[messaging] TFC - Onion routed messaging with endpoint security

[dawuud]

Hi Lennart,

Thanks for publicly posting this question.
Below are some papers. Perhaps I have missed something
and someone on this list will hopefully decide to be
helpful and tell us.


Roger of Tor Project wrote a blog post on this topic:
https://blog.torproject.org/one-cell-enough-break-tors-anonymity

In that post he mentioned several papers:

The Traffic Analysis of Continuous-Time Mixes
by George Danezis
https://www.freehaven.net/anonbib/cache/danezis:pet2004.pdf

Approximating a Global Passive Adversary Against Tor
by Chakravarty, Sambuddho; Stavrou, Angelos; Keromytis, Angelos D.
https://academiccommons.columbia.edu/doi/10.7916/D82J6QBM

How Much Anonymity does Network Latency Leak?
by NICHOLAS HOPPER
EUGENE Y. VASSERMAN
ERIC CHAN-TIN
https://www.freehaven.net/anonbib/cache/tissec-latency-leak.pdf

I continued looking for more papers and found this:

Analyzing the Effectiveness of Passive Correlation Attacks
on the Tor Anonymity Network
by Sam DeFabbia-Kane
https://pdfs.semanticscholar.org/17a6/736b5b8d9a2e516adbebb338e3265681b1c9.pdf



Sincerely,
David


On Sun, Jan 27, 2019 at 01:20:57AM +0100, Lennart Oldenburg wrote:
> Hi David,
> 
> Could you (or the larger group here) point me to the paper that
> trivially deanonymizes Tor users with timing attacks in a few seconds
> once conducted by a global adversary?
> 
> I heard that argument before and am currently trying to find the
> academic reference it is based on.
> 
> Thanks a lot in advance!
> 
> Best
> Lennart
> 
> On 24/01/2019 21.56, dawuud wrote:
> > 
> > Hi Markus,
> > 
> > It's kinda cool your thorough defense of endpoint security.
> > Certainly I agree with you that endpoint security is important.
> > But since we are on a mailing list that is obstensibly about
> > solving messaging problems I will focus my comments on these issues instead.
> > 
> > I'd like to point out that the secure messaging problem isn't really solved yet
> > because there is currently no deployed encrypted messaging applications that provide
> > traffic analysis resistance against global adversaries. This of course includes Tor
> > which can trivially be broken in just a few seconds using timing correlation.
> > And to make a more nuanced point, so called "secure messaging" applications
> > should be using multiple security domains; currently this is my main criticism
> > of Signal messenger besides requiring the use of phone numbers.
> > 
> > I feel totally justified on harping on this one point until we arrive
> > at a good solution because ex-NSA director, Michael Hayden is famously
> > quoted as having said: "We kill people based on meta-data".
> > 
> > Onion services do hide geographical location from adveraries that
> > are unable to break Tor. But is this really an appropriate threat model?
> > Do you think colluding nation state adversaries cannot break Tor?
> > The conclusions of the academic literature on these points are quit clear
> > and there is over 37 years of published academic literature on the topic
> > of anonymous messaging. Many of these papers describe systems that
> > have far stronger threat models than Tor, things like:
> > 
> > * decryption mix networks
> > * verified mix shuffles
> > * private information retrieval
> > * dining cryptographer networks
> > * broadcast based designs (with trial decryption)
> > * oblivious random access memory
> > * secure multi-party computation
> > 
> > I don't understand why you decided to use the term "traffic masking".
> > Isn't this "traffic padding"?
> > 
> > Without a proper statistical model to assist in tuning it's not clear
> > how much this will help. I should mention that Tor Project is very
> > interested in using traffic padding in future versions of Tor and
> > they wish to encourage academics to explore this possibility. Clearly,
> > it will take at least one PhD worth of research to establish safety
> > margins in the use of traffic padding for Tor and I suspect discrete network event
> > simulators will help with this.
> > 
> > 
> > Cheers,
> > David
> > 
> > On Thu, Jan 24, 2019 at 05:27:39PM +0200, Markus Ottela wrote:
> >> Hi!
> >>
> >> The traffic here is quite low so I hope it's ok if I post my work:
> >>
> >> TFC (https://github.com/maqp/tfc) is something I've worked on since spring
> >> 2012. The idea was to create a messaging system that splits the TCB on two
> >> airgapped computers that communicate with a networked computer via
> >> unidirectional gateways. To enforce the unidirectional behavior it's using a
> >> simple circuit that for each direction uses an optocoupler as an optical
> >> repeater in the middle of a serial gateway: The photoelectric effect in LEDs
> >> is inefficient, and the photodiodes do not emit light, so the IC only works
> >> in one way.
> >>
> >> This hardware layout prevents remotely inserted malware from entering the
> >> Source Computer (that outputs ciphertexts). It also prevents the malware
> >> from exfiltrating keys/plaintexts from the Destination Computer (that
> >> decrypts incoming messages). The Networked Computer only ever sees
> >> non-sensitive data like ciphertexts and public keys.
> >>
> >> On Networked Computer the relay program runs a v3 Onion Service and web
> >> clients needed to request data from Onion Services of contacts. In this
> >> respect it's similar to Ricochet: There is no server in the middle to tap.
> >>
> >> As for cryptographic primitives, TFC uses single X448 (OpenSSL
> >> implementation) that by default prompts the user to verify base10
> >> fingerprints. XChaCha20-Poly1305 (libsodium implementation) has per-message
> >> forward secrecy that relies on BLAKE2b hash ratchet. Keys are generated with
> >> GETRANDOM syscall. All sensitive persistent data on endpoints is encrypted
> >> with the same XChaCha, and the key for it is derived from salt and password
> >> using Argon2d.
> >>
> >> Since during key exchange the public key needs to be typed manually into the
> >> Source Computer, DH ratchet and thus future secrecy isn't practical. The
> >> user can of course re-exchange keys whenever they like it. The lack of
> >> future secrecy is compensated by the architecture that prevents key
> >> exfiltration.
> >>
> >> The application is written in Python (3.6), is FOSS, and the HW is Free
> >> Hardware Design (circuit diagrams and step-by-step build instructions are
> >> available). The code has type annotations and I've tried to make good unit
> >> tests for it.
> >>
> >> For metadata protection I tried to make TFC to install anonymously. Onion
> >> Services hide geo-location and identity of the users. I've also added an
> >> optional traffic masking feature that locks Transmitter Program to a
> >> selected contact/group, and sends a continuous stream of noise packets to
> >> those recipients. Files and messages are inserted into the noise stream when
> >> needed. This should hide quantity, schedule, and type of communication even
> >> from an adversary that compromises the Networked Computer of sender /
> >> recipient.
> >>
> >> It's not perfect however. There's a bunch of attack vectors from Source
> >> Computer compromise during install to covert exfiltration channels in
> >> Destination Computer. I've tried to be as thorough as possible about these
> >> risks in the threat model / security design articles, which you can find
> >> from the project's wiki: https://github.com/maqp/tfc/wiki
> >>
> >> Any feedback / criticism is more than welcome!
> >>
> >> Markus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20190127/c98b7cb1/attachment.sig>