How to Create a Secure Google to IoT Core Connection with MAXQ1065

Introduction

Over the last 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. The easy access to the internet and the advances in technology and communications opened the door to manage the 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 are expected. A secure environment is required to avoid a catastrophic event. This article shows how to use the MAXQ1065 with Google IoT Core to create this secured 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 Crypto 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 via Tamper IN
  • Field upgradeable
• Secure storage
  
  
  • ChipDNA protection + Die Shield, tamper detectors
  • 8KB dynamic filesystem (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 slave, with secure channel
• -40/+105°C, 1.8V/3.3V operation, 100nA shutdown mode (**)
• 12-TDFN 3 × 3mm pitch 0.5mm

Google IoT Core Description

The Google IoT Core is an IoT device management, authentication, and communication facility. IoT node devices (directly or through a Gateway) connect to the Google IoT Core server. Usually, a TLS connection is established to authenticate the Google IoT Core server. The devices are rather authenticated with the JSON Web Token (JWT) protocol.

Basics

IoT devices (directly or through a Gateway) connect to the Google IoT Core server. Before to allow connection with the Google IoT Core, each device needs to establish a Transport Layer Security (TLS) session with the Google IoT Core server. This TLS session establishment creates a shared symmetric key for the authentication, integrity and encryption of the communication, and gives a guarantee to the IoT device that it is connected to a legit server. In addition, the server also securely identifies the IoT device using the JWT protocol once the TLS session is initiated. After this secure mutual authentication occurs, a regular HTTP or MQTT traffic can flow through the established TLS session.

The JWT authentication relies on a customer-defined root certificate and key pair (JWT_CA certificate and JWT key pair). IoT devices are grouped into so-called "registries" from the server standpoint, and each registry is defined by its own JWT_CA certificate. All devices belonging to a registry must confirm their identity by proving ownership of a JWT certificate issued by the registry-attached JWT_CA private key. Every device has its own JWT key pair, and a JWT certificate issued by the 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 https://cloud.google.com/iot/docs/create-device-registry and follow the tutorial "Create an IoT Core device registry" and proceed up to the step "Create a device registry" (included).

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 '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 Google IoT Core registry.
   
   
   1. Open the generated certificate file 'cert_CA.pem' and copy its content.

   

   

   2. Go to the Google Cloud into the "IoT Core" panel.

   

   3. Select the right registry.

   

   4. Under the selected registry, click the "CA Certificates" drop-down menu.

   

   5. Click ADD CERTIFICATE button.

   

   6. In the Add CA certificate window, in the Certificate value box, paste the content from the file "cert_CA.pem" and click ADD.

   

   7. The certificate is added to the registry and used to authenticate the IoT node devices featuring the MAXQ1065. Now the MAXQ1065 must be provisioned with a device specific certificate. For more details, see the Provision the Device (MAXQ1065) section.

   

Provision the Device (MAXQ1065)

The 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_googleiot script. This script provides an example of each of the next steps. Here is the procedure. For every single device, the 'init_tls_googleiot' script perform 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 Google IoT core server, and more specifically, it belongs to the registry which is defined by the root JWT_CA certificate used to issue the device's certificate.

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

5. Obtain the Google IoT TLS Root Certificate (GTS LTSR Cert) or Certificate GS Root R4 as a backup from:
   
   
   1. https://pki.goog/gtsltsr/gtsltsr.crt
   or
   
   2. https://pki.goog/gsr4/GSR4.crt
6. Load the Google IoT TLS Root Certificate into the MAXQ1065 memory.

Register the Device on Google IoT Core

Every time a client device connects to the Google IoT core server, its identity must be securely verified by the server. By pre-registering every single device into the Google IoT registry, further authentication is made faster and simpler. Indeed, each device's certificate is loaded into the Google 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 Google 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 actually 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 single device needs to be registered into the Google IoT Core server by following this process.

Add a device named 'EXAMPLE_DEVICE' into the registry by using the Google IoT GCP console:

gcloud iot devices create EXAMPLE_DEVICE --project=maximiot-224510 --region=us-central1 --registry=my-registry --public-key path=csr_cert.pem,type=es256-x509-pem

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

Running the Device

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

1. The device verifies the Google IoT Core server certificate using its local Google IoT TLS 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 Google IoT TLS root certificate that is 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 Google 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 23 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.

The client device once 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.

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/.

A user can execute the entire process mentioned above with the SDK's example provided in the "google_iot" folder:

./iot_core_mqtt_client -p maximiot-224510 -d projects/maximiot-224510/locations/us-central1/registries/my-registry/devices/EXAMPLE_DEVICE -t /devices/EXAMPLE_DEVICE/state

Provisioning Options

For an easy deployment, ADI offers an out of the box factory secure programming service. For more information and the minimum requirement, contact an ADI sales representative.

Figure 26 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 allow 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.

As an aside, the pre-programming 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 to implement provable security in embedded devices at a reasonable cost.