BaselineWatch
Desk
Your fleet and your work Fleetyour releases and the hardware they run onTriagewhat needs a decisionWatchlistthe products and platforms you runSaved searchesthe lists you come back to
This instance Sourceswhat is read, how often, under what termsDigestthe daily or weekly summary, and alerts
How it is drawn Appearancethe look and the colour schemeBrandingthe mark this instance wears
Owner sign-in

5 Automate Lifecycle 270

NIST platform security: roots of trust, firmware and secure enclaves IR 8320D (Draft)
All changes in this version
first version loaded 5 Automate Lifecycle 270

Title

Automate Lifecycle 270

Control

Fig. 1. Stage 0 Implementation: Typical Enterprise-Grade Machine Identity Management 271

For more detailed information and the solution architecture for Stage 0, please refer to Sec. 3 of 272 IR 8320C [IR8320C] . 273

Stage 1: Secret Key In-Use Protection with Hardware-Based Confidential 274 Computing 275

This section describes Stage 1 of the prototype implementation: protecting secret keys in-use 276 with hardware-based confidential computing. 277 Mechanisms to protect secret keys in-use exist. An attached or network-based hardware security 278 module (HSM) performs cryptographic processing inside the HSM 1 where the private key is 279 stored. Therefore, loading the key into RAM is not necessary. However, while this works in 280 some deployments, it’s not suited for dynamic and multi-tenant environments such as public or 281 private cloud and edge. In these environments, workloads can get scheduled on any host and 282 using an HSM has additional operational and performance costs. A solution that works in these 283 environments is desirable. This means a solution that does not require additional hardware, can 284 scale if needed and, ideally, uses software configuration and deployment paradigms. The 285 solution described in this document uses confidential computing to protect keys in-use. 286 Confidential computing uses trusted execution environments (TEEs) to protect secrets from other 287 software running on the host, including privileged software like the operating system (OS), 288 hypervisor, and firmware. Software that operates on the secrets also runs in the TEE so that 289 secrets never need to get loaded into regular RAM. TEEs provide isolated areas of execution. 290

1 See Sec. 7.5, “Protecting Keys and Secrets” in NIST IR 8320 [IR8320] . Programmable TEE implementations may support attestability , the ability for a TEE to “provide 291 evidence or measurements of its origin and current state, so that the evidence can be verified by 292 another party and—programmatically or manually—it can decide whether to trust code running 293 in the TEE. It is typically important that such evidence is signed by hardware that can be 294 vouched for by a manufacturer, so that the party checking the evidence has strong assurances that 295 it was not generated by malware or other unauthorized parties.” [ConfCC] The evidence can 296 contain the public key part of an ephemeral public/private key pair generated inside the TEE. 2 297 The relying party can wrap secrets with the TEE public key 3 before sharing them with the TEE. 298 Considerations such as the freshness of the evidence and protection against replay attacks are 299 TEE technology-dependent. For more detailed information on this solution and the use of TEE, 300 please refer to Sec. 4 of IR 8320C [IR8320C] . 301 Fig. 2 shows a detailed view of the interactions between the workload on the host and the TEE. It 302 also shows the transfer of the private key from the network HSM. Components in Fig. 2 include 303 the client, workload, TEE adapter, TEE, and TEE attestation and network HSM proxy. 304

Fig. 2. Private Key Protection Flows 305

2 The public key could also be communicated to the relying party separately and its hash included in the evidence. By checking that the hash of the public key and the hash in the evidence match, the relying party ensures that the public key has been generated inside a TEE. 3 This can be done in two steps. First, a Symmetric Wrapping Key (SWK) is generated by the relying party. The SWK is then wrapped with the TEE public key and sent to the TEE. The relying party can then share secrets with the TEE after wrapping them with the SWK. For detailed information about the solution overview and the interaction of its components, 306 please refer to Sec. 4 of IR 8320C [IR8320C] . 307

Stage 2: Machine Identity Management and End-to-End Protection 308

This section describes Stage 2 of the prototype implementation, which brings together the Stage 309 0 and Stage 1 prototypes. 310 In-use secret key protection with hardware-based confidential computing provides a level of 311 protection that is not available from traditional machine identity management solutions. In 312 dynamic and multi-tenant environments such as public or private cloud and edge, secret key 313 protection typically relies on software controls. Software controls can be circumvented by 314 malicious agents because of vulnerabilities in the software, a malicious administrator, or poor 315 operational procedures. On the other hand, confidential computing protects sensitive data such as 316 secret keys with hardware-based mechanisms that are supported by the CPU. This allows the 317 hardware-based protection of secret keys. 318 Fig. 3 shows the high-level architecture of the prototype. There are two distinct workflows in the 319 figure: the configuration and provisioning flows are depicted by the gray dashed lines, and the 320 runtime flows are depicted by the green dotted lines. 321

Fig. 3. High-Level Prototype Architecture 322

Please refer to Sec. 5 of IR 8320C [IR8320C] for the detailed steps for the configuration and 323 provisioning flows and the runtime flows. 324 References 325

[ConfCC] Confidential Computing Consortium (2021) A Technical Analysis of Confidential 326 Computing. https://confidentialcomputing.io/wp- 327 content/uploads/sites/85/2021/03/CCC-Tech-Analysis-Confidential-Computing- 328 V1.pdf 329 [IR8320] Bartock M, Souppaya M, Savino R, Knoll T, Shetty U, Cherfaoui M, Yeluri R, 330 Malhotra A, Banks D, Jordan M, Pendarakis D, Rao JR, Romness P, Scarfone KA 331 (2022) Hardware-Enabled Security: Enabling a Layered Approach to Platform 332 Security for Cloud and Edge Computing Use Cases. (National Institute of 333 Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal 334 Report (IR) 8320. https://doi.org/10.6028/NIST.IR.8320 335 [IR8320C] Bartock M, Souppaya M, Cherfaoui M, Xie J, Cleary P (2022) Hardware-Enabled 336 Security: Machine Identity Management and Protection. (National Institute of 337 Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal 338 Report (IR) 8320C. https://doi.org/10.6028/NIST.IR.8320C.ipd 339 [Polydys] Polydys ML, Wisseman S (2009) Software Assurance in Acquisition: Mitigating 340 Risks to the Enterprise. https://apps.dtic.mil/dtic/tr/fulltext/u2/a495389.pdf 341