Chapitre 7 Protection et sécurité

7.1 Protection

Un système d'exploitation digne de ce nom doit comporter des dispositifs et des procédures de protection des objets qu'il permet de manipuler. Les objets à protéger appartiennent à deux grandes catégories : les objets persistants tels que les fichiers, et les objets éphémères créés en mémoire pendant l'exécution d'un processus et destinés à disparaître avec lui. Les objets matériels, tels que périphériques physiques, interfaces réseau, etc., sont assimilés à des objets persistants. La protection consiste à empêcher qu'un utilisateur puisse altérer un fichier qui ne lui appartient pas et dont le propriétaire ne lui en a pas donné l'autorisation, ou encore à empêcher qu'un processus en cours d'exécution ne modifie une zone mémoire attribuée à un autre processus sans l'autorisation de celui-ci, par exemple.

De façon très générale la question de la protection d'un objet informatique se pose dans les termes suivants, inspirés des concepts mis en oeuvre par le système Multics :

Un objet a un propriétaire identifié, généralement l'utilisateur qui l'a créé. Un objet est, sous réserve d'inventaire, soit un fichier, soit un processus, soit des structures de données éphémères créées en mémoire par un processus, mais nous avons vu à la section 5.4 que pour Multics tous ces objets sont en fin de compte des segments ou sont contenus dans des segments de mémoire virtuelle.
Le propriétaire d'un objet peut avoir conféré à lui-même et à d'autres utilisateurs des droits d'accès à cet objet. Les types de droits possibles sont en général les suivants (on peut en imaginer d'autres) :
- droit d'accès en consultation (lecture) ;
- droit d'accès en modification (écriture, destruction, création) ;
- droit d'accès en exécution ; pour un programme exécutable la signification de ce droit est évidente ; pour un répertoire de fichiers ce droit confère à ceux qui le possèdent la faculté d'exécuter une commande ou un programme qui consulte ce répertoire ;
- droit de blocage, par exemple pour un processus en cours d'exécution ou éligible pour l'exécution.
À chaque objet est donc associée une liste de contrôle d'accès (access control list) qui énumère les utilisateurs autorisés et leurs droits.
Avant toute tentative d'accès à un objet par un utilisateur, l'identité de cet utilisateur doit être authentifiée.
Pour qu'un utilisateur ait le droit d'exécuter une action sur un objet, et dans un système informatique cette action est perpétrée par l'entremise d'un processus, il faut en outre que le processus en question possède le pouvoir voulu. Le pouvoir est un attribut d'un processus, il peut prendre des valeurs qui confèrent à ce processus des privilèges plus ou moins étendus. Jusqu'à présent nous n'avons rencontré que deux valeurs possibles de pouvoir : le mode superviseur et le mode utilisateur, mais nous allons voir que certains systèmes ont raffiné la hiérarchie des valeurs de pouvoir.
La valeur du pouvoir d'un processus peut changer au cours de son exécution. Ainsi un processus qui se déroule dans un mode utilisateur peut faire une demande d'entrée-sortie, ce qui nécessite le mode superviseur. Ceci sera résolu, sous Unix par exemple, par le mécanisme de l'appel système, qui transfère le contrôle, pour le compte du processus utilisateur, à une procédure du noyau qui va travailler en mode superviseur.
Nous définirons la notion de domaine de protection dans lequel s'exécute un processus comme l'ensemble des objets auxquels ce processus a accès et des opérations qu'il a le droit d'effectuer sur ces objets. Lorsqu'un processus change de valeur de pouvoir, il change par là même de domaine de protection.

Les dispositifs et procédures de protection du système d'exploitation vont consister à faire respecter les règles qui découlent des droits et pouvoirs énumérés ci-dessus et à empêcher leur violation. La protection au sens où nous allons l'étudier dans ce chapitre ne consiste pas à empêcher les erreurs humaines, les défaillances techniques ou les actes de malveillance qui pourraient faire subir à un objet un sort non désiré, mais seulement à empêcher leur incidence sur les objets en question. Il faut protéger les données et les processus d'un utilisateur contre les processus des autres utilisateurs, protéger le fonctionnement du système contre les processus des utilisateurs et vice-versa, enfin protéger l'un de l'autre les processus d'un même utilisateur.

La qualité des dispositifs et procédures de protection fait la sûreté d'un système d'exploitation. On conçoit notamment aisément que le contrôle des droits et des pouvoirs doive être à l'abri des manipulations d'utilisateurs désireux sans légitimité d'accroître leurs privilèges, ce qui signifie que les procédures de contrôle doivent s'exécuter avec le mode de pouvoir le plus grand et les droits les plus étendus, inaccessibles aux simples utilisateurs. Cette réflexion de simple bon sens suffit à refuser le qualificatif « sûr » à tel système d'exploitation qui comporte un système perfectionné de listes d'accès réalisé... en mode utilisateur, et pour lequel de surcroît l'identification des utilisateurs est facultative.

En effet, il va sans dire, mais disons-le : il ne sert à rien de contrôler les droits et les pouvoirs du propriétaire d'un processus si déjà son identité n'est pas raisonnablement certaine. Les procédures d'identification et d'authentification des utilisateurs sont un préalable à toute stratégie de protection.

7.1.1 Un parangon de protection : Multics

Dans le domaine de la protection, l'approche mise en oeuvre par le système Multics dès les années 1960 fait encore aujourd'hui figure de référence exemplaire. Nous allons la décrire.

De même que les auteurs de Multics avaient accompli une percée conceptuelle considérable et qui reste aujourd'hui à poursuivre en réunissant les objets de mémoire et les fichiers dans un concept unique de segment, ils ont aussi imaginé pour la protection une approche et des concepts originaux et puissants que les systèmes d'aujourd'hui redécouvrent lentement.

Les dispositifs de protection de Multics

Nous décrirons les dispositifs et procédures mis en oeuvre dans Multics pour assurer la protection des objets parce que, bien qu'anciens, ils restent à ce jour de l'an 2002 une réalisation de référence. Cette description doit beaucoup à celles de l'ouvrage collectif de Crocus [15], Systèmes d'exploitation des ordinateurs et du livre de Silberschatz et ses collègues [62] Principes appliqués des systèmes d'exploitation.

La protection sous Multics repose sur une structure dite « en anneaux ». Chaque processus s'exécute dans un anneau, chaque anneau correspond à un niveau de privilèges. Multics offre huit anneaux numérotés de 0 à 7, l'anneau 0 procure les privilèges les plus élevés, l'anneau 7 les moins élevés. L'anneau du processus courant figure dans le mot d'état de programme (PSW, cf. section ??).

Chaque segment (de mémoire volatile ou persistante), pour chaque type d'accès (lecture, écriture, exécution si le segment contient un programme ou un répertoire), appartient à un anneau. Si un processus s'exécute dans un anneau de valeur inférieure ou égale à l'anneau d'exécution d'un segment, par exemple, il peut exécuter le programme contenu dans ce segment, sinon non.

À tout moment un processus peut changer d'anneau, sous le contrôle du système d'exploitation évidemment, et ainsi acquérir de façon temporaire ou définitive des privilèges supérieurs qui lui ouvriront l'accès à de nouveaux segments.

Figure 7.1 : Protection en anneaux sous Multics

