Securing Amazon FreeRTOS devices at scale with Infineon OPTIGA Trust X

Post by David Walters, Senior Partner Specialist Solutions Architect, IoT at Amazon Web Services, and Artem Yushev, Applications Engineer, Embedded Security Systems, at Infineon.

One of the most significant challenges for device manufacturers developing new microcontroller-based IoT devices is how to manufacture and provision those devices at scale without compromising security.

In this blog post, we explore the options, considerations, and challenges for manufacturing IoT devices at scale. We examine how Amazon FreeRTOS provides security on the device. You learn how the secure provisioning model with AWS IoT Core and Amazon FreeRTOS can scale to millions of devices with the help of AWS partners like Infineon.

First, we examine how AWS IoT authenticates devices to connect to the platform with X.509 certificates.

AWS IoT certificate-based authentication

AWS IoT uses Public Key Infrastructure (PKI) and Transport Layer Security (TLS) with X.509 certificates to authenticate devices connecting to the platform.

In a previous blog post, Setting Up Just-in-Time Provisioning with AWS IoT Core, we outlined the just-in-time provisioning (JITP) process. If you aren’t familiar with JITP, we recommend that you spend some time familiarizing yourself with the process before reading on.

There are several certificates required to connect to AWS IoT Core using JITP. Some certificates are held on the device and others in a secure physical location on-premises.

Amazon Trust Services (ATS) Endpoint Certificate

The ATS certificate is signed by a certificate authority (CA) owned by Amazon. When the device first connects to AWS IoT Core, this certificate is used by the device to verify that it is actually connecting to the AWS IoT server.

CA signer certificate

The device manufacturer’s designated CA signs the CA signer certificate. It is uploaded to AWS IoT to verify each device provisioned using the JITP process.

The CA signer certificate’s private key should always be held in a secure location, on a hardware security module, in the factory or on-premises. You should exert control over who in your manufacturing and production supply chain can access the private key. If compromised, an attacker could use the CA signer certificate’s private key to issue additional device certificates.

Device certificate

Each device needs a uniquely generated device certificate, sometimes referred to as a client certificate, signed by the CA signer certificate’s private key using a certificate signing request (CSR). The device certificate includes a public key and is signed with the CA signer certificate.

When the device connects to AWS IoT for the first time, AWS IoT verifies that the device certificate has been signed with the CA signer certificate.

On some occasions, there may be a chain of certificates from the signer certificate to the device certificate.

Securely manufacturing IoT devices

At a certain point in your product development lifecycle, you are confident in your application and device design. Consider how you manufacture thousands, hundreds of thousands, or even millions of devices using the AWS IoT PKI model.

Secure elements

Secure elements provide tamper-resistant storage of private keys, certificates, and other data, as well as a host of cryptographic functions that can be performed on the module rather than in software.

Using a secure element ensures that the sensitive crypto elements are never exposed to the main microcontroller and application. In addition, power-constrained devices can benefit from running cryptographic functions on a secure element, because the cryptographic functions are more power efficient and several times faster than in software.

Choosing a CA

You may choose to use your own CA, a partner’s CA, or the ATS endpoint certificate provided by Amazon. If you choose to use your own CA, you must put the proper security measures in place to ensure that your root certificate is never compromised.

Device certificate generation and provisioning

Developers often start developing their IoT devices with the security credentials baked into the firmware of the device. This approach is fine for prototyping and testing, but it‘s difficult to create custom firmware images for a large number of devices.

In a production scenario, it’s common to generate and inject the device certificate and private keys at manufacturing time. Implement a delivery mechanism and the ability to write those credentials to a secure place on the microcontroller. With this method, take extra care to ensure your CA Signer Certificate and device certificate private keys are not compromised in transit.

If you have a secure element on your device, it may be possible to generate the device certificate’s private key on the secure element. This means that your private key is never exposed to the factory, reducing the risk of your device credentials being compromised in transit.

Secure storage of certificates

Consider how to secure those credentials at rest on the device. You may choose to store them in an area in the microcontroller flash that is programmed one time, and never rewritten (One Time Programming, OTP), or a write-protected flash memory sector. A secure element can be used to store the certificates when tamper-resistant security is needed.

Amazon FreeRTOS

Amazon FreeRTOS (a:FreeRTOS) is an open-source operating system for microcontroller devices. Amazon FreeRTOS uses the real-time operating system FreeRTOS at its heart. The service adds in numerous additional libraries such as Bluetooth Low Energy, over-the-air (OTA) updates, an MQTT client, and all of the necessary security libraries to connect, secure, deploy, and manage the device.

In this post, we focus on the PKCS #11 library as it relates to managing the security of your devices.

PKCS #11

PKCS #11 is a standard that defines an API for security object lifecycle including retrieving and creating security objects like private keys and certificates. Amazon FreeRTOS uses PKCS #11 to access and modify security tokens to perform operations such as Transport Layer Security, OTA updates, and provisioning.

Amazon FreeRTOS provides two ways for device manufacturers to leverage PKCS #11: software implementation and hardware secure elements.

PKCS #11 software implementation

