la certification d applications Java Card

Transcription

1 N o d ordre : 2614 THÈSE présentée devant l université de Rennes 1 pour obtenir le grade de : DOCTEUR DE L UNIVERSITÉ DE RENNES 1 Mention INFORMATIQUE par Marc Éluard Équipe d accueil Laboratoire d accueil École Doctorale Composante universitaire LANDE IRISA (Institut de Recherche en Informatique et Systèmes Aléatoires) MATISSE IFSIC (Institut de Formation Supérieure en Informatique et Communication) Titre de la thèse : Analyse de sécurité pour la certification d applications Java Card Soutenue le 10 décembre 2001 devant la commission d examen composée de : Mme. Isabelle ATTALI Rapporteur M. Roberto GIACOBAZZI Rapporteur M. Pierre GIRARD Examinateur M. Thomas JENSEN Directeur de thèse M. Olivier RIDOUX Président M. Jean-Pierre TALPIN Examinateur

2 ii

3 Remerciements Difficile exercice que les remerciements. Comme l aurait si bien dit Murphy dans une de ses lois : s il y a bien une personne qui lira les remerciements, ce sera forcément celle que vous aurez oublié de remercier.. Pour éviter que cette loi ne se vérifie, je tiens à remercier toutes les personnes qui m ont soutenu durant ces années d étude. Ceci fait, je tiens à remercier particulièrement les membres de mon jury. Je commencerai par Thomas Jensen qui m a encadré et soutenu durant ces trois longues années. Je continuerai par Isabelle Attali et Roberto Giacobazzi qui ont accepté d être les rapporteurs de cette thèse et qui ont fait, à cette occasion, un très gros et très bon travail. Viennent ensuite Pierre Girard et Jean-Pierre Talpin qui ont accepté de faire partie des examinateurs. Pour terminer avec le jury, je remercie Olivier Ridoux qui a accepté d en être le président. Merci à l équipe LANDE, passée et présente, pour les diverses discussions que j ai pu avoir avec ses membres. Je citerai Thomas de Grenier de Latour, mon collocataire de bureau, qui a eu le malheur d être là durant la dernière ligne droite. Je remercie aussi Jean-Philippe Pouzol et Thomas Colcombet avec lesquels j ai pu avoir de nombreuses et fructueuses discussions. Je n oublie pas Thomas Jensen, qui a su écouter mes problèmes et m aider à les surmonter. Merci enfin à tous ceux qui ont été là pour que je n oublie pas qu il y avait une vie en dehors de la thèse. Merci à Agnès, à nos deux familles ainsi qu à tous les amis qui ont su être là quand je sortais de mon bureau. Que les personnes qui croyaient apparaître dans cette partie se rassurent elles y sont, en tout cas dans mon esprit... Je concluerai en disant un grand merci à tous ceux dont j ai croisé la route et qui m ont, d une façon ou d une autre, apporté tous ces petits quelques choses qui ont fait que j en suis là aujourd hui.

4 iv

5 v Table des matières Introduction 1 I Contexte de la thèse 3 1 Aperçu des problèmes liés à la sécurité 5 Introduction Définitions Différentes formes d attaques Politique de sécurité multi-niveaux Modèles de sécurité Modèles de confidentialité Contrôle d accès discrétionnaire Contrôle d accès mandataire Contrôle de flux d informations Modèles d intégrité Modèles de disponibilité Conclusion Critères Communs 25 Introduction Cible de l évaluation Exigences fonctionnelles Niveau d assurance de l évaluation Exigences d assurance Cible de sécurité Évaluation d une ST Évaluation d une TOE Profil de protection Conclusion Cartes à puce et Java Card 39 Introduction Cartes à puce Java Java Card Éléments de sécurité disponible dans Java Card

6 vi Conclusion II Langage et sémantique 51 4 Définition du langage 53 Introduction Transformations Représentation Quelques notations Représentation d un Class file Conclusion Sémantique opérationnelle 61 Introduction Modélisation des valeurs dynamiques Valeurs État Fonctions auxiliaires Aspects syntaxiques Aspects dynamiques Sémantique opérationnelle Tests du pare-feu Règles de la sémantique Conclusion III Analyse et vérification de propriétés 83 6 Analyse et mise en équations 85 Introduction Exemple pour les langages orientés objets Domaines abstraits Modification de la représentation d un Class file Modification des valeurs dynamiques Fonctions Modélisation du pare-feu et de la gestion des objets partagés Informations calculées par l analyse Définition des contraintes Contraintes simples Contraintes conditionnelles quantifiées Analyse Fonctions Mise en équations des instructions Modélisation du JCRE Résolution du système de contraintes Construction du système à résoudre

7 vii Résolution par recherche de point fixe Conclusion Vérification de propriétés 115 Introduction Graphe de flot de contrôle Exprimer des propriétés Exemples de propriétés Invariants sur les états Propriétés sur les traces Conclusion Conclusion 125 Bibliographie 127 IV Annexes 137 A API Java Card 139 A.1 Mots clé de Java Card A.2 Packages A.3 Classes A.4 Interfaces B Exemple d applettes Java Card avec partage d objets 143 B.1 Définition du partage B.2 Classe CAlice B.3 Classe CBob C Exemples de transformations de code 153 C.1 Code du programme en Java Card C.1.1 Classe Mere C.1.2 Classe Fille C.1.3 Classe PetiteFille C.2 Code en bytecode Java Card C.2.1 Classe Mere C.2.2 Classe Fille C.2.3 Classe PetiteFille C.3 Code dans notre bytecode C.3.1 Classe Mere C.3.2 Classe Fille C.3.3 Classe PetiteFille C.4 Code du programme sous forme de contraintes C.4.1 Classe Mere C.4.2 Classe Fille C.4.3 Classe PetiteFille

