The Basic Root of Trust in Cryptographic Infrastructure

 

In security, a “root of trust” is an element that can be trusted and then used to ensure that the entire system is secure. In cryptography, it can be used to mean many things, but the most basic root of trust is that cryptographic keys are secure and protected from theft.

It’s All About the Keys

All cryptographic operations – encryption, signing, authentication, and authenticated key exchange – rely on secret keys that must remain secret. If the secret key is known to an attacker, then the attacker can do everything that the legitimate parties can do. If the key is a signing key, then it can sign on any message, transaction or document as the legitimate signer; if the key is a decryption key, then it can decrypt everything protected by that key; and if the key is for authentication of a person or device, then it can impersonate that person or device at will. Furthermore, the attacker can use those secrets in the same way as the legitimate user, and thus the attack can be very hard to detect.

Therefore, correctly implemented cryptography can provide very high levels of assurance and security – however, if the secret keys are stolen then the entire house comes crashing down in one fell swoop, and all protection is completely lost. As a result, any deployment of cryptography must carefully consider how the secret keys are stored and protected. A strong method of protection will become the root of trust for the entire system, and thus is absolutely crucial.

Key Storage Solutions

Although this sounds quite simple, it is actually very challenging. In “do it yourself” solutions, software engineers often struggle with the question of where to keep keys. There are many cases where secret keys are found hard-coded into the application code, which is the easiest to deploy with the worst possible security (since everyone has access to the code, basic reverse engineering reveals the secret keys).

Another solution used is to store keys locally on the machine that runs the application. However, this makes them very vulnerable to theft, even if protections like DPAPI are used (first, DPAPI and other obfuscation measures are not perfect; and second, the keys are vulnerable when used in memory and so can be stolen from RAM).

More advanced solutions use secure enclaves like Intel SGX, but software side channel attacks on SGX and other similar solutions are extremely effective at stealing cryptographic keys, and so these are also very weak roots of trust that cannot really be trusted.

Due to the complexity of building a strong root of trust, enterprises typically do not allow “do it yourself” solutions by their software engineers, and purchase secure key stores. These can be in the form of physical HSMs (Hardware Security Modules), virtual HSMs (like the Unbound vHSM®), physical or virtual smartcards, and more.

 

Factors in Choosing Key Storage Platforms

When choosing such a solution, it is crucial to build a clear threat model and to ensure that the solution answers those threats. For example, the security of HSMs is primarily in their hardware protections; this makes a lot of sense when the HSM can be physically accessed by an attacker. However, if the machine is installed in a secure data center, the main threat is that of software attacks and the question is then whether HSMs are the optimal solution in this case.

On the one hand, HSMs have a limited API making them harder to attack. On the other hand, the software security of HSMs is not their focus, the software stack is typically not the latest, and powerful software attacks on HSMs have actually been demonstrated.

The Unbound vHSM® achieves trust through a different paradigm of separation; using secure multiparty computation, secret keys are never whole at any time, and are shared between two servers so that each piece reveals nothing about the key. Likewise, Unbound’s CoT solution shares keys between endpoints (like mobile devices) and servers to achieve a virtual smartcard/token. In both of these solutions, a high level of security is achieved by making it hard for an attacker to simultaneously breach both locations. For example, in the vHSM® solution, different administrator credentials can be used for the machines, they can be placed in different environments, and so on (all depending on the organization’s threat model).

Factors in Key Management for Root of Trust

Other factors that are important to consider when choosing a root of trust solution include:

  • The ability to remotely administer and deploy the solutions (always important, but even more so today)
  • The flexibility in supporting business and operations needs.

Possibilities include utilizing cloud key management systems or vaults, but these raise the question as to whether an organization wishes to entrust its most sensitive secrets to a third party.

The question isn’t whether a cloud provider would maliciously steal an organization’s secrets (that would be suicide) — but rather the impact of a rogue administrator, silent subpoenas, and being caught up in a mega-breach which doesn’t necessarily target your organization. In addition, there is always the question of what remains after deletion, and whether an organization can really gain complete control over their keys once they have handed them over.

 

Rising to the Challenge

Unfortunately, there are no easy answers to the question of how to build a strong root of trust for an organization’s cryptographic infrastructure. In some cases, a combination of solutions is even needed. Despite this, it is imperative that organizations rise to the challenge and ensure that the cryptographic skyscraper that they build stands on strong foundations.

Prof. Yehuda Lindell

Prof. Yehuda Lindell

Yehuda Lindell is a professor of Computer Science at Bar-Ilan University, and a cryptographer with expertise in secure multiparty computation (MPC) that forms the technological core of Unbound’s solutions. Yehuda served as the Chief Scientist of Unbound from its inception until February 2019, when he took over the role as CEO.

Subscribe to BLOG

shares