Basiques des échanges sécurisés

Introduction

Ce petit article, sans prétention, a pour but de revoir les basiques de la cryptographie. Si tu es un développeur, et que tu ne comprends pas les notions de certificats et de chaines de certificats d’autorités, alors, tu es au bon endroit !

Bonne lecture…

But/définition de la Cryptographie

Sans faire un cours d’histoire, l’être humain a toujours eu besoin de pouvoir communiquer de manière sécurisée. César, à l’époque de l’antiquité, avait le ROT 13 qui permutait de 13 rangs chaque lettre de l’alphabet pour chiffrer ses messages. Ce qui n’était bien sûr pas super sécurisé, car la répétition des mots usuels se traduit par la même succession de lettre. On casse donc le code assez rapidement sans ordinateur.

On peut dire que pour être sécurisé à 100%, 4 grandes notions doivent être respectées :

La confidentialité : mécanisme pour transmettre des données, de sorte que seul le destinataire souhaité puisse les lire;

L’intégrité : mécanisme pour s’assurer que les données reçues n’ont pas été modifiées durant la transmission;

L’authentification : mécanisme pour permettre d’identifier des personnes, ou des entités, et de certifier leur identité;

La non répudiation : mécanisme pour enregistrer un acte, un engagement d’une personne ou d’une entité, de sorte que celle-ci ne puisse pas nier avoir accompli cet acte, ou pris cet engagement.

Nous allons voir comment s’assurer de l’application de ces 4 principes, dans nos échanges entre nos applications ou nos utilisateurs.

2 grandes écoles de chiffrement

2 grandes façons de chiffrer existent, le chiffrement symétrique (ou à clé privée) et l’asymétrique (ou à clé publique). On verra plus tard qu’ils peuvent s’utiliser conjointement.

Un schéma d’explication sur leur fonctionnement sera plus clair qu’un long discours :

Sans titre

La différence se situe au niveau des clés : dans le cas du protocole à clé secrète, il faut qu’Alice transmette sa clé de manière sûre à Bob, sinon, tout le monde sera capable de lire son message. La sécurité de cette technique repose uniquement sur l’échange de la clé secrète.

Le saviez-vous ?

Si vous faites un « ou exclusif » entre un message et une clé de même taille à usage unique alors le chiffrement est parfaitement sécurisé (One Time Pad). Mais on imagine aisément pourquoi c’est très contraignant (il faut avoir une nouvelle clé pour chaque message, la transmettre au destinataire,…).

Alors que pour le protocole à clé publique, la clé publique peut justement être vue de tous. Pour déchiffrer les messages qu’on lui envoie, Bob devra utiliser sa clé privée. On est sûr que seul Bob peut lire le message.

Bon, avec une petite analyse du scénario avec clé publique, on voit que le scénario décrit assure la confidentialité de la donnée, mais pas l’intégrité,  ni l’authentification et surement pas la non répudiation.

Pour vous expliquer comment palier à ce problème, je dois vous introduire la notion de Hash.

Notion de Hash ou de condensat

Une fonction de hachage permet de calculer un résumé (condensat) de la donnée. Cette opération est irréversible (en théorie). La moindre modification de la donnée change de manière non prédictible le hash associé.

Exemples :

« soprasteria » donne « 8e6333c588f6c10c65cc31f6551b4d7686ca7c69930be464f90d8ffdc4d86d9a » (SHA256)

« soprasteriaa » donne « 3c9af2440382b5ebb9df8463946274a8eff826504c6ea3fd197789903093fbff » (SHA256)

Le hachage est utilisé dans différents domaines :

  • Création d’une clé pour indexer des structures longues;
  • Vérification d’intégrité des structures longues;
  • Comparaison des mots de passe.

Attention aux collisions d’une fonction de hachage, qui, à partir d’un couple de données de départ distinct, donne une somme de contrôle identique. Certains algorithmes sont donc dépréciés comme le MD5 et le SHA-1. Aujourd’hui, l’utilisation des algorithmes SHA-256 ou SHA-3 est fortement recommandée.

Malheureusement, il reste possible de cracker le système, à l’aide de tables de hachage correspondant à des valeurs (telles que des mots de passe) souvent utilisées.

  • D’où l’intérêt de choisir un mot de passe non prédictible.

Pour se protéger de ce type d’attaque, le hash est souvent associé à la notion de sel :

Le salage (salting en anglais) consiste à ajouter une chaîne de caractères à l’information avant le hachage. Par exemple, au lieu de hacher le mot de passe seul, on peut le faire sur le résultat de la concaténation du mot de passe avec une autre chaîne de caractères pseudo-aléatoire, obtenue par un hachage de l’identifiant (login) concaténé avec le mot de passe.

  • Cela permet de renforcer la sécurité de cette fonction.

Le simple ajout d’un sel avant hachage rend caduque l’utilisation de ces tables de hachage , et le craquage doit faire appel à des méthodes telles que l’attaque par force brute (méthode consistant à tester toutes les valeurs possibles).

Bon, c’est bien gentil tout ça, mais qu’est-ce que je fais avec ce Hash ?

Workflow d’échange asymétrique respectant les 4 principes de la crypto

