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.
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 Machine and Predix Edge Manager are useful components to guide devices through the following steps:
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.
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 Machine and Predix Edge Manager are useful components to guide devices through the following steps:
- Add a new device
- Enroll the device
- Acquire a UAA Access token
- Make API requests
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.
No comments:
Post a Comment