Securisation des services B2B à l''aide d'IPSEC

Déploiement du protocole IPsec pour la sécurisation du B2B
Rédigé et présenté par AMBANI BALLA Bernadette Olga et LEMA NOAH Bernadette Page 1
DEDICACE
A
MES PARENTS
M. NTSAMA ZOA PIERRE
&
Mme NTSAMA ISABELLE

A
MES PARENTS
M. NOAH ATANGANA ADALBERT
&
Mme NOAH MARTHE

REMERCIEMENTS
Au terme de ce mémoire de fin d’étude, nous tenons à remercier tout d’abord
l’Eternel Dieu qui nous a illuminé et donné la sagesse, l’intelligence et la force de rédiger ce
rapport.
Nous témoignons aussi notre profonde gratitude à tous nos dirigeants. Nous pensons
particulièrement :
- A Monsieur le Directeur de l’IUT de Douala Pr. Louis Max AYINA OHANDJA,
pour nous avoir donné l’opportunité de suivre notre formation.
- A Monsieur le Chef de département Génie Informatique, Dr Joseph MVOGO
NGONO.
- A Monsieur CHIMI Emmanuel pour son encadrement
- A notre encadreur, M. YOMBI Jean Armand pour sa disponibilité permanente et le
soutien moral qu’il nous a apporté.
- A Monsieur NDZANA RIGOBERT de la cellule informatique de l’IUT de
DOUALA pour ses conseils et son appuie dans le cadre de notre formation.
- A tous les membres de la famille NTSAMA ZOA pour leur amour et soutien.
- A la famille NOAH pour son soutien moral et matériel;
- A mon oncle Monsieur OYONO MINLO JOSEPH pour son soutien financier
- A Notre Pasteur la REV. BEKOMBO MARTHE pour son soutient moral, spirituel
et matériel.
- A tous les enseignants et à tout le personnel de l’IUT de Douala.
- A Madame NDJOCK ROSE SOLANGE pour son soutien moral
- A tous nos camarades de classe et amis.
- A tous nos biens aimés dans le Seigneur
- A tous ceux qui de près ou de loin ont contribué à la réalisation de cet ouvrage; qu’ils
trouvent ici l’expression de notre profond sentiment.

TABLE DES MATIÈRES
DEDICACE.................................................................................................................................. 1
REMERCIEMENTS..................................................................................................................... 3
RESUME..................................................................................................................................... 7
ABSTRACT................................................................................................................................. 8
INTRODUCTION GENERAL...................................................................................................... 9
PARTIE 1 : PRESENTATION DU B2B........................................................................................10
CHAPITRE I : Définition, aspects et classement ........................................................................11
1. Définition .....................................................................................................................11
2. De l'échange à l'intégration ............................................................................................11
3. Classification ................................................................................................................12
CHAPITRE II : Les différents modèles B2B .............................................................................13
1. Le modèle des relations transactionnelles............................................................................13
1.1 Présentation ....................................................................................................................13
1.2 Les avantages..................................................................................................................13
1.3 L'EDI (Electronic Data Interchange).................................................................................14
2. Le modèle d'intégration de processus..................................................................................14
2.1 Présentation ....................................................................................................................14
2.2 Fondements ....................................................................................................................14
3. Le modèle du partage des ressources ..................................................................................15
3.1 Présentation ....................................................................................................................15
3.1.1 Partage des capacités de production ...............................................................................15
3.1.2 Partage des compétences...............................................................................................16
3.1.3 Partage des informations ...............................................................................................16
3.1.4 Partage des stocks.........................................................................................................17
PARTIE 2 : IPSEC.......................................................................................................................19
CHAPITRE I : Les besoins de sécurité sur IP.............................................................................20
1. Les faiblesses d'IP.........................................................................................................20
1.1 L'écoute des paquets........................................................................................................20
1.2 L'usurpation d'adresse (IP address spoofing)................................................................21
2. Les nouveaux besoins ....................................................................................................21
CHAPITRE II : Les techniques de sécurité.................................................................................23
1. La cryptographie symétrique ..........................................................................................23
2. La cryptographie asymétrique ........................................................................................24

3. Le Hachage...................................................................................................................25
4. La signature numérique..................................................................................................25
Chapitre III : Présentation d’IPsec .............................................................................................27
1. Définition .....................................................................................................................27
2. Mécanismes de sécurité .................................................................................................28
2.1 Authentication Header (AH) ............................................................................................29
2.2 Encapsulation Security Payload (ESP)..............................................................................29
3. Les modes de sécurité d’IPsec.......................................................................................30
3.1 Le mode Transport..........................................................................................................31
3.2 Le mode Tunnel..............................................................................................................31
CHAPITRE IV :Politiques de sécurité et gestion des clés...........................................................33
1. Politiques de sécurité.........................................................................................................33
1.1 La "Security Policy Database" (SPD)................................................................................33
1.2 La "Security Association Database" (SADB).....................................................................33
2. Gestion des clefs : IKE et ISAKMP....................................................................................34
2.1 ISAKMP.........................................................................................................................34
2.1 IKE................................................................................................................................35
3. Les phases d'IKE...............................................................................................................35
3.1 Première Phase................................................................................................................36
3 .2 Deuxième Phase.............................................................................................................37
3.3 Les groupes : New Groupe Mode .....................................................................................39
3.4 Phases et modes ..............................................................................................................39
4. Architecture d’IPsec..........................................................................................................39
5. Cas concret d'échange IKE entre deux machines .................................................................41
Chapitre V : Les failles du protocole IPsec.................................................................................45
1. Quelques failles actuelles d’IPsec...................................................................................45
PARTIE 3 : DEPLOIEMENT DE IPSEC ......................................................................................46
Chapitre I : Installation de IPsec................................................................................................48
1. Introduction ..................................................................................................................48
2. Scénario........................................................................................................................48
3. Outils utilisés................................................................................................................49
4. Installation....................................................................................................................49
Chapitre 2 : Configuration d’IPsec.............................................................................................51
1. Configuration de la première machine.............................................................................51
2. Configuration de la deuxième machine ...........................................................................54
3. Test et Résultats ............................................................................................................57

3.1 Test................................................................................................................................57
3.2 Résultats ...................................................................................................................58
CONCLUSION GENERALE.......................................................................................................59
ANNEXE A – SIGLES ET ACRONYME.....................................................................................60
ANNEXE B.................................................................................................................................62
ANNEXE C - RÉPERTOIRE DE FIGURES.................................................................................65
REFERENCES BIBLIOGRAPHIQUES........................................................................................66
WEBOGRAPHIE........................................................................................................................66

RESUME
L’évolution des services Internet tel que le business électronique et l’échange de
documents confidentiels ont orienté les travaux de recherches à sécuriser le réseau IP dans le
soucis d’assurer l’authentification, l’intégrité et la confidentialité des données au cours de leur
transit sur internet. Plusieurs solutions ont été élaborées parmi lesquelles figures IPSec
(Internet Protocol Security), protocole standardisé par l’IETF (Internet Engineering Task
Force), est une architecture de sécurité au niveau de la couche réseau ; Il s’agit en fait d’une
combinaison de plusieurs algorithmes et techniques de chiffrement dans un seul protocole
dont la négociation entre deux entités communicantes doit s’établir de manière sécurisée. Pour
son déploiement, IPsec fait appel à deux mode : le mode Transport et le mode Tunnel. Le
mode transport n’assurant pas une entière sécurité, le Mode tunnel serait le mieux indiqué à
cet effet.
La mise en œuvre de ce protocole dans les services Business To Business (B2B)
consiste en quelque sorte à configurer soient les passerelles ou les routeurs/serveurs des
différentes entreprises. Soit le poste de travail d’un partenaire afin qu’il puisse avoir accès au
données. Le jumelage de ses deux mécanismes que sont AH (Authentication Header) et ESP
(Encapsulating Security Payload) garantit la sécurité des données. Les Association de
Sécurité (SA) quant à elles permettent la protection des lignes de communication.
Le protocole IPsec peut être implémenté aussi bien dans les systèmes Windows que
dans les systèmes UNIX. Dans le cadre de ce mémoire, le système Ubuntu de Linux à été
preféré pour son interface graphique agréable et son adaptabilité facile pour les débutants.

ABSTRACT
The evolution of the Internet services as the electronic business and the exchange of
confidential documents oriented the works of research to secure the IP network in the worries
to assure the authentication, the integrity and the confidentiality of the data during their transit
on internet. Several solutions have been elaborated among which IPsec faces (Internet
Protocol Security), protocol standardized by the IETF (Internet Engineering Task Force), is an
architecture of security to the level of the layer network; It is in fact about a combination of
several algorithms and techniques of ciphering in only one protocol of which the negotiation
between two communicating entities must settle of secured manner. For its spreading, IPsec
calls on two modes: the transport mode and the Tunnel mode. The fashion transportation not
assuring a whole security, the Fashion tunnel would be best indicated to this effect.
The spreading of this protocol in the services Business To Business (B2B) consists in
a way to configure are the footbridges or the routeurs/serveurs of the different enterprises.
Either the station of work of a partner so that he/it can have access to the given. The twinning
of its two mechanisms that is AH (Authentication Header) and ESP (Encapsulating Security
Payload) guarantees the security of the data. Security Associations as for them permit the
protection of the communication lines.
The IPsec protocol can be as well implémented in the Windows systems that in the
systems UNIX. In the setting of this memory, the Ubuntu system of Linux has been preferred
for its pleasant graphic interface and its easy adaptability for the beginners.

