Document

Applications de la cryptographie à clé publique

Crypter un message $M$ revient à appliquer à celui-ci une fonction bijective $f$ de sorte de former le message chiffré $M^{'} = f (M)$ . Déchiffrer ce dernier consiste alors à calculer $f^{- 1} (M^{'})$ pour déterminer $M$ .

Dans les systèmes de cryptographie symétrique (comme la grille de Vigénère, le système DES,...), la connaissance de $f$ suffit pour déterminer immédiatement $f^{- 1}$ . Dans les systèmes de cryptographie asymétrique, connaître $f$ ne permet techniquement pas, sauf pour le concepteur du code, de déterminer $f^{- 1}$ (par exemple, parce que cela nécessite de savoir factoriser un très grand nombre). Dans ce cas $f$ peut être transmise à n'importe qui, on l'appelle clé publique. L'application $f^{- 1}$ , en revanche, reste confidentielle, on l'appelle clé privée (ou clé secrète), seul le concepteur du code en a la connaissance.

La cryptographie à clé publique est à l'origine de nombreux protocoles permettant se sécuriser les transactions informatiques. Pour simplifier la présentation de ces protocoles, nous appellerons Alice et Bernard les deux individus souhaitant échanger des informations. Nous noterons $(S_{A}, P_{A})$ le système de clés qu'Alice aura pris soin de former, $S_{A}$ étant la clé secrète qu'elle seule connaît, $P_{A}$ étant la clé publique que Bernard, entre autres, connaît.

Signature électronique

Alice veut envoyer un message $M$ à Bernard et ce dernier veut s'assurer qu'Alice en est effectivement l'expéditrice. Pour ce faire, Alice va accompagner son message d'une signature électronique.

Alice commence par réaliser un résumé $R = h (M)$ de son message. Pour cela elle fait appel à une fonction $h$ (dite fonction de hachage) connue de tous. Pour faire simple, la fonction $h$ va, par exemple, prendre une lettre sur 10 du message initial pour former le message résumé. Dans la pratique, les fonctions de hachage sont plus complexes et sont définies de sorte que la moindre modification du message $M$ entraîne une modification sensible de son résumé $R$ . L'un des algorithmes de hachage usuel est le MD5.

