Archives de catégorie : Cryptographie. Chiffrement

Cette catégorie regroupe des informations sur la cryptographie de manière générale, et sur le chiffrement. L’actualité fait hélas de plus en plus mention de failles liées aux processus de sécurisation et de chiffrement.

Parmi les sites expliquant les principes et les bases, bibmath.net est très clair et très fourni.

Cryptologie

La cryptologie est la science de l’écriture secrète, comprenant la cryptographie (technique de chiffrement de message) et la cryptanalyse (technique de déchiffrement d’un message).

Principes

Stéganographie

La stéganographie est la dissimulation du message sur un support d’apparence anodine (une tablette gravée puis recouverte de cire, le crâne rasé du messager qui laissera ensuite repousser ses cheveux, etc.).

Transposition

La transposition consiste en la permutation de lettres, sans en changer la valeur, comme dans un anagramme. Le secret réside dans le choix de la transposition :

  • En dents de scie, et autres dérivés ;
  • La scytale spartiate, où le secret est le diamètre de la scytale.

Substitution

La substitution est le remplacement d’une lettre par un autre caractère, sans modifier sa position. Il en existe différentes formes

  • Monoalphabétique : l’alphabet reste le même durant tout le chiffrement (ex : César)
  • Polyalphabétique : l’alphabet change lors du chiffrement (ex : Vigénère)
  • Homophonique : plusieurs substitutions sont possibles pour un même caractère.

Cryptanalyse

Les débuts de cryptanalyse sont liées à l’évolution des mathématiques, des statistiques et de la linguistique. Les premiers principes furent appliqués pour ordonner chronologiquement les chapitres du Coran, en fonction de la fréquence d’usage de mots modernes par exemple. L’analyse des fréquences d’usage des lettres fut également étudié.

La faiblesse de Vigénère

Longtemps considéré comme sûr, il reste vulnérable à l’analyse des fréquences, pourvu que le texte chiffré soit assez long et la clé relativement courte : si la clé fait 5 caractères de long, on se retrouve finalement face à 5 substitutions monoalphabétiques (car la clé se répète de façon cyclique lors du chiffrement), d’où on peut conjecturer les lettres les plus fréquentes.

Il faut toutefois connaître la longueur de la clé ; or on peut la déduire de l’espacement des séquences de lettres répétées dans le texte chiffré (là encore si le texte est assez long), qui sera probablement le plus grand diviseur commun des espacements entre les séquences répétées.

Le chiffre indéchiffrable : le masque jetable

Vigénère était plus robuste que tout chiffrement monoalphabétique, mais restait sensible à l’analyse des fréquences. Les Américains eurent l’idée d’une clé de la longueur du message pour utiliser Vigénère : l’analyse de fréquence devient alors impossible si la clé est suffisamment aléatoire, puisque qu’il n’y a aucune répétition prévisible. Il fut finalisé par la major Mauborgne, d’après les travaux de Vernam qui donna son nom au système (« chiffre de Vernam »).

Théoriquement incassable, il est malheureusement très difficile d’emploi :

  • Il faut des clés (masque) vraiment aléatoires, aussi longues que les textes à chiffrer, et nombreuses car chaque masque est jetable (on parle de livre de chiffre pour l’ensemble des feuillets dont chacun décrit une clé jetable). Or un vrai aléas est très difficile à obtenir ;
  • Il faut que l’émetteur et le récepteur disposent de la même liste de masques et les utilisent dans le même ordre (puisque chacun ne peut être utilisé qu’une fois). Toute interception de la liste des masques compromet alors l’ensemble des communications !
  • Il doit impérativement être jetable, car il suffit de deux textes chiffrés avec le même clé pour que la cryptanalyse redevienne possible.

Son usage sur un champ de bataille est rendu quasi-impossible par la nécessité que tous les points de communications doivent avoir le même livre de chiffres (non compromis) et le temps nécessaire au chiffrement et déchiffrement aurait nécessité un travail colossal.

Son usage restera en pratique limité à quelques communications ultra-confidentielles, de fréquence modérée, avec un échange de clés (de livre de chiffres) bien sécurisé.

Exemples de chiffres marquants

  • Enigma
  • Chiffre de Lorenz
  • Chiffre de Beale

Informatique quantique

Voir l’article dédié à l’informatique quantique.

Anecdotes

  • Marie Stuart, reine d’Ecosse, correspondit avec des textes chiffrés pour comploter contre la reine d’Angleterre.
  • George Pérec écrivit en 1969 un livre entier de 200 pages ne contenant pas la lettre e. Sa traduction anglaise réussit le même exploit !
  • Le téléphone rouge entre présidents américain et russe utilise un mécanisme de masque jetable.
  • Ce fut Sacha Guitry qui amena un exemplaire de la machine Enigma en Angleterre12 juste avant l’invasion de la Pologne par les forces allemandes.

