Entre los requisitos para un intercambio de claves seguro está la confirmación de la clave. Me pregunto por qué se requiere este paso. Incluso si la otra parte no ha calculado un valor correcto para el secreto compartido, no importa. No podrá descifrar la información enviada de todos modos. ¿Por qué molestarse y asegurarse de que la otra parte posea el secreto compartido correcto? Se dice que este es un requisito para un intercambio de claves seguro. Pero ¿por qué?
Ciertamente podrían descifrar cualquier cosa que envíes porque estás hablando de cifrado síncrono, donde se usa la misma clave para cifrar y descifrar el tráfico. Para que esto funcione, ambas partes deben acordar una clave para el intercambio. La verificación de secreto compartido no es realmente un requisito para un intercambio de claves seguro desde un punto de vista teórico, usted podría intercambiar claves de forma segura con cualquier persona realmente. Sin embargo, si no verifica el otro lado, podría estar configurando una VPN con cualquier persona, incluso con aquellas que no desee, y enviar todo tipo de información confidencial. Es por esto que la verificación del remitente es una parte integral de todas las tecnologías de transferencia segura.
Es posible que se confunda al mezclar la tecnología PKI y VPN, pensando erróneamente que cuando PKI se encarga de verificar que solo el verdadero destinatario puede descifrar el tráfico. No es tan sencillo porque el descifrado PKI (asíncrono en lugar del cifrado síncrono) requiere un gran uso de computación, por lo que las transferencias seguras casi siempre usan PKI para la verificación del remitente, pero luego configuran el cifrado síncrono para las transferencias.
EDITAR: el cartel dice que la fuente es una conferencia
Si ambos lados no comparten la misma clave, ninguno de los dos podría descifrar el tráfico del otro, por lo que la confirmación de la clave es importante desde una perspectiva de operabilidad, si no desde una perspectiva de seguridad pura. Además, si está utilizando una VPN para verificar la autenticación (consulte IPSEC AH), debe verificar las claves, o no puede estar seguro de qué es el tráfico auténtico. Lo que puede significar el profesor es que simplemente no funcionará sin una verificación clave, en lugar de ser un proceso de seguridad.
¿Por qué molestarse y asegurarse de que la otra parte posea el secreto compartido correcto? Se dice que este es un requisito para un intercambio de claves seguro. Pero ¿por qué?
Además de otras razones, a veces se requiere una confirmación de clave durante la validación del algoritmo. Por ejemplo, El Sistema de Validación de Esquemas de Acuerdo Clave (KASVS) de NIST los requiere en algunas instancias.
Para completar, aquí está la definición de NIST de la Sección 4.1, página 7:
Un procedimiento para proporcionar seguridad a una parte (el destinatario de la confirmación de la clave) de que la otra parte (el proveedor de la confirmación de la clave) posee realmente el material de codificación y / o el secreto compartido correcto.
Incluso si la otra parte no ha calculado un valor correcto para el secreto compartido, no importa. No podrá descifrar la información enviada de todos modos.
Esto puede no ser necesariamente cierto. Si un malo puede manchar el intercambio, él / ella puede aprender algunas cosas en ausencia de una ruptura total mediante el control de los parámetros. En este caso, la ejecución del protocolo se detendría inmediatamente en la fase de confirmación de la clave en lugar de darle al atacante más de un bocado de la manzana proverbial.
Protocolos de autenticación y establecimiento de claves (pp. 162-63) en realidad detalla un ataque al intercambio de claves que se ve frustrado por la conformación de las claves, por lo que no es teórico.
Nunca he implementado un protocolo de confirmación de claves, pero espero que sean un protocolo de desafío / respuesta de dos vías que no use el material de claves directamente. Probablemente agrega de 2 a 4 mensajes adicionales al protocolo.
Es bidireccional porque ambas partes deben demostrar el conocimiento de la clave. No utiliza el material de claves directamente para evitar revelar información sobre la clave real a un adversario.
En una nota relacionada, nunca usas directamente el secreto compartido / material clave. Debe moverlo del dominio Diffie-Hellman a otro dominio donde los valores son igualmente probables (es decir, distribuidos uniformemente). IPSec usa HKDF para este paso.
Lea otras preguntas en las etiquetas key-exchange