Discussion in 'Article Discussion' started by Gareth Halfacree, 13 Apr 2016.
I looked around a bit and found evidence it would have both, I quote from the present pre-encryption setup:
• Legacy 5V V BUS start, voltage / current adjust after negotiation
• Dead Battery detection and charging
• Default policies built-in for hardware-only starts
• Software interface enables more advanced policies
• Expose power delivery status to OS
• Support features to eliminate silent failures
So I conclude with encryption it would I expect also do the 'hardware' system and on top a more expansive OS experience for running systems.
Because obviously in many cases you don't have a thing running an OS, like for instance when charging a portable device that's low on power.
I'd like to see it made possible to verify the certification of cables, but NOT to verify the exact brand of cables. HP has already proven that, given a chance, some manufacturers WILL lock down their USB Type-C charging to only their own brand.
The power microcontroller runs off the base 5V×100mA that's always sent, regardless of cable and do the negotiation and everything else needed to bootstrap the higher-level stuff. Adding a little bit of verification logic there is pretty trivial, if time-consuming - but then again, a completely flat phone take s a solid while to go from empty to charging already, so it's hardly changing the status quo.
Also, can we please not call it encryption? Cause that is not what this protocol does. This protocol only does authentication, and if you need encryption, you'll have to write your own encryption over USB driver and hardware to make it happen.
Sadly, as a side-effect of how the certificate-based system is, each cert should be unique, and as such it will be entirely possible for vendors to lock down to only their choice of cables.
In practice, I don't think the majority will do that, cause it's a good way the get the FTC and EC on your ass for blatant anticompetitive behaviour (as oppose to previous situations where there was no universal spec).
All that said, **** HP, especially their HPE arm, which recently locked down all firmware updates for their servers. For now, I'm never buying any HP or IBM gear until they change that policy.
All I see happening is hundreds of thousands of clones of the same USB cable being made, which drives up the costs whilst still having exactly the same sub-standard quality wiring. Not only that but it seems like a nice site to add a new attack vector. Signing cables increases costs for everyone, adds complexity to the manufacturing process and doesn't solve any problems.
I've elaborated already a few posts above why I don't think this is an issue, since we can just revoke a leaked/compromised cert and they'll be shoved back down to base USB 3.1 spec which is relatively harmless.
Those already exist, in stuff like the rubber ducky. In fact, I use something very similar myself called a Soarer convertor to make my 1985 IBM Model F keyboard work with shiny, modern, all-USB computers.
Manufacturing a real, compliant USB3-capable USB-C cable is already pretty damn expensive compared to a USB2-only on due to the high bandwidth requirements of USB3. Adding a 5c chip to the assembly is pretty small in comparison.
As for solving problems, if used properly not only does it solve the dodgy cable problem, it also gives IT admins all around the world the ability to allow only approved USB devices to connect, which, incidentally, should also should stuff like the rubber ducky from working at all.
Separate names with a comma.