Remote Attestation in a Client-Server Architecture with Multiple Clients

[Leinweber__Marc]

Hey everybody,

Assume the following scenario: we want to implement a password manager that uses a central service that enables the different clients (on different devices) to synchronize their local databases. It doesn't matter if this service is run by a company or on a server of the user (compare to owncloud usage scenarios). To make our application more "secure", we want to use an Intel SGX enclave for the central service.

Then, the typical workflow would be:

1. local client attests central enclave
2. user registers / logs in
3. (local and remote database are synced)
4. user stores / retrieves passwords

Now my question: Does every user of our password manager need to register with the Intel Attestation Service (IAS)? If yes, wouldn't this imply that, since private key sharing is really bad, every single device needs to be registered?

According to my investigations, the answer is, at least for the development and testing phase, yes. I could not find any public information for production scenarios. All I know is that a business registration changes the behavior of the enclave (it can be run in production mode) which is not of any matter here. I have two thoughts on this:

1. If I am correct, isn't this a show stopper for SGX? Using SGX without the attestation feature seems to be useless but the above mentioned use case seems to perfect for SGX.
2. How do services such as https://www.fortanix.com/ circumvent or solve the problem? Their documentation does not give a hint for needed interaction with Intel.

The above described scenario is only an example; it can be improved and we do not plan to implement it. But it was a lot easier to describe a scenario, that can be easy imagined and seems to be a realistic use case for SGX, than describing our current project plans.

Thanks in advance for your help,
Marc

[Scott_R_Intel]

Hi Marc.

Short answer...  no, every user/client does not have to register with IAS.  Only the service provider's (you) server ("ISV Remote Attestation Server") would need to register with IAS.  It is the only component that actually "talks" to IAS.  Then, after a successful "remote attestation" of your enclave distributed to the clients, you can securely distribute any secrets you'd like (passwords, keys, etc).

For more info on remote attestation, including some good diagrams demonstrating RA, see this article and it's associated sample on GitHub:

https://software.intel.com/en-us/articles/code-sample-intel-software-guard-extensions-remote-attestation-end-to-end-example

https://github.com/intel/sgx-ra-sample

Note, your server does not necessarily have to support SGX to utilize remote attestation.

Hope this helps.

Scott

[Leinweber__Marc]

Hi Scott,

Thank you for your answer but I believe that you maybe misunderstood my scenario. I don't want the enclave to be rolled out to every client. In my scenario the users trust their local clients but they distrust the central service enclave. Thus, the central service utilizes SGX and each of the local clients needs to attest the central enclave remotely to be able to trust it.

If I would use a central attestation server, the clients would need to trust this server. However, if this server is malicious it could manipulate the response to the individual clients.

Best wishes,
Marc

[JohnMechalas]

To do this properly, you'd want to have enclaves on both the client and server and have them attest to each other. Otherwise, the untrusted application on the client could be modified by malicious software to always report the server as trusted. The advantage of Intel SGX is that the enclaves are immutable once compiled and signed. This is important when deploying software to client systems, especially ones you don't control.

Regardless of where the enclaves sit, it's the enclave signer (you, the software vendor) that registers with IAS to use remote attestation, not the end user.

[Leinweber__Marc]

Hi John,

Thank you for your answer. I know that the above mentioned scenario can be improved. I have chosen this simple scenario to give us an easy to understand image on which we can base our discussion.

For the following I refer to the first link provided by Scott.

Figure 2 states that the service provider establishes during remote attestation an authenticated channel to the client application that has an enclave part. The service provider establishes a connection to the IAS using MTLS and the IAS verifies the quote that the service provider received from the enclave.

Now I want to extend this scenario. The enclave offers a central service, e.g. a trusted data store in the cloud. In fact, the enclave is now a service provider itself. Say, my company is the software vendor for the data store service enclave. Additonally, we operate instances of this service and sell the access to it to our customers. To enable our customers to use this service, we also maintain and sell a client software, which itself has in scenario 1 an enclave part but in scenario 2 not. The client software connects to the data store in the cloud, they perform a (in scenario 1 mutual) remote attestation and eventually the client software can be used to retrieve data from resp. send data to the cloud service enclave which in turn seals and stores it for future requests. I have attached to figures that illustrate both of the scenarios.

Now, to my understanding, an attester, a party that wants to verify a quote, has to communicate with the IAS (according to Scott's link and the SGX Developer Guide). According to the IAS API Spec (I have revision 4.1) the attester has to establish a MTLS connection to the IAS. In this connection, the quote is transferred to the IAS which, in return, give a success or failure message.

My understanding was that the certificate used for enclave signing is not the same that is used for the MTLS protocol during Remote Attestation communication with IAS. Additionally, since each attester has to have the private key corresponding to the certificate, how can I ship this private key to the attesters (regardless of their state - enclave or not)? So is my understanding correct, that, when I do not want to or cannot introduce a single Remote Attestation Server as proposed by Scott, each Client needs to register with IAS?

Thank you,
Marc

[JohnMechalas]

At some point, the clients need to establish a connection to a trusted service in order to securely provision a secret. That trusted service does not have to be the same system as your central password server in your example. But you do need something that you can say is trusted, that the clients implicitly will trust, otherwise you're not going to be able to resolve this cleanly.

The short answer to your question of "how do I put the same private key on the clients" is to not do that in the clear. It's to use the encrypted enclave option in SGX to place an encrypted enclave on the client systems. That enclave will need to do a remote attestation initially in order to obtain a decryption key from some central service that you control and maintain. That central service is considered trusted.

Using encrypted enclaves allows you to statically provision a secret, such as a private key, into an enclave. Only the loaded, decrypted enclave will have access to that secret. Encrypted enclaves include a bootstrap enclave to perform the initial remote attestation, obtain the decryption key for the "real" enclave, and seal it to disk (so that RA is not necessary every time the enclave loads) with some time-based policy that you determine.

So, for your situation, you could do the following:

1. Deploy a client enclave that is the same on all clients. That enclave would be encrypted, and contain a statically compiled secret.
2. Deploy a central password service in each data center or enterprise environment that also contains an enclave. 
3. Set up a provisioning server that the clients in #1 must attest to in order to obtain their enclave decryption keys.

It would make sense to use an encrypted enclave for the central service in #2, as well, since in your model it is untrusted. This means any private key stored on that system outside of an enclave would also be untrusted.

With this model, you would not necessarily need the clients to perform a remote attestation to validate the central service. Both enclaves could be provisioned with static keys that are used to generate a shared session key. The enclaves would not be able to negotiate a session unless they both had the correct secret.

[Leinweber__Marc]

Hey John,

Thank you so much for answer. This clarified a lot for me.

Best wishes,
Marc