Protocoles cryptographiques: définitions, enregistrements, propriétés, classification, attaques

Ce texte sera l'un des chapitres réécrits du manuel sur la protection de l'information du Département de l'ingénierie radio et des systèmes de contrôle, ainsi que, à partir de ce code de formation, le Département de la protection de l'information de l'Institut de physique et de technologie de Moscou. Le tutoriel complet est disponible sur github (voir aussi les versions préliminaires ). Je prévois de télécharger de nouveaux «gros» éléments sur le hub, d'une part, pour recueillir des commentaires et observations utiles, et d'autre part, pour donner à la communauté plus de matériel de synthèse sur des sujets utiles et intéressants.

Concepts de base

Pour la réussite de tout objectif de protection des informations, il est nécessaire de participer au processus de protection de plusieurs entités qui, selon certaines règles, effectueront des actions techniques ou organisationnelles, des opérations cryptographiques, interagiront les unes avec les autres, par exemple, en transmettant des messages ou en vérifiant leurs identités respectives.

La formalisation de ces actions se fait à travers une description du protocole. Protocole - une description d'un algorithme distribué dans le processus duquel deux ou plusieurs participants effectuent séquentiellement certaines actions et échangent des messages (ci-après, dans cette section, les définitions sont données sur la base de [Cheremushkin: 2009] ).

Par un participant (sujet, partie) du protocole, on entend non seulement des personnes, mais aussi des applications, des groupes de personnes ou des organisations entières. Formellement, les participants ne sont considérés que ceux qui jouent un rôle actif au sein du protocole. Bien que lors de la création et de la description des protocoles, vous ne devez pas non plus oublier les côtés passifs. Par exemple, un cryptanalyste passif n'est pas officiellement un participant aux protocoles, mais de nombreux protocoles sont développés en tenant compte de la protection de ces «non-participants».

Le protocole se compose de cycles ( tour anglais) ou de passes ( passage anglais). Un cycle est un intervalle de temps d'activité d'un seul participant. À l'exception du tout premier cycle de protocole, il commence généralement par la réception d'un message et se termine par l'envoi.

Un cycle (ou passage) se compose d' étapes (actions, étape en anglais , action ) - actions terminées spécifiques effectuées par un participant au protocole. Par exemple:

• génération d'une nouvelle valeur (aléatoire);
• calcul des valeurs de fonction;
• vérification des certificats, clés, signatures, etc.;
• recevoir et envoyer des messages.

Une mise en œuvre passée ou même théorique du protocole pour des participants spécifiques est appelée une session . Chaque participant à la session joue un ou plusieurs rôles . Dans une autre session de protocole, les participants peuvent changer de rôle et exécuter des fonctions complètement différentes.

Nous pouvons dire que le protocole décrit de manière normative les règles de comportement de chaque rôle dans le protocole. Une session est une description descriptive (peut-être théoriquement) d'une implémentation de protocole qui a eu lieu dans le passé.

Un exemple de description de protocole.

1. Un participant avec le rôle Expéditeur doit envoyer un message à un participant avec le rôle Destinataire.
2. Un participant avec le rôle Destinataire doit recevoir un message d'un participant avec le rôle Expéditeur.

Un exemple de description de session de protocole.

1. Le 1er avril, à 13 heures, Alice a envoyé un message à Bob.
2. Le 1er avril, à 13 h 05, Bob a reçu un message d'Alice.

Un protocole protégé ou un protocole de sécurité sera appelé un protocole qui fournit au moins une fonction de protection [ISO: 7498-2: 1989] :

• authentification des parties et de la source de données,
• contrôle d'accès
• confidentialité
• l'intégrité
• incapacité de refuser l'envoi ou la réception.

Si un protocole sécurisé est conçu pour exécuter les fonctions de sécurité d'un système cryptographique, ou si des algorithmes cryptographiques sont utilisés lors de son exécution, alors un tel protocole sera appelé cryptographique .

Enregistrement de protocole

Pour enregistrer des protocoles liés à la mise en œuvre de fonctions de protection des informations, n'utilisez pas d'expressions comme «participant avec le rôle de« expéditeur », mais remplacez-les par des notations courtes comme« expéditeur »ou utilisez des exemples généralement acceptés: Alice, Bob, Clara, Eva, etc., e. Les accords suivants sont utilisés.

