Hacker News Reader

Comment by geofft | Hacker News Reader

This form of "authentication" smells like DRM, especially as they're using it to limit power and they're using Digicert to sign devices. And if you're speaking X.509 or something on both sides I'm intensely curious to see how vulnerable the attack surface is.

The "authentication" that would actually help is to default to only allowing charging through ports (and allow charging without authentication - who cares where I get 65 W of power from? are there malicious electrons?), and show a little "new device" authentication screen with a Bluetooth-style pairing process when I connect something new. Then either burn an asymmetric key onto the device or generate a random symmetric key (and leave the CAs out of it), and on the host, bind the key to the current function of the device, as displayed on the pairing screen. If I clicked "Trust this keyboard," don't let it turn into a CD drive. If I clicked "Trust these headphones," don't let it turn into a keyboard. And so forth.

View on HN

Exactly. If it's a wired connection requiring physical access what is being protected? For the benefit of which party?

I do want to be able to plug into public USB PD outlets, other people's chargers, etc. confidently, and there is a legitimate security problem there. Even though it's wired and physically adjacent it isn't necessarily trusted. But that can be done without DRM.

Even with some kind of authentication that doesn't change the fact that public USB outlets can still be rigged to fry your machine. The likelihood of it is probably incredibly small but I personally still wouldn't use public USB outlets.

I can trust a public outlet to not fry my phone. That is simple, if my phone stays functional I'm good, and if it gets fried I take some real world measures (go to small causes court, make a denounce to some government agency) to get compensation.

The real problem on public outlets is with data attacks, not power. If I can set my phone to ignore all the data at the first hardware level, and it is a simple enough level that no attack is viable (that second one being a large "if"), then there is no large problem anymore.

> That is simple, if my phone stays functional I'm good, and if it gets fried I take some real world measures (go to small causes court, make a denounce to some government agency) to get compensation.

This is much easier said than done (in the US at least.)

First, you'd be looking at at least a year of going back and forth in small claims court and by the end of it still have no guarantee of winning. Even if you did win, there's no guarantee the judge would award you the full amount to pay for your fried device.

It almost certainly would not pay your time at the courthouse though; you can ask the judge for punitive but you cannot include legal expenses in small claims court demands.

In the end you would still be out hundreds or thousands of dollars and numerous hours of your time. That's why to me the tiny benefit of using a public USB outlet is just not remotely worth the risk of such a nightmarish hassle.

This is the same thing as just plugging into a regular power outlet. You don't know if the thing you're expecting to provide 110v is actually giving you 10,000v.

Then again if things were really bad or malicious you could end up losing your life like Sheryl Aldeguer.

My old no-name Android phone (not USB C) has such an option, and searching around it seems to be a reasonably common feature, although not present on all devices. It looks similar to this (mine has the same typo, "USB fuctions"):

https://farm8.staticflickr.com/7485/16035739946_51d110ea40.j...

In charge-only mode it doesn't even enumerate as a USB device when plugged into a computer with an active USB controller, so I suspect no attacks (besides physical ones like overvolting as others here have mentioned) are possible in this mode --- the USB controller on the device is completely disabled.

>> If I can set my phone to ignore all the data at the first hardware level, and it is a simple enough level that no attack is viable (that second one being a large "if"), then there is no large problem anymore.

> My old no-name Android phone (not USB C) has such an option, and searching around it seems to be a reasonably common feature, although not present on all devices.

I use one of these. The nice thing about the newer versions is that you can verify the impossibility of a data connection through easy physical inspection.

https://www.amazon.com/PortaPow-3rd-Data-Blocker-Pack/dp/B00...

The problem with that is you also block the pins needed to negotiate power delivery over USB C, so you're limited to 10 W (5 V * 2 A). Laptops that use USB C for charging use C and not micro-B precisely because they need more power than that.

The generic (unofficial?) name for such a device is a USB condom.

