NIST platform security: roots of trust, firmware and secure enclaves IR 8320
All1 Introduction2 Hardware Platform Security Overview3 Platform Integrity Verification4 Software Runtime Protection Mechanisms5 Data Protection and Confidential Computing6 Remote Attestation Services7 Cloud Use Case Scenarios Leveraging Hardware-Enabled Security8 Next Steps
| Ref | Title | Text | |
|---|---|---|---|
| 1 | Introduction | In data centers and edge computing, there are three significant forces that impact security: (1) the introduction of billions of connected devices and increased adoption of the cloud have significantly increased attack surfaces; (2) hacking | |
| 2 | Hardware Platform Security Overview | The data center threat landscape has evolved in recent years to encompass more advanced attack surfaces with more persistent attack mechanisms. With increased attention being applied to high- level software security, attackers are pushing l | |
| 3 | Platform Integrity Verification | A key concept of trusted computing is verification of the underlying platform’s integrity. Platform integrity is typically comprised of two parts: • Cryptographic measurement of software and firmware. In this report, the term measurement r | |
| 3.1 in 3 |
Hardware Security Module (HSM) | A hardware security module (HSM) is “a physical computing device that safeguards and manages cryptographic keys and provides cryptographic processing” [5] . Cryptographic operations such as encryption, decryption, and signature generation/v | |
| 3.2 in 3 |
The Chain of Trust (CoT) | The chain of trust (CoT) is a method for maintaining valid trust boundaries by applying a principle of transitive trust. Each firmware module in the system boot process is required to measure the next module before transitioning control. On | |
| 3.3 in 3 |
Supply Chain Protection | Organizations are increasingly at risk of supply chain compromise, whether intentional or unintentional. Managing cyber supply chain risks requires, in part, ensuring the integrity, quality, and resilience of the supply chain, its products, | |
| 4 | Software Runtime Protection Mechanisms | This section describes various software runtime attacks and protection mechanisms. | |
| 4.1 in 4 |
Return Oriented Programming (ROP) and Call/Jump Oriented Programming | (COP/JOP) Attacks ROP attacks focus on utilizing buffer overflows and targeted memory overwrites of return addresses in the stack. Attackers redirect return flows by corrupting addresses on the data stack to be locations in already-executa | |
| 4.2 in 4 |
Address Translation Attacks | Commodity OSs rely on virtual memory protection models enabled via paging enforced by the processor memory management unit (MMU). OSs isolate process and kernel memory using page tables managed by systems software, with access permissions s | |
| 4.3 in 4 |
Memory Safety Violations | Approximately 70 percent of the vulnerabilities addressed through security updates each year are memory safety issues [12] . They are especially common in programs written in languages such as C and C++ that expose pointers. These code bugs | |
| 4.4 in 4 |
Side-Channel Attacks | The vulnerability underlying cache timing side-channel attacks is that the pattern of allocations into the cache of a central processing unit (CPU), and, in particular, which cache sets have been used for the allocation, can be determined b | |
| 5 | Data Protection and Confidential Computing | With the increase in adoption of customer-based cloud services, virtualization has become a necessity in cloud data center infrastructure. Virtualization simulates hardware for multiple cloud workloads. Each workload is isolated from others | |
| 5.1 in 5 |
Memory Isolation | There are many technologies that provide data protection via encryption. Most of these solutions focus on protecting the respective data while at rest and do not cover the fact that the data is decrypted and vulnerable while in use. Applica | |
| 5.2 in 5 |
Application Isolation | Application isolation utilizes a TEE to help protect the memory reserved for an individual application. The trust boundary associated with the application is restricted to only the CPU. Future generations of these techniques will allow enti | |
| 5.3 in 5 |
VM Isolation | As new memory and execution isolation technologies become available, it is more feasible to isolate entire VMs. VMs already enjoy a degree of isolation due to technologies like hardware- assisted virtualization, but the memory of each VM re | |
| 5.4 in 5 |
Cryptographic Acceleration | Encryption is quickly becoming more widespread in data center applications as industry adopts more standards and guidelines regarding the sensitivity of customer data and intellectual property. Because cryptographic operations can drain sys | |
| 6 | Remote Attestation Services | Measuring a server’s firmware/configuration and extending these measurements to a root of trust for storage and reporting can help keep track of which firmware is running on a platform. Some platform integrity technologies can even perform | |
| 6.1 in 6 |
Platform Attestation | Figure 1 shows a remote attestation service (AS) collecting platform configurations and integrity measurements from data center servers at a cloud service provider (CSP) via a trust agent service running on the platform servers. A cloud ope | |
| 6.2 in 6 |
Remote TEE Attestation | There are instances when the high assurance that the output of the processing in a TEE can be trusted should be conveyed to a relying party. This is achieved thanks to a TEE attestation flow. Remote TEE attestation involves the generation o | |
| 7 | Cloud Use Case Scenarios Leveraging Hardware-Enabled Security | This section describes a number of cloud use case scenarios that take advantage of the hardware- enabled security capability and trust attestation capability integrated with an operator orchestration tool to support various security and com | |
| 7.1 in 7 |
Visibility to Security Infrastructure | A typical attestation includes validation of the integrity of platform firmware measurements. These measurements are unique to a specific BIOS/UEFI version, meaning that the attestation report provides visibility into the specific firmware | |
| 7.2 in 7 |
Workload Placement on Trusted Platforms | Platform information and verified firmware/configuration measurements retained within an attestation service can be used for policy enforcement in countless use cases. One example is orchestration scheduling. Cloud orchestrators, such as Ku | |
| 7.3 in 7 |
Asset Tagging and Trusted Location | Trusted geolocation is a specific implementation of the aforementioned trusted asset tag feature used with platform attestation. Key attribute values specifying location information are used as asset tags and provisioned to server hardware, | |
| 7.4 in 7 |
Workload Confidentiality | Customers who place their workloads in the cloud or the edge accept that their workloads are secured by their service providers, typically without insight or knowledge as to what security mechanisms are in place. The ability for end users t | |
| 7.5 in 7 |
Protecting Keys and Secrets | Cryptographic keys are high-value assets in workloads, especially in environments where the owner of the keys is not in complete control of the infrastructure, such as public clouds, edge computing, and network functions virtualization (NFV | |
| 8 | Next Steps | NIST is seeking feedback from the community on the content of the report and soliciting additional technology example contributions from other companies. The report is intended to be a living document that will be frequently updated to refl |
26 of 26.