SP5 Sécurité Lot 5.2 Spécification des composants de sécurité et audit

Transcription

1 Projet ANR-Verso 2008 UBIS «User centric»: ubiquité et Intégration de Services SP5 Sécurité Lot 5.2 Spécification des composants de sécurité et audit Page 1 sur 39

2 Auteurs : Participants : Version : H.AISSAOUI / N. Simoni R.Salman / S.Natouri V2 Date : Historique du Document Version Date Modifications V H.AISSAOUI V N.Simoni V H.AISSAOUI V N. Simoni Page 2 sur 39

3 Table des matières 1. INTRODUCTION RAPPEL DE LA DEFINITION DES COMPOSANTS DE SECURITE CONCEPTS D UBIS LES SPECIFICATIONS Les Black Box des services de sécurité La Black Box d identification La Black Box d authentification La Black Box d autorisation Black Box d identification/authentification forte Le Modèle Informationnel des Composants de Sécurité Modèle informationnel d Identification Modèle informationnel d Authentification Modèle informationnel d Autorisation Modélisation en XML Le modèle XML d identification Le modèle XML d authentification Le modèle XML d autorisation CONCLUSION BIBLIOGRAPHIE ET WEBOGRAPHIE Page 3 sur 39

4 Table des illustrations Table 01 : Méthodes d authentification... page 06 Table 02 : Types de contrôle d accès... page 07 Figure 01 : Black box et les trois Interfaces... page 09 Figure 02 : Modèle Informationnel... page 10 Figure 03 : Passage VPSN... page 11 Figure 04 : Types d Identification... page 12 Figure 05 : Identification par (login/password)... page 13 Figure 06 : Authentification par (login/password)... page 14 Figure 07 : Exemple d authentification... page 15 Figure 08 : La Black Box du composant autorisation... page 15 Figure 09 : Authentification par un certificat... page 16 Figure 10 : Identification par la biométrie... page 17 Figure 11 : Authentification par la biométrie... page 18 Figure 12 : Authentification par la carte à puce... page 18 Figure 13 : Autre type d Authentification par la carte à puce... page 19 Figure 14 : Modèle informationnel d identification... page 20 Figure 15 : «Usage Plan» du composant identification... page 20 Figure 16 : «Control Plan» du composant identification... page 21 Figure 17 : «Management Plan» du composant identification... page 21 Figure 18 : Classe «Entity» du composant identification... page 22 Figure 19 : Classe «Management» du composant identification... page 22 Figure 20 : Classe «Connection» du composant identification... page 23 Figure 21 : Classe «Contraint» du composant identification... page 23 Figure 22 : Modèle informationnel d authentification... page 24 Figure 23 : «Usage Plan» du composant authentification... page 24 Figure 24 : Classe «Entity» du composant authentification... page 25 Figure 25 : Modèle informationnel d autorisation... page 26 Figure 26 : Classe «Entity» du composant autorisation... page 27 Figure 27 : Classe «Management» du composant autorisation... page 27 Figure 28 : La classe «Connection» du composant autorisation... page 28 Figure 29 : La classe «Constraint» du composant autorisation... page 28 Figure 30 : Les interfaces du composant autorisation... page 29 Page 4 sur 39

5 1. Introduction Dans le sous projet SP5, il s agira de traiter tous les aspects liés à la sécurité de manière générale dans UBIS, ce livrable (SP5.2) vise, particulièrement, à déterminer l ensemble des spécifications des composants de sécurité afin d obtenir une session unique «sans couture» de l utilisateur qui assure la continuité de service, les contraintes de qualité de service de bout en bout et de personnalisation de services selon ses préférences. En même temps il faut respecter l architecture d UBIS qui est basée sur l architecture SOA. Pour cela, la sécurité doit être modélisée et spécifiée à travers des composants de services, qui vérifient les caractéristiques du modèle de composition de service dans UBIS. L utilisation de ces services doit être indépendante du contexte de l utilisateur. Ces services doivent être autonomes, stateless et mutualisables entre les utilisateurs, et interopérables avec les autres composants de services. Ils doivent aussi offrir une certaine valeur de qualité de service demandée par l utilisateur. Fondamentalement les enjeux de la sécurité restent les mêmes : authentifier les utilisateurs, gérer les autorisations et auditer l ensemble de l organisation pour assurer l intégrité de l ensemble. Nous allons faire un rappel des définitions (2) et des concepts d UBIS (3) concernant les modèles qui nous permettent d avoir les bonnes abstractions représentatives du monde réel. A la suite de quoi nous pourrons faire les spécifications ( 4) des composants de sécurité. On terminera par une conclusion (5). 2. Rappel de la définition des composants de sécurité La description de l architecture de sécurité pour un projet importe de différencier les composants de la sécurité, qui sont souvent confondus : Identification (2.1), Authentification ( 2.2), Autorisation ( 2.3) et l Audit ( 2.4) qui permettra d avoir la traçabilité (2.5). 2.1 L identification Il s agit de donner un nom à un objet, à une personne, qui sera utilisé pour décliner son identité. Un objet qui n a pas de nom est anonyme, et dans ce cas l objet ne peut être tenu responsable d une action fautive. Un objet peut avoir un pseudonyme (un alias), il cache alors son vrai nom, mais il reste responsable des actions qu il pourra exécuter sous son faux nom [5]. 2.2 L authentification C est la preuve de l identité d une entité ou de ces opérations. Il s agit d un processus incorruptible pour garantir que le sujet est bien celui qu il prétend être [5]. La table suivante présente les méthodes d identification /authentification les plus utilisées : La méthode Couple : identifiant + mot de passe Description Il s'agit de la méthode la plus simple et la plus répandue. l'identifiant est généralement et automatiquement attribué par le système ou son administrateur, le choix du mot de passe est souvent laissé libre à l'utilisateur ; il peut être attribué par le système, et l utilisateur le modifie. Le problème avec ce modèle est que la plupart des utilisateurs se contentent d'utiliser un mot de passe facile à retenir ; par conséquent, il peut être Page 5 sur 39

