Re: Security restrictions on web<->device communication

Hi Luiz,

  thanks for your reply. See my answer below.

Kind Regards,
Julien

On Mon, Apr 13, 2015 at 3:14 PM, Von Dentz, Luiz <luiz.von.dentz@intel.com>
wrote:

> Hi Julien,
>
> On Mon, Apr 13, 2015 at 3:14 PM, 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), 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). 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).
>
> In Linux/BlueZ the services registered by plugins get blacklisted so
> they are not accessible to the upper layers to avoid possible
> conflicts between apps, that includes HoG, GATT, GAP, etc.
>

Ok, thanks for the clarification on BlueZ.


> >>
> >> >> 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.
>
> But do you use signed writes for this or just long writes enabling
> encryption? So far I haven't seem any good use for signed writes, but
> in the other hand the stack could auto detect the application is
> trying to write to an attribute that requires authentication, but note
> that WriteValue has no offset so currently it would require you to
> pass all firmware blob at once.


For the BT Smart functionnal communication and the DFU, we are  using LTK
(Long Term Key).
The LTK is exchanged during the pairing process.

We are not using (and have never seen so far) devices using CSRK, signature
sent after the PDU.

Another level of protection is the signature sent after the DFU which is
used to ensure veracity of the file downloaded.


> >>
> >> >> 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, 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
> >> >>
> >> >
> >>
> >
>