La oración que cita es sobre ataques de repetición . Si dos sistemas A y B ejecutan el protocolo y B comprueban su identidad al firmar algún elemento de datos x , entonces ese valor x debe cambiar de alguna manera cada vez que se reproduzca el protocolo. De lo contrario, si se reutiliza x , entonces un atacante C puede hacerse pasar por B , al observar primero el protocolo una vez (para obtener una copia de B en x ), luego afirma ser B y muestra ese valor de firma nuevamente.
Entonces x debe cambiar cada vez; y A debe estar seguro de que x es un nuevo valor, por lo que no debe ser elegido por B , sino por A . Un valor elegido nuevamente para cada protocolo ejecutado por una parte y enviado a la otra se denomina nonce .
La situación simétrica surge cuando A firma y B verifica, por lo que necesita dos nonces, y cada sistema debe firmar el nonce del otro lado.
Sin embargo, una simple falta de acceso no es suficiente, porque algún atacante laborioso podría hacer lo siguiente:
-
C se conecta a A y afirma ser B .
- Simultáneamente, C se conecta a B y afirma ser A .
-
A envía un nonce u para que lo firme C ( A lo verificará con B clave pública).
-
B envía un nonce v para que lo firme C ( B lo verificará con A clave pública).
-
C envía u a B como el nonce que debe firmar B .
-
C envía v a A como el nonce que debe firmar A .
-
B firma u , como lo especifica el protocolo.
-
A firma v , como lo especifica el protocolo.
-
C envía la firma de B en u a A .
-
C envía la firma de A en v a B .
¡Y voila! A y B recibieron una firma de, respectivamente, B y A , en los valores de nonce u y v que enviaron. Así que ahora A y B están "seguros" de hablar entre ellos, mientras que en realidad están hablando con el atacante C .
El truco aquí es que C "vuelve a enviar" nombres y firmas: el atacante envía como "nonce para firmar" el valor que recibió él mismo, y también lo envía como "firma en nonce" a Firma que recibió. Para evitar este tipo de ataques, la firma no debe cubrir solo el nonce, sino también suficientes datos específicos de la conexión para evitar este redireccionamiento. Ese es el punto de incluir todo el IKE_SA_INIT en ese bloque que está firmado.
Este tipo de problema de protocolo es genérico; Encontrará el mismo tipo de contramedidas en SSL / TLS , donde tanto la firma del cliente ( CertificateVerify ) y las sumas de control finales ( Finished messages) operan en hashes computados en todos los mensajes anteriores de intercambio de información.