Bluetooth Smart (In)Security: How to fight firmware attacks

When it comes to protecting users from data sniffing Bluetooth Smart Secure Connections just doesn’t cut it. And your firmware updates are just as vulnerable.

Firmware attacks have been around for almost two decades now. It’s well-documented that Bluetooth Low Energy (BLE / Bluetooth Smart / Bluetooth 4.x) enabled devices are not airtight. While it’s true that the majority of interactions transmitted via BLE are innocuous, smart devices frequently transmit discreet information and firmware updates that attackers can easily sniff.

BLE Secure Connections uses either Just Works or 6 digit pin (or, less frequently, Out Of Band) to encrypt information sent over the air. These solutions, however, are easily breached by sniffers who obtain encryption keys when observing the initial connection between two devices. Malicious parties can also use brute force attacks to decipher pin codes. Sniffers siphoning communications during over-the-air firmware updates can recover the code and rework it into a copycat device.



Bluetooth Low Energy security is just not good enough.

Take a look at this Google user’s review of Context Information Security’s “Ramble” app, which lets you map broadcasting BLE devices:

Found hundreds of Bluetooth devices all nicely mapped with GPS coordinates…. Wondered how many, if any, utilize strong encryption. Then wondered if anyone could watch my Fitbit leave home then loot the place of devices and valuables of which they made a checklist. Wrapped myself in tin foil. [Five stars.]

I know what you mean, Google user. It’s a scary world out there. We can only hope that no one is interested in our step counts or when we decide to turn on our AC. Or – worse yet for developers – in copying our sensitive firmware.

The good news is that developers can fight against weak security.

lockDevelopers must build upon or circumvent standard BLE security to prevent data sniffing and brute force attacks on firmware updates.

One solution is preloading devices with encryption keys so they never have to travel the airwaves. This method places firmware safety firmly in the hands of the developer by fully bypassing built-in BLE security measures.

Secure bootloaders empower developers to evade firmware thieves – but there are currently limited options. Rigado’s [legacy] RigDFU software, for example, allowed users to make secure changes to existing firmware on their devices using 128-bit AES end-to-end encryption with a user-made key.

There is little more we can do for active BLE-powered communication as we await the expansion of Bluetooth 4.2-enabled devices with improved security features. For now we must continue to be mindful and vigilant of what we share. On a positive note developers are able to securely update their firmware. You can still be the master and commander of your firmware’s destiny.

You can read more about commercial IoT here.