vérification étendue d'un protocole de routage sécurisé...

Introduction Méthodologie Protocole SUAP Performances de SUAP Conclusions & Perspectives

Vérification étendue d’un protocole de routage sécurisé pourles réseaux UAANET

Jean Aimé Maxa, Nicolas Larrieu, Mohamed Slim Ben Mahmoud

Journée de présentations des doctorants

Chantier Sécurité et Vie Privée du RTRA STAE

Laboratoire d’accueil: ENAC, axe ResCo de l’équipe TELECOMEcole doctorale: Systèmes (EDSYS)

1/26


Plan

1 Introduction et contexte du travail

2 Élaboration d’une méthodologie de prototypage rapide

3 Création du protocole SUAP (Secure UAV Ad hoc routingProtocol)

4 Validation des performances du protocole SUAP

5 Conclusions & Perspectives

2/26


Pourquoi un réseau Ad hoc ?

Réseau UAANET (UAV Ad hoc Network)

Réseau ad hoc mobile (MANET - Mobile ad hoc Network) où lesnœuds sont des drones et des stations sol

Caractéristiques spécifiques :

Faible densité de nœuds, mobilité spécifique (3D), connectivitéintermittente.

3/26


Besoins de sécurité

Vulnérabilités des réseauxMANET

Canal de communicationvulnérable

Absence d’une ligne dedéfense

Problème de coopération

Attaques sur le routageAttaque Blackhole : générationde paquets falsifiés permettantd’établir une route erronée

Attaque Wormhole :coordination entre deux ouplusieurs attaquants pour créerun tunnel et intercepter letrafic

Contexte UAANETLe protocole de routage doit être robuste aux différentes attaques

1 L’authentification des paquets de routage est primordiale pour lasurvie de la mission

2 Les attaquants ne doivent pas pouvoir falsifier le choix d’une route

4/26


Contexte de travail : vérification et validationde la sûreté pour une flotte de drones

Sûreté de fonctionnementAnticiper les défaillances et lespannes

[DO 178 B], [DO 178 C] :normes de certification dulogiciel pour l’avionique

Vérification de conformité entrele code source et l’architecurelogicielle durant la conception

Besoin de validationAssurer que la flotte dedrones n’entre pas encollision avec d’autressystèmes (UTM : UASTraffic Management)

Nécessite une méthodologiequi prenne en comptel’évaluation et lacertification du logicielproduit

Contribuer à la validation (dans le but d’obtenir une certification)du système UAS utilisé

5/26


Plan






6/26


Méthodologie de développement

7/26


Plan






8/26


Objectif du protocole SUAP

Proposer une route fiable1 Authentifier les messages de routage

Eviter les modifications non autorisées des messages de routageEviter les attaques conduisant à la dégradation de performance

2 Protéger contre l’attaque wormholeAssurer que les paquets de routage ne passent pas par un tunnelwormhole

9/26


Objectif du protocole SUAPProposer une route fiable

1 Authentifier les messages de routageEviter les modifications non autorisées des messages de routageEviter les attaques conduisant à la dégradation de performance

2 Protéger contre l’attaque wormholeAssurer que les paquets de routage ne passent pas par un tunnelwormhole

9/26


Mécanismes de sécurité mis en oeuvre dansSUAP

Champs non mutables

Utilisation d’une signaturenumérique

Algorithme utilisé RSA

Champs mutables

Utilisation d’une chaine dehachage (en incluantl’identité du prochain nœuddans la table)

Algorithme utilisé SHA-256(peut également utiliser lesautres variantes SHA)

La contribution porte sur l’implémentation orientée modèle de cesmécanismes et les validations formelles qui en découlent

10/26


Nouveaux mécanismes de sécurité proposéspour SUAP

RaisonnementL’attaque wormhole diminue d’une manière significative le nombrede sauts d’une source vers une destination.

Il est possible de connaitre la distance relative entre deux voisins(synchronisation des nœuds)

On considère le problème en deux dimensions

PropositionRelation entre le nombre de sauts et la distance géographique entreles nœuds

Inclusion de l’identité des nœuds légitimes dans le calcul del’empreinte (valeur de hash)

11/26


Nouveaux mécanismes de sécurité proposéspour SUAP

11/26


Illustration de l’échange des paquets Hello

T = distance totale de la route légitimehc = valeur virtuelle du nombre de sauts

TDmax − 1 ≤ hc <

TDmax + 1

(1)avec

T =n∑

i=0,j=0Ri ,j

Dr1 envoi un paquet Hello aunœud Dr2

Dr2 calcule la distance relativeet déduit la valeur virtuelle dunombre de sauts

Dr2 compare le nombre de sautsvirtuel avec le nombre de sautsinclus dans le paquet.12/26


Illustration de l’échange des paquets Hello