Isn't that the wrong direction? My concern is not so much that my phone will show up to an attacker as a storage device, which can generally be restricted or be set to require pairing - my concern is that the attacker will show up to my phone (or laptop) as an accessory, in particular as a keyboard and mouse and perhaps an external display, at which point they can click through any permission or pairing prompts the OS might try to show.

Definitely!

If my Moto G5+ is locked then it seems that plugging in a keyboard behaves pretty much like plugging a keyboard into a desktop or laptop computer except that it doesn't respond to c-a-del.

I can unlock from the external keyboard by pressing the windows key and then typing my pin number but the multimedia keys and print screen on the keyboard work even with the screen locked.

I would rather that it didn't do any of that until I give permission on the mobile itself.

Power-only USB cables offer good data protection, or just set your device in such a mode.

No such devices exist with USB Power Delivery support, I believe. (I believe you cannot make a passive adapter as you could for 5V, 2A-or-less plain USB A/B power connections; you have to speak the USB protocol and register as a device before you can switch to more than 5V or draw more than 2A. And plenty of people want more than 10W power.)

I also don't believe any OSes offer a mode where they negotiate power delivery and not data, though I'd love to be wrong - that would be 90% of my proposal. It wouldn't let you authenticate individual devices, but it would let you go back to having a single port that's just a charging port.

> you have to speak the USB protocol and register as a device before you can switch to more than 5V or draw more than 2A.

It depends on which "USB protocol" you're talking about. With USB-C, there are five separate data buses on the plug, each running its own protocol. There is the traditional USB 2.0 bus (half-duplex differential pair), a pair of differential dual simplex buses (normally USB 3.0/3.1/3.2, can also be used for alternate protocols like DisplayPort), a pair of sideband wires (used only by alternate protocols), and the Configuration Channel. All configuration of the other data buses and of the main power bus is done through the Configuration Channel, in simple cases through resistor values, in more complex cases through the USB-PD protocol.

So yeah, you have to speak the "USB protocol" to switch to more than 5V or more than 3A, but the "USB protocol" you have to speak is not the traditional USB 2.0 or USB 3.x protocol, but instead the completely separate USB-PD protocol, which runs on its own dedicated set of wires. I doubt you can show up as a pen drive full of malware through the USB-PD protocol, but I don't doubt that cutting the other buses (keeping only the Configuration Channel/VCONN and the main power bus) will still work to deliver power, even at higher voltages and/or currents.

The reason this isn't standardized (as far as I know, a "charging-only" plug is only allowed as a captive cable on a non-charger) is for compatibility: if your device doesn't understand USB-PD, it might not charge at a full speed unless it sees a short on the USB 2.0 bus (Battery Charging specification), and doing that short on an adapter would allow a device to draw too much power from a non-charger.

You can buy type c condoms that do all the negotiation but block data to and from the cable.

Do you have a link to such an item? All I have found is devices that lower you to USB A-style 10 W charging.

18V, 5A would be a shock hazard.

DC voltages below 50 V are considered "safe" in normal indoor conditions. It's often referred to as "extra low voltage", as opposed to "low voltage" (50 V - 1000 V) and "high voltage" ( > 1000 V).

If you want to verify the safety of 18 V: ever touch both poles of a 9V battery with your fingers? You can't feel anything. Go ahead and try two in series, you still won't feel it.

Really? I can feel 4 volts between my finger and thumb. Isn't painful or anything, but I can tell when a lipo battery is charged vs. discharged.

You can feel lower voltages if you fingers are injured, or if you... lick them.

As kids (6-9y) we used to test the voltages of 3R12 (4.5v) by touching the poles with tongue, a sharp bites - the battery was good.

Yes, here is a good video about this: https://www.youtube.com/watch?v=ZxBF7WC0TQk

That's roughly the voltage that laptop AC adapters output, and they do so continuously without needing any special negotiation/signaling.

(Even those from manufacturers that try to lock this down using an EEPROM, e.g. Dell, still output their voltage like the others, but the laptop might not want to charge from an "unofficial" power source.)

If you stick it in your mouth or something, maybe. Or if you're soaking wet and have a terrible heart. Otherwise, nobody's getting hurt off 18v.

