La llave que se autodestruye: discos cifrados y reboots desatendidos

📻 Versión en audio: si prefieres escuchar en vez de leer, el resumen del artículo está justo aquí arriba.

Cifrar discos y reiniciar sin que nadie vaya a presionar una tecla

Si mantienes servidores propios, conoces la transacción: el disco cifrado te protege contra el robo físico, pero se la cobra en cada reboot. Sin manos en la consola, el equipo arranca y queda pegado esperando la passphrase. La salida fácil — guardar la llave en un archivo dentro de la misma máquina, como la opción keylocation de ZFS o la mayoría de los setup LUKS — recupera la comodidad, pero mata el propósito: el ladrón no rompe la criptografía, simplemente se lleva la caja completa con la llave adentro. El candado queda siempre a la vista de quien tiene la puerta.

La idea: un interruptor de hombre muerto para tus llaves

Esta semana Julio Merino, que lleva años escribiendo sobre sistemas operativos en su blog, lanzó ZKeys, un servicio que ataca el dilema con un giro simple: la llave vive fuera del servidor. La máquina la baja al arrancar y, después, mantiene su copia viva enviando keepalives periódicos. Si el servicio deja de recibir pings por un rato largo — porque alguien la desconectó para llevársela, por ejemplo — la llave se bloquea sola. Es un literal dead-man switch: cuando el servidor deja de latir, la llave muere con él.

Los detalles del diseño tienen su gracia. En el servicio solo vive una mitad de la passphrase; la otra queda en la máquina que la usa, así que comprometer al proveedor no da nada reconstruible. Además, la llave viaja cifrada y el password de descarga solo pasa por la memoria del backend unos segundos. El costo de todo esto lo declaran sin maquillaje: si pierdes el password o el servicio muere, no hay rescate. Respaldar la llave completa en un tercer lugar físico no es opcional, es parte del contrato.

Mi lectura: el modelo de amenaza cambia con el hardware

Mi primera reacción fue entusiasmo a medias. La idea es bacán, pero en mi mundo de VPS el modelo de amenaza es distinto: el que eventualmente puede leer la memoria RAM de tus procesos no es un ladrón en tu living, es el proveedor, y ninguna llave remota te protege de eso. El caso de uso genuino es el hardware propio — el NAS con las fotos de la familia, la laptop que viaja en el bolso, el server apilado en un rack que puede desaparecer entero en un traslado.

¿Lo usaría tal cual? No. La cadena de arranque del disco es el peor lugar posible para una dependencia frágil, y esto es exactamente eso: un keepalive crítico confiado a un servicio gratuito mantenido por una persona sola, con dos instancias sin replicación — él mismo admite que la europea tiene cortes de energía seguidos. Un corte de red de 24 horas en Chile sucede mucho más seguido que un robo a una casa con alarma, y el escenario inverso es real: cae la luz, se corta el internet, el UPS rinde y la máquina rebootea sola cuando vuelve el cable… pero la llave ya está bloqueada. Tu NAS queda fuera de combate por días, esperando que alguien llegue con el password.

La versión DIY vale más que el servicio

Lo mío sería replicar el patrón con lo que ya tengo a mano: LUKS, la llave partida en dos, y el keepalive apuntando a mi propia infraestructura, con un umbral de bloqueo generoso y alertas cuando el servicio deje de ver pings. La idea de ZKeys vale más que el ZKeys mismo: el patrón del dead-man switch se arma en una tarde, eso sí, con el mismo pacto incómodo — respaldo físico de la llave en un tercer lugar, o no jugar. La pregunta correcta en cada server no es «¿puedo cifrarlo y que igual arranque solo?», sino «¿qué le pasa al disco si la red se muere 24 horas?«. Eso no lo responde la criptografía; lo responde la arquitectura.

Fuente del tema: Unattended reboots with encrypted disks de Julio Merino.

Fuente de inspiración: Unattended reboots with encrypted disks – by Julio Merino