Sujets Exercices Securite PDF

Sujets des exercices dirigs
Scurit et Rseaux
UE RSX 112
2007-2008
G. Florin, S. Natkin
CNAM- Anne 2007/2008
-1-
Exercices UE Scurit et Rseaux
Table des matires
CHAPITRE 1 : FONCTIONS CRYPTOGRAPHIQUES .................................................................................................... 3

Exercice 1
Exercice 2
Exercice 3
Exercice 4
Exercice 5
Exercice 6
Exercice 7
Exercice 8
: Chiffres cls secrtes; cryptogramme 1............................................................................................ 3

: Fonctionnement du chiffre cl publique RSA................................................................................. 5
: Dcryptage du RSA................................................................................................................................. 6
: Signatures RSA........................................................................................................................................ 7
: Etude du jeu de pile ou face en rseau................................................................................................ 8
: Partage d'un secret...............................................................................................................................12
CHAPITRE 2: PROTOCOLES DE SECURITE.................................................................................................................13

Exercice 9 : Problme de notarisation....................................................................................................................13
Exercice 10 : Changement priodique de cls en cryptographie cls publiques.........................................15
Exercice 11 : Protocoles d'changes de cls scuriss.........................................................................................17
Exercice 12 : Construction dun systme de paiement par chques support lectronique ........................20
Exercice 13 : Protocole de micro-paiement sur Internet......................................................................................22
Exercice 14 : Proprits des certificats....................................................................................................................25
CHAPITRE 3 : NORMES ET IMPLANTATIONS INDUSTRIELLES ...........................................................................26
Exercice 15 : Kerberos................................................................................................................................................26
Exercice 16 : Authentification daccs au rseau Internet : solution des protocoles PAP et CHAP...........29
Exercice 17 : Authentification daccs au rseau Internet : le protocole RADIUS .........................................31
Exercice 18 : Scurisation des rseaux sans fils WIFI : les normes WEP...........................................................35
Exercice 19 : Architecture de scurit IPSEC ........................................................................................................39
Exercice 20 : IPSEC : Le protocole dchanges de cls IKE/OAKLEY secret pr partag.........................43
Exercice 21 : Scurisation des communications en Internet avec SSL-TLS......................................................48
Exercice 22 : Commerce lectronique sur Internet (SET "Secure Electronic Transactions")......................51
Exercice 23 : Authentification des usagers et autorisation des requtes dans le WEB..................................55
Exercice 24 : Scurisation du courrier avec S/MIME...........................................................................................58
Exercice 25 : Scurisation du DNS : les normes DNSSEC-1 ...............................................................................59
Exercice 26 : Scurisation DNS : Difficults en DNSSEC-1, les normes DNSSEC-2 ......................................63
Exercice 27 : DNS et Messagerie Internet SMTP, lutte contre le courrier non sollicit................................66
Exercice 28 : Politiques de scurit : pare-feux et filtrage des paquets...........................................................68
Exercice 29 : Environnement de scurit SSH 'Secure Shell'..............................................................................70
-2-
CHAPITRE 1 : FONCTIONS
CRYPTOGRAPHIQUES
Exercice 1 : Chiffres cls secrtes; cryptogramme 1
1) Cassez le cryptogramme suivant qui utilise une substitution monoalphabtique. Le texte en
clair ne contient que des lettres. Cest un extrait dune fable de La Fontaine.
gcxobwryv ib ogx tb syiib
ypsyxg ib ogx tbv qmgzev
t cpb wgqrp wrox qysyib
g tbv obiybwv t roxrigpv
vco cp xgeyv tb xcojcyb
ib qrcsbox vb xorcsg zyv
ab igyvvb g ebpvbo ig syb
jcb wyobpx qbv tbcd gzyv
ib obfgi wcx wrox mrppbxb
oybp pb zgpjjcgyx gc wbvxyp
2) En supposant que vous disposiez dun histogramme de la rpartition des lettres et des
digrammes dans la langue franaise ainsi quune fonction Nombre_fautes(texte) qui donne (selon un
correcteur orthographique) el pourcentage de mots dans un texte qui ont au moins une faute
dorthographe, imaginez un algorithme de cryptanalyse de ce type de crypto-systmes
-3-
Rpartition des lettres dans lexemple

et dans la langue franaise
lettre
h
k
l
n
u
a
d
f
m
e
j
z
q
s
t
w
r
i
c
p
o
v
x
y
g
b
Total
Exemple
pourcentage
0,0
0,0
0,0
0,0
0,0
0,5
0,5
0,5
1,0
1,5
2,0
2,0
2,5
3,0
3,4
3,9
4,4
5,9
6,4
6,4
7,4
7,9
7,9
8,4
8,9
15,8
100,0
Nb lettre
0
0
0
0
0
1
1
1
2
3
4
4
5
6
7
8
9
12
13
13
15
16
16
17
18
32
203
-4-
lettre
k
w
z
j
y
x
h
b
q
f
g
v
m
p
c
d
o
u
l
r
i
t
n
a
s
e
Franais
pourcentage
0,0
0,1
0,1
0,2
0,3
0,5
0,7
0,8
0,8
1,1
1,2
1,3
2,3
2,9
3,4
4,3
5,2
5,2
6,0
6,4
7,2
7,4
7,7
8,1
8,9
17,7
99,9

Casser le cryptogramme suivant qui utilise une transposition par colonnes. Le texte en clair
est issu d'un ouvrage classique sur l'informatique; on peut donc supposer que le mot "ordinateur" y
figure. Le texte ne contient que des lettres (sans espace). Il est dcoup en blocs de 5 caractres
pour plus de lisibilit.
ntsus ueire eibps etsio ootuu rpmrn eaicq iunps cnlog
euern lndur raose xnntu dnaeo eseue clton nretd trels

1) Chiffrer avec le chiffre de Vigenre le texte suivant "textesecretadecoder" en utilisant
comme clef le mot crypto.
2) Pour le mme texte en clair on obtient le texte chiffr suivant "brqksmzcspxiqxtcxzr" .Quel
est la clef ?
3) Supposons que vous disposiez dun texte en clair et une partie du mme texte chiffr,
mais que ce texte soit plus court que la clef (par exemple vous ne connaissez que brq dans lexemple
prcdent). Quelle information cela vous apporte til ? Imaginez des stratgies de cryptanalyse dans
le cas ou la clef est un mot franais et dans le cas ou cest une suite alatoire de lettres. Comment
distinguer priori ces deux cas ?
Exercice 4 : Fonctionnement du chiffre cl publique RSA

On rappelle les principes du chiffre RSA ( Rivest, Shamir, Adleman, 1978) qui a aussi t
appel chiffre du MIT ('Massachussetts Institute of Technology') ou se trouvaient les crateurs du
chiffre.
1- Choisir deux nombres p et q premiers et grands (p, q > 10100)
2 - Calculer n: = p * q z: = (p - 1) * (q - 1)
3 - Soit d un nombre premier avec z (z et d sont premiers entre eux).
4 - Dterminer un entier e tel que e * d = 1 mod z .
Soit A un message binaire. Dcouper A en blocs de k bits tel que k soit le plus grand entier
tel que 2k < n.
Soit P un bloc de k bits, le codage de P est donn par :
C = E(P) = Pe (mod n)
Le dchiffrement d'un message chiffr C est donn par:
P= D(C) = Cd (mod n)
-5-
On donne les valeurs numriques suivantes : p = 3, q = 11 (trop petites en pratique, mais

traitable en exercice).
1) Calculer les valeurs des nombres d et e vrifiant les conditions de l'algorithme du MlT. Pour avoir
un couple unique on prend la plus petite valeur possible de d et pour cette valeur la plus petite valeur
possible de e.
Quelle est la cl publique et quelle est la cl secrte?
2) Soit le message de 3 chiffres 1, 6, 15 soit par blocs de 5 bits la configuration de bits suivante:
00001 00110 01111
Coder ce message en utilisant les paramtres de chiffrement RSA prcdents.
3) On reoit le message suivant par blocs de 6 bits (4 , 14 , 24):
000100 001110 011000
Donner la valeur initiale du message (texte en clair), en prenant les mmes valeurs pour d, e et k qu'
la question 2.
4) Pourquoi ne peut-on prendre p et q petits ?
Que se passe-t-il lorsque p et q sont de l'ordre de l0 l0 ?
Exercice 5 : Dcryptage du RSA

On constate quun utilisateur du chiffre RSA a comme cl publique le couple (7,143) soient
e = 7 et n = 143. Sachant que ces valeurs sont trop petites pour confrer la mondre scurit au
chiffre RSA, on veut casser ce chiffre, c'est--dire retrouver la cl secrte partir de la
connaissance de la cl publique.
1) On doit tout dabord retrouver z = (n) = (p-1)(q-1) la fonction dEuler de lentier n. Pourquoi ?
2) Quelle est la valeur numrique de z pour les valeurs numriques prises en exemple dans ce
problme?
3) Dfinissez une mthode pour retrouver la cl prive d partir de e et de z = (n) ?
4) Quelle est la valeur numrique de d ?
5) Pourquoi a t'on pu casser facilement ce chiffre ?
-6-
Exercice 6 : Signatures RSA

Un attaquant souhaiterait dsorganiser le fonctionnement dune communication par messages
protgs par des signatures RSA (des signatures qui utilisent comme algorithme de chiffrement cl
publique le chiffre RSA).
1) Rappelez les principes gnraux du chiffre RSA ?
2) Rappelez les objectifs dune signature (quelles sont les proprits attendues dune signature
numrique pour un document ou un message dans lidal) ?
3) Rappelez les principes de fonctionnement de la signature RSA ?
4) En observant le fonctionnement du chiffre RSA, lattaquant conjecture que le produit des chiffres
RSA de deux messages M1 et M2 est le chiffre du produit des deux messages (on utilise comme
produit la multiplication des entiers modulo n). Autrement dit RSA(M1 * M2) = RSA(M1) *
RSA(M2). Montrez que cette proprit est effectivement vraie.
5) A partir de la remarque prcdente, lattaquant se dit que sil peut couter deux messages
correctement signs par leur metteur au moyen dune signature RSA, il peut gnrer un message
produit des deux messages couts auquel il adjoindra une signature qui sera le produit des
signatures des deux messages couts. Est-ce que l'attaquant russira dsorganiser les
communications en faisant accepter le message qu'il a forg (le destinataire acceptera le message en
le considrant comme correctement sign) ? (2 points)
-7-
Exercice 7 : Etude du jeu de pile ou face en rseau

Alice et Bernard communiquent distance au moyen dun rseau (par messages
asynchrones ou tout autre mode de communications par messagerie textuelle, par tlphone etc ).
Ayant un diffrent relativement une dcision, ils veulent sen remettre au hasard pour la dcision
finale. Pour cela ils doivent construire un protocole par change de messages asynchrones qui ralise
une dcision alatoire de mme nature que celle de pile ou face lorsque deux personnes sont en
prsence.
La dcision pile ou face comporte traditionnellement le choix au hasard par lun des
participants du cot pile ou face dune pice de monnaie et le lancement de la pice par lautre
participant. Pour remplacer le lancement de la pice de monnaie Alice et Bernard dcident de tirer
un entier au hasard (not n non nul). Selon que l'entier n est pair ou impair, on considre que la pice
est retombe cot pile ou cot face. Pour remplacer le choix au hasard entre pair et impair, Alice et
Bernard dcident d'utiliser le tirage alatoire d'une variable entire binaire (note p).
Alice et Bernard se mfient mutuellement lun de lautre et souhaitent dterminer un
protocole ayant un bon niveau de scurit c'est--dire que lun comme lautre ne doit pas pouvoir
tricher et doit pouvoir vrifier que lautre ne triche pas. Le protocole dfinir nutilisera pas de tiers
de confiance qui assurerait pendant le droulement un rle de coordination ou darbitrage. Le
protocole ne peut pas non plus disposer dun tat global commun qui serait ralis par laccs une
mmoire commune partage.
Une version de base du protocole pourrait tre la suivante. Dans cette version, dans une
premire phase, Alice est la participante qui tire lentier au hasard et Bernard le participant qui
choisit pair ou impair. Dans la seconde phase, Alice et Bernard changent en clair leur valeur. Dans
la troisime phase les deux partenaires dcident qui est gagnant.
Alice
Bernard
Choisir n
au hasard
(entier)
Choisir p
au hasard
(pair ou
impair)
Envoyer n en clair
Envoyer p en clair
Dcision finale :
Alice gagne si
Bernard na pas
donn la bonne
parit.
Dcision finale
Bernard gagne sil
a donn la bonne
parit.
1) Etudiez le protocole prcdent en scurit. Quelles sont les fraudes possibles de la part de Alice
ou Bernard ?
2) On cherche une solution au jeu de pile ou face en rseau sans utiliser de fonctions
cryptographiques. On doit donc transmettre des valeurs alatoires en clair par messages
-8-
asynchrones. Peut-on construire un protocole scuritaire (par exemple rendre scuritaire le

protocole prcdent)? Pourquoi est-ce difficile (cherchez construire une solution et montrez ses
difficults) ?
Pour garantir la scurit de la dcision finale, Alice et Bernard tudient la possibilit dutiliser
des fonctions cryptographiques. On passe une solution de base avec trois messages. Au lieu
denvoyer n directement dans son premier message, Alice va envoyer f(n) ou f est une fonction
cryptographique applique n. Une ide assez naturelle consiste utiliser pour f une fonction de
chiffrement symtrique cl secrte k (f est par exemple le DES ou l'AES). Alice transmet donc
dans son premier message fk(n) ou k est une cl secrte choisie par Alice. Dans cette premire
solution cryptographique, Bernard transmet ensuite p en clair. Dans le troisime message Alice
transmet Bernard n et k en clair.
Alice
Bernard
Choisir n au hasard
(entier).
Choisir k cl secrte
Choisir p
au hasard
(pair ou
impair)
Envoyer fk(n) (n en chiffre)
Envoyer p en clair
Envoyer n et k en clair
Dcision finale :
Alice gagne si
Bernard na pas
donn la bonne
parit.
Dcision finale
Bernard gagne sil
a donn la bonne
parit.
3) Le protocole obtenu est il scuritaire (selon vous est ce que Alice ou Bernard en utilisant ce
protocole avec un chiffre cl secrte peuvent tricher) ?
4) Dans les mmes conditions qu' la question prcdente, utilise maintenant une fonction f de
chiffrement asymtrique (typiquement le chiffre RSA). Alice dtermine au dbut du protocole un
couple cl publique/cl prive. Pour envoyer n chiffr au dbut sous la forme fk(n), Alice doit-elle
chiffrer avec la cl prive ou avec la cl publique qu'elle vient de dterminer. Alice termine en
envoyant comme prcdemment les moyens de dchiffrement de n (k,n). Le protocole obtenu est il
scuritaire (selon vous est ce qu'en utilisant ce protocole avec un chiffre cl publique Alice ou
Bernard peuvent tricher)? (2 points)
Dans une approche cls publiques avec le chiffre RSA, Alice doit donc gnrer pour ellemme un couple cl publique (note (e,N)), cl prive (note (d,N)) avec N=PQ produit de deux
-9-
nombres premiers. Cependant, dans l'optique d'une approche cl publique il est assez naturel que
Alice aprs avoir choisi son couple cl publique, cl prive dvoile Bernard sa cl publique. On va
donc examiner maintenant une nouvelle solution dans laquelle Alice commence le protocole en
gnrant un couple cl publique/cl prive. Elle choisit l'entier n alatoire. Dans son premier message
elle communique Bernard la valeur de la cl publique (e, N) en clair et le chiffre RSA de n au
moyen de sa cl publique. A la fin du protocole Alice dvoile Bernard sa cl prive Pour simplifier
la vrification Alice dvoile aussi les deux entiers premiers utiliss P et Q. Bernard a le mme
comportement que prcdemment en choisissant p et en le transmettant en clair.
Alice
Bernard
Choisir des cls RSA

publique (e,N) et prive
(d,N)
Choisir n au hasard
(entier)
Envoyer (e,N) en clair, RSA(e,N)(n)
soit n en chiffre RSA
Choisir p
au hasard
(pair ou
impair)
Envoyer p en clair
Envoyer n , la cl prive (d,N) en clair

Envoyer P, Q tel que N=PQ en clair
Dcision finale :
Alice gagne si
Bernard na pas
donn la bonne
parit.
Dcision finale
Bernard gagne sil
a donn la bonne
parit.
5) Le protocole obtenu est il scuritaire (selon vous est ce que Alice ou Bernard en utilisant ce
protocole avec le chiffre cl publique RSA peuvent tricher)?
Aprs avoir cherch utiliser un chiffre on cherche maintenant utiliser une fonction de
hachage cryptographique H (comme le MD5 ou le SHA-1). Une solution de base avec fonction de
hachage est la suivante :
-10-
Alice
Bernard
Choisir n
au hasard
(entier)
Choisir p
au hasard
(pair ou
impair)
Envoyer H(n)
Envoyer p en clair
Envoyer n en clair
Dcision finale :
Alice gagne si
Bernard na pas
donn la bonne
parit.
Dcision finale
Bernard gagne sil
a donn la bonne
parit.
6) Rappelez la dfinition dune fonction de hachage sens unique. Que se passe til (du point de vue
de la scurit), si la fonction H nest pas sens unique ?
7) Rappelez la dfinition dune fonction de hachage collisions faibles difficiles. Que se passe til
(pour la scurit) si la fonction H nest pas collisions faibles difficiles ?
8) Rappelez la dfinition dune fonction de hachage collisions fortes difficiles. Que se passe til
(pour la scurit) si la fonction H nest pas collisions fortes difficiles ?
9) Le protocole sous lhypothse que H est sens unique et collisions fortes difficiles est il
scuritaire (Alice ou Bernard peuvent ils tricher) ?
10) Alice et Bernard souhaitent dfinir un protocole, qui puisse tre en cas de litige, soumis un
juge. Pour cela, Alice et Bernard se proposent de modifier le protocole qui vient d'tre dcrit (avec
fonction de hachage) ou dajouter lutilisation dautres fonctions cryptographiques dans les
messages. Proposez des modifications pour une version du protocole qui puisse tre soumise
larbitrage en non rpudiation dun juge (justifiez les mcanismes introduits permettant de dfendre le
point de vue que seuls Alice ou Bernard peuvent tre l'auteur de leurs messages et que les messages
mis ont effectivement t reus) ?
11) La mthode de Diffie-Hellman est rpute permettre un change de cl secrte alatoire entre
deux entits qui ne peuvent communiquer que par un rseau non scuris. L'objectif est donc que la
cl ne circule jamais en clair sur le rseau et qu'elle soit alatoire. On peut donc essayer de rsoudre
le problme pos par la scurisation du jeu de pile ou face en rseau, en utilisant la solution de
Diffie-Hellmann pour partager les deux variables alatoires ncessaires au jeu de pile ou face. Peuton construire une solution au jeu de pile ou face empchant Alice ou Bernard de tricher et qui serait
bas sur l'utilisation du protocole de Diffie et Hellmann? (2 points)
-11-
Exercice 8 : Partage d'un secret

Un conseil d'administration prend ses dcisions au moyen de votes lectroniques. Il
comporte un prsident dont la voix compte double et trois membres dont la voix est simple (nots 1,
2, 3). Une dcision n'est prise que si un vote rassemble au moins 3 voix. Les votes sont acquis
lorsque le titulaire prsente selon son rang soit une soit deux parts d'un secret.
- Les services de scurit ont fait implanter la mthode de Shamir avec une arithmtique modulo 31.
- Le secret partag est tir alatoirement la valeur 7.
- Les coefficients alatoires du polynme retenu sont 1, 9, et le terme constant est 7.
- On dduit les parts de secret du prsident des valeurs aux points x=1; x=2.
- On dduit des parts du secret des membres 1, 2, 3 des valeurs du polynme pour 3, 4 , 5.
1) Quelles sont les valeurs des parts?
2) On suppose que le prsident et le membre 1 sont d'accords. Montrez qu'ils peuvent emporter le
vote.
-12-
CHAPITRE 2: PROTOCOLES DE SECURITE

Exercice 9 : Problme de notarisation
On souhaite raliser un service ayant pour objectif la non rpudiation de transactions entre
deux sites A et B qui fonctionnent en mode A client et B serveur (service de notarisation). Le notaire
est not N.
On note b la clef de chiffrement (clef publique dans les crypto systmes asymtriques) de
Bob et B sa clef de dchiffrement (clef prive dans les crypto systmes asymtriques).
Les tapes du protocole sont les suivantes :
1. Alice chiffre et signe M avec sa clef a et lenvoie au notaire.
2. Le notaire dchiffre le message, vrifie la signature qui garantit que le demandeur du service est
bien Alice. Il attribue lenvoi du message un numro de squence envoi(M), date cet envoi
te(M), enregistre envoi(M), te(M), M dans un fichier intgre. Il constitue un message contenant
envoi(M) sign avec la clef dAlice et (envoi(M), te(M), M) chiffr avec sa clef.
3. Alice peut alors contrler la signature qui authentifie le notaire (qui est le seul avec Alice
connatre la clef dAlice) et constitue une rfrence de la preuve denvoi. Par contre Alice ne
peut pas dchiffrer la seconde partie du message. Elle lenvoie Bob.
4. Bob ne peut pas, lui non plus, lire le message. Il le renvoie au notaire
5. Le notaire dchiffre le message avec sa clef. Il vrifie que le numro denvoi est dans son fichier.
Il attribue la rception du message un numro de squence rception(M), date cette rception
tr(M), enregistre rception(M), tr(M), M dans le fichier intgre. Il constitue un message
contenant (envoi(M), te(M), rception(M),tr(m), M) sign et chiffr avec la clef de Bob. Il
transmet ce message Bob. Il envoi un message contenant rception(M) Alice.
6. Bob peut dchiffrer le message, contrler la signature qui authentifie le notaire. Il envoie un
accus de rception sign avec sa clef au notaire.
7. Le notaire enregistre la fin de la transaction.
1) Rappelez la dfinition du problme de non rpudiation.
2) Dcrivez par des diagrammes d'change de messages chaque tape en utilisant uniquement des
algorithmes de chiffrement symtriques; pour chaque tape, exprimez les proprits obtenues:
confidentialit, intgrit, non rpudiation, vis a vis de tous les participants (A, B, N, les autres entits
prsentes dans le rseau) qui sont ralises par chacune des six tapes.
3) Proposez pour chacune des tapes une solution cl publique qui atteigne exactement les
proprits prcdentes vis a vis des mmes intervenants. Expliquez de manire trs prcise
pourquoi votre solution assure les proprits recherches.
4) On suppose que l'usager client A dispose d'un dlai dmax pour signaler la perte de sa cl. Toute
perte non signale dans le dlai dmax ne peut-tre tenue charge contre l'usager. Toute perte non
signale aprs le dlai dmax entrane la responsabilit totale du client en cas de contestation.
-13-
Que pourrait faire le notaire pour que le serveur B et le notaire ne soient jamais pigs par
un client malveillant qui dclare la perte de sa cl aprs avoir donn un ordre et avant dmax. Dans
quelles applications une telle stratgie est elle utilisable? Dans quelles applications est-elle
inutilisable?
5) La solution utilise l'algorithme RSA. Si un utilisateur pour rpudier sa signature lectronique
conteste la scurit du protocole quels arguments peuvent tre opposs?
6) Le site B peut essayer de dnier avoir reu l'ordre (s'il ne lui convient pas) en n'mettant pas
l'acquittement final et en prtendant ensuite qu'il n'a jamais reu la transaction interprtable ou que
son calculateur est tomb en panne ce moment. Comment le notaire peut-il contrer cette attitude
(recherchez une solution dduite des pratiques bancaires courantes)?
-14-
Exercice 10 : Changement priodique de cls en cryptographie cls

