Schneier on Security

maqp • February 18, 2018 6:03 PM

@Sancho_P

TL;DR, what I’m missing is your / TFC’s specific goal

The readme starts with “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.”

what is the intended audience

The FAQ says: TFC is for everyone who consider it necessary to assess their threat model: adversaries that hack endpoints.

(This should be more clearly stated, but the readme implies it as well.)

the adversary, where are the limits.

Threat model tackles the adversary and limitations.

Re complexity: Yes, the system is too complex for my simple mind, but would I be the only idiot to botch it up at the first attempt to use it?”

Assuming you’re able to follow the instructions, no you wouldn’t.

My thinking is about a tamper-evident box with three ports, data in, data out and key, likely some buttons / a display (if absolutely needed).

Sounds like more work and building for the user. Where does the data come in? It’s either a) a system connected to network: That’s as secure as standard CA cert signing where remote compromise of automated certificate creation might allow production of rogue certs. Or b) it’s a dedicated airgapped computer taking input from user and feeding it through data in, you might as well trust that system to run the code that manages keys and encrypts messages that get output to network. TFC is already doing that. I don’t think user should be making any more hardware than they already have to.

I don’t think the system should be taking a stream because real time communication with Tor is too slow. Also, having unauthenticated stream would be dangerous, and bundling 24-byte counter and 16-byte MAC for small chunks of data causes overhead for serial. The decryption device should tell the user if encryption fails because that implies tampering.

Encryption is decryption

In a way, XChaCha20 is a stream cipher so you XOR with same keystream, but what do you mean?

At your TxM / RxM machines the single transmission line is already the logical data diode. There is no return channel, so why adding the HW?

Quoting Security Design:

While serial interfaces most likely have more than just rule-based limitations on Tx/Rx pin assignment, more assurance should be sought. To guarantee unidirectional behavior, a simple hardware device called data diode is required in between sending and receiving serial interface.

The trick is the simple communication principle: The sender is broadcasting but doesn’t know if there is any receiver, and it will not accept any feedback.

That is true for the Transmitter Computer. However, the Networked and Receiver Computers might have vulnerabilities that add receiver functionality to Networked Computer and sender functionality to Receiver computer. The malware on Receiver computer can then leak keys and/or plaintexts. Malware could theoretically remap Rx-pin on Receiver Computer’s serial interface to send for some specific time period; It’s impossible to inspect what the controller can or can not do. All you can do is distribute trust on what enforces unidirectionality. You can use optocouplers, or even dumber components where logical components are near impossible to hide.

Ethernet is dangerous because (when) it relies on feedback

Quoting Security Design: “features such as auto MDI-X make it impossible to enforce unidirectional UDP transmission over Ethernet”

Simple serial ends in a HW shift register + buffer

I’m not sure if you’re talking about the same thing, but e.g. here is an example of buffer based unidirectional link. It’s a bit simpler in design but not nearly as trustworthy as the optocoupler. There is very little added inconvenience from the bread board data diode design, so I don’t think it’s worth it.
Let me know if I misunderstood what you meant.

Reprogram your system via serial? Possible, but only when your SW permits, and it is not easy to achieve.

So the question is, does the NSA know of a zero day in serial interface’s firmware? I don’t know but I’m trying to design a system that assumes they do yet remains secure exfiltration-wise.

With that in mind I challenge your TxM / RxM separation, because in principle it is one device that could be switched (or even turned around) from send to receive and back.

If you’re going to be moving data back and forth from airgapped system to single system, you might as well use airgapped computer and e.g. PGP, and move data across the gap via serial where transmitter is on only when you output (and when stuxnet style malware chooses to transmit). This issue is discussed in the threat model.

I’m still a fan of good old OTP, but even with complex encryption you’d need a key, don’t you?

TFC-OTP could have (but never did) encrypted the key pad with symmetric encryption before it touched Transmitter/Receiver Computer disk. The problem there was I would’ve either had to encrypt the key in blocks, or I would’ve had to encrypt the entire pad every time a chunk from the pad was used and needed to be overwritten.