T = distance totale de la route légitimehc = valeur virtuelle du nombre de sauts

TDmax − 1 ≤ hc <

TDmax + 1

(1)avec

T =n∑

i=0,j=0Ri ,j

Dr1 envoi un paquet Hello aunœud Dr4 à travers le tunnel

Dr4 calcule la valeur virtuelle dunombre de sauts

Dr4 compare les deux valeurs denombre de sauts et constatel’anomalie

12/26


Mécanismes de sécurité contre l’attaquewormhole

13/26


Illustration de l’échange des paquets dedécouverte de route

Opération sur le nœud Dr1Calcul de Hashold

Calcul de Hashnew =H(Dr1,Dr2,Hashold)

Dr1 ⇒ Dr2 :[64,H, sign,Hashnew ,Hashold ]

Opération sur le nœud Dr2Calcul de Hashverifier =H[Dr1,Dr2,Hashlold ]

Comparaison de Hashverifier etHashnew

Si Hashverifier = Hashnew ⇒il n’y a pas de tunnel wormhole

14/26


Illustration de l’échange des paquets dedécouverte de route

Opération sur le nœud Dr1Calcul de Hashold

Calcul de Hashnew =H(Dr1,Dr2,Hashold)

Dr1 ⇒ Dr2 :[64,H, sign,Hashnew ,Hashold ]

Opération sur le nœud Dr4Calcul de Hashverifier =H[Dr1,Dr4,Hashlold ]

Comparaison de Hashverifier etHashnew

Hashverifier 6= Hashnew ⇒ il yun tunnel wormhole

14/26


Mise en œuvre grâce à des modèles àétats-transitions

15/26


Vérification étendue du protocole SUAP

Vérification formelle des propriétés de sécurité avec AVISPA

ObjectifsVérifier l’utilité des contre-mesuresTrouver des variantes d’attaques auxquelles SUAP serait vulnérable

RésultatsPropriétés du protocole SUAP conformes aux objectifs de sécuritéattendus

16/26


Plan






17/26


Topologie de test pour les fonctions desécurité

Permet de valider les classes departition de sécurisation des traficsde routage

Fonctions d’authentification etd’intégrité

Protocole AODV modéliséet SUAP modélisé

IEEE 802.11g

18/26


Délai de bout en bout et délaid’acheminement des trafics vidéo

0

2000

4000

6000

8000

10000

12000

[6.5−7] [7−7.5] [7.5−8] [8−8.5] [8.5−9] [9−9.5] [9.5−10] [10−15] [15−20] [20−25] [25−50][50−100]

Occure

nces

Intervalle de délai

Proportion du délai de bout en bout

1637

10052

3670

17081300

906501

24340 19 11 7

Délai pour traficde signalisation Valeurs

Délai moyen 7.43 msDélai maximum 100 msDélai pour traficde charge utile Valeurs

Délai moyen 9.2 msDélai maximum 104 ms

ConclusionLe délai nécessaire pour authentifier les paquets ne pénalise pasl’échange des trafics temps réel

19/26


Taux de connectivité et de livraison desdonnées

0

10

20

30

40

50

60

70

80

90

100

AODV(1) SUAP(1) AODV(2) SUAP(2)

Taux d

e liv

rais

on

(%

)

Protocole (attaquants)

Taux de livraison

40.50

90.00

5.68

88.50

0

10

20

30

40

50

60

70

80

90

AODV(1) SUAP(1) AODV(2) SUAP(2)C

onn

ectivité

(en %

)Protocole (attaquants)

Taux de connectivité

10.80

88.20

4.30

88.10

ConclusionAODV souffre de l’effet de l’attaque blackhole.

Avec SUAP, la connectivité est maintenue

20/26


Validation des mécanismes contre l’attaquewormhole

Paramètres ValeurNombre de nœuds légitimes 5 (4 drones et une station sol)Mobilité Rejeu de scénarios de mobilité réelsProtocole de routage SUAP et AODV modéliséProtocole MAC Couche d’accès idéaleTrafic applicatif généré trafic C2 et vidéo

21/26


Validation des mécanismes contre l’attaquewormhole

Objectif1 Étudier la capacité de SUAP à

détecter l’attaque wormholeprendre des décisions sur le choix d’une route

2 Métrique choisieTaux de création d’une route sur le chemin légitime

Paramètres ValeurNombre de nœuds légitimes 5 (4 drones et une station sol)Mobilité Rejeu de scénarios de mobilité réelsProtocole de routage SUAP et AODV modéliséProtocole MAC Couche d’accès idéaleTrafic applicatif généré trafic C2 et vidéo

21/26


Taux de création d’une route passant par lesnœuds légitimes

0

10

20

30

40

50

60

70

80

90

0 100 200 300 400 500 600

Taux (

%)

Durée de la mission (seconds)

Taux de création d’une route