Finalement il apparaît que les plus fidèles disciples de l'équipe Multics furent les ingénieurs d'Intel. Depuis le modèle 80286 jusqu'à l'actuel Itanium les processeurs de la ligne principale d'Intel disposent d'une gestion de mémoire virtuelle à adressage segmenté. Aucun système d'exploitation implanté sur ces processeurs, que ce soient ceux de Microsoft ou les Unix libres FreeBSD, NetBSD ou Linux, ne tire parti de ce dispositif pour unifier les gestions de la mémoire virtuelle et de la mémoire persistante (le système de fichiers) ; les premiers sont contraints à la compatibilité avec leurs ancêtres... et les Unix aussi.

Les processeurs Intel disposent d'un système de protection à quatre anneaux, typiquement destinés respectivement au noyau du système pour l'anneau 0, aux fonctions auxiliaires du système pour les anneaux 1 et 2, et aux programmes en mode « utilisateur » pour l'anneau 3. Le VAX disposait aussi d'un tel système à quatre anneaux. Sur les Intel ces possibilités ne sont guère utilisées par les systèmes d'exploitation. Les systèmes conventionnels comme Unix possèdent un système d'anneaux dégradé à seulement deux anneaux (le mode superviseur et le mode utilisateur) et un système de listes d'accès dégradé avec pour chaque fichier des droits d'accès en lecture, en écriture et en exécution pour trois ensembles d'utilisateurs : le propriétaire du fichier, les membres de son groupe, tous les autres utilisateurs. Linux utilise l'anneau 0 comme mode noyau et l'anneau 3 comme mode utilisateur et c'est tout. Ces systèmes plus rudimentaires ont (avaient ?) l'avantage d'être moins lourds.

7.2 Sécurité

7.2.1 Menaces, risques, vulnérabilités

La sécurité des systèmes informatiques (et de façon plus large celle des systèmes d'information) est un vaste problème dont les aspects techniques ne sont qu'une partie. Les aspects juridiques, sociaux, ergonomiques, psychologiques et organisationnels sont aussi importants, mais nous ne les aborderons pas ici. Nous laisserons également de côté les aspects immobiliers de la sécurité, qui ne doivent bien sûr pas être oubliés mais sont loin de notre propos.

Les problèmes techniques actuels de sécurité informatique découlent directement ou indirectement de l'essor des réseaux, qui multiplie la quantité et la gravité des menaces potentielles. Ces menaces entrent dans une des catégories suivantes : atteinte à la disponibilité des systèmes et des données, destruction de données, corruption ou falsification de données, vol ou espionnage de données, usage illicite d'un système ou d'un réseau, usage d'un système compromis pour attaquer d'autres cibles.

Les menaces engendrent des risques : perte de confidentialité de données sensibles, indisponibilité des infrastructures et des données, dommages pour le patrimoine scientifique et la notoriété, coûts humains et financiers. Les risques peuvent se réaliser si les systèmes menacés présentent des vulnérabilités.

7.2.2 Principes de sécurité

La résorption des vulnérabilités repose sur un certain nombre de principes et de méthodes que nous allons énumérer dans la présente section avant de les décrire plus en détail.

Inutile de se préoccuper de sécurité sans avoir défini ce qui était à protéger : en d'autres termes une organisation quelconque désireuse de protéger ses systèmes et ses réseaux doit déterminer son périmètre de sécurité, qui délimite l'intérieur et l'extérieur. Une fois fixé ce périmètre, il faut aussi élaborer une politique de sécurité, en d'autres termes décider ce qui est autorisé et ce qui est interdit. À cette politique viennent bien sûr s'ajouter les lois et les règlements en vigueur, qui s'imposent à tous. Ceci fait, il sera possible de mettre en place les solutions techniques appropriées à la défense du périmètre selon la politique choisie. Mais déjà il est patent que les dispositifs techniques ne pourront pas résoudre tous les problèmes de sécurité.

Les systèmes et les réseaux comportent des données et des programmes que nous considérerons comme des ressources. Certaines ressources sont d'accès public, comme par exemple un serveur WWW, d'autres sont privées pour une personne, comme une boîte à lettres électronique, d'autres sont privées pour un groupe de personnes, comme l'annuaire téléphonique interne d'une entreprise. Ce caractère plus ou moins public d'une ressource doit être traduit dans le système sous forme de droits d'accès, comme nous l'avons vu au début de ce chapitre.

Les personnes qui accèdent à une ressource non publique doivent être identifiées ; leur identité doit être authentifiée ; leurs droits d'accès doivent être vérifiés : à ces trois actions correspond un premier domaine des techniques de sécurité, les méthodes d'authentification, de signature, de vérification de l'intégrité des données objet et d'attribution de droits.

La sécurité des accès par le réseau à une ressource protégée n'est pas suffisamment garantie par la seule identification de leurs auteurs. Sur un réseau local de type Ethernet où la couche de liaison de données fonctionne en diffusion il est possible à un tiers de capter la transmission de données. Si la transmission a lieu à travers l'Internet, les données circulent de façon analogue à une carte postale, c'est-à-dire qu'au moins le facteur et la concierge y ont accès. Dès lors que les données doivent être protégée, il faut faire appel aux techniques d'un second domaine de la sécurité informatique : le chiffrement.

Authentification et chiffrement sont indissociables : chiffrer sans authentifier ne protège pas des usurpations d'identité (l'attaque dite de type man in the middle), authentifier sans chiffrer laisse la porte ouverte au vol de données. Mais ces deux méthodes de sécurité ne suffisent pas, il faut en outre se prémunir contre les intrusions destinées à détruire ou corrompre les données, ou à en rendre l'accès impossible. Les techniques classiques contre ce risque sont l'usage de coupe-feux (firewalls) et le filtrage des communications réseaux, qui permettent de protéger la partie privée d'un réseau dont les stations pourront communiquer avec l'Internet sans en être visibles. Entre le réseau privé et l'Internet les machines publiques seront placées dans une zone démilitarisée (DMZ), où elles hébergeront par exemple le serveur WWW et le relais de messagerie de l'entreprise. Ces machines exposées au feu de l'Internet seront appelées bastions.

Certains auteurs considèrent que ces techniques de sécurité par remparts, ponts-levis et échauguettes sont dignes du Moyen-âge et leur préfèrent les systèmes de détection d'intrusion (IDS), plus subtils. Cela dit, dans un paysage informatique où les micro-ordinateurs prolifèrent sans qu'il soit réaliste de prétendre vérifier la configuration de chacun, le filtrage et le coupe-feu sont encore irremplaçables.

Nous allons examiner un peu plus en détail chacune de ces collections de techniques, en commençant par la cryptographie parce que les techniques de l'authentification en sont dérivées.

7.2.3 Chiffrement

Nous ne saurions tracer ici une histoire complète des codes secrets, pour laquelle le lecteur pourra se reporter au livre de Simon Singh [63] par exemple. Tout ce qui est antérieur à 1970 a un intérêt essentiellement historique, bien que passionnant et riche d'enseignements, comme par exemple le rôle récemment mis en lumière d'Alan Turing dans le déroulement de la Seconde Guerre mondiale, évoqué dans la biographie d'Andrew Hodges [30].

Chiffrement symétrique : DES

De l'époque de Jules César à la fin des années 1970, un grand nombre de systèmes de chiffrement ont été inventés, qui consistaient à faire subir à un texte clair une transformation plus ou moins complexe pour en déduire un texte inintelligible, dit chiffré. La transformation repose sur deux éléments, une fonction mathématique (au sens large) et une clé secrète. Seule une personne connaissant la fonction et possédant la clé peut effectuer la transformation inverse, qui transforme le texte chiffré en texte clair.