Of course given the key exfiltration security, symmetric encryption wasn’t such a major weak link I might have just as well used symmetric crypto. I went with symmetric because the Post-Snowden paranoia of what to trust and what to not trust settled a bit and I learned a lot about cryptography and that you can trust 256-bit symmetric crypto without too many reservations: attacks lie elsewhere.

So I have to confess I couldn’t follow your story with the “local Destination Computer”, a sketch might help, but now we are back at the issue to discuss in a security forum.

A sketch is worthless if you don’t bother taking a look at the existing 3D renders I’ve made for the wiki that explain HW layout, key exchanges etc complexity graphically 😉 Furthermore, most of what you wondered were discussed in the wiki which is quite structured. Judging by your emails, you have read at least a part of it, so what’s going on here? I don’t have time to repeat myself — I quoted the wiki only this time to make my point clear: a lot of the the information is there. I’d rather spend my time working on that wiki — to add what isn’t there, to make it more readable, and eventually to make it useful for everyone here, and even to the novice end-user. If you’re not familiar with Python that’s OK, the wiki has barely any code in it.

maqp • February 19, 2018 6:20 AM

@65535

@Sancho_P was the one who picked the components and created the original schematics. My modifications are only minor, I just added a second optocoupler making one of the three FT232R adapters able to both send (to Destination Computer) and to receive (from Source Computer).

I don’t think @Sancho_P is questioning the project, just that it’s not immediately clear why some things are done the way they are.

This project has been an exceptional challenge to explain. Some people just want to know how it works, they’re fine with the 10,000 feet picture. Others immediately raise eye-brows and question why it’s done like that, which is great, because that means they want to understand the design rationale. At that point you have to bore into the details, but that will make the 10k feet people’s eyes hurt. And once you’ve explained the details, some will understand, others will ask/suggest doing otherwise, and then you have to further explain why alternatives are not good.

I think I managed to cram all that into the security design section on local key exchange. And in the future I’ll try to expand that on all other topics as well. I recently stumbled upon collapsible markdown so I’ll be able to rewrite each topic with “What? How? Why? Why not do X instead?” style documentation where you can choose the detail to read about it. I think that will satisfy everyone’s needs: It’ll allow you to choose whether you want to increase level of detail after reading about the topic, or after you’ve read the higher level description of the entire project.

HCPL7723 interdiction: This is a problem indeed. But since at no point I’ve been able to provide instructions about how to build data diode with LEDs/photodiodes, I might as well get rid of other problems like the slow baudrate CNY75 optocoupler (I originally used) had.
I do realize 7723 might include more complex logic with it’s DC power supply, but I don’t think CNY75 couldn’t also hide a HW backdoor. There simply isn’t a good fix to this problem. I’ve been thinking about linking to other projects that also use 7723 so that users can mask the purpose until they receive the parts. It’s a tough problem. Another point of failure is ordering the USB-to-serial adapters. OTOH those are less specific components and stocked by more local HW stores.

One good thing here is the HCPL7723 uses DC through and throgh, so you could replace the jump wiring with standard diodes to force the direction of current flow. Since TTL voltages are not AC but DC, it’s possible to enforce current flow direction, meaning Rx-pin of Destination Computer can’t send current to the optocoupler, which in turn can’t send current to Tx-pin of Networked Computer.

Do you have a way of getting them individually and in-expensively?

You should ask the local HW store to stock them, and advertise them as an easy way to protect SoCs from over-voltage when working on GPIO projects. People buy more boards for more projects when they succeed, not when they fry the first and get the jitters.

“Is there a way to build it with out the use of a soldering iron? “

The bread board model doesn’t require any kind of soldering. (The USB-to-TTL adapter does but you can order models where the adapter is baked into the USB connector, and instead of pins, you have wires that you can just (strip and) pluck into the bread board.) So you can build it without ever touching soldering iron, so no, there’s no need for local expert.

