RS-Key: The Case for Open-Source Hardware Security in the Age of Passkeys

The security key market has long operated on an unusual premise: trust us, we know what we are doing. Yubico, Nitrokey, and their peers ask users to place absolute confidence in opaque silicon, closed firmware, and proprietary attestation chains. The entire model rests on the assumption that a corporation's engineering discipline exceeds what any individual or community could achieve. RS-Key, an open-source firmware project from a single maintainer, pushes back against that assumption in a language few expected: Rust, running on a $4 Raspberry Pi RP2350.

The Transparency Problem in Hardware Security

Commercial security keys are black boxes by design. When you plug in a YubiKey, you trust that its firmware correctly implements FIDO2, that its random number generator is not backdoored, that its secure element actually resists the attacks Yubico claims it resists. None of this is independently verifiable by the user. The security community has spent decades building formal verification tools, fuzzing frameworks, and cryptographic audits, yet the devices we trust most for our digital identities remain opaque.

This is not a failure of the companies involved. Auditing hardware is expensive, and the threat models of most users do not include nation-state adversaries with decapping equipment. But there is a meaningful difference between security that cannot be inspected and security that chooses not to be inspected. RS-Key collapses that distinction. Every line of code, every cryptographic primitive, every unsafe block in the Rust source is available for scrutiny on GitHub. The project's documentation includes an architecture guide that explains how it is built, and every instance of unsafe code is auditable.

Why RP2350 Matters More Than It Appears

The Raspberry Pi RP2350 is not a secure element. The project states this plainly, and it is worth repeating: if your threat model includes funded laboratory attacks, you should buy a certified key. But the RP2350 represents something more interesting than a silicon compromise. It is a $4 microcontroller with USB, hardware crypto accelerators, and one-time-programmable fuses that can enable secure boot. For the first time, the gap between a hobbyist board and a production security token has narrowed to the point where the difference is firmware, not hardware.

RS-Key exploits this convergence. It implements FIDO2 and WebAuthn, OpenPGP card 3.4, PIV smart-card functionality via PKCS#11, OATH TOTP/HOTP, and Yubico-style OTP. It supports post-quantum FIDO2 through ML-DSA-44, an experimental scheme that most commercial keys have not yet shipped. The project supports up to 256 resident passkeys, 255 OATH accounts, 24 PIV slots, and 4 OTP slots, all flash-bound capacities that exceed what many commercial keys offer.

The development experience reflects this accessibility. The quick start is a clone, a nix develop shell, a cargo build, and a drag-and-drop UF2 flash. The host tooling, written in Python, provides CLI and TUI interfaces for day-to-day operations. The project even includes a RAM-only flash-erase image for clean-slate testing. This is not a proof of concept; it is a working development environment for security key firmware.

The Rust Advantage in Cryptographic Code

The choice of Rust for this project is not incidental. Security key firmware runs in an environment where memory safety bugs are catastrophic, where buffer overflows can leak cryptographic material, and where undefined behavior can silently undermine every guarantee the system claims to make. The Embassy async runtime provides structured concurrency without the overhead of an operating system, and the no_std constraint eliminates entire classes of runtime dependencies.

The project's treatment of unsafe code is instructive. Rather than avoiding unsafe entirely, which is impractical in embedded systems that must interact with hardware registers and DMA buffers, RS-Key audits every unsafe site and documents the reasoning. This is the approach that the broader Rust security community has converged on: not the elimination of unsafe, but the rigorous justification of it.

The absence of certain OpenPGP curves, specifically Brainpool, X448, and Ed448, reflects a different kind of pragmatism. There are no mature no_std Rust implementations of these curves. Rather than shipping incomplete or unaudited code, RS-Key omits features it cannot yet implement correctly. This restraint is itself a security posture.

The Single-Maintainer Paradox

RS-Key is a hobby project under active development by a single maintainer. This fact complicates the narrative in useful ways. Commercial security keys benefit from organizational accountability, insurance, and teams of engineers. But they also suffer from institutional inertia, threat model assumptions that may not match the user's reality, and the inability to inspect the code that protects your identity.

A single maintainer cannot provide the same guarantees as a funded security team. The project acknowledges this explicitly: it has had no external security audit, the RP2350 is not a secure element, and a stolen board is only as strong as the optional OTP and secure boot hardening you have applied to it. The project's threat model documentation is unusually honest about what it protects against and what it does not.

But the single-maintainer model also has advantages that are easy to overlook. Decision cycles are short. Feature priorities respond to actual user needs rather than market positioning. The codebase is small enough that a motivated reader can understand the entire system. And the project's AGPL-3.0 license, inherited from the pico-keys firmware family it reimplements, ensures that any forks remain open.

The Broader Pattern

RS-Key participates in a larger movement toward open-source hardware security. Projects like the Trezor, the OpenSmartCard project, and the soloKeys initiative have all explored what happens when the security community applies its own tools to its own infrastructure. What distinguishes RS-Key is its willingness to target a microcontroller platform that costs less than a cup of coffee, while still implementing a feature set that approaches commercial keys.

The post-quantum FIDO2 support deserves particular attention. The ML-DSA-44 implementation is experimental and disabled by default because some browsers reject unknown algorithm IDs, but its presence signals a direction. Commercial key manufacturers will eventually ship post-quantum algorithms, but they will do so on their timeline, behind their attestation, with their priorities. RS-Key makes the same algorithms available now, to anyone with an RP2350 board and a willingness to read the documentation.

Production Hardening and Its Limits

The project offers an optional production path that fuses a random master key into RP2350 OTP and enables secure boot. Once activated, these steps are irreversible: the board will only run signed images, and the reflash workflow changes permanently. This is real security hardening, and the documentation is careful to note that it is also irreversible and potentially bricking.

The tension here is fundamental. Security requires commitment, and commitment requires irreversible choices. A board that can be reflashed at any time is a board that any attacker with physical access can reflash. A board with fused OTP is a board that is harder to attack but also harder to recover. RS-Key does not pretend to resolve this tension. It presents the tradeoffs, provides the tools, and lets the user decide.

What RS-Key Is Not

The project's documentation is unusually explicit about its limitations. It is not a drop-in replacement for an audited commercial key. It does not protect against physical or lab attacks. It does not guarantee that a compromised host with the device unlocked will behave differently from any other security key in the same situation. It is not affiliated with or endorsed by Yubico, Nitrokey, or Raspberry Pi.

This honesty is itself a contribution. The security industry has a tendency to present absolute guarantees where conditional ones would be more accurate. RS-Key's willingness to say this is experimental, that the RP2350 is not a secure element, and that a stolen board is only as strong as the hardening you apply, represents a more mature approach to security communication than many commercial vendors manage.

The Philosophical Core

What RS-Key really challenges is the assumption that security must be centralized to be trustworthy. The traditional model says: trust a company with a track record, because companies have accountability, insurance, and professional engineers. The open-source model says: trust the code, because anyone can read it, fork it, and verify it. Neither model is complete. Companies can be compromised, code can contain subtle bugs, and most users will never read a line of either.

But the availability of the code changes the game in ways that are easy to miss. When the firmware is open, security researchers can audit it. When the build process is reproducible, the binary can be verified against the source. When the threat model is documented, users can make informed decisions. The single maintainer behind RS-Key has created something that a corporation cannot: a security key whose guarantees you can check yourself, for the cost of a Raspberry Pi board and an afternoon of reading.

The project exists at an interesting intersection: sophisticated enough to implement real cryptographic protocols, honest enough to acknowledge what it cannot protect against, and accessible enough that a curious developer can build it in an evening. That combination is rare in security, and it is worth paying attention to.