Delivering Hyper Scale Trust in the Cloud

Thmb_120

Designing products and services to be frictionless will lead to more compelling user experiences and greater affinity with the customer. For example, biometric chip in Apple iPhone helps establish seamless user identity & trust to unlock screen, make one-step secure payment to buy apps from app store etc. In this case, there is a 1:1 relationship between user-device and manufacturer of a device enabling frictionless experience for user. But it is not the same in the case of an upscale hotel that has IoT devices (smart bulbs, digital key locks, smart thermostat, connected vending machines etc.) to enhance guest experience i.e., hotel first needs to secure different manufacturer’s IoT devices procured & installed in its premises and rooms. Then establish a temporary trust relationship between guest checking into the hotel & devices in room and when guest checks out remove the temporary trust established at the time of check-in to avoid misuse of devices by guests etc.

Problem Statement
How do you bring trust to all the participants in both a value chain and ecosystem of device manufacturers, their services and the digital experience for the users with and through service providers?

What’s trust got to do with it?
The enemy of trust is anonymity–without it there can be no trusted bidirectional communication between a device, cloud services and third parties. Without authentication, authorization and governance of both identity and the means to establish trust, the bad actors can take over a wearable, street light, vehicle control system and cause havoc. An IoT device can get flipped into a ‘bot’ to initiate DDoS attack. Without trust between two parties–a bad actor can get in the middle of the session or transaction as a man-in-the-middle to steal the data. Without confidence in the ‘original seal’ of a device there is counterfeit and without trusted firmware patch, devices become vulnerable to future cyber-attacks etc.

The role of Cloud Platforms
There are many actors that participate in the IoT service ecosystem. A key player is the cloud platform. IoT cloud platforms provide identity & trust functionality for the devices managed through their IoT cloud platform. E.g., The AWS IoT Thing Registry contains device attributes such as serial numbers, certificates and policies. The Registry also allows for policy definitions that enable PKI certificate based policy configuration across multiple MQTT (the publish-subscribe-based lightweight messaging protocol) topics used for device-to-cloud service communication. This policy configuration enables establishment of trust for the devices to enable secure firmware upgrade of devices as well as to control messages that get published on the MQTT channel/topics.

However, because the primary focus for IoT cloud platform providers is to provide identity & trust capabilities related only to devices and allows users of the IoT device to build context specific trust capabilities, there is a need for an additional trust layer that enables the following:

  • The ability for device manufacturers and service providers to implement bring-your-own certificate (BYOC) capabilities to establish context specific trust establishment. Context specific trust establishment enable usage of certificates depending on the environment in which a device is operating
  • Identity driven assignment of PKI certificates to MQTT topic to enable persona based trust establishment on an IoT device that is shared by multiple users
  • Automate lifecycle management of PKI certificates & associated crypto keys that are used for establishing trust for IoT devices as well as for the users of the devices

Without these additional identity & trust capabilities, there would unpleasant consequences as highlighted in below security incidences.

  • The inability to revoke or rekey a certificate that was compromised could result in situations such as the recently reported IoT worm that has the potential to disrupt smart bulbs in a city’s smart lighting systems using a compromised master key in the ZigBee Light Link (ZLL) protocol.1
  • With a strong device-to-user-to-application-to-service identify and trust mapping, IoT devices could become bots for initiating DDoS attacks, such as the Dyn DNS DDoS attack demonstrated attack.2

IoT Trust Layer for AWS Cloud Platform
Value add of the trust layer for AWS IoT cloud platform is described through an upscale hotel use case wherein the hotel is considering installing AWS IoT SDK-integrated smart devices like smart bulbs, digital key locks, smart thermostat etc., to provide an improved experience for their guests. Hotel wants to make establish a temporary trust between the guest and the smart devices in the guest’s room to protect guest’s privacy as well to protect devices being used as bot by malicious guest.