Laptops tend to be 19V and you can hold them with both hands wet w/o any risk (it's DC, so even better).

If you lick them it'd be quite unpleasant but that's that.

Voltage below (roughly) 36 are safe.

No. Skin resistance is at least around 100k Ohm at that voltage.

The shock hazard is the 5A, not necessarily the 18V.

Well, no. If 5A flows through you from hand-to-hand, sustained for longer than an instant, you're probably dead. But I've touched live power supply terminals for something rated for 20A without a second thought.

And if there's a 10kV differential between your left and your right hand, sustained for longer than an instant... You're probably dead. But I've touched a 10kV power supply (not on purpose, this one), and...still here.

So! What gives?

Well. Place a 0.1 ohm resistor across that power supply. 18V across 0.1 ohms will produce a current of 180A. This will dissipate more than 3kW in the resistor, and it will very rapidly disassemble itself. But that doesn't happen!

Okay, now put a 10 megaohm resistor across that power supply. It's 5A, right? So 5A across 1 megaohm will produce a voltage of 5000kV. This will dissipate 25 megawatts, and destroy the resistor even faster. This also doesn't happen!

In fact, what will happen in the first case is that 5A, not 180A flows (assuming the PSU doesn't detect the apparent short and shut down entirely.). But Ohm's law says that if 18V is placed across a 0.1 ohm resistor, 180A must flow!

Ah, but 18V isn't placed across the resistor. Instead, as current draw approaches the 5A limit, the power supply starts dropping the voltage. No more than 5A will flow, even if that means the voltage must be decreased.

And 5A won't flow through the 1 megaohm resistor, either. Instead, no more than 18V will be placed across the load, even if that means the current must decrease.

So, the power supply won't kill you UNLESS your skin resistance is low enough that 18V causes a lethal (very roughly roughly 1A) current to flow through you. Luckily, humans have a fairly high skin resistance, at least when we're dry, and 18V is fine.

It's not the volts that kill you, it's the amps which the volts are directly related to. 10kV across your body, sustained for a bit, will kill you dead, modulo some sort of miracle. 10kV at 1mA across your body ... is impossible. If you touch a 10kV, 1mA supply- the voltage will drop so that only 1mA flows.

It's not the voltage limit on the power supply that kills you. It's not the current limit on the power supply that kills you. Both need to be high enough to do you in.

Extremely interesting explanation. Thank you man.

I would like to peruse your electronic skills for another quite unrelated question that has been hovering my head for quite a while.

I know that normal USB (1,2) devices charge using the provided 5V rail off the USB connection. And I've read somewhere else that coming from a PC motherboard or other regulated (standardized) USB outlet, the port will provide about 500mA.

What would happen if i took a ATX PSU and rigged usb ports directly (at the correct power pins) to the psu's 5V rails?

Would I fry any devices plugged in? Or..

Would any plugged devices limit their intake and I'd be left with a 'super quick charger' which can charge any device at the maximum amount of power that the device can receive power? those 5V rails usually output at 30A+ and stuff.

thank you again, and hope you can shed some light into this long doubt of mine (I always 'dreamed' of creating some atx-frankstein psu which i could use for electronic experiments but also fit some usb ports in it).

EE/CE here: In order if your questions...

1. Assuming you hooked the 5V to the USB 5V and the GND to the USB GND pins, nothing bad would happen.

2. Nothing would get fried

3. Plugged in devices would respond according to how they're designed. Most cell phones will limit current and only draw 500mA if they don't have any other signalling to test otherwise. Some will slowly ramp current until their own internal limits if voltage drop isn't too bad. Some 'dumb' devices will pull as much current as they 'want' or need. You won't be able to push 30A into any device because there are almost no USB devices that 'want' that much current. Even really poor behaving devices (outside of outright broken ones) will probably only draw 3-5A max. Technically this is non-compliant, since there are defined USB specifications for how USB ports should be connected.

If you wanted to make a 5V 'mega USB' charger, here's all you'd need to do: Take your 5V, many amp power supply and connect all USB-A ports you want to it, with a constraint that number of USB ports should be total amperage divided by 2.5. E.g. if you had a 10A supply, only use 4 USB ports. Short the D+ and D- pins together on the connector. 5V should be connected to your large 5V rail, GND should be connected to ground.

That's it. You've just made a 'DCP' (Dedicated charging port) device. By USB standards any device connected can pull up to 1.5A; in practice they'll usually pull 2.1A or more if they can.

THANK YOU! that's what i needed to know.

knowing shit about electronics, i was worried there would be 'too much current' and that i could fry something :-)

have a good one, man o/

Don't we have technologies for that like fuses?

In particular, people seem to use untrusted AC power outlets all the time without their devices being fried. The motivations of an attacker who wants to fry devices (mere lulz) and the motivation of an attacker who wants to break into working devices silently are very different; it makes sense to expect more of the latter, and to define the latter and not the former as within your threat model.

A fuse protects against overcurrent. It does nothing against overvoltage, or worse, reverse polarity (which was what fried Benson Leung's device). USB-C has a maximum of 20V, and that's only when negotiated by both devices; many devices will only expect 5V. If an untrusted low-quality power supply fails, it can put the full line voltage (alternating from -110V to 110V or more) into the USB cable. Protecting against that would add a lot of bulk and cost to a device. AC powered devices, on the other hand, already have to deal with the full line voltage (which includes negative voltages) all the time, so there's no extra cost for them.

The solution I use and many others is to only charge a usb battery in public, and you use that battery to charge your devices.

That works well to solve all the issues with public power ports.

Fuses and input protection in general can't save your device from a malicious attacker connecting say a powerful taser into a usb port.

I mean, they also can't solve a malicious attacker connecting a powerful taser above a USB port and trying to maim whoever uses the port. What's your threat model again?

Obviously. I mean that you can't protect the device from malicious power and usb outlets. And for non-malicious things the device should already have input protection, otherwise it's unsafe to use if it doesn't when plugged in and unsafe leaving it plugged in unattended (you can die from electrocution or it can cause fire).

Is this a real problem or a razors in apples problem?

A real problem for some is that standardizing power adapters interferes with the sale of original manufacturers' adapters. The authentication mechanism looks to be designed to fix this revenue leak.

Why would anyone do that? If you just want to vandalize things and have the physical access necessary to install a USB outlet, there are much easier ways to do that. Data attacks are much more realistic because the attacker can gain something beyond just causing destruction.

> that doesn't change the fact that public USB outlets can still be rigged to fry your machine.

That is true, but not something that I'm overly fussed about. I'd much rather have my USB port fried than to suffer an intrusion.

I am also suspicious of public usb charging ports. That's why I prefer to use my AC power adapter. Not only do I make sure to get full USB-C power capacity, I know nobody can hack my phone because the AC port has no data channel.

I don't know squat about USB C (I don't have any equipment that uses it yet), but with A & B, my solution to this problem is simple -- I use charging-only cables that don't pass the data lines through.

USB C has a power delivery spec that permits increasing voltage above 5V; in order to do that you need to negotiate what each side (and the cable, too, I think) supports before increasing voltage. That's how laptops that use much more than 10 W can use USB C as their charging port.

But that's only for high voltage charging, right? You can still get 5V without negotiation, if I understand correctly. If so, that's a tradeoff I would be perfectly fine with.

USB-C is being used to power things where 5V is not remotely sufficient. So while for some devices (cell phones, largely) 5V is a plausible tradeoff, I don't really see a world where many MacBook / Chromebook / etc users opt for 5V max charging power.

Fair enough, but I was really just talking about safety when using public charging points, which implies smaller devices. Also, I was really talking about what I find acceptable. Other people's mileage may vary.

Yeah, but BigCo can't charge you $20 for that no-data-passthrough cable.

Doesn't USB require the data connection to allow it to negotiate higher than the base power level?

How?

As described in my comment above: enable power delivery without data delivery by default.

Counterfeit and/or unsafe USB power delivery cables are a fire hazard today, whether or not a data channel is negotiated. How does disabling data delivery improve the safety of a PD-only USB connection over a physically unsafe cable?

This crypto-signature approach is already used by the Apple MFi program, which has made it difficult-to-impossible to sell counterfeit and/or unsafe Lightning devices.

I think we have completely unrelated threat models. I'm worried about malicious USB ports / devices trying to steal my data or at least make me have a bad day. If someone is trying to set a device on fire, authentication won't help. They just need to fail authentication and use that as the bomb's trigger.

You're worried, I think, about poor-quality devices that aren't malicious, just incompetent - or poor-quality cables. (I'm already willing to carry my own cable - I already carry a USB-A data blocker around, but USB-C data blockers don't seem to exist.) I think that can be solved without cryptographic authentication, with the standard approach of having a certification organization like UL or the USB-IF themselves investigate cable/charger production and test them. It seems the major problem here is with Amazon listing cables without showing whether they have certifications (or checking whether certifications are forged), and that's a general Amazon problem with poor-quality hardware and counterfeits.

This article is talking about autorun, Stuxnet, etc. so I think they're focusing on the latter. If the USB-IF wanted to use digital signatures to authenticate cables I'd be more on board, but if they do that, they should just be authenticating cables, not devices. (A cable, I believe, can be engineered to just cut the circuits if a device tries to pass too much voltage, or is wired backwards, or something.)

> USB-C data blockers don't seem to exist.

They do -- I carry one one of my employees made in our lab. Search for "usb-c condom" or "usb-c data blocker" and you will find several offered for sale.

The ones I've seen work by severing all of the data pins, limiting you to the old 5 V * 2 A limit. Have you seen any data blockeds that support the power delivery spec and are suitable for devices that need over 10 W (larger laptops, the Switch, etc.)?

I have one that negotiates power delivery on both ends. But I don’t believe it was manufactured commercially — it’s just a bare board with no housing. I’ll ask the guy who made it if he’d publish the design files.

There’s a whole spectrum of bad actors.

Incompetence is scarier than malicious actors imo, and expecting users to carry USB condoms around seems like a bad idea.

I assume USB-IF wants all uses of the word USB with respect to any hardware - including cables - to be backed by a DigiCert signature, and all other uses to be rejected by non-developer-mode devices so their enforcement success rate improves versus generic knockoffs that can’t easily be sued.

difficult-to-impossible

Apparently not according to the Chinese, who made the first clone (based on an 8051 microcontroller IIRC) within months of the official release. They're still in an ongoing cat-and-mouse game with Apple.

Difficult-or-impossible to bring to market for sale to all iPhone users worldwide, not difficult to reverse engineer on a bench.

By controlling issuance of permission to use the connector, Apple is able to prohibit non-compliant products from becoming widespread worldwide. (And even China just last month declared their intent to make IP enforcement viable, which further strengthens Apple’s position with respect to MFi.)

The USB folks appear to believe that if they introduce a similar licensing arrangement for USB, they’ll be able to refuse licenses to unsafe implementations to deny them access to the worldwide USB market. MFi still works today, so I certainly don’t blame them for trying.

That means they don't need cryptography for this, right?

That is not a meaning I would have derived from my reply. You’re welcome to construct a scenario explaining what you mean, but the question alone offers no guidance on what you’re thinking to permit me to construct a reply.

You've argued that legal protections, including China's stronger IP stance, means that USB-IF can be confident about cracking down on counterfeiting, and that it doesn't matter that the connector is east to reverse-engineer. If so, how is a cryptographic authentication scheme as described in the article (including authentication of devices, not just connectors and cables) relevant, let alone useful? How does it help anti-counterfeiting and why are the legal mechanisms by themselves insufficient?

I'm not planning to follow up further on this thread, sorry. If you are able to define an anti-counterfeiting mechanism that does not depend on cryptographic signatures, you could probably corner a billion dollar market. I encourage doing so, but have no further assistance to offer you.

Hopefully the computer it's getting plugged into. Considering how viruses apparently spread through USB sticks, some protection is clearly a good idea.

No idea if that's what this system does, though. Ultimately it has to be the computer itself that knows to protect itself. If insecure USB-C also exists, having the possibility of security may not be good enough.

It is for the benefit of the user in not catching fire

Given the number of crappy USBPD implementations out there, it would be nice if some sort of counterfeit-resistant validation program existed. That said, I would still like the option to trust/use an "insecure" device.

Get a USBC voltmeter dongle from amazon. Best $20 I've spend:

https://www.amazon.com/gp/product/B01NAWYSVK

UPDATE: actually, no, the displays is upside down on one of my devices! Duh! A cheap gyroscope would help, or another OLED screen on the back but in the opposite direction (as USBC-cables are reversible)

If you spend a bit more, you can find ones that will trigger USB-PD without you having to plug a device in. Will also test the various protocols like Qualcolm's Quick Charge, Huawei's FCP, Samsung's AFC, etc.

Can I ask which one you recommend? (hopefully readable when you only have USB-C ports on the right handside)

This one is going back to Amazon.

That will tell you the basics, but you will still miss things like transients. Still it gives useful information.

> the displays is upside down on one of my devices!

wait I don't get it. It's USB-C, just flip it over?

The ports are only on the right hand side. The voltmeter screen always display in the same orientation. So if I flip it over, it will display correctly instead of upside down, but only the person sitting in front of me will be able to read it as the display will be facing the back of the screen of the laptop

It is a simple USB-C design oversight from Pluggable that a simple gyroscope or extra screen would have fixed easily.

Try plugging it in to the left side of your computer instead of the right side.

Try buying me a new laptop?

what if you turned both the dongle and your laptop upside down?

>And if you're speaking X.509 or something on both sides I'm intensely curious to see how vulnerable the attack surface is.

Very. ASN.1 vulnerabilities have been exploited multiple times in the wild, in mainstream libraries (like OpenSSL). Now imagine every hardware vendor writes their own shitty implementation and ships it as a blob to phone manufacturers. And that's all without going into the full blown X.509 PKI part of the spec, which adds yet another layer of complexity - all under control of chargers you plug into. Now imagine this is implemented by the kind of companies who wish to perform DRM on what charger you are allowed to use.

This spec is a recipe for disaster and implementing it will seriously reduce the security of devices.

1) There's no practical alternative to X.509 for PKI because the standards, tooling, and libraries simply don't exist and arguably never will given the momentum of X.509. A PKI infrastructure won't even make it out the gate if it can't interoperate with the existing X.509-based CA ecosystem.

