Navigation – Plan du site
111 | 2012
Annuaire du Collège de France 2010-2011
Résumé des cours et travaux 111e année
III. Chaires annuelles

Informatique et sciences numériques

Martin Abadi
p. 805-810

Notes de la rédaction

Les vidéos des cours et de certains séminaires sont disponibles sur le site Internet du Collège de France : http://www.college-de-france.fr/site/martin-abadi/course-2010-2011.htm et http://www.college-de-france.fr/site/martin-abadi/seminar-2010-2011.htm. La leçon inaugurale est éditée sous forme imprimée (Fayard/Collège de France, 2011) et numérique (Collège de France, 2013 ; en ligne : http://books.openedition.org/cdf/421). Elle est également disponible sous forme audio et vidéo sur le site Internet du Collège de France : http://www.college-de-france.fr/site/martin-abadi/inaugural-lecture-2011-03-10-18h00.htm

Texte intégral

La sécurité informatique

1Dans son cours de 2007-2008, Gérard Berry a expliqué pourquoi et comment le monde devient numérique. La sécurité devient numérique elle aussi. À l’heure actuelle, des questions de sécurité informatique se posent partout, non seulement dans le renseignement militaire mais également dans la finance, le commerce, la gestion de données médicales, la vie sociale et bien d’autres domaines. La sécurité informatique est d’autant plus délicate que nous utilisons des systèmes relativement ouverts, malléables et hétérogènes, comme le Web. Les motivations des attaques et les procédés qu’elles mettent en œuvre y sont variés et parfois surprenants. Malgré cette diversité, les mêmes principes et les mêmes méthodes s’appliquent dans de nombreux contextes.

2Lors de ce cycle d’enseignement au Collège de France, nous nous sommes penchés sur les modèles généraux de sécurité, sur les techniques et mécanismes de protection correspondants et sur leurs garanties, leurs limitations et leurs failles. Le cours a traité en particulier des contrôles d’accès et de la fiabilité du logiciel. Plus tard, il a traité aussi des protocoles cryptographiques pour communiquer sur les réseaux comme Internet. J’espère avoir donné ainsi une idée des buts de la sécurité informatique, de ses outils fondamentaux et de ses difficultés. Dans le séminaire, les orateurs, qui sont parmi les plus grands chercheurs du domaine, ont comblé certaines des lacunes du cours et présenté d’autres perspectives sur le sujet.

Cours

3La sécurité informatique est un vaste sujet difficile à isoler d’autres parties de l’informatique (notamment des langages de programmation, du génie logiciel, des bases de données, des systèmes d’exploitation et des réseaux). Le cours en a pourtant décrit un grand nombre d’aspects pratiques et théoriques, parfois de manière assez détaillée, parfois de manière plus schématique ou allusive. Certains des concepts et techniques présentés dans le cours sont assez anciens et restent fondamentaux. D’autres sont le fruit de travaux de recherche récents. Mon but n’était certes pas de faire un tour d’horizon complet du monde de la recherche, mais plutôt de signaler quelques pistes et quelques résultats.

4Pour entamer l’étude de la sécurité informatique, la leçon inaugurale est partie d’un exemple de la vie courante : le problème du spam. Cet exemple nous a menés vers des thèmes plus larges, comme la correction des programmes et les techniques de chiffrement, qui intéressent l’informatique à long terme. Nous avons aussi aperçu d’autres dimensions économiques et sociales de la sécurité. Ensuite, entrant dans le vif du sujet, nous avons expliqué en quoi consiste la sécurité informatique, et si elle ressemble ou non à la sécurité dans d’autres cadres. Nous avons finalement ébauché des approches permettant de décrire et d’analyser des systèmes de communication sécurisée.

5Le reste du cours s’est composé de huit séances. Nous avons consacré les quatre premières aux politiques de sécurité et à leur mise en œuvre par des mécanismes comme les contrôles d’accès. Dans les quatre dernières séances, nous nous sommes surtout intéressés à la sécurité des communications et aux protocoles cryptographiques.

Les politiques de sécurité et leur mise en œuvre

6Les politiques de sécurité requièrent généralement des propriétés de secret, d’intégrité et de disponibilité. Par exemple, dans un système où un acteur, Alice, envoie des données à un autre acteur, Bob, l’« intégrité » exprime que les données que Bob reçoit sont bien celles qu’Alice lui a envoyées, le « secret » que seul Bob reçoit ces données, et la « disponibilité » que les données parviennent bien à Bob. Ces notions sont discutées assez longuement dans le texte de la leçon inaugurale.