An IoT device manufacturer supplying AWS IoT SDK-integrated smart devices might have provision PKI certificates, or ‘birth certificates,’ installed in the devices in the manufacturing plan. However, the hotel would want to provision its own ‘operational certificates’ in the devices to make sure devices have trust relationship established to the hotel.

When a guest checks in, the hotel creates temporary guest identity & associated PKI certificate. The created guest identity could be written on an RFID or NFC enabled smart access card & could optionally be linked to guest’s other details like loyalty account and guest preferences e.g., ambience lighting setting or subscribed pay TV channels etc. When the guest uses the access card to enter the smart room, based on the guest identity, corresponding PKI certificate is downloaded to all the smart devices in the room to establishing trust relationship between user and device. With certificate controlling the information that is exchanged between devices and the cloud service, hotel can make sure IoT devices in the rooms are protected from malicious guest. When the guest checks-out, temporary guest identity and the corresponding PKI certificate are removed.

To provision for the technical underpinnings required to establish identity and trust in the smart hotel use case—as well as numerous other industry use cases and vertical applications—Aricent has developed the Identity Federation, Root of Trust, Certificate and Key (IDROCK) lifecycle management and delivery framework.

Aricent’s IDROCK Framework: Hyper Scale Trust for the IoT
The Aricent IDROCK lifecycle management and delivery framework brings in an orchestration trust layer to enable automated and streamlined management of device and user identities, as well as internet scale PKI certificates. As shown in Figure 1, the IDROCK backend server integrates with AWS IoT cloud services through AWS-provided APIs to automate the lifecycle management of root certificates, as well as birth and operational certificates associated with millions of device and user identities. Along with the IDROCK backend server integration with AWS IoT cloud services, a low footprint Aricent IDROCK agent is integrated with the AWS device SDK to handle the trust lifecycle management in the IoT devices. The IDROCK agent can communicate with the cloud services through HTTPS or KMIP over secure MQTT.

36436356f6925203ef3b175508ba3bf9-0
Figure 1: The IDROCK enabled trust layer integration with AWS IoT (Source: Aricent)

Figure 2 depicts how the IoT device manufacturer would use the intuitive IDROCK administration portal to generate device birth certificates, signed either through a self-signed or CA-signed root certificate, and register the certificates with AWS IoT. Since the manufacturer could enable remote secure firmware upgrades of devices through a specific MQTT publish-subscribe topic, the IDROCK portal allows configuring that associates a certificate to a MQTT topic dedicated for firmware upgrades. This also further ensures secured signed upgrade of device firmware.

36436356f6925203ef3b175508ba3bf9-1
Figure 2: Interaction of different participants in the enhanced trust layer enabled by IDROCK

Once the AWS SDK-enabled IoT devices from the manufacturer are installed in the hotel, the hotel can use the IDROCK portal to generate and install its operational certificates in the devices. Also, during the check-in process, when the hotel guest management system creates an identity for the guest, the same identity is used by IDROCK to map the guest’s identity with the devices that are installed in the guest’s room. This will make sure temporary trust is established between the guest’s identity and the IoT devices fitted in the room and the hotel premises. When the guest checks out, their identity-to-IoT-device mapping is purged from the IDROCK backend server, removing the temporary trust established at the time of check-in and avoiding and misuse of the IoT devices.

Summary
There is a growing need to augment the security layer provided by public and private IoT cloud platforms with an add-on trust layer—such as the one enabled by Aricent IDROCK—for furthering trust for all the participants involved in the value chain. Device manufacturers need to plan for such trust layer as a value add to their services to deliver a frictionless digital experience enabled through their IoT devices.

References
[1] Kovacs, Eduard 'IoT Worm Could Hack All Smart Lights in a City' November 10, 2016, SecurityWeek
[2] Loshin, Peter 'Details emerging on Dyn DNS DDoS attack, Mirai IoT botnet' October 28, 2016, TechTarget

Leave a Reply

Your email address will not be published. Required fields are marked *