[messaging] TFC - Onion routed messaging with endpoint security

[Lennart Oldenburg]

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
>>
>> _______________________________________________
>> Messaging mailing list
>> Messaging at moderncrypto.org
>> https://moderncrypto.org/mailman/listinfo/messaging
>>
>> _______________________________________________
>> Messaging mailing list
>> Messaging at moderncrypto.org
>> https://moderncrypto.org/mailman/listinfo/messaging