SECURITE DANS LES GRILLES DE CALCUL

Transcription

1 DEA Informatique Réseaux et Systèmes Mémoire de DEA Informatique SECURITE DANS LES GRILLES DE CALCUL LABORATOIRE IRISA- UNIVERSITE DE RENNES 1 PROJET PARIS Campus Universitaire de Beaulieu RENNES Cedex France Réalisé par Jamal Eddine GHAFFOUR [email protected] Dirigé par Mme. Christine MORIN et M. Louis Rilling {christine.morin,louis.rilling}@irisa.fr Université Rennes 1 Juin 2004

2 Table des Matières Table des Matières... 2 Introduction Accès sécurisé aux ressources d une grille Introduction aux grilles de calcul Architecture générale d une grille de calcul Différentes topologies de grilles Besoins de sécurité dans un environnement de grille Intergiciels pour grilles de calcul Globus Legion Discussion Conclusion Protocole de sécurité pour une grille Objectif du stage Contexte du protocole Modèle Cryptographie dans les systèmes distribués La cryptographie à clé publique Cryptographie à seuil Rafraîchissement proactif Adaptation Description des requêtes Description du fonctionnement du protocole Asynchronisme Discussion Vérification des protocoles de Sécurité Introduction Propriétés de sécurité Modèle de vérification Logique Modale BAN Model checking Vérification du protocole Authentification Secret Disponibilité Conclusion Référence Annexe

3 Introduction Le concept de «grille de calcul» (Grid [1]) est apparu suite à la demande des scientifiques de disposer d une très grande puissance de calcul et d une capacité de stockage de l ordre du péta octet. Le travail collaboratif des scientifiques nécessite en permanence l accès et l échange d importantes bases de données à travers l Internet afin de corréler entre elles leurs informations, établir des statistiques, analyser les résultats De même, les scientifiques ont besoin d effectuer des calculs importants pour modéliser une situation ou un appareil, exécuter un programme de CAO Ces traitements exigent la plupart du temps des moyens de calculs et de stockage considérables. De plus, ils correspondent à une utilisation intensive des ressources de calcul mais seulement pendant un laps de temps réduit. L investissement nécessaire ne peut être pris en charge par des entités isolées, mais exige la mise en place de collaborations plus larges, au niveau international. Les centres de calcul en tant que tels ne suffiront plus d'ici quelques années. Le concept de grille de calcul sera sans doute une réponse à cette demande. Les grilles sont définies comme un ensemble d institutions/individus qui décident de partager des ressources et des services sous certaines contraintes et politiques. Ce partage peut être un simple accès aux fichiers, une demande de calcul, une allocation de mémoire ou toute autre opération qui paraît parfois nécessaire pour résoudre quelques problèmes de recherche ou d industrie qui demandent des ressources importantes. Les ressources partagées entre les institutions/individus qui font partie de la grille sont physiquement distribuées et parfois individuellement administrées. Afin d assurer un accès sécurisé aux ressources exposées, de nouveaux protocoles et outils doivent être définis pour supporter l environnement particulier de la grille et assurer les services de sécurité : la disponibilité, confidentialité, intégrité, authentification, et la non répudiation. L objectif de stage est la définition d un protocole de sécurité qui permet un accès sécurisé aux ressources partagées d une grille. Ce protocole doit garantir les services de sécurité, prendre en compte les propriétés associées à l environnement des grilles, et considérer les nouveaux défis liés à cet environnement : ressources reliées à travers des réseaux publics non protégés «Internet», politique et mécanismes de sécurité différents pour chaque institution/individu, dynamicité, et passage à l échelle. Dans ce rapport, nous présentons une description d un protocole de sécurité que nous avons défini pour un environnement de grille. Nous décrivons également sa validité en utilisant les méthodes et les outils de vérification pour les protocoles de sécurité. Dans une première partie, nous présentons les grilles, nous décrivons les besoins de sécurité associés à l environnement des grilles et les solutions adoptées par quelques intergiciels de grilles en terme de sécurité. Dans la deuxième partie nous décrivons le protocole de sécurité que nous avons défini durant ce stage, nous commençons par une description des hypothèses relatives à l environnement d exécution du protocole, puis nous présentons le protocole proposé. La troisième partie est consacrée à la vérification et à la validation de ce protocole. Nous exposons dans la quatrième partie les conclusions de notre travail. 3

4 1 Accès sécurisé aux ressources d une grille Cette partie représente un état de l art des systèmes de sécurité employés dans les grilles. Nous commençons par définir les propriétés d une grille : nous décrivons l architecture générale de la grille, ainsi que ses différentes topologies. Ensuite, nous entamons la définition des propriétés de sécurité qu il faut satisfaire dans un environnement de la grille. Nous décrivant par la suite quelques intergiciels de grille (Globus et Legion), et nous terminons par une discussion sur les différents systèmes utilisés dans la grille pour assurer la sécurité. 1.1 Introduction aux grilles de calcul Le terme «The Grid» ou «grille de calcul», a été introduit pour la première fois aux Etats- Unis dans les années 1990 pour décrire une infrastructure de calcul répartie utilisée dans des projets de recherche scientifique et industrielle. Dans un des premiers documents qui définissent des concepts de grille de calcul [1], les scientifiques tentent de fournir une définition détaillée des objectifs, de la forme et de l architecture des grilles de calcul. La notion de grille de calcul est fondée dur le concept de la grille d électricité (power grid). Par analogie à cette grille d électricité, la notion de grille de calcul (computational grid) est définie comme étant une infrastructure matérielle et logicielle qui fournit des service pour partager des ressources pour résoudre qui demandent des ressources importantes. 1.2 Architecture générale d une grille de calcul Nous présentons dans ce paragraphe un ensemble de principes et de critères de conception généraux utilisés dans la définition des architectures de grilles. Les grilles de calcul possèdent quatre principales caractéristiques [6]: Existence de plusieurs domaines administratifs : les ressources sont géographiquement distribuées et appartiennent à différentes organisations chacune ayant ses propres politiques de gestion et de sécurité. Ainsi il est indispensable de respecter les politiques de chacune de ces organisations. Hétérogénéité des ressources : les ressources dans une grille sont de nature hétérogène en terme de matériels et de logiciels. Passage à l échelle (scalability) : une grille pourra être constituée de quelques dizaines de ressources à des millions voire des dizaines de millions. Cela pose de nouvelles contraintes sur les applications et les algorithmes de gestion des ressources. Nature dynamique des ressources : les grilles sont caractérisées par leur aspect dynamique (Arrivée de nouveaux membre, départ des membres existants, ). Cela pose des contraintes sur les applications telles que l adaptation au changement dynamique du nombre de ressources, la tolérance aux pannes et aux délais 4

5 Plusieurs étapes constituent le processus de construction d une grille [6]: intégration des différents composants matériels et logiciels en une ressource globale à travers le réseau. l implémentation d intergiciels offrant une vue transparente et consistante à cette ressource. le développement d outils permettant le contrôle et la gestion de l infrastructure et des applications. le développement d applications exploitant cette infrastructure. Dans [3], une architecture générale des grilles de calcul est proposée. Bien que chaque projet ait sa propre architecture, une architecture générale est importante pour expliquer certains concepts fondamentaux des grilles. La figure ci-dessous illustre une telle architecture : Applications Recherche scientifique, ingénierie, finances, portail Environnements et outils de programmation Langages, interfaces, librairies, compilateurs Intergiciels Soumission et ordonnancement de tâches, découverte de services Sécurité Authentification, autorisation, confidentialité Infrastructure matérielle PC, Station de travail, équipement réseau, Figure 1 : Architecture générale d une grille de calcul 1.3 Différentes topologies de grilles [4] énumère les grilles d un point de vue topologique en trois types par ordre croissant d étendue géographique et de complexité: intragrilles (intragrids), extragrilles (extragrids) et intergrilles (intergrids). Intragrille (en analogie avec Intranet) : la plus simple des grilles est l intragrille, composée d un ensemble relativement limitée de ressources et de services et appartenant à une organisation unique. Les principales caractéristiques d une telle grille sont l interconnexion à travers un réseau performant et haut débit, un domaine 5

6 de sécurité unique et maîtrisé par les administrateurs de l organisation et un ensemble relativement statique et homogène de ressources. Extragrille (en analogie avec Extranet) : une extragrille étend le modèle en regroupant plusieurs intragrilles. Les principales caractéristiques d une telle grille sont la présence d un réseau d interconnexion hétérogène haut et bas débit (LAN/WAN), de plusieurs domaines de sécurité distincts, et d un ensemble plus ou moins dynamique de ressources. Un exemple d utilisation est lors d alliances et d échanges «Business -to- Business» (B2B) entre entreprises partenaires. Intergrille (en analogie avec Internet) : une intergrille consiste à agréger les grilles de multiples organisations, en une seule grille. Les principales caractéristiques d une telle grille sont la présence d un réseau d interconnexion très hétérogène haut et bas débit (LAN / WAN), de plusieurs domaines de sécurité distincts et ayant parfois des politiques de sécurité différentes et même contradictoires, et d un ensemble très dynamique de ressources. 1.4 Besoins de sécurité dans un environnement de grille Cette partie est consacrée à la description des besoins de sécurité dans un environnement de grilles. Echange des politiques de sécurité Dans un environnement de grille, les politiques de sécurité déployées dans chaque institution/individu sont différentes. L aspect dynamique de la grille exige que ces politiques doivent être découvertes dynamiquement. En effet, dans le cas où deux institutions/individus veulent communiquer entre eux, ils commencent par découvrir les politiques et les mécanismes adoptés par chacun d entre eux, suivi par un processus de négociation afin de définir les politiques et les mécanismes optimaux qu ils utiliseront pour une communication sécurisée. Ainsi, un modèle de sécurité dans l environnement des grilles doit intégrer les services suivant : la description, la découverte et la négociation des politiques et des mécanismes de sécurité. Authentification Ambiguïté Un des gains offerts par le déploiement des grilles, qu il n y a pas de limitation géographique sur la localisation de ses membres. Ceci entraîne l utilisation de plusieurs systèmes non compatibles, qui doivent assurer une communication authentifiée entre les participants des 6

7 différentes institutions/individus. Pour pouvoir développer plus facilement et plus rapidement des systèmes d intercommunication qui rendent transparents les différents mécanismes et politiques de sécurité utilisés localement, les opérations requises pour chaque système pour un niveau de sécurité donné, doivent être claires et non ambiguë. Authentification mutuelle Tout modèle de sécurité fiable doit aussi garantir le bon fonctionnement du concept d authentification mutuelle afin d établir une confiance entre les parties communicantes. La notion de confiance s établit après la phase d authentification, et toute entité autorisée aura confiance pour accéder aux services disponibles en fonction de ses droits d accès. Cette confiance mutuelle permet au service de s assurer que les instituts/individus qui utilisent les ressources sont les vrais instituts/individus et non pas des imposteurs. Elle permet également aux utilisateurs de s assurer qu ils utilisent les ressources des institutions/individus, auxquels ils font confiance avant de commencer toute communication. Cette authentification mutuelle est mise en œuvre souvent en utilisant les autorités de certification (CA), qui représente un tiers de confiance en attribuant des certificats pour chaque institution/individu. Une authentification unique Afin d assurer un calcul parallèle et un équilibrage de charge dans une grille, l exécution d une tâche en utilisant les ressources de la grille peut s étendre sur plusieurs institutions/individus. L authentification unique vient en aide pour une institution/individu pour ne pas s authentifier à chaque fois la tâche s étends sur un nouveau domaine. En effet, une fois l institution/individu s authentifie avec succès auprès d une entité d authentification de la grille (obtention d un ticket d accès), elle n a pas à se re-authentifier à chaque fois que la tâche s étends sur un autre domaine de la grille. Délégation Les services permanents doivent être capables d effectuer des actions à la faveur de l utilisateur sans son intervention. S il n y a pas de relation de confiance entre le domaine source de la requête et le domaine traversé par cette requête, l application utilisateur délègue à une entité son autorité afin de réaliser les actions nécessaires dans ce domaine. La délégation d une autorité d une entité à une autre doit être mise en œuvre avec précaution, c est à dire que l entité déléguée ne peut pas effectuer plus que les tâches que celles que la délégation lui a confié. La délégation doit être valable pour une durée de vie limitée afin de réduire la possibilité d une mauvaise utilisation de cette autorité. Dans plusieurs scénarios, une tâche initiée par l utilisateur prend plus de temps que celui spécifié dans la durée de vie des credentials (Un credential est une liste de droits accordés à un utilisateur) délégués. Dans ce cas, l utilisateur doit être informé avant l expiration des credentials pour pouvoir les rafraîchir afin que la tâche puisse s achever. 7

8 Identification Un environnement de grille est constitué de plusieurs domaines qui maintiennent entre eux des relations de confiance. Toute opération entre les institutions/individus des différents domaines nécessite une authentification mutuelle. Après une authentification réussie d une entité d un domaine sur un autre domaine, ce dernier essaye d identifier l entité communicante à partir de son registre d utilisateurs pour définir ses droits d accès. Pour ce faire il faut partager un registre global des utilisateurs, ce qui parait irréaliste à cause de l aspect dynamique de la grille. En outre, les credentials sont exprimés différemment dans chaque domaine et donc sont syntaxiquement et sémantiquement incompatibles. Une solution est d implémenter des services de mappage/traduction dans les entités intermédiaires (proxies, passerelle, etc.) dans chaque domaine. Le rôle de ce service est de transformer l identité d une entité qui fait partie des identités d un domaine en une identité dans un autre domaine. Confidentialité La confidentialité est assurée en ne permettant qu aux entités ayant le droit d accéder aux données/programmes d y accéder. Ceci peut être garanti, premièrement en imposant des infrastructures physiques pour le réseau de la grille (VPN), deuxièmement en utilisant des algorithmes de chiffrement (RSA [18], El-Gamal [19]). Intégrité des données Chaque membre de la grille doit posséder des méthodes et des outils pour s assurer que les données reçues ne sont pas affectés par des modifications non autorisées. En fonction de la politique de sécurité adoptée et les relations de confiance établie entre les membres de la grille, ce service peut est implémenté ou non. Par exemple, une grille qui maintient une relation de confiance entre tous ses domaines peut ne pas exiger ce service à chaque passage par un domaine intermédiaire lors d une communication point à point. Administration Un modèle de sécurité doit offrir des fonctions d administration qui incluent plusieurs aspects: administration des clés, administration des répertoires d utilisateurs, administration des politiques de confiances, administration des politiques de mappage et traduction. Selon la politique choisie dans la grille, cette dernière peut être administrée d une manière centralisée ou décentralisée. L utilisation d un système centralisé restreint l aspect dynamique et flexible de la grille et nécessite une connaissance des mécanismes et des politiques déployées dans chaque institution/individu. Ainsi le choix d une administration décentralisée est plus souhaitable, car elle offre aux administrateurs de chaque institution/individu la liberté de gérer leurs ressources locales. Les fonctions d administration doivent également offrir les outils qui assument un niveau élevé de sécurité, comme les anti-virus et les détecteurs d intrusion. 8

