V5: Hardware Platform Requirements
Control Objective
Hardware is more difficult and costly to compromise and subvert than software. Therefore hardware security can provide a robust foundation for embedded device security. On the other hand, hardware that contains backdoors or undocumented debug features can completely compromise the security of the entire device even if adequate security measures have been taken on the other layers of the stack.
The purpose of the controls listed in this chapter is to ensure that as long as hardware is available for secure configuration, it is been configured in the most secure way possible. This includes disabling or securing debug interfaces, setting up all existing alarms and sensor mechanisms to combat tampering, using anti-cloning hardware protection such as OTP fuses, and the use of the MMU (Memory Management Unit) for secure process isolation.
This chapter provides the requirements for the hardware platform, to guarantee secure configuration. For example, 3.1.4 discusses correctly configuring Secure Boot, 5.1.2 requires the platform to support this. 5.1.1 requires that the platform supports disabling debug interfaces, 1.2.4 requires that this is applied in production.
Security Verification Requirements
Design
#
Description
L1
L2
L3
5.1.1
Verify that the platform supports disabling or protecting access to debugging interfaces (e.g. JTAG, SWD).
✓
✓
5.1.2
Verify that the platform supports validating the authenticity of the first stage bootloader.
✓
✓
5.1.3
Verify that cryptographic functions are provided by the platform. E.g. by leveraging dedicated functionality provided by the main chip or by external security chips.
✓
✓
5.1.4
Verify that sensitive data such as private keys and certificates can be stored securely by leveraging dedicated hardware security features.
✓
✓
5.1.5
Verify that the platform provides memory and I/O protection capabilities so that only privileged processes can access certain resources.
✓
✓
5.1.6
Verify that the security configuration of the platform can be locked (e.g. through burning OTP fuses).
✓
✓
5.1.7
Verify that debugging headers are removed from PCBs.
✓
✓
5.1.8
Verify the chosen hardware has no unofficially documented debug features, such as special pin configurations that can enable or disable certain functionality.
✓
✓
5.1.9
Verify that the platform provides protection against physical decapsulation, side channel and glitching attacks.
✓
5.1.10
Verify descriptive silkscreens are removed from PCBs
✓
References
For more information, see also:
Common Weakness Enumeration (CWE) Hardware Design: https://cwe.mitre.org/data/definitions/1194.html
IoT Security - Physical and Hardware Security: https://www.embedded.com/iot-security-physical-and-hardware-security/
IETF RFC 8576 - IoT Security: State of the Art and Challenges (5.10 Reverse Engineering Considerations): https://tools.ietf.org/html/rfc8576
ENISA - Baseline Security Recommendations for IoT: https://www.enisa.europa.eu/publications/baseline-security-recommendations-for-iot/at_download/fullReport
GSMA - IoT Security Guidelines for Endpoint Systems: https://www.gsma.com/iot/wp-content/uploads/2017/10/CLP.13-v2.0.pdf
NSA Hardware and Firmware Security Guidance: https://github.com/nsacyber/Hardware-and-Firmware-Security-Guidance
Last updated