Chapitre III : Les protocoles IKEs

IPSec est une suite de protocoles IETF qui permet de sécuriser le protocole Internet
(IP). En particulier, IPSec fournit la confidentialité, l’intégrité des données, le
contrôle d'accès et l'authentification de la source des données. IPSec fournit la
sécurité de bout en bout, d'une la manière transparente à l'application sans avoir à
modifier chaque application séparément. La figure 3.1 illustre l’architecture du
protocole IPSec. Les propriétés de sécurité d'IPSec dépendent essentiellement des
protocoles d'échange des clés sous-jacents connus sous le nom du protocole IKE
(Internet Key Exchange). IKE est un protocole complexe.

Figure 3.1 L’architecture de l’IPSec (Zheng and Zhang, 2009)

3.1 Le protocole IKE version 1

Le protocole Internet Key Exchange (IKE) est la partie principale de la mise en

œuvre de l’IPSec. Il est utilisé pour négocier les clés secrètes entre les deux parties,
appelées par l'initiateur et le répondeur. La clé secrète est le résultat du protocole, et
il est utilisé pour créer les associations de sécurité (SA) qui définissent comment le
trafic entre les deux parties doit être protégé.

IKE est spécifié par la Société Internet RFC 2409 (Request for Comments) qui fait
référence au protocole ISAKMP (Internet Security Association and Key
Management Protocol) et une identification de DOI (Domain of interpretation) qui
est utilisé pour interpréter le contenu des messages ISAKMP (Allard et al., 2008;
Harkins and carrel, 1998 ; Perlma and Kaufman, 2001; Thomas and Elbirt, 2006; Su
and Chang, 2007).

Page 1
Chapitre III : Les protocoles IKEs

3.1.1 Fonctionnement du protocole

Le protocole IKE est conçu pour échanger les clés de chiffrement et de négocier les
associations de sécurité pour la communication sécurisée. Il fonctionne en deux
phases.

 La phase 1 consiste à établir une SA ISAKMP et dériver les secrets partagés

qui seront utilisés pour protéger les échanges de la phase 2;
 La phase 2 consiste à négocier la SA de l’IPSec (ou d'autres services de
sécurité) et génère la clé de chiffrement.

En outre, le protocole IKE définit trois modes de base d’échange : le mode principal
et le mode agressif sont utilisés dans la phase 1, et le mode rapide est utilisé dans la
phase 2 (Cheng, 2001; Zhu et al., 2010; Zhou, 2000).

3.1.1.1 Une association de sécurité (Security association, SA)

SA est un ensemble de politiques de sécurité utilisée pour protéger les informations.

Une SA ISAKMP établie dans la phase 1 est utilisée pour protéger les messages IKE
tandis qu'un SA IPSec établi dans la phase 2 est utilisé pour protéger des paquets IP.

Une SA ISAKMP comprend principalement les attributs de sécurité suivants :

 L’algorithme de hachage (hash algorithm) : indique l’algorithme de hachage

qui peut être utilisé par le serveur IKE (e.g. MD5, SHA, Tiger);
 L’algorithme de chiffrement (encryption algorithm) : indique l’algorithme de
chiffrement qui peut être utilisé par le serveur IKE (DES-CBC, IDEA-CBC,
Blowfish-CBC, RC5-R16-B64-CBC, 3DES-CBC, CAST-CBC);
 La méthode d’authentification (authentication method): indique la méthode
d’authentification qui peut être utilisée par le serveur IKE (pre-shared key,
digital signature, public key encryption);
 La fonction pseudo-aléatoire (prf Algorithm): indique la fonction de pseudo-
aléatoire qui peut être utilisée par le serveur IKE;
 La description du groupe pour dériver le secret partagé ;
 La durée de vie de SA.

Page 2
Chapitre III : Les protocoles IKEs

Les attributs de sécurité à négocier dans un SA IPSec sont différents de ceux dans
une SA ISAKMP (Cheng, 2001; Thomas and Elbirt, 2006).

 Le type de protocole IPSec (par exemple AH, ESP);

 L’algorithme de protocole IPSec (par exemple AH-HMAC-MD5, AH-
HMAC-SHA-1, ESP-DES, ESP-3DES);
 L’algorithme d'authentification utilisé avec ESP (par exemple HMAC-MD5,
