- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Fri, 24 Apr 2015 13:57:00 +0200
- To: Dave Raggett <dsr@w3.org>, public-web-bluetooth@w3.org
On 2015-04-24 12:02, Dave Raggett 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. FIDO devices in similarity to other security tokens depend on that they are "surrounded" by trusted middleware. > 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? If you connect a security token to a unit which isn't trustworthy all bets are off, that's all. The only thing that the token provides is a safe place for storing/using keys. What's the use-case here? Anders > > — > Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>> > > >
Received on Friday, 24 April 2015 11:57:30 UTC