Re: app level security

Another and maybe more general usage of tokens over BLE
https://cyberphone.github.io/openkeystore/resources/docs/webnfc--web2device-bridge.pdf
which embeds security tokens (of any kind) in a proper environment.

Anders

On 2015-04-25 11:36, Dave Raggett wrote:
>
>> On 24 Apr 2015, at 22:09, Jeffrey Yasskin <jyasskin@google.com <mailto:jyasskin@google.com>> wrote:
>>
>> On Fri, Apr 24, 2015 at 3:02 AM, Dave Raggett<dsr@w3.org <mailto:dsr@w3.org>>wrote:
>>
>>     Jeffrey wrote:
>>
>>>     Bluetooth LE Secure Connections establish a connection between a
>>>     Central and a Peripheral device that's secure against other nearby
>>>     radios. However, Central devices often run many applications, only one
>>>     of which the user intends to use with a given Peripheral. Current
>>>     Bluetooth pairing mechanisms allow these other applications to
>>>     communicate with the Peripheral in a way that's indistinguishable from
>>>     the application the user intended. [1]
>>>
>>>     For example, the FIDO protocol
>>>     (https://fidoalliance.org/specifications/overview/) assumes the FIDO
>>>     device is talking to an application that honestly reports the origin
>>>     of signature requests. If an untrusted device or application can talk
>>>     to the FIDO device, it can request a signature for an arbitrary
>>>     origin, which breaks FIDO's protection against phishing. Bluetooth
>>>     secure pairing defends against the untrusted device, but not the
>>>     untrusted application.
>>>
>>>     We have a couple ideas for dealing with the problem, but we're
>>>     definitely open to better ideas this group comes up with.
>>
>>     This would seem to be a problem for the FIDO device to address. If someone were to attempt to connect via the browser API, then it would be up to the FIDO device to determine that the connecting device/app is not authorised, and to close the connection accordingly.  This security challenge is thus something we don’t need to address for the browser API.
>>
>>     What am I missing here?
>>
>>
>> I think this is more a problem the Bluetooth SIG should address than the Web API, but the reason it's relevant to this group at all is that the FIDO device currently has no way to determine what the connecting app or website is. For most Web protocols, we identify the source origin when creating a connection, but for this one we're not doing so. That's ok within the Bluetooth security model that devices are designed against, but for the occasional device that uses a different model, it'd be good to do something.
>>
>> I've cc'ed Alexei who works on FIDO and argued for doing something.
>
> Thanks. I am hoping that Alexei can give us some more details on the FIDO devices.  I am guessing that the client device (e.g. a laptop) would first need to be “bonded" with the FIDO device. If this is at the operating system level, then any app on the laptop would be able to invoke the key signing operation provided by the FIDO device. Perhaps the browser could block key signing requests from web applications?  Alternatively, if the FIDO device requires app level authentication, then the browser could only provide this for legitimate key signing requests.
>
> A further thought is the potential for limiting access to capabilities provided by bluetooth smart devices to specific web applications. This could be based on app level authentication above the level of the browser API, or it could be based upon the browser checking the web app’s origin.  One use case could be a personal health device that should only be used with a given web app. Another use case could be a toy robot that should only be used with the manufacturer’s web app.
>
> —
>    Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>
>
>
>

Received on Saturday, 25 April 2015 12:09:32 UTC