INTRODUCTION GENERAL
L’évolution des nouvelles technologies de communication (NTIC) de nos jours offre la
latitude à toutes les entreprises sans distinction de taille ou de domaine, de migrer vers le
business électrononique. En effet les transactions entre les entreprises via le réseau public
(internet) exposent ces dernières à des arnaques de toutes natures tout simplement parce qu’il
est peu fiable.
Pour rendre les échanges sur un réseau Internet moins vulnérable, il existe diverses techniques
de sécurités, parmi lesquelles les protocoles SSL (Secure Socket Layer) et TLS (transport
Layer Secure) qui sont tous basés entre la couche transport du et la couche application
modèle TCP/IP et permettent de sécuriser les échanges d’informations, le protocole IPSec
(Internet Protocol Security) qui fera l’objet de notre étude, est implémenté sur la couche
réseau du modèle OSI et sécurise les trafics entrants et sortants d’un quelconque réseau. Ainsi
le déploiement du Protocol IPSec en vue de la sécurisation des services Business To Business
(B2B) fera l’objet de notre étude.
Elle s’articulera tour à tour sur les différents points suivants à savoir la présentation
des B2B, la présentation du protocole IPSec et le déploiement du Protocol dans deux B2B.

PARTIE 1 : PRESENTATION DU B2B

CHAPITRE I : Définition, aspects etclassement
1. Définition
Le Business to Business (B to B) concerne l'utilisation de supports électroniques pour
tout ou partie des échanges d'information d'une entreprise avec d'autres entreprises:
fournisseurs, sous-traitants, clients, prestataires de services, organismes financiers, etc.
Figure 1 : Aspect du B2B
2. De l'échange à l'intégration
Dans une perspective de maîtrise des coûts et de gestion de la qualité du service aux
clients de l'entreprise, le Business to Business tend, en outre, à utiliser les technologies de la
communication, en particulier les technologies Internet pour:
intégrer les échanges externes, par exemple:
 intégrer les flux réels (approvisionnement, ventes, etc.) avec les flux financiers
via les organismes bancaires;
 intégrer la gestion des prospects, le suivi des clients et le service après-vente;
intégrer les échanges externes avec les échanges internes d'information. Il s'agit de
l'intégration du front office avec le back office, par exemple:

 intégration de la gestion des approvisionnements, de la planification de la
production, de la planification des livraisons et de la gestion des commandes
clients.
3. Classification
De nombreux ouvrages et revues consacrés à l'e-business classent les modèles B to B
sur la base des formes d'intégration décrites ci-dessus. Cette approche n'est pas significative
pour les PME car la problématique envisagée s'applique essentiellement aux grandes
entreprises et aux sociétés multinationales.
Le premier critère de classification proposé concerne la finalité des échanges
d'information d'une PME avec d'autres entreprises. Sur la base de ce critère on distinguera
trois modèles B to B:
 le modèle des relations transactionnelles.
 le modèle d'intégration des processus.
 le modèle de partage des ressources.
Dans le cas des relations transactionnelles et de l'intégration de processus, on tiendra
compte d'un second critère: la situation d'approvisionnement d'un produit ou service. Ce
critère recouvre deux dimensions:
 l'intensité de la concurrence entre les fournisseurs d'un bien ou service;
 la contribution du bien ou service au profit de l'entreprise qui l'acquiert.

CHAPITRE II : Les différents modèles B2B
1. Le modèle des relations transactionnelles
1.1 Présentation
Dans le cadre de relations traditionnelles avec des entreprises fournisseurs/clientes,
tout ou partie des processus d'achat/de vente font appel à des supports électroniques:
 le passage d'une commande
 l'envoi d'un accusé de réception de la commande
 la notification de livraison
 l'envoi de la facture
 éventuellement l'exécution du paiement.
Figure 2: Modèle des relations transactionnelles
1.2 Les avantages
Les principaux avantages du modèle transactionnel sont:
 la réduction des coûts des transactions commerciales par rapport à un système
classique (fax, courrier postal, téléphone).
 la réduction des coûts internes par diminution des interventions humaines dans les
processus commerciaux et administratifs (économies de temps et rationalisation).
 la réduction des délais nécessaires à l'exécution effective d'une transaction, ce qui
permet d'envisager des méthodes de gestion basées sur une logistique en flux tendus.
Il devrait également contribuer à fidéliser les relations de partenariat avec les
clients/fournisseurs.

1.3 L'EDI (Electronic Data Interchange)
Depuis de nombreuses années, l'EDI et la norme Edifact ont été utilisés pour
standardiser les échanges de données dans les relations transactionnelles entre des grandes
entreprises et avec certains de leurs sous-traitants. Toutefois, la mise en œuvre traditionnelle
de l'EDI est très complexe et coûteuse. L'adoption de l'EDI par les entreprises restait donc un
phénomène marginal, surtout en ce qui concerne les PME. Aujourd'hui, la situation change
radicalement et le modèle transactionnel devient plus accessible aux entreprises de taille
modeste. Ce changement est principalement dû à l'apparition:
 de solutions techniques plus conviviales et moins coûteuses, notamment basées sur
XML, qui permet la traduction des données échangées dans un format standard et
leur présentation via une interface Web.
 d'intermédiaires techniques capables de prendre en charge les aspects les plus
lourds de la gestion des systèmes (sécurité, traduction et archivage des données,
etc.) via des plates-formes spécialisées.
Les risques techniques et les investissements requis (notamment en formation des
utilisateurs et en interfaçage avec les SI existants) deviennent donc moins importants.
2. Le modèle d'intégration de processus
2.1 Présentation
Il s'agit d'intégrer à distance des processus de travail entre des entreprises distinctes.
Ces processus peuvent être industriels ou logistiques. L'intégration peut requérir la mise en
place d'un système de workflow inter-entreprises.
Ce modèle d'e-business a pour objectifs principaux la réduction des coûts de coordination
et le raccourcissement des délais d'échange de biens et de services entre entreprises.
2.2 Fondements
Il se fonde sur:
 la recherche d'une rationalisation maximale dans la conduite d'un processus inter
entreprises.

 une profonde intégration des systèmes d'information, tant au sein des entreprises
participantes qu'entre elles.
 la production de feedbacks appropriés au pilotage du processus global.
3. Le modèle du partage des ressources
3.1 Présentation
Le modèle Business to Business de partage de ressources s'avère particulièrement
important pour les PME wallonnes dans la mesure où il leur permet de regrouper leurs forces
en vue de répondre aux défis majeurs que sont:
 l'intensification de la concurrence
 l'appropriation continue des nouvelles technologies.
Le partage des ressources via l'e-business est aux PME ce que l'entreprise virtuelle est
aux grands groupes industriels. Il convient donc lui accorder une attention particulière. Ce
modèle concerne le recours aux technologies de la communication pour assurer la gestion
partagée d'une ressource commune à plusieurs partenaires. En fonction du type de ressource,
on distinguera quatre sous-modèles:
3.1.1 Partage des capacités de production
Les alliances entre entreprises permettent de:
 répondre en commun à des demandes dépassant les capacités de chaque entreprise
individuelle

 exploiter des capacités de production (matérielles, humaines) sous-utilisées
 partager des équipements ou tout autre moyen de production, en vue de procéder à
des économies d'échelle et/ou à une mutualisation des coûts.
Ce modèle d'e-business est surtout profitable lorsque l'entreprise:
 est confrontée à des fluctuations fréquentes de la demande (activités saisonnières,
etc.)
 n'a pas la taille suffisante pour répondre à toutes les demandes et/ou pour
bénéficier d'économies d'échelle.
3.1.2 Partage des compétences
Partager des compétences permet de:
 troquer des connaissances ou du savoir-faire
 mettre en commun ces connaissances ou ce savoir-faire
 recruter en commun des collaborateurs détenteurs de connaissances ou de
savoir-faire utiles à l'ensemble des partenaires; ce qui implique une grande
confiance mutuelle (peu probable entre concurrents).
Ce modèle d'e - Business imposera une définition précise:
 des procédures de dépôt et de retrait de l'information
 du degré de confidentialité et de disponibilité de l'information partagée.
3.1.3 Partage des informations
Partager des informations clients/marché, pour:
 conquérir de nouveaux marchés sur lesquels les partenaires n'étaient pas encore
