Attestation from multiple users

[Info__SGX]

I have a question regarding the SGX attestation mechanism. SGX allows for an application owner to attest the enclave using the Inter-platform enclave attestation, which involves the application, enclave, and quoting enclave to return a QUOTE structure. My understanding is that this allows the remote user to verify that the enclave has been instantiated correctly, i.e. by ensure the value of MRENCLAVE. Please correct me if I'm wrong.

Is a separate 3rd party remote user allowed to use this attestation mechanism on the same enclave? Let's say that the application owner has already attested the enclave, and now the enclave is performing some service to the owner's application. A 3rd party user (not application owner) wants to perform attestation on this enclave. Is this possible?

[JesusG_Intel]

Hello Info, SGX,

Yes, more than one than 3rd party application can attest the same enclave. By nature, SGX enclaves are independent from outside applications because the enclaves do not trust outside entities. The remote, relying 3rd party can live somewhere on the internet or on the same premises as the enclave. It is up to the 3rd party to determine and implement how they will communicate securely with the enclave.

Regards,

Jesus

[user14]

Hey,

Thanks! I am developing a similar application, where multiple 3rd parties attest an enclave. I am confused about the SP's public key that is passed in sgx_ra_init().

1. Which attack this public key helps us prevent?
2. It's recommended that the SP's public key should be hardcoded in the enclave. So, do we make multiple enclaves with different public keys for each SP?

[JesusG_Intel]

Hello Tarun,

We must remember why remote attestation is used in the first place. Remote attestation occurs when a client application, such as a Blue Ray player application running on your computer, needs to contact a service provider in order to retrieve secrets from the service provider. The service provider cannot give the secrets to just any application that asks for them. Instead, the service provider requires the client application to prove that it is legitimate and is approved to receive the secrets from the service provider. In our case, the enclave that is associated with the client application is used to store and provide the secrets that the remote service provider uses to verify the authenticity of the request from the client.

The service provider's public key is used by the enclave to generate a context that is used in the rest of the key exchange process (based on the Diffie Hellman Key Exchange algorith) with the service provider. The public key is hard-coded in the enclave so that the enclave can communicate only with the service provider that owns that public key. If the public key were instead passed to the enclave via other means, then an attacker can use that enclave to communicate with a different service provider and cause havoc.

If you want the enclave to be able to communicate with other service providers, then you can hard code the public keys of each service provider in the same enclave. The client application would then somehow tell the enclave which service provider key to use depending on which service provider it wants to communicate with. Again, by hardcoding the keys in the enclave you ensure that the enclave communicates only with the limited, pre-approved list of service providers.

You may find these discussions helpful: 

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

remote attestation end-to-end example , which states, "The Service Provider's public key should be hardcoded into the enclave. This, combined with enclave signing, ensures that the key cannot be changed by end users so that the enclave can only communicate with the intended remote service."

The comment below is found in the source code of client.cpp for the remote attestation end-to-end example     

* WARNING! Normally, the public key would be hardcoded into the
* enclave, not passed in as a parameter. Hardcoding prevents
* the enclave using an unauthorized key.

Regards,

Jesus

[user14]

Thanks, all the explanations helped me understand things more clearly.

So, there is two-way authentication. The service provider verifies the identity and validity of the enclave by getting a report from IAS and the enclave authenticates the SP by using a hardcoded public key. 

In my application, there can be 'n' number of SP which can't be predetermined. In my use case, I want to allow anyone to communicate with the enclave and verify it. Is it a bad thing to do?

 The public key is hard-coded in the enclave so that the enclave can communicate only with the service provider that owns that public key. If the public key were instead passed to the enclave via other means, then an attacker can use that enclave to communicate with a different service provider and cause havoc.

Can you please point out the security issues I'll have if I allow anyone to communicate with my enclave? Let's say my enclave just do some operations on the request and returns the response. SP creates a secret channel using remote attestation and then sends a request and then receives a response. 

[JesusG_Intel]

Hello Tarun,

Remote Attestation is used when the enclave client (i.e. the platform that hosts the client application and enclave) initiates the communication with the service provider, hence the service provider is providing a service to the enclave client. In your case, it seems that you want the service provider to play a different role in relation to the enclave client. Your service provider may be providing services to other clients, but your enclave is providing a service to your service provider. In this case, you would not do remote attestation. Your service provider applications must authenticate themselves to the host application on your enclave platform and the host application communicates directly with the enclave in the platform via ecalls and ocalls.

