Re: Security restrictions on web<->device communication

Thanks for the comments. I'm drafting an email to the Bluetooth Security
Experts Group to see if they have thoughts and can help us get anything
necessary standardized through the SIG.

It looks like 2 approaches may be enough to keep devices secure against
hostile websites:
1) Define a blacklist of OS-only services, like HID and FIDO. OSes would
expose custom interfaces to these blacklisted protocols, like chrome.hid.
This covers existing devices.
2) Start defining a pairing mechanism that works between apps and
peripherals. It looks like a lot of fitness trackers are doing this
already, to deal with the lack of secure pairing in BT 4.0 and 4.1, but
it's not clear how secure it is. This makes it easier to build secure new
devices.

I haven't heard any interest in a whitelist of any sort, so I think we
won't be pursuing it. I'm still worried about what we'll do when a critical
device turns out to have a horrible security flaw, and the device has no
device ID service, but hopefully the chooser will prevent mass exploits.

Jeffrey

On Mon, Apr 13, 2015 at 5:14 AM, Julien Racle <jracle@logitech.com> wrote:

> Hi Jefferey,
>
>   I had a chat with a few folks, and below is out input (in blue).
>
> Sorry for the delay!
>
> Cheers,
> Julien
>
> On Mon, Apr 6, 2015 at 8:00 PM, Jeffrey Yasskin <jyasskin@google.com>
>  wrote:
>
>> Thanks for the reply!
>>
>> On Mon, Apr 6, 2015 at 10:08 AM, Scott James Remnant <keybuk@google.com>
>> wrote:
>> >> Can the Bluetooth experts here think of other devices for which general
>> >> web
>> >> access would be a security problem? Can you put us in touch with any
>> other
>> >> Bluetooth security experts who would have good input?
>> >
>> > Keyboards.
>>
>> Yep.
>>
>
> As keybuk states, indeed (mice and) keyboards are risky to be exposed to
> the web. So HID over GATT profile is a serious candidate for security
> concerns.
>
> At the time of writing chrome.hid API with reillyg we've blocked at
> chromium level a few dangerous HID usages (see here
> <https://chromium.googlesource.com/chromium/src.git/+/master/device/hid/hid_usage_and_page.cc>),
> cause all OSes didn't block sniffing or writing to those ones (thinking of
> Mac OS for instance).
>
> At Logitech, we historically communicate (over USB and Bluetooth Classic)
> with many of our devices (thinking particularly of mice and keyboards)
> using HID vendor collections. We participated to HID over GATT (HOGP)
> service some time ago, and hence unleashed implementation by OS makers of
> HID class drivers over Bluetooth Smart.
>
> I recall however that HOGP is black-listed by Windows RT APIs (see here
> <https://msdn.microsoft.com/en-us/library/windows/apps/bg182882.aspx#four>).
> On windows, we still use setup API to communicate with system's HID class
> driver (which in turn is a HOGP implementor). I don't recall on MacOS.
>
> Thus, at Logitech we're better off using HID vendor if possible, but we do
> also have a proprietary service to achieve same functionality for OSes that
> have no HID API support (like iOS).
>
>
>
>> >> If browsers were to require devices to expose a particular service
>> before
>> >> letting websites talk to the device, what proportion of existing
>> devices
>> >> would be able to accept a firmware update to expose that service?
>> >
>> > None. LE is too low bandwidth for things like firmware updates, and if
>> there
>> > were such a thing, the "Firmware Update" GATT service would be a prime
>> > example of the answer to your question above ;-)
>>
>> FitBits appear to update their firmware over an LE connection. It
>> takes ~10 minutes. It's straightforward to sign firmware updates, and
>> check the signature before applying the update, which would make it
>> safe to allow arbitrary access to that service, but I don't know if
>> actual manufacturers have bothered to incorporate that security
>> feature.
>>
>
> Our BLE devices do perform DFU over GATT. Depending on the embedded
> application it takes more or less time. BLE evolutions will make usage of
> longer packets possible, leading to quicker DFU. In any case, DFU can be
> performed in background, allowing parallel usage of the device, then
> switching to the new application when DFU is over.
>
> We do more and more use devices capable of updating their firmware, like
> FitBit does, and it is crucial to keep this feature.
>
>
>> >> If browsers were to require a device's PnP_ID to appear on a whitelist
>> >> before we'd grant access, do any of you have a feeling for how
>> difficult
>> >> that whitelist would be to maintain? I see about 500 vendors granted
>> IDs
>> >> through the Bluetooth SIG, and we'd probably want each of them to
>> provide
>> >> a
>> >> URL we could fetch to get their piece of the whitelist.
>> >
>> > Since the Device ID specification is just a GATT service, it's easy for
>> any
>> > other device to forge; I'm not sure of the value of this white list?
>>
>> The value of the whitelist is that we wouldn't expose devices to
>> hostile websites unless their maker opts into that access. If a device
>> manufacturer goes to the trouble of using someone else's device ID in
>> order to let websites access their device, they've asserted that we
>> don't need to protect their device against web access. The main
>> problem with colliding device IDs is that we can't _remove_ access to
>> one, if it's vulnerable, without removing access to all of its clones.
>>
>
> We have trouble thinking of the value of such list as well.
> We'd need to standardize access to a white-list inside vendor's website.
> That sounds complicated.
>
> >> If browsers were to require a service's UUID to appear on a whitelist
>> >> before
>> >> we'd grant access, can you think of any safe way to include UUIDs that
>> >> aren't standardized? In particular I'm worried about attackers
>> >> whitelisting
>> >> their victims' UUIDs. Is it safe enough to let any registered vendor
>> >> whitelist any UUID?
>> >
>> > We should assume that standardized UUIDs will be already blacklisted by
>> the
>> > host subsystem, and that only non-standard service UUIDs will be
>> accessible
>> > by the web browser.
>>
>> That's not quite true: heart rate monitors are standardized, but not
>> blacklisted by the host subsystem. I think you're right about
>> keyboards.
>
>
> See above remarks for HOGP profile. I think other standardized profiles
> should be treated with the same level of consciousness as OS maker do.
> Heart-rate monitoring is not something sensitive IMO.
>
> Sensitive operations (DFU etc) will happen through vendor-specific
> services, but we have to balance security vs the fact that any non-standard
> UUID white/black-listing should be kept easily maintainable. IMO if we have
> to put such mechanisms, the procedure should be 'dynamic' (user consent).
>
>
>> >> If browsers allow access by default, and a device is found to be
>> >> vulnerable
>> >> to an attack, what's the best way to blacklist it? I hear that the
>> Device
>> >> Information service may not distinguish different devices using the
>> same
>> >> controller.
>> >
>> > Device ID should be different per-device.
>>
>> 'k, that's good. Do we know that device makers actually follow that
>> "should"? What should we do for devices that omit the device ID
>> entirely?
>>
>
> DIS <https://www.bluetooth.org/en-us/specification/adopted-specifications>,
> except for HID devices, is optional. So we can't rely on its presence.
>
> As a side remark (thinking of HOGP service), communication (R/W) with
> keyboards requires an authenticated link, whereas reading mouse reports
> does not.
>
> We shall also take into account this level of security.
>
>
> On Mon, Apr 6, 2015 at 8:00 PM, Jeffrey Yasskin <jyasskin@google.com>
> wrote:
>
>> Thanks for the reply!
>>
>> On Mon, Apr 6, 2015 at 10:08 AM, Scott James Remnant <keybuk@google.com>
>> wrote:
>> >> Can the Bluetooth experts here think of other devices for which general
>> >> web
>> >> access would be a security problem? Can you put us in touch with any
>> other
>> >> Bluetooth security experts who would have good input?
>> >
>> > Keyboards.
>>
>> Yep.
>>
>> >> If browsers were to require devices to expose a particular service
>> before
>> >> letting websites talk to the device, what proportion of existing
>> devices
>> >> would be able to accept a firmware update to expose that service?
>> >
>> > None. LE is too low bandwidth for things like firmware updates, and if
>> there
>> > were such a thing, the "Firmware Update" GATT service would be a prime
>> > example of the answer to your question above ;-)
>>
>> FitBits appear to update their firmware over an LE connection. It
>> takes ~10 minutes. It's straightforward to sign firmware updates, and
>> check the signature before applying the update, which would make it
>> safe to allow arbitrary access to that service, but I don't know if
>> actual manufacturers have bothered to incorporate that security
>> feature.
>>
>> >> If browsers were to require a device's PnP_ID to appear on a whitelist
>> >> before we'd grant access, do any of you have a feeling for how
>> difficult
>> >> that whitelist would be to maintain? I see about 500 vendors granted
>> IDs
>> >> through the Bluetooth SIG, and we'd probably want each of them to
>> provide
>> >> a
>> >> URL we could fetch to get their piece of the whitelist.
>> >
>> > Since the Device ID specification is just a GATT service, it's easy for
>> any
>> > other device to forge; I'm not sure of the value of this white list?
>>
>> The value of the whitelist is that we wouldn't expose devices to
>> hostile websites unless their maker opts into that access. If a device
>> manufacturer goes to the trouble of using someone else's device ID in
>> order to let websites access their device, they've asserted that we
>> don't need to protect their device against web access. The main
>> problem with colliding device IDs is that we can't _remove_ access to
>> one, if it's vulnerable, without removing access to all of its clones.
>>
>> >> If browsers were to require a service's UUID to appear on a whitelist
>> >> before
>> >> we'd grant access, can you think of any safe way to include UUIDs that
>> >> aren't standardized? In particular I'm worried about attackers
>> >> whitelisting
>> >> their victims' UUIDs. Is it safe enough to let any registered vendor
>> >> whitelist any UUID?
>> >
>> > We should assume that standardized UUIDs will be already blacklisted by
>> the
>> > host subsystem, and that only non-standard service UUIDs will be
>> accessible
>> > by the web browser.
>>
>> That's not quite true: heart rate monitors are standardized, but not
>> blacklisted by the host subsystem. I think you're right about
>> keyboards.
>>
>> >> If browsers allow access by default, and a device is found to be
>> >> vulnerable
>> >> to an attack, what's the best way to blacklist it? I hear that the
>> Device
>> >> Information service may not distinguish different devices using the
>> same
>> >> controller.
>> >
>> > Device ID should be different per-device.
>>
>> 'k, that's good. Do we know that device makers actually follow that
>> "should"? What should we do for devices that omit the device ID
>> entirely?
>>
>> Thanks,
>> Jeffrey
>>
>> > On Mon, Apr 6, 2015 at 8:37 AM Jeffrey Yasskin <jyasskin@google.com>
>> wrote:
>> >>
>> >> Hi all,
>> >>
>> >> Does anyone here have thoughts on the questions below? We really need
>> >> wider input in order to balance security against usability.
>> >>
>> >> Thanks,
>> >> Jeffrey
>> >>
>> >> On Wed, Mar 18, 2015 at 9:59 AM, Jeffrey Yasskin <jyasskin@google.com>
>> >> wrote:
>> >> > Hi Web Bluetooth folks,
>> >> >
>> >> > Some Google folks have been talking about the security risks of
>> exposing
>> >> > devices to the Web when those devices weren't designed to be secure
>> in
>> >> > the
>> >> > face of that access. We'd like your input in figuring out how best to
>> >> > mitigate those risks, especially by answering the questions at the
>> >> > bottom of
>> >> > this email.
>> >> >
>> >> > An example vulnerable device comes from the FIDO specifications:
>> >> > https://fidoalliance.org/specifications. In particular, a web
>> >> > application
>> >> > that gets paired with a FIDO device can sign a challenge presented
>> by a
>> >> > different origin, breaking the FIDO security model. The UI needed to
>> >> > phish a
>> >> > user in this way appears to be simple.
>> >> >
>> >> > To mitigate this risk, I've put together a draft GATT service at
>> >> >
>> >> >
>> https://docs.google.com/document/d/1T6hLoLvOzNrcMrbtUxAO8yF8zskHiqKfEIPxJNYvfvg/edit
>> >> > to let devices control their interactions with websites, in a way
>> that
>> >> > resembles both CORS and postMessage's origin attribution. Feel free
>> to
>> >> > comment on that document.
>> >> >
>> >> > Once that service is standardized, if a device implements it, we're
>> home
>> >> > clear. The open question is what to do about devices that don't
>> define
>> >> > the
>> >> > new service.
>> >> >
>> >> > We'd like to get some feedback from this list before deciding what to
>> >> > do.
>> >> >
>> >> > Can the Bluetooth experts here think of other devices for which
>> general
>> >> > web
>> >> > access would be a security problem? Can you put us in touch with any
>> >> > other
>> >> > Bluetooth security experts who would have good input?
>> >> > If browsers were to require devices to expose a particular service
>> >> > before
>> >> > letting websites talk to the device, what proportion of existing
>> devices
>> >> > would be able to accept a firmware update to expose that service?
>> >> > If browsers were to require a device's PnP_ID to appear on a
>> whitelist
>> >> > before we'd grant access, do any of you have a feeling for how
>> difficult
>> >> > that whitelist would be to maintain? I see about 500 vendors granted
>> IDs
>> >> > through the Bluetooth SIG, and we'd probably want each of them to
>> >> > provide a
>> >> > URL we could fetch to get their piece of the whitelist.
>> >> > If browsers were to require a service's UUID to appear on a whitelist
>> >> > before
>> >> > we'd grant access, can you think of any safe way to include UUIDs
>> that
>> >> > aren't standardized? In particular I'm worried about attackers
>> >> > whitelisting
>> >> > their victims' UUIDs. Is it safe enough to let any registered vendor
>> >> > whitelist any UUID?
>> >> > If browsers allow access by default, and a device is found to be
>> >> > vulnerable
>> >> > to an attack, what's the best way to blacklist it? I hear that the
>> >> > Device
>> >> > Information service may not distinguish different devices using the
>> same
>> >> > controller.
>> >> >
>> >> >
>> >> > Thanks for any help,
>> >> > Jeffrey
>> >>
>> >
>>
>>
>