présents (par exemple à l'étranger);
 lancer de nouveaux produits.
La complémentarité entre les firmes partenaires est essentielle.
Partager des informations fournisseurs, pour:

 réduire les coûts d'approvisionnement via un accroissement du pouvoir de négociation.
Les formes concrètes de cette stratégie peuvent être:
 le simple échange d'informations (sur demande ou selon un rythme prédéterminé);
 la mise en place d'un système de commandes groupées, en fonction des besoins;
 la constitution de groupements d'achats organisés de manière formelle.
Partager des informations techniques, pour:
 mettre en commun et échanger des informations techniques sur des produits, des
procédés de production, des outils techniques
 mutualiser les coûts d'acquisition, de traitement et d'exploitation de ces informations.
Les formes concrètes de cette stratégie peuvent être:
 la mise en place d'un processus de recherche et développement commun (la
complémentarité des firmes est alors essentielle);
 une veille technologique commune;
 le partage d'expériences techniques (maintenance de machines, procédés de
production, etc.).
Partager des informations de veille sectorielle, économique, concurrentielle, pour:
 mutualiser les coûts attachés à la veille commerciale et concurrentielle.
L'information sectorielle sera propre au secteur d'activité des firmes concernées, alors
que l'information économique est de nature plus générale (état de certains marchés à
l'exportation, de la bourse, suivi macroéconomique, etc.). Une veille concurrentielle commune
à peu de chance de se produire entre concurrents. Cette stratégie ouvre plutôt la voie à des
politiques d'intermédiation pour des entreprises tierces (information broker), qu'à de véritables
politiques Business to Business.
3.1.4 Partage des stocks
La gestion commune des stocks entre entreprises permet de:
 faire face à des pénuries passagères de produits finis ou de matières premières,
 faire face à des demandes qui dépassent les capacités d'une entreprise individuelle,

 mutualiser les risques inhérents à une activité saisonnière.
Ce modèle d'e-business est adapté dans les secteurs:
 confrontés à des fluctuations fréquentes de la demande (activités saisonnières,
etc.);
 où l'état des stocks doit être anticipé longtemps à l'avance (les pépiniéristes par
exemple).
Ce type de coopération nécessite:
 la participation d'un nombre assez important d'entreprises exerçant la même activité,
 un degré de confiance élevé entre partenaires.

PARTIE 2 : IPSEC

CHAPITRE I : Les besoins de sécurité sur IP
1. Les faiblesses d'IP
Originellement IP est le principal protocole d'interconnexion des machines
informatiques. Les spécifications d'IP étaient axées essentiellement sur la robustesse (routage
dynamique, par exemple) et non sur la sécurité (ni la fiabilité). Ainsi actuellement le protocole
IP est sujet à de nombreux problèmes de sécurité dont nous décrirons quelques exemples. IP
étant utilisé aussi bien pour les communications par l'Internet qu'au sein des réseaux
d'entreprises, ces problèmes peuvent avoir de larges répercussions
1.1 L'écoute des paquets
Sur IP, les données transportées sont contenues en clair dans les paquets, il est donc
possible si on peut accéder aux paquets IP qu'échangent deux machines de connaître toutes les
informations échangées entre ces deux machines.
Il existe des outils pour accéder aux paquets en cours de transmission ("sniffer")
comme, par exemple :
 Ethereal qui permet de visualiser les paquets et leur contenu. Il est capable de
réassembler le message TCP d'origine à partir des paquets IP.
 Dsniff qui peut récupérer des mots de passe sur le réseau, est capable de clore
n'importe quelle connexion TCP. Dsniff implémente aussi une attaque dit "de
l'homme au milieu" (man-in-the-middle) sur SSH qui permet notamment de modifier
les paquets lors du transit sans que les deux machines communicantes puissent le
savoir.
Lorsque deux ordinateurs de deux réseaux différents communiquent les paquets
peuvent par exemple transiter successivement sur le réseau de l'entreprise puis sur celui du
fournisseur d'accès Internet (FAI) puis sur la dorsale de l'Internet (backbone) puis sur le FAI
de l'autre réseau puis sur les réseaux de la machine destinatrice. Chaque routeur, ou chaque
brin intermédiaire, sont autant de points où il est possible, pour quelqu'un malintentionné,
d'écouter les communications.

1.2 L'usurpation d'adresse (IP address spoofing)
Un autre problème d'IP est le contrôle des adresses sources. Les routeurs ne vérifient
pas l'adresse source des paquets qui transitent.
L'« usurpation d'adresse IP » (également appelé mystification ou en anglais spoofing
IP) est une technique consistant à remplacer l'adresse IP de l'expéditeur d'un paquet IP par
l'adresse IP d'une autre machine. Cette technique permet ainsi à un pirate d'envoyer des
paquets anonymement. Il ne s'agit pas pour autant d'un changement d'adresse IP, mais d'une
mascarade de l'adresse IP au niveau des paquets émis.
Figure 3: Attaque par usurpation
Ainsi, un paquet spoofé avec l'adresse IP d'une machine interne semblera provenir du
réseau interne et sera relayé à la machine cible, tandis qu'un paquet contenant une adresse IP
externe sera automatiquement rejeté par le pare-feu.
2. Les nouveaux besoins
Aux vues de ces faiblesses, on peut définir de nouveaux besoins auxquels doit
répondre IP:
Confidentialité: La capture des paquets ne doit pas permettre de savoir quelles sont les
informations échangées. Seules les machines réceptrices et émettrices doivent pouvoir
accéder à l'information.
Authentification: Le récepteur doit être capable de vérifier si les données reçues
proviennent bien de l'émetteur supposé.

Intégrité: Le récepteur doit être capable de vérifier si les données n'ont pas été modifiées
lors de la transmission. Il y a aussi des propriétés moins évidentes à saisir mais néanmoins
importantes :
Protection contre le rejeu : Une personne qui intercepte un message d'une
communication sécurisée entre deux machines ne pourra pas retransmettre ce message
sans que cela soit détecté.

CHAPITRE II : Les techniques de sécurité
1. La cryptographie symétrique
Ces systèmes sont appelés symétriques car la même clef sert à chiffrer et à déchiffrer.
Il faut donc que l'expéditeur et le destinataire, et eux seuls, possèdent cette clé pour pouvoir
s'échanger des messages de façon confidentielle.
Il existe plusieurs algorithmes de ce type couramment utilisés dans le monde : DES
(Data Encryption Standard).
C'était le standard du gouvernement américain depuis 1977. Il chiffre par blocs de 64
bits avec une clé d'une longueur de 56 bits. On parle de chiffrement par bloc quand
l'algorithme prend en entrée un message de longueur constante (si le message est plus long, on
le découpe en plusieurs blocs de la longueur voulue). Aujourd'hui cet algorithme est considéré
comme trop faible, car une recherche systématique par essai de clés permet de déchiffrer le
message en un temps raisonnable suite à l'augmentation de la puissance des ordinateurs.
Le "Triple DES" a été introduit pour renforcer la sécurité du DES. Il consiste, pour
simplifier, à chiffrer trois fois le message par DES (par deux ou trois clés de 56 bits).
Le standard (américain) est devenu en 2001 l'algorithme AES (Advanced Encryption
Standard), créé par des chercheurs belges de l'université catholique de Louvain : Vincent
Rijmen et Joan Daemen sous le nom de "Rijndael". L'AES est reconnu comme très sûr, il
bénificie aussi de l'atout de pouvoir être utilisé avec des clés de différentes tailles (128, 192 et
256 bits) et d'être portable sur beaucoup d'architectures.
Il existe bien d'autres algorithmes à clé symétrique : IDEA (International Data
Encryption Algorithm), blowfish, RC4, RC5, cast128, tiger, twofish ...
La figure suivante représente un envoi entre deux personnes avec un algorithme
symétrique :

Figure 4: Envoi de message chiffré avec un algorithme symétrique
Alice et Bob partagent la même clé K, ils chiffrent le texte en clair et déchiffrent le
texte chiffré avec K.
2. La cryptographie asymétrique
Dans les systèmes à clefs asymétriques, les clefs de chiffrement et de déchiffrement
sont distinctes cependant elles sont liées par une relation mathématique mais ne peuvent pas
être déduites l'une de l'autre (dans la pratique). La clef de chiffrement est rendue publique
(appelée clef publique) tandis que celle de déchiffrement doit être gardée totalement secrète
(et appelée clef privée).
Ainsi tout le monde peut chiffrer un message avec la clé publique (ou clé de
chiffrement) mais seul le détenteur de la clé privée (ou clé de déchiffrement) peut déchiffrer le
message chiffré.
Un autre intérêt de ce système, c'est qu'il permet la vérification d'identité. En effet la
clé privée peut aussi servir de clé de chiffrement pour l'algorithme considéré et tout le monde
pourra déchiffrer le message chiffré avec la clé publique.
La figure suivante représente un envoi entre 2 personnes avec un algorithme asymétrique.
Figure 5 : envoi de message chiffré avec un algorithme asymétrique