publiques.
On tudie un protocole de transmission d'informations dvelopp pour scuriser une voie
point point (logiciel de communication Nicecom). Dans l'une des versions on utilise un algorithme
de cryptographie cls publiques comme le RSA.
Chaque utilisateur dispose donc au dpart d'un couple cl publique, cl prive pour un
algorithme cls publiques RSA:
Pour un utilisateur A: cl secrte DA et cl publique EA
Pour un utilisateur B: cl secrte DB et cl publique EB
Pour rendre excessivement difficiles les violations de scurit on dcide dans ce produit de
pratiquer un changement priodique des cls de faon automatise (par change de messages en
cours de dialogue).
En fait les cls vont donc tre modifies priodiquement de sorte que l'on utilisera pour un
site comme A une suite de couples de cls: (EA(0) = EA, DA(0) = DA ), puis (EA(1), DA(1)) ,
....., puis (EA(i), DA(i)) , (EA(i+1), DA(i+1)) ,....
A l'instant initial A utilise (EA(0), DA(0)) et B connat EA(0) et symtriquement. B utilise
(EB(0), DB(0)) et A connat EB(0).
On veut atteindre les objectifs suivants:
O1 : Authentification des correspondants.
Dans les exemples traits A est l'appelant et B l'appel.
O2 : Confidentialit des informations qui circulent sur le rseau.
O3 : Authentification de l'origine de tous les messages changs.
O4 : Limitation de la dure d'usage des cls par changement priodique.
Le logiciel considr utilise un protocole Px suivant entre les deux usagers A et B. Dans le
schma suivant on ne dcrit pas compltement le rle de tous les messages et l'utilisation des
variables changes (objet de questions du problme).
1) Quel type de problme permet de rsoudre le protocole Px (justifiez votre rponse en discutant
du fonctionnement du protocole Px en particulier du rle des nombres RA et RB)? Que pensez vous
de l'efficacit de ce protocole pour rsoudre ce problme en termes de scurit et de performances?
2) On prend le protocole Px comme base pour obtenir une version modifie Py permettant le
changement scuris des cls c'est dire le passage du couple (EA(i), DA(i)) (EA(i+1), DA(i+1))
et galement du couple (EB(i), DB(i)) (EB(i+1), DB(i+1)). On suppose que les sites disposent
d'algorithmes leur permettant de dterminer quand ils le souhaitent des couples cl publique, cl
prive comme (EA(i+1), DA(i+1)) pour l'algorithme RSA.
-15-
2.1) Proposez des modifications du protocole Px pour dfinir le protocole Py qui assurent le
changement scuris des cls.
A
Choisir un nombre
alatoire RA
Envoyer [RA]
RA
Recevoir [RA]
Choisir un nombre
alatoire RB
Envoyer [DB{EA(RA),RB}]
DB{EA(RA),RB}
Recevoir [DB{EA(RA),RB}]
Dcoder RA et RB
Envoyer [DA{EB(RB)}]
DA{EB(RB)}
Recevoir [DA{EB(RB)}]
Dcoder RB
2.2) Quelles cls change-t-on, quel moment, selon quel cryptage? Justifiez votre solution. On
rappelle que la scurit de l'algorithme RSA repose sur le fait que les cls prives doivent rester
confidentielles.
3) En quoi la technique de modification des cls applique rend t-elle extrmement difficile l'action
des pirates.
3.1) On examinera d'une part le problme de dcryptage par un pirate qui essaierait de casser le
code par analyse des messages changs.
3.2) On examinera ensuite le cas d'un pirate qui connatrait les cls initiales d'un utilisateur A ou B
par des moyens autres que le dcryptage (ngligence de l'utilisateur). Que se passe-t-il?
3.3) L'accs au calculateur de l'metteur ou du destinataire en session distance constitue une
possibilit d'attaque d'un tel protocole. Que doit faire un pirate qui a russi se connecter?
3.4) Quels sont les moyens matriels et logiciels qui protgent les systmes de ce type d'attaque?
4) 4.1) Quand on est en phase i (avec les couples des cls (EA(i), DA(i)) (EB(i), DB(i)) ) comment
sont assures la confidentialit et l'authentification des messages en mode RSA ?
4.2) Quel est l'inconvnient majeur de cette approche ?
4.3) Comment pourrait-on rsoudre ce dernier problme ?
-16-
Exercice 11 : Protocoles d'changes de cls scuriss

1) Le problme de lchange de cls secrtes en utilisant un rseau (le partage dun secret), est l'un
des problmes les plus importants de la scurit. Pourquoi ?
2) De manire gnrale, citez les proprits de scurit qui doivent tre satisfaites par un protocole
qui transporte une cl secrte ?
3) Une solution dchange de cls entre Alice et Bernard (A et B) en cryptographie cl secrte est
souvent ralise en supposant lexistence dun tiers de confiance qui est un gardien de cls. On fait
lhypothse que chaque utilisateur A (Alice) et B (Bernard) possde une cl secrte. On fait
lhypothse que le gardien connat ces cls secrtes KA et KB. Proposez un protocole scuris
dchange dune cl entre Alice et Bernard en utilisant les services du gardien de cls. Alice
demande au dbut du protocole, une cl de session au gardien, pour dialoguer avec Bernard.
(Alice)
Gardien
Demande_cl (A, B)
------------------------------>
B (Bernard)
4) La cryptographie cls publique est rpute permettre des interlocuteurs ne se connaissant pas
de communiquer de faon confidentielle. On cherche une solution cl publique entre deux entits A
et B (Alice et Bernard). La solution recherche est discipline intrinsque cest dire que le
protocole garantit par lui mme la scurit poursuivie sans utiliser de gardien de cl, de juge,
darbitre, de notaire etc. pour rgler dventuels problmes. Proposez un protocole scuris
dchange de cl discipline intrinsque utilisant la cryptographie cl publique. Analysez votre
protocole en termes de rptition et dinsertion dans le rseau entre Bernard et Alice dun pirate
Martin.
5) Une ide due Rivest et Shamir, deux des inventeurs du RSA a t baptise protocole
cliquets car elle fonctionne par tapes qui ne permettent pas de revenir en arrire. Il sagit dune
solution cl publique et discipline intrinsque dont lobjectif est de parer une attaque de
lintercepteur Martin. Le protocole suivant est plus gnral que lchange dune cl : il propose
lchange dun message not Message_A entre Alice et Bernard et dun Message_B de Bernard
vers Alice :
-17-
A (Alice)
B (Bernard)
Envoi_cl_publique( EA )---------------------------------------->
<-------------------------------------- Envoi_cl_publique( EB )
Dterminer Message_A
Premire_partie (EB(Message_A) )
Envoi (Premire_partie (EB(Message_A) ) )
-------------------------------------->
Dterminer Message_B
Premire_partie (EA(Message_B) )
Envoi (Premire_partie (EA(Message_B)))
<-------------------------------------Envoi (Seconde_partie (EB(Message_A) ) )
-------------------------------------->
Envoi (Seconde_partie (EA(Message_B)))
<--------------------------------------Dchiffrage complet Message_B
Dchiffrage complet Message_A
Le dcoupage des messages crypts en deux parties (par exemple par moiti) doit simplement
tre tel quune partie dun message chiffr nest pas dchiffrable directement sans la connaissance de
lautre partie. On enverrait par exemple dans un codage par blocs, la premire moiti de chacun des
blocs puis la seconde moiti de chacun des blocs. Pourquoi un tel protocole gne t il
considrablement une attaque dun intercepteur ?
6) Avec la mthode dchange dun secret de Diffie et Hellman (1976) deux sites peuvent partager
une valeur secrte. Chaque site met une valeur caractristique du secret (qui est donc publique) et
chaque site utilisant cette valeur peut calculer un secret. Pourquoi ce secret ne peut tre devin par
un couteur passif ? Que peut faire un couteur actif pour contrer ce protocole ?
7) Pour donner un bon niveau de scurit, la plupart des solutions implantes utilisent un annuaire (un
tiers de confiance) qui distribue des cls publiques de manire scurise. On appelle certificat une
donne liant un nom logique (un nom dusager) et une clef publique associe ce nom. Un protocole
dchange de cls de session commence alors par un accs scuris une cl publique comme suit :
A (Alice)
Demande_certificat (B)
Gardien
B (Bernard)
---------------------------------------------------------->
Envoyer_certificat (certificat_B)
<--------------------------------------------------------Comment le protocole suivant est il excut pour empcher une attaque de lintercepteur
Martin ? On peut ensuite par exemple procder un change de cl de session en toute confiance.
8) DAP ("Directory Access Protocol") est le protocole client serveur de gestion rpartie de
l'annuaire X500 associ la messagerie X400. LDAP ("Lightweight Directory Access Protocol") est
une version simplifie de DAP adapte lenvironnement Internet pour en faire un protocole de
niveau application de l'Internet. Il permet un client LDAP d'accder, de modifier, d'ajouter des
donnes un annuaire gr par un serveur LDAP en utilisant les protocoles TCP/IP. De trs
nombreux types de donnes peuvent tre stocks dans un annuaire LDAP mais la donne
-18-
essentiellement gre par les annuaires LDAP sont des certificats au format X509. Les certificats
X509 ont t dfinis au dpart dans la norme X509 de la suite des protocoles X500. La
spcification suivante dfinit lessentiel de la structure de donne associe un certificat au format
X509 (langage de syntaxe de donnes ASN1). Commentez la structure de donne ainsi retenue.
Comment est vrifie une signature ?
Certificate ::= SIGNED {
SEQUENCE{
version [0]
Version DEFAULT v1,
serialNumber
CertificateSerialNumber,
signature
AlgorithmIdentifier,
issuer
Name,
validity
Validity,
subject
Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueIdentifier
[1] IMPLICIT UniqueIdentifier OPTIONAL
}
}
Version ::= INTEGER { v1(0), v2(1), v3(2) }
CertificateSerialNumber ::= INTEGER
AlgorithmIdentifier ::= SEQUENCE {
algorithm
ALGORITHM.&id({SupportedAlgorithms}),
parameters
ALGORITHM.&Type ({SupportedAlgorithms}
{@algorithm}) OPTIONAL }
SupportedAlgorithms ALGORITHM ::= { ... }
Validity ::= SEQUENCE { notBefore UTCTime, notAfter UTCTime }
SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING
}
Time ::= CHOICE { utcTime
UTCTime,
generalizedTime
GeneralizedTime }
SIGNED { ToBeSigned } ::= SEQUENCE {
toBeSigned ToBeSigned,
encrypted ENCRYPTED { HASHED {ToBeSigned }}}
-19-
Exercice 12 : Construction dun systme de paiement par chques

support lectronique
On souhaite construire un systme de paiement par chques tel que les chques puissent tre
achemins dans un rseau non scuris (par exemple sur lInternet dans des courriers lectroniques).
On appelle A (pour acheteur) la personne qui met le chque, C (pour commerant) la
personne qui reoit le paiement. BA est la banque de A et BC la banque de C.
On construit la solution en cryptographie cls publiques (chiffrement asymtrique utilisant
typiquement lalgorithme RSA) de sorte que les partenaires possde tous un couple (E , D) ou E est
la mthode de chiffrement cl publique et D est la mthode de dchiffrement. On note
respectivement (Ea , Da) , (Eba , Dba) , (Ec , Dc) , (Ebc , Dbc) les couples de cls.
Les cls publiques sont accessibles sous forme de structures de donnes certificats dans un
annuaire de certificats. Enfin pour faire de la signature on utilise une fonction de hachage H ayant de
bonnes proprits de scurit. La fonction de hachage scuritaire note H est par exemple le MD5
ou le SHA.
I) Protocole chque standard
A peu prs comme dans la vie courante, pour rgler un achat, lacheteur A prpare une
formule de chque qui comporte les coordonnes de A (en fait lidentifiant A qui peut comporter
diffrentes informations dont le numro de compte etc.), les coordonnes de C (lidentifiant du
destinataire C), un identifiant unique de chque Id_Cheq_A (un numro de chque de A qui doit
faire quune formule de chque a un identifiant unique) et le montant du chque (baptis tout
simplement Montant). Toutes ces informations sont signes par A. On a donc tout d'abord :
A, C , Id_Cheq_A , Montant , Da (H (A , C , Id_Cheq_A , Montant ) )
A
C
Pour mettre le chque en paiement, C signe le chque en utilisant sa cl prive et transmet le
chque endoss sa banque BC pour que le montant soit vir son compte.
C, BC , Id_Cheq_A , Montant , Dc (Da (H (A , C , Id_Cheq_A , Montant )))
C
BC
I.1) Avec ce protocole un intrus peut-il faire payer ses dpenses auprs de C en se faisant passer
pour A . Comment C vrifie que seul A, a pu mettre le chque ?
I.2) Avec ce protocole pourquoi la banque BC est elle sure que seul A a pu mettre le chque, quil
est destin C et que C a accept le paiement ? Voyez vous une diffrence entre la signature
Dc(Da(H(A,C,Id_Cheq_A ,Montant))) et lutilisation de deux signatures concatnes
Da(H(A,C,Id_Cheq_A,Montant)), Dc(H(A,C,Id_Cheq_A,Montant))
I.3) Avec ce protocole, C peut-il prsenter plusieurs fois le chque en paiement sa banque ? A
peut-il utiliser plusieurs fois le mme chque pour payer C (le mme commerant) ou des
commerants diffrents ?
I.4) Est ce que les paiements effectus par A sont confidentiels ?
I.5) Est ce que A peut faire des chques sans provision ?
-20-
II) Protocole chque de banque

On utilise maintenant le protocole suivant.
A, C, Id_Cheq_A , Montant , Da (H (A,C, Id_Cheq_A ,Montant) )
A
BA
A, C, Id_Cheq_A , Montant , Dba(Da(H (A,C, Id_Cheq_A ),Montant)))
BA
A
A, C, Id_Cheq_A , Montant , Dba(Da(H (A,C, Id_Cheq_A ),Montant)))
C
A, C, Id_Cheq_A , Montant , Dc(Dba(Da(H (A,C, Id_Cheq_A ),Montant)))
BC
II.1) Ce protocole sapparente la notion de chque de banque. Pourquoi ? (Avec ce protocole

comment sassurer simplement que A ne peut faire des chques sans provision )
II.2) Avec ce protocole comment assurer que A ne peut utiliser plusieurs fois le mme chque pour
payer le mme commerant ou des commerants diffrents ?
II.3) Comment construire une solution pour que les paiements effectus par A soient confidentiels ?
-21-
Exercice 13 : Protocole de micro-paiement sur Internet

Dans ce problme Bob souhaite faire raliser n oprations successives par Alice. Ces
oprations ont la particularit d'tre toutes les mmes et d'avoir les mmes paramtres. En fait nous
allons utiliser dans la suite du problme ces oprations pour des paiements de sommes trs faibles
sur Internet (par exemple une somme fixe d'un centime d'euro chaque opration).
Alice souhaite authentifier lmetteur dune opration (ici cest Bob) chaque opration.
1) Quels sont les avantages et les inconvnients dune authentification unique en dbut dune session
(comme dans le protocole telnet) et dune authentification pour chaque opration (authentification en
continu) ?
Dans ce problme nous supposons que pour lauthentification en continu, Bob et Alice ont
pralablement chang une clef secrte C comportant k bits. H est une fonction de hachage de
scurit qui a t ngocie entre Alice et Bob, est le ou exclusif, s est un nombre alatoire sur k
bits (nombre alatoire de scurit qui est diffrent chaque authentification). On note{C s} H le
rsultat de lapplication de la fonction de hachage H au ou exclusif de C et de s. On note un message
: metteur, destinataire, type du message, donnes.
De manire dcomposer la solution on l'tudie progressivement. Dans une premire tape on
considre le cas dune seule opration (donc n=1). Le protocole appliqu est le suivant:
Bob
Bob gnre un nombre
alatoire s sur k bits;
il calcule h1 = {C s} H
Rseau
Alice
Bob, Alice, 'Transmission du

nombre s sur k bits', s
Bob demande Alice la
ralisation de lopration
Bob, Alice,'Demande
opration', h1
Alice vrifie que

h1 = {C s} H
Si oui Alice ralise
lopration
2) Quelles sont les proprits des fonctions de hachage de scurit ?

3) Pourquoi Estelle ne peut, en coutant les messages qui circulent entre Alice et Bob, accder la
cl secrte C partage par Alice et Bob?
4) Comment Alice peut-elle authentifier Bob ?
5) Comment s'appelle la technique de chiffrement utilise dans ce protocole?
On considre maintenant le protocole suivant dfini pour n oprations successives :
-22-
Bob
Bob gnre s alatoire
sur k bits et calcule :
h0 = C s
h1 = {h0}H
Rseau
Alice
hi = {hi-1}H
..
hn= {hn-1}H
Bob conserve la suite h1
, . hi, , hn
2
Bob, Alice, 'demande prliminaire

d'ouverture de n oprations', s
Alice calcule la suite

h0 = C s
h1 = {h0}H
.
hi = {hi-1}H
..
hn+1= {hn}H
Alice dtruit les hi et ne
conserve que hn+1
4
Demande de la
premire opration
Bob, Alice, 'demande d'opration', hn
.
2+ Demande de la ime
2i opration (i n)
..
Bob, Alice, 'demande d'opration',
hn-i+1
2+
2i
+1
Authentification de Bob ?
Ralisation de lopration 1
si OK
Authentification de Bob ?
Ralisation de lopration i
si OK
6) Bob mmorise toute la suite des hi quil prsente un par un chaque opration en commenant
par hn puis hn-1. puis hn-i+1.. Alice mmorise une seule valeur en commenant par hn+1 quelle
remplace ensuite par hn puis hn-1 et ainsi de suite chaque nouvelle opration. Quelle est la
vrification ralise par Alice pour authentifier Bob aux tapes 5 et 2+2i+1 ?
7) Expliquez pourquoi Estelle, qui observe ce protocole ne peut aucune tape en tirer des
informations suffisantes pour pouvoir usurper lidentit de Bob.
-23-
Supposons que lon se place dans une approche de cryptographie cl publique. Alice et
Bob disposent donc de couples cl publique, cl prive et de certificats accessibles dans un annuaire
de certificats. Pour raliser le protocole prcdent dauthentification, dans une tape pralable, Alice
et Bob doivent sauthentifier en utilisant un protocole clef publique, Alice doit gnrer la cl secrte
C et doit lenvoyer Bob en utilisant galement la mthode cls publiques.
8) Donnez une solution pour cette authentification mutuelle et pour l'change de cl C. Quel(s)
protocole(s) de l'Internet pourrait servir faire ces authentifications.
Supposons que Alice soit une banque et Bob un de ses clients. On utilise maintenant le
protocole prcdent pour faire des micro paiements. Un protocole de micro paiement est un
protocole permettant de dbiter des sommes trs faibles pour des applications de consultation
payantes sur Internet (lire une page d'un document ou dun journal par exemple). On suppose que n
reprsente une somme en centimes d'euro (n = 1000 centimes par exemple). Cette somme est
dbite du compte courant de Bob au dbut et crdite un compte "de micro paiement" utilisable par
Bob.
On suppose que chaque dbit de micro paiement vaut un centime, ce centime est dbit du
compte de micro paiement de Bob lors de la ralisation par Alice dune opration. Chaque
opration du protocole prcdent est donc un paiement d'un centime.
Quand le compte de micro paiement est vide, Bob doit alimenter nouveau son compte de
micro paiement et Alice et Bob recommencent toute une autre srie doprations de micro paiement.
Si Bob dcide de ne plus payer de cette faon, alors que son compte de micro paiement n'est pas
vide, son compte courant est crdit du solde du compte de micro paiement.
9) Expliquez pourquoi Bob ne peut pas faire de la fausse monnaie (chaque centime est identifi, ne
peut tre rejou).
10) Expliquez pourquoi Estelle ne peut se substituer Bob pour utiliser le compte de micro paiement
de Bob.
11) Quel est l'avantage de ce protocole par rapport un paiement qui utiliserait chaque tape une
authentification selon les mthodes habituelles (par exemple utilisation de SSL pour les paiements par
carte bancaire sur Internet).
-24-
Exercice 14 : Proprits des certificats

