Maintenant que nous connaissons le processus de boot, si on examinait ce processus d'un point de vue de la sécurité !

Lorsqu'on parle de sécurité, il faut d'abord savoir dans quel cas on se positionne et de quoi on cherche à se prémunir. Ici, je considère que le système lui-même est sécurisé. Je suppose que l'attaquant est devant la machine et cherche un accès root.

On considère que chaque élément est sécurisé pour ce qui est de ses propres fonctionnalités, ce qui veut dire que si le bootloader est protégé par mot de passe, il n'y a pas de faille dans le bootloader lui-même permettant d'outrepasser ce mot de passe. Nous nous attacherons donc à chercher ce qui peut être détourné dans le flux d'exécution en entrée et en sortie de chaque élément.

Je vais commencer par la fin, du plus facile au plus difficile.

rc

Rc est lancé par init et ne prend ses paramètres que de init. Ceux-ci sont fixés en dur dans /etc/inittab. Son démarrage ne peut donc être détourné que d'une façon : par modification du contenu du disque. GoTo partition /

Parmi ces paramètres il y a le paramètre 1 qui lance rc dans le runlevel 1, ce qui dans la plupart des cas se termine par un sulogin. Ouf on est protégé par le mot de passe root.

Mais vérifiez bien, dans certains cas il se termine par un simple shell et donc réussir à passer un tel paramètre permettrait à l'attaquant un accès root à votre machine.

Pour passer 1 en paramètre GoTo init

init

Init est lancé par le noyau après lecture de la racine. Il lit sa configuration dans /etc/inittab. Il peut donc être détourné par modification du disque : GoTo partition /

Parmi les paramètres qu'on peut lui passer il y a 1 et S, 1 renvoie au problème ci-dessus et S lance lui-même sulogin, donc même vérification. Ces paramètres viennent du noyau : GoTo noyau

Init est un binaire choisi par le noyau, or il est possible de dire au noyau de changer d'init à travers le bon paramètre. Par exemple, je peux ajouter init=/bin/sh aux paramètres du noyau pour qu'init ne soit jamais lancé qu'un shell apparaisse à sa place. Ça y est je suis root ! C'est d'ailleurs la technique pour changer de mot de passe root lorsque vous l'avez perdu.

Pour changer d'init GoTo noyau.

Init peut aussi être lancé par initrd, il souffre dans ce cas exactement des mêmes problèmes que lorsqu'il est lancé par le noyau : GoTo initrd.

Note upstart, initrdng... :
Il se peut (et ca va être de plus en plus courant) qu'init ou rc soit remplacé par autre chose, type upstart. Dans ce cas seul les noms des paramètres et le format des fichiers change. Mais les impacts sont exactement les mêmes.

Initrd

Initrd prend ses paramètres de la ligne de commande du noyau, mais généralement (il y a plein d'initrd différents) ils sont passés tels quels à init.

D'autre part initrd peut être chargé par 2 moyens, j'ai décrit le bootloader comme un moyen mais le noyau peut aussi charger lui-même l'initrd si on lui demande (avec le paramètre initrd=). On peut donc détourner son chargement par plusieurs moyens : GoTo noyau, GoTo bootloader.

Il est aussi possible de modifier directement l'initrd, par exemple lors d'une réinstallation distante. Celui-ci contenant tout ce qu'on veut, modifier son contenu permet de lancer n'importe que processus ... GoTo partition /boot

Noyau

Le noyau en lui-même ne vous rend pas root mais rien ne vous empêche d'y faire une modification pour qu'il vous fasse root une fois le système chargé.

Le noyau est chargé depuis la partition /boot donc une modification de cette partition et c'est gagné : GoTo partition /boot

Le noyau prend ses paramètres du bootloader, parmi ceux-ci de nombreux paramètres permettent de détourner le système : root= init= initrd= et surement bien d'autres. GoTo bootloader

Partition /

Jusque là, nous n'avons évoqué que les risques mais pas encore de faille. C'est parce qu'aucune interférence de l'utilisateur n'a été possible, tout est automatisé. Mais ça va changer.

Lors du montage de la racine, il y a une interférence possible : le disque contenant / peut avoir été modifié, voire remplacé, pour modifier /etc/inittab, /sbin/init, /etc/init.d/rc ou toute autre chose.

Pour éviter ce problème, il y a deux possibilités :

• mettre un cadenas sur la machine pour garantir l'intégrité physique du disque
• chiffrer le disque

Dans le premier cas, le problème est remonté aux autres couches pour garantir l'intégrité logique et éviter qu'on réussisse à booter sur un autre OS pour modifier le disque. GoTo bootloader.

Dans le deuxième cas, le chiffrement (par exemple avec luks ou truecrypt) doit être assuré par une clé.

• si cette clé est sur la machine et son mot de passe aussi : elle est dans un élément de boot (initrd, partition de boot ...) on reporte le problème GoTo partition /boot
• si cette clé ou son mot de passe n'est pas sur la machine (carte à puce, mot de passe, clé usb ...) alors il y a besoin d'un personne présente à chaque boot ...
• le chiffrement peut aussi être assuré par une puce (TPM) qui ne quitte pas la machine, auquel cas, on garanti que le disque ne quittera pas la machine pour être lu ou modifié (mais pas de garantie contre le formatage), par contre il peut être lu sur place par un autre OS.

Dans tous les cas, seul le démarrage post-noyau est préservé, pour le reste GoTo bootloader.

bootloader

Le bootloader est la source de tous les maux. C'est en effet par lui que l'utilisateur a tout loisir de modifier des paramètres de démarrage.

Le bootloader passe ses paramètres au noyau qui les passe à l'initrd qui les passe à init. Ces paramètres viennent de la configuration du bootloader mais pour un certain nombre de bootloader ils peuvent être directement demandés à l'utilisateur. Dans ce cas il y a moyen d'interdire cette modification à travers un mot de passe. Par exemple grub.

Le bootloader charge sa configuration puis choisit et charge le noyau et l'initrd, tout ceci depuis la partition de boot. Dans tous les cas il doit lire une version non chiffrée, ce qui interdit le chiffrement de cette partition.

Pire, le bootloader est incapable de savoir que le disque n'a pas changé. Donc un simple ajout de disque permet de le faire booter sur un noyau/initrd différent.

Vous ne pouvez presque rien y faire: GoTo partition /boot.

Bon en supposant qu'il n'y a pas de problème, le bootloader est chargé par le bios, il peut donc être détourné : GoTo Bios.

Partition /boot

J'inclue dans la définition de la partition de boot tout ce qui contient la configuration du bootloader, le bootloader lui-même, le noyau et l'initrd, même si ils peuvent être physiquement à des endroits différents. Protéger la partition de boot est très complexe, car tout doit être accessible en clair depuis des outils ayant des fonctionnalités très restreintes.

Les possibilités sont :

• sceau physique sur la machine
• TPM

Mettre un gros cadenas sur la machine permet d'éviter une lecture ou une modification de /boot. Mais il on ne se prémunit pas d'une personne un peu patiente avec un accès complet à la machine.

La dernière solution, complexe à mettre en place et sans garantie absolue est d'utiliser une puce TPM qui va vérifier (mesurer) le bootloader à chaque étape de son chargement, puis vérifier chaque élément que le bootloader charge avant de lancer le noyau.

Bios

Le bios s'exécute tout seul depuis lui-même, il se charge puis lis ses paramètres. Parmi ces paramètres il y a la séquence de boot, qui peut elle-même être modifiée par l'utilisateur.

Il est donc possible, voire facile de dire au bios de booter sur une clé USB et de prendre le contrôle du disque et donc de la machine. Pour éviter ce cas de figure il est possible de mettre un mot de passe au bios. Ainsi on est sûr de booter sur le bon disque, mais seulement s'il y a un cadenas sur la machine puisque le bios ne vérifie pas que le disque n'a pas été remplacé.

GoTo Matériel.

Matériel

Il est possible de changer le bios lui-même. Et ce de plusieurs façons. Si c'est un flash, il est possible de le remplacer logiciellement, si c'est une rom il est possible de la remplacer matériellement.

Et enfin le plus simple pour remplacer le bios est de remplacer la carte mère. Hop ni vu ni connu ...

Pour se protéger de cela ? Le cadenas ... ou la puce TPM, dont la mise en place est toujours très complexe et non garantie.

Conclusion

Résumons-nous car cet article commence à être un peu long. Différencions les cas dont on veut se protéger.

Accès réseau

Si l'attaquant n'a accès à la machine que par le réseau, on est tranquille pour ce qui est de la séquence de boot : No problemo.

Accès KVM

Si l'attaquant n'a accès à la machine que par KVM (pas de possibilité de toucher aux périphériques). Mettre un mot de passe sur le bootloader, le bios et vérifier que le mode rescue demande le mot de passe root devrait suffire. En effet les seul moyen d'attaque sont les paramètres de lancement du système.

N'oubliez pas que le simple accès KVM permet des choses comme le reboot via les magic keys

Accès cadenassé

Si on suppose que l'attaquant peut apporter un CD ou une clé usb sur le système, paramétrer le bios pour booter sur un disque et y mettre un mot de passe est un moyen simple à mettre en place pour éviter le boot sur un autre système.

Mais attention, il ne faut pas que l'utilisateur puisse ouvrir la machine, il pourrait réinitialiser le bios.

Accès au disque sans droit de boot

A partir du moment où l'attaquant a accès au disque c'est presque foutu. Si l'attaquant n'est pas une personne autorisée à booter la machine, il est possible de chiffrer le disque avec une clé qui ne se trouve pas sur le disque. Il faudra alors la rentrer à chaque démarrage. L'attaquant ne disposant pas de cette clé, il me pourra ni lire ni modifier les données où le système. Mais c'est déjà une solution assez contraignante.

D'autant plus que pour être complète cette solution doit garantir le noyau et l'éventuel initrd sur lequel on boote et donc vérifier soi même à chaque boot qu'on utilise une partition de boot non modifiée.

On en arrive au dernier cas ...

Accès complet

Lorsque l'attaquant a un accès complet à la machine, il n'existe qu'un moyen de se protéger (et encore) : la puce TPM.

Elle permet de :

• protéger le bios d'un changement
• protéger le bootloader d'un changement
• protéger le noyau d'un changement
• protéger le contenu du disque d'un changement

Mais tout cela est compliqué et nécessiterait un autre article que je ne suis pas encore prêt à faire, je n'ai même pas de puce TPM chez moi.

PS : Notez une dernière chose que je n'ai pas abordé, le chiffrement des données. Le chiffrement du disque contenant les données (/home et /srv selon vos besoins) devient obligatoire dès qu'on prévoit qu'il y aura un accès physique. Il doit de préférence se faire avec un moyen propre à l'utilisateur (mot de passe / clé / carte à puce ...) pour éviter les attaques à travers le boot de l'OS.

PPS : Considérez qu'a partir du moment où quelqu'un a un accès physique à votre machine c'est mort.

PPPS : Sauf si votre machine est une carte à puce.

PPPPS : Et encore ...

Bon courage !

Je ne me souviens pas avoir fait un article complet sur le processus de boot. Il y en avait un partiel ici. En voici un !

BIOS

Le bios est le premier élément à être lancé, si on excepte l'appui sur le bouton ON et quelques autres détails. Celui-ci initialise le processeur ainsi qu'une partie du matériel, comme la carte vidéo ou le clavier.

Le bios est constitué d'une mémoire (rom ou flash) placée sur la carte mère.

Notez que quasiment tous les bios étant maintenant des flash il est possible de les mettre à jour, voire de les remplacer. Et justement un projet existe pour remplacer les bios propriétaires par des bios libres (comme Max): coreboot de son ancien nom linuxbios.

Le bios est configuré pour choisir un périphérique sur lequel booter. En général c'est le premier disque dur, mais cela peut aussi être une clé usb ou un lecteur disquette. Il est même possible de choisir au moment du boot.

Sur le périphérique en question, et à l'exception du lecteur CD qui a son protocole (el torito), le bios charge le premier secteur (512 octets), le met en RAM, et le lance.

Notez que le "BIOS" est spécifique aux PC, d'autres architectures ont des firmware EFI (Apple) ou des OpenBoot (Sun).

Bootloader

Dans ce premier secteur se trouve le bootloader (grub, lilo, silo, syslinux, mbr dos ...).

Le bootloader est découpé en plusieurs morceaux à cause de la limite des 512 octets. Sa première activité est de réussir à se charger complètement.

Celui de windows est assez simpliste, mais sous linux on en trouve avec plein de fonctionnalités sympa.

Une fois qu'il est prêt, il lit sa configuration puis choisit un périphérique et une partition où lire le noyau et éventuellement un initrd. Et enfin il passe la main au noyau en lui donnant quelques paramètres.

Noyau

Le noyau est déjà chargé, il n'a "presque" plus rien à faire. Si ce n'est tout initialiser : les interruptions, le mode du processeur, les périphériques ...

Une fois qu'il a fini (ou même un peu avant) il monte la racine (/) à partir de de qui lui a été spécifié en ligne de commande.

Et enfin il lance init en lui passant quelques paramètres provenant de sa propre ligne de commande.

Si un initrd est chargé, il l'utilise comme racine et prend l'init s'y trouvant. Dans ce cas il ne cherche pas à monter la racine. Sinon GoTo init.

Initrd

Initrd est un intermédiaire qui a été rajouté au processus de boot pour permettre le chargement dynamique de driver ainsi que la configurations de certain éléments comme le réseau ou le NFS.

Initrd est un ancien nom. En pratique, c'est maintenant un initramfs qui est chargé (c'est la même chose mais en mieux, le premier est un block device et le second une archive) avant le montage de la racine. Celui-ci est monté à la racine. Son boulot, rendre la vraie racine accessible. NFS, driver manquant, LVM, toutes les raisons sont bonnes pour utiliser un initrd.

