When it comes to the Industrial Internet of Things (IIoT), device security offers a very distinctive set of challenges. This tutorial provides a hands-on guide to authenticating devices on the GE Predix platform.

Predix is GE’s software platform for the Industrial Internet. Deployed on machines, onsite or in the cloud, Predix handles big data at an industrial scale, providing insights to improve asset performance management, ops and business. In the second of a series of articles, we explore how to authenticate devices on Predix.

The first challenge here is: devices aren’t human.

We could store a password on the device, but that technique presents certain flaws. The device could be tampered with, which could compromise its password. And it’s hard to set or reset passwords on devices without accessing the devices themselves, making it impractical for managing a plethora of IoT devices in remote locations.

The second challenge is that devices require added protection because they may control mission critical equipment that generate sensitive information. We want them to be as secure as possible to minimize risk. In short, we need a way to automatically assign identities to devices and enable them to use those identities to authenticate with the cloud without requiring human intervention.

Predix uses a certificate-based enrollment process to apply identity to Predix Machine so that it can authenticate itself to Predix Cloud, the Edge Manager and other Predix applications. When a device programmatically enrolls to Edge Manager, it obtains a signed digital certificate designed specifically for devices, eliminating the process of manually entering the logon and security information, and allowing devices to start up and authenticate to Predix Cloud. Let’s look at the process step by step.

Step 1: Add a device

Manufacturers are responsible for including a serial number and a name on their devices and embedding them with an encrypted, shared secret. This is used in the authentication process. But first, we begin with a client that can call an API. The client calls an API to Edge Manager and adds the device to Edge Manager such that it knows that the device is about to enroll.

Step 2: Enroll the device

Next, you make the enrollment call. The device generates a key pair on its own (this way the private key never leaves the device). The device makes a REST call to Edge Manager using the pre-shared key as a token to make the call. If Edge Manager doesn’t recognize the key and pair the serial number with the shared secret, the call is rejected.

If the call is accepted, Edge Manager calls the User Account and Authentication (UAA) API and creates a client associated with it for that device. The device wraps the public key inside a Certificate Signing Request and sends it to Edge Manager along with the shared secret and all of the metadata. The certificate is signed by the certificate service, and returned to the device. In order to use the certificate to authenticate, you need more granular access to the identity itself. This is where we have credential binding to UAA.

What is UAA? you may ask. UAA started as an open source project designed to provide authentication and identity management for Cloud Foundry, on which Predix is built. UAA implements the OAuth2.0 specification.

Step 3: Obtain an access token from UAA

When a device wants to authenticate to the cloud we use a JWT bearer token. (JWT stands for JSON Web Token, which is defined in RFC 7519.) The JWT bearer token payload contains a variety of data, including issuer, client ID and an expiration date. The client ID serves as the device’s identity in the authentication process. To generate a JWT bearer token, the device takes its private key, signs the payload and creates a digital signature. The device sends the signature to the cloud, and the cloud verifies that that device created that signature, and then the JWT bearer token is issued for the device.

Once generated, the JWT bearer token is sent back up to the cloud. The UAA verifies the token with the Certificate as a Service backend, pulls the public key to verify the signature and, once verified, issues an access token just as when you make a standard API call. In this way, the UAA ultimately enables the device to act as a client to the application services.

Step 4: Device makes a request to the application

In the final step, the token is appended to the authorization header just as in any other REST call that you make.

Through this process, devices are securely enabled to access application services. Data from the devices can be ingested via Time Series, with assurance about where that data came from. Components of digital twins can be securely identified and, if a part, such as a brake pad, is switched out, the new brake pad can identify itself so that it can be incorporated, via the Asset Service, into a particular digital twin.

With only a few steps we have made it as simple as possible to authenticate devices in the IoT and still sleep at night knowing we’ve taken precautions to minimize security risks.