8 viii D Analyse statique et interprétation abstraite 165 Introduction D.1 Rappels et notations D.1.1 Treillis D.1.2 Fonctions D.2 Analyse statique de programmes par interprétation abstraite D.3 Méthodes de résolution de systèmes D.3.1 Point fixe D Calcul classique D Itération chaotique D Algorithme D.3.2 Méthodes symboliques D.4 Application aux langages impératifs Conclusion E Preuve de correction de l analyse vis à vis de la sémantique 185 E.1 Les relations de correction E.1.1 Relation de correction entre états E.1.2 Relation de correction entre propriétaires E.1.3 Relation de correction entre les valeurs E Relations de correction entre les objets E Relation de correction entre les références non définie 188 E Relation de correction entre les valeurs primitives. 189 E.1.4 Relation de correction et Lookup E.1.5 Relation de correction et tests du pare-feu E.2 Correction des instructions F Preuves de la satisfaisabilité du système de contraintes 201 F.1 F Q est monotone F.2 Eval CCQ est monotone F.3 Eval CS est monotone F.4 Eval Val est monotone Résumé 207

9 ix Liste des tableaux 1.1 Exemple de classification MLS des objets Exemple de classification MLS des personnes Exemple de matrice de contrôle d accès A.1 Les mots clés dans Java Card A.2 Liste des packages de Java Card A.3 Les classes disponibles dans Java Card A.4 Les interfaces disponibles dans Java Card D.1 Abstraction de la fonction d addition sur D.2 Exemple d élargissement sur les intervalles

10 x

11 xi Liste des figures 1.1 Attaque par répétition Attaque par mystification Le président et les rapports médicaux Garibaldi et les rapports médicaux Exemple de graphe de protection Exemple de Bell - LaPadula Compilation d un programme Java Card Architecture d une Java Card Schéma de résolution des systèmes Exemple de graphe de flot de contrôle Exemple du pare-feu Exemple de confinement de donnée Exemple de contrôle de flot d information Exemple de contrôle des appels Exemple de contrôle des transactions Exemple de la Muraille de Chine D.1 Exemple d EPO D.2 Exemple d ordre partiel qui est un treillis D.3 Exemple d ordre partiel qui n est pas un treillis D.4 Sous-treillis du treillis D D.5 Exemple d EPOC D.6 Sous-treillis booléen du treillis D D.7 Abstraction des entiers par leur signe D.8 Élargissement/Rétrécissement D.9 Décomposition en nœuds D.10 Treillis des intervalles sur les entiers

12 xii

13 Introduction Le mot sécurité est très utilisé de nos jours, il s applique dans des domaines très différents. Les systèmes d information constituent un des ces domaines. Ces systèmes sont nombreux (PC, cartes à puce, Internet, etc.) et de plus en plus utilisés. Les exigences des utilisateurs en terme de sécurité sont de plus en plus importantes. La réponse à cette demande passe par des mécanismes robustes de preuves ou de tests. Pour accroître la confiance en ces solutions, il est nécessaire d ouvrir les preuves. L utilisateur n a pas, en général, les connaissances requises pour comprendre les preuves, mais il est possible de mettre à sa disposition des rapports dans lesquels il peut trouver assez d informations pour avoir confiance en la sécurité mise en œuvre dans un produit. C est un des principes des critères de certification. Ces critères permettent de donner une note à des produits qui reflète l effort fourni pour mettre en œuvre et prouver la sécurité. Notre travail ne porte pas sur la sécurité des systèmes d information en général, mais sur le système particulier que sont les cartes à puce. Ces cartes sont de plus en plus utilisées à travers le monde et leurs capacités de calcul et de stockage leurs permettent de contenir plusieurs applications. Pour programmer ces applications, divers langages existent, dont celui qui nous intéresse, Java Card. Le but de cette thèse est de donner un ensemble de mécanismes permettant de vérifier la sécurité des applications Java Card s exécutant sur des cartes à puce. Ces différents mécanismes apparaissent sur le schéma suivant : Class File Java Card Class File Abstraits Graphes de flot de contrôle Sémantique Propriété Abstraction Analyse Vérification Oui / Non Les applications à vérifier sont des programmes Java Card qui sont donnés dans des fichiers nommés Class file. La structure de ces fichiers ainsi que certaines informations qu ils contiennent ne sont pas intéressantes du point de vue de la sécurité.

