What you'd described would require each USB device to cryptographically sign its communications with an unique key. AFAIK USB doesn't have this, but thunderbolt does (it's called "secure connect"). Even if it does get implemented though, it probably won't help much because most users can be social engineered into trusting the new device.

The common USB device classes (video device, HID keyboard/mouse, etc.) don't have this, but anybody can define a new device class that does.

It seems like maybe Microsoft should have required something like this for Windows Hello cameras, if they intended for people to use the hardware as a single factor authenticator.

i.e. the camera generates internal crypto keys and tells Windows about them when you set up Windows Hello, then Windows does a challenge/response to make sure it's getting an image from the authentic camera during login attempts.

Apple did something like this with the fingerprint reader home buttons on iPhones, which is why you had to replace the motherboard + home button as a single unit on damaged devices. They could have provided a reprovisioning tool, but it's Apple, so they didn't.

” They could have provided a reprovisioning tool, but it's Apple, so they didn't.”

They did

They most certainly did not.

https://www.ifixit.com/News/9020/no-fix-iphone-7-home-button

https://www.ifixit.com/Guide/MacBook+Air+13-Inch+Retina+Disp...

Source?

There exists the USB Authentication Specification Rev. 1.0 [1] which states in section 3.3:

"A private key used by one Authentication Responder shall not be used by any other Authentication Responders. For example, one instance of a USB PD power supply cannot have the same private key as another instance of the USB PD power supply, even if they are otherwise identical model."

[1] https://usb.org/document-library/usb-authentication-specific...

Current USB host controllers aren’t built in the way they can distinguish between physical removal and electronic self reset.

Maybe if you’re NSA you could roll your own USB xHCI and a USB A receptacle that could characterize and identify individual units down to a machine in China used to assemble it, but that will be lightyears ahead of commercial USB host controllers.

My point was if the class, VID or PID changes then treat it like a "new" device. If it presents subdevices or is suddenly a hub, those are new devices.

You'd have to also detect PID/VID brute force attacks. Short of a cryptographic key (as gruez talked about), a device being able to guess a valid class+PID+VID combo would be bad, so this would have to be treated similar to a password brute-force attack: too many "new" devices in a short time (especially unplugged without clicking the authorization UI) would cause the system to stop accepting new devices for a time.

Ideally you can also detect something else -- eg: serial number -- but I think that starts getting into manufacturer/device-specific implementations. (If only there was a company with billions of dollars and huge facilities and relationships with USB vendors and the capability to test tons of devices..)

>My point was if the class, VID or PID changes then treat it like a "new" device

Yes, I understood that. What I'm saying that USB wouldn't give you any context for that. A device changing would be indistinguishable from one being removed and a new one going in. Or future "rubby duckies" could emulate a hub, and add multiple devices, all operating simultaneuously.

I don't see why you need context?

> A device changing would be indistinguishable from one being removed and a new one going in. Or future "rubby duckies" could emulate a hub, and add multiple devices, all operating simultaneuously.

In all of these cases, the system should show a prompt asking the user for authorization. Hopefully in a way that makes it clear if they didn't just physically attach a new keyboard, they should be extremely suspicious about what's currently connected to their USB ports.

Yes, you could prompt for every USB device detection. You would have to do that on boot too, though, which would probably give users security notice fatigue. There's basically no persistence, serial numbers, etc.

Only initially. I guess maybe I wasn't clear in my original post, but my idea was always that the system would remember any authorized device (presumably by VID+PID+capabilities, but maybe also serial or other identifying info if the device+OS supports it). You'd only get the UI prompt the very first time you plug in a new keyboard -- after that, you can plug it in at will and it continues to work. This is also why I mentioned about VID/PID brute force attacks.

It would be rare to see multiple devices at once -- eg: the very first boot, or plugging in a new complex device like a dock -- but the experience of this hinges on having the right UI. Having a series of pop-ups like "Do you accept Generic USB Hub 06 (connected to Root USB Hub 2)?" is going to cause them all to be ignored, but, for example, showing a tree of devices and making it easy to accept all at once would probably be ok. And hubs in particular may be a special case, where you don't bother to prompt, but I don't know if that opens an attack vector.

What input device do you use to accept the prompt?

A PS/2 mouse would work, but who has those anymore?

Plus you'd have to teach people to turn off their computers before plugging them in, which would be hard with Windows these days, when Shutdown is actually Hibernate