9. August 2022

[dimakuv]

(Please note that the meetings happen on Tuesdays from now on!)

Agenda

(please write your proposed agenda items in comments under this discussion)

• Vijay: Local Attestation TLS (LA-TLS) design, such that two independent Gramine instances can securely communicate via the UNIX Domain socket. Vijay thinks that MRSIGNER-based verification of SGX reports is enough.
• Borys: RFC: Add POSIX shared untrusted memory support #757 @llly started implementing it, but we must first reach consensus on the approach

[vijaydhanraj]

Meeting Notes Aug 9th 2022:

1. Review Local Attestation (LA-TLS) between Enclaves:

Vijay reviewed the high-level design of enabling attestation between enclaves running on the same hardware using MRsigner. The goal was to,

• Local attestation between two independent enclaves so that they can share secrets.
• Enabling seamless socket connection (named pipes) between two independent enclaves running on the same hardware.

1. Attestation with MRsigner using a trusted third party should be fine.

2. For mutual attestation, MRenclave cannot be used as it will result in a circular dependency. And Borys feels that even with MAGE approach we may need all images or at least hashes of the application. For mutual attestation with MRsigner both Michal and Borys feel we may need a unique ID for each enclave that can be cross-verified as a malicious host could swap enclaves with the same MRsigner exposing more attack surfaces. If this issue can be solved, then implementing seamless socket communication (named pipes) should be possible.

Mona and Vijay brought up that if we establish a DH session, the host may not be able to swap the enclaves.

Borys suggested that the DH session can prevent swapping of the enclaves by the host during runtime but if the host swapped the enclave even before the DH key exchange occurred then the issue is still there.

Example from Borys that thwarts MRsigner approach:
We have three applications, say a SQL server, PHP and nginx, and all of them are signed with the same MRsigner. Basically, a cluster that serves a http server. The malicious host now spawns another SQL server instead of PHP. Now nginx server starts to talk to SQL expecting it to be PHP and local attestation may even succeed as they all have the same MRsigner.

Mostly likely it will blow up due to protocol error but if this mismatch doesn't end in exit but continues then this could lead to some other site and could compromise the security of the system.

So, this necessitates an unique ID that needs to be set for each enclave so that the other party/enclave can know which unique ID to expect during local attestation.

Mona: Can we have something in between to address the unique ID issue or some documentation with gaps using MRsigner approach?
AR: Vijay and Mona will further discuss and get back.

2. Shared untrusted memory support:

Regarding this RFC #757 and PR #827, @llly will present the design in the next Gramine community meeting before proceeding with further implementation.

[boryspoplawski]

And Borys feels that even with MAGE approach we may need all images or at least hashes of the application.

It's not how I "feel" and not that "we may need", it's literally how that framework works: Since this step requires all specific parts for generating the common part, MAGE does not scale well for a system with enclaves developed by different parties - you need all enclaves to build the system/cluster of enclaves that will be able to mutually attest.

So, this necessitates an unique ID that needs to be set for each enclave so that the other party/enclave can know which unique ID to expect during local attestation.
Mona: Can we have something in between to address the unique ID issue or some documentation with gaps using MRsigner approach?

This problem is solvable. The issue is that the solution might be cumbersome and most likely will require extensive configuration from end users (enclave/manifest developers), so it's not clear that the gains (ability to split few processes between different Gramine instances all being able to communicate) outweighs the complexity of implementing and using such approach.

[vijaydhanraj]

MAGE does not scale well for a system with enclaves developed by different parties

Clarification: But this is not the case here. It is the same party and so the proposal to use MRsigner. Maybe for different parties, we can say we don't support mutual attestation.

This problem is solvable. The issue is that the solution might be cumbersome and most likely will require extensive configuration from end users (enclave/manifest developers), so it's not clear that the gains (ability to split few processes between different Gramine instances all being able to communicate) outweighs the complexity of implementing and using such approach

There are already two cases requiring the socket communication using named pipes. Folks also prefer named pipes as it is more performant rather than sockets communicating over a network. It would be nice to create PoC at least and I can volunteer for it once we finalize a high-level design to solve this issue.

[boryspoplawski]

Clarification: But this is not the case here. It is the same party and so the proposal to use MRsigner. Maybe for different parties, we can say we don't support mutual attestation.

No, this was just a corollary from the fact that this framework requires all enclave specific parts at build time. Just read the first part of the sentence (or the whole paper, it's of course explained there).

There are already two cases requiring the socket communication using named pipes.

I'm not aware of any. All I've heard was solvable if you put all processes in one Gramine instance, it was just a matter of preference from users - they didn't want to do that. So it was more like "we want this feature because it's easier for us" than "we need this otherwise we cannot run our app in Gramine".

using named pipes.

Actually we talked about UNIX domain sockets (both named and unnamed), not named pipes (FIFOs).

Folks also prefer named pipes as it is more performant rather than sockets communicating over a network.

This is most likely not the case in Gramine, given that each read/write needs to copy data and perform enclave exit+entry.

[vijaydhanraj]

Clarification: But this is not the case here. It is the same party and so the proposal to use MRsigner. Maybe for different parties, we can say we don't support mutual attestation

No, this was just a corollary from the fact that this framework requires all enclave specific parts at build time. Just read the first part of the sentence (or the whole paper, it's of course explained there).

What I meant is for enclaves created by the same MRsigner we could either share MRenclave or any other unique ID which could be later verified. This cannot be done with different/unknown parties.
Update: Referring to a whitelist that can be shared between the enclaves signed by the same MRsigner.

Actually we talked about UNIX domain sockets (both named and unnamed), not named pipes (FIFOs).

Yes, correct, I have used named pipes and Unix domain sockets interchangeably. I will stick to referencing as Unix domain sockets.

This is most likely not the case in Gramine, given that each read/write needs to copy data and perform enclave exit+entry.

True, but in case of TCP/IP socket, won't it be even worse? Because in addition to enclave exit + entry, the packets may also have routing overheads or is this insignificant? Meaning both TCP/IP based sockets and Unix domain sockets have the same performance in Gramine. Also, we must specify the IP/port in the manifest.

. So it was more like "we want this feature because it's easier for us" than "we need this otherwise we cannot run our app in Gramine".

And yes, agree that will make it easier for the user.

[monavij]

Please move this discussion to the issue 814.