Secure Enclave Root of Trust Generation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing cryptographic systems without Hardware Security Modules (HSMs) face challenges in securely generating and sharing Root of Trust (ROT) across nodes, as they rely on password encryption and are vulnerable to attacks when the operating system or root user is compromised.
Innovation Solution
The implementation of a secure enclave in each node of a clustered cryptosystem, which generates and shares a Root of Trust (ROT) using multi-party secret sharing. This involves attesting to a remote server, receiving a key splitter logic, and partitioning the ROT into multiple shares, ensuring secure communication and replication across all nodes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the Root of Trust is stored in system memory for use by applications, then the ROT is accessible and functional, but the ROT is exposed in plain text and vulnerable to compromise if the application is targeted
Solution Approach 1:
The Root of Trust is segmented into multiple key shares using secret sharing schemes. Each node in the cluster holds only a portion of the ROT, and the complete ROT can be reconstructed only when a threshold number of nodes collaborate. This segmentation ensures that even if one node is compromised, the attacker cannot obtain the full ROT.
Solution Approach 2:
A secure enclave acts as an intermediary between the application and the Root of Trust. The enclave securely holds the key shares and performs cryptographic operations without exposing the ROT to the application or operating system. This intermediary layer protects the ROT from attacks while maintaining its functionality.
2Adaptability or versatility
If the same Root of Trust is replicated across multiple nodes, then cryptographic operations can be performed in other components of the ecosystem, but the ROT must be copied into system memory which exposes it to attacks
Solution Approach 1:
Instead of replicating the complete ROT across nodes, the system segments the ROT into key shares and distributes them to different nodes. Each node can participate in cryptographic operations by contributing its share, enabling versatility without requiring full ROT replication in system memory.
Solution Approach 2:
The patent replaces the mechanical copying of ROT into system memory with a cryptographic reconstruction process. Nodes contribute their key shares through secure communication channels, and the ROT is reconstructed temporarily in the secure enclave for cryptographic operations, then destroyed. This substitution eliminates the need for persistent ROT storage in vulnerable memory locations.
3Reliability
If password encryption is used to protect the Root of Trust, then the ROT is encrypted at rest, but the password also resides in the same system creating a security concern
Solution Approach 1:
The system extracts the password dependency from the security architecture by using the secure enclave's hardware-based key management. The enclave generates and manages encryption keys without requiring external passwords, eliminating the vulnerability of storing passwords in the same system while maintaining encryption protection.
Solution Approach 2:
The secure enclave serves as an intermediary that manages cryptographic keys without exposing them to the operating system or requiring password protection. The enclave's hardware security perimeter isolates key management operations from the vulnerable software environment, eliminating the need for password-based protection while maintaining strong encryption.
Data Source
Figure 1A~1B
Figure 2
Figure 3A
AI summary
Provided is a system (100) for securely generating, and multi-party sharing of, a Root of Trust (RoT) in a clustered cryptosystem (110) by way of a secure enclave (55) within each node (50). It improves cluster loading crypto command performance such as digital signing and signature verification without use of an HSM. Each node attests to a Remote Server (40), submits a join request, and receives obfuscated key splitter logic. A different Remote Server provides a deobfuscator code to the node. Nodes share attestation information amongst themselves for joining the cluster (110). A primary node generates the RoT and splits it into partitions, which are then shared with other nodes. Each node thereafter regenerates the same RoT. Communications between secure enclaves are secured over a TLS channel. Other embodiments are disclosed.