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

7.4 Workload Confidentiality

NIST platform security: roots of trust, firmware and secure enclaves IR 8320
All changes in this version
first version loaded 7 Cloud Use Case Scenarios Leveraging Hardware-Enabled Security part of 7

Title

Workload Confidentiality

Control

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 to encrypt their workload images can provide at-rest cryptographic isolation to protect customer data and intellectual property. Key control is integral to the workload encryption process. While it is preferable to transition key storage, management, and ownership to the endpoint customer, an appropriate key release policy must be defined that includes a guarantee from the service provider that the utilized hardware platform and firmware are secure and uncompromised.

There are several key management solutions (KMSs) in production that provide services to create and store keys. Many of these are compliant with the industry-standardized Key Management Interoperability Protocol (KMIP) or Public Key Cryptography Standards (PKCS) #11 over a network connection and can be deployed within customer enterprises. The concept is to provide a thin layer on top of the KMS called a key broker , as illustrated in Figure 5 , that applies and evaluates policies to requests that come into the KMS. Supported requests to the key broker include key creation, key release policy association, and key request by evaluating associated policies. The key release policy can be any arbitrary set of rules that must be fulfilled before a key is released. The policy for key release is open-ended and meant to be easily extendible, but for the purpose of this discussion, a policy associated with platform trust is assumed. Figure 5: Notional Example of Key Brokerage

Once the key policy has been determined, a KMS-created and managed key can be used to encrypt a workload image, as shown in Figure 6 . The enterprise user may then upload the encrypted image to a CSP orchestrator image store or registry.

Figure 6: Notional Example of Workload Image Encryption

The key retrieval and decryption process is the most complex piece of the workload confidentiality story, as Figure 7 shows. It relies on a secure key transfer between the enterprise and CSP with an appropriate key release policy managed by the key broker. The key is released to the workload server to decrypt the encrypted workload and launch it. The policy for key release discussed here is based on platform trust and the valid proof thereof. The policy can also dictate a requirement to wrap the key using a public wrapping key, with the private portion of the wrapping key only known to the hardware platform within the CSP. Figure 7: Notional Example of Workload Decryption

When the runtime node service receives the launch request, it can detect that the image is encrypted and make a request to retrieve the decryption key. This request can be passed through an attestation service so that an internal trust evaluation for the platform can be performed. The key request is forwarded to the key broker with proof that the platform has been attested. The key broker can then verify the attested platform report and release the key back to the CSP and node runtime services. At that time the node runtime can decrypt the image and proceed with the normal workload orchestration. The disk encryption kernel subsystem can provide at-rest encryption for the workload on the platform.