7Les contrôles d’accès constituent un des principaux mécanismes pour mettre en œuvre diverses politiques de sécurité dans la plupart des systèmes informatiques, et parfois ils fournissent aussi un cadre pour décrire ces politiques. Par exemple, la politique de sécurité d’un gouvernement pourrait requérir que seules certaines personnes doivent connaître le budget des services de renseignement de ce gouvernement. Une mise en œuvre de cette politique de sécurité peut se fonder sur des contrôles d’accès qui vérifient que seules ces personnes peuvent lire le contenu des fichiers qui contiennent le budget en question. Évidemment, il y a un écart entre la politique de sécurité et sa mise en œuvre concrète, et des erreurs sont possibles.

8Typiquement, chaque composante d’un système a une vision locale de ce qui se passe dans ce système. L’usager qui lance un programme ne comprend peut-être pas que cette action va conduire à une certaine requête en aval ; et chaque application et chaque service logiciel ne connaît peut-être que partiellement le contexte, les causes et les conséquences des requêtes qu’il doit traiter. En outre, un système de contrôle d’accès ne concerne que certains objets (par exemple, des fichiers), et peut difficilement empêcher des fuites d’information qui ne passeraient pas par ces objets. Les contrôles de flots d’information pourraient résoudre ces problèmes. Souvent, ils sont présentés comme une alternative aux contrôles d’accès. Pourtant, la réalisation des contrôles de flots d’information peut s’appuyer sur des contrôles d’accès. Elle peut aussi s’appuyer sur une analyse fine de l’exécution des programmes et porter non seulement sur les accès à des objets comme les fichiers, mais aussi sur les effets, directs et indirects, de chaque instruction des programmes.

9Dans le cadre d’un cours d’informatique, il n’est sans doute pas trop surprenant que nous nous intéressions aux programmes, ni que ceux-ci soient omniprésents. Des programmes apparaissent dans chacun des éléments des contrôles d’accès :

– Les programmes font des requêtes, parfois assez indépendamment des activités immédiates de chaque usager. Par exemple, un programme qui, périodiquement, sauvegarde des copies de tous les fichiers d’un système doit demander à lire tous ces fichiers. Nous pouvons donc voir les programmes comme des « principaux » (c’est-à-dire comme des agents qui font des requêtes) et contrôler leurs accès aux fichiers.

– Les programmes sont aussi l’objet de requêtes. Le plus souvent, les requêtes demandent de lancer ces programmes, mais parfois il s’agit de lire ou de modifier un programme.

– Généralement des programmes réalisent les opérations concernées par les contrôles d’accès, par exemple des opérations pour modifier des fichiers.

– Enfin, un « moniteur de références » (une composante des systèmes de sécurité qui décide quelles requêtes accorder) peut être un programme, un ensemble de programmes, ou encore des fragments de logiciel entrelacés dans d’autres programmes. Souvent, le moniteur de références fonde ses décisions sur des politiques formulées séparément, dans un format spécial qui vise à rendre plus aisé d’exprimer ces politiques de manière claire, uniforme, correcte et cohérente. Bien que ce format soit généralement rudimentaire et ad hoc, il s’agit parfois d’un langage de programmation riche basé sur une logique formelle.

10Les programmes jouent un rôle également central dans le contrôle des flots d’information.

11S’il est possible de considérer chaque programme comme un principal, ce programme est pourtant lié à d’autres principaux. D’une part, le programme est lié à d’autres programmes avec lesquels il interagit. D’autre part, il est lié à des usagers : les usagers qui l’ont écrit ou l’ont modifié, ceux qui l’ont fourni ou installé, ou encore ceux qui le lancent. Si on fait confiance au programme et si on lui accorde certains droits, c’est souvent en partie parce que l’on fait confiance à certains de ces usagers, mais les politiques qui établissent ce transfert de confiance sont variées et souvent implicites dans l’état d’un système. Plus généralement, un programme pourrait avoir les droits de son appeleur, qu’il s’agisse d’un autre programme ou d’un usager ; ou d’un usager tenu pour responsable, peut-être son auteur ; d’autres droits, peut-être à cause de propriétés intrinsèques au programme établies par des analyses statiques ou par des preuves logiques ; ou enfin une combinaison de tous ces droits. Toutes ces possibilités s’avèrent utiles et se manifestent dans divers systèmes, mais elles posent des questions délicates qui sont loin d’être résolues complètement.