Alice et Bob et n’importe quelle personne sur Internet connaissent les clés publiques
PKa et PKb. Alors que chacun possède sa propre clef privée SKa et SKb. Pour envoyer un
message à Bob, Alice chiffre le message M avec la clef publique de Bob. Ensuite elle obtient
un message C=Eb(M) et le transmet sur le réseau que n’ importe quel intrus peut l’intercepter
et ne peut guère le déchiffrer puisqu’ il a besoin de la clé privé de Bob pour le déchiffrer.
Pour éviter de charger les processeurs avec des temps de calcul, les techniques
utilisées font appel à une combinaison des deux systèmes. En effet les algorithmes
asymétriques sont utilisés pour transmettre la clé qui sera utilisé avec les algorithmes
symétriques ou pour signer des documents.
3. Le Hachage
Le hachage est un mécanisme qui consiste à calculer, à partir d’un message initial une
empreinte de taille fixe et inférieure au message initial, en appliquant une transformation
mathématique sur ce dernier. Cette fonction traite une entrée de longueur variable (dans ce
cas, un message pouvant contenir des milliers ou des millions de bits), afin d'obtenir en sortie
un élément de longueur fixe appelée « valeur hash » En cas de modification des données
(même d'un seul bit), la fonction de hachage garantit la production d'une « valeur hash »
différente, ce qui garantit l’intégrité d’un texte transmis. Les algorithmes les plus utilisées
sont :
MD5 (Message Digest) : crée une empreinte de 128 bits.
SHA (Secure Hash Algorithm) : crée des empreintes de 160 bits.
4. La signature numérique
Celle-ci permet au destinataire de vérifier l’authenticité, l’origine, et l’exactitude des
données reçues. Ainsi, les signatures numériques sur base de systèmes à clé publique
garantissent l'authentification et l'intégrité des données. Elles fournissent également une
fonctionnalité de non répudiation, afin d'éviter que l'expéditeur prétende ne pas avoir envoyé
les informations. Ceci est possible puisque la signature électronique est réalisée avec l'aide de
la clé privée du signataire.
La figure suivante représente les différentes étapes d’envoi et de vérification de
signature numérique que nous venons de citer :

Figure 6 : envoi de message avec une signature
A chiffre le texte avec la clé publique de B et l’envoie. Il garanti ainsi la
confidentialité du document. Ensuite il calcule le message haché qui le chiffre avec sa clé
privée et l’envoi à B.
De son coté B déchiffre le message reçu par sa clé privée et calcule son haché, puis
déchiffre par la clé publique de A le deuxième message et le compare avec le haché qu’il a
calculé. En cas d’égalité l’intégrité du message et la non répudiation ont été garantis.
Récemment des nouveaux protocoles, regroupant les différents points fondamentaux dont
nous venons de les citer ont été élaboré. Parmi ceux-ci, IPsec et IKEv2 feront sujet du
paragraphe suivant.

Chapitre III : Présentationd’IPsec
1. Définition
IPsec (Internet Protocol Security) est un ensemble de protocoles permettant le
transport de données IP sécurisées. Il comprend des mécanismes de chiffrement et
d’authentification. L’IETF (Internet Engineering Task Force) standardise ce protocole et
son architecture depuis 1995, et publie des RFCs dont la plus importante aujourd’hui
est IPsecv2 [2]. Il a été décidé que IPsec serait obligatoire dans IPv6 et facultatif dans
IPv4, mais
avec un
mécanisme
identique.
Figure 7 : Le protocole IPSec dans le modèle OSI
Ipv4 et Ipv6 sont deux versions de l’Internet Protocol (IP), protocole de niveau 3 dans
le modèle OSI. Elles n’oﬀrent aucun service de sécurité. IPsec va permettre de sécuriser les
communications s’appuyant sur IP. Ce protocole a été développé par l’Internet Engineering
Task Force (IETF) qui travaille depuis 1992 à la standardisation d'IPsec et des RFC ont été
produites en ce sens depuis 1995.
Il permet de sécuriser les échanges de données au niveau de la couche réseau. Il est
optionnel dans Ipv4 bien que recommandable, et mis en place (implémentation) dans Ipv6.
IPsec assure une protection renforcée contre les attaques grâce à une sécurité de bout en bout.
Les seuls ordinateurs qui doivent connaitre la protection IPsec sont l’émetteur et le
destinataire de la communication.

IPsec permet de protéger les communications entre les groupes de travail, les
ordinateurs du réseau local, les clients et serveurs de domaine, les succursales (éventuellement
distantes), les extranets et les clients itinérants. IPsec n’est pas un protocole ﬁxe il s’agit d’un
cadre pour implémenter les services de sécurité (le choix existe pour les services et les
protocoles de chiﬀrement).
2. Mécanismes de sécurité
Pour sécuriser les échanges ayant lieu sur un réseau TCP/IP, il existe plusieurs
approches, en particulier en ce qui concerne le niveau auquel est effectué la sécurisation :
niveau applicatif (messages chiffrés par exemple), niveau transport (TLS/SSH), ou à l’opposé
niveau physique (boîtiers chiffrant toutes les données transitant par un lien donné). IPsec,
quand à lui, vise à sécuriser les échanges au niveau de la couche réseau.
La sécurité de cette communication est garantie par le fait qu’IPsec présente ces
différents services :
 la confidentialité : capacité à ne permettre l'accès à des donnés que par des
personnes ou des processus autorisés.
 L'authentification : capacité à connaître l'identité des personnes ou processus
qui envoie des données ou des messages.
 L'intégrité : IPSec permet de s'assurer qu'aucun paquet n'a subit de
modification quelconque (attaque dite active) durant sa transmission.
 La non – répudiation : l'auteur des données ou messages envoyer ne peut renier
ce qu'il a fait.
 Protection contre les écoutes et analyses de trafic : IPsec permet de chiffrer les
adresses IP réelles de la source et de la destination, ainsi que tout l'en-tête IP.
C'est le mode de tunneling, qui empêche tout attaquant à l'écoute d'interférer
des informations sur les identités réelles des extrémités du tunnel.
 Protection contre le rejeu : C’est le fait de capturer un ou plusieurs paquets
dans le but de les envoyer à nouveau (sans avoir à les déchiffrés). IPsec permet
de se prémunir contre ce type d’attaque.
IPsec fait ainsi appel à deux principaux mécanismes de sécurité pour le trafic IP : les
protocoles AH (Authentication Header) et ESP (Encapsulation Security Payload).

2.1 Authentication Header (AH)
Le mécanisme AH est conçu pour assurer l’intégrité et l’authentification des
datagrammes IP sans chiffrement des données (i.e. sans confidentialité). Il protège aussi
contre le rejeu (permet de détecter une tentative d’attaque consistant à envoyer de
nouveau un paquet valide intercepté précédemment sur le réseau).
Le principe d’AH est d’adjoindre au datagramme IP classique un champ
supplémentaire permettant à la réception de vérifier l’authenticité des données incluses dans
le datagramme.
2.2 Encapsulation Security Payload (ESP)
Esp peut assurer au choix, un ou plusieurs des services suivants :
 Confidentialité (confidentialité des données et protection partielle contre l'analyse du
trafic si l'on utilise le mode tunnel).
 Intégrité des données en mode non connecté et authentification de l'origine des
données, protection contre le rejeu.
La confidentialité peut être sélectionnée indépendamment des autres services, mais son
utilisation sans intégrité/authentification (directement dans ESP ou avec AH) rend le trafic
vulnérable à certains types d'attaques actives qui pourraient affaiblir le service de
confidentialité.
Figure 8: IPSec Authentication Header (AH)

Le champ bourrage peut être nécessaire pour les algorithmes de chiffrement par blocs
ou pour aligner le texte chiffré sur une limite de 4 octets.
Les données d'authentification ne sont présentes que si ce service a été sélectionné.
Voyons maintenant comment est appliquée la confidentialité dans Esp.
L'expéditeur :
 Encapsule, dans le champ "charge utile" d’Esp, les données transportées par le
datagramme original et éventuellement l'en-tête IP (mode tunnel).
 Ajoute si nécessaire un bourrage.
 Chiffre le résultat (données, bourrage, champs longueur et en-tête suivant).
 Ajoute éventuellement des données de synchronisation cryptographiques (vecteur
d'initialisation) au début du champ "charge utile".
Un des grands apports d'IPsec est de sécuriser toutes les applications ou
communications au-dessus d'IP de façon transparente.
3. Les modes de sécurité d’IPsec
Il existe deux modes dans IPsec, le mode Transport et le mode Tunnel. Ces deux
modes diffèrent par la méthode de construction des paquets IP des messages.
Figure 9 : IPSec ESP format

3.1 Le mode Transport
Le mode Transport ne modifie pas l'en-tête initial; seules les données sont protégées.
Il s'intercale entre le protocole réseau (IP) et le protocole de transport (TCP, UDP...).
Plusieurs variantes existent, conformément aux protocoles décrits plus haut :
Figure10 : Transformation AH en mode Transport.
Figure 11 : Transformation ESP en mode Transport.
3.2 Le mode Tunnel
Le mode Tunnel remplace les en-têtes IP originaux et encapsule la totalité du paquet
IP. Par exemple, l'adresse IPA externe pourra être celle de la passerelle de sécurité
implémentant IPsec, et l'adresse IPB interne sera celle de la machine finale, sur le réseau
derrière la passerelle. La figure suivante représente un exemple de mode tunnel.
Figure 12 : Exemple de communication sécurisé en mode tunnel

Dans cette figure les paquets échangées sur le réseau ne porte que les adresses des
passerelles, les adresses des réseaux A et B de destination sont encapsulées et chiffrées dans
le paquet IPsec.
Dans ce cas un attaquant capable d’observer les données transitant par un lien n’est
pas à même de déterminer quel volume de données est transféré entre deux hôtes particuliers.
La figure suivante représente l’ordre d’encapsulation des protocoles AH et ESP dans ce mode:
Figure 13 : Transformation AH en mode Tunnel.
Figure 14 : Transformation ESP en mode Tunnel.
Dans le mode Tunnel, tout le paquet IP est protégé. Pour cela, il est considéré comme
un simple message, et un nouvel en-tête IP est créé.
Le mode Tunnel possède comme grand intérêt de pouvoir créer des tunnels sécurisés.
Deux machines ou passerelles de deux réseaux voulant sécuriser leurs communications qui
passent par une zone non protégée, vont créer un tunnel IPsec entre ces deux passerelles.
Toute communication d'une machine d'un réseau vers l'autre sera encapsulée dans un nouvel
en-tête IP. Une personne écoutant la communication ne verrait que des paquets allant d'une
passerelle à l'autre sans pouvoir comprendre le contenu de ces paquets. Ce mode correspond à
un réseau privé virtuel ou VPN (Virtual Private Network).
On peut parfois trouver un troisième mode hybride nommé le mode Nesting il utilise à
la fois le mode transport et le mode tunnel : Un paquet IPsec est encapsulé dans un paquet
IPsec comme l’explique la figure suivante :
Figure 15: le mode hybride Nesting

CHAPITRE IV : Politiques de sécurité et gestiondes clés
1. Politiques de sécurité
1.1 La "Security Policy Database" (SPD)
La "Security Policy Database" (SPD) regroupe l'ensemble des comportements que le
système doit présenter par rapport à des communications externes. Cette base sert donc à
décider, lors de l'ouverture d'une communication, si elle doit ou non utiliser IPsec. En général,
les adresses source et destination, le protocole et les ports source et destination (pour TCP ou
UDP) suffisent pour définir une politique de sécurité ("Security Policy" en anglais). Il est à
noter qu'une "Security Policy" est unidirectionnelle comme une SA, si la communication veut
s'établir dans les deux sens il faudra deux "Security Policy" ou entrée dans la SPD.
Il faut ensuite associer à ces communications les fonctionnalités IPsec que l'on veut
leur appliquer. Si on désire de la confidentialité, on va spécifier qu'il faut utiliser la
transformation ESP. On peut aussi spécifier que l'on désire de l'authentification, il s'agit alors
de la transformation AH. Il existe aussi la transformation "Ipcomp" (IP compression) qui
compresse les paquets.
1.2 La "Security Association Database" (SADB)
La SAD donne un contexte à chaque connexion unidirectionnelle IPsec, qu’on appelle
SA ou « association de sécurité », regroupant l’ensemble de ces informations.
Une association de sécurité (SA) est donc une structure de données qui regroupe
l’ensemble des paramètres de sécurité associés à une communication donnée. Une SA est
unidirectionnelle. En conséquence, protéger une ligne de communication requiert deux
associations, une dans chaque sens. Les services de sécurité sont fournis par l’utilisation soit
de AH soit de ESP. Si AH et ESP sont tous deux appliqué au trafic en question, deux SA
(voire plus) sont créées ; on parle de paquet (bundle) de SA.
Une SA regroupe l'ensemble de ces informations :
 L’index qu’identifie une SA : SPI (Security Parameter Index)
 les adresses @source et @destination
 le mode de la connexion IPsec (tunnel ou transport)

 le type de service de sécurité IPsec utilisé : ESP ou AH
 l’algorithme utilisé pour le service, et la clé utilisée
 Le temps de vie
La PAD (Policy Authorization Database) est une base de données indiquant la manière
dont un nœud doit être identifié, ou quels sont les identifiants qui doivent être pris en
compte lors de la phase d'authentification.
2. Gestion des clefs : IKE et ISAKMP
Les protocoles sécurisés présentés dans les paragraphes précédents ont recours à des
algorithmes cryptographiques et ont donc besoin de clefs. Un des problèmes fondamentaux
d'utilisation de la cryptographie est la gestion de ces clefs. Le terme "gestion" recouvre la
génération, la distribution, le stockage et la suppression des clefs.
IKE (Internet Key Exchange) est un système développé spécifiquement pour Ipsec qui
vise à fournir des mécanismes d'authentification et d'échange de clef adaptés à l'ensemble des
situations qui peuvent se présenter sur l'Internet. Il est composé de plusieurs éléments : le
cadre générique Isakmp et une partie des protocoles Oakley et Skeme. Lorsqu'il est utilisé
pour Ipsec, IKE est de plus complété par un "domaine d'interprétation" pour Ipsec.
2.1 ISAKMP
ISAKMP (Internet Security Association and Key Management Protocol) a pour rôle la
négociation, l'établissement, la modification et la suppression des associations de sécurité et
de leurs attributs. Il pose les bases permettant de construire divers protocoles de gestion des
clefs (et plus généralement des associations de sécurité). Il comporte trois aspects principaux :
 Il définit une façon de procéder, en deux étapes appelées phase 1 et phase 2 : dans la
première, un certain nombre de paramètres de sécurité propres à ISAKMP sont mis en
place, afin d'établir entre les deux tiers un canal protégé ; dans un second temps, Ce
canal est utilisé pour négocier les associations de sécurité pour les mécanismes de
sécurité que l'on souhaite utiliser (AH et Esp par exemple).
 Il définit des formats de messages, par l'intermédiaire de blocs ayant chacun un rôle
précis et permettant de former des messages clairs.

 Il présente un certain nombre d'échanges types, composés de tels messages, qui
permettant des négociations présentant des propriétés différentes : protection ou non
de l'identité, perfect forward secrecy (PFS).
ISAKMP est décrit dans la Rfc 2408.(conf. Annexe B)
2.1 IKE
IKE utilise ISAKMP pour construire un protocole pratique. Il comprend quatre modes :
 Le mode principal (Main mode)
 Le mode agressif (Aggressive Mode)
 Le mode rapide (Quick Mode)
 Le mode nouveau groupe (New Groupe Mode)
Main Mode et Aggressive Mode sont utilisés durant la phase 1, Quick Mode est un
échange de phase 2. New Group Mode est un peu à part : Ce n'est ni un échange de phase 1,
ni un échange de phase 2, mais il ne peut avoir lieu qu'une fois qu'une SA Isakmp est établie ;
il sert à se mettre d'accord sur un nouveau groupe pour de futurs échanges Diffie-Hellman.
3. Les phases d'IKE
ISAKMP se décompose en deux phases:
 La première phase permet de vérifier l'identité des entités en présence. On décide des
algorithmes de cryptographie utilisés pour les futures négociations ISAKMP.
Á la fin de cette phase, chaque entité doit disposer d'une clé de chiffrement, d'une clé
d'authentification et d'un secret partagé qui servira de "graine" dans la phase suivante (on
produit une clé en fonction de valeurs déjà calculées).
 La deuxième phase permet de négocier les attributs plus spécifiques à Ipsec
(utilisation d'AH ou d'ESP par exemple), ces échanges sont chiffrés et authentifiés
grâce aux éléments décidés lors de la première phase.
Il y a un intérêt à ce découpage. La première phase fait appel à de la cryptographie
asymétrique qui est lente, elle est de plus utilisée qu'une seule fois pour définir les paramètres
qui vont permettre de sécuriser les échanges de phase 2. La phase 2 est en revanche appelée
plusieurs fois, en effet les clés qui servent à chiffrer deviennent vulnérables avec le temps ou

quand on s'en sert beaucoup (un cryptanalyste a plus de matériel (ou messages) pour essayer
de casser la clé). Cette phase est donc régulièrement ré-effectuée pour changer certaines clés
de sessions.
Il existe en effet trois grands types d'utilisation de clé :
 les clés de chiffrement de clés : elles sont souvent de très longue durée de vie et
peuvent être contenues dans des certificats.
 les clés maîtresses : elles servent à générer d'autre clés, par exemple une pour
l'authentification et une autre pour le chiffrement (le secret partagé à la fin de Diffie-
Hellman rentre dans cette catégorie).
 les clés de session : ce sont elles qui sont utilisés pour chiffrer par exemple, elles ont
en général une durée de vie assez faible (ça peut être quelques minutes).
Il existe plusieurs schémas possibles pour la phase 1. On décide de celui que l'on veut
utiliser suivant le degré de rapidité ou de sécurité que l'on veut atteindre. Il faut aussi que le
démon IKE de l'autre système accepte le schéma que l'on propose. En général l'administrateur
précise un ordre de préférence.
On va utiliser les notations standards définies dans la RFC 2409 (conf. Annexe B)
3.1 Première Phase
Deux modes sont possibles pour la première phase, le mode "main" et le mode
"aggressive".
 Le mode principal (Main mode)
Dans le premier échange, les deux entités se mettent d'accord sur les paramètres
cryptographiques à utiliser. Le deuxième échange est un échange Diffie-Hellman. Après le
deuxième échange, les deux entités ont donc un secret partagé qui permet de chiffrer la suite
des échanges. Dans le troisième échange, l'identité des entités est vérifiée (elles ne sont
accessibles que par elles).
Initiator Responder
HDR, SA
------------------------------------------------------------->
HDR, SA

<------------------------------------------------------------
HDR, KE, Nonce
------------------------------------------------------------->
HDR, KE, Nonce
<-------------------------------------------------------------
HDR*, IDii, Auth
-------------------------------------------------------------->
HDR*, IDir, Auth
<--------------------------------------------------------------
figure 12. Main mode
 Le mode Agressif (aggressive mode)
Le premier message (de l'Initiator) envoie les propositions des mécanismes
cryptographiques mais aussi le matériel pour l'échange de Diffie-Hellman. Le deuxième
échange (du Responder) finalise le choix des mécanismes de sécurité, termine l'échange
Diffie-Hellman et envoie l'information pour prouver son identité. Le dernier message permet
à l'Initator de prouver son identité. L'intérêt de ce mode est d'être très rapide car diminue les
échanges (3 messages au lieu de 6), mais assure un niveau de sécurité plus faible (notamment
les identités ne sont pas protégées).
Initiator Responder
HDR, SA, KE, Nonce, IDii
--------------------------------------------->
HDR, SA, KE, Nonce, IDir, Auth
<--------------------------------------------
HDR*, Auth
---------------------------------------------->
figure 13. Aggressive Mode
3 .2 Deuxième Phase
Les messages échangés durant la phase 2 sont protégés en authenticité et en
confidentialité grâce aux éléments négociés durant la phase 1. L'authenticité des messages est

assurée par l'ajout d'un bloc Hash après l'en-tête Isakmp et la confidentialité est assurée par le
chiffrement de l'ensemble des blocs du message.
Quick Mode est utilisé pour la négociation de SA pour des protocoles de sécurité
donnés comme Ipsec. Chaque négociation aboutit en fait à deux SA, une dans chaque sens de
la communication.
Plus précisément, les échanges composant Ce mode ont le rôle suivant :
 Négocier un ensemble de paramètres Ipsec (paquets de SA)
 Échanger des nombres aléatoires, utilisés pour générer une nouvelle clef qui dérive du
secret généré en phase 1 avec le protocole Diffie-Hellman. De façon optionnelle, il est
possible d'avoir recours à un nouvel échange Diffie-Hellman, afin d'accéder à la
propriété de Perfect Forward Secrecy, qui n'est pas fournie si on se contente de
générer une nouvelle clef à partir de l'ancienne et des aléas.
 Optionnellement, identifier le trafic que Ce paquet de SA protégera, au moyen de
sélecteurs (blocs optionnels IDi et IDr ; en leur absence, les adresses Ip des
interlocuteurs sont utilisées).
D'autre part, il existe une option appelée Perfect Secrecy Mode (PFS) qui force les
parties à échanger de nouveaux secrets supplémentaires dans le but d'éviter que toutes les clés
du système ne dépendent d'une seule et même clé mère (SKEYID).
Initiator Responder
HDR*, HASH(1), SA, Nonce, [KE] [IdDi,IDcr]
------------------------------------------------------------------------------------->
HDR*, HASH(2), SA, Nonce, [KE] [IdDi,IDcr]
<------------------------------------------------------------------------------------
HDR*, HASH(3)
------------------------------------------------------------------------------------->
figure 14. Le Quick Mode

3.3 Les groupes : New Groupe Mode
Le groupe à utiliser pour Diffie-Hellman peut être négocié, par le biais du bloc SA,
soit au cours du Main Mode, soit ultérieurement par le biais du New Group Mode. Dans les
deux cas, il existe deux façons de désigner le groupe à utiliser :
 Donner la référence d'un groupe prédéfini : il en existe actuellement quatre, les quatre
groupes Oakley (deux groupes MODP et deux groupes EC2N).
 Donner les caractéristiques du groupe souhaité : type de groupe (MODP, ECP, EC2N),
nombre premier ou polynôme irréductible, générateurs...
3.4 Phases et modes
Au final, le déroulement d'une négociation IKE suit le diagramme suivant :
Figure 16: Organigramme d’IPsec
4. Architecture d’IPsec
L’architecture d’IPsec, d’accord avec l’information présentée, peut se résumer dans le
schéma suivant :
Négociation
ISAKMP SA
Négociation de SA
pour AH et ESP

Figure 17: Schéma global d'IPsec
 Le trafic entrant et le trafic sortant
Trafic sortant : lorsque la couche IPsec reçoit des paquets sortants (la machine veut
envoyer un paquet vers l’extérieur), le système vérifie dans la SPD quelle politique
IPsec (SP) doit être associée à ce paquet. S’il existe une politique IPsec, le système va
rechercher s’il existe une SA qui correspond à cette SP. Si le système trouve la SA
correspondant, le paquet se voit appliquer les règles définies dans la SA, sinon le
système va appeler le démon IKE pour négocier une SA avec le nœud destinataire
du paquet. Cette SA doit satisfaire les SP des deux nœuds.
Trafic entrant : lorsque la couche IPsec reçoit un paquet en provenance du réseau,
elle examine l'en-tête pour savoir si ce paquet s'est vu appliquer un ou plusieurs
services IPsec et si oui, quelle SA. Elle consulte alors la SAD pour connaître les
paramètres à utiliser pour la vérification et/ou le déchiffrement du paquet. Une fois le
paquet vérifié et/ou déchiffré, la SPD est consultée pour savoir si la SA
appliquée au paquet correspondait bien à celle requise par les politiques de
sécurité. Dans le cas où le paquet reçu est un paquet IP classique, la SPD permet de
savoir s'il a néanmoins le droit de passer.

5. Cas concret d'échange IKE entre deux machines
Deux machines essayent de mettre en place IPsec entre elles. Il s'agit des machines
d'adresse IPv6 2001:660:284:100:2c0:4fff:fea9:8128 (machine A) et
2001:660:284:100:200:c0ff:fe4a:d8c5 (machine B).
Ces traces sont tirées d'une option du démon ISAKMPd qui enregistre les paquets des
échanges après les avoir déchiffrés si nécessaire. On peut noter que l'autre démon utilisé est
racoon, il y a bien une certaine interopérabilité entre les divers démons existants (mais pas
totale).
Ces traces ne sont que des illustrations des schémas d'échange ci-dessus.
Début de la première phase.
A ------ HDR + SA -----------------> B
14:24:26.639104 2001:660:284:100:2c0:4fff:fea9:8128.500 >
2001:660:284:100:200:c0ff:fe4a:d8c5.500: isakmp: phase 1 I ident:
(sa: doi=ipsec situation=identity
(p: #1 protoid=isakmp transform=1
(t: #0 id=ike (type=enc value=3des)(type=hash value=md5)(type=auth
value=preshared)(type=group desc value=modp1024)(type=lifetype value=sec)(type=lifedu
ration value=0e10))))
On remarque que A propose de chiffrer avec 3DES, de hacher avec MD5 et que la
méthode d'authentification est le secret partagé (preshared).
B ---------- HDR, SA ---------------> A
14:24:33.714317 2001:660:284:100:200:c0ff:fe4a:d8c5.500 >
2001:660:284:100:2c0:4fff:fea9:8128.500: isakmp: phase 1 R ident:
(p: #1 protoid=isakmp transform=1
(t: #0 id=ike (type=enc value=3des)(type=hash value=md5)(type=auth
value=preshared)(type=group desc value=modp1024)(type=lifetype value=sec)(type=lifedu
ration value=0e10))))
(vid: len=16)

