Protocoles ILKP et SILKP : principes
La plupart des échanges que nous faisons régulièrement sur Internet utilisent, pour la sécurité des données, des protocoles qui reposent sur du chiffrement asymétrique. Le terme asymétrique vient du fait qu'il utilise deux clés différentes, l'une, la clé publique, pour chiffrer, l'autre, la clé privée, pour déchiffrer. Cette clé privée ne doit jamais être diffusée, sinon tous les secrets échangés n’en sont plus !
Lors du début de l’échange, les clés publiques sont échangées en clair, car aucun chiffrement n’a encore été mis en place. C’est le cas du protocole https utilisé par tous les navigateurs Internet pour éviter qu’on puisse vous espionner quand vous accéder à vos comptes bancaires ou autres.
Si une personne mal intentionnée utilise un outil de capture de paquets réseau, comme Wireshark par exemple, il verra quelque chose ressemblant à ceci :
L’échange des clés est très détaillé grâce aux RFCs publiés qui décrivent in extenso les protocoles et on peut facilement retrouver les clés publiques. Mais ensuite tout est chiffré et on ne peut plus savoir à quoi correspondent les données.
Les mathématiciens de génie qui ont mis au point les algorithmes pour fabriquer et utiliser ces clés ont aussi prouvé qu’il fallait, avec un ordinateur classique, plusieurs dizaines, voire centaines d’années, pour « casser » la clé, c’est-à-dire pour reconstituer la clé privée à partir de la clé publique.
Oui mais en septembre 2019, le géant américain Google a annoncé sur le site de la Nasa, avoir atteint la « suprématie quantique ». Et depuis d’autres annonces nous avertissent que dans peu de temps, si ne n’est déjà fait, les machine quantiques seront capables de « casser » une clé asymétrique en quelques minutes.
Face à la menace des machines quantiques, ce protocole propose une méthode de chiffrement faite pour empêcher ces types de calculateur de trouver, dans un temps raisonnable, les données chiffrées. Il s’utilise dans les échanges sur Internet et, plus largement, pour créer des tunnels de communication sécurisée dans les réseaux TCP/IP.
Supposons que nous utilisions un chiffrement symétrique. Car, si pour certains il suffit de doubler la longueur des clés pour supporter une attaque avec l’algorithme de Grover (1), pour d’autres le chiffrement asymétrique avec des clés finies, même de taille très grande, peut être cassé en quelques secondes grâce à des algorithmes quantiques comme celui de Shor ou de Simon (2).
Une clé de 32 bits propose plus de 4 milliards de combinaisons, et une clé de 64 bits en propose plus de 18 milliards de milliards (1,8 1019). Mais d’après Google, sa machine met 200 secondes pour faire un calcul qui prend 10 000 ans à une puissante machine classique (3), soit environ 1 seconde pour trouver la clé de 64 bits.
Entendu, mais si la clé est de taille infinie ?
Avoir une clé de taille infinie signifie que pour envoyer une donnée de N octets la clé est de N octets soit de 8xN bits. Autrement dit, chaque octet envoyé est chiffré avec un octet aléatoirement différent. Donc si le message fait 16 octets, la clé est de 8x16=128 bits, soit 2128 possibilités. Afin de s’assurer une bonne marge de sécurité, mettons-nous dans le cas le plus défavorable en supposant que tout ce qui est d’ordre 2n pour une machine classique, soit linéaire pour une machine quantique. Dans ce cas, la machine quantique va mettre 2 secondes pour trouver la clé de 128 bits.
Si on envoie | 1024 octets : | 128 s, soit env. 2 minutes, |
| 1 Méga octets : | 131072 s, soit 36 heures 24 minutes, |
| 1 Giga octets : | 134217728 s, soit 4,24 années, etc. |
Toutes les suppositions faites ici surestiment volontairement la puissance du calcul quantique. Autrement dit si l’échange est de 20 Go, il faudra au moins 80 ans pour déchiffrer le message !
Mais en réalité c’est le temps nécessaire à reconstituer toutes les possibilités du message. Reste ensuite à choisir parmi elles, le message. Ce qui n’est possible que si on sait ce que l’on cherche !
La question devient donc : comment faire pour que deux entités, qui échangent pour la première fois à travers un réseau TCP/IP, fabriquent une même clé infinie sans que ceux qui les observent puissent la connaître ? Pour résoudre ce problème il faut être capable de fabriquer, de manière isolée, une même suite infinie d’octets aléatoires.
La difficulté, dans cette étape, est de construire un algorithme qui génère une forte entropie, c’est-à-dire dont le nombre de possibilités devient rapidement très grand. Prenons l’exemple du cube de Monsieur Ernö Rubik, le classique, celui qui possède 6 faces et 9 cases par face. Inscrivons une clé de 54 caractères (un par case) sur le cube, puis effectuons une série de rotations pour brouiller la clé. Le nombre de configurations différentes possibles du cube est supérieur à 43 trillions ( très précisément 43 252 003 274 489 856 000 (4) ). Mais en fait le nombre de façons d’écrire cette clé est 54 ! (factorielle 54). En effet, pour inscrire le premier caractères on a 54 possibilités, puis il en reste 53 pour le second , etc. Le nombre de combinaisons est donc supérieur à 2,3 x 1075 ! De plus une clé est une suite quelconque d’octets. Ce n’est pas comme un message fabriqué avec des mots appartenant à un langage, défini par une grammaire ayant des règles syntaxiques, ce qui permet de le retrouver même si l’on n’en possède qu’une partie.
ILKP est un acronyme pour « Infinite Length Key Protocol ».
Ce protocole (Start Infinite Length Key Protocol) permet aux utilisateurs du protocole ILKP d’obtenir une startkey. Le service associé utilisant ce protocole sur un port dédié, est le même quel que soit le serveur qui l’héberge. Le rôle d’un tel service consiste donc à effectuer un calcul (et il y a beaucoup de solutions) qui permet d’obtenir un tel résultat.
Concrètement, une machine A s’adresse au service SILKP en donnant l’adresse IPv4 de son correspondant B. Elle reçoit des informations permettant de fabriquer UNE startkey adaptée à cet échange, choisie parmi un très grand nombre de possibilités. Le correspondant B s’adressant « au même moment » à ce service (mais pas forcément au même serveur) en lui donnant l’adresse IPv4 de A, obtient d’autres informations mais qui lui permettent de fabriquer la même startkey. Et tout autre échange se fera avec une startkey différente.
Le logiciel qui implémente ces protocoles et qui permet de créer des tunnels afin de chiffrer les échanges, se décline en trois versions :
La version dite « solo » qui permet d’échanger uniquement entre les serveurs qui possèdent la même version solo. Elle n’a pas besoin de startkey et n’utilise donc pas de serveur SILKP.
La version dite « silkp » qui permet d’échanger avec tous les serveurs qui possèdent la version silkp. Elle a besoin dans certains cas de startkey et utilise donc les serveurs SILKP.
La version dite « tests silkp » qui est une version silkp limitée dans le temps. Elle est gratuite et permet de faire des tests pour vérifier que le chiffrement est efficace.
Pour obtenir rapidement votre version personnalisée pour Linux 64 bits, faire une demande par email à : ilkp arobase seriane point org
(1) : https://fr.wikipedia.org/wiki/Algorithme_de_Grover
(2) : https://fr.wikipedia.org/wiki/Algorithme_de_Shor
(3) : https://www.lesechos.fr/2015/12/google-presente-son-ordinateur-quantique-...
(4) : https://fr.wikipedia.org/wiki/Rubik's_Cube