Cryptographie – Partie I : les enjeux

Temps de lecture : 11 minute(s)

Dans cette série d’articles, je tenterai de rendre accessibles au plus grand nombre l’intérêt, les principes et les limites de la cryptographie que tout le monde utilise aujourd’hui sans forcément la comprendre.

Qu’est-ce que la cryptographie ?

La cryptographie est une des disciplines de la cryptologie s’attachant à protéger des messages (assurant confidentialité, authenticité et intégrité) en s’aidant souvent de secrets ou clés.

La cryptographie, c’est bon pour la démocratie !

Je sais bien que cela va à contre-courant de ce qu’on vous rabâche à longueur de journées, ces temps-ci, mais c’est vrai.

En fait la cryptographie peut être vue comme le dernier rempart contre la dictature.

Quand les gouvernements commencent à prétendre que la cryptographie doit être considérée comme une arme, et à ce titre interdite, vous pouvez commencer à vous inquiéter sérieusement sur la pureté de leurs intentions.

Il est tout à fait légitime que vous souhaitiez garder secrètes un certain nombre d’informations que vous ne voulez pas voir circuler.  Il est tout à fait légitime qu’un journaliste qui enquête sur des affaires mettant en cause l’un ou l’autre politique puisse protéger ses sources par des moyens notamment cryptographiques.  Il est tout aussi légitime que les opposants politiques puissent échanger en toute confidentialité dans des pays qui ne sont pas précisément réputés pour leur démocratie.

L’histoire récente, en France de l’Affaire des Fadettes devrait nous pousser à réfléchir s’agissant de mettre directement à portée des services de renseignement des informations sur les sources journalistiques.   Et on ne parle pas le la Corée du Nord, là !

Les couplets visant à nous tirer des larmes sur les méchants terroristes qui utilisent la cryptographie pour faciliter leurs méfaits, c’est de la démagogie.  Les armes de guerre sont interdites, il me semble, et cela ne les empêche pas de s’en procurer, et de s’en servir ?  On va aussi interdire l’usage du téléphone, puisque les terroristes s’en sont notoirement servis ?  Et la voiture aussi pendant qu’on y est ?

Non, la seule cible des lois visant à empêcher l’usage de moyens cryptographiques forts, ce sont les citoyens comme vous et moi.  Pas les terroristes ou les pédophiles.  D’ailleurs, qu’est-ce qui empêchera ces derniers d’utiliser quand même la cryptographie ?  Le respect des lois ?

Thomas Jefferson, troisième président des Etats-Unis d’Amérique l’avait déjà résumé ainsi :

Quand le gouvernement craint le peuple, il y a la liberté. Quand le peuple craint le gouvernement, il y a la tyrannie.

Ils rêvent debout

Il est parfaitement illusoire pour tout gouvernement, à fortiori s’il est totalitaire de penser qu’il pourrait empêcher qui que ce soit d’avoir recours à des moyens qui lui permettent de protéger ses informations et sa correspondance.

Or il n’est pas besoin d’être docteur en mathématiques pour créer un tel logiciel.  Les outils sont là, et les moyens de les propager aussi.  On interdit une application un jour, le lendemain elle peut être en service ailleurs, sous un autre nom.

C’est d’ailleurs la raison pour laquelle en France, par exemple, on s’orienterait plutôt vers l’obligation, pour les fournisseurs de services (et donc aussi les développeurs)  de donner une copie des clés cryptographiques aux autorités.

Pourquoi c’est une mauvaise idée

Tout d’abord parce que dans bien des cas, la cryptographie est précisément utilisée se prémunir des agissements de nos gouvernements.

Quel mouton irait donner la clé de sa bergerie au loup ?  Je ne suis ni terroriste ni criminel d’aucune sorte, pourtant je ne me priverai pas volontairement des moyens de me défendre contre mon propre gouvernement, le cas échéant.  C’est ainsi que les choses doivent être en démocratie.

Des méthodes plus ou moins farfelues ont bien été proposées ça et là, visant à ménager la chèvre et le chou, permettant aux citoyens de protéger leurs données tout en permettant aux forces de l’ordre de mener leur mission d’enquête, mais elles posent plus de problèmes qu’elles n’apportent de solutions.

