¿Es fundamentalmente posible desarrollar un sistema informático (probado) transparente?

Con el hardware existente, no, es fundamentalmente imposible demostrar que el código que ejecuta es el código que debe ejecutar y nada más. Esto se ve fácilmente con respecto a la confidencialidad: imagine, por ejemplo, que ejecuta una aplicación de conteo de votos; Los votantes se conectan y envían su voto. La aplicación "honesta" no filtra datos de votos individuales, aunque ve todos los votos y sabe qué votó cada votante. Sin embargo, desde el exterior, solo ve los paquetes de red que van y vienen, por lo que no puede saber si alguna otra parte del sistema está inspeccionando el contenido de la RAM al mismo tiempo o no. En la práctica, un mantenedor de sistema malicioso ejecutaría la aplicación en una máquina virtual y tomaría instantáneas de VM cada vez que se conectara un nuevo votante. En virtud de que la VM emula una máquina "verdadera", este tipo de actividad maliciosa no se puede descartar de manera confiable.

Todavía se pueden hacer algunas cosas para intentar obtener algunas garantías de que el código que se ejecuta es el esperado:

• El hardware podría configurarse en una sala con seguridad física, bajo auditoría, con procedimientos de acceso que requieran al menos dos operadores humanos y cámaras de video que lo graben todo. Esto se hace comúnmente para la raíz autoridades de certificación : ese tipo de máquina está en una PC fuera de línea, guardada en una jaula en una habitación segura , y se usa ocasionalmente (por ejemplo, mensualmente) para emitir algunos certificados a la AC intermedia y para crear una nueva CRL. Todo el proceso apunta a garantizar que, de hecho, la máquina solo hará lo que se supone que debe hacer; y esto es todo procedimientos , sin software especial.

• Para algunas operaciones, existen posibles protocolos criptográficos. Por ejemplo, para los sistemas de votación, se puede usar cifrado homomórfico , lo que permite que el sistema central cuente los votos sin tener acceso a El contenido de la votación actual. Como los votantes solo envían votos cifrados, deben demostrar que los contenidos son "válidos" (cifraron un 0 o un 1, pero no otro valor): esto se hace con pruebas de conocimiento cero . Note el matiz aquí: el votante no está probando que está usando un código de fuente abierta específico que encripta su voto; pero demuestra que lo que finalmente envía a la máquina de conteo es, de hecho, el cifrado de un voto válido, independientemente de cómo lo haya calculado realmente.

La publicación de Tom es un buen comienzo en esto. Sin embargo, hay un enfoque más directo que creé hace años: una implementación estándar en diversas piezas de hardware que se verifican entre sí. Derivé esto porque me di cuenta de que el problema de la subversión en realidad se reducía a qué fabricantes o revisores confías. El problema de ataque requiere que el enemigo sepa lo que está golpeando. Ayuda de diversidad / ofuscación allí. Por lo tanto, suponiendo que cada persona tenga un hardware o herramientas en las que confíe, la solución surge naturalmente para lograr que todas calculen el mismo resultado utilizando los mismos datos. El uso de tarjetas integradas y E / S de alta velocidad hace que el proceso sea barato y rápido.

Entonces, comienzas con una cadena de herramientas certificada para el código. Describí cómo construir uno aquí en HN:

enlace

También puede usar Oberon System como componente porque es un compilador sin trabas, bien documentado, flexible, fácil de entender y portátil. También hay un esquema similar al de Scheme, incluida la variante VLISP que se verifica matemáticamente hasta x86, PPC y ARM.

De todos modos, el punto es que tiene (a) mapeo de HLL a binario, (b) interfaz de sistema operativo con el mismo, (c) hardware diferente y confiable para cada parte, (d) cada interfaz implementada + cadena de herramientas para ello , (e) analizador de E / S robusto + mediación de E / S para hardware. Estos se combinan con un interruptor que ejecuta los pasos del software en trozos fijos con comprobaciones ocasionales (por ejemplo, hashes) en los resultados mientras se comparte la máquina para publicar impresiones bonitas y distribuirlas. Cualquiera de estas partes puede ver una desviación y llamarlo. Con un protocolo de voto decente y amp; I / O, esto puede escalar hasta tantos verificadores como puede manejar su servidor de agregación.

Entonces, ahí está tu respuesta. Es lo que se me ocurrió para resolver la seguridad de los sistemas de compilación en los que las partes mutuamente sospechosas deben confiar. Asumí que eventualmente veríamos ataques de hardware de TLA. La solución fue la diversidad, la ofuscación, el arranque fácil y la verificación fácil de que todos estamos en la misma página. Snowden y el catálogo TAO confirmaron mis predicciones y validaron eso y otros métodos míos. Esto se puede aplicar a la mayoría de los problemas, excepto en tiempo real o de alto rendimiento. Sin embargo, hay versiones en tiempo real de cada componente en otros proyectos. Simplemente no trabajé en ellos y no puedo decir cómo sería la integración.