9 Dans la littérature des systèmes de sécurité, on ne décrit pas comment ces derniers sont administrés. 1.5 Intergiciels pour grilles de calcul Dans cette partie, nous donnons une vue d ensemble sur les principaux intergiciels pour grilles de calcul. Nous exposons essentiellement les intergiciels Globus et Legion. Nous avons choisi ces intergiciels en raison de leur importance et leur maturité aux niveaux académique et industriel et à cause de l intérêt grandissant envers eux dans les projets de grande ampleur Globus La boîte à outils Globus est formée d un ensemble de composants [9]. Globus est devenu le grand standard utilisé dans les projets de grilles de calcul. Plusieurs nombreuses entreprises ont adopté Globus pour servir de base à leurs produits commerciaux pour grilles de calcul. Par la suite, nous présentons les principales fonctionnalités offertes par Globus à ses utilisateurs, particulièrement en terme de sécurité Introduction Globus fournit les fonctionnalités et les services de base nécessaires pour la construction de grilles de calcul. Ainsi, nous trouvons des services et des mécanismes tels que la sécurité, la localisation et la gestion des ressources, la communication Globus est composé d un ensemble de modules ayant chacun une interface que les services de niveau supérieur peuvent utiliser pour invoquer ses mécanismes. La table1 expose ces différents services [7]. Service Nom Description Gestion de ressources GRAM Allocation des ressources et gestion des processus Communication Nexus Service de communication unicast et multicast Sécurité GSI Authentification et autorisation Information MDS Information sur la structure et l état de la grille Table 1 : Principaux services offerts par Globus. Par la suite, nous détaillons les mécanismes de gestion de la sécurité dans Globus Gestion de la sécurité Globus fournit une architecture de sécurité complexe permettant de sécuriser le fonctionnement de la grille. Les composants de sécurité fournissent les mécanismes qui assurent l authentification, l autorisation et la confidentialité des échanges. Cette architecture de sécurité est appelée «Grid Security Infrastructure» ou GSI [17]. Globus repose sur la cryptographie à clé publique. Ainsi pour pouvoir utiliser les mécanismes de sécurité de GSI, il faut créer une paire de clés (publique/privée) et demander la délivrance 9

10 d un certificat numérique d une autorité de certification (CA) et cela pour chaque noeud de la grille. A la fin de cette procédure, nous avons sur chaque machine trois informations importantes contenant respectivement : la clé publique du CA, la clé privée du nœud et le certificat numérique du nœud (au format X.509). Il est important de noter que le fichier contenant la clé privée du nœud devra être particulièrement sécurisé pour ne pas y permettre un accès illégal par des utilisateurs non autorisés. Pour cela les mécanismes du système d exploitation sous-jacent devront être utilisés (droits d accès, chiffrement, détection d intrusion et d intégrité). Authentification et autorisation Dans un scénario de communication entre deux nœuds de la grille, il faut qu ils aient confiance l un en l autre, on parle d une authentification mutuelle. Pour cela GSI offre un mécanisme d authentification mutuelle et d autorisation qui utilise SSL/TLS [20]. Globus assure cette procédure pour chaque requête d exécution de tâche. La procédure est la suivante comme présentée dans la figure2 [4] : 1. Le nœud A envoie son certificat au nœud B. 2. B s assure que le certificat est valide et extrait l identité et la clé publique de A du certificat. 3. B génère un nombre aléatoire et l envoie à A. 4. Lors de la réception de ce nombre, A le chiffre avec sa clé privée (c est ici que A pourra demander à l utilisateur d entrer le mot de passe) et l envoie à B. 5. Lors de la réception du nombre chiffré, B le déchiffre avec la clé publique de A et s assure qu il est le même. A est alors authentifié par B. 6. La procédure est répétée dans le sens inverse pour que A authentifie B. 7. B transpose le nom de l utilisateur se trouvant dans le certificat en un nom d utilisateur local au nœud. Pour cela un fichier appelé grid-map est utilisé. 10

11 4 Mot de passe Noeud A Ton certificat 1 envoyer 3 Ton certificat créer & envoyer Nœud B 2 Donnes ta clé publique & sujet Ta clé privée aléatoire aléatoire Clé publique de CA 4 Chiffrer & envoyer 5 aléatoire décrypter Ta Clé privée 5 Identifier Sujet 6 mappage Nom utilisateur <Sujet> <nom utilisateur> Fichier de mappage Figure 2 : Authentification et autorisation Délégation et authentification unique Imaginons la situation où un utilisateur doit lancer des milliers de tâches et que ses tâches doivent lancer à leurs tours de nouvelles tâches. Il devient impossible de demander à l utilisateur de fournir son mot de passe. Heureusement GSI offre un mécanisme de délégation permettant de diminuer le nombre de fois qu un utilisateur doit fournir son mot de passe. Ce mécanisme de délégation est une extension des mécanismes de SSL. La création d un proxy est la solution. Ainsi si un utilisateur utilise un nœud A authentifié par un nœud B, il pourra créer un proxy sur B lui délégant ainsi son autorité. B sera en mesure de créer des tâches sur un nœud C comme si l utilisateur sur A les avait créées. Un proxy consiste en un nouveau certificat numérique avec une nouvelle paire de clés publique/privée. Il contient l identité de l utilisateur légèrement modifiée pour indiquer que c est un proxy. Ce nouveau certificat est signé par l utilisateur lui-même et non pas par l AC. De plus un proxy a une durée de vie limitée. Il est alors utilisé pour assurer la procédure d authentification mutuelle et d autorisation sans avoir à impliquer l utilisateur. 11

12 La figure suivante détaille les étapes de création et d utilisation d un proxy [4] : Utilisateur Création d un proxy utilisateur C U Host computer Proxy utilisateur C UP Allocation d une resource distante C P C U C U P C R Long-lived credential Temporary credential Delegated credential User s credential Proxy credential Resource proxy credential Site 1 Resource credentials Global-to-local mapping table Site 2 Global-to-local mapping table Resource credentials C R Local policy and mechanisms Processus C P Allocation de ressources Processus C P C R Local policy and mechanisms Figure 3 : Délégation, création et utilisation d un proxy (source [8]). Il faut noter que ce processus d authentification et d autorisation du proxy nécessite l établissement d une chaîne de confiance de l autorité de certification jusqu au proxy en passant par l utilisateur. Communication chiffrée Bien que GSI requière le déroulement des processus d authentification et d autorisation, la procédure de chiffrement des communications entre nœuds n est pas utilisée par défaut et cela afin d éviter la surcharge des échanges par le chiffrement et le déchiffrement. Mais puisque GSI utilise SSL comme système sous-jacent, la procédure de création d une clé secrète commune entre deux nœuds est possible (clé de session). Cette clé sera alors utilisée par un algorithme tel que DES [22] pour chiffrer les échanges. D un autre côté GSI assure par défaut l intégrité des données. Pour plus de détails sur GSI le lecteur pourra se référer à ww.globus.org/security. 12

