Intel® SGX for Dummies – Part 3

In my previous two blog posts I provided an overview of the Intel® SGX design objectives.  Without further ado, below is a more detailed description of the remaining design objectives.

As a reminder, I highlighted these eight design objectives for Intel® SGX:

  1. Allow application developers to protect sensitive data from unauthorized access or modification by rogue software running at higher privilege levels.
  2. Enable applications to preserve the confidentiality and integrity of sensitive code and data without disrupting the ability of legitimate system software to schedule and manage the use of platform resources.
  3. Enable consumers of computing devices to retain control of their platforms and the freedom to install and uninstall applications and services as they choose.
  4. Enable the platform to measure an application’s trusted code and produce a signed attestation, rooted in the processor, that includes this measurement and other certification that the code has been correctly initialized in a trustable environment.
  5. Enable the development of trusted applications using familiar tools and processes.
  6. Allow the performance of trusted applications to scale with the capabilities of the underlying application processor.
  7. Enable software vendors to deliver trusted applications and updates at their cadence, using the distribution channels of their choice.
  8. Enable applications to define secure regions of code and data that maintain confidentiality even when an attacker has physical control of the platform and can conduct direct attacks on memory.

In my previous two posts I expanded upon the first five objectives.  In this post, I will review the remaining 3.

Objective 6 – Allow the performance of trusted applications to scale with the capabilities of the underlying application processor.

This objective builds from this idea of minimizing disruption to current development processes.  One of the significant contributors to the software spiral has been the ability of software developers to take full advantage of increasing processor performance.  For maximum utility, trusted applications should not incur significant performance penalties.

Objective 7 – Enable software vendors to deliver trusted applications and updates at their cadence, using the distribution channels of their choice.

If the proposed solution requires independent software vendors (ISVs) to work closely with platform manufacturers in order to pre-provision their applications at platform manufacturing time, or deliver updates only integrated with other platform level firmware and software updates, also it would drastically impede the ability of application providers to deliver innovation.

Objective 8 – Enable applications to define secure regions of code and data that maintain confidentiality even when an attacker has physical control of the platform and can conduct direct attacks on memory.

Given the number of ways that an adversary can choose to attack a platform that he or she has in his or her physical possession, an effective solution must provide protection from many types of hardware attacks.  Researchers at Princeton University demonstrated one such attack:  https://citp.princeton.edu/research/memory/.  Many other attacks are possible using memory bus analyzers and related techniques.

 

 

Well this is it for the design objectives.  I'll be back again when Intel is ready to provide more Intel® SGX information and resources.

For more complete information about compiler optimizations, see our Optimization Notice.

3 comments

Top
AB.'s picture

@Matt,

(1) Can we return data from enclave through some mechanism? (I understand that we can send parameters *to* enclave via RAX but I am thinking can we return processed data too? )

(2) Also is there a way that the data processed in enclave is persistent throughout the lifetime of the process which created the enclave?

What I have in my mind is the following usecase - Use enclave to store sensitive data. Whenever the app wants to use keys, it enters the enclave, use the keys to process some data and leave. And enter again if required.

-Anitha

Matthew H. (Intel)'s picture

@Anitha, good question.

You are correct that we are assuming that only 4K pages can be added to the enclave using EADD.  For a secure solution, we are expecting that, data, code, and any necessary stack and heap memory are placed within the enclave.  If your code were small enough, theoretically you could combine the code, data, stack, and heap together into a 4K page.

But also in case it wasn't clear from the Programming Reference, once a page of linear (application) address space is added to the enclave (a one time operation) the memory can be read or written to from code within the enclave just like regular memory, a byte at a time if you like.

I hope this helps.

Thanks,

-Matt

 

AB.'s picture

Is it possible to store sensitive data in small chunks (around bytes instead of 4k pages) in enclave? My initial impression from reading the SGX manual is that it possibly allows only 4k page usage - but I could be wrong.

Add a Comment

Have a technical question? Visit our forums. Have site or software product issues? Contact support.