Edge Computing Security: Device Attestation Enabling Zero-Touch-Onboarding At Scale

This post is part 4 of the series. Read part 1 here / Read part 2 here / Read part 3 here

A recent white paper published by Infineon, Globalsign, Eurotech, and Microsoft describes a blueprint for ZTO in the context of Microsoft Azure. In the following paragraphs, we will describe the process currently implemented in Eurotech’s IoT stack in a bit more technical details. This stack leverages the Eclipse Kura and Eclipse Kapua open source projects, both part of the Eclipse IoT Working Group.

At manufacturing time, the TPM 2.0 components of the edge devices and IoT Gateways are seeded with a unique, long-lived IEEE 802.1AR standard-based Initial Device Identity (IDevID) signed by Eurotech and a customer-signed Local Device Identity (LDevID). The devices are also seeded with an initial configuration for its Everyware Software Framework (ESF) middleware containing the MQTT URL endpoint and credentials (username/password) for the IoT platform’s provisioning service, the platform being Everyware Cloud in this case.

At first activation in the field, the ESF-powered device will connect to the IoT platform’s Provisioning Server, using the LDevID to pass SSL mutual authentication and the initial credentials to establish a secure MQTT connection.

If a matching provisioning request is confirmed on the IoT platform’s side, the latter will send an updated configuration to the gateway. This configuration includes:

• Endpoint and configuration for the PKI that will manage the gateway’s operational credentials
• URL of the MQTT endpoint for the IoT Platform’s broker
• Randomly generated credentials for the device’s MQTT connection
• A certificate to validate the remote management commands sent by the platform
• Any other configurations for the specific use case (ESF / Kura Wires, drivers and assets configuration for field devices, etc.)

Interactions with the PKI rely on EST (Enrolment over Secure Transport), a cryptographic protocol described in RFC 7030.

To start the process, the device needs to obtain the address of an EST PKI and its challenge password as a shared secret. Once it gets those, the edge device will generate a key pair in the TPM, contact the PKI, create a certificate signing request, and send it to PKI for enrollment. Authentication is ensured via mutual SSL using the LDevID. The platform’s provisioning service sends a secret challenge to the edge device. Finally, the device will use the certificate returned by the PKI to authenticate itself to the MQTT Broker of the IoT platform.

At this point, all initial ZTO steps have been performed, and the device’s provisioning, with all necessary software configurations and updates, can take place.

Throughout the product lifecycle, the edge device will update its ZTO certificate when revoked or expired by re-enrolling. The IoT platform will periodically update the list of disabled/retired devices on the Cloud side by downloading the list of revoked certificates from the PKI and synchronizing that information with its black-listed devices.

Naturally, what we covered in this post is a more detailed overview of one of the possible ways to implement device attestation and secure ZTO for solutions targeting higher-value connected assets, as encountered in industrial, energy & utilities, transportation, or medical applications. There are others, allowing you to effectively address security challenges in other application scenarios.

In our next post, we will explore what can be built on top of the foundation device attestation provides.

All Edge of Things contributors belong to Eclipse Foundation member organizations or are Foundation staff. The contributors to this particular post are Robert Andres (Eurotech), Frédéric Desbiens (Eclipse Foundation), and Kilton Hopkins (Edgeworx).