listen to this article:
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.
Why Key Protection is the Basic Root of Trust
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 is absolutely crucial.
Ways of Building a Strong Root of Trust & Vulnerabilities
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).
Hardware Root of Trust
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).
Software Root of Trust
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, physical or virtual smartcards, and more.
Choosing Hardware Security Modules as the Root of Trust
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 Virtual Hardware Security Module 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 CORE for Identity Security 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 virtual HSM 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).
Choosing Third Parties Key Management as the 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), and the flexibility in supporting business and operations needs.
To this end, 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 that 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.