BHUSA17: SGX Remote Attestation is not sufficient

Yogesh Prem Swami, Secure Substrates

[Note: As a reminder, these are my notes. The opinions are generally of the presenter, unless specifically noted.]

Swami used to work at Cryptography Research and is now at a startup working on secure containers. A typical misconception is that SGX is a black box, but that's not true. Interrupting the processor can reveal information.

How to ensure that software runs on real hardware?  The cloud provider can actually put it on a simulator. Two types of attacks - run simulation on general hardware or run simulator inside real hardware to man-in-the-middle.  SGX protects against both of these attacks.

You need to make sure you're using real HSM hardware, which is hard as the cloud provider may not do that.

Looking at the common SGX Enclave Design

• Define a generic remote attestation scheme
• Arbitrarily compose different crypto schemes (generate keys, save to disk, generator CSR requests and create audit log)
• Define a workflow that combines first 2 steps

Example is vacuously broken. Attacker runs attestation correctly and runs rest of the protocol outside of the enclave. Allows attacker to simulate some sub-computations, commitment log of confidential data (eg sha256 of someone's birthdate), send confidential data over encrypted TLS and simulates states related to birthdate. Enclave is a single protocol sequentially composed of sub-protocols.

Imagine where the user wants to store their keys on disk. The problem here is SGX does not have an internal counter, so it needs to get it from outside source. The trusted way to do this is via the TPM, but you want to make sure nobody switches out the motherboard and reset the counter. Sounds good? But this scheme is still insecure. The enclave doesn't have a way to control how many instances of the enclave exist. Attacker runs the same enclave concurrently and feeds the same tpm_cntr and tpm_sig to both instances. Concurrent composition not limited to running the same operation. SGX has no built-in replay protections. Launch enclave cannot limit concurrency, EINITOKEN is a long-term credential and the whitelist is ineffective.

The damage is not limited to that piece of data but anything that depends on that data. You're not just effecting one node, you might be impacting multiple notes.


Another issue is state malleability and knowledge extractors. SGX enclave is nota  black box, as adversary can force the enclave to exit at arbitrary execution point via AEX and then control what happens after AEX. Global enclave state is malleable! Partial rewinding effect possible, since SGX allows multiple threads within the same enclave, interrupt one-thread at appropriate point and ecall other threads. Careful wit interactive proof-of-knowledge protocols, as they require just two responses per commitment to reveal the secret.

Now onto other issues...

Group signatures allow members to anonymously sign messages on behalf of the group with a single group public-key (unique private key per member).  Group manager decides who can join the group and grants credentials to each member. Security goals are full anonymity and member revocation. Can use EPID for anonymity, blind join and member revocation.

EPID signatures have two distinct components: basic signature and non-revoked signature proof. Basic signature is based on BBS+. In addition to basic signature, each signature also contains a lot of math that is hard to capture on a blog. EPID doesn't have full anonymity if you revoke a key.


Each platform given a provisioning ID (PPID), which is known by the CPU and Intel, so there can be no anonymity of join (though it also doesn't claim). The researcher believes there is an online database, maintained by Intel, online of all of these highly sensitive IDs that would be an attractive target for attackers.


Enclave creates local attestation for quoting enclave (QE) and optionally requests QE to generate local attestation for for quote for anclave. QE creates encrypted EPID signature and the enclave validates QE's lcoal attestation on encrypted quote. The enclave sends encrypted quote to Service Provider (SP), SP cannot validate the quote itself even if it has access to group public key.


Provisioning enclave and quoting enclaves are securely implemented, but lots of bike shedding crypto. It is secure against sequential, concurrent and state malleability. There is no privacy in spite of group signatures. Remote attestation quotes are encrypted and can only be validated by Intel, which destroys privacy and could be abused by MitM (Intel?)