Linux Attitude

Niveau :
Résumé : HTTP

HTTP règne en maître dans le monde des protocoles. C'est le plus utilisé et il n'est pas près de lâcher sa place. Je vais vous rappeler pourquoi.

Les protocoles

Dans le monde des protocoles il y a plusieurs couches.

Partons de la couche 3 : IP. Ce protocole est internet à lui tout seul. Personne ne parviendra à le détrôner si ce n'est lui-même (IPv6). Les autres protocoles de niveaux 3 viables visent des niches ou du à-peine-réseau (bluetooth ou usb collent aussi au modèle osi).

Sur la couche 4 on trouve TCP et UDP, qui ont très peu de concurrents. Il en existe, mais ils sont rares car difficiles à développer (il faut toucher au noyau sous linux si on veut faire propre et efficace).

Sur la couche 5 on trouve des milliers de protocoles, ils sont faciles à développer (en espace utilisateur) et donc courants. Et pourtant, on constate que sur internet un très petit nombre d'entre eux sont utilisés en masse : DNS, SMTP, HTTP. Les autres POP, IMAP, FTP, SSH ... sont utilisés mais commencent à se faire anecdotiques. Pourquoi ?

HTTP

HTTP est de loin de plus utilisé parce que de plus en plus de services se basent directement sur HTTP plutôt que d'inventer leur protocole. Et ils ont de très bonnes raisons pour ça :

• ne pas réinventer la roue, des bibliothèques et des serveurs existent déjà
• HTTP est autorisé à traverser quasiment tous les firewalls
• il traverse le NAT
• il est capable de supporter la déconnexion (il fonctionne en mode non connecté)
• le SSL est déjà implémenté
• l'authentification est déjà implémentée
• il est possible de développer rapidement une preuve de concept avec apache et un langage de script
• il utilise une API très simple : question -> réponse

Du coup on le retrouve dans :

• les sites web (ouf)
• le transfert de fichier
• les systèmes de fichiers (webdav)
• les appels de fonction à distance (XMLRPC)
• la gestion de calendrier (caldav)
• l'interconnexion de services (SOAP)
• les applications distantes (ajax)
• la communication instantanée (Jabber)
• et j'en oublie ...

Mais pourquoi une telle domination sur tous les autres protocoles ? Ce n'est pas seulement grâce à l'omniprésence des navigateurs. Tout d'abord HTTP propose déjà un certain nombre de services (voir plus haut) qui ne sont plus à redévelopper. Mais surtout, regardons ses concurrents :

• SMTP
• DNS
• RPC
• SNMP
• Et c'est tout !

Oui c'est tout, en effet, ce sont à peu près les seuls protocoles qui ont été prévus pour être extensibles et disposer d'une couche supérieure. Ils fonctionnent tous sur le système question réponse et laissent le soin à la couche du dessus d'interpréter le sens des questions et des réponses :

• DNS : basé sur UDP, non fiable, limité en taille -> éliminé
• SNMP : idem, même s'il existe une version TCP -> éliminé
• RPC : format binaire difficile à mettre en place -> éliminé
• SMTP : il est difficile de récupérer autre chose que des codes d'erreur en SMTP puisqu'il est fait pour l'envoi -> éliminé

Si on veut développer une nouvelle application qui communique par le réseau, on a le choix entre inventer un nouveau protocole ou simplement créer une sémantique de question / réponse au dessus de HTTP et profiter de tous ses avantages. Les rares cas où ce n'est pas possible :

• besoin de données en temps réel (et encore le débit augmentant, HTTP peut faire RTSP du pauvre)
• besoin de la notion d'évènement du serveur vers le client (et encore, certaines bidouilles HTTP laissant la connexion ouverte permettent ce comportement)
• besoin de multicast ou de fonctionnalités encore exotiques aujourd'hui

Conclusion

Le HTTP c'est LE protocole, celui qui remplace le TCP d'hier. Le TCP n'est plus ce qu'il était, c'est à dire la couche sur laquelle on se base pour développer un nouveau protocole. Vous pouvez être sûr qu'il y a encore des milliers de protocoles à inventer, mais vous pouvez aussi être sur que la plupart d'entre eux se baseront sur HTTP. D'ailleurs celui-ci étant extensible, il est probable qu'il évolue un jour pour être un peu plus générique et apporter des réponses aux problèmes qui se posent dans certains cas comme les évènements.

