# Hoja de ruta Tres cosas, en este orden: por dónde va cada parte del proyecto y qué lo demuestra, qué queda y por qué tiene que ocurrir en el orden en que aparece, y qué he descartado. En esta página no hay fechas. No anuncio ninguna, porque una fecha es lo primero que deja de ser verdad en una hoja de ruta, y porque esto lo hago yo solo: cualquier fecha que te diera sería una suposición con una tipografía bonita. En esta página 1. [Estado](https://kleidos.dev/#status) 2. [Lo siguiente](https://kleidos.dev/#next) 3. [Descartado](https://kleidos.dev/#dropped) ## Por dónde va el proyecto Todo, con honestidad: lo que funciona, lo que se está construyendo y lo que no se ha empezado. Cada fila dice qué lo demuestra. Funciona ### Un firmware, nueve placas Cada placa registra su propio hardware (la pantalla, el controlador de alimentación, los botones o el teclado) en el mismo firmware, y los dibujos de «Los dispositivos» se generan a partir de las medidas de esas mismas placas (src/boards/). Funciona ### La bóveda cifrada en el dispositivo Las entradas se guardan como registros cifrados y autenticados, con claves distintas para cifrar, autenticar y comprobar el desbloqueo, y la batería de pruebas que corre en el ordenador cubre el ciclo completo y los rechazos (src/vault/). Funciona ### El desbloqueo, con cada tipo de entrada Las placas de dos botones aceptan un PIN marcado con el arco temporizado, las que tienen teclado aceptan una contraseña, y las táctiles ofrecen cualquiera de los dos (src/ui/entry/). Funciona ### Escribir por Bluetooth El dispositivo se convierte en un teclado Bluetooth durante la sesión que se le ordena abrir, escribe por un enlace vinculado y autenticado, y vuelve a apagar la radio cuando la sesión termina (src/ble/). Funciona ### Actualizar el firmware desde el navegador En las placas con sitio para dos particiones de aplicación, el firmware se sube desde el panel de administración; una imagen compilada para otra placa, o de una versión anterior, se rechaza, y una actualización que arranca pero nunca se confirma vuelve atrás por sí sola (src/platform/ota.cpp). En construcción ### El panel de administración En desarrollo. Ya es donde se añaden entradas, se importan de otro gestor y se exportan como copia de seguridad cifrada, y sigue cambiando (src/web/). En construcción ### La compilación endurecida En desarrollo. Secure Boot, el cifrado de la flash y los ajustes cifrados están configurados para las placas de 8 MB; en las de ESP32-S3 la clave propia del chip la graba un paso que ya existe y que todavía no he ejecutado en ninguna placa (docs/security/secure-provisioning-checklist.md). Sin empezar ### El consumo, medido en la batería Las cifras con la placa despierta salen de su propio controlador de alimentación y están en la página de mediciones; las de reposo siguen siendo estimaciones. No he hecho las medidas de banco que las cambiarían por lecturas de un polímetro (docs/testing/production-sleep-checklist.md). Sin empezar ### La tirada larga de principio a fin Los criterios de publicación piden 50 ciclos completos (arrancar, desbloquear, navegar, escribir, dormir) sin un cuelgue. No los he hecho, y tampoco he marcado ninguna otra casilla de esa lista (docs/QA_CHECKLIST.md). Sin empezar ### La primera publicación Todavía no hay nada que instalar: el firmware va por la versión 0.1.0, no hay ninguna publicación, y la página Resumen dice «Próximamente» porque es así (version.txt). Sin empezar ### Grabar una placa desde el navegador La página que instalaría el firmware por USB desde un navegador está escrita y aparcada: no tiene ninguna publicación que ofrecer, así que este sitio no publica nada en la dirección de esa página, y su propio manifiesto no lista ninguna compilación (web/). Sin empezar ### Una revisión de alguien de fuera No he encargado a nadie de fuera del proyecto que revise el firmware ni la criptografía. El expediente por el que empezaría un auditor está escrito y esperando (docs/security/audit-dossier.md). No pongo fechas. Esta lista solo nombra trabajo que existe en el repositorio, y un paso que nada de lo que hay allí pueda demostrar figura como sin empezar. ## Qué viene ahora, y por qué en ese orden Quedan ocho pasos. El orden es la parte con la que merece la pena discrepar: cada uno dice qué no puede empezar hasta que esté hecho. ### Paso 1. Terminar el panel de administración El panel del navegador es la forma de llenar una bóveda. Son nueve placas y solo tres tienen teclado: en las otras seis, teclear una contraseña a mano en el propio dispositivo no es una manera realista de añadirla. El panel funciona; no está terminado. #### Qué espera a esto Cualquier cosa que alguien llamara una primera versión. No tiene sentido publicar una bóveda a la que cueste meter algo. src/web/ ### Paso 2. Que la compilación endurecida pueda crear una bóveda La compilación endurecida es la que lleva arranque verificado, flash cifrada y la clave que sale del PIN mezclada con un secreto que solo tiene ese dispositivo, que es lo que deja sin sentido probar PIN tras PIN fuera del dispositivo. En las placas de ESP32 clásico ese secreto es un valor aleatorio guardado en los ajustes cifrados; en las placas ESP32-S3 es una clave en los fusibles del chip, que se graba desde el ordenador en un paso aparte, antes del primer arranque endurecido, y la subida se niega a seguir sin ella. El paso ya existe, pero ninguna placa ha pasado todavía por él. #### Qué espera a esto Todo lo que la página de seguridad dice que hace la compilación endurecida. Ahora mismo la compilación más fuerte es la que no puedo darle a nadie. docs/security/secure-provisioning-checklist.md ### Paso 3. Abrir el repositorio Está privado mientras preparo la primera versión. Antes hay que repasar el historial, y hay que decidir con qué licencia entra una contribución ajena: eso tiene que quedar resuelto antes de integrar la primera, no después. #### Qué espera a esto La página de seguridad, que te pide creer veinte amenazas y cuarenta y cinco controles que no puedes leer. Y la revisión del final de esta lista, porque nadie audita lo que no puede abrir. CONTRIBUTING.md ### Paso 4. Medir el consumo en la propia batería Todas las cifras de sueño que publica el proyecto son estimaciones. Las de estado despierto son reales (salen del controlador de alimentación de la propia placa, con su propia batería), pero el dispositivo no puede medirse el sueño a sí mismo en un tiempo útil: hace falta un polímetro, un banco y una tarde. #### Qué espera a esto Cualquier cifra de autonomía. Hoy la página de mediciones no da ninguna y dice por qué en cada fila. docs/testing/production-sleep-checklist.md ### Paso 5. Pasar los cincuenta ciclos Cincuenta ciclos completos de desbloquear y escribir, en cada placa, sin un cuelgue. Hay partes automatizadas; el conjunto no lo he ejecutado nunca. #### Qué espera a esto La publicación. Un firmware que no se ha dejado funcionando un día entero es un firmware cuyo primer día largo ocurre en la mesa de otro. docs/QA_CHECKLIST.md ### Paso 6. Publicar la primera versión Un número de versión, una etiqueta y una imagen por placa. Hoy no existe nada que descargar, y esa es la primera línea de la lista de límites del resumen. #### Qué espera a esto El instalador de abajo, que no tiene nada que servir mientras esto no exista. version.txt ### Paso 7. Publicar el instalador del navegador Una página que graba una placa por USB desde el navegador, sin instalar ninguna herramienta. Está escrita y aparcada en el repositorio, apuntando a una versión que no existe. #### Qué espera a esto Que lo use alguien que no sea yo. Para eso está. web/ ### Paso 8. Que lo lea alguien de fuera El modelo de amenazas, la matriz de controles y el registro de dependencias los ha escrito aquí la misma persona que escribió el código que describen. Eso vale algo, y no es una revisión. #### Qué espera a esto Nada, y va al final a propósito: auditar un blanco en movimiento es no auditar nada, así que espera a que los pasos de arriba dejen de moverlo. docs/security/audit-dossier.md Nada de esto es un compromiso de fechas. La lista de arriba es donde un paso cambia de estado, y el feed publica el cambio el día que lo escribo. ## Lo que he descartado Una lista de todo lo que a alguien le gustaría no es un plan; un plan es también la forma de lo que deja fuera. Estas son nueve cosas que este proyecto no va a hacer, cada una con el motivo escrito donde podrías comprobarlo, y cuatro de ellas resueltas por una medición y no por gusto. ### Una derivación de clave costosa en memoria Argon2id o scrypt en lugar de PBKDF2. Medido frente a las cifras publicadas de una tarjeta gráfica actual: scrypt, con la memoria que tienen estos chips, acelera al atacante en vez de frenarlo. La mejor configuración de Argon2id que cabría en un ESP32-S3 multiplica el coste aproximadamente por cinco, y a cambio pide una primitiva costosa en memoria escrita a mano y fuera de la API criptográfica de la plataforma, una derivación distinta en las placas sin RAM externa, y material derivado de la clave que vive en una memoria a la que se le puede poner una sonda. Dos cifras más de PIN lo multiplican por cien. docs/research/kdf-performance.md ### Las 600 000 iteraciones que recomienda OWASP Para el desbloqueo son unos 5,3 segundos en las placas ESP32-S3 y 24 en las de ESP32 clásico. El desbloqueo está dimensionado a unos dos segundos: 175 000 iteraciones y 40.000. El fichero de copia de seguridad sí usa 600 000, porque nadie se queda delante del dispositivo esperando a que acabe una copia. docs/research/kdf-performance.md ### Claves de acceso por Bluetooth o por la red Alguien lo pidió, y lo investigué antes de contestar. El transporte Bluetooth para llaves de seguridad solo existe en Windows, necesita su propio emparejamiento del sistema operativo y arrastra informes sin resolver de que no funciona; Chromium dejó de admitirlo en 2020. Ningún navegador ni ningún sistema operativo llega a un autenticador por la red local. El único camino que funciona en todos los equipos es USB, y solo podrían ofrecerlo las cuatro placas ESP32-S3: sería una función de portada que cinco de las nueve placas no tienen. docs/research/passkeys-feasibility.md ### Corregir el reloj Tres placas no llevan chip de reloj y mantienen la hora durante un sueño con un oscilador interno. En 66 sueños medidos, el error fue de 6033 partes por millón de retraso a 2300 de adelanto; cada chip arrastra su propio desvío y la temperatura del propio chip mueve el error más que nada. Ninguna corrección que se ajuste a esa dispersión mantendría un código de un solo uso dentro de su margen de un paso, así que no se aplica ninguna: en esas placas, un código pide una sincronización nueva. docs/research/slow-clock-sleep-matrix.md ### Un contador en hardware para los intentos fallidos Haría imposible hacer retroceder el contador de PIN fallidos restaurando una imagen antigua de la flash. Los contadores de programación única del chip admiten un puñado de escrituras en toda la vida de la pieza, y este valor se reescribe en cada PIN equivocado. Está anotado como riesgo aceptado, no como función pendiente. docs/security/audit-dossier.md ### Arranque verificado en las placas de 4 MB Dos ranuras de actualización y un gestor de arranque firmado no caben en 4 MB de flash. Tres placas (el Plus 1.1, el Plus SE y el CoreInk) se regraban enteras, y la rejilla de dispositivos del resumen dice qué placas tienen compilación endurecida y cuáles no. docs/variants.md ### Un volcado de fallo en una compilación que se publica Es la forma obvia de averiguar por qué se ha reiniciado un dispositivo. Un volcado de fallo es una copia de las pilas de las tareas, y en el instante del fallo esas pilas pueden contener el PIN y la clave de la bóveda. Las compilaciones de desarrollo lo llevan; ninguna de producción ni endurecida lo activa, y una comprobación de la compilación falla si alguna empieza a hacerlo. docs/security/serial-silence-and-crash-records.md ### Las bibliotecas ya hechas para el hardware Nueve placas y dos familias de chip se compilan desde un solo árbol de fuentes, sin core de Arduino dentro. Cada pantalla, cada controlador de alimentación, cada chip de reloj, cada sensor de movimiento, cada panel táctil y cada teclado funciona con un driver escrito en este repositorio, y la biblioteca gráfica que usa todo el ecosistema de aficionados se retiró de la flota entera, incluida la única placa para la que seguía dibujando. src/drivers/ ### Una política de seguridad de contenido en este sitio Esta página no tiene inicio de sesión, ni entrada de datos, ni sesión: una política no tendría nada que proteger, y el elemento que la declara es justo lo que impide que funcione la protección antibots del alojamiento. Lo que sobrevivió a su retirada es la regla con la que se la confundía: ni script en línea, ni estilo en línea, ni manejadores de eventos en el marcado, y nada de esta página cargado desde otro sitio. El guardián rechaza un despliegue que incumpla cualquiera de esas cuatro. scripts/site/check_publish.py Cualquiera de estas se puede reabrir con un argumento mejor que el que la cerró. Para eso están los motivos.