Proving enclave functionality

[martijnlammers]

I'm currently trying to research the SGX enclaves specifically and I got a better understanding what actually happens in the CPU/RAM from reading the CCF whitepaper and various internet sources.

I've received the question on whether there is any proof to ensure that everything works as stated a couple of times, to which I personally really didn't have any, other than trusting the source and taking it as it is. There definitely is a valid reason not to be guillible, trusting is great but confirming is better after all.

Are there any tests I can execute locally to prove it's functionality? I had in mind to indentify enclave memory ranges, ensure system calls are being blocked and perhaps read the encrypted data from RAM?

[eddyashton]

A great question! Trusted computation has to ultimately rely on some trusted root. For SGX deployment, that means trusting that an attestation could only be produced on a chip that Intel has correctly built and commissioned. We think that's roughly the minimal viable root of trust, but obviously it's still pretty large!

So in terms of confirming that the CCF node you're talking to is running inside SGX, you should ask for its quote through one of the built-in endpoints, and confirm that you trust that quote (because it is signed/endorsed transitively by an Intel root cert). The idea is that you trust your local network stack, and that produces an encrypted TLS channel, which terminates in a node claiming to run inside SGX, and running a code ID that doesn't leak that TLS termination elsewhere. So if you believe the quote returned is a valid attestation, and valid attestations can only come from secure nodes, then you're talking to a secure node. For the sake of manual inspection, I think there's also some probes you could run on a machine to confirm that it really is running an SGX enclave, though I don't know what they are and then you're still trusting whatever stack runs that probe (it's probably written by Intel!).

I don't recommend trying to confirm that memory is encrypted. If you can ask the SGX driver if it thinks it is managing and encrypting range, that might be useful (and similar to the kind of probe mentioned above). But inspecting the range yourself and trying to distinguish encrypted data from random junk or compressed pages, is hard-to-impossible.

[martijnlammers]

On reconsideration, checking the raw data from RAM actually is very insensible I agree. Your elaboration does really encapsulate the difficulty in manual inspection quite well. I'm worried it will lead to a never ending game of 'I don't trust X' fueled by valid, healthy skepticism. Nonetheless, I'll try my best to attempt the suggested methods as soon as I get the chance.

[martijnlammers]

@eddyashton Is there a simple, innocent and reversible way to tamper with SGX software, something that'll trigger the termination of the TLS channel(s)? Or does that happen to be out of your field of expertise? I mainly want to test the memory sealing and attestation as those are the main functionalities according to the whitepaper.

The memory sealing part I'd like to test out by checking whether system calls are being blocked to the enclave ranges (how I'll end up getting this done I'd still have to figure out) and my second test would be to compare out of the box SGX software with tampered one to test whether SGX can recognize the changes by terminating the startup.

So far I did take a look at the quote of the node, however this consists of a lot of junk I'm not capable of comprehending, apart from mrenclave, which is as far as I understand is the measurement - a hash of the code, initial state, config, stack, heap...- and the node_id, which also is a digest of something I'm not familiar with, but that's not as relevant for now.

[achamayou]

The node_id is a digest of the node's public key: https://microsoft.github.io/CCF/main/governance/common_member_operations.html?highlight=sha%20256#trusting-a-new-node

Intel has resources explaining attestation here: https://www.intel.com/content/www/us/en/developer/tools/software-guard-extensions/attestation-services.html#Elliptic%20Curve%20Digital%20Signature%20Algorithm%20(ECDSA)%20Attestation and the collateral that goes into them, note that CCF only makes use of ECDSA attestation (EPID is more or less deprecated at this point).

mrenclave is indeed the initial measurement of the enclave, and one of our automated end to end tests checks that a node with a quote for an invalid mrenclave is rejected by a network: https://github.com/microsoft/CCF/blob/main/tests/code_update.py#L44. This may be a good starting point for your experiments?

[martijnlammers]

Thank you, for the response @achamayou.
Based on the referenced test code, - correct me if I'm wrong - I could change the C++ shared object that is being placed inside the enclave on a different node, right? (Or just use a different pre-existing one for sake of argument).

This would conclude to a different CodeID / measurement, resulting in a joining node being terminated(?), which would prove an existing network running SGX does not allow for any different (or tampered) code other than the code its already running?

And doing it this way doesn't actually require me to play around with SGX drivers, which is also neat, cause that's probably not something I should be touching.

[achamayou]

@mAlyanak yes, that's right, any change to the code will result in a different measurement. Unless you explicitly tell your network to accept this new code id via governance, nodes running it will be rejected when trying to join.