HMAC-SHA-1);
 Le mode d'encapsulation (par exemple, le mode tunnel, le mode de transport);
 La description du groupe pour PFS (Perfect Forward Secrecy);
 La durée de vie SA (Cheng, 2001; Thomas and Elbirt, 2006).

3.1.1.2 Le mode principal (Main mode)

Dans le protocole mode principal, Il y a six étapes d'échange entre l'initiateur et le

répondeur. Les deux premières étapes négocient les paramètres de sécurité de la SA
ISAKMP; les deux secondes étapes échangent les valeurs publiques de Diffie-
Hellman; et les deux dernières étapes authentifient la SA ISAKMP et l'échange de
Diffie-Hellman.

RFC 2409 définit quatre méthodes d'authentification pour le protocole de mode

principal: la clé pré-partagée, la signature numérique, le chiffrement à clé publique et
le mode révisé de chiffrement à clé publique pour l'authentification. Nous discutons
tout d’abord les caractéristiques d’IKE qui sont indépendantes de toutes les méthodes
d'authentification et puis nous détaillons ces méthodes d'authentification (Cheng et
al., 2001; Thomas and Elbirt, 2006).

3.1.1.2.1. Les caractéristiques communes du protocole IKE

 Les composantes publiques DH générées par l'initiateur (noté gXi) et le répondeur

(noté gXr) seront mis dans les charges utiles d’échange de clé (KE).
 Le calcul des données d'authentification [AUTH] dépend de la méthode
d'authentification utilisée. Mais, quelle que soit la méthode d'authentification, les
données d'authentification sont toujours calculées dans les valeurs de hachage
d'information suivantes:

Page 3
Chapitre III : Les protocoles IKEs

 HASHI = prf(SKEYID, gXi ǁ gXr ǁcookie-Iǁcookie-RǁRǁSAǁIDI). HASHI est

envoyé par l’initiateur;
 HASHR = prf(SKEYID, gXr ǁ gXi ǁcookie-Rǁcookie-IǁRǁSAǁIDR). HASHR est
envoyé par le répondeur;
 Le symbole "ǁ" signifie la concaténation;
 « SA » dans HASHI et HASHR est la charge utile SA envoyée par
l'initiateur;
 « Prf » est une fonction pseudo-aléatoire habituellement mise en œuvre
par une clé-hash telle que HMAC; la transformation mathématique
exacte est déterminée lors de la négociation des paramètres;
 SKEYID est la clé de prf, Elle est différente pour chaque méthode
d'authentification.

La sortie finale de la première phase de protocole IKE est une SA ISAKMP avec
trois clés secrètes partagées exclusivement entre l'initiateur et le répondeur. Les trois
clés sont:

 SKEYIDd = prf(SKEYID, gXi Xr

ǁcookie-Iǁcookie-Rǁ0). La clé SKEYIDd est
utilisée pour dériver d'autres clés dans les phases I et II du protocole IKE;
 SKEYIDa = prf(SKEYID, SKEYIDd ǁgXi Xr
ǁcookie-Iǁcookie-Rǁ1). La clé
SKEYIDa est utilisée pour authentifier des messages de la deuxième phase de
protocole IKE;
 SKEYIDe = prf(SKEYID, SKEYIDa ǁgXi Xr
ǁcookie-Iǁcookie-Rǁ2). La clé
SKEYIDe est utilisée pour chiffrer les messages 5 et 6 en mode principal et
tous les messages de la Phase II du protocole IKE;
Le secret partagé DH, gXi Xr
, est la principale source d'entropie (aléatoire) pour
dériver ces trois clés.

IKE définit ses propres paramètres lors de la négociation des paramètres. Ces
paramètres incluent les méthodes d'authentification, les algorithmes de hachage, les
algorithmes de chiffrement, les fonctions pseudo-aléatoires, et les groupes
algébriques Diffie-Hellman.

Dans les sections suivantes, nous discutons les quatre méthodes d'authentification.
Parmi ces méthodes, on trouve la méthode de clé pré-partagée qui représente la

Page 4
Chapitre III : Les protocoles IKEs

forme de base. Les trois autres peuvent être considérées comme des variantes de la
méthode clé pré-partagée (Cheng, 2001; Thomas and Elbirt, 2006).

3.1.1.2.2. Le protocole IKE utilisant une clé pré-partagé