Sources

Fiche de lecture : 2253150975 / 978-2253150978

Logarithme discret

Voir aussi

Heartbleed

Heartbleed est le nom donné à une faille dans une implémentation d’openSSL.

OpenSSL : c’est quoi ?

Avant toute chose, il faut savoir que SSL (dont les versions récentes s’appellent TLS) est un protocole qui permet de chiffrer des communications sur internet et d’authentifier une machine (un serveur web par exemple). Chiffrer, c’est rendre illisible un message à tous ceux qui ne disposent pas de la clé de déchiffrement. Ce protocole est très utilisé sur internet, et openSSL est un des outils d’implémentation de SSL parmi les plus utilisés.

Quand vous vous connectez de manière sécurisée sur un site web, vous passez par https et plus de la moitié de serveurs web dans le monde utilisent openSSL pour réaliser cette connexion https.

Quelle est la faille ?

La faille permettrait à un attaquant d’avoir accès à certaines données chiffrées lors des communications SSL sur les sites utilisant les versions vulnérables. En conséquence, certains mots de passe (voire certains certificats) pourraient être compromis et donc réutilisés par l’attaquant.

Quel est le composant touché ?

La faille est exploitable quand une version vulnérable d’openSSL est installée sur le serveur web. OpenSSL est un logiciel open source. Seules certaines versions sont vulnérables :

La branche 0.9.8 n’est pas touchée, et la correction est présente à partir de la version 1.0.1g. 

Sources

  • http://heartbleed.com/
  • https://www.openssl.org/news/secadv/20140407.txt
  • https://www.20minutes.fr/high-tech/1348577-20140410-heartbleed-faire-proteger-faille-securite-geante
  • http://www.lemonde.fr/technologies/article/2014/04/11/faille-heartbleed-les-sites-pour-lesquels-il-est-conseille-de-changer-son-mot-de-passe_4399564_651865.html
  • http://www.lemonde.fr/technologies/article/2014/04/09/une-enorme-faille-de-securite-dans-de-nombreux-sites-internet_4397995_651865.html
  • https://www.nextinpact.com/news/86941-heartbleed-openssl-et-question-securite-expliques-simplement.htm

Poodle

Poodle est le nom donné à une faille inhérente au protocole SSL v3.

Désactivation de SSLv2 et SSLv3 sur Plesk

Sur Plesk, il est possible de désactiver SSL v2 et v3 de façon définitive, grâce à un paramètre disablesslv3 qu’il faut positionner à true. J’avoue avoir eu un peu de mal à trouver comment faire, mais une fois que c’est fait, cela débarrasse de ce boulet !

Pour plus d’informations, il faut aller sur le forum Plesk. Et pour mémoire, voici la manip : 

# mysql -uadmin -p`cat /etc/psa/.psa.shadow` -Dpsa -e "insert into misc values('disablesslv3', 'true')"


# /usr/local/psa/admin/bin/httpdmng --reconfigure-all

La 1ère ligne positionne le paramètre, la 2e permet de reconstruire les configurations nécessaires. Pour vérifier, tapez : 

# cat /var/www/vhosts/system/*/conf/last_nginx.conf | grep ssl_protocols

Il s’agit de la configuration de nginx, et les vieux SSL doivent avoir disparu.

Voir aussi Logjam.

SHA-1

SHA-1 est le nom d’un algorithme de hachage très utilisé en cryptographie.

Qu’est-ce qui se passe avec SHA-1

Beaucoup de bruits courent en 2014-2015 au sujet de la vulnérabilité potentielle de cet algorithme de hachage. Il est très fortement utilisé dans toute l’industrie informatique, notamment dans les certificats numériques (mais pas uniquement).

Or des travaux ont mis en évidence des failles possibles sur cet algorithme dès 2005. Toutefois, cela restait théorique car hors de portée de la puissance de calcul disponible à l’époque. Dix ans plus tard, les choses ont bien sûr évolué.

Quel est le problème ?

Avec l’augmentation continue de la puissance de calcul des ordinateurs, le nombre d’empreintes possibles (2 puissance 160 pour SHA-1) devient une limite de plus en plus accessible pour différents types d’attaques, d’autant que certains types d’attaques permettent de réduire la puissance nécessaire.

