Is there a reason why the use of the Remote Attestation wrappers are a must?

[Xepheryy]

Specfiically, the use of sgx_get_quote().

There is no warning about the use of the functions that will shortcircuit the remote attestation process on the sdk/api pages.

[jmechalas]

The code that calls sgx_get_quote() is for generating a quote from the enclave directly, and that is for diagnostic purposes only. A real application should not need to call this function. This should be explained in the comments, but if that's not clear please let me know where you would like to have that documented.

[Xepheryy]

Hi, thanks for your reply. For some context, I was developing my own remote attestation protocol similar to Intel's protocol, without the use of the wrapper functions.
Since then I have tried calling the functions required for the contents of msg1 and msg3 e.g. sgx_get_quote() but there would always be errors. I have also tried to mimic the wrapper functions by calling Ecalls from the application layer into the enclave to call the functions required but to no avail.
Due to the time constraints of my project, I was then forced into using the wrappers.

In my original post, I was referring to this specifically, https://software.intel.com/en-us/sgx-sdk-dev-reference-sgx-get-quote, where there was no warning about the usage of the prohibited functions.

May I know why an application should not call these functions? From a technical standpoint as well as my curiosity

[jmechalas]

OK, I think I understand your question now. Apologies for the misunderstanding previously.

Strictly speaking, the client application/enclave does not have to call the wrapper functions, and they are provided as a convenience for developers. You can implement these functions yourself if you wish, and the source code for sgx_ra_get_msg1() and sgx_ra_proc_msg2() is in the SGX SDK, specifically in ukey_exchange. The source for sgx_ra_init() and sgx_ra_init_ex() is also in the SGX SDK, in tkey_exchange. This will help you understand what needs to happen before you can execute the lower-level functions like sgx_get_quote().

As a general rule, if you are using Intl's RA, use the wrappers. It's faster, easier, and it takes care of some important security details (e.g., making sure the RA context is opaque). But there's no reason why you can't call the lower-level functions like sgx_get_quote() directly so long as you are not undermining the security of the quote validation procedure. It's just more work to do it yourself.

Certainly, if you are implementing your own RA protocol, then it may be necessary to do your own message generation and processing rather than rely on the wrappers provided by the SDK. Those wrappers more or less assume you are doing things the "Intel way", so to speak.

Does that help?

[anithag]

@jmechalas

Sorry for commenting on closed issue. But I am wondering if you can elaborate on the following

making sure the RA context is opaque

What do you mean by RA context is opaque? How could one potentially err by not making it opaque.

I get that the remote attestation key is secret and that only QE can access this key, but how is the policy enforced? For example, when sgx_get_quote() is called, who and how an attestation key is accessed?

At a high level, I am wondering how the SDK protects access to the remote attestation key.

[jsun39]

Remote attestation key has been encrypted by QE's seal key. So only Intel QE could access this attestation key: and this key was used to sign one message(like user enclave's report).