The WebUSB Security Model
Update 2017–06–15: For those just catching up on WebUSB this article is no longer up to date with the current spec or what is implemented in Chromium. The manufacturer whitelisting requirement for device access is no longer enforced. Please see the “Security and Privacy Considerations” section of the specification for information about the security model.
In the spirit of Jeffrey Yasskin’s post on Web Bluetooth I’d like to take some time to explain what WebUSB is and isn’t and clarify the security model to show why we think it can improve security for the particular class of devices it serves.
What WebUSB isn’t for
First an introduction to the world of USB devices: The majority of devices fall into one of a few standardized device classes. USB HID (mice and keyboards) and USB Mass Storage (flash drives) being the most popular. The full list, as well as the specifications for how to design a device that implements one of these standard classes, is available from the USB Implementer’s Forum. Operating systems recognize a device implementing one of these classes and load a generic driver so most of the time the user never needs to think about it at all.
WebUSB is not about these kinds of devices. Operating systems handle them well enough and the web platform has high level APIs that cover things like receiving keyboard & mouse input, uploading & downloading files, and playing & recording audio & video.
The goal of WebUSB
We want to give developers building new kinds of devices the ability to deliver an out of the box experience without requiring users to install any new software, especially new drivers, on their system and thus improve security for users of these devices.
Here’s what happens today when you unbox a new device and plug it in:
- If it’s one of the standard device classes, the operating system loads a generic driver and you’re all set. Yay! Otherwise, it’s probably not recognized and you have to go fishing in the box for the instructions.
- You find the CD that came with the device, or a postcard with a link to the manufacturer’s site, and download whatever you find there.
- The installer needs to load a custom kernel driver, or if you’re lucky just a system service, to support the device. It asks for your password.
- Everything looks good now, so you launch the new application and get started with your new hardware.
There are many places where this can go wrong. Let’s take a look at a few:
- Downloading and running native software is dangerous. Once an application is running on your system it can do anything you can, and can be difficult to remove if you decide you don’t want to keep it. On top of that, since it had to install system components it asked for your password so now it has completely unfettered access to all of your data.
- All software is buggy. Device drivers, by virtue of running in the kernel (thankfully this is starting to change), can take down the whole system when they crash. Also, any security vulnerability they have can be exploited to gain access to the highly privileged environment in which they run.
- If you’re not running a supported operating system then you’re out of luck. I keep a Windows virtual machine around for all the devices I have that simply don’t have a software version for macOS.
WebUSB allows device vendors to take advantage of a number of the web’s best features to provide ease of use and security to their users:
- Only sites whitelisted by the device can even request permission to connect because the device is integrated into the web security model. Shady sites cannot even request permission to interact with the device.
- The web is ephemeral. If you’re only borrowing the device or decide to return it, there’s nothing left on your system to hunt down and remove.
- The API is available cross-platform, even on mobile devices, substantially reducing development costs and giving users the choice to use whatever platform they like best.
- Sites run in their own sandboxes. Even if a site is malicious or compromised it can’t access other sites or devices that the user hasn’t given it access to. If the site crashes you can just reload it.
Now with WebUSB the user can set up their device securely and effortlessly:
- Your browser detects that a new WebUSB-compatible device has been connected. It displays a notification offering to navigate you to the right page on the manufacturer’s site to get started.
- The site asks for your permission to connect to your device, protecting your privacy in case the device has access to personal information.
- You’re all set, the web application is talking to the device and you can get to work.
Malicious devices are still dangerous
WebUSB cannot protect the user against a malicious device attempting to exploit software outside the browser. Such attacks usually target the kernel. Projects such as the Facedancer21 provide tools for fuzzing systems against malicious devices. To do their part, sites should never trust that the device they’re connected to isn’t impersonating the device they expect with malicious intent.
While supporting firmware updates in the field is a good practice for most devices, this ability can be hijacked to turn a good device into a malicious one. WebUSB requires site to be served over HTTPS which prevents code injection by network attackers. Sites that have been compromised to serve malware are however far too common on the web. The only protection against this is firmware integrity checking within the device. Attacks such as iSeeYou have shown that this is already best practice as native malware can already easily attack a vulnerable device.
In summary
WebUSB lowers the cost of writing and distributing software for new USB devices, while making users safer by reducing the need to download unknown privileged native software, and ensuring only software trusted by the manufacturer can interact with the device.
Acknowledgements
Thanks to Vincent Scheib, Owen Campbell-Moore and Jeffrey Yasskin for helping to edit this post.
