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.

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.

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.

> 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...

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.

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.

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.

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.

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.

(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 lick them it'd be quite unpleasant but that's that.

Voltage below (roughly) 36 are safe.

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.

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).

o/

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.

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/

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.

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

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.

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.

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.)

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.

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

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.

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.

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.

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)

This one is going back to Amazon.

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

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

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.

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.)

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...

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.

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.

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.

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.

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

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).

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.

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

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.

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.

(Besides, how do you see this working? 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.

But I like your suggestions for pairing.

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.

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?