AN-7648: How to Create a Secure AWS IoT Core Connection with MAXQ1065

Introduction

Over recent years, the number of smart devices has grown exponentially. The complexity of their design and functions has provided numerous features that have simplified our lives. Easy access to the internet and advances in technology and communications have opened the door to manage remote devices at any time and from anywhere without the need to be physically present at the device location. However, as more and more devices become interconnected, the risk of data manipulation, unauthorized access, and security breaches is expected. A secure environment is required to avoid a catastrophic event. This article shows how to use the MAXQ1065 with AWS IoT Core to create this secure environment and explains how to generate the required certificates and keys, describes their usage, and provides a real-life example of a basic secure connection and setup. The MAXQ1065 SDK is referred to in this application note to generate keys, certificates, device provision, and tests. The SDK is available upon request.

MAXQ1065 Features

• Fixed-function IC for embedded device security
• Security functions
  • (D)TLS 1.2, generic SP800-56r3 ECC DH key exchange
  • Generic cryptographic toolbox for authentication, confidentiality, attestation unique ID secure boot/secure update
  • External watchdog function with configurable timings
  • Reset output (selectable events)
  • Power-ON tamper detection through tamper input pin (IN)
  • Field upgradeable
• Secure storage
  • ChipDNA protection + die shield, tamper detectors
  • 8KB dynamic file system (10K cycles) with customizable security attributes
  • Secure key management and life cycle, x.509 support
• Hardware crypto engines
  • SHA-2-256
  • ECC (NIST P-256)*: ECDSA, ECDH
  • AES-128/256 (GCM, CBC, ECB, CCM)
  • NIST SP800-90A/B/C ready TRNG
• 10MHz SPI peripheral, with secure channel
• -40°C/+105°C, 1.8V/3.3V operation, 100nA shutdown mode (**)
• 12-pin TDFN, 3mm x 3mm, pitch 0.5mm

AWS IoT Core Description

AWS IoT Core is a platform for managing, authenticating, and communicating with IoT devices. IoT devices connect to the AWS IoT Core server, either directly or through a gateway. Typically, a TLS connection is used to authenticate the server, while the devices themselves are authenticated using the JSON Web Token (JWT) protocol.

Basics

Before IoT devices establish a connection to the AWS IoT Core server, either directly or through a gateway, each device must initiate a Transport Layer Security (TLS) session with the AWS IoT Core server. This TLS session creates a shared symmetric key, ensuring authentication, integrity, and encryption of the communication. It also provides a guarantee to the IoT device that it is connected to a legitimate server.

Once the TLS session is established, the server securely identifies the IoT device using the JSON Web Token (JWT) protocol. After this mutual authentication is complete, regular HTTP or MQTT traffic can flow securely through the established TLS session.

JWT authentication relies on a customer-defined root certificate and key pair, known as the JWT_CA certificate and JWT key pair. From the server's perspective, IoT devices are organized into groups called "registries," where each registry is defined by its own JWT_CA certificate. All devices within a registry must verify their identity by proving ownership of a JWT certificate issued by the JWT_CA's private key associated with that registry. Each device has its own JWT key pair and a corresponding JWT certificate issued by the registry's JWT certification authority (JWT_CA).

Note: All certificates must be in X.509 v3 format, encoded in the Privacy Enhanced Mail (PEM) format, which is a DER format encoded into base64 and wrapped between the BEGIN CERTIFICATE----- and-----END CERTIFICATE delimiters. The JWT_CA private key must be in the PEM format, encrypted with at least 128 bits of security. The readers need to refer to standards such as PKCS#8 that define the private key encryption techniques. The JWT_CA private key allows to generate “valid” devices; therefore, it is essential to preserve its secrecy and strictly control its usage.

Preparation

Before proceeding, refer to the AWS IoT Core documentation and follow the tutorial "Managing things with the registry.” Complete the steps up to and including "Detach a principal from a thing."

Authentication Setup

Create the JWT_CA root certificate (and private key) attached to the registry. The MAXQ1065 SDK includes the ‘make_ca_cert’ script that generates a self-signed certificate and key required for this sequence.

Required Steps

