Intel® Software Guard Extensions (Intel® SGX)
Use hardware-based isolation and memory encryption to provide more code protection in your solutions.
1291 Discussions

What messages are useful to attest to a third party that my enclave hasn't been tampered?




I have successfully made your ra-sample-sgx sample working. I was wondering if I want to prove to a third party that my enclave is attested by Intel, which kind of information I should provide to this third party?

To give you a concrete example, this exposed service by town-crier works this way: 

 curl -d '{"id": 123, "jsonrpc": "2.0", "method": "attest"}'

returns the following


Town crier points to your ra example, I see in the sp code that I can retreive the mr_enclave from the Enclave Report Details and there's a quote information in the IAS Report, I checked the lengths and they don't correspond to the length in the town-crier service.


My aim is to attest to a third party that the code running into an enclave in my server hasn't been tampered, which messages I need to return to such third parties?





0 Kudos
3 Replies
Super User

Good morning Antonio, I hope your week is starting well.  This is the follow up that I mentioned in your question about the report_data field in the enclave attestation report.

The issues you are dealing with are arguably one of the immature elements of the SGX ecosystem.  The notion of 3rd party Service Providers (SP's), which would stand alongside a software vendor (ISV) and Intel to provide attestation services to a client of the ISV, has not developed or evolved.  As a result everyone active in the ecosystem appears to be 'rolling their own' solutions.

If you have communication with Intel Attestation Services (IAS) up and operational, you will need to convey information from the Attestation Verification Report to the client of your enclave that allows the client to make an informed decision as to the status of the enclave that is executing.  The three most important data elements in the attestation verification report are as follows:

  • isvEnclaveQuoteStatus
  • isvEnclaveQuoteBody
  • platformInfoBlob

The isvEnclaveQuoteStatus advises the client as to the overall status of the enclave executing on the platform.  The isvEnclaveQuoteBody provides the identity characteristics of the enclave while the platformInfoBlob contains information that details why the remote platform does not have an optimum Trusted Computing Base (TCB).  There are potentially open issues with respect to a clients ability to properly interpret the platformInfoBlob but we will leave that issue alone for the current time.

One of the difficulties with respect to simply conveying this information to a client is that the client would have no reason to trust the information.  The trust predicate is conveyed from Intel with respect to this information by a signature generated over the entire HTTP/REST response from IAS.  The obvious solution to this would be to simply hand the entire IAS report to the client in some suitable format that the client can review.

Once this issue is resolved the remaining problem to be addressed is to convey to the client, through some type of out-of-band mechanism, the identity characteristics of the enclave, which are as follows.

  • Identity of enclave signer.
  • Identity of enclave.
  • Attributes of enclave.
  • Software and security versions.

All of these values are in the body of the enclave quote structure that is returned by IAS.

With respect to your other post, there is probably no need to be worried about putting anything in the report_data field of the enclave quote in the model you are pursuing.  Data in that field is typically used if the objective is to establish a security context between a client and an enclave.  It would seem that your aspirations are to provide a guarantee to a client that a known version of the enclave is being executed.  That information is present in the enclave attestation quote that is available in validated form by Intel.

Hopefully this information is helpful, let me know if we can provide any additional clarifications.

Have a good week.

Dr. Greg


Hi Dr. Greg,

Thanks a lot for your clarification, I was just wondering the reason why the platformInfoBlob is empty if the enclave is trusted by IAS. I was actually thinking that such a field would be very interesting to be transmitted to a third party to after an attestation, but it looks like it's populated only if there's an error.




Super User

Good morning Antonio, I hope this note finds your day starting well.

The purpose of the platformInfoBlob (PIB) is to convey information on why Intel is indicating that the Trusted Computing Base (TCB) of the platform is less then optimal.  As a result there is no information to be conveyed in the case where the platform is certified with an attestation status of 'OK'.

Have a good day.

Dr. Greg