Skip to main content

4 Server Platform Security Rules

Security rules straddle hardware and firmware.

ID#Rule
SEC_010The server platform MUST implement a hardware Root of Trust (RoT) ([19]) as a dedicated and trusted subsystem, isolated from the application processor, to provide security-specific functions.
A Root of Trust (RoT) is a component that performs one or more security-specific functions, such as measurement, storage, reporting, verification, update, security lifecycle management, and key derivation. An RoT is typically a combination of a minimal amount of hardware and firmware that must be implicitly trusted by all system components to always behave as expected, since its misbehavior cannot be detected under normal operation. A hardware RoT moves critical functions and assets off the application processor hart to a dedicated and isolated trusted subsystem, which provides stronger protection against both physical and logical attacks. Examples of open-source RoT IPs include OpenTitan ([20]) and Caliptra ([21]).
SEC_020The hardware RoT MUST manage a security lifecycle.
A security lifecycle reflects the trustworthiness of a system throughout its lifetime and indicates the lifecycle state of hardware-provisioned assets. The minimum security lifecycle should include the following states: - Manufacture – The system may not yet be locked down and contains no hardware-provisioned assets. - Security Provisioning – The process of provisioning hardware-provisioned assets. - Secured – Hardware-provisioned assets are locked (immutable); only authorized software may be executed, and revealing debug capabilities are disabled. - Recoverable Debug – Part of the system is in a revealing debug state. The RoT remains uncompromised, and hardware-provisioned secrets remain protected. - Terminated – Hardware-provisioned assets are permanently inaccessible and revoked prior to entering this state. This includes derived assets such as attestation keys.
SEC_030The hardware RoT SHOULD implement a secure identity and SHOULD support platform attestation.
A secure identity is an element capable of generating a cryptographic signature that can be verified by a relying party. It represents the immutable part of the secure platform—​such as immutable hardware, configurations, and firmware. Immutable components cannot be modified after the completion of security provisioning. See ([22]) for examples of secure identity derivation and use. Attestation is the process of vouching for the accuracy of information ([19]). Platform attestation enables a relying party to determine the trustworthiness of the platform before submitting sensitive assets to it. See ([23]) for an example of the protocols used for attestation. The attestation must be signed by the hardware RoT using a hardware-provisioned secure identity or a cryptographic key derived in a verifiable manner from that identity.
SEC_040The firmware MUST implement UEFI Secure Boot and Driver Signing ([5] Section 32, "Secure Boot and Driver Signing")
SEC_050For systems that are not intended to be locked down, or that are intended to be locked down but have not been locked down yet, it MUST be possible for a physically present and/or strongly authenticated out-of-band management user to disable Secure Boot enforcement, thus allowing unsigned code to be executed.
SEC_060For systems that are not intended to be locked down, or that are intended to be locked down but have not been locked down yet, it MUST be possible for a physically present and/or strongly authenticated out-of-band management user to fully manage the contents of the PK, KEK, db and dbx Secure Boot key stores. This includes the ability to delete all factory-provided keys, enroll their own custom keys, and reset the key stores to their factory state.
The term "locked down" refers to the (optional) ability to prevent the Secure Boot configuration from being modified further once the desired security lifecycle state has been reached. This could be implemented, for example, via an eFuse. Note that the "locked down" state is distinct from the "Deployed Mode" Secure Boot state defined in the UEFI spec. Being able to prevent even a physically present user from altering the Secure Boot configuration can be useful in the context of highly regulated industries or government bodies.
SEC_070The platform and firmware MUST back the UEFI Authenticated Variables implementation with a mechanism that cannot be accessed or tampered by an unauthorized software or hardware agent.
SEC_080The firmware MUST implement in-band firmware updates as per [16].
SEC_090Firmware update payloads MUST be digitally signed.
SEC_100Firmware update signatures MUST be validated before being applied.
Cryptographic algorithms and key sizes used for firmware update signing and verification should comply with the security and regulatory requirements of the geographies or markets in which the platform operates. Examples of relevant standards include the U.S. National Institute of Standards and Technology (NIST) cryptographic guidelines and the Commercial National Security Algorithm (CNSA) Suite.
SEC_110It MUST NOT be possible to bypass secure boot, authentication or digital signature failures, except as specified in SEC_050 and SEC_060.