OpenSK: a Rust FIDO2 security key you can flash onto an nRF52840 board

What OpenSK actually is, and who it is not for

OpenSK is a Rust implementation of a FIDO2 security key, the kind of external device you plug in or tap to sign in to a website. The repository also supports U2F, and the README notes that non-discoverable credentials created with either protocol are compatible with the other. So the same hardware can answer CTAP1 and CTAP2 requests for the same credential.

The intended audience is narrow and the README says so plainly: this is a proof-of-concept and a research platform, not meant for daily usage. That sentence should be read literally. If you want a key for your bank account, buy a certified one. If you want to read, modify, reflash and instrument a CTAP2 authenticator, OpenSK is one of the few codebases where the whole stack, from application down to the operating system, is in the tree. The README frames that as the goal: a full open source experience for security keys, down to a 3D printable enclosure.

Two ways to run it: Wasefire applet or library

The README lists exactly two execution modes. OpenSK can run as a Wasefire applet, or as a library. The Cargo.toml at the repository root describes the applet: the package is named opensk-wasefire and depends on the wasefire prelude with a specific feature set, including api-crypto-ecdsa, api-crypto-hash, api-crypto-hkdf, api-usb-ctap, api-store and api-button. Those features are the hardware capabilities the applet asks the runtime for, which is the concrete picture of how the data flows: the CTAP layer lives in libraries/opensk, and it reaches the chip through Wasefire's API surface rather than talking to registers directly.

The root Cargo.toml also shows the feature flags you can turn on at build time. ctap1 enables U2F support. ed25519 pulls in both opensk/ed25519 and wasefire/api-crypto-ed25519. fingerprint wires in wasefire-common and a fingerprint matcher API. config-command and debug are separate flags. This is a build-time configuration model, not a runtime settings file, so what your key can do is decided before you flash it.

On the cryptography side, the README is honest about a gap: the project is still integrating the ARM CryptoCell-310 embedded in the Nordic nRF52840 chip to enable hardware-accelerated cryptography, and until that is done it uses RustCrypto. That is a software fallback in a device whose whole job is holding secrets. It is a reasonable research trade-off and a poor production one.

Installing OpenSK on a supported board

Hardware comes first. The README lists four supported boards: the Nordic nRF52840-DK, the Nordic nRF52840 Dongle, the Makerdiary nRF52840-MDK USB dongle, and the Feitian OpenSK dongle. If your board is not on that list, the README gives you nothing to work with.

The installation path is a general setup document plus per-hardware instructions. The README points to docs/install.md and says it links specific instructions for the hardware you want to use at the end. The repository root contains setup.sh and flash.sh, which are the two scripts that name implies you will use.

./setup.sh

The Python side of the tooling is declared in pyproject.toml, which requires Python 3.13 or newer and lists colorama, cryptography, fido2, hid, ruff and tqdm as dependencies. That dependency list tells you what the host tools do: they speak FIDO2 over HID to the board, so you can drive the device from a laptop rather than only through a browser.

./flash.sh

The README does not document what flash.sh accepts as arguments or which board it defaults to, so check docs/install.md before running it. After flashing, the README's own success test is a demo website: visit webauthn.io and try to register and then log in. If that fails, the README points to docs/debugging.md for troubleshooting. For anything beyond the default build, docs/customization.md is the next stop.

The certification gap on the develop branch

This is the single most important thing to understand before adopting OpenSK, and the README states it without hedging. The version that implemented CTAP 2.0 was certified by the FIDO Alliance. That is a numbered branch, and the corresponding release is tagged ctap2.0, dated 2021-06-23. The develop branch, which is what you land on by default, tracks the latest CTAP specification and is not FIDO certified.

The README adds that the develop branch is under development and therefore less rigorously tested than the numbered branches. Combine that with the proof-of-concept disclaimer and you have a project that is deliberately not promising you a compliant authenticator on its main line of work. If your goal is a certified CTAP 2.0 device, you want the older code, not the newest code. If your goal is to work on current CTAP features, you accept that nobody has certified the result.

There is a second, quieter limitation: the README does not document rollback or recovery for a board that fails mid-flash. docs/debugging.md is where that would live, but the README itself does not describe it.

Post-quantum signatures as a research artifact

The most interesting thing in this repository is not the FIDO2 support. It is the hybrid post-quantum work. The README says the project implemented post-quantum cryptography on OpenSK and released the code under the hybrid-pqc tag. The associated paper, Hybrid Post-Quantum Signatures in Hardware Security Keys, was published at the 4th ACNS Workshop on Secure Cryptographic Implementation in Kyoto in June 2023 and won the best paper award.

That matters for how you read the project's purpose. OpenSK is a platform for trying signature schemes on real key hardware, where the constraints are memory, flash and a slow chip rather than a server CPU. The README's news entry dates the PQC paper reference to 2023-08-24. If you are evaluating OpenSK for a product, this research angle is a reason to read the code and a reason not to ship it: the hybrid-pqc tag is a research release, not the certified line.

OpenSK compared with a certified commercial key

The obvious alternative is a commercial FIDO2 key from a vendor whose product has passed FIDO certification and comes with a warranty. The difference in approach is not subtle. A commercial key is a closed device: you get a certified behaviour and no visibility into how the credential is stored or how the CTAP state machine handles an edge case. OpenSK gives you the opposite trade. You get the source, the ability to enable or disable CTAP1 and Ed25519 at build time through Cargo features, and the ability to attach a debugger. You give up certification on develop, hardware-accelerated crypto while the CryptoCell-310 integration is unfinished, and any expectation of daily-use reliability.

A second alternative is the Wasefire project, which OpenSK itself depends on and points to as one of its two run modes. That is not really a competitor; it is the runtime underneath. Choosing OpenSK as a Wasefire applet means adopting both, and the README's link to the Wasefire example is the place to start if you want that path.

Licence, maintenance and what upgrading costs

OpenSK is Apache-2.0, declared in the root Cargo.toml and shipped as a LICENSE file at the repository root. Apache-2.0 is permissive and includes a patent grant, which is the usual reason projects in the security space pick it over MIT. That is a factual note about the licence text, not legal advice; if you plan to redistribute a product built on this code, have counsel read the file.

The maintenance picture is mixed. The repository is not archived, and the last push was on 2026-09-04, so work is happening. But the only listed release is ctap2.0 from 2021-06-23, and the README's own news entries stop in 2023. There is no versioned release cadence to upgrade against. Practically, your upgrade unit is a commit on develop, and the develop branch is the one the README warns is less rigorously tested. The Cargo.toml pins edition 2024 and a specific set of Wasefire features, and the repository carries a rust-toolchain.toml, so toolchain drift is a real cost when you pull. Budget for reading diffs rather than bumping a version number.

Editorial conclusion

Adopt OpenSK if you are a firmware or security researcher who already owns a supported Nordic or Makerdiary board and wants a readable Rust CTAP2 implementation you can modify, including the hybrid post-quantum experiment released under the hybrid-pqc tag. Do not adopt it as your daily authenticator: the README states it is proof-of-concept, not meant for daily usage, and the develop branch is not FIDO certified. Before flashing, confirm your board is one of the four listed in the README, read docs/install.md for your specific hardware, and check whether you need the certified CTAP 2.0 code from the numbered branches rather than develop.

Frequently asked questions

Official sources

1. google/OpenSK on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases