Tenga en cuenta que no repudio se trata de convencer a un tercero (un juez): Alice firma un mensaje y lo envía a Bob, para que no solo Bob esté convencido de que el mensaje realmente proviene de Alice y no fue alterado, pero Bob puede mostrárselo a Charlie y Charlie también estará convencido. Aquí, solo tiene un cliente y un servidor, no un tercero, por lo que la "no repudio" no es relevante aquí. Esto parece más un problema de autenticación .
La primera respuesta es que no es posible por los siguientes motivos: si la máquina está totalmente comprometida, el atacante podría leer todo su contenido. El atacante puede ejecutar un clon de la máquina en una máquina virtual y dejar que ese clon hable con el servidor. El clon informará que todo está bien, mientras el atacante saquea el sistema genuino. Desde el punto de vista de un criptógrafo, se puede hacer una diferencia entre dos entidades, desde el exterior (por ejemplo, un perro guardián genuino y uno falso), solo si no pueden computar las mismas cosas, y la capacidad de computar equivale a conocimiento : el perro guardián puede calcular una respuesta al servidor que el atacante no puede falsificar solo si el perro guardián conoce algunos datos secretos que el atacante no conoce y, por construcción, esto no sucede .
La segunda respuesta es que podría ser factible pero requiere que las condiciones sean las adecuadas. Si observamos el problema detenidamente, vemos que el objetivo del atacante es hablar con el servidor y emitir mensajes que la máquina comprometida no puede producir. Esto significa que el perro guardián puede funcionar de manera confiable solo si el compromiso es destructivo . Por ejemplo, supongamos que:
- El cliente bajo supervisión usa un conjunto de archivos del sistema (el sistema operativo con su kernel y bibliotecas y utilidades).
- En condiciones normales, estos archivos no son del todo conocidos por el atacante (puede tener copias de algunos o la mayoría de ellos, pero no todos).
- Pero el servidor conoce todos los archivos, exactamente.
- Un compromiso exitoso necesariamente "daña" al menos un archivo (ese es el punto difícil) y los contenidos modificados no pueden ser recuperados posteriormente por el atacante.
En estas condiciones, puede utilizar lo siguiente:
- Haga un archivo de todos los archivos del sistema, en orden alfabético. El formato del archivo debe incluir los nombres y los contenidos del archivo y ser determinista: si realiza el archivo dos veces , obtendrá el doble del mismo archivo de salida, exacto hasta el último bit. El archivo de almacenamiento no se almacena en el disco o en la memoria RAM; es hash al vuelo con SHA-256.
- Sea K la salida SHA-256. A intervalos regulares, el cliente habla con el servidor; el servidor envía un desafío aleatorio C , y el cliente responde con HMAC / SHA-256, calculado sobre C y usando K como tecla.
- El servidor utiliza su conocimiento de los archivos del cliente para volver a calcular K y verificar la salida HMAC.
El protocolo de desafío-respuesta con HMAC evita los ataques de reproducción. MitM tampoco aplica. Realmente estamos en el campo de la teoría de la información aquí, no en el "cripto normal".
Lamentablemente, es muy difícil garantizar las condiciones anteriores. El secreto de los contenidos del dispositivo es casi imposible de lograr cuando el dispositivo es un producto de consumo (el atacante puede comprar otras instancias de dispositivos, abrirlos y ver todos los contenidos), y la mayoría de los compromisos no son destructivos. al menos en lo que respecta a los archivos del sistema: los desbordamientos de búfer y vulnerabilidades similares conducen a explotaciones solo de RAM, sin cambio alguno en los archivos del sistema.
Por lo tanto, lo que expongo aquí es más un concepto teórico que nada práctico. Sin embargo, esto debería ayudar a comprender el problema: para evitar alteraciones ocultas, el perro guardián debe poseer un "secreto" que no se revelará a través de un compromiso total, lo cual es un tanto paradójico y requiere un poco de trampa con condiciones absurdas. p>