Original Title：IoT Security Fundamentals—Part 5: Connecting Securely to IoT Cloud Services

　　Editor’s Note: Despite the proliferation of IoT devices, securing these devices remains an on-going concern, to the degree that security challenges can be a barrier to adoption of connected devices in Industrial IoT (IIoT) and mission-critical applications where corporate and personal data may be compromised in the event of a successful attack. Securing IoT applications can be daunting, but in reality IoT device security can be built upon a few relatively straightforward principles that are supported by hardware security devices. By following well-established security practices, these concerns can be addressed. This multi-part series provides practical guidance to help developers ensure best practices are followed from the outset. Part 1 discusses the cryptographic algorithms underlying secure designs. Part 2 discusses the role of private keys, key management, and secure storage in secure IoT designs. Part 3 examines the mechanisms built into secure processors to mitigate other types of threats to IoT devices. Part 4 identifies and shows how to apply security mechanisms in advanced processors to help ensure the isolation needed to mitigate attacks on the runtime environment of IoT devices. Here, Part 5 describes how IoT security continues from IoT devices through higher level security measures used to connect those devices to IoT cloud resources.

　　Internet of Things (IoT) security depends on multiple layers of protection extending from the IoT device's hardware foundation through its execution environment. Threats remain for any connected device, however, and typical IoT application requirements for cloud connectivity can leave both IoT device and cloud services open to new attacks. To mitigate these threats, IoT cloud providers use specific security protocols and policies which, if misused, can leave IoT applications vulnerable. Using preconfigured development boards, developers can quickly gain experience with the security methods used by leading IoT cloud services to authenticate connections and authorize use of IoT devices and cloud resources.

　　This article describes the connection requirements of two leading cloud services, Amazon Web Services (AWS) and Microsoft Azure, and shows how developers can use development kits and associated software from a variety of vendors to quickly connect with these services.

　　The role of IoT portals in cloud services

　　When an IoT device connects to a resource such as a cloud service or remote host, it potentially exposes itself—and by extension the entire IoT network—to threats masquerading as legitimate services or servers. Conversely, the cloud service itself similarly faces the threat of attacks from hackers mimicking IoT device transactions in an attempt to penetrate cloud defenses. To help ensure protection for both IoT devices and cloud resources, cloud services require the use of specific security protocols for mutual authentication of identity for sign in and subsequent authorization to ensure permitted usage of services. These protocols are typically included in a set of services that provide a secure portal between IoT devices and cloud resources.

　　As with other available IoT cloud service platforms, AWS and Azure each provide a specific entry portal that IoT devices need to use to interact with each provider's full set of cloud resources such as virtual machines (VMs) and software-as-a-service (SaaS) offerings. Using a functionally similar set of mechanisms and capabilities, Azure IoT Hub and AWS IoT provide this portal for their respective enterprise cloud offerings.

　　At a minimum, these and other IoT portals use specific authentication protocols implemented through each provider's software development kit (SDK) to create a secure connection. For AWS, IoT devices connect using mutual authentication with a device gateway. The device gateway connects the IoT device with other IoT support services, using information held in a device registry to store a unique device identifier, security credentials and other metadata needed to manage access to AWS services (Figure 1). In Azure, the identity registry serves a similar function.

Figure 1: As with other cloud providers, AWS provides developers with a set of specialized services designed to enhance the security and effectiveness of transactions between IoT devices and enterprise cloud services. (Image source: Amazon Web Services)

　　AWS IoT and Azure IoT each provide a service that maintains state information in a virtual device associated with each physical IoT device. In AWS IoT, device shadows provide this capability for AWS IoT, while device twins provide similar capabilities for Azure IoT.

　　This notion of a security portal extends to IoT edge services such as AWS Greengrass or Azure IoT Edge. These edge service offerings bring some cloud services and capabilities down to the local network, where edge systems are placed physically close to IoT devices and systems in large-scale deployments. Developers can use a service such as Azure IoT Edge to implement application business logic or provide other functional capabilities needed to reduce latency or provide services to local operators, such as in industrial automation (Figure 2).

Figure 2: To support edge computing, cloud service providers offer specialized services such as Microsoft Azure IoT Edge, which brings some Azure IoT cloud services closer to the physical devices associated with the IoT application. (Image source: Microsoft Azure)

　　Dealing with requirements for IoT portal connectivity