6 facilement trouvé par une attaque (Force Brute, par Dictionnaire). De plus le mot de passe circule en clair sur le réseau, par conséquent, il souffre de risque d écoute. Donc la sécurité de cette méthode dépend de la complexité du mot de passe. OTP : OneTime Password C est une méthode d'authentification forte basée sur le principe de challenge/ réponse. OTP est basé sur l utilisation d un mot de passe pour une et une seule session. De plus, le mot de passe n'est plus choisi par l'utilisateur, mais il est généré automatiquement par une méthode pré calculée. Cela supprime les contraintes de : Longévité du mot de passe. Le mot de passe est utilisé une seule fois Simplicité du mot de passe. Le mot de passe est calculé par l'ordinateur et n est pas choisi par un utilisateur. Attaque par dictionnaire ou par force brute : Pourquoi essayer de cracker un mot de passe obsolète? Sniffer et chiffrement du mot de passe : le mot de passe à usage unique peut être envoyé en clair sur le réseau : lorsqu'un sniffer en détecte un, il est déjà trop tard, car il est utilisé, et non ré-exploitable. Généralement les mots de passe à usage unique sont générés à partir des fonctions de hachage MD4 et MD5. Il y a deux entités dans le fonctionnement d OTP : le générateur qui produit un mot de passe d une phrase secrète (pass-phrase), et d un défi (Challenge) envoyée par le serveur. La deuxième entité est le serveur qui doit : - envoyer un défi qui contient les paramètres d OTP pour le générateur. - vérifier le mot de passe reçu en comptant OTP par lui-même et comparant le résultat avec le mot reçu, et le stocker. - faciliter la transmission du pass-phrase de manière sûre. RFID Radiofréquence identification Ce système est utilisé pour identifier des objets passant devant un dispositif de lecture. Les systèmes RFID sont composés généralement d éléments fixes (appelés station de base, lecteur, coupleur, terminal, etc.) ayant pour fonction d identifier, et de traiter (par ondes radio) les informations continues dans un ou plusieurs éléments déportés, comme les transpondeurs, les tags, les badges, ou les étiquettes électronique. Une puce RFID est encastrée dans un badge. Elle porte un numéro d identification ; Ce numéro est ensuite associé à un utilisateur. il existe deux types de technologie : - RFID passif : la carte ne possède pas l alimentation propre. La carte Page 6 sur 39

7 est alimentée lors du passage par un champ électromagnétique généré par la lecture. La détection de cette carte se fait à quelques centimètres. - RFID actif : la carte a sa propre alimentation, qui permet une détection de la carte à plus longue portée. RFID n est pas une solution sécurisée. Biométrique Le certificat PKI Public Key Infrastructure Carte à puce Carte à puce EAP/TLS extensible authentication protocol Un ensemble de procédés vise à établir l'identité d'une personne, à partir de la mesure d'une ou plusieurs de ses caractéristiques morphologiques, biologiques ou comportementales telles que les empreintes digitales, les traits du visage, les comportements de la personne. Cette solution est mis en ouvre pour protéger des applications sensibles. L identifiant de l utilisateur peut être stocké dans une carte à puce, ou sur un serveur central, ou sur le poste. Le problème avec ce type est que la biométrie ne passe pas à l échelle ; et la réponse est toujours un seul bit 0/1 oui/non ; un utilisateur malveillant peut le détecter et le modifier. Ensemble des techniques basées sur la cryptographie à clé publique. L utilisation de ce système nécessite d avoir un canal sécurisé pour s échanger les clés. la publication de la clé publique est faite en utilisant un certificat X509. Ce certificat est délivré par une tierce partie de confiance, il s appelle autorité de certification CA. CA est chargé d assurer la véracité des informations contenues dans le certificat à clé publique et sa validité. Le certificat permet de chiffrer ou signer des messages sans avoir à partager de secret. L identifiant ici c est le certificat signé par CA. Les cartes à puce sont principalement utilisées comme moyens d'identification personnelle (carte d identité, badge d accès aux bâtiments, carte d assurance maladie) ou de paiement (carte bancaire) ou preuve d'abonnement à des services prépayés (carte de téléphone, titre de transport). L intérêt majeur de cette méthode est de stocker sur la carte un certificat, ou un mot de passe complexe; ainsi l utilisateur n est plus obligé ni de retenir un mot de passe complexe, ni d utiliser un mot de passe facile. En plus cette carte est sécurisée par un code PIN (personal identifier number). Donc pour authentifier l utilisateur, il faut la présence de la carte, avec le code PIN. C est une extension de la carte à puce. Elle est simple, robuste, et très sûre. Le certificat de l utilisateur, le certificat de CA, et la clé privée de l utilisateur sont stockés sur cette carte. La carte EAP/TLS réalise tous les traitements et les opérations de chiffrement SSL par le billet de son processus intégré. Donc le terminal de l utilisateur se comporte comme un relais de communication passif entre le serveur SSL et la carte à puce. Les avantages de la carte EAP/TLS sont : la protection contre l usurpation de l identité, l aisance de la mobilité du client, et le confinement de la sécurité. Il est robuste contre quelques types d attaque par exemple Chevaux de Troie [6]. Table 1 : Méthodes d authentification Page 7 sur 39

