these doctorat une architecture de securité

More documents

Recommendations

Info

Conclusion – Optimisation de la surcharge cryptographique Notre solution permet de prendre en compte les besoins en terme de sécurité des divers acteurs intervenant dans l’élaboration de la politique de sécurité. Cette approche permet d’éviter de chiffrer plusieurs fois de suite des flux et évite ainsi une perte de performance lors des communications. L’approche actuelle est indépendante du protocole réseau sousjacent. Cette fonctionnalité peut être à double tranchant. N’ayant pas d’informations sur le réseau, il se peut que le chiffrement effectué par notre mécanisme de sécurité soit à son tour chiffré par des mécanismes de plus bas niveau. – Extension du protocole de déploiement Le déploiement via un descripteur de sécurité pose le problème de l’activation et de la configuration de sécurité à appliquer au runtime distant. Il faut copier les descripteurs de déploiement, le fichier de règles de sécurité et, au besoin, les fichiers représentant les certificats des entités listées dans le fichier de politique de sécurité. Une solution serait la mise en place de mécanismes au niveau du descripteur de déploiement qui permettraient de gérer l’installation distante des fichiers de sécurité requis. tel-00239252, version 1 - 5 Feb 2008 – Utilisation d’un cryptosystème à courbe elliptique La génération d’une paire de clés publique/privée pour le cryptosystème RSA est coûteuse en temps du fait qu’elle requiert des clés de grande taille. La cryptographie à courbe elliptique [65, 28] est une branche prometteuse de la cryptographie à clé publique. Elle offre potentiellement la même sécurité que les système de cryptographie à clé publique mais avec des clés de tailles réduites. A titre de comparaison, une taille de clé de 160 bits en utilisant les courbes elliptiques équivaut en terme de niveau de sécurité à une clé RSA de 1024 bits. 8.2.2 Vers d’autres mondes Plates-formes de services ouvertes Les applications dont l’architecture peut évoluer dynamiquement en cours d’exécution sont un domaine de recherche en vogue actuellement. Le besoin principal vient du fait que certaines applications sont sensibles à leur contexte ou peuvent avoir besoin de charger/mettre à jour/décharger certains de leurs modules sans pour autant pouvoir interrompre leur exécution. La spécification Open Service Gateway Interface (OSGi) [97] se présente actuellement comme le standard de fait pour ces plates-formes. Eclipse, l’interface de développement GPL développée initialement par IBM, a remplacé son système de plug-ins par des services OSGi permettant à l’application d’évoluer, de se reconfigurer en temps réel sans redémarrage. L’architecture d’une plate-forme OSGi (figure 8.1) se compose d’une plate-forme de services FIG. 8.1 – Architecture OSGi 134
Section 8.2. Perspectives ouverte ; elle représente l’environnement logiciel permettant de gérer le cycle de vie d’autres applications. Au sein de cette plate-forme, des bundles qui représentent des espaces de services, permettent d’exposer un certain nombre de services. Actuellement, la spécification OGSi ne possède pas de notion concernant la distribution des services. Les recherches visant à introduire cette notion de distribution n’en sont encore qu’à leurs débuts. Il serait intéressant d’étudier les fonctionnalités que peut apporter notre mécanisme de sécurité au sein d’une telle plate-forme. Comme première approche permettant de visualiser ce qui pourrait être fait, nous pouvons établir un parallèle entre les divers éléments d’une infrastructure OSGi et une infrastructure ProActive . Le runtime correspondrait à la plateforme d’accueil OSGi, les applications aux bundles et les objets actifs aux services. Environnement ubiquitaire Ce manuscrit a permis de présenter un nouveau modèle d’infrastructure de sécurité (les entités sécurisées) et leur intégration au sein de la bibliothèque ProActive . Cependant, nous pensons que les configurations qui ont donné naissance à ce modèle peuvent se retrouver dans d’autres environnement que les applications distribuées. tel-00239252, version 1 - 5 Feb 2008 Nous pensons tout particulièrement aux Smart Devices et aux Pervasive networks. L’infrastructure de ces environnements se compose d’un ensemble d’éléments hétérogènes (capteurs, moteurs, ordinateurs) interagissant entre eux afin de mener à bien leurs missions. Les réseaux de capteurs, par exemple, sont des architectures ouvertes dans lesquelles n’importe quel intrus peut potentiellement intercepter les communications ou encore émettre de faux messages. Afin de garantir ces communications, il est nécessaire d’utiliser des protocoles cryptographiques. Chaque capteur doit pouvoir être identifié ainsi que les messages qu’il émet. Le principal problème de sécurité consiste en la génération, la diffusion ou encore l’invalidation des clés ou des certificats. Il serait intéressant d’étudier l’adéquation de notre modèle de sécurité avec un réseau de capteurs et notamment notre façon d’attribuer des certificats aux divers capteurs. On peut, en effet, mettre en avant une similitude, au niveau conceptuel, entre les objets actifs et les capteurs. Chacun dans leur domaine, ces unités de base doivent coopérer afin de réaliser une tâche précise. 135
Page 1 and 2:
THÈSE DE DOCTORAT École doctorale
Page 3 and 4:
tel-00239252, version 1 - 5 Feb 200
Page 5 and 6:
Table des matières Remerciements x
Page 7 and 8:
TABLE DES MATIÈRES 6.3.3 Optimisat
Page 9 and 10:
Table des figures tel-00239252, ver
Page 11 and 12:
Liste des tableaux 2.1 Niveau de co
Page 13 and 14:
Remerciements Mes remerciements von
Page 15 and 16:
Chapitre 1 Introduction tel-0023925
Page 17 and 18:
Section 1.1. Problématique et obje
Page 19 and 20:
Chapitre 2 Théories et Modèles Ce
Page 21 and 22:
Section 2.2. Vulnérabilités des s
Page 23 and 24:
Section 2.3. Le contrôle d’accè
Page 25 and 26:
Section 2.4. Introduction à la cry
Page 27 and 28:
Section 2.4. Introduction à la cry
Page 29 and 30:
Section 2.5. Les infrastuctures à
Page 31 and 32:
Section 2.6. Les politiques de séc
Page 33 and 34:
Section 2.6. Les politiques de séc
Page 35 and 36:
Section 2.7. Programmation Réflexi
Page 37 and 38:
Section 2.7. Programmation Réflexi
Page 39 and 40:
Section 2.8. Sécurisation du code
Page 41 and 42:
Section 2.9. Conclusion ce contexte
Page 43 and 44:
Chapitre 3 Étude d’intergiciels
Page 45 and 46:
Section 3.2. Open Grid Service Arch
Page 47 and 48:
Section 3.2. Open Grid Service Arch
Page 49 and 50:
Section 3.3. CORBA // recuperation
Page 51 and 52:
Section 3.4. Les Entreprise JavaBea
Page 53 and 54:
Page 55 and 56:
Page 57 and 58:
Section 3.5. La plateforme .NET sé
Page 59 and 60:
Section 3.5. La plateforme .NET } L
Page 61 and 62:
Section 3.6. Bilan Legion Globus CO
Page 63 and 64:
Chapitre 4 Contexte : ProActive tel
Page 65 and 66:
Section 4.2. Objets Actifs objet. t
Page 67 and 68:
Section 4.3. Sémantique des commun
Page 69 and 70:
Section 4.5. Communications de grou
Page 71 and 72:
Section 4.5. Communications de grou
Page 73 and 74:
Section 4.6. Déploiement des appli
Page 75 and 76:
Section 4.6. Déploiement des appli
Page 77 and 78:
Section 4.7. Conclusion Le con
Page 79 and 80:
Chapitre 5 Une architecture de séc
Page 81 and 82:
Section 5.2. Un modèle de sécurit
Page 83 and 84:
Page 85 and 86:
Page 87 and 88:
Section 5.3. Authentification des e
Page 89 and 90:
Page 91 and 92:
Page 93 and 94:
Section 5.4. Politiques de sécurit
Page 95 and 96:
Section 5.4. Politiques de sécurit
Page 97 and 98: Section 5.5. Négociation Dynamique
Page 99 and 100: Section 5.5. Négociation Dynamique
Page 101 and 102: Section 5.6. Sécurité induite par
Page 109 and 110: Section 5.7. Propagation dynamique
Page 111 and 112: Section 5.8. Exemple du journal int
Page 113 and 114: Chapitre 6 Implantation dans ProAct
Page 115 and 116: Section 6.1. Création des entités
Page 117 and 118: Section 6.2. Interface de programma
Page 119 and 120: Section 6.3. Migration et sécurit
Page 121 and 122: Section 6.4. Communications de grou
Page 123 and 124: Section 6.4. Communications de grou
Page 125 and 126: Section 6.5. Architecture pair-à-p
Page 127 and 128: Section 6.5. Architecture pair-à-p
Page 129 and 130: Section 6.6. Tolérance aux pannes
Page 131 and 132: Section 6.7. Modèle à composants
Page 133 and 134: Section 6.7. Modèle à composants
Page 135 and 136: Section 6.8. Sémantique des commun
Page 137 and 138: Section 6.9. Conclusion Pour qu’u
Page 139 and 140: Chapitre 7 Tests et performances 7.
Page 141 and 142: Section 7.2. Les itérations de Jac
Page 143 and 144: Section 7.2. Les itérations de Jac
Page 145 and 146: Chapitre 8 Conclusion Ce chapitre r
Page 147: Section 8.2. Perspectives tel-00239
Page 151 and 152: Annexe A Grammaire de la politique
Page 153 and 154: Bibliographie tel-00239252, version
Page 155 and 156: BIBLIOGRAPHIE tel-00239252, version
show all

these doctorat une architecture de securité

Create successful ePaper yourself

Delete template?

Save as template?