Fondo
Estoy desarrollando un servicio que consiste en un pequeño dispositivo cliente sin cabeza (por ejemplo, OLinuXino) que contendrá datos confidenciales.
El dispositivo se conectará a una red remota (quizás detrás de un firewall) y su objetivo es abrir un túnel ssh inverso a un servidor automáticamente (es decir, desatendido).
El dispositivo contendrá una clave para conectarse al servidor ssh, y esa clave no debe usarse en otro dispositivo.
El dispositivo se distribuirá a los clientes para que cualquiera pueda tener acceso físico a él.
No quiero que nadie pueda obtener los datos de un dispositivo determinado y mi objetivo es ralentizar la recuperación de datos confidenciales.
Al menos, si sucede, me gustaría que el servidor lo detecte y bloquee cualquier acceso adicional mediante la clave de ese dispositivo dado. En realidad, si alguien intenta hacer algo desagradable con el dispositivo, definitivamente podría bloquear su acceso (y poner en la lista negra a esa persona o compañía).
El dispositivo es una pequeña máquina Linux (que ejecuta Debian Wheezy). No planeo usar un chip resistente al amortiguador por ahora (como se describe aquí )
Aviso
Ya escuché acerca de Mandos, pero parece que solo funciona en la red local, aunque mi dispositivo y servidor estarán en sitios remotos.
También leí esta pregunta: Para desbloquear remotamente los volúmenes LUKS a través de SSH, ¿cómo puedo verificar la integridad antes de enviar una frase de contraseña? y soy consciente de que lo que quiero lograr puede ser imposible. Pero mi objetivo aquí es agregar la mayor seguridad posible a ese dispositivo.
Mi solución actual: Mi primer pensamiento es cifrar el volumen de rootfs del dispositivo para proteger los datos en él (basado en esta solución ). Cuando se enciende el dispositivo, se conecta de forma desatendida al servidor (con initramfs) y abre un primer túnel ssh inverso (con una clave que es menos importante que perder).
Planeo eliminar los conectores del teclado o la pantalla y / o los controladores del dispositivo.
El servidor entonces (desatendido):
- utiliza el túnel inverso para conectarse al dispositivo;
- carga en el dispositivo un programa que comprueba que no se modificó ningún archivo;
- carga en el dispositivo un pequeño programa que comprueba el hardware del dispositivo (cpuid y mac address) y lo ejecuta para obtener esta información;
- si uno de los anteriores no funcionó o devolvió información incorrecta, bloquea el acceso al dispositivo y la cuenta del cliente (es decir, el servidor nunca volverá a aceptarlos para conectarse), finalmente borre todos los datos en el dispositivo;
- si los pasos 2 y 3 tuvieron éxito, descifra el volumen de rootfs y permite que se inicie el servicio del sistema real;
Todos los sistemas de archivos en el dispositivo se montan de solo lectura utilizando el sistema de archivos de unión (aufs).
Después de eso, se cierra el primer túnel inverso y se inicia el dispositivo.
Después del arranque, se abre un nuevo túnel con la tecla "real". En ese momento, los datos confidenciales se descifran en la memoria RAM del dispositivo.
Mi objetivo: Mi objetivo es asegurar las rootfs del dispositivo o una parte de los datos que están dentro de él, bloqueando o ralentizando a cualquiera que quiera leerlo.
Mis preguntas
Pregunta 1: ¿cuáles son los daños de mi solución? ¿Cuáles son las posibles explotaciones para cada paso?
Pregunta 2: ¿existen otras soluciones posibles que serían mejores para lograr mi objetivo?