Use MRENCLAVE-based EGETKEY for parent-child secure channel establishment

[kailun-qin]

Description of the feature

Currently Gramine is using the DHE-based key exchange (fixed to 3072 bit prime order multiplicative groups) plus the combination w/ SGX local attestation (for authentication) to establish secure channels between the parent and child enclaves. See https://github.com/gramineproject/gramine/blob/8fe78a6752a86c91afe0552387bb1395b6d0c294/pal/src/host/linux-sgx/pal_process.c.

There seems to be no need to perform DH and verify each other's SGX info in such case if we know that both the parent and the child will produce the same SGX key if we use MRENCLAVE-based EGETKEY instruction.

Why Gramine should implement it?

This approach seems reasonable (needs some crypto-experts' evaluation though) and may simplify our complex logic in pal_processes.c.

[dimakuv]

I agree with this note. Maybe our SIGMA-like protocol is indeed an overkill for our Gramine parent-child case, because both the parent and the child always have the exact same MRENCLAVE, ATTRIBUTES, and other security-critical measurements.

In other words, it looks like we can shift the burden of generating a symmetric crypto from a software implementation (a modified DHE key exchange/SIGMA software protocol) to the hardware implementation (EGETKEY derivation provided by Intel SGX).

We should just be very careful with what inputs we provide to EGETKEY, so that it's impossible for e.g. a debug child enclave to connect to the production parent enclave.

[mkow]

if we know that both the parent and the child will produce the same SGX key

You almost stated the problem in this very sentence :) Other parent<->children will also have the same connection key and we'll end up with a few connection streams encrypted with the same key, making them decryptable (like, almost fully decryptable if the we end up using a stream cipher inside TLS).

We'd need to use a KDF and mix something like (parent_id, child_id) into the key.

[kailun-qin]

like, almost fully decryptable if the we end up using a stream cipher inside TLS

But we have the cipher used in control so this won't happen (w/ a COA-resistant cipher)?

We'd need to use a KDF and mix something like (parent_id, child_id) into the key.

Anyway, yes I agree -- better to use a KDF. When I stated use MRENCLAVE-based EGETKEY, I actually did not limit to use the SGX key directly as the session key. But mix something like (parent_id, child_id) into the key seems hard, we don't have this common (parent_id, child_id) in both parent and child for KDF before having an established secure channel (just like a circular dependency).

Alternatively we may use it to seal the session key/PSK/common secret so that they can only be unsealed by one w/ the same enclave identity afterwards.

[mkow]

But we have the cipher used in control so this won't happen (w/ a COA-resistant cipher)?

We're using Mbed TLS interfaces which (AFAIR) assume that the symmetric key cannot be reused between connections. I don't know well how TLS works internally, but it actually doesn't matter - what matters is the Mbed TLS API we're using and what it assumes about the key.

Anyways, I'm fine with changing this code but only if you provide a convincing proof that it will still be secure :) The old code was verified a few times and I'm a bit hesitant to touch it without a proper security/crypto analysis.

[dimakuv]

if we know that both the parent and the child will produce the same SGX key

You almost stated the problem in this very sentence :) Other parent<->children will also have the same connection key and we'll end up with a few connection streams encrypted with the same key, making them decryptable (like, almost fully decryptable if the we end up using a stream cipher inside TLS).

We'd need to use a KDF and mix something like (parent_id, child_id) into the key.

Yes, sorry, you're absolutely right here. We do need to throw the unique IDs into the KDF mix. But as Kailun stated, the exchange of IDs should be secure (tied both to the key-generation materials and to the SGX enclave identity), which is problematic.

Anyways, I'm fine with changing this code but only if you provide a convincing proof that it will still be secure :) The old code was verified a few times and I'm a bit hesitant to touch it without a proper security/crypto analysis.

Indeed. Kailun just had this idea, and we wanted to dump it here to not forget about this. We didn't think much about the correctness and security properties. It might well be that this won't work at all (due to the problem above), and in the end the protocol becomes the same as what we have now.

[dimakuv]

Ok, maybe we should have created a Discussion rather than an Issue. I can move this to Discussion, if you want.

[mkow]

Yeah, I'd move it there until we have a clear proposal how to do that change.

[dimakuv]

Done.

[mkbhanda]

Think of a rogue child enclave .. if it can see process-ID of other enclaves, it could reverse engineer session encryption keys for other parent-child pairs? So something with parent-child ids would just not be secure. At the point of child creation, could parent pull some randomness and share with child as part of initialization?

[mkow]

if it can see process-ID of other enclaves, it could reverse engineer session encryption keys for other parent-child pairs?

But it either has a different MRENCLAVE, thus EGETKEY will generate a different key, or it has the same MRENCLAVE, which means it's Gramine so it's not a rogue enclave.

[mkbhanda]

Thank you @mkow. My error, mixed up MRENCLAVE with MRSIGNER.