14 2 Introduction Nous les transformons, par un mécanisme d abstraction, dans un nouveau format, les Class file abstraits. La seconde partie de ce document se concentre sur la définition complète du langage utilisé dans ces Class file abstraits. A part le mécanisme des exceptions, toutes les instructions du bytecode se retrouvent dans notre langage. L abstraction porte essentiellement sur les valeurs primitives et sur les instructions qui les manipulent. La sémantique opérationnelle de tout le langage est formellement défini à l aide d un système de règles de transition. Chaque règle est composée d un ensemble d hypothèses sur l exécution de l instruction et de son effet sur l état de l environnement. Les tests de protection effectués sur l environnement sont modélisés par huit prédicats qui sont intégrés dans les règles sémantiques pour simuler son action sur le déroulement d un programme. Les propriétés de sécurité à vérifier portent sur les exécutions de ces programmes. Pour connaître ces exécutions, nous utilisons une analyse statique basée sur la résolution d un système de contraintes qui nous permet de calculer un graphe de flot de contrôle de ces programmes. La troisième partie de ce document présente l analyse, c-à-d. la transformation des instructions en contraintes et la résolution de cet ensemble de contraintes par recherche de point fixe. Pour affiner les résultats de cette analyse, nous utilisons un nouveau type de contrainte : les contraintes conditionnelles quantifiées. Elles peuvent être vues comme une généralisation des contraintes conditionnelles de Palsberg et Schwartzbach [Palsberg et Schwartzbach 91]. Elles permettent une analyse paresseuse du programme, les contraintes ne sont générées que pour le code qui est effectivement appelé. Cela limite la taille du système initial ainsi que le nombre de contraintes à résoudre à celles intervenant explicitement dans la résolution. De plus, notre analyse possède une certaine sensibilité au flot de contrôle, cela affine l analyse en évitant de regrouper des valeurs venant d appels différents. L analyse est prouvée correcte vis à vis de la sémantique et la validité de la recherche de point fixe est aussi prouvée. Ces preuves permettent d affirmer que l analyse modélise correctement les effets des instructions, que le résultat est bien une sur-approximation des programmes et que la solution du système de contraintes peut effectivement être calculée à l aide de l algorithme itératif classique de calcul de point fixe. En ce qui concerne le moyen d exprimer les propriétés à vérifier, nous utilisons le formalisme des automates finis, approche utilisée par Schneider [Schneider 00] sous le nom d automates de sécurité. Après avoir formalisé les graphes de flot de contrôle obtenus avec notre analyse et les automates finis, nous donnons le principe de la vérification. La vérification utilise le principe de la vacuité de l intersection de deux langages et elle permet de déterminer si oui ou non les programmes Java Card respectent les propriétés. Nous terminons en présentant quelques propriétés intéressantes qu il est possible d exprimer et de vérifier sur les applications Java Card.

15 Première partie Contexte de la thèse

16

17 Chapitre 1 Aperçu des problèmes liés à la sécurité Introduction Dans ce chapitre, nous présentons les concepts de base de ce que l on appelle la sécurité informatique. La section 1.1 détaille la terminologie propre au domaine : les sujets (les intervenants), les objets (les données), les propriétés de sécurité (confidentialité, intégrité et disponibilité) et les politiques et modèles de sécurité. La mise en place de mécanismes de sécurité se justifie par l existence de menaces pouvant se concrétiser sous forme d attaques. La section 1.2 présente un aperçu de plusieurs types d attaques afin de montrer d une part leur diversité, et d autre part les conséquences qu elles peuvent engendrer. Nous traitons des attaques des communications, de la phase d authentification, du contrôle d accès ainsi que des attaques plus classiques comme les chevaux de Troie, les codes parasites autopropageables et les vers. Un système d information protège ses données (ses biens) en utilisant des règles régissant les interactions entre les objets et les sujets. Cet ensemble de règles est présenté en suivant deux niveaux de formalisme. Le premier niveau est informel et permet de donner un certain nombre de principes régissant le système : c est la politique de sécurité. La section 1.3 présente une politique de sécurité très connue : la politique de sécurité multi-niveaux. Le deuxième niveau est formel et peut être vu comme une implémentation mathématique d une politique de sécurité : c est le modèle de sécurité. Comme pour les attaques, il existe de nombreux modèles et la section 1.4 n en présente qu une petite partie. Un modèle est souvent défini pour une propriété de sécurité, il existe donc des modèles pour la confidentialité, l intégrité et la disponibilité. Ces trois propriétés n ont pas été étudiées avec le même intérêt, de ce point de vue la confidentialité est la plus importante et la disponibilité est la moins importante. Parmi tous les modèles existants, nous présentons le HRU, le BLP, la Muraille de Chine et le contrôle de flux pour la confidentialité ; les modèles de Biba et de Clark-Wilson pour l intégrité ; et le modèle de Jonathan Millen pour la disponibilité.

18 6 I.1 - Aperçu des problèmes liés à la sécurité 1.1 Définitions Les définitions proposées dans cette section sont tirées des critères d évaluation européen [ITS 91] et canadien [CTC ]. La sécurité est spécifiée en terme des deux entités suivantes : les sujets et les objets. Définition 1.1 (Sujets) Les utilisateurs humains ou les processus informatiques qui travaillent pour eux. Un sujet peut ḙtre également un objet. Par exemple, un processus peut en créer un autre qui lui-mḙme manipule des objets. Définition 1.2 (Objets) Entités passives du système qui contiennent ou reçoivent de l information. Ces deux notions permettent de définir un système sécurisé. Définition 1.3 (Système sécurisé) Un système est dit sécurisé s il met en œuvre des mécanismes de sécurité permettant de garantir les trois propriétés suivantes : Confidentialité des données l information contenue dans les objets ne doit ḙtre ni rendue accessible, ni divulguée, à un sujet non autorisé ; Intégrité des données l information contenue dans les objets ne doit pas ḙtre altérée ou détruite de manière non autorisée ; Disponibilité de service l accès aux services offerts par le système doit toujours ḙtre possible pour un sujet autorisé. Par exemple, les opérations destinées à occuper illégalement du temps de traitement doivent ḙtre détectées. Les différents mécanismes à mettre en œuvre ont pour but de protéger le système des attaques qu il peut subir. Une attaque est une action visant à violer une (ou plusieurs) des propriétés précédemment citées. Quelques attaques sont décrites dans la section 1.2. La définition des mécanismes de sécurité se fait au sein de la politique de sécurité. Définition 1.4 (Politique de sécurité) Une politique de sécurité est constituée par l ensemble des lois, règles et pratiques qui régissent le traitement des informations sensibles et l utilisation des ressources par le matériel et le logiciel d un système. Un exemple de politique de sécurité est donné dans la section 1.3. La notion de politique de sécurité permet de définir celle de modèle de sécurité. Définition 1.5 (Modèle de sécurité) Un modèle de sécurité est composé d une expression formelle (mathématique) des règles de la politique de sécurité permettant de démontrer des théorèmes (aussi appelés invariants ) concernant la sécurité de l information. Pour des raisons de compréhension, un modèle peut ḙtre accompagné d une description informelle. Un modèle de sécurité peut être vu comme une formalisation d une politique de sécurité. La section 1.4 présente quelques modèles de sécurité classiques permettant de garantir les trois propriétés de sécurité.