8 2.3 L autorisation C est un ensemble d actions et de directives qui permettent de spécifier les droits d accès aux ressources par un sujet. Elles déterminent les privilèges de l utilisateur en fonction de ses attributs. La fonction d autorisation peut être divisée en deux phases: phase de définition des politiques d accès, et phase d'exécution des politiques. L'autorisation a pour rôle d'empêcher la divulgation non autorisée de l'information ou des données en contrôlant l'accès à celles-ci. Pour cela, il repose sur l'identification et l'authentification des utilisateurs. La plupart des protocoles de sécurité offrent une telle fonction, habituellement sous forme d'une liste de contrôle d'accès (LCA). Les listes LCAs énumèrent les personnes, les groupes de personnes ou les processus qui sont autorisés à accéder à certains fichiers ou répertoires. La table suivante présente quelques types de contrôle d accès : Type de Contrôle d accès RBAC Role Based Access control CBAC Contexte Based Access Control LBAC: Lattice Based Access Control OrBAC Organization Based Access Control Description C est un modèle de contrôle d'accès à un système d'information dans lequel chaque décision d'accès est basée sur le rôle auquel l'utilisateur est attaché. Un rôle correspond généralement à la structure d'une entreprise. Les utilisateurs exerçant des fonctions similaires peuvent être regroupés sous le même rôle. Un rôle, déterminé par une autorité centrale, associe à un sujet des autorisations d'accès sur un ensemble des objets [16]. permet d'associer des permissions de contrôle d'accès avec les contextes où les utilisateurs fonctionnent. Les utilisateurs acquièrent ou perdent leurs autorisations lors du passage d'un contexte spécifique, contrairement aux solutions de contrôle d'accès traditionnels où l'identité d'utilisateur/rôle déclenche l'évaluation des politiques lors d'une demande d'accès aux ressources. CBAC peut inspecter le trafic pour les sessions qui proviennent du réseau externe. CBAC filtre intelligemment les paquets TCP et UDP à partir des sessions de la couche application. Un Lettice est utilisé pour définir des niveaux de sécurité, qui peuvent être associés à des objets et à des sujets, pour déterminer le droit d accès d un sujet à un objet. Un sujet est seulement autorisé à accéder à un objet si le niveau de sécurité de ce sujet est supérieur ou égal à celle de l'objet Cette méthode est basée sur trois entités (sujet, action, objet). Pour contrôler l'accès, on spécifie si un sujet a la permission de réaliser une action sur un objet. Le but principal d'orbac est de permettre de définir une politique de sécurité indépendamment de son implémentation [17]. La méthode choisie pour arriver à ce but est l'introduction d'un niveau abstrait. Les sujets sont abstraits en rôle. Un rôle est un ensemble de sujets sur lequel les mêmes règles de sécurité sont appliquées. Les actions sont abstraites en activité. Une activité est un ensemble d'actions sur lequel les mêmes règles de sécurité sont appliquées. Les objets sont abstraits en vue. Une vue est un ensemble d'objets sur lequel les mêmes règles de sécurité sont appliquées. Table 2 : Types de contrôle d accès Page 8 sur 39

9 2.4 L audit C est l observation, l analyse, l enregistrement et la compréhension des événements importants qui vont concourir à construire le fil de son histoire, après la constatation d une panne, ou d une attaque. Dans la pratique, on enregistre dans les différents dispositifs de sécurité des journaux qui seront des témoins de confiance chargés d interpréter la trame des opérations, et d imputer la responsabilité d une erreur ou d un acte malveillant [5]. Un audit ne concerne pas seulement la sécurité. Il peut servir à évaluer des aspects stratégiques, organisationnels ou de qualité d'un système d'information pour répondre efficacement aux besoins des services métiers d'une entité. Il existe plusieurs méthodes pour mener à bien un audit informatique, je cite à titre d exemple la méthode EBIOS (Expression des Besoins et Identification des Objet de Sécurité). Cette méthode permet d apprécier et de traiter des risques, qui représentent «une source de menace, une menace, une vulnérabilité, un impact» [18]. EBIOS suit la démarche suivante: L étude du contexte : identifier les métriques (les biens essentiels et les biens supports) et les paramètres à prendre en compte dans le traitement de risques. L étude des événements redoutés : identifier et estimer les besoins de sécurité des biens essentiels (en termes de disponibilité, d intégrité, de confidentialité..), ainsi que tous les impacts (sur les missions, sur la sécurité des personnes, financiers, juridiques...), et les sources des menaces (humains, environnement, internes, externes, accidentelles, délibérées) susceptibles d être à l origine. Ce qui permet de formuler les événements redoutés. L étude des scénarios des menaces : identifier et estimer les scénarios qui peuvent engendrer les événements redoutés, et constituer des risques. Pour ce faire il faut étudier les menaces que les sources peuvent générer et les vulnérabilités exploitables. L étude des risques : mettre en évidence les risques pesant sur l'organisme en confrontant les événements redoutés aux scénarios de menaces. Il décrit également comment estimer et évaluer ces risques, et enfin comment identifier les objectifs de sécurité qu'il faudra atteindre pour les traiter. L étude des mesures de sécurité : spécifier les mesures de sécurité à mettre en œuvre, comment planifier la mise en œuvre de ces mesures, et comment valider le traitement des risques et les risques résiduels. Page 9 sur 39

10 2.5 La traçabilité Selon la norme ISO 8402 : " Aptitude à retrouver l historique, l utilisation ou la localisation d un produit ou d un processus de délivrance d un service au moyen d identifications enregistrées ". C est une fonction qui consiste à repérer l histoire des entités ou des fractions des entités dans un monde mobile. La traçabilité peut déterminer la position d un objet ou d un sujet, dater des transactions et noter des enseignements sur des situations. Cette fonction est importante pour contrôler un objet, pour pister un suspect, ou pour reconstruire un scénario lors d une enquête [5]. 3. Concepts d UBIS 3.1 Black Box de composant de service Comme nous l avons défini dans le SP3.1 notre composant de service se modélise comme une boite noire «black box». Cette dernière a trois interfaces, sur lesquelles il reçoit des requêtes (Figure 1). Pour permettre un interfonctionnement entre les ESs, ces interfaces doivent être les plus génériques possibles. Et ils doivent aussi permettre d accéder aux fonctionnalités réalisées par les composants de service [3]. Elles sont : Usage interface: elle permet de faire appel aux fonctions principales réalisées par l ES. Control interface: elle inclut la signalisation nécessaire pour le provisionning des ESs, l activation et la désactivation dans le VPSN. Management interface : elle permet de gérer la QoS (autogestion), et l état du composant durant les différentes phases (déploiement et accounting). Figure 1 : Black box et les trois Interfaces La convergence interne de ces trois interfaces, est nécessaire pour rendre le comportement d ES dynamique à un événement extérieur, quelque soit cet événement (usage, contrôle, gestion). 3.2 Conception de ES à base d opération Sur le plan d usage, l élément de service a été proposé comme une chaine d opération. Une opération est un élément autonome, réutilisable, et elle n a pas de contraintes ou de conditions de lien avec d autres opérations ; pour ces raisons, elle peut être utilisée dans un autre Page 10 sur 39

11 composant. Lors qu elle est utilisée dans un schéma particulier, un lien logique entre les opérations est fait [3]. 3.3 Le modèle informationnel [4] Pour avoir une représentation efficace du monde réel, qui est hétérogène, nous devons avoir une structure informationnelle homogène contenant les informations pertinentes et synthétiques d un ES. Le modèle informationnel est un modèle générique et abstrait. Il permet la description de n importe quelle entité du monde réel (un nœud, un lien, un réseau). Pour chaque élément de réseau (NE Network Element), le modèle précise son architecture, et ses services offerts, via des interfaces permettent à l élément de réseau de répondre à des demandes de services, ou émettre des messages aux entités (Figure 2). Un élément de réseau se compose d éléments logiciels «service», qui contient les classes suivantes: Usage : représente l interface d usage qui reçoit les requêtes de l utilisateur. Gestion : représente l interface de gestion qui gère l état d ES, et la QoS rendu. Contrôle : représente l interface de contrôle. Il reçoit des requêtes pour contrôler l ES. L élément de réseau se compose aussi de la classe Architecture qui contient les classes suivantes : Contraint : qui englobe les contraintes du service. Entity : qui représente la fonction cœur du ES. Là on trouve les opérations nécessaires pour rendre le service à l utilisateur. Connexion : qui représente la table de routage (les relations entre l ES et les autres éléments), et la QoS de cette table. SAP : qui représente les points d accès par lesquels les services de l ES peuvent être demandés ou fournis. Management : qui gère la QoS et les états de l ES. Dans ce modèle on intègre les quatre critères du modèle QoS, comme des paramètres pour chaque classe (Figure 22). La valeur courante de la QoS est intégrée dans deux classe : «Entity et Connexion». La valeur seuil est intégrée dans la classe Management. La valeur conception est intégrée dans la classe Contraint. Page 11 sur 39

12 Grâce à ce modèle, nous avons une base de connaissance complète et globale de chaque composant. Figure 2 : Modèle Informationnel Maintenant, nous passons aux spécifications des composants : «identification, authentification et autorisation» à travers les cinq dimensions suivantes : architecturale et organisationnelle : présentées par les trois plans. Protocolaire : présentée par une black-box Fonctionnelle : présentée par les opérations de la black-box Informationnelle : présentée par le modèle informationnel. 4. Les Spécifications Les composants de sécurité «identification, authentification et autorisation» doivent respecter toutes les spécifications définies sur un composant de service dans UBIS. Ils doivent donc être autonomes, mutualisables, interopérables et auto-gérables. Il doit avoir la même architecture et respecter le même modèle de QoS. Pour ce faire, nous allons modéliser nos composants de service selon les cinq dimensions (architecturale, relationnelle, fonctionnelle, informationnelle et organisationnelle) mentionnées dans le chapitre précédent. Ces composants sont structurés en trois plans comme tous composants de service dans UBIS : le plan d usage, de contrôle et de gestion. Ces plans permettent son utilisation, son approvisionnement et sa gestion. Page 12 sur 39

13 Les composants d authentification et d autorisation sont des composants de base qui permettent de passer d un pré-vpsn au VPSN actif. A chaque ouverture de session, ces deux composants interviennent pour construire le VPSN actif en fonction du pré-vpsn, de la disponibilité des services, et de leurs qualités de service (Figure 3). Contrairement aux deux autres composants, le composant d identification est demandé au moment de l inscription de l utilisateur. Figure 3 : Passage VPSN 4.1. Les Black Box des services de sécurité Nous détaillons les fonctionnalités des deux composants de sécurité (identification et authentification), en utilisant le couple (login/password) comme un identifiant. Les autres types vont être traités brièvement. Chaque composant est représenté par une black box dans laquelle nous allons aborder juste le plan d usage, et mettre en évidence les opérations effectuées en fonctions des requêtes des utilisateurs La Black Box d identification Le but du composant d identification est de donner un identifiant à chaque utilisateur, pour qu il soit reconnu dans le système. Selon les rôles, les préférences, ou les fournisseurs de services auxquels l utilisateur est abonné, il dispose un ou plusieurs types d identifiants (Figure 4), à titre d exemple : One Time Password (OTP), un couple (login /password), carte à puce, biométrie, ou certificat. Figure 4 : Types d Identification Page 13 sur 39

14 Commençons par le couple (login/password). Le login est un nom qui permet d identifier un utilisateur ; ce login suffit largement pour identifier un utilisateur. Dans notre système, le login est insuffisant pour identifier l utiliser. Pour des raisons de sécurité, nous sommes obligés de coupler ce login avec un mot de passe. La black box du composant d identification comporte une seule entrée «un pseudo» (Figure 5). Dès qu il reçoit une requête de l utilisateur, il exécute les opérations suivantes: Recherche(): si le pseudo est déjà dans la base de données, nous recevons une réponse négative (NOK), ce qui veut dire que l utilisateur possède déjà un identifiant. Dans le cas contraire, le composant enchainera, en fonction des besoins de l entreprise, les opérations suivantes. Gréer_login() : le composant génère un login. Créer_Password (): le composant génère un password. Figure 5 : Identification par (login/password) Le résultat en sortie dépendra de l enchainement des opérations précédentes. Il peut être soit un seul login, soit un couple (login /password), soit un login et plusieurs passwords (login + password1 +password2). Nous allons évoquer deux remarques afin d éviter la confisions faite entre le service d inscription et le service identification, et de limiter quelques vulnérabilités. Remarque1 : Il faut distinguer entre les deux cas suivants : 1 ier cas : le système donne la faculté à l utilisateur de choisir son propre login et mot de passe : L utilisateur remplit à travers un formulaire son identifiant et son profils. Après la saisie de toutes ces informations, le système les enregistre dans sa base de données. C est le service d inscription 2 ième cas : le système génère l identifiant à l utilisateur : Au moment de l inscription d un utilisateur, le système génère l identifiant, en se basant sur ce qu on appelle le «service d inscription». Puisque les deux services (identification et inscription) sont enchainés, certains membres du projet UBIS les considèrent comme un seul service. Remarque 2 : Le composant d identification n est pas lié au composant d authentification. Page 14 sur 39