On ne devrait plus parler de TCP/IP mais de HTTP/TCP/IP. Finalement, on se rapproche du modèle OSI.

Niveau :
Résumé : crypto

Vocabulaire

Avant de pouvoir parler de sécurisation des communications, il faut avoir quelques bases en cryptographie. Commençons par le vocabulaire :

• Coder : transformer une information en code (par exemple numériser une photo, écrire en morse ou en ASCII)
• Chiffrer : transformer une information codée de façon à la rendre illisible à une autre personne que son destinataire
• Déchiffrer : lire un document chiffré avec les informations nécessaires pour le faire
• Décrypter : tenter de lire un document chiffré sans avoir la clé de déchiffrement
• Signer : ajouter une information à un document prouvant qu'il a bien été écrit/lu par son auteur/lecteur sous cette forme et n'a pas été modifié
• Empreinte : somme de contrôle d'un message (MD5, SHA) en cryptographie on cherche à faire en sorte qu'il soit impossible de créer un message ayant une empreinte donnée
• Cryptanalyse : études des attaques permettant de décrypter un message ou de casser un chiffrement
• Cryptographie : étude des systèmes de protection de messages
• Cryptologie : ensemble de la cryptographie et de la cryptanalyse
• Crypter : ce mot n'existe pas

Entropie

L'entropie est une mesure de la quantité d'information. Cette mesure n'est pas absolue, elle est relative à une quantité d'information possible.

Par exemple un octet est une valeur parmi 256. Un octet vraiment aléatoire (avec une répartition linéaire) a donc une entropie de 8. En pratique on ne cherche que rarement la valeur d'une entropie. On chercher plutôt à comparer obtenir des propriété sur l'entropie.

Par exemple prenons une suite de 5 octets. Si je peux déduire les 4 dernier octets à partir du premier (2*x 4*x 8*x 16*x), alors leur entropie est la même que celle d'un seul octet.

Maintenant si cette suite est véritablement aléatoire (tirée aux dés non pipés), l'entropie devient 5 fois plus grande.

Et enfin si cette suite n'est pas vraiment aléatoire, c'est-à-dire tirée avec un générateur pseudo aléatoire (/dev/urandom), alors leur entropie est égale à l'entropie du générateur pseudo aléatoire. Celle-ci se mesure par la taille de l'état interne du générateur.

Il est important de bien saisir cette notion pour comprendre la sécurité des algorithmes.

Entropie mesurée

Lorsque nous générons une suite d'octets, nous pouvons connaître l'entropie des données (et encore ...).

Lorsque nous récupérons des données, l'entropie n'est pas mesurable. Mais elle est estimable. En effet, pour une grande suite d'octets, si celle-ci est compressible, cela veut dire qu'il existe une technique pour déduire certains octets à partir des autres. L'entropie est donc très (le très variant en fonction du nombre d'octets considérés) probablement inférieure à la taille de la version compressée.

Pour tout système on peut donc chercher à en réduire l'entropie en éliminant des informations qui n'en sont pas vraiment. C'est le travail que font les gens qui développement des codecs (audio, vidéo ...).

Espace de chiffrement

L'espace de chiffrement est le nombre de tests que l'on doit effectuer pour en découvrir la clé de chiffrement d'un système. Si le système de chiffrement était parfait, il serait de la même taille que la clé. Malheureusement, on sait que la perfection n'existe pas.

Les études successives d'un système permettent souvent de réduire cet espace. Soit grâce à des informations obtenues par des moyens détournés (sous partie de la clé disponible, comparaison possible de texte clair et de texte chiffré ...), soit par une faiblesse du système qui va réduire sa propre entropie (ce cas est assez rare).

Sécurité

La sécurité d'un système s'estime à partir de cet espace de chiffrement. Plus il est grand, plus une machine devra mettre de temps pour trouver la clé de chiffrement et plus le système va être sûr.

Attention tout de même, ce n'est pas parce qu'un système de chiffrement est sûr que vos données le sont.