I’m using cheap netbooks for the project. Those still come with standard removable mini PCIe network cards. The SoCs like RPi come with integrated wireless so I’ve put those aside for now. If you’re willing to donate me a beaglebone, I can look into creating a configuration for that. This project doesn’t have any funding, everything has come from my own pocket so it’s natural HW support isn’t broad.

It’s hard to give recommendations to what specific laptops you buy, but if it runs Ubuntu 17.10 and allows you to remove wireless interfaces, webcams, mics etc. it should be fine.
https://www.amazon.com/Dell-Inspiron-i3162-0003BLU-Laptop-Celeron/dp/B01L8PENTO would probably do as it comes with 32GB flash drive and Ubuntu takes about 10GB. Also, https://www.youtube.com/watch?v=9LrhFq7xh_k shows the wireless card is removable.

“Lastly, could this entire 3 computer setup be done on VMware or Virtualbox?”

Yes it can. Install Ubuntu 17.10 on a virtual machine, and just copy paste the following to terminal

wget https://cs.helsinki.fi/u/oottela/tfc/install.sh && bash install.sh lt

Then enter password when prompted and the installation takes care of itself. You don’t need to even try this with three VMs per simulated user. The local testing configuration the command above installs simulates three computers inside multiplexed terminal emulator called Terminator. You need one VM for Alice, another VM for Bob.

maqp • February 20, 2018 5:21 PM

@Sancho_P

None taken, the more to the point the better.

It’s impossible to teach everything in one wiki. I can explain what’s different, provide links to existing material and hope people are able to comprehend the project.

The dedicated energy-gapped computer would either need to run the decryption itself, or it needs an access to some decryption oracle like a smart card that holds the key. Since the easiest way to compromise communication is to display something other than what was decrypted by either the computer itself or by the smartcard, adding anything else doesn’t add security in major way.

“To transfer data from and to this machine via Internet the box would be used.”

So if I’m following you, you’re saying it would be something like
(Energy gappped computer) (inline encryptor/decryptor) (networked computer)
and everything would be encrypted decrypted transparently by some tamper-proof inline-box?

Could you draw me a schematic about devices, their purposes and how unidirectionality works in this case.

“Encryption fail doesn’t always mean tampering, that conclusion would be paranoid.”

When there is separate error checking and correction, the assumption must be adversary has attempted attack. User will receive a warning that “packet from X had invalid MAC”.

“In my opinion it is wrong when the decryption device knows anything.”

Decryption system must by definition have the key, and when it decrypts, it will by definition learn the plaintext. What do you mean?

“Truecrypt got it wrong when it said “wrong key” or something like that, refusing to decrypt (mount) with the wrong key, this is the ideal hint for an attacker.”

No they did not. There will always exist redundancy in plaintext data. E.g. file systems have their own headers. What happens with Truecrypt is, after the key has been derived from password and salt, it will attempt to decrypt and if the resulting plaintext contains ASCII string TRUE in it in known offset, it will conclude decryption was successful.
It’s not easy decryption. You don’t put computational difficulty for ciphertext decryption or plaintext recognition, you put it into the slow hash function used in key derivation. TrueCrypt got it wrong, but the reason was you couldn’t adjust iteration count for PBKDF2.

“No. The device decrypts to it’s best knowledge, only the user (a real person, if that can be achieved) can decide about success or fail.”

That completely ignores known plaintext attacks. XChaCha20 is useless without authentication. This is so basic stuff it’s taught immediately after OTP is used as an example of a cipher: Don’t use OTP, it’s not KPA secure. (Sadly usually teachers leave out that OTP is meant to be used with unconditionally secure authentication).

“TFC has (rightly) a dedicated tamper evident HW for the serial transmission”

There isn’t. There are three ordinary computers with ordinary USB-to-TTL adapters and the assumption user is seeking protection from remote attacks, not physical attacks.

“so what is the talking about pin reassignment?”

