Is the Secure Element always needed on securing IoT/Embedded designs?

Cloud IoT providers raised the bar for IoT security by introducing authentication via digital certificates for cloud connected devices. In other words, the device needs to present a digital certificate to authenticate with the Cloud IoT enablers such as AWS IoT and the back-end will use the actual certificate to precisely identify a connected device – a cryptographically strong ID.

These requirements translate into an increased demand for IoT devices equipped with unique device certificates, capable of performing mutual authentication and secure connectivity. The industry found an easy solution to augment existing non-secure MCUs/MPUs using readily available components. The Secure Element (SE) provides an easy to deploy solution to fulfill the requirements presenting several advantages such as:

·      can be pre-programmed - in volume, as bare component

·      strong physical security with protection against a variety of attacks

·      small footprint, very low power

·      small impact on existing board designs

The SE has shaped its use on fulfilling the following functions:

·      Provide strong identity and mutual authentication

·      Provide the secure key agreement function for SSL\TLS session encryption\decryption

·      Protect keys and certificates at rest

The above capabilities make the secure element a recommended hardware companion for most MCUs which embed little or no HW security. However, the design needs careful considerations. In such design, the security binding is established between the secure element and the remote server (see figure below) while applications are running in the microcontroller (CPU). In most designs the connection between the CPU and the SE is not secured or protected making man-in-a-middle attacks very easy. The way to counter this shortfall would be to secure the communication between the SE and the CPU but then the CPU must support a minimum set of security features like the ones present in the SE. The CPU must at least have the capability to securely store a symmetric key that would be shared with the SE. At this point the design\logistics gets complicated because both the CPU and the SE need to be provisioned with secrets before or during manufacturing of the boards.

In a secondary use case scenario, the SE steps into the role of the 3rd party entity that validates the boot image of the CPU during boot thus contributing to the Secure Boot architecture. Once again, the communication between the CPU and the SE needs to be secure and the SE needs to be securely provisioned.

The Secure Element presents yet another risk – being a separate hardware element it can be removed and reused; therefore, secrets become portable and enable counterfeit products.

However, for proper use cases and with proper design the SE will significantly boost security for many MCU or MPU designs. The SE also benefits from a good software support from the silicon providers and the ecosystem partners.

But what are the use cases where the SE promises come up short on delivery?

There are few aspects to consider when recommending or adding a Secure Element to a project.

1.      It is slow and its interface is slow. The interface to the SE is typically provided via an I2C interface and therefore one should not expect any data throughput higher than a theoretical 400kbps. This is in line with the processing speed and it marks the territory for where the SE must be used. For example, it is OK to secure communications for low bandwidth connections such as LoRaWAN, LTE-NB etc. In the case of high throughput TLS connections, the SE cannot perform session key refreshing and encryption/decryption at the required speed.

2.      Trusted execution capabilities are very limited. The SE usually supports a small fixed set of crypto operations with a limited number of modes. For example, a usual set of capabilities would be: AES 128, SHA-256 for symmetric operations and 2-3 elliptic curves for asymmetric operations (sign, verify, key agreement).

3.      Must be provisioned – provisioning of a Secure Element or any other secure silicon introduces logistics problems, requires secure facilities and these all lead to higher cost.

4.      It is intended to be programmed once and not be managed – even if the SE can be managed by an external part, doing so securely requires a secure CPU next to it

5.      Firmware cannot be updated

The use case for adding a Secure Element to a board design incorporating an Arm MPU that embeds TrustZone and secure boot (such as NXP i.MX and QorIQ Layerscape) is very limited.

Arm TrustZone if implemented correctly, provides the fundamental hardware isolation and the computing capability to fulfill use cases that the Secure Element cannot. In many MPU designs TrustZone is augmented with cryptographic hardware for symmetric and asymmetric operations, random number generator, active tampers, scrambled memories etc. which creates a very rich trusted execution framework not just for cryptography but also for building resilience in designs and running custom code securely significantly contributing to intellectual property protection.

The true number generator embedded in the MPU has enough entropy to be used for key generation during runtime but also during secure firmware provisioning. Thus, keys can be generated on the fly to encrypt firmware images uniquely for each device and to generate device identities. This way device manufacturers do not need to inject keys from an external HSM but only to extract public keys for records or for provisioning the Cloud IoT.

Keys and digital certificates injected at manufacturing for various other use cases would be stored encrypted in the NVM since most MPU designs do not incorporate storage in the die. One problem with this approach is that if the NVM fails or is erased then the key material is lost. OEMs must design devices to protect or recover in such use cases. One option would be to use a Secure Element for permanent\safe key storage. However, it is recommended that the Secure Element be made available as a secure peripheral and therefore out of the reach of the operating system.

To summarize, the Secure Element has a role in securing today's IoT and embedded designs, but it should not be used or recommended on all designs as a one solution that solves all use cases. There is also a hidden cost associated with real time implementations - from board design changes to logistics. When a design includes an MPU with embedded security then the augmentation of capabilities with a Secure Element need to be considered carefully. Such an MPU can surpass easily and for many cases the benefits of the Secure Element.

Real use cases for adding the SE to a secure MPU (i.e i.MX7, 8, Layerscape, RT) come true when a key vault is needed to add redundancy to the flash. Such high level of resilience is suited for use cases in aviation, military, self-driving control, sensitive industrial environments but not for the mass market IoT designs in smart home, smart buildings, connected car, smart cities etc.