Cryptographie et tunnel OpenVPN
08/02/2005
 Christian CALECA 
Liste des cours

Les clés du chiffrement

Accueil ] [ Avant propos ] [ Les clés du chiffrement ] [ Méthodes ] [ OpenVPN simple ] [ OpenSSL ] [ Tunnel sécurisé ] [ Applications ]


Résumons nous.

En cryptographie numérique, chiffrer une information consiste à modifier la suite d'octets qui constituent cette information au moyen d'un algorithme mathématique.

L'algorithme étant normalisé, il peut être connu de tout le monde. Ainsi, pour que le secret soit assuré, il faudra que cet algorithme utilise un paramètre supplémentaire appelé une clé. Une information chiffrée avec un algorithme connu restera déchiffrable par les seuls possesseurs de la clé appropriée, même si l'algorithme est connu de tous. Les clés de chiffrement sont donc les éléments essentiels dans la garantie du secret souhaité.

Une fois le procédé mis en place, nous pouvons en attendre quelques services.

Confidentialité

L'usage auquel on pense en premier est naturellement la confidentialité des données. Le premier désir est bien que les messages ne soient lisibles que par les seules personnes autorisées.

C'est bien, mais c'est loin de suffire, pour assurer une totale relation de confiance.

Contrôle d'intégrité et authentification

Intégrité

Dans certains cas, il peut être nécessaire d'assurer simplement que les données sont intègres, c'est à dire qu'elles n'ont pas été au passage falsifiées par un intrus. Ces données restent "claires", au sens où elles ne sont pas secrètes.

Un exemple simple : je propose en téléchargement un fichier contenant une application informatique. Je voudrais éviter qu'un intrus ne puisse, par un moyen quelconque, dénaturer mon application et y introduisant, par exemple, un "root kit".

Mon code est sous licence GPL, les sources sont disponibles, je ne veux pas rendre mon application secrète, je veux juste en assurer l'intégrité du code.

