Mais qui est Le Chiffre ?

Le Chiffre est le premier super-méchant auquel est confronté James Bond, dans « Casino Royale », premier roman de la séri

L'histoire du chiffrement d'un message est longue comme celle des guerres de l'Humanité. César a laissé son nom à un principe primitif mais toujours efficace. Cette stratégie a été revue et industrialisée dans les années 1920s par les banques Allemandes : Les transferts financiers entre les différents établissements bancaires étaient transmis par télégramme, mais les messages étaient cryptés dans les agences avec la fameuse machine Enigma pour éviter tout casse virtuel par les postiers. Lors de la remilitarisation de l'Allemagne, ces engins si efficaces entrèrent en fonction pour les manœuvres militaires.
Les méthodes actuelles de chiffrement utilisent des clés asymétriques, ce qui veut dire qu'une clé de lecture ne permet pas d'écrire un message codé. Actuellement, elles sont majoritairement basées sur le chiffrement RSA, écrite durant les années 1970s, et elles sont autant utilisées dans les domaines stratégiques (Militaires, diplomatiques,...) que civiles.
Les opérations bancaires, monétaires, de transfert de titres furent pendant longtemps les utilisateurs civils les plus importants de communications chiffrées, car elles utilisaient les infrastructures publiques de télécommunication (télégramme, télex, modem sur téléphone, liaisons louées,…).

Le Chiffre vous garanti une solide protection, vous permettant d'effectuer des opérations financières partout dans le monde

Techniquement, ce sont des algos qui sont réputés comme suffisamment fiables, tant qu'on ne peut les casser. La méthode de “cassage”, ce que l'on appelle une compromission, s'obtient en général par une attaque en force brute : essayer mécaniquement toutes les possibilités, trouver des nombres premiers de plus en plus grands, parfois jusqu'à 4 000 chiffres. Avec l'augmentation continue de la puissance de calcul des ordinateurs, on travaille avec des nombres de plus en plus grands, rendant coûteux et onéreux la compromission d'une paire de clé. En gros, allonger une clé primaire d'un seul chiffre double la durée estimée de cassage par attaque en force brute : Une clé à 500 chiffres est deux fois plus longue à casser qu'une clé de 499 chiffres. C'est comme pour les sécurités sur les billets de banques, elles ne pourront bloquer indéfiniment toute contrefaçon, elles doivent au moins la rendre non-rentable.

Néanmoins, il existerait des faiblesses dans ces constructions mathématiques. Les algorithmes utilisés actuellement ont un certain nombre de faiblesses publiquement connues, et leurs implémentations font en sorte de ne pas générer de clés faibles. Jusqu'à plus ample informé, quand celles-ci ne sont pas publiques, et/ou seraient utilisées à la discrétion de certains services de renseignement militaires.

Avant d'aller plus loin, il est important de noter qu'on parle de chiffrement, car les messages encodés doivent être reconstitués à l'identique à l'arrivée. Ce qui n'est pas le cas d'autres méthodes de cryptages dites destructrices, comme le hashage (MD5, CRC32, SHA-1,...).

Chiffrement for the masses

Dans l'univers d'internet, difficile de se passer d'une solution de chiffrement. C'est une étape indispensable que de pouvoir établir un canal privatif et sécurisé entre deux personnes, qu'il sera impossible de lire à leur insu.

Certains services du quotidien fonctionnent sur le principe de la confiance. Vous confiez à ÉDF vos crédences bancaires car vous estimez leurs relevés justes. De même que vous attendez de votre quotidien une information fraîche et honnête, vous attendez de votre facteur qu'il n'ouvre pas vos courriers. Dans un univers mathématique où les services postaux seraient en concurrence, si justement les clients ne font plus confiance à La Poste, leur service ne serait pratiquement plus utilisé, sinon par les pollupost publicitaires.

Contrairement à ce que certains politiques peuvent croire, les occasions où vous utilisez quotidiennement une communication chiffrée ne manquent pas :

• Quand vous envoyez vos e-mails, vous aimeriez que ceux-ci n'arrivent qu'aux bonnes personnes
• Quand vous achetez en ligne, votre numéro de Carte Bleue ne doit être destiné uniquement à la banque du commerçant, pas à l'ensemble des serveurs hébergés chez OVH
• Quand vous établissez un dossier personnel du type impôts ou mutuelle de santé, certaines de vos réponses ne sont pas forcément destinées à vos voisins
• Quand vous téléphonez (Skype, Jabber, voire votre mobile), ce n'est pas forcément pour inclure la Terre entière dans votre conversation
• Quand vous utilisez votre wifi chez vous, votre concierge n'a pas à savoir chaque page que vous consultez
• Quand vous mettez à jour votre site d'e-commerce, ça serait bien que personne ne change les prix à votre place

