The Entrust nShield Connect HSM

The Entrust nShield Connect and PQC Agility (Deep Dive)

The nShield Connect is Entrust’s flagship network-attached HSM, widely used in enterprise environments for key management, encryption, and digital signing. It’s FIPS 140-2 Level 3 certified (with FIPS 140-3 in progress as of 2025) and supports a client-server architecture where multiple systems can access its cryptographic services over a network.

Historically optimized for classical algorithms (RSA, ECDSA, AES), Entrust has been adapting it for PQC in response to quantum threats, particularly since NIST’s PQC standardization process began yielding finalists in 2017 and winners in 2024 (ML-KEM, ML-DSA, etc.).

Entrust’s PQC strategy hinges on two pillars: firmware updates to introduce new algorithm support and the CodeSafe SDK for custom implementations, aiming to transition legacy systems to quantum-resistant cryptography like ML-DSA (lattice-based signing) and ML-KEM (lattice-based key encapsulation).

How nShield Connect Supports PQC Algorithms

1. Firmware Updates: Baseline PQC Support

  • Mechanism: Entrust delivers PQC algorithm support through firmware upgrades to the nShield Connect. These updates embed standardized algorithms (e.g., ML-DSA, ML-KEM) into the HSM’s cryptographic engine, making them available via standard APIs like PKCS#11, CNG, and JCE.
  • Current Status: As of March 03, 2025, Entrust has rolled out firmware supporting NIST’s PQC winners—ML-KEM (Kyber) and ML-DSA (Dilithium)—following their standardization in August 2024 (FIPS 203, 204). Earlier beta firmware included experimental support for PQC candidates (e.g., CRYSTALS-Dilithium, Falcon) since 2022, tested in their Post-Quantum Labs.
  • Process: Users upgrade firmware via Entrust’s Security World management software, which maintains key continuity across reboots. The HSM then exposes ML-DSA for signing/verification and ML-KEM for key encapsulation, replacing or supplementing RSA/ECDSA.
  • Key Details:
    • ML-DSA (e.g., ML-DSA-44): Public key ~1312 bytes, signature ~2420 bytes.
    • ML-KEM (e.g., ML-KEM-512): Public key ~800 bytes, ciphertext ~768 bytes.
    • Contrast with RSA-2048 (256-byte key) and ECDSA P-256 (64-byte key, 72-byte signature).

2. CodeSafe SDK: Custom PQC Implementation

  • Mechanism: CodeSafe is a secure execution environment within the nShield HSM, allowing developers to load custom C code (compiled into ELF binaries) to implement PQC algorithms or hybrid workflows. This runs in a tamper-resistant sandbox, leveraging the HSM’s hardware acceleration.
  • PQC Use Case: Entrust provides a Post-Quantum SDK (part of CodeSafe) with pre-built libraries for ML-DSA and ML-KEM, plus templates for other lattice-based or hash-based algorithms (e.g., Falcon, SPHINCS+). Developers can extend this for bespoke needs or early adoption of non-standardized PQC.
  • Flexibility: CodeSafe enables hybrid certificates (e.g., RSA+ML-DSA) by running dual signing operations, critical for legacy transitions where full PQC isn’t yet feasible.
  • Requirements: Requires developer expertise in C, familiarity with nShield APIs (nCore), and testing within the HSM’s constrained environment (e.g., limited memory, no dynamic linking).

3. Hybrid Certificate Support

  • Mechanism: Entrust supports hybrid PQC/classical certificates, combining RSA/ECDSA with ML-DSA/ML-KEM in a single X.509 structure. This is facilitated via firmware and CodeSafe, allowing phased migrations.
  • Implementation: A certificate might use RSA for legacy compatibility and ML-DSA for quantum resistance, with the HSM managing both keys and signing operations. Entrust’s beta trials (e.g., 2023 PQC Labs with ISARA) demonstrated this with Dilithium+RSA hybrids.
  • Ease: Simplifies transition by keeping legacy systems operational while introducing PQC, though it doubles key storage and processing overhead.

4. APIs and Integration

  • Supported APIs: PKCS#11, Microsoft CNG, Java JCE, and nShield’s nCore API expose PQC functions post-firmware update. Legacy apps using these APIs can adopt ML-DSA/ML-KEM with configuration changes, though code updates are often needed for larger key sizes.
  • Performance: Hardware acceleration optimizes lattice-based operations (e.g., matrix multiplications for ML-DSA/ML-KEM), but PQC is slower than ECDSA (e.g., ML-DSA signing ~10x slower).