La science de l'invention des codes secrets s'appelle la cryptographie. La science, adverse, du déchiffrement de ces codes est la cryptanalyse. Si le cryptanalyste ignore tout de la fonction de chiffrement et de la clé il aura le plus grand mal à déchiffrer, mais un bon code doit résister à la découverte de sa fonction de chiffrement tant que la clé reste secrète.

Une bonne fonction de chiffrement doit éviter de prêter le flanc à la cryptanalyse. Ainsi le code de César, qui reposait sur une simple transposition circulaire des lettres de l'alphabet, est très facile à décoder par l'analyse des fréquences des lettres dès lors que l'on sait dans quelle langue a été écrit le message. Un bon code doit aussi chiffrer de façons différentes deux occurrences successives d'un même texte dans le corps du message pour éviter que la détection d'une répétition ne fournisse des indices au cryptanalyste. La connaissance simultanée d'un texte clair et de sa version chiffrée, comme dans le cas de Champollion et de la pierre de Rosette, est bien sûr une aubaine pour le décodeur, comme l'occurrence de noms propres etc.

L'invention de l'ordinateur a bien sûr donné un essor considérable à la cryptographie et à la cryptanalyse. Ce n'est d'ailleurs pas un hasard si le créateur du modèle théorique de l'ordinateur, Turing, a été aussi pendant la guerre un formidable concepteur de machines à déchiffrer les codes allemands chiffrés par les automates Enigma. Les machines de Turing, appelées « Bombes », étaient fondées sur une réalisation originale du logicien polonais Marian Rejewski. La courbe qui trace le succès des attaques de sous-marins allemands contre les convois transatlantiques qui acheminaient les fournitures américaines à la Grande-Bretagne subit des fluctuations importantes qui correspondent au délai à l'issue duquel l'équipe d'Alan Turing à Bletchley Park parvenait à déchiffrer plus ou moins parfaitement le code allemand après un changement de combinaison des Enigma. Lorsque l'on sait l'importance militaire qu'ont eue ces fournitures, on ne saurait sous-estimer la contribution de Turing à la victoire alliée.

Le premier système de chiffrement informatique normalisé fut créé par un Allemand émigré aux États-Unis en 1934, Horst Feistel. Sa nationalité et son métier de cryptographe lui valurent quelques difficultés avec la National Security Agency (NSA), désireuse avant tout de garder la maîtrise des moyens de chiffrement et de pouvoir percer les codes utilisés par des personnes privées. Finalement il mit ses compétences au service d'IBM, pour qui il développa au début des années 1970 le cryptosystème Lucifer, base du futur Data Encryption Standard (DES).

Le DES repose sur les principes suivants : le texte clair est codé en numération binaire et découpé en blocs de 64 bits. Chaque bloc est découpé en demi-blocs dont les bits subissent des permutations complexes, puis les demi-blocs sont additionnés et soumis à d'autres transformations. L'opération est recommencée seize fois. La fonction de transformation comporte des variations en fonction de la clé, qui est un nombre arbitraire choisi par les utilisateurs du code. Le nombre de valeurs possibles pour la clé détermine le nombre de façons différentes dont un message peut être chiffré. L'émetteur du message secret le chiffre selon l'algorithme DES au moyen de la clé, le destinataire applique la fonction inverse avec la même clé pour le déchiffrer.

La NSA a obtenu que la normalisation du DES en 1976 comporte une limitation de la taille de la clé à 56 bits, ce qui correspond à 10¹⁷ valeurs possibles. Aujourd'hui cette valeur est notoirement trop faible, et l'on utilise le triple DES, avec une longueur de clé de 112 bits.

La nouvelle norme AES utilise des clés de 128, 192 et 256 bits. La mise en concurrence pour AES a été lancée le 2 janvier 1997 et le choix de la solution a eu lieu le 3 octobre 2000. C'est l'algorithme Rijndael développé par Joan Daemen et Vincent Rijmen de l'Université catholique de Leuven qui a été retenu.

La postérité actuelle du DES procure un chiffrement qui peut être considéré comme robuste, à condition que soit résolu le problème crucial de tous les systèmes qui reposent sur une clé secrète utilisée aussi bien pour le chiffrement que pour le déchiffrement : les participants doivent s'échanger des clés de façon secrète, ce qui n'est pas simple.

Diffie, Hellman et l'échange de clés

Depuis des siècles le problème de l'échange des clés était considéré comme un inconvénient naturel du chiffrement. Les ambassades et les états-majors y consacraient des efforts importants, que les espions s'efforçaient de déjouer.

Avec l'utilisation de l'ordinateur et des télétransmissions, et la dématérialisation de l'information qu'ils autorisent, le problème se pose différemment. Dans les années 1970 un chercheur indépendant et excentrique, Whitfield Diffie, réfléchissait au moyen pour deux utilisateurs du réseau ARPANET d'échanger des courriers électroniques chiffrés sans se rencontrer physiquement. En 1974 il donna une conférence sur le sujet au centre de recherche Thomas J. Watson d'IBM à Yorktown Heights (déjà le lieu de travail de Horst Feistel), et là il apprit que Martin Hellman, professeur à l'Université Stanford à Palo Alto, avait déjà donné une conférence sur le même sujet. Aussitôt il prit sa voiture et traversa le continent pour rencontrer Hellman.

Diffie et Hellman cherchaient une méthode pour convenir d'un secret partagé sans le faire circuler entre les participants ; en d'autres termes une fonction mathématique telle que les participants puissent échanger des informations dont eux seuls puissent déduire le secret. Les caractéristiques souhaitées d'une telle fonction sont la relative facilité de calcul dans le sens direct, et la quasi-impossibilité de calculer la fonction réciproque. Ainsi, si s est le secret en clair, F la fonction de chiffrement, c le secret chiffré, D la fonction de déchiffrement, il faut que c=F(s) soit facile à calculer, mais s=D(c) pratiquement impossible à calculer pour tout autre que les participants, au prix de quel stratagème, c'est ce que nous allons voir.

La solution repose sur un chapitre de l'arithmétique très utilisé par les informaticiens, l'arithmétique modulaire, ou l'arithmétique basée sur les classes d'équivalence modulo n.

Considérons l'ensemble des entiers relatifs Z muni de l'addition et de la multiplication. La division entière de a par b que nous avons apprise à l'école primaire y est définie ainsi :

a ÷ b ® a = b × q + r

où q est le quotient et r le reste de la division. Ainsi :

13 ÷ 3 ® 13 = 3 × 4 +1

Intéressons-nous maintenant à tous les nombres qui, divisés par un nombre donné n, par exemple 3, donnent le même reste r. Nous avons déjà trouvé un nombre, 13, pour lequel r=1, donnons-en quelques autres :

1 ÷ 3	®	3 × 0 +1
4 ÷ 3	®	3 × 1 +1
7 ÷ 3	®	3 × 2 +1
10 ÷ 3	®	3 × 3 +1
13 ÷ 3	®	3 × 4 +1
16 ÷ 3	®	3 × 5 +1

On dit que ces nombres constituent une classe d'équivalence, et qu'ils sont tous équivalents à 1 mod3 (prononcer « un modulo trois ») :

4 º 1 mod3