19 I Différentes formes d attaques 7 L ensemble des règles de sécurité exprimés dans les politiques et les modèles est appelé la base informatique de confiance (ou TCB : Trusted Computing Base). Définition 1.6 (TCB) Les règles de sécurité de la TCB peuvent ḙtre de type : Physique les mesures physiques de protection telles que le gardiennage, le confinement dans des enceintes blindées, des portes à contrˆole d accès, etc ; Logique les mesures logicielles de protection des objets. Par exemple, un contr ˆole d accès aux fichiers ou encore le login + mot de passe ; Organisationnel les mesures de sécurité de type administratives. Par exemple, les procédures de gestion des ressources informatiques peuvent ḙtre réglementées par une loi ou une norme. De plus, la TCB doit inclure les parties critiques du système d exploitation. Ces ensembles pris séparément peuvent permettre de garantir les trois propriétés de sécurité. Mais l utilisation cohérente de deux ou trois de ces ensembles permet d augmenter cette garantie. Par exemple, il est possible d utiliser un contrôle d accès par carte magnétique pour les bâtiments et un mécanisme de login + mot de passe installé sur les machines. 1.2 Différentes formes d attaques Voici une liste non exhaustive de différentes formes d attaque envisageables à l encontre d un système. Les attaques ont pour objectif l infirmation d une (ou plusieurs) propriété(s) définie(s) dans la politique de sécurité (confidentialité, intégrité, disponibilité). Attaques des communications Dans un système, toutes les informations circulent au travers des canaux de communication. L attaquant peut ainsi intercepter les communications concernant les informations sensibles lors de leurs transferts. Dans le cadre des communications, les informations sensibles ne transitent généralement pas en clair, des algorithmes de chiffrement sont souvent utilisés [Schneier 95]. Il faut donc que l attaquant déchiffre les informations qu il a pu récupérer. La propriété visée par cette forme d attaque est la confidentialité des données. Les canaux de communication peuvent être utilisés de deux façons différentes, un nom leur est donnée en fonction de leur utilisation : les canaux légitimes et les canaux cachés [Lampson 73]. Les canaux légitimes sont utilisés pour des transferts autorisés d information entre utilisateurs ou processus. Les canaux cachés sont utilisés pour des transferts d information qui viole la politique de sécurité. C est une utilisation détournée d un canal de communication. Les canaux cachés peuvent être de deux types : les canaux mémoire ou canaux de stockage : ils impliquent l écriture par un processus et la lecture par un autre d une unité de stockage du système. Ces unités de stockage sont des entités qui ne sont pas des objets mais qui permettent de transférer de l information. Par exemple l existence même d un objet, le nom d un fichier ou encore l indicateur libre/occupé d un périphérique ;

20 8 I.1 - Aperçu des problèmes liés à la sécurité les canaux temporels : ils impliquent la modulation par un processus de son usage d une ressource (CPU par exemple). Cette modulation est observée par un second processus. Un canal de communication, par exemple un fichier, peut être légitime en pièce jointe d un courriel et en même temps caché en lui donnant un nom bien spécifique. Attaques de la phase d authentification L attaquant peut observer la phase d identification d un sujet pour pouvoir se faire passer pour lui. Une attaque possible consiste à rejouer le scénario d authentification, c-à-d. envoyer exactement les même messages que la personne espionnée (figure 1.1). Alice Alice Bob Bob Serveur Serveur Alice Bob Flux réel Flux attendu Serveur FIG. 1.1 Attaque par répétition FIG. 1.2 Attaque par mystification L attaquant peut par ailleurs faire une mystification, il simule le comportement d une machine pour tromper un utilisateur et ainsi récupérer le login et le mot de passe, figure 1.2. Dans le cas d un système avec des terminaux distants, il est possible d intercepter une demande de connection et ainsi se substituer à l utilisateur légitime. Une fois l attaque réussie, l attaquant possède les mêmes droits que la personne dont il a volé l identité. Entre autre, il peut lire les données (confidentialité), les effacer (intégrité) ou encore mettre en panne la machine (disponibilité). Attaques du contrôle d accès Il est possible d essayer de contourner les mécanismes de sécurité en utilisant des failles. Ces failles (intentionnelles ou non) sont souvent appelées portes dérobées ou trappes. Ces deux termes peuvent être utilisés indifféremment. L existence et l utilisation de ces trappes ne correspondent pas toujours à des objectifs malveillants. Par exemple, certains systèmes d exploitation possèdent des comptes cachés avec de hauts privilèges afin de faciliter le travail de maintenance. Toutefois, leur existence constitue un trou de sécurité et un attaquant peut s en servir pour pénétrer dans le système. En 1998, un groupe de hackers nommé Cult of the Dead Cow (cdc) a développé une application client/serveur, connue sous le nom de Back Orifice. Elle permet au client de surveiller, d administrer et d effectuer n importe quelle action sur la machine exécutant le serveur. Les auteurs affirment qu ils ont écrit ce logiciel dans le but de mettre en évidence les problèmes de sécurité de Windows 95/98. Cette application est écrite avec les API Windows et donc le serveur ne peut s exécuter que sur des machines utilisant le système d exploitation Windows. En revanche, le client peut s exécuter sur diverses plates-formes. Il faut remarquer tout de même que cette application amène quelques réflexions. En effet, il est par exemple possible de s en servir