Microsoft a pris les devants, et a considéré qu’il devenait hasardeux de continuer à reposer sur l’algorithme SHA-1 pour certains types de certificats, et a décidé de ne plus l’utiliser et de n’utiliser que des algorithmes plus robustes, ce qui est une très bonne chose pour la sécurité informatique en général.

D’autres acteurs de l’informatique ont emboîté le pas de Microsoft, notamment les éditeurs de navigateurs internet : ils ont mis en place des mécanismes d’information et d’alerte pour indiquer à l’internaute qu’un site web (plus précisément : le certificat présenté par le site web) utilisera un algorithme considéré comme obsolète. Cela peut aller de la simple information visuelle (message « les technologies utilisées dans ce certificat seront bientôt obsolètes », changement de couleur de l’icône « cadenas ») jusqu’à l’apparition d’une page d’alerte.

Attaque par collision avec préfixe choisi

Ok, je vous perds, et je m’y perds aussi. Expliquons.

Préfixe choisi

Pour faire simple, cela revient à construire deux documents informatiques ayant le même hash. Google et CWI l’ont fait en 20171.

En 2019, une nouvelle étude2 vient montrer cette fois la viabilité économique3 de cette attaque, en chiffrant le coût de sa réalisation.

Voir aussi

Capri, c’est fini

Début 2020, une étude montre qu’il est désormais possible, à un coût raisonnable, de réaliser des attaques sur SHA-1 à préfixe choisi.

En clair, quand un objet est « signé » via un hash SHA-1, il est maintenant possible de le remplacer par un autre objet dont le hash sera identique.

Conclusion : Les certificats signés en SHA-1 et autres bi-clés de type PGP signées ne peuvent plus être considérés comme valides !

Freak

Une de plus ! Freak est une faille quasiment de conception de SSL. Une fonctionnalité, diront certains.

Dans les années 1990, l’administration américaine s’inquiétait de la prolifération des systèmes de chiffrement, et craignait de ne plus en avoir le contrôle (comprendre : ne plus pouvoir déchiffrer les messages codés, en cas de besoin). Elle a donc décidée d’interdire l’exportation de tout ce qui était indéchiffrable avec les moyens de l’époque, d’où une limitation de la taille de clés (par exemple).

Les outils se sont adaptés en conséquence, prévoyant un mécanisme spécial « export » qui ramenait automatiquement à des valeurs convenables la complexité du chiffrement lors d’un échange, même si les deux parties pouvaient faire beaucoup mieux.

Avec le temps, cette limitation est tombée, mais le mécanisme servant à réduire la taille des clés a été reconduit dans la plupart des outils utilisés. Et on s’en est rendu compte seulement en 2015, alors que cette fonctionnalité était largement documentée, et n’était même pas cachée1 !

FREAK a touché toutes les bibliothèques SSL/TLS ou applications utilisant SSL/TLS ayant respecté la réglementation… et oublié de supprimé cette limitation quand les règles se sont assouplies. Exemple : openSSL, S-Channel, Chrome…

Liens externes

Logjam

Logjam est une nouvelle faille dans le désormais périlleux chemin de la cryptographie, touchant une étape de négociation lors d’une connexion [[TLS|SSL/TLS]]. Même si, comme Freak, son exploitation n’est pas forcément facile, cela va imposer à moyen terme l’augmentation de la longueur de certaines clés, ou l’utilisation de certains algorithmes à la place de certains jugés trop faibles, ce qui aura surtout pour effet de compliquer encore la vie des webmasters (et des navigateurs web).

En effet, à force d’augmenter la solidité des mécanismes de sécurité, on finit par demander beaucoup de calculs à la fois au serveur et au navigateur ; or tout le monde n’est pas obligatoirement à niveau, et on pourrait finir (par exemple) par rendre certains sites inaccessibles aux utilisateurs dont les ordinateurs (ou les navigateurs web) ne sauraient pas composer avec cette complexité croissante.

Une synthèse, avec un outil de test ainsi que les recommandations à suivre sont ici : weakdh.org.

Désactivation sur Plesk

Sur Plesk, si vous avez une version 2.2 d’Apache couplé à nginx, il faudra un peu ruser pour ne plus être exposé à Logjam. pour plus d »infos, allez voir le forum.

Il faut en premier lieu créer un fichier DH personnalisé, de complexité (longueur) suffisante : 

openssl dhparam -out dhparams.pem 2048

Ensuite, il faut un template personnalisé pour ses sites web, dans /usr/local/psa/admin/conf/templates/custom/domain. Le fichier à modifier est nginxDomainVirtualHost.php. Il faut ajouter l’option ssl_dhparam en lui mettant le fichier que l’on vient de créer. 