13 1.5.2 Legion Les concepteurs de Legion l avaient défini comme un système fournissant à ses utilisateurs une interface uniforme à une importante capacité de calcul, facilitant la collaboration entre eux et cachant la complexité due au fait que le système est constitué de milliers voire de millions de ressources distribuées à travers le monde. En effet, l utilisateur aura l illusion d utiliser un ordinateur unique mais très puissant. Dans la suite nous présentons les principes de base de Legion ainsi que les fonctionnalités offertes par la plateforme essentiellement en terme de sécurité Introduction L architecture de Legion est une architecture en couches [10], avec au plus bas niveau l infrastructure matérielle et logicielle. La couche en dessus est constituée des objets de base («Core Legion Objects») [11]. Cet ensemble d objets implémente les fonctionnalités fondamentales (gestion des ressources, migration, sécurité ) requises pour le bon fonctionnement du système. La couche suivante est composée de l ensemble des objets offrant des fonctionnalités de haut niveau tels que les services d ordonnancement, de système de fichiers et d information. Les deux dernières couches offrent des librairies d interface aux services sous-jacents et les applications des utilisateurs. La figure suivante illustre l architecture de Legion : Application Librairie Legion (méthode d invocation de service) Systéme de fichier Legion Service de gestion de ressources Objet Legion de gestion de services (Core Objects) Infrastructure Figure 4 : Architecture de Legion (source Services de sécurité Dans ce paragraphe, nous citons trois mécanismes de sécurité offerts par Legion permettant d assurer un niveau de sécurité dans le système. Ces trois mécanismes traitent de l authentification, de l autorisation et de la confidentialité des échanges. 13

14 Identification et authentification Les identités dans Legion sont fondées sur les identificateurs d objets ou LOID. Même les utilisateurs de Legion possèdent leur propre LOID. La partie concernant la sécurité dans un LOID contient un certificat X.509 contenant lui-même une clé publique RSA. L inclusion d une clé publique dans un LOID rend facile le chiffrement des messages destinés à un objet et la vérification des données signées par lui. Ce certificat est propagé avec les appels de méthodes entre objets. L authentification de l identité d un objet ou d un utilisateur se fait alors en se basant sur ces certificats X.509 et en utilisant le mécanisme de chaîne de confiance. Autorisation Dans un environnement de grille de calcul, il est fréquent que les tâches (des objets dans le cas de Legion) accèdent à des ressources de la part de l utilisateur. Puisqu il est interdit de fournir la clé privée d un utilisateur aux objets qui le représentent, il faut utiliser un autre mécanisme. Revenir à chaque appel à l utilisateur pour fournir sa clé privée est un mécanisme fastidieux, complexe et non performant. Pour éviter cela, un mécanisme de délégation est utilisé dans Legion avec l utilisation des «credentials». Quand un objet demande l accès à une ressource, il présente le credential qu il possède. Cette ressource pourra alors décider de lui accorder l accès ou pas. Dans Legion deux types de credentials existent [12]: Delegated credential : qui spécifie explicitement le bénéficiaire. Bearer credential : qui donne tous les bénéfices à son porteur. L accès est contrôlé du côté des ressources par des listes d accès «Access Control List». Chaque ressource contient une liste d objets (représentés par leur LOID) qui peuvent y accéder. Plus particulièrement chaque méthode d un objet est munie de deux listes, une appelée allow et l autre appelée deny. Lors de l appel de cette méthode par un objet la liste deny est consultée pour s assurer que l identité (LOID) de l objet n existe pas. Dans le cas contraire, la liste allow est consultée pour s assurer que l identité de l objet existe. C est suite à cette double procédure que l objet se voit accorder l accès à la méthode. Confidentialité et intégrité des communications Un appel de méthode dans Legion consiste en un ensemble de messages. Legion assure la confidentialité et l intégrité de ces messages. Il existe trois modes de sécurité dans Legion [12]: Pas de chiffrement Mode privé : dans ce mode tout le message est chiffré. RSA est utilisé pour échanger une clé DES (clé de session) qui sert pour le chiffrement. Mode protégé : dans ce mode la partie du message contenant des informations critiques (tel qu un credential) est chiffrée. L autre partie est protégée en conservant son intégrité (utilisation d une fonction de hachage). Le but de chiffrer un crendential est d empêcher son vol. 14

15 Enfin, notons que Legion fournit un mécanisme d estampillage, permettant d éviter toute attaque par répétition. 1.6 Discussion Cette partie sera consacrée à la description d autres modèles existants et les mécanismes qui ils déploient pour adresser les besoins de sécurité. Plus que Legion et Globus, les modèles décrits incluent les projets qui adressent les infrastructures pour le calcul distribué CRISIS [13], SHARP [14]; ainsi que ceux qui définissent des systèmes de fichiers distribués SFS [15], FARSITE [16]. Authentification, confidentialité et intégrité La majorité des infrastructures (GLOBUS, CRISIS, SHARP) de sécurité introduisent le protocole SSL (Secure Socket Layer) dans leurs infrastructures pour permettre l authentification. GSI utilise OpenSSL ou SSLeay qui sont des implémentations libre du protocole SSLv3. Ce dernier garantie aussi la confidentialité et l intégrité des données et supporte les proxies de certificats pour la communication avec les CAs. Ceci explique le grand déploiement de ce protocole dans les architectures de sécurité distribuée (CRISIS, LEGION, SFS, FARSITE). Dans une première implémentation, GLOBUS oblige son infrastructure à supporter une seule autorité de certification CA qui associe les Credentials aux utilisateurs. Mais en pratique, les utilisateurs doivent être capable de se présenter avec des Credentials obtenus de n importe quel CA : Le CA du domaine local, un CA commercial, etc. la nouvelle implémentation de GSI supporte les multiples CAs ; et donc les domaines doivent être capable de traiter les Credentials attribués par différents CAs, et en même temps introduire dans leurs politiques locales l information des CAs auxquels ils font confiance, et à qui ces CAs doivent faire confiance. par exemple, un domaine qui offre des outils pour l éducation peut faire confiance par exemple dans un CA d une école, et ne fait pas confiance à des certificats attribués à des utilisateurs qui sont pas étudiants par exemple. Alors les utilisateurs doivent présenter tous leurs Credentials et le domaine décide lequel il va utiliser en fonction de ses politiques de contrôle. CRISIS introduit dans son approche deux types de certificat : les certificats d identité et les certificats de transfert. Le certificat d identité associe une clé publique à un principal (utilisateur, machine), et qui est valide pour une période de temps. Le certificat de transfert sert à transférer une partie de privilège d un principal à un autre principal. Dans l approche de CRISIS ; le CA signe les certificats d identité qui seront valable pour une longue durée (souvent de l ordre de semaines) et identifie un principal local OLA (on-line agent)qui sera chargé de re-signer ce certificat avec un temps relativement court (à l ordre des heures). Le support de cette approche offre plusieurs avantages. Premièrement, pour réussir à voler les clés, le CA et l OLA doivent être «subverted : détournés». En outre l existence du OLA permet au CA d être non fonctionnel pour des durées importantes liées à la validité de ses certificats, par conséquent attaquer le CA devient une tache très difficile. Un autre avantage 15

16 de cette approche que le système de certification reste opérationnel même dans l existence des CAs ou des OLAs qui sont malicieux. Une autre approche qui définit un système de fichier distribué est SFS, ce dernier assume qu il y a dans chaque domaine un serveur de fichier et un serveur d authentification. Pour accéder à un fichier, l utilisateur envoie une requête au serveur de fichier, ce dernier transmet cette demande (opaque pour lui) au serveur d authentification local qui vérifie la signature de l utilisateur et extrait ses Credentials, qui sont envoyé au retour au serveur de fichier qui décident en fonction de ses ACLs si l utilisateur a le droit d accès au fichier. Le serveur d authentification local maintient la liste des utilisateurs et des groupes qui sont définis localement, et maintient dans des caches la liste de tous les utilisateurs et des groupes qui peuvent utiliser ce système de fichiers distribué. Chaque serveur d authentification locale met à jour périodiquement (chaque heure) son cache en demandant les bases des utilisateurs aux serveurs d authentification des autres domaines en utilisant une communication sécurisée SSL par exemple. Cette approche permet la disponibilité du système dans le cas où un serveur d authentification d un domaine n est pas disponible, mais augmente considérément la taille des caches dans le cas d un système qui contient un grand nombre d utilisateur. Etablissement d une relation de confiance entre domaines L approche de Globus ne nécessitent pas une relation de confiance supplémentaire entre les différents domaines pour permettre la délégation, ceci est dû à l authentification effectuée pour chaque allocation de ressources entre le proxy utilisateur et le proxy ressource, ou entre le processus crée dynamiquement et le proxy de ressource. CRISIS nécessitent une relation de confiance entre les différents domaines de la grille, il suppose la présence de multiples domaines administrés d une façon autonome et dans chaque domaine il y a au moins une entité CA/OLA. Les différents domaines ont pas le même degré de confiance dans chaque CA, et donc les CAs sont arrangé dans une structure de graphe. Lorsque un principal reçoit un certificat d un CA situé dans un domaine quelconque, il vérifie la validité de ce dernier en cherchant dans le graphe un chemin de confiance à partir du domaine locale (domaine où se situe la principal) au domaine destination (domaine source du certificat). Dans la version actuelle de CRISIS le graphe est maintenu statiquement par l administrateur de chaque domaine, et dans les versions prochaines le support dynamique de ce graphe est prévu. Farsite utilise la même approche que celui de CRISIS pour assurer les relations de confiance entre les différents domaines. SFS nécessite également une relation de confiance entre les différents domaines pour permettre l échange des bases d utilisateurs et des groupes entre les serveurs d authentification locaux. SFS se contente de maintenir cette relation de confiance dans des fichiers de configurations définis localement par l administrateur du domaine. 16

17 Identification et Autorisation L infrastructure GSI définie initialement utilisait des simples ACLs (Access Control List) pour définir les droits d accès à un utilisateur identifié à partir de la phase d authentification. Dans la version courante de GSI, et avec le support de multiples autorité de certification CAs comme déjà expliqué dans la partie authentification, GSI introduit une fonction générale de contrôle d accès en utilisant l API GAAC (Generic Autorisation & Access Control). Dans un système distribué, il y a moins de confiance et plus de risques ; alors il est vitale que les principals transfèrent le moins possible de leurs privilèges aux autres principals. CRISIS introduit la notion de rôles qui associent une partie des privilèges d un utilisateur avec des nom (nom de domaine, de principal, de tache, etc.) permettant le choix des privilèges à transférer vers un processus. Le principal crée un nouveau rôle en générant un certificat d identité qui contient clé publique/clé privée, et un certificat de transfert qui définit la partie des privilèges associée à ce rôle. Pour autoriser des principals à effectuer des taches sur des domaines distants, CRISIS maintient des ACLs sur chaque nœud. Dans l approche de CRISIS, pour effectuer l autorisation les demandeurs sont responsables de prouver qu ils sont autorisés pour accéder à un objet. Le demandeur envoi au reference monitor une liste de certificats qui décrit ses Credentials, ce dernier vérifie si tous les certificats sont signé par une clé publique d un CA qu il lui fait confiance (recherche dans le graphe des CAs) et après il vérifie dans ses ACLs si le principal est autorisé pour un tel accès. Dans le Projet LEGION, chaque objet est identifié par un LOID unique (Legion Object Identifier). LOID consiste à un nombre variable de champs de données binaire ; un de ces champs contient un certificat X.509. L accès à un objet dans LEGION est défini comme la possibilité d appeler une méthode de cet objet. Le contrôle d accès n est pas centralisé ce qui permet à chaque objet de renforcer son politique de contrôle d accès. Le modèle général d accès dans LEGION se base sur l utilisation d une couche MayI qui définit si l objet appelant est autorisé pour un tel appel. Une fois l utilisateur obtient ses Credentials, les serveurs SFS décident les droits d accès en fonction de ces derniers. Dans un approche simple, SFS définit trois type de credentials : Unix Credentials qui sont basés sur le fichier /etc/passwd du système UNIX, public key credentials qui représentent une fonction de hachage appliquée à la clé publique de l utilisateur, et Group List Credentials qui définit les groupes auxquels l utilisateur appartient. Dans SFS l accès de contrôle est basé sur ces trois types de Credentials, le serveur vérifie l ACL associé au fichier ou au répertoire pour déterminer si la requête peut être honorée. 1.7 Conclusion Les modelés décrits dans cette partie, ont tous conservé une vision statique d un système distribué pour adresser les besoins de sécurité dans un environnement de grilles. En effet, ils se sont fondés sur des solutions de base pour la sécurité dans un système distribué (Kerberos [21], PKI) en introduisant des services qui remédient quelques problèmes associés à la grille : Service d authentification unique pour alléger l utilisation de la grille, délégation pour permettre l accès à des ressources de plusieurs domaines. Mais tous ces 17

18 modèles n ont pas abordé les problèmes liés à dynamicité de la grille et qui nécessite d introduire des services de flexibilité et d interopérabilité. Le projet Globus dans son infrastructure GSI reste le seul à aborder cet aspect en intégrant des solutions génériques et paramétrables. Le support de la dynamicité de la grille nécessite l introduction d autres systèmes de sécurité. En effet, les solutions décrites sont basées sur des modèles de confiances qui définissent les différentes relations de confiance entre les domaines de la grille. Cette solution montre ses limites rapidement dans environnement dynamique et de grande échelle. Nous décrivons dans la suite de ce rapport notre proposition pour un protocole de sécurité pour un environnement de la grille. 18

19 2 Protocole de sécurité pour une grille Dans cette partie, nous décrivons le protocole de sécurité que nous avons défini pour un accès sécurisé aux ressources d une grille. Nous commençons par définir les objectifs et les besoins d un tel protocole, ensuite nous proposons une description détaillé du fonctionnement de notre protocole, et nous terminons par une discussion sur les propriété garantit par le protocole ainsi que les façon de son utilisation dans le différentes architectures de la grille. 2.1 Objectif du stage L approche la plus simple est de mettre en œuvre une infrastructure centralisée qui introduit des serveurs dédiés pour assurer les propriétés de sécurité. La mise en œuvre d une telle infrastructure introduit un point de vulnérabilité dans le système, car si l entité centrale est corrompue tout le service est corrompu. Les services de sécurité proposés pour les grilles ont essayé de définir une architecture moins centralisée fondée sur les chaînes de confiance. Dans l exemple du projet Globus, son infrastructure GSI nécessite pour ses processus d authentification et d autorisation l établissement d une chaîne de confiance entre les autorités de certification des différentes institutions/individus de la grille. Dans un environnement de grille, chaque institution/individu membre de la grille est administré individuellement et met en œuvre ses propres mécanismes et politiques de sécurité. Par conséquent, il n y a aucune garantie sur les moyens de sécurité déployés dans cette institution. Les autorités de certification déployées dans les domaines de la grille dans le cas de GSI peuvent être facilement corrompues, et alors présenter un point de vulnérabilité pour le service. Les grilles sont caractérisées également par leur dynamicité, la maintenance de ces chaînes de confiance devient une tâche difficile dans un système à grande échelle. L objectif de base dans notre stage est définir un service de sécurité qui satisfait les propriétés suivantes : Décentralisé : les services d authentification et d autorisation doivent être garantis en absence d une entité centrale (autorité de certificat, serveur d authentification). On souhaite également que notre système soit similaire à un système pair à pair dans le sens où les services de sécurité sont réalisés par des membres des systèmes et non pas par des serveurs dédiés à réaliser les services (les membres de la grille sont à la fois des utilisateurs et des serveurs). Dynamique : l environnement de grille est caractérisé par sa dynamicité, le protocole doit alors s adapter pour supporter les changements de l architecture de la grille (départ d un nœud, arrivée d un nœud, nœud détecté corrompu ). Disponible : un protocole de sécurité doit assurer un service permanent en protégeant le service des attaques lancées par des adversaires. Un modèle 19

20 d adversaire analogue à un modèle de tolérance aux fautes est proposé pour caractériser la puissance d un adversaire. Deux modèles sont définis : - Adversaire passif : il est capable de lire les informations sur le système sans changer son comportement (voler l information enregistrée sur les serveurs, voir le contenu des messages échangés...). - Adversaire actif : en plus de la lecture des informations, il est capable de contrôler le comportement du système afin de le dévier de sa spécification (empêcher la terminaison d une opération cryptographique, altérer ou détruire les messages échangés..). On parle d un adversaire byzantin. Sécurisé : le protocole doit assurer les services de sécurité : authentification, intégrité, confidentialité, non répudiation. Authentification unique : à travers une seule authentification avec succès, un membre de la grille peut accéder aux différentes ressources/programmes exposés par la grille. Résistant au facteur d échelle : une grille consiste en un nombre d institutions/individus de l ordre de quelques centaines ou des milliers qui partagent l utilisation de leurs ressources. Un protocole de sécurité doit passer à l échelle en permettant ses services dans un réseau de grande taille. 2.2 Contexte du protocole L idée clé dans notre protocole est de permettre un fonctionnement analogue à un serveur d authentification et d autorisation qui attribue des tickets pour permettre les accès aux différentes ressources de la grille (tel que par exemple un serveur Kerberos). L architecture centralisée représente une grande vulnérabilité aux attaques des adversaires (attaques passives, attaques actives). Ainsi, notre protocole essaye de réduire cette vulnérabilité en faisant appel aux protocoles de réplication, tout en gardant une utilisation transparente d un seul serveur pour les utilisateurs du service. Par conséquent, pour accéder à une ressource de la grille, chaque membre de la grille doit avoir un ticket d accès. Un ticket dans notre service se compose des informations reliés à l utilisateur (sa clé publique, ses droits d accès, ). Notre service est fondé sur la confiance dans la clé secrète du service. Tout membre qui souhaite un accès à une ressource de la grille présente un ticket, qu il obtient après la phase d authentification. L accès est accepté si et seulement si le ticket est signé par la clé secrète du service. Ainsi, notre service maintient un couple clé privé/publique. La clé privée est maintenue secrète, et utilisée pour signer les ticket d accès. Afin de permettre la vérification du ticket, tous les membres de la grille ont la connaissance de la clé publique du service. Dans ce qui suit, les membres de la grille qui sont autorisés à participer aux processus de signature avec la clé secrète du service sont appelés des serveurs, tandis que les autres entités sont appelées des clients. 20

21 Notre service démarre avec un serveur central qui détient cette clé secrète. En fonction du nombre de serveurs connectés à notre service et des hypothèses sur l environnement d exécution, ce dernier évolue en un système décentralisé. En effet, le serveur central définit un partage de la clé secrète et associe à chaque serveur de la grille un sous partage en utilisant la cryptographie à seuil. De cette manière, pour signer un message chaque serveur génère une signature partielle du message en utilisant son sous-partage, et un ensemble de serveurs est capable de générer une signature de ce message avec la clé secrète du service à partir des signatures partielles, et sans qu aucun d eux ne connaisse explicitement la clé secrète. En utilisant une cryptographie à seuil ( n, t + 1), plus de t serveurs doivent être corrompus pour pouvoir générer une signature par la clé secrète du service. Notre protocole utilise également le rafraîchissement des sous-partages pour lutter contre les adversaires mobiles. Les sous-partages sont périodiquement régénérés et les anciens sont détruits. Ceci oblige l adversaire à attaquer au moins t + 1serveurs dans une période limitée appelée fenêtre de vulnérabilité. 2.3 Modèle Notre décrivons dans cette partie notre protocole de sécurité dans un environnement synchrone. Dans la partie xxx, nous définissons les adaptations faites à notre protocole dans un système asynchrone. Notre protocole est constitué de deux phases en fonction du nombre de participants au système: Phase 1 Un seul serveur détient la clé secrète du service. On assure que les moyens de sécurité déployés dans le domaine qui contient ce serveur. Afin d assurer la disponibilité du service, on peut mettre en place plusieurs serveurs qui détiennent la clé secrète du service. Le passage à un système décentralisé est fait en supposant que avec n serveurs, un adversaire n arrive pas à corrompre plus de t serveurs dans une fenêtre de vulnérabilité. Afin d assurer la disponibilité du service, la décision de passage à un système décentralisé est prise dés que n! 2 t + 1 dans un environnement synchrone, et n! 3 t + 1 dans un environnement asynchrone. Phase 2 Les processus d authentification et d autorisation deviennent décentralisés. Plusieurs serveurs participent à la signature du ticket. Les hypothèses liées à notre environnement d exécution sont les suivantes : Serveurs : Notre protocole est exécuté par n serveurs. Ils peuvent être corrects ou corrompus. Un serveur corrompu peut arrêter son exécution, dévier son exécution de sa 21

22 spécification (fautes byzantines), et/ou rendre l information enregistrée dans le serveur inaccessible. On suppose que : au plus t serveurs sont corrompus durant une fenêtre de vulnérabilité. les algorithmes cryptographiques utilisés sont sécurisés (cryptographie à clé publique, cryptographie à seuil, rafraîchissement proactif des sous partages) Lien de communication : chaque serveur est connecté à un canal de diffusion broadcast. Les nœuds connectés à ce canal peuvent lire d une manière instantanée chaque message diffusé sur ce dernier par un autre nœud. Environnement synchrone : les serveurs ont accès à une horloge globale. Le temps est divisée en périodes de temps déterminées par l horloge globale (par exemple, un jour, une semaine, etc.). Au début de chaque période, les serveurs exécutent un protocole de mise à jour (update phase). A la fin de cette phase, les serveurs enregistrent de nouveaux sous partages pour la clé secrète du service. Ces hypothèses offrent aux adversaires la capacité de : corrompre t serveurs dans un temps limité «fenêtre de vulnérabilité», insérer de nouveaux messages, détruire, altérer, rejouer, et réordonner les messages. Système centralisé Système décentralisé Client Trusted1 Serveur1 Sous-partage s 1 Serveur2 Sous-partage s 2 Client Trusted2 Serveur1 Secret S Client Trusted3 Serveur3 Sous-partage s 3 Serveur4 Sous-partage s 4 Figure 5 : Passage d un système centralisé à un système décentralisé. Le système évolue en un système décentralisé après la connexion de 3 serveurs n! 3 t + 1. Le serveur 1 définit un partage (4,1) pour la clé S et associe chaque sous-partage s i au serveur i. 22

23 2.4 Cryptographie dans les systèmes distribués La cryptographie à clé publique Les algorithmes à clé publique définissent une paire de clés pour chaque utilisateur. En effet, chaque utilisateur possède deux clés P et S. La clé S est la clé secrète jamais échangée ou communiquée, tandis que la clé P est dite clé publique, et elle est volontairement partagée et mise à la disposition de tous les autres utilisateurs, qu ils soient légitimes ou intrus. Tout message chiffré par la clé secrète S d un utilisateur A ne peut être déchiffré que par la clé publique P qui lui est complémentaire et vice versa. La fiabilité des systèmes à clé publique repose sur la possibilité de trouver une paire de clés à la fois complémentaires et inviolables. Quel que soit le processus d attaque, quelle que soit la technique de calcul mise en œuvre, et quelle que soit la puissance des machines utilisées, la clé publique à elle seule ne doit théoriquement pas permettre d en déduire la clé secrète. Le coût d une telle opération doit être excessivement cher et donc infaisable. Contrairement aux algorithmes à clé symétrique, les algorithmes à clé publique n utilisent en général pas le même processus et cycle de calcul lors du chiffrement et du déchiffrement. Les fondements théoriques de cette technique supposent l utilisation de deux fonctions l une inverse de l autre. Toute la fiabilité des systèmes asymétriques repose sur la difficulté de trouver la fonction inverse à partir de la fonction utilisée lors du chiffrement et du déchiffrement. Pour assurer cette caractéristique, certains fondements mathématiques sont utilisés. En effet, les fonctions de calcul et de transformation utilisés dans ces algorithmes sont soit des fonctions de puissance dans un anneau d entiers modulo N, soit des fonctions exponentielles dans un corps fini Dans notre protocole, nous utilisons une infrastructure à clé publique. Chaque pair de la grille conserve un couple de clé privée et clé publique défini individuellement qui est présenté à notre service pour être certifié. Les pairs utilisent l algorithme RSA qui est jusqu à nos jours considéré comme la référence des algorithmes asymétriques. L algorithme RSA a été développé au laboratoire MIT par Rivest, Shamir, et Adelman. Cet algorithme est détaillé en annexe Cryptographie à seuil La distribution de la confiance dans notre protocole est accomplie à travers l utilisation de la cryptographie à seuil [23,24]. Un schéma cryptographique à seuil ( n, t + 1) permet à n parties le partage de la capacité d effectuer une opération cryptographique (e.g., création d une signature digitale). Quand t + 1 parties sont capables d effectuer cette opération, cette dernière reste infaisable pour tout quorum de parties dont la taille est inférieure strictement à t +1. Dans notre cas, n serveurs peuvent signer le ticket d accès. Pour assurer que le service tolère t serveurs corrompus, on utilise également le schéma à seuil ( n, t + 1) et on divise la clé privée du service S en n sous-partages ( s 1, s2,..., sn ), et on associe à chaque serveur i (un serveur dans notre protocole représente une entité qui a le droit de participer au processus de génération du ticket) un sous-partage privé s i. ( s1, s2,..., sn ) est appelé le partage ( n, t + 1) de S. 23

24 Dans notre service, pour signer un ticket d accès, une demande est envoyée à un serveur de notre service appelé le combineur. Le combineur envoi cette demande de signature à un quorum de serveurs. Chaque serveur génère une signature partielle du ticket en utilisant son sous-partage privé et envoie cette signature partielle au combineur. Lorsque le combineur obtient t + 1 signatures correctes, il devient capable de générer un ticket signé par la clé secrète du service S. Tel que exemple, voir en annexe le protocole de Shoup [35] qui décrit un protocole de cryptographie à seuil en utilisant RSA. Les serveurs corrompus (au max t) ne peuvent pas générer correctement à eux seuls un ticket d accès aux ressources de la grille, car ils ne peuvent générer au maximum que t signatures partielles. La figure suivante utilise un schéma cryptographique à seuil ( 3,2), chaque serveur i obtient un partage s i de la clé privée du service S. Pour un message, le serveur i peut générer une signature partielle PS ( m, si ) en utilisant son partage s i. Les serveurs corrects 1 et 3 génèrent des signatures partielles et les envoient au combineur c. Bien que le serveur 2 n arrive pas à envoyer sa signature partielle, le combineur est capable de générer la signature PS ( m, S) de m par la clé privée du service S. Cryptographie à seuil s 1 serveur1 m s 2 c m S serveur2 s 3 serveur3 Figure 6 : Un schéma de cryptographie à seuil ( 3,2) Avec l application de la cryptographie à seuil, on doit lutter contre le comportement des serveurs corrompus. Un serveur corrompu peut générer une signature non valide que le combineur peut vérifier, après le processus de génération, en utilisant la clé publique du service K (la clé publique K est supposée connue par tous les utilisateurs du service). Dans le cas où la vérification échoue, le combineur choisit un autre ensemble de t + 1 signatures 24

25 partielles. Ce processus se continue jusqu à ce que combineur construise la signature correcte du ticket Rafraîchissement proactif En plus de la cryptographie à seuil, notre service utilise également le rafraîchissement des partages pour tolérer les attaques des adversaires mobiles, et adapter sa configuration aux changements dans la structure de la grille. La notion d adversaire mobile a été initialement proposée par Ostrovsky et Yung [25] pour caractériser les adversaires qui temporairement corrompent un serveur et passent à une autre victime (e.g, sous la forme d un virus injecté dans le réseau). Pour ce modèle d adversaire, un adversaire peut être capable de corrompre tous les serveurs du service au bout d un certain temps. Bien que les serveurs corrompus, dans notre protocole, soient détectés et exclus du service, l adversaire peut continuer dans le temps à collecter plus de t sous-partages à partir de nouveaux serveurs corrompus. De cette manière, il devient capable de reconstruire la clé secrète du service et de signer des tickets invalides non reconnus comme tels. Le schéma proactif [26, 27, 28, 29, 30] est proposé pour lutter contre les adversaires mobiles. Un schéma cryptographique proactif utilise le rafraîchissement des partages. Ceci permet aux serveurs de calculer, d une façon collaborative, de nouveaux partages à partir des anciens partages sans divulguer la clé secrète du service aux serveurs de la grille. Le nouveau partage constitue également un partage ( n, t + 1) de la clé secrète du service. Après rafraîchissement, les serveurs suppriment les anciens partages et vont utiliser les nouveaux pour les signatures partielles. Les nouveaux partages sont indépendants des anciens. En effet l adversaire ne peut pas combiner les nouveaux et les anciens partages pour découvrir la clé secrète du service. Par conséquent, l adversaire est obligé de corrompre t + 1 serveurs dans le temps relatif à la période de rafraîchissement. Le rafraîchissement des partages est caractérisé par l homomorphisme suivant. Si ( s 1, s2,..., sn ) est un partage ( n, t + 1) de S 1, et ( s 1, s2,..., sn ) est un partage ( n, t + 1) de S alors ( s 1 + s1, s 2 + s 2,..., s n + s n ) est un partages ( n, t + 1) de S 1 + S 2. Si S 2 est égal 0 alors on obtient un nouveau partage ( n, t + 1) de S 1. Soit n serveurs et soit le partage ( n, t + 1) de la clé secrète S, tel que à chaque serveur i on associe le secret s i. Supposons que tous les serveurs soient corrects, le rafraîchissement des partages s effectue comme suit : premièrement, chaque serveur génère aléatoirement s 1 i, s2i,..., sni, un partage ( n, t + 1) de 0. Chaque sous-partage s ij est envoyé au serveur j à travers un lien sécurisé ; quand j obtient les sous-partages s 1 j, s2 j,..., snj, il peut calculer son ' nouveau partage à partir de ces sous-partages et de son ancien partage ( s j = s j +! = s ) i 1 ij. Le rafraîchissement des secrets doit tolérer des ensembles de sous-partages non envoyés ou erronés en provenance de serveurs corrompus. Même en présence de ces derniers, les serveurs corrects peuvent définir de nouveaux partages en utilisant les sous-partages générés par les t + 1 serveurs corrects [31,32]. n 25

26 2.4.4 Adaptation Dans notre protocole, on prévoit également le changement de la configuration de la grille dû à sa dynamicité. La variation des partages permet à notre service de changer sa configuration d un partage ( n, t + 1) à ( n ', t' + 1). De cette façon, le service peut s adapter, à la volée, au changement de la grille : si un serveur corrompu est détecté, le service doit exclure ce dernier et rafraîchir les partages. Si un serveur se déconnecte, ou un nouveau serveur se connecte, le service doit changer sa configuration en fonction de ces changements. Par exemple, on suppose que le service maintient à un instant donné le secret avec un partage ( 7,3). Si, à un certain moment, un serveur est détecté corrompu et si un autre vient de se déconnecter, le service doit changer son partage pour qu il devienne ( 5,2) au lieu de ( 7,3). Ce problème était étudié dans [33]. L idée de la solution est fondée encore sur le rafraîchissement des partages. La seule différence est que l ensemble ses serveurs génèrent et distribuent des sous partages fondés sur la nouvelle configuration du service : pour t + 1 des n anciens serveurs, chaque serveur i calcule s, s,..., s ) un partage ( n ', t' + 1) de son ( i1 i2 in' ème partage s i et distribue le sous partage s ij d une manière sécurisée au j serveur des n nouveaux serveurs. Chaque nouveau serveur peut donc calculer un nouveau partage à partir des sous partages reçus. Ce nouveau partage constitue un partage ( n ', t' + 1) de la même clé secrète du service. Notons que le rafraîchissement des partages ne change pas la clé secrète du service. Les entités de la grille peuvent continuer à utiliser la clé publique du service pour vérifier la validité des tickets. Cette propriété garde le mécanisme de rafraîchissement transparent aux membres du service, et donc permet le passage à l échelle du service. 2.5 Description des requêtes Nous décrivons dans cette partie les requêtes du protocole qui constituent une pour les utilisateurs une interface d accès au service de sécurité mis en œuvre par le protocole. sign < IDD, IDT, K p, cred > Cette demande est envoyée par un membre de la grille pour obtenir un ticket. Les paramètres mentionnés dans la requête sont générés localement par l utilisateur. IDD : un identifiant unique de la demande, il doit être unique pour chaque demande pour éviter les attaques par répétition (par exemple prendre la valeur de l horloge locale). IDT : l identifiant associé au ticket (réponse à la requête), il doit également être unique. Il va identifier le ticket dans les requêtes d invalidation et de vérification. K p : ce paramètre représente la clé publique du demandeur. La signature du ticket par la clé secrète du service certifie la clé publique. cred : ce paramètre représente les autorisations souhaités par l utilisateur. 26

27 invalidate < IDD, IDT > Cette requête est envoyée par un membre de la grille pour invalider son ticket. Cette invalidation peut être demandée, par exemple, après la modification de la paire de clés (clé publique/privée) utilisé par ce membre. Après invalidation d un ticket, les serveurs diffusent aux utilisateurs de la grille l information que le ticket dont l identifiant est IDT n est plus valide. L invalidation du ticket nécessite la possession de ce ticket : en effet le membre doit établir préalablement une confiance mutuelle avec le serveur avant d effectuer cette demande. verify < IDD, IDT, k, p cred > Cette requête est envoyée par un membre pour vérifier la validité d un ticket. Cette requête est employée dans le cas d un environnement asynchrone. Elle est envoyée à un ensemble de serveurs pour valider le contenu d un ticket (par exemple, les droits d accès encapsulé dans ce ticket). Cette requête est utilisée uniquement dans le cas d un environnement asynchrone. 2.6 Description du fonctionnement du protocole Notre service commence par un serveur central. Il définit une clé secrète S pour le service, ainsi qu une clé publique K. Le serveur peut utiliser une autorité de certification pour certifier sa clé publique auprès des membres de la grille. Le serveur tient à jours une liste des membres du service. Le serveur enregistre une clé!1 publique k i pour chaque membrei, qui lui détient la clé privée k i. Le serveur conserve également une liste des droits d accès de chaque membre de la grille. Les droits d accès associés à chaque membre du service classifient les membres de la grille en deux classes : Trusted : ces membres ont la capacité de participer dans le processus d authentification dans notre système. Ils constituent les serveurs de notre système. Chaque membre Trusted connecté au service reçoit un sous-partage de la clé secrète ainsi que la liste des membres avec leur doit d accès et la liste de leurs clés publiques. Not-trusted : ils représentent les clients de notre système. Une fois connecté au service, il est informé des membres trusted du système. Soit n le nombre de membres trusted qui sont connectés à notre système à un moment donné. Phase 1 : n < 2 t + 1 (Système centralisé) Le serveur définit un polynôme H tel que : deg( H ) = t et H ( 0) = S. Pour tout i de 1 à n, calculer ( H ( i), i). Les ( H ( i), i) représentent les sous-partages de S qui sont associés à chaque serveur i. 27

28 Si un membre j souhaite se connecter aux services de la grille, il définit une paire de!1 clés privée/publique k / k. Il envoie une requête sign au serveur. La requête est j j signée par la clé privée du membre k. La requête générée est de la forme suivante : < k j,{ sign, IDD, IDT, k j, cred}!1 k j!1 j A la réception d une demande de ticket en provenance d un membre j, le serveur vérifie si c est vraiment j en décryptant le message en utilisant la clé publique k j de j. Après une vérification réussie (déchiffrement réussi avec la clé publique), le serveur définit la classe de ce membre. Si le membre demandeur appartient à Trusted, il reçoit en plus du ticket, un souspartage ( H ( j), j), ainsi que la liste des utilisateurs avec leurs secrets et leurs droits d accès. Sinon (il ne fait pas partie de liste des Trusted), il reçoit le ticket et la liste des utilisateurs Trusted. La réponse en retour est de la forme : > < { sign, IDD, IDT, k j, cred}! 1 { IDT, k k j, cred, time} S j > En effet, la réponse est constituée de deux parties : la première est la requête source de la réponse du serveur. Elle permet au demandeur de s assurer que cette réponse est généré à partir de sa demande afin d éviter les attaques par répétition. La deuxième partie représente le ticket signé par la clé secrète du service S. Il contient un paramètre time qui représente la durée de validité du ticket. De cette façon, le serveur attribue un ticket pour l accès aux ressources de la grille et certifie la clé publique pour une requête sign effectuée. Deux membres A et B qui obtiennent leurs tickets peuvent établir une confiance mutuelle en utilisant leurs tickets. 28

29 d / k A A A + Ticket de A d / k B B A B B + Ticket B + ( 2 Nb ) k A { Na } 1 2, Nb2! 1! k A }B k { K } 1 AB, Na 2! 1! k B }A k { Nb 2,{ Nb 2}, K } K 1 AB AB! K A }B K Figure 6 : Authentification mutuelle entre A et B Après cet échange protocolaire, A et B sont chacun sûrs de l identité de l autre, il peuvent communiquer d une minière sécurisée en chiffrant les données avec la clé de session K AB. Selon le protocole décrit à la figure 7, A présente son ticket à l entité B. B vérifie la validité du ticket : elle décrypte le ticket en utilisant la clé publique du service K. Si le ticket est valide (déchiffrement réussi), B obtient l information que l entité A a comme clé publique k. Pour s assurer que c est vraiment A qui a proposé le ticket, et non pas une adversaire A!1 qui rejoue les messages, elle doit détenir la clé privée k A. B décide alors de lever un défi à l émetteur et lui propose de décrypter une nonce Nb 2 (assure la fraîcheur des messages) signé par la clé publique k A. B envoie également son ticket. Une fois A reçoit le message de B, elle doit répondre au défi en retournant à B la valeur du nonce utilisé dans son défi. De la même façon A va essayer de s assurer de l identité de B en lui levant également un défi. Une fois B voit la valeur de sa nonce du défi dans la réponse de A, elle devint sûre qu il communique à A et lui propose une clé de session K AB. De la même façon, A peut être sûre qu elle communique à B, et donc accepter la clé de session proposée K. Phase 2 : n! 2 t + 1 (Système décentralisé) Le serveur central attend que le nombre n des membres Trusted (serveurs) connectés aux système soit supérieur à 2 t + 1. Il décide alors du passage à un système décentralisé. Il communique à chaque serveur i un sous partage ( H ( i), i), la liste des utilisateurs du service, la liste des secrets et la liste des accès correspondantes. Lorsque le système passe à ce mode décentralisé, Les serveurs prennent en considérations les changements relatifs aux grilles (départ de serveurs, arrivée de serveurs, détection des serveurs corrompus ) pour s adapter à la nouvelle configuration et garder la disponibilité AB 29

