gramine-sgx-pf-crypt encrypt based on mrenclave/mrsigner

[tiagorvmartins]

Looked for documentation around this tool and couldn't find a answer to my question, so asking here,

According to my understanding of it, gramine-sgx-pf-crypt is a tool that can be used to encrypt/decrypt data, this data can then be used inside a running gramine enclave which decrypts the data using a secret server provisioning, which will provide the key to decrypt the data that got encrypted and mounted into the gramine process.

I may be wrong, but I don't see any relationship between the encryption process (at least on the arguments of this tool) and the system encrypting the data.

Let me explain better, basically I would like this data to be encrypted in a way that only a specific enclave having a specific mrsigner/mrenclave could decrypt the data, because it seems to me that if the "wrap_key" used to encrypt the data gets leaked, then anyone could in fact decrypt the data, correct?

More on this (https://gramine.readthedocs.io/en/stable/manifest-syntax.html#encrypted-files)

Key names beginning with underscore (_) denote special keys provided by Gramine:

"_sgx_mrenclave" (SGX only) is the SGX sealing key based on the MRENCLAVE identity of the enclave. This is useful to allow only the same enclave (on the same platform) to unseal files.

"_sgx_mrsigner" (SGX only) is the SGX sealing key based on the MRSIGNER identity of the enclave. This is useful to allow all enclaves signed with the same key (and on the same platform) to unseal files.

If I understood correctly, this is to be used on the manifest files when using the encrypted FS volume, with key_name param, not entirely sure how this works, but couldn't someone just create a different manifest file (with different _sgx_mrenclave and _sgx_mrsigner) and generate a new gramine enclave attach the same data and decrypt the data (assuming that they would have access to the volume encrypt data and secret server provisioning would provide to them the "wrap_key") ?

What confuses me even more generally on this process is that gramine-sgx-pf-crypt can even be ran with decrypt arg completely outside of a running enclave as long as the user has access to the "wrap_key", correct?

To sum up, is there any way to encrypt the data in a way that only specific mrenclave is able to decrypt it?

Thank you!

[kailun-qin]

Hi @tiagorvmartins! Pls see my comments below.

it seems to me that if the "wrap_key" used to encrypt the data gets leaked, then anyone could in fact decrypt the data, correct?

Yes.

"_sgx_mrenclave" (SGX only) is the SGX sealing key based on the MRENCLAVE identity of the enclave. This is useful to allow only the same enclave (on the same platform) to unseal files.
"_sgx_mrsigner" (SGX only) is the SGX sealing key based on the MRSIGNER identity of the enclave. This is useful to allow all enclaves signed with the same key (and on the same platform) to unseal files.

but couldn't someone just create a different manifest file (with different _sgx_mrenclave and _sgx_mrsigner) and generate a new gramine enclave attach the same data and decrypt the data (assuming that they would have access to the volume encrypt data and secret server provisioning would provide to them the "wrap_key") ?

I don't understand -- if (s)he specifies the encrypted file mounts using the key_name of _sgx_mrenclave or _sgx_mrsigner, then the data to be decrypted has to be encrypted using the sealing key, i.e., no sense/usage of "wrap_key" in this case. As explained in the manifest doc, the sealing keys are based on the MRENCLAVE and MRSIGNER identity of the enclave, a new enclave having different MRENCLAVE/MRSIGNER cannot get the same key, hence is not able to decrypt the data.

What confuses me even more generally on this process is that gramine-sgx-pf-crypt can even be ran with decrypt arg completely outside of a running enclave as long as the user has access to the "wrap_key", correct?

Yes, the "wrap_key" must be kept in secret by the user and has to be previsioned to the enclave using a secure channel established after proper remote attestation. This guarantees that except the user her/himself and the enclave that a user has attested/trusted have the access to the "wrap_key", any others won't be able to access the key thus decrypt the data.

To sum up, is there any way to encrypt the data in a way that only specific mrenclave is able to decrypt it?

Yes, you can specify _sgx_mrenclave in the encrypted file mounts to encrypt and bind spefic data to MRENCLAVE. Alternatively, your enclave app can perform file encryption by itself, using the SGX sealing keys exposed under /dev/attestation/keys/_sgx_mrenclave.

[tiagorvmartins]

Hi @kailun-qin thank you for your reply, I believe I understood.

The problem then (on our side) is doing the encrypting of the data outside of the enclave and relying only on the wrap_key.
I believe then the correct procedure, will be, the secret server provisioning running inside the enclave and being the one of generating this encrypted data.

Then on the other enclave "consuming" this data, we would use a key_name with _sgx_mrenclave on the FS mount volume matching the mrenclave of the other secret server provisioning?
Is that it?

Thank you again!

[kailun-qin]

Then on the other enclave "consuming" this data, we would use a key_name with _sgx_mrenclave on the FS mount volume matching the mrenclave of the other secret server provisioning?

The challenge here would be it's hard to have "the other enclave consuming this data" and the "secret provisioning server enclave" to have the exact same MRENCLAVE (since it uniquely identifies any particular enclave via its measurement).

To make is secure in your case, IIUC, you can simply make the encryption key ("wrap_key") generation and data encryption in your "secret provisioning enclave". Then on "the other enclave consuming this data", it'll still use this "wrap_key" for encrypted mounts instead of _sgx_mrenclave. And since "the other enclave consuming this data" won't get such key until you have attested it properly, i.e., checking its MRENCLAVE and authenticity via remote attestation, it's guaranteed that the only enclave having the expected MRENCLAVE can consume that data.

[tiagorvmartins]

Thank you!
I missunderstood the purpose of _sgx_mrenclave, even having two different enclaves with different mrenclaves,
I thought the purpose of _sgx_mrenclave (on consumer enclave) could be used as the key (this key would be the producer enclave mrenclave) to decrypt the data.
But I guess it doesn't work this way.

[kailun-qin]

Right, to recall, the _sgx_mrenclave key is "the SGX sealing key based on the MRENCLAVE identity of the enclave, which is useful to allow only the same enclave (on the same platform) to unseal files".