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

D.2 Solution Architecture 579

NIST platform security: roots of trust, firmware and secure enclaves IR 8320D (Draft)
All changes in this version
first version loaded Appendix D Machine Identity Runtime Protection and Confidential Computing 558 part of D

Title

Solution Architecture 579

Control

Fig. 8 shows how the components of the solution interact with each other in the step-by-step 580 process to launch NGINX workloads utilizing Intel SKC to protect its key. 581 Fig. 8. NGINX Key Transfer Workflow with Secure Key Caching 582

Some workloads deployed by tenants in datacenters that are under the control of a third party 583 (CSPs, edge provider, and enterprise private cloud) use sensitive cryptographic keys. These keys 584 must be adequately protected by tenants. Keys can also be disclosed because of the 585 vulnerabilities in the third-party infrastructure. 586 Key protection can be achieved using an HSM, but this requires ad hoc cloud or edge 587 environment that allows physical access to servers. With SKC, tenants can continue to use 588 standard cloud and edge environments without compromising the confidentiality of their 589 sensitive keys and without additional tools. 590 Fig. 9 details the call flows between the individual components of the solution with the specific 591 information that is transmitted for each interaction in the process of launching NGINX 592 workloads utilizing Intel SKC to protect its key. 593 Fig. 9. NGINX Key Transfer Call Flow 594