Et enfin celui-ci charge le vrai init pour l'étape suivante.

Init

Init est cette fois un vrai processus unix lancé par le noyau, et comme c'est le premier il a pour pid 1. Il prend sa configuration dans /etc/inittab. Dans sa configuration il y a quelques processus à lancer et à surveiller, il s'agit essentiellement des terminaux locaux.

Mais surtout il lance /etc/init.d/rc en lui passant en paramètre le runlevel dans lequel on est sensé fonctionner.

rc

rc est un simple script qui a pour pour seul objectif de lancer les différents démons qu'on trouve dans /etc/rcX.d où X est un runlevel

Et voila, à partir de là on peut considérer que le système est lancé.

Notez que sous certains systèmes comme ubuntu on trouve des outils comme upstart qui remplacent à la fois init et rc pour faire à peu près la même chose.

Maintenant qu'on connaît Internet, faisons le voyage du petit paquet.

Prélude

Un paquet n'apparait pas subitement du néant, il vient d'une information. Prenons par exemple un concert de Johnny transmis en streaming. L'information est le son, lui-même codé sous une certaine forme, nous avons par exemple le PCM, le MP3 etc. Pour ceux que ca intéresse, vous pouvez étudier les codecs ou déjà les transformées de Fourier. Jusque là ce que sont que des maths et de la physique.

Une fois ces données devenues des nombres, on les code comme des suites d'octets (8 bits, mais c'est historique, pourquoi pas 12 bits ou 18 bits ou même 7 ? mystère), on en fait des groupes de disons 1460 (totalement au hasard) qu'on met dans un paquet.

Ensuite le système ajoute des informations à ce paquet, par exemple un numéro d'ordre, la taille, l'adresse de l'émetteur, ou même des trucs qui ne servent à rien. L'information la plus importante est l'adresse de destination, en IPv4 elle est de la forme 1.2.3.4

Le premier problème est qu'il faut deviner cette adresse, le deuxième problème est que les barbus qui ont inventé ce protocole n'ont pas pensé qu'un jour les gens pourraient ne pas connaître l'adresse IP de la machine avec qui elles communiquent (qui ne connaît pas le numéro de téléphone des ses amis ?).

C'est pourquoi on a dû inventer un autre système qui permet d'obtenir cette information. Il tourne par dessus IP (ouf). Il s'agit du DNS, un annuaire qui permet non seulement de retrouver les adresses des machines depuis un nom lisible, mais aussi qui permet de déménager sans avoir à avertir tout son carnet d'adresse.

Il est bien dommage que ce système n'ait pas été intégré au protocole internet, ça nous aurait évité bien des soucis, mais bon il faut faire avec.