You must think about what secrets are being exchanged between the enclave client and the "service provider." What kind of "operations" are you thinking of doing with your enclave? Remember, remote attestation is used when the client enclave wants secrets from the service provider. The service provider uses remote attestation to ensure that it is safe to send the secrets to the enclave.

[user14]

Thanks!

Sorry for the incomplete explanation of my application. I'll try to make it more clear.

In my case, there is x number of clients and y number of SPs. These numbers are dynamic. In my application, a client initiates communication with an SP, and SP sends that client a challenge string. The client must perform some operations(explained in the next paragraph) on it and sends back the response to SP. By using the remote attestation, an SP wants to make sure that the client executed those operations correctly and integrity of the response. So, In my case, I am using remote attestation for the integrity of the response from the client after some operations. 

I want to use the client's enclave for website account authentication. A user can go to a website and register themselves. At the time of registration, the SGX creates a public-private key pair and sends the public key to the SP. To make sure that the OS doesn't replace the public key during registration, SP uses remote attestation. At the time of account authentication, the website will send a challenge (along with its identity like foobar.com) that must be signed by the corresponding private key. The SP verifies it using the public key it received during registration. Here, the host OS can do MITM. It can impersonate as a website lets say foobar.com. To prevent it, an SP sends a public certificate to the enclave, on receiving it, the enclave verifies the validity of the certificate (checks if signed by a valid CA) and matches the certificate's identity(URL) with the identity in the authentication challenge, if there is a match, the enclave uses that public certificate key for DH process to creates shared key between enclave and SP. This way, at the time of account authentication the enclave always communicates to the intended website. 

Are there some issues if I go with this approach? 

One more question, if the SP's public key is transferred through the network to enclave and OS try to replace it, would it be able to execute complete MITM? I think it will only be able to impersonate as an SP to enclave but wouldn't be able to impersonate as an enclave to SP. As, in the attestation proof, the public key of the enclave is there, if an attacker just forwards it to SP, it won't be able to MitM and it can't generate its own attestation proof. Is it right or am I missing something?

[JesusG_Intel]

Hello Tarun, you mentioned that there could be any number of service providers and they cannot be predetermined?  Do you realize that each SP has to be programmed to communicate with the enclave and licensed to use the Intel Attestation Service?

You are right, if the service provider's public key is tampered with in transmission, and the enclave uses that public key to communicate with the service provider, then the attacker can impersonate the service provider to the enclave. Remote attestation prevents an attacker from impersonating an enclave and hard coding the public key helps the prevent the service provider from being impersonated.

Also, your client base will be limited to clients with processors and BIOS that support SGX.

Other than authenticating to the service provider, what is the job of the enclave? The enclave would normally be used to seal a secret locally that is first provided by the service provider. For example, a key or hash that is used to decrypt BluRay data locally. If the enclave's only roll is to authenticate, then it seems like your use case can be solved using current technologies that do not require SGX and remote attestation.

[user14]

you mentioned that there could be any number of service providers and they cannot be predetermined?  Do you realize that each SP has to be programmed to communicate with the enclave and licensed to use the Intel Attestation Service?

Yes, I understand that.

 your client base will be limited to clients with processors and BIOS that support SGX.

I understand that. It's an optional feature, So I think it would be fine.

Other than authenticating to the service provider, what is the job of the enclave? The enclave would normally be used to seal a secret locally that is first provided by the service provider. For example, a key or hash that is used to decrypt BluRay data locally. If the enclave's only roll is to authenticate, then it seems like your use case can be solved using current technologies that do not require SGX and remote attestation.

The primary purpose of my enclave is to authenticate. The enclave also seals the private key generated during registration. So it can't be accessed by anyone other than the enclave for authentication. We trust the enclave doesn't do anything malicious with that private key and verifies the public certificate of the SP before returning a authentication response. I can't think of a way to do it without using SGX and remote attestation. If I don't use SGX, a malicious OS would have access to the private keys registered with all the SPs.  In my threat model, I want to protect the authentication private keys from the OS. Is there anything I'm missing here?

[JesusG_Intel]

Hello Tarun,

I get it and so do you. You need to solve the problem of how to securely provision the public keys of the service providers to the enclaves. The remote attestation documentation says that the public keys should be provided to the enclave developer before the enclave is implemented so that the public key can be hard coded. If you don't do this, you have to find another way.

Regards,

Jesus