Alice exploite alors sa clé secrète $S_{A}$ pour chiffrer le résumé en $R^{'} = S_{A} (R)$ , cela va constituer la signature du message $M$ . Elle envoie ensuite à Bernard le message $M$ accompagné de sa signature $R^{'}$ . A la réception, il calcule $R = h (M)$ et $R^{″} = P_{A} (R^{'})$ . Il vérifie ensuite,à l'aide de la clé publique d'Alice, que $R = R^{″}$ . Si le test est satisfait, Bernard est assuré qu'Alice est bien l'expéditrice du message.

Authentification

Maintenant Alice veut transmettre un message $M$ à Bernard. Pour cela elle lui envoie le message chiffré $S_{A} (M)$ que Bernard est en mesure de décrypter puisqu'il connaît la clé publique d'Alice $P_{A}$ . Soupçonneux, Bernard se pose alors la question suivante : est-ce bien Alice qui m'envoie ce message, ou bien s'agit-il d'un imposteur qui me transmettrait des données usurpées lors de précédentes communications d'Alice ?

Pour résoudre ce problème, Bernard va s'assurer que sa correspondante est bien en possession de la clé secrète $S_{A}$ . Pour cela Bernard, choisit un message $N$ au hasard et demande à Alice de chiffrer $N$ . Elle obtempère et transmet $N^{'} = S_{A} (N)$ . Bernard calcule $N^{″} = P_{A} (N^{'})$ et vérifie si $N^{″} = N$ . Si le test est satisfait, il peut alors être assuré qu'il communique bien avec Alice, auteur du système de clés $(P_{A}, S_{A})$ .

Certificat

C'est maintenant Bernard qui désire envoyer des données confidentielles à Alice. Alice lui transmet sa clé publique $P_{A}$ mais Bernard est pris de doutes : Alice est-elle réellement Alice ?, n'aurait-il pas affaire à un usurpateur qui vient de lui transmettre sa propre clé publique ?

En vue de rassurer Bernard, Alice va lui envoyé un certificat. Pour cela, elle se rend auprès d'une autorité officielle dont l'honnêteté est reconnue de tous, appelée autorité de certification (comme par exemple VeriSign). Elle produit auprès de celle-ci différentes informations personnelles y compris sa clé publique. L'autorité de certification produit alors un document regroupant ses données, ainsi qu'un numéro de série et une période de validité. De plus, ce document est accompagné d'une signature électronique assurant que l'autorité de certification est effectivement l'auteur du certificat ainsi formé

Bernard en recevant ce certificat, et s'il reconnaît la compétence de l'autorité de certification, peut alors être assuré que la clé publique qui lui est transmise est celle d'Alice.

Avec Internet Explorer, vous pouvez connaître les autorités de certification validées par votre navigateur en allant voir l'onglet « Sécurité » dans « Options Internet ».

Le protocole SSL

Le protocole SSL (Secure Socket Layer) a été développé par Nestcape Communications Corp. en collaboration avec RSA Data Security Inc. afin de sécuriser les échanges d'informations sur Internet. Les serveurs bancaires (tels que La Poste...) et 60 % des sites de commerce électronique utilise ce protocole pour échanger les informations avec le client. Comme nous allons le voir, ce protocole assure :

- la confidentialité des informations transmises entre client et serveur ;

- l'agrémentation par un organisme officiel du serveur ;

- la non usurpation de l'identité du client.

Pour fixer les idées, mettons que Bernard décide d'acheter un CD sur le site de commerce en ligne d'Alice. Pour cela il va devoir transmettre son numéro de carte bleue au serveur du site. Deux problèmes, se posent :

- le site commercial n'est il pas un leurre en vu de voler le précieux numéro de carte bleue de Bernard ;

- n'importe qui peut surveiller les communications entre Bernard et Alice et donc intercepter au passage le fameux numéro de carte bleue ou encore simuler une fausse transaction.

Déroulement du protocole SSL

1ère étape : (échange des clés et certification d'Alice)

Bernard (ou plus précisément son logiciel de navigation internet) demande au serveur d'Alice un certificat que cette dernière aura préalablement demandé à un organisme qualifié. Le serveur envoie ce certificat dans lequel figure la clé public $P_{A}$ d'Alice. Bernard vérifie que le certificat a été délivré par une autorité dont il reconnaît la compétence et que ce certificat est bien en cours de validité. Bernard crée ensuite un système de clés asymétriques $(P_{B}, S_{B})$ , qui ne servira que pour cette transaction, il envoie sa clé publique $P_{B}$ à Alice en prenant soin de chiffrer celle-ci par l'intermédiaire de $P_{A}$ . Alice décrypte le message reçu par l'intermédiaire de sa clé secrète $S_{A}$ et prend donc connaissance de $P_{B}$ .

A ce stade, la clé publique de Bernard n'est pas véritablement rendue publique, car seule Alice est capable de prendre connaissance de celle-ci. Nous allons voir pourquoi tout à l'heure...

2ème étape : (authentification de Bernard)

Alice réalise l'authentification de Bernard en lui demandant de chiffrer un message $M$ choisi au hasard. Bernard obtempère en exploitant sa clé secrète $S_{B}$ , puis envoie le message crypté : $M^{'} = S_{B} (M)$ . Alice vérifie $P_{B} (M^{'}) = M$ et est alors certaine que Bernard est bien l'auteur du système de clés.

Si une personne mal intentionnée a observé les échanges réalisés durant la première étape, elle est capable de les exploiter pour simuler un futur échange avec Alice... Cependant, n'étant pas en possession de la clé $S_{B}$ , l'usurpateur est démasqué au cours de cette étape d'authentification.

3ème étape : (échange d'information)

Si les étapes précédentes se sont correctement déroulées, Bernard et Alice vont pouvoir échanger des informations confidentielles, chacun en les codant avec sa propre clé secrète. Bernard peut donc transmettre son numéro de carte bleue $N$ sous la forme $N^{'} = S_{B} (N)$ , Alice et elle seule, est en mesure de déchiffrer celui-ci.

En fait, dans la pratique, les systèmes de chiffrement asymétriques sont gourmands en calculs, ce qui ralentit les transactions. Par suite, ces systèmes sont en fait utilisés pour chiffrer une clé symétrique qui servira à la suite des communications (un peu comme pour le système PGP).

Notons qu'après tous ses efforts il serait dommage que votre numéro de carte bleu traîne sur le disque dur du serveur, proie à n'importe quel « hacker ». Par conséquent, le protocole précédent est souvent modulé de sorte que le numéro de carte bleue de Bernard soit transmis à la banque d'Alice, cette dernière lui transmettant alors un accord de paiement. C'est le principe du protocole SET (Secure Electronic Transaction) qui semble devoir succéder au SSL.

Encadré : Authentification des cartes bleues

Le principe de la signature électronique est assez semblable à celui adopté par le groupement interbancaire (GIE) pour certifier les cartes bleues. Le GIE a formé en 1983 un système de clés $(S, P)$ asymétriques sur la base du système RSA avec un nombre $n = p q$ de 96 chiffres décimaux. Jusqu'en 1999, il s'est servi de ce système pour certifier les cartes bleues. Voyons comment :

Lorsqu'un client fait une demande de carte bleue à sa banque, cette dernière réunit un certain nombre d'informations qu'elle communique au GIE. A partir de ces données, le GIE forme un numéro d'identifiant $I$ , correspondant au numéro à 16 chiffres visible sur la carte. De plus, à l'aide de sa clé secrète, le GIE forme un numéro, dit d'authentification, $J = S (I)$ . Ces données, ainsi que quelques autres, dont le code personnel à 4 chiffres (appelé code PIN pour Personal Identifer Number) sont emmagasinées dans les quelques Ko de mémoire (EEPROM) de la puce de la carte bleue. Cette dernière peut alors être envoyée au client.

Voyons maintenant ce qui se passe lors de l'usage de cette carte bleue chez un commerçant :

Une fois celle-ci insérée dans le terminal, commence une phase d'authentification (ce message apparaît parfois sur l'écran du terminal). Lors de celle-ci, les numéros $I$ et $J$ sont lus et le terminal vérifie que $P (J) = I$ et que $I$ ne figure pas dans une liste d'identifiants interdits (comportant notamment les numéros des cartes volées). Si le montant de la transaction est inférieur à environ 100 Euros, la phase d'authentification s'arrête là, sinon, le terminal contacte un serveur général pour voir s'il n'y aurait pas d'interdit bancaire dans l'air... Vient ensuite le moment où le client entre son code PIN. Ce dernier est transmis à la puce de la carte. Si la puce reçoit successivement 3 codes incorrects, elles se figent et il faut refaire une demande de carte bleue... Si la puce reçoit un code correct alors elle mémorise le montant et la date de la transaction, vérifie que la somme des montants des transactions écoulées dans la semaine ne dépasse pas une certaine somme, et produit un numéro de transaction (qui apparaîtra sur la facturette que donnera le commerçant). Lorsque toutes ses opérations se déroulent correctement, la transaction est validée, le client repart avec sa marchandise et le commerçant transmettra dans la soirée à sa banque l'ensemble des transactions réalisées dans la journée.

Serge Humpich a découvert en 1998 une faille dans le système précédent. Le nombre $n$ de 96 chiffres défini par le GIE en 1983 était certes impossible à factoriser à l'époque, mais l'est devenu entre temps (voir http://www.parodie.com/monetique/topsecret_04032000.htm). Humpich est alors parvenu à déterminer la clé secrète du GIE. Il était alors facile, à partir d'un numéro d'identifiant $I$ farfelu, de concevoir une fausse carte bleue dont la puce répondait « oui » à n'importe quel code PIN. Ces cartes furent appelées les « yescard ». Elles n'étaient valides que pour des montants inférieurs à 100 euros car l'authentification, ne nécessitait pas de consultation bancaire. Ces cartes n'étaient valables qu'une journée, car dès le lendemain leur numéro d'identifiant était incorporé à la liste des numéros interdits...

Serge Humpich a voulu négocier sa découverte avec le GIE mais au lieu de cela il fut licencié de l'entreprise dans laquelle il travaillait puis condamné à 10 mois de prison avec sursis en février 2000.

Pour résoudre le problème qu'il a posé, le GIE a décidé d'équiper les nouvelles cartes bancaires d'un numéro d'authentification construit à partir d'un nombre $n = p q$ d'environ 230 chiffres.

Cela durera jusqu'à ce que quelqu'un parvienne à factoriser ce nouvel $n$ ...

Encadré :

Les systèmes de cryptographie tels que RSA sont en général très gourmands en calculs ; il est alors fréquent de les coupler avec des systèmes à clé symétrique qui sont d'exécutions plus rapides. C'est le cas du programme PGP (Pretty Good Privacy) développé en 1991 par Philip Zimmermann qui est devenu un standard sur le Net car longtemps diffusé librement.

Pour chiffrer un texte, le programme PGP commence par réaliser une compression du texte. Cela a certes pour effet d'en réduire la taille mais aussi de supprimer les redondances dont les cryptanalystes sont souvent friands. Ensuite le programme PGP détermine aléatoirement une clé symétrique de 128 bits qui ne servira qu'au codage du texte en cours. La génération de nombres aléatoires par des procédés mathématiques n'est pas toujours satisfaisante, aussi, c'est ici les mouvements de la souris ou les délais entre deux frappes de touches du clavier qui permettent de générer ces nombres.

La clé formée est utilisée pour réaliser un cryptage par blocs : le message de départ est découpé en blocs de 64 bits dont les éléments sont permutés et transformés en fonction de la clé fixée au départ ; l'algorithme choisi ici porte le nom d'IDEA (International Data Encryption Algorithme), il est assez proche de DES (Date Encryption System). Pour décrypter le message formé, il suffit d'en connaître la clé, il faut donc absolument sécuriser celle-ci. Pour cela, on la chiffre via un algorithme RSA.

Au final, on dispose d'une méthode de cryptage fiable et rapide.

5/6