> What I'd really like is the system to consider every new USB device untrusted, and require specific approval before it's added as a device. This should apply to its capabilities too (eg: if a "keyboard" suddenly is presenting itself as storage, that causes a prompt). Think along the lines of "Acme WebCam XYZ wants to add a Camera and Microphone. Allow?"

There's USBGuard on Linux that seems to do some of this. Can't vouch for it, as I've never used it, though.

https://wiki.archlinux.org/title/USBGuard

https://github.com/USBGuard/usbguard

>if a "keyboard" suddenly is presenting itself as storage, that causes a prompt

I'm not clear on how you would know it was the keyboard changing identities and not just a new device. Does the USB protocol provide anything where you would know, assuming devices can change Base Class, VID, PID, and so on?

For that matter, I don't think it needs to change. It can just emulate a hub and present both.

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

> What I'd really like is the system to consider every new USB device untrusted, and require specific approval before it's added as a device.

QubesOS does this by quarantining your USB controllers in a dedicated virtual machine.

https://www.qubes-os.org/doc/usb-qubes/

Usb-guard for Linux also uses kernel features to accomplish similar.

I dont know of any methods to do this on MacOS or Windows though.

Seems like a recipe for severe headaches and cursing when devices fail while you're logged out and now you can't log in by just connecting a new keyboard.

"Please press this key sequence, then type your password, on the newly attached keyboard to enable it for use."

Then you will (probably) get malwares that open a window in fullscreen that imitates that prompt and sends data to a server.

You probably could add some kind of fingerprint that allow identifying the legit prompts, but since it is not done with login screens...

This is why Windows used to ask for Ctrl-alt-del before login. And if you have malware already on your system, it's already too late.

Aside from already having malware making this irrelevant, if you didn't just physically attach a new keyboard, the message about a new keyboard is also going to seem very suspicious.

Now I'm curious if there's some device that presents itself as a keyboard, types some Powershell script and "copies" files off of the computer using numlock/capslock/scrolllock signals.

That's a USB Rubber Ducky

Hah.

Never played with one, but I just assumed it was a macro playback engine, not surprising, I suppose it would do more.

Yes! Look into BadUSB, there's some really cool, but also scary, stuff out there.