KL Security Key

Experimentelles Open-Source-Projekt von Karaaslan Labs für Engineering und Interoperabilität eines RP2040-FIDO2/WebAuthn-Authentifikators.

Status: Engineering-/Forschungsprojekt. Nicht von der FIDO Alliance zertifiziert. Kein kommerzieller Security-Token mit hoher Assurance.

KL Security Key ist ein kuratiertes Derivat von polhenarejos/pico-fido. Es untersucht, wie weit sich ein kostengünstiges RP2040-Board als physischer WebAuthn-Authentifikator nutzen lässt, während Identität, Attestierung, Validierungsnachweise und Vertrauensgrenzen explizit bleiben.

Auf einen Blick

Bereich	Aktuelle Engineering-Referenz
Hardware	RP2040 USB-Entwicklungsboard
Transport	USB FIDO HID
CTAP/GetInfo-Versionen	FIDO_2_0, FIDO_2_1, FIDO_2_3
User Presence / Verifikation	Physischer Button + 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 von der FIDO Alliance zertifiziert

Warum dieses Projekt existiert

Das Projekt begann mit einer praktischen Frage: Kann ein kostengünstiges Entwicklungsboard zu einem nutzbaren physischen Sicherheitsschlüssel für echte WebAuthn-Anmeldung werden, ohne die Engineering-Kompromisse zu verbergen?

Die interessante Arbeit bestand am Ende nicht einfach darin, RP2040 dazu zu bringen, FIDO2 auszuführen. Die schwierigeren Teile waren Authentifikator-Identität, physische User Presence, Attestierung, Windows-Verhalten, reproduzierbare Quellcode-Änderungen, Interoperabilität mit Relying Parties und das genaue Wissen darüber, was die Nachweise beweisen – und was nicht.

Verifiziert auf der physischen Referenz

• Frische WebAuthn-Registrierung: PASS.
• Authentifizierung / GetAssertion mit derselben Credential: PASS.
• Windows-Provider: MicrosoftCtapHidProvider.
• CTAP2-Pfad beobachtet mit U2fProtocol=false.
• Physische User Presence für Registrierung und Anmeldung erforderlich.
• PIN-/User-Verification-Pfad validiert.
• Packed-Attestierungs-Signatur: PASS.
• Attestierungs-Leaf → KL Security Key Root CA-Verifikation: PASS.
• AAGUID-Übereinstimmung zwischen Authenticator-Daten und Zertifikatserweiterung: PASS.
• Mandantenlokale gerätegebundene Registrierung in Microsoft Entra und frische Anmeldung mit physischem Schlüssel: PASS mit deaktivierter Attestierungsdurchsetzung.

Das Entra-Ergebnis ist ein Interoperabilitätsergebnis, keine Microsoft-Zertifizierung oder globale Authentifikator-Anerkennung. Siehe docs/interoperability-case-study.md für die genaue Grenze.

Architektur

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; unabhängige Tastatur-/CCID-artige Laufzeit-Schnittstellen sind nicht Teil des KL-Referenzprofils.

Referenzprofil bauen

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

Der Build aktiviert die Durchsetzung physischer User Presence, das FIDO-only-Laufzeitprofil und den Packed-Attestierungs-Pfad. Gültiges Attestierungs-Schlüssel-/Zertifikatsmaterial muss separat bereitgestellt werden; private Attestierungs-Schlüssel werden von diesem Repository weder veröffentlicht noch automatisch bereitgestellt.

Vertrauensgrenzen und Nicht-Behauptungen

Dieses Repository behauptet nicht:

• FIDO-Alliance-Zertifizierung;
• Schutz auf Secure-Element-Niveau gegen physische Schlüsselextraktion;
• universelles Vertrauen, Allowlisting oder Kompatibilität seitens Relying Parties;
• Gleichwertigkeit mit YubiKey, Nitrokey oder einem anderen kommerziellen Sicherheitsschlüssel-Anbieter;
• Eigentum von Karaaslan Labs an der USB VID/PID des Upstream-/Projekts;
• Microsoft-Zertifizierung oder globale Anbieter-Anerkennung;
• dass ein Erfolg auf Protokollebene mit einer Relying Party die Akzeptanz durch eine andere beweist.

Lesen Sie THREAT-MODEL.md, bevor Sie die Referenz als mehr als einen Engineering-/Forschungs-Authentifikator betrachten.

Dokumentationsübersicht

Dokument	Zweck
docs/architecture.md	Laufzeitprofil, Quellcode-Layout und Engineering-Grenzen
docs/attestation-and-pki.md	AAGUID, Packed Attestation und PKI-Modell
docs/validation-evidence.md	Validierungsnachweise für physische Referenz und kuratierten Quellcode
docs/interoperability-case-study.md	Interoperabilitätsnachweise und -grenzen für Relying Party / Microsoft Entra
docs/windows-webauthn-debugging.md	Evidenzbasierter Windows-/WebAuthn-Debugging-Workflow
THREAT-MODEL.md	Bedrohungsmodell und Sicherheits-Nicht-Behauptungen
UPSTREAM.md	Upstream-Herkunft und Derivat-Änderungen
SECURITY.md	Schwachstellenmeldung und Sicherheitsrichtlinie

Quelle, Herkunft und Veröffentlichungsmodell

Das Submodul pico-keys-sdk ist auf einen bekannten Upstream-Commit gepinnt. KL-spezifische SDK-Änderungen werden durch scripts/apply-sdk-overlay.py angewendet, das exakt auf einen Commit gepinnt ist und bei unerwartetem Quellcode-Zustand fail-closed arbeitet.

Dieses öffentliche Repository ist bewusst um den KL Security Key-Referenzpfad kuratiert. Unabhängige geerbte Forschungsartefakte und Legacy-Release-Helfer sind nicht Teil der veröffentlichten KL-Oberfläche; die Upstream-Herkunft bleibt in UPSTREAM.md und in der Git-Historie dokumentiert.

Die Binärverteilung ist bewusst nicht das anfängliche Veröffentlichungsziel, solange USB-Identitäts-/Distributionsanforderungen ungeklärt bleiben. Quelle, Dokumentation und Validierungsmethodik sind die primären Artefakte.

Das öffentliche Attestierungs-Root-Zertifikat ist unter certs/KL-Security-Key-Root-CA-v1.cert.pem verfügbar. Private Root-/Geräteschlüssel werden niemals veröffentlicht.

Mitwirken und Sicherheit