The Luna Network HSM

The Luna Network HSM and PQC Agility (Deep Dive)

The Luna Network HSM is Thales’ flagship network-attached, general-purpose HSM, designed for high-performance cryptographic operations across enterprise applications (e.g., PKI, code signing, TLS). It’s FIPS 140-2 Level 3 certified (with FIPS 140-3 certification pending as of 2025) and operates as a shared network resource, accessible via multiple clients over TCP/IP. Built for classical algorithms like RSA, ECDSA, and AES,

Thales has been adapting it for PQC following NIST’s standardization process, with ML-DSA and ML-KEM finalized in August 2024 (FIPS 204 and FIPS 203, respectively).

Thales’ PQC strategy centers on Functionality Modules (FMs)—customizable firmware extensions—delivered through firmware updates, positioning the Luna Network HSM as “crypto-agile” for transitioning from legacy to quantum-resistant algorithms.

How Luna Network HSM Supports PQC Algorithms

1. Firmware Updates and Functionality Modules (FMs)

  • Mechanism: Thales introduces PQC support via firmware upgrades that include Functionality Modules (FMs)—pluggable software components executed within the HSM’s secure boundary. FMs extend the HSM’s cryptographic capabilities, adding algorithms like ML-DSA for signing/verification and ML-KEM for key encapsulation.
  • Current Status: As of March 03, 2025, Thales has released firmware supporting ML-DSA and ML-KEM, aligning with NIST’s 2024 standards. Earlier beta firmware (e.g., Luna 7 series, 2022-2024) included experimental PQC support for candidates like CRYSTALS-Dilithium and CRYSTALS-Kyber, tested in Thales’ Quantum Lab initiatives.
  • Process: Firmware updates are applied using the LunaCM (Command Manager) or Luna Shell (lsh), requiring a reboot. Pre-built FMs for ML-DSA/ML-KEM are loaded automatically post-update, while custom FMs can be developed for specific needs (more on this below).
  • Key Details:
    • ML-DSA-44: Public key ~1312 bytes, signature ~2420 bytes.
    • 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. Pre-Built vs. Custom FMs

  • Pre-Built FMs: Thales provides ready-made FMs for NIST PQC algorithms (ML-DSA, ML-KEM) as part of firmware releases. These are optimized for standard use cases (e.g., PKI, TLS) and accessible via APIs like PKCS#11, CAPI/CNG, and JCE without additional coding.
  • Custom FMs: For non-standard PQC algorithms (e.g., Falcon, SPHINCS+) or hybrid workflows, users can develop custom FMs using Thales’ FM SDK. This requires C programming, compilation into HSM-compatible binaries, and Thales approval/deployment, running within the HSM’s tamper-resistant environment.
  • Hybrid Support: Custom FMs can implement hybrid certificates (e.g., RSA+ML-DSA), combining legacy and PQC operations. Thales has demoed this in trials (e.g., 2023 Quantum Lab with DigiCert), though it’s not pre-built out of the box.

3. API and Application Integration

  • Supported APIs: PKCS#11, Microsoft CAPI/CNG, Java JCE, and Thales’ proprietary Luna API expose PQC functions after firmware updates. Legacy apps can adopt ML-DSA/ML-KEM by updating configurations to use new OIDs (e.g., FIPS 204 for ML-DSA).
  • Performance: The Luna HSM’s hardware acceleration (e.g., dedicated crypto co-processors) optimizes lattice-based operations for ML-DSA/ML-KEM, though PQC remains slower than classical algorithms (e.g., ML-DSA signing ~1-2 ms vs. ECDSA ~0.1 ms).