7 º 1 mod3

...

On construit de la même façon une classe des nombres équivalents à 0 mod3, qui contient -6, -3, 0, 3, 6, 9, 12, ..., et une classe des nombres équivalents à 2 mod3, avec -7, -4, -1, 2, 5, 8, 11, ....

On peut définir une addition modulaire, par exemple ici l'addition mod 3 :

4+7 (mod 3 )	=	(4+7) mod3
	=	11 mod3
	=	2 mod3

On démontre (exercice laissé au lecteur) que l'ensemble des classes d'équivalence modulo n muni de cette relation d'équivalence (réflexive, transitive) et de cette addition qui possède les bonnes propriétés (associative, commutative, existence d'un élément neutre 0 modn et d'un symétrique pour chaque élément) possède une structure de groupe appelé le groupe additif Z_n (prononcé « Z modulo n »).

On peut aussi faire des multiplications :

4 × 7 (mod 3 )	=	(4 × 7) mod3
	=	28 mod3
	=	1 mod3

Nous pouvons montrer là aussi que la multiplication modulo 3 possède toutes les bonnes propriétés qui font de notre ensemble de classes d'équivalence un groupe pour la multiplication, mais cela n'est vrai que parce que 3 est premier. En effet si nous essayons avec les classes d'équivalence modulo 12, nous aurons des diviseurs de zéro, ce qui détruit la structure de groupe :

4 × 7 (mod 12 )	=	(4 × 7) mod12
	=	28 mod12
	=	4 mod12

4 × 6 (mod 12 )	=	(4 × 6) mod12
	=	24 mod12
	=	0 mod12

Dans la seconde expression, le produit de 4 et 6 est nul, ce qui est très regrettable. Aussi pourrons-nous bien définir un groupe multiplicatif Z_n^*, qui si n est premier aura les mêmes éléments que le groupe additif Z_n à l'exclusion de 0, mais si n n'est pas premier il faudra en retrancher les classes correspondant aux diviseurs de n et à leurs multiples :

Z₃^*	=	{1, 2}
Z₁₂^*	=	{1, 5, 7, 11}
Z₁₅^*	=	{1, 2, 4, 7, 8, 11, 13, 14}

Dans ce groupe multiplicatif chaque élément a un inverse (sinon ce ne serait pas un groupe) :

5 × 5 mod12	=	25 mod12
	=	1 mod12
7 × 7 mod12	=	49 mod12
	=	1 mod12
11 × 11 mod12	=	121 mod12
	=	1 mod12

7 × 13 mod15	=	91 mod15
	=	1 mod15

On note que les calculs sont faciles mais les résultats un peu imprévisibles : justement, c'est le but que poursuivent nos deux cryptographes. La fonction y=ax n'est pas monotone. L'exponentielle est définie :

5³ mod11	=	125 mod11
	=	4

et si n est premier elle a les mêmes propriétés que dans Z :

(a^x)^y = (a^y)^x = a^{x . y}

Voici maintenant le protocole d'échange de clés de Diffie-Hellman, illustré par un exemple avec de petits nombres pour pouvoir faire les calculs à la main. Martin Hellman en a eu l'inspiration une nuit, mais il est le résultat de leur travail commun, auquel d'ailleurs il faut adjoindre Ralph Merkle. Le protocole repose sur une fonction de la forme K=W^X modP, avec P premier et W < P. Une telle fonction est très facile à calculer, mais la connaissance de K ne permet pas d'en déduire facilement X. Cette fonction est publique, ainsi que les valeurs de W et P. Prenons W=7 et P=11¹.

Anne choisit un nombre qui restera son secret, disons A=3.
Bernard choisit un nombre qui restera son secret, disons B=6.
Anne et Bernard veulent échanger la clé secrète, qui est en fait S=W^B.A modP, mais ils ne la connaissent pas encore, puisque chacun ne connaît que A ou que B, mais pas les deux.
Anne applique à A la fonction à sens unique, soit a le résultat :

a = W^A modP

= 7³ mod11

= 343 mod11

= 2
Bernard applique à B la fonction à sens unique, soit b le résultat :

b = W^B modP

= 7⁶ mod11

= 117 649 mod11

= 4
Anne envoie a à Bernard, et Bernard lui envoie b, comme représenté par la figure 7.2. a et b ne sont pas la clé, ils peuvent être connus de la terre entière sans que le secret d'Anne et de Bernard soit divulgué.

Figure 7.2 : Échange de clés selon Diffie et Hellman

= .9@percent
Anne a reçu b et calcule b^A modP (qui est, soit dit en passant, (W^B)^A modP, soit 7^{B . A} mod11, mais elle ne connaît pas B) : = .15@percent

b^A modP = 4³ mod11

= 64 mod11

= 9
Bernard a reçu a et calcule a^B modP (qui est, soit dit en passant, (W^A)^B modP, soit 7^{A . B} mod11, mais il ne connaît pas A) :

a^B modP = 2⁶ mod11

= 64 mod11

= 9

Anne et Bernard obtiennent à la fin de leurs calculs respectifs le même nombre 9 qui n'a jamais été exposé à la vue des indiscrets : c'est la clé S ! N'est-ce pas miraculeux ? Ils ont juste échangé l'information nécessaire pour calculer la clé, sans divulguer celle-ci.

Supposons qu'Ève veuille épier les conversations d'Anne avec Bernard : elle pourra intercepter l'échange des messages non chiffrés a et b, à partir desquels elle veut calculer S = a^B modP. Elle ignore S et B. L'équation à résoudre pour calculer B consiste à calculer la fonction réciproque de la fonction à sens unique :

W^B = b modP

Si nous étions dans le monde des nombres réels la solution serait triviale :

B =

logb

logW

Mais dans le monde des classes d'équivalence modulo n ce problème dit du logarithme discret n'a pas de solution simple. C'est un sujet de recherche. Le « front » est aujourd'hui à des valeurs de P qui sont des nombres de 450 chiffres binaires. L'algorithme est sûr si P a 512 chiffres binaires.

L'algorithme de Diffie-Hellman est sans doute une découverte majeure, totalement contraire à l'intuition. Il procure à deux acteurs d'un cryptosystème le moyen d'échanger une clé sans la faire circuler sur le réseau. Mais il restait à faire une découverte encore plus stupéfiante, inspirée d'ailleurs par celle que nous venons de décrire : un cryptosystème fondé sur des clés publiées dans des annuaires publics !

Le chiffrement asymétrique : algorithme RSA

La méthode de Diffie et Hellman permet l'échange de clés, mais elle impose une concertation préalable entre les acteurs. Parfois ce n'est pas pratique : si Anne veut envoyer à Bernard un courrier électronique chiffré pendant qu'il est en vacances, elle sera obligée d'attendre son retour pour établir la clé avec lui.

Whitfield Diffie avait eu une autre idée, pour laquelle il n'avait pas trouvé de solution mathématique appropriée : un système où l'on utiliserait une clé pour chiffrer et une autre pour déchiffrer. Ainsi, Bernard proposerait à Anne une clé de chiffrement, avec laquelle elle coderait le message, et Bernard le décoderait avec une clé différente, la clé de déchiffrement. La clé de chiffrement ne permet que de chiffrer, même Anne serait incapable de déchiffrer son propre message avec cette clé, seul Bernard le peut avec sa clé de déchiffrement. Comme la clé de chiffrement ne fonctionne que dans un sens, elle permet de créer des secrets mais pas d'en dévoiler, et elle peut donc être publique, inscrite dans un annuaire ou sur un site WWW. Quiconque veut envoyer un message chiffré à Bernard peut la prendre et l'utiliser.

