Entropy sources in confidential cloud environments

Entropy Sources in Confidential Cloud Environments: Revisiting the BSI 2016 Assessment of RDRAND and RDSEED under Intel TDX and AMD SEV-SNP, a paper of 69 pages written with Ben Lubowski at Hochschule Flensburg.

Abstract

The BSI 2016 study on random number generation in virtual environments established that a Linux guest can obtain sufficient entropy under appropriate configuration, while identifying boot-time entropy starvation, noise source degradation under VMM operation, and a demonstrated interception of RDRAND by a malicious hypervisor. Because that study assumed a non-malicious VMM throughout, its conclusions do not reach the adversarial cloud deployments that motivate the present work. This paper revisits them on current Intel and AMD server hardware and on a Linux kernel whose entropy architecture has since been redesigned rather than refined, and carries them forward into hardware-enforced confidential computing. We assess the min-entropy of RDRAND and RDSEED under NIST SP 800-90B on bare metal on both vendor platforms and in an AMD SEV-SNP guest, we re-examine whether the interception attack demonstrated in 2016 remains feasible on current VMM implementations, using a KVM guest for that part, we establish from the specifications and from hypervisor and firmware source what Intel TDX changes architecturally, and we trace what becomes of the Linux combiner guarantee once the hypervisor is excluded from the Trusted Computing Base. Across fourteen datasets the delivered output is indistinguishable from full entropy, on both vendors and inside the confidential guest alike, and a ladder of constructed sources shows how little that establishes, since a generator carrying thirty-two bits of entropy receives the same assessment to six decimal places, under the NIST estimators and under the AIS 31 suite and under a compression check. The interception demonstrated in 2016 reproduces on current hypervisor code, and the architectures remove it on the instruction path while leaving the host its say over what a guest is told about the instruction. The resulting picture is one of narrowing rather than repair. Of the eleven entropy sources feeding the input pool, confidential computing alters the assessment of exactly one, so that the security of a confidential guest’s entropy pool comes to rest on the single proposition that the CPU instruction delivers the entropy its specification claims, which no party outside the manufacturer is in a position to verify and which no assessment of output can confirm.

Research questions

1. Entropy quality. What can an SP 800-90B assessment of RDRAND and RDSEED output establish about the entropy that output contains, and can such an assessment tell it apart from a source known to lack entropy?
2. Interception feasibility. Is the RDRAND and RDSEED interception attack demonstrated by the BSI 2016 study still feasible on current KVM/QEMU and current Intel and AMD CPUs, and does the VM-exit behaviour differ between the two vendors?
3. Confidential computing as a resolution. To what extent do Intel TDX and AMD SEV-SNP remove the hypervisor's influence over RDRAND and RDSEED, and on what does the entropy supply of a confidential guest then rest?
4. Sufficiency for high-security deployments. Under what conditions can RDRAND and RDSEED, combined with the Linux entropy pool, satisfy BSI high-security requirements for cloud systems, including those without a physical TPM or HSM?

Original study

BSI, Analysis of Random Number Generation in Virtual Environments, 2016. PDF. It assumed a non-malicious hypervisor throughout, which the paper drops.