Etude de l'impact d’un deploiement d’une architecture de securite multi-domaines

mellowfetaΑσφάλεια

19 Ιουν 2012 (πριν από 5 χρόνια και 2 μήνες)

927 εμφανίσεις

M:Larrieu
M:SlimBenMahmoud
Projet Telecommunication et Reseaux:

Etude de l'impact d'un deploiement d'une
architecture de securite multi-domaines
dans un contexte aeronautique.
Mathieu AUG

E - Alice DE GUILLEBON
25 janvier 2010
Table des matieres
1 Introduction 4
2 IPsec 5
2.1 Mecanismes de securite.................................5
2.2 Presentation d'IPSec..................................5
2.3 Mode de fonctionnement d'IPSec...........................6
2.4 Realisation d'IPSec...................................7
2.5 Synthese.........................................7
3 Architecture de distribution des cles 8
3.1 Principes.........................................8
3.2 Operations realisables par une PKI..........................9
3.3 Prise en compte des PKI dans un contexte aeronautique..............10
4 Realisation des scenarios 11
4.1 Les donnees.......................................11
4.2 Methode.........................................11
4.3 Resultats........................................13
5 Simulations et resultats theoriques 15
5.1

Etude theorique.....................................15
5.2 Simulation avec OPNET................................17
5.3 Resultats........................................20
6 Conclusion 22
A Principaux mecanismes de securite 25
A.1 Cryptage de cle secrete ou cle symetrique.......................25
A.2 Cryptage de clefs publiques/privees ou clefs asymetriques..............25
TABLE DES MATI

