karaaslanlabs/kl-security-keyAutenticatore FIDO2/WebAuthn sperimentale basato su RP2040 con attestazione packed e interoperabilità documentata con Windows/Entra
Progetto sperimentale open-source di ingegneria e interoperabilità per un autenticatore FIDO2/WebAuthn su RP2040, a cura di Karaaslan Labs.
Stato: progetto di ingegneria/ricerca. Non certificato FIDO Alliance. Non è un token di sicurezza commerciale ad alta affidabilità.
Perimetro delle evidenze: le osservazioni sul dispositivo reale riportate di seguito appartengono alla versione congelata v5.2. Il lavoro di hardening della v5.3 è esclusivamente off-device e non è stato installato né verificato sul riferimento fisico.
KL Security Key è un derivato curato di polhenarejos/pico-fido. Esplora fin dove può essere spinta una scheda RP2040 a basso costo come autenticatore WebAuthn fisico, mantenendo espliciti identità, attestazione, evidenze di validazione e confini di fiducia.
| Area | Riferimento fisico congelato v5.2 |
|---|---|
| Hardware | Scheda di sviluppo USB RP2040 |
| Trasporto | USB FIDO HID |
| Versioni CTAP/GetInfo | FIDO_2_0, FIDO_2_1, FIDO_2_3 |
| Presenza / verifica utente | Pulsante fisico + supporto PIN/UV |
| Attestazione | Packed ES256, x5c, certificato specifico del dispositivo |
| AAGUID | d9359dc7-6938-5822-b951-006507247d8f |
| Interoperabilità | Windows WebAuthn + validazione Microsoft Entra locale al tenant |
| Distribuzione | Source-first; nessuna release di binario firmware KL |
| Elemento sicuro | Nessuno |
| Certificazione | Non certificato FIDO Alliance |
La build di riferimento del sorgente main seleziona -DPICO_BOARD=pico in scripts/build-kl-reference.sh, puntando alla configurazione standard della scheda Raspberry Pi Pico con 2 MiB di flash esterna. Anche il builder isolato off-device della v5.3 seleziona -DPICO_BOARD=pico; il suo validatore dell'output UF2 verifica la finestra di indirizzi della flash da 2 MiB della Pico. Questi sono vincoli di sorgente/build, non una validazione fisica di ogni scheda RP2040.
Altre schede RP2040 possono avere capacità di flash o configurazioni hardware differenti. La issue upstream di Pico FIDO #278 documenta un fallimento alla prima operazione WebAuthn su una scheda con flash più grande, quando il limite di flash impostato in fase di compilazione nel firmware non corrispondeva al layout a runtime. Tale riscontro upstream non è un guasto riprodotto di KL Security Key, ma illustra perché la sola corrispondenza del chip RP2040 non sia una prova sufficiente di compatibilità.
Non dare per scontato che il firmware di riferimento KL funzioni su schede RP2040 arbitrarie, né eseguire il flashing di un dispositivo basandosi unicamente su una build riuscita o su un framing UF2 valido. Qui non si rivendica alcuna compatibilità con schede alternative, alcun nuovo test hardware né alcuna distribuzione di binari firmware. Il riferimento fisico congelato v5.2 non è stato modificato.
Il progetto è nato da una domanda pratica: una scheda di sviluppo economica può diventare una chiave di sicurezza fisica utilizzabile per l'accesso WebAuthn reale, senza nascondere i compromessi ingegneristici?
Il lavoro interessante si è rivelato non semplicemente far girare FIDO2 su RP2040. Le parti più difficili sono state l'identità dell'autenticatore, la presenza fisica dell'utente, l'attestazione, il comportamento su Windows, le modifiche riproducibili al sorgente, l'interoperabilità con le relying party e il sapere esattamente cosa le evidenze dimostrano — e cosa non dimostrano.
I risultati in questa sezione sono stati ottenuti con il dispositivo v5.2 preservato e non devono essere attribuiti a sorgenti successivi o a build firmware sperimentali. Consultare docs/validation-evidence.md per l'SHA-256 dell'UF2 congelato e i confini dei test.
MicrosoftCtapHidProvider.U2fProtocol=false.Il risultato Entra è un risultato di interoperabilità, non una certificazione Microsoft né un riconoscimento globale dell'autenticatore. Consultare docs/interoperability-case-study.md per i limiti esatti.
L'attuale hardening HID/APDU/OTP è tracciato nella Draft PR #7. Include un percorso di integrazione SDK basato su patch, test di regressione lato host ed evidenze di build ARM isolate locali. Queste verifiche non costituiscono un test su dispositivo reale, un test completo di conformità FIDO, una certificazione o un rilascio in produzione. GitHub Actions esegue test host/sorgente e controlli di pubblicazione; le build ARM complete sono state verificate localmente, non in GitHub Actions.
Il branch main e la sua build di riferimento non includono automaticamente le patch v5.3 non unite. Per le evidenze sperimentali attuali e i blocchi in sospeso, utilizzare la PR #7 anziché considerare gli hash UF2 storici o i singoli test superati come stato hardware più recente. Nessun binario firmware derivante da questo lavoro è offerto per il download o il flashing.
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"]
Il runtime validato è intenzionalmente ristretto: FIDO HID è l'interfaccia della chiave di sicurezza; le interfacce runtime non correlate in stile tastiera/CCID non fanno parte del profilo di riferimento 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
La build main abilita l'applicazione della presenza fisica dell'utente, il profilo runtime FIDO-only e il percorso di attestazione packed; non è una build delle modifiche v5.3 non ancora unite. Il materiale valido per chiave/certificato di attestazione deve essere fornito separatamente; le chiavi di attestazione private non sono pubblicate né fornite automaticamente da questo repository. Compilare un UF2 non autorizza a flashare un dispositivo.
Questo repository non dichiara: