Ceci est une ancienne révision du document !


cryptographie certificats x509

Les clés du chiffrement

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 1) ou SHA 2).

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 :

  • l'empreinte d'un message est complètement significative de ce message. Il n'y a pratiquement aucune chance que deux messages différents puissent avoir la même empreinte,
  • la modification d'un seul bit dans le fichier original va considérablement modifier son empreinte,
  • le procédé est irréversible, c'est à dire qu'il est extrêmement difficile de reconstituer le message à partir de son empreinte.

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 :

  • les clés symétriques, on chiffre et déchiffre avec la même clé.
  • les clés asymétriques, avec une clé publique et une clé privée, ce qui est chiffré avec l'une ne peut être déchiffré qu'avec l'autre.
    Les deux clés sont uniques et sont liées l'une à l'autre, mais si la clé privée reste confidentielle, la clé publique, elle, peut être copiée à volonté.

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 :

  • chaque personne dispose d'un jeu de clés comportant :
    • une clé privée : elle est unique et confidentielle, elle appartient exclusivement à l'hôte concerné, il ne la distribue à personne, aucun double de cette clé ne doit être créé,
    • une clé publique : elle est unique également, mais tout le monde peut s'en procurer une copie, il suffit d'aller la chercher chez un dépositaire, dit « tiers de confiance ». Il s'agit en quelque sorte d'un concierge qui garde ces clés publiques et certifie qu'elles appartiennent bien à la personne indiquée,
  • ce qui est chiffré avec une clé publique ne peut être déchiffré qu'avec la clé privée correspondante,
  • ce qui est chiffré avec la clé privée ne peut être déchiffré qu'avec la clé publique correspondante.

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

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 :

  • L'empreinte réalisée est intimement attachée au contenu de mon message, si le message est intercepté et modifié, l'empreinte devra être recalculée,
  • comme l'empreinte a été signée avec ma clé privée, je suis le seul à pouvoir le faire, donc toute modification ultérieure à l'envoi ne pourra pas être signée avec la bonne clé (aussi longtemps que ma clé privée restera secrète).

Lorsque le destinataire recevra le message signé :

  • le destinataire recalcule l'empreinte du message reçu,
  • il déchiffre l'empreinte signée avec la clé publique de l'expéditeur,
  • il compare les deux empreintes. Si elles sont identiques, c'est que le message :
    • est bien conforme à l'envoi, puisque les empreintes sont identiques,
    • est bien envoyé par l'expéditeur propriétaire de la clé publique avec laquelle l'empreinte signée a été déchiffrée.

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 :

  • comme j'ai chiffré avec la clé publique du destinataire, le message sera illisible pour qui ne détiendra pas la clé privée correspondante,
  • comme seul le bon destinataire, normalement, détient cette clé privée, il sera le seul à pouvoir déchiffrer le message.

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 :

  • Je réalise une empreinte de mon message et je la chiffre avec ma clé privée pour l'authentifier,
  • je chiffre le message lui-même avec la clé publique du destinataire pour le rendre confidentiel;
  • j'envoie le tout au destinataire.

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 :

  • comme il est le seul à pouvoir déchiffrer avec sa clé privée, le message est bien confidentiel,
  • comme je suis le seul à pouvoir chiffrer l'empreinte avec ma clé privée, le message est bien authentique.

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

  • il faut chiffrer et déchiffrer deux fois au lieu d'une, comme on le ferait avec une clé symétrique,
  • le chiffrement/déchiffrement avec des clés différentes est une opération mathématique plus lourde, plus coûteuse en ressources CPU.

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.

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

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 3)) 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 sure. 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):

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

Et bien entendu, le certificat contient une 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 :

  • les autorités de certification sont hiérarchisées, il y a des autorités racines et des autorités intermédiaires, ce qui aboutit à une structure arborescente. Si deux autorités intermédiaires sont certifiées par une même autorité  hiérarchiquement supérieure, elles appartiennent au même arbre et donc la confiance est mutuelle, nous avons ici un arbre de confiance,
  • deux arbres différents peuvent à un niveau quelconque (mais supérieur à celui des partenaires impliqués), établir entre eux un lien de confiance mutuelle, ce qui donne naissance à des réseaux de confiance.

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 :

  • récupération des demandes de certificats,
  • réalisation des certificats,
  • tenue de la liste de révocation,
  • distribution des certificats aux demandeurs…

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 nœuds d'un même réseau.

A quel niveau chiffrer

Dans la pile des protocoles réseau, il est courant d'utiliser le chiffrement :

  • dans le noyau du système, au niveau IP, avec IPsec. Ainsi, tout ce qui passera sur le réseau sera automatiquement chiffré suivant les règles établies sans que les applications n'aient à s'en soucier,
  • dans l'espace utilisateur, au niveau des applications elles-mêmes, qui choisiront ou non de chiffrer, avec par exemple, SSL.  HTTPS en est une illustration, comme IMAPS, POPS ou encore SSH.

SSL, développé au départ par Netscape a été repris en OpenSource sous le nom de TLS : Transport Layer Security. Protocole de sécurisation de la couche transport, défini par la RFC 2246. La version 1.0 de TLS est en fait SSL v3.

1)
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 extrêmement difficile de retrouver le message à partir de son hachage.
2)
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 l'irréversibilité : connaissant le haché d'un message, il est extrêmement difficile de reconstituer le message ; l'absence de collision : il est extrêmement difficile de trouver deux messages différents produisant le même haché. En outre, la modification d'un seul bit du message d'entrée produit un haché qui aura en moyenne la moitié des octets différents.
3)
Certificate Authority. Tierce Partie de Confiance en français