HSM vs Intel SGX
When evaluating secure execution environments for custody, two common options are HSM (Hardware Security Modules) and Intel SGX (Software Guard Extensions). While both aim to protect sensitive operations, they differ fundamentally in architecture, threat surface, and assurance levels.
Intel SGX (Software Guard Extensions)
Intel SGX provides a Trusted Execution Environment (TEE) inside a general-purpose CPU. It separates trusted enclaves from untrusted host code, allowing sensitive logic to run in a protected memory region. However, the security of enclaves depends heavily on the CPU vendor and firmware supply chain, and vulnerabilities have been repeatedly demonstrated in public research.
- Shared hardware between trusted and untrusted zones
- Multiple high-profile attacks (e.g., sgx.fail) exploiting side-channels and speculative execution
- Relies on the CPU vendor for attestation infrastructure
- Still requires an HSM or other secure device for durable key storage and code signing
- Large attack surface due to integration with full CPU, OS, and driver stacks
- Difficult to audit because enclave code executes alongside complex general-purpose systems
SGX is powerful for certain workloads, but its shared environment and history of side-channel attacks limit its suitability as a root of trust for institutional-grade custody.
Hardware Security Module (HSM)
HSMs, in contrast, are dedicated cryptographic appliances purpose-built to generate, store, and use private keys inside a tamper-resistant boundary.
- Dedicated hardware with bank-grade security used for decades in payments and finance
- Only loads the minimal wallet-specific code (Vault) into the secure execution environment
- Smaller attack surface (Vault), easier to review and audit compared to full CPU/OS environments
- Integrated True Random Number Generator (TRNG) and standards-approved DRBGs
- Tamper-resistant key storage with zeroization on tamper events
- Strict access control with PKCS#11 interface
- Certified under FIPS 140-2/3 Level 3 for cryptographic assurance
- Built-in support for segregated roles and multi-factor authentication (USB tokens, PIN pads)
- Physical and logical protections hardened specifically against key exfiltration
Because HSMs are standalone devices with narrow functionality, they reduce complexity and remove reliance on untrusted host environments. They enforce cryptographic boundaries at the hardware level and are easier to certify, monitor, and operate in regulated financial environments.
Comparison Summary
| Aspect | Intel SGX | HSM |
|---|---|---|
| Architecture | TEE inside general-purpose CPU | Dedicated cryptographic appliance |
| Attack Surface | Large (CPU, OS, drivers, side-channels) | Minimal, purpose-built firmware |
| Vulnerabilities | Multiple public attacks (sgx.fail, Foreshadow, etc.) | Rare; mitigated with tamper-proofing and certifications |
| Key Storage | Not durable; requires external secure storage | Native tamper-resistant storage |
| Randomness | Depends on CPU instructions (RDRAND) | Hardware TRNG + FIPS-approved DRBG |
| Auditability | Complex, difficult to review | Narrow codebase, easier to audit |
| Certification | No equivalent to FIPS 140-3 L3 | FIPS 140-3, PCI HSM, Common Criteria |
| Role Separation | Software-based | Hardware-enforced with USB tokens + PIN pads |
| Use in Custody | Needs HSM for keys | Can stand alone as root of trust |
Intel SGX offers enclave-based isolation but remains vulnerable to side-channel attacks and still depends on HSMs for durable key storage. HSMs provide a hardened, certifiable, and auditable platform specifically designed to protect cryptographic material. For institutional custody, HSMs remain the gold standard as the root of trust, while TEEs like SGX are better suited for complementary tasks, not for custody keys.