This note briefly discusses hardware security keys, the basic FIDO2 workflow, and two representative products: YubiKey and CanoKey.

Some familiarity with public-key cryptography and GnuPG is required to understand this post.

Introduction to Hardware Security Keys

Once pubclic-key cryptography is used in practice, private key management becomes the real problem.

A common solution is to keep a master key offline, derive short-lived subkeys, and use those subkeys for actual encryption, signing, or authentication.
This raises the next question: where should the subkeys live?

A common answer is: inside a hardware security key, so that the private key stays in dedicated hardware rather than entering normal host memory.

1. Hardware security keys

A hardware security key is a device designed to keep private keys inside dedicated hardware and let the host request cryptographic operations without directly receiving the secret itself.

In other words:

• the host requests the operation,
• the device holds the private key.

This is why such devices are useful for encryption, signing, and authentication: they reduce the exposure of private keys to the ordinary software environment of the computer.

2. FIDO2

With that framing, FIDO2 is easier to understand.

FIDO2 is a modern authentication protocol built around WebAuthn and CTAP2.
The protocol details are not important here. What matters is the following:

in FIDO2, the private key remains inside the authenticator.

The host or browser can request proof of possession, but the key itself does not leave the hardware.
That is the core idea.

3. The FIDO2 workflow

At a very high level, the FIDO2 authentication flow is simple.

1. the website sends a challenge to the client,
2. the browser forwards it to the hardware key,
3. the hardware key signs the challenge with the relevant private key,
4. the website verifies the signature using the corresponding public key.

The important point is that, during the whole workflow, the private key never leaves the hardware key.

4. FIDO2 hardware keys in practice

In practice, the two names most readers are likely to encounter are YubiKey and CanoKey.

Yubikey

YubiKey is the mainstream choice.
It was once more open, but after the notorious YubiKey NEO vulnerability, the project moved toward a more closed model. I regard this as a crude response: reducing openness after a vulnerability does not solve the deeper trust problem. A closed security key is still something users are asked to trust without being able to inspect.

Canokey

CanoKey, by contrast, is a smaller and less mature project. It's cheaper and more open source.

Its repositories are publicly available under the canokeys GitHub organization, so it exposes much more of its software (CanoKey-core) and hardware implementation to developers.

CanoKey also clearly separates its developer versions from its retail versions.
The developer versions, such as STM32 and nRF52, are more open and easier to study, but they are not intended to provide real security: if someone gets physical access to the device, they may be able to extract the plaintext private keys.
The retail versions, by contrast, use a different hardware path and are the ones intended to function as actual security products. CanoKey docs