Internet-Draft CVMP December 2023
Deng & Yu Expires 3 June 2024 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
Confidential Virtual Machine Provisioning in Cloud Environment
Published:
Intended Status:
Informational
Expires:
Authors:
J. Deng
G. Yu

Confidential Virtual Machine Provisioning in Cloud Environment

Abstract

This document specifies the procedures of provisioning confidential virtual machine in the cloud environment.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 3 June 2024.

Table of Contents

1. Introduction

Confidential computing protects workload and data in use leveraging hardware-based security technology. Confidential virtual machine (CVM) in the cloud environment is one use case of confidential computing. There is an increasing adoption of CVMs in the cloud. CVM allows a cloud tenant to protect the sensitive workload and data, and manage the cryptography keys independently from the cloud service providers.

When adopting CVMs in the cloud, the CVM features, CVM provisioning and management of cryptography keys, etc. depend on different hardware. Common CVM provisioning procedures and requirements are needed. This document specifies the procedures of provisioning CVMs in the cloud environment and the requirements.

2. Terms

The following terms are used in this document.

3. Procedures of CVM Provisioning in Cloud Environment

The procedures of CVM provisioning in Cloud Environment includes the following:

3.1. Feature Acquirement

Before creating a CVM instance, Cloud Tenant acquires the supported CVM features from CVM platform. Figure 1 shows example feature acquirement between Cloud Tenant and CVM Platform. CVMFeatureRequest message is sent by Cloud Tenant to CVM Platform requesting the supported CVM features. CVM returns CVMFeatureResponse carrying a list of supported features, which may include:

  • SecureBoot: whether secure boot is supported.
  • LiveMigration: whether live migration is supported.
  • AuxilaryFirmware: whether allows Cloud Tenant to specify firmware to be used.
  • BIOS: whether allows Cloud Tenant to customize BIOS.
  • SVN: whether allows Cloud Tenant to specifies SVN.

+--------+                     +----------+
| Cloud  |                     |   CVM    |
| Tenant |                     | Platform |
+--------+                     +----------+
        |                              |
        |                              |
        |      CVMFeatureRequest       |
        |----------------------------->|
        |                              |
        |                              |
        |      CVMFeatureResponse      |
        |<-----------------------------|
        |                              |


Figure 1: CVM feature acquirement

3.2. CVM Creation

Figure 2 shows that Cloud Tenant requests to create CVM instance(s) and CVM Platform responds with the creation result. In the CVMCreateRequest message requesting CVM creation, Client tenant provides the requested features. The features are described as in Section 3.1. CVM Platform returns with CVMCreateResponse. If the creation is successful, in CVMCreateResponse message, CVM Platform indicated successful CVM creation and returns information on the features requested by Cloud Tenant.


+--------+                 +----------+
| Cloud  |                 |   CVM    |
| Tenant |                 | Platform |
+--------+                 +----------+
        |                           |
        |    CVMCreateRequest       |
        |-------------------------->|
        |                           |
        |  CVMCreateResponse        |
        |<--------------------------|
        |                           |


Figure 2: CVM instance creation

3.3. Key Provisioning

The key provisioning consists of Policy Setup, Key Allocation, Key Acquirement, and Key Update between Key Agent and Key Server.

The security considerations for the communication between Key Agent and Key Server are presented in Section 5.

3.3.1. Policy Setup

In Policy Setup, Cloud Tenant provides Key server with information needed for Key Allocation, Key Acquirement, and Key Update. The information at least includes SVN, measurements, etc. Figure 3 shows example Keying Policy setup between Key Agent and Key Server.


        +--------+                        +--------+
        | Cloud  |                        |  Key   |
        | Tenant |                        | Server |
        +--------+                        +--------+
                |                                 |
                |  SetKeyPolicy                   |
                |-------------------------------->|
                |                                 |
                |                 PolicyResponse  |
                |<--------------------------------|
                |                                 |


Figure 3: Key provisioning

3.3.2. Key Allocation

Figure 4 shows example key allocation. Key Agent sends KeyAllocRequest message to Key Server to request a new security key. Key Server then allocates a KeyID, generates and saves a root key for Key Agent, derives a security key from the root key with input parameters including the SVN provided by Key Agent, and returns the KeyID and Security Key. Allocation usually occurs when CVM is started for the first time, and CVM needs to use Security Key for encryption.


        +--------+                        +--------+
        | Key    |                        |  Key   |
        | Agent  |                        | Server |
        +--------+                        +--------+
                |                                 |
                |  KeyAllocRequest                |
                |-------------------------------->|
                |                KeyAllocResponse |
                |<--------------------------------|


Figure 4: Key provisioning

3.3.3. Key Acquirement

Figure 5 shows example key acquirement where Key Agent acquires a pre-allocated Security Key with the KeyID.


        +--------+                        +--------+
        | Key    |                        |  Key   |
        | Agent  |                        | Server |
        +--------+                        +--------+
                |                                 |
                |  KeyAcquireRequest              |
                |-------------------------------->|
                |              KeyAcquireResponse |
                |<--------------------------------|


Figure 5: Key provisioning

3.3.4. Key Update

Key Agent within a CVM may chose to update the minimal required SVN of the Key by sending KeyUpdateRequest to Key Server. Key Server will only update the SVN if the old SVN with the Key Agent is lower than the target SVN. After successful SVN update, a Key Agent with outdated SVN cannot acquire the Security Key with the pre-allocated KeyID. A CVM which meets the requirement of minimum SVN can request the Key Server to re-allocate a new Security Key from the corresponding root key. Figure 6 shows example key update.


        +--------+                        +--------+
        | Key    |                        |  Key   |
        | Agent  |                        | Server |
        +--------+                        +--------+
                |                                 |
                |  KeyUpdateRequest               |
                |-------------------------------->|
                |              KeyUpdateResponse  |
                |<--------------------------------|


Figure 6: Key Update

3.4. CVM Management

This section presents the procedures for CVM management.

4. IANA Considerations

This memo includes no request to IANA.

5. Security Considerations

5.1. Communication Security Between Key Agent and Key Server

Key Agent and Key server are mutually authenticated and the communications between them are confidentially and integrity protected. The security can leverage the attestation evidence in [RFC9334]. The messages can use CBOR and the security wrapper as in [RFC9052].

5.2. Communication Security Between Cloud Tenant and Key Server

This section considers the communication security between Cloud Tenant and Key Server.

6. References

6.1. Normative References

[RFC9334]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, , <https://www.rfc-editor.org/info/rfc9334>.
[RFC9052]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, , <https://www.rfc-editor.org/info/rfc9052>.

Acknowledgements

Contributors

Authors' Addresses

Juan Deng
Guorui Yu