Nitrokey 3 - Open-Source Hardware FIDO2 Key

Nitrokey 3 - Open-Source FIDO2, OpenPGP, and HMAC Hardware Key

In the Nitrokey 3, open source goes all the way down. Unlike proprietary security keys, the Nitrokey 3 publishes both its hardware design (schematic and PCB layout under open-source licenses) and its firmware (written in Rust using the Trussed cryptography framework)¹. Consequently, every HMAC-SHA256 computation, every ECDSA signature, and every key storage operation can be audited by any security researcher with the technical background to verify the code.

At approximately $59 USD², the Nitrokey 3 is priced above the Thetis Pro and comparable to the YubiKey 5 NFC. It justifies its cost through protocol breadth: FIDO2/WebAuthn, OpenPGP 3 (for email and file signing), PIV (smart card for Windows domain authentication), TOTP/HOTP, and applications built on the Trussed framework including HMAC-SHA256 operations. The USB-C/NFC model (Nitrokey 3A NFC) covers modern connector standards; a USB-A model (Nitrokey 3A Mini) is also available for legacy ports.

For developers who want hardware-enforced HMAC-SHA256 rather than HMAC-SHA1, the Nitrokey 3's Trussed platform supports HMAC-SHA256 through its application framework. Custom applications running on the Trussed platform can use the hardware-isolated key store for HMAC operations, providing SHA-256 where the YubiKey 5 NFC offers only SHA-1 in its OTP slots.

The open-source design is most valuable for high-security environments where supply chain trust is a concern. Organizations that audit their dependencies can verify the Nitrokey's firmware against the published source before deployment, providing a level of assurance that proprietary keys cannot match regardless of security certifications.

Specifications²

Generating OpenPGP keys directly on the Nitrokey 3 hardware

Generating an OpenPGP key directly on the Nitrokey 3 produces private key material that never exists outside the device, which is the strongest possible guarantee that the secret cannot be stolen through a software vulnerability. Use GnuPG to initiate on-card generation: gpg -card-edit, then the admin command, then generate³. The Trussed secure element creates the key internally and blocks export. Only the public key leaves the device. For existing GPG subkeys on disk, moving a subkey to the card with gpg -edit-key and keytocard removes the private key from disk and leaves a stub pointer in its place so that GnuPG still routes signing operations to the hardware.

Keeping private key material on-card

The security benefit comes from never creating the private key in host memory. Once generated on the device, the private material cannot be copied to a laptop image or extracted by malware, and even a fully compromised operating system cannot dump what it never had access to in the first place. This on-device generation pattern is the reason hardware security keys are recommended for high-value email signing, code commit signing, and encryption operations where the private key must remain isolated from any general-purpose computing environment. Organizations that handle classified or regulated data often mandate on-card key generation specifically because it eliminates the attack window that exists between key creation on a general-purpose OS and key import into hardware, which is the moment when a keylogger or memory scraper could capture the secret.

Thunderbird and most mail clients that support GnuPG-based OpenPGP signing work with keys stored on the Nitrokey 3. Email signed with a hardware-stored key provides assurance that the private key was not compromised even if your workstation was infected after the key moved to the device. This guarantee holds because the signing operation happens inside the secure element, so the private key material never appears in the host computer's memory where a keylogger or memory scraper could capture it.

In SSH authentication, the PIV application exposes keys through PKCS#11

For SSH key authentication with hardware protection, the PIV application on the Nitrokey 3 stores RSA or ECC keys and exposes them through a PKCS#11 interface that any standards-compliant SSH client can use⁴. Add PKCS11Provider /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so (or the equivalent OpenSC path on your system) to your ~/.ssh/config. The SSH client passes authentication challenges to the device, which signs them internally. The private key never leaves the device during an SSH session, so even a compromised SSH agent on the host cannot leak the raw key material.

Matching the SSH workflow to human presence

Hardware SSH is strongest when a person is present to press the key, because the physical touch requirement guarantees that no automated process can initiate an SSH session without deliberate human authorization. For unattended jobs, consider short-lived software keys with strict repository permissions instead of bypassing the button requirement, since a hardware key that requires a button press at three in the morning is a deployment bottleneck no engineer wants to debug.

For fully automated CI or deployment pipelines that require SSH access without human interaction, PIV-based hardware keys impose a button-touch requirement that may not suit the use case. Software keys with tightly scoped access controls are often more appropriate for pipelines where no human is present to press the button.

When open-source firmware auditability matters for your threat model

When your security policy requires verifiable supply chain integrity for authentication hardware, the Nitrokey 3 provides a verification path that proprietary devices cannot match. Build the Trussed firmware from the published source at github.com/Nitrokey/nitrokey-3-firmware. Verification only holds if you compute a hash for the firmware you built and compare that digest against the value reported by nitropy nk3 verify-update⁵. A matching hash confirms the factory firmware matches the published source code.

Turning auditability into a deployment gate

This verification step is uncommon for individual users but relevant for organizations with formal supply chain policies. The comparison takes under five minutes on a modern workstation. No proprietary hardware security key offers an equivalent option because the firmware is not published. For environments that audit every firmware component in their security boundary, this auditability is a concrete differentiator. Make the firmware hash comparison a mandatory step in your procurement checklist, so that every batch of newly purchased keys is verified against the published source before it enters production, rather than trusting that the factory firmware matches the open-source repository without checking.