La cryptographie : une affaire de confiance

On ne le dit pas assez : la cryptographie, c’est avant tout une histoire de confiance.  Ainsi lorsque vous utilisez tel ou tel logiciel, vous lui confiez vos données afin qu’il les sécurise, et ce faisant vous lui déléguez également le pouvoir de vous trahir.

Oh bien sûr, n’utiliser que des applications issues du monde de l’Open Source, et qui ont été dûment auditées devrait vous protéger contre pareille mésaventure…  Mais cela ne fait que reporter la confiance sur la ou les personnes qui ont audité l’application.  Et elles peuvent aussi se tromper.  Parfois on aimerait croire que ce ne sont que des erreurs…

Le cas OpenSSL

OpenSSL est, dans le monde de Linux, une importante bibliothèque de cryptographie utilisée notamment pour encrypter les communications avec les serveurs sécurisés (vous savez, le petit cadenas dans la barre du navigateur).

En mars 2014, des experts en sécurité de chez Google, et indépendamment, une équipe de la société finlandaise Codenomicon découvraient une faille majeure dans l’implémentation.

Cette faille permettait à un attaquant de récupérer des informations critiques sur les clés de sécurité en forgeant spécialement des paquets puis en les envoyant au serveur.  On considère qu’au moment de sa découverte, environ 17% des serveurs sécurisés, soit 500.000 serveurs étaient vulnérables.  Certains smartphones android (Jelly Bean) étaient également vulnérables.

On sait que la faille était présente depuis deux ans au moins.  Elle avait été introduite par un développeur nommé Robin Seggelmann, dans une des améliorations qu’il avait apportées au programme.  Il avait purement et simplement oublié de valider la longueur d’un bloc.  La personne ayant audité le code ultérieurement ne l’a pas vu non plus.

En fin de l’article consacré à Heartbleed sur Wikipedia, un lien est fait vers l’article intitulé « The man who introduced serious ‘Heartbleed’ security flaw denies he inserted it deliberately« .  Dans lequel on apprend que :

The German software developer who introduced a security flaw into an encryption protocol used by millions of websites globally says he did not insert it deliberately as some have suggested.

In what appears to be his first comments to the media since the bug was uncovered, Robin Seggelmann said how the bug made its way into live code could « be explained pretty easily ».

Ce n’était pas volontaire… Et il est bien placé pour le savoir !

La preuve vaut ce qu’elle vaut, les faits sont là.  Que l’on croie ou pas qu’il s’agit d’une erreur de débutant (le gars est quand même docteur en informatique…) n’a plus guère d’importance aujourd’hui.  Mais il était impératif d’en tirer toutes les conclusions, et de réévaluer notre rapport aux logiciels de sécurité, notamment sur le plan de la confiance aveugle que l’on faisait auparavant aux logiciels issus du libre qui se montrent finalement aussi dangereux que les logiciels propriétaires.

Cela n’a pas été fait, je le crains.  En tout cas de manière incomplète.

Selon Bloomberg, la NSA aurait exploité cette faille depuis deux ans au moins, soit approximativement la date à laquelle le bug aurait été introduit dans le code source.

La NSA a rapidement démenti ces informations.  Et là aussi, on a un témoin de premier plan : l’accusé lui-même.

Les leçons de HeartBleed

Tout d’abord il faut bien comprendre que cette faille n’était pas anodine.  Elle permettait de récupérer, de manière un peu aléatoire des informations qui pouvaient être critiques, telles les clés secrètes protégeant le certificat SSL du serveur.

Un attaquant possédant ces informations peut aisément intercepter les informations qui désormais pour lui sont en clair.  Mieux, il peut monter un serveur qui se fera passer pour le serveur original auprès des internautes.

Imaginez que de telles informations arrivent entre les mains d’une dictature comme le Qatar ou l’Arabie Saoudite où la répression des opposants politiques est féroce ?

