IoT security fundamentals: connecting securely to IoT Cloud services
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).
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
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
Azure IoT edge device
Telemetry
IoT Hub
Insights and module health
Insight
Action
Azure IoT Edge runtime
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. Credit: Microsoft Azure
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. 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
Listing 1: Developers use a JSON format to describe AWS IoT access rights policies for their IoT devices. Credit: AWS
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
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). 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
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
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. Credit: Microsoft Azure
“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}”]
}
]
}
we get technical
26
27
Powered by FlippingBook