12Compte tenu de l’importance des programmes, nous devons nous inquiéter de leur correction et de leur fiabilité. Nous pourrions aussi craindre leur complexité. En outre, nous voudrions que les programmes soient protégés, au repos, dans les systèmes de fichiers, et surtout quand ils s’exécutent. Nous voudrions aussi qu’ils soient contraints à communiquer seulement sur les interfaces prévues, pour que les dispositifs de sécurité ne puissent pas être contournés. Typiquement, ces tâches de protection et d’isolation sont confiées au matériel des ordinateurs et aux systèmes d’exploitation, avec des instruments comme les espaces d’adressage ; ce sont des instruments puissants et efficaces mais de très bas niveau. Parfois, les langages de programmation et leurs environnements d’exécution permettent la mise en œuvre de solutions plus fines et plus agiles.

La sécurité des communications

13Dans certains systèmes, une autorité centrale assure la sécurité des composantes de base, puis met des outils fiables à la disposition des autres applications et services logiciels. Par exemple, dans un ordinateur classique, un système d’exploitation peut protéger ses propres données des autres programmes et servir d’intermédiaire pour permettre à ces autres programmes de communiquer entre eux de manière sûre. Dans ce but, le système d’exploitation réalise certains contrôles essentiels (notamment des contrôles d’accès). Par contre, une telle autorité centrale n’existe pas – ou elle intervient moins fréquemment – sur des réseaux comme Internet.

14En dehors de la portée d’une autorité centrale, nous pouvons avoir recours à des méthodes cryptographiques. La cryptographie fournit des techniques pour garantir le secret (notamment divers algorithmes de chiffrement) et aussi l’intégrité (notamment des « signatures digitales »). Dans une moindre mesure, la cryptographie peut parfois contribuer à la disponibilité. Elle permet de sauvegarder des données au repos, et elle constitue surtout un outil primordial pour garantir la sécurité des communications sur les réseaux. Dans le cours, nous avons donc présenté son vocabulaire et esquissé quelques-uns de ses principes et de ses techniques ; elle pourrait bien entendu faire l’objet de plusieurs années d’enseignement.

15En général, un protocole est un ensemble de règles pour l’échange de messages. Ces règles sont essentielles au fonctionnement des réseaux. Elles décrivent le format des messages et leur ordre. Elles peuvent par exemple dire que si un acteur, sur un réseau, envoie un message avec la question « qui-vive ? » exprimée sous forme binaire à un autre acteur, celui-ci répondra avec son nom et son mot de passe.

16Pour réfléchir à quelques aspects fondamentaux de la sécurité dans les réseaux sans pourtant trop m’attarder sur tous les détails de leurs protocoles, j’ai décidé de prendre comme point de départ un célèbre cartoon paru dans le New Yorker en 1993. Dans ce cartoon, un chien expliquait à un autre : « Sur Internet, personne ne sait que vous êtes un chien ». Ce cartoon suggérait qu’il est impossible de connaître l’identité et les caractéristiques personnelles des acteurs sur Internet. En effet, la notion d’identité sur Internet est assez faible. Souvent, nous y avons peu de garanties d’authenticité, et par conséquent peu de garanties de confidentialité et de disponibilité. Pourtant, Internet et les façons dont nous nous en servons ont évolué depuis 1993. D’une part, les garanties d’authenticité se sont renforcées, grâce notamment à l’utilisation de certificats pour les sites Web et autres méthodes cryptographiques. D’autre part, pour des raisons publicitaires parfois, on a développé des techniques et des astuces pour tenter d’identifier les usagers ou pour déceler les caractéristiques et les goûts de ceux-ci, souvent à leur insu. Même si ces procédés restent assez approximatifs, ils inquiètent les usagers et posent un danger pour leurs données privées, qui sont de plus en plus abondantes sur les sites de commerce électronique, sur les réseaux sociaux comme Facebook et ailleurs. Cet état de choses est peu satisfaisant. Un monde où nous pourrions choisir entre authenticité parfaite et anonymat parfait semblerait bien plus attirant.

