Re: app level security

Hi folks,

Quick overview of FIDO devices for those who may not know:
* FIDO devices are cryptographic device that acts as a second (or only)
factor for user authentication
* FIDO devices must have a test of user-presence (e.g., touch sensor or
fingerprint reader)
* FIDO devices speak a standardized protocol
* FIDO devices operate on something similar to the "same origin policy" in
order to preserve user privacy across various applications and websites

Since FIDO devices are often a separate form factor (e.g. a USB or
Bluetooth dongle), they rely on some client (e.g., web browser) to tell the
FIDO devices which origin is making a request.  In this sense (and in a
couple of others that are also part of the privacy guarantees), the client
is part of the trusted computing base.

I *think* the client/browser plays the same role for giving origins or
applications access to the microphone, camera, keyboard, or just about any
user input device.  So what we're proposing is to treat FIDO devices as
such input devices -- that, instead of providing a keystroke, provide the
user identity.

-Alexei

On Sat, Apr 25, 2015 at 5:09 AM Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

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