How to Use Microsoft® Azure® RTOS and the ATECC608 TrustFLEX Secure Element
Microchip Technology Inc.Microchip Technology Inc.
Do you use Microsoft Azure RTOS, the ATECC608 or TA100 secure elements and want to implement a secure boot and TLS mutual authentication for your Internet of Things (IoT) device? If so, you are at the right place.
The IoT chain of trust from the embedded device to the Azure cloud security is composed of various layers. In this blog post, we will focus on establishing the most foundational concept, the root of trust, which is composed of the secure boot function and a TLS mutual authentication using Microsoft Azure Real Time Operating System (RTOS) and the ATECC608 TrustFLEX secure authentication Integrated Circuit (IC).
To start, how do you implement some level of secure boot when your IoT device uses a standard microcontroller (MCU)? Well, this is where a secure element like the ATECC608 or TA100 can come in handy. Granted, there is no bootROM in this case, but between no secure boot and a secure boot with an isolated public key inside a secure element for verification, the threat model and the business conditions will likely favor the secure element-based design. In our case, we will be using the traditional SAME54 Arm® Cortex®-M4-based MCU and the ATECC608 TrustFLEX secure element add-on board for the hardware representing the IoT end node. Now, if your end node requires multi-threading and needs Azure RTOS to benefit from all the Azure-related embedded API, how does the communication between the MCU and the secure element work within this RTOS environment? We need to look at PKCS#11.
PKCS#11 stands for Public Key Cryptography Standards number 11. It is an interface to trigger cryptographic operations that will leverage secrets (the keys). In simple terms, it is a standard interface between an operating system and a Hardware Security Module (HSM). The HSM in our case is the ATECC608 and—you guessed it—the OS is Azure RTOS.
Microsoft Azure has conveniently integrated the PKCS#11 interface inside its Azure RTOS.
Cryptographic commands will go through Azure RTOS to PKCS#11 but there is an intermediate library needed: Microchip CryptoAuthLib. This library makes the secure element agnostic of the MCU or processor. CryptoAuthLib already supports calls from a PKCS#11 interface and translates them into low-level commands to the ATECC608 TrustFLEX or TA100 secure element as shown in the graphic below.
The embedded system needs to perform an Elliptic Curve Digital Signature Algorithm (ECDSA) verifywith the public key associated to the private key which signed the code. The public key in the ATECC608 TrustFLEX TLS configuration is illustrated below. When you download Trust Platform Design Suite (TPDS), you can access it with no NDA.
Something to know is Microsoft Azure offers a “Device Update” service, where you can use a pre-generated public/private key pair where the private key is ideally protected in an HSM and the Device Update performs the sign operation of the code and creates a signature as the output. The public key associated to the signature would be provisioned (securely programmed) into Microchip ATECC608 TrustFLEX slot 15 using Microchip secure key provisioning service. The TPDS will navigate you through the onboarding process. The private key which signed the code should never leave the company HSM nor should be provided to any Contract Manufacturers (CMs). Remember, security is a shared responsibility model. Now we have a signed code that will be loaded by the CM from Device Update in each MCU during manufacturing. We will provision the public key inside its secure elements, either the ATECC608 TrustFLEX or TA100, using our HSM-equipped factories. The CM will also assemble the already provisioned secure element and keys won’t be exposed to the supply chain. Now, the IoT device company can remain flexible with the CM of their choice.
After taking care of the secure boot comes the mutual authentication between the embedded device and the Azure IoT Hub. Before pushing data to Azure IoT Hub, the embedded device will need to trust the cloud and vice versa. The IoT device will mutually authenticate with Device Provisioning Service (DPS). The manifest file provided by Microchip, which contains the certificates associated to the private key solicited by the TLS mutual authentication, is uploaded in DPS. DPS now has the list of public keys and can verify the signature issued within the secure element of the embedded system to finalize the chain of trust. The chain of trust is constituted of both the secure boot and mutual authentication where the public key of the secure boot and the private key of the TLS mutual authentication are protected and isolated from code, people and manufacturers all the way through the development and deployment of embedded device. DPS then communicates confidently to Azure IoT Hub based on a trusted IoT device via NetX TLS also supported and provided by Azure RTOS.
The TLS mutual authentication relies on a Public Key Infrastructure (PKI) that can be static or managed. For static PKI, Azure accommodates any root certificate companies such as Digicert, GlobalSign and more. For managed PKI, device management services are available from Microchip security partner companies such as Crypto Quantique, KeyFACTOR and Kudelski. Their API can plug directly into the Azure cloud environment to revoke, rotate and audit your certificates.
When it comes down to the TrustFLEX for TLS secure elements, they can do more than the two previously mentioned use cases and address a variety of use cases such as:
To summarize, you can access the entire project including Azure RTOS with a PKCS#11 implementation to implement a secure boot and mutual authentication using the pre-configured ATECC608 TrustFLEX and Microchip secure provisioning service. Download the latest version of TPDS and try the Azure RTOS use case and C-code project. Remember to contact your Microchip local security expert and check out the Design Week webinar with Azure Expert Tim Stapkov.
New Podcast Episode
Related News