17Par protocole de sécurité, nous entendons un protocole qui est censé garantir des propriétés de sécurité, typiquement en utilisant des méthodes cryptographiques. Le protocole SSL en est un exemple bien connu ; il vise à assurer l’intégrité et le secret des données échangées par deux acteurs sur Internet. Dans le cours, nous avons décrit SSL et quelques autres protocoles. Certains ont des buts similaires à SSL. D’autres tentent de préserver l’anonymat des acteurs. D’autres encore, plus exotiques, permettent de faire des calculs répartis sans partager les entrées de ces calculs. Par exemple, grâce à un de ces protocoles, deux usagers peuvent comparer leurs coordonnées géographiques et estimer leur distance sans pourtant se révéler mutuellement ces coordonnées.

18La conception des dispositifs de sécurité est généralement délicate. En particulier, les protocoles de sécurité contiennent fréquemment des failles. Il est donc utile de développer des méthodes pour décrire rigoureusement ces protocoles et pour les analyser, comme l’explique le texte de la leçon inaugurale. Certaines de ces méthodes s’appuient sur des outils logiciels puissants, le vérificateur ProVerif, par exemple, dont Bruno Blanchet a fait une démonstration dans le cours.

Séminaire

19Chacune des huit séances du cours proprement dit fut suivie d’une heure de séminaire avec l’intervention d’une personnalité extérieure, souvent en relation directe avec les thèmes du cours mais sur des questions plus spécifiques :

– John Mitchell (Stanford) : « Web Security and Untrusted JavaScript » ;

– Ron Rivest (MIT) : « Security of Voting Systems » ;

– Andrew Myers (Cornell) : « Constructive Security Using Information Flow Control » ;

– Butler Lampson (Microsoft) : « Usable Security Through Isolation »;

– David Pointcheval (CNRS) : « Quelles garanties nous apporte la cryptographie ? » ;

– Adi Shamir (Institut Weizmann) : « How Cryptosystems are Really Broken »;

– Leslie Lamport (Microsoft) : « From Byzantine Generals to Hackers »;

– Véronique Cortier (CNRS) : « Comment prouver la sécurité des protocoles cryptographiques ? ».

20Comme ces titres l’indiquent, la plupart de ces orateurs ont parlé l’anglais. Le site Web du Collège de France contient à la fois des versions originales et des versions françaises de leurs interventions.

Publications

Articles dans des revues

21Abadi M., Harris T. et Moore K.F., « A Model of Dynamic Separation for Transactional Memory », Information and Computation, Vol. 208, No. 10, octobre 2010.

Abadi M. et Plotkin G., « A Model of Cooperative Threads », Logical Methods in Computer Science, Vol. 6, No. 4, octobre 2010.

Abadi M., Birrell A., Harris T. et Isard M., « Semantics of Transactional Memory and Automatic Mutual Exclusion », ACM Transactions on Programming Languages and Systems, vol. 33, n° 1, janvier 2011.

Articles dans les actes de conférences et workshops

22John J.P., Yu F., Xie Y., Krishnamurthy A. et Abadi M., « Heat-seeking Honeypots: Design and Experience », Proceedings of the Twentieth International World Wide Web Conference, mars 2011.

Pitsillidis A., Xie Y., Yu F., Abadi M., Voelker G.M. et Savage S., « How to Tell an Airport from a Home: Techniques and Applications », Proceedings of HotNets-IX: Ninth ACM Workshop on Hot Topics in Networks, octobre 2010.

Birgisson A., McSherry F. et Abadi M., « Position Paper: Differential Privacy with Information Flow Control », Proceedings of ACM SIGPLAN Sixth Workshop on Programming Languages and Analysis for Security, juin 2011.

John J.P., Yu F., Xie Y., Krishnamurthy A. et Abadi M., « deSEO: Combating Search-Result Poisoning », Proceedings of Usenix Security, août 2011.

Haut de page

Pour citer cet article

Référence papier

Cours et travaux du Collège de France. Annuaire 111e année, Collège de France, Paris, avril 2012, p. 805-810. ISBN 978-2-7226-0156-7

Référence électronique

Martin Abadi, « Informatique et sciences numériques », L’annuaire du Collège de France [En ligne], 111 | 2012, mis en ligne le 22 novembre 2013, consulté le 25 février 2018. URL : http://journals.openedition.org/annuaire-cdf/1653

Haut de page

Auteur

Martin Abadi

Professeur associé au Collège de France pour l’année académique 2010-2011

Haut de page

Droits d’auteur

Collège de France

Haut de page