2) Historically you never wrote ad hoc parsers. ASN.1 describes a grammar to be consumed by a compiler generator. The X.509 specification and extensions are almost entirely ASN.1 grammars with interspersed commentary. You can feed those grammars directly into the generator, and IIRC I've seen builds where the grammars were extracted directly from the RFCs. OpenSSL and other open source projects suffered from parsing exploits because historically all ASN.1 compiler generators were closed source, commercial products.

I don't disagree that it will likely be ugly. Open source options for properly working with ASN.1 are still poor, and these days even commercial vendors principally rely on open source toolchains. I've used the amazing asn1c which can be fed the official X.509 grammar and spit out a clean, strongly-typed BER, DER, or PER parser. But I've never seen it used by other open source projects. IIRC the mailing-list is mostly chatter from telecommunications contractors.

Bad ASN.1 support doesn't need to be the case. Hand rolling DER parsers is a choice. If we can write good generators for gRPC, we can write them for ASN.1. And from the perspective of C and C++ asn1c largely suffices.[1]

[1] My biggest grip with asn1c is that, IIRC, it still requires dynamic memory for grammars like X.509 with variably sized arrays and strings. It would be nice to see a compiler that supports generating statically sized fields and which simply errors out if an object doesn't fit within the field. Then you could use asn1c for really low-level, embedded firmware, and more importantly could greatly simplify application code traversing the data structures. ASN.1 supports specifying maximum sizes which could be used to size fields (and maybe are in asn1c) but that's a separate thing, and in any event X.509 doesn't make use of this (though I suppose it would be easy to amend the specification, formally or informally.)

