IoT key security: Architectural trade-offs for constrained devices

Ensuring security within the Internet of Things (IoT) ecosystem begins with robust cryptographic key management. However, when dealing with billions of resource-constrained devices—from simple sensors to complex gateways—traditional approaches become inefficient or prohibitively expensive. IoT security architects face a dilemma: how to achieve a high level of key protection without exceeding device budget, power consumption, and computational capabilities, while also ensuring scalable lifecycle management.

Defining constraints: Resource profiles of IoT devices and their impact on key management

Resource limitation is a defining characteristic of most IoT devices, directly influencing the choice of key management architecture. These constraints include:

• Computational Power (CPU): Microcontrollers (MCUs) have significantly less power compared to traditional processors, complicating the execution of complex cryptographic operations.
• Memory (RAM/Flash): Limited RAM and flash memory necessitate the use of lightweight cryptographic algorithms and efficient key storage methods.
• Power Consumption: Many IoT devices operate on batteries for years, so any cryptographic operations must be as energy-efficient as possible to avoid reducing device lifespan.
• Cost: For mass IoT deployments, minimizing component cost is critical, often restricting the use of expensive hardware security modules.

These limitations demand careful selection of cryptographic algorithms and key sizes. For instance, standard public-key algorithms like RSA and ECC might be too slow or resource-intensive for constrained environments. Lightweight Cryptography offers a practical solution, using, for example, 128-bit keys for symmetric encryption, balancing security with resource requirements.

Hardware Root of Trust for keys: From TPM to PUF

Hardware Roots of Trust (HRoT) are the cornerstone of secure key management, providing protection against physical and software attacks. These include:

• Trusted Platform Module (TPM): A TPM is a specialized chip that provides secure storage for cryptographic keys, random number generation, and remote attestation functions. While TPMs offer a high level of security, their cost and integration requirements can be significant for some resource-constrained IoT devices.
• Trusted Execution Environment (TEE): A TEE creates an isolated environment on the main processor where confidential code executes and sensitive data is processed, protected from the main operating system. GlobalPlatform develops specifications for TEEs, providing an open security architecture for consumer and connected devices.
• Secure Element (SE): An SE is a protected microcontroller designed for secure storage and processing of sensitive data, including cryptographic keys. SEs offer a high level of protection against physical and logical attacks and are often used for authentication and secure communication.
• Physical Unclonable Functions (PUF): PUFs leverage unique physical characteristics of a chip, arising during manufacturing, to generate unique, unclonable identifiers and cryptographic keys. PUFs are considered a lightweight and cost-effective solution for resource-constrained devices as they do not require storing cryptographic assets on the device. However, some PUF implementations may be vulnerable to machine learning attacks.

The choice among these hardware solutions depends on the risk profile, budget, and performance requirements. For example, for devices with high security demands, such as medical devices or smart locks, hardware key storage is the only justifiable choice.

Software approaches to key management: Trade-offs and vulnerabilities

In cases where hardware solutions are too expensive or resource-intensive, software approaches to key storage may be acceptable, but with certain trade-offs and vulnerabilities.

• Storage in encrypted flash memory: Keys can be stored in encrypted form in the device's flash memory. This requires a master key that protects other keys. However, if an attacker gains physical access to the device, they may attempt to dump the flash memory and extract the keys.
• Key Derivation Functions (KDF): KDFs can be used to generate keys based on secret data stored on the device and unique identifiers. This reduces the amount of data that needs to be stored.
• Code obfuscation: While obfuscation is not a foolproof protection method, it can make reverse engineering and key extraction from software more difficult.

The primary vulnerability of software key storage is that keys exist as data that the microcontroller can read. This makes them vulnerable to side-channel attacks, memory dumping, and other software exploits. NIST SP 800-57 provides recommendations for cryptographic key management, emphasizing the importance of protecting keys throughout their lifecycle.

Software key storage may be acceptable for devices with a short lifespan, very limited budgets, or those deployed in physically protected environments. However, it is not recommended for devices where key compromise could lead to significant financial losses, security threats, or regulatory violations.

Key lifecycle: Provisioning, rotation, and revocation at scale

