Re: [briar-devel] Threat model

[Michael R. <mi...@br...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi David,

Thanks for the questions!

On 23/07/12 16:47, David Fetter wrote:
> 1.  "There are some users who can keep their nodes secure - those
> who can't are considered, for the purposes of the threat model, to
> be controlled by the adversary."
> 
> Given that any node could be compromised, how is information about 
> such a compromise disseminated?  What precautions, if any, are in 
> place around using that dissemination system as an attack vector,
> e.g. falsely accusing one or more nodes of being compromised?

We've come up with a few ideas for addressing this problem. The
simplest idea is called device revocation. If Alice loses any of her
devices, she uses any of her remaining devices to send a revocation
message to her contacts. The revocation message lists the devices that
have _not_ been lost. Each contact who receives the message places any
unlisted devices in quarantine. While a device is in quarantine, the
only messages that will be accepted from it are revocation messages.

Alice can use a device to revoke itself if she fears she's about to
lose it - to do that, she sends a revocation message that doesn't list
the device itself.

The rationale for quarantine is as follows: Imagine that Alice's phone
is stolen but her laptop is not. The adversary uses the phone to
revoke the laptop. Later, when Alice realises her phone has been
stolen, she uses the laptop to revoke the phone. Which revocation
message should Alice's contacts believe? The only safe answer is both
- - they shouldn't talk to either device until they can meet face to
face with Alice to discover which device was really stolen.

But for that to work, the contacts have to accept revocation messages
from revoked devices. So we create a special quarantine state where
revocation messages are accepted but all other messages are ignored.

This idea has some serious limitations. If Alice loses all her
devices, she can't send a revocation message. If Alice is arrested,
her contacts don't have a formal way to warn each other not to trust
her devices. We've discussed some ideas for dealing with those
situations, but all the ideas we've come up with so far are complex
and have privacy implications.

> 2.  "The adversary has a limited ability to persuade users to
> trust the adversary's agents - thus the number of social
> connections between the adversary's nodes and the rest of the
> network is limited."
> 
> In places like the former East Germany, this assumption was wholly 
> false.  To what extent is the Briar system sensitive to its being 
> true?

If a Briar network is thoroughly infiltrated by the adversary's
agents, the adversary will know who belongs to the network and most of
the groups each user subscribes to. The adversary will also be able to
make educated guesses about which pseudonyms belong to which users.
That's far from ideal, but I believe it's no more information than the
adversary would learn from any other communication system for a
comparable cost.

For example, if instead of using Briar the users were to use Tor to
post messages on a forum, the adversary could compile a list of Tor
users from the ISP's connection logs and make an educated guess about
which users were posting which messages by comparing the connection
logs with the messages' timestamps. If the users were to set up
private bridges to conceal their connections to Tor, the adversary
could discover the bridges by infiltrating the social network.

In general, it seems to me that a secure communication system can
either use public contact points, in which case the adversary can
block and/or monitor access to the system automatically, or private
contact points, in which case the adversary can block and/or monitor
access to the system through infiltrators. The best we can do is to
force the adversary to use lots of infiltrators.

Thanks again for the questions. Please feel free to follow up on any
of the above points or ask any other questions that come to mind!

Cheers,
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJQDajRAAoJEBEET9GfxSfMyygIALUKJ9Uu5rWhoU2HNBmMH5Ut
ytTbyxWchqV2HsC5xVI2FsmA2TvaWgMg4alxCJbXiq5JtZs1fYfDLMXs/B8/bQzx
TRT+hQWRgXRZ7Sx/sMeQAkOuGAF+W/KQpTbE8hxwdp0uX90UQuIlBTYwIw08D9Ul
SlRCcJNx3GhEpJWnzqJWBqerPQKErusRMqloVuKmOQW+xrfyfB6r3bLg2zPeud4D
VJtHeXWlsG/AlmbtzUdoZOjQgZ3sjM6vvqHdUW8Olc9vdd1o/j/l8ItfAnAAUp0I
WqcAUlxmz2T2LLEA6wsvqSdHW9Ip3EVpKESa+D45JgGY2vqYHx0tSJiei7q76tY=
=0UkM
-----END PGP SIGNATURE-----