Support for Key Separation and Sharing (KSS)

[atsuki-momose]

Dear Gramine Team,

We understand that KSS is currently unsupported in Gramine. We believe this is a crucial feature in some cases, such as mutual attestation. For example, suppose we have two enclaves, P and Q. Enclave P can attest Q with a hard-coded measurement (i.e., MR-Enclave) of Q. However, Q lacks the measurement of P in its attested enclave. Therefore, P’s measurement must somehow be provided without changing Q’s measurement. The extended IDs in KSS, such as the extended product ID or configuration ID, are thus necessary for resolving this asymmetry.

We have noticed some related discussions that appear to remain open:

• RFC: Add support for KSS (key separation and sharing) #800
• Support SGX extended product ID #903

Could you kindly let us know if there is any plan to support KSS in the near future?

Thank you!

[kailun-qin]

@atsuki-momose: Thank you for your interest in KSS support in Gramine!

Could you kindly let us know if there is any plan to support KSS in the near future?

Currently, we have no plans to support KSS in the near future. Could you please share how you intend to use KSS in Gramine, like are you looking to use it in a production environment or for research purposes?

[atsuki-momose]

@kailun-qin: Thank you for your quick reply! We are planning to use KSS to design a microservice system that we may adopt in our production environment. Specifically, we are considering two Gramine instances, P and Q, for different tasks, which may run on the same host or on separate hosts. Our requirements are:

1. P must send data to Q through a secure channel
2. Q must communicate exclusively with P.

To establish a secure channel, P must attest to Q using a known measurement value (i.e., the MR-Enclave hard-coded in P). At the same time, Q must attest to P to satisfy the second requirement. However, since P’s measurement is only available after Q’s measurement has been determined, it cannot be hard-coded in Q. Although P’s measurement could be provided at runtime, we prefer binding it to the quote without service-level mutability for security reasons. For these reasons, we plan to use the config ID to bind P’s measurement to Q’s quote.

[atsuki-momose]

@mkow: In this scenario, Q’s config ID includes the MR-Enclave of P. During the attestation process, P receives Q’s quote and verifies that the config ID matches its own MR-Enclave, ensuring that Q communicates exclusively with P. Although binding the MR-Enclave in the user-level report data is an option, we prefer binding it to an immutable ID for enhanced security.

[mkow]

Hmm, I don't see why can't you do exactly the same without KSS? In KSS scenario P verifies MRENCLAVE+CONFIGID of Q and only then sends secrets to Q, and without KSS you can either:

• Just remove the Q->P check and ensure that Q only talks on the TLS channel on which it received the secrets (this seems to be the simplest solution of all). An attacker could still run Q and connect it to non-P, but then Q doesn't know any secrets, so the attacker gains nothing.
• If you need to make new connections to other P instances later: Together with the P->Q MRENCLAVE checking and establishing the TLS connection, send P's MRENCLAVE. From this point on Q can verify the new connections based on the MRENCLAVE.

I don't know the exact setup you want to do (so the above may require adjustments), but from my experience every KSS usecase can be replaced with an equivalent non-KSS design (which is often even simpler).

[atsuki-momose]

@mkow: The need for an immutable ID arises from the potential corruption of Q. Suppose an attacker connects to Q, pretending to be the real P. The attacker could exploit an application-level vulnerability to take control of Q. Later, when P connects to Q and sends sensitive data, the data could be leaked to the attacker. To protect P against a potentially vulnerable Q, we need an immutable ID to authenticate Q.

[mkow]

I see, I think it indeed makes sense in this scenario (although, I didn't spend too much time analyzing it).

btw. It's still possible to do the same without KSS though ;) Q could hardcode P's MRENCLAVE, and P could calculate Q's MRENCLAVE dynamically, replacing a placeholder region in Q memory map with P's own MRENCLAVE (P would contain a copy of Q without that placeholder area filled). That's some acrobatics, but may be a viable alternative for you, until we implement KSS.

[atsuki-momose]

@mkow: Dynamically calculating the MR-Enclave in P is indeed among our potential options. However, we hope to avoid this approach for another reason. We also plan to bind an additional runtime ID to the config ID (for a different purpose), which we prefer to keep immutable for the same reason. Therefore, we need an extended ID that can be inserted after SGX signing.

We believe this type of requirement is likely to arise when designing a complex microservice architecture, rather than a simpler one-node delegated computation. We would greatly appreciate it if Gramine could support KSS in the near future.