15 Afin d éviter l usurpation d identité, il faut que le service d inscription invoque le service d identification. L utilisateur doit avoir la possibilité de changer son mot de passe. Tenant en considération ce qui a été dit précédemment, nous avons proposé un composant d identification générique, qui peut être utilisé dans n importe quel contexte, et par n importe quel fournisseur. En suite, nous proposons le composant d authentification concernant le type d identification (login/password) La Black Box d authentification Le service d authentification a pour objectif de garantir une authentification unique par session. Pour ce faire le composant d authentification vérifie l identifiant fourni par l utilisateur et génère un jeton (Token). Ce Token contient les informations nécessaires pour identifier un utilisateur auprès des autres services, ainsi l utilisateur n a plus besoin de s authentifier plusieurs fois dans une session. La black box de ce composant a comme entrée un couple (login/password) (Figure 6). Figure 6 : Authentification par (login/password) Dans la black box on voit les opérations d usage plan, que le service d authentification exécute pour rendre le service à l utilisateur. Les opérations sont : Recherche () : rechercher dans la base de données en utilisant le login pour récupérer le mot de passe stocké. Recherche () : rechercher les paramètres nécessaires pour les algorithmes utilisés, exemple : clé de déchiffrement. Algo1(): c est l exécution d un algorithme pour traiter les identifiants, exemple : déchiffrer le mot de passe. Algo2(): c est l exécution d un algorithme pour traiter les identifiants, exemple : appliquer la fonction de hachage. Match(): comparer les paramètres d identification stockés dans la base et les paramètres fournis par l utilisateur après l utilisation des algorithmes nécessaires. S ils ne sont pas équivalents, le résultat se traduit par un message (NOK) ; dans le cas contraire, le composant exécutera l opération suivante Générer() : le service génère un Token qui contient les identifiants de l utilisateur. L enchaînement de ces opérations se différencie selon plusieurs facteurs : les algorithmes utilisés pour l authentification, le type d identification, le contexte La sortie de ce service sera un Token pour le système, et un message positif ou négatif pour l utilisateur. L exemple suivant démontre en détail le processus d exécution de ce service en se basant sur un cas réel : Page 15 sur 39

16 L utilisateur saisit son login et son password, le service reçoit ce couple chiffré, il fait une recherche pour obtenir la clé de déchiffrement du système; il déchiffre le mot de passe; en suite il applique une fonction de hachage( HMAC) du mot de passe. Une autre recherche se fait en même temps pour récupérer le password stocké dans la base de données sous en forme (HMAC). le service fait une comparaison entre HMAC (Password fourni) et HMAC (Password stocké); si les deux hachés sont égaux, le service génère un Token, et envoie un message (OK) à l utilisateur. Dans le cas contraire, il envoie un message (Nok) à l utilisateur (Figure 7). Figure 7 : Exemple d authentification Le service d authentification doit être enchainé par : Un service de session: qui ouvre directement la session en cas d authentification réussit. Un service d affichage: pour afficher les réponses aux utilisateurs (OK/NoK). Un service de stockage: pour enregistrer le Token sous forme de cookies. Le niveau de sécurité de ce type d authentification basé sur un couple login/password dépend de la complexité du password. Pour obtenir un niveau de sécurité plus élevé, il existe d autres moyens d authentification qui se basent sur des certificats, la biométrie et la carte à puce La Black Box d autorisation Lors de l ouverture de sa session, une partie demande un ensemble de services et donc de composants de services. L autorisation unique intervient à ce niveau pour autoriser (ou interdire) la partie à utiliser chaque composant de service. Le composant autorisation a besoin de deux choses en entrée : l identité de la partie qui demande l accès au composant de service en question (par rapport auquel cette autorisation est faite); et l identité de ce composant de service. La partie doit impérativement être authentifiée avant de passer à l autorisation. En sortie, l autorisation donne une réponse positive(ok) ou négative (KO). Selon cette réponse le composant en question sera inséré ou non dans le VPSN de la partie. Page 16 sur 39

