Connection Security

In this step, we’ll explore connection security.

In Intel IoT Reference Architecture, connection security (the term they use is ‘network level’ security), refers to an IoT solution’s ability ‘to ensure secure application, traffic, and data security in transit through every type of wired and wireless network connection’.

Similarly, Microsoft recommends that IoT solutions focus on secure communication as a top architectural priority. As a foundational principle, all cloud communication with devices or field gateways must occur through secure channels when the devices talk directly to endpoints.

The Microsoft reference architecture adopts the following principles of Clement Vasters’s Service Assisted Communication model:

• Devices do not accept unsolicited network connections. All connections and routes are established in an outbound-only fashion.
• Devices generally only connect or establish routes to well-known service gateways that they are peered with. In case they need to feed information to or receive commands from a multitude of services, devices peer with a gateway that takes care of routing information downstream and ensures that commands are only accepted from authorised parties before routing them to the device.
• The communication path between device and service (or device and gateway) is secured at the transport and application protocol layers, mutually authenticating the device to the service or gateway and vice versa. Device applications do not trust the link-layer network.
• System-level authorisation and authentication should be based on per-device identities, and access credentials and permissions should be near-instantly revocable in case of device abuse.
• Bidirectional communication for devices that are connected sporadically due to power or connectivity concerns, may be facilitated through holding commands and notifications to the devices until they connect to pick those up.
• Application payload data may be separately secured for protected transit through gateways to a particular service.

Trustworthy and Secure Communication

Information received from and sent to a device must be trustworthy, if anything depends on that information. Trustworthy communication means that information is of verifiable origin, correct, unaltered, timely, and cannot be abused by unauthorised parties in any fashion.

Even telemetry from a simple sensor that reports a room’s temperature every five minutes should not be left unsecured. If any control system reacts to this input or draws any other conclusions from it, the device and the communication paths from and to it must be trustworthy.

Unless a device can support the following key cryptographic capabilities, its use should be constrained to local networks and all inter-network communication should be facilitated through a field gateway:

• Data encryption with a provably secure, publicly analysed, and broadly implemented symmetric-key encryption algorithm such as AES with at least 128-bit key length.
• Digital signature with a provably secure, publicly analysed, and broadly implemented symmetric-key signature algorithm such as SHA-2 with at least 128-bit key length.
• Support for either TLS 1.2 for TCP or other stream-based communication paths or DTLS 1.2 for datagram-based communication paths.
• Updateable key-store and per-device keys. Each device must have unique key material or tokens that identify it toward the system. The devices should be able to store the key securely on the device; for example, using a secure key-store. The device should be able to update the keys or tokens periodically or reactively in emergency situations in case of a system breach. A key update might occur over the air or through some other means, but updateability is required.
• The firmware and application software on the device must allow for updates to enable the repair of discovered security vulnerabilities.

Legacy Devices: If legacy devices must use insecure or nonstandard and proprietary communication paths into the cloud system, they should be connected through a separately hosted custom protocol gateway or local field gateway.

For more information on how the Azure IoT framework can enable secure communication, see the Azure IoT Reference Architecture.

Connection Security and the Azure IoT Hub

In the first step of this activity, we saw that understanding how data flows through your solution is an important first step in creating a robust threat model and ensuring data flow is secure.

Azure IoT Hub offers the durability of messaging between cloud and devices through a system of acknowledgements in response to messages. Additional durability for messaging is achieved by caching messages in the IoT Hub for up to seven days for telemetry and two days for commands.

Efficiency is important to ensure the conservation of resources and operation in a resource-constrained environment. HTTPS (HTTP Secure), the industry-standard secure version of the popular HTTP protocol, is supported by Azure IoT Hub, enabling efficient communication. Advanced Message Queuing Protocol (AMQP) and Message Queuing Telemetry Transport (MQTT), supported by Azure IoT Hub, are designed not only for efficiency in terms of resource use but also for reliable message delivery.

Scalability requires the ability to securely interoperate with a wide range of devices. Azure IoT Hub enables secure connection to both IP-enabled and non-IP-enabled devices. IP-enabled devices are able to directly connect and communicate with the IoT Hub over a secure connection. Non-IP-enabled devices are resource-constrained and connect only over short distance communication protocols, such as Zwave, ZigBee, and Bluetooth. A field gateway is used to aggregate these devices and performs protocol translation to enable secure bidirectional communication with the cloud.

Additional connection security features include:

• The communication path between devices and Azure IoT Hub, or between gateways and Azure IoT Hub, is secured using industry-standard Transport Layer Security (TLS) with Azure IoT Hub authenticated using X.509 protocol.
• In order to protect devices from unsolicited inbound connections, Azure IoT Hub does not open any connection to the device. The device initiates all connections.
• Azure IoT Hub durably stores messages for devices and waits for the device to connect. These commands are stored for two days, enabling devices connecting sporadically, due to power or connectivity concerns, to receive these commands. Azure IoT Hub maintains a per-device queue for each device.

Once you’ve completed this step, mark it as complete and we’ll move on to cloud security.