remote attestation

[gu_j_1]

If the users want to verify whether their applications are correctly loaded into an enclave on distrustful cloud, they should connect Intel to do the remote attestation?

Is there any other way to verify an enclave without connecting Intel every time when loading?

Thanks!

[Surenthar_S_Intel]

Hi Gu,

Each and every enclave has to be attested and verified through IAS. Once the attestation is done for the 1st time it is not necessary for verify the enclave without connecting intel attestation sever all the time. The attestation can be stored in local disk for offline use using Sealing key.

Thanks and Reagrds,
Surenthar Selvaraj

[gu_j_1]

Hi, Surenthar

Thank you!

If the enclave is first launched in machine A, it sends the quote to user and user stores it. When the enclave is launched in machine B, previous quote is invalid. Is connecting to IAS necessary again in this situation?

Is it possible that Intel allows so many end users to use IAS?

Is it possible that Intel allows some other companies to do the IAS work?

[Surenthar_S_Intel · Accepted solution]

Hi Gu,

If the enclave is first launched in machine A, it sends the quote to user and user stores it. When the enclave is launched in machine B, previous quote is invalid. Is connecting to IAS necessary again in this situation?

• Answer: Yes, connecting to IAS is necessary. when the enclave is launched in machine B, there is no “previous quote” unless the enclave has attested before.

Is it possible that Intel allows so many end users to use IAS?

• Answer: Yes, Intel allows so many enclave to use IAS. Quotes are per enclave, not per user.

Is it possible that Intel allows some other companies to do the IAS work?

• Answer: No, Intel doesn’t allows some other companies to do the IAS work

Thanks and Reagrds,
Surenthar Selvaraj

[Zhicong_H_]

Hi Surenthar,

There seems to be a bit inconsistency in this thread.

You mentioned "The attestation can be stored in local disk for offline use using Sealing key". So, the attestation is stored on the SGX machine, otherwise there is no sealing key.

But then you acknowledged Gu's description that "If the enclave is first launched in machine A, it sends the quote to user and user stores it." Here 'user' is not the SGX machine, right?

I am confused here. Maybe I misunderstand somewhere? Could you specify who stores the attestation?

Moreover, I skimmed through most of Intel documentations about SGX, and never found a statement about storing attestation for future use (I only know that you can seal the secret for future use after attestation.)   Could you give a brief description about how the stored attestation will be used again in the future?

Many thanks,

Zhicong

[Surenthar_S_Intel]

Hi,

You mentioned "The attestation can be stored in local disk for offline use using Sealing key". So, the attestation is stored on the SGX machine, otherwise there is no sealing key.

               Here i am referring Attestation as the secret data (in the form of Encrypted)  received from IAS and stored for future use(Sealing Process).

But then you acknowledged Gu's description that "If the enclave is first launched in machine A, it sends the quote to user and user stores it." Here 'user' is not the SGX machine, right?

               If the enclave is first launched in machine A, it connecting to IAS and get the secret data and stored it (SGX Machine). when the enclave is launched in machine B, there is no “previous quote” unless the enclave has attested before.  

Please refer the below blog for more information

https://software.intel.com/en-us/blogs/2016/05/04/introduction-to-intel-sgx-sealing

https://software.intel.com/en-us/attestation-sealing-with-software-guard-extensions

-Surenthar

[Yan__Yudao]

Hi Selvaraj,

My question is: is it possible that Intel allows many end users/clients with out enclave to use IAS? That means if I set up a application with enclave, and expose to many end users on web browser or client app. Is it possible to let end users who using web browser or client app to attest my enclave and verify with IAS?

[Dr__Greg]

Good afternoon, I hope this note finds everyone's week having gone well.

As I watched this thread unfold it seemed that it suffered from somewhat of a lack of crispness and clarity.  Hopefully, the following reflections will help advance the level of community understanding of SGX remote attestation and to assist us in our 'Best Reply' quest.

First of all, it is important to note that SGX in no way relieves security architects from conforming to the three basic laws of security thermodynamics; ie. the requirement to implement identification, authentication and authorization.  SGX simply provides infrastructure to implement these fundamental tenants of information security.

This thread got a bit confusing when Surenthar began talking about encrypting a quote using static sealing keys.  It makes no sense to encrypt a quote or a quote verification from Intel Attestation Services (IAS), since they are both point in time statements regarding the authenticity of the identification and platform characteristics of an initialized enclave.

In fact, the Quoting Enclave (QE) accepts a liveness nonce from a party requesting a quote in order to prevent a security adversary from simply replaying a previous quote.  It is an expectation of SGX remote attestation that the verifying party provide a nonce as a component of the attestation request and to verify that the offered nonce is in the report body that is returned by IAS, either directly or through a Service Provider (SP).

So, it would make no sense to encrypt and store a quote, since it would be irrelevant from a security perspective at a later time.  For example, consider an SGX based banking application.  From a security perspective, each time a web based client establishes a session there is a need to request remote attestation of the application enclave so that the application can authorize, via the enclave application version number and the enclave security version (SVN) that it is an application/enclave the client wishes to engage with from a session or security perspective.

