Remote Attestation Simulation

[mxl01]

When I run the RemoteAttestation Sample provided in the sgx SampleCode Folder in Debug-Simulation mode, everything works despite some hints in this community that RA in sim-mode is not possible. When I try to build my own solution however, sgx_ra_proc_msg2 returns an unexpected error which I am unfortunately not able to debug. Is it possible to run remote attestation in simulation mode and what can cause the problem of the unexpected error? Also, is there a solution to step into enclave code because sgx-gdb does not show source file lines and does not step into the sgx_ra_proc_msg2-ecall.

System specs:

Intel(R) Core(TM) i7-8550U CPU

Ubuntu 20.04 LTS

Intel SGX-SDK 2.13

Thanks in advance!

[JesusG_Intel]

Hello mxl01,

Simulation mode works with the RemoteAttestation sample app because it does not use the real IAS. Everything is simulated! The file RemoteAttestation/service_provicer/ias_ra.cpp states:

// This whole file is used as simulation of the interfaces to be

// delivered by the IAS. This sample does not contact the real

// IAS. The IAS Sevice Provider developer needs to follow the 

// IAS onboarding process to gain access to the real IAS.

Use https://github.com/intel/sgx-ra-sample if you want to access the real IAS. Your system must support SGX to use the sgx-ra-sample.

If you want to be able to debug the PSW, where sgx_proc_msg2 is implemented, you must install the debug and development packages of the PSW. Refer to the instructions here: https://github.com/intel/linux-sgx/tree/master#using-the-local-reporecommended

"Optionally, you can install *-dbgsym or *-debuginfo packages to get the debug symbols, and install *-dev or *-devel packages to get the header files for development.

NOTE: To debug with sgx-gdb on Ubuntu 16.04, you need to ensure the Intel(R) SGX PSW is built under the condition that the environment variable DEB_BUILD_OPTIONS="nostrip" is set."

Sincerely,

Jesus G.

Intel Customer Support

[mxl01]

Thank you very much! The problem about the driver is that my Intel(R) Core(TM) i7-8550U CPU does not support FLC and therefore is not able to run the DCAP drivers, however my Ubuntu 20.04 kernel does not support the old driver from the linux-sgx driver repo. Do you have any tips on how to deal with this? Thanks! 

[JesusG_Intel]

Hello Max,

If you are using Linux kernel 5.11 or higher and your processor does not support FLC, download and build the latest OOT driver from: https://github.com/intel/linux-sgx-driver#build-and-install-the-intelr-sgx-driver

Sincerely,

Jesus G.

Intel Customer Support

[JesusG_Intel]

Hello Max,

Were you able to install the OOT driver by building it from the source?

Sincerely,

Jesus G.

Intel Customer Support

[mxl01]

Hi Jesus,

yes, I updated to 5.11 mainline kernel and I was able to install the drivers, however, the SGX_ERROR_UNEXPECTED problem with sgx_proc_msg2 is still unsolved and remains undebuggable even though I installed the sgx-driver package and the debug-symbol- version of the PSW. When I try to reverse the byte-order, sgx_proc_msg2 returns an error SGX_INVALID_SIGNATURE, which would indicate an error in the signature process. As far as I understand it, the signature consists only of ECDSA_k(gb || ga) with a key k derived from the private key of Service Provider. I use all of the provided keys of the RemoteAttestation Sample, so I really don't know where the error originates from. Also, it seems that in the RemoteAttestation Sample, this signature scheme is not really used as the first 32 bytes of msg2's signature are just the exact first 32 bytes of gb without any changes.

Thanks for the help regarding the driver anyway!

[JesusG_Intel]

Hello Mxl01,

Ensure your subscription and signature type match.

Use a linkable subscription and a linkable signature if your quote type is linkable.

Use an unlinkable subscription and unlinkable signature if your quote type is unlinkable.

Refer to https://api.portal.trustedservices.intel.com/EPID-attestation for more information.

Yes, debugging remote attestation is difficult.

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

expected ones.

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.

Sincerely,

Jesus G.

Intel Customer Support

[JesusG_Intel]

Hello Max,

Have you made progress on this issue?

Also, be sure to read https://software.intel.com/content/www/us/en/develop/articles/code-sample-intel-software-guard-extensions-remote-attestation-end-to-end-example.html, which contains descriptions of how each message is composed.

Sincerely,

Jesus G.

Intel Customer Support

[mxl01]

Hello Jesus,

yes, I am now using the Crypto-Backend of the RemoteAttestation Sample and try to build the IAS requests on my own, such that I can debug messages easier. I need to improve the crypto-primitives to not be deterministic once I am able to debug everything and will switch to OpenSSL like the code sample you linked. My current problem is the IAS Server giving me a 400: Bad Request Status and as https://api.trustedservices.intel.com/documents/sgx-attestation-api-spec.pdf  states, this has to do with an invalid isvEnclaveQuote (as this is the only payload I am sending). Do you happen to know if the quote generated inside the RemoteAttestation Sample is filled with mocked data or just not up-to-date anymore? I am literally passing the quote as-is in base64 encodng to the IAS.

Thanks again for your steady help, slow progress is better than no progress

Max

[JesusG_Intel]

Hello Mxl01,

Please describe the modifications you made to the RemoteAttestation sample and how are you invoking it.

Also, double-check that you are using the appropriate signature types, i.e. linkable or unlinkable, for your quote based on your subscription. The attestation API spec states:

"In case the Service Provider registered with a linkable EPID signature policy but uses unlinkable EPID signatures (and vice versa), IAS will respond with “400 Bad Request” to Verify Attestation Evidence call."

Sincerely,

Jesus G.

Intel Customer Support

[JesusG_Intel]

Hello Mxl01,

Do you still need help with this issue?

Sincerely,

Jesus G.

Intel Customer Support

[mxl01 · Accepted solution]

Hello Jesus,

this problem was caused by a wrong (hardcoded) SPID, which was my mistake. Now the IAS responds with SW_HARDENING_NEEDED. This is due to the deterministic crypto-backend used in the sample_cryptolibrary of the RemoteAttestation sample right?

[JesusG_Intel]

Hello Mxl01,

Thanks for telling us how you resolved your issue, it is very helpful!

I can't say for sure why are you receiving that response from IAS but here is more information that may be helpful.

According to the SGX Attestation API Spec:

SW_HARDENING_NEEDED – the EPID signature of the ISV enclave QUOTE has been verified correctly but due to certain issues affecting the platform, additional SW Hardening in the attesting SGX enclaves may be needed. The relying party should evaluate the potential risk of an attack leveraging the relevant issues on the attesting enclave, and whether the attesting enclave employs adequate software hardening to mitigate the risk.

Look at the reported Security Advisories (SAs) for the specific issues IAS found.

Refer to these articles for more information:

• Receiving ISV Enclave Trust Status as "Enclave NOT TRUSTED - Reason: CONFIGURATION_AND_SW_HARDENING_NEEDED" During Remote Attestation
• Intel SGX Attestation Technical Details

Sincerely,

Jesus G.

Intel Customer Support

[mxl01]

Thanks, I will look into this!

[JesusG_Intel]

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.