Taux de route légitime établie avec SUAPTaux de route passant par des attaquants avec SUAP

ConclusionTaux de création d’une route légitime est de 85 % avec SUAPcontre 0 % avec AODV

Avec SUAP, les paquets de données ne sont échangés que sur laroute légitime

22/26



0

10

20

30

40

50

60

70

80

90

100

0 100 200 300 400 500 600

Taux (

%)



Taux de route légitime établie avec SUAPTaux de route passant par des attaquants avec SUAPTaux de route passant par des attaquants avec AODV



22/26



0

10

20

30

40

50

60

70

80

90

100

0 100 200 300 400 500 600

Taux (

%)



Taux de route légitime établie avec SUAPTaux de route passant par des attaquants avec SUAPTaux de route passant par des attaquants avec AODV

Taux de route légitime établie avec AODV



22/26


Plan






23/26


Conclusions

Génie logiciel

Élaboration et validation d’une méthodologie de développement desystèmes embarqués critiques

Utilisation de modèles pour concevoir l’architecture détaillée dusystème

Vérification formelle des modèles et du code source généré

Sécurité des réseaux UAANET

Élaboration et validation du protocole SUAP

Nos résultats valident que SUAP authentifie les messages et protègecontre l’attaque wormhole

SUAP offre un niveau de service acceptable

24/26


Perspectives

Infrastructure de gestion de clé adaptée au contexteUAANET

Proposer une architecture de gestion de clé pour les réseauxUAANET afin de gérer le cycle de vie des clés cryptographiquesutilisées dans la solution SUAP

Sécurité des trafics utiles échangésDéfinir une solution de sécurité applicative pour la confidentialitédes données utiles

Etude de performance complémentaire du protocole SUAPAugmenter le nombre de nœuds durant l’expérimentation réelle

Déployer un attaquant mobile en environnement réel

Tester l’attaque wormhole en environnement réel

25/26


Merci pour votre attention

26/26

Spécification du protocole SUAP avec AVISPAAnalyse de l’authentificationdes messages

Analyse de l’attaque wormhole

RésultatsLe protocole SUAP assure l’authentification des messages

L’attaque wormhole n’est pas solutionnée27/26

Illustration des étapes de vérification formelle

28/26

Description de l’attaque Blackhole

Single blackholeL’attaquant jette tous lespaquets de donnés qu’il reçoit

L’attaquant propose demeilleures routes (en jouant surle nombre de sauts)

Collaborative blackholePlusieurs nœuds malveillantsattaquent le réseausimultanément

29/26

Format du paquet requête

30/26

Architecture générique de conception pour lapartition de routage

31/26

VirtualMesh : lien entre tests réel et tests ensimulation

32/26

Taux de connectivité des protocoles enenvironnement émulé

20

30

40

50

60

70

80

90

100

AODV DSR OLSR

Connectivité

(en %

)

Protocole

Connectivité en état instable

90.65

58.20

24.10

60

60.5

61

61.5

62

62.5

63

63.5

AODV DSR OLSR

Connectivité

(en %

)

Protocole

États instables / Durée de simulation

62.90

61.70

60.40

ConclusionAODV présente de meilleures connectivités en états instables

33/26

Délai moyen de bout en bout et délai dereconstruction d’une route en environnement

émulé

5

6

7

8

9

10

11

AODV DSR OLSR

Déla

i (e

n m

s)

Protocole

Délai moyen de bout en bout

5.32

10.15

5.91

1.5

2

2.5

3

3.5

4

4.5

5

5.5

6

6.5

AODV DSR OLSR

Déla

i (e

n m

s)

Protocole

Délai moyen de reconstruction d’une route

1.94 1.90

5.77

33/26

Durée de vie moyenne d’une route

Stabilité d’une routeDurée de vie moyenne d’une route : 14.328955 s

0

5

10

15

20

25

30

35

12mn 16mn 20mn 24mn

aver

age

lifet

ime

(sec

ond)

Delay (minutes)(number of occurrences of route loss)

Route stability

’restablish.out’

34/26

Variation de la durée de vie de route enfonction de la force du signal reçu

−75

−70

−65

−60

−55

−50

−45

−40

−35

−30

0 5 10 15 20 25 30 35

Sig

nal s

tren

gth

(en

dbm

)

Times ( minutes)

Variation of route lifetime depending on signal strength

’puissanceetstability.dat’ using 2:3

35/26

Délai de rétablissement d’une route après uneperte de route

0.0005

0.001

0.0015

0.002

0.0025

0.003

0.0035

0.004

0.0045

0.005

12mn 16mn 20mn 24mn

Del

ay (

in s

econ

ds)

Delay (in minutes)(number of occurrences of route re−establishment)

Average delay to re−establish route

’recup.dat’

36/26

vérification étendue d'un protocole de routage sécurisé...

Documents