KL Security Key

Experimental open-source RP2040 FIDO2/WebAuthn authenticator engineering and interoperability project by Karaaslan Labs.

Status: engineering/research project. Not FIDO Alliance certified. Not a commercial high-assurance security token.

Evidence boundary: the real-device observations below belong to frozen v5.2. The v5.3 hardening work is off-device only and has not been installed or verified on the physical reference.

KL Security Key is a curated derivative of polhenarejos/pico-fido. It explores how far a low-cost RP2040 board can be taken as a physical WebAuthn authenticator while keeping identity, attestation, validation evidence and trust boundaries explicit.

At a glance

Area	Frozen v5.2 physical reference
Hardware	RP2040 USB development board
Transport	USB FIDO HID
CTAP/GetInfo versions	FIDO_2_0, FIDO_2_1, FIDO_2_3
User presence / verification	Physical button + PIN/UV support
Attestation	Packed ES256, x5c, device-specific certificate
AAGUID	d9359dc7-6938-5822-b951-006507247d8f
Interoperability	Windows WebAuthn + tenant-local Microsoft Entra validation
Distribution	Source-first; no KL firmware binary release
Secure element	None
Certification	Not FIDO Alliance certified

Board and flash-size scope

The main source-reference build selects -DPICO_BOARD=pico in scripts/build-kl-reference.sh, targeting the stock Raspberry Pi Pico board configuration with 2 MiB of external flash. The isolated v5.3 off-device builder also selects -DPICO_BOARD=pico; its UF2 output validator checks the Pico 2 MiB flash address window. These are source/build constraints, not physical validation of every RP2040 board.

Other RP2040 boards may have different flash capacity or board configurations. Upstream Pico FIDO issue #278 documents a first-WebAuthn-operation failure on a larger-flash board when the firmware's compile-time flash limit did not match its runtime layout. That upstream finding is not a reproduced KL Security Key failure, but it illustrates why matching the RP2040 chip alone is not sufficient evidence of compatibility.

Do not assume the KL reference firmware works on arbitrary RP2040 boards, or flash a device based solely on a successful build or valid UF2 framing. No alternate-board compatibility, new hardware test, or firmware binary distribution is claimed here. The frozen v5.2 physical reference has not been changed.

Why this project exists

The project began with a practical question: can an inexpensive development board become a usable physical security key for real WebAuthn sign-in, without hiding the engineering compromises?

The interesting work turned out not to be simply making RP2040 run FIDO2. The harder parts were authenticator identity, physical user presence, attestation, Windows behavior, reproducible source changes, relying-party interoperability and knowing exactly what the evidence does — and does not — prove.

Verified on the frozen v5.2 physical reference

The results in this section were obtained with the preserved v5.2 device and must not be attributed to later source or experimental firmware builds. See docs/validation-evidence.md for the frozen UF2 SHA-256 and test boundaries.

• Fresh WebAuthn registration: PASS.
• Authentication / GetAssertion with the same credential: PASS.
• Windows provider: MicrosoftCtapHidProvider.
• CTAP2 path observed with U2fProtocol=false.
• Physical user presence required for registration and sign-in.
• PIN/user-verification path validated.
• Packed attestation signature: PASS.
• Attestation leaf → KL Security Key Root CA verification: PASS.
• AAGUID agreement between authenticator data and certificate extension: PASS.
• Microsoft Entra tenant-local device-bound registration and fresh physical-key sign-in: PASS with attestation enforcement disabled.

The Entra result is an interoperability result, not Microsoft certification or global authenticator recognition. See docs/interoperability-case-study.md for the exact boundary.

v5.3 development — off-device only

The current HID/APDU/OTP hardening is tracked in Draft PR #7. It includes a patch-based SDK integration path, host-side regression tests, and local isolated ARM build evidence. These checks are not a live-device test, full FIDO conformance test, certification, or production release. GitHub Actions runs host/source tests and publication checks; full ARM builds have been verified locally, not in GitHub Actions.

The main branch and its reference build do not automatically include the unmerged v5.3 patches. For current experimental evidence and outstanding blockers, use PR #7 rather than treating historical UF2 hashes or individual test passes as the latest hardware status. No firmware binary from this work is offered for download or flashing.

Architecture

flowchart LR
    RP["Relying party / Microsoft Entra"] --> WA["Browser + Windows WebAuthn"]
    WA --> CTAP["CTAP2 over USB HID"]
    CTAP --> KEY["KL Security Key<br/>RP2040"]
    KEY --> AT["Packed ES256 attestation<br/>device-specific key + x5c"]
    AT --> ROOT["KL Security Key Root CA"]

The validated runtime is intentionally narrow: FIDO HID is the security-key interface; unrelated keyboard/CCID-style runtime interfaces are not part of the KL reference profile.

Build the main source reference profile

git clone --recurse-submodules https://github.com/karaaslanlabs/kl-security-key.git
cd kl-security-key
export PICO_SDK_PATH=/path/to/pico-sdk
export PICO_TOOLCHAIN_PATH=/path/to/arm-none-eabi-toolchain
./scripts/build-kl-reference.sh

The main build enables physical user-presence enforcement, the FIDO-only runtime profile and the packed-attestation path; it is not a build of the unmerged v5.3 changes. Valid attestation key/certificate material must be provisioned separately; private attestation keys are not published or auto-provisioned by this repository. Building a UF2 does not authorize flashing a device.

Trust boundaries and non-claims

This repository does not claim:

• FIDO Alliance certification;
• secure-element-level protection against physical key extraction;
• universal relying-party trust, allowlisting or compatibility;
• equivalence to YubiKey, Nitrokey or another commercial security-key vendor;
• Karaaslan Labs ownership of the upstream/project USB VID/PID;
• Microsoft certification or global vendor recognition;
• that protocol-level success with one relying party proves acceptance by another.

Read THREAT-MODEL.md before treating the reference as anything beyond an engineering/research authenticator.

Documentation map