Et la littérature est abondantes sur le sujet, wikipedia n'est pas le seul à proposer des informations.

Niveau :
Résumé : RSA ; DSA

La suite ... la suite ... Aujourd'hui les signatures.

Non il ne s'agit pas du petit gribouillis que vous mettez en bas des chèques. Il s'agit de signature numérique. Et ce n'est pas non plus une image scannée de votre gribouillis. Même si le but de la signature numérique est la même, il s'agit de présenter une preuve (presque) infalsifiable du fait que vous avez bien lu, voire écrit un message.

En fait la signature ne fait que vous identifier, prouver que c'est bien vous qui étiez là. Le sens même de la signature dépend du document signé (chèque, article scientifique, patch ...)

Principe

Un document signé numériquement doit assurer deux choses :

• Que le document transmis n'a pas été modifié depuis que vous l'avez lu
• Que c'est bien vous qui avez lu / écrit / approuvé ce document, c'est-à-dire
  • que ce n'est pas quelqu'un d'autre
  • que vous l'avez bien fait

C'est la combinaison de deux choses qui va permettre cela :

• Une fonction de hachage à sens unique
• Un algorithme à clé publique

La première garantit que le document correspond à une empreinte et qu'on ne produire de document modifié ayant la même empreinte. Le deuxième garantit que la signature ne peut être générée à partir d'une empreinte différente, si ce n'est par le signataire.

Par conséquent, on prouve que c'est bien le propriétaire de la clé concernée qui a signé le document.

Attention, seule la combinaison document - empreinte - signature le prouve. Ce qui veut dire qu'il est toujours possible de supprimer un élément pour empêcher de prouver que vous l'avez signé (non monsieur le juge, il n'y a pas de preuve que j'ai signé ce chèque). Dans le même ordre d'idée, seule la signature de la clé prouve que celle-ci vous appartient et donc que c'est bien vous l'auteur de la signature. C'est donc au destinataire de conserver ces données s'il veut un jour pouvoir fournir la preuve que vous avez signé le document.

Authentification

La signature permet l'authentification. Supposons que vous vouliez vous authentifier sur un serveur. Il suffit que le serveur vous envoie un challenge (un message) que vous devrez signer. Il va alors vérifier la signature (et les certificats qui vont avec) et vous serez authentifié.

Algorithmes

Hachage

On utilise une fonction de hachage qu'on considère comme sûre (donc éviter md5). Voir l'article précédent.

RSA

Pour la partie signature à clé publique, on utilise souvent le RSA comme expliqué dans un article précédent.

DSA

Un autre algorithme est fréquemment utilisé pour les signatures, il s'agit du DSA (Digital Signature Algorithm). Cet algorithme à clé publique a été développé pour ne fonctionner que dans le mode signature.

Il n'est ni plus ni moins sécurisé que le RSA, il est juste différent. Il utilise des formules mathématiques similaires au RSA et n'est pas plus difficile à comprendre que celui-ci.

Niveau :
Résumé : SHA1 ; MD5

Une fonction de hachage est une fonction surjective qui prends un certain nombre d'octets en entrée et qui rend un nombre fixe d'octets en sortie. Elles sont donc à sens uniques et plusieurs entrées peuvent donner le même résultat.

Ces fonctions peuvent servir à la détection d'erreurs involontaires ou à la détection de modifications volontaires. Dans le premier cas on cherche à avoir une fonction qui permettra de détecter des erreurs de transmission, de lecture ou de recopie (le dernier chiffre de votre numéro de sécurité sociale). Dans le deuxième cas, on cherche à empêcher une personne de lire ou de modifier elle-même le contenu des données et de les faire passer pour les données originales, c'est ce qu'on utilise pour signer un document ou stocker un mot de passe (vous saviez que vous aviez en réalité une infinité de mots de passe qui fonctionnent ?).

CRC

Dans la première catégorie, on trouve un grand nombre de codes de redondance cyclique. Ils consistent à calculer des polynômes sur les données en entrée. Il existe une méthode permettant de les calculer facilement et sous forme de flux, ce qui fait qu'ils sont très rapides et facile à implémenter dans le matériel.

Ils ne sont pas standardisés puisqu'ils dépendent de la définition du polynôme choisi ainsi que de la taille du résultat.