ERES 3
A.2.1 fonction de hachage...............................26
A.3 Syntese..........................................26
B Programme de traitement des donnees horaires 28
C Gestion de projet 38
Chapitre 1
Introduction
La generalisation des reseaux dans les avions permettra de fournir des services aux passagers,
a l'equipage et aux compagnies.Ces nouveaux canaux sont percus comme de nouvelles vulnera-
bilites.La demande pour securiser ces nouveaux ux de donnees repond a des attentes de s^urete
aeronautique.
Nous allons considerer des avions orant un acces a un reseau Internet a chaque passager.
Internet Protocol Security ( IPSec) est la solution consideree pour apporter un mecanisme de
securite au protocole IP qui en est depourvu.L'objet de cette etude est de quantier l'impact
d'une de cette solution.Une premiere partie presente le protocole IPSec et l'architecture necessaire
pour sa mise en oeuvre.La deuxieme partie aborde le perimetre de l'etude en denissant les ux
concernes par l'etude et en detaillant les scenarios retenus.Enn la troisieme partie presente
des resultats obtenus avec le logiciel de simulation OPNET et par analyse theorique de certains
echanges.
Chapitre 2
IPsec
2.1 Mecanismes de securite
La securite informatique vise plusieurs objectifs:
{ la condentialite:capacite a ne permettre l'acces a des donnees que par des personnes et
processus autorises.
{ l'authentication:capacite a conna^tre l'identite des personnes ou processus qui envoient
des donnees ou des messages.
{ l'integrite:capacite a ne permettre la modication des donnees que par des personnes et
processus autorises.
{ non-repudiation:l'auteur des donnees ou messages envoyes ne peut renier ce qu'il a fait.
Plusieurs mecanismes de securite sont disponibles.Ils reposent sur des methodes de cryptage.Les
principaux mecanismes sont les clefs symetriques,asymetriques et les fonctions de hachage dont
le fonctionnement est rappele en annexe A.
2.2 Presentation d'IPSec
Ipv4 et Ipv6 sont deux versions de l'Internet Protocol (IP),protocole de niveau 3 dans le modele
OSI.Elles n'orent aucun service de securite.IPSec va permettre de securiser les communications
s'appuyant sur IP.Ce protocole a ete developpe par l'Internet Engineering Task Force ( IETF)[6].
Il permet de securiser les echanges de donnees au niveau de la couche reseau.Il est optionnel
dans Ipv4 bien que recommandable,et mis en place (implementation) dans Ipv6.IPsec assure une
protection renforcee contre les attaques gr^ace a une securite de bout en bout.Les seuls ordinateurs
qui doivent connaitre la protection IPsec sont l'emetteur et le destinataire de la communication.
IPsec permet de proteger les communications entre les groupes de travail,les ordinateurs du reseau
local,les clients et serveurs de domaine,les succursales (eventuellement distantes),les extranets
et les clients itinerants.IPSec n'est pas un protocole xe il s'agit d'un cadre pour implementer
les services de securite ( le choix existe pour les services et les protocoles de chirement).
Chapitre 2.IPsec 6
2.3 Mode de fonctionnement d'IPSec
IPSec ajoute des informations aux paquets IP pour fournir de la securite.Dans Ipv6 ces
mecanismes sont implantes au niveau des extensions d'en-t^ete.Dans Ipv4 des nouvelles ent^etes
sont ajoutees aux paquet IP( contenant elles-m^emes des champs Next Header ).
Deux en-t^etes ont ete prevues:
"Authentication Header (AH)"garantissant la securite d'acces (authentication de l'emet-
teur ) et l'integrite (signature) des paquets IP.Cette en-t^ete a une longueur de 24 octets.
Ce mecanisme n'assure pas la condentialite des donnees.
"Encapsulating Security Payload (ESP)"garantissant la condentialite (cryptage),l'authen-
tication des donnees du paquet IP,l'integrite des donnees.
L'authentication est mise en oeuvre gr^ace a des techniques de contr^ole d'integrite fondees
sur HMAC (hash function based message authentication code).Les algorithmes de hachage
utilises peuvent ^etre Message Digest 5 ( MD5 [7] ) ou bien des algorithmes plus recents SHA-
X.
La condentialite est mise en oeuvre par des techniques cryptographiques a clefs secretes.
Ces deux protocoles peuvent ^etres utilises separement ou simultanement.Ainsi une distri-
bution des cles est necessaire et realisee par un protocole de niveau superieur.La gestion
des cles doit ^etre independante des algorithmes de securite.
Les mecanismes (AH et ESP) utilisent des parametres (algorithmes utilises,clefs partages...) sur
lesquels les tiers doivent se mettre d'accord.L'echange de cles publiques se realise a travers une
infrastructure (PKI).IPSec a besoin d'une telle infrastructure qui realise de plus la negociation des
algorithmes.Pour une conguration dynamique,nous allons utiliser le protocole IKE(Internet Key
Exchange) [2].Celui-ci va donc se charger de l'echange des clefs et de tous les parametres associes
a la securisation des echanges.Une authentication des tiers par echange des clefs publiques ou
par secret partage est necessaire puis plusieurs clefs seront generees pour AH et ESP.
IPSec est principalement utilise dans deux modes:
mode transport:Seule la partie donnee du paquet est securisee.L'ne-t^ete initiale n'est pas
modiee.( gure 1)
Mode tunnel:tout le paquet,y compris l'en-t^ete,est securise.L'adresse IP sera celle de la
passerelle de securite.( gure 2)
Figure 1 { Mode transport.
Chapitre 2.IPsec 7
Figure 2 { Mode tunnel.
2.4 Realisation d'IPSec
La realisation d'IPSec repose sur une association de securite (SA) (gure3) qui est la combi-
naison de clefs negociees,de protocole de securite,et de l'index des parametres de securite (SPI),
qui tous ensemble,denissent la securite utilisee pour proteger la communication d'un emetteur
a un recepteur.Le SPI est unique.Cette valeur caracterise un SA parmi les autres existant sur le
m^eme noeud.Pour etablir ces associations deux phases sont necessaires.
Figure 3 { Association de securite.
Pour assurer une communication securisee,IKE realise deux phases.La condentialite et
l'authentication sont assurees durant chacune des phases par l'utilisation d'algorithmes de codage
et decodage.Une premiere phase de negociation va consister a etablir un canal securise,authentie.
IKE fournit automatiquement une protection necessaire des identites durant cette phase.Ensuite,
une phase permet de negocier les parametres utiles a la SA.
2.5 Synthese
Le deploiement d'IPSec augmente la charge du trac en ajoutant des en-t^etes.De plus,les
delais sont modies car le codage et l'encodage necessitent du temps de calcul.Enn,la mise en
place de telles communications engendre des echanges supplementaires sur le reseau.Ces trois
points seront pris en compte pour l'evaluation de l'overhead.
Chapitre 3
Architecture de distribution des cles
3.1 Principes
L'infrastructure de clefs publiques (PKI ) est un ensemble de logiciels,protocoles et docu-
ments necessaires pour gerer les clefs publiques.Les operations realisees sur celles-ci sont:la
publication,le renouvelement,et la revocation.Les concepts fondamentaux impliques dans PKI
sont les concepts de certications et les autorites de certications.L'autorite de certications est
un serveur central en lequel tous les utilisateurs ont conance.Tout utilisateur connait la clef
publique Kpca de l'autorite de certication (CA).Les clefs publiques individuelles sont certiees
par un CA.Un certicat n'est autre que les informations de l'utilisateur accompagnees de sa clef
publique et de la signature du CA utilisant la clef secrete du CA.Les utilisateurs s'inscrivent en
Figure 4 { Principe d'une PKI
fournissant une copie de leur clef publique au CA.Le CA verie que la clef publique est authen-
tique ou valide et verie l'identite de l'utilisateur,cela permet de contrecarrer toute tentative de
substitution.La signature numerique d'un certicat permet de declarer que les informations ont
Chapitre 3.Architecture de distribution des cles 9
ete attestees par une autre personne ou entite.La signature numerique ne garantit pas totalement
l'authenticite du certicat.Elle conrme uniquement que les informations d'identication signees
correspondent ou sont liees a la cle publique.Ainsi,un certicat equivaut en realite a une cle
publique comportant un ou deux types d'ID joints ainsi qu'une estampille agreee par d'autres
personnes ables.Une telle architecture repose donc sur un tiers de conance.Les certicats sont
utilises lors de l'echange de cles publiques avec un autre utilisateur.Les certicats ou serveurs
de certicats viennent de la necessite de mettre en place des systemes pouvant fournir des meca-
nismes de securite,de stockage et d'echanges.Ces systemes peuvent se presenter sous la forme de
referentiels de stockage uniquement,appeles serveurs de certicats ou sous la forme de systemes
structures orant des fonctions de gestion de cles,appeles infrastructures de cle publique (PKI).
Un serveur de certicats,egalement appele serveur de cles,est une base de donnees permettant
aux utilisateurs de soumettre et de recuperer des certicats numeriques.
3.2 Operations realisables par une PKI
Une PKI contient les fonctions de stockage de certicats d'un serveur de certicats,mais elle
ore egalement des fonctions de gestion de certicats (emission,revocation,stockage,recupera-
tion et abilite des certicats).La principale fonction d'une PKI est de presenter l'autorite de
certication.Ce tiers de conance peut ^etre une entite humaine (une personne,un groupe,un
service,une entreprise ou une autre association) autorisee par une societe a emettre des certicats
a l'attention de ses utilisateurs informatiques.Une CA fonctionne comme un service de contr^ole
des passeports du gouvernement d'un pays.Elle cree des certicats et les signe de facon numerique
a l'aide d'une cle privee de CA.
Les certicats sont utiles tant qu'ils sont valides.Si l'on considere que la validite d'un certicat
est permanente,la securite n'est plus garantie.Les certicats sont donc crees avec une periode de
validite par defaut:une date/heure de debut et une date/heure d'expiration.Ce certicat peut
^etre utilise pendant la totalite de sa periode de validite (sa duree de vie).Lorsque ce certicat
arrive a expiration,il n'est plus valide,car l'authenticite de sa paire de cles/d'identication n'est
plus assuree.M^eme si l'on peut l'utiliser en toute securite pour re-conrmer les informations
cryptees ou signees pendant la periode de validite,on ne doit pas le considerer comme able pour
les t^aches cryptographiques a venir.
emission de certicats:La CA distribue la LRC aux utilisateurs a intervalles reguliers (et
eventuellement hors cycle,a savoir lors de la revocation d'un certicat) an de les emp^echer,
en theorie,d'utiliser sans le savoir un certicat compromis.Toutefois,il peut arriver qu'un
nouveau certicat compromis soit utilise entre deux LRC dierentes.
revocation de certicats:L'annulation d'un certicat prealablement a sa date d'expiration
peut parfois s'averer necessaire,en particulier lorsque son detenteur quitte l'entreprise ou
pense que la cle privee correspondante est compromise.Dans ce cas,on parle de revocation.
Les certicats expires sont inutilisables,mais ne constituent pas une menace aussi serieuse
Chapitre 3.Architecture de distribution des cles 10
pour la securite que les certicats revoques.(Les certicats revoques sont connus et stockes
chez chaque utilisateurs)
Par exemple par defaut,la duree de vie des certicats est de l'ordre de deux heures et demie sur
des routeurs CISCO.La distribution des clefs publiques peut se faire autrement que par certicat
et autorite de certication.En eet,on peut,par exemple,utiliser les tunnels VPN dans le cas
ou l'on a peu d'avions et peu de systemes au sol.Cependant,PKI est l'infrastructure a clefs
publiques la mieux standardisee,implementee et deployee.
3.3 Prise en compte des PKI dans un contexte aeronau-
tique
Le fait d'utiliser un seul CA permet de centraliser et de faciliter l'inter-operabilite.Neanmoins,
la presence du tiers de conance implique des echanges entre les utilisateurs dans l'avion et le
CA.Pour des vols d'une duree inferieure a deux heures trente ces echanges peuvent avoir lieu
lorsque l'avion est au sol.L'utilisation de technologie type WI-max permet d'acceder a une bande
passante susante,pour que ce trac supplementaire ne soit pas penalisant.Lors des vols long
courrier,ce trac est plus problematique car il encombre une bande passante reduite.
Chapitre 4
Realisation des scenarios
L'etude se concentre sur l'impact de l'utilisation de IPSec dans un reseau aeronautique.Nous
considerons l'espace aerien francais et cherchons a evaluer la surcharge ( overhead) induite par
cette technologie de securite.La situation etudiee est prospective et considere que chaque passager
a acces a internet de maniere securisee.Il est donc necessaire de conna^tre le nombre d'utilisateurs
a un moment donne ainsi que les services qui lui sont proposes.
4.1 Les donnees
Les donnees mises a disposition sont des enregistrements heure par heure des vols.Ces donnees
sont issues des bases de la DSNA-DTI et mises en forme par M.Besse et M.Larrieu.Voici un extrait
de chier:
08:00:00 C160 CTM2115
08:00:00 A321 AAF287
08:00:00 F900 GHMEI
08:00:00 A320 TAR725
08:00:00 CRJ1 PWF5630
08:00:00 B772 MSR986
08:00:00 B772 AZA605
08:00:00 FA50 DSO23
Le code OACI de l'avion et le numero de vol sont enregistres apres le creneau horaire,ici 08h/09h.
Ces informations sont un point de depart qu'il faut exploiter.
4.2 Methode
Les passagers sont classes en trois categories qui representent les principales distinctions de
services oerts.
Chapitre 4.Realisation des scenarios 12
La classe"eco"a un acces au reseau moins important que les deux autres classes:les passagers
ont acces a un prol bas,acces a HTTP,au mail.
La classe"aaire"ou"business"a acces au web au mail et a FTP.
La premiere"classe"ou"rst"a acces en plus des services precedents,a la voix sur IP.
Il faut donc relier les donnees ( code OACI et numero de vol) a la quantite d'utilisateurs pour
chaque classe.Les bases de donnees aeronautiques disponibles a L'ENAC via le service de re-
cherche economique n'ont pas permis de correler les informations.Leur cadre d'etude est prin-
cipalement lies aux informations commerciales des aeroports mais ne permet pas de repondre a
notre besoin.Sans information sur l'organisation des avions et donc sur la repartition des classes,
nous avons recherche la capacite maximale de chaque avion an d'appliquer un pourcentage cor-
respondant a la proportion moyenne de chaque classe.Une base de donnees EURCONTROL
permet de relier le code OACI d'un avion a une che descriptive tres complete ( gure 5).Les
informations sur les congurations des avions restent tres rares.Nous avons ane notre approche
Figure 5 { Fiche EUROCONTROL pour l'A380
en trouvant un site communautaire listant l'ensemble des congurations des avions.Le but de
cette communaute est de choisir le meilleur siege lors de ses voyages!Le site seatguru [8] nous
Figure 6 { Plan seatguru pour l'A318
a permis de conna^tre precisement le nombre de places pour chaque classe ( gure 6).Lorsque
plusieurs versions d'un appareil sont exploitees,nous avons moyenne les resultats.
Chapitre 4.Realisation des scenarios 13
Ces informations ont alimente un programme java qui a synthetise les donnees horaires initiales
( listing en annexe B).
gros.addElement("A310");//220 A 247
grosAvion.addElement(new Aircraft("A310",0,20,181));
gros.addElement("A321");//185 a 220
grosAvion.addElement(new Aircraft("A321",42,0,146));
gros.addElement("B742");//366 a 452
grosAvion.addElement(new Aircraft("B742",0,56,383));
4.3 Resultats
Nous connaissons maintenant la repartition des classes utilisateurs au cours d'un journee pour
la France metropolitaine ( gure 7).De plus nous avons la connaissance de la conguration de
chaque type d'avion.Nous avons identie plusieurs scenarios pour lesquels il faut quantier le
Figure 7 { Frequentation horaire de chaque classe.
deploiement d'IPSec:
Chapitre 4.Realisation des scenarios 14
scenario minimal:considerer un avion avec un passager < economie >,un passager"business",
un passager"rst".
scenario avion:considerer un avion representatif ( A320 par exemple) avec 5"rst",28"busi-
ness"et 122"economie".
scenario France:considerer l'ensemble du trac national a un moment donne.
Les chires fournis sont les capacites de chaque avions.Bien s^ur,tous les utilisateurs n'utilisent
pas simultanement leur connexion.De m^eme,les taux de remplissage des avions se situent entre
70 et 80% de leur capacite (ref [1]).Les donnees recoltees sont donc a ponderer pour representer
une utilisation reelle.Elles representent une capacite maximale theorique.
Chapitre 5
Simulations et resultats theoriques
Nous avons obtenu des resultats en utilisant le logiciel de simulation de reseaux OPNET.
Cette approche a ete completee par une etude theorique pour prendre en compte des messages
que OPNET ne simule pas ( negociation avec le CA).
5.1

Etude theorique
Lors de l'etablissement d'une connexion IPsec,la mise en place de plusieurs operations s'avere
necessaire.En eet,pour echanger des messages de maniere securise,un echange de clefs est
indispensable.Cela se fait gr^ace a l'infrastructure d'echange de clefs publiques (IKE) qui permet
d'etablir et de maintenir les associations de securite.Une association de securite permet de stocker
et de manipuler l'ensemble des parametres geres par IKE.Le champ SPI dans les en-t^etes AH et
ESP est un index sur cette base.Cela permet entre-autres d'identier quels mecanismes de securite
l'on prend.Les associations de securite s'etablissent gr^ace a des certicats.Sur ces certicats,on a
plusieurs champs:l'utilisateur,les clefs publiques,la periode de validite du certicat.Un certicat
a une longueur aux alentours de 700 octets.
Detaillons le surplus de ux engendre par les mecanismes ESP et AH.
Les tailles des paquets vont donc augmenter en fonction des mecanismes que l'on prend.
En-t^ete d'authentication AH:elle assure l'integrite et l'authentication de l'origine des data-
grammes IP.
Figure 8 { En-t^ete AH..
Donc on a une en-t^ete de 12 octets et 0 a 255 de donnees d'authentication.
Encapsulation ESP:
Chapitre 5.Simulations et resultats theoriques 16
Figure 9 { En-t^ete ESP.
Longueur en plus avec ESP:10 octets,0 a 255 octets de padding et 2 octets de longueur pour
les deux derniers champs.(Les valeurs ont ete deduites des RFC 2459 [3],4303 [5],2401 [6],4306
[4].)
Regardons,maintenant,theoriquement,le ux engendre en plus avec l'activation d'IPsec:
Soit N le nombre d'utilisateurs.Soit k le nombre de messages envoyes,on va avoir un ux de
donnees qui augmente entre
{ si seul AH est utilise:(12k +700) *N et (267k + 700) *N
{ si seul ESP est utilise:(12k +700) *N et (267k + 700) *N
{ si AH et ESP sont utilises:(24k +700) *N et (534k + 700) *N
Nous pouvons donc illustrer graphiquement ces resultats pour 20 paquets envoyes par utili-
sateur.
Pour AH ou ESP active:
Figure 10 { Surplus theorique du fait de la signalisation d'un protocole.
Pour AH et ESP active:Le nombre d'utilisateurs est represente en abscisse et en ordonnee le
trac de signalisation en octets.
Chapitre 5.Simulations et resultats theoriques 17
Figure 11 { Surplus theorique du fait de la signalisation des deux protocoles.
5.2 Simulation avec OPNET
Nous considerons trois reseaux locaux dans l'avion relie au sol par un liaison satellite via un
routeur ( gure 15).Les sous-reseaux sont
APC ux passagers.
AOC ux a destination des operations des compagnies aeriennes.
ATS ux a destination des services de la circulation aerienne.
Les ux AOC et ATS sont consideres comme beaucoup moins importants,en volume,par rapport
au ux APC.Nous etudierons dans un premier temps uniquement les ux APC en attendant une
modelisation des autres ux.
An de nous familiariser avec l'outil de modelisation OPNET nous envisageons tout d'abord
une situation simpliste:un avion avec un passager de chaque classe ( gure 13).Un poste APC est
modelise par une succession de modules ( gure 14) qui representent les traitements des donnees.
Nous nous interessons plus particulierement au module IP
encap qui realise l'encapsulation des
donnees de la couche 4 ( et inversement).Il est a signaler que le choix des algorithmes utilises
etait absent.Il s'agit d'un modele a etat dont chaque etat contient du code en C qui sont les
instructions utiles pour le simulateur.Nous avons utilise des modules standards existants pour
simuler IPSec avec les en-t^etes ESP en mode transport ( gure 16).
Nous avons programme des sondes an de recueillir les informations pertinentes.En eet,
l'information sur les tailles des paquets n'est pas disponible par defaut dans la collection des
sondes.Plut^ot que de faire un scenario avec IPSec et un autre sans,nous avons place des sondes
enregistrant la taille des paquets avant et apres l'encapsulation ESP.
Chapitre 5.Simulations et resultats theoriques 18
Figure 12 { Topologie de l'etude.
Figure 13 { Topologie du reseau avion.
Chapitre 5.Simulations et resultats theoriques 19
Figure 14 { Modelisation poste APC.
Figure 15 { Machine a etat de du module IP.
Figure 16 { ESP en mode transport.
Chapitre 5.Simulations et resultats theoriques 20
5.3 Resultats
Dans les gures suivantes ( 17,18,19) les courbes bleus representent la moyenne des tailles des
paquets avec IPSec,et les rouges sans.L'abscisse represente le temps,une simulation durant 4
heures.Les tailles des paquets sont exprimees en bits.
Figure 17 { Taille des paquets avec et sans ESP pour la classe economie.
Figure 18 { Taille des paquets avec et sans ESP pour la classe aaire.
Chapitre 5.Simulations et resultats theoriques 21
Figure 19 { Taille des paquets avec et sans ESP pour la classe rst.
Pour la gure 20 les courbes bleue,verte et rouge representent respectivement les delais de la
classe rst,aaire et economie.
Figure 20 { Delai des paquets avec ESP pour les trois classes.
On remarque une dierence notable pour la classe rst.Les delais sont plus importants.On
peut attribuer cette caracteristique au service de voix sur IP.
La dierence entre les tailles des paquets est de l'ordre de grandeur des resultats de l'etude
theorique.On observe une dierence d'environ 50 octets pour la simulation contre entre 12 et
250 octets pour l'etude theorique.Seule cette etude a pu ^etre realisee par manque de temps.En
eet,la prise en main mais aussi l'utilisation reguliere d'OPNET nous a reserve de nombreuses
surprises...La prochaine etude aurait ete une simulation en mode tunnel entre les routeurs avions
et des serveurs sollicites.
Chapitre 6
Conclusion
Au cours de notre etude,nous avons dans un premier temps fait des recherches sur le mode de
securite IPsec.Puis,nous avons etudie la topologie du ciel francais gr^ace a une base de donnees.
En correlant ces informations et la conguration des avions nous avons etabli des scenarios.Enn
nous avons,theoriquement et pratiquement,quantie le volume de trac genere par la signalisation
d'IPsec.Cette demarche a ete menee dans le cadre d'un projet dont le suivi est presente en annexe
C.
D'un point de vue materiel,l'"internet"dans les cabines est possible,comme l'exemple de
Connexion By Boeing le prouve.Neanmoins,les contraintes economiques ont ete une raison prin-
cipale de l'abandon de ce projet.Cette experience doit nous amener a considerer l'architecture
de securite la plus pertinente possible,pour ne pas degrader le service oert autant en terme
de capacite que de prix.L'impact d'IPSec est signicatif.Il conviendrait d'etudier nement les
combinaisons d'algorithmes possibles dans IPSec an d'obtenir le meilleur compromis temps de
traitement/ecacite.De m^eme des experiences sur la gestion des certicats pourraient permettre
de denir l'architecture ou les reglages (duree de validite) les plus appropries a securiser des tracs
internet pour les passagers aeriens.
Bibliographie
[1] Observatoire de l'aviation civile.Tendance et derniers resultats du transport aerien interna-
tional.Technical report,DGAC-DTA,octobre 2009.
[2] D.Harkins and D.Carrel.The Internet Key Exchange (IKE).RFC 2409 (Proposed Standard),
November 1998.Obsoleted by RFC 4306,updated by RFC 4109.
[3] R.Housley,W.Ford,W.Polk,and D.Solo.Internet X.509 Public Key Infrastructure Certi-
cate and CRL Prole.RFC 2459 (Proposed Standard),January 1999.Obsoleted by RFC
3280.
[4] C.Kaufman.Internet Key Exchange (IKEv2) Protocol.RFC 4306 (Proposed Standard),
December 2005.Updated by RFC 5282.
[5] S.Kent.IP Encapsulating Security Payload (ESP).RFC4303 (Proposed Standard),December
2005.
[6] S.Kent and R.Atkinson.Security Architecture for the Internet Protocol.RFC 2401 (Proposed
Standard),November 1998.Obsoleted by RFC 4301,updated by RFC 3168.
[7] R.Rivest.The MD5 Message-Digest Algorithm.RFC 1321 (Informational),April 1992.
[8] www.seatguru.com.The ultimate source for aiplane seating,in- ight amenties,and airline
information.
Table des gures
1 Mode transport......................................6
2 Mode tunnel........................................7
3 Association de securite...................................7
4 Principe d'une PKI....................................8
5 Fiche EUROCONTROL pour l'A380..........................12
6 Plan seatguru pour l'A318................................12
7 Frequentation horaire de chaque classe..........................13
8 En-t^ete AH.........................................15
9 En-t^ete ESP........................................16
10 Surplus theorique du fait de la signalisation d'un protocole...............16
11 Surplus theorique du fait de la signalisation des deux protocoles.............17
12 Topologie de l'etude....................................18
13 Topologie du reseau avion................................18
14 Modelisation poste APC.................................19
15 Machine a etat de du module IP.............................19
16 ESP en mode transport..................................19
17 Taille des paquets avec et sans ESP pour la classe economie...............20
18 Taille des paquets avec et sans ESP pour la classe aaire................20
19 Taille des paquets avec et sans ESP pour la classe rst..................21
20 Delai des paquets avec ESP pour les trois classes.....................21
21 Principe de la cle partagee................................25
22 Principe des cles asymetriques..............................26
23 Realisation prevue du projet...............................38
24 Realisation eective du projet..............................38
Annexe A
Principaux mecanismes de securite
A.1 Cryptage de cle secrete ou cle symetrique
En cryptographie conventionnelle,egalement appelee cryptage de cle secrete ou de cle syme-
trique,une seule cle sut pour le cryptage et le decryptage.Dans ce cryptage,tous les points
de securite ne sont pas veries:seules,la condentialite et l'integrite sont assures.Pour contrer
cela,nous allons utiliser un cryptage a clefs asymetriques.
Figure 21 { Principe de la cle partagee
A.2 Cryptage de clefs publiques/privees ou clefs asyme-
triques
La cryptographie de cle publique est un procede asymetrique utilisant une paire de cles pour
le cryptage:une cle publique qui crypte des donnees et une cle privee ou secrete correspondante
pour le decryptage.
La cryptographie de cle publique presente un avantage majeur:en eet,elle permet d'echanger
des messages de maniere securisee sans aucun dispositif de securite.L'expediteur et le destina-
Chapitre A.Principaux mecanismes de securite 26
taire n'ont plus besoin de partager des cles secretes via une voie de transmission securisee.Les
communications impliquent uniquement l'utilisation de cles publiques et plus aucune cle privee
n'est transmise ou partagee.
Figure 22 { Principe des cles asymetriques
De plus la cryptographie de cle publique ore une methode pour mettre en oeuvre des si-
gnatures numeriques (cf illustration 22).Celles-ci permettent au destinataire de verier leur au-
thenticite,leur origine,mais egalement de s'assurer qu'elles sont intactes.Ainsi,les signatures
numeriques de cle publique garantissent l'authentication et l'integrite des donnees.Elles four-
nissent egalement une fonctionnalite de non repudiation,an d'eviter que l'expediteur ne pretende
qu'il n'a pas envoye les informations.Ce type de cryptage permet egalement de realiser une si-
gnature numerique.Elle peut attester du contenu des informations,ainsi que de l'identite du
signataire.
A.2.1 fonction de hachage
Une fonction de hachage (cf gure 4) a sens unique dans le processus permet d'ameliorer le
schema ci-dessus.Cette fonction traite une entree de longueur variable (dans ce cas,un message
pouvant contenir indieremment des milliers ou des millions de bits),an d'obtenir en sortie un
element de longueur xe.Si une fonction de hachage securisee est utilisee,il est impossible de
recuperer la signature d'un document pour la joindre a un autre document ou d'alterer un message
signe.La moindre modication apportee a un document signe entraine l'echec du processus de
verication de la signature numerique.
A.3 Syntese
Les techniques de clefs secretes permettent seulement d'obtenir la condentialite et l'integrite.
L'authentication est accessible par les techniques de clefs asymetriques.Cette technique permet
egalement de coder les donnees ( condentialite) mais est beaucoup moins ecace.A m^eme
Chapitre A.Principaux mecanismes de securite 27
conguration materielle une technique a clefs publiques ( RSA ) est environ 1000 fois plus lente
qu'une technique de clefs privees (DES).De plus,les clefs secretes sont diciles a maintenir sur
tous les postes.Si un seul poste est compromis tous le systeme est compromis.Pourtant,seul ce
mecanisme permet de crypter des donnees de taille importante en un temps acceptable.Les deux
techniques de cryptage seront utilisees pour proposer un systeme securise s^ur et ecace.Ainsi,
on envoie des clefs secretes temporaires dans des messages cryptes avec des clefs asymetriques(les
certicats).
Nous avons donc besoin de protocoles pour assurer l'echange des informations et des clefs.
C'est le r^ole des infrastructures d'echange de clef.
Annexe B
Programme de traitement des donnees
horaires
import java.io.*;
import java.util.*;
/**
* @author mathieu auge
*/
public class LectureLigne {
public static class Aircraft {
private String codeOACI;
private int nbmaxpx;
private int propfirst;
private int propaffaire;
private int propeco;
public Aircraft(String s,int n,int p1,int p2,int p3) {
this.codeOACI = s;
this.nbmaxpx = n;
this.propfirst = p1;
this.propaffaire = p2;
this.propeco = p3;
}
Chapitre B.Programme de traitement des donnees horaires 29
public Aircraft(String s,int p1,int p2,int p3) {
this.codeOACI = s;
this.nbmaxpx = p1 + p2 + p3;
this.propfirst = p1;
this.propaffaire = p2;
this.propeco = p3;
}
public String getCode() {
return this.codeOACI;
}
public int getfirst() {
return this.propfirst;
}
public int getBisuness() {
return this.propaffaire;
}
public int getEconomy() {
return this.propeco;
}
public boolean equals(String s) {
return (this.codeOACI.equalsIgnoreCase(s));
}
}
/*enum Gros{
A380,
B772,
B752,
CL60
};*/
public static void main(String[] argv) throws IOException {
//ajout des bornes max moyennes par types de porteurs.
//infos sur les avions --> http://elearning.ians.lu/aircraftperformance/
Chapitre B.Programme de traitement des donnees horaires 30
Aircraft ac = new Aircraft("A30B",250,0,20,230);
Vector<Aircraft> grosAvion = new Vector<Aircraft>();
Vector<Aircraft> petitAvion = new Vector<Aircraft>();
Vector<Aircraft> moyenAvion = new Vector<Aircraft>()
/* notes:
informations sur les classes d'apres seatguru.
*modele Airfrance selectionne:first-affaire/voyageur/tempo
*/
Vector<String> gros =
new Vector<String>();
gros.addElement("A30B");//220 a 336
grosAvion.addElement(new Aircraft("A30B",250,0,20,230));
gros.addElement("A306");//266 a 298
grosAvion.addElement(new Aircraft("A306",24,0,242));
gros.addElement("A380");//555 a 853
grosAvion.addElement(new Aircraft("A380",9,80,449));
gros.addElement("A330");//de 253 a 293
grosAvion.addElement(new Aircraft("A330",40,0,179));
gros.addElement("A340");//313 A 359
grosAvion.addElement(new Aircraft("A340",33,0,248));
gros.addElement("A310");//220 A 247
grosAvion.addElement(new Aircraft("A310",0,20,181));
gros.addElement("A321");//185 a 220
grosAvion.addElement(new Aircraft("A321",42,0,146));
gros.addElement("B742");//366 a 452
grosAvion.addElement(new Aircraft("B742",0,56,383));
gros.addElement("B744");//416 a 524
grosAvion.addElement(new Aircraft("B744",0,50,383));
gros.addElement("B752");//200 a 228
grosAvion.addElement(new Aircraft("B752",12,26,72));
gros.addElement("B772");//305 a 440
grosAvion.addElement(new Aircraft("B772",4,49,211));
gros.addElement("B763");//de 269 a 351
grosAvion.addElement(new Aircraft("B763",10,30,119));
gros.addElement("DC10");//250 A 410
grosAvion.addElement(new Aircraft("DC10",24,38,223));
gros.addElement("DC87");//180 A 269
//pas d'info idem B752
grosAvion.addElement(new Aircraft("DC87",12,26,72));
Chapitre B.Programme de traitement des donnees horaires 31
gros.addElement("MD11");//de 250 a 410
grosAvion.addElement(new Aircraft("MD11",24,38,223));
//moyenne du nombre max de passagers 378 passagers
//MOYEN ENTRE 70 ET 200
Vector<String> moyen =
new Vector<String>();
moyen.addElement("A319");//124 a 142
moyenAvion.addElement(new Aircraft("A319",22,16,75));
//moyenne des trois versions possiblesex:
/*affaire:28 0 38
voyageur:57 0 0
tempo:0 142 81*/
moyen.addElement("A320");//150 a 180
moyenAvion.addElement(new Aircraft("A320",5,28,122));
moyen.addElement("AT72");//72 passagers
moyenAvion.addElement(new Aircraft("AT72",0,0,0));
moyen.addElement("B703");//147 A 219
moyenAvion.addElement(new Aircraft("B703",0,0,0));
moyen.addElement("B732");//115 a 130
moyenAvion.addElement(new Aircraft("B732",0,0,0));
moyen.addElement("B733");//128 a 149
moyenAvion.addElement(new Aircraft("B733",0,0,0));
moyen.addElement("B738");//162
moyenAvion.addElement(new Aircraft("B738",16,0,132));
moyen.addElement("BA11");//119
moyenAvion.addElement(new Aircraft("BA11",0,0,0));
moyen.addElement("BA46");//82 passagers
moyenAvion.addElement(new Aircraft("BA46",0,0,0));
moyen.addElement("C130");//92 passagers
moyenAvion.addElement(new Aircraft("C130",0,0,0));
moyen.addElement("C160");//93 passagers
moyenAvion.addElement(new Aircraft("C160",0,0,0));
moyen.addElement("DC9");//93 passagers
moyenAvion.addElement(new Aircraft("DC9",0,0,0));
moyen.addElement("F70");//107 A 122
moyenAvion.addElement(new Aircraft("F70",0,0,0));
Chapitre B.Programme de traitement des donnees horaires 32
moyen.addElement("F100");//107 A 122
moyenAvion.addElement(new Aircraft("F100",0,0,0));
moyen.addElement("MD80");//172
moyenAvion.addElement(new Aircraft("MD80",0,0,0));
moyen.addElement("T154");//158 A 180
moyenAvion.addElement(new Aircraft("T154",0,0,0));
//moyenne du nombre max de passagers 134 passagers
//petit <70
Vector<String> petit =
new Vector<String>();
petit.addElement("ATP");//64 a 70 passagers
petitAvion.addElement(new Aircraft("ATP",0,10,54));
//pas d'information
petit.addElement("AT43");//42 A 50
petitAvion.addElement(new Aircraft("AT43",0,0,50));
petit.addElement("BE9L");//4
petitAvion.addElement(new Aircraft("BE9L",0,2,2));
petit.addElement("BE20");//13
petitAvion.addElement(new Aircraft("BE20",0,6,7));
petit.addElement("C421");//6 A 10
petitAvion.addElement(new Aircraft("C421",0,5,5));
petit.addElement("C550");//6 A 10
petitAvion.addElement(new Aircraft("C550",10,0,0));
petit.addElement("C560");//8
petitAvion.addElement(new Aircraft("C560",8,0,0));
petit.addElement("CL60");//52
petitAvion.addElement(new Aircraft("CL60",4,10,38));
petit.addElement("CRJ1");//50
petitAvion.addElement(new Aircraft("CRJ1",4,10,36));
petit.addElement("D328");//50
petitAvion.addElement(new Aircraft("D328",4,10,36));
petit.addElement("DH8C");//50
petitAvion.addElement(new Aircraft("DH8C",4,10,36));
petit.addElement("E120");//30
petitAvion.addElement(new Aircraft("E120",0,0,30));
petit.addElement("F900");//8 A 18
petitAvion.addElement(new Aircraft("F900",4,4,0));
Chapitre B.Programme de traitement des donnees horaires 33
petit.addElement("F27");//28 PASSAGERS
petitAvion.addElement(new Aircraft("F27",4,4,20));
petit.addElement("F50");//50 A 58
petitAvion.addElement(new Aircraft("F50",4,10,36));
petit.addElement("FA10");//8 (?)
petitAvion.addElement(new Aircraft("FA10",2,6,0));
petit.addElement("FA20");//8
petitAvion.addElement(new Aircraft("FA20",8,0,0));
petit.addElement("FA50");//8 A 12
petitAvion.addElement(new Aircraft("FA50",8,0,0));
petit.addElement("FGTR");//1 A 2
petitAvion.addElement(new Aircraft("FGTR",2,0,0));
petit.addElement("H25B");//8
petitAvion.addElement(new Aircraft("H25B",4,4,0));
petit.addElement("LJ35");//8
petitAvion.addElement(new Aircraft("LJ35",4,4,0));
petit.addElement("MU2");//7
petitAvion.addElement(new Aircraft("MU2",4,3,0));
petit.addElement("P28A");//5
petitAvion.addElement(new Aircraft("P28A",2,3,0));
petit.addElement("PA27");//5
petitAvion.addElement(new Aircraft("PA27",0,0,5));
petit.addElement("PA31");//5
petitAvion.addElement(new Aircraft("PA31",0,0,5));
petit.addElement("PA34");//5
petitAvion.addElement(new Aircraft("PA34",0,0,5));
petit.addElement("PAY2");//5
petitAvion.addElement(new Aircraft("PAY2",5,0,0));
petit.addElement("PAY3");//5
petitAvion.addElement(new Aircraft("PAY3",5,0,0));
petit.addElement("JS31");//18
petitAvion.addElement(new Aircraft("JS31",4,4,10));
petit.addElement("SB20");//50 A 58
petitAvion.addElement(new Aircraft("SB20",0,0,53));
petit.addElement("SF34");//34
petitAvion.addElement(new Aircraft("SF34",0,0,34));
petit.addElement("SW3");//8 A 11
petitAvion.addElement(new Aircraft("SW3",4,4,0));
petit.addElement("TRIN");//4
Chapitre B.Programme de traitement des donnees horaires 34
petitAvion.addElement(new Aircraft("TRIN",0,0,4));
//moyenne du nombre max de passagers 21 passagers
int pasPetit = 21;
int pasGros = 378;
int pasMoyen = 134;
int nbligne = 0;
int NbGros = 0;
int NbMoyen = 0;
int NbPetit = 0;
//details des places
int nbfirst = 0;
int nbbussiness = 0;
int nbeco = 0;
int NbGrosV = 0;
int NbMoyenV = 0;
int NbPetitV = 0;
int detectionV;
int NbInconnueV = 0;
int NbInconnue = 0;
int detection;
int modeleInconnue = 0;
String modele;
BufferedReader lecteurAvecBuffer = null;
String ligne;
try {
lecteurAvecBuffer = new BufferedReader(new FileReader(argv[0]));
} catch (FileNotFoundException exc) {
System.out.println("Erreur d'ouverture");
}
while ((ligne = lecteurAvecBuffer.readLine())!= null) {//System.out.println(ligne);
detection = 0;
detectionV = 0;
modele = ligne.substring(9,13);
//System.out.println("avion du type -->"+modele+"<--");
Chapitre B.Programme de traitement des donnees horaires 35
if (gros.contains(modele)) {//System.out.println("Un gros de plus");
NbGros += 1;
detection = 1;
}
if (moyen.contains(modele)) {//System.out.println("Un moyen de plus");
NbMoyen += 1;
detection = 1;
}
if (petit.contains(modele)) {//System.out.println("Un petit de plus");
NbPetit += 1;
detection = 1;
}
Iterator i = moyenAvion.iterator();
while (i.hasNext()) {
Aircraft tempo = (Aircraft) i.next();
if (tempo.getCode().equals(modele)) {
NbMoyenV += 1;
detectionV = 1;
nbfirst += tempo.getfirst();
nbbussiness += tempo.getBisuness();
nbeco += tempo.getEconomy();
}
}
Iterator j = petitAvion.iterator();
while (j.hasNext()) {
Aircraft tempo = (Aircraft) j.next();
if (tempo.getCode().equals(modele)) {
NbPetitV += 1;
detectionV = 1;
nbfirst += tempo.getfirst();
nbbussiness += tempo.getBisuness();
nbeco += tempo.getEconomy();
Chapitre B.Programme de traitement des donnees horaires 36
}
}
Iterator k = grosAvion.iterator();
while (k.hasNext()) {
Aircraft tempo = (Aircraft) k.next();
if (tempo.getCode().equals(modele)) {
NbGrosV += 1;
detectionV = 1;
nbfirst += tempo.getfirst();
nbbussiness += tempo.getBisuness();
nbeco += tempo.getEconomy();
}
}
if (detectionV == 0) {
System.out.println("MODELE INCONNU dans les vectors -->"+ modele +"<--");
NbInconnueV += 1;
}
if (detection == 0) {
System.out.println("MODELE INCONNU -->"+ modele +"<--");
NbInconnue += 1;
}
nbligne += 1;
}
lecteurAvecBuffer.close();
System.out.println("on a lu"+ nbligne +"lignes.");
System.out.println(
"on a"+ NbPetit +"petits.Soit"+ NbPetit * pasPetit +"passagers");
System.out.println(
"on a"+ NbPetitV +"petits avec Vectors");
System.out.println(
"on a"+ NbMoyen +"moyens.Soit"+ NbMoyen * pasMoyen +"passagers");
System.out.println(
"on a"+ NbMoyenV +"moyens avec Vector.");
System.out.println(
"on a"+ NbGros +"gros.Soit"+ NbGros * pasGros +"passagers");
System.out.println(
Chapitre B.Programme de traitement des donnees horaires 37
"on a"+ NbGrosV +"gros avec Vector.");
System.out.println(
"FIRST:"+ nbfirst);
System.out.println(
"BUSINESS:"+ nbbussiness);
System.out.println(
"ECONOMY"+ nbeco +"gros avec Vector.");
if (NbInconnue!= 0) {
System.out.println("ATTENTION MODELE NON GERE."+ NbInconnue +"lignes non-traitees.");
}
}
}
Annexe C
Gestion de projet
diagramme de Gantt initial (gure 23 )et realisation eective (gure 24 ).En ce qui concerne
Figure 23 { Realisation prevue du projet.
Figure 24 { Realisation eective du projet.
le management de projet et les etudes prealables,nous pouvons remarquer que nous avons tenus
Chapitre C.Gestion de projet 39
les delais.Les dierences entre nos diagrammes de Gantt proviennent du fait que nous avons eu
de grosses contraintes materielles.En eet,nous avons d^u lancer des simulations sous OPNET.
Or,il s'avere que nous n'avions pas assez d'espace disque.De plus,nous avons eu des problemes:
certaines operations,possibles au depart,devenaient impossibles par la suite sur des chiers qui
nous appartenaient tant au point de vue lecture qu'au point de vue ecriture.Ces problemes de droit
qui nous emp^echaient de lancer nos simulations ont mobilise plusieurs membres de LEOPART
que nous remercions pour leur soutien.
Les resultats eectifs pourraient ^etre approfondis avec un peu plus de temps et de meilleurs
moyens techniques.