Protocolos de distribución de claves criptográficas asimétricas: Denning - Sacco, DASS, Wu Lama

Los protocolos asimétricos, o protocolos basados ​​en criptosistemas con claves públicas, pueden debilitar los requisitos para la etapa preliminar de protocolos. En lugar de una clave secreta compartida que deben tener dos partes (cada una de las partes y un centro de confianza), en los protocolos que se consideran a continuación, las partes deben primero intercambiar claves públicas (entre ellas o con un centro de confianza). Tal intercambio preliminar puede tener lugar a través de un canal de comunicación abierto, bajo el supuesto de que el criptoanalista no puede influir en el contenido del canal de comunicación en esta etapa.

Protocolo Denning - Sacco

El protocolo fue propuesto por Dorothy Denning y Giovanni Sacco en 1981 (inglés Dorothy E. Denning, Giovanni Maria Sacco ). En este protocolo, el iniciador (Alice) recurre al centro de confianza (Trent) para obtener certificados de ambos participantes a la vez. El mismo participante también es responsable de la formación de una nueva clave de sesión. $$$K$.

1. $$$Alice \ to \ left \ {A, B \ right \} \ to Trent$
2. $$$Trent \ to \ left \ {S_T (A, K_A, T_T), S_T (B, K_B, T_T) \ right \} \ a Alice$
3. Alice genera una nueva clave de sesión $$$K$
   $$$\ begin {array} {lll} Alice \ to \ {& E_B (S_A (K, T_A)), & \\ & S_T (A, K_A, T_T), y \\ & S_T (B, K_B, T_T) & \} \ a Bob \ end {array}$
4. Bob verifica la firma del centro de confianza en el certificado $$$S_T (A, K_A, T_T)$descifra la clave de sesión $$$K$y verifica la firma de Alice.

Mensaje perdido $$$E_B (S_A (K, T_A))$cualquier identificador hace que el protocolo sea vulnerable a un ataque con claves de sesión conocidas y permite que el segundo lado (Bob) se haga pasar por el iniciador (Alice) en una sesión con un tercero (Clara).

1. Alice y Bob tuvieron una sesión de protocolo, generando una nueva clave de sesión $$$K$.
2. $$$Bob \ a \ left \ {B, C \ right \} \ a Trent$
3. $$$Trent \ to \ left \ {S_T (B, K_B, T_T), S_T (C, K_C, T_T) \ right \} \ a Bob$
4. Bob juega mensajes $$$S_A (K, T_A)$y $$$S_T (A, K_A, T_T)$de Alice en una sesión con Clara:
   $$$\ begin {array} {lll} Bob ~ (Alice) \ to \ {& E_C (S_A (K, T_A)), & \\ & S_T (A, K_A, T_T), y \\ & S_T (C, K_C, T_T) & \} \ a Clara \ end {array}$
5. Clara verifica con éxito la firma del centro de confianza en el certificado $$$S_T (A, K_A, T_T)$descifra la clave de sesión $$$K$y verifica la firma de Alice.

Como resultado, Clara está segura de que recibió una nueva clave de sesión de Alice. $$$K$.

Protocolo DASS

El protocolo DASS era una parte integral del Servicio de seguridad de autenticación distribuida (DASS), desarrollado por DEC y descrito en RFC 1507 en septiembre de 1993.

En el protocolo DASS, por analogía con los protocolos Wide-Mouth Frog y Denning-Sacco, el iniciador (Alice) genera una nueva clave de sesión y, para cada sesión de protocolo, un nuevo par de claves públicas y privadas del remitente. Trusted Center (Trent) se utiliza como depósito de certificados de clave pública de los participantes. Pero a diferencia de Denning-Sacco, ambos participantes recurren a su vez al centro de confianza.

1. $$$Alice \ to \ left \ {B \ right \} \ to Trent$
2. $$$Trent \ to \ left \ {S_T \ left (B, K_B \ right) \ right \} \ a Alice$
3. $$$Alice \ to \ left \ {E_K \ left (T_A \ right), S_A \ left (L, A, K_P \ right), S_ {K_P} \ left (E_B \ left (K \ right) \ right) \ right \} \ a Bob$
4. $$$Bob \ a \ left \ {A \ right \} \ a Trent$
5. $$$Trent \ to \ left \ {S_T \ left (A, K_A \ right) \ right \} \ a Bob$
6. $$$Bob \ to \ left \ {E_K \ left \ {T_B \ right \} \ right \} \ para Alice$