Un administrateur observe des certificats gnrs par la mme autorit de certification dans
le cadre dune infrastructure cl publique (une PKI). Il examine des certificats diffrents. Pour fixer
les ides on suppose par exemple que les certificats sont gnrs selon la norme X509.
1) En matire de scurit informatique, rappelez la dfinition dun certificat ?

2) Ladministrateur constate que deux certificats diffrents portent une signature identique. Quelle
peut tre la source de cette situation ? Quel est le danger rsultant (que doit faire ladministrateur) ?
3) Ladministrateur examine deux certificats diffrents et constate quils portent des cls publiques
identiques. Quelle peut tre la source de cette situation ? Quel est le danger rsultant ?
4) Ladministrateur constate que deux certificats diffrents portent un numro de srie identique.
Quelle peut tre la source de cette situation ? Quel est le danger rsultant (que doit faire
ladministrateur) ?
5) Ladministrateur constate que deux certificats diffrents sont signs au moyen de la mme cl
prive. Quelle peut tre la source de cette situation ? Quel est le danger rsultant (que doit faire
ladministrateur) ?
-25-
CHAPITRE 3 : NORMES ET IMPLANTATIONS

INDUSTRIELLES
Exercice 15 : Kerberos
Le projet Athena du MIT (Massachusetts Institutes of Technology) tait, dans le milieu des
annes 80, un projet de recherche portant sur les systmes rpartis. Il avait pour objectif la
dfinition d'un environnement homogne d'accs pour des PC sous MS/DOS, des stations de
travail ou des calculateurs sous UNIX en grand nombre et relis par plusieurs rseaux locaux. L'un
des points forts de cet environnement qui reste, est le protocole qui gre la fois l'authentification
des utilisateurs et certains mcanismes de protection. Ce protocole est dnomm Kerberos
(Cerbre est le chien trois ttes, gardien de l'enfer).
Depuis ces origines Kerberos a connu de nombreuses variantes et a t implants dans
diffrents produits (en particulier chez Digital et plus rcemment chez Microsoft). Il constitue le
standard des systmes de distribution des clefs symtriques (gardiens des clefs) et est trs utilis
dans lInternet, en particulier par les organismes de recherche et denseignement. La plupart des
protocoles de lInternet (PPP, HTTP, SMTP, FTP) supportent une authentification des entits
communicantes base sur Kerberos. Ses principes ont t repris dans des architectures de
protection comme DCE et Windows. La version lIETF est la v5 qui nutilise que la cryptographie
symtrique (DES et triple DES) et les fonctions de hachage scuritaires (MD5 et SHA-1), la v4
faisant lobjet de la RFC1501.
Description du protocole
Kerberos met en communication trois entits :
- lentit client : un programme ou un utilisateur sur une machine donne. Pour simplifier nous
considrons que lentit client figure uniquement un utilisateur humain. Pour nous ce sera Alice.
- lentit serveur: un programme requis par lentit client (par exemple le serveur de fichier).
Ce sera dans la suite le serveur Bob.
- le centre de distribution des clefs, appel KDC (pour Key Distribution Center), il connat
les clefs prives de toutes les entits clients ou serveurs quil conserve dans une base de donnes, il
gnre aussi des clefs de session (temporaires).
Pour fonctionner Kerberos ncessite une synchronisation des horloges de toutes les
machines du rseau. Ce protocole doit raliser entre tout couple d'horloge du rseau un cart
infrieur 5 mn pour des dates lues au mme instant (ce qui est assez facile raliser).
Pour pouvoir utiliser un serveur, Kerberos ralise un protocole de distribution de cls de
session qui respecte les tapes suivantes :
1. Alice sauthentifie auprs du KDC
2. Alice demande un ticket d'utilisation du serveur Bob au KDC. Un ticket au sens de Kerberos
comporte essentiellement une cl de session et diffrentes informations annexes dtailles plus
loin. KDC lui renvoie un ticket valable pour le serveur demand.
-26Exercices UE Scurit et Rseaux
3. Quand Alice sollicite le serveur Bob, elle utilise le ticket que lui a remis le KDC quil met dans
sa requte.
Nous allons dtailler les trois tapes prcdentes. Pour cela, nous dfinissons prcisment
les notations des diffrents objets manipuls par le protocole :
Alice
A,a
SA,sa
Bob
B,b
Kerberos
KDC,kdc
KAB,kab
Ticket
date_fab_X
date_courante
Le nom du client.
Une clef utilise par Alice pour sauthentifier qui en gnral est drive dun mot
de passe A est connue dAlice et de Kerberos (en majuscule quand elle est
utilise pour le dchiffrement, en minuscule pour le chiffrement)
La clef de session dAlice SA est connue dAlice et de Kerberos
Le nom du serveur invoqu.
La clef prive du serveur Bob. (en majuscule quand elle est utilise pour le
dchiffrement, en minuscule pour le chiffrement)
Le nom du serveur de distribution des clefs
La clef de Kerberos connue de lui seul(en majuscule quand elle est utilise pour
le dchiffrement, en minuscule pour le chiffrement)
La clef de session dtermine entre client et serveur. (en majuscule quand elle est
utilise pour le dchiffrement, en minuscule pour le chiffrement)
Le ticket donn un client Alice pour utiliser un serveur Bob.
La date de fabrication de l'objet X
Date donne par lhorloge locale de la machine
Comme dans tout systme d'accs a mots de passe, le client a convenu pralablement avec
ladministrateur systme dun nom (Alice), et dun mot de passe qui devient la clef prive A dAlice.
Pareillement, il a t convenu, pour le programme serveur, dun nom (Bob), et dune clef prive B.
Les clefs ne sont connues que de leur propritaire (qui doivent donc les garder secrtes), et du
serveur d'authentification Kerberos. Ce systme doit donc tre particulirement bien protg.
Etape 1 : Authentification du client

Alice commence par envoyer une requte dauthentification KSB_AS_REQ contenant son
Nom de login (Alice) Kerberos. Kerberos lui renvoie un message KSB_AS_REP contenant une
clef de session SA personnelle Alice et un ticket de contrle daccs TGT (Ticket Granting
Ticket).
1) Quelles sont les fonctions que doit raliser un gardien de clefs ? Expliquez les principes du triple
DES et ses avantages par rapport au DES ? A quoi peut servir la combinaison dune fonction de
hachage et dun crypto systme symtrique ?
-27-
Alice
Kerberos
KSB_AS_REQ, Alice, Kerberos
Gnre la clef SA ;
date_per_SA := date_courante+ dure_validit ;
TGT= {Alice, SA, date_per_SA}sym
kdc
REP := {SA, TGT}sym

a
SA,TGT := {REP }sym
A
KSB_AS_REP, Kerberos, Alice,

REP
2) Expliquez lusage des deux chiffrements raliss dans cette tape. Contre quelle attaque est
utilise la variable date_per_SA ? Expliquez son usage.
Etape 2 : Obtention du ticket daccs au serveur
Lorsque Alice dsire (durant la priode de validit de son ticket dauthentification) utiliser le service
du serveur Bob, elle adresse Kerberos une requte daccs ce serveur. Cette requte contient
outre le nom du serveur, TGT et la date courante chiffre avec SA. A rception de cette demande
Kerberos dchiffre TGT, rcupre la clef SA, dchiffre la date avec SA et vrifie que cette date est
voisine de son heure courante.
3) Que prouve ce contrle ? Quelle technique de protection peut utiliser Kerberos pour le contrle
des droits dAlice? Quel est lusage du chiffrement ralis par Kerberos?
Etape 3 : Accs au serveur applicatif
Dans un dlai compatible avec la dure de validit du Ticket, Alice va demander au serveur Bob
dexcuter la transaction pour laquelle elle a obtenu le ticket. Elle envoi donc ce serveur une
requte avec le ticket.
4) A quoi sert la variable d1 et pourquoi est elle chiffre ? Expliquez le principe du contrle ralis
par Bob ? Quel est lusage de la variable REP2 ? A quoi pourra servir KAB dans la suite des
changes de la transaction courante entre Alice et Bob ? Comment appelle ton une telle variable?
Extension de Kerberos
Une extension de Kerberos est en cours de normalisation. Elle consiste utiliser un crypto
systme asymtrique pour toutes les oprations utilisant des clefs rmanente (A,B, KDC). Dans ce
cas Kerberos na plus besoins de stocker les clefs symtriques de chaque participant. Il ne stocke
que des clefs symtriques de session et sa clef (KDC) et des certificats pour chaque utilisateur. Ceci
rduit considrablement le risque li une attaque de Kerberos.
5) Donnez le schma dchange de messages de ltape 1 (cas nominal) correspondant cette
extension en justifiant lutilisation de chaque opration cryptographique.
[Adr_c ; Adr_s ; ( { Ac }Cl_sess_c,s ; { Tc,s }Cl_s ) ]
-28-
Exercice 16 : Authentification daccs au rseau Internet : solution des

protocoles PAP et CHAP
Laccs au rseau Internet est le plus souvent ralis en utilisant le protocole de liaison PPP
(Point to Point Protocol). Cest un protocole de communication point point entre deux sites
voisins dans le rseau. Il lui est associ une suite de protocoles dont un protocole de ngociation des
paramtres de la liaison et deux protocoles dauthentification permettant de raliser un contrle
daccs au rseau.
Le protocole PAP (Password Authentication Protocol, RFC 1334), constitue la forme la
plus simple et la plus classique dauthentification utilise avec PPP. La figure suivante montre la
structure des messages changs :
Code dfinit le type du message.
Identificateur permet dassocier les requtes et les rponses.
Longueur dfinit la longueur de la zone donne.
0
7
31
15
Code
Longueur
Identificateur
Donnes
PAP est bas sur la connaissance par les deux sites dun mot de passe secret associ au
demandeur. Aprs ngociation des paramtres de liaison et avant lchange de donnes, le site
demandant laccs au rseau avec PAP doit fournir son mot de passe au prestataire daccs.
Lchange est le suivant :
Trame Code 1 : Demande dauthentification (par lusager)
La zone donnes comporte :
- longueur du nom du demandeur utilis (1 octet)
- nom du demandeur daccs (user's name)
- longueur de mot de passe utilis (1 octet)
- mot de passe (password)
Le mot de passe est trait comme dans les systmes classiques. Il est compar avec une
valeur stocke dans un fichier de mots de passes (ventuellement crypts) sur le site du prestataire
daccs.
Trame Code 2 : Acquittement positif dauthentification
La zone donnes est inexistante.
Le demandeur peut ensuite mettre des trames PPP.
Trame Code 3 : Rejet dauthentification
Lutilisateur ne peut pas transmettre de trames. Il doit mettre nouveau une trame
de code 1 et russir les tapes 1 et 2.
1) Citez deux faiblesses de cette mthode ?
-29-
Le protocole CHAP ( Challenge Handshake Authentication Protocol, RFC 1994 rend

obsolte PAP RFC 1334), a ensuite t propos. Il est bas sur le mme format de message et sur
la mme connaissance par les deux sites demandeur et prestataire, dun nom dusager associ un
mot de passe secret. Aprs la phase de ngociation des paramtres de la liaison cest le prestataire
daccs qui prend linitiative dauthentifier le demandeur de connexion :
Trame Code 1 : Envoi dun challenge
La zone donnes comporte :
- longueur du challenge utilis (1 octet)
- valeur du challenge (suite binaire)
Trame Code 2 : Rponse
Le demandeur de connexion concatne :
- la valeur de lidentificateur
- la valeur du mot de passe secret
- la valeur du challenge
Lensemble est condens au moyen dune fonction de hachage sens unique. Lalgorithme
de hachage employ est ngociable.
MD5 est le plus souvent utilis (16 octets de hachage).
Trame Code 3 : Acquittement positif dauthentification.
Le prestataire compare la valeur reue la valeur rsultat dun calcul identique effectu
localement.
Si les rsultats sont identiques lauthentification a russie.
Trame Code 4 : Rejet dauthentification.
Les valeurs reues et calcules tant diffrentes
lauthentification est rejete.
Ultrieurement, le prestataire priodiquement dtermine une valeur de challenge et rpte les
tapes un trois.
2) Quelles sont les avantages de cette solution en matire de rsistance aux attaques par coute et
rptition de trafic cout?
3) Pourrait-on avec CHAP authentifier le prestataire comme on authentifie le demandeur ?
4) Peut-on utiliser plusieurs noms et plusieurs mots de passe pour un mme utilisateur? Pour quel
usage ?
5) Quelles sont les inconvnients de cette solution
6) Quelles sont les qualits indispensables de la solution en matire de mot de passe ?

7) Quelles sont les qualits indispensables de la solution en matire de fonction de hachage sens
unique?
8) Quelles sont les qualits indispensables de la solution en matire de valeur de challenge?
9) Est ce que ce protocole rsiste linsertion dun intrus sur la ligne entre le demandeur et le
prestataire qui peut tre couteur actif (active wiretaping) ?
-30-
Exercice 17 : Authentification daccs au rseau Internet : le protocole

RADIUS
Lauthentification des utilisateurs par des prestataires daccs au rseau Internet peut tre
ralise au moyen des protocoles PAP (Password Authentication Protocol, RFC 1334 octobre
1992) ou CHAP (Challenge Handshake Authentication Protocol, RFC 1994, aot 1996). Ces
protocoles appartiennent la suite des protocoles de niveau liaison de lInternet PPP (Point to Point
Protocol, RFC 1661, juillet 1994)
On tudie dans ce problme une solution plus rcente dfinie par le protocole RADIUS
(Remote Authentication Dial In User Service, RFC 2138, avril 1997). Ce protocole a t dfini
par la socit Linvingston qui la donn la communaut Internet. Il est largement implant
actuellement par les principaux fournisseurs de matriels daccs Internet et est donc utilis par de
nombreux prestataires daccs.
RADIUS dfinit un nouveau protocole dauthentification tout en permettant dutiliser les
principaux protocoles existants pour les prestataires qui souhaitent conserver leurs mthodes de
travail (PPP/PAP, PPP/CHAP, UNIX/login local ou NIS Network Information System de SUN,
ou mme Kerberos). Il tend les fonctions dauthentification dautres fonctions dadministration de
rseau, baptises dans le jargon mtier fonctions AAA pour Authentication, Authorization,
Accounting (Vrification didentit, Contrle des droits, Comptabilit).
RADIUS est un protocole client serveur de niveau application. Les clients sont soit des sites
serveurs daccs Internet (NAS Network Access Server), soit des routeurs, des pare_feux, des
applications daccs distant comme telnet, rlogin. Le serveur RADIUS est un site de gestion
centralise des informations AAA.
Pour assurer le transport des informations entre client et serveur, RADIUS utilise dans tous
les cas le rseau Internet par son protocole de transport UDP.
Notons enfin que le protocole RADIUS est extensible car les changes de donnes se font
au moyen de la notion dattribut. Un attribut est dfini par son type, sa longueur, sa valeur de sorte
que de nouveaux attributs associs de nouvelles fonctions peuvent tre ajouts sans modifier
lexistant.
RADIUS est bas sur un format de message dduit du format LCP (Link Control
Protocol) de PPP utilis galement par les protocoles PAP et CHAP.
Code
Ident
Longueur
Authentificateur
(16 octets)
Attributs
Les diffrents champs dans le dessin prcdent ont la signification suivante :
a) Le code dfinit en fait sur un octet le type du message.
1
Access-Request
2
Access-Accept
3
Access-Reject
-31-
4
5
11
12
13
255
Accounting-Request
Accounting-Response
Access-Challenge
Status-Server (experimental)
Status-Client (experimental)
Reserved
b) Lidentificateur (identifier sur un octet) associe les requtes et les rponses. La zone
longueur (length) dfinit sur deux octets la longueur totale des donnes incluant code, longueur etc.
c) Lauthentificateur (Authenticator) (16 octets) est utilis comme son nom lindique pour
lauthentification. Sa mthode de calcul est diffrente selon les types de messages (voir plus loin
lexplication du protocole).
d) Les attributs (Attributes) sont utiliss pour vhiculer toutes les informations ncessaires
aux changes AAA. Le format dun attribut est le suivant :
Longueur
Type
Valeur
Quelques exemples de types dattributs.

1 User-Name
4 NAS-IP-Address
7 Framed-Protocol
10 Framed-Routing
13 Framed-Compression
16 Login-TCP-Port
19 Callback-Number
22 Framed-Route
25 Class
2 User-Password
3 CHAP-Password
5 NAS-Port
6 Service-Type
8 Framed-IP-Addres
9 Framed-IP-Netmask
11 Filter-Id
12 Framed-MTU
14 Login-IP-Host
15 Login-Service
17 (unassigned)
18 Reply-Message
20 Callback-Id
21 (unassigned)
23 Framed-IPX-Network 24 State
26 Vendor-Specific
Version de base du protocole dauthentification

Les principes de scurit du protocole dauthentification sont les suivants. Comme pour le
protocole CHAP les changes RADIUS sont scuriss par une cl secrte partage entre client et
serveur (baptis secret dans la suite). Les usagers sont connus par un nom dusager et sont
authentifis par un mot de passe secret. Le protocole offre deux possibilits diffrentes dauthentifier
un utilisateur distant. Ce premier change constitue la version de base.
Serveur_RADIUS
Client_RADIUS
Access-Request
Access-Accept ou Access-reject
Structure du message Access-Request

-32-
- Le champ authentificateur contient une valeur alatoire de 16 octets. Dans le message AccessRequest cette valeur est baptise authentificateur de requte (Request Authenticator).
- Un champ attribut de type nom dusager contient le nom dutilisateur en clair.
- Un champ attribut de type mot de passe contient le mot de passe usager cod par :
MD5 ( Secret || Authentificateur ) OUEX Mot_de_passe
|| : l'oprateur de concatnation.
MD5 : fonction de hachage sens unique pour crer une signature de 16 octets.
OUEX : ou exclusif (en anglais XOR) entre lempreinte MD5 et le mot de passe sur 16 octets.
Une technique est propose pour crypter les mots de passe de plus de 16 octets sur 16
octets. Si pi est le ime bloc de 16 octets du mot de passe le calcul est donn par :
b1 = MD5(Secret || Authentificateur)
c(1) = p1 ouex b1
b2 = MD5(Secret || c(1))
c(2) = p2 ouex b2
...
bi = MD5(Secret || c(i-1))
c(i) = pi ouex bi
Structure du message Access-Accept ou Accept-Reject
- Ces messages de rponse servent essentiellement par leur type accepter ou rejeter
lauthentification.
- Le champ Authentificateur des messages Access-Accept ou Access-Reject contient une signature
MD5 des informations suivantes concatnes (notion de Response Authenticator)
MD5 (
Code de rponse ||
Identificateur de rponse ||
Longueur de rponse ||
Authentificateur (celui de la requte) ||
Attributs de rponse (si ncessaire) ||
Secret )
- Zones attributs (si ncessaire).
1) Dans le message access-request comment est utilis lauthentificateur ( quoi sert il) ? Quelles
sont les caractristiques associes lauthentificateur de requte pour que le secret ne puisse tre
dcrypt ?
2) On remarque dans la mthode dauthentification RADIUS lemploi de MD5 et du ou exclusif.
Quelle est la mthode de chiffrement qui se rapproche le plus de la mthode employe pour le mot
de passe (pourquoi le mot de passe ne peut-il tre dcrypt)?
3) Comment le serveur vrifie til lidentit de lusager ? Peut-on utiliser un fichier des mots de passe
crypts comme en UNIX ou doit-on avoir les mots de passe en clair sur le serveur RADIUS?
4) Le client peut-il galement authentifier le serveur ?
5) La solution rsiste telle une attaque par rptition ?
-33-
Version complte du protocole dauthentification

Cette authentification est dfinie dans la norme pour renforcer la scurit par exemple lors de
lauthentification automatique dun usager possesseur dune carte puce. Elle comporte deux
changes requte/rponse.
Aprs une premire requte (message access-request dj vu) le serveur ne rpond pas par
une acceptation ou un rejet. Il rpond par un message de type access-challenge.
Le second change requte/rponse comporte une nouvelle requte dauthentification
access-request qui est alors accepte ou rejete.
Serveur_RADIUS
Client_RADIUS
Access-Request
Access-Challenge
Access-Request
Access-Accept ou Access-reject
Structure du message Access-Challenge

- Le champ authentificateur contient une valeur qui est un authentificateur de rponse (Response
Authenticator) calcule dune faon exactement identique celle dcrite dans le protocole de base
pour les messages Access-Accept ou Access-Reject.
- Un attribut de type state contient une chane binaire dfinie la discrtion du serveur.
- Un autre attribut de type reply_message contient une zone dinformation. Il sagit en fait dune
chane de texte caractre explicatif.
Structure du second message Access-Request
- A la rception de access-challenge le client doit rpondre par un Access-Request analogue celui
du premier change avec cependant les modifications suivantes:
. utilisation dun nouvel identificateur
. utilisation dun nouvel authentificateur
. la chane binaire fournie par le serveur dans lattribut state doit tre concatne au mot de
passe avant lutilisation de celui-ci.
6) A quoi sert le message Access-Challenge (quels sont les principes gnraux de ce
protocole d'authentification)?
7) A quels types dattaque rsiste le protocole complet? A quels types dattaque ne rsiste til pas ?
-34-
Exercice 18 : Scurisation des rseaux sans fils WIFI : les normes WEP
Le dveloppement des rseaux locaux sans fils IEEE 802.11 connus sous le sigle
commercial WIFI (WIreless FIdelity) est trs rapide et trs important. Les rseaux locaux sans fils
(Wireless LANs) permettent de dployer de petites infrastructures de rseau local sans avoir besoin
de cbler les btiments. Dans la plupart des cas, ces rseaux sans fils fonctionnent pour acheminer et
recevoir du trafic de lInternet mondial auquel le rseau est connect via un point daccs. Le
systme informatique qui joue le rle de point daccs possde quand lui une liaison filaire avec
lInternet.
Dans ce problme on tudie les techniques de scurit qui ont accompagn la premire
gnration du WIFI (802.11 de base en 1997, 802.11b en 1999). Ces mcanismes de scurit sont
runis sous le sigle WEP (Wired Equivalent Privacy).
1) Le problme de scurit est un problme considr comme majeur dans un rseau sans fil.
Pourquoi (citez diffrentes attaques qui rendent ces infrastructures particulirement vulnrables) ?
Authentification dans le WEP

