Sécurité Vol 2 - Les base en cryptographie - 1

J'ai pris le temps pour écrire ce second article sur la sécurité mais vieux motard que jamais. J'ai été pas mal occupé et un peu fainéant pour être honnête. Bref, je vais expliquer brièvement les bases techniques essentielles qu'il est indispensable de maîtriser pour pouvoir comprendre ce qui viendra ensuite.

Précédent article de la série : Sécurite - Vol 1 : définitions

Un peu de vocabulaire

Tout d'abord une précision utile. Le langage couramment employé en matière de cryptographie est généralement incorrect. Entre néologismes et mauvaises traductions de l'anglais, la plupart des gens, et j'en fait partie, utilisent des mots qui portent un sens différent de celui qu'ils veulent communiquer, ou qui carrément n'existent pas. Je vous renvoie à cet article très clair sur le sujet : Les mots « crypter » et « cryptage » n’existent pas !.

J'utilise parfois les conventions courantes bien qu'elles soient incorrectes : par exemple "décrypter" au lieu de "déchiffrer". Toutes mes excuses aux puristes.

Hachage

Le hachage est désigné par de nombreux termes souvent dérivés de l'application de ce principe qui est très employé en informatique et en cryptographie. On entendra donc parler de hashcode, d'empreinte, de condensat, de clé de contrôle et d'autres termes encore.

Le hachage est simplement une fonction (au sens mathématique du terme) qui prend en entrée une information quelconque et produit en sortie une donnée qui a des propriétés particulières qui la rendent très utile dans de nombreux domaines.

Le hash a donc des propriétés intéressantes dont nous allons parler rapidement.

Unicité

Deux données différentes en entrée ne produiront jamais un hash identique. C'est la conception de l'algorithme de hachage qui garantit ceci

Si deux valeurs différentes peuvent produire un même hash, on parle de collision, et quand la possibilité d'un tel cas est avérée l'algorithme est abandonné. Ceci s'est déjà produit à plusieurs reprises par le passé ce qui n'est pas sans conséquence. Par exemple, les algorithmes de hachage étant implémentés par les navigateurs pour sécuriser la navigation en https, le fait qu'on découvre qu'un algorithme doit être abandonné et remplacé par un autre implique une mise à jour du navigateur. Voilà pourquoi il est recommandé de toujours utiliser un navigateur récent et à jour pour faire des achats ou toute autre opération sensible en ligne. C'est également pour cette raison qu'il faut maintenir à jour ses systèmes d'exploitation. Actuellement (début 2017) l'algorithme SHA-1 est majoritairement utilisé, or il vient d'être démontré qu'il avait des failles et devait être abandonné au profit d'un algorithme plus robuste (SHA-256 à priori).

Non-réversibilité

Il n'est pas possible de retrouver la donnée en entrée à partir de son hash. Si quelqu'un dispose du hash d'une donnée, il ne peut pas en déduire la donnée initiale.

C'est pour cette raison que les hackers ont constitué des bases de données avec des milliards de chaînes de caractères, et le résultat de l'application des fonctions de hachage courante sur chacune de ces données. Ainsi, en connaissant un hash et l'algorithme avec lequel il a été produit (des données relativement aisées à obtenir), en faisant une recherche dans cette base sur la colonne qui stocke le hash, on pourra déduire la chaîne de caractères initiale si elle n'est ni trop longue ni trop complexe (la complexité de mesurant par le fait de mélanger différentes types de caractères : minuscules, majuscules, caractères spéciaux etc...). On appelle ça une attaque par dictionnaire.

Usages fréquents

Contrôle d'accès par mot de passe

Il est fréquent que les applications nécessitent une authentification de l'utilisateur, ceci afin de vérifier son identité. Une fois l'identité établie, il est possible de déterminer son niveau d'habilitation (les actions qu'il peut entreprendre, les données auxquelles il a accès etc.). 

Le moyen le plus simple et le plus fréquent encore de nos jours de contrôler l'identité d'un utilisateur est de lui demander de s'identifier en saisissant un identifiant (login) et de prouver qu'il est bien le détenteur de cette identité en fournissant un mot de passe. Comme le mot de passe a été défini initialement par l'utilisateur à la création de son compte, et qu'il est censé ne l'avoir communiqué à personne et le conserver secret (en évitant par exemple de l'inscrire sur un post-it collé sur son écran), si le mot de passe fourni correspond, on est certain de l'identité de la personne.

