Author: bing.zhu@intel.com
Background
Typically, a Key Management System, or KMS, is backed with a Hardware Security Module, or HSM. However, the existing hardware HSM solution is very expensive and complex to manage. Cloud HSM solutions could mitigate the problems but still depend on the dedicated external hardware devices.
Intel® Software Guard Extensions (Intel® SGX) offers hardware-based memory encryption that isolates and encrypts specific application code and data in memory. Such memory is called an enclave. User-level code is allowed to allocate enclaves to protect its secrets from other processes even they are running at higher privilege levels, like kernel, hypervisor, and BIOS firmware.
The eHSM is targeted to provide traditional HSM-equivalent crypto cryptographic functionalities (including key generation, management, use etc.) inside the Intel® SGX enclave.
The eHSM-KMS is a Key Management System backed with the eHSM. And compared with the traditional solution, it is an open-source solution with low cost, high scalability, and high availability, and can be easily deployed to cloud. It supports the public Representational State Transfer (REST) cryptographic APIs to be fully compatible with the commercial cloud KMS interfaces.
The source code of the project is available in GitHub: https://github.com/intel/ehsm
Overview of the eHSM-KMS
This diagram depicts the high-level architecture of the eHSM-KMS,
APPID and APIKey Enrollment
Since only the user with valid APPID and APIKey could request the public cryptographic RESTful APIs, eHSM-KMS provides a new Enroll APP, which is used to retrieve the APPID and APIKey from the eHSM-core enclave. The APPID and APIKey are retrieved via the remote secure channel (based on the Intel® SGX remote attestation).
Introduction to Keys used in eHSM-KMS
eHSM-KMS will provide different kinds of keys, but none of them will be exposed outside of the SGX enclave.
- DK (DomainKey) an AES key used to protect/wrap the CMKs in a domain (region). It must be securely distributed/provisioned across all Intel® SGX-capable machines or nodes in a domain.
- CMK (Customer Master Key) eHSM-KMS supports both symmetric keys and asymmetric keys. The symmetric CMK primarily used to wrap the DataKey, but can be used to encrypt an arbitrary small set of bytes data. The asymmetric CMK is primarily used to sign/verify or asymmetric encrypt/decrypt data, not for the DataKey.
- DataKey a symmetric key with random size of bytes. Users will use the plaintext of the DataKey to encrypt local data without using KMS and store the encrypted data together with the ciphertext of the DataKey. The plaintext of DataKey should be cleared from memory as soon as possible after use. When the user wants to obtain the plaintext of DataKey again, it needs to call Decrypt with the CMK to get the plaintext of DataKey.
Domain and Worker Nodes
All the Intel® SGX worker nodes (Intel® SGX-capable platforms) can equivalently & seamlessly provide KMS services for users. eHSM-core Enclave in each node should be provisioned with the capability of retrieving the cleartext of DomainKey (DomainKey sharing across all the nodes in one domain).
Each node may be offline/down and new node may be joined to or removed from a specific domain.
DomainKey Provisioning
The following diagram illustrates the secure provisioning flow using the eHSM-KMS protocol to provision the DomainKey to an Intel® SGX-backed eHSM-core Enclave.
Two major components are introduced in this provisioning system: eHSM-dkeyserver, which is deployed on a centralized node (could be an HSM-equipped platform or an Intel® SGX-capable platform); and eHSM-dkeycache, which is deployed on the SGX node worker node together with eHSM-core enclave (only need one instance for each node).
- eHSM-dkeyserver runs as a TCP/IP socket server, and it’s responsible for generating DK and protecting the DK in the HSM or enclave, and provisioning it to each Intel® SGX node in this domain.
- eHSM-dkeycache runs as a proxy agent in each Intel® SGX node, and it is responsible for retrieving the DK from the ehsm-dkeyserver via remote secure channel. The DK is then distributed to each ehsm-core instance via local secure channel.
Whenever a new node is joined or refreshed into the domain, the eHSM-dkeycache service will try to connect the eHSM-dkeyserver to retrieve the DK and distribute it to each eHSM-core instance via the secure channel.
Conclusion
The eHSM-KMS supports most of the mainstream key management service interfaces, and all cryptographic keys are protected by Intel SGX hardware technology. By deploying the domain key distribution service, it can provide the highly scalable and distributed key management services across different Intel® SGX worker nodes.
This system has already been integrated with the BigDL project to provide key management functionality. Customers could deploy the total solution on their own private cloud or deploy it on a public cloud like Alibaba Cloud ECS Intel® SGX instances.
Acknowledgement
This post reflects the work of many people at Intel, including Shaopu Yan, Yang Huang, Jingdong Lu, Bing Zhu, Kai Wang, Hanyu Long, Zhenlong Ji and our partner Alibaba Cloud Security team.
Contact bing.zhu@intel.com for more information.