The Edge of Things
Published in

The Edge of Things

Edge Computing Security: Device Attestation Through A Certificate Hierarchy Approach

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

There are many ways to implement device attestation. In this post, we will describe one that we consider a good match for the requirements of IoT and Edge Computing deployments.

The general idea is to create a set of certificates that attest to the integrity of several different aspects of the devices. Certificates used for device attestation in IoT and edge devices have more applications than ensuring the end-user that the device to be deployed is a genuine product with a genuine TPM installed. The same mechanism — leveraging distinct X.509 certificates with the appropriate lifetimes — may be used for attesting the ownership of the device at a given time or even the integrity of its installed software.

These different purposes are best enabled with an open, standardized approach to creating a certificate hierarchy. A good place to start is the IEEE 802.1AR standard. 802.1AR was originally designed for computer networking applications but can certainly be leveraged with other types of devices. The standard defines Secure Device Identities (DevIDs) meant to be used as interoperable, secure device authentication credentials. A standardized device identity streamlines authentication and simplifies device deployment and management.

A device with DevID support features a globally unique, long-lived, Initial Device Identifier (IDevID) provided by the device manufacturer. The device may also support the creation of Locally Significant Device Identifiers (LDevIDs), which are shorter-lived than the IDevID. Each LDevID is bound to the device. They cannot be forged, and it is impossible to transfer them to another device without the private key used to effect the cryptographic bond between the LDevID and the device.

In our proposed approach, the device identity (IDevID) forms the root of the certificate hierarchy, and LDevID certificates are used to attest to other aspects of the device. Those aspects include, among others:

  • Device ownership: The association between a device and a customer
  • Integrity: This covers the hardware components, the firmware for components that require it, the operating system, and the applications.
  • Infrastructure or platform provisioning: The association between an on-premises or Cloud IoT platform to implement or leverage secure zero-touch onboarding mechanisms.
  • Device full provisioning: An attestation that the device is fully provisioned and ready to use for actual workloads.

LDevID certificates could also be leveraged in the context secure applications and their management. For example, a standard such as PKCS#11, which specifies an application programming interface (API) for devices using security hardware like a TPM, for storing cryptographic information and performing cryptographic functions, allows for the management (creation, modification, deletion) of cryptographic (asymmetric, symmetric, elliptic curve, etc.) keys and certificates. One application could be to sign custom application packages and prevent the execution of unsigned packages on the devices.

To support a hierarchy of certificates like the one we described, it is necessary to handle the certificates securely. This includes:

  • Generating and managing certificates with the appropriate characteristics to support the attestation workflow and ensure the certificates’ validation is possible.
  • Storing them with the assistance of the appropriate hardware, such as a Trusted Platform Module (TPM). It is impossible to build hardware root of trust otherwise.

To start building the certificate hierarchy, it is necessary to first generate the IDevID, which allows to validate that the device hardware is genuine. It is also preferable to leverage a TPM that already comes with a certificate, such as an enrollment key (EK), allowing verification that the security chip itself is genuine.

The diagram below summarizes the flow of certificates composing the hierarchy.

Zero-touch onboarding (or provisioning) becomes possible once the certificate hierarchy has been established and deployed.

In our next post, we will discuss that process in a little more detail and explore what lies beyond zero-touch onboarding.

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




The Edge of Things features insights from industry thought-leaders on edge computing and IoT technologies. All articles are contributed by Eclipse Foundation members and staff.

Recommended from Medium

Quick guide on how to set up BDD test automation framework using Frameworkium

One day, you’re questioning what on earth will ever make you feel happy and fulfilled

Offshore vs Onshore Software Development

What kind of TURN server is being used?

Download Stock/Returns Data from Yahoo Finance — Python/Jupyter Notebook

Playing with Haskell

How to manage AWS Resources

78th Monthly Technical Session

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Robert Andres

Robert Andres

Tech business advisor, focusing on market strategy, analyst relations and partner ecosystems, in ITC, IoT and Edge. Member of the Eurotech executive team.

More from Medium

Edge Computing Security: It Starts With Solid Device Identity and Attestation

Avoiding Security Alert Hell: Introducing Squyre

A case for a new breed of Security GRC

Ditching Password for Ditching Security and Democracy ?