4. Additional Features

  • Quantum Random Number Generator (QRNG): Luna Network HSMs integrate QRNG for stronger key generation, enhancing PQC security (e.g., randomness for ML-KEM key encapsulation).
  • Partitioning: Multiple tenants or applications can use PQC in isolated partitions, supporting phased migrations where legacy RSA/ECDSA persists alongside ML-DSA/ML-KEM.

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

  • Firmware Upgrade: Simple Initial Step. Installing firmware with pre-built FMs for ML-DSA/ML-KEM is straightforward via LunaCM—download, apply, reboot. This enables PQC but doesn’t automatically migrate legacy workflows.
  • Application Changes: Moderate to High Effort. Legacy RSA/ECDSA systems require significant updates:
    • Key Size Handling: ML-DSA-44 (1312-byte public key, 2420-byte signature) and ML-KEM-512 (800-byte public key, 768-byte ciphertext) far exceed RSA-2048 (256 bytes) and ECDSA P-256 (72 bytes), necessitating updates to key stores, certificate formats, and protocols (e.g., TLS 1.3).
    • API Adjustments: PKCS#11 apps need new OIDs and logic to process larger PQC data. For example, a legacy app expecting 72-byte ECDSA signatures must handle ML-DSA-65’s 3307-byte signatures.
    • Performance Tuning: PQC’s slower operations (e.g., ML-DSA signing ~10x slower than ECDSA) may require load balancing or hybrid fallbacks for high-throughput use cases.
  • Custom FM Development: High Effort. Building custom FMs for hybrid RSA+ML-DSA or non-NIST PQC (e.g., Falcon) involves:
    • C coding with the FM SDK.
    • Testing in a sandboxed HSM environment.
    • Submission to Thales for signing/deployment (a 4-6 week process, per Thales docs).
    • This is impractical for rapid legacy uplift unless pre-built FMs suffice.
  • Hybrid Transition: Moderate Ease. Custom FMs can pair RSA/ECDSA with ML-DSA/ML-KEM in hybrid certificates, easing migration by maintaining legacy compatibility. However, this doubles key management complexity (e.g., ~1.5 KB combined vs. 256 bytes for RSA) and isn’t pre-configured.

Practical Challenges

  1. FM Customization Bottleneck: Pre-built FMs for ML-DSA/ML-KEM work well for standard use, but custom FMs for hybrid or niche PQC needs are slow and costly—Thales’ approval process and SDK complexity deter quick adaptation.
  2. Performance Overhead: Even with hardware acceleration, ML-DSA and ML-KEM lag behind RSA/ECDSA. For example, ML-DSA-65 signing (3 ms) vs. ECDSA P-256 (0.1 ms) can strain real-time applications (e.g., HSM-backed web servers), requiring optimization or reduced security levels (e.g., ML-DSA-44).
  3. Legacy Integration: RSA/ECDSA keys must be replaced, not upgraded, necessitating key rotation and re-issuance of certificates. Hybrid mode mitigates this, but full PQC breaks older systems without PQC support.
  4. Storage Demands: PQC’s larger keys and signatures stress HSM capacity. A single ML-DSA-87 key pair plus signature (6 KB) vs. ECDSA P-256 (0.3 KB) demands 20x more space, impacting partition planning and network bandwidth.
  5. Firmware Rollout Pace: Thales has kept up with NIST’s 2024 standards, but earlier PQC delays (e.g., beta FMs in 2022-2023) suggest potential lag for future algorithm tweaks or custom requests.

Practicality of Thales’ Claims

  • Claim: “Crypto-agility through modular FMs ensures seamless PQC adoption.”
  • Reality: Partially True, Overstated Simplicity. Pre-built FMs deliver ML-DSA/ML-KEM effectively for standard use cases, and the modular concept is innovative. However, “seamless” oversells the experience—legacy uplift requires app rework, performance tuning, and significant effort for custom FMs.
  • Strengths: Pre-built FMs and hardware acceleration make it viable for organizations sticking to NIST PQC (e.g., CAs adopting ML-DSA). QRNG and partitioning add value for phased transitions.
  • Weaknesses: Custom FM development is a practical nightmare—slow, expensive, and Thales-dependent—undermining agility for non-standard needs. Legacy integration isn’t as smooth as marketed, especially without hybrid pre-configuration.

Deep Dive Takeaways

  • Technical Capability: Luna Network HSM supports ML-DSA and ML-KEM robustly via pre-built FMs, with hardware acceleration softening PQC’s performance hit. Custom FMs offer flexibility, and hybrid options are feasible with effort.
  • Ease of Upgrade: Moderate Overall. Firmware with pre-built FMs is simple to deploy, but legacy transitions demand app updates (Moderate effort) or custom FM coding (High effort)—not a drop-in solution.
  • Practicality: Thales shines for standard PQC adoption with resources to handle integration, but the “crypto-agile” label feels aspirational for legacy systems—customization and performance gaps hinder true seamlessness.