30 du service. Ils adaptent le paramètre t dynamiquement en exécutant le protocole d adaptabilité expliqué en partie xxx. Bootstrap On suppose que pour pouvoir accéder au service les clients n ont pas la connaissance de tous les serveurs du système. Ils y accèdent en faisant appel à des bootstraps. Le bootstrap dans notre service, est un serveur qui est informé de l état des serveurs (serveurs corrompus, serveurs corrects ) dans une période «fenêtre de vulnérabilité», car il participe au protocole de rafraîchissement proactif des partages. Le bootstrap joue le rôle d un combineur déjà mentionné en partie xxx. De cette façon, les clients dans notre service n ont pas à gérer la liste des serveurs corrects afin de pouvoir signer un ticket. Signature d un ticket Une requête sign est effectuée de la façon suivante : Le demandeur envoie sa demande au bootstrap (les utilisateurs peuvent être informés du bootstrap à travers une page Web par exemple). Ce dernier envoie cette demande à 2 t +1 serveurs. Chaque serveur i signe la réponse en utilisant son sous-partage s i et l envoie en réponse au bootstrap. Le bootstrap regroupe les signatures partielles et génère la signature par la clé secrète S (voir annexe pour l algorithme de shoup pour la génération de signature). Le t+ 1 bootstrap peut effectuer C 2t+ 1 combinaisons afin de construire une signature. Ce nombre peut être petit si le choix de t est judicieux ( t est petit). Bootstrap Corrompu Le bootstrap choisi par le client afin de signer sa demande peut être corrompu. Ainsi le client peut ne pas avoir de réponse, ou avoir une réponse corrompue. Par conséquent le bootstrap est un ensemble de serveurs de cardinal t + 1. Le client commence par envoyer la demande à un seul bootstrap. A la réception de la réponse, il vérifie la réponse en utilisant la clé publique du service. Si la réponse est corrompue, il diffuse la demande à t + 1 serveurs. Puisque t serveurs peuvent être corrompus au maximum, au moins un serveur correct qui répond correctement à cette demande. Ainsi, toute requête sign aboutit. Le client peut recevoir également plusieurs réponses correctes, et il doit être capable de rejeter les réponses redondantes. Invalidation 30

