In our recent article "Are your cryptographic keys truly safe? Root of Trust redefined for the cloud era" featured in HelpNetSecurity, we discussed how the objective of a Hardware Security Module (HSM) is to ensure that the keys it stores cannot be compromised. When the safety of the keys in an HSM can be assured, it can function as a Root of Trust.
We explored the challenges of using traditional, purely hardware Root of Trust solutions in modern, cloud-hosted computing environments, and outlined the features and functionality that would present the ideal next gen Root of Trust solution.
As a reminder, first and foremost the ideal solution must guarantee that an organization maintains exclusive ownership of its keys to protect them from being exposed to unauthorized parties, from federal authorities to malicious attackers. Secondly, the solution needs to be provided as a service, with all that entails. It must be cloud-native so that it is globally available and can be auto-scaled to meet sudden demand. Finally, the solution must meet international and regional security standards.
Back to the drawing board
It is evident that existing solutions focus on protecting the “root” (or master) key. However, a key that exists somewhere can eventually be compromised. In the search for an alternative, the Akeyless team proposed a paradigm shift:
What if there is no encryption key in the first place? And if so, how do you use a key without having a key?
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.
Fresh new angle
To overcome these shortfalls, the Akeyless team proposed and patented a new model called Akeyless Distributed Fragments Cryptography™ (Akeyless DFC™) in which keys are never created as a whole and do not need to be combined in order to use the key for encryption, decryption, and signing.
With Akeyless DFC™, fragments are independently generated, in parallel, across different regions and on different cloud providers. The fragments are completely isolated from one another, to the point that they are not even aware that other fragments exist.
Because the fragments exist in isolation and there is no dependency between them, cryptographic actions can be performed in parallel, rather than sequentially. An Akeyless Client, such as an SDK placed within the customer environment, performs the encryption using a challenge and response process against the different fragments to obtain the mathematical material required to encrypt the data.
The bottom line: You will NEVER find the key in memory. Anywhere. It never exists as a whole. Not when it is created, not when it is stored, and not when it is used.
Fundamental to this methodology is the fact that it provides full fragment isolation while still maintaining the ability to perform refresh actions, making it extremely difficult to obtain all fragments of a key.
Refresh actions provide a strong layer of security by changing the mathematical values of the fragments without breaking their overall sum. As the fragments keep changing, a malicious attacker attempting to get their hands on a key would need to attack all the locations that hold the different fragments at the same time in a simultaneous attack vector.
Exclusive key ownership
One of the main requirements from a next gen Root of Trust solution is that the organizations using it can be absolutely certain that their keys are always theirs, even when another party manages the key storage infrastructure.
The Akeyless DFC™ model supports this exact capability. In addition to the key fragments created and stored in the Akeyless environment, customers can create their own key fragment which is stored in their environment, to which we do not have access. Akeyless leverages standard cryptography rules which dictate that even someone holding 99% of the fragments still holds zero percent of the key. Therefore, without the customer key fragment (the elusive 1%), it is impossible to ever hold the key.
From an operational perspective, the customer fragment is only a single fragment of the key, and can therefore be backed up just like any other data to ensure it is never lost. Further, a single customer fragment can be part of thousands of encryption keys, meaning that choosing to use a customer fragment does not increase the administrative load.
Going back to the scenario above, the SDK placed within the customer environment performs the encryption using a challenge and response process against the different fragments, including the local customer key fragment to which Akeyless does not have access.
Next Gen Root of Trust: Akeyless Vault Platform
Harnessing the power of Akeyless DFC™, the Akeyless Vault Platform offers a FIPS-validated virtual HSM, provided as-a-Service (SaaS), with automatic and infinite scaling, global availability, and exclusive key ownership guaranteed.
Global coverage, infinite scalability, high availability
The Akeyless Vault Platform was designed using cloud-native architecture on top of several cloud providers, with the support of automatic scaling and high availability. Its scalability is limited only by the available cloud resources, giving it the potential to create an infinite number of keys and handle an infinite number of encryption, decryption, and signing transactions.
In cases of high traffic, high volume encryption, the platform also provides caching mechanisms to prevent latency issues.
As a SaaS solution, the platform can be accessed from wherever your resources are in the world, from on-premise to cloud, across multiple regions. It is also agnostic to the identity type of your resources, so you can easily use it for any of your environments, whether legacy, hybrid, or across multi-cloud architectures. For seamless connectivity, Akeyless supports multiple authentication methods, including cloud identities (CSP IAM) such as AWS IAM, Azure AD, and GCP, as well as a unique on-prem Akeyless Universal Identity™.
CLOUD Act and supply chain attack protection
As shown above, with Akeyless DFC™, your encryption keys never exist as a whole, and can therefore not be compromised, even though the key management infrastructure is not under your control.
Neither Akeyless nor any of the CSPs on which the key fragments are stored can decrypt your encrypted data. This provides additional protection against unauthorized access to your data, helping you remain compliant with industry regulations and privacy mandates. Likewise, it mitigates the threat from supply chain attacks.
While most companies are required to provide data requested by federal authorities as per the CLOUD Act, when your data is protected using Akeyless DFC™, you can be confident that your data cannot be handed over without your knowledge. Any request for information will have to be fulfilled by you, rather than to your cloud provider.
Certified by international security standards
While Akeyless DFC™ is innovative, it is important to emphasize that the technology is based on standard cryptography, with standard keys and algorithms such as RSA and AES. As a result, Akeyless DFC™ is US NIST FIPS 140-2 certified, and the entire platform has completed a SOC2-Type II attestation and is ISO 27001 certified.
The future is now
Built on-top of our unique Root of Trust technology, is the Akeyless Vault Platform. The platform serves as a unified Secrets Orchestration solution to manage and protect all types of secrets, including credentials, tokens, api-keys, certificates, and encryption keys, with the strong security of a virtual HSM. This allows all of your secrets, regardless of location, to be centrally managed from a single solution.