En matire dauthentification, le WEP dfinit principalement deux mthodes baptises
authentification ouverte et authentification cl partage. Nous examinons aussi une solution utilisant
les adresses de niveau liaison (adresses MAC).
a) Lauthentification ouverte
Chaque rseau Wifi est caractris par un identifiant unique baptis SSID ('Service Set
Identifier'). Cet identifiant est dfini pour distinguer les rseaux WIFI. Une station doit donc
connatre le SSID du rseau dans lequel elle souhaite s'insrer. La mthode dauthentification
consiste faire vrifier par le point d'accs quune station qui dialogue avec le point daccs
prsente le bon SSID identifiant du rseau. L'identifiant SSID prsent par une station circule en
clair dans les messages. Dans le mode PCF, cet identifiant peut galement tre diffus en clair par le
point d'accs dans certains messages.
2) Quelle est la scurit offerte par la mthode dauthentification par lidentificateur de rseau SSID?
Une autre technique pour authentifier les usagers dun rseau sans fils n'est pas normalise
mais elle est assez souvent implante. Elle consiste se baser sur les adresses de niveau liaison
(adresses de la carte rseau ou adresse MAC 'Medium Access Control'). En effet, de faon
exactement identique un rseau local Ethernet, chaque station dun rseau WIFI possde une
adresse unique de niveau liaison. Dans certains rseaux WIFI, le point daccs maintient une liste
des adresses MAC autorises utiliser ses services. Si une adresse MAC, fournie comme adresse
source par une station, nappartient pas la liste, cette station ne peut communiquer via le point
daccs.
3) Quels sont les avantages et inconvnients de la mthode dauthentification par les adresses MAC
(particulirement du point de vue de la scurit)?
c) Lauthentification cl partage
-35-
Le WEP suppose quune cl secrte est partage entre toutes les stations et le point
daccs. Dans cette mthode d'authentification, lorsqu'une station apparat dans un rseau, elle met
une requte d'authentification, le point daccs lui rpond par un message contenant en clair un
nonce. La station doit rpondre en retournant la valeur du nonce chiffre en RC4 au moyen de la cl
secrte. Le chiffre RC4 est le chiffre utilis pour le chiffrement en confidentialit du WEP et il est
dcrit plus loin. Si le point daccs peut vrifier que le nonce est correctement chiffr alors
lauthentification russit sinon elle choue.
4) Rappelez la dfinition d'un nonce. Quels sont les avantages et inconvnients de la mthode
dauthentification en WIFI par cls partages (particulirement du point de vue de la scurit)?
Confidentialit dans le WEP

La confidentialit dans le WEP est base sur le chiffre cl secrte RC4 (Rivest Cipher n
4). Cest le quatrime chiffre invent par Ron Rivest, lun des inventeurs du RSA. Il existe aussi des
chiffres RC5, RC6. Le chiffre RC4 est officiellement proprit de la socit RSADSI (RSA Data
Security Incorporated', socit qui dtenait le brevet du RSA). En dehors du rseau local 802.11
WIFI, RC4 est retenu dans un trs grand nombre de logiciels trs diffuss comme MS Access,
Adobe Acrobat, Oracle Secure SQL, SSL, Lotus Notes, chiffrement de mots de passe Windows,
...
RC4 est un chiffre symtrique, utilisant une cl secrte qui doit tre connue des entits
communicantes autorises (cl secrte partage). Dans le WEP on peut utiliser deux tailles de cls:
40 bits (5 octets) ou 104 bits (13 octets).
Le chiffre RC4 est gnralement prsent sous la forme des deux algorithmes suivants.
A) Initialisation dun tableau alatoire S de 256 octets partir de la cl secrte stocke
dans le tableau key
Ce premier algorithme initialise un tableau S (utilis dans le second algorithme pour chiffrer).
Cette initialisation prend comme base la cl secrte range dans un tableau doctets key de longueur
key_length. Par exemple en WEP on a key_length = 5 ou 13. Le tableau S est de 256 octets. A la
fin de l'initialisation, S contient toutes les valeurs possibles des octets (de 0 255) distribues
alatoirement. Cette distribution est obtenue partir de la cl dans le tableau key par une suite
dchanges de cases dans le tableau S. Pour cela on ralise des calculs dadresse modulo 256
(puisque le tableau S possde 256 entres) pour dterminer les cases que l'on change.
j := 0 ;
(Initialisation de la variable entire j)
pour i = 0..255
S[i] := i ;
(Initialisation du tableau S de 256 cases)
pour i = 0..255
(Permutation du tableau S)
j := (j+S[i]+key[i mod key_length]) mod 256; (Choix de case modulo 256)
aux:=S[i] ; S[i]:=S[j] ; S[j]:=aux ;
(Echange de S[i] et S[j])
B) Boucle de chiffrement octet par octet
Cet algorithme dfinit le chiffrement de chaque octet en utilisant le tableau S. Pour chaque octet
chiffrer on commence par permuter nouveau le tableau S. Pour cela on fait un calcul dadresse et
-36-
on change deux cases du tableau S. Pour le chiffrement proprement dit, on commence par choisir
une valeur stocke dans le tableau S. Cet octet, not k, rsulte dun calcul dadresse et de
lextraction de la valeur de la case du tableau S correspondante. k est utilis pour raliser le
chiffrement effectif, par un ou exclusif avec loctet en clair chiffrer.
On rappelle la dfinition du ou exclusif : 0 0 = 0, 0 1 = 1, 1 0 = 1, 1 1= 0
Avec cette dfinition on rappelle que le ou exclusif est son propre inverse (l'opration inverse du
ou exclusif , la soustraction, est le ou exclusif x x = 0).
i:= 0; j := 0 ;
rpter
(Boucle pour tous les octets chiffrer)
i := (i+1) mod 256 ;
(Choix d'une case i)
j := (j+S[i]) mod 256 ;
(Choix d'une case j)
aux := S[i] ; S[i] := S[j] ; S[j] := aux ;
(Echange de S[i] et S[j])
k := S[(S[i]+S[j]) mod 256] ;
(On prend une valeur k dans S)
octet_chiffr := octet_en_clair k ;
( ou exclusif avec k)
jusqu fin du texte en clair ;
5) Si lon utilise lopration de chiffrement RC4 spcifie par les deux algorithmes prcdents, quels
sont les algorithmes utiliss pour le dchiffrement (commentez votre rponse) ?
6) Quelle est la mthode de chiffrement vue en cours qui se rapproche le plus de ce chiffre (citez les
points de rapprochement qui vous font proposer votre choix)?
7) Quelles sont les diffrences principales entre le RC4 et le chiffre vu en cours que vous proposez ?
8) On suppose quon utilise le chiffre RC4 sur deux messages diffrents avec la mme cl. Un
attaquant coute le trafic chiffr. Cet attaquant peut connatre sur certains messages tout ou partie du
texte en clair. Par exemple, parce que le format de certains messages est connu et que de
nombreuses valeurs qui correspondent aux diffrents champs sont connues (messages complets du
protocole WIFI connus, existence denttes de messages connues avec les protocoles IP, TCP,
HTTP, SMTP ). On suppose donc que sur un message un attaquant connat un octet en clair et il
connat la valeur chiffre qui circule (octet_chiffr). Sur un second message, utilisant la mme cl,
lattaquant connat seulement loctet chiffr. En utilisant la technique de chiffrement RC4 base sur le
ou exclusif montrez que lattaquant peut dchiffrer loctet du second message ?
En WEP, pour ne pas utiliser sur chaque message la mme cl secrte (on vient de voir que
c'est trs mauvais), on complte la cl secrte partage en lui rajoutant en tte une valeur de 24 bits.
Cette valeur est appele vecteur dinitialisation. De la sorte, pour un message donn, la cl RC4
utilise est compose de trois octets de vecteur dinitialisation suivis de 5 ou 13 octets de cl secrte
partage.
WEP ne spcifie pas de rgle prcise concernant le choix du vecteur dinitialisation. La
norme indique seulement que le vecteur d'initialisation utilis pour un message doit tre transmis en
clair avec ce message. Certaines implantations commencent toujours en prenant pour le premier
message mis la valeur 0. Ensuite, le vecteur dinitialisation est gr comme un numro de squence.
Il est simplement incrment pour chaque nouveau message mis.
9) Dans cette gestion du vecteur d'initialisation, on souhaite faire une premire estimation de la
rutilisation de la mme cl. On fait un calcul approch en supposant un rseau WIFI fonctionnant
-37-
54 megabits/s et transmettant uniquement des messages de longueur moyenne 1000 octets en

permanence. Il s'agit d'une simple estimation car les protocoles ont un comportement beaucoup plus
complexe qu'on ne peut rsumer une mission continue de messages de 1000 octets. Selon cette
estimation, au bout de combien de temps rutilise ton le mme vecteur dinitialisation donc la mme
cl de chiffrement WEP (en ouvrant ainsi une possibilit de dchiffrement) ?
Il existe d'autres techniques de piratage nettement plus complexes non dcrites ici qui
permettent de casser une cl WEP en peu de temps.
Intgrit dans le WEP

En matire de contrle dintgrit, le WEP propose dutiliser le code polynomial habituel des
rseaux locaux IEEE 802 (on parle aussi souvent du CRC Cyclic Redundancy Check). Ce code
porte sur les donnes d'une trame et il est baptis ICV ('Integrity Check Value'). Il est dfini
exactement de la mme faon que dans Ethernet. Une zone de donnes en WIFI est complte par
un ICV de longueur 32 bits, obtenu comme le reste dans une division de polynme.
On rappelle que si M(x) est le polynme associ un message M et CRC32(x) est le
polynme de degr 32 utilis comme gnrateur du code polynomial pour tous les rseaux IEEE
802, alors le contrle d'intgrit est dfini par les coefficients du polynme ICV(x) obtenu comme le
reste dans la division de M(x) multipli par x32 par CRC32(x). De manire prcise on dfinit ICV
par la division suivante dans laquelle Q(x) est le polynme quotient :
x32 M(x) = CRC32(x) Q(x) ICV(x)
Tout se passe du point de vue de la scurit comme si le code polynomial ICV tait
considr comme une fonction de hachage permettant la dtection des modifications. De faon
protger cette forme de hachage des modifications dun pirate, le code polynomial ICV est chiffr en
confidentialit comme les donnes du message en RC4. Pour une cl secrte K et une zone de
donnes chiffrer M, on transmet donc dans une trame WIFI, le message M chiffr en RC4 suivi de
ICV chiffr en RC4. Si l'on note || la concatnation, la trame transmise contient donc RC4( K , M ||
ICV).
10) Montrer que si lon transmet un message M dont le polynme associ M(x) est de la forme
M1(x) M2(x) alors l'ICV associ M est le ou exclusif des ICV de M1 et de M2 (on dit encore
que le calcul d'ICV est linaire soit ICV(x) = ICV1(x) ICV2(x) )
11) Un pirate intercepte un message M1 correctement construit et chiffr en WEP par son metteur.
Le pirate acquiert donc RC4(K , M1 || ICV1). Il ajoute (en ou exclusif) ce message correct un
message M2 en clair avec son code polynomial ICV2 correct. En fait il remplace RC4(K , M1 ||
ICV1) par le message modifi (M2 || ICV2) ( RC4(K , M1 || ICV1) et le transmet au destinataire.
Montrez que la vrification dintgrit base sur la vrification du code polynomial ICV chiffr ne
dtecte pas cette modification.
12) Au total que penser de lensemble des mcanismes de scurit proposs dans le WEP.
Comment faire mieux ?
-38-
Exercice 19 : Architecture de scurit IPSEC

Le document qui suit est un chapitre de la norme qui dfinit l'architecture de scurit des
communications en IP (IP SECurity, RFC Request For Comments numro 2401). L'objectif
poursuivi ici concerne la comprhension de cette norme. Le chapitre 5, qui a t slectionn,
sintresse au traitements de scurit appliquer aux datagrammes IP par IPSEC ('IP Traffic
Processing'), tout d'abord en sortie (Outbound, section 5.1) puis en entre (Inbound, section
5.2). Le document est suivi d'un ensemble de questions. Chaque question appelle en rponse une
explication ncessitant la comprhension de l'un des mcanismes de scurit voqu dans le
document, en relation avec votre connaissance de IPSEC. La comprhension peut ncessiter
plusieurs lectures mais il nest pas ncessaire de sattacher comprendre tous le document des le
dpart. On peut rpondre aux questions successives en progressant dans le document. Par contre,
les rponses aux questions poses qui seraient une simple traduction de langlais, n'ont pas d'intrt.
RFC 2401
Security Architecture for IP
November 1998
5. IP Traffic Processing
As mentioned in Section 4.4.1 "The Security Policy Database (SPD)",
the SPD must be consulted during the processing of all traffic
(INBOUND and OUTBOUND), including non-IPsec traffic. If no policy is
found in the SPD that matches the packet (for either inbound or
outbound traffic), the packet MUST be discarded.
NOTE: All of the cryptographic algorithms used in IPsec expect their
input in canonical network byte order (see Appendix in RFC 791) and
generate their output in canonical network byte order. IP packets
are also transmitted in network byte order.
5.1 Outbound IP Traffic Processing
5.1.1 Selecting and Using an SA or SA Bundle
In a security gateway or BITW implementation (and in many BITS
implementations), each outbound packet is compared against the SPD to
determine what processing is required for the packet. If the packet
is to be discarded, this is an auditable event. If the traffic is
allowed to bypass IPsec processing, the packet continues through
"normal" processing for the environment in which the IPsec processing
is taking place. If IPsec processing is required, the packet is
either mapped to an existing SA (or SA bundle), or a new SA (or SA
bundle) is created for the packet. Since a packet's selectors might
match multiple policies or multiple extant SAs and since the SPD is
ordered, but the SAD is not, IPsec MUST:
1. Match the packet's selector fields against the outbound
policies in the SPD to locate the first appropriate
policy, which will point to zero or more SA bundles in the
SAD.
2. Match the packet's selector fields against those in the SA
bundles found in (1) to locate the first SA bundle that
matches. If no SAs were found or none match, create an
appropriate SA bundle and link the SPD entry to the SAD
entry. If no key management entity is found, drop the
-39-
packet.
3. Use the SA bundle found/created in (2) to do the required
IPsec processing, e.g., authenticate and encrypt.
In a host IPsec implementation based on sockets, the SPD will be
consulted whenever a new socket is created, to determine what, if
any, IPsec processing will be applied to the traffic that will flow
on that socket.
NOTE: A compliant implementation MUST not allow instantiation of an
ESP SA that employs both a NULL encryption and a NULL authentication
algorithm. An attempt to negotiate such an SA is an auditable event.
5.1.2 Header Construction for Tunnel Mode
This section describes the handling of the inner and outer IP
headers, extension headers, and options for AH and ESP tunnels. This
includes how to construct the encapsulating (outer) IP header, how to
handle fields in the inner IP header, and what other actions should
be taken. The general idea is modeled after the one used in RFC
2003, "IP Encapsulation with IP":
o The outer IP header Source Address and Destination Address
identify the "endpoints" of the tunnel (the encapsulator and
decapsulator). The inner IP header Source Address and
Destination Addresses identify the original sender and
recipient of the datagram, (from the perspective of this
tunnel), respectively. (see footnote 3 after the table in
5.1.2.1 for more details on the encapsulating source IP
address.)
o The inner IP header is not changed except to decrement the TTL
as noted below, and remains unchanged during its delivery to
the tunnel exit point.
o No change to IP options or extension headers in the inner
header occurs during delivery of the encapsulated datagram
through the tunnel.
o If need be, other protocol headers such as the IP
Authentication header may be inserted between the outer IP
header and the inner IP header.
The tables in the following sub-sections show the handling for the
different header/option fields (constructed = the value in the outer
field is constructed independently of the value in the inner).
5.1.2.1 IPv4 -- Header Construction for Tunnel Mode
IPv4
Header fields:
version
header length
TOS
total length
ID
flags (DF,MF)
fragmt offset
<-- How Outer Hdr Relates to Inner Hdr -->

Outer Hdr at
Inner Hdr at
Encapsulator
Decapsulator
------------------------------4 (1)
no change
constructed
no change
copied from inner hdr (5)
no change
constructed
no change
constructed
no change
constructed, DF (4)
no change
constructed
no change
-40-
TTL
protocol
checksum
src address
dest address
Options
constructed (2)
AH, ESP, routing hdr
constructed
constructed (3)
constructed (3)
never copied
decrement (2)
no change
constructed (2)
no change
no change
no change
1. The IP version in the encapsulating header can be different

---------------------------Document interrompu ici.
1) Le paragraphe d'introduction du chapitre prend comme point de dpart la notion de SPD qui est
un lment de base de IPSEC. Rappelez la dfinition et le rle de la SPD. La norme souligne quun
datagramme entrant ou sortant doit obligatoirement correspondre une entre de la SPD sinon le
datagramme doit tre dtruit. Pourquoi?
Pour faciliter la lecture du texte nous fournissons les informations suivantes. Il existe trois
faons d'ajouter des traitements de scurit IPSEC des quipements en rseau existants (trois
types de solutions dimplantation dIPSEC).
a) Par la modification du code du protocole IP en intgrant compltement IPSEC dans une
implantation IP existante.
b) Une solution voisine de la prcdente mais plus modulaire consiste sparer le plus
clairement possible le code de IPSEC du code IP standard. La partie de code spcifique IPSEC
apparat alors comme un module spar de IP qui est activ si ncessaire. On parle alors en anglais
de solution "Bump-In-The-Stack" do le sigle BITS. Certains aspects comme la fragmentation et le
rassemblage des datagrammes qui peuvent tre ncessits par IPSEC, doivent quand mme tre
traits par une modification dans le code du protocole IP (qui est alors assez lgre).
Les deux solutions a) et b) sont applicables tous les types d'entits rseaux (htes, routeurs
ou passerelles de scurit) par modification logicielle.
c) La solution baptise "Bump-In-The-Wire" ayant pour sigle BITW consiste faire raliser
la scurisation IPSEC par un composant matriel/logiciel ddi, l'extrieur de lentit rseau
demandant une scurisation IPSEC. Il peut sagir dune passerelle de scurit (un quipement de
rseau ddi la scurit) ou dun routeur jouant galement le rle de passerelle de scurit.
2) A la fin du premier paragraphe de la section 5.1.1, la norme rappelle que dans la dfinition dune
politique de scurit IPSEC, les rgles sont ordonnes (elles sont exploites dans un ordre qui est
dfini par ladministrateur de la scurit). A quoi correspond cette notion dordre (pourquoi les
rgles sont-elles ordonnes) ? Indication : vous pouvez relier la dfinition dune politique de scurit
IPSEC la dfinition dune politique de scurit dans un filtre de paquets dun pare-feu.
Le paragraphe 5.1.1 distingue deux cas possibles en ce qui concerne la consultation de la
SPD. Les paragraphes associs aux deux cas commencent l'un par 'In a security gateway' et l'autre
par 'In a host'). Dans le premier cas, on voit en lisant le texte, que chaque datagramme en mission
commence par une consultation de la SPD. Dans le second cas le texte s'intresse l'application de
IPSEC sur le trafic de datagrammes cr par une socket (communication de niveau transport en
TCP ou en UDP). La SPD est consulte seulement chaque fois qu'une socket est cre.
-41-
3) Expliquez cette diffrence de comportement entre les deux cas (quels sont les avantages et les
inconvnients des deux mthodes). A quel type d'implantation serait plutt associ le cas d'IPSEC
fonctionnant pour une communication socket ?
4) Le premier paragraphe dans le point 5.1.1 fait rfrence la notion de SA. Rappelez le rle d'une
SA ?
5) Le premier paragraphe du 5.1.1 fait aussi rfrence une notion de "SA bundle" ('SA bundle' :
littralement un paquet ou une liasse de SA). En effet, dans certains cas, un trafic de communication
IP est soumis plusieurs SAs, chacune d'entre elle dfinissant une transformation particulire do la
notion de SA bundle. Dans quelle circonstance enchane t'on plusieurs traitements en scurit
IPSEC? Quel intrt a-t-on alors acqurir ensemble les SA associes ?
6) On voque dans le mme paragraphe, par exemple dans la formule 'If no SAs were found
or none match, create an appropriate SA', la possibilit de cration dynamique d'une
SA. On a donc un mode statique (une SA est cre au pralable) et un mode dynamique (une SA
est cre lorsqu'un datagramme circule). Les deux modes sont adapts des rseaux de nature
diffrente. A quels types de rseaux correspondent les deux modes de cration des SAs ?
7) Comment peut-on dynamiquement crer une SA (donnez un ou des exemples de solution
technique permettant cette cration) ? Indication : le mode dynamique est principalement ralis par
les protocoles IKE/ISAKMP/OAKLEY.
-42-
Exercice 20 : IPSEC : Le protocole dchanges de cls IKE/OAKLEY