17 Figure 8 : La Black Box du composant autorisation Black Box d identification/authentification forte Notre système est centré sur l utilisateur (user-centric), ce qui veut dire que le client peut choisir le type d identification/authentification qu il souhaite utiliser selon ses besoins et ses préférences. Nous allons illustrer des black box qui nous permettent de modéliser trois types d authentification forte en se basant sur des certificats X509, la biométrie et la carte à puce Le certificat : L autorité de certificat (CA) génère le certificat X509, qui contient des informations sur la personne, sa clé publique, la date de validité et la signature de CA. La création et la distribution de ces certificats, vus comme un service d identification. Le certificat identifie la personne parce qu il contient ses informations personnelles (nom, prénom). Pour authentifier l utilisateur en utilisant son certificat, il faut vérifier deux conditions : L identité de l utilisateur qui demande l accès au système. La validité de son certificat. L utilisateur s identifie lui-même par le chiffrement d un petit message (m) en utilisant sa clé privé (m) kp u. Grâce à ce message on assure la première condition. Pour le deuxième, normalement, le système lui-même peut avoir les certificats de ses utilisateurs, ou les demander au CA. Afin de faciliter les tâches du système (chercher dans la base de données ou demander les certificats de CA à chaque demande d authentification), on propose que l utilisateur envoie son certificat avec le message (m) kp u,. Pour empêcher l attaque «man in the middle», le dernier message qui contient (m) kp u + certificat, sera chiffré en utilisant la clé publique du système. Donc le message final est: M = [(m) kp u +certificat] kps Kp u : représente la clé privée de l utilisateur. Kps : représente la clé publique du système. Dès que le service d authentification reçoit M sur l interface d usage, il exécute les opérations suivantes : Déchiffrer () : déchiffre M en utilisant la clé privée du système. Valider cert() : après le déchiffrement il extrait le certificat, et vérifie sa validité. S il n est pas valide, le service termine son travail et il envoie un message négatif à l utilisateur. S il est valide, on passe à l opération suivante. Déchiffrer m() : le service déchiffre le message (m) en utilisant la clé publique de l utilisateur stocké dans son certificat. Si le déchiffrement ne réussit pas, le service envoie une réponse négative à l utilisateur. S il réussit, il passe à la dernière étape. Créer Token() : génère un Token à l utilisateur, contenant ses informations (Figure 9). Page 17 sur 39

18 La biométrie : Figure 9 : Authentification par un certificat Le service d identification construit l identifiant de l utilisateur en se basant sur la récupération de ses caractéristiques biologiques (ses yeux, son empreinte ), ou de son comportement (sa signature, la résolution d un labyrinthe). Composant d identification : Nous allons prendre à titre d exemple le cas de l empreinte digitale : notre composant obtient comme entrées deux éléments: l image du doigt de l utilisateur. son nom/prénom. Cette image est traitée par des algorithmes pour extraire la minutie. La minutie représente l identifiant de l utilisateur (Figure 10). Figure 10 : Identification par la biométrie L inconvénient de ce type d identification est que les gens laissent leurs empreintes digitales partout (poignée de porte, vitres bureau ); il existe des types d attaques (clonning attack, ), peuvent extraire ces empreintes. Pour renforcer ce type d identification, et avoir une authentification forte, on a proposé de générer un code PIN (personal identification number) pour chaque utilisateur. Grâce à ce dernier on peut éliminer quelques attaques. Le code PIN sera utilisé aussi comme une clé de chiffrement, pour chiffrer le couple (nom, identifiant) afin d éliminer l usurpation des identités, et le stocker dans la base de données. Le composant d authentification : Le composant obtient comme entrée le nom/prénom de l utilisateur, son code PIN, et l image de son empreinte digitale. Notre composant va chercher l identifiant de cet utilisateur stocké dans la base de données en utilisant son nom. En parallèle le service exécute les opérations suivantes : Traiter () : il traite l image de l empreinte digitale en appliquant quelques algorithmes. Extraire () : après le traitement de l image, il extrait la minutie qui représente l identifiant biométrique. Page 18 sur 39

19 Chiffrer() : cette opération permet de réaliser un chiffrement du couple (l identifient biométrique, le nom de l utilisateur) en utilisant le code PIN fourni par l utilisateur. Match () : cette opération fait une comparaison entre les données fournies par l opération Chiffrer() et l identifiant chiffré et stocké dans la base (Figure 11). S ils sont égaux, la sortie sera un Token et un message OK. Figure 11 : Authentification par la biométrie La carte à puce : Le système identifie son utilisateur en lui donnant un identifiant stocké sur une carte à puce. Cet identifiant peut être un certificat ou un mot de passe complexe qui seront utilisés pour les transactions et le chiffrement. En même temps le système donne à l utilisateur un code secret PIN (Personal Identication number) stocké sur la carte. La fabrication de la carte et la création du code PIN (personal identication number) sont considérées comme un service d identification. Dans ce cas nous traitons juste le service d authentification : L utilisateur s identifie lui-même par la présence de sa carte et son code PIN. Dès que le composant d authentification reçoit une requête, il lit le code PIN stocké sur la carte, après il le compare avec le code PIN saisi par l utilisateur. S ils sont équivalents, le composant génère un Token qui contient l identifiant de l utilisateur stocké sur la carte (Figure 12). Figure 12 : Authentification par la carte à puce Autre type d identifiant qui peut être stocké sur la carte au lieu du certificat ou du mot de passe ; c est l identifiant biométrique (l empreinte digitale). L authentification avec l identifiant biométrique est plus forte, parce que l utilisateur scanne son doigt au lieu de saisir un code PIN composé de quatre chiffres. Dans ce cas, le composant d authentification traite l image reçue du doigt de l utilisateur en appliquant plusieurs algorithmes pour extraire la minutie qui Page 19 sur 39

20 représente l identifiant. En même temps, il lit l identifiant biométrique stocké sur la carte. Ensuite il compare les deux, et génère un Token s ils sont égaux, (Figure 13). Figure 13 : Autre type d Authentification par la carte à puce Nous avons abordé les composants d identification et d authentification concernant les quatre types d identifiant (login/password, le certificat, la biométrie et la carte à puce). Les composants d identification (et les composants d authentification) ont été modélisé comme des black box ayant les même entrées (des requêtes) et la même sortie. L utilisation de ces composants proposés est indépendant des contextes des utilisateurs. Cependant, chaque composant doit rendre une certaine valeur de QoS demandée par chaque utilisateur. C est le plan de gestion qui s occupe de cela. Pour en savoir plus, on montre par la suite, le modèle informationnel de chaque composant en détail Le Modèle Informationnel des Composants de Sécurité Ce modèle présente l architecture de chaque service dans UBIS. Il va nous aider à bien répondre aux questions suivantes : comment les composants sont interopérables entre eux? Comment le composant respecte le contrat de chaque utilisateur? Comment le composant assure l autogestion de son travail? Les classes du modèle informationnel répondent à ces questions. L interface d usage rend l interopérabilité. Le plan de gestion avec la classe Management rendent l autogestion d un composant en fonction de la qualité de service. De plus, le modèle informationnel représente une base de connaissance complète et seule pour chaque ES. Il englobe ses informations (l adresse, les contraints, la table de routage, les valeurs de qualité de service demandé par chaque utilisateur ), et toutes les opérations nécessaires pour répondre aux requêtes sur les trois interfaces Modèle informationnel d Identification Le logiciel «Magic-Draw», a été utilisé pour modéliser le modèle informationnel, en utilisant le langage UML. Chaque classe dans le modèle est représentée par trois champs, le premier champ représente le nom de la classe, le deuxième représente les paramètres d entrée et de sortie, et le dernier champ représente les fonctions de cette classe (Figure 14). Page 20 sur 39

