Intel® Software Guard Extensions (Intel® SGX)
Discussion board focused on hardware-based isolation and memory encryption to provide extended code protection in solutions.
1490 Discussions

In the remote attestation condition, is it safe if I leak expected mrenclave and mrsigner?

riclee
Beginner
3,563 Views

In the remote attestation condition, the verify code should compare exepcted mrenclave , mrsigner  with the mrenclave , mrsigner generated by isv envlave . If I leak the exepcted mrenclave and mrsigner, Is that safe ? what kind of attack will I get ? 

0 Kudos
1 Solution
Daniel_ˢᵍˣ
New Contributor I
3,292 Views

@riclee wrote:

step question . If the attacker control the equipment , use another program with same MRENCLAVE and MRSIGNER to replace the original program , the attack can be successful ?  


  • If the program is different then the MRENCLAVE is different.
  • If the attacker has a legitimate enclave image (e.g. something.signed.so) but changes it, then when this image is loaded into the enclave (when you do sgx_create_enclave) the enclave will get a different MRENCLAVE because the enclave image is no longer the same.

In your question you say the attacker created another program that has the same MRENCLAVE and MRSIGNER. So legitimate enclave and malicious enclave now have the same MRENCLAVE. This should not be possible.

But let's say that somehow the attacker did the impossible and created this malicious enclave successfully. In this case, then yes, the malicious enclave can pass Remote Attestation.

During Remote Attestation the quote containing a bunch of information on the enclave (including MRENCLAVE) is sent to the ISV. The ISV sends the quote to IAS. IAS looks at its fields, namely MRENCLAVE and MRSIGNER, and thinks all is okay because these look like the legitimate enclave's fields. IAS creates a signed attestation report and sends it back from IAS to ISV. ISV checks the report and now believes the malicious enclave is actually the legitimate enclave and is tricked into providing service to the attacker's enclave.

View solution in original post

0 Kudos
11 Replies
Sahira_Intel
Moderator
3,528 Views

Hi,

 

MRENCLAVE and MRSIGNER are created during the signing step of an enclave – the measurements become part of the signature structure (SIGSTRUCT) that is contained in the signed enclave.

During remote attestation of a running enclave, MRENCLAVE and MRSIGNER are contained in the quote that is send to a remote party that wants to verify an enclave.

This quote is signed by a public key for which the trust is routed in an Intel CA.

The remote party checks the signature of the quote and then compares the contained MRENCLAVE and MRSIGNER to expected values of MRENCLAVE and MRSIGNER.

Intel SGX ensures that a quote – signed by a public key for which the trust is routed in an Intel CA – contains exactly the MRENCLAVE and MRSIGNER belonging to the enclave requesting the quote.

Some program could pretend to have exactly the same MRENCLAVE and MRSIGNER, but such a program would not be able to generate a quote with a valid signature, so leaking these values would not be dangerous. 

See SGX Developer Guide for more information: https://download.01.org/intel-sgx/linux-1.5/docs/Intel_SGX_Developer_Guide.pdf#page=15

Please let me know if you have more questions.

 

Sincerely,

Sahira

 

riclee
Beginner
3,514 Views
0 Kudos
riclee
Beginner
3,474 Views

I asked the gramine maintainer , he said leaking mrenclave and mrsigner is not dangerous . who is right? 

riclee_0-1670209477721.png

 

0 Kudos
Sahira_Intel
Moderator
3,419 Views

Hi,

Apologies for the confusion. I have revised my response. Leaking MRSIGNER and MRENCLAVE is safe, as they are not confidential.

 

Sincerely,

Sahira

0 Kudos
riclee
Beginner
3,383 Views

I have read the link , as my understanding, in the remote attestation, the QE sign the report with EPID private key, generate a signature , then the IAS use the EPID public group key to verify the signature . Because every Intel equipment has the unique EPID private key, even the program has the same MRENCLAVE and MRSIGNER , but the program is on different Intel equipment , so the signature is different , the attack program can not pass the verification , am I right? 

step question . If the attacker control the equipment , use another program with same MRENCLAVE and MRSIGNER to replace the original program , the attack can be successful ?  

0 Kudos
Daniel_ˢᵍˣ
New Contributor I
3,293 Views

@riclee wrote:

step question . If the attacker control the equipment , use another program with same MRENCLAVE and MRSIGNER to replace the original program , the attack can be successful ?  


  • If the program is different then the MRENCLAVE is different.
  • If the attacker has a legitimate enclave image (e.g. something.signed.so) but changes it, then when this image is loaded into the enclave (when you do sgx_create_enclave) the enclave will get a different MRENCLAVE because the enclave image is no longer the same.

In your question you say the attacker created another program that has the same MRENCLAVE and MRSIGNER. So legitimate enclave and malicious enclave now have the same MRENCLAVE. This should not be possible.

But let's say that somehow the attacker did the impossible and created this malicious enclave successfully. In this case, then yes, the malicious enclave can pass Remote Attestation.

During Remote Attestation the quote containing a bunch of information on the enclave (including MRENCLAVE) is sent to the ISV. The ISV sends the quote to IAS. IAS looks at its fields, namely MRENCLAVE and MRSIGNER, and thinks all is okay because these look like the legitimate enclave's fields. IAS creates a signed attestation report and sends it back from IAS to ISV. ISV checks the report and now believes the malicious enclave is actually the legitimate enclave and is tricked into providing service to the attacker's enclave.

0 Kudos
riclee
Beginner
3,281 Views
0 Kudos
Sahira_Intel
Moderator
3,345 Views

Hi,

Yes, that other program with the exact same MRENCLAVE and MRSIGNER would never be able to generate a new quote with a valid signature, so it would not be able to pass verification. 

What do you mean by if the "attacker controls the equipment"? 

 

Sincerely,

Sahira 

0 Kudos
riclee
Beginner
3,335 Views

the quote signature is generated using the EPID private key. The EPID private key is owned by the cpu .If attacker controls the equipment , which means the attacker has the same EPID private key.  when the other program with same mrenclave and mrsigner, attacker controling the equipment (means controling the cpu), can generate the valid quote signature . I don't know whether i make it clear ?

 

or in other word , if the other program with the same MRENCLAVE and MRSIGNER is on the same computer with the original program , the other program can pass the remote verification ?

 

@Sahira_Intel 

0 Kudos
riclee
Beginner
3,319 Views

I don't understand the word "that other program with the exact same MRENCLAVE and MRSIGNER would never be able to generate a new quote with a valid signature", the quote signature is signed by EPID private key, that means any program quote on the platform can be signed by the EPID private key without limit, why can't another program generate a valid signature for quote?Maybe I misunderstood , I can't make it clear. And I have read intel document about remote attestation , I can't get helpful information about my confusion. Could you give more detail about you reply?

 

@Sahira_Intel 

0 Kudos
AnaWilliam850
New Contributor I
2,773 Views

Hi! I have the same problem, thank for the comment

0 Kudos
Reply