karaaslanlabs/kl-security-keyAuthentificateur FIDO2/WebAuthn expérimental basé sur RP2040 avec attestation packed et interopérabilité documentée Windows/Entra
Projet expérimental d'ingénierie et d'interopérabilité d'un authentificateur FIDO2/WebAuthn RP2040 open source par Karaaslan Labs.
Statut : projet d'ingénierie/recherche. Non certifié par la FIDO Alliance. Ce n'est pas un jeton de sécurité commercial à haute assurance.
Périmètre des preuves : les observations sur appareil réel ci-dessous concernent la version figée v5.2. Le travail de durcissement v5.3 est réalisé hors appareil uniquement et n'a pas été installé ni vérifié sur la référence physique.
KL Security Key est un dérivé sélectionné de polhenarejos/pico-fido. Il explore jusqu'où une carte RP2040 à bas coût peut être poussée en tant qu'authentificateur WebAuthn physique, tout en rendant explicites l'identité, l'attestation, les preuves de validation et les frontières de confiance.
| Domaine | Référence physique figée v5.2 |
|---|---|
| Matériel | Carte de développement USB RP2040 |
| Transport | USB FIDO HID |
| Versions CTAP/GetInfo | FIDO_2_0, FIDO_2_1, FIDO_2_3 |
| Présence / vérification de l'utilisateur | Bouton physique + prise en charge PIN/UV |
| Attestation | Packed ES256, x5c, certificat propre à l'appareil |
| AAGUID | d9359dc7-6938-5822-b951-006507247d8f |
| Interopérabilité | WebAuthn Windows + validation Microsoft Entra locale au tenant |
| Distribution | Priorité au code source ; aucune publication de binaire firmware KL |
| Élément sécurisé | Aucun |
| Certification | Non certifié par la FIDO Alliance |
La compilation de référence source main sélectionne -DPICO_BOARD=pico dans scripts/build-kl-reference.sh, ciblant la configuration standard de la carte Raspberry Pi Pico avec 2 MiB de flash externe. Le constructeur hors appareil isolé v5.3 sélectionne également -DPICO_BOARD=pico ; son validateur de sortie UF2 vérifie la fenêtre d'adresses de flash de 2 MiB de la Pico. Il s'agit de contraintes de source/compilation, et non d'une validation physique de chaque carte RP2040.
D'autres cartes RP2040 peuvent avoir une capacité de flash ou des configurations différentes. Le ticket upstream Pico FIDO issue #278 documente un échec à la première opération WebAuthn sur une carte à flash plus grande lorsque la limite de flash à la compilation du firmware ne correspondait pas à sa disposition à l'exécution. Cette constatation upstream n'est pas une défaillance reproduite de KL Security Key, mais elle illustre pourquoi la seule correspondance du chip RP2040 ne constitue pas une preuve suffisante de compatibilité.
Ne partez pas du principe que le firmware de référence KL fonctionne sur des cartes RP2040 arbitraires, et ne flashez pas un appareil sur la seule base d'une compilation réussie ou d'un cadrage UF2 valide. Aucune compatibilité avec d'autres cartes, aucun nouveau test matériel et aucune distribution de binaire firmware ne sont revendiqués ici. La référence physique figée v5.2 n'a pas été modifiée.
Le projet est né d'une question pratique : une carte de développement bon marché peut-elle devenir une clé de sécurité physique utilisable pour une véritable connexion WebAuthn, sans masquer les compromis d'ingénierie ?
Le travail intéressant s'est avéré ne pas être simplement de faire tourner FIDO2 sur RP2040. Les parties les plus difficiles ont été l'identité de l'authentificateur, la présence physique de l'utilisateur, l'attestation, le comportement sous Windows, la reproductibilité des modifications du code source, l'interopérabilité avec les relying parties, et la connaissance exacte de ce que les preuves démontrent — et ne démontrent pas.
Les résultats de cette section ont été obtenus avec l'appareil v5.2 préservé et ne doivent pas être attribués à des sources ou à des compilations de firmware expérimentales ultérieures. Voir docs/validation-evidence.md pour le SHA-256 du UF2 figé et les limites des tests.
MicrosoftCtapHidProvider.U2fProtocol=false.Le résultat Entra est un résultat d'interopérabilité, et non une certification Microsoft ni une reconnaissance mondiale de l'authentificateur. Voir docs/interoperability-case-study.md pour la limite exacte.
Le durcissement actuel HID/APDU/OTP est suivi dans la Draft PR #7. Elle inclut un chemin d'intégration du SDK basé sur des patchs, des tests de régression côté hôte et des preuves de build ARM isolées en local. Ces vérifications ne constituent pas un test sur appareil réel, un test complet de conformité FIDO, une certification ni une version de production. GitHub Actions exécute les tests hôte/source et les vérifications de publication ; les builds ARM complets ont été vérifiés en local, pas dans GitHub Actions.
La branche main et sa build de référence n'incluent pas automatiquement les patchs v5.3 non fusionnés. Pour les preuves expérimentales actuelles et les blocages en suspens, utilisez la PR #7 plutôt que de considérer les hachages UF2 historiques ou des tests individuels réussis comme l'état matériel le plus récent. Aucun binaire de firmware issu de ce travail n'est proposé au téléchargement ou au flashage.
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"]
Le runtime validé est volontairement restreint : FIDO HID constitue l'interface de clé de sécurité ; les interfaces runtime non liées de type clavier/CCID ne font pas partie du profil de référence KL.
maingit 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