Il faut juste pouvoir être sûr que personne ne pourra calculer la clé de déchiffrement à partir de la clé de chiffrement. Et là il faut une intuition mathématique décisive.

Si l'idée du chiffrement asymétrique à clés publiques revient à Diffie et Hellman (sans oublier les précurseurs britanniques tenus au secret), la réalisation de cette idée revient à Rivest, Shamir et Adleman, qui ont trouvé une solution mathématique permettant la mise en oeuvre de l'idée et donné son nom à cette solution : RSA, leurs initiales.

Une personne désireuse de communiquer selon cette méthode doit procéder ainsi :

Prendre deux nombres premiers p et q. En cryptographie réelle on choisira de très grands nombres, de 150 chiffres décimaux chacun. Nous allons donner un exemple avec p=3 et q=11.
Calculer n=pq, soit dans notre exemple n=33.
Calculer z=(p-1)(q-1). (Ce nombre est la valeur de la fonction f(n), dite fonction phi d'Euler, et incidemment elle donne la taille du groupe multiplicatif modulo n, Z_n^*). Dans notre exemple z=20.
Prendre un petit entier e, impair et premier avec z, soit e=7. Dans la pratique e sera toujours petit devant n.
Calculer l'inverse de e(mod z ), c'est-à-dire d tel que e . d=1 modz. Les théorèmes de l'arithmétique modulaire nous assurent que dans notre cas d existe et est unique. Dans notre exemple d=3.
La paire P = (e, n) est la clé publique.
La paire S = (d, n) est la clé privée.

Voyons ce que donne notre exemple. La clé publique de Bernard est donc (7, 33). Anne veut lui envoyer un message M, disons le nombre 19. Elle se procure la clé publique de Bernard sur son site WWW et elle procède au chiffrement de son message M pour obtenir le chiffré C comme ceci :

C=P(M) = M^e modn

C=P(19) = 19⁷ mod33 = 13

Pour obtenir le texte clair T Bernard décode avec sa clé secrète ainsi :

T=S(C) = C^d modn

T=S(13) = 13³ mod33 = 19

Miraculeux, non ? En fait c'est très logique :

S(C)	=	C^d modn
	=	(M^e)^d modn
	=	M^e.d modn
	=	M modn

Le dernier résultat, M^e.d = M (mod n ) découle du fait que e et d sont inverses modulo n, il se démontre grâce au petit théorème de Fermat, ce que nous ne ferons pas ici.

À quel type d'attaque est exposé RSA ? Un espion (Ève par exemple) pourra obtenir la clé publique de Bernard P = (e,n), qui a servi à chiffrer M, ainsi que le message chiffré, C. Pour trouver M l'équation à résoudre est :

C = M^e modn

n, C et e étant connus. Encore une fois dans le monde des réels la solution est triviale : M = [e]C. Mais dans le monde modulaire la solution est M = [e]C modn , et il n'y a pas de méthode connue pour la calculer, même pour de petites valeurs de e. Ainsi, trouver la racine cubique modulo n d'un nombre y n'est pas un problème résolu aujourd'hui, et d'ailleurs beaucoup de cryptosystèmes industriels utilisent effectivement e=3.

En fait la seule attaque possible (outre la recherche de failles de réalisation du logiciel) consisterait à trouver p et q par recherche des facteurs de n, ce que l'on appelle la factorisation du nombre n. La factorisation permettrait de calculer z = f(n) = (p-1)(q-1). Le nombre secret d est tel que e.d º 1 modz. d est un nombre du même ordre de grandeur que z, soit un nombre de mille chiffres binaires. Ce calcul serait réalisable, mais le problème est que la factorisation n'est pas un problème résolu, et qu'il est donc impossible en général de calculer p, q et z.

Les réalisations industrielles ont longtemps utilisé, et utilisent parfois encore e=3. De nos jours e=2¹⁶+1 = 65 537 est populaire. Avec un tel choix d est du même ordre de grandeur que n, soit d » 2¹⁰²⁴. L'élévation à une puissance de cet ordre peut être réalisée efficacement par des algorithmes de type « élévation au carré et multiplication » (square and multiply), qui prennent moins d'une seconde dans une carte à puce².

Le lecteur trouvera des explications mathématiques supplémentaires dans l'ouvrage de Cormen, Leiserson et Rivest (le R de RSA) [17] ou dans celui de Menezes, van Oorschot et Vanstone [43], ou encore, de façon plus abordable, dans ceux de Gilles Dubertret[21] d'Albert Ducrocq et André Warusfel [22]. Au demeurant, il est stupéfiant de constater que les découvertes prodigieuses de Diffie, Hellman, Merkle, Rivest, Shamir et Adleman reposent sur des bases mathématiques déjà entièrement établies par Leonhard Euler (1707--1783), sinon par Pierre de Fermat (1601--1665), et que personne n'y avait pensé avant.

7.2.4 Pretty Good Privacy (PGP) et signature

Le système PGP défraya la chronique judiciaire en 1993 lorsque son auteur Philip Zimmerman fut soumis à une enquête sévère du FBI pour le motif d'avoir exporté illégalement des armes de guerre, en l'occurrence pour avoir placé son logiciel en accès libre sur l'Internet. Les autorités policières américaines (et françaises) ont tendance à penser que le chiffrement robuste est un obstacle à leurs investigations parce qu'il leur interdirait de déchiffrer les messages échangés par des criminels ou des ennemis. Aujourd'hui tous les dispositifs cryptographiques les plus puissants sont accessibles facilement par l'Internet et ainsi disponibles pour lesdits criminels, espions, etc. Une législation restrictive ne s'appliquerait par définition qu'aux honnêtes citoyens soucieux de respecter la loi parce que c'est la loi, pas parce que c'est difficile de faire autrement. Une telle législation n'aurait donc pour effet que de mettre les honnêtes gens à la merci des criminels, ce qui ne semble pas l'effet recherché, en principe du moins.

Sachant que de telles législations sont en déclin, même en France, pays qui a fermement tenu l'arrière-garde jusqu'en 1998, voyons le contenu de PGP. En fait, PGP n'apporte aucune révolution, il est plutôt un assemblage ingénieux et pratique des techniques évoquées ci-dessus.

L'idée du chiffrement asymétrique avec un couple clé publique--clé privée semble tellement puissante qu'on ne voit pas de raison pour qu'elle ne supplante pas toutes les autres techniques. En fait un algorithme aussi puissant soit-il ne résout pas tous les problèmes. D'abord les algorithmes de chiffrement asymétriques tel RSA sont très lourds en temps de calcul, et échanger de nombreux messages chiffrés ainsi devient vite un fardeau.

L'attaque par le milieu (Man in the middle)

Ensuite, le meilleur chiffrement du monde ne peut pas empêcher qu'un agent malintentionné, disons Charles, se soit fait passer pour Bernard, ait intercepté les communications d'Anne, et lui ait présenté sa clé publique comme étant celle de Bernard : ainsi Charles pourra facilement déchiffrer les messages d'Anne avec sa propre clé privée, les lire, puis les re-chiffrer avec la vraie clé publique de Bernard et les faire parvenir à ce dernier. Ce type d'attaque, appelé Man in the middle (par le milieu), est difficile à déjouer une fois que Charles a réussi à s'introduire dans le circuit de communication ; elle peut être tentée contre RSA et aussi contre Diffie-Hellman.

En fait nous sommes ramenés au sempiternel problème dont nous nous croyions débarrassés : comment établir une relation de confiance entre Anne et Bernard, comment échanger des clés dignes de foi. Mais nous avons quand même accompli un progrès : cet échange de clés doit être certifié, mais il peut se faire au grand jour puisque les clés sont désormais publiques. Les clés publiques doivent être signées par une autorité supérieure, ce qui donne naissance à le notion d'infrastructure de gestion de clés, ou IGC (PKI en anglais), voir plus loin section 7.2.6.

Pour pallier la lenteur des calculs d'algorithmes à la RSA, Zimmerman eut l'idée de recourir au bon vieux chiffrement à clé partagée ; comme le point faible de ce dernier est l'envoi de la clé, on utilisera RSA pour communiquer une clé de session pour un algorithme à clés symétriques, clé qui servira à chiffrer la suite des communications avec cet algorithme classique. En l'occurrence Zimmerman choisira IDEA, un cousin de DES à clés de 128 bits, créé à Zurich par James L. Massey et Xuejia Lai, et réputé très robuste. Incidemment les systèmes de communication chiffrés tels que SSL (Secure Socket Layer) utilisés pour les transactions par le WWW, la relève de courrier électronique et la connexion conversationnelle à distance par SSH (Secure Shell) fonctionnent de cette façon.

Cette utilisation combinée des méthodes de chiffrement symétrique (DES en l'occurrence) et asymétrique sera la vraie révolution pratique, qui suscitera la colère de la NSA et de ses homologues dans d'autres pays dont la France. Avant que cette possibilité existe, les utilisateurs de cryptosystèmes se mettaient laborieusement d'accord sur une clé, puis ils l'utilisaient pendant longtemps. La NSA disposait sans doute des moyens de casser le chiffrement DES, ce qui lui ouvrait des mois de lecture paisible de messages réputés secrets. Avec la combinaison de DES et RSA, les utilisateurs changent de clé à chaque échange de messages, ce qui complique beaucoup la tâche des « services ».

PGP sera la cible principale de l'ire des services gouvernementaux, non parce qu'il serait un cryptosystème révolutionnaire, mais parce qu'il constitue une trousse à outils facile d'emploi pour l'usage quotidien, avec les outils de chiffrement symétrique et asymétrique, la gestion de « trousseaux de clés » publiques et privées, l'incorporation automatique de ces outils au logiciel de courrier électronique de l'utilisateur, sans oublier les accessoires de signature électronique. Bref, on installe PGP (ou maintenant sa version libre GnuPG) sur son ordinateur personnel et ensuite tous les messages sont chiffrés et déchiffrés sans que l'on ait à s'en préoccuper. Les services semblaient mal supporter cette situation.

Signature

Outre sa fonction de chiffrement, RSA est aussi utilisable de façon très simple pour signer de façon sûre et non répudiable un document : il suffit que l'émetteur (le signataire en l'occurrence) chiffre le document à authentifier avec sa clé privée : le destinataire déchiffrera avec la clé publique de l'émetteur, et si le déchiffrement réussit ce sera une authentification sûre.

En fait, plutôt que de signer en chiffrant de cette façon l'ensemble du message, on en extrait un résumé numérique par un algorithme de condensation, tel MD5 créé par Ron Rivest, ou SHA (Secure Hash Standard FIPS 180-1), que l'on chiffre. Outre une signature non répudiable, ce procédé garantit en pratique l'intégrité du message. Le principe d'une fonction de condensation (ou de hachage) est le suivant : soient M et M' deux messages, et H la fonction :

si M ¹ M', la probabilité que H(M) = H(M') est très voisine de 0 ;
quel que soit M, il est difficile de trouver un M' ¹ M tel que H(M') = H(M).

