[messaging] TFC - Onion routed messaging with endpoint security

Markus Ottela oottela at cs.helsinki.fi
Thu Jan 24 07:27:39 PST 2019


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



More information about the Messaging mailing list