EDIT: s/compiler generator/parser generator/. Though, ASN.1 parser generators are also typically compiler generators, I guess, in the sense of generating code to "compile" data structures to the encoded form, which is probably what was going through my head when I muddled the terminology. The benefit of fixed-size, pointer-free structure fields in C is more pronounced when initializing a structure to be serialized.

Can't this be solved in the host OS? USB devices have a vendor and product id (VID, PID) and a device class (HID class [1]). I'm not sure why the operating system couldn't keep track of which ones are authorized. It could also allow whitelisting of certain HID classes (eg "allow all mice"). If the HID changes, it would prompt for authorization again, which would mitigate an entire class of attacks ("BAD USB").

It would still allow someone to bypass the authentication if they know the VID and PID of something already authorized with the desired HID class, but that seems reasonable and is significantly better than what we have today.

Are there any systems that work like this today, and if not, is there a reason?

[1] https://en.m.wikipedia.org/wiki/USB_human_interface_device_c...

That would work somewhat—VID/PID can't be trusted but device class can be. But the problem is that on e.g. my MacBook with a single USB C port, sometimes I want to use a keyboard (either an actual keyboard or a YubiKey) and sometimes I don't (if I'm charging). If I plug in a hub I want to trust my hub but not someone else's device claiming to be a hub. And so forth.

Having a charging-only-by-default port would be a 90% solution, but would be very annoying for people who need to reauthorize a device every time they plug it in, which is why I think pairing is better. And I'm not sure what devices you can reasonably trust other than pure power. HID is definitely out for fear of Rubber Ducky-style attacks. External video adapters can read your screen. Headphones can listen in on calls. Thumbdrives / PTP devices might be safe if handled carefully but are kind of the classic worry, so I'm not sure if people will want those. Maybe pure U2F devices, webcams, and audio input devices? Not sure how useful or user-friendly such a restriction would be.

I guess what I'm picturing is the first time you plug in your keyboard/Yubikey/whatever, your system prompts you "A new device 'AcmeCo USB Keyboard' (VID=xxxx/PID=xxxx) wants to provide service(s): Keyboard Input. Allow? Once/Always/No/Never." After that, your system saves that combination, and assuming you authorized it permanently, whenever you plug in that VID/PID, it has access to be a keyboard.

If it tries to present another HID later, that would result in a new prompt, the same as a brand new device. If it changes HID while plugged in, that could even be a more severe message along the lines of "Hey, this keyboard just tried to become a video adapter and thumb drive, that's really suspicious and you should probably destroy it with fire".

Likewise, VID/PID changing without being unplugged/replugged in, changing too quickly, or even just after too many new VID/PIDs in a short time period should result in a temporary lockdown -- in the same way fail2ban blocks repeated login attempts from a given IP.

What prevents a malicious device from pretending to be a common model of keyboard (say the most common Apple or Dell one)?

Exactly why cryptographic authentication is required. There are fuzzing devices today that present themselves as known VID/PID/HID combinations that have generic drivers in modern OS's and can exploit that.

One of the primary drivers for this is the power delivery - imagine a scenario where you have authentic power brick and laptop and buy a counterfeit USB-PD cable, power brick sends 100W over it and it results in the cable melting since it was really a $5 knock-off and you end up with a fried USB-C port in your laptop and possibly a fire. I'm sure most people would wish that the power-brick/laptop checked that cable is genuine and build to handle the power.

That seems like a very weak failsafe likely to be easily cracked and those bad actors only slowed down a bit - if history is any guide.

Why not implement something like detecting voltage drop between charger and device? Short circuit detection, etc. You can do a lot if you can have both sides communicate with each other, and at that point it matters a whole lot less if your cable lies to you plus you catch a lot of other failure conditions.

Apparently, BC 1.2 spec verbiage suggests this is already a hard requirement:

The OTG device is required to limit the current it draws from the ACA such that VBUS_OTG remains above Vaca_opr min.

There are more use cases where being able to prove cryptographically the identity of the device is very useful from security point of view, PD is simply one of them.

> One of the primary drivers for this is the power delivery - imagine a scenario...

Not a USB engineer, but a quick peek at the BC 1.2 spec suggests the ball would have to be dropped on at least two additional fronts for the suggested failure mode to occur:

1.) The Charging Port device vendor for failing to implement any of the allowed shutdown measures suggested in BC1.2 §4.1.4; and