7.2.5 Usages du chiffrement : IPSec et VPN

Dans les lignes qui précèdent nous avons imaginé le chiffrement de messages individuels, mais ce n'est en aucun cas le seul usage possible de cette technique. On peut imaginer, et de plus en plus c'est ce qui sera réalisé, le chiffrement systématique de toutes les communications en réseau. À cette échelle demander à chaque utilisateur de disposer de son propre logiciel de chiffrement serait inefficace. Le dispositif de chiffrement (matériel ou logiciel) devra être installé au niveau du routeur d'entrée dans une zone de confiance qui pourra être un réseau ou un sous-réseau privé, en gardant à l'esprit que la majorité des attaques viennent de l'intérieur. Les techniques de réseau privé virtuel (VPN) permettent, avec les mêmes outils, d'instaurer un canal chiffré entre deux noeuds quelconques de l'Internet, ces noeuds pouvant eux-mêmes être des routeurs d'entrée de réseaux. IPSec désigne un ensemble de RFCs destinés à incorporer ces techniques (et d'autres, relatives aussi à la sécurité) au protocole IP lui-même, plutôt que d'avoir recours à des solutions externes. IPv6 a été conçu pour comporter d'emblée toutes les spécifications IPSec.

7.2.6 Annuaire électronique et gestion de clés

À ce stade de l'exposé, nous disposons de deux types de cryptosystèmes, l'un symétrique à secret partagé, l'autre asymétrique avec clés publiques et clés privées, le second permettant l'échange du secret partagé nécessaire au premier. Nous avons aussi, sans coût supplémentaire, un système de signature sûre et non répudiable qui garantit en outre l'intégrité des messages reçus. Ce qu'un système technique ne peut fournir à lui seul, c'est l'établissement du circuit de la confiance : comment être sûr que telle clé publique ne m'a pas été fournie par un usurpateur ? PGP fournit à ce problème une solution à l'échelle d'une personne et de son cercle de relations : trousseau de clés publiques et privées conservé sur le disque dur d'un ordinateur personnel. Mais il est patent que PGP ne répond pas, du moins à lui tout seul, à ce problème à l'échelle d'une entreprise, ni a fortiori à celle de l'Internet. Pour ce faire il faut recourir à un système d'annuaire électronique complété par une infrastructure de gestion de clés (IGC, en anglais Public Key Infrastructure, PKI).

L'annuaire électronique est une base de données au format un peu particulier qui rend les services habituels d'un annuaire : répertorier des personnes ou des serveurs selon un schéma hiérarchique, de l'entité la plus englobante (pays) à la plus petite (personne) en passant par plusieurs niveaux (entreprise, département, service...). L'annuaire électronique contient aussi, idéalement, des certificats, qui comprennent notamment les clés publiques des entités enregistrées. Pour attester la véracité de ces certificats, ils sont, toujours idéalement, signés par une ou plusieurs autorités de certification, et éventuellement par le détenteur de la clé lui-même.

Il existe une norme assez généralement acceptée pour la structure hiérarchique de désignation des objets de l'annuaire, héritée de la norme d'annuaire X500 de l'ISO et adaptée de façon simplifiée par l'IETF pour les protocoles de l'Internet, sous le nom LDAP (Lightweight Directory Access Protocol). La syntaxe ne fera peut-être pas l'unanimité, mais elle permet de traiter à peu près tous les cas possibles. Voici le DN (Distinguished Name) de l'objet « Jacques Martin », c'est-à-dire son nom absolu, constitué de RDNs (Relative Distinguished Names) successifs, un peu comme les noms relatifs dans une arborescence de fichiers Unix constituent le chemin absolu d'un fichier ; CN signifie Common Name, OU Organizational Unit, O Organization :

cn=Jacques Martin, ou=Groupe Système, 
ou=Division Informatique, o= Compagnie Dupont

La forme des certificats découle également de la normeX500, et elle obéit à la norme X509.

Qui certifie la signature des autorités de certification ? En bref, qui me garantit que le contenu de l'annuaire n'est pas un artefact créé par un escroc ? La procédure de création de l'IGC et d'enregistrement des entités comportera nécessairement une intervention humaine qui à chaque étape constate l'identité de la personne (physique, morale ou technique) à laquelle est délivré le certificat. Un certificat émis par l'IGC décrit une entité et contient sa clé publique, ainsi que les signatures des autorités qui garantissent le certificat.

Dans un monde idéal (idéal du point de vue de la sécurité informatique, qui n'est certes pas le seul possible), une hiérarchie d'IGC propage une certaine confiance. Chaque personne qui accède à un système d'information est identifiée par l'annuaire et authentifiée par son certificat et sa clé publique, dont le pendant est la clé privée. Chaque serveur est également identifié et authentifié. Les communications entre les deux peuvent être chiffrées. Ceci aurait pour avantage, outre de faire obstacle plus efficacement à la fraude informatique, de permettre aux personnes de posséder un système d'identification électronique unique (single sign on) au lieu d'avoir à connaître des dizaines de mots de passe et autres codes secrets pour leur carte bancaire, leur téléphone mobile, leurs courriers électronique privé et professionnel, la consultation en ligne de leurs comptes bancaires, les différents systèmes informatiques auxquels elles accèdent pour leur vie professionnelle et privée.

7.2.7 Sécurité d'un site en réseau

Découpage et filtrage

Assurer la sécurité de systèmes informatiques abrités sur un site connecté à l'Internet et de ce fait accessible du monde entier est une autre branche de ce domaine dont, en 2002, beaucoup d'organisations ne semblent pas avoir pris l'exacte mesure.

Comme nous l'avons déjà mentionné, il appartient tout d'abord aux responsables du site de déterminer le périmètre qu'ils veulent protéger, ainsi que ce qu'ils veulent permettre et autoriser.

Cet examen aboutit généralement à identifier un certain nombre de services qui doivent être accessibles de l'extérieur par nature, comme un serveur WWW, un relais de courrier électronique, un serveur DNS. Les ordinateurs qui abritent ces services devront être visibles de l'Internet, c'est-à-dire que le DNS doit publier leurs adresses.

Les autres ordinateurs, que ce soient des serveurs internes ou les stations de travail des personnes qui travaillent sur le site, ne doivent pas être visibles, mais il faut néanmoins qu'ils puissent accéder à l'Internet. En d'autres termes, une session TCP initiée de l'intérieur du site depuis un de ces ordinateurs est autorisée, mais une session initiée de l'extérieur vers le même ordinateur est interdite parce que réputée erronée ou hostile (pour un expert en sécurité informatique les deux termes sont synonymes).

De quels moyens et méthodes disposons-nous en 2002 pour mettre en oeuvre une telle politique de sécurité ? Il nous faut pour cela nous rappeler le chapitre 6 consacré aux réseaux, et notamment ce que nous avons dit des informations contenues dans les en-têtes de datagrammes IP et de segments TCP, ainsi que du routage.

Chaque paquet IP qui se présente à un routeur est doté d'une fiche signalétique constituée de ses en-têtes. Les informations principales par rapport au sujet qui nous occupe sont les adresses IP d'origine et de destination et le protocole de transport (TCP ou UDP), figurant dans l'en-tête de datagramme IP, et les numéros de ports³ d'origine et de destination, figurant dans l'en-tête de segment TCP ou de datagramme UDP. La mention dans l'en-tête IP du protocole de transport permet de connaître le format de l'en-tête de transport (TCP ou UDP), et ainsi d'y retouver le numéro de port. Nous avons vu que l'association d'une adresse et d'un port constituait une socket (voir section 6.6.1). Une paire de sockets identifie de façon unique une connexion dans le cas de TCP. Le routeur maintient une table des connexions TCP établies qui lui permet de déterminer si ce paquet appartient à une communication déjà en cours (parce que entre mêmes adresses IP et avec mêmes numéros de ports, par exemple) ou à une nouvelle communication.

Le routage est un grand instrument de sécurité. Il permet de découper un grand réseau en autant de sous-réseaux qu'on le souhaite, et de contrôler le trafic entre ces sous-réseaux. Les sous-réseaux peuvent d'ailleurs être virtuels, pour s'affranchir des contraintes de localisation, ce qui sera de plus en plus le cas avec le développement de l'informatique mobile. Ceci exige des compétences et du travail, parce que ce que nous avons dit du routage montre que c'est tout sauf simple. Mais un tel investissement est indispensable à qui veut disposer d'un réseau sûr.

Forts de cette possibilité, nous pourrons découper le réseau de notre site en un sous-réseau public, qui abritera les serveurs visibles de l'extérieur, et un sous-réseau privé, éventuellement divisé lui-même en sous-réseaux consacrés à tel groupe ou à telle fonction. Chacun de ces sous-réseaux verra son accès et son trafic régis par des règles spéciales.

Les règles d'accès et de trafic appliquées aux réseaux consistent à établir quels sont les type de paquets (en termes de protocole et de numéro de port, en l'état actuel de la technique) autorisés en entrée ou en sortie depuis ou vers tel réseau ou telle adresse particulière. Ainsi un serveur de messagerie pourra recevoir et émettre du trafic SMTP (port 25) mais n'aura aucune raison de recevoir du trafic NNTP (Network News Transfer Protocol). Appliquer ce genre de règles s'appelle du filtrage par port.

Le sous-réseau public (souvent appelé « zone démilitarisée » ou DMZ) devra faire l'objet de mesures de sécurité particulièrement strictes, parce que de par sa fonction il sera exposé à toutes les attaques en provenance de l'Internet. Le principe de base est : tout ce qui n'est pas autorisé est interdit, c'est-à-dire que tout paquet qui n'a pas de justification liée aux fonctions du serveur de destination doit être rejeté.

Figure 7.3 : Réseau avec DMZ et coupe-feu

Il est prudent que les serveurs en zone publique contiennent aussi peu de données que possible, et même idéalement pas du tout, pour éviter qu'elles soient la cible d'attaques. Ceci semble contradictoire avec le rôle même d'un accès à l'Internet, mais cette contradiction peut être résolue en divisant les fonctions. Ainsi pour un serveur de messagerie il est possible d'installer un relais en zone publique qui effectuera toutes les transactions avec le monde extérieur mais transmettra les messages proprement dit à un serveur en zone privée, inaccessible de l'extérieur, ce qui évitera que les messages soient stockés en zone publique en attendant que les destinataires en prennent connaissance. De même un serveur WWW pourra servir de façade pour un serveur de bases de données en zone privée. Ces serveurs en zone publique qui ne servent que de relais sont souvent nommés serveurs mandataires (proxy servers en anglais).

La figure 7.3 représente un tel dispositif, avec un routeur d'entrée qui donne accès à la DMZ et un coupe-feu (firewall), qui est en fait un routeur un peu particulier dont nous détaillerons le rôle ci-dessous, qui donne accès à un réseau privé.

Le relayage entre zone publique et zone privée fonctionne aussi dans l'autre sens : l'utilisateur en zone privée remet son courrier électronique au serveur privé, qui l'envoie au relais en zone publique, qui l'enverra au destinataire. Pour consulter une page sur le WWW, l'utilisateur s'adresse au serveur relais qui émettra la vraie requête vers le monde extérieur. Ici le relayage peut procurer un autre avantage, celui de garder en mémoire cache les pages obtenues pendant un certain temps, pour les fournir au même utilisateur ou à un autre lorsqu'il les redemandera sans avoir à accéder à la source distante (l'analyse statistique des requêtes révèle que dans un contexte donné les gens accèdent souvent aux mêmes pages).