ssl_ciphers                 HIGH:!aNULL:!MD5;


ssl_prefer_server_ciphers   on;


ssl_dhparam             /dhparams.pem;

Ensuite on reconfigure et ça devrait aller. 

# /usr/local/psa/admin/bin/httpdmng --reconfigure-all

Pour vérifier, tapez : 

# cat /var/www/vhosts/system/*/conf/last_nginx.conf | grep dh_param

Liens externes

  • http://www.nextinpact.com/news/94144-logjam-apres-freak-nouvelle-faille-dans-chiffrement-connexions.htm
  • http://forum.odin.com/threads/ssl-poodle-sslv3-bug.323338/#post-761018
  • https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf

Certificat

Un certificat (en réalité un certificat numérique, mais je simplifie la terminologie car je ne parle que de sécurité informatique) est un document informatique permettant de prouver l’authenticité et l’intégrité d’un élément (une clé) de chiffrement public.

Il existe plusieurs types de certificats, ayant des caractéristiques et des niveaux de garantie assez différents.

Caractéristiques principales

Classes de certificats

Bien qu’il n’y ait pas de standard en la matière, les autorités de confiance délivrant les certificats proposent différents niveaux de garanties, déclinées souvent en classes.

Etendue de la validation

Il y a trois grand types de validation :

Domain Validation (DV)

C’est le type le plus simple de validation pour un certificat. L’autorité de certification (AC) émettra un certificat de validation de domaine à toute personne apparaissant comme contact administratif dans le registre public associé à chaque nom de domaine (ou suivant des contrôles assez simples se basant sur une adresse mail). La seule garantie obtenue est que le nom de domaine est bien celui qui apparaît, ce qui peut suffire à certains usages. Cela permet toutefois de chiffrer le trafic entre l’internaute et le site en question, et d’établir un minimum de confiance de façon assez rapide (pour le propriétaire du site).

Organization Validation (OV)

Ici, l’Autorité de Certification contrôle également l’identité de l’entreprise et de la personne formulant la demande de certificat. C’est un niveau supérieur, qui permet d’associer une identité à un nom de domaine, ce qui peut trouver son utilité quand des noms de domaines peuvent être ambigus.

Extended Validation (EV)

Édictées par le CA Browser Forum1, les directives EV2 obligent l’Autorité de Certification à effectuer une vérification beaucoup plus poussée de l’identité de l’entreprise ou de la personne demandant le certificat. Le niveau de garantie est supérieur à un certificat OV, ce qui est attesté par une barre verte contenant le nom de l’organisation dans certains navigateurs. En général, ils ne permettent pas le multi-domaine (SAN) ni le wildcard.

Type de certificat

Wildcard

Multi-domaine (SAN)

Usage

Validité d’un certificat

Que doit-on vérifier pour pouvoir dire qu’un certificat est valide ?

  1. Le certificat doit avoir un format valide ;
  2. le certificat doit être valide au moment de son utilisation (date de fin mais aussi date de début) ;
  3. il doit être issu d’une autorité de confiance (CA) reconnue et fiable ;
  4. le nom du service correspond bien à celui que l’on veut (champ CN du sujet) ;
  5. l’usage du certificat est conforme à celui qu’on veut en faire, en vérifiant :
    1. Basic constraints : indique notamment s’il s’agit d’un certificat racine ou non (CA:FALSE par exemple)
    2. Key Usage : signature, chiffrement, etc.
    3. Extended Key Usage : authentification du site web, par exemple ;
  6. le certificat ne doit pas avoir été révoqué (mais c’est bien rare que cette vérification soit faite…).

Applications

SSL/TLS

SSL et TLS sont deux noms différents pour la même chose. Enfin presque : il y a eu plusieurs versions de SSL (notamment v2 et v3) puis l’appellation TLS a remplacé SSL. Nous avons donc eu TLS 1.0, puis TLS 1.1 et maintenant TLS 1.2.

SSL est un protocole permettant de sécuriser des échanges de flux réseaux. Comme tout protocole, il n’est constitué que de spécifications : on dit quoi faire et comment. Après, ce sont des programmes (des librairies…) qui implémentent (mettent en oeuvre en pratique) ce protocole.

SuperFish

Etablissement d’une session TLS

Avant d’échanger des messages de façon sécurisée, il faut commencer par se mettre d’accord sur la façon de faire.

Hello client (ClientHello)

