12 ms·
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
by geofft 8y ago
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.
- Skunkleton 8y agoGiven 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.
- devereaux 8y agoGet a USBC voltmeter dongle from amazon. Best $20 I've spend: https://www.amazon.com/gp/product/B01NAWYSVK 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)
- robotmlg 8y ago> the displays is upside down on one of my devices! wait I don't get it. It's USB-C, just flip it over?
- devereaux 8y agoThe 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.
- Skunkleton 8y agoThat will tell you the basics, but you will still miss things like transients. Still it gives useful information.
- fwip 8y agoTry plugging it in to the left side of your computer instead of the right side.
- devereaux 8y agoTry buying me a new laptop?
- Skunkleton 8y agowhat if you turned both the dongle and your laptop upside down?
- ThatPlayer 8y agoIf 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.
- devereaux 8y agoCan 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.
- microcolonel 8y agoWell, 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.
- geofft 8y agoMost 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?)
- JohnFen 8y ago> 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.
- microcolonel 8y agoI'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.
- karmakaze 8y agoExactly. If it's a wired connection requiring physical access what is being protected? For the benefit of which party?
- geofft 8y agoI 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.
- warent 8y agoEven 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.
- marcosdumay 8y agoI 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.
- karmakaze 8y agoPower-only USB cables offer good data protection, or just set your device in such a mode.
- geofft 8y agoNo 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.
- Spooky23 8y agoSeems 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.
- SahAssar 8y agoHow is that any different from AC->USB adapters before USB-C?
- detaro 8y agoBefore, 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.
- learc83 8y agoFaulty usb chargers can put line voltage on the charging end anyway, regardless of the spec.
- oasisbob 8y agoOr, Power over Ethernet. 48 volts at up to ~75 watts.
- Spooky23 8y agoMy 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.
- derefr 8y agoIn 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.
- rvooda 8y agoI've always wondered if "authentication" is possible on a Quantum Realm.
- gregmac 8y agoCan'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_class https://en.m.wikipedia.org/wiki/USB_human_interface_device_c...
- NullPrefix 8y agoHow are you going to authorize new HID devices without other currently working and authorized HID devices?
- wpowiertowski 8y agoExactly 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.
- deleted 8y ago[deleted]
- phil21 8y agoThat 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.
- q3k 8y ago>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.
- wahern 8y ago1) 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.)
- Abishek_Muthian 8y agoHow about for USB hardware tokens? Would it be a legible case for such authentication.
- lightedman 8y ago"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.
- geofft 8y agoNegotiation, 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?
- lightedman 8y agoAuthentication also means verifying that the charger is what it says it is and is capable of doing what it claims to do. Without authentication, your phone would not know the difference between QuickCharge and TurboPower specs, and might not charge properly (or pick the wrong charging spec and get fried.)
- londons_explore 8y agoThe 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.
- kwhitefoot 8y agoAll 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.