1. Execute the ‘make_ca_cert’ script:
   1. It generates and saves the JWT_CA private key into the file ‘cert privkey_server_ECDSA_secp256r1_secp256r1.pem’. It is used later to issue device specific certificates that are stored in the MAXQ1065 memory.
   2. It also generates the self-signed x509 JWT_CA certificate using the generated JWT_CA private key into the file ‘cert_CA.pem’.
2. Upload the generated JWT_CA certificate to AWS IoT Core registry.
   1. Open the generated certificate file ‘cert_CA.pem’ and copy its content.

      

   2. Go to the AWS Console into the IoT Core panel.

      

   3. Under Security, click the Certificates button.
   4. Click the Add Certificate button and click on Register certificates.

      

   5. In the Register certificates window, click CA is not registered with AWS IoT. Click the Upload button, upload ‘cert_CA.pem,’ and then click Register.

      

   6. On the Certificates page, select the certificate registered by clicking the checkbox next to the certificate. Click on the Actions dropdown, then click Activate to activate the certificate.

      

   7. The certificate is added to the registry and activated. It can now be used to authenticate the IoT node devices featuring the MAXQ1065. Next, as detailed in the Provision the Device (MAXQ1065) section, the MAXQ1065 must be provisioned with a device-specific certificate.

Provision the Device (MAXQ1065)

Device provisioning creates the device-specific key pair and issues its certificate using the JWT_CA private key.

To achieve this process, the MAXQ1065 SDK includes the ‘init_tls_iot’ script. This script provides an example of each of the next steps shown in the following procedure. For every individual device, the ‘init_tls_iot’ script performs the following steps:

1. Generate a device key pair (JWT private key and JWT public key) within the MAXQ1065.
2. Read out the generated device public key.

   

3. Certify the generated JWT public key with the JWT_CA private key.
4. Load back the device JWT certificate (csr_cert.pem) into the device (more specifically, into the MAXQ1065 memory).

   

Now the IoT device has its own JWT authentication keys and the associated certificate. Therefore, it can be authenticated by the AWS IoT Core server and, more specifically, it belongs to the registry that is defined by the root JWT_CA certificate used to issue the device’s certificate.

The additional steps below consist in loading the AWS IoT root certificate into the client device, which allows the device to authenticate the AWS IoT core server during the TLS handshake, and to make sure it is connected to the authentic AWS IoT server and not an unknown server. These steps are also performed by the same ‘init_tls_iot’ script:

1. Obtain the Amazon Root CA 3 from: https://www.amazontrust.com/repository/AmazonRootCA3.pem
2. Load the Amazon Root CA 3 into the MAXQ1065 memory.

   

Register the Device on AWS IoT Core

Every time a client device connects to the AWS IoT core server, its identity must be securely verified by the server. By preregistering every single device into the AWS IoT registry, further authentication is made faster and simpler. Indeed, each device’s certificate is loaded into the AWS IoT server registry once, upon registration. Verification of the device’s certificate using the registry’s JWT_CA certificate is performed at that stage. The AWS IoT core server uses the registry’s certificate JWT_CA to verify that the JWT certificate coming from the client device (certificate is stored in the MAXQ1065) is issued with the JWT_CA private key. Then, whenever the device connects to the IoT server, no further transmission and verification of its certificate is required. The server simply identifies the device, makes sure it belongs to the registry, and requests a JWT authentication to confirm its identity.

Every individual device needs to be registered into the AWS IoT Core server by following this process.

1. Upload ‘csr_cert.pem’ to AWS IoT Core > Security > Certificates > Register certificates, as shown in Figure 6.
2. Add a device named ‘EXAMPLE_DEVICE’ into the registry by using the AWS CloudShell:
   1. aws iot create-thing --thing-name EXAMPLE_DEVICE
   2. aws iot attach-thing-principal --thing-name EXAMPLE_DEVICE --principal arn:aws:iot:{Certificate ARN}

      

Here, the JWT device certificate provided in the command line above (file named csr_cert.pem) is verified by AWS IoT Core using the JWT_CA certificate uploaded previously.

Running the Device

Connecting the device to the AWS IoT Core server follows this process:

1. The device verifies the AWS IoT Core server certificate using its local Amazon root certificate.

   

   1. The server sends its certificate to the client (also known as the device).
   2. The client verifies the server certificate using the Amazon root certificate that was previously loaded into the MAXQ1065 during the provisioning stage. The verification of that certificate occurs within the MAXQ1065.
   3. The MAXQ1065 extracts the server public key upon success and stores it for future use.

      