31 Après avoir reçu un ticket, le client peut changer sa paire de clés (décision de l administrateur, détection d intrusion ), et doit ainsi invalider son ticket. Il génère une demande invalidate et l envoie à l ensemble des serveurs dans l ensemble bootstrap. Chaque serveur à la réception de cette requête diffuse la demande à tous les utilisateurs du système. Ces derniers enregistrent sur leurs disques les tickets invalides tant qu il est encore valable (sa durée de validité est encore valable). A chaque fois qu un ticket est présenté, le client vérifie premièrement la validité du champs time dans le ticket et si il est valide, ensuite il vérifie sur son disque s il n est pas déjà invalidé. Vérification Comme déjà mentionné, le choix d un t petit est judicieux car il réduit le temps et le coût de génération de la signature, ainsi que le nombre de messages échangés. Choisir un t petit peut représenter une grande faille de notre système. Nous avons proposé d introduire un mécanisme de vérification en supposant que l attaquant peut à un moment attaquer plus que t serveurs mais jamais attaquer plus de t + k tel de t < t + k < 2 t + 1. En attaquant t + 1 serveurs, le service peut être non disponible si les serveurs corrompus refusent de participer au processus de génération des signatures (signatures partielles corrompues). L adversaire peut également générer des tickets corrompus (associer des droits d accès à des entités non autorisées). L idée dans notre protocole pour résoudre ce deuxième problème (génération de signatures non valides), est vérifier la validité des informations contenues dans le ticket. Pour ce faire, le ticket est accompagné par les identifiants des serveurs qui ont participé au processus de signature. Un ticket avec t + k + 1 identifiants de serveurs est valide. (i) Le client envoie la demande de signature d un ticket à n + k + 1 serveurs de l ensemble bootstrap. (ii) Chaque bootstrap diffuse cette demande vers 2 t + 1 serveurs. (iii) Chaque serveur envoie en réponse : < tiket > si + < IDi, IDT > di (iv) (v) < tiket > s i : est la signature partielle du ticket de la demande. < ID i, IDT > d i représente l identifiant du serveur et l identifiant du ticket signé par la clé privée du serveur i. Le bootstrap génère une signature du ticket par la clé secrète du service S. En effet, il doit trouver un ensemble de signatures partielles de cardinal t + k + 1 tel que chaque sous-ensemble de taille t + 1 génère une signature correcte. Le bootstrap répond à la demande par : < IDT, k p, cred, time > S + ID1 < ID1, IDT > d... ID <, >..., 1 i IDi IDT d ID < > i t k IDt k IDT d t + k + 1 La réponse contient un ensemble de t + k + 1serveurs qui ont participé à la signature. A la réception d un ticket avec la liste des identifiants, le client doit vérifier le nombre des identifiants associés au ticket. Pour chaque serveur i dans la liste des identifiants, le client va vérifier son appartenance à la liste des Trusted. Si un serveur i n appartient pas à cette liste, alors le ticket est rejeté. Sinon il lui demande s il a vraiment participé à la 31

32 génération de la signature. Si tous les t + k + 1 serveurs confirment avoir participé dans la signature du ticket, au moins un est correct et donc le client peut être sûr de la validité du contenu du ticket. Une fois qu un ticket est vérifié valide, il est stocké dans un cache sur disque afin de ne pas répéter le processus de vérification pour le même ticket plusieurs fois. Pour le bon fonctionnement de cet outil de vérification, les clients doivent faire confiance aux tickets associés aux serveurs. En effet ces derniers ne nécessitent aucune vérification. 2.7 Asynchronisme Supposer que le système est synchrone n est pas nécessairement valide pour les grilles, à cause de la distribution géographique de ses membres, de leurs liaisons à travers l Internet, et de l hétérogénéité des processeurs (les temps de calcul sont différents sur chaque processeur). Par conséquent, toute hypothèse de synchronisme représente une vulnérabilité pour notre système : l adversaire peut lancer des attaques de type déni de service, par exemple, en déconnectant un nœud pour une longue durée, suffisante pour invalider l hypothèse de synchronisme. Ceci implique que les protocoles fondés sur un système synchrone, ne sont pas adéquats à notre environnement. Afin de réduire cette vulnérabilité, nous avons adapté notre protocole à un environnement asynchrone. Dans ce cas, il n y a pas de limite sur le temps de délivrance des messages, et sur le temps d exécutions des tâches. Rafraîchissement proactif asynchrone APSS L APSS [34] (aynchronuous proactive secret sharing) a été défini par Zhou et al. pour répondre au besoin d un protocole de rafraîchissement proactif dans un environnement asynchrone. APSS est défini pour une utilisation dans un environnement comme Internet. En effet les pannes et les attaques peuvent invalider les hypothèses liées au temps : Système asynchrone (absence d horloge globale): le temps de délivrance des messages est illimité, ainsi que la vitesse d exécution des processus. APSS restreint le nombre des processus qui échouent dans l exécution du protocole, mais ne pose pas d hypothèses sur le comportement des processeurs : Processeurs : soit n le nombre de processeur dans le système. Un processeur est correct ou corrompu (fautes byzantines). L environnement est caractérisé par l hypothèse que dans une période égale à une fenêtre de vulnérabilité, au plus t processeurs peuvent être corrompus. Afin d assurer un fonctionnement correct de APPS, il faut que l inégalité 3t +1! n soit vérifiée. 32

33 Sans faire d hypothèses sur les liens de communication, l attaquant peut processeurs de communication. Par conséquent APSS suppose : priver les Liens de communication : les liens de communication dont supposé équitables (Fair link). Ils ne délivrent pas nécessairement tout les messages envoyés, mais si un processeur envoient un message une infinité de fois à une destination, ce message est reçu au moins une fois par la destination. Les messages en transit peuvent être altérés ou détruites. Dans cet environnement, l adversaire peut : Corrompre jusqu à n 3 processeurs, Insérer de nouveaux messages, détruire, altérer, rejouer, et réordonner les messages, lancer des attaques de déni de service en retardant les messages et le temps d exécution des processeurs. En absence d une horloge globale, APSS définit la fenêtre de vulnérabilité en terme des événements et non pas en terme du temps. Le contrôle de la fenêtre de vulnérabilité par événements peut introduire un point de vulnérabilité en retardant ces événements et ce qui conduit à un élargissement de la durée de la fenêtre de vulnérabilité. Mais cette vulnérabilité est relative au modèle d adversaire choisi. APSS est plus robuste que PSS pour ces deux modèles suivants: Compromettre les serveurs est fonction du temps disponible pour l attaque Compromettre les serveurs est fonction du type du serveur (système d exploitation, application, etc.). En effet, le protocole APSS permet à résister à des attaques contre lesquelles PSS n offre pas de défense. D ailleurs, APSS permet à résister à des attaques de déni de service qui mettent en cause les hypothèses associées au système synchrone. Le protocole APSS est prouvé correct, et il assure les propriétés suivantes : APSS secret : le secret S du service n est jamais divulgué. APSS disponibilité : le secret S peut être reconstruit à partir des sous partages enregistrés sur les serveurs corrects. APSS vivacité : les adversaires ne peuvent pas empêcher la terminaison d exécution. Protocole dans un environnement asynchrone 33

