W3C home > Mailing lists > Public > public-web-bluetooth-log@w3.org > August 2016

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

From: Jeffrey Yasskin via GitHub <sysbot+gh@w3.org>
Date: Wed, 03 Aug 2016 22:04:39 +0000
To: public-web-bluetooth-log@w3.org
Message-ID: <issue_comment.created-237389452-1470261877-sysbot+gh@w3.org>
I think a secure firmware update service has to either require a 
signature from the old firmware's author or require the user to opt in
 on the device, like in @gfwilliams' example of holding down a button 
while inserting the battery.

The difficult decisions come when some implementations of the same 
service are secure and others aren't. I think the right rule there is 
that if the initial definition of a service encouraged a secure 
implementation, then we allow the service, and if the initial 
definition did not encourage a secure implementation, then we 
blacklist it. The "definition" doesn't need to be formal: if a service
 is initially used on a single device in a secure way, and then copied
 by other devices in an insecure way, I'd lean toward leaving it 
allowed, and calling the insecure copies a mistake that those devices'
 creators are responsible for.

I also don't think we should proactively look for insecure services 
that are only used on a single device. We should wait for those 
devices' creators to complain to us about a security problem they're 
encountering in the wild, and ask to have their service blacklisted. 
The risk here is that they'll have re-used someone else's service 
without telling us, and we'll break that other device by surprise. 
Anyone have preferences about how we should avoid that?

This does mean that individual devices can avoid the blacklist by just
 changing a standard service's UUID. I think that's fine: if a UUID is
 only used on a single device, it's 1) hard for an attacker to write a
 single program that attacks a huge number of people's devices, and 2)
 it's easy for us to blacklist that UUID if the device maker later 
realizes it was a mistake, since that won't cause collateral damage.


A registry of human-readable names for services is hard because there 
are so many services, but it's plausible for the few services on the 
blacklist. For the Chrome implementation, we'll have to figure out how
 to prioritize that. For instance, we probably don't want to delay 
shipping the API in order to make the blacklist overridable. 

GitHub Notification of comment by jyasskin
Please view or discuss this issue at 
 using your GitHub account
Received on Wednesday, 3 August 2016 22:06:45 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 3 August 2016 22:06:46 UTC