Intuitivement on imagine que l'application en question doit stocker le mot de passe de l'utilisateur quelque part en regard de son identifiant pour pouvoir vérifier le mot de passe. Hé bien non. Il est certes possible de faire ainsi mais c'est une très très très mauvaise pratique et c'est bien souvent interdit. En fait, on ne stocke pas le mot de passe mais uniquement son hash. En comparant le hash du mot de passe saisi avec le hash stocké initialement, on fait la vérification voulue sans devoir stocker en clair le mot de passe (ce qui permettrait à quelqu'un de mal intentionné ayant accès au fichier des mots de passe d'usurper n'importe quelle identité).

Il arrive que des hackers arrivent à voler les fichiers stockant les identifiants et les mots de passe, ou les hash de mot de passe si la sécurité est gérée correctement (ceci dis, si c'était le cas, il n'auraient pas pu voler les fichiers en question). Si les mots de passe sont en clair, ils peuvent directement voler votre identité numérique (s'authentifier sous votre nom et mener des actions qui vous seront imputées).Si ce sont des hash, ils feront une attaque par dictionnaire : si vos mots de passes sont trop simples et trop courts, ils arriveront à leur fin, mais si vous avez défini un mot de passe assez long et mélangeant chiffres + lettres + caractères spéciaux, ils n'arriveront pas à trouver votre mot de passe.

On peut éliminer le risque d'attaque par dictionnaire en utilisant une technique appelée "salage" (salt) : au lieu de stocker le hash du mot de passe, on stocke le hash de la combinaison du hash du mot de passe et d'une chaîne de caractère constante. Il n'y a ainsi plus de lien direct entre la valeur stockée dans le fichier des mots de passe et le mot de passe de l'utilisateur. 

Vous devez comprendre maintenant pourquoi de plus en plus on vous oblige à avoir des mots de passe d'une longueur minimum et avec une certaine complexité. 

Si on ajoute qu'on peut en outre vous obliger à les changer fréquemment, et sans réutiliser des anciens mots de passe, et que vous utilisez de nombreuses applications ayant chacune sa propre liste d'utilisateurs et mots de passe, ça peut rapidement devenir problématique de se rappeler de tous ces mots de passes. Une astuce serait d'utiliser le même mot de passe sur les différentes applications mais d'une part ce n'est pas forcément possible (chaque application imposant des règles de longueur et de complexité différentes), et d'autre part c'est dangereux (le mot de passe volé sur un site donnera accès à tous vos autres comptes sur tous vos autres sites). Une autre astuce consiste à noter tous ces mots de passes et identifiants quelque part... très dangereux aussi car si quelqu'un vole votre fichier, il aura accès à toutes vos identités numériques. Il existe différentes parades dont nous parlerons plus en détail dans un autre article tant le sujet est vaste (en informatique, il existe une discipline spécifique dédiée au sujet, appelée IAM Identity and Access Management) : mise en place de SSO (Single Sign On, on ne s'authentifie qu'une seule fois et une seule identité numérique permet l'accès à de multiples applications), fédération d'identité (un même référentiel utilisateur est utilisé par de nombreuses applications interfacées via des protocoles standards sur le référentiel en question).

Signature électronique

Dans le monde réel, vous authentifiez des documents en apposant votre signature. Il existe un équivalent en informatique qui a la même valeur probante au niveau juridique moyennant le respect de quelques pré-requis.

Nous n'allons pas détailler ce point car nous n'avons pas encore abordé tous les pré-requis. Mais nous pouvons déjà expliquer que la signature numérique est un hash du document qui a ensuite été chiffré par un algorithme de cryptographie asymétrique (rien de compliqué, nous verrons ça dans un prochain article).

Du fait des propriétés d'un hash, on peut vérifier la validité de la signature vis à vis d'un document en recalculant le hash et en le comparant avec la signature numérique (le hash initial qui a été chiffré). Si le document a été modifié, le hash sera différent et la signature invalide pour ce document (par ailleurs, il n'est pas possible de falsifier la signature de par les propriétés de la cryptographie asymétrique)..

Usages courants en informatique

Nous mettons le focus sur la sécurité et n'abordons donc pas toute une catégorie d'usages des fonctions de hachage en informatique (généralement basées sur l'unicité et la moindre taille que la donnée hachée).

Un hash peut servir de somme de contrôle (checksum). L'exemple typique est le téléchargement d'un très gros fichier depuis un serveur web : il y a des risques non négligeables que le fichier téléchargé sur votre poste soit corrompu (un seul octet invalide suffit, si votre fichier fait des centaines de Méga-Octet et est téléchargé depuis l'autre bout du monde et passe par des lignes sous marines et un grand nombre d'équipements réseaux, il n'est pas exceptionnel que des problèmes surviennent). Pour vérifier que le fichier n'a pas été corrompu (et éventuellement de façon volontaire pour introduire un virus dans un programme par exemple, au delà des simples problèmes de communication), vous pouvez généralement télécharger un second fichier (bien souvent le résultat d'un hachage par l'algorithme MD5) : ce second fichier est le hash du fichier téléchargé. Avec l'utilitaire adéquat implémentant l'algorithme de hachage utilisé, vous recalculez le hash du fichier et le comparez avec le hash téléchargé : si ils correspondent, le fichier n'a pas été corrompu sinon vous n'avez plus qu'à relancer le téléchargement).

Conclusion (temporaire)

La sécurité est un sujet relativement complexe : si on essaye de le prendre de front c'est très obscur, mais si on commence par comprendre les briques de base, ça devient assez simple, tant qu'on ne rentre pas dans les arcanes des algorithmes (sinon un très solide bagage mathématique est requis).

Nous venons de voir une première brique, les autres suivront dans quelque temps.