And proprietary algorithm can be protected using SGX, we can we can carefully choose certain components to place in enclaves to provide assurances that core components are protected. The trusted part must contain the core functions of the algorithm which need to protected from attack.
In future,the SGX2 instructions provide better protection of proprietary code which can be loaded and then protected using the EPCM. These instructions allow for dynamic memory and threading support which is common among proprietary algorithm.
In this presentation Frank McKeen clearly states that the enclave code is NOT protected, as it is loaded unencrypted into memory. But modifying the code of the enclave would change the resulting identity of the enclave. Otherwise, why wouldn't you store any secrets in the enclave before it has been completely loaded?
Have I misunderstood what McKeen said?
Hi Rodolfo, I hope your day is going well.
No you did not misunderstand McKeen's lecture, code and/or data which is linked into the enclave execution image is 'in the clear' and can be analyzed and/or disassembled. Only when the enclave image is loaded via the EADD instructions into Enclave Page Cache (EPC) memory and initialized/sealed with the EINIT instruction is the code/data encrypted by the Memory Encryption Engine (MEE).
If the enclave was built in 'Release' mode, signed with a key which has a trust root linked back to the processor (currently the Intel signing key signature fused into the processor) and has the debug bit cleared in the enclave attribute mask, the ENCLU debug instructions will be disabled. At that point in time the execution of the enclave cannot be traced, modified or analyzed. Of course, at that point in time, the enclave contents also have integrity and confidentiality protections as well.
As you allude to in your post, this is why you must jump through the enclave attestation and quoting hoops in order to get data into an enclave with confidentiality and integrity protections and not just link your secrets into the enclave image. Once an enclave is securely instantiated you are basically dealing with an independent communication's domain which needs to establish a security context with another communication's domain in order to transport data with integrity and confidentiality guarantees into the enclave.
Since the establishment of a security context is always predicated on the notion of the exchange of an authenticated secret between two communication domains the methodology is the same as in standard communications theory, although it tends to get lost in the jargon surrounding SGX. An enclave generates an ephemeral key challenge (ie. Elliptic Curve Diffie-Hellman (ECDH)) which is signed by the enclave. The counter-party accepts and authenticates the ECDH request and generates the shared secret and counter-challenge for the originating enclave. The signed/authenticated ECDH response is returned to the originating enclave, which after authentication of the response, leaves the two communication domains with a shared secret to use for the purposes of protecting and verifying data which is to be transported into the enclave.
We have digested the SGX2 architecture documents and other information which is publically available. The primary focus of those instructions are to implement dynamic memory allocation within an enclave. There are not a lot of details as to how Intel is proposing to do 'dynamic linking' or loading of 'proprietary code' but obviously dynamic memory allocation is a necessary preamble.
With a bit of hand waving one could envision a 'proprietary' code module which is symmetrically encrypted and thus protected outside the context of an enclave. In this model one still needs a 'bootstrap' enclave which has to have access to the encryption material needed to authenticate and decrypt the code/data which is being dynamically loaded. That leaves you back at the need to establish a security context between the 'bootstrap' enclave and the authority/context which has prepared the protected material for ingress into the enclave.
Anusha/Intel can advise the thread if any of this analysis is incorrect.
Thank you for this thorough comment on SGX guarantees.
Just to make it clear, we do agree that SGX does not guarantee confidentiality of enclave code from an attacker that has ring-0 privilege. Is that right?
The enclave memory cannot be read or written from outside the enclave regardless of current privilege level and CPU mode (ring3/user-mode, ring0/kernel-mode, SMM, VMM, or another enclave). The abort page is returned in such conditions.It was an oversight on my part,Intel(R) Software Guard Extensions is not designed to handle side channel attacks or reverse engineering. It is up to the Intel(R) SGX developers to build enclaves that are protected against these types of attack.
Roshan Mehta wrote:
I am looking for a sample code to protect an algorithm say a function mysort(param x, param y) in the context of intel SGX such that outside my enclave mysort() function is encrypted and it only decrypts inside enclave.
How could I achieve this ? Where should I write mysort function i.e. in the enclave project or app project and call through edl interface. How should I encrypt it, where should I keep the key and the logic to decrypt it.
A sample code is much appreciated
Intel is providing some sample code for algorithm confidentiality.
They called it PCLoader.
Here is an article on private algorithms with sgx.