El problema fundamental de la identidad IoT
Los dispositivos IoT necesitan autenticarse, pero dependen de secretos almacenados en memoria flash o EEPROM. Un atacante con acceso físico al dispositivo puede extraer esas credenciales y clonar el nodo. Sin identidad verificable, cada dispositivo en la red es un punto de falla potencial.
Hay un segundo problema que pocos consideran: la criptografía asimétrica actual (RSA, ECDSA) será vulnerable cuando existan computadoras cuánticas suficientemente potentes. Los estándares post-cuánticos de NIST (FIPS 203, 204) ya están publicados pero apenas se adoptan en IoT embebido.
La pregunta de fondo: ¿es posible crear una identidad que dependa de lo que el dispositivo es, no de lo que almacena, y que resista tanto la extracción física como la computación cuántica?
SRAM-PUF: la huella digital del silicio
PUF significa Physical Unclonable Function: una función física que no se puede clonar. La idea es explotar las variaciones microscópicas del proceso de fabricación del silicio.
Cuando un chip ESP32 se enciende, los bits de su SRAM estática se inicializan en un patrón que depende de la física de cada transistor individual. Este patrón es:
- Único: Dos chips del mismo lote tienen patrones diferentes
- Reproducible: El mismo chip produce un patrón similar cada vez que se enciende
- No clonable: Las variaciones son resultado del proceso de fabricación, no de datos almacenados
Cómo se mide
El proceso de enrollment en nuestro framework usa el ESP32 en modo deep sleep para capturar el patrón SRAM en cada arranque. El firmware soporta dos perfiles de medición:
- Básico: 200 mediciones (~5 min de enrollment)
- Strong: 1,000 mediciones (~25 min, mayor estabilidad)
Después de N mediciones, se generan códigos de corrección de errores (helper data) que estabilizan la respuesta PUF entre reinicios. De la respuesta estable se deriva un device ID de 64 bytes via SHA-512.
// Lectura de SRAM raw en ESP32 (simplificado)
uint8_t sram_snapshot[SRAM_SIZE];
memcpy(sram_snapshot, (void*)SRAM_BASE_ADDR, SRAM_SIZE);La ventaja fundamental: la identidad PUF no se puede extraer como un archivo, no se puede copiar a otro chip, y no existe en ninguna parte excepto en la física del dispositivo mismo.
Criptografía post-cuántica: preparando el futuro
Una huella PUF sin firma criptográfica es solo un número. Para que sea una identidad verificable, necesitamos firmarla. Pero las firmas tradicionales (RSA, ECDSA) serán vulnerables cuando existan computadoras cuánticas suficientemente potentes.
Por eso usamos algoritmos post-cuánticos estandarizados por NIST:
- ML-DSA-87 / Dilithium-5 (FIPS 204): Para firmas digitales. El dispositivo firma su identidad con ML-DSA, y cualquier verificador puede validar la firma sin necesidad de compartir secretos. Nivel de seguridad NIST 5 (el máximo).
- ML-KEM-768 / Kyber-768 (FIPS 203): Para intercambio de claves. Permite establecer un canal seguro entre dispositivo y servidor sin que un atacante cuántico pueda descifrar la comunicación.
ML-DSA-87 en ESP32: benchmarks reales
Integramos mldsa-native (PQCA, Apache/ISC/MIT) como componente ESP-IDF con adaptaciones para el ESP32: reducción de RAM interna, redirección de buffers grandes (~62 KB) al heap (el main task del ESP32 solo tiene 12 KB de stack), y uso de esp_fill_random() para entropía por hardware.
Benchmark sobre 10,000 iteraciones en ESP32-WROOM-32D v3.1 @ 240 MHz:
| Operación | Promedio | Desv. Est. | Mín | Máx |
|---|---|---|---|---|
| Keygen | 41.09 ms | 0.15 ms | 40 ms | 42 ms |
| Sign | 185.17 ms | 146.63 ms | 57 ms | 1,516 ms |
| Verify | 42.00 ms | 0.01 ms | 41 ms | 42 ms |
La varianza alta en signing es esperada: FIPS 204 usa rejection sampling, donde cada intento de firma puede requerir múltiples iteraciones internas. Keygen y verify son determinísticos y estables.
Ledger auditable anclado a Bitcoin
La tercera capa usa un Centralized Ledger Database (CLD), inspirado en LedgerDB (Yang et al., PVLDB 2020), como registro criptográficamente verificable de identidades. A diferencia de una blockchain completa, el CLD es un ledger centralizado pero auditable:
- Journal append-only con cadena de hashes: cada operación incluye el hash de la anterior, garantizando integridad secuencial
- Árboles Merkle por lote: permiten pruebas de inclusión y consistencia eficientes
- Protocolo de doble firma (non-repudiation): el dispositivo firma con ML-DSA, el servidor firma el recibo. Ninguna parte puede negar la transacción
Para eliminar la necesidad de confiar en el servidor, los Merkle roots se anclan periódicamente a Bitcoin via OpenTimestamps. Cualquier auditor externo puede verificar la integridad de los registros sin depender del servidor: solo necesita el Merkle root y el timestamp en la blockchain de Bitcoin.
Estado actual del framework
| Componente | Estado |
|---|---|
| SRAM-PUF enrollment | Funcional |
| Firmware root of trust + Step 0 | Funcional |
| ML-DSA-87 (firmas post-cuánticas) | Funcional (benchmark, pendiente integración) |
| Web flasher (provisioning via Chrome) | Funcional |
| Almacenamiento cifrado (AES-256-CBC + HMAC-SHA512) | Funcional |
| AKE Steps 1-4 (autenticación mutua completa) | En desarrollo |
| CLD: journal, Merkle, non-repudiation | En desarrollo |
| OpenTimestamps (anclaje a Bitcoin) | Pendiente |
Resultado
Un framework de identidad de 3 capas con componentes funcionales validados experimentalmente. El dispositivo se autentica por lo que es (su silicio), no por lo que almacena (una clave que puede ser extraída). Resistente tanto a extracción física como a computación cuántica.
La investigación continúa en el INAOE como parte de mi trabajo de maestría. El código fuente está disponible en GitHub.