34 Ce paragraphe définit des adaptations de notre protocole, liés au nouvel environnement asynchrone. Note protocole utilise le protocole APSS, ainsi son modèle est analogue à celui associé à APSS. La condition de passage d un système centralisé à un système décentralisé est la suivante : n! 3 t + 1. En absence d horloge globale, le champ time du ticket ne doit plus faire partie des paramètres. Un ticket prend alors le format suivant : < { IDT, k j, cred} S >. Ainsi, lorsque un client présente son ticket à un autre client pour accéder à sa ressource, ce dernier va vérifier la validité du ticket auprès des serveurs et la requête verify sera générée. Les serveurs doivent enregistrer les tickets qu ils ont signés partiellement afin de répondre à la demande de vérification. Les serveurs associent à chaque ticket une durée de validité (12 heures par exemple) qui représente la durée d enregistrement sur le disque avant d être supprimé. Vérifier un ticket à chaque fois il est présenté pour accéder à une ressource devient rapidement coûteux. Comme optimisation, les clients peuvent après la vérification d un ticket, lui attribuer une durée de validité locale (30 minutes, par exemple). L utilisation de ce mécanisme de vérification requiert une organisation spéciale des serveurs. En effet, supposons qu un ensemble de t + 1serveurs aient participé à la signature d un ticket. Chacun enregistre le ticket sur don disque. Lorsque le client utilise un ticket pour accéder à une ressource, celui-ci doit être vérifié. Afin de vérifier le ticket, la solution évidente, est d envoyer au bootstrap la demande de vérification, qui, à son tour va diffuser la requête vers tous les serveurs du système. La procédure de vérification se déroule comme suit : 1. Un client reçoit un ticket de la forme < IDT, k, cred >. p S 2. Le client envoie au bootstrap une requête pour vérifier le ticket. La requête est de la forme verify < IDD, IDT, k, p cred >. 3. Le bootstrap diffuse la demande à tous les serveurs du système dont le nombre est n. 4. Chaque serveur qui enregistre le ticket compare les paramètres de la requêtes avec les informations stockées localement (vérifier la clé publique, les doits d accès, etc.). si les informations sont conformes, il génère une signature partielle de la forme suivante: < IDT, OK > s. Sinon il génère la réponse suivante : < IDT, NO > i s.la i réponse est envoyé au bootstrap. 5. Le bootstrap reconstruit une signature à partir des signatures partielles. S il réussi cela veut dire que t + 1ont confirmé la validité du ticket, ce qui prouve que le ticket est valide car au moins un serveur est correct dans l ensemble de t + 1 serveurs. Le bootstrap retourne une réponse au demande : < IDT, OK > si le ticket est valide, < IDT, NO > S sinon. 6. La demande accepte le ticket s il est valide et lui attribue une durée de validité locale. Sinon, il le rejette. S 34

35 2.8 Discussion Notre protocole est fondé sur l utilisation de la cryptographie à clé public en associant à chaque membre de la grille une paire de clé public/privée. L utilisation de cette architecture pour le chiffrement assure un service sécurisé en permettant les propriétés d identification, de confidentialité, et de non répudiation. Le protocole détient une clé secrète dans laquelle tous les membres de la grille font confiance. Les tickets d accès sont signés par cette clé secrète, et l obtention d un ticket permet l accès à toutes les ressources exposées par la grille durant le temps de validité de ce ticket. Ceci assure la propriété d authentification unique par notre service. Le protocole assure également la propriété de décentralisation et de disponibilité en se fondant sur la duplication. La clé secrète est partagée par plusieurs serveurs (confiance partagée). En effet, la décision de génération de secret est effectuée par plusieurs serveurs, et le processus d identification est réalisé à travers la collaboration d un ensemble de serveurs. Le propriété de dynamicité peut être également implémenté en exploitant le protocole d adaptabilité expliqué en partie Enfin, pour assurer la propriété de résistance au facteur d échelle, autre mécanisme doivent être intégrés à notre protocole comme les mécanismes de mappage et de translation des identifiants. Le protocole que nous avons défini pour un environnement synchrone peut être implémenté dans une intragrille. En effet, cette dernière peut assurer les hypothèses relatives à l environnement nécessaire pour l exécution de notre protocole : Les ressources peuvent être interconnectées par des liens de communication sécurisés et fiables (liens point à point). Ainsi le temps de délivrance des messages peut être borné. Les processeurs sont souvent homogènes. Ainsi la définition d une borne pour la vitesse d exécution est possible. Le domaine de sécurité de l intragrille est géré par une organisation unique. Il est maîtrisé par les administrateurs de cette organisation. Ces derniers ont une connaissance globale de l architecture de la grille. Par conséquent, l administrateur peut définir les paramètres du protocole (calculer la durée de la fenêtre de vulnérabilité). Puisque le nombre des membres dans une intragrille est limité, la gestion des droits d accès peut être confiée aux serveurs. Les serveurs gèrent l accès pour toutes les ressources de l intragrille et donc une liste d autorisation doit être définie sur ces serveurs. Les clients ne conservent localement aucune liste d accès. En effet, le rôle associé au client après la phase d authentification (le rôle est représenté dans le champ cred du ticket) sera valable pour tout accès aux ressources exposées par l intragrille. Dans un environnement d extragrille ou d intergrille, les ressources sont partagées via le réseau Internet. L utilisation de notre protocole en environnement asynchrone est indispensable afin de ne pas mettre en cause les propriétés de sécurité. Le nombre d utilisateurs dans ce type de grille peut dépasser des milliers, et donc le serveur ne doit pas avoir à gérer ce grand nombre d utilisateurs avec leurs droits d accès. L utilisation de proxy et de mécanismes de délégation peut apporter une solution dans ce genre d architecture. 35

36 3 Vérification des protocoles de Sécurité Dans cette partie, nous nous intéressons à la validation de notre protocole de sécurité. Nous commençons par définir les propriétés de sécurité que doit satisfaire un protocole de sécurité. Ensuite nous entamons les outils et les techniques utilisées pour vérifier et valider les protocoles cryptographiques, et nous terminons par l application de ces outils sur notre protocole. 3.1 Introduction La justesse des protocoles cryptographique dépend à la fois des algorithmes de chiffrement et des messages échangés entre les différentes entités participantes à un protocole. En effet, de nombreuse failles ont été découvertes sur des protocoles qui ont été définis fiables pour de longues années. L étude logique du fonctionnement global du protocole est difficile à mener sans appel à des méthodes spécifiques. Il est particulièrement délicat de pouvoir cerner les différents échanges de messages possibles et les différents scénarios de communication possibles. Parfois la sécurité est un sujet sensible pour quelques applications. Ainsi, les protocoles cryptographiques utilisés par ce genre d application nécessitent une vérification systématique du système, ainsi qu une preuve formelle qui garantit la validité du protocole et la justesse des tests effectués. C est à ce niveau que les méthodes de vérification formelle ont été appliquées aux protocoles cryptographiques. La littérature des méthodes de vérification distingue quatre classes de méthodes formelles appliquées à la vérification des protocoles cryptographiques. Il s agit de l utilisation des logiques modales [36, 37, 38, 39, 40], le model-checking [41, 42, 43], l algèbre de processus [9], [10] et les méthodes de démonstration automatique générales. Dans le cadre notre stage, nous nous intéressons qu à la logique modale et au model-checking. 3.2 Propriétés de sécurité Le but de ce cette partie est de faire une liste (non exhaustive) des propriétés de sécurité. Un protocole de sécurité doit assurer les propriétés suivantes : Authentification : l authenticité permet au récepteur de s assurer de l identité de l émetteur. Ce service est aussi appelé identification. Un protocole d authentification doit assurer les points suivants : 1) Si A et B sont honnêtes : si A est capable de s authentifier auprès de B, B doit accepter l identité de A. 2) B ne peut pas réutiliser l information remise par A pour s identifier en tant que A auprès de C. 3) La probabilité qu une tierce entité C réussisse à se faire passer par A auprès de B est négligeable. 36

37 4) Le point 3) reste vrai même si : C a observé un grand nombre (polynomial) d instances du protocole d identification entre A et B C a participé à des exécutions précédentes du protocole d identification auprès de A ou (non exclusif) B. plusieurs instances du protocole peuvent s exécuter simultanément sans compromettre le processus d identification. Contrôle d accès : cette propriété vise à éviter toute utilisation non autorisée des ressources du système. Confidentialité des données : la confidentialité des données consiste à faire en sorte que seul le destinataire légitime puisse comprendre et analyser le contenu du message. Elle permet également à empêcher toute analyse significative du flux d informations échangées. En effet, l intrus ne doit théoriquement avoir aucune information lui permettant de tirer des conclusions quant aux messages échangées. Secret : ce service doit assurer la préservation du secret des informations sensibles. La préservation de secret est une condition de justesse de plusieurs protocoles cryptographiques. Dans le cas de notre protocole par exemple, le service repose sur le fait que la clé secrète du service S demeure un secret partagé entre les serveurs. D un autre côté la clé de session définie lors d une authentification mutuelle entre deux membre A et B doit rester secrète tout au long de la durée de la session. Intégrité des données : ce service assure que le message parvient au destinataire sans être modifié ou altérer. Non répudiation : la technique de non répudiation vise à ce que les émetteurs soient responsables de leurs messages et ne puissent pas nier les avoir émis. Ainsi, le destinataire ne pourra jamais nier l arrivée d un message qu il a réellement reçu. Disponibilité : la propriété de disponibilité concerne la prévention d'un déni d'accès non autorisé à l'information ou à des ressources. Un adversaire peut lancer des attaques de type déni de service pour empêcher par exemple le processus d authentification d un participant honnête au protocole. L utilisation de la cryptographie à clé publique (supposé sécurisée) assure dans notre protocole les propriétés de confidentialité, intégrité, et non répudiation. Dans le travail qui suit, nous nous intéressons à discuter les propretés d authentification, secret, et de disponibilité. Nous commençons tout d abord par décrire les méthodes et les outils de vérification, ensuite nous décrivons leurs utilisations dans le cadre de notre protocole. 37

38 3.3 Modèle de vérification L étude des protocoles cryptographiques commence donc par une première étape de modélisation. Depuis quelques années, de nombreux modèles dédiés aux protocoles se sont développés Logique Modale BAN L utilisation des logiques modales comme outil d analyse et de vérification des protocoles cryptographiques a été proposé initialement par la logique BAN Burrows, Abadi et Needham [36]. L idée est de proposer un outil logique qui permet de modéliser les actions des différents acteurs d un protocole cryptographique donné. Une fois modélisé, le protocole est analysé afin de tirer des conclusions relatives aux connaissances et croyances des différents acteurs. Les protocoles analysés subissent une transformation initiale qui n est autre qu une représentation du protocole par un ensemble de formules logiques concernant les messages échangés. La logique modale propose généralement un ensemble de règles d expression et de procédés de reconnaissance des formules correctes. La logique de BAN repose sur les croyances «belief». Son objectif est d évaluer les croyances que devrait avoir chaque participant à l issue de l exécution du protocole. Nous allons détailler par la suite la logique de BAN, car nous utiliseront pour évaluer les croyances entre les participants dans notre protocole. La logique d authentification BAN La logique BAN a été proposée en 1990 comme une logique d authentification pour l analyse des protocoles cryptographiques. Le protocole à analyser subit une transformation initiale qui consiste à l exprimer sous forme de formules logiques relatives aux messages échangés par les différents utilisateurs légitimes du protocole. La logique BAN est une logique de la croyance. Elle permet de décrire les propositions que les agents tiennent à partir d'un protocole. Par exemple, Alice peut parvenir à croire qu'une clé qu'elle a reçue du protocole est une bonne clé de session pour communiquer avec Bob. Si Bob atteint ce même état de croyance, alors on peut affirmer que l'authentification est réussie, mais cette logique nécessite des hypothèses qui définissent des croyances associées aux agents avant le début de l échange protocolaire. Notations et règles de BAN BAN utilise les notations et les règles suivantes: Dans toutes ces expressions, X est soit un message, soit une formule. Voici les expressions du langage BAN 38

39 Symboles Signification A, B, S, P, Q, R Participants légitimes du protocole. K ab, K as, K bs Clés secrètes partagées entre les participants indiqués en indice. K a, K b, K s Clés publiques respectivement de A, B et S.! 1! 1! 1 K a, Kb, K s Clés privées respectivement de A, B et S. N a, N b, N c Formules particulières représentant des noces. P X Le participant P croit que le message/formule X est vrai(e). P X P a reçu X qui a été envoyé sur le réseau par un participant quelconque. P peut donc rejouer X. P a envoyé un message contenant X, aucune information quant à la P ~ X fraîcheur du message ne peut être déduite, le message contenant X aurait bien pu être envoyé par P durant une session antérieure d exécution du protocole. Le participant P a une juridiction sur X. P X Typiquement, les serveurs de clés ont juridiction sur les clés qu ils génèrent. La formule (message) X est fraîche, autrement di, elle n a fait partie #(X) d aucun message émis avant le début de la session actuelle de communication. P K! Q La clé K est une clé secrète partagée par P et Q. K a P K est une clé publique du participant P. X est un secret partagé par les participants P et Q. P Q P et Q sont les seuls participants pouvant utiliser X pour prouver leur identité. {X} K Cryptogramme représentant X chiffré avec la clé K. X Y X combiné avec Y. Y étant un secret prouvant l indenté de l émetteur de XY. Table 2 : Notations utilisées dans la logique de BAN Critiques et limites de la logique BAN La logique BAN a été définit pour formaliser la vérification de la validité des protocoles d'authentification. Cette logique a subi de nombreuses critiques. En 1990, Nessett a proposé le protocole suivant afin de montrer les faiblesses de l'analyse BAN. 1. A B: {Na, Kab}Ka 2. B A: {Na}Kab 39