　　Whether connecting through an edge system or directly with the provider's IoT service, IoT devices typically need to satisfy a series of requirements to connect through the provider's IoT portal and use the provider's cloud services. Although the details differ, IoT devices need to provide at a minimum, some item such as a private key, X.509 certificate, or other security token. The key, certificate, or token provides the IoT portal with attestation or proof of the IoT device's identity during the authentication phase of the device-cloud connection sequence. In addition, IoT cloud services typically require a specification of the policies used to define access rights for interactions between IoT devices and cloud services.

　　As with other enterprise computing requirements, attestation information for authentication and policy information for access management need to be provided using specific formats and procedures specified by leading IoT cloud services like AWS IoT and Azure IoT. These services support certificate-based authentication at a minimum, but also support use of other forms of attestation. For example, developers can use token-based authentication methods based on a JSON Web Token (JWT) for AWS IoT, or a shared access signature (SAS) token for Azure IoT.

　　As mentioned earlier, these services use registries to hold metadata for each IoT device. Along with security and other information, these registries store the access rights policies that need to be defined to connect an IoT device. Although specified in different ways for different cloud services, these policy definitions describe access rights for different communications channels and entities. For example, a simple AWS IoT access right policy would use a JSON format to indicate that an IoT device with a particular "thing" name in the AWS IoT device registry could connect and publish messages only on a channel with the same associated thing name (Listing 1).

　　Copy

　　{

　　"Version": "2012-10-17",

　　"Statement": [

　　{

　　"Effect": "Allow",

　　"Action":["iot:Publish"],

　　"Resource": ["arn:aws:iot:us-east-1:123456789012:topic/${iot:Connection.Thing.ThingName}"]

　　},

　　{

　　"Effect": "Allow",

　　"Action": ["iot:Connect"],

　　"Resource": ["arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}"]

　　}

　　]

　　}

　　Listing 1: Developers use a JSON format to describe AWS IoT access rights policies for their IoT devices. (Code source: AWS)

　　Cloud-ready development kits

　　Although cloud providers offer detailed specifications of those formats and procedures, the providers' support forums are typically filled with questions from developers tripped up by some small but vital detail that prevents authentication and access management. Perhaps even worse, from a security standpoint, unintended misuse of attestation or incomplete definition of access policies can leave IoT devices, networks, and applications open to attack. The availability of off-the-shelf development boards and accompanying software packages allows developers to quickly navigate through these connection procedures, using vendor-provided examples to rapidly connect to IoT clouds. For example, Espressif Systems' ESP32-Azure IoT Kit or Seeed Technology's AZ3166 IoT Developer Kit include Azure-certified boards designed to connect easily with the Microsoft cloud.

　　Microsoft provides complete step-by-step demonstrations, including authentication and access credentials for the supported development kits. With the AZ3166 board, for example, developers press buttons on the board to initiate connection with their local Wi-Fi network. Once connected, they can use the Azure IoT Device Workbench contained within the Azure IoT Tools extension pack for Microsoft Visual Studio Code to develop, debug and interact with the Azure IoT Hub. Using this toolset and its sample code packages, developers create an object for the IoT device in Azure IoT Hub and use a provided file to provision the associated identity registry with the credentials and other metadata required to connect the IoT board to Azure IoT Hub (Figure 3).

Figure 3: Sample code and credentials provided in the Microsoft Azure IoT Device Workbench help developers complete provisioning for connecting the Seeed Technology AZ3166 IoT Developer Kit to Azure IoT Hub. (Image source: Microsoft Azure)

　　The Azure IoT Device Workbench provides additional support software and metadata that lets developers quickly load the AZ3166 board with sample code and begin transmitting measurements from the board's temperature and humidity sensor to Azure IoT Hub.

　　The steps involved in creating a representation for the physical IoT device in the IoT cloud and for provisioning the associated registry are needed just to connect devices with the IoT cloud. To take advantage of cloud services, however, the Azure IoT Hub needs an access rights policy. To monitor the device-to-cloud messages coming from the AZ3166 sensor, developers can simply use the Azure shared access policies screen to select a prebuilt policy designed to quickly enable the required access rights (Figure 4).

Figure 4: Developers can use prebuilt policies to easily authorize use of Azure cloud services with sensor data from the Seeed Technology AZ3166 IoT Developer Kit. (Image source: Microsoft Azure)

　　When working with AWS IoT, developers can turn to development kits such as Microchip Technology's AT88CKECC-AWS-XSTK-B Zero Touch Provisioning kit and accompanying software to quickly evaluate cloud connectivity. This updated version of an earlier Microchip Zero Touch Provisioning kit comes preloaded with authentication credentials. Using additional scripts provided with the kit, developers can rapidly connect the board to AWS IoT without dealing with private keys and certificates (see, "Take the Zero-Touch Approach to Securely Lock Down an IoT Device").