21 I Différentes formes d attaques 9 honnêtement pour gérer un ordinateur à distance. Ce genre d application existe et se trouve facilement dans le commerce (PCAnyWhere, Carbon Copy, LapLink, etc). Les conséquences d une utilisation malhonnête peuvent être catastrophiques (suppression de fichier, capture de mot de passe, etc). Cette notion d utilisation honnête et malhonnête est rare. Du point de vue de la sécurité proprement dite, il faut considérer que les actions sont toujours malhonnêtes. Ce style d attaque est surtout utilisée dans le cadre de la confidentialité et de l intégrité. Chevaux de Troie Un cheval de Troie est un programme qui, sous le couvert de fonctionnalités licites (réelles ou non), viole la sécurité (confidentialité et intégrité). Une possibilité est de réécrire des commandes du système. Par exemple, la commande ls 1 pour être réécrite afin qu elle ait encore ses fonctionnalités initiales, c-à-d. lister le contenu d un répertoire et, en plus, qu elle sauvegarde ce listing dans un fichier et l envoie à quelqu un. Des programmes comme les économiseurs d écran peuvent être utilisés comme des chevaux de Troie : au cours de l installation, ils copient l économiseur proprement dit et en plus peuvent installer un programme malveillant tel que la partie serveur de Back Orifice. Codes parasites autopropageables Le terme codes parasites autopropageables (ou CPA) est un terme scientifique pour désigner le terme de virus informatique [Ludwig 93]. Un virus est un programme (code) qui en s exécutant se duplique (autopropageable) et se greffe sur d autres programmes à leur insu (parasite). Un CPA ne peut pas survivre seul, sa seule chance de survie est de se greffer sur d autres programmes. Quand un programme infesté s exécute, il exécute le CPA qui se duplique et ainsi de suite. En général, les fonctionnalités des CPA ne s arrêtent pas à la duplication et à l infection, ils peuvent aussi divulguer ou détériorer des informations. Il existait plus de CPA logiciels identifiés dans le monde début 1999, ce chiffre est passé à plus de en juin 2001 (Source Mc Afee [mca ]). Les effets peuvent être multiples et plus ou moins destructeurs, et leurs conditions d activation peuvent être très différentes. Par exemple, la virus Ping Pong fait apparaître une balle de ping pong qui se promène sur l écran. L infection peut entraîner des dommages dans les fichiers, mais ce ne sont pas des dégâts intentionnels, ils ne sont pas prévu dans le code du virus. Un CPA comme Dark avenger a des intentions beaucoup plus dévastatrices. Dès que le virus a infecté soixante fichiers, il prend un secteur du disque au hasard et l efface. Si ce secteur était occupé par un programme ou une donnée, ceux-ci sont perdus. Le virus Michelangelo, pour sa part, ne déclenche ses effets dévastateurs que le 6 mars (la date anniversaire de Michelangelo). Le reste du temps, il ne fait que de l infection. Quand il s active, il remplace une partie des données qui sont sur le disque par des caractères pris au hasard. En janvier 1998, Caligula s attaque à la propriété de confidentialité. Le virus recherche la clé secrète par défaut de PGP 5.x (pour Pretty Good Privacy) et l envoie 1. La commande ls d Unix est l équivalent de la commande dir de Dos.

22 10 I.1 - Aperçu des problèmes liés à la sécurité par FTP sur le site Codebreakers. Cependant, cela ne permet pas d obtenir l accès aux fichiers sécurisés car la clé secrète est cryptée. Tous les 31 du mois, il affiche une boîte de dialogue contenant : WM97/Caligula (c) Opic [CodeBreakers 1998], No cia, No nsa, No satellite, Could map our veins.. Un dernier virus, plus récent, le CIH/Tchernobyl s est activé le 26 avril 1999, la date anniversaire de la catastrophe de Tchernobyl. Il infecte les fichiers exécutables et essaie d effacer les premiers 2048 secteurs de chaque disque dur, ce qui a pour effet de faire perdre toutes les informations contenues sur ces disques. De plus ce virus s attaque à des parties très basses du système et peut rendre ainsi la machine inutilisable. Les effets dévastateurs des CPA peuvent violer les trois propriétés de sécurité. Vers Un ver est un agent autonome capable de se propager sans l utilisation d un programme ou l intervention d une personne [Shoch et Hupp 82]. Ce n est donc pas un CPA, car il n a pas besoin de parasiter un autre fichier pour survivre. La plus célèbre attaque de vers s est produite en novembre 1988 par erreur, le ver n était pas fini. Un étudiant (Robert T. Morris) lança un programme sur Internet qui était capable de se développer par lui-même à travers le réseau [Eichin et Rollis 89]. Huit heures après le lancement de ce programme, entre 2000 et 3000 ordinateurs étaient déjà infectés. Les ordinateurs commencèrent à tomber en panne parce que le ver réapparaissait plus rapidement que les connexions réseaux ne pouvaient l effacer. Robert Morris fut le premier à être condamné pour un crime informatique. Un ver est apparu en Juillet 2001 : Code Red. Ce vers se déplace sur Internet en utilisant, sur des serveurs Web, une attaque de type buffer-overflow. Une fois un serveur infecté, le ver crée 100 copies de lui même. Il utilise les 99 premières pour continuer l infection de serveurs Web. Le dernier ver cherche des informations sur le serveur et si il se trouve sur un serveur Windows 2000/NT version US, il installe une page Web disant : Welcome to Hacked By Chinese!.. Cette page reste 10 heures dans le système et disparaît. Si la date de la machine est supérieure au 20 du mois, les vers arrêtent de faire de l infection et attaquent le site : Les attaques de vers sont toutefois rares parce que les serveurs sur Internet sont de plus en plus différents mais c est toujours une méthode utilisée par les attaquants quand une nouvelle faille est découverte dans un système d exploitation. Cela a l avantage pour l agresseur de pouvoir attaquer un maximum de sites en peu de temps. Cette duplication frénétique entraîne généralement des problèmes sur la disponibilité des machines. Il existe des organismes spécialisés dans les virus et les anti-virus, entre autres : le C.E.R.T Coordination Center [cer ], l Anti-Virus Emergency Response Team [ave ], le Virus Encyclopedia [avp ], McAfee [mca ] ou encore Symantec Anti-Virus [nor ]. Cette liste des différentes formes d attaques est loin d être exhaustive, mais elle montre déjà un grand nombre de possibilités. Mais elle ne reflète pas la réalité en ce qui concerne les propriétés ciblées par ces attaques. En effet, la propriété la plus souvent ciblée par les attaquants est la confidentialité, suivie de l intégrité puis de la disponibilité.