The software implementation of PKCS#11 works under the assumption that your security tokens are held on a specific area in flash on the microcontroller. All cryptographic operations are done in software inside Amazon FreeRTOS with mbedTLS, as shown in the following diagram. This area in flash should never be written to after programming the device, and is preferably write-protected.

PKCS #11 interface with secure elements

Amazon FreeRTOS provides a PKCS #11 API that can be implemented to interact with a secure element, as shown in the following diagram. The application simply calls these PKCS #11 APIs to perform actions like TLS handshakes or decryption of data, and the API makes the appropriate calls to perform the action on the secure element.

Infineon OPTIGA Trust X with Amazon FreeRTOS

OPTIGA™ Trust X by Infineon is a turnkey secure element solution based on a high-end security microcontroller, shown in the following image.

This secure element natively supports the following crypto primitives:

• Four slots to store user credentials such as a device certificate and a corresponding private key
• Two certificate slots to store trusted certificates such as the ATS endpoint certificate
• Up-to 4.5 kBytes user provided data (excluding storage for certificates and private keys
• Elliptic cryptography (EC):
  • Key-pair generation for NIST P-256/P-384 curves
  • Signature generation and verification for EC Digital Signature Algorithm (ECDSA)
  • Shared Secret generation using EC Diffie-Hellmann (ECDH)
• True and deterministic random number generation
• I2C interface
• Common Criteria certified EAL6 + hardware

Integration with Amazon FreeRTOS

Infineon has implemented the PKCS #11 APIs in Amazon FreeRTOS to interface with the OPTIGA™ Trust X. Amazon FreeRTOS provides a reference example of the integration of the OPTIGA™ Trust X with the XMC4800 Connectivity Kit development board.

In addition, Amazon FreeRTOS provides a demo application with instructions to provision a secure element with the correct certificates and private keys to connect to AWS IoT Core.

Next, we examine how a single OPTIGA Trust X chip registers with AWS IoT and uses the ATS endpoint CA to generate device certificates, as shown in the following diagram.

The process is as follows:

• Generate a new key pair on the OPTIGA Trust X and export the public key.
• Generate a CSR.
• Send the CSR to the AWS IoT server
• AWS IoT constructs a new certificate based on the CSR and signs it with the ATS endpoint CA
• AWS IoT sends the resulting certificate back to the user.
• The received certificate is written in the OPTIGA Trust X and linked to the private key slot.

This process demonstrates how the OPTIGA Trust X can be provisioned for devices in small numbers by a manual process.

Infineon secure manufacturing

When you are ready to manufacture your devices at scale, Infineon is able to pre-provision your OPTIGA™ Trust X secure elements in their security certified manufacturing facility.

Pre-enrolling all OPTIGA Trust X secure elements removes the complexity and security challenges that come with maintaining the certificate infrastructure in the AWS IoT PKI model. When you place the secure element chip on your device in the manufacturing process, your devices are ready to connect to AWS IoT and you know your devices were provisioned in a highly secure environment.

Infineon takes extra precautions to protect all sensitive security tokens from being leaked or exposed during the provisioning process. The OPTIGA Trust X is Common Criteria EAL6+ certified and the personalization process is covered under this certification. The CC certificate can be found at www.bsi.bund.de by searching for BSI-DSZ-CC-0961 (Hardware Identifier IFX_CCI_00000Bh).

JITP with secure elements

Infineon’s secure manufacturing process, along with JITP, enables your devices to connect to AWS IoT at scale when using OPTIGA Trust X secure elements. This is accomplished with the process shown in the following diagram and outlined below.

The process is as follows:

• Infineon creates a new dedicated CA issued by the Infineon root CA.
• Using this new CA as the signer, Infineon securely provisions all OPTIGA Trust X secure elements with the necessary device certificates and private keys. The device certificate is set to read-only access and the private key will never leave the secure element.
• Infineon sends the provisioned OPTIGA Trust X secure elements to you along with the CA certificate.
• You will register the CA Certificate with AWS IoT.
• AWS IoT requires proof of possession of the private key for the CA certificate, so must send this request back to Infineon. Infineon provides this registration certificate while preventing the private key from being exposed.
• You use the registration certificate to complete the CA registration procedure on AWS IoT and set up a bulk provisioning template per the JITP process.

All of your devices with an OPTIGA Trust X can now be connected and provisioned to AWS IoT using JITP.

Conclusion

Managing your devices to remain secured and that your process for securing those devices is scalable up to millions of devices is a challenge. When using X.509 certificates with AWS IoT, consider who has control of your certificates and how you can generate millions of unique device certificates without compromising on security. You also must consider how the private keys are stored on the device to prevent sophisticated attackers from compromising the keys.

With APN Partners like Infineon, Amazon FreeRTOS provides integration with secure elements using the open standard PKCS #11 interface. Infineon’s OPTIGA Trust X secure element provides tamper-resistant key generation and storage of your device certificate.

Using the JITP feature in AWS IoT, you can quickly register all of the certificates provided by Infineon by using their secure manufacturing process. Your certificates will be provisioned in an environment you can trust. Each of your production devices is protected against sophisticated tampering attacks, and you are able to quickly on board a large fleet of devices at scale.