Blacklisting firmware update services that don't default to checking signatures

Hi all,

With any firmware update service, there's a risk that users will be
phished into granting a malicious site access to re-flash their
device. Devices can prevent this by checking that any image they
accept is signed by their manufacturer, but so far that hasn't been
the default for the pre-defined update services, which means we have a
lot of devices out in the wild that could be hijacked. For update
services defined by radio manufacturers, attackers can write a single
program that attacks a lot of devices, while devices that define their
own update services make the attackers at least know about the
individual attacked device.

I've filed https://github.com/WebBluetoothCG/registries/issues/7 and
https://github.com/WebBluetoothCG/registries/issues/8 to add the
Nordic and TI firmware update services to the WebBT blacklist, but I'm
sure there are others we should add too. Please help me find and add
those.

This is really unfortunate, but we have to minimize the risk that we
open our users up to a big attack.

I'm still trying to figure out the minimum safety level for an update
service to stay un-blacklisted. Certainly a service whose default
implementation doesn't compile until you generate a key pair and embed
the public half, and whose UUID had never been used for a less-secure
implementation, would be fine.

Jeffrey

Received on Wednesday, 30 March 2016 01:00:16 UTC