Hardware Security Modules Don’t Make Signing Interfaces Safe

Myth

If your private key never leaves the HSM, you are safe. The standard pitch for hardware security modules rests on physical isolation: keys stay inside tamper-resistant silicon, attackers cannot steal what they cannot dump, and signatures generated inside the boundary remain trustworthy.

This assumption drives institutional key management, FIPS 140-2 validation marketing, and most threat modeling. The key never leaves the box, so the box defines the perimeter.

Reality

Researchers from UC San Diego and France’s INRIA published a preprint on the IACR Cryptology ePrint Archive (September 20, 2026) demonstrating that forging valid RSA signatures without ever extracting the private key from the hardware is possible.

The attack turns the HSM into a chosen-message signing oracle. With raw signing enabled and unformatted numbers submitted across the API, the device signs arbitrary inputs. The team sent roughly 4 billion chosen messages (2^32 requests), collected the outputs, and used the mathematical structure of RSA to reconstruct enough state to forge fresh signatures. The key stayed inside the hardware. Valid signatures came out anyway.

The intuition is simple: a vault that blindly stamps every sheet of paper slid under the door will eventually give away the stamp.

Executing the attack required 1,380 CPU core-years against a 1,024-bit RSA key. Modern deployments using PKCS#1 v1.5 or PSS padding are not immediately vulnerable. Padding randomizes or structures the input and breaks the oracle. But 1,024-bit RSA and raw signing modes persist in legacy enterprise PKI, embedded equipment, and industrial hardware. The research proves that key non-extractability fails as a defense when the signing interface is permissive and unthrottled.

Bitcoin and Ethereum are not affected. Both use elliptic curve signatures (ECDSA and Schnorr), not RSA. But any system relying on RSA blind signatures, Privacy Pass token issuance, or legacy signing appliances faces a changed threat model.

The authors frame this as evidence for accelerating the post-quantum migration. Physical isolation offers no protection against algorithmic shortcuts, whether through mathematical oracle attacks today or Shor’s algorithm on future quantum hardware.

How to protect

Audit your HSM signing interfaces before someone else does. Hardware that accepts unrestricted signing calls needs API-layer controls, not just physical locks. Check which mechanisms your device exposes:

# List active mechanisms on the HSM slot. Look for raw RSA (CKM_RSA_X_509) and disable it.
pkcs11-tool --module /usr/lib/libsofthsm2.so --show-info
pkcs11-tool --module /usr/lib/libsofthsm2.so --list-mechanisms --slot 0 | grep -i rsa

Four controls that close the vector:

• Alert on signing volume: Four billion requests should not go unnoticed. Set strict rate limits per application identity, not per session, and wire anomaly alerting to your SIEM before any threshold gets tested.
• Disable raw RSA mechanisms at the hardware layer: In PKCS#11, CKM_RSA_X_509 is the raw signing mechanism. If your device exposes it, disable it. Mandate PSS padding for new signing workflows; PKCS#1 v1.5 is acceptable only when the input is fully constrained.
• Retire 1,024-bit RSA keys: NIST deprecated 1,024-bit RSA in 2013. If your HSMs still hold 1,024-bit keys, this research removes the last excuse. Move to 2,048-bit minimum; 4,096-bit or Ed25519 for keys with a long lifetime.
• Start post-quantum signing planning now: ML-DSA (CRYSTALS-Dilithium) is NIST-standardized. Any root certificate or signing infrastructure with validity past 2030 needs a migration timeline on paper today, not after a forced event.

The attack didn’t break RSA’s mathematics. It broke the assumption that exposing a signing interface is safe when the key is physically isolated. Those are different problems with different fixes.

The security boundary is the API, not the enclosure. Design accordingly.