[messaging] TFC - Onion routed messaging with endpoint security

[dawuud]

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
-------------- 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/20190124/335f9281/attachment.sig>