Security questions on the Bluetooth serial API.

[hemeryar]

Hi there! The TAG review for the bluetooth via serial classic ended up on the Open Web Platform Intent review list. I had some questions to help us better understand the security/privacy implications of the API:

• Are the service UUIDs fixed to this list https://www.bluetooth.com/specifications/specs/ or can you have truly custom ones?
• If truly custom ones exist, do you have an idea of the kind of use cases that would involve them?
• Do you know if there exists a list of vulnerable devices or would we need to craft one?
• Is there any reason to not standardize the defense mechanisms? Do you expect for example platforms to matter and the browser would have to mitigate depending on a heuristic?

Thanks, Arthur

[nondebug]

Hi Arthur, thanks for taking a look.

Are the service UUIDs fixed to this list https://www.bluetooth.com/specifications/specs/ or can you have truly custom ones?

Service UUIDs aren't fixed. Vendors can create their own 128-bit UUIDs to represent vendor-defined services.

For this feature, all services with UUIDs reserved by the Bluetooth spec will be blocked except for Serial Port Profile.

If truly custom ones exist, do you have an idea of the kind of use cases that would involve them?

Custom UUIDs are used for any functionality not covered by the standard profiles. A device might expose a serial service with a custom UUID as a debugging interface, or as an interface to access advanced features not included in the standard profile.

Do you know if there exists a list of vulnerable devices or would we need to craft one?

Rather than blocking per-device, we plan to maintain a list of vulnerable service UUIDs. There's a table defined in the Chromium source code but it contains no UUID entries because we don't know of any custom service UUIDs that should be blocked. The standard Bluetooth UUIDs are blocked by a rule that compares the UUID to the Bluetooth Base UUID; this is less error-prone than maintaining a list of all such services.

Is there any reason to not standardize the defense mechanisms? Do you expect for example platforms to matter and the browser would have to mitigate depending on a heuristic?

There's no reason not to publish the UUID blocklist as part of the specification and I expect we will update the spec with a blocklist. This is similar to how we handle vulnerable devices for other device APIs: WebUSB, WebHID, Web Bluetooth.

Currently there's no serial blocklist because (as described in Security Considerations) a blocklist-based filtering mechanism doesn't work well for RS-232 ports or serial adapters which don't provide any metadata about the connected serial device. That's not the case for Bluetooth, we can identify vulnerable devices by the services they expose.

I don't expect we would need to change the blocking behavior for different platforms. It will be least confusing for users and developers if device compatibility is consistent across all platforms and implementations.