As Bluetooth® finds its way into ever more sophisticated applications, demands on the short-range radio hardware are constantly increasing, both in terms of performance and security. The nRF5340, one of Nordic Semi’s latest additions to its short-range radio portfolio, made major inroads on both of these fronts. The SoC, which is at the heart of the u-blox NORA-B1 Bluetooth 5.2 low energy module series, broke new ground as the world’s first wireless SoC to feature two Arm® Cortex®-M33 processors, at once meeting the needs of both ultra-low-power and high-performance. And by incorporating Arm’s TrustZone and Cryptocell-312, the nRF5340 takes the security of Bluetooth applications to the next level without sacrificing performance.
In an interview, Pål Kastnes, Technical Marketing Manager at Nordic Semiconductor, presents the nRF5340’s security functionality, why now was the right moment to bring it to the market, and what it means for customers and end-users.
The nRF5340 dual-core Bluetooth 5.2 SoC comes with new security functionality. Can you walk us through some of these features?
When we started with Bluetooth in the nRF51 series SoCs, we simply encrypted the link to the smartphone through the pairing process and this encrypts all data transfers on the fly. In the nRF52 series, we started to have enough horsepower to run advanced applications on the chip, for instance running a full TCP/IP stack with DTLS and TLS. Response times remained on the slower side, as TLS can require tens of seconds to set up a connection, which is power-hungry and becomes unacceptable if you have to do it every time you establish a connection. The nRF52840 SoC featured an ARM TrustZone® CryptoCell cryptographic unit, delivering improved security, but more importantly, a much better user experience.
With the nRF5340, we wanted to push it even further. Since we went with the Arm Cortex M33, we had the opportunity to implement Arm TrustZone to help customers make better, safer solutions. With TrustZone, devices can run everything related to security inside their own little bubble, separating the concerns. The security-critical functionality – handling the keys, provisioning, upgrading firmware – can be made in a smaller piece of code that the remaining application can interact with through a controlled, limited, and secure interface. This makes it easier for the developers, who, instead of reviewing a full megabyte of code for vulnerabilities, can just focus on the few kilobytes that take care of all the crypto functionality.
What are the biggest challenges in securing Bluetooth applications?
If you have a solution that runs on a static connection, for example, a wearable that connects to your phone, encryption basically costs nothing in terms of compute time and power, as it runs entirely on the AES (advanced encryption standard) engine. Then, from the phone to the cloud, you have an end-to-end encrypted link, where the devices on each end are doing the encryption. This requires you to have control of the phone and trust the software running on it, as it has full access to all data transferred. This is OK if it is your phone, but it is not so easy if it isn’t. Of course, if you have a device that keeps connecting to all the other units in the area and gets keys all the time, the cost goes up.
What really costs is when you move to cloud-connected solutions rather than “phone-to-X” solutions. With a wearable device, you typically wear it on your arm, and you carry it with your phone. As long as the connection from the phone to the wearable device is secure, nothing bad can really happen, because people need to pair with it, and to do so, take the device away from you to get access. But if you look at a smart lightbulb at home, it's connected to your home network all the time, so you need to make sure that if you try to do a firmware upgrade or other things, things just need to work.
When you go to the cloud, you go through an external network, so you need a way to set up a safe connection to the device with all the setup data used visible to everyone. Because of that, you need much more robust algorithms, which take more time to run. That hits you on power, because the more calculations you have to do, the more expensive it becomes, and the more time it takes.
In which market segments do you see the most demand for enhanced security?
It is being pushed primarily in applications in which the user is not involved most of the time, where you want to deploy devices all over the place, and when you want to have the possibility to do firmware updates securely. Concretely, this includes smart home solutions, and industrial applications, from the production floor to professional lighting, and health.
If you look at companies that take security very seriously, specs that come from them typically require a lot of cryptography and security built into the devices, because in order to make solutions private, you need to encrypt all communications end to end. Even though they are personal devices, they all connect back to your account. They may look like products from other vendors that connect to your phone, but they are actually cloud-connected.
What are some potential next steps in security that you see on the horizon?
Security is a never-ending page – it will never be finished. We started out with a normal processor, then we added Cryptocell, we went on to a TrustZone enabled device, again with Cryptocell. If you look at where Arm went, it is still embedded on the device, but they have introduced a separate CPU to run the Cryptocell, then added a SIM card implementation inside the device. They are continuously moving up the ladder – there is a progression. Ultimately, it’s about adding more and more layers to make it more and more difficult to get to the core.
It’s always a balance. If we build the safest solution on the market, it will add so much to the cost that the product will not be viable, and the customer won’t adopt it. But we are preparing solutions so that they are ready when customers want them.
Ultimately, the level of security you are aiming for should always be a conscious choice when you start a project. Building security from the get-go is a lot easier than patching it into a complete solution in the end. Patching it in in the end always fails.