23 I Politique de sécurité multi-niveaux 11 Pour répondre à tous ces problèmes, il est nécessaire de mettre en place des règles qui régissent les interactions entre les sujets et les objets. Ces règles peuvent être données avec deux niveaux de formalisme : de façon informelle avec les politiques de sécurité (section 1.3) ou de façon formelle avec les modèles de sécurité (section 1.4). 1.3 Politique de sécurité multi-niveaux Il existe plusieurs politiques de sécurité, basées par exemple sur les systèmes transactionnels commerciaux [Clark et Wilson 87] ou encore sur les principes des conflits d intérêt [Brewer et Nash 89]. Dans cette section, nous décrivons en détail une politique de sécurité définie par le département de la défense américain (DoD). Il formalise la politique de sécurité militaire, exemple de politique de sécurité multi-niveaux (politique MLS pour Multi-Level Security). Cette politique spécifie que [Landwehr 81] : toute information possède une classe de sécurité ; tout individu possède un niveau d autorisation. Les classes de sécurité et les niveaux d autorisation sont de même type. Ils sont constitués de deux éléments : un niveau de sensibilité (lorsque l on parle de personnes, on utilise aussi le terme niveau de sécurité ) ; un ensemble de domaines qui permet de décrire le type des informations et des individus. Pour expliquer la politique MLS, nous utilisons un exemple dans lequel il y a quatre niveaux de sensibilité et quatre domaines. Les quatre niveaux de sensibilité sont non classifié, confidentiel, secret et top secret. Ils sont ordonnés par la relation : non classifié confidentiel secret top secret Les quatre domaines sont : OTAN, extra-terrestre, nucléaire et médical. Les domaines sont indépendants les uns des autres et ne sont pas ordonnés. Un ensemble de domaines peut être vide. Il est possible de définir une relation d ordre partiel sur les ensembles de domaines. La relation est une relation de domination, ici un ensemble de domaines A domine un ensemble de domaines B (noté B A) si et seulement si B est un sous-ensemble de A (B A). Objet Niveau de sensibilité Domaines Plan d attaque top secret nucléaire Rapports médicaux confidentiel médical Oui Oui et le taxi jaune non classifié Zone 51 top secret extra-terrestre, nucléaire TAB. 1.1 Exemple de classification MLS des objets Avec ces différentes notions, nous pouvons donner une classification MLS des objets (tableau 1.1).

24 12 I.1 - Aperçu des problèmes liés à la sécurité Personne Niveau de sécurité Domaines Le président top secret nucléaire,médical,otan L homme à la cigarette top secret extra-terrestre,nucléaire,otan Garibaldi top secret extra-terrestre, nucléaire Docteur Ross confidentiel médical Personne extérieure non classifié TAB. 1.2 Exemple de classification MLS des personnes De même, il est possible de classifier les personnes (tableau 1.2). Une personne (S(N 1, D 1 )) peut agir sur un objet (O(N 2, D 2 )) si les deux règles suivantes sont vérifiées (S O) : 1. le niveau de sécurité de la personne est supérieur ou égal au niveau de sensibilité de l objet (N 1 N 2 ) ; 2. l ensemble de domaines de la personne domine l ensemble de domaines de l objet (D 2 D 1 ). Prenons l exemple de dossiers médicaux et regardons comment sont gérées les autorisations d accès pour le président (figure 1.3) et pour Garibaldi (figure 1.4). Le président Les rapports médicaux top secret top secret secret confidentiel confidentiel non classifié nucléaire, médical, médical OTAN Le président peut consulter les dossiers médicaux. Son niveau de sécurité (top secret) est supérieur au niveau de sensibilité des rapports (confidentiel) et le domaine médical est bien inclus dans l ensemble des domaines du président ( nucléaire, médical, OTAN ). FIG. 1.3 Le président et les rapports médicaux Cette politique montre comment il est possible de définir des règles pour empêcher la violation d une propriété de sécurité. Dans le cas de la politique MLS, cette propriété est la confidentialité. À aucun moment, une information ne peut être accédé par une personne qui n a pas la classe de sécurité suffisante. En revanche, une personne autorisée peut changer le contenu d un document sans restriction, ce qui peut permettre de violer une propriété d intégrité. Le principe de classe de sécurité et de niveau d autorisation est à la base de nombreux autres modèles. Ces nombreuses utilisations viennent du fait que cette politique est simple et qu il est facile de la modifier en fonction des besoins.

