Every day we see some sort of new Internet of Things (IoT) device. The Maker movement is coming up with hundreds, if not thousands of these devices and they’re all ready to take on the world as the next great widget. But you have to ask yourself:
“Are all connected devices better simply because they are connected? Are they safer?”
“Is a smart deadbolt lock safer than it’s “dumb” counterpart?”
A recent article very easily broke the security on 12 of the 16 smart deadbolts tested. Seems like the answer to the above is “no”.
In an ever increasing connected world, the security of devices and the data stored on them and shared between them is a major concern. Additional security seems like the simple answer, but at what cost? Building a completely secure, connected device may make the price to the end customer unfeasible.
In what follows I aim to take you through the typical decision tree so that you can carve your own path through the jungle of options.
First: There just isn’t One Bluetooth
Bluetooth has gone through a few name changes over the last few years, finally settling with designations that describe the technology in use. Gone are “classic” “smart” and “smart ready”. Today the designations are simply:
- Bluetooth basic rate / enhanced data rate (BR/EDR)
- Bluetooth low energy (LE)
The underlying Core 4.2 specifications have not changed, though, and Core 5.0 is nearing release.
Let’s take a look at what security and encryption options exist. LE Secure Connections have been introduced with 4.2. This uses Elliptic curve Diffie-Hellman (ECDH) to generate keys coupled with new pairing procedures for exchanging keys. While this does allow authenticated and secure connections, not all Bluetooth LE devices can take advantage of it, especially smaller ones where the Bill of Material (BOM) cost is critical.
Second: How You Pair is Key to How You Secure Your Device
The pairing process takes place with an initiator and a responder. Devices fall into one of five categories:
- Display Only – A numeric display shows a passkey
- Display Yes/No – A numeric display plus a means of feedback with a button for Yes or No
- Keyboard only – No display, but allows numeric entry
- No Input / No Output – No displays, keyboards or switches
- Keyboard / Display – Both a keyboard and display are present
The following table, adapted from Volume 3, Part H of the Bluetooth Core 4.2 specification, shows which types of connections can and cannot be encrypted:
|Responder||Display Only||Display Yes/No||Keyboard Only||No Input
|No Input No Output||No||No||No||No||No|
* Authentication is possible with Numeric Comparison
In looking at this matrix, half of the types of device pairings cannot support any encryption by nature of their design. As we move to devices that can allow authentication, we are also moving to higher and higher BOM costs. In addition, all of the pairings that can be authenticated require some sort of user interaction.
Third: The Importance of Securing Firmware Updates
One of the most critical operations during the life of a device are firmware updates. These updates cannot take place in the clear for two reasons:
- The update can be intercepted and a duplicate device made. Consider many items found on eBay that are obvious clones of a well-known device selling for a fraction of the cost.
- A device in the field could have rogue firmware loaded that compromises the device, rendering it inoperable or worse – sending erroneous data.
How is one supposed to design an inexpensive device yet keep its firmware secure? This is where the Rigado RigDFU secure bootloader comes into play. For an end-device that uses a Rigado Module, it’s possible to program an encryption key over a UART while this device is undergoing final production test. This keeps the key out of the airwaves.
When the time comes to send an update to the end-device, the same key is used to encrypt the OTA update. Now all of the spaces in the table above suddenly become filled with “Yes”. Every Bluetooth LE device, from a low-cost sensor to an interactive thermostat, can now benefit from secure, encrypted firmware updates.
If that’s not enough, Rigado is keenly aware that firmware updates over Bluetooth take time. Bluetooth 5 is attempting to speed the interface and allow longer packets, though one fact remains. Until now, the entire firmware image is required to be sent. With Rigado’s DeviceOps framework, coupled with RigDFU, update files are not only encrypted, but they’re also incremental and compressed. Now simple bug fixes and feature updates take a few seconds rather than several minutes.
The Bluetooth SIG has implemented a nice set of encryption capabilities with LE Secure Connections, though one needs to include otherwise unnecessary components and user interaction into their design.