2 ms·
In SGX, you do have verification that the microcode has been updated. This is known as the CPUSVN value, it is part of the SGX report that gets issued, and mixe
by ENOTTY 6y ago
In SGX, you do have verification that the microcode has been updated. This is known as the CPUSVN value, it is part of the SGX report that gets issued, and mixed into the keys used to sign reports.
- pstrateman 6y agoExcept this attack extracted the attestation keys, so I can attest to any version of the microcode that I want. (Even ones that don't exist).
- ENOTTY 6y agoThis attack did not extract the root attestation secret or sealing secret, both stored in CPU fuses. Instead, this attack extracted the sealing and attestation keys stored by the current version of Intel's Quoting Enclave under the current microcode revision (and presumably all previous microcode revisions). Assuming Intel fixes the vulnerability in the next revision of microcode (lets call it Rev H), the Quoting Enclave will need to generate and/or store new attestation keys. Because the root secrets were not leaked AND the microcode revision has revved forward, these cannot be derived under previous microcode revisions. Thus, they are assumed not to be available to the attacker under the SGXAxe/Cacheout vulnerabiilty. Intel generates or provides access to new public keys that correspond to the attestation keys. You use these to verify the Quoting Enclave's attestations. Intel additionally asserts that these new public keys will only verify attestations created by the Quoting Enclave running under Rev H of the microcode. You must determine whether to trust this assertion.