Extremely cool that you came up with the same architecture as Tinfoil Chat @phnx linked above.
Which OS to use for each computer
With respect to message confidentiality, the networker (computer 1 in your case) can be pretty much any OS you want, it has very little to do with the security aside managing whatever routing protocol you want to use for the ciphertexts. Qubes doesn’t have root password for VMs so privilege escalation is trivial. Make sure everything sensitive passing through that computer is encrypted beforehand.
With respect to metadata, Tails is the ideal distro for computer 1 as its content can be identical to each user, making it really hard to identify user from files alone, when remotely accessing the OS. Registered HW IDs etc are of course a problem, so second-hand, COTS HW etc are advisable.
Computer 3 (Destination computer) doesn’t have to run Tails. The endpoint security provided by the data diode ensures there’s no way to exfiltrate keys. But, the more internal hardening it has, the harder it is for malware to cause issues. if you’d run Qubes on destination computer, you could move received attachments to other VMs to protect them from receiver VM compromise.
The computer 2 that acts as the source computer is the most critical for security, but since the data diode protects it from incoming data, it’s effectively immune to remote compromise. Thus it doesn’t matter too much which OS it has, as long as it’s FOSS. OTOH, Remember: if it’s infected via other means, the compromised device can covertly exfiltrate keys to computer 1 during idle hours.
Questions
Do you think 3 letter agency can steal private key stored on No.1 –
The computer no. 1 in your design is the one connected to network: private keys can be stolen from it. Again, please don’t store anything requiring confidentiality on it.
–or decrypted messages stored on No.3?
The computer no. 3 that receives messages is more or less exfiltration proof, provided you can eliminate all covert channels, there’s a long list of those. This requires users to make physical changes to their HW according to their threat model. If the malware on receiver computer can exfiltrate a private key by blinking the screen during the night and the (web)camera of a nearby internet-connected device can read the changes in lighting, you’re out of luck. The material that needs to be exfiltrated is usually tiny, just 256 bits.
Do I deserve to buy expensive data diode for my privacy?
The EAL7+ certified stuff is good investment if you’re managing security for Washington Post whistleblower line. Not so much if you’re an individual looking for a balance between affordable and secure.
There’s two ways to hack a cheap data diode
-
Daisy chain 2-4 ethernet to fiber converters and use something like udpcast to send data. Do note that the 2-4 converters is per direction. Avoid ordering from Ebay; The ones I got had moisture damage. The higher the quality of converter and fiber, the less you have to deal with error correction. The faster the link and the slower the transmission speed, the more reliable it gets, so compared to the EAL7+ stuff, splurging a bit and getting gigabit converters for 10…100Mbps connection is not a bad idea. If your implementation requires multiple converters, the fibers carrying just the negotiation signals don’t have to be high quality. I’m unsure if there’s any way to determine how many converters you need as it seems to depend on the model, but I’d recommend getting 4. If you only need 2 per direction, you’re in luck and you have what you need, and if it requires 3 or 4, you know how many more you need to order. As for the fiber optic cables, get two good quality ones for file transmission, and 2-4 low quality ones for the carrier signal
-
Build one yourself. TFC documentation has a few guides on how to build one using serial interface with TTL level voltages. Do note that the USB-to-TTL adapter used in the guides hasn’t been in production for some time, and thus the designs are a bit outdated. But if you know your way around electronics, attaching ones like this is much more future-proof as it’s circuit design agnostic: It has adjustable switch for both 5V and 3.3V VCC (and probably Tx/Rx pin) to power on the optocoupler, and the jumper cable adjusts to whatever circuit design you use.
I think data diode isolation is better than Qubes OS or Graphene OS isolation system, because it prevents from cpu vulnerabilities or firmware exploit.
Yeah software protection is always going to be inferior to HW giving physical limitations to which direction data transfer can happen.
My recommendation is to see if TFC can provide you with the functionality you need. It has 1:1 chats, group chats (to the extent it can be implemented), and file transfer. You can try it on a single OS (so called local test configuration) or in a three Qubes VM layout first.
Since you’re already thinking about designing a system –
One thing the project has taught me, is there’s a LOT that can go wrong with designing the system, and even things that first seemed right, have on closer inspection caused the endpoint security to fail catastrophically – the clearest example being the bootstrap key exchange between the isolated devices. So heed my warning: building another protocol from scratch is a long, long, long, rocky road and there’s not too many people with experience building stuff like this. And personally, I’m too busy with the rest of my life to do anything more than maintain the codebase.
Thus, you’re on your own. If you decide to still proceed, you might want to read through the documentation and code in depth first: it’s going to save you nothing short of years in development time.