Ça y est, nous avons un paquet, il est rempli avec nos données et toutes les informations nécessaires, comme une enveloppe remplie et timbrée.

Première sortie

Et ensuite ? On dépose l'enveloppe à la poste la plus proche. La plupart des machines connaissent l'adresse de la poste la plus proche (euh non la passerelle) grâce à DHCP, un système mis en place pour diffuser cette information.

Votre machine connaît l'adresse IP de la passerelle, elle utilise alors la seule carte réseau dont elle dispose pour lui envoyer directement le paquet. Si vous êtes chez vous, la poste c'est probablement votre xxxBox. Si vous êtes dans une entreprise, il s'agit d'un routeur caché quelque part derrière un bureau.

Dans le cas d'une yyyBox, elle ne fait qu'une chose, elle envoie le paquet aussi sec vers le seul routeur qu'elle connait, à travers un DSLAM qui se trouve dans un local appartenant à France Telecom au bout de votre ligne téléphonique.

L'autoroute de l'information

Et c'est parti ! Chaque routeur est en fait un centre de tri, il dispose d'un table contenant toutes les adresses du monde (ou presque :-). En effet il est lui-même connecté à d'autres routeurs eux-même connectés à d'autres routeurs etc. Donc il prend l'enveloppe, lit d'adresse et va regarder dans sa table à quel routeur il doit envoyer le paquet. Et hop c'est reparti.

Ainsi mon paquet parti de chez messire Tartempion va passer entre les mains du routeur de son FAI, puis de celui d'un ami de son FAI, puis d'un transitaire qui fait payer cet ami, puis d'un autre routeur ami de mon FAI, puis d'un routeur de mon FAI avant d'arriver chez moi.

Comment ces routeurs peuvent-ils avoir toutes ces informations ? Tout simplement grâce à un protocole nommé BGP. Il permet aux routeurs de s'échanger des messages pour connaître la table de leurs voisins, et donc savoir à qui ils peuvent envoyer des paquets. Les routeurs appartenant souvent à des personnes différentes, le protocole BGP permet d'appliquer une stratégie de décision choisie par le propriétaire. Par exemple "X ne me paie pas bien, essaie d'abord de passer par Y à moins que ce ne soit impossible".

Les propriétaires de ces routeurs s'appellent des AS. Mais un propriétaire donné peut avoir plusieurs routeurs. Ces routeurs communiquent entre eux, mais cette fois sans arrière pensée politique et donc utilisent un protocole différent, comme par exemple OSPF.

L'arrivée

Et enfin le dernier routeur de la chaîne, le facteur va me délivrer le paquet.

Ma machine va ouvrir l'enveloppe et récupérer le contenu du paquet. Elle va aussi tenter de mémoriser quelques informations comme l'adresse de retour, pour au cas où ...

Si ma machine fait tourner un logiciel qui comprend les paquets envoyés par messire Tartempion, alors elle va pouvoir lire le paquet et récupérer les divers nombres qu'il contient, puis hop, mathématiques, physique, Fourier, codecs, on retrouve 1ms de Johnny.

Postlude

Voilà ce qu'on appelle l'autoroute de l'information. Plusieurs choses sont importantes sur cette autoroute.

Tout d'abord il y a généralement un péage qui permet de l'entretenir. C'est votre abonnement à internet. Mais ensuite personne ne vous demande ce que vous transportez, ça peut être du vin ou une lettre d'amour, l'important est uniquement d'arriver à bon port. C'est ce qu'on appelle la neutralité du net. Pas de filtrage, pas de discrimination, peut-être aura-t-on un jour une haute autorité de lute contre les discriminations sur internet !

Ensuite tout le monde doit parler le même format de paquet pour se comprendre. Et ce format n'appartient à personne. Si chacun parlait son propre format, ce ne serait pas internet.

Enfin internet est fait de toutes les machines connectées à internet. Si personne ne se connecte, si personne n'envoie de paquet, internet n'existe pas.

Et l'ipv6 dans tout ca !