En temps normal, quand vous surfez par le web, vous utilisez le protocole http:// (la première partie de l'URL), qui envoie et réceptionne des données en clair. Seulement sur Internet, les trames du dialogue sont susceptibles de passer par des chemins très différents entre deux points, c'est le principe même de ce réseau. En étant à Toulouse, quand je communique avec un serveur basé à Lille, mes données remontent à Paris via Bordeaux (ou une partie peuvent être envoyées par Montpellier), mais peuvent passer par Londres puis Bruxelles... Et encore, on parle d'un hébergement à un endroit fixe. Quand on parle d'un service en cloud, tout est possible.

Un chiffre aux multiples fonctions

Les principales missions du chiffrement sont :

① Certifier votre correspondant

Vous avez besoin d'être absolument sûr que le correspondant avec qui vous allez entamer un dialogue est bien la personne qu'il prétend être. Et, au besoin, inversement

② Confidence de la communication

Celle-ci ne s'adresse qu'à lui, et ne saurait être écoutable en clair par un tiers

③ Intégrité du message

Celui-ci ne doit pouvoir être modifié entre les deux correspondants

④ Non-contrefaçon

S'il est impossible de certifier que des messages ne sont pas interceptés par un tiers, que celui-ci ne puisse insérer dans la conversation des réparties en se faisant passer pour un des correspondants

Dans le cas du web, si il y a besoin d'une confidentialité, on utilise le protocole https://. Les différences sont minimes avec le http:// (le protocole est identique à part la procédure d'authentification, à part le numéro de port qui passe du 80 au 443), mais il est chiffré entre votre navigateur et le serveur que vous consultez. Il se présente pour l'utilisateur par un affichage légèrement différent, allant du traditionnel cadenas :

... à un aspect très modifié de la barre d'adresse.

Les bonnes pratiques conseillent de systématiquement proposer une version https:// d'un site pour peu qu'on identifie les visiteurs avec des données personnelles. Depuis un an, un serveur web peut indiquer par un manifeste HSTS que le navigateur doit obliger l'utilisateur à passer en https:// pour toutes les visites ultérieures. Après l'avoir mis en pratique, je ne peux le conseiller qu'aux cas vraiment critiques type paiement bancaires ou webmail car il sera impossible de revenir en arrière.

Seulement, il est impossible pour les utilisateurs du web de tenir personnellement une liste de toutes les signatures numériques (les paires de clés pour initier un dialogue) de l'ensemble des usagers de l'internet. C'est ici qu'entre en jeu les...

Tiers de confiance, chiffres presque entiers ?

