Download pdf - Sujets Exercices Securite

CNAM- Anne 2007/2008 -1- Exercices UE Scurit et Rseaux

Sujets des exercices dirigs

Scurit et Rseaux

UE RSX 112

2007-2008

G. Florin, S. Natkin


Table des matires

CHAPITRE 1 : FONCTIONS CRYPTOGRAPHIQUES .................................................................................................... 3 Exercice 1 : Chiffres cls secrtes; cryptogramme 1............................................................................................ 3 Exercice 2 : Chiffres cls secrtes; cryptogramme 2............................................................................................ 5 Exercice 3 : Chiffres cls secrtes; cryptogramme 3............................................................................................ 5 Exercice 4 : Fonctionnement du chiffre cl publique RSA................................................................................. 5 Exercice 5 : Dcryptage du RSA................................................................................................................................. 6 Exercice 6 : Signatures RSA........................................................................................................................................ 7 Exercice 7 : Etude du jeu de pile ou face en rseau................................................................................................ 8 Exercice 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


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) le pourcentage de mots dans un texte qui ont au moins une faute dorthographe, imaginez un algorithme de cryptanalyse de ce type de crypto-systmes


Rpartition des lettres dans lexemple et dans la langue franaise

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


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 l0l0 ?

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 = f(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 = f(n) ? 4) Quelle est la valeur numrique de d ? 5) Pourquoi a t'on pu casser facilement ce chiffre ?


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)


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.

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

Dcision finale : Alice gagne si

Bernard na pas donn la bonne

parit.

Envoyer p en clair

Envoyer n en clair

Alice Bernard

Choisir n au hasard (entier)

Choisir p au hasard (pair ou impair)

Dcision finale Bernard gagne sil a donn la bonne

parit.


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. 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 elle-mme un couple cl publique (note (e,N)), cl prive (note (d,N)) avec N=PQ produit de deux



parit.

Envoyer p en clair

Envoyer fk(n) (n en chiffre)

Alice Bernard

Choisir n au hasard (entier).

Choisir k cl secrte



parit.

Envoyer n et k en clair


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. 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 :

Envoyer n , la cl prive (d,N) en clair Envoyer P, Q tel que N=PQ en clair



parit.

Envoyer p en clair

Envoyer (e,N) en clair, RSA(e,N)(n) soit n en chiffre RSA

Alice Bernard

Choisir des cls RSA publique (e,N) et prive

(d,N) Choisir n au hasard

(entier)



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. Peut-on 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)



parit.

Envoyer p en clair

Envoyer H(n)

Alice Bernard

Choisir n au hasard (entier)



parit.

Envoyer n en clair


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.


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.


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)?


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.


2.1) Proposez des modifications du protocole Px pour dfinir le protocole Py qui assurent le changement scuris des cls.

A BChoisir un nombre alatoire RA

Choisir un nombre alatoire RB

Envoyer [DA{EB(RB)}]

DB{EA(RA),RB}

Recevoir [DB{EA(RA),RB}]

Envoyer [DB{EA(RA),RB}]

DA{EB(RB)}

Recevoir [DA{EB(RB)}]

Envoyer [RA]

Recevoir [RA]

RA

Dcoder RA et 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 ?


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 B (Bernard) Demande_cl (A, B) ------------------------------> 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 :


A (Alice) B (Bernard)

Envoi_cl_publique( EA )----------------------------------------> Dterminer Message_B

Premire_partie (EA(Message_B) ) Envoi (Premire_partie (EA(Message_B)))

Envoi (Seconde_partie (EA(Message_B)))

Envoyer_certificat (certificat_B)


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 }}}


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 ?


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))) A C A, C, Id_Cheq_A , Montant , Dc(Dba(Da(H (A,C, Id_Cheq_A ),Montant))) C 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 ?


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 Rseau Alice 1 Bob gnre un nombre

alatoire s sur k bits; il calcule h1 = {C s}H

2 Bob, Alice, 'Transmission du nombre s sur k bits', s

3 Bob demande Alice la ralisation de lopration

Bob, Alice,'Demande opration', h1

4 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 :


Bob Rseau Alice 1 Bob gnre s alatoire

sur k bits et calcule : h0 = C s h1 = {h0}H .

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

3 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

5 Authentification de Bob ? Ralisation de lopration 1 si OK

. .. 2+2i

Demande de la ime opration (i n)

Bob, Alice, 'demande d'opration', hn-i+1

2+2i+1

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.


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).


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) ?


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.


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 Le nom du client. A,a 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)

SA,sa La clef de session dAlice SA est connue dAlice et de Kerberos Bob Le nom du serveur invoqu. B,b La clef prive du serveur Bob. (en majuscule quand elle est utilise pour le

dchiffrement, en minuscule pour le chiffrement) Kerberos Le nom du serveur de distribution des clefs KDC,kdc La clef de Kerberos connue de lui seul(en majuscule quand elle est utilise pour

le dchiffrement, en minuscule pour le chiffrement) KAB,kab La clef de session dtermine entre client et serveur. (en majuscule quand elle est

utilise pour le dchiffrement, en minuscule pour le chiffrement) Ticket Le ticket donn un client Alice pour utiliser un serveur Bob. date_fab_X La date de fabrication de l'objet X date_courante 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 ?


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 ) ]

KSB_AS_REQ, Alice, Kerberos

Gnre la clef SA ; date_per_SA := date_courante+ dure_validit ; TGT= { }symkdcAdate_per_SSA,Alice, REP :={ }symaTGTSA,

KSB_AS_REP, Kerberos, Alice, REP

Alice Kerberos

SA,TGT :={ }symAREP


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.

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 ?

Identificateur Longueur Code

Donnes

0 7 15 31


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) ?


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.

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

0 1 2 3 Code Longueur

Attributs

Ident Authentificateur (16 octets)


4 Accounting-Request 5 Accounting-Response 11 Access-Challenge 12 Status-Server (experimental) 13 Status-Client (experimental) 255 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 :

Quelques exemples de types dattributs. 1 User-Name 2 User-Password 3 CHAP-Password 4 NAS-IP-Address 5 NAS-Port 6 Service-Type 7 Framed-Protocol 8 Framed-IP-Addres 9 Framed-IP-Netmask 10 Framed-Routing 11 Filter-Id 12 Framed-MTU 13 Framed-Compression 14 Login-IP-Host 15 Login-Service 16 Login-TCP-Port 17 (unassigned) 18 Reply-Message 19 Callback-Number 20 Callback-Id 21 (unassigned) 22 Framed-Route 23 Framed-IPX-Network 24 State 25 Class 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. Structure du message Access-Request

Valeur Longueur Type

0 1 2

Client_RADIUS

Access-Accept ou Access-reject

Serveur_RADIUS

Access-Request


- Le champ authentificateur contient une valeur alatoire de 16 octets. Dans le message Access-Request 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 ?


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.

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 ?

Client_RADIUS

Access-Accept ou Access-reject

Serveur_RADIUS

Access-Request

Access-Request

Access-Challenge


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


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


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


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 ?


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


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 Outer Hdr at Inner Hdr at IPv4 Encapsulator Decapsulator Header fields: -------------------- ------------ version 4 (1) no change header length constructed no change TOS copied from inner hdr (5) no change total length constructed no change ID constructed no change flags (DF,MF) constructed, DF (4) no change fragmt offset constructed no change


TTL constructed (2) decrement (2) protocol AH, ESP, routing hdr no change checksum constructed constructed (2) src address constructed (3) no change dest address constructed (3) no change Options never copied 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.


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