Dans la mesure où la faille était généralisée, et que tous les serveurs vulnérables ont pu, à un moment ou à un autre se faire dérober leur clé secrète, il y avait lieu de révoquer immédiatement l’ensemble de ces certificats.  Cela n’a pas été fait.  Bon nombre de ces serveurs tournent donc toujours avec des certificats qui ne valent plus rien si l’on s’en tient à la stricte application des bons principes de sécurité informatique.

On ne dispose pas de statistiques quand au nombre de serveurs potentiellement vulnérables qui n’auront pas fait révoquer leur certificat dans la foulée.  Rien n’oblige les sociétés à communiquer à ce sujet, mais il y a gros à parier qu’une bonne partie, par souci d’économie ou par paresse aura simplement laissé la situation en l’état.

Cette faille a été pour bon nombre d’entre-nous un électrochoc.  Nous pensions (et maintenant on se rend compte à quel point on a été naïfs) que les logiciels issus du monde du libre (open source) étaient forcément plus fiables que les autres.  Comme si le fait d’avoir été édité en Open Source avait un pouvoir magique en quelque sorte.

Cette croyance un peu folle nous a été patiemment instillée au fil des ans par les experts en sécurité informatique, tels Bruce Schneier.  Dans leurs écrits, ceux-ci mettaient régulièrement en garde les utilisateurs contre les Snake Oil products, entendez : les logiciel de charlatans.

Le même qui continue de pousser vers des application issues de l’Open Source, telles Signal d’OpenWhispers, qui est pourtant un bien mauvais candidat s’agissant de protéger les données de ses utilisateurs.  Interpellé par un tel soutien, j’ai posé la question directement à l’intéressé.  Je n’ai pas de réponse à ce jour.  Mais peut-être est-ce une réponse, après tout.

En poussant la réflexion un peu plus loin, je me suis aperçu que le premier ennemi de la liberté sur internet, c’est la concentration.

Qu’une application soit bonne ou mauvaise, dès qu’elle concentrera suffisamment d’utilisateurs, elle deviendra une cible privilégiée pour les agences étatiques.  Pire, ce sera une cible facile, parce qu’isolée.

La guerre asymétrique

La guerre asymétrique, théorisée par Sun Tzu dans l’Art de la guerre, il y a 2.500 ans et largement appliquée par toutes les guérillas du monde consiste à ne pas affronter l’ennemi directement, mais à le harceler là où ses positions sont les plus faibles.

Les experts dans la défense doivent s’enfoncer jusqu’au centre de la Terre (…).  Pour se mettre en défense contre l’ennemi, il faut être caché dans le sein de la Terre, comme ces veines d’eau dont on ne sait pas la source, et dont on ne saurait trouver les sentiers. C’est ainsi que vous cacherez toutes vos démarches, et que vous serez impénétrable

Ainsi il ne viendrait jamais à l’idée d’un lapin d’affronter un groupe de chasseurs, je pense.  Mais alors pourquoi, sur base d’idées suggérées par eux aller tous se regrouper dans la même prairie le jour de l’ouverture de la chasse ?

Dans cette insidieuse guerre que les agences étatiques et les gouvernement mènent contre leurs propres citoyens,  je pense que la solution réside dans la multiplication des obstacles.

Les bonnes mauvaises idées

La tendance actuelle, dans le développement d’applications en cryptographie est d’une part à la vitesse, et d’autre part à l’utilisation de protocoles dits state of the art, tels Elliptic Curve et AES.

  • Vitesse : A quoi sert de pouvoir tester toujours plus de combinaisons par seconde, si ce n’est de favoriser le bruteforcage, c’est-à-dire le cassage du code par essais successifs de toutes les combinaisons possibles ?  Pour la personne qui veut protéger ses données, la plupart du temps, cela ne représente aucun avantage particulier.

Par contre on comprend aisément que pour des agences étatiques telles la NSA qui dispose de supercalculateurs d’une puissance colossale, c’est un avantage inestimable.

