Why we chose Intel® SGX to power Runtime Encryption

As more and more organizations migrate towards the cloud, those organizations are getting more and more concerned about the security of the infrastructure backing the cloud and privacy of their data.

For decades, people have been trying to run software with hardened, more secure architectures. Such architectures are generally known as trusted computing, trusted execution environments (TEE), secure enclaves, or protected module architectures (PMA).

Various security technologies are currently available from vendors such as AMD (SKINIT, SME and SEV), Intel (TXT, SGX), ARM (TrustZone) and Microsoft (VBS).

How do you choose which one to use? In this post I’ll explain the main reasons Fortanix® chose Intel® SGX.

When we set out to create the world’s most secure computing platform, we were looking for an architecture that implements complete mediation, enables least privilege, and can significantly reduce the trusted computing base (TCB).

Complete mediation is making sure that all access paths are checked.

Your bank can have a state-of-the art biometric security system at the front door, but that’s not going to stop anyone from climbing through the basement window.

Least privilege is about compartmentalization: making sure that once you’re inside you’re only allowed to see or do things you’re allowed to see or do, and no more. Maybe you can talk to the teller at the counter, but you won’t be allowed into the vault.

Reducing the TCB means less opportunities to do things wrong. Keeping with the bank analogy, it’s easier to secure a small fortified building than it is to secure an entire campus.

As it turns out, most of the commercially available security technologies simply don’t meet these three requirements.

The security properties we’re looking for can be partially accomplished using cryptography. However, crucially, you can’t build a secure system relying only on confidentiality (encryption), you have to also use integrity protection.

This is a well-known principle in cryptographic engineering. Not using integrity protection can be considered a failure in complete mediation: you’re allowing someone else to tamper with your data outside your security boundary, but you’re letting the tampered data right back in during decryption.

This often leads to unexpected results. For example, it’s the lack of integrity protection that has left AMD SME/SEV vulnerable to attack, as described in two papers from last month [source] and 2016 [source].

As explained in our GCN article, current-day computer systems generally have a strictly hierarchical privilege model. Such models can’t properly enable least-privileged designs.

ARM TrustZone, for example, introduces a special secure mode on the processor, but for the most part it is just a strictly more privileged mode of the processor.

This means that all software running in secure mode has blanket access to all other software and data running in both secure and non-secure mode.

For our platform, we need a way to strictly separate programs such that each program individually can be responsible for its own data.

Modern computing infrastructure is extremely complex. Take, for example, the boot process of a typical computer. To get to a running state, you need to go through the BIOS, the bootloader, possibly the hypervisor, the kernel, the graphical shell.

And that’s just what’s happening on the CPU. There might be other components that also have privileged access to system components, such as an embedded processor (Intel ME or AMD PSP), or a baseboard management controller (BMC).

Technologies that require security of a large chunk of the platform and boot chain such as Intel TXT, AMD SKINIT, and Microsoft VBS can’t practically be used in a secure way, because the TCB is so large. This is especially true if you don’t want to trust the platform owner, such as in the cloud.

Related read: How to protect your applications on public and private clouds using Fortanix Runtime Encryption®

Intel® SGX does provide complete mediation by implementing integrity-protected encryption and isolation directly at the processor level.

This also reduces the TCB to just the processor and your application. And it’s that same isolation that allows you to split up your application achieving least privilege.

I hope I have convinced you that Intel® SGX is not only the best choice for our Runtime Encryption® platform, but also currently the only choice.

Of course, we will closely follow upcoming security technologies. In the future, it’s entirely possible that Runtime Encryption® will be made available on other platforms that are sufficiently secure.

Also Read: Never bring a knife to a gunfight!