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

Hi Martin,

what I am saying is that you need to identify the application. There is currently no defined procedure for identifying application or service/profile relationships on the level above L2CAP or GATT.

There is authorization concept for services, but that is different from authentication and encryption. All authentication is based on device to device.. Meaning once one service on a pair of device is authenticated, then all of them are authenticated. The same applies to encryption. The LE link is authenticated and encrypted. Not the individual service or application.

So if you want to authenticate and encrypt between two application (or service/profile for that matter), you need to built this on top of what current Bluetooth Core specification provides you.

LE L2CAP connection oriented channels are a host stack features. It can be enabled on existing Bluetooth controllers. No change in the controller firmware needed. To enable LE L2CAP connection oriented channels (which is a Bluetooth 4.1 feature) you require an update to the operating system. One released profile utilizing LE L2CAP CoC is IPSP.

The next step is of course to create a New Work Proposal.

Regards

Marcel

________________________________________
From: Martin Woolley [mwoolley@bluetooth.com]
Sent: Monday, April 20, 2015 07:17
To: Holtmann, Marcel; Jeffrey Yasskin; seg-main@bluetooth.org
Cc: public-web-bluetooth; Alexei Czeskis
Subject: RE: Helping peripherals deal with semi-trusted applications on paired centrals.

Hi, Jeffrey spoke with me at Bluetooth World about this.

Let me check I'm understanding the response here; the suggestion is to implement an authentication protocol or procedure between the browser and Bluetooth device over an L2CAP connection oriented channel? If so [dumb question mode engaged] wouldn't this require the device to support this in its firmware? I think Jeffrey and the W3C is looking to solve this problem for all Bluetooth LE devices in general not for particular devices he has control over.

If I've summarized correctly is this something there's any mileage in approaching via a New Work Proposal?

Comments?

Martin

-----Original Message-----
From: Holtmann, Marcel [mailto:marcel.holtmann@intel.com]
Sent: 20 April 2015 08:44
To: Jeffrey Yasskin; seg-main@bluetooth.org
Cc: public-web-bluetooth; Alexei Czeskis; Martin Woolley
Subject: 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

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 18:13:17 UTC