RE: Helping peripherals deal with semi-trusted applications on paired centrals.

Hi Jeffrey,

the Bluetooth pairing and bonding is on the device level. It is not an application or service level protection. It authentication and encryption between two devices.

Idea #1 is pretty much out of scope for the Bluetooth SIG as far as I can tell. The decisions of OS implementations to define certain Bluetooth LE profiles / service as system vs user is manufacturer specific.

Idea #2 is not going to work. Bluetooth pairing and bonding is defined as per device. If a device is trusted, then it is trusted for all other services with the same security level requirements. What you are looking at is an application level encryption / authentication. The Bluetooth Core specification does not have the concept of application level security. And so far no service defines application level security. All services base their security requirements on the concept of device security.

I think what you are proposing is pretty much TLS (or DTLS) over GATT. I would actually propose to run TLS (or DTLS) over a LE L2CAP connection oriented channel if you are security cautious.

This is an application level problem and you need to solve it on the application level. From the Bluetooth Core perspective, we know nothing about what is running above GATT or LE L2CAP CoC.

On side note, I think the Fitbit authentication problem has a serious security flaw. I remember reading something about that. The lesson is that any proprietary authentication or encryption will have just flaw. Open specification and open source code here is beneficial. And if you care about your security and privacy, you want this all peer reviewed.

Idea #3 seems to be not feasible to me. And honestly, once you TLS (or DTLS) over LE L2CAP CoC, then you do not need any other service to talk and try to authenticate. The problem is actually to find a common framework to authenticate application. Remember that you want to be interoperable. So an application A on OS Y need to be able t talk to application B on OS Z.

Where I am standing, applications that care about 1:1 end-to-end authentication and encryption have to provide it by themselves. This is not provided by the Bluetooth Core specification.

Regards

Marcel

________________________________________
From: Jeffrey Yasskin [jyasskin@google.com]
Sent: Sunday, April 19, 2015 20:58
To: seg-main@bluetooth.org
Cc: public-web-bluetooth; Alexei Czeskis; mwoolley@bluetooth.com
Subject: 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.

Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

Received on Monday, 20 April 2015 15:02:50 UTC