• Alice, Bob (de l'anglais A, B ) - expéditeur et destinataire.
• Karl, Clara, Charlie (de l'anglais. C ) - un tiers égal.
• Eve (de l' espionnage anglais) est un cryptanalyste passif.
• Mellory (du malicieux anglais) est un cryptanalyste actif.
• Trent (du trust anglais) est une partie de confiance.

Il n'y a pas de format d'enregistrement de protocole universellement accepté; ils peuvent différer à la fois en apparence et en exhaustivité de la description. Par exemple, voici le format d'enregistrement du protocole Diffie-Hellman le plus complet.

• Étape préliminaire.
  • Toutes les parties ont choisi le commun $$$g$ et $$$p$ .
• Réussite 1.
  • Alice génère au hasard $$$a$ .
  • Alice calcule $$$A = g ^ a \ bmod p$ .
  • Alice envoie Bob $$$A$ .
• Réussite 2.
  • Bob prend d'Alice $$$A$ .
  • Bob génère au hasard $$$b$ .
  • Bob calcule $$$B = g ^ b \ bmod p$ .
  • Bob envoie Alice $$$B$ .
  • Bob calcule $$$s = A ^ b \ bmod p$ .
• Réussite 2.
  • Alice enlève Bob $$$B$ .
  • Alice calcule $$$s = B ^ a \ bmod p$ .
• Le résultat du protocole.
  • Les parties ont calculé une clé de session partagée $$$s$ .

Comparez maintenant avec un bref enregistrement du même protocole.

1. $$$A \ à B: A = g ^ a \ bmod p$
2. $$$B \ à A: B = g ^ b \ bmod p$

Dans un bref enregistrement, l'initialisation et les prérequis, les calculs des données non transmises (dans cet exemple, une clé de session commune, sont omis) $$$s$ ), ainsi que les éventuels contrôles.

Dans ce didacticiel, nous nous en tiendrons à un format d'enregistrement intermédiaire.

1. Alice génère $$$a$ .
   $$$Alice \ à \ gauche \ {A = g ^ a \ bmod p \ droite \} \ à Bob$ .
2. Bob génère $$$b$ .
   Bob calcule $$$s = A ^ b \ bmod p$ .
   $$$Bob \ à \ gauche \ {B = g ^ b \ mod p \ droite \} \ à Alice$ .
3. Alice calcule $$$s = B ^ a \ bmod p$ .

Nous convenons également des règles d'enregistrement de l'affaire lorsqu'un cryptanalyste actif (Mellory) se fait passer pour un utilisateur légal.

$$

$$\ begin {array} {llllc} (1) & A & \ to M \ left (B \ right) &: & A = g ^ a \ bmod p, \\ (2) & M \ left (A \ right ) & \ à B &: & A ^ * = g ^ {a ^ *} \ bmod p, \\ (3) & B & \ à M \ gauche (A \ droite) &: & B = g ^ b \ bmod p, \\ (4) & M \ left (B \ right) & \ to A &: & B ^ * = g ^ {b ^ *} \ bmod p. \\ \ end {array}$$

Ou en attribuant une colonne distincte à chaque participant.

$$

$$\ begin {array} {lllclllc} (1) & A & \ to & M \ left (B \ right) & {} & {} &: & A = g ^ a \ bmod p, \\ (2) & {} & {} & M \ left (A \ right) & \ to & B &: & A ^ * = g ^ {a ^ *} \ bmod p, \\ (3) & {} & {} & M \ left (A \ right) & \ gets & B &: & B = g ^ b \ bmod p, \\ (4) & A & \ gets & M \ left (B \ right) & {} & {} & : & B ^ * = g ^ {b ^ *} \ bmod p. \\ \ end {array}$$

Pour réduire la description et simplifier la comparaison des différents protocoles, utilisez les conventions suivantes pour la désignation des données transmises.

• $$$A$ , $$$B$ , $$$C$ , etc. - identifiants des participants au protocole: Alice, Bob et Clara, respectivement.
• $$$M$ (à partir d'un message en anglais) - un message dans sa forme originale, en clair, quel que soit l'encodage. Autrement dit, sous $$$M$ le texte source peut être compris comme du texte ou, par exemple, du son, ou déjà un certain nombre ou un tableau de bits qui correspond uniquement à ce message.
• $$$K$ (à partir de la clé anglaise) - une touche. Sans autre élaboration, il désigne généralement une clé de session secrète.
• $$$K_A$ - une clé secrète partagée entre Alice et Trent (pour les cryptosystèmes symétriques).
• $$$K_A$ - Clé publique d'Alice (pour les cryptosystèmes asymétriques).
• $$$E_K \ left (\ dots \ right)$ (de l'anglais encrypt ) - données chiffrées sur la clé $$$K$ .
• $$$E_A \ left (\ dots \ right)$ , $$$E_B \ left (\ dots \ right)$ - des données chiffrées sur les clés d'Alice et Bob, respectivement.
• $$$L$ (de la durée de vie en anglais) - la durée de vie, par exemple, d'un certificat.
• $$$S_K \ left (\ dots \ right)$ (à partir du signe anglais) - données et signature numérique correspondante sur la clé publique $$$K$ .
• $$$T_A$ , $$$T_B$ (à partir de l' horodatage anglais) - horodatages des participants respectifs.
• $$$R_A$ , $$$R_B$ (à partir de l'anglais random ) - nombres aléatoires sélectionnés par les participants respectifs.

Exemples d'utilisation de la notation.

• $$$E_ {K_B} (M)$ ou juste $$$E_B (M)$ - message $$$M$ chiffré avec la clé de Bob $$$K_B$ .
• $$$S_A (R_A)$ - nombre aléatoire $$$R_A$ généré par Alice et signé par elle. Autrement dit, le message contiendra à la fois un nombre aléatoire (en texte brut) et une signature électronique de ce numéro.
• $$$S_T (A, K_A, T_T, L)$ - Identifiant et clé d'Alice, horodatage et durée de vie de cet enregistrement, tous ensemble signés par la clé publique du centre de confiance (Trent). C’est en fait le certificat clé d’Alice.

Propriétés de sécurité du protocole

Un système sécurisé et, par conséquent, un protocole sécurisé peuvent exécuter diverses fonctions de sécurité. Beaucoup de ces fonctions ou objectifs (objectifs anglais) peuvent être formulés comme une résistance à une classe particulière d'attaques. Le plus complet et le plus pertinent est considéré comme la liste et l'interprétation de ces objectifs dans le document du projet AVISPA ( validation automatisée anglaise des protocoles et applications de sécurité Internet ) [AVISPA] , résumant les descriptions de divers documents de l'IETF ( Internet Engineering Task Force ). Ces objectifs sont considérés comme étant formalisés , c'est-à-dire que pour les protocoles individuels, il est possible de prouver ou de réfuter formellement la réalisation de ces objectifs.

• Authentification (unidirectionnelle).
  Anglais Authentification (monodiffusion) .
  
  • (G1) Authentification du sujet.
    Anglais Authentification d'entité (Authentification d'entité homologue) .
    
    Une garantie pour un côté du protocole par la présentation de preuves et / ou de pouvoirs de la deuxième partie participant au protocole, et que la deuxième partie a effectivement participé à la session en cours du protocole. Cela se fait généralement par la présentation de ces données qui ne peuvent être générées que par l'autre côté. L'authentification du sujet implique que les données reçues peuvent être tracées sans ambiguïté au sujet du protocole, ce qui implique l'authentification de la source de données.
  • (G2) Authentification des messages.
    Anglais Authentification des messages (authentification de l'origine des données) .
    
    Une garantie que le message ou l'élément de données reçu a été créé par un certain sujet à un moment (généralement non spécifié) dans le passé, et que ces données n'ont pas été endommagées ou falsifiées. Mais sans fournir l'unicité ou l'actualité. L'authentification des messages implique leur intégrité.
  • (G3) Répéter la protection.
    Anglais Replay Protection
    
    Protection contre la situation où une partie enregistrera un message et le lira plus tard (éventuellement dans une autre session de protocole), ce qui conduira à une interprétation incorrecte de cette partie comme authentifiée.
• Authentification lors de l'envoi à plusieurs adresses ou lors de la connexion à un service d'abonnement / notification.
  Anglais Authentification en multidiffusion ou via un service d'abonnement / notification .
  
  • (G4) Authentification explicite du destinataire.
    Anglais Authentification implicite de destination .
    
    Le protocole doit garantir que le message envoyé est lisible uniquement pour les destinataires légitimes. Autrement dit, seuls les participants autorisés légalement auront accès aux informations pertinentes, à un message de multidiffusion ou à une session de communication de groupe. Comprend des groupes de distribution avec des adhésions très dynamiques.
  • (G5) Authentification source.
    Anglais Authentification source .
    
    Les destinataires légaux pourront authentifier la source et le contenu des informations ou des communications de groupe. Comprend les cas où les membres du groupe ne se font pas confiance.
• (G6) Autorisation (par un tiers de confiance).
  Anglais Autorisation (par un tiers de confiance) .
  
  La garantie de la possibilité d'autoriser (en termes de protocole) d'un sujet à accéder aux ressources d'un autre en utilisant un tiers de confiance. Cela implique que le propriétaire de la ressource peut ne pas avoir ses propres listes d'accès (Eng. Access Control List, ACL ) et s'appuie sur celles du côté de confiance.
• Génération conjointe de clés.
  Anglais Propriétés de l'accord clé .
  
  • (G7) Authentification par clé.
    Anglais Authentification par clé .
    
    Une garantie pour l'une des entités que seuls les utilisateurs légaux peuvent accéder à une clé secrète spécifique.
  • (G8) Preuve de propriété de la clé.
    Anglais Confirmation de clé (preuve de possession de clé) .
    
    Une garantie pour l'une des entités que l'autre entité possède réellement une clé secrète particulière (ou les informations nécessaires pour obtenir une telle clé).
  • (G9) Parfait secret direct.
    Anglais Perfect Forward Secrecy (PFS) .
    
    Garantir que la future compromission des clés principales ne compromet pas les clés de session des sessions de protocole précédentes.
  • (G10) Génération de nouvelles clés.
    Anglais Dérivation de clé fraîche .
    
    Garanti pour créer de nouvelles clés de session pour chaque session de protocole.
  • (G11) Une occasion sûre de convenir des paramètres de sécurité.
    Anglais Négociation sécurisée des capacités (Résistance aux dégradations et aux attaques de négociation) .
    
    La garantie est non seulement que les parties légales ont la possibilité de s'entendre sur les paramètres de sécurité, mais aussi que la partie illégale n'est pas intervenue dans le protocole et n'a pas conduit à la sélection de ses paramètres de sécurité préférés (éventuellement les plus faibles).
• (G12) Confidentialité.
  Anglais Confidentialité (secret) .
  
  La garantie qu'un élément de données spécifique (une partie du message transmis) reste inconnu de l'attaquant. À cette fin, le secret de la clé de session, l'authentification de la clé ou la fiabilité des clés principales à long terme ne sont pas pris en compte.
• L'anonymat.
  Anglais L'anonymat .
  
  • (G13) Protection des identifiants contre l'écoute (non-connectivité).
    Anglais Protection d'identité contre les écoutes .
    
    La garantie que l'attaquant (l'écouteur) n'est pas en mesure de relier la messagerie du sujet à sa véritable identité.
  • (G14) Protection des identifiants des autres parties.
    Anglais Protection de l'identité contre les pairs .
    
    Une garantie que le participant à la correspondance n'est pas en mesure de connecter la messagerie du sujet avec une personne réelle, mais uniquement avec un certain pseudonyme.
• (G15) Protection limitée contre les attaques par déni de service.
  Anglais Résistance (limitée) au déni de service (DoS) .
  
  S'assurer que le protocole suit certains principes qui réduisent la probabilité (compliquant l'utilisation) de certaines classes d'attaques par déni de service.
• (G16) Invariance de l'expéditeur.
  Anglais Invariance de l'expéditeur .
  
  Une garantie pour l'une des parties que la source du message reste la même que celle qui a commencé la communication, bien que l'identification réelle de la source ne soit pas importante pour le destinataire.
• Irréfutabilité.
  Anglais Non-répudiation .
  
  • (G17) Responsabilité.
    Anglais Responsabilité .
    
    Capacité garantie de suivre les actions des sujets sur les objets.
  • (G18) Preuve d'origine.
    Anglais Preuve d'origine .
    
    Garantie de preuves irréfutables de la source du message.
  • (G19) Preuve de livraison.
    Anglais Preuve de livraison .
    
    Garantie de preuve irréfutable du fait de recevoir le message.
• (G20) Propriété temporaire protégée.
  Anglais Propriété temporelle de sécurité .
  
  La garantie de la capacité de prouver que le fait que le système se trouve dans l'un des États signifie qu'une fois dans le passé, le système était au moins une fois dans un autre État. Par exemple, l'obtention d'un accès d'un sujet à une ressource signifie qu'une fois dans le passé, le sujet a réussi à payer cet accès.

Des exemples de propriétés de sécurité implémentées par divers protocoles sont donnés dans le tableau.

Classification du protocole

Il n'y a pas de classification universellement acceptée des protocoles de sécurité. Cependant, un ensemble de caractéristiques objectives et non ambiguës classant les protocoles peut être distingué.

• Classification selon le nombre de participants au protocole:
  • bilatéral
  • tripartite, etc.,
  • multilatérale.
• Classement par le nombre de messages transmis:
  • interactif (avec présence de messagerie mutuelle);
  • non interactif (avec messagerie unique), souvent appelé schémas . La définition n'est pas entièrement complète. Tout schéma comporte au moins deux étapes. Lors de la première étape préliminaire, le centre de confiance distribue des informations aux pairs participants. Lors de la deuxième étape (sessions de protocole spécifiques), les participants échangent ces informations en recevant le secret d'origine ou une nouvelle clé de session secrète. De plus, l'échange d'informations peut aller entre plus de deux participants. Cependant, après l'échange mutuel d'informations, aucun laissez-passer supplémentaire n'est requis pour atteindre les objectifs du programme.
• Classement par le nombre de passes (tours):
• Classification par systèmes cryptographiques utilisés:
  • basé uniquement sur des cryptosystèmes symétriques;
  • basé sur l'inclusion de cryptosystèmes asymétriques.
• Classification par propriétés de protocole protégées:
  • (G1) fournit ou non l'authentification du premier, du deuxième côté du protocole, etc.;
  • (G2) fournit ou non l'authentification des messages;
  • (G3) fournit ou non une protection contre la répétition;
  • etc.
• Classement par type de participants:
  • Peer-to-peer, lorsque tous les participants peuvent jouer n'importe quel rôle au sein du protocole;
  • avec un intermédiaire de confiance lorsqu'un tiers de confiance est toujours impliqué dans le protocole;
  • avec un arbitre de confiance, lorsqu'une troisième partie de confiance peut participer au protocole, si les autres participants ne sont pas d'accord.

Une classification moins objective et non ambiguë peut également être introduite sur la base d'une évaluation subjective des protocoles.

• Classification selon l'objet du protocole:
  • ... assurer l'intégrité
  • ... signé numériquement
  • ... identification
  • ... confidentialité
  • ... la distribution des clés,
  • ... etc.
• Classification de la "complétude" des fonctions exercées:
  • primitifs, sont utilisés comme composant de base dans la construction de protocoles d'application;
  • intermédiaire;
  • appliqué, conçu pour résoudre des problèmes pratiques.

La classification par objet peut également être reformulée en une classification par les propriétés protégées du protocole pour lequel elle a été développée. Dans ce cas, il sera nécessaire de mettre en évidence les «propriétés de base» (par exemple, G10 - la formation de nouvelles clés), et la majeure partie du reste sera attribuée à d'autres (par exemple, G7 - authentification de clé et G8 - confirmation de la propriété de la clé). Déterminer lesquelles des propriétés sont «de base» et lesquelles sont «supplémentaires» créera une ambiguïté dans la classification en fonction de l'objectif du protocole. Si toutes les propriétés du protocole sont dites «basiques», alors une telle classification deviendra trop détaillée.

La classification par "exhaustivité" des fonctions exercées est problématique du fait qu’aucun protocole ne peut être qualifié de "pleinement appliqué". Tout protocole en lui-même n'est qu'une partie d'un certain système d'information (ou organisationnel), qui remplit simplement la fonction requise par les utilisateurs. Cependant, nous pouvons dire que les protocoles individuels (par exemple, TLS) sont des protocoles d'un niveau plus élevé que les protocoles, par exemple Diffie-Hellman, car ces derniers font souvent partie intégrante du même protocole TLS.

Attaques de protocole

Les propriétés protégées des protocoles peuvent être déclarées lorsque les auteurs du protocole les déclarent eux-mêmes (et, généralement, donnent divers arguments en faveur de l'exécution de ces fonctions), et implicites lorsque les auteurs d'un système s'appuient sur la mise en œuvre de propriétés protégées par un certain protocole.

Une attaque contre un protocole sécurisé est une tentative d'analyser des messages de protocole et / ou d'effectuer des actions non prévues par le protocole pour violer les propriétés déclarées ou implicites du protocole. (La définition modifiée de [Cheremushkin: 2009] est utilisée . La différence est que Cheryomushkin dans sa définition ne décrit pas ce qu'est un «dysfonctionnement du protocole» et laisse des cas ambigus de violation, par exemple, les propriétés de G9 / PFS et G20 / STP.)

Une attaque est considérée réussi si au moins une des propriétés déclarées ou implicites du protocole est violée.

En cas d'attaque réussie sur les propriétés implicites, nous préciserons que l' attaque sur l'utilisation du protocole est réussiedans un système. Cela ne parlera bien sûr pas des défauts du protocole lui-même, mais du mauvais choix du protocole (ou de ses paramètres) par les auteurs du système.

Il existe de nombreux types d'attaques de protocole. De nombreuses attaques ont des principes généraux, ce qui permet de distinguer les classes d'attaque pour simplifier l'analyse et le développement de protocoles résistants à des classes d'attaque entières.

• Attaque MitM au milieu
  Anglais man-in-the-middle attack
  
  , , , , , , , . , ( G1). —.
• Replay
  Anglais replay attack
  
  , , , , . , , - .
• TF
  Anglais type flaw attack
  
  , , () ( ). , , Wide-Mouth Frog, —, Yahalom —.
• PS
  Anglais parallel-session attack
  
  , . , , —.
• STS
  Anglais short-term secret attack
• KN
  Anglais known-key attack
  
  , , (, ), , , .
• UKS
  Anglais unknown key-share attack
  
  , ( , , ), . , , -.

Il est important de noter que sauf indication contraire, alors dans l'analyse des protocoles cryptographiques (systèmes non spécifiques), l'hypothèse de la force de toutes les primitives cryptographiques utilisées est utilisée. Par exemple, il est supposé que, même s'il existe un échange sécurisé d'informations à l'aide d'une clé de session générée dans une session d'un protocole cryptographique, l'attaquant ne disposera pas de suffisamment de ressources et de temps pour obtenir cette clé de session via une attaque sur les chiffrements utilisés ou des fonctions de hachage résistantes à la cryptographie.

D'autre part, il faut supposer que les clés de session obtenues dans le cadre des sessions de protocole seront après un certain temps (cependant beaucoup plus longues que la session de communication elle-même) obtenues par l'attaquant (classes d'attaque STS et KN). Et après beaucoup plus de temps, l'attaquant pourra accéder aux clés «principales» - clés d'utilisation à long terme, donc des protocoles avec la génération de clés de session devraient être développés, y compris la propriété G9 / PFS.

(Les sections qui suivent décrivent les protocoles spécifiques.)

Les références

• [ISO 7498-2: 1989] ISO 7498-2: 1989. Systèmes de traitement de l'information - Interconnexion de systèmes ouverts - Modèle de référence de base - Partie 2: Architecture de sécurité: Norme / ISO / CEI JTC 1 Technologies de l'information. - 02.1989. - URL: www.iso.org/standard/15841.html .
• [AVISPA] Validation automatisée des protocoles et des
  applications de sécurité Internet (AVISPA): IST-2001-39252. Livrable 6.1 «Liste des problèmes sélectionnés». Propriétés (objectifs). - 2003. - URL: www.avispa-project.org/delivs/6.1/d6-1/node3.html
• [Cheremushkin] Cheremushkin A. V. Protocoles cryptographiques: propriétés et vulnérabilités de base // Applied Discrete Mathematics. - 2009. - nov. - problème. 2. - p. 115-150.- URL: cyberleninka.ru/article/n/kriptograficheskie-protokoly-osnovnye-svoystva-i-uyazvimosti.pdf .

Postface

L'auteur sera reconnaissant des commentaires factuels et autres sur le texte. La présentation et le texte ont été préparés en grande partie sur l'excellente conférence de Cheryomushkin (lien ci-dessus).