Effective management of the cryptographic key lifecycle is a complex task, especially for millions of IoT devices. NIST SP 800-57 defines key lifecycle states: pre-activation, active, deactivated, compromised, and destroyed.

• Secure Provisioning: This is the process of initially embedding keys into the device.
• Factory Provisioning: Keys are embedded during manufacturing in a secure environment, often using a Hardware Security Module (HSM), which ensures key generation and storage in a tamper-resistant environment.
• Field Provisioning: Keys are generated or loaded onto the device after deployment, requiring robust remote authentication mechanisms and secure communication channels.
• Key Rotation: Regular key changes reduce the risk of compromise. NIST SP 800-57 recommends cryptoperiods of 1-2 years for TLS keys and 1-3 years for signing keys. For IoT devices, this can be implemented through hierarchical keys or Firmware Over-The-Air (FOTA) updates using Secure Boot.
• Key Revocation: In the event of a key compromise, a mechanism for immediate revocation is necessary to prevent further unauthorized access. This can be challenging for offline devices or devices with limited communication capabilities. Revocation strategies must consider the impact on service availability.

The ETSI TS 103 645 standard also emphasizes the importance of securely storing sensitive security parameters and ensuring software integrity through secure boot mechanisms.

Hybrid architectures: Combining hardware and software key protection

The optimal solution for many IoT scenarios is a hybrid architecture that combines the benefits of hardware and software key protection. This allows for a balance between security, cost, and operational efficiency.

Examples of hybrid architectures:

• Hardware Root of Trust for the master key: Using a TPM, TEE, or SE to store the device's primary (master) key. This master key never leaves the hardware module and is used to encrypt and decrypt other, derived keys.
• Software management of derived keys: Derived keys used for specific operations (e.g., telemetry encryption, session authentication) can be generated and managed in software, but always under the protection of the master key. This allows for flexible key management, reducing the load on expensive hardware modules.
• Secure boot and firmware updates: Secure Boot mechanisms ensure that the device executes only authentic and unaltered code, signed by a trusted key stored in the hardware root of trust. This is also critical for secure Firmware Over-The-Air (FOTA) updates, which may include key rotation.

This approach leverages the strengths of each method: hardware modules provide a high level of protection for critical keys, while software solutions offer flexibility and scalability for less sensitive operations. For example, for low-power sensors, a PUF can be used for unique identification and initial key generation, with session keys then managed in software.

Key management architecture selection mechanism

Choosing the optimal key management architecture for IoT devices is a multi-factor decision. The following matrix helps evaluate the trade-offs:

This matrix demonstrates that no single solution fits all. For simple, disposable sensors with a low risk of compromise, software key storage with appropriate security measures may suffice. For critical devices controlling physical processes or handling sensitive data, investment in hardware roots of trust is mandatory.

How AZIOT implements this

AZIOT, as a platform for building automation and industrial IoT, integrates a variety of devices, from simple Modbus sensors to complex BACnet and LoRaWAN gateways. Key management in AZIOT is based on principles of hierarchical trust and minimizing the attack surface. For resource-constrained devices connecting via MQTT or LoRaWAN, AZIOT supports the use of lightweight cryptographic algorithms and mechanisms for pre-shared keys or certificates provisioned during manufacturing. For more powerful edge devices and gateways, AZIOT leverages hardware roots of trust (if available on the device) to protect master keys and ensure secure boot. The key lifecycle, including rotation and revocation, is managed centrally through the AZIOT platform, allowing for scalable application of security policies and incident response, using auditing and access control mechanisms. This provides a robust foundation for remote attestation and secure firmware updates, which are critical for long-lived IoT deployments.

For more information on Intecracy and inbase.com.ua solutions, visit Intecracy solutions and inbase.com.ua solutions.

Practical conclusion for the IoT security architect

Choosing the cryptographic key management architecture for constrained IoT devices is not merely a technical decision but a strategic one. It requires a deep understanding of the trade-offs between security level, cost, power consumption, and operational complexity. Instead of seeking a universal solution, architects should adopt an adaptive approach, combining hardware and software mechanisms according to the risk profile and resource capabilities of each device class. Investing in hardware roots of trust for critical components and developing robust key lifecycle processes are key to building a resilient and scalable IoT ecosystem.