Let’s say Networked Computer and Destination Computer are connected to each other using simple wires (photo) (Networked on left).
The theory here is, Networked Computer receives magical NSA malware that does the following.

1. Malware sends itself through serial and data diode to Destination Computer
2. Malware on Destination Computer steals keys
3. Malware on Networked Computer periodically prompts for Destination computer to exfiltrate data. It will then tell the controller of TTL adapter on left to listen to voltage shifts on Tx-pin. If malware on Destination Computer had acquired the keys, it will tell the Destination Computer side TTL-adapter’s controller to output data via Rx-pin. The end result is successful exfiltration of data. As I’ve said, AFAIK it’s impossible to verify the pins on the adapters have more than rule based limitations on capabilities, so the data diode circuit is mandatory. However, the optocoupler might be altered in interdiction so, you probably shouldn’t even trust that, but use simple LED and phototransistor.

“Think of the tamper evident black box, it is yours, until you rely on dubious libraries”

Tamper evident box doesn’t help if the system is possible to compromise remotely. Dubious libraries can be audited and PySerial code doesn’t change between installs as the library’s hash is pinned to installer. If nobody’s able to obtain trustworthy software online, it’s game over for the field of computer security. On a side note, @Bruce had some interesting thoughts on extent of hacking here.

“It does not accept code from that pin, not at boot or later, only data.”

Machine instructions are data. It’s a practical impossibility to check all possible inputs and see whether one initializes covert, malicious functionality. This is a major problem in auditing HW with CISC architecture, there was a talk in BlackHat about this just last year.

“But the RxM is the same as the TxM and it is not until someone popped it open.”

It’s not the same. RxM can be compromised at any point, TxM can’t. Let’s say you used the wire-based data diode on TxM-NH communication. If the TxM-side TTL adapter controller hasn’t been infected to listen on Tx-pin periodically, the Networked Computer probably can’t compromise it later because there’s nothing listening. However, RxM can receive data that might be interpreted as commands by malware at some lower level my SW never sees, so there’s a chance NSA could reprogram RxM side hardware remotely at will.

“Um, are you hinting at some irregularities?”

No. There’s no need to worry about this as EU/Finland doesn’t have a concept of national security letters / national security requests. There are no backdoors or any malicious functionality.

“The example you’ve linked to is funny, CD4050 completely obsolete, free of function.”

My point was merely, that while you could achieve unidirectional serial communication via things like a buffer, there’s equal amount of inconvenience yet less assurance compared to optocouplers. I should learn more about the HW but I only have so many hours in day. All in due time.

“Airgapped (energygapped) computer running PGP is a very bad idea, it’s never tamperproof and nearly fully open to the world because of mandatory updates”

Agreed. Even if you don’t update it, you’re constantly exchanging data with the network because communication with it requires bidirectional connection to network. If you see this, you understand why you need to split TCB into Source and Destination Computer. It is my understanding you disagreed on this matter, is it still the case? If, why?

“I’m sitting on the horse viewing at it’s back, so I can’t see where it goes to”

Have you tried running the local test version with data diode simulator to see how it all works? Have you seen this older video about local testing simulation. Things have changed quite a bit after that but you should be able to grasp on the idea.

maqp • February 21, 2018 11:47 PM

@65535:

Maybe. Using the VMs method seems to exclude the optocoupler/Datadiode. I am correct in this assumption?

Yes. If the animation isn’t enough for you, you’re going to need the full setup or attempt bridging the serial adapters yourself. I don’t see why that couldn’t be done though so give it a try if you have adapter(s) lying around. If it doesn’t work, try the standard installation with some old HW.

I’ll try to modify the experimental version enough you can manually define three interfaces and applications running on same computer. That way you can pass data through data diode, and you can run the contact using another computer and set of data diodes, or inside VM with the local testing version that emulates data diodes.

maqp • February 22, 2018 4:32 PM

@AtAMall:

Any networked device can be taken over by a nation state to remove whatever application sits on that. However, Roger Dingledine made an interesting point in his talk:

