msg2.g_b.gx = 71f76c3a1b06cc702b66cd21626bf1f6d7d894be5941282384ce80cdb845eae5
msg2.g_b.gy = 5f5f250493ec7e8fc68e0ef0055d0065532b5a14e8fb1f6748e6b19e7cebb9c4
msg2.spid = 1718b04d7fc5d48bd1eb9a6465b36c0d
msg2.quote_type = 0100
msg2.kdf_id = 0100
msg2.sign_ga_gb = 04583fcdfb5fa1aad7af60aa69eb55d506aa46ef05bb223c507f026d283e4f2156d35352713c6bd0dfc7739a46b22f97f15d596e6663f75360ea1660d61aedbd
msg2.mac = aa40bfa3b0647d7e6eab166017a01afd
msg2.sig_rl_size = 00000000
+++ msg2_size = 168
I have attached the msg2 that my client receives from the RP. I am getting an error while processing the msg2. What could be the possible reasons for the error? Also, is there any recommended way to debug such errors?
I built upon https://github.com/intel/sgx-ra-sample for my application. I am using hardware-debug mode. I tried sgx-gdb but was not able to make sense out of it, as it's not letting me step into sgx_ra_proc_msg2 properly. Maybe I am not understanding it properly. Is there another way to find the problem?
Note: I have previously asked this question but is closed due to my lack of response. Sorry about that.
It is expected that trying to do a remote attestation with an enclave in simulation mode will fail.
You can find this note in the sgx-ra-sample, https://github.com/intel/sgx-ra-sample:
"Note that Remote Attestation will fail for clients running in simulation mode, as this mode has no hardware protection."
Yes! I think I would need some help. I am trying to debug the program using sgx-gdb, but no luck, will get back to you if I find something. I double-checked for a linkable subscription and a linkable signature.
The SGX Developer Reference gives this advice for helping debug your Remote Attestation Service Provider:
As an ISV writing the remote attestation service provider, you may want to debug the message flow. One way to do this would be to provide pre-generated messages that can be replayed and verified. However, not that S1 message = (GID || ga) includes the random component ga generated inside an enclave. Also, the remote attestation service provider generates a
random public+private key pair as part of its msg2 generation, but without any interaction with Intel® SGX. Finally, each of these has state or context that is associated with cryptographic operations and is used to ensure that certain calls being made are in the correct order and that the state is consistent. These characteristics help protect the remote attestation flow against attacks, but also make it more difficult to replay pre-generated messages.
To overcome these, the cryptographic library is modified and used (only) by the sample service provider. Any time that key generation, signing, or other operation requests a random number, the number 9 is returned. This means that the crypto functions from sample_libcrypto.lib are predictable and cryptographically weak. If we can replay msg1 send from the isv_app,
the sample service_provider.dll will always generate the exact same msg2. We now have a sufficient system to replay messages sent by the isv_app and have it verify that the responses sent by the remote service are the
To replay messages and exercise this verification flow, pass in 1 or 2 as a command-line argument when running the sample application isv_app. The isv_app will ignore errors generated by the built-in checks in the Intel SGX.
Developers wishing to debug their remote attestation service provider should be able to temporarily modify their cryptographic subsystem to behave in a similar manner as the sample_libcrypto.lib and replay the pre-computed messages stored in sample_messages.h. The responses from their own remote attestation service provider should match the ones generated by ours, which are also stored in sample_messages.h.