principes de base

Cette page reprend le chapitre précédent, la répétition étant la base de l'enseignement.

Le chiffrement repose essentiellement sur deux éléments complémentaires:

• un algorithme mathématique permettant de «tordre» et de «détordre» les données de manière telle que seuls les deux protagonistes puissent se comprendre. Cet algorithme mathématique est publique, donc tout le monde (presque) peut savoir exactement comment les données sont tordues et détordues. Autrement dit, tout seul, cet algorithme ne sert à rien. D'où la nécessité du second élément:
• une clé de chiffrement et/ou de déchiffrement. L'algorithme se sert de cette clé (ou de ces clés) pour faire son travail et c'est la confidentialité de ces clés qui assure la confidentialité du tout.

Le «chiffre» plus souvent appelé «la cryptographie» permet ces choses fondamentales dans une relation de confiance:

1. la confidentialité, qui permet d'échanger à l'abri des oreilles indiscrètes,
2. l’authenticité, qui permet d'être certain que le partenaire est bien celui qu'il prétend être,
3. l'intégrité, qui permet d'être sûr que le message reçu n'a pas été modifié pendant son transport.

Tous ces points devraient être assurés lors de l'échange de données privées, dont le plus bel exemple est une transaction monétaire à travers le bouge qu'est l'internet.

Le principe de base repose sur deux composants essentiels:

1. un algorithme de chiffrement dont la robustesse est éprouvée, le meilleur moyen étant d'en publier le code pour que toute personne en ayant les compétences puisse l'étudier, y déceler des failles et les corriger. Ceci implique que cet algorithme, connu de tous, nécessite un élément supplémentaire qui lui, devra être variable et le plus souvent confidentiel ou au moins dont une partie soit confidentielle,
2. une clé de chiffrement à injecter dans algorithme pour permettre le chiffrement et/ou le déchiffrement du message.

Ici la même clé sert à chiffrer et déchiffrer, ce qui sous-entend que les deux parties disposent en secret de la même clé. Ceci, sous réserve que le secret entourant la clé n'ait pas fuité, va essentiellement assurer la confidentialité du dialogue.

Se pose alors l'épineux problème de l'échange de cette clé entre les deux parties qui doit se faire de façon confidentielle et sûre. Il va falloir trouver une solution solide pour cet échange.

Il repose sur une paire de clés dont l'une est privée et l'autre publique. Ce qui est chiffré par l'une ne peut être déchiffrée que par l'autre (et réciproquement). Ce concept est récent et n'a été développé qu'à partir du XX^eme siècle.

Il y a donc deux possibilités:

• chiffrer avec une clé privée, et tout le monde pouvant se procurer la clé publique correspondante (de façon légale, puisqu'elle est réputée publique) pourra déchiffrer le message…
• chiffrer avec une clé publique un message et seul me propriétaire de la clé correspondante pourra le déchiffrer.

Le problème résiduel étant de garantir l'authenticité du propriétaire de la clé publique. Dans la pratique, il faudra faire appel à une autorité de certification (Certificat Authority) qui garantira que la clé publiquement exposée appartient bien à celui que s'en prétend propriétaire.

Il y aura une procédure à suivre, pour satisfaire à cette exigence, détaillée un peu plus loin. En attendant, considérons comme acquis ce qui suit:

Un certificat (au format de la norme X509) contient en substance:

1. une clé publique,
2. l'intitulé du propriétaire,
3. l'organisme qui en certifie la légitimité
4. une durée de validité

sera fourni à qui en aura fait la demande légitime.

Tout ceci ressemblant finalement à une carte d'identité, dont le titulaire dispose de la clé privée correspondante. Il pourra ainsi chiffrer une information que tout le monde pourra déchiffrer après acquisition du certificat X509 correspondant.

Un serveur, contacté par un client λ signe un message avec sa clé privée, et diffuse dans la foulée son certificat X509. Le client λ peut alors déchiffrer le message avec la clé publique contenue dans le certificat reçu. Après avoir vérifié que ce certificat est validé par une CA, le client λ est donc certain de l'origine du message. En effet, si un indélicat a publié le certificat d'un tiers, il ne peut normalement pas disposer de la clé privée correspondant et ne pourra donc pas signer quoi que ce soit pouvant être déchiffré avec la clé publique usurpée.

Dans la pratique, le message pouvant être long, on effectue un «hachage((Opération mathématique permettant de déduire une chaîne de caractères de longueur constante, quelle que soit la taille du message, et parfaitement représentative du contenu du message. un changement si infime soit-il du message aboutissant à un hachage totalement différent.

Le message lui-même sera transmis en clair, seul son hachage sera chiffré avec la clé privée. Bien sûr, le contenu du message en clair pourrait être falsifié. Cependant, à l'arrivée chez le client ce dernier va:

1. calculer le hachage du message clair,
2. déchiffrer avec la clé publique du X509 le hachage initial chiffré;
   1. s'il ne peut pas le déchiffrer, l'opération s'arrête. quelque chose a foiré.
   2. s'il peut le déchiffrer, il le compare alors au hachage qu'il a calculé localement
      1. s'ils sont différents, l'opération s'arrête, quelque chose a foiré.
      2. s'ils sont égaux, ceci veut dire deux choses:
         1. le déchiffrement du hachage original prouve que son auteur est bien celui qu'il prétend être, sur la foi de l'authenticité du certificat X509,
         2. l'égalité des deux hachages démontre l'intégrité du message reçu.

Ici, Nous avons réalisé deux opérations fondamentales:

1. l'authenticité, grâce au déchiffrement réussi du hachage d'origine,
2. l'intégrité, grâce à l'égalité des hachages original et calculé localement.

Le client ayant reçu le X509 du serveur et s'étant assuré de sa légitimité va pouvoir chiffrer un message avec la clé publique contenue dans le certificat en sachant que seul le propriétaire de la clé privée correspondante pourra le déchiffrer. Cette méthode, mise en œuvre dans le protocole SSL originel pour partager une clé symétrique, n'est plus utilisée actuellement.

Pour obtenir un certificat X509 validé (signé) par une Autorité de Certification, il faut:

1. construire un couple de clés privée/publique,
2. envoyer la clé publique à une autorité compétente, avec des éléments permettant à cette autorité de garantir la légitimité du certificat à fournir. Dans la pratique, le certificat servant essentiellement à garantir le nom complet d'un serveur, la CA va fonctionner de la façon suivante:
3. la CA va vérifier au moyen d'une requête DNS que ce nom complet de serveur existe bien,
4. elle va vérifier que le serveur en question répond bien à une requête HTTP. Si c'est le cas, c'est que le serveur existe bien sous ce nom, qui figurera dans le certicficat. L'expérience est plus facile à faire avec HTTPS, mais le processus reste le même pour tout protocole d'application s'appuyant sur TLS.

Lorsque l'on navigue vers https://www.laposte.fr, le cadenas qui apparaît à gauche de l'URL permet d'obtenir des informations sur le certificat X509 que le site nous a envoyé:

1. C'est bien la société «LAPOSTE SA» qui l'a émis,
   
   
2. il est certifié par Global Sign qui est une autorité de certification reconnue.

Il est possible d'extraire quelques informations remarquables de ce certificat:

• sa période de validité:

          Validity
              Not Before: Jun  9 07:46:26 2026 GMT
              Not After : Dec 25 07:46:26 2026 GMT

• son sujet principal:

          Subject: businessCategory = Private Organization, serialNumber = 356 000 000, jurisdictionC = FR, C = FR, ST = \C3\8Ele-de-France, L = Paris, O = LA POSTE SA, CN = www.laposte.fr

• Tous les URL habilités à présenter ce certificat:

   Subject Alternative Name: 
                  DNS:www.laposte.fr, DNS:www.laposte.com, DNS:api.boutique.laposte.fr, DNS:boutique.laposte.fr, DNS:boutiqueducourrier.laposte.fr, DNS:buralistes.laposte.fr, DNS:cdnstaging.lpel.net.extra.laposte.fr, DNS:m.laposte.fr, DNS:pro.boutique.laposte.fr, DNS:pro.boutiqueducourrier.laposte.fr, DNS:laposte.fr

  Tous ces URL sont vérifiés par l'autorité de certification bien sûr.

• l'usage principal de ce certificat:

  Key Usage: critical
                  Digital Signature

  Le fait d'être «critique» signifie que le client doit s'assurer d'avoir correctement compris tout le contenu du certificat avant de se servir de la clé publique contenue pour valider une signature.

• l'usage étendu:

  Extended Key Usage: 
                  TLS Web Server Authentication, TLS Web Client Authentication

Il y a, bien entendu, bien d'autres informations techniques, le but n'étant pas ici de décortiquer complètement un certificat X509.

Pour vérifier la validité d'un certificat, les navigateurs disposent d'une collection de certificats d'autorités de certification. Ces certificats, comme tous les X509 contiennent la clé publique de la CA, ce qui permet au client de vérifier la signature par ladite CA des certicicats correspondant. Ils ont un intervalle de validité déterminé, ce qui nécessite leur mise à jour régulière.

Pour être certain de ne pas rater la présence de ces mises à jour, deux solutions sont possibles:

• installer le paquet unattended-upgrades
  Description :
  installation automatique des mises à jour de sécurité
  Ce paquet peut télécharger et installer les mises à jour de sécurité automatiquement sans intervention, en se basant uniquement sur les paquets installés depuis les sources APT configurées, et en vérifiant les changements de fichiers de configuration par dpkg.
• instller le paquet apticron
  Description :
  outil simple pour envoyer un courriel en cas de mise à jour de paquet en attente –⋅version cron
  Apticron est un simple script qui envoie un courriel quotidien lorsqu'une mise à jour de paquet est en attente, comme les mises à jour de sécurité, ou des paquets en attente aussi bien dans dselect qu'aptitude.

1. le serveur contacté en HTTPS envoie son certificat X509, avec une signature au moyen de sa clé privée.
2. le client, après avoir vérifié l'authenticité du certificat, déchiffre la signature, ce qui lui assure à son tour l'authenticité du serveur.
3. le client et le serveur vont alors entamer un dialogue qui doit aboutir à la création d'une clé «de session» identique chez les deux partenaires de façon confidentielle. C'est le protocole TLS qui va le permettre.