This section explains the concepts of Roots of Trust (RoT) and Chains of Trust (CoT) in security architectures. Here are the key points:
- Roots of Trust (RoT): A Root of Trust is a fundamental security component that provides essential functions like measurement, storage, reporting, recovery, verification, and updates. RoTs must always behave as expected since any misbehavior cannot be detected. RoTs serve as the starting point in a Chain of Trust to extend secure functionality.
- Chains of Trust (CoT): A Chain of Trust extends security by linking successive trusted elements to perform secure operations. For example, a Recovery RoT (RTRec) initiates recovery by launching trusted components that execute recovery processes. Components within a CoT have elevated privileges for security functions (e.g., device updates) but can relinquish them once tasks are complete.
- Security Considerations: RoTs must be secure by design, with a focus on minimizing the attack surface and implementing robust mitigations. Vendors ensure trustworthiness by: Making RoTs immutable. Verifying the integrity and authenticity of any updates. Running RoTs in isolated environments or with higher privileges to prevent tampering.
- Platform-Level RoTs: Complex platforms may have multiple independent RoTs and CoTs due to different devices and manufacturers. Example: A hard disk controller and a host platform may each have independent chains of trust for recovery in case of firmware corruption.
- RoT Foundation: All security mechanisms should be built on Root of Trust (RoT) principles to ensure a secure foundation.
- CoT Anchored in RoT: If a Chain of Trust (CoT) is used, it must be anchored by a Root of Trust (RoT) to maintain security.
- Protection from Tampering: RoTs and CoTs must be designed to resist tampering by software or malicious actions from the operating system.
- Non-volatile Storage: Elements of the CoT (for Update, Detection, and Recovery) must be stored in platform firmware to ensure persistence and reliability.
Root of Trust for Update (RTU) and Chain of Trust for Update (CTU)
- Authenticating Updates: Devices with mutable firmware must use either an RTU or CTU to authenticate firmware updates.
- Update Mechanism: If the RTU or CTU is mutable, it must support authenticated updates and be recoverable after catastrophic events, such as power loss.
- Digital Signatures: The RTU or CTU must include a key store and use a compliant digital signature algorithm (e.g., FIPS 186-4) for verifying update images.
- Key Store Updates: The key store must be updated using authenticated mechanisms, with physical presence required for secure local updates.
Root of Trust for Detection (RTD) and Chain of Trust for Detection (CTD)
- Detection Mechanisms: Devices with detection capabilities must rely on an RTD or CTD to detect firmware and data corruption.
- Corruption Detection: The RTD or CTD should include or have access to the necessary information to detect corruption of firmware and critical data.
Root of Trust for Recovery (RTRec) and Chain of Trust for Recovery (CTRec)
- Recovery Capabilities: Devices implementing recovery mechanisms must rely on an RTRec or CTRec to manage recovery after corruption is detected or when instructed by an administrator.
- Performing Recovery: The RTRec or CTRec should perform recovery operations to restore firmware and critical data to a valid state.
