karaaslanlabs/kl-security-keyExperimenteller RP2040 FIDO2/WebAuthn-Authenticator mit gepackter Attestierung und dokumentierter Windows/Entra-Interoperabilität
Experimentelles Open-Source-Projekt von Karaaslan Labs für Engineering und Interoperabilität eines RP2040-FIDO2/WebAuthn-Authenticators.
Status: Engineering-/Forschungsprojekt. Nicht FIDO-Alliance-zertifiziert. Kein kommerzieller Security-Token mit hoher Assurance.
Evidenzgrenze: Die untenstehenden Beobachtungen am realen Gerät gehören zum eingefrorenen v5.2. Die Härtungsarbeiten in v5.3 finden ausschließlich außerhalb des Geräts statt und wurden nicht auf der physischen Referenz installiert oder verifiziert.
KL Security Key ist eine kuratierte Ableitung von polhenarejos/pico-fido. Das Projekt lotet aus, wie weit sich ein kostengünstiges RP2040-Board als physischer WebAuthn-Authenticator treiben lässt, während Identität, Attestierung, Validierungsnachweise und Vertrauensgrenzen explizit bleiben.
| Bereich | Eingefrorene physische Referenz v5.2 |
|---|---|
| Hardware | RP2040-USB-Entwicklungsboard |
| Transport | USB FIDO HID |
| CTAP/GetInfo-Versionen | FIDO_2_0, FIDO_2_1, FIDO_2_3 |
| Nutzerpräsenz / -verifikation | Physische Taste + PIN/UV-Unterstützung |
| Attestierung | Packed ES256, x5c, gerätespezifisches Zertifikat |
| AAGUID | d9359dc7-6938-5822-b951-006507247d8f |
| Interoperabilität | Windows WebAuthn + mandantenlokale Microsoft-Entra-Validierung |
| Distribution | Source-first; keine KL-Firmware-Binärveröffentlichung |
| Secure Element | Keines |
| Zertifizierung | Nicht FIDO-Alliance-zertifiziert |
Der main-Source-Referenz-Build wählt -DPICO_BOARD=pico in scripts/build-kl-reference.sh und zielt damit auf die Standardkonfiguration des Raspberry Pi Pico mit 2 MiB externem Flash. Der isolierte v5.3-Off-Device-Builder wählt ebenfalls -DPICO_BOARD=pico; sein UF2-Ausgabe-Validator prüft das 2-MiB-Flash-Adressfenster des Pico. Dies sind Source-/Build-Einschränkungen, keine physische Validierung jedes RP2040-Boards.
Andere RP2040-Boards können eine andere Flash-Kapazität oder Board-Konfiguration aufweisen. Das Upstream-Pico-FIDO-Issue #278 dokumentiert einen Fehler bei der ersten WebAuthn-Operation auf einem Board mit größerem Flash, als das zur Kompilierzeit festgelegte Flash-Limit der Firmware nicht zum Laufzeit-Layout passte. Dieser Upstream-Befund ist kein reproduzierter Fehler des KL Security Key, verdeutlicht aber, warum die bloße Übereinstimmung des RP2040-Chips kein ausreichender Kompatibilitätsnachweis ist.
Gehen Sie nicht davon aus, dass die KL-Referenz-Firmware auf beliebigen RP2040-Boards funktioniert, und flashen Sie ein Gerät nicht allein aufgrund eines erfolgreichen Builds oder einer gültigen UF2-Rahmung. Es wird hier weder Kompatibilität mit alternativen Boards noch ein neuer Hardware-Test noch eine Firmware-Binärverteilung beansprucht. Die eingefrorene physische Referenz v5.2 wurde nicht verändert.
Das Projekt begann mit einer praktischen Frage: Kann ein preisgünstiges Entwicklungsboard zu einem nutzbaren physischen Sicherheitsschlüssel für echte WebAuthn-Anmeldungen werden, ohne die technischen Kompromisse zu verbergen?
Die interessante Arbeit bestand am Ende nicht einfach darin, RP2040 dazu zu bringen, FIDO2 auszuführen. Die schwierigeren Teile waren Authenticator-Identität, physische Nutzerpräsenz, Attestierung, Windows-Verhalten, reproduzierbare Source-Änderungen, Interoperabilität mit Relying Parties und das genaue Wissen darüber, was die Evidenz beweist – und was nicht.
Die Ergebnisse in diesem Abschnitt wurden mit dem erhaltenen v5.2-Gerät erzielt und dürfen nicht späteren Source- oder experimentellen Firmware-Builds zugeschrieben werden. Siehe docs/validation-evidence.md für den eingefrorenen UF2-SHA-256 und die Testgrenzen.
MicrosoftCtapHidProvider.U2fProtocol=false.Das Entra-Ergebnis ist ein Interoperabilitätsergebnis, keine Microsoft-Zertifizierung oder globale Authenticator-Anerkennung. Die genaue Abgrenzung ist in docs/interoperability-case-study.md beschrieben.
Die aktuelle HID/APDU/OTP-Härtung wird in Draft PR #7 verfolgt. Sie umfasst einen patchbasierten SDK-Integrationspfad, hostseitige Regressionstests und lokale isolierte ARM-Build-Nachweise. Diese Prüfungen sind kein Live-Gerätetest, kein vollständiger FIDO-Konformitätstest, keine Zertifizierung und kein Produktionsrelease. GitHub Actions führt Host-/Quelltests und Publikationsprüfungen aus; vollständige ARM-Builds wurden lokal verifiziert, nicht in GitHub Actions.
Der main-Branch und sein Referenz-Build enthalten die nicht zusammengeführten v5.3-Patches nicht automatisch. Für aktuelle experimentelle Nachweise und offene Blocker sollte PR #7 herangezogen werden, statt historische UF2-Hashes oder einzelne bestandene Tests als aktuellen Hardware-Status zu betrachten. Es wird kein Firmware-Binary aus dieser Arbeit zum Download oder Flashen angeboten.
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"]
Die validierte Laufzeitumgebung ist bewusst eng gefasst: FIDO HID ist die Sicherheitsschlüssel-Schnittstelle; nicht zugehörige Tastatur-/CCID-artige Laufzeit-Schnittstellen sind nicht Teil des KL-Referenzprofils.
main-Quellreferenzprofil erstellengit 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
Der main-Build aktiviert die Durchsetzung der physischen Benutzerpräsenz, das FIDO-only-Runtime-Profil und den Pfad für gepackte Attestierung; er ist kein Build der nicht zusammengeführten v5.3-Änderungen. Gültiges Attestierungsschlüssel-/Zertifikatsmaterial muss separat bereitgestellt werden; private Attestierungsschlüssel werden von diesem Repository weder veröffentlicht noch automatisch bereitgestellt. Das Erstellen einer UF2 autorisiert nicht das Flashen eines Geräts.
Dieses Repository erhebt nicht den Anspruch auf: