Re: Security restrictions on web<->device communication

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

> 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 ;-)

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

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

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

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/1T6hLoLvOzNrcMrbtUxAO8yF8zskHi
> qKfEIPxJNYvfvg/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
>
>