• John Partridge

Hardware vs. Software for Secure Databases

We are often asked to compare our E2EE approach for secure databases to hardware approaches, specifically CPU enclaves and full-memory encryption (FME). Intel and AMD both have (or have announced) such products. Not surprisingly, we believe an E2EE software design offers much stronger security guarantees (i.e., much lower risk) and at a much lower cost.

First, an observation about hardware-based security generally. The obvious concern is that when security flaws are found as they inevitably will be (e.g., this, this, this, and this), the remediation for patching hardware is more disruptive and costly than for software. Restarting a VM with a new software revision (or, even better, just hot-swapping it) is much less of an operational disruption than taking a whole server down, flashing its CPU with new microcode, and restarting it.

Second, the hardware-based approach requires users to extend a much higher level of trust.

Even if Intel and AMD succeed where no one has succeeded before and make a vulnerability-free CPU, the threat model remains fundamentally different between a “secure” CPU (the hardware approach) and E2EE data (the software approach). In the hardware approach, the client has to establish that the CPU it's talking to can be trusted; it uses a "remote attestation" protocol to do so. At minimum, the user has to trust that the vendor securely implemented the attestation protocol. But the required level of trust actually runs much deeper: the user has to trust the chip vendor to make sure the enclave key they burned into each CPU is never compromised and never shared since it gives access to all the data in the enclave. And let’s not forget the additional side-channel attacks that hardware is exposed to, such as power consumption, electromagnetic waves, sometimes even sound. Some users may be comfortable extending so much trust but not everyone is.

With the E2EE approach, however, the client uses cryptography software that the user controls and can independently review. Users only need to trust themselves. We believe is a powerful advantage and since trust and risk go hand in hand, the less trust you are forced to extend, the less risk you are forced to assume.

For a CISO to sign up for adopting enclaves and FME they will need to get comfortable with:

  1. Integrating the enclave attestation protocol and FME support with their preferred access control system

  2. Revising their applications to use Intel SGX or AMD SEV for all sensitive data

  3. Replacing every CPU that's going to handle sensitive data

  4. Waiting for all the software vendors to release new versions that take advantage of FME

  5. Dealing with the incompatibility issues between different layers in the software stack

  6. Handling a newly discovered vulnerability by choosing between a) running vulnerable servers for days / weeks / months, or b) unscheduled downtime for CPU microcode patches

On the other hand, for a CISO to sign up for an E2EE approach, they will need to get comfortable with:

  1. Integrating the E2EE solution with their preferred key management system

  2. Revising their applications to use E2EE for all sensitive data

At the end of the day, so long as the CPU has access to plaintext data - which it does even with enclaves and FME - it will remain a juicy target for hackers. But with E2EE that juicy target disappears, and a lot of risk along with it.

© 2020 by Aroki Systems, Inc.