40 Le Protocole Nessett (1990) Dans le premier message, Alice chiffre une clé de session en utilisant sa clé privée (dont la clé publique est supposée accessible à tous). Bob lui envoie en retour la valeur Nb chiffrée avec cette clé de session. Bien sûr, cette clé de session n'est pas bonne pour les communications entre Alice et Bob, car tout le monde peut l'extraire à partir du message d'alice. Mais la dérivation des croyances de chaque entité à l'aide de la logique BAN mène à la conclusion que ce protocole est un bon protocole d'authentification. C'est bien grâce à l'hypothèse initiale A! B que le protocole Nessett peut être validé par une analyse BAN. Ainsi, relativement au protocole à vérifier, des hypothèses supplémentaires doivent être décrite et qui peuvent pas être retirées à partir du protocole dans la phase d idéalisation- phase de transformation du protocole-. Ce protocole définit par Nessett a eu trois effets : A Kab (i) (ii) montrer les limites et la portée réelle des outils logiques encourager le développement de nouvelle logiques plus expressives, qui en outre de la validation de l authentification, s intéressent à autres propriétés de la sécurité (secret, confidentialité, ) Model checking Le modèle checking à la différence avec BAN, introduit à son modèle l existence d un intrus. L utilisation du model checking pour la vérification d un protocole cryptographique consiste à représenter ce protocole sous forme d un ensemble d états et d un ensemble de règles de transitions qui prennent en considération la présence des adversaires. La modélisation d un protocole en model checking est constituée de l ensemble des messages échangés entre les participants du protocole, ainsi que les connaissances initiales des participants légitimes (les clés publiques, les secrets partagés, etc.). L exécution du modèle consiste à rechercher les attaques possibles sur un protocole. En effet, l espace des états est parcouru pour vérifier la possibilité d atteindre un état où les propriétés de sécurité ne sont pas satisfaites. En arrivant sur cet état, l exécution retourne une trace de l exécution, et qui représente une attaque sur ce protocole. La vérification d un protocole cryptographique en utilisant le modèle checking s effectue de la façon suivante. Le protocole à vérifier est décrit dans une spécification qui représente les entités participantes dans le protocole, les connaissances de chaque entité, les messages échangés durant ce protocole, les propriétés de sécurité à vérifier, ainsi que les capacités de l intrus dans ce modèle. L analyseur prends la spécification du protocole et construit le modèle d états associé à ce protocole. Parmi ces états, il y a un état où les propriétés de sécurité ne sont pas satisfaites. L analyseur effectue des recherches et essaye de trouver une exécution qui mène à cet état d insécurité. L exécution consiste à choisir un état initial et faire les transitions d un état à un autre en fonction des messages échangés et de l évolution des connaissances des participants. Si une exécution qui mène à état d insécurité est détectée, le système est considéré non sécurisé. Dans le cas contraire, l analyseur confirme qu il n y a aucune séquence d exécution possible qui permet d atteindre cet état d insécurité. Ceci veut dire que l analyseur ne détecte 40

41 aucune attaque sur le protocole. Ce résultat reste relatif au modèle utilisé et ne constitue pas une garantie pour la sécurité du protocole. En effet en absence d une preuve formelle de la sécurité du protocole, une vérification de la validité par model-checking reste apprécié, car les failles de sécurité les plus répondus sur les protocoles cryptographique étaient détectés en utilisant les outils de model-checking. Plusieurs modèles ont été définis pour la vérification des protocoles cryptographiques. L un des premiers modèle était le modèle de Dolev et Yao [43], suivi par autres modèles qui introduisait des extensions et des améliorations à leur modèle, par exemple le modèle de Meddew [42] et le modèle CSP [44]. L utilisation de ces modèles nécessite la traduction du protocole en une spécification relative au modèle choisit. En effet, la description du protocole requiert une bonne maîtrise des notations et des règles employées par le modèle. Afin de rendre l utilisation de ces modèles plus simple et plus accessible aux utilisateurs, plusieurs outils ont été développés. Ces outils permettent à leurs utilisateurs de décrire leurs protocoles dans une description académique (la littérature employée pour décrire les protocoles cryptographiques), et générer une spécification formelle du protocole que l analyseur va utiliser pour effectuer la vérification. Nous énumérons par la suite quelques outils utilisés dans la communauté scientifiques, qui utilisent le model-checkin pour vérifier les protocoles cryptographiques. Casper/FDR [45] Cet outil a été développé pour vérifier les protocoles décrits en CSP (algèbre de processus). Le nombre de sessions et de participants est borné, la taille des messages est également bornée. La vérification du protocole correspond alors au modelchecking d un modèle fini. La principale difficulté est le traitement de l explosion du nombre d états lorsqu on considère plusieurs sessions par exemple. C est en particulier le modelchecking avec FDR du protocole de Needham-Schroeder [48] qui a permis à G. Lowe de trouver son attaque sur ce protocole puis d en proposer une nouvelle version. Mur L outil Mur [46] est assez proche de Casper. Il traite lui aussi des protocoles avec un nombre de sessions et une taille des messages bornés. De même, les messages sont typés. Le modèle utilisé suppose de plus que l intrus a une mémoire finie. Cependant, cet outil n est pas uniquement dédié à la vérification des protocoles cryptographique. Il peut également vérifier la «cohérence de cache» de protocoles (pas nécessairement cryptographiques). Casrul L outil Casrul [47] permet également de chercher des attaques pour un nombre de sessions et de participants borné. Les protocoles sont décrits sous forme de règles de réécriture. CASRUL retrouve ainsi de nombreuses attaques sur les protocoles cryptographiques. 3.4 Vérification du protocole Authentification Dans ce paragraphe, nous vérifions la propriété d authentification de notre protocole en utilisant la logique d authentification de BAN. En effet nous allons montrer que l échange décrit par la suite entre deux membres A et B, garantit une authentification mutuelle. 41

42 L échange protocolaire décrit au dessus représente la phase1 de notre protocole. Il est constitué de trois entité, le serveur central S et deux membres A et B. A! S : A, k A,{N, A, k } 1. a A 1 1 k Ā 2. S! A : A,k A,{Na, A,k 1 A, cred } K S B " S : B, k B,{N, B, k }! 1 k B 3. b B 1 S! B : A,k,{N, B,k, cred} 4. B b1 B K S A! B : N, A,, cred 5. { a k 1 A }S K B! A : N b, B,k,cred,(Nb ) K 6. { } 1 B 2 k A S A " B :{ Na 1 2, Nb2! 1! k A }B { k B " A : K 1 AB, Na 2! 1! k B }A { k A " B : Nb2, Nb2, K } K 1 AB AB! k A}B k 7. { } 8. { } 9. { } Les variables Na1 et Nb1 sont des nonces (ils représentent des instances du paramètre IDT représenté dans la description du protocole en partie xxx). Les Na2 et Nb2 sont également des nonces, et ils sont utilisés pour assurer la fraîcheur des messages. k, représentent respectivement les clés publiques de A et B. A k B!1 A, k!1 B k, K S représentent respectivement les clés privées de A, B et S. K AB représente une clé de session qui sera utilisé pour chiffrer les communication entre A et B. La vérification de l authentification mutuelle entre A et B par l utilisation de BAN revient à monter que A et B chacun croit à l identité de l autre, ainsi qu à la clé de session K AB forgée entre les deux. Montrer cette propriété est équivalent à montrer les propriétés suivantes : A # K B # K AB AB (1) 42

43 Ces deux propriétés permettent aux deux entités A et B à croire dans la nouveauté de la clé K. AB A B B A K A AB! B A B K AB K A AB! B B A K AB (2) Ceci revient à monter que A croit que B croit en K AB. K AB, ainsi que B croit que A croit en A B K A AB! B A K AB K A AB! B B K AB (3) Les deux entités A et B croient le secret Démonstration : K AB Hypothèse : Notre service est basé sur la confiance dans la clé secrète su service. Par conséquent A et B croient dans la clé secrète K du serveur S. Et donc : K S K S A! S et B! S A partir des message 5 et 6 dans le protocole, on peut retirer que : A S K A K B! A et B S! B On a également: A K A K B! A et B! B S Monter (1) : B # K AB car c est B qui a proposé K AB dans le message 7. Montrons alors que A # K AB À partir du message 8 dans l échange protocolaire: A {{(Na! 1, K }! K A K B 2 AB } K K Puisque A! A, et A! B (cette propreté (3) il sera démontré dans la suite), Alors A ( Na 2! 1, K AB ). A fait confiance dans la fraîcheur de Na 2 (car c est A qu elle a proposée) et donc A # Na 2, d où A # K AB Montrer (2): Afin de montrons (3), montrons d abord que : 1 B A 43

44 B A K A! A. K B! B. A partir du message 5, on peut retirer que B {Na 1A,k A, cred}! 1 puisque B! S K S alors B S ~ {Na1 A,k A, cred} équivalent à dire que : K A B S ~! A (cette équivalence est retirée du fait que les utilisateurs du protocole ont connaissance des éléments d un ticket. En effet, ils savent que le champ K p dans le ticket représente la clé publique). Puisque B S K A K A! A donc B! A. D une manière similaire (message 6) on montre que : A! B. K B K S Montrons maintenant que A B K AB et B A K AB A partir du message 8 on a: A {K, Na!! 1, puisque A! B alors A B ~ K AB AB 2 1} K B à partir de la propriété de fraîcheur (1) A # K AB on obtient que : A B K AB A partir du message 9, et de la même façon on peut trouver B A K AB K B Monter (3) : Montrer A K AB et B K AB. C est B qui a proposé K AB, et donc B croit en K AB B K AB. En plus A B K AB du message 8, on a donc A B ~ K AB d où A K AB Cette démonstration prouve que la propriété d authentification mutuelle est assurée par notre protocole dans sa phase1. Cette propriété reste également garantie par notre protocole en passage à sa phase2. En effet, la clé secrète du service devient distribuée sur plusieurs serveurs, mais ce changement n implique aucun changement dans le processus d authentification. Les utilisateurs continuent à voir le service comme un seul serveur qui signe leurs tickets, et l échange protocolaire nécessaire pour l établissement de l authentification mutuelle ne subit aucun changement. 44

45 3.4.2 Secret La démonstration de la propriété d authentification a été faite sur l hypothèse que les utilisateurs font confiance dans la clé secrète du service. Ainsi, il est indispensable de vérifier que le secret (clé secrète du service) reste protégé, et que l attaquant n arrive pas à divulguer ce secret durant l exécution de notre service. Les protocoles utilisés pour le partage de la clé secrète (en environnement synchrone ou asynchrone) sont théoriquement sécurisés et assure la propriété du secret. Dans cette partie, nous allons utiliser le model checking de vérifier si les propriétés de sécurité (secret, authentification) sont assurées en présence d un modèle d adversaire. Plusieurs outils se présente pour la vérification des protocoles de sécurité. Nous avons choisit l utilisation de Casper et Carsul comme outils de vérification de notre protocole. Bien que Casper a quelques limites (nombre de session borné, nombre d état limité, etc.), ce dernier était choisit pour la richesse de son langage, capable de décrire des protocoles plus complexes (phase2 de notre protocole). Nous avons également vérifié la phase1 de notre protocole avec l outil Carsul. Notre protocole a été vérifié par succès par les deux outils (en phases1 utilisation de Casper et Carsul, et Casper pour la phase2). Aucune attaque n a été détectée sur notre protocole en utilisant ces outils de vérification. La description de notre protocole dans les langages associés à ces outils est représentée dans partie annexe Disponibilité Notre service essaye d offrir un service disponible en utilisant la réplication. L adaptation de notre protocole à un système asynchrone offre également plus de disponibilité à notre service en luttant contre les attaques de déni de service. Les entités corrompues représentent une vulnérabilité pour la propriété de disponibilité de notre service. La détection et l élimination des membres corrompus dans notre service (serveurs ou clients corrompus) est équivalent à l augmentation de la disponibilité. En effet, l implémentation d un service de recouvrement sur chaque membre de notre service offre plus de disponibilité. Ce service peut s exécuter périodiquement : recharger le code à partir d une source sécurisé (une source en lecture seule par exemple) afin d éliminer les programmes de type cheval de Troie reconstruire l état de chaque membre de la grille. ne plus utiliser les informations confidentielles utilisées avant le recouvrement. 45

46 4 Conclusion Dans cette parie, nous présentons un résumé des réalisations que nous avons proposées pour la conception d un service qui permet un accès sécurisé aux ressources de la grille. Nous présentons ensuite quelques perspectives qui pourraient être amenées dans des travaux postérieures. 4.1 Bilan L interet des grille. Les solutio existant pour permettre la sécurité : utilsation des relation de confiance, hypothése d une architecture statique, prposer un protocle qui assure les propriée de. Dans ce rapport, nous avons présenté notre protocole qui permet un accès sécurisé aux ressources d une grille. Ainsi, nous avons défini les propriétés que doit ssatisfaire notre protocole, et qui sont imposés par l environnement de la grille. Nous avons décrit les hypothèses relatives à l environnement de l exécution, ainsi qu une description détaillée des requêtes supportées par notre protocole. Nous avons commencé par une description du protocole dans un environemement synchrone, suivi d une adaptation de l utilisation du protocole dans un environnement asynchrone. En suite une phase de vérification du protocle est présentée. En effet, nous avons prouvé formellement la propriété d authentification en utilisant la logique BAN, ainsi que nous avons vérifié l absence d attaques sur notre protocole en utilisant le model checking par le biais des outils CASPER et CARSUL. 4.2 Perspective Nous supposons que de possibles études peuvent être mené sur notre travail. Ces travaux peuvent étudier les point suivants : Une preuve formelle de la corectness du protocole. Une implémentation et évaluation de performance. Introduction des mécanismes de délégation, de mappage et de translation. Minimisation des nombre de messages échangés en bien structurant le groupes de serveurs. 46

