Community
cancel
Showing results for 
Search instead for 
Did you mean: 
hyunsoo
New Contributor I
191 Views

IAS(Intel Attestation Service) does not identify enclave

Jump to solution

Both remote attestation based on EPID and ECDSA cannot identify enclave's identity. It means that we can know the fact that remote party running enclave has genuine CPU to run SGX, but we don't know whether their enclave is really the one that I know or not. Of course, we can check MRENCLAVE or MRSIGNER, but this can be manipulated easily(IAS cannot validate these values), so we can't trust that values. Is there a method to identify other remote enclaves?

0 Kudos
1 Solution
hyunsoo
New Contributor I
69 Views

Hi James, Thanks for clarifying second question

I think that we don't need to talk about the second case further as you explained correctly. 

I searched more, and I notice a fact that enclave identification(MRENCLAVE, MRSIGNER) cannot be modified. These values are calculated when an enclave is loaded by EEXTEND instruction and stored in SECS which is not accessible by any enclave including itself. When EREPORT instruction is executed, cpu read MRENCLAVE and MRSIGNER from SECS and copy to report to be returned. Yeah, an attacker can't generate any forged report. After this phase, QE and IAS guarantee their integrity and correctness.

Generating report in local --> cannot be modified any value in the report by an attacker.

Generating quote in local --> cannot be modified any value in the quote by an attacker.

Verification quote by IAS --> guarantee whether the received quote is born from QE or not.

So, SGX can guarantee the identification of a remote enclave on the fly. it's amazing.  Are there any other pitfalls that I didn't notice? 

 

View solution in original post

8 Replies
JesusG_Intel
Moderator
172 Views

Hello Hyunsoo,


MRSIGNER, MRENCLAVE, ISVPRODID, and ISVSVN are exactly the things you use to verify your enclave, as shown in our RA sample here. If any of these have been modified, the report itself that contains those items would fail verification.


Sincerely,

Jesus G.

Intel Customer Support


hyunsoo
New Contributor I
159 Views

Did you check the verification code? quote enclave does not check MRSIGNER and MRENCLAVE. Instead, they compare CMAC values in report by deriving CPU key. For example, an attacker can generate a report itself by filling in the information of another target enclave on the same platform. In this case, we can't identify between our intended enclave and the attacker's enclave.

JesusG_Intel
Moderator
115 Views

Hello Hyunsoo,


If an attacker modifies the quote’s MRSIGNER or MRENCLAVE or anything else in the quote, the CMAC comparison would fail. If another enclave other than Intel’s Quoting Enclave (QE) tries to generate or sign a Quote, then IAS would also fail the Quote’s signature check. It is not possible to fake the quotes as you described because either the QE or IAS would detect the changes based on the many CMAC measurements. Refer to the End-to-end Remote Attestation Sample for more details, especially Msg3 and Msg4.


If you still have a doubt, describe to us step-by-step how you think an attacker can fake out both the Quoting Enclave and IAS by modifying values. This will help us identify where the confusion is.


Sincerely,

Jesus G.

Intel Customer Support


hyunsoo
New Contributor I
110 Views

Thanks for the great answer. Yes, your statements are exactly right. Let me put two examples.

1. Attacker can generate report(not quote) itself by filling out with forged values such as attacker's MRSIGNER, attacker's MRENCLAVE, and etc. And then he request Quote Enclave to make quote using his report. In this step, Quote Enclave does not verify the values in the report(actually, QE can't do fundamentally unless QE can directly load target enclave, generate measurement and check it).

 

2. As far as I know, QE can be compiled in local and the source code is open to anyone. If the victim has installed malicious QE then the attacker can generate a fake quote. 

 

Actually, the second case is impractical than the first case. Anyway, there are more cases maybe. The fundamental reason why I raised this problem is that SGX does not have an underlying identification mechanism of the target enclave. Underlying SGX authentication checks only HW state(CPU key derivation), not SW State(Enclave identification). It implies that Cukcoo attack is possible in SGX too.

 

I don't know how your team is formed in this community. I hope that you deliver this claim to your colleagues and see how they think. I'll wait for your response. Thank you.

James_B_Intel1
Employee
104 Views

>1. Attacker can generate report(not quote) itself by filling out with forged values such as attacker's >MRSIGNER, attacker's MRENCLAVE, and etc. And then he request Quote Enclave to make quote using his >report. In this step, Quote Enclave does not verify the values in the report(actually, QE can't do >fundamentally unless QE can directly load target enclave, generate measurement and check it).

When a REPORT is generated by an Enclave, the Enclave cannot input the REPORT fields other than ReportData.  The HW generates the MRSIGNER and MRENCLAVE and other fields in the EREPORT instruction and then generates the CMAC.  Any attempt by the enclave to modify these values after the CMAC is generated will be detected by the target enclave when verifiying the report.

>>2. As far as I know, QE can be compiled in local and the source code is open to anyone. If the victim >>has installed malicious QE then the attacker can generate a fake quote. 

This is not possible.  Only the Intel signed QE will be able to get the private Attestation Key during the provisioning step recognized by IAS.  Any other enclave, even using the exact same opensource QE code, will not be able to get an attestation key that the IAS will accept as will not be signed by the Intel QE signing key (difference MRSIGNER).

 

 

 

hyunsoo
New Contributor I
70 Views

Hi James, Thanks for clarifying second question

I think that we don't need to talk about the second case further as you explained correctly. 

I searched more, and I notice a fact that enclave identification(MRENCLAVE, MRSIGNER) cannot be modified. These values are calculated when an enclave is loaded by EEXTEND instruction and stored in SECS which is not accessible by any enclave including itself. When EREPORT instruction is executed, cpu read MRENCLAVE and MRSIGNER from SECS and copy to report to be returned. Yeah, an attacker can't generate any forged report. After this phase, QE and IAS guarantee their integrity and correctness.

Generating report in local --> cannot be modified any value in the report by an attacker.

Generating quote in local --> cannot be modified any value in the quote by an attacker.

Verification quote by IAS --> guarantee whether the received quote is born from QE or not.

So, SGX can guarantee the identification of a remote enclave on the fly. it's amazing.  Are there any other pitfalls that I didn't notice? 

 

View solution in original post

JesusG_Intel
Moderator
63 Views

Hello Hyunsoo,


I'm glad you were able to research the answers to your questions.


You may be interested in reading about the SGX Security model in slides 109 - 121: https://software.intel.com/content/dam/develop/external/us/en/documents/332680-001-720907.pdf.


Sincerely,

Jesus G.

Intel Customer Support


JesusG_Intel
Moderator
48 Views

This thread has been marked as answered and Intel will no longer monitor this thread. If you want a response from Intel in a follow-up question, please open a new thread.


Reply