Même proposition du coté de B, il y a donc concordance. Un bloc vid pour Vendor Id
est aussi fourni.
A ---------- HDR, KE, Nonce ------> B
14:24:33.807258 2001:660:284:100:2c0:4fff:fea9:8128.500 >
(ke: key len=128)
(nonce: n len=16)
Début de l'échange de Diffie-Hellman.
B ---------- HDR, KE, Nonce ------> A
14:24:33.917484 2001:660:284:100:200:c0ff:fe4a:d8c5.500 >
(ke: key len=128)
(nonce: n len=16)
(vid: len=16)
Continuation de Diffie-Hellman
A ---------HDR, ID; Hash ----------> B
14:24:34.042996 2001:660:284:100:2c0:4fff:fea9:8128.500 >
(id: idtype=IPv6 protoid=0 port=0 len=16 2001:660:284:100:2c0:4fff:fea9:8128)
(hash: len=16)
(n: doi=ipsec proto=isakmp type=INITIAL-CONTACT spi=92ae255eba1e5c1672cc477ad2370f71)
A décline son identité sous forme d'adresse IPv6. Le INITIAL-CONTACT est un
signal du démon qui fait savoir que pour lui c'est la première fois que le communication
s'établit et qu'il faut donc oublier les anciennes SA. Le bloc Hash sert à l'authentification ici
(idem dans la suite de l'échange).
B ---------HDR, ID; Hash ----------> A
14:24:34.177205 2001:660:284:100:200:c0ff:fe4a:d8c5.500 >

(id: idtype=IPv6 protoid=udp port=500 len=16 2001:660:284:100:200:c0ff:fe4a:d8c5)
(hash: len=16)
De même B décline son identité.
Début de la deuxième phase.
A ----------HDR,SA,KE,Nonce, ID, Hash --> B
14:24:34.312872 2001:660:284:100:2c0:4fff:fea9:8128.500 >
2001:660:284:100:200:c0ff:fe4a:d8c5.500: isakmp: phase 2/others I oakley-quick:
(hash: len=16)
(p: #1 protoid=ipsec-esp transform=1 spi=1ee4aa74
(t: #1 id=3des (type=lifetype value=sec)(type=life value=04b0)(type=enc mode
value=transport)(type=auth value=hmac-md5)(type=group desc value=modp1024))
))
(nonce: n len=16)
(ke: key len=128)
(id: idtype=IPv6 protoid=0 port=0 len=16 2001:660:284:100:200:c0ff:fe4a:d8c5)
On peut remarquer que dans le bloc Proposal le protoid est maintenant ipsec-esp au
lieu de isakmp auparavant.Un spi est proposé, ansi que l'algorithme de chiffrement (3DES),
l'algorithme d'authentification utilisera hmac-md5 comme fonction de hachage.
Ici la réponse au initial contact:
14:24:34.341761 2001:660:284:100:200:c0ff:fe4a:d8c5.500 >
2001:660:284:100:2c0:4fff:fea9:8128.500: isakmp: phase 2/others R inf:
(hash: len=16)
(n: doi=ipsec proto=isakmp type=INITIAL-CONTACT spi=92ae255eba1e5c1672cc477ad2370f71
orig=([|isakmp]))
B ----------HDR,SA,KE,Nonce, ID, Hash --> A