Anonymous updates is an awesome concept. Imagine downloading the next Debian Update, and attacker’s like ‘That’s the target, let’s give him the exploit’. Through Tor, it’s a bunch of anonymous people doing anonymous updates. They can’t target because there’s nothing recognizable about them.

If all TFC users are unrecognizable when observing the Networked Computer running Tails, it’s hard to know which user to do DoS attack on. All they can see is some random Onion Service connecting to other random Onion Services, exchanging public keys and ciphertexts. It’s much better than e.g. Ricochet where despite end-to-end encryption and anonymity, observing the Networked Computer reveals content that can deanonymize the user. If anonymity is the goal, it’s vital to use Tails on dedicated Networked computer, not OSX on everyday machine.

maqp • February 22, 2018 6:25 PM

@AtAMall:

“Perhaps everybody who can should run a Tor relay.”

This is true. However, you should not run relay on same computer that’s running Onion Service, that is the Networked computer TFC runs on.

If you can, run a relay separately. That not only helps TFC and it benefits every other project too: Tor, Tor Browser, Ricochet, OnionShare, Tor Messenger etc.

Running exit nodes on network you own might or might not be a problem. So check your local laws and consider notifying LEA about it and the implications beforehand. I’m not aware of any place where running a relay node is illegal or problematic.

“I am too lazy to remove the HDD before surfing the web”

In such scenario I think I’d use FDE on that HDD. Although I would assume you’ve done that already.

As for the question on Apple store, I don’t have an answer for you.

maqp • February 22, 2018 9:35 PM

“You start citing from my point–”

You really need to provide me with the sketch and role description, sort of the equivalent of Security Design wiki article. It’s impossible for me to read between the lines what properties you expect your energy-gapped computer to have.

Please do not use hints like The Chinese. The connotations including what threat a country is, is not global. Be specific about what you mean.

“if this device is found as your property you are lost!”

Again, TFC rules out physical attacks including being hanged for being in possession of TFC in some autocratic nation. Creating a system small enough to be concealed is a task for someone more experienced.

“What is your take on that?”

Please also watch the pronouns. I’m not sure whether “that” refers to workhorse computer you describe in the sentence above, or TFC’s split TCB. If you were talking about TFC, under it’s threat model, it is secure. If you want to impose different threat model like “TFC should be physically secure and come in form of tamper proof HW”, please make that clear and then we can discuss if an easy to setup, cost-effective, tamper-proof hardware is a possibility.

“I don’t like when your reply isn’t to the point but changes the direction, sorry.”

I don’t intentionally try to change direction, but many times I don’t understand what you’re saying, so I try to read your point between the lines and answer the question (as I did above in regard to “that” pronoun when I assumed it was about TFC).

I suggest in all future Friday squid blogs we abandon this meta-discussion completely and continue with making concentrate edits to the project, kind of like you’d be making pull requests. So things like

“I don’t understand this concept, please explain X and Y with layman terms”
“I don’t understand why you assume X”
“X could be expressed better if it said Y”
“X has a typo in it”
“X has a bug in it”

Rule of thumb being, if your point doesn’t require making a quote, it probably isn’t productive. It’s Friday in US soon, so a new blog post is coming. Let’s continue this meta-discussion under this thread until we reach conclusion so it doesn’t take space elsewhere.

“Receive data from RxM when the single data wire ends at RxM’s input HW”

I assume FT232R controller on RxM’s USB-to-Serial adapter can choose what the functionality of Rx-pin is. Sort of like how Raspberry Pi can choose whether GPIO is for input or output. If malware on RxM can reprogram the FT232R to transmit via Rx-pin and the single data wire back to optocoupler, it’s game over.

Reasons I assume this is because it’s near impossible to verify chips are not backdoored or designed/manufactured cheaply at the factory. Also I’m not sure if e.g. Raspberry Pi has hard-coded pin assignments for UART, or if the are kind of like GPIO where it can be changed at will.

“Make the FT232 (USB adapter) to read from it’s output, the txd pin?”

