Search code examples
securityopen-sourcesgxtrusted-computing

Using Intel SGX Remote Attestation in a Client-Server Architecture


Assume the following scenario: we want to implement an open-source 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 (please ignore current attack research on SGX enclaves).

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 another show stopper for SGX? Using SGX without the attestation feature seems to be useless.
  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.

P.S.: This question is kind of consecutive to Intel SGX developer licensing and open-source software


Solution

  • One does not need an Intel-registered certificate to create a quote but one does need to communicate with the IAS (Intel Attestation Service) to verify a quote, which requires an Intel-registered certificate. So every node checking if a remote attestation is valid would require such a certificate in a naive approach.

    One could of course leverage SGX to provide a proxy which would be structured somewhat like that:

    1. Generate two certificates and their corresponding private key, I'll name one of them the IAS-conn-cert and the other one the Proxy-cert.
    2. Register the IAS-conn-cert of them to the IAS.

    Of course, you need to have to trust that these certificates were indeed generated in an enclave. To do so, you could remotely attest to another service provider you trust. Now pin (by for example hard-coding) the Proxy-cert in your client application. When it needs to verify a quote, it connects to the enclave using that pinned proxy-cert thus knowing it connects to the enclave. The enclave will then connect to the IAS and relay everything it receives from the client to the IAS and vise-versa. The client can now communicate with the IAS without having to own an IAS-registered certificate but can still be assured that there is no tampering in the proxy, given that it trusts that the proxy-certificate was indeed generated in a non-malicious enclave.