A question about Enclave sign and verification

[Changzheng_W_Intel]

As my understanding, the public key corresponding to the signing private key is build into enclave and can be measured by CPU when an enclave is initialized.

Docs said that

"The verifier of the remote attestation must check the identity of the signer (MRSIGNER) before
provisioning any secrets. The Intel SGX architecture does not verify the certificate chain when
an enclave is instantiated. The hardware only verifies the enclave measurement (MRENCLAVE)
and saves a hash of the ISV’s public key contained in the enclave signature in MRSIGNER. This
means that anyone can modify an enclave and re-sign it. Similarly, the verifier must also check
the enclave attributes to prevent provisioning any secret to a debug enclave, for instance."

If Intel SGX architecture does not verify the public key as a certificate chain, then how to make sure there is no adversary modified and re-signed the enclave? I suppose an adversary can change anything in the enclave including the " identity of the signer " in the enclave to cheat SGX architecture.

Is that right? Is there any mechanism to make verify the public key is the right one in the enclave?

Thanks

[PadmaPriya_M_Intel]

Hi,

To avoid third parties to collude, Intel has introduced the use of an anonymous signature technique, known as Intel® Enhanced Privacy ID (Intel® EPID), for signing enclave quotes. 

The application returns the quote structure and any associated manifest of supporting data to the service challenger. The challenger uses the EPID public key certificate to validate the signature over the quote or may optionally choose to use an EPID verification service to perform this function. The challenger compares the enclave information in the quote against the trusted configuration and only renders the service to the application if the enclave information matches the trusted configuration. The challenger might enforce different trust policies, for example, only trusting a specific version of an enclave, identified by the measurement of the code and data in the enclave, or trusting all enclaves with a specific Product ID from a specific enclave author, identified by the hash of the public key in the ISV certificate. A trust policy must include enclave authorship and attributes check. For example, a debug enclave should never be trusted with any secret.