2.) the Downstream Port device vendor for failing to constrain current draw based on sensed Vaca_opr min = 4.1V (Table V) per ibid. §§6.2.2 and 6.3.1.

I can see how the knock-off cable would be toast, and depending on insulation rating, may potentially catch fire, but struggle to see how either the CP or DP USB-C ports would fry (considering they're both designed for a target power).

USB-PD only raises the limit from 3 amps to 5. It doesn't increase the risk of fire very much at all, even in a counterfeit cable.

How are you going to authorize new HID devices without other currently working and authorized HID devices?

Seems like a response to reality to me. There’s a pretty obvious liability issue to these complex magic plugs that can deliver significant power.

It’s one of those things that makes USB-C really dumb. Any negligent Chinese manufacturer can drop a cable on Amazon that is a hazard.

In solving all problems, USB-C is a problem.

How is that any different from AC->USB adapters before USB-C?

My understanding is that different cables have different capabilities.

I find a wonky cable a higher risk than shitty charging equipment, especially as it may work fine for low power needs.

Before, power according to spec was 2.5 W, with common chargers going up to 10 W or so. USB-PD specifies up to 100 W.

Faulty usb chargers can put line voltage on the charging end anyway, regardless of the spec.

Or, Power over Ethernet. 48 volts at up to ~75 watts.

In other words, basically treat the driver initialized to talk to the client-device the way mobile iOS treats apps: start them off with no capabilities, and then make them ask the OS to prompt in order to get persistent capability tokens granted.

The USB standards body is worried about 'fake' cables which claim to be able to support 1000 amps of current at 1000 volts and then proceed to catch fire...

This authentication is supposed to prove that the cables claims have been tested.

It will undoubtedly help safety and compatibility, at the cost of an open ecosystem and pushing prices up.

Well, as it pertains to power delivery, it seems to me that UL and friends could have their own keys, which they would delegate to manufacturers of certified devices.

I figure the authentication will happen largely in the host software as well, so if you're running a real operating system you'll be able to install your own keys.

Most of the people I love and care about, as well as most of the people who hold my personal data in trust, are not using "real" operating systems in your definition.

(Besides, how do you see this working? Are you manufacturing your own USB devices?)

> Are you manufacturing your own USB devices?

I do (depending on your definition of "manufacturing". I buy USB controller chips to add to my projects), although not USB C.

Now that you bring it up, I do wonder if this authentication scheme will mean that hobbyists won't be able to use it.

I've done a USB device, so yeah I have some stake in this. I suspect there will be CAs and certificates just as with TLS, the question is how costly and time consuming it'll all be.

All my mobile phones ask me when I plug in to USB whether they should do more than just charge so it seems like a non-problem anyway.

But I like your suggestions for pairing.

How about for USB hardware tokens? Would it be a legible case for such authentication.

"and allow charging without authentication - who cares where I get 65 W of power from"

That 65W of power on USB-C is coming in at 20V most likely. Many devices simply will not tolerate that high of a voltage. This is why authentication and negotiation are absolutely essential.

Negotiation, yes. But why authentication? Why do I care from whom the 20 V come as long as it is actually 20 V?

You can fry a regular AC-powered device by giving it 240 V power instead of 120 V, or 50 Hz instead of 60 Hz, or whatever. But we don't need authentication of power outlets. What makes USB different?

I've always wondered if "authentication" is possible on a Quantum Realm.

Reply on news.ycombinator.com