Une autorité de certification (Certificate Authority ou C.A.) est un tiers de confiance : En encodant avec sa clé de cryptage une clé de décryptage (celle du site de vente en ligne, de la banque, d'un ministère, etc...), il vous garanti que la personne avec qui vous dialoguez est bien celle qu'elle prétend être. Quand vous vous connectez à un site par un canal chiffré, mais dont vous n'avez pas la clé, ce site indique quelle est son C.A., laquelle fourni publiquement sa clé de déchiffrement. Si vous faites confiance à cette C.A., vous récupérez la clé du certificat du site que vous joignez, laquelle s'ajoute au trousseau de votre navigateur. On saute donc la mission ①, tout en vous donnant la clé pour poursuivre votre dialogue dans les garanties suivantes. La suite, c'est une génération de clés de dialogues entre votre navigateur et le site correspondant, des clés qui seront jetées à la fin de votre session de surf.
Ce mécanisme de clés est basé sur les algorithmes SSL, lesquels sont basés sur les travaux de Ronald Rivest, Adi Shamir et Leonard Adleman, aka R.S.A., plus tard fondateurs de RSA Security.

Il existe un nombre relativement restreint d'entreprises « Tiers de confiance », les clés publiques de déchiffrage de ces entreprises sont donc embarquées dans votre navigateur web, votre client e-mail, voire au niveau du système. Car oui, même au niveau de votre système d'exploitation, afin de garantir des mises-à-jour logicielles, ce n'est pas un certificat délivré par Microsoft, Apple, Mozilla, Red-Hat, Ubuntu que vous utilisez, mais des clés délivrées par des tiers de confiance à ces entreprises/organismes. C'est pour une raison de cohérence et d'universalité, car vous pourriez utiliser un autre outil que le gestionnaire logiciel de votre système d'exploitation afin de mettre à jour votre ordinateur.
Les conditions de création de telles clés, leur enregistrement public et leurs révocations font parti du travail de ces tiers, avec des rôles clairement séparés. Je vous conseille de lire la Wikipédia sur le sujet qui sera infiniment plus pédagogue que moi.

Allons sur le site normal (non-chiffré) de Google :

Vous pouvez faire apparaitre une bulle de certificat de confidentialité en cliquant sur la favicon à gauche de l'adresse.
Notez que pour mes captures, j'ai pris Firefox 7 (encore en version béta à la date de mon billet) car elle introduit de subtils changements introduits sur le desktop par Chrome et qui semblent devenir la norme : la disparition dans la barre d'URL de l'indication du protocole http://, et de mettre en sous-contraste ce qui n'est pas le nom de domaine principal du site.

Maintenant, passons sur la page sécurisée de Google :

Le protocole https:// apparait, avec entre la favicon et l'URL l'indication du possesseur du certificat SSL utilisé. On notera que Google sert son site sécurisé dans un sous-domaine à part (encrypted.), mais plus bizarre, le certificat SSL de Google a été délivré par un revendeur (Google lui-même) mais délivré à personne (?).
Cliquons sur plus d'informations, et regardons les détails du certificat :

Le certificat SSL de Google a été chiffré par le C.A. Equifax Secure, devenu GeoTrust en Juin 2010. C'est donc ce tiers de confiance qui nous certifie les clés. Equifax a autorisé un revendeur (Google Internet Authority) à générer des clés pour le domaine google.com.

Si vous vous amusez à générer une clé en dehors de ces tiers de confiance, de suite, c'est une méfiance généralisée contre vous qui va s'installer.

Voilà un business avec des gros chiffres

Lors de la création du protocole https:// en 1995, RSA Security était l'unique autorité délivrant/facturant des certificats. Ce qui posait de multiples problèmes : À l'époque, la législation Américaine sur les technologies militaires interdisait de commercialiser en dehors des États-Unis des clés solides, les clés commercialisables faisaient moins de 256 bits, ce qui rendait leur intégrité en partie dérisoire pour un usage bancaire. Il y avait de même un monopole par l'existence d'un brevet mathématique sur l'algorithme RSA, donc un prix totalement arbitraire vis-à-vis d'un service et l'impossibilité de critiquer le système sous peine d'en être exclu.

En 2000, le brevet RSA expire. Des entreprises indépendantes peuvent donc se constituer en Certificate Authority, à condition d'inspirer suffisamment confiance pour que leurs clés publiques soient embarqués par les éditeurs des navigateurs.

C'était prévisible, cette gestion des clés certifiantes est immédiatement devenue un business. Malheureusement avec les dérives qui vont avec : Commercialisation à outrance, économies en tout genre et comme toujours dans un service informatique, c'est la sécurité qui en est le premier poste à souffrir. Dans leur domaine, voilà qui en est paradoxal.

Il était déjà arrivé que des C.A. démarchent “très pro-activement” certaines entreprises, allant même jusqu'à prendre induement la place de leur fournisseur de clés SSL. Le cas d'une commercialisation abusive est déjà arrivée à Mozilla, la fondation éditrice de Firefox. Il aurait pu devenir possible pour des réseaux maffieux de se faire passer par Mozilla et de glisser des mises-à-jour vérolées dans Firefox/Thunderbird.

Tout ça pour quelques chiffres

Le gros problème, c'est que passer par un C.A. est la seule méthode pour avoir une sécurisation viable de son site web. Pour peu qu'on propose un système monétaire (paiement embarqué), un webmail, un backoffice d'un site corporate ou un extranet sensible, ou même un service web hébergé en cloud, il est franchement recommandé de proposer une version chiffrée de son site web : Par exemple dans le cas où l'utilisateur utilisera votre site via un wifi ouvert (non-crypté, ou insuffisamment). Aucun des opérateurs proposant du wifi en itinérance (Fonera, FreeWifi, Orange,...) n'utilise de wifi protégé, sans compter les hôtels, Starbucks™ et autre McDo.

Mais si votre délivreur de clés SSL commence à générer des clés à votre nom à des organisations totalement étrangères, le cycle complet de confiance tombe. Vous comptiez utiliser Google Mail, mais votre gouvernement vous écoute voire vous envoie de faux messages. C'est exactement ce qu'il s'est passé pendant le Printemps Arabe : Pour mâter les révoltes, le gouvernement Iranien s'est placé entre Internet et les FAI nationaux, et a soigneusement écouté tous les mails échangés via Gmail. Le problème ne concerne pas une petite faune marginale de geeks, mais dans ce cas précis, au moins 300 000 internautes !
Imaginez de même que les mises-à-jour de vos serveurs sont compromis par une duplication imbue de Microsoft, Apple,… vous ne pouvez plus avoir la moindre confiance envers votre propre ordinateur. La situation serait beaucoup plus difficile à démontrer, mais elle concernerait la totalité de la population connectée, donc les entreprises étrangères sur place. Ben là aussi, c'est arrivé avec des certificats contrefaits de fabricants Taïwanais permettant à des virus de se loger bien au chaud.

La correction a été aussi rapide que possible : Une révocation des certificats publics du C.A. en question à condition que tout le monde l'applique. Or, entre nous, s'il y a bien une chose que le Grand Public ne fait jamais, ce sont les mises-à-jour de sécurité.

Chiffres molles

Et c'est bien là le problème : Le C.A. Comodo infiltré et compromis par un pirate, qui à partir de ces serveurs, s'est fabriqué de fausses clés. Puis moins de 3 mois après, rebelote avec un autre C.A., DigiNotar, sauf que cette entreprise s'est ingénié à minimiser la réalité de la situation. On a crû que seulement moins d'une demi-douzaine de certificats ont été contrefaits, ce serait au moins 500.
Avoir caché la situation a été fait exclusivement pour ne pas perdre des clients, mais voilà : Nier un incendie n'aide pas à l'éteindre.

Et selon les éléments qu'a livré le pirate qui a revendiqué ces exploit, il a eu la tâche facilitée par le fait que ces C.A. ont très mal séparés les éléments vitaux de la création d'un certificat. D'ailleurs, en plus de Comodo et DigiNotar, il a aussi compromis GlobalSign (qui est un énorme fournisseur du marché, et qui a immédiatement arrêté toute activité jusqu'à correction) et 3 autres C.A... Pour ajouter l'insulte à l'inconsistance, le fait que DigiNotar a voulu cacher sciemment l'ampleur des dégâts en dit long sur la confiance qu'on peut accorder à ce C.A.