2. The device authenticates itself to the AWS IoT Core server.

   

   1. The server creates a new ECDHE key pair.
   2. The server signs the ECDHE public key and a random number coming from the MAXQ1065 using the server private key and sends the signed ECDHE public key back to the device.
   3. The device’s MAXQ1065 uses the server public key decoded from the server certificate to verify the signature of the incoming data from the server. The server public key is verified and decoded in the previous step and stored in the MAXQ1065.
   4. If the signature is verified, it proves the identity of the server, then the ECDHE public key is kept internally for the next step.

      

3. Perform ECDHE key exchange. Derive session keys.

   

   1. The MAXQ1065 creates a new random ECDHE key pair.
   2. The private ECDHE key gets combined with the authenticated server’s ECDHE public key.
   3. The combination gives a shared secret on both ends (device and server). The shared secret is further derived into AES session keys.

      

4. Perform application layer security. Encrypt/decrypt packages using session keys.
   

   Figure 20 shows the TLS communication once the session is established. When the server sends a message (e.g., a response to the request) to the client, the server encrypts and signs its message using the AES session keys.

   

   Once the client device receives the TLS packet from the server, the device’s main microcontroller then inputs the TLS packet into the MAXQ1065. The MAXQ1065 decrypts and verifies the TLS packet using the previously established session keys and returns it in the clear to the main microcontroller. The same process is applied for the other direction of communication.

   

5. Authenticate the client.

   

   After the TLS session is established, the client device authenticates the server, but the server is not yet authenticated by the device. This additional step is performed to complete the mutual authentication.

   The client device generates a JWT and signs it by using its own JWT private key. The server then verifies this signed token using the client’s JWT certificate. Here is the detailed process:

   1. The server sends a challenge (a random number) to the client.
   2. The client uses the MAXQ1065 to sign the challenge using its JWT private key.
   3. The client sends back the signature and the client JWT certificate.
   4. The server verifies the client’s JWT certificate using the JWT_CA certificate and takes the client’s public key from it.
   5. The server verifies the signature of the challenge using the trustworthy public key from the client’s certificate.
   6. If the signature is verified, it proves the client actually owns the private key that matches the public key present with its certificate.

For more information on JWT, refer to https://jwt.io/.

Provisioning Options

For easy deployment, Analog Devices offers an out-of-the-box factory secure programming service. For more information and minimum requirements, contact an Analog Devices sales representative.

Figure 24 shows the common flow for this service.

Conclusion

The IoT devices are by nature exposed to attackers as they may be unattended or not deployed within secure facilities. It makes it easier for attackers to carry invasive attacks in an attempt to obtain cryptographic keys from those devices. Obtaining the keys allows an attacker to impersonate a device or replace its firmware to create botnets, which can be the building block for large-scale attacks on networks.

The MAXQ1065 secure cryptographic coprocessor enhances the security of connected embedded systems by adding securely implemented cryptographic functions and secure key storage to any microcontroller running an embedded system or IoT application. In particular, the MAXQ1065 ChipDNA PUF technology provides an exponential increase in protection against the invasive and reverse engineering attacks that hackers apply on integrated circuits to extract the credentials. Any attempt to prove or observe the ChipDNA operation modifies the underlying circuit characteristics, which prevents the discovery of the unique secret that protects the connection credentials to an IoT cloud infrastructure. Additional features of the MAXQ1065 can enable a mandatory device firmware verification before the connection credentials are made available for use, which guarantees that the device is running a legitimate firmware before connecting to the IoT cloud server. Likewise, data encryption keys may be locked in until the device is actually deployed in the field, which protects the sensitive data during the manufacturing and shipment phases.

The preprogramming of keys and certificates into the MAXQ1065 makes further enrollment of IoT devices to the cloud infrastructure instantaneous and even more secure. The IoT device can be manufactured without environment security requirements, but the pre- provisioned MAXQ1065 IC comes already secure with the connection credentials locked in.

The MAXQ1065 raises the bar for an attacker and allows implementation of provable security in embedded devices at a reasonable cost.