secret pr partag
La scurisation du protocole IP (Internet Protocol) seffectue dans le cadre des normes
IPSEC (IP Security). IPSEC est trs utilis industriellement en raison du dploiement norme du
protocole IP. IPSEC dfinit des mthodes pour la confidentialit, l'authentification et l'intgrit des
datagrammes IP.
Dans ce problme, nous tudions une partie importante de IPSEC associe aux protocoles
d'changes de cls. En effet un change scuris en IPSEC commence par lutilisation dun
protocole dchange de cls globalement appel IKE (Internet Key Exchange RFC 2407, 2408,
2409, 2412). IKE est considr comme un protocole de session indpendant de IP. Il fonctionne en
utilisant les services du transport UDP sur le port 500. Pour raliser ses services, IKE combine des
lments issus de protocoles diffrents.
a) La partie ISAKMP (Internet Security Association and Key Management Protocol)
dfinit un cadre gnral pour lchange de cls. ISAKMP dcrit de manire gnrique les phases
dun change de cls. ISAKMP dfinit la ngociation des mthodes de scurit utilises et la faon
de dterminer les paramtres associs aux mthodes de scurit.
De manire gnrale IPSEC donc IKE, ISAKMP etc.. sont des protocoles trs flexibles qui
offrent la possibilit d'utiliser un ensemble trs complet de mthodes de scurit. Pour lutilisateur de
nombreux choix sont donc effectuer. Ainsi un mode de fonctionnement scuris doit dfinir
diffrentes informations de politique de scurit : adresses IP autorises, ports autoriss. L'utilisateur
doit aussi choisir les fonctions cryptographiques qu'il souhaite (DES, 3DE, AES, MD5, SHA ) et
enfin les protocoles de scurit appliqus ( cls secrtes , cls publiques ). Il faut ensuite dfinir
les paramtres spcifiques qui doivent tre utiliss pour appliquer la politique retenue (valeur des
cls, etc ).
Pour spcifier tout ces choix, une association de scurit (SA Security Association) est une
structure de donnes qui stocke lensemble des paramtres associs une communication donne.
De manire schmatique, une association de scurit est dfinie par une adresse IP, le protocole de
scurit utilis, le pointeur dans un enregistrement dune base de donnes contenant lensemble des
paramtres de scurit ncessaires au bon fonctionnement du protocole.
ISAKMP dfinit deux phases successives. La phase 1 comprend la ngociation de
lassociation de scurit utilise pour les propres besoins de lchange de cl (fonctions
cryptographiques et protocoles utiliss par IKE). La phase 1 comprend ensuite un change de cls
secrtes le plus souvent ralis par le protocole de Diffie-Hellman (il existe dautres possibilits non
tudies ici). La phase 1 comporte enfin une authentification mutuelle des deux entits
communicantes.
La phase 2 du protocole ISAKMP est la phase de ngociation des associations de scurit
(SAs) utilises dans les change scuriss IP ultrieurs.
b) ISAKMP dfinit un cadre gnrique. Il faut donc dfinir des protocoles rels qui ralisent
ISAKMP. Diffrentes propositions ont t effectues pour raliser ISAKMP. On peut citer les
protocoles nomms SKIP, Photuris, OAKLEY ou SKEME qui dfinissent concrtement des
formats de messages et des rgles d'enchanement de ces messages entre deux partenaires. Nous
nous intressons ici au protocole OAKLEY qui est lun des plus utiliss.
Utilisation de cls changes manuellement en OAKLEY
-43-
Nous tudions maintenant dans ISAKMP/OAKLEY la solution de base, baptise Pre

Shared Keys. Dans cette solution, pour assurer la scurit du protocole dchange de cls, la mme
valeur d'une cl secrte PSK (Pre-Shared-Key) doit tre au pralable, affecte manuellement dans
chacune des deux entits communicantes. Par exemple, un administrateur rseau doit se connecter
successivement sur deux routeurs IP relis et installer sur chaque routeur la valeur de la cl secrte
PSK. Dautres solutions existent, par exemple une solution base sur lutilisation du chiffre cls
publiques RSA au moyen de certificats stocks dans un annuaire. Nous n'tudions pas cette solution
ici.
La phase 1 du protocole ISAKMP/OAKLEY (qui ngocie, change des cls en DiffieHellman et authentifie mutuellement) est ralise concrtement dans le cas des cls pr partages en
six messages. On appelle ce mode le mode de fonctionnement principal (main mode). Il existe un
mode annexe plus court en trois messages baptis agressive mode que nous ntudions pas ici.
Le diagramme en flches dchange des six messages montre que les deux premiers
messages permettent de slectionner les protocoles et mthodes de cryptographie utilises dans les
messages qui suivent. On y slectionne une association de scurit (une SA) utilise pour la partie
change de cls IKE. Les deux messages suivants servent pour lchange de cl de session. Les
deux derniers messages servent pour lauthentification et lintgrit. Louvreur dune communication
scurise est baptis initiateur, le site distant est baptis rpondeur (terminologie utilise dans la
norme).
Rpondeur R
Initiateur I
IP
UDP
Entte ISAKMP CKY-I
IP
UDP
Entte ISAKMP CKY-I , CKY-R
Rp : SA = une SA de la liste
IP
UDP
Entte ISAKMP CKY-I CKY-R
Cl_I
IP
UDP
Cl_R
IP
UDP
Proposition : liste de SA pour IKE
Nonce_I
Nonce_R
Identifiant_I
Hachage-I
Message chiffr en confidentialit

IP
UDP
Identifiant_R
Hachage-R
Message chiffr en confidentialit

1) Dans lentte ISAKMP du premier message, linitiateur place ce qui est appel en ISAKMP un
cookie. Il est not CKY-I. Le rpondeur agit en retournant ce cookie CKY-I et en ajoutant son
propre cookie CKY-R. On utilise ensuite le mme couple de cookies dans tous les messages. Le
choix du nom cookie et la prsence dans tous les messages indique un objectif didentification dune
communication. Les cookies doivent donc identifier de faon unique un change de cls la manire
dune rfrence de connexion. Le terme cookie est aussi associ lide de grer une approche de
-44-
fonctionnement client serveur sans tat. Rappelez la dfinition dun mode client serveur sans tat ? Le
protocole ISAKMP/OAKLEY peut-il tre sans tat (ventuellement jusqu'o) ?
2) ISAKMP indique que le cookie a surtout pour objectif de parer des attaques en dni de service
(DOS Denial of Service). On rappelle quun dni de service est obtenu quand un site (ici le
rpondeur) est soumis par un pirate des demandes en avalanche (ici des changes de cls) pour
lempcher de travailler. Gnralement cette attaque est prpare sur diffrents sites dont lintrus a
pris le contrle et ces sites sont dclanchs simultanment (flooding attack). Peu importe que les
requtes chouent. En fonction des caractristiques du protocole ISAKMP/OAKLEY, pourquoi le
rpondeur est-il sensible au problme de dni de service (ce qui justifie un mcanisme de prvention
du dni de service)?
3) Pour parer des attaques en dni de service dun rpondeur, la norme indique que le cookie
rpondeur CKY-R doit tre caractristique du site qui le gnre et vrifiable par ce site lorsquon le
lui retransmet (dans les messages ultrieurs). Il doit donc reposer sur un secret connu du site qui
gnre le cookie. On recommande dimplanter le cookie en appliquant une fonction de hachage avec
cl secrte la concatnation de ladresse IP source, IP destination, port UDP source, port UDP
destination. Pour cela on peut utiliser lun des MACs dont limplantation est obligatoire en IPSEC :
HMAC-MD5 ou HMAC-SHA-1 avec comme cl un secret choisi par le rpondeur.
Imaginez une attaque en dni de service que ce cookie empche (ventuellement des
attaques)?
4) Avec ISAKMP/OAKLEY on utilise gnralement la solution dchange de cls de DiffieHellman. On voit que l'initiateur et le rpondeur changent des valeurs Cl_I et Cl_R. Quelle sont
les valeurs dfinissant Cl_I et Cl_R selon le protocole de Diffie-Hellman que doivent schanger
linitiateur et le rpondeur dans les zones cls du troisime et du quatrime message. Quel est ensuite
le secret partag entre linitiateur et le rpondeur selon le protocole de Diffie-Hellman ? On appelle
dans la suite du problme cette valeur: cl_Diffie_Hellman.
5) Quels sont les avantages et quels sont les inconvnients de lutilisation du protocole dchange de
cls de Diffie-Hellman ?
A la suite de lchange Diffie-Hellman du troisime et du quatrime message le protocole
ISAKMP/OAKLEY dfinit alors une mthode de calcul des cls secrtes qui vont tre utilises
ensuite. En fait ISAKMP/OAKLEY ne propose pas d'utiliser directement la Cl_Diffie_hellman
mais propose de calculer des cls drives. Dans le mode cl pr-partage que nous tudions ici, la
norme indique que les deux entits calculent tout dabord une cl matresse baptise SKEYID
dfinie par la forme suivante dans laquelle la notation || dfinit la concatenation:
SKEYID = PRF (Pre_Shared_Key , Nonce_I || Nonce_R)
Dans cette formule, le sigle PRF dfinit une fonction qui est un gnrateur de nombres pseudo
alatoires (PRF est un abrg pour Pseudo Random Function). PRF peut donc tre choisi par une
implantation comme tout gnrateur de nombres pseudo-alatoires deux paramtres qui sont une
cl (pour un gnrateur cette cl servira de graine) et un message M. En fait la norme indique aussi
que PRF pourra tre le plus souvent ralise par une fonction de hachage cl secrte c'est--dire
un MAC(cl,M) (de cl secrte cl et appliqu au message M).
A partir de SKEYID (cl matresse) la norme dfinit le calcul de trois cls drives, trois cls
secrtes utilises par la suite.
-45-
- SKEYID_e est une cl secrte utilise pour protger les messages du protocole dchange
de cls IKE/ISAKMP/OAKLEY en confidentialit. On lutilise tout de suite sur les deux derniers
messages.
- SKEYID_a est une cl secrte utilise en phase 2 par lchange de cls pour authentifier ses
communications.
- SKEYID_d est une cl secrte utilise comme cl matresse pour gnrer ensuite dautres
cls secrtes qui vont protger les communications proprement dites en IP (scurit des donnes
usagers). Cest donc une cl utilise par dautres associations de scurit ngocies en phase 2
ISAKMP.
Ces cls secrtes sont dfinies comme suit :
SKEYID_d = PRF (SKEYID, cl_Diffie_Hellman || CKY_I || CKY_R || 0)
SKEYID_a = PRF (SKEYID, cl_Diffie_Hellman || CKY_I || CKY_R || 1)
SKEYID_e = PRF (SKEYID, cl_Diffie_Hellman || CKY_I || CKY_R || 2)
On voit qu'elles sont fabriques partir de SKEYID comme cl et avec un hachage de la
concatnation de la cl de Diffie-Hellman, des deux cookies et d'un entier diffrenciant les trois cls
qui est tout simplement sur un octet.
Les deux derniers messages de lchange en six messages sont ddis lauthentification et
lintgrit. Le paramtre principal est un identifiant de lmetteur du message (Identifiant_I ou
Identifiant_R selon les cas) qui est soit une adresse IP (sur 4 octets) soit un nom de domaine DNS
(FQDN Fully Qualified Domain Name). Deux mcanismes de scurit sont utiliss dans ces deux
derniers messages.
a) Les deux partenaires calculent des quantits baptises HASH_I et HASH_R selon les
formules :
HACHAGE_I = PRF (SKEYID, Cl_I || Cle_R || CKY-I || CKY-R || SA || Identifiant_I)
HACHAGE_R = PRF (SKEYID, Cl_I || Cle_R || CKY-I || CKY-R || SA|| Identifiant_R)
b) La norme indique que la charge utile du cinquime et du sixime message est chiffre en
confidentialit en utilisant la cl SKEYID_e. Donc dans le cinquime et le sixime message
lidentifiant suivi du hachage sont chiffrs au moyen du chiffre cl secrte slectionn dans
lassociation de scurit (par exemple DES, 3DES, AES) en utilisant la cl SKEYID_e.
6) Comment lauthentification mutuelle de l'initiateur et du rpondeur est elle effectue?
7) Pourquoi doit-on dans cet change de cls soccuper plus particulirement de lintgrit des
messages changs? Comment lintgrit des messages est elle obtenue ?
8) Comment le secret de la cl pr partage est-il protg ?
9) A quoi servent les nonces I et R ?
10) Quapporte le chiffrement en confidentialit des deux derniers messages ?
11) Rappelez les proprits dune bonne cl secrte. Quels sont les mcanismes dans la gnration
des cls secrtes utilises en IPSEC qui garantissent la qualit de ces cls ?
-46-
12) Quels sont les avantages et les inconvnients de ce mode de base dchange de cls pr
partages (change manuel de cls) du point de vue de ladministration de rseau (travail de
lingnieur systme rseau) ?
-47-
Exercice 21 : Scurisation des communications en Internet avec SSL-TLS

SSL (Secure Sockets Layer), est une norme de rseau qui permet de scuriser les
communications pour des applications Internet utilisant TCP/IP. SSL offre un service de
communication analogue celui des sockets mais SSL ajoute aux communications standards, des
fonctions de scurit (authentification du client par le serveur, du serveur par le client, intgrit,
confidentialit des donnes changes) et ventuellement aussi des fonctions de compression.
Dvelopp par Netscape jusqu la version 3.0 (novembre 1996), lIETF a alors adopt
SSL et a prsent sa version baptise TLS (Transport Layer Security RFC 2246 en 1998)
compatible avec SSL 3.0. Par rapport SSL, TLS offre quelques extensions mineures comme une
amlioration des signatures, diffrents traitements derreurs supplmentaires, ... En ce sens TLS 1.0
est parfois dsign comme SSL 3.1.
SSL/TLS est dcoup en deux grandes parties. La partie Handshake assure les fonctions
initiales dun change scuris. La partie Record assure les fonctions de scurit sur les donnes
utilisateur en appliquant des approches de cryptographie et de signatures dfinies pendant la phase
de Handshake. Ce problme tudie plus particulirement la partie Handshake.
La partie Handshake de SSL/TLS permet dtablir le contexte de scurisation utilis ensuite
dans la phase dchange de donnes. La partie Handshake permet lauthentification des entits
communicantes. Elle permet galement lchange de cls de session.
Un contexte de scurisation comporte :
- Un identifiant de session scurise choisi par le serveur.
- Un certificat dentit distante (optionnel).
- Une mthode de compression (si la compression est applique).
- La suite cryptographique utilise (voir plus loin).
- Une cl secrte (master secret 48 octets partags entre client et serveur).
- Une variable indiquant si la session peut couvrir plusieurs connexions TCP.
Les oprations principales du protocole Handshake sont :
1. Ngocier la suite cryptographique utilise pendant le transfert des donnes.
2. Etablir une cl de session partage entre le client et le serveur
3. Authentifier le serveur par le client (optionnel).
4. Authentifier le client par le serveur (optionnel).
En SSL/TLS une suite cryptographique est un choix relatif aux lments suivants :
- La mthode dchange de cls.
- La mthode de chiffrement utilise pendant le transfert des donnes.
- La mthode de hachage utilise pour la cration dune signature.
La mthode dchange de cls peut se faire de deux faons. Lune utilise les algorithmes
cl publique et la notion de certificat. Une autre mthode est prvue en labsence de certificats : la
mthode de Diffie-Hellman.
Le chiffrement est ralis au moyen dun algorithme cl secrte. Neuf algorithmes cl
secrtes avec des variantes sur les longueurs de cls sont possibles (DES, Triple-DES, IDEA,
etc)
La fonction de hachage sens unique (Digest Function) peut galement tre slectionne
(MD5, SHA-1)
-48-
En combinant les diffrents choix possibles dans les trois domaines prcdents, la norme
dfinit 31 suites de chiffrement cohrentes qui peuvent tre adoptes aprs ngociation.
1) Du point de vue du modle OSI on considre que SSL-TLS est de niveau session alors que
linterface socket standard nest pas de niveau session. Pourquoi ?
2) La plupart des utilisations de SSL/TLS comporte lauthentification du serveur par le client (bien
que les fonctions dauthentification soient optionnelles). Citez une application de cette
authentification. De manire gnrale pourquoi est il important dauthentifier un serveur ?
3) Pour un serveur, il est galement possible avec SSL-TLS dauthentifier le client. Citez une
application de cette authentification. De manire gnrale quelle est lutilisation de cette
authentification.
4) Le protocole SSL/TLS propose, dans lune de ses modalits, dutiliser la notion de certificat.
Cette approche est dailleurs de loin la plus souvent retenue. A quoi sert un certificat. Rappelez les
principaux champs dun certificat ?
5) La vrification dun certificat comporte diffrentes tapes. Quels sont les traitements raliser
pour vrifier un certificat ?
6) Rappelez les principes dune authentification en utilisant un algorithme cls publiques ?
Les changes du protocole Handshake sont assez complexes. En particulier ce protocole
dpend des techniques de scurisation utilises (dfinies par le contexte de scurisation ngoci). On
prsente les principaux lments du fonctionnement du protocole Handshake en omettant beaucoup
de dtails pour simplifier.
Lchange suivant est utilis en cas dauthentification dans les deux sens au moyen de
certificats. Ce protocole ngocie le contexte de scurisation, change les certificats et les valide,
construit un secret partag sur 48 octets (master secret) qui permet de fabriquer des cls de
session et il change des messages de terminaison.
Client
Serveur
ClientHello(protocolVersion, random, sessionID,Ciphersuite, compressMethod)

ServerHello(protocolVersion, random, sessionID,Ciphersuite, compressMethod)
quest
Certificate ()
CertificateRequest ()
Certificate ()
ClientKeyExchange ()
Finished()
-49-
Finished()
Explications des changes

a) La premire phase (messages ClientHello, ServerHello) correspond la ngociation du contexte
de scurisation. Le client envoie diffrentes informations proposant un contexte de scurisation
(premier message avec version du protocole SSL, un nombre alatoire, un nonce, une suite
cryptographique, une mthode de compression). Le serveur choisit les valeurs dfinitives du contexte
de scurisation acceptable en fonction de la proposition client (second message). Il fournit galement
un nombre alatoire.
b) Dans le cas dune authentification du serveur, le serveur fournit son certificat (message
Certificate). Il demande le certificat du client sil y a aussi authentification du client (message
CertificateRequest).
c) Le client valide le certificat du serveur.
d) Le client envoie son certificat au serveur. Il cre un secret au moyen dun gnrateur de nombres
alatoires (pre master secret). Le client lenvoie au serveur encrypt avec la cl publique du
serveur (message ClientKeyExchange). Le client gnre le secret partag (master secret) partir du
pre master secret et des deux nombres alatoires changs dans les deux premiers messages.
e) Le serveur valide le certificat client. Il dcrypte le secret (pre master secret) envoy par le client
au moyen de sa cl prive. Il gnre selon le mme algorithme que le client le mme secret partag
(master secret).
f) En utilisant le secret maintenant partag (master secret), le client et le serveur gnrent chacun de
leur cot la mme cl secrte de session utilisable pour des algorithmes cls prives (comme le
DES).
g) Le client et le serveur changent des messages de terminaison (Finished) chiffrs au moyen de la
cl secrte de session. Ces messages indiquent que le protocole de Handshake est termin et que les
changes auront lieu partir de maintenant en utilisant le contexte de scurit ngoci. Ces messages
doivent tre dchiffrs et vrifis.
7) Quels sont les mcanismes du protocole Handshake qui assurent lauthentification du serveur vis
vis du client?
8) Le protocole SSL utilise une combinaison de mthodes de cryptographie qui comprend des
algorithmes cls publiques et des algorithmes cls prives. Pourquoi utiliser concurremment les
deux techniques?
-50-
Exercice 22 : Commerce lectronique sur Internet (SET "Secure

Electronic Transactions")
Pour scuriser le commerce lectronique sur Internet le standard SET a t propos en
1996/1997. Il est soutenu par les principaux groupements de cartes bancaires Visa et Master Card
ainsi que par de nombreux fournisseurs (IBM, Microsoft, ...). SET propose un ensemble de
protocoles de scurit pour le paiement par carte bancaire sur Internet. Il utilise pour cela des
techniques de cryptographie ( cls publiques RSA, cls secrtes DES, de fonction de hachage
SHA-1). C'est une solution purement logicielle.
Une vision simplifie de l'architecture de SET est donne par la figure suivante ou
apparaissent les diffrents calculateurs de l'acheteur, du marchand, des banques ainsi qu'une
passerelle faisant interface entre le monde Internet (utilisant le protocole SET) et le rseau bancaire.
Banque
du marchand
Banque
de l'acheteur
Rseau du
groupement
bancaire
(architecure
Internet ou autre)
Passerelle
de paiement
Serveur
du marchand
PC
de l'acheteur
Rsau des utilisateurs
(architecture Internet avec
protocoles SET)
Le fonctionnement de base est analogue celui des cartes de crdits habituelles. L'acheteur
connecte son poste de travail sur le serveur du marchand. Il consulte le catalogue des produits
proposs, passe commande et autorise le paiement. Le marchand accepte la commande et la ralise.
Le marchand pour se faire payer adresse sa banque l'autorisation de paiement de l'acheteur via la
passerelle de paiement. On trouve donc trois protocoles essentiels dans SET:
- Le protocole d'achat.
- Le protocole d'autorisation de paiement.
- Le protocole de paiement
Voici (parmi de nombreuses autres) quelques rgles de scurit de base que les protocoles
SET doivent respecter :
a) L'acheteur et la passerelle de paiement doivent pouvoir vrifier que le marchand est bien
celui qu'il prtend tre. Le marchand doit pouvoir vrifier que l'acheteur et la passerelle de paiement
sont bien ceux qu'ils prtendent tre.
b) Une personne non autorise ne doit pas pouvoir modifier les messages changs entre le
marchand et la passerelle de paiement.
c) Le marchand ne doit pas pouvoir accder au numro de la carte de l'acheteur.
d) Le banquier na pas connatre la nature de la commande passe par lacheteur au
marchand.
-51-
1) Les problmes de scurit associs aux rgles a) b) c) prcdentes sont des problmes gnraux
traits en cours. Donnez pour les rgles a) puis b) puis c) les noms des problmes associs.
Rappelez de manire succincte la dfinition de ces problmes (en une phrase).
SET est un protocole applicatif, qui dfinit une politique de scurit. A partir des lments
prcdents on cherche spcifier cette politique
2) Quels sont les quatre rles qui doivent tre considrs ?
On dfinit les objets suivants
a)
b)
c)
d)
e)
f)
La carte bleue
Le PIN code de la carte bleue ("Personal Identification Number", le code secret)
Le numro de la carte bleue
L'identifiant de la commande
Le contenu qualitatif de la commande (sa nature)
Le prix de la commande
Selon le cas on dfinit pour les objets prcdents une ou plusieurs des mthodes suivantes:
A. Crer
B. Lire (connatre la donne)
C. Accepter (signer la donne)
3) Pour chaque objet donnez les mthodes applicables (A, B ou C)
4) Etablir la matrice des droits: Il s'agit d'une matrice ayant en colonne (au nombre de 13) les
mthodes et en ligne (au nombre de 4) les rles. Si un rle X a le droit d'utiliser la mthode y
l'lment X,y est marqu 1 et n'est pas marqu sinon.
Pour mettre en oeuvre les protocoles de scurit utilisant la cryptographie SET dfinit une
phase d'accrditation pralable des acteurs par une autorit de certification (en fait une hirarchie
d'autorits).
Autorit de certification
Acheteur
Passerelle
de
paiement
Marchand
Vue globalement, l'autorit de certification dlivre des certificats aux diffrents acteurs des
protocoles SET.
5) Qu'est ce qu'un certificat? Quelles en sont les proprits principales?
6) On tudie maintenant le processus d'achat. Il se droule en deux changes requtes rponses
successifs.
Premier change (l'change initial)
-52-
La requte initiale de l'acheteur vers le marchand indique simplement en clair l'intention par
l'acheteur de passer commande.
La rponse initiale du marchand comporte trois lments:
- un identifiant de commande plus sa signature numrique
- le certificat du marchand avec sa cl publique
- le certificat de la passerelle de paiement avec sa cl publique.
A la suite de ce premier change, quelles vrifications peuvent tre effectues par l'acheteur ?
7) Le second change du processus d'achat comporte l'envoi de la requte d'achat et une rponse
d'accus de rception de commande.
Envoi de la requte d'achat
L'acheteur construit la structure de donne commande qui a vocation a tre communique au
marchand (produits, quantits, prix avec l'identification de la commande fournie par le marchand
pendant l'change initial...). Elle est baptise par la suite OI ("Order Information").
L'acheteur construit la structure de donnes de paiement qui a vocation a tre communique
la passerelle de paiement (informations concernant la carte bancaire de l'acheteur et identification
de la commande payer fournie par le marchand pendant l'change initial). Elle est baptise dans la
suite PI ("Payment Information").
En fait les deux structures de donnes sont lies. Le paiement ne concerne que la commande
identifie. Il doit tre effectu que si la commande est accepte par le marchand. La commande n'est
effective que si la banque approuve le paiement. De plus le contenu de la commande doit tre cach
la banque et le contenu des instructions de paiement doit tre cach au marchand.
Pour lier les deux structures de donnes, l'acheteur calcule par l'algorithme SHA-1 la
fonction de hachage de chacune des structures de donnes SHA-1(OI) et SHA-1(PI). Il applique
nouveau la fonction de hachage SHA_1 l'ensemble (SHA-1(OI), SHA-1(PI)) des fonctions de
hachage concatnes. Il chiffre cette dernire empreinte en RSA avec sa cl prive. C'est en fait une
signature numrique double qui est ralise. Elle est baptise dans la norme SET signature duale.
Signature duale =
{{{OI }
, {PI }SHA1}SHA1
SHA1
clef _ prive _ acheteur

RSA
Le message suivant est prpar pour la passerelle de paiement:

PI, Signature duale
L'acheteur choisit une cl alatoire cl_ala pour le DES. Le message a destination de la
passerelle de paiement est chiffr en DES au moyen de cette cl.
_ala
{PI, Signatureduale}cl
DES
La cl DES est chiffre au moyen de la cl publique de la passerelle arrive avec le certificat
de la passerelle.
_ PUBLIQUE_ PASSERELLE
{cl _ ala}CLEF
RSA
Finalement le message de requte d'achat envoy au marchand contient toutes les
informations suivantes:
_ala
{PI, Signatureduale}cl
,
DES
{PI}SHA1 ,
_ PUBLIQUE_ PASSERELLE
{cl _ ala}CLEF
,
RSA
OI,
Signature duale,
Certificat de l'acheteur.
-53-
Envoi de la rponse du marchand la requte d'achat

Le marchand construit un message de rponse qui a comme unique signification d'tre un
accus de rception de la commande. Le marchand signe numriquement ce message (fonction
SHA_1 et chiffre RSA avec sa cl prive). Il ajoute l'ensemble son propre certificat.
7.1) Comment le marchand vrifie t'il l'intgrit de la commande OI?
7.2) Comment est ralise la confidentialit des informations concernant la carte de crdit vis vis
du marchand?
7.3) Comment le marchand vrifie t'il que l'acheteur est bien celui qu'il prtend tre?
-54-
Exercice 23 : Authentification des usagers et autorisation des requtes