　　Other development kits, including Renesas' RTK5RX65N0S01000BE RX65N Cloud Kit and Infineon Technologies' KITXMC48IOTAWSWIFITOBO1 AWS IoT kit, extend support for AWS IoT connectivity with support for rapid development of applications based on Amazon FreeRTOS. AWS provides detailed directions for registering the boards, creating authentication credentials, and loading provided JSON policies needed to connect to AWS IoT and use AWS services.

　　Simplifying provisioning for large-scale IoT deployments

　　Development kits such as those described above serve as effective platforms both for rapid prototyping of IoT applications and for exploring IoT cloud service connection requirements. In practice, however, developers will typically need to turn to more advanced approaches designed to simplify provisioning of IoT devices in real-world applications. Both Azure IoT and AWS IoT support a wide variety of methods that allow more automated provisioning of individual devices or large numbers of IoT devices in a large-scale deployment.

　　With AWS IoT, for example, developers can use a bootstrap method for certificate provisioning. Here, the smart product ships with a bootstrap certificate associated with the minimal access rights needed to request and access a new certificate (Figure 5).

Figure 5: AWS IoT supports a method to bootstrap certificate provisioning in IoT devices. (Image source: Digi-Key Electronics, from Amazon Web Services)

　　Using the bootstrap certificate, the device connects to the cloud ("1" in Figure 5), requests ("2") a new certificate, receives ("3") the URL of the certificate generated by an AWS serverless Lambda function, and retrieves ("4") that certificate from an AWS Simple Storage Services (S3) bucket. Using that new certificate, the device then logs back into AWS IoT ("5") to proceed with normal operations.

　　AWS offers other cloud services that support dynamic provisioning of authentication tokens using execution resources like AWS Lambda functions. For example, an automotive application might rely on a series of ephemeral connections where use of a token is both more practical and more secure. Here, after an AWS module for IoT authentication and authorization approves the request for a token, the AWS Security Token Service (STS) generates a token for delivery to the vehicle's systems. Using that token, those systems can access AWS services subject to validation by the AWS Identity and Access Management (IAM) service (Figure 6).

Figure 6: Leading cloud service providers support other forms of attestation for authentication such as this process for dynamic generation of security tokens by AWS Security Token Service (STS). (Image source: Amazon Web Services)

　　AWS provides a similar capability for dynamic assignment of access rights. Here, other AWS Lambda functions would assign a set of policies associated with a valid token (Figure 7).

Figure 7: Developers can use cloud services to implement dynamic assignment of access rights, which is particularly useful for applications with ephemeral connections or short-lived operations. (Image source: Amazon Web Services)

　　Other IoT cloud services allow developers to more efficiently deal with provisioning in large-scale deployments. For example, AWS IoT provides fleet provisioning capabilities, including support for a larger scale deployment of the kind of bootstrap method described earlier. Azure IoT's Device Provisioning Service provides a group enrollment capability that supports provisioning of large numbers of IoT devices that share the same X.509 certificate or SAS token.

　　Shared responsibility for security

　　IoT cloud providers provide a number of effective methods for enhancing end-to-end security for IoT applications. Nevertheless, IoT developers cannot expect that those methods can bear the full weight of security requirements for their particular IoT application. In fact, cloud service providers carefully outline their specific role and responsibilities in IoT application security with specific models such as AWS' shared responsibility model (Figure 8).

Figure 8: As with other leading cloud providers, AWS describes the responsibilities that it shares with cloud users to protect the cloud infrastructure on one hand and customer applications on the other. (Image source: Amazon Web Services)

　　AWS and Microsoft Azure each provide shared responsibilities documents that describe and explain the provider's own role and that of the customer in securing resources, data, and applications. In its documentation, Microsoft also offers an overview of some of the relationships between shared security and compliance requirements. Ultimately, cloud providers retain responsibility for the security of the cloud, while customers remain responsible for applications, data and resources used in the cloud.

　　Conclusion

　　IoT applications depend on layers of security built up from hardware-based mechanisms for cryptography and secure key storage. As with any connected product, security threats can arrive in all manner of interactions when IoT devices connect with cloud services. To protect themselves and their customers, IoT cloud providers dictate specific requirements for authentication and access rights management. Although providers offer detailed documentation on those requirements and associated specifications, developers can find that their efforts to implement secure connectivity sometimes leave resources exposed, or conversely, inaccessible. Using development boards and associated software, developers can quickly connect to cloud services and rapidly prototype IoT applications with end-to-end security.