Key Management and vTPM Protection

ZSphere supports an external Key Management Service (KMS) or a Native Key Provider (NKP) to supply keys for encrypting virtual Trusted Platform Module (vTPM) state, reducing the risk of offline disclosure of TPM state files. Both options use the same VM protection workflow. Their main differences are the key source, management approach, and recovery requirements.

Environments with an existing centralized key management system can connect to an external KMS. Environments without an external service can use an NKP. A vTPM provides trusted computing capabilities to the guest operating system, allowing features such as BitLocker to protect disks. Connecting a key provider does not automatically enable TPM for VMs or encrypt their system or data disks.

Key Provider Options

A Standard Key Provider connects to an external KMS through KMIP. A Native Key Provider supplies keys through a local platform backend. The main differences are as follows:

Item	Standard Key Provider (External KMS)	Native Key Provider (NKP)
Key source	Creates or retrieves resource keys from an external key management service through KMIP.	Manages keys through a local platform backend.
Connection and runtime dependencies	Requires a service address, port, protocol version, client identity, and server trust material. The external service must remain reachable.	The platform initializes the key backend and maintains key versions. It depends on the platform's root key material and synchronization between management nodes.
Backup and recovery	Backup and high availability of external keys depend on the KMS deployment.	Supports separate backup and recovery, with optional password protection for backup files.
Security boundary	Key management can be integrated into a separate management system. The platform still needs to retrieve and use resource keys.	Keys reside within the platform's management domain. Their protection depends on the security of the platform and its root key material.

Architecture and Mechanism

The management service uses a unified resource key interface to establish key references for vTPMs and provide hosts with resource keys from the specified key provider. KMS and NKP use different key sources, but share the subsequent host identity verification, key delivery, and TPM state protection workflow.

The management service retrieves resource keys from KMS or NKP through key-tool, verifies host identity, and wraps the keys for delivery. Host components use the keys to protect TPM state. — Figure 1. Shared vTPM Key Protection Workflow for KMS and NKP

The management node uses key-tool to create or retrieve resource keys from the specified provider. The external KMS uses a KMIP backend, while the NKP uses the platform's local backend.
Before delivering keys, the management service checks the target host's public key and fingerprint verification status, and wraps the resource keys using HPKE.
On the host, the KVM Agent and key-agent work together to prepare a libvirt Secret for the TPM backend.
swtpm uses the key to protect TPM backend state. The guest operating system uses trusted computing capabilities through the vTPM device without directly accessing KMS or NKP.

Key Protection Throughout the VM Lifecycle

vTPM state, key references, and the keys in the provider must remain consistent. The platform prepares the required keys and host resources during VM creation, startup, migration, and recovery.

Lifecycle Stage	Protection Mechanism and Requirements
Creation and enablement	A key provider is specified for the vTPM. If no provider is explicitly specified, the default provider can be used. An external KMS requires authentication and trust material. When an NKP is created, it initializes the local backend and synchronizes the root key. Its initial backup status is Not Backed Up. A separate backup is recommended before use.
Startup and restart	The platform checks for an existing Secret on the host and reuses it if available. Otherwise, it retrieves the resource key from the key provider and delivers it to the host. Restarting the guest operating system and restarting the VM process through the platform involve different key preparation procedures.
Migration	The platform prepares the keys and Secrets for existing resources on the target host. TPM state and key references must remain consistent during migration.
Snapshots and cloning	TPM state and key references must remain consistent when snapshots are created or restored. If the TPM is reset during cloning, credentials bound to the original TPM in the guest operating system must be recovered or rebound according to operating system requirements.
Backup and recovery	A VM backup includes TPM state and key reference information, but does not replace a backup of the key provider itself. After KMS recovery, the original keys must remain accessible. NKP recovery requires a backup of the original provider to restore its root key and metadata. Creating a new NKP with the same name does not restore the original keys.
Deletion and destruction	When a TPM is removed or a VM is permanently deleted, the platform performs cleanup of TPM state, key references, and host Secrets. Deleting a KMS configuration does not destroy external keys or mean that all historical copies have been cryptographically erased. Check dependencies involving VMs, snapshots, and backups before deletion.

Changing the default key provider does not automatically change existing resource bindings. Switching existing resources to another provider requires a separate re-encryption operation. If the target provider is an NKP, it must be backed up first.

Failure Handling and Recovery

Key retrieval or identity verification failure: An unreachable KMS, incomplete authentication material, an unavailable local NKP key service, or lost root key material can cause operations that require key retrieval to fail. The platform refuses to deliver keys if host public key verification fails, and blocks migration if Secret preparation on the target host fails. The platform does not directly shut down a running VM solely because its key provider disconnects. Whether subsequent operations succeed depends on whether the keys must be retrieved again.
Key provider recovery failure: During NKP recovery, the platform validates the provider name and UUID, and imports the original root key and metadata. Incorrect backup contents or an incorrect protection password cause parsing or import to fail. Recovery is rejected if the name or UUID conflicts with an existing provider.
Node synchronization failure: If NKP node synchronization fails, the platform records the failure and retries. Node synchronization and separate backups serve different purposes. Keep a separate provider backup so that keys can be recovered after a platform failure or rebuild.

Applicable Environments

vTPM protection is based on KVM virtualization and works with UEFI/NVRAM. Hosts require a key service and components such as libvirt, QEMU, and swtpm. The guest operating system requires the corresponding TPM driver. External KMS services connect through KMIP. Specific product and protocol version combinations are subject to interoperability validation results.

A vTPM provides trusted computing capabilities to the guest operating system. To use disk protection features such as BitLocker, install or configure the corresponding features in the operating system and securely retain recovery credentials.

Security and Operations Requirements

Key and backup protection: The management service and hosts need to use resource keys at runtime. An external KMS provides independent key management, but this does not mean that keys never leave the KMS. Password protection is recommended for NKP backups. Store the password separately from the backup file.
Deployment and capacity: Resource preparation, startup that requires key retrieval, migration, and recovery involve key requests, wrapping, and host preparation. An NKP also requires local backend calls and node synchronization. Guest disk reads and writes do not require an external KMS request for every I/O operation. When planning a deployment, assess key service capacity and availability against bulk VM startup, HA restart, concurrent migration, and failure recovery requirements.
Management and auditing: The platform supports key provider management, default provider configuration, resource re-encryption, KMS certificate and client identity management, and NKP backup and recovery. Management operations primarily require administrator permissions, while query operations have separate authorization controls. The platform provides audit records for management operations such as provider creation, update, deletion, and NKP backup and recovery.

PreviousEncrypted Password Storage NextResource Deletion Protection