Hé bien, c'est justement un autre format de paquet, avec des adresses différentes. C'est donc un autre réseau, on pourrait l'appeler internet 2 ou alternet si ce n'était pas déjà pris. Et c'est pour cette raison qu'IPv6 ne marche pas. Lorsqu'on parle de passer à IPv6, on ne parle pas de mettre à jour un logiciel, mais de se connecter à un nouveau réseau, un autre, différent. Ce sera donc très très long, comme de passer du français à l'espéranto. Comme de passer du téléphone à internet.

Qu'est-ce qu'Internet ? Cette question, dont la réponse parait évidente à beaucoup n'est pas facile à expliquer.

Internet expliqué à ma mère

Et plutôt que d'expliquer ce qu'est Internet, je vais plutôt expliquer comment marche Internet, car c'est son fonctionnement qui le définit.

Internet est un ensemble de réseaux (net) interconnectés (inter) grâce au protocole IP (internet protocol) aussi appelé IPv4. Ce protocole ne fait qu'une seule chose (et le fait bien :-), transférer des informations (mail, télévision ...) sous forme de petits paquet d'un appareil à un autre.

Internet est caractérisé par le fait que tout internet est accessible par tout internet. Si mon téléphone est connecté à internet alors internet est connecté à mon téléphone. S'il peut envoyer un paquet sur internet (par exemple 1s de musique), on peut aussi lui envoyer un paquet depuis internet.

Donc pour que mon appareil soit sur internet il lui faut seulement 2 choses :

• parler le protocole IP
• être connecté à internet

Internet ce n'est que ça. Mais il y a beaucoup d'autres choses à dire sur internet.

Internet expliqué à mon père

Sur internet on trouve énormément de choses. Malheureusement la plupart des gens n'en connaissent qu'une, le web, j'y reviendrai.

Sur internet il on trouve :

• les emails : un email est découpé en petits paquets qui sont envoyés par IP à une autre machine qui va les stocker dans un coin en attendant que l'utilisateur vienne les chercher
• le téléphone : les applications comme skype ou ekiga découpent votre voix en petits paquets et les envoient à un autre appareil sur internet
• le peer to peer : ce sont les applications qui profitent le plus du concept d'internet, tout ce qu'on y trouve y est découpé en petits paquets qui sont transférés à de multiples personnes, ces personnes peuvent alors enregistrer ces paquets et les retransmettre à d'autres personnes, le nombre de personnes connectées en permanence fait que la plupart de ces paquets sont toujours disponibles
• la messagerie instantanée : chaque message est mis dans un paquet et envoyé au destinataire

On y trouve aussi quelques autres service un peu moins visibles :

• les news : un système de diffusion de messages au monde entier
• irc : un système de communication instantané fonctionnant par groupes de discussion
• ssh : un système de prise de contrôle à distance d'appareils
• ... : il y en a des milliers, il m'est impossible de tous les citer ici

Internet expliqué à ma fille

Comme je le disais, sur internet on trouve le web, c'est l'univers le plus connu du grand public. Le web fonctionne grâce à des logiciels comme firefox ou chrome et des serveurs eux aussi connectés à internet. Ce logiciels font plusieurs choses (donc pas toujours forcément bien :-), ils prennent une adresse que vous leur indiquez et vont trouver le serveur correspondant et lui demandent la page web. Celle-ci est renvoyée par le serveur, découpée en petits paquets, comme d'habitude.

Une fois récupérée cette page est affichée par le navigateur. Elle peut contenir énormément de choses, ça peut être la page de google, ça peut être votre page facebook ... il y en a des milliards.

Et comme internet est internet, il suffit d'être connecté à internet pour voir ces pages. Sauf bien sûr s'il y a un système de protection mis en place spécialement pour n'autoriser que l'accès à certaines personnes, comme pour un compte twitter.

Internet expliqué à mon fils

Voila, c'est tout, Internet c'est comme un bar, on y trouve de tout, il y a un groupe qui chante sur scène et pendant ce temps un couple se forme à une table, d'un côté quelqu'un téléphone à sa femme pendant que de l'autre un groupe de discussion se forme.

Internet c'est un bar à l'échelle de la planète. Mais ce n'est qu'un bar. Il ne sert à rien de le fermer, on ne put empêcher aux gens de discuter, par contre il est possible d'écouter le voisin, d'intercepter ses conversations ...

La prochaine fois nous passerons à une version légèrement plus technique.

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.

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.

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.