Par contre les CRC ne permettent pas de protéger les données contre des modifications volontaires puisqu'il est assez facile de calculer une série d'octets qui donnera un résultat donné.

MD5

MD5 a été inventé par Ronald Rivest, celui qui a fait entre autre rc4 et rc5. Cette fois l'algorithme a pour but d'empêcher de reconstruire une source de données différente produisant un résultat donné. Il est très répandu et sert probablement à stocker vos mots de passe. Malheureusement il est depuis quelque temps déjà considéré comme peu sûr, même s'il n'y avait pas eu d'attaque dessus. Il a d'ailleurs récemment fait la une puisqu'il a été possible de calculer des collisions avec un bête cluster de 200 PS3 pendant quelques jours, comme quoi c'est à le portée de tout le monde.

Il est donc fortement déconseillé de l'utiliser pour une application de sécurité durable.

SHA

SHA est une série de fonctions de hachage dont les algorithmes sont complètement différents les uns des autres. Elles peuvent être utilisées pour la sécurité tout comme MD5.

• SHA-0 est dépassés depuis longtemps.

• SHA-1 est la plus répandue après MD5, et conseillée si vous ne disposez pas de SHA-2. Bien qu'on ait des doutes sur sa sûreté, on n'a pas encore réussi à produire des collisions en un temps humainement mesurable.

• SHA-2 est une fonction de hachage à taille variable. Si vous voyez des SHA-224, SHA-256, SHA-384 ou SHA-512, il s'agit toutes de SHA-2 avec la taille précisée en suffixe. C'est la méthode la plus sûre actuellement.

