karaaslanlabs/kl-security-keyAutenticador experimental FIDO2/WebAuthn para RP2040 con atestación empaquetada e interoperabilidad documentada con Windows/Entra
Proyecto experimental de ingeniería e interoperabilidad de autenticador FIDO2/WebAuthn RP2040 de código abierto por Karaaslan Labs.
Estado: proyecto de ingeniería/investigación. No certificado por la FIDO Alliance. No es un token de seguridad comercial de alta garantía.
Límite de la evidencia: las observaciones en dispositivo real a continuación pertenecen a la v5.2 congelada. El trabajo de endurecimiento de la v5.3 es únicamente fuera de dispositivo y no ha sido instalado ni verificado en la referencia física.
KL Security Key es un derivado curado de polhenarejos/pico-fido. Explora hasta dónde se puede llevar una placa RP2040 de bajo coste como autenticador WebAuthn físico, manteniendo explícitos la identidad, la atestación, la evidencia de validación y los límites de confianza.
| Área | Referencia física congelada v5.2 |
|---|---|
| Hardware | Placa de desarrollo USB RP2040 |
| Transporte | USB FIDO HID |
| Versiones CTAP/GetInfo | FIDO_2_0, FIDO_2_1, FIDO_2_3 |
| Presencia / verificación del usuario | Botón físico + soporte PIN/UV |
| Atestación | Packed ES256, x5c, certificado específico del dispositivo |
| AAGUID | d9359dc7-6938-5822-b951-006507247d8f |
| Interoperabilidad | WebAuthn de Windows + validación local del tenant de Microsoft Entra |
| Distribución | Prioridad al código fuente; sin publicación de binario de firmware KL |
| Elemento seguro | Ninguno |
| Certificación | No certificado por la FIDO Alliance |
La compilación de referencia del código fuente de main selecciona -DPICO_BOARD=pico en scripts/build-kl-reference.sh, apuntando a la configuración estándar de la placa Raspberry Pi Pico con 2 MiB de flash externa. El compilador aislado fuera de dispositivo de la v5.3 también selecciona -DPICO_BOARD=pico; su validador de salida UF2 comprueba la ventana de direcciones de flash de 2 MiB de la Pico. Estas son restricciones de código fuente/compilación, no una validación física de cada placa RP2040.
Otras placas RP2040 pueden tener distinta capacidad de flash o configuración de placa. El issue #278 del Pico FIDO original documenta un fallo en la primera operación WebAuthn en una placa con mayor flash cuando el límite de flash en tiempo de compilación del firmware no coincidía con su distribución en tiempo de ejecución. Ese hallazgo del proyecto original no es un fallo reproducido de KL Security Key, pero ilustra por qué coincidir solo en el chip RP2040 no es evidencia suficiente de compatibilidad.
No asuma que el firmware de referencia KL funciona en placas RP2040 arbitrarias, ni flashee un dispositivo basándose únicamente en una compilación exitosa o en un encapsulado UF2 válido. Aquí no se afirma compatibilidad con placas alternativas, ni nuevas pruebas de hardware, ni distribución de binarios de firmware. La referencia física congelada v5.2 no ha sido modificada.
El proyecto comenzó con una pregunta práctica: ¿puede una placa de desarrollo económica convertirse en una clave de seguridad física utilizable para el inicio de sesión WebAuthn real, sin ocultar los compromisos de ingeniería?
El trabajo interesante resultó no ser simplemente hacer que la RP2040 ejecutara FIDO2. Las partes más difíciles fueron la identidad del autenticador, la presencia física del usuario, la atestación, el comportamiento en Windows, los cambios de código fuente reproducibles, la interoperabilidad con las partes de confianza y saber exactamente qué demuestra la evidencia —y qué no—.
Los resultados de esta sección se obtuvieron con el dispositivo v5.2 preservado y no deben atribuirse a compilaciones posteriores del código fuente ni a firmware experimental. Consulte docs/validation-evidence.md para el SHA-256 del UF2 congelado y los límites de las pruebas.
MicrosoftCtapHidProvider.U2fProtocol=false.El resultado de Entra es un resultado de interoperabilidad, no una certificación de Microsoft ni un reconocimiento global del autenticador. Consulte docs/interoperability-case-study.md para conocer el límite exacto.
El endurecimiento actual de HID/APDU/OTP se rastrea en el Draft PR #7. Incluye una ruta de integración del SDK basada en parches, pruebas de regresión del lado del host y evidencia de compilación ARM aislada local. Estas comprobaciones no son una prueba en dispositivo real, una prueba completa de conformidad FIDO, una certificación ni una versión de producción. GitHub Actions ejecuta pruebas de host/fuente y comprobaciones de publicación; las compilaciones ARM completas se han verificado localmente, no en GitHub Actions.
La rama main y su compilación de referencia no incluyen automáticamente los parches de v5.3 sin fusionar. Para obtener la evidencia experimental actual y los bloqueos pendientes, utilice el PR #7 en lugar de tratar los hashes UF2 históricos o las pruebas individuales superadas como el estado más reciente del hardware. Ningún binario de firmware de este trabajo se ofrece para descarga o flasheo.
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"]
El entorno de ejecución validado es intencionalmente limitado: FIDO HID es la interfaz de la llave de seguridad; las interfaces de ejecución no relacionadas de estilo teclado/CCID no forman parte del perfil de referencia de 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