0

The Intel official remote attestation sample code, e.g. https://www.intel.com/content/www/us/en/developer/articles/code-sample/software-guard-extensions-remote-attestation-end-to-end-example.html, describe a model that encalve runs in client and server provides secret data, as the below picture shows.

Intel Remote Attestation Model

But I want implement a service that computes user's secret data in enclave. So there are many clients providing secret data and a server running encalve. The obstacle is that the intel sgx sdk doesn't fit this model. For example, function sgx_init_ra declared in sgx_tkey_exchange.h accepts a public key for later verification, and intel's document recommends hard-coding the public key into the enclave code.

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.

This fits intel's remote attestation model, but not mine. Becuase in my model, there are many client(secret data provider), and it's difficult to get the client's public key safely.

So, Is there a method to use intel sgx sdk in this model?

Nada
  • 3
  • 1

1 Answers1

0

Intel, for sure, recommends that you hardcode RA server's public key, but it;s not at all mandatory.

I'm working on a research project that implements enclaves that, upon start, contact a key distribution/rotation server. This server holds all the private/public/symmetric keys needed and distributes them in a secure manner.

If you don't want to hardcode the RA server's pubkey in your enclave, then use the untrusted part of your app to contact a server that will provide the key for you. A way to secure the transaction is the use of MRSIGNER as the identity of the enclave.

To sum up, the workflow could be the following:

  • APP, UNTRUSTED: contact key server, fetch RA server's pubkey
  • APP, UNTRUSTED: create the enclave, provision it with the pubkey
  • APP, TRUSTED: complete the attestation process
  • and so on.

But to be clear: be aware that the attesation's goal is twofold. The first is to attest an enclave, the second (which may interest you) is to establish a secure communication channel using the session key generated during the RA's DHKE. This is your secure way to exchange info between the RA server and the enclave.

X99
  • 905
  • 10
  • 24