Re: Web Bluetooth security model

On Mon, Apr 11, 2016 at 1:14 AM, Von Dentz, Luiz
<luiz.von.dentz@intel.com> wrote:
> Hi Jeffrey,
>
> On Fri, Apr 8, 2016 at 11:44 PM, Jeffrey Yasskin <jyasskin@google.com> wrote:
>> On Wed, Apr 6, 2016 at 9:40 PM, Paul Theriault <ptheriault@mozilla.com>
>> wrote:
>>>
>>> Hi Jeffrey,
>>>
>>> Thanks for writing this up.  Back at the start of this process, we talked
>>> about a CORS-like opt-in for devices. I note that seems to have been ruled
>>> out - I remember seeing some discussion about this, but can you summarise
>>> was this approach not taken?  Were there technical reasons why devices
>>> couldn’t signal that they were Web Bluetooth safe/ authorise origins?  Would
>>> it be something possible to consider in the future, or is it infeasible?
>>
>>
>> There are about 3 options for CORS-like control overall:
>>
>> 1) Devices have no knowledge of or control over which origins communicate
>> with them. This is the situation with the current Web Bluetooth proposal. We
>> think this is relatively safe because it matches the situation devices are
>> already in with native apps, so the security-conscious ones have been
>> designing for it. (e.g. Fitbit has a key exchange process with its
>> particular app, not just the BLE exchange with the peer device.) Lots of
>> devices aren't security-conscious, but many of these are also low-value. I
>> wish I could quantify this more than I can.
>>
>> 2) Devices have to opt into particular origins communicating with them. This
>> is how CORS works and is the safest option, but excludes all existing
>> devices, like your cheap pedometer, from being used with the web. Part of
>> the way we're starting to get manufacturers' interest is by writing demo
>> apps that use their products, like
>> https://webbluetoothcg.github.io/demos/bluetooth-toy-bb8/, and that wouldn't
>> be possible with an opt-in rule.
>>
>> 3) Devices can opt out of particular origins communicating with them. This
>> is where I'd like to end up. I sent an NWP for this
>> (https://www.dropbox.com/sh/8uyuts52hvx5tdy/AAAgI_CMVXYz-jR0IJWGv8ata/Handling%20Semi-trusted%20Applications%20NWP.docx?dl=0)
>> to the Bluetooth SIG last year, but I don't have time to personally drive it
>> through their process, so it didn't go anywhere. If someone else has time,
>> I'd love for them to take over. Marcel Holtmann thinks the right way to do
>> this is to have the UA's Bluetooth Controller pretend to be multiple
>> different radios, one for each website, so that normal Bluetooth bonding
>> would distinguish between origins, but I'm not sure that's the way to go,
>> since it doesn't actually communicate the origin.
>
> I don't think we need to go as far as emulating one controller per
> website, instead I would have each website having a dedicated ATT/GATT
> channel. Actually this is already possible with a custom service that
> could authenticate per-app and make use of L2CAP Connection oriented
> Channels. I guess this would be much simpler to pass and this actually
> pushes further the use of L2CAP CoC which is a much better way to
> handle things like firmware upload, this could also solve problems
> related to the fact that ATT uses a fixed channel with a quite big
> timeout of 30 seconds and no way to cancel it except disconnecting the
> ACL link and starting over.

That's the discussion I need someone to own with the Bluetooth SIG, if
we're going to get a CORS-like mechanism for Web Bluetooth to use.

Jeffrey

Received on Monday, 11 April 2016 15:21:43 UTC