Redefining Root of Trust For The Cloud Era (Part 1)

In the digital world, cryptographic solutions use encryption keys to secure data at rest, data in use, and data in transit. They are responsible for encrypting and decrypting the data, validating identities by authenticating users and devices, and securing transactions with digital signatures and certificates.

Beneath the complex world of encryption use cases and algorithms lies a simple, fundamental principle: the encryption keys must remain a secret. As soon as an encryption key becomes known, it is worthless.

Now, you can and should encrypt the keys themselves, but then how do you protect those encryption keys? This cycle eventually ends with a root key, which is the most important key in the chain. You need to protect your root keys in such a way that you have the highest level of confidence that they will never be compromised – this means you need a Root of Trust.

To further complicate matters, in more secure environments, you might need multiple root keys, for example for different business units or per applications, to mitigate the damage if any single key is exposed.

For years we have assumed that hardware is less vulnerable to attack than software. The resulting consensus is that for the best possible protection you should store encryption keys on hardware, such as on a Hardware Security Module (HSM). HSMs come in the form of USBs, extension cards, and even whole appliances in your data center. You can even rent an HSM on a public cloud.

Is a hardware Root of Trust still the best solution?

Technology has evolved dramatically over the last few years. Driven by the availability of ephemeral infrastructure in the cloud that provides almost unlimited auto-scaling, compute power has increased exponentially. As a by-product of the trend towards cloud computing, the concept of a single, well-defined security perimeter has been virtually obliterated

The facts on the ground and in the cloud have changed. What does this mean for Root of Trust?

Fragmented key concepts such as Shamir Secret Sharing and Multiparty Computation (MPC) proved that it is possible to work with fragments of keys, rather than with whole keys, but they fell short of the overall requirements. In the case of Shamir, the key is created, fragmented, and then the fragments are combined when the key needs to be used. In other words, at the points of creation and usage, the key exists.

Although MPC creates fragments of keys that do not need to be combined to perform encryption operations, it requires running inefficient sequential operations between parties. In addition, some MPC models required the implementation of new cryptographic primitives and libraries, which is a path best avoided if you want the solution to be easily adopted by practitioners in the industry. And finally, many MPC solutions did not support auto-scaling.

Hardware is no longer invincible

Hardware is not as impenetrable as it used to be. As computing has become more powerful and sophisticated, new hardware attack vectors like Meltdown and Spectre have been discovered that exploit microprocessor vulnerabilities to access data. Even HSMs have been hacked.

Intel’s Software Guard Extensions (SGX) provides an alternative approach that enables a CPU to encrypt data in an enclave, which is an isolated environment inside memory. This effectively puts an HSM in every CPU. Unfortunately, SGX has also fallen victim to multiple attacks.

Auto-scaling is a necessity

Modern computing, both within a public or private cloud, is characterized by efficiency, agility, and scalability. This is primarily enabled by software that provides auto-scaling solutions using ephemeral resources.

HSMs are not designed to auto-scale or to be used with a pay-per-use model. You can’t automatically spin up another HSM to meet peak demand. Consider a major online retailer who needs X HSMs to validate payment transactions on an ongoing basis, and 3X HSMs to do this over a peak period like Black Friday. The retailer would have to maintain all 3X HSMs year-round, even though they are only required for a couple of days. Similarly, if demand suddenly rises beyond the planned capacity, the retailer will not be able to process payments, potentially losing huge amounts of revenue.

Accessibility is everything

A large and growing number of organizations use distributed hybrid environments, with some resources on-premises and others in the public cloud, in some cases even across multiple regions and multiple clouds. When your resources are everywhere, your Root of Trust needs to be accessible from everywhere too.

If you use an HSM on-premises, you need to provide network access and authentication for cloud resources. This means exposing your internal environment to incoming traffic from external public networks.

Solutions that replicate an on-premises HSM to a CloudHSM attempt to resolve this issue, but these are cumbersome to administer, and although they do resolve the issue of providing access to cloud resources, the issue of authenticating these resources remains.

You’re not the exclusive owner of your cloud-based HSM

When you are working with cloud infrastructure, the hardware (and in many cases also the software) is not under your control. This is also true of cloud-based HSMs provided by cloud service providers (CSPs).

You need to look no further than the CLOUD Act to realize that your CSPs have immediate access to your keys and data. This is not theoretical access – this report published by Amazon details the law enforcement data requests with which Amazon complied over a six month period in 2020. It’s not a big jump to imagine an insider at your CSP exploiting this ability to expose your keys.

While CSPs make genuine efforts to secure their hardware under the Shared Responsibility Model, the nature of the beast is that using third-party infrastructure also leaves you vulnerable to supply chain attacks. Consider the attack on SolarWinds and imagine the repercussions of your CSP – and by extension you – falling victim to such a large-scale supply chain attack.

Next-gen Root of Trust requirements

It’s clear that the implementation of Root of Trust as a purely hardware solution deployed in a single location needs to move with the times. Hardware-based Root of Trust was designed for a different world, and it struggles to meet the demands of modern computing.

We need new solutions that overcome the drawbacks of hardware-only solutions, without compromising security. Essentially, we are looking for solutions that provide true Root of Trust-as-a-service, including:

• Auto-scalability and efficiency, with new models of consumption per transaction, just like any other service. The solution needs to seamlessly grow together with your environment.
• Anytime, anywhere access, whether from on-premises or from the cloud, with omni-channel authentication based on modern authentication methods such as AWS-IAM Roles, Azure Identity, OpenID, and so on.
• Exclusive ownership of your encryption keys and signing keys. Especially in non-trusted environments, the solution needs to guarantee that you are the only party that can access your keys, to ensure they are protected from being exposed to anyone, from federal authorities to malicious attackers.
• International security standard certification, such as US NIST FIPS 140.2. FIPS has several levels of strength. For example, in highly regulated environments, hardware is required to achieve certain FIPS levels, so the solution must be able to include hardware in a scalable way.