Usar certificados de clave pública $$$\ left \ {S_T \ left (B, K_B \ right) \ right \}$ y $$$\ left \ {S_T \ left (A, K_A \ right) \ right \}$ que Trent envía y una confirmación adicional de la propiedad de las claves correspondientes, los participantes pueden autenticarse mutuamente. Descifrar con éxito las marcas de tiempo de los mensajes $$$E_K \ left (T_A \ right)$y $$$E_K \ left \ {T_B \ right \}$ proporciona prueba de propiedad de la clave de sesión.

El protocolo utiliza toda la vida ( $$$L$) clave de sesión $$$K_P$pero la marca de tiempo no está incluida en el mensaje. Como resultado, el protocolo sigue siendo vulnerable a un ataque con una clave de sesión conocida. Supongamos que Mellory pudo grabar una sesión de comunicación completamente pasada entre Alice y Bob, y luego pudo acceder a la clave de sesión $$$K$. Esto le permite a Mellory autenticarse como Alice frente a Bob.

1. $$$Mellory ~ (Alice) \ to \ left \ {E_K \ left (T_M \ right), S_A \ left (L, A, K_P \ right), S_ {K_P} \ left (E_B \ left (K \ right) \ right) \ right \} \ a Bob$
2. $$$Bob \ a \ left \ {A \ right \} \ a Trent$
3. $$$Trent \ to \ left \ {S_T \ left (A, K_A \ right) \ right \} \ a Bob$
4. $$$Bob \ to \ left \ {E_K \ left \ {T_B \ right \} \ right \} \ para Alice$

En la primera pasada, Mellory solo cambia el primer mensaje que contiene una marca de tiempo $$$E_K \ left (T_M \ right)$. Mellory copia el resto de la sesión grabada. Si Bob no registra las claves utilizadas, no notará la falsificación. La solución más simple para esta vulnerabilidad es incluir una marca de tiempo en el mensaje. $$$S_A \ left (T_A, L, A, K_P \ right)$.

Como la clave de sesión está en el protocolo $$$K$cifrado por la clave "maestra" Bob $$$K_B$, entonces un compromiso de este último dará lugar a un compromiso de todas las claves de sesión utilizadas anteriormente. Es decir, el protocolo no proporciona un secreto directo perfecto (objetivo G9).

Ni Trent ni Bob están involucrados en la formación de nuevas claves de sesión. Por lo tanto, Alice puede obligar a Bob a usar la antigua clave de sesión, como en los protocolos Wide-Mouth Frog y Yahalom.

Protocolo de Wu Lama

El protocolo Wu-Lama, propuesto en 1992 ( Thomas YC Woo, Simon S. Lam ), agrega números aleatorios de participantes a los mensajes, lo que protege el protocolo, incluso de ataques repetidos, y también proporciona confirmación de la propiedad clave. También es el único protocolo considerado en esta sección en el que una parte confiable es generada por una parte confiable (Trent).

1. $$$Alice \ to \ left \ {A, B \ right \} \ to Trent$
2. $$$Trent \ to \ left \ {S_T (K_B) \ right \} \ a Alice$
3. $$$Alice \ to \ left \ {E_B (A, R_A) \ right \} \ a Bob$
4. $$$Bob \ a \ left \ {A, B, E_T (R_A) \ right \} \ a Trent$
5. $$$Trent \ to \ left \ {S_T (K_A), E_B (S_T (R_A, K, A, B)) \ right \} \ a Bob$
6. $$$Bob \ to \ left \ {E_A (S_T (R_A, K, A, B), R_B) \ right \} \ para Alice$
7. $$$Alice \ to \ left \ {E_K (R_B) \ right \} \ a Bob$

Desde en el certificado de clave de sesión $$$S_T (R_A, K, A, B)$El número aleatorio de Alice está presente $$$R_A$, el atacante no podrá usar el certificado anterior en una nueva sesión en nombre de Bob. Por lo tanto, el sexto paso del protocolo permite a Alice asegurarse de que Bob conozca la nueva clave de sesión $$$K$y, por lo tanto, posee su clave "maestra" $$$K_B$(ya que esta es la única forma de obtener el certificado del mensaje $$$E_B (S_T (R_A, K, A, B)))$)

Mensaje $$$E_K (R_B)$de Alice a Bob en el séptimo pasaje nos permite garantizar al mismo tiempo que Alice conoce su clave "maestra" $$$K_A$(ya que fue capaz de descifrar $$$E_A (\ puntos, R_B)$) y una nueva clave de sesión $$$K$porque pudo cifrar correctamente $$$R_B$esta llave