• SHA-3 n'existe pas encore et fait l'objet d'un concours pour savoir quelle sera la solution d'avenir. (d'ailleurs monsieur sécurité Bruce Schneier en personne y participe)

Niveau :
Résumé : DES ; AES

Après avoir vu le fonctionnement des algorithmes de chiffrement à clé publique, intéressons-nous à leur complémentaire, les algorithmes à clé privée.

Algorithme

La méthode de chiffrement par clé privée est des plus simple. Une valeur, commune à deux personnes communiquant ensemble, permet de chiffrer et déchiffrer des messages.

Exemple avec l'algorithme d'addition / soustraction :

• Choix d'une clé privée entre les 2 participants : 4
• Message à envoyer : 123
• Chiffrement du message : 123 + 4 = 127
• Envoi d'un message chiffré 127
• Déchiffrement du message : 127 - 4 = 123

Simple comme bonjour à comprendre, il a fallu des siècles pour admettre qu'il était plus important de cacher la clé que de cacher la méthode de chiffrement. Ceci pour une raison simple, les algorithmes utilisés jusque là étaient trop simplistes et n'auraient pas résisté à la moindre analyse.

Il existe de très nombreux algorithmes, plus ou moins bons, plus ou moins historiques, plus ou moins standards. Limitons-nous à deux standards.

Algorithmes de chiffrement

DES

Le DES est un algorithme promu par la NSA (qui a pour objectif de vous espionner) dans les années 70. Il est relativement simple et avec un peu de patience vous le comprendrez sans problème. Il se base sur un ensemble de 16 cycles de permutations et décalages paramétrés par la clé. Je ne le décrirai pas car c'est un peu long et pas franchement utile.

Il est obsolète depuis longtemps mais ne lâche pas le morceau si facilement (die DES, die). Il se base sur une clé de 56bits et est sensible à la cryptanalyse différentielle (utilisation de plusieurs messages semblables pour trouver la clé plus facilement).

AES

L'AES est un algorithme récent promu par le NIST (qui a pour objectif de standardiser le monde industriel). Je n'ai pas lu en détail la spécification, mais il s'agit d'une combinaison de 4 opérations élémentaires : le remplacement d'octet, le décalage d'octet, l'échange d'octets et la combinaison avec la clé.

L'AES permet d'utiliser des clés de taille variable entre 128 et 256 bits.

Méthodes de chiffrement

Les algorithmes sont eux-même divisés deux grandes catégories selon ce qu'ils sont capables de chiffrer.

Chiffrement par bloc

Les algorithmes de chiffrement par bloc sont capables de chiffrer des blocs indépendamment les uns des autres. Ce qui est très pratique pour les disques durs par exemple.

Chiffrement par flot

Les algorithmes de chiffrement par flot sont capables de chiffrer des données au fil des données, l'élément de base étant généralement bien plus petit qu'un bloc. C'est bien utile pour vos conversations téléphoniques par exemple.

Il est en général possible de transformer un algorithme de chiffrement par bloc en algorithme de chiffrement par flot. Le contraire n'est pas toujours vrai.

Niveau :
Résumé : RSA ; courbes elliptiques

Après vous avoir présenté les certificats, parlons de ce qui a permis la création de la notion de certificat : le chiffrement à clé publique.

Algorithme

Un algorithme de chiffrement à clé publique est un algorithme qui utilise une clé différente pour chiffrer et pour déchiffrer. Prenons un exemple simple et supposons que personne n'ait découvert la division. On choisit un algorithme à base de multiplication :

• Créons une clé privée : 0.25
• Et une clé publique : 4
• Un message à chiffrer : 123
• Chiffrons le message avec la clé publique : 123 * 4 = 492
• On transmet le message 492
• Déchiffrons le message avec la clé privée : 492 * 0.25 = 123

Et voila, on peut donner à tout le monde la clé publique. Personne ne sachant diviser par 4, il est impossible de retrouver la clé privée à partir de la clé publique, il est donc impossible lire un message qui a été chiffré spécialement pour vous avec votre clé publique. Par contre, en tant que possesseur de la clé privée, cachée au reste du monde, vous pourrez le lire.

Remarquez qu'on peut aussi utiliser la même technique dans l'autre sens pour faire de la signature :

• Créons une clé privée : 0.25
• Et une clé publique : 4
• Un message à signer : 123
• Signons le message avec la clé privée : 123 * 0.25 = 30.75
• On transmet le message 123 avec sa signature 30.75
• Vérifions la signature avec la clé publique : 30.75 * 4 = 123

Cet algorithme prouve cette fois que c'est bien la clé privée qui a été utilisée pour produire le message. En effet, personne ne sachant diviser 123 par 4, seul vous êtes capables de produire la signature à partir du message de départ. Mais attention, ça ne prouve pas que le message n'a pas été créé de toutes pièces. C'est pourquoi, en pratique, on utilise en plus une fonction à sens unique pour éviter qu'on puisse créer un message à partir de votre signature.

Bien sûr en pratique on utilise des fonctions un peu plus complexes et des nombres un peu plus grands.

RSA

Le RSA, du nom de ses inventeurs Rivest, Shamir et Adleman, est un algorithme de chiffrement à clé privée basé sur la fonction puissance modulo.

C = M^e [n]

• M est le message à chiffrer
• C est le message chiffré
• n et e sont la clé publique

Pour le déchiffrer on utilise :

M = C^d [n] 

• d est la clé privée

Et c'est tout, la méthode présentée précédemment pour chiffrer et déchiffrer est toujours valide. Il reste à créer les différents nombre proposés ici :

• On prend p et q 2 nombres premiers choisis au hasard
• On prend e statiquement (généralement 3 ou 65637)
• n = p*q
• On calcule d de façon à ce que e*d = 1 (p-1)(q-1)

Et voila on a toutes nos données. Notez que je n'ai pas prouvé que ça marche, mais d'autres l'ont fait.

La sécurité du système suppose deux choses :

• on a besoin de p et q pour retrouver d
• on ne connaît pas d'algorithme rapide nous donnant p et q à partir de n

Une clé RSA typique fait entre 1024 bits et 4096bits soit entre 100 et 400 chiffres.

Courbes elliptiques

Le RSA n'est pas le seul algorithme de chiffrement à clé publique, loin de là, mais c'est le plus utilisé. Le chiffrement par courbe elliptique utilise des courbes elliptiques (sisi) qui sont de la forme

y^2 = x^3 + a*x + b

Le chiffrement se base sur l'inversion de points sur cette courbe.

Je ne vous ferais pas l'affront de vous expliquer les théorèmes mathématiques qui sont derrière, je pense qu'ils sont connus de tous !
Non en fait, c'est surtout que je n'ai pas tout compris, mon niveau en mathématiques est un peu trop léger et je ne voudrais pas dire de connerie.

Ce qu'il faut savoir à propos de courbes elliptiques :

• Les théorèmes sous-jacents sont similaires à ceux du RSA, ce qui veut dire qu'un algorithme pour casser l'un permettrait de casser l'autre
• Les clés de chiffrement peuvent être plus petites pour une sécurité similaire, 224 bits équivaut à une clé RSA de 2048bits (attention ce n'est pas linéaire).
• Les algorithmes de chiffrement et déchiffrement sont plus lents que pour le RSA
• La résistance à la cryptanalyse augmente plus vite avec la taille des clés que pour le RSA

Niveau :
Résumé : certificat

Parlons un peu sécurité. Il a déjà été question de certificats iciet là. Attachons-nous un peu plus à comprendre ce qu'est un certificat.

Un certificat est composé d'une partie publique et d'une partie privée. Je vous passe la théorie sur la cryptographie à clé publique, ce sera pour une autre fois. Intéressons-nous à la partie publique du certificat. Dans le cas d'un certificat x509 (initié par l'ITU, formaté par RSA et complété par l'IETF), on trouve un certain nombre d'informations. Ces informations permettent deux choses :

• identifier le propriétaire
• authentifier le propriétaire

Accessoirement on y retrouve aussi des signatures prouvant que l'identification a été faite par une personne digne de confiance.

Usage

On se sert de ces certificats pour initialiser des connexions sécurisées. Pour cela on commence par vérifier que le certificat appartient bien à la personne avec qui on veut communiquer grâce à une chaine de certification. Ensuite on vérifie qu'on a bien le propriétaire du certificat, et enfin on utilise un protocole adapté pour s'échanger une clé de session permettant de chiffrer les prochaines communications.

Détaillons tout ceci en partant de la fin.

Clé de session

Le chiffrement à clé publique a l'inconvénient d'être lent, on préfère donc utiliser un algorithme à clé privée, plus rapide, pour communiquer le plus gros des données. C'est pourquoi on s'échange une clé de session temporaire en utilisant un algorithme à clé publique, puis le reste de la communication se fait par clé privée.

Autre avantage, l'attaque est plus difficile puisque la clé servant à la communication peut changer régulièrement.

Mais avant de s'échanger une clé de session, il faut être sur de parler à la bonne personne.

Authentification

Pour être sur de communiquer avec le propriétaire du certificat, on utilise un algorithme à clé publique prouvant qu'on discute bien avec le propriétaire de la clé privée correspondante. Grâce à quelques échanges on sait qu'on communique avec la bonne personne et on peut commencer à échanger des données privées comme la clé de session.

Cette vérification peut être faite dans les 2 sens, chacun peut authentifier son correspondant. Pourtant dans le cas du web, c'est généralement seulement le client (internaute) qui authentifie le serveur (site web).

Mais avant d'authentifier votre correspondant, vous voudriez être sur que c'est bien avec lui que vous voulez communiquer.

Vérification du certificat

Rien ne sert de parler à Superman si sa carte d'identité indique qu'il est en fait Clark Kent

On vérifie donc que le certificat qui nous est présenté n'a pas été falsifié, mais surtout on vérifie ses signatures (toujours avec quelques algorithmes à clé privée bien sentis). S'il est signé par une personne de confiance alors on lui fait confiance. Sinon niet, rien ne prouve que ce n'est pas ma banque qui joue à se faire passer pour mon voisin.

La chaine de confiance

Un certificat est signé par une autorité, qui est elle-même représentée par un certificat. Mais alors, que vérifie-t-on ?

En effet, rien ne prouve qu'on connait l'autorité mieux que le correspondant. On vérifie donc qu'elle est elle-même signée par une autre autorité. La boucle ne s'arrête que lorsqu'on tombe sur un certificat racine, signé par lui-même. On est alors obligé de lui faire confiance les yeux fermés (enfin presque, on vérifie qu'elle est installée sur la machine) .

En pratique ces racines sont installées depuis longtemps sur les logiciels. Et la plupart les logiciels permettent d'en ajouter de nouvelles.