Le filtrage par port permettra la communication entre le proxy et le serveur en zone privée de façon contrôlée. Les routeurs disposent de fonctions de filtrage assez élaborées, permettant de distinguer quels protocoles et quels numéros de ports sont autorisés selon l'origine et la destination, et si telle communication a été initiée depuis un noeud à l'intérieur ou à l'extérieur du réseau.

Une pratique courante consiste à placer à l'entrée du réseau privé un coupe-feu (firewall). Un coupe-feu est un ordinateur qui filtre les communications un peu comme un routeur, d'ailleurs il est possible de configurer un routeur pour lui faire jouer le rôle d'un coupe-feu simple. Le coupe-feu a généralement des possibilités plus étendues, notamment en termes de suivi de connexion et d'analyse des paquets. Plus précisément, un routeur doit décider au coup par coup du sort de chaque paquet individuel, avec très peu de possibilité d'analyse historique, un coupe-feu peut disposer d'informations plus complètes, peut garder des datagrammes en file d'attente jusqu'à reconstituer une séquence plus longue de la communication et en faire une analyse plus complète. Bien sûr ceci a un coût en termes de débit...

Routeur filtrant et coupe-feu, configurés pour repousser certaines attaques en rejetant des paquets appartenant à des connexions suspectes, produisent des fichiers de comptes rendus (logs) qui relatent les incidents. Il est bien sûr indispensable, pour bénéficier de la protection qu'ils sont censés procurer, d'analyser le contenu de ces fichiers et de les confronter avec les avis publiés par les CERT's (Computer Emergency Response Teams) (sur les CERT's voir la section suivante 7.2.8). Ceci suppose des ingénieurs compétents pour ce faire, ce qu'oublient certaines entreprises qui se croient protégées en achetant (fort cher) un coupe-feu clés en mains, configuré avec des filtres pertinents à un instant donné mais périmés quinze jours plus tard, et qui se retrouvent ainsi dotés d'une magnifique ligne Maginot⁴.