21 Figure 14 : Modèle informationnel d identification Les trois classes (Usage Plan, Control Plan, Management Plan) représentent les interfaces de composant d identification, où il reçoit des requêtes de l extérieur. Ces requêtes déclenchent le travail du service. L interface d usage (Figure 15) reçoit une seule requête avec deux paramètres : Recieve_IdentityRequest( pseudo, serviceid) : qui reflète la demande d un identifiant. Figure 15 : «Usage Plan» du composant identification Le plan de contrôle (Figure 16) reçoit les requêtes suivantes avec un seul paramètre ServiceID : Signal_activer(serviceID): une requête pour active le service. Signal_Binding(serviceID): une requête pour relier le service avec un autre service. Signal_Desactiver(serviceID): une requête pour désactiver le service. Signal_Deployment(serviceID) : une requête pour mettre en place (en marche) le service. Page 21 sur 39

22 Figure 16 : «Control Plan» du composant identification Le plan de management (Figure 17) reçoit les requêtes suivantes: CurrentQOS_Request (serviceid): demande la value courante de QoS de ce service. Change_QOSThresholdValue ( serviceid, QoSThresholdValue ) : changer la valeur seuil de QoS de ce service. CurrentState_Request (serviceid) : demande l état courant pour le composant de l identification. Figure 17 : «Management Plan» du composant identification La classe «Entity» (Figure 18) : Elle contient les opérations qu on a présentées en utilisant la black box, et les opérations nécessaires pour dialoguer avec la base de données. La classe Entity fournit aussi la valeur courante de la QoS (contenant les quatre critères de QoS). Les opérations sont: SearchDB( pseudo ) : recherche dans la base de données, si le pseudo est déjà stocké. Si oui le service va terminer l exécution. Recieve_DBResopnse() : il reçoit la réponse de la base de données. Generate_login (): si le pseudo n est stocké dans la base, le service peut lui générer un login. Generate_Password() : si le pseudo n est pas stocké, le service peut lui générer un password. SendReponse() : il envoie la réponse (login, login/password), ou (login/password/password). Change_QOSCurrentVal() : il met à jour la valeur courante de la QoS. Page 22 sur 39

23 Figure 18 : Classe «Entity» du composant identification La classe «Management» (Figure 19) : Elle contient la valeur seuil de la QoS et les opérations responsables de changement de l état du composant, et de comparer entre sa valeur courante de QoS et la valeur seuil afin d observer la dégradation de la QoS. Cette classe contient la valeur seuil de la QoS, et il prend la valeur courante de la classe Entity. Les opérations principales: SetQoSThresholdVal() : permet de mettre ou changer la valeur seuil de la QoS. Compare_CQoS_TQoS() : pour comparer entre la valeur courante, et la valeur seuil, de la QoS. Notify_Alert() : permet d envoyer des signaux, exemple: le signal indique la dégradation de la QoS. Change_State() : permet de changer l état de ce composant. Notify_NewState() : permet d envoyer un signal indiquant le changement de l état de ce composant. Figure 19 : Classe «Management» du composant identification La classe «Connection» (Figure 20) : Elle contient la valeur courante de la QoS, et de la table de routage. Il exécute les opérations : SetRoutTable( ServiceID ) : construire la table de routage. GetRoutingTable() : récupérer la table de routage. GetQoSRoutingTable() : récupérer la valeur courante de QoS de la table de routage. SetQoSRoutingTabl() : mettre à jour la valeur curent de la table de routage. GetConnectionState() : récupérer l état de la connexion. Page 23 sur 39

24 Figure 20 : Classe «Connection» du composant identification La classe «Contraint» (Figure 21) : regroupe les contraintes du composant d identification. Cette dernière contient la valeur de conception de QoS, qui représente la valeur maximum de QoS d un composant. Les contraintes du composant d identification sont classifiées en quatre catégories : User contraints : pseudo. Service contraints : service ID, nombre de requête, la valeur de conception de QoS qui représente la valeur maximum de QoS du composant. Network contraints : protocoles de réseau, connexion avec la base de données, connexion de réseau, débit de connexion. Terminal contraints : processeur, mémoire. Figure 21 : Classe «Contraint» du composant identification Modèle informationnel d Authentification De la même façon, le composant d authentification a été représenté en utilisant le modèle informationnel (Figure 22). Les classes suivantes : Control Plan, Management Plan, Connection, SAP, Contraint et Management, ont les mêmes fonctions que les classes du composant d identification. Nous montrons ici juste les opérations des classes : Usage Plan, et Entity. Page 24 sur 39

25 Figure 22 : Modèle informationnel d authentification Le plan d usage (Figure 23) reçoit une seule requête d authentification avec trois paramètres : Auth_request(login,password,serviceID). Figure 23 : «Usage Plan» du composant authentification La classe «Entity» (Figure 24) : Elle englobe les opérations de la black box dont on a parlé dans le ($ ), celles utilisées pour dialoguer avec la base de données et celles responsables de l observation de la valeur courante de la QoS. Les opérations sont: SearchKey() : demande de la clé de déchiffrement. Recieve_key() : réception de la clé de chiffrement de la base de données. ExecutAlgo1() : exécution d une méthode pour déchiffrer. ExecutAlgo2() : exécution d une méthode pour appliquer la fonction de hachage. Search_DBPWD( login ) : demander le password stocké dans la base de données. Recieve_password() : réception du passward stocké dans la base de données. Page 25 sur 39

