[seg-main] Helping peripherals deal with semi-trusted applications on paired centrals.

Hello Bluetooth Security Experts,

The World Wide Web Consortium 'Web Bluetooth' group is working on a
specification to let web pages communicate with Bluetooth devices via
GATT: https://webbluetoothcg.github.io/web-bluetooth/. When
investigating the security implications, we discovered a problem with
the pairing model for Bluetooth in general when used in modern
operating systems, which I'll describe below. We'd like your help
finding a good fix for this problem, and getting it adopted by the
Bluetooth SIG if that's the right thing to do.

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.

Idea #1: Define a list of services that should be reserved to the OS.
The HID service is effectively already on this list to prevent
keylogging, but as other and non-standard services appear that need
the same protection, it would be nice to have the Bluetooth SIG
maintain a central list.

Idea #2: Define a GATT application pairing profile that runs an
algorithm like LE Secure Connections, but between a single application
and an otherwise-unpaired peripheral. If messages between an
application and a peripheral are encrypted with a key that other
applications don't know, the other applications can't spy on the
connection. I believe there are existing examples of this in HID
Global's Seos layer and probably in several health monitors, like
Fitbit's 4-digit pairing with its application. There are also examples
of manufacturers getting it wrong and building insecure systems, which
a standard profile would make less likely:
http://makezine.com/2014/01/03/reverse-engineering-the-estimote/.

Idea #3: Define a GATT profile to let the OS identify the application
that's communicating. This potentially needs to be multi-layer: a
website running on a browser running on a mobile OS would have the OS
identify the browser, and the browser identify the website.


Can you consider the problem and let us know what you think?

Thanks,
Jeffrey Yasskin
https://www.w3.org/community/web-bluetooth/


[1] On traditional operating systems (e.g. Windows, Mac, Linux), this
doesn't matter, since an untrusted application also gets full
privileges to steal data, change other applications' UI, etc. However,
modern operating systems (e.g. Android, iOS, the Web) allow the user
to run an application without granting it full access to other
applications.
/n/n/n/n(c) Copyright, Bluetooth SIG, Inc. This email message and any attachments may contain confidential information that is legally protected and is solely intended for the individuals and their respective Bluetooth SIG member companies on this mailing list. Any unauthorized disclosure, use, copying, or distribution is strictly prohibited. Usage of this mailing list must comply with the terms of usage located at https://www.bluetooth.org/about/legal.htm. If you are not the intended recipient, please notify the author and destroy the original transmission without reading or saving.

Received on Monday, 20 April 2015 03:59:27 UTC