The USB-C Hardware Security Module
For PKCS#11 and PKI: every key generated and kept inside a smart card on an EAL6+ certified platform, in a device that verifies its own firmware at boot.
The KeyNub hardware security module (HSM) protects keys that must never be copyable. Every private key is generated inside the smart card fitted in the device and is non-extractable, so there is no export path to misuse and nothing on the host worth stealing. To your operating system it is an ordinary USB smart-card reader, so the PKCS#11 tooling your PKI already uses drives it with nothing to install.
What Makes the KeyNub HSM Different
Nothing to Install
The device presents the standard USB smart-card reader class, so Windows, Linux and macOS each bind their own built-in driver. No INF file, no kernel module, no vendor middleware between your application and your keys.
Keys Born on the Card
RSA up to 4096 bits and elliptic curves up to P-521, generated in hardware inside the card. Private keys are created there and are non-extractable: there is no command, and no firmware path, that can read one out.
You Hold Every Credential
The card ships uninitialised. You set the SO-PIN, the user PIN and the encrypted backup domain yourself. No KeyNub-held credential exists, which means nobody but you can ever administer your keys.

For PKI and Certificate Authorities
A root you can hold in your hand
A certificate authority is only as trustworthy as the place its private key lives. Generate that key inside the KeyNub HSM and it exists in exactly one place, in hardware, on a Common Criteria EAL6+ certified platform — not in a file, not in a keystore, not in a backup somebody forgot to encrypt.
- Root and issuing CA keys for an internal PKI, held offline between signing ceremonies.
- Code signing for Windows, Java, firmware and container images, where a leaked key means revoking every release you ever shipped.
- TLS server keys that stay on the machine they belong to.
- Document and e-mail signing, S/MIME and qualified signature workflows.
- SSH and machine identity for infrastructure that has to prove what it is.
Encrypted key backup is built in. At initialisation you choose how many shares the device key encryption key is split into, and you hold all of them — so a key can be restored to a replacement device without ever existing outside hardware.
Works With the Tools You Already Use
Standard interfaces, not a vendor island
The KeyNub HSM speaks PKCS#11 through OpenSC, which has supported this card for years. That means your existing PKI software drives the device directly, and KeyNub neither replaces it nor charges you for it.
- PKCS#11 via
opensc-pkcs11— the interface almost every PKI product speaks. - Windows CryptoAPI and CNG through the OpenSC minidriver, so certificates appear in the Windows certificate store and Active Directory Certificate Services, Authenticode and signtool can use them.
- EJBCA as a PKCS#11 crypto token for issuing and root CAs.
- XCA for managing keys, requests and certificates on the token.
- OpenSSL through pkcs11-provider or the PKCS#11 engine.
- Java via SunPKCS11, for keystores and JAR signing.
- Initialisation and key backup with
sc-hsm-tool.
Windows, Linux and macOS are all driverless: the operating system binds its own CCID driver the moment the device is plugged in.
More Than a Card Reader
The hardware around the card is not passive
Most USB HSMs in this class are a bridge chip in front of a smart card. The KeyNub HSM adds the things a bridge cannot: the firmware is verified before it runs, the host-facing code cannot reach your keys, updates are signed, and the device will tell you what it is.
- Secure boot. The controller ROM verifies an ECDSA signature over the firmware before it runs, enforced by one-time-programmable fuses. Debug access is permanently disabled on shipped units.
- Isolated attack surface. The USB stack and every parser the host can reach run in a separate Arm TrustZone world, unable to address the card, the device identity or storage.
- Signed firmware updates with automatic rollback. Updates are signed and installed into a second slot; one that fails its self-test reverts unaided, so an update cannot leave you with a brick.
- Attestation. Send the device a fresh challenge and it returns a signed report of its firmware version, its configuration and the identity of the card inside — genuine firmware and genuine hardware, provable on demand.
- Sealed enclosure. No user-serviceable parts, and a device identity issued by the KeyNub HSM root CA.
Technology at a Glance
| Key generation | On the card, in hardware: RSA 1024–4096, ECDSA and ECDH 192–521 bits |
| Mechanisms | RSA PKCS#1 v1.5, PSS, OAEP and X.509; ECDSA with SHA-1 and SHA-224/256/384/512; ECDH with and without cofactor |
| Signing performance | ECDSA P-256 39 ms, RSA-2048 113 ms, RSA-4096 1.04 s |
| Key generation time | EC P-256 1.1 s, RSA-2048 2.6 s, RSA-4096 40–100 s |
| Secure element | A Common Criteria EAL6+ certified smart card |
| Key backup | Encrypted export and import under a key encryption key you split into shares at initialisation |
| Interface | USB-C, USB 2.0 Full Speed, bus powered. Standard USB CCID smart-card reader plus a vendor interface for management |
| Operating systems | Windows, Linux and macOS — driverless on all three |
| Controller | 32-bit Arm Cortex-M33, 2 MB flash, secure boot, TrustZone isolation |
| Enclosure | Compact sealed USB-C housing with status and fault indicators |
| Origin | Developed and supported in Germany |
Full specifications, including the complete mechanism list, are in the datasheet.
Questions we get asked
Are the keys really protected in hardware?
Every private key is generated inside a smart card on a Common Criteria EAL6+ certified platform and is non-extractable. There is no export command and no firmware path to key material.
Do I need to install a driver?
No. The device presents the standard USB smart-card reader class, so Windows, Linux and macOS each bind their own built-in driver. There is no INF file, no kernel module and no vendor middleware.
Which algorithms and key sizes does it support?
RSA from 1024 to 4096 bits and ECDSA and ECDH from 192 to 521 bits, all in hardware, with PKCS#1 v1.5, PSS, OAEP and X.509 padding and SHA-1 through SHA-512.
Will it work with the PKI software I already use?
Yes. It speaks PKCS#11 through OpenSC, so EJBCA, XCA, OpenSSL, Java through SunPKCS11 and the Windows certificate store all drive it directly. No KeyNub software takes part in a key operation.
How fast is a signature?
Measured through the device: an ECDSA P-256 signature in 39 ms, RSA-2048 in 113 ms. Key generation takes 1.1 s for EC P-256 and 2.6 s for RSA-2048.
Can I back up a key?
Yes. At initialisation you choose how many shares the device key encryption key is split into, and you hold all of them, so a wrapped copy of a key can be restored to a replacement device without ever existing outside hardware.
Who holds the PINs?
You do. The card ships uninitialised, so you set the SO-PIN, the user PIN and the backup domain yourself. No KeyNub-held credential exists.
Can I prove a key was generated in hardware?
Yes. Send the device a fresh challenge and it returns a signed report of its firmware version, its configuration and the identity of the card fitted in it.
Contact Us
Tell us what you need the HSM to protect and we will tell you straight whether it fits. Volume pricing, evaluation units and OEM variants — your own enclosure, logo, USB identifiers and firmware — are all available.