Je vais donc réaliser un "résumé concis" de mon fichier, typiquement une somme MD5 (ou SHA). Ce résumé est suffisamment précis pour qu'il puisse mettre en évidence toute modification ultérieure de mon fichier. Bien sûr, nous parlons ici de mathématiques. Un résumé MD5 d'un fichier contenant l'image ISO d'un DVD ROM d'installation d'une distribution linux, par exemple, serait de la forme : 5025c41edf87b679f036377013234d9b (MD5sum du DVD d'installation de la fedora core 2).

Ce résumé concis, ou empreinte, dispose de caractéristiques fondamentales :

Bien. Mais sans précautions supplémentaires, ça ne va pas suffire, parce que celui qui arrivera à corrompre mon fichier en téléchargement, pourra sans doute modifier aussi l'empreinte, pour qu'elle soit celle du fichier corrompu.

Une empreinte, si elle utilise bien un procédé de chiffrement, ne dispose pas d'un secret. l'algorithme utilisé (MD5, SHA...) est public et s'il n'est pas possible de reconstituer un message à partir de son empreinte, il est en revanche tout à fait possible pour quiconque de recalculer une empreinte après modification de l'information.

Typiquement, une somme MD5, sans précautions particulières, ne servira qu'à vérifier que le fichier n'a pas été corrompu lors du téléchargement, mais elle n'apportera pas la preuve de l'authenticité du fichier en téléchargement.

Il faudra donc trouver en plus, un moyen pour certifier l'authenticité de cette empreinte.

Authentification

Il s'agit d'apporter par la cryptographie la preuve que le message est bien authentique. Compte tenu de ce que nous venons de voir, il suffira dans la plupart des cas de pouvoir assurer que l'auteur de l'empreinte du message est bien celui qu'il prétend être. Il s'agit en quelque sorte d'une lettre manuscrite, non raturée et signée.

Non répudiation

C'est le corollaire direct de l'authentification. Celui qui qui a rédigé une lettre manuscrite, non raturée et signée de sa main, ne pourra en aucun cas prétendre par la suite qu'il n'en est pas l'auteur. Il en va de même pour l'authentification numérique.

Les clés, leurs types et leurs utilités

Il y a deux types de clés :

Il s'agit en fait d'un abus de langage. Les clés ne sont pas symétriques ni asymétriques, ce sont les procédés de chiffrement qui le sont

Chiffrement symétrique

C'est le plus facile à comprendre, c'est aussi la méthode de chiffrement la plus facile à réaliser et qui consomme le moins de ressources de calcul et de bande passante.

Les deux hôtes qui doivent échanger des données confidentielles (secrètes) disposent tous les deux d'une clé identique. L'émetteur chiffre les données avec, puis les envoie au récepteur. Ce dernier déchiffre avec la même clé pour récupérer des données lisibles.

Cette méthode assure la confidentialité des données, celui qui intercepterait la communication ne pourra pas lire les données échangées tant qu'il n'aura pas pu se procurer la clé. Il n'y a aucune authentification de faite sur l'émetteur comme sur le récepteur, sauf si deux personnes seulement disposent de la clé.

Le principal souci avec cette méthode, c'est qu'il faut s'échanger la clé et lors de cet échange, sans précautions particulières, n'importe quoi peut se produire.

Chiffrement asymétrique

Cette méthode permet de faire aussi bien l'authentification que la confidentialité des données. Il est évidemment possible de combiner les deux.

Principes de base

Là, c'est un peu plus complexe et il vaut mieux bien suivre pour ne pas se perdre :

Tout ceci peut à première vue paraître absurde, puisqu'il y a à chaque fois une clé qui peut être récupérée par n'importe qui. Oui mais...

Authentification

authentification

Je réalise une empreinte avec un algorithme non réversible (MD5, SHA...). Cette empreinte ne permet pas de reconstruire le message original, mais elle représente "à coup sûr" un résumé de mon message original. Un simple bit modifié dans le message donnerait une empreinte complètement différente.

Je chiffre cette empreinte avec ma clé privée et l'envoie, avec le message en clair, au destinataire.

Mon message n'est pas confidentiel, il est envoyé en clair. Mais :

Lorsque le destinataire recevra le message signé :

déchiffrement

Voilà résolu le problème de la signature (authentifiée). Ce type de signature engage l'expéditeur. Il ne peut nier avoir envoyé cette information, puisqu'il l'a signée sans falsification possible, pour autant que l'on soit sûr de l'authenticité de la clé publique.

Confidentialité

Je chiffre mon information avec la clé publique du destinataire, et je lui lui envoie cette information. N'importe qui peut faire de même, puisque le chiffrement se fait avec une clé publique. N'importe qui peut récupérer la clé publique de n'importe qui chez le concierge.

Donc, le message n'est pas authentifié, mais :

Je n'ai pas pu m'authentifier auprès du destinataire, mais j'ai pu lui envoyer un message confidentiel, puisqu'il est le seul à pouvoir le déchiffrer.

Les deux

Vous avez compris le principe ? Alors, faire les deux devient simple :

les deux

Le destinataire déchiffrera le message avec sa clé privée, en calculera localement l'empreinte, puis déchiffrera l'empreinte envoyée avec ma clé publique :

Bon. Ca roule, mais vous comprenez bien que l'opération est lourde :

Rappelons que le principal problème du chiffrement symétrique, est qu'il faut s'échanger l'unique clé à un moment donné et que, lors de cet échange, quelqu'un pourrait l'intercepter.

Ce problème va être résolu magistralement de la façon suivante :

Un échange authentifié et confidentiel

Dans un échange d'informations (tunnel VPN par exemple), l'idéal, pour économiser les ressources CPU et augmenter le débit de l'échange, serait de trouver un moyen sûr d'échanger entre les partenaires une clé symétrique. Avec ce que nous savons, c'est relativement facile à réaliser.

Dans un premier temps, je fabrique une clé symétrique, à usage limité dans le temps, que nous appellerons une clé de session, usine

Je vais envoyer à mon interlocuteur cette "clé symétrique", que je vais authentifier et rendre confidentielle par les méthodes vues plus haut.

clés

Et voilà le travail. Nous sommes deux à disposer de la même clé, transmise par une voie sécurisée. 

La suite de l'échange pourra être chiffrée et déchiffrée avec cette clé de façon symétrique. Mais comme ça ne suffit pas, cette clé aura une durée de vie assez courte, quitte à devoir en échanger une nouvelle en cours de dialogue.

En effet, un intrus qui suivrait la discussion pourrait, au moyen d'outils faits exprès pour, finir par découvrir la clé symétrique, parce qu'il dispose d'un volume suffisant de données chiffrées, qu'il a eu le temps de trouver la clé grâce à la puissance de ses outils de cryptanalyse. Il faudra donc donner à la clé une durée de vie inférieure au temps nécessaire estimé pour la découverte de la clé.

Plus la clé sera "compliquée", plus ce temps sera long, mais plus les temps de chiffrement et de déchiffrement seront longs eux aussi. Tout est donc ici affaire de compromis.

Le tiers de confiance

Vous l'avez compris, cette magnifique mécanique ne fonctionnera qu'à une condition : le "concierge"  (CA) qui détient les clés publiques doit être digne de confiance, faute de quoi, n'importe quoi peut se produire...

Que pourrait-il arriver si une clé publique n'appartenait pas réellement à la personne indiquée ? Tout simplement une personne pourrait se faire passer pour une autre. Une fausse carte d'identité, en quelque sorte.

Tout repose donc sur la confiance que l'on peut mettre dans la personne qui détient les clés publiques.

Généralement, il s'agit d'un organisme de réputation sérieuse , à qui l'on confiera sa clé publique, et dont on détient la clé publique de façon sûre. La clé publique de l'organisme permettra de vérifier l'authenticité dudit organisme.

Les certificats

Il existe dans le monde plusieurs organismes (CA) de ce type. Leurs services, est-il nécessaire de le dire, ne sont pas gratuits, loin de là.

Lorsque je m'adresse à un tel organisme pour récupérer une clé publique, il me l'enverra avec un certificat. En gros, il s'agit pour ledit organisme de chiffrer la clé publique demandée, ainsi que quelques informations supplémentaires sur le propriétaire de cette clé, avec sa propre clé privée, pour authentifier son envoi. Il me reste à disposer de la clé publique du tiers de confiance, par un moyen sûr. Les certificats sont à la norme X.509.

Si je suis sûr de la clé publique du tiers et si j'ai confiance en lui, alors je pourrai mettre aussi ma confiance dans les clés publiques qu'il me distribuera.

Votre navigateur a installé, peut-être à votre insu, des certificats de divers organismes de certification (exemple avec Mozilla Firefox):

certificate

Voici un résumé du contenu d'un certificat :

contenu

Et bien entendu, le certificat contient une clé publique :

clé publique

Comme une clé s'use (le volume de données chiffrées avec devient trop important, ce qui risque d'augmenter significativement les chances de découverte de cette clé), il faudra prévoir une durée de vie à cette clé et donc au certificat.

