Three key factors significantly impact security in data centers and edge computing. First, there is a hugely increased number of attack surfaces due to the introduction of billions of connected devices and increased cloud adoption.
Second, sophisticated and constantly developing methods of data compromise are part of the industrialization of hacking. Third, there are incoherent, inconsistent security control implementations in solutions made up of various technologies from various vendors.
This calls for a security strategy to completely secure all systems, including hardware platforms that serve as servers in a data center or edge computing facility where workloads and data are executed and accessed (e.g., application servers, storage servers, virtualization servers).
The hardware platform of a server serves as the first layer of security. Because software and firmware have a larger attack surface and can be modified more easily, hardware-enabled security offers a stronger foundation.
By offering a base-layer, immutable hardware module that links software and firmware verifications from the hardware to the application space or designated security control, hardware-enabled security improves existing security.
Some of the major threats against the platform firmware and hardware include:
- Unauthorized access to and the potential extraction of sensitive platform or user data, including direct physical access to dual in-line memory modules (DIMMs)
- Modification of platform firmware, such as that belonging to the Unified Extensible Firmware Interface (UEFI)/Basic Input/Output System (BIOS), Board Management Controller (BMC), Manageability Engine (ME), Peripheral Component Interconnect Express (PCIe) device, and various accelerator cards.
- Supply chain interception through the physical replacement of firmware or hardware with malicious versions
- Access to data or execution of code outside of regulated geopolitical or other boundaries
- Circumvention of software and/or firmware-based security mechanisms
There are many ways to measure platform integrity, such as:
1. Hardware Security Module (HSM)
A physical computer that manages and protects cryptographic keys and performs cryptographic processing is known as a hardware security module (HSM). The HSM device typically hosts cryptographic operations like encryption, decryption, and signature generation/verification, and many implementations offer hardware-accelerated cryptographic mechanisms.
A particular kind of HSM called a trusted platform module (TPM) can create cryptographic keys and encrypt discrete sensitive data like passwords, cryptographic keys, and cryptographic hash values. The TPM is a standalone device that can be connected to client devices, server platforms, and other items. Storing digest measurements of platform firmware and configuration during boot is one of TPM’s primary use cases.
A digest is created and then extended to the TPM platform configuration register (PCR) to measure each firmware module. Platform-specific specifications like the Trusted Computing Group (TCG) PC Client Platform Firmware Profile provide guidelines for determining which firmware measurements each PCR includes. Multiple firmware modules can be added to the same PCR.
Additionally, TPMs can create binding and signing keys specific to each TPM and kept in the non-volatile random-access memory of the TPM (NVRAM). This key pair’s private portion is decrypted inside the TPM, so only the TPM’s hardware or firmware can access it. Limiting private keys to the platform firmware with ownership and access to the designated TPM can establish a special relationship between the keys generated within a TPM and a platform system. While signing keys are used to create and validate cryptographic signatures, binding keys encrypt and decrypt data. A random number generator (RNG) is a protected capability that the TPM offers without access controls. This RNG serves as an entropy source for nonces, key generation, and signature randomness in crucial cryptographic operations.
2. The Chain of Trust (CoT)
The chain of trust (CoT) technique uses the transitive trust principle to maintain legitimate trust boundaries. Before passing control to the following firmware module during the system boot process, the current module must be measured. It is advised to immediately store the measurement value of a firmware module measurement in a root of trust, such as an HSM register, for later attestation. The CoT can be expanded into the application domain, enabling the measurement and attestation of files, directories, devices, peripherals, etc.
The RoT module is the first CoT component. It may be made up of various hardware and firmware parts. Immutable read-only memory (ROM) code is the foundation of the RoT core firmware module for several platform integrity technologies. Not all technologies, however, define their RoTs in this way. Typically, the RoT is divided into components for measuring and verifying. Before giving control to the first component, the core RoT for verification (CRTV) is in charge of verifying it. The first component to be executed in the CoT is the core RoT for measurement (CRTM), which extends the initial measurement to the TPM. The CRTM can be split into a dynamic and static portion (SCRTM) (DCRTM). Except for volatile attributes like date and time, the SCRTM comprises components that measure firmware at system boot time. This results in a stable set of measurements that remain constant across reboots. The RoT for measurement can be dynamically reestablished thanks to the DCRTM, which enables a CoT to be established without having to restart the system.
While an RoT built entirely of firmware can be flashed and modified, one built with hardware protections will be more challenging to change. The danger of an immutable hardware RoT is that it can’t be patched. The RoT should be maintained as low as possible. Firmware is a particular category of computer software that, in the context of this publication, provides low-level control for a device’s particular hardware.
