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.
KL Security Key es un derivado curado de polhenarejos/pico-fido. Explora hasta dónde se puede llevar una placa RP2040 de bajo costo 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 de ingeniería actual |
|---|---|
| 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 | Windows WebAuthn + validación local de inquilino de Microsoft Entra |
| Distribución | Enfoque en código fuente; sin lanzamiento de binario de firmware KL |
| Elemento seguro | Ninguno |
| Certificación | No certificado por la FIDO Alliance |
El proyecto comenzó con una pregunta práctica: ¿puede una placa de desarrollo económica convertirse en una llave 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 el RP2040 ejecute FIDO2. Las partes más difíciles fueron la identidad del autenticador, la presencia física del usuario, la atestación, el comportamiento de Windows, los cambios de código fuente reproducibles, la interoperabilidad con las partes confiables y saber exactamente qué prueba la evidencia —y qué no prueba—.
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.
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 KL.
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
La compilación habilita la aplicación de la presencia física del usuario, el perfil de ejecución solo FIDO y la ruta de atestación Packed. El material válido de clave/certificado de atestación debe aprovisionarse por separado; las claves privadas de atestación no se publican ni se aprovisionan automáticamente por este repositorio.
Este repositorio no declara:
Lea THREAT-MODEL.md antes de tratar la referencia como algo más allá de un autenticador de ingeniería/investigación.
| Documento | Propósito |
|---|---|
docs/architecture.md | Perfil de ejecución, estructura del código fuente y límites de ingeniería |
docs/attestation-and-pki.md | AAGUID, atestación Packed y modelo de PKI |
docs/validation-evidence.md | Evidencia de validación de referencia física y código fuente curado |
docs/interoperability-case-study.md | Evidencia y límites de interoperabilidad con partes confiables / Microsoft Entra |
docs/windows-webauthn-debugging.md | Flujo de trabajo de depuración de Windows/WebAuthn basado en evidencia |
THREAT-MODEL.md | Modelo de amenazas y no declaraciones de seguridad |
UPSTREAM.md | Procedencia upstream y cambios derivados |
SECURITY.md | Reporte de vulnerabilidades y política de seguridad |
El submódulo pico-keys-sdk está fijado a un commit upstream conocido. Los cambios específicos de KL en el SDK se aplican mediante scripts/apply-sdk-overlay.py, que está fijado a un commit exacto y falla de forma segura ante un estado del código fuente inesperado.
Este repositorio público está intencionalmente curado en torno a la ruta de referencia de KL Security Key. Los artefactos de investigación heredados no relacionados y los ayudantes de lanzamiento heredados no forman parte de la superficie publicada de KL; la procedencia upstream permanece documentada en UPSTREAM.md y en el historial de Git.
La distribución binaria intencionalmente no es el objetivo de publicación inicial mientras los requisitos de identidad/distribución USB sigan sin resolverse. El código fuente, la documentación y la metodología de validación son los artefactos principales.