Skip to main content

Public Key Infrastructure

A robust Public Key Infrastructure (PKI) is imperative for ensuring secure cloud communication throughout the lifecycle of devices in a fleet. PKI includes the creation, management, and distribution of keys and certificates used in public-key cryptography.

A central tenet of public-key cryptography is the protection of private key material. Establishing PKI allows for private keys to be generated in and never leave secure storage on a device. This dramatically reduces the potential of private key material being compromised.

Establishing PKI​

When one of your devices connects to Golioth, it'll prove its identity by presenting a signed certificate. The device certificate contains the device's public key, as well as its project and device ID. Device certificates are issued by a certificate authority (CA), which validated the information in the certificate and signed it.

To verify the certificate the device presented, Golioth goes through a list of known CAs for your project. If the device's certificate was signed by one of the known CAs, Golioth can trust the information within it, and the device can start sending and receiving data.

In order to start leveraging PKI for device certificates, it is necessary to establish at least one CA, and register it with Golioth.

PKI Providers​

Golioth supports two mechanisms for registering CAs: Direct connections to external PKI providers, and manually uploading CA certificates. By establishing a direct connection to an external PKI provider, Golioth automatically keeps an up to date list of CAs, and is able to forward certificate signing requests on behalf of your devices, allowing devices to perform certificate rotation through Golioth's infrastructure.

For now, the only supported external PKI provider type is AWS Private Certificate Authority. If you're using a different service for your Public Key Infrastructure, you need to register your CAs manually, and certificate rotation will not be supported.

Read how to set up AWS Private CA as a PKI provider for detailed instructions on how to set this up.

If you do not have a PKI provider service set up, but still want to leverage certificate authentication in your development process, you can also establish local PKI with openssl.

Certificate IDs​

When issuing a device certificate, the certificate ID used in the common name (CN) is a unique identifier within the Golioth project specified in the organization (O) that is used to distinguish the physical device when using the certificate. The sole purpose of this identifier is to associate the physical device with a device on the Golioth platform. While a device's certificate ID may match other device attributes, such as the device name, it does not specifically connotate any other meaning. Using a dedicated identifier for this purpose enables zero-touch provisioning and other flexible provisioning workflows.

When a physical device presents a valid certificate to Golioth and proves possession of the associated private key, the physical device is associated with a device on Golioth according to the following logic.

  1. If a Golioth device already exists with the given certificate ID, the physical device is associated with it.
  2. If a Golioth device exists with a name that matches the certificate ID, and it has no certificate ID set, then the certificate ID is set and the physical device is associated with it.
  3. If no devices exist with either a matching certificate ID, or a matching name and no certificate ID, then a new device is created on Golioth with the certificate ID set, and the physical device is associated with it.

After a certificate ID is set on a Golioth device it is immutable. However, the name of the device remains mutable. In the third case above, this can lead to a scenario where a Golioth device exists with a name and certificate ID, and the name matches the certificate ID presented by the physical device, but the certificate IDs do not match. If this occurs, a new Golioth device is created with certificate ID set to match the physical device's certificate ID, and with name set to the same value of the certificate ID with a random suffix appended. Otherwise, the name of the newly created Golioth device will be set to the same value of the certificate ID.

Verification of Golioth Server Certificate​

Similarly to how Golioth must be able to establish a chain of trust rooted in the CA certificates uploaded in a project, a device must also be able to verify that it is communicating with Golioth. To accomplish this, one or more root CA certificates must be stored on the device. Golioth will present a server certificate, or a chain of certificates, that allow the device to establish a chain of trust rooted in the stored CA certificates.

Firmware SDKs and libraries distributed by Golioth typically will include the necessary root CA certificates to verify certificates presented by the platform. For example, the Golioth Firmware SDK embeds the ISRG Root X1 and Golioth Root X1 root CA certificates, whereas the pouch only embeds the latter.

Zero-Touch Provisioning​

The use of certificates enables devices to be created on the Golioth platform without a user needing to interact with the console or management API. This workflow is referred to as zero-touch provisioning and can alleviate operational overhead, particularly when deploying large fleets of devices. However, customers are still welcome to manually provision devices prior to their first connection.