dans le WEB
Le World Wide Web a tout dabord t conu comme un outil de diffusion de documents
publics de sorte que peu defforts ont t effectus au dpart pour contrler laccs aux informations
offertes. Comme de plus en plus dinformations et surtout de services ont t distribus au moyen du
WEB, des outils de scurit ont t proposs pour satisfaire les besoins qui sont apparus. Ce sujet
examine des solutions successives qui ont t dveloppes dans le cadre du protocole HTTP pour
rpondre aux besoins dauthentification des usagers et dautorisation des requtes quils mettent.
La version 1.0 du protocole HTTP (HTTP/1.0 RFC 1945 mai 1996) propose un
mcanisme de base de contrle daccs utilisant une authentification mot de passe (mcanisme
basic).
Si un utilisateur client requiert une page protge dun serveur WEB sans fournir de couple
usager, mot de passe, il reoit en rponse un code derreur 401 (unauthenticated). Sur rception
de ce diagnostic le navigateur du client demande alors lutilisateur un nom dusager autoris et son
mot de passe au moyen dun dialogue interactif dans une fentre. Lorsquune rponse est fournie le
navigateur client rmet la requte vers le serveur avec les informations usager:mot_de_passe.
Lorsque lon met sur le rseau une requte avec le couple nom dusager et mot de passe, ces
informations sont codes mais non cryptes (enregistrement de la requte baptis Authorization).
La mthode de codage en format texte ascii employe est baptise Base64. Elle consiste
essentiellement dcouper les informations par groupes de 6 bits et reprsenter les groupes de 6
bits par un caractre ASCII. Par exemple si on souhaite transmettre le couple usager:mot_de_passe
"Aladdin:open sesame", il apparat dans la requte une ligne de la forme :
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
De la sorte, si les mots de passe ne sont pas immdiatement lisibles dans les requtes
(human readable), il sont facilement dcodables par un programme de dcodage et peuvent donc
tre connus de tout le monde (les mots de passe ne sont pas crypts).
1) Quels sont les avantages et les inconvnients en termes de scurit et de cot de mise en uvre
dune telle approche dauthentification ?
Le serveur WEB autorise une requte en consultant des fichiers crs par ladministrateur du
serveur. Nous reprenons ici la protection de pages WEB par rpertoires telle quelle est dfinie dans
le cadre de loutil NCSA Mosaic et reprise en version trs voisine dans le serveur Apache. Le
systme dexploitation est le systme UNIX.
Supposons que ladministrateur dun serveur WEB souhaite protger un rpertoire
(baptisons le /mydir/turkey) contenant des pages WEB. Il doit crer dans ce rpertoire un fichier
dont le nom par dfaut est .htaccess. Un exemple de fichier .htaccess est le suivant:
AuthUserFile /otherdir/.htpasswd
AuthGroupFile /dev/null
AuthName ByPassword
AuthType Basic
<Limit GET PUT>
require user daniel
</Limit>
-55-
Dans la premire ligne de ce fichier on dcrit o se trouve le fichier des mots de passe. Il est
ici baptis /otherdir/.htpasswd (cest un fichier qui a pour nom .htpasswd et qui se trouve dans le
rpertoire otherdir). La seconde ligne indique quil nexiste pas de protection daccs au niveau
groupe dutilisateurs, ce qui est indiqu par le fait que le fichier des protections de groupe est un flot
vide (/dev/null). La chane associe la troisime ligne (mot cl AuthName) peut tre arbitrairement
choisie par ladministrateur. Elle dfinit le nom du domaine auquel sapplique la politique de
protection. Ce nom est transmis par le serveur au navigateur et il est affich lors des demandes de
mots de passe. Il permet lusager de savoir quel nom dusager et quel mot de passe fournir (en
fonction du domaine accd). Ici le nom du domaine est un nom passe partout Bypassword. La
ligne AuthType (type dauthentification) dfinit le protocole dauthentification comme tant Basic
cest--dire celui que nous tudions ici. Dautres authentifications sont utilisables (PGP,
KerberosV4, KerberosV5, ou Digest que nous examinons plus loin). On voit ensuite que dans ce
fichier exemple seules les requtes GET et PUT sont autorises (enregistrement Limit GET PUT).
On aurait pu dfinir ici une authentification pour dautres oprations du protocole HTTP. Ici,
lautorisation est prvue uniquement pour lusager daniel.
Il faut bien sur crer le fichier /otherdir/.htpasswd de mots de passe. Il contient des
enregistrements de la forme usager:mot_de_passe. Les serveurs WEB disposent doutils pour crer
simplement par des dialogues interactifs ces fichiers de protection.
2) On suppose que ladministrateur du serveur WEB doit protger dautres pages WEB qui ont t
cres dans un autre rpertoire /mydir/goose. Ces pages appartiennent un nouveau domaine
baptis realm. Ladministrateur souhaite protger laccs ces pages WEB en autorisant lusager
daniel pour les oprations GET, PUT et POST , et lusager laurent uniquement pour les requtes
GET sur ces nouvelles pages. Quels sont les fichiers qui doivent tre crs et quel endroit doivent
til se trouver?
Quand on ralise un service daccs distant en rseau comme telnet ou de transfert de
fichiers comme ftp, on commence par une ouverture de connexion (login process) pendant laquelle
on ralise une authentification de lusager. Cette authentification demeure effective pendant toute une
priode considre comme formant un tout du point de vue de la protection. Pendant une telle
session un usager peut raliser un ensemble doprations puis fermer la session quand bon lui
semble.
3) Le protocole HTTP est il conu selon le principe prcdent, cest dire que laccs un
ensemble de pages, dimages dun serveur forme un tout ou bien chaque accs est-il considr
comme indpendant des autres comme cest le cas pour un serveur sans tat (le serveur est il avec
ou sans tat) ?
4) Quelles sont les consquences du choix prcdent relativement au problme dauthentification
(quelle technique peut-on proposer cot navigateur client pour simplifier la vie de lusager sa
console) ?
A la version 1.1 du protocole HTTP (HTTP/1.1 RFC 2068 janvier 1997) est associe un
autre protocole dauthentification baptis message digest authentication dfini par la RFC 2069
janvier 1997. Des amliorations ont encore t apportes au protocole de la version digest par la
RFC 2617 juin 1999.
On dfinit ici les principes gnraux de la solution sans entrer dans les dtails. Lorsquune
rponse dun serveur WEB une requte dun navigateur client est un rejet (code 401
unauthenticated), la rponse du serveur contient un champ particulier baptis nonce qui contient
-56-
une valeur alatoire la discrtion du serveur. Ce message de rejet devient alors ce que lon appelle
un challenge. Au lieu de rpondre par le nom dusager et le mot de passe, le navigateur client doit
alors rpondre par un nom dusager et la place du mot de passe la valeur :
MD5( concat ( nom dusager, mot de passe, nonce ) )
Dans lexpression prcdente, concat dsigne loprateur de concatnation. On voit donc
que le navigateur ayant obtenu un nom dusager et un mot de passe doit fabriquer un texte qui
concatne le nom dusager, le mot de passe et le nonce. Ensuite il lui applique la fonction MD5 qui
dfinit une fonction de hachage sens unique. Le rsultat est la valeur transmise ( la place du mot
de passe).
La RFC 2069 propose dutiliser par dfaut dans le protocole dauthentification de type
digest la fonction MD5 (Message Digest version 5). Dautres fonctions de hachage sens unique
peuvent tre ngocies.
5) Comment le serveur WEB ralise la vrification de lautorisation daccs une page
WEB protge (le navigateur client ayant envoy une requte avec nom dusager, MD5( concat (
nom dusager, mot de passe, nonce ) ) comme expliqu plus haut) ?
6) Pourquoi avoir appliqu la fonction MD5 au mot de passe et en mme temps au nonce (quest ce
que cela apporte en termes de scurit) ?
7) La mthode de vrification permet-elle de stocker les mots de passe dans le fichier des mots de
passe sous une forme crypte (comme dans les fichiers de mot de passe daccs un systme
UNIX) ou bien doit-on avoir sur le serveur le fichier des mots de passe en clair ? Quelle est la
consquence relativement la scurit de la mthode?
La valeur du nonce dpend de limplantation du serveur (implementation dependent). La
norme suggre nanmoins pour assister les implanteurs de serveurs WEB une valeur de nonce qui
peut-tre recalcule, de manire ce que la valeur obtenue soit identique (presque toujours) entre un
challenge et sa rponse.
Nonce = MD5 ( concat (adresse_IP, ":", estampille , ":", cl_prive) )
Adresse_ip est ladresse IP de la machine du client.
Estampille est une valeur dpendante du temps qui ne change pas trs souvent.
Cl_prive est une valeur secrte du serveur.
8) Pourquoi choisir une estampille temporelle qui ne change pas trs souvent ? Quel est le risque
encouru par cette mthode?
9) Pourquoi avoir choisi dintroduire dans le nonce ladresse IP du client, une estampille temporelle,
un secret (en quoi le choix des valeurs utilises dans le nonce limite til le risque encouru) ?
-57-
Exercice 24 : Scurisation du courrier avec S/MIME

S/MIME ('Secure/Multipurpose Internet Mail Extensions') dfinit un ensemble de standards
pour transmettre de manire scurise des documents au format MIME.
1) Rappelez l'objectif poursuivi par la dfinition du format MIME. Citez deux grandes applications
de l'Internet qui utilisent le format MIME.
S/MIME offre les grandes catgories de services de scurit suivantes: authentification,
intgrit, non-rpudiation, confidentialit. Pour cela il permet de transfrer de nouveaux types
d'attachements qui sont des parties scurises. Une partie scurise est elle mme une partie MIME
(En tte + corps). On distingue trois types de parties dans le domaine de la scurit pour lesquelles
le standard dfinit un format prcis (CMS Cryptographic Message Syntax en S/Mime version 3):
Partie signer ou chiffrer ('data')
Partie chiffre ('envelopped data')
Partie composant la signature dun texte en clair ('siagned data')
2) A quoi sert chaque nouveau type ?
Un document sign est dcrit en ASN1 par la dfinition suivante :
SignedData ::= SEQUENCE {
version Version,
digestAlgorithms DigestAlgorithmIdentifiers ,
contentInfo ContentInfo,
certificates [0] IMPLICIT ExtendedCertificatesAndCertificates OPTIONAL,
crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos }
3) Que peuvent contenir et quels sont les usages des variables dont les types sont:
DigestAlgorithmIdentifiers
ExtendedCertificatesAndCertificate
CertificateRevocationLists
4) Lorsque l'on transmet un document chiffr il est possible de le compresser galement. Dans quel
ordre effectue t'on les oprations: chiffrer, compresser, encoder en ASCII? (Justifiez votre rponse).
-58-
Exercice 25 : Scurisation du DNS : les normes DNSSEC-1

De nombreuses attaques dans le rseau Internet sont conduites en utilisant les faiblesses en
matire de scurit du DNS dans sa version de base (non scurise). En effet, cette version qui est
encore pratiquement la seule utilise ne possde aucun mcanisme de contrle dintgrit ou
dauthentification. Par exemple, si un attaquant arrive modifier les informations fournies par un
serveur DNS ou par un cache DNS, il peut remplacer ladresse dune machine rendant un service
normal par ladresse dune autre machine contrle par lui. Avec cette nouvelle machine qui va
recevoir toutes les requtes, un pirate peut raliser diffrents types dattaques (espionnage,
dguisement, attaque par le milieu).
Lun des problmes essentiels tous les niveaux dans le DNS est donc le maintien de
lintgrit des informations gres et transmises par les diffrentes entits DNS. Cest lobjet de
propositions runies sous le nom densemble DNSSEC (pour DNS SECurity extensions). Les
normes DNSSEC sont encore en volution. Nous tudions dans ce problme leur premire version.
1) Dans le DNS rappelez le rle des diffrentes entits communicantes suivantes: serveur primaire,
serveur secondaire, cache et rsolveur ?
2) Rappelez les grandes lignes des diffrents protocoles de communications que le DNS dfinit entre
les diffrentes entits prcdentes : serveur primaire, serveur secondaire, cache et rsolveur.
TSIG (Transaction Signature RFC 2845)
Lune des solutions, propose pour la scurisation du DNS dans le cadre DNSSEC, est
baptise TSIG. TSIG sapplique aux messages changs par les protocoles DNS en dfinissant une
signature ajoute ces messages. TSIG permet dauthentifier lentit DNS mettrice et permet de
signer en intgrit des donnes fournies par cette entit DNS en utilisant une fonction de hachage et
une mthode de cryptographie symtrique ( cl secrte).
Pour les besoins du protocole TSIG, on rajoute deux informations dans chaque message mis. Tout
dabord on rajoute la date et lheure de lmission du message (chaque message est horodat au
moyen de lhorloge temps rel de la machine mettrice). On rajoute surtout dans chaque message
protg, une signature calcule au moyen de la cl secrte et d'une fonction de hachage scuritaire
selon la mthode HMAC sur laquelle nous revenons plus loin.
La RFC recommande dutiliser une cl secrte par paire de communicants. Pour distinguer les
diffrentes cls utilises, chaque cl possde un nom logique qui doit tre connu de lmetteur et du
destinataire. Ce nom est transmis dans chaque message scuris afin de dterminer la cl utilise
lmission et utiliser par le rcepteur.
3) Compte tenu des principes gnraux de fonctionnement de TSIG qui viennent dtre dcrits, entre
quelles entits communicantes dans le DNS le protocole TSG vous semble til le mieux adapt
(justifiez votre rponse) ?
4) Pourquoi le protocole TSIG a-t-il prvu un horodatage des messages au moyen de la date et de
lheure dmission de chaque message? Quel contrle est effectu par un rcepteur de message?
Expliquez pourquoi le champ d'horodatage doit tre sign ?
-59-
5) Quelles proprits doivent vrifier les horloges de chaque entit DNS pour que les contrles
d'horodatage soient efficaces? Quel protocole complmentaire TSIG doit on absolument mettre en
uvre pour que lhorodatage fonctionne correctement ?
De manire gnrale on appelle en scurit MAC (Message Authentication Code), une
information rajoute un message qui sert de signature en intgrit en utilisant une fonction de
hachage et une cl secrte. HMAC signifie Keyed-Hashing Message Authentication Code. HMAC
est une mthode particulire de construction dun MAC. HMAC est dfini par la RFC 2104. Cest
une mthode de signature assez largement utilise (IPSEC, SSL, DNSSEC).
Pour construire une signature HMAC on utilise une cl secrte note K et une fonction de hachage
de scurit note H. Il peut sagir par exemple de MD5 ou de SHA-1. De la sorte on a des
HMAC-MD5 ou des HMAC-SHA-1.
Comme H nest pas unique on note B le nombre doctets gnr pour chaque hachage (par exemple
avec des condenss de 128 bits on a donc B=16 octets).
Si la cl K est trop courte (elle fait moins de B octets) on la complte avec des 0. Si la cl K est
trop longue elle est tronque B octets par application de la fonction H.
0n dfinit deux chanes de B octets utilises pour faire du bourrage (padding):
Ipad = 0x36 rpt B fois (l'octet 36 en hexadcimal rpt B fois).
Opad = 0x5C rpt B fois (l'octet 5C en hexadcimal rpt B fois).
La signature HMAC pour un message M est donne par:
HMAC(M) = H ( K XOR Opad || H ( K XOR Ipad || M ) )
Dans lexpression prcdente, XOR est loprateur de ou exclusif. La double barre || indique la
concatnation.
De manire expliciter autrement la signature HMAC on peut encore dire quelle est obtenue au
moyen des tapes suivantes de calcul:
A. Si K fait plus de B octets calculer K = H(K).
B. Si K fait moins de B octets ajouter des 0 K de faon ce que K soit de longueur B.
C. Calculer K XOR Ipad.
D. Concatner le message M au rsultat de 3.
E. Appliquer H au rsultat de 4.
F. Calculer K XOR Opad.
G. Concatner le rsultat de 5 au rsultat de 6.
H. Appliquer H au rsultat de 7.
6) La cl K est une cl secrte. Quelles prcautions doit-on prendre concernant sa longueur, sa
gnration et son stockage?
7) Sur quelles proprits de H reposent la scurit du mcanisme de signature en intgrit HMAC?
8) Rappelez la mthode classique de signature vue en cours? Quel est l'avantage de HMAC en
terme de performance par rapport la mthode classique de signature?
Nouveaux enregistrements ressources KEY, SIG (RFC 2535 2539)
Une autre solution propose dans le cadre DNSSEC pour lauthentification et lintgrit
repose sur la cration de deux nouveaux types denregistrements ressources (KEY et SIG) qui
peuvent tre stocks dans une base de donnes DNS.
Lenregistrement KEY a pour objectif de stocker des cls selon un format propre au DNS.
Comme lutilisation de cls ne concerne pas uniquement le DNS, lenregistrement KEY peut aussi
-60Exercices UE Scurit et Rseaux
servir pour dautres protocoles de scurit (au niveau rseau avec IPSEC, au niveau transport avec
TLS ou au niveau application avec SMIME).
La structure de lenregistrement KEY est la suivante :
{Nom , TTL, Classe=IN, Type=KEY, (Indicateurs, Protocole, Algorithme, Valeur de cl)}
- Un nom denregistrement KEY peut appartenir diffrents types permettant diffrentes
utilisation de la cl. Dans le cas le plus usuel (scurisation du DNS), il sagit dun nom de zone
DNS pour lequel on dfinit une cl (par exemple cnam.fr). Un nom denregistrement KEY peut
galement tre un nom de machine ou un nom dutilisateur.
- Les indicateurs (flags) dfinissent diffrents champs prcisant lutilisation de la cl (quel est le
type du champ nom, )
- Le champ protocole dfinit le protocole de scurit utilisant la cl (par exemple 3 : DNSSEC,
)
- Le champ algorithme dfinit lalgorithme de chiffrement auquel est destin la cl (par exemple 3 :
DSA ).
- La valeur de la cl (code au format base 64).
Lenregistrement ressource SIG est plac aprs un enregistrement ressource donn. Il
contient une signature pour cet enregistrement ressource. La technique de signature est la technique
habituelle (ce nest pas une signature HMAC). De la sorte, on peut interroger un serveur DNS sur
un enregistrement ressource (mode de fonctionnement de base) mais on peut aussi demander la
signature de cet enregistrement ressource. Pour amliorer les performances on peut aussi enregistrer
une signature pour un ensemble denregistrements ressources.
La structure de lenregistrement SIG est la suivante :
{Nom , TTL, Classe=IN, Type=SIG, (Type de lenregistrement sign, Algorithme, TTL dorigine,
Date dchance, Date de signature, Empreinte de la cl, Autorit signatrice, Signature)}
- Type de lenregistrement sign (par exemple SOA).
- Champ algorithme (dfinit les algorithmes utiliss pour gnrer une signature).
- TTL dorigine (dfinit le TTL de lenregistrement sign).
- Date d'chance (la date limite dutilisation dune signature).
- Date de signature (dfinit la date de cration de la signature).
- Empreinte de la cl (dfinit un rsum, une empreinte de la cl utilise).
- Autorit ayant sign (dfinit le nom de lautorit qui a gnr la signature).
- Valeur de la signature (code au format base 64).
9) A quel type dalgorithme de chiffrement est selon vous destin lenregistrement KEY.
10) Avec les nouveaux enregistrements KEY et SIG comment se passe une requte daccs
scurise dans le DNS?
11) Les enregistrements KEY sont des enregistrements ressources qui peuvent tre protgs aussi
par un enregistrement SIG ? A quoi sert lenregistrement SIG dans ce cas ?
12) Une ide qui a t propose pour vrifier une cl est dutiliser la hirarchie de nommage du
DNS comme hirarchie des autorits de certification. Selon cette approche comment fonctionnerait
alors la vrification dune cl (par exemple si un enregistrement est sous l'autorit d'une zone
iie.cnam.fr, quels sont les niveaux d'autorits impliqus dans le contrle de cet enregistrement, quels
sont les contrles raliss par le destinataire)?
-61-
13) Les champs date dchance de signature et date de signature de lenregistrement montrent que
la validit dune signature dpend du temps. Pourquoi? Quel protocole est indispensable pour
valider correctement les signatures ?
-62-
Exercice 26 : Scurisation DNS : Difficults en DNSSEC-1, les normes