What Surenthar was referring to was the encryption and persistent storage of sensitive data that may be imported into an enclave from a client.  The entire purpose of attestation from this perspective is to authenticate an Elliptic Curve Diffie Hellman (ECDH) key exchange between an attesting enclave and a verifying party.  This allows the two entities to negotiate a shared secret that can be used as the basis for the derivation of a symmetric key for the purposes of providing confidentiality and integrity guarantees for data that is being exchanged between the two parties.

As all security architects should know, identification is a necessary security requirement in an ephemeral key exchange transaction. Failing to implement strong authentication opens up the opportunity for a Man In The Middle Attack against the negotiated session key.

If data is to be persisted long term on the enclave side of the security context, the enclave requests the derivation of a static sealing key using the ENCLU[EGETKEY] instruction.  That key is in turn hashed or otherwise whitened in a deterministic fashion in order to provide a symmetric key that can be used for secure persistence of the data.All of this is accomplished by a 64 byte data field that is included in the body of a report request structure.  An attesting enclave places up to 64 bytes of data of its choosing in the field and then requests that a CMAC based signature (hash) be generated over the structure.  This signature is based on the report key which is another type of static key that can be generated by the ENCLU[EGETKEY] instruction and is specific to only the processor that generates it.

This signature can be re-generated by another enclave running on the platform in order to support intra-processor attestation.  This is possible since the report key is a processor specific value and thus available to any enclave initialized on a specific processor.

This CMAC based signature/hash is replaced by an Enhanced Privacy ID (EPID) signature in a remote attestation environment.  IAS verifies that the provided signature over the report body was generated by a member of the processor specific group and returns an RSA certificate authenticated confirmation that the report was generated by a legitimate enclave running on a provisioned platform.

This provides a framework that supports the ability of a client to 'trust' the 64 bytes of report data in the enclave.  If the data is an ECDH public generator key the client can safely generate a key pairing against the data and derive a shared secret key and in the process generate a public generator key for the enclave to generate its version of the shared secret.  Obviously, the enclave needs some method of identifying and authorizing the client/verifying party as well.

There is nothing 'special' about the 64 byte report data field.  If the stock Intel SDK is being used for attestation, a 32 byte (256 bit) NIST P-256 public generator key will be used in the field.  Our POSSUM protocol, which we wrote specifically to support secured enclave<->enclave communication based on bilateral remote attestation, uses this field to authenticate a Curve25519 public generator key.

It is important to note that this field is 'in the clear' and has no confidentiality guarantees associated with it.  The field only has an integrity guarantee that it was generated by an enclave with the specified identification characteristics, ie; signer measurement, enclave measurement, version number and security version values.  Also included, as a component of the attestation report, is a statement of platform conformance to the Trusted Computng Base (TCB) that has been designated as known good for the platform that is generating the attestation quote.

With respect to the ability of this to scale, the only bottleneck is the amount of computational resources that Intel is using to implement IAS.  The service is platformed on the Amazon EC2 cloud so presumably all of this has been designed with surge capacity and similar considerations.  Just for clarity, IAS doesn't have to have any knowledge of an enclave, all it is doing is verifying that the quote came from a platform that has been previously provisioned with an Intel issued EPID.  Intel is thus serving as the 'trusted third party' in the establishment of the security context.

From a security design perspective, an attestation should be requested every time there is a need to create a security context between an enclave and a verifying party/application.  Presumably this would occur as a component of session setup for whatever type of communications is being conducted.

In the standard Intel SDK all of this is a bit confusing since the attestation is mediated by an SP.  This means that a verifying party has to create a security context between itself and the SP and mediate the key/report data exchange through that context.  We elected to bypass all of that which considerably diminishes the security domain that has to be verified/trusted.

The statement was made above that Intel isn't supporting attestation by third parties.  That doesn't mean that it isn't possible to implement an independent attestation service but does require that someone roll up their sleeves and write a bit of code.  As a component of the provisioning process, Intel sends a copy of the group public key to the platform being  provisioned.  This is a requirement so that the platform can conduct its own independent pairing with the group key in order to support the generation of the platform's private EPID key.  The key and the group identifier come down in the second message from the Intel provisioning service and again in the fourth message.

As I noted in the following thread:

https://software.intel.com/en-us/forums/intel-software-guard-extensions-intel-sgx/topic/781730

Intel makes the EPID member and verifier code available in open source form.  The path forward would be to abstract the group key(s) from the provisioning process and transform the key into a form that could be used with the EPID verifier code to verify an EPID based signature generated by a QE over a platform report.

We would find it interesting to hear any compelling arguments as to why this wouldn't be possible.  We may write a proof of concept implementation depending on other deadlines we have and/or interest by parties we are involved with who have voiced concerns about single source attestation services.

Hopefully all of this helps with advancing a general understanding of how attestation works.  We can certainly answer additional questions either publically or privately if anyone wants to use our web-site to contact us.

Best wishes for a pleasant weekend from the Upper Midwest.

Dr. Greg

[Scott_R_Intel]

Dr. Greg, et al.

I made a note of a few attestation questions posted on the forums in the past so I could come back to them at the right time...

I just wanted to make you all aware of some new 3rd party attestation primitives that were recently announced and released, in case you hadn't already seen them.  Our new Data Center Attestation Primitives (DCAP) help large enterprises and service providers provide a way to build out their own attestation capabilities.

A new whitepaper was just recently published with info and lots of links on DCAP:

https://software.intel.com/en-us/blogs/2018/12/09/an-update-on-3rd-party-attestation

Regards.

Scott