Objectif : Bob souhaite envoyer des données chiffrées à Alice, en lui garantissant qu’il en est l’expéditeur, et que cette donnée n’a pas été altérée en chemin.

  • Bob crée une paire de clés asymétriques : il conserve la clé privée et diffuse librement la clé publique (notamment à Alice);
  • Alice crée une paire de clés asymétriques : clé privée (qu’elle conserve), clé publique (qu’elle diffuse librement, notamment à Bob);
  • Bob effectue un hash de son message « en clair » puis chiffre ce hash avec sa propre clé privée => il crée la signature électronique du message;
  • Bob chiffre son message avec la clé publique d’Alice;
  • Bob envoie le message chiffré accompagné de la signature électronique.

La partie “envoi de Bob” est terminée, maintenant, Alice va essayer de lire le message :

  • Alice reçoit le message chiffré de Bob, accompagné de la signature électronique;
  • Alice déchiffre le message avec sa propre clé privée. À ce stade, le message est lisible, mais elle ne peut pas être sûre que Bob en soit l’expéditeur;
  • Alice déchiffre la signature électronique avec la clé publique de Bob;
  • Alice utilise la même fonction de hachage sur le texte en clair et compare avec le hash déchiffré de Bob;
  • Si les deux hash correspondent, alors Alice peut avoir la certitude que Bob est l’expéditeur, et que le message n’a pas été modifié.

(Ce workflow est très largement inspiré de l’article Wikipédia https://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique)

2 petites remarques :

  • La notion d’intégrité se fait par le chiffrement du hash par une clé privée, que l’on appelle aussi signature électronique du document;
  • Tout est basé sur la confiance que l’on accorde à la clé publique, ou comment contrôler que la clé publique appartient bien à celui qui le prétend ?

Donc tout repose sur la notion de certificat !!!

Mais, c’est quoi exactement un certificat ?

On peut voir un certificat comme un « wrapper » d’une clé publique, il contient celle-ci, et ajoute des informations s’assurant qu’elle appartient à la bonne personne.

L’idée est plutôt de dire qu’une entité, en laquelle on croit aveuglement (une autorité de certification ou tiers de confiance), nous assure de l’identité du propriétaire de cette clé publique.

Donc le certificat contient, en résumé :

  • La clé publique de son détenteur, et des informations sur son identité;
  • Le nom distinctif de l’autorité de certification (l’entité que l’on croit aveuglement);
  • La signature électronique (chiffrement du condensat par la clé privée de l’AC) de l’autorité de certification (AC).

Maintenant, abordons le mécanisme d’obtention d’un certificat pour Bob, auprès d’une autorité de certification nommée d’AC1:

  1. Bob génère sa clé privée ainsi qu’un CSR contenant la clé publique (Certificate Signing Request);
  2. Bob envoi le CSR à AC1 ainsi que des justificatifs de son identité;
  3. AC1 renvoi le certificat à Bob contenant la clé publique de Bob + la signature électronique d’AC1;
  4. Bob peut donc diffuser son certificat à toute entité croyant AC1.

Il faut savoir qu’une AC, est très souvent une chaine de certificat qui sont issue les uns des autres (le certificat racine a permis de faire le certificat n-1, qui lui-même a permis de faire le certificat n-2, et ainsi de suite…). Ce principe permet de créer un arbre de certification :

Sans titre2

Le certificat racine est auto signé, il assure lui-même qu’il est bien lui-même ;-). Il faut bien croire en quelqu’un, en début de chaîne !!!

Cette ensemble constitue ce que l’on appelle une PKI (Public Key Infrastructure) ou IGC, en français (infrastructure de gestion de clés).

Bon, j’avoue, je prends un raccourci, ce que je viens de décrire est en fait le fonctionnement des certificats de type X509.

Il existe un autre format nommé OpenPGP.

La différence notable entre ces deux formats, est qu’un certificat X509 ne peut contenir qu’un seul identifiant, et ne peut être signé que par une seule autorité de certification.

Un certificat OpenPGP peut contenir plusieurs identifiants, qui peuvent être signés par une multitude d’autres certificats OpenPGP.

=> La notion de toile de confiance apparaît, je ne crois plus une AC, mais un nombre significatif de personnes dans mon réseau. Corrompre ce réseau est plus compliqué que cracker une AC.

Malheureusement, cette notion de toile de confiance n’est que très peu utilisée en entreprise.

Performance du chiffrement asymétrique

J’ai encore une fois pris un raccourci pour faciliter l’explication. Le chiffrement asymétrique étant plutôt coûteux, il est de bon ton de chiffrer le message de manière symétrique, et de ne chiffrer que la clé symétrique de manière asymétrique.

On profite donc de la rapidité du chiffrage symétrique, et de l’échange de clé publique du chiffrement asymétrique !

Pour voir une implémentation concrète de ce processus, voir les normes XML-Sign et XML-Enc.

Conclusion

J’espère que ce petit article vous a apporté quelques basiques quant à la cryptographie.

Dans un prochain article, nous verrons une mise en pratique de ces concepts, en Java, à travers les Frameworks Apache Santuario et Bouncy Castle.

Leave a Reply

Your email address will not be published. Required fields are marked *