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

Remote Attestation Example: Does Service Provider Verify the SigRL?

He__Yi
Beginner
641 Views

Hi!

I'm looking at the remote attestation example provided on https://github.com/intel/sgx-ra-sample.

When the service provider (sp.cpp) obtains msg1, verifying SigRL, then generates msg2, it seems like SP only created a IAS_Request object, then call the IAS_Request::sigrl function, which seems just to be a HTTP request to Intel to receive a C string named as sigrl. It doesn't seem like the SP analyze the SigRL to make sure ISV enclave is out of the list...

I'm wondering if there was something that I missed in the code that covers how the SP verify the SigRL list...

 

Thanks a lot!

Yi

0 Kudos
1 Solution
Junli_S_Intel
Employee
641 Views

Typical scenario, the Service Provider will not analyze the SigRL. Instead Service Provider will send the SigRL to client. And client is the SigRL's consumer. 

View solution in original post

0 Kudos
5 Replies
Junli_S_Intel
Employee
642 Views

Typical scenario, the Service Provider will not analyze the SigRL. Instead Service Provider will send the SigRL to client. And client is the SigRL's consumer. 

0 Kudos
He__Yi
Beginner
641 Views

Hi!

 

Thank you for your reply!

Yeah I misunderstood it. On SP's side, between msg1 and msg2, the SigRL is retrieved merely to be sent back to the client enclave. The real verification of the enclave's quote on the SP's side is happening very late between msg3 and msg4, implemented by the IAS_Request::report function, which will send the encoded quote to intel for verification.

I understand why the client enclave needs an SigRL between msg1 and msg2. It seems just like the enclave has a choice to terminate before even generating its signature once it finds out its private key is presented in the SigRL that SP sends (Detailed in paper: Enhanced Privacy ID: A Direct Anonymous Attestation Scheme with Enhanced Revocation Capabilities). But I'm wondering why it is the SP to get SigRL from Intel and send it to the enclave. Wouldn't it be good for the enclave to get it directly from Intel? It seems like only the SP that registered in Intel with a SPID and two subscription keys presented can get the SigRL. But in this sense, can the enclave trust the SigRL sent by SP? Since how the client enclave react to SigRL stored in sgx_ra_msg2 is hidden in sgx_ra_proc_msg2() function (and the sgx_ra_proc_msg2_trusted function within it), I don't know if it is really the case that the enclave will terminate when it finds out its private key is actually in the SigRL, although it seems so because this function can return SGX_ERROR_EPID_MEMBER_REVOKED.

Overall I guess based on the implementation of EPID it is computationally impossible to make an un-tampered enclave believe it has been compromised by modifying the SigRL sent from SP. And on the other side, even it makes a tampered enclave believe it is not tampered, its signature will still fail the quote verification. So I guess in terms of security, it is fine. Just that I'm not quite sure why this is designed in this way... Is it because that EPID needs to distinguish from DAA, or because the necessity of a subscription control of access to SigRL?

 

Thanks!

0 Kudos
He__Yi
Beginner
641 Views

Hi!

Just found that sgx_ra_proc_msg2() also needs to talk to Intel (In Intel® Software Guard Extensions SDK for Linux* OS Page 109). If the enclave trusts the SP's SigRL, why would it need to talk to Intel in this case? I would assume Attestation Key Provisioning has been completed in sgx_ra_get_msg1. If that's not the case, could it be that both sgx_ra_get_msg1 and sgx_ra_proc_msg2 talk to Intel for Key Provisioning? 

In general, could you provide more details on (1) why both sgx_ra_get_msg1 and sgx_ra_proc_msg2 need to talk to Intel, and (2) how the Key Provisioning is done in details?

 

Thanks a lot!

0 Kudos
He__Yi
Beginner
641 Views

So far as I known, key provisioning is done by making the Provisioning Enclave call EGETKEY(Provisioning) to generate the Provisioning key, then the Provisioning Enclave sends the provisioning key to Intel. Intel will verify the key, then send the Attestation Key to the Provisioning Enclave.

I would assume it to be completed in one round within the sgx_ra_get_msg1... Please correct me if I am wrong.

 

Thanks! 

0 Kudos
Junli_S_Intel
Employee
641 Views

He, Yi wrote:

Hi!

 

Thank you for your reply!

Yeah I misunderstood it. On SP's side, between msg1 and msg2, the SigRL is retrieved merely to be sent back to the client enclave. The real verification of the enclave's quote on the SP's side is happening very late between msg3 and msg4, implemented by the IAS_Request::report function, which will send the encoded quote to intel for verification.

I understand why the client enclave needs an SigRL between msg1 and msg2. It seems just like the enclave has a choice to terminate before even generating its signature once it finds out its private key is presented in the SigRL that SP sends (Detailed in paper: Enhanced Privacy ID: A Direct Anonymous Attestation Scheme with Enhanced Revocation Capabilities). But I'm wondering why it is the SP to get SigRL from Intel and send it to the enclave. Wouldn't it be good for the enclave to get it directly from Intel? It seems like only the SP that registered in Intel with a SPID and two subscription keys presented can get the SigRL. But in this sense, can the enclave trust the SigRL sent by SP? Since how the client enclave react to SigRL stored in sgx_ra_msg2 is hidden in sgx_ra_proc_msg2() function (and the sgx_ra_proc_msg2_trusted function within it), I don't know if it is really the case that the enclave will terminate when it finds out its private key is actually in the SigRL, although it seems so because this function can return SGX_ERROR_EPID_MEMBER_REVOKED.

Overall I guess based on the implementation of EPID it is computationally impossible to make an un-tampered enclave believe it has been compromised by modifying the SigRL sent from SP. And on the other side, even it makes a tampered enclave believe it is not tampered, its signature will still fail the quote verification. So I guess in terms of security, it is fine. Just that I'm not quite sure why this is designed in this way... Is it because that EPID needs to distinguish from DAA, or because the necessity of a subscription control of access to SigRL?

 

Thanks!

0 Kudos
Reply