25 I Modèles de sécurité 13 Garibaldi Les rapports médicaux top secret top secret secret confidentiel confidentiel non classifié extra-terrestre, nucléaire? médical Garibaldi ne peut pas consulter les dossiers médicaux. Son niveau de sécurité (top secret) est bien supérieur au niveau de sensibilité des rapports (confidentiel) ; en revanche, le domaine médical n est pas inclus dans l ensemble des domaines de Garibaldi ( extra-terrestre, nucléaire ). FIG. 1.4 Garibaldi et les rapports médicaux 1.4 Modèles de sécurité Un modèle de sécurité est une version formelle d un politique de sécurité. Elle formalise quels sont les sujets et les objets du système ainsi que les règles qui régissent les interactions. Certains modèles de sécurité sont basés sur la notion de machine à états [Landwehr 81]. De tels modèles se servent de variables d état où les valeurs des variables représentent l état du système à un moment donné. La valeur d une variable peut être modifiée par une fonction de transformation. Ces fonctions permettent de tenir à jour les variables en fonction des changements d état du système. N importe quel élément peut être une variable d état (par exemple, un octet peut être une variable d état). Par exemple, les variables d état d un système peuvent être : les sujets et les objets du système ; leurs attributs de sécurité (par exemple leur niveau de sécurité) ; les droits d accès entre les sujets et les objets. Toute commande qui affecte l état du système doit avoir sa fonction de transformation pour que le changement d état du système soit répercuté sur les variables d état. Si les variables d état vérifient les invariants, alors l état du système est dit sûr. Le modèle de sécurité est dit sûr si, quelle que soit la fonction de transformation appliquée aux variables, les invariants sont conservés. Par exemple, pour vérifier un modèle de confidentialité, il faut montrer que quelle que soit la suite de commandes effectuées, il est impossible à un utilisateur d accéder à une information protégée. Un système est dit sécurisé s il met en œuvre un modèle de sécurité sûr. Il faut prouver la correspondance entre le modèle et son implémentation et aussi montrer l absence de canaux cachés. Mais, peu de modèles intègrent la notion de canaux cachés, il faut donc les étudier séparément. Comme pour les formes d attaques, les modèles de sécurité sont nombreux. La liste des modèles présentés ici n est pas exhaustive. Les attaques sont surtout ciblées sur la confidentialité, les modèles de sécurité respectent la même tendance. La confidentialité est la propriété la plus étudiée dans le cadre des modèle de sécurité, d où un nombre

26 14 I.1 - Aperçu des problèmes liés à la sécurité important de modèles. De ce fait, dans la présentation des modèles, l accent est mis sur la confidentialité avec cinq modèles. Nous présentons deux modèles pour l intégrité et un modèle pour la disponibilité Modèles de confidentialité Pour garantir la confidentialité des données, deux types de mesures peuvent être appliqués : Le premier type consiste à faire un contrôle sur l accès aux données. Pour le contrôle d accès aux informations, nous supposons que tous les utilisateurs qui se connectent au système sont correctement identifiés et authentifiés et qu aucun utilisateur ne peut acquérir les droits d un autre. La politique de sécurité sous-jacente possède des règles qui permettent d établir si un sujet donné peut accéder à un objet donné. Ce contrôle d accès peut être discrétionnaire ou mandataire. Dans le contrôle discrétionnaire, le contrôle est fonction de l identité des sujets et/ou des groupes auxquels ils appartiennent. Ce contrôle est appelé discrétionnaire car un sujet possédant un certain droit est en mesure de donner ce droit à quelqu un d autre [TCS 85]. Dans le contrôle mandataire, le contrôle est fonction des niveaux de sensibilité des sujets et des objets. Contrairement au contrôle discrétionnaire, les niveaux de sensibilité ne peuvent pas être changés ou transférés par un utilisateur. Ils sont gérés par un tiers, appelé mandataire ou administrateur [TCS 85]. Le deuxième type de mesures ne se focalise pas sur l accès aux informations mais sur le flux de ces informations ainsi que sur leurs transferts Contrôle d accès discrétionnaire Modèle HRU Pour illustrer le contrôle d accès discrétionnaire, nous présentons le modèle à matrice d accès, appelé aussi modèle HRU [Harrison et al. 76]. Ce modèle a été présenté pour la première fois en 1971 par Butler W. Lampson [Lampson 71] et il fut complété par Michael A. Harrison, Walter L. Ruzzo et Jeffrey D. Ullman en Le système est composé de deux types d entités : les sujets et les objets. Le modèle se présente sous la forme d une matrice qui comprend une ligne par sujet et une colonne par objet et par sujet. L intersection d une ligne et d une colonne indique les droits du sujet sur l objet. Voici la liste des droits utilisés dans les modèles cités précédemment : propriétaire : le sujet est propriétaire de l objet (généralement, le propriétaire est le créateur de l objet) ; lecture : le sujet peut lire le contenu de l objet ; écriture : le sujet peut modifier de l information existante dans l objet mais il ne peut pas en ajouter ; ajouter : le sujet peut ajouter de l information dans l objet mais il ne peut ni lire ni modifier le contenu de l objet ; exécuter : le sujet peut exécuter l objet quand celui-ci représente une entité exécutable ; contrôler : un sujet qui a crée un processus peut en contrôler tous ses droits. Voici un exemple de matrice d accès dans laquelle seuls les droits lire (l), écrire (e) et exécuter (x) sont donnés (figure 1.3). Il existe trois sujets (S 1, S 2 et S 3 ) et cinq objets (O 1, O 2, O 3, O 4 et O 5 ).

