Greetings from VanHack!

Hello Noisebridgers!

I’m reaching out from Vancouver Hack Space (also VHS, or VanHack) to see if Noisebridge would like to connect with us. We are testing out a hardware-secure messaging client called Tin Foil Chat locally at the space, and we wondered if Noisebridge would like to create a node to link our spaces. If things go well between us, maybe we could expand the network!

Here’s a pic of our full hardware isolated TFC node in action:

Any questions, feel free to reach out. You have some NB fans up north!

(Plot twist - it’s actually a listening device …)

Nice try, FBI

Seriously though … WHO SENT YOU? WHO ARE YOU WORKING FOR?

back into your Faraday cage, daemon!

Uhhhhhh…ummmmmm…

(pretend this never happened)

jitsi.noisebridge.io/hackitorium ← let’s talk :slight_smile:

Hey! I’m on East Coast time, and was asleep when this was posted (early night). And for sure! I think we’d love to connect, keeping hackerspaces alive has been tough over here.
It sounds like we’ll need to configure our Unicorn server or similar NB affiliated device (Cc @James) to get this working. Maybe we can install this and take it out for a spin with you guys?

The idea of the design is to have have “partially airgapped” computers talk without the ability for any actor to remotely exfiltrate meaningful data. Each endpoint needs 3 computers that utilize a data diode to enforce the one-way flow of information. Messages are typed into the upstream computer and sent across a data diode to the networked computer. They are then passed to a contact’s networked computer which forwards them across another data diode pointing toward a destination computer. Like this:

The are three levels of configuration:

  • Testing config that simulates 3 computers

  • Qubes OS config that uses strict firewall rules to pass info between VMs.

  • Hardware data diode config that uses 3 X86 computers and the physical data diode device. Designed to be secure against remote APTs.

I recommend anyone interested check out the Github page for TFC:

We’d love to help you guys get set up :slight_smile:

1 Like

Hello VHS! It looks like proper setup would involve some actual hardware on-site, will dig into git and see what all is involved there.

If you happen to be available please join us or send an emissary to our weekly general meeting tonight starting at 8pm https://jitsi.noisebridge.io/hackitorium#config.startWithAudioMuted=true&config.startWithVideoMuted=true

I appreciate your ephemeral protocol which looks you intend for this thread to auto disappear, we can also switch it to visible to logged in users only to side step the scrapers.

Made me curious on using ARM devices with the diode… what are the actual minimum system specs needed for each of the machines? When generating the VM’s how many cores and ram do you allocate?

Found this thread detailing Raspberry Pi’s not being supported, but the fact remains that there is a vast variety of both ARM and x86 sbc devices all over the market. Would be really useful to know exact specs required for setting this up on each of the three machines. Also, I see no mobile support is possible, which is fine. Cool project!

Hi everyone! The good folks at VHS I’ve been helping a bit linked me this thread.

I added some recommendations for system requirements to the FAQ.

Indeed. The main requirement is, in data diode isolated configuration you should be able to remove all hardware that could be used to exfiltrate keys from the Source/Destination computer. Many SBCs seem to sandwitch the Wi-Fi/BT into the CPU die itself, which makes them difficult, if not impossible to airgap reliably. This is why I gave up supporting Raspberry Pis after gen2.

Given the past discussion with VHS, the goal doesn’t seem to be dialing the isolation to 11, thus anything that runs Python3.7/3.8 should do fine. I’ll try to help you debug issues on SW side if you encounter any. Alas, I’m not made of money atm so buying SBCs isn’t currently possible.

The Networker side of TFC (Networked Computer + Relay Program) could in theory be run on a smartphone with a dedicated client, but unfortunately the bulkiness of data diode and Source/Destination computer would still be a problem:

Reliably airgapping a smartphone for use as Source/Destination Computer requires Andrew Huang -level skills. At most I could assume the user is able to remove wifi-cards and perhaps solder through-hole components (or at most, SMT components of an inexpensive HW such as the data diode PCB).

The user probably already owns some form of laptop/desktop PC for daily use, so the assumption is they’d use that as the networker.

For really compact setups, three GDP Pocket2s with de-soldered Wi-Fi interfaces, and data diode with USB-to-TTL adapters inside the USB-plug could be used. But that’s anything but inexpensive / easy.

