Private code launch for enclaves

[David William Kohlbrenner]

Hi all,

This was brought up in some of our offline discussions, and while we don't have it planned for near-term support, we're interested in other's thoughts.

The objective is to enable a remote client to easily launch an enclave without the code being exposed to the platform operator. (Confidentiality, not just integrity)

We've put some of our ideas/proposals below, they are in no way final.

Thoughts?

Mechanisms are in rough order of complexity and SM involvement

* Mechanism 1

 + allow loading code pages (the 'exec' model)

   - Enclave ships with/receives over secure channel an encrypted binary

   - Enclave creates new RW pages (using syscall to runtime)

   - Decrypts code into new pages

   - Marks pages RX (syscall to runtime)

 + Benefits:

   - Trivially implemented with minor changes to eyrie-rt

 + Cons:

   - SM is not involved in the creation of a (logically) distinct enclave

   - All authenticity guarantees are done by loading enclave

   - Loading enclave is now trusted for lifetime of the app

   - Loading enclave can only load 1 secure code program

* Mechanism 2a

 + Allow enclaves to launch other enclaves (the ‘fork + exec’ model)

   - Enclave ships with/receives over secure channel an encrypted binary

   - Enclave creates new RW pages (using syscall to runtime)

   - Decrypts code into new pages

   - Enclave requests creation of a new enclave (SM)

   - New enclave is launched, access to memory is removed from launcher

* Mechanism 2b

 + Allow enclaves to launch other encrypted enclaves (‘fork + exec ++’ model)

   - Enclave ships with/receives over secure channel an encrypted binary

   - Enclave creates new RW pages (using syscall to runtime)

   - Enclave loads still-encrypted code pages

   - Enclave requests creation of a new enclave (SM), and hands off packaged key to SM

   - New enclave is launched and decrypted by SM (or verified stub), access to memory is removed from launcher

* Mechanism 3

 + Allow encrypted enclave launch (‘magic exec’ model)

   - Host/launcher enclave obtains a special attestation report with an SM pubkey

   - Client sends an encrypted blob + SM pubkey encrypted decryption key to host

   - Host loads encrypted blob + encrypted key to SM

   - SM creates enclave as normal

   - SM decrypts key, decrypts blob (or verified stub does it) in enclave

[Kuniyasu Suzaki]

This article reminds me of the TEEP (Trusted Execution Environment Provisioning) protocol discussed at IETF now. The TEEP is a remote management protocol of Trusted Applications (TAs).

https://github.com/ietf-teep/teep-protocol

 

The launching mechanism is essential for TEEP. The comparison of launching mechanisms is interesting. I think some ideas are already implemented.

 

Mechanism 2a resembles the Secure Storage TA of OP-TEE.

https://optee.readthedocs.io/en/latest/architecture/trusted_applications.html#secure-storage-ta

 

Mechanism 3 resembles the Intel PCL (Protected Code Loader)

https://github.com/intel/linux-sgx/tree/master/SampleCode/SampleEnclavePCL

 

I want to evaluate the proposed mechanism with the existing mechanism.

Especially, the effects for Secure Monitor and runtime.

2019年3月19日火曜日 4時40分23秒 UTC+9 David William Kohlbrenner:

[Dayeol Lee]

Hi Kuniyasu,

Sounds good!

I think the integrity of the binary can be protected with an initial measurement as well.

Mechanism 2 (fork-based) can reuse the create enclave SBI, and mechanism 3 will require a new SBI.

I personally prefer 1 and 2a than 2b and 3 because they require less SM modification.

Any thoughts?

Thanks,

Dayeol

--
You received this message because you are subscribed to the Google Groups "Keystone Enclave Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keystone-enclave-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keystone-enclave-forum/505a22d5-e981-4785-a4ce-d9862bc28a45%40googlegroups.com.

[Kuniyasu Suzaki]

Hello Dayeol and David,

 

I am not sure how to manage the decrypt key.

Mechanism1 and 2a seems that Runtime get a decrypt key for an encrypted binary, but Mechanism2b and 3 seems that Secure Monitor get a decrypt key.

I am not sure how to get the key.

Is the key common for a Secure Monitor or Runtime? Or is the key different for each device?

Which is the final key manager on each mechanism?

I think it affects the difficulty of SM modification.

Kuniyasu Suzaki

2020年3月27日金曜日 2時56分43秒 UTC+9 Dayeol Lee:

To unsubscribe from this group and stop receiving emails from it, send an email to keystone-enclave-forum+unsub...@googlegroups.com.