Re: [web-bluetooth] What is a secure Device Firmware Update Service?

Hi guys,

  in a nutshell I'm in favor of black-listing potentially dangerous 
**_standard_** 
[services](https://www.bluetooth.com/specifications/gatt/services) and
 
[characteristics](https://www.bluetooth.com/specifications/gatt/characteristics),
 and agree with standard UUIDs that have been chosen so far in 
[gatt_blacklist.txt](https://github.com/WebBluetoothCG/registries/blob/master/gatt_blacklist.txt).
 

  However **_I want to sit against blacklisting vendor-defined 
services and characteristics_**, and leave responsibility to the 
vendor for its device being eventually corrupted. As it is already 
stated in spec, [**_device access is 
powerful_**](https://webbluetoothcg.github.io/web-bluetooth/#device-access-is-powerful),
 and user must be aware of it.

  My first caution with the practice of black-listing is that we'd 
always be behind both standard, and of course vendor-defined UUIDs. As
 I state above, I'm in favor of such blacklist for standard UUIDs 
cause standard evolves slowly, and my guess is that dangerous UUIDs, 
that needs black-listing, have already been put into it. For instance,
 I don't want any other UI to turn of privacy flag, or to trace my 
gizmo's serial number..

  Now, as regards vendor-defined services and characteristics, please 
also pay attention that a service may have multiple purposes, and 
hence may not be dedicated to, say, solely Device Firmware Update 
(DFU). 

  At Logitech, we are used to encapsulating our own protocols in 
standard-defined ones. We use for years a protocol called HID++, which
 originated from HID vendor. There are 2 versions, [which are 
public](https://drive.google.com/folderview?id=0BxbRzx7vEV7eWmgwazJ3NUFfQ28&usp=sharing)
 : version 1.0 and version 2.0. Version 2.0 is _object-oriented_ in 
spirit, in that it is a set of interfaces (that we call features in 
our lingo) defining functions and events. Similar to what are services
 and characteristics in GATT.

  We have defined a vendor service for HID++ over GATT, that will 
expose various features, among which you'll find DFU. Now the fact 
that DFU is secure or not lies in its implementation. We guarantee our
 DFU implementation to be secure, by having implemented the following 
: 
- DFU file is digitally signed using private key
- Device firmware embeds public key for signature verification during 
DFU, and hence rejects any requests for injecting rogue firwmare.

So, **please do not black-list vendor-defined services** at risk to 
block all device access, and make us fall-back to using native apps. 
Native apps aiming to break device firmware or just play with it are 
already done by couple of reverse-engineers (we love them and want to 
make them happy!), and other security-research companies help us to 
pinpoint and correct defects (e.g. MouseJack / KeyJack for Unifying 
receiver by [Bastille](https://www.bastille.net/)).

To finish, we might want to black-list DFU services provided in demo 
kits, but this makes testing being a burden. I'd leave responsibility 
of device vendors not to use those services, but rather provide their 
own GATT service.


-- 
GitHub Notification of comment by jracle
Please view or discuss this issue at 
https://github.com/WebBluetoothCG/web-bluetooth/issues/258#issuecomment-237200042
 using your GitHub account

Received on Wednesday, 3 August 2016 10:21:21 UTC