Quick correction here. This was indeed the case in previous versions, but it’s since been upgraded to use Qubes’ qr-exec RPC (the same one Qubes uses to send files from one VM to another) which removes the network stack from the attack surface.


Anyway, let me know if you have any questions! :smile:

2 Likes

Thanks!!! :heart:

Makes sense, perhaps we can work together to find a casual, off-the-shelf diy solution. Here are a couple 64-bit x86 sbc devices:

RockPi X - brand new $49 - $59 x86 sbc device with up to 4gb ram.
Atomic Pi - x86 sbc device with 2gb ram that has always been ~$40.00

Any suggestions on how I might find devices that avoid this? Perhaps those without Wi-fi and BT…?

RockPi E is available 64-bit ARM with no wifi/bt and 2gb ram for $35.00 while remaining Super tiny. For $37.00 you can add POE.

Nice, curious on any ways to make this both more affordable, possibly require less power, and be compact! Obviously, that is not the primary goal when we can also use VM’s. :+1:

We do have spare boxes which could be re-purposed for a physical hardware version.

Totally understandable as an individual. Maybe we can work together in acquiring the hardware to test out various configurations that work for the spaces!

Yeah that should do it. Some netbooks may be cheaper than a $40-50 SBC + screen + peripherals + battery and charger. It of course depends on what the hackerspace has to provide beforehand. I’m myself using age old ~200USD netbooks that have removable wifi network cards.

E.g. Newegg lists some sub $200 chromebooks that might run Ubuntu.

TFC also has something called local test install configuration that runs the three main programs in Terminator. The only “isolation” is the behavior of the programs to only send or receive data. There is no key exfiltration security in that case but it’s not a large concern for a hackerspace with multiple users.

VMs could of course be used if one wanted to pass data between VMs via bridged USB-to-TTL adapter and the hardware data diode. (The Qubes configuration uses VM based isolation for SW only security). The local test runs even the cheap netbooks, but running e.g. three VirtualBox VMs requires a bit more computing power, and the QubesOS is incredibly picky on HW and requires at least 8GB of RAM etc.

Wonderful! A community working on finding usable hardware is what I’ve always hoped would happen!

might find some ideas to consider for hardware here -> https://libreboot.org/docs/hardware/

1 Like

Super cool project! What are your goals with TFC? How can it be extremely important in the grand scheme of things?

If it can run on totally open hardware, allow for many identities per physical node, and be made as easy to get started with and accessible as possible, I could imagine something like this as an even more secure alternative to SecureDrop, perhaps.

What are the technical limitations on message size? I ask in thinking about sending files over TFC – perhaps ones too large to fit into RAM.

1 Like

What are your goals with TFC?

Time will tell. Currently it’s in maintenance only.

How can it be extremely important in the grand scheme of things?

The remote exploitation of endpoints will become a tool of first resort for LEAs due to the deployment cost of exploits being negligible compared to the sunk cost of their development so over time the project (or at least the architecture) will become quite a bit more important.

allow for many identities per physical node

It’s currently not possible to do this but there’s no technical requirement. “Multiple identities” might not even be necessary once Tor Project implements prop224 basic authentication so you can appear selectively online. But if there’s a use case for it, it wouldn’t be impossible to add multiple identities. But new features will have to wait, I’m focusing on my studies for the time being.

I could imagine something like this as an even more secure alternative to SecureDrop, perhaps.

Sure, journalists could use TFC to establish secure anonymous links with sources. Both endpoints need to be powered on continuously to allow asynchronous communication. However, purchasing TFC-related hardware etc. isn’t necessarily what a non-technical whistleblower would want, and ordering the components etc. might leave a bigger paper trail than throwing Tails onto an old thumb drive and disposing of the thumb drive and an old laptop after making the leak via public wifi hotspot. So the OPSEC is quite complicated. IMO TFC works better in closed communication of political dissidents etc.

What are the technical limitations on message size?

The size of RAM is the only limiter for individual messages. Larger text should be sent as file (as it’s faster and has less parsing overhead on receiving end). If traffic masking mode is used by the sender, even files are sent as individual message-like packets. Traffic masking is very slow for sending large files, but the idea is you’re sending packets at constant rate anyway, so sending file data is more useful than sending noise data. Also, sending a file has smaller priority than messages so the file transmission will take place when you’re not chatting.

I ask in thinking about sending files over TFC – perhaps ones too large to fit into RAM.

