What is CIPHERLEAKs?

logo
CIPHERLEAKs


Root causes of the vulnerability logo

Two features in the design of SEV (and SEV-SNP) caused this vulnerability

  • SEV hardware encrypts the VM's memory using 128-bit AES symmetric encryption. The AES engine integrated into the AMD System-on-Chip (SOC) automatically encrypts the data when it is written to the memory and automatically decrypts the data when it is read from memory. Latest SEV processors adopt the XOR-Encrypt-XOR (XEX) encryption mode in the memory encryption where the ciphertext is calculated by c=ENC(m⊕T(Pm))⊕T(Pm)c=ENC(m\oplus T(P_m))\oplus T(P_m). The 128-bit entropy tweak function T()T() fixed all existing vulnerabilities in SEV AES encryption. However, the same plaintext always has the same ciphertext in system physical address PmP_m during the lifetime of a guest VM.
  • For performance optimization, SEV (including SEV-ES and SEV-SNP) does not prevent the hypervisor from read accessing the ciphertext of the encrypted memory.

Ciphertext side channels logo

By monitoring the changes in the ciphertext of the victim VM, the adversary is able to infer the changes of the corresponding plaintext. This ciphertext side channel may seem innocuous at first glance, but when applied to certain encrypted memory regions, it may be exploited to infer the execution of the victim VM. Specifically, we target at monitoring the ciphertext of the VMSA. We particularly construct two attack primitives: execution state inference and plaintext recovery. Execution state inference can help locate the physical address of targeted functions and infer the executing function of a process. The ciphertext side channel can also be exploited to recover the plaintext from some of the ciphertext blocks. To recover plaintext from the ciphertext, the adversary first needs to build a dictionary of plaintext-ciphertext pairs for the targeted registers, and then make use of the dictionary to recover the plaintext value of the registers of interest during the execution of a sensitive application.

Case studies logo

We present two case studies to illustrate the CIPHERLEAKs attack. In the first attack, we show that the constant-time RSA implementation in OpenSSL can be broken with known ciphertext for the plaintext values of 0 to 31 (which can be easily collected during VM's lifecycle). In the second attack, we show that the constant-time ECDSA signature can be compromised with known ciphertext of the plaintext values of 0 and 1. In both of the two cases we presented, the adversary can recover the private key d of RSA encryption and the secret nonce k in ECDSA signature with 100% accuracy.

Disclosure logo

We disclosed the vulnerability of the ciphertext side channel and the CIPHERLEAKs attack to AMD team. AMD engineers have acknowledged the vulnerability on SEV, SEV-ES, and SEV-SNP, and filed an embargo that is effective until August 10, 2021. As of the time of writing, CVE number, CVE-2020-12966, has been reserved for the vulnerability. AMD also announces a security bulletin together with a hardware patch for SEV-SNP in August 2021 (https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1013).

Research Paper logo

Docs

Read our paper

Read more details about CIPHERLEAKs.

Cite

Cite our paper

Explore AMD SEV.



People logo



Q&A logo

  • Who is affected by CIPHERLEAKs?

    All SEV, SEV-ES and SEV-SNP are affected by CIPHERLEAKs, which are supported by AMD EPYC server processors.

  • What is SEV?

    AMD’s Secure Encrypted Virtualization (SEV) is an extension of the AMD Virtualization (AMD-V) technology. It provides security features, such as memory encryption and isolation to virtual machines (VM), in order to support scenarios like confidential cloud computing where hypervisors are not trusted to respect the security of the VMs. When SEV is enabled, the memory pages used by a guest VM are transparently encrypted by a secure co-processor using an ephemeral key that is unique to each VM, thus allowing the guest VMs to compute on encrypted memory. SEV is AMD's ambitious movement towards confidential cloud computing, which is gaining traction in the cloud industry. For instance, Google Cloud recently provides SEV feature in its cloud computing service. Customers now can setup SEV-enabled VMs, called Confidential VMs, as its first product of Confidential Computin

  • What is SEV-SNP?

    To address the attacks against SEV that exploit memory integrity flaws, AMD recently announced SEV Secure Nested Paging (SEV-SNP) and released a whitepaper describing its high-level functionality in January 2020. SEV-SNP protects guest VM's memory integrity by introducing a new structure called Reverse Map Table (RMP). The source code for SEV-SNP software support can be found here.

  • Which SEV generations are affected?

    CIPHERLEAKs can affect SEV (the original generation), SEV-ES (the second generation) and SEV-SNP (the third and the latest generation).

  • What is CVE-2020-12966?

    CVE stands for Common Vulnerabilities and Exposures and CVE-2020-12966 is the official record of CIPHERLEAKs attack.

  • Are there some software patches available?

    Unfortunately, CIPHERLEAKs attack can collect the function's internal state by Advanced Programmable Interrupt Controller (APIC). Thus, no software solutions may work properly. Some hardware-level patches are expected.

  • What hardware migrations are available for CIPHERLEAKs?

    AMD has developed mitigation in the VMSA Register Protection feature to help protect against a malicious hypervisor. The mitigation is available for enablement in 3rd Gen AMD EPYC™ processors and requires the use of SEV-SNP, which is supported on 3rd Gen AMD EPYC™. The update has been released as part of MilanPI-SP3_1.0.0.5. There is no hardware migration for prior generations of AMD EPYC™. For more information, please refer to https://www.amd.com/en/corporate-product-security-bulletin-amd-sb-1013.

  • What is Constant-time Cryptography?

    Constant-time cryptography implementations are widely used in mainstream cryptography libraries to mitigate timing attacks, the design of constant-time functions is used to reduce or eliminate data-dependent timing information. Specifically, Constant-time implementations are making the execution time independent of the secret variables, therefore, do not leak any secret information to timing analysis.

    To achieve constant execution time, there are three rules to follow. First, the control-flow paths cannot depend on the secret information. Second, the accessed memory addresses can not depend on the secret information. Third, the inputs to variable-time instructions such as division and modulus cannot depend on the secret information.

  • The LOGO?

    The crocodile and the character "L" in the LOGO stand for CIPHERLEAKs respectively. You are welcomed to use our LOGO.



Essential Links logo