14:24:34.598281 2001:660:284:100:200:c0ff:fe4a:d8c5.500 >
2001:660:284:100:2c0:4fff:fea9:8128.500: isakmp: phase 2/others R oakley-quick:
(hash: len=16)
(p: #1 protoid=ipsec-esp transform=1 spi=0d37f6e5
(t: #1 id=3des (type=lifetype value=sec)(type=life value=04b0)(type=enc mode
value=transport)(type=auth value=hmac-md5)(type=group desc value=mod
p1024))))
(nonce: n len=16)
(ke: key len=128)
(id: idtype=IPv6 protoid=0 port=0 len=16 2001:660:284:100:200:c0ff:fe4a:d8c5)
La réponse propose des caractéristiques identiques à celles proposées, les deux entités
sont donc d'accord sur celles-ci.
A ----------- Hash -------------------------------> B
14:24:34.638155 2001:660:284:100:2c0:4fff:fea9:8128.500 >
2001:660:284:100:200:c0ff:fe4a:d8c5.500: isakmp: phase 2/others I oakley-quick:
(hash: len=16)

Chapitre V : Les failles du protocole IPsec
1. Quelques failles actuelles d’IPsec
En introduisant des protocoles de sécurité dans un réseau, que ce soit pour filtrer les
communications, ou pour protéger le trafic en confidentialité ou en authentification, les
performances d'un réseau en termes de débit et temps de transit sont affectées. Cette
diminution de performances est en partie due aux opérations de chiffrement/déchiffrement et
de génération/vérification de l'authentification qui sont très gourmandes en temps de calcul.
IPsec en particulier présente certaines lacunes dont on cite :
 La protection d’une communication multicast avec IPsec n'est pas possible à
ce moment. En effet les deux protocoles AH et ESP l’autorisent mais le
protocole qui gère ces associations de sécurité IKE, que nous détaillerons
dans le chapitre suivant, ne permet pas de négocier des associations de sécurité
qu’entre deux terminaux.
 Le renouvellement des associations de sécurité occupe toute la bande passante
et aucun autre message n’est échangé.
 L’utilisation du protocole DHCP permet entre autre d'allouer dynamiquement
une adresse à un terminal. La difficulté est de savoir, au niveau d'une
passerelle, quelle politique de sécurité à cette adresse.
 Le manque de dynamité dans la mise en œuvre des IPsec. Pour que les IPsec
soient d'un usage plus courant, non limité à un domaine administratif défini, il
faudrait que n'importe quel couple d'équipements IPsec puisse entrer en
communication de façon improvisée, sans aucun arrangement initial sur des
secrets cryptographiques, des certificats, sans faire appel à des services
spécifiques.

PARTIE 3 : DEPLOIEMENT DE IPSEC

Chapitre I : Installation de IPsec
1. Introduction
Pour la mise en œuvre pratique de IPsec, le modèle du partages des ressources est
celui qui a été choisit pour ce projet. Celui-ci ne pose pas une exigence particulière par
rapport à la méthode de configuration. Ainsi, nous avons choisi de configurer une machine
hôte et sa passerelle/serveur qui peut être qualifié de méthode Host to Host, en mode Tunnel.
Pour l’authentification trois modes sont possibles: le mode du secret partagé (Pre
Shared Key), le mode du certificat X509.le mode (appelé abusivement) DNSsec et X509, où
le certificat X509 est récupéré via le DNS. Nous utiliserons le mode du secret partagé.
2. Scénario
Le scénario classique est :
 l'administrateur de la machine configure la SPD grâce à la commande setkey.
 Lorsqu’ un paquet passe par la machine (depuis ou vers le réseau) le noyau
vérifie s'il correspond ou non à une entrée de la SPD.
 si IPsec est demandé pour ce paquet le noyau cherche les attributs IPsec
correspondants dans la SAD.
 si ces attributs n'existent pas alors le noyau demande au démon IKE (racoon)
de les négocier avec la machine concernée.
 les attributs sont négociés entre les deux démons IKE.
Figure 18: Tunnel IPsec entre un hôte et le
serveur local

 racoon les positionne dans une nouvelle entrée de la SADB et le paquet peut
enfin être chiffré ou authentifié grâce à IPsec.
3. Outils utilisés
 Environnement de test : VMware (createur de machine virtuelle)
 Système d’exploitation : Ubuntu 10.04
 IPsec-tools
 Racoon
4. Installation
 Installation des outils « ipsec-tools » et « racoon » via les paquets ubuntu :
sudo -s
# apt-get install ipsec-tools
# apt-get install racoon
 Chargement manuelle des modules noyau nécessaires :
modprobe esp4
Capture d'écran 1: Installation d’IPsec et Racoon

modprobe ah4
modprobe ipcomp
 Configuration du chargement permanent, en modifiant le fichier « /etc/modules » :
vim /etc/modules
# Ajout des modules
esp4
ah4
ipcomp
Capture d'écran 2: Chargement des modules noyau

Chapitre 2 : Configuration d’IPsec
1. Configuration de la première machine
Adresse IP PC1 : 192.168.1.25
Adresse IP PC2 : 192.168.1.24
 Modification du fichier « /etc/racoon/setkey.conf » :
#!/usr/sbin/setkey -f
# On efface les politiques de sécurité
# Flush the Security Association Database (SAD)
# And the Security Policy Database (SPD)
flush;
spdflush;
# AH SAs using 128 bit long keys
add 192.168.1.25 192.168.1.24 ah 0x200 -m transport -A hmac-md5
0xc0291ff014dccdd03874d9e8e4cdf3e6;
0x96358c90783bbfa3d7b196ceabe0536b;
# ESP SAs using 192 bit long keys (168 + 24 parity)
add 192.168.1.25 192.168.1.24 esp 0x201 -m transport -E 3des-cbc
0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831;
0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df;
# Politiques de sécurité

spdadd 192.168.1.25 192.168.1.24 any -P out ipsec
esp/transport//require
ah/transport//require;
spdadd 192.168.1.24 192.168.1.25 any -P in ipsec
 Mise à jour les droits :
chmod 600 /etc/racoon/setkey.conf
 Lancement de la mise à jour :
setkey -f /etc/racoon/setkey.conf
 Vérification des modifications :
setkey -D

setkey -DP
 On sauvegarde les paramètres pour chaque redémarrage dans le fichier « /etc/rc.local
» :
#!/bin/sh -e
# rc.local
# Force IPSEC dès le démarrage
exit 0

2. Configuration de la deuxième machine
La configuration du deuxième PC est pratiquement la même. Une légère différence se pose au
niveau de la configuration de la politique de sécurité du fichier /etc/racoon/setkey.conf
 Modification du fichier « /etc/racoon/setkey.conf » :
#!/usr/sbin/setkey -f
# On efface les politiques de sécurité
# Flush the Security Association Database (SAD)
# And the Security Policy Database (SPD)
flush;
spdflush;
# AH SAs using 128 bit long keys
0xc0291ff014dccdd03874d9e8e4cdf3e6;
0x96358c90783bbfa3d7b196ceabe0536b;
# ESP SAs using 192 bit long keys (168 + 24 parity)
0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831;
0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df;
# Politiques de sécurité
spdadd 192.168.1.25 192.168.1.24 any -P in ipsec

spdadd 192.168.1.24 192.168.1.25 any -P out ipsec
 mise à jour :
 Vérification des modifications :
setkey -D

setkey -DP
 On sauvegarde les paramètres pour chaque redémarrage dans le fichier « /etc/rc.local »
:
#!/bin/sh -e
# rc.local
# Force IPSEC dès le démarrage
exit 0