Comme une clé peut se perdre ou être volée , il faudra aussi prévoir un système "d'opposition". Une liste de révocation, qui permet de signaler les certificats non encore expirés, mais qui ne sont plus dignes de confiance pour une raison quelconque. La CA se doit donc de tenir à jour une liste de révocation, et, lorsqu'un utilisateur doit user d'un certificat qui est déjà en sa possession, il devrait commencer par vérifier si celui-ci n'a pas été révoqué entre temps.

Comme nous sommes dans un monde imparfait (d'ailleurs, si nous étions dans un monde parfait, les clés ne seraient d'aucune utilité), il peut se faire que l'usage de certains types de clés particulièrement "solides" soit réglementé. Il peut se faire qu'un exemplaire de la clé privée doive être mis sous séquestre, à disposition éventuelle des services de renseignements. Des organismes spécialisés dans cette mise sous séquestre de clés privées existent à cet effet.

Arbres et réseaux de confiance

Normalement, si deux interlocuteurs disposent chacun d'un certificat, mais chez des CA différentes, ils ne peuvent à priori se faire mutuellement confiance, sauf si par un procédé quelconque les deux CA affichent une confiance mutuelle. Entrer ici dans les détails nous mènerait vraiment trop loin, mais sachons tout de même que :

Le réseau de connaissances

Une autre méthode consiste à utiliser un réseau de connaissances. J'ai, en principe, confiance dans mes amis et les amis de mes amis sont mes amis, donc, je peu faire confiance à une clé publique qui est contresignée par un ami dont je suis sûr. Ca peut aller loin, c'est le principe de l'homme qui a vu l'homme qui a vu l'homme qui a vu l'homme qui a vu Dieu.

C'est aussi le principe adopté en messagerie électronique par des procédés de signature comme GNUpg.

Les PKI

Les Public Key Infrastructures regroupent tout ce qui est nécessaire à la gestion des clés publiques et des certificats :

Lorsqu'une organisation désire mettre en place une telle infrastructure, sans avoir recours à des entreprises spécialisées, il lui est possible de le faire.

Bien entendu, les certificats produits n'auront de valeur qu'au sein de cette organisation. Il existe des projets Open Source qui proposent des outils de gestion d'infrastructure de clés publiques. Nous n'irons pas aussi loin dans cet exposé.

Bref...

Le principe est donc assez simple, il faut au départ disposer de clés publiques appartenant à des gens dont on est sûr. Si ces gens dont on est sûr me certifient comme étant authentiques des clés de gens que je ne connais pas, ces clés publiques seront à leur tour réputées sûres.

Vous voyez la limite d'un tel système ? Non ? Alors, imaginez que dans la chaîne, il y ait une clé falsifiée qui passe pour authentique, à la suite d'une malversation quelconque. Alors, toutes les clés certifiées par cette clé falsifiée pourront être ou ne pas être authentiques... 

Il est donc assez illusoire d'imaginer ce système comme parfaitement sûr. Fort heureusement, dans la plupart des cas, un seul administrateur certifiera les clés dont nous aurons besoin pour, par exemple, créer un tunnel sécurisé ou simplement une authentification entre deux noeuds d'un même réseau.


CA
Certificate Authority. Tierce Partie de Confiance en français.

(retour)

MD5
Message Digest 5. Fonction définie dans la RFC 1321. Il s'agit d'un hachage unidirectionnel, permettant d'identifier un message, car deux messages produiront deux hachages différents, et il est impossible de retrouver le message à partir de son hachage.

(retour)

SHA
Secure Hash Algorithm. Algorithme de hachage Sécurisé, c'est-à-dire qu'il calcule l'empreinte d'une suite d'octets. L'entrée peut être de taille quelconque, la sortie fait toujours 20 octets. Les caractéristiques de SHA (comme tous les algorithmes de hachage) sont : 

(retour)

Toutes ces définitions sont issues du Jargon Français


Précédente ] [ Accueil ] [ Suivante ]