[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