nRF5 SDK v12.0 is now available for Nordic developers to download and use in their designs. We’ve added quite a few things this time around to help you, the big story however is the production grade introduction of secure OTA-DFU with signing.
Living in a constantly updated world
Software updates are a part of everyday life today. Barely a month passes without at least a few things we own getting a software shot in the arm from their manufacturers, be it feature improvements or resolution of issues both major and minor. I hear from those I talk to outside engineering circles ‘why all these upgrades’? Well, it’s just a fact of life, things are getting more complex, we demand more from products, and last, but perhaps most importantly we have devices such as Nordic SoCs that actually make it possible to do these things.
People may have begun to forget how annoying some products were when we knew they had a glitch but we just had to learn to live with it. That is no longer the case.
Of course updating this firmware is a big step for a product, out with the old, in with the new. It’s important to get it right. Security, verification, certification etc. are major watchwords in IoT these days. Updates need to be trustable, we need to know what they are, where they’ve come from and that they’ll do what they purport to do. We began working on signing for firmware upgrades some time back to improve security and trustability so let’s look at that story.
Improving Device firmware Upgrades
Quite some time back we introduced Device Firmware Upgrade (DFU) in bootloader for nRF51, which took advantage of upgradable flash-based architecture of the nRF51 SoCs. This brought the capability to update applications not only via a cable but most importantly Over The Air (OTA) via gateway devices such as smartphones, tablets and PCs. This was complemented with reference implementation for transport over BLE for iOS and Android.
Since then we have introduced features to the solution:
-
Ability to upgrade SoftDevices
-
Ability to upgrade Bootloader
-
Init packet for CRC-verification, version check etc.
-
UART as transport instead of OTA from external application controller
-
Dual and single banked solution
-
Experimental support for asymmetric signing of firmware
All this has been possible, thanks to the fact that the nRF51 is using flash. Now, we've raised the bar considerably. With SDK v12.0 we are introducing a reworked architecture and some significant improvements.
Let's walk through some of the highlights:
Signing of firmware
We believe that firmware signing is crucial for certain products. In short, signing of firmware is a way to ensure that the firmware upgrade that is pushed to its target has roots from the correct and verified sender, and only from this source.
Asymmetric keys contain of two keys: Private and public key. The private key is in this scenario, used to sign firmware. This is your key, and must NEVER be shared. The public key is the one that may be public. The public key is only able to read and de-crypt firmware that has been signed by the paired private key
The feature list above highlights experimental support for asymmetric firmware signing. With the new DFU solution, we are taking this feature out of experimental. A lot of effort has been done to done to allow you to enable this feature easily, leverage the freedom to use your favourite cipher and run efficient on relatively constrained devices.
Even though, we have made it easy to change cipher, we have included examples based on micro-ecc ECDH using the P258 curve. This is the same as used for Bluetooth Secure Connections.
New init packet format
Init packet, also known as DFU Command serialization is now based on Protocol Buffers (protobuf).
-
Used for signed hash
-
Version control
-
Etc...
Supporting tools
To have a complete DFU solution, it is crucial to have supporting tools. With this release, we are releasing a range of supporting tools and solutions to make it easy for you:
-
nRFUtility v1.0 to generate key pairs, sign firmware, generate init packet and prepare .zip-file that is ready to be distributed.
-
PC transport [need information on how, what]
-
Android and iOS libraries to easily include DFU transport and message parsing in phone applications – also available in source code
Nordic DFU service has its own 16 bit UUID
To make it simpler to work with Nordic DFU services, we have reserved 2x 16 bit UUID’s to be used for the new DFU service.
-
FE59 is reserved to indicate Signed firmware
-
FE58 is reserved to indicate Unsigned firmware
Resume from failure
If firmware upgrade for some reason fails in the middle of the process, we have added support to resume the process from the point of failure, instead of starting the complete update process from scratch. This improves efficiency and of course power consumption. This is also supported in the mobile libraries that we provide.
Prepared for the future
As Object Transfer Service (OTS) has been adopted by Bluetooth SIG, we have designed the new DFU architecture to be suited for this when it has been enabled in suited devices such as phones.
Freedom to choose
As you can hopefully see, we've made this all about allowing you to be able easily use your preferred solution for signing, transport and implementation.
To do this, we provide an architecture that makes it easy to enable signing, to use cipher of choice, transport of choice with a very flexible init packet. All this in source code in our nRF5 SDK v12.0.
Reference implementations in source code for iOS and Android makes it easy add DFU support to your mobile application.
To lower the entrance barrier, we do provide reference example in the SDK to illustrate how we are running this on our side.
Future plans
- Button-less DFU
- Additional transport protocols
Legacy DFU
Legacy bootloader is still available for download in older SDKs (v11.0 and older) . Both the updated iOS and Android DFU library will support legacy and old DFU from same library.
Supported PC tools are available through nRF utility.
Other features in nRF5 SDK v12.0
Secure DFU with signing is a major deal, and hopefully above we've given you a good scope-out of what is there and what this means for your development and future products.
But there is more to nRF5 SDK v12.0 and here's a quick list of what else you can expect to find there:
- Cortex-M4F floating point example (FFT)
- Continuous Glucose Monitoring Service (CGMS) for Bluetooth
- S132 v3.0.0 support
- S130 v2.0.1 support
- S212 v2.0.0 support
- S332 v2.0.0 support
- Capacitive sensor driver and library (csense)
- CMSIS DSP library support
- Gazell support on nRF52 (experimental)
That's all folks! Happy exploring!
