Protocoles de distribution de clés cryptographiques asymétriques: Denning - Sacco, DASS, Wu Lama

Les protocoles asymétriques, ou les protocoles basés sur des cryptosystèmes à clés publiques, peuvent affaiblir les exigences pour la phase préliminaire des protocoles. Au lieu d'une clé secrète partagée que deux parties doivent avoir (soit chacune des parties et un centre de confiance), dans les protocoles examinés ci-dessous, les parties doivent d'abord échanger des clés publiques (entre elles ou avec un centre de confiance). Un tel échange préliminaire peut avoir lieu sur un canal de communication ouvert, en supposant que le cryptanalyste ne peut pas influencer le contenu du canal de communication à ce stade.

Protocole de Denning - Sacco

Le protocole a été proposé par Dorothy Denning et Giovanni Sacco en 1981 (anglais Dorothy E. Denning, Giovanni Maria Sacco ). Dans ce protocole, l'initiateur (Alice) se tourne vers le centre de confiance (Trent) pour les certificats des deux participants à la fois. Le même participant est également responsable de la formation d'une nouvelle clé de session. $$$K$ .

1. $$$Alice \ à \ gauche \ {A, B \ droite \} \ à Trent$
2. $$$Trent \ to \ left \ {S_T (A, K_A, T_T), S_T (B, K_B, T_T) \ right \} \ vers Alice$
3. Alice génère une nouvelle clé de session $$$K$
   $$$\ begin {array} {lll} Alice \ to \ {& E_B (S_A (K, T_A)), & \\ & S_T (A, K_A, T_T), & \\ & S_T (B, K_B, T_T) & \} \ à Bob \ end {array}$
4. Bob vérifie la signature du centre de confiance sur le certificat $$$S_T (A, K_A, T_T)$ décrypte la clé de session $$$K$ et vérifie la signature d'Alice.

Message manquant $$$E_B (S_A (K, T_A))$ tout identifiant rend le protocole vulnérable aux attaques avec une clé de session connue et permet au deuxième côté (Bob) d'usurper l'identité de l'initiateur (Alice) dans une session avec un tiers (Clara).

1. Alice et Bob ont eu une session de protocole, générant une nouvelle clé de session $$$K$ .
2. $$$Bob \ à \ gauche \ {B, C \ droite \} \ à Trent$
3. $$$Trent \ à \ gauche \ {S_T (B, K_B, T_T), S_T (C, K_C, T_T) \ droite \} \ à Bob$
4. Bob joue des messages $$$S_A (K, T_A)$ et $$$S_T (A, K_A, T_T)$ d'Alice en session avec Clara:
   $$$\ begin {array} {lll} Bob ~ (Alice) \ to \ {& E_C (S_A (K, T_A)), & \\ & S_T (A, K_A, T_T), & \\ & S_T (C, K_C, T_T) & \} \ à Clara \ end {array}$
5. Clara vérifie avec succès la signature du centre de confiance sur le certificat $$$S_T (A, K_A, T_T)$ décrypte la clé de session $$$K$ et vérifie la signature d'Alice.

En conséquence, Clara est sûre d'avoir reçu une nouvelle clé de session d'Alice. $$$K$ .

Protocole DASS

Le protocole DASS faisait partie intégrante du service de sécurité d'authentification distribuée (DASS), développé par DEC et décrit dans la RFC 1507 en septembre 1993.

Dans le protocole DASS, par analogie avec les protocoles Wide-Mouth Frog et Denning - Sacco, l'initiateur (Alice) génère une nouvelle clé de session et, pour chaque session de protocole, une nouvelle paire de clés publique et privée de l'expéditeur. Le Trusted Center (Trent) est utilisé comme référentiel des certificats de clé publique des participants. Mais contrairement à Denning-Sacco, les deux participants se tournent tour à tour vers le centre de confiance.

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

Utilisation de certificats de clé publique $$$\ left \ {S_T \ left (B, K_B \ right) \ right \}$ et $$$\ left \ {S_T \ left (A, K_A \ right) \ right \}$ que Trent envoie, et une confirmation supplémentaire de la propriété des clés correspondantes, les participants peuvent s'authentifier mutuellement. Décryptage réussi des horodatages des messages $$$E_K \ gauche (T_A \ droite)$ et $$$E_K \ left \ {T_B \ right \}$ fournit une preuve de propriété de la clé de session.

Le protocole utilise une durée de vie ( $$$L$ ) clé de session $$$K_P$ mais l'horodatage n'est pas inclus dans le message. Par conséquent, le protocole reste vulnérable à une attaque avec une clé de session connue. Supposons que Mellory a pu enregistrer une session de communication complètement passée entre Alice et Bob, puis a pu accéder à la clé de session $$$K$ . Cela permet à Mellory de s'authentifier comme Alice devant 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) \ droite) \ droite \} \ à Bob$
2. $$$Bob \ à \ gauche \ {A \ droite \} \ à Trent$
3. $$$Trent \ to \ left \ {S_T \ left (A, K_A \ right) \ right \} \ to Bob$
4. $$$Bob \ à \ gauche \ {E_K \ gauche \ {T_B \ droite \} \ droite \} \ à Alice$

Lors de la première passe, Mellory ne modifie que le premier message contenant un horodatage $$$E_K \ gauche (T_M \ droite)$ . Mellory copie le reste de la session enregistrée. Si Bob n'enregistre pas les clés utilisées, il ne remarquera pas l'usurpation d'identité. Le correctif le plus simple pour cette vulnérabilité consiste à inclure un horodatage dans le message. $$$S_A \ gauche (T_A, L, A, K_P \ droite)$ .

Puisque la clé de session est dans le protocole $$$K$ chiffré par la clé "maître" Bob $$$K_B$ , alors un compromis de ce dernier entraînera un compromis de toutes les clés de session précédemment utilisées. Autrement dit, le protocole n'offre pas un secret direct parfait (objectif G9).

Ni Trent ni Bob ne sont impliqués dans la formation de nouvelles clés de session. Par conséquent, Alice peut forcer Bob à utiliser l'ancienne clé de session, comme dans les protocoles Wide-Mouth Frog et Yahalom.

Protocole de Wu Lama

Le protocole Wu-Lama, proposé en 1992 ( Thomas YC Woo, Simon S. Lam ), ajoute un nombre aléatoire de participants aux messages, ce qui protège le protocole, y compris contre les attaques répétées, et confirme également la propriété des clés. C'est également le seul protocole considéré dans cette section dans lequel une nouvelle clé est générée par une partie de confiance (Trent).

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

Depuis dans le certificat de clé de session $$$S_T (R_A, K, A, B)$ Le nombre aléatoire d'Alice est présent $$$R_A$ , l'attaquant ne pourra pas utiliser l'ancien certificat dans une nouvelle session au nom de Bob. Par conséquent, la 6ème passe du protocole permet à Alice de s'assurer que Bob connaît la nouvelle clé de session $$$K$ , et possède donc sa clé «maître» $$$K_B$ (car c'est le seul moyen d'obtenir le certificat à partir du message $$$E_B (S_T (R_A, K, A, B)))$ )

Message $$$E_K (R_B)$ d'Alice à Bob sur le septième passage nous permet de garantir en même temps qu'Alice connaît sa clé "master" $$$K_A$ (car il a pu déchiffrer $$$E_A (\ points, R_B)$ ) et une nouvelle clé de session $$$K$ car il a pu crypter correctement $$$R_B$ cette clé.