26 Match_pwd_pwdS( PWD, SPWD ): comparaison entre le password stocké, et le password fourni par l utilisateur après l exécution des algorithmes nécessaires. Generat_Token(PWD, login) : génération de Token qui contient les identifiants de l utilisateur. Send_reponse() : envoie de la réponse (Token, OK/NOK). Change_QOSCurrentValue() : mise à jour de la valeur courante de la QoS. Figure 24 : Classe «Entity» du composant authentification Le composant d authentification a besoin de quelques paramètres pour exécuter ses opérations. Ces paramètres sont regroupés dans la classe «Contraint», et sont classifiés en quatre catégories : User contraints : login, password. Service contraints : la clé de chiffrement (ou déchiffrement), protocoles de déchiffrement, nombre de requêtes, la valeur conception de la QoS. Network contraints : protocoles de réseau, DB connexion, connexion de réseau, connexion débit. Terminal contraint : mémoire, processus Modèle informationnel d Autorisation Le modèle informationnel du composant autorisation respecte le modèle générique. Dans cette partie nous détaillons les différentes classes, ensuite nous faisons une modélisation en XML de ces modèles informationnels. Page 26 sur 39

27 Figure 25 : Modèle informationnel d autorisation La classe «Entity» (Figure 26) : Elle contient l ensemble des attributs statiques et dynamiques et les méthodes permettant au composant autorisation de remplir sa fonction. L opération «Extract» se fait en trois étapes : Extract_Party_ID (Authentication_Token) : permet de récupérer l identifiant de la partie. Cette identifiant est stocké chiffré sur le jeton d authentification. Send_Search_Party_Permissions_Request (Party_ID, ServiceElementID): envoie une requête de recherche des permissions de la partie, qui joue des rôles, sur un élément de service vers la base de données ou l annuaire où sont stocké les rôles de la partie et ses permissions sur les différentes ressources. Receive_Search_Party_Permissions_Response (): c est une méthode qui écoute la réponse de la requête envoyée durant l étape précédente. L opération «Search» se fait en deux étapes : Send_Search_ServiceElementID_Rights_Request(ServiceElementID) : envoie une requête de recherche des droits offerts par l élément de service. Receive_Search_ ServiceElementID_Rights_Response (): c est une méthode qui écoute la réponse de la requête envoyée durant l étape précédente. Et enfin l opération «Matching» prend en entrée les sorties des opérations précédentes et donne la décision de l autorisation. Page 27 sur 39

28 Figure 26 : Classe «Entity» du composant autorisation La classe Entity se charge aussi du changement des valeurs courantes de la QoS du composant autorisation. La classe «Management» (Figure 27) : Figure 27: La classe «Management» du composant autorisation Dans la classe management nous définissons les opérations de surveillance de la QoS du composant autorisation et de la gestion de ce dernier selon ces valeurs. Cette classe stocke les valeurs seuils de la QoS et fait appel aux autres classes (Entity et Constraint) pour récupérer les valeurs courantes et de conception de QoS en cas de besoin. Dans cette classe nous définissons des méthodes de : Positionnement des valeurs seuils de la QoS. Déploiement du composant autorisation. Binding du composant autorisation avec les éléments des autres niveaux de visibilité. Surveillance de QoS du composant tels que : Page 28 sur 39

29 o o o La comparaison entre les valeurs courantes et les valeurs seuils de QoS. Le changement de l état du composant, et La création d un warning ou d une alerte en cas de besoin. Cette classe s occupe aussi de la notification des opérations qu elle fait à l intérieur du composant de service vers le monde extérieur. La classe «Connection» (Figure 28) : Elle remplit la table QosRoutingTable. Cette dernière est construite au moment du déploiement du composant. Elle indique les valeurs de QoS des liens logiques de ce composant avec les autres composants qui font partie de son VSC. Figure 28 : La classe «Connection» du composant autorisation. La classe «Constraint» (Figure 29) : Pour que le composant d autorisation fonctionne, il faudra que la partie possède un jeton d authentification. Ceci représente une contrainte utilisateur. Le composant d autorisation a aussi besoin de recevoir l identité du composant de service par rapport auquel la requête autorisation est faite. De plus, il aura besoin de certains protocoles pour communiquer avec les autres ESs (contraintes service). Pour fonctionner, le composant a besoin d autres éléments au niveau réseau (NE) et terminal(te) (contraintes réseaux et contraintes équipements). Pour le moment, la précision de ces contraintes est difficile puisque nous essayons de mettre en place le premier démonstrateur du projet UBIS. La précision de ces contraintes constitue alors l un des objectifs futur à réaliser sur le composant d autorisation. En plus des contraintes, la classe «constrain»t stocke les valeurs de conception de la QoS du composant autorisation. Page 29 sur 39

30 Figure 29 : La classe «Constraint» du composant autorisation. Les interfaces du composant autorisation (Figure 30) : L interface d usage permet au composant autorisation de recevoir la requête d autorisation. L interface de gestion permet de recevoir des requêtes liées à la gestion de la QoS telles que la requête de : Changement de valeurs courantes de QoS, Positionnement des valeurs seuils, ou encore Changement d état. Sur l interface de contrôle, le composant reçoit des requêtes de types approvisionnement/signalisation telles que des requêtes d activation ou de désactivation du composant, des requêtes de binding, des requêtes de déploiement, etc. Figure 30 : Les interfaces du composant autorisation. Les composantes «identifications, authentification et autorisation», que nous avons proposés, doivent fournir une certaine valeur de QoS, pour qu ils soient disponibles, et utilisables par les utilisateurs qui demandent ces valeurs. Si un de ces composants ne respecte pas le contrat demandé par l utilisateur, il sera remplacé par un autre composant qui offre le même service, et qui garantie les conditions demandées. Page 30 sur 39