Et s’il n’est pas mauvais d’avoir des applications capables de d’encrypter ou de décrypter de gros volumes de données par seconde, il serait à tout le moins prudent de s’assurer que cela ne peut pas être fait dans des délais raisonnables.  Il existe des techniques, telles HashCash permettant de faire précisément cela.

  • State of the Art : Le problème, selon moi avec ces algorithmes modernes, c’est que pratiquement personne ne comprend plus vraiment comment ils fonctionnent dynamiquement dans le détail.  A cela s’ajoute qu’ils ont été audités, et bien souvent amendés par… la NSA.  Je ne sais pas pour vous, mais moi je ne trouverais pas particulièrement rassurant de dormir dans un poulailler dont la serrure aurait été améliorée par le renard.

Encore une fois, je n’aurais pas tendance à jeter le bébé avec l’eau du bain.  Pourquoi ne pas profiter à fond de la sécurité de AES… Et emballer le tout dans une autre couche cryptographique faisant appel à des moyens disons plus rudimentaires, mais dont on sait qu’ils sont impossible à casser lorsque d’une part le texte n’est pas connu (cette condition est supposée garantie par AES dans ce cas) et que la clé est suffisamment longue (on peut fort bien dériver des clés à partir de l’originale et s’en servir uniquement pour la couche extérieure).

Dans le pire des cas cela ne rendrait pas le texte contenu plus sûr, et dans le meilleur, cela le rendrait inattaquable par les services de renseignement.

Cryptographie classique versus Cryptographie moderne

On considère de manière générale que la cryptographie classique reprend toutes les méthodes développées à partir de l’antiquité jusque dans les années 1970, et que tout ce qui vient après, avec notamment la cryptographie asymétrique et le traitement par ordinateur se rapporte à la cryptographie moderne, supposément plus sûre.  Mais l’est-elle vraiment ?  Et pourquoi ?

Certainement, mais pas parce qu’elle est « moderne ».  Tout simplement parce que ce que l’on faisait avant, avec une simple feuille de papier et un crayon se fait maintenant avec un ordinateur.  Et précisément pour cette raison, on a pu développer des combinaisons infiniment plus complexes que tout ce qui existait auparavant.  Durant la seconde guerre mondiale, on permutait des lettres… Aujourd’hui on permute les bits.

Mais n’allez pas penser comme la doxa voudrait vous en convaincre que la cryptographie classique était faible pour autant…   A cet égard, savez-vous qu’il existe encore aujourd’hui des équipes de passionnés qui font tourner depuis des années de logiciels de cryptanalyse pour casser les derniers messages envoyés par les commandants de U-Boot dans l’Atlantique nord, durant les dernier jours d’avril-mai 1945 ?

Savez-vous qu’à ce jour, la quatrième partie du message gravé sur la sculpture Kryptos n’a toujours pas été décodée ?  Pourtant on sait que cela a bel et bien été fait sur un coin de table, avec un crayon et un papier en utilisant des techniques classiques.

Ne pas mettre tous ses oeufs dans le même panier !

Ainsi, ce que je recommande essentiellement, c’est de profiter des avantages amenés par la cryptographie moderne, tout en les combinant à des moyens cryptographiques plus classiques, pour autant bien sûr que l’utilisation de ceux-ci ne compromettent pas la clé utilisée dans la première.

Il ne faut pas permettre à l’adversaire de choisir le terrain ni les armes :

  • Multiplier les protocoles, la combinaison des protocoles et les applications, multipliant par autant les fronts pour l’adversaire, tout en diluant ses moyens.
  • Ne pas concentrer trop d’utilisateurs sur une application ou un protocole particulier.
  • Tout encrypter et appliquer partout la notion du prix à payer.  J’ai un message encrypté et vous voulez le décoder ?  Très bien, vous finirez sans doute par y arriver, mais cela vous coûtera beaucoup de moyens, et donc d’argent.  Et cela ne fait qu’un seul message.  Et pour le même prix, c’est peut-être ma dernière liste de courses.
avatar

Philippe Huysmans

Webmaster du Vilain Petit Canard, citoyen de nationalité belge, marié et père de deux enfants. Je vis en Belgique et j’exerce la profession d’Informaticien à Bruxelles. Mes articles