3. Test et Résultats
3.1 Test
• Sur PC2
tcpdump -i eth0 host 192.168.1.25 and 192.168.1.24 > /dev/pts/0
ping 192.168.1.25
• Sur PC1
tcpdump host 192.168.1.24
ping 192.168.1.24

3.2 Résultats
Nous voyons défiler des AH et des ESP, preuve que notre tunnel est fonctionnel.

CONCLUSION GENERALE
La sécurisation des échanges à travers internet est très importante surtout pour les
entreprises qui font dans le business électronique. Ainsi il a été question pour nous mettre en
place le protocole IPsec pour la sécurisation des échanges B2B. Ainsi il été mentionné que
plusieurs méthodes peuvent être mise en place selon le modèle de B2B choisi. Mais dans le
cadre de notre étude nous avons choisi une méthode universelle à tous ces modèles ; c’est – à
– dire qui peut être déployé aussi bien dans la modèle des relations transactionnelles que dans
le modèle d'intégration des processus et le modèle de partage des ressources.
IPSec est comme nous l'avons vu un assemblage de plusieurs protocoles et
mécanismes, ce qui le rend techniquement très complexe. IPSec est d'autre part en constante
évolution car il est soutenu par une grande population technique et scientifique. Il existe de
nombreux documents à son sujet ou sur des sujets annexes comme l'interopérabilité avec les
dispositifs de translation d'adresse.

ANNEXE A – SIGLES ET ACRONYME
3DESE
AFNOR
AH
CAM
CBC
DES
DH
DOI
ESP
FAQ
GSS-API
HMAC
IANA
ICMP
ICV
IDEA
IETF
IKE
IP
IPng
IPPCP
IPsec
IPv4
IPv6
ISAKMP
ISO
IV
MAC
MDn
OSI
PFS
RACE
RCn
RFC
RIPE
RIPE-MD
RSA
Triple-DES Encryption protocol
AssociationFrançaise de Normalisation
AuthenticationHeader
Code d'Authentification de Message
Cipher Block Chaining
Data Encryption Standard
DIFFIE-HELLMAN
Domain Of Interpretation
Encapsulating SecurityPayload
Frequently Asked Questions
Generic Security Service API
a MACmechanismbased on cryptographic Hashfunctions
Internet Assigned numbers Authority
Internet ControlMessage Protocol
Integrity CheckValue
InternationalData EncryptionAlgorithm
Internet Engineering TaskForce
Internet Key Exchange
Internet Protocol
IP new generation
IP Payload CompressionProtocol
IP security protocol
IP version 4
IP version 6
Internet Security Association andKey Management Protocol
InternationalStandardization Organization
Initialization Vector
Message Authentication Co*e
Message Diges* n
Open Systems Interconnection
Perfect Forward Secrecy
Research and development in AdvancedCommunication technologies in Europe
RIVEST'S Code n
Request ForComments
RACE Integrity Primitives Evaluation
RIPE Message Digest
RIVEST, SHAMIR,ADLEMAN

SA
SAD
SHA
SKEME
SKIP
SPD
SPI
SSH
SSL
TCP
TLS
TTL
UDP
VPN
Security Association
Security AssociationDatabase
Secure Hash Algorithm
a Versatile Secure Key Exchange MechanismforInternet
Simple Key management forInternet Protocols
Security Policy Database
Security ParameterIndex
Secure SHell
Secure Socket Layer
TransmissionControlProtocol
TransportLayerSecurity
Time To Live
UserDatagramProtocol
Virtual Private Network

ANNEXE B
 Bloc d’ISAKMP
La structure des paquets ISAKMP est constituée de chaînage de blocs.
Il existe 13 types de blocs possibles :
Nom Sigle
Security Association SA
Proposal P
Transform T
Key Exchange KE
Identification ID
Certificate CERT
Certificate Request CR
Hash HASH
Signature SIG
Nonce NONCE
Notification N
Delete D
Vendor ID VID
tableau 1. bloc de ISAKMP

Le bloc Security Association indique le contexte et la situation de l'échange.
Il comporte notamment le DOI qui précise si on est dans un échange de type ISAKMP
(première phase) ou dans l'étape plus spécifique d'IPsec (deuxième phase).
Ce bloc est composé d'un ou plusieurs blocs Proposal. Le bloc Proposal contient des
propositions sur les mécanismes de sécurité à fournir tel que les ESP avec les SPIs
correspondants. Ce bloc est composé d'un ou plusieurs blocs Transform.
Le bloc Transform contient les algorithmes et les attributs associés pour les mécanismes de
sécurité contenus dans les blocs Proposal.
Le bloc Key Exchange contient des données nécessaires à la génération de clés. Ces données
dépendent du contexte et du protocole d'échange de clés.
Le bloc Identification contient des données nécessaires à l'identification des entités présentes.
Ces données dépendent du contexte et du procédé d'identification. Plusieurs types sont
possibles : adresses IP (v4 ou v6), voire plage d'adresses IP, mais aussi FQDN (Fully
Qualified Domain Name) (exemple : xbox.ipv6.rennes.enst bretagne.fr) ou USER FQDN
(exemple : toto@toto.org). Son interprétation est différente en phase 1 ou en phase 2. En
phase 1 ce bloc sert à l'authentification, tandis que en phase 2 cela sert de traffic selector.
Le bloc Certificate contient un certificat ainsi que le type de certificat contenu. Ce certificat
peut être de différents types: PKCS#7, DNS signed KEY, X509 (signature key exchange ou
attribute) ou SPKI certificate.
Le bloc Certificate Request permet de réclamer un certificat à l'entité tiers (en précisant le
type de certificat voulu).
Le bloc Hash contient le résultat d'une fonction de hachage (cf bloc Transform) sur le
message ou sur un attribut.
Le bloc Signature contient le résultat d'un mécanisme de signature sur le message ou sur un
attribut. Cela est souvent utilisé pour faire de l'authentification.
Le bloc Nonce contient des valeurs aléatoires choisies par une des entités.
Le bloc Notification contient des messages d'erreur ou d'information. Son interprétation
dépend du contexte.
Le bloc Delete permet à une entité de préciser à son homologue qu'elle vient de supprimer
une SA.

Le bloc Vendor ID comme il est spécifié dans les RFC peut-être utilisé à des fins spécifiques
à une implémentation. Mais en général, il sert a négocier des extensions.
Notations standards définies dans la RFC 2409 :
Notation Signification
HDR Header ISAKMPD
HDR* tous les payloads sont chiffrés
SA
Payload de négociation, contient des
propositions pour l'initiateur
Nonce Payload Nonce
KE Payload d'échange de clé
IDii Payload d'identité Phase 1 initiateur
IDci Payload d'identité Phase 2 initiateur
IDir Payload d'identité Phase 1 répondeur
IDcr Payload d'identité Phase 2 répondeur
Auth Mécanisme d'authentification
HASH Payload du Hash
tableau 2. Notation standard des échanges

ANNEXE C - RÉPERTOIRE DE FIGURES
Figure 1 : Aspect du B2B
Figure 2: Modèle des relations transactionnelles
Figure 3: Attaque par usurpation
Figure 4: Envoi de message chiffré avec un algorithme symétrique
Figure 5 : envoi de message chiffré avec un algorithme asymétrique
Figure 6 : envoi de message avec une signature
Figure 7 : Le protocole IPSec dans le modèle OSI
Figure 8: IPSec Authentication Header (AH)
Figure 9: IPSec ESP format
Figure10 : Transformation AH en mode Transport.
Figure 11 : Transformation ESP en mode Transport.
Figure 12 : Exemple de communication sécurisé en mode tunnel
Figure 13 : Transformation AH en mode Tunnel.
Figure 14 : Transformation ESP en mode Tunnel.
Figure 15: le mode hybride Nesting
Figure 16: Organigramme d’IPsec
Figure 17: Schéma global d'IPsec
Figure 28: Tunnel IPsec entre un hôte et le serveur local

REFERENCES BIBLIOGRAPHIQUES
[Gislaine LABOURET] :
• IPSEC : PRÉSENTATION TECHNIQUE
• LA SECURITÉ RESEAU AVEC IPSEC (NETWORK SECURITY WITH IPSEC)
[Arnaud AUCHER] : MISE EN PLACE DE IPSEC
[Fiche de l'AWT]: Le Business to Business (B2B)
[EMONET Jean-Bruno] : Racoon : Installation et Configuration ; jbemonet@ext.cri74.org
MANUEL DE REFERENCE VMWARE
WEBOGRAPHIE
• www.System-Linux.htm
• www.farmeip.com/ipsec
• www.technet.microsoft.com/fr-fr/library/cc783420%28WS.10%29.aspx
• Commentcamarche.net
• www.forum.tt-hardware.com/cat-6--Software-OS-Reseaux.htm

Securisation des services B2B à l''aide d'IPSEC

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Securisation des services B2B à l''aide d'IPSEC

Ähnlich wie Securisation des services B2B à l''aide d'IPSEC (20)

Mehr von Olga Ambani

Mehr von Olga Ambani (8)

Securisation des services B2B à l''aide d'IPSEC