Authentication: The Key to Securing Connected Devices with Public Key Infrastructure Technology
by Will Charlton, on August 7, 2018
As the growth of IoT continues to rise, businesses often feel pressure to integrate connectivity into new or existing products lines quickly. As a result, security can become a last-minute consideration, making billions of devices vulnerable to attacks and intrusions that can compromise personal privacy, public safety, and company reputations. Leveraging public key infrastructure (PKI) technology during the manufacturing and provisioning process can serve as a valuable way to establish trust and ensure secure communication between your connected devices in the field and your cloud platform. In this blog, we’ll discuss the importance of authentication in the PKI process and provide an overview of typical PKI scenarios.
When talking about IoT, an aspect of security that we refer to as authenticity can often be overlooked. Identifying devices is everything when it comes to relational timeseries data, authenticating devices is everything when it comes to making absolutely certain that a device sending data into your cloud platform was made by you and purchased from you. This form of security protects your company from, for example, competitors making similar devices that function identically to your own, but at a cheaper price.
IoT devices typically connect and send their business data to some type of IoT platform, which can range from hilariously unsecured (http:80, mqtt:1883) to state-of-the-art secured (https:443, mqtt:8883). When using secure communications, the platform must identify the connecting device in some way or another. Symmetric strategies typically use tokens, while asymmetric strategies often use the TLS client certificate. Using a TLS Client Certificate to identify the connecting device is done by using the common name field in the certificate’s subject (e.g., /CN=00:C1:32:5F:00:2A), but this only proves that the device presenting the certificate has a usable common name (i.e., it was self-signed). In order to authenticate that the device in question came from your assembly line, you need to have two things:
- An IoT platform that can verify a client certificate against a certificate authority (CA).
- A device whose client certificate was signed by the same CA.
Without the IoT platform’s ability to verify that a given client certificate was signed by a given CA, there is no way to verify that the device was manufactured and provisioned by you. And, from the device’s perspective, if its client certificate wasn’t signed by the CA, the IoT platform will reject its connection request.
If you are bringing connected devices to market, working with a market-trusted PKI provider, such as DigiCert, or investing in your organization to become your own CA can provide a path to authenticity. When your device’s client certificates are signed by a trusted CA, nefarious agents that can conceivably copy your device’s dimensions, attributes, and software/firmware stack will fall short because they can’t fake a signed client certificate—if you didn’t sign it, the device can’t connect to the IoT platform.
Today, Exosite’s Murano platform can support various PKI system architectures, regardless of the PKI provider. Below are some typical PKI scenarios that are supported by Murano’s PKI-enablement feature.
Custom Root CA Certificate
Device manufacturers can define their own root CA certificate. During manufacturing, each device creates a certificate signing request (CSR) that the root CA must sign and then load the resultant certificate onto the device. Once the devices are manufactured and ready to connect, the CA certificate (the public key) is copied into your Murano product solution and loaded onto all of your devices, which present both their client certificate (signed by the CA) and the CA certificate during connection requests. Murano will validate that each device’s client certificate was signed by the root CA before allowing its data onto the platform.
Root and Intermediary Certificates
PKI systems often utilize intermediary certificates. This is done for security purposes and because certificates expire over time. In this type of system, though similar to the root CA method above, it is the intermediary CA that signs device CSRs. In this case, the intermediary certificate must be concatenated with the signed client certificate in order for Murano to validate the device’s connection request.
DigiCert Integration
Exosite has integrated the DigiCert API within Murano. This means that you (the manufacturer) can create a DigiCert account and provide your credentials to Murano (i.e., API token, profile name, and desired length of signing window). Once configured, devices can present their CSRs to Murano for signature. In this scenario, Murano serves as a broker between the device and your DigiCert account. This feature enables you to use one of the most trusted PKI providers (DigiCert) without having to interface with their API.
Exosite is committed to providing a world-class, end-to-end security foundation to build the future of connected products. By using Murano as your IoT platform and leveraging its PKI-enablement feature, you can confidently authenticate your devices in the field and ensure secure communication with the cloud platform. For more information on using Murano’s PKI enablement feature, visit the PKI section on our documentation site.