C'est le feuilleton de cette fin d'été, sachant qu'un autre casse y'a 6 mois, chez RSA Security cette fois-ci, aurait permis à des malveillant de faire main basse sur des documents très particuliers : des faiblesses de divers algos de chiffrages (dont le RSA, dont SSL,…) qui n'ont jamais été révélés au public.
Une situation encore plus ubuesque en France où des recherches sur les faiblesses des chiffrages sont strictement interdites par les lois DADVSI, LOPPSI, HADOPI et LCEN (Loi pour la Confiance en l'Économie Numérique, ben voyons…).

En attendant, les responsables de sites web voient deux types d'attaques périmétriques face auxquelles ils sont totalement démunis : le détournement de nom de domaine (DNS poisonning) et désormais le faux et usage de faux certificat SSL en leur nom.

Cela amène certaines autorités d'internet, en plus de revoir le système DNS, à songer à remplacer le SSL, mais on est loin du consensus.

Chiffres en berne

Seulement, pourquoi payer (assez cher et tous les ans) des certificats si le fournisseur, l'“autorité” qui vous la vend n'est plus digne de confiance ? Et surtout, pourquoi encore faire confiance à ces C.A. qui n'appliquent qu'une politique de sécurité au rabais ? Et d'ailleurs, puisque finalement ces C.A. ne sont que des marchands de services plus préoccupés par leur C.A. chiffre d'affaire que par la valeur morale de leur service, il est temps de faire jouer leur responsabilité morale.

La sanction est proche : Les certificats d'autorités ne sont embarqués dans les navigateurs que parce que leurs éditeurs leur font confiance. La Mozilla Foundation a lancé un ultimatum à l'ensemble des C.A. : Conduisez immédiatement un audit de sécurité par un organisme indépendant, où les utilisateurs de notre navigateur ne feront plus confiance à vos clients. Et il n'y aura aucune exception.
Évidemment, en cas de retrait d'un certificat d'un C.A., des centaines milliers de sites deviendront inaccessibles avec ce navigateur. Mais le but de la Mozilla Foundation n'est pas d'acquérir des parts de marchés, mais d'améliorer Internet pour l'usager, en toute ouverture. Sacrifier l'accès à des milliers de sites, si c'est pour obliger à de meilleurs pratiques ne sera pas une première de leur part. Et cela ne les a pas empêchés d'être le navigateur web le plus utilisé en Europe, donc l'exigence paie.

On peut parler d'une réelle prise d'otage, mais la gabegie est édifiante chez certains C.A., troués depuis 3 mois. Et soyez assurés que les autres éditeurs de navigateurs (Microsoft, Google, Apple,…) appliqueront eux aussi la sanction de Mozilla.

Car sur Internet, tout est question de confiance. Et elle ne se chiffre pas...