27 I Modèles de sécurité 15 O 1 O 2 O 3 O 4 O 5 S 1 S 2 S 3 S 1 l e l e x S 2 l e e l S 3 l e e l e x TAB. 1.3 Exemple de matrice de contr ˆole d accès Le sujet S 1 ne peut agir que sur quatre objets qui sont O 1, O 3, O 5 et S 2. Il peut lire O 1 et O 3, il peut écrire O 1 et O 5 et il peut enfin exécuter S 2. Quand le système change d état, le changement doit être répercuté sur la matrice d accès. Dans le modèle HRU, il existe six primitives qui permettent de construire les fonctions de transformation. Ces primitives sont les suivantes : donner un droit d à un sujet S sur un objet O ; enlever un droit d à un sujet S sur un objet O ; créer un sujet S ; créer un objet O ; détruire un sujet S ; détruire un objet O (si celui-ci n est pas un sujet). Dans ce modèle, le problème est de déterminer si une configuration d un système sûr est sûre pour un droit d. Dans le cadre général, ce problème est indécidable [McLean 94]. C est pour cela que ce modèle est peu utilisé tel quel. Modèle Prendre-accorder Pour le contrôle d accès discrétionnaire, il existe d autres modèles, par exemple le modèle Prendre-accorder (take-grant model). Ce modèle est décrit par Matt Bishop et Lawrence Snyder ([Bishop et Snyder 79, Snyder 81]) et concerne le problème de transfert d informations. Pour ce faire, ils proposent d utiliser un graphe de protection. Celui-ci est composé de deux sortes de noeuds : une pour les sujets et une pour les objets ; les arcs sont étiquetés par les droits d un sujet sur un objet. Le modèle contient quatre règles de réécriture de graphe qui caractérisent les transferts d informations implicites (des arcs qui se déduisent des arcs initialement présents). Ces règles sont Post, Pass, Spy et Find. Le modèle prend en compte qu un sujet peut changer ses droits. Pour ce faire, il existe deux nouveaux droits (t pour take et g pour grant) et quatre nouvelles règles (Take, Grant, Create et Remove). Si S 1 a un droit t sur un sujet S 2 alors il peut, en utilisant Take, prendre les droits que S 2 possède sur les objets. Grant permet à S 1 de donner (d accorder) les droits qu il possède à S 2. Un exemple est donné sur la figure 1.5. Grâce à ces différentes règles, il est possible de savoir si un sujet peut accéder à une entité du système que ce soit directement ou implicitement. Il est aussi possible de connaître pour chaque sujet, tous les droits qu il possède (ou qu il peut posséder) sur les entités du système. La grande différence entre les modèles HRU et Prendre-accorder est la prise en compte explicite des transferts de droits. Dans le modèle HRU, un sujet peut donner un droit sans restriction alors que dans le Prendre-accorder, il faut en avoir la permission.

28 16 I.1 - Aperçu des problèmes liés à la sécurité Voici un graphe de protection dans lequel interviennent trois sujets et un objet (les noeuds pour les sujets ont un fond blanc, les noeuds pour les objets ont un fond gris). Les droits sont l pour lecture, e pour écriture et t pour take. s l o e t 1 s 2 s 3 En utilisant deux des règles (Take et Post), ce graphe se réécrit en un graphe plus complet. l s l o e t 1 s 2 s 3 e l La règle Take permet de trouver l arc explicite entre S 3 et O avec le droit e, S 3 peut prendre les droits (le droit t) que S 2 possède sur O, c-à-d. le droit e. Les deux arcs implicites (en pointillé) sont déduits à l aide de la règle Post. Si un sujet S 1 peut lire un objet O et qu un autre sujet S 2 peut écrire ce même objet, alors le sujet S 1 peut prendre connaissance d informations détenues par le sujet S 2 (de même pour S 1 et S 3 ). Nous en déduisons que S 1 est capable de lire des informations de S 3, ce qui n était pas évident sur le premier schéma. FIG. 1.5 Exemple de graphe de protection Il existe des systèmes dans lesquels le fait de posséder un droit ne suffit pas pour pouvoir le donner. Par exemple, sous Unix, un sujet ne peut donner un droit que s il est propriétaire de l objet. Ce genre de restriction est bien pris en compte dans le modèle Prendre-accorder Contrôle d accès mandataire Modèle BLP Une faiblesse du modèle de contrôle d accès discrétionnaire est que la sécurité du système repose sur la confiance que l on porte aux utilisateurs. En effet dans ce modèle, un utilisateur peut partager les droits qu il possède comme il le souhaite. Pour pallier cette faiblesse, David Elliott Bell et Leonard J. LaPadula ont défini un modèle de contrôle d accès mandataire, le modèle BLP [Bell et LaPadula 73b, Bell et LaPadula 73a, Bell et LaPadula 76]. Dans le modèle BLP, nous retrouvons une matrice d accès telle qu elle a été définie dans le modèle HRU. Les différents droits sont également les mêmes que dans le modèle HRU. Le reste du modèle est basé sur la politique de sécurité multi-niveaux (politique MLS, section 1.3). Une classe de sécurité est définie pour chaque sujet et chaque objet. Elle se compose d un niveau de sensibilité et d un ensemble de domaines. Bell et LaPadula ont défini une propriété, dite de confinement, plus connue sous le nom de *-property (ou star property). Cette propriété est constituée de deux règles portant sur les conditions d accès d un sujet sur un objet : 1. accès en lecture : le sujet doit avoir une classe de sécurité qui domine celle de l objet (S O) ;