Le 1er message est envoyé par le client au serveur. Ce message contient :

  • Le numéro de version de la version TLS la plus récente supportée par le client ;
  • la date et heure client ;
  • 28 octets aléatoires ;
  • un numéro de session (en cas de reprise de session) ;
  • la liste des méthodes cryptographiques supportées par le client ;
  • la liste des méthode de compression supportées ;
  • certaines valeurs spécifiques comme le nom du service demandé (Server Name Indication).

Premier retour serveur

Le serveur va ensuite envoyer un paquet de messages pour avancer dans le dialogue.

Hello serveur (ServerHello)

Le serveur va d’abord poliment renvoyer son bonjour. Il va indiquer :

  • La version du protocole SSL/TLS qu’il souhaite utiliser ;
  • la date et heure côté serveur ;
  • 28 octets aléatoires ;
  • un numéro de session si besoin ;
  • l’algorithme cryptographique et l’algorithme de compression retenus pour cette session, en fonction de ce que supporte le client.

Présentation des certificats du serveur (Certificate)

Le serveur envoie ensuite ses certificats.

à approfondir

Echange de clé serveur (ServerKeyExchange)

Le contenu de cette partie est variable. Elle est fonction de ce qui a été négocié auparavant, principalement des algorithmes cryptographiques retenus.

  • Dans le cas d’un échange de type Diffie-Hellman, ce message contient les paramètres de cet échange. Ils sont générés aléatoirement par le serveur et signés par la clé privée du serveur (sauf dans le cas d’un échangé DH/ECDH anonyme).
  • Dans les autres cas, ce message n’existe pas car les informations nécessaires sont dans le certificat.

Fin du bonjour (HelloDone)

Ce message marque la fin de cette étape. Mais ça n’est pas fini pour autant.

Pre-master secret

Voici maintenant une étape tout aussi importante dans l’établissement de l’échange : l’échange d’un pre-master secret, valeur essentielle pour la connexion, et qui ne doit être connue que des deux parties (Alice et Bob). Il existe plusieurs méthodes pour cela :

  • RSA : la valeur secrète est générée par le client, aléatoirement, et elle est envoyée au serveur chiffrée avec la clé publique du serveur (donc seul le serveur peut la déchiffrer), dans un message ClientKeyExchange.
  • Diffie-Hellman ou Elliptic Curve Diffie-Hellman (DH ou ECDH) : la valeur secrète est négociée via l’algorithme de Diffie-Hellman. Il en existe une variante basée sur les courbes elliptiques. Les paramètres côté serveur sont inclus dans le certificat ; côté client, c’est également dans le certificat si le client en présente un, sinon il doit en générer aléatoirement.
  • Diffie-Hellman Ephemeral (DHE) avec également une variante basée sur les courbes elliptiques (ECDHE) : les valeurs secrètes sont générées aléatoirement, dans tous les cas, et de façon unique pour chaque transaction. Côté serveur, les paramètres sont signés avec sa clé privée.
  • Diffie-Hellman anonyme, avec variante EC : C’est du DHE mais sans chiffrement côté serveur. En conséquence, cette négociation est vulnérable aux attaques MITM.

On en parle, hélas

Oui, on parle de SSL malheureusement, car on se rend compte de son importance et de la menace représentée par les failles du protocole ou de son implémentations. Freak, Poodle ou Heartbleed sont des exemples de failles ayant fortement impacté le monde informatique mais aussi, indirectement, les utilisateurs.

Quelles versions utiliser ?

Le conseil général est le suivant : toujours utiliser la dernièr version quand c’est possible.

Est-ce toujours possible ?

Comme le titre le laisse entendre : non. Comme vu plus haut, la connexion en SSL/TLS se fait sur la base d’une négociation entre le serveur (le site internet) et le client (le navigateur web). Les deux essayent généralement d’utiliser les versions les plus récentes et les plus sécurisées, mais il arrive souvent que les navigateurs ne soient pas à jour et ne connaissent tout simplement pas les versions récentes de TLS.

Y a-t-il des versions à éviter ?

Oui, car certaines versions contiennent des failles intrinsèques (par exemple Poodle). Par ailleurs, avec le temps, certaines attaquent deviennent plus faciles : soit parce qu’elles sont mieux connues, soit parce que la puissance de calcul nécessaire est plus facilement accessible. A fin juin 2015, on considère que SSL v2 et SSL v31 ne doivent plus être utilisées.

Liens

Liens internes

Liens externes

Registre distribué

La technologie de registre distribué a le vent en poupe depuis quelques années (depuis la popularisation des cryptomonnaies telles que le bitcoin). On appelle aussi ça « chaîne de blocs », traduction plus littérale mais technique : ça dit ce que c’est, mais pas ce que ça fait, à l’inverse de « registre distribué ».

Continuer la lecture →