¿Cómo reemplazar un identificador constante, por un recurso en una red, con uno variable?

En el nivel básico, todos los sistemas de autenticación modernos asumen que el cliente posee algún tipo de información que puede usarse para probar su identidad y que la información debe mantenerse en secreto. Podría ser un nombre de usuario, contraseña, par de clave pública / privada, etc ...

Si esa información está comprometida, la cadena de autenticación se rompe y el secreto debe cambiarse.

En sus preguntas y comentarios, menciona que el cliente está completamente subvertido, lo que básicamente descarta un sistema de autenticación y que la interacción del usuario no es posible. Obviamente, esto no es poca cosa y podría ser mucho más difícil con otras capas de protección para evitar que el host se vea comprometido en primer lugar.

Sin embargo, suponiendo que el cliente esté completamente comprometido, la pregunta no es cómo implementar un sistema de autenticación, sino cómo realizar la verificación de integridad del cliente. Esto podría lograrse a través del análisis de comportamiento más específicamente en el ámbito de la Prevención / Detección de Intrusos. Si no puede confiar en el cliente, el uso de un agente de punto final en el cliente no sería una opción y su método de detección tendría que ser completamente externo al cliente.

Esto te deja posiblemente con dos opciones que se me ocurren:

• Prevención de intrusiones basada en la red para poner en cuarentena a clientes sospechosos de la red.
• Protección basada en hipervisor, como la API vmSafe de VMware ( vmSafe ) que permite la inspección inmediata de un cliente. Lo que significa que puede conectarse a una API que le permite inspeccionar lo que se está ejecutando en la CPU y en la memoria sin estar dentro de la superficie de ataque y vulnerable a un ataque. En este caso, la protección para el kit raíz y la detección de virus ya está disponible.

En ambos casos es posible que no se cumplan sus requisitos exactos, no está claro su intención exacta, sin embargo es posible. Sin embargo, esta solución aún se usaría con un sistema de autenticación en el cliente, solo se usa para ayudar a detectar si el cliente está comprometido.

Espero que ayude, si no, quizás pueda dar algunos detalles sobre la implementación exacta.

No. El modelo que has descrito dicta que siempre confíes en el cliente.

Cualquier cosa {hashing o keying o cálculo de un nuevo valor} realizado por el cliente en algún momento será residente en la memoria del cliente.

Lo más probable es que no haya una solución al problema que ha bosquejado.

Pero ... Un enfoque que podría observar más de cerca es usar un TPM. Un TPM es una pieza de hardware confiable que se puede usar para almacenar secretos criptográficos, y puede organizar su lanzamiento solo a software confiable. Dependiendo de las necesidades particulares de su aplicación, es posible de manera remota que esto le brinde al menos una solución parcial a su problema.

Sin embargo, hay un montón de advertencias con los TPM. Los TPM no están diseñados para ser seguros contra ataques físicos, por lo que si el atacante tiene acceso físico al dispositivo, olvídelo, no es seguro. Además, no hay mucho soporte de software para esto, por lo que estarás a la vanguardia y habrá grandes desafíos de ingeniería. Además, no todas las máquinas contienen un TPM.

Consulte también Estado de la implementación de informática de confianza y certificación remota y ¿Verificando la integridad del software del servidor? .

Pero, nuevamente, lo más probable es que el problema, tal como lo ha bosquejado, no se pueda resolver por medios técnicos.

En un escenario en el que siempre confía en el cliente pero desea asumir el peor de los casos, realmente solo tendrá dos opciones

1) Confíe en los usuarios mucho más que en sus máquinas (lo que no es una idea tan remota), es decir, una contraseña es mucho más segura que un archivo de contraseñas, etc.

2) Confíe en algo físico (algo parecido a un token RSA, o incluso algo tan "simple" como el hashing del identificador de un número de serie o algo parecido a ese

Sugeriría un modelo de clave pública-privada similar a ssh además de su identificador. Si el cliente en A quiere conectarse a B (al que A se ha conectado anteriormente), A comprueba que B no ha cambiado emitiendo un desafío a B basado en la clave de host pública del servidor B (que A almacenó de sus interacciones anteriores) que B solo puede responder con la clave de host privada de B. Luego, A puede autenticarse con B (ya sea enviando la contraseña a través de un canal encriptado o usando una clave privada / pública) e iniciar sesión en el sistema B.

Claro, si un atacante M obtuviera la clave de host privada para B, podrían hacerse pasar por B; pero debe hacer todo lo posible para proteger sus claves privadas para que no se lean del disco o de la memoria (cifre el disco; limite los permisos de lectura; manténgase actualizado sobre los parches de seguridad; etc).