Contributions de l’ENST Bretagneà l’ACI Dispo

RSM/SERES

- 2 -

Résumé des contributions

• Modèle de sécurité NOMAD

• Expression de politiques de disponibilité

• Disponibilité effective par construction dans les réseaux mobiles et fixes

• Identification des obligations pour la disponibilité

• Tissage des aspects de disponibilité

• Analyse de la disponibilité dans les réseaux mobiles

• Applications : TCP/IP et OLSR

• Expression disponibilité/déni de service

• Analyse par model-checking

• Applications : Allocateur de ressource - Philosophes

- 3 -

Propriété de disponibilité

• Définition• Aptitude à répondre à une demanderépondre à une demande d’un service, d’une

ressource en garantissant des contraintesgarantissant des contraintes d’horaires, de délai et de performances

• Politique de disponibilité• Politique d’attente en temps fini• Politique d’attente en temps borné

• MWT : Maximum Waiting Time Policy

• Application aux réseaux ad-hoc• Pas de disponibilité « absolue »

• Mobilité et malveillance

• Disponibilité « faible »• Si une route entre deux nœuds existe, alors communication possible entre ces

nœuds en temps borné

- 4 -

Un nouveau modèle de sécurité pour une meilleure expressivité

• Modèle pour l’expression des

• Privilèges (permission, interdiction et obligation) associés à des actions non atomiques

• Obligations à satisfaire avant l’expiration des délais

• Privilèges contextuels activables lorsque des conditions sont satisfaites

• Un modèle basé sur

• Logique déontique : privilèges sur des actions non atomiques

• Logiques temporelle et temporisée : délais et gardes temporels

- 5 -

Nomad : NoNon atommic aactions and ddeadlines

• Modèle de politique de sécurité• Contrôle d’accès aux services

• Ex. routage et données de routage• Permission, Interdiction

• Contrôle d’usage des services• Ex. transfert et actualisation des données de routage• Obligation

• Prise en compte du facteur temps• Ex. délai de construction d’une (portion de) route• Remplir les obligations en respectant les délais• Sinon violation

• Prise en compte du contexte• Ex. la mobilité, la réputation

• Sémantique des mondes possibles et axiomatique complète

Article CSFW’2006

- 6 -

Nomad : dérivation des aspects de disponibilité

• Mise en œuvre de la politique de disponibilité• Dérivation et tissage des aspects de disponibilité• Application à un protocole du réseau fixe

Aspects fonctionnels

Aspects de disponibilité

Règles de tissage

Tisseur AOPComposition des aspects

de disponibilité et des aspects fonctionnels

Article ARES’2006

- 7 -

Analyse de la dispo dans les réseaux mobiles

• Expression de propriétés élémentaires

• Analyse d’un protocole ad hoc• Identifier les points de contrôle

• Approche de détection de comportement malveillant orientée propriétés• Mise en œuvre dans un protocole proactif représentatif

• Tissage des aspects correspondants• Approche générique en cours

• Cf. Topo de Tony RAMARD

Article en cours de soumission ICWMC’2007

- 8 -

Rapport technique :

Travaux de Master 2 Recherche

Vérification de la dispo par model-checking

• Vérification de la correction et de la stabilité du routage fourni par OLSR• En Promela/Spin• Avec SMV d’une version synchrone du protocole

• Analyse de la disponibilité et de la régularité de OLSR• En Uppaal

• Objectif• Exploration du protocole OLSR et de ses propriétés de sécurité

nominales

• Résultat lié à la méthodologie de vérification• Explosion combinatoire dès 4 nœuds : résultat attendu

• Résultat• Identification des éléments d’indisponibilité de OLSR

- 9 -

Expression de la disponibilité

• Environnement malveillant =• Certains acteurs peuvent coopérer pour créer des dénis de

service

• Disponibilité forte =• Il suffit que le demandeur et le fournisseur du service coopèrent

pour que le service soit rendu, quel que soit le comportement des autres acteurs du système• Suffisant pour se protéger de tout déni de service dans un environnement

"malveillant"

• Disponibilité faible = • Il est nécessaire que le demandeur et le fournisseur du service

coopèrent avec au moins un autre acteur du système pour que le service soit rendu• Détermine des attaques de déni de service potentielles• Suffisant dans un environnement "bienveillant"