Encrypt /dev/attestation/keys/my_key with _sgx_mrenclave (makes sense?)

[tiagorvmartins]

Hey Gramine team, quick question, does it make any sense or is it even possible to receive a key from a secret provisioner and write it to a path that is a fs mount with encrypted key _sgx_mrenclave?

We made it working using standard allowed files on path /dev/attestation/keys/my_key instead of fs.mount encrypted

But we would like this 'wrap' key received by the secret provisioner to be encrypted as well by the _sgx_mrenclave,

Why you may ask?

• We do have concerns that if we attach a docker volume to /dev/attestation/keys this will be exposed to outside, which we don't want - not sure this is a problem though, since these are pseudo-file, so just wondering here?

Thank you!

[kailun-qin]

Hi @tiagorvmartins, thanks for your questions!

is it even possible to receive a key from a secret provisioner and write it to a path that is a fs mount with encrypted key _sgx_mrenclave?

Yes, it is possible to write to the path /dev/attestation/keys/ but the key name (in your case my_key) has to be specified somewhere in the manifest (e.g., in an encrypted mount where my_key is used for encrypted files). Pls see some discussions here: #1412. May I know the usage of my_key (i.e., is this for encrytped files or app-specific)?

We made it working using standard allowed files on path /dev/attestation/keys/my_key instead of fs.mount encrypted
But we would like this 'wrap' key received by the secret provisioner to be encrypted as well by the _sgx_mrenclave,

Sorry I did not understand: you'd like this 'wrap' key received by the secret provisioner to be encrypted as well by the _sgx_mrenclave but you made it working using standard allowed files on path /dev/attestation/keys/my_key instead of fs.mount encrypted? If you want it to make it persistent and protected by _sgx_mrenclave, why allowed files?

We do have concerns that if we attach a docker volume to /dev/attestation/keys this will be exposed to outside, which we don't want - not sure this is a problem though, since these are pseudo-file, so just wondering here?

I think your current usage of allowed files for my_key would simply make it in plaintext outside Gramine.

[tiagorvmartins]

Hey @kailun-qin sorry for tagging, just need a clarification on this please.

I believe I understood but would like some confirmations from the team:

1. the path /dev/attestation/keys/ only exists inside Gramine as pseudo files and not in the untrusted host, they are not written to disk (?)
2. assuming 1) is true, there is no way to extract the keys from that path to outside of the running Gramine process.
3. assuming 1) and 2) are true, there isn't really the need to encrypt the secret key itself on that path.

Can you confirm or deny every point above? Thank you!

More notes: Even if I wanted to encrypt the key on /dev/attestation/keys/the_key I would need to use fs.mount, and that specific scenario was failing on my end, was getting permission denied when using fs.mount on /dev/attestation/keys/my_key with type encrypted and key name _sgx_mrenclave. Can elaborate more on this, if required, with a simple sample.

I did accept the answer before, but wanted to confirm because some bits are still unclear to me, thank you again so much!

[dimakuv]

1. the path /dev/attestation/keys/ only exists inside Gramine as pseudo files and not in the untrusted host, they are not written to disk (?)

This is correct. The files under this directory are ephemeral and exist only inside of the Gramine SGX enclave, and only for the lifetime of this SGX enclave.

2. assuming 1) is true, there is no way to extract the keys from that path to outside of the running Gramine process.

There is no "automatic" way to extract the keys from that directory. But one can always write a program that performs a copy
cp /dev/attestation/keys/my_key /usr/real/path/on/hard/disk/my_key_copy

This explicit way works. Similarly, one can copy in the other direction -- copy the existing key on the hard disk to this directory, so that all Gramine FS mounts marked with my_key will use the copied key for decryption/encryption of files. (In fact, that's what our Secret Provisioning library does under the hood.)

3. assuming 1) and 2) are true, there isn't really the need to encrypt the secret key itself on that path.

Yes, under that path you don't need to encrypt the secret key. But if you copy this key from/to somewhere else, then you need to encrypt that copy of the key.

More notes: Even if I wanted to encrypt the key on /dev/attestation/keys/the_key I would need to use fs.mount, and that specific scenario was failing on my end, was getting permission denied when using fs.mount on /dev/attestation/keys/my_key with type encrypted and key name _sgx_mrenclave. Can elaborate more on this, if required, with a simple sample.

Yes, this is not supposed to work. You must never specify the FS mount /dev/attestation/keys in the manifest file. Gramine mounts this automatically for you on startup, and populates this special directory by itself.

So real world scenarios always use some form of "copy the received/read from disk key into /dev/attestation/keys/".

[tiagorvmartins]

This makes sense to me and clarifies all my remaining doubts, thank you @dimakuv!

[mkow]

does it make any sense or is it even possible to receive a key from a secret provisioner and write it to a path that is a fs mount with encrypted key _sgx_mrenclave?

I think it does if your goal is continue using the enclave without the need to contact the provisioning server on each run (and if that's fine in your security model).

• We do have concerns that if we attach a docker volume to /dev/attestation/keys

I don't see what Docker has to do with the security of this idea? Something is either inside Gramine or on the untrusted host, the whole Docker thing is within the untrusted host.

[tiagorvmartins]

Thank you both that answered my question!