Defining remote attestation requirements in critical infrastructure
In critical infrastructure (CI), the compromise of IoT devices can lead to catastrophic consequences, including industrial process failures, downtime, security threats, and significant financial losses. For instance, the 2015 Jeep incident, linked to vehicle software vulnerabilities, resulted in the recall of 1.4 million cars and damaged the brand's reputation. Vulnerable IoT devices can serve as entry points for attackers, allowing unauthorized network access, sensitive data theft, or disruption of critical systems and physical infrastructure.
For such systems, Recovery Point Objective (RPO) and Recovery Time Objective (RTO) are crucial metrics. Mission-critical (Tier 1) systems often require RPO from 'near-zero' to a few minutes, and RTO from a few minutes to less than an hour. In the financial sector, critical transactional systems may demand an RPO of less than 1 minute and an RTO of 15 minutes. Healthcare systems supporting patient care frequently require an RTO of less than 4 hours, with electronic health records needing an RPO measured in minutes.
Simultaneously, IoT devices in CI often have limited computational resources, low power consumption, and may run on outdated software, complicating the implementation of sophisticated security mechanisms. Remote attestation, while effective, can introduce additional latency and computational overhead. Therefore, architecture selection must account for these constraints, ensuring a high level of trust without excessive impact on performance and cost.
Hardware remote attestation architectures (TPM/TEE): Advantages and limitations
Hardware remote attestation architectures, based on Trusted Platform Module (TPM) or Trusted Execution Environment (TEE), offer the highest level of trust and resilience against attacks. TPM, specifically TPM 2.0, is a hardware module that provides a hardware root of trust, securely stores cryptographic keys, and records boot process measurements in Platform Configuration Registers (PCRs). This enables cryptographic verification of a device's state during startup. The Trusted Computing Group (TCG) actively develops attestation standards, including DICE (Device Identifier Composition Engine) specifications, which guide establishing trust in systems with and without TPM.
TEE, such as ARM TrustZone, creates an isolated, secure environment for program execution and confidential data storage, leveraging processor capabilities for isolation. This allows sensitive operations to run in a protected space, isolated from the main operating system.
The advantages of hardware solutions lie in their high resistance to software attacks, as they provide physical tamper-resistance or tamper-evidence. However, TPM 2.0 can introduce a delay of 1 to 10 ms per operation, which might be unacceptable for some low-power IoT devices. Furthermore, implementing hardware modules increases the Bill of Materials (BOM) cost and development complexity. Despite this, investing in secure hardware early in the development cycle often pays off in the long run.
Software remote attestation architectures: Flexibility and risks
Software remote attestation architectures rely solely on software mechanisms to generate and verify system integrity evidence. This approach does not require specialized hardware, making it more accessible for environments where hardware upgrades are impractical or economically unfeasible. The attestation process typically involves executing predefined checks, collecting system measurements, and applying cryptographic methods to protect the integrity of the results.
The primary advantages of software solutions are their flexibility and lower implementation cost. They can be applied to a wide range of existing IoT devices, including those without built-in hardware roots of trust. However, software methods are generally less reliable than hardware ones. Attackers with sufficient privileges can bypass or manipulate the software responsible for generating evidence. They are vulnerable to attacks such as side-channel attacks, rollback attacks, and data memory attacks, which often fall outside their scope.
Performance impact is also a significant factor. Software methods can suffer from high latency. For example, memory checksum-based protocols like SWATT can introduce significant execution overhead due to memory redirection, affecting overall response time. Nevertheless, some developments aim for energy-efficient software solutions on standard hardware.
Hybrid remote attestation architectures: A compromise between security and cost
Hybrid remote attestation architectures combine elements of hardware and software solutions, aiming to achieve an optimal balance between security, performance, and cost. In such approaches, hardware roots of trust are used to protect the most critical parts of the attestation process, such as key storage and initial measurements, while software components handle additional checks or policy enforcement. This allows for a minimal hardware footprint combined with on-device software to provide the necessary guarantees.
The effectiveness of hybrid solutions lies in their ability to mitigate risks inherent in purely software approaches while avoiding the excessive cost and complexity of fully hardware systems. They can provide a level of security comparable to hardware methods while offering the flexibility of software solutions, particularly the ability to operate without constant access to secret keys during response computation.
An example of a hybrid approach includes protocols that use hardware monitoring to ensure the correct execution of the attestation process, signing the final response with a key only when the computation is trustworthy. Such solutions can support interrupts and detect Time-of-Check-Time-of-Use (TOCTOU) attacks, a significant improvement over many software and some hardware methods. Hybrid architectures can also be scalable, such as PUF-enhanced parallel attestation protocols that distribute memory among IoT swarm nodes for rapid verification with built-in hardware security.
Criteria for selecting a remote attestation architecture for critical infrastructure
Choosing the optimal remote attestation architecture for IoT devices in critical infrastructure requires careful analysis across several key criteria:
- Trustworthiness: How resilient the architecture is to attacks and the level of confidence it provides regarding device integrity. Standards like NIST SP 800-193 offer guidance on platform firmware resiliency and mechanisms for protection, detection, and recovery from attacks.
- Impact on device performance: IoT device computational resources and power consumption are often limited. It is essential to assess the latency, throughput, and energy consumption introduced by the attestation mechanism.
- Impact on network performance: The volume of traffic generated by the attestation process can affect network resources, especially in large-scale IoT deployments.
- Implementation and maintenance complexity: How easy it is to integrate the architecture into existing systems, develop, and maintain it throughout the device lifecycle.
- Cost (BOM + development + operation): The total cost of ownership (TCO), including initial hardware costs, software development, and ongoing operational expenses. While hardware solutions may have a higher upfront cost, they are often more economical in the long run regarding operational costs.
- Flexibility and scalability: The architecture's ability to adapt to different device types, use cases, and scale for large deployments.
- Resistance to known attacks: Evaluation of the architecture's ability to withstand common threats such as firmware spoofing, memory attacks, DoS attacks, and physical tampering.
These criteria must be integrated into the decision-making process to ensure that the chosen remote attestation architecture not only meets security requirements but is also practical and economically viable for critical infrastructure.
Remote attestation architecture selection mechanism
| Criterion | Hardware (TPM/TEE) | Software | Hybrid |
|---|---|---|---|
| Trustworthiness | High (hardware root of trust, physical attack resistance) | Low/Medium (vulnerable to software and physical attacks) | Medium/High (combines advantages, mitigates risks) |
| Impact on device performance | Medium (can introduce latency, requires resources) | Medium/High (can have high latency, depends on implementation) | Low/Medium (optimized impact, depends on balance) |
| Impact on network performance | Low (minimal data exchange) | Medium (may require more frequent checks) | Low/Medium (optimized data exchange) |
| Implementation and maintenance complexity | High (hardware integration, development complexity) | Low/Medium (software implementation, flexibility) | Medium (combination of hardware and software aspects) |
| Cost (BOM + development + operation) | High (additional hardware components, specialized development) | Low (utilizes existing hardware) | Medium (optimal balance between components and development) |
| Flexibility and scalability | Low/Medium (depends on hardware support) | High (easily adapts to various devices) | Medium/High (combines adaptability and security) |
| Resistance to known attacks | High (resistance to software and many physical attacks) | Low (vulnerable to software, memory attacks) | Medium/High (improved resistance compared to software) |
At AZIOT, we understand that for cybersecurity heads and IoT solutions architects in critical infrastructure, selecting the right remote attestation architecture is a strategic decision that directly impacts the resilience and security of the entire system. Our experience in designing and implementing comprehensive solutions for industrial IoT enables us to provide expert support in choosing and integrating optimal attestation mechanisms that meet the highest standards of security and performance.
The optimal choice of remote attestation architecture for IoT devices in critical infrastructure is not merely a technical decision but a strategic one. It requires a deep understanding of the trade-offs between trust level, performance, cost, and implementation complexity. A thorough analysis of these factors and the application of hybrid approaches will enable the creation of a resilient and secure architecture capable of protecting critical systems from ever-evolving cyber threats.
Learn more about IoT solution integration and automation at Intecracy solutions and inbase.com.ua solutions.
Source list
- sepiocyber.com
- idb.orgCybersecurity and the Internet of Things (IoT) | IDBExpandExpandExpandSearchSearchToggle MenuPreviousContinueContinueContinueContinueContinueContinueContinueFacebookLinkedinYouTubeExpandExpandExpandToggle Menu CloseSearch
- iasme.co.ukWhat are the consequences of a compromised IoT device? - IASME - Home
- cloudi-fi.comIoT device vulnerability: Definition, risks and prevention
- cisa.gov
- veeam.comRTO vs RPO: What They Mean and How To Set Targets
- sentinelone.comRTO vs RPO: Key Differences in Disaster Recovery Planning
- encryptionconsulting.comHow to Secure IoT Vulnerabilities | Encryption Consulting