Confidential coding (with hardware Secure Enclaves)

In a corporate or government setting, there are cases where your algorithms and data better stay confidential. Hardware secure enclaves are a vendor-specific way to enforce this, and notably include :

• Intel® SGX (Software Guard Extensions);
• Apple® Secure Enclave.

There are many interpretations to “confidential”, though, hence why we better mark the field now: what are hardware secure enclaves able to do?

What they do:

• make sure the data-algorithm jumps & variables- stored in memory is not readable, either by introspection, debugging and exploits (buffer overflow…). Even if an attacker controlled a kernel-space driver, which would let him dump the whole system RAM, he would not be able to “see” the data as it is stored in a specific CPU area;
• encrypt binary objects with a security mechanism, in general a signed key pair, which the hardware is able to validate;
• prevent binary objects from tampering: security keys are stored in-CPU with a hash of these.

What they do not do:

• prevent binary objects from leaking;
• prevent security keys form leaking;
• prevent human stupidity.

Typical example: An application (test_app) requests a security password from an encrypted shared library (Enclave.so/dylib). While it is being computed, it is not readable in-memory by any means, as it is in a memory area controlled by the Secure Enclave. The application only receives the final, computed, form of the password.

test_app calls “get_secure_password()” from Enclave.so, which unlocks Secure Enclave with a security key, computes the password in a protected area of memory, and returns it to test_app

The following hardware implementations will be of interest to us:

1. Intel® SGX:

• Hardware: Intel “Skylake” CPUs and above
• Randomizer: Intel Secure Key Technology (RDRAND)
• Limitations: 64 to 128 MB of data
• SDK: proprietary
• Documentation: extensive
• Compatible OSes: Windows®, Linux (Ubuntu 16–20, RHEL/CentOS 7–8, Fedora 31, NixOS)

2. Apple® Secure Enclave:

• Hardware: MacBook Pro (w. T1 chip), iMac (w. T2 chip), iPhone 5s+, iPad Air+
• Randomizer: True Random Number Generator (TRNG)
• Limitations: cannot store random data (need to manually encrypt/decrypt data in-program), language is Objective-C or Swift
• SDK: proprietary (included in Xcode)
• Documentation: sparse
• Compatible OSes: macOS “Catalina” 10.15+, iOS 13.0+

One can notice that, if Apple computers may be equipped with compatible CPUs, they are unable to use SGX as the feature is hard-disabled in their BIOSes. Probably the reason Intel does not provide macOS versions of its SDK :-).

As of existing implementation: the Phala blockchain, based upon Substrate, takes advantage of Intel SGX to provide confidential Smart Contracts.

In the following days, we will review both technologies in the form of tutorials.
Here is the first one : [HowTo] Coding with Intel® SGX on RHEL/CentOS 8 (1)