Re: Security restrictions on web<->device communication

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

Received on Monday, 6 April 2015 15:37:30 UTC