FT232R controller of USB-to-serial adapter that connects to NH can be reprogrammed by adversary that has taken control of NH. Optocoupler doesn’t have to compromise NH.

“Where would the code in RxM come from to send keys to NH?”

From adversary who has compromised NH, and that sends it from NH through data diode.

So let me try to write this open:

If it’s not possible to reprogram the pin layout of USB-to-Serial, and if the galvanic connections can not be turned into covert side channel that malware can use to emit keys, then a single data wire is a secure data diode design. In any other scenario we need the optical gap. I’ll illustrate this with detailed example

1. User buys USB-to-Serial adapters from local hardware store. They are cheaply made, and their Tx/Rx pins can be re-programmed for opposite function by the computer the adapter is plugged into.
2. User boots up TFC.
3. NSA remotely inserts malware into NH.
4. Malware on NH sends other piece of malware to RxM. This succeeds because any optocoupler (backdoored or not) allows traffic flow to this direction by design: RxM must be able to receive messages from network. The Malware compromises RxM with a series of low-level machine instructions, and the less privileged software like PySerial or TFC never see this malicious packet.

5. User performs local key delivery. Malware on RxM copies the local key from RAM when it’s decrypted by Receiver Program (the key decryption key is manually typed by user).

Without boring into details, if this local key leaks from RxM, security of TFC falls like a deck of cards. This must be prevented.

1. Malware on RxM re-programs the USB-to-Serial adapter’s FT232R via USB, so malware can send via Rx-pin towards NH at will.

2. Malware on NH re-programs the USB-to-Serial adapter’s FT232R via USB, and adds read functionality to Tx-pin so it can receive from RxM at will.

Now at this point we can evaluate how exfiltration happens on data diode design

Scenario a) NH sends secret optocoupler CPU wakeup instruction and waits for data on Tx-pin. The CPU wakeup instruction makes it all the way to RxM. Malware detects the instruction and sends local key to NH via Rx-pin. Game over.

Scenario b) User orders HCPL7723 that is interdicted. The unit user receives comes with a covert CPU. Malware on NH wakes up the CPU with the secret instruction and waits for data on Tx-pin. CPU on optocoupler forwards the instruction to RxM and waits for incoming data from RxM. Malware on RxM receives the instruction, and sends the key via Rx-pin to optocoupler. Optocoupler forwards the key NH that’s listening on Tx-pin. Game over.

Scenario c) User was lucky and their HCPL7723 was not backdoored: Despite badly designed FT232Rs, the optocoupler protects from exfiltration. Whether or not users should risk getting a backdoored chip, is up for a debate. Would e.g. risk-averse NSA try that?

Scenario d) User used simple components (LED and phototransistor) in place of optocoupler: since it’s a practical impossibility to hide a backdoor in them, there is much more assurance but less speed. Should TFC make the trade-off with convenience over security is also up for a debate.

So the bit bang serial vs UART is completely new to me. I’m glad I’m learning. I’d love to hear more about it. So I could rephrase, “My concern is something like bit bang inside poorly design serial interfaces that allows remapping.”

As for FT232R, this page says “In addition, asynchronous and synchronous bit bang interface modes are available.” So I’m not entirely convinced even good controllers could not be changed to slow speed bit bang mode for the duration of exfiltration. For Raspberry Pi, things look better, but then again, the integrated wireless is an issue. So if Beaglebone comes with dedicated UART pins, that’s a decent start for a TFC SoC project. However, I don’t think it’s worth the risk, considering how cheap the data diode is.

maqp • February 23, 2018 2:51 PM

@ Clive Robinson

This looks like a decent USB adapter for S/PDIF sender.

Alternatively, cheap sound cards seem to have TOSLINK IN and OUT, although for laptops a USB sound card with S/PIDF input should be sought. I did a quick search but didn’t find one.