DNSSEC-2
Les normes DNSSEC (Domain Name System SECurity) dfinissent un ensemble
dextensions au DNS pour en assurer la scurit. Actuellement DNSSEC agit essentiellement en
garantissant lintgrit des donnes obtenues en rponse une requte. DNSSEC scurise
galement certaines oprations systmes attaches larchitecture DNS comme les transactions de
mise jour dynamique ou le transfert, entre serveurs primaires et secondaires, de la base de donnes
relative une zone. On rappelle quune zone est une partie de larborescence du DNS. La notion de
zone correspond lide de dlgation de la responsabilit dans la fourniture des rponses une
requte. La responsabilit pour une zone est dlgue par la zone parente une autorit qui
administre une zone fille c'est--dire un ensemble de noms de domaines ayant comme prfixe le nom
de domaine de la zone parente. La zone fille met en uvre un ensemble de serveurs fournissant au
reste de lInternet les informations DNS relatives cette zone. Les zones sont donc disjointes.
Nous nous intressons dans ce texte la garantie de lintgrit. DNSSEC utilise pour cela
uniquement la cryptographie clefs publiques RSA dans le cadre de signatures RSA des donnes
gres par le DNS. Chaque zone va donc devoir disposer dune paire de clefs (cls prives et cls
publiques). De sorte que DNSSEC doit rsoudre galement les problmes du stockage des cls et
de la distribution des clefs publiques.
Rappels DNSSEC - 1
La premire version DNSSEC - 1 (RFC 2535) adopte une approche assez naturelle pour la
gestion des cls. En DNSSEC - 1, un couple cl prive, cl publique permet de signer puis de
vrifier les informations relatives une zone. On associe une signature chaque RR (Resource
Record ou enregistrement ressource) mais pour tre plus efficace on signe aussi des RRsets c'est
dire des ensemble denregistrements ressources qui ont le mme nom et le mme type mais des
valeurs diffrentes. Ces RR regroups sont habituellement transfrs ensemble comme par exemple
la liste de tous les serveurs de courriers dans un domaine. Les signatures sont stockes comme les
enregistrements ressources dans la base de donnes de zone au moyen dun nouveau type
denregistrement ressource cr pour DNSSEC: le RR SIG. Outre la valeur dune signature,
lenregistrement SIG comporte le nom du domaine possesseur de la cl ayant servi construire la
signature.
La cl publique utilise qui permet de vrifier une signature est stocke dans un autre
nouveau type d'enregistrement ressource cr pour DNSSEC : le RR KEY. Le RR KEY est lui
aussi sign par un RR SIG.
Pour vrifier lintgrit dun enregistrement DNS, les deux enregistrements prcdents (SIG
et KEY) le concernant peuvent tre obtenus par des requtes DNS habituelles.
1) Le problme qui se pose alors est celui de valider la cl publique qui permet le contrle dune
signature. On suppose tout d'abord quune zone choisit elle-mme son couple cl publique, cl
prive et quelle signe elle-mme au moyen de sa cl ses enregistrements ressources et sa cl
publique (solution dite dauto signature pouvant tre adopte au dbut du dploiement de
DNSSEC). Comment un client peut-il valider une signature dans ce mode d'auto signature ? Vous
rappellerez les solutions que vous connaissez de distribution des cls publiques. Vous les valuerez ?
-63-
2) Pour la mise en uvre des signatures DNSSEC, on suggre quelquefois quil est prfrable
dutiliser des cls plutt courtes. Pourquoi cette proposition (discutez en les avantages et les
inconvnients) ?
3) Quand des cls sont courtes quelle prcaution doit-on prendre ?
Il est apparu trs naturel, en raison de lexistence de la hirarchie de nommage du DNS,
dassocier une chane de certification larbre du DNS. Lide de base pour le fonctionnement des
signatures devient la suivante. La zone parente doit signer la cl publique dune zone fille.
4) En cas de renouvellement frquent des cls, quel problme se pose alors ?
Pour certaines requtes DNS la rponse est ngative en ce sens que l'information demande
n'existe pas. Il ny a pas de rponse quand une requte porte sur des noms inexistants ou sur des
types denregistrements qui n'ont pas t dfinis pour un nom de domaine qui existe par ailleurs. Une
rponse ngative est significative et usurper une telle rponse peut permettre des attaques. Un
nouveau type denregistrement dans le DNS baptis NXT a t cr. Les enregistrements NXT sont
insrs dans un fichier de zone entre les enregistrements correspondants deux noms (do le sigle
de next, le prochain). Un enregistrement NXT est associ un nom de domaine. Il contient la liste
des diffrents types de RR qui sont renseigns pour ce nom de domaine et il pointe sur le prochain
nom de domaine figurant dans le fichier de zone. Le dernier nom de domaine de la zone pointe sur le
premier nom de sorte quune base de donnes de zone est aussi une liste circulaire.
5) Quelle prcaution doit-on prendre relativement lordre des enregistrements ressource dans une
base de donnes de zone.
6) Avec lenregistrement NXT quels sont les problmes de confidentialit qui se posent du point de
vue de la diffusion des informations concernant larchitecture informatique dune entreprise ?
DNSSEC - bis (DNSSEC - 2)
A la suite de lexprimentation de DNSSEC version 1, diffrents problmes ayant t
relevs. Une nouvelle version a t propose et adopte (RFC 4033), de sorte que pour viter toute
ambigut les enregistrements ressources utiliss par la version 2 portent des noms diffrents de ceux
de la version 1 : SIG est devenu RRSIG, KEY est devenu DNSKEY, NXT est devenu NSEC.
Nous tudions ici une seule modification importante. On propose en version 2 que chaque zone
dispose de deux sortes de cls pour les chiffrements RSA. Ces cls seront donc a priori diffrentes
moins de leur donner la mme valeur mais on ne gagne plus rien.
Les cls baptises ZSK (pour 'Zone Signing Key') dsignent les clefs utilises pour la
signature de pratiquement tous les types d'enregistrements ( une exception qu'on va voir). En ce
sens une cl ZSK est analogue la cl utilise en signature dans la version DNSSEC -1 (une cl
stocke dans l'enregistrement KEY).
Les clefs baptises KSK ('Key Signing Key') servent dans la construction de la chane de
confiance. Elles ne signent que d'autres cls. La KSK d'une zone est signe par la ZSK de la zone
parente. Elle sert principalement signer la ZSK de la zone.
La chane de confiance est alors assure par la cration d'un nouvel enregistrement ressource
baptis DS pour 'Delegation Signer'. Un enregistrement DS est localis dans une zone parente pour
crer un lien de scurit avec une zone fille. DS contient une signature de la KSK de la zone fille
(c'est--dire un hachage de la KSK de la zone fille chiffr par la ZSK de la zone mre).
-64-
7) Avec cette solution pourquoi devient-il beaucoup plus facile de changer de cl ZSK dans une
zone ?
8) On suggre quavec DNSSEC bis les cls KSK doivent tre longues. Pourquoi ?
9) Quels sont les inconvnients de cette solution ? Indication : listez les oprations raliser.
-65-
Exercice 27 : DNS et Messagerie Internet SMTP, lutte contre le courrier

non sollicit
Diffrentes mthodes de lutte contre le courrier non sollict (spam) ont t proposes.
Dans ce problme, nous tudions deux de ces mthodes qui sont bases sur les relations entre la
messagerie SMTP et le service de nom de domaines DNS.
Dans ce texte, une entreprise connecte lInternet possde un nom de domaine (comme
par exemple fai.com..). Cette entreprise gre un service de courrier lectronique au moyen de
diffrents serveurs de messagerie SMTP. Un hte de lInternet, dont ladresse IP est a.b.c.d et dont
le nom de domaine DNS est hote.domaine.. , utilise le protocole SMTP pour envoyer un courrier
lectronique un destinataire dadresse usager@fai.com.
1) Dans le DNS rappelez la dfinition de la notion denregistrement ressource (RR Resource
record) ?
2) A quoi servent les types denregistrements A et MX ?
3) Quelles sont les actions que doit raliser un client SMTP (qui tourne par exemple ici sur
hote.domaine..) pour localiser un serveur de courrier avant de commencer les changes SMTP (ces
actions impliquent essentiellement le DNS) ?
Pour viter une partie des courriers non sollicits (spam) certaines entreprises pour
effectuer une premire catgorie de vrifications simples imposent les deux rgles suivantes.
a) Tout hte de lInternet qui expdie des courriers lectroniques un serveur de courrier
doit avoir obligatoirement un enregistrement ressource de type PTR dans sa base de donne DNS
permettant deffectuer une recherche inverse.
b) Le nom de domaine dun hte metteur de courrier doit possder un enregistrement
ressource de type A.
4) Comment lenregistrement ressource de type PTR est il utilis dans le DNS pour raliser une
recherche inverse ?
5) Quelles sont les informations dont dispose un serveur SMTP pour identifier lmetteur dun
courrier lectronique quil vient de recevoir (trois informations)?
6) Quelle sont les vrifications que veut effectuer un serveur SMTP dune entreprise comme fai.com
qui impose aux metteurs de courriers les deux rgles a) et b) (quelles sont les requtes DNS
utilises) ?
7) Ladministrateur dun site metteur de courrier, souhaite vrifier que son DNS est correctement
configur pour que ses courriers ne soient pas rejets par une entreprise comme fai.com.. qui
applique les rgles a) et b). Il utilise loutil nslookup disponible sous Unix ou Windows.
Quelles commandes doit-il taper pour vrifier quil satisfait les deux rgles a) et b) (expliquez
la formation des noms de domaines utiliss pour les lignes de commande) ?
Pour exprimer votre rponse vous pouvez utiliser aussi dig ou host si vous les connaissez
mieux.
-66-
Cependant les deux rgles a) et b) nvitent plus beaucoup de courriers non sollicits car les
entreprises qui font du spam le font, non pas partir de machines dans leur domaine, mais partir de
machines appartenant dautres domaines de lInternet qui ont t infestes par des virus chargs
dmettre les courriers indsirables. Une proposition de vrification qui amliore les rgles a) et b) a
t rcemment accepte par lIETF. Lensemble des nouveaux mcanismes est baptis SPF pour
Sender Policy Framework. La nouvelle vrification est base sur la cration dans le DNS dun
nouveau type denregistrement ressource qui contient pour un domaine les machines habilites
mettre du courrier.
8) Le nouvel enregistrement ressource a dabord t dfini en utilisant le type existant TXT.
Pourquoi avoir utilis ce type existant ?
Il existe de nombreuses variantes en SPF pour spcifier une machine habilite mettre du
courrier. Une faon basique mais quand mme trs significative dappliquer la politique SPF consiste
crer lenregistrement suivant :
domaine. IN TXT "v=spf1 mx all"
domaine. : le nom de domaine concern par lenregistrement ressource
IN TXT : enregistrement ressource type TXT pour le rseau Internet
"v=spf1" : une valeur obligatoire pour indiquer une utilisation du RR TXT en spf version 1
"mx"
: spcifie que tous les serveurs de courrier du domaine sont des metteurs autoriss
"-all"
: indique que tous les courriers qui ne satisfont pas la contrainte sont rejets.
Il existe diffrentes variantes syntaxiques permettant de spcifier des metteurs autoriss :

directement par le nom de domaine dun hte ou par une plage dadresses IP autorises etc
9) Quelles sont les vrifications qui sont effectues par un serveur SMTP dune entreprise qui
applique la politique SPF vis--vis dun metteur ayant insr dans son DNS lenregistrement
ressource prcdent (quelles sont les requtes DNS utilises) ? En matire de scurit, quelle
approche sapparente la technique SPF ?
10) Lutilisation de SPF permet de contrler mieux le volume des courriers non sollicits. Expliquez
lensemble des mcanismes que vous proposez reposant sur SPF pour effectuer ce contrle.
-67-
Exercice 28 : Politiques de scurit : pare-feux et filtrage des paquets

Un pare-feu ( firewall ) peut rassembler diffrents dispositifs de scurit mais le plus
souvent il se rsume un dispositif essentiel : un filtre de paquets qui fonctionne dans l'Internet.
Un filtre de paquet ( packet filter ) s'applique donc le plus souvent des datagrammes IP.
Pour le configurer on doit dfinir une politique de scurit base sur des ensembles de capacits. On
prsente le plus souvent ces capacits sous la forme dun tableau. Lexemple suivant montre
introduit simplement un exemple d'cole des diffrentes informations que l'on va prciser :
Adresse
Adresse
Port
Port
Protocole
Autres
source
destination
source destination
champs
163.173.128.36 163.173.128.40 2840
6032
TCP
Bit SYN=1
163.173.128.44 163.173.129.76 1030
5040
UDP
Action
Autoriser
Interdire
On voit que les principaux champs utiliss pour le filtrage sont les adresses IP source et
destination, les ports source et destination, le protocole transport par IP qui est soit TCP soit UDP.
On voit ensuite que tous les autres champs dun paquet IP ou dun segment TCP ou UDP sont
susceptibles dtre lobjet dun filtrage et sont regroups dans une seule colonne. Ainsi, lexemple
montre quon peut dfinir pour autoriser une transmission, la prsence obligatoire du bit SYN dans
le segment TCP. On trouve enfin dans la dernire colonne, une action associe la capacit qui est
soit dautoriser la communication soit de linterdire. En rsum on peut donc dfinir une politique de
scurit portant non seulement sur ladressage mais aussi sur tous les paramtres dappels ou de
rponse relatifs aux protocoles IP/TCP/UDP.
Selon les choix effectus dans un pare-feux industriel, la forme syntaxique qui permet de
configurer une ligne du tableau est assez variable. Par ailleurs, pour dfinir la politique de scurit
(remplir les lignes du tableau) on doit aussi connatre certains aspects smantiques du fonctionnement
du filtre. Par exemple, nous supposerons ici que le filtrage est appliqu en sortie c'est--dire juste
avant dmettre un paquet sur lune des interfaces de sortie du dispositif matriel qui supporte le filtre
(par exemple un routeur ou un hte). Nous supposerons galement que les lignes du tableau (les
capacits) sont exploites lune aprs lautre dans lordre ou elles apparaissent. La premire ligne
qui est satisfaite dclenche laction associe qui est soit de transmettre soit dinterdire la transmission
(c'est--dire de dtruire le datagramme). D'autres choix sont possibles.
1) Les rgles de filtrage associes aux lignes du tableau prcdent sont des capacits dans une
politique de scurit. Quel est le sujet, quel est lobjet et quel est le droit associ la capacit ?
2) Dans une politique de scurit en matire de communications, on peut avoir une attitude qui
consiste autoriser un ensemble limit de communications permettant aux utilisateurs de travailler et
interdire tout les autres communications par dfaut.
Comment sappelle le principe de scurit qui gouverne un tel choix de politique. Quels sont les
avantages et quels sont les inconvnients de cette politique ?
3) Donnez la forme gnrale dune liste de capacits qui dfinit une politique conforme au principe
de la question 2 (tout ce qui nest pas autoris est interdit). On notera une zone qui peut prendre
toutes les valeurs possibles par une *.
4) Une autre version pour concevoir une politique de scurit est de permettre par dfaut tout ce qui
nest pas interdit. Quels sont les avantages et les inconvnients dun tel choix. Donnez la forme
gnrale dune liste de capacits quand on adopte cette seconde stratgie.
-68-
5) Dans une connexion TCP pratiquement tous les segments ont le bit ACK positionn (prsence
dun champ dacquittement insr dans le segment). Quels sont les segments qui nont pas le bit
ACK positionn ?
6) Dduire de la question prcdente, la forme dune politique de scurit (avec deux rgles de
filtrage) qui interdit un processus (avec une adresse source port source) douvrir une connexion
TCP sur une adresse destination port destination mais qui lui permet de poursuivre une
communication (une connexion) qui a t ouverte par lautre extrmit (le processus peut fonctionner
en serveur passif mais pas en ouvreur actif )?
7) Une entreprise possde un rseau dentreprise connect lInternet mondial au moyen dun filtre
de paquets. Lentreprise souhaite dfinir une politique de scurit ou lon interdit par dfaut tout ce
qui nest pas autoris. Pour la politique de scurit relative aux accs distance en Telnet on
souhaite interdire toute connexion en provenance de lextrieur du rseau dentreprise (de lInternet
mondial) vers le rseau dentreprise. Par contre on souhaite autoriser toutes les connexions en Telnet
partir dun client (un poste de travail) connect au rseau dentreprise vers nimporte quel serveur.
Donnez la liste de filtrage qui autorise le trafic Telnet en sortie et qui linterdit en entre (il est
indispensable d'expliquer les choix effectus pour les diffrents champs d'une rgle de filtrage) ?
Indications :
a) On considrera que ladresse IP du rseau de lentreprise est 163.173/16
b) Le port Telnet est le port 23.
c) On sattachera ce que les ports allous aux services bien connus ('well known ports' des
serveurs comme le port 23 de telnet) soient distingus des ports allous dynamiquement aux
clients qui demandent une connexion. On pourra considrer que les ports allous
dynamiquement ont toujours un numro suprieur 1023.
8) Lentreprise ne possde quun seul serveur de messagerie (MTA Mail Transfer Agent) qui
fonctionne avec le protocole Internet SMTP. Le protocole SMTP est un protocole client-serveur.
Le MTA de l'entreprise est un client SMTP pour d'autres serveurs dans l'Internet lorsqu'un membre
du personnel met un courrier. Le MTA est un serveur SMTP dun client distant lorsqu'un membre
du personnel reoit un courrier. On cherche tout d'abord dfinir en franais les principaux
changes qui doivent tre autoriss entre le serveur de messagerie de lentreprise et les autres
serveurs de messagerie distants dans lInternet mondial. Quelles sont les quatre catgories de
messages qui vont devoir tre autoriss entre le serveur de messagerie de lentreprise et ces
machines distantes?
9) Quelle est la liste des capacits (des rgles de filtrage) qui doivent tre dfinies pour autoriser la
circulation des courriers lectroniques entre le serveur de messagerie de lentreprise et le reste de
lInternet (il est indispensable d'expliquer les choix effectus pour les diffrents champs d'une rgle
de filtrage)?
Indications :
a) On considrera que ladresse IP du serveur de lentreprise est 163.173.128.20.
b) Le port SMTP est le port 25.
c) On sattachera ce que les ports allous aux services bien connus ('well known ports' des
serveurs comme le port 25) soient distingus des ports allous dynamiquement qui ont
toujours un numro suprieur 1023.
-69-
Exercice 29 : Environnement de scurit SSH 'Secure Shell'

Scurit des commandes distance (commandes r 'remote')
Dans le systme UNIX on peut utiliser les trois commandes suivantes : cp (copie dun fichier
dans un autre), sh (lancement de linterprteur de commande shell pour excuter une commande),
login (ouverture dune nouvelle session interactive sur un autre compte).
Avec larrive de larchitecture de rseaux TCP/IP, luniversit californienne de Berkeley a
fourni en 1983 dans sa livraison Unix (Unix BSD Berkeley Software Distribution) un paquetage de
trois commandes nouvelles permettant lexcution distance des trois commandes prcdentes qui
ntaient possibles jusque l que localement.
Le nom qui a t donn aux nouvelles commandes adaptes lunivers rseau, a t obtenu
en prfixant par r (pour remote) le nom de la commande en mode centralis soit rsh, rcp, rlogin.
Ces commandes sont ralises par un processus lanc sur le site client par un usager dsireux
dexcuter la commande. Le client dialogue avec un processus serveur qui doit tre lanc en
permanence sur le site distant. Ce serveur est donc constamment en attente des demandes
dexcution des commandes client pour les traiter.
Par exemple, pour excuter distance la liste des fichiers dans le rpertoire par dfaut
(commande UNIX ls), de lusager gerard (paramtre dans la commande l pour login) qui
possde un compte sur la machine ulysse.cnam.fr on excute :
% rsh -l gerard ulysse.cnam.fr "ls"
Lmetteur de la requte doit alors fournir le mot de passe associ au compte gerard sur la
machine ulysse.cnam.fr. Dans la version de base, qui reste le fonctionnement de nombreuses
implantations des commandes rsh, rcp, rlogin, tous les changes se font en clair.
1) Donnez la liste la plus large dattaques que vous pouvez imaginer sur l'excution des commandes
distantes en mode de base. Il est obligatoire de justifier pour une attaque cite comme possible, le
mode opratoire de lattaque (dcrire le fonctionnement de lattaque et sa consquence sur
lexcution des commandes distantes qui vient dtre dcrit).
Afin dviter aux utilisateurs de devoir saisir, pour chaque commande distante, un mot de
passe, on permet pour chaque compte utilisateur de crer dans le rpertoire principal (le rpertoire
par dfaut), un fichier dont le nom est par convention .rhosts. Ce fichier contient une liste des
machines, qui sont autorises excuter des commandes sans vrification du mot de passe, sur le
compte associ au rpertoire qui contient le fichier .rhosts. Les htes lists dans ce fichier sont
baptiss htes de confiance pour un compte utilisateur donn ( trusted hosts ). Cette mthode des
htes de confiance est galement applique globalement pour lensemble des utilisateurs dune
machine au moyen dun fichier systme dont le nom est par convention /etc/hosts.equiv. Ce fichier
contient une liste dautorisation ou dinterdiction de lutilisation des commandes r pour des
ordinateurs ou des utilisateurs.
2) Comment appelle t'on en scurit le contenu d'un tel fichier (dfinissez cette approche de la
scurit par comparaison aux diffrentes approches de scurit vues en cours) ?
-70-
3) Quelles sont les failles en scurit de la mise en uvre des fichiers .rhosts ou hosts.equiv
(donnez la liste la plus large dattaques que vous pouvez imaginer) ?
Gnralits SSH
La version initiale de l'environnement de scurit SSH (Secure SHell) a t propose en
1995 par Tatu Ylnen (chercheur finlandais) pour permettre lexcution scurise des commandes
distance Unix que nous venons de voir. T. Ylnen a donc introduit une nouvelle srie de commandes
prfixes par s pour scurit. La principale nouvelle commande a t baptise ssh (secure shell)
pour raliser lexcution scurise de toute commande distance. Pour scuriser des transferts de
fichiers il a introduit des commandes comme scp ('ssh copy') et sftp (ssh file transfer protocol).
Dans ce texte nous ne considrons que la scurisation des commandes d'UNIX mais le protocole
SSH peut-tre utilis aussi pour scuriser des commandes Windows ou Mac OS. SSH est devenu
avec le temps un logiciel de scurit trs rpandu dans la scurisation des applications rseaux.
Ce texte sintresse la version 2 (SSH V2), normalise lIETF aprs de longs dbats en
janvier 2006. Les RFC principales sont : SSH Protocol Architecture (SSH-ARCH RFC 4251),
SSH Authentication Protocol (SSH-AUTH RFC 4252), SSH Transport Layer Protocol (SSHTRANS RFC 4253), SSH Connection Protocol (SSH-CONN RFC 4254).
La version 2 de SSH hrite par de nombreux aspects de mcanismes dvelopps pour la
version 1. Mais la version 2 corrige des faiblesses de scurit de certains mcanismes de la version
1. Par exemple on y introduit l'utilisation du protocole dchange de cls de Diffie-Hellman,
l'utilisation de macs . La version 2 ajoute de nouvelles fonctions. Pour toutes ces raisons, elle est
incompatible avec la version 1 qui est donc destine disparatre.
Au total, SSH version 2 offre la possibilit de construire plusieurs sessions concurrentes
scurises (construire plusieurs VPN SSH) avec authentification forte, contrle dintgrit et
chiffrement des sessions. Chaque session permet l'une des applications scurise suivante:
- Sessions de travail distance ('remote login') : ssh, slogin remplaant rsh, login
- Sessions de transfert de fichiers: scp ou sftp qui remplacent rcp ou ftp.
- Sessions de dport d'affichage multi fentre : pour le protocole X11.
- Sessions ralisant des tunnels chiffrs : pour acheminer des informations changes par
dautres protocoles (SSH Port forwarding soit relayage ou transfert de port).
SSH V2 est structure en modules spars alors que la version 1 tait monolithique.
Lorganisation modulaire en couches de SSH V2 (au dessus de TCP) est la suivante :
Applications scurises utilisant des tunnels SSH
Commandes distance scurises SCP, SFTP, SSH,
SSH-CONN
Sessions scurises SSH
SSH-AUTH
Authentification client SSH
SSH-TRANS
Authentification serveur, Echanges confidentiels de donnes SSH
TCP
Transmission Control Protocol
La couche SSH-TRANS ralise lauthentification du serveur, ngocie les algorithmes utiliss
(chiffrement, change de cls, intgrit, compression), change les cls de session, assure les
fonctions de confidentialit et dintgrit sur les donnes, ralise des fonctions de compression.
-71-
La couche SSH-AUTH ralise lauthentification du client avec diffrentes possibilits (par

mot de passe, cl publique, hte de confiance). Elle assure les changements de cl ou de mot de
passe.
La couche SSH-CONN utilise la couche de transport pour multiplexer plusieurs sessions
interactives scurises. On peut ainsi excuter des commandes shell distance, ou faire
communiquer des applications multi-fentre (avec X11), ou effectuer des transferts de port TCP ce
qui permet de scuriser par SSH des applications non scurises en appliquant de manire
transparente ces applications les protocoles de scurit SSH.
Mcanismes dauthentification du serveur

L'authentification, dans lexcution de commandes distance, est un problme majeur. En
SSH, lauthentification est vue deux niveaux. On authentifie tout d'abord un hte serveur SSH i.e.
une machine qui excute un processus serveur SSH. Cette authentification russie, ouvre un change
de cls de session qui permettent toute la suite des communications SSH dtre chiffres en
confidentialit et contrles en intgrit. On peut alors commencer traiter des commandes usager.
On ralise alors un second type dauthentification : on authentifie individuellement les usagers qui
demandent des accs des comptes sur un hte serveur.
Nous commenons par l'authentification des machines. Elle utilise uniquement une approche
cls publiques. Donc, au moment de linstallation de SSH sur un serveur, un administrateur
systme doit commencer par gnrer un couple cl publique/cl prive et l'attribuer cette machine.
Pour ensuite tablir une relation SSH entre un client et un serveur, la machine cliente doit possder la
cl publique de la machine servante.
SSH prvoit que cette cl publique soit contenue dans un certificat, auquel cas sa protection
et sa vrification sont dfinies dans le cadre d'une infrastructure cls publiques. Cette solution, trs
rpandue, prsente les difficults de mise en uvre inhrentes aux PKI.
SSH propose comme alternative plus lgre une PKI, de pouvoir grer les cls publiques
sans structure de certificat. Dans ce cas, une cl publique est associe un seul enregistrement dans
un fichier ayant comme champs: le nom de domaine de la machine serveuse SSH possdant la cl,
son adresse IP, l'algorithme cl publique pour lequel la cl est dfinie, la valeur de la cl. Pour
information voici un enregistrement de cl publique:
serveur_ssh.cnam.fr, 163.173.29.211 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA06
jFqviLMMJ/GaJNhGx/P6Z7+4aJIfUqcVjTGQasS1daDYejcfOAWK0juoD+zS3BsGKKYKPA5Gc5
M8v+3NHLbPn1yTpDBgl6UzA0iiMPCbwnOLx61MrBTk+/qJI9kyDaJf4LEY6Chx4IJP0ZN5NmAl
CtXQsca3jwFAF72mqPbF8=
a) Une premire mthode recommande pour faire connatre la cl publique dun site serveur
est de linstaller manuellement dans un fichier sur chaque site client.
Une cl publique de serveur est connue, pour tous les utilisateurs dun systme client, si elle
a t installe dans un fichier systme global dont le nom est par convention en Open-SSH
/etc/ssh_known_hosts. Dans ce texte, parmi les diffrentes implantations des normes SSH, nous
utilisons pour nos exemples la version libre Open-SSH.
La cl publique peut tre connue d'un seul utilisateur si elle se trouve dans le fichier
known_hosts qui est par convention localis dans le sous rpertoire .ssh du rpertoire par dfaut de
cet utilisateur (fichier ~/.ssh/known_hosts ou ~ dsigne de manire gnrale le rpertoire par dfaut
dun usager soit par exemple /users/deptinfo/gerard).
-72-
b) Dans certains cas, un usager client peut vouloir utiliser un serveur distant sans que la cl
publique de cette machine ne soit connue du client. Dans ce cas, le client SSH demande et obtient
du serveur sa cl publique par un change de messages ralise louverture de la connexion SSH.
On propose alors lusager demandeur de mettre cette cl publique dans son fichier
~/.ssh/known_hosts.
4) Quel problme de scurit peut poser la transmission en rseau de la cl publique dun serveur
SSH distant sans la structure de certificat ?
Le dialogue console suivant est une partie de celui quon peut constater lorsquun client tente
pour la premire fois dtablir une communication en Open-SSH avec un site distant dont le nom de
domaine est serveur_ssh.cnam.fr et dont la cl publique ne figure pas dans fichier known_hosts :
% ssh serveur_ssh.cnam.fr
The authenticity of host serveur_ssh.cnam.fr (163.173.29.211)' can't be

established.
RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'serveur_ssh.cnam.fr, 163.173.29.211' (RSA) to
the list of known hosts.
Dans la liste prcdente on constate que la transmission de la cl publique du serveur distant

(serveur_ssh.cnam.fr) au client local (le processus qui excute la commande ssh) na pas t juge
suffisamment authentifie (cest parce que la cl nexistait pas dans lun des fichiers
/etc/ssh_known_hosts ou ~/.ssh/known_hosts). Limplantation du client SSH a alors propos
lusager une valeur dempreinte de la cl publique. RSA key fingerprint dsigne littralement une
empreinte digitale pour une cl RSA. La mthode de calcul de lempreinte nest pas prcise par la
norme SSH. Elle est laisse au choix des implantations (ici on peut constater le rsultat du calcul
dempreinte par Open-SSH sur une valeur de cl publique). Lempreinte est calcule une premire
fois lors de la gnration de la cl publique avec comme objectif sa diffusion par un moyen diffrent
de celui utilis pour la cl publique. Lempreinte est recalcule sur la valeur de cl publique change
en rseau et elle est dite. Lutilisateur est cens connatre cette empreinte pour valider par sa
rponse yes/no lentre de cette cl dans le fichier ~/.ssh/known_hosts de son compte. La
mthode de diffusion de lempreinte nest pas non plus normalise. Elle peut tre manuelle.
Lempreinte peut figurer dans une liste dempreintes sur une page Web ou se trouver dans un fichier
dun serveur protg, dans un annuaire LDAP, il a t aussi propos un enregistrement ressource
DNS pour les empreintes de cls SSH .
6) La solution constitue une forme d'infrastructure cls publiques. Evaluez la scurit de la solution
propose (quelles doivent tre les qualits de lempreinte et de sa diffusion).
7) Lorsque la cl publique du serveur est connue du client, SSH en version 1 applique une solution
dauthentification standard du serveur base sur un chiffre cl publique. Cette solution est utilisable
galement en SSH V2. Rappelez les principes du protocole dauthentification utilisant un chiffre cl
publique.
Mcanismes de confidentialit
-73-
Aprs lauthentification du serveur, on ralise un change de cl de session (de cl secrte).

La version 2 de SSH permet au dbut dune connexion SSH, la ngociation (le choix) dune
mthode dchange de cl de session (nous verrons une solution cl publique et une solution DiffieHellman) et le choix dun algorithme de chiffrement cl secrte comme le 3-DES-CBC (implant
obligatoirement en SSH) ou lAES-128-CBC (dutilisation recommande). A partir de lchange de
cl de session, tous les changes SSH sont chiffrs en confidentialit au moyen d'un chiffre cls
secrtes et sont aussi protgs en intgrit.
8) On peut choisir comme mthode dchange de cls, la mthode de base qui a t dfinie pour la
version 1 de SSH. Elle sappuie directement sur la disponibilit dun chiffre cl publique. Cette
mthode dchange de cl de base est linitiative du client. Rappelez le mode de fonctionnement
dun change de cls de session au moyen dun chiffre cls publiques. Avec un chiffre cl
publique, peut-on combiner en un mme protocole, lchange de cl de session et lauthentification
du serveur ?
SSH V2 nimpose comme mthode obligatoirement implante pour lchange de cls, que la
mthode de Diffie-Hellman (toutes les autres mthodes sont optionnelles). En SSH V2, lchange de
Diffie_Hellman est classique dans la mesure ou le client commence par transmettre sa valeur de
Diffie-Hellman, le serveur rpond en transmettant la sienne. Les deux communicants peuvent alors
dterminer la cl secrte partage. Une variante apparat en SSH car le serveur ajoute dans son
message de rponse, la signature dun ensemble dinformations comportant les identifications des
communicants, des contenus de messages prcdents et aussi les deux valeurs changes dans le
protocole de Diffie-Hellman puis la valeur de la cl secrte partage. Le serveur a dj pu la calculer
aprs le premier message du client.
9) Pourquoi le serveur ajoute til la signature de ces donnes. Cette signature peut-elle aussi
authentifier le serveur ? Justifiez vos rponses.
10) SSH V2 proclame quil satisfait la proprit de secret parfait des cls (PFS Perfect Forward
Secrecy). Quest ce que cela veut dire ? Pourquoi cette proprit est-elle satisfaite ?
Mcanismes dauthentification du client

On doit maintenant authentifier lutilisateur client. SSH propose trois modes
dauthentification : hte de confiance, mot de passe, cl publique.
11) La solution des htes de confiance est trs similaire celle des commandes r (avec les fichiers
hosts) en particulier du point de vue de la scurit. Elle a t conserve pour des raisons de
compatibilit avec lexistant et pour des configurations avec des risques limits en scurit. Dans des
rseaux dentreprise un tant soit peu attaqus, elle est en gnral interdite. Quaurait-il fallu faire pour
que lapproche des htes de confiance soit scurise ?
12) Le plus souvent, on privilgie en SSH lauthentification du client base sur un chiffre cls
publiques contre l'authentification par mot de passe.
Citez diffrentes faiblesses de lauthentification mot de passe mme si l'change d'authentification
est chiffr en confidentialit comme en SSH.
-74-
Lorsquun nouvel utilisateur de SSH se prsente dans une approche cl publique, la

premire opration qu'il doit accomplir est de se doter dun couple cl publique cl prive. Avec
SSH en version 2, la gnration du couple est effectue selon un paramtre de type qui a comme
valeur soit RSA soit DSA (commandes ssh-keygen t rsa ou ssh-keygen t dsa).
13) Expliquez la diffrence entre ces deux options. Selon vous pourquoi a-t-on offert cette
possibilit en SSH version 2 ?
Un exemple dexcution de commande de gnration de cls en SSH en version 2 est donn
plus loin. Il existe des diffrences, principalement de syntaxe selon les implantations de SSH (usage
des noms de fichiers, conventions de paramtrisation, ..).
% ssh-keygen
Generating RSA keys: Key generation complete.
Enter file in which to save the key (/users/deptinfo/gerard/.ssh/identity):
Created directory '/users/deptinfo/gerard/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /users/deptinfo/gerard /.ssh/identity.
Your public key has been saved in /users/deptinfo/gerard /.ssh/identity.pub.
The key fingerprint is:
1024 39:82:19:c3:3a:f4:14:3a:b8:8b:a8:5b:72:bd:c7:b9
On observe, dans lexcution de la commande ssh-keygen, que les cls publique et prive
sont conserves dans deux fichiers identity et identity.pub du rpertoire baptis .ssh. On observe
galement que lutilisateur sest vu demander une chane de caractre (une phrase de passe) au
prompt "Enter passphrase" qu'il a du rpter au prompt "again". On voit aussi que cette chane est
facultative. Quand elle est fournie, elle est utilise comme cl secrte d'un algorithme de chiffrement
cl secrte pour chiffrer le fichier contenant la cl prive. En consquence, chaque fois qu'on devra
utiliser la cl prive, l'usager se verra demander la phrase de passe pour dchiffrer la cl prive.
Quand la phrase de mot de passe n'est pas fournie par l'utilisateur lors de la cration, celui-ci doit
assurer par lui-mme la protection de sa cl prive. On a donc deux approches de scurisation d'une
cl prive.
14) Comparez les deux approches de scurisation de la cl prive (niveau de scurit, aisance du
procd,).
L'utilisateur d'une authentification SSH cl publique doit galement enregistrer sa cl
publique sur le serveur SSH sur lequel il va s'authentifier. Il doit placer cette cl dans un fichier dans
le sous-rpertoire .ssh du rpertoire par dfaut du compte sur lequel il s'authentifie. Cette
transmission doit tre scurise. Une solution de base est de la scuriser au moyen du mot de passe
habituel douverture de session sur un compte sur le serveur distant. A partir de l on peut
authentifier l'usager client au moyen d'une solution a cl publique.
Dans le cas de lutilisation dune phrase de passe, la demande frquente de cette phrase un
usager est fastidieuse. SSH propose une solution au moyen d'un agent pour fournir cette phrase la
place de l'usager.
Mcanismes dintgrit
-75-
15) La version 1 de SSH utilisait le CRC-32 comme contrle de lintgrit des messages transmis.
C'est--dire quon calculait pour chaque message chang en SSH une redondance selon la mme
mthode que celle qui est utilise dans tous les rseaux locaux (par exemple en Ethernet ou en Wifi).
Cette mthode a t abandonne en SSH version 2. Pourquoi ?
16) SSH version 2 utilise comme contrle de lintgrit un HMAC. Rappelez le mode de
fonctionnement de cette mthode de contrle dintgrit. Pourquoi est-elle de scurit ?
-76-

Sujets Exercices Securite PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Sujets Exercices Securite PDF

Transféré par

Droits d'auteur :

Formats disponibles

Sujets des exercices dirigs

CNAM- Anne 2007/2008

Exercices UE Scurit et Rseaux

Table des matires

CHAPITRE 1 : FONCTIONS CRYPTOGRAPHIQUES .................................................................................................... 3

: Chiffres cls secrtes; cryptogramme 1............................................................................................ 3

CHAPITRE 2: PROTOCOLES DE SECURITE.................................................................................................................13

CNAM- Anne 2007/2008

Exercices UE Scurit et Rseaux

CNAM- Anne 2007/2008

Exercices UE Scurit et Rseaux

Rpartition des lettres dans lexemple

CNAM- Anne 2007/2008

Exercices UE Scurit et Rseaux

Exercice 2 : Chiffres cls secrtes; cryptogramme 2

Exercice 3 : Chiffres cls secrtes; cryptogramme 3

Exercice 4 : Fonctionnement du chiffre cl publique RSA

Exercices UE Scurit et Rseaux

On donne les valeurs numriques suivantes : p = 3, q = 11 (trop petites en pratique, mais

Exercice 5 : Dcryptage du RSA

CNAM- Anne 2007/2008

Exercices UE Scurit et Rseaux

Exercice 6 : Signatures RSA

CNAM- Anne 2007/2008

Exercices UE Scurit et Rseaux

Exercice 7 : Etude du jeu de pile ou face en rseau

Exercices UE Scurit et Rseaux

asynchrones. Peut-on construire un protocole scuritaire (par exemple rendre scuritaire le

Envoyer fk(n) (n en chiffre)

Exercices UE Scurit et Rseaux

Choisir des cls RSA

Envoyer n , la cl prive (d,N) en clair

CNAM- Anne 2007/2008

Exercices UE Scurit et Rseaux

CNAM- Anne 2007/2008

Exercices UE Scurit et Rseaux

Exercice 8 : Partage d'un secret

CNAM- Anne 2007/2008

Exercices UE Scurit et Rseaux

CHAPITRE 2: PROTOCOLES DE SECURITE

Exercices UE Scurit et Rseaux

CNAM- Anne 2007/2008

Exercices UE Scurit et Rseaux

Exercice 10 : Changement priodique de cls en cryptographie cls

CNAM- Anne 2007/2008

Exercices UE Scurit et Rseaux

Exercices UE Scurit et Rseaux

Exercice 11 : Protocoles d'changes de cls scuriss

CNAM- Anne 2007/2008

Exercices UE Scurit et Rseaux

Exercices UE Scurit et Rseaux

CNAM- Anne 2007/2008

Exercices UE Scurit et Rseaux

Exercice 12 : Construction dun systme de paiement par chques

Exercices UE Scurit et Rseaux

II) Protocole chque de banque

II.1) Ce protocole sapparente la notion de chque de banque. Pourquoi ? (Avec ce protocole

CNAM- Anne 2007/2008

Exercices UE Scurit et Rseaux

Exercice 13 : Protocole de micro-paiement sur Internet

Bob, Alice, 'Transmission du

Alice vrifie que

2) Quelles sont les proprits des fonctions de hachage de scurit ?