La figure 3.2 représente le mode principal du protocole IKE utilisant une clé pré-
partagée. Une clé secrète doit être partagée exclusivement entre l'initiateur et le
répondeur avant que la négociation IKE ne s’effectue. AUTH sont remplacés par
HASHI et HashR. La clé SKEYID est dérivée de la clé pré-partagée (Cheng, 2001):

SKEYID = prf (preshared-key, NONCEIǁNONCER)

Figure 3.2 Le mode principal de protocole IKE utilisant une clé pré-partagé (Cheng,
2001)
Dans le protocole ci-dessus, HDR est un en-tête ISAKMP qui traite chaque message
IKE. HDR* indique que toutes les charges utiles qui suivent le HDR sont cryptés.
SAproposal et SAchoice sont les charges de l'association de sécurité. NonceI et NonceR
sont des charges utiles de nonce. IDI et IDR sont des charges utiles d'identification
ISAKMP. (Les indices I et R dans ces charges représentent respectivement
l'initiateur et le répondeur,). Les authentificateurs HASHI et HASHR sont générés
par l'initiateur et le répondeur, respectivement (Cheng, 2001).

Page 5
Chapitre III : Les protocoles IKEs

3.1.1.2.3. IKE utilisant la signature à clé public

La figure 3.3 illustre le mode principal du protocole IKE utilisant une signature à clé
publique. AUTH sont remplacés par les signatures de l'initiateur et du répondeur, le
SIGI et le SIGR sont calculés sur HASHI et HASHR. CERTI et CERTR sont les
certificats des clés publiques de l'initiateur et du répondeur. Les certificats sont
placés à l'intérieur des charges utiles CERTIFICAT ISAKMP et ils peuvent être
utilisés pour vérifier les signatures. L'envoi des certificats est facultatif. Si aucun
certificat n’est envoyé, alors les deux parties doivent acquérir un autre certificat à
travers d’autre canal, habituellement un PKIX. Les certificats doivent être vérifiés
avant d'être utilisés pour vérifier les signatures. La clé SKEYID est dérivée à partir
des nonces comme suit:

SKEYID = prf ( NONCEI ǁNONCER,gXiXr)

Figure 3.3 IKE utilisant une signature à clé public (Cheng, 2001)
La clé SKEYID est fraiche parce qu’elle dépend des paramètres générés
aléatoirement, mais cette clé ne peut être utilisée pour l'authentification, car ni les
nonces ni le secret de DH, gXiXr, sont cryptographiquement liés à l'identité de
l'initiateur ou du répondeur. L'authentification est assurée par les signatures à clé
publique (Cheng, 2001).

Page 6
Chapitre III : Les protocoles IKEs

3.1.1.2.4. IKE utilisant le cryptage à clé publique

Figure 3.4 représente le mode principal du protocole IKE utilisant le cryptage à clé
publique. PKI et PKR sont les clés publiques de l'initiateur et du répondeur. Notons
que les nonces sont chiffrés avec la clé publique du destinataire prévu. Puisque seul
le titulaire de la clé privée correspondante peut déchiffrer un nonce chiffré, les
nonces deviennent des secrètes partagées entre l'initiateur et le répondeur. L'idée est
d'utiliser les deux nonces pour remplacer une clé pré-partagée avec un avantage
supplémentaire que les nonces sont éphémères et non des secrets partagés à long
terme. La clé SKEYID est dérivée à partir des nonces:

SKEYID = prf (hash (NONCEIǁNONCER), cookie-Iǁcookie-R)

Figure 3.4 IKE utilisant le cryptage à clé publique (Cheng, 2001)

Où "hash" est un algorithme de hachage déterminé lors de la négociation des

paramètres. Les nonces sont des secrets partagés, la clé SKEYID est aussi un secret
partagé; HASHI et HASHR peuvent être utilisés directement pour l'authentification
(Cheng, 2001).

Page 7
Chapitre III : Les protocoles IKEs

3.1.1.2.5. IKE utilisant le chiffrement à clé publique révisée

La figure 3.5 représente le mode principal du protocole IKE utilisant le cryptage à clé
publique révisée. La clé SKEYID est le même que celui d’IKE utilisant le cryptage à
clé publique. IKE utilisant le chiffrement à clé publique révisée corrige deux défauts
d’IKE, utilisant le cryptage à clé publique.
Premièrement, le nombre total d'opérations de chiffrement à clé publique est réduit
de quatre à deux. Les nonces sont toujours cryptés avec les clés publiques. Deux clés
de chiffrement symétrique, KeI et KeR, sont dérivées, elles sont utilisées pour crypter
les paramètres d’échange entre l’initiateur et le répondeur. L'algorithme de
chiffrement à clé symétrique est déterminé au cours de la négociation des paramètres
(Cheng, 2001).

KeI= prf (NONCEI, cookie-I)

KeR = prf (NONCER, cookie-R)

Figure 3.5 IKE utilisant le chiffrement à clé publique révisée (Cheng, 2001)

Deuxièmement, l'initiateur est autorisé à envoyer son certificat de clé publique

cryptée au répondeur de sorte que celui-ci peut utiliser la clé publique à l'intérieur du

Page 8
Chapitre III : Les protocoles IKEs

certificat pour crypter NONCER. Le certificat peut être chiffré vu que le cryptage à
clé symétrique est utilisé afin que la taille du certificat ne pose pas de problème.

3.1.1.3 Le mode agressif

La figure 3.6 représente le mode agressif du protocole IKE utilisant les différentes
méthodes d'authentification. Les caractéristiques de ce mode sont :

Figure 3.6 Le protocole IKE en mode agressif (Cheng, 2001)

Page 9
Chapitre III : Les protocoles IKEs

 Les identités ne sont pas cryptées, sauf dans la méthode de chiffrement à clé
publique ou révisée;

3.1.1.4 Le mode rapide

Comme son nom l'indique, le mode rapide est proposé pour être rapide et efficace.
Une négociation de mode rapide se compose de trois messages et il peut se conduire
sans l’utilisation de toutes les opérations de cryptographie à clé publique.

Le mode rapide fournit la possibilité d'utiliser des techniques D-H, de sorte que gXi et
gXr illustrés dans la figure suivante soient facultatifs. En outre, les identités IDUi et
IDUr sont facultatives; si les identités ne sont pas envoyées, il suppose que les
identités non envoyées sont les mêmes que l'IDI et IDR dans le SA ISAKMP. De
plus, si l'initiateur envoie gXi ou (IDUi , IDUr) dans le premier message, le répondeur
doit envoyer gXr (IDUi et IDUr) dans le second message pour continuer la négociation.

Dans la figure 3.7, le symbole « * » après les en-têtes des messages indiquent que les
corps de ces messages sont cryptés par la clé SKEYIDe et l’algorithme de
chiffrement utilisé se trouve dans SA ISAKMP. HASH1, HASH2 et HASH3
authentifient les messages correspondants. Ils sont calculés par la clé SKEYIDa et la
fonction pseudo-aléatoire dans la SA ISAKMP:

HASH1 = prf (SKEYIDa, message-IDǁSAǁNONCEI [ǁgXi] [ǁIDUiǁIDUr])

HASH2 = prf (SKEYIDa, message-IDǁSAǁNONCER [ǁgXr] [ǁIDUiǁIDUr])

HASH3 = prf(SKEYIDa, 0ǁmessage-IDǁNONCEIǁNONCER)

Les informations entre crochets ([]) sont facultatives lors du calcul des valeurs de
hachage; ils sont utilisés si et seulement si les messages contiennent ses informations.

Page
10
Chapitre III : Les protocoles IKEs

Figure 3.7 Le mode rapide du protocole IKE (Cheng, 2001)

Les propositions contenues dans la charge utile SA sont pour la sécurité du protocole
IPSec. Les paramètres de sécurité de l’IPSec sont générés pour chaque protocole de
sécurité et ils sont choisis par le répondeur. La clé du protocole, appelé KEYMAT,
est dérivée comme suit (Cheng, 2001):

KEYMAT = prf(SKEYIDd, [gXiXr ]protocolǁSPIǁNONCEIǁNONCER)

3.2 Le protocole IKE version 2

IKE est le protocole utilisé pour établir une association de sécurité (SA) dans la suite
du protocole IPSec. IKEv2 est la seconde version du protocole IKE. L’IETF a délivré
IKEv2 (la nouvelle version de protocole IKE) en décembre 2005 dans RFC 4306
(Kaufman, 2005; Kaufman et al., 2010).

3.2.1 Le fonctionnement d’IKEv2

IKEv2 conserve le cadre du protocole IKEv1 et son processus d'échange des clés est
également divisé en deux étapes (Haddad and Mirmohamadi, 2005; Lu et al., 2008):

 L’étape 1: Echange initiale (The initial exchange): est utilisé pour construire
la SA IKE (IKE Security Association) et la SA CHILD (Security Association
Enfant) entre les entités communicantes.
 L’étape 2: CREATE-CHILD-SA (builds Child Security Association) de
l'échange: est utilisé lorsqu’on a besoin de plus de SA CHILD pour protéger
les données d'application ou une nouvelle SA IKE.

Page
11
Chapitre III : Les protocoles IKEs

IKEv2 utilise les paramètres suivants:

 HDR: l’en-tête de message;
 SAx: l’association de sécurité envoyée par x (l’initiateur ou répondeur);
 KEx: les valeurs publiques de Diffie-Hellman (DH) envoyées par x
(l’initiateur ou répondeur);
 Nx : nombres pseudo-aléatoires envoyés par x;
 SK {données}: fournit le chiffrement et l’intégrité des données;
 ID: les informations d'identité;
 AUTH: les informations d’authentification de l’identité;
 CERT: certificat;
 CERTREQ: certificat des informations de demande;
 [CERT]: est une charge utile de CERT et elle est facultative.

3.2.1.1 L’échange initiale « initial exchange »

Le premier échange dans l’IKEv2 correspond à la première étape dans IKEv1; son
processus d'échange est effectué par quatre messages, comme il est représenté dans la
figure suivante.

Figure 3. 8 L’échange initiale « initial exchange» (Lu et al., 2008)

Dans le premier et le deuxième message, l’initiateur et le répondeur négocient les
paramètres confidentiels (SAi et SAr), ils échangent les valeurs publiques de D-H
(KEi et KEr) et les nombres pseudo-aléatoires (Ni, Nr). Après la négociation, les

Page
12
Chapitre III : Les protocoles IKEs

deux entités communicantes génèrent leurs propres clés, une clé de chiffrement SKei
pour l’initiateur et SKer pour le répondeur ainsi qu’une clé d’authentification SKai
pour l’initiateur et SKar pour le répondeur.

Dans le troisième et quantième message, les deux entités communicantes échangent

AUTH mutuellement, et ils négocient les paramètres de la SA CHILD
simultanément. Si l'authentification de l'identité est passée, la SA IKE et la SA
CHILD pourraient être construites entre les entités.

3.2.1.2 L’échange CREATE-CHILD-SA

L’échange CREATE-CHILD-SA correspond à la deuxième étape dans IKEv1 qui est

utilisé pour construire un SA CHILD sous la protection de la SA IKE. L’échange
CREATE-CHILD-SA est utilisé dans SA IKE et la nouvelle négociation SA CHILD.
Le processus d'échange est composé uniquement de deux messages, comme le
représente la Figure 3.9.

Figure 3.9 L’échange CREATE-CHILD-SA (Lu et al., 2008)

Dans cette étape, les deux entités de communication doivent négocier les
caractéristiques de cryptologie de SA CHILD. Les charges utiles (SAi et SAr) sont
utilisées pour négocier les algorithmes de la SA CHILD. Si les deux entités
communicantes veulent vérifier la propriété « perfect forward protection » de la SA
CHILD, elles peuvent utiliser KEi, KEr pour effectuer un nouvel échange Diffie-
Hellman.

3.2.1.3 L'échange de l'information

Les deux parties de la communication ont besoin de transmettre des messages de

contrôle pendant la période de négociation des clés. Ces messages ont pour but
d’avertir des erreurs ou des remarques des points importants de l'autre partie, et ces

Page
13
Chapitre III : Les protocoles IKEs

travaux peuvent être complétés par l'échange d'informations. Le processus d'échange

d'information est représenté dans la figure 3.10.

Figure 3.10 L'échange de l'information (Lu et al., 2008)

L'échange d'informations peut contenir plusieurs types d’information telle que :
 Les charges utiles de notification (N);
 Les charges utiles de suppression (D);
 Les charges utiles de configuration (P) ou sans charge utile, par exemple, une
partie de communication peut transmettre un message sans charge utile
d'échange d'informations pour détecter si l'autre partie est encore dans un état
actif.

Page
14