Hacker News new | ask | show | jobs
by justaguyonline 2226 days ago
What would it take to have a Thunderbolt/USB C condom? You know, like those standard USB adapter that just drops the data leads on a usb charger to make attacks like this impossible. Maybe we would have to implement a hardware switch on the device itself?

I'm not going to feel safe charging with a public use charger until I find some way to insure only power and not data is making it to my device. Even POE feels like it's safer than modern peripheral standards right now.

(I admit this might not be perfectly linked to the article, it's just a need I've felt for a while but I can't seem to buy a solution for.)

3 comments

USB power delivery does not use the data lines at all. It negotiates the permissible voltage and current using Vbus pin only. There's no reason why your USB data port needs to be enabled while charging. Just disable it. I actually have a charge-only thunderbolt cable in my desk ... it's incredibly irritating because the only way to tell the difference between it and a real thunderbolt cable is that it doesn't work.
Sounds like exactly what I was looking for, where did you pick it up?
Secops at work distributed them. I have no idea where they came from.
I just bring my own brick for such circumstances. It takes no effort for me to evaluate the security, and it’s more flexible than counting on built in USB ports.
But buses, trains, planes — they all offer a USB socket, not a power socket.
I've long since taken to carrying a USB battery that can charge and provide power at the same time. It's more reliable for me than USB condoms, and, well, it's a battery, which is useful too.
That’s not been my experience, but I’m sure it’s hyper location/company specific.

As another commenter mentioned, I too carry a battery for longer trips, which is useful for charging devices when physically on the move and away from outlets. The model I chose from Anker can also top up a MBP, albeit slowly.

How about a SSH-like “trust on first use” prompt for all data connections? Each USB/TB device has its own pub/private keypair.

If you ever plug in a charging cable and get the prompt, you know something is wrong.

I think Thunderbolt already does something like this? At least on Windows, I'm prompted to trust or not trust a new Thunderbolt device before it can do anything except draw power. (I didn't know that was a feature and kept wondering why my external GPU wasn't showing up...)
That is exactly what TB has. The problem is that the device private key (in many(/all?) devices) sits in the flash memory completely unprotected so anyone can clone it.
It is not like ssh at all. It is a problem that secrets are kept in the flash and it is also a problem that those secrets are sent over the untrusted channel.
The key is transferred only on the initial connection, after that a challenge/response mechanism is used. So from UX point of view it achieves similar TOFU, even if the technical details vary a bit. Sure, its bit worse but it is still very much trust on first use.
After the device is connected, use looks like a key consistency aware system like an ssh client. It is as you note very different in the first protocol run.

To extract the device secret value, an attacker needs to connect the target device to an attacker device. As you note, the thunderbolt device leaks the secret value over the untrusted channel. Impersonation of that device after that moment is trivial as a result.

The entire cryptographic protocol is broken from the start.

> To extract the device secret value, an attacker needs to connect the target device to an attacker device. As you note, the thunderbolt device leaks the secret value over the untrusted channel.

If victin device is connected to attacker host, then only responses to challenges are potentially leaked. That might allow active mitm, but not cloning the key. That's the whole reason TFA needed to go poking around in flash to get the keys.

Not saying that TB is the best security protocol in the universe, but as far as I can tell the vulnerabilities exposed here are mostly implementation flaws rather than protocol level issues.