This could be a functional COTS solution if it’s possible to write raw bytes through the sound cards. It’s much more robust than the daisy-chained Ethernet-to-Fiber data didoe I constructed years ago: with FEC the $100 system had about 10Mbps of reliable throughput. 125Mbps is a big improvement.

The inconspicuousness of the HW is a huge benefit as well. As for designing my own, I’m not an EE. I would imagine this requires a USB controller that talks to the TOSLINK connector, with possibly another IC between those two. What do you think?

“Where possible “bit banging serial” should be avoided due to the overhead.”

Agreed. The context here was malware would add that feature, and thus provide covert half-duplex exfiltration channel where UART chip bit bangs via Rx-pin.

“There are two basic ways to do bit banging which is just basically changing or checking a hardware status line bassed on time.”

Could SW based line status checking with fast CPU allow covert reception of additional data via spurious pulses the normal bit banging UART receiver ignores? (Again, I’m assuming user doesn’t realize their USB-to-Serial has been changed to bit banging mode)

“That said it’s done on the Raspberry Pi 3 for the serial port as the serial hardware in the Broadcom Chip is being used to do Bluetooth instead.”

Yet another issue for RPi3, not as bad as the wireless but still.

maqp • February 23, 2018 10:50 PM

@Sancho_P

“For the WiFi and Bluetooth, you can disable it, and I’d suggest not to only trust but also (RF) test it’s off.”

If Destination Computer can receive malware, that malware can covertly switch the Wifi on for the duration of exfiltration.

“but at first it’s purpose is to break the triple dangerous GND supply path (first for unintended damage, second for data corruption, third for data leaking).”

I’ll have to read through the specs. However, there probably isn’t discussion on topics such as “this is how we made sure nation state can’t reprogram TxD/RxD purpose although we didn’t include API for user to do that, like we did with CBUS/DBUS”. So what it’s meant to do is different from what it could do. You’d need to review the firmware and VLSI masks to have proof on the fact it can’t be compromised: Specs aren’t enough.

If the single wire data diode design is secure, why do you think there’s a chance that data might leak?

I’ll reply more in depth after I get some sleep.

maqp • March 3, 2018 5:14 AM

@Sancho_P

“My take is, some malware has to be already installed on RxM from the very beginning”

But that’s kind of pointless. If you’re going to target some system, pre-compromise the TxM. That computer can output keys at any point.

I’ll try different approach to justify my detail-agnostic reasoning:

The difference between vulnerability and backdoor is whether the weakness was placed into the system intentionally. The difference between infected and clean system is whether the system has malware that actively tries to steal keys. You can insert malware through vulnerability and a backdoor. RxM probably doesn’t have backdoors, but I must assume it will always have a vulnerability that allows malware insertion via serial. This malware can then perform arbitrary commands.

It’s hard to argue about whether or not my assumption has basis over specs. While yes, you can sometimes spot vulnerabilities by reading specs specs (e.g. “this chip uses bit banging by default”), that doesn’t mean chips with non-bit banging UART are not reprogrammable. This can only be proven/disproven with VLSI masks, but since thats not a possibility, I should just assume it’s vulnerable.

So to be more clear: I have interest in hearing and speculating how attack can be done / prevented, but I don’t want to ignore the potential vulnerability just because I don’t have the resources to prove it exists, especially when I have the resources (cheap data diode) to prevent compromise in case it does exist.

One argument for the possibility of hidden feature is chips often don’t do what they could and manufacturers aren’t advertising the fact they have put restrictions on them. E.g. Intel puts restrictions to create artificial differentiation between their chips, so that they can sell the same chip to different customers with different features for different price.

“Better would have been “information”, like clock frequency, load (activity)”

Ah so this is why you think data diode is needed. I agree. Common grounds etc can form a side channel that leaks information.

So would “Data diode prevents simple and differential power analysis attacks via shared wiring. It also guarantees serial interfaces (e.g. vulnerable UART design and cheap ones that resort in bit banging) can not remap pins to form covert return channels.” be a better way to justify using the data diode?

@65535:

Sad to hear that. Get well soon!