Embed Size (px)
Citation preview
Une approche UML pour l’analyse temporelle de communications de groupes sécurisées S. Mota* — T. Villemur* * Laboratoire d’Analyse et d’Architecture des Systèmes 7 avenue du Colonel Roche 31 077 Toulouse cedex 04, France {smota, villemur}@laas.fr RÉSUMÉ. Dans le monde des systèmes qui utilisent des communications sous forme de diffusion de groupes, le critère de sécurité devient un facteur de plus en plus important. La difficulté d’assurer des communications sécurisées augmente avec la prise en compte des caractéristiques intrinsèques des groupes en termes de structure organisationnelle et d’évolution dynamique dans le temps. La complexité de leurs interactions justifie pleinement le recours à des techniques de modélisation et de vérification formelles. Dans ce contexte, à partir d’une analyse UML des fonctionnalités nécessaires pour un système de communication de groupe sécurisé, cet article présente une architecture générique pour étudier et modéliser de tels systèmes. L’utilisation du profil UML TURTLE et de ses outils de support à cette architecture, permet de délimiter les contraintes temporelles requises par les mécanismes de sécurité utilisés. L’application de cette approche s’est déroulée dans le cadre du projet SAFECAST pour une application de radiocommunication mobile. Elle a permis de fixer les limites temporelles des mécanismes proposés pour cette application. ABSTRACT. Within systems using group multicast, security become a more and more important parameter. The difficulty to guarantee secure communications increases when intrinsic characteristics of groups are taken into account in term of structure and dynamic evolution in time. The interaction complexity fully justifies the use of modelling techniques and formal verification. Inside this context, starting from a UML analysis of functionalities required for secure group communication systems, this paper presents a generic architecture for modelling such systems. The use of UML profile TURTLE and tools that support this architecture is required for analysing the temporal constraints of the proposed security mechanisms. This approach has been applied in the framework of the SAFECAST project for a mobile radiocommunication system. It has fixed the temporal limits of the proposed mechanisms for this system. MOTS-CLÉS : Services sécurisés, Communications de groupe, Conception formelle, Vérification temporelle, UML. KEYWORDS: Secure services, Group communications, Formal design, Temporal verification, UML.
Ce travail a été réalisé dans le cadre du projet SAFECAST du RNRT (http://rnrt-safecast.org/
1. Introduction
La nécessité de systèmes sécurisés de communication pour des groupes d’utilisateurs [ZOU 05] pose le problème de la protection des données. Cette protection, qui s’appuie sur un chiffrement de l’information, doit garantir les propriétés d’intégrité et de confidentialité, tout en offrant un degré de réactivité suffisant du système. La prise en compte de la structure intrinsèque des groupes et de leur évolution dynamique dans le temps complexifie l’étude de l’ensemble de ces propriétés. Il est donc nécessaire, dans les phases amont de spécification du système, de procéder à des étapes de modélisation pour précisément caractériser les limites des propriétés de sécurité utilisées, en termes de garanties temporelles.
Dans ce cadre, nous proposons une approche de modélisation et d’études temporelles de propriétés de sécurité, au travers d’un canevas architectural que nous avons défini pour des communications de groupes. De façon plus détaillée, cette approche de modélisation et de vérification du système doit prendre en compte les trois éléments suivants : le premier élément est le développement d’une architecture compatible avec les besoins définis pendant l’étape d’analyse du système. Le deuxième élément contient le choix de la méthodologie de conception et des outils qui la supportent. A partir des deux éléments précédents, le troisième élément s’attache à la modélisation et à la vérification [FON 06] du système. Dans ce contexte, le présent article se focalise sur (i) la détermination des fonctionnalités du système, (ii) la proposition d’une architecture de modélisation et (iii) la vérification temporelle des fonctionnalités proposées.
L’article est structuré de la manière suivante. La section 2 présente la problématique des communications de groupe et de leur sécurisation. La section 3 montre les fonctionnalités identifiées lors de la phase d’analyse du système à développer. L’approche d’analyse temporelle, avec l’architecture de modélisation proposée et l’utilisation du profil TURTLE, fait l’objet de la section 4. La section 5 décrit l’application de cette approche au projet SAFECAST. La section 6 conclut l’article.
2. Communications de groupes sécurisées
La protection des données s’appuie le plus généralement sur des techniques de chiffrement au moyen de clés [ZOU 05]. Deux types d’algorithmes existent, asymétriques ou bien symétriques. Les algorithmes asymétriques, qui utilisent une paire de clés publique et privée, sont bien adaptés à des échanges point-à-point. Cependant, leur utilisation dans des communications de groupes s’avère trop lourde au vu de la combinatoire des couples de clés et de leur charge de calcul. De plus, la complexité du chiffrement asymétrique compromet le passage à l’échelle. Ceci explique que la majorité des travaux autour des communications de groupes utilisent des algorithmes symétriques à clé secrète qui gèrent une clé partagée (clé de
Une approche UML pour l’analyse temporelle de communications de groupes sécurisées
groupe). De façon plus précise, ces travaux se basent sur l’algorithme distribué et contributif de Diffie et Hellman [DIF 76], puis utilisent une des extensions qui ont été proposées pour des groupes.
Dans le domaine des systèmes distribués qui gèrent des groupes de processus, des couches logicielles qui augmentent la sécurité et la confidentialité des échanges ont été récemment implantées. Le système Ensemble [ROD 01], qui provient des systèmes de communications de groupe plus anciens ISIS et HORUS, ajoute une couche de sécurité. Il supporte le partitionnement multiple, permet un calcul de clés de groupe efficace, et offre plusieurs politiques de sécurité définies au niveau applicatif. Le système Secure Spread implante 5 protocoles de génération de clé différents, dont la majorité sont des extensions du protocole de groupes de Diffie et Hellman. Le choix entre les divers protocoles permet à l’utilisateur d’établir, un compromis sécurité-performance selon ses besoins. La principale faiblesse de Secure Spread est qu’il repose sur des serveurs qui ne doivent pas être défaillants.
Une grande partie des langages de modélisation associés à un outil de vérification, qui étudient des protocoles de sécurité, sont basés sur des règles de réécriture. Nous pouvons citer CASRUL et AVISPA comme environnements représentatifs [FON 06]. La principale faiblesse de ces outils est de ne pas prendre en compte le temps. A l’opposé, nous trouvons quelques environnements plus généraux, basés sur des systèmes de transitions, qui manipulent du temps et qui commencent à être utilisés pour l’analyse de protocoles de sécurité. Parmi cette classe d’outils, nous pouvons citer UPPAAL et TURTLE [FON 06]. L’utilisation de ces environnements, et leur adaptation aux spécificités des protocoles de sécurité, doit se faire par la proposition et l’utilisation de méthodologies qui assisteront le concepteur dans sa démarche analytique [APV 06].
3. Fonctionnalités pour des communications de groupes sécurisés
Les fonctionnalités et rôles que nous avons isolés sont mis en œuvre lorsque la session est active, c’est-à-dire lorsque les membres sont présents dans le groupe et qu’ils communiquent entre eux. Nous n’avons pas décrit les fonctionnalités nécessaires en dehors des sessions (par ex. la création des droits des membres et des types de groupes) car elles ont moins de contraintes en terme d’interactivité et de garanties de sécurité.
Pendant une session active, deux grandes classes de fonctionnalités sont définies : celles de sécurité et celles intra-groupes. Chacune d’entre elles, expliquée par la suite, est représentée par un diagramme de cas d’utilisation UML. D’autres types de diagrammes UML, notamment les diagrammes de séquence, ont été utilisés pour spécifier de manière plus fine les fonctionnalités isolées.
3.1. Rôles pour structurer les groupes
La composition des groupes pour des communications sécurisées s’appuie sur une organisation en rôles. En effet, cette organisation nous semble assez proche du niveau applicatif et suffisamment liée aux caractéristiques des systèmes que nous souhaitons décrire (des groupes supportant des hiérarchies d’utilisateurs humains) ; De plus, ce découpage est assez général pour représenter des groupes structurés sous forme hiérarchique (membres avec des rôles de différente importance) ou structurés sous forme plane (membres avec des rôles identiques). Un rôle représente pour un membre l’accès à un ensemble de ressources et confère à un membre un ensemble de droits et de fonctions. Chaque rôle est lié à la mise en œuvre d’une fonctionnalité. Les rôles que nous avons identifiés apparaîtront par la suite dans les diagrammes de cas d’utilisation (Fig. 1).
Dans le cadre d’une session active, le rôle « Member » est pris par chaque membre présent. Le rôle « ChiefMember », qui étend le rôle « Member », est détenu par le(s) chef du (des) groupe(s). Ce rôle permet d’être informé de l’état courant du groupe et autorise la supervision du groupe. Lors de la phase de création et de distribution des clés, le rôle « Supervisor » est détenu par la(les) personne(s) qui génère(nt) et distribue(nt) la clé. Les autres membres conservent le rôle « Member ». Pour traiter de la dynamique au sein d’un groupe, nous distinguons les rôles suivants : le rôle « ConcernedMember » désigne le membre qui va entrer/sortir d’un groupe, ou bien se déplacer dans la hiérarchie du groupe. Le rôle « Administrator » est détenu par la personne qui a le droit de faire descendre, monter ou exclure un membre. Ce dernier rôle peut être détenu par un chef du groupe ou par tout membre autorisé. Le rôle « ContactedMember » intervient lorsque des membres sont sortis temporairement du groupe, suite à des problèmes de communications. Ce rôle est pris par le membre qui autorise la reconnexion.
3.2. Fonctionnalités de sécurité
Ces fonctionnalités supportent les mécanismes de contrôle d’accès et de confidentialité des échanges dans les groupes pendant la durée d’une session, y compris lors de son évolution dynamique. Ces mécanismes seront basés sur des clés de groupe symétriques. En effet, l’emploi de combinaisons de couples de clés asymétriques nous semble difficilement gérable et utilisable pour des diffusions de groupes. La Fig. 1 (a) montre le diagramme de cas d’utilisation regroupant ces fonctionnalités.
La fonction « RenewKeyHierarchical » sert à générer et à renouveler les clés de communication dans des groupes de structure hiérarchique. Ces deux fonctions utilisent les fragments « DistributeKeyHierarchical» et « DistributeKeyPlane» comme montré dans le diagramme. Ces deux fragments héritent du fragment générique « DistributeKey ». Pour maintenir un niveau de sécurité suffisant, la
Une approche UML pour l’analyse temporelle de communications de groupes sécurisées
fonction « RenewBasePeriodicKey» sert à renouveler périodiquement les clés toutes les « N » heures dans le système. Les deux fonctions non détaillées « RenewMergedGroupKey» et « Renew PeriodicMergedGroup» interviendront pour de futures extensions à nos travaux, pour gérer des fusions et des séparations de groupes.
(a) Gestion des Mécanismes de Sécurité (b) Gestion intra groupe
Figure 1. Fonctionnalités pour des groupes sécurisés
3.3. Fonctionnalités intra-groupes
Les fonctionnalités intra-groupes traitent de la gestion des groupes de communication, et plus précisément de la dynamique à l’intérieur d’un même groupe. Deux acteurs particuliers de la Fig. 1 (b) représentent de façon agrégée un ensemble de membres au sein d’un groupe. On trouve ainsi la classe « Group » qui représente les membres d’un groupe, et la classe « Medium » qui modélise le médium de communication.
La Fig. 1 (b) montre le diagramme de cas d’utilisation regroupant ces fonctionnalités. Les fonctionnalités intra-groupes comprennent, l’entrée « Join », la sortie « Leave » d’un membre, la descente dans la hiérarchie « Downgrade », la montée dans la hiérarchie « Upgrade », la reconnexion « Reconnect » applicable lorsqu’un membre qui appartenait au groupe a perdu la connexion et, finalement, la fonctionnalité « Reinstat » si le membre concerné était exclu. Ces fonctionnalités utilisent toutes le fragment « ConnectMember» qui contient l’action de se connecter à un groupe. La fonctionnalité générique « ExcludeGroupMember» traite l’exclusion d’un membre. Elle intervient pour son exclusion définitive du groupe.
4. Approche d’analyse temporelle
L’approche que nous souhaitons mettre en œuvre s’appuie, à partir des fonctionnalités précédemment identifiées, sur la proposition d’une architecture générique pour modéliser des protocoles de communication de groupes sécurisés. L’étude des validités temporelles des mécanismes utilisés au sein de cette architecture se fera en utilisant un outil d’analyse formel : l’environnement TURTLE.
4.1. Architecture proposée
A notre connaissance, il n’existe pas de patron d’architecture communément admis pour modéliser des systèmes de sécurité [AMI 05]. Dans la lignée du modèle de référence OSI (Open System Interconnection), nous avons développé quatre niveaux sous la forme de couches indépendantes qui composent l’architecture de modélisation que nous proposons (Fig. 2). Les niveaux les plus bas se chargent des opérations de communication sécurisées. Les deux niveaux les plus hauts se chargent des opérations de gestion des éléments mis en œuvre (clés et groupes). Au niveau applicatif, se trouvent les membres connectés au système.
4.1.1. Services de diffusion sécurisée
La première couche de communication, la plus basse, Medium, offre les services élémentaires de diffusion multipoint. Trois types de services ont été définis dans ce médium : un service de communication point-à-point, un service multipoint (de 1 vers N) et un service de diffusion (1 vers tous).
La deuxième couche, Security Operators (SO), offre les actions élémentaires de sécurité qui garantissent l’intégrité, la confidentialité et le non rejeu. On trouve des opérations de Hashing pour garantir l’intégrité des données, des opérations de Chiffrement qui servent à la confidentialité et d’empêchement de rejeu avec l’utilisation d’Index.
4.1.2. Services de gestion
La couche Group Communication Key Management (GCKM) gère les opérations liées à la sécurisation des groupes, opérations liées aux clés de session. Le service de renouvellement de clés inclut les deux sous-services : la génération et la distribution des clés. Les clés de session générées sont destinées à chaque niveau de hiérarchie d’un groupe de communication. La distribution des clés se fait selon deux cas : entre des chefs d’un groupe, à l’intérieur d’un groupe. Le renouvellement des clés doit se faire en maintenant l’intégrité du système vis-à-vis des changements des rôles et des entrée/sorties des utilisateurs.
La couche supérieure, Group Membership Mechanisms (GMM), se charge des éléments de gestion de groupes en contrôlant leur structure, leur évolution et leur
Une approche UML pour l’analyse temporelle de communications de groupes sécurisées
dynamique. Cette couche intègre les fonctionnalités intra groupes précédemment identifiées, intégration faite sous la forme d’un service par fonctionnalité. Le fonctionnement de ces services se fait en relation avec les mécanismes de gestion des clés de session sous-jacents et l’utilisation des rôles qui donnent des droits aux membres.
Figure 2. Architecture de modélisation de communications de groupes sécurisées
Le but de l’architecture que nous proposons est de rester le plus générique possible et de servir de cadre d’analyse à divers mécanismes de sécurité. Ces mécanismes sont, soit plus liés à l’aspect de bas niveau communication, soit plus proches des niveaux de gestion des groupes et des éléments de sécurité. Cette analyse et cette vérification interviendront sur l’ensemble des fonctionnalités mises en œuvre dans le système.
4.2. Profil UML TURTLE
Le profil UML (Unified Modeling Language) temps réel TURTLE (Fig. 3) spécialise la notation de l’OMG (Object Management Group) pour modéliser des systèmes temps réel et distribués, dans lesquels le respect de contraintes temporelles est une préoccupation première. Le profil TURTLE [APV 04] a une sémantique formelle exprimée dans l’algèbre de processus RT-LOTOS à laquelle il emprunte en particulier la communication par rendez-vous entre objets et la possibilité d’introduire de l’indéterminisme temporel dans le comportement des objets. Il est particulièrement adapté à la description d’actions avec des durées et, par la suite, à la vérification du respect d’exigences et de contraintes temporelles.
Security Operators SO
Medium
Group MembershipMechanisms
GMM
Group Communication
Key Management
GCKM
User #1
Group MembershipMechanisms
GMM
Group Communication
Key Management
GCKM
User #2
Group MembershipMechanisms
GMM
Group Communication
Key Management
GCKM
User #N
…
Secure multicast services
Management services
Security Operators SO
Medium
Group MembershipMechanisms
GMM
Group Communication
Key Management
GCKM
User #1
Group MembershipMechanisms
GMM
Group Communication
Key Management
GCKM
User #2
Group MembershipMechanisms
GMM
Group Communication
Key Management
GCKM
User #N
…
Security Operators SO
Medium
Security Operators SO
Medium
Group MembershipMechanisms
GMM
Group Communication
Key Management
GCKM
User #1
Group MembershipMechanisms
GMM
Group Communication
Key Management
GCKM
User #1
Group MembershipMechanisms
GMM
Group Communication
Key Management
GCKM
User #2
Group MembershipMechanisms
GMM
Group Communication
Key Management
GCKM
User #2
Group MembershipMechanisms
GMM
Group Communication
Key Management
GCKM
User #N
Group MembershipMechanisms
GMM
Group Communication
Key Management
GCKM
User #N
…
Secure multicast services
Management services
Figure 3. Chaîne d’outils TURTLE
Le profil TURTLE est outillé pour éditer des diagrammes et générer deux types de codes : soit du code RT-LOTOS qui permet de réutiliser les outils RTL et CADP à des fins de vérification formelle de modèles TURTLE ; soit du code Java à des fins de prototypage.
La validation des contraintes temporelles se fait par des techniques de minimisation et d’analyse du graphe d’accessibilité du système. Le graphe d’accessibilité qui représente l’ensemble des états stables que le système peut atteindre à partir de son état initial est étiqueté par des informations relatives aux actions exécutées par le système. Dans notre cas, ces étiquettes marquent le début et la fin d’une fonctionnalité du système. Ceci permet, lors de la mise en œuvre automatique de réduction du graphe d’accessibilité en automate quotient par l’outil CADP, de vérifier les durées maxima obtenues par chacune des fonctionnalités du système. On peut ainsi valider des durées pour chaque fonctionnalité, de façon unitaire, mais aussi vérifier des combinaisons par entrelacement ou exécution concurrentes de fonctionnalités.
Cette association de marques temporelles et de techniques de réduction en automate quotient, associée et intégrée dans une chaîne de validation de propriétés temporelles, se révèle particulièrement intuitive et facile à mettre en œuvre pour des non spécialistes. Elle permet très facilement, au moment de la spécification du système, de vérifier quelles seront les durées des mécanismes de sécurité proposés et de confronter ces durées aux exigences temporelles que l’on souhaitait obtenir. Cette approche aide le concepteur à faire des choix en termes de validité temporelle. En effet, ce dernier peut être amené à relâcher, à remplacer, ou à abandonner certains mécanismes de sécurité trop longs à exécuter, ou bien à relâcher certaines exigences temporelles pour maintenir un haut niveau de sécurité, ou bien à faire des compromis temps versus sécurité pour maintenir la réalisation d’un système suffisamment réactif et suffisamment sécurisé.
ReachabilityGraph
Analysis
Analysis of Traces
Simulation
FormalValidation
Minimization
Generationspecification
QuotientAutomaton
Design
AnalysisTTOOL
CADP/Aldebaran
RTL
JAVA Code
Rapid Prototyping
TURTLE Intermediate
Format(TIF)
RT-LOTOSspecification
Une approche UML pour l’analyse temporelle de communications de groupes sécurisées
5. Application
5.1. Projet SAFECAST
Les missions de sécurité civiles et militaires nécessitent la coopération de divers corps d’intervention tels que les secouristes, les pompiers, les policiers. Chaque corps possède ses spécificités en termes de règles hiérarchiques et de commandement. Leurs interventions sur des théâtres d’opération communs impliquent une organisation dynamique des effectifs placés sur le terrain pour former des groupes hétérogènes de par leur corps d’origine, mais structurés et commandés de façon cohérente en fonction des rôles de chacun. Telle est la problématique étudiée par le projet SAFECAST, projet du Réseau National de la Recherche en Télécommunications dédié à l’étude, à la conception et à la validation de fonctionnalités et de mécanismes garants de communications sécurisées à l’intérieur de groupes dynamiques [EAD 04].
Ce projet, qui représente le cadre de nos recherches, porte sur des communications dans des réseaux de diffusion multicast de type Private Mobile Radiocommunication (PMR) utilisés dans des zones d’intervention (incendies, attentats, situation de crise, etc.). Les utilisateurs ont à leur disposition des terminaux mobiles sécurisés qui supportent des flux données et audio. Ils communiquent de façon sécurisée à l’intérieur de leur groupe. Du fait de la dynamique des groupes, les éléments de sécurité devront s’actualiser en ligne pour garantir la sécurité établie lors des spécifications du système.
Les mécanismes de sécurité instanciés dans ce cadre applicatif sont les suivants. Dans les niveaux les plus hauts, le mécanisme le plus important est celui mis en œuvre pour la gestion de la clé de session. Dans le cadre du projet, à cause de l’utilisation de groupes dynamiques, il est nécessaire de mettre en œuvre un algorithme cryptographique symétrique, distribué et contributif, pour la gestion de clés. Le choix s’est porté sur l’algorithme de Diffie et Hellman étendu à un contexte de groupe [DIF 76]. Seuls les chefs de groupe, en petit nombre, utilisent cet algorithme pour générer la clé de session. Ils la diffusent ensuite aux autres membres. Dans les niveaux les plus bas, la clé de session intervient pour les opérations de chiffrement et de déchiffrement mises en œuvre au niveau de la couche physique. L’index utilisé pour le non rejeu contient l’identité de chaque membre.
Au niveau transmission, les débits offerts par le médium radio sont de deux types. La classe bas débit garantit un débit de 6 kb/s avec une portée de 3 km ; la classe moyen débit supporte 100 kb/s avec une portée de 100 km. Ces deux débits correspondent aux valeurs utilisées pour les réseaux radio ad hoc, de type PMR.
5.2. Validation des exigences SAFECAST
L’architecture de sécurité de groupe proposée, instanciée par les mécanismes de sécurité de projet SAFECAST et par le type de réseau utilisé, a été modélisée en utilisant le profil TURTLE. La structuration des principaux modules TURTLE reproduit exactement la structure architecturale de la Fig. 2. L’ensemble des huit fonctionnalités de sécurité et de gestion intra-groupes identifiées (1. Key Generation and Distribution ; 2. Join ; 3. Leave ; 4. Reconnection ; 5. Reinstallation ; 6. Exclusion ; 7. Upgrade ; 8. Downgrade) sont inclues dans la modélisation. Les groupes étudiés comprennent jusqu’à sept membres. Cette section présente les résultats obtenus.
Le tableau 1 liste les exigences temporelles que le système doit respecter par fonctionnalité. Chaque ligne du tableau décrit une exigence temporelle qui doit être vérifiée lors d’un changement dans la composition des groupes. Ces exigences concernent la mise en place de fonctionnalités, les temps de réaction d’un utilisateur pour certaines configurations de groupes, ou bien des temps de détection d’échanges anormaux de messages. Les délais à vérifier proviennent de l’application de communication multipoint radio PMR de SAFECAST. Ils sont assez variables. Certains se situent dans l’échelle de la milliseconde, d’autres utilisent des délais proches de la seconde, les derniers, les plus lâches, mettent en œuvre des exigences de l’ordre de l’heure. La deuxième colonne du tableau donne la limite temporelle à respecter pour chaque exigence. Les huit colonnes suivantes donnent la liste des fonctionnalités étudiées dans le cadre du réseau bas débit dont la valeur est de 6 kbps. Les huit dernières colonnes donnent la liste des fonctionnalités étudiées dans le cadre du réseau moyen débit dont la valeur est de 100 kbps. La valeur F (False) indique que la propriété s’applique à la fonctionnalité étudiée, mais que son exigence temporelle n’est pas satisfaite. De la même façon, la valeur T (True) indique que la propriété s’applique à la fonctionnalité étudiée, et que son exigence temporelle est satisfaite. Une case vide indique qu’une propriété ne s’applique pas à une fonctionnalité.
Par exemple, le délai moyen d’une entrée tardive dans une communication chiffrée (deuxième ligne) doit rester inférieur à 1000 ms. Dans le cas d’un réseau bas débit, cette propriété s’applique sur les trois fonctionnalités Join, Reconnection et Reinstallation. Pour chaque cas, la valeur F est obtenue, ce qui signifie que les exigences de cette propriété ne sont pas respectées pour le réseau bas débit. De la même façon, pour un réseau moyen débit, cette propriété s’applique sur les trois fonctionnalités Join, Reconnection et Reinstallation. Pour chaque cas, la valeur T est obtenue, ce qui indique que les exigences temporelles de cette propriété sont bien respectées pour un réseau moyen débit.
La ligne « Durée obtenue » affiche le temps donné par l’environnement TURTLE par fonctionnalité, pour les réseaux bas et moyens débits. Par exemple, le temps obtenu pour la réalisation de la fonctionnalité Key Generation and
Une approche UML pour l’analyse temporelle de communications de groupes sécurisées
Distribution, dans le cas bas débit est de 1945 ms. Dans le cas moyen débit, ce temps est de 121 ms.
Nous constatons que beaucoup d’exigences temporelles ne sont pas satisfaites lors de l’utilisation de réseaux à bas débit. Par contre, toutes les exigences temporelles sont satisfaites pour des réseaux à moyen débit, sauf le temps d’accès à un groupe multimédia.
Tableau 1. Validation ou invalidation des exigences temporelles
5.3. Bilan des exigences SAFECAST
La conclusion que nous pouvons en tirer est que les mécanismes de sécurité proposés dans le projet SAFECAST sont trop exigeants vis-à-vis des contraintes du réseau à bas débit. Cette non satisfaction de contraintes est détectée par modélisation avant toute mise en œuvre, évitant ainsi de procéder à la réalisation d’un système dont on s’apercevra uniquement lors de son utilisation que les contraintes sont irréalisables. Dans le cas du bas débit, le concepteur devra choisir deux pistes : soit garder des mécanismes sécurisés mais avec des contraintes temporelles plus lâches, soit ne pas utiliser les mécanismes de sécurité s’il ne peut pas relâcher les contraintes. Dans le cas du moyen débit, toutes les exigences temporelles sont satisfaites, excepté le temps d’accès à un groupe multimédia.
Ces résultats mettent en exergue la nécessité de compromis entre l’utilisation de fonctionnalités sûres mais coûteuses en temps versus le respect des performances. Dans un cadre plus méthodologique, ils guident ainsi sur l’identification des compromis à réaliser et sur les choix à effectuer avant toute réalisation.
6. Conclusion
Cet article a présenté l’approche que nous avons proposée pour l’étude et la validation des contraintes temporelles de mécanismes de sécurité, au sein de systèmes de communication de groupes. Le cadre architectural proposé, supporté
FonctionnalitéPropriété
145
482
482
323
323
222
296
121
2 677
5 954
5 954
4 028
4 028
3 284
3 764
1 945 Durée obtenue (ms)
TT60 000 Meilleur temps d'exclusion par un membre ayant les doits d’exclusion (< 1 m)
TT3 600 000 Pire temps d'exclusion d'un membre par un administrateur (< 1 h)
TTTTTTTTTT60 000 Temps d’accès au groupe Messagerie (< 1 m)
FFTTTFFFFF350 Temps d’accès au groupe Multimédia (< 350 ms)
TTTTTTTTTTTTTTTT10 000 Le délai de détection de rejeu (< 10 s)
TTTTTTTTTTTTTTTT10 000 Le délai de détection d’une violation d’intégrité (< 10 s)
TTTFFF2 000 Le délai pire d’une Entrée tardive dans une communication chiffrée (< 2s)
TTTFFF1 000 Le délai moyen d’une Entrée tardive dans une communication chiffrée (< 1s)
TF350 Le délai d’établissement d’une communication chiffrée (< 350 ms)
Exclude
Reinstat
Dow
ngrade
Upgrade
Reconn
Leave
Join
Gen&
Dist
Exclude
Reinstat
Dow
ngrade
Upgrade
Reconn
Leave
Join
Gen&
Dist
Durée limite (ms)
Moy. Débit (100 kb/s)Bas débit (6kb/s)
145
482
482
323
323
222
296
121
2 677
5 954
5 954
4 028
4 028
3 284
3 764
1 945 Durée obtenue (ms)
TT60 000 Meilleur temps d'exclusion par un membre ayant les doits d’exclusion (< 1 m)
TT3 600 000 Pire temps d'exclusion d'un membre par un administrateur (< 1 h)
TTTTTTTTTT60 000 Temps d’accès au groupe Messagerie (< 1 m)
FFTTTFFFFF350 Temps d’accès au groupe Multimédia (< 350 ms)
TTTTTTTTTTTTTTTT10 000 Le délai de détection de rejeu (< 10 s)
TTTTTTTTTTTTTTTT10 000 Le délai de détection d’une violation d’intégrité (< 10 s)
TTTFFF2 000 Le délai pire d’une Entrée tardive dans une communication chiffrée (< 2s)
TTTFFF1 000 Le délai moyen d’une Entrée tardive dans une communication chiffrée (< 1s)
TF350 Le délai d’établissement d’une communication chiffrée (< 350 ms)
Exclude
Reinstat
Dow
ngrade
Upgrade
Reconn
Leave
Join
Gen&
Dist
Exclude
Reinstat
Dow
ngrade
Upgrade
Reconn
Leave
Join
Gen&
Dist
Durée limite (ms)
Moy. Débit (100 kb/s)Bas débit (6kb/s)
par l’environnement TURTLE de modélisation et d’analyse des exigences et des contraintes temporelles, a été instancié dans le cadre du projet SAFECAST. Nous avons pu ainsi vérifier que les mécanismes de sécurité proposés sont trop coûteux en temps dans le cas d’utilisation de réseaux radio à bas débit, obligeant ainsi à faire des compromis sécurité versus temps pour obtenir un système réaliste.
A court terme, nous prévoyons d’utiliser le cadre architectural proposé pour analyser d’autres mécanismes de sécurité ; nous prévoyons notamment de tester des améliorations de l’algorithme de Diffie Hellman pour des clés de groupe, pour s’approcher d’avantage des exigences temporelles non respectées. A moyen terme, nous souhaitons poursuivre nos études sur la structuration des groupes, en ajoutant des mécanismes inter groupes qui prendront en compte des fusions et des séparations de groupes. Les interactions de ces nouveaux mécanismes de gestion de groupe avec les mécanismes de sécurité feront partie des travaux à réaliser. A plus long terme, nous prévoyons de compléter nos travaux par la prise en compte de groupes de tailles plus conséquentes.
7. Bibliographie
[AMI 05] Amir Y., Nita-Rotaru C, Stanton J, Tsudik G. Secure Spread: An integrated Architecture for Secure Group Communication. IEEE Transactions on Dependable and Secure Computing, Sept 2005.
[APV 04] Apvrille L., Courtiat J.P., Lohr C., de Saqui-Sannes P., TURTLE: A Real-Time UML Profile Supported by a Formal Validation Toolkit, IEEE Transactions on Software Engineering, Vol 30, No 7, pp 473-487, Juillet 2004.
[APV 06] Apvrille L., de Saqui Sannes P., Pacalet R., Apvrille A., Un environnement de conception de systèmes distribués basé sur UML, Revue Annales des Télécommunications, Vol.61, N°11-12, pp.1395-1416, 2006.
[DIF 76] Diffie W., Hellman M. E., New Directions in Cryptography. IEEE Transactions on Information Theory, 22, n. 6, p. 644-654 (1976).
[EAD 04] EADS. Projet National SAFECAST. L1.1 Dossier de Définition de l’application de communication de groupe, sept. 2004.
[FON 06] Fontan B., Mota Gonzalez S., Villemur T., de Saqui-Sannes P., Courtiat J.P., UML-Based Modeling and Formal Verification of Authentication Protocols, IEEE International. Symposium on Secure Software Engineering, Washington DC, USA, mars 2006.
[ROD 01] Rodeh O., Birman K.P., Dolev D., “The Architecture and Performance of Security Protocols in the Ensemble Group Communication System: Using Diamonds to Guard the Castle”. ACM Transaction on Information and System Security, Vol. 4, No. 3, August 2001, pp. 289-319.
[ZOU05] Zou X., Ramamurthy B., Magliveras S.S., Secure Group Communications over Data Networks, Springer, 2005.