TFC uses compression for files and larger messages so AFAIK the entire compressed data needs to fit in RAM. Files larger than the RAM probably shouldn’t be sent over TFC anyway, as that will must likely unnecessarily tax the Tor network. But it can be done by splitting the compressed file in multiple parts (separate compression programs have better support for decompressing several parts). It’s also a bad idea in general. At the default speed of 19200 bauds, sending a 1GB file over data diode takes more than 6 days.

Another issue is the Reed-Solomon erasure code that adds a lot of computational overhead for large amounts of data. So you can stretch these limits by disabling error correction, and/or by increasing the serial interface baudrate, or by tweaking your own fiber-optic data diode. But since the isolation mechanism breaks if you try to forward a file by moving it manually from Destination to Source (never do that!), TFC will never be practical as a file sharing tool. However, a journalist/protester uploading a photo or small video from conflict zone by connecting the camera only to Source Computer, is something that can be done.

1 Like

Whoops, meant to say “there’s no technical restriction”.

Good point; I agree that LEA hacking will likely become more prevalent over time.

I was thinking more like journalists running TFC hardware and sources doing the software-only version.

Does it make the hardware significantly more expensive to increase the bandwidth?

I could see that being a reasonable possibility since the journalist’s endpoint might contain the private information (or enough to deanonymize them) of several sources. I would still recommend sources use at least the Qubes isolated configuration if SW only approach is to be used. The only inconvenience is the setup time and it’s already a lot more secure. In general up-to-date smart phones are more secure than desktop OSs, so e.g. Briar / Signal might be more secure than the local testing configuration, especially if the desktop OS isn’t fresh, and is running all sorts of software. The next release of Ubuntu will finally default to Wayland so users get intermediate isolation between programs.

The optocoupler of the data diode design is rated at 50Mbps, but the serial interface tends to cap it at around 2Mbps. I’ve had success in transferring data at around 10Mbps with daisy chained ethernet-to-fiber adapter system and heavily error corrected UDP streams via udpcast program, but that was never implemented for TFC. The earlier Qubes configuration used UDP for inter-VM communication so the git history has mostly production ready code if there is desire to expand the functionality. You can see one example of such data diode system at github. The forum is picky about sharing links so check the dyode project under the Github account wavestone-cdt.

The idea of daisy chaining is,

  • The Tx-side of first adapter in the chain announces itself to the second adapter
  • Upon receiving the signal to it’s Rx side, the Tx side of second adapter sends a confirmation back
  • The confirmation is actually forwarded to the Rx of the third adapter
  • The third adapter can’t tell its Tx is not connected to the second adapter, and depending on the protocol, the third adapter will either
    • Be ready to receive because it received the confirmation from second
    • Send a second confirmation back to what it thinks its communicating with via its Tx, but it’s actually forwarded to Rx of fourth adapter.

Regardless of whether three or four adapters are needed, the last one in the chain will only send unnecessary confirmation information wrt. TCP packets, but since it’s only UDP that’s being used, the sending device doesn’t block on not receiving confirmations.

The price isn’t astronomical, but still noticeably higher:

The TTL-data diode takes three 16USD TTL adapters, PCB ~1$, two 3USD optocouplers, and a few other tiny copmonents ~5USD so it’s roughly 60 USD.

The fiber-optic data diode takes 3-4 adapters per direction, so 6-8 units of fiber-to-ethernet adapters at á 30 USD.

SC-to-SC patch cables are about á 8 USD and you need 2-3 per direction so that’s 32-48 USD

Cheapest 3ft Cat5 Ethernet cable is á 3 USD, you need two of those per direction and might want one for WAN connectivity so 12…15 USD

Plus you probably need at least one extra USB-to-Ethernet adapter for the Networked Computer, but if none of the computers feature RJ-45 port, you need four or five depending on whether you want Networked Computer to connect to WAN via Ethernet, or wireless. USB-to-Ethernet adapters are 13 USD on newegg so 13-65 USD.

180…240 + 32…48 + 12…15 + 13…65 brings you to total of 237…368 USD per user. So the daisy chained fiber data diode is 4…6 times more expensive than the TTL adapter version. That alone wouldn’t be too bad, but two netbooks for TCB add about 400 to the price, unless you have old laptops lying around. But it’s still dirt cheap compared to commercial data diode units. I have no price quote, but since they’re usually EAL7+ certified (highest possible common criteria evaluation which imples formal audits etc.), my guess is the prices are between 3,000 and 15,000 USD per unit, and you need two of those per user.

