Tinfoil Chat (TFC) is a high assurance encrypted messaging system that operates on top of existing IM clients. The free and open source software is used together with free hardware to protect users from passive eavesdropping, active MITM attacks and remote CNE practised by organized crime and nation state attackers.
XSalsa20 encryption and Poly1305-AES MACs provide end-to-end encrypted communication with deniable authentication: Symmetric keys are either pre-shared, or exchanged using Curve25519 ECDHE, the public keys of which are verified via off-band channel.
Key generation relies on Kernel CSPRNG, but also supports mixing of external entropy from open circuit design HWRNG, that is sampled by a RPi through it's GPIO interface either natively, or remotely (SSH over direct ethernet cable). TFC provides per-message forward secrecy with PBKDF2-HMAC-SHA256 hash ratchet.
The software is used in hardware configuration that provides strong endpoint security: Encryption and decryption are separated on two isolated computers. The split TCB interacts with a third, networked computer through unidirectional serial interfaces. Direction of data flow is enforced with free hardware design data diodes; Lack of bidirectional channels to isolated computers prevents insertion of malware to the encrypting computer and exfiltration of keys and plaintexts from the decrypting computer -- even with exploits against zero-day vulnerabilities in software and operating systems of the TCB halves.
TFC supports multiple IM accounts per user to hide the network structure of communicating parties, even during end-to-end encrypted group conversations.
TFC allows a group or two parties to defeat metadata about quantity and schedule of communication with trickle connection, where messages are inserted into a constant stream of encrypted noise traffic. Covert file transfer can take place in background during conversation over the trickle connection.
How it works
TFC uses three computers per endpoint. Alice enters her messages and commands to program Tx.py running on her transmitter computer (TxM), a TCB separated from network. Tx.py encrypts and signs plaintext data and relays the ciphertext from TxM to her networked computer (NH) trough a serial (RS-232) interface and a hardware data diode.
Messages and commands received to NH are relayed to IM client (Pidgin or Finch), and to Alice's receiver computer (RxM) via another serial interface and data diode. The program Rx.py on Alice's RxM authenticates, decrypts and processes the received messages and commands.
The IM client sends the packet either directly or through Tor network to IM server, that then forwards it directly (or again through Tor) to Bob.
IM client on Bob's NH forwards packet to NH.py, that then forwards it to Bob's RxM (again through data diode enforced serial interface). Bob's Rx.py on his RxM then authenticates, decrypts, and processes the packet.
When the Bob responds, he will send the message using Tx.py on his TxM and in the end, Alice reads the message from Rx.py on her RxM.
Why keys can not be exfiltrated
Malware that exploits an unknown vulnerability in RxM can infiltrate the system, but is unable to exfiltrate keys or plaintexts, as data diode prevents all outbound traffic.
Malware can not infiltrate TxM as data diode prevents all inbound traffic. The only data input to TxM is the public key of contact, which is manually typed by the user.
The NH is assumed to be compromised: all sensitive data that passes through NH is always encrypted and signed.
Optical repeater inside the optocoupler of the data diode (below) enforces direction of data transmission with the laws of physics.
Supported Operating Systems
TxM and RxM
- Tails 2.6
- *buntu 16.04
- Linux Mint 18 Sarah
- Raspbian Jessie