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

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

Exactly. I'm asking for suggestions on the right way to standardize a layer
on top of the current Bluetooth Core specification. Does there have to be a
New Work Proposal in order to even start figuring out what general
direction that should go?

Jeffrey

On Mon, Apr 20, 2015 at 10:41 AM, Holtmann, Marcel <
marcel.holtmann@intel.com> wrote:

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