So my guess is average user will rather deal with the 19200…2M baud transfer rates. Companies might be more interested in the fiber-optic version, or using commercial data diodes, especially if they want to establish secure communication nodes for, e.g., executive level communication between offices.

Hardware Requirements & Raspberry Pi:
I saw the thread explaining that Raspberry Pi is a no-go due to on-die wireless. I’m curious if the Raspberry Pi Zero (1st gen, not the W model) could work for source/dest. It has no wireless, a great form factor, and the price is right. Additionally, it exposes UARTs directly (via PiHat), eliminating the need for an FTDI board. The only drawback I see is that it falls significantly short of the advertised system requirements, having only 512 MB RAM and a single-core, 1 GHz, 32-bit CPU. My questions are:

  1. Are 64-bit, 2 GHz, 4 thread, 1 GB hard requirements for TFP to work, or will a less-capable system work but just be less performant?
  2. Can you elaborate on what, specifically, relies on these resources?
  3. Is there opportunity to reduce these system requirements either in software or through alternative hardware?

OpenBSD
Is there existing or planned support for OpenBSD as the OS used for source/dest/networked computers? If not, could you give a quick overview of which components would need a porting effort beyond recompiling?

Also, what are your thoughts on dedicated FPGA implementations for source/dest?

The only resource-intensive part is the Argon2 key derivation function. The idea is Argon2 on fast hardware compensates weaker passwords for physical attackers who would try to compromise the databases to get access to contact list/keys/message logs. The Argon2 implementation adapts according to system specs so it should run on pretty much all hardware. For PSK key exchange, the the PSK is delivered to contact encrypted with a key that is derived from another password with Argon2. The limitation in this case is it’s hard to guess the HW resources available for contact, so I had to set RAM to somewhat high but not too high. The current value is 512 Mebibytes, but a closed circle of peers can of course set it lower if they have less free ram. Not sure if a RPiZero with 1GB running Raspbian has 512MiB of free RAM, but users can adjust the value by editing src.common.statics, line 556. If you do that, make sure you use strong passwords. The easiest way to do that is to type in the password generate that automatically generates a 128-bit passphrase using EFF wordlist. If automatically generated passwords are used, Argon2 is safe even with lowest specs (1 thread, 32768 kiB RAM, 1 iteration).

Number of cores for PSK is set to 2 but that shouldn’t cause problems even if the CPU is single threaded, it just means a single core has to do context switching while handling both threads. The number of threads can be adjusted right below the memory cost variable, and iterations (time cost) are just above memory cost the statics.py file.

The 64-bit requirement is something I also need to figure out. I hate myself for not documenting the reason for the requirement, now I have to backtrack git log to see what caused 32-bit CPUs to not work.

The 2GHz is a QoL thing, if the OS can deal with slower CPU, it’s fine. In addition to Argon2, one part that does add computational overhead is the Reed-Solomon erasure codes, especially with large file transmissions. Unfortunately the RS implementation is pure Python: I couldn’t find any library that would provide bindings for e.g. an implementation written in C. The erasure code can be replaced with BLAKE2b based checksum for error detection with the command /set serial_error_correction False and restarting TFC. The rest of TFC is very lightweight, including the cryptographic algorithms like X448 and XChaCha and should run just fine even on a potato.

Is there existing or planned support for OpenBSD as the OS used for source/dest/networked computers?

The endpoint security properties are mostly the guarantees that are accomplished with the hardware data diode, so I haven’t looked too much into less popular OSs, although I totally get especially Destination Computer would benefit from a hardened OS. I have more time in my hands in June, I’ll take a look then. It’s been 5+ years since I last had a look at OpenBSD, so perhaps any issues it may have had then, have been resolved.

Also, what are your thoughts on dedicated FPGA implementations for source/dest?

That would be an interesting project, but alas it’s outside my programming skills. The Python implementation can of course be used as a higher level PoC and guideline for lower level implementations. I’m not sure if FGPA based endpoint would be more secure against remote inputs (but a correct implementation definitely reduces attack surface, and if it is also immutable to a remote attacker, that would definitely be something).

Let me know if you have more questions!