Device Security

In this step, we’ll explore how a secure device model fits into a secure IoT ecosystem. You’ll be introduced to secure IoT devices and will learn how to develop your own device security model.

Device security includes device provisioning and authentication. A threat model for devices should also include how data is stored and transmitted, as well as how to protect devices from spoofing and DOS attacks.

Basic Device Security

Intel, in their IoT Platform Reference Architecture document describes device security by claiming that a device is secure when an IoT solution can:

‘Protect device and user identities, ensure device integrity, and protect operational and personal data on every device. Each device should guarantee authentication without jeopardising individual privacy and have the ability to automatically self-assess and resolve any situation.’

That’s a tall order, but this level of device security should be considered essential for a secure IoT ecosystem. Similarly, Microsoft recommends IoT architects focus on the physical security of devices and sensors.

Physical Tamper Proofing and Safety

Sensors and devices can and must often be placed in public areas, where anyone may potentially have physical access to them. Tampering with the device is not just the act of manipulating the device hardware or software. A digitally trustworthy sensor may be tricked into reporting misleading data by dismounting and relocating it. Or, an attacker could impact the environment around the device, creating misleading physical conditions in the immediate proximity of the device, pushing the overall system into an erroneous reaction. A lit lighter held near a smoke or temperature sensor might, for instance, trick a digital building control system into flooding a hotel hallway with the sprinkler system.

As the IoT space blurs digital and physical concerns, it also blurs security with safety. Suddenly, security threats become safety threats. If something goes wrong with automated or remote-controllable devices—from physical defects to control logic defects to willful unauthorised intrusion and manipulation—production lots may be destroyed, buildings may be looted or burned down, and people may be injured or die. This is a different class of damage than someone maxing out a stolen credit card limit. The security bar for commands that make things move, and also for sensor data that eventually results in commands that cause things to move, must be higher than in any e-commerce or banking scenario.

Some exemplary measures that can be taken to improve the security of the physical device are:

• Choosing microcontrollers/microprocessors or auxiliary hardware that provide secure storage and use of cryptographic key material, such as trusted platform module (TPM)63 integration.
• Securing boot loader and secure software loading, anchored in the TPM.
• Using sensors to detect intrusion attempts and attempts to manipulate the device environment with alerting and potentially ‘digital self-destruction’ of the device.[^1]

For more information on how the Azure IoT framework can help keep devices secure, see the Azure IoT Reference Architecture.

Device Security and Azure IoT Hub

You can secure devices out in the field by providing a unique identity key for each device, which can be used by the IoT infrastructure to communicate with the device while it’s in operation. With Azure’s IoT framework, the process is quick and easy to set up. The generated key with a user-selected device ID forms the basis of a token used in all communication between the device and the Azure IoT Hub.

Device IDs can be associated with a device during manufacturing (that is, flashed in a hardware trust module) or can use an existing fixed identity as a proxy (for example CPU serial numbers).

Since changing this identifying information in the device isn’t simple, it’s important to introduce logical device IDs in case the underlying device hardware changes but the logical device remains the same.

In some cases, the association of device identity can happen at device deployment time. For example, an authenticated field engineer physically configures a new device while communicating with the solution back-end.

The Azure IoT Hub identity registry provides secure storage of device identities and security keys for a solution. Individual or groups of device identities can be added to an allow list or a block list, enabling complete control over device access.

Azure IoT Hub access control policies, in the cloud, enable the activation and disabling of any device identity, providing a way to disassociate a device from an IoT deployment when required. This association and disassociation of devices is based on each device identity.

To support these features, the Azure IoT framework supports the following through the device identity store:

Device Identity Authority: The device identity store is the authority for all device identity information. It also stores and allows for validation of cryptographic secrets for device client authentication. The identity store typically doesn’t provide any indexing or search facility beyond direct lookup by the device identifier; that functional role is taken on by another store that keeps the application-specific domain model. These stores are primarily separated for security reasons; lookups on devices should not allow disclosing cryptographic material.

Provisioning: Device provisioning uses the identity store to create identities for new devices in the scope of the system or to remove devices from the system. Devices can also be enabled or disabled. When they are disabled, they cannot connect to the system, but all access rules, keys, and metadata stay in place.

A solution’s provisioning workflow takes care of processing individual and bulk requests for registering new devices and updating or removing existing devices. It will also handle the activation, and potentially the temporary access suspension and eventual access resumption. The provisioning workflow ensures that the device is registered with all back-end systems that need to know about its identity and additional metadata attributes as needed. These features help to ensure that device identity is securely managed and that onboarding or suspending a device from the solution can be managed centrally which can help ensure that only secure devices are included in the ecosystem when a threat has been detected.

Device security is a logical first step when you consider how to secure your IoT solution. Now that you have an understanding of device security, let’s move on to connection security.