7.2.8 Les CERT (Computer Emergency Response Teams)

Organisation des CERT's

Les CERT's (Computer Emergency Response Teams), comme leur nom l'indique, centralisent, vérifient et publient les alertes relatives à la sécurité des ordinateurs, et notamment les annonces de vulnérabilités récemment découvertes. Les alertes peuvent émaner des auteurs du logiciel, ou d'utilisateurs qui ont détecté le problème. Détecter une vulnérabilité ne veut pas dire qu'elle soit exploitée, ni même exploitable, mais le risque existe.

Les vulnérabilités publiées par les CERT's sont relatives à toutes sortes de systèmes ; leur publication constitue une incitation forte pour que les industriels concernés (les producteurs du système ou du logiciel le plus souvent) les corrigent. Certains tentent aussi de ralentir le travail des CERT's, dont ils aimeraient bien qu'ils ne dévoilent pas leurs faiblesses...

Le premier CERT a vu le jour à l'Université Carnegie-Mellon de Pittsburgh à la fin des années 1980. En 2002 la France dispose de trois CERT's : le CERTA pour les besoins des administrations et services publics, le CERT Renater s'adresse aux Universités et centres de recherche, le CERT-IST s'adresse au monde industriel. En fait la coopération entre les CERT's est assez étroite.

La publication des avis des CERT's est une contribution majeure et vitale à la sécurité des systèmes d'information. Simplement le volume est tel que leur dépouillement représente un travail considérable par des personnes compétentes.

Faut-il publier les failles de sécurité ?

Un débat s'est engagé sur le bien fondé de certains avis, et sur la relation qu'il pourrait y avoir entre le nombre d'avis concernant un logiciel ou un système donné et sa qualité intrinsèque. Les détracteurs des logiciels libres ont par exemple mis en exergue le volume très important d'avis des CERT's qui concernaient ceux-ci (par exemple Linux, le serveur WWW Apache, Sendmail, etc.) pour en inférer leur fragilité. Leurs défenseurs ont riposté en expliquant que les avis des CERT's concernaient par définition des failles de sécurité découvertes et donc virtuellement corrigées, alors que l'absence d'avis relatifs à tel système commercial pouvait simplement signifier que son auteur passait sous silence ses défauts de sécurité en profitant de son opacité. Or l'expérience prouve que tout dispositif de sécurité a des failles ; les vrais attaquants ne perdent pas leur temps à faire de la recherche fondamentale sur la factorisation des grands nombres entiers, ils essaient de repérer les failles d'implémentation et ils les exploitent. Face à ce risque la meilleure protection est une capacité de riposte rapide, qui consiste le plus souvent à commencer par désactiver le composant pris en défaut en attendant la correction. La communauté du logiciel libre excelle dans cet exercice, mais avec les logiciels commerciaux les utilisateurs n'ont souvent aucun moyen d'agir sauf à attendre le bon vouloir de leur fournisseur. Dans ce contexte, la publication d'avis des CERT's relatifs à des logiciels commerciaux est très bénéfique parce qu'elle incite les fournisseurs à corriger plus rapidement un défaut dont la notoriété risque de nuire à leur réputation. Mais certains fournisseurs cherchent à obtenir le silence des CERT's en arguant du fait que leurs avis risquent de donner aux pirates des indications précieuses... ce qui est fallacieux parce que les sites WWW des pirates sont de toute façon très bien informés et mis à jour, eux, selon les principes du logiciel libre, ce qui indique où est l'efficacité maximum. L'expérience tend à prouver qu'une faille de sécurité est d'autant plus vite comblée qu'elle est publiée vite et largement. L'accès au code source du logiciel en défaut est bien sûr un atout supplémentaire.

1: Le lecteur attentif remarquera que beaucoup d'auteurs utilisent cet exemple numérique. S'il se donne la peine de quelques essais personnels il constatera qu'il y a une bonne raison à cela : les autres valeurs numériques suffisamment petites donnent des résultats corrects mais peu pédagogiques du fait de coïncidences fâcheuses.
2: Je remercie François Bayen pour ses suggestions qui ont notablement amélioré les exposés cryptographiques de ce chapitre.
3: Rappelons qu'un port dans la terminologie TCP/IP est un numéro conventionnel qui, associé à une adresse IP, identifie une extrémité de connexion.
4: Le lecteur non français peut ignorer le nom de cette ligne de fortifications infranchissable établie par l'armée française dans les années 1930 pour se prémunir d'une invasion allemande, et qui n'avait que le défaut de ne pas être placée à l'endroit où cette invasion s'est produite en 1940.

a	=	W^A modP
	=	7³ mod11
	=	343 mod11
	=	2