That's what remote attestation is supposed to prevent. https://en.wikipedia.org/wiki/Trusted_Computing#Remote_attes...
Basically you're trusting the processor to truthfully attest its execution state. You can't emulate it because the attestation is signed with a key that's burned into the processor.
Edit: I found a description and it does sound like they store a master key in all CPUs!
https://blog.quarkslab.com/overview-of-intel-sgx-part-2-sgx-...
It is stored in e-fuses, which can be read, but it is encrypted using a Physical Unclonable Function, which means to read it you would need the CPU to be running. Very difficult but I'd be surprised if it were impossible.
>The solution first adopted by the TCG (TPM specification v1.1) required a trusted third-party, namely a privacy certificate authority (privacy CA). Each TPM has an embedded RSA key pair called an Endorsement Key (EK) which the privacy CA is assumed to know. In order to attest the TPM generates a second RSA key pair called an Attestation Identity Key (AIK). It sends the public AIK, signed by EK, to the privacy CA who checks its validity and issues a certificate for the AIK. (For this to work, either a) the privacy CA must know the TPM's public EK a priori, or b) the TPM's manufacturer must have provided an endorsement certificate.) The host/TPM is now able to authenticate itself with respect to the certificate. This approach permits two possibilities to detecting rogue TPMs: firstly the privacy CA should maintain a list of TPMs identified by their EK known to be rogue and reject requests from them, secondly if a privacy CA receives too many requests from a particular TPM it may reject them and blacklist the TPMs EK. The number of permitted requests should be subject to a risk management exercise. This solution is problematic since the privacy CA must take part in every transaction and thus must provide high availability whilst remaining secure. Furthermore, privacy requirements may be violated if the privacy CA and verifier collude. Although the latter issue can probably be resolved using blind signatures, the first remains.
However as far as I can tell they actually have a unique key per CPU, and they store a database of them which you have to query over the internet to verify an enclave.
It has the downside of requiring a network request to Intel to verify the enclave, but it does mean that there isn't a master key to leak.