Ease of Upgrading Legacy RSA/ECDSA to ML-DSA/ML-KEM

  • Firmware Upgrade: Simple but Limited. Applying firmware to enable ML-DSA/ML-KEM is straightforward via Security World—download, install, reboot. However, this alone doesn’t migrate legacy keys or workflows; it just makes PQC available.
  • Application Changes: Moderate to High Effort. Legacy RSA/ECDSA apps must be reworked to use PQC:
    • Key Size Handling: ML-DSA-44 (1312-byte public key) and ML-KEM-512 (800-byte public key) dwarf RSA-2048 (256 bytes), requiring updates to key storage, certificate formats, and protocols (e.g., TLS, CMS).
    • API Adjustments: PKCS#11 apps need new object identifiers (OIDs) for ML-DSA (e.g., FIPS 204) and ML-KEM (FIPS 203), plus logic to handle larger signatures/ciphertexts.
    • Performance Tuning: Slower PQC operations (e.g., ML-DSA signing ~1-2 ms vs. ECDSA ~0.1 ms) may bottleneck high-throughput systems, needing optimization or hybrid fallback.
  • CodeSafe Effort: High for Custom Needs. Using the SDK to implement PQC or hybrids demands C coding, testing in the HSM sandbox, and deployment via Security World. Entrust’s pre-built libraries ease this, but legacy integration isn’t plug-and-play.
  • Hybrid Transition: Moderate Ease. Hybrid certificates reduce immediate pressure by pairing RSA with ML-DSA, but managing dual keys doubles complexity and storage (e.g., ~1.5 KB combined vs. 256 bytes for RSA alone).

Practical Challenges

  1. Developer Burden: CodeSafe’s power comes with a catch—teams need skilled developers to adapt legacy apps, especially for non-standard APIs or complex workflows. Entrust’s documentation is robust, but the learning curve is steep.
  2. Performance Trade-Offs: ML-DSA and ML-KEM are computationally heavier than RSA/ECDSA. Even with hardware acceleration, signing/verification latency increases (e.g., ML-DSA-65: ~3 ms vs. ECDSA: ~0.1 ms), impacting real-time applications like HSM-backed TLS servers.
  3. Legacy Compatibility: RSA/ECDSA keys can’t be “upgraded” to PQC—they must be replaced, requiring key rotation strategies. Hybrid mode helps, but full PQC adoption breaks compatibility with older systems lacking PQC support.
  4. Firmware Dependency: PQC rollout pace depends on Entrust’s firmware releases. While ML-DSA/ML-KEM are supported post-2024 NIST standards, delays in earlier beta phases (e.g., 2022-2024) suggest potential lag for future tweaks.
  5. Storage Overhead: PQC’s larger keys and signatures strain HSM memory and network bandwidth. A single ML-DSA-87 key pair plus signature (6 KB) consumes 20x more space than ECDSA P-256 (0.3 KB), requiring capacity planning.

Practicality of Entrust’s Claims

  • Claim: “Future-proof cryptography with flexible PQC support via CodeSafe and firmware.”
  • Reality: Partially True, Overstated Ease. Firmware delivers ML-DSA/ML-KEM efficiently, and CodeSafe offers unmatched flexibility for custom PQC (e.g., early Falcon adoption). However, “future-proof” glosses over the heavy lifting—legacy uplift isn’t seamless. App rewrites, performance tuning, and developer expertise erode the plug-and-play promise.
  • Strengths: Hybrid support and SDK depth are genuinely forward-thinking, ideal for organizations with resources to invest in PQC now (e.g., CAs, financial institutions).
  • Weaknesses: For simpler setups or teams without SDK skills, the upgrade feels clunky—firmware alone doesn’t bridge the RSA/ECDSA-to-PQC gap without significant downstream effort.

Deep Dive Takeaways

  • Technical Capability: nShield Connect robustly supports ML-DSA and ML-KEM via firmware and CodeSafe, with hardware acceleration softening PQC’s performance hit. Hybrid certificates are a practical bridge.
  • Ease of Upgrade: Moderate Overall. Firmware is easy, but legacy transitions demand app updates (Moderate effort) or custom coding (High effort), far from a drop-in replacement.
  • Practicality: Entrust excels for proactive, tech-savvy users willing to tackle SDK complexity and performance trade-offs. For others, the crypto-agility claim feels aspirational—real, but not effortless.

This deep dive shows nShield Connect is PQC-ready but not PQC-simple.