47 5 Référence [1] V. Berstis. Fundamentals of Grid Computing, IBM Red paper, October [2] I. Foster and C. Kesselman, eds. The Grid: Blueprint for a Future Computing Infrastructure, Morgan Kaufmann, San Francisco, [3] M. Chetty and R. Buyya. Weaving electrical and computational grids: How analogous are they?. Computing in Science and Engineering, May/June [4] V. Berstis et al. Introduction to Grid Computing with Globus. IBM RedBook, December [5] I. Foster, What is the Grid? GRIDSTART Technical Newsletter, March [6] M. Baker, R. Buyya, D. Laforenza. Grids and Grid Technologies. Wide-Area Distributed Computing, International Journal of Software: Practice and Experience (SPE), Volume 32, Issue 15, Wiley Press, USA, Nov [7] I. Foster and C. Kesselman. Globus: A Metacomputing Infrastructure Toolkit. Intl J. Supercomputer Applications, 11(2): , [8] Rundy Bulter, Von Welch, Douglas Engert, Ian Foster, Steven Tuecke, Johon Volmer, and Carl Kesselman. A National-Scale Authentication Infrastructure. IEEE Computer, 33(12):60-66, December [9] R. Lock. An Introduction to the Globus Toolkit. Lancaster University, February [10] Grimshaw, A. S., Wulf, W. A., French, J. C., Weaver, A. C., Reynolds, P. F. Jr. Legion: The Next Logical Step Toward a Nationwide Virtual Computer. Tech. Rep. CS , Dept. of Computer Science, Univ. of Virginia, [11] Lewis, M. J., Grimshaw, A. S. the Core Legion Object Model. Proc. of the 5th Intl. Symp. On High Performance Distributed Computing, August [12] Mike Lewis and Andrew Grimshaw, "The Core Legion Object Model," Proceedings of the Fifth IEEE Conference on High Performance Distributed Computing, pp , Syracuse, NY, August [13] E. Belani, A. Vahdat, T. Anderson, and M. Dahlin. The CRISIS wide area security architecture. In Usenix Security Symposium, January [14] Y.Fu, J. Chase, B. Chun, S. Schwab, and A. Vahdat. SHARP: An Architecture for Secure ResourcePeering. ACM conference on Computer and Communication Security, December

48 [15] David Maziére, Michael Kaminsky, M.Frans Kaashoek. and Emmet Witchel. Separiitng th Key Management from File System Security. In Proceding of the 17 ACM Symposium on Operating System Principles (SOSP), pages , December [16] A. Adya, W. Bolosky, M. Castro, G. Cermark, R. Chaiken, J. Douceur, J.Howell, J.Lorch, and R.Wattenhofer. Farsite: Federated, Available, and Reliable Storage for an th Incompletely Trusted Environnement. In Proceding of the 5 ACM Symposium on Operating System Design and Implementation, December [17] I.Foster, C. Kesselman, G.Tsudik, and Tuecke. A security Architecture for Computational Grids ACM conference on Computer and Communication Security. [18] RSA [19] T. Dierks and C. Allen. The TLS protocol, IETF RFC Jan [21] J.Steiner, B. Neuman, and J.Schiller. Kerberos: An Authentication System for open Network System. In Usenix Conference Proceedings, pages [22] DES [23] Y. Desmedt. Threshold cryptography. European Transactions on Telecommunications, 5(4): ,July August [24] Y. Desmedt and Y. Frankel. Threshold cryptosystems. In G. Brassard, editor, Advances in Cryptologypto 89, the 9th Annual International Cryptology Conference, Santa Barbara, CA USA, August 20 24,1989, Proceedings, volume 435 of Lecture Notes in Computer Science, pages Springer, [25] R. Ostrovsky and M. Yung. How to withstand mobile virus attacks. In Proceedings of the 10th Annual Symposium on Principles of Distributed Computing (PODC 91), pages 51 59, Montreal, Quebec, Canada, August 19 21, ACM. [26] S. Jarecki. Proactive secret sharing and public key cryptosystems. Master s thesis, Department of Electrical Engineering and Computer Science, Massachusetts Institute of Technology, Cambridge, MA USA, September [27] A. Herzberg, M. Jakobsson, S. Jarecki, H. Krawczyk, and M. Yung. Proactive public-key and signature schemes. In Proceedings of the 4th Annual Conference on Computer Communications Security, pages , Zurich, Switzerland, April 1 4, ACM. [28] A. Herzberg, S. Jarecki, H. Krawczyk, and M. Yung. Proactive secret sharing or: How to cope with perpetual leakage. In D. Coppersmith, editor, Advances in Cryptology Crypto 95, the 15th Annual International Cryptology Conference, Santa Barbara, CA USA, August 27 31, 1995, Proceedings, volume 963 of Lecture Notes in Computer Science, pages Springer,

49 [29] Y. Frankel, P. Gemmel, P. MacKenzie, and M. Yung. Optimal resilience proactive publickey cryptosystems. In Proceedings of the 38th Symposium on Foundations of Computer Science, pages , Miami Beach, FL USA, October 20 22, IEEE. [30] Y. Frankel, P. Gemmell, P. MacKenzie, and M. Yung. Proactive RSA. In B. S. Kaliski Jr., editor, Advances in Cryptology Crypto 97, the 17th Annual International Cryptology Conference, Santa Barbara, CA USA, August 17 21, 1997, Proceedings, volume 1294 of Lecture Notes in Computer Science, pages Springer, [31] T. Pedersen. Non-interactive and information-theoretic secure verifiable secret sharing. In J. Feigenbaum, editor, Advances in Cryptology Crypto 91, the 11th Annual International Cryptology Conference, Santa Barbara, CA USA, August 11 15, 1991, Proceedings, volume 576 of Lecture Notes in Computer Science, pages Springer, [32] P. Feldman. A practical scheme for non-interactive verifiable secret sharing. In Proceedings of the 28 th Annual Symposium on the Foundations of Computer Science, pages IEEE, October 12 14, [33] Y. Desmedt and S. Jajodia. Redistributing secret shares to new access structures and its applications. Technical Report ISSE TR-97-01, George Mason University, July [34] L. Zhou, F. Schneider, F. B., and R. Van Renesse. Proactive Sercret Sharing for Asynchronuous systems. Submitted to ACM Transactions on Information and System Security. [35] V. Soup. Practical threshold signatures, in Proc. Eurocrypt 00, page Springer- Verlag.2000 [36] M.Burrows, M.Abadi and R.Needham. A logic of authentication. ACM transactions on Computer Systems, 8(1): 18-36, February 1990 [37] M.Burrows, M.Abadi, and R.M.Needham.The scope of a logic of authentication Revised Research Report 39 Digital Systems Research Center 1994 [38] S.Einar. Exploring the BAN approach to protocol analysis. In IEEE Symposium on Security and Privacy 1991 [39] S.Gurgens, SG logic - A formal analysis technique for authentication protocols In the International Workshop on Security Protocols, Paris, France, April Springer Verlag Lecture Notes in Computer Science 1361 [40] Michiharu and M.Anish. An extended logic for analyzing timed release public key protocols 1997 available from the author at [email protected] and [email protected] [41] W.Marrero, E.M.Clarke, and S.Jha. Model checking for security protocols Technical Report CMU_SCS Carnegie Mellon University, May 1995 [42] C.Meadows. Using narrowing in the analysis of key management protocols.in Proceedings of the IEEE Symposium on Research in Security and Privacy. Pages , 49

50 Oakland, CA, May 1989.IEEE Computer Society, Technical Committee on Security and Privacy, IEEE Computer Society Press. [43] D. Dolev and A.C. Yao. On the security of public key protocols. In roceedings of the 22nd Symp. on Foundations of ComputerScience, pages , Nashville,Tennessee, USA, IEEE Computer Society Press. [13] I. Cervesato, N. Durgin, P. Lincoln, J. Mitchell, and A. Scedrov. A meta-notation for protocol analysis. In Proceedings of the 12th IEEE Computer Security Foundations Workshop (CSFW 99), pages 55 69, Mordano, Italy, IEEE Computer Society Press. [44] A. W. Roscoe. Model-checking CSP. In A Classical Mind, Essays in Honour of C. A. R. Hoare. Prentice-Hall, [45] Gavin Lowe. Casper: a compiler for the analysis of security. Technical report, University of Leicester, UK, July [46] J. Mitchell, M. Mitchell, and U. Stern. Automated analysis of cryptographic protocols using murphi. In Proceedings of the IEEE Symposium on Security and Privacy, pages IEEE Computer Society Press, May [47] F. Jacquemard, M. Rusinowitch, and L. Vigneron. Compiling and verifying security protocols. In Logic for Programming and Automated Reasoning (LPAR 00), volume 1955 of Lecture Notes in Computer Science, November [48] R.Needham and M.Schroeder. Using encryption for authentication in large networks of computers. Communication of the ACM, 21(12): ,

51 6 Annexe La description du protocole phase1 en langage HLPSL [ ]qui sera vérifié par l outil Casper : -- phase1 protocol #Free variables A, B : Agent S : Server tb1, ta1,tb2, ta2 : TimeStamp kab : SessionKey SKey : Agent -> PrivateKey PK : Agent -> PublicKey InverseKeys = (SKey,SKey), (kab,kab) #Processes INITIATOR(A) knows SKey(A),PK INITIATOR(B) knows SKey(B),PK RESPONDER(S) knows SKey(S),PK RESPONDER(B) knows SKey(B),PK #Protocol description 0. -> A : B [B!= A] 1. A -> S : A,PK(A), {ta1, A, PK(A)}SKey(A) 2. S -> A : A,{ta1, A, PK(A)}SKey(S) 3. B -> S : B,PK(B), {tb1, B, PK(B)}SKey(B) 4. S -> B : B,{tb1, B, PK(B)}SKey(S) 5. A -> B : {ta1, A, PK(A)}SKey(S) 6. B -> A : {{tb1, B, PK(B)}SKey(S), tb2}}pk(a) 7. A -> B : {{ta2,tb2 }SKey(A)}PK(B) 8. B -> A : {{ta2,kab }SKey(B)}PK(A) 9. A -> B : {{ta2,kab }SKey(A)}PK(B) #Specification NonInjectiveAgreement(A,B,[kab]) Agreement(A,B,[kab]) #Actual variables TimeStamp = MaxRunTime = 0 Alice, Bob, Intrus : Agent 51

52 server : Server Kab : SessionKey InverseKeys = (Kab,Kab) #Functions symbolic SKey #System INITIATOR(Alice, Bob, server) RESPONDER(Bob) ; RESPONDER(Bob) SERVER(server) #Intruder Information Intruder = Intrus IntruderKnowledge = {Alice, Bob, Intrus, sever, SKey(Intrus), PK} La description du protocole phase1 en langage HLPSL [ ]qui sera vérifié par l outil Casper : -- phase2 protocol #Free variables A, B : Agent S[1..n] :Server C : combiner tb1, ta1,tb2, ta2 : TimeStamp t,n,i : Number kab : SessionKey Ks : ThresholdKey; SKey : Agent -> PrivateKey PK : Agent -> PublicKey TK : Agent -> ThresholdKey(n,t+1) InverseKeys = (SKey,SKey), (kab,kab) #Processes INITIATOR(A) knows SKey(A),PK INITIATOR(B) knows SKey(B),PK RESPONDER(B) knows SKey(B),PK for i:=1 to n RESPONDER(S[i]) knows SKey(TK(S[i])), PK Combiner(C,S) #Protocol description 0. -> A : B [B!= A] 1. A -> C : A,PK(A), {ta1, A, PK(A)}SKey(A) 2. C -> A : A,{ta1, A, PK(A)}SKey(S) 3. B -> C : B,PK(B), {tb1, B, PK(B)}SKey(B) 4. C -> B : B,{tb1, B, PK(B)}SKey(S) 52

53 5. A -> B : {ta1, A, PK(A)}SKey(S) 6. B -> A : {{tb1, B, PK(B)}SKey(S), tb2}}pk(a) 7. A -> B : {{ta2,tb2 }SKey(A)}PK(B) 8. B -> A : {{ta2,kab }SKey(B)}PK(A) 9. A -> B : {{ta2,kab }SKey(A)}PK(B) #Specification NonInjectiveAgreement(A,B,[kab]) Agreement(A,B,[kab]) #Actual variables TimeStamp = MaxRunTime = 0 Alice, Bob, Intrus : Agent server[1..n] : Server combiner : Combiner Kab : SessionKey InverseKeys = (Kab,Kab) #Functions symbolic SKey #System INITIATOR(Alice, Bob) RESPONDER(Bob) ; for i:=1 to n SERVER(server[i]) #Intruder Information Intruder = Intrus IntruderKnowledge = {Alice, Bob, Intrus, SKey(Intrus), PK} for i:=1 to n IntruderKnowledge = {server[i]} La description du protocole phase1 en langage HLPSL [ ]qui sera vérifié par l outil CASRUL : %% Protocolephase1.hlpsl Protocol Test ; Identifiers A,B,S: user; ka, kb: public_key; Kab: symmetric_key; Na1,Na2, Nb1,Nb2 : number; Knowledge A: B, S, Ka, Ka, ks; %% Ka' est la clé privée de A B: B, S, Kb, Kb, Ks; 53

54 S: B, B, Ka, Kb, Ks, Ks ; Messages 1. A ->S: A, ka, {Na1,A,Ka}ka 2. S ->A: A, {Na1,A,Ka}Ks 3. B ->S: B,kb, {Nb1,B,Kb}Kb 4. S ->B: B,{Nb1,B,Kb}Ks 5. A ->B: A, {Na1A,Ka}Ks 6. B ->A: B, {Nb1,B,Kb}Ks, {Nb2}Ka 7. A ->B: {{Na2, Nb2-1}Ka }Kb 8. B ->A: {{kab, Na2-1}Kb }Ka 9. A ->B: {{kab, Na2-1}Ka }Kb Session_instances [A:alice; B:bob; S:server; Ka:ka; Kb:kb; Ks:ks]; Intruder divert, impersonate; Intruder_knowledge a, b, se, ka, kb, ks; Goal correspondence_between A B; Goal B authenticate A on kab; Goal A authenticate B on kab; Goal Secret Ks',ka',kb'; 54