Bruce Schneier
Cryptographie appliquée Deuxième édition Protocoles, algorithmes et codes cource en C
Traduction de Laurent Viennot
Table des matières P ré fa ce Comment lire ce livre ........................................................................................... R em erciem ents.......................................................................................................
xiii xiv xvii
À
p ro p o s de l’ au teu r
x ix
1
P rin cip e s d e base 1.1 Terminologie ................................................................................................ 1.2 Steganographie............................................................................................. 1.3 Substitution et transposition....................................................................... 1.4 Ou exclusif s i m p l e ..................................................................................... 1.5 Masque j e t a b l e ................. 1.6 Algorithmes inform atiques.......................................................................... 1.7 Grands nom bres.............................................................................................
1
Protocoles cryptographiques
1 1 9 10 14 15 18 18
21
2
B riqu es élém en taires 2.1 Introduction aux p r o t o c o le s ...................................................................... 2.2 Communications à l’aide d ’un cryptosystèmeà clef s e crè te................... 2.3 Fonctions à sens unique ............................................................................ 2.4 Fonctions de hachage à sens u n iqu e.......................................................... 2.5 Communications à l’aide d ’un cryptosystèmeà clef p u b liq u e............... 2.6 Signatures num ériques................................................................................ 2.7 Signatures numériques avec chiffrement................................................ 2.8 Générateurs aléatoires et pseudo-aléatoires.............................................
23 23 30 31 32 33 37 44 47
3
P r o to c o le s élém en taires 3.1 Échange de clefs ......................................................................................... 3.2 Authentification............................................................................................ 3.3 Authentification et échange de c le fs ......................................................... 3.4 Analyse formelle des protocoles d ’authentification et d ’échange de clefs 3.5 Cryptographie à clef publique à clefs multiples....................................... 3.6 Secret m orcelé............................................................................................... 3.7 Secret r é p a r t i...............................................................................................
51 51 56 61 70 74 75 77
TABLE DES MATIÈRES 3.8
Protection cryptographique de bases dedonnées....................................
80
4
P r o to c o le s in term édiaires 4.1 Services de datation ................................................................................ 4.2 Canal su b lim in a l......................................................................................... 4.3 Signatures numériques incontestables....................................................... 4.4 Signatures numériques à vérificateurd é d ié ............................................... 4.5 Signatures par procuration......................................................................... 4.6 Signatures collectives................................................................................... 4.7 Signatures numériques « Fail-Stop »..... ..................................................... 4.8 Calcul avec données chiffrées...................................................................... 4.9 Mise en gage ............................................................................................... 4.10 Jouer à pile ou f a c e ...................................................................................... 4.11 Poker à l’a v e u g le ......................................................................................... 4.12 Accumulateurs à sens unique ................................................................... 4.13 Divulgation tout ou rien de s e c r e t s .......................................................... 4.14 Dépôt de c le f s ...............................................................................................
81 81 85 87 88 89 90 91 92 92 95 99 102 103 103
5
P r o to c o le s avancés 5.1 Preuves à divulgation nulle ...................................................................... 5.2 Identification par preuve à divulgation n u lle .......................................... 5.3 Signatures en aveugle ................................................................................ 5.4 Cryptographie à clef publique à based ’identification . . . . . . . . . 5.5 Transfert in con scien t.................................................................................. 5.6 Signatures in conscien tes............................................................................ 5.7 Signature simultanée de co n tr a t................................................................ 5.8 Courrier électronique certifié...................................................................... 5.9 Echange simultané de s e c r e t s ...................................................................
109 109 117 120 123 124 126 127 131 132
6
P r o to c o le s ésotériq u es 6.1 Elections sûres ............................................................................................ 6.2 Calcul réparti s û r ......................................................................................... 6.3 Diffusion de messages anonymes . 6.4 Argent électronique . . . . . . .
135 135 144 148 150
II 7
Techniques cryptographiques
161
L on g u eu r des clefs 163 7.1 Longueur des clefs secrètes......................................... ............ 163 7.2 Longueur des clefs publiques...................................................................... 170 7.3 Comparaison de la longueur des clefssecrètes et des clefs publiques . 178 7.4 Attaques des anniversaires contre unefonction de hachage à sens unique 178 ..................................................... 179 7.5 Quelle doit être la longueur de clef? 7.6 Avertissement............................................................................................... 180
TABLE DES MATIÈRES
vii
8
G e stio n des clefs 181 8.1 Génération de c l e f s ......................................................................................... 182 8.2 Espaces des clefs non linéaires...................................................................... 188 188 8.3 Transfert de c l e f s ............................................................................................ 8.4 Vérification de clefs ...................................................................................... 190 8.5 Utilisation des c le fs ......................................................................................... 192 8.6 Mise à jour des c l e f s ...................................................................................... 193 87 Stockage des c le f s ............................................................................................ 193 8.8 Duplicata des c l e f s ......................................................................................... 194 195 8.9 Clefs co m p ro m ise s......................................................................................... 8.10 Longévité des c l e f s ......................................................................................... 196 8.11 Destruction des c l e f s ...................................................................................... 197 198 8.12 Gestion des clefs pour la cryptographie à clef p u b liq u e ..........................
9
T y p e s et m o d e s d ’a lgorith m es 9.1 Carnet de codage électronique.................................................................... 9.2 Bloc rejoué ................................................................................................... 9.3 Mode de chiffrement avec chaînage de b l o c s ........................................... 9.4 Algorithmes de chiffrement en c o n t in u .................................................... 9.5 Chiffrement autosynchrone en c o n t i n u ....................................................... 9.6 Chiffrement à rétroaction ............................................................................. 9.7 Chiffrement synchrone en co n tin u ................................................................ 9.8 Mode de rétroaction de s o r t i e ................................................ 9.9 Mode « compteur » ......................................................................................... 9.10 Autres m o d e s .................................................................................................. 9.11 Choix d’un mode opératoire de chiffrement.................................. 9.12 Intercalation..................................................................................................... 9.13 Chiffrement par blocs vs chiffrement en co n tin u .......................................
201 202 203 205 209 211 212 214 216 219 220 222 223 225
10 U tilisa tion des a lgorith m es 227 10.1 Choix d’un a lgorith m e................................................................................... 228 10.2 La cryptographie à clef publique vs la cryptographie à clef secrète . . 230 10.3 Chiffrement des canaux de com m unication................................................ 230 10.4 Chiffrement des données à des fins de stockage ...................................... 235 10.5 Chiffrement matériel vs chiffrement logiciel ............................................. 237 10.6 Compression, codage et chiffrem ent............................................................. 240 10.7 Détection du chiffrem ent............................................................................... 241 10.8 Cacher du texte chiffré dans du texte c h iffré ............................................. 242 10.9 Destruction d’in fo rm a tio n ............................................................................ 243
III
Algorithmes cryptographiques
245
11 R u d im en ts m ath ém a tiqu es 247 11.1 Théorie de l’in form a tion ............................................................................... 247 11.2 Théorie de la com p lex ité............................................................................... 251 11.3 Théorie des n o m b r e s ..................................................................................... 256 11.4 Factorisation .................................................................................................. 271
TABLE DES MATIÈRES 11.5 11.6
Génération de nombres premiers ............................................................ Logarithmes discrets dans un corps fini . . .
274 278
12 Le D E S 12.1 H istoriqu e...................................................................................................... 12.2 Description du DES....................................................................................... 12.3 Niveau de sécurité du D E S • 12.4 Cryptanalyse différentielle et linéaire ............ . . . 12.5 Les critères réels de conception . . . . . . 12.6 Variantes du DES ........................ 12.7 A quel point le DES est-il sûr de nos j o u r s ? . .
281 281 286 296 302 . . 311 312 318
13 A u tres a lgorith m es d e ch iffrem en t par b lo cs 13.1 L ucifer . ................................................................. 13.2 M a d r y g a ........ 13.3 N e w D E S ..................................................................................................... 13.4 F E A L ............................................................................................................ 13.5 R E D O C ......................................................................................................... 13.6 L O K I ............................................................................................................ 13.7 K hufu et K hafre ........................................................................................ 13.8 R C 2 ............................................................................................................... 13.9 I D E A ............................................................................................................ 13.10 M M B ............................... ............................................................. 13.11 C A - 1 . 1 ......................................................................................................... 13.12 S k i p j a c k .....................................................................................................
321 321 322 325 325 331 332 335 337 338 345 346 347
14 E n co re d ’au tres algorith m es de ch iffrem ent par b lo c s 14.1 G O S T ........................................................................................................... 14.2 C A S T ............................................................................................................ 14.3 B l o w f is h ..................................................................................................... 14.4 S A F E R ....................................... ................................................................ 14.5 3 - W A Y ................................ .................................................................. 14.6 C R A B ........................................................................................................... 14.7 SX A L 8 et M B A L ..................................................................................... 14.8 R C 5 .............................................................................................................. 14.9 Autres algorithmes dechiffrementpar blocs . . 14.10 Théorie des algorithmes dechiffrement par blocs . 14.11 Utilisation de fonction dehachageà sens unique...................................... 14.12 Choisir un algorithme de chiffrement par blocs .
351 351 354 355 359 361 362 364 364 366 366 372 375
15 C o m b in a iso n d ’ algorith m es de ch iffrem ent par b lo cs 15.1 Surchiffrement double ..................................................................... 15.2 Surchiffrement t r i p l e ............................................ 15.3 Doublement de la longueur deb l o c ........................................................... 15.4 Autres schémas de surchiffrement . 15.5 Troncature de clef (dans C D M F ) . 15.6 Blanchim ent.................................................................................................. 15.7 Mise en cascade de plusieursalgorithm es.................................................
377 377 379 384 384 387 387 388
TABLE DES MATIÈRES 15.8
IX
Combiner plusieurs algorithmes de chiffrement par b l o c s ...................
389
16 G én érateu rs de su ites aléa toires et ch iffrem ent en con tin u 16.1 Générateurs pseudo-aléatoires de suites................................................... 16.2 Registres à décalage à rétroaction lin é a ir e ............................................. 16.3 Conception et analyse d’algorithmes de chiffrement en continu . . . . 16.4 Chiffrement en continu à base de R D R L ................................................ 16.5 A 5 ................................................................................................................ 16.6 H ugues X P D / K P D ................................................................................ 16.7 N a n o t e q ................................................................................................... 16.8 R a m b u t a n ................................................................................................ 16.9 Générateurs a d d i t if s ................................................................................ 16.10 G ifford ................................................................................................... 16.11 A lgorithm e M ...................................................................................... 16.12 P K Z IP ......................................................................................................
391 391 395 402 403 412 413 413 414 414 416 417 417
17 A u tre s algorith m es d e ch iffrem en t e n con tin u et générateurs d e suites v raim en t aléatoires 17.1 R C 4 ............................................................................................................. 17.2 S E A L .......................................................................................................... 17.3 W A K E ....................................................................................................... 17.4 Registres à décalage à rétroaction avec r e t e n u e .................................. 17.5 Chiffrement en continu à base de R D R R .............................................. 17.6 Registres à décalage à rétroaction non linéaire..................................... 17.7 Autres algorithmes de chiffrement en c o n t i n u ..................................... 17.8 Approche par la théorie des systèm es.................................................... 17.9 Approche par la théorie de la com plexité.............................................. 17.10 Autres approches à la conception d ’algorithmes de chiffrement en conti nu ................................................................................................................. 17.11 Chiffrement en continu en cascade ........................................................ 17.12 Choisir un algorithme de chiffrement en con tin u .................................. 17.13 Génération de plusieurs flux à partir d’un seul générateur pseudo aléatoire de suites........................................................................................ 17.14 Générateurs de suites vraiment aléatoires ........................................... 18 F on ction s d e hachage à sens u n iqu e 18.1 Introduction................................................................................................ 18.2 Snefru ................................................................................................... 18.3 N -H a s h ...................................................................................................... 18.4 M D 4 ............................................................................................................. 18.5 M D 5 ............................................................................................................ 18.6 M D 2 ............................................................................................................ 18.7 Algorithme sûr de hachage SHA .......................................................... 18.8 R I P E - M D ................................................................................................ 18.9 H A V A L ...................................................................................................... 18.10 Autres fonctions de hachage à sens u n iq u e ........................................... 18.11 Utilisation d ’algorithmes de chiffrement par b l o c s .............................. 18.12 Utilisation d ’algorithmes à clef p u b liq u e ..............................................
419 419 420 423 424 427 433 435 436 437 439 441 442 442 444 453 453 455 457 458 460 465 465 469 469 470 471 479
X
TABLE DES MATIÈRES 18.13 Choix d’une fonction de hachage à sensu n i q u e .................................... 18.14 Codes d ’authentification de m essages.....................................................
479 479
19 A lg o rith m e s à c le f p u b liq u e 19.1 Introduction................................................................................................ 19.2 Algorithmes à em pilem ent........................................................................ 19.3 R S A ............................................................................................................. 19.4 P ohlig - H ellman ................................................................................. 19.5 R a b i n .......................................................................................................... 19.6 E l G a m a l ................................................................................................... 19.7 M c E liece ................................................. 19.8 Cryptosystèmes à courbes elliptiqu es..................................................... 19.9 L U C ............................................................................................................. 19.10 Automates fin is ..........................................................................................
485 485 486 491 499 500 501 504 505 506 507
20 A lg o rith m e s d e sign atu re n u m ériqu e à c le f p u b liq u e 20.1 Algorithme de signature numérique D SA ............ 20.2 Variantes de D SA .................................................................................... 20.3 Algorithme de signature numérique G O S T . 20.4 Schémas de signature numérique à basede logarithmes discrets . . 20.5 O ng Schnork S h a m ir . . 20.6 E S I G N ...................................................................................................... 20.7 Automates cellulaires................................................................................. 20.8 Les autres algorithmes à clef publique ................................................
509 509 520 522 523 525 526 527 527
21 Schém as d ’ id en tifica tion 531 531 21.1 F eige - F iat - S hamir .............................................................................. 21.2 G uillou - Q u i s q u a t e r ........................................................................... 536 21.3 Sc h n o r r .................................................................................................... 538 21.4 Convertir un schéma d ’identification en un schéma de signature numé rique .............................................................................................................. 540 22 A lg o rith m e s d ’éch an ge d e clefs 22.1 D iffie - H ellman .................................................................................... 22.2 Protocole point à p o in t............................................................................. 22.3 Protocole à trois passes de Sh a m i r ....................................................... 22.4 C O M S E T .................................................................................................... 22.5 Échange de clefs chiffré............................................................................. 22.6 Négociation de clef fortifiée .................................................................... 22.7 Distribution de clef de conférence et diffusion de s e c r e t.....................
541 541 544 544 545 546 550 551
23 A lg o rith m e s sp éciau x p o u r p r o to c o le s 23.1 Cryptographie à clef publique à clefs multiples.................................... 23.2 Algorithmes de partage de s e c r e t .......................................................... 23.3 Canal s u b lim in a l....................................................................................... 23.4 Signatures numériques incontestables.................................................... 23.5 Signatures numériques à vérificateur d é d ié ........................................... 23.6 Calcul avec données chiffrées....................................................................
555 555 556 560 565 567 569
TABLE DES MATIÈRES 23.7 23.8 23.9 23.10 23.11 23.12 23.13 23.14 23.15 23.16
IV
Pile ou face équitable................................................................................. Accumulateurs à sens unique ................................................................. Divulgation tout ou rien de s e c r e t s ........................................................ Cryptosystèmes équitables et à sûreté intégrée . . . . Preuves à divulgation nulle .................................................................... Signatures en aveugle................................................................................. Transfert in con scien t................................................................................. Calcul réparti s û r ....................................................................................... Chiffrement prob a b iliste.......................................................................... Cryptographie quantique..........................................................................
Le monde réel
24 E x em p les d e réa lisation 24.1 Protocole IBM de gestion de clefs secrètes........................................... 24.2 M I T R E N E T .............................................................................................. 24.3 RNIS .......................................................................................................... 24.4 S T U - I I I ....................................................................................................... 24.5 K e r b e r o s .................................................................................................... 24.6 K r y p t o K n i g h t ....................................................................................... 24.7 SESAME .................................................................................................... 24.8 Architecture cryptographique commune d’I B M .................................. 24.9 Environnement d’authentification I S O .................................................. 24.10 « Privacy-Enhanced Mail » ( P E M ) .......................................................... 24.11 « Message Security Protocol » (M SP ) .................................................... 24.12 « Pretty G ood Privacy » (P G P ) ........................................................... 24.13 Cartes à p u c e .............................................................................................. 24.14 « Public-Key Cryptography Stan dards » (P K C S) ........................................................................................ 24.15 Système de paiement électronique u n iv e r s e l........................................ 24.16 C l i p p e r ....................................................................................................... 24.17 C a p s t o n e .................................................................................................... 24.18 Modèle 3600 du dispositif de sécurité du téléphone d ’A T & T . . . .
xi 570 572 572 575 577 579 579 580 582 584
587 589 589 590 591 593 594 600 600 601 602 606 612 613 615 616 618 620 622 623
25 P o litiq u e 625 625 25.1 « National Security Agency » ( N S A ) ...................................................... 25.2 « National Computer Security Center » (N C SC ).................................... 627 25.3 « National Institute of Standards and Technology »( N I S T ) .............. 628 25.4 R SA D ata Se c u r it y , In c ....................................................................... 632 25.5 « Public Key Partners » ( P K P ) ............................................................... 632 25.6 « International Association for Cryptologie Research »(IACR) . . . 634 25.7 « R A C E Integrity Primitives Evaluation » (R IP E ) . . . . . 634 25.8 « Conditional Access for Europe » ( C A F E ) .......................................... 635 25.9 « ISO/IEC 9979 » ......................................................................................... 636 25.10 Groupes industriels, de défense des libertés civiles, et professionnelles 637 25.11 S c i .c r y p t ................................................................................................... 638 25.12 C y p h e r p u n k s .......................................................................................... 638
xii
TABLE DES MATIÈRES 25.13 25.14 25.15 25.16
Brevets......................................................................................................... Réglementation américaine à l’exportation .................................. Importation et exportation decryptographie............................... L é g a lit é ......................................................................................................
P o stfa ce de M a tt B la ze
V
Code source
639 639 647 648 651
655
D E S .......................................................................................................................... 657 L O K I 9 1 ................................................................................................................. 675 I D E A ....................................................................................................................... 685 G O S T ....................................................................................................................... N701 B l o w f i s h ................................................................................................................ 711 3-W a y ....................................................................................................................... 721 R C 5 .......................................................................................................................... 727 A 5 ............................................................................................................................. 729 S E A L ....................................................................................................................... 735 L ex iq u e anglais—français
741
B ib lio g ra p h ie
747
In d ex
827
Préface Il existe deux types de cryptographie dans le monde: la cryptographie qui empêche votre petite sœur de lire vos fichiers, et la cryptographie qui empêche les principaux gouvernements de lire vos fichiers. Ce livre traite de la deuxième. Je prends une lettre, l’enferme dans un coffre et cache ce coffre quelque part dans New York... si je vous demande ensuite de lire la lettre, il n’est pas question de sécurité: c’est de l’obscurité. Autre exemple : je prends une lettre, l’enferme dans un coffre et vous donne le coffre avec ses spécifications de conception et une centaine d’autres coffres identiques avec leurs combinaisons, de telle manière que vous et les meilleurs perceurs de coffres-forts puissiez étudier le mécanisme de verrouillage... si vous ne pouvez toujours pas ouvrir le coffre contenant la lettre, il est alors question de sécurité. Pendant de nombreuses années, ce type de cryptographie était le domaine exclusif des militaires. La « National Security Agency » américaine et ses contreparties en ex-Union soviétique, au Royaume-Uni, en France, en Israël, et partout ailleurs, ont dépensé des milliards de dollars au jeu très sérieux de la protection de leurs propres communications, tout en essayant de casser toutes celles des autres. Le particulier, avec nettement moins d ’expertise et de budget, était impuissant à protéger sa propre vie privée vis-à-vis de ces gouvernements. Durant ces vingt dernières années, il y a eu une explosion de recherche académique publique en cryptographie. Alors que la cryptographie classique est utilisée depuis longtemps par des citoyens ordinaires, la cryptographie par ordinateur était le domaine réservé des militaires depuis la Seconde Guerre mondiale. De nos jours, la cryptographie à la pointe de l’art est pratiquée en dehors de la protection des murs des agences militaires. Le profane peut maintenant employer des techniques cryptographiques qui le protègent contre les adversaires les plus puissants — à un niveau de sécurité qui pourrait même le protéger des agences militaires pour plusieurs années à venir. Est-ce que l’individu moyen a besoin de ce type de sécurité? Je l’affirme. Il peut prépa rer une campagne politique, il peut discuter de ses impôts, ou avoir une liaison illicite. Il peut concevoir un nouveau produit, discuter d’une stratégie de commercialisation, ou préparer une prise de pouvoir commerciale agressive. Il peut vivre dans un pays qui ne respecte pas le droit à la vie privée de ses citoyens. Il peut faire quelque chose qu’il estime ne pas être illégal mais qui l’est. Peu importe les raisons, ses données et ses communications sont personnelles, privées et ce n’est l’affaire de personne d’autre à part lui. Ce livre est publié en des temps troubles. L’administration C l i n t o n a adopté le pro gramme « Escrowed Encryption Standard» (qui repose sur la puce CLlPPERet la carte F o r t e z z a ) et le projet de loi « Digital Telephony ». Ces deux initiatives tendent à
xiv
Préface
donner au gouvernement la possibilité de mener des surveillances électroniques. Cela repose sur la dangeureuse hypothèse orwelienne que le gouvernement a le droit d ’écouter les communications privées, et qu’il y a anguille sous roche si un citoyen tente de dissimuler un secret au gouvernement. Les lois ont toujours permis de mener une éventuelle surveillance avec l’autorisation des tribunaux. Mais c ’est la première fois que chacun est contreint de participer activement pour rendre sa surveillance possible. Ces initiatives ne sont pas seulement des propositions gouvernementales concernant un domaine obscur, elles sont une tentative préventive et unilatérale d’usurper des pouvoirs qui relevaient de chacun. C l ip p e r et la loi « Digital Telephony » ne protègent pas la vie privée : elles obligent les individus à avoir confiance inconditionnellement dans le Gouvernement quant au respect de leur vie privée. Elle émet l’hypothèse que le Gouvernement fait partie des bons et que tous les citoyens font partie des méchants. Les mêmes autorités légales qui ont placé des écoutes illégales sur les lignes téléphoniques de Martin Luther King Jr. peuvent facilement espionner un téléphone protégé par une puce C l ip p e r . Durant ces cinq dernières années, les autorités de police locales ont été poursuivies pénalement ou civilement dans de nombreuses juridictions — y compris le Maiyland, le Connecticut, le Vermont, la Géorgie, le Missouri et le Nevada — pour avoir placé des écoutes illégales. C ’est une mauvaise idée de déployer une technologie qui pourrait un jour aider un état policier. On peut en tirer la leçon qu’il est insuffisant de se protéger avec des lois, il faut se protéger avec les Mathématiques. Le chiffrement est trop important pour être laissé au gouvernement. Ce livre vous donne les moyens de préserver votre vie privée ; les appareils de chiffrement peuvent être déclarés illégaux, mais l’information ne le sera jamais.
Comment lire ce livre J’ai écrit Applied Cryptography comme un ouvrage de référence exhaustif sur la cryp tographie moderne. J’ai privilégié la lisibiüté du texte sans pour autant sacrifier l’exac titude et la précision. Ce livre ne se veut pas un traité mathématique. Bien que je n’aie pas donné délibérément de fausses informations, j ’ai été cavalier avec la théo rie. Pour ceux qui sont intéressés par le côté formel, il y a de nombreuses références bibliographiques de la littérature académique. Le premier chapitre introduit la cryptographie, définit de nombreux termes et présente brièvement la cryptographie avant l’ère informatique. Les chapitres 2 à 6 (première partie) présentent les protocoles cryptographiques. Les protocoles vont du plus simple (envoyer un message chiffré d ’une personne à l’autre) au plus complexe (jouer à pile ou face par téléphone) et à l’ésotérique (l’échange d ’argent électronique sûr et anonyme). Certains de ces protocoles sont évidents, d’autres sont presque ahurissants. La cryptographie permet de résoudre de nombreux problèmes que la plupart des gens n’ont jamais réalisé qu’il soit possible de les résoudre. Les chapitres 7 à 10 (deuxième partie) présentent les techniques cryptographiques. Les quatre chapitres de cette partie sont tous importants même pour l’utilisation la plus élémentaire de la cryptographie. Les chapitres 7 et 8 traitent des clefs : quelle doit être la longueur d’une clef pour qu’elle soit sûre, comment engendrer les clefs, comment stocker les clefs, comment détruire les clefs, etc. La gestion des clefs est la
Préface
xv
partie la plus difficile de la cryptographie, et est souvent le tendon d’Achille de systèmes cryptographiques qui seraient sinon très sûrs. Le chapitre 9 présente différents moyens d’utiliser les algorithmes cryptographiques, et le chapitre 10 donne les tenants et les aboutissements des algorithmes : comment choisir, réaliser, et utiliser des algorithmes. Les chapitres 11 à 23 (troisième partie) fournissent une liste d ’algorithmes, le livre dé crit finalement les algorithmes. Le chapitre 11 donne des fondements mathématiques. Ce chapitre n’est obligatoire que si vous êtes intéressé par les algorithmes à clef pu blique. Si vous voulez seulement réaliser le DES (ou quelque chose de similaire), vous pouvez passer ce chapitre. Le chapitre 12 décrit le D E S : l’algorithme, son histoire, sa sécurité, et quelques variantes. Le chapitre 13, 14 et 15 décrivent d’autres algo rithmes à clef secrète. Si vous voulez quelque chose de plus sûr que le DES, lisez la section sur ID E A ou sur le DES triple. Si vous voulez prendre connaissance de plu sieurs algorithmes, dont certains pourraient être plus sûrs que le DES, lisez les trois chapitres. Les algorithmes 16 et 17 traitent des algorithmes de chiffrement en continu. Le chapitre 18 concerne les fonctions de hachage à sens unique: M D5 et SHA sont les plus communes bien que j ’en décrive beaucoup d ’autres. Le chapitres 19 décrit les algorithmes à clef publique, le chapitre 20 concerne les algorithmes de signature nu mérique à clef publique. Les algorithmes importants sont R SA , D SA , F ia t - S h a m ir et D if f ie H e l l m a n respectivement. Le chapitre 23 contient des algorithmes à clef publique et des protocoles plus ésotériques ; les mathématiques peuvent se compliquer : attachez votre ceinture. Les chapitres 24 et 25 (quatrième partie) se tournent vers le monde réel de la cryp tographie. Le chapitre 24 décrit quelques réalisations concrètes de ces algorithmes et de ces protocoles, tandis que chapitre 25 aborde le contexte politique qui entoure la cryptographie. Ceux-ci n’ont aucunement la prétention d’être exhaustifs. Enfin, ce livre contient les codes sources de dix des algorithmes de la troisième partie. Je n’ai pas pu inclure autant de codes que je l’aurait souhaité pour des raisons de limitation en place, et sans quoi les codes sources cryptographiques n’auraient pas pu être exportés. (Aussi surprenant que cela puisse paraître, le Département d’Etat amé ricain a autorisé l’exportation de la première édition ce livre avec les codes sources qu’il contenait, mais a refusé l’exportation d’une disquette de codes sources contenant exac tement les mêmes codes sources. Allez savoir.) Un jeu de disquettes inclus bien plus de codes sources que je ne pouvais en donner dans ce livre ; cela constitue probablement la plus grande bibliothèque de codes sources cryptographiques hors des institutions mili taires. Je ne peux envoyer des disquettes de codes sources qu’aux citoyens américains ou canadiens vivant aux Etats-Unis ou au Canada, mais cela devrait heureusement changer un jour. S’il y avait une critique à faire de ce livre, c’est que sa nature encyclopédique le rend moins lisible. C ’est vrai, mais je voulais offrir une seule référence pour ceux qui pour raient rencontrer un algorithme dans la littérature académique ou dans un produit. À ceux qui s’intéressent plus à un cours d’introduction, je présente mes excuses. Beaucoup est fait dans ce domaine. C ’est la première fois que tant de choses ont été rassemblées sous un même chapeau. Même ainsi, il y a de nombreuses choses que le manque de place m’a obligé à laisser de côté. J’ai essayé de couvrir les sujets que je trouvais soit importants, d ’intérêt pratique, ou intéressants. Quand je n’ai pu traiter un sujet en profondeur, j ’ai donné les références des publications qui le font. J’ai fait la chasse aux erreurs du mieux que j ’ai pu, mais de l’avis général c ’est quasi
xvi
Préface
impossible de n’en laisser aucune. La seconde édition contient sûrement moins d’erreurs que la première. Je tiens à votre disposition une liste des errata qui est périodiquement postée au group USENET s c i . c r y p t . Si quelqu’un trouve une erreur, s’il vous plaît, avertissez-moi. Pour chaque erreur, la première personne qui me la signale recevra une copie gratuite de la disquette1.
1. N ote du traducteur : cette offre n ’est valable que pou r l’édition am éricaine de l’ouvrage.
Préface
xvii
Remerciements La liste des gens qui ont contribué à la réalisation de ce livre semble infinie mais ils méritent tous d ’être mentionnés. Je tiens à remercier Don A l v a r e z , R oss A n d e r s s o n , Dave B a l e n s o n , Karl B a r r u s , Steve B e l l o v i n , Dan B e r n s t e i n , Eli B i h a m , Joan B o y a r , Karen C o o p e r , W hit D if f ie , Joan F e i g e n b a u m , Phil K a r n , Neal K o b l i t z , Xuejia L a i , Tom L e r a n t h , Mike M a r k o w i t z , Ralph M e r k l e , Bill P a t t o n , Peter P e a r s o n , Charles P f l e e g e r , Ken P iz z i n i , Bart P r e n e e l , Mark R io r d a n , Joachim S c h u r m a n , et Marc S c h w a r t z pour avoir lu et corrigé tout ou partie du ma nuscrit de la première édition; Marc VÀUCLAIR pour avoir traduit la première édi tion en français ; Abe A b r a h a m , Ross A n d e r s o n , Dave B a n i s a r , Steve B e l l o v i n , Edi B i h a m , Matt B is h o p , Matt B l a z e , Gary C a r t e r , Jan C o m e n is c h , Claude C r é p a u , Joan D a e m e n , Jorge D a v i l a , Ed D a w s o n , Whit D if f ie , Cari E l l is o n , Joan F e i g e n b a u m , Niels F e r g u s o n , Matt F r a n k l i n , Rosario G e n n a r o , Dieter G ollm ' a n n , Mark G o r e s k y , Richard G r a v e m a n , Stuart H a b e r , Jingman H e , bob H o g u e , Kenneth I v e r s e n , Markus J a k o b s s o n , Burt K a l i s k i , Phil K a r n , John K e l s e y , John K e n n e d y , Lars K n u d s e n , Paul K o c h e r , John L a d w i g , Xuejia L a i , Arjen L e n s t r a , Paul L e y l a n d , Mike M a r k o w i t z , Jim M a s s e y , Bruce M c N a i r , William H u g h M u r r a y , Roger N e e d h a m , Clif N e u m a n , Kaisa N y b e r g , Luke O ’ C o n n o r , Peter P e a r s o n , René P e r a l t a , Bart P r e n e e l , Yisrael R a d a i , Matt R o b s h a w , Michael R o e , Phil R o g a w a y , Avi R u b i n , Paul R u b i n , Selwyn R u s s e l l , Kazue S a k o , Mahmoud S a l m a s i z a d e h , Markus S t a d l e r , Dmitry T i t o v , Jimmy U p t o n , Marc V a u c l a i r , Serge V a u d e n a y , Gideon Y u v a l , Glen Z o r n , et plusieurs employé anonymes du gouvernement américain pour avoir lu et édité plusieurs parties de la seconde édition ; Lawrie B r o w n , Leisa C o n d i e , Joan D a e m e n , Peter G u t m a n n , Alan I n s l e y , Chris J o h n s t o n , John K e l s e y , Xuejia L a i , Bill L e i n i n g e r , Mark M a r k o w i t z , Richard O u t e r b r i d g e , Peter P e a r s o n , Ken P iz z i n i , Colin P l u m b , Steph R a v a n o n a , R S A D a t a S e c u r i t y , I n c ., Michael R o e , Michael W o o d , et Phil Z i m m e r m a n n pour m’avoir fourni des codes sources ; Paul M a c N e r l a n d pour avoir réalisé les figures de la première édition; Karen C o o p e r pour son travail de secrétaire de rédaction pour la seconde édition ; Beth F r i e d m a n pour avoir revu et corrigé la seconde édition ; Carol K e n n e d y pour avoir fait l’index de la seconde édi tion; les lecteurs de s c i .c r y p t et de la liste de courrier électronique Cypherpunks pour avoir commenté des idées, avoir répondu à des questions et avoir corrigé des er reurs dans la première édition ; Randy S e u s s pour avoir fourni un accès à l’iNTERNET ; Jeff D u n t e m a n n et Jon E r ic k s o n pour m ’avoir aidé à commencer ; la famille I n s l e y pour avoir donné l’impulsion, les encouragements, le soutien, les conversations, l’amitié et les dîners ; et A T & T B e l l L a b s pour m ’avoir licencié et pour avoir rendu tout cela possible. Ces personnes m’ont aidé à créer un livre bien meilleur que ce que j ’aurais pu faire tout seul. Bruce S c h n e ie r Oak Park, 111.
[email protected]
A propos de l’auteur Bruce S c h n e ie r est le président de C o u n t e r p a n e S y s t e m s , une entreprise de conseil en cryptographie et sécurité en informatique, située à Oak Park dans l’Illinois aux États-Unis. Bruce S c h n e ie r est aussi l’auteur de E-Mail Security (J o h n W il e y & F il s , 1995) et Protect Your Macintosh (P e a c h p i t P r e s s , 1994) ; et a écrit des dou zaines douzaines d ’articles dans les principales revues. Il est l’un des éditeurs associé de Dr. Dobb’s Journal où il gère la colonne « Algorithms Alley », il est aussi éditeur associé de Computer and Communication Security Reviews. Bruce S c h n e ie r officie dans le conseil de direction de VInternational Association for Cryptologie Research, il est membre du conseil consultatif du Electronic Privacy Information Center, et il fait parti du comité de programme du New Security Paradigms Workshop. En plus de tout cela, il trouve du temps pour donner de fréquents exposés sur la cryptographie, la sécurité en informatique, et la confidentialité.
Chapitre 1
Principes de base 1.1
Terminologie
Expéditeur et destinataire Supposons qu’un expéditeur veut envoyer un message à un destinataire. Cet expéditeur veut envoyer le message de manière sûre: il veut s’assurer qu’aucune oreille indiscrète ne puisse s’informer du message.
Messages et chiffrement Un message est appelé te x te en clair. Le processus de transformation d ’un message de telle manière à le rendre incompréhensible est appelé chiffrem ent (ou en cry p tion ). Le résultat de ce processus de chiffrement est appelé te x te chiffré (ou encore c r y p to gram m e). Le processus de reconstruction du texte en clair à partir du texte chiffré est appelé déch iffrem en t (ou d é cry p ta g e ). Ces différents processus sont illustrés par la figure 1.1.
FlG. 1.1 — Chiffrement et déchiffrement L’art et la science de garder le secret de messages est appelé cry p to g ra p h ie pratiquée par des cry p to g ra p h e s. Les cry p ta n a lystes pratiquent la cry p ta n a lyse qui est l’art de décrypter des messages chiffrés. La branche des mathématiques qui traite de la cryp tographie et de la cryptanalyse s’appelle la cr y p to lo g ie et ses pratiquants sont appelés cryp tologu es. De nos jours, presque tous les cryptologues sont des mathématiciens théoriciens par la force des choses. Le texte en clair est noté A L Ce peut être une suite de bits, un fichier de texte, un enregistrement de voix numérisé, ou une image vidéo numérique. Du point de vue de
Chapitre 1
2
Principes de base
l’ordinateur, A i n’est rien d’autre que de l’information binaire1. Le texte en clair peut être transmis ou stocké. Dans tous les cas, A i est le message à chiffrer. Le texte chiffré est noté C. C ’est aussi de l’information binaire, parfois de la même taille que A i, parfois plus grand2. La fonction de chiffrement, notée E , transforme A i en C. Ce qui en notation mathématique s’écrit : E ( M ) = C.
La fonction inverse, notée D, de déchiffrement transforme C en A i : D{C) = A i.
Comme le but de toutes ces opérations n’est rien d’autre que de retrouver le message en clair à partir de la version chiffrée de ce même message, l’identité suivante doit être vérifiée : D ( E ( M ) ) = A i.
Authentification, intégrité, non désaveu En plus de la confidentialité, on attend souvent de la cryptographie d’accomplir d ’autres tâches: 1. A u th e n tifica tio n . Le destinataire d ’un message doit pouvoir s’assurer de son origine. Un intrus ne doit pas être capable de se faire passer pour quelqu’un d ’autre. 2. In tég rité. Le destinataire d ’un message doit pouvoir vérifier que celui-ci n’a pas été modifié en chemin. Un intrus doit être incapable de faire passer un faux message pour un légitime. 3. N o n désaveu. Un expéditeur ne doit pas pouvoir, par la suite, nier à tort avoir envoyé un message. Ce sont des exigences vitales en matière d ’interactions sociales par ordinateur; elles sont l’analogue des rencontres face à face. Quelqu’un est-il celui qu’il prétend être? La pièce d’identité, le permis de conduire, le diplôme de médecin, ou le passeport d’une personne sont-ils valides? Ce sont les questions auxquelles l’authentification, l’intégrité, et le non désaveu répondent.
Algorithmes cryptographiques Un a lgorith m e cry p to g ra p h iq u e est une fonction mathématique utilisée pour le chiffrement et le déchiffrement3. 1. A partir du chapitre suivant, ce livre ne traite que de cryptographie appliquée à de l’inform ation binaire. 2. En com binant com pression et chiffrement, C peut être plus petit que A 4. Toutefois, en général, le chiffrement à lui seul ne fait pas l’opération de com pression. 3. Généralement, un algorithm e cryptographique com prend deux fonctions: une pour chiffrer et l’autre pou r déchiffrer.
1.1
Terminologie
3
Si la sécurité d’un algorithme est basée sur le fait que celui-ci est tenu secret, on parlera alors d ’algorithme restreint. De tels algorithmes ne présentent plus qu’un intérêt historique car de nos jours ils sont inadéquats pour les besoins actuels de sécurité. Un groupe d ’utilisateurs important ou variable ne peut utiliser de tels algorithmes car chaque fois qu’un membre quitte le groupe, tous les autres doivent se mettre à utiliser un autre algorithme. Si quelqu’un révèle accidentellement le secret, tout le mende doit changer d’algorithme. Encore plus accablant, les algorithmes restreints ne permettent aucun contrôle de qualité et aucune standardisation. Chaque groupe d’utilisateurs doit avoir son propre algorithme. Un tel groupe ne peut pas utiliser de produits tout faits, matériels ou logiciels, vendus dans le commerce; un espion peut acheter le même produit et apprendre l’algorithme. Ils leur faut écrire leur propres algorithmes et les programmer eux même. S’il n’y a pas de bon cryptographe dans le groupe, ils ne sauront pas s’ils ont un algorithme sûr. Malgré cela, les algorithmes restreints sont très populaires pour les applications à bas niveau de sécurité. Les utilisateurs ne réalisent pas, ou bien ne se soucient pas des problèmes de sécurité inhérents à leur système. La cryptographie moderne résoud ce problème avec une clef, notée k. Cette clef peut prendre une des valeurs parmi un grand nombre de valeurs possibles. L ’ensemble des valeurs possibles d ’une clef est appelé esp ace d es clefs. Les opérations de chiffrement et de déchiffrement utilisent toutes les deux cette clef (i.e., elles dépendent de la clef et ceci est dénoté par l’indice k), aussi les fonctions s’écrivent de la manière suivante: E k{ M ) = C D k(C) = M .
Ces fonctions vérifient la propriété suivante (voir la figure 1.2): : D k(Ek( M ) ) = M .
FlG. 1.2 - Chiffrement et déchiffrement avec une clef Certains algorithme utilisent des clefs différentes pour le chiffrement et le déchiffrement(voir la figure 1.3). Dans ce cas, la clef de chiffrement, notée ki, est différente de la clef de déchiffrement, notée k,2 - Les relations suivantes décrivent un tel cryptosys tème: E kl( M ) = C D k2(C) - M D k2(Ekl( M ) ) = M . Avec ces algorihtmes, toute la sécurité réside dans la (ou les) clef(s), et non dans les détails de l’algorithme. Ceci implique que l’algorithme peut être publié et anlysé.
Chapitre 1
4 Clef de chiffrement
Texte en clair
1
Principes de base
Clef de déchiffrement
Texte chiffré
Chiffrement
.
Texte en clair original
Déchiffrement
F ig. 1.3 - Chiffrement et déchiffrement avec deux clefs
On peut fabriquer en masse un produit utilisant cet algorithme. Peu importe qu’une espionne connaisse votre algorihtme; si elle ignore votre clef, elle ne pourra pas lire vos messages. Un cryptosystème est composé d ’un algorithme, et de tous les textes en clairs, textes chiffrés, et clefs possibles.
Algorithmes à clef secrète Il y a deux types principaux d ’algorithmes à base de clefs : à clef secrète ou à clef pu blique. Les algorith m es à c le f secrète sont des algorithmes où la clef de chiffrement peut être calculée à partir de la clef de déchiffrement ou vice versa. Dans la plupart des cas, la clef de chiffrement et la clef de déchiffrement sont identiques. Pour de tels algorithmes, l’émetteur et le destinataire doivent se mettre d ’accord sur une clef à utiliser avant d’échanger des messages. Cette clef doit être gardée secrète. La sécurité d ’un algorithme à clef secrète repose sur la clef : si celle-ci est dévoilée, alors n’importe qui peut chiffrer ou déchiffrer des messages dans ce cryptosystème. Le chiffrement et le déchiffrement dans un algorithme à clef secrète sont notés : E k{ M ) = C D k(C) = M .
Les algorithmes à clef secrète peuvent être classés en deux catégories. Certains opèrent sur le message en clair un bit à la fois. Ceux-ci sont appelés algorith m es de chif frem ent en continu. D ’autres opèrent sur le message en clair par groupes de bits. Ces groupes de bits sont appelés b lo cs, et les algorithmes correspondants sont appelés a lgorith m es d e ch iffrem en t par b lo cs. Pour des algorithmes réalisés sur ordina teur, la taille typique des blocs est de 64 bits — ce qui est assez grand pour interdire l’analyse et assez petit pour être pratique4.
Algorithmes à clef publique Les algorith m es à c le f p u b liq u e sont différents. Ils sont conçus de telle manière que la clef de chiffrement soit différente de la clef de déchiffrement. De plus, la clef de déchiffrement ne peut pas être calculée (du moins en un temps raisonnable) à partir de la clef de chiffrement. De tels algorithmes sont appelés « à clef publique » parce que la clef de chiffrement peut être rendue publique : n ’importe qui peut utiliser la clef de 4. Autrefois, avant l’utilisation de l’ou til inform atique, les algorithm es manipulaient généralement le texte en clair caractère par caractère. Vous pouvez considérer de tels algorithm es com m e un chiffrement en continu d ’ un caractère à la fois.
1.1
Terminologie
5
chiffrement pour chiffrer un message mais seul celui qui possède la clef de déchiffrement peut déchiffrer le message chiffré résultant. Dans de tels systèmes, la clef de chiffrement est appelée c le f p u b liq u e et la clef de déchiffrement est appelée c le f privée. La clef privée est aussi parfois appelée c le f secrète mais pour éviter toute confusion avec les algorithmes à clef secrète, ce terme ne sera pas utilisé ici. Le chiffrement en utilisant la clef publique k est noté : E k( M ) = C .
Bien que les clefs publique et privée soient différentes, le déchiffrement avec la clef privée correspondante est noté : D k(C) = M . Parfois, les messages seront chiffrés avec la clef privée et déchiffrés avec la clef publique ; une telle technique est utilisée pour les signatures numériques (voir § 2.6). Malgré le risque de confusion possible, ces opérations seront notées : E k{ M ) = C D k(C) = M .
Cryptanalyse Le but principal de la cryptographie est de préserver le texte en clair de l’indiscré tion des espions (aussi appelés adversaires, attaquants, intercepteurs, intrus, oppo sants, oreilles indiscrètes, cryptanalystes, décrypteurs, ou tout simplement ennemis). On suppose que les espions ont plein accès aux communications entre l’expéditeur et le destinataire. La cryptanalyse est la science de la reconstitution du texte en clair sans connaître la clef. Une cryptanalyse réussie peut fournir soit le texte en clair, soit la clef. La cryptanalyse peut également mettre en évidence les faiblesses d’un cryptosystème qui peuvent éventuellement faciliter les attaques contre celui-ci5. Une tentative de cryptanalyse est appelée attaque. Un des axiomes fondamentaux de la cryptographie, énnoncé pour la première fois par l’hollandais A. Kerckhoffs au dixneuvième siècle, est que l’ennemi possède tous les détails de l’algorithme et qu’il ne lui manque que la clef spécifique utilisée pour le chiffrement [795]6. Bien que cela ne soit pas toujours le cas dans le monde réel de la cryptanalyse, c ’est toujours vrai dans le monde académique de la cryptanalyse, et c ’est de toute façon une bonne assertion dans le monde réel de la cryptanalyse. Si l’on ne sait pas casser un algorithme même en sachant comment il fonctionne, on ne sait certainement pas le casser sans cette connaissance. Il y a quatre types génériques d’attaques cryptanalytiques. Il va de soi que chacune d’entre elles repose sur l’hypothèse que le cryptanalyste dispose de la connaissance complète de l’algorithme de chiffrement : 1. L ’a ttaq u e à te x te ch iffré seu lem en t. Le cryptanalyste dispose du texte chif fré de plusieurs messages, tous ayant été chiffrés avec le même algorithme. La 5. La perte d ’ une clef par des moyens autres que la cryptanalyse est appelée com prom ission. 6. Bien sûr, on peut supposer que la C IA n ’ a pas l’habitude de com m uniquer au M ossad quoique ce soit au sujet de ses algorithm es. Bien que le M ossad le découvre de toute façon...
Chapitre 1
6
Principes de base
tâche du cryptanalyste est de retrouver le texte en clair du plus grand nombre de messages possible ou mieux encore de trouver la ou les clefs qui ont été utili sées pour chiffrer les messages ce qui permettrait de déchiffrer d’autres messages chiffrés avec ces mêmes clefs. Données: Ci = E k ( M i ) , C 2 = E k ( M 2),...,C i = E k ( M t ). Requis: Soit A i i , M 2, - . , M i , soit k, soit un algorithme permettant de déduire à partir de Ci+i = E k { M i + 1 ).
M i+ 1
2. L ’a tta q u e à te x te en cla ir con n u . Le cryptanalyste a non seulement accès aux textes chiffrés de plusieurs messages mais aussi aux textes en clair correspondants. La tâche est de retrouver la ou les clef(s) utilisées pour chiffrer ces messages ou un algorithme qui permet de déchiffrer n’importe quel nouveau message chiffré avec la même clef. D o n n é e s: M k,C i
=
E k { M i ) , M 2,C2 = E k ( M 2) , . . . , M t ,Ct — E k { M r).
R eq u is : Soit k, soit un algorithme permettant de déduire A f,+ i à partir de C i+ i = Ek{M.r+ 1). 3. L ’a ttaq u e à te x te en cla ir c h o is i7. Non seulement le cryptanalyste a accès aux textes chiffrés et aux textes en clair mais de plus il peut choisir les textes en clair à chiffrer. Cette attaque est plus efficace que l’attaque à texte en clair connu car le cryptanalyste peut choisir des textes en clair spécifiques qui donneront plus d ’informations sur la clef. La tâche consiste à retrouver la ou les clefs utilisées pour chiffrer ces messages ou un algorithme qiii permette de déchiffrer n’importe quel nouveau message chiffré avec la même clef. D o n n é e s: M i , C i = E k ( M \ ) , M 2,C2 = E k ( M 2) , . . . , M i , C t = E k ( M %), où le cryptanalyste choisit A 4 i , A 4 2,...,A 4 i. R e q u is : Soit k , soit un algorithme permettant de déduire JAt+i à partir de f'ï+l -4. L ’attaq u e à te x te en clair ch oisi a d a p ta tiv e 8. C ’est un cas particulier de l’attaque à texte en clair choisi. Non seulement le cryptanalyste peut choisir les textes en clair mais il peut également adapter ses choix en fonction des textes chiffrés précédents. Dans une attaque à texte en clair choisi, le cryptanalyste est juste autorisé à choisir un grand bloc de texte en clair au départ tandis que dans une attaque à texte en clair adaptative, il choisit un bloc initial plus petit et ensuite il peut choisir un autre bloc en fonction du résultat pour le premier et ainsi de suite. Il y a au moins trois autres types d’attaques cryptanalytiques. 1. L ’ atta qu e à te x te ch iffré choisi. Le cryptanalyste peut choisir différents textes chiffrés à déchiffrer. Les textes déchiffrés lui sont alors fournis. Par exemple, le cryptanalyste a un dispositif qui ne peut être désassemblé et qui fait du déchif frement automatique, sa tâche est de retrouver la clef. 7. Parfois appelée au point suivant. 8. Parfois appelée
«
attaque à texte en clair choisi statique
«
attaque à texte en clair choisi dynamique
»
par opp osition à la m éthode décrite ».
1.1
Terminologie D o n n é e s: C i,A li
7
=
£>a..(Ci),C2,A12
=
D k (C 2) , —, C i , M t = D k (C i).
R e q u is : k. Ce type d’ attaque est principalement applicable aux cryptosystèmes à clef pu blique et sera illustrée dans le paragraphe 19.3. Une attaque à texte chiffré choisi fonctionne parfois pour les cryptosystèmes à clef secrète9. 2. L ’a ttaq u e à c le f ch oisie. Cela n’est pas une attaque où le cryptanalyste peut choisir la clef; il est seulement au courant de quelques relations entre différentes clefs. C ’est étrange et obscur. Ce n’est pas très pratique. Nous y reviendrons au paragraphe 12.4. Les attaques à texte en clair connu et les attaques à texte en clair choisi sont plus courantes que vous ne pourriez l’imaginer. Il arrive qu’un cryptanalyste dispose du texte en clair d ’un message ou qu’il soudoie quelqu’un pour chiffrer un message choisi. Parfois, vous n’avez même pas besoin de soudoyer quelqu’un : si vous donnez un mes sage à un ambassadeur, il y a de fortes chances pour que ce message soit chiffré et envoyé à son pays d ’origine pour évaluation. Beaucoup de messages ont des en-têtes et des conclusions qui peuvent être connues ou devinées par le cryptanalyste. Le code source chiffré est particulièrement vulnérable à cause de l’apparition fréquente des mots clefs: # d efin e, s tr u c t, e ls e , return. Le code exécutable chiffré souffre de la même vulnérabilité : dans ce cas ce sont les fonctions, les structures de boucles, etc. qui sont en cause. Il est connu que des attaques à texte en clair connu (et même à texte en clair choisi) ont été menées avec succès durant la Seconde Guerre mondiale. Le livre de David K a h n [468, 469, 470] donne quelques exemples historiques de ce type d’attaques. Et n’oubliez pas l’axiome de Kerckhoffs: ne comptez pas sur un cryptosystème dont la résistence réside dans le fait que l’ennemi ne sait pas comment fonctionne votre algorithme. Vous vous trompez si vous croyez qu’il vaut mieux garder secret les détails de votre algorithme plutôt que de laisser la communauté scientifique l’analyser. De plus, il serait naïf de penser que personne ne désassemblera votre code exécutable pour reconstruire votre algorithme10. Les meilleurs algorithmes dont nous disposions sont ceux qui ont étés rendus publics et attaqués par les meilleurs cryptographes au monde, et qui ne sont toujours pas cassés11. Les cryptanalystes n’ont pas toujours accès à l’algorithme — c ’était le cas quand les Etats-Unis ont cassé le code diplomatique japonais, P U R P L E , pendant la Seconde Guerre mondiale [795] mais la plupart du temps ils y ont accès. Si l’algorithme est utilisé dans un programme commercial de sécurité, c ’est seulement une question de temps et d ’argent pour désassembler le programme et retrouver l’algorithme. Si l’algorithme est utilisé dans un système militaire de communication, c’est aussi une question de temps et d ’argent pour acheter (ou voler) l’équipement et reconstruire l’algorithme. Il y a beaucoup de cas historiques où les cryptanalystes ne connaissaient pas l’algorithme ; parfois ils l’ont cassé, parfois ils ont échoué. Dans tous les cas il est irréaliste de compter sur la confidentialité de l’algorithme. 9. Une attaque â texte en clair choisi menée de front avec une attaque â texte chiffré choisi est parfois appelée a tta q u e à te x te choisi. 10. C eci est arrivé en 1994 avec l’algorithm e R C 4 voir la section 17.1 11. La « N ational Security A gen cy » garde ses algorithm es secrets, mais les meilleurs cryptographes travaillent dans ses murs. D e plus, ils s’échangent leurs algorithm es les uns les autres, s’ appuyant sur leurs pairs pour déceler toute faiblesse dans leurs travaux.
Chapitre 1
8
Principes de base
Ceux qui clament avoir un système inviolable seulement parce qu’ils ne peuvent pas eux-mêmes le casser sont soit des génies, soit des fous. Malheureusement, il y en a plus de la seconde espèce de par le monde. Attention à ceux qui vantent les vertus de leur algorithme mais qui refusent de le rendre public : avoir confiance en leur algorithme est comme faire confiance à un remède de charlatan. Pour différencier les bons algorithmes des mauvais, les bons cryptographes acceptent le regard critique de leurs pairs.
Sécurité des cryptosystèmes Les différents algorithmes ont des niveaux de sécurité divers, plus ou moins difficiles à casser. Si le coût nécessaire pour casser un algorithme dépasse la valeur de l’information chiffrée, alors cet algorithme est probablement sûr. Si le temps nécessaire pour casser un algorithme est plus long que le temps durant lequel l’information chifrée doit rester secrète, alors cet algorithme est probablement sûr. S’il faut plus d’information pour casser l’algorithme qu’il n’en a été chiffré avec la même clef, alors votre algorithme est probablement sûr. Je dis « probablement » car il est toujours possible qu’une nouvelle avancée soit faite en cryptanlyse. D ’un autre côté, une information perd de sa valeur avec le temps. Il est important que la valeur d’une information reste toujours inférieure au coût nécessaire pour briser la protection qui l’entoure. Lars Knudsen a classé ces différentes manières de casser un algorithme. Les voici par ordre décroissant de sévérité: 1. C assage co m p le t. Un cryptanalyste trouve la clef k telle que Dk(C) = Ai. 2. O b te n tio n g lob a le. Un cryptanalyste trouve un algorithme de remplacement A équivalent à Dy.(C) sans connaître k. 3. O b te n tio n locale. Un cryptanalyste trouve le texte en clair d ’un message chiffré qu’il a intercepté. 4. O b te n tio n d ’ in fo rm a tio n Un cryptanalyste glane quelque information à pro pos du texte en clair ou de la clef. Cette information pourrait être certains bits de la clef, un renseignement sur la forme du texte en clair, et ainsi de suite. Un algorithme est in con d ition n ellem en t sûr si — peu importe la quantité de texte chiffré dont le cryptanalyste dispose — il n’y a pas d ’information suffisante pour re trouver le texte en clair. De fait, seul le masque jetable (voir § 1.5) est invulnérable étant donné des ressources infinies. Tous les autres cryptosystèmes sont vulnérables à une attaque à texte chiffré seulement, simplement en essayant toutes les clefs possible une par une et en regardant si le texte en clair résultant a un sens. Ceci s’appelle une attaque exh a u stive (voir la section 7.1). La cryptographie se préoccupe plus particulièrement de cryptosystèmes invulnérables par calcul. Un algorithme est considéré in vu ln érable par ca lcu l (ou parfois qualifié de fort), s’il ne peut pas être cassé avec les ressources disponibles actuellement et dans le futur. Ce qui constitue ces « ressources disponibles » est ouvert à l’interprétation.
1.2
Steganographie
9
On peut mesurer la compiexité(voir la section 7.1) d ’une attaque de l’une ou l’autre des manières suivantes: 1. C o m p le x ité en in form a tion . La quantité d’information nécessaire en entrée pour l’algorithme. 2. C o m p le x ité en tem ps. Le temps nécessaire pour achever l’attaque. Ceci est aussi appellé effort. 3. C o m p le x ité en esp a ce. La quantité de mémoire nécessaire à l’attaque. Comme règle de base, la complexité d ’une attaque est prise comme le minimum de ces trois facteurs. Pour certaines attaques, il faut jongler entre les trois complexités: une attaque peut être plus rapide au prix de besoins en mémoire plus importants. Les complexités sont exprimées en un ordre de grandeur. Si un algorithme a, par exemple, un effort de 2128, alors il faut 2128 opérations pour le casser12. Peu importe, si vous faites l’hypothèse que vous aurez suffisamment de puissance de calcul pour faire un million d ’opérations par seconde et que vous mettiez un million de processeurs en parallèle à la tâche, cela prendra encore 1019 années pour retrouver la clef pour l’exemple donné plus haut. Cela correspond à un milliard de fois l’âge de l’univers. Tandis que la complexité d’une attaque est constante (c’est-à-dire, jusqu’à ce qu’un cryptanalyste trouve une meilleure attaque), la puissance de calcul est tout sauf constante. Durant ce dernier demi-siècle, il y a eu des progrès phénoménaux en puis sance de calcul et il n’y pas de raison de penser que cela s’arrêtera si tôt. Nombre d ’attaques cryptanalytiques sont très bien adaptées aux machines parallèles : la tâche peut être morcelée en milliards de petites tâches et aucun des processeurs ne doit interagir avec les autres. Annoncer qu’un algorithme est sûr simplement parce qu’on ne peut pas le casser avec la technologie d’aujourd’hui est hasardeux. Les bons cryptosys tèmes sont conçus pour être invulnérables même avec les puissances de calcul prévues d ’ici à de nombreuses années dans le futur.
Terminologie historique Historiquement, on appelle c o d e un cryptosystème qui sert au niveau des unités linguis tiques : mots, locutions, phrases, etc. Par exemple, le mot « SOEUR » peut être le texte chiffré pour la phrase entière : « TOURNER À GAUCHE DE 90 DEGRÉS » ; le mot « NONNES » peut être le texte chiffré de « TOURNER À DROITE DE 90 DEGRÉS * ; et les mots « TR A LA LA » peuvent être le texte chiffré pour « OBUSIER » . Les codes de ce type ne sont pas décrits dans ce livre, ils sont présentés dans [795, 796]. Les codes sont utiles dans certaines circonstances seulement. Les chiffres sont utiles en toute cir constance. S’il n’y a pas d ’entrée pour le mot « TROPPO » dans le carnet de codage, il ne peut pas être « codé ». On peut tout chiffrer à l’aide d’un chiffre.
1.2
Steganographie
La stegan ograph ie sert à cacher des messages secrets dans d’autres messages, de sorte que l’existence même du secret est dissimulée. Généralement, l’expéditeur écrit 12. Ces opérations peuvent être com plexes et coûteuses en tem ps de calcul.
10
Chapitre 1
Principes de base
un message innoffensif et dissimule un message secret dans la même feuille de papier. Parmi les astuces historiques, on note les encres invisibles, de minuscules trous d’épingle dans des caractères sélectionnés, d ’infimes changements dans l’écriture manuelle des caractères, des marques au crayon sur un texte tapé à la machine, etc. Plus récemment, on peut cacher des messages secrets dans les images graphiques. Remplacez le dernier bit significatif de chaque point de l’image par celui d’un message; l’image graphique ne changera pas de manière appréciable— la plupart des standards graphiques étant spécifiés pour plus de variations de couleurs que l’œil humain ne peut en saisir— et le destinataire peut récupérer le message. On peut stocker de cette façon un message de 64 kilo-octets dans une image 1024 par 1024 à nivaux de gris. Il existe dans le domaine public différentes applications pour faire cela. Les fo n ctio n s m im étiq u es de Peter Wayner permettent de détourner des messages. Elles modifient un message de sorte que son profil statistique ressemble à quelque chose d’autre: une des rubriques classique du New York Times, une pièce de Shakespeare, ou un groupe de nouvelles sur Internet [1586, 1587]. Cette sorte de stéganographie ne trompera pas une personne mais elle peut tromper de gros ordinateurs passant au crible l’Internet à la recherche de messages intéressants.
1.3
Substitution et transposition
Avant l’avènement des ordinateurs, la cryptographie traitait des cryptosystèmes basés sur les lettres (ou caractères). Les différents algorithmes cryptographiques remplaçaient des caractères par d’autres ou transposaient les caractères. Les meilleurs systèmes faisaient les deux opérations plusieurs fois. C ’est plus complexe de nos jours, mais la philosophie est restée essentiellement la même. La différence majeure est que les algorithmes actuels manipulent les bits au lieu des caractères. Ce n’est finalement qu’un changement de taille d ’alphabet : on passe de 26 éléments à 2 éléments. La plupart des bons algorithmes de cryptographie combinent toujours des substitutions avec des transpositions.
Chiffre à substitution Un chiffre à su b stitu tio n est un chiffre dans lequel chaque caractère du texte en clair est remplacé par un autre caractère dans le texte chiffré. Le destinataire applique la substitution inverse au texte chiffré pour recouvrer le texte en clair. En cryptographie classique, il y a quatre types de base de substitution : - Un ch iffre à su b stitu tio n sim ple est un chiffre dans lequel chaque caractère du texte en clair est remplacé par un caractère correspondant dans le texte chiffré. Les cryptogrammes publiés dans les journaux sont des exemples de chiffres à substitution simple. - Un ch iffre à su b stitu tio n h o m o p h o n iq u e (ou chiffre à su b stitu tion sim ple à rep résen ta tion m u ltip le) est comme un chiffre à substitution simple, sauf qu’à un caractère du texte en clair on fait correspondre plusieurs caractères dans le texte chiffré. Par exemple, « A » peut correspondre à 5, 13, 25 ou 56, « B » peut correspondre à 7, 19, 31 ou 42 ; etc.
1.3
Substitution et transposition
11
- Un ch iffre à su b stitu tio n sim ple par p oly g ra m m es est un chiffre pour lequel les caractères sont chiffrés par blocs. Par exemple, « ABA » peut être chiffré par « RTQ » tandis que « ABB » est chiffré par « SLL ». - Un ch iffre à su b stitu tio n p o ly a lp h a b é tiq u e est composé à partir de plusieurs chiffres à substitution simple. Par exemple, il peut y avoir 5 chiffres à substitution simple utilisés ; celui qui est utilisé dépend de la position du caractère à chiffrer dans le texte en clair. Le fameux ch iffre d e Jules C ésar, dans lequel chaque caractère du texte en clair est remplacé par celui qui se trouve trois places plus loin dans l’alphabet modulo 26 (A est remplacé par D, B est remplacé par E..., W est remplacé par Z, X est remplacé par A, Y est remplacé par B, Z est remplacé par C) est un chiffre à substitution simple. R O T I3 est un programme de chiffrement fréquemment utilisé sur les systèmes UNIX. Dans ce chiffre, A est remplacé par N , B est remplacé par O , etc. Chaque lettre est décalée de 13 places. . Chiffrer un fichier deux fois avec R O T 13 redonne le fichier original : M = R O T 1 3 (R O T 1 3 (A f)).
R O T I3 n’est pas destiné à la sécurité. Il est souvent utilisé dans les messages de cour rier électronique pour cacher du texte pouvant être offensant, pour éviter de dévoiler trop tôt la solution d ’un casse-tête, etc. Ce type de chiffres peut être facilement cassé car le chiffre ne cache pas les fréquences sous-jacentes des différents caractères du texte en clair. En langue anglaise, il ne faut pas plus de 25 caractères du texte chiffré avant qu’un bon cryptanalyste ne puisse reconstruire le texte en clair [1439]. Un algorithme général pour casser ce genre de chiffre est décrit dans [581, 589, 1602, 85, 1481, 1246, 880]. Une bonne réalisation sur ordinateur est donnée dans [700]. Les chiffres à substitution à représentation multiple furent utilisés dès 1401 par le Duché de Mantoue en Italie [795]. Ils sont biens plus difficiles à casser que les chiffres à substitution simple, mais toutefois ils ne cachent pas suffisamment les propriétés statistiques de la langue du texte en clair. Ces chiffres sont trivialement cassés par une attaque à texte en clair connu. Une attaque à texte chiffré seulement est plus difficile mais elle ne prend que quelques secondes par ordinateur. Les détails sont donnés dans [1272]. Les chiffres à substitution simple par polygrammes sont des chiffres dans lesquels les lettres sont chiffrées par groupe. Le procédé PLAYFAIR, inventé en 1854, était utilisé par les Britanniques pendant la Première Guerre mondiale [795]. Il chiffre les lettres par paires. La cryptanalyse de ce procédé est présentée dans [589, 1481, 880]. Le chiffre de H ill est encore un autre exemple de chiffre à substitution simple par polygrammes [734]. Les codes de Huffman sont parfois utilisés pour chiffrer, c ’est un chiffre à substi tution simple par polygrammes qui est peu sûr. Les chiffres à substitution polyalphabétique ont été inventés par Léon BATTISTA en 1568 [795]. Ils furent utilisés par les Nordistes durant la guerre de Sécession. Bien qu’ils puissent être facilement cassés [820, 579, 589, 795] (plus particulièrement avec l’aide d’ordinateurs), nombre de produits commerciaux de sécurité informatique utilisent ce type de chiffre [1392, 1397, 1506]. La méthode pour casser le système de chiffrement à substitution polyalphabétique, utilisé par le traitement de texte WordPerfect, est
Chapitre 1
12
Principes de base
décrite dans [145, 146J. Le chiffre de V i g e n Èr e et le chiffre de B e a u f o r t sont des exemples historiques de chiffres à substitution polyalphabétique. Les chiffres à substitution polyalphabétique utilisent plusieurs clefs monoalphabétiques. Chaque clef est utilisée à tour de rôle pour chiffrer une lettre du texte en clair (la première clef pour le premier caractère, la deuxième clef pour le deuxième, et ainsi de suite). Lorsque toutes les clefs ont été utilisées, on les réutilise en recommençant à la première. S’il y a ainsi 20 clefs monoalphabétiques, tous les 20 caractères on utilise la même clef. Le nombre de clefs utilisées donne la p é rio d e du chiffre. En cryptographie classique, les chiffres avec des périodes longues étaient considérablement plus difficiles à casser que ceux avec des périodes courtes. Grâce aux ordinateurs, il est facile de casser même ceux avec des périodes très longues. Un autre type de chiffre est celui où l’on utilise un autre texte pour chiffrer le texte en clair. Bien que ce chiffre ait une période égale à la longueur du texte en clair, il peut aussi être cassé facilement [578, 795].
Chiffre à transposition Un chiffre à tra n sp o sitio n est un chiffre dans lequel les caractères du texte en clair demeurent inchangés mais dont les positions respectives sont modifiées. Pour appliquer la tra n sp o sitio n sim ple en colon n es, on écrit le texte en clair horizontalement sur un morceau de papier quadrillé de largeur fixe et l’on relève le texte chiffré verticalement (voir la figure 1.4). Pour déchiffrer le texte chiffré, il suffit d ’écrire verticalement celui-ci sur un morceau de papier quadrillé de la même largeur et de lire horizontalement le texte en clair. Texte en clair l ’a s s a s s in
est le d o cteu r
M a t r ix , r e g a r d e z d e r r iè r e l ’h o r l o g e
LASSASSIN ESTLEDOCT EURMATRIX REGARDEZD ERRIERELH 0RL0GE
Texte chiffré : LEERE OASUE RRSTR GRLSL M AIOA EAREG SDTDR ESORE EICIZ LN TXD H
F i g . 1.4 - Transposition simple en colonnes La cryptanalyse de ces chiffres est présentée dans [589, 1481]. Comme les lettres du texte chiffré sont les mêmes que celles du texte en clair, une analyse statistique de la fréquence des lettres montre que chaque lettre se comporte à peu près comme dans la langue d ’origine du texte. Cela donne un indice imprtant au cryptanalyste qui peut essayer différentes techniques pour retrouver l’ordre correct des lettres. Appliquer une deuxième transposition au texte chiffré augmente grandement la sécurité. Il y a des chiffres à transposition encore plus compliqués mais les ordinateurs permettent de les
1.3
Substitution et transposition
13
casser pratiquement tous. Le procédé allemand A D F G V X , utilisé pendant la Première Guerre mondiale, est un chiffre à transposition (plus un chiffre à substitution simple). C ’était un algorithme très compliqué pour l’époque mais il a été cassé par Georges P a i n VIN, un cryptanalyste français [468]. Bien que de nombreux cryptosystèmes modernes utilisent la transposition, c ’est contrai gnant parce que la transposition nécessite beaucoup de mémoire et parfois elle impose que les messages à chiffrer aient une longueur multiple d ’une certaine valeur. La sub stitution est beaucoup plus utilisée.
Machines à tambours Dans les années 20, de nombreux dispositifs mécaniques ont été inventés pour automa tiser le chiffrement. Ils utilisaient une (ou plusieurs) pièce mécanique appelée ta m b ou r (ou r o to r) qui était conçue de manière à effectuer une opération de substitution. Une m achines à ta m b o u rs (ou m achines à rotors) a un clavier et un ensemble de rotors, et réalise une version du chiffre de VlGENÈRE. Chaque rotor est une permutation arbitraire de l’alphabet, a 26 positions et effectue une substitution simple. Par exemple, un rotor pouvait être conçu pour substituer « F » à « A » , « U » à « B », « L » à « C », etc. Les picots de sortie d ’un rotor entraînent ceux du rotor suivant. Par exemple, dans une machine à quatre rotors, le premier rotor pouvait substituer « F » à « A », le deuxième « Y » à « F », le troisième « E » à « Y », et le quatrième « C » à « E »; « C » étant la sortie dans le texte chiffré. Puis certains rotors se décalent et la substitution est différente la fois suivante. C’est la combinaison de tous ces rotors et des engrenages les entraînant qui rendent cette machine sûre.Comme tous les rotors bougent, et à des vitesses différentes, la pé riode d’une machine à n rotors est 26” . Certaines machines peuvent avoir des nombres de positions différents sur chaque rotor, ce qui complique encore plus la tâche du cryp tanalyste. La machine à rotors la plus connue est la machine E n i g m a , utilisée par les Allemands pendant la Seconde Guerre mondiale. L’idée de base est due à Arthur S c h e r b iu s et Arvid Gerhard D a m m en Europe. Elle a été brevetée aux Etats-Unis par Arthur S c h e r b iu s [1388]. Les Allemands avaient considérablement étoffé le concept de base pour leur effort de guerre. Il y avait un tableau qui permutait légèrement le texte en clair, et un rotor supplémen taire qui obligeait chaque rotor à opérer deux fois sur chaque lettre. Aussi compliquée qu’elle fut, la machine ENIGMA a été « cassée » durant la Seconde Guerre mondiale. Une équipe de cryptographes polonais a cassé une version simplifiée de la machine E n ig m a , une équipe britannique, dont Alan T u r in g faisait partie, a cassé la vraie machine E n i g m a . Pour plus d ’informations concernant les machines à rotors et la fa çon dont elles peuvent être cassées voyez [795, 93, 451, 496, 449, 880, 1326, 1589, 691]. Deux comptes rendus fascinants relatant comment la machine E n i g m a a été cassée sont donnés dans [737, 797],
Lectures recommandées Ce n’est pas un livre sur la cryptographie classique, aussi ne vais-je pas m’étendre plus avant sur ce sujet. Deux excellents livres présentant la cryptologie d’avant l’ère
Chapitre 1
H
Principes de base
informatique sont [589, 1481]; la cryptanalyse des machines à chiffrer se trouve dans [451]. Dorothy D e n n in g présente nombre de ces chiffres dans [462], et [880] donne une analyse relativement mathématique de ces mêmes chiffres. Un autre texte plus ancien sur la cryptographie, qui traite des sujets analogues, est [106]. Un article qui donne un bon aperçu du sujet est [580]. Les livres historiques de David K a h n sont aussi excellents [795, 796, 797).
1.4
Ou exclusif simple
X O R est l’opération ou exclusif, notée « ' » en C ou © en Mathématiques. C’est une opration classique sur les bits:
00 0 = 0 001 = 1 1©0=1
101 = 0 Remarquez les propriétés suivantes: a© a= 0 a © b© b = a
L’algorithme du ou exclusif simple est vraiment embarrassant; ce n’est rien d ’autre qu’un chiffre de V iG e n Èr e . Il est inclus ici car il est très souvent utilisé dans des logiciels commerciaux, du moins dans le monde M S -D O S et le monde M a c i n t o s h [1506, 1392]. Si un logiciel de sécurité clame qu’il utilise un algorithme de chiffrement « propriétaire » — et qui est nettement plus rapide que le DES — il y a de fortes chances qu’il s’agisse d ’une variante de ceci : /* Usage: crypto key input_file output_file */ void mainfint argc, char *argv[]) FILE *fi, *fo; int *cp; int c; if (cp = argv[l] ) { if ((fi = fopen(argv[2] ,"rb")) != NULL) -[ if ((fo = fopen(argv[3],"wb")) != NULL) { while ((c = getc(fi)) != EOF) { if (!*cp) cp = argv[l]; c '= *(cp++); putc(c,fo); > fclose(fo); >
1.5
Masque jetable
15
fc lo s e (fi);
> > > C ’est un algorithme à clef secrète. Le texte en clair est combiné à la clef par une opération « ou exclusif » pour produire le texte chiffré. Comme l’application du ou exclusif deux fois avec la même valeur redonne la valeur initiale, le chiffrement et le déchiffrement utilisent exactement le même programme (© dénote l’opération logique ou exclusif) : M ® K = C C®K = M
Il n’y a pas de vraie sécurité ici. Ce type de chiffre est trivial à casser, même sans ordinateur [589, 1481]. Cela ne prendra que quelques minutes avec un ordinateur. Faisons l’hypothèse que le texte est en langue anglaise. De plus, supposons que la clef a une petite longueur arbitraire. Voici comment le casser : 1. Découvrir la longueur de la clef par un procédé appelé c o m p ta g e d e coïn cid en ces [579]. Comparer le texte chiffré à lui-même mais décalé d ’un certain nombre d’octets : compter le nombre d’octets identiques. Si les deux segments de texte mis face à face ont été codés avec la même clef, quelque chose comme plus de 6 % des octets seront égaux. S’ils ont été codés avec une clef différente alors moins de 0,4 % des octets seront égaux (avec comme hypothèse une clef quelconque et un texte en clair composé de caractères A SC II ; d’autres textes en clair donneront des pourcentages différents). Le plus petit déplacement qui indique une coïncidence élevée est la longueur de la clef recherchée. 2. Décaler le texte chiffré de cette longueur et appliquer le ou exclusif entre le texte chiffré et le texte ainsi décalé. Cette opération élimine la clef et vous laisse avec le résultat du ou exclusif du texte en clair avec lui-même décalé. Comme l’anglais a environ un bit d ’information utile par octet (voir § 11.1), il y a suffisamment de redondance pour choisir le déchiffrement correct. Malgré cela, la liste des marchands de logiciels qui prétendent que cet algorithme est « presque aussi sûr que l’algorithme DES » continue de s’allonger [1392]. C ’est cet algorithme (avec une clef de 160 bits) que la NSA a finalement permis à l’industrie américaine du téléphone cellulaire numérique d’utiliser pour assurer la confidentialité des communications. Un ou exclusif simple empêchera peut-être votre sœur de lire vos fichiers mais cela n’arrêtera pas un cryptographe plus de quelques minutes.
1.5
Masque jetable
Croyez-le ou non, il existe un cryptosystème parfait. Il s’appelle tech n iqu e du masque je t a b le (« one-time pad » ) 13 et a été inventé en 1917 par le major Joseph 13. Note du traducteur : le term e « masque jeta b le » com m e traduction du vocable anglo-saxon « one-tim e pad » a été em prunté à [240].
Chapitre 1
16
Principes de base
M a u b o r g n e et Gilbert V e r n a m d’A T & T [795]14. Dans sa forme classique, le masque jetable n’est rien d’autre qu’une très longue suite non répétitive et aléatoire de lettres, écrite sur des pages reliées ensemble pour former un bloc. L’émetteur utilise chaque lettre du masque à son tour pour chiffrer exactement un caractère du texte en clair. L ’algorithme de chiffrement est simple : on ajoute le rang de la lettre à chiffrer au rang de la lettre correspondante du masque, le résultat modulo 26 donne le rang de la lettre du texte chiffré. Le destinataire dispose d ’un bloc identique et utilise le masque de la même manière pour déchiffrer les lettres du message chiffré une à une. Chaque lettre du masque est utilisée une seule fois, pour un seul message. L ’émetteur chiffre le message et détruit les pages correspondantes du bloc. Le destinataire a un masque identique et utilise tour à tour chaque lettre du masque pour déchiffrer chaque lettre du message chiffré. If détruit ensuite les mêmes pages du bloc. A chaque nouveau message on utilise de nouvelles pages et donc une nouvelle clef. Par exemple, si le message est :
MASQUEJET ABLE et que le morceau de masque utilisé est : TBFRGFARFMIKL alors le texte chiffré est : GCYIBKKWZNKWQ puisque l’on a: M + T mod 26 = G A + B mod 26 = C S + F mod 26 = Y etc. En émettant l’hypothèse que l’adversaire n’a pas accès au bloc qui contient le masque jetable, ce système est parfaitement sûr. Un texte chiffré donné peut correspondre à n’importe quel texte en clair de même longueur. Comme tout masque est également probable (rappelez-vous que le masque est une suite aléatoire), un adversaire n’a pas d ’information pour baser sa cryptanalyse. Le morceau de masque aurait tout aussi bien pu être : RXDCXFHVQBYRX qui donnerait le texte en clair : OEUFDECAILLES ou encore : RTFDAPUVHMGNX qui donnerait le texte en clair : OISEAUPARADIS 14. En fait, un masque jetable est un cas particulier d ’un schém a à seuil (voir § 3.7).
1.5
Masque jetable
17
Ce point vaut la peine d’être répété : comme tout texte en clair est équiprobable, il n’y a aucun moyen pour le cryptanalyste de déterminer quel est le bon texte en clair. Le « ou exclusif » d ’une clef aléatoire avec un texte en clair non aléatoire produit un texte chiffré complètement aléatoire, peu importe la puissance de calcul. Le point faible, et il est de taille, est que les lettres du masque doivent être engendrées aléatoirement. Toute attaque contre la technique du masque jetable se fera contre la méthode utilisée pour engendrer le masque. On ne peut pas envisager l’utilisation d’un générateur pseudo-aléatoire ; ceux-ci possèdent toujours des propriétés non aléatoires. Si vous utilisez un générateur vraiment aléatoire — c ’est beaucoup moins facile qu’il n’y paraît (voir § 17.14) — cette technique est sûre. L’autre point important est que vous ne pouvez jamais utiliser à nouveau le même morceau du masque. Même avec un masque de plusieurs gigaoctets, un cryptanalyste qui possède des textes chiffrés avec des séquences de masque se recouvrant peut re construire le texte en clair. Il compare chaque paire de textes chiffrés en décalant l’un par rapport à l’autre et compte le nombre de lettres identiques en même position. Quand les textes sont alignés, la proportion de lettres identiques augmente d’un coup — le pourcentage exact dépend de la langue utilisée dans le texte en clair. Ensuite la cryptanalyse est facile. Il s’agit d ’un index de coïncidences mais avec deux « périodes » seulement à comparer [905]. L’idée du masque jetable peut être facilement étendue au chiffrement de données bi naires. On utilise un masque composé de bits au lieu de caractères. Au lieu d ’addition ner le texte en clair et le masque, on utilise le ou exclusif. Pour déchiffrer, on applique le ou exclusif avec le même masque jetable. On ne change rien d ’autre et on a un niveau de sécurité parfait. Tout cela à l’air mirobolant, mais il y a quand même quelques problèmes. La longueur du masque est égale à la longueur du message à transmettre. C ’est acceptable pour quelques messages courts mais pas pour une ligne de transmission à 1,544 mégabit par seconde. Malgré tout, vous pouvez enregistrer 650 mégaoctets de bits aléatoires sur un CD-ROM mais il y a des problèmes. Premièrement, vous avez besoin d ’exactement deux copies des bits aléatoires alors que les CD-ROMs sont économiquement intéres sants en grande quantité seulement. Deuxièment, vous devez pouvoir détruire les bits aléatoires déjà utilisés. Un CD-ROM ne peut-être effacé autrement qu’en le détrui sant physiquement. Les cassettes numériques sont bien mieux adaptées à ce genre de besoins. Même si vous résolvez les problèmes de la distribution du masque et de sa sauvegarde, vous devez encore vous assurer que l’expéditeur et le destinataire soient parfaitement synchronisés. Si le destinataire est décalé ne serait-ce que d ’un bit (ou si quelques bits sont perdus pendant la transmission), le message déchiffré n’aura aucun sens. Si quelques bits sont faussés durant la transmission (aucun bit n ’est ajouté ou retiré, ils sont seulement modifiés), seul ces bits-là seront mal déchiffrés. D’autre part, un masque jetable ne permet aucune authentification. Les masques jetables ont encore leur utilité aujourd’hui, principalement pour des ca naux de communications ultra-secrets et à faible débit. Le « téléphone rouge » entre les Etats-Unis et l’ex-Union soviétique était15, paraît-il, chiffré à l’aide de la technique du masque jetable. Nombre de messages d ’espions soviétiques étaient chiffrés par masque jetable. De tels messages sont encore secrets même aujourd’hui et le resteront à tout ja 15. L’est-il encore?
Chapitre 1
18
Principes de base
mais. Peu importe combien de temps les super-ordinateurs consacreront à essayer de les casser, peu importe le nombre de personnes qui essaieront encore d’ici à un demi-siècle avec des machines et des techniques inimaginables, ils resteront secrets. Même quand les extraterrestres venant d’Andromède atterriront avec leurs gigantesques engins spa tiaux et leur puissance de calcul inimaginable, ils ne seront pas capables de déchiffrer les messages des espions soviétiques chiffrés à l’aide de la technique du masque jetable (à moins qu’il puissent aussi voyager dans le temps et récupérer les masques utilisés).
1.6
Algorithmes informatiques
Il y a de nombreux algorithmes cryptographiques. Les trois plus courants sont : - DES (standard de chiffrement de données) « Data Encryption Standard » : l’al gorithme de chiffrement informatique le plus populaire. Le DES est un standard américain et même international, du Gouvernement américain et il a l’aval de l’armée américaine pour le chiffrement de données de nature sensible mais non secrète. C ’est un algorithme à clef secrète : la même clef sert au chiffrement et au déchiffrement. - R SA (d’après le nom de ses concepteurs : R i v e s t , S h a m ir et A d l e m a n ) : l’al gorithme à clef publique le plus populaire. Il peut aussi bien être utilisé pour le chiffrement que pour la signature numérique. - D SA (algorithme de signature numérique) « Digital Signature Algorithm » : un autre algorithme à clef publique. Il fait partie du standard de signature numé rique DSS ou « Digital Signature Standard ». Il ne peut pas être utilisé pour le chiffrement mais seulement pour la signature numérique. C ’est de ce genre de choses qu’il est question dans ce livre.
1.7
Grands nombres
Tout au long de cet ouvrage, j ’utilise des grands nombres pour décrire différents points en cryptographie. Il est aisé de perdre de vue l’ordre de grandeur de ces grands nombres. Le tableau 1.1 montre les équivalents des grands nombres manipulés en cryptographie par rapport à des grands nombres en physique. Ces nombres sont des estimations d’ordre de grandeur. Us ont été puisés dans différentes sources. La plupart des nombres venant de l’astrophysique sont expliqués dans l ’article de Freeman D y s o n : « Time Without End: Physics and Biology in an Open Universe » dans Reviews of Modem Physics, volume 52, numéro 3, juillet 1979, pages 447 à 460. Les nombres indiqués pour les accidents de la circulation ont été calculés à partir des statistiques collectées par le ministère des Transports américain : 163 morts par million de personnes en 1993 et une longévité moyenne de 69,7 années.
1.7
Grands nombres
19
Tab. 1.1 - Grands nombres
Equivalent physique Probabilité de mourir foudroyé (par jour) Probabilité de gagner le gros Lot à la loterie américaine Probabilité de gagner le gros lot à la loterie américaine et de mourir foudroyé le même jour Probabilité de se noyer (aux Etats-Unis et par an) Probabilité d ’être tué dans un accident d ’automobile (aux Etats-Unis en 1993) Probabilité d ’être tué dans un accident d ’automobile (aux Etats-Unis et sur une vie) Temps d ’ici à la prochaine glaciation Temps d’ici à ce que le soleil explose en nova Age de la terre Age de l’univers Nombre d ’atomes constituant la terre Nombre d ’atomes constituant le soleil Nombre d ’atomes constituant la galaxie Nombre d’atomes constituant l’univers (sans tenir com pte de la matière sombre)
Nombre 1 chance sur 9 milliards (2 ’ ’ ) 1 chance sur 4000000 (222)
1077 (226E)
Volume de l’univers
1084 (2280) cm3
1 chance sur 261 1 chance sur 59000 (216) 1 chance sur 6100 (213) 1 chance sur 88 (27) 14000 ans (214) 109 (230) années 109 (230) années 1010 (234) années 10E1 (2170) 1067 (2190) 1067 (2223)
Si l’univers est ferm é: Durée de vie de l’univers
1011 (237) années 1018 (261) secondes
Si l’univers est ouvert : Temps d ’ici à ce que les étoiles peu massives se refroidissent Temps d ’ici à ce que les planètes quittent leur étoile Temps d’ici à ce que les étoiles quittent leur galaxie Temps d’ici à ce que les orbites disparaissent par radiation gravitationnelle Temps d ’ici à ce que les trous noirs s’évaporent complètement par le processus de H aw king Temps d’ici à ce que toute la matière soit liquide à 0 K Temps d’ici à ce que toute la matière se transforme en fer Temps d ’ici à ce que toute la matière soit absorbée par des trous noirs
1014 (247) années 101E (2eo) années 1019 (264) années 102n (267) années 1064 (2213) années 1065 (2216) années 10 10
1 r i2 6
1
e
années j
années
Première partie Protocoles cryptographiques
Chapitre 2
Briques élémentaires 2.1
Introduction aux protocoles
Le but de la cryptographie est de résoudre des problèmes1. La cryptographie résoud des problèmes qui ont à voir avec la confidentialité, l’authentification, l’intégrité, et les gens méfiants ou malhonnêtes. Vous pouvez apprendre tout sur les algorithmes et les techniques, mais ceux-ci ne sont intéressants que s’ils sont mis à contribution pour résoudre des problèmes. C’est pourquoi nous allons d’abord regarder les protocoles de plus près. Un p r o to c o le est une série d ’étapes, impliquant deux ou plusieurs participants, conçu pour accomplir une tâche. Cette définition est importante. Il y est question d ’une « série d’étapes », c ’est-à-dire qu’un protocole est une suite ordonnée d ’étapes et qu’il a un début et une fin. Chaque étape doit être exécutée à son tour et aucune autre étape ne peut être exécutée avant que la précédente ne soit finie. L ’expression « deux ou plusieurs participants » indique qu’il faut au moins deux personnes pour accomplir un protocole ; une personne isolée ne peut accomplir un protocole. Il est vrai qu’une personne seule peut réaliser une série d ’étapes pour accomplir une tâche (par exemple, cuire un gâteau), mais ce n’est pas un protocole. En dernier lieu, l’expression « conçu pour accomplir une tâche » indique qu’un protocole doit faire quelque chose. Ce qui ressemble à un protocole mais qui n’accomplit pas une tâche n’est pas un protocole mais bien une perte de temps. Les protocoles ont d ’autres caractéristiques : chaque participant d’un protocole doit connaître le protocole et toutes les étapes à suivre d’avance ; - chaque participant impliqué dans un protocole doit être d’accord pour adhérer au protocole ; - le protocole doit être non ambigu : chaque étape doit être bien définie et il ne doit pas y avoir de possibilité de mésentente ; - un protocole doit être complet: il doit y avoir une action spécifique à chaque situation possible. 1. D e fait, c ’est le but d e l’ inform atique tou t cou rt — ce que beaucoup de gens tendent à oublier.
Chapitre 2
24
Briques élémentaires
Les protocoles dans ce livre sont organisés en une série d’étapes. L ’exécution d ’un protocole parcourt linéairement ces étapes, sauf s’il y a des instructions de branchement indiquant qu’il faut poursuivre à partir d’une autre étape. Chaque étape comprend des calculs effectués par l’un des participants, et/ou des messages envoyés d ’un participant à un autre. Un p r o t o c o le cry p to g ra p h iq u e est un protocole qui utilise la cryptographie. Les participants peuvent être des amis qui ont implicitement confiance les uns en les autres ou ils peuvent être des ennemis qui ne se font pas confiance du tout. Un protocole cryptographique utilise certains algorithmes cryptographiques, mais en général le but d’un protocole va au-delà de la simple confidentialité. Les participants d’un protocole peuvent vouloir partager partiellement un secret pour calculer une valeur, engendrer une suite aléatoire, convaincre l’autre interlocuteur de son identité, ou signer simul tanément un contrat. Tout l’intêret d’utiliser la cryptographie dans un protocole est d ’empêcher ou de détecter l’espionnage ou la tricherie. Si vous n ’avez jamais vu de tels protocols auparavant, cela va changer radicalement votre idée de ce que des participants mutuellement méfiants peuvent accomplir sur un réseau informatique. En général, on peut formuler cela ainsi: - Il doit être impossible de faire ou d ’apprendre plus que ce qui est prévu dans le protocole. C ’est beaucoup plus difficile qu’il n’y parraît. De nombreux protocoles sont exami nés dans les prochains chapitres. Dans certains, un des participant peut tromper les autres. Dans d ’autres, un espion peut altérer le protocol ou apprendre des informations secrètes. Certains protocoles échouent faute de précision dans la définition des régies. D ’autres échouent parce que leurs auteurs ont manqué de méticulosité dans leur ana lyse. Comme pour un algorithme, il est bien plus difficile de prouver qu’un protocle est sûr que le contraire.
But des protocoles Dans la vie de tous les jours, il y a des protocoles informels pour quasiment tout : com mander des marchandises par téléphone, jouer au poker, voter aux élections. Personne ne pense vraiment à ces protocoles ; ils ont évolué au cours du temps, tout le monde sait comment les utiliser et ils marchent. De nos jours, les interactions humaines se font de plus en plus à travers des réseaux informatiques et non face à face. Les ordinateurs ont besoin de protocoles pour faire ce que les gens font sans y penser. Si vous déménagez vers un autre pays et que vous y trouvez un bureau de vote complètement différent de ce que vous avez l’habitude d’utiliser, vous vous adapterez facilement. Les ordinateurs ne sont pas aussi flexibles. Nombre de protocoles « face à face » requièrent la présence des gens pour assurer l’impartialité et la sécurité. Enverriez-vous une liasse de billets à un étranger pour qu’il vous achète des marchandises? Joueriez-vous au poker avec quelqu’un si vous ne pouvez pas le voir mélanger les cartes et les distribuer? Enverriez-vous au Gouvernement votre vote par courrier sans quelque assurance que votre anonymat soit préservé? Il est naïf de croire que les utilisateurs d’un réseau informatique sont honnêtes. Il est naïf de croire que les gestionnaires du réseau sont honnêtes. Il est même naïf de croire que les concepteurs du réseau étaient honnêtes. La plupart le sont mais les quelques
2.1
Introduction aux protocoles
25
autres peuvent faire beaucoup de dégâts. En formalisant les protocoles, nous pouvons examiner comment des participants malhonnêtes peuvent essayer de tricher et ainsi développer des protocoles qui excluent les tricheurs. Non seulement les protocoles formalisent les comportements mais de plus il permettent d’abstraire le processus d’accomplissement d’une tâche des mécanismes par lesquels cette tâche est accomplie. Un protocole de communication entre deux ordinateurs est le même, que ce soient des P C d ’IBM , des V A X de D i g i t a l o u encore des téléco pieurs. Nous pouvons examiner les protocoles sans nous noyer dans les détails de leur réalisation concrète. Une fois que nous sommes convaincus de tenir un bon protocole, nous pouvons le réaliser avec n’importe quoi tel que des ordinateurs, des téléphones ou même des gaufriers intelligents.
Les acteurs Pour illustrer les protocoles, j ’ai engagé des acteurs (voir le tableau 2.1)2. Alice et Bernard sont les acteurs principaux. Ils accompliront tous les protocoles généraux à deux participants. Par convention, Alice commencera tous les protocoles. Bernard ré pondra. Si le protocole requiert l’intervention d ’un troisième ou quatrième participant, Christine et David seront appelés à la rescousse. Les autres acteurs joueront des rôles spécifiques qui seront détaillés plus tard.
T a b . 2.1
Alice Bernard Christine David Estelle Martin Ivan Gatien Patricia Victor
- Liste des acteurs et de leur rôle
participante de tous les protocoles participant de tous les protocoles participante des protocoles à trois ou quatre participants participant des protocoles à quatre participants espionne attaquant malveillant actif arbitre intègre gardien : il surveillera Alice et Bernard dans certains protocoles plaideuse vérificateur (contrôleur)
Protocoles arbitrés Un arbitre est un tiers, personne de confiance et désintéressée qui veille au bon dérou lement du protocole (voir la figure 2.1a). L ’arbitre est dit « désintéressé » parce qu’il n’a pas d’intérêt dans l’accomplissement du protocole et qu’il n’a aucune allégeance envers les autres participants. L ’arbitre est dit de « confiance » parce que tous les par ticipants au protocole acceptent que ce qu’il dit est vrai, que ce qu’il fait est correct 2. Note du traducteur : dans la littérature anglo-saxonne, les prénom s des acteurs : A lice, B ob , Carol, Dave, Eve, Mallet, Trent, W arden, P eggy et V ictor correspondent respectivem ent à Alice, Bernard, Christine, David, Estelle, M artin, Ivan, G atien, P atricia et V ictor dans cette édition française. Le choix de Bernard plutôt que B ob n ’est pas traditionnel mais cela ne change rien à la com préhension de l’ouvrage car ces prénom s peuvent être quelconques pour autant qu ’ ils com m encent par la bonne lettre.
Chapitre 2
26
Briques élémentaires
et que sa part du protocole sera complète. Les arbitres aident au bon accomplissement de protocoles entre participants méfiants.
F ig. 2.1 - Types de protocoles Dans le monde réel, les hommes de loi jouent souvent le rôle d’arbitre. Par exemple, Alice vend une voiture à Bernard, un inconnu. Bernard veut payer par chèque mais Alice n’a aucun moyen de savoir si le chèque est un chèque en bois. Alice veut s’assurer de la solvabilité du chèque avant de céder les papiers du véhicule (titre de propriété inclus) à Bernard. Bernard, qui n’a pas plus confiance en Alice qu’elle en lui, ne veut pas donner le chèque avant d ’avoir reçu les papiers. Un homme de loi qui a la confiance d ’Alice et de Bernardentre alors en scène. Grâce à l’aide de celui-ci, Alice et Bernard peuvent se mettre d ’accord sur le protocole suivant, qui garantit que ni l’un ni l’autre ne pourra tricher : 1° Alice donne les papiers et les clefs à l ’homme de loi. 2° Bernard donne le chèque à Alice. 3° Alice dépose le chèque à sa banque.
2.1
Introduction aux protocoles
21
4° après un certain laps de temps nécessaire à la vérification et à l ’encaissement du chèque, l’homme de loi donne les papiers et les clefs à Bernard. Si le chèque n’est pas encaissé après le laps de temps donné, Alice en informe l ’homme de loi et lui fournit la preuve de ce qu’elle avance; alors l’homme de loi rend les papiers et les clefs à Alice.
Dans ce protocole, Alice fait confiance à l’homme de loi pour qu’il ne donne les papiers et les clefs que si le chèque est solvable (et donc encaissé) et pour qu’il lui rende ceuxci dans le cas contraire. Bernard fait confiance à l’homme de loi pour qu’il garde les papiers et les clefs jusqu’à ce que le chèque soit encaissé. Pour l’homme de loi, peu importe si le chèque est solvable ou non. Il fera sa part du protocole dans tous les cas puisqu’il sera payé de toute façon. Dans cet exemple, l’homme de loi joue le rôle d’un agent de dépôt. Les hommes de loi agissent comme arbitres pour les testaments et parfois pour la négociation de contrats. Les Bourses agissent comme arbitres entre les acheteurs et les vendeurs. Les banques agissent aussi comme arbitres. Bernard peut acheter la voiture d ’Alice à l’aide d’un chèque certifié : 1° Bernard fait un chèque et le donne à sa banque. 2° Après avoir retiré du compte de Bernard le montant nécessaire pour couvrir le chèque et après l’avoir placé sur un compte bloqué, la banque certifie le chèque et le rend à Bernard.
3° Alice donne les papiers et les clefs à Bernard et Bernard donne le chèque certifié à Alice. 4° Alice dépose le chèque à sa banque.
Ce protocole est effectif parce qu’Alice a confiance en la certification réalisée par la banque. Alice pense que la banque garde bien son argent et qu’elle ne s’en sert pas pour des investissements douteux. Un notaire est aussi un arbitre. Quand Bernard reçoit un acte notarié d ’Alice, il est convaincu qu’Alice a bien signé ce document de sa propre main et volontairement. Le notaire peut, si nécessaire, attester du fait en justice. Le concept d’arbitre est aussi vieux que notre société. Il y a toujours eu des gens — souverains, prêtres, etc. qui avaient l’autorité et le devoir d ’agir honnêtement. Les arbitres ont un rôle et une position sociale particulière dans notre société. Tromper le public leur ferait perdre ce statut : des hommes de loi qui utiliseraient des dépôts fiduciaires à des fins malhonnêtes s’exposeraient à la radiation de leur ordre. Cette image de confiance ne correspond pas toujours à la réalité mais nous montre l’idéal. Cet idéal peut être adapté au monde de l’informatique mais il y a quand même quelques difficultés lorsque les ordinateurs arbitrent : - Il est plus aisé de trouver et d’avoir confiance en un tiers si on sait qui il est et si on peut le rencontrer. Deux participants se méfiant l’un de l’autre ont de fortes chances d’être méfiants vis-à-vis d’un arbitre sans visage quelque part dans un réseau. - Le réseau informatique doit assumer le coût de l’arbitrage. Nous connaissons les honoraires des notaires. Qui est prêt à en payer le coût dans un réseau informa tique?
Chapitre 2
28
Briques élémentaires
- Il y a un délai inhérent au protocole d’arbitrage. - L’arbitre doit s’occuper de chaque transaction; il est un goulot d ’étranglement potentiels dans toute réalisation à grande échelle de protocoles. Augmenter le nombre d ’arbitres peut aider à faire face à ce problème mais alors le coût de la réalisation augmente aussi. - Comme tout le monde sur le réseau doit faire confiance à l’arbitre, il devient le point sensible du réseau et la cible privilégiée de ceux qui veulent corrompre le réseau. Malgré tout, les arbitres ont encore un rôle à jouer. Dans les protocoles, le rôle de l’arbitre sera tenu par Ivan.
Protocoles avec juge-arbitre L’arbitrage coûte cher, aussi les protocoles arbitrés peuvent être divisés en deux sousp r o to c o le s : un sous-protocole non arbitré qui est exécuté chaque fois que le protocole est utilisé, et un autre sous-protocole arbitré auquel on ne fait appel que s’il y a un litige entre les participants. Dans ce cas particulier, on ne parlera pas d’arbitre mais de ju g e -a r b itr e (voir la figure 2.1b). Un juge-arbitre est aussi un tiers désintéressé et digne de confiance. Contrairement à un arbitre, il n ’est pas impliqué dans chaque protocole. Le juge-arbitre n’est appelé que pour déterminer si une transaction a été effectuée honnêtement. Les juges sont des juges-arbitres professionnels. Contrairement au notaire, les juges n’interviennent que lorsqu’il y a contestation. Alice et Bernard peuvent conclure un contrat sans l’intervention d’un juge. Un juge ne verra jamais ce contrat sauf si l’une des parties porte l’affaire devant les tribunaux. Le protocole de signature de contrat peut être formalisé de la façon suivante : Sous-protocole non arbitré (exécuté à chaque fois) 1° Alice et Bernard négocient les termes du contrat. 2° Alice signe le contrat. 3° Bernard signe le contrat. Sous-protocole avec juge-arbitre (exécuté uniquement en cas de contestation) : 1° Alice et Bernard comparaissent devant un juge. 2° Alice présente sa défense. 3° Bernard présente sa défense. 4° Le juge tranche. La différence entre un arbitre et un juge-arbitre (du moins pour les besoins de cet ouvrage) est que le juge-arbitre n’est pas toujours nécessaire. S’il y a contestation, un juge est appelé pour trancher. S’il n’y a pas contestation, un juge n’est pas nécessaire. Il existe des protocoles informatiques avec juges-arbitres. Ces protocoles reposent sur l’hypothèse que les participants sont honnêtes mais si quelqu’un triche, les données collectées pendant l’exécution du protocole permettront à un tiers désintéressé de dé terminer s’il y a eu tricherie. Dans un bon protocole avec juge-arbitre, ce dernier peut
2.1
Introduction aux protocoles
29
également indiquer l’identité de celui qui a triché. Au lieu d’empêcher la tricherie, les protocoles avec juge-arbitre détectent la tricherie. Le caractère inévitable de la détec tion agit comme une mesure préventive et décourage la fraude.
Protocoles à discipline intrinsèque Un p r o to c o le à disciplin e in trin sèqu e est le meilleur type de protocole. Le protocole lui-même garantit l’intégrité de la transaction (voir la figure 2.1c). Il ne faut pas d’ar bitre pour utiliser le protocole. Il ne faut pas de juges-arbitres pour régler les conflits. Le protocole est construit de telle façon que les contestations soient impossibles. Si l’ un des participants essaie de tricher, l’autre participant le détecte immédiatement et le protocole est interrompu. Quels que soient les espoirs du tricheur, ils seront déçus. Dans le meilleur des mondes, tout protocole devrait être à discipline intrinsèque. Malheureusement, il n’existe pas un tel protocole pour chaque type de transaction possible.
Attaques de protocoles Les attaques dirigées contre les protocoles peuvent viser soit les algorithmes cryptogra phiques utilisés par les protocoles, soit les techniques cryptographiques utilisées pour réaliser les algorithmes, ou encore le protocole lui-même. Comme ce paragraphe ne traite que les protocoles, nous allons supposer que les algorithmes et les techniques sont sûres et ne regarder que les attaques contre le protocole lui-même. II y a plusieurs façons d ’attaquer un protocole. Quelqu’un qui n ’est pas impliqué dans le protocole peut espionner tout ou partie de celui-ci. C ’est ce que l’on appelle une attaque passive parce que l’attaquant ne modifie pas le protocole. Tout ce qu’il peut faire c’est observer le protocole et ainsi essayer de collecter de l’information. Ce type d’attaque correspond à une attaque à texte chiffré seulement, telle celle que décrite dans le paragraphe 1.1. Les attaques passives sont difficiles à détecter, aussi les protocoles essayent de s’en prémunir plutôt que de les détecter. Dans de telles attaques le rôle de l’espion sera joué par Estelle. Un attaquant peut aussi essayer d ’altérer le protocole pour le tourner à son avantage. Il peut prétendre être quelqu’un d’autre, intercaler de nouveaux messages, supprimer des messages, remplacer un message par un autre, envoyer un vieux message, détruire le canal de communication ou encore modifier l’information enregistrée par un ordinateur. On parlera alors d’a ttaq u es actives car elles requièrent une attitude active de la part de l’attaquant. La manière dont sont menées ces attaques dépendent du réseau. Les attaquants passifs ne sont intéressés que par l’information qu’ils peuvent glaner concernant les participants au protocole. Ils collectionnent les messages qui circulent entre les différents participants et en essayant de les cryptanalyser. Les attaques ac tives peuvent au contraire avoir bien d’autres objectifs. L’attaquant peut vouloir soit obtenir de l’information, soit dégrader les performances du système, soit corrompre de l’information existante, soit encore avoir accès à des ressources non autorisées. Les attaques actives sont bien plus sérieuses, plus particulièrement dans les protocoles où les participants n’ont pas confiance entre eux. L’attaquant n’est pas forcément un étranger. Il peut être un utilisateur légitime du système. Il peut être l’administrateur du système. Il peut même y avoir plusieurs attaquants actifs, travaillant ensemble,
Chapitre 2
30
Briques élémentaires
chacun étant un utilisateur légitime. Le rôle de l’attaquant malicieux actif sera joué par Martin. Il se peut que l’attaquant soit un des participants au protocole. Ilpeut mentir pendant le protocole ou même ne pas du tout suivre les règles. Ce type d’attaquantest appelé tricheur. Les trich eu rs passifs respectent le protocole mais ils essaient d’obtenir plus d ’informations que le protocole ne leur permet normalement. Les tricheu rs actifs altèrent le protocole en cours en essayant de tricher. Il est très difficile de garantir la sécurité du système si la plupart des participants sont des tricheurs actifs mais, parfois, il est possible pour les participants légitimes de détecter qu’il y a tricherie active. De toute façon, les protocoles doivent se prémunir de manière fiable contre la tricherie passive.
2.2
Communications à l’aide d’un cryptosystème à clef secrète
Comment deux parties peuvent-elles communiquer de manière sûre? Ils chiffrent leur communication bien sûr. Le protocole complet est plus compliqué que cela. Voyons comment Alice peut envoyer un message chiffré à Bernard : 1° Alice et Bernard choisissent un cryptosystème. 2° Alice et Bernard choisissent une clef. 3° Alice chiffre son texte en clair à l ’aide de l ’algorithme choisi et avec la clef sélectionnée. Cette étape produit un texte chiffré.
4° Alice envoie le texte chiffré à Bernard. 5° Bernard déchiffre le texte chiffré avec le même algorithme et la même clef, et finalement lit le message.
Que peut apprendre Estelle un espion qui se place entre Alice et Bernard, en écoutant le protocole? Si tout ce qu’elle peut entendre est la transmission de l’étape 4, elle peut essayer de cryptanalyser le texte chiffré. Cette attaque passive est une attaque à texte chiffré seulement. Il existe des algorithmes qui sont résistants (pour autant que l’on sache) peu importe la puissance de calcul dont Estelle dispose pour s’y attaquer. Toutefois, Estelle n’est pas stupide. Elle sait que si elle peut écouter les étapes 1 et 2 du protocole, elle aura ce qu’il lui faut. Elle connaîtra alors l’algorithme et la clef; elle en saura autant que Bernard. Quand le message est transmis à l’étape 4, tout ce qu’elle a à faire est de le déchiffrer pour elle-même. Un bon cryptosystème est un système où la sécurité est inhérente à la connaissance de la clef et non pas à celle de l’algorithme. C ’est pourquoi la gestion des clefs est un problème si important en cryptographie. Avec un algorithme à clef secrète, Alice et Bernard peuvent réaliser l’étape 1 en public mais ils doivent réaliser l’étape 2 en secret. La clef doit rester secrète avant, pendant et après le protocole, sinon, le message ne serait plus confidentiel3. 3. La cryptographie à clef publique résout ce problèm e d ’ une autre manière qui sera décrite dans le paragraphe 2.5.
2.3
Fonctions à sens unique
31
Martin, un attaquant actif, peut faire d ’autres choses. Il peut essayer de casser le canal de communication de l’étape 4, s’assurant ainsi qu’Alice ne peut pas transmettre du tout son message à Bernard. Martin peut aussi intercepter les messages d’Alice et les remplacer par d’autres de son cru. Si de plus Martin connaît la clef (en interceptant la communication de l’étape 2 par exemple), il peut chiffrer ses propres messages et les envoyer à Bernard en lieu et place des messages interceptés. Bernard n’aurait aucun moyen de détecter que ces messages ne viennent pas d ’Alice. Si Martin ne connaissait pas la clef, les messages qu’il enverrait en remplacement seraient du charabia lorsqu’ils seraient déchiffrés par Bernard. Bernard, pensant que le message vient d’Alice, croirait que le réseau, ou Alice, ont de sérieux problèmes. Quant à Alice, que peut-elle faire pour fausser le protocole? Elle peut donner une copie de la clef à Estelle. A l’aide de celle-ci, Estelle peut lire tout ce que Bernard dit. Elle peut reproduire ses propos dans le New York Times. Bien que cela soit grave, la faute n’est pas imputable au protocole. Il n’y a rien dans le protocole qui puisse empêcher Alice de donner une copie du texte en clair à Estelle. Bien sûr, Bernard peut faire tout ce qu’Alice peut faire. Ce protocole présume qu’Alice et Bernard se font confiance mutuellement. En résumé, un cryptosystème à clef secrète a les problèmes suivants : - Les clefs doivent être distribuées secrètement. Elles ont autant de valeur que tous les messages chiffrés avec elles car connaître les clefs donne accès à tous les messages. Pour des cryptosystèmes utilisés à l’échelle de la planète, la distribution des clefs peut être une tâche décourageante. Souvent, des messagers apportent les clefs à leur destination (de la main à la main). - Si la clef est compromise (volée, devinée, extorquée, achetée, etc.) alors Estelle peut déchiffrer tous les messages chiffrés à l’aide de cette clef. Elle peut alors se faire passer pour l’un des participants et insuffler ses propres messages pour tromper l’autre participant. - Si une clef différente est utilisée pour chaque paire d’utilisateurs d’un réseau, le nombre total de clefs croît très vite par rapport au nombre d ’utilisateurs. Par exemple, 10 utilisateurs ont besoin de 45 clefs différentes pour pouvoir mener n’importe quelle conversation deux à deux ; 100 utilisateurs ont besoin de 4950 clefs différentes. Ce problème peut être minimisé en gardant un petit nombre d’utilisateurs mais cela n’est pas toujours possible.
2.3
Fonctions à sens unique
La notion de fo n ctio n s à sens u n iqu e est fondamentale pour la cryptographie à clef publique. Bien qu’elles ne constituent pas un protocole en elles-mêmes, les fonctions à sens unique sont des éléments de base de la plupart des protocoles décrits dans ce livre. Une fonction à sens unique est une fonction relativement aisée à calculer mais considé rablement plus difficile à inverser. En d’autres termes, étant donné un x, il est facile de calculer f(x), mais étant donné f(x) il est difficile de calculer x. Dans ce contexte, « dif ficile » veut dire qu’il faudrait des millions d ’années pour calculer la fonction inverse même si tous les ordinateurs du monde s’attelaient à la tâche.
32
Chapitre 2
Briques élémentaires
Casser une assiète est un bon exemple de fonction à sens unique. Il est facile de cas ser l’assiète en mille morceaux. Toutefois, il est très difficile de recoller les morceaux ensembles pour reconstruire l’assiète. Cela a l’air correct mais on ne peut pas en démontrer la véracité. D ’un point de vue strictement mathématique, il n’y a pas de preuve que des fonctions à sens unique existent ni même d ’indice qu’elles peuvent être définies [233, 532, 603, 662]. Cependant, de nombreuses fonctions ont l’air d’être à sens unique: nous pouvons facilement les calculer et, à ce jour, nous ne connaissons pas de moyen simple pour les inverser. Par exemple, x2 dans un corps fini est facile à calculer mais le calcul de \fx est nettement plus difficile. Par la suite, je prétendrai que des fonctions à sens unique existent. Nous en reparlerons dans le paragraphe 11.2. Mais à quoi peuvent bien servir des fonctions à sens unique? On ne peut pas les utiliser telles quelles pour le chiffrement. Un message chiffré à l’aide d’une fonction à sens unique n’est pas d ’une grande utilité: personne ne peut le déchiffrer4. Pour la cryptographie à clef publique, nous avons besoin de ce que l’on appelle une fon ctio n à sens u n iqu e à b rè ch e s e c r è te 5. Une fo n ctio n à sens unique à brèch e secrète est un type spécial de fonction à sens unique. Il est facile de la calculer dans un sens et difficile de le faire dans l’autre sens. Mais pour celui qui connaît le secret, il est aisé de calculer la fonction dans l’autre sens. En d ’autres termes, il est facile de calculer f (x) étant donné x et difficile de calculer x étant donné f{x). Toutefois, il existe une information secrète, y, telle qu’étant donné f(x) et y, il est facile de calculer x. Une montre est un bon exemple de fonction à sens unique à brèche secrète. Il est facile de démonter une montre en ses centaines de pièces. Il est très difficile de remettre les pièces ensemble pour reconstruire une montre qui fonctionne. Toutefois, grâce à l’information secrète que constitue le plan de montage de la montre, il est bien plus facile de reconstruire la montre.
2.4
Fonctions de hachage à sens unique
Une fo n c tio n d e h achage à sens u n ique porte de nombreux noms: fonction de compression, fonction de contraction, digest, empreinte digitale, code correcteur cryptographique, code de vérification d ’intégrité, code de détection de manipulation6. Peu importe comment on les appelle, de telles fonctions sont fondamentales pour la cryptographie moderne. Ces fonctions interviennent comme éléments de base dans de nombreux protocoles. Des fonctions de hachage ont été utilisées en informatique depuis longtemps. Une fonc tion de hachage est une fonction, mathématique ou autre, qui convertit une chaîne de caractères de longueur quelconque en une chaîne de caractères de taille fixe (souvent de taille inférieure, cette chaîne est appelée em p rein te). Un exemple de fonction de hachage simple est une fonction qui à partir d’une chaîne de caractères calculerait un 4. E xercice : écrivez un message sur une assiette, cassez l’ assiette en mille m orceaux, et donnez ensuite les morceaux à un ami. Demandez-lui de lire le message. Constatez à quel point votre ami est impressionné par cette fonction à sens unique. 5. Il existe des applications cryptographiques des fonctions à sens unique tou t court (voir § 3.2). 6. N ote du traducteur : les fonctions de hachages sont parfois appelées « fonctions à adressage dispersé ».
2.5
Communications à l’aide d’un cryptosystème à clef publique
33
octet qui serait le résultat du ou exclusif de tous les caractères de la chaîne donnée. Le but de l’opération est de déterminer une empreinte digitale de la chaîne de caractères d’entrée. Cette empreinte permettrait de déterminer si une autre chaîne a des chances d’être identique à celle pour laquelle l’empreinte a été calculée. Comme les fonctions de hachage ont la caractéristique de faire correspondre plusieurs valeurs d ’entrée dif férentes à une même valeur de sortie, on ne peut pas s’en servir pour déterminer avec certitude si deux chaînes sont égales mais on peut l’utiliser pour avoir une garantie raisonnable d ’égalité. Une fonction de hachage à sens unique est une fonction de hachage qui est aussi une fonction à sens unique ; il est aisé de calculer l’empreinte à partir de la chaîne d ’entrée mais il est difficile d’engendrer des chaînes qui ont une certaine empreinte. La fonction de hachage du paragraphe précédent n’est pas à sens unique : étant donné un octet, il est trivial d’engendrer une chaîne dont le « ou exclusif » de ses caractères donne cet octet-là. Vous ne pourriez pas faire cela pour des fonctions de hachage à sens unique. Avec une bonne fonction de hachage à sens unique, il est aussi difficile de produire deux chaînes ayant la même empreinte. La fonction de hachage est publique; il n’y a pas de secret dans l’opération. Une fonction de hachage est sûre parce qu’elle est à sens unique. La sortie ne dépend pas de l’entrée de manière observable. Tout changement d ’un bit quelconque à l’entrée entraîne le changement, en moyenne, de la moitié des bits du résultat. Etant donné une empreinte il est irréalisable par calcul de trouver une chaîne ayant cette empreinte. Pensez à cela comme un moyen d ’associer une empreinte à des fichiers. Si vous vou lez vérifier que quelqu’un possède un fichier donné (que vous avez aussi) sans qu’il vous l’envoie, vous lui demandez alors l’empreinte du fichier. S’il vous envoie la bonne empreinte, alors il est très probable que la personne a le fichier en question. C ’est particulièrement adapté aux transactions financières où l’on ne veut pas qu’un retrait de cent francs devienne un retrait de mille francs. Normalement, vous utiliseriez une fonction de hachage à sens unique sans clef de telle manière que n’importe qui puisse calculer l’empreinte. Si vous voulez que seul votre correspondant soit capable de la calculer, alors lisez le paragraphe suivant.
Code d’Authentifîcation de Messages Un C o d e d ’ A u tïie n tifica tio n d e M essages (C A M ) est une fonctions de hachage à sens unique qui fonctionne de plus avec une clef secrète (voir § 18.14). L’empreinte dé pend à la fois de l’entrée et de la clef. Tout se passe en théorie comme avec une fonction de hachage sauf qu’il faut avoir la clef pour calculer l’empreinte. On peut construire un CAM à partir d’une fonction de hachage ou d ’un algorithme de chiffrement par bloc. Il existe aussi des fonctions spécialement conçues pour faire un C A M .
2.5
Communications à l’aide d’un cryptosystème à clef publique
On peut comparer un algorithme à clef secrète à un coffre-fort. La clef est la com binaison du coffre. Celui qui connaît la combinaison peut ouvrir le coffre, mettre un document à l’intérieur et le refermer. Quelqu’un d’autre, qui possède aussi la combi
Chapitre 2
34
Briques élémentaires
naison, peut ouvrir le coffre et prendre le document. Toute personne qui ne connaît pas la clef n’a pas d’autre ressort que d ’apprendre l’art de percer les coffres-forts. En 1976, Whitfîeld D i f f i e et Martin H e l l m a n ont changé ce paradigme de la cryp tographie à tout jamais [494]7. Ils ont décrit la cry p to g ra p h ie à c le f publique. Au lieu d ’une clef, il y a deux clefs différentes : une publique et une privée. De plus, il est difficile de calculer la clef privée à partir de la clef publique. Toute personne peut à l’aide de la clef publique chiffrer un message mais elle ne peut pas le déchiffrer. Seule la personne en possession de la clef privée peut déchiffrer le message. C ’est comme si quel qu’un avait changé le coffre-fort de la cryptographie en une boîte aux lettres. Mettre une lettre dans la boîte revient à chiffrer avec la clef publique, tout le monde peut le faire. Il suffit de la glisser dans la fente. Sortir le courrier de la boîte revient à déchiffrer avec la clef privée. C ’est difficile en général, il faut un chalumeau. Cependant, celui qui détient le secret (la clef physique de la boîte aux lettres) peut facilement retirer le courrier de la boîte. Mathématiquement, le procédé est basé sur une fonction à sens unique à brèche secrète décrite ci-dessus. Le chiffrement est la direction facile La clef publique constitue les instructions pour le chiffrement : tout le monde peut chiffrer un message. Le déchif frement est la direction difficile. C ’est suffisamment difficile pour que des gens avec des ordinateurs C r a y et des milliers (ou même des millions) d’années à leur disposi tion ne puissent pas déchiffrer les messages sans connaître le secret. Le secret, ou la brèche secrète, est la clef privée. Avec ce secret, le déchiffrement est aussi facile que le chiffrement. Voici comment Alice peut envoyer un message à Bernard en utilisant la cryptographie à clef publique : 1° Alice et Bernard choisissent un cryptosystème à clef publique. 2° Bernard envoie à Alice sa clef publique. 3° Alice chiffre son message en utilisant la clef publique de Bernard et lui envoie le résultat.
4° Bernard déchiffre le message d’Alice en utilisant sa clef privée. Remarquez comment la cryptographie à clef publique résout le problème la distribution des clefs de la cryptographie à clef secrète. Avant, Alice et Bernard devaient se mettre d’accord sur une clef en secret. Alice pouvait en choisir une au hasard mais elle devait toutefois la faire parvenir à Bernard. Elle pouvait la lui avoir donnée par le passé mais cela imposait de se rencontrer auparavant. Elle pouvait la lui envoyer par courrier recommandé mais cela prend du temps. La cryptographie à clef publique rend la chose facile. Sans aucun arrangement au préalable, Alice peut envoyer un message confideiitiel à Bernard. Estelle, qui écoute tout l’échange, dispose de la clef publique de Bernard et du message chiffré avec cette clef, mais elle ne peut ni retrouver la clef privée de Bernard ni le contenu du texte en clair du message. Plus généralement, un groupe d ’utilisateurs en réseau s’accordent pour utiliser un cryp tosystème à clef publique. Chaque utilisateur a sa ou ses clefs publiques et privées. Toutes les clefs publiques sont disponibles dans une base de données quelque part. 7. La N SA prétend avoir eu connaissance du con cept dès 1966, mais ne l’a jam ais prouvé.
2.5
Communications à l’aide d’un cryptosystème à clef publique
35
Ainsi le protocole est plus simple : 1° Alice obtient la clef publique de Bernard par la base de données. 2° Alice chiffre son message en utilisant la clef publique de Bernard et lui envoie le résultat.
3° Bernard déchiffre le message d’Alice en utilisant sa clef privée. Dans le premier protocole, Bernard devait envoyer sa clef publique à Alice avant qu’elle ne puisse lui envoyer un message. Le second protocole est plus proche du courrier traditionnel. Bernard n’est pas concerné par le protocole tant qu’il ne lit pas son courrier.
Cryptosystèmes hybrides Les premiers algorithmes à clef publique furent publiés à l’époque où il était question de prendre le DES comme standard. Il en résulta une sorte de politique partisane dans le milieu de la cryptographie. D i f f i e la décrivit dans ces termes [492] : « L’excitation provoquée par les cryptosystèmes à clef publique dans la presse populaire et la presse scientifique n’a pas été partagée par l’admi nistration cryptographique. L’année de la découverte de la cryptographie à clef publique, la « National Security Agency » (N SA) proposait d'adop ter un système cryptographique conventionnel, conçu par « International Business Machines » (IB M ), comme standard fédéral de chiffrement de données (DES, « Data Encryption Standard »). Marty Hellman et moi critiquions la proposition sur le fait que sa clef était trop courte, mais les fabricants étaient prêts à soutenir le standard proposé et nos critiques étaient vues par beaucoup comme une tentative d ’enrayer le processus de création du standard au profit de nos propres travaux. La cryptographie à clef publique fut attaquée à son tour dans la litérature commerciale [1131] et par des articles se voulant techniques [850, 1159], comme si elle était plus un produit en concurrence qu’une récente découverte. Ceci n’empêcha pas néanmoins la NSA réclamer sa part de mérite. Son directeur précisa dans l’Encyclopédie Britannica [1466] qu’« il avaient découvert la cryptographie à deux clefs dix ans plus tôt », bien qu’aucune preuve de cette affirmation n’ait jamais vu le jour. » En pratique, les algorithmes à clef publique ne se substituent pas aux algorithmes à clef secrète. On les utilise pour chiffrer des clefs et non des messages. Il y a deux raisons à cela: - Les algorithmes à clef publique sont lents. Les algorithmes à clef secrète sont généralement au moins 1000 fois plus rapides que les algorithmes à clef publique. Il est vrai que les ordinateurs sont de plus en plus rapides et qu’ils pourront dans quinze ans utiliser la cryptographie à clef publique aussi rapidement que la cryptographie à clef secrète aujourd’hui. Mais les besoins en bande passante aug mentent aussi et on aura toujours besoin de chiffrer des données plus rapidement que cela n’est possible avec la cryptographie à clef publique.
Chapitre 2
36
Briques élémentaires
- Les cryptosystèmes à clef publique sont vulnérables aux attaques à texte en clair choisi. Si C = E(Ai) où A i est un texte en clair parmi n textes en clair possibles, alors il suffit à un cryptanalyste de chiffrer les n messages et de comparer les textes chiffrés résultant avec C (la clef de chiffrement est publique). Il ne pourra
pas trouver la clef de déchiffrement de cette manière, mais il pourra déterminer M.
Une attaque à texte en clair choisi peut être particulièrement efficace s’il y a relative ment peu de messages chiffrés possibles. Par exemple, si A i est un montant en francs inférieur à un million, cette attaque marchera; le cryptanalyste essaye les un million de montants possibles. (Le chiffrement probabiliste résoud ce problème; voir § 23.15.) Même si A i n’est pas aussi clairement défini, cette attaque peut être très efficace. Savoir simplement qu’un texte chiffré ne correspond pas à un texte en clair particulier peut s’avérer une information utile. Un cryptosystème à clef secrète ne présente pas ce défaut car un cryptanalyste ne peut pas faire des chiffrements d’essai avec une clef inconnue. Dans la plupart des applications pratiques, la cryptographie à clef publique est utilisée pour protéger et distribuer les clefs de session, et ces clefs d e session sont utilisées dans des algorithmes à clef secrète pour protéger les messages transmis [879]. Cela est parfois appelé im c r y p to sy stè m e hybride. 1° Bernard envoie sa clef publique à Alice. 2° Alice engendre une clef de session aléatoire, k, la chiffre avec la clef publique de Bernard et envoie le résultat à Bernard. E B{k)
3° Bernard utilise sa clef privée pour déchiffrer le message d’Alice et ainsi retrou ver la clef de session. D B(EB(k)) = k
4° Alice et Bernard utilisent alors la même clef de session pour chiffrer leur conversation.
En ce qui concerne la distribution des clefs, la cryptographie à clef publique résout un important problème de manipulation de clefs. Avec la cryptographie à clef secrète, la clef de chiffrement repose quelque part avant de servir. Si Estelle met la main dessus, elle peut déchiffrer les messages qui seront chiffrés avec cette clef. Avec le protocole ci-dessus, la clef de chiffrement est créée au moment de son utilisation pour chiffrer les communications et elle est détruite dès qu’on en a plus besoin. Cela réduit consi dérablement le risque de compromettre la clef de session. Bien sûr, c ’est la clef privée qui risque d’être compromise, mais à moindre risque puisqu’elle n’est utilisée qu’une fois par communication pour chiffrer une clef de session. Il en sera question au para graphe 3.1.
Les énigmes de Merkle Ralph Merkle a inventé le premier un système de cryptographie à clef publique. En 1974, il s’est inscrit à un cours de sécurité en informatique donné par Lance Hoffman
2.6
Signatures numériques
37
à l’Université de Berkeley en Californie. Son devoir de fin dânnée, soumis bien avant la fin de l’année avait pour sujet le problème des « Communications privées par des canaux peu sûrs » [1073]. Hoffman ne put comprendre l’idée de Merkle et ce dernier abandonna peut-être le cours. Il continua de travailler sur le problème, malgrès un échec continuel à faire comprendre ces résultats. La technique de Merkle était basée sur des « énigmes » plus faciles à résoudre pour l’expéditeur et le destinataire que pour un espion. Voici comment Alice envoie un message chiffré à Bernard sans avoir besoin d’échanger une clef avec lui. 1° Bernard engendre 220 (ou environ un million) de messages de la form e: « Ceci est l’énigme numéro x. Voici la clef secrète y », où x est un nombre alâtoire et y une clef secrète aléatoire, x et y sont tous les deux différents pour chaque message. Il chiffre chaque message avec une clef de 20 bits différente et les envoie à Alice.
2° Alice choisi un message au hasard et opère une attaque exhaustive pour retrou ver le texte en clair. Cela demande un travail important mais pas impossible.
3° Alice chiffre son message secret avec la clef qu’elle a récupérée et l’envoie à Bernard avec x. 4° Bernard connaît la clef secrète y qu’il avait mise dans le message x, aussi peut-il déchiffrer le message.
Estelle peut casser ce système, mais elle doit faire beaucoup plus de travail que Alice ou Bernard. Pour retrouver le message de l’étape 3, elle doit effectuer une attaque exhaustive sur chacun des 220 messages de l’étape 1; cette attaque a une complexité de 240. La valeur de x n’aidera pas Estelle car elle a été donnée au hasard à l’étape 1. En général, Estelle doit effectuer un effort environ égal au carré de celui produit par Alice. Cet avantage de n par rapport à n2 est petit pour les standards cryptographiques mais cela peut suffir dans certaines circonstances. Si Alice et Bernard pauvent tester dix mille clefs par seconde, il leur faudra chacun une minute pour mener à bien leur étape et une autre minute pour envoyer les énigmes de Bernard à Alice par une liaison à 1,544 mégaoctets. Si Estelle dispose de moyens de calcul comparables, il lui faut environ un an pour casser le système. Il existe d ’autres algorithmes encore plus difficiles à casser.
2.6
Signatures numériques
Les signatures manuscrites sur des documents ont été longtemps utilisées pour prou ver l’identité de leur auteur ou du moins l’accord du signataire avec le contenu du document. Qu’est-ce qui rend une signature si importante [1396] ? 1. Une signature est authentique. La signature convainc le destinataire que le signa taire a délibérément signé le document. 2. Une signature ne peut pas être falsifiée (imitée). La signature est la preuve que le signataire a délibérément signé le document.
Chapitre 2
38
Briques élémentaires
3. Une signature n’est pas réutilisable. La signature fait partie du document et une personne malintentionnée ne peut pas déplacer la signature sur un autre document. 4. Un document signé est inaltérable. Une fois le document signé, il ne peut plus être modifié. 5. Une signature ne peut pas être reniée. La signature et le document sont des objets physiques. Le signataire ne peut pas prétendre plus tard ne pas avoir signé le document. Dans la réalité, aucune de ces affirmations n’est, tout à fait vraie. Les signatures peuvent être falsifiées; des signatures peuvent être transférées d ’un document à l’autre. Les documents peuvent être altérés après avoir été signés. Toutefois, nous acceptons de vivre avec ces problèmes : c ’est difficile de tricher et on risque d’être démasquer. On aimerait bien faire la même chose avec des ordinateurs mais il y a des problèmes. Premièrement, les fichiers informatiques sont facilement copiables. Même si la signature de quelqu’un est difficile à falsifier (une image graphique de la signature manuscrite, par exemple), il est facile de la transférer d ’un document à un autre par « couper, coller ». La simple présence d ’une telle signature ne garantit rier. Deuxièmement, il est facile de modifier un document après qu’il a été signé sans laisser de traces de la modification.
Signature de documents à l’aide d’un cryptosystème à clef se crète et d’un arbitre Alice veut signer un message numérique et l’envoyer à Bernard. Avec l’aide d ’Ivan et d ’un cryptosystème à clef secrète, elle peut le faire. Tvan est un arbitre puissant et respecté. Il peut communiquer avec Alice et Bernard (ou toute autre personne désirant signer un message numérique). Il partage une clef secrète, K a avec Alice et une clef secrète différente K b avec Bernard. Ces clefs ont été établies longtemps avant que le protocole ne soit exécuté et elles peuvent être utilisées plusieurs fois pour plusieurs signatures. 1° Alice chiffre son message pour Bernard avec la clef K a et envoie le résultat à Ivan.
2° Ivan déchiffre le message avec K a 3° Ivan assemble le message déchiffré et un avis comme quoi il a reçu ce message d ’Alice. Ivan chiffre le résultat avec K b -
4° Bernard déchiffre le tout avec K b - Il peut maintenant lire le message et la certification d’Ivan comme quoi Alice a bien envoyé ce message.
Comment Ivan sait-il que le message vient bien d ’Alice et non pas d’un imposteur? Il déduit cela du message chiffré. Comme seuls lui et Alice partagent la clef secrète, seule Alice peut chiffrer un message avec cette clef. Est-ce aussi valable qu’une signature sur papier? Voyons caractéristique par caracté ristique : 1. La signature est authentique. Ivan est un arbitre en qui on a confiance et Ivan sait que le message venait d’Alice. Le certificat d ’Ivan sert de preuve à Bernard.
2.6
Signatures numériques
39
2. La signature est infalsifiable. Seule Alice (et Ivan mais tout le monde lui fait confiance) connaît K A, donc seule Alice peut envoyer un message chiffré avec K A à Ivan. Si quelqu’un avait essayé de se faire passer pour Alice, Ivan s’en serait rendu compte immédiatement à l’étape 2 du protocole et n’aurait pas certifié l’authenticité du message. 3. La signature n’est pas réutilisable. Si Bernard essaie de prendre le certificat d ’Ivan et qu’il l’associe à un autre message, Alice crierait à l’imposture. Alors, un arbitre (qui peut être Ivan, mais cela peut être n’importe quel arbitre ayant accès à la même information) demanderait à Bernard de produire le texte en clair. L’arbitre chiffrerait le texte en clair avec K A et constaterait que le message chiffré ne correspond pas à celui que Alice a donné à Ivan. Bien entendu, Bernard ne peut pas produire un message chiffré valide puisqu’il ne connaît pas K A. 4. Le document signé est immuable. Si Bernard falsifiait le message après l’avoir reçu, Ivan pourrait dévoiler l’imposture exactement de la même façon que celle décrite au paragraphe précédent. 5. La signature ne peut pas être reniée. Même si plus tard, Alice prétend ne pas avoir envoyé le message, le certificat d ’Ivan démontre le contraire. Rappelez-vous que tout le monde a confiance en Ivan, ce qu’il dit est la vérité. Si Bernard veut montrer le document signé par Alice à Christine, il ne peut pas révéler sa clef secrète à Christine. Il doit passer par Ivan également : 1° Bernard prend le message en clair et le texte du certificat d’Ivan, chiffre le tout avec K b et envoie cela à Ivan.
2° Ivan déchiffre le tout avec K b 3° Ivan vérifie dans sa base de données que le message original venait bien d’Alice. 4° Ivan chiffre le tout avec K ç (la clef secrète qu’il partage avec Christine) et envoie le résultat à Christine.
5° Christine déchiffre le tout avec K c . Elle peut maintenant lire le message en clair et le certificat d’Ivan qui affirme qu’Alice a bien envoyé ce message.
Ces protocoles sont valables mais ils sont coûteux en temps pour Ivan. Il doit passer ses journées à chiffrer et déchiffrer des messages, jouant le rôle d’intermédiaire pour toute paire de correspondants qui veulent s’échanger des documents signés. Il doit garder une copie de chaque message (encore que ceci puisse-être évité en envoyant au destinataire une copie du message crypté de l’expéditeur). Ivan va devenir le goulot d ’étranglement du système de communication même s’il est incarné par un programme informatique sans âme. Ce qui est plus ardu reste encore de créer et d ’entretenir quelqu’un comme Ivan, quel qu’un en qui tout le monde dans le réseau a confiance. Ivan doit être infaillible ; même s’il ne fait qu’une erreur sur un million de signatures, personne n’aura confiance en lui. Ivan doit être totalement sûr. Si sa base de données de clefs secrètes venait à être divulguée ou si quelqu’un modifiait son code, toute signature deviendrait inutilisable. Des faux documents prétendument signés des années auparavant pourraient fleurir. Il en résulterait le chaos. Cela pourrait marcher en théorie mais il en va autrement de la pratique.
Chapitre 2
40
Briques élémentaires
Signature de documents à l’aide d’un cryptosystème à clef pu blique Il existe des algorithmes à clef publique qui peuvent être utilisés pour des signatures numériques. Pour certains algorithmes — l’algorithme R SA (voir § 19.3) en est un exemple — la clef publique, ou la clef privée peuvent être utilisées pour le chiffrement. Chiffrez un document avec votre clef privée et vous avez une signature numérique sûre. Dans d’autres cas — l’algorithme DSA (voir § 20.1) en est un exemple — il y a un algorithme séparé pour les signatures numériques qui ne peut pas être utilisé pour le chiffrement. Cette idée a été exprimée pour la première fois par DIFFIE et H e l l m a n [494] et a été étendue et améliorée par d ’autres [1293, 1339, 1034, 1294, 440]. Se référer à [1105] pour une vue générale sur le domaine. Le protocole est simple : 1° Alice chiffre le document avec sa clef privée, signant ainsi le document. 2° Alice envoie le résultat à Bernard.
3° Bernard déchiffre le message avec la clef publique d ’Alice, vérifiant ainsi la signature.
Ce protocole est nettement meilleur que le précédent. Ivan n’est pas nécessaire ni pour signer, ni pour vérifier les signatures8. Alice et Bernard n’ont même pas besoin d’Ivan pour résoudre les contestations : si Bernard ne peut effectuer l’étape 3, alors il sait que la signature n’est pas valide. Ce protocole a aussi les propriétés que nous recherchons : 1. La signature est authentique: quand Bernard vérifie le message avec la clef pu blique d’ Alice, il sait qu’Alice l’a signé. 2. La signature est infalsifiable : seule Alice connaît sa clef privée. 3. La signature n’est pas réutilisable : la signature est une fonction du document et elle ne peut être transférée sur n’importe quel autre document. 4. Le document signé est immuable : s’il y a la moindre falsification du document, il ne peut plus être vérifié avec la clef publique d ’Alice. 5. La signature ne peut pas être reniée. Bernard n’a pas besoin de l’aide d ’Alice pour vérifier sa signature.
Documents signés et datations En fait, Bernard peut duper Alice dans certaines circonstances. Il peut réutiliser la signature et le document ensemble. Ce n’est pas très intéressant si Alice a signé un contrat (qu’est-ce qu’une copie de plus ou de moins du contrat original?) mais cela devient très intéressant si Alice a signé un chèque numérique. Supposons qu’ Alice envoie à Bernard un chèque numérique d’une valeur de 100 francs Bernard porte le chèque à la banque, celle-ci vérifie la signature et transfère l’argent du 8. II est nécessaire pour assurer que la clef publique d ’A lice est bien la sienne.
2.6
Signatures numériques
41
compte d ’Alice au compte de Bernard. Bernard qui est un personnage peu recommandable garde une copie du chèque numérique. La semaine suivante, il peut l’apporter de nouveau à la banque (ou même à une autre banque). La banque vérifie la signature et transfère l’argent d ’un compte à l’autre. Si Alice ne vérifie jamais ses relevés bancaires, Bernard peut continuer ainsi ad vitam aeternam. Pour éviter cela, les signatures numériques contiennent souvent une datation (date + heure) Cette datation de la signature est attachée à l ’ensemble du message et signée avec le reste du message. La banque stocke ces datations dans une base de données. Dès lors, si Bernard essaie d ’encaisser le chèque d’Alice une deuxième fois, la banque compare la datation avec sa base de données. Comme la banque à déjà honoré ce chèque avec la même datation, la banque appelle la police. Bernard passe alors quhize ans en prison et occupe son temps libre à apprendre les protocoles cryptographiques.
Signature de documents à l’aide d’un cryptosystème à clef pu blique et d’une fonction de hachage à sens unique Dans les applications pratiques, les algorithmes à clef publique sont souvent trop in efficaces pour signer de longs documents. Pour gagner du temps, les protocoles de signatures numériques sont souvent réalisés avec des fonctions de hachage à sens unique [432, 433]. Au lieu de signer le document, Alice signe l’empreinte du document. Dans ce protocole, les choix de la fonction de hachage à sens unique et de l’algorithme de signature numérique ont été fixés avant qu’il ne se déroule. 1° Alice calcule, à l’aide de la fonction de hachage à sens unique, l’empreinte de son document. 2° Alice chiffre, à l’aide de l’algorithme de signature numérique, cette empreinte avec sa clef privée, signant ainsi par la même occasion le document.
3° Alice envoie le document et l’empreinte signée à Bernard. 4° Bernard calcule, à l’aide de la fonction de hachage à sens unique,l’empreinte du document qu’Alice lui a envoyé. Ensuite, à l’aide de l’algorithme de signa ture numérique, il déchiffre l’empreinte signée avec la clef publique d’Alice. La signature est valide si l’empreinte de la signature est la même que l’empreinte qu’il a produite.
La vitesse de ce procédé est beaucoup plus élevée et comme les chances d ’avoir deux documents différents ayant la même empreinte de 160 bits sont seulement de 1 sur 2160, tout le monde peut sans crainte identifier la signature de l’empreinte à la signature du document lui-même. Si la fonction utilisée n’est pas à sens unique, il serait aisé de créer plusieurs documents ayant la même empreinte et d ’amener quelqu’un à les signer tous à son insu en ne lui faisant signer qu’un seul. Ce protocole n’est pas valable sans une fonction de hachage à sens unique. Ce protocole a d ’autres avantages. Premièrement, la signature peut être gardée sépa rément du document. Deuxièmement, pour le destinataire, les exigences en espace de stockage pour le document et la signature sont beaucoup plus restreintes. Un système d’archivage peut utiliser ce type de protocole pour vérifier l’existence d ’un document sans stocker son contenu. La base de données centrale ne stockerait que les empreintes des fichiers. Elle ne doit avoir aucun accès aux fichiers ; les utilisateurs envoient leurs
Chapitre 2
Briques élémentaires
empreintes à la base de données, et la base de données enregistre ces empreintes ainsi que la datation. S’il y a par la suite un désaccord quant à l’auteur et la datation d ’un document, la base de données n’a qu’à rechercher l’empreinte dans ses fichiers. Cela a des implications très importantes pour la vie privée : Alice peut obtenir le copyright d’un document et cepandant garder le document secret. Ce n’est que si elle doit prouver ses droits qu’il lui faut rendre le document public (voir § 4.1).
Algorithmes et terminologie Il y a de nombreux algorithmes de signature numérique. Tous sont des algorithmes à clef publique : il y a une information secrète pour signer les documents et il y a une information publique pour vérifier les signatures. Parfois le procédé de signature est appelé ch iffrem en t avec une c le f p riv é e et le procédé de vérification est appelé déch iffrem en t avec une c le f pu bliqu e. Cela prête à confusion et n’est valable que pour un seul algorithme, R SA . Et diffients algorithmes présentent des différences de réalisation. Par exemple, l’utilisation de fonctions de hachage à sens unique et/ou de datations ajoute des étapes aux procédés de signature et de vérification. Plusieurs algorithmes peuvent être utilisés pour des signatures numériques mais pas pour chiffrer. En général, je ferai référence aux procédés de signature et de vérification sans plus entrer dans le détail des algorithmes utilisés. Signer un message avec une clef privée K est noté : Sk ( M )
et vérifier une signature avec une clef publique correspondante est : Vk ( M) .
La séquence de bits associée au document signé (dans l’exemple ci-dessus, l’empreinte du document signée avec la clef privée) sera appelée signature n um ériqu e ou sim plement signature. Le protocole, par lequel le destinataire d’un message est convaincu de l’identité de l’expéditeur et de l’intégrité du contenu du message, est appelé authen tification. Ces protocoles sont exposés plus en détail dans le paragraphe 3.2.
Signatures multiples Comment Alice et Bernard peuvent-ils signer le même document numérique? Sans les fonctions de hachage à sens unique, il y a deux façons de procéder. Dans le premier cas, Alice et Bernard signent séparément des copies du document lui-même. Le message résultant aura le double de la taille du document original. Dans le deuxième cas, Alice signe le document en premier et ensuite Bernard signe la signature d’Alice. Cela marche sauf qu’il est impossible de vérifier la signature d’Alice sans vérifier celle de Bernard. Si une empreinte du document est signée en lieu et place du document lui-même, alors le protocole pour la signature multiple est facile : 1° Alice signe le document. 2° Bernard signe le document.
3° Bernard envoie sa signature à Alice. 4 ° Alice envoie le document, sa signature et la signature de Bernard à Christine.
2.6
Signatures numériques
43
5° Christine vérifie les signatures d’Alice et de Bernard. Alice et Bernard peuvent faire les étapes 1 et 2 en série ou en parallèle. Dans l’étape 5, Christine peut vérifier n’importe quelle signature sans vérifier l’autre.
Non désaveu et signatures numériques Alice peut tricher avec les signatures numériques et il n’y a rien que l’on puisse faire pour l’éviter. Elle peut signer un document et prétendre après coup qu’elle ne l’a pas signé. D ’abord, elle signe le document normalement. Ensuite, elle publie de façon anonyme sa clef privée, ou elle la laisse traîner dans un lieu public, ou elle prétend seulement avoir fait l’une de ces deux actions. Alice prétend alors que sa clef privée est compromise et que d ’autres s’en servent en se faisant passer pour elle. Elle nie avoir signé le document et tout ceux qu’elle avait signés avec sa clef privée. Ceci s’appelle un désaveu. La datation permet de limiter la portée de ce type de tricherie mais Alice peut toujours prétendre que sa clef a été compromise avant la signature du document. Si Alice fait les choses dans les temps, elle peut signer un document puis prétendre ne pas l’avoir fait. Voila pourquoi on entend si souvent parler de clefs privées cachées dans des dispositifs résistant à l’investigation afin qu’Alice n’y ait pas accès et qu’elle ne puisse en abuser. Bien que rien ne puisse être fait pour éviter ce type d’abus, on peut prendre des mesures pour éviter que d’anciennes signatures ne puissent être remises en cause lors de la contestation d ’une nouvelle signature. Par exemple, Alice pourrait « perdre » sa clef pour éviter de payer à Bernard la babiole qu’il lui a vendue la veille et par la même occasion remettre en cause tout débit sur son compte en banque. La solution est pour le destinataire d’un document signé de le faire dater [456], Le protocole général se trouve dans [32]: 1° Alice signe un message. 2° Alice remplie une entête avec des informations sur son identité. Elle signe cette entête et le message signé et envoie le tout à Ivan.
3° Ivan vérifie la signature globale et l’identité d’Alice. Il ajoute une datation au message signé et à l’entête. Ensuite, il signe et envoie le tout à Bernard et Alice.
4° Bernard vérifie la signature d’Ivan, l’identité d’Alice et la signature de celle-ci. 5° Alice vérifie le message que Ivan a envoyé à Bernard. Si elle n’a pas émis le message, elle le fait rapidement savoir.
Un autre protocole utilise Ivan après le fait [213]. Après avoir reçu un message signé, Bernard peut en envoyer une copie à Ivan pour vérification. Ivan peut attester de la validité de la signature d’Alice.
Applications des signatures numériques Une des premières utilisations des signatures numériques fut de vérifier les traités de limitations des essais nucléaires [1460, 1472]. Les États-Unis et l’Union soviétique (quel qu’un sait-il encore ce qu’était l’Union Soviétique?) pouvaient mettre des sismographes
Chapitre 2
44
Briques élémentaires
sur le territoire de leur homologue pour contrôler les essais nucléaires réellement effec tués. Le problème était que la nation qui contrôlait voulait être sûre que l’homologue ne truquait pas les données produites par les sismographes placés sur son sol. De plus, chaque nation voulait s’assurer que les sismographes n’envoient que les informations spécifiquement nécessaires au contrôle. Les techniques d ’authentification traditionnelles permettaient de faire face au premier problème mais seules les signatures numériques permettaient de faire face aux deux problèmes. Grâce à ces dernières, la nation contrôlée pouvait lire les données des sis mographes sur son territoire et la nation qui contrôle savait que les données n’avaient pas été falsifiées.
2.7
Signatures numériques avec chiffrement
En combinant les signatures numériques avec la cryptographie à clef publique, nous pouvons concevoir un protocole qui combine la sécurité du chiffrement avec l’authentification des signatures numériques. Pensez à une lettre signée dans une enveloppe : la signature numérique donne une preuve de l’identité de son auteur et le chiffrement offre la confidentialité. 1° Alice signe le message avec sa clef privée. Sa ( M )
2° Alice chiffre le message signé avec la clef publique de Bernard et lui envoie le résultat. E b (Sa ( M ) )
3° Bernard déchiffre le message avec sa clef privée. D b (E b (Sa { M ) ) ) = S a { M )
4° Bernard vérifie avec la clef publique d ’Alice et obtient le message initial. Va (Sa ( M ) ) = M
Il semble naturel de signer avant de chiffrer. Quand Alice écrit une lettre, elle la signe et le met ensuite dans l’enveloppe. Si elle met la lettre non signée dans l’enveloppe et signe ensuite l’enveloppe, alors Bernard pourrait craindre que la lettre n’aie été remplacée. Si Bernard montrait à Christine la lettre et l’enveloppe d’Alice, Christine pourrait l’accuser de mentir sur la lettre qui est arrivée dans l’enveloppe. En matière de correspondance aussi il est prudent de signer avant de chiffrer. C ’est non seulement plus sûr — un adversaire ne peut retirer la signature d’un message pour y mettre la sienne — mais il faut prendre en compte des considérations légales: si le signataire ne peut pas voir le texte qu’il signe, sa signature pourrait alors être contestée au vues de la loi [1323]. De plus, il existe des attaques cryptanalytiques contre cette technique utilisée avec des signatures R S A (voir § 19.3). Alice n’a aucune raison d’utiliser la même paire clef publique, clef privée pour chiffrer et signer. Elle peut avoir deux paires de clef: une pour chiffrer et une pour signer. La
Ü.7
Signatures numériques avec chiffrement
séparation présente des avantages: elle peut livrer sa clef de chiffrement à la police sans compromettre sa signature, une clef peut être mise en dépôt (voir § 4.13) sans affecter l’autre, et les clefs peuvent avoir des tailles différentes ou encore expirer à des dates différentes. Bien sûr, les messages doivent être datés pour éviter qu’ils ne soient réutilisés. La datation peut aussi aider à se prémunir contre d’autres ennuis comme celui décrit dans le paragraphe suivant.
Renvoyer un message comme accusé de réception Considérons une réalisation de ce protocole avec en plus la possibilité d’envoyer des messages de confirmation. Chaque fois que quelqu’un reçoit un message, il ou elle le renvoie à l’expéditeur comme accusé de réception. 1° Alice signe un message avec sa clef privée, le chiffre avec la clef publique de Bernard et lui envoie le résultat. E b {Sa { M) )
2° Bernard déchiffre le message avec sa clef privée et vérifie la signature avec la clef publique d’Alice, s ’assurant ainsi que c ’est bien Alice qui a signé le message et obtenant également le message en clair. Va (D b (E b (Sa ( M )))) - M
3° Bernard signe le message avec sa clef privée, le chiffre avec la clef publique d’Alice et envoie le résultat à Alice. E A(SB( M ) )
4° Alice déchiffre le message avec sa clef privée, et vérifie la signature avec la clef publique de Bernard. Si le message obtenu est le même que celui qu’elle a envoyé à Bernard, elle sait que celui-ci a reçu le message correctement.
Si le même algorithme est utilisé pour la signature numérique et le chiffrement, une attaque est possible [505]. Dans ce cas, l’opération de signature numérique est l’inverse de l’opération de chiffrement : Vx — E x et S x = E>x • Faisons l’hypothèse que Martin est un utilisateur légitime du système ayant sa propre clef publique et sa propre clef privée. Voyons ce qui se passe si Martin lit le courrier de Bernard. Martin enregistre le message qu’ Alice envoie à Bernard à l’étape 1, puis il envoie ce message à Bernard prétendant en être l’auteur. Bernard pense que c’est un message légitime de Martin, il le déchiffre donc avec sa clef privée et essaie ensuite de vérifier la signature de Martin en le déchiffrant avec la clef publique de Martin. Le message obtenu qui est du pur charabia est : E m {D b {E b {D a {M)))) = E m {D a { M) ) .
Même ainsi, Bernard continue à exécuter le protocole et envoie un accusé de réception à Martin : E m (D b (E m (D a (M)))).
Chapitre 2
Briques élémentaires
Maintenant, il suffit à Martin de déchiffrer le message avec sa clef privée, de le chiffrer avec la clef publique de Bernard, de le déchiffrer une fois de plus avec sa clef privée et finalement de chiffrer le résultat avec la clef publique d ’Alice. Voilà! Martin a A4. Il n’est pas déraisonnable d’imaginer que Bernard puisse envoyer l’accusé de réception de manière automatique. Le protocole peut être, par exemple, inclus dans le logiciel de communication et celui-ci peut envoyer les accusés de réception de manière au tomatique. C ’est, cette obstination à envoyer un accusé de réception à du charabia qui affaiblit le protocole. Si Bernard vérifiait la lisibilité du message avant d ’envoyer l’accusé de réception, il éviterait ce problème de sécurité. Il y a moyen d ’améliorer cette attaque de telle manière que Martin puisse envoyer un message différent de celui qu’il a enregistré. Il est très important de ne jamais signer n’importe quel message envoyé par d ’autres personnes ni de déchiffrer des messages quelconques et de donner le résultat à quelqu’un d’autre.
Protection contre l’attaque L ’attaque ci-dessus marche parce que l’opération de chiffrement est la même que l’opé ration de vérification de signature et que l’opération de déchiffrement est la même que l’opération de signature. Un protocole sûr utiliserait une opération pour le chiffrement légèrement différente de l’opération de signature numérique, l’attaque serait évitée. Le problème peut être résolu en utilisant au choix des clefs différentes pour chaque opération, des algorithmes différents pour chaque opération, des datations qui rendent le message entrant différent du message sortant, ou encore des signatures numériques avec fonction de hachage à sens unique(voir § 2.6). En général, le protocole suivant est parfaitement sûr : 1° Alice signe le message. 2° Alice chiffre le message et sa signature avec la clef publique de Bernard (uti lisant un algorithme de chiffrement différent de celui utilisé pour la signature) et envoie le résultat à Bernard.
3° Bernard déchiffre le message avec sa clef privée. 4° Bernard vérifie la signature d’Alice. Il est possible de modifier le protocole afin qu’Alice chiffre le message avant de le signer. Bien que cela puisse être utile dans certaines circonstances — quand un intermédiaire doit pouvoir vérifier la signature sans être capable de lire le message — en général c ’est mieux de chiffrer tout. Pourquoi donner de l’information à Estelle après tout?
Attaques contre la cryptographie à clef publique Dans tous ces protocoles à clef publique, j ’ai passé sous silence comment Alice obtient la clef publique de Bernard. Le paragraphe 3.1 explique cela en détail mais cela vaut la peine d’en parler maintenant. La méthode la plus facile pour obtenir une clef publique est de l’obtenir à partir d ’une base de données sûre quelque part. Cette base de données doit être publique de telle manière que n ’importe qui puisse y quérir la clef publique de quelqu’un d ’autre. La base de données doit aussi être protégée en écriture sauf pour Ivan ; sinon Martin pourrait
2.8
Générateurs aléatoires et pseudo-aléatoires
remplacer la clef publique de Bernard par une de son choix. Après cela, Bernard ne pourrait plus lire les messages qui lui seraient destinés tandis que Martin le pourrait. Même si les clefs publiques sont stockées dans une base de données sûre, Martin peut encore remplacer une clef par une autre pendant sa transmission. Pour éviter cela, Ivan peut signer chaque clef publique avec sa propre clef privée (voir § 2.6). Quand Ivan fait cela, il agit comme une Autorité d ’Authentification de Clefs ou comme un Centre de Distribution de Clefs (appelons-le C D C en abrégé). Dans les réalisations pratiques, le C D C signe un message composite contenant le nom de l’utilisateur, la clef publique et toute autre information importante concernant l’utilisateur. Ce message composite signé est stocké dans la base de données du C D C . Quand Alice obtient la clef publique de Bernard, elle vérifie la signature du C D C pour s’assurer de la validité de la clef qu’elle a obtenue. En analyse finale, cela ne rend pas les choses impossibles pour Martin, juste plus difficiles. Alice a encore la clef publique du C D C stockée quelque part. Martin doit remplacer cette clef par la sienne, fausser la base de données et remplacer les clefs valides par les siennes toutes signées avec sa clef privée comme s’il était le C D C et alors il est arrivé à ses fins. Même des signatures sur papier peuvent être contrefaites si Martin s’en donne la peine. Comme il a été dit précédemment, cela sera raconté dans les moindres détails au paragraphe 3.1.
2.8
Générateurs aléatoires
aléatoires
et
pseudo
Pourquoi se préoccuper de générateurs aléatoires de nombres dans un livre sur la cryptographie? Il y a déjà un générateur aléatoire de nombres inclus dans chaque compilateur ; ce n’est qu’un simple appel de fonction après tout. Malheureusement, ces générateurs aléatoires de nombres ne sont en général pas sûrs du tout du point de vue cryptographique et probablement même pas très aléatoires. La plupart d’entre eux sont désespérément mauvais. Les générateurs aléatoires de suites ne sont pas aléatoires parce qu’ils ne doivent pas l’être. La plupart des applications simples, telles que les jeux informatiques, ont besoin de tellement peu de nombres aléatoires qu’on ne s’en rend même pas compte. Toutefois, la cryptographie est très sensible aux propriétés des générateurs aléatoires de nombres. Utilisez un générateur de mauvaise qualité et vous commencerez à avoir des corrélations gênantes et des résultats étranges [1239, 1248]. Si la sécurité dépend de votre générateur aléatoire de nombres, des corrélations non désirées ou des résultats étranges ne font pas votre affaire. Le problème d’un générateur aléatoire de nombres est qu’il ne produit pas une suite aléatoire. Probablement, ce qu’il produit ne ressemble même pas de loin à une suite aléatoire. Bien sûr, il est impossible de produire une suite aléatoire à l’aide d ’un or dinateur. K n u t h cite John VON N e u m a n n comme maxime: « Toute personne qui envisage d’utiliser des méthodes arithmétiques pour produire des chiffres aléatoires est, bien sûr, en état de péché. » [864] Les ordinateurs sont des bestioles déterministes : on
les alimente à l’entrée, des opérations tout à fait prévisibles — déterministes — ont lieu à l’intérieur et finalement un résultat sort à l’autre bout. Entrez la même chose en deux instants différents et vous obtiendrez le même résultat à la sortie à chaque
Chapitre 2
Briques élémentaires
fois. Entrez la même chose dans deux ordinateurs identiques et le même résultat sera produit par chacun d ’eux. Il n’y a qu’un ensemble fini d ’états dans lesquels peut se trouver un ordinateur (un grand nombre fini, mais un nombre fini toutefois) et ce qui sort sera toujours une fonction déterministe de ce qui entre et de l’état de l’ordinateur. Cela veut dire que tout générateur aléatoire de nombres sur ordinateur (du moins, sur une machine de Turing) est, par définition, périodique. Tout ce qui est périodique est, par définition, prévisible. Et ce qui est prévisible n’est pas aléatoire. Un vrai générateur aléatoire de suites nécessite une entrée vraiment aléatoire ; un ordinateur ne peut pas fournir cela.
Suites pseudo-aléatoires Le mieux que peut produire un ordinateur est un gén érateu r p seu d o-a léa toire de suites. Qu’est-ce? Beaucoup de gens se sont attaqués au problème de définir cela formellement, mais je m ’abstiendrai ici. La période de la suite doit être suffisamment longue de telle manière qu’une suite finie de longueur raisonnable — c ’est-à-dire une suite qui soit utile dans un contexte donné — ne soit pas périodique. En d’autres termes, si vous avez besoin d ’une suite d’un milliard de bits aléatoires, ne choisissez pas un générateur qui a une période de 16000 bits. Ces sous-suites non périodiques relativement courtes, doivent être autant que possible indiscernables d ’une suite aléa toire. Par exemple, elles doivent avoir le même nombre de 1 que de 0 ; à peu près la moitié des segments (suites de bits ayant la même valeur) doivent être de longueur 1, un quart de longueur 2, un huitième de longueur 3, etc. On ne doit pas pouvoir les compresser. Les distributions des segments de 0 et des segments de 1 doivent être les mêmes [645, 864, 106, 1359]. Ces propriétés peuvent être mesurées empiriquement et comparées aux prévisions statistiques en utilisant un test en y 2. Pour nos besoins, un générateur de suites est pseudo-aléatoire s’il satisfait la propriété suivante : 1. Il a l’air aléatoire. Cela veut dire qu’il réussit tous les tests statistiques que l’on peut trouver. (Commencez par ceux décrits dans [864].) Pas mal d’efforts ont été investis pour produire des bonnes suites pseudo-aléatoires sur ordinateur. Les descriptions de tels générateurs abondent dans la littérature aca démique, avec des tests variés sur leur caractère aléatoire. Tous ces générateurs sont périodiques (il n’y a pas moyen de l’éviter) ; mais avec des périodes potentielles de 2256 bits et plus, il peuvent être utilisés pour les applications les plus exigeantes. Mais le problème des corrélations non désirées et des résultats étranges est toujours présent. Tout générateur déterministe en produira si vous l’utilisez d’une certaine façon. Et c’est cette propriété que le cryptanalyste utilisera pour attaquer le système.
Générateurs pseudo-aléatoires cryptographiquement sûrs Les applications cryptographiques exigent plus des générateurs pseudo-aléatoires de suites que les autres applications informatiques. « Aléatoire du point de vue de la cryptographie » ne signifie pas statistiquement aléatoire bien que cela en fasse partie. Pour qu’une suite pseudo-aléatoire soit cry p tog ra p h iq u em en t sûre, le générateur
2.8
Générateurs aléatoires et pseudo-aléatoires
49
doit en plus satisfaire la propriété suivante : 2. Il est imprévisible. Il doit être impossible par calcul de prédire quel sera le bit aléa toire suivant, connaissant complètement l’algorithme ou le matériel qui engendre la suite et connaissant tous les bits déjà engendrés. Les suites pseudo-aléatoires cryptographiquement sûres ne peuvent être comprimées...à moins d’avoir le secret : le germe utilisé pour initialiser le générateur. Comme tout algorithme cryptographique, les générateurs pseudo-aléatoires de suites cryptographiquement sûrs peuvent subir des attaques. Tout comme il est possible de casser un algorithme de chiffrement, il est possible de casser un générateur pseudo aléatoire de suites cryptographiquement sûr. Faire des générateurs résistant aux at taques est tout l’intêret de la cryptographie.
Suites vraiment aléatoires Maintenant nous entrons dans le domaine des philosophes. Existe-t-il quelque chose d'aléatoire! Qu’est-ce qu’une suite aléatoire? Comment savoir si une suite est aléatoire? Est-ce que « 101110100 » est plus aléatoire que « 101010101 » ? La mécanique quantique nous apprend qu’il y a des phénomènes physiques que l’on peut qualifier d’aléatoire dans le monde réel. Mais est-ce que ce caractère aléatoire est préservé quand on le transpose dans le monde macroscopique des puces informatiques et des machines à nombre d’états fini? Toute philosophie mise à part, de notre point de vue, un générateur de suites est vraiment aléatoire s’il jouit de la propriété suivante : 3. Il ne peut pas être reproduit de manière fiable. Si vous exécutez le générateur de suites deux fois avec exactement les mêmes entrées (du moins des entrées aussi identiques que possible), vous obtenez deux suites aléatoires différentes. La sortie d’un générateur satisfaisant ces trois propriétés conviendrait pour engendrer un masque jetable, générer des clefs ou pour toute autre application cryptographique qui a besoin d ’un générateur vraiment aléatoire. La difficulté est de déterminer si une suite est vraiment aléatoire. En chiffrant de manière répétée une chaîne avec DES et une clef fixée, on obtient une suite qui a l’air aléatoire; vous ne pourrez pas savoir si elle n’est pas aléatoire, à moins d ’employer l’équipe de la NSA qui travaille sur le DES.
Chapitre 3
Protocoles élémentaires 3.1
*
Echange de clefs
Une technique cryptographique courante consiste à utiliser une clef différente pour chiffrer chaque conversation entre deux individus. On parlera alors de clef de session parce qu’elle n’est utilisée que pour une session particulière de communication. Comme on le vera au paragraphe 8.5, les clefs de session sont utiles car elles n ’existent que durant la durée de la communication. Il n’est pas simple de faire aboutir cette clef de session commune entre les mains des participants de la conversation.
Échange de clefs à l’aide de la cryptographie à clef secrète On fait l’hypothèse que Alice et Bernard sont des utilisateurs d’un réseau, et partagent chacun une clef avec, le Centre de Distribution des Dlefs (CDC)[1270], Ivan dans notre protocole. Ces clefs doivent être mises en service avant le protocole1. 1° Alice appelle Ivan et demande une clef de session pour communiquer avec Bernard.
2° Ivan engendre aléatoirement une clef de session. Il chiffre deux copies de celleci, l’une avec une clef secrète qu’il partage avec Alice, et l’autre avec une clef secrète qu’il partage avec Bernard. Ivan envoie les deux copies à Alice.
3° Alice déchiffre sa copie de la clef de session. 4° Alice envoie à Bernard sa copie de la clef de session. 5° Bernard déchiffre sa copie de la clef de session. 6° Alice et Bernard utilisent la clef de session pour communiquer confidentielle ment.
Ce protocole repose sur la sécurité absolue de Ivan qui sera plutôt un programme informatique de confiance qu’une personne de confiance. Si Martin corrompt Ivan, tout le réseau est compromis. Il a alors à sa disposition toutes les clefs secrètes que 1. Le protocole passe sous silence le réel problèm e de la distribution de ces clefs secrètes; on fait l’hypothèse q u ’elles sont en service et que M artin ne sait pas où elles se trouvent.
Chapitre 3
52
Protocoles élémentaires
Ivan partage avec tous les utilisateurs ; il peut lire tous les messages passés qu’il a enregistrés et toutes les communications futures. Tout ce qu’il doit faire c’est placer une écoute sur les lignes de communication et enregistrer le trafic des messages chiffrés. L’autre inconvénient de ce système est que Ivan représente un potentiel goulot d ’étran glement. Il doit participer à chaque échange de clef. Si Ivan se trompe, cela perturbe tout le système.
Échange de clefs à l’aide de la cryptographie à clef publique Le cryptosystème hybride de base a été décrit dans le paragraphe 2.5. Alice et Bernard utilisent la cryptographie à clef publique pour se mettre d’accord sur une clef de session, et l’utilisent pour chiffrer des données. Dans une application pratique, les deux clefs publiques signées d’Alice et Bernard seront accessibles dans une base de donnée. Cela rend le protocole plus simple, et Alice peut envoyer de manière sûre un message à Bernard, même s’il n’a jamais entendu parler d ’elle : 1° Alice obtient la clef publique de Bernard de la part du C D C . 2° Alice engendre une clef de session aléatoire, la chiffre avec la clef publique de Bernard et envoie le résultat à Bernard.
3°
Bernard déchiffre
4°
Alice et Bernard conversation.
le message d’Alice en utilisant sa clef privée. utilisent alors la même clef de session pour chiffrer leur
L’attaque de l’intercepteur Tandis qu’Estelle ne peut pas faire mieux que tenter de casser l’algorithme à clef publique, ou tenter une attaque à texte chiffré seulement contre les textes chiffrés, Martin peut déchiffrer les messages entre Alice et Bernard. Martin est beaucoup plus fort qu’Estelle. Non seulement il peut écouter les messages entre Alice et Bernard, mais il peut aussi modifier des messages, détruire des messages et en insérer des nouveaux de son cru. Martin peut se faire passer pour Bernard en s’adressantà Alice et se faire passer pour Alice en s’adressant à Bernard. Voici comment l’attaque peut être conduite : 1° Alice envoie sa clef publique à Bernard. Martin intercepte cette clef et envoie sa propre clef publique à Bernard.
2° Bernard envoie sa clef publique à Alice. Martin intercepte cette clef et envoie sa propre clef publique à Alice.
3° Quand Alice envoie un message à Bernard, chiffré avec ce qu’elle croit être la clef publique de Bernard, Martin l ’intercepte. Comme ce message est en fait chiffré avec sa clef publique, il le déchiffre avec sa clef privée, le chiffre à nouveau avec la clef publique de Bernard et envoie le résultat à Bernard.
4° Quand Bernard envoie un message à Alice, chiffré avec ce qu’il croit être la clef publique d’Alice, Martin l’intercepte. Comme ce message est en fait chiffré avec sa clef publique, il le déchiffre avec sa clef privée, le chiffre à nouveau avec la clef publique d’Alice et envoie le résultat à Alice.
3.1
Échange de clefs
53
Même si les clefs publiques d ’Alice et de Bernard sont stockées dans une base de données, cette attaque peut être conduite. Il suffit que Martin intercepte la requête d’Alice vers la base de données et qu’il envoie à Alice sa propre clef publique à la place de celle de Bernard. Il peut faire la même chose avec Bernard et remplacer la clef d’Alice par la sienne. Il peut même subrepticement pénétrer dans la base de données et remplacer les clefs d’Alice et Bernard par sa clef publique. Le lendemain, il attend simplement qu’Alice et Bernard dialoguent entre eux. Il intercepte alors les messages et les modifie. Il a réussi. L’attaque de l’intercepteur marche parce qu’Alice et Bernard n’ont aucun moyen de vérifier qu’ils parlent bien l’un à l’autre. En faisant l’hypothèse que Martin est rapide et qu’il n’introduit pas de délai notable dans le comportement du réseau, aucun des deux ne peut soupçonner que quelqu’un est là entre eux deux en train d ’espionner toute leur correspondance supposée confidentielle.
Protocole à cliquets Le protocole à cliquets, inventé par Ron R i v e s t et Adi S h a m i r [1338] a de bonnes chances de repousser l’attaque de l’intercepteur. Voici comment cela marche : 1° Alice envoie sa clef publique à Bernard. 2° Bernard envoie sa clef publique à Alice. 3° Alice chiffre son message avec la clef publique de Bernard. Elle envoie la moitié du message chiffré à Bernard.
4° Bernard chiffre son message avec la clef publique d’Alice. Il envoie la moitié du message chiffré à Alice.
5° Alice envoie l’autre moitié de son message chiffré à Bernard. 6° Bernard réunit les deux morceaux du messagechiffré venant d’Alice le résultat avec sa clef privée. Bernard envoie l’autremoitié de son chiffré à Alice.
et déchiffre message
7° Alice réunit les deux morceaux du message chiffré venant de Bernard et dé chiffre le résultat avec sa clef privée.
Le point important est qu’une moitié de message est inutilisable sans l’autre moitié ; on ne peut déchiffrer les moitiés séparément. Bernard ne peut lire aucune partie du message d ’Alice avant l’étape 6 et Alice ne peut lire aucune partie du message de Bernard avant l’étape 7. Il y a plusieurs moyens de réaliser cela : - Si l’algorithme de chiffrement est un algorithme par blocs, chaque moitié de chaque bloc (par exemple, un bit sur deux) peut être envoyée dans chaque moitié de message chiffré. - Le déchiffrement du message peut être dépendant du vecteur d’initialisation (voir § 9.3) qui ne serait envoyé qu’avec la deuxième moitié du message. - La première moitié du message pourrait être une empreinte du message chiffré (voir § 2.4) et le message chiffré lui-même pourrait être la seconde moitié.
54
Chapitre 3
Protocoles élémentaires
Pour voir comment cela complique la vie de Martin, revoyons sa tentative de corruption du protocole. Il peut toujours remplacer les clefs publiques d ’Alice et de Bernard par sa propre clef publique dans les étapes 1 et 2. Mais maintenant, quand il intercepte la première moitié du message d’ Alice à l’étape 3, il ne peut pas le déchiffrer avec sa clef privée et le rechiffrer avec la clef publique de Bernard. Il doit inventer un nouveau message et envoyer la moitié à Bernard. Quand il intercepte la moitié du message de Bernard vers Alice à l’étape 4, il a le même problème. Il ne peut pas le déchiffrer avec sa clef privée et le rechifîrer avec la clef publique d’Alice. Il doit inventer un nouveau message et envoyer la moitié de celui-ci à Alice. Quand il intercepte les deux autres moitiés des messages d ’Alice et de Bernard aux étapes 5 et 6, il est trop tard pour qu’il puisse changer les nouveaux messages qu’il a inventés. La conversation entre Alice et Bernard sera forcément complètement différente de ce qu’elle aurait dû être. Martin peut peut-être appliquer ce schéma. S’il connaît Alice et Bernard suffisamment pour imiter les deux côtés d ’une conversation entre eux, alors ils ne se rendront jamais compte qu’ils sont dupés. Mais c ’est certainement plus difficile pour Martin que de simplement intercepter et lire les messages qu’ils s’échangent.
Échange de clefs à l’aide de signatures numériques L’utilisation de signatures numériques pendant un protocole d ’échange de clefs de ses sion permet également d’éviter l’attaque de l’intercepteur. Ivan signe les clefs publiques d’Alice et de Bernard. Les clefs signées contiennent un certificat de propriété signé. Quand Alice et Bernard reçoivent les clefs, ils vérifient chacun la signature d’Ivan. Après cela, ils savent que la clef publique appartient bien à leur correspondant. Le protocole d ’échange de clefs de session peut alors avoir lieu. Martin a de sérieux problèmes. Il ne peut pas se faire passer pour Alice ou Bernard car il ne connaît pas leurs clefs privées. Il ne peut pas remplacer une des clefs publiques par la sienne parce que sa clef est signée comme étant celle de Martin. Tout ce qu’il peut faire c ’est écouter le trafic entre Alice et Bernard ou encore il peut couper la ligne pour empêcher Alice et Bernard de dialoguer. Ce protocole repose sur Ivan mais le risque de corrompre le C D C est nettement in férieur. Si Martin corrompt Ivan (s’il investit le C D C ), tout ce qu’il obtient c ’est la clef privée d ’Ivan. Cette clef ne lui permet que de signer de nouvelles clefs ; il ne peut déchiffrer aucune clef de session ou lire quelque message que ce soit. Pour pouvoir lire les messages qui transitent, Martin doit pouvoir se faire passer pour un utilisateur du réseau et amener des utilisateurs légitimes à chiffrer des messages avec sa fausse clef publique. Martin peut monter ce geiue d’attaque. Avec la clef privée d’Ivan, il peut créer des clefs signées factices pour tromper Alice et Bernard. Après, soit il peut les enregistrer dans la base de données à la place des clefs légitimes, soit il peut intercepter les requêtes vers la base de données et répondre à la place de celle-ci en envoyant ses clefs factices. Cela lui permet de mettre en œuvre une attaque de l’intercepteur et d’écouter les communications des utilisateurs. Cette attaque marche, mais rappelez-vous que Martin doit être un attaquant puissant. Intercepter et modifier des messages est nettement plus difficile que de lire et déchiffrer les messages qui transitent sur un réseau qui utilise un algorithme à clef secrète. Sur un canal de diffusion, tel qu’un réseau radio, il est presque impossible de remplacer un message par un autre, encore que le réseau entier puisse être brouillé. Dans les
3.1
55
Échange de clefs
réseaux informatiques, c’est plus facile et il semble que cela devienne plus facile chaque jour. Il est possible de duper les protocoles d ’intercommunication et d ’attaquer les routeurs d’un réseau; les attaque actives ne signifient pas quelqu’un dans les égouts avec un stétoscope et elles ne sont pas réservées aux agences dont le nom comporte trois lettres.
Transmission simultanée de clefs et de messages Alice et Bernard n’ont pas besoin de terminer le protocole d ’échange de clefs avant d’échanger des messages. Dans le protocole suivant, Alice envoie un message, A4, à Bernard sans qu’il n’y ait eu d ’échange de clefs au préalable : 1° Alice engendre une clef de session aléatoire, K , et chiffre A4 en utilisant K . E k (M)
2° Alice obtient la clef publique de Bernard par la base de données. 3° Alice chiffre K avec la clef publique de Bernard. E b ( K)
4° Alice envoie le message chiffré et la clef de session chiffrée à Bernard. E k (A4),E b ( K )
Pour mieux se prémunir contre une attaque de l’intercepteur, Alice peut signer la transmission.
5° Bernard déchiffre la clef de session, K , en utilisant sa clef privée. 6° Bernard déchiffre le message d’Alice en utilisant la, clef de session. C’est avec ce système hybride que la cryptographie à clef publique est souvent utilisée dans les systèmes de communication. Elle peut être combinée aux signatures numé riques, à la datation, ou à tout autre protocole de sécurité.
Diffusion de clef et de message Il n’y a pas de raison pour qu’Alice ne puisse envoyer le message chiffré à plusieurs personnes. Dans l’exemple suivant, Alice envoie le message chiffré à Bernard, Christine et David : 1° Alice engendre une clef de session aléatoire, K , et chiffre A4 avec K . E k (A4)
2° Alice obtient les clefs publiques de Bernard, Christine et David par la base de données.
3° Alice chiffre K avec la clef publique de Bernard, chiffre K avec la clef publique de Christine et chiffre K avec la clef publique de David. E b (K) , E c ( K) ,E d (K)
Chapitre 3
56
Protocoles élémentaires
4° Alice diffuse le message chiffré et toutes les clefs chiffrées à qui veut bien les recevoir. E b (K),Ec (K),Ed (K),Ek ( M )
5° Seuls Bernard, Christine et David peuvent déchiffrer la clef de session K à l’aide de leur clef privée.
6° Seuls Bernard, Christine et David peuvent déchiffrer le message d'Alice en utilisant K .
Cet algorithme peut être réalisé dans un réseau « stocke-et-relaie ». Un serveur central peut relayer le message d’Alice à Bernard, Christine et David avec chacun une version chiffrée de la clef de session. Le serveur n’a pas à être sûr et il n’a pas à avoir la confiance des utilisateurs car il ne peut déchiffrer aucun message.
3.2
Authentification
Quand Alice accède à un ordinateur (ou un distributeur de billets automatique, ou un service de banque à domicile, ou tout autre type de terminal), comment l’ordinateur peut-il savoir qui elle est? Comment l’ordinateur sait-il qu’elle n’est pas Estelle essayant de se faire passer pour Alice? Traditionnellement, les mots de passe servent à résoudre ce problème. Alice entre un mot de passe, et l’ordinateur confirme qu’il est correct. Alice et l’ordinateur connaissent tous deux cette information secrète, et l’ordinateur le demande à Alice chaque fois qu’elle essaie d’entrer en communication avec lui.
Authentification à l’aide de fonctions à sens unique Ce que Roger N e e d i i a m et Mike G u y ont réalisé, c’est que l’ordinateur n’a pas besoin de connaître les mots de passe: l’ordinateur doit juste être capable de distinguer un mot de passe correct d ’un mot de passe incorrect. C ’est facile à l’aide de fonctions à sens unique [1601, 528, 1285, 1127]. Au lieu de stocker les mots de passe, l’ordinateur stocke le résultat de la fonction à sens unique appliquée à chacun des mots de passe. 1° Alice envoie son mot de passe à l’ordinateur. 2° 3°
L ’ordinateur calcule la fonction à sens unique du mot de passe. L ’ordinateur compare le résultat de ce calcul à données.
celui qu’il a danssa
L’attaque de quelqu’un qui pénètre dans le système informatique et qui vole la liste des mots de passe est moins à craindre, car l’ordinateur ne stocke plus la table des mots de passe corrects mais bien la liste des résultats de l’application de la fonction à sens unique aux mots de passe. Cette liste est inutilisable parce que la fonction à sens unique ne peut pas être inversée pour retrouver les mots de passe.
Attaque par dictionnaire et salage Même le fichier des mots de passe chiffrés avec une fonction à sens unique est vulnérable. Pendant son temps libre, Martin construit la liste des 1000 000 mots de passe les plus
basede
3.2
Authentification
57
utilisés. Il calcule alors la fonction à sens unique pour tous les 1000 000 mots de passe et stocke le résultat. Si chaque mot de passe a environ 8 octets, le fichier résultant n’aura pas plus de 8 méga-octets ; ce qui tient aisément sur quelques disquettes. Ensuite, Martin vole le fichier des mots de passe chiffrés. Il compare les mots de passe chiffrés avec son fichier des mots de passe chiffrés possibles et localise ceux qui sont identiques. C’est une attaque par dictionnaire. Celle-ci est étonnamment efficace en pratique (voir § 8.1). Le salage est un moyen de rendre cette attaque plus difficile. Le sel est une chaîne aléatoire qui est jointe au mot de passe avant qu’il ne soit transformé par la fonction à sens unique. Ensuite, le sel utilisé et le résultat de la fonction à sens unique sont tous deux stockés dans la base de données. Si le nombre de valeurs de sel possibles est suffisamment grand, cela empêche presque tout à fait l’attaque par dictionnaire de mots de passe communs car Martin doit calculer les valeurs de la fonction à sens unique pour chaque sel. C ’est un embryon de vecteur d ’initialisation (voir § 9.3). L’idée ici est d’obliger Martin à chiffrer chacun des mots de passe de son dictionnaire qu’il tente comme mot de passe de quelqu’un et ce pour chaque nouvelle personne et non une fois pour toutes. Il faut pas mal de sel. La plupart des systèmes U N IX n’utilisent que 12 bits pour le sel. Même avec cela, Daniel K l e in a développé un programme qui retrouve 21 % des mots de passe sur un système donné en à peu près une semaine [848, 849]. David F e l d m e ie r et Philip K a r n ont rassemblé une liste d ’environ 732 000 mots de passe communs combinés avec 4096 valeurs possibles de sel. Ils estiment qu’environ 30 % des mots de passe d’un système donné peuvent être retrouvés grâce à cette liste [563]. Saler n’est par le remède universel; augmenter le nombre de bits du sel ne va pas résoudre tous les problèmes. Le sel ne protège que contre les attaques par dictionnaires contre un fichier de mots de passe chiffrés, mais non contre une attaque concertée dirigée contre un seul mot de passe. Le salage masque le fait que certaines personnes ont le même mot de passe sur plusieurs systèmes mais cela ne rend pas meilleurs des mots de passe mal choisis.
SKEY SKEY est un programme d’authentification dont la sécurité repose sur une fonction à sens unique / . Il est facile à expliquer. Pour mettre en place le système, Alice entre un nombre aléatoire R. L ’ordinateur calcule f(R), f {f {R)) , f(.f(f(R))) et ainsi de suite cent fois. Notons ces nombres X i , . . . , x 10oL’ordinateur affiche la liste de ces nombres et Alice la met dans sa poche à l’abri. L’ordinateur conserve aussi Xioi en clair dans une base de données à côté du nom d’Alice. La première fois qu’Alice veut se connecter, elle entre son nom et aqoo- L’ordinateur cal cule f ( x ioo) et le compare avec arioiî s’il sont égaux, Alice est authentifiée. L’ordinateur remplace alors aqoi par .x10o dans la base de données. Alice barre aqoo de sa liste. Chaque fois qu’Alice se connecte, elle entre le dernier nombre x* qu’elle n’a pas encore barré sur sa liste. L ’ordinateur calcule f{xf) et le compare avec xi + 1 qui se trouve dans la base de donnée. Estelle ne peut pas obtenir d ’information intéressante car chacun des nombres n’est utilisé qu’une seule fois, et la fonction est à sens unique. De cette manière, un attaquant ne peut pas se servir de la base de données. Bien sûr, quand
58
Chapitre 3
Protocoles élémentaires
Alice est à court de nombres sur sa liste, elle doit refaire l’opération d ’initialisation du système.
Authentification grâce à la cryptographie à clef publique Même avec du sel, le premier protocole présente des défauts de sécurité sérieux. Quand Alice entre son mot de passe dans le système, toute personne qui a accès au chemin des données entre le point de saisie et l’ordinateur hôte 2 peut le lire. Elle peut accéder à l’ordinateur hôte à travers un long chemin tortueux en passant par quatre sociétés industrielles concurrentes, trois pays, ou encore deux universités avant-gardistes. En chacun de ces points de passages, Estelle peut écouter la séquence d’accès. Si Estelle a accès au processeur et à la mémoire de l’ordinateur hôte, elle peut lire le mot de passe avant qu’il ne soit chiffré. La cryptographie à clef publique peut résoudre ce problème. L’ordinateur hôte gère un fichier avec la clef publique de chaque utilisateur ; chaque utilisateur garde sa clef privée. Voici un premier protocole naïf. Lors de la séquence d ’accès, le protocole se déroule comme suit : 1° L ’ordinateur hôte envoie une chaîne de caractères aléatoire à Alice. 2° Alice chiffre cette chaîne avec sa clef privée et envoie le résultat à l’ordinateur hôte avec son nom.
3° L ’ordinateur hôte utilise la clef publique d’Alice qui est dans sa base de données et déchiffre le message à l ’aide de celle-ci. 4° Si la chaîne obtenue est la même que celle que l’ordinateur hôte a envoyée à Alice en premier lieu, l’ordinateur hôte sait que c ’est bien Alice qui essaie d ’accéder au système.
Personne d’autre n’a accès à la clef privée d’Alice et donc personne ne peut se faire passer pour Alice. Ce qui est plus important encore : Alice n’envoie jamais sa clef privée sur la ligne de communication vers l’ordinateur hôte. Estelle, qui écoute le protocole, ne peut obtenir aucune information qui lui permette de deviner la clef privée ou de se faire passer pour Alice. La clef privée est longue et non mnémonique. De plus, elle sera manipulée automatique ment par le logiciel et le matériel de communication de l’utilisateur. Le terminal d’Alice doit donc être « intelligent » et Alice doit avoir confiance en lui, mais ni l’ordinateur hôte à distance, ni le canal de communication n’ont à être sûrs. En général, il est idiot de chiffrer des chaînes de caractères aléatoires envoyées par un autre participant : des attaques telles que celles décrites dans le paragraphe 19.3 peuvent être montées. Un protocole de preuve d ’identité sûr prend la forme plus compliquée suivante : 1° Alice effectue des calculs à partir de quelques nombres aléatoires et de sa clef privée. Elle envoie le résultat à l’ordinateur hôte.
2° L ’ordinateur hôte envoie à Alice un nombre aléatoire différent. 2. N ote du traducteur : on parlera ici d ’ « ordinateur hôte » pour désigner l’ordinateur auquel Alice désire se connecter pour le différencier de l’ordinateur dont A lice se sert éventuellement pour se connecter, stocker sa clef privée et effectuer sa part des calculs. C e dernier ne doit pas forcément être un P C mais peut tou t aussi bien être une carte à puces.
3.2
Authentification
59
3° Alice effectue des calculs à partir des nombres aléatoires (ceux qu’elle avait choisis et celui qui lui a été envoyé par l’ordinateur) et de sa clef privée. Elle envoie le résultat à l’ordinateur hôte.
4° L ’ordinateur hôte effectue un calcul à partir des différents nombres qu ’il a reçus d’Alice et de la clef publique d’Alice pour vérifier qu’Alice connaît bien sa clef privée.
5° Si tel est le cas, l’identité d’Alice est vérifiée. Si Alice n’a pas plus confiance en l’ordinateur hôte que l’ordinateur hôte n’a confiance en Alice, alors Alice peut demander à l’ordinateur hôte de prouver son identité de la même manière. L’étape 1 peut paraître superflue et déroutante mais elle est nécessaire pour résister à certaines attaques. Les sections 21.1 et 21.2 décrivent mathématiquement plusieurs algorithmes et protocoles. Voyez aussi [946].
Authentification mutuelle par protocole à cliquets Alice et Bernard sont deux utilisateurs qui veulent s’identifier mutuellement. Chacun d’entre eux a un mot de passe que l’autre connaît: Alice a Pa et Bernard a Pg. Voici un protocole qui ne marche pas : 1° Alice et Bernard échangent leurs clefs publiques. 2° Alice chiffre Pa avec la clef publique de Bernard et envoie le résultat à Bernard.
3° Bernard chiffre Pg avec la clef publique d’Alice et envoie le résultat à Alice. 4° Alice déchiffre PB et vérifie que c 'est correct. 5° Bernard déchiffre P a et vérifie que c ’est correct. Martin peut monter avec succès une attaque de l’intercepteur (voir § 3.1) : 1° Alice et Bernard échangent leurs clefs publiques. Martin intercepte les deux messages. Il remplace la clef publique de Bernard par la sienne et envoie le résultat à Alice. Il remplace la clef publique d’Alice par la sienne et envoie le résultat à Bernard.
2° Alice chiffre Pa avec la clef publique qu’elle croit être celle de Bernard et envoie le résultat à Bernard. Martin intercepte le message, déchiffre P a avec sa clef privée, rechiffre Pa avec la clef publique de Bernard et envoie le résultat à Bernard.
3° Bernard chiffre Pg avec la clef publique qu’il croit être d’Alice et envoie le résultat à Alice. Martin intercepte le message, déchiffre Pg avec sa clef privée, rechiffre Pg avec la clef publique d’Alice et envoie le résultat à Alice.
4° Alice déchiffre Pg et vérifie que c ’est correct. 5° Bernard déchiffre P a et vérifie que c ’est correct. Du point de vue d’Alice et Bernard, rien ne change. Mais maintenant, Martin connaît Pa et Pg
Chapitre 3
60
Protocoles élémentaires
Donald D a v ie s et W yn P r ic e décrivent comment le protocole à cliquets peut empêcher cette attaque [435] : Steve B e l l o v i n et Michael M e r r i t t décrivent des méthodes d’attaque contre ce protocole [118]. Si Alice est un utilisateur et Bernard un ordinateur hôte, Martin peut prétendre être Bernard, exécuter les étapes 1 à 5 du protocole avec Alice et ensuite couper la communication. Cela doit être idéalement fait avec grand art par Martin en simulant du bruit de ligne ou des pannes de réseau mais peu importe, Martin a le mot de passe d’Alice. Il peut maintenant se mettre en communication avec Bernard et compléter le protocole. Voilà ! Martin a le mot de passe de Bernard. Le protocole peut être modifié de telle manière que Bernard donne son mot de passe avant Alice en faisant l’hypothèse que le mot de passe de l’utilisateur est nettement plus sensible que le mot de passe de l’ordinateur hôte. Une variante plus compliquée permet d’attaquer cette version modifiée du protocole (voir [118]).
SKID SKID2 et SK ID 3 sont des protocoles d’identification à clef secrète développés pour le projet R IP E du programme R A C E [1316] (voir § 25.7). Ils utilisent une fonction à sens unique à clef (un C A M , pour « Code d'Authentification de Messages », voir § 2.4) pour fournir la sécurité, et tous les deux font l’hypothèse qu’Alice et Bernard partagent une clef secrète K . SKID2 permet à Bernard de prouver son identité à Alice. Voici le protocole : 1° Alice choisit un nombre aléatoire, R a ■ Le document R IP E précise qu’il doit avoir 64 bits. Elle l’envoie à Bernard.
2° Bernard choisit un nombre aléatoire, R b - Le document R IP E précise qu’il doit avoir 64 bits. Il envoie à Alice : R b ,H k {R a ,Rb ,B) H k est le C A M . (Le document R IP E suggère d’utiliser la fonction R IP E M A C — voir § 18.14). Dans la formule, B est le nom de Bernard.
3° Alice calcule H k (R a , R b ,B) et compare avec ce qu’elle a reçu de Bernard. Si les valeurs sont égales alors Alice sait qu’elle communique avec Bernard.
SKID3 offre l’identification mutuelle d ’Alice et Bernard. Les tiques à celles de SKID2 et le protocole se poursuit ainsi :
étapes1 à3 sontiden
4° Alice envoie à Bernard : H k {R b ,A) Dans la formule, A est le nom d’Alice.
5° Bernard calcule H k {R b ,A) et compare avec ce qu’il a reçud’Alice. Silès va leurs sont égales alors Bernard sait qu’il communique avec Alice.
Ce protocle n’est pas sûr contre l’attaque de l’intercepteur. En général, l’attaque de l’intercepteur est à redouter dans les protocoles qui ne mettent pas en jeu un secret de quelque nature que ce soit.
3.3
Authentification et échange de clefs
61
Authentification de message Quand Bernard reçoit un message de la part d ’Alice, comment est-il sûr de son authen ticité? Si Alice a signé son message, c’est facile. La signature numérique suffit pour convaincre n’importe qui de l’authenticité du message. La cryptographie à clef secrète permet une part d’authentification. Quand Bernard reçoit de la part d ’Alice un message chiffré avec la clef qu’il partagent, il sait qu’il vient bien d’Alice. Personne d’autre ne connaît leur clef. Toutefois, Bernard n’a aucun moyen de prouver ce fait à un troisième parti. Bernard ne peut pas montrer le message à Ivan et le convaincre qu’il vient d ’Alice. Ivan peut être convaincu que le message vient soit d ’Alice, soit de Bernard (car ils sont les seuls à posséder cette clef secrète), mais il ne peut pas savoir lequel. Si le message n’est pas chiffré, Alice pourrait aussi utiliser un CAM . Cela convaincra aussi Bernard de l’authenticité du message, mais cela présente le problème que la solution apportée par la cryptographie à clef secrète.
3.3
Authentification et échange de clefs
Les protocoles suivants résolvent un problème informatique général. Alice et Bernard sont en deux points distants d’un réseau. Ils veulent dialoguer entre eux en toute confidentialité. Comment Alice et Bernard peuvent-ils échanger une clef secrète et en même temps être sûrs qu’ils se parlent bien l’un à l’autre et non pas à Martin? Dans la plupart des cas, on fait l’hypotlièse qu’Ivan partage une clef secrète distincte avec chaque participant et que ces clefs ont été mises en place avant le début du protocole. La tableau 3.1 récapitule les symboles rencontrés dans les protocoles.
- Symboles utilisés dans les protocoles d’authentification et déchange de clefs le nom d’Alice le nom de Bernard chiffrement avec une clef partagée par Ivan et Alice ea Eg chiffrement avec une clef partagée par Ivan et Bernard I un numéro d’ordre ° K une clef de session aléatoire L une longévité des datations Ta ,Tb des nombres aléatoires choisis par Alice et Bernard respectivement Il a ; l ig
T a b . 3.1
A B
“ Note du traducteur: ce num éro perm et différencier les différentes utilisations d ’un mêm e protocole.
« Wide-Mouth Frog » Le. protocole « Wide-Mouth Frog » [287, 288] est probablement le protocole de gestion de clefs secrètes le plus simple qui utilise un serveur en qui l’on a confiance. Alice et Bernard partagent chacun une clef secrète avec Ivan. Ces clefs ont elles-mêmes été distribuées secrètement et avec garantie d ’authenticité par un autre canal externe dont
Chapitre S
62
Protocoles élémentaires
nous admettrons qu’il est sûr. Ces clefs sont seulement utilisées pour la distribution des clefs et non pas pour chiffrer des messages entre utilisateurs. Rien qu’en utilisant deux messages, une clef de session est transférée d ’Alice à Bernard : 1° Alice combine la datation, le nom de Bernard, B et une clef de session aléatoire et chiffre le tout avec la clef secrète qu ’elle partage avec Ivan. Elle envoie le résultat chiffré à Ivan avec son nom. A , E a (Ta , B, K)
2° Ivan déchiffre le message d’Alice. Ivan combine une nouvelle datation, le nom, d’Alice, et la clef de session aléatoire. Il chiffre le tout avec la clef secrètequ’il partage avec Bernard. Ivan envoie le résultat chiffré à Bernard. E B(TB, A , K )
L’hypothèse la plus risquée faite par ce protocole est qu’Alice est suffisamment com pétente pour engendrer des clefs de session valables. Rappelez-vous qu’il n’est pas aisé d’engendrer des nombres aléatoires ; le protocole fait peut-être trop confiance à Alice à ce propos.
Yahalom L’auteur de ce protocole est Y a h a l o m [187]. Comme dans le protocole précédent, Alice et Bernard partagent une clef secrète avec Ivan [287, 288]. 1° Alice combine son nom avec un nombre aléatoire et envoie le tout à
Bernard:
A, R a
2° Bernard combine le nom d ’Alice, le nombre aléatoire d’Alice, un autre nombre aléatoire et chiffre le tout avec la clef secrète qu ’il partage avec Ivan. Il envoie ceci à Ivan avec son nom : B , E b (A,R a ,R b )
3° Ivan engendre deux messages. Le premier est constitué du nom de Bernard, une clef de session aléatoire pour Alice et Bernard, le nombre aléatoire d’Alice et le nombre aléatoire de Bernard; le tout étant chiffré avec la clef secrète qu'il partage avec Alice. Le deuxième est constitué du nom d’Alice et de la clef de session aléatoire; le tout étant chiffré avec la clef secrète qu’il partage avec Bernard. Il envoie les deux messages chiffrés à Alice : E a ( B , K , R a ,R b ),E b (A, K)
4° Alice déchiffre le message chiffré avec sa clef secrète, extrait K , et confirme que R a a la même valeur qu’à l’étape 1. Alice envoie à Bernard deux messages. Le premier est le message qu’elle a reçu d’Ivan, chiffré avec la clef de Bernard. Le deuxième est R B, chiffré avec la clef de session: E b ( A , K) , E k (R b )
3.3
Authentification et échange de clefs
63
5° Bernard déchiffre le message chiffré avec sa clef, extrait K et confirme que R b est le même que celui de l’étape 2.
Finalement, Alice et Bernard sont convaincus qu’ils se parlent bien l’un à l’autre et non pas à un tiers. La nouveauté ici c ’est que Bernard est le premier à contacter Ivan qui n’envoie qu’un seul message à Alice.
Needham et Schroeder Ce protocole, inventé par Roger N e e d h a m et Michael S c h r o e d e r [1159], utilise aussi la cryptographie à clef secrète et Ivan.
1° Alice envoie un message à Ivan constitué de son nom, du nom de Bernard, et d’une valeur aléatoire:
(A , B , R a ) 2° Ivan chiffre, avec la clef secrète qu ’il partage avec Bernard, un message consti tué d’une clef de session aléatoire et du nom d’Alice. Ensuite, il chiffre, avec la clef secrète qu ’il partage avec Alice, un message constitué de la valeur aléatoire d’Alice, du nom de Bernard, de la clef de session et du message chiffré avec la clef secrète qu’il partage avec Alice. Finalement, il envoie à Alice le message chiffré : E a (Ra , B , K , E b (K,A))
3° Alice déchiffre le message et extrait K . Elle confirme que R a est bien la même valeur qu’elle a envoyée à Ivan à l’étape 1. Ensuite, elle envoie à Bernard le message qu ’lvan a chiffré avec la clef de Bernard : E b (K,A)
4° Bernard déchiffre le message et extrait K . Il engendre alors un autre nombre aléatoire. Il chiffre ce nombre avec K et envoie le résultat à Alice: E k {Bb )
5° Alice déchiffre le message avec K . Elle engendre R b — 1 et le chiffre avec K . Elle envoie le résultat à Bernard: E k {Rb — 1
)
6° Bernard déchiffre le message avec K et vérifie qu’il s ’agit bien de R b ~ 1. Toutes ces allées et venues avec Ra , R b et R b —1 garantissent qu’il n’y a pas d’attaque où les messages sont rejoués. La présence de R a à l’étape 3 confirme à Alice que le message d’Ivan est légitime et non pas une répétition d ’une réponse à une exécution antérieure du protocole. Quand Aüce déchiffre R b avec succès et qu’elle envoie R b — 1 chiffré à Bernard à l’étape 5, celui-ci est assuré que les messages d ’Alice ne sont pas des répétitions de messages d’exécutions antérieures du protocole. Le plus grand problème de sécurité avec ce protocole est que les vieilles clefs de session ont de la valeur. Si Martin parvient à obtenir une ancienne clef de session K , il peut
Chapitre S
64
Protocoles élémentaires
monter l’attaque suivante avec succès [467]. Tout ce qu’il doit faire c ’est enregistrer les messages d ’Alice à Bernard pendant l’étape 3. Alors, une fois qu’il a K , il peut prétendre être Alice : 1° Martin envoie à Bernard, le message suivant : E
b
(K ,A )
2° Bernard extrait K , engendre R b et envoie à celle qu’il croit être Alice: E k (R b )
3° Martin intercepte le message, le déchiffre avec K et envoie à Bernard : E k {R b - 1)
4° Bernard vérifie que le message prétendument d’Alice est Rb — 1. Maintenant, Martin a convaincu Bernard qu’il est Alice. Un protocole avec datation peut faire échouer cette attaque [467, 462]. Une datation est ajoutée au message d ’Ivan chiffré à l’étape 2 avec la clef de Bernard: E B(K,A,T). Pour les datations, une horloge système sûre et précise est nécessaire, ce qui n’est pas trivial en soit à réaliser. Les conséquences sont dramatiques si la clef secrète partagée entre Alice et Ivan vient à être compromise. Martin peut l’utiliser pour obtenir des clefs de session pour dialoguer avec Bernard (ou toute autre personne avec qui il veut converser). Pis encore, Martin peut continuer à faire cela même si Alice change sa clef [96]. N e e d h a m et S c h r o e d e r ont essayé de corriger leur protocole pour faire face à ces at taques [1160]. Leur nouveau protocole est essentiellement le m êm e que celui d ’ OTWAYR e e s publié dans le même numéro du même journal.
Otway-Rees Ce protocole utilise aussi la cryptographie à clef secrète [1234]. 1° Alice engendre un message constitué d’un numéro d ’ordre, de son nom, du nom de Bernard, et d’un nombre aléatoire, le tout chiffré avec la clef secrète qu’elle partage avec Ivan. Elle envoie le message chiffré à Bernard avec le numéro d ’ordre, son nom à elle et son nom à lui: I , A , B , E a (R a ,I,A,B) 2° Bernard engendre un message constitué d’un nouveau nombre aléatoire, du numéro d’ordre, du nom d’Alice et celui de Bernard, le tout chiffré avec la clef secrète qu’il partage avec Ivan. Il envoie le message chiffré résultant à Ivan avec le message chiffré qu’il a reçu d’Alice, le numéro d’ordre, son nom à elle et son nom à lui: I,A ,B ,E a {R a ,I,A ,B ),E b {R b ,I,A,B)
3.3
65
Authentification et échange de clefs
3° Ivan engendre une clef de session aléatoire. Il crée alors deux messages. L ’un est composé du nombre aléatoire d’Alice et de la clef de session, et est chiffré avec la clef qu ’il partage avec Alice. L ’autre est composé du nombre aléatoire de Bernard et de la clef de session, et est chiffré avec la clef qu’il partage avec Bernard. Il envoie les deux messages avec le numéro d’ordre à Bernard: I , E a (RA jK ) , E b (R b , K )
4° Bernard envoie à Alice le message chiffré avec la clef d’Alice et avec le numéro d’ordre: I , E a {R a , K)
En émettant l’hypothèse que tous les nombres aléatoires sont corrects et que le numéro d’ordre n’a pas changé en cours de route, Alice et Bernard sont maintenant convaincus de leurs identités respectives et ils ont une clef secrète avec laquelle communiquer.
Kerberos K e r b e r o s est une variante du protocole de Needham et Schroeder, il est présenté en détail dans le paragraphe 17.4. Dans le protocole de base K e r b e r o s version 5, Alice et Bernard partagent chacun des clefs avec Ivan. Alice veut engendrer une clef de session pour dialoguer avec Bernard.
1° Alice envoie un message à Ivan avec son identité et celle de Bernard: A ,B
2° Ivan engendre un message avec la datation, une longévité, une clef de ses sion aléatoire, et l’identité d’Alice. Il chiffre cela avec la clef qu’il partage avec Bernard. Ensuite il engendre un autre message avec la datation, la longévité, la clef de session et l’identité de Bernard, et il chiffre le résultat avec la clef qu’il partage avec Alice. Il envoie les deux messages chiffrés à Alice: E a ( T, L,K,B) ,E b (T,L,K,A)
3° Alice engendre un message avec son identité et la datation, chiffre cela avec K et envoie le résultat à Bernard. Alice envoie aussi à Bernard le message qu ’elle a reçu d’Ivan, chiffré avec la clef de Bernard : E k (T,A),E b (T,L,K,A)
4° Bernard engendre un message avec la datation plus un, le chiffre avec K et envoie le résultat à Alice : E k (T + 1)
Le protocole marche mais il présume que toutes les horloges sont synchronisées avec l’horloge d’Ivan. En pratique, cet effet est obtenu en synchronisant les horloges à quelques minutes près d ’une horloge de référence et en détectant les répétitions dans l’intervalle de temps donné.
Chapitre 3
66
Protocoles élémentaires
Neuman-St ubblebine Que ce soit par des erreurs de système ou par sabotage, il se peut que les horloges se désynchronisent, Si cela arrive, il existe une attaque possible contre la plupart de ces protocoles [646]. Si l’horloge de l’expéditeur est en avance, Martin peut intercepter un message de l’expéditeur et le rejouer plus tard quand la datation devient à jour sur le site du destinataire. Cette attaque peut avoir des conséquence désagréables. Ce protocole présenté pour la première fois dans [821] et corrigé dans [1162] tente de contrer cette attaque. C ’est une amélioration du protocole Yalahom qui en fait un excellent protocole. 1° Alice engendre un message avec son nom, un nombre alâtoire et l’envoie à Bernard. A, R a
2° Bernard chiffre le nom d’Alice, le nombre aléatoire, et la datation avec la clef qu ’il partage avec Ivan. Il envoie le résultat, son nom et un autre nombre aléa toire à Ivan. B , R b ,E b (A,R a ,Tb )
3° Ivan engendre une clef de session aléatoire et crée alors deux messages. Le premier est constitué du nom de Bernard, du nombre aléatoire d ’Alice, de la clef de session, et de la datation, le tout chiffré avec la clef qu'il partage avec Alice. Le second se compose du nom d ’Alice, de la clef de session, et de la datation, le tout chiffré avec la clef qu ’il partage avec Bernard. U envoie les deux messages à Alice avec le nombre aléatoire de Bernard. E a (B, R a ,K,T b ),E b (A,K,T b ),R b
4° Alice déchiffre le message chiffré avec sa clef, extrait K , et vérifie que R a est bien le même quà l’étape 1. Alice envoie deux messages à Bernard. Le premier est celui qu’elle a reçu de Ivan et qui est chiffré avec la clef de Bernard. Le second est R b , chiffré avec la clef de session. E b (B, K, T b ),E k (Rb )
5° Bernard déchiffre le message chiffré avec sa clef, extrait K , et vérifie que TB et R b ont la même valeur qu’à l’étape 2.
Si les nombres aléatoires et les datations correspondent, Alice et Bernard sont convain cus de l’identité de l’un l’autre et ils partagent une clef secrète. Il n ’est pas nécessaire que les horloges soient synchronisées car les datations proviennent toutes de l’horloge de Bernard ; il vérifie uniquement des datations qu’il a engendrées lui-même. Ce protocole présente un autre avantage: Alice peut utiliser le message qu’elle a reçu de Ivan pour d ’autres authentifications avec Bernard jusqu’à une certaine limite de temps fixée à l’avance. Supposons que Bernard et Alice ont terminé le protocole ci-dessus et ont fini de communiquer. Alice et Bernard sont en mesure de mener une nouvelle authentification en trois étapes, sans l’aide de Ivan. 1° Alice envoie à Bernard le message que Ivan lui avait envoyé à l’étape 3 et un nouveau nombre aléatoire. E b (A,K,T b ),R’a
3.3
Authentification et échange de clefs
67
2° Bernard envoie à Alice un autre nouveau nombre aléatoire, et le nouveau nombre aléatoire d’Alice chiffré avec leur clef de session. R'B,E K (R'A)
3° Alice envoie à Bernard son nouveau nombre aléatoire chiffré avec leur clef de session. E k (R'b )
Les nouveaux nombres aléatoires empêchent toute attaque consistant à rejouer de vieux messages.
DASS Les protocoles DASS, développés par D i g it a l E q u i p m e n t C o r p o r a t i o n , per mettent aussi l’authentification mutuelle et l’échange de clefs [606, 1523, 1522]. Contrairement aux autres protocoles, DASS utilise à la fois la cryptographie à clef secrète et la cryptographie à clef publique. Alice et Bernard ont chacun une clef privée. Ivan possède des copies signées de ces clefs privées. 1° Alice envoie à Ivan un message constitué du nom de Bernard. B
2° Ivan envoie à Alice la clef publique de Bernard, K b , signée avec la clef privée d’Ivan, T . Le message signé comprend le nom de Bernard. St ( B , K b )
3° Alice vérifie la signature d’Ivan pour confirmer que la clef qu’elle a reçue est bien la clef publique de Bernard. Elle engendre une clef secrète aléatoire, et une paire aléatoire « clef publique, clef privée » : Kp. Elle chiffre une datation avec K . Elle signe une longévité de clef, L, son identification, A , et K p avec sa clef privée, K A. Enfin, elle chiffre K avec la clef publique de Bernard et signe le résultat avec K p. Elle envoie le tout à Bernard: E k (Ta ),SKa ( L, A, K p),Sk p (EKb ( K ))
4° Bernard envoie à Ivan (ce peut être un autre Ivan) un message contenant le nom d’Alice: A
5° Ivan envoie la clef publique d’Alice à Bernard, signée avec la clef publique d’Ivan : St ( K a )
6° Bernard vérifie la signature d ’lvan pour confirmer que la clef qu ’il a reçue est bien la clef publique d’Alice. Il vérifie alors la signature d’Alice et récupère K p. Il vérifie la signature et utilise sa clef privée pour retrouver K . Ensuite, il déchiffre TA pour être sûr que le message n’est pas périmé.
Chapitre 3
68
Protocoles élémentaires
7° Si Vauthentification mutuelle est nécessaire, Bernard, chiffre une nouvelle da tation avec K et envoie le résultat à Alice. E k (Tb )
8° Alice déchiffre Tb avec K pour être sûre que le message n’est pas périmé. D E C a réalisé les protocoles DASS. Vous trouverez plus d ’informations dans [35].
Denning-Sacco Ce protocole utilise aussi la cryptographie à clef publique [467]. Ivan conserve une base de donnée contenant toutes les clefs publiques. 1° Alice envoie un message à Ivan avec son nom et celui de Bernard: A ,B
2° Ivan envoie à Alice la clef publique de Bernard, K b , qu’il signe avec sa propre clef privée, T. Ivan envoie aussi à Alice la clef publique de celle-ci, K a , qu’il signe avec sa clef privée. St ( B , K b ),St ( A, K a )
3° Alice envoie à Bernard une clef de session aléatoire et une datation signés avec sa clef privée et chiffrés avec la clef publique de Bernard, le tout accompagné des deux clefs publiques signées. E b (Sa (K,T a )),St { B , K b ),St ( A , K a) 4° Bernard déchiffre le message d’Alice avec sa clef privée et vérifie la signature d’Alice avec la clef publique de celle-ci. Pour plus de sûreté, il vérifie que la datation est toujours valide.
À ce niveau, Alice et Bernard ont tous les deux la clef K , et peuvent communiquer en sécurité. Cela a l’air de fonctionner mais il n’en est rien. Après avoir terminer le protocole avec Alice, Bernard peut se faire passer pour Alice [9]: 1° Bernard envoie à Ivan son nom et celui de Christine . B ,C
2° Ivan envoie à Bernard les clefs publiques de Bernard et Christine qu ’il signe. St ( B , K b ),St (C, Kc )
3° Bernard envoie à Christine la clef de session et la datation qu’il a reçus d’Alice après les avoir chiffrés avec la clef publique de Christine, le tout accompagné des certificats d’Alice et de Christine. E c (Sa (K,T a )),St ( C, K c ),St ( A , K a)
3.3
69
Authentification et échange de clefs
4° Christine déchiffre le message d’« Alice » avec sa clef privée et contrôle la signature d’Alice avec la clef de celle-ci. Elle vérifie que la datation est toujours valide.
Christine croit maintenant parler avec Alice; Bernard l’a trompée avec succès. En fait, Bernard peut tromper n’importe quel membre du réseau jusqu’à ce que la datation expire. Ce problème est facile à régler. Il suffit d ’ajouter les noms dans le message chiffré à l’étape 3: E b {Sa {A, B, K, T a )),St { B , K b ),St { A , Ka )
Maintenant Bernard ne peut plus réutiliser le vieux message d ’Alice avec Christine parce qu’il est clairement dédié à la communication entre Alice et Bernard.
Woo-Lam Ce protocole utilise encore la cryptographie à clef publique [1612, 1613]: 1° Alice envoie à Ivan un message contenant son nom et celui de Bernard. A ,B
2° Ivan envoie à Alice la clef publique de Bernard qu’il signe avec sa propre clef privée. St ( K b )
3° Alice vérifie la signature de Ivan. Elle envoie alors à Bernard son nom et un nombre aléatoire, qu’elle chiffre avec la clef publique de Bernard. E k b ( A, R a )
4° Bernard envoie à Ivan son nom, celui d’Alice et le nombre aléatoire d’Alice qu’il chiffre avec la clef publique de Ivan. A , B , E k t {Ra )
5° Ivan envoie à Bernard la clef publique d’Alice qu’il signe avec sa propre clef privée. Il lui envoie aussi le nombre aléatoire d’Alice, une clef de session aléa toire, le nom d’Alice, le nom de Bernard, le tout signé avec la clef privée de Ivan et chiffré avec la clef publique de Bernard. S t ( K a ),EKb (St (Ra ,K, A, B))
6° Bernard contrôle la signature de Ivan. Il envoie alors à Alice la deuxième partie du message que Ivan lui a envoyé à l’étape 5 et un autre nombre aléatoire, le tout chiffré avec la clef publique d’Alice. E Ka (St (Ra , K, A, B) , Rb ) 7° Alice vérifie la signature de Ivan et son nombre aléatoire. Elle envoie alors à Bernard le second nombre aléatoire qu’elle chiffre avec la clef de session. E k (R b )
8° Bernard déchiffre son nombre aléatoire et vérifie qu’il n’a pas changé.
Chapitre 3
70
Protocoles élémentaires
Autres protocoles X .509 sont 24.9. Le protocole K r y p t o K n ig h t est décrit dans le pa ragraphe 24.6. Le protocole: « Echange de Clef Chiffré » 3, est décrit dans le para graphe 22.5. Il y a beaucoup d ’ autres protocoles dans la littérature. Les protocoles
décrits dans le paragraphe
K u p e r e e [695] est un autre protocole à clef publique. D ’autres protocoles à l’étude utilisent
beacons, un noeud du réseau en qui l’on a confiance et qui émet en continu
des nombre aléatoires authentifiés [783].
Les leçons Il faut tirer quelques leçons importantes des protocoles précédents, à la fois de ceux qui ont étés cassés et de ceux qui ne l’on pas été: - Beaucoup de protocoles échouent parce que leurs concepteurs essayent d’être trop intelligents. Ils optimisent leurs protocoles en laissant de côté des points importants: les noms, des nombres aléatoires, et ainsi de suite. Le remède est de tout rendre explicite [44, 45]. - On a vite fait de s’embrouiller en essayant d’optimiser, cela dépend beaucoup des hypothèses que l’on fait. Par exemple, si l’on dispose de datations sûres, on peut faire beaucoup de choses impossibles sans cela. Le choix du protocole dépend de l’architecture du réseau utilisé pour les commu nications. Voulez-vous minimiser la taille des messages ou leur nombre? Est-ce que tous les partis peuvent se parler les uns les autres ou seulement quelques uns d’entre eux. De telles questions permettent de développer des méthodes formelles pour l’analyse des protocoles.
3.4
Analyse formelle des protocoles d’au thentification et d’échange de clefs
Le problème d ’obtenir une clef de session sûre entre deux ordinateurs (et deux per sonnes) est si important qu’il a mené à de nombreuses recherches. Une part des re cherches a été dévouée au développement de protocoles tels que ceux examinés dans les paragraphes 3.1, 3.2, et 3.3. Ceci a conduit à de plus amples et plus intéressants problèmes: l’analyse formelle des protocoles d’authentification et d ’échange de clefs. On a trouvé des failles dans certains protocoles apparament sûrs des années après qu’ils furent proposés et les chercheurs voulaient des outils permettant de prouver la sécurité d ’un protocole dès le début. Bien que la plupart de ce travail puisse s’appliquer aux pro tocoles cryptographiques en général, l’emphase en recherche concerne principalement l’authentification et l’échange de clefs. 3. E n c r y p te d K e y E x ch a n g e.
3-4
Analyse formelle des protocoles d’authentification et d’échange de clefs
71
Il y a quatre approches fondamentales de l’analyse de protocoles cryptographiques [1053] : 1. Modéliser et vérifier le protocole en utilisant des languages de spécification et des outils de vérification qui ne sont pas spécifiquement dédiés à l’analyse de protocoles cryptographiques. 2. Développer des systèmes experts avec lequel un concepteur de protocoles peut inventer et tester différents scénarios. 3. Modéliser les nécéssités d’une famille de protocoles à l’aide de régies logiques sur l’anlyse de savoir et de croyance. 4. Développer une méthode formelle basée sur les propriétés de réécriture de termes algébriques dans les sytèmes cryptographiques. Une discussion complète de ces quatres approches et des recherches qui tournent autour dépasse largement le sujet de ce livre. Voir [1055, 1357] pour une bonne introduction; nous allons juste toucher du bout des doigts les avancées majeures dans le domaine. La première approche traite un protocole cryptographique comme n’importe quel autre programme et s’occuppe de prouver son exactitude. Certains chercheurs présentent un protocole comme une machine à état fini [1455, 1357], d’autres utilisent des exten sions du calcul des prédicats du premier ordre [823], et d ’autres encore analysent les protocoles à l’aide de languages de spécification [1568]. Toutefois, ce n’est pas pareil de prouver l’exactitude que de prouver la sécurité et cette approche ne permet pas de détecter de nombreux protocoles défectueux. Bien qu’elle fût largement étudiée en premier lieu, la plupart des travaux dans le domaine ont étés redirigés alors que la troisième approche gagnait en popularité. La deuxième approche utilise des systèmes experts pour déterminer si le protocole peut atteindre un état indésirable (comme la divulgation d ’une clef par exemple). Si cette approche est plus apte à détecter les failles, elle ne garantie pas la sécurité et ne fournit pas non plus de technique pour découvrir des attaques. C ’est efficace pour déterminer si un protocole a une faille donnée mais pas pour trouver une faille inconnue dans un protocole. On trouvera des exemples d’une telle approche dans [997, 1525]; un système à base de règles développé par l’armée américaine qui s’appelle l’ « Interrogateur4 » est examiné dans [1098]. La troisième approche est de loin la plus populaire, elle fut lancée par Michael B u r r o w s , Martin A b a d i et Roger N e e d h a m . Ils ont développé un modèle de logique formelle pour l’analyse de savoir et de croyance appelé la logiqu e B A N [287, 288]. BAN est la logique la plus utilisée pour analyser les protocoles d’authentification. Elle repose sur l’hypothèse que l’authentification est une fonction dépendant de l’intégrité et de la fraîcheur, et elle permet de suivre la valeur de ces deux attributs au cours du protocole au moyen de règles logiques. Malgrès le développement de beaucoup de variantes et d ’extensions, la plupart des concepteurs de protocoles se réfèrent encore aux premiers travaux. La logique BAN ne permet pas de prouver la sécurité; elle permet seulement de rai sonner sur l’authentification. Cette logique est simple et immédiate, facile à appliquer 4. L’« I n te r ro g a to r » en anglais.
72
Chapitre 3
Protocoles élémentaires
et pourtant utile pour détecter des failles. Certaines formulations de la logique BAN ressemblent à ceci: Alice croit A . (Alice agit comme si X était vrai.) Alice voit X . (Quelqu’un a envoyé à Alice un message contenant X . Celle-ci peut le lire et l’envoyer à nouveau — après un éventuel déchiffre ment.) Alice a dit X . (À un moment donné, Alice a envoyé un message conte nant X . On ne sait pas quand il a été envoyé ou même s’il a été envoyé durant le protocole en cours. On sait seulement que Alice croyait X quand elle l’a dit.) X est récent (ou frais). (A n’a jamais été envoyé dans un message à quelqu’instant que ce soit avant le protocole en cours.) Et ainsi de suite. La logique B A N fournit aussi des règles pour raisonner sur des croyances à l’intérieur d’un protocole. En appliquant ces règles aux formulations lo giques concernant le protocole, on peut prouver certaines choses ou répondre à certaines questions à propos du protocole. Par exemple, une des règles est celle de la signification d’un message: Si Alice croit qu’elle et Bernard partagent une clef secrète K et si Alice voit X chiffré avec K , et si Alice n’a pas chiffré X avec K , alors Alice croit que Bernard a dit X .
Une autre règle est celle de la vérification de nombre aléatoire Si Alice croit que X n’a pu être prononcé que récemment et que Bernard a dit A , alors Alice croit que Bernard croit A .
Il y a quatre étapes dans une analyse avec BAN : 1. Décrire le protocole dans une forme idéalisée à l’aide de formulations logiques telles que les précédentes. 2.
Ajouter toutes les hypothèses concernant l’état initial du protocol.
3.
Insérer des formules logiques inhérentes aux formulations: des assertions à propos de l’état du système après chaque formulation.
4.
Applliquer les règles logiques aux assertions et aux hypothèses pour trouver les croyances de chaque parti au cours du protocole.
Les auteur de la logique B A N « voient les protocoles idéalisés comme des spécifications plus claires et plus complètes que les descriptions traditionnelles de la littérature... » [287, 288]. D ’autres ne se laissent pas impressionner et critiquent cette étape car elle pourrait dénaturer le protocole réel [1161, 1614], Voir [225, 1563] pour une poursuite du débat. D ’autres détracteurs essayent de montrer que la logique BAN peut conduire pour certains protocoles à des caractéristiques clairement fausses [1161] — voir [289, 1513] pour une réfutation — et que la logique BA N concerne seulement la confiance et pas la sécurité [1513]. De plus amples débats se trouvent dans [1495, 707, 1011],
3-4
Analyse formelle des protocoles d’authentification et d’échange de clefs
73
Malgrès ces critiques, la logique B A N est un succès. Elle a contribué à trouver des failles dans différents protocoles dont N E E D H A M -S C H R O E D E R et une première version d’un protocole C C IT T X .509 [308]. Elle a permis de montrer des redondances dans beau coup de protocoles comme Y a h a l o m , N e e d h a m - S c h r o e d e r , et K e r b e r o s . Bien des articles publiés font état de la sécurité de leurs protocoles grâce à la logique BAN [41, 1162, 80]. D’autres systèmes de logique ont étés publiés, certains sont des extensions de la logique BAN [647, 588,1562, 829], et les autres sont basés sur B A N pour palier à des faiblesses connues [1495, 1011]. La plus prisée parmi celles-là est G N Y [647] bien qu’elle présente certains défauts [41]. Des probabilités de croyance ont été ajoutées à la logique B A N avec un succès mitigé [296, 507]. D ’autres logiques formelles sont proposées dans [163, 799, 292]; dans [1518], les auteurs essayent de combiner les aspects de plusieurs logiques. Enfin, il existe des logiques où les croyances peuvent changer avec le temps [1130, 1515]. Avec quatrième approche à l’analyse des protocoles cryptographiques, on modélise le protocole par un système algébrique, on exprime l’état de connaissance des participants en ce qui concerne le protocole, et on analyse alors s’il est possible d’ateindre certains états. Cette approche n’a pas connu autant d ’égards que les logiques formelles, mais ça ne saurait tarder. Michael M e r r i t t l’a utilisée le premier en montrant qu’un modèle algébrique permet d’analyser les protocoles cryptographiques. On trouvera d’autres approches dans [506, 1512, 1538, 1539, 1540, 1514, 1614], L’Analyseur de Protocoles des laboratoires de recherche de la marine américaine5 est probablement l’application la plus réussie de ces techniques [1516, 824, 1054, 1517]; il a mis en évidence de nouvelles failles et d ’autre déjà connues dans quelques protocoles [1052, 1053, 1055]. L 'Analyseur de Protocoles utilise des définitions d ’actions du type: - Accepter (Bernard, Alice, A i, N ). (Bernard accepte le message A i comme prove nant d ’Alice durant la manche N de Bernard.) - Apprendre(Estelle,A4). (Estelle apprend A4.) - Envoyer(Alice, Bernard, Q, A i). (Alice envoie A4 à Bernard en réponse à la requête Q.) Request(Bernard, Alice, Q, N ). (Bernard envoie Q à Alice durant la manche N de Bernard.) A parjjr de ces actions, on peut spécifier des exigences. Par exemple: - Si Bernard a accepté un message A4 de la part d ’Alice à un moment donné, alors Estelle n ’a appris A4 à aucun moment. - Si Bernard a accepté un message A4 de la part d ’Alice dans la manche N de Bernard, alors Alice a envoyé A4 à Bernard en réponse à une requête survenue durant la manche N de Bernard. Pour utiliser l’ Analyseur de Protocoles, le protocole doit être spécifier avec les construc teurs précédents. On distingue alors quatre phases dans l’analyse: la définition des règles de transition pour les participants honêtes, la description des opérations acces sibles à tous les participants (honêtes ou malhonêtes), la description des blocs de base 5. N a vy R esea rch L a b o ra to ry (N R L ).
Chapitre 3
74
Protocoles élémentaires
constituant le protocole, et la description des exigences. Le but de tout ceci est de montrer qu’un protocole donné remplit ses exigences. Les outils comme YAnalyseur de Protocoles pourrait éventuellement conduire à des protocoles dont la sécurité serait prouvée. Alors que le gros du travail dans les méthodes formelles vise à appliquer les dites méthodes à des protocoles existants, d’autres travaux tendent à utiliser les méthodes formelles pour concevoir le protocole dès le départ. Les premiers pas dans cette direction sont dans [713]. L 'Analyseur de Protocoles tente aussi d ’accomplir cela [1516, 224, 1517]. L’application de méthodes formelles aux protocoles cryptographiques reste une idée assez nouvelle et il est vraiment difficile de savoir où elle mène. Pour l’instant, le point sensible semble résider dans le processus de formalisation.
3.5
Cryptographie à clef publique à clefs multiples
Pour la cryptographie à clef publique, il y a deux clefs. Un message est chiffré avec l’une et déchiffré avec l’autre. En général, l’une des clefs est privée et l’autre est publique. Toutefois, faisons maintenant l’hypothèse qu’Alice a une clef et Bernard l’autre. Alice peut chiffrer un message que seul Bernard pourra déchiffrer et Bernard peut chiffrer un message que seule Alice pourra lire. Ce concept a été généralisé par Colin B o y d [220]. Imaginez une variante de la crypto graphie à clef publique avec trois clefs: K a , K b , K c , distribuées comme indiqué dans le tableau 3.2. T a b . 3 .2
- Clefs en possession de chacun des participants
Participant : Alice Bernard Christine David Etienne Francis
Clef(s) en sa possession : Ka Kb Kc K a et K b K b et K c K a et K c
Alice peut chiffrer un message avec K a de manière qu’Étienne qui dispose de K b et de K c puisse le déchiffrer, de même que Bernard et Christine s’ils se mettent ensemble. Bernard peut chiffrer un message afin que Francis puisse le lire et Christine peut chiffrer un message de façon que David puisse le lire. David peut chiffrer un message avec K a de manière qu’Etienne puisse le lire, avec K b de manière que Francis puisse le lire, ou encore avec K a et K b de manière que Christine puisse le lire. De même, Etienne peut chiffrer un message de telle manière qu’Alice, David ou Francis puissent le lire. Les différentes possibilités sont résumées par le tableau 3 .3 et il n’y en a pas d’ autres. Ce schéma peut être étendu à n clefs. Si un sous-ensemble de ces clefs est utilisé pour chiffrer le message, le complément de celui-ci (les clefs non utilisées pour le chiffrement)
3.6
Secret morcelé
75
T a b . 3 .3
- Chiffrement à trois clefs
Chiffré avec les clefs : Ka Kb Kc K a et K b K a et K c K b et K c
Doit être déchiffré avec les clefs : K b et K c K a et K c K a et K b KC Kb Ka
est nécessaire pour déchiffrer le message.
Diffusion de message Imaginez que vous ayez cent opérateurs sur le terrain. Vous voulez envoyer des messages à certains sous-ensembles de vos opérateurs mais vous ne connaissez pas à l’avance la composition des sous-ensembles. Vous pouvez chiffrer le message séparément pour chaque destinataire, ou créer des clefs pour chaque combinaison possible. La première option augmente considérablement le trafic des communications ; la deuxième nécessite un très grand nombre de clefs. La cryptographie à clefs multiples est nettement plus facile. Considérons trois opéra teurs: Alice, Bernard et Christine. Vous donnez à Alice K a et K b , à Bernard K b et K c , et à Christine K a et K c - Ainsi, vous pouvez dialoguer avec n’importe quel sousensemble d’entre eux. Si vous voulez envoyer un message que seule Aüce puisse lire, chiffrez-le avec K c - Quand elle reçoit le message, elle le déchiffre avec K a et puis K r . Si vous voulez envoyer un message que seul Bernard puisse lire, chiffrez-le avec K a - Si vous voulez envoyer un message que seule Christine puisse lire, chiffrez-le avec K b - Si vous voulez envoyer un message qu’Alice et Bernard puissent lire, chiffrez-le avec K a et K c , et ainsi de suite. Cela peut paraître peu excitant, mais avec 100 opérateurs, ce schéma est pour le moins efficace. Envoyer des messages individuels nécessite de partager une clef avec chaque opérateur (100 clefs au total). Pour couvrir tous les sous-ensembles possibles, il faut 2100 — 2 clefs (on exclus les messages destinés à tous les opérateurs et à aucun). Le schéma qui vient d ’être décrit marche avec un seul texte chiffré et 100 clefs différentes. Le seul inconvénient est qu’il faut aussi diffuser le sous-ensemble d’opérateurs auquel ce message est destiné; sans cela, chaque opérateur devrait essayer toutes les combinaisons de clefs possibles à la recherche de la bonne. Les nom des destinataires suffisent. Dans la réalisation directe de ceci, chacun reçoit une quantité massive de données relatives aux clefs. Il y a d’autres techniques pour la diffusion de messages, certaines ne présentent pas le problème précédent. Elles sont décrites dans le paragraphe 22.7.
3.6
Secret morcelé
Imaginer que vous ayez inventé une nouvelle crème de garniture super-collante et super sucrée. Peut-être avez vous fait une sauce pour hamburger encore plus insipide que
Chapitre 3
16
Protocoles élémentaires
celle de vos concurrents. C ’est important, vous devez garder le secret. Vous ne pouvez indiquer la composition exacte des ingrédients qu’à vos employés en qui vous avez le plus confiance: mais qu’arrive-t-il si l’un d ’entre eux vous quitte pour aller à la concurrence? Le secret est dévoilé et il ne faudra pas attendre longtemps avant que tous les marchands de « fastfood » du quartier ne fassent des hamburgers aussi insipides que les vôtres. Pour remédier à cela, on fera appel au secret m orcelé. Il y a moyen de prendre un message et de le couper en morceaux [553]. Chaque morceau en lui-même n’a aucune signification mais si vous les rassemblez vous pouvez faire la sauce. Si un employé vous quitte avec un morceau de la recette, cette information est inutilisable par elle-même. Le morcellement de secret le plus simple partage un message entre deux personnes. Voici un protocole où Ivan partage un message entre Alice et Bernard. 1° Ivan engendre une chaîne aléatoire de bits, R, ayant la même longueur que le message A i.
2° Ivan combine A i avec R par ou exclusif pour obtenir S. A4 ® R = S
3° Ivan donne R à Alice et S à Bernard. Pour reconstruire le message, Alice et Bernard n’ont qu’une étape à effectuer : 4° Alice et Bernard combinent leurs morceaux par ou exclusif pour reconstruire le message : R ® S = A4
Cette technique, pour autant que tout soit fait correctement, est absolument sûre. Chaque élément est en lui-même sans valeur. Essentiellement, Ivan chiffre le message avec un masque jetable. Il donne ensuite le masque à une personne et le message chiffré à l’autre. Le paragraphe 1.5 explique la technique du masque jetable; ce système de chiffrement est absolument sûr. Aucune puissance de calcul ne permet de retrouver le message avec un seul morceau. Il est aisé d ’étendre ce schéma à plusieurs personnes. Pour morceler un message entre plus de deux personnes, on combine d’autres chaînes aléatoires de bits avec le message Dans l’exemple qui suit, Ivan partage le message en quatre morceaux : 1° Ivan engendre trois chaînes aléatoires de bits, R, S et T , ayant chacune la même longueur que le message A i.
2° Ivan combine par ou exclusif A i avec les trois chaînes : AA@R®S®T = U
3° Ivan donne R à Alice, S à Bernard, T à Christine et U à David. Et voici comment Alice, Bernard, Christine et David reconstruisent le message : 4° Alice, Bernard, Christine et David se mettent ensemble pour calculer: R @ S < $ > T ® U = A4
3.7
Secret réparti
77
C’est un protocole à juge-arbitre. Ivan a tous les pouvoirs et il peut faire ce qu’il veut. Il peut donner du charabia et prétendre que ce sont les bons éléments du secret ; personne ne le saura jusqu’à ce qu’ils essaient de reconstruire le secret. Il peut donner un morceau à Alice, Bernard, Christine et David, puis dire à tout le monde que seuls Alice, Christine et David sont nécessaires pour reconstruire le secret. Il peut alors licencier Bernard. Et comme c ’est Ivan qui décide comment partager le secret, c ’est en son pouvoir d’agir ainsi. Il y a toutefois un défaut à ce protocole : si un des morceaux est perdu, le message est perdu aussi. Par exemple, si Christine s’en va chez le concurrent avec son morceau de la recette de la sauce, les autres sont dans l’embarras. Elle ne peut pas reproduire la recette, mais il en est de même pour Alice, Bernard et David. Alice, Bernard et David n’ont qu’une information commune : la longueur du message — rien de plus. Cela est dû au fait que R, S, T, U et A4 ont tous la même longueur; dès que l’on connaît l’un d’eux, on connaît la longueur du message. Rappelons que A4 n’est pas morcelé dans le sens usuel du terme, il est combiné par ou exclusif avec des chaînes aléatoires de bits.
3.7
Secret réparti
Vous mettez au point un programme de lancement de missiles nucléaires. Vous voulez être sûr qu’un fou furieux ne puisse pas déclencher le lancement. Vous voulez être sûr que deux fous furieux ne puissent pas déclencher le lancement. Vous voulez que trois officiers parmi cinq deviennent fous furieux avant d’autoriser le lancement. C’est un problème facile à résoudre. Construisez un système de lancement mécanique. Donnez une clef à chacun des cinq officiers et arrangez-vous pour qu’il faille qu’au moins trois officiers mettent leur clef dans la bonne serrure avant que vous ne les autorisiez à faire sauter l’ennemi du jo u r6. On peut faire encore plus sophistiqué. Peut-être qu’ un général et deux colonels peuvent lancer le missile, mais si le général est occupé à jouer au golf alors il faut cinq colonels pour autoriser le lancement du missile. Fabriquez le contrôleur de lancement de manière qu’il nécessite cinq clefs. Donnez trois clefs au général et une clef à chaque colonel. Le général avec l’aide de deux colonels peut lancer le missile. Cinq colonels peuvent faire de même mais un général et un colonel ne peuvent rien faire, ni quatre colonels. Un schéma de répartition, appelé schéma à seüil permet tout cela et plus encore. Au niveau le plus simple, vous pouvez prendre n’importe quel message (par exemple, une recette secrète, un code de lancement, ou même une liste de blanchissage) et le diviser en n éléments, appelés parts, de telle manière que n’importe quel ensemble de m parts puisse être utilisé pour reconstruire le message. Plus précisément, on parlera de schéma à seuil—(m ,n). Avec un schéma à seuil-(3,4), Ivan divise la recette secrète de la sauce entre Alice, Bernard, Christine et David de manière que trois d’entre eux puissent mettre leurs parts ensemble pour reconstruire le message. Si Christine est en vacances, Alice, Bernard et David peuvent le faire. Si Bernard est écrasé par un bus, Alice, Christine et David peuvent le faire. Mais si Bernard est écrasé par un bus et que Christine est en vacances, Alice et David ne peuvent pas reconstruire le message. 6. Si vous êtes vraim ent inquiet, vous pou vez éloigner les serrures à grande distance et exiger que les clefs soient insérées simultanément. Vous ne voudriez quand m êm e pas qu ’ un officier fou furieux qui aurait volé deux clefs soit capable d ’annihiler tou te une ville?
78
Chapitre S
Protocoles élémentaires
Les schémas à seuil sont plus variés que cela. Tout scénario de répartition peut être modélisé à l’aide de schémas. Vous pouvez diviser un message entre les occupants de votre immeuble, pour cela vous avez besoin de : 1°) sept occupants du premier étage et cinq occupants du deuxième étage ; 2°) il y a quelqu’un du troisième étage, dans ce cas il ne faut que cet occupant-là, trois occupants du premier étage et deux personnes du deuxième étage ; 3“) il y a quelqu’un du quatrième étage, auquel cas il faut cet occupant et un occupant du troisième étage, ou cet occupant et deux personnes du premier étage avec une personne du deuxième étage, etc. Cette idée a été inventée indépendamment par Adi S h a m i r [1421] et George B l a k l e y [189], et étudiée en profondeur par Gus SiMMONS [1473]. 11 y a plusieurs algorithmes différents décrits dans le paragraphe 23.2.
Répartition de secret avec des tricheurs Il y a plusieurs moyens de tricher avec le schéma à seuil. Voici seulement quelques-uns d’entre eux : Scénario 1 : Les colonels Alice, Bernard et Christine sont dans un bunker quelque part sous terre. Un jour, ils reçoivent un message codé de leur président: « Lancer les missiles. Nous allons rayer de la carte la recherche sur les réseaux neuronaux. » Alice, Bernard et Christine révèlent leur part, mais Christine donne un nombre aléatoire. Elle est en fait une pacifiste et elle ne veut pas lancer les missiles. Comme Christine n ’a pas donné la bonne part, le secret qu’ils récupèrent n’est pas le bon. Les missiles restent dans leurs silos. Pis encore, personne ne sait pourquoi. Alice et Bernard, même s’ils collaborent, ne peuvent pas prouver que la part de Christine n’est pas valable. Scénario 2 : Les colonels Alice et Bernard sont dans leur bunker avec Martin. Martin s’est déguisé en colonel et aucun des autres ne soupçonne la supercherie. Le même message est envoyé par le président et chacun révèle sa part. « Ha, Ha ! » s’écrie Martin, « Ce message du président est factice et j ’en suis l ’auteur. Maintenant je connais vos parts. » Il s’enfuit alors par l’escalier avant que quiconque ne puisse l’attraper. Scénario 3 : Les colonels Alice, Bernard et Christine sont dans leur bunker avec Martin qui une fois de plus s’est déguisé. Le même message vient du président et chacun révèle sa part. Martin ne révèle la sienne qu’après avoir entendu les trois autres. Comme les trois autres permettent de reconstituer le secret, il fabrique rapidement une part valide et révèle celle-ci. Maintenant, non seulement il connaît le secret mais de plus personne ne se rend compte qu’il ne fait pas partie du schéma. Certains protocoles qui contrent ce type de tricheurs sont décrits dans le para graphe 23.2.
Répartition de secret sans Ivan Une banque veut que sa chambre forte ne s’ouvre que si trois employés parmi cinq utilisent leur clef. Cela ressemble à un schéma à seuil (3,5), sauf qu’il y a un hic. Personne ne doit connaître tout le secret. Il n’y a pas d ’Ivan pour répartir le secret en cinq parties. Il existe des protocoles par lesquels cinq personnes peuvent créer un secret et recevoir chacun un élément de manière qu’aucun des participants ne puisse reconstruire le secret sans les autres. Ces protocoles ne seront pas abordés dans ce livre, voyez [445] pour les détails.
3.7
Secret réparti
79
Répartition de secret sans révélation des parts Ces schémas présentent un problème. Quand tout le monde se réunit pour reconstruir le secret, chacun doit révéler sa part. Il peut en être autrement. Si le secret réparti est une clef privée (pour une signature numérique par exemple), alors n détenteurs d’une partie du secret peuvent partiellement signer un document. Le document est signé avec la clef privée répartie seulement après la derniere signature partielle et personne n’est informé de la part d’un autre. Le secret peut alors être réutilisé et son maniement ne nécessite pas d ’opérateur de confiance. Ce concept est exploré plus avant par Yvo D e s m e d t et Yair F r a n k e l [481, 482].
Secret réparti vérifiable Ivan donne à Alice, Bernard, Christine et David une part du secret à chacun, ou du moins prétend le faire. La seule façon pour chacun d ’eux pour savoir s’il a une part valide est de reconstruire le secret. Ivan a pu envoyer à Bernard une part de rien du tout, ou bien Bernard a reçu accidentellement une mauvaise part à cause d’une erreur de transmission. Le secret réparti vérifiable permet à chacun d’eux de contrôler individuellement qu’il possède une part valide, sans qu’il soit nécessaire de reconstruire le secret [560, 1245].
Secret réparti avec veto Un secret est réparti entre cinquante personnes de manière que dix d ’entre-elles puissent reconstituer le secret. C ’est facile. Mais peut-on réaliser un schéma de secret réparti avec la contreinte supplémentaire que vingt personnes puissent empêcher les autres quel que soit leur nombre - de reconstruire le secret? Il se trouve que c’est possible [160]. Les mathématiques sous-jacentes sont compliquées, mais l’idée de base est que chacun reçoit deux parts : un « oui » et un « non ». Au moment de reconstruire le secret, chacun soumet une de ses deux parts. Le choix de la part dépend du souhait du participant quand à la reconstruction du secret. S’il y a au moins m parts « oui » et au plus n parts « non », alors le secret est reconstruit. Dans la cas contraire, il ne l’est pas. Bien sûr, rien n’empêche un nombre suffissant de personnes favorables d’aller dans un coin sans les autres (en supposant qu’ils se connaissent) et de reconstruire le secret. Mais dans la situation ou chacun soumet sa part dans un ordinateur central, cela n’est pas possible.
Secret réparti avec désistement Vous avez installé votre de système de secret réparti et vous voulez maintenant licencier un des participants. Vous pourriez instaurer un nouveau schéma mais cela demande du temps. Il existe des méthodes pour copier ce système. Elles permettent d ’activer instantanément un nouveau schéma dès qu’un participant devient indésirable [851].
80
3.8
Chapitre 3
Protocoles élémentaires
Protection cryptographique de bases de données
La liste des membres d’une association professionnelle est une information intéressante. D ’une part, vous voulez distribuer la base de données à tous les membres : vous voulez qu’ils puissent communiquer entre eux, échanger des idées, et s’inviter les uns les autres pour boire une tasse de thé. D’autre part, si vous distribuez des copies de la base de données des membres, une copie finira tôt ou tard par tomber dans les mains d’agents d’assurance ou d’autres fournisseurs de courrier publicitaire. La cryptographie peut améliorer la situation. Vous pouvez chiffrer la base de données de manière qu’il soit facile d ’extraire l’adresse d’un membre mais qu’il soit difficile d ’obtenir la liste d’adresses complète. Ce schéma, décrit dans [552, 551], est évident. Choisissez une fonction de hachage à sens unique et un algorithme à clef secrète. Chaque enregistrement dans la base de données est composé de deux champs. Le champ d ’indexation est le nom de famille de l’adhérent converti par la fonction de hachage à sens unique. Le champ de données est le nom complet et l’adresse de l’adhérent, chiffré en utilisant le nom de famille comme clef. Chercher un membre ayant un nom de famille donné est facile. Premièrement, calculez l’empreinte du nom de famille par la fonction de hachage à sens unique et cherchez cette empreinte dans les champs d’index de la base de données. S’il y a une concordance, alors il existe un membre ayant ce nom de famille. S’il y a plusieurs concordances, alors il y a plusieurs personnes dans la base de données ayant le même nom de famille. Finalement, pour chaque concordance, déchiffrez le nom complet et l’adresse en utilisant le nom de famille comme clef. Dans [552], les auteurs utilisent ce système pour protéger un dictionnaire de 6000 verbes espagnols. Ils indiquent que les dégradations de performance dues au chiffrement sont minimes. Des possibilités supplémentaires sont offertes par [551] pour faire des recherches sur des index multiples mais l’idée est la même. Le problème principal avec ce système est que vous ne pouvez pas retrouver un enregistrement d ’une personne si vous ne connaissez pas l’orthographe exacte du nom de famille de celle-ci. Vous pouvez essayer plusieurs orthographes jusqu’à ce que vous trouviez la bonne, mais ce n’est pas très pratique de passer en revue tous les noms commençant par « Sch » quand vous recherchez « Schneier ». Cette protection n’est pas parfaite. Il est possible pour un vendeur particulièrement persévérant de reconstruire la base de données des membres en essayant tous les noms de famille possibles. S’il dispose du Bottin, il peut le faire. Cela peut prendre plusieurs semaines à un ordinateur dédié à cette tâche, mais c ’est faisable. Toutefois, la tâche est plus difficile, ce qui signifie « plus cher » pour un fournisseur de courriers publicitaires. Une autre approche, décrite dans [192], permet d ’extraire des statistiques concernant des données chiffrées.
Chapitre 4
Protocoles intermédiaires 4.1
Services de datation
Dans de nombreuses situations les gens veulent pouvoir certifier qu’un document exis tait à une date donnée. Pensez à une contestation de copyright ou de brevet : celui qui peut produire le document le plus ancien gagne la partie. Il y a plusieurs manières de faire cela avec des documents papier. Des notaires peuvent signer les documents ; des hommes de loi peuvent garder des copies. Si un litige apparaît, le notaire ou l’homme de loi peut attester de l’existence de la lettre à une certaine date. Dans le monde numérique, c ’est beaucoup plus difficile. Il n ’y a pas moyen d’examiner des documents numériques pour détecter des signes de falsification. Ils peuvent être copiés et modifiés à volonté sans que cela soit décelable. Il est trivial de changer la date de création d’un fichier informatique. Personne ne peut regarder un document numérique et affirmer: « Oui, ce document a été créé avant le 4 novembre 1952. » Stuart H a b e r et W . Scott S t o r n e t t a chez B e l l c o r e ont réfléchi au problème [683, 684, 99]. Ils voulaient un protocole de datation de documents qui ait les trois propriétés suivantes : - les données elles-mêmes doivent être datées indépendamment de leur support physique ; - il ne doit pas être possible de changer le moindre bit d’un document sans que cela soit apparent ; - il doit être impossible de dater un document avec une date et une heure différentes de la vraie date.
Solution arbitrée Ce protocole utilise Ivan, qui assume le rôle d ’un service de datation sûr et fiable. Bien sûr, Alice veut dater un document : 1° Alice transmet une copie du document à Ivan. 2° Ivan enregistre la date et l’heure auxquelles il a reçu le document et garde une copie de sauvegarde du document.
Chapitre 4
82
Protocoles intermédiaires
Maintenant, si quelqu’un met en doute l’affirmation d ’Alice concernant la date de créa tion du document, elle doit juste faire appel à Ivan. Il produira sa copie du document et vérifiera qu’il l’a bien reçue à la date mentionnée. Ce protocole marche mais il a des défauts. Premièrement, il n ’y a pas de confidentialité : Alice doit donner une copie du document à Ivan. Toute personne à l’écoute pendant cette transaction peut le lire. Elle peut chiffrer le document, mais même ainsi il doit encore être stocké dans les bases de données d ’Ivan. Quelle est la sécurité de ces bases de données ? Deuxièmement, la base de données elle-même doit être gigantesque car les besoins d ’archivage seraient énormes. De plus une très large bande passante serait requise pour envoyer de grands documents à Ivan. Le troisième défaut est lié aux erreurs potentielles. Une erreur de transmission ou un défaut magnétique dans l’ordinateur central d ’Ivan pourrait invalider complètement l’affirmation d’ Alice quant à la date de création du document. Quatrièmement, il se peut que quelqu’un d’aussi honnête qu’Ivan pour gérer le service de datation n’existe pas. Peut-être qu’Alice fait appel aux services de la société de Bernard: « Datation et Art Nouveau. » Il n’y a rien qui empêche Alice et Bernard d’être complices et de dater des documents comme bon leur semble.
Solution arbitrée améliorée L’utilisation des fonctions de hachage à sens unique et les signatures numériques peuvent éviter la plupart de ces défauts : 1° Alice produit, à l’aide de la fonction de hachage à sens unique, une empreinte du document.
2° Alice transmet l’empreinte à Ivan. 3° Ivan date l’empreinte avec la date et l’heure auxquelles il a reçu l’empreinte et signe le résultat.
4° Ivan envoie l’empreinte signée et la datation à Alice. Cela permet de pallier tous les défauts sauf le dernier mentionné. Alice ne doit plus craindre de devoir révéler le contenu de son document : l’empreinte est suffisante. Ivan ne doit plus stocker des copies des documents (ni même de leur empreinte), ainsi les problèmes de capacité de stockage excessive sont résolus (rappelez-vous que les fonc tions de hachage à sens unique n’ont pas de clef). Alice peut immédiatement examiner l’empreinte datée et signée qu’elle a reçue à l’étape 4 et ainsi détecter toute erreur de transmission. Il reste le risque qu’Alice et Ivan puissent être complices pour produire n’importe quelle datation.
Protocole de filiation Un moyen d ’éviter ce dernier défaut est de lier la datation d ’Alice avec les autres datations déjà produites par Ivan, pour d’autres utilisateurs éventuels. Comme l’ordre dans lequel Ivan recevra les requêtes n’est pas connu d’avance, la datation d ’Alice doit être plus récente que celle de la requête précédente. Et comme la requête qui suit celle d’Alice est liée à la datation qu’ Alice a obtenue, sa requête doit forcément avoir eu lieu avant. La requête d’Alice est donc prise en sandwich dans le temps.
4-1
Services de datation
83
Si A est le nom d ’Alice, l’empreinte qu’Alice veut dater est Hn, et la datation précédente est Tn- 1 , alors le protocole est donné par: 1° Alice envoie Hn et A à Ivan. 2° Ivan envoie en réponse à Alice : S K ( n , A , 11n fljL i f n —
ly S n —li-^ n )
où Ln est l ’information qui relie à la datation précédente: H ( I n - l , H n - \ , T n -.\ )
Sk signifie que le message est signé avec la clef publique d’Ivan. Le nom d’Alice certifie celle-ci comme auteur de la requête. Le paramètre n indique le numéro d’ordre de la requête: c ’est la ne datation produite par Ivan. La datation est donnée par le paramètre Tn. L ’information additionnelle consiste en l'identi fication de l’auteur, l’empreinte, la datation et l’empreinte de la datation du document précédent qu’Ivan a daté.
3° Après qu’Ivan ait daté le document suivant, il envoie à Alice l’identification de l’auteur de ce document: In+ i ■
Si quelqu’un met en doute la datation d’Alice, elle contacte les auteurs des documents antérieurs et postérieurs : In- t et In+i- Si leurs documents sont aussi remis en question, ils se mettent en contact avec In- 2 et In+2 , et ainsi de suite. Chacun peut montrer que son document a été daté après celui qui précède et avant celui qui suit. Ce protocole rend très difficile la complicité entre Alice et Ivan et les empêche de pro duire un document avec une fausse datation. Ivan ne peut pas postdater un document car cela nécessiterait de connaître à l’avance la requête qui précédera ce document. Même s’il pouvait falsifier cela, il devrait alors connaître d’avance la requête avant * cela » , et ainsi de suite. Il ne peut pas antidater un document car la datation doit être prise en sandwich entre des documents datés juste avant et juste après : or ces documents ont déjà été datés. Le seul moyen de contrer ce schéma est d ’inventer des chaînes de requêtes fictives, passées et futures par rapport au document d’Alice, suffisamment longues pour décourager toute personne de contester la datation.
Protocole distribué Les gens meurent. Les datations se perdent. Beaucoup d’événements peuvent se pro duire entre le moment de la datation et la contestation de celle-ci. Quand la contestation arrive, Alice ne pourrait plus forcément obtenir une copie de la datation d’/ „ _ i . Ce défaut peut être évité en incorporant dans la datation d ’Alice les datations des 10 requêtes qui ont précédé celle d ’Alice et en envoyant à Alice les identifications des auteurs des 10 requêtes qui ont suivi la sienne. Alice a ainsi plus de chance de trouver quelqu’un qui a encore sa datation. Suivant le même ordre d’idée, le protocole suivant se passe tout à fait de la collaboration d’Ivan : 1° A partir d’Hn, Alice engendre une suite de valeurs aléatoires en se servant d’un générateur aléatoire de suites cryptographiquement sûr:
v 1,v2,v3,...yk
Chapitre 4
84
Protocoles intermédiaires
2° Alice interprète chacune de ces valeurs comme l’identification I d’une autre personne. Elle envoie H n à chacune d’entre elles.
3° Chacune de ces personnes associe la date et l’heure à l ’empreinte, signe le résultat et envoie le résultat à Alice.
4° Alice collecte et stocke toutes les signatures pour former la datation. Le générateur aléatoire de suites cryptographiquement sûr de l’étape 1 empêche Alice de choisir des identificateurs corrompus comme vérificateurs. Même si elle fait des changements mineurs à son document pour obtenir un ensemble d’identificateurs cor rompus, ses chances de réussir sont négligeables. La fonction de hachage rend aléatoire le choix des I ; Alice ne peut pas les forcer. Ce protocole marche car le seul moyen dont dispose Alice pour tricher est de convaincre les k personnes de collaborer. Comme elle les choisit aléatoirement à l’étape 1, les chances d’y arriver sont quasi inexistantes. Plus la société est corrompue, plus k doit être élevé. De plus, il faut prévoir un mécanisme qui tienne compte des personnes qui ne peuvent pas produire une datation sur le champ. Dans ce cas, tout ce qui serait nécessaire serait un sous-ensemble des k réponses attendues pour former une datation valable. Les détails dépendent de la réalisation.
Développements futurs D ’autres améliorations des protocoles de datation sont présentées dans [99]. Les au teurs utilisent des arbres binaires pour augmenter le nombre de datations qui dépendent d’une datation donnée, réduisant par la même occasion la possibilité de produire des chaînes de datations fictives. Ils recommandent également d’éditer publiquement l’em preinte des datations du jour, dans les journaux par exemple. Cela remplit une fonction similaire à l’envoi de l’empreinte à un ensemble aléatoire de personnes dans le protocole distribué. De fait, B e l l C O R E fait cela dans chaque numéro du New York Times du dimanche depuis 1992. Ces protocoles de datation sont brevetés [685, 686, 687]. Une société inattendue de Bellcore, SU RETY TECHNOLOGIES, détient les brevets et a mis sur le marché un « sys tème de notaire numérique » mettant en oeuvre ces protocoles. Dans la première ver sion, les clients envoyaient une requête « certifiée » à un serveur central de coordination. En suivant la technique de Ralph M e r k l e [590], qui permet de construire des arbres grâce à des fonctions de hachage [77], le serveur produit un arbre d ’empreintes dont les feuilles sont toutes les requêtes reçues durant une seconde, et renvoie à chaque client la liste des empreintes du chemin allant de la feuille lui correspondant jusqu’à la racine de l’arbre. Le client la conserve localement et peut produire un « certificat de notaire numérique » pour chacun des fichiers qui ont étés certifiés. La suite des racines de ces arbres forme le « dossier de validation universel » qui est accessible dans de multiples banques de données et publié sur CD-ROM. Le logiciel client comprend une fonction de « validation » qui permet à l’utilisateur de tester si un fichier a été certifié dans sa forme actuelle 1 2. 1. Pour cela il faut récupérer la racine de l’arbre approprié et la com parer à la valeur obtenue en appliquant la fonction de hachage adéquate sur le fichier et son certificat.
2. Pour plus d’ informations, contacter Surety T ech n ologies, 1 Main S t ., Chatham, NJ, 07928 É tats-U nis, T é l: (201) 701-0600, Fax: (201) 701-0601.
4-2
Canal subliminal
4.2
85
Canal subliminal
Alice et Bernard ont été arrêtés et vont aller en prison. Il entre à la prison des hommes et elle entre à la prison des femmes. Leur seul moyen de communiquer est par missives. Gatien, le gardien, est disposé à permettre l’échange de messages entre Alice et Bernard pour autant que ceux-ci ne soient pas chiffrés. Gatien s’attend à ce qu’ils complotent pour concocter un plan d ’évasion, aussi veut-il pouvoir tout lire. Gatien espère aussi duper soit Alice, soit Bernard. Il veut que l’un accepte un message factice comme un message valide venant de l’autre. Alice et Bernard sont prêts à prendre le risque d’être dupés, sinon ils ne pourraient pas communiquer du tout et ils doivent préparer leurs projets. Pour mener cela à bien, ils doivent duper le gardien et trouver un moyen de communiquer confidentiellement. Ils doivent mettre en place un canal subliminal, un canal caché de communication entre eux, au nez et à la barbe de Gatien, bien que les messages eux-mêmes ne contiennent pas d’information confidentielle. A l’aide de messages signés inoffensifs ils vont échanger de l’information confidentielle bien que Gatien lise toute la correspondance. Un canal subliminal simple pourrait être le nombre de mots dans une phrase. Un nombre impair de mots correspondrait à « 1 », tandis qu’un nombre pair de mots correspondrait à « 0 ». Ainsi, tandis que vous lisez ce paragraphe d ’apparence innocente, j ’ai envoyé à mes collaborateurs sur le terrain le message « 110 ». Le défaut de cette technique est d’être de la simple stéganographie (voir § 1.2); il n’y a pas de clef: la sécurité dépend uniquement de la confidentialité de l’algorithme. Une meilleure sécurité est certainement possible. Gustavus SlMMONS a inventé le concept de canal subliminal dans les algorithmes de si gnature numérique conventionnels [1464, 1477]. Comme les messages subliminaux sont cachés dans ce qui ressemble à des signatures numériques normales, c ’est une forme de dissimulation. Gatien voit transiter des messages innocents signés mais il rate com plètement l’information qui circule sur le canal subliminal. En fait, l’algorithme de signature numérique subliminal est indiscernable d’un algorithme de signature numé rique normal, du moins pour Gatien. Gatien non seulement ne peut pas lire le canal subliminal mais il ne peut même pas déceler sa présence. En général, le protocole ressemble à ceci : 1° Alice engendre un message innocent, aléatoirement. 2° A l’aide d’une clef secrète qu’elle partage avec Bernard, Alice signe ce message innocent de manière à cacher son message subliminal dans la signature. C ’est le cœur du protocole à canal subliminal (voir § 20.S).
3° Alice envoie le message signé à Bernard via Gatien. 4° Gatien lit le message innocent et vérifie la signature. Ne détectant rien d’anor mal, il passe le message à Bernard.
5° Bernard vérifie la signature du message innocent, confirmant ainsi que le mes sage vient bien d’Alice.
6° Bernard ignore le message innocent et, utilisant la clef secrète qu’il partage avec Alice, il extrait le message subliminal.
Qu’en est-il de la tricherie? Gatien ne fait confiance à personne et personne ne lui fait confiance. Il peut toujours empêcher la communication, mais il n’a aucun moyen
86
Chapitre 4
Protocoles intermédiaires
d’introduire des messages factices. Comme il ne peut pas engendrer de signature valide, Bernard détecterait la tentative de Gatien à l’étape 5. Et comme il ne connaît pas la clef secrète partagée, il ne peut pas lire le canal subliminal. Plus important encore, il n’a pas la moindre idée que des messages subliminaux sont échangés. Des messages numériques signés ne sont pas différents d’aspect des messages numériques signés avec messages subliminaux cachés dans la signature. La tricherie entre Alice et Bernard est plus problématique. Dans certaines réalisations du canal subliminal, l’information secrète dont Bernard a besoin pour lire les messages subliminaux est la même information dont Alice a besoin pour signer les messages innocents. Si tel est le cas, Bernard peut se faire passer pour Alice. Il peut signer des messages dont Alice serait alors prétendûment l’auteur et Alice ne peut rien faire pour l’en empêcher. Si elle doit lui envoyer des messages subliminaux, elle doit lui faire confiance pour qu’il n ’abuse pas de sa clef privée D’autres réalisations du canal subliminal n’ont pas ce défaut Une clef secrète partagée entre Alice et Bernard permet à Alice d ’envoyer des messages subliminaux à Bernard mais elle est différente de la clef privée d ’Alice. Cette clef secrète ne permet pas à Bernard de signer des messages à la place d ’Alice. Alice n’a pas à faire confiance à Bernard pour qu’il n’abuse pas de sa clef privée.
Applications du canal subliminal L’application la plus évidente du canal subliminal est observée dans un réseau d’es pionnage. Si tout le monde envoie et reçoit des messages signés, les espions ne se feront pas remarquer en envoyant des messages subliminaux dans des documents signés. Bien entendu, les espions de la partie adverse peuvent faire la même chose. Grâce à un canal subliminal, Alice peut signer un contrat sous la menace. Quand elle signe le contrat, elle introduit le message subliminal : « J ’y suis contrainte. » D ’autres applications sont plus subtiles. Une société peut signer des documents et cacher des messages subliminaux, lui permettant ainsi de suivre les documents tout au long de leur existence. Le Gouvernement peut marquer de la monnaie numérique. Un programme de signature malveillant peut dévoiler la clef privée par le canal subliminal. Les possibilités sont sans fin.
Signature numérique exempte de canal subliminal Alice et Bernard échangent des messages signés pour négocier les termes d’un contrat. Ils utilisent un protocole de signature numérique. Toutefois, cette négociation de contrat sert de façade à leurs activités d’espionnage. Quand ils usent de l’algorithme de signature numérique, peu leur importe les documents qu’ils signent. Ils utilisent un canal subliminal dans les signatures pour échanger de l’information secrète entre eux. Les services de contre-espionnage, en revanche, ne savent pas que cette négociation de contrat et leurs signatures sont des façades. Ceci a conduit certaines personnes à créer des schémas de signature exempts de canal subliminal. Ce sont des sché mas de signature numérique qui ne peuvent pas être modifiés pour contenir un canal subliminal [477, 479].
4-3
Signatures numériques incontestables
4.3
87
Signatures numériques incontestables
Des signatures numériques conventionnelles peuvent être copiées intégralement. Parfois, cette propriété est souhaitable comme dans le cas des annonces publiques par exemple. Dans d ’autres situations cela peut être un défaut. Imaginez une lettre signée, person nelle ou commerciale. Si plusieurs copies de cette lettre circulent dans la nature, cela peut être embarrassant et même prêter au chantage. La meilleure solution est une si gnature numérique qui peut être reconnue valable, mais que le destinataire ne peut pas montrer à un tiers sans le consentement du signataire. La société A l i c e S o f t w a r e C o m p a n y distribue le célèbre logiciel D E W (« D oEVERYTHiNG -W O RD tm »). Pour garantir que leur logiciel n’est pas infecté par un virus, ils ajoutent une signature numérique. Toutefois, ils veulent que seuls les acheteurs légi times du logiciel, pas les pirates, puissent vérifier la signature. Cependant, si des copies de DEW sont infectées, il n’y aurait aucun moyen pour la société A l i c e S o f t w a r e C o m p a n y de contester une signature valable. Les signatures in con testa b les [211] conviennent pour ce genre de tâche. Tout comme les signatures numériques normales, une signature incontestable dépend du document signé et de la clef privée du signataire. Mais contrairement à une signature numérique normale, une signature incontestable ne peut être vérifiée sans le consentement du signataire. « Signature intransférables » serait un nom plus approprié, mais on continue à les appeler ainsi car si Alice est forcée de confirmer ou de désavouer une signature— au tribunal par exemple—elle ne peut pas contester sa propre signature. Les mathématiques sur lesquelles repose ce protocole sont décrites dans le para graphe 16.7, mais l’idée de base est simple: 1° Alice présente une signature à Bernard. 2° Bernard engendre un nombre aléatoire et l’envoie à Alice. 3° Alice effectue un calcul, utilisant le nombre aléatoire et sa clef privée, et envoie le résultat à Bernard. Alice ne peut faire ce calcul que si la signature est valide.
4° Bernard confirme ce fait. Il y a un protocole suplémentaire dans lequel Alice prouve qu’elle n’a pas signé un document, sans pouvoir le contester s’il s’agit bien de sa signature. Bernard ne peut pas contourner le protocole et convaincre Christine que la signature d’Alice est valide, parce que Christine ne sait pas que les nombres de Bernard sont aléatoires. Il peut très bien avoir refait le protocole à l’envers sur papier sans l’aide d’Alice et ensuite montrer le résultat à Christine. Christine ne peut pas être convaincue que la signature d’Alice est valide à moins d’exécuter le protocole avec Alice elle-même. Cela peut ne pas avoir beaucoup de sens maintenant mais cela en aura une fois que les mathématiques sous-jacentes auront été présentées au paragraphe 23.4. Cette solution n ’est pas parfaite. Y vo D e s m e d t et Moti Y u n g montrent que Bernard peut, dans certaines applications convaincre Christine de la validité de la signature d’Alice [487]. Par exemple, Bernard achète une copie légale du logiciel D E W . Il peut valider la signature qui accompagne le logiciel quand il le veut. Bernard peut alors convaincre Christine qu’il est un vendeur de la société A l i c e S o f t w a r e C o m p a n y . Il lui vend une copie pirate du logiciel D E W . Quand Christine essaie de valider la signature avec
88
Chapitre 4
Protocoles intermédiaires
Bernard, il valide simultanément la signature avec Alice. Quand Christine lui envoie le nombre aléatoire, il l’envoie à Alice. Quand Alice répond, il envoie la réponse à Christine. Christine est alors convaincue qu’elle est une acheteuse légitime du logiciel alors qu’il n’en est rien. Cette attaque est un cas particulier du problème du grand maître aux échecs qui est décrit en détail dans le paragraphe 5.2. Telles quelles, les signatures icontestables ont de nombreuses applications; il y a beau coup de situation où Alice ne veut pas que n ’importe qui puisse vérifier sa signature. Elle ne veut sûrement éviter que sa correspondance personnelle puisse être vérifiée par la presse, montrée et vérifiée hors du contexte, où même vérifiée après que les choses ont changé. Si elle signe une bribe d’information qu’elle a vendue, elle ne veut pas que ceux qui n’ont pas payé pour l’information puissent tout de même en vérifier l’authenticité. En contrôlant ceux qui vérifient sa signature, Alice protège sa vie privée. Une variante des signatures incontestables permet de séparer le lien entre le signataire et le message, et le lien entre le signataire et la signature [911]. Dans ce cadre, n’im porte qui est capable de vérifier que le signataire a bien produit la signature, mais la coopération du signataire est nécessaire pour vérifier que la signature est valide pour le message en question. Il existe une notion similaire, celle de signatures incontestables arbitrées. Imaginez qu’Alice travaille pour la société Toxines et envoie des documents compromettants à un journal en utilisant un protocole de signature incontestable. Alice peut confirmer sa signature au prés du journaliste, et à personne d ’autre. Toutefois, Bernard, le contre maître suspecte Alice d ’avoir divulgué les documents. Il demande à Alice de contester le protocole pour se laver de tout soupçon, et Alice refuse. Bernard prétend que la seule raison poussant Alice à refuser est sa culpabilité et il la licencie. Les signatures incontestables arbitrées s’utilisent comme les signatures incontestables sauf que seul Ivan peut effectuer le protocole de contestation. Bernard ne peut pas demander à Alice de contester sa signature car seul Ivan en est capable. Si Ivan est le sytème judiciaire, il ne devra effectuer le protocole qu’en cas de dispute.
4.4
Signatures numériques à vérificateur dédié
La SARL Logiciels Alice fait des ventes astronomiques de D E W , à tel point que Alice passe plus de temps à vérifier des signatures incontestables qu’à élaborer de nouveaux logiciels. Alice voudrait engager une presonne chargée de vérifier les signatures pour toute l’en treprise. Alice, ou tout autre programmeur, pourrait signer des documents avec un protocole de signature incontestable; mais les vérifications seraient toutes faites par Christine. Il se trouve que c ’est possible grâce aux signatures à vérificateur dédié [337, 1221]. Alice peut signer un document de sorte que Bernard est convaincu de la validité de la signature sans pouvoir convaincre un troisième parti; ce faisant, Alice peut désigner Christine comme future vérificatrice de la signature. Alice n’a pas même besoin de la permission de Christine; il lui suffit d’utiliser la clef publique de celle-ci. De plus Christine peut encore confirmer la signature d’Alice qu’Alice soit partie en voyage, qu’elle ait quitté la société, ou qu’elle soit morte.
4-5
Signatures par procuration
89
Les signatures à vérificateur dédié sont une sorte de compromis entre les signatures nu mériques classiques et les signatures incontestables. Dans certaines circonstances, Alice voudra restreindre le nombre des personnes capables de vérifier sa signature. D ’un autre côté, donner un contrôle total à Alice peut compromettre l’utilisation des signatures : Alice pourrait refuser de coopérer pour confirmer ou désavouer une signature en prétexant qu’elle a perdu les clefs nécessaires, ou en étant simplement injoignable. Les signatures à vérificateur dédié assurent à Alice la protection d ’une signature incontes table sans lui permettre d’abuser de cette protection. Alice préférera voir les choses ainsi: les signatures à vérificateur dédié lui permettent d ’éviter des utilisations indérisables, de la protéger si elle perd sa clef, et d’assurer la pérénité du fonctionnement des signatures si elle est en vacances, à l’hopital, ou morte. Cette idée permet toutes sortes d ’applications. Christine peut se déclarer « notaire publique ». Elle publie sa clef et n’importe qui peut la désigner comme vérificatrice de ses signatures. Elle peut faire payer chaque confirmation de signature et mener une vie tranquille. Christine peut être un bureau de brevetage, une agence gouvernementale, ou l’ordi nateur hôte d ’une organisation. Ce protocole permet de différencier les personnes qui signent les documents de celles qui vérifient les signatures.
4.5
Signatures par procuration
Les signatures à vérificateur dédié permettent de désigner quelqu’un d’autre comme vérificateur des signatures. Alice doit par exemple partir en voyage d’affaires quelque part où elle n’a pas accès à un réseau informatique, comme la jungle africaine. Ou il se peut qu’elle soit indisposée après une opération chirurgicale. Elle attend un courrier électronique important et a briffé son secrétaire Bernard pour répondre en conséquence. Comment Alice peut-elle permettre à Bernard de signer des messages pour elle, sans lui donner sa clef privée? Les signatures par procuration apportent une solution [1010], Alice peut donner une procuration à Bernard, en remplissant les propriétés suivantes: - Distingabilité. N’importe qui peut distinguer une signature par procuration d’une signature usuelle. - Non falsification. Seul le signataire original et le signataire interposé peuvent produire une signature par procuration. - Signataire interposé malveillant. Un signataire interposé ne peut pas pro duire de signature de signature sans qu’on puisse détecter qu’il s’agit d’une si gnature par procuration. - Vérification. Une signature par procuration peut convaincre un vérificateur de l’accord du signataire original sur le message signé. - Identification. Le signataire original peut déterminer l’identité du signataire interposé à partir d’une signature par procuration. - Non désaveu. Un signataire interposé ne peut pas désavouer une signature par procuration qu’il a produit.
Chapitre 4
90
Protocoles intermédiaires
Dans certains cas, une forme d’identification plus large est nécessaire, permettant à n’importe qui de déterminer l’identité du signataire interposé à partir de la signature par procuration. Des protocoles de signatures par procuration, basés sur différentes réalisations de signatures numériques, se trouvent dans [1010].
4.6
Signatures collectives
David C h a u m présente ainsi ce problème dans [333] : « Une société a plusieurs ordinateurs. Chacun est connecté au réseau local. Chaque département de la société a sa propre imprimante (aussi connec tée au réseau local) et seul le personnel du département a le droit de se servir de cette imprimante. Avant d’imprimer, l’imprimante doit donc être convaincue que l’utilisateur travaille dans ce département . En même temps, la société impose la confidentialité ; le nom de l’utilisateur ne peut pas être révélé. Toutefois, si quelqu’un découvre en fin de journée qu’une imprimante a été utilisée trop souvent, le directeur doit être capable de retrouver qui en a abusé pour envoyer une facture au coupable. » La solution à ce problème est appelée signature collective. Les signatures collectives ont les propriétés suivantes : - Seuls les membres du groupe peuvent signer des messages. - Celui qui reçoit une signature peut vérifier que c’est une signature valide de ce groupe mais ne peut pas déterminer quel membre du groupe a signé. - En cas de litige, la signature peut être « ouverte » pour révéler l’identité du signataire.
Signature collective avec arbitre Ce protocole utilise un arbitre en qui l’on a confiance : 1° Ivan engendre un lot de paires « clef privée, clef publique » et donne à chaque membre du groupe une liste différente de clefs privées uniques. Il n’y a pas de doublon entre les listes3.
2° Ivan publie la liste principale de toutes les clefs publiques pour le groupe dans un ordre aléatoire. Il reste seul à savoir qui possède quelle clef.
3° Quand un membre du groupe veut signer un document, il choisit une clef au hasard parmi sa liste personnelle.
4° Quand quelqu’un veut vérifier qu’une signature appartient au groupe, il re cherche dans la base de données publique la clef publique et vérifie la signature.
5° En cas de litige, Ivan connaît la correspondance entre les clefs publiques et les membres du groupe. 3. Si le groupe com porte n membres, et chaque m em bre a m paire de clefs, il y a en tou t n X m paires de clefs au total.
1^.1
Signatures numériques « Fait-Stop »
91
Le défaut de ce protocole est qu’il nécessite l’intégrité d ’Ivan. Il connaît les clefs privées de tout le monde et il peut imiter des signatures. De plus, la liste des clefs de chaque membre doit être suffisamment longue pour éviter que l’on puisse analyser quelles clefs ils ont utilisées. L’article de C h a u m [333] donne d ’autres protocoles. Pour certains d ’entre eux, Ivan ne peut pas imiter de signatures. Dans d’autres Ivan n’est pas toujours nécessaire. Un autre protocole [352] permet non seulement de cacher l’identité du signataire, mais aussi d’élargir le groupe à de nouveaux membres. On trouvera encore un autre protocole dans [1241]
4.7
Signatures numériques « Fail-Stop »
Faisons l’hypothèse qu’Estelle est un adversaire puissant. Elle a de grands réseaux in formatiques, des pièces pleines d ’ordinateurs Cray : une puissance informatique consi dérablement plus importante que celle d ’Alice. Tous ces ordinateurs fonctionnent jour et nuit pour trouver la clef privée d ’Alice. Et enfin, le résultat tombe. Estelle peut maintenant se faire passer pour Alice signant à sa place des documents à volonté. Les signatures numériques « Fail-Stop », introduites par Birgit P f i t z m a n n et Michael W a i d n e r [1250], empêchent ce genre de tricherie. Si Estelle falsifie des signatures de cette manière, alors Alice peut prouver qu’il y a eu falsification. Si Alice signe des documents et renie sa signature après coup, prétendant qu’il y a eu falsification, un tribunal peut vérifier ses dires. L’idée de base des signatures numériques « Fail-Stop » est que pour chaque clef publique possible, de nombreuses clefs privées conviendraient. Chacune de ces clefs privées donne des signatures numériques différentes. Toutefois, Alice n’a qu’une clef privée et elle ne peut calculer qu’une signature. Alice ne sait rien des autres clefs privées. Estelle essaie de retrouver la clef privée d ’Alice (dans ce cas-là, Estelle peut être Alice qui essaie de trouver une seconde clef privée pour elle-même). Elle collectionne les messages signés et, en utilisant sa batterie d’ordinateurs Cray, elle essaie de retrouver cette clef privée. Même si elle finit par trouver une clef privée valide, comme il y en a de nombreuses possibles, il est fort probable qu’elle en ait découvert une différente de celle qu’Alice utilise. La probabilité qu’Estelle retrouve la bonne clef peut être rendue si faible qu’elle est négligeable. Maintenant, quand Estelle falsifie une signature au bas d’un document avec la clef privée qu’elle a trouvée, cette signature sera différente de celle qui aurait été calculée par Alice. Quand Alice est traînée devant les tribunaux, elle peut produire les deux signatures différentes du même message : celle obtenue à l’aide de sa clef privée et celle produite par Estelle. Elle peut ainsi prouver qu’il y a eu falsification. De même, Alice ne peut pas fabriquer les deux signatures différentes et Alice est toujours liée par sa signature. Ce schéma de signature empêche Estelle d’imiter la signature d ’Alice par puissance de calcul seulement ; en revanche, il ne peut rien contre Martin qui fort probablement entrera par effraction au domicile d ’Alice et volera sa clef privée, ou encore contre Alice qui signe un document et puis qui soi-disant perd sa clef. Pour se protéger du premier, Alice devrait s'acheter un bon chien de garde; ce genre de choses dépasse le cadre de la cryptographie.
Chapitre 4
92
Protocoles intermédiaires
Des développements théoriques et des applications concernant les signatures « FailStop » sont décrits dans [1249, 1251, 732, 733].
4.8
Calcul avec données chiffrées
Alice veut connaître la valeur d ’une certaine fonction f ( x ) pour une valeur particulière de x. Malheureusement, son ordinateur est en panne. Bernard est disposé à lui calculer f(x) mais Alice ne veut pas que Bernard connaisse x. Comment Alice peut-elle laisser Bernard calculer f ( x ) sans lui révéler x ? C ’est le problème général du calcul avec données chiffrées, appelé aussi « cacher de l’information à un oracle ». Dans l’exemple ci-dessus, Bernard est l’oracle : il répond à des questions. On peut appliquer cela à certaines fonctions ; nous en reparlerons dans le paragraphe 23.6.
4.9
Mise en gage
La Grande Alice, magicienne extraordinaire, va maintenant vous prouver son talent. Elle va deviner quelle carte Bernard va choisir avant même qu’il ne le fasse ! Observez comment Alice écrit sa prédiction sur un bout de papier. Emerveillez-vous quand Alice met le bout de papier dans une enveloppe et scelle celle-ci. Frissonnez quand Alice tend cette enveloppe à un membre de l’assemblée choisi au hasard. « Choisis une carte, Bernard, n’importe quelle carte. » Il la regarde et la montre à Alice et au public. C ’est un sept de carreau. Alice récupère maintenant l’enveloppe. Elle l’ouvre. La prédiction, écrite avant que Bernard ne choisisse, dit « sept de carreau » ! Applaudissements. Le truc est qu’Alice change d ’enveloppe à la fin du tour. Toutefois, les protocoles cryptographiques peuvent fournir une méthode où ce tour de passe-passe est impossible. Pourquoi est-ce utile? Voici une histoire plus banale: Alice la cambiste, veut convaincre l’investisseur Bernard que sa méthode de choix d’actions en hausse est fiable. Bernard : « Choisis cinq actions pour moi. Si elles sont toutes en hausse, je te confie mes affaires. » Alice : « Si je choisis cinq actions pour toi, tu peux investir toi-même sans me payer en retour. Pourquoi est-ce que je ne te montrerais pas plutôt les actions que j ’ai choisies le mois dernier? » Bernard : « Comment puis-je savoir que tu n ’as pas changé ton choix du mois dernier après avoir connu les résultats? Si tu m’indiques ton choix maintenant, je sais que tu ne peux pas le changer. Je n’investirai pas dans ces actions avant d ’avoir acheté ta méthode. Fais-moi confiance. » Alice : « Je préfère te montrer mon choix du mois précédent. Fais-moi confiance. » Voilà le problème : Alice veut s’en remettre à un choix mais elle ne veut pas révéler ce choix avant un certain temps. Bernard, de son côté, veut être sûr qu’Alice ne puisse pas changer son choix après coup.
4-9
Mise en gage
93
Mise en gage à l’aide de la cryptographie à clef secrète Ce protocole de mise en gage utilise la cryptographie conventionnelle : 1° Bernard engendre une chaîne de bits aléatoire, R, et l’envoie à Alice : R
2° Alice crée un message constitué du bit qu’elle veut mettre en gage, b (cela peut même être plusieurs bits), et de la chaîne aléatoire de Bernard. Elle chiffre le tout avec une clef aléatoire, K et envoie le résultat à Bernard. E K (R,b)
C’est la partie de mise en gage du protocole. Bernard ne peut pas déchiffrer le message et donc il ne connaît pas la valeur du bit. Quand vient le moment pour Alice de révéler la valeur du bit, le protocole se poursuit ainsi : 3° Alice envoie la clef à Bernard. 4° Bernard déchiffre le message pour retrouver le bit. Il vérifie la chaîne aléatoire pour vérifier la validité du bit.
Si le message ne contenait pas la chaîne aléatoire de Bernard, Alice pourrait, en ca chette, déchiffrer le message qu’elle a donné à Bernard en essayant différentes clefs, jusqu’à ce qu’elle en trouve une qui donne au bit une valeur autre que celle qu’elle avait mise en gage. Comme le bit ne peut avoir que deux valeurs, elle serait sûre de trouver une clef qui convienne après très peu d’essais. La chaîne aléatoire de Bernard empêche cette attaque. Alice doit trouver un nouveau message qui non seulement contient son bit inversé mais aussi la chaîne aléatoire de Bernard inchangée. Si l’algorithme de chif frement est bon, les chances pour Alice de trouver une autre clef sont infimes. Alice ne peut pas changer la valeur du bit après l’avoir mis en gage.
Mise en gage à l’aide de fonctions à sens unique Ce protocole utilise des fonctions à sens unique4 : 1° Alice engendre deux chaînes de bits aléatoires, Ri et R ? . R i ,R2
2° Alice crée un message contenant les deux chaînes aléatoires et le bit qu’elle veut mettre en gage (cela peut même être plusieurs bits). (Ri,R2,b)
3° Alice applique la fonction à sens unique H au message et envoie le résultat à Bernard ainsi qu’une des deux chaînes aléatoires.
H(Ri,R2,b),Ri 4. Remarquez que tou te fonction à sens unique générale convient pou r ce ty p e d e protocole, pas seulement les fonctions de hachage à sens unique.
Chapitre 4
94
Protocoles intermédiaires
Cette dernière transmission est la mise en gage proprement dite. Alice a utilisé une fonction à sens unique à l’étape 3 et donc Bernard ne peut pas l’inverser pour retrouver la valeur du bit. Quand.vient le tour d ’Alice pour révéler le bit, le protocole se poursuit ainsi: 4° Alice envoie à Bernard le message d’origine:
5° Bernard applique la fonction à sens unique à ce message et compare la valeur obtenue et R\ à la valeur qu’Alice avait envoyée à l’étape S et R\. Si elles concordent, le bit est valable.
L’avantage de ce protocole sur le précédent est que lorsque la communication est établie, seule une communication unidirectionnelle est nécessaire : Bernard n’a pas à parler à Alice. Alice envoie à Bernard un message pour mettre en gage le bit et un message pour le révéler. La chaîne aléatoire de Bernard n’est pas nécessaire car le message de mise en gage d ’Alice est le résultat d ’une fonction à sens unique. Alice ne peut pas tricher et trouver un autre message (Ri,R'2,b'), tel que H(Ri,R'2,b') = H(R\,R 2 ,b). Si Alice n’envoyait pas Ri, alors elle pourrait changer les valeurs de Ri et R^ et ainsi changer la valeur de b. Le fait que Bernard connaisse déjà R\ l’en empêche.
Mise en gage à l’aide d’un générateur pseudo-aléatoire de suites Ce protocole est encore plus simple [1146] : 1° Bernard engendre une chaîne aléatoire de bits et l ’envoie à Alice. Rb
2° Alice engendre un germe aléatoire pour un générateur pseudo-aléatoire de bits. Ensuite pour chaque bit de la chaîne aléatoire de Bernard, elle envoie à Bernard: (a) soit la sortie du générateur aléatoire si le bit de Bernard est 0 ;
(b) soit
le « ou exclusif » de la sortie du générateur et de son bit, si le bit de Bernard est 1.
Quand vient le moment pour Alice de révéler son bit, le protocole se poursuit ainsi : 3° Alice envoie à Bernard le germe aléatoire. 4° Bernard effectue l ’étape 2 du protocole pour vérifier qu’Alice était honnête. Si la chaîne aléatoire de Bernard est assez longue, et que le générateur pseudo-aléatoire de bits est imprévisible, Alice n’a aucun moyen pratique de tricher.
f.10
Jouer à pile ou face
95
Pâtés Les chaînes de mise en gage qu’Alice envoie à Bernard sont parfois appelées pâtés. Un pâté est une suite de bits, bien que les protocoles n’utilisent pas cette propriété. Comme le dit Gilles B r a s s a r d : « Ils pourraient tout aussi bien être faits de poussière d’étoile (ou de photons polarisés!) si cela s ’avérait utile. » [239] Les pâtés ont les propriétés suivantes : - Alice peut mettre un pâté en gage. Ce faisant, elle s’engage quant à la valeur d’un bit spécifique. - Alice peut ouvrir n’importe quel pâté qu’elle a mis en gage. Quand elle ouvre un pâté, elle peut convaincre Bernard de la valeur du bit qu’elle a mis en gage lors qu’elle a mis le pâté en gage. Donc, elle ne peut pas ouvrir un pâté indifféremment à la fois comme un 0 ou comme un 1. - Bernard ne peut rien apprendre sur la méthode pour ouvrir un pâté non encore ouvert et mis en gage par Alice. C ’est vrai même après qu’Alice a ouvert d’autres pâtés. - Les pâtés ne contiennent pas d’autre information que le bit mis en gage par Alice. Les pâtés eux-mêmes ainsi que les procédés de mise en gage et d ’ouverture ne sont en aucune façon corrélés avec d ’autres secrets qu’Alice pourrait vouloir cacher à Bernard.
4.10
Jouer à pile ou face
C’est l’heure d ’une petite histoire, avec Joe K i l i a n [832] : Alice et Bernard veulent jouer à pile ou face mais ils n’ont pas de pièce à lancer. Alice propose une méthode pour jouer à pile ou face mentalement. « Premièrement, tu penses à un bit aléatoire, ensuite je pense à un bit aléatoire. Ensuite on prend le ou exclusif des deux bits. » suggère-t-elle. « Mais que se passe-t-il si l’un de nous deux ne choisit pas aléatoire ment? » demande Bernard. « Peu importe. Aussi longtemps que l’un des deux bits est vraiment aléatoire, le ou exclusif des deux bits doit être aléatoire. » répond Alice, et après un moment de réflexion, Bernard est d ’accord. Peu de temps après, Alice et Bernard trouvent dans la rue un livre sur l’intelligence artificielle. En bonne citoyenne, Alice dit : « L ’un de nous deux doit ramasser le livre et le mettre dans une poubelle. » Bernard est d ’accord et suggère qu’ils utilisent leur protocole de tirage à pile ou face pour décider qui devra jeter le livre. « Si le dernier bit est 0, alors tu ramasseras le livre, et si c ’est un 1, alors je le ferai. Quel est ton bit ? » dit Alice. Bernard répond « 1. » « Comme le mien, répond-t-elle avec espièglerie. Ce n’est pas ton bon jour. »
Chapitre 4
96
Protocoles intermédiaires
Inutile d ’insister, ce protocole de tirage à pile ou face a un défaut ma jeur. Bien qu’il soit vrai qu’un bit x vraiment aléatoire, combiné par ou exclusif avec un autre bit x non corrélé donne un bit vraiment aléatoire, le protocole d ’Alice ne garantit pas que les deux bits aient des distributions indépendantes. En fait, il n’est pas difficile de vérifier qu’aucun protocole mental ne permet à deux parties, avec des ressources infinies, de jouer à pile ou face honnêtement. Alice et Bernard étaient bien embêtés jusqu’à ce qu’ils reçoivent une lettre d ’un obscur étudiant en cryptographie. L’information que contenait la lettre était bien trop théorique pour avoir une quelconque utilité pratique mais l’enveloppe qui contenait la lettre était par contre d’une très grande utilité. Lorsqu’Alice et Bernard voulurent à nouveau jouer à pile ou face, ils jouèrent une version modifiée du protocole. D ’abord, Bernard choisissait un bit, mais au lieu de l’annoncer immédiatement, il l’écrivait sur un bout de papier et plaçait celui-ci dans une enveloppe. Ensuite, Alice annonçait son bit. Finalement, Alice et Bernard sortaient de l’enveloppe le bit de Bernard et calculaient le bit aléatoire. Ce bit était vraiment aléatoire si un d ’entre eux au moins avait joué honnêtement. Alice et Bernard avaient un protocole qui marchait ; le rêve du cryptographe d ’avoir un rôle social était satisfait et ils vécurent heureux jusqu’à la fin de leurs jours. Ces enveloppes ressemblent à des pâtés. Quand Manuel B lum introduisit le problème du jeu à pile ou face au téléphone [201], il obtint une solution grâce au protocole de mise en gage suivant : 1° Alice met en gage un bit aléatoire, en utilisant l ’un des protocoles de mise en gage décrits au paragraphe 4-9.
2° Bernard essaie de deviner le bit. 3° Alice révèle le bit à Bernard. Bernard gagne le tirage s ’il a deviné correctement le bit d’Alice.
En général, un tel protocole doit satisfaire les propriétés suivantes : - Alice doit tirer à pile ou face avant que Bernard ne devine. - Alice ne doit pas être capable de changer la pièce après avoir entendu le choix de Bernard. - Bernard ne doit pas pouvoir savoir comment la pièce a atterri avant de faire son choix. Il y a de nombreuses façons de réaliser cela.
Jouer à pile ou face à l’aide de fonctions à sens unique Si Alice et Bernard peuvent se mettre d ’accord sur le choix d ’une fonction à sens unique, le protocole est simple : 1° Alice choisit un nombre aléatoire, x. Elle calcule y = f (x), où f {x) est la fonction à sens unique.
4-10
97
Jouer à pile ou face
2° Alice envoie y à Bernard. 3° Bernard devine si x est pair ou impair et envoie sa supposition à Alice. 4° Si la supposition de Bernard est correcte, le résultat du lancer est face. Si la supposition de Bernard est incorrecte, le résultat du lancer est pile. Alice annonce le résultat du lancer et envoie x à Bernard.
5° Bernard vérifie que y = f(x). La sécurité de ce protocole dépend du choix de f(x). Si Alice peut trouver x et x', où x est pair et x' est impair et où y = f { x ) = f{x'), alors elle peut tromper Bernard à chaque lancer. De plus, Alice doit veiller à ce que le bit de poids faible de x ne soit pas corrélé avec f(x). Sinon, Bernard peut tromper Alice de temps à autre. Par exemple, si x est pair dans 75 % des cas, Bernard est avantagé5.
Jouer à pile ou face à l’aide de la cryptographie à clef publique 11 y a un autre protocole qui marche avec soit la cryptographie à clef publique, soit la cryptographie à clef secrète. La seule exigence est que l’algorithme soit commutatif, comme suit : D Kl ( E k2 (EKl ( M) ) ) = E k , {A4) En général, cette propriété n’est pas satisfaite par les algorithmes à clef secrète, mais l’est par les algorithmes à clef publique (l’algorithme à clef publique R S A , par exemple). Voici le protocole: 1° Alice et Bernard engendrent chacun une paire « clef publique, clef privée ». 2° Alice engendre deux messages, l’un indiquant face et l’autre pile. Ces messages doivent contenir une chaîne aléatoire unique, de manière qu’Alice puisse véri fier leur authenticité plus tard dans le protocole. Alice chiffre les deux messages avec sa clef et les envoie à Bernard. E A ( M l ) , E A ( M 2)
3° Bernard, qui ne peut lire aucun des deux messages, choisit l’un d’entre eux au hasard (il peut lancer une pièce de monnaie, engager un ordinateur malfaisant pour tenter en vain de décider lequel choisir, ou même consulter son horoscope chinois - peu importe). Il chiffre celui qu’il a choisi avec sa clef et envoie le résultat à Alice. E b (E a ( M ) ) A4 représente donc soit A4i soit A42.
4° Alice qui ne peut pas lire ce message, le déchiffre avec sa clef et envoie le résultat à Bernard. D a {E b (E a ( M) ) )
=
E b ( M i ) si M = M !
=
E b {A42) si A4 — A42
5. Le bit de poids faible constitue parfois un mauvais ch oix car il arrive q u ’il soit plus facile à calculer.
Chapitre 4
98
Protocoles intermédiaires
5° Bernard déchiffre le message avec sa clef pour découvrir le résultat du lancer. Il envoie le message déchiffré à Alice. D b (E b ( M ) )
=
Mi
—
M 2 si M = M 2
si M = M i
6° Alice lit le résultat du lancer et vérifie que la chaîne aléatoire est correcte. 7° Alice et Bernard révèlent tous les deux leurs clefs de telle manière qu’ils puissent vérifier que ni l’un ni l’autre n’a triché.
Ce protocole est à sécurité intrinsèque. Chaque participant peut immédiatement détec ter toute tentative de tricherie de l’autre. Aucun tiers n’est nécessaire pour conduire le protocole ni pour résoudre les litiges après que le protocole a été exécuté. Pour voir pourquoi il en est ainsi, essayons de tricher. Si Alice veut tricher et imposer le tirage face, elle dispose de trois moyens pour modifier le lancer.Premièrement, elle peut chiffrer deux messages face àl’étape 2. Bernard découvrirait celalorsqu’Alice révèle sa clef (ou ses clefs) à l’étape 7.Deuxièmement, elle peut mal déchiffrer le message à l’étape 4. Toutefois, elle ne peut pas trouver un moyen de déchiffrer le message pour imposer un autre contenu qui ne soit pas du charabia. Bernard découvrirait la supercherie à l’étape 5. Troisièmement, elle peut mentir quand à la validité du message à l’étape 6. Bernard s’en rendrait compte à l’étape 7, quand Alice ne pourrait pas prouver que le message n ’est pas valide. Bien sûr, Alice peut refuser de participer à toute étape du protocole, auquel cas la supercherie d’Alice serait évidente pour Bernard. Si Bernard veut tricher et imposer le tirage pile, il n ’a pas plus de possibilités. Il peut mal chiffrer le message à l’étape 3, mais Alice découvrirait la supercherie à l’étape 6 en lisant le message. Il peut mal exécuter l’étape 5 mais cela donnerait aussi du charabia qu’Alice découvrirait à l’étape 6. Il peut prétendre n’avoir pu bien exécuter correcte ment l’étape 5 à cause d ’une tricherie d ’Alice, mais ce type de tricherie serait découvert à l’étape 7. Finalement, il peut envoyer un message pile à l’étape 5, peu importe le message qu’il a déchiffré, mais Alice pourrait immédiatement vérifier l’authenticité de ce message à l’étape 6.
Jouer à pile ou face dans un puits Il est intéressant de remarquer que dans tous ces protocoles, Alice et Bernard n’ap prennent pas le résultat du lancer en même temps. Il y a un instant du protocole où un des participants (Alice dans les deux premiers protocoles et Bernard dans le dernier) connaît le résultat du lancer mais ne peut pas le changer. Ce participant peut toutefois retarder la divulgation du résultat à l’autre participant. On dira alors que l’on jo u e à pile o u face dans un puits. Imaginez un puits. Alice est près du puits et Bernard est très loin. Bernard lance une pièce, celle-ci atterrit dans le puits. Alice peut maintenant regarder dans le puits et voir le résultat mais elle ne peut pas atteindre la pièce pour changer son état. Bernard ne peut pas voir le résultat du lancer jusqu’à ce qu’Alice l’autorise à s’approcher suffisamment près pour regarder dans le puits.
j .l l
Poker à l’aveugle
99
Génération de clef par jeu à pile ou face Une application concrète de ce protocole est la génération de clef. Les protocoles de jeu à pile ou face, permettent à Alice et Bernard d’engendrer une clef aléatoire sans que l’un ou l’autre ne puisse influer sur la clef. Et en faisant l’hypothèse qu’Alice et Bernard chiffrent tous leurs échanges, cette clef sera à l’abri des oreilles indiscrètes.
4.11
Poker à l’aveugle
Un protocole similaire au troisième protocole de jeu à pile ou face permet à Alice et Bernard de jouer au poker, chacun étant à une extrémité d’une liaison par courrier électronique Au lieu de fabriquer et de chiffrer deux messages (un pour pile et un pour face), Alice fabrique 52 messages, un pour chaque carte du paquet. Bernard choisit 5 messages au hasard, les chiffre avec sa clef publique et les renvoie à Alice. Alice déchiffre les messages et envoie le résultat à Bernard qui déchiffre ceux-ci à son tour pour découvrir sa donne. Il envoie, sans les chiffrer avec sa clef dans ce cas-là, 5 autres messages à Alice, qui les déchiffre pour déterminer sa donne. Durant le jeu, des cartes supplémentaires peuvent être distribuées en suivant le même protocole. À la fin du jeu, Alice et Bernard révèlent leurs jeux et leurs paires de clefs ; ainsi chacun peut être assuré que l’autre n’a pas triché.
Poker à l’aveugle avec trois joueurs Le jeu de poker est plus amusant avec plus de joueurs. Le protocole de base du poker à l’aveugle peut être étendu à trois joueurs et plus. Une fois de plus, l’algorithme cryptographique doit être commutatif. 1° Alice, Bernard, et Christine, chacun, engendrent une clef secrète ou une paire « clef privée, clef publique ». 2° Alice engendre 52 messages, un pour chaque carte à jouer. Ces messages doivent contenir une chaîne aléatoire unique de manière qu’elle puisse véri fier leur authenticité plus tard dans le protocole. Alice chiffre tous les messages avec sa clef et les envoie à Bernard. E A ( M n)
3° Bernard, qui ne peut lire aucun des messages, en choisit 5 au hasard. R les chiffre avec sa clef et les renvoie à Alice. E B(EA( M n)) 4° Bernard envoie les 47 autres messages à Christine. E A( M n)
5° Christine, qui ne peut lire aucun des messages, en choisit 5 au hasard. Elle les chiffre avec sa clef et les renvoie à Alice. E c (EA( M n))
Chapitre 4
100
Protocoles intermédiaires
6° Alice, qui ne peut lire aucun des messages qui lui sont renvoyés, déchiffre ceuxci avec sa clef et envoie les résultats à Bernard ou Christine (en fonction de leur provenance). D A(EB(EA( M n))) = E B( M n) D A(Ec (EA( M n))) = E c ( M n)
7° Bernard et Christine déchiffrent les messages avec leurs clefs respectives pour découvrir leurs donnes. D B(EB ( M n)) — M n Dc {Ec { M n)) = M n
8° Christine choisit 5 autres messages parmi les 42 restant. Elle les envoie à Alice. E A( M n)
9° Alice déchiffre les messages pour découvrir sa donne. D A(EA( M n))
=
AAn
10° A la fin du jeu, Alice, Bernard et Christine dévoilent leurs jeux et leur clefs afin que chacun puisse vérifier qu’il n’y a pas eu tricherie.
Des cartes supplémentaires peuvent être distribuées de la même manière. Si soit Bernard, soit Christine veut une carte, il ou elle prend le talon chiffré et exécute le protocole avec Alice. Si Alice veut une carte, celui ou celle qui a le talon à ce moment-là lui envoie une carte au hasard. Idéalement, l’étape 10 ne devrait pas être nécessaire. Les joueurs ne devraient pas être obligés de révéler leur jeu en fin de partie : seuls les joueurs qui n’ont pas suivi devraient le faire. Puisque l’étape 10 ne fait partie du protocole que pour détecter les tricheurs, on peut y remédier. Au poker, il est seulement intéressant de savoir si le gagnant a triché ou non. Tous les autres peuvent tricher tant qu’ils veulent du moment qu’ils ne gagnent pas. Voyons donc des cas où différents joueurs gagnent. Si Alice gagne, elle dévoile son jeu et ses clefs. Bernard peut utiliser la clef privée d ’Alice pour confirmer qu’elle a honnêtement exécuté l’étape 2 (en d ’autres termes que les 52 messages correspondent bien aux 52 cartes à jouer). Christine peut confirmer qu’Alice ne ment pas concernant la composition de son jeu en chiffrant les cartes d ’Alice avec la clef d’Alice et en vérifiant que les messages obtenus correspondent bien à ceux que Christine lui a envoyés à l’étape 8. Si soit Bernard, soit Christine gagne, il ou elle révèle son jeu et ses clefs. Alice peut confirmer que les cartes sont authentiques en comparant avec sa chaîne aléatoire. Elle peut confirmer que le jeu est composé des cartes distribuées en les chiffrant avec la clef du gagnant, et en comparant avec ce qu’elle a envoyé à l’étape 3 ou 5. Ce protocole ne protège pas contre la complicité de plusieurs joueurs malfaisants. Alice et un autre joueur peuvent effectivement se liguer contre le troisième et plumer celui-ci sans éveiller le moindre soupçon. Il est donc important de vérifier les chaînes aléatoires et les clefs chaque fois que les joueurs révèlent leur jeu. Et si vous êtes assis à cette
4-11
Poker à l’aveugle
101
table virtuelle avec deux autres joueurs qui ne révèlent jamais leur main quand l’un des deux est le donneur (Alice, dans le protocole ci-dessus), arrêtez de jouer. Il faut noter que si cela constitue une théorie intéressante, le réaliser sur un ordinateur est une tâche ardue. Une réalisation sur des stations de travail Sparc avec trois joueurs (un par station) prend huit heures pour mélanger les cartes [515].
Attaques contre les protocoles de poker à l’aveugle Les cryptographes ont montré qu’il y a des petites fuites d’information dans ces pro tocoles de poker à l’aveugle quand l’algorithme RSA est utilisé [456, 575]. Plus préci sément, si la représentation binaire de la carte est un résidu quadratique (voir § 11.3), alors la carte chiffrée est aussi un résidu quadratique. Cette propriété peut être utilisée pour marquer certaines cartes — tous les as par exemple. Cela ne révèle pas grand chose sur les jeux des joueurs, mais dans un jeu comme le poker, la moindre parcelle d’information peut être un avantage à long terme. Shafî G o l d w a s s e r et Silvio M i c a l i [626] ont développé un protocole de poker à l’aveugle à deux joueurs qui ne souffre pas de ce défaut. Mais sa complexité le rend bien plus théorique que pratique. Un protocole général de poker à l’aveugle à n joueurs qui élimine le problème de fuite d ’information a été développé dans [393]. Le compte rendu d’autres recherches sur les protocoles de poker sont donnés dans [575, 1636, 393]. Un protocole compliqué qui évite aux joueurs de devoir révéler leur jeu est décrit dans [394]. Don COPPERSMITH décrit deux moyens de tricher au poker à l’aveugle si celui-ci utilise l’algorithme R S A [374].
Distribution anonyme de clefs Bien qu’il soit improbable que quiconque utilise ce protocole pour jouer au poker par modem, Charles P f l e e g e r décrit une situation où ce protocole serait bien utile [1254], Considérez le problème de la distribution des clefs. Si nous émettons l’hypothèse que les utilisateurs ne peuvent pas engendrer leurs clefs eux-mêmes (elles doivent avoir une certaine forme, ou elles doivent être signées par un organisme, ou quelque chose de similaire), alors nous devons mettre en place un serveur centralisé pour engendrer et distribuer les clefs. Le problème est de trouver un moyen pour distribuer les clefs de manière que personne, même pas le serveur lui-même, puisse déterminer qui a quelle clef. Le protocole suivant résout le problème : 1° Alice engendre une paire « clef privée, clef publique ». Pour ce protocole, elle garde les deux clefs secrètes.
2° Le C D C engendre une suite continue de clefs. 3° Le C D C chiffre les clefs une à une avec sa propre clefpublique. 4° Le C D C transmet les clefs une à une sur le réseau. 5° Alice choisit une clef au hasard. 6° Alice chiffre la clef choisie avec sa clef publique. 7° Alice attend un peu (suffisamment longtemps pour que le serveur ne puisse pas deviner quelle clef elle a choisie) et envoie la clef doublement chiffrée au CDC.
Chapitre 4
102
Protocoles intermédiaires
8° Le C D C déchiffre la clef doublement chiffrée avec sa clef privée, donnant une clef chiffrée avec la clef publique d’Alice.
9° Le serveur envoie cette clef chiffrée à Alice. 10° Alice déchiffre la clef avec sa clef privée. Estelle, qui écoute tout, n’a pas la moindre idée de la clef choisie par Alice. Elle voit un flot continu de clefs passer à l’étape 4. Quand Alice renvoie sa clef au serveur à l’étape 7, elle est chiffrée avec sa clef publique, qui est également secrète. Estelle n’a aucun moyen de corréler celle-ci avec le flot de clefs du serveur. Quand le serveur renvoie la clef à Alice à l’étape 9, elle est aussi chiffrée avec la clef publique d ’Alice. Ce n’est qu’à l’étape 10, quand Alice déchiffre sa clef, que celle-ci est dévoilée. Si vous utilisez l’algorithme R S A , il y a des fuites d’information dans ce protocole, au rythme d ’un bit par message. C ’est lié aux résidus quadratiques une fois de plus. Si vous envisagez de distribuer des clefs ainsi, veillez à ce que la fuite d’information soit suffisamment faible. Bien sûr, si Alice ne peut pas faire confiance au C D C, la fuite d ’information est inévitable. Un C D C malveillant garderait un enregistrement de toutes les clefs qu’il engendre. Il pourrait ensuite parcourir cet enregistrement pour déterminer quelle est la clef d’Alice. Ce protocole présume qu’Alice agit honnêtement. Si l’algorithme R SA est utilisé, elle peut agir pour obtenir plus d’information qu’elle ne devrait en avoir. Ce n ’est pas un problème dans notre scénario, mais peut le devenir dans d ’autres circonstances.
4.12
Accumulateurs à sens unique
Alice fait partie de la société Clique d’import export. Il lui arrive de rencontrer les autres membres dans des restaurants mal éclairés et de chuchoter des secrets à droite à gauche. Le problème est que le restaurant est si mal éclairé qu’elle a du mal à voir si la personne à l’autre bout de la table est aussi membre. La société Clique peut opter pour plusieurs solutions. Chaque membre peut porter une liste des membres. Cela pose deux problèmes. Premièrement, tout le monde doit transporter une importante base de données, et deuxièmement, ils doivent surveiller de prés leurs listes des membres. D ’un autre côté, un secrétaire.de confiance pourrait distribuer des cartes d’identité signées numériquement. Ceci présente l’avantage sup plémentaire de permettre aux étranger de vérifier l’appartenance d ’un membre (pour des remises chez l’épicier par exemple), mais cela requiert un secrétaire de confiance. Aucun membre de la société Clique ne mérite une telle confiance. Une solution originale consiste à utiliser quelque chose du nom de a ccu m u lateu r à sens unique [126]. C ’est, une sorte de fonction de hachage à sens unique, à la différence près que c ’est, commutatif. C ’est à dire qu’il est, possible d ’appliquer cette fonction à la liste des membres dans n’importe quel ordre en obtenant toujours la même valeur. On peut même rajouter des membres toujours sans se soucier de l’ordre. Aussi, voici ce qu’Alïce fait. Elle calcule l’accumulation de tous les noms des membres excepté le sien. Ensuite, elle stocke le résultat avec son nom. Bernard, ainsi que tous les autres membres, font de même. Maintenant, quand Alice et Bernard se rencontrent dans le restaurant, mal éclairé, ils échangent simplement leurs valeurs d ’accumulation et leurs noms. Alice vérifie alors que l’ajout du nom de Bernard à sa valeur d’accumulation
4-13
Divulgation tout ou rien de secrets
103
produit le même résultat que l’ajout du nom d’ Alice à sa propre valeur d’accumulation. Bernard fait de même. Chacun sait alors que l’autre est bien un membre. De plus, aucun des deux n’a la moindre idée des identités des autres membres. Encore mieux, on peut donner toutes les valeurs d’accumulation à des personnes exté rieures. Alice peut alors prouver son appartenance à la société à une personne extérieure (peut-être pour obtenir une remise au magasin local de contre espionnage) sans que la personne extérieure puisse deviner la liste entière des membres. Pour ajouter de nouveaux membres, il suffit d’envoyer leurs noms aux autres. Malheureusement, le seul moyen d ’effacer un membre et d ’envoyer à tout le monde une nouvelle liste et de recalculer les valeurs d’accumulation. Mais la société Clique n’a besoin de faire cela que si un membre démissionne; les membres morts peuvent rester sur la liste. (Aussi étrange que cela puisse paraître, cela n’a jamais posé de problème). C’est une idée intelligente qui entre en application chaque fois que vous désirez les mêmes effets que les signatures numérique sans avoir recourt à un signeur centralisé.
4.13
Divulgation tout ou rien de secrets
Imaginez qu’Alice soit un ex-agent, secret de l’ex-Union soviétique, aujourd’hui sans emploi. Pour se faire de l’argent, elle vend des secrets. Toute personne prête à en payer le prix peut acheter un secret. Elle a même un catalogue. Tous les secrets sont mentionnés avec un numéro et avec des titres alléchants : « Où est Jimmy Hoffa? », « Qui contrôle secrètement la Commission Trilatérale? », « Pourquoi Boris Yeltsin paraît-il toujours avoir avalé une couleuvre? », etc. Alice ne donnera pas deux secrets pour le prix d ’un, ni la moindre information concer nant n’importe quel secret. Bernard, un acheteur potentiel, ne veut pas acheter des secrets au hasard, ni dire à Alice quel secret il veut lui acheter. Cela ne regarde pas Alice, sinon, elle pourrait ajouter à la fin de son catalogue : « Quels sont les secrets qui intéressent Bernard? » Un protocole de poker ne marchera pas dans ce cas-là car, à la fin du protocole, Alice et Bernard doivent mutuellement révéler leur jeu. B y aussi des astuces que Bernard peut utiliser pour apprendre plus d ’un secret. La solution s’appelle les protocoles à divulgation tout ou rien de secrets (aussi connus sous le nom de A N D O S : « all-or-nothing disclosure of secrets ») [249], car dès que Bernard a obtenu l’information sur un quelconque secret d’Alice, il a perdu toute chance d’apprendre quoi que ce soit concernant les autres secrets. Il y a plusieurs protocoles A N D O S décrits dans la littérature cryptographique. Certains d’entre eux seront décrits dans le paragraphe 23.9.
4.14
Dépôt de clefs
Voici comment Silvio
M lC A U
introduit ce sujet [1091] :
« Les écoutes téléphoniques, autorisées par les autorités judiciaires, consti tuent le moyen le plus efficace de la société pour prévenir le crime et pour confondre les criminels. Il y a donc une crainte légitime quant à la large
104
Chapitre 4
Protocoles intermédiaires
diffusion de la cryptographie à clef publique, qui pourrait être un outil puissant dans les mains des organisations criminelles et terroristes. De fait, plusieurs projets de loi proposent qu’une agence gouvernementale puisse, dans certaines circonstances définies par la loi, être capable d ’obtenir le texte en clair de toute communication sur un réseau public. Actuellement, cette demande se traduirait en une obligation pour tous les citoyens de: 1°) utiliser un cryptosystème faible — c ’est-à-dire, un cryptosystème que les autorités (mais aussi n’importe qui d ’autre !) pourrait casser sans grand effort; 2°) remettre, a priori, leur clef secrète à cette autorité. Il n’est pas étonnant qu’une telle alternative ait provoqué un tollé général. La plupart des citoyens concernés estiment que le secret de la vie privée doit passer avant la sécurité nationale et la mise en application de la loi. » Le dépôt de clefs est au coeur du programme gouvernemental américain C L IP P E R et de son standard de chiffrement par clefs sous dépôt « Escrowed. Encryption Standard ». Il s’ agit ici de développer un cryptosystème qui permetrait, à la fois de protéger la vie privée de chacun et de faire des écoutes sous autorisation judiciaire. Ce standard tire sa fiabilité de puces résistante à l’investigation. Chaque puce de chif frement aurait un numéro d ’identification unique et une clef secrète. Cette clef est divisée en deux morceaux et fichée avec son numéro dans deux organismes distincts de dépôt. Chaque fois que la puce chiffre un fichier de données, elle commence par chiffrer la clef de session avec cette clef secrète unique. La clef de session chiffrée et le numéro d’identification de la puce sont transmis lors de la communication. Quand un organisme de répression veut déchiffrer le traffique chiffré avec une de ces puces, elle se procure les clefs appropriées au prés des organismes de dépôt grâce au numéro d ’identification, ensuite elle combine les deux clefs au moyen de l’opération X O R , elle déchiffre la clef de session, qu’elle peut utiliser pour déchiffrer le trafique de messages. U y a quelques complications pour faire fonctionner cela au nez et à la barbe des tricheurs; les détails seront abordés au paragraphe 24.16. On peut faire la même chose avec des logiciels en utilisant la cryptographie à clef publique [84, 1581, 1582, 1583]. M i c a l l i appelle son idée les c r y p t o s y s t è m e s é q u i t a b l e s [1091, 1090]6. Dans ces cryptosystèmes, la clef privée est morcellée et chaque morceau est confié à une autorité différente. Comme pour un schéma de secret réparti, les autorités peuvent se mettre ensemble pour reconstruire la clef privée. De plus, les morceaux ont la propriété de pouvoir être validés individuellement, sans reconstruire la clef privée. Alice peut créer sa propre clef privée, la diviser en n morceaux et donner chacun des n morceaux à un dépositaire7. Aucun de ces dépositaires ne peut reconstruire individuel lement la clef privée d’Alice. Toutefois, chacun des dépositaires peut vérifier la validité du morceau de clef qui lui a été confié ; Alice ne peut pas envoyer à un des dépositaires une chaîne de bits aléatoire et espérer s’en tirer ainsi. Si l’autorité judiciaire autorise une écoute, les autorités compétentes pour faire respecter la loi peuvent réquisitionner les n morceaux auprès des n dépositaires. Avec les n morceaux, les autorités peuvent reconstruire la clef privée et peuvent placer une écoute sur les lignes d ’Alice. En outre, Martin, doit corrompre tous les n dépositaires pour être capable de reconstruire la clef privée d’Alice et ainsi violer sa vie privée. 6 . Le gouvernem ent am ércain aurait payé un m illion de dollars à M i c a l l i pou r l’ utilisation de son brevet [1092, 1093]; des com pagnies de banques ont ensuite acheté le brevet de M i c a l l i . 7. N ote du traducteur : en français, on parle également de « fidéicom missaire ».
4-If
Dépôt de clefs
105
Voici comment le protocole est défini : 1° Alice crée sa paire « clef privée, clef publique ». Elle partage sa clef privée en plusieurs morceaux publics et privés.
2° Alice envoie un morceau public et le morceau privé correspondant à chaque dépositaire. Ces messages doivent être chiffrés. Elle envoie aussi la clef publique au C D C .
3° Chaque dépositaire effectue un calcul pour vérifier que le morceau public et le morceau privé dont il dispose sont corrects. Chaque dépositaire stocke le morceau privé quelque part en sécurité et envoie le morceau public au C D C.
4° Le C D C effectue un autre calcul sur les morceaux publics et la clef publique. Si tout est correct, il signe la clef publique d’Alice et soit il la renvoie à celle-ci, soit il l’affiche dans une base de données quelque part.
Si une autorité judiciaire autorise une écoute, alors chaque dépositaire remet son mor ceau au C D C . Le C D C reconstruit alors la clef privée. Avant cela, ni le C D C , ni aucun des dépositaires ne pouvait reconstruire individuellement la clef privée : tous les dépositaires sont requis pour reconstruire la clef. Tout algorithme à clef publique peut être rendu équitable de cette manière. Certains algorithmes particuliers sont décrits dans le paragraphe 23.10. L’article de M lC A L i [1091, 1090] présente des méthodes pour combiner cela avec un schéma à seuil, de manière qu’un sous-ensemble des dépositaires (par exemple, 3 parmi 5) soit nécessaire pour reconstruire la clef privée. Il montre aussi comment combiner cela avec un transfert inconscient (voir § 5.5) afin que les dépositaires ne puissent pas connaître l’identité du propriétaire de la clef privée reconstruite. Les cryptosystèmes équitables ne sont pas parfaits. Un criminel peut exploiter le sys tème en utilisant un canal subliminal (voir § 4.2) pour insérer une autre clef secrète dans son morceau. De cette manière, il peut communiquer de façon sûre avec quelqu’un d’autre en utilisant cette clef subliminale sans avoir à se soucier d’une mise sur écoute judiciaire. Un autre protocole appelé d é p ô t d e clefs à sû reté in tégrée résoud ce problème [957, 834]. L’algorithme et le protocole seront décrits au paragraphe 23.10.
La politique du dépôt de clefs Mis à part les plans gouvernementaux de dépôts de clefs, il existe plusieurs propositions. Ceci nous amène à nous poser la question suivante: quels sont les avantages pour l’utilisateur de mettre sa clef sous dépôt? En fait, il n’y en a aucun. L ’utilisateur n’en retire rien qu’il ne puisse se procurer luimême. Il peut sauvegarder ses clefs si il veut (voir § 8.8). Le dépôt de clef garanti que la police peut écouter ses conversations ou lire ses dossiers même s’ils sont chiffrés. Il garanti que la NSA peut écouter ses appels internationaux sans autorisation, même s’ils sont chiffrés. Peut-être sera-t-il autorisé à utiliser la cryptographie dans des pays qui maintenant l’ont bannie, mais ça semble être le seul avantage. Le dépôt de clef a de considérables désavantages. L’utilisateur doit faire confiance à l’agent de sécurité des dépôts, ainsi qu’à l’intégrité des personnes impliquées dans la procédure. Il doit croire que les agents de dépôts ne changeront pas leur politique, que le gouvernement ne changera pas ses lois et que ceux qui ont toute autorité pour
106
Chapitre 4
Protocoles intermédiaires
obtenir ses clefs le fasse dans le cadre de la loi et avec responsabilité. Imaginez une attaque terroriste massive à New York; quelles seraient les limites dépassées par la police en répercussion? Il est dur d ’imaginer des plans de dépôts de chiffrement fonctionnant tels que ses parti sans le voudraient, c ’est-à-dire sans aucune sorte de pression légale. La prochaine étape évidente est de bannir l’utilisation des chiffrements non déposés. C ’est probablement la seule manière de rendre un système commercial lucratif, et c’est certainement la seule manière de les faire utiliser par des criminels et terroristes techniquement très équipés. Il n’est pas facile de dire s’il sera aisé de faire disparaître la cryptographie non dépo sée, ou si cela affectera la cryptographie en tant que discipline académique. Comment puis-je rechercher des programmes d’algorithmes cryptographiques sans avoir en ma possession du matériel de chiffrement non déposé; aurai-je besoin d ’une autorisation spéciale ? Il y a des questions légales. Les dépôts de clefs engageront-ils la responsabilité des uti lisateurs s’il y avait une fuite de données chiffrées? Si le gouvernement américain essaie de protéger les agences de dépôts, cela ne voudrait-il pas dire que c ’est l’utilisateur qui sera systématiquement en faute si le secret devait être compromis soit par l’utilisateur soit par l’agence de dépôts? Que se passerait-il si une grande entreprise de dépôts de clefs, gouvernementale ou civile, se faisait voler toutes ses clefs mises en dépôt? Que se passerait-il si le gou vernement américain essayait d ’étouffer l’affaire? Cela aurait un indéniable effet sur la volonté des utilisateurs à continuer à utiliser le dépôt de clefs. Si ce n’est pas volontaire, quelques scandales de ce genre auraient pour effet d ’augmenter la pression politique pour soit le rendre volontaire, soit rajouter des règles complexes à cette industrie. Ce qui serait encore plus dangereux serait un scandale rendu publique où un membre de l’opposition à l’administration en place, ou un vif opposant aux agences de ren seignement ou de police, aurait été sous surveillance pendant plusieurs années. Ceci pourrait faire monter un sentiment hostile au chiffrement mis sous dépôt. Si les signatures de clefs sont comme les chiffrement de clefs mises sous dépôt, il y a alors d ’autres débouchés. Peut-on accepter des autorités qu’elles utilisent des signatures de clefs pour mener des opérations contre des criminels? Est-ce-que l’authenticité des signatures basées sur des clefs déposées sera reconnue en cour de justice? Quels recours auront les utilisateurs si les autorités utilisent leurs signatures de clefs pour signer des contrats défavorables, pour aider une industrie étatisée, ou pour voler de l’argent? La globalisation de la cryptographie amène toute une série de questions. Est-ce-que les politiques de dépôts de clefs seront compatibles entre différentes nations? Est-ce-que les entreprises multi-nationales devront déposer leurs clefs séparément dans chaque pays afin de respecter les différentes législations? Sans un minimum de compatibilité, un des avantages supposés des dépôts de clefs (utilisation internationale de chiffrement) disparaît. Que se passerait-il si des pays ne faisaient pas confiance en la sécurité des agences de dépôts de clefs? Comment les utilisateurs feraient-ils des affaires? Leurs contrats digitaux seront-ils confirmés par la cour, ou est-ce-que le fait que leur signature de clef soit sous dépôt aux Etats-Unis leur permet de dire qu’en Suisse quelqu’un d ’autre aurait pu signer ce contrat électronique ? Y aura-t-il des dispositions spéciales pour les personnes faisant des affaires dans de tels pays? Et à propos de l’espionnage industriel, il n’y a aucune raison de croire que les pays
4-14
Dépôt de clefs
107
faisant de l’espionnage industriel pour leurs grandes entreprises ou leurs entreprises nationalisées ralentiront leurs actions sur les systèmes de chiffrement des dépôts de clefs. En effet, puisqu’aucun pays ne va autoriser les autres à surveiller ses opérations de renseignement, l’utilisation étendue de chiffrements déposés augmentera probablement la pose d’écoutes téléphoniques. Même si les pays respectueux du droit civil utilisent le dépôt de clefs pour la seule poursuite légitime des criminels et des terroristes, on peut être certain qu’il sera aussi utilisé pour traquer des dissidents, faire chanter des opposants politiques, etc... Les communications digitales offrent aujourd’hui, à la différence des technniques analo giques, la possibilité de surveiller de manière bien plus poussée les mouvements des citoyens, les opinions, les achats et les associations. Il n’est pas facile de dire si cela affectera les dépôts de clefs commerciaux, excepté que dans 20 ans, vendre à la Turquie ou à la Chine un système de dépôt de clefs prêt à l’emploi ressemblera fortement à vendre des matraques en Afrique du Sud dans les années 1970, ou construire une usine chimique en Iraq en 1980. Pire, des enregistre ments faciles et indétectables de communications pourront inciter des gouvernements à surveiller les communications de nombreux de leurs citoyens, même ceux qui n’avaient jamais essayé auparavant. Il n’y a pas de garantie que les démocraties libérales seront insensibles à cette tentation.
Chapitre 5
Protocoles avancés 5.1
Preuves à divulgation nulle
Alice : « Je connais le mot de passe de l’ordinateur de la Réserve Fédérale Américaine, la recette secrète de la sauce de McDonald et le contenu du volume 4 de l’ouvrage de K n u t h . » Bernard : « Non, tu ne les connais pas. » Alice : « Si, je les connais. » Bernard : « Que non ! » Alice : « Mais si ! » Bernard: « Prouve-le! » Alice : « Bon, je vais tout te dire. » (Elle murmure à l’oreille de Bernard.) Bernard: « C ’est intéressant. Maintenant, je sais aussi. Et je vais tout raconter au Washington Post. » Alice: « Aïe! » Malheureusement, le moyen le plus simple pour Alice de prouver à Bernard qu’elle connaît un secret est de lui dévoiler celui-ci. Mais alors, partageant le secret Bernard peut ensuite le raconter à qui veut bien l’entendre et Alice n’y peut rien. (Dans la littérature, d ’autres acteurs montent sur les planches pour ce genre de protocoles. Patricia joue généralement le rôle du plaideur et Victor le rôle du vérificateur. Ces noms sont utilisés dans les exemples à venir.) En utilisant les fonctions à sens unique, Patricia peut effectuer une p reu v e à d iv u l gation nulle [628]. Ce protocole démontre à Victor que Patricia a une information mais il ne donne aucun moyen à Victor de déterminer quelle est cette information. Ces preuves prennent la forme de protocoles interactifs. Victor pose à Patricia une série de questions. Si Patricia connaît l’information, elle peut répondre à toutes les questions correctement. Si elle ne la connaît pas, elle a 50 % de chances de répondre correctement. Après une dizaine de questions ou plus, Victor sera convaincu que Patricia connaît l’information. De plus, aucune des questions ou réponses ne donne à Victor le moindre indice concernant l’information de Patricia — excepté le fait que Patricia la connaît.
Chapitre 5
110
Protocoles avancés
Preuve à divulgation nulle de base Jean-Jacques Q u i s q u a t e r et Louis G u il l o u [1292] illustrent les preuves à divulgation nulle à l’aide de l’histoire d ’une grotte. La grotte, illustrée à la figure 5.1, a un secret. Celui qui connaît la formule magique peut ouvrir la porte entre C et D. Pour toute autre personne, les deux tunnels mènent à un cul-de-sac.
F lG . 5.1 - Grotte à divulgation nulle
Patricia connaît le secret de la grotte. Elle veut le prouver à Victor mais elle ne veut pas lui révéler la formule magique. Voici comment elle le convainc : 1° Victor se place au point A. 2° Patricia entre dans la grotte jusqu’au point C ou jusqu’au point D. 3° Après que Patricia a disparu dans la grotte, Victor va jusqu’au point B . 4° Victor crie à Patricia en lui demandant : (a) soit de sortir par le tunnel de gauche ;
(b) soit
de sortir par le tunnel de droite.
5° Patricia s ’exécute, en utilisant la formule magiquesi nécessaire. 6° Patricia et Victor répètent les étapes 1 à 5 unnombre n de fois. Supposons que Victor filme tout ce qu’il voit avec une caméra. Il enregistre disparais sant dans la cave, il enregistre le moment où il crie à Patricia par quel tunnel elle doit sortir et il filme Patricia sortant. Il enregistre les n essais. En voyant ce film, Christine serait-elle convaincue que Patricia connaît la formule magique? Non Victor et Patricia auraient pu s’entendre à l’avance ce que Victor crierait et Patricia n’aurait eu qu’à aller dans le bon tunnel. Elle serait ainsi toujours sortie du bon côté sans connaître la formule magique. Us pourraient encore procéder autrement. Patricia va dans un des
5.1
Preuves à divulgation nulle
111
passages et Victor lui fait une requête aléatoire. Si Victor a demandé le bon passage, tout va bien; sinon, ils coupent cette séquence du film final. De quelque manière que ce soit, Victor peut obtenir un film avec exactement la même séquence d ’événements que dans une preuve réelle où Patricia connaît la formule magique. Cela prouve deux choses. Premièrement, Victor ne peut pas convaincre un troisième parti de ta validité de la preuve. Deuxièmement, le protocole a une divulgation nulle. Dans le cas où Patricia ne connaissait pas la formule magique, Victor n’apprendra évidemment rien en regardant le film. Mais comme il n’y a pas de moyen de distinguer un enregistrement réel d ’un faux, Victor ne peut rien apprendre de la preuve réelle, elle a forcément une divulgation nulle. La technique utilisée dans ce protocole est appelée « couper-et -choisir » à cause de sa similitude avec le protocole classique pour diviser quelque chose équitablement : 1° Alice coupe en deux. 2° Bernard choisit une des moitiés pour lui-même. 3° Alice prend la moitié restante. Il est dans l’intérêt d ’Alice de partager honnêtement à l’étape 1, car Bernard peut choisir sa part à l’étape 2. Michael R a b i n est le premier à avoir utilisé la technique « couper-et-choisir » en cryptographie [1293]. Les concepts de p r o to c o le in te ra ctif et de divulgation nulle furent formalisés par la suite [628, 629]. La technique couper-et~choisir marche parce que Patricia ne peut pas deviner à coup sûr le côté par lequel Victor lui demandera de sortir. Si elle ne connaît pas le secret, elle ne peut ressortir que par où elle est entrée. Elle a 50 % de chance de deviner le côté par lequel Victor lui demandera de sortir au tour suivant, elle a donc 50 % de chance de pouvoir le duper. Les chances de pouvoir le duper en deux tours sont de 25 % et les chances de pouvoir le duper en n tours n fois sont de une sur 2n . Après 16 tours, Patricia a une chance sur 65 536 de duper Victor à chaque fois. Victor peut raisonnablement conclure que si les 16 preuves de Patricia sont toutes valables, alors elle doit connaître la formule magique pour ouvrir la porte entre C et D. (L’analogie avec la grotte n’est pas parfaite. Patricia peut simplement prendre un des tunnels et ressortir par l’autre ; la technique couper-et-choisir n ’est pas nécessaire. Toutefois, la preuve mathématique en a besoin.) Faites l’hypothèse que Patricia connaît une information et que cette information est la solution d ’un problème très difficile. Le protocole de base consiste en plusieurs tours : 1° Patricia utilise son information et un nombre aléatoire pour transformer son problème en un autre problème très difficile qui est isomorphe à la fonction initiale. Elle utilise alors son information et le nombre aléatoire pour résoudre le nouveau problème difficile.
2° Patricia met en gage la solution de ce nouveau problème à l’aide d’un protocole de mise en gage quelconque.
3° Patricia dévoile à Victor le nouveau problème très difficile. Victor ne peut pas utiliser ce nouveau problème pour déduire la moindre information concernant, le problème initial ou sa solution.
4° Victor demande à Patricia : (sl) soit de prouver que l ’ancien et le nouveau problèmes sont isomorphes,
Chapitre 5
112
Protocoles avancés
(b) soit
de dévoiler la solution mise en gage à l’étape 2, et de prouver que c ’est bien une solution du nouveau problème.
5° Patricia s ’exécute. 6° Patricia et Victor effectuent les étapes 1 à 5 un nombre n de fois. Vous souvenez-vous de la caméra dans l’épisode de la cave? On peut faire la même chose ici. Victor peut transcrire tous ses échanges entre lui et Patricia. Il ne peut pas utiliser la transcription pour convaincre Christine, car il peut s’entendre avec Patricia pour construire une simulation qui maquille le savoir de Patricia. Cet argument prouve que le protocole est à divulgation nulle. Les mathématiques sous-jacentes à ce type de preuve sont compliquées. Les problèmes et les transformations aléatoires doivent être choisis judicieusement de manière que Victor n’obtienne pas la moindre information concernant la solution du problème ini tial, même après plusieurs itérations du protocole. Tous les problèmes difficiles ne peuvent pas être utilisés pour des preuves à divulgation nulle mais c ’est, le cas pour nombre d ’entre eux.
Isomorphisme de graphes Un exemple permettra de mieux illustrer ce concept. Celui-ci vient de la théorie des graphes [621, 624]. Un graphe est un réseau de lignes connectant des points. Si deux graphes sont identiques mis à part les noms des étiquettes, on dit qu’ils sont iso m orph es. Pour des graphes extrêmements grands, il peut falloir des siècles de calcul pour vérifier s’ils sont isomorphes; c ’est l’un des problèmes difficiles abordés au para graphe 11.1. Faites l’hypothèse que Patricia connaît l’isomorphisme entre deux graphes G i et GV Le protocole suivant convainc Victor que Patricia connaît bien cet isomorphisme : 1° Patricia permute aléatoirement les nœuds de G\ pour obtenir un autre graphe. H qui est isomorphe à G i. Comme Patricia connaît l’isomorphisme entre G\ et H , elle connaît aussi l’isom.orphisme entre H et G'2 ■ Pour toute autre personne, trouver l ’isomorphisme entre G'i et H ou entre G'2 et H , est aussi difficile que de trouver l’isomorphisme entre G\ et G 2 2° Patricia envoie H à Victor. 3° Victor demande à Patricia: {a) soit de lui prouver que G\ et H sont isomorphes ;
(b) soit
de lui prouver que G 2 et H sont isomorphes.
4° Patricia s ’exécute : {a) soit elle prouve que Gi et H sont isomorphes sans prouver que G 2 et H sont isomorphes ;
( b ) soit elle prouve que G 2 et H sont isomorphes sans prouver que G i et H sont isomorphes.
5° Patricia et Victor répètent les étapes 1 à f un nombre n de fois.
5.1
Preuves à divulgation nulle
11S
Si Patricia ne connaît pas l’isomorphisme entre G\ et G 2 , elle ne peut pas créer un graphe H qui soit isomorphe aux deux autres. Elle peut alors uniquement créer un graphe qui est isomorphe soit à G \, soit à G’2 mais pas aux deux. Comme dans l’exemple précédent, elle n’a que 50 % de chance de deviner quelle épreuve Victor lui fera subir à l’étape 4. Le protocole ne donne aucune information utile à Victor pour l’aider à découvrir l’iso morphisme entre G’i et G’2 . Comme Patricia engendre un nouveau graphe H à chaque tour du protocole, il n’y a aucune information pour Victor, même après plusieurs tours. 1 1 ne pourra pas découvrir l’isomorphisme entre Gi et G’2 à partir des réponses de Patricia. Victor reçoit une nouvelle permutation de H h chaque tour, ainsi que l’isomorphisme entre H et G\ ou bien Gi- Victor pourrait aussi bien générer cela lui-même. Le fait que Victor peut créer une simulation prouve que le protocole est à divulgation nulle.
Circuit hamiltonien Une variante de cet exemple fut présentée pour la première fois par Manuel B l u m [133]. Patricia connaît un chemin fermé continu, suivant les lignes, et qui passe par tous les points une fois et une seule. Un tel chemin est appelé circu it ham iltonien . Trouver un tel chemin est un autre problème difficile. Patricia dispose de cette information— qu’elle a certainement obtenue en construisant le graphe à partir d ’un certain circuit hamiltonien— et elle veut convaincre Victor qu’elle connaît un tel che min. Patricia connaît le circuit hamiltonien du graphe G. Victor connaît G mais pas le circuit hamiltonien. Patricia veut prouver qu’elle connaît ce circuit hamiltonien sans le dévoiler. Voici comment le protocole se déroule : 1° Patricia permute aléatoirement le graphe G. Elle déplace les points et change leurs étiquettes pour former un nouveau graphe, H . Comme G et H sont topologiquement isomorphes (c’est-à-dire, des graphes identiques), si elle connaît un circuit hamiltonien de G, elle peut alors facilement trouver un circuit hamil tonien de H . Si elle n’avait pas créé H elle-même, déterminer l’isomorphisme entre les deux graphes aurait été un problème autrement plus difficile ; cela peut prendre des années de temps de calcul. Elle chiffre ensuite H et obtient H ' 1.
2° Patricia donne une copie de H ' à Victor. 3° Victor demande à Patricia : (sl) soit de lui prouver que H ’ est le chiffrement d’un graphe isomorphe à G ;
(b ) soit de lui montrer un circuit hamiltonien de H . 4° Patricia s ’exécute : (a) soit elle prouve que H ’ est le chiffrement d’un graphe isomorphe à G en révélant la permutation et en déchiffrant tout, sans montrer un circuit hamiltonien de G ou H ; 1. Cela doit être un chiffrement probabiliste de chaque ligne connectant deu x points de H , c ’est à dire un 0 chiffré ou un 1 chiffré pou r chaque ligne dans H .
Chapitre 5
U4
Protocoles avancés
(b ) soit elle montre un cycle hamiltonien de H en ne déchiffrant que les lignes constituant le circuit hamiltonien, sans prouver que G et H sont topologiquement isomorphes.
5° Patricia et Victor effectuent les étapes 1 à 4 un nombre n de fois. Si Patricia est honnête, elle peut produire la preuve à l’étape 3 à Victor. Toutefois, si elle ne connaît pas un circuit hamiltonien de G, elle ne peut pas créer un graphe H qui lui permette de relever les deux défis. Le mieux qu’elle puisse alors faire est soit de créer un graphe isomorphe à G, soit de créer un graphe qui ait le même nombre de lignes et de points avec un circuit hamiltonien correct. Comme elle a 50 % de chance de deviner quelle épreuve Victor lui fera passer à l’étape 3, Victor peut répéter le protocole assez de fois pour se convaincre que Patricia connaît un circuit hamiltonien de G.
Preuves à divulgation nulle en parallèle Le protocole de base de preuve à divulgation nulle nécessite n échanges entre Patricia et Victor. Pourquoi ne pas les faire tous en parallèle : 1° Patricia utilise son information et n nombres aléatoires pour transformer le problème difficile en n problèmes isomorphes différents. Elle utilise ensuite son information et les nombres aléatoires pour résoudre les n nouveaux problèmes difficiles.
2° Patricia met en gage la solution aux n nouveaux problèmes. 3° Patricia dévoile les n nouveaux problèmes à Victor. Victor ne peut pas utili ser ceux-ci pour obtenir de l’information concernant le problème initial ou sa solution.
4° Pour chacun des nouveaux problèmes difficiles, Victor demande à Patricia : (a ) soit de lui prouver que les nouveau et ancien problèmes sont isomorphes ;
(b) soit
de lui montrer la solution qu’elle a mise en gage à l ’étape 2 et lui prouver que c ’est une solution du nouveau problème.
5° Patricia s ’exécute pour chacun des nouveaux problèmes difficiles. Malheureusement, ce n’est pas si simple. Ce protocole ne remplit pas les mêmes pro priétés de divulgation nulle que le protocole précédent. A l’étape (4), Victor peut choisir comme requêtes le résultat d ’une fonction de hachage à sens unique appliquée aux va leurs mises en gages à la première étape, rendant ainsi la transcription non simulable. Le protocole est toujours à divulgation nulle, mais d’une manière différente. Il a l’air sût en pratique, mais personne ne sait comment le prouver. Nous savons que dans cer taines circonstances, certains protocoles pour certains problèmes peuvent marcher en parallèle en restant à divulgation nulle [251, 112, 548, 618].
Preuves à divulgation nulle non interactives Christine ne peut pas être convaincue parce que le protocole est interactif et elle n’est pas partie prenante du protocole. Pour convaincre Christine, et toute autre personne qui serait intéressée, on a besoin d’un protocole non interactif.
5.1
Preuves à divulgation nulle
115
Des protocoles ont été inventés pour des preuves à divulgation nulle non interactives [1380, 204, 1381, 207]. Ces protocoles ne nécessitent aucune interaction; Patricia peut les publier et ainsi apporter la preuve à quiconque se donne la peine de la vérifier. Le protocole de base est similaire à celui des preuves à divulgation nulle en parallèle, mais une fonction à sens unique prend la place de Victor: 1° Patricia utilise son information et n nombres aléatoires pour transformer son problème difficile en n problèmes isomorphes différents. Elle utilise ensuite son information et les nombres aléatoires pour résoudre les n nouveaux problèmes difficiles.
2° Patricia met en gage les solutions aux n nouveaux problèmes difficiles. 3° Patricia utilise toutes ces mises en gage comme entrée à une fonction de ha chage à sens unique. Après tout, les mises en gage ne sont rien d’autre que des suites de bits. Elle sauve alors les n premiers bits du résultat de sa fonction de hachage à sens unique.
4° Patricia prend les n bits engendrés à l’étape S. Pour chaque ie nouveau pro blème difficile — suivant que le ie bit vaut 0 ou 1 — elle exécutera l’une des deux étapes suivantes : (a.)s’il vaut 0 , elle prouve que l’ancien et le nouveau problèmes sont iso morphes ;
(b ) s ’il vaut 1, elle dévoile la solution qu’elle a mise en gage à l’étape 2 et prouve que c ’est une solution du nouveau problème.
5° Patricia publie toutes les mises en gage de l’étape 2 ainsi que les réponses de l’étape 46°
Victor, Christine, ou toute autre personne intéressée, vérifie que les étapes 1 à 5 ont été exécutées correctement.
C’est étonnant : Patricia publie des données qui ne contiennent pas la moindre infor mation sur son secret et pourtant ces données peuvent être utilisées pour convaincre n’importe qui de l’existence du secret. On peut aussi utiliser le protocole pour des schémas de signature numérique en appliquant la fonction de hachage à sens unique à la fois aux messages initiaux et au message à signer. Cela marche parce que la fonction de hachage à sens unique se comporte comme un générateur aléatoire non biaisé de bits. Pour que Patricia puisse tricher, elle devrait être capable de prédire le résultat de la fonction de hachage à sens unique. Rappelezvous que si elle ne connaît pas la solution du problème difficile, elle ne peut répondre qu’à un des défis de l’étape 4 mais pas aux deux. Si elle arrivait à savoir d ’avance ce que la fonction de hachage à sens unique donnera, elle pourrait tricher. Toutefois, Patricia ne dispose d’aucun moyen pour forcer la fonction de hachage à sens unique à produire certains bits, ou pour deviner ceux qui seront produits. La fonction à sens unique remplace en fait Victor dans le protocole, en choisissant au hasard un des deux défis à l’étape 4. Pour un protocole non interactif, il doit y avoir bien plus d’itérations « défi-réponse ». Patricia, et non Victor, choisit les problèmes difficiles à l’aide de nombres aléatoires. Elle peut prendre différents problèmes, donc différents vecteurs de bits de mise en gage,
Chapitre 5
116
Protocoles avancés
jusqu’à ce que le résultat de la fonction de hachage à sens unique lui convienne. Pour le protocole interactif, 1 0 itérations sont suffisantes (cela donne une probabilité de 1 chance sur 2 10 = 1024 que Patricia puisse tricher). Pour le protocole non interactif ce n’est pas suffisant. Rappelons que Martin peut toujours relever un des deux défis à l’étape 4. Il peut essayer de deviner les défis qu’il devra relever à l’étape 4, effectuer les étapes 1 à 3, et regarder s’il a bien deviné. Dans le cas contraire, il peut répéter l’opération jusqu’à un coup de chance. Un ordinateur permet aisément de faire 1024 tentatives. Pour se prémunir de cette attaque exhaustive, les protocoles non interactifs requièrent 64 itérations, ou même 128, pour être valables. C ’est là tout l’intérêt d’utiliser une fonction de hachage à sens unique: Patricia ne peut pas prédire la sortie de la fonction car elle ne peut pas prédire son entrée. Les mises en gage utilisées en entrée ne sont connues qu’après avoir résolu les nouveaux problèmes.
Généralités B l u m a prouvé que tout théorème mathématique peut être converti en un graphe tel que la preuve du théorème est équivalente à un circuit hamiltonien. On trouvera dans [623] une preuve du cas général statuant que tout problème NP admet une preuve à divulgation nulle si l’on admet l’existence des fonctions de hachage à sens unique et donc de bons algorithmes de chiffrement. De cette façon toute preuve mathématique peut être convertie en une preuve à divulgation nulle. Grâce à cette technique, les chercheurs peuvent prouver au monde entier qu’ils connaissent la preuve d’un théorème particulier sans rien révéler de celle-ci. En effect, B l u m aurait pu publier ses résultats sans les dévoiler. On distingue aussi les preu ves à d iv u lg a tion m inim ale. Dans une preuve à divul gation minimale, les propriétés suivantes sont vérifiés :
- Patricia ne peut pas tromper V ictor: si Patricia ne connaît pas la preuve, ses chances de convaincre Victor sont négligeables. Victor ne peut pas tromper Patricia. Il n’a pas le moindre indice concernant la preuve, à part le fait que Patricia connaît la preuve. En particulier, Victor ne peut faire la démonstration à personne sans d ’abord en faire la preuve par lui-même à partir de zéro. Pour les protocoles de preuve à divulgation nulle, une propriété supplémentaire doit être vérifiée : - Victor n’apprend rien de Patricia qu’il ne puisse apprendre par lui-même mis à part le fait que Patricia connaît le secret. Il y a une différence notable entre les preuves à divulgation minimale et les preuves à divulgation nulle2. Ces concepts ont été présentés dans [628, 621, 624]. Des théories plus poussées, basées sur des concepts mathématiques différents ont été développées indépendamment dans [244, 323, 243]. 2. C e sujet dépasse le cadre de ce livre mais le lecteur intéressé pou rra faire b o n usage de la bibliographie à la fin de cet ouvrage.
5.2
Identification par preuve à divulgation nulle
117
Il y a de plus différentes sortes de preuves à divulgation nulle : - P arfaite. Il existe un simulateur qui donne des transcriptions ayant la même distribution que les transcriptions réelles3. - P ro b a b iliste . Il existe un simulateur qui donne des transcriptions ayant la même distribution que les transcriptions réelles, mis à part un nombre constant d ’ex ceptions. - C alcu la toire. Il existe un simulateur qui donne des transcriptions que l’on ne peut distinguer des transcriptions réelles. Un simulateur n’existe peut-être pas, mais on peut prouver que Victor n’apprendra jamais de la preuve une quantité polynomiale d ’information4.
- In u tile .
Au fil des années, pas mal de recherches ont été effectuées, tant sur le plan théorique que sur le plan pratique, sur les preuves à divulgation minimale et à divulgation nulle. Mike B u r m e s t e r et Yvo D e s m e d t ont inventé les p r e u v e s i n t e r a c t i v e s d i f f u s é e s , où un plaideur peut diffuser une preuve interactive à divulgation nulle à un grand groupe de vérificateurs [284]. Une horde de cryptographes a prouvé que tout ce qui peut être prouvé par une preuve interactive peut l’être aussi à l’aide d ’une preuve interactive à divulgation nulle [755, 122]. Un bon article général sur le sujet est [550]. Pour des détails mathématiques supplé mentaires, des variantes, des protocoles et des applications consultez [592, 621, 244, 323, 623, 123, 245, 1536, 1561, 242, 593, 619, 511, 594, 217, 113, 219, 833, 104, 950, 624, 480, 617, 620, 218, 1379, 76]. On a écrit énormément sur le sujet.
5.2
Identification par preuve à divulgation nulle
Dans le monde réel, nous utilisons des objets physiques pour prouver notre identité : carte d’identité, passeport, permis de conduire, cartes de crédits, etc. Les documents contiennent quelque chose qui les rattache à une personne : une photo, généralement, mais ce pourrait tout aussi bien être une empreinte digitale, une empreinte rétinienne ou une radiographie dentaire. Ne serait-ce pas intéressant de fane la même chose nu mériquement? L’utilisation des preuves à divulgation nulle comme preuve d ’identité fut proposée pour la première fois par Uriel F e i g e , Amos F i a t et Adi S h a m i r [568, 569]. La clef privée d’Alice devient fonction de son « identité ». Grâce à une preuve à divulgation nulle, elle prouve qu’elle connaît sa clef privée et ainsi par la même occasion prouve son identité. On trouvera des algorithmes dédiés à cela au paragraphe 23.11. Cette idée est vraiment efficace. Elle permet aux gens de prouver leur identité sans aucune évidence matérielle. Toutefois, ce n’est pas achevé. Voici quelques exemples d’abus. 3. C ’est le cas des problèm es du circuit ham iltonien et de l’ isom orphism e de graphes. 4. C ’est le cas de la preuve en parallèle.
118
Chapitre 5
Protocoles avancés
Le problème du grand maître aux échecs Voici comment Alice, qui ne connaît même pas les règles du jeu d’échecs, peut vaincre un grand maître. Elle décide d ’affronter Gary K A S P A R O V et Anatoly K a r p o v , en même temps et au même endroit mais dans des pièces séparées. Elle joue les blancs contre K a s p a r o v et les noirs contre K a r p o v Chaque grand maître ignore la présence de l’autre. K a r p o v , avec les blancs, joue son premier coup. Alice note le coup et va dans la pièce o ù se trouve K a s p a r o v . Elle joue alors avec les blancs exactement ce coup-là. K a s p a r o v joue ensuite son premier coup avec les noirs. Alice note le coup et va dans la pièce où se trouve K a r p o v et joue le coup de K a s p a r o v contre K a r p o v . Cela continue ainsi jusqu’à ce qu’elle gagne la partie contre l’un et perde contre l’autre (ou encore qu’elle termine les deux parties sur un match nul). En fait, K a s p a r o v joue contre K a r p o v , et Alice joue simplement le rôle d ’intermé diaire entre les joueurs, imitant les coups d ’un grand maître sur l’échiquier de l’autre. Toutefois si ni K a s p a r o v , ni K a r p o v n’est au courant de la présence de l’autre, chacun sera bien surpris par la qualité de jeu d’Alice. Ce type de supercherie peut être utilisé contre les identifications par preuve à divul gation nulle [483, 130]. Pendant qu’Alice prouve son identité à Martin, celui-ci peut prouver en même temps à Bernard qu’il est Alice.
La supercherie des mafiosi Lors d ’une présentation des techniques d ’identification par preuve à divulgation nulle, Adi S h a m i r dit [1419] : « Je pourrais aller à un magasin géré par la mafia un million de fois et ils ne seraient toujours pas capables de se faire passer pour moi. » Voici comment la mafia peut le faire. Alice mange au « Petit Bernard », un restaurant géré par la mafia. Christine fait ses emplettes chez « David Dior », une bijouterie de luxe. Bernard et Christine sont tous deux membres de la mafia et ils communiquent par une liaison radio secrète. Alice et David ne sont au courant de rien. A la fin du repas d ’Alice, quand elle s’apprête à payer et à prouver son identité à Bernard, celui-ci signale à Christine que la supercherie peut commencer. Christine achète quelques diamants très chers et s’apprête à prouver son identité à David. Ensuite, pendant qu’Alice prouve son identité à Bernard, celui-ci transmet par radio l’informa tion à Christine et Christine effectue le même protocole avec David. Quand David pose une question lors du protocole, Christine transmet la question à Bernard qui de mande à Alice. Quand Alice répond, Bernard transmet la bonne réponse à Christine. De fait, Alice ne fait que prouver son identité à David. Bernard et Christine ne font que s’interposer dans le protocole et font transiter les messages de l’un à l’autre. Quand le protocole se termine, Alice a prétendument acheté des diamants très chers (avec lesquels Christine disparaît dans la nature).
La supercherie des terroristes Si Alice est prête à collaborer avec Christine, elles peuvent aussi duper David. Dans ce protocole, Christine est une terroriste réputée. Alice l’aide à entrer dans le pays. David est l’officier d ’immigration. Alice et Christine sont connectées par une liaison radio secrète.
5.2
Identification par preuve à divulgation nulle
119
Quand David pose des questions à Christine dans le cadre du protocole de preuve à divulgation nulle, Christine les relaie par radio à Alice, qui y répond elle-même. Christine donne ces réponses-là à David. En réalité, Alice prouve son identité à David, avec Christine faisant l’office de voie de communication. Quand le protocole se termine, David pense que Christine est Alice et la laisse entrer dans le pays. Trois jours plus tard, Christine commet un acte terroriste.
Propositions de solutions Les supercheries des mafiosi et des terroristes sont toutes deux réalisables parce que les conspirateurs communiquent par une liaison radio secrète. Un moyen d’éviter ces fraudes consisterait à exiger que toutes les identifications aient lieu dans une cage de Faraday, qui bloque toutes les émissions électromagnétiques. Dans l’exemple des terroristes, cela garantirait à David que Christine ne reçoit pas ses réponses d’Alice. Dans l’exemple des mafiosi, Bernard pourrait construire une fausse cage de Faraday dans son restaurant mais le bijoutier David en aurait une vraie : Bernard et Christine ne pourraient pas communiquer. Pour résoudre le problème du grand maître aux échecs, il faudrait, obliger Alice à reter assise jusqu’à la fin de la partie. Thomas B e t h et Y vo D e s m e d t proposent une autre solution qui utilise des horloges précises [155]. Si chaque étape du protocole doit se dérouler à un instant donné précis, les conspirateurs n’auront pas de temps pour communiquer. Dans le cas de l’histoire des grands maîtres aux échecs, si chaque coup doit être joué quand l’aiguille des secondes passe par 0, alors Alice n’aura pas le temps de courir d ’une pièce à l’autre. Bernard et Christine n’auront pas le temps de se passer les questions et les réponses.
La supercherie aux identités multiples Il existe d’autres moyens de violer les preuves à divulgation nulle, décrits également dans [483, 130]. Dans certaines réalisations, l’identité de ceux qui enregistrent une clef publique n’est pas contrôlée. Ainsi, Alice peut avoir plusieurs clefs privées et donc plusieurs identités. Cela peut être très utile si elle a l’intention de frauder le fisc. Alice peut aussi commettre un crime et disparaître. Tout d ’abord, elle crée et publie plusieurs identités. Elle n’utilise pas l’une d ’entre elles. Ensuite, elle se sert de cette identité-là une fois et commet un crime de manière que celui qui l’a identifiée soit le témoin. Le témoin connaît l’identité de la personne qui a commis le crime, mais Alice ne se sert plus jamais de cette identité — on ne pourra pas retrouver sa trace. Pour éviter cela, il devrait exister une technique qui empêche chaque personne d’avoir plus d’une identité. Dans [130], les auteurs suggèrent l’idée « terrifiante » de bébés « infalsifiables » qui ne peuvent pas être clonés et qui ont un numéro unique gravé dans leur code génétique. Ils suggèrent aussi que chaque bébé devrait requérir une identité à sa naissance (de fait, ce serait les parents qui devraient faire les démarches car les bébés ont d’autres préoccupations). Il est facile de tricher dans ce cas : les parents pourraient requérir plusieurs identités à la naissance de l’enfant. A la fin, le caractère unique d ’un individu serait basé sur la confiance.
Chapitre 5
120
Protocoles avancés
Le prêt de passeports Alice veut aller en Argentine, mais le Gouvernement refuse de lui donner un visa. Christine propose de louer son identité à Alice (Bernard s’était proposé en premier mais cela posait des problèmes évidents). Christine vend sa clef privée à Alice et Alice part en Argentine prétendant être Christine. Non seulement Christine a été payée pour son identité mais encore elle dispose main tenant d ’un alibi parfait. Elle commet un crime pendant qu’Alice est en Argentine. « Christine » a prouvé son identité en Argentine : comment pourrait-elle commettre un crime chez elle? Bien sûr, Alice est libre de commettre des crimes également. Elle les commet avant son départ ou après son retour, de préférence près du domicile de Christine. D ’abord, elle s’identifie comme Christine (elle a la clef privée de Christine, c ’est donc facile pour elle), ensuite elle commet un crime et s’enfuit. La police vient alors appréhender Christine. Christine prétendra qu’elle a loué son identité à Alice mais qui pourrait croire une histoire aussi insensée? Le problème est qu’Alice ne prouve pas effectivement son identité, elle prouve qu’elle possède une information secrète. C ’est le lien entre cette information et la personne qui est faussé. La solution des bébés « infalsifiables » éviterait ce genre de fraudes, de même qu’un état policier dans lequel chaque citoyen devrait très fréquemment prouver son identité (à la fin de chaque jour, à chaque coin de rue, etc.). Les méthodes de biométrie— empreintes digitales, images rétiniennes, empreintes vocales, et ainsi de suite—peuvent aider à résoudre le problème.
Preuve d’appartenance à un groupe Alice veut prouver à Bernard qu’elle est membre d’une organisation super secrète, mais elle ne veut pas révéler son identité. Ce problème est proche de celui de prouver son identité et a été étudié [887, 907, 908, 1210, 1451]. Certaines solutions sont reliées au problème des signal;ures collectives (voir § 4.6).
5.3
Signatures en aveugle
Une caractéristique essentielle des protocoles de signature numérique est que le signa taire d ’un document sait toujours ce qu’il signe. C ’est très bien, sauf que nous voulons l’inverse. Il y a des situations où nous voulons que des gens signent un document sans jamais en voir le contenu. Ce n ’est pas un protocole très utile en tant que tel, mais nous l’utiliserons plus tard pour réaliser des protocoles de vote et de paiement numérique. Il y a moyen pour le signataire de « presque » savoir ce qu’il signe, sans savoir exactement. Mais commençons par le début.
Signatures en aveugle total Bernard est notaire. Alice veut qu’il signe un document mais elle ne veut pas qu’il ait la moindre idée de ce qu’il signe. Bernard ne s’intéresse pas au contenu du document,,
5.3
Signatures en aveugle
121
il ne fait que certifier que le document a été enregistré devant notaire à une certaine date. Voilà ce à quoi il consent : 1° Alice prend le document et le multiplie par une valeur aléatoire. Cette valeur aléatoire est appelée f a c t e u r d e c a m o u f l a g e . 2°
Alice envoie le document camouflé à Bernard.
3° Bernard signe le document camouflé. 4° Alice divise par le facteur de camouflage, retrouvant ainsi le document original signé par Bernard.
Ce protocole ne marche que si la fonction de signature et la fonction de multiplication sont commutatives. Si ce n’est pas le cas, il y a moyen de modifier le document au trement qu’en utilisant la multiplication. Les algorithmes mathématiques utiles sont présentés dans le paragraphe 23.12. Pour le moment, faites l’hypothèse que c’est une multiplication et que les mathématiques sont au point. Bernard peut-il tricher? Peut-il acquérir de l’information concernant le document qu’il signe? Si le facteur de camouflage est vraiment, aléatoire, il ne peut pas. Le document camouflé que Bernard signe à l’étape 2 ne ressemble en rien au document original d’Alice. Le document camouflé avec la signature de Bernard à l’étape 3 ne ressemble en rien au document signé à la fin de l’étape 4. Même si Bernard met la main sur le do cument avec sa signature après l’accomplissement du protocole, il ne peut pas prouver (à lui-même ou à toute autre personne) qu’il l’a signé dans le cadre de ce protocole-là. Il sait que sa signature est valide. Il sait qu’il (ou quelqu’un d ’autre avec sa clef pri vée) a signé ce document ; il peut, comme n’importe qui d’autre, vérifier la signature. Toutefois, il ne dispose d ’aucun moyen de corréler la moindre information qu’il a reçue durant le protocole avec le document signé. S’il signe un million de documents avec ce protocole, il n’a toujours pas de moyen de savoir dans quel cas il a signé tel document. Les propriétés des signatures en aveugle total sont : - La signature de Bernard sur le document est valide. La signature sert de preuve que Bernard a signé le document. Bernard sera convaincu qu’il a signé le docu ment. quand on le lui montrera. Les propriétés des signatures numériques présen tées au paragraphe 2 . 6 sont aussi valables. - Bernard ne peut pas faire le lien entre un document signé et l’acte de signature du document Même s’il garde une trace de toutes les signatures en aveugle qu’il a effectuées, il ne peut pas déterminer quand il a signé un document donné. Estelle, assise entre les deux, qui écoute tout le protocole, en sait, encore moins que Bernard.
Signatures en aveugle Avec le protocole de signature en aveugle total, Alice peut faire signer n’importe quoi par Bernard : « Bernard doit un million de francs à Alice », « Bernard est le père du premier-né d’Alice », « Bernard doit un sachet de dragées à Alice ». Les possibilités sont infinies. Nul besoin d’insister, ce protocole n’est pas particulièrement utile. Il existe toutefois un moyen pour Bernard de savoir ce qu’il signe, tout en maintenant les propriétés intéressantes de la signature en aveugle. Le cœur de ce protocole est la
Chapitre 5
122
Protocoles avancés
technique du « couper-et-choisir ». Considérons un exemple. De nombreuses personnes entrent dans le pays chaque jour et les services des douanes veulent s’assurer qu’elles ne font pas la contrebande de cocaïne. Les officiels peuvent fouiller tout le monde mais ils utilisent plutôt une solution probabiliste. Ils fouillent une personne sur dix qui entrent. Une personne sur dix voit ses effets personnels fouillés ; les neuf autres personnes passent sans autre formalité. Les contrebandiers chroniques échapperont au contrôle la plupart du temps mais ils ont 10 % de chance d’être attrapés. Et si le système pénal est efficace, la sanction pour avoir été pris une fois dépassera largement le gain des neuf autres fois. Si le service des douanes veut augmenter ses chances d ’attraper les contrebandiers, ils doivent fouiller plus de personnes. S’ils veulent diminuer leur chance, ils diminuent le nombre de personnes fouillées. En manipulant les probabilités, ils contrôlent l’efficadté du protocole pour attraper les contrebandiers. Le protocole de signature en aveugle utilise une méthode similaire. Bernard reçoit une grande pile de documents reliés. Il les o u v r e (i.e. les examine) tous sauf un et signe ce dernier. Imaginez que les documents camouflés sont dans des enveloppes. Le procédé de ca mouflage consiste à mettre le document dans une enveloppe. Le procédé de retrait du facteur de camouflage consiste à ouvrir l’enveloppe. Quand le document est dans l’en veloppe, personne ne peut le lire. Le document est signé grâce à une feuille de carbone dans l’enveloppe. Quand les signataires signent l’enveloppe, leurs signatures passent à travers la feuille de carbone et sont ainsi transférées sur le document. Le scénario suivant implique un groupe d’agents du contre-espionnage. Leur identité est secrète : même l’agence de contre-espionnage ne sait pas qui ils sont. Le directeur de l’agence veut donner à chaque agent un document signé attestant : « Le porteur de la présente signée (insérer le nom d’emprunt, de l’agent ici) bénéficie de l’immunité diplomatique totale. » Chaque agent a sa propre liste de noms d’emprunt donc l’agence
ne peut pas simplement distribuer des documents signés. Les agents ne veulent pas envoyer leur nom d ’emprunt à l’agence: l’ennemi peut avoir investi l’ordinateur de l’agence. En outre, l’agence ne veut pas signer en aveugle n’importe quel document que lui donne l’agent Un agent malin pourrait soumettre un message tel que: « L ’agent (nom) est retraité et a droit à une pension d’un million de francs par an. Signé: Monsieur le Président. » Dans ce cas un protocole de signature en aveugle est utile. Faisons l’hypothèse que chaque agent a n noms d ’emprunt possibles, qu’il a choisi lui-
même et que personne d ’autre ne connaît. Supposons également qu’il importe peu aux agents sous quel nom d’emprunt ils obtiennent l’immunité diplomatique. Enfin admet tons que l’ordinateur de l’agence s’appelle « Ordinateur Secret Central de l ’Agence de Renseignements » (O S C A R en d’autres termes). 1° L ’agent Bernard prépare n documents, chacun utilisant un nom d’emprunt dif férent, garantissant à cet agent l’immunité diplomatique.
2° Bernard camoufle chacun des documents avec un facteur de camouflage diffé rent.
3° Bernard envoie les n documents camouflés à OSCAR. 4° OSCAR choisit n — 1 documents au hasard et demande à Bernard le facteur de camouflage pour chacun de ces neuf messages.
5-4
Cryptographie à clef publique à base d’identification
123
5° Bernard envoie les bons facteurs de camouflage à OSCAR. 6°
OSCAR retire le facteur de camouflage des n — 1 documents et s ’assure qu’ils sont corrects.
7° OSCAR signe le n e document et l’envoie à Bernard. 8°
Bernard retire le facteur de camouflage et lit son nouveau nom d’emprunt: « Le Grand Blond avec une Chaussure Noire. » Le document signé lui procure l’immunité diplomatique totale sous ce nom.
Ce protocole résiste aux tricheries éventuelles de Bernard. Pour tricher, il devrait pré dire de façon sûre quel document OSCAR n’examinera pas. Ses chances sont de 1 sur n : pas très bonnes. OSCAR sait cela aussi et il est confiant quand il signe le ne document : celui qu’il n’a pas pu examiner. Avec ce document-là, le protocole est le même que le protocole précédent de signature en aveugle total, et il préserve toutes les propriétés d ’anonymat. Il est possible de rendre les chances pour Bernard de tricher avec succès aussi petites que nécessaires. A l’étape 4, OSCAR choisit au hasard n /2 documents et Bernard lui envoie les bons facteurs de camouflage correspondants à l’étape 5. À l’étape 7, OSCAR multiplie ensembles les documents restants et signe le tout. À l’étape 8 , Bernard re tire les facteurs de camouflage. La signature d’ OSCAR n’est valable que si les n /2 documents signés étaient identiques. Pour tricher, Bernard doit deviner quel est le sous-ensemble qu’OSCAR va choisir; ses chances de réussite sont bien moindre que lorsqu’il essaye de deviner le document qu’OSCAR n’examinera pas. Il y a un autre moyen pour Bernard de tricher. Il peut engendrer deux documents différents: un qu’OSCAR serait prêt à signer et un autre non. Ensuite, il trouve deux facteurs de camouflage tels que l’un appliqué au premier document et l’autre au se cond donnent le même document camouflé. De cette façon, si OSCAR demande à examiner le document, Bernard lui donne le facteur de camouflage qui le transforme en un document anodin. Si OSCAR ne demande pas à voir le document et le signe, Bernard utilise le facteur de camouflage qui transforme le document camouflé en do cument malveillant. Bien que cela soit théoriquement possible, les mathématiques des algorithmes particuliers utilisés pour ce protocole, rendent les chances de Bernard de trouver une telle paire de facteurs infiniment faibles. Nous en reparlons plus en détail dans le paragraphe 23.12.
Brevets C h a u m a posé des brevets sur différents types de signatures en aveugle (voir le ta bleau 5.1).
5.4
Cryptographie à clef publique à base d’identification
Alice veut envoyer un message confidentiel à Bernard. Elle ne veut se procurer sa clef publique dans un serveur de clefs; elle ne veut pas avoir à vérifier la signature d ’un troisième parti de confiance avec le certificat de sa clef publique; et elle ne veut même
Chapitre 5
124
T
Numéro 4 759 063 4 759 064 4 914 698 4 949 380 4 991 210
ab
.
Protocoles avancés
5.1 - Les brevets de signature numérique posés par Chaum
Date Titre 19/7/88 Systèmes 19/7/88 Systèmes 3 /3 /9 0 Systèmes 14/8/90 Systèmes 5/2/91 Systèmes
de de de de de
signature signature signature signature signature
en en en en en
aveugle aveugle aveugle aveugle aveugle
[324] sans anticipation [325] avec aperçu [329] avec retour de valeur [331] imprévisible [334]
pas enregistrer la clef publique de Bernard sur son propre ordinateur. Elle veut juste lui envoyer un message confidentiel. Les c r y p t o s y s t è m e s à b a s e d ’ i d e n t i f i c a t i o n 5 permettent de résoudre ce problème [1429]. La clef publique de Bernard est basée sur son nom et son addresse électronique (ou encore son numéro de téléphone, ou son addresse en ville, ou quoi que ce soit d’autre). Avec la cryptographie à clef publique classique, Alice a besoin d ’un certificat signé numériquement qui lie l’identité de Bernard à sa clef publique. Avec la cryptogra phie à clef publique à base d ’identification, la clef publique de Bernard est son identité. C ’est une idée vraiment séduisante, l’idée idéale dont on peut rêver pour un système de courrier électronique: si Alice connaît l’addresse de Bernard, elle peut lui envoyer du courrier en toute sécurité. Cela rend la cryptographie aussi transparente qu’il est possible. Le sytème est fondé sur Ivan qui fournit des clefs privées basées sur l’identité. Si jamais la clef d’Alice est compromise, elle doit changer un aspect de son identité pour avoir une autre clef. Le problème le plus sérieux est d ’élaborer un système qui ne laisse pas la possibilité à des utilisateurs malhonnêtes de s’unir pour créer une clef. Une grande part de travail a été faite sur les mathématiques sous-jacentes— la plupart au Japon— qui s’avèrent affreusement compliquées quand il s’agit de rendre le sytème sûr. De nombreuses solutions parmi celles proposées impliquent que Ivan choisisse un nombre aléatoire pour chaque utilisateur— ce qui à mon avis vient à l’encontre de l’idée même du système. Certains algorithmes décrits aux chapitres 19 et 20 peuvent s’utiliser à base d ’identification. Pour les détails algorithmiques et cryptographiques, se reporter à [198, 1429, 891, 1030, 1519, 1224, 1205, 909, 693, 675, 1138, 1031, 1520, 1544, 1552, 6 8 , 1218, 318, 319, 1553, 1547, 1551, 944, 1521, 750, 1238]. On trouvera un algorithme qui ne repose pas sur des nombres aléatoires dans [1043]. Le système introduit dans [1554, 1555, 1511] résiste aux attaques à clefs publiques choisies, de même que celui présenté dans [1550, 1548, 1549, 1003, 378, 1546]. Honnêtement, rien de ce qui a été proposé jusqu’à présent n’est à la fois réalisable et sûr.
5.5
Transfert inconscient
Le cryptographe Bernard essaie désespérément de factoriser un nombre n de 500 bits. Il sait que celui-ci est le produit de 5 nombres de 100 bits mais il n’en sait pas plus. (C ’est un problème sérieux pour Bernard. S’il ne peut pas retrouver la clef, il devra 5. Ces cryptosystèm es sont aussi qualifiés de systèmes sans partage interactif de clef.
5.5
Transfert inconscient
125
faire des heures supplémentaires et il va rater son poker à l’aveugle hebdomadaire avec Alice.) Alice passe alors par là : « Il se trouve que je connais un facteur du nombre » dit Alice, « et je te le donnerai pour cent francs. Cela fait un franc le bit. » Pour montrer qu’elle est sérieuse, elle utilise un schéma de mise en gage de bits et met en gage chaque bit individuellement. Bernard est intéressé, mais il n’a que 50 francs. Alice n’est pas prête à abaisser son prix et elle propose de vendre à Bernard la moitié des bits pour la moitié du prix. « Cela t ’évitera pas mal de boulot », dit-elle. « Mais comment puis-je être sûr que ton nombre est bien un facteur de n ? Si tu me montres le nombre et que tu me laisses vérifier que c ’est un facteur, alors je serai d’accord avec tes conditions », dit Bernard. Alice n’a pas l’intention de le suivre dans cette voie, ils sont donc dans une impasse. Alice ne peut pas convaincre Bernard que son nombre est un facteur de n sans le révéler et Bernard n’est pas prêt à payer 50 bits d’un nombre qui pourrait bien lui être inutile. Cette histoire empruntée à Joe K i l i a n [832], introduit le concept de t r a n s f e r t i n Alice transmet un groupe de messages à Bernard. Bernard reçoit un sousensemble de ces messages, mais Alice ignore quels sont ceux qu’il reçoit. Cependant, cela ne résout pas tout à fait le problème précédent. Après que Bernard a reçu une moitié aléatoire des bits, Alice doit encore le convaincre que les bits qu’elle envoie constituent un facteur de n en utilisant une preuve à divulgation nulle. Dans le protocole suivant, Alice va envoyer à Bernard un des deux messages. Bernard en recevra un et Alice ne saura pas lequel. c o n s c ie n t .
1
° Alice engendre deux paires « clef publique clef privée », soit 4 clefs au total. Elle envoie les deux clefs publiques à Bernard.
2° Bernard choisit une clef pour un algorithme à clef secrète (le DES par exemple). Il choisit une des clefs publiques d’Alice aléatoirement et chiffre sa clef DES avec cette dernière. Il envoie la clef chiffrée à Alice sans lui dire quelle clef publique il a utilisée pour la chiffrer.
3° Alice déchiffre la clef de Bernard avec ses deux clefs privées. Dans un des cas elle utilise la bonne clef et déchiffre avec succès la clef DES de Bernard. Dans l’autre cas, elle utilise la mauvaise clef et n’engendre rien d’autre qu’une suite de bits sans sens qui néanmoins n’en ressemble pas moins à une clef DES quelconque. Comme elle ne connaît pas le texte en clair correct, elle ignore quoi est quoi.
4° Alice chiffre ses deux messages chacun avec une des deux clefs DES qu’elle a engendré à l’étape précédente (une vraie et une sans sens) et envoie les deux résultats à Bernard.
5° Bernard reçoit l’un des messages d’Alice chiffré avec la bonne clef DES et l’autre message avec une clef factice. Bernard utilise sa clef DES pour déchiffrer les deux messages d’Alice mais il ne peut lire avec succès que l’un d’entre eux.
Chapitre 5
126
Protocoles avancés
À ce point, le transfert inconscient est terminé. Bernard a pu lire un des deux messages (celui chiffré avec sa clef DES) et Alice n’a aucun moyen de savoir lequel. Une étape supplémentaire est nécessaire pour qu’Alice ne puisse pas tricher. 1
° Après avoir terminé le protocole et quand les deux résultats possibles du trans fert sont connus, Alice doit donner à Bernard ses clefs privées afin qu ’il puisse vérifier qu’elle n’a pas triché. Après tout, elle pourrait avoir chiffré le même message avec les deux clefs à l’étape 4-
Dès lors, Bernard peut resconstituer le second message. Ce protocole résiste à une attaque d ’Alice car elle n ’a aucun moyen de savoir quelle est la bonne clef DES parmi les deux qu’elle a calculées. Le protocole résiste à une attaque de Bernard, car avant que le protocole ne soit terminé, il n’a aucun moyen d ’avoir les clefs privées d’Alice donc il ne peut pas calculer l’autre clef DES qui a été utilisée pour chiffrer l’autre message (celui des deux qu’il n’a pas pu lire). On pourrait penser que ce n’est qu’une méthode plus compliquée pour tirer à pile ou face par modem, mais ce protocole a des implications profondes quand il est utilisé au sein de protocoles plus compliqués. Bien sûr, rien n ’empêche Alice d ’envoyer deux messages totalement dénués de senr : « Gna, Gna » et « Cornichon ». Ce protocole garantit qu’Alice envoie à Bernard un des deux messages; il ne fait rien pour garantir que Bernard désire recevoir l’un d’entre eux. Il existe d ’autres protocoles de transfert inconscient décrits dans la littérature. Certains d ’entre eux sont non interactifs, ce qui signifie qu’Alice peut publier ses deux messages et que Bernard ne peut comprendre qu’un des deux. Il peut le faire lui-même, il n’a pas besoin de communiquer avec Alice pour cela [111]. Nombre de protocoles de ce chapitre utilisent le protocole de transfert inconscient. Personne n’a besoin de transfert inconscient en pratique, mais la notion est une brique élémentaire importante pour construire des protocoles plus compliqués. Cependant il y a plusieurs sortes de transfert inconscient: j ’ai deux secrets et vous en obtenez un, j ’ai n secret et vous en obtenez un, j ’ai un secret et vous l’obtenez qvec probabilité 1 / 2 , et ainsi de suite. Toutes les variantes sont équivalentes [250, 395, 399].
5.6
Signatures inconscientes
Honnêtement, je ne connais pas d’application pour cela, il en existe deux variantes [350] : 1
. Alice possède n messages différents. Bernard peut choisir un des n messages pour qu’Alice le signe, et Alice n ’aura aucun moyen de savoir quel message elle a signé.
2
. Alice possède un message. Bernard peut choisir une clef parmi n avec laquelle Alice va signer le message, et Alice ne pourra pas déterminer la clef elle aura utilisé.
C ’est une idée intéressante, je suis sûr qu’elle a son utilité quelque part.
5.7
Signature simultanée de contrat
5.7
127
Signature simultanée de contrat
Signature de contrat avec un arbitre Alice et Bernard veulent conclure un contrat. Ils se sont mis d’accord sur les termes du contrat mais aucun des deux ne veut signer sans que l’autre signe aussi. Face à face, c’est facile : ils signent ensemble. A distance, ils peuvent utiliser un arbitre. 1
° Alice signe mie copie du contrat et envoie le résultat à Ivan.
2° Bernard signe une copie du contrat et envoie le résultat à Ivan. 3° Ivan envoie un message à Alice et à Bernard indiquant à chacun que l’autre a signé le contrat.
4° Alice signe deux copies du contrat et les envoie à Bernard. 5° Bernard signe les deux copies du contrat et envoie une copie à Alice et en garde une pour lui-même. 6°
Alice et Bernard informent Ivan qu’ils ont chacun une copie du contrat signée par eux deux.
7° Ivan déchire les deux copies de contrat chacun avec une seule signature. Le protocole marche parce qu’Ivan empêche les deux parties de tricher. Si Bernard refusait de signer le contrat à l’étape 5, Alice pourrait demander à Ivan la copie du contrat déjà signée par Bernard. Si Alice refusait de signer à l’étape 4, Bernard pourrait faire de même. Quand Ivan indique qu’il a reçu les deux contrats à l’étape 3, Alice et Bernard savent tous deux qu’ils sont liés par le contrat. Si Ivan ne reçoit pas les deux contrats, il déchiffre celui qu’il a reçu et aucune partie n’est liée.
Signature simultanée de contrat sans arbitre (face à face) Si Alice et Bernard étaient assis face à face, ils pourraient signer le contrat de la manière suivante [1254] : 1° Alice signe avec la première lettre de son nom et passe le contrat à Bernard. 2° Bernard signe avec la première lettre de son nom et passe le contrat à Alice. 3° Alice signe avec la deuxième lettre de son nom et passe le contrat à Bernard. 4° Bernard signe avec la deuxième lettre de son nom et passe le contrat à Alice. 5° Cela continue ainsi jusqu’à ce qu’Alice et Bernard aient tous deux signé avec leurs noms en entier.
Si vous ignorez le défaut évident de ce protocole (Bernard a un nom plus long qu’Alice), cela marchera. Après avoir signé avec une seule lettre, Alice sait qu’aucun juge ne la considérera comme liée par les termes du contrat. Mais cette lettre est un acte de bonne volonté et Bernard répond avec un acte similaire de bonne volonté. Après que chaque participant a signé avec quelques lettres, un juge sera certainement convaincu que les deux parties ont signé le contrat. Toutefois, les détails sont obscurs. Sûrement qu’ils ne sont pas liés après la première lettre ; mais ils le sont certainement dès qu’ils ont signé leur nom entier. A quel point du protocole deviennent-ils liés?
Chapitre 5
128
Protocoles avancés
Après avoir signé avec la moitié de leurs noms? Les deux tiers de leurs noms? Les trois quarts? Comme ni Alice ni Bernard ne sont certains de l’instant à partir duquel ils sont liés, ils craignent un peu, à chaque instant, d ’être liés. Cela n’a pas de sens pour Bernard de dire : « Tu as signé avec quatre lettres et moi je n’ai signé qu’avec trois lettres. Tu es liée et moi pas. » Il n’y a pas de raison que Bernard ne continue pas le protocole. Plus longtemps ils continuent, plus grande est la probabilité qu’un juge les considèrent comme liés. Une fois de plus, il n ’y a aucune raison de ne pas continuer le protocole. Après tout, ils voulaient tous deux signer le contrat ; ils ne voulaient simplement pas signer l’un avant l’autre.
Signature simultanée de contrat sans arbitre ( à distance) Ce protocole exploite le même type d’incertitude [120]. Alice et Bernard alternent les petits pas vers un contrat signé jusqu’à ce qu’ils aient tous deux signé. Dans ce protocole, Alice et Bernard échangent une série de messages signés de la forme : « J’accepte de me considérer comme lié(e) au contrat avec une probabilité p. » Celui qui reçoit un tel message peut le montrer à un juge et, avec une probabilité p, le juge considérera le contrat comme signé. 1
° Alice et Bernard conviennent d’une date à laquelle le protocole de signature devra être terminé.
2° Alice et Bernard décident d’une différence de probabilités à utiliser. Par exemple, Alice peut décider qu’elle ne veut pas être liée avec une probabilité de 2 % supérieure à la probabilité de Bernard. Appelons A la différence de probabilité d’Alice et B celle de Bernard.
3° Alice envoie un message à Bernard avec p = A. 4° Bernard envoie un message à Alice avec p = A + B . 5° Soit p' la probabilité du message qu’Alice a reçu de Bernard à l’étape précédente. Alice envoie à Bernard un message signé avec le minimum de p = p' + A ou p =l. 6
° Soit p' la probabilité du message que Bernard a reçu d ’Alice à l’étape précédente. Bernard envoie à Alice un message signé avec le minimum de p = p' + B ou p= 1.
7° Alice et Bernard continuent à alterner les étapes 5 tous deux reçu le message avec p = 1 , ou jusqu’à l’étape 1 soit dépassée.
et 6 jusqu’àce qu’ilsaient ce queladate convenue à
Tout au long du déroulement du protocole, Alice et Bernard consentent à être liés par le contrat avec une probabilité de plus en plus grande. Par exemple, le premier message d’Alice pourrait indiquer qu’elle se considère comme liée avec une probabilité de 2 %. Bernard pourrait répondre qu’il est lié avec une probabilité de 3 %. Le message suivant d’Alice pourrait indiquer qu’elle est liée avec une probabilité de 4 %, et ainsi de suite jusqu’à ce qu’ils soient liés avec une probabilité de 1 0 0 %. Si Alice et Bernard terminent tous deux le protocole, tout va bien. Si la date d’échéance du protocole arrive, chaque participant peut montrer le contrat à un juge avec le dernier
Signature simultanée de contrat
5.7
129
message signé de l’autre participant. Le juge choisit simplement une valeur aléatoire entre 0 et 1. Si la valeur est inférieure à la probabilité que l’autre participant a signé, alors les parties sont liées. Si la valeur est plus grande que la probabilité, alors les parties ne sont pas liées6. C ’est cela que l’on entend par être lié au contrat avec une probabilité p. C’est le protocole de base, mais il peut y avoir d ’autres complications. Si Alice com mence à signer des messages avec des incréments de plus en plus faibles de probabilité, Bernard peut répondre dans le même sens. Le juge peut trancher en l’absence d’un des participants. La décision du juge lie soit les deux parties, soit aucune ; il n’y a pas de situations où l’une des parties est liée et l’autre pas. Aussi longtemps que l’une des parties est disposée à avoir une probabilité légèrement supérieure d ’être liée à l’autre (peut importe la petitesse de l’écart), le protocole se terminera.
Signature simultanée de contrat sans arbitre (en utilisant la cryptographie) Ce protocole cryptographique utilise la même approche des petits pas [531]. Le DES est utilisé pour la description du protocole bien que tout algorithme à clef secrète conviendrait. 1
° Alice et Bernard choisissent chacun aléatoirement 200 clefs DES groupées par paires. Il n’y a rien de spécial à propos de ces paires ; elles sont juste appariées pour les besoins du protocole.
2° Alice et Bernard engendrent chacun n paires de messages, Gi et Di : « Ceci est la moitié gauche de ma ie signature. » et « Ceci est la moitié droite de ma ie signature. », par exemple. L ’identificateur i va de 1 à n. Les messages comprendront aussi probablement une signature numérique du contrat comme définie précédemment, et une datation. Le contrat est considéré comme signé si l’autre participant peut produire les deux moitiés Gi et Di d’une paire de signatures.
3° Alice et Bernard chiffrent tous deux leurs paires de messages avec chaque paire de clefs D ES, le message gauche avec la clef gauche de la paire, et le message droit avec la clef droit de la paire. 4° Alice et Bernard s ’envoient réciproquement leur paquet de 2n messages chiffrés, en s ’assurant que l’autre sait que tel message appartient à telle moitié de telle paire.
5° Alice et Bernard s ’envoient réciproquement toutes les paires de clefs en utilisant le protocole de transfert inconscient pour chaque j>aire. C ’est-à-dire qu’Alice envoie à Bernard soit la clef utilisée pour chiffrer la moitié gauche, soit la clef utilisée pour chiffrer la moitié droite, indépendamment, pour chacune des n paires. Bernard fait de même. Ils peuvent alterner l’envoi des moitiés, ou l’un peut envoyer les n et puis l’autre faire de même — peu importe. Maintenant, Alice et Bernard ont tous deux une clef de chaque paire mats chacun ignore quelles sont les clefs en possession de l’autre. 6. Le ju ge enregistre la valeur au cas où il y aurait d ’autres litiges liés à ce contrat-
Chapitre 5
130 6°
Protocoles avancés
Alice et Bernard déchiffrent tous deux les moitiés de messages comme ils peuvent, en utilisant les clefs qu’ils ont reçues. Ils s ’assurent que les messages déchiffrés sont corrects.
7° Alice et Bernard s ’envoient réciproquement les premiers bits des 2n clefs DES. 8°
Alice et Bernard répètent l’étape 7 pour les deuxièmes bits des 2n clefs DES, les troisièmes bits, et ainsi de suite, jusqu’à ce que toutes les clefs DES aient été transférées.
9° Alice et Bernard déchiffrent les moitiés restantes des paires de messages et le contrat est signé.
Pourquoi Alice et Bernard doivent-ils faire tout cela? Supposons qu’Alice veuille tricher et voyons ce qui se passe. Aux étapes 4 et 5, Alice peut perturber le protocole en envoyant à Bernard des chaînes de bits sans sens. Bernard découvrirait cela à l’étape 6 , quand il essaierait de déchiffrer la moitié qu’il a reçue, quelle que soit cette moitié. Bernard peut alors arrêter sans dommage, puisqu’Alice ne peut déchiffrer aucune des paires de messages de Bernard. Si Alice était très maligne, elle pourrait ne perturber que la moitié du protocole. Elle pourrait envoyer la moitié gauche de chaque paire correctement et envoyer du charabia comme moitié droite. Bernard n’a que 50 % de chance de recevoir la moitié droite et donc Alice peut tricher la moitié du temps. Toutefois, cela ne marche que s’il n’y a qu’une paire de clefs. S’il n’y avait que deux paires, ce type de supercherie pourrait réussir dans 25 % des cas. C ’est pour cela que n doit être grand. Alice doit anticiper correctement le résultat de n protocoles de transfert inconscient; Alice n’a que 1 chance sur 2” de réussir cela. Si n = 10, Alice a une chance sur 1024 de rouler Bernard. Alice peut aussi envoyer des bits aléatoires à Bernard à l’étape 8 . Peut-être que Bernard ne saura pas qu’elle lui a envoyé des bits aléatoires jusqu’à ce qu’il reçoive la clef complète et qu’il essaie de déchiffrer les moitiés de messages. Mais une fois de plus, les probabilités sont du côté de Bernard. Il a déjà reçu la moitié des clefs et Alice ne sait pas quelles sont ces moitiés. Alice est sûre de lui envoyer un bit erroné pour une des clefs qu’il a déjà reçues, et lui, il saura immédiatement qu’Alice essaie de le rouler. Peut-être qu’ Alice va continuer l’étape 8 jusqu’à ce qu’elle ait suffisamment de bits des clefs pour casser les messages DES et ensuite arrêter de transmettre les bits. Le DES a une longueur de clef de 56 bits. Si elle reçoit 40 des 56 bits, elle ne doit essayer que 2 16 (65 536) clefs pour pouvoir lire le message une tâche qui est certainement à la portée d ’un ordinateur. Mais Bernard aura exactement le même nombre de bits des clefs d ’Alice (ou un bit de moins tout au plus) et donc il pourra faire la même chose. Alice n’a pas d’autre choix que de poursuivre le protocole. Le point principal est qu’Alice doit jouer le jeu honnêtement, car les chances de rouler Bernard sont bien trop minces. A la fin du protocole, les deux parties ont n paires de messages signés, chacune d ’elles suffit pour une signature valable. Alice a néanmoins la possibilité de tricher; elle peut envoyer des messages identiques à Bernard durant l’étape 5. Bernard ne pourra s’en rendre compte qu’à la fin du protocole, mais il peut utiliser une transcription du protocole pour convaincre un juge de la duplicité d ’Alice. Il y a deux faiblesses dans les protocoles de ce type [120] : Premièrement, il y a un problème si l’une des parties a nettement plus de puissance de calcul que l’autre. Si, par exemple, Aüce peut casser l’algorithme plus rapidement que
5.8
Courrier électronique certifié
131
Bernard, alors elle peut arrêter plus tôt de transmettre des bits à l’étape 8 et calculer elle-même les clefs de Bernard. Bernard qui ne peut pas faire la même chose en un temps raisonnable ne sera pas content. Deuxièmement, il y a un problème si une des parties arrête le protocole plus tôt. Si Alice arrête abruptement le protocole, tous deux devront faire le même effort pour faire les calculs, mais Bernard n’a pas de réel recours légal. Si, par exemple, le contrat spécifie qu’il doit faire quelque chose dans une semaine, et qu’ Alice arrête le protocole en un point où Bernard devrait consacrer un an à calculer pour qu’ Alice soit vrai ment engagée, il y aurait alors un problème. La vraie difficulté ici est qu’il n’y a pas d’échéance à court terme à laquelle le processus doit se terminer comme il se doit : soit les deux parties liées, soit aucune. On retrouve ces problèmes avec les protocoles décrits aux paragraphes 5.8 et 5.9.
5.8
Courrier électronique certifié
Le même protocole de transfert inconscient simultané - utilisé pour la signature de contrats — peut être utilisé pour certifier du courrier électronique [531]. Faites l’hy pothèse qu’Alice veut envoyer un message à Bernard mais elle ne veut pas qu’il le lise sans avoir envoyé un accusé de réception signé. Les postiers le font couramment mais la même chose peut être faite avec la cryptographie. Whitfield D i f f i e aborde pour la première fois ce problème dans [488]. A première vue, le protocole de signature simultanée de contrats peut faire cela. Alice simplement chiffre son message avec une clef DES. Sa moitié du protocole peut être quelque chose comme : « Ceci est la moitié gauche de la clef DES : 32F5. » La moitié du protocole pour Bernard serait quelque chose comme : « Ceci est la moitié gauche de mon accusé de réception. » Tout le reste serait de même. Pour voir pourquoi cela ne marche pas, rappelez-vous que le protocole dépend du fait que le transfert inconscient de l’étape 5 maintient l’honnêteté des deux parties. Chacun des participants sait qu’il envoie à l’autre une moitié valide mais personne ne sait laquelle. Ils ne trichent pas à l’étape 8 parce que les chances de réussite sont ridicules. Si Alice envoie non pas un message mais une moitié de clef DES, Bernard n’a aucun moyen de vérifier la validité de la clef DES à l’étape 6 . Alice peut toujours vérifier la validité de l’accusé de réception de Bernard donc celui-ci est obligé d’être honnête. Alice peut en toute impunité envoyer à Bernard une fausse clef DES et celuici ne s’en rendra pas compte avant qu’Alice en reçoive l’accusé de réception. Bonne chance Bernard ! Eviter cela nécessite quelques aménagements du protocole : 1° Alice chiffre son message en utilisant une clef DES aléatoire et envoie le ré sultat à Bernard. 2°
Alice engendre n paires de clefs DES. La première clef de chaque paire est engendrée aléatoirement; la seconde clef de chaque paire est le ou exclusif de 1a. première clef et de la clef de chiffrement du message.
3° Alice chiffre un message factice avec chacune de ses 2n clefs. 4° Alice envoie à Bernard tous les messages chiffrés en s ’assurant qu’il sache que tel message est telle moitié de telle paire.
132
Chapitre 5
Protocoles avancés
5° Bernard, engendre n paires de clefs DES aléatoires. 6°
Bernard engendre une paire de messages qui forment un accusé de réception valide. « Ceci est la moitié gauche de mon accusé de réception » et « Ceci est la moitié droite de mon accusé de réception » sont de bons candidats avec l'ad jonction d’un certain type de validation. Il fait n paires d’accusés de réception, chacune numérotée. Comme dans le protocole précédent, l’accusé de réception est considéré comme valide si Alice peut produire les deux moitiés d’un accusé de réception (avec le même numéro) et toutes ses clefs de chiffrement.
7° Bernard chiffre chacune de ses paires de messages avec les paires de clef DES, la i e paire de messages avec la ie paire de clefs, le message gauche avec la clef gauche de la paire et le message droit avec la clef droite de la paire. 8°
Bernard envoie son paquet de messages à Alice en s ’assurant qu’Alice sait que tel message est telle moitié de telle paire.
9° Alice et Bernard s ’envoient réciproquement chaque paire de clefs en utilisant le protocole de transfert inconscient. En d’autres termes, Alice envoie à Bernard soit la clef utilisée pour chiffrer le message gauche, soit la clef utilisée pour chiffrer le message droit, pour chacune des n paires. Bernard fait de même. Ils peuvent soit alterner les envois de moitiés, soit envoyer les n d’un coup, peu impoile. Maintenant, Alice et Bernard ont une clef de chaque paire mais ni l’un ni l ’autre ne sait ce que l’autre a reçu.
10° Alice et Bernard déchiffrent les moitiés comme ils peuvent et s ’assurent de la validité des messages déchiffrés.
11° Alice et Bernard s ’envoient réciproquement le premier bit des n clefs DES. (S’ils s ’inquiètent de la présence éventuelle d’Estelle capable de lire le courrier, alors ils doivent chiffrer la transmission entre eux.)
12° Alice et Bernard répètent l’étape 11 pour le deuxième bit des 2n clefs DES, le troisième bit, et ainsi de suite jusqu’à ce que tous les bits de toutes les clefs
DES aient été transmis. 13° Alice et Bernard déchiffrent les moitiés restantes des paires de messages. Alice a un accusé de réception valide de Bernard et celui-ci peut appliquer le ou exclusif à n’importe quelle paire de clefs pour retrouver la clef de chiffrement du message d’origine.
Les étapes 5 à 8 pour Bernard et les étapes 9 à 12 pour Alice et Bernard sont les mêmes que pour le protocole de signature de contrats. La différence se marque par les messages factices chiffrés d’Alice. Ds donnent à Bernard un moyen de vérifier les transferts inconscients d’Alice à l’étape 1 0 , qui oblige Alice à être honnête aux étapes 11 à 13. Et tout comme pour le protocole de signature simultanée de contrat, une moitié gauche et une moitié droite d ’une des paires de messages d’Alice sont toutes deux nécessaires pour terminer le protocole. A
5.9
Echange simultané de secrets
Alice connaît un secret A ; Bernard connaît un secret B . Alice est disposée à dire A à Bernard si Bernard lui dit B . Bernard est disposé à dire B à Alice si Alice lui dit A. Le
5.9
Échange simultané de secrets
133
protocole suivant peut être observé dans une cours d ’école, il ne marche manifestement pas: 1° Alice : « Je te le dirai si tu me le dis en premier. » 2° Bernard : « Je te le dirai si tu me le dis en premier. » 3° Alice : « Non, toi en premier. » 4° Bernard: « A h ! bon. » (Bernard chuchote dans l’oreille d’Alice.) 5° Alice : « Ha ! Ha ! Je ne te dis rien. » 6°
Bernard : « C ’est pas juste. »
La cryptographie peut le rendre équitable. Les deux protocoles précédentssont des réalisations d ’un protocole plus général qui permet à Alice et à Bernardd ’échanger simultanément des secrets [531]. Plutôt que de redonner tout le protocole, voici ce qu’il faut changer au protocole de courrier numérique certifié : Alice effectue les étapes 11 à 5 en utilisant A comme message. Bernard fait les mêmes étapes en utilisant B comme message. Alice et Bernard effectuent le transfert incons cient de l’étape 1 0 , déchiffrent les moitiés comme ils peuvent à l’étape 1 1 , et effectuent les itérations des étapes 1 2 et 13. S’ils sont inquiets d’une présence éventuelle d ’Estelle, ils peuvent chiffrer leurs messages. Finalement, Alice et Bernard déchiffrent tous deux les moitiés restantes des paires de messages et effectuent le ou exclusif de n’importe quelle paire de clefs pour retrouver la clef de chiffrement du message initial. Ce protocole permet à Alice et Bernard d’échanger simultanément des secrets, mais il ne dit rien du tout de la qualité des secrets échangés. Alice peut promettre à Bernard la solution du labyrinthe du Minotaure mais lui envoyer la carte du métro de Boston. Bernard recevra le secret d ’Alice peu importe la nature de celui-ci. On trouvera d’autres protocoles dans [1298, 202, 1001, 1528, 706, 755, 263, 362, 418].
Chapitre 6
Protocoles ésotériques 6.1
Elections sûres
À moins qu’il n’y ait un protocole qui évite la tricherie et qui garantisse la confiden tialité, le vote informatique ne sera jamais utilisé pour des élections grandeur nature. Le protocole idéal a au minimum les 6 caractéristiques suivantes : 1. Seules les personnes autorisées à voter peuvent voter. 2. Personne ne peut voter plus d’une fois. 3. Personne ne peut déterminer pour qui quelqu’un d ’autre a voté. 4. Personne ne peut dupliquer le vote de quelqu’un d ’autre. (Il s’avère que cette exigence est la plus difficile à remplir.) 5. Personne ne peut modifier le vote de quelqu’un d ’autre sans être découvert. 6.
Tous les votants peuvent vérifier que leur vote a bien été pris en compte dans le décompte final.
De plus, certains schémas de vote pourraient ajouter l’exigence : 7. Tout le monde sait qui a voté et qui n’a pas voté. Avant d’aborder les protocoles compliqués qui ont ces caractéristiques, voyons quelques protocoles simplistes qui ne les ont pas.
Protocole de vote simpliste n° 1 1° Tous les votants chiffrent leur vote avec la clef publique de l’Autorité Centrale de Décompte (Â C D ). 2°
Tous les votants envoient leur vote à Z’A C D .
3° L ’A C D déchiffre les votes, les compte et rend les résultats publics.
Chapitre 6
136
Protocoles ésotériques
Ce protocole a des défauts à chaque point. L’A C D n’a aucune idée d ’où viennent les votes, et donc elle ne sait pas si les votes sont émis par des votants autorisés ou pas. Elle n’a pas la moindre possibilité de détecter si les votants votent plus d ’une fois. Du côté des avantages, personne ne peut modifier le vote de quelqu’un d ’autre, mais personne n’essaierait de le faire quand c’est tellement plus facile de voter un nombre infini de fois pour forcer le résultat de son choix.
Protocole de vote simpliste n° 2 1° Tous
lesvotants
signent leur vote avec leur clef privée.
2°
Tous
lesvotants
chiffrent leur vote signé avec laclef publique
3°
Tous
lesvotants
envoient leur vote à Z’A C D .
4°
L ’A C D déchiffre résultats publics.
les votes, vérifie les signatures,décompte les
de Z’A C D .
votes et rend les
Ce protocole satisfait les propriétés ( 1 ) et ( 2 ) : seuls les votants autorisés peuvent voter et personne ne peut voter plus d ’une fois. Pour cela, l’A C D doit garder une trace des votes reçus à l’étape 3. Les votes sont signés avec la clef privée des votants donc l’ACD sait qui a voté, qui n’a pas voté et combien de fois chaque votant a voté. Si un vote signé par un votant non autorisé arrive — ou un vote signé par un votant qui a déjà voté — l’A C D l’ignore. De plus, personne ne peut modifier le vote d’autrui même s’il l’intercepte à l’étape 2 grâce à la signature numérique. Le défaut de ce protocole est que la signature est attachée au vote et qu’ainsi l’ACD sait qui a voté pour qui. Le chiffrement des votes avec la clef publique de l’ACD empêche quiconque écoute le protocole de déterminer qui vote pour qui, mais ce n’est pas suffisant. C ’est comme si un assesseur de bureau de vote regardait par-dessus votre épaule dans l’isoloir. Les deux exemples suivants montrent à quel point il est difficile de remplir ne serait-ce que les trois premières exigences d ’un protocole de vote sûr.
Vote avec signatures en aveugle Ce que nous devons faire c ’est d ’une certaine façon dissocier le vote du votant tout en maintenant l’authentification. C ’est exactement ce que réalise le protocole de signature en aveugle. 1° Tous les votants engendrent dix ensembles de messages, chaque ensemble contient un vote valide pour chaque vote possible (par exemple, si le vote est une question optionnelle : « oui » ou « non », chaque ensemble contient deux votes, un pour « oui » et l’autre pour « non »). Chaque message contient éga lement un numéro de série engendré aléatoirement suffisamment grand pour éviter les collisions avec les autres votants.
2° Tous les votants camouflent individuellement tous les messages (voir § 5.3) et envoient le résultat à Z’A C D . 3° L ’A C D vérifie dans sa base de données pour être sûre que des votants n’ont pas déjà auparavant soumis des votes camouflés pour leur signature. Elle ouvre neuf des dix ensembles de messages et vérifie qu ’ils ont été faits dans les règles.
6.1
Élections sûres
137
Ensuite, elle signe individuellement chaque message dans le dixième ensemble. Enfin, elle les renvoie aux votants et enregistre les noms des votants dans sa base de données.
4° Les votants dévoilent les messages pour donner un ensemble de votes signés par TA C D . (Ces votes sont signés mais non chiffrés, donc les votants peuvent aisément voir quel vote est « oui » et quel vote est « non ».)
5° Les votants choisissent l’un des votes ( O Démocratie !) et chiffrent celui-ci avec la clef publique de l’A C D . 6°
Les votants envoient leur vote.
7° L ’A C D déchiffre les votes, vérifie les signatures, vérifie dans sa base de don nées pour des numéros de série redondants, enregistre le numéro de série, et décompte les voix. Elle publie les résultats du vote avec tous les numéros de série et leur vote associé.
Un votant malveillant, appelons-le Martin, ne peut pas tricher dans ce système. Le protocole de signature en aveugle garantit que son vote est unique. S’il essaie d ’envoyer le même vote deux fois, l’A C D détectera le numéro de série redondant à l’étape 7 et rejettera le second vote. S’il essaie d ’obtenir plusieurs votes signés à l’étape 2, l’A C D découvrira cela à l’étape 3. Martin ne peut pas engendrer des votes factices car il ne connaît pas la clef privée de l’autorité. Il ne peut pas intercepter et modifier les votes d’autres votants pour les mêmes raisons. La technique « couper et -chosir » utilisée à l’étape 3 sert à assurer l'unicité des votes. Sans cette étape, Martin pourrait créer un ensemble de votes identiques en tout point sauf le numéro de série, et réussir à les faire tous valider. Une A C D malintentionnée ne peut pas déterminer la façon de voter des individus. Comme le protocole de signature en aveugle empêche l’autorité de voir les numéros de série avant qu’ils soient émis, l’A C D ne peut pas faire le lien entre un vote camouflé qu’elle signe et le vote finalement émis. La publication de la liste des numéros de série et de leur vote associé permet à tous les votants de vérifier que leur vote a bien été pris en compte. Il y a encore des défauts. Si l’étape 6 n’est pas anonyme et si l’A C D peut enregistrer qui a envoyé tel vote, alors elle peut déterminer qui a voté pour qui. Toutefois, si elle reçoit les votes dans une urne scellée et qu’elle les décompte plus tard, elle ne peut pas. De plus, bien que l’A C D ne puisse pas relier les votes aux individus, elle peut engendrer un grand nombre de votes valides signés et tricher en les soumettant elle même. Et si Alice se rend compte que l’ A C D a changé son vote, elle n’a pas les moyens d ’en faire la preuve. Il existe un protocole de ce type qui tente de corriger ces défauts [1204, 1372].
Vote avec deux autorités centrales Une solution est de répartir le pouvoir de l’A C D en deux parties. Aucune des deux parties n’a assez de pouvoir pour tricher de son propre chef. Le protocole suivant utilise une Autorité Centrale de Légitimation (A C L ) pour au thentifier les votants et une A C D séparée pour compter les votes [1375]. 1° Tous les votants envoient un message à l’A CL demandant un numéro de vali dation.
Chapitre 6
138
Protocoles ésotériques
2° L 'ACL renvoie aux votants un numéro de validation aléatoire. L 'ACL main tient une liste des numéros de validation. L A C L maintient également une liste des destinataires des numéros de validation, au cas où ils essaieraient de voter à nouveau.
3° L A C L envoie la liste des numéros de validation à Z’A C D . 4° Tous les votants choisissent un numéro d’identification individuel aléatoire. Ils créent un message avec leur numéro d’identification, le numéro de validation qu’ils ont reçu et leur vote v. Ils envoient le message à l’A C D .
5° L 'A C D compare le numéro de validation avec la liste qu’elle a reçue de Z'ACL à l’étape 3. Si le numéro de validation y figure, Z'ACD le biffe (pour empêcher quiconque de voter deux fois). L ’A C D ajoute le numéro d’identification à la liste des gens qui ont voté pour un candidat donné et ajoute un au décompte. 6°
Après que tous les votes ont été reçus, Z’A C D publie le résultat ainsi que les listes des numéros d’identification et pour qui leur propriétaire a voté.
Un avantage de ce système est que tous les votants peuvent regarder la liste des nu méros d ’identification et trouver le leur. Cela leur prouve que leur vote a été pris en compte. Bien sûr, tous les messages circulant entre les différents participants du pro tocole doivent être chiffrés et signés pour éviter que quelqu’un puisse se faire passer pour quelqu’un d ’autre et pour éviter les interceptions. L’A C D ne peut pas modifier les votes parce que tous les votants vont rechercher leur numéro d ’identification. Si un votant ne le trouve pas ou le trouve dans une autre liste que celle pour laquelle il a voté, il saura immédiatement qu’il y a eu tricherie. L’ACD ne peut pas trafiquer l’urne parce que l’A C L surveille. L ’A C L sait combien de votants ont été validés ainsi que leurs numéros de validation. Toute modification de l’un ou l’autre est immédiatement détectée. Martin qui n’est pas un votant autorisé, peut essayer de tricher en devinant un numéro de validation valide. La probabilité de succès de cette attaque peut être minimisée en rendant le nombre de numéros de validation possibles nettement plus grand que le nombre de numéros de validation effectivement émis : un million de nombres de 100 chiffres par exemple. Bien sûr, les numéros de validation doivent être engendrés aléatoirement. Malgré cela, l’A C L fait, en quelque sorte, toujours autorité. Elle peut valider des votants non autorisés. Elle peut valider des votants légitimes plusieurs fois. Le risque peut être minimisé en obligeant l’A C L à publier la liste des votants validés (mais pas leur numéro de vaüdation). Si le nombre de votants sur cette liste est inférieur au nombre de votes comptés, il y a anguille sous roche. S’il y a plus de votants validés que de votes, cela signifie probablement que des votants validés ne se sont pas donnés la peine de voter. De nombreuses personnes sont enregistrées pour voter choisissent de ne pas participer aux ballottages. Ce protocole est aussi vulnérable à une collusion entre l’A C D et l’ACL. Si les deux se mettent ensemble, elles peuvent corréler leurs bases de données et déterminer qui a voté pour qui.
6.1
139
Élections sûres
Vote avec une seule autorité centrale Un protocole plus complexe peut être utilisé pour éviter le danger de collusion entre l’ACL et l’A C D [1375]. Ce protocole est identique au précédent excepté les deux modifications suivantes : - l’A C L et l’A C D sont une seule et même organisation ; - A N D O S (voir § 4.13) est utilisé pour distribuer des numéros de validation ano nymes à l’étape 2 . Comme le protocole de distribution anonyme de clefs empêche l’A C D de savoir quel votant a eu quel numéro de validation, l’A C D ne peut pas corréler les numéros de validation avec les votes reçus. Il faut toutefois toujours être sûr que l’A C D n’attribuera pas des numéros de validation à des votants non légitimes. On peut aussi résoudre le problème avec des signatures en aveugle.
Vote amélioré avec une seule autorité centrale Ce protocole utilise aussi le protocole A N D O S [1181]. C ’est un excellent protocole et il satisfait les 6 propriétés d’un bon protocole de vote. Il ne satisfait pas la 7e contrainte, mais il a deux propriétés supplémentaires par rapport à celles mentionnées au début de ce paragraphe : 7. Les votants peuvent changer d’avis (c’est-à-dire, retirer leur vote et voter à nou veau) pendant une période de temps donnée. 8.
Si les votants découvrent que leur vote a été mal comptabilisé, ils peuvent iden tifier et corriger le problème sans compromettre la confidentialité de leur vote.
Voici le protocole : 1° L ’A C D publie la liste de tous les votants légitimes. 2° Pendant un laps de temps spécifié, toute personne peut indiquer son intention de voter auprès de Z’A C D .
3° L ’A C D publie la liste des votants participant à l ’élection. 4° Tous les votants reçoivent un numéro d’identification, I, en utilisant le proto cole A N D O S.
5° Tous les votants engendrent une paire clef publique clef privée : k,d. Si v est le vote, ils engendrent le message suivant et l’envoient à Z’A C D : I ,E k(I,v) 6°
L ’A C D confirme les votes en publiant : E k(I,v)
7° Tous les votants envoient à Z'ACD : I,d
Chapitre 6 8°
Protocoles ésotériques
L ’A C D utilise d pour déchiffrer les votes. A la fin de l’élection, elle publie les résultats de l’élection et pour chaque vote possible, la liste de tous les E k(I,v) contenant ce vote-là.
9° Si un votant constate qu ’un vote n’est pas comptabilisé correctement, il proteste en envoyant: I ,E k{I,v),d 10
° Si un votant veut changer son vote (c ’est possible dans certains types d’élec tions) de v à v', il peut envoyer à l ’A C D : I ,E k(i,v'),d
Un autre protocole de vote [587] utilise des signatures en aveugle à la place d ’ANDOS, mais il est essentiellement le même. Les étapes 1 à 3 sont des préliminaires au vote lui-même. Leur but est de déterminer et de publier le nombre total de votants. Bien que certains d ’entre eux ne participeront probablement pas, cela réduit la possibilité pour l’A C D d ’ajouter des votes frauduleux. A l’étape 4, il est possible que deux votants reçoivent le même numéro d ’identification. Cette éventualité peut être évitée en ayant bien plus de numéros d ’identification qu’il n’y a de votants. Si deux votants soumettent des votes avec le même identificateur, l’A C D engendre un nouveau numéro d’identification i', choisit l’un des deux votes et publie : r , E k(i,v)
L’émetteur de ce vote le reconnaît et envoie un deuxième vote en répétant l’étape 5 avec le nouveau numéro d ’identification. L’étape 6 donne la possibilité à tous les votants de vérifier que l’A C D a reçu leur vote correctement. Et si leur vote est mal comptabilisé, ils peuvent le prouver à l’étape 9. En faisant l’hypothèse que tous les votes sont corrects à l’étape 6 , le message qu’ils envoient à l’étape 9 constitue une preuve que leur vote a été mal comptabilisé. Le défaut principal de ce protocole est que l’A C D peut allouer des votes pour des gens qui répondent à l’étape 2 mais qui ne votent pas. Un autre défaut est la complexité du protocole A N D O S. Les auteurs recommandent de diviser une grande population de votants en groupes plus petits, comme des districts électoraux. Il reste un problème plus sérieux : l’A C D peut négliger de compter un vote. Ce problème ne peut être résolu : Alice prétend que l’A C D a sciemment oublié de compter son vote, mais l’A C D prétend qu’Alice n’a jamais voté.
Vote sans une autorité centrale de comptabilisation Ce protocole permet de se passer complètement de l’A C D , les votants se surveiellent les uns les autres. Conçu par Michael M e r r i t t [266, 597, 267], il est si difficile à manier que seule une poignée de participants peut le mettre en pratique, il est malgré tout intéressant à étudier. Alice, Bernard, Christine et David votent oui ou non (0 ou 1) à propos d ’un sujet particulier. Faites l’hypothèse que chaque participant a une clef publique et une clef
6.1
Élections sûres
141
privée, que tout le monde connaît la clef publique de chacun. 1° Tous les votants choisissent un vote et effectuent ce qui suit: (a) ajouter une chaîne aléatoire à leur vote; ( b ) chiffrer le résultat de ( c )
chiffrer le résultat de
(d ) chiffrer le résultat de ( e )
chiffrer le résultat de
l’étape (a) avec la clef publique de David; l’étape (b) avec la clef publique de Christine; l’étape (c) avec la clef publique de Bernard; l’étape (d) avec la clef publique d’Alice;
( f ) ajouter une nouvelle chaîne aléatoire au résultat de l’étape (e) et chiffrer le tout avec la clef publique de David. Ils enregistrent la valeur de cette chaîne aléatoire;
(g) ajouter une nouvelle chaîne aléatoire au résultat de l’étape (f) et chiffrer le tout avec la clef publique de Christine. Ils enregistrent la valeur de cette chaîne aléatoire;
(h ) ajouter une nouvelle chaîne aléatoire au résultat de l’étape (g) et chiffrer le tout avec la clef publique de Bernard. Ils enregistrent la valeur de cette chaîne aléatoire ;
(i) ajouter une nouvelle chaîne aléatoire au résultat de l’étape (h) et chiffrer le tout avec la clef publique d’Alice. Ils enregistrent la valeur de cette chaîne aléatoire. Si E est la fonction de chiffrement, R est une chaîne aléatoire et V est un vote, le vote ressemble à ceci: EA(Rb,E B(Ri>E c (R 3,ED(R2,EA(E B(Ec (ED(V1R 1)))))))) Tous les votants sauvegardent les résultats intermédiaires à chaque point du calcul. Ces résultats seront utilisés plus tard dans le protocole pour confirmer que leur vote est parmi ceux qui ont été comptabilisés.
2° Tous les votants envoient leur vote à Alice. 3° Alice déchiffre tous les votes avec sa clef privée, vérifie que son vote est bien parmi l’ensemble des votes (en cherchant sa chaîne aléatoire parmi les votes), et ensuite elle retire toutes les chaînes aléatoires à ce niveau.
4° Alice mélange l’ordre de tous les votes et envoie le résultat à Bernard. Chaque vote ressemble à ceci maintenant : E B{Ri ,E c {R 3 ,E D(R 2 ,E A{E B(Ec {ED{V,R1)))))))
5° Bernard déchiffre tous les votes avec sa clef publique, vérifie que son vote est bien parmi l’ensemble des votes, retire toutes les chaînes aléatoires à ce niveau, mélange tous les votes et envoie le résultat à Christine. Chaque vote ressemble à ceci maintenant: E c ( R 3 ,E d ( R 2,E a ( E b ( E c ( E d ( V ,R 1 ) ) ) ) ) )
Chapitre 6
142 6°
Protocoles ésotériques
Christine déchiffre tous les votes avec sa clef publique, vérifie que son vote est bien parmi l’ensemble des votes, retire toutes les chaînes aléatoires à ce niveau, mélange tous les votes et envoie le résultat à David. Chaque vote ressemble à ceci maintenant : E d (R 2 ,E a (E b (E c (E d (V A ) ) ) ) )
7° David déchiffre tous les votes avec sa clef publique, vérifie que son vote est bien parmi l ’ensemble des votes, retire toutes les chaînes aléatoires à ce niveau, mélange tous les votes et envoie le résultat à Alice. Chaque vote ressemble à ceci maintenant : E a (E b (E c (E d (V,R i)))) 8°
Alice déchiffre tous les votes avec sa clef publique, vérifie que son vote est bien parmi l’ensemble des votes, signe l’ensemble des votes, et envoie le résultat à Bernard, Christine et David. Chaque vote ressemble à ceci maintenant: S a (E b (E c (E d (V ,/Zi))))
9° Bernard vérifie et retire la signature d’Alice. Il déchiffre tous les votes avec sa clef publique, vérifie que son vote est bien parmi l’ensemble des votes, signe l’ensemble des votes, et envoie le résultat à Alice, Christine et David. Chaque vote ressemble à ceci maintenant : S B {E c{E D{V,Ry))) 10
° Christine vérifie et retire la signature de Bernard. Elle déchiffre tous les votes avec sa clef publique, vérifie que son vote est bien parmi l’ensemble des votes, signe l ’ensemble des votes, et envoie le résultat à Alice, Bernard et David. Chaque vote ressemble à ceci maintenant: SC{E D{V,Ry))
1 1
° David vérifie et retire la signature de Christine. Il déchiffre tous les votes avec sa clef publique, vérifie que son vote est bien parmi l ’ensemble des votes, signe l’ensemble des votes, et envoie le résultat à Alice, Bernard et Christine. Chaque vote ressemble à ceci maintenant: S d {V,R i)
12° Tous vérifient et retirent la signature de David. Ils s ’assurent que leur vote est bien parmi l’ensemble des votes (en cherchant leur chaîne aléatoire parmi les votes).
13° Chacun retire les chaînes aléatoires de chaque vote et compte les voix.
6.1
Élections sûres
Non seulement ce protocole marche mais il est auto-arbitré. Alice, Bernard, Chris tine et David sauront immédiatement si quelqu’un triche. Aucune A C D ou A C L n’est nécessaire. Pour voir comment cela marche, essayons de tricher. Si quelqu’un essaie de rajouter des voix, Alice le détectera à l’étape 3 quand elle recevra plus de votes que de participants. Si Alice essaie de rajouter des voix, Bernard le détectera à l’étape 4. Un moyen plus détourné de tricher est de remplacer un vote par un autre. Comme les votes sont chiffrés avec plusieurs clefs publiques, n’importe qui peut créer autant de votes valides que nécessaire. Il y a deux rondes au protocole de déchiffrement : la ronde 1 est constituée des étapes 3 à 7, et la ronde 2 est constituée des étapes 8 à 11. Le remplacement de votes est détecté de façon différente dans les deux rondes. Si quelqu’un remplace un vote par un autre dans la ronde 2 , ces actions sont découvertes immédiatement. A chaque étape les votes sont signés et envoyés à tous les votants. Si un (ou plusieurs) votant constate que son vote n ’est plus dans l’ensemble des votes, il peut immédiatement arrêter le protocole. Comme les votes sont signés à chaque étape, et que tout le monde peut remonter la ronde 2 du protocole, il est aisé de déterminer qui a remplacé des votes. Remplacer un vote par un autre pendant la ronde 1 du protocole est plus subtil. Alice ne peut pas le faire à l’étape 3, car Bernard, Christine ou David le détecteraient à l’étape 5, 6 ou 7. Bernard pourrait essayer à l’étape 5. S’il remplace le vote de Christine ou de David (rappelez-vous qu’il ne sait pas à qui tel vote correspond). Christine ou David s’en rendront compte à l’étape 6 ou 7. Ils ignoreront qui a modifié leur vote (bien que cela ne puisse être que quelqu’un ayant déjà manipulé leur vote) mais ils sauront que leur vote a été falsifié. Si Bernard est chanceux et choisit le vote d’Alice pour la substitution, elle ne s’en rendra compte qu’à la deuxième ronde. A ce moment-là, elle détectera à l’étape 8 que son vote manque. Toutefois, elle ne saura pas qui a modifié son vote. Durant la première ronde, les votes sont mélangés d ’une étape à l’autre et non signés: il est impossible pour qui que ce soit de remonter le protocole afin de déterminer qui a truqué les votes. Un autre moyen de tricher est d ’essayer de deviner qui a voté pour qui. A cause du mélange durant la première ronde, il est impossible de remonter le protocole pour associer les votants aux votes. Le retrait des chaînes aléatoires pendant la première ronde est également crucial pour préserver l’anonymat. Si elles ne sont pas retirées, le mélange des votes peut être défait en rechiffrant les votes avec la clef publique de celui qui a mélangé. Tant que le protocole tient, la confidentialité des votes est sûre. Plus fort encore, à cause de la chaîne aléatoire initiale R i , même des votes identiques sont chiffrés différemment à chaque étape du protocole. Personne ne connaît le résultat du vote avant l’étape 1 1 . Quels sont les défauts de ce protocole? Premièrement, le protocole nécessite un grand nombre de calculs. L’exemple décrit ici n’implique que 4 votants et c ’était compliqué. Cela ne marcherait jamais pour de vraies élections avec des dizaines de milliers de votants. Deuxièmement, David apprend les résultats de l’élection avant tout le monde. Bien qu’il ne puisse plus en modifier le résultat, cela lui donne un pouvoir que les autres n’ont pas. Pour en finir, tout cela s’applique aux protocoles de vote avec autorité centrale. Le troisième problème est qu’Alice peut faire le même vote que n’importe quel autre votant. Pour comprendre pourquoi cela peut être un problème, considérons une élection
Chapitre 6
144
Protocoles ésotériques
à trois personnes Alice, Bernard et Estelle. Estelle ne soucie pas du résultat de l’élection, mais elle veut connaître le vote d ’Alice. Pour cela, elle copie le vote d’Alice et le résultat de l’élection sera forcément égal au vote d ’Alice.
Autres schémas de vote De nombreux protocoles sûrs d’élection ont été proposés. On peut les cataloguer en deux tendances de base. Il y les protocoles de mélange, comme le « vote sans autorité centrale de tabulation » où les votes sont mélangés de sorte que personne ne peut associer un vote avec un votant. Il y a aussi des protocoles de division où les votes indiciduels sont répartis entre diffé rentes autorités de comptabilisation de sorte qu’aucune ne puisse tromper les votants à elle seule [364, 363, 128, 125]. Ces protocoles ne protègent la vie privée des votants que dans la mesure où les « parties » du Gouvernement (ou quiconque gère l’élection) ne conspirent pas contre le votant1. Un protocole de division est donné dans [1373]. L’idée de départ est que chaque votant partage son vote en plusieurs parties. Par exemple, s’il s’agit de voter « oui » ou « non », un 1 pourrait signifier « oui » et un 0 pourrait signifier « non »; le votant produirait alors plusieurs nombres dont la somme ferait soit 0, soit 1. Ces parties sont chiffrées et envoyées aux autorités de comptabilisation, une par autorité. Chaque centre totalise les parts qu’il reçoit 2 et le vote final est la somme de tous les totaux. Il y a des protocoles qui certifient que la somme des parts de chaque votant vaut bien 1 ou 0 . Un autre protocole, dû à David C h a u m [328], permet de retrouver les votants qui essaient de perturber les élections. Toutefois, dans ce cas, le vote doit être recommencé sans le votant trublion; cette approche n’est pas pratique pour des votes à grande échelle. Un autre protocole de vote plus complexe qui pallie certains des défauts est décrit dans [770, 771]. Il y a même un protocole de vote qui utilise le surchiffrement [222], Un autre protocole de vote, qui prétend être pratique pour des élections à grande échelle, est décrit dans [587]. Et [351] permet aux votants de s’abstenir. Les protocoles de vote marchent, mais ils facilitent le commerce des votes. Le risque devient d ’autant plus grand que l’acheteur peut s’assurer que le vendeur a voté comme promis. Certains protocoles sont conçus pour qu’un votant ne puisse pas prouver à autrui qu’il a voté d’un côté donné [127, 4, 1374].
6.2
Calcul réparti sûr
Le calcu l rép arti sûr est un protocole par lequel un groupe de personnes peuvent se rasssembler pour calculer la valeur d ’une fonction à plusieurs arguments. Chaque participant fournit un seul argument de la fonction. Chacun dans le groupe connaîtra le résultat de l’évaluation de la fonction mais personne n’apprend rien qui ne puisse se déduire du résultat concernant les valeurs d ’arguments fournies par les autres membres. Voici quelques exemples : X. C ette idée de scinder une autorité centrale en plusieurs parties, en qui l’ on n ’a confiance que si elles sont réunies vient de [320]. 2. Il y a des protocoles qui perm ettent de vérifier l’exactitude des totaux.
6.2
Calcul réparti sûr
Protocole n° 1 Comment un groupe de personnes peuvent-elles calculer la moyenne de leurs salaires sans que personne n’apprenne le montant du salaire d ’un autre? 1° Alice ajoute un nombre aléatoire secret à son salaire, chiffre le résultat avec la clef publique de Bernard et l’envoie à Bernard.
2° Bernard déchiffre le résultat d ’Alice avec sa clef privée. Il ajoute son salaire à ce qu’il a reçu d’Alice, chiffre le résultat avec la clef publique de Christine et l’envoie à Christine.
3° Christine déchiffre le résultat de Bernard avec sa clef privée. Elle ajoute son salaire à ce qu’elle a reçu de Bernard, chiffre le résultat avec la clef publique de David et l’envoie à David.
4° David déchiffre le résultat de Christine avec sa clef privée. Il ajoute son salaire à ce qu’il a reçu de Christine, chiffre le résultat avec la clef publique d’Alice et l’envoie à Alice.
5° Alice déchiffre le résultat de David avec sa clef privée. Elle retire le nombre aléatoire de l’étape 1 pour retrouver la somme des salaires de tout le monde. 6°
Alice divise le résultat par le nombre de personnes (4 dans ce cas-ci) et annonce le résultat.
Ce protocole fait l’hypothèse que tout le monde est honnête. Si les participants mentent à propos de leur salaire, la moyenne sera fausse. Un défaut plus sérieux est qu’Alice peut truquer le résultat présenté aux autres. Elle peut retirer le nombre qu’elle veut du résultat à l’étape 5 et personne ne s’en rendrait compte. Alice pourrait en être empêchée en l’obligeant à mettre en gage son nombre aléatoire en utilisant n’importe quel schéma de mise en gage de le paragraphe 4.9 mais quand elle révèle son nombre aléatoire à la fin du protocole, Bernard peut connaître le montant du salaire d ’Alice.
Protocole n° 2 Alice et Bernard sont ensemble au restaurant et discutent de leur âge respectif. Ni l’un ni l’autre ne veut dire son âge à l’autre mais ils sont tous les deux curieux de savoir qui est le plus âgé. Ils pourraient chacun murmurer leur âge à l’oreille d’un tiers de confiance (le serveur, par exemple), qui calculera de tête et qui annoncera le résultat à Alice et Bernard. Il y a deux défauts au protocole ci-dessus. Premièrement, le serveur ordinaire n’a pas de capacité de calcul pour traiter des problèmes plus complexes que la comparaison entre deux nombres. Deuxièmement, si Alice et Bernard étaient vraiment soucieux du caractère secret de leurs informations, ils devraient noyer le serveur dans un verre d’eau de Vichy sinon celui-ci pourrait tout raconter au sommelier. La cryptographie à clef publique offre une solution bien moins violente. U existe un protocole grâce auquel Alice qui connaît la valeur a, et Bernard qui connaît la va leur b, peuvent ensemble calculer f(a,b) de manière qu’ Alice n’ait aucune information concernant b et que Bernard n’ait aucune information concernant a. Ainsi, Alice et Bernard sont tous deux convaincus de la validité des calculs. Comme l’algorithme
Chapitre 6
146
Protocoles ésotériques
cryptographique utilisé est partie intégrante du protocole, les détails seront donnés dans le paragraphe 23.14. Bien sûr, ce protocole ne protège pas contre les tricheurs actifs. Il n’y a rien qui empêche Alice (ou Bernard par la même occasion) de tricher sur son âge. Si Bernard était un programme informatique qui exécutait aveuglément le protocole, Alice pourrait apprendre son âge (est-ce que l’âge d ’un programme informatique est compté à partir du temps où il a été écrit ou à partir du temps où il a commencé à être exécuté?) par applications répétées du protocole. Alice peut exécuter le protocole en donnant comme âge 60 ans. Après avoir appris qu’elle est plus âgée, elle exécute le protocole à nouveau en prétendant être âgée de 30 ans. Après avoir appris que Bernard est plus âgé, elle exécute le protocole à nouveau avec 45 et ainsi de suite jusqu’à que ce qu’elle connaisse l’âge de Bernard avec une précision aussi grande que souhaitée. En faisant l’hypothèse que les participants ne trichent pas activement, il est aisé d ’étendre ce protocole à plus de deux participants. N’importe quel nombre de personnes peuvent déterminer l’ordre de leurs âges par des applications honnêtes et répétées du protocole ; et aucun participant n’apprendra l’âge d’un autre participant.
Protocole n° 3 Alice aime faire des choses un peu perverses avec des ours en peluche. Bernard a des fantasmes érotiques à propos des tables en marbre. Chacun est gêné d ’évoquer ses fétiches particuliers mais aimerait bien trouver le compagnon qui partage leur ... hum ... style de vie. Au « Service Informatique Sécurisé de Rencontres de Groupetm » nous avons conçu un protocole pour de telles personnes. Nous avons numéroté une liste étonnante de fétiches depuis « a » jusqu’à « z ». Discrètement, séparés par un modem, Alice et Bernard peuvent participer à un protocole multi-participants sûr. Ensemble, ils peuvent déterminer s’ils partagent ou non un fétiche particulier. Si oui, ils peuvent envisager une heureuse relation. Si non, ils peuvent se dire au revoir, assurés de la confidentialité de leurs secrets. Personne, même pas la « Secure Multiparty Computation Dating Servicetm » ne saura jamais. Voilà comment ça marche. 1
° Alice applique une fonction de hachage a sens unique au nom de son fétiche et obtient une suite de huit chiffres.
2° Alice se sert de cette suite de chiffres comme d’un numéro de téléphone au quel elle appelle et laisse un message pour Bernard. Si personne ne répond ou si le numéro n’est pas en service, Alice applique autant de fois qu’il est nécessaire la fonction de hachage au numéro de téléphone pour avoir en ligne quelqu’un qui puisse participer au protocole.
3° Alice dit à Bernard combien de fois elle a du appliquer la fonction de hachage au nom de son fétiche.
4° Bernard applique la fonction de hachage au nom de son fétiche le même nombre de fois. Il téléphone au numéro que forme le résultat et demande si personne n’a laissé de message pour lui.
Bernard peut faire une attaque à texte en clair choisi. Il peut appliquer la fonction de hachage à des noms de fétiches usuels et appeller aux numéros de téléphones résultants
6.2
147
Calcul réparti sûr
à la recherche de messages pour lui. Ce protocole ne marche vraiment que s’il y a assez de textes en clair possibles pour rendre cette attaque infaisable. Il existe aussi un protocole mathématique similaire au protocole n° 2. Alice connaît a, Bernard connaît b et ensemble ils vont déterminer si a = b de telle manière que Bernard n’apprenne rien sur a et Alice n’apprenne rien sur b. Les détails sont donnés dans le paragraphe 23.14.
Protocole n° 4 Voici un autre problème pour le calcul réparti sûr [1375]. Un comité se réunit réguliè rement pour voter secrètement sur certains sujets. (Oui, ils gouvernent secrètement le monde, ne dites à personne que je vous l’ai dit.) Tous les membres du comité peuvent voter par « oui » ou « non ». En plus, deux participants ont le droit d’émettre des « super-votes » : « S—oui » et « S non ». Ils ne sont pas obligés d’émettre des super votes, ils peuvent émettre des votes normaux s’ils préfèrent. Si personne n’émet de super-vote, alors la majorité des voix décide de l’issue du scrutin. Dans le cas où il n’y a qu’un seul super-vote, ou deux super-votes équivalents, tous les votes normaux sont ignorés. Dans le cas de deux super-votes contradictoires, la majorité des votes normaux l’emporte. Nous voulons un protocole qui réalise de façon sûre ce type de vote. Deux exemples illustreront le processus de vote. Faites l’hypothèse qu’il y a 5 votants normaux, Nj à IV5 et deux super-votants Si et S2. Voici le résultat du vote n° 1 Si
S -oui
S-2 Ni non non
N2 N3 non non
N4 oui
N5 oui
Dans ce cas-là,seul compte le vote de Si et lerésultat est « oui ». Voici le résultat du vote surle sujet suivant n° 2 : Si
S -oui
S2 S- non
Ni
non
N2 non
N3 non
N4 oui
N5 oui
Ici les deux super-votes s’annulent et la majorité des « non » l’emporte. S’il n’est pas nécessaire de cacher comment le vote a été tranché : par un super-vote ou par une majorité de votes réguliers, c ’est une simple application du protocole de vote sûr. S’il est par contre important de garder cette information secrète, un protocole de calcul réparti sûr plus compliqué est nécessaire. Ce type de vote peut exister dans la vie courante. Cela peut faire partie de la structure d’une société où certaines personnes ont plus de pouvoir que d ’autres. Ou cela peut faire partie des procédures de l’ONU où certaines nations ont plus de pouvoir que d’autres.
Protocoles répartis inconditionnellement sûr Il s’agit simplement d’un cas particulier d ’un théorème plus général: un ensemble de n participants peut calculer évaluer n’importe quelle fonction à n arguments de sorte que chacun connaîtra le résultat sans qu’un sous-ensemble de moins de n / 2 participants ne puisse obtenir d’autre information que leurs arguments et l’information inhérente au résultat. Pour les détails, voir [121, 339, 1299, 622].
Chapitre 6
148
Protocoles ésotériques
*
Evaluation répartie sûre de circuits Alice a sa donnée a, Bernard a sa donnée b. Ensemble, ils désirent calculer une certaine fonction f{a,b) de manière qu’Alice n’apprenne rien sur la donnée de Bernard et que Bernard n’apprenne rien sur la donnée d ’Alice. Le problème générique de calcul réparti sûr est aussi appelé évalu a tion rép a rtie sûre d e circu its. Ici Alice et Bernard peuvent créer un circuit booléen arbitraire. Ce circuit accepte les entrées d ’Alice et de Bernard et produit une sortie. L’évaluation sûre de circuits est un protocole qui accomplit trois choses : 1
. Alice peut entrer sa donnée sans que Bernard ne puisse la connaître.
2. Bernard peut entrer sa donnée sans qu’Alice ne puisse la connaître. 3. Alice et Bernard peuvent tous deux calculer la sortie en étant tous deux convain cus que la sortie est correcte et que personne n ’a triché. Les détails concernant les évaluations sûres de circuits peuvent être trouvés dans [832].
6.3
Diffusion de messages anonymes
Vous ne pouvez pas aller dîner avec un groupe de cryptographes sans qu’il y ait du chahut. Dans [327], David C h a u m introduit le Problème du Dîner des Cryptographes: « Trois cryptographes sont en train de dîner dans leur restaurant trois étoiles favori. Leur serveur les informe que des arrangements ont été pris avec le maître d’hôtel pour que la note soit payée anonymement. L ’un des cryptographes peut avoir payé le dîner, ou cela peut être la NSA. Les trois cryptographes respectent leur droit respectif d ’effectuer un paiement anonyme mais ils aimeraient bien savoir quand c ’est la NSA qui paie. » Comment les cryptographes, appelés Alice, Bernard et Christine, déterminent-ils si l’un d’entre eux paie le repas tout en préservant l’anonymat du payeur? C h a u m continue ainsi pour résoudre le problème : « Chaque cryptographe lance une pièce non biaisée derrière son menu, entre lui et le cryptographe à sa droite, de telle façon qu’eux deux seuls voient le résultat du lancer. Chaque cryptographe annonce alors à haute voix si les deux pièces qu’il peut voir — celle qu’il a lancée et celle que son voisin de gauche a lancée — sont tombées sur la même face ou sur des faces opposées. Si l’un des cryptographes est le payeur, il annonce le contraire de ce qu’il voit. Un nombre impair de différences annoncé autour de la table indique que l’un des cryptographes paie l’addition ; un nombre pair de différences indique que la NSA paie (en faisant l’hypothèse que le repas n ’est payé qu’une seule fois). Ainsi, si un cryptographe paie, aucun des deux autres n’apprend quoi que ce soit concernant l’identité du payeur à partir des annonces. » Pour voir si cela marche, imaginez qu’Alice essaie de deviner quel autre cryptographe a payé le dîner (en faisant l’hypothèse que ni elle ni la NSA n’ont payé). Si elle voit deux
6.3
Diffusion de messages anonymes
149
faces différentes, alors les deux autres cryptographes, Bernard et Christine, ont tous deux annoncé « identiques », ou ils ont tous deux annoncé « différentes ». (Rappelezvous qu’un nombre impair de cryptographes annonçant « différentes » indique que l’un d’entre eux paie.) Si tous les deux ont dit « différentes » alors le payeur est le cryptographe le plus proche de la pièce qui est identique à la pièce cachée (celle qui a été lancée entre Bernard et Christine). Si tous les deux ont dit « identiques » alors le payeur est le cryptographe le plus proche de la pièce différente de la pièce cachée. De même, si Alice voit deux faces identiques, alors soit Bernard a dit « identiques » et Christine « différentes » ou inversément. Si la pièce cachée est la même que les deux pièces qu’elle voit, alors le cryptographe qui a dit « différentes » est le payeur. Si la pièce cachée est différente des deux pièces qu’elle voit, alors le cryptographe qui a dit « identiques » est le payeur. Dans tous les cas, Alice doit connaître le résultat du lancer entre Bernard et Christine pour déterminer qui a payé. Ce protocole peut être généralisé pour n’importe quel nombre de cryptographes : ils sont tous assis en rond et lancent des pièces entre eux. Même deux cryptographes peuvent effectuer le protocole: bien sûr ils savent qui a payé mais quelqu’un qui observe le protocole peut seulement dire si un des cryptographes a payé ou si la NSA a payé. Il ne peut pas dire quel cryptographe a payé. Les applications de ce protocole dépassent largement le cadre du restaurant. C ’est un exemple d ’ a b s e n c e i n c o n d i t i o n n e l l e d e m o y e n d e r e t r o u v e r l ’ e x p é d i t e u r e t le d e s t i n a t a i r e . Un groupe d ’utilisateurs d ’un réseau disposent du protocole suivant pour échanger des messages anonymes. 1° Les utilisateurs s ’organisent sous forme d’un anneau logique. 2° A intervalles réguliers les paires d’utilisateurs adjacents lancent une pièce entre eux, en utilisant un protocole équitable de jeu à pile ou face. Ils veillent à ce que tous leurs messages soient chiffrés de manière qu ’ils soient les seuls à connaître le résultat du lancer.
3° A intervalles réguliers chaque utilisateur annonce soit « identiques », soit « dif férentes ». Si les utilisateurs veulent diffuser cm message individuellement, ils commencent sim plement à inverser les annonces dans les rondes correspondant à des 1 dans la repré sentation binaire du message. Par exemple, si le message est « 1001 », ils inversent leur réponse, disent la vérité, disent la vérité et finalement inversent leur réponse. En faisant l’hypothèse que les résultats des lancers sont « différentes », « identiques », « identiques », « identiques », ils annoncent « identiques », « identiques », « identiques », « différentes ». Si les utilisateurs détectent que le résultat du protocole ne correspond pas au mes sage qu’ils essaient d’envoyer, ils savent que quelqu’un d’autre est également en train d’essayer d’envoyer un message. Ils arrêtent alors de transmettre durant un nombre aléatoire de rondes avant d’essayer à nouveau. Les paramètres exacts doivent être ba sés sur le volume de messages circulant sur le réseau mais l’idée est claire. Pour rendre les choses encore plus intéressantes, les messages peuvent être chiffrés par les clefs publiques des uns et des autres. Alors, quand tout le monde reçoit le message (une réalisation concrète de cela ajouterait des en-têtes et des conclusions de messages standards), seul le destinataire légitime peut déchiffrer et lire le message. Personne d’autre ne sait qui l’a envoyé. Personne ne sait qui peut le lire. L ’analyse de trafic, qui
150
Chapitre 6
Protocoles ésotériques
trace et enregistre les motifs de communication entre les gens bien que les messages soient eux-mêmes chiffrés, est inutile dans ce cas-là. Une alternative au lancer de pièce entre participants adjacents est de partager un fichier de bits aléatoires. Peut-être pourront-ils le ranger sur un CD-ROM, ou l’un des membres de la paire pourra engendrer un paquet de bits aléatoires et les envoyer à l’autre participant (en chiffrant le transfert bien sûr) ? Une autre possibilité est de convenir de l’utilisation d ’un générateur pseudo-aléatoire de nombres et ils peuvent alors chacun engendrer la même chaîne de bits pseudo-aléatoires pour le protocole. Un problème dans ce protocole est le suivant: si un participant malveillant ne peut lire aucun message, il peut par contre fausser le système sans être pris en mentant à l’étape 3. Il existe une modification de ce protocole qui permet de détecter les perturbations [1580, 1253] ; le problème s’appelle le « Dîner des Cryptographes à la Discothèque ».
6.4
Argent électronique
L ’argent est un problème. C ’est gênant à transporter, cela peut répandre les maladies, et on peut vous le voler. L ’existence des cartes de crédit a largement réduit la quantité de monnaie qui circule dans notre société mais l’élimination complète de la monnaie est virtuellement impossible. Cela n’arrivera jamais : les trafiquants de drogue et les politiciens ne l’accepteront jamais. Les cartes de crédit et les chèques sont associées à un relevé : vous ne pouvez pas cacher à qui vous donnez de l’argent. D ’un autre côté, les chèques et les cartes de crédit autorisent une intrusion dans votre vie privée à un degré jamais imaginé auparavant. Vous pourriez ne jamais avoir à faire à la police de toute votre vie, mais la police peut surveiller vos transactions financières. Ils peuvent voir où vous achetez de l’essence, de la nourriture, qui vous appelez au téléphone, tout cela sans bouger de leur ordinateur. Les gens ont besoin d ’un moyen de protéger leur anonymat pour protéger leur vie privée. Heureusement, il existe un protocole compliqué qui permet des messages authentiques mais dont on ne peut retrouver l’émetteur. Alice la lobbyiste peut transférer de l’argent électronique au sénateur Bernard de manière que la journaliste Estelle ne connaisse pas l’identité d’Alice. Bernard peut alors déposer cet argent électronique sur son compte en banque, même si la banque n’a pas la moindre idée de qui est Alice. Mais si Alice essaie de corrompre deux hommes politiques avec le même argent électronique — chose facile à tenter avec un programme de copies de bits — elle sera repérée par la banque. Et si Bernard essaie de déposer deux fois le même argent électronique sur deux comptes dif férents, il sera repéré — mais Alice restera anonyme. On nomme aussi cela de l’argent électronique anonyme pour le différencier de l’argent élctronique avec relevé comme les cartes de crédit. La demande sociale pour ce genre de choses est forte. Avec la montée d’Internet dans les transactions commerciales, il y a un appel grandissant pour la préservation de la vie privée dans les réseaux et l’anonymat dans les affaires3. D ’un autre côté, les banques et les gouvernements ne veulent pas abandonner le contrôle que leur procure les systèmes actuels de paiement avec relevé. Ils y seront contreints pourtant. Tout ce dont il suffit 3. Les gens ont de bonnes raisons d’être rétissants avant d’envoyer leur numéro de carte de crédit via Internet.
6.4
Argent électronique
151
pour Lancer l’argent électronique, c ’est une institution de confiance qui changera les nombres numériques contre de l’argent officiel. Les protocoles d’argent électronique sont très compliqués. Nous allons en mettre un sur pied, étape par étape. Pour plus de détails lisez [322, 344, 330, 340, 345]. Rendez vous bien compte qu’il s’agit là d’un seul protocole d’argent électronique, il en existe d’autres.
Protocole n° 1 Les quelques premiers protocoles sont des analogies matérielles des protocoles cryptographiques. Le protocole suivant est un protocole matériel pour des ordres de paiement anonymes : 1° Alice prépare 100 ordres de paiement anonymes de 1000 francs. 2° Alice place chacun d’entre eux avec une feuille de carbone dans 100 enveloppes différentes. Elle donne le tout à la banque.
3° La banque ouvre 99 enveloppes et confirme que chacune d’entre elles contient bien un ordre de paiement d’un montant de 1 0 0 0 francs.
4° La banque signe la seule enveloppe non ouverte restante. La signature passe à travers le carbone sur l’ordre de paiement. La banque rend l’enveloppe non ouverte à Alice et retire 1 000 francs de son compte.
5° Alice ouvre l’enveloppe et utilise l’ordre de paiement chez un commerçant. 6°
Le commerçant vérifie la signature de la banque pour s ’assurer que l’ordre de paiement est légitime.
7° Le commerçant porte l’ordre de paiement à la banque. 8°
La banque vérifie sa signature et crédite le compte du commerçant de 1 0 0 0 francs.
Ce protocole marche. La banque ne voit jamais l’ordre de paiement lors de la signature, donc quand le commerçant l’apporte à la banque, celle-ci ne sait pas qu’il est d’Alice. La banque est toutefois convaincue qu’il est valide grâce à sa signature. La banque est persuadée que le montant de l’ordre de paiement non ouvert est de 1 0 0 0 francs (et non pas de 1 0 0 0 0 0 francs ou de 1 0 0 0 0 0 0 0 0 francs) grâce à la technique « couperet-choisir » (voir § 5.1). Elle vérifie les 99 autres enveloppes, Alice n’a donc que 1 % de chance de tromper la banque. Bien sûr, en cas de tricherie, la banque infligera une amende d’un montant tel que cela découragera toute tentative. Si la banque refuse de signer le dernier chèque (si Alice est prise en flagrant délit de tricherie) sans aucune punition, Alice pourrait continuer jusqu’à ce qu’elle ait de la chance4.
Protocole n° 2 Le protocole précédent empêche Alice d ’indiquer un montant supérieur à ce qu’elle est en droit de prétendre sur un ordre de paiement, mais rien ne l’empêche de photocopier 4. Les peines de prison sont de bons moyens de dissuasion.
152
Chapitre 6
Protocoles ésotériques
l’ordre de paiement et de l’utiliser deux fois. Pour éviter cela nous devons compliquer le protocole : 1° Alice prépare 100 ordres de paiement anonymes de 1000 francs chacun. Sur chaque ordre de paiement elle ajoute une chaîne aléatoire différente et unique, suffisamment longue pour que les chances qu’un autre utilisateur utilise la même chaîne soient négligeables.
2° Alice place chacun d’entre eux avec une feuille de carbone dans 100 enveloppes différentes. Elle donne le tout à la banque.
3° La banque ouvre 99 enveloppes et confirme qu’il s ’agit bien d’ordres de paiement pour un montant de 1 0 0 0 francs, et que les chaînes aléatoires uniques sont bien différentes.
4° La banque signe la dernière enveloppe non ouverte. La signature passe à travers le carbone sur l’ordre de paiement. La banque rend l’enveloppe non ouverte à Alice et retire 1000 francs de son compte.
5° Alice ouvre l’enveloppe et utilise l’ordre de paiement chez un commerçant. 6°
Le commerçant vérifie la signature de la banque pour s ’assurer que l’ordre de paiement est légitime.
7° Le commerçant porte l’ordre de paiement à la banque. 8°
La banque vérifie sa signature et contrôle sa base de données pour vérifier qu ’un ordre de paiement avec la même chaîne aléatoire unique n’a pas déjà été déposé auparavant. Si tout est en ordre, la banque crédite le compte du commerçant du montant de 1000 francs. La banque enregistre la chaîne aléatoire unique dans sa base de données.
9° Si cet ordre de paiement a déjà été déposé auparavant, la banque n’acceptera pas l’ordre de paiement.
Dès lors, si Alice essaie d ’utiliser une photocopie de l’ordre de paiement, ou si le com merçant essaie d ’encaisser une photocopie de l’ordre de paiement, la banque le détec tera.
Protocole n° 3 Le protocole précédent protège la banque de la tricherie mais il ne permet pas l’identifi cation du tricheur. La banque ne sait pas si la personne qui a acheté l’ordre de paiement (la banque ne peut pas savoir que c ’est Alice) a essayé de rouler le commerçant ou si le commerçant a essayé de rouler la banque. Le protocole suivant corrige ce défaut :
1° Alice prépare 100 ordres de paiement anonymes de 1000 francs chacun. Sur chaque ordre de paiement elle ajoute une chaîne aléatoire différente et unique, suffisamment longue pour que les chances qu’un autre utilisateur utilise la même chaîne soient négligeables.
2° Alice place chacun d’entre eux avec une feuille de carbone dans 100 enveloppes différentes. Elle donne le tout à la banque.
6.4
Argent électronique
15S
3° La banque ouvre 99 enveloppes et confirme qu’il s ’agit bien d’ordres de paiement pour un montant de 1 0 0 0 francs, et que les chaînes aléatoires uniques sont bien différentes.
4° La banque signe la dernière enveloppe non ouverte. La signature passe à travers le carbone sur l’ordre de paiement. La banque rend l’enveloppe non ouverte à Alice et retire 1 000 francs de son compte.
5° Alice ouvre l’enveloppe et utilise l’ordre de paiement chez un commerçant. 6°
Le commerçant vérifie la signature de la banque pour s ’assurer que l’ordre de paiement est légitime.
7° Le commerçant demande à Alice d’écrire une chaîne d’identification aléatoire sur l’ordre de paiement. 8°
Alice s ’exécute.
9° Le commerçant apporte l’ordre de paiement à la banque. 10° La banque vérifie la signature et contrôle sa base de données pour vérifier qu’un ordre de paiement avec la même chaîne aléatoire unique n’a pas déjà été déposé auparavant. Si tout est en ordre, la banque crédite le compte du commerçant du montant de 1000 francs. La banque enregistre la chaîne aléatoire unique et la chaîne aléatoire d’identification dans sa base de données. 1 1
° Si la chaîne aléatoire unique est dans sa base de données, la banque refuse d’accepter l’ordre de paiement. Ensuite, elle compare la chaîne d’identification avec celle qui est enregistrée dans sa base de données. Si c ’est la même, la banque sait que c ’est le commerçant qui a fait une photocopie de l’ordre de paiement. Si elle est différente, la banque sait que c ’est la personne qui a acheté l’ordre de paiement qui l’a photocopié.
Ce protocole fait l’hypothèse que le commerçant ne peut pas modifier la chaîne d’iden tification une fois qu’Alice l’a écrite sur l’ordre de paiement. L’ordre de paiement peut avoir une suite de petites cases que le commerçant demandera à Alice de remplir avec des X ou des O. L’ordre de paiement serait fait de papier qui se déchire si l’on tente d’effacer. Comme l’interaction entre le commerçant et la banque a lieu après qu’Alice a dépensé l’argent, le commerçant reste avec un mauvais ordre de paiement sur les bras. Des réalisations pratiques de ce protocole nécessitent qu’Alice attende près de la caisse pendant l’interaction entre le commerçant et la banque tout comme pour les cartes de crédit aujourd’hui. Alice peut essayer de rouler le commerçant. Elle peut essayer d ’utiliser une copie de l’ordre de paiement une seconde fois en donnant la même chaîne d ’identification à l’étape 7. A moins que le commerçant n’enregistre les ordres de paiement qu’il reçoit dans une base de données, le commerçant se fera rouler. Le protocole suivant élimine ce défaut.
Protocole n° 4 S’il s’avère que la personne qui a acheté l’ordre de paiement a essayé de rouler le commerçant, il incombe à la banque de déterminer l’identité du tricheur. Pour ce faire nous devons quitter le monde matériel pour celui de la cryptographie.
Chapitre 6
154
Protocoles ésotériques
La technique du morcellement de secret peut être utilisée pour cacher le nom d’Alice dans l’ordre de paiement numérique.
1° Alice prépare n ordres de paiement anonymes d’une somme donnée. Chaque ordre de paiement contient une chaîne aléatoire unique différente, X , assez longue pour que la chance d’en avoir deux identiques soit négligeable. Sur chaque ordre de paiement, il y a aussi n paires de chaînes de bits d ’identifi cation, I i ,l 2 , . . . ,In- Cela fait n paires différentes sur chaque chèque. Chacune de ces paires est engendrée de la façon suivante: Alice crée une chaîne qui contient son nom, son adresse et toute autre information que la banque désire quant à son identité. Ensuite elle coupe cette chaîne en deux morceaux en utili sant le protocole de morcellement de secret (voir § 3.6). Enfin elle met en gage chaque morceau en utilisant un protocole de mise en gage de bits. Par exemple, I37 est constituée de deux parties : Iz7G et IyjD■ Chaque partie est un paquet de bits mis en gage dont on peut demander l’ouverture à Alice, et dont l’ouverture correcte peut être instantanément vérifiée. Toute paire I ^ G et h rD’ Par exemple, révèle l’identité d’Alice (mais pas l 37G et h%D). Chacun des ordres de paiement ressemble à ceci : Montant : . . . francs Chaîne unique: X Chaîne d’identification: I\ = (I\G,lyD) h = { h a J 2 D)
ln 2°
(^nci^np)
Alice camoufle les n ordres de paiement en utilisant le protocole de signature aveugle. Elle donne le tout à la banque.
3° La banque demande à Alice de retirer le camouflage de n — 1 ordres de paie ment et confirme qu’ils sont conformes. La banque vérifie le montant, la chaîne unique et demande à Alice de révéler toutes les chaînes d’identification.
4° Si la banque constate qu’Alice n’a pas fait de tentative de tricherie, elle signe Tordre de paiement camouflé restant. La banque rend à Alice l ’ordre de paie ment camouflé et retire le montant de son compte.
5° Alice retire le camouflage de Tordre de paiement et l’utilise chez un commer çant. 6°
Le commerçant vérifie la signature de la banque pour s ’assurer de la légitimité de Tordre de paiement.
7° Le commerçant demande à Alice de révéler aléatoirement la moitié gauche ou la moitié droite de chacune des chaînes d’identité de Tordre de paiement. En fait, le commerçant donne à Alice une chaîne d e sélection aléatoire de n bits: bi, b-2 , ..., bn. Alice ouvre soit la partie gauche, soit la partie droite de L suivant que bi vaut 0 ou 1. 8°
Alice s ’exécute.
9° Le commerçant porte l’ordre de paiement à la banque.
6.4
Argent électronique
155
10° La banque vérifie la signature et contrôle sa base de données ■pour vérifier qu’un ordre de paiement avec la même chaîne aléatoire unique n’a pas été déposé auparavant. Si tout est en ordre, la banque crédite le compte du commerçant du montant de 1000 francs. La banque enregistre la chaîne aléatoire unique et toutes les informations d’identification dans sa base de données.
11° Si la chaîne aléatoire unique est dans sa base de données, la banque refuse d’accepter l’ordre de paiement. Ensuite, elle compare la chaîne d’identification sur l’ordre de paiement avec celle qui est enregistrée dans sa base de données. 5* c 'est la même, la banque sait que c ’est le commerçant qui a fait une photo copie de l ’ordre de paiement. Si elle est différente, la banque sait que c ’est la personne qui a acheté l’ordre de paiement qui l’a photocopié. Comme le second commerçant — qui a accepté l’ordre de paiement d’Alice — lui a donné une autre chaîne de sélection que le premier commerçant, la banque trouvera une position de bit où l’un des commerçants a demandé d’ouvrir la moitié gauche et l’autre commerçant a demandé d’ouvrir la moitié droite. La banque calcule le ou exclusif des deux moitiés pour retrouver l’identité d’Alice.
C’est un protocole étonnant, aussi regardons-le sous différents angles. Alice peut-elle tricher? Son ordre de paiement numérique n’est rien d ’autre qu’une chaîne de bits, donc elle peut la copier. L’utiliser une première fois ne pose pas de problème : elle exécute tout le protocole et tout va très bien. Le commerçant lui donnera une chaîne de sélection aléatoire à l’étape 7 et Alice ouvrira soit la partie gauche, soit la partie droite de chaque I, à l’étape 8 . A l’étapelO, la banque enregistrera toutes ces données ainsi que la chaîne unique de l’ordre de paiement. Quand Alice essaie d ’utiliser le même ordre de paiement numérique une seconde fois, le commerçant (soit le même commerçant soit un autre) lui donnera une autre chaîne de sélection aléatoire à l’étape 7. Alice doit s’exécuter à l’étape 8 : ne pas le faire signalerait immédiatement l’anomalie au commerçant. Si le commerçant apporte l’ordre de paiement à la banque à l’étape 1 0 , la banque remarquera immédiatement qu’un ordre de paiement avec la même chaîne unique a déjà été déposé. La banque compare alors les moitiés ouvertes des chaînes d ’identification. Les chances que les deux chaînes de sélection soient les mêmes sont de 1 pour n ; cela a peu de chance de se produire d’ici à la prochaine ère glaciaire. La banque trouve alors une paire dont la moitié gauche a été ouverte la première fois et la moitié droite a été ouverte la deuxième fois. Elle calcule le ou exclusif des deux moitiés et découvre le nom d’Alice. La banque sait qui a essayé d’utiliser cet ordre de paiement deux fois. Le protocole ne nécessite pas la présence d ’Alice tandis que la banque et le commerçant exécutent leur part du protocole. Ce n’est que si Alice triche que la banque connaît son identité. Alice ne peut pas empêcher que son identité soit révélée. Elle ne peut pas modifier la chaîne unique ni les chaînes d’identification car dans ce cas la signature de la banque ne serait plus valable. Le commerçant s’en rendrait immédiatement compte à l’étape 6 . Alice peut essayer subrepticement de faire passer un ordre de paiement aux dépens de la banque, un ordre sur lequel les chaînes d’identification ne révéleraient pas son nom ou mieux encore, un ordre dont les chaînes d’identification donneraient le nom de quelqu’un d’autre. Les chances de réussir cette ruse à l’étape 3 sont de 1 sur n. Ce n’est pas si improbable que cela mais si la pénalité est assez lourde, Alice n’essaiera
156
Chapitre 6
Protocoles ésotériques
pas. Ou, vous pouvez augmenter le nombre d ’ordres de paiement qu’Alice doit préparer à l’étape 2 . Est-ce que le commerçant peut tricher? Ses chances sont encore moins grandes. Il ne peut pas encaisser l’ordre de paiement deux fois : la banque détecterait la double utilisation de la chaîne de sélection. Il ne peut pas reporter la faute sur Alice, seule Alice peut ouvrir les chaînes d ’identification. Même une collusion entre Alice et le commerçant ne peut pas duper la banque. Comme la banque signe l’ordre de paiement avec la chaîne unique, elle est sûre de ne payer cet ordre qu’une fois. Qu’en est-il de la banque? A-t-elle un moyen de déterminer qu’un ordre de paiement encaissé a été signé pour Alice? Alice est protégée par le protocole de signature en aveugle des étapes 2 à 5. La banque ne peut faire le lien, même si elle garde un enre gistrement complet de toutes les transactions. Bien mieux, la banque et le commerçant n’ont aucun moyen de se mettre ensemble pour déterminer qui est Alice. Alice peut entrer dans le magasin et dans le plus complet anonymat faire ses achats. Estelle peut tricher. Elle peut espionner la communication entre Alice et le commerçant, et si elle peut aller à la banque avant lui, elle peut porter l’ordre de paiement à la banque en premier. La banque l’acceptera, et même pire, quand le commerçant viendra porter son ordre de paiement, il sera suspecté de tricherie. Si Estelle vole et dépense l’argent électronique d’ Alice avant cell-ci, c’est Alice qui sera suspectée de tricherie. Il n’y a aucun moyen d ’empêcher cela; c ’est la conséquence directe de l’anonymat procuré par l’argent électronique. Alice et le commerçant doivent tous les deux protéger leurs bits comme ils le feraient avec des billets. Ce protocole se situe quelque part entre les protocoles arbitrés et les protocoles autoarbitrés. Alice et le commerçant font confiance à la banque pour qu’elle honore les ordres de paiement, mais Alice n’a pas confiance dans la banque en ce qui concerne son identité.
Argent électronique et crime parfait L’argent électronique a aussi son mauvais côté. Parfois, les gens ne veulent pas autant d’anonymat. Observons Alice en train de commettre le crime parfait [1577] : 1
° Alice kidnappe un bébé.
2
° Alice prépare 10000 ordres de paiement anonymes de
1
000 francs chacun (ou
autant qu ’elle veut pour le montant qu ’elle veut).
3° Alice camoufle les 10 000 ordres de paiement en utilisant un protocole de signa ture en aveugle. Elle envoie les résultats aux autorités en menaçant de tuer le bébé si les instructions suivantes ne sont pas suivies à la lettre : ( a )
faites signer les 1 0 0 0 0 ordres de paiement par une banque;
(b) publiez les
résultats dans un quotidien.
4° Les autorités s ’exécutent. 5° Alice achète le journal, retire le camouflage des ordres de paiement, et com mence à les utiliser. Les autorités n’ont aucun moyen de faire le lien entre les ordres de paiement et Alice.
6.4
Argent électronique
157
6° Alice libère le bébé. Cette situation est autrement dramatique que toute autre impliquant des biens ma tériels (de l’agent liquide par exemple). Comme il n’y a pas de contact physique, la police a moins de chances d’appréhender le ravisseur. En général, cependant, l’argent électronique n’est pas une bonne affaire pour les crimi nels. Le problème vient du fait que l’anonymat ne marche que dans un sens: l’acheteur est anonyme, mais pas le vendeur. De plus, le vendeur ne peut pas cacher le fait qu’il a reçu de l’argent électronique. Avec l’argent électronique, le gouvernement pourra faci lement déterminer combien d ’argent vous recevez, mais pas comment vous le dépensez.
Argent électronique pratique Une société néérlandaise, D ig i C a s h , possède la plupart des brevets existants en la matière, et a réalisé des protocoles d ’argent électronique dans des produits qui fonc tionnent. Toute personne intéressée doit contacter DigiCash BV, Kruislaan 419, 1098 VA Amsterdam, Pays-Bas.
Autres protocoles d’argent électronique Il existe d’autres protocoles d’argent électronique; voir [708, 6 6 , 736, 1635, 985]. Certains d’entre eux mettent en jeu des mathématiques assez compliquées. En général, on peut distinguer diverses catégories de protocoles d ’argent électronique. Dans les systèmes en ligne, le commerçant doit communiquer la banque à chaque vente, ce qui ressemble aux protocoles actuels de carte de crédit. S’il y a un problème, la banque reffuse d’encaisser et Alice ne peut pas tricher. Dans les systèmes au ton om es, comme le protocole n° 4, aucune communication entre le commerçant et la banque n’est nécessaire durant la transaction. Ces systèmes n’em pêchent pas Alice de tricher, mais détectent toute tricherie éventuelle. Alice sait que cela arrivera, aussi elle ne triche pas. Une autre solution est de créer une carte à mémoire spéciale (voir § 24.13) contenat une puce résistante à l’investigation appelée observatrice [336, 346, 391]. La puce observatrice garde une mini-base de données contenant toutes les dépenses d’argent électronique faites avec cette carte. Si Alice essaye de copier de l’argent électronique et de le dépenser deux fois, la puce observatrice détectera la tentative et empêchera la transaction. Comme la puce résiste à l’investigation, Alice ne peut effacer la mini-base de données sans endommager la carte. L ’argent peut passer de main en main, et quand il est finalement déposé, la banque peut déterminer qui a triché, s’il y a lieu. Les protocoles d’argent électronique peuvent être classés selon un autre critère. Dans les systèmes de porte monnaie électronique, on utilise des sommes fixes; on a alors besoin de différentes pièces représentant différents montants. Les chèques électro niques permettent de régler n’importe quel montant jusqu’à une valeur maximale et la partie non dépensée est rendue pour se faire rembourser. Deux excellents et complètement différents protocoles d’argent électronique autonomes se trouvent dans [227, 228, 229] et [565, 567, 566]. Un système appelé N e t C a s h pré sente des propriétés d ’anonymat plus restreintes [1057, 1056]. Un autre système récent est [293].
Chapitre 6
158
Protocoles ésotériques
Dans [1219], Tat.suaki O k a m o t o et Kazuo O h t a donnent la liste de 6 propriétés que devrait satisfaire un système d’argent, électronique idéal : 1. L ’indépendance. La sécurité de l’argent électronique ne doit dépendre d ’aucune localisation physique. L’argent peut être transféré par des réseaux informatiques. 2. Sécurité. L ’argent électronique ne peut pas être copié et réutilisé. 3. Anonymat (absence de possibilité d ’identifier l’émetteur). L ’anonymat des utilisateurs est protégé : personne ne peut retrouver les liens entre les utilisa teurs et les achats. 4. Paiement hors-ligne. Quand un utilisateur paie un achat avec de l’argent élec tronique, le protocole entre l’utilisateur et le commerçant est exécuté hors-ligne. C ’est-à-dire, que le commerce n’a pas à être relié à un ordinateur central pour traiter le paiement de l’utilisateur. 5. Transférabilité. L’argent électronique peut être transféré à d’autres utilisateurs. 6.
Divisibilité. Une pièce d ’argent électronique d ’un certain montant peut être subdivisée en pièces d ’argent plus petites de montants moins élevés. (Bien sûr, les totaux doivent être corrects au bout du parcours.)
Les protocoles présentés ici satisfont les propriétés 1, 2, 3 et 4 mais pas 5 et 6 . Il existe des systèmes d ’argent électronique en-ligne qui satisfont toutes les propriétés sauf la quatrième [322, 417, 1252]. Le premier système d ’argent électronique hors-ligne qui satisfait les propriétés 1, 2, 3 et 4, similaire à ceux décrits ci-avant, est décrit dans [344]. O k a m o t o et O h t a proposent un système qui satisfait les propriétés 1 à 5 [1217] ; ils proposent également un système qui satisfait les propriétés 1 à 6 mais le volume des données à traiter pour l’achat d ’un seul article est approximativement de 200 méga-octets. Un autre système de porte monnaie électronique est décrit dans [524]. Le schéma d ’argent électronique proposé dans [1219], des mêmes auteurs, satisfait les propriétés 1 à 6 mais sans la nécessité de cet énorme volume de données. La taille totale du transfert de données pour un seul achat est d ’environ 2 0 kilo-octets et le protocole peut être effectué en quelques secondes. Les auteurs considèrent que c ’est le premier système d ’argent électronique idéal sans possibilité d’identification de l’acheteur.
Cartes de crédit anonymes Ce protocole [998] utilise plusieurs banques différentes pour préserver l’identité du consommateur. Chaque consommateur possède un compte dans deux banques diffé rentes. La première banque connaît l’identité de la personne et lui procure du crédit. La seconde ne connaît le consommateur que sous un pseudonyme (similaire à un compte numéroté dans une banque Suisse). Le consommateur peut retirer des fonds dans la seconde banque en prouvant que le compte est bien le sien. Cependant la banque ne connaît pas la personne et ne veut pas lui donner de crédit. La première banque connaît le client et transfert les fonds vers la seconde banque— sans savoir le pseudonyme. Le consommateur peut alors dépenser ces fonds de manière anonyme. A la fin du mois, la seconde banque donne une note à la première banque, dont la solvabilité lui inspire confiance. La première banque
6.4
Argent électronique
159
passe la note au consommateur; elle a confiance en sa solvabilité puisqu’elle le connaît. Quand le consommateur paye, la première banque transfert des fonds additionnels vers la seconde banque. Toutes les transactions se font par un intermédiaire, qui agit comme une banque d’Etat électronique: il instaure des comptes entre les banques, fait passer les messages et créé des relevés. Les échanges entre le client, le marchant, et les diverses banques sont abordés dans [998]. A moins que tout le monde ne se ligue contre le client, son anonymat est assuré. Cependant, ce n’est pas de l’argent électronique, la banque peut facilement tricher. Le protocole procure aux clients les avantages de la carte de crédit sans dévoiler leur vie privée.
Deuxième partie Techniques cryptographiques
Chapitre 7
Longueur des clefs 7.1
Longueur des clefs secrètes
La sécurité d’un cryptosystème à clef secrète dépend de deux choses : la solidité de l’algorithme et la longueur de la clef. La première caractéristique est plus importante mais la deuxième est plus facile à illustrer. Faisons l’hypothèse que la solidité de l’algorithme est parfaite. Cela est très difficile à réaliser en pratique mais nous supposerons que c’est faisable dans cet exemple. Par solidité parfaite, je veux dire qu’il n’existe pas de meilleur moyen de casser le crypto système que d’essayer toutes les clefs possibles : on parlera alors d ’attaque exhaustive. Pour lancer une telle attaque, un cryptanalyste a besoin d ’un petit bout de texte chiffré et du texte en clair correspondant; une attaque exhaustive est une attaque à texte en clair connu. Dans le cas d’un chiffrement par blocs, le cryptanalyste aura besoin d ’un bloc de texte chiffré et du texte en clair correspondant: en général 64 bits. Obtenir cette paire de texte chiffré et de texte en clair est plus facile que vous ne pourriez l’imaginer. Un cryptanalyste peut obtenir une copie d’un message en clair par certains moyens et intercepter le texte chiffré correspondant. U est possible qu’il connaisse quelque chose sur le format du texte chiffré; par exemple, c’est un fichier écrit sous W o r d , il est précédé de l’entête standard des courriers électroniques, c’est un fichier répertoire UNIX, une image au format T IF F , ou encore une fiche standard dans une base de donnée. Tous ces formats présentent des octets prédéfinis. Le cryptanalyste n’a pas besoin de texte en clair pour lancer cette attaque. Il est facile de calculer la complexité d’une attaque exhaustive. Si la clef a 8 bits, il y a 28 = 256 clefs possibles. Il faudra donc 256 tentatives pour trouver la bonne clef et en moyenne 128 suffiront. Si la clef a 56 bits, il y a alors 2 56 k 7,2 x 10ie clefs possibles. En faisant l’hypothèse qu’un super-ordinateur peut essayer un million de clefs par seconde, il faudra 2 000 ans pour trouver la bonne clef. Si la clef a 64 bits, il faudra alors 600 000 ans à ce même super-ordinateur pour trouver la bonne clef parmi les 2 64 « 1 , 8 x 1 0 19 clefs possibles. Si la clef a 128 bits, il faudra 1025 années. L ’univers est âgé d’environ 1010 ans, et donc 1025 ans est probablement suffisant. Avec une clef de 2 048 bits, un million de super-ordinateurs hypothétiques travaillant en parallèle passeraient 1 0 597 années pour trouver la clëf. D ’ici là, l’univers peut déjà avoir implosé ou s’être répandu dans le néant.
164
Chapitre 7
Longueur des clefs
Avant de vous précipiter pour inventer un cryptosystème avec une clef de 8 kilo-octets, rappelez-vous qu’il y a une autre condition à satisfaire : l’algorithme doit être suffisam ment solide pour qu’il n’y ait pas d ’autre attaque possible que l’attaque exhaustive. Ce n’est pas aussi facile qu’il y paraît. La cryptographie est un art subtil. Les cryptosys tèmes qui semblent parfaits sont souvent mauvais. Des cryptosystèmes solides peuvent être grandement affaiblis par de toutes petites modifications. Deux cryptosystèmes so lides utilisés ensemble sans précautions peuvent interagir entre eux et produire des textes codés faciles à déchiffrer. Le meilleur conseil que l’on puisse donner au cryp tographe amateur est de suspecter tout nouvel algorithme et ce, même avec un petit brin de paranoïa. Il vaut mieux avoir confiance en un algorithme parce que des crypto graphes professionnels l’ont examiné sous toutes ses coutures pendant de nombreuses années sans trouver de failles, plutôt que parce que les inventeurs d ’un algorithme clament haut et fort que leur algorithme est inviolable. Rappelez vous une remarque importante faite au paragraphe 1.1 : la sécurité d’un cryp tosystème doit résider dans la clef et non pas dans les détails de l’algorithme. Faites toutes les hypothèses suivantes : 1 - 1 ’attaquant a accès à tous les détails de votre algo rithme. 2 —il a accès à autant de texte chiffré qu’il le souhaite et il peut attaquer votre algorithme grâce à des textes chiffrés seulement. 3- il peut monter une attaque à texte en clair. 4—il peut monter une attaque à texte en clair choisi. Si votre cryptosystème reste sûr même avec toute cette connaissance dans les mains de l’attaquant, alors vous avez atteint le niveau de sécurité souhaitable. Cet avertissement mis à part, il y a suffisamment de marge de manœuvre dans le domaine de la cryptographie. Dans la vie de tous les jours, il y a des situations où un tel niveau de sécurité n’est pas vraiment nécessaire. La plupart des attaquants n’ont pas les connaissances et les ressources de nos Gouvernements, et même ceux qui ont de tels moyens ne sont pas forcément intéressés à casser votre cryptosystème. Si vous avez l’intention de comploter pour renverser un Gouvernement, alors tenez-vous en aux algorithmes éprouvés décrits à la fin de cet ouvrage. Pour les autres : amusez-vous !
Estimation du temps et du coût d’une attaque exhaustive Rappelez vous qu’une attaque exhaustive est une attaque à texte en clair connu; elle ne requiert qu’une petite quantité de texte chiffré et de texte en clair correspondant. Si vous faites l’hypothèse que l’attaque la plus efficace contre un algorithme est une attaque exhaustive (une hypothèse très forte s’il en est !), quelle doit être la longueur de la clef pour qu’une telle attaque soit impraticable? Deux paramètres déterminent la vitesse d’une attaque exhaustive : le nombre de clefs à tester et la vitesse de chaque test. La plupart des algorithmes à clef secrète acceptent comme clef n’importe quel motif de bits de longueur fixe. L’algorithme DES a une clef de 56 bits, il y a donc 256 clefs possibles. Certains algorithmes présentés dans cet ouvrage ont une clef de 64 bits ; il y a donc 264 clefs possibles pour de tels algorithmes. D ’autres encore ont une clef de 128 bits. La vitesse à laquelle on peut tester une clef est un facteur déterminant mais, toutefois, il est moins important. Dans ce qui suit, je ferai l’hypothèse que le temps mis pour tester une clef est le même pour tous les algorithmes. Dans la réalité, pour un algorithme donné, une clef pourrait être testée deux, trois voire même dix fois plus vite que pour un autre algorithme. Ce petit facteur n ’est pas important car ce que nous regardons ci-après c ’est ce qui rend une attaque exhaustive impraticable par un facteur « un
7.1
Longueur des clefs secrètes
165
million » ou plus ! La communauté cryptographique s’est surtout concentrée sur l’ attaque exhaustive de l’algorithme DES. En 1977, Whitfield D i f f i e et Martin H e l l m a n [495] ont décrit une machine hypothétique. Elle serait composée d’un million de processeurs et chacun de ces processeurs serait capable de tester un million de clefs par seconde. Une telle machine pourrait tester 256 clefs en 20 heures. Si une telle machine était construite pour attaquer une clef de 64 bits, elle testerait les 264 clefs en 214 jours. L’attaque exhaustive est faite pour les processeurs parallèles. Chaque processeur peut tester un sous-ensemble des clefs. Les processeurs n’ont pas à communiquer entre eux : la seule communication nécessaire est un message indiquant la réussite et la clef pour laquelle elle a été obtenue. U n’y a pas de contraintes de mémoire partagée. Il est facile de concevoir une telle machine parallèle avec un million de processeurs, chacun d ’entre eux calculant indépendamment des autres. Plus récemment, Michael Wiener a décidé de concevoir une machine spécialement dé diée à la recherche exhaustive [1599, 1600] L II a conçu des puces et des cartes spéciali sées. Après estimation des prix, il s’est aperçu qu’on pouvait construire pour 1 million de dollars une machine capable de casser une clef de 56 bits dans un temps moyen de trois heures et demi (et sept heures au pire). De plus le rapport prix sur vitesse est linéaire. Le tableau 7.1 donne une généralisation de ces résultats pour différentes longueurs de clef. Rappelez vous de la loi de M o o r e : la puissance de calcul des or dinateurs double tous les 18 mois environ. Cela signifie que le coût est divisé par 10 tous les cinq ans; ce qui coûte 1 million de dollars en 1995 sera construit pour 100 000 dollars en l’an 2000. Les ordinateurs systoliques pourraient même faire mieux [726].
- Estimation du temps moyen d’une attaque exhaustive par une machine dédiée construite en 1995.
Tab. 7.1
Coût 100 K$ IMS 10 M$ 100 M$ 1 G$ 10 G$ 100 G$ 1 G$ 10 G$
40 2 sec. 0 ,2 sec. 0 ,0 2 sec. 2 millisec. 0 , 2 millisec. 0 ,0 2 millisec. 2 microsec. 0 ,2 microsec. 0 ,0 2 microsec.
Longueur de la clef en bits 64 80 56 1 an 35 heures 700 siècles 3,5 heures 37 jours 70 siècles 2 1 min. 4 jours 7 siècles 2 min. 9 heures 70 ans 13 sec. 7 ans 1 heure 1 sec. 5,4 min. 245 jours 0 , 1 sec. 32 sec. 24 jours 3 sec. 2,4 jours 0 , 0 1 sec. 1 millisec. 0,3 sec. 6 heures
112
128
ans 1 0 1 3 ans 1 0 1 2 ans 1 0 1 1 ans 1 0 10 ans 1 0 9 ans 1 0 8 ans 1 0 7 ans 1 0 ® ans
1 0 19
1 0 14
1 0 18 1 0 17 1 0 16 1 0 15 1 0 14 1 0 13 1 0 12 10 11
ans ans ans ans ans ans ans ans ans
Pour les clefe de 56 bits, c’est à la portée de la plupart des grandes entreprises et de nombreuses organisations criminelles. Les budgets militaires des nations les plus industrialisées permettraient de construire une machine à casser les clefs de 64 bits. Casser une clef de 80 bits est toujours hors de portée, mais si la tendance actuelle continue, cela changera dans 30 ans seulement. U est bien sûr ridicule d ’estimer la puissance des ordinateur à venir dans 30 ans. Une avancée dans quelque technologie de science-fiction pourrait faire de ces chiffres 1. II a conçu la machine pour DES, mais l’analyse tient pout la plupart des algorithmes.
166
Chapitre 7
Longueur des clefs
une histoire drôle. À l’opposé, des limitations physiques encore inconnues pourraient impliquer qu’ils sont exagérément optimistes. En cryptographie, il vaut mieux être pessimiste. Opter pour un algorithme avec des clefs de 80 bits semble une vue à très court terme. Il faut des clefs d ’au moins 112 bits. Si un attaquant veut vraiment trouver une clef, tout ce qui lui reste à faire est de dé penser le montant nécessaire. En conséquence, il semble prudent d’estimer la « valeur » minimale d ’une clef: quelle valeur peut être attribuée à une clef avant que cela n’ait un sens économique de la trouver ? Pour donner un exemple extrême, si un message en clair vaut 1,39 $, cela n’aurait pas grand sens de dépenser 10 million de dollars pour trouver la clef. D ’un autre côte, si le message en clair vaut 100 million de dollars, alors le déchiffrement de ce seul message justifierait la dépense. Notons aussi que la valeur de certains messages décroît rapidement avec le temps.
Méthodes logicielles de recherche exhaustive Sans matériel spécialisé et sans machines massivement parallèles, une attaque exhaus tive est significativement plus difficile. Une attaque exhaustive par logiciel est environ 1 0 0 0 fois plus lente qu’avec une machine dédiée. L’avantage d’une attaque exhaustive par logiciel n’est pas sa rapidité mais bien le fait qu’elle est « gratuite ». Cela ne coûte rien de faire chercher des clefs à un micro ordinateur quand il ne fait rien d’autre. S’il trouve une clef, tant mieux. S’il n’en trouve pas, rien n’est perdu. Rien n’empêche de mettre un réseau entier de micro-ordinateurs à la tâche. Une expérience récente avec l’algorithme DES a utilisé le temps libre de 40 stations de travail pour tester 234 clefs en un seul jour [605]. A cette vitesse, cela prendrait 4 millions de jours pour tester toutes les clefs mais si suffisamment de gens essaient une attaque telle que celle-là, quelqu’un, quelque part sera peut-être chanceux, comme il est dit dans [605] : « Le nœud d’une attaque par logiciel est la pure malchance. Imaginez un ré seau informatique universitaire avec 512 stations de travail mises en réseau. Sur certains campus ce serait un réseau de taille moyenne. Elles pourraient même être répandues de par le monde et elles coordonneraient leur activité par courrier électronique. Faisons l’hypothèse que chaque station de travail est capable d’effectuer 15 000 chiffrements par seconde ... En tenant compte du surcoût pour tester une clef et passer à la clef suivante, ce chiffre est ramené à 8 192 tests par seconde par machine. Pour essayer toutes les clefs possibles [de 56 bits] cela prendrait ainsi 545 ans (en faisant l’hypothèse que le réseau est dédié à cette tâche 24 heures par jour). Notez qu’avec ces données cela donne à nos étudiants casseurs de code une chance sur 200 000 de trouver une clef en un jour. Sur un long week-end, leurs chances passent à 1 sur 66000. Plus le matériel est rapide, ou plus il y a d ’ordina teurs disponibles, plus leurs chances augmentent. Ce ne sont pas de bons rapports pour gagner au tiercé mais cela n’est cependant pas acceptable. De tels rapports sont meilleurs que ce que la loterie nationale offre. « Une chance sur un million? » « Cela ne peut pas se reproduire en mille ans? » Il n’est plus possible honnêtement de dire de telles choses. Est-ce un risque acceptable de nos jours ? »
7.1
Longueur des clefs secrètes
167
L’utilisation d’un algorithme avec une clef de 64 bits au lieu de 56 bits rend ce type d’attaque 256 fois plus difficile. Avec une clef de 40 bits, la situation est nettement plus dramatique. Un réseau de 400 ordinateurs, chacun capable de faire 32 000 chiffrements par seconde, peut effectuer une attaque exhaustive contre une clef de 40 bits en une seule journée2. L’utilisation d’une clef de 128 bits rend une telle attaque ridicule à envisager. L’industrie estime que d ’ici à 1996, il y aura 200 millions d ’ordinateurs de par le monde. Cette estimation inclut tout depuis les super-ordinateurs Cray jusqu’aux nanoordinateurs. Si tous ces ordinateurs coopéraient à une attaque exhaustive à raison de 1 million de chiffrements par seconde, cela prendrait encore 1 million de fois l’âge de l’univers pour trouver la clef.
Réseaux neuronaux Les réseaux neuronaux ne sont pas très utiles pour la cryptanalyse, premièrement à cause de la forme de l’espace des solutions. Les réseaux neuronaux sont efficaces dans les problèmes où il y a une continuité des solutions, certains plus que d’autres. Ceci permet à un réseau neuronal d ’apprendre et de proposer des solutions de plus en plus adaptées au fur et à mesure. Les opportunités d’apprendre quelque chose quand on casse un algorithme sont rares: soit on retrouve la clef, soit on ne la retrouve pas3. Les réseaux neuronaux marchent bien dans les environnements structurés où il y a quelque chose à apprendre mais pas dans le monde de grande entropie et d ’apparent chaos qu’est la cryptographie.
Virus La difficulté majeure dans une attaque de cette ampleur est de convaincre chaque utilisateur individuel de se prêter à l’expérience. Vous pourriez demander poliment mais cela prendrait trop de temps. Pire même, ils pourraient refuser. Vous pourriez essayer d’investir leurs machines la nuit mais ce serait encore plus coûteux en temps. De plus, vous risqueriez de finir en prison pour violation de domicile. Les virus informatiques pourraient répandre un programme de recherche exhaustive de clef efficacement sur un nombre maximum d’ordinateurs. Cette idée, particulièrement insidieuse, a été présentée pour la première fois dans [1595]. L’attaquant écrit un virus informatique et le lâche dans la nature. Ce virus-là ne refor mate pas le disque dur, ou ne détruit pas des fichiers ; tout ce qu’il fait c’est travailler à une attaque exhaustive quand l’ordinateur n’a rien d ’autre à faire. Différentes études ont montré que les micro-ordinateurs sont inactifs 70 % à 90 % du temps. Ainsi le virus n’aurait aucune difficulté pour trouver du temps pour accomplir sa tâche. Si par ailleurs il est bénin, il peut même passer inaperçu en continuant sa tâche. Éventuellement, une des machines infectées trouvera la bonne clef. A ce point, il y deux manières de procéder. Premièrement, le virus peut donner naissance à un nouveau virus différent. Celui-ci ne ferait rien d ’autre que se répandre et détruire toute copie de son ancêtre, tout en transportant de machine en machine l’information concernant la bonne 2. En 1992, les algorithmes RC2 et RC4 ont été autorisés à l’exportation hors des Etats-Unis pour autant que leur clef soit restreinte à 40 bits (voir § 13.8). 3. Du moins, c’est vrai quand l’algorithme est bon.
Chapitre 7
168
Longueur des clefs
clef. Lors de ses pérégrinations, il finirait par atterrir sur la machine de celui qui a lancé l’attaque initiale. Une autre approche plus subtile consisterait à afficher le message suivant sur l’écran de l’ordinateur infecté qui a trouvé la bonne clef : Il y a un problème sérieux à cet ordinateur. Veuillez appeler le numéro de téléphone 1-800-123-4567 et lire le nombre de 64 bits suivant à l ’opérateur: xxxx xxxx xxxx xxxx Il y a une prime de 100 $ à la première personne qui communiquera cette information. Quelle est l’efficacité d’une telle attaque? Faisons l’hypothèse qu’un ordinateur infecté essaie 1 000 clefs par seconde. C ’est nettement moins que ce que l’on attendrait comme vitesse, mais n’oublions pas que cet ordinateur est sensé accomplir d’autres tâches. Faisons également l’hypothèse qu’un tel virus peut infecter 10 millions d ’ordinateurs. Le virus pourrait casser une clef de 56 bits en 83 jours et une clef de 64 bits en 58 ans. Vous devrez peut-être corrompre les auteurs de vaccins informatiques mais c’est votre problème. Toute augmentation de la vitesse des micro-ordinateurs ou du nombre d’ordinateurs rendrait bien évidemment cette attaque plus efficace.
La loterie chinoise La « loterie chinoise » est une suggestion originale mais réalisable pour une machine massivement parallèle pour attaquer l’algorithme DES [1289]. Imaginez que l’on incor pore une puce de recherche exhaustive de clef, capable de faire un million de tests par seconde dans chaque radio et dans chaque télévision nouvellement construits. Chaque puce est programmée pour tester un ensemble différent de clefs et ce automatiquement, dès qu’elle reçoit une paire « texte en clair, texte chiffré » sur les ondes. Alors chaque fois que le Gouvernement chinois veut casser une clef, il diffuse les données et toutes les radios et les télévisions du pays se mettent à la tâche. Eventuellement, la bonne clef apparaîtra sur l’écran de télévision de quelqu’un, quelque part dans le pays. Le Gouvernement chinois paie alors un prix à cet heureux gagnant d’une loterie un peu particulière. Grâce à la promesse d’une récompense, le Gouvernement est sûr que la bonne clef sera transmise correctement et en prime, cela favorise la vente de radios et de télévisions contenant cette puce spéciale. Si chaque homme, femme et enfant en Chine possède une radio ou une télévision, la bonne clef, pour un algorithme qui utilise 56 bits pour la clef, sera trouvée en 64 secondes. Si seulement un chinois sur dix possède une radio ou une télévision (ce qui est plus proche de la réalité), alors la bonne clef apparaîtra au bout de 11 minutes. La bonne clef pour un algorithme à 64 bits apparaîtra au bout de 4 heures et demie (45 heures si seulement un chinois sur dix possède une radio ou une télévision). Certaines modifications sont nécessaires pour rendre cette attaque praticable. Premiè rement, il serait plus facile que chaque puce essaie des clefs aléatoires au lieu d’un ensemble prédéterminé de clefs. Cela ne ralentirait l’attaque que de 39 % (pas grand chose en comparaison des chiffres que nous manipulons). De plus, le parti commu niste chinois devrait convaincre chaque personne d ’écouter ou de regarder une certaine
7.1
Longueur des clefs secrètes
169
émission à un certain moment de la journée pour être sûr que toutes les radios et télé visions sont opérationnelles au moment de la diffusion de la paire « texte en clair, texte chiffré ». Finalement, chacun recevrait comme instruction de contacter le Central-PeuImporte-Son-Nom si jamais une clef apparaît à l’écran et de lire les nombres qui y figurent. Le Parti pourrait même transformer cela en loterie : la personne qui trouve la clef, reçoit un prix. Le tableau 7.2 montre l’efficacité de la loterie chinoise pour différents pays et pour différentes longueurs de clef. La Chine est clairement en bonne position pour conduire une telle attaque, mais elle devrait équiper chaque homme, femme et enfant de sa propre radio ou télévision. Les Etats-Unis ont moins d ’habitants mais beaucoup plus d’équipement par tête d’habitant. L’état du Wyoming pourrait casser une clef de 56 bits rien qu’à lui seul en moins d’un jour. Tab. 7.2 —Estimations pour une attaque exhaustive pour la loterie chinoise (les données concernant la population et le nombre de radios et télévisions proviennent de « 1995 World Almanac and Book o f Facts ») _____________________________________________
Contrée Chine Etats-Unis Irak Israël Wyoming (USA) Morehead, NC (U SA)
Population (approx.) 1190431000 260 714000 19890000 5051000 470 000 6100
Nombre de télévisions et radios 257000000 739000000 4730000 3 640000 1330000 17300
Temps nécessaire Clef de 56 bits Clef de 64 bits 280 secondes 20 heures 97 secondes 6,9 heures 4,2 heures 44 jours 5,5 heures 58 jours 160 jours 15 heures 48 jours 34 années
Biotechnologie Si les biopuces sont possibles, il serait alors idiot de ne pas s’en servir pour construire un outil d’attaque exhaustive répartie. Considérez un animal hypothétique, malencon treusement appelé « DESosaure » [1289]. Il est constitué de cellules biologiques capables de tester les clefs possibles. La paire « texte en clair-texte chiffré » est diffusée aux cellules par un canal optique (ces cellules sont transparentes, vous voyez). Les solutions sont transmises à l’organe vocal du DESosaure par l’intermédiaire de cellules spéciales qui se propagent dans le système circulatoire de l’animal. Un dinosaure typique a 1014 cellules (sans compter les bactéries). Si chacune d’entre elles est capable d ’effectuer un million de chiffrements par seconde (d’accord, cela est un grand « si »), retrouver une clef de 56 bits prendrait sept dix millièmes de seconde. Retrouver une clef de 64 bits prendrait moins de deux dixièmes de seconde. Retrouver une clef de 128 bits prendrait encore 1 0 1 1 années, malgré tout. Une autre approche biologique serait d’utiliser des algues modifiées génétiquement pour la cryptographie et qui seraient capables d’effectuer des attaques exhaustives contre les algorithmes cryptographiques [1289]. Ces organismes rendraient possible la réalisation d’une machine distribuée avec plus de processeurs, car ils pourraient couvrir une grande surface. La paire « texte en clair-texte chiffré » pourrait être diffusée par satellite. Si un organisme trouve le résultat, il pourrait induire un changement de couleur des cellules voisines pour communiquer le résultat en retour au satellite.
170
Chapitre 7
Longueur des chefs
Faites l’hypothèse qu’une cellule d ’algue typique a la taille d ’un cube de 10 fi de côté (cela est probablement une large estimation), alors 1 0 1 5 d’entre elles peuvent remplir un mètre cube. Déversez-les dans l’océan pour couvrir une superficie de 518 km2, sur une épaisseur d’eau d ’un mètre (vous vous débrouillez pour savoir comment faire — moi je suis juste celui qui a les idées), et vous aurez 1 0 23 d ’entre elles flottant sur l’océan (ce qui représente plus de 380 milliards de litres4). Si chacune d ’entre elles peut essayer un million de clefs par seconde, elles retrouveront la clef d’un algorithme avec une clef de 128 bits en juste un peu plus de 100 ans5. Des percées dans la vitesse de calcul des algues, du diamètre des algues ou même dans la taille de la flaque sur l’océan pourraient réduire ces nombres de façon significative. Ne me parlez même pas de la nanotechnologie.
Limitations thermodynamiques Selon le second principe de la thermodynamique, une certaine quantité d ’énergie est nécessaire pour représenter de l’information. Enregistrer un simple bit en changeant l’état d’un sytème requiert une quantité d ’énergie supérieure à kT, où T est la tempé rature fondamentale du système et A; la constante de B o l t z m a n . (Restez avec moi, la leçon de physique est presque terminée.) Etant donné que k = 1,38.10” 16 et que la température ambiante de l’univers est de 3,2, un ordinateur idéal marchant à 3,2 consommerait 4,4.10 ~ 16 à chaque modification ou effacement d ’un bit. Faire tourner un ordinateur à une température plus basse que le rayonnement cosmique environnant demanderait un apport énergétique suplémentaire pour faire fonctionner une pompe à chaleur. Maintenant, le soleil dégage chaque année une énergie égale à 1 ,2 1 .1041 environ. C’est assez pour effectuer 2 ,7 .1 0 56 changements de bit dans notre ordinateur idéal; et assez pour qu’un compteur de 18 7 bits prenne toutes ses valeurs. En construisant une sphère de D y s o n autour du soleil et en captant toute son énergie pendant 32 ans, notre ordinateur pourrait compter jusqu’à 2 192. Bien-sûr il ne resterait pas assez d ’énergie pour effectuer d’autres opérations utiles avec ce compteur. Mais il s’agit juste d ’une étoile, pas très douée pour cela. Une supemova moyenne dégage quelque chose comme 1051. (Environ cent fois plus d ’énergie serait dégagée sous forme de neutrinos, mais laissons les passer pour l’instant.) Si toute cette énergie pouvait être canalisée afin d ’effectuer un seul calcul gigantesque, un compteur de 219 bits pourrait passer par tous ses états. Ces nombres n’ont rien à voir avec la technologie du matériel; ils sont les bornes supé rieures autorisées par la thermodynamique. Et ils impliquent fortement qu’une attaque exhaustive contre des clefs de 256 bits restera impossible jusqu’à ce que les ordinateurs soient construits avec autre chose que de la matière et fonctionnent ailleurs que dans l’espace.
7.2
Longueur des clefs publiques
Les fonctions à sens unique ont été traitées dans le paragraphe 2.3. Multiplier deux grands nombres premiers est une fonction à sens unique ; il est facile de multiplier les 4. Par comparaison, la catastrophe de VExxon Valdez a répandu 38 millions de litres de pétrole. 5. L’explosion démographique résultante des algues est votre problème.
7.2
Longueur des clefs publiques
171
nombres pour obtenir un produit, mais difficile de factoriser ce produit et de retrouver les deux grands nombres premiers (voir § 11.3). La cryptographie à clef publique utilise l’idée de faire une fonction à sens unique à brèche secrète. En fait, c ’est un mensonge ; factoriser est supposé être un problème dur (voir § 11.4). Pour chacun d’entre-nous, il semble l’être. Mais même s’il l’est, personne ne peut prouver que les problèmes durs le sont vraiment. La plupart d ’entre-nous pensons que factoriser est dur, mais cela n’a jamais été prouvé mathématiquement, d’une façon ou d’une autre. Il est intéressant de s’y attarder un peu. Il est facile de s’imaginer dans 50 ans, en train de se remémorer le bon vieux temps où l’on pensait que la factorisation était dure, où la cryptographie était basée sur cette factorisation et où des entreprises gagnaient de l’argent dans ce domaine. Il est facile d ’imaginer que les développements futurs en théorie des nombres rendront la factorisation plus simple ou que les développements en théorie de la complexité rendront la factorisation triviale. Il n’y a aucune raison de croire que ceci arrivera (et la plupart des personnes qui en savent assez pour se faire leur propre opinion vous diront que c’est peu probable) mais il n’y a non plus pas de raison de croire que cela n’arrivera pas. Dans tous les cas, aujourd’hui, les algorithmes dominants de chiffrement à clef pu blique sont basés sur la difficulté de factoriser des grands nombres qui sont le produit de deux grands nombres premiers. (D ’autres algorithmes reposent sur une chose ap pelée problème logarithmique discret mais, pour le moment, supposons que le même raisonnement s’applique.) Ces algorithmes sont aussi sensibles aux attaques exaustives, mais d’un type différent. Casser ces algorithmes ne veut pas nécessairement dire es sayer toutes les clefs possibles ; casser ces algorithmes veut dire essayer de factoriser un grand nombre (ou de prendre des logarithmes discrets dans un très grand corps fini — un problème similaire). Si le nombre est trop petit, vous n ’avez aucune sécurité. Si le nombre est assez grand, vous êtes protégé contre toute la puissance de calcul mon diale jusqu’à ce que le soleil devienne une nova (étant donnée la connaisance actuelle des mathématiques). Le paragraphe 11.3 parle de factorisation avec plus de détails mathématiques ; je me limiterai ici au temps nécessaire pour factoriser des nombres de longueurs variables. Factoriser des grands nombres est dur. Hélas pour les concepteurs d ’algorithmes, cela devient plus facile. Pis encore, cela devient plus facile plus rapidement que les ma thématiciens l’avaient prévu. En 1976, Richard G u y écrivait : « Je serais surpris que quiconque puisse factoriser régulièrement des nombres d’une taille de 1 0 80 sans forme spéciale durant ce siècle. » [681]. En 1977, Ron RlVEST disait que factoriser un nombre à 125 chiffres prendrait 40 quadrillions d’années [602]. En 1994, un nombre à 129 chiffres a été factorisé [71]. S’il y a là une leçon à retenir, c’est bien que faire des prédictions est stupide. Le tableau 7.3 montre les records de factorisation des douzes dernières années. L’algorithme de factorisation le plus rapide était alors le crible quadratique (voir § 11.3). Ces chiffres sont assez effrayants. Il est commun aujourd’hui de voir des nombres de 512 bits utilisés dans des systèmes opérationnels. Les factoriser, et par conséquent compromettre leur sécurité, est tout à fait dans le domaine du possible: l’utilisation de toutes les machines reliées à l’Internet durant une paire de jours fériés y suffirait. La puissance de calcul est généralement mesurée en mips-ans : un ordinateur effectuant un million d’instructions par seconde (mips) pendant une année, soit à peu près 3 * 1013 instructions. Par convention, une machine d ’ 1 mips est équivalente au DEC VAX
172
Chapitre 7
T a b . 7.3
Année 1983 1985 1988 1989 1993 1994
Longueur des clefs
- Factorisation utilisant le crible quadratique
Nombre de décimales des nombres factorisés 71 80 90 12 0
Combien de fois un nombre de 512 bits est plus dur à factoriser > 2 0 millions > 2 millions 250000 30000 500
129
10 0
10 0
11/780. Donc un mips-an est l’équivalent d ’un VAX 11/780 tournant pendant un an. (Un Pentium 100 MHz est une machine de 50 mips; une machine Paragon d ’Intel à 1800 processeurs est une machine de 50000 mips.) En 1983, factoriser un nombre à 71 chiffres demandait 0,1 mips-an ; la même opération en 1994 avec un nombre à 129 chiffres demandait 5000 mips-an. Cette augmentation insensée de la puissance de calcul est principalement le résultat de l’introduction du calcul distribué, utilisant le temps d ’inactivité des stations de travail d ’un réseau. Cette tendance a été initiée par Bob S i l v e r m a n et développée par Arjen L e n s t r a et Mark M a n a s s e . En 1983, factoriser prenait 95 heures CPU sur un seul Cray X-M P ; en 199A cela nécessitait 5000 mips-ans et utilisait le temps d’inactivité de 1600 ordinateurs à travers le monde pendant environ huit mois. Les méthodes modernes de factorisation se prêtent à ce genre de distribution des tâches. La situation s’empire encore. Un nouvel algorithme de factorisation a remplacé le crible quadratique : le crible général sur corps numérique. En 1989, les mathématiciens vous auraient dit que le crible général sur corps numérique ne serait jamais pratique. En 1992, ils vous auraient dit que c’était pratique, mais seulement plus rapide que le crible quadratique dans les cas de nombres à plus de 130 à 150 chiffres. Aujourd’hui, il est reconnu être plus rapide que le crible quadratique pour des nombres compre nant bien moins de 116 chiffres [504, 637]. Le crible général sur corps numérique peut factoriser un nombre de 512 bits plus de 10 fois plus rapidement que le crible qua dratique. L’algorithme tournerait moins d’un an sur un Paragon Intel 1800. Le ta bleau 7.4 nous donne le nombre de mips-ans nécessaires pour factoriser des nombres de différentes tailles, en considérant les applications actuelles du crible général sur corps numérique [1195].
Tab.
7.4 - Factorisation utilisant le crible général sur corps numérique Nombre de bits 512 768 1024 1280 1536 2048
Mips-ans nécessaires pour factoriser 30000 2 * 10 8 3*10n 1 * 1 0 14 3 * 1016 3 * 102°
7.2
Longueur des clefs publiques
113
Le crible général sur corps numérique est de plus en plus rapide. Les mathématiciens trouvent toujours des nouvelles optimisations, des nouvelles techniques. Il n’y a aucune raison de penser que cette tendance ne continuera pas. Un algorithme voisin, le crible spécial sur corps numérique, peut déjà factoriser des nombres d’une forme spécialisée (ce sont des nombres généralement pas utilisés pour la cryptographie) bien plus rapidement que le crible général sur corps numérique peut factoriser des nombres généraux de même taille. Il n’est pas déraisonnable de penser que le crible général sur corps numérique peut être optimisé pour aller aussi vite [1195] ; il est d ’ailleurs fort possible que la NSA sache déjà comment faire. Le tableau 7.5 donne le nombre de mips-ans nécessaires pour que le crible spécial sur corps numérique factorise des nombres de différentes longueurs [1195].
Tab.
7.5 - Factorisation utilisant le crible spécial sur corps numérique Nombre de bits 512 768 1024 1280 1536 2048
Mips-ans nécessaires pour factoriser <200 10 0 0 0 0
3 * 107 3 * 109 2 * 1 0 11 4 * 1014
Lors d’un atelier de l’Institut européen pour la sécurité des systèmes en 1991, les participants ont convenu qu’un module de 1024 bits devrait être suffisant pour des secrets à long terme jusqu’en 2005 [157]. Néanmoins, ils ajoutèrent: « Bien que les participants de cet atelier pensent être les plus qualifiés dans leurs domaines respectifs, cette déclaration [concernant la durabilité de la sécurité] devrait être considérée avec beaucoup de prudence. » C ’est un bon conseil. Le cryptographe avisé est très prudent lorsqu’il choisit la longueur de clefs publiques. Pour déterminer de quelle longueur de clef vous avez besoin, il faut que vous considériez à la fois le niveau de sécurité désiré et la durée de vie de la clef, ainsi que le nec plus ultra de la factorisation. Aujourd’hui, vous avez besoin d’un nombre de 1024 bits pour avoir le niveau de sécurité que vous aviez en 1980 avec un nombre de 512 bits. Si vous voulez que vos clefs restent sûres pour les 20 prochaines années, 1024 bits sont probablement insuffisants. Même si vos secrets ne valent pas l’effort investit pour factoriser votre module, vous êtes peut-être en danger. Imaginez un système bancaire automatique qui utilise le RSA pour la sécurité. Martin peut aller devant la justice et déclarer : « Avez-vous lu dans les journaux qu’en 1994 le RSA-129 a été cassé et que les nombres de 512 bits peuvent être factorisés par toute organisation prête à dépenser quelques millions de dollars et à attendre quelques mois? Pour sa sécurité, ma banque utilise des nombres à 512 bits, et j’en profite pour vous dire que ce n’est pas moi qui ait effectué ces septs retraits. » Même si Martin ment, il est probable que le juge somme la banque de s’expliquer. Mais alors, pourquoi ne pas utiliser des clefs de 10000 bits? Vous pouvez, mais sachez que plus votre clef sera longue, plus vous passerez de temps à la calculer. Vous voulez une clef assez longue pour qu’elle soit sûre, mais assez courte pour que le calcul soit faisable.
Chapitre 7
174
Longueur des clefs
Un peu plus haut dans ce paragraphe, j ’ai dit que faire des prédictions est stupide. Je vais maintenant en faire quelques-unes. Le tableau 7.6 regroupe mes recommandations pour les longueurs de clefs publiques, selon le niveau de sécurité de votre clef que vous désirez. Il y a trois longueurs de clefs pour chaque année, une pouvant supporter les attaques individuelles, une sûre pouvant supporter les attaques d’une entreprise majeure, et une pouvant supporter les attaques d’un gouvernement.
T a b . 7.6
Année 1995 2000
2005 2 0 10
2015
- Longueurs recommandées de clefs publiques (en bits)
contre un individu 768 1024 1280 1280 1536
contre une entreprise 1280 1280 1536 1536 2048
contre un gouvernement 1536 1536 2048 2048 2048
Voici quelques hypothèses de [71] : « Nous pensons pouvoir acquérir 100 000 machines sans développer d ’efforts surhumains et en toute probité. En fait, nous ne lâcherions pas un virus sur Internet pour trouver les ressources pour nous. Beaucoup d’organisations ont chacune des milliers de machines sur le réseau. Les utiliser demanderait une grande diplomatie, mais ne devrait pas être impossible. En considérant la puissance moyenne de 5 mips et une durée d ’un an, il ne semble pas trop déraisonnable de s’embarquer sur un projet qui exigera un demi-million de mips-ans. » Le projet de factorisation d ’un nombre à 129 chiffres a mobilisé à peu près 0,03 pourcent de la puissance de calcul globale d’Internet [1195], et ils n’ont vraiment pas forcé. Il est raisonnable de penser qu’un projet ayant fait l’objet d’une bonne campagne de publicité puisse mobiliser 2 pourcents de la puissance de calcul mondiale pendant une année. Supposons qu’un cryptanalyste puisse mettre la main sur 10000 mips-ans, une grande entreprise peut en avoir 107 et un gouvernement 10°. Supposons également que la puissance de calcul augmente d’un facteur 10 tous les cinq ans. Enfin, supposons que les progrès mathématiques en matière de factorisation nous permettent de factoriser des nombres généraux à la vitesse du crible spécial sur corps numérique. (Ce n’est pas encore possible, mais cette avancée pourrait survenir à tout moment.) Le tableau 7.6 recommande différentes longueurs de clefs pour la sécurité en différentes années. N’oubliez pas de prendre la valeur de la clef en considération. Les clefs publiques sont souvent utilisées pour sécuriser des choses de grande valeur pour une longue durée: la clef maîtresse d’une banque pour un système d ’argent électronique, la clef qu’un gouvernement utilise pour certifier ses passeports ou la clef publique d ’une signature électronique d’un notaire. Cela ne vaut probablement pas la peine de passer des mois de calcul pour casser la clef privée d’un individu, mais si vous pouvez imprimer votre propre argent avec une clef que vous avez cassé, l’idée devient plus attrayante. Une clef de 1024 bits est assez longue pour signer quelque chose qui sera vérifié dans la semaine,
7.2
Longueur des clefs publiques
175
le mois, ou même quelques années. Mais vous ne voulez sûrement pas vous retrouver devant la justice dans 2 0 ans avec un document signé électroniquement et voir la partie opposée démontrer comment contrefaire un document avec la même signature. Faire des prédictions au-delà d ’un future proche est encore plus insensé. Qui connait les progrès qui vont être effectué en calcul, en matière de réseau et en mathématiques d’ici à l’an 2020? Néanmoins, si on considère la situation d’un point de vue général, pour chaque décade, nous pouvons factoriser des nombres deux fois plus longs que la décade précédente. Ceci nous mène au tableau 7.7. T ab. 7.7 - Prédictions de factorisation à long terme Année 1995 2005 2015 2025 2035 2045
Longueur de clef (bits) 1024 2048 4096 8192 16384 32 768
D’un autre côté, la technologie de factorisation peut atteindre son apogée bien avant 2045. D’ici vingt ans, nous serons peut-être capable de factoriser n’importe quel nombre. Je pense néanmoins que ceci est très peu probable. Tout le monde ne sera pas d ’accord avec mes recommandations. La NSA a mandaté des clefs de 512 à 1024 bits pour leur standard de signature électronique (voir § 20.1), ce qui est bien moins que ce que je recommande pour une sécurité à long terme. Pretty Good Privacy (voir § 24.12) a une longueur de clef RSA maximum de 2047 bits. Arjen LENSTRA, le plus célèbre « factorisateur » mondial, refuse de faire des prédictions audelà de 10 ans [960]. Le tableau 7.8 nous livre les recommandations sur la longueur de clef de Ron R i v e s t , faites en 1990, que je considère bien trop optimistes [1334]. Bien que son analyse paraisse correcte sur papier, les événements récents montrent que des surprises arrivent régulièrement. Il semble logique de choisir ses clefs afin de se protéger de futures surprises. T ab . 7.8
- Recommandations optimistes de Année 1990 1995 2000
2005 2 0 10
2015 2020
Faible 398 405 422 439 455 472 489
R
iv e s t
Moyenne 515 542 572 602 631 661 677
sur la longueur de clef (en bits)
Elevée 1289 1399 1512 1628 1754 1884 2017
Les estimations les plus basses parlent d’un budget de 25 000 dollars, de l’algorithme du crible quadratique et d ’un progrès technologique de 20 pourcents par an. Les es timations moyennes parlent d ’un budget de 25 millions de dollars, de l’algorithme du
176
Chapitre 7
Longueur des clefs
crible général sur corps numérique et d ’un progrès technologique de 33 pourcents par an. Enfin, les estimations les plus optimistes avancent un budget de 25 milliards de dollars, un algorithme du crible général quadratique tournant à la vitesse du crible spécial sur corps numérique et un progrès technologique de 45 pourcents par an. Il est toujours possible qu’un progrès en matière de factorisation me surprenne, mais j ’ai intégré ceci dans mes calculs. Mais pourquoi me faire confiance? Je viens de prouver ma stupidité en faisant des prédictions.
Calculs biologiques Maintenant, cela devient étrange. En 1994, Léonard M. A d l e m a n a trouvé une mé thode pour résoudre un problème N P —complet (voir § 1 1 .2 ) dans un laboratoire de biochimie, en utilisant des molécules d ’ADN pour représenter les solutions du pro blème [21]. (Ici, par « solutions », on entend « réponses » et non pas « liquide conte nant des substances ».) Le problème qu’ A d l e m a n a résolu était un cas particulier du problème de trouver un chemin orienté Hamiltonien : soit une carte avec des villes connectées par des routes à sens unique, trouvez un chemin de la ville A à la ville Z qui ne passe exactement qu’une seule fois par chaque ville de la carte. Chaque ville était représentée par des chaînes aléatoires distinctes de 20 bases d ’ADN ; avec les techniques conventionnelles de biologie moléculaire, A d l e m a n a synthétisé 50 picomoles (30 mil lions de millions de molécules) de la chaîne d’ADN représentant chaque ville. Chaque route était aussi représentée par une chaîne de 20 bases d ’ADN, mais ces chaînes n’ont pas été choisies de façon aléatoire : elles ont été choisies judicieusement de manière à ce que la fin de la chaîne d’ADN représentant la route de la ville P à la ville K (« route P K ») ait tendance à se rapprocher de la chaîne d’ADN représentant la ville P , et que la fin de la route P K ait tendance à se rapprocher de la ville K . A d l e m a n a synthétisé 50 picomoles d’ADN représentant chaque route, les a mixé tous ensemble avec l’ADN représentant toutes les villes et a ajouté un enzyme ligase qui noue ensemble les bouts de molécules d ’ADN. La relation judicieuse entre les chaînes d’ADN de la route et les chaînes d’ADN de la ville fait que la ligase lie les chaînes d’ADN de la route entre-elles de manière légale. C ’est-à-dire que l’issue de la route qui va de P à A sera toujours reliée au début d ’une route qui part de la ville K , jamais à l’issue d ’une autre route ou au début d’une route qui part d’une ville autre que K . Après un temps de réaction minutieusement limité, la ligase a construit un grand nombre de chaînes d ’ADN représentant des chemins multiroutes légaux bien qu’aléatoires sur la carte. De cette soupe de chemins aléatoires, A d l e m a n peut retrouver la plus infime trace (peut-être même une seule molécule) d ’ADN qui représente la réponse au problème. En utilisant les techniques communes de la biologie moléculaire, il écarte toutes les chaînes d ’ADN qui représentent des chemins trop longs ou trop courts. (Le nombre de routes dans le chemin cherché doit être égal au nombre de villes moins un.) Ensuite, il écarte toutes les chaînes d ’ADN qui ne passent pas par la ville A, puis celles qui ne passent pas par la ville B, etc... S’il reste un ADN à l’issue de cette série d ’éliminations, la séquence de routes qu’il décrit est la solution au problème de découverte d ’un chemin orienté Hamiltonien. Par définition, toute instance d ’un problème N P —complet peut être transformé, en temps polynomial, en une instance de tout autre problème N P —complet, et par consé quent en un problème de découverte d ’un chemin orienté Hamiltonien. Depuis les an
7.2
Longueur des clefs publiques
177
nées 1970, les cryptologues ont essayé d ’utiliser les problèmes N P —c o m p l e t s pour la crypotographie à clef publique. Bien que le cas résolu par A d l e m a n fut modeste (sept villes sur sa carte, une énigme qui peut être résolue en réfléchissant quelques minutes), la technique en est à ses balbutiements et ne rencontrerait aucun obstacle à être étendue à des problèmes plus conséquents. C ’est pourquoi, les arguments à propos des protocoles cryptographiques basés sur des problèmes N P c o m p l e t s , arguments qui jusqu’alors commen çaient par « Supposons qu’un adversaire possède un million de processeurs, chacun d’entre-eux pouvant effectuer un million de tests par seconde, » pourraient bientôt de venir « Supposons qu’un adversaire possède un millier de lieux de fermentation, chacun ayant une capacité de 2 0 0 0 0 litres. »
Ordinateurs quantiques Attention, cela devient encore plus étrange. Le principe sous-jacent de l’ordinateur quantique inclut la dualité onde-particule découverte par Albert E i n s t e i n . Un photon peut simultanément exister dans un grand nombre d ’états. L ’exemple classique est celui du photon qui se comporte comme une onde quand il rencontre un mirroir partiellement argenté ; il est à la fois réfléchi et transmis. C ’est tout comme une vague qui vient se jeter sur une digue qui comporte une petite ouverture, la vague sera refoulée mais passera un peu à travers la digue. Néanmoins, quand un photon est mesuré, il se comporte comme une particule et un seul état peut être détecté. Dans [1449], Peter S h o r nous montre une conception d e machine à factoriser qui repose sur les principes de la mécanique quantique. A l’inverse d’un ordinateur classique, qui en fait est dans un état unique, fixe, à un moment donné, un ordinateur quantique a une fonction d ’onde interne, qui est une superposition d ’une combinaison des états de base possibles. Les calculs transforment la fonction d ’ondulation, modifiant ainsi tout l’ensemble des états en une seule opération. De cette façon, un ordinateur quantique est une amélioration par rapport à l’automate classique à état fini : il utilise les propriétés quantiques afin de factoriser en temps polynomial ; ce qui nous permet théoriquement de casser les cryptosystèmes basés sur la factorisation ou le problème du logarithme discret. Le consensus est que les ordinateurs quantiques sont compatibles avec les lois fonda mentales de la mécanique quantique. Néanmoins, il est peu probable qu’une machine de factorisation quantique soit construite dans le futur. Un obstacle majeur est le pro blème de décohérence qui fait que des formes ondulatoires superposées perdent leur distinction et que l’ordinateur ne marche pas. La décohérence implique qu’un ordi nateur quantique fonctionnant à 1 Kelvin ne marche pas plus d ’une nanoseconde. De plus, un très grand nombre de portes serait nécessaire pour construire une machine de factorisation quantique ; cela peut rendre sa construction impossible. Le concept de SHOR nécessite un module complet d’exponentiation en arithmétique modulaire. Aucune horloge interne ne peut être utilisée, alors des millions, voire des milliards de portes seraient nécessaires pour factoriser des nombres cryptographiquement signifi catifs. Si n portes quantiques ont une probabilité minimum p d ’échouer, le nombre moyen d’essais par coup réussi est de (1/(1 — p))n- Le nombre de portes nécessaires croît polynômialement avec la longueur en bits du nombre, donc le nombre d’essais nécessaires serait superexponentiel en la longueur des nombres utilisés (ce qui est pire que factoriser par des divisions).
Chapitre 7
178
Longueur des clefs
Ainsi, alors que la factorisation quantique attire de nombreux chercheurs, il est extrê mement peu probable qu’elle soit jamais mise en pratique. Mais ne dites pas que je ne vous ai pas prévenu.
7.3
Comparaison de la longueur des clefs secrètes et des clefs publiques
Un système sera attaqué au niveau de son point faible. Si vous concevez un système qui utilise à la fois les cryptographies à clef secrète et à clef publique, les longueurs de clefs pour chaque type de cryptographie devront être choisies de façon à ce qu’il soit aussi difficile d ’attaquer le système via l’un ou l’autre des mécanismes. Il n’est pas logique d ’utiliser un algorithme à clef secrète de 128 bits avec un algorithme à clef publique de 386 bits, de même qu’il n’est pas logique d ’utiliser un algorithme à clef secrète de 56 bits avec un algorithme à clef publique de 1024 bits. Le tableau 7.9 donne les longueurs des modules des algorithmes à clef publique dont la difficulté de factorisation égale à peu près la difficulté d’une attaque exaustive pour les longueurs de clefs secrètes usuelles.
T ab . 7.9 - Longueurs des clefs secrètes et des clefs publiques avec résistances similaires
aux attaques exhaustives_____________________________________________
Longueur de clef secrète 56 bits 64 bits 80 bits 1 1 2 bits 128 bits
Longueur de clef publique 384 bits 512 bits 768 bits 1792 bits 2304 bits
Ce tableau nous dit que si vous êtes assez soucieux pour votre sécurité pour choisir un algorithme à clef secrète avec une clef de 1 1 2 bits, alors vous devriez choisir une longueur de module d ’au moins 1792 bits pour votre algorithme à clef publique. En général, vous devriez choisir une longueur de clef publique plus sûre que votre longueur de clef secrète. Les clefs publiques demeurent généralement plus longtemps et sont utilisées pour protéger plus d’informations.
7.4
Attaques des anniversaires contre une fonction de hachage à sens unique
Il y a deux attaques exhaustives pour une fonction de hachage à sens unique. La première est la plus évidente: soit H (A i), l’empreinte d’un message, un adversaire aimerait être capable de créer un autre document, A i', tel que II(A i) = II(A i'). La seconde attaque est plus subtile: un adversaire aimerait trouver deux messages aléatoires, A i et A i ', tel que H (A i) — H (A i'). Cela s’appelle une collision et c’est une attaque bien plus facile que la première.
Quelle doit être la longueur de clef?
7.5
179
Le paradoxe de l’anniversaire est un problème statistique standard. Combien de per sonnes doit-il y avoir dans une pièce pour qu’il y ait de bonnes chances qu’au moins l’une d’entre-elles ait la même date d’anniversaire que vous? La réponse est 253. Maintenant, combien de personnes doit-il y avoir pour qu’il y ait de bonnes chances qu’au moins deux d’entre-elles aient la même date d ’anniversaire? La réponse est surprenante: 23. Avec seulement 23 personnes dans une pièce, il y a tout de même 253 paires différentes de personnes. Trouver quelqu’un avec une date d ’anniversaire spécifique est analogue à la première at taque ; trouver deux personnes avec la même date d’anniversaire aléatoire est analogue à la seconde attaque. Cette seconde attaque est plus connue sous le nom d’attaque des anniversaires. Supposons qu’une fonction de hachage à sens unique est sûre et que la meilleure attaque est l’attaque exaustive. Elle produit un résultat à m bits. Trouver un message dont l’em preinte a une valeur donnée exigerait de hacher 2m messages aléatoires. Trouver deux messages qui ont la même empreinte n’exigerait de hacher que 2 m / 2 messages aléa toires. Une machine qui hâche un million de messages par seconde mettrait 600 000 ans pour trouver un second message qui correspondrait à une empreinte donnée de 64 bits. Cette même machine pourrait trouver une paire de messages de même empreinte en à peu près une heure. Comprenez que si les attaques des anniversaires vous inquiètent, vous devriez choisir une valeur de hachage deux fois plus longue que celle que vous pensez être nécessaire. Par example, si vous voulez réduire les chances que quelqu’un casse votre système à moins de 1 pour'2 80, utilisez une fonction de hachage à sens unique à 160 bits.
7.5
Quelle doit être la longueur de clef?
Il n’y a pas de réponse unique à cette question ; cela dépend de la situation. Pour déterminer le niveau de sécurité dont vous avez besoin, vous devez vous poser quelques questions. Que valent vos données? Combien de temps doivent-elles rester confiden tielles? Quelles sont les ressources de vos adversaires? Une liste client peut bien valoir 1 000 dollars. Les données financières d ’un divorce houleux doivent bien valoir 10000 dollars. Monter une campagne de publicité et de marketing d’un produit d’une grande société vaut sûrement 1 million de dollars. Les clefs maîtresses d ’un système d’argent électronique valent des milliards. Dans le monde commercial, les secrets doivent seulement être gardés pendant quelques minutes. Dans l’industrie journalistique, les secrets d ’aujourd’hui font les grands titres de demain. Les informations concernant le développement de produits doivent sûrement rester secrètes pendant un an ou deux. Les données du recensement américain sont légalement gardées secrètes pendant 1 0 0 ans. La liste des invités pour la fête d’anniversaire de votre sœur n’intéresse que vos proches curieux. Les secrets commerciaux d ’une compagnie intéressent les compagnies rivales. Les secrets militaires intéressent des puissances miütaires rivales. Vous pouvez même spécifier vos desiderata de sécurité en ces termes. Par exemple : La longueur de clef doit être telle qu’il n’y ait pas une probabilité de plus de 1 pour 2 32 qu’un attaquant disposé à dépenser 1 0 0 millions de dollars puisse casser le système en moins d ’un an, même en faisant l’hypothèse
180
Chapitre 7
Longueur des clefs
que la technologie progresse à un taux de croissance de 30 % par an sur la période. Le tableau 7.10, emprunté partiellement à [157], estime le niveau de sécurité requis pour plusieurs types d ’informations.
Tab.
7.10 - Niveau de sécurité nécessaire pour différents types d’informations
Type de trafic
Longévité
Informations militaires tactiques Annonces de produits, fusions, taux d’intérêt Plans d’affaires à long terme Secrets commerciaux (e.g. la recette du Coca-Cola) Secrets de la bombe H Identités d ’espions Affaires privées Embarras diplomatiques Données du recensement américain
minutes/heures
Longueur de clef minimum 56-64 bits
j ours/semaines années
64 bits 64 bits
décades > 40 ans > 50 ans > 50 ans > 65 ans 1 0 0 ans
bits 128 bits 128 bits 128 bits au moins 128 bits au moins 128 bits 112
La puissance de calcul future est plus difficile à évaluer, mais à vue de nez : l’efficacité des équipements de calcul divisée par le prix double tous les 18 mois et augmente d’un facteur 10 tous les 5 ans [100]. Donc, d ’ici à 50 ans, les ordinateurs les plus rapides seront 10 milliards de fois plus rapides qu’aujourd’hui ! Gardons à l’esprit que ces chiffres ne prennent en compte que des ordinateurs génériques ; qui sait quel type de système de recherche cryptographique exhaustive pourra être développé d’ici à 50 ans? En faisant l’hypothèse qu’un algorithme cryptographique sera utilisé pendant 30 ans, vous pouvez avoir une idée du niveau de sécurité qu’il doit offrir. Un algorithme conçu aujourd’hui ne sera probablement pas d’un usage généralisé avant l’an 2 0 0 0 et sera tou jours utilisé en l’an 2025 pour chiffrer des messages qui devront rester secrets jusqu’en 2075 ou plus tard.
7.6
Avertissement
Ce chapitre entier ne veut absolument rien dire. La notion de prédiction de la puis sance de calcul dans les 10 années à venir, sans parler des 50 prochaines années, est absolument ridicule. Ces calculs ne doivent être qu’une indication, rien de plus. Si le passé est une indication, le futur sera bien différent de tout ce qu’on a pu prévoir. Soyez prudent. Si vos clefs sont plus longues qu’il vous semble nécessaire, alors moins de surprises technologiques vous concerneront.
Chapitre 8
Gestion des clefs Alice et Bernard ont un système de communication sûr. Ils jouent au poker en aveugle, ils signent simultanément des contrats et échangent même de l’argent électronique. Leurs protocoles sont sûrs. Leurs algorithmes sont le nec plus ultra. Malheureusement, ils achètent leurs clefs à la société C l e f s e t c o n f i a n c e d’Estelle dont le slogan est « Vous pouvez nous faire confiance : la sécurité est le deuxième nom de l’ex-belle-mère de notre voyageur de commerce. » Estelle n’a pas à casser les algorithmes. Elle ne compte pas sur les failles subtiles dans les protocoles. Elle peut utiliser leurs clefs pour lire tous les messages entre Alice et Bernard sans lever le moindre petit doigt cryptographique. Dans le monde réel, la gestion des clefs est la partie de la cryptographie la plus difficile. Concevoir des algorithmes et des protocoles sûrs n’est pas chose aisée mais vous pouvez compter sur un corps important de recherche académique. Garder les clefs secrètes est encore plus dur. Les cryptanalystes attaquent souvent les algorithmes à clef secrète et les algorithmes à clef publique par leur gestion des clefs. Pourquoi Estelle s’évertuerait-elle à casser un algorithme cryptographique quand il lui est plus facile de retrouver les clefs à cause d ’un relâchement dans les procédures de gestion des clefs? Pourquoi devrait-elle dépenser 1 0 millions de dollars pour construire une machine de cryptanalyse alors que 1 0 0 0 dollars suffirait à corrompre un employé? Dépenser 1 million de dollars pour acheter un employé des communications occupant un poste stratégique au sein d’une ambassade diplomatique peut se révéler être une vrai affaire. Les W a l k e r s ont vendu pendant des années aux soviétiques les clefs de chiffrement de la marine américaine. Le directeur du contre-espionnage de la C IA s’est vendu pour moins de 2 millions de dollars, femme incluse. C’est beaucoup moins onéreux que de construire de puissantes machines de cassage de chiffrement et d ’employer de brillants cryptanalystes. Estelle peut voler les clefs. Elle peut arrêter ou kidnapper quelqu’un qui connaît les clefs. Elle peut séduire quelqu’un et lui soutirer les clefs de cette façon. (Les M a r i n e s qui gardaient l’ambassade américaine à Moscou n’étaient pas insensibles à ce type d ’attaque.) Il est beaucoup plus facile de trouver les points faibles chez une personne que dans un système cryptographique. Alice et Bernard doivent protéger leurs clefs au même niveau de sécurité que les données qu’elles chiffrent. Si une clef n’est pas changée régulièrement, ça pourrait être une
Chapitre 8
182
Gestion des clefs
quantité énorme de données. Malheureusement, beaucoup de produits commerciaux déclarent tout simplement « Nous utilisons DES » et oublient tout le reste. Les résultats sont loins d’être concluants. Par exemple, le programme D i s k l o c k pour M a c i n t o s h (version 2.1), vendu par la plupart des marchands de logiciels, prétend offrir la sécurité du chiffrement DES. Il chiffre les fichiers en utiüsant le DES. Sa réalisation de l’algorithme DES est correcte. Toutefois, D i s k l o c k stocke la clef DES avec le fichier chiffré. Si vous savez où regarder pour trouver la clef et que vous voulez lire un fichier chiffré avec le DES de D i s k l o c k , retrouvez la clef dans le fichier chiffré et ensuite de déchiffrez le fichier à l’aide de la clef. Cela n’a pas d ’importance que le programme utilise le chiffrement DES — la réalisation est dénuée de toute sécurité. D ’autres informations concernant la gestion des clefs peuvent être trouvées dans [463, 105, 1284, 1235, 775, 361]. Les chapitres suivants s’occupent des résultats et des solutions.
8.1
Génération de clefs
Le niveau de sécurité d’un algorithme dépend de la clef. Si vous utilisez un processus cryptographiquement faible pour engendrer des clefs, alors tout votre système est faible. Estelle n’a pas à essayer de cryptanalyser votre algorithme de chiffrement ; elle a juste à cryptanalyser votre algorithme de génération de clefs.
Espaces de clefs réduits Le DES a une clef de 56 bits. Dans une réalisation correcte, toute chaîne de 56 bits peut être la clef: il y a 2 56 ( « 1016) clefs possibles. N o r t o n D i s c r e e t de M S-D O S (versions 8.0 et antérieures) n’autorisent que des clefs A SC II, forçant le bit de poids fort de chaque octet à prendre la valeur zéro, le programme convertit aussi les minuscules en majuscules (ainsi le cinquième bit de chaque octet est toujours l’opposé du sixième) et ignore le bit de poids faible de chaque octet, ne permettant finalement que 2 40 clefs possibles. Ces mauvaises procédures de génération de clefs rendent son DES dix mille fois plus facile à casser qu’une réalisation correcte. Le tableau 8.1 donne le nombre de clefs possibles, suivant certaines contraintes sur les chaînes de caractères à l’entrée. Le tableau 8.2 donne le temps requis pour une recherche exhaustive à travers toutes ces clefs, sur la base d’un million de tentatives par seconde. Notez qu’il n ’y a pas de différence en temps notable entre une recherche exhaustive pour des clefs de 8 octets d’emblée, et une recherche progressive où les clefs de 4 octets sont essayées, puis de 5 octets, ainsi de suite jusqu’à 8 octets.
T a b . 8.1 - Nombre de clefs possibles pour différents espaces de clefs
Lettres minuscules (26) Lettres minuscules et chiffres (36) Caractères alphanumériques (62) Caractères affichables (95) Caractères ASCII (128) Caractères ASCII 8 bits (256)
4 octets 460000 1700000 1,5 xlO7 8,1 xlO 7 2,7x10® 4,3 x 109
5 octets 1,2 xlO7 6,0 xlO 7 9,2 x 10® 7,7 xlO9 3,4 xlO 10 1,1 xlO 12
6 octets 3,1x10® 2,2 x 109 5,7 xlO 10 7,4 xlO11 4,4 x 1012 2,8 x 1014
7 octets 8,0x 10“ 7,8 xlO10 3,5 xlO 12 7,0 xlO13 5,6 xlO 14 7,2 xlO 16
8 octets 2,1 xlO 11 2,8 xlO 12 2,2 xlO 14 6,6 xlO 15 7,2 xlO 16 1,8 xlO 19
8.1
183
Génération de clefs
Tab. 8.2 - Recherche exhaustive de différents espaces de clefs (sur la base d’un million de tentatives par secondes) Lettres minuscules (26) Lettres minuscules et chiffres (36) Caractères alphanumériques (62) Caractères affichables (95) Caractères ASCII (128) Caractères ASCII 8 bits (256)
4 octets 0,5 s 1,7 s 15,0 s 1,4 mn 4,5 mn 1,2 h
5 octets 12 s 1 mn 15 mn 2,1 h 9,5 h 13 j
6 octets 5 mn 36 mn 16 h 8,5 j 51 j 8,9 ans
7 octets 2,2 h 22 h 41 j 2,2 ans 18 ans 2300 ans
8 octets 2,4 j 33 j 6,9 ans 210 ans 2 300 ans 580000 ans
Toute réalisation parallèle et matérielle d ’une attaque exhaustive spécialisée conviendra ici. En testant un million de clefs par seconde (soit avec une machine, soit avec plusieurs machines en parallèle), il est envisageable de retrouver une clef de 8 octets faite de lettres minuscules ou de lettres minuscules et de chiffres, une clef de 7 octets faite de caractères alphanumériques, une clef de 6 octets de caractères affichables ou de caractères ASCII, et une clef de 5 octets de caractères ASCII de 8 bits. Et rappelez-vous, la puissance de calcul double tous les 18 mois. Si vous espérez voir vos clefs résister à des attaques exhaustives pendant 1 0 ans, vous devriez revoir votre copie.
Mauvais choix de clefs Quand les gens choisissent leur clef par eux-mêmes, ils font généralement un mauvais choix1. Ils choisiront bien plus probablement « Barney » que « 9(hH/A — ». Ce n ’est pas toujours dû a de mauvaises habitudes de sécurité ; « Barney » est plus facile à retenir que « 9(hH/A— ». L’algorithme le plus sûr du monde ne sera pas d’une grande utilité pour les utilisateurs qui choisissent le nom de leur épouse comme clef ou qui écrivent leurs clefs sur des petits bouts de papier dans leur portefeuille. Un algorithme de recherche exhaustive intelligent n’essaie pas toutes les clefs dans leur ordre numérique ; il essaie d’abord les clefs les plus évidentes. On appelle cela une attaque par dictionnaire, parce que l’attaquant utilise un dic tionnaire de clefs communes. Daniel K l e i n fut capable de retrouver 40 % des mots de passe d’un ordinateur moyen en utilisant ce système [848, 849]. Non, il n’a pas essayé les mots de passe les uns après les autres en tentant de se connecter. Il a copié le dossier chiffré du mot de passe et mené son attaque dans son coin. Voici ce qu’il a essayé : 1. Le nom de l’utilisateur, les initiales, le nom du compte, et d’autres informations concernant la personne comme mot de passe possible. L ’un dans l’autre, jusqu’à 130 mots de passe différents furent essayés sur base de ces informations. Pour un compte désigné par « klone » d ’un utilisateur appelé « D aniel V. K lein » les mots de passe suivants furent entre autres tentés: klone, kloneO, k lo n e l, k lo n el23, dvk, dvkdvk, d k le in , DKlein, le in a d , n ie lk , d vk lein , danielk, DvkkvD, DANIEL-KLEIN, (k lo n e ), KleinD, etc. 2.
Des mots de différentes bases de données. Celles-ci comprennent les listes des noms d’hommes et de femmes (environ 16 0 0 0 au total) ; des noms d ’endroits (y
1 Note du traducteur : l’ inform ation reprise dans cette section est typiquem ent anglo-saxonne mais elle est également d ’ application, moyennant de légères m odifications, pou r les utilisateurs d ’ expression francophone.
184
Chapitre 8
Gestion des clefs
compris les variantes telles que « sp a m », « spanish », « spaniard » soient tous considérés) ; des noms de personnages célèbres ; des noms de dessins animés et de personnages de dessins animés ; des titres, personnages et lieux de films ou d ’histoires de science-fiction; des noms de créatures mythiques (collectées dans la mythologie de B u l f i n c h et dans le dictionnaire des bêtes mythiques) ; des sports (y compris les noms d’équipes, les surnoms et les termes spécialisés) : des nombres (à la fois écrits en chiffre — « 2001 » et écrits en toute lettre « tw elve ») ; des chaînes de caractères et de nombres (« a », « aa », « aaa », « aaaa », etc.); des syllabes chinoises (à partir de la romanisation P i d g i n du chinois, un système international standard pour écrire du chinois sur un clavier anglais) ; la K m g James Bible ; les termes de la biologie ; des mots familiers ou vulgaires (tels que « fuckyou », « ibmsux », « deadhead ») ; des motifs de clefs du clavier (tels que « qwerty », « asdf », « zxcvbn ») ; des abréviations (telles que « roygb iv », les cou leurs de l’arc-en-ciel en anglais ou « o o t ta f agvah », un mnémonique pour retenir les noms des 12 nerfs crâniens en anglais) ; les noms de machines (à partir du fi chier /etc/hosts) ; des personnages, pièces ou lieux de l’œuvre de SHAKESPEARE; des mots communs du Yiddish ; des noms d ’astéroïdes ; et une collection de mots de différents articles techniques publiés par K l e i n lui-même. Tout compris, plus de 60000 mots différents furent considérés par utilisateur (en ignorant les dou blons). 3. Des variantes des mots de l’étape 2. Cela inclut : mettre la première lettre en majuscule, mettre un caractère de contrôle comme première lettre, mettre tout le mot en majuscule, renverser le mot (avec et sans la mise en majuscule précédente), remplacer la lettre « o » par le chiffre « 0 » (ainsi le mot « sc h o la r » sera aussi testé comme « schOlar »), remplacer la lettre « 1 » par le chiffre « 1 » (ainsi le mot « sch o la r » sera aussi testé comme « sc h o la r »), et faire des remplacements similaires de la lettre « z » par le chiffre « 2 » et la lettre « s » par le chiffre « 5 ». Un autre test consistait à mettre le mot au pluriel (peu importe si le mot était bien un substantif) avec suffisamment de subtilité de telle manière que « d re ss » devenait « d r e sse s », « house » devenait « houses », et « d a is y » devenait « d a i s ie s ». Les règles de mise au pluriel ne furent pas seulement prises au pied de la lettre par K l e in , ainsi « datum » devint « datums » (et non pas « data »), tandis que « sphynx » devint « sphynxs » (et non pas « sphynges »). De la même façon, les suffixes « -ed », « -e r » et « -in g » furent ajoutés pour transformer des mots tels que « phase » en « phased », « phaser » et « phasing ». Ces tests supplémentaires ajoutèrent 1000 000 de mots à la liste des mots de passe possibles à tester pour chaque utilisateur.
4. Différentes mises en majuscule des mots de l’étape 2 qui ne furent pas considérées pour l’étape 3. Cela inclut la mise en majuscule d’une seule lettre à toutes les positions possibles (ainsi « m ichael » donne « m ichael », « miChael », « micHael », « michAel », etc.), la mise en majuscule de deux lettres (« M ichael », « MiChael », « MicHael », .. , « mIChael », « mlcHael », etc.), la mise en majuscule de trois lettres, etc. La mise en majuscule d’une seule lettre rajouta environ 400000 mots à tester par utilisateur tandis que la mise en majuscule de deux lettres rajouta 1500 000 de mots supplémentaires. La mise en majuscule de trois lettres aurait rajouté au moins 3000000 de mots par utilisateur s’il y avait eu suffisamment de
8.1
Génération de clefs
185
temps pour effectuer les tests. Tester les mises en majuscule de quatre, cinq et six lettres s’avérait infaisable sans beaucoup plus de puissance de calcul. 5. Des mots de langues étrangères pour des utilisateurs étrangers. Le test spécifique qui fut réalisé était d’essayer des mots de passe chinois pour les utilisateurs chi nois. La romanisation Pidgin des syllabes chinoises a été utilisée, en combinant les syllabes par une, deux ou trois pour former des mots. Comme aucun test ne fut fait pour déterminer si les mots engendrés avaient un sens, une recherche ex haustive fut entamée. Comme il y a 298 syllabes chinoises dans le système Pidgin, il y a 158 404 mots de deux syllabes et un peu plus de 16 000 000 de mots de trois syllabes. Un mode d ’attaque similaire peut être aisément utilisé pour la langue anglaise en utilisant des règles pour construire des mots prononçables mais sans aucun sens. 6.
Des paires de mots. L ’ordre de grandeur d’un test exhaustif de ce type est stupé fiant. Pour simplifier le test, seuls les mots de trois et quatre caractères de long de /usr/dic.t/words furent utilisés. Même ainsi, le nombre de paires est de l’ordre de dix millions.
Une attaque par dictionnaire est bien plus efficace quand elle est montée contre un fichier de clefs plutôt que contre une seule clef. Un seul utilisateur peut être assez malin pour choisir de bonnes clefs. Si un millier de personnes choisissent leur propre clef comme mot de passe d ’accès à un système informatique, les chances sont élevées que le mot de passe d ’au moins une personne se trouve dans le dictionnaire de l’attaquant.
Clefs aléatoires Les bonnes clefs sont des chaînes aléatoires de bits générées par des processus automa tiques. Si une clef a 64 bits de long, toutes les chaînes possibles de 64 bits devraient être équiprobables. Engendrez les bits de la clef à partir d’une source aléatoire fiable (voir § 17.14) ou d ’un générateur pseudo-aléatoire de bits cryptographiquement sûr (voir chapitres 16 et 17). Si ces dispositifs automatiques ne sont pas disponibles, lancez une pièce de monnaie ou un dé. C’est important, mais ne vous laissez pas emporter dans une conversation quant à savoir si les bruits aléatoires des sources audios sont plus aléatoires que ceux des déchets radioactifs. Aucun de ces bruits aléatoires sera parfait, mais ils seront probablement assez bons. Il est important d ’utiliser un bon générateur de nombre aléatoire pour la génération de clef, mais il est encore plus important d’utiliser de bons algorithmes de chiffrement et de bonnes procédures de gestion de clefs. Si le fait que vos clefs soient aléatoires vous ennuie, utilisez la technique du broyage de clef, décrite plus loin. Certains algorithmes de chiffrement ont des clefs faibles : des clefs spécifiques qui sont moins sûres que les autres clefs. Je vous conseille de détecter ces clefs et d ’en engendrer une autre si vous en découvrez une. Le DES n’a que 16 ('lefs faibles sur 256, donc les chances d’engendrer Lune d ’elles sont incroyablement faibles. Il a été argumenté qu’un cryptanalyste n’aurait pas la moindre idée qu’une clef faible est utilisée et donc ne tire pas avantage de leur utilisation accidentelle. Toutefois, détecter les quelques clefs faibles est tellement facile qu’il semble imprudent de ne pas le faire. Engendrer des clefs pour les systèmes de cryptographie à clef publique est nettement plus difficile car souvent les clefs doivent avoir certaines propriétés mathématiques
Chapitre 8
186
Gestion des clefs
(elles doivent parfois être un nombre premier, un résidu quadratique, etc.). Des tech niques pour engendrer des grands nombres premiers aléatoires sont décrites dans le paragraphe 11.5. La chose importante à se rappeler du point de vue de la gestion des clefs est que les germes de ces générateurs doivent être complètement aléatoires. Engendrer une clef aléatoire n ’est pas toujours possible. Parfois, il est nécessaire de mémoriser votre clef2. Si vous devez engendrer une clef facile à mémoriser, rendezla obscure. L’idée est d ’avoir quelque chose de facile à mémoriser mais de difficile à deviner. Voici quelques suggestions : - Des paires de mots séparés par un signe de ponctuation, par exemple: « tu rtle*m oose » ou « z o r c h ls p la t ». - Des chaînes de caractères qui sont un acronyme de phrases plus longues, par exemple « Mein Luftkissenfahrzeug ist voiler Aale! » donne la clef « MLivA ! ».
Phrases-mots de passe Une meilleure solution est d ’utiliser une phrase entière au lieu d’un seul mot et de convertir cette phrase en une clef. Ces phrases sont appelées phrase clef Une technique appelée broyage de clef, transforme des phrases faciles à mémoriser en des clefs aléatoires. Utilisez une fonction de hachage à sens unique pour transformer un texte de longueur quelconque en une chaîne de bits pseudo-aléatoire. Par exemple, le texte suivant facile à mémoriser: Mon nom est Ozymandias, roi des rois. Contemple mon œuvre, O toi le tout puissant, et désespère. pourrait être « broyé » pour donner la clef de 64 bits suivante (en hexadécimal) : E6C1 4398 5AE9 0A9B Bien sûr, taper une phrase entière dans un ordinateur peut se révéler difficile. Les bonnes idées pour résoudre ce problème sont les bienvenues. Si la phrase est assez longue, la clef résultante sera aléatoire. Ce que signifie exactement « assez longue » est sujet à interprétation. La théorie nous dit que l’anglais standard a à peu près 1,3 bits d ’information par caractère (voir § 11.1). Pour une clef de 64 bits, une phrase clef d’à peu près 49 caractères, ou de 10 mots normaux anglais, devrait être suffisante. A vue de nez, dites-vous que vous avez besoin de 5 mots pour 4 bits de clef C ’est une hypothèse modérée, sachant que cela ne prend en compte ni les lettres majuscules ou minuscules, ni l’espacement, ni la ponctuation. Cette technique peut même être utilisée pour engendrer la clef privée des systèmes cryptographiques à clef publique : le texte peut être transformé en un germe aléatoire et ce germe peut être fourni à un système déterministe qui engendre la paire « clef privée, clef publique ». Si vous choisissez une phrase clef, choisissez quelque chose d ’unique et de facile à retenir. Ne choisissez pas des phrases extraites de la littérature, l’exemple de « Ozymandias » n’est pas bon. Les œuvres complètes de S h a k e s p e a r e et les dialogues de « La guerre des étoiles (Star Wars) » sont disponibles et peuvent être utilisés pour une attaque 2. Constatez com bien de tem ps il vous faut pou r m ém oriser 25e8 5 6 f2 e8ba c820.
8.1
Génération de clefs
187
par dictionnaire. Choisissez quelque chose d ’obscur, mais de personnel. Injectez-y de la ponctuation et des majuscules ; si vous pouvez, ajoutez-y des nombres et des symboles non alphanumériques. Des mots anglais incorrects, voire des mots étrangers, font que votre phrase clef est moins sensible à une attaque par dictionnaire. Une suggestion est d’utiliser une phrase « choquante et dénuée de sens » : quelque chose d ’assez offensif que vous saurez retenir mais que vous n’écrirez sûrement pas. Malgré tout ce qui a été écrit ici, l’obscurité ne remplacera pas le vrai hasard. Les meilleurs clefs sont des clefs aléatoires, difficiles à retenir.
Génération de clefs suivant le standard ANSI X 9.17 Le standard AN SI X 9.17 désigne une méthode de génération de clefs (voir figure 8.1) [57]. Ce processus n ’engendre pas des clefs faciles à mémoriser : il est plus adapté à la génération de clefs de session ou de nombres pseudo-aléatoires au sein d’un système. L’algorithme cryptographique utilisé pour engendrer les clefs est le DES triple mais ce pourrait être aussi bien tout autre algorithme.
F ig.
8 .1
Le standard ANSI X 9 .17 de génération de clefs
Soit E k ( X ) le chiffrement DES de X avec la clef K . C ’est une clef spéciale réservée à la génération de clefs. Vo est un germe de 64 bits secret. T est une datation. Pour engendrer la clef aléatoire Ri, calculez : Ri
=
Epc(Efi-(7'z)
© Vi).
Pour engendrer U f i, calculez: V%+ 1 — E
k
( E k ( Ti ) © R i ) .
Pour transformer Ri en une clef DES, ajustez simplement un bit sur huit pour la parité. Si vous avez besoin d’une clef de 64 bits, utilisez-la telle quelle. Si vous avez besoin d’une clef de 128 bits, engendrez une paire de clefs et joignez-les.
Génération de clefs du Département de la Défense américain Le Département de la Défense américain recommande l’utilisation du DES en mode OFB (voir § 9.8) pour générer des clefs aléatoires [1151]. Générez une clef DES à partir de vecteurs d’interruption de système, de registres d’état de système et de compteurs de système. Générez un vecteur d’initialisation à partir de l’horloge du système, de l’identification du système, de la date et de l’heure. Pour le texte en clair, utilisez une quantité de 64 bits générée en externe: huit caractères tapés par un administrateur système par exemple. Utilisez le résultat comme votre clef.
Chapitre 8
188
8.2
Gestion des clefs
Espaces des clefs non linéaires
Imaginez que vous êtes une organisation militaire de cryptographie, fabriquant des équipements de cryptographie pour vos troupes. Vous voulez utiliser un algorithme sûr, mais vous avez peur que cet équipement tombe entre des mains ennemies. La dernière chose que vous voulez est que cet ennemi soit capable d’utiliser cet équipement pour protéger ses propres secrets. Si vous pouvez placer votre algorithme dans un module inviolable, voici ce que vous pouvez faire. Vous pouvez exiger des clefs de forme spéciale et secrète ; toutes les autres clefs feront que le module chiffrera et déchiffrera en utilisant un algorithme sévèrement affaibli. Vous pouvez vous arranger pour que les chances de tomber sur une clef correcte soient de plus en plus faibles quand on ne connaît pas cette forme spéciale. On appelle cela un espace de clef non linéaire, car toutes les clefs ne sont pas de force égale, (le contraire est un espace de clef linéaire). Une manière facile de le faire est de créer la clef en deux parties : la clef elle-même et une chaîne fixe chiffrée avec cette clef. Le module déchiffre la chaîne avec la clef; si il obtient la chaîne fixe il utilise la clef normallement, sinon, il utilise un algorithme différent, plus faible. Si l’algorithme a une clef de 128 bits et une taille de 64 bits, la clef générale est de 192 bits ; ceci donne à l’algorithme une clef efficace de 2 128 et réduit les chances de trouver par hasard une bonne clef à un contre 2 64. Vous pouvez même être encore plus subtil. Vous pouvez créer un algorithme tel que certaines clefs sont plus fortes que d ’autres. Un algorithme peut ne présenter aucune clef faible — qui soit vraiment très mauvaise — tout en ayant un espace de clef non linéaire. Ceci ne marche que si l’algorithme est secret et si l’ennemi ne peut pas en analyser le code machine, ou si la différence entre les niveaux de clefs est suffisamment subtile pour que cela ne se remarque pas. La NSA l’a utilisé avec ses algorithmes secrets dans ses modules Overtake (voir § 25.1). L ’ont-ils refait avec Skipjack (voir § 13.12)? Personne ne le sait.
8.3
Transfert de clefs
Alice et Bernard vont utiliser un algorithme cryptographique à clef secrète pour com muniquer de manière sûre ; ils ont besoin d ’une clef commune. Alice engendre une clef en utilisant un générateur aléatoire de clefs. Maintenant elle doit la faire parvenir à Bernard, en toute sécurité. Si Alice peut rencontrer Bernard quelque part (une allée sombre, une pièce sans fenêtre, ou sur un des satellites de Jupiter), elle peut lui donner une copie de la clef. Sinon, ils ont un problème. La cryptographie à clef publique résout ce problème élégamment et avec un minimum de préarrangements, mais ces techniques ne sont pas toujours disponibles (voir § 3.1). Certains systèmes peuvent utiliser des ca naux de communication alternatifs réputés pour être sûrs. Alice peut envoyer à Bernard la clef par un messager de confiance. Elle peut l’envoyer par courrier certifié ou via un service de livraison express. Elle peut créer un nouveau canal de communication avec Bernard et espérer que personne n’écoute celui-là. Alice peut envoyer à Bernard la clef secrète sur le canal de communication, celui qu’ils vont utiliser. C ’est idiot : si le canal garantit le chiffrement, envoyer la clef de chiffrement
8.3
Transfert de clefs
189
en clair sur le même canal garantit que n’importe qui écoutant le canal peut déchiffrer toutes les communications. Le standard X 9 .17 [57] détermine deux types de clefs : les clefs de chiffrement de clefs et les clefs de données. Les clefs de chiffrement de clefs chiffrent les autres clefs pour la distribution. Les clefs de données chiffrent le trafic des messages. Ces clefs de chiffrement de clefs doivent être distribuées manuellement (bien qu’elles puissent être en sécurité dans un système inviolable, tel qu’une carte à puce), mais seulement très rarement. Les clefs de données sont distribuées plus souvent. Vous trouverez plus de détails dans [82]. Ce concept de deux niveaux de clefs est très utilisé dans la distribution de clefs. Une autre solution au problème de distribution est de diviser la clef en plusieurs mor ceaux (voir § 3.6) et d’envoyer chaque morceau par un canal différent. Un morceau pourrait être envoyé par téléphone, un par courrier, un par courrier express, un par pigeon voyageur, etc. (voir la figure 8.2). Comme un adversaire arrivant à collecter tous les morceaux sauf un ne pourra pas reconstruire la clef, cette méthode marchera dans tous les cas excepté les cas extrêmes. Le paragraphe 3.6 présente des schémas pour diviser une clef en plusieurs morceaux. Alice pourrait même utiliser un schéma de partage de secret (voir § 3.7), permettant à Bernard de reconstruire la clef même si quelques morceaux se sont égarés pendant la transmission.
F ig. 8.2 - Distribution de clef morcelée Alice envoie à Bernard la clef de chiffrement de clefs de manière sûre, soit en se ren contrant en chair et en os, soit par la technique de morcellement présentée ci-dessus. Une fois qu’Alice et Bernard disposent tous deux de la clef de chiffrement de clefs, Alice peut envoyer à Bernard les clefs de données journalières sur le même canal de communication. Alice chiffre chaque clef de données journalière avec la clef de chiffre ment de clefs. Comme le volume chiffré avec la clef de chiffrement de clefs est faible, elle ne doit pas être changée trop souvent. Toutefois, si la clef de chiffrement de clefs est compromise alors tous les messages chiffrés avec toutes les clefs journalières sont compromis, la clef de chiffrement des clefs doit être stockée de manière sûre.
190
Chapitre 8
Gestion des clefs
Distribution de clefs dans des grands réseaux Des clefs de chiffrement de clefs, partagées par des paires d’utilisateurs, conviennent bien dans des petits réseaux, mais deviennent rapidement incommodes quand le réseau s’agrandit. Comme chaque paire d’utilisateurs doit échanger des clefs, le nombre total d’échanges de clefs requis dans un réseau de n personnes est de n(n — l ) / 2 . Dans un réseau de 6 personnes, 15 échanges de clefs sont nécessaires. Dans un réseau de 1000 personnes, près de 500 000 échanges de clefs sont nécessaires. Dans ce cas, la création d ’un serveur central de clefs (ou de plusieurs serveurs) rend 1 opération beaucoup plus efficace. Alternativement, tout protocole de cryptographie à clef secrète ou de cryptographie à clef publique du paragraphe 3.1 fournit un moyen de distribution de clefs sûr.
8.4
Vérification de clefs
Quand Bernard reçoit une clef, comment peut-il savoir que celle-ci vient bien d’Alice et non pas de quelqu’un qui se fait.passer pour Alice? Si Alice lui a donnée lors d’une rencontre en chair et en os, c’est facile. Si Alice a envoyé la clef par un porteur de confiance, alors Bernard doit avoir confiance dans le porteur. Si la clef est chiffrée avec une clef de chiffrement de clefs, alors Bernard doit avoir confiance dans le fait que seule Alice a cette clef. Si Alice utilise un protocole de signature numérique pour signer la clef, Bernard doit avoir confiance dans la base de données de clefs publiques quand il vérifie la signature (il doit aussi croire qu’ Alice n ’a pas divulgué sa clef). Si le Centre de Distribution des Clefs (C D C ) signe la clef publique d’Alice, Bernard doit avoir confiance dans le fait que la clef publique du C D C n’a pas été falsifiée. En fin de compte, quelqu’un qui contrôle complètement tout le réseau autour de Bernard peut lui faire croire ce qu’il veut. Martin peut envoyer un message chiffré et signé en prétendant être Alice. Quand Bernard essaie d’atteindre la base de données de clefs publiques pour vérifier la signature d’Alice, Martin peut fournir sa propre clef publique. Martin peut inventer son propre C D C factice et remplacer les vraies clefs publiques du C D C pour son propre usage. Bernard ne se rendra compte de rien. Certaines personnes ont utilisé cet argument pour clamer que la cryptographie à clef publique est inutile. Comme le seul moyen pour Alice et Bernard de s’assurer que leur clef n’est pas falsifiée est de se rencontrer en chair et en os, la cryptographie à clef publique n’améliore pas du tout la sécurité. Cette vision est naïve. C ’est théoriquement vrai, mais la réalité est bien plus compli quée. La cryptographie à clef publique, utilisée avec des signatures numériques et des C D C de confiance, rend bien plus difficile la substitution d’une clef par une autre. Bernard peut ne jamais être tout à fait certain que Martin ne manipule pas son uni vers, mais Bernard peut être certain que faire cela nécessite bien plus de ressources que celles dont disposent la plupart des Martin du monde réel. Bernard peut aussi vérifier la clef d ’Alice par téléphone, il entend alors sa voix. La reconnaissance de la voix est un très bon moyen d ’identification. Si c ’est une clef publique, il peut la réciter en toute sécurité en public. Si c ’est une clef secrète, il peut utiliser une fonction de hachage à sens unique pour vérifier la clef. P G P (voir § 24.12) et A T & T T SD (voir § 24.18) utilisent tous les deux ce genre de vérification de clef. Parfois, il peut même être sans importance de vérifier à qui appartient une clef publique.
8.4
Vérification de clefs
191
Il peut être nécessaire de vérifier qu’elle appartient bien à la même personne que celle à qui elle appartenait l’an dernier. Si quelqu’un envoie un ordre de retrait à une banque, la banque ne doit pas s’inquiéter de savoir qui retire l’argent, elle doit seulement s’assurer que c’est la même personne que celle qui a déposé l’argent originellement.
Détection d’erreurs pendant la transmission de clef Parfois les clefs sont faussées pendant la transmission. Comme une clef faussée peut signifier des mégaoctets de texte chiffré indéchiffrables, c’est un problème. Toutes les clefs devraient être transmises avec un certain type de détection d ’erreurs et des bits de correction d’erreur. De cette façon les erreurs de transmission peuvent être facilement détectées, et si nécessaire la clef peut être retransmise. Une des méthodes le plus communément utilisée est de chiffrer une valeur constante avec la clef et d’envoyer les 2 à 4 premiers octets du texte chiffré en même temps que la clef. Du côté du récepteur, on fait la même chose. Si les constantes chiffrées concordent, alors la clef a été transmise sans erreurs. Les chances pour une erreur de ne pas être détectée vont de 1 pour 2 16 à 1 pour 2 32.
Détection d’erreur de clef pendant le déchiffrement Parfois, le destinataire veut vérifier si une clef particulière qu’il possède est la clef secrète de déchiffrement. Si le texte en clair envoyé est du type A SC II, il peut essayer de déchiffrer et lire le message. Si le texte en clair est aléatoire, il y a d’autres techniques. L’approche naïve est d ’attacher un b l o c d e v é r i f i c a t i o n : une en-tête connue pré cédant le texte en clair avant chiffrement. A la réception, Bernard déchiffre l’en-tête et vérifie qu’elle est correcte. Ca marche, mais cela donne à Estelle un texte en clair connu pour l’aider à cryptanalyser le système. Cela rend aussi plus faciles les attaques contre les chiffres à clefs courtes comme le DES et les algorithmes exportables. Précalculez la somme de contrôle une fois pour chaque clef, puis utilisez cette somme de contrôle pour déterminer la clef de chaque message que vous interceptez par la suite. C’est une caractéristique de toute somme de contrôle de clef où ne sont pas incluses des données aléatoires ou tout du moins différentes. C ’est conceptuellement similaire à l’utilisation d’un sel pour générer des clefs à partir de phrases-clefs. Voici une meilleure façon de le faire [822] : 1° Générez un vecteur d’initialisation (différent de celui utilisé pour le message). 2° Utilisez ce vecteur d’initialisation pour générer un grand nombre de bits : par exemple 512.
3° Hachez le résultat. 4° Utilisez les même bits de l’empreinte, par exemple 32, pour la somme de contrôle de la clef.
Ceci donne à Estelle des informations, mais très peu. Si elle essaie d’utiliser les 32 bits de la valeur finale du hachage pour entreprendre une attaque massive, elle devra effectuer de multiples chiffrements ainsi qu’un hachage par clef; une attaque massive sur la clef elle-même serait plus rapide.
Chapitre 8
192
Gestion des clefs
De plus, elle n’aura pas de valeurs de texte en clair connues à essayer, et même si elle arrive à choisir une valeur aléatoire à notre place, elle ne pourra pas choisir un de nos textes, puisqu’ils passent au hachage avant qu’elle puisse les voir.
8.5
Utilisation des clefs
Le chiffrement par logiciel est angoissant. Il est loin le temps où les simples microordinateurs étaient sous le contrôle de programmes isolés. Maintenant, il y a le SYSTEM 7 du M a c i n t o s h , W i n d o w s N T et U NIX. Vous ne pouvez pas prévoir quand le système va interrompre l’application de chiffrement en cours, écrire le tout sur disque, et s’occuper d’une tâche urgente. Quand le système redonne finalement la main au chiffrement de ce qui doit être chiffré, tout a l’air normal. Personne ne réalise que le système a écrit toute l’application de chiffrement sur disque et qu’il a écrit la clef en même temps. La clef est maintenant sur le disque, non chiffrée jusqu’à ce que l’ordinateur réécrive à cet endroit à nouveau. Cela peut prendre des minutes ou des mois. Cela pourrait même jamais se produire : la clef pourrait encore être là quand un adversaire passe le disque dur au peigne fin. Dans un environnement multitâche préemptif, vous pouvez mettre votre application à un niveau de priorité suffisamment élevé pour qu’elle ne soit pas interrompue. Cela diminuerait le risque. Même ainsi, c ’est encore trop hasardeux. Les réalisations matérielles sont plus sûres. De nombreux dispositifs sont conçus pour effacer la clef si l’on essaie de les décortiquer. Par exemple, la carte de chiffrement de l’IBM P S /2 a une unité en époxyde qui contient la puce DES, l’alimentation et la mémoire. Bien sûr, vous devez faire confiance au fabricant pour qu’il ait réalisé cela correctement. Quelques applications de communication, tels que les chiffreurs de téléphone, peuvent utiliser des c l e f s d e s e s s i o n . Une clef de session est une clef qu’on utilise juste pour une opération de communication — une seule conversation téléphonique — puis dont on se débarasse. Il n ’y a pas de raison de garder la clef après qu’elle ait été utilisée. Et si vous utilisez un protocole d’échange de clef pour la transférer, elle n’a pas besoin d ’être stockée avant d ’être utilisée. De ce fait, la clef est moins susceptible d ’être compromise.
Contrôler l’usage de la clef Avec certaines applications, il est préférable de contrôler comment une clef de session est utilisée. Certains utilisateurs en auront besoin seulement pour le chiffrement ou le déchiffrement. Les clefs de session peuvent être autorisées à l’emploi sur certaines machines ou à certains moments. Pour gérer ce genre de restrictions, un procédé attache à la clef un V E C T E U R DE C O N TR Ô L E (V C ) ; le vecteur de contrôle définit les utilisations et les restrictions de cette clef (voir § 24.1) [1035, 1036]. Ce VC est haché puis combiné par ou exclusif avec une clef maîtresse ; le résultat est utilisé comme clef de chiffrement pour chiffrer la clef de session. Cette clef de session ainsi chiffrée est alors stockée avec le VC. Pour retrouver la clef de session, hachez puis combinez par ou exclusif le VC avec la clef maîtresse et utilisez le résultat pour déchiffrer la clef de session chiffrée. Les avantages de ce procédé sont que le VC peut être d’une longueur tout à fait arbi traire et qu’il est toujours stocké en clair avec la clef chiffrée. Ce procédé est en partie responsable de l’inviolabilité des matériels et de l’incapacité des utilisateurs d’accéder
8.6
Mise à jour des clefs
193
directement aux clefs. Ce système est abordé plus à fond dans les chapitres 24.1 et 24.8.
8.6 Mise à jour des clefs Imaginez un lien de données chiffrées où vous voulez changer vos clefs quotidiennement. Il est souvent fastidieux de distribuer une nouvelle clef chaque jour. Une solution plus facile est de générer une nouvelle clef à partir de l’ancienne; quelquefois, on appelle cela une m i s e À j o u r d e s c l e f s . Il suffit d ’une fonction de hachage à sens unique. Si Alice et Bernard partagent la même clef et l’utilisent simultanément avec la même fonction à sens unique, ils obtiendront le même résultat. Puis ils peuvent prendre les bits dont ils ont besoin pour créer la nouvelle clef. La mise à jour de clef marche, mais souvenez-vous que la nouvelle clef n’est pas plus sûre que l’ancienne. Si Estelle a réussi à mettre la main sur l’ancienne clef, elle peut effectuer l’opération de mise à jour de clef elle-même. Néanmoins, si Estelle n’a pas l'ancienne clef et lance une attaque seulement à texte de chiffré sur le trafic chiffré, c’est une bonne manière pour Alice et Bernard de se protéger.
8.7
Stockage des clefs
Le stockage de clefs le moins complexe est pour l’utilisateur isolé, Alice, qui chiffre ses fichiers pour une utilisation future. Comme elle est la seule concernée, elle est la seule responsable de sa clef. Certains systèmes prennent une approche facile : la clef est stockée dans le cerveau d ’Alice et jamais dans le système. Alice doit mémoriser la clef et l’entrer chaque fois qu’elle a besoin qu’un fichier soit chiffré ou déchiffré. Un exemple d’un tel système est donné par IPS [881]. Les utilisateurs peuvent soit entrer directement leur clef de 64 bits, soit entrer la clef sous forme d ’une longue chaîne de caractères. Le système engendre alors une clef de 64 bits à partir de la chaîne de caractères, à l’aide d’une technique de broyage de clefs. Une autre solution est de stocker la clef sur une carte à piste magnétique, une clef en plastique avec une puce R O M (appelée une clef R O M ), ou sur une carte à puce [558, 559, 461]. Un utilisateur peut alors entrer sa clef dans le système, en insérant sa carte dans un lecteur spécial de la boîte de chiffrement ou attaché au terminal informatique. Il peut l’utiliser seulement dans les limites précisées par le vecteur de contrôle. La clef RO M est une très bonne idée. Les personnes comprennent les clefs physiques, ce qu’elles représentent et comment les protéger. Mettre une clef cryptographique sous cette même forme rend le stockage et la protection de cette clef plus intuitive. Cette technique est rendue encore plus sûre en morcelant la clef en deux moitiés et en stockant une moitié dans le terminal et l’autre moitié dans la clef R O M . Le procédé STU-III du gouvernement américain de protection du téléphone fonctionne de cette manière. Perdre la clef R O M ne compromet pas la clef cryptographique, changez-la et tout rentre dans l’ordre. Ceci est aussi vrai dans le cas de la perte du terminal. De cette façon, compromettre soit la clef R O M soit le terminal ne compromet pas la clef cryptographique — un adversaire doit avoir les deux moitiés.
Chapitre 8
194
Gestion des clefs
Des clefs difficiles à mémoriser peuvent être stockées sous forme chiffrée, en utilisant quelque chose de similaire à une clef de chiffrement de clefs. Par exemple, une clef privée R SA peut être chiffrée par DES et stockée sur le disque. Pour récupérer la clef R SA , l'utilisateur doit donner la clef D ES au programme de déchiffrement. Si les clefs sont engendrées de manière déterministe (avec un générateur pseudo aléatoire de nombres cryptographiquement sûr) il peut être plus simple de réengendrer les clefs à partir d ’un mot de passe facile à retenir chaque fois qu’elles sont nécessaires. L’idéal serait qu’une clef n’apparaisse jamais non-chiffrée hors du module de chiffre ment. Ce n’est pas toujours possible, mais c’est un but que nous devons atteindre.
8.8
Duplicata des clefs
Alice est le responsable financier de la société « Secrets, S.A. », « Nous ne dévoilons pas notre devise ». Comme tout employé consciencieux, elle suit les consignes de sécurité de sa société et chiffre toutes ses données. Malheureusement, elle ignore les consignes de sécurité routière pour traverser la rue et est renversée par un camion. Que fait Bernard, le président de la société? Bernard est bien embarassé, à moins qu’Alice n’ait laissé une copie de sa clef. Le but du chiffrement est de rendre les fichiers non récupérables sans la clef. Ses fichiers seront perdus à jamais, à moins qu’Alice soit une débile ou qu’elle utilisait un logiciel de chiffrement miteux. Bernard peut éviter cela de plusieurs manières. La plus simple est parfois appelée d é p ô t d e c l e f (voir § 4.14) : Bernard exige que ses employés mettent leur clef par écrit et la donnent au responsable de la sécurité de l’entreprise, qui les enfermera en lieu sûr (ou qui les chiffrera toutes avec une clef maîtresse). Maintenant, si Alice est tuée sur l’autoroute, Bernard peut demander la clef d’Alice à son responsable de la sécurité. Bernard devrait aussi s’assurer d ’avoir personnellement la combinaison du coffre, sinon si le responsable de la sécurité est lui aussi écrasé par un autre camion, Bernard serait de nouveau frappé par la malchance. Le problème avec ce système de gestion de clefs est que Bernard doit avoir confiance dans le responsable de la sécurité pour que celui-ci ne fasse pas un mauvais usage des clefs dont il a la garde. Plus important encore, tous les employés doivent avoir confiance dans le responsable de la sécurité pour qu’il ne fasse pas mauvais usage de leur clef. Une bien meilleure solution est d ’utiliser un protocole de partage de secret (voir § 3.7). Quand Alice engendre la clef, elle partage également celle-ci en un certain nombre de morceaux. Elle envoie ensuite chaque morceau — chiffré bien sûr — à un employé différent de la compagnie suivant en cela les consignes de sécurité de la société. Aucun des morceaux n’est la clef à lui seul mais quelqu’un peut rassembler les morceaux et peut ainsi reconstruire la clef. Maintenant, Alice est protégée contre toute personne malintentionnée et Bernard est protégé de la perte de toutes les données d’Alice en cas d ’accident. Ou encore, elle peut stocker tous les morceaux, chacun chiffré avec une clef publique d ’un employé différent de la société, sur son propre disque dur . De cette façon, personne ne s’occupe de la gestion des clefs tant que ce n’est pas nécessaire. Un autre schéma de duplication de clef [194] utilise les cartes à puce (voir § 24.13) pour le dépôt temporaire des clefs. Alice peut mettre sa clef d ’ordinateur sur une carte à puce et la donner à Bernard pendant qu’elle s’absente. Bernard peut utiliser la carte pour avoir accès à son ordinateur, mais comme la clef est inscrite dans la carte, Bernard
8.9
Clefs compromises
195
ne peut pas la connaître. Et le système marche à double sens : Bernard peut vérifier que la clef permet l’accès à l’ordinateur d ’Alice, et quand Alice reviendra, elle pourra vérifier si Bernard a utilisé la clef et si oui, combien de fois. Un tel schéma n’est pas applicable aux transmissions de données. Sur un téléphone protégé, la clef ne devrait exister que le temps de l’appel. Pour le stockage de données, comme on vient de le dire, le dépôt de clef peut être une bonne idée. J’ai perdu environ une clef tous les cinq ans, et ma mémoire est supérieure à la moyenne. Si 200 millions de personnes utilisaient la cryptographie, ce même taux équivaudrait à 40 millions de clefs perdues annuellement. Je laisse un double des clefs de ma maison à mon voisin, au cas où je les perde. Si les clefs de la maison étaient des clefs cryptographiques, et si je les perdais, je ne pourrais plus jamais rentrer chez moi. Au même titre que je garde à part un duplicata de mes données, il me semble logique de garder une copie de ses clefs de chiffrement de données.
8.9
Clefs compromises
Tous les protocoles, techniques et algorithmes de ce livre ne sont sûrs que si la clef (la clef privée dans un système à cryptographie à clef publique) reste secrète. Si la clef d’Alice est perdue, volée, imprimée dans un quotidien ou compromise d’une façon ou d’une autre, alors toute sa sécurité s’envole. Si la clef compromise était celle d ’un système cryptographique à clef secrète, Alice doit changer sa clef et espérer que le dommage causé est minimum. Si c’était une clef privée, elle a de plus gros problèmes ; sa clef publique est probablement sur tous les serveurs du réseau. Et si Estelle a accès à la clef privée d’Alice, elle peut alors se faire passer pour elle sur le réseau : elle peut lire du courrier chiffré, signer de la correspondance, conclure des contrats, et ainsi de suite. Estelle peut devenir Alice. Quand une clef privée est compromise il est vital de diffuser l’information le plus vite possible à travers le réseau. Toute base de données publique de clefs publiques doit être immédiatement avertie qu’une clef privée est corrompue, sinon quelqu’un qui n’est pas au courant pourrait chiffrer un message avec cette clef. Il faut espérer qu’Alice sait quand sa clef a été compromise. Si un C D C gère les clefs, Alice doit l’avertir que sa clef a été compromise. S’il n ’y a pas de C D C , elle doit alors avertir tous ses correspondants. Quelqu’un doit rendre public le fait que tout message reçu après la perte de la clef est suspect et que personne ne doit envoyer de message à Alice avec la clef publique associée. L’application devrait utiliser un système de datation et les utilisateurs peuvent alors différencier les messages suspects des messages légitimes. Si Alice ne sait pas exactement quand sa clef a été compromise, les choses sont plus difficiles. Alice peut vouloir annuler un contrat signé par la personne qui a volé la clef. Si le système le permet, alors tout un chacun a la possibilité d ’annuler un contrat rien qu’en prétendant que sa clef a été compromise avant la signature du contrat. Seul le juge pourra en débattre. C’est un problème très sérieux qui met en lumière les dangers que prend Alice en liant son identité à une seule clef. Alice ferait mieux d ’avoir différentes clefs pour différentes applications — tout comme elle a différentes clefs dans sa poche qui ouvrent différentes serrures. D ’autres solutions à ce problème sont la biométrie, des limitations d ’utilisation d’une clef, l’insertion de délais et la contre-signature.
196
Chapitre 8
Gestion des clefs
Les procédures et les recommandations sont rarement optimales, mais elles sont ce que l’on peut faire de mieux. La morale de cette histoire est qu’il faut protéger les clefs, et les clefs privées par-dessus tout.
8.10
Longévité des clefs
Aucune clef de chiffrement ne doit être utilisée pour une période indéfinie. Elle devrait expirer automatiquement tout comme un passeport ou une licence. 1 1 y a plusieurs raisons à cela : - Plus la clef sera utilisée longtemps, plus elle aura de chances d’être compromise. Les gens mettent par écrit les clefs, ils les perdent. Les accidents arrivent. Si vous utilisez la même clef pendant un an, il y a bien plus de chances qu’elle soit compromise que si vous l’utilisez un jour seulement. Plus la clef est utilisée longtemps, plus grande est la perte si la clef est compro mise. Si la clef est utilisée seulement pour chiffrer un seul document de budget sur un serveur de fichiers, alors la perte de la clef ne compromet que ce document. Si la même clef est utilisée pour chiffrer tous les budgets sur le serveur de fichiers alors la perte est nettement plus catastrophique. - Plus la clef est utilisée longtemps, plus grande est la tentation pour quelqu’un de fournir l’effort nécessaire pour la retrouver — même si cet effort est une attaque exhaustive. Retrouver une clef partagée par deux unités militaires pendant un jour permettrait à quelqu’un de lire et d’engendrer des messages entre ces deux unités pendant un jour. Retrouver une clef partagée par un état-major de l’armée pendant un an permettrait à la même personne de lire et d’engendrer des mes sages à travers le monde entier pendant toute une année. En ayant conscience du budget, dans notre monde d’après-guerre froide, quelle clef choisiriez-vous d’attaquer? - Il est en général plus facile d ’effectuer une cryptanalyse quand on a plus de texte chiffré avec une même clef. Pour toute application cryptographique, il doit y avoir une consigne qui détermine la longévité d’une clef. Des clefs différentes peuvent avoir des longévités différentes. Pour un système basé sur la connection, tel que le téléphone, il semble logique d’utiliser une clef pour la durée de l’appel et d ’en utiliser une nouvelle à chaque appel. Les systèmes dédiés aux canaux de communication ne sont pas si évidents Les clefs devraient avoir une durée de vie relativement courte, selon la valeur et la quantité de données chiffrées pendant une période donnée. La clef pour une liaison de communication à 1 gigabit par seconde doit être changée plus souvent que la clef pour une liaison par modem à 9600 bauds. En faisant l’hypothèse qu’il existe une méthode efficace pour transmettre des nouvelles clefs à l’aide d ’une clef de chiffrement de clefs, les clefs de session doivent être changées au minimum chaque jour. Les clefs de chiffrement de clefs ne doivent pas être changées aussi souvent. Elles sont utilisées occasionnellement (grosso modo une fois par jour) pour l’échange de clefs. Cela génère peu de texte chiffré au cryptanalyste, et le texte en clair correspondant n’a pas
8.11
Destruction des clefs
197
de forme particulière. Toutefois, si une clef de chiffrement de clefs est compromise, la perte potentielle est énorme : toutes les communications chiffrées avec ces clefs. Dans certaines applications, les clefs de chiffrement de clefs sont changées seulement une fois par mois ou une fois par an. Vous devez comparer le danger induit par le maintien d’une clef pour un bon moment à celui induit par la distribution d ’une nouvelle clef. Les clefs de chiffrement utilisées pour chiffrer des fichiers pour archivage ne doivent pas être changées souvent. Les fichiers peuvent rester chiffrés sur le disque pendant des mois ou des années avant qu’on en ait besoin à nouveau. Les déchiffrer et les rechiffrer avec une nouvelle clef chaque jour n’augmente aucunement la sécurité: cela donne juste plus de matière première au cryptanalyste. Une solution serait de chiffrer chaque fichier avec une clef unique par fichier et ensuite de chiffrer toutes ces clefs avec une clef de chiffrement de clefs. La clef de chiffrement de clefs devrait alors être mémorisée ou stockée dans un endroit sûr. Bien sûr la perte de cette clef signifierait la perte de toutes les autres clefs. Les clefs privées des applications de cryptographie à clef publique ont des durées de vie variables en fonction de l’application. Les clefs privées utilisées pour les signatures numériques et les preuves d’identité doivent durer des années (voire même une vie entière). Les clefs privées utilisées pour jouer à pile ou face peuvent être ignorées directement après avoir terminé le protocole. Même si la sécurité d’une clef est supposée durer toute une vie, il peut être prudent de la changer de tant à autre. Les clefs privées de nombreux réseaux ne sont valables que deux ans ; après cela l’utilisateur doit se procurer une nouvelle clef privée. L’ancienne clef doit toujours rester secrète au cas où l’utilisateur doive vérifier une signature numérique pour cette période. Mais la nouvelle clef devrait être utilisée pour signer de nouveaux documents, réduisant ainsi le nombre de documents dont disposerait un cryptanalyste pour une attaque.
8.11
Destruction des clefs
Etant donné que les clefs doivent être remplacées régulièrement, les vieilles clefs doivent être détruites. Les vieilles clefs ont de la valeur, même si elles ne sont plus jamais utilisées. Avec celles-ci, un adversaire peut lire d ’anciens messages chiffrés [70]. Les clefs doivent être détruites de manière sûre (voir § 10.9). Si la clef est écrite sur un bout de papier, le papier peut être déchiqueté ou brûlé. Veillez à utiliser une machine à déchiqueter de très bonne qualité : de nombreux mauvais déchiqueteurs sont sur le marché. Les algorithmes de ce livre sont protégés des attaques exhaustives qui coûtent des millions de dollars et qui prennent des millions d ’années. Si un adversaire peut retrouver votre clef en récupérant la sortie de la machine à déchiqueter dans votre poubelle, et s’il peut payer 1 0 0 chômeurs dans un pays pauvre 0 , 1 dollar par heure pendant un an pour recoller les pages déchiquetées, cela ne représenterait que 26 0 0 0 $ bien dépensés. Si la clef est dans une mémoire E E P R O M , la clef peut être réécrite plusieurs fois. Si la clef est dans une E P R O M ou une P R O M , la puce doit être broyée en mille morceaux et disséminée aux quatre vents. Si la clef est stockée sur un disque d ’ordinateur, les bits utilisés pour son stockage doivent être réécrits plusieurs fois (voir § 10.9) ou le disque devrait lui-même être déchiqueté. Un problème potentiel est que, dans un ordinateur, les clefs peuvent être facilement copiées et stockées en divers endroits. Tout ordinateur qui autogère sa mémoire, en
Chapitre 8
198
Gestion des clefs
écrivant et en lisant continuellement la mémoire de travail sur le disque, ne fait qu’aug menter le problème. Il n’y a aucun moyen de s’assurer que la clef a effectivement été correctement effacée, plus particulièrement si le système de conduite de l’ordina teur contrôle le processus d ’effacement lui-même. Les plus paranoïaques d ’entre vous doivent envisager l’écriture d’un programme d ’effacement spécial qui balaie tous les disques pour rechercher des copies du motif des bits de la clef dans les blocs non utili sés et alors effacer ces blocs. N’oubliez pas non plus d’effacer le contenu de tout fichier temporaire, ou du fichier de pagination (« swap file ») si nécessaire.
8.12
Gestion des clefs pour la cryptographie à clef publique
La cryptographie à clef publique rend la gestion des clefs plus facile mais elle a ses propres problèmes. Chaque personne n’a qu’une clef publique, peu importe le nombre d’utilisateurs du réseau. Si Alice veut envoyer un message à Bernard, elle doit se pro curer la clef publique de Bernard. Elle peut l’obtenir de plusieurs manières : Elle peut l’obtenir auprès de Bernard. Elle peut l’obtenir auprès d’une base de données centrale. Elle peut l’obtenir à partir de sa propre base de données privée. Le paragraphe 2.5 présente un certain nombre d’attaques contre la cryptographie à clef publique, basée sur Martin qui remplace la clef de Bernard par la sienne. Le scénario est qu’Alice veut envoyer un message à Bernard. Elle demande à la base de données publique et obtient la clef publique de Bernard. Mais Martin, qui est sournois, remplace la clef de Bernard par la sienne. (Si Alice demande directement à Bernard, Martin doit intercepter la communication entre Alice et Bernard et remplacer la clef de Bernard par la sienne.) Alice chiffre son message avec la clef de Martin et l’envoie à Bernard. Martin intercepte le message, le déchiffre, le lit. Il le rechiffre alors avec la vraie clef publique de Bernard et envoie le résultat à Bernard. Ni Alice, ni Bernard ne remarquent quoi que ce soit.
Certificat de clef publique Un CE RTIFIC AT DE c l e f p u b l i q u e est constitué de la clef publique de quelqu’un si gnée par une personne de confiance. Les certificats sont utilisés pour contrecarrer les remplacements d’une clef par une autre [879]. Le certificat de Bernard dans la base de données des clefs publiques contient bien plus que sa clef publique. Il contient des informations concernant Bernard — son nom, son adresse, etc. — et il est signé par quelqu’un en qui Alice a confiance : Ivan, habituellement connu sous le nom d’autorité de certification (A C en abrégé). En signant à la fois la clef et les informations concer nant Bernard, Ivan certifie que ces informations sont correctes et que la clef publique appartient bien à Bernard. Alice vérifie la signature de Ivan et ensuite utilise la clef publique en étant sûre que c’est bien celle de Bernard et de personne d ’autre. Les cer tificats jouent un rôle important dans nombre de protocoles à clef publique tels que le PE M [827] (voir § 24.10) et le X .509 [309] (voir § 24.9).
8.12
Gestion des clefs pour la cryptographie à clef publique
199
Une caractéristique compliquée non-cryptographique accompagne ce genre de système. Quelle est la signification de la certification? Ou, pour s’exprimer autrement, qui est investit du pouvoir de certification, et envers qui? N’importe qui peut signer le certi ficat d’un autre, mais il faut un moyen de filtrer les certificats suspects : par exemple, les certificats d’employés d’une compagnie signés par l’ A C pour une autre compagnie. Normalement, une chaîne de certification transfère la confiance: une seule entité dé signée certifie des agents, ces agents certifient les A C des entreprises, lesquelles A C certifient leurs employés. Voici d’autres questions qui demandent réflexion : - Quel niveau de confiance en l’identité de quelqu’un est induit par son certificat ? - Quelles sont les relations entre une personne et l’A C qui certifie sa clef publique, et comment ces relations peuvent être impliquées par le certificat? - Qui peut-on désigner comme étant la « seule entité de confiance » au sommet de la chaîne de certification? De quelle longueur devrait être une chaîne de certification? L’idéal serait que Bernard suive une sorte de procédure d ’authentification avant que l’AC ne signe son certificat. De plus, une datation ou une indication de la période de validité du certificat est importante pour se protéger des clefs compromises [467]. La datation n’est pas suffisante. Les clefs peuvent être invalidées avant expiration, soit pour des raisons de compromission ou administratives. C ’est pourquoi il est important que l’A C garde une liste des certificats invalidés et que les utilisateurs la consulte régulièrement. Ce problème de révocation de clef est toujours difficile à résoudre. Une paire « clef publique, clef privée » n ’est pas suffisante. Il est certain qu’une bonne application de la cryptographie à clef publique requiert des clefs distinctes pour le chif frement et les signatures digitales. Cette séparation permet d ’avoir différents niveaux de sécurité, temps d’expiration, procédures de duplication, etc... Quelqu’un pourrait signer des messages avec une clef de 2048 bits stockée dans une carte à puce et va lable pour 20 ans, alors qu’ils pourraient utiliser une clef de 768 bits stockée dans un ordinateur et valable pour six mois pour le chiffrement. Une paire unique de clefs pour le chiffrement et la signature n’est pas non plus suf fisante. Une clef privée authentifie une relation ainsi qu’une identité, et les personnes ont plus d’une relation. Alice pourrait vouloir signer un document en tant qu’Alice, l’individu, un autre en tant qu’Alice, vice-présidente de la société « Monolith, S.A. », et un troisième en tant qu’Alice, présidente d ’une organisation communautaire. Certaines de ces clefs sont plus importantes que d ’autres et demandent à être mieux protégées. Alice pourrait avoir à stocker un duplicata de sa clef de travail auprès de l’officier de sécurité de l’entreprise ; elle ne veut pas que l’entreprise ait une copie de la clef avec laquelle elle a signé un emprunt. Tout comme Alice a plusieurs clefs dans sa poche, elle aura plusieurs clefs cryptographiques.
Gestion distribuée des clefs Dans certaines situations, ce genre de gestion des clefs centralisée ne marchera pas. Peut-être qu’il n’y a pas d ’A C en laquelle Alice et Bernard ont confiance. Peut-être
200
Chapitre 8
Gestion des clefs
qu’Alice et Bernard n’ont confiance qu’en leurs amis. Peut-être qu’Alice et Bernard n’ont confiance en personne. La gestion distribuée des clefs, utilisée dans le programme « Pretty Good Privacy » (P G P ) (voir § 24.12) résout ce problème à l’aide de parrains. Les parrains sont d’autres utilisateurs du système qui peuvent signer les clefs publiques de leurs amis. Par exemple, quand Bernard engendre sa clef publique, il en donne une copie à ses amis: Christine et David. Ils connaissent Bernard et donc ils signent chacun la clef publique de Bernard et lui envoient une copie des clefs signées. Maintenant, Bernard présente sa clef publique à une étrangère, Alice; il la lui présente avec les signatures de ses deux parrains. Si Alice connaît et a confiance en Christine, elle a des raisons de croire que la clef de Bernard est valide. Si elle connaît un peu et a quelque peu confiance en Christine et David, elle a des raisons de croire que la clef de Bernard est valide. Si elle ne connaît ni Christine ni David, elle n’a aucune raison de faire confiance à la clef de Bernard. Au fil du temps, Bernard rassemblera bien plus de parrains. Si Alice et Bernard gra vitent dans les mêmes cercles, les chances d ’Alice de connaître un des parrains de Bernard sont élevées. Pour se prémunir contre Martin qui remplace une clef par une autre, un parrain doit s’assurer que la clef de Bernard appartient bien à celui-ci avant de la signer. Le parrain peut demander que la clef soit communiquée lors d ’une rencontre en chair et en os, ou vérifiée par téléphone. L ’avantage de ce mécanisme est qu’il n’y a pas d’A C en qui tout le monde doit avoir confiance. Le défaut est que lorsqu’Alice reçoit la clef publique de Bernard, elle n’a aucune garantie de connaitre un des parrains, et par conséquent aucune garantie de pouvoir avoir confiance dans la validité de cette clef.
Chapitre 9
Types et modes d’algorithmes Il existe deux modèles de base d ’algorithmes à clef secrète : l’algorithme de chiffrement par blocs et l’algorithme de chiffrement en continu. Les algorithmes de chiffrement par blocs manipulent des blocs de texte en clair et de texte chiffré — généralement de 64 bits mais quelquefois plus longs. Les algorithmes de chiffrement en continu manipulent des flots de textes en clair et de textes chiffrés bit par bit ou octet par octet (ou même mot de 32 bits par mot de 32 bits). Avec un algorithme de chiffrement par blocs, le même bloc de texte en clair sera toujours chiffré en un même bloc de texte cliiffré, en utilisant la même clef. Avec un algorithme de chiffrement en continu, le même bit ou octet de texte en clair sera chiffré en un bit ou un octet différent à chaque chiffrement. Un mode cryptographique combine en général un algorithme cryptographique, une sorte de rétroaction et des opérations simples. Les opérations sont simples car la sécurité est une fonction du chiffrement sous-jacent, et non du mode. De plus, le mode de chiffrement ne devrait pas compromettre la sécurité de l’algorithme dont il découle. Il y a d’autres motifs de sécurité : les motifs dans un texte en clair doivent être dissimu lés, l’entrée de l’algorithme cryptographique doit être rendue aléatoire, la manipulation du texte en clair par insertion d’erreurs dans le texte chiffré doit être difficile et le chif frement de plus d’un message avec la même clef doit être possible. Nous discuterons de tout ceci en détails dans les paragraphes suivants. L’efficacité est aussi à prendre en considération. Le mode ne doit pas être moins efficace, de manière significative, que l’algorithme cryptographique sous-jacent. Dans certaines circonstances, il est important que le texte chiffré ait la même taille que le texte en clair. Une troisième considération concerne la tolérance aux fautes. Certaines applications ont besoin de chiffrer ou de déchiffrer en parallèle, alors que d’autres ont besoin de faire autant de précalculs que possible. Avec encore d ’autres, il est important que le processus de déchiffrement soit capable de surmonter des erreurs de bits dans le flot de textes chiffrés, des pertes ou des rajouts de bits. Comme nous allons le voir, les différents modes ont différents sous-ensembles de ces caractéristiques.
202
9.1
Chapitre 9
Types et modes d’algorithmes
Carnet de codage électronique
Le mode du c a r n e t d e c o d a g e é l e c t r o n i q u e (E C B pour « Electronic CodeBook ») est la méthode la plus évidente pour utiliser un algorithme de chiffrement par blocs un bloc de texte en clair se chiffre en un bloc de texte chiffré. Comme un même bloc de texte en clair sera toujours chiffré en un même bloc de texte chiffré, il est théoriquement possible de créer un carnet de codage de textes en clair et de leurs textes chiffrés correspondants. Néanmoins, si la taille du bloc est de 64 bits — le carnet de codage aura donc 264 entrées — ce qui est bien trop grand pour être précalculé et stocké. Et rappelez-vous, chaque clef a un carnet différent. C ’est le mode opératoire le plus simple à utiliser. Chaque bloc de texte en clair est chiffré indépendamment. Vous n’avez pas à chiffrer un fichier linéairement : vous pouvez d’abord chiffrer les 1 0 blocs du milieu, ensuite les blocs de la fin puis ceux du début. C ’est important pour des fichiers chiffrés auxquels on accède aléatoirement, comme une base de données. Si une base de données est chiffrée par le mode ECB, alors n’importe quel enregistrement peut être ajouté, effacé, chiffré ou déchiffré indépendamment de tous les autres — en faisant l’hypothèse que les enregistrements ont un nombre entier de blocs de chiffrement. Et le processus est dérivable ; si vous avez de multiples processeurs de chiffrement, ils peuvent chiffrer ou déchiffrer différents blocs qui n’ont aucun rapport les uns avec les autres. Le défaut du mode E CB est que si un cryptanalyste a le texte en clair et le texte chiffré de plusieurs messages, il peut commencer à construire un carnet de codage sans connaître la clef. Dans la plupart des situations du monde réel, des fragments de mes sages ont tendance à se répéter. Différents messages peuvent avoir des séquences de bits en commun Des messages engendrés par ordinateur, tel que le courrier électronique, peuvent avoir des structures régulières. Les messages peuvent être redondants ou avoir de longues chaînes de zéros ou d ’espaces. Si un cryptanalyste apprend que le texte en clair « 5e081bc5 » donne le texte chiffré « 7ea593a4 », il est capable de déchiffrer ce bloc de texte chiffré dès qu’il apparaît dans un autre message. Si les messages chiffrés contenant beaucoup de redondances, et qu’elles ont tendance à apparaître aux mêmes endroits dans différents messages, un cryptanalyste peut obtenir beaucoup d’informations. Il peut mener des attaques statistiques contre le texte en clair sous-jacent, sans se soucier du niveau de l’algorithme de chiffrement par blocs. Cette vulnérabilité est plus grande au début et à la fin des messages où apparaissent des en-têtes et des conclusions bien définies qui contiennent des informations concer nant l’expéditeur, le destinataire, la date, etc. Ce défaut est parfois appelé débuts stéréotypés et fins stéréotypées et sera évité par les modes décrits ci-après. Le côté positif est qu’il n’y a pas de risque, au point de vue sécurité, à chiffrer de multiples messages avec la même clef. En fait, chaque bloc peut être considéré comme un message à part chiffré avec la même clef. Les erreurs de bits dans le texte chiffré, quand il est déchiffré, feront que le bloc entier de texte en clair sera incorrectement déchiffré mais n’affecteront pas le reste du texte en clair. Néanmoins, si un bit du texte chiffré est accidentellement perdu ou rajouté, le reste du texte chiffré sera incorrecte ment déchiffré à moins qu’il y ait une sorte de structure d ’encadrement pour réaligner les limites du bloc.
9.2
Bloc rejoué
203
Remplissage La plupart des messages ne se divisent pas exactement en un nombre entier de blocs de 64 bits (ou de toute autre taille) : il y a d ’habitude un bloc court à la fin. L’ECB traite des blocs de 64 bits. Le rem plissage permet de régler ce problème. Remplissez le bloc avec un schéma régulier des zéros, des uns, des uns et des zéros en alternance — pour compléter le bloc. Si vous devez être capable de retirer le remplissage après le déchiffrement, ajoutez le nombre d ’octets de remplissage comme dernier octet du dernier bloc. Par exemple, faites l’hypothèse que la taille des blocs est de 64 bits, et que le dernier bloc contient 3 octets (24 bits). Cinq octets de remplissage sont nécessaires pour transformer le dernier bloc en un bloc de 64 bits; ajoutez 4 octets de 0 et un octet final avec le nombre 5. Après déchiffrement, détruisez les 5 derniers octets du dernier bloc déchiffré. Pour que cette méthode marche correctement, tous les message doivent être remplis. Même si le texte en clair s’achève à la limite d’un bloc, vous devez remplir un bloc complet. Sinon, vous pouvez utiliser un caractère marqueur de fin de fichier pour délimiter la fin du texte en clair, puis remplir à la suite de ce caractère. La figure 9.1 propose une alternative appelée vol de texte chiffré [405]. E i n- i est le dernier bloc en clair plein et M .n est le bloc final en clair court. Cn~j est le dernier bloc chiffré plein et Cn est le bloc final chiffré court. C' est juste un résultat intermédiaire et ne fait pas partie du texte chiffré transmis. Chiffrement
Mn-1
Déchiffrement
Mn
1r
Cnu
«=•
C’ r
1
1f
Cn
°k
C„
ir C’
Mn
F ig. 9.1
9.2
1r
1r C’
Vol de texte chiffré en mode ECB
Bloc rejoué
Un défaut plus dangereux avec le mode E C B est que l’adversaire pourrait modifier les messages chiffrés sans connaître la clef, ni même l’algorithme, de manière à duper le destinataire légitime. Ce défaut fut décrit en premier dans [295], Pour illustrer le problème, considérons un système de transfert de fonds inter-bancaire qui fait circuler de l’argent entre des comptes dans différentes banques. Pour rendre
204
Chapitre 9
Types et modes d’algorithmes
la vie plus facile pour le système informatique de la banque, les banques se sont mises d’accord sur un format de message standard pour les transferts d’argent qui ressemble à ceci : Banque A : émettrice Banque B: bénéficiaire Nom du déposant Numéro de compte du déposant Montant du dépôt
15 blocs 15 blocs 6 blocs 2 blocs 1 bloc
Un bloc correspond à un chiffrement de bloc de 8 octets. Les messages sont chiffrés à l’aide d’un algorithme de chiffrement par blocs en mode ECB. Martin, qui écoute les communications entre les deux banques, la banque d ’Alice et la banque de Bernard, peut utiliser cette information pour s’enrichir. Premièrement, il programme son ordinateur pour enregistrer tous les messages chiffrés de la banque d’Alice vers la banque de Bernard. Ensuite, il transfère 100 dollars de la banque d ’Alice vers son compte à la banque de Bernard. Plus tard, il recommence. En utilisant son ordinateur, il met les messages enregistrés en corrélation en cherchant une paire de messages identiques. Ces messages sont ceux qui autorisent le transfert de 100 dollars vers son compte. S’il y a plus d’une paire de messages identiques (ce qui est très certainement probable), il fait un autre transfert et enregistre le résultat. Finalement, il isole le message qui a autorisé la transaction. Maintenant, il peut insérer à volonté ce message dans la liaison de communication. Chaque fois qu’il envoie un message à la banque de Bernard, un nouveau montant de 100 dollars est crédité sur son compte. Lorsque les deux banques contrôleront la balance de leurs transferts (probablement en fin de journée), elles détecteront les autorisations de transfert fantômes ; mais si Martin est malin, il aura déjà retiré l’argent et sera en route vers une république exotique où il n’y a pas de loi d ’extradition. Et il a sûrement commis son forfait avec des montants beaucoup plus élevés que 1 0 0 dollars et avec de nombreuses autres banques. A première vue, les banques pourraient aisément éviter cela en rajoutant une datation à leurs messages. Datation Banque A : émettrice Banque B : bénéficiaire Nom du déposant Numéro de compte dudéposant Montant du dépôt
1 bloc 15 blocs 15 blocs 6 blocs 2 blocs 1 bloc
Deux messages identiques seraient facilement identifiés avec ce système. Mais, en utili sant une méthode appelée blocs rejoués, Martin peut encore s’enrichir. La figure 9.2 montre que Martin peut extraire les huit blocs chiffrés correspondant à son nom et son numéro de compte : les blocs 5 à 12. En analysant cette figure, Martin, désormais armé, ricane dans son coin. Il intercepte aléatoirement des messages de la banque d ’Alice vers la banque de Bernard et remplace les blocs 5 à 12 dans le message avec les octets correspondant à son nom et à son numéro de compte. Ensuite, il les envoie à la banque de Bernard.Il n’a pas à savoir qui est le déposant légitime ; il n ’a même pas à connaître lemontantdu transfert (bien
9.3
Mode de chiffrement avec chaînage de blocs
205
Numéro de bloc 1
2
Banque Datation émettrice
3
4
Banque bénéficiaire
5
6
7
8
9
10
Nom du déposant
11
12
Compte du déposant
13
Montant
Cham p
FlG. 9 2 - Exemple d’un dossier à blocs chiffrés
qu’il puisse corréler les messages des différents transferts avec des montants différents qu’il a effectués vers son compte, et ainsi déterminer les blocs chiffrés correspondant à certains montants). Simplement, il remplace les noms et les numéros de compte par les siens et il contemple le solde de son compte augmenter, (il faut que Martin soit prudent et ne modifie pas le message de retrait, imaginez rien qu’une seconde que chacun ait une longueur différente.) Cela prendra plusieurs jours aux banques pour détecter cela. Lorsqu’elles feront la balance journalière des transferts, tout sera en ordre. Ce ne sera certainement pas avant que l’un des déposants honnêtes s’aperçoive que l’argent ne lui a pas été crédité, ou que quelqu’un remarque l’activité inhabituelle du compte de Martin, que les banques découvriront l’escroquerie. Martin n’est pas stupide, et d’ici là il aura fermé son compte, changé son nom et acheté une villa en Argentine. Les banques peuvent minimiser le problème en changeant fréquemment de clef mais Martin peut aussi travailler plus vite. Néanmoins, rajouter un C A M peut aussi ré soudre le problème. Pourtant, c ’est un défaut fondamental en mode ECB. Martin peut retirer, répéter ou échanger des blocs à volonté. La solution est une technique appelée chaînage.
9.3
Mode de chiffrement avec chaînage de blocs
Le chaînage utilise une méthode de rétroaction car les résultats du chiffrement du bloc précédent sont réutilisés comme entrées pour le chiffrement du bloc courant. En d’autres termes, chaque bloc est utilisé pour modifier le chiffrement du bloc suivant. Chaque bloc chiffré dépend non seulement du bloc de texte en clair qui l’a engendré mais aussi de tous les blocs de texte en clair qui précèdent celui-ci. En mode de chiffrement avec chaînage de blocs (C B C pour « cipher block chaining »), le texte en clair est combiné par ou exclusif avec le bloc chiffré précédent avant d’être chiffré. La figure 9.3a montre le chiffrement CBC en action. Après qu’un bloc de texte en clair a été chiffré, le texte chiffré correspondant est aussi stocké dans un registre de rétroaction. Avant que le bloc suivant de texte en clair soit chiffré, il est combiné par ou exclusif avec le registre de rétroaction pour devenir la nouvelle entrée de l’algorithme de chiffrement. Le texte chiffré résultant est à nouveau stocké dans le registre de rétroaction pour être combiné par ou exclusif avec le bloc de texte en clair suivant, et ainsi de suite jusqu’à la fin du message. Le chiffrement de chaque
Chapitre 9
206
Types et modes d’algorithmes
bloc dépend de tous les blocs précédents. M.
i-l
■VI
M.
i
S
M. , 1+1
Ci-l
i+J
M i-l
C:i+1
M.
' 'i
M.
'" i + l
(b) Déchiffrement CBC
(a) Chiffrement CBC
F ig. 9.3 - Mode de chiffrement par chaînage de blocs Le déchiffrement est aussi facile(voir la figure 9.3b). Un bloc de texte chiffré est déchiffré normalement, et aussi sauvé dans le registre de rétroaction. Une fois que le bloc suivant a été déchiffré, il est combiné par ou exclusif avec le contenu du registre de rétroaction. Ensuite, le bloc suivant de texte chiffré est sauvé dans le registre de rétroaction, et ainsi de suite jusqu’à la fin du message. Mathématiquement, on peut écrire : Ct = E fc i- M t © C j - i )
■Mi = C i-! © D n{Ct).
Vecteur d’initialisation Le mode C B C ne produit des blocs chiffrés différents pour des mêmes blocs en clair seulement si un des blocs précédents est différent. Deux messages identiques donneront toujours le même texte chiffré. Pis encore, deux messages qui commencent de la même façon donneront le même texte chiffré jusqu’à la première différence. Certains messages ont un en-tête commun : un en-tête de lettre, une ligne « Frorri » d’un message électro nique, par exemple. Bien qu’une attaque par blocs rejoués soit toujours impossible, ce début identique donne encore d’utiles informations au cryptanalyste. Evitez cela en chiffrant des données aléatoires comme premier bloc. Ce bloc de données aléatoires est appelé vecteur d’initialisation (IV pour « initialization vector »), variable d ’initialisation ou valeur initiale de chaînage. L’IV n’a pas de sens : il est juste là pour rendre chaque message unique. Quand le destinataire déchiffre ce bloc, il l’utilise pour remplir le registre de rétroaction et l’ignore par ailleurs. Une datation fait un bon IV. Sinon, utilisez des bits aléatoires.
9.3
Mode de chiffrement avec chaînage de blocs
201
Avec l’addition de l’IV , des messages en clair identiques donneront des messages chiffrés différents. Il est donc impossible pour un espion de tenter une attaque par blocs rejoués, et encore plus difficile de constituer un carnet de codage. Bien que l’IV devrait être unique par message chiffré avec la même clef, ce n’est pas une condition absolue. L’IV n’a pas besoin d’être tenu secret ; il peut être transmis en clair avec le texte chiffré. Si vous n’êtes pas persuadé, considérez le raisonnement suivant. Nous possédons un message de plusieurs blocs: B\, B 2 , ......., B ,. B\ est chiffré avec l’IV. B 2 est chiffré avec le texte chifré de Bi en tant qu’IV . B 3 est chiffré avec le texte chifré de B 2 en tant qu’IV , etc. Donc, s’il y a n blocs, il y a n — 1 IV , même si l’IV original est gardé secret. Il n’y a donc aucune raison de garder l’IV secret ; l’IV est juste un simple bloc de texte chiffré — un peu comme Bq qui commence la série.
Remplissage Le remplissage marche exactement comme dans le mode E B C , mais dans certaines applications le texte chiffré doit avoir exactement la même taille que le texte en clair. Peut-être qu’un texte en clair doit être chiffré et mis exactement à la même place en mémoire. Dans ce cas, vous devez chiffrer le dernier bloc court différemment. Faites l’hypothèse que le dernier bloc a j bits. Après avoir chiffré le dernier bloc complet, rechiffrez le texte chiffré, sélectionnez les j bits les plus à gauche du texte chiffré deux fois et combinez le résultat par ou exclusif avec le bloc court pour donner le texte chiffré. Cela est illustré par la figure 9.4. M
n-2
M
Pn (j-bits de long)
-*0
Sélectionne les j-bits
-e
les plus a gauchi “ n-2
“n 1
C (j-bits de long)
F ig. 9.4 - Méthode de chiffrement pour le dernier bloc La faiblesse ici est que bien que Martin ne puisse pas retrouver le dernier bloc, il peut le modifier systématiquement en changeant des bits du texte chiffré. Si les tout derniers bits du texte chiffré contiennent de l’information vitale, c ’est une faiblesse. Si les derniers bits contiennent simplement des informations de gestion, ce n’est pas un problème. Le vol de texte chiffré est une meilleure méthode (voir la figure 9.5) [405]. M „_ i est le dernier bloc en clair plein et M n est le bloc final en clair court. Cn^\ est le dernier bloc chiffré plein et Cn est le bloc final chiffré court. C ' est juste un résultat intermédiaire
208
Chapitre 9
Types et modes d’algorithmes
et ne fait pas partie du texte chiffré transmis. L’avantage de cette méthode est que tous les bits d ’un message en clair passent par l’algorithme de chiffrement.
Propagation d’erreurs Le mode C B C peut être décrit comme une rétroaction du texte chiffré du côté du chiffrement et une alimentation en texte chiffré du côté du déchiffrement. Ceci a des conséquences sur les erreurs. Une erreur d ’un seul bit dans un bloc de texte en clair va affecter le bloc de texte chiffré correspondant et tous les blocs de textes chiffrés qui suivent. Ce n’est pas de grande portée parce que le déchiffrement va inverser cet effet et le texte en clair retrouvé aura la même seule erreur. Les erreurs dans le texte chiffré sont plus fréquentes. Elles peuvent tout simplement provenir d ’un bruitage de la liaison ou d ’un disfonctionnement du dispositif de stockage. En mode C B C , une erreur d ’un seul bit dans le texte chiffré affecte un bloc, et un bit du texte en clair reconstruit. Le bloc contenant l’erreur est complètement brouillé. Le bloc suivant a une erreur de 1 bit au même endroit que le bit erroné. Cette transformation d’une petite erreur dans le texte chiffré en une grande erreur dans le texte en clair est appelée amplification d’erreur. C’est un handicap majeur. Les blocs après le deuxième ne sont pas affectés par l’erreur, donc le mode C B C est auto-réparateur. Deux blocs sont affectés par une erreur mais le système récupère et continue à fonctionner correctement pour tous les blocs suivants. Le C B C est un exemple d ’algorithme de chiffrement par blocs utilisé d ’une manière auto-synchronisée, mais seulement au niveau du bloc. Bien que le mode C B C récupère rapidement les erreurs de bits, il ne récupère pas du tout les erreurs de synchronisation. Si un bit est ajouté ou perdu dans le flot de texte chiffré, alors tous les blocs suivants sont décalés d ’un bit et le déchiffrement va produire du charabia indéfiniment. Tout cryptosystème qui utilise le mode C B C doit s’assurer que la structure des blocs reste intacte, soit par encadrement soit en stockant les données dans des paquets de plusieurs blocs.
9-4
Algorithmes de chiffrement en continu
209
Problèmes de sécurité Des problèmes potentiels sont causés par la structure même du C B C . Primo, du fait qu’un bloc de texte chiffré affecte les blocs suivants d’une manière simple, Martin peut ajouter des blocs à la fin d ’un message chiffré sans être détecté. Ce sera à coup sûr déchiffré en charabia, mais dans certaines situations, ce n’est pas désirable. Si vous utilisez le C B C , vous devriez structurer votre texte en clair de façon à savoir où le message s’arrête et de pouvoir détecter les rajouts de blocs supplémentaires. Secundo, Martin peut altérer un bloc de texte chiffré pour introduire des changements voulus dans le bloc déchiffré de texte en clair. Par exemple, si Martin change un seul bit de texte chiffré, le déchiffrement du bloc entier sera incorrect, mais le bloc suivant comportera une erreur d ’ 1 bit en lieu et place du bit correspondant. Il y a des situations où ceci est désirable. Le message en clair entier devrait inclure une sorte de contrôle redondant ou une authentification. Finalement, bien que les motifs du texte en clair soient dissimulés par le chaînage, les très longs messages auront encore des motifs. Le paradoxe de l’anniversaire prévoit qu’il y aura des blocs identiques après 2m / 2 blocs, où m est la taille du bloc. Pour un bloc d ’une taille de 64 bits, ça représente à peu près 34 giga-octets. Un message doit être incroyablement long avant que ce ne soit un problème.
9.4
Algorithmes de chiffrement en continu
Les algorithmes de chiffrement en continu convertissent le texte en clair en texte chiffré 1 bit à la fois. La réalisation la plus simple d ’un algorithme de chiffrement en continu est illustrée par la figure 9.6. Un générateur de codons 1 engendre un flux de bits (appelons-les codons) : k\, k,2 , k%, ... , fcj. Ce flux est combiné par ou exclusif avec le flux de bits du texte en clair m j, ?7i2 , m 3 , ..., m ,, pour produire le flux de bits du texte chiffré. Ci = mi © h
F ig. 9.6 - Chiffrement en continu 1. Note du traducteur : le term e « c o d o n » a été utilisé pou r alléger la traduction de termes techniques anglo-saxons qui n ’ont pas d ’équivalents simples en français.
210
Chapitre 9
Types et modes d’algorithmes
Du côté du déchiffrement, les bits du texte chiffré sont combinés par ou exclusif avec un flux identique de codons pour retrouver les bits du texte en clair. rrii = a © kt
Comme : ml ® k i @ki = ml
tout va bien. La sécurité du système dépend entièrement des détails internes du générateur de co dons. Si le générateur de codons engendre un flux continu de zéros, le texte chiffré sera identique au texte en clair et toute l’opération sera inutile. Si le générateur de codons engendre un motif répétitif de 16 bits, l’algorithme n’est rien d’autre que le simple algorithme du ou exclusif qui n’est pas du tout sûr (voir § 1.4). Si le générateur de codons engendre une suite de bits aléatoires (pas pseudo-aléatoires, vraiment aléatoires — voir § 2 .8 ), vous avez la technique du masque jetable et une sécurité parfaite. La sécurité des algorithmes de chiffrement en continu concrets est entre les deux ex trêmes (ou exclusif et masque jetable) — idéalement, elle est plus proche du masque jetable. Le générateur de codons engendre un flux de bits qui ont l’air aléatoires, mais en fait il est déterministe et il peut être reproduit de façon infaillible au moment du déchiffrement. Plus la sortie du générateur est aléatoire, plus il est difficile pour le cryptanalyste de le casser. Si, néanmoins, le générateur de codons engendre le même flot de bits chaque fois qu’on l’active, le système cryptographique résultant sera facile à casser. Un exemple montrera mieux pourquoi. Si Estelle a un texte chiffré et le texte en clair correspondant, elle peut combiner par ou exclusif le texte en clair avec le texte chiffré pour retrouver le flux de codons. Ou, si elle dispose de deux textes chiffrés avec le même flux de codons, elle peut les combiner par ou exclusif pour obtenir le résultat de la combinaison par ou exclusif des deux textes en clair. C ’est facile à casser et elle peut alors combiner par ou exclusif un des textes en clair avec le texte chiffré pour retrouver le flux de codons. Maintenant, chaque fois qu’elle intercepte un message chiffré, elle a les codons néces saires pour déchiffrer le message. De plus, elle peut déchiffrer et lire tout texte chiffré qu’elle aurait intercepté avant. Quand Estelle obtient une seule paire « texte en clair, texte chiffré », elle peut tout lire. C’est pourquoi tous les algorithmes de chiffrement en continu utilisent des clefs. La sor tie du générateur de codons est une fonction de la clef.Maintenant, si Estelle a une paire « texte en clair, texte chiffré », elle peut seulement lire les messages chiffrés avec une seule clef. Changez la clef et l’adversaire se retrouve à la case départ. Les algorithmes de chiffrement en continu sont spécifiquement utiles pour chiffrer des communications continues : un lien T - l entre deux ordinateurs, par exemple. Un générateur de codons est composé de trois parties de base (voir la figure 9.7). L’état interne décrit l’état courant du générateur de codons. Deux générateurs de codons, avec la même clef et le même état interne, produisent le même flux de codons. La fonction de sortie prend l’état interne et engendre un codon (un bit). La fonction état-suivant prend l’état interne et engendre un nouvel état interne.
9.5
Chiffrement autosynchrone, en continu
F ig. 9.7
9.5
211
A l’intérieur d’un générateur de codons
Chiffrement autosynchrone en continu
Dans un algorithme de chiffrement autosynchrone en continu, chaque bit du flux de codons est une fonction d ’un nombre fixe de bits du texte chiffré qui précède [1383]. Les militaires appellent cela un chiffrement à clef automatique (C T A K pour « ciphertext auto key »). L ’idée de base a été brevetée en 1946 [6 6 8 ]. La figure 9.8 illustre un chiffrement autosynchrone en continu. L’état interne est une fonction des n bits précédents du texte chiffré. La complexité cryptographique réside dans la fonction de sortie qui prend l’état interne et qui engendre un codon. Comme l’état interne dépend entièrement des n bits précédents du texte chiffré, au déchiffrement, le générateur de codons se synchronisera automatiquement avec le gé nérateur de codons du chiffrement après avoir reçu n bits de texte chiffré.
FlG. 9.8 - Un générateur de codons autosynchrone
Chapitre 9
212
Types et modes d’algorithmes
Dans des réalisations intelligentes de ce mode, chaque message commence avec un en-tête aléatoire long de n bits. Cet en-tête est chiffré, transmis et déchiffré. Le déchif frement en sera incorrect, mais après ces n bits les deux générateurs de codons seront synchronisés. L’inconvénient du chiffrement autosynchrone en continu est qu’il est sujet à la propa gation d’erreur. Pour chaque bit de texte chiffré corrompu durant la transmission, le générateur de codons de déchiffrement produira n codons erronés. Donc, pour chaque erreur de texte chiffré, il y aura n erreurs correspondantes dans le texte en clair, jusqu’à ce que le bit corrompu sorte de l’état interne.
Problèmes de sécurité Les systèmes de chiffrement autosynchrone en continu sont aussi vulnérables aux at taques par blocs rejoués. D ’abord, Martin enregistre quelques bits de texte chiffré. Puis, un peu plus tard, il place cet enregistrement dans la communication. Après quelque charabia initial pendant que le récepteur se resynchronise, le vieux texte chiffré sera déchiffré normalement comme légitime. Le récepteur n’a aucun moyen de déterminer que ces données ne sont pas courantes, mais qu’il s’agit de vieilles données rejouées. A moins qu’un système de datation soit utilisé, Martin peut convaincre une banque de créditer son compte plusieurs fois en répétant toujours le même message (en suppo sant que la clef n’ait pas changé, bien sûr). D ’autres faiblesses dans ce type de schéma pourraient être exploitées dans le cas de fréquentes resynchronisations [412].
9.6
Chiffrement à rétroaction
Un bloc chiffré peut aussi être utilisé en tant que chiffrement autosynchrone en continu ; cela s’appelle le mode de chiffrement à rétroaction (C F B pour « Cipher Feedback »). Avec le mode C B C , le chiffrement ne peut pas commencer avant qu’un bloc complet de données ait été reçu. C ’est un défaut dans certaines applications réseaux. Dans l’environnement d ’un réseau sûr, par exemple, un terminal doit pouvoir transmettre chaque caractère à l’ordinateur central dès qu’il est entré. Quand les données à traiter se présentent sous forme de paquets de la taille de l’octet, le mode C B C ne fonctionnera pas. En mode C F B , les données peuvent être chiffrées par unités plus petites que la taille de bloc. L ’exemple suivant chiffre un caractère ASCII à la fois (on parle alors de CFB à 8 bits). Mais le chiffre 8 n’est pas sacré, vous pouvez chiffrer les données un bit à la fois en utilisant un C F B à 1 bit, bien qu’utiliser un chiffrement complet d’un bloc pour un seul bit représente beaucoup de travail ; un chiffrement en continu serait une meilleure idée. (Réduire le nombre de rondes d’un chiffrement par blocs pour accélérer les choses n’est pas recommandé [1280] ) Vous pouvez aussi utiliser un C FB à 64 bits, ou tout autre C F B à n bit où n est inférieur ou égal à la taille du bloc. La figure 9.9 illustre un C FB à 8 bits appliqué à un algorithme de chiffrement par blocs de 64 bits. Un algorithme de chiffrement par blocs en mode C F B manipule une file d’attente de la taille d’un bloc d’entrée. Initialement, la file d’attente est remplie avec un IV , comme en mode C B C . La file d ’attente est chiffrée et les huit bits les plus à gauche du résultat sont combinés par ou exclusif avec le premier caractère de 8 bits du texte en clair pour devenir les 8 premiers bits du texte chiffré. Ce caractère peut
9.6
213
Chiffrement à rétroaction
maintenant être transmis. Les mêmes huit bits sont placés dans les huit bits les plus à droite de la file d’attente et tous les autres bits sont décalés de huit positions vers la gauche. Les huit bits les plus à gauche sont ignorés. Le caractère en clair suivant est alors chiffré de la même manière. Le déchiffrement est le processus inverse. Des deux côtés, chiffrement et déchiffrement, l’algorithme de chiffrement par blocs est utilisé dans son mode de chiffrement.
F ig. 9.9 - Mode de chiffrement à rétroaciion à
8
bits
Si n est la taille du bloc de l’algorithme, alors un C FB à n bit ressemble à ceci (voir la figure 9.10) : Ci = A4t © E k {C%- i)
M.i = Ci © EK(Ci~i).
F i g . 9 .1 0
- CFB à n bit avec un algorithme à n bit
Chapitre 9
Types et modes d’algorithmes
Tout comme le mode C B C , le mode C FB lie les caractères du texte en clair entre eux de manière que le texte chiffré dépende de tout le texte en clair qui précède.
Vecteur d’initialisation Pour initialiser le processus C FB , l’entrée de l’algorithme de blocs doit être initiée par un IV. Tout comme l’IV du mode C B C , il n’a pas besoin d’être secret. Néanmoins, l’IV doit être unique2. Si le l’IV du mode C F B n’est pas unique, un cryptanalyste peut retrouver le texte en clair correspondant. LTV doit être changé avec chaque message. Ce peut être un nombre de série, qui augmente après chaque message et qui ne se répète pas tout au long de la vie de la clef. Pour des données chiffrées à stocker, cela peut être une fonction de l’index utilisé pour rechercher les données.
Propagation d’erreurs Avec le mode C F B , une erreur dans le texte en clair affecte tous les textes chiffrés suivants et cette erreur est inversée par le déchiffrement. Une erreur dans le texte chiffré est plus intéressante à considérer. Le premier effet d ’une erreur d ’un seul bit dans le texte chiffré est de provoquer une erreur d’un seul bit dans le texte en clair. Après cela, cette erreur entre dans le registre à décalage, où elle embrouille tout jusqu’à ce qu’elle ressorte à la fin du registre. En mode C FB à 8 bits, 9 octets de texte en clair déchiffré sont embrouillés par une erreur d’un seul bit dans le texte chiffré. Après cela, le système récupère et tous les textes en clair suivants sont déchiffrés correctement. En général, en mode C F B à n bit, une seule erreur d’un texte chiffré affectera le déchiffrement du bloc présent et des m /n —1 blocs suivants, où m est la taille du bloc Un problème subtil avec ce type de propagation d’erreur est que si Martin connaît le texte en clair de la transmission, il peut changer 1 état de certains bits d’un bloc donné et ainsi le faire déchiffrer en ce qu’il veut. Le bloc suivant peut être déchiffré comme du charabia, mais les dégâts peuvent déjà avoir été accomplis. Et il peut changer les derniers bits d ’un message sans être détecté. Le mode C F B est aussi autoréparateur pour ce qui est des erreurs de synchronisation. L’erreur entre dans le registre à décalage, embrouille 8 octets de données, jusqu’à ce qu’elle ressorte à l’autre bout. Le C FB est un exemple d ’algorithme de chiffrement par blocs utilisé comme algorithme de chiffrement autosynchrone en continu.
9.7
Chiffrement synchrone en continu
Dans un algorithme de chiffrement synchrone en continu, le flux de codons est engendré indépendamment du flux du message. Les militaires appellent cela un chiffrement à clef automatique de clef (K A K pour « Key Auto-Key »). Du côté du déchiffrement, un autre générateur de codons produit un flux identique de codons, les uns après les autres. Tout se passe bien tant que les deux générateurs sont synchrones. Si l’un des deux saute une étape du cycle ou si un bit du texte chiffré est perdu pendant la transmission, alors chaque caractère du texte chiffré après l’erreur ne pourra plus être déchiffré correctement. 2. C ’est différent de l’ IV du m od e C B C , qui devrait être unique mais n ’a pas à l’ être.
9.7
215
Chiffrement synchrone en continu
Si cela arrive, l’émetteur et le récepteur doivent resynchroniser leurs générateurs de codons avant de continuer. Pour compliquer les choses, ils doivent le faire de façon à ce qu’aucune partie du flux de codons ne soit réutilisée, et donc la solution simpliste qui consiste à revenir à un état antérieur ne marchera pas. Un avantage, toutefois, est que les chiffrements synchrones en continu ne propagent pas les erreurs de transmission. Si un bit est corrompu durant la transmission (ce qui est nettement plus probable que de perdre un bit) alors seul le bit erroné sera mal déchiffré. Tous les bits qui précèdent ou qui suivent ne seront pas affectés. Comme un générateur de codons doit engendrer le même flux au chiffrement et au dé chiffrement, il doit être déterministe. Comme il est réalisé par une machine à états finis (c’est-à-dire, un ordinateur), la suite finira par se répéter. Ces générateurs de codons sont appelés périodiques. Excepté pour les masques jetables, tous les générateurs de codons sont périodiques. Un générateur de codons doit avoir une longue période, bien plus longue que le nombre de bits que le générateur devra produire entre deux changements de clef. Si la période est plus courte que le texte en clair, alors différentes parties du texte en clair seront chiffrées de la même manière — un gros défaut. Si un cryptanalyste connaît une partie du texte en clair, il peut reconstituer une partie du flot de clefs et l’utiliser pour en savoir plus sur le texte en clair. Même si le cryptanalyste n’a que le texte chiffré, il peut combiner par ou exclusif les parties chiffrées avec le même flot de clefs et obtenir les combinaisons par ou exclusif du texte en clair avec ce dernier. C ’est juste un algorithme de combinaison par ou exclusif avec une très longue clef. La longueur suffisante d ’une période dépend de l’application. Un générateur de codons qui chiffre un lien T —1 en continu chiffrera 237 bits par jour. La période du générateur de codons doit être bien plus grande que cela, même si la clef est changée tous les jours. Si la période est assez longue, vous n’auriez à devoir changer la clef que chaque semaine ou chaque mois. Le chiffrement synchrone en continu protège aussi contre les insertions et les omissions dans le texte chiffré, car elles causeraient un perte de synchronisation et seraient tout de suite détectées. En revanche, il ne protège pas tout à fait contre la modification d’un bit. Tout comme en mode C F B , Martin peut modifier certains bits du flux. S’il connaît le texte en clair, il peut faire l’opération de façon à imposer le texte déchiffré. Les bits suivants seront déchiffrés incorrectement (jusqu’à ce que le système récupère), mais dans certaines applications, Martin peut occasionner beaucoup de dommages.
Attaque par insertion Les algorithmes de chiffrement synchrone en continu sont vulnérables à une attaque par insertion [100]. Martin a enregistré un flux de texte chiffré, mais il ne connaît pas le texte en clair oü le flux de codons utilisé pour chiffrer le texte en clair. Texte en clair original: Flux de codons original: Texte chiffré original:
mi
m2
h Cl
fe2 Cl
m3 k3 c3
m4 c4
Martin insère un seul bit connu, m ', dans le texte en clair après m,\ et s’arrange pour faire chiffrer ce nouveau texte en clair avec le même flux de codons. Il enregistre le
Chapitre 9
216
Types et modes d’algorithmes
texte chiffré résultant : Nouveau texte en clair: Flux de codons original: Texte chiffré mis à jour :
mi
m'
ki
k2
Cl
C2
m2 k3
m3
c3
C4
7714 k§
4
En faisant l’hypothèse qu’il connaît la valeur de m ', il peut déterminer tout le texte en clair après ce bit à partir du texte chiffré original et du nouveau texte chiffré : k2 — c 2 © m 'i et donc rri2 = c2 © k2 k3 = c 3 © rri2 , et donc m 3 = c 3 © A'3
fc3 = C4 © m.3 , et donc
7714
= c4 ©
Martin n’a même pas à connaître la position dans laquelle le bit a été inséré ; il doit juste comparer le texte chiffré avec le texte chiffré mis à jour et déterminer à partir de quel endroit ils diffèrent. Pour se protéger contre cette attaque, il ne faut jamais utiliser le même flux de codons pour chiffrer deux messages différents.
9.8
Mode de rétroaction de sortie
Le mode de ré tr o a c tio n d e so rtie (O F B pour « Output-feedback ») est une méthode qui consiste à utiliser un algorithme de chiffrement par blocs comme un algorithme de chiffrement synchrone en continu. Il est similaire au mode C FB , sauf que n bits du bloc de sortie précédent sont mis dans les positions les plus à droite de la file d ’attente (voir la figure 9.11). Le déchiffrement est l’inverse de ce processus. Cela s’appelle l’OFB à n bit. Des deux côtés, chiffrement et déchiffrement, l’algorithme de chiffrement par blocs est utilisé dans son mode de chiffrement. Cette méthode est parfois appelée ré tro a ctio n interne, parce que le mécanisme de rétroaction est indépendant à la fois des flots de texte en clair et de texte chiffré [295]. Si n est la taille du bloc d’un algorithme, alors un O FB à n bits ressemble à ceci (voir la figure 9.12) : Ct — A L © St
; St = EK(St- i )
M , = Cr © St
; Sx — Ej((St- i ) .
Si est l’état, qui est indépendant soit du texte en clair soit du texte chiffré. Une caractéristique intéressante du mode O F B est qu’ une grosse partiedu travail peut être effectuée séparément, avant mêmeque le message en clair n’existe.Puis,quand le message arrive, il peut être combiné par ou exclusif avec le produit de l’algorithme pour produire le texte chiffré.
Vecteur d’initialisation Le registre à décalage de l’O F B doit aussi être chargé initialement avec un IV. Il devrait être unique mais n’a pas besoin d ’être secret.
9.8
Mode de rétroaction de sortie
F i g . 9.11
217
- Mode de rétroaction de sortie à 8 bits
Propagation d’erreurs Le mode O F B n’a pas d ’amplification d’erreur. Une erreur d ’un seul bit dans le texte chiffré occasionne une erreur d’un seul bit dans le texte en clair récupéré. Cela peut être utile dans certaines transmissions analogiques numérisées, comme la voix ou la vidéo numérisée, où une erreur occasionnelle d’un bit peut être tolérée mais pas l’am plification d’erreur. D ’autre part, la perte de synchronisation est fatale. Si les contenus des registres à déca lage de chiffrement d’une part et de déchiffrement d’autre part ne sont pas identiques, alors le texte en clair récupéré sera du charabia. Tout système qui utilise le mode OFB doit avoir un mécanisme de détection de perte de synchronisation, et un mécanisme
F i g . 9 .1 2
- OFB à n bits avec un algorithme à n bits
Chapitre 9
218
Types et modes d’algorithmes
pour remplir les deux registres à décalage avec un nouveau (ou le même) IV pour resynchroniser.
Problèmes de sécurité avec le mode OFB Une analyse du mode O FB [590, 430, 431, 790] démontre que le mode O F B ne peut être utilisé que si la taille de la rétroaction est égale à la taille des blocs. Par exemple, vous ne pouvez utiliser qu’un algorithme à 64 bits avec un O FB à 64 bits. Bien que le Gouvernement américain autorise d ’autres tailles de rétroaction pour le DES [1156], évitez-les. Le mode O F B combine par ou exclusif un flot de clefs avec le texte. Ce flot de clefs se répétera. Il est important qu’il ne se répète pas avec la même clef, sinon, il n’y a pas de sécurité. Quand la taille de la rétroaction égale celle du bloc, l’algorithme de chiffrement par blocs agit comme une permutation des valeurs de m bit (où m est la longueur de bloc) et la longueur moyenne de cycle est 2m — 1. Pour un bloc de 64 bits, sa longueur est énorme. Quand la taille n de la rétroaction est inférieure à celle du bloc, la longueur moyenne de cycle tombe à environ 2 " /2. Pour un bloc de 64 bits, ça ne représente que 2 32, ce n’est pas assez long.
Algorithmes de chiffrement en continu avec le mode OFB Un algorithme de chiffrement en continu peut aussi fonctionner en mode OFB. Dans ce cas, la clef affecte la fonction de l’état suivant (voir la figure 9.13). La fonction résultante ne dépend pas de la clef ; très souvent c ’est quelque chose de simple, comme un seul bit de l’état interne ou la combinaison par ou exclusif de multiples bits de l’état interne. La complexité cryptographique se trouve dans la fonction de l’état suivant ; cette fonction est dépendante de la clef. Cette méthode est aussi appelée rétroaction interne [295], car le mécanisme de rétroaction est interne à l’algorithme de génération de clef.
F i g . 9 .1 3
Un générateur de codons en mode de rétroaction de sortie
Dans une variante de ce mode, la clef détermine juste l’état initial du générateur de
9.9
Mode « compteur »
219
codons. Une fois que la clef aura réglé l’état interne du générateur, celui-ci marchera sans problème.
9.9
Mode « compteur »
Les algorithmes de chiffrements par blocs en mode compteur utilise des suites de nombres en entrée de l’algorithme [826, 496, 718]. Au lieu d ’utiliser la sortie du chiffre ment pour remplir le registre à décalage, l’entrée du registre est un compteur. Après chiffrement d ’un bloc, le compteur est augmenté d’une certaine valeur, typiquement un. Les propriétés de synchronisation et de propagation d ’erreurs sont les mêmes que pour le mode O FB . Le mode compteur résoud le problème de sortie de n bit du mode OFB où n est plus petit que la longueur de bloc. Rien à propos du compteur n’est sacré ; il ne doit pas compter toutes les entrées pos sibles dans l’ordre. Vous pouvez utiliser tous les générateurs de suites aléatoires des chapitres 16 et 17, qu’ils soient cryptographiquement sûrs ou pas, en entrée de l’algo rithme de blocs.
Algorithmes de chiffrement en continu en mode compteur Les algorithmes de chiffrement en continu en mode « compteur » ont des fonctions d’état-suivant simples et des fonctions de sortie compliquées qui dépendent de la clef. Cette technique, illustrée dans la figure 9.14 a été suggérée dans [496, 718]. La fonction d’état-suivant peut être aussi simple qu’un compteur qui rajoute une unité à l’état précédent.
F i g . 9.14
- Un générateur de codons en mode « compteur »
Dans un chiffrement en continu en mode compteur, il est possible d’engendrer le ie bit de la clef k, sans avoir à engendrer d’abord tous les bits précédents. Il suffit de mettre le compteur manuellement à la valeur du ie état et d ’engendrer le bit. C ’est utile pour protéger des fichiers de données à accès aléatoire: vous pouvez déchiffrer un bloc de données spécifique sans déchiffrer tout le fichier.
Chapitre 9
220
9.10
Types et modes d’algorithmes
Autres modes
Mode de chaînage de blocs Pour utiliser un algorithme de chiffrement par blocs en mode de chaînage de b locs (B C pour « block chaining »), il suffit de combiner par ou exclusif l’entrée du chiffre ment par bloc avec le ou exclusif de tous les blocs de texte chiffré précédents. Tous comme pour le mode C B C , un IV démarre le processus. Mathématiquement cela ressemble à : Ci = EK (M i ® Ft)
;
Fi+i = Fz © C%
M Z= FZ® D k (Cz)
;
Fl+1 = Ft ® Ci.
Tout comme pour le mode C B C , le processus de rétroaction du mode B C amplifie les erreurs dans le texte en clair. Le défaut principal du mode B C vient du fait que le déchiffrement d’un bloc chiffré dépend de tous les blocs chiffrés précédents, une seule erreur dans le texte chiffré fausse le déchiffrement de tous les blocs chiffrés suivants.
Mode de chiffrement par chaînage de blocs avec propagation Le mode dech iffrem en t par chaînage d e b lo c s avec p rop a g a tion (P C B C pour « Propagating cipher block chaining ») [1084] est similaire au mode C B C , excepté que le bloc de texte chiffré précédent et le bloc de texte en clair précédent sont tous deux combinés par ou exclusif avec le bloc de texte en clair courant avant chiffrement (ou après déchiffrement) (voir la figure 9.15). C%= E K ( M t ffi Ct- i © M ,- i ) ■Adj =
© M t- i © D k (Cz)
Le mode P C B C est utilisé dans K e r b e r o s v e r s i o n 4 (voir § 24.5) pour effectuer à la fois le chiffrement et le contrôle d ’intégrité en une passe. En mode P C B C , une erreur dans le texte chiffré occasionne un déchiffrement incorrect de tous les blocs qui suivent. Cela signifie que vérifier un bloc standard à la fin du message permet de s’assurer de l’intégrité de tout le message. Malheureusement, il y a un défaut à ce mode [876]. Echanger deux blocs de texte chiffré occasionne un déchiffrement incorrect des deux blocs de texte en clair correspondants, mais à cause de la nature de l’opération de ou exclusif avec le texte en clair et le texte chiffré, ces erreurs se compensent et s’annulent. Donc un système de vérification d ’intégrité qui ne regarde que les quelques derniers blocs de texte déchiffrés, peut être amené à accepter un message partiellement embrouillé. Bien que personne n ’ait trouvé comment exploiter ce défaut, K e r b e r o s VERSION 5, est passé au mode C B C une fois que le défaut a été découvert.
Mode de chiffrement par chaînage de blocs avec sommes de contrôle Le ch iffrem en t par chaînage d e b lo c s avec som m es d e co n trô le (C B C C pour « Cipher block chaining with checksum ») est une variante du mode C B C [1620]. Gardez
9.10
Autres modes
221
F ig. 9.15 —Mode de chiffrement par chaînage de blocs avec propagation
une combinaison par ou exclusif de tous les blocs de texte en clair, et combinez-la par ou exclusif avec le dernier bloc de texte en clair avant chiffrement. Le mode C B C C s’assure que tout changement effectué à un quelconque des blocs chiffrés change le résultat déchiffré du dernier bloc. Si le dernier bloc contient un type de contrôle d ’intégrité ou une constante, alors l’intégrité du texte en clair déchiffré peut être vérifiée avec peu de frais supplémentaires.
Rétroaction de la sortie avec une fonction nonlinéaire La ré tr o a c tio n d e la sortie avec un e fo n ctio n n on lin éaire (O F B N L F pour « Output feedback mode with a nonlinear function ») [777] est une variante des deux modes O F B et E C B où la clef change avec chaque bloc: Ci = EKl{ M t)
;
K i = EK {Ki- 1)
M i = D Kt(Ci)
;
K i ~ E K ( K i ^ i)
Une erreur d’un seul bit dans le texte chiffré ne se répercute que dans un seul bloc en clair. Néanmoins, si un seul bit est perdu ou ajouté, alors il y a une propagation infinie d’erreurs. Avec un algorithme de chiffrement par blocs qui a un algorithme compliqué de gestion de clef, comme le DES, ce mode est lent. Je ne connais pas de cryptanalyse de ce mode.
Encore d’autres modes D’autres modes sont possibles, bien qu’ils ne soient pas couramment utilisés. Le mode de chaînage d e te x te en cla ir (P B C pour « plaintext block chaining ») est comme le mode C B C sauf que le texte en clair précédent est combiné par ou exclusif avec le
222
Chapitre 9
Types et modes d’algorithmes
bloc de texte en clair au lieu du texte chiffré. Le mode de chiffrem ent à rétroaction du te x te en clair (P F B pour « plaintext feedback ») est comme le mode C FB , sauf que c ’est le texte en clair, et non pas le texte chiffré, qui est utilisé pour la rétroaction. Ces deux modes permettent les attaques à texte en clair choisi afin de résister aux attaques à texte en clair connu. Il y a aussi le mode de chiffrem ent p a r b lo cs avec chaînage des différen ces en tre b lo c s d e te x te en clair (C B C P D pour « cipher block chaining of plaintext différence »). Je suis persuadé que c ’est encore plus étrange. Si un cryptanalyste a une machine de recherche exaustive de clefs, alors il peut re trouver la clef s’il peut deviner un des blocs de texte en clair. Certains de ces modes étranges reviennent à un chiffrement léger avant d ’appliquer l’algorithme de chiffre ment : par exemple, combiner le texte par ou exclusif avec une chaîne de caractères secrète ou le permuter. A peu près n’importe quoi d’inhabituel permet d ’éviter ce type de cryptanalyse.
9.11
Choix d’un mode opératoire de chif frement
Si la simplicité et la vitesse sont vos critères principaux, le mode ECB est le plus facile et le plus rapide à utiliser pour un algorithme de chiffrement par blocs. C ’est aussi le plus faible. Non seulement un algorithme est vulnérable à l’attaque des blocs rejoués, mais en mode EC B , il est plus facile à cryptanalyser. Je ne recommande donc pas le mode ECB pour le chiffrement des messages. Pour le chiffrement de données aléatoires, telles que d ’autres clefs, l’ECB est un bon mode à utiliser. Comme les données sont courtes et aléatoires, aucun des points faibles du mode E C B n ’ont d ’importance pour cette application. Pour du texte en clair normal, utilisez plutôt les modes C B C , C FB , ou O FB . Celui que vous choisirez dépendra de vos exigences spécifiques. Les deux tableaux 9.1 et 9.2 résument la sécurité et l’efficacité des différents modes. Le mode C B C convient en général pour chiffrer des fichiers. L ’augmentation du niveau de sécurité est significative ; et bien qu’il puisse y avoir des erreurs de bit dans les don nées stockées, il n ’y a presque jamais d ’erreurs de synchronisation. Si votre application est une réalisation logicielle, le mode C B C est presque toujours le meilleur choix. Le mode C FB — plus spécifiquement le mode C F B à 8 bits — est généralement le mode de choix pour chiffrer des flots de caractères quand chaque caractère doit être traité individuellement, comme c ’est le cas pour le lien entre un terminal et un ordinateur central. Le mode O FB est généralement utilisé pour les systèmes synchrones à grande vitesse où la propagation d’erreurs est inacceptable. Le mode O FB est aussi le mode de choix quand du pré-traitement est requis. Le mode O F B est le mode de choix dans un environnement où il y a beaucoup d ’erreurs, car il ne les propage pas. Restez à l’écart des modes étranges. L ’un des quatre modes de base — E C B , CBC, OFB et C F B est adéquat pour presque n’importe quelle application. Ces modes ne sont pas exagérément complexes et probablement ne diminuent pas le niveau de sécurité du système. Bien qu’il soit possible qu’un mode compliqué puisse augmenter le niveau de sécurité d ’un système, il est plus probable qu’il n’augmente que sa complexité.
9.12
Intercalation
T a b . 9.1 - R é s u m é
223
d e s m o d e s d e c h if f r e m e n t s p a r b l o c s
ECB Sécurité
C BC Sécurité
— Les motifs des textes en clair ne sont pas dissimulés. — L ’entrée de l’algorithme de chiffrement par bloc n’est pas aléatoire ; c ’est comme le texte en clair. + Plus d ’un seul message peut être chiffré avec la même clef. — Le texte en clair est facile à manipuler ; des blocs peuvent être retirés, répétés ou interchangés.
+ Les motifs des textes en clair sont dissimulés en combinant par o u e x c l u s i f avec le bloc chiffré précédent. + L’entrée de l’algorithme de chiffrement par bloc est aléatoire en combinant par o u e x c l u s i f avec le bloc chiffré précédent. + Plus d ’un seul message peut être chiffré avec la même clef. + / — Le texte en clair est quelque peu difficile à manipuler; des blocs peuvent être retirés du début et de la fin du message, des bits du premier bloc peuvent être changés, et la répétition permet des changements contrôlés.
Efficacité + La vitesse est la même que celle de l’algorithme de chiffrement par blocs. — Le texte chiffré est jusqu’à un bloc plus long que le texte en clair, du fait du remplissage. — Pas de pré-traitement possible. + Le traitement est parallélisable.
Tolérance aux fautes — Une erreur dans le texte chiffré affecte tout un bloc du texte en clair. — Une erreur de synchronisation est irrécupérable.
Efficacité + La vitesse est la même que celle de l’algorithme de chiffrement par blocs. — Le texte chiffré est jusqu’à un bloc plus long que le texte en clair, sans compter l’IV. — Pas de pré-traitement possible. + / — Le traitement n’est pas dérivable; le déchiffrement est parallélisable et supporte l’accès aléatoire.
Tolérance aux fautes — Une erreur dans le texte chiffré affecte tout un bloc du texte en clair et le bit correspondant du bloc suivant. — Une erreur de synchronisation est irrécupérable.
Aucun des modes étranges n’a de meilleures propriétés pour la propagation d’erreurs et pour les mécanismes de récupération d’erreurs.
9.12
Intercalation
Dans la plupart des modes, le chiffrement d’un bit (ou d’un bloc) dépend du chiffre ment du bit (ou du bloc) précédent. Cela rend souvent impossible la parallélisation du chiffrement. Prenez par exemple du matériel qui fait du chiffrement en mode CBC. Même si ce matériel contient quatre puces de chiffrement, une seule peut marcher à la fois. La puce suivante a besoin du résultat de la puce précédente pour commencer à
Chapitre 9
224
T a b . 9.2 - R é s u m é
Types et modes d’algorithmes
d e s m o d e s d e c h if f r e m e n t s p a r b l o c s
CFB Sécurité
ÔFB/Compteur Sécurité
+ Les motifs des textes en clair sont dissimulés. + L’entrée de l’algorithme de chiffrement par bloc est aléatoire. + Plus d ’un seul message peut être chiffré avec la même clef pourvu qu’un IV différent soit utilisé. + / — Le texte en clair est quelque peu difficile à manipuler; des blocs peuvent être retirés du début et de la fin du message, des bits du premier bloc peuvent être changés, et la répétition permet des changements contrôlés.
+ Les motifs des textes en clair sont dissimulés. + L ’entrée de l’algorithme de chiffrement par bloc est aléatoire. + Plus d’un seul message peut être chiffré avec la même clef pourvu qu’un IV différent soit utilisé. — Le texte en clair est très facile à manipuler ; tout changement dans le texte chiffré affecte directement le texte en clair.
Efficacité + La vitesse est la même que celle de l’algorithme de chiffrement par blocs. — Le texte chiffré est de la même taille que le texte en clair, sans compter l’IV. + / — Le chiffrement n ’est pas paralléli sable; le déchiffrement est dérivable et supporte l’accès aléatoire. — Du pré-traitement est possible avant l’apparition d ’un b loc; le bloc de texte chiffré précédent peut être chiffré.
Tolérance aux fautes — Une erreur dans le texte chiffré affecte le bit correspondant du texte en clair et le bloc suivant. -I- Des erreurs de synchronisation de la taille d ’un bloc sont récupérables. Le mode C F B à 1 bit peut récupérer après le rajout ou la perte de bits.
Efficacité + La vitesse est la même que celle de l’algorithme de chiffrement par blocs. — Le texte chiffré est de la même taille que le texte en clair, sans compter l’IV. — Du pré-traitement est possible avant l’apparition du message. + / — Le traitement OFB n’est pas pa rallélisable ; le traitement compteur est parallélisable.
Tolérance aux fautes — Une erreur dans le texte chiffré affecte seulement le bit correspondant du texte en clair. + Une erreur de synchronisation est irrécupérable.
travailler. La solution est d ’in terca ler les multiples flots de chiffrement. (Ce n’est pas un chiffre ment multiple, ceci sera abordé dans les paragraphes 15.1 et 15.2). Au lieu d ’utiliser une seule chaîne en mode C B C , utilisez-en quatre. Les premier, cinquième et un bloc sur quatre par la suite sont chiffrés en modes C B C avec un IV. Les second, sixième et un bloc sur quatre par la suite sont chiffrés en modes C B C avec un autre IV , et ainsi de suite. LTV total est plus long qu’il l’aurait été sans intercalaires. C’est comme si vous chiffriez quatre messages différents avec la même clef et quatre différents IV. Ces messages sont tous intercalés.
9.13
Chiffrement par blocs vs chiffrement en continu
225
Cette astuce peut aussi être utilisée pour augmenter la vitesse de matériels de chiffre ment. Si vous avez trois puces de chiffrement, chacune capable de chiffrer des données à 33 mégabits/seconde, vous pouvez les intercaler pour chiffrer un seul canal de données à 100 mégabits/seconde. La figure 9.16 montre trois flots parallèles intercalés en mode C FB . L ’idée peut aussi marcher en modes C B C et O FB , et avec autant de flots parallèles que désiré. Souvenezvous juste que chaque flot a besoin de son propre IV. Il ne doit pas être partagé.
F ig. 9.16
9.13
Mode de chiffrement par chaînage de blocs avec propagation
Chiffrement par blocs vs chiffrement en continu
Bien que les systèmes de chiffrement par blocs et les systèmes de chiffrement en continu soient très différents, des systèmes de chiffrement par blocs peuvent être utilisés en tant que systèmes de chiffrement en continu et des systèmes de chiffrement en continu peuvent être utilisés en tant que systèmes de chiffrement par blocs. La meilleure défi nition de la différence que j ’ai trouvée est celle de Ranier R u e p p e l [1364] : « Les systèmes de chiffrement par blocs agissent sur des données avec une transformation fixe des grands blocs de données en clair; les systèmes de chiffrement en continu agissent avec une transformation variant avec le temps des chiffres en clair individuels. » Dans le monde réel, les systèmes de chiffrement par blocs sont plus généraux (ils peuvent être utilisés dans n’importe lequel des quatres modes) et les systèmes de chif frement en continu sont plus faciles à analyser mathématiquement. Il y a beaucoup de travail théorique effectué sur l’analyse et la conception des systèmes de. chiffrement en continu ; la plupart de ces travaux sont effectués en Europe, je ne sais pour quelle raison. Ils ont été utilisés par les militaires du monde entier depuis l’invention de l’élec tronique. Cela semble changer dorénavant ; récemment, une grande quantité d’articles théoriques sur les systèmes de chiffrement par blocs ont été publiés. Il y aura peut-être que bientôt une théorie sur le modèle des systèmes de chiffrement par blocs aussi riche que la théorie sur la conception des systèmes de chiffrement en continu.
226
Chapitre 9
Types et modes d’algorithmes
Ceci mis à part, les différences entre ces deux systèmes se trouvent dans les réalisations. Les systèmes de chiffrement en continu qui ne chiffrent et ne déchiffrent qu’un bit à la fois ne sont pas vraiment adaptés à des réalisations logicielles. Les systèmes de chiffrement par blocs sont nettement plus faciles à réaliser en logiciel, car ils évitent les manipulations de bits qui sont coûteuses en temps de calcul et ils opèrent sur des données dans des blocs de taille raisonnable. D ’un autre côté, les systèmes de chiffrement en continu sont mieux adaptés à des réalisations matérielles car ils peuvent être réalisés de façon très efficace dans du silicone. Ce sont des considérations importantes. Il semble logique pour un appareil de chiffre ment d’un canal digital de communications de chiffrer chaque bit quand il arrive. C ’est ce que l’appareil voit. D ’un autre côté, il semble illogique pour un logiciel de chiffre ment de chiffrer chaque bit séparément. Il y a des exemples précis où le chiffrement de chaque bit et de chaque octet est nécessaire dans un système informatique — chiffrer le lien entre le clavier et le microprocesseur, par exemple — mais généralement le bloc de chiffrement devrait au moins être de la largeur du bus de données.
Chapitre 10
Utilisation des algorithmes Considérez la sécurité (sécurité des données, sécurité des communications, sécurité de l’information,...) comme une chaîne. La sécurité du système entier n’est pas plus forte que le plus faible des maillons. Tout doit être sûr: les algorithmes cryptographiques, les protocoles, la gestion des clefs, et bien plus. Si vos algorithmes sont sophistiqués mais que votre générateur de nombre aléatoire est mauvais, un cryptanalyste judicieux attaquera votre système par la génération des nombres aléatoires. Si vous comblez cette lacune mais oubliez de bien effacer la partie de la mémoire qui contient la clef, un cryptanalyste cassera votre système par cette voie. Si vous faites tout correctement mais accidentellement envoyez un courrier électronique de la copie de vos dossiers sûrs au Wall Street Journal, autant que vous ne fassiez rien du tout. Ce n’est pas juste. En tant que concepteur de système sûr, vous devez vous proté ger contre tous les moyens possibles d’attaque, alors qu’il suffit à un cryptanalyste d’exploiter la moindre faille dans votre système de sécurité ! La cryptographie n’est qu’une partie de la sécurité, et souvent une très petite partie. C ’est la partie mathématique pour rendre un système sûr, ce qui est différent d ’effec tivement rendre un système sûr. La cryptographie a ses « grands pontes » : des gens qui passent tant de temps à discuter à propos de la longueur idéale de clef qu’ils en oublient tout le reste. Si la police secrète veut savoir ce qu’il y a dans votre ordinateur, il leur est plus facile de pénétrer chez vous et d’installer une caméra qui enregistre tout ce qui apparaît sur votre écran que de cryptanalyser votre disque dur. De plus, la vue traditionnelle de la cryptographie comme étant une technologie « es pion contre espion » devient de moins en moins appropriée. Plus de 99 pourcents de la cryptographie utilisée dans le monde ne protège pas de secrets militaires ; c’est dans des applications telles que les cartes bancaires, les cartes de chaînes de télévision payantes, les péages autoroutiers, les cartes d’accès aux immeubles et aux ordinateurs, les termi naux de loterie et les pré-paiements de compteurs électriques [44, 45] qu’elle se trouve. Dans ces applications, le rôle de la cryptographie est de rendre la petite criminalité un peu plus difficile ; l’exemple de l’adversaire bien financé avec toute une armée de cryptanalystes dans une pièce remplie d ’ordinateurs ne s’applique pas ici. La plupart de ces applications ont utilisé de la cryptographie bas de gamme, mais les attaques victorieuses menées contre elles n’ont rien à voir avec la cryptanalyse. Elles im pliquaient des employés véreux, des opérations judicieuses de piratage, des réalisations
228
Chapitre 10
Utilisation des algorithmes
stupides, des ratés d ’intégration et des idioties aléatoires. (Je recommande fortement le papier de Ross A n d e r s o n « Pourquoi les cryptosystèmes ont échoué » [45] ; il de vrait être lu par toute personne évoluant dans ce domaine.) Même si la N SA a admis que la plupart des échecs de sécurité dans sa zone d ’intérêt sont dus à des échecs de réalisations, et non pas à des échecs au niveau des algorithmes et des protocoles [1125]. Dans ces exemples, peu importe si la cryptographie était bonne ou pas ; les attaques victorieuses l’ont complètement surpassée.
10.1
Choix d’un algorithme
Quand on en arrive à jauger et à choisir les algorithmes, les gens ont plusieurs choix : - Ils peuvent utiliser un algorithme publié, croyant que les algorithmes publiés ont été décortiqués par de nombreux cryptographes ; si personne ne l’a encore cassé, alors il doit être très bon. - Ils peuvent faire confiance à un fabricant, croyant qu’un fabricant connu a une réputation à défendre et qu’il ne risquera pas cette réputation en vendant des équipements ou des programmes avec des algorithmes de mauvaise qualité. - Ils peuvent faire confiance à un consultant indépendant, croyant qu’un consul tant impartial est mieux équipé pour faire une évaluation fiable des différents algorithmes. - Ils peuvent faire confiance au Gouvernement, croyant que le Gouvernement est digne de confiance et qu’il ne tromperait pas ses citoyens. - Ils peuvent écrire leur propre algorithme, croyant que leurs compétences en cryp tographie n’ont pas leur pareil et qu’ils ne doivent avoir confiance en personne d’autre qu’eux-même. Chacune de ces croyances est problématique, mais la première semble être la plus sensée. Placer votre confiance dans un seul fabricant, consultant ou gouvernement revient à chercher des ennuis. La plupart des gens qui portent l’étiquette « consultant en sécurité » (même des firmes célèbres) ne connaissent en général rien au chiffrement. La plupart des fabricants en sécurité ne sont pas fiables. Les meilleurs cryptographes au monde travaillent pour la NSA, mais ils ne disent pas tout ce qu’ils savent. Les intérêts qu’ils poursuivent ne sont pas conformes à ceux des citoyens. Et même si vous êtes un génie, écrire votre propre algorithme et ensuite l’utiliser sans l’avoir soumis à l’examen critique des pairs est de l’inconscience pure. Les algorithmes de ce livre sont publiques. La plupart ont été divulgués dans la littéra ture publique et ont été cryptanalysés par des experts dans le domaine. Je mentionne tous les résultats publiés, positifs et négatifs. Je n’ai pas accès aux cryptanalysés en treprises par la myriade d ’organisations de sécurité militaire de par le monde (qui sont probablement meilleures que les institutions académiques — elles le font depuis plus longtemps et elles sont mieux financées), donc il est possible que ces algorithmes soient plus faciles à casser qu’ils ne le paraissent. Même ainsi, il est bien plus probable qu’ils soient plus sûrs qu’un algorithme conçu et réalisé en secret par une société spécialisée en sécurité.
10.1
Choix d’un algorithme
229
Le point faible de ce raisonnement est que nous ne connaissons pas les capacités des nombreuses organisations militaires de cryptanalyse. Quels algorithmes la NSA peut-elle casser? Pour la majorité d’entre nous, il est impos sible de le dire. Si vous êtes arrêté en possession d’un ordinateur chiffré avec DES, il est peu probable que le FB I produise le contenu déchiffré comme pièce à conviction ; le fait qu’ils peuvent casser l’algorithme est souvent un secret bien plus important que les informations qui sont alors déchiffrées. Pendant la deuxième guerre mondiale, il était interdit aux Alliés d ’utiliser une information déchiffrée du trafic Ultra des Allemands, à moins qu’ils aient pu plausiblement obtenir l’information autrement. La seule façon de pousser la NSA à reconnaître sa capacité à casser un algorithme donné est de chiffrer une information tellement importante qu’ils ne pourront pas faire autrement que de la divulguer publiquement. Ou, mieux encore, créez une blague très drôle et envoyez-la par courrier électronique chiffré à des correspondants ambigus dans des pays suspects. Les employés de la NSA sont aussi des hommes; je doute qu’il puisse garder une si bonne blague secrète. Une bonne hypothèse de travail est que la N SA peut lire chaque message qu’elle choisit, mais qu’elle ne peut pas lire tous les messages qu’elle choisit. La NSA est limitée par ses ressources et doit faire un choix dans ses cibles. Une autre bonne hypothèse est qu’elle préfère casser autre chose que des codes ; cette préférence est si forte qu’elle se résoudra à casser les codes seulement quand elle voudra préserver le secret qu’elle a lu le message. Dans tous les cas, la meilleure chose que la plupart d ’entre-nous peuvent faire est de choisir parmi des algorithmes publiques qui ont raisonnablement résisté à une obser vation publique et à des cryptanalysés.
Algorithmes pour l’exportation Pour exporter un algorithme hors des Etats-Unis, il faut l’autorisation du Gouver nement américain (plus exactement, de la N SA — voir § 25.1). Il est généralement admis que ces algorithmes autorisés à l’exportation peuvent être cassés par la NSA. Bien que personne n’ait admis cela pour la postérité, voici quelques indices de ce que la NSA est suspectée, en privé, de suggérer aux sociétés qui veulent exporter des produits cryptographiques : - Laissez passer un bit de la clef de temps à autre caché dans le texte chiffré ; - Ramenez la clef effective à quelque chose dans la gamme des 30 bits. Par exemple, tandis qu’un algorithme pourrait accepter une clef de 100 bits, la plupart de ces clefs peuvent être équivalentes ; Utilisez un IV fixé, ou chiffrez un en-tête fixé au début de chaque message chiffré. Cela facilite une attaque à texte en clair choisi ; engendrez quelques octets aléatoires, chiffrez-les avec la clef, et placez le texte en clair et le texte chiffré de ces octets aléatoires au début du message chiffré. Cela facilite également une attaque à texte en clair connu. La NSA reçoit une copie du code source, mais les détails de l’algorithme restent cachés pour les autres. Il est évident que personne ne fait de publicité quant à ces faiblesses,
Chapitre 10
230
Utilisation des algorithmes
mais faites attention si vous achetez un produit de chiffrement américain qui a été approuvé pour Pexport.
10.2
La cryptographie à clef publique vs la cryptographie à clef secrète
Cryptographie à clef publique ou cryptographie à clef secrète? Quelle est la meilleure? Cette question n’a aucun sens mais est l’objet d ’un débat depuis que la cryptographie à clef publique a été inventée. Ce débat suppose que les deux types de cryptographie peuvent être comparés d ’égal à égal. Ils ne le peuvent pas. N e e d h a m et S c h r o e d e r [1159] remarquent que le nombre de messages et leur lon gueur sont bien plus grands dans les algorithmes à clef publique que dans les algo rithmes à clef secrète. Leur conclusion montre que l’algorithme à clef secrète est plus efficace que l’algorithme à clef publique. Bien que cela soit vrai, cette analyse oublie le gain significatif en sécurité de la cryptographie à clef publique. Whitfield D if f ie écrit [490, 492] : « En envisageant la cryptographie à clef publique comme une nouvelle forme de cryptosystème plutôt qu’une nouvelle forme de gestion de clefs, je me prépare aux critiques tant du point de vue de la sécurité que de la perfor mance. Les opposants remarquèrent rapidement que le système R S A était 1000 fois plus lent que le DES et nécessitait des clefs presque 10 fois plus grandes. Bien qu’il fût clair dès le début que l’utilisation des systèmes à clefs publiques pouvait être limitée à l’échange des clefs pour la cryptogra phie conventionnelle (à clef secrète), il n’était pas immédiatement clair que cela fût nécessaire. Dans ce contexte, la proposition de construire des sys tèmes hybrides [879] fut saluée comme une invention en soi. »
La cryptographie à clef publique et la cryptographie à clef secrète sont deux choses différentes ; elles résolvent des problèmes de types différents. La cryptographie à clef secrète est meilleure pour chiffrer des données. Elle est infiniment, plus rapide et n’est pas prédisposée à des attaques à texte chiffré choisi. La cryptographie à clef publique peut faire des choses que la cryptographie à clef secrète ne permet pas ; elle est adaptée pour la gestion des clefs et une myriade de protocoles exposés dans la Partie I. D ’autres installations ont été exposées dans la Partie I : fonctions de hachage à sens unique, codes d’authentification de message , etc... Le tableau 10.1 énumère les diffé rents types d ’algorithmes et leurs propriétés [806].
10.3
Chiffrement des canaux de communi cation
C’est le problème classique d’Alice et de Bernard: Alice veut envoyer à Bernard un message sûr. Que fait-elle? Elle chiffre le message. En théorie, ce chiffrement peut être effectué dans n’importe quelle couche OSI (Interface de systèmes ouverts, « Open Systems Interface » en Anglais) du modèle
10.3
Chiffrement des canaux de communication
T
ab
. 1 0 .1 - C
lasses
Confidentialité Algorithmes Algorithmes Algorithmes Algorithmes
de chiffrement à clef secrète de chiffrement à clef publique de signature digitale d ’échange de clef
Fonctions de hachage à sens unique Codes d ’authentification de message
231
d ’a l g o r it h m e s
Authentification
Intégrité
Clef
Gestion
Oui Oui Non
Non Non Oui Optionnel Non Oui
Non Non Oui Non
Oui
Oui Non Non
Oui Oui
Oui Non Oui Non Non
de communication. (Voir le standard d’architecture de sécurité OSI pour plus d’infor mations [310].) En pratique, le chiffrement a lieu soit dans les basses couches (une et deux), soit dans les hautes couches. S’il s’effectue dans les basses couches, il est appelé chiffrement lien par lien; tout ce qui passe par un lien de données particulier est chiffré. Si le chiffrement s’effectue dans des couches plus élevées, il est appelé chif frement de bout en bout ; les données sont chiffrées de façon sélective et restent chiffrées jusqu’à ce qu’elles soient déchiffrées par le destinataire final désigné. Chaque approche a ses avantages et ses inconvénients.
Chiffrement lien par lien L’endroit le plus simple pour rajouter le chiffrement se trouve dans la couche physique (voir la figure 10.1). Cela est appelé chiffrement lien par lien. Les interfaces avec la couche physique sont généralement standardisées et il est facile de connecter un dispo sitif de chiffrement à cet endroit. Ces dispositifs chiffrent toutes les données qui passent par eux, incluant les données elles-mêmes, les informations de routage et les informa tions du protocole. Ils peuvent être utilisés sur tous les types de liens de communication numérique. Par ailleurs, tout dispositif de commutation ou de stockage intelligent sur le parcours entre l’émetteur et le récepteur doit déchiffrer le flux de données avant de le traiter. Ce type de chiffrement est très efficace. Comme tout est chiffré, un cryptanalyste ne peut obtenir aucune information sur la structure de l’information. Il n’a pas la moindre idée de qui parle à qui, de la longueur des messages envoyés, à quel moment de la journée ils communiquent, etc. On parle alors de sécurité du flot de trafic : non seulement l’ennemi n’a pas accès à l’information, mais il ignore aussi la destination et le volume de cette information. La sécurité ne dépend d’aucune technique de gestion du trafic. La gestion des clefs est
F
ig
.
10.1 - Chiffrement au niveau des liens
Chapitre 10
232
Utilisation des algorithmes
aussi simple : seules les deux extrémités d ’une ligne doivent partager une clef et elles peuvent changer leur clef indépendamment du reste du réseau. Imaginez-vous une ligne de communication synchrone, chiffrée en mode C FB à 1 bit. Après l’initialisation, cette ligne peut fonctionner indéfiniment, récupérant automati quement des erreurs de bit ou de synchronisation. La ligne chiffre dès que des messages sont envoyés à partir d ’une extrémité vers l’autre ; sinon, elle chiffre et déchiffre des données aléatoires. Estelle n’a aucune idée de la date des messages envoyés ou non; elle n’a pas d ’idée du début et de la fin des messages. Tout ce qu’elle voit est un flux continu de bits qui ont l’air aléatoires. Si la ligne de communication est asynchrone, le même mode C FB à 1 bit peut être utilisé. La différence est que l’adversaire peut obtenir de l’information sur le taux de la transmission. Si cette information doit rester secrète, prenez des précautions en envoyant des messages factices entre les communications utiles. Le plus gros défaut du chiffrement lien par lien est que chaque lien physique du réseau doit être chiffré : laisser un seul lien non chiffré compromet la sécurité de tout le réseau. Si le réseau est grand, le coût peut rapidement devenir prohibitif pour ce type de chiffrement. De plus, tous les nœuds du réseau doivent être protégés, car ils véhiculent des données non chiffrées. Si tous les utilisateurs du réseau se font confiance mutuellement et si tous les nœuds sont en lieu sûr, cela peut être acceptable. C ’est toutefois improbable. Même dans une société, l’information doit être gardée secrète au sein d’un département. Si le réseau se trompe de chemin pour acheminer une information, tout le monde peut la lire. Le tableau 10.2 résume les avantages et les inconvénients du chiffrement lien par lien.
Ta
b
.
10.2 - Chiffrement au niveau physique: avantages et inconvénients
Avantages Opération plus simple, puisqu’elle est transparente pour l’utilisateur. Tout est chiffré avant d ’être envoyé sur le lien. Un seul jeu de clefs par lien est nécessaire. Fournit une sécurité du flot de traffic, puisque chaque information de routage est chiffrée. Le chiffrement est en ligne. Inconvénients Les données sont vulnérables dans les nœuds intermédiaires.
Chiffrement de bout en bout Un autre approche consiste à mettre le dispositif de chiffrement entre la couche réseau et la couche de transport. Le dispositif de chiffrement doit pouvoir interpréter les données d ’après les protocoles jusqu’à la couche trois et chiffrer seulement les unités de données de transport qui sont alors recombinées avec les informations de routage non chiffrées et envoyées aux couches inférieures du protocole.
10.3
Chiffrement des canaux de communication
233
Cette approche évite le problème du chiffrement/déchiffrement au niveau de la couche physique. En utilisant le chiffrement de bout en bout, les données restent chiffrées jusqu’à ce qu’elles atteignent leur destination finale (voir la figure 10.2). Le défaut principal du chiffrement de bout en bout est que les informations de routage pour les données ne sont pas chiffrées; un bon cryptanalyste peut pas mal apprendre de qui parle à qui, à quel moment et pendant combien de temps, sans même connaître le contenu de ces conversations. La gestion des clefs est également plus difficile car les utilisateurs doivent s’assurer qu’ils ont bien des clefs communes.
F ig . 10.2 - Chiffrement de bout en bout
Construire un dispositif de chiffrement de bout en bout est difficile. Chaque système de communication particulier a ses propres protocoles. Parfois, les interfaces entre ces niveaux ne sont pas bien définies, rendant la tâche plus difficile encore. Si le chiffrement a lieu dans une couche haute de l’architecture de communication, comme les couches application et présentation, alors cela peut être indépendant du type de réseau de communication utilisé. C ’est toujours du chiffrement de bout en bout, mais la réalisation du chiffrement ne doit pas se préoccuper des codes de ligne, de la synchronisation entre les modems, des interfaces physiques, etc. Dans les temps hé roïques de la cryptographie électromécanique, le chiffrement et le déchiffrement avaient entièrement lieu hors ligne : cela ne fait qu’une étape de moins. Le chiffrement dans ces hautes couches interagit avec le logiciel de l’utilisateur. Le lo giciel est différent pour des architectures d’ordinateur différentes et donc le chiffrement doit être optimisé pour différents systèmes informatiques. Le chiffrement peut être réa lisé par le logiciel ou par du matériel dédié. Dans ce dernier cas, l’ordinateur enverra les données au matériel dédié pour les chiffrer, avant de les envoyer vers les couches inférieures de l’architecture de communication pour être transmises. Ce processus re quiert quelque intelligence et n’est pas adapté aux terminaux non intelligents. De plus, il peut y avoir des problèmes de compatibilité entre les différents types d’ordinateurs. Le plus gros inconvénient du chiffrement de bout en bout est qu’il permet l’analyse de trafic. C ’est l’analyse de messages chiffrés: d’où ils viennent, où ils vont, de quelle longueur ils sont, quand ils ont été envoyés, à quelle fréquence, s’ils coïncident avec des événements extérieurs tels que des rendez-vous, et bien plus. Beaucoup de bonnes informations sont enterrées dans ces données et un cryptanalyste voudra mettre les mains dessus. Le tableau 10.3 présente les aspects positifs et négatifs du chiffrement de bout en bout.
Combinaison des deux Le tableau 10.4, emprunté à [1254], compare les chiffrements lien par lien et de bout en bout. Combiner les deux, bien qu’étant très cher, est le moyen le plus efficace de
Chapitre 10
234
Utilisation des algorithmes
T a b . 10.3 - Chiffrement lien par lien : avantages et inconvénients
Avantages Niveau de secret plus élevé. Inconvénients Requiert un système de gestion des clefs plus complexe. L’analyse de trafic est possible, puisque l’information de routage n’est pas chiffrée. Le chiffrement est hors-ligne.
rendre sûr un réseau. Le chiffrement de tout lien physique rend toute analyse des informations de routage impossible, tandis que le chiffrement de bout en bout réduit le danger des données non chiffrées aux différents nœuds du réseau. Les gestions des clefs des deux schémas peuvent être complètement séparées : les gestionnaires de réseau peuvent s’occuper du chiffrement au niveau physique, tandis que les individus peuvent avoir la responsabilité du chiffrement de bout en bout.
Tab. 10.4 C
Comparaison des chiffrements lien par lien et de bout en bout
h if f r e m e n t l ie n
par
l ie n
C
h if f r e m e n t
de
bo u t en
bout
Sécurité dans les machines hôtes Message exposé chez l’hôte envoyeur. Message chiffré chez l’hôte envoyeur. Message exposé dans les nœuds intermé- Message chiffré dans les nœuds intermé diaires. diaires. Rôle de l’utilisateur Effectué par l’hôte envoyeur. Transparent pour l’utilisateur. L ’hôte maintient le chiffrement. Un service pour tous les utilisateurs. Peut être réalisé en matériel. Tous ou aucun messages chiffrés.
Effectué par le processus d’envoi. L’utilisateur effectue le chiffrement. L’utilisateur doit trouver l’algorithme. L’utilisateur sélectionne le chiffrement. Plus facilement effectué dans le logiciel. L’utilisateur choisit de chiffrer ou pas, pour chaque message.
Exigences de la réalisation Nécessite une clef par paire d’utilisa Nécessite une clef par paire d’hôtes. Nécessite un matériel ou un logiciel de teurs. Nécessite un matériel ou un logiciel de chiffrement à chaque hôte. chiffrement à chaque nœud. Effectue l’authentification des nœuds. Effectue l’authentification des utilisa teurs.
10. Jf
10.4
Chiffrement des données à des fins de stockage
2S5
Chiffrement des données à des fins de stockage
Chiffrer des données pour les stocker et les récupérer plus tard peut être utilisé dans le modèle d’Alice et de Bernard. Alice envoie toujours un message à Bernard, mais dans ce cas « Bernard » est Alice dans un temps futur. Néanmoins, le problème est fondamentalement différent. Dans les canaux de communication, les messages en transit n’ont pas de valeur intrin sèque. Si Bernard ne reçoit pas un message particulier, Alice peut toujours le renvoyer. Ceci n’est pas vrai pour le stockage des données chiffrées. Si Alice ne peut pas déchiffrer son propre message, elle ne peut pas remonter le temps et le rechiffrer. Elle l’a perdu à jamais. Ceci veut dire que les applications de chiffrement pour le stockage des données devraient avoir des mécanismes pour empêcher des erreurs irrécupérables de s’infiltrer dans le texte chiffré. La clef de chiffrement a la même valeur que le message, elle est seulement plus pe tite. En effet, la cryptographie convertit de gros secrets en petits. Etant plus petites, elles peuvent facilement être perdues. Les procédures de gestion des clefs devraient considérer que les mêmes clefs seront utilisées maintes fois et que les données pourront demeurer sur disque pendant des années avant d ’être déchiffrées. De plus, les clefs seront présentes pendant une longue période. Une clef utilisée pour une liaison téléphonique devrait, ce qui serait idéal, exister juste le temps de la commu nication. Une clef utilisée pour le stockage des données peut servir pendant des années et doit par conséquent être stockée de manière sûre pendant des années. D’autres problèmes spécifiques au chiffrement des données informatiques en vue de stockage sont énumérés dans [361] : - Les données peuvent aussi exister sous forme de texte en clair, soit sur un autre disque, dans un autre système informatique ou sur papier. Il y a plus d’occasions pour des cryptanalystes de monter une attaque à texte en clair connu. - Dans les applications de bases de données, des parcelles de données peuvent être plus petites que la taille de blocs de la plupart des algorithmes. Cela donnera un texte chiffré qui peut être largement plus grand que le texte en clair. - La vitesse des périphériques d’entrée et sortie nécessite une grande vitesse de chiffrement et de déchiffrement, et une réalisation matérielle du chiffrement sera probablement nécessaire. Pour certaines applications, des algorithmes à haute vitesse pourraient être nécessaires. - Un stockage sûr et de longue durée pour les clefs est nécessaire. - La gestion des clefs est nettement plus compliquée, car différentes personnes doivent accéder à différents fichiers, différentes portions d’un même fichier, etc. Si les fichiers chiffrés ne sont pas structurés en enregistrements et champs, comme dans les fichiers de texte, l’accès est facile : tout le fichier est déchiffré avant usage. Si les fichiers chiffrés sont des fichiers d’une base de données, la solution est problématique. Déchiffrer toute la base de données pour accéder à un seul enregistrement est inefficace,
2S6
Chapitre 10
Utilisation des algorithmes
mais chiffrer les enregistrements indépendamment peut être sujet à une attaque du type des blocs rejoués. De plus, vous devez être sûr que le fichier non chiffré est effacé après le chiffrement (voir § 10.9). Pour plus de détails et un autre aperçu, consultez [427, 571].
Déréférencer les clefs Quand vous chiffrez un disque dur volumineux, vous avez deux options. Vous pouvez chiffrer toutes les données en n’utilisant qu’une seule clef. Cela fournit au cryptana lyste une grande quantité de texte chiffré à analyser et rend impossible à de multiples utilisateurs de voir seulement des parties du disque. Ou, vous pouvez chiffrer chaque fichier avec une clef différente, forçant les utilisateurs à mémoriser une clef différente pour chaque fichier. La solution et de chiffrer chaque fichier avec une clef séparée et de chiffrer ces clefs avec une autre clef connue des utilisateurs. Chaque utilisateur ne doit se souvenir que de cette clef. Des utilisateurs différents peuvent avoir différents sous-ensembles des clefs de chiffrement de fichier chiffrés avec leur clef. Il peut même y avoir une clef maîtresse qui chiffre toutes les clefs de chiffrement de fichier. Ceci est même plus sûr car les clefs de chiffrement de fichier sont aléatoires et moins vulnérables à une attaque par dictionnaire.
Chiffrements au niveau du disque vs chiffrements au niveau des fichiers Il y a deux manières de chiffrer un disque dur : au niveau des fichiers et au niveau du disque. Le chiffrement au niveau des fichiers signifie que tous les fichiers sont chiffrés séparément. Pour utiliser un fichier qui a été chiffré, vous devez d ’abord le déchiffrer, puis l’utiliser et enfin le rechiffrer. Le chiffrement au niveau du disque garantit un disque logique dans l’ordinateur de l’utilisateur où toutes les données y sont chiffrées. Bien effectué, cela fournit une sécurité qui, au delà du choix d’un bon mot de passe, ne demande pas grand chose de la part de l’utilisateur. Néanmoins, le disque doit être beaucoup plus complexe qu’un simple programme de chiffrement de fichier, car il doit s’occuper d ’allouer de nouveaux secteurs à des fichiers, de recycler de vieux secteurs, de traiter des requêtes de lecture et de mise à jour des accès aléatoires pour toute donnée sur le disque, etc... En pratique, le disque demande un mot de passe à l’utilisateur avant de démarrer. Ceci génère une clef maîtresse de déchiffrement qui peut alors être utilisée pour déchiffrer les clefs de déchiffrement nécessaires pour les différentes données.
Fournir un accès aléatoire à un disque chiffré La plupart des systèmes devraient être capable d’accéder aux secteurs d’un disque de manière aléatoire. Ceci implique des complications quant à l’utilisation de nombreux algorithmes de chiffrement en continu et d’algorithmes de chiffrement par blocs dans tout mode de chaînage. Plusieurs solutions sont possibles. Utilisez l’adresse secteur pour générer un IV unique pour chaque secteur qui est chiffré ou déchiffré. Le défaut est que chaque secteur sera toujours chiffré avec le même IV. Assurez-vous que cela ne pose pas de problème de sécurité.
10.5
Chiffrement matériel vs chiffrement logiciel
231
Pour la clef maîtresse, générez un bloc pseudo-aléatoire aussi grand qu’un secteur. (Vous pouvez le faire en utilisant un algorithme en mode O F B par exemple.) Pour chiffrer tout secteur, combinez d ’abord par ou exclusif avec ce bloc pseudo-aléatoire, puis chiffrez normalement avec un algorithme de chiffrement par blocs en mode ECB. Cela s’appelle E C B + O F B (voir § 15.4). Comme C B C et C FB sont des modes de récupération d ’erreurs, vous pouvez utilisez tous les blocs du secteur sauf les premiers et seconds pour générer un IV pour ce secteur. Par exemple, l’IV du secteur 3 001 peut être le hachage de toutes les données du secteur, mis à part les premiers 128 bits. Après avoir généré l’IV , chiffrez normalement en mode C B C . Pour déchiffrer le secteur, vous utilisez les 64 bits du second bloc du secteur en tant qu’IV puis déchiffrez le reste du secteur. Ensuite, en utilisant les données déchiffrées, vous régénérez l’IV et déchiffrez les premiers 128 bits. Vous pouvez utiliser un algorithme de chiffrement par blocs avec une taille de bloc assez grande pour pouvoir chiffrer tout le secteur d’un coup. C R A B (voir § 14.6) en est un exemple.
10.5
Chiffrement matériel vs chiffrement logiciel
Chiffrement matériel Jusqu’à il y a peu, tous les équipements de chiffrement étaient des réalisations ma térielles dédiées. Ces boîtes de chiffrement/déchiffrement se branchaient sur les lignes de communications et chiffraient toutes les données passant sur la ligne. Bien que le chiffrement en logiciel prenne de l’importance aujourd’hui, le matériel est toujours le choix qui est fait par les militaires et les applications commerciales sérieuses. La NSA, par exemple, n’autorise que le chiffrement par le matériel. Il y a plusieurs raisons à cela. La première est la vitesse. Comme nous le verrons dans la troisième Partie, les algo rithmes de chiffrement consistent en de nombreuses opérations compliquées sur des bits de texte en clair. On ne trouve pas sous le sabot d’un cheval des ordinateurs qui com prennent ce genre d ’opérations en standard. Les deux algorithmes de chiffrement les plus courants, le DES et R SA , ne fonctionnent pas bien sur des processeurs généraux. Bien que certains cryptographes aient essayé de rendre les algorithmes plus facilement réalisables en logiciel, le matériel dédié gagnera toujours la course de vitesse. De plus, le chiffrement est souvent une tâche de calcul intensif. Mobiliser le processeur principal de l’ordinateur pour cela est inefficace. Confier le chiffrement à une autre puce, même si cette puce n’est qu’un autre processeur, rend tout le système plus rapide. La deuxième raison est la sécurité. Un algorithme de chiffrement fonctionnant sur un ordinateur commun n’a pas de protection physique. Martin peut utiliser différents outils de débogage et subrepticement modifier l’algorithme sans que qui que ce soit s’en rende compte. Les dispositifs de chiffrement matériels peuvent être bien encapsulés pour prévenir cela. Des boîtes à l’épreuve de l’investigation peuvent empêcher que quelqu’un modifie le dispositif de chiffrement matériel. Des puces VLSI dédiées peuvent être recouvertes d ’un film protecteur chimique spécial tel que toute tentative d’accéder à l’intérieur provoque la destruction des circuits logiques de l a puce. Les puces C l i p p e r
Chapitre 10
238
Utilisation des algorithmes
T ab. 10.5 - Chiffrements au niveau des fichiers vs au niveau du disque C
h if f r e m e n t a u
n iv e a u
d e s f ic h ie r s
C
h if f r e m e n t
au
n iv e a u
du
d is q u e
Bénéfices Facilité de réalisation et d’utilisation. Les fichiers temporaires, de travail, et Flexibilité. autres, peuvent être gardés dans le Baisse de performance très faible. disque sûr. Les utilisateurs peuvent transférer des fiIl est plus difficile d ’oublier de rechiffrer chiers entre différentes machines sans quelque chose avec ce genre de système, problèmes. Les utilisateurs peuvent sauvegarder des fichiers sans problèmes. Questions de sécurité Beaucoup de choses peuvent mal se pas ser avec un disque ou un programme résident en mémoire. De mauvaises conceptions permettront des attaques à texte en clair, voire à texte chiffré, choisi. Si tout le système est verrouillé avec un mot de passe, la perte de ce mot de passe fait que l’attaquant peut tout ob tenir. Un ensemble plus limité d ’algorithmes de chiffrement peut raisonnablement être utilisé pour ce genre d ’application. Par exemple, des algorithmes de chif frement en continu en mode O F B ne marcheraient pas. Problèmes d’ utilisation
Fuite possible par des programmes nonsécurisé (un programme peut écrire un fichier sur le disque pour un stockage temporaire, par exemple). Une mauvaise conception peut toujours rechiffrer la même clef pour le même mot de passe.
L’utilisateur doit savoir ce qu’il doit faire. II peut y avoir différents mots de passe pour différents fichiers. Le chiffrement manuel de fichiers sélectionnés est le seul contrôle d ’accès.
II y aura une baisse de performance. Le disque peut réagir de manière inattendu avec W i n d o w s , l’émulation OS2 DOS, des gestionnaires de disque, etc...
et C a p s t o n e du gouvernement américain (voir § 24.16 et § 24.17) sont conçues pour résister à toute investigation. Les puces peuvent être conçues pour qu’il soit impossible à Martin de lire la clef non chiffrée. IBM a développé un système cryptographique pour chiffrer les données et les commu nications sur les ordinateurs centraux [517, 1032]. Il comprend des modules spéciaux résistants à l’investigation pour contenir les clefs. Ce système est décrit dans le para
10.5
Chiffrement matériel vs chiffrement logiciel
239
graphe 24.1.
Le rayonnement électromagnétique peut parfois révéler ce qui se passe dans un équipe ment électronique. Des boîtes dédiées au chiffrement peuvent être blindées de manière à ne pas laisser s’échapper d’information. Les ordinateurs multi-usage traditionnels peuvent être blindés également, mais c’est nettement plus complexe à réaliser. Les mi litaires américains appellent ceci T E M P E S T ; c ’est un sujet qui dépasse largement le cadre de ce livre. La raison finale pour la prédominance des réalisations matérielles est la facilité d’ins tallation. La plupart des applications de chiffrement n’impliquent pas des ordinateurs classiques. Les gens peuvent vouloir chiffrer leur conversations téléphoniques, leurs en vois de fax, ou leurs liens de données. Il est moins cher de mettre du matériel dédié au chiffrement dans les téléphones, les fax, et les modems que de mettre le chiffrement dans un microprocesseur et un logiciel. Même quand les données chiffrées viennent d’un ordinateur, il est plus simple d’installer un périphérique de chiffrement que de modifier le logiciel système de l’ordinateur. Le chiffrement doit être invisible et ne doit pas gêner l’utilisateur. Le seul moyen de réaliser cela en logiciel est de réaliser le chiffrement dans les couches profondes du système de conduite. Ce n’est pas simple. De plus, même un néophyte de l’informatique peut brancher une boîte de chiffrement entre son ordinateur et son modem externe. Aujourd’hui, les trois types principaux de dispositifs matériels de chiffrement sur le marché sont : des modules de chiffrement autonomes (qui effectuent des fonctions telles que la vérification de mots de passe et la gestion des clefs pour les banques), des boîtes dédiées au chiffrement pour les liens de communications et les cartes que l’on enfiche dans les ordinateurs personnels. Certaines boîtes de chiffrement sont conçues pour des types spéciaux de liens de com munication, comme les boîtes de chiffrement pour liens T -1 qui sont conçues pour ne pas chiffrer les bits de synchronisation. Il existe différentes boîtes pour les lignes de communications synchrones et asynchrones. De nouvelles boîtes semblent accepter de plus grandes vitesses (en bits par seconde) et sont plus versatiles. Malgré cela, nombre de ces périphériques occasionnent des incompatibilités. Les ache teurs doivent en être avertis et doivent bien connaître leurs besoins particuliers, sinon ils se retrouvent propriétaires d ’un équipement de chiffrement qui n’arrive pas à effec tuer la tâche demandée. Faites attention aux restrictions quant au type de matériel, au système de conduite, aux programmes d ’application, au réseau, etc. Les cartes chiffreuses P C chiffrent en général tout ce qui est écrit sur le disque dur et peuvent également être configurées pour chiffrer tout ce qui est écrit sur des disquettes ou sur les ports séries. Ces cartes ne sont pas blindées contre les rayonnements électro magnétiques ou les interférences de signaux, puisque cela n’a pas de sens de protéger les cartes si l’ordinateur ne l’est pas. De plus en plus de sociétés commencent à mettre du matériel de chiffrement dans leurs équipements de communication. Des téléphones sûrs, des fax sûrs et des modems sûrs sont tous disponibles. La gestion interne des clefs de ces périphériques est en général sûre, bien qu’il existe autant de schémas que de vendeurs d’équipement. Certains schémas sont mieux adaptés à une situation qu’à une autre, et les acheteurs doivent savoir d’une part quel type de gestion des clefs est incorporé dans la boîte de chiffrement et d’autre part ce qu’ils doivent fournir par eux-mêmes.
Chapitre 10
240
Utilisation des algorithmes
Chiffrement logiciel Tout algorithme de chiffrement peut être réalisé en logiciel. Les désavantages sont la vitesse, le coût et la facilité de modification (ou de manipulation). Les avantages sont la flexibilité et la portabilité, la facilité d ’utilisation et la facilité de mise à jour. Les algorithmes écrits en C à la fin de cet ouvrage peuvent être réalisés, modulo des petites modifications, sur n’importe quel ordinateur. Ils peuvent être incorporés dans de plus grandes applications comme les programmes de communications ou les traitements de texte. Les logiciels de chiffrement sont populaires et disponibles pour tous les systèmes de conduites majeurs. Ils sont destinés à protéger des fichiers individuels : l’utilisateur doit généralement chiffrer et déchiffrer des fichiers spécifiques. Il est important que la gestion des clefs soit sûre : les clefs ne devraient pas être stockées sur le disque n’importe où (ou même écrites dans une zone mémoire qui peut être recopiée sur le disque par la gestion de mémoire virtuelle). Les clefs et les fichiers non chiffrés doivent être effacés après chiffrement. Nombre de programmes sont négligents à ce propos et l’utilisateur doit choisir prudemment. Bien sûr, Martin peut toujours remplacer le logiciel de chiffrement par autre chose. Mais pour la plupart des utilisateurs, ce n’est pas un problème. Si Martin peut s’introduire dans nos bureaux et modifier nos programmes de chiffrement, il peut aussi installer une caméra cachée dans le mur, mettre le téléphone sur écoute, et un détecteur T E M P E S T dans la rue. Si Martin est aussi puissant, l’utilisateur a alors perdu le jeu avant même qu’il n’ait commencé.
10.6
Compression, codage et chiffrement
Utiliser un algorithme de compression de données avec un algorithme de chiffrement est logique pour deux raisons : - La cryptanalyse s’appuie sur l’exploitation de redondances dans le texte en clair ; compresser un fichier avant de le chiffrer réduit ces redondances. - Le chiffrement prend du temps ; compresser un fichier avant de le chiffrer accélère le processus tout entier. La chose importante dont il faut se souvenir est de compresser avant de chiffrer. Si l’algorithme de chiffrement est bon, le texte chiffré ne sera pas compressible ; il ressem blera à des données aléatoires. (Ceci est un bon test d’un algorithme de chiffrement ; si le texte chiffré peut être compressé, alors l’algorithme n’est probablement pas très bon.) Si vous voulez ajouter tout type de codage de transmission ou de détection d’erreur et de récupération, n’oubliez pas de l’ajouter après le chiffrement. S’il y a du bruit dans la voie de communication, les propriétés d ’extension d ’erreur du déchiffrement ne feront qu’amplifier ce bruit. La figure 10.3 résume ces étapes.
10.7
Détection du chiffrement
F
10.7
ig
.
241
10.3 - Chiffrement avec compression et contrôle d’erreur
Détection du chiffrement
Comment Estelle peut-elle détecter un fichier chiffré? Elle est dans l’espionnage, alors c’est une question importante. Imaginez qu’elle espionne un réseau où les messages fusent de tous les côtés à des vitesses élevées ; elle doit sélectionner les plus intéressants. Les fichiers chiffrés sont certainement intéressants, mais comment peut-elle savoir qu’ils sont chiffrés? En général, elle s’appuie sur le fait que les programmes de chiffrement les plus popu laires ont des en-têtes bien définies. Les messages de courrier électronique chiffrés avec soit PE M soit P G P (voir § 24.10 et § 24.12) sont faciles à identifier pour cette raison. D’autres chiffreurs de fichier produisent juste un fichier de texte chiffré de bits appa remment aléatoires. Comment peut-elle le distinguer d’un autre fichier avec des bits apparemment aléatoires? Il n’y a pas de méthode infaillible, mais Estelle peut essayer un certain nombre de choses : - Examiner le fichier. Le texte A S C II est facilement décelable. D ’autres formats de dossier, tels que T IF F , TeX , C, P o s t c r i p t , facsimile G3 ou M i c r o s o f t E x c e l ont des caractéristiques standards identifiables. Un code exécutable est aussi détectable. Les fichiers U N IX ont souvent des « nombres magiques » qui peuvent être détectés. - Essayer de décompresser le fichier en utilisant les algorithmes de compression les plus connus. Si le fichier est compressé (et non chiffré), cela devrait donner le fichier original. - Essayer de compresser le fichier. Si le fichier est du texte chiffré (et que l’algo rithme est bon), alors la probabilité que le fichier puisse être compressé à un degré appréciable par une compression d ’usage général est faible. (Par « à un degré appréciable », j ’entends plus de 1 ou 2 pourcents.) Si c’est quelque chose d’autre (une image binaire ou un fichier de données binaires, par exemple) cela peut probablement être compressé. Tout fichier qui ne peut être compressé et qui ne l’est pas déjà est probablement du texte chiffré. (Bien entendu, il est toujours possible de faire un texte chiffré spécifique qui soit compressible.) Identifier l’algorithme est beaucoup plus dur. Si l’algorithme est bon, vous ne pourrez pas. S’il a quelques petites altérations, il peut être possible de reconnaître ces altérations dans le fichier. Néanmoins, les altérations devront être assez significatives ou le fichier assez gros afin que cela puisse marcher.
242 10.8
Chapitre 10
Utilisation des algorithmes
Cacher du texte chiffré dans du texte chiffré
Alice et Bernard se sont envoyés des messages chiffrés tout au long de l’année. Estelle les a tous récupérés, mais elle ne peut déchiffrer aucun d ’entre-eux. Finalement, la police secrète se lasse de tous ces textes chiffrés illisibles et arrête la paire. « Donnez-nous vos clefs de chiffrement », demandent-ils. Alice et Bernard refusent, puis ils aperçoivent un appareil de torture. Que peuvent-ils faire? Ne serait-il pas agréable de pouvoir chiffrer un fichier de manière à ce qu’il y ait deux déchiffrements possibles, chacun avec une clef différente? Alice pourrait chiffrer un vrai message vers Bernard avec l’une des clefs et un message banal avec l’autre. Si Alice se faisait arrêter, elle pourrait livrer la clef du message banal et garder la vrai clef secrète. La façon la plus simple de faire ceci est avec les masques jetables. Soit Ad le texte en clair, £ le texte en clair leurre, C le texte chiffré, K la vrai clef et K ' la clef leurre. Alice chiffre Ad : Ad © K = C Alice et Bernard partagent K , Bernard peut donc déchiffrer C : C@K = M
Si la police secrète les force à leur livrer leur clef, ils ne livrent pas K , mais à la place : K' = C© £
La police obtient alors le texte en clair leurre : C© K’ = £
Comme ce sont des masques jetables et que K est totalement aléatoire, il n ’y a pas de moyen de prouver que K ' n’était pas la bonne clef. Pour rendre les choses encore plus convaincantes, Alice et Bernard devraient concocter des messages leurres moyennement compromettants pour les substituer aux messages réels vraiment compromettants. Une paire d ’espions israéliens l’ont fait une fois. Alice pourrait prendre Ad et le chiffrer avec son algorithme préféré et sa clef K pour obtenir C. Puis elle prend C et le combine par ou exclusif avec un bout de texte en clair mondain (« Ici Pans » par exemple) pour obtenir K '. Elle stocke C et la combinaison par ou exclusif sur son disque dur. Maintenant, si la police secrète l’interroge, elle peut expliquer qu’elle est une cryptographe amateur et que K ' est simplement un masque jetable pour C. La police pourrait suspecter quelque chose, mais à moins qu’elle connaisse K , elle ne peut pas prouver que l’explication d ’Alice est fausse. Une autre méthode consiste à chiffrer Ad avec un algorithme à clef secrète K , et £ avec K '. Intercalez les bits (ou octets) des textes chiffrés pour faire le texte chiffré final. Si la police secrète demande la clef, Alice lui donne K ' et dit que les bits (ou octets) alternés sont des bruits aléatoires pour décourager toute cryptanalyse. Le fait est que cette explication est si peu plausible que la police secrète ne la croira probablement pas (surtout maintenant qu’elle est suggérée dans ce livre).
10.9
Destruction d’information
243
Une meilleure manière est qu’Alice crée un message leurre, £ , tel que A4 et £ mis bout à bout et compressés soient à peu près de la taille de £ . Appelez cet enchaînement A i'. Alice chiffre alors A i' avec tout algorithme qu’elle partage avec Bernard pour obtenir C. Puis elle envoie C à Bernard. Bernard déchiffre C pour obtenir A i', puis A i et £. Ensuite, ils calculent tous les deux C® L — K'
Ce K ' devient le masque jetable leurre qu’ils utiliseront si la police secrète fait irruption. Alice doit transmettre £ afin que son alibi et celui de Bernard coïncident. Une autre méthode est qu’Alice prenne un message banal et le passe par un code correcteur d’erreur. Puis elle peut introduire des erreurs qui correspondent au message secret chiffré. A la réception, Bernard peut extraire les erreurs pour reconstruire le message secret et le déchiffrer. Il peut aussi utiliser le code correcteur d’erreur pour retrouver le message banal. Alice et Bernard auront du mal à expliquer à la police secrète pourquoi ils obtiennent constamment un taux d ’erreur de bits de 30 pourcents sur un réseau pourtant sans bruit, mais dans certaines circonstances, ceci peut marcher. Enfin, Alice et Bernard peuvent utiliser des canaux subliminaux dans leurs algorithmes de signature digitale (voir § 4.2 et § 23.3). C ’est indétectable, ça marche très bien mais a le défaut de n’autoriser qu’environ 20 caractères de texte subliminal par l’envoi de message banal signé. Ce n’est bon que pour l’envoi de clefs.
10.9
Destruction d’information
Quand vous détruisez un fichier sur la plupart des ordinateur, le fichier n’est pas réellement détruit. La seule chose qui est détruite est l’entrée dans le fichier d’index du disque, qui indique à la machine où se trouve le fichier. Beaucoup de vendeurs de logiciel ont fait fortune en vendant des logiciels de récupération de fichiers après qu’ils furent détruits. Il y a encore un autre motif d ’inquiétude: la mémoire virtuelle implique que votre ordinateur peut lire et écrire la mémoire vers le disque à tout instant. Même si vous ne le sauvez pas, vous ne savez jamais quand un document sensible est envoyé sur le disque. Ce qui veut dire que même si vous ne sauvegardez jamais vos données en clair, votre ordinateur pourrait le faire pour vous. Les programmes de compression au niveau du disque comme « Stacker » et « DoubleSpace » peuvent rendre encore plus difficile la prévision de la manière avec laquelle, et de l’endroit où, l’information est stockée sur le disque. Pour effacer un fichier de manière à ce que ces logiciels ne puissent pas les reconstituer, vous devez écrire physiquement sur chaque bit du fichier sur le disque. D ’après le Centre National de Sécurité Informatique américain (« National Computer Security Center ») [1149] : « La réécriture est le procédé par lequel des données non secrètes sont écrites dans des zones de stockage qui contenaient auparavant des données sensibles ... Pour purger le ... support de stockage, le D o D (le Département de la Défense américaine) requiert la réécriture avec un motif, puis son complément et finalement un autre motif ; par exemple réécrivez première ment avec 0011 0101, suivi de 1100 1010 et ensuite avec 1001 0111. Le
Chapitre 10
Utilisation des algorithmes
nombre de réécritures dépend du type du support de stockage, parfois de sa sensibilité, et parfois des requis du D oD sur certains composants. Dans tous les cas, une purge n’est pas complète avant qu’une réécriture finale soit faite avec des données non secrètes. » Vous aurez peut-être à effacer des fichiers, voire des disques entiers. Vous devrez aussi effacer tout l’espace inutilisé de votre disque dur. La plupart des logiciels qui prétendent réaliser le standard du D oD réécrivent trois fois : une fois avec uniquement des 1, ensuite avec uniquement des 0 et finalement avec un motif répétitif de 1-0. Etant donné mon niveau général de paranoïa, je recommande de réécrire un fichier détruit sept fois : la première fois avec uniquement des 1, la seconde avec uniquement des 0 et les 5 autres fois avec un générateur de séquence pseudo aléatoires cryptographiquement sûr. Des développements récents au N IST avec des microscopes à effet tunnel suggèrent que même cela pourrait ne pas être suffisant. Honnêtement, si vos données ont tant de valeur, considérez qu’il est « impossible » de les effacer complètement d ’un support magnétique. Brûlez ou déchiquetez le support ; il est moins onéreux d’acheter un nouveau support que de perdre vos secrets.
Troisième partie Algorithmes cryptographiques
Chapitre 11
Rudiments mathématiques 11.1
Théorie de l’information
La théorie moderne de l’information fut définie pour la première fois par Claude Elmwood S h a n n o n [1437, 1438]. Ces articles ont été réédités récemment par IEEE Press [1440]. Pour un bon traitement mathématique du sujet, consultez [595]. Dans cette section, je n’aborderai que quelques sujets importants.
Entropie et incertitude La théorie de l’information définit la q u a n t i t é d ’ i n f o r m a t i o n d ’un message comme le nombre minimal de bits nécessaires pour coder toutes les significations possibles de ce message. Par exemple, le champ « jour de la semaine » dans une base de données ne contient pas plus de 3 bits d’information, parce que l’information peut être codée avec 3 bits : 000 001 010 011 100 101 110
= = = = = = =
dimanche lundi mardi mercredi jeudi vendredi samedi
Si cette information était représentée par les chaînes de caractères ASCII correspon dantes, cela prendrait plus de place mémoire mais cela ne contiendrait pas plus d’infor mation. De façon similaire, le champs « sexe » de la base de données contient seulement 1 bit d’information, bien qu’il donne l’impression de devoir être stocké comme l’une des deux chaînes de 5 caractères ASCII « homme » ou « femme ». Formellement, la quantité d’information dans un message M est mesurée par l’e n t r o p i e d’un message, dénotée H (M ). L ’entropie d’un message indiquant le sexe est de 1 bit ; l’entropie d’un message indiquant le jour de la semaine est un tout petit peu moins que 3 bits. En général, l’entropie d ’un message est log2 n, où n est le nombre de significations possibles. Cela suppose que toutes les significations sont équiprobables.
Chapitre 11
S48
Rudiments mathématiques
L’entropie d’un message mesure également son i n c e r t i t u d e . C ’est le nombre de bits de texte en clair qui doivent être retrouvés pour retrouver le texte en clair en entier à partir du texte chiffré. Par exemple, si le bloc de texte chiffré « QHP*5 » a pour texte en clair soit « homme » soit « femm e », alors l’incertitude du message est de 1. Un cryptanalyste doit découvrir un seul bit bien choisi pour retrouver le message.
Taux du langage Pour un langage donné, le t a u x d u l a n g a g e est r = H ( M ) /N
où N est la longueur des messages. Le taux de l’anglais courant prend plusieurs valeurs entre 1 bit et 1,5 bit par lettre, pour des grandes valeurs de N . Dans son livre [1439], S h a n n o n annonce que l’entropie dépend de la longueur du texte. Plus précisément, il indique un taux de 2,3 bit par lettre pour des bribes de 8 lettres, mais le taux tombe entre 1,3 et 1,5 bits par lettre pour des bribes de 16 lettres. Thomas C o v e r a trouvé, avec des techniques de théorie des jeux, une entropie de 1,3 bits par lettre1. Le t a u x a b s o l u d’un langage est le nombre maximal de bits qui peuvent être codés par chaque caractère, en faisant l’hypothèse que toutes les séquences de caractères sont équiprobables. S’il y a L caractères dans le langage, le taux absolu est : R = log2 L
C ’est l’entropie maximale des caractères isolés. Pour l’anglais, avec 26 lettres, le taux absolu est log2 26 = 4,7 bits par lettre. Il n’est pas surprenant que le taux effectif de l’anglais soit nettement inférieur au taux absolu : l’anglais est une langue fortement redondante. La r e d o n d a n c e d’un langage, notée D , est définie par : D — R —r
Étant donné que le taux de l’anglais est de 1,3, la redondance est de 3,5 bits par lettre2. Cela veut dire que chaque caractère apporte 3,5 bits d ’information redondante. Un message ASCII qui n’est rien d ’autre que de l’anglais écrit n’a que 1,2 bit d ’infor mation par 8 bits du message. Cela veut dire qu’il y a alors 6,8 bits de redondance, ce qui donne une redondance globale de 0,85 bit d ’information par bit de texte ASCII et une entropie de 0,15 bit d ’information par bit de texte ASCII. Le même message codé par le système B A U D O T , à 5 bits par caractère, a une redondance de 0,76 bit et une entropie de 0,34 bit par bit de texte B A U D O T . La prise en compte des blancs, de la ponctuation, des nombres et de la mise en page modifierait ces résultats.
Sécurité d’un cryptosystème S h a n n o n a défini un modèle mathématique précis de ce que l’on peut entendre par un cryptosystème sûr. Le but des cryptanalystes est de déterminer la clef K , le texte 1. J ’utiliserai ce tau x d e 1,3 dans ce livre. 2. N ote du traducteu r: d ’après [240], la redondance d e la langue française est un petit peu plus élevée.
11.1
Théorie de l’information
249
en clair A4, ou les deux. Toutefois, ils peuvent se contenter de certaines informations probabilistes concernant A4 si c’est du son numérisé, si c ’est un texte en allemand, si ce sont des données pour un tableur, ou quelque chose d ’autre. Pour la plupart des cryptanalysés du monde réel, les cryptanalystes ont quelques in formations probabilistes concernant A4 avant de commencer. Ils connaissent probable- . ment le langage du texte en clair. Ce langage a une certaine redondance associée. Si c’est un message destiné à Bernard, il commence probablement par « C h e r B o b , ». Certainement, « C h e r B o b , » est plus probable que « e 8 T & g [,m ». Le but de la cryp tanalyse est, par analyse, de modifier les probabilités associées avec tous les textes en clair possibles. Finalement un texte en clair considéré comme certain (ou au moins, très probable) émergera du paquet des textes en clair possibles. Il existe quelque chose que l’on peut appeler cryptosystème à c o n f i d e n t i a l i t é p a r f a i t e . C ’est un cryptosystème dans lequel le texte chiffré ne fournit pas la moindre information concernant le texte en clair (excepté peut-être sa longueur). S h a n n o n postula que ce n’était possible que si le nombre de clefs possibles est au moins aussi grand que le nombre de messages possibles. En d ’autres termes, la clef doit être au moins aussi longue que le message lui-même et aucune clef ne peut être réutilisée. En d’autres termes encore, le masque jetable (voir § 1.5) est le seul cryptosystème qui assure une confidentialité parfaite. La confidentialité parfaite mise à part, le texte chiffré donne quelques informations sur le texte en clair correspondant. C ’est inévitable. Un bon algorithme cryptographique minimisera cette information ; un bon cryptanalyste exploite cette information pour retrouver le texte en clair. Les cryptanalystes utilisent la redondance naturelle du langage pour réduire le nombre possible de textes en clair. Plus le langage est redondant, plus simple il est à cryp tanalyser. C ’est la raison pour laquelle de nombreuses réalisations cryptographiques concrètes utilisent avant de chiffrer un programme de compression pour réduire la taille du texte. La compression réduit la redondance du message et aussi le travail à fournir pour chiffrer et déchiffrer. L’entropie d’un cryptosystème est une mesure de la taille de l’ensemble des clefs. Elle est approchée par le logarithme en base 2 du nombre de clefs : H (K ) = log2(nombre de clefs)
Un cryptosystème avec une clef de 64 bits a une entropie de 64 ; un cryptosystème avec une clef de 56 bits a une entropie de 56. En général, plus grande est l’entropie, plus difficile il est de casser le cryptosystème.
Distance d’unicité Pour un message de longueur n, le nombre de clefs différentes qui traduiront un message chiffré en un texte en clair intelligible dans un même language est donné par la formule suivante [714, 102] : 2H ( K ) ~ n D _ ^ S h a n n o n [1438] a défini la d i s t a n c e d ’ u n i c i t é , U, appelée aussi le point d ’unicité, comme une approximation de la quantité de texte chiffré telle que la somme des infor mations réelles (entropie) dans le texte en clair correspondant et de l’entropie de la clef de chiffrement soit égale au nombre de bits de texte chiffré utilisés. Il montra alors que
250
Chapitre 11
Rudiments mathématiques
des textes chiffrés plus longs que cette valeur sont raisonnablement certains de n’avoir qu’un seul déchiffrement plausible. Des textes chiffrés significativement plus courts que cela ont des chances d’avoir plusieurs déchiffrements également valables et donc augmentent la sécurité, car il est difficile à l’attaquant de choisir le bon déchiffrement. Pour la plupart des cryptosystèmes à clef secrète, la distance d’unicité est définie comme l’entropie du cryptosystème divisée par la redondance du langage : U = H (K)/D .
La distance d’unicité, comme toute mesure d ’information statistique ou théorique, ne fait pas de prédictions déterministes mais donne des résultats probabilistes. La distance d ’unicité indique le minimum de texte chiffré pour lequel il est probable qu’il n’y ait qu’un seul texte en clair plausible correspondant quand une attaque exhaustive est montée. En général, plus grande est la distance d’unicité, meilleur est le cryptosystème. Pour le DES, avec une clef de 56 bits, et un message en anglais codé en ASCII, la distance d’unicité est d ’environ 8,2 caractères ASCII, ou 66 bits. Le tableau 11.1 donne les distances d ’unicité pour différentes longueurs de clef. Les distances d’unicité de quelques cryptosystèmes classiques sont donnés dans [448].
T a b . 11.1
clef.
- Distances d’unicité de texte ASC II chiffré avec différentes longueurs de ______________________________________________ Distance d ’unicité Longueur de la clef (en nombre de lettres) (en bits) 40 5,9 8,2 56 64 9,4 11,8 80 128 18,8 256 37,6
La distance d’unicité n’est pas une mesure de la quantité de texte chiffré qu’il faut pour la cryptanalyse mais bien de la quantité de texte chiffré nécessaire pour qu’il n’y ait qu’une solution raisonnable à la cryptanalyse. Un cryptosystème peut être inviolable par calcul même si théoriquement il est possible de le casser avec une faible quantité de texte chiffré3. La distance d ’unicité est inversement proportionnelle à la redondance. Quand la redondance approche de zéro, même un chiffrement trivial peut être inviolable par une attaque à texte chiffré seulement. S h a n n o n définit un cryptosystème dont la distance d ’unicité est infinie comme un système à c o n f i d e n t i a l i t é i d é a l e . Remarquez qu’un cryptosystème idéal n’est pas forcément un cryptosystème parfait, bien qu’un cryptosystème parfait soit nécessai rement un cryptosystème idéal. Si un cryptosystème offre une confidentialité idéale, même une cryptanalyse réussie laissera une incertitude quant à savoir si le texte dé codé est le bon texte. 3. La théorie de la c r y p t o g r a p h i e r e la t iv is é e , bien qu ’ésotérique et peu pratique, est appropriée ici [233, 234, 235, 236, 237, 238].
11.2
Théorie de la complexité
251
Théorie de l’information en pratique Bien que ces concepts aient une grande valeur théorique, la cryptanalyse réelle se base rarement là-dessus. Trop petit, la distance d’unicité reste aussi peu sûre que si elle est grande. Peu d’algorithmes pratiques sont totalement imperméables à l’analyse; toutes sortes de caractéristiques peuvent servir de bras de levier pour casser certains messages chiffrés. Toutefois, des considérations sur la théorie de l’information sont parfois utiles, par exemple pour déterminer l’intervalle de changement de clefs pour un algorithme déterminé. Les cryptanalystes utilisent une variété de tests statistiques basés sur la théorie de l’information afin de mener leurs analyses dans les directions les plus efficaces. Malheureusement, la plupart des publications concernant la théorie de l’information appliquée à la cryptanalyse demeurent secrètes, comme le compte-rendu du séminaire de 1940 d ’Alan T u r i n g .
Confusion et diffusion Les deux techniques de base pour gommer les redondances dans un texte en clair sont selon S h a n n o n la confusion et la diffusion [1438]. La c o n f u s i o n gomme les relations entre le texte en clair et le texte chiffré. Elle évite l’analyse du texte chiffré par recherche de redondances et de motifs statistiques. Le moyen le plus simple de réaliser cela est la substitution. Un chiffre à substitution simple, tel le système à décalage de Jules César, est un système dans lequel chaque lettre identique du texte en clair est remplacée par une même autre lettre dans le texte chiffré. Les chiffres à substitution modernes sont plus compliqués : un long bloc de texte en clair est remplacé par un autre bloc de texte chiffré et le mécanisme de substitution change avec chaque bit du texte en clair. Ce type de substitution n’est pas nécessairement suffisant ; le système allemand E N IG M A est un algorithme de substitution complexe qui fut cassé durant la Seconde Guerre mondiale. La d i f f u s i o n disperse la redondance du texte en clair en la répartissant dans le texte chiffré. Un cryptanalyste qui recherche ces redondances aura plus de difficultés à les trouver. Le moyen le plus simple de provoquer la diffusion est la transposition (ap pelée aussi p e r m u t a t i o n ) . Un chiffre à transposition simple, telle la transposition en colonnes, réarrange simplement les lettres du texte en clair. Les chiffres modernes réalisent ce type de permutation, mais ils emploient d’autres formes de diffusion qui peuvent diffuser les parties du message à travers la totalité du message. Les chiffres en continu se basent sur la confusion seulement. Les algorithmes par blocs utilisent à la fois la confusion et la diffusion. En règle générale, la diffusion seule est facile à casser (bien que la double transposition résiste mieux que beaucoup d’autres méthodes faisables avec un papier et un crayon).
11.2
Théorie de la complexité
La théorie de la complexité fournit une méthodologie pour analyser la complexité de calcul de différents algorithmes et techniques cryptographiques. Elle compare les algorithmes et les techniques cryptographiques pour déterminer leur niveau de sécurité. La théorie de l’information nous apprend que tous les algorithmes cryptographiques (excepté les masques jetables) peuvent être cassés. La théorie de la complexité nous
252
Chapitre 11
Rudiments mathématiques
apprend s’ils peuvent être cassés avant la fin du monde...
Complexité des algorithmes La complexité d’un algorithme est déterminée par la puissance de calcul nécessaire pour l’exécuter. La complexité calculatoire d’un algorithme est mesurée par deux pa ramètres : T (pour la c o m p l e x i t é e n t e m p s ) et S (pour la c o m p l e x i t é e n e s p a c e , ou mémoire nécessaire). En général T et 5 sont tous deux exprimés en fonction de n, où n est la taille de l’entrée4. En général, la complexité calculatoire d’un algorithme est exprimée à l’aide de ce que l’on appelle la notation « grand O » : l’ordre de grandeur de la complexité du calcul à savoir le terme de la fonction de complexité qui croît le plus vite avec n ; toutes les constantes et les termes d ’ordre inférieur sont ignorés. Par exemple, si la complexité en temps d ’un algorithme donné est de 4n2 + 7 n + 12, alors la complexité en calcul sera de l’ordre de n2, ce qui s’exprime aussi par 0 ( n 2). De cette façon, la mesure de la complexité en temps est indépendante du système. Vous n’avez pas à connaître le timing exact des différentes instructions ou le nombre de bits utilisés pour représenter les différentes variables ou même la vitesse du processeur. Tel ordinateur peut être une fois et demi plus rapide qu’un autre ou tel autre peut avoir un chemin de donnée deux fois plus large, l’ordre de grandeur de la complexité d ’un algorithme reste le même. Ce n’est pas de la triche ; quand vous manipulez des algorithmes aussi complexes que ceux décrits dans cet ouvrage, les autres informations sont en général négligeables par rapport à l’ordre de grandeur de la complexité. Cette notation vous permet de voir la façon dont les besoins en temps et en espace évoluent avec la taille des entrées. Par exemple, si T = (D(n), alors doubler la taille de l’entrée double le temps de calcul de l’algorithme. Si T = 0 ( 2 n), alors ajouter 1 bit à la taille de l’entrée double le temps de calcul de l’algorithme (à un facteur constant près). En général, les algorithmes sont classés d’après leur complexité en temps ou en espace. Un algorithme est c o n s t a n t si sa complexité est indépendante de n : 0 (1 ). Un algo rithme est l i n é a i r e , 0(n), si sa complexité croît linéairement avec n. Les algorithmes peuvent être aussi q u a d r a t i q u e s , c u b i q u e s , etc. Tous ces algorithmes sont p o l y n o m i a u x : leur complexité est 0 ( n ‘ ) où t est une constante. La classe des algorithmes qui ont une complexité en temps polynomiale sont appelés algorithmes p o l y n o m i a u x e n te m p s.
Les algorithmes dont la complexité est 0 ( t ^ n^), où t est une constante et f(n) est une certaine fonction polynomiale de n, sont appelés e x p o n e n t i e l s . Ceux dont la complexité est 0 { t ^ n^), où t est une constante et /( n ) est plus que constante mais moins que linéaire, sont appelés s u p e r p o l y n o m i a u x . Idéalement, les cryptographes voudraient pouvoir dire que tout algorithme de cassage pour leurs chiffres doivent être exponentiels en temps. En pratique, les affirmations les plus fortes qui peuvent être faites, étant donné l’état de l’art de la théorie de la complexité, sont de la forme « tout algorithme de cassage connu pour ce chiffre a une complexité superpolynomiale en temps ». C ’est-à-dire que, pour les chiffres utili sés en pratique, les algorithmes de cassage que nous connaissons ont une complexité 4. Il y a d ’ autres mesures de la com plexité : le nom bre de bits aléatoires, le débit de com m unications, la quantité de données, etc.
11.2
Théorie de la complexité
253
superpolynomiale en temps mais qu’il n’est pas encore possible de prouver qu’on ne pourra jamais découvrir un algorithme de cassage polynomial en temps. Les avancées en théorie de la complexité permettront peut-être un jour de concevoir des chiffres pour lesquels l’existence d’algorithmes de cassage polynomiaux en temps pourra être écartée mathématiquement avec certitude. Quand n croît, la complexité en temps d’un algorithme peut faire une énorme différence quant à l’applicabilité de l’algorithme. Le tableau 11.2 montre les temps d ’exécution de différentes classes d’algorithmes pour lesquels n vaut un million. Le tableau passe sous silence les constantes et montre pourquoi il est raisonnable de les ignorer.
Tab. 11.2 - Temps de calcul pour différentes classes d’algorithmes Classe
Complexité
Constants Linéaires Quadratiques Cubiques Exponentiels
0 (1 ) 0 (n ) 0 ( n 2) 0 ( n 3) 0 ( 2n)
Nombre d’opérations pour n = 106 1 106 1012 1018 JQ301 030
Temps pour 10 opérations par seconde 1 ps 1s 11,6 j 32 000 années 10301 o°6 fois l’âge de l’univers
En faisant l’hypothèse que l’unité de temps de votre ordinateur est la microseconde, (lis), l’ordinateur peut effectuer un algorithme constant en une microseconde, un al gorithme ünéaire en une seconde et un algorithme quadratique en 11,6 jours. Cela prendrait 32000 ans pour exécuter l’algorithme cubique; ce qui n’est pas très pra tique, mais dans ce cas-là l’univers existe encore, il serait possible pour un ordinateur de fournir finalement une solution. Exécuter des algorithmes exponentiels est futile, peu importe comment vous extrapolez la puissance de calcul, le traitement en parallèle et l’aide d’extra-terrestres super-intelligents. Prenez le problème de l’attaque exhaustive contre un cryptosystème. La complexité en temps de cette attaque est proportionnelle au nombre de clefs possibles, qui est une fonction exponentielle de la longueur de clef. Si n est la longueur de clef, alors la complexité d ’une attaque exhaustive est 0 ( 2n). Le paragraphe 10.1 présente la controverse autour de la clef de 56 bits au lieu de 112 bits pour le DES. La complexité d’une attaque exhaustive contre une clef de 56 bits est 256 ; alors que contre une clef de 112 bits la complexité est de 2112. Le premier résultat est à la limite du réalisable, le deuxième est tout à fait hors de portée.
Complexité de problèmes La théorie de la complexité classe aussi la complexité inhérente des problèmes, et pas seulement la complexité d ’algorithmes particuliers utiüsés pour résoudre des pro blèmes5. La théorie détermine les temps et espace minimaux nécessaires pour résoudre l’instance la plus difficile du problème sur un ordinateur théorique connu sous le nom de m a c h i n e d e T u r i n g . Il s’agit d ’une machine à états finis avec une mémoire en 5. Une excellente introduction du sujet est donnée dans [603, 214, 1236] ; voyez également [1102, 31, 741],
Chapitre 11
254
Rudiments mathématiques
écriture et en lecture sous la forme d ’un ruban infini. Il s’avère que la machine de Turing est un modèle réaliste du calcul. Les problèmes qui peuvent être résolus avec des algorithmes polynomiaux en temps sont appelés s o l u b l e s , parce qu’ils peuvent généralement être résolus en un temps raisonnable pour des entrées de taille raisonnable6. Les problèmes qui ne peuvent pas être résolus en temps polynomial sont appelés n o n s o l u b l e s , parce que calculer leur solution devient rapidement impossible. Les problèmes non solubles sont parfois appelés simplement d i f f i c i l e s . Ils le sont. Les problèmes qui peuvent être résolus par des algorithmes exponentiels ou superpolynomiaux sont non solubles par calcul, même pour des valeurs relativement petites de n. Il y a pire. Alan T u r i n g a prouvé que certains problèmes étaient i n d é c i d a b l e s . Il est impossible de concevoir un algorithme pour les résoudre, et certainement pas un algorithme polynomial. Les problèmes peuvent être rangés dans des classes de complexité qui dépendent de la complexité de leurs solutions. La figure 11.1 montre les classes de complexité les plus importantes et leurs liens présumés (malheureusement il n’y a pas beaucoup de preuves mathématiques à ce propos).
F
ig
. 1 1 .1 -
Classes de complexité
Tout en bas, la classe P contient tous les problèmes qui peuvent être résolus en temps polynomial. La classe N P contient tous les problèmes qui peuvent être résolus en temps polynomial sur une machine de Turing non déterministe. C’est une variante de la machine de Turing normale qui devine les solutions. La machine devine une solution d ’un problème— soit en faisant par chance une bonne hypothèse, soit en essayant toutes les possibilités en parallèle— et vérifie son hypothèse en temps polynomial. 6. La définition exacte de « ra iso n n a b le » dépend des circonstances.
11.2
Théorie de la complexité
255
L’intérêt cryptographique de la classe N P réside en ceci: de nombreuses classes de chiffres conventionnels peuvent être cassés en un temps non déterministe polynomial. Etant donné un texte chiffré C, le cryptanalyste devine simplement un texte en clair X et une clef k, et en un temps polynomial il exécute l’algorithme de chiffrement sur les entrées X et k, et enfin vérifie si le résultat est égal à C. C ’est important théoriquement, car cela donne une borne supérieure de la complexité pour la cryptanalyse des chiffres de ces classes. Bien sûr, en pratique, c’est un algorithme en temps polynomial déterministe que le cryptanalyste recherche. De plus, cet argument n’est pas applicable à toutes les classes de chiffres et en particulier aux masques jetables — pour tout C, il y a de nombreuses paires X , k qui donnent C quand on utilise l’algorithme de chiffrement mais la plupart de ces X sont des textes en clair non légitimes sans aucun sens. La classe N P contient la classe P parce que tout problème soluble en temps polynomial sur une machine de Turing déterministe est aussi soluble en temps polynomial sur une machine de Turing non déterministe, car l’étape de devinette peut tout simplement être supprimée. Si tous les problèmes N P sont solubles en temps polynomial sur une machine détermi niste, alors P — N P . Bien qu’il semble évident que certains problèmes N P se montrent nettement plus difficiles que d ’autres (une attaque exhaustive contre un chiffre vs le chiffrement d’un bloc quelconque de texte en clair), il n’a jamais été prouvé que P ^ N P (ou P = N P ). Toutefois, tous ceux qui travaillent en théorie de la complexité soupçonnent qu’elles ne sont pas égales. Plus étrange encore, il y a des problèmes spécifiques dans N P qui se révèlent aussi difficiles que tout autre problème de même catégorie- C O O K [369] a prouvé que le problème SA T (« étant donné une formule booléenne propositionnelle, y a-t-il un moyen d’assigner des valeurs de vérité aux variables de telle manière que la formule soit vraie ? ») est N P —co m p le t. Cela veut dire que, si SA T peut être résolu en temps polynomial, alors P — N P . Inversement, si l’on peut prouver que tout problème dans N P n ’a pas un algorithme déterministe polynomial en temps, cela démontrerait que
SAT n’admet pas non plus d’algorithme déterministe polynomial en temps. Il n’y a donc pas de problème plus difficile que SA T dans N P . Depuis que l’article de C O O K a été publié, un grand nombre de problèmes ont été montrés équivalents à SA T ; des centaines d ’entre eux sont cités dans [370] et des exemples sont donnés ci-dessous. Par extension, j ’appelerai ces problèmes également N P —co m p le ts : c’est-à-dire, ils sont aussi difficiles que tout autre problème dans N P . Si leur solvabilité en temps polynomial déterministe était déterminée, alors la question P vs N P serait tranchée. Est-ce que P est égale à N P ? est la question centrale non résolue de la théorie de la complexité et personne ne s’attend à avoir une réponse de si tôt. Si quelqu’un démontrait que P — N P , alors la plus grande partie de cet ouvrage serait inutile : comme je l’ai expliqué ci-dessus, de nombreuses classes de chiffres sont trivialement cassables en temps polynomial non déterministe et si P = N P , ils sont cassables par des algorithmes déterministes utilisables. Plus haut dans la hiérarchie de la complexité on trouve P S P A C E . Les problèmes dans P S P A C E peuvent être résolus dans un espace polynomial mais pas nécessairement en temps polynomial. P S P A C E comprend N P mais il y a dans P S P A C E des problèmes dont on pense qu’ils sont plus difficiles que N P . Bien sûr, ce n ’est pas non plus prouvé. Il y a une classe de problèmes, appelés P S P A C E —com p lets, qui ont la propriété suivante : si n’importe lequel d ’entre eux est dans N P alors P S P A C E = N P et si l’un
Chapitre 11
256
Rudiments mathématiques
d’entre eux est dans P alors P S P A C E = P. Et enfin, il y a une classe de problèmes appelés E X P T I M E . Ces problèmes sont solubles en temps exponentiel. Les problèmes E X P T I M E —complets sont ceux qui ne peuvent pas être résolus en temps déterministe polynomial. Il a été démontré que P n’est pas égale à E X P T I M E .
Problèmes N P —complets Michael G a r e y et David J o h n s o n ont rassemblé une liste de plus de 300 problèmes N P —complets [603]. En voici seulement quelques-uns: Le Problème du Commis Voyageur. Un commis voyageur doit visiter n villes différentes et il n’a qu’un plein d ’essence (il ne peut donc parcourir qu’une distance maximale). Existe-t-il un itinéraire qui lui permettrait de visiter chaque ville une fois et une seule avec ce plein d ’essence?7 Le Problème du Groupement par trois. Soit n hommes et n femmes dans une pièce ainsi que n membres du clergé (prêtres, rabbins, etc.) ; soit une liste des groupements acceptables, qui consistent en un homme, une femme, et un membre du clergé disposé à officier. Etant donné cette liste des triplets possibles, est-il possible d ’arranger n groupements de telle manière que chacun soit épouse quelqu’un, soit officie pour un mariage? Le Problème 3-SAT. Soit une liste de n propositions logiques, chacune comportant trois littéraux : (x A y) => z, (x A w) V ( ~ i z ) , ((->« A ->x) V (z A (u V - æ ) ) ) => ( ( - i z A u ) V x), etc. Existe-t-il une assignation de valeurs de vérité pour tous les littéraux qui satisfasse toutes les propositions?8
11.3
Théorie des nombres
Ce livre n’est pas un ouvrage sur la théorie des nombres, aussi je me contenterai d ’ébaucher ici les quelques thèmes nécessaires à la bonne compréhension des chapitres suivants. Si vous voulez approfondir votre connaissance de la théorie des nombres, vous consulterez avantageusement les ouvrages suivants: [1436, 79, 1177, 16, 970, 682, 744, 422]. Pour la théorie des corps finis, mes deux livres préférés sont: [981, 1050]. Consultez également [95, 1157, 1158, 1067].
Congruences Vous avez tous appris l’arithmétique modulo n 9 à l’école ; cela s’appelait Y arithmé tique de l’horloge. Rappelez-vous les problèmes tels que: « si Marc dit qu’il sera à la maison pour 10 heures et qu’il rentre 13 heures plus tard, à quelle heure rentre-t-il à la maison et quel est l’âge du capitaine? » 7. C ’est une généralisation du problèm e d u Circuit H am iltonien — voir § 5.1. 8. C ’est un cas particulier d u problèm e S A T m entionné ci-dessus. 9. Les termes arithm étique des congruences, congruences et arithm étique m od u lo n, désignent tous la mêm e chose.
11.3
257
Théorie des nombres
C’est de l’arithmétique modulo 12. 23 modulo 12 est égal à 11. (1 0 + 1 3 ) mod 12 = 11. Ce qui s’exprime aussi par « 23 et 11 sont équivalents modulo 12 ». (10 + 13) = 11
(mod 12).
La notation a = b (mod n) indique que a = fe + kn pour un certain entier k. Si a et b sont positifs et si b est plus petit que n, vous pouvez considérer que b est le reste de la division de a par n. On a aussi la propriété que a et 6 donnent le même reste quand ils sont divisés par n. Parfois, b est appelé le résidu de a modulo n. On dit aussi que a est congru à b modulo n (le symbole s dénote une congruence). Ce ne sont que différentes manières de dire la même chose. L’ensemble des entiers de 0 à n — 1 forme ce que l’on appelle l’ensemble de tous les résidus modulo n. Ce qui signifie que, pour tout entier quelconque a, son résidu modulo n est un nombre compris entre 0 et n — 1 bornes comprises. L’opération a mod n dénote le résidu de a. Ce résidu est un nombre entier compris entre 0 et n — 1. Cette opération est parfois appelée la réduction modulo n. Par exemple, 5 mod 3 = 2. Attention, cette définition de « mod » peut être différente de celle qui est utilisée dans certains langages de programmation. Par exemple, l’opérateur modulo du langage Pascal fournit parfois un résultat négatif. Dans ce cas, le résultat est compris entre —n~ 1 et n- 1. Dans le langage C, l’opérateur % fournit le reste de la division du premier opérande par le deuxième ; ce résultat peut être négatif si l’un des opérandes est négatif. Lorsque vous réalisez un algorithme de ce livre dans un langage de programmation pour lequel l’opération modulo peut donner un résultat négatif, n’oubliez pas d’ajouter n au résultat d ’une opération modulo si celui-ci est négatif. Tout comme l’arithmétique classique, l’arithmétique modulo n jouit des propriétés de commutativité, d ’associativité et de distributivité. De plus, lors d ’un calcul, la valeur finale obtenue sera la même que vous appliquiez la réduction modulo n à chaque étape intermédiaire ou que vous appliquiez celle-ci au résultat final seulement. Les formules suivantes expriment formellement certaines de ces propriétés : (a + b) mod n
= ((a mod n) + (b mod n )) mod n
(a — b) mod n
= ((a mod n) —(b mod n)) mod n
(a x b) mod n
= ((a mod n) x (b mod n )) mod n
(a x (b + c)) mod n
= (((a x 6) mod n) + ((a x c) mod n)) mod n.
En cryptographie, on fait un usage intensif de l’arithmétique modulo n. Celle-ci per met de restreindre la taille de tous les résultats intermédiaires et de la valeur finale. C’est indispensable, par exemple, pour le calcul de logarithmes discrets ou de racines carrées qui sont des opérations très coûteuses en ressources de calcul (temps et es pace mémoire). Pour un module n qui peut être représenté par k bits, le résultat de toute addition, soustraction ou multiplication peut être représenté par au plus 2k bits. Comme on peut appliquer la réduction modulo n pour toutes les étapes intermédiaires d’un calcul, on ne devra jamais manipuler des nombres représentés par plus de 2k bits.
Chapitre 11
258
Rudiments mathématiques
On peut ainsi, par exemple, calculer des exponentielles en arithmétique modulo n sans engendrer des résultats intermédiaires démesurés. Elever un nombre à une puissance entière modulo n, ax mod n
se fait par une série de multiplications et de divisions, mais il existe des techniques pour effectuer cela efficacement. Une de ces techniques consiste à minimiser le nombre de multiplications modulo n ; une autre consiste à optimiser le calcul de la multiplication modulo n. Comme l’arithmétique modulo n est distributive, il est plus efficace d ’entre lacer les multiplications avec des réductions modulo n à chaque étape intermédiaire. Pour les exemples qui suivent, cela peut ne pas sembler d ’une grande utilité, mais pour des nombres de 200 bits c ’est essentiel. Par exemple, si vous voulez calculer a8 mod n, n’utilisez pas l’approche simpliste qui consiste à effectuer 7 multiplications suivies d ’une coûteuse réduction modulo n finale : ( a x a x a x a x a x a x a x a ) mod n.
Il est plus avantageux d ’effectuer 3 multiplications plus petites ainsi que 3 réductions modulo n également plus petites : ((a2 mod n)2 mod n )2 mod n. La même technique appliquée à une puissance 16e donne : a16 mod n — ({(a2 mod n )2 mod n )2 mod n)2 mod n. Calculer ax mod n quand x n ’est pas une puissance de 2 n’est qu’un tout petit peu plus difficile. Illustrons cela pour x — 25. La première étape consiste à représenter x en notation binaire (c’est-à-dire, comme une somme de puissances de 2). La représentation binaire de 25 est 11001 et donc 25 = 24 + 23 + 2°. Ensuite, quelques transformations élémentaires donnent : a25 mod n
=
(g
=
(a x ((a2)2)2 x (((a 2)2)2)2) mod n
x a8 x a 16) mod n
=
((((a 2 x a)2)2)2 x a) mod n
Par un arrangement judicieux de la mémorisation des résultats intermédiaires, il y a moyen de n ’effectuer que 6 multiplications : (((((((a 2 mod n ) x a) mod n )2 mod n)2 mod n )2 mod n) x a) mod n. Cette technique de calcul s’appelle la so m m a tion en chaîne [864]. Elle utilise une suite d’additions simple et évidente qui est basée sur la représentation binaire. Cela peut être codée en C par la fonction suivante : unsigned long modexp (unsigned long a, unsigned long x, unsigned long n) ■
ll.S
Théorie des nombres
259
unsigned long s; s = 1; while(u) -[ if(x&l) /* x est-il impair ? */ s = (s*a)%n; x»=l; a = (a*a)%n; } return(s); } Une autre fonction, récursive, est la suivante : unsigned long exp_rapide(unsigned long a, unsigned long x, unsigned long n) { unsigned long tmp; if(x==l) return(a°/n) ; if(l~(a&l)) { tmp = exp_rapide(a,x»l,n) ; return((tmp*tmp)%n); > else { tmp = exp_rapide(a, (x-l)»l,n) ; tmp = (tmp*tmp)%n; tmp = (tmp*a)%n; return(tmp); > } Si k est le nombre de bits de l’exposant x, la technique précédente nécessite, en moyenne, 1,5 x k opérations. Trouver la suite d ’opérations la plus courte possible est un problème difficile (il a été prouvé qu’une telle suite contient au moins fc —1 opérations), mais il n’est pas trop difficile de ramener le nombre d’opérations à 1,1 x k ou mieux encore quand k est grand. Il est possible de calculer efficacement des réductions modulo n utilisant toujours le même n avec la méthode de Montgomery [1117]. Une autre méthode est l’algorithme de Barrett [94]. Les performances de ces deux algorithmes et de celui donné plus haut sont données dans [2] : l’algorithme que j ’ai présenté plus haut consti tue le meilleur choix pour une seule réduction modulo n, l’algorithme de B a r r e t t est le meilleur pour des petits arguments, et la méthode de M o n t g o m e r y est la meilleure pour le calcul de puissances modulo n en général10. L’inverse du problème de l’élévation de puissance est le calcul du logarithme discret. Nous en reparlerons bientôt (voir § 9.6). 10. La m éthode de M o n t g o m e r y peut aussi tirer avantage des petites puissances en utilisant ce qui s’appelle de l ’arithm étique m ixte.
Chapitre 11
260
Rudiments mathématiques
Nombres premiers Un nombre premier est un nombre entier, strictement plus grand que 1, dont les seuls facteurs sont 1 et lui-même : aucun autre nombre ne le divise exactement. Le nombre 2 est un nombre premier, de même que: 73, 2 521, 2 365 3 4 7 7 3 4 3 3 9 , et 2 756839 — 1. Un nombre qui n’est pas premier est dit composé. Il y a une infinité de nombres premiers. En cryptographie, on utilise souvent de très grands nombres premiers (de 512 bits ou plus). Evengelos K r a n a k i s est l’auteur d ’un excellent livre sur la théorie des nombres, les nombres premiers, et leur application en cryptographie [896]. Paulo R lB E N B O lM a écrit deux excellents ouvrages de référence sur les nombres premiers en général [1318, 1319].
Plus grand commun diviseur Deux nombres sont premiers entre eux quand il n’ont d’autre facteur en commun que 1. En d’autres termes, si le plus grand commun diviseur (P G C D en abrégé) de a et n est 1, alors a et n sont dits premiers entre eux, ce qui s’écrit : pgcd(a,n) = 1.
Les nombres 15 et 28 sont premiers entres eux ainsi que 13 et 500, tandis que 15 et 27 ne le sont pas (3 est un facteur commun plus grand que 1). Un nombre premier est premier par rapport à tous les autres nombres excepté ses propres multiples. La méthode la plus simple pour calculer le plus grand commun diviseur de deux nombres est donnée par l’algorithme d ’Euclide. Cet algorithme est décrit dans les « Eléments d’Euclide » écrits 300 ans avant J.-C. E u c l i d e ne l’a pas inventé. Les his toriens pensent que l’algorithme en question pourrait être plus vieux de 200 ans. C ’est un des plus vieux algorithmes non triviaux connus et nous nous en servons encore de nos jours. K n u t h décrit cet algorithme et quelques variantes modernes [864]. En C : /* calcule le plus grand commun diviseur de x et y */ int pgcdfint x, int y) f int g; if (x < 0) x = -x; if (y < 0) y = -y ; if (x + y == 0) ERR0R j g = y; whilefx > 0) { g = x; x = y 7. x; y = g; > return(g); >
ll.S
Théorie des nombres
261
Cet algorithme peut être généralisé pour calculer le PGCD d’un tableau de m nombres : / * c a lc u le l e plu s grand commun d iv is e u r de x l , x2,
xm * /
in t m u ltip le _ p g cd (in t m, in t *x) { s iz e _ t i ; in t g; if(m < 1) re tu r n (O ); g = x [0] ; f o r ( i = l ; i
r e t u r n (g ); >
Inverses modulo n Vous vous rappelez les inverses? L ’inverse de 4 est 1/4 car 4 x 1 / 4 = 1. Dans le monde de l’arithmétique modulo n, c ’est plus compliqué: 4 x i s l
(mod 7).
Cette équation revient à chercher un x et un k tels que :
f
4x = 7k + 1
et où x et k sont des entiers. Le problème général consiste à trouver un x tel que : 1 = (a x x) mod n ce qui s’écrit aussi : a-1 = x
(mod n).
Le calcul de l’inverse d ’un nombre modulo n est un problème difficile à résoudre. Parfois, il y a une solution ; parfois, il n’y en a pas. Par exemple, l’inverse de 5 modulo 14 est 3 car 5 x 3 = 15 = 1 (mod 14). D ’autre par, 2 n’a pas d’inverse modulo 14. En général, a *1 = x (mod n) a une solution x unique si a et n sont premiers entre eux. Si a et n ne sont pas premiers entre eux, alors cTx = x (mod n) n’a pas de solution. Si n est un nombre premier, alors chaque nombre compris entre 1 et n —1 est premier par rapport à n et chacun a exactement un inverse modulo n dans cet intervalle. Mais comment calcule-t-on l’inverse de a modulo n ? Il y a plusieurs méthodes. L’algorithme d ’Euclide permet aussi calculer l’inverse d ’un nombre modulo n. Cet algorithme est parfois appelé a l g o r i t h m e d ’ E u c l i d e é t e n d u .
Chapitre 11
262
Rudiments mathématiques
Voici l’algorithme écrit en C + + : #define estPair(x) ((x & 0x01) == 0) #define estlmpair(x) (x & 0x01) #define intervertir(x.y) (x “= y, y ~= x, x "= y) void EuclideÉtendu(int *u, int *v, int *ul, int *u2, int *u3) { // Attention : u et v seront intervertis si u < v int k, tl, t2, t3; if(*u < *v) intervertir(*u,*v); for(k=0; estPair(*u) && estPair(*v); ++k) { *u » = 1; *v » = 1; > *ul = 1; *u2 = 0; *u3 = *u; tl = *v; t2 = *u-l; t3 = *v; do { do { if(estPair(*u3)) { if (estPairOul) II estPair(*u2) ) { *ul += *v; *u2 += *u; > *ul » = 1; *u2 » = 1; *u3 » = 1; > if(estPair(t3) II *u3 < t3) { intervertir(*ul,tl); intervertir(*u2,t2); intervertir(*u3,t3); > > while(estPair(*u3) ); while(*ul < tl II *u2 < t2) { *ul += *v; *u2 += *u; > *ul -= tl; *u2 -= t2; *u3 -= t3; } while(t3 > 0); while(*ul >= *v && *u2 >= *u) { *ul -= *v; *u2 -= *u; > *u « = k; *u2 « = k; *u3 <<= k; } main(int argc, char **argv) { int a,b,pgcd; if(argc < 3) { cerr << "Utilisation : euclide u v" << endl; return(-l); > int u = atoi(argv[l]);
11.3
263
Théorie des nombres int v = atoi(argv[2]); if(u <= 0 II v <= 0) { cerr « "Les arguments doivent être strictement positifs!" « endl; return(-2);
> // Attention, u et v seront échangés si u < v EuclideÉtendu(&u,& v ,& a ,& b ,fepgcd); cout « a « " * " « u « " + ( « b « ") * " « v « " = " « pgcd « endl; if(pgcd == 1) cout « "L’inverse de " « v « " mod " « u « « u - b « endl; return(O);
" est : "
> Je ne vais pas prouver que cela marche, ni donner la théorie sous-jacente. Les détails se trouvent dans [864], ou dans tout autre texte sur la théorie des nombres cité plus haut. L’algorithme est itératif et peut être lent pour des grands nombres. K n u t h a montré que le nombre moyen de divisions pour cet algorithme est donné par : 0,843 x log2(rt) + 1,47.
Calcul de coefficients L’algorithme d’EucilDE peut aussi être utilisé pour résoudre la classe de problèmes suivante. Etant donné un tableau de m variables xi,X 2 ,—,xm, trouver un tableau de m coefficients Wi,U2 ,...,um, tel que: m x
x xm — 1.
Petit théorème de Fermât Si m est premier, et a n’est pas un multiple de m, alors le p e t i t t h é o r è m e d e indique que: c/m- 1 _ j (mod m).
F e r m â t 11
Fonction d’Euler Il y a une autre méthode pour calculer l’inverse d ’un nombre modulo n mais il n’est pas toujours possible de l’appliquer. L ’ e n s e m b l e r e s t r e i n t d e s r é s i d u s modulo n est l’ensemble des résidus premiers par rapport à n (cet ensemble est un sous-ensemble de 11. Pierre de Fermât, m athém aticien français, a vécu de 1601 à 1665 C e théorèm e n ’ a rien à voir avec son dernier théorème.
264
Chapitre 11
Rudiments mathématiques
l’ensemble de tous les résidus modulo n défini précédemment). Par exemple, l’ensemble restreint des résidus modulo 12 est {1,5,7,11}. Si n est premier, alors l’ensemble res treint des résidus est l’ensemble de tous les nombres entre 1 et n — 1. Le nombre 0 ne fait jamais partie de l’ensemble restreint des résidus. La fonction d’Euler12 de n (parfois appelée indicateur d’Euler de n) est le nombre d’éléments (« le cardinal ») de l’ensemble restreint des résidus modulo n. Cette fonction est notée :
Par exemple, quel est l’inverse de 5 modulo 7? Comme 7 est premier,
Par l’algorithme d ’ E üC LlD E , on a : x = (b x (a-1 mod n)) mod n.
En général, l’algorithme d ’EucLiDE est une méthode plus rapide pour calculer les inverses modulo n, plus particulièrement pour des nombres d ’environ 500 bits. Si pgcd(a,n) / 1, tout n’est pas perdu. Dans le cas général, (a x x) mod n = b peut avoir des solutions multiples ou pas de solution du tout.
Théorème du reste chinois Si vous connaissez la décomposition en facteurs premiers de n, alors vous pouvez utiliser le théorème du reste chinois pour résoudre un système d’équations particulier. La version de base du théorème a été découverte au premier siècle de notre ère par le mathématicien chinois S u n T s e . 12. Leonhard E uler est un m athém aticien suisse qui vécu t de 1707 à 1783.
11.3
265
Théorie des nombres
En général, si la décomposition en facteurs premiers de n est n = pi x 'P'2. x ... x r , alors le système d ’équations : ( x mod p,) = ai, pour i = l,2,...,t admet une solution unique x, telle que x soit inférieur à n. Certains nombres premiers peuvent apparaître plusieurs fois dans le produit. Par exemple, pi peut être égal à p 2 . Ainsi, pour a et 6 quelconques tels que a < p et b < q (p et q premiers), il existe un seul x tel que x soit inférieur à p x q et tel que : x = a (mod p), et x = b (mod q).
Pour calculer ce x, on utilise l’algorithme d’EucLlDE pour calculer u tel que: u x q= 1
(mod p)
et ensuite on calcule : x = (((a — b) x u) mod p) x q + b.
Voici le théorème du reste chinois codé en C : /*
r e s t l e nombre d ’ élém ents dans l e s tableau x m e t u; me s t l e tab lea u des p a ir e s de modules prem iers en tre eux; u e s t l e tab leau des c o e f f i c i e n t s l e r é s u lt a t e s t n t e l que n == u[k] ‘/. m[k] ( k = 0 . . r - l ) e t n < m [0 ]* m [l]* .. .* m [r -l]
*/ /* l a fo n c t io n d ’ Euler e u le r ( ) e s t la is s é e comme e x e r c ic e au le c t e u r . * / in t r e s t e _ c h in o is (s iz e _ t r , in t *m, in t *u) s iz e _ t i ; in t module; in t n; module = 1; f o r ( i= 0 ; i< r ; ++i) module *= m [ i ] ; n = 0; f o r ( i= 0 ; i< r ; + + i) { n += u [ i ] * m odexp(m odule/m ti], e u l e r ( m [i ] ) , m [ i ] ) ; n '/.= module; } r e t u r n (n ); }
266
Chapitre 11
Rudiments mathématiques
Un corollaire du théorème du reste chinois peut être utilisé pour résoudre un problème similaire : si p et q sont premiers et p est inférieur à q, alors il existe un x unique inférieur à p x q tel que : a = x (mod p), et b = x (mod q).
Si a > b mod p, alors : x — (((a — ( b mod p)) x u) mod p) x q + b.
Si a < b mod p, alors : x — (((a + p — (b mod p)) x u) mod p) x q + b.
Résidus quadratiques Si p est premier et a est inférieur à p, alors a est un r é s i d u q u a d r a t i q u e modulo p si : x 2 = a (mod p), pour un certain x. Une valeur quelconque de a ne satisfait pas forcément cette propriété. Par exemple, si p — 7, les résidus quadratiques sont 1, 2 et 4 : 12 = 1
=
1
22 = 4
ee
4
(mod 7) (mod 7)
32 = 9
=
2
(mod 7)
42 = 16
EE
2
(mod 7)
52 = 2 5
=
4
(mod 7)
62 = 36
=
1
(mod 7).
Remarquez que chaque résidu quadratique apparaît deux fois dans la liste. Il n’existe pas de valeur de x qui satisfasse une des équations : x2
=
3
(mod 7)
x2
=
5
(mod 7)
x2
=
6
(mod 7)
Les nombres 3, 5 et 6 ne sont donc pas des résidus quadratiques modulo 7. Bien que je ne le fasse pas ici, il est aisé de démontrer qu’il y a exactement (p — l ) /2 résidus quadratiques modulo p et (p - l) /2 nombres qui ne sont pas des résidus quadratiques modulo p. De même, si a est un résidu quadratique modulo p, alors a a exactement deux racines carrées: l’une comprise entre 0 et (p — l ) /2 et l’autre entre (p —l ) /2 et (p —1). L ’une de ces racines carrées est aussi un résidu quadratique modulo p ; celle-ci est appelée racine carrée prin cip ale. Si n est le produit de deux nombres premiers, p et q, il y a exactement (p — l)(q — l) /4 résidus quadratiques modulo n. Un résidu quadratique modulo n est un carré parfait modulo n. Par exemple, il y a 6 résidus quadratiques modulo 35: 1, 4, 9, 11, 16, 29. Chacun d ’entre eux a exactement 4 racines carrées.
11.3
Théorie des nombres
2t
Symbole de Legendre Le sy m b o le d e L egen dre, noté13 L(a,p), est défini quand a est un entier quelconqi et p est un nombre premier plus grand que 2. Il vaut 0, 1 ou —1 : L(a,p) =
0
si a est divisible par p.
L(a,p) =
1
si a est un résidu quadratique modulo p.
L(a,p) —
—1
si a n’est pas un résidu quadratique modulo p.
Un moyen simple de calculer L(a,p) est donné par : L(a,p) = o ( 2
mod p.
Un autre moyen de le calculer est donné par les formules récursives suivantes :
1. si a = 1, alors L(a,p) = 1 ; 2. si a est pair, alors L(a,p) — L(a/2,p) x ( —1)(p2-1)/8 ; 3. si a est impair, alors L(a,p) = L(p mod a,a) x (—i ) !0- 1)*!?*-1)/4. Remarquez que c ’est aussi un moyen efficace de déterminer si a est un résidu quadr tique modulo p (seulement quand p est premier, évidemment).
Symbole de Jacobi Le s y m b o l e d e J a c o b i , noté J(a,n) est une généralisation du symbole de L e g e n d r il est défini pour toute paire d’entiers a et n. Cette fonction est utilisée dans les tes de primalité. Le symbole de JACOBI est une fonction de l’ensemble restreint des résid des facteurs de n. Il peut être calculé grâce à différentes formules [1418]. En voici u qui repose sur les définitions suivantes : 1. J(a,n) n’est défini que pour n impair. 2. J(0,n) = 0. 3. Si n est premier, alors J(a,n) = 0 si n divise a. 4. Si n est premier, alors J(a,n) = 1 si a est un résidu quadratique modulo n. 5. Si n est premier, alors J(a,n) — —1 si a n’est pas un résidu quadratique modi n.
6. Si n est un nombre composé, alors J(a,n) = J(a,p i) x ... x J(a,pm), où pi,...,} est la décomposition en facteurs premiers de n. Les règles suivantes permettent de calculer récursivement le symbole de 1. J(l,n) = 1 2. J(a x b,n) = J(a,n) x J(b,n) 13. N ote du traducteur : il est aussi parfois noté
Jacobi :
Chapitre 11
268
3.
Rudiments mathématiques
J(2,n) — 1 si (n2 — l)/8 est pair, — 1 sinon
4 J(a,n) = J((a mod n),n) 5. J{a,pi x p2) = J(a,pi) x J{a,pv) 6. Si pgcd(a,b) = 1 et a et b sont tous deux impairs (la loi de réciprocité n’est pas valable pour les entiers pairs) : 6a. J(a,b) = +J(b,a) si (a — 1)(6 — l)/4 est pair 6b. J(a,b) = —J(b,a) si (a — l)(i> — l)/4 est impair. Voici l’algorithme en C : /* Cet algorithme calcule le symbole de Jacobi récursivement. */ #define estPair(x) (x & 1 == 0) #define estlmpair(x) (x & 1) int Jacobi(int a, int b) { int d; assert(estImpair(b)); if (a >= b) a V.= b; /* Règle 4 */ if (a == 0) retum(O); /* Définition 1 */ if(a == 1) return(l); /* Règle 1 */ if (a < 0) if(estPair((b-1)/2)) re t u m Jacobi(-a,b) ; else return -Jacobi(-a,b); if(estPair(a)) if(estPair((b*b - l)/8>) return +Jacobi(a/2,b); else return -Jacobi(a/2,b);
/* Règles 3 et 2 */
d = pgcd(a,b); assert(estlmpair(a)); /* Ceci est garanti par le test estPair(a) plus haut */ if(d == a) /* a divise b */ return 0; /* Règle 5 */ else if(d != 1) return Jacobi(d.b) * Jacobi(a/d,b); /* Règle 2 */
11.3
269
Théorie des nombres else if(estPair((a-l)*(b-l)/4)) return +Jacobi(b,a); /* Règle 6a */ else return -Jacobi(b,a); /* Règle 6b */
> Si on sait que n est premier, il suffit de calculer a^n~ 1^ 2 mod n au lieu d’exécuter l’algorithme précédent; dans ce cas, J(a,n) est équivalent au symbole de Legendre. Le symbole de Jacobi ne permet pas de déterminer si a est un résidu Si J{a,n) = 1 et n est un nombre composé, a n’est pas forcément un résidu quadratique modulo n. Par exemple : 7(7,143) = J ( 7 ,ll) x 7(7,13) = (—1)(—1) = 1. Toutefois, il n’existe pas de nombre entier tel que x2 = 7 (mod 143).
Entiers de Blum Si p et ç sont deux nombres premiers et qu’ils sont tous les deux congrus à 3 modulo 4, alors n = pq est appelé e n t i e r d e B l u m . Si n est un entier de B l u m , chaque résidu quadratique modulo n a exactement 4 racines carrées. L ’une de ces racines carrées est aussi un carré; c ’est la racine carrée p r i n c i p a l e . Par exemple, la racine carrée principale de 139 modulo 437 est 24. Les trois autres racines carrées sont 185, 252 et 413
Générateurs Si p est premier, et g est plus petit que p, alors g est un g é n é r a t e u r modulo p si : pour chaque b de 1 à p — 1, il existe un certain a tel que ga = 6 (mod p). On dit aussi de façon équivalente, que g est p r i m i t i f par rapport à n. Par exemple, si p = 11, 2 est générateur modulo 11 : 210 = 1 024
--
1
21 = 2
=
2
(mod 11)
(mod 11)
28 = 256
=
3
(mod 11)
22 = 4
4
(mod 11)
24 = 16
s =
5
(mod 11)
29 = 512
=
6
(mod 11)
27 = 128
-
7
(mod 11) (mod 11)
26 = 64
= 8 — 9
25 = 32
::
23 = 8
10
(mod 11) (mod 11)
Tout nombre de 1 à 10 peut être exprimé comme 2“ (mod p). Pour p = 11, les générateurs sont 2, 6, 7 et 8. Les autres nombres ne sont pas géné rateurs. Par exemple, 3 n’est pas un générateur parce qu’il n’y a pas de solution à l’équation : 3a = 2 (mod 11).
Chapitre 11
270
Rudiments mathématiques
En général, trouver un générateur n’est pas un problème facile, sauf si l’on connaît la décomposition en facteurs premiers de p — 1. Soit çi,Ç 2 viÇ n les facteurs premiers de p — 1. Pour déterminer si un nombre, g, est un générateur modulo p, on calcule: g{p- i)/e
(mod p)
pour toutes les valeurs de q = Çi,<72,—,9nSi cette expression vaut 1 pour un certain alors g n’est pas un générateur. S’il n’existe pas de qi tel que cette expression vaille 1, alors g est un générateur modulo p. Par exemple, pour p — 11, les facteurs premiers de p — 1 = 10 sont 2 et 5. Pour tester si 2 est un générateur on calcule : 2 ( n - i ) / 5 m od n
=
4
2( n - i)/2 mod n
_
1Q
Aucun des résultats n’est égal à 1, donc 2 est un générateur. Pour tester si 3 est un générateur on calcule : 3 ( n - i ) / 5 m od n
=
9
3 ( n - i )/2 m o d n
=
L
Comme le dernier résultat est égal à 1, 3 n’est pas un générateur. Si vous avez besoin d ’un générateur modulo p, choisissez tout simplement un nombre au hasard entre 1 et p — 1 et testez si c ’est un générateur. Il y en a un bon nombre, aussi vous en trouverez probablement un rapidement.
Corps de Galois Pas de panique ! Ce titre ne cache rien de terrible. En fait, depuis plusieurs paragraphes, nous effectuons déjà des calculs dans un corps de G a l o i s . Dans le cadre de l’arithmé tique modulo n, si n est premier ou une puissance entière d’un nombre premier, alors nous avons ce que les mathématiciens appellent un co r p s fini. Dans le cas particulier de n premier, nous utiliserons plutôt la lettre p. Ce type de corps fini est tellement important que les mathématiciens lui ont donné le nom de son promoteur : on parlera d’un co rp s d e G a lois et on l’écrira Zjp. Evariste G a l o i s , mathématicien français qui a vécu au début du XIXe siècle, a beaucoup produit dans le domaine de la théorie des nombres avant de mourir à l’âge de 20 ans dans un duel. Dans u n corps de G a l o i s , l’addition, la soustraction, la multiplication et la division sont bien définies. Il existe un élément neutre pour l’addition : 0 et un élément neutre pour la multiplication: 1. Chaque nombre non nul a un inverse unique (cela ne serait pas vrai si p n’était pas premier). Les lois de commutativité, d ’associativité et de distributivité s’appliquent. E n cryptographie, on se sert beaucoup de l’arithmétique dans un corps de G a l o i s . Toute la théorie des nombres s’applique, les nombres gardent une taille finie et il n’y a pas d’erreur d’arrondi pour la division. Nombre de cryptosystèmes sont basés sur Z /p , où p est un nombre premier très grand. Pour compliquer un peu plus les choses, les spécialistes de cryptographie utilisent aussi l’arithmétique modulo des polynômes irréductibles de degré u et à coefficients entiers
11-4
Factorisation
271
modulo q (avec q premier). Ces corps sont notés Z jqn. Tous les calculs sont fait modulo un certain polynôme irréductible de degré n, p(x). La théorie de ces corps est hors du propos de cet ouvrage: malgré cela, je décrirai certains cryptosystèmes qui en font usage. Si vous voulez jouer un peu avec ces corps, Z / 23 a pour éléments : 0 , 1 , x, x + 1 , x2, x 2 + 1 , x2+ x , x 2 + X + 1 . Ï I existe un algorithme pour calculer des inverses dans Z /2 n dont on peut faire mie réalisation sur machine parallèle [423]. Quand on parle de polynômes, le terme « premier » est souvent replacé par le terme « irréductible » . Un polynôme est dit irréductible s’il ne peut pas être exprimé comme le produit de deux autres polynômes (différents de 1 et de lui-même). Le polynôme x 2 + 1 est irréductible sur les entiers. Par contre, le polynôme x z + 2x2 -f x est réductible : il est équivalent au produit x(x + l)(a: + 1). On appelle primitif un polynôme qui est générateur dans un corps donné; tous ses co efficients sont premiers entre eux. Nous reparlerons de polynômes primitifs à l’occasion des générateurs de nombres pseudo-aléatoires (voir § 16.2). Les calculs dans 2 /2 ” peuvent être rapidement réalisés matériellement grâce à des registres à décalage linéaire à rétroaction. Pour cette raison, les calculs dans Z j2 n sont souvent plus rapides que dans 2 /p . Tout comme l’exponentiation peut être réalisée de manière très efficace dans Z j 2” , il en est de même du logarithme discret [187, 188, 372, 383]. Si vous voulez en apprendre plus consultez [147]. Pour le corps de G a lo is 2 /2 ” , les spécialistes de cryptographie aiment utiliser le trinôme p(x) = x n + x + 1 comme module car la longue série de coefficients nuls entre xn et x rendent la réalisation de la multiplication très efficace [190], Le trinôme doit être primitif, sinon cela ne fonctionne pas. Pour n inférieur à 1000, le trinôme x n + x + 1 est primitif [1651, 1650] si n vaut : 1,3,4,6,9,15,22,28,30,46,60,63,127,153,172,303,471,532,865,900. Il existe une réalisation matérielle de Z /2 127 avec p(x) — x ’ 27 + x + 1 [1633,1634,1136]. L’article [154] décrit des architectures matérielles efficaces pour réaliser l’exponentia tion dans 2 /2 ” .
11.4
Factorisation
Factoriser un nombre signifie trouver ses facteurs premiers : 10 = 2 x 5 60 = 2 x 2 x 3 x 5 252 601 = 41 x 61 x 101 2113 - 1 = 3 391 x 23 279 x 65 993 x 1868 569 x 1066 818132 868 207 Le problème de la factorisation est l’un des plus vieux de la théorie des nombres. Il est facile de factoriser un nombre mais c ’est coûteux en temps. Toutefois, il y a eu des avancées dans l’état de l’art. Actuellement, le meilleur algorithme de factorisation est : Le c r i b l e s u r c o r p s n u m é r i q u e (NFS pour « Number Field Sieve ») [962] (voir aussi [964, 20, 283]). Le c r i b l e g é n é r a l s u r c o r p s n u m é r i q u e est
272
Chapitre tl
Rudiments mathématiques
la méthode de factorisation la plus rapide connue pour des nombres de plus de 110 chiffres environ [504, 637). Elle n’était pas efficace au moment où elle a été proposée pour la première fois, mais cela a changé depuis grâce à une série d ’améliorations survenues ces dernières années. Le crible sur corps numérique est encore trop nouveau pour avoir permis d ’établir des records de factorisation, mais cela viendra bientôt. Le NFS a été utilisé pour factoriser le neuvième nombre de F E R M A T : 2512 + 1 [966, 965]. Il existe d ’autres algorithmes de factorisation, mais ils ont été supplantés par le crible sur corps numérique : Le crib le q u a d ra tiqu e [1267, 1619,1269]. C ’est l’algorithme le plus rapide connu pour des nombres de moins de 110 chiffres et il a été très utilisé [442]. Une version plus rapide de cet algorithme est appelée crible quadratique multipolynomial [1459, 304]. La version la plus rapide de cet algorithme est appelée variante à deux grands facteurs premiers du crible quadratique multipolynomial. M é th o d e des co u r b e s ellip tiq u es (E C M pour « Elliptic Curve Method ») [968, 1118, 1119]. Cette méthode a été utilisée pour trouver des facteurs de 43 chiffres décimaux mais rien de plus grand. A lg o rith m e M o n te -C a r lo d e P o lla rd [1264, 252]. Cet algorithme ap paraît également dans le volume 2, page 370 de l’ouvrage de K n u th [864], A lg o rith m e des fra ction s continues. Voyez [1129, 1262, 864]. Cet algo rithme n’est même pas dans la course. T en tativ e d e division . C ’est le plus vieil algorithme de factorisation: il consiste à tester tous les nombres premiers jusqu’à la racine carrée du nombre à factoriser. Voyez [255] pour une bonne introduction à ces différents algorithmes de factorisation, excepté pour le crible sur corps numérique. La meilleur présentation du crible sur corps numérique se trouve dans [962]. Des références plus anciennes sont [502, 1604, 1268]. Des informations sur la factorisation parallèle peuvent être trouvées dans [253]. Si n est le nombre à factoriser, la variante la plus rapide du crible quadratique nécessite un nombre d’opérations équivalent à : e (l+ 0 (l))(ln «)*(ln (ln n ))i
Le crible sur corps numérique est plus rapide avec un temps heuristique asymptotique estimé de : (l,9 2 3 + 0 (l))(ln n )4 (ln (ln n ))§
En 1970, la factorisation d ’un nombre « difficile » de 41 chiffres était à la une des jour naux [1129] 14. Dix ans après, factoriser des nombres difficiles de taille double prenait quelques heures de calcul sur un ordinateur CRAY [442]. En 1988, Cari P o M E R A N C E a conçu une machine à factoriser modulaire en utilisant des puces VLSI sur mesure [1269]. La taille du nombre que vous pouvez factoriser dépend 14. Un nom bre « difficile » est un nom bre qui n ’a pas de petits facteurs et qui n ’ a pas une forme spéciale qui perm et de le factoriser plus facilement.
11.4
Factorisation
273
de la taille de la machine que vous pouvez vous permettre de construire. Il ne l’a jamais construite. En 1993, un nombre difficile de 120 chiffres a été factorié grâce au crible quadratique; le calcul a demandé l’équivalent de 825 millions d ’instructions par seconde pendant un an (mips-an en abrégé) et fut mené en trois mois de temps réel [469] D ’autres résultats se trouvent dans [501]. Aujourd’hui, la factorisation tend à utiliser les réseaux d ’ordinateurs [304, 966]. En factorisant un nombre de 116 chiffres, Arjen L E N S T R A et Mark M A N A S S E utilisèrent 400 mips-an, le temps d ’inaction d ’une batterie d ’ordinateurs tout autour du monde pendant quelques mois. En mars 1994, une équipe de mathématiciens menée par L e n s t r a a factorisé un nombre de 129 chiffres (428 bits) grâce à la variante du crible quadratique multi polynomial [71]. Des volontaires sur Internet ont mené à bien le calcul: 600 personnes et 1600 machines durant huit mois, probablement le plus grand multi-processeur ad hoc jamais assemblé. Le calcul a demandé l’équivalent de 4000 à 6000 mips-an. Les ma chines communiquaient par courrier électronique, envoyant leurs résultats individuels à un central qui s’est occupé de l’étape finale de l’analyse. Ce calcul était basé sur le crible quadratique et des théories vieilles de cinq sms; un dixième du temps de calcul aurait suffit avec le crible sur corps numérique [960]. Selon [71] : « Nous en concluons que les nombres de 512 bits courament utilisés pour R SA sont vulnérables face à n’im porte quelle organisation prête à dépenser quelques millions de dollars et à attendre quelques mois. » Ils estiment que factoriser un nombre de 512 bits demande 100 fois plus de travail avec les mêmes moyens et 10 fois plus en utilisant le crible sur corps numérique et la technologie actuelle [960]. Pour rester au courant de l’art de factoriser, R SA D a t a S e c u r i t y a instauré en mars 1991 un concours de factorisation ( le « RSA Factoring Challenge * ) [534]. Il s’agit d’une liste de nombres difficiles, chacun étant le produit de deux nombres premiers de tailles comparables. Chaque nombre premier est congru à 2 modulo 3. Il y a 42 nombres dans le concours; leur taille va croissante de 100 chiffres à 500 chiffres de 10 en 10 (plus un nombre de 129 chiffres). Au moment d ’écrire ces lignes, RSA-100, RSA-110, RSA-120 et RSA-129 ont étés factorisés, tous grâce au crible quadratique. RSA-130 pourrait être le prochain (en utilisant le crible sur corps numérique), ou les champions de factorisation pourraient bien sauter directement à RSA-140 C’est un domaine qui évolue vite. Il est difficile d ’extrapoler les progrès de la technologie de la factorisation car personne ne peut prédire les avancées mathématiques. Avant que le crible sur corps numérique ne soit découvert, de nombreuses personnes ont conjecturé que le crible quadratique était asymptotiquement aussi rapide que toute autre méthode de factorisation pourrait l’être. Ils avaient tort. Des progrès à court terme dans le crible sur corps numérique pourraient aller dans le sens d’abaisser la constante : 1.923. Pour certains nombres de forme spéciale, comme les nombres de F e r m â t, la constante avoisine plutôt 1.5 [966, 965]. Si c ’était le cas pour les nombres difficiles utilisés en cryptographie à clef publique, les nombres de 1024 bits pourraient être factorisés aujourd’hui. Une façcon d ’abaisser la constante consiste à trouver de meilleurs moyens de représenter les nombres par des polynômes à petits coefficients. Le problème n’a pas encore été étudié en profondeur, mais des avancées vont probablement arriver [960].
Chapitre 11
Rudiments mathématiques
Pour obtenir les résultats les plus récents du concours de factorisation, envoyez un courrier électronique à ch a lle n g e -in fo @ rsa .com .
Racines carrées modulo n Si n est le produit de deux nombres premiers, alors la possibilité de calculer des racines modulo n demande une puissance de calcul équivalente à celle nécessaire pour factoriser n [1294, 36, 37, 200]. En d’autres termes, celui qui connaît les facteurs premiers de n peut facilement calculer les racines carrées d ’un nombre modulo n, mais pour tous les autres le calcul est prouvé être aussi difficile que pour calculer les facteurs premiers de n.
11.5
Génération de nombres premiers
La cryptographie à clef publique a besoin de nombres premiers. Tout réseau de taille raisonnable en demande un grand nombre. Avant de présenter les mathématiques sousjacentes à la génération de nombre premiers, je vais répondre à quelques questions évidentes : 1. Si tous le monde a besoin d’un nombre premier différent, ne va-t-on pas tomber à court? Non, le père Noël ne tombera jamais à court de nombres premiers pour tous les petits garçons et toutes les petites filles sages. En fait, il y a plus de 10151 nombres premiers de 512 bits de long ou m oins15. Il y a 1084 d ’atomes dans l’univers. Si chaque atome de l’univers avait besoin d ’un milliard de nombres premiers chaque microseconde depuis l’origine des temps jusqu’à maintenant, il faudrait 10116 nombres premiers; il en resterait encore approximativement 10151. 2. Que se passe-t-il si deux personnes choisissent par accident le même nombre premier? Avec un choix de plus de 10151 nombres premiers, les chances que cela arrive sont inférieures aux chances que l’ordinateur se consume spontanément au moment précis où vous gagnez à la loterie. Cela ne vaut pas la peine de s’en préoccuper. 3. Si quelqu’un créé une base de donnée contenant tous les nombres premiers, pourra-t-il s’en servir pour casser les algorithmes à clef publique? Oui, mais il ne peut pas la créer. Si vous disposiez de disques de un gigaoctets pesant un gramme, alors la liste des nombres premiers de 512 bits serait si lourde qu’elle dépasserait la limite de Chandrasar et imploserait pour se transformer en trou noir... ainsi, vous ne pourriez pas en retirer de données de toute manière. Si la factorisation d ’un nombre est si difficile, comment peut-il être facile de générer un nombre premier? L’astuce vient de ce que répondre par oui ou par non à la question « Est-ce que n est premier? » est bien plus facile que de répondre à la question plus compliquée « Quels sont les facteurs premiers de n ? » Générer des nombres aléatoires, puis essayer de les factoriser est une mauvaise méthode de génération de nombres premiers. La méthode appropriée consiste à générer des 15. Pour des nom bres de taille N , la probabilité q u ’un nom bre aléatoire soit premier est approxim a tivement de 1 pou r ln 2 .IV-
11.5
Génération de nombres premiers
275
nombres aléatoires et tester s’ils sont premiers. Il existe plusieurs tests probabilistes de primalité, ce sont des tests qui permettent de déterminer si un nombre est premier avec un certain niveau de confiance. En supposant que ce « niveau de confiance » est suffisant, ce type de tests est assez bon. J’ai entendu appeler les nombres ainsi produits « nombres premiers de type industriel » : ce sont des nombres probablement premiers avec une faible chance d’erreur contrôlable. Supposons qu’un test soit mis au point pour échouer une fois sur 250. Cela veut dire qu’il y a une chance sur 1015 pour que le test affirme à tort qu’un nombre composé est premier16. Si pour certaines raisons vous avez besoin de plus de certitude dans la primalité du nombre, vous pouvez faire descendre le taux d ’erreur plus bas encore. Par contre, si vous considérez que les chances d ’obtenir un nombre composé sont 300 millions de fois plus faibles que celles de gagner à la loterie nationale, peut-être que vous ne vous inquiéterez pas trop. Une présentation générale des développements dans le sujet se trouve dans [1266, 210]. D’autres articles importants sont [1497, 388, 15, 23, 628, 654, 912].
Solovay—Strassen S o l o v a y et S t r a s s e n ont développé un algorithme probabiliste de test de prima lité [1497]. Cet algorithme utilise le symbole de JACOBI pour tester si p est premier:
1. Choisissez un nombre aléatoire a inférieur à p. 2. Si le pgcd(a,p) ^ 1; alors p échoue au test et il est composé. 3. Calculez j — a^p~ 1^ 2 mod p. 4. Ca lcu lez le sym bole de JACO BI J(a,p).
5. Si j ^ J(a,p), alors p n’est certainement pas premier. 6. Si j — J(a,p), alors la probabilité que p ne soit pas premier est au plus de 50 %. Un nombre a qui permet d ’affirmer que p n’est certainement pas premier s’appelle un tém oin. Si p est composé, il y a au moins 50 % de chances pour qu’un nombre a aléatoire soit un témoin. Répétez ce test t fois avec t valeurs différentes aléatoires pour a. Un nombre composé à une chance sur 2* de passer les t tests.
Lehmann Un autre test, plus simple, a été développé indépendamment par L e h m a n n [956]. Voici l’algorithme pour tester si t est premier : 1. Choisissez un nombre aléatoire a inférieur à p. 2. Calculez a^p_1^ 2 mod p. 3. Si a^p 'U /2
lou — 1 (mod p) pour tous les i, alors p n’est pas premier.
4. Si a(p-1) / 2 = 1 ou —1 (mod p) alors la probabilité que p soit composé est de 50 % au plus. 16. Le test n’ indiquera jam ais à tort qu ’ un n om bre est com posé.
Chapitre 11
276
Rudiments mathématiques
À nouveau, un nombre aléatoire a a au moins 50 % de chances d ’être un témoin. Répétez le test t fois. Si le calcul vaut 1 ou —1, mais pas toujours 1, alors p est probablement premier avec un taux d ’erreur de 1 sur 2e.
Rabin—Miller L’algorithme que tout le monde utilise— il est facile— a été développé par R a b i n , en partie à partir des idées de M i l l e r [1099, 1295]. En fait, c ’est une version simplifiée de l’algorithme recommandé par la proposition pour le DSS du N IST [1176, 1174]. Choisissez d ’abord un nombre aléatoire p à tester. Calculez b, où b est le nombre de fois que 2 divise p — 1 (c’est-à-dire que 2b est la plus grande puissance de 2 qui divise p — 1). Ensuite calculez m tel que p = 1 + 2bm. 1. Choisissez un nombre aléatoire a inférieur à p. 2. Posez j = 0 et z = am mod p. 3. Si z = 1 ou si z = p — 1, alors p passe le test et peut être premier. 4. Si
j
> 0 et z = 1, alors p n’est pas premier.
5. Posez j ~ j + 1. Si j < b et z ^ p — 1, posez z = z2 mod p et retournez à l’étape (4). Si z = p — 1, alors p passe le test et peut être premier. 6. Si j = b et z ^ p — 1, alors p n’est pas premier. Les chances d ’un nombre composé de passer ce test décroissent plus vite qu’avec les algorithmes précédents. Trois quarts des valeurs possibles de a sont à coup sûr des témoins. Cela veut dire qu’un nombre composé passera le test moins d ’une fois sur 4f, où t est le nombre d’itérations. En réalités, ces estimations sont très pessimistes. Pour la plupart des nombres aléatoires, environ 99,9 % des valeurs possibles de a sont des témoins [103]. Il existe même de meilleures estimations [420]. Pour des candidats de n bits (où n est supérieur à 100), les chances d ’erreur sur un test sont de 1 sur A n 2 ' ^ 2. Et pour un candidat de 256 bits, les chances d ’erreurs après six tests sont inférieures à une sur 251. Vous trouverez plus de théorie dans [421],
Considérations pratiques Dans les réalisations du monde courant, la génération de nombres premiers est rapide. 1. Générez un nombre aléatoire p de n bits. 2. Mettez le bit de poids fort et le bit de poids faible à 1 17. 3. Vérifiez par prudence que p n’est pas divisible par les petits nombres premiers : 3, 5, 7, 11, etc. De nombreuses réalisations testent la divisibilité de p par tous les nombres premiers inférieurs à 256. Le plus efficace est de tester la divisibilité par tous les nombres premiers inférieurs à 2000. Vous pouvez faire cela efficacement avec une roue [864]. 17. Le bit de poids fort assure que p a la longueur requise et le bit d e poids faible assure que p est impair.
11.5
Génération de nombres premiers
4. Effectuez le test générez un autre petite de a pour échoue à l’un des
277
de
R a b i n —M i l l e r pour un a aléatoire. Si p réussit le test, a aléatoire et faites le test à nouveau. Choisissez une valeur rendre les calculs plus rapides. Faites cinq tests [654]18. Si p tests, générez un autre p et essayez encore.
Une autre option consiste à ne pas générer p au hasard mais à essayer les uns après les autres tous les nombres à partir d ’un point aléatoire jusqu’à trouver un nombre premier. L’étape 3 est optionnelle, mais c ’est une bonne idée. Tester si un nombre p impair aléatoire est divisible par 3, 5 et 7 permet d’éliminer 54 % des nombres impairs avant d’arriver à l’étape 4. Tester avec tous les nombres premiers inférieurs à 100 permet d’éliminer 76 % des nombres impairs; tester avec tous les nombres premiers inférieurs à 256 permet d’éliminer 80 % des nombres impairs. En général, la part de nombre impairs qui ne sont multiples d’aucun nombre premier inférieur à n est de 1.12/ km . Plus vous prenez n grand, plus cela requiert de pré-calcul avant d ’arriver au test de R
a b in
-M
il l e r
.
Une réalisation de cette méthode sur une Sparc II était capable de trouver des nombres premiers de 256 bits en un temps moyen de 2,8 secondes, des nombres premiers de 512 bits en un temps moyen de 24,0 secondes, des nombres premiers de 768 bits en un temps moyen de 2 minutes, des nombres premiers de 1024 bits en un temps moyen de 5,1 minutes [929].
Nombres premiers forts Si n est le produit de deux nombres premiers p et q, il peut être désirable d’utiliser des n om b res p rem iers forts pour p et q. Ce sont des nombres qui ont certaines propriétés qui rendent leur produit n difficile à factoriser par des méthodes spécifiques. Voici quelques propriétés parmi celles qui ont été suggérées [1339, 654] : Le plus grand commun diviseur de p — 1 et q — 1 doit être petit. p — 1 et q — 1 doivent tous deux avoir des grands facteurs premiers, respec tivement p' et q1. p' — 1 et 4 — 1 doivent tous deux avoir des grands facteurs premiers. (p — l ) /2 et (q — l ) /2 doivent tous deux être premiers [189]. (Notez que si cette condition est vérifiée, alors les deux premières le sont aussi.)
La question de savoir si des nombres premiers forts sont nécessaires est sujette à débat. Ces propriétés ont été développées pour empêcher certains algorithmes de factorisation. Toutefois, les algorithmes de factorisation les plus rapides ont autant de chances de factoriser des nombres qui satisfont ces critères que ceux qui ne les satisfont pas [832]. Je recommande de ne pas générer spécifiquement des nombres premiers forts. La taille des nombres premiers est bien plus importante que leur structure. De plus les exigences de structure peuvent être néfastes car elles vont à l’encontre du caractère aléatoire. Cela peut changer. De nouveaux algorithmes de factorisation peuvent être découverts qui marchent mieux avec des nombres ayant certaines propriétés qu’avec ceux qui n’en jouissent pas. S’il en est ainsi, des nombres premiers forts seront peut-être à nouveau 18. Un suffit peut-être mais faites en cinq.
Chapitre 11
278
Rudiments mathématiques
nécessaires. Vérifiez votre journal de mathématiques théoriques local pour les dernières nouvelles.
11.6
Logarithmes discrets dans un corps fini
L ’exponentiation modulaire est une autre fonction à sens unique fréquemment utilisée en cryptographie. Evaluer l’expression suivante est facile : ax mod n.
Le problème inverse de l’exponentiation modulaire est celui de la recherche du loga rithme discret d ’un nombre. C ’est un problème difficile. Trouver un x tel que ax = b (mod n). Par exemple : Si 3X mod 17 = 15, alors x = 6. Les logarithmes discrets n’ont pas tous des solutions (rappelez-vous que les seules solutions valides sont entières). Il est facile de voir qu’il n’y a pas de solution x pour l’équation : 3X mod 13 = 7. Il est encore plus difficile de résoudre ces problèmes pour des nombres de 1024 bits.
Calcul de logarithmes discrets dans un groupe fini Il y a trois groupes principaux dont les logarithmes discrets sont intéressants pour les cryptographes : - le
groupe multiplicatif des corps premiers: Z /p ;
- le
groupe multiplicatif des corps finis de caractéristique 2: Z / 2" ;
- le
groupe des courbes elliptiques sur des corps finis F : E C (F ).
La sécurité de nombreux algorithmes à clef publique est basée sur le problème de la détermination des logarithmes discrets, et donc le problème est étudié intensivement. Un bon aperçu condensé du problème et des meilleures solutions à l’époque peut être trouvé dans [1194, 1047]. Le meilleur article à jour sur le sujet est [945]. Si p, lemodule, est premier, alors la complexité du calcul des logarithmes discrets dans Z /p est essentiellement la même que celle de la factorisation d ’unnombre n d’à peu près la même taille où n est le produit de deux nombres premiers de tailles comparables [1383, 945]. C ’est-à-dire : e ( l +
0(l))(ln
n ) i (ln(ln
n) ) i
11.6
Logarithmes discrets dans un corps fini
279
Le crible sur corps numérique est plus rapide avec son estimation asymptotique heu ristique du temps de calcul : e (l,9 2 3 + 0 (l))(ln n)3 (ln(ln n ))§
Stephen POHLtG et Martin H e llm a n ont trouvé un moyen rapide de calculer des logarithmes discrets dans Z j p si p - 1 n’a que des petits facteurs premiers [1263]. Pour cette raison, seuls les corps tels que p — 1 a au moins un grand facteur premier sont utilisés en cryptographie. Un autre algorithme [18] calcule les logarithmes discrets à une vitesse comparable à la factorisation ; il a été ensuite étendu aux corps de la formes Z / p n [716]. Cet algorithme a été critiqué [729] car il a certains défauts théoriques. D’autres articles [1590] montrent combien le problème est effectivement difficile. Le calcul de logarithme discret est intimement lié à la factorisation. Si vous savez calculer le logarithme discret, alors vous savez factoriser19. Actuellement, il y a trois méthodes de calcul de logarithmes discrets dans un corps premier [374, 945, 650] : le crible linéaire, le schéma d ’entiers de Gauss et le crible sur corps numérique. Le plus gros des calculs préliminaires ne doit être effectué qu’une fois pour chaque corps. Après cela, des logarithmes donnés peuvent être rapidement calculés. C’est un défaut de sécurité pour les systèmes basés sur ces corps. Il est important que différents utilisateurs utilisent des corps premiers différents. Des utilisateurs de la même application peuvent cependant utiliser le même corps premier. Le monde des corps polynomiaux, Z j 2", n’a pas été ignoré par les chercheurs. Un algorithme heuristique a été proposé dans [729]. L’algorithme de C O P P E R S M IT H rend raisonnable la recherche des logarithmes discrets dans des corps tels que Z j 2127 et possible la recherche dans Z j 2400 [372], Cela est basé sur les travaux de [187]. L’étape de précalcul est énorme, mais sinon c’est élégant et efficace. Une réalisation pratique avec une version nettement moins efficace du même algorithme, après une période de précalcul de 7 heures, trouve des logarithmes discrets dans Z j 2127 en quelques secondes chacun [1137, 794]20. Plus récemment, les précalculs pour Z j 2227, Z / 2 313 et Z j 2401 ont été terminés et des progrès significatifs ont été faits pour Z j 2503. Ces calculs sont exécutés sur un ordinateur massivement parallèle n C u b e -2 avec 1024 processeurs [651, 652], Calculer des logarithmes discrets dans Z j 2593 est encore hors de portée. Tout comme pour les logarithmes discrets dans un corps premier, les précalculs néces saires pour calculer des logarithmes discrets dans un corps polynomial ne doivent être faits qu’une fois. E l G a m a l [522] donne un algorithme pour calculer des logarithmes discrets dans le corps Z j p 2 .
19. L’inverse n’ a jam ais été prouvé. 20. C e corps particulier fut utilisé dans quelques cryptosystèm es [146, 1633, 1634], il n ’est pas sûr.
Chapitre 12
Le DES 12.1
Historique
Le DES (pour « Data Encryption Standard »), aussi connu sous le nom D E A pour la norme ANSI (pour « Data Encryption Algorithm ») et D E A -1 pour la norme ISO, est un standard mondial depuis plus de 20 ans. Bien qu’il montre des signes de vieillesse, il a remarquablement bien résisté à des années de cryptanalyse et il est toujours sur contre tous les adversaires, excepté peut-être contre les plus puissants.
Développement du standard Au début des années 70, la recherche cryptographique non militaire était faite au petit bonheur. Il n’y avait quasiment aucune publication dans le domaine. Beaucoup de gens savaient que les militaires utilisaient des équipements de codages spéciaux pour communiquer, mais peu d’entre eux comprenaient la science de la cryptographie. L’Agence nationale de sécurité américaine (N SA pour « National Security Agency ») avait une expérience considérable mais son existence n’était même pas publiquement admise. Les acheteurs ignoraient ce qu’ils achetaient. Quelques petites compagnies concevaient et vendaient des équipements cryptographiques, principalement pour les gouverne ments hors Etats-Unis. Ils étaient tous différents ; aucun de ces dispositifs ne pouvait communiquer avec un autre. Et personne ne savait s’ils étaient vraiment sûrs ou pas ; il n’existait pas d’instance indépendante pour certifier leur niveau de sécurité, et ceux qui achetaient des équipements cryptographiques ne savaient pas vraiment ce qu’ils achetaient. Un rapport gouvernemental rapporta [443] : « Les implications profondes du lien entre les différentes variantes de méca nismes de clefs, ainsi que les principes de fonctionnement et la force réelle des équipements de chiffrement et déchiffrement étaient, et sont encore, virtuellement inconnus de presque tous les acheteurs, et il est très difficile de faire des choix bien informés quant au type d’équipement — en-ligne, hors-ligne, génération de clef, etc. —- qui satisfassent les besoins en sécurité des acheteurs. »
282
Chapitre 12
Le D E S
En 1972, le Bureau national des standards américain (NBS pour « National Bureau of Standards »), maintenant dénommé l’Institut national des standards et de la technologie (N IST pour « National Instïtute of Standards and Technology »), a lancé un programme pour protéger les ordinateurs et les communications de données. Un des objectifs ce programme consistait à développer un algorithme standard de cryptographie unique qui puisse protéger les données numériques durant leur transmission et leur stockage. Cet algorithme unique serait testé et certifié, et il permettrait à différents équipements cryptographiques d’interagir. Il serait moins cher à réaliser et aisément disponible Dans le numéro du 15 mai 1973 du « Fédéral Register », le NBS faisait un appel d’offres public pour un algorithme standard de cryptographie, qui spécifiait un ensemble de critères de conception de l’algorithme : - il devait fournir un niveau de sécurité élevé ; - il devait être complètement spécifié et facilement compréhensible ; - sa sécurité devait être liée à la clef ; et ne devait pas dépendre de la confidentialité de l’algorithme ; - il devait être disponible à tous les utilisateurs ; - il devait être adaptable à diverses applications ; - il devait pouvoir être réalisé de façon économiquement rentable dans des dispo sitifs électroniques ; - il devait être efficace ; - il devait pouvoir être validé ; - il devait être exportable. La réponse du public indiqua qu’il existait une demande très forte pour un standard de cryptographie, mais qu’il y avait très peu d’expertise dans ce domaine. Certains mathématiciens ont envoyé des squelettes d ’algorithmes assez sommaires. Aucune des soumissions ne satisfaisait les critères énumérés ci-dessus. Le NBS émit un deuxième appel d ’offres dans le numéro du 27 août 1974 du « Fédéral Register » . Finalement, ils obtinrent un candidat prometteur basé sur un algorithme développé par IBM au début des années 70, appelé L u c i f e r (voir § 13.1). Une équipe d’IBM travaillait sur la cryptographie à la fois à Kinston et à Yorktown Heights; elle était constituée entre autres de Roy A d l e r , Don C o p p e r s m i t h , Horst F E IS T E L , Edna G r o s s m a n , Alan K o n h e i m , Cari M e y e r , Bill N o t z , Lynn S m i t h , Walt T u c h m a n et Bryant T u c k e r m a n . L’algorithme, bien que complexe, était sans détours. Il n’utilisait que des opérations logiques simples sur des petits groupes de bits et pouvait être réalisé de manière rela tivement efficace en matériel et en logiciel. Le NBS demanda le concours de la NSA pour évaluer le niveau de sécurité de cet al gorithme et pour déterminer son adéquation comme standard fédéral. IBM avait déjà déposé un brevet pour cet algorithme [516], mais était prêt à céder la propriété intellec tuelle en vue de sa fabrication, de sa réalisation et de son utilisation. Le NBS travailla
12.1
Historique
283
sur les termes de cet accord avec IBM et obtint finalement une licence non exclusive et gratuite de fabriquer, utiliser et vendre des dispositifs appliquant cet algorithme. Finalement, dans le numéro du 17 mars 1975 du « Fédéral Register », le NBS publiait à la fois les détails de l’algorithme et la déclaration d’IB M d’octroi d ’une licence non exclusive et gratuite [538]. Un autre avis publié dans le numéro du 1er août 1975 du « Fédéral Register » faisait appel aux commentaires des agences nationales et du public en général. Et il y eut de nombreux commentaires [722, 495, 1126]. De nombreux cryptographes voyaient d’un mauvais œil la « main invisible de la N SA dans le développement de cet algorithme. Ils craignaient que la N SA ait pu modifier l’algorithme pour y introduire une brèche secrète. Ils protestèrent contre le fait que la NSA avait réduit à 56 bits la longueur de clef qui était de 128 bits originellement (voir § 13.1). Le raisonnement sous-jacent aux choix faits dans la conception du DES devint clair au début des années 90, mais dans les années 70 cela semblait mystérieux et inquiétant. En 1976, le NBS organisa deux ateliers pour évaluer la proposition de standard. Le premier atelier s’intéressa aux mathématiques de l’algorithme et à l’existence possible d’une brèche secrète [1199]. Le second atelier s’intéressa à la possibilité d ’augmenter la longueur de clef [232]. Les concepteurs, les évaluateurs, les réalisateurs, les vendeurs, les utilisateurs et les critiques furent invités. A tout point de vue, les ateliers furent animés [1124]. En dépit des critiques, le DES fut adopté au niveau fédéral le 23 novembre 1976 [232] et son utilisation autorisée pour les communications gouvernementales non classées secrètes. La description officielle du standard, FIPS PU B 46, « Data Encryption Standard » [1153] fut publiée le 15 janvier 1977 et entra en vigueur un mois plus tard. Le FIPS PU B 81, « DES Modes of opération » [1156] en 1980, et le FIPS PU B 74, « Guidelines for Implementing and Using the NBS Data Encryption Standard » [1155] parut en 1981. Le NBS publia également le document FIPS PU B 112 qui spécifie l’utilisation du DES pour le chiffrement de mots de passe [1151] et le FIPS PUB 113, qui spécifie l’utilisation du DES pour l’authentification de données informa tiques [1152]. (FIPS vient de « Fédéral Information Processing Standard », standard fédéral pour le maniement d’informations.)
Adoption du standard L’Institut national américain de standardisation (AN SI pour « American National Standards Institute ») homologua le DES comme standard pour le secteur privé sous la référence ANSI X 3.92 [56]. Us l’appelèrent D E A (pour « Data Encryption Algorithm »). AN SI publia un standard pour les modes d ’opération du D E A sous la référence AN SI X 3.106 [55], qui correspondait au document NBS, et un standard pour le chiffrement avec le DES en réseau AN SI X 3.105 [54]. Deux autres groupes au sein de l’AN SI, représentant respectivement le monde ban caire des opérations aux particuliers et le monde bancaire des grands comptes, ont développé des standards basés sur le DES. Les opérations bancaires aux particuliers concernent les transactions entre les institutions financières et les particuliers, tan dis que les opérations bancaires des grands comptes concernent les transactions entre institutions bancaires. Le groupe de travail « Financial Institution Wholesale Retail Working Group» de l’ANSI a développé un standard pour la gestion et la sécurité des PIN (ANSI
Chapitre 12
Le D ES
X 9.8) [64], ainsi qu’un autre standard basé sur le DES pour l’authentification de messages dans le commerce de détail (A N SI X 9.19) [58]. Le groupe a une ébauche de standard pour la distribution sûre de clefs (AN SI X 9.24) [60]. Le groupe de travail « Financial Institution Wholesale Security Working Group » de l’AN SI a développé ses propres standards pour l’authentification de messages (ANSI X 9 .9) [65], pour la gestion des clefs (A N SI X 9.17) [57, 1171], pour le chiffrement (ANSI X 9.23) [59], et pour l’authentification sûre de personne ou de nœud (ANSI X 9.26) [61]. L ’ « American Bankers Association » développe des standards optionnels pour le monde financier. Ils ont publié un standard recommandant l’utilisation du D ES chaque fois que le chiffrement est nécessaire [5] et un autre pour la gestion des clefs cryptographiques [6]. Avant le « Computer Security Act » de 1987, les services généraux de l’administration américaine (G S A pour « General Services of Administration ») avaient la responsabi lité de la définition des standards de communication fédéraux. Depuis le « Computer Security Act », cette responsabilité a été transférée au NIST. Les G SA publièrent trois standards qui utilisaient le DES : deux concernant les exigences en matière de sécurité en général et de l’interfonctionnement des équipements (F E D E R A L STAN D ARD 1026 [663] et F é d é r a l S t a n d a r d 1027 [664]), et un pour les équipements de télécopie suivant la norme « Groupe 3 » ( F é d é r a l S t a n d a r d 1028 [665]). Le Département du Trésor (« Department of Treasury») a émit une directive afin que tous les messages de transferts de fonds électroniques soient authentifiés par le DES [474, 476] ; il décrivit également les critères que devaient satisfaire tous les équi pements d’authentification [475]. L’Organisation internationale de normalisation (ISO pour « International Organizationfor Standardization ») décida dans un premier temps de soutenir le DES (rebaptisé pour l’occasion D E A -1) comme norme internationale; mais l’ISO décida ensuite de ne pas se mêler de la cryptographie. Toutefois, le groupe de travail « International Wholesale Financial Standards » de l’ISO utilisa le DES dans une norme d ’authen tification internationale [762] et pour la gestion des clefs [765]. DES est aussi spécifié dans un standard financier australien [1197].
Validation et réception d’équipement DES Dans le cadre du DES, le N IST valide les réalisations du DES. Cette validation confirme que la réalisation est conforme au standard. Jusqu’en 1994, le N IST n’a validé que les réalisations en matériel ou en microprogrammation; jusqu’alors, les réalisations logicielles ont été exclues du standard. En mars 95, 73 réalisations différentes avaient été validées. Le N IST a aussi développé un programme certifiant les équipements conformes aux AN SI X 9.9 et FIPS 113. En mars 1995, 33 produits avaient été validés. Le Département du Trésor a une procédure supplémentaire de validation. Le N IST a aussi un programme certifiant qu’un équipement est conforme à AN SI X 9.17 pour la gestion des clefs dans les grands comptes [1171]; en mars 1995, quatre produits avaient été validés.
12.1
Historique
285
1987 Les termes du standard prévoient qu’il peut être revu tous les cinq ans. Dans le numéro du 6 mars 1987 du « Fédéral Register », le NBS faisait un appel aux commentaires concernant l’évaluation de la deuxième tranche de cinq ans. Le NBS soumettait trois choix à l’examen [1487, 1488] : reconduire le standard pour trois ans, le supprimer ou revoir son domaine d ’application. Le NBS et la NSA évaluèrent le standard. La NSA était plus impliquée cette fois-ci. Grâce à une directive de l’exécutif signée par Ronald R e a g a n , appelée N SDD-145, la NSA avait un droit de veto sur le NBS en matière de cryptographie. Tout d ’abord, la NSA annonça qu’elle ne reconduirait pas le standard. Le problème n’était pas que le DES ait été cassé ou même qu’il pût être suspecté d ’avoir été cassé. Il était simplement de plus en plus probable qu’il serait bientôt cassé. A sa place, la NSA proposait le programme « Commercial COMSEC Endorsement » (C C E P ), qui aurait finalement offert une série d ’algorithmes pour remplacer le DES [92]. Ces algorithmes conçus par la N SA ne seraient pas divulgués; une couche protectrice dans les puces VLSI aurait empêché la reconstruction de l’algorithme (voir § 25.1). Cette annonce ne fut pas très bien accueillie. De nombreuses personnes indiquèrent que le DES était très répandu dans le monde des affaires (plus particulièrement le monde financier) et qu’aucune alternative valable n’était disponible. Le retrait du standard aurait laissé de nombreuses organisations sans protection pour leurs données. Après pas mal de débats, le DES fut reconduit comme standard gouvernemental américain jus qu’en 1992 [1154]. D ’après le NBS, le DES ne serait plus reconduit par la suite [1487].
1993 Ne dites jamais « jamais plus ». En 1992, il n’y avait toujours pas d ’alternative au DES. Le NBS, maintenant appelé N IST, sollicita une fois de plus les commentaires dans le « Fédéral Register » [543] : « Le but de cet avis est d’annoncer l’évaluation du bien-fondé de la pour suite de l’utilisation du standard pour protéger des données informatiques. Les commentaires de l’industrie et du public sont souhaités sur les alterna tives suivantes pour le FIPS 46—1. Les coûts (impacts) et les bénéfices de ces alternatives doivent être inclus dans les commentaires : « — Reconduire le standard pour une nouvelle période de cinq (5) ans. L ’Institut national des standards et de la technologie continuerait à valider les équipements qui réalisent le standard. FIPS 4 6 -1 conti nuerait à être la seule méthode approuvée pour protéger des données informatiques non secrètes. « - Retrait du standard. L’Institut national des standards et de la tech nologie ne continuerait pas à valider les équipements qui supportent le standard. Les organisations pourraient continuer à utiliser les équi pements existants qui réalisent le standard. D’autres standards pour raient être émis par le N IST en remplacement du DES.
286
Chapitre 12
Le D E S
« - Revoir les clauses d’application et/ou de réalisation du standard. Cette révision impliquerait toute modification du standard permettant l’uti lisation de réalisations logicielles du DES aussi bien que matérielles ; permettant l’utilisation répétée (itérative) du DES dans certaines ap plications ; permettant l’utilisation d ’autres algorithmes approuvés et enregistrés par le NIST. » La période de commentaire se clôtura le 10 décembre 1992. D ’après une déclaration de Raymond K a m m e r , directeur par intérim du N IST à l’époque [802] : « L ’année dernière, le N IST sollicita formellement les commentaires sur la reconduite du DES. Après analyse de ces commentaires, et d ’autres infor mations techniques que j ’ai reçues, j ’envisage de recommander au Secrétaire du Commerce qu’il reconduise le DES pour une nouvelle période de cinq ans. J’envisage également de suggérer au Secrétaire que, lors de l’annonce de la reconduction, nous affirmions notre intention de lui trouver des alter natives durant les cinq années qui viennent. En mettant cette déclaration sur la table, nous espérons donner aux individus la chance de donner leur opinion sur une transition technique méthodique. En attendant, nous de vons prendre en compte le très grand nombre de systèmes qui utilisent ce standard éprouvé. » Bien que l’Office d ’évaluation technologique américain (« Office of Technology Assesment ») citât les dires de Dennis B r a n s t a d affirmant que la période utile d ’ex ploitation du DES devrait se terminer à la fin des années 90 [1200], l’algorithme fut reconduit pour cinq années supplémentaires [1175]. Les réalisations logicielles de DES furent finalement admises pour être validées. Quelqu’un veut-il essayer de deviner ce qui arrivera en 1998?
12.2
Description du DES
Le DES est un système de chiffrement par blocs; il chiffre les données par blocs de 64 bits. Un bloc de 64 bits du texte en clair entre par un côté de l’algorithme et un bloc de 64 bits du texte chiffré sort de l’autre côté. Le chiffrement et le déchiffrement utilisent tous deux le même algorithme (avec des différences uniquement dans le plan de génération des clefs). La longueur de la clef est de 56 bits. Généralement, la clef est exprimée comme un nombre de 64 bits mais un bit sur huit utilisé comme bit de contrôle de parité est ignoré1. La clef peut être n’importe quel nombre de 56 bits et peut être changée à tout moment. Une poignée de nombres sont des clefs fragiles mais ils peuvent aisément être évités. Toute la sécurité réside dans la clef. Au niveau le plus simple, l’algorithme n ’est rien d ’autre que la combinaison de deux techniques de base du chiffrement : confusion et diffusion. L ’élément constitutif du DES est une seule combinaison de ces techniques (une substitution suivie d ’une permutation) appliquée au texte, basée sur la clef. On parlera alors de ron d e. Le DES a 16 rondes, c ’est-à-dire qu’il applique 16 fois la même combinaison de techniques au bloc de texte en clair (voir la figure 12.1). 1. Ces bits de parité sont les bits de poids faible des octets de la clef.
12.2
Description du DES
287
Texte en clair
çjp
k2
F
ig
.
12.1 - DES
L’algorithme n’utilisant que des opérations arithmétiques et logiques standard sur des nombres d’au maximum 64 bits, il était facile de le réaliser avec la technologie de la fin des années 70. La nature répétitive de l’algorithme le rend idéal pour l’utilisation de puces spécialisées. Les premières réalisations logicielles étaient inélégantes mais les réalisations actuelles sont nettement meilleures.
Plan général de l’algorithme Le DES manipule le texte en clair par blocs de 64 bits. Après une permutation initiale, le bloc est coupé en une partie droite et une partie gauche, chacune d’une longueur de 32 bits. Après cela, il y a 16 rondes d ’opérations identiques, appelées « fonction / », lors desquelles les données sont combinées avec la clef. Après la 16e ronde, les parties droite et gauche sont réassemblées et une permutation finale (l’inverse de la permutation initiale) termine l’algorithme. À chaque ronde (voir figure 12.2), les bits de la clef sont décalés et 48 bits sont alors sélectionnés parmi les 56 bits de la clef. La partie droite des données est étendue à 48 bits par une permutation expansive, combinée avec 48 bits de la clef décalée et permutée par ou exclusif, remplacée par 32 nouveaux bits par un algorithme de substitution et
288
Chapitre 12
Le D E S
permutée une fois de plus. La « fonction / » est constituée de ces quatre opérations. La sortie de la « fonction / » est alors combinée avec la moitié gauche par un ou exclusif. Le résultat de ces opérations devient la nouvelle moitié gauche ; l’ancienne moitié de gauche devient la nouvelle moitié droite. Ces opérations sont répétées 16 fois, donnant le DES à 16 rondes.
F
ig .
12.2 - Une ronde du DES
Si B %est le résultat de la ie itération, Li et Ri sont respectivement les moitiés gauche et droite de £?,, est la clef de 48 bits pour la ie ronde, et / est la fonction qui fait toute les substitutions, permutations et ou exclusif avec la clef, alors une ronde est décrite par : l'î — R %—i R% —
i © f ( R i - i , K t ).
La permutation initiale Le tableau 12.1 décrit la permutation initiale qui transpose le bloc d’entrée avant la première ronde. Ce tableau, ainsi que les autres tableaux de ce chapitre, doit être lu de gauche à droite et de haut en bas. Par exemple, la permutation initiale déplace le bit 58 jusqu’à la position 1, le bit 50 jusqu’à la position 2, le bit 42 jusqu’à la position 3, etc.
Tab.
~ 58 62 57 61
50 42 54 46 49 41 53 45
34 38 33 37
26 30 25 29
12.1 - Permutation initiale
18 22 17 21
ÏÔ 2 14 6 9 1 13 5
60 64 59 63
52 56 51 55
44 48 43 47
36 40 35 39
28 32 27 31
20
12 T
24 19 23
16 8 11 3 15 7
12.2
Description du DES
289
La permutation initiale et la permutation finale correspondante n’affectent pas la sécu rité du DES. (Tout ce qu’on peut dire est que son but premier est de rendre plus facile le chargement du texte en clair ou du texte chiffré dans une puce DES en morceaux de taille un octet. Rappelez vous que le DES est arrivé avant les microprocesseurs 16 ou 32 bits.) Comme cette permutation bit à bit est difficile à réaliser en logiciel (bien que ce soit banal en matériel), de nombreuses réalisations logicielles du DES n’incluent pas les permutations initiale et finale. Bien que ce nouvel algorithme ne soit pas moins sûr que le DES, il n’est pas conforme au standard DES et ne doit pas être appelé DES.
Le plan de génération des clefs Initialement, les 64 bits de la clef DES sont réduits à 56 bits en ignorant un bit sur huit. Ceci est décrit par le tableau 12.2. Ces bits peuvent être utilisés comme bits de contrôle de parité pour vérifier qu’il n’y a pas eu d’erreur lors de la saisie de la clef.
T
~ 57 10 63 14
49 2 55 6
41 59 47 61
ab
.
33 25 51 43 39 31 53 45
12.2 - Permutation de clef Ï7 35 23 37
9 27 15 29
ï 19 7 21
58 11 62 13
50 42 3 60 54 46 5 28
34 26 52 44 38 30 20 12
Ï 8~ 36 22 4
Après que la clef de 56 bits a été extraite, une clef de 48 bits différente est engendrée pour chaque ronde du DES. Ces clefs K i, sont déterminées de la manière suivante : Tout d ’abord, la clef de 56 bits est divisée en deux moitiés de 28 bits. Ensuite les moitiés sont décalées vers la gauche d’une ou deux positions, en fonction de la ronde. Le nombre de bits de décalage est donné par le tableau 12.3.
T
Ronde Nombre de décalages
.
ab
\
2 3~4
1
1
2
2
12.3 - Décalage de clef par ronde 5 2
7
6 2
9
8 2
2
1
ÏÔ
ÏÏ
2
2
12 2
13 2
Ï4 2
Ï5 2
lfT 1
Après avoir été décalés, 48 bits parmi les 56 sont sélectionnés. Comme cette opération combine une permutation des bits avec une sélection d ’un sous-ensemble des bits, elle est appelée permutation compressive, ou encore choix permuté. Cette opération fournit un sous-ensemble de bits qui a la même taille que la sortie de la permutation expansive. Le tableau 12.4 définit la permutation compressive. Par exemple, le bit en position 33 de la clef décalée va en position 35 de la sortie, et le bit en position 18 de la clef décalée est ignoré. Les décalages ont pour effet de rendre différents les sous-ensembles de bits utilisés dans chaque sous-clef. Chaque bit est utilisé dans approximativement 14 des 16 sous-clefs, bien que tous les bits ne soient pas utilisés exactement le même nombre de fois.
290
Chapitre 12
T
ab
14
Vf
II
23 41 44
19 52 49
12 31 39
.
Le D E S
12.4 - Permutation compressive 24 4 37 56
ï 26 47 34
5 8
55 53
3 16 30 46
28 7 40 42
Ï5 27 51 50
6
20 45 36
21 13 33 29
10 2 48 32
La permutation expansive Par cette opération, la moitié droite des données, Rl, est étendue de 32 à 48 bits. Comme cette opération change l’ordre des bits et qu’elle répète certains bits, elle est appelée permutation expansive. Cette opération a deux buts : le résultat a la même taille que la clef pour l’opération ou exclusif, et elle fournit un résultat plus long qui pourra être comprimé pendant l’opération de substitution. Toutefois, aucun de ces deux buts n’est sa raison d ’être cryptographique. En permettant à un bit d’affecter deux substitutions, la dépendance entre les bits d’entrée et les bits de sortie se dilue plus vite. On parlera d’effet d ’avalanche. Le DES est conçu afin de parvenir le plus vite possible à ce que chaque bit du texte chiffré dépende de chaque bit du texte en clair et de chaque bit de la clef. La figure 12.3 illustre la permutation expansive. On l’appelle parfois ta b le T . Pour chaque bloc de 4 bits d ’entrée, le premier et le quatrième bit, représentent chacun 2 bits du bloc de sortie, tandis que les deuxième et troisième bits, représentent chacun un bit du bloc de sortie. Le tableau 12.5 indique la correspondance entre les positions de sortie et les positions d ’entrée. Par exemple, le bit en position 3 du bloc d ’entrée va en position 4 du bloc de sortie, et le bit en position 21 du bloc d ’entrée va en positions 30 et 32 du bloc de sortie. Bien que le bloc de sortie soit plus grand que le bloc d ’entrée, il n’existe qu’un bloc d’entrée possible pour un bloc de sortie donné.
F ig . 12.3 - Permutation expansive
12.2
291
Description du DES
T ab . 12.5 - Permutation expansive
32
1
2
8
9 17 25
10
11
12
18 26
19 27
20
21
20
21
22
28
29
28
29
30
16 24
3
4
5 13
4 12
5 13
6
14
7 15 23 31
8
16 24 32
9 17 25 1
La substitution par tables—S Après que la clef comprimée a été combinée par ou exclusif avec le bloc expansé, le résultat de 48 bits est soumis à une opération de substitution. Ces substitutions sont réalisées à l’aide de huit tables de substitution, ou tables-S. Chaque table-S 1 a six bits d ’entrée et quatre de sortie, et il y a huit tables-S 1 différentes2. Les 48 bits sont divisés en blocs de 6 bits. Chaque bloc est manipulé séparément par une tableS différente: le bloc 1 est manipulé par la table -S 1, le bloc 2 est manipulé par la table- S 2, etc. Voir la figure 12.4. Chaque table-S a 4 rangs et 16 colonnes. Chaque cellule dans la table est un nombre de 4 bits. Les 6 bits du bloc d ’entrée spécifient le rang et la colonne à exploiter pour obtenir la sortie. Le tableau 12.6 montre les 8 tables -S. Les bits d’entrée spécifient une cellule de la table-S d’une manière très particulière : considérez 6 bits d’entrée étiquetés fq, 6 2 , 6 3 , 6 4 , fis, fie ; les bits fi] et fie sont combinés pour former un nombre de 2 bits, entre 0 et 3, qui correspond à un rang dans la table ; les 4 bits du milieu, 62 à fis, sont combinés pour former un nombre de 4 bits, entre 0 et 15, qui correspond à une colonne dans la table. Par exemple, faites l’hypothèse que l’entrée de la sixième table-S (c’est-à-dire les bits 31 à 36 en sortie de la fonction ou exclusif ) soit 1100102. Le premier et le dernier bits, combinés pour former 102, indiquent qu’il faut prendre le 2 e rang de la table. Les 4 bits du milieu combiné pour former 10012 indiquent qu’il faut prendre la 9e colonne de la table. La cellule au 2e rang, 9e colonne de la table-S 6 est 0. Rappelez-vous que l’on numérote les rangs et les colonnes à partir de 0 et non de 1. La valeur 00002 remplace 110010 2 .
Bien sûr, dans une réalisation logicielle, il est bien plus facile d ’utiliser des tableaux de 64 entrées pour les tables S. Cela demande de réarranger un peu les entrées, mais ce n’est pas difficile3. Toutefois, décrire ainsi les tables-S aide à visualiser la façon dont 2. L ’espace m ém oire total occu p é par les ta b le s -S du D E S est de 256 octets. 3. Il ne faut pas changer uniquement les indices sans réarranger les entrées. Les ta b le s -S sont conçues très précisément.
F ig . 12.4 - Table-S de substitution
Chapitre 12
292
T
Table-5 14 4 0 15 4 1 15 12 Table-S 15 1 3 13 0 14 13 8 Table-S 10 0 13 7 13 6 1 10 Table-S 7 13 13 8 10 6 3 15 Table S 2 12 14 11 4 2 11
2
1
12.6 - Tables-S
1
2
15
11
8
3
10
6
12
4
2
13
1
10
6
12
11
6
2
11
1
7
15 5
12
9
9 3
4 14
12
8
2
8
14 7
6
11
3
15
2
8
11
10
1
3
4 15
13 4
14 9 9
6
15 6
3
0
0
6
3 4 15 9
8
7
3 5
0
6
9
6
15
0
7 13
8
11
5 9 3
7 14
10
0
7 8
10
3 5
0
0
6
13
5
10
9 5
:
12 6
.
14 13 4
4 7 10 3: 9 0 4 13 4: 14 11 9 0 5: 4 2 1
8
Table-S 12
1: 13 7 14
ab
Le D E S
3 8
7
2
13
12
0
0
1
10
6
8
12
6
9
11
6
7
12
0
9 3 5
5
1
13
12
10
2
8
5
7 14
11
1
2
12
4
15
14
10
1
2
8
3 13
7
2
12
1
8
4
3 5
2
8
4 15 9
11
12
7
3 15
15
13 3
12
5 9
1 2
9 5
0
12
11
6
10
1
1
7 4
10
11
6
8
5
7 13 14
13 7
1
0
8
5 15
2
13
6
9 15
2
6
8
0
13
12
9
5 3
6
1 0
3 13 4
14 12
12 11
10
7
1
15
9 7
0
11
4
12
11
5
10
5
3
11
5
11
12
1
10
14
10
5
6 10
14
5 15 9
2
8
15 14
7
11 2
1
2
12
4 14 2
15 9 4 14
0
14
9
9 3 4
8
6
0
14 3
5
: 10
10 15 4 9 14 15 4 3 2 Table S 7 : 4 11 2 13 0 11 1 4 11 6 11 13 Table-S 8 : 13 2 8 1 15 13 7 11 4 2 1 14
2
5 12
14 7 13 8
8
9
5
15
10
11
15 4
0
8
13
3 14
12 1
9 3 4
1
10
7
14 7
10
11
1
10
4
12
2
13
10
4
6
8
10
15 3
1
9 4
12
7 14
10
8
7
7
2
12
9
3 15 5
4 14
14 0
11
7
10
1
13
11
6
1
7
6
0
8
13
9 5
7
5
10
6
1
12
2
8
6
6
8
0
15 5
0
15
14
2
9 3
12
12
9 5
3
14
5
0
6
11
0
0
6
10
13
15
12
9
0
15 3
14 3 5
5 3
11 8
2
7
9 5
8
6
11
2
12.2
Description du DES
293
elles fonctionnent. On peut voir chaque table-S 1 comme une permutation de quatre de ses entrées: les bits de £>2 à 65 sont pris en entrée et il en sort un résultat de quatre bits. Les bits bi et be proviennent des emplacements contigus; ils sont utilisés pour sélectionner une des quatres permutations possibles de la table-S en question. Cette étape de substitution par tables-S est cruciale dans le DES. Toutes les autres opérations sont linéaires et faciles à analyser. Les tables-S sont non linéaires et, par dessus tout, elles confèrent au DES son niveau de sécurité. Cette phase de substitution donne 8 blocs de 4 bits qui sont recombinés pour former un seul bloc de 32 bits. Ce bloc passe alors à l’étape suivante : la permutation-P.
La permutation—P Les 32 bits de sortie des substitutions par tables .S sont permutés à l’aide d ’une tableP. Cette table met en correspondance chaque bit de l’entrée avec un bit de sortie;
aucun bit n’est utilisé deux fois et aucun bit n’est ignoré. O 11 parlera de permutation pure, ou tout simplementde permutation. Le tableau12.7montre à quelle position migre chaque bit. Par exemple, le bit 21 va en position 4, tandis que le bit 4 va en position 31.
T
Ï6 2
7 8
20 24
21 14
ab
29 32
.
12.7 —Permutation-P
12 28 27 3
Ï7 9
1 15 19 13
23 30
26
5 Ï 8 31 22 11 4
6
10 25
Finalement, le résultat de la permutation-P est combiné par ou exclusif avec la moitié gauche du bloc initial de 64 bits. Ensuite, les parties gauche et droite sont échangées et une nouvelle ronde commence.
La permutation finale La permutation finale, qui est l’inverse de la permutation initiale, est décrite par le tableau 12.8. Notez que les parties gauche et droite ne sont pas échangées après la dernière ronde du DES ; c ’est le bloc RieLie qui est utilisé comme entrée pour la permutation finale. Il n’y a rien de bien particulier ici ; échanger les moitiés et décaler la permutation donnerait exactement le même résultat ; il en est ainsi pour que le même algorithme puisse être utilisé pour le chiffrement et le déchiffrement.
T
~4Ô 38 36 34
8 6
4 2
48 46 44 42
16 14 12 10
56 54 52 50
ab
24 22 20 18
.
12.8 - Permutation finale 64 62 60 58
32 30 28 26
39 37 35 33
7 5 3 1
47 45 43 41
15 13 11 9
55 53 51 49
23 21 19 17
63 61 59 57
3F 29 27 25
294
Chapitre 12
Le D ES
Déchiffrement du DES Après toutes ces substitutions, permutations, ou exclusif et décalages, vous pourriez penser que l’algorithme de déchiffrement est totalement différent et aussi déroutant que l’algorithme de chiffrement. Tout au contraire, les différentes opérations ont été choisies pour offrir une propriété très utile : le même algorithme est utilisé pour le chiffrement et le déchiffrement. Avec le DES il est possible d’utiliser la même fonction pour chiffrer un bloc et pour le déchiffrer. La seule différence est que les clefs doivent être utilisées dans l’ordre inverse. Si les clefs de chiffrement de chaque ronde sont A i , A 2 , A 3 , ... , A i 6 , alors les clefs de déchiffrement sont respectivement A 16, A 1 5 , A 1 4 , ... , K\. L’algorithme qui engendre les clefs pour chaque ronde est également circulaire, et le nombre de décalages (vers la droite) à effectuer devient 0 ,1 ,2 ,2 ,2 ,2 ,2 ,2 , 1 ,2 ,2 ,2 ,2 ,2 ,2 , 1 .
Modes opératoires du DES Le document FIPS PU B 81 spécifie quatre modes opératoires: E CB, C B C , OFB, et C FB (voir le chapitre 9) [1156]. Le standard bancaire de l’AN SI spécifie les modes E C B et C B C pour le chiffrement, et les modes C B C et CFB à n bits pour l’authentification [55]. Dans le monde du logiciel, la certification n’existe pas. A cause de sa simplicité le mode E C B est le plus souvent utilisé dans les logiciels commerciaux classiques, bien qu’il soit le plus vulnérable aux attaques. Le mode de chiffrement avec chaînage de blocs est utilisé occasionnellement, bien qu’il ne soit guère plus compliqué que le carnet de codage électronique et qu’il procure un niveau de sécurité nettement plus élevé.
Réalisations matérielles et logicielles du DES De nombreuses publications décrivent des réalisations efficaces matérielles et logicielles de l’algorithme [1007, 8 8 , 535, 536, 437, 740, 1575, 183, 275, 1574]. Le détenteur du record de rapidité de la puce DES est un prototype développé par D i g i t a l E q u ip m e n t C o r p o r a t i o n [513]. Elle offre les modes ECB et C B C et elle est réalisée avec une matrice de 50000 transistors G a A s . Les données peuvent être chiffrées et déchiffrées à la vitesse de 1 gigabit par seconde (15,6 millions de blocs DES par seconde). C ’est impressionnant. La table 12.9 donne les spécificités de certaines des puces DES du commerce. Les apparentes disparités entre les vitesses d ’horloges et les taux de donées sont dues au parallélisme incorporé dans certaines puces. La puce la plus impressionnante est la 6 8 6 8 de VLSI (appelée à ses débuts la « garde barrière »). Non seulement elle peut appliquer le DES en 8 cycles d’horloge (des pro totypes peuvent le faire en quatre), mais elle peut aussi appliquer le le triple DES en 25 cycles d ’horloge en mode E C B , et en 35 cycles d ’horloge en mode O FB ou CBC. Cela me paraît impossible mais je vous assure que ça marche. Une réalisation logicielle du DES sur un ordinateur central IBM 3090 peut effec tuer 32 000 chiffrements DES par seconde. La plupart des microprocesseurs sont plus lents, mais impressionnants malgré tout. Le tableau 12.10 [605, 793] donne des chiffres concrets et des estimations pour divers microprocesseurs I n t e l et M O T O R O L A .
12.2
295
Description du DES
T
ab
.
12.9 - Les puces dédiées au DES dans le commerce. Puce
Marque
AMD AMD AM D
Année
Am9518 Am9568 AmZ8068 T7000A SuperCrypt CE99C003 SuperCrypt CE99C003 Cryl2C102 CA20C03A
AT& T C E -I n fo sys
IscCE-Infosys C ryptech N e w b r id g e
CA20C03W C A 9 5 C 6 8 /18/09 PCC100 Roadrunner284
N e w b r id g e N e w b r id g e P ij n e n b u r g SEM APHORE
Communications VLSI T e c c h n o l o g y VLSI T e c c h n o l o g y VLSI T e c c h n o l o g y W e s t e r n D ig it a l
T
ab
.
VM007 VM009 6868 W D2001/2002
Vitesse
Taux de
d ’horloge (en MHz)
données chiffrées (en megaoctets par seconde)
Commercialisé
20
1,7 1,9 12,5
non non non non oui
1994
30
20,0
oui
1989 1991 1992 1993 ? ?
20 25 8 33 ?
2,8 3,85 0,64 14,67 2,5 35,5
oui oui oui oui oui oui
20,0 14,0 64,0 0,23
oui oui oui non
1981 ? 1982 1985 1992
3 4 4 ?
40 32
1993 1993 1995 1984
33 32 3
1,3 1,5
12.10 - Vitesse du DES pour différents processeurs
Processeur 8088 68000 80286 68020 68030 80386 68030 68040 68040 80486 Sun ELC HyperSparc RS6000-350 Sparc 10/52 DEC Alpha 4000/610 HP 9000/887
Vitesse (en MHz) 4,7 7,6 6 16 16 25 50 25 40 33
125
Blocs DES (par seconde) 370 900 1100 3 500 3900 5000 9600 16000 23 200 40600 26000 32000 53000 84000 154000 196000
Chapitre 12
296
12.3
Le D E S
Niveau de sécurité du DES
Les gens ont longtemps mis en doute le niveau de sécurité du DES [464]. Il y a eu bon nombre de spéculations sur la longueur de la clef, le nombre d’itérations et le schéma de conception des tables-S. Les tables S semblaient tout particulièrement mystérieuses — toutes ces constantes, sans aucune raison apparente à leur valeurs particulières. Certaines personnes craignaient que la NSA ait caché une « brèche secrète » dans l’algorithme, de façon à pouvoir facilement déchiffrer les messages. Une commission sénatoriale, le « Senate Select Committee on Intelligence », étudia la question en 1978, avec les autorisations top-secrètes du plus haut niveau. Les résultats de cette enquête sont restés secrets mais un résumé en a été publié disculpant la NSA de toute malveillance dans la conception de l’algorithme [1226]. « Il est établi [que la NSA] a convaincu IBM du bien-fondé du choix d’une clef plus courte, [que la NSA] a indirectement participé au développement de la structure des tables- S et [que la NSA] a certifié que l’algorithme final DES était, pour autant que l’on sache, exempt de toute faiblesse statistique ou mathématique » [435]. Toutefois, comme le gouvernement ne rendit jamais publics les résultats complets de l’enquête, de nombreuses personnes restèrent sceptiques. T U C H M A N et M e y e r , deux des cryptographes d ’IBM qui ont conçu le DES, décla rèrent que la NSA n’avait, pas altéré le schéma de conception [842] : « Leur approche de base consistait à chercher des fonctions solides de substi tution, de permutation et de génération de clefs ... IBM a classé les notes concernant les critères de conception à la demande de la N SA ... « La NSA nous a dit que nous avions par inadvertance réinventé certains des se crets fondamentaux qu’elle utilise pour ses propres algorithmes », expliqua T
uchm an
. »
Plus loin dans l’article, T u c h m a n déclara: « Nous avons développé l’algorithme DES entièrement à l’intérieur d’IBM avec des IBMistes. La NSA n’a pas dicté une seule ligne! » T U C H M A N confirma ceci lorsqu’il présenta l’histoire du DES à la « National Computer Security Conférence » en 1992. D ’un autre côté, C o p p e r s m i t h a écrit [376, 379]: « La NSA a aussi apporté des conseils techniques à IB M .» Et les propos suivant de K o n h e i m ont été rapportés: «Nous avons envoyé nos tables S à Washington. Elles nous ont été renvoyées toutes différentes. Nous leur avons fait subir nos tests et elles ont réussi.» Certaines personnes ont pris cela comme une preuve que la NSA avait caché une « brèche secrète ». Quand la NSA fut interrogée quant à toute faiblesse introduite intentionnellement dans le DES, elle répondit [367] : « Pour ce qui est du standard de chiffrement de données (D ES), nous pensons que le compte-rendu public de l’enquête menée par le « Senate Committee for Intelligence » en 1978 quant au rôle de la NSA dans le dé veloppement du DES répond à votre question. Le rapport de la commission indique que la N SA n’a pas faussé la conception du DES en quelque façon que ce soit, et que le niveau de sécurité offert par le DES était plus que suffisant pour résister au moins cinq à dix ans sur les données non classées pour lesquelles il était conçu. En bref, la NSA n’a pas imposé ou tenté d’imposer la moindre faiblesse au DES. »
12.3
Niveau de sécurité du D E S
297
Pourquoi ont-ils alors modifié les tables-S? Peut-être pour s’assurer qu’IBM n’avait pas caché une « brèche secrète » dans le DES. La NSA n’avait aucune raison de faire confiance aux chercheurs d ’IBM , et aurait manqué à son devoir en n ’évitant pas toute possiblité d ’une « brèche secrète » dans le DES. Donner les tables-S était un moyen de s’en assurer. Très récemment, de nouveaux résultats de cryptanalyse ont éclairé cette question sous un autre jour, mais pendant de nombreuses années elle fut l’objet de multiples spécu lations.
Clefs faibles La méthode pour obtenir les sous-clefs pour chaque ronde de l’algorithme à partir de la clef initiale implique l’existence de certaines clefs faibles [722, 428]. Rappelezvous que la valeur initiale est divisée en deux moitiés, chaque moitié étant décalée indépendamment de l’autre. Si tous les bits de chaque moitié sont soit des 0, soit des 1, alors la clef utilisée pour n’importe quel cycle de l’algorithme est la même que pour tous les cycles de l’algorithme. Tel est le cas si la clef est constituée entièrement de 1 ou entièrement de 0, ou si une moitié est entièrement constituée de 1 et l’autre entièrement de 0. De plus, deux des clefs faibles ont d ’autres propriétés qui les rendent moins sûres [428]. Les quatre clefs faibles sont données en notation hexadécimale par le tableau 12.11. Rappelez-vous qu’un bit sur huit est un bit de contrôle de parité et que la permutation initiale change légèrement l’ordre des bits de la clef.
Ta
b
.
12.11 - Clefs DES faibles
Valeur de clef faible (avec bits de parité) 0101 1F1F EOEO FEFE
0101 0101 0101 1F1F 0E0E 0E0E EOEO F1F1 F1F1 FEFE FEFE FEFE
Clef 0000000 0000000 FFFFFFF FFFFFFF
0000000 FFFFFFF 0000000 FFFFFFF
De plus, il existe des paires de clefs qui chiffrent un texte en clair en un même texte chiffré. En d ’autres termes, une clef de la paire peut être utilisée pour déchiffrer des messages chiffrés avec l’autre clef de la paire. Ceci est dû à la méthode utilisée pour engendrer les sous-clefs dans le DES ; au lieu d’engendrer 16 sous-clefs différentes, ces paires de clefs n’engendrent que 2 sous-clefs différentes. Chacune de ces sous-clefs est utilisée 8 fois dans l’algorithme. Ces clefs sont appelées clefs sem i-faibles. Elles sont décrites dans le tableau 12.12. Il y a aussi des clefs qui ne produisent que 4 sous-clefs différentes, chacune étant utilisée 4 fois dans l’algorithme. Ces clefs sont décrites dans le tableau 12.13. Avant de condamner le DES parce qu’il a des clefs faibles, notez que cette liste de 64 clefs est minuscule en comparaison du nombre total de clefs possibles, à savoir : 72057594037927936. Si vous choisissez les clefs aléatoirement, les chances d ’en choisir une parmi ces clefs
Chapitre 12
298
Le D E S
T a b . 12.12 - Clefs DES semi-faibles
01FE 1FE0 01E0 1FFE 011F EOFE
T
01FE 1FE0 01E0 1FFE 011F EOFE
ab
.
01FE 0EF1 01F1 OEFE 010E F1FE
01FE 0EF1 01F1 OEFE 010E F1FE
et et et et et et
FE01 E01F E001 FE1F 1F01 FEEO
FE01 E01F E001 FE1F 1F01 FEEO
FE01 F10E F101 FEOE 0E01 FEF1
FE01 F10E F101 FEOE 0E01 FEF1
12.13 - Clefs DES potentiellement faibles
1F 01 1F 01
1F 1F 01 01
01 1F 01 1F
01 01 1F 1F
OE 01 OE 01
OE OE 01 01
01 OE 01 OE
01 01 OE OE
EO FE FE EO FE EO EO FE
EO FE EO FE EO FE EO FE
01 01 1F 1F 01 01 1F 1F
01 01 01 01 1F 1F 1F 1F
FI FE FE FI FE FI FI FE
FI FE FI FE FI FE FI FE
01 01 OE OE 01 01 OE OE
01 01 01 01 OE OE OE OE
FE EO FE EO
1F 1F 01 01
EO FE EO FE
01 01 1F 1F
FE FI FE FI
OE OE 01 01
FI FE FI FE
01 01 OE OE
01 1F 1F 01 1F 01 01 1F
EO FE EO FE EO FE EO FE
EO EO FE FE EO EO FE FE
01 01 01 01 1F 1F 1F 1F
01 OE OE 01 OE 01 01 OE
FI FE FI FE FI FE FI FE
FI FO FE FE FI FI FE FE
01 01 01 01 OE OE OE OE
EO FE FE EO FE EO EO FE
01 1F 01 1F 01 1F 01 1F
01 01 1F 1F 01 01 1F 1F
EO EO EO EO FE FE FE FE
FI FE FE FI FE FI FI FE
01 OE 01 OE 01 OE 01 OE
01 01 OE OE 01 01 OE OE
FI FI FI FI FE FE FE FE
1F 01 1F 01
FE FE EO EO
01 1F 01 1F
EO EO FE FE
OE 01 OE 01
FE FE FI FI
01 OE 01 OE
FI FI FE FE
01 1F 1F 01 1F 01 01 1F
01 1F 01 1F 01 1F 01 1F
EO EO FE FE EO EO FE FE
EO EO EO EO FE FE FE FE
01 OE OE 01 OE 01 01 OE
01 OE 01 OE 01 OE 01 OE
FI FI FE FE FI FI FE FE
FI FI FI FI FE FE FE FE
FE EO FE EO
FE FE EO EO
EO FE EO FE
EO EO FE FE
FE FI FE FI
FE FE FI FI
FI FE FI FE
FI FI FE FE
faibles sont négligeables. Si vous être vraiment paranoïaque, vous pouvez détecter les ciels faibles lors de la génération de clefs. Certains ne pensent pas que cela en vaille la peine. D ’autres pensent que c ’est tellement facile qu’il vaut mieux le faire. Vous trouverez plus de détails concernant les clefs faibles et semi-faibles dans [1122]. D ’autres types de clefs faibles ont été recherchés mais aucun n’a été trouvé.
12.3
299
Niveau de sécurité du D E S
Clefs complémentaires Prenez le complément bit à bit d’une clef ; autrement dit, remplacez tous les 0 par des I et tous les 1 par des 0. Après cela, si la clef originale est utilisée pour chiffrer un bloc de texte en clair, alors le chiffrement du complément du bloc de texte en clair par la clef complémentaire donnera le complément du texte chiffré. Si x' est le complément de x, alors l’identité est donnée comme suit : E k {M ) = C E K'( M ') = C'.
Cela n’a rien de mystérieux. Les sous-clefs sont combinées avec la moitiée de droite après la permutation expansive. Cette propriété de complémentarité provient de ce fait. Cela veut dire qu’une attaque à textes en clair choisis contre le DES ne devra tester que la moitié des clefs possibles : 2 55 clefs au lieu de 2 51 [1084]. B i h a m et S h a m i r montrent [178] qu’il existe une attaque à textes en clair connus de la même complexité avec au moins 2 3 3 textes en clair connus. II est douteux que cela constitue une faiblesse, car la plupart des messages n’ont pas de blocs complémentaires de texte en clair (dans un texte en clair aléatoire, les chances sont infimes) et l’on peut conseiller aux utilisateurs de ne pas utiliser de clefs complé mentaires.
Structure algébrique Il y a 264! manières de mettre en correspondance tous les textes en clair possibles de 64 bits avec tous les textes chiffrés possibles. Avec sa clef de 56 bits, l’algorithme DES donne donc 256 (~ 1016) de ces relations. En utilisant le surchiffrement, il semble possible d ’obtenir un plus grand nombre de ces relations. Toutefois, ceci n’est vrai que si le DES n’a pas une certaine structure algébrique. Si l’opération de chiffrement par le DES était interne, pour tous K\ et K 2, il existerait A 3 tel que : E K2 ( EK l(P )) - E K3(P) En d’autres termes, cette opération formerait un groupe, et chiffrer un bloc de texte en clair avec K\ puis A 2 serait identique au chiffrement du bloc avec A 3 . Pire encore, le DES serait vulnérable à une attaque par collisions qui ne nécessite que 228 étapes, nettement moins que les 256 étapes nécessaires pour une recherche exhaustive [803]. Si l’opération de chiffrement par le DES était pure, pour tous A i , AT2 et Kg, il exis terait A 4 tel que :
E K3(EK2(EKi (P))) = E k 4(P) Le DES triple serait alors inutile4. Don C O P P E R S M IT H a écrit très tôt un article théorique donnant des indices sur la question, mais cela n’était pas suffisant [381]. Plusieurs mathématiciens se sont attaqués à cette question [590, 428, 431, 529, 725, 790]. Ces expériences rassemblèrent un « grand nombre d’indices » indiquant que le DES n’est pas un groupe [803, 375, 804,1122, 805], 4. Rem arquez q u ’un algorithm e de chiffrement interne est nécessairement pur, mais un algorithm e de chiffrement pur n ’est pas forcém ent interne.
300
Chapitre 12
Le D ES
mais il fallut attendre 1992 pour que les cryptographes réussissent à prouver que le DES n’est pas un groupe [297], C o p p e r s m i t h a affirmé que l’équipe d’IBM le savait depuis longtemps.
Longueur de clef La première proposition d ’IBM à la NBS avait une clef de 112 bits. Quand le DES devint un standard, cette longueur avait été ramenée à 56 bits. De nombreux cryp tographes préconisaient une clef longue. Leurs arguments tournaient principalement autour de la possibilité d ’une attaque exhaustive (voir § 7.1). En 1976 et 1977, D i f f i e et H e l l m a n démontrèrent qu’un ordinateur parallèle dédié à l’attaque du DES pouvait retrouver la clef en un jour et coûterait 20 millions de dollars. En 1981, D i f f i e et H e l l m a n révisèrent leurs chiffres à la hausse : deux jours de recherche par clef et 50 millions de dollars [489]. Ils admettaient que c ’était hors de portée de quiconque excepté les organisations telles que la NSA, mais considéraient que d ’ici à 1990, le DES ne serait plus sûr du tout [717]. H e l l m a n [716] présenta un autre argument contre une petite taille de clef : en jouant sur le compromis mémoire - temps de calcul dans le sens de la mémoire, il serait possible d ’accélérer le processus de recherche. II suggérait la possibilité de calculer et de stocker 256 résultats possibles du chiffrement d ’un même bloc de texte en clair avec toutes les clefs possibles. Alors, pour retrouver une clef, tout ce qui restait à faire au cryptanalyste était d ’insérer le bloc de texte en clair dans le processus de chiffrement, de récupérer le texte chiffré et de rechercher la clef par comparaison. H e l l m a n estima le coût d ’une telle machine à 5 millions de dollars.
Les argumentations pour ou contre l’existence d’un système permettant de casser le DES quelque part dans les caves du Gouvernement ont continué. Plusieurs personnes firent remarquer que le temps moyen entre deux pannes des puces DES ne serait jamais assez grand pour garantir qu’une telle machine puisse marcher. Cette objection est superflue comme le montre [1289]. D ’autres ont suggéré d ’accélérer encore le processus et de réduire l’effet de pannes des puces. Entre-temps, les réalisations matérielles du DES ont lentement approché le million de chiffrements par seconde nécessaire pour la machine spécialisée de D i f f i e et H e l l m a n . En 1984, des puces capables d’exécuter 256000 chiffrements par seconde ont été fabri quées [535, 536]. En 1987, des puces qui effectuaient 512000 chiffrements par seconde ont été développées, et une version capable de tester plus d ’un million de clefs par seconde était faisable [740, 1575]. Et en 1993, Michael W i e n e r a conçu une machine coûtant un million de dollars pouvant accomplir une attaque exhaustive contre le DES en un temps moyen de 3,5 heures (voir § 7.1). Jusqu’ici, personne n’a admis publiquement avoir construit une telle machine, bien qu’il soit raisonnable de penser que quelqu’un en a déjà construit une. Un million de dollars ne constitue pas une somme importante pour un pays développé. Ce n’est qu’en 1990 que deux mathématiciens israéliens, B i h a m et S h a m i r , ont dé couvert la cry p ta n a lyse différentielle, une technique qui écarta la question de la longueur de clef. Avant que nous ne décrivions cette technique, énumérons quelques autres critiques à l’encontre de la conception du DES.
12.3
Niveau de sécurité du D E S
301
Nombre de rondes Pourquoi 16 rondes? Pourquoi pas 32? Après 5 rondes, chaque bit du texte chiffré est une fonction de chaque bit du texte en clair et de chaque bit de la clef; et après 8 rondes, le texte chiffré est essentiellement une fonction aléatoire de chaque bit du texte en clair et de chaque bit de la clef [1088, 1084]5. Alors pourquoi l’algorithme ne s’arrête-t-il pas alors après 8 rondes? Au fil des ans, il y a eu des attaques réussies contre des variantes du DES avec un nombre de rondes réduit. Le DES avec 3 ou 4 rondes fut facilement cassé en 1982 [50]. Le DES avec 6 rondes est tombé quelques années plus tard [341]. C ’est la cryptanalyse différentielle de B i h a m et S h a m i r qui explique également cela; avec n’importe quel nombre de rondes inférieur à 16 le DES peut être cassé par une attaque à texte en clair connu plus efficacement que par recherche exhaustive. L’attaque exhaustive est certainement plus pratique, mais il est intéressant de constater que l’algorithme a exactement 16 rondes.
Conception des tables—S En plus d ’avoir été accusée d ’avoir réduit la longueur de la clef, la NSA fut aussi accusée d’avoir modifié le contenu des tables-S. Sommée de justifier la conception des tables-S, la NSA indiqua que les détails de conception de l’algorithme étaient sensibles et qu’ils ne seraient pas rendus publics. Plusieurs cryptographes s’inquiétaient de la possibilité que la NSA ait introduit une brèche secrète dans les tables-S, lui permettant ainsi de cryptanalyser l’algorithme. Depuis, pas mal d ’effort a été investi dans l’étude de la conception et du fonctionne ment des tables-S. Au milieu des années 70, L e x a r C o r p o r a t i o n [972, 722] et B e l l L a b o r a t o r i e s [1126] examinèrent le fonctionnement des tables-S. Leurs analyses ne révélèrent aucune faiblesse, bien qu’ils trouvèrent tous les deux des caractéristiques inexplicables. Les tables-S avaient plus de caractéristiques en commun avec des trans formations linéaires que n’en auraient eu des tables choisies aléatoirement. L’équipe de B e l l L a b o r a t o r i e s indiqua que les tables-S pouvaient avoir une brèche secrète et le rapport L E X A R concluait ainsi : « Certaines structures découvertes dans le DES ont sans doute été in sérées pour renforcer le système contre certains types d’attaques. D’autres structures tendent à affaiblir le système. » D’un autre côté, ce rapport contenait aussi la mise en garde suivante: « ...le problème [de la recherche de structures dans les tables-,S’] est rendu plus complexe par la capacité qu’a l’esprit humain de trouver une structure apparente dans des données aléatoires, mais qui ne constitue pas vraiment une structure. » Au second atelier du DES, l’ Agence nationale de sécurité américaine révéla certains des critères de conception des tables- .S’ [232]. Cela n’atténua pas le moins du monde la suspicion des gens et le débat continua [231, 424, 717, 1510, 1559]. 5. Cela s’appelle l’effet de cascade.
Chapitre 12
Le D ES
Plusieurs excentricités concernant les tables - S ont vu le jour dans la littérature. Les trois derniers bits de sortie de la quatrième table S 4 peuvent être obtenus de la même manière que les premiers en prenant le complément de certains bits d ’entrée [436, 438]. Deux entrées différentes, mais soigneusement choisies, peuvent produire la même sortie [436]. Il est possible d ’obtenir la même sortie d ’une seule ronde DES en changeant les bits de trois tables S contigües seulement [485]. S h a m i r a remarqué que les tables-S1paraissaient déséquilibrées en quelque sorte, mais il était loin de pouvoir utiliser cela dans une attaque [1430]6. D ’autres chercheurs ont montré que des principes publiques de conception permettaient de générer des tables-S ayant les caractéristiques observées [270].
Résultats supplémentaires Il y a eu d ’autres tentatives de cryptanalyse du DES. Un cryptographe a recherché l’absence de caractère non aléatoire sur la base de tests spectraux [561]. D ’autres cryp tographes ont recherché des séquences de facteurs linéaires dans le DES, mais leur attaque échouait après huit rondes [1308, 341, 533]. En 1987, une attaque non publiée de Donald D a v ie S exploitait la façon dont la permutation expansive répète les bits dans des tables S adjacentes ; cette attaque est elle aussi inutilisable à partir de huit rondes [178, 441].
12.4
Cryptanalyse différentielle et linéaire
Cryptanalyse différentielle En 1990, Eli B ih a m et Adi S h a m ir ont introduit la notion de cryptanalyse différen tielle [174, 175, 179, 178]. C ’était une nouvelle méthode de cryptanalyse, inconnue à ce moment-là du public. En utilisant cette méthode, B ih a m et S h a m ir trouvèrent une attaque à texte en clair choisi contre le DES plus efficace que la recherche exhaustive. La cryptanalyse différentielle traite spécifiquement les paires de textes chiffrés : des paires de textes chiffrés dont les textes en clair présentent certaines différences particulières. Elle analyse l’évolution de ces différences de textes en clairs à travers les différentes rondes du DES quand ils sont chifrés avec la même clef. Choisissez simplement des textes en clair avec une différence fixée. Les deux textes en clair peuvent être choisis aléatoirement tant qu’ils vérifient des conditions particulières de sur leur différence ; le cryptanalyste n’a pas même besoin de connaître leurs valeurs7. En utilisant alors les différences dans les textes chiffrés résultants, assignez différentes probabilités aux clefs possibles. À force d ’analyser des paires de textes chiffrés, vous finirez par trouver la clef la plus probable. C ’est la bonne clef. Les détails sont plus compliqués. La figure 12.5 représente la fonction résultant d’une ronde de DES. Imaginez qu’elle prenne en entrée la paire X et X de différence A X . Les sorties Y et Y ' sont connues et par conséquent leur différence A Y aussi. La permutation expansive et la table-P sont toutes les deux connues, A A et A C le sont 6. Il m entionna aussi une caractéristique de la cinquièm e ta b le -S , mais c ’est seulement après huit ans que la cryptanalyse pu t exploiter cette caractéristique. 7. Pour le D E S, le term e « différence » est défini par l’opération de « o u e x c lu s if ». Il peut en être autrement pou r d ’autres algorithm es.
12. J)
Cryptanalyse différentielle et linéaire
303
donc aussi. B et B ' ne sont pas connus mais leur différence A B est égale à A / l 8. Voici l’astuce : pour tous les A A possibles, toutes les valeurs de ÔC ne sont pas équiprobables. La combinaison de A A et A C donne des indications sur les bits de A © K i et A' © KiComme A et A! sont connus, cela nous donne de l’information sur Ki.
F
ig
.
12.5 - La fonction résultant d’une ronde de DES
Examinons la dernière ronde du DES. (La cryptanalyse différentielle ignore les per mutations initiales et finales. Elles n’ont aucun effet sur l’attaque mis à part celui de la rendre plus difficile à expliquer.) Si nous pouvons déterminer K ie, alors nous avons 48 bits de la clef9. Les 8 autres bits peuvent être obtenus par recherche exhaustive. La cryptanalyse différentielle nous donnera /C eCertaines différences dans les paires de textes en clair ont de fortes chances de réap paraître dans les paires de textes chiffrés correspondantes. On les appelle caractéris tiques. Les caractéristiques s’étendent sur plusieurs rondes et définissent essentielle ment un chemin à travers ces rondes. Il y a une différence en entrée de chaque ronde et une différence en sortie avec une certaine probabilité. Vous pouvez trouver ces caractéristiques en générant un tableau où les lignes corres pondent aux entrées possibles (les combinaisons par ou exclusif de deux ensembles 8. Q uand on regarde la différence, les deux opérations de o u e x c lu s if de K z sur A et A ! s’ annulent. 9. R appelez-vous que la sous-clef de chaque ronde est constituée de 48 des 56 b its de la clef.
304
Chapitre 12
Le D E S
différents de bits d’entrée), les colonnes correspondent aux différences en sorties pos sibles, et chaque case contient le nombre de fois où une sortie particulière est obtenue pour une entrée donnée. Vous pouvez générer un tel tableau pour chacune des huit tables-S 1 du DES. Par exemple la figure 12.6a donne une caractéristique d’une ronde. La différence en entrée du côté gauche est L ; cela peut-être n’importe quoi. La différence en entrée du côté droit est O10. Comme il n’y a pas de différence à l’entrée de la fonction résultant de la ronde, il n’y en a pas à la sortie. Ainsi, la différence du côté gauche est L ® 0 = L, et la différence du côté droit est 0. C ’est une caractéristiques triviale, qui est vrai avec probabilité 1 . La figure 12.6b donne une caractéristique moins évidente. La différence du côté gauche est à nouveau arbitraire: L. La différence du côté droit est 0x60000000; les deux entrées ne différent que par le premier et le troisième bits. Il y a une probabilité de 14/64 pour que la différence en sortie de ronde soit L © 0x00808200. Cela signifie que la différence en sortie est L © 0x00808200 du côté gauche et 0x60000000 du côté droit avec probabilité 14/64.
F ig. 12.6 - Des caractéristiques du DES Des caractéristiques différentes peuvent être combinées. Et en supposant que les rondes sont indépendantes, on peut multiplier les probabilités. La figure 12.7 combine les deux caractéristiques décrites ci-dessus. La différence en entrée est 0x00808200 du côté gauche et 0x60000000 du côté droit. A la fin de la première ronde, la différence en entrée et la sortie de la fonction résultant de la ronde s’annulent, laissant une différence en sortie de 0. Cela entre dans la deuxième ronde; la différence finale en sortie est 0x60000000 du côté gauche et 0 du côté droit. Cette caractéristique sur deux rondes a probabilité 16/64. Une paire de textes en clair qui satisfait la caractéristique est une paire juste. Une paire de textes en clair qui ne la satisfait pas est une paire fausse. Une paire juste suggérera la bonne clef de ronde (pour la dernière ronde de la caractéristique) ; une 10. Les deux entrées ont mêm e partie droite, ce qui donne une différence égale à 0.
12-4
305
Cryptanalyse différentielle et linéaire
A=Y
A=X
▼ A=X
T A =Y X = 0x60000000 Y = 0x00808200 A vec probabilité — 64
F ig. 12.7 - Une caractéristique du DES à deux rondes
paire fausse suggérera une clef aléatoire. Pour trouver la bonne clef, il suffit rassembler assez d’essais pour qu’une clef soit suggérée plus souvent que les autres. En effet, la bonne clef se démarquera des autres alternatives qui sont aléatoires. Ainsi l’attaque différentielle brute sur le DES à n rondes produira la sous-clef de 48 bits utilisée à la ronde n, et les huit bits restants sont obtenus par recherche exhaustive. Il reste des problèmes importants. Tout d’abord les chances de réussite sont faibles avant d’avoir atteind un certain seuil. Avant d’avoir obtenu assez de données, vous ne pouvez pas distinguer la bonne clef au milieu de tout le bruit. Ensuite, l’attaque est trop lourde en pratique : il faut utiliser des compteurs pour assigner des probabilité à 2 48 sous-clefs différentes, la somme de données requise est trop importante pour que cela puisse marcher. B i i i a m et S h a m i r ont modifié leur attaque. Au lieu d ’utiliser une caractéristique à 15 rondes sur le DES à 16 rondes, ils ont utilisé une caractéristique à 13 rondes et quelques astuces pour les rondes restantes. Une caractéristique plus courte avec une probabilité plus grande fonctionnait mieux. Us utilisèrent de plus des mathématiques astucieuses pour obtenir des clefs candidates de 56 bits qui pouvaient être testées immédiatement, ce qui permet de se passer des compteurs. Cette attaque réussi dès que la bonne paire est trouvée ; cela évite le seuil et donne une probabilité linéaire de succès. Si vous avez 1000 fois moins de paires, vous avez mille fois moins de chances de succès. Cela paraît
Chapitre 12
306
Le D ES
terrible, mais c ’est beaucoup mieux que le seuil. Il reste toujours une petite chance de succès immédiat. Les résultats sont très intéressants. Le tableau 12.14 est un résumé de l’attaque contre le DES avec différents nombres de rondes [178]. T ab. 12.14 - Attaques par cryptanalyse différentielle contre le DES Complexité de l’analyse
2 38
Textes en clair analysés 4
2 44
2
2 32*
2 24
2 43
2 14
2 15
11
2 31
2 47
2
2 32*
12
2 31
2 47
2 21
2 21
13 14 15 16
2 39
2 52
2
2 32*
2 39
2 5ï
2 29
2 29
2 47
2 56
27
2 37
2 47
2 55
Nombre de rondes
Textes en clair choisis
Textes en clair connus
8
2 14
9
2 24
10
2 36
29
2 37
La complexité de l’analyse peut être fortement réduite pour ces variantes en utilisant quatre fois plus de textes en clair avec la méthode de la clique.
La meilleure attaque contre le DES complet à 16 rondes nécessite 247 textes en clair choisis. Ceci peut être converti en une attaque à texte en clair connu, mais qui néces site 255 textes en clairs connus. De plus cela requiert 237 opérations du DES durant l’analyse. La cryptanalyse différentielle marche contre le DES et d ’autres algorithmes similaires avec des tables-5 constantes. L’attaque dépend fortement de la structures des tablesS ; il se trouve que celles du DES sont optimisées contre la cryptanalyse différentielle. L’attaque marche contre le DES sous tous ses modes opératoires - E C B , C B C , CFB et O F B - avec la même complexité [178]. La résistance du DES peut être améliorée en augmentant le nombre de rondes. La cryptanalyse différentielle (à texte en clair choisi) contre le DES avec 17 ou 18 rondes prend à peu près le même temps que la recherche exhaustive [167]. Avec 19 rondes ou plus, la cryptanalyse différentielle devient impossible car elle nécessite plus de 2 64 textes en clair choisis : rappelez-vous que le DES utilise des blocs de 64 bits, de sorte qu’il n’y a que 2 64 textes en clair possibles11. Voici quelques points importants. Premièrement, l’attaque est largement théorique. Le temps énorme et les données requises pour monter une attaque cryptanalytique diffé rentielle mettent celle-ci hors de portée de presque tout le monde: pour collecter les données nécessaires à cette attaque, il faut chiffrer, au taux de 1,5 mégabit par seconde, un flot de textes en clair choisis pendant presque trois ans. Deuxièmement, ce doit être une attaque à texte en clair choisi. La cryptanalyse différentielle marche aussi pour une attaque à texte en clair connu, mais vous devez parcourir toutes les paires « texte en clair-texte chiffré » pour trouver celles qui conviennent. Pour un DES complet à 16 11. En général, on prouve q u ’un algorithm e résiste à la cryptanalyse différentielle en prouvant que le nom bre de textes en clair nécessaires pou r l'attaque est plus grand que le nom bre de textes en clair possibles.
12. J,
Cryptanalyse différentielle et linéaire
307
rondes, cela rend l’attaque légèrement moins efficace que l’attaque exhaustive (l’at taque cryptanalytique différentielle nécessite 2 5 5 ,1 opérations et l’attaque exhaustive 255 opérations). Tout le monde admet que le DES correctement réalisé est encore sûr par rapport à la cryptanalyse différentielle. Pourquoi le DES est-il si résistant à la cryptanalyse différentielle? Pourquoi les tablesS sont-elles optimisées pour rendre cette attaque aussi difficile que possible? Pourquoi comporte-t-il le nombre de rondes nécessaires mais ni plus ni moins? Parce que les concepteurs étaient au courant. Don C o p p e r s m i t h d’IB M a récemment écrit [376, 379] : « La conception tirait avantage de certaines techniques cryptanalytiques, plus précisément la technique de « cryptanalyse différentielle » qui n’ap paraissait pas dans la littérature publiée. Après des pourparlers avec la NSA, il fut décidé que la divulgation des considérations utilisée pour la conception révélerait la technique de cryptanalyse différentielle, une tech nique puissante qui pouvait être utilisée contre de nombreux algorithmes de chiffrement. Cela aurait altéré l’avantage compétitif sur d’autres pays dont les Etats-Unis jouissaient dans le domaine de la cryptographie. » Adi S h a m i r répondit à cela en mettant C o p p e r s m i t h au défi de dire qu’il n’avait pas trouvé d’attaque plus puissante depuis lors. COPPERSMITH a choisi de rester silencieux à ce propos [1431].
Cryptanalyse par clefs corrélées Le tableau 12.3 donne le nombre de bits de décalage de la clef après chaque ronde : 2 bits après chaque ronde, excepté 1 bit après les rondes 1, 2, 9 et 16. Pourquoi? La c r y p t a n a l y s e p a r c l e f s c o r r é l é e s examine les différences entre des clefs diffé rentes, comme la cryptanalyse différentielle. Cette attaque est différente de toutes les attaques déjà présentées : le cryptanalyste choisit une relation entre une paire de clefs, mais ne choisit pas les clefs elles-mêmes. Les données sont chiffrées avec les deux clefs. Dans la version à texte en clair connu, le cryptanalyste connaît le texte en clair et le texte chiffré de données quelconques chiffrées avec la clef. Dans la version à texte en clair choisi, le cryptanalyste a la possibilité de choisir les textes en clair chiffrés avec les deux clefs. Un DES modifié, où la clef est décalée de 2 bits après chaque ronde, est moins sûr. Eli B i h a m a développé une attaque par clefs corrélées qui casse cette variante en utilisant 2 1 7 clefs choisies - textes en clair choisis, ou 2 3 3 clefs choisies - textes en clair connus [165, 169]. Cette attaque n’est pas réalisable, mais elle est intéressante pour trois raisons. Tout d’abord, c ’est la première attaque contre le système de génération de sous-clefs de l’algorithme. Deuxièmement, cette attaque est indépendante du nombre de rondes de l’algorithme ; elle est tout aussi efficace sur le DES à 16, 32 ou 1000 rondes. Et troisiè mement, le DES résiste à cette attaque. Les variations dans les rotations contrecarrent la cryptanalyse par clefs corrélées.
Chapitre 12
308
Le D E S
Cryptanalyse linéaire La c r y p t a n a l y s e l i n é a i r e est un autre type d ’attaque cryptanalytique inventée par Mitsuru M a t s u i [1024, 1026, 1025]. Cette attaque utilise des approximations linéaires pour décrire l’action d’un algorithme de chiffrement par blocs (en l’occurrence, le DES). Cela veut dire que si vous combinez par ou exclusif une partie des bits du texte en clair, une partie des bits du texte chiffré, puis les deux résultats ensembles, vous obtenez un simple bit qui est la combinaison par ou exclusif de certains bits de la clef. Ceci est une approximation linéaire qui est valide avec une probabilité p. Si p ^ 1/ 2 , il est possible d’exploiter ce biais. En rassemblant des textes en clair et leurs textes chiffrés associés, vous pouvez devinez la valeur des bits de la clef. Plus vous rassemblez de données, plus votre clef supposée est fiable. Plus le biais est important, plus les chances de succès sont grandes, pour la même quantité de données. Comment trouver de bonnes approximations linéaires pour le D E S? Trouvez de bonnes approximations linéaires sur une ronde, puis et joignez les ensembles12. Regardons les tables- S. Il y a 6 bits en entrée et 4 en sortie. Les bits en entrée peuvent être combinés de 63 manière utiles (2 6 — 1), et ceux en sortie peuvent être combinés de 15 manière utiles. Maintenant, pour chaque table-5, vous pouvez estimez pour une entrée choisie aléatoirement la probabilté qu’une combinaison par ou exclusif en entrée soit égale à une combinaison par ou exclusif en sortie. S’il y a une combinaison présentant un biais assez important, alors la cryptanalyse linéaire peut marcher. Si les approximations linéaires ne sont pas biaisées, alors elles sont valides pour 32 des 64 entrée possibles. Je vous épargne les pages de tables, mais sachez que la tableS la plus biaisée est la cinquième. Plus précisément, le deuxième bit est égal à la combinaison par ou exclusif des 4 bits d ’entrée pour seulement 12 entrées. Ceci se traduit par une probabilité de 3/16, ou un biais de 5/16, et constitue le biais le plus extrême de toutes les tables-S1. ( S h a m i r avait remarqué cela [1430], sans trouver de moyen de l’exploiter.) La figure 12.8 montre comment faire de cela une attaque contre la fonction résultant d’une ronde de DES. Le bit en entrée de la cinquième table-S est f>26 13- Les 4 bits de sortie de la cinquième table-S sont Cn, c 1 g, C19 et c2o •Nous pouvons suivre le bit f>26 de l’entrée à la table-S. Le bit a 26 est combiné par ou exclusif au bit K z^6 de la sous-clef pour obtenir f>26. Et le bit X n devient a 2 6 via la permutation expansive. Après la table-S, les 4 bits de sortie deviennent via la table-P 4 des bits de sortie de la fonction résultant de la ronde: I 3 , lg , E14 et Y25. Cela signifie que l’équation suivante est vérifiée avec probabilité 1/2 — 5/16 : X n © L3 © L3 © 5^8 © E14 © Y25 — R i ,26
Les approximations linéaires de différentes rondes peuvent être combinées d’une ma nière similaire à celle présentée pour la cryptanalyse différentielle. La figure 12.9 est une approximation sur 3 rondes avec une probabilité de 1/2 —0,0061. Chaque approxi mation est de qualité variable : la dernière est très bonne, la première est assez bonne, et celle du milieu est mauvaise. Mais les trois approximations sur une ronde ensembles donnent une très bonne approximation sur trois rondes. 12. Vous pouvez à nouveau ignorer les perm utations initiale et finale qui n ’affectent pas l’ attaque. 13. Je num érote les bits de gauche à droite et de 1 à 64. M a t s l 'I n ’ a pas tenu com pte de cette convention avec le D E S, et il num érote ses bits de droite à gauche et de 0 à 63. C ela suffirait à vous rendre fou.
12.J,
Cryptanalyse différentielle et linéaire
F ig .
309
12.8 - Une approximation linéaire sur une ronde du DES.
L’attaque de base consiste à utiliser la meilleure approximation linéaire du DES à 16 rondes. Cela requiert 247 blocs de textes en clair connus, et donnera un bit de la clef. Ce n ’est pas très utile. Si vous échangez le rôle du texte en clair et du texte chiffré, et si vous utilisez le déchiffrement au lieu du chiffrement, vous pouvez obtenir deux bits de la clef. Ce n ’est toujours pas très utile. Il est posible d’affiner la technique. Utilisez une approximation linéaire sur 14 rondes pour les rondes 2 à 15. Devinez les 6 bits de la sous-clef correspondant à la cinquième table-S pour la première ronde et la dernière (cela fait 12 bits de la clef en tout). En fait, vous effectuez 2 12 cryptanalysés linéaires en parallèle et vous sélectionnez la bonne vis à vis des probabilités. Cela donne les 12 bits et 626 en plus, et en inversant texte en clair et texte chiffré, on obtient 13 autres bits. Pour trouver les 30 bits restant, utilisez une recherche exhaustive. Il y a d’autres astuces, mais le principe de base est là. Utilisée contre le DES à 16 rondes, cette attaque permet de trouver la clef avec 243 textes en clair connus en moyenne. Une réalisation logicielle de cette attaque a décou vert une clef de DES en 50 jours avec 1 2 stations de travail HP9735. C ’est l’attaque la plus efficace contre le DES au moment d’écrire ces lignes. La cryptanalyse linéaire dépend fortement de la structure des tables-S 1 et celles du DES ne sont pas optimisées contre ce type d’attaques. En fait l’ordre des tables-S choisi pour le DES figure parmi les 9 à 16 % de ceux qui offrent le moins de protection
310
Chapitre 12
B
17
A =[3,8,14,25]
B = [8 ,14,25]
Le D ES
________ avec probabilité 1/2+6,1_________
F i g . 12.9 - Une approximation linéaire sur trois rondes du DES.
contre la cryptanalyse linéaire [1027]. Selon Don COPPERSMITH [376, 379], la résistence à la cryptanalyse linéaire « ne faisait pas parti des critères de conception du DES ». Soit ils n’avaient pas connaissance de la cryptanalyse linéaire, soit ils connaissaient une autre technique encore plus puissante dont le critère de résistence prenait le dessus. La cryptanalyse linéaire est plus récente que la cryptanalyse différentielle, et elle peut connaître plus d ’améliorations de performances durant les prochaines années. Quelques idées sont proposées dans [1281, 801], mais il n’est pas clair qu’elles puissent être utilisées contre le DES complet. Cependant, elles fonctionnent très bien contre les variantes avec moins de rondes.
12.5
Les critères réels de conception
311
Directions futures Certains travaux ont visé à étendre le concept de cryptanalyse différentielle à un niveau plus haut de différentielles [703, 168, 938, 858, 861]. Lars K n u d s e n utilise ce qu’il appelle les différentielles partielles pour attaquer le DES à 6 rondes ; cela nécessite 32 textes en clair choisis et 20000 chiffrement [861]. C ’est encore trop récent pour savoir si ces extensions faciliteront l’attaque du DES à 16 rondes. Une autre voie d ’attaque est la c r y p t a n a l y s e d i f f é r e n t i e l l e - l i n é a i r e qui consite à combiner la cryptanalyse différentielle et la cryptanalyse linéaire. Susan L a n G F O R D et H e l l m a n ont une attaque contre le DES à 8 rondes qui trouve 10 bits de la clef avec une probabilité de succès de 80 avec 512 textes en clair choisis et une probabilité de succès de 95 avec 768 textes en clair choisis [949]. Après l’attaque, une recherche exhaustive de l’espace des clefs restantes (246 clefs possibles) est nécessaire. Si cette attaque est comparable en temps aux attaques précédentes, elle nécessite beaucoup moins de textes en clair. Cependant, elle ne semble pas s’étendre facilement à plus de rondes. Mais cette attaque est encore récente et le travail continue. Il est possible qu’il y ait une percée dans les années à venir. Il est possible que la combinaison de cette attaque avec la cryptanalyse différentielle de haut niveau puisse porter ses fruits. Qui sait?
12.5
Les critères réels de conception
Une fois la cryptanalyse différentielle devenue publique, IB M publia les critères de conception des tables-S' et des tables-P [376, 379]. Les critères pour les tables-S' sont: Chaque table-S 1 prend
6
bits en entrée et 4 en sortie14.
Aucun bit de sortie d’une table-S' ne devrait s’approcher d’une fonction linéaire des bits d ’entrée. - Si l’on fixe les bits les plus à gauche et les bits les plus à droite d’une table-S1, et si l’on fait varier les 4 bits du milieu, toutes les sorties possibles de 4 bits sont obtenues exactement une fois. - Si deux vecteurs d ’entrée à une table-S ne diffèrent que d ’un bit, les vecteurs de sortie doivent différer d’au moins deux bits. - Si deux vecteurs d’entrée à une table S ne diffèrent que par les deux bits du milieu, les vecteurs de sortie doivent différer d’au moins deux bits. Si deux vecteurs d’entrée à une table-S 1 diffèrent par les deux premiers bits et sont identiques sur les deux derniers, les vecteurs de sortie ne doivent pas être les mêmes. - Pour toute différence non nulle entre deux vecteurs d’entrée, parmi les 32 paires possibles de vecteurs présentant cette différence, au plus 8 doivent donner la même différence en sortie. Un critère similaire au précédent, mais dans le cas de trois tables-S 1 actives. 14. C ’était la taille m axim ale intégrable dans une pu ce avec la technologie de 1974.
312
Chapitre 12
Le DES
Les critères pour les tables-P sont r Les quatre bits de sortie de la table .S' de la ronde i sont distribués de manière que deux d’entre eux affectent les deux bits du milieu de la table-S^ de la ronde i + 1 et que les deux autres en affectent les deux derniers bits. - Les quatre bits de sortie de chaque table-S' affectent six autres tables S ; deux d’entre eux n’affectent jamais la même table-S. - Si le bit de sortie d’une table-S affecte l’un des deux bits du milieu d’une autre table-S, alors aucun bit de sortie de cette autre table S ne peut affecter l’un des bits du milieu de la première table-S. L’article continue sur l’explication des critères. Il est assez facile de générer des tablesS de nos jours, mais cela constituait une tâche hardue au début des années 1970. Une citation de T u c h m a n révèle qu’ils ont fait des tourner des ordinateurs durant des mois pour mitonner les tables S.
12.6
Variantes du DES
Surchiffrement DES Certaines réalisations utilisent le DES triple (voir figure 12.10). Comme le DES n’est pas un groupe, le texte chiffré résultant est plus difficile à retrouver par recherche exhaustive : 2 1 1 1 tentatives au lieu de 256. Voir le paragraphe 8.2 pour plus de détails.
FiG. 12.10
DES triple
Le DES avec des sous-clefs indépendantes Une autre variante utilise une sous-clef différente pour chaque ronde, au lieu de les engendrer à partir d ’une seule clef de 56 bits [902]. Comme il faut 48 bits de clef à
12.6
Variantes du D E S
SIS
chacune des 16 rondes, cela signifie que la longueur de clef de cette variante est de 768 bits. Cette variante augmenterait radicalement la difficulté d’une attaque exhaustive contre l’algorithme; cette attaque aurait une complexité de 2 768. Cependant, une attaque par collisions (voir § 15.1) est possible. Cela réduit la com plexité de l’attaque à 2 384 ; ce qui est encore assez grand pour toute exigence de sécurité concevable. Bien que l’utilisation de sous-clefs indépendantes contrecarre la cryptanalyse linéaire, la cryptanalyse différentielle s’applique encore à cette variante qui peut être cassée avec 261 textes en clair choisis (voir le tableau 12.15) [174, 178]. Il semble qu’il n’existerait aucune modification du plan de génération de clefs qui puisse rendre le DES beaucoup plus fort.
DESX DESX est une variante du DES de la R S A D a t a S e c u r i t y , I n c . qui a été incluse dans le programme de courrier électronique sûr M a i l S a f e en 1986 et la « boîte à outils » B SA FE en 1987. Le D E S X utilise une technique appelée le blanchiment (voir § 15.6) pour embrouiller les entrées et les sorties du DES. En plus de la clef de DES de 56 bits, le D E SX a une clef de blanchiment de 64 bits. Ces 64 bits sont combinés par ou exclusif au texte en clair avant la première ronde du DES. 64 bits supplémentaires, calculés à l’aide d ’une fonction à sens unique à partir de la clef totale de 1 2 0 bits, sont combinés par ou exclusif au texte chiffré après la dernière ronde [162]. Le blanchiment rend le D E S X nettement plus fort que le DES contre une attaque exhaustive ; l’attaque fera 2120/n opérations avec n textes en clair connus. Il augmente aussi la sécurité face à la cryptanalyse différentielle et à la cryptanalyse linéaire ; ces attaques nécessitent 261 textes en clair choisis et 260 textes en clair connus respectivement [1350].
crypt(3) CRYPrr(3 ) est une variante du DES que l’on trouve dans les systèmes U NIX. Elle est
principalement utilisée comme fonction à sens unique pour les mots de passe, mais elle est aussi parfois utilisée pour le chiffrement. A la différence du DES, CRYPT(3) a une permutation expansive qui dépend de la clef avec 2 1 2 permutations possibles. Le but initial était d ’empêcher l’utilisation des puces DES disponibles dans le commerce pour construire un casseur de mots de passe.
Le DES généralisé Le DES généralisé (G D E S pour « Generaltzed DES >) a été inventé à la fois pour ac célérer le DES et pour renforcer l’algorithme [1386, 1387]. La taille des blocs augmente tandis que la quantité de calcul reste constante. La figure 12.11 donne le diagramme du G DES. Le G D E S opère sur des blocs de taille variable de texte en clair. Les blocs à chiffrer sont divisés en q sous-blocs de 32 bits dont le nombre exact dépend de la taille globale (il est libre, mais doit être fixé pour chaque réalisation). En général, q est égal à la taille de bloc divisé par 32. La fonction f est calculée une fois par ronde sur le bloc le plus à droite. Le résultat est combiné par ou exclusif avec toutes les autres parties, qui sont alors décalées circulairement vers la droite. Le G D E S utilise un nombre variable de rondes, n. Il y a
Chapitre 12
314
Le DES
Texte en clair
i *o(I)
H
i
V 2)
i
*o(3)
- “V
'
t
^X
i x
f
,r
\
_
X
4
B,(q-o
b,<3>
*!«>
i B 0(V
k2 B2l 0
*
j
2<2>
[ g 2(q-nj
|
b 7(q)
■\— _ —
■ «« « tld)
(2)
B, (3)
~ ~ r~
Texte chiffré
F i g . 12.11
- Aperçu du G D ES
une légère modification pour la dernière ronde, de manière à ce que le chiffrement et le déchiffrement ne diffèrent que par l’ordre des sous-clefs (tout comme le DES). En fait, si q = 2 et n — 16, c'est le DES. B i h a m et S h a m i r [174, 175] ont montré qu’en utilisant la cryptanalyse différentielle, le G DES avec q = 8 et n = 16 peut être cassé avec seulement 6 textes en clair choisis. Si des sous-clefs indépendantes sont aussi utilisées, 16 textes en clair choisis sont nécessaires. Le G D E S avec q = 8 et n = 22 peut être cassé avec 48 textes en clair choisis, et casser le G D ES avec q = 8 et n = 31 ne nécessite que 500000 textes en clair choisis. Même le G D E S avec q — 8 et n = 64 est plus faible que le DES ; il faut 249 textes en clair choisis pour le casser. En fait, tout schéma G D E S qui est plus rapide que le DES est aussi moins sûr (voir le tableau 12.15).
Une variante de ce concept a récemment vu le jour [1593]. Il est probable qu’elle ne soit pas plus sûre que le GDES original. En général, toute variante du DES à largeur de bloc plus grande qui est plus rapide que le DES a de grandes chances d ’être aussi moins sûre que le DES.
12.6
Variantes du D E S
315
DES avec d ’autres tables—S D’autres modifications du DES sont centrées sur les tables-S. Certaines conceptions rendent l’ordre des tables-S variable. D ’autres concepteurs ont rendu le contenu des tables-S lui-même variable. B i h a m et S h a m i r montrèrent [177, 178] que la concep tion des tables-S, ainsi que leur ordre lui-même étaient optimisés pour résister à la cryptanalyse différentielle : « Le changement de l’ordre des huit tables-S du DES (sans changer leur valeur) rend aussi le DES nettement plus faible: le DES avec 16 rondes d ’un autre ordre particulier peut être cassé en 238 étapes environ... On peut montrer que le D ES avec des tables-S aléatoires est très facile à casser. Même des changements minimes d’une entrée d’une table-S du DES peuvent rendre le DES plus facile à casser. » Les tables-S du D ES n’ont pas été optimisées contre la cryptanalyse linéaire. Il existe de meilleures tables-S que celles qui vont avec le DES, mais choisir en aveugle de nouvelles tables-S est une mauvaise idée. Le tableau 12.15 [174, 176] donne la liste de quelques modifications du DES et le nombre de textes en clair choisis nécessaires pour en faire la cryptanalyse différentielle. Une modification non évoquée dans la liste qui consiste à combiner les moitiés de droite et de gauche en utilisant l’addition modulo 24 au lieu du ou exclusif est 2 17 fois plus difficile à casser que le DES [690].
Tab.
12.15
Attaques par cryptanalyse différentielle contre des variantes du DES
Opération modifiée DES complet (aucune modification) Permutation-P Permutation identité Ordre des tables-S Ou exclusif par addition Tables S : Aléatoires Permutations aléatoires Une entrée Tables uniformes Suppression de l’expansion E Ordre de E et ou exclusif de sous-clef G D E S (largeur q = 8) : 16 rondes 64 rondes ^i n t r t • » • ■ » »
Nombre de textes en clair choisis1” 247 (clef dépendante) Ne peut pas être restreint 2I9 2ss 239, 231 218 --- 220 2S3 _ 241 233 226 226 244 6, 16 249 (clef indépendante)
le o u e x c l u s i f est remplacé par l’addition ; des entrées séparées par un trait d ’union indiquent l’intervalle du nombre de textes en clair choisis nécessaires en fonction des nombres aléatoires.
316
Chapitre 12
Le DES
RDES RDES est une variante du DES où l’échange des moitiés gauche et droite n’est pas toujours fait, cela dépend de la clef [893]. Les échanges sont fixés en fonction de la clef uniquement. Cela veut dire qu’il y a 215 possiblités pour les 15 échanges dépendants de la clef, et que la variante ne résiste pas à la cryptanalyse différentielle [817, 894, 119]. Le R D E S possède de nombreuses clefs faibles. En fait, presque toutes les clefs sont plus faibles qu’une clef typique du DES. Cette variante ne devrait pas être utilisée. Une meilleure idée consiste à n ’échanger qu’à l’intérieur de la moitié de droite au début de chaque ronde. Une autre idée préférable consiste à faire dépendre les échanges des données en entrée au lieu d’une fonction statique de la clef. 11 y a nombre de variantes possibles [814, 815]. Dans le R D E S-1, les échanges dépendent des données de par le mot de 16 bits au début de chaque ronde. Dans le R D ES-2, il y a échange des octets dépendant des données au début de chaque ronde après les échanges sur 16 bits comme dans le R D E S-1. Et ainsi de suite jusqu’au R D ES-4. R D ES-1 est sûr à la fois contre la cryptanalyse différentielle [815] et la cryptanalyse linéaire [1145]. On peut présumer que le R D E S-2 et les versions suivantes le sont aussi.
snDES Un groupe de chercheur koréens, mené par Kwangjo K i m , a essayé de trouver un jeu de tables-S sûres de manière optimale à la fois contre la cryptanalyse différentielle et la cryptanalyse linéaire. Leur première proposition, connue sous le nom de s2DES, fut présentée dans [835] et on prouva qu’elle était pire que le DES en ce qui concerne la cryptanalyse différentielle [857, 858], Leur proposition suivante, s3DES fut présentée dans [838] et on prouva qu’elle était pire que le DES en ce qui concerne la cryptanalyse linéaire [854, 1498, 1535, 858, 839]. B i h a m suggéra un changement mineur rendant le .s3DES sûr à la fois contre la cryptanalyse linéaire et la cryptanalyse différentielle [172]. Le groupe est retourné à ses ordinateurs et a développé de meilleures techniques pour la conception de tables-S [837, 840]. Ils ont proposé par la suite le s4DES [836] et le s5DES [839, 955]. Le tableau 12.16 donne les tables-S du .s3DES avec les tables-S 1 et 2 inversées, qui sont sûres à la fois face à la cryptanalyse différentielle et la cryptanalyse linéaire. Insérer cette variante dans un DES triple irritera à coup sûr les cryptanalystes.
Le DES avec des tables—S dépendantes de la clef Les cryptanalysés différentielle et linéaire ne marchent que si le cryptanalyste connaît la composition des tables S’ . Si les tables-S sont dépendantes de la clef et choisie par une méthode cryptographiquement sûre, alors les cryptanalysés différentielle et linéaire sont bien plus difficiles. N’oubliez pas cependant que des tables-S aléatoires ont des caractéristiques différentielle et linéaire assez pauvres ; même si elles sont secrètes. Voici une méthode pour utiliser une clef additionnelle de 48 bits afin de générer des tables-S résistantes à la fois aux cryptanalysés différentielle et linéaire [172]. 1. Réordonner les tables S : 2, 4, 6, 7, 3, 1, 5, 8. 2. Sélectionner 16 des bits restants de la clef. Si le premier bit est 1, intervertir les deux premières lignes de la table-S 1 avec les deux dernières lignes de la
12.6
317
Variantes du D E S
Tab.
Table-S 13 14 8 2 14 9 1 4 Table-S 15 8 6 15 9 14 10 5 Table-S 3 13 4 13 5 6 1 11 Table-S 9 0 5 10 10 7 3 9 Table-S 5 15 6 9 15 0 12 5 Table-S 4 3 14 13 13 0 1 7 Table-S 4 10 10 15 2 12 12 6 Table-S 13 10 2 7 4 13 8 11
12.16 - Tables-S du s3DES où les tables-S 1 et 2 sont renversées 1: 0 11 3 14 2: 3 9 5 3 3: 11 1 8 7 4: 7 12 9 15 5: 9 3 10 0 6: 7 11 10 4 7: 15 6 9 3 8: 0 13 14 7
3 13 10 7
10 4 0 11
4 1 7 13
7 14 13 8
9 7 4 2
11 5 8 6
8 15 5 3
12 0 6 5
6 3 15 10
1 10 11 12
15 6 12 0
2 9 1 15
5 12 2 9
14 5 8 15
4 3 2 12
2 12 4 9
9 10 15 0
5 0 3 6
0 13 10 1
11 8 7 2
10 4 6 8
1 11 13 4
13 14 1 11
7 2 11 14
6 1 12 7
12 7 0 13
5 8 11 2
14 7 13 8
8 2 14 13
0 14 3 4
6 11 0 14
4 15 9 6
15 10 2 12
1 12 4 10
12 3 1 15
7 9 10 3
2 5 7 0
10 0 15 9
9 6 12 5
11 6 12 0
12 0 5 6
5 15 0 10
10 3 6 5
6 9 11 12
15 8 3 14
3 13 14 2
1 11 4 1
14 1 2 7
2 7 8 13
8 2 13 4
4 14 15 8
13 4 1 11
10 15 9 6
0 5 3 15
3 12 5 10
14 0 4 9
4 10 14 3
2 8 8 7
12 7 11 2
7 13 1 14
1 4 7 11
13 2 6 8
6 11 12 1
8 14 13 4
U 1 2 13
10 4 9 14
9 2 4 11
0 7 3 8
14 1 7 13
13 8 14 2
15 9 1 10
5 10 15 12
12 5 6 3
6 3 12 5
2 15 8 6
11 0 5 15
1 12 11 0
8 6 2 9
12 0 6 9
2 5 15 0
9 3 10 5
1 12 4 10
6 9 1 15
11 1 5 2
5 8 11 13
0 11 3 4
3 13 0 14
7 14 8 7
14 4 7 11
13 7 14 1
8 2 13 8
7 1 0 14
3 4 9 2
9 14 3 4
14 11 7 13
4 8 10 1
2 15 1 6
15 12 8 5
12 6 2 9
1 10 11 0
5 9 15 12
6 5 5 15
11 0 12 3
8 3 6 10
Chapitre 12
318
Le DES
table- S 1. Si le deuxième bit est 1, intervertir les huits premières colonnes de la tables-S 1 avec les huits dernières. Faire de même pour la table S 2 avec les troisième et quatrième bits. Et ainsi de suite pour les tables-S 3 à 8. 3. Prendre les 32 bits restants. Combiner les quatre premiers par ou exclusif avec chaque entrée de la table-S 1, les quatre suivants avec chaque entrée de la tableS 2, et ainsi de suite. La complexité d ’une cryptanalyse différentielle contre ce système est 251, la complexité d’une cryptanalyse linéaire est 253, la complexité d ’une recherche exhaustive est 2102. Ce qui est appréciable avec cette variante est qu’elle peut être réalisée avec du matériel existant. Plusieurs vendeurs de puces DES proposent des puces avec des tables-S1 chargeables. On peut appliquer cette méthode de génération des tables-S1en dehors de la puce et les charger ensuite. Les cryptanalysés différentielle et linéaire sont infaisables vu le nombre de textes en clairs connus ou choisis qu’elles mettent en jeu, et une recherche exhaustive est inconcevable— tout cela sans pénaliser la rapidité.
12.7
%
_
-
_
A quel point le DES est-il sûr de nos jours ?
La réponse est à la fois facile et difficile. Dans la réponse facile, on ne regarde que la longueur de la clef (voir § 7.1). Une attaque exhaustive menée par une machine spécialement dédiée à cela ne prend que 3,5 heures en moyenne et la machine ne coûte que un million de dollars en 1993 [1599, 1600]. Le DES est si répendu qu’il est naïf de croire que la NSA et ses homologues n’ont pas construit une telle machine. Et rappelez vous que le coût sera divisé par 5 tous les dix ans. Le DES deviendra de moins en moins sûr avec le temps qui passe. Dans la réponses difficile, on essaye d ’estimer les techniques cryptanalytiques. La cryp tanalyse différentielle était connue de la NSA longtemps avant le milieu des années 1970, quand le DES devint un standard pour la première fois. Il est naïf de croire que les théoriciens de la NSA sont resté inactifs depuis lors ; ils ont certainement déve loppé des techniques cryptographiques nouvelles qui s’appliquent au DES. Mais il n’y a aucun fait, seulement des rumeurs. Winn SCHWARTAU a écrit que la NSA avait construit une machine à casser le DES massivement parallèle dès le milieu des années 1980 [1409]. Au moins une telle ma chine a été construite par Harris C o r p avec un C r a y Y -M P comme superviseur. U existe probablement une série d ’algorithmes permettant de réduire la complexité d’une attaque exhaustive de plusieurs ordres de grandeur. Des algorithmes contextuels, ba sés sur le fonctionnement interne du DES, peuvent éliminer des ensembles de clef possibles sur la base de solutions partielles. Des algorithmes statistiques réduisent la taille effective de la clef davantage encore. Et d’autres algorithmes essayent des clefs probables— mots, code A SC II imprimable, etc. (voir § 8.1). La rumeur dit que la NSA peut casser le DES en 3 à 15 minutes, selon la puissance de calcul dont ils disposent. Et ces machines ne coûteraient que 50000 $ chacune en grosse quantité. Une rumeur différente insinue que la N SA possède une large bibliothèque de textes en clair et de textes chiffrés, ces experts peuvent effectuer une sorte de calcul statistique et se diriger ensuite vers une batterie de disques optiques pour récupérer la clef.
12.7
A quel point le D E S est-il sûr de nos jours?
319
Ce ne sont que des rumeurs, mais elles ne me rassurent pas à propos du DES. Il a juste été une cible trop importante pendant trop longtemps. Presque n’importe quelle modification du DES sera plus ennuyeuse ; il se peut que l’algorithme résultant soit plus facile à casser, mais la N SA n’aura peut-être pas les ressources pour se consacrer au problème. Ma recommandation est d ’utiliser la construction de B i h a m pour des tables -S’ dé pendantes de la clef. Elle est facile à réaliser en logiciel et dans les puces qui ont des tables- S chargeables, et elle présente les mêmes performances que le DES. Elle acroît la résistance de l’algorithme contre une attaque exhaustive, rend les cryptanalysés dif férentielle et linéaire plus difficiles, et donne à la N SA quelque chose d’aussi solide que le DES— mais différente— pour s’occuper.
Chapitre 13
Autres algorithmes de chiffrement pair blocs 13.1
Lucifer
À la fin des années 1960, IB M lança un programme de recherche en cryptographie, du nom de L u c i f e r , mené p a r Horst F e i s t e l puis p a r Walt T u c h m a n . L u c i f e r est aussi un algorithme de chiffrement par blocs né de ce projet au début des années 1970 [1489, 1491], En fait, il existe au moins deux algorithmes différents portant ce nom [554, 1499]. Et [554] laissait quelques lacunes dans les spécifications. Tout cela a créé pas mal de confusion. LU CIFER est un réseau de substitution-permutation constitué de briques de base simi laires au DES. Dans le DES, la sortie de la fonction / est combinée par ou exclusif avec l’entrée de la ronde précédente, ce qui donne l’entrée de la ronde suivante. Les tables- S de L u c i f e r prennent quatre bits en entrée et quatre bits en sortie ; l’entrée des tables-S est une permutation au niveau des bits de la sortie des tables-S de la ronde précédente ; l’entrée des tables-S de la première ronde est le texte en clair. Un bit de la clef est utilisé pour choisir la table-S à utiliser parmi deux tables-S possibles1. Contrairement au D ES, il n’y a pas de moyens d’échange entre les rondes, et les blocs ne sont pas coupés en deux. L u c i f e r est doté de 16 rondes, des blocs de 128 bits, et d’une gestion de clef plus simple que celle du DES. En utilisant la cryptanalyse différentielle contre la première version de L u c i f e r , B i h a m et S i i a m i r ont montré que L u c i f e r avec des blocs de 32 bits et 8 rondes pouvait être cassé par 40 textes en clair choisis et 229 étapes; la même attaque peut casser L u c i f e r avec des blocs de 128 bits et 8 rondes par 60 textes en clair choisis et 253 étapes. Une autre attaque cryptanalytique différentielle cassa L u c i f e r à 128 bits et 18 rondes par 24 textes en clair choisis et 221 étapes. Toutes ces attaques utilisent les tables-S1solides du DES. En utilisant la cryptanalyse différentielle contre la deuxième mouture, ils trouvèrent que les tables-S1 étaient nettement plus faibles que celles du DES. Des analyses plus poussées ont montré que plus de la moitié des clefs possibles n’étaient pas sûres [119]. L’attaque à clefs corrélées peut casser L u c i f e r à 128 bits, 1. Dans L u c ife r , cela est représenté par une seule t a b le -T avec 9 bits en entrée et 8 bits en sortie.
Chapitre 13
322
Autres algorithmes de chiffrement par blocs
avec n’importe quel nombre de rondes, par 233 clefs choisies-textes en clair choisis ou par 265 clefs choisies-textes en clair connus [165]. La deuxième version de L u c ife r est encore moins fiable [177, 178, 119].
Certaines personnes croient que L u c i f e r est plus sûr que le DES à cause de la longueur de la clef et du manque de résultats publiés. Ce n’est clairement pas le cas. Aux Etats-Unis, L u c i f e r est couvert par plusieurs brevets : [555, 557, 556, 1490]. Tous ont expiré.
13.2 W.E. M
Madryga adryga
pro po sa cet algorithm e de chiffrem ent p a r blocs en 1984 [1008].
Il
est efficace p o u r des réalisations logicielles : il n ’y a pas de perm utations gênantes, et toutes les opérations sont effectuées sur des octets.
Ses objectifs de conception méritent d ’être cités : 1. Le texte en clair ne peut pas être obtenu à partir du texte chiffré sans l’usage de la clef. (Cela veut seulement dire que l’algorithme est sûr.) 2. Le nombre d’opérations nécessaires pour déterminer la clef à partir d ’un échan
tillon de textes en clair et textes chiffrés doit être égal (statistiquement) au pro duit du nombre d’opérations pour un chiffrement par le nombre de clefs possibles. (Cela veut dire qu’il ne peut pas y avoir d ’attaque à texte en clair plus efficace que t’attaque exhaustive.) 3. La connaissance de l’algorithme ne doit pas diminuer son niveau de sécurité. (Toute la sécurité réside dans la clef.) 4. Un changement d’un bit de la clef doit produire des changements radicaux dans le texte chiffré d ’un même texte en clair, et un changement d’un bit du texte en clair doit produire des changements radicaux dans le texte chiffré avec une même clef. (On appelle cela l’effet d’avalanche.) 5. L’algorithme doit contenir une combinaison non commutative de substitutions et permutations. 6. L’algorithme doit contenir des substitutions et des permutations contrôlées à la fois par les données d ’entrée et par la clef. 7. Des groupes de bits redondants dans le texte en clair doivent être complètement
masqués dans le texte chiffré. 8. La longueur du texte chiffré doit être la même que celle du texte en clair. 9. Il ne doit pas y avoir la moindre relation simple entre les clefs possibles et leurs effets sur le texte chiffré. 10. Toutes les clefs possibles doivent donner un système de chiffrement sûr. (Il ne doit pas y avoir de clefs faibles.) 11. La longueur de la clef et celle du texte doivent être ajustables pour satisfaire les exigences des applications et les niveaux de sécurité requis.
13.2
M adryga
323
12. L ’algorithme doit être réalisable efficacement sur les gros ordinateurs centraux, les mini-ordinateurs, les micro-ordinateurs et sur les dispositifs logiques2. Le DES satisfaisait déjà les objectifs 1 à 9, mais les trois derniers étaient neufs. En faisant l’hypothèse que le meilleur moyen d ’attaquer l’algorithme est l’attaque exhaus tive, la longueur de clef variable devait certainement faire taire les objections de ceux qui pensaient qu’une clef de 56 bits était trop courte. Ils pouvaient réaliser l’algorithme avec la longueur de clefs qu’ils désiraient. Et, pour tout ceux qui avaient déjà essayé une réalisation logicielle du DES, un algorithme qui tenait compte des réalisations logicielles était le bienvenu.
Description de Madryga M a d r y g a a deux cycles imbriqués. Le cycle externe est répété 8 fois (bien que ce nombre puisse être augmenté si la sécurité le justifie) et consiste en une application du cycle interne au texte en clair. Le cycle interne est celui qui transforme le texte en clair en texte chiffré et il est répété une fois pour chaque bloc de 8 bits (octet) du texte en clair. Donc, cet algorithme passe 8 fois successivement sur tout le texte en clair. Une itération du cycle interne opère sur une fenêtre de 3 octets de données, appelée le cadre courant (voir la ligure 13.1). Cette fenêtre avance d ’un octet à chaque itéra tion3. Les 2 premiers octets du cadre courant sont décalés circulairement ensemble d’un nombre de positions variable, tandis que le dernier octet est combiné par ou exclusif avec certains bits de la clef. A mesure que le cadre courant avance, tous les octets sont successivement décalés circulairement et combinés par ou exclusif avec les éléments de la clef. Les rotations successives se superposent avec les résultats des ou exclusif et des rotations précédentes, et les résultats du ou exclusif sont utilisés pour influencer la rotation. Cela rend tout le processus réversible. Comme chaque octet influence les 2 octets à sa gauche et un octet à sa droite, après 8 passes chaque octet du texte chiffré dépend des 16 octets à sa gauche et des 8 octets à sa droite. Lors du chiffrement, chaque itération du cycle interne démarre le cadre courant à l’avant-dernier octet du texte en clair et avance circulairement jusqu’au troisième oc tet avant la fin. Tout d ’abord, la clef entière est combinée par ou exclusif avec une constante aléatoire, puis décalée circulairement à gauche de 3 bits. Les 3 bits de poids faible de l’octet de poids faible du cadre courant sont mémorisés ; ils contrôleront la rotation des 2 autres octets. Après cela, l’octet de poids faible du cadre courant est combiné par ou exclusif avec l’octet de poids faible de la clef. Ensuite, les 2 octets de poids fort sont décalés ensemble circulairement vers la gauche d’un nombre variable de bits (de 0 à 7). Enfin, le cadre courant est décalé vers la droite d ’un octet et tout le processus est répété. Le rôle de la constante aléatoire est de transformer la clef, quelle qu’elle soit, en une suite pseudo-aléatoire. La longueur de cette constante doit être égale à la longueur de la clef, et doit être la même pour tous ceux qui veulent communiquer entre eux. Pour une clef de 64 bits, M a d r y g a recommande la constante : 0x0FlE2D3C4B5A6978. Le déchiffrement est le processus inverse. Chaque itération du cycle interne démarre le cadre courant au troisième octet avant la fin du texte chiffré, et avance circulairement 2. En fait, les fonctions utilisées dans l’algorithm e se limitent au o u e x c lu s if et aux décalages. 3. Les données sont considérées com m e circulaires quand on traite les 2 derniers octets.
Chapitre 13
324
Texte
1
2
3
Déplacement du cadre courant
WF(1)
4
5
Autres algorithmes de chiffrement par blocs
TL-2
6
WF(2)
WF(3)
8 bits
8 bits
8 bits
RQT
TL
Amplitude
Mot à décaler
Transposition
TL-1
-du décalage 3 bits
16 bits Translation '
8 bits
\ Clef
1
2
© KL
3
® Empreinte de clef
1
2
KL
3
F
ig
i
.
13.1 - Une itération de
M
adryga
dans la direction inverse jusqu’au deuxième octet avant la fin du texte chiffré. La clef et les 2 octets de texte chiffré sont décalés vers la droite. Et le ou exclusif est effectué avec les rotations.
Cryptanalyse de Madryga Les chercheurs de la « Queensland. University of Technology » [676] ont examiné M a d r y g a ainsi que d’autres algorithmes de chiffrement par blocs. Ils observèrent que l’algorithme ne montrait pas de signes d ’effet d ’avalanche texte en clair-texte chiffré. De plus, il y avait un plus haut pourcentage de 1 que de 0 dans leurs textes chiffrés de test. Bien que je ne connaisse pas d’analyse formelle de l’algorithme, une évaluation rapide faite par Eli B i i i a m concluait ainsi [167] : L’algorithme ne contient que des opérations linéaires (rotations et ou ex clusif), qui sont légèrement modifiées en fonction des données. Il n’y a rien qui vaille les solides tables-S du DES. De plus, la parité de tous les bits du texte en clair et du texte chiffré est une constante qui ne dépend que de la clef. Donc, si vous avez un texte en clair et son texte chiffré correspondant, vous pouvez prédire la parité du texte chiffré de n’importe quel texte en clair. Rien de bien accablant en soi, mais cela ne me laisse pas une bonne impression de cet algorithme. J’éviterais d ’utiliser M a d r y g a .
13.3
13.3
New DES
325
NewDES
Le N ew D E S a été conçu en 1985 par Robert S c o t t comme une alternative possible au DES [1410, 368]. L’algorithme n’est pas une variante du DES comme son nom pourrait le laisser entendre. Il manipule des blocs de 64 bits de texte en clair mais il a une clef de 120 bits. Il est plus simple que le DES : il n’y a pas de permutations initiale ni finale, et toutes les opérations sont sur des octets entiers -— à aucun moment, l’algorithme ne lit, n’écrit ou ne permute le moindre bit individuellement. (En réalité, NewDES n’a rien à voir avec une nouvelle version du DES, le nom est malheureux.) Le bloc de texte en clair est divisé en sous-blocs de 8 octets: Bo, B\, ... , Be, B7. Ensuite les blocs sont soumis à 17 rondes. Chaque ronde a 8 étapes. A chaque étape, un des sous-blocs est combiné par ou exclusif avec une partie de la clef (il y a une exception), remplacé par un autre octet calculé par une fonction / et ensuite combiné par ou exclusif avec un autre sous-bloc pour devenir ce sous-bloc. La clef de 120 bits de long est divisée en 15 sous-blocs: K 0, K i, ... , A i 3 , K\4. Le processus est plus facile à comprendre visuellement qu’à décrire. La figure 13.2 décrit l’algorithme N ewDES. La fonction f est obtenue à partir de la Déclaration d’indépendance américaine. Voir [1410] pour une description plus détaillée. S c o t t a montré que chaque bit du texte en clair affecte chaque bit du texte chiffré après seulement 7 rondes. Il a aussi analysé la fonction f et n’a pas trouvé de défauts évidents. Charles C o N N E L L [222] a remarqué que le N ew D E S a la même propriété de complémentarité de clef que le DES : si E k { A4) = C alors E K>(A4') — C'. Cela réduit le nombre d’étapes nécessaires pour une attaque exhaustive de 2 120 à 2 119. B i h a m a remarqué que tout changement d ’un octet entier, appliqué à tous les octets de la clef et, tous les octets de données excepté B 5, jouit d’une autre propriété de complémentarité [167]. Ce qui réduit le nombre d’étapes nécessaires pour une attaque exhaustive à 2 112. Ce n’est pas bien inquiétant, mais l’attaque à clefs corrélées de B i h a m peut casser NewDES avec 233 clefs choisies— textes en clair choisis en 24s étapes [114]. Bien que cette attaque soit coûteuse en temps de calcul et largement théorique, elle rend le NewDES nettement plus faible que le DES.
13.4
FEAL
FEAL a été conçu par Akihiro S h i m i z u et Shoji M i y a g u c h i , de N T T J a p o n [1442]. Il utilise une taille de blocs de 64 bits et une clef de 64 bits. L ’idée était de concevoir un algorithme similaire au D ES mais où chaque ronde serait plus sûre que le DES. Avec moins de rondes, l’algorithme irait plus vite. Malheureusement, la réalité est bien en deçà des buts de conception.
Description de FEAL La figure 13.3 donne le schéma d ’une ronde de l’algorithme. Le processus démarre avec un bloc de 64 bits de données (soit du texte en clair, soit du texte chiffré). Au départ, le bloc de données est combiné par ou exclusif avec les 64 bits de la clef. Ensuite le bloc de données est coupé en deux moitiés (gauche et droite). La moitié gauche est combinée par ou exclusif avec la moitié droite pour donner une nouvelle moitié droite, et les deux
326 Ronde 1
Chapitre 13 BO
fiO
fil
fil
fi2
B2
Autres algorithmes de chiffrement par blocs
fi3
B3
fi4
fi4
B5
fi5
B6
fi6
B1
B1
F ig. 13.2 - Algorithme N ew D E S
moitiés passent à travers n rondes (4 à l’origine). À chaque ronde la moitié droite est combinée avec 16 bits dérivés de la clef (en utilisant la fonction / ) et combinée par ou exclusif avec la moitié gauche pour former la nouvelle moitié droite. La moitié droite originale (avant la ronde) forme la nouvelle moitié gauche. Après n rondes (rappelezvous de ne pas échanger les moitiés gauche et droite après la ne ronde) la moitié gauche est à nouveau combinée par ou exclusif avec la moitié droite pour former une nouvelle moitié droite et ensuite les moitiés gauche et droite sont assemblées pour former un
134
327
FEAL
tout de 64 bits. Le bloc de données est combiné par ou exclusif avec 64 bits dérivés de la clef, et l’algorithme se termine. ( V e x te en clair {Texte chiffré})
(K 8, K 9, K 10, K 11) {(K 12, K 1 3 , K 14, K+5)}
64 bits 64 bits 32 bits
32 bits
L 0 { f l8 } L 0 {/? 8 )
R 0 {L&]
£
KQ[ K7)
/? 0 {L 8 }
f
L 1 {/? 7}
£
L7{ Rl )
£
K\{ K6] Rl { L7]
f
K7[ K0} R 7 { L 1}
f
■0
R8{ L0} 64 bits
L 8 {/? 0 }
(K 12, K 13, K 14, K 15) - { ( K 8 ,
K
9,
K
10, K 1 1 )}
{}: Déchiffrement (^Texte chiffré {Texte en clair}^)
F ig. 13.3 - Une ronde de F E A L La fonction / prend 32 bits des données et 16 bits dérivés de la clef et mélange le tout. Le bloc de données est divisé en morceaux de 8 bits, ensuite les morceaux sont combinés par ou exclusif et se remplacent les uns les autres jusqu’à ce que cela sorte par l’autre bout. La figure 13.4 décrit la fonction / . Les deux fonctions ,S'o et Si sont définies par : So{a,b) = décalage circulaire à gauche de 2 bits((a + b) mod 256) Si(a,b) = décalage circulaire à gauche de 2 bits((o + 6 + 1 ) mod 256).
Le même algorithme est utilisé pour le chiffrement et le déchiffrement. La seule diffé rence est que, lors du déchiffrement, les clefs dérivées doivent être utilisées dans l’ordre inverse. La figure 13.5 décrit la fonction permettant d’obtenir les clefs dérivées. D’abord, la clef de 64 bits est divisée en deux. Les moitiés sont combinées par ou exclusif et soumises à la fonction fk comme indiqué sur le diagramme. La figure 13.6 décrit la fonction fk- Les deux entrées de 32 bits sont divisées en blocs de 8 bits puis combinées et substituées
Chapitre 13
328
Autres algorithmes de chiffrement par blocs
So
«0
f (a, b)
ai
TlX
,
a 32 bits
e * —
©■
a2 Cl\, b j . 8 bits
Remarquez que a est partagé en 4 sous - chaînes de 8 bits a,, a2, a3, a4.
F i g . 13.4 - Fonction f
comme indiqué. So et Si sont définies comme ci-dessus. Les blocs de 16 bits de clef sont alors utilisés dans l’algorithme de chiffrement/déchiffrement. Sur un processeur 80286 cadencé à 10 MHz, une réalisation en assembleur de F E A L 32 peut chiffrer les données à la vitesse de 220 kilo-bits par seconde. F E A L - 64 peut chiffrer à la vitesse de 120 kilo-bits par seconde [1110].
F i g . 13.5 - Plan de génération de clef de FE A L
1S-4
329
FEAL
a
32 bits
f K («’b> 50 (X, ,X2 ) = rot2((X, + X2 ) mod 256) 5 i (X ,,X 2) = rot2((X, + X2 + 1 ) mod 256) Xj et X2 : entrées de 8 bits SQet Si : résultats de 8 bits r o t2 (r ) : décalage circulaire à gauche de 2 bits de T
F
ig
.
13.6 - Fonction fk
Cryptanalyse de FEAL FEAL avec 4 rondes, appelé F E A L -4 , a été cryptanalysé avec succès au moyen d’une attaque à texte en clair choisi [458] et a été démoli par la suite [1139]. Cette dernière attaque, lancée par Sean M u r p h y , a été la première attaque par cryptanalyse dif férentielle publiée et n’avait recours qu’à 20 textes en clair choisis. Les concepteurs revinrent à la charge avec un F E A L à 8 rondes [1443, 1444, 1114] dont cryptanalyse fut annoncée à la conférence SECURICOM’89 par B i h a m et S h a m i r [1419]. Une autre attaque à texte en clair choisi utilisant 10000 chiffrements [612] obligea les concepteurs à abandonner F E A L —8 et à concevoir F E A L -N [1109, 1110] avec un nombre variable de rondes (plus grand que 8, bien sûr). B i h a m et S h a m i r appliquèrent leurs techniques de cryptanalyse différentielle contre
FE A L -N et trouvèrent q u ’ils pouvaient casser F E A L -N plus rapidem ent que par recherche exhaustive (avec m oins de 264 chiffrements de textes en clair choisis) pour
32 rondes [176]. Il fallait 228 textes en clair 246,5 textes en cla ir connus p o u r casser F E A L -16. Il fallait 2000 textes en clair choisis ou 237,5 textes en cla ir connus p o u r casser F E A L - 8. F E A L -4 peut être
les versions de l ’algorithm e avec m oins de choisis ou
cassé avec seulement 8 textes en cla ir choisis, sélectionnés soigneusement.
Les concepteurs de F E A L ont aussi défini F E A L —N X, une variante de FE A L, pour accepter des clefs de 128 bits (voir la figure 13.7) [1107, 1110]. B i h a m et S h a m i r ont montré que F E A L -N X avec une clef de 128 bits est aussi facile à casser que F E A L -N avec une clef de 64 bits, quelle que soit la valeur de N [176]. Récemment, F E A L -N (X )S
330
Chapitre 13
Autres algorithmes de chiffrement par blocs
a fait son apparition, il renforce F E A L grâce à une fonction dynamique d’interversion.
F ig. 13.7 - Plan de génération de clefs de F E A L —N X Il y a plus. Une autre attaque contre F E A L -4 ne nécessitant que 1000 textes en clair connus et ne nécessitant que 20 000 textes en clair connus contre F E A L -8 fut publiées dans [1524]. D ’autres attaques se trouvent dans [1557, 1558]. L a meilleure attaque, est celle de Mitsuru M a t s u i et Atsuhiro Y a m a g i s h i [1028]. C ’est la première utilisation de la cryptanalyse linéaire et elle peut casser F E A L -4 avec 5 textes en clair connus,
13.5
REDOC
331
FEAL -6 avec 100 textes en clair connus, et F E A L —8 avec 215 textes en clair connus. Chaque fois que quelqu’un trouve une nouvelle attaque cryptanalytique, il semble qu’il assaye toujours sur F E A L en premier.
Brevets FEAL est breveté aux Etats-Unis [1445] et des brevets sont en attente en Angleterre, en France et en Allemagne. Toute personne désirant une licence pour cet algorithme doit contacter: Intellectual Property Department, NTT, 1-6 Uchisaiwai-cho, 1-chome, Chiyada-ku, 100 Japan.
13.5
REDOC
REDOC II est un autre algorithme de chiffrement par blocs, conçu par Michael W O O D pour C r y p t e c h , I n c . [887, 234]. Il a une clef de 20 octets (160 bits) et manipule des blocs de 80 bits. REDOC II effectue toutes ses manipulations — permutations, substitutions, ou ex clusif avec la clef — au niveau des octets, ce qui rend l’algorithme très efficace en logiciel. R E D O C II utilise des tables de fonctions variables. Contrairement au DES, qui a un ensemble fixe de tables de permutation et substitution (bien qu’optimisées pour la sécurité), R E D O C II utilise un ensemble de tables dépendantes de la clef et du texte en clair (des tables-S1en réalité). R E D O C II se déroule en 10 rondes ; chaque ronde est une série compliquée de manipulations sur les blocs. Une autre caractéristique unique de sa conception est l’utilisation de masques. Ce sont des nombres dérivés de la table de clefs, qui sont utilisés dans le choix des tables pour une fonction donnée d ’une ronde donnée. La valeur des données et la valeur des masques sont toutes deux utilisées pour sélectionner les tables de fonction. En faisant l’hypothèse que l’attaque exhaustive est la plus efficace, R E D O C II est très sûr: 2160 opérations sont nécessaires pour retrouver la clef. Thomas C u s iC K a cryptanalysé une ronde de R E D O C II, mais n’a pas été capable d’étendre cette attaque à plusieurs rondes [404]. En utilisant la cryptanalyse différentielle, B i h a m et S h a m i r ont réussi, à cryptanalyser une ronde de R E D O C II avec 2300 textes en clair choi sis [177], mais cette attaque ne peut pas être étendue à plusieurs rondes. Ils parvinrent également à obtenir la valeur de 3 masques après 4 rondes mais cette attaque ne peut pas être étendue non plus.
REDOC III RED O C III est une version rationalisée de R E D O C II, également conçue par Michael W o o d [1617]. Elle manipule des blocs de 80 bits. La longueur de clef est variable et peut atteindre 2 560 octets (20480 bits). Cet algorithme ne comporte que des ou exclusif des octets de la clef avec des octets du message ; il n’y a ni permutations ni substitutions. 1. Créez une table de clef de 256 clefs de 10 octets en utilisant la clef secrète. 2. Créez deux masques de 10 octets, M\ et M 2 - M\ est le résultat du ou exclusif des 128 premières clefs de 10 octets; M 2 est le résultat du ou exclusif des 128 autres clefs de 10 octets.
332
Chapitre 13
Autres algorithmes de chiffrement par blocs
3. Pour chiffrer un bloc de 10 octets : (a) Calculez le ou exclusif du premier octet du bloc de données avec le premier octet de M i. Sélectionnez la clef dans la table de clefs (celle qui a été calculée à l’étape 1) en utilisant cette valeur comme index (compris entre 0 et 255). Calculez le ou exclusif de chaque octet du bloc de données avec l’octet correspondant de la clef ainsi sélectionnée (sauf pour le premier octet). (b) Calculez le ou exclusif du second octet du bloc de données avec le second octet de M\. Sélectionnez la clef dans la table de clefs (celle qui a été calculée à l’étape 1) en utilisant cette valeur comme index (compris entre 0 et 255). Calculez le ou exclusif de chaque octet du bloc de données avec l’octet correspondant de la clef ainsi sélectionnée (sauf pour le deuxième octet). (c) Continuez ainsi pour tout le bloc de données (octets 3 à 10) jusqu’à ce que chaque octet ait été utilisé pour sélectionner une clef après avoir été combiné par ou exclusif avec M \ , et en combinant chaque octet du bloc de données avec la clef, sauf pour l’octet utilisé pour sélectionner la clef. (d) Répétez les étapes (a) à (c) avec M iCet algorithme est simple et rapide. Avec un processeur 80386 cadencé à 33 MHz, l’algorithme chiffre les données à 2,75 mégabits par seconde. W o o d a estimé qu’une conception VLSI avec pipelines, avec un chemin de données de 64 bits devrait être capable de chiffrer les données à plus de 1,28 gigabit par seconde avec une horloge cadencée à 20 MHz. R E D O C III n’a pas un bon niveau de sécurité [1446], Il est vulnérable à la cryptanalyse différentielle. Il suffit seulement de 223 textes en clair choisi environ pour reconstruire les deux masques.
Brevets et licences Les deux versions de R E D O C sont brevetées aux États-Unis [1616). Des brevets à l’étranger sont en attente. Toute personne désireuse d ’obtenir une licence pour R E D O C II ou R E D O C III doit contacter: Michael C. Wood, Delta Computec, Inc., 6647 Old Thompson Rd., Syracuse, NY 13211.
13.6
LOKI
L O K I est australien et fut présenté en 1990 comme une alternative potentielle au DES [278]. Il utilise des blocs de 64 bits et une clef de 64 bits. La structure générale de l’algorithme et la gestion des clefs étaient basés sur [277, 279], et la conception des tables-S1étaient basées sur [1257]. En utilisant la cryptanalyse différentielle, B i h a m et S h a m i r sont parvenus à casser L O K I avec 11 rondes ou moins, plus vite que par attaque exhaustive [177]. De plus, il existe une propriété de complémentarité par 8 bits qui réduit la complexité d’une attaque exhaustive par un facteur 256 [177, 917, 918]. Lars K n u d se n a montré que LO K I, avec 14 rondes ou moins, est vulnérable à la cryp tanalyse différentielle [853, 855]. De plus, si L O K I est réalisé avec d’autres tables-S', il
13.6
333
LO KI
est probable que l’algorithme de chiffrement résultant sera vulnérable à la cryptanalyse différentielle.
LOKI91 En réponse à ces attaques, les concepteurs de LO K I retournèrent à la planche à dessin et révisèrent leur algorithme. Le résultat est LOKI91 [276]4. Pour rendre l’algorithme plus résistant à la cryptanalyse différentielle et pour supprimer la propriété de complémentarité de la clef, les modifications suivantes ont été apportées : 1. L’algorithme de génération des sous-clefs a été changé de telle manière que les moitiés sont échangées une ronde sur deux au heu de toutes les rondes. 2. L’algorithme de génération des sous-clefs a été changé de telle façon que le déca lage circulaire de la sous-clef de gauche soit alternativement de 12 et 13 bits vers la gauche. 3. Les ou exclusif initial et final du bloc avec la clef ont été supprimés. 4. Les tables-S1ont été modifiées pour mettre en ordre leurs propriétés vis à vis du ou exclusif (pour augmenter leur résistence à la cryptanalyse différentielle), et pour éliminer toute valeur x telle que f(x ) = 0 où f est la fonction résultant de la combinaison des tables- E, des tables-s et des tables -P.
Description de LOKI Le mécanisme de L O K I est similaire à celui du DES (voir la figure 13.8). Le bloc de données est divisé en une moitié gauche et une moitié droite, puis soumis à 16 rondes, tout comme dans le DES. A chaque ronde, la moitié droite est d’abord combinée par ou exclusif avec un morceau de la clef, puis envoyé à travers une permutation expansive (voir tableau 13.1). T a b . 13.1 - Permutation expansive 3 28 27 20 19 12 11
2 26 18 10
1 25 17 9
32 24 16 8
31 20 23 22 15 14 7 6
29 28 27 26 25~ 21 20 19 18 17 13 12 11 10 9 5 4 3 2 1
Les 48 bits de sortie sont divisés en quatre blocs de 12 bits et chaque bloc passe à travers une table-S1de substitution. La table-S fonctionne ainsi : prenez chaque entrée de 12 bits ; utilisez les deux bits de gauche et les deux bits de droite pour former le nombre r, et les huits bits du centre pour former le nombre c. La sortie O de la table-S est la suivante : 0(r,c) = (c + ((r * 17) © Oxf f)&0xf f) 31 modulo Pr Pr est donné par le tableau 13.2. 4. La version précédente fut rebaptisée L O K I89.
334
Chapitre 13
F ig .
Autres algorithmes de chiffrement par bloa
13.8 - Aperçu de LOKI91
Ensuite, les quatres sorties de huit bits sont assemblées pour former un nombre d{ 32 bits qui est envoyé à travers la permutation décrite dans le tableau 13.3. Enfin, Ie moitié droite est combinée par ou exclusif avec la moitié gauche pour devenir la moitié gauche, et la moitié gauche devient la nouvelle moitié droite. Après 16 rondes, le bloc est à nouveau combiné par ou exclusif avec la clef pour produire le texte chiffré. Les sous-clefs sont engendrées à partir d e la clef de manière simple. Tout d’abord, le clef de 64 bits est divisée en une moitié gauche et une moitié droite. A chaque ronde, le sous-clef est la moitié gauche. Cette moitié gauche est décalée circulairement de 12 or
T a b . 13 .2 - Pr
r: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Pr : 375 379 391 395 397 415 419 425 433 445 451 463 471 477 487 488
13.7
K hufu
et K h a f r e
335
T a b . 13.3 -
1
2
3
4
5
6
Table- P de permutation 7
8
9
10
11
12
13
14
15
16
Pr : 375 279 391 395 397 415 419 425 433 445 451 463 471 477 487 488
13 bits vers la gauche, et ensuite les moitiés gauche et droite sont échangées toutes les deux rondes. Tout comme pour le DES, le même algorithme peut être à la fois utilisé pour le chiffrement et le déchiffrement, avec quelques modifications quant à l’utilisation des sous-clefs.
Cryptanalyse de LOKI91 Lars K n u d se n a essayé de cryptanalyser LO K I91 [856, 858]. Il ne parvint pas à utiliser la cryptanalyse différentielle contre l’algorithme révisé. Toutefois, il a trouvé une attaque à texte en clair choisi qui réduit la complexité d ’une attaque exhaustive par îm facteur de presque 4. Cette attaque exploite une faiblesse du plan de génération de clefs, qui est également une faiblesse si l’algorithme est utilisé comme fonction de hachage à sens unique. Une autre attaque à clef corrélée de peut casser LOKI91 avec 232 clefs choisies-textes en clair choisis ou 248 clefs choisies-textes en clair connus [165]. Cette attaque est indépendante du nombre de rondes de l’algorithme. (Dans le même article, B ih a m casse LO K I89 avec 217 textes en clair choisis ou 233 textes en clair connus.) U est facile de rendre LO K I91 résistant à cette attaque ; il suffit d ’éviter le plan de génération de clefs simple.
Brevets et licences LOKI n’est pas breveté. Tout le monde peut le réaliser et l’utiliser. Le code source de la réalisation donnée dans ce livre est protégée par le copyright de l’« University of New South Wales ». Toute personne intéressée par l’utilisation commerciale de cette réalisation (ou une autre réalisation plus rapide de plusieurs ordres de grandeur) doit contacter: Director CITRAD, Department of Computer Science, University Collège, UNSW, Australian Defense Force Academy, Canberra ACT 2600, Australia, Fax : +61-6-268-8581.
13.7
Khufu et Khafre
En 1990, Ralph M e r k l e proposa deux algorithmes. Les principes de base du schéma de conception de ces cryptosystèmes sont [1077] : 1. La taille de 56 bits de la clef DES est trop petite. Compte tenu du coût négligeable de l’augmentation de la taille de la clef (la mémoire est bon marché et disponible à volonté), celle-ci doit être augmentée. 2. Bien que l’utilisation intensive de permutations dans le DES convienne bien aux réalisations matérielles, elles sont très difficiles pour les réalisations logicielles. Les réalisations logicielles les plus rapides du DES utilisent des techniques de
Chapitre 13
336
Autres algorithmes de chiffrement par blocs
recherche dans des tables pour réaliser les permutations. De telles techniques peuvent donner les mêmes caractéristiques de « diffusion » que les permutations et tout en étant plus flexibles. 3. Les tables-S du DES sont petites, avec seulement 64 entrées de 4 bits par table. Maintenant que les mémoires sont plus grandes, les tables- S' doivent grandir. De plus, les 8 tables - S sont utilisées simultanément. Bien que cela convienne pour une réalisation matérielle, cela semble une restriction déraisonnable en logi ciel. Une taille de table-S plus grande et une utilisation séquentielle (plutôt que parallèle) des tables S doivent être employées. 4. Les permutations initiale et finale du DES sont considérées comme inutiles du point de vue de la cryptographie et doivent être supprimées. 5. Toutes les réalisations rapides du DES précalculent les clefs de chaque ronde. Donc, il n’y a pas de raison de ne pas rendre ce calcul plus compliqué. 6. Contrairement au DES, le schéma de conception des tables-S' doit être public. Aujourd’hui, M e r k l e ajouterait probablement à sa liste : « résistant aux cryptanalysés différentielle et linéaire », mais ces attaques étaient inconnues au début des années 90.
Khufu K h u f u est un chiffrement p a r blocs de 64 bits. Les 64 bits de texte en clair sont d’abord divisés en deux moitiés de 32 bits, G et D , qui sont combinées par ou exclusif avec des clefs dérivées. Ensuite, elles sont l’objet d’une suite de rondes similaires au DES. A chaque ronde, l’octet de poids le plus faible de G est utilisé comme entrée d’une table S de 256 entrées. Chaque cellule de table -S a une longueur de 32 bits. La cellule de 32 bits sélectionnée dans la table-S est combinée par ou exclusif avec R. L est ensuite décalé circulairement d ’un multiple de 8 bits, L et R sont échangés et la ronde se termine. La table-S elle-même n’est pas statique, mais change toutes les 8 rondes. Finalement, après la dernière ronde, L et R sont combinés par ou exclusif avec des clefs dérivées et recombinés pour former le texte chiffré. Bien que des parties de la clef soient combinées par ou exclusif avec le bloc chiffré au début et à la fin, le but principal de la clef est d’engendrer les tables-S. Ces tables-S sont secrètes et, par essence, font partie de la clef. L’algorithme de M e r k l e a besoin d’une clef de longueur totale de 512 bits (64 octets) et il fournit un algorithme pour engendrer les tables-S' à partir de la clef. Le nombre de rondes de l’algorithme est libre M e r k l e fit remarquer que le K h u f u à 8 rondes est sensible à une attaque à textes en clair choisis et recommandait 16, 24 ou 32 rondes [1077]. (Il a limité le choix du nombre de rondes à un multiple de 8). Comme K h u f u a des tables S dépendantes de la clef et secrètes, il est immune à la cryptanalyse différentielle. Il existe une attaque différentielle contre le K h u f u à 16 rondes qui trouve la clef à l’aide de 231 textes en clair choisis [613], mais elle ne s’applique pas avec plus de rondes. Si une attaque exhaustive est le meilleur moyen d ’attaquer K h u f u , il est incroyablement difficile à casser. Une clef de 512 bits donne une complexité de 2512 inconcevable dans toutes les circonstances
13.8
RC2
337
Khafre est le second des cryptosystèmes proposés par M e r k l e [1077]5. Le schéma de conception est similaire à celui de K h u f u , excepté qu’il a été conçu pour des appli cations où il n’y a pas de temps de précalcul. Les tables-é> ne dépendent pas de la clef. K h a f r e utilise des tables S fixées. De plus, la clef est combinée par ou exclusif avec le bloc chiffré non seulement avant la première ronde et après la dernière, mais aussi toutes les 8 rondes de chiffrement. M e r k l e postula que des clefs de 64 ou 128 bits seraient utilisées pour K h a f r e et que plus de rondes seraient nécessaires pour K h a f r e que pour K H U F U . Ceci, combiné avec le fait que chaque ronde de K h a f r e est plus compliquée que pour K h u f u , rend K h a f r e plus lent. En compensation, K h a f r e ne nécessite pas de précalcul et chiffre des petites quantités de données plus rapidement. En 1990, B i i i a m et S h a m i r utilisèrent leurs techniques de cryptanalyse différentielle contre K h a f r e [177]. Ils réussirent à casser K h a f r e à 16 rondes avec une attaque à texte en clair choisi qui utilise environ 1500 chiffrements différents. Cela leur prit environ une heure, en utilisant un ordinateur personnel. Convertir cette attaque en une attaque à texte en clair connu nécessiterait environ 238 chiffrements. KHAFRE à 24 rondes peut être cassé par une attaque à texte en clair choisi à l’aide de 253 chiffrements et, par une attaque à texte en clair connu à l’aide de 259 chiffrements. Khafre
Brevets K h u f u et K h a f r e sont tous deux brevetés [1078]. Le code source des algorithmes se trouve dans les brevets. Toute personne désirant acquérir une licence pour l’un des al gorithmes doit contacter : D ire c to r o f L ic e n s in g , Xerox C orp oration , P.O. Box 1600, Stam ford, CT, 0 6 9 0 4-1 60 0 .
13.8
RC2
R.C2 est un algorithme de chiffrement à clef de taille variable conçu par Ron R i v e s t pour la société R S A D a t a S e c u r i t y , I n c . (R S A D S I). Apparemment, « R C » est l’abréviation de « Ron’s Code » (« le code de Ron ») bien qu’officiellement il s’agisse de celle de « Rivest’s Code » (« le code de Rivest » ) 6. Il s’agit dun algorithme « privé » et sa description n’a pas été publiée. Ne pensez pas un seul instant que cela accroisse la sécurité. R C2 a déjà été utilisé dans des produits commerciaux; je suis sûr que quelqu’un l’a déjà désassemblé. Pour autant que je sache, R C 2 n’est pas breveté. RC2 est un algorithme de chiffrement par bloc à clef de taille variable conçu comme un remplaçant du DES. D ’après la société, les réalisations logicielles de R C2 sont trois fois plus rapides que le DES. Il chiffre les données par blocs de 64 bits. R C2 est un algorithme de chiffrement par blocs « mélange-et- broie ». Il n ’y a pas de tables-S [813] ; les deux opérations sont « mélange-et broie » et l’une d’entre elles est chosie à chaque ronde. Selon leur propre littérature [1345] : « ...RC2 n ’est pas un algorithme de chiffrement par blocs itératif. Cela 5. K hufu et K hafre ont été baptisés d ’ après les nom s de deu x pharaons égyptiens. 6. R C 3 fut cassé dans les murs de R S A D S I durant son développem ent ; R C 1 n ’est jam ais sorti des notes de R iv e s t .
Chapitre 13
338
Autres algorithmes de chiffrement par blocs
suggère que R C2 offre plus de protection contre les cryptanalysés différen tielle et linéaire que les autres algorithmes de chiffrement par blocs qui font reposer leur sécurité sur une conception similaire à celle du DES. » La volonté de R SA D SI de ne pas divulguer leur algorithme au public jette un doute sur leurs affirmations. Ils sont prêts à fournir les détails de l’algorithme à des scientifiques disposés à les cryptanalyser. Je ne connais personne qui les ait pris au mot car cela reviendrait à faire le travail d’analyse pour eux. Malgré tout, Ron R i v e s t n’est pas un charlatan. C ’est un cryptographe talentueux et respecté. J’ai assez confiance dans son algorithme, bien que je n’aie pas inspecté personnellement le code. R C 4 qui fut la propriété intelectuelle de R SA D SI a été divulgué sur I n t e r n e t (voir § 17.1), et RC2 ne devrait pas tarder à l’être aussi. Un accord récent entre l’Association des éditeurs de logiciels américaine (SPA pour « Software Publishers Association ») et le Gouvernement américain a accordé un statut d’exportation spécial (voir § 25.14) à R C2 et R C 4 (voir § 17.1). Les produits qui utilisent l’un des deux algorithmes ont droit à une procédure d ’exportation simplifiée, pour autant que les clefs n’aient pas plus de 40 bits de longueur. Une longueur de clef de 40 bits est-elle suffisante? Il y a un total de 240 (~ 1012) clefs possibles. En faisant l’hypothèse que la recherche exhaustive est la méthode la plus efficace de cryptanalyse (une hypothèse forte s’il en est, étant donné que l’algorithme n’a pas été publié) et en faisant l’hypothèse que le cryptanalyste peut tester un million de clefs par seconde, il faudra 12,7 jours pour trouver la bonne clef. Un millier de machines en parallèle trouveront la clef en vingt minutes. Selon R S A D a t a S e c u r i t y , I n c ., bien que le chiffrement et le déchiffrement soient rapides, la recherche exhaustive de clefs ne l’est pas. Un temps significatif est passé à mettre en place le plan de génération de clefs. Bien que ce temps soit négligeable par rapport au temps de chiffrement et de déchiffrement des messages, il ne l’est pas quand on essaie toutes les clefs. Le gouvernement américain n ’autoriserait jamais à l’exportation un algorithme qu’ils ne puissent pas eux-mêmes casser, du moins en théorie. Une autre possibilité d’attaque serait de créer une bande magnétique ou un disque compact (C D ) avec un bloc de texte en clair chiffré selon toutes les clefs possibles. Pour casser un message donné, vous avez juste à lire la bande magnétique et comparer les blocs de texte chiffré avec les blocs de textes chiffrés sur la bande. S’il y a une concordance, essayez la clef candidate et voyez si le message a un sens. Si vous choisissez un bloc de texte en clair assez usuel (que des zéros, le caractère ASCII de l’espace, etc.), cette méthode devrait marcher. La capacité de stockage nécessaire pour un bloc de texte en clair de 64 bits chiffré avec toutes les 1012 clefs possibles est de 8 téra-octets — ce qui est faisable. Pour obtenir des informations concernants les licences pour RC2, contacter RSADSI (voir § 25.4).
13.9
IDEA
La première version du système de chiffrement ID E A , conçu par Xuejia L a i et James a s s e y , a fait surface en 1990 [940]. Il s’appelait PES (« Proposed Encryption Standard »). L ’année suivante, après que B i h a m et S h a m i r eurent présenté la cryp tanalyse différentielle, les auteurs ont renforcé leur système pour résister à cette M
13.9
339
ID E A
attaque [942, 936]. Ils l’appelèrent alors IPES (« Improved Proposed Encryption Standard »). IPES fut rebaptisé ID E A en 1992 (« International Data Encryption Algorithm »). IDEA est basé sur des fondations théoriques impressionnantes et bien que la cryp tanalyse ait fait des progrès contre des variantes avec un nombre de ronde réduit, l’algorithme a l’air solide. De mon point de vue, c ’est le meilleur et le plus sûr des algorithmes disponibles publiquement à ce jour. Le futur d ’ID E A n’est pas encore clair. Rien ne presse pour l’adopter en remplacement du DES, en partie parce qu’il est breveté et nécessite une license pour être utilisé dans les applications commerciales, et en partie parce que les gens attendent encore de voir avec quel brio l’algorithme traversera les prochaines années de cryptanalyse.
Survol d’IDEA IDEA est un algorithme de chiffrement par blocs ; il manipule des blocs de texte en clair de 64 bits. La clef est longue de 128 bits. Le même algorithme est utilisé pour le chiffrement et le déchiffrement. Comme tous les algorithmes de chiffrement par blocs que nous avons déjà vus, ID E A utilise à la fois la confusion et la diffusion. La philosophie de la conception de l’algo rithme est basée sur le « mélange d’opérations de différents groupes algébriques ». Il y a trois groupes algébriques dont les opérations sont mélangées, et toutes ces opérations sont facilement réalisables à la fois en logiciel et en matériel : - ou exclusif, - addition modulo 2 16, - multiplication modulo ID E A ).
2 16
+ 1 (cette opération est un peu la table-S' de
Toutes ces opérations (et ce sont les seules opérations de l’algorithme car il n’y a pas de permutations) manipulent des sous-blocs de 16 bits. Cet algorithme est efficace même sur des processeurs 16 bits.
Description d’IDEA La figure 13.9 donne un aperçu d’ID E A . Le bloc de données de 64 bits est divisé en 4 sous-blocs de 16 bits : X L, X 2 , A 3 et A 4 . Ces 4 sous-blocs deviennent les entrées de la première ronde de l’algorithme. Il y a 8 rondes au total. À chaque ronde, les 4 sous-blocs sont combinés par ou exclusif, additionnés, multipliés entre eux et avec 6 sous-blocs de 16 bits dérivés de la clef. Entre chaque ronde, le deuxième et le troisième sous-bloc sont échangés. Enfin, les quatre sous-blocs sont combinés avec les quatre sous-clefs dans une transformation finale. A chaque ronde, la séquence d’événements est la suivante : 1
. multipliez X i et la première sous-clef ;
2.
additionnez X 2 et la deuxième sous-clef ;
3. additionnez A 3 et la troisième sous-clef ;
Chapitre 13
340
^1
^2
Autres algorithmes de chiffrement par blocs
Xj : sous-bloc de 16 bits de texte en clair Yj : sous-bloc de 16 bits de texte chiffré z[r^ :sous-bloc de clef de 16 bits © : ou exclusif bit à bit de sous-blocs de 16 bits H - adoition modulo 2 16 d’entiers de 16 bits Q : multication modulo 2 16+1 d’entiers de 16 bits avec le sous-bloc nul correspondant à 216
F
ig .
13.9 - Squelette d l D E A
4. multipliez X i et la quatrième sous-clef ; 5. combinez par ou exclusif les résultats des étapes (1) et (3) ; 6. combinez par ou exclusif les résultats des étapes (2) et (4) ; 7. multipliez le résultat de l’étape (5) avec la cinquième sous-clef ; 8. additionnez les résultats des étapes (6) et (7) ; 9. multipliez le résultat de l’étape (8) par la sixième sous-clef ;
^3
^4
13.9
341
ID E A
10. additionnez les résultats des étapes (7) et (9) ; 11.
combinez par ou exclusif les
résultats desétapes (1)
et
(9) ;
12.
combinez par ou exclusif les
résultats desétapes (3)
et
(9) ;
13.
combinez par ou exclusif les
résultats desétapes (2)
et
(10);
14.
combinez par ou exclusif les
résultats desétapes (4)
et
(10).
La sortie de la ronde est constituée des 4 sous-blocs produits par les étapes (11), (13), (12) et (14). Echangez les deux blocs intérieurs (sauf lors de la dernière ronde) et cela donne l’entrée de la ronde suivante. Après la huitième ronde, il y a une transformation finale : 1. multipliez X i et la première sous-clef ; 2. additionnez X% et la deuxième sous-clef ; 3. additionnez X 3 et la troisième sous-clef; 4. multipliez X 4 et la quatrième sous-clef. Enfin, les 4 sous-blocs sont réassemblés pour former le texte chiffré. La création des sous-clefs est aussi facile. L’algorithme en utilise 52 (6 pour chacune des 8 rondes et 4 pour la transformation finale). D ’abord, la clef de 128 bits est divisée en 8 sous-clefs de 16 bits. Ce sont les 8 premièressous-clefs pour l’algorithme(les 6 de la première ronde et les 2 premières de la deuxième ronde).Ensuite la clef est décalée circulairement de 25 bits vers la gauche et à nouveau divisée en 8 sous-clefs. Les 4 premières sont utilisées lors de la deuxième ronde et les 4 autres lors de la troisième ronde. La clef est à nouveau décalée circulairement de 25 bits vers la gauche pour les 8 sous-clefs suivantes, et ainsi de suite jusqu’à la fin de l’algorithme. Le déchiffrement est exactement le même, excepté que les sous-clefs sont inversées et légèrement différentes. Les sous-clefs de déchiffrement sont inverses par rapport à l’addition ou par rapport à la multiplication des sous-clefs de chiffrement. (Pour les besoins d’ID E A , tous les sous-blocs constitués uniquement de zéros représentent 216 = —1 modulo 216 + 1 pour la multiplication; et l’inverse de la multiplication de 0 est donc 0.) Calculer ces inverses prend du temps mais vous ne devez le faire qu’une fois par clef de déchiffrement. Le tableau 13.4 indique les sous-clefs de chiffrement et les sous-clefs de déchiffrement correspondantes.
Vitesse d’IDEA Les réalisations logicielles actuelles d ’ID E A sont presque aussi rapides que le DES. Sur un 80386 cadencé à 33 MHz, ID E A chiffre à la vitesse de 880 kilo-bits par seconde et 2400 kilo-bits par seconde sur un 80486 cadencé à 66 MHz. Vous auriez pu croire IDEA plus rapide, mais les multiplications coûtent cher. Multiplier deux nombres de 32 bits prend 40 cycles d’horloges sur un 80486 (et 10 sur un Pentium). Une réalisation V LSI de P E S chiffre les données à 55 mégabits par seconde à 25 MHz [212, 402]. Une autre puce VLSI, développée à l’ETH de Zürich, conte nant 251000 transistors sur une puce de 107,8 mm2 , chiffre les données à l’aide d’ID EA à la vitesse de 177 mégabits par seconde avec une fréquence d’horloge de 25 MHz [935, 211, 401],
342
Chapitre 13
Ronde 1
:
Sous-clefs de chiffrement et déchiffrement pour I D E A
Sous-clefs de chiffrement p
z
™
2:
Z<2)
z
z
p
3:
z [ 3)
z
P
4:
Z [ 4)
z
P
5:
z
z
f
6:
z [ 6)
z
p
P
z
p
z
p
z
p
z
P
z
p
z
P
z
p
z
f
z
P
P
z
f
z
p
z
z
1
]
Sous-clefs de déchiffrement z<9)- J
p
Z6
z
p
z
p
z
p
z
p
z
p
z
p
z
p
7 (4 ) 6
z
z
p
z
p
p
z
z
p
-
z
p
z
p
z
p
-
z
p
z
p
z
p
-
z
p
z
p
-
z
P
-
z
p
z
P
1
-
z
p
-
z
p
z
p
-
1
-
z
p
-
z
p
z
p
-
1
-
-
1
-
p
-
1
z
p
-
p
z
p
z
ÜN 1.-V 00
T a b . 13.4 -
Autres algorithmes de chiffrement par blocs
z
p
z
p
z
p
z
p
z
p
zp
z
p
-
z
p
z
p
-
z
p
z
p
-
-
7:
z
z
P
z
P
z
p
z
p
z
p
z
P
1
-zp
-
z
p
z
p
-
8:
z [ 8)
z
P
z
P
z
p
z
p
z
p
z
p
-
1
-
z
p
-
z
p
z
p
-
finale:
z [ 9)
z
f
z
P
z
p
z
p
-
1
-
z
p
-
z
P
z
p
-
P
]
zp
z
p
z
z
p
p
]
Cryptanalyse d’IDEA La longueur de clef d’ID E A est de 128 bits — plus du double de celle du DES. En faisant l’hypothèse que l’attaque exhaustive est la plus efficace, il faudrait 2128 (ss 1038) chiffrements pour retrouver la clef. Concevez une puce qui peut tester un milliard de clefs par seconde et mettez-en un milliard à la tâche, cela prendra 1013 années — c ’est plus que l’âge de l’Univers. Une matrice de 1024 puces pourrait trouver la clef en un jour mais il n’y a pas assez d ’atomes de silicium dans l’univers pour construire une telle machine. Là, nous tenons du solide, mais je vais garder un œil sur le débat sur la matière sombre, on ne sait jamais. Peut-être, toutefois, que l’attaque exhaustive n’est pas la meilleure attaque contre ID E A . L’algorithme est encore trop récent pour donner des résultats cryptanalytiques définitifs. Les concepteurs ont fait de leur mieux pour rendre l’algorithme immune à la cryptanalyse différentielle ; ils ont défini le concept de chiffre de Markov et ont montré qu’il est possible de modéliser et de quantifier la résistence à la cryptanalyse différen tielle [942, 937]. (La figure 13.10 montre l’algorithme PES original, à comparer avec l’algorithme ID E A de la figure 13.9 qui a été renforcé pour résister à la cryptanalyse différentielle. Il est étonnant de constater comment quelques changements subtils font une grande différence.) L a i prétend (il donne des indices probants, pas une preuve) qu’ID E A est immune à la cryptanalyse différentielle après seulement 4 de ses 8 rondes. D ’après Eli B i h a m , son attaque à clefs corrélées ne marche pas contre ID EA [114]. Willi M e i e r a examiné les trois opérations algébriques de ID EA, et a fait remar quer que bien qu’étant incompatibles, il arrive qu’on puisse les simplifier de manière à faciliter la cryptanalyse de temps en temps [1058]. Son attaque est plus efficace que l’attaque exhaustive pour l’ID E A à deux rondes (242 opérations), mais moins efficace pour l’ID E A à trois rondes ou plus. ID E A avec ses huits rondes est sûr. Joan D a e m e n a découvert une classe de clefs faibles pour ID E A [408, 413]. Ce ne sont pas des clefs faibles dans le sens où certaines clefs du DES sont faibles, où la fonction de chiffrement est sa propre inverse. Elles sont faibles dans le sens où si elles sont utilisées, un attaquant peut facilement les identifier avec une attaque à texte en clair choisi. Voici, par exemple, une classe de clefs faibles (en hexadécimal) : 0000 0000 0X00 0000 0000 000X XXXX X000
13.9
343
ID E A
F ig . 13.10
Squelette de PES
où « X » peut être n’importe chiffre hexadécimal. Si cette clef est utilisée, la combinaison par ou exclusif de deux textes en clair donne la combinaison par ou exclusif des deux textes chiffrés résultants. Dans tous les cas, la chance d’engendrer une telle clef aléatoirement est extrêmement faible: une sur 296. Il n’y a pas de danger si vous choisissez les clefs aléatoirement et il est facile de modifier ID E A pour qu’il n’y ait plus de clefs faibles : combiner par ou exclusif chaque clef avec OxODAE [413] Je n’ai pas eu connaissance d’autres résultats.
344
Chapitre 13
Autres algorithmes de chiffrement par blocs
Modes opératoires d’IDEA et de ses variantes ID E A peut être utilisé avec n’importe lequel des modes opératoires de chiffrement par blocs décrits dans le chapitre 9. Toute réalisation d’ID E A double serait vulnérable à la même attaque par collisions que pour le DES (voir § 15.1). Toutefois, comme la longueur de clef d’ID E A est plus du double de celle du DES, l’attaque est impossible. Cela nécessiterait de stocker 64 x 2128 bits, ou 1039 octets. Peut-être y a-t-il suffisam ment de matière dans l’univers pour créer un dispositif de mémoire aussi grand mais j ’en doute. Si vous êtes également tracassé par les univers parallèles, vous pouvez utiliser une réalisation de l’ID E A triple (voir § 15.2) : C = E K l ( D K2( E K l ( M ) ) ) .
Elle est immune à l’attaque par collisions. Il n’y pas de raisons de ne pas réaliser ID E A avec des sous-clefs indépendantes. L’algorithme nécessite au total 52 clefs de 16 bits ou une clef de longueur totale de 832 bits. Cette variante est certainement plus sûre, mais personne ne sait à quel point. Une variante naïve pourrait consister à doubler la taille des blocs. L’algorithme mar cherait aussi bien avec des sous-blocs de 32 bits au lieu de 16 bits, et avec une clef de 256 bits. Le chiffrement serait plus rapide et la niveau de sécurité augmenterait d’un facteur 232. En est-il ainsi? La théorie sous-jacente à l’algorithme dépend de la prima lité de 216 + 1 alors que 232 + l n ’est pas premier. L ’algorithme peut être éventuellement être modifié pour marcher mais il aurait des propriétés de sécurité très différentes. L ai dit qu’il serait difficile de le faire fonctionner [935]. Même si ID E A paraît nettement plus sûr que le DES, il n’est pas toujours facile de remplacer l’un par l’autre dans une application existante. Si votre base de données et vos écrans d’interrogation sont conçus pour accepter une clef de 64 bits, il pourrait être impossible de mettre la clef de 128 bits d ’ID E A à la place. Pour ces applications, engendrez la clef de 128 bits en accolant la clef de 64 bits à elle-même. Mais sachez que cette modification affaiblit considérablement IDEA. Si vous êtes plus concerné par la vitesse que par la sécurité, vous pourriez adopter une variante de ID E A avec moins de rondes. Jusqu’à présent, la meilleure attaque contre ID E A va plus vite que la recherche exhaustive pour seulement 2,5 rondes ou moins [1058] ; ID E A serait deux fois plus rapide avec 4 rondes et aussi sûr d ’après ce que je sais.
Avertissement ID E A est un nouvel algorithme. Il n’y a encore aucun article publié quant à sa cryp tanalyse. Est-ce qu’ID E A est un groupe? ( L a i pense que non [935].) Existe-t-il des moyens non encore découverts de casser l’algorithme? ID E A a une base théorique ferme. Toutefois, jour après jour des algorithmes qui paraissaient sûrs sont tombés devant de nouvelles formes de cryptanalyse. Il y a pour le moment plusieurs groupes académiques et militaires qui tentent de cryptanalyser ID E A . Aucun d’entre eux n’a réussi jusqu’ici (et aucun n’est disposé à l’annoncer publiquement), mais qui sait, un jour...
13.10
345
MMB
Brevets et licences L’algorithme de chiffrement par blocs ID E A est breveté en Europe et aux États-Unis [1018, 1019]. Le brevet est détenu par ASCOM-T e c h AG. Il n’y a pas de droits d ’exploitation à payer pour un usage non com mercial. Les utilisateurs commerciaux désireux d ’obtenir une licence doivent contacter: Ascom Systech AG, Dept. CMVV, Gewerbepark, CH-5506, Mâgenwil, S u isse, T e l: +41 64 565-983, Fax: +41 64 565-990, e -m a il: ideaascom .ch.
13.10
MMB
On reproche à ID E A d ’utiliser des blocs de chiffrement de 64 bits. Ce reproche a été émis par Joan D a e m e n avec l’algorithme appelé M M B (pour « Modular Multiplicationbased Block cipher ») [390, 407, 408]. M M B est fondé sur la même théorie de base qu’ID E A : mélanger des opérations de différents groupes algébriques. M M B est un algorithme itératif qui consiste principalement en des étapes linéaires ( ou exclusif et application de la clef) et l’utilisation en parallèle de quatre substitutions non inversibles linéairement. Ces applications sont déterminées par une multiplication modulo 232 — 1 avec des facteurs constants. Le résultat est un algorithme comportant à la fois des blocs de 128 bits et une clef de 128 bits. M M B manipule des sous-blocs de 32 bits de texte ( xq,xi,x 2 ,X3) et des sous-blocs de clef de 32 bits {ko,ki,k2 ,ks}- Cela rend l’algorithme bien adapté à la réalisation sur des processeurs modernes de 32 bits. Une fonction non linéaire / est appliquée 6 fois en alternance avec des o u e x c l u s i f . Voici l’algorithme (toutes les opérations sur les indices sont effectuées modulo 4) : Xi = X i® ki pour i = 0 à 3 f ( x 0 , X i , X 2 , X3 )
Xi = X i® ki+ 1 pour i = 0 à 3 f ( x 0 , X i, X 2 ,X3 )
Xi = X i® ki + 2 pour i = 0 à 3 f ( x o , X l , X 2 , X3 )
Xi = x ,® k i pour i = 0 à 3 f(x o ,X i,x 2,xs )
Xi = X i® kl+ 1 pour i = 0 à 3 f ( x 0 , x 1 , X 2 ,X3 ) Xi
— X i ® ki+ 2 pour i — 0 à 3
f{Xc,X]_,X2,X?).
La fonction / a trois étapes : 1.
Xi
=
Ci- x ï
pour i
=
0 à 3.
2. Si l’octet le moins significatif de xo est 1, alors significatif de x% = 0, alors X 3 — X 3 ® C.
3. Xi = Xi~ 1 © xt © xt+i pour i = 0 à 3.
xq
= Xq © G ; si l’octet le moins
Chapitre 13
346
Autres algorithmes de chiffrement par blocs
L’opération de multiplication de l’étape 1 se fait modulo 232 — 1. Pour les besoins de l’algorithme, si le second opérande est 232 —1, alors le résultat est 232 —1. Les constantes sont (en hexadécimal) : C = 2AAAAAAA c0 = 025F1CDB
Ci = 2c0 c2 — 23c0 c3 = 27c0. La constante C est la constante la « plus simple » avec un poids ternaire élevé, le bit le moins significatif égal à 0 et sans symétrie circulaire. La constante Co a été choisie d ’après certaines caractéristiques. Les constantes Ci, c2 et c3 sont des versions décalées de co pour éviter des attaques basées sur la symétrie. Voir [407] pour plus de détails. Le déchiffrement est le processus inverse. Les étapes 2 et 3 sont leurs propres inverses. L ’étape 1 utilise c~ 1 au lieu de c*. La valeur de c0 1 est 0DAD4694.
Sécurité de M M B La conception de l’algorithme assure que chaque ronde a une diffusion considérable, indépendamment de la clef. Avec ID E A , la diffusion dépend dans une certaine mesure des sous-clefs en question. M M B a aussi été conçu pour ne pas avoir de clef faible à la différence de ID E A . M M B est mort [405]. Bien qu’aucune cryptanalyse n’ait été publiée, ceci est vrai pour plusieurs raisons. Premièrement, il n’a pas été conçu pour résister à la cryptanalyse linéaire. Les auteurs ont choisi ces facteurs multiplicatifs pour leur résistence à la cryptanalyse différentielle mais ils ignoraient la cryptanalyse linéaire. Deuxièmement, Eli B ih a m détient une attaque effective à clefs choisies [167] qui ex ploite le fait que toutes les rondes sont identiques et que les clefs sont simplement décalées cycliquement de 32 bits. Troisièmement, bien que M M B puisse être très effi cace en logiciel, une réalisation matérielle de l’algorithme serait bien plus lente que le DES. D a e m e n conseille à toute personne intéressée dans l’amélioration de M M B de faire une analyse de la multiplication modulaire par rapport à la cryptanalyse, de choisir des nouveaux facteurs et de rendre la constante C différente à chaque ronde [405]. Enfin, il conseille d’améliorer la gestion des clefs en ajoutant des constantes aux clefs de ronde pour éliminer le biais. Il ne le fera pas lui-même, il a conçu 3 -W a y à la place (voir § 14.5).
13.11
C A —1.1
C A est un chiffrement par blocs construit à partir d ’un automate cellulaire, conçu par Howard G u t o w i t z [678, 680, 679]. Il chiffre le texte en clair par blocs de 384 bits et a une clef de 1088 bits (il s’agit en fait de deux clefs, une clef de 1024 bits et une de 64 bits). De par la nature de l’automate cellulaire, cet algorithme est le plus efficace quand il est réalisé avec des circuits intégrés massivement parallèles. C A 1.1 utilise des règles d’automate cellulaire à la fois réversibles et irréversibles. Par une règle réversible, chaque état du réseau découle d ’un unique état prédécesseur, tandis
13.12
S k ip j a c k
347
que par une règle irréversible, un état peut avoir de nombreux états prédécesseurs. Pendant le chiffrement, les règles irréversibles sont itérées en remontant le temps. Pour aller en arrière par rapport à un état, un état est sélectionné aléatoirement parmi les états prédécesseurs possibles. Ce processus peut être répété un grand nombre de fois. L’itération arrière sert donc à mélanger de l’information aléatoire avec le message. CA 1.1 utilise une catégorie particulière de règles partiellement linéaires irréversibles qui sont telles qu’un état prédécesseur aléatoire peut être rapidement construit pour n’importe quel état. Les règles réversibles sont aussi utilisées pour certaines étapes du chiffrement. Les règles réversibles (de simples permutations parallèles sur des sous-blocs de l’état) sont totalement non linéaires. Les règles irréversibles sont entièrement déduites à partir de la clef, tandis que les règles réversibles dépendent à la fois de la clef et des informa tions aléatoires insérées pendant les étapes de chiffrement avec les règles irréversibles. C A -1.1 est construit autour d ’une structure de blocs chaînés. C ’est-à-dire que la ma nipulation des blocs de messages est partiellement découplée du flot d’informations aléatoires insérées durant le chiffrement. Ces informations aléatoires servent à relier les étapes de chiffrement ensemble. Elles peuvent aussi être utilisées pour chaîner le chiffrement d ’un flot de blocs. L ’information dans le lien est engendrée dans l’appareil de chiffrement. C A -1.1 est un nouvel algorithme et il est trop tôt pour se prononcer quant à son niveau de sécurité. G u t o w i t z décrit des attaques possibles, y compris la cryptanalyse différentielle, mais il est incapable de casser l’algorithme. G u t o w i t z offre une prime de 1000 $ à « toute personne qui développerait une méthode applicable pour casser C A -1.1 ». C A -l.le s t breveté [680], mais son utilisation est libre pour des utilisations non com merciales. Toute personne intéressée par une licence pour l’algorithme ou par la prime offerte pour sa cryptanalyse doit contacter : Howard G utow itz, ESPCI, L aboratoire d’ É lectron iq u e, 10 rue Vauquelin, 75005 P a r is , France.
13.12
Skipjack
S k i p j a c k est l’algorithme de chiffrement développé par la NSA pour les puces C l i p p e r et C a p s t o n e (voir § 24.16 et § 24.17). Comme cet algorithme est classé « Top Secret », il n’a jamais été publié. Il sera réalisé uniquement dans des puces résistantes à l’inves tigation. L’algorithme est classé « Top Secret » non pas parce que cela augmente la sécurité, mais parce que la N SA ne veut pas que l’algorithme soit utilisé sans le mécanisme de dépôt de clef C l i p p e r . Ils ne veulent pas que l’algorithme soit réalisé en logiciel et s’étende à travers le monde. S k i p J a c k est il sûr? Si la NSA veut produire un algorithme sûr, elle peut certainement le faire. D ’un autre côté, si la N SA veut concevoir un algorithme avec brèche secrète, elle peut tout aussi bien le faire. Voici ce qui a été publié [1174, 468] :
- C ’est un algorithme itératif de chiffrement par blocs. - La taille des blocs est de 64 bits.
Chapitre 13
Autres algorithmes de chiffrement par blocs
- Il a une clef de 80 bits. - Il peut être utilisé avec les modes opératoires : E C B , C F B , O FB sur 64 bits et C B C sur 1, 8, 16, 32 ou 64 bits. - Il y a 32 rondes par opération simple de chiffrement ou de déchiffrement. - La NSA a démarré la conception en 1985 et a terminé l’évaluation en 1990. La documentation de la puce C l i p p e r de M y k o t r o n x indique que la latence de l’algorithme S k i p j a c k est de 64 cycles d ’horloges. Cela veut dire que chaque ronde prend deux cycles d’horloges : certainement un pour la substitution par table-S1et un pour le o u e x c l u s if final à la fin de la ronde7. La documentation de M y k o t r o n x fait référence à cette opération sur deux cycles sous le nom de « table G » et à l’ensemble sous le nom de « s h if t » (« décalage »). (Une partie de la table-G est appelée table-F, probablement une table de constantes, ou peut-être une table de fonctions.) J ’ai entendu une ru m eur disant que S k i p j a c k utilise 16 tables S , et une autre disant que la m ém oire totale prise p a r les tables -S est de 128 octets. Il y a p eu de chances que ces rum eurs soient toutes les deux vraies.
Une autre rumeur insinue qu’à l’inverse de celles du DES, les rondes de S k i p j a c k n’agissent pas sur des moitiés de bloc. Ceci combiné avec la notion de « décalages » et une déclaration faite par mégarde à la conférence Crypto ’94 comme quoi S k i p j a c k a « une structure interne sur 48 bits » implique qu’il est de conception similaire à SHA (voir § 18.7) mais avec quatre sous-blocs de 16 bits : trois sous-blocs passent à travers une fonction à sens unique dépendant de la clef pour donner 16 bits qui sont combinés par ou exclusif avec le sous-bloc restant. Ensuite le bloc entier est décalé circulairement de 16 bits pour devenir l’entrée de la ronde suivante. Cela implique aussi 128 octets de données pour les tables-.S'. Je suspecte que les tables ,? dépendent de la clef. L a structure de S k i p j a c k est probablem ent sim ilaire à celle d u D E S . L a N SA est consciente de la possibilité de reconstruire l ’algorithm e à p a rtir des puces ; ils ne ris queront pas de nouvelles techniques cryptographiques avancées.
Le fait que la NSA compte utiliser l’algorithme S k i p j a c k pour chiffrer son « Defense Messaging System » (D M S) indique que l’algorithme est sûr. Pour convaincre les scep tiques, le N IST a autorisé « des experts reconnus extérieurs au gouvernement à accéder aux détails confidentiels de l’algorithme pour évaluer ses possibilités et rapporter pu bliquement leurs résultats » [802]. Le rapport préliminaire de ces experts [266] conclut aussi : « En faisant l’hypothèse que le coût de la puissance de calcul est divisé par deux tous les dix-huit mois, c’est dans 36 ans que la difficulté pour casser S k i p j a c k par attaque exhaustive égalera la difficulté de casser le DES aujourd’hui. Donc il n’y a pas de risque significatif que S k i p j a c k soit cassé par attaque exhaustive dans les 30 à 40 ans à venir. « Il n’y a pas de risque significatif que S k i p j a c k puisse être cassé par une méthode d ’attaque basée sur un raccourci, y compris la cryptanalyse différentielle. Il n’y a pas de clefs faibles ; il n’y a pas de propriété de complé mentarité. N ’ayant pas eu le temps d ’évaluer l’algorithme dans les détails, 7. R appelez vous que les perm utations ne prennent pas de tem ps en réalisation matérielle.
13.12
S k i p ja c k
349
les experts ont évalué le processus de conception et d’évaluation de la N SA elle-même. « Le niveau de sécurité de S k i p j a c k contre une attaque cryptanalytique ne dépend pas du caractère secret de l’algorithme. » Bien sûr les experts n’ont pas eu le temps d ’examiner l’algorithme d’assez près pour en arriver à une conclusion par eux-mêmes. Tout ce qu’ils pouvaient faire était de regarder les résultats que la N SA leur a montré. Une question sans réponse est de savoir si l’espace des clefs est linéaire (voir § 8.2). Même si S k i p j a c k n’a pas de clef faible au sens du D E S , des artéfacts du processus de gestion des clefs pourrait rendre certaines clefs plus fortes que d’autres. SK IP JA C K aurait beau avoir 270 clefs fortes, bien plus que le D E S , les chances d ’en choisir une au hasard seraient seulement de 1 sur 1000. Personnellement, je pense que l’espace des clefs de SK IP JA C K est linéaire, mais le fait que personne ne l’ait jamais dit publiquement est inquiétant. S k i p j a c k est breveté, mais le brevet est en train d ’être retiré de la distribution par un accord sur la confidentialité du brevet [1128]. Le brevet ne verra le jour que si l’algorithme S k i p j a c k est reconstitué avec succès depuis une puce. Cela fournit au gouvernement le beurre et l’argent du beurre : la protection d ’un brevet et la confiden tialité d’un marché secret.
Chapitre 14
Encore d’autres algorithmes de chiffrement par blocs 14.1
GOST
GO ST est un algorithme de chiffrement par blocs provenant de l’ex-Union Soviétique [657, 1399]. « GOST » est l’acronyme de « Gosudarstvennyi Standard », ce qui veut dire « standard gouvernemental ». C ’est une sorte d ’analogue du FIPS américain mis à part le fait qu’il se référé à n’importe quel type de standard1. Le numéro de ce standard est 28147-89. Le commité gouvernemental de normalisation soviétique autorisa le standard, quel qu’il soit. Je ne sais pas si G O S T 28147-89 a été utilisé pour des messages classés secrets ou seulement pour des besoins civils. Une remarque préliminaire spécifie que l’algorithme « remplit toutes les exigences cryptographiques et qu’il n’y a pas de limite sur le de gré de confidentialité des informations à protéger ». J’ai entendu qu’il fut initialement utilisé pour des communications à haut degré de confidentialité, y compris des com munications militaires classées, mais sans en avoir la confirmation.
Description de GOST GOST utilise des blocs de 64 bits et une clef de 256 bits. La clef comporte d’autre élé ments suplémentaires qui seront présentés plus loin. L ’algorithme consiste en l’itération sur 32 rondes d’un algorithme de chiffrement simple. Pour chiffrer, il faut commencer par partager le texte en deux : la moitié gauche, L et la moitié droite D. La sous-clef pour la ronde i est notée Ki. La ronde i de G O S T se formalise ainsi : t , — Ri—i
Ri = Li-i © f(Ri~î A ) 1. En réalité, le nom com plet est « G osudarstvennyi Standard Soyuza SSR », soit « standard gou vernemental de l’ Union des républiques socialistes soviétiques ».
S52
Chapitre 14
Encore d’autres algorithmes de chiffrement par blocs
La figure 14.1 illustre une ronde de G O S T . La fonction / est assez simple. Tout d’abord, la moitié droite et la ie clef sont ajoutées modulo 232. Le résultat est coupé en huit morceaux de 4 bits qui passent ensuite chacun à travers une table-S' différente. Il y a huit tables S distinctes dans G O S T ; les quatres premiers bits vont dans la première table-S, les quatre suivants dans la deuxième, et ainsi de suite. Chaque table-S est une permutation des nombres de 0 à 15. Une table-S pourrait être la suivante par exemple : 7, 10, 2, 4, 15, 9, 0, 3, 6, 12, 5, 13, 1, 8, 11 Dans ce cas, le bit en position 0 en entrée se retrouve en position 7 en sortie. Celui de position 1 se retrouve en position 10, et ainsi de suite. Les huits tables-S sont toutes différentes; elles sont considérées comme une partie de la clef et doivent rester secrètes.
F i g . 14.1 - Une ronde de G O S T
Les sorties des tables-,S' sont mises bout à bout pour former un mot de 32 bits qui subit un décalage circulaire à gauche de 11 bits. Finalement, le résultat est combiné par ou exclusif à la moitié gauche pour devenir la moitié droite, et la moitié droite devient la nouvelle moitié gauche. Faites cela 32 fois et vous avez fini. La génération des sous-clefs est simple. La clef de 256 bits est coupée en huit morceaux de 32 bits : k\, fc2, ••-, kg. Chaque ronde utilise une des sous-clefs comme indiqué dans le tableau 14.1. Le déchiffrement se fait avec le même algorithme en inversant l’ordre des ki. Le standard G O S T ne dit pas comment générer les tables S1, elles sont d ’une certaine manière fournies [657]. Certains spéculèrent qu’une certaine organisation soviétique pourrait fournir des tables-S solides à qui bon lui semblerait et des mauvaises à ceux qu’elle voudrait espionner. Cela pourrait très bien être vrai mais des discussions plus poussées avec un fabricant de puces G O S T en Russie mènent à une autre alternative.
14-1
GOST
353
Tab.
14.1 - Sous-clefs utilisées dans chaque ronde de G O S T
Ronde : ï 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Sous-clef: 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 Ronde: 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 Sous-clef: 1 2 3 4 5 6 7 8 8 7 6 5 4 3 2 1
Il a généré lui-même les permutations des tables-.S' avec un générateur de nombres aléatoires. Plus récemment, un ensemble de tables-S utilisé dans par la banque centrale de Russie a vu le jour. Ces tables-S sont aussi utilisées dans la fonction de hachage à sens unique GOST (voir § 18.11) [659]. Elles sont données dans le tableau 14.2.
Cryptanalyse de GOST Il y a des différences majeures entre G O S T et le DES. - La génération des sous-clefs est compliquée dans le DES. Elle est simple dans GOST. - Le DES utilise une clef de 56 bits; G O S T utilise une clef de 256 bits. Si vous prenez en compte les tables S, cela représente environ 610 bits d’information secrète. - Les tables-S1du DES ont 6 bits d’entrée et 4 de sortie; celles de G O S T ont 4 bits d ’entrées et 4 de sortie. Les deux algorithmes utilisent 8 tables-S, mais celles du DES sont quatre fois plus grandes que celles de G O S T . - Le DES utilise une permutation irrégulière, appelée une table-P ; G O S T utilise un décalage circulaire à gauche de 11 bits. - Le DES opère 16 rondes ; G O S T en opère 32. S’il n’y a pas d ’autre moyen de casser G O S T que l’attaque exhaustive, c ’est un algo rithme très sûr. G O S T utilise une clef longue de 256 bits et même plus si on compte les tables-S. G O S T est certainement plus résistant aux cryptanalyse différentielle et
T
Table-S Table-S Table-S Table-S Table-S Table-S Table-S Table-S
1: 2: 3: 4: 5: 6: 7: 8:
4 14 5 7 6 4 13 1
ab
.
14.2 - Tables-S de G O S T
10 9 2 13 8 0 11 4 12 6 13 15 8 1 13 10 3 4 13 10 1 0 8 9 12 7 1 5 15 13 11 10 0 7 2 1 11 4 1 3 15 5 15 13 0 5 7 10
14 6 11 1 12 10 2 3 8 1 2 14 15 12 7 15 14 4 6 12 8 4 10 9 14 13 3 6 8 5 9 0 10 14 7 4 9 2 3 14
7 15 5 3 0 7 5 9 6 0 9 11 11 2 5 3 0 3 11 2 9 12 15 14 6 8 2 12 6 11 8 12
Chapitre 14
354
Encore d’autres algorithmes de chiffrement par blocs
linéaire que le DES. Bien que les tables -S aléatoires de G O S T soient probablement plus faibles que celles adoptées dans le DES, le fait qu’elles soient secrètes renforce la résistence de G O S T aux attaques différentielles et linéaires. Ces deux attaques dé pendent aussi du nombre de rondes : plus il y a de rondes, plus l’attaque est difficile. Le seul fait que G O S T ait deux fois plus de rondes que le DES rend probablement les deux cryptanalysés différentielle et linéaire impratiquables. Les autres parties de G O S T sont équivalentes ou inférieures à celles du DES. GOST n’utilise pas de permutation expansive équivalente à celle du DES. Retirer cette per mutation du DES l’affaiblit en réduisant l’effet d ’avalanche; il est raisonnable que G O S T est plus faible que s’il utilisait une telle permutation. L ’emploie dans GOST de l’addition au lieu du ou exclusif du DES n’est pas moins sûre. La principale différence entre les deux algorithmes semble résider dans le décalage circulaire de G O S T au lieu d ’une permutation expansive. Cette permutation augmente dans le DES l'effet d ’avalanche. Dans G O S T , le changement d ’un bit d’entrée affecte une table-S à la première ronde, ce qui affecte ensuite deux tables S à la deuxième ronde, puis quatre à la troisième ronde, et ainsi de suite. Il faut huit rondes de GOST avant que la modification d ’un bit n’affecte tous les bits de sortie, alors que cinq suffisent avec le DES. Ceci est certainement une faiblesse. Mais n’oubliez pas que G O S T a 32 rondes et que le D ES en a 16. Les concepteurs de G O S T ont essayé de réaliser un compromis entre l’efficacité et la sécurité. Ils ont modifiés la conception originelle du DES pour obtenir un algorithme mieux adapté à la réalisation par logiciel. Ils semblent avoir été moins sûrs de la sécurité de l’algorithme et ils ont essayé de la compenser en allongeant la longueur de la clef, en gardant les tables -S secrètes et en doublant le nombre d ’itérations. Que leurs efforts aient abouti à un algorithme plus sûr que le DES reste encore à voir.
14.2
CAST
C A S T a été conçu au Canada par Carlisle A d a m s et Stafford T a v a r e s [14, 11]. Ils prétendent que le nom provient de la façon dont l’algorithme a été conçu, et est sensé évoquer l’image du hasard, mais remarquez les initiales des auteurs. Dans C A S T , les blocs ont une taille de 64 bits, ainsi que la clef. La structure de C A S T va vous paraître familière. L ’algorithme utilise huit tables ,? prenant 8 bits en entrée et 32 en sortie. La construction de ces tables S est compliquée et dépend de la réalisation, reportez-vous aux références pour les détails. Pour chiffrer, il faut partager le texte en clair en la moitié gauche et la moitié droite. L ’algorithme opère huit rondes. A chaque ronde, la moitié droite est combinée avec une partie de la clef en utilisant une fonction / et avec la moitié gauche par ou exclusif pour devenir la nouvelle moitié droite. La moitié droite originelle (avant modifications) devient la nouvelle moitié gauche. Après la huitième ronde, il ne faut pas échanger les deux moitiés droite et gauche ; le texte chiffré est obtenu en les mettant bout à bout. La fonction / est simple : 1° Diviser les 32 bits d’entrée en quatre parts de 8 bits, a, b, c, d. 2° Diviser les 16 bits de la sous-clef en deux morceaux de 8 bits : l, m. 3° Passer a à travers la table S 1, b à travers la table-S 2, c à travers la table-S 3,
14-3
355
B lo w fis h
d à travers la table- S 4, l à travers la table-S 5, m à travers la table-S 6 .
4° Combiner par ou exclusif les six sorties des tables-S ensembles pour obtenir la sortie finale de 32 bits. Une alternative consiste à combiner par ou exclusif les 32 bits d’entrée et 32 bits de la clef, à partager le résultat en quatre parts de 8 bits, et à combiner le tout par ou exclusif [11]. Il se trouve que N rondes de cette version sont aussi sûres que N + 2 rondes de l’autre option. Les sous-clefs de 16 bits sont facilement calculées d ’après la clef de 64 bits. En notant ki,k-2 , ■■■fis les huits octets de la clef, les sous-clefs de chaque ronde sont les suivantes : Ronde Ronde Ronde Ronde Ronde Ronde Ronde Ronde
1 : k\, 2 : kz, 3 : k$, 4 : k?, 5 : k4, 6 : k2 , 7 : ks , 8 : k6,
k-2 k4 ke k$ k-j,
fci fc7
La solidité de cette algorithme réside dans ses tables -S. Les tables S de C A S T ne sont pas fixées ; de nouvelles tables sont construites pour chaque application. Les critères de conception sont donnés dans [14] ; les fonctions courbées sont les colonnes des tables5, et sont choisies selon un certain nombre de propriétés désirées des tables-5 (voir § 14.10). Une fois qu’un ensemble de tables S a été attribué à une réalisation donnée de C A S T , elles restent fixes à jamais. Les tables-5 dépendent de la réalisation, mais pas de la clef. Il est montré dans [14] que C A S T résiste à la cryptanalyse différentielle et dans [731] qu’il résiste à la cryptanalyse linéaire. La seule méthode connue de casser C A S T est l’attaque exhaustive. La société N o r t h e r n T e l e c o m utilise C A S T dans leur logiciel de sécurité « Entrust » qui est distribué pour les Macintosh, les PC, et les stations Unix. Les tables -S qu’ils ont choisies n’ont pas été rendues publiques. Le gouvernement canadien évalue actuel lement C A S T comme un nouveau standard de chiffrement. C A S T est en instance de brevetage.
14.3
Blowfish
B l o w f i s h est un algorithme de ma conception, prévu pour être réalisé par logiciel sur les gros microprocesseurs [1394, 1393]. L ’algorithme n’est pas breveté et le code source en C qui se trouve à la fin de cette ouvrage fait partie du domaine publique. J’ai conçu B l o w f i s h pour répondre aux critères de conception suivants :
1. Rapidité. B l o w f i s h chiffre sur un microprocesseur 32 bits à la vitesse de 26 cycles d ’horloge par octet. 2. Compacité.
B
l o w f is h
peut tourner avec moins de 5 kilo-octets de mémoire.
Chapitre 14
356
Encore d’autres algorithmes de chiffrement par blocs
3. Simplicité. B l o w f i s h n ’utilise que des opérations simples : addition, ou exclusif, et recherche dans des tableaux avec des paramètres de 32 bits. Sa conception est facile à analyser, ce qui le rend résistant aux erreurs de programmation [13951. 4. Sécurité variable. La longueur de la clef est variable dans B l o w f i s h et peut atteindre 448 bits. B l o w f i s h est optimisé pour les applications où la clef ne change pas souvent, comme les liens de communication ou un chiffreur automatique de fichiers. Il est significative ment plus rapide que le DES avec des microprocesseurs 32 bits possédant une mémoire cache importante tels que le Pentium ou le PowerPC. B l o w f i s h n’est pas adapté aux applications telles que l’échange de paquets avec beaucoup de changement de clefs, ou à l’utilisation comme fonction de hachage à sens unique. L ’espace mémoire requis est trop important pour l’utiliser dans les cartes à puces.
Description de Blowfish B l o w f i s h est un algorithme de chiffrement par blocs de 64 bits à longueur de clef variable. L ’algorithme se fait en deux phases : expansion de la clef et chiffrement des données. L ’expansion de la clef convertit une clef de taille inférieure à 448 bits en plusieurs tableaux de sous-clefs d’une taille totale de 4168 octets. Le chiffrement est obtenu en itérant 16 fois une fonction simple (voir la figure 14.2). Chaque ronde consiste en une permutation dépendant de la clef et une substitution dépendant de la clef et des données. Toutes les opérations sont des additions et des ou exclusifs sur des nombres de 32 bits. La seule opération supplémentaire est la consul tation de quatre tableaux indéxés par ronde. B lo w fis h
utilise un grand nom bre de sous-clefs. C es sous-clefs doivent être pré
calculées avant tout chiffrement ou déchiffrement de données.
Le tableau P est constitué de 18 sous-clefs de 32 bits : Pi,P'2 , ■■■,Pis-
Il y a quatre tables-S de 32 bits ayant 256 entrées chacune : $1,0,$1.1 , •••A , 255 $ 2 ,0 ,$ 2 .1 ,- . . ,$2,255 $ 3 ,0 ,$ 3 ,l i ■••,$3,255 $ 4 ,0,$4.1 , - ■- ,$4,255
La méthode de calcul de ces sous-clef sera exposée un peu plus loin. B l o w f i s h est un réseau de Feistel (voir § 14.10) constitué de seize rondes. L ’entrée est un élément de données x de 64 bits. Pour chiffrer, procéder de la manière suivante : Partager x en deux moitiés de 32 bits : Pour i variant de 1 à 16, effectuer:
XL = XL © Pt x R = F (x l ) ® Xn Echanger x l et x r
.
x l ,x r .
14-3
35 7
B lo w fis h
F
Échanger
xr
et
xr
= xr ® Pn
x l
=
x r ®
Remettre
Pi8 et
xr
ig
.
14.2 -
B
l o w f is h
x r
(annuler le dernier échange).
x r
bout à bout.
La fonction F est la suivante (voir la figure 14.3) : Diviser x r en quatre parts de 8 bits a,b,c,d. x r ) = ((5 i,a + S2,b modulo 232) ® 5 3iC) + 5 4,d modulo 232
F {
Le déchiffrement s’effectue exactement de la manière en inversant l’ordre des Pi. Les réalistions de B l o w f i s h nécessitant une vitesse maximale devraient dérouler la boucle et s’assurer de la présence des sous-clefs dans la mémoire cache. Voir [570] pour les détails.
Chapitre 14
358
8 bits
Encore d’autres algorithmes de chiffrement par blocs
Table-S 1
32 bits l
8 bits
Table-S 2
32 bits 1
32 bits 8 bits
Table-S 3
32 bits 32 bits
8 bits
Table-S 4
32 bits
F ig . 14.3 - La fonction F
Les sous-clefs sont calculées de la manière suivante :
1° Initialiser le tableau- P et les quatre tables-S avec une chaîne de caractères fixée. Cette chaîne est constituée des décimales de
tï.
2 ° Combiner par ou exclusif Pi et les 32 premiers bits de la clef, P2 avec les 32
bits suivants, et ainsi de suite pour tous les bits de la clef Itérer ce procédé le nombre nécessaire de fois pour traiter tout le tableau-P. 3 ° Chiffrer la chaîne constituée de zéros uniquement avec B l o w f ish et les sous-
clefs telles qu’elles sont après les étapes 1 et 2 . 4 ° Remplacer Pi et P2 avec le résultat de l’étape 3. 5 ° Chiffrer le résultat de l’étape 3 avec B lo w fish et les sous-clefs modifiées. 6°
Remplacer P3 et P4 avec le résultat de l’étape 5.
7° Itérer ce procédé de manière à remplacer tous les éléments du tableau-P et des tables-S (dans l’ordre) avec le résultat de l’algorithme B l o w f ish modifié à chaque fois.
521 itérations sont nécessaires au total pour générer toutes les sous-clefs. L’application peut stocker les sous-clefs, il n’est pas nécessaire d ’effectuer ce procédé de génération plusieurs fois.
Sécurité de Blowfish Serge V a u d e n a y a examiné B l o w f ish avec r rondes en ayant connaissance des tablesUne attaque différentielle permet de retrouver le tableau-P avec 2 8 r + 1 textes en clair choisis [1570]. Pour certaines clefs faibles qui génèrent de mauvaises tables-5 (la S.
144
SAFER
359
probabilité d ’en prendre une au hasard est de une chance sur 214), cette attaque n’a besoin que de 24r 11 textes en clair choisis. Si les tables- S ne sont pas connues, cette attaque permet de détecter si une clef faible a été utilisée, mais ne permet pas de la trouver (ni les tables- 5 , ni le tableau-P). Cette attaque ne marche que contre les variantes avec peu de rondes; elle est complètement impraticable contre le B l o w f i s h à 16 rondes. Bien sûr, la découverte de clefs faibles est significative, même si elle semble impossible à utiliser. Une clef faible est une clef pour laquelle deux entrées d’une des table-S1sont identiques. Il n’y a pas moyen de tester si une clef est faible avant d ’effectuer la phase d’expansion. Si vous vous inquiétez, il vous faut faire l’expansion de la clef et vérifier qu’aucune des tables-S n’a deux entrées identiques. Cependant, je ne pense pas que cela soit nécessaire. Je ne connais aucune attaque cryptanalytique contre B l o w f i s h . Par prudence, ne réalisez pas B l o w f i s h avec un nombre réduit de rondes. La société K e n t M a r s h L t d . a incorporé B l o w f i s h dans leur produit de protection « FolderBolt » pour Microsoft Windows et Macintosh. Il fait aussi partie de « Nautilus » et « PGPfone ».
14.4
SAFER
SA F E R K -64 vient de « Secure And Fast Encryption Routine » qui veut dire procédure de chiffrement rapide et sûre [1015]. « K-64 » signifie que la clef a une longueur de 64 bits. James M a s s e y a conçu cet algorithme non déposé pour C y l i n k C o r p . et fait partie de certains de leurs produits. Le gouvernement de Singapour prévoit d’utiliser cet algorithme avec une clef de 128 bits [1016] pour une large variété d ’applications. Il n’y a ni brevet, ni droits d ’exploitation, ni aucune autre restriction sur son utilisation. La taille des blocs et de la clef sont de 64 bits. Ce n’est pas un réseau de Feistel comme le DES (voir § 14.10), mais un algorithme de chiffrement par blocs itératif: la même fonction est appliquée pour un certain nombre de rondes. Chaque ronde utilise deux sous-clefs de 64 bits, et l’algorithme n’utilise que des opérations sur des octets.
Description de SAFER Le bloc de texte en clair est divisé en huit parts d ’un octet : . . . ,BH. Les sousblocs subissent alors r rondes. Pour finir, une transformation de sortie est appliquée aux sous-blocs; Chaque ronde utilise deux sous-clefs : —i et K^rLa figure 14.4 illustre une ronde de S A F E R K-64. Les sous-blocs sont tout d’abord combinés avec des bits de la sous-clef K
Ce sont des opérations dans le corps fini Z/257, et 45 est un générateur de ce corps. Dans les réalisations pratiques de SA F E R , il est plus rapide de stocker ces valeurs dans un tableau que de les recalculer à chaque fois. Les sous-blocs sont alors combi nés avec des bits de la sous-clef K ir par ou exclusif ou par addition. Les résultats
360
Chapitre 14
F
ig .
Encore d’autres algorithmes de chiffrement par blocs
14.4 - Une ronde de S A F E R
de cette opération passent alors à travers trois couches d’opérations linéaires dont l'intérêt est d ’augmenter l’effet d’avalanche. Chaque opération est appelée une pseudo transformation d’Hadamard (P T H en abrégé). Si une P T H prend en entrée ai et a2, alors sa sortie est : bi = (2 * ai + a2) modulo 256 62
= (ai + a2) modulo 256
Après les r rondes, on opère une transformation finale, la même que la première étape de chaque ronde. Bi, B 4 , B 5 , et Bs sont combinés par ou exclusif avec les octets correspondants de la dernière sous-clef, et Z?2, B 3 , Bç, et B 7 sont additionnés avec les bits correspondants de la dernière sous-clef. Le résultat est le texte chiffré. Le déchiffrement est le procédé inverse: la transformation de sortie (avec des sous tractions au lieu des additions), puis r rondes inversées. La PTH inversée (P T H I) est donnée par : ax = (£>1 — 6 2 ) modulo 256 a 2 = {—bi + 2è2) modulo 256 M A S S E Y conseille d ’effectuer 6 rondes, m ais vous pouvez en faire plus p o u r plus de sécurité.
14.5
361
3 -W A Y
La génération des sous-clefs est simple. La première sous-clef K\ est la clef elle même. Les sous-clefs suivantes sont produites de la manière suivante : K i+1 = (K i « <
3i) + Ci
Le symbole « < < < » est un décalage circulaire vers la gauche soit encore une rotation vers la gauche. La rotation se fait octet par octet, et c, est une constante de la ronde. Si Cij représente le j e bit de la constante de la ie ronde, vous pouvez calculer les constantes de toutes les rondes grâce à la formule suivante : Cij = 4545
Généralement, ces valeurs sont stockées dans un tableau.
SAFER K-128 Cette alternative de gestion des clefs a été développée par le ministère de l’intérieur de Singapour, et incorporée ensuite par M a s s e y dans S A F E R [1016]. Elle repose sur deux clefs de 64 bits K a et Kb- L’astuce consiste à générer deux séquences de sous-clefs en parallèle et à prendre alternativement une sous-clef dans chaque séquence. Cela signifie qu’en prenant K a — K h, la clef de 128 bits est compatible avec la clef de 64 bits K a.
Sécurité de SAFER k-64 M A S S E Y a montré que S A F E R est immune à la cryptanalyse différentielle à partir de huit rondes et suffisament résistant à cette attaque après six rondes. La cryptanalyse linéaire est inefficace contre cet algorithme après trois rondes seulement [1016]. KNUDSEN a trouvé une faiblesse dans la gestion des clefs : il existe virtuellement pour chaque clef au moins une autre clef (et parfois jusqu’à neuf autres clefs) telle que les clefs chiffrent des textes en clair différents en textes chiffrés identiques [862]. Le nombre de textes en clair différents qui deviennent le même texte chiffré après six rondes est compris entre 222 et 228. Si la sécurité de S A F E R n’en patît pas lorsqu’il est utilisé comme algorithme de chiffrement, cela réduit considérablement sa sécurité s’il est employé comme fonction de hachage à sens unique. Dans tous les cas, K N U D SEN conseille d ’effectuer huit rondes. SA F E R a été conçu pour C y l i n k qui est soudoyée par la N SA [87]. Je recommande quelques années de cryptanalyse intensive avant d ’utiliser S A F E R sous quelque forme que soit.
14.5
3-W A Y
3-W AY est un algorithme de chiffrement par blocs conçu par Joan D A E M E N [405, 411]. Il utilise des blocs et une clef de même taille : 96 bits, et il est conçu pour être très efficace en réalisation matérielle. 3-W AY n ’est pas un réseau de Feitel mais un algorithme de chiffrement itératif. 3W AY peut comprendre n rondes; D a e m e n en conseille 11.
362
Chapitre 14
Encore d’autres algorithmes de chiffrement par blocs
Description de 3-W A Y L’algorithme est simple à décrire Pour chiffrer un bloc de texte en clair x , procédé comme suit : Pour i variant de 0 à n — 1, effectuer les opérations suivantes : x = x © Kt x = theta(x) x = pi — l(x ) x = gamma(x) x = pi — 2(x)
x = x © K n+ 1 x = theta(x)
Les fonctions sont les suivantes : theta(x) est une fonction de substitution linéaire— en substance, un mélange de décalages circulaires et de ou exclusifs. - pi — l(x ) et pi — 2(x) sont des permutations simples.
- gamma(x) est une fonction de substitution non linéaire. C’est cette étape qui a donné son nom à 3-W A Y ; il s’agit de l’exécution en parallèle d ’opérations de substitution sur des blocs de 3 bits de l’entrée. Le déchiffrement se fait de la même manière en inversant les bits de l’entrée et aussi ceux de la sortie. Le code source de 3-W A Y se trouve à la fin de ce livre. Jusqu’à présent, personne n’a réussi à cryptanalyser 3-W AY. L’algorithme n’est pas breveté.
14.6
CRAB
Les auteurs de cet algorithme sont Burt KALISKI et Matt RoBSHAW des laboratoires R SA [800]. L ’idée de C R A B est d’utiliser les techniques propres au fonctions de ha chage à sens unique pour construire un algorithme de chiffrement rapide. Du coup, C R A B ressemble beaucoup à M D5, et les concepts du paragraphe 18.5 seront suppo sés connus dans ce qui suit. C R A B s’appuie sur une grande taille de blocs : 1024 octets. Comme C R A B est plutôt un travail de recherche qu'un algorithme réel, aucune procédure de génération de clef n’est décrite. Les auteurs suggèrent une méthode permettant de déduire d ’une clef de 80 bit les trois sous-clef requises, bien que l’algorithme pourrait très bien accepter des clefs de longueur variable. C R A B utilise deux ensembles de grandes sous-clefs: Une permutation des nombres de 0 à 255 : Po,Pi, ■•■,p 2bcUn tableau de 2048 nombres de 32 bits : So,S \, . . . ,52047-
CRAB
14.6
363
Ces sous-clefs doivent être calculées avant le chiffrement ou le déchiffrement. Voici comment chiffrer un bloc X de 1024 octets : 1° D i v i s e r X e n 256 s o u s -b lo c s d e 32 b i t s : X 0 , X i , . . . , X 255. 2° P e r m u t e r les s o u s -b lo c s d e X s e lo n P . 3° P o u r r v a r ia n t de 0 à 3 e t g v a r ia n t de 0 à 63, e ffe c tu e r : A = X {4g )< < < 2r B = -V(4ff+ l ) « < 2 r C = X ( 4g+2 ) < « 2 r B
=
X ( 4 f/+3'j < < < 2 r
P o u r s v a r ia n t de
0 à 7, fa ir e :
A = A © (B + f r(B ,C ,D ) + *S'512ir+8g+s) A’ = D D = C C = B B = A « < 5 A = A'
^ { 4g ) < « 2r = A A ( 4 s- | _ i ) « < 2r — B X ( 4 g + 2) < « 2 r
=
C
X (4 < , i - 3 ) « < 2 r
—
D
4° R e m e t tr e X 0 , X i , . . . , X 255 e n s e m b le p o u r f o r m e r le t e x t e c h iffr é. Les fonctions f r ( B , C , D ) sont similaires à celles utilisées dans M D -5 : f ( B , C , D ) — ( B A C ) V ( ( - .B ) A D ) f ( B , C , D ) = ( B A D ) V ( C V (-,£>)) f(B ,C ,D ) — B 0 C ® D f { B , C , D ) = C © ( B V (-.£>))
Le déchiffrement se fait par le procédé inverse. La génération des clefs est une lourde tâche. Voici comment produire le tableau P représentant la permutation requise à partir d’une clef K de 80 bits :
1°
ln itia lis e r K^, K\, . . . ,Kg a v e c les d ix o c te ts d e K .
2° P o u r i v a r ia n t d e 10 à 255 e ffe c tu e r : Ki =
2 © K i—g © K i -
7
© K i - 10.
3° P o u r i v a r ia n t de 0 à 255, p o s e r P i = i. 4° m = 0.
Chap re 14
Encore d’autres algorithmes de chiffrement par blocs
5° Effectuer deux fois la boucle suivante : pour i variant de 256 à 1 (par incré mentations de —1), faire: m = ( K 256-i + K 257- i ) modulo i K 257-i = ^257-i « < 3 Echanger I\ et l\-\
Le tableau S pourrait être construit d ’une manière similaire, soit à partir de la même clef de 80 bits, soit à partir d’une autre. Les auteurs attirent l’attention sur l’importance de ces détails : « il peut très bien exister des schémas alternatifs à la fois plus efficaces et offrant plus de sécurité » [800]. C R A B a été présenté plus comme un nid d ’idées nouvelles que comme un algorithme fonctionnant. Il utilise beaucoup de techniques similaires à celles de M D -5. B ih a m prétend qu’une taille de bloc trop large rend la cryptanalyse d ’un algorithme plus aisée [167]. D ’un autre côté, C R A B pourrait fort bien s’accomoder d’une très longue clef. Dans ce cas, « plus aisé à cryptanalyser » risque de ne plus vouloir dire grand chose.
14.7
SXAL8 et M B AL
Il s’agit d ’un algorithme par blocs de taille 64 bits [769]. SX A L 8 est l’algorithme de base; M B A L est une version étendue dans laquelle la taille des blocs est variable. Partant du fait que M B A L opère intelligemment de façon interne, les auteurs pré tendent obtenir une sécurité suffisante avec peu de rondes seulement. Avec une taille de bloc de 1024 bits, M B A L est environ 70 fois plus rapide que le DES. Malheuresement, il est montré dans [1180] que M B A L est propice à la cryptanalyse différentielle et dans [866] qu’il est propice à la cryptanalyse linéaire.
14.8
R.C5
RC5 est un algorithm e de chiffrement p a r blocs avec de nom breux param ètres : taille des blocs, taille de la clef, et nom bre de rondes. R o n R
iv e s t
en estl’inventeur et il a
R SA [1335, 1336], Il y a trois opérations: ou exclusif, addition, et rotation. Les rotations prennent un temps constant sur la plupart des processeurs et les rotations variables sont des fonc tions non linéaires. Ces rotations qui dépendent à la fois de la clef et des données constituent la partie intéressante. La longueur des blocs est variable dans R C5, mais on se concentrera dans l’exemple qui suit sur une taille de 64 bits. Le chiffrement nécessite 2r + 2 mots de 32 bits dépendants de la clef, Sq,Si , . . . ,S2r+2, où r est le nombre de rondes. Nous parlerons de leur génération plus tard. Pour chiffrer, diviser tout d’abord le bloc de texte en clair en mots de 32 bits : A et B. Il faut alors procéder ainsi : été analysé p a r les laboratoires
A = A + iSo B = B + Si
14-8
365
RC5
Pour i variant de 1 à r, effectuer :
A — {{A 0 B) « < B = ((B ® A) « <
B ) + S2i A) + S2i+ 1
La sortie est constituée des registres A et B. Le déchiffrement est tout aussi facile. Partager le texte chiffré en deux mots A et B , et effectuer : Pour i décroissant de r à 1 : B = {{B - S 2z+1) » > A) ® A A = (( A - S m ) » > B ) ® B
B = B +Sx A = A 4- Sq
La création du tableau de ciels est plus compliquée mais directe aussi. Commencez par copier les bits de la clef dans un tableau L de c mots de 32 bits (en remplissant si nécessaire le dernier mot avec des zéros). Initialisez alors le tableau en utilisant un générateur congruentiel modulo 232 : S0 = P Pour i variant de 1 à 2 (r + 1) — 1, effectuer : St = {Si + Q ) modulo 232 P = 0xB7E15163 et P = 0x9E3779B9 sont des constantes basées sur Pour finir, mélangez L et S :
e.
i= j = 0 A = B = 0
Effectuer n fois (où n est le maximum de 2(r + 1) et c) : A = Si = (Sz + A + B) « < 3 B = Lt = { L j + A + B ) « < {A + B)
i = {i + 1) modulo 2(r + 1) j = (j + 1) modulo c
RC5 est en fait une famille d’algorithmes. Nous avons défini R C 5 avec des mots de 32 bits de long et des blocs de 64 bits de long ; rien n’empêche l’algorithme de fonctionner avec des mots de 64 bits de long et des blocs de 128 bits de long. R i v e s t désigne les réalisations particulières de R C5 par R C 5 - w / r / b où w est la taille des mots, r le nombre de rondes, et b la longueur de la clef en octets. Pour w = 64, P et Q valent respectivement 0xB7E151628AED2A6B et 0x9E3779B97F4A7C15.
366
Chapitre 14
Encore d’autres algorithmes de chiffrement par blocs
R C5 est nouveau, mais les laboratoires R SA ont passé un temps considérable à l’ana lyser avec une taille de bloc de 64 bits. Après 5 rondes, les statistiques paraissent très bonnes. Après 8 rondes, chaque bit du texte en clair affecte au moins une rotation. Il existe une attaque différentielle avec 224 textes en clair choisis- pour 5 rondes, 245 pour 10 rondes, et 268 pour 15 rondes. 11 n ’y a bien sûr que 264 textes en clair possibles, aussi cette attaque ne marchera pas pour 15 rondes ou plus. Des estimations en crypta nalyse linéaire indiquent que l’algorithme est sûr après 6 rondes. R i v e s t recommande au moins 12 rondes et 16 si possible [1336]. Ce nombre pourrait changer. R SA D SI est en train de faire breveter R C5, et le nom est déposé. La société prétend que les frais de license seront très réduits, mais vous feriez mieux de vérifier au près d’eux.
14.9
Autres algorithmes de chiffrement par blocs
11 existe dans la littérature un algorithme appelé C R Y P T O -M E C A N O [303]; il n’est pas sûr. Quatre cryptographes japonais ont présenté un algorithme basé sur la théorie du chaos à la conférence EUROCRYPT’91 [688, 689]. B i h a m a cryptanalysé cet algorithme à la même conférence [164], Un autre algorithme repose sur des sous-ensemble d ’un ensemble particulier de chiffres aléatoires [694]. Il existe plusieurs algorithmes basés sur la théorie des codes correcteurs d’erreurs : une va riante de l’algorithme de M c E l i e c e (voir § 19.7) [786, 1301], l’algorithme de R a o N a m [1303, 735, 1508, 1302, 1064, 1066, 1065, 1304], des variantes de l’algorithme de R a o - N a m [470, 751, 1507], et l’algorithme de L i - W a n g [975, 1532] ; aucun n’est sûr. C A L C n’est pas sûr [1115]. Un algorithme du nom de T E A pour « Tiny Encryption Algorithm » (petit algorithme de chiffrement) est encore trop neuf pour être commenté. V i n o est encore un autre algorithme [1271]. M a c G u f f i n , un algorithme de chiffre ment par blocs conçu par Matt B l a z e et moi-même n’est pas sûr non plus [196] ; il fut cassé durant la conférence où il a été présenté. B a s e K i n g , un algorithme de conception philosophiquement identique à celle de 3-W AY mais avec une taille de bloc de 192 bits [390], est trop nouveau pour être commenté. Il y a bien plus d ’algorithmes de chiffrement par blocs disponibles hors de la com munauté cryptologique. Certains sont utilisés par diverses organisations gouvernemen tales et militaires. Je n’ai aucune information les concernant. Il y a aussi des douzaines d ’algorithmes commerciaux privés. Certains peuvent être bons ; la plupart ne le sont probablement pas. Si les sociétés estiment que rendre l’algorithme public ne sert pas leurs intérêts, il vaut mieux faire l’hypothèse qu’elles ont raison et éviter l’algorithme.
14.10
Théorie des algorithmes de chiffre ment par blocs
J’ai décrit au paragraphe 11.1 les principes de confusion et de diffusion de S h a n n o n . Cinquante après la première rédaction de ces principes, ils restent les fondations de la conception d ’un bon algorithme de chiffrement par blocs.
14-10
Théorie des algorithmes de chiffrement par blocs
367
La confusion sert à cacher les relations entre le texte en clair, le texte chiffré, et la clef. Vous rappelez vous comment la cryptanalyse différentielle peut exploiter la moindre relation entre ces trois éléments? Une bonne confusion rend les relations statistiques si compliquées que mêmes ces outils cryptanalytiques puissants ne marche pas. La diffusion répand l’influence d ’un bit particulier du texte en clair ou de la clef aussi loin que possible dans le texte chiffré. Cela camoufle aussi les relations statistiques et rend la cryptanalyse plus difficile. La confusion à elle seule suffit pour la sécurité. Un algorithme qui mettrait en corres pondance en fonction de la clef les 264 textes en clair possibles avec les 264 textes chiffrés possibles serait tout à fait solide. Le problème est que cela nécessiterait beaucoup de mémoire : il faudrait stocker un tableau de 1020 octets. La conception d ’algorithmes de chiffrement par blocs consiste à créer quelque chose qui ressemble à un tel algorithme, mais en utilisant beaucoup moins de mémoire. L’astuce est de mélanger répétivement la confusion (avec des tableaux beaucoup plus petits) et la diffusion avec un seul algorithme de chiffrement dans différentes com binaisons. Ceci s’appelle un algorithme de chiffrement produit. Un algorithme constitué de couches de substitution et de permutations est parfois appelé un réseau substitution-permutation ou encore un réseau SP. Considérez la fonction / du DES. La permutation expansive et la table P servent à la diffusion ; les tables—S servent à. la confusion. La permutation expansive et la tableP sont linéaires ; les tables S ne sont pas linéaires. Chaque opération isolée est assez simple ; ensembles, elles fonctionnent plutôt bien. Le DES présente quelques principes de conception d’algorithmes de chiffrement sup plémentaires. Le premier est l’idée d’un algorithme de chiffrement itératif. Cela désigne tout simplement le fait de prendre une fonction de ronde simple est de la ré péter plusieurs fois. Le DES à deux rondes n’est pas bien solide ; il faut au moins cinq rondes avant que les bits de sortie dépendent de tous les bits d’entrée et de tous les bits de la clef [1088, 1084]. Le DES à seize rondes est solide; le DES à trente deux rondes l’est encore plus.
Réseaux de Feistel La plupart des algorithmes de chiffrement par blocs sont des réseaux de Feistel. Cette idée date du début des années 1970 [554, 555]. Prenez un bloc de longueur n et divisez le en deux moitiés de longueur n /2 : L et R. n doit bien sûr être pair. Vous pouvez définir un algorithme de chiffrement par blocs itératif où la sortie de la ie ronde est déterminée d’après la sortie de la ronde précédente : h)
Ri
1
R i = L i_ i © f ( R i ~ i , K t )
Ki est la sous-clef utilisée dans la ie ronde and / est une fonction quelconque.
Vous avez pu rencontrer ce concept dans les algorithmes DES, L u c i f e r , FE A L, h u f u , K h a f r e , LO K I, G O S T , C A S T , B l o w f i s h , et d’autres. Pourquoi en parler tant? Il est garanti que la fonction est inversible. Comme la moitié droite et la sortie de la fonction de ronde sont combinées par ou exclusif, l’égalité suivant est forcément vérifiée : K
Ri
©
f{Ri—
îjff») —
I~>i—i
©
f(Ri-i,Ki)
©
/ ( R ^ — ijKi) =
Li
-1
Chapitre 14
368
Encore d ’autres algorithmes de chiffrement par blocs
Un algorithme de chiffrement construit avec cette méthode est forcément inversible pour peu qu’on puisse reconstruire l’entrée de la fonction / à chaque ronde. La nature de / n’est pas importante ; / n’a pas besoin d ’être inversible. On peut concevoir une fonction / aussi compliquée que désiré, et il ne sera pas nécessaire de réaliser deux algorithmes différents— un pour le chiffrement et un pour le déchiffrement. La structure des réseaux de Feistel prend cela en compte automatiquement.
Relation simples Le DES vérifie la propriété suivante: E k { M ) = C implique E K' { M ' ) = C' où M ' , C et K ' sont les compléments bit à bit de A f, C et K respectivement. Cette propriété réduit la complexité d ’une attaque exhaustive d’un facteur deux. LO K I vérifie des propriétés de complémentation qui réduisent la complexité d ’un facteur 256. Une relation simple peut être définie comme dans [860] : Si E k ( M ) = C, alors E f{K)( g ( M , K ) ) = h(C,K). où f , g et h sont des fonctions simples. Par simples, j ’entends qu’elles sont faciles à calculer, bien plus faciles qu’une itération de l’algorithme. Dans le cas du DES, / , g et h sont la complémentation bit à bit (de leur première variable). C ’est le résultat de la combinaison par ou exclusif de la clef avec des parties du texte. Les bons algorithmes de chiffrement ne vérifient aucune relation simple. Des méthodes pour trouver de telles faiblesses sont données dans [918].
Structure de groupe Quand on examine un algorithme, il est naturel de se demander si c ’est un groupe. Les éléments du groupe sont les blocs de texte chiffré avec chaque clef possible, et l’opération du groupe est la composition. Regarder la structure de groupe d ’un algorithme sert à comprendre combien de brouillage supplémentaire on obtient en chiffrant plusieurs fois. Cependant, la question pertinente n’est pas de savoir si un algorithme est vraiment un groupe, mais à quel point il est proche d’un groupe. Si cela revenait à perdre un élément, ce ne serait pas un groupe ; mais statistiquement le double chiffrement serait une perte de temps. Les travaux concernant le DES ont montré qu’il est loin d’être un groupe. Il reste encore des questions intéressantes à propos du semi-groupe généré par le chiffrement par le DES. Est-qu’il contient l’identité : c ’est à dire, engendre-t-il un groupe? En d ’autres termes, certaines combinaisons d ’opérations de chiffrement (pas de déchiffrement) fournissent-elles éventuellement la fonction identité? Si c ’est le cas, quelle est la longueur de la combinaison la plus petite? Le but est d’estimer la taille de l’espace des clefs pour une attaque exhaustive théorique et de donner la meilleure borne inférieure de l’entropie de l’espace des clefs.
Clefs faibles Dans un bon algorithme de chiffrement par blocs, toutes les clefs sont aussi solides les une que les autres. Les algorithmes qui ont un petit nombre de clefs faibles ne posent généralement pas de problème. Il y a peu de chance d ’en tirer une au hasard et il est facile de les éviter. Cependant, on peut parfois exploiter ces clefs faibles si l’algorithme est utilisé comme fonction de hachage à sens unique (voir § 18.11).
14-10
Théorie des algorithmes de chiffrement par blocs
369
Résistence aux cryptanalysés différentielle et linéaire L’étude des cryptanalyse différentielle et linéaire a éclairé de manière significative la théorie des bons algorithmes de chiffrement par blocs. Les concepteurs d’ID E A ont introduit le concept de différentielles, une généralisation de l’idée de base des ca ractéristiques [942], Ils soutiennent qu’un algorithme de chiffrement par blocs peut être conçu pour résister à cette attaque; ID E A est le résultat de ce travail [942]. Ce concept est davantage formalisé dans [1186,1187], où Kaisa N y b e r g et Lars K n u d s e n ont montré comment construire des algorithmes de chiffrement par blocs dont il est possible de prouver la résistance à la cryptanalyse différentielle. Cette théorie s’étend aux différentielles de plus haut degré [703, 168, 938, 858, 861] et aux différentielles partielles [861]. Les différentielles de haut degré ne semblent s’appliquer qu’aux algo rithmes ayant un petit nombre de rondes, mais les différentielles partielles se combinent parfaitement avec les différentielles. La cryptanalyse linéaire est plus récente, et est encore en cours d’amélioration. Des notions de rang de clef [1023] et d ’approximation multiple [801, 802] ont été définies. D’autres travaux étendant l’idée de la cryptanalyse linéaire se trouvent dans [1281] ; dans [949], on tente de combiner les cryptanalysés linéaire et différentielle en une seule attaque. Les techniques de conceptions qui protégeront contre ces types d ’attaques sont encore floues. K n u d s e n a fait quelques progrès en considérant quelques critères nécessaires (mais peut-être pas suffisants) pour ce qu’il appelle les les réseaux de Feistel sûr en pratique: des algorithmes de chiffrement qui résistent à la fois à la cryptanalyse différentielle et la cryptanalyse linéaire [860]. N y b e r g a introduit en cryptanalyse linéaire un concept analogue à celui des différentielles en cryptanalyse différentielle [794]. De manière assez intéressante, il semble y avoir une sorte de dualité entre les cryptanalyses différentielle et linéaire. Cette dualité apparaît à la fois dans la conception de techniques pour construire de bonnes caractéristiques ou de bonnes approximations linéaires [171, 1027], et dans la conception de critères de construction d ’algorithmes résistants à ces deux attaques [312], Qui sait où mènera cette ligne de recherche. Pour commencer, D a e m e n a développé une stratégie de conception d’algorithmes basée sur les cryptanalysés linéaire et différentielle [405].
Conception de tables—S La solidité d’une variété de réseaux de Feistel— et plus spécifiquement leur résistence aux cryptanalyse différentielle et linéaire— est directement reliée à leurs tables-S. Ceci a lancé une voie de recherche sur ce qui constitue de bonnes tables S. Une table—S est une simple substitution : une application de m bits d ’entrée vers n bits de sortie. Une table- S avec m bits en entrée et n bits en sortie s’appelle une table— S à m*n bits. Les tables- S constituent en général la seule étape non linéaire d’un algorithme ; elles sont ce qui lui donne sa sécurité. En général, plus elles sont grandes, meilleures elles sont. Le DES a huit tables S à 6*4 bits différentes. K h u f u et K h a f r e ont une seule table5 à 8*32 bits, L O K I a une table S à 12*8 bits, et B l o w f i s h et C A S T ont tous les deux des tables S à 8*32 bits. Dans ID E A la table-S1est en fait l’étape de mulitplication modulaire ; c’est une table- S à 16* 16 bits. Plus la table-S est grande, plus il
370
Chapitre 14
Encore d’autres algorithmes de chiffrement par blocs
est difficile de trouver des statistiques utiles à l'attaque par cryptanalyse linéaire ou différentielle [655, 730, 1628]. Aussi, quand des tables S aléatoires ne protègent pas optimalement en général contre les cryptanalysés différentielle et linéaire, il est plus facile de trouver des tables S solides si elles sont plus grandes. La plupart des tables-S aléatoires ne sont ni linéaires, ni dégénérées, et offrent une forte résistence à la cryp tanalyse linéaire, et la fraction qui ne satisfait ces critères devient rapidement infime quand le nombre de bits en entrée décroît [1190, 1191, 1192], La grandeur de m est plus importante que celle de n. Augmenter n réduit l’efficacité de la cryptanalyse différentielle, mais augmente largement celle de la cryptanalyse linéaire; En fait, si n > 2m — m, il y a toujours une relation linéaire entre les bits en entrée et en sortie de la table S'. Et si n > 2m, alors il existe une relation linéaire entre les bits de sortie [171]. La plupart de ces travaux met enjeu les fonctions booléennes [101,1104,1273,1413]. Pour être sûres, les fonctions booléennes utilisées dans une table-S1doivent satisfaire des conditions spécifiques. Elles ne devraient pas être linéaires ou affines, ni même s’en approcher [13, 1184, 1183, 1193]. Il devrait y avoir un équilibre entre les un et les zéros, et aucune corrélation entre différentes combinaisons de bits. Les bits en sortie devraient se comporter indépendamment lorsqu’on eomplémente un bit en entrée. Ces critères de conception sont aussi reliés à l’étude des fonctions courbées qui sont les fonctions dont on peut prouver qu’elles sont optimalement non linéaires. Bien que leur définition soit simple et naturelle, leur étude est très compliquée [1356, 1225, 958, 906, 1182, 1282, 299, 300, 301, 156, 353, 503, 302]. Une propriété très importante semble être l’effet d’avalanche : combien de bits changent en sortie d’une table-S quand certains bits sont changés en entrée. Il est facile d’im poser certaines conditions aux fonctions booléennes pour qu’elles satisfassent certains critères d ’avalanche, mais les construire est bien plus difficile. Le critère d ’ avalanche strict (C A S en abrégé) guarantit que la moitié des bits changent en sortie quand un bit change en entrée [1588]. Se référer aussi à [1483, 574, 1273, 403]. Un article tente d’examiner tous ces critères en termes de perte d’information [1642], Il y a quelques années, les cryptographes ont proposé de choisir les tables -S de sorte que le tableau des distributions des différences soit uniforme. Cela protégerait de la cryptanalyse différentielle en aplatissant les différentielles de n’importe quelle ronde [10. 445, 446, 1184]. LO K I, par exemple, suit cette conception. Cependant, cette approchi peut parfois favoriser la cryptanalyse différentielle [178]. En fait, une meilleure approcht consiste à s’assurer que la différentielle maximale est aussi petite que possible. Kwangjc Kim a proposé cinq critères de construction des l abiés- S [835], similaires aux critères de conception des tables-S1du DES. Choisir de bonnes tables S n’est pas une tâche aisée ; il y a plusieurs idées qui s’op posent sur la façon de le faire. On peut recenser quatre approches différentes. 1. Choisir aléatoirement. Il est clair que les petites tables -S aléatoires ne sont pas sûres, mais les grandes tables S aléatoires peuvent l’être suffisament. Les tablesS prenant en entrée huit bits ou plus sont assez solides [1191, 1192]. Celles dr douze bits sont meilleures. On obtient encore plus de robustesse si les tables -S sont à la fois aléatoires et dépendantes de la clef. ID E A utilise des tables S à la fois grandes et dépendantes de la clef. 2. Choisir et tester. Certains algorithmes de chiffrement produisent des tables S et
14-10
Théorie des algorithmes de chiffrement par blocs
371
testent alors si elles ont les propriétés requises. Voir [13, 730] pour des exemples de cette approche.
3. Les faire à la main. Cette technique utilise peu les mathématiques : les tables S sont produites par des méthodes plus intuitives. Bart P r e n e e l a établi que «...les critères intéressants théoriquement ne sont pas suffisants [pour choisir des fonctions booléennes pour les tables- 5]...» et que «...des critères de conception ad hoc sont nécessaires » [1273].
4. Les faires grâce aux mathématiques. Il s’agit de générer des tables S selon des principes mathématiques de sorte que l’on puisse prouver qu’elles soient résis tantes aux cryptanalysés différentielle et linéaire, et qu’elles ont de bonnes pro priétés de diffusion. Voir [1185] pour un excellent exemple de cette approche.
Il y a eu quelques demandes de combinaison des approches « à la main » et « grâce aux mathématiques », mais le principal débat semble se tenir entre les tables choisies aléatoirement et les tables S ayant certaines propriétés. La dernière approche a cer tainement l’avantage d’être optimale contre les attaques connues— les cryptanalysés linéaire et différentielle— mais elle offre une protection inconnue contre les attaques inconnues. Les concepteurs du DES connaissaient la cryptanalyse différentielle et ses tables- S ont été optimisées contre elle. Il semble qu’ils ne connaissaient pas la crypta nalyse linéaire et les tables du DES sont très faibles contre elle [1027]. Des tables-S1 aléatoires seraient plus faibles contre la cryptanalyse différentielle et plus fortes contre la cryptanalyse linéaire. D’un autre côté, des tables -5 aléatoires peuvent ne pas être optimales contre ces deux attaques, mais on peut les rendre assez grandes pour qu’elles soient suffisament ré sistantes. Il y aussi plus de chances pour qu’elles soient suffisament résistantes aux attaques inconnues. Le débat fait toujours rage, mais mon opinion est que les tables S devraient être aussi grandes que possible, aléatoires, et dépendantes de la clef.
Concevoir un algorithme de chiffrement par blocs Il est facile de concevoir un algorithme de chiffrement par blocs. Si vous visualisez un algorithme avec des blocs de taille 64 bits comme une permutation des nombres de 64 bits, il est clair qu’à peu près toutes ces permutations sont sûres. La difficulté consiste à concevoir un algorithme non seulement sûr, mais aussi facile à décrire et à réaliser. Il est facile de concevoir un algorithme si vous assez de mémoire pour des tables-5 à 48*32 bits. Il est difficile de concevoir un DES non sûr si vous faites 128 rondes. Si votre clef fait 512 bits, vous ne vous souciez pas ses propriétés de complémentation. Le vrai but — et la raison pour laquelle la conception d’algorithmes de chiffrement par blocs est si difficile — est de concevoir un algorithme avec une plus petite clef possible, des besoins en espace mémoire les plus petits possibles, et un temps d’exécution le plus court possible.
Chapitre 14
372
14.11
Encore d’autres algorithmes de chiffrement par blocs
Utilisation de fonction de hachage à sens unique
Le moyen le plus simple de chiffrer avec une fonction de hachageà sens uniqueconsiste à appliquer cette fonction à la concaténation du bloc de textechiffré précédent et de la clef, puis à combiner le résultat avec le bloc de texte en clair courant par ou exclusif: Ci = M t © H { K , C i - 1 ) M.% = Ci © H ( K, Ci —1 )
La taille des blocs est celle de la sortie de la fonction de hachage Ceci donne en fait un algorithme en mode C FB . Une construction similaire donne un algorithme en mode OFB:
Ci = M i ® Si ; Si = HiKiCi-i) M i = Ci ® Si ; St = H ( K , C t- i )
La sécurité de ce schéma dépend de celle de la fonction de hachage.
Karn Cette méthode, inventée par Phil K a r n et placée dans le domaine public, dérive un algorithme de chiffrement réversible à partir d’une fonction de hachage à sens unique particulière. L’algorithme manipule le texte en clair et le texte chiffré par blocs de 32 octets.La clef peut avoir n’importe quelle longueur, bien que certaines longueurs de clefs soient plus efficaces pour certaines fonctions de hachage à sens unique. Pour les fonctions de hachage à sens unique M D 4 et M D5, des clefs de 96 octets (768 bits) conviennent le mieux. Pour chiffrer, divisez d’abord le texte en clair en deux moitiés de 16 octets: M g et M d ■ Ensuite, divisez la clef en deux moitiés de 48 octets: K g et KdM = M g, Md K = K g; K d
Joignez K g et M g et calculez l’empreinte par une des fonctions de hachage à sens unique décrites au chapitre 14, ensuite combinez cette empreinte par ou exclusif avec M d pour obtenir la moitié droite du texte chiffré: Cd- Ensuite, joignez Kd à Cd et calculez l’empreinte par la fonction de hachage à sens unique, ensuite combinez le résultat par ou exclusif avec M g pour obtenir Cg. Finalement, joignez Cd à Cg pour produire le texte chiffré. Cd = M d ® H { M g, Kg) Cg = M g ® H { M d , K d)
C = Cgffd
14-11
Utilisation de fonction de hachage à sens unique
373
Pour le déchiffrement, inversez simplement le processus. Joignez K,j et C,j, calculez l’empreinte et combinez la par ou exclusif avec Cg pour produire A4g. Joignez K g à M.g, calculez l’empreinte et combinez-la par ou exclusif avec Cd pour obtenir AidM g = C g © H(Cg, K g) Aid — Cg © H{Cd,Kd) A4 = A4g,A4d
La structure générale de l’algorithme est la même que la plupart des algorithmes par blocs décrits dans cette section. Il n’y a que 2 rondes, car la complexité de l’algorithme est cachée dans la fonction de hachage à sens unique. Et, puisque la clef n ’est utilisée que comme entrée à la fonction de hachage à sens unique, elle ne peut pas être retrouvée par une attaque à texte en clair choisi — en faisant, bien sûr, l’hypothèse que la fonction de hachage à sens unique est sûre.
Luby—Rackoff Michael L u b y et Charles R a c k o f f montrèrent que K a r n n’était pas sûr[1002]. Considérez deux messages d’un bloc : A B et A C . Si le cryptanalysteconnaît à la fois le texte en clair et le texte chiffré du premier message, et s’il connaît la première moitié du texte en clair du second message, alors il peut aisément calculer la deuxième moitié du second message. Ceci est une attaque à texte en clair connu utile seulement dans certaines circonstances mais c ’est un problème de sécurité majeur. Un algorithme de chiffrement à trois rondes évite ce problème [1002, 1645, 1646]. Il utilise trois fonctions de hachage à sens unique Hi, H 2 et H3. Des travaux plus poussés ont montré que l’on peut prendre f / j = H 2 ou bien H 2 ~ Hz, mais pas les deux en même temps [1202]. De plus, H\, H 2 et Hz ne peuvent pas se baser sur l’itération de la même fonction de base [1645]. Dans tous les cas, en supposant que H{k,x) se comporte comme une fonction pseudo-aléatoire, voici une version à trois rondes : 1° divisez la clef en deux moitiés K g et Kd ; 2° divisez le bloc de texte en clair en deux moitiés Go et Do ; 3° joignez K g à Go et calculez l’empreinte du résultat à l’aide de la fonction de
hachage à sens unique; combinez l’empreinte par ou exclusif avec D 0 pour obtenir D\ : Di = Do © H ( K g,Go) ;
4° joignez Kd à D\ et calculez l ’empreinte du résultat à l’aide de la fonction de hachage à sens unique; combinez l’empreinte par ou exclusif avec G q pour obtenir G x : Gi = G 0 ® H ( K d, Dl ) ;
5° joignez K g à G 1 et calculez l’empreinte du résultat à l’aide de la fonction de hachage à sens unique; combinez l’empreinte par ou exclusif avec Di pour obtenir D 2 : D 2 — D 1 ® H ( K g,Gi) ;
6° joignez G 1 à D 2 pour obtenir le message.
Chapitre 14
Encore d’autres algorithmes de chiffrement par blocs
« Message Digest Cipher » (M DC) M D C , inventé par Peter G uTM A N N [677], est un moyen de transformer une fonction de hachage à sens unique en un algorithme de chiffrement par blocs qui opère en mode C FB . Le système est virtuellement aussi rapide et au moins aussi sûr que la fonction de hachage. Il est supposé dans le reste du paragraphe que vous êtes familier avec le chapitre 18. Les fonctions de hachage telles que M D5 et SHA utilisent un bloc de 512 bits de texte pour transformer une valeur d ’entrée (de 128 bits dans M D5, et 160 bits dans SHA) en une valeur de sortie de même taille. Cette transformation n’est pas inversible, mais elle est parfait pour le mode C F B : la même opération est utilisée pour le chiffrement et le déchiffrement. Examinons M D C avec SHA. M D C a une taille de blocs de 160 bits et une clef de 512 bits. La fonction de hachage est utilisée par effets de bord avec l’ancienne empreinte comme bloc de texte en entrée (160 bits) et la clef comme entrée de 512 bits (voir la figure 14.5). Normalement, quand on utilise la fonction de hachage seulement pour calculer l’empreinte d ’une entrée, l’entrée de 512 bits varie chaque fois que l’empreinte d’un nouveau bloc de 512 bits est calculée. Mais dans ce cas, l’entrée de 512 bits devient une clef fixe.
C le f
B lo c m essage
Valeur d ’ entree
— ►
Fonction de hachage
Valeur -------►
de sortie
F onction de hachage
T exte en c la ir-
-► Texte chiffre
(b ) F onction de hachage utilisée en tant
(a ) F onction d e hachage
q u ’ algonthm e de chiffrem ent par b lo c en m od e CFB
F ig .
14.5 - M D C
M D C peut être utilisé avec n ’im p orte quelle fonction de hachage à sens unique : MD4, M D5, S n e f r u , et autres. Il n ’est pas breveté. N ’im porte q u i peut l ’utiliser à tout m om ent, com m e il le désire, sans payer de royalties [677]. Cependant, je ne fais pas confiance à cette construction. Il est possible d’attaquer la fonction de hachage d’une manière qui échappe à ce qui est prévu dans sa conception. Il n’est pas important que les fonctions de hachage à sens unique résistent aux attaques à textes en clair choisis, où un cryptanalyste choisit plusieurs de ces valeurs de départ de 160 bits, les « chiffre » par la même « clef » de 512 bits, et utilise cela pour obtenir des informations sur la clef de 512 bits utilisée. Comme les concepteurs de la fonction de hachage ne se sont pas préoccupés de cela, il semble que c ’est une mauvaise idée d ’espérer voir votre algorithme de chiffrement par blocs résister à cette attaque.
14-12
Choisir un algorithme de chiffrement par blocs
375
Sécurité des algorithmes de chiffrement basés sur des fonctions de hachage à sens unique Même si ces constructions peuvent être sûres, elles dépendent du choix de la fonc tion de hachage à sens unique sous-jacente. Une bonne fonction de hachage ne fait pas forcément un algorithme de chiffrement sûr. Les nécessités cryptographiques sont différentes. Par exemple, la cryptanalyse linéaire n’est pas une attaque envisageable contre les fonctions de hachage à sens unique, mais elle marche contre les algorithmes de chiffrement. Une fonction de hachage telle que SHA pourrait présenter des caracté ristiques linéaires qui pourraient fragiliser un algorithme de chiffrement tel que M D C, sans pour autant affecter la sécurité de SHA en tant que fonction de hashage. Je ne connais aucune cryptanalyse particulière à des algorithmes de chiffrement basés sur des fonctions de hachage ; attendez l’arrivée d ’une telle analyse avant d ’avoir confiance en l’un d ’eux.
14.12
Choisir un algorithme de chiffrement par blocs
C’est une question difficile. Le DES n’est certainement pas sûr contre les principaux gouvernements mondiaux à moins que vous ne chiffriez que de petites quantités de données avec la même clef. Il est probablement suffisant contre n’importe qui d’autre, mais cela est train de changer. Toutes sortes d ’organisations auront bientôt les moyens de se payer des machines dédiées à la recherche exhaustive de clefs pour le DES. Les tables S dépendantes de la clef de B i h a m résisteront probablement des années à tous les adversaires excepté les plus fortunés, et peut-être même à ceux-ci aussi. Si vous voulez une confidentialité qui perdure des décades ou si vous avez peur des possibilités de cryptanalyse des principaux gouvernements, utilisez le DES triple avec trois clefs indépendantes. Les autres algorithmes ne sont pas dénués d ’intérêt. J’aime B l o w f i s h pour sa rapidité et pour l’avoir écrit. 3-W A Y a l’air bon, et G O S T est probablement acceptable. Le problème pour recommander l'un d ’eux est que la NSA dispose certainement d’une bat terie impressionante de techniques cryptanalytiques qui sont toujours classées secrètes, et je ne sais pas quels sont les algorithmes qu’ils peuvent casser avec. Le tableaul4.3 donne les rapidités de quelques algorithmes. Ils sont là à titre de comparaison. Mon algorithme favori est ID E A . Sa clef de 128 bits, combinée avec sa résistance à toutes les méthodes de cryptanalyse connues publiquement, m’incline à le préférer. L’algorithme a été cryptanalyse par de nombreux groupes différents, et aucun résultat sérieux n’a été révélé jusqu’à présent. On annoncera peut-être demain des résultats de cryptanalyse dévastateurs ; en attendant je parie sur ID EA.
376
Chapitre 14
Encore d’autres algorithmes de chiffrement par blocs
T a b . 14.3 - Vitesse de chiffrement de quelques algorithmes de chiffrement par blocs sur un 486SX à 33 MHz_________________________________________________________
Algorithme
Vitesse de chiffrement (kilo-octets/seconde) Algorithme
B l o w f ish (12 rondes) 182 B l o w f ish (16 rondes) 135 B l o w fish (20 rondes) 110 DES 35 F E A L -8 300 F E A L -16 161 F E A L -3 2 91 G O ST 53 ID E A 70 221 K h u fu (16 rondes) K h u fu (24 rondes) 153 K h u fu (32 rondes) 115 L u b y - R a c k o f f (avec M D 4 )4 7 L u b y - R a c k o f f (avec M D 5 )3 4 L u b y -R a c k o f f (avec S H A ) 11 52 L u c ife r
Vitesse de chiffrement (kilo-octets/seconde)
M D C (avec M D 4 ) M D C (avec M D 5 ) M D C (avec S H A ) N e w DES
186 135 23 233
R E D O C II R E D O C III R C 5 -3 2 /8 R C 5 -3 2 /1 2
78 127
1
86
R C 5 -3 2 /1 6 R C 5 -3 2 /2 0 S A F E R (6 rondes) S A F E R (8 rondes) S A F E R (10 rondes) S A F E R (12 rondes) 3 -W A Y
65 52 81 61 49 41 25
D E S triple
12
Chapitre 15
Combinaison d’algorithmes de chiffrement par blocs Il existe de nombreuses façon de combiner des algorithmes de chiffrement par blocs pour obtenir de nouveaux algorithmes. Le but de la manœuvre est d ’essayer d ’augmenter la sécurité en évitant les turpitudes de la conception d ’un nouvel algorithme. Le DES est un algorithme sûr ; il a été cryptanalysé pendant plus de vingt ans et le meilleur moyen de la casser en pratique reste l’attaque exhaustive. Cependant, la clef est trop courte. Ne serait-il pas souhaitable d ’utiliser le DES comme un élément de base d ’un autre algorithme? Nous aurions tous les avantages: l’assurance de deux décennies de cryptanalyse et une longue clef. Le surchiffrement est une technique de combinaison : utiliser le même algorithme pour chiffrer le même bloc de texte en clair plusieurs fois avec différentes clefs. Il existe d’autres techniques. Chiffrer un bloc de texte en clair deux fois avec la même clef, que ce soit avec le même algorithme ou avec un autre, ne sert pas à grand chose. Pour le même algorithme, cela n’affecte pas la complexité d ’une recherche exhaustive1. Pour des algorithmes différents cela peut être ou ne pas être le cas. Si vous allez utiliser une des techniques de ce chapitre, assurez vous que les différentes clefs sont différentes et indépendantes.
15.1
Surchiffrement double
Un moyen naïf d ’augmenter le niveau de sécurité d ’un algorithme de chiffrement par blocs est de chiffrer le bloc deux fois avec deux clefs différentes. Premièrement, chiffrez le bloc avec la première clef, et ensuite chiffrez le résultat avec la deuxième clef. Le déchiffrement est le processus inverse. C = E K2(E K l(M )) M
= D K l ( D K a(C ))
1. Rappelez vous de supposer qu ’ un cryptanalyste connaît les détails de l’ algorithm e ainsi que le nombre de chiffrements effectués.
378
Chapitre 15
Combinaison d’algorithmes de chiffrement par blocs
Si l’algorithme de chiffrement par blocs est un groupe (voir § 11.3), il existera forcément une clef K$ telle que : C = EK, { E Kl( M ) ) = E Ka(M) Dans le cas contraire, le bloc de texte chiffré résultant du double chiffrement serait beaucoup plus difficile à retrouver par recherche exhaustive. Au lieu de 2n tentatives (où n est le nombre de bits de la clef), il faudrait 22n tentatives. Si l’algorithme manipule des blocs de 64 bits, le texte doublement chiffré nécessiterait 2 128 tentatives pour retrouver la clef. Cela n’est pas vrai pour une attaque à texte en clair connu. M e r k l e et H e llm a n [1072] ont développé un compromis temps-mémoire qui, dans le cadre d’une attaque à texte en clair connu, permet de casser ce chiffrement double avec 2 n+1 tentatives et non pas 22" tentatives2. Cette attaque est appelée attaque par collisions et elle marche en chiffrant à une extrémité, en déchiffrant à l’autre et en mettant en correspondance les résultats au milieu. L’attaque est conduite de la manière suivante: le cryptanalyste connaît A4i, Ci, A4 2 et C2 , tels que : Ci -- E k 3 ( Ekx{ M 1 )) C2 — E k 2 ( E k, ( M . 2 ))
Pour tous les K possibles (soit K i , soit K 2 ), calculez Ek{-M-i) et gardez le résultat en mémoire. Quand vous les avez tous, calculez D u {Ci) pour tous les K et cherchez le même résultat en mémoire. Si vous le trouvez, il est possible que la clef courante soit K 2 et la clef en mémoire K j . Essayez de chiffrer M 2 avec K\ et K 2 : si cela donne C2, vous pouvez être pratiquement sûr (avec une probabilité de succès de 2 2n~2b, où b est la taille de bloc) que vous avez K\ et K 2. Sinon, continuez à chercher. Attendez-vous à avoir environ (22” -26) faux résultats positifs avant de trouver le bon. Le nombre maximal de tentatives de chiffrement que vous devrez probablement essayer est 2 x 2 ", ou 2 n+1. Si la probabilité d’erreurs est trop grande, vous pouvez utiliser un troisième bloc de texte chiffré pour avoir une probabilité de succès de 2 2n~ 3b. Il y a encore d’autres optimisations [914]. Cette attaque nécessite beaucoup de mémoire, 2n blocs. Pour un algorithme à 56 bits, cela donne 256 blocs de 64 bits, ou 259 octets. C ’est encore beaucoup de mémoire par rapport à ce que quelqu’un peut appréhender aisément mais c ’est suffisant pour convaincre le plus paranoïaque des cryptographes que le chiffrement double ne vaut rien. Pour une clef de 128 bits, la mémoire requise ateind la somme astronomique de 1039 octets. Si nous supposons qu’il existe un moyen de stocker un bit d’information sur un seul atome d ’aluminium, le périphérique de mémoire nécessaire à cette attaque formerait un cube d’aluminium solide de 1 km de côté. L ’attaque par collisions semble infaisable pour des clefs de cette longueur. . Une autre méthode de surchiffrement double, appelée parfois Davies-Price, est une variante de C B C [435]. Ct = EKl ( M t © EK2(Ci~i)) ■Mi — D k x{Ci ) © D k 2(Ci ~ 1 ) 2. Ils l’ont m ontré pou r le DES, mais le résultat peu t être généralisé à n ’ im porte quel algorithme de chiffrement par blocs.
15.2
Surchiffrement triple
379
Ils prétendent que « ce mode n’a pas de vertu spéciale », mais il semble vulnérable à la même attaque par collisions que les autres modes de surchiffrement double.
15.2
Surchiffrement triple
Surchiffrement triple avec deux clefs Une meilleure idée, proposée par T u c h m a n dans [1559], est de chiffrer un bloc trois fois avec deux clefs : primo avec la première clef, ensuite avec la seconde clef, et finale ment avec la première clef à nouveau. Il suggéra que l’expéditeur chiffre d’abord avec la première clef, ensuite déchiffre avec la deuxième clef et finalement chiffre avec la troisième clef. C = E k i ( D K2 (EKi ( M ))) M = D Kl(EK2 (DKl(C)))
Cette méthode est parfois appelée le mode « chiffre-déchiffre-chiffre » (ED E pour « encrypt-decrypt-encrypt ») [57]. Si l’algorithme de chiffrement par blocs a une clef de n bits, alors ce schéma a une clef de 2n bits. Le curieux schéma « chiffre-déchiffrechiffre » a été conçu par IB M pour préserver la compatibilité avec des réalisations conventionnelles de l’algorithme : en choisissant la même clef pour K\ et K 2 on ramène l’opération au chiffrement unique avec la clef. Il n’y a pas de sécurité inhérente au schéma « chiffre-déchiffre-chiffre » mais il a été utilisé pour améliorer l’algorithme DES dans les standards X 9.17 et ISO 8732 [57, 765]. K\ et I <2 sont alternées pour contrecarrer l’attaque par collisions décrite plus haut. SiC = E k 2 (E k 1 (Ei;i( M) ) ) , un cryptanalyste pourrait précalculer E ^ 1 (Ek, (.Ad)) pour tous les K i possibles et effectuer ensuite l’attaque. Cela ne requiert que 2n+2 chiffre ments. Le surchiffrement triple avec deux clefs n’est pas sujet à la même attaque par collisions décrite auparavant. Mais M e r k l e et H e l l m a n ont développé un autre compromis temps-mémoire qui peut casser cette technique en 2 n _ 1 étapes en utilisant 2 ” blocs de mémoire [1072]. Pour toutes les K 2 possibles, déchiffrer 0 et stocker le résultat en mémoire. Ensuite, déchiffrer 0 avec toutes les K\ possibles pour obtenir M .. Chiffrer alors triplement M. pour obtenir C, puis déchiffrer C avec K\. Si ce déchiffrement est un déchiffrement de 0 avec un K 2 (stocké en mémoire), la paire K \ ,K 2 est une candidate éventuelle. Vérifier si c’est juste. Sinon, continuer à chercher. C’est une attaque à texte en clair choisi, qui nécessite pour être montée, un nombre énorme de textes en clair choisis. Cela demande 2 " étapes, 2 ” blocs de mémoire et 2 b textes en clair choisis. Ce n ’est pas très pratique, mais c ’est une faiblesse. Paul van O o r s c h o t et Michael W ie n e r ont converti cette attaque en une attaque à texte en clair, nécessitant p textes en clair connus. Cet exemple repose sur l’hypothèse du mode EDE. 1° Deviner la première valeur intermédiaire a.
380
Chapitre 15
Combinaison d’algorithmes de chiffrement par blocs
2° Tabuler, pour chaque K % possible, la seconde valeur intermédiaire b quand la première valeur intermédiaire est a, en utilisant le texte en clair connu : b = D Kl(C) où C le texte chiffré provenant d’un texte en clair connu.
3° Regarder dans le tableau, pour chaque K 2 possible, les éléments qui donnent une seconde valeur valeur intermédiaire b qui correspond : b = E K2 (a)
4° La probabilité de succès est p/b où p est le nombre de textes en clair connus et b est la taille des blocs. Si aucune valeur ne correspond, essayer un autre a et recommencer.
L’attaque requiert 2rl+rn/ p étapes et p blocs de mémoire. Pour le DES, cela fait 2120/p [1564]. Pour p supérieur à 256, cette attaque est plus rapide que la recherche exhaustive
Surchiffrement triple avec trois clefs Si vous allez utiliser le chiffrement triple, je recommande trois clefs différentes. La longueur de clef est plus grande, mais le stockage de la clef n’est, en général, pas un problème. C = E K3 {DK2 {EKl{M) ) ) •M = S>k , ( E K2 (Ük 3 (C)))
L’attaque avec le meilleur compromis temps-mémoire nécessite 22" étapes et 2” blocs de mémoire [1072]. Le chiffrement triple, avec trois clefs indépendantes, est aussi sûr que ce que l’on pourrait attendre du chiffrement double.
Surchiffrement triple avec clef minimale (TEM K ) Il existe un moyen sûr d’utiliser le surchiffrement triple avec deux clefs qui n’est pas sujet à l’attaque précédente. Cela s’appelle le surchiffrement triple avec clef minimale (T E M K pour « Triple Encryption with Minimum K ey ») [858]. L ’astuce consiste à dériver trois clefs de deux et X 2 : K l = E x , (D X2 (EX i (Ti))) K 2 = E X2 (DXl ( e X2 { t 2))) K 3 = EXl (E > x2 (EX i (T3)))
Ti, T2 et I 3 sont des constantes non nécessairement secrètes. Cette une construction spéciale qui garantie que pour n’importe quelle paire de clefs, la meilleure attaque est une attaque à texte en clair connu.
15.2
Surchiffrement triple
381
Modes de surchiffrement triple ne suffit pas de spécifier surchiffrement triple ; il y a plusieurs manières de le faire. En choisir une affecte à la fois la sécurité et l’efficacité. Voici deux modes possibles de surchiffrement triple : 11
C B C interne. Chiffrer le fichier entier en mode C B C trois fois (voir la figure 15.1a). Cela nécessite trois IV différents. Cj = EK3(Si(BCi-1) ; St = Dfc2(TiQ)Si^i) ; T) = M i — Ti^iCBDh^i'E) ; Tt — Sl-\ Q)Ek .2(Si) ; S, -
C * _ i
(BD^-ffCi)
Co, S0 et T0 sont les IV.
C B C externe. Surchiffrer triplement le fichier entier en mode C B C (voir la figure 15.1b). Cela nécessite un seul IV. Ci = EKs (Dk 2 (Ekx(M i © C ,_ i))) Ci = 1 © D Kl ( Ek 2 (D a 3 (Ci))) Le IV est Co-
F ig .
15.1 - Surchiffrement triple en mode CB C
Les deux modes requièrent plus de ressources que le chiffrement simple : plus de ma tériel ou plus de temps. Cependant, avec trois puces de chiffrement, la bande passante
382
Chapitre 15
Combinaison d’algorithmes de chiffrement par blocs
du C B C interne est aussi grande que celle du chiffrement simple. Comme les trois chif frements C B C sont indépendants, les trois puces peuvent travailler en permanence, chacune ayant une rétroaction sur elle-même. Par contre, la rétroaction du C B C externe est extérieure aux trois chiffrements. Cela veut dire que même avec trois puces, la bande passante est le tiers de celle du chiffrement simple. Pour obtenir la même bande passante, il faut intercaler des IV (voir § 9.12) : Ci = E k 3 {D k 3 ( E ^ i - M i
3)))
Dans ce cas, les IV sont Co, C 1 et C _ 2 . Cela ne facilite pas les réalisations logicielles, à moins que vous ne disposiez d’une machine parallèle. Malheureusement, le mode le plus simple est aussi le moins sûr. BIHAM a étudié plu sieurs modes dans l’optique de la cryptanalyse différentielle à texte chiffré choisi et a trouvé que le C B C interne est seulement légèrement plus sûr que le chiffrement simple contre une attaque différentielle. Si vous visualisez le surchiffrement triple comme un seul algorithme plus gros, alors la rétroaction interne autorise l’introduction d ’infor mation connue et externe dans les rouage internes de l’algorithme ; ceci facilite la cryptanalyse. Les attaques différentielles ont besoin d ’une quantité énorme de textes chiffrés choisis et ne sont pas très pratiques, mais les résultats devraient inspirer la méfiance des paranoïaques. Un autre examen vis à vis de l’attaque par colüsions et de l’attaque exhaustive montre qu’ils sont tous les deux sûrs [807]. Il existe aussi d’autres modes. Vous pouvez chiffrer le fichier entier une fois en ECB, puis deux fois en C B C ; ou une fois en C B C , une fois en EC B , et une fois en CBC ; ou encore deux fois en C B C et une fois en E C B . B ih a m a montré que ces variantes ne sont pas plus sûres que le DES vis à vis d ’une attaque par cryptanalyse différentielle à texte en clair choisi [170]. Et il n’y a pas beaucoup d’espoir pour les autres variantes. Si vous voulez utiliser le surchiffrement triple utilisez des modes sans rétroaction externe.
Variantes du surchiffrement triple Avant qu’il y ait des preuves que le DES n’est pas un groupe, plusieurs schémas de surchiffrement furent proposés. Une façon de s’assurer que le surchiffrement triple ne se réduit pas à un simple chiffrement consiste à changer effectivement la taille des blocs. Une méthode simple est d’ajouter un bit de remplissage. Complétez le texte avec une chaîne de bits aléatoires de longueur égale à la moitié de la longueur d’un bloc, entre le premier et le second et entre le second et le troisième chiffrement (voir la figure 15.2). Si P est la fonction de remplissage, on a : C = E K3 ( P ( DK2 (P(EKl(M)))))
Ce remplissage non seulement brouille les motifs réguliers mais aussi superpose les blocs chiffrés comme des briques. Cela ne rajoute qu’un bloc à la longueur du message. Une autre technique, proposée par Cari E llison consiste à utiliser de fonction de permutation sans clef entre les trois chiffrements. La permutation pourrait opérer sur de grands blocs— de l’ordre de 8 kilo-octets— et donnerait une taille de bloc effective de 8 kilo-octets à cette variante. En supposant que la permutation est rapide, cette variante n’est pas beaucoup plus lente que le surchiffrement triple classique. C = E K3(T(DK2(T(EKl(M)))))
15.2
Surchiffrement triple
383
T rassemble un block en entrée (jusqu’à 8 kilo-octets de long) et utilise un générateur pseudo-aléatoire pour le transposer. Le changement d’un bit en entrée cause le change ment de huit octets en sortie après le premier chiffrement, de 64 octets au mieux après le deuxième chiffrement, et de 512 octets au mieux après le troisième chiffrement. Si chaque algorithme par blocs fonctionne en mode C B C , comme proposé à l’origine, alors l’effet du changement d’un seul bit a des chances d ’atteindre le bloc de 8 kilo-octets en entier, même dans les blocs autres que le premier.
La version la plus récente de ce schéma répond à l’attaque de B ih a m sur le CBC interne en introduisant une passe de blanchiment pour masquer les motifs du texte en clair. Cette passe est un flot de combinaisons par ou exclusif avec un générateur de nombres aléatoires cryptographiquement sûr, appelé R ci-dessous. L’application de T avant et après empêche le cryptanalyste de savoir à priori quelle clef a été utilisée pour chiffrer n’importe quel bit donné en entrée du dernier chiffrement. Le deuxième chiffrement est noté nE (chiffrement avec n clefs utilisées de manière cyclique) :
C = E Ks(R(T(nEK2(T(EKl( m ) ) ) Tous les chiffrement sont fait en mode C B C et les clefs sont fournies au moins pour les n + 2 clefs de chiffrement et générateur de nombres aléatoires cryptographiquement sûr. Ce schéma a été proposé avec le DES, mais il fonctionne avec n’importe quel algorithme de chiffrement par blocs. Je ne connais aucune étude de la sécurité de ce schéma.
384
15.3
Chapitre 15
Combinaison d’algorithmes de chiffrement par blocs
Doublement de la longueur de bloc
Certains arguments circulent dans la communauté académique pour savoir si des blocs de 64 bits sont suffisament longs. D ’un côté, cette taille ne permet la diffusion du texte en clair que sur 8 octets du texte chiffré. D ’un autre côté, une taille de blocs plus grande rend les motifs difficiles à masquer de façon sûre ; il n’y a plus de place pour les erreurs. Certains ont proposé de doubler la longueur des blocs d ’un algorithme en utilisant le surchiffrement [305]. Avant de réaliser cela, vérifiez l’existence potentielle d ’attaques par collisions. Le schéma de Richard OUTERBRIDGE, illustré par la figure 15.3, n’est pas plus sûr que le surchiffrement triple à deux clefs avec une taille de bloc classique [859].
F ig . 15.3 - Doublement correct de la longueur de bloc
Cependant, je ne conseille pas ce genre de choses. Ce n’est pas plus rapide que le surchiffrement triple conventionnel : il faut toujours six chiffrements pour chiffrer deux blocs de données. Nous connaissons les caractéristiques du surchiffrement triple ; les constructions telles que celle-ci ont souvent des vices cachés.
15.4
Autres schémas de surchiffrement
Le problème avec le surchiffrement triple avec deux clefs est qu’il permet de doubler l’espace des clefs, mais nécessite trois chiffrements par bloc de texte en clair. Ne seraitil pas opportun de trouver un moyen intelligent de combiner deux chiffrements de manière à doubler l’espace des clefs?
15.4
Autres schémas de surchiffrement
385
Mode compteur OFB double Cet algorithme utilise un algorithme par blocs pour générer deux flots de clefs qui sont alors utilisés pour chiffrer le texte en clair. Si — E ü ïiS i-i © f i ) ; f i = / i + l
Ti — E x2(Ti-1 © I 2) ; h = I2 + 1 Ci = M z © Si © Ti
Si et Ti sont des variables internes et Ji et J2 sont des compteurs. Deux copies de l’al gorithme fonctionnent dans une sorte de mode compteur O F B , et le texte en clair Si et Tt sont combinés ensemble par ou exclusif. Les deux clefs K\ et K 2 sont indépendantes. Je ne connais aucune cryptanalyse de cette variante.
ECB avec OFB Cette méthode a été conçue pour chiffrer plusieurs messages de même taille fixée, par exemple des secteurs de disques [193, 194], Utiliser deux clefs. Il faut tout d’abord créer un masque à la taille voulue à l’aide de K i et de l’algorithme. Ce masque sera utilisé à chaque fois qu’on chiffre un message avec les mêmes clefs. Combinez alors par ou exclusif le texte en clair avec le masque. Finalement, chiffrez le résultat avec l’algorithme et / f 2 en mode E CB. Ce mode n’a pas été analysé ailleurs que dans l’article où il est apparu. Il est claire ment au moins aussi solide qu’un simple chiffrement en mode E C B et peut-être aussi solide que deux passes de l’algorithme. Un cryptanalyste pourrait vraissemblablement chercher les deux clefs indépendamment si plusieurs textes en clair connus sont chiffrés avec les mêmes clefs. Pour contrecarrer l’analyse de blocs identiques à des positions identiques dans différents messages, vous pouvez ajouter un IV. A l’inverse de l’utilisation classique d’un IV dans tous les autres modes, ici l’IV est combiné par ou exclusif avec chaque bloc du message avant le chiffrement en mode E CB. Matt B l a z e a conçu ce mode pour son sytème cryptographique de fichiers sous U N IX (appelé CFS pour « Cryptographie File System »). C’est un mode pratique car la latence n’est que d’un chiffrement en mode E C B ; on peut générer le masque une fois pour toutes en le stockant. Dans CFS, l’algorithme de chiffrement n’est autre que le DES.
xDES* Dans [1646, 1647], le DES est utilisé comme élément de construction d’une série d’al gorithmes de chiffrement par blocs avec à la fois une taille de clef et une taille de bloc plus grandes. Ces constructions ne dépendent pas du tout du DES et peuvent être reproduites avec n’importe quel algorithme par blocs. Le premier algorithme, x D E S 1, est simplement une construction de LlJBY-RACKOFF avec l’algorithme de chiffrement par blocs comme fonction sous-jacente (voir § 14.11). La taille de bloc et la taille de clef sont respectivement le double de celles de l’algorithme sous-jacent. Dans chacune des trois rondes, chiffrez la moitié droite avec l’algorithme par blocs et l’une des clefs, combinez le résultat par ou exclusif avec la moitié de gauche, et échangez les deux moitiés.
386
Chapitre 15
Combinaison d’algorithmes de chiffrement par blocs
C’est plus rapide que le surchiffrement triple classique car trois chiffrements permettent de chiffrer deux fois plus que l’algorithme sous-jacent. Mais une simple attaque par collisions permet de trouver la clef avec 2 k blocs de mémoire, où k est la taille de la clef de l’algorithme sous-jacent. Chiffrez la moitié droite d’un bloc de texte en clair avec toutes les valeurs possibles de K\, combinez la par ou exclusif avec la moitié gauche du texte en clair, et stockez ces valeurs dans un tableau. Chiffrez alors la moitié droite du texte chiffré avec toutes les valeurs possibles de K 3 et regardez si cela correspond à une des valeurs du tableau. Si vous en trouvez une, la paire de clefs K i , K 3 forme un candidat potentiel. Répétez l’attaque plusieurs fois et il ne restera qu’un seul candidat. Cela montre que x D E S 1 n’est pas une solution idéale. Il y a même pire, il existe une attaque à texte en clair choisi qui prouve que x D E S 1 n ’est pas beaucoup plus sûr que l’algorithme de chiffrement par blocs sous-jacent [858], xD E S2 étend cette idée à un algorithme à 5 rondes avec une taille de bloc 4 fois supérieure et une taille de clef 10 fois supérieure à celles de l’algorithme sous-jacent. La figure 15.4 illustre une ronde de x D E S 2 ; chacun des quatre sous-blocs ont même taille que les blocs de l’algorithme sous-jacent et les 10 clefs sont indépendantes.
F ig . 15.4
Une ronde de x D E S 2
Ce schéma est lui aussi plus rapide que le surchiffrement triple : dix chiffrements per mettent de chiffrer un bloc de taille quatre fois plus grande. Cependant, il est vulné rable à la cryptanalyse différentielle [858] et ne devrait pas être utilisé. Le schéma est vulnérable même si le DES est utilisé avec des clefs de rondes indépendantes. Pour i > 3, xDES* est probablement trop imposant pour s’avérer utile en tant qu’al gorithme par blocs. Par exemple, la taille de bloc de xD E S6 est six fois supérieure à celle de l’algorithme sous-jacent, sa taille de clef est 21 fois supérieure, et 21 chiffre ments sont nécessaires pour chiffrer un bloc six fois plus gros que ceux de l’algorithme sous-jacent. Le surchiffrement triple est plus rapide.
Surchiffrement quintuple Si le surchiffrement triple ne vous paraît pas assez sûr vous avez peut-être besoin de chiffrer des clefs du surchiffrement triple en utilisant un algorithme encore plus sûr—
Troncature de clef (dans C D M F )
15.5
387
alors vous pourriez utiliser des surchiffrements de plus haut degré. Le surchiffrement quintuple est très résistant à l’attaque par collisions3. C = E Ki(DK2 (EK3 (DK2 ( E k A M ) ) ) ) )
M = DK i (EK2(DK3(EKADKi (C))))) Cette construction est compatible avec le surchiffrement triple en prenant = K 3 et aussi avec le chiffrement conventionnel en prenant K \ = K 2 = K 3. Bien sûr, il serait encore plus sûr de prendre cinq clefs indépendantes.
15.5
Troncature de clef (dans CDMF)
IBM a conçu cet algorithme pour leur utilitaire C D M F (voir § 24.8) pour réduire une clef de 56 bits à 40 bits ce qui est la taille requise pour l’exportation [785]. La clef est supposée inclure les bits de parité. 1° Mettre à zéro les bits de parité qui sont les bits 8, 16, 24, 32, 40, 48, 56, 64. 2° Chiffrer le résultat de l’étape 1 avec le DES et la clef OxC408B0540BAlEOAE, et combiner le résultat avec la clef obtenue à l’étape 1 par ou exclusif. 3° Mettre à zéro les bits suivants dans le résultat de l’étape 2 : 1, 2, 3, 4, 8, 16, 17, 18, 19, 20, 24, 32, 33, 34 35, 36, 40, 48, 49, 50, 51, 52, 56, 64. 4° Chiffrer le résultat de l’étape 3 avec le DES et la clef 0xEF2C041CE6382FE6. Cette clef est alors utilisée pour chiffrer les messages.
Retenez que cette méthode racourcie la longueur des clefs, et affaiblit par conséquent l’algorithme.
15.6
Blanchiment
B lanchim ent est le no m donné à une technique consistant à com biner p a r ou exclusif une partie de la clef avec l ’entrée d ’un algorithm e de chiffrement p a r blocs, et à com biner
La variante D ESX, RSA D I, est la prem ière à l ’avoir em ployée; viennent ensuite K h u f u
par ou exclusif une pa rtie de la clef avec la sortie de l ’algorithm e. développée p a r et K
hafre
(probablem ent indépendam m ent de celle-là)4.
L’idée est d’empêcher le cryptanalyste d’obtenir une paire texte en clair, texte chiffré pour l’algorithme en question. La technique oblige les cryptanalystes à deviner non seulement la clef de l’algorithme, mais aussi les valeurs de blanchiment. Comme il y a une combinaison par ou exclusif avant et après l’algorithme, cette technique n’est pas propice à une attaque par collisions. C = K 3 0 E K 2( M ® A r) M
= K i © D K 2(C © K 3)
3. Des arguments similaires à ceux utilisés à propos du surchiffrement dou ble perm ettent de mon trer que le surchiffrement quadruple n’a pporte qu’ une faible am élioration de sécurité par rapport au surchiffrement triple. 4. RiVBST a nom m é cette technique ainsi, ce m ot n’ est pas d ’ un usage conventionnel.
388
Chapitre 15
Combinaison d’algorithmes de chiffrement par blocs
Si K i = K%, une attaque exhaustive nécessite 2n+fc/,p opérations où n est la taille de la clet, b la taille des blocs, et p le nombre de textes en clair connus. Si K\ et K-A sont différentes, une attaque exhaustive nécessite 2 " 15 11 opérations avec trois textes en clair connus. Contre les cryptanalysés différentielle et linéaire, ces mesures ne fournissent que quelques bits de clef de protection. Mais sur le plan du temps de calcul, c’est un moyen très économique d ’augmenter la sécurité d ’un algorithme de chiffrement par blocs.
15.7
Mise en cascade de plusieurs algo rithmes
Qu’en est-il si on chiffre le bloc tout d’abord avec l’algorithme A et la clef K a et ensuite avec l’algorithme B et la clef K b ? Il se peut qu’Alice et Bernard ne soient pas d ’accord sur la sécurité des algorithmes : Alice veut utiliser un algorithme A et Bernard veut utiliser un algorithme B. Cette technique est parfois appelée m ise en cascade et peut être généralisée à bien plus de deux algorithmes et deux clefs. Les pessimistes disent qu’il n’y a pas de garantie que les deux algorithmes ensemble augmenteront le niveau de sécurité. Il pourrait y avoir des interactions subtiles entre les deux algorithmes qui, au contraire, diminueraient le niveau de sécurité. Même le surchiffrement avec deux ou trois algorithmes différents pourrait ne pas être aussi sûr que vous le croyez. La cryptographie est un art difficile. La réalité est beaucoup plus rose. Les avertissements précédents ne valent que si les clefs sont reliées les unes aux autres. Dans le cas où toutes les clefs sont indépendantes, le résultat est au moins aussi difficile à casser que le premier algorithme [1042]. Si le second algorithme est vulnérable à une attaque à texte en clair choisi, alors le premier algorithme pourrait faciliter cette attaque et rendre le second algorithme vulnérable à une attaque à texte en clair connu seulement quand ils sont utilisés en cascade. Cette attaque potentielle n’est pas limitée aux algorithmes de chiffrement : si vous laissez quelqu’un d ’autre précisez quel algorithme est utilisé sur vos messages avant chiffrement, vous feriez mieux de vous assurer que votre chiffrement résistera à une attaque en texte en clair choisi5. On peut formuler cela de meilleure manière ainsi : face à une attaque à texte en clair choisi, une cascade d ’algorithmes de chiffrement est au moins aussi difficile à casser que l’une de ses composantes [858]. Un précédent résultat statuait qu’une cascade d ’algorithmes est au moins aussi difficile à casser que la plus solide de ses composantes, mais ce résultat est basé sur des hypothèses non fondées [530]. C ’est seulement quand les algorithmes commutent, comme c’est le cas pour une cascade d’algorithmes de chiffrement en continu (ou d’algorithmes de chiffrement par blocs en mode O F B ), que leur mise en cascade donne un résultat au moins aussi solide que le plus solide des algorithmes la composant. Si Alice et Bernard n’ont pas confiance en l’algorithme de l’autre, ils peuvent utiliser une mise en cascade. Si ce sont des algorithmes de chiffrement en continu, l’ordre n’a pas d ’importance. Si ce sont des algorithmes par blocs, Alice peut utiliser l’algorithme 5. N otez au passage que l’ algorithm e utilisé couram m ent pou r com presser et numériser la parole à la vitesse des m odem s est C E L P qui a été con çu par la NSA.
15.8
Combïaer plusieurs algorithmes de chiffrement par blocs
389
A puis B et Bernard qui a plus confiance en B peut utiliser B puis A. Ils pourraient même ajouter un bon algorithme de chiffrement en continu entre les deux ; cela ne fait pas de mal et ça peut très bien augmenter la sécurité. Retenez que chaque clef doit être indépendante. Si A a une clef de 64 bits et B une clef de 128 bits, le résulat après mise en cascade doit avoir une clef de 192 bits. Si vous n’utilisez pas des clefs indépendantes, alors il y a beaucoup plus de chances que les pessimistes aient raison.
15.8
Combiner plusieurs algorithmes de chiffrement par blocs
Voici un autre moyen de combiner plusieurs algorithmes de chiffrement par blocs, l’un d’eux offre au moins autant de sécurité que chaque algorithme. Effectuer avec deux algorithmes (et deux clefs indépendantes) les opérations suivantes : 1° Générer une chaîne de bits aléatoire R de même taille que le message. 2° Chiffrer R avec le premier algorithme. 3° Chiffrer R (B A4 avec le second algorithme. 4° Le texte chiffré est le résultat des étapes 2 et 3.
En supposant que la chaîne de bit est réellement aléatoire, cette méthode consiste à chiffrer A4 avec un masque jetable et à chiffrer à la fois le message chiffré et le masque, chacun avec un des deux algorithmes. Comme les deux sont nécessaires pour reconstruire A4, un cryptanalyste doit casser les deux algorithmes. L ’inconvénient est que le texte chiffré est deux fois plus gros que le texte en clair. On peut étendre cette méthode pour un plus grand nombre d’algorithmes, mais le texte chiffré augmente avec chaque addition d ’un algorithme. C ’est une bonne idée, mais je ne pense pas qu’elle soit très pratique.
Chapitre 16
Générateurs de suites aléatoires et chiffrement en continu 16.1
Générateurs suites
pseudo-aléatoires
de
Générateurs linéaires congruentiels Les g é n é r a t e u r s lin é a ir e s c o n g r u e n t ie ls sont des générateurs pseudo-aléatoires de suites de la forme : X n = {u X n _i
4- b) mod m
où X n est le ne nombre de la suite et le nombre précédent de la suite. Les sym boles a, b, et m dénotent des constantes : a est le m u lt ip li c a t e u r , b est l’ in c r é m e n t et m est le m o d u le . Le germe est la valeur initiale de Xq. Ce générateur a une période qui n’est pas plus grande que m. Si a, b e t m sont choisis correctement1, alors le générateur sera un g é n é r a t e u r d e p é r io d e m a x im a le , et aura une période m. Les détails concernant le choix des constantes qui garantit la période maximale peuvent être trouvés dans [864, 953] Une autre bonne publication sur les générateurs linéaires congruentiels et leur théorie est [1452]. Le tableau 16.1, emprunté à [1283], donne une liste des bonnes constantes pour des gé nérateurs linéaires congruentiels. Elles donnent toutes des générateurs à période maxi male et même, plus important encore, ces générateurs passent le test spectral de carac tère aléatoire pour les dimensions 2, 3, 4, 5 et 6 [390, 864]. Elles sont arrangées dans l’ordre croissant du plus grand produit qui ne donne pas de dépassement de capacité pour une longueur de mot donnée. L’avantage des générateurs linéaires congruentiels est qu’ils sont rapides, ne nécessitant que peu d ’opérations par bit. 1. Par exem ple, b et m doivent être premiers entre eux.
392
Chapitre 16
Tab
16.1
Générateurs de suites aléatoires et chiffrement en continu
Constantes pour générateurs linéaires congruentiels a
b
m
ÿiu
106
221 222 223
211
1283 1663 1663 2531 1399 1283 11213 2531 6173 3041 28411 6571 2957 2731 4621 29573 17117 6173 28411 18257 54773 24631 25673 24749 66037 25673 25367 45289 51749 49297 36979 25673 30809 29573 45289 150889 28411 51349 54773 49297 150889 374441 107839 66037 45989
6075 7875 7875 11979 6655 6075 53125 11979 29282 14406 134456 31104 14000 12960 21870 139968 81000 29282 134456 86436 259200 116640 121500 117128 312500 121500 120050 214326 244944 233280 175000 121500 145800 139968 214326 714025 134456 243000 259200 233280 714025 1771875 510300 312500 217728
Dépassement pour
224
225
226
227
421 430 936 1366 171 859 419 967 141 625 1541 1741 1291 205 421 1255 281 1093 421
1021 1021 228
229
230
23i
232 233 234 235
1277 741 2041 2311 1807 1597 1861 2661 4081 3661 3877 3613 1366 8121 4561 7141 9301 4096 2416 17221 36261 84589
16.1
393
Générateurs pseudo-aléatoires de suites
Malheureusement, les générateurs linéaires congruentiels ne peuvent pas être utilisés pour la cryptographie par chiffrement en continu, car ils sont prévisibles. Les géné rateurs linéaires congruentiels ont été cassés pour la première fois par Jim R e e d s [1305, 1306, 1307] et Joan B o y a r [702], Elle a aussi cassé les générateurs quadra tiques : X n — (a X + bX n - 1 + c) mod m et les générateurs cubiques : X n - (aX „ _ i 4 bX%_ 1 4 cX n - 1 4 d) mod m.
D’autres chercheurs ont étendu les travaux de B o y a r pour casser tout générateur œngruentiel polynomial [934, 899, 900]. Les générateurs linéaires congruentiels tron qués ont aussi été cassés [583, 706, 582], de même que les générateurs linéaires congruen tiels tronqués avec des paramètre inconnus [1505, 215], L ’évidence est faite que les générateurs congruentiels ne sont pas utiles pour la cryptographie. Toutefois, les générateurs linéaires congruentiels restent utiles pour des applications non cryptographiques, comme les simulations. Ils sont efficaces et ont de bons com portements statistiques par rapport aux tests empiriques les plus raisonnables. Vous trouverez pas mal d’information sur les générateurs linéaires congruentiels et leurs réalisations dans [953].
Combinaison de générateurs linéaires congruentiels Plusieurs personnes ont examiné la combinaison de générateurs linéaires congruentiels [1597, 952]. Leurs résultats ne sont pas plus sûrs cryptographiquement, mais ils ont des périodes plus longues etils passent mieux les tests de caractère aléatoire. Utilisez ce générateur sur les ordinateurs à motde 32 bits [532] : s t a t i c lo n g s i = 1
;
s t a t i c lo n g s2 = 1
;
/ * Un " l o n g " d o i t
# d e f i n e M O D M U L T (a,b ,c,m ,s) q = s / a ;
a v o ir 32 b i t s .
s = b * (s -a * q )
-
*/
c*q;
if
( s < 0 ) s+=m;
/ * M 0 D M U L T (a ,b ,c,m ,s) c a l c u l e s * b mod m, é t a n t d o n n é m =a*b+c e t 0 <= c < m. */ / * com binedLCG f o u r n i t u n e v a l e u r r é e l l e
* l ’ in te r v a lle
(0 ,1 ).
E lle
p s e u d o - a lé a t o ir e dans
co m b in e d e s g é n é r a t e u r s l i n é a i r e s
*
31
* c o n g r u e n t ie ls a vec d es p é r io d e s de 2
31 -8 5 e t 2
-2 4 9
* e t a une p é r i o d e é g a l e au p r o d u i t d e c e s d eu x * n om b res p r e m i e r s .
*/
d o u b l e com binedLCG ( v o i d )
t lo n g q ; lo n g z ; M0DMULT ( 5 3 6 6 8 , 4 0 0 1 4 ,
12211, 2147483563L, s i
M0DMULT ( 5 2 7 7 4 , 4 0 6 9 2 ,
3791,
z = si -
s2
;
2147483399L ,
)
s2 )
Chapitre 16
394 if
Générateurs de suites aléatoires et chiffrement en continu
( z < 1 ) z += 2 1 4 7 4 8 3 5 6 2 ;
r e t u r n z * 4 . 6 5 6 6 1 3 e - 10 ;
> /*
En g é n é r a l ,
v o i d in itL C G
il
f a u t a p p e l e r in itL C G a v a n t d ’ u t i l i s e r com binedL C G .
( lo n g I n i t S l ,
*/
lo n g I n itS 2 )
{ s i = I n itS l
;
s2 = In itS 2
;
> Ce générateur fonctionne tant que la machine peut représenter tous les entiers compris entre —231 -f 85 et 231 — 85. Les variables s i et s2 sont globales; elles maintiennent l’état courant du générateur. Avant le premier appel, elles doivent être initialisées. La variable s i doit avoir une valeur initiale entre 1 et 2147483562; la variable s2 doit avoir une valeur initiale entre 1 et 2147483398. Le générateur a une période d’environ 1018. Si vous n’avez qu’un ordinateur 16 bits, utilisez plutôt le générateur suivant : s ta tic
in t s i = 1
s ta t ic
in t s2 = 1
/ * Un " i n t " d o i t
a v o i r 16 b i t s .
*/
s t a t ic in t s3 = 1 # d e f i n e M 0 D M U L T (a ,b ,c,m ,s) q « s / a ; /*
s = b * (s -a * q )
-
c*q;
if
(s < 0 )
s+=m;
com binedLCG f o u r n i t u n e v a l e u r r é e l l e p s e u d o - a l é a t o i r e dams
* l ’ in te r v a lle
(0 ,1 ).
E lle
co m b in e d e s g é n é r a t e u r s l i n é a i r e s
*
15
* c o n g r u e n t ie ls a v ec d es p é r io d e s de 2
15 -4 0 5 ,
2
15 -1 0 4 1 ,
et 2
-1 1 1 1
* e t a u n e p é r i o d e é g a l e au p r o d u i t d e c e s t r o i s * n o m b re s p r e m i e r s . * / d o u b le com binedLCG ( v o i d ) in t q ; in t z
;
MODMULT
( 206,
157, 21,
32363,
MODMULT
( 217,
146, 4 5 ,
31727,
s2 )
MODMULT
( 222,
142, 133, 31657,
s3 )
z = si
s2
if
;
( z > 706 ) z -=
z += s 3 if
-
si )
3 2 3 62
;
;
( z < 1 ) z += 3 2 3 6 2
;
r e t u r n z * 3 .0 8 9 9 e -5
;
> / * En g é n é r a l ,
v o i d in itL C G
il
f a u t a p p e l e r in itL C G a v a n t d ’ u t i l i s e r com binedL C G . * /
( in t I n it S l,
in t In itS 2 ,
In itS 3
)
16.2
Registres à décalage à rétroaction linéaire
395
i
si = InitSl ; ë2 = InitS2 ; e 3 = InitS3 ; } Ce générateur fonctionne tant que la machine peut représenter tous les entiers entre —32 363 et 32 363. Les variables s i , s2 et s3 sont globales; elles maintiennent l’état courant du générateur. Avant le premier appel, elles doivent être initialisées. La variable si doit avoir une valeur initiale entre 1 et 32 362. La variable s2 doit avoir une valeur initiale entre 1 et 31762. La variable s3 doit avoir une valeur initiale entre 1 et 31656. Le générateur a une période de 1,6 x 1013. Pour ces deux générateurs, le terme constant b est nul.
16.2
Registres à décalage à rétroaction li néaire
Les séquences de registres à décalage s’utilisent à la fois en cryptographie et en théorie des codes. Il existe une théorie très riche à leur propos ; les algorithmes de chiffrement en continu basés sur des registres à décalage ont été le cheval de bataille des cryptographes militaires depuis les débuts de l’électronique. Un registre à décalage à rétroaction est composé de deux parties : un registre à décalage et une fonction de rétroaction (voir la figure 16.1). Le registre à décalage est une suite de bits. Chaque fois qu’un bit est nécessaire, tous les bits du registre à décalage sont décalés vers la droite de un bit. Le nouveau bit le plus à gauche est calculé en fonction des autres bits dans le registre. Le registre à décalage produit un bit en sortie, le moins significatif en général. La période d ’un registre à décalage est la longueur de séquence produite avant qu’elle ne commence à se répéter.
bn
r -------- -—
bn-l
ir
bt
b3
b2
bi
1r
r
ir
ir
Fonction de rétroaction
F i g . 16.1 - Registre à décalage à rétroaction
Les cryptographes ont rafolé des algorithmes de chiffrement faits de registre à décalage car ils sont faciles à réaliser en matériel. Je ne traiterai que la théorie mathématique. Ernst S e l m e r le responsable de la cryptographie pour le gouvernement norvégien a fondé la théorie des séquences de registre à décalge en 1965 [1416]. Solomon G o l o m b , un mathématicien de la NSA, a écrit un livre avec les résultats de S e l m e r et d ’autres qui lui sont propres [645]. Voir aussi [982, 981, 1649]. La forme la plus simple de registre à décalage est le registre à décalage à rétroac-
Chapitre 16
396
Générateurs de suites aléatoires et chiffrement en continu
tion linéaire, ou en abrégé R D R L 2 (voir la figure 16.2). La fonction de rétroaction est simplement la combinaison par ou exclusif de certains des bits du registre ; la liste de ces bits s’appelle une séquence de dérivation ou parfois une configuration de Fibonaeci. Comme la rétroaction est simple, une large partie des théories mathé matiques s’appliquent à l’analyse des R D R L . Les cryptographes aiment analyser les suites de bits pour se convaincre qu’elles sont assez aléatoires pour être utilisées en cryptographie.
F i g . 16.2 - Registre à décalage à rétroaction linéaire
La figure 16.3 représente un R D R L de 4 bits, dérivé au premier et au quatrième bit. Il est initialisé avec la valeur 1111, produira la suite d’états internes suivante avant de se répéter : 1 1 1 1 0 111 10 11 0 10
1
10 10 110 1 0 110 0 0 11 10 0 1
0 10 0 0 0 10 0 0 0 1
10 0 0 2. N ote du traducteur : en anglais, les registres à décalage à rétroaction linéaire sont appelés « h n ea r feed ba ck sh ift reg isters » et sont abrégés * L F S R ».
F ig . 16.3 - R D R L à 4 bits
16.2
Registres à décalage à rétroaction linéaire
397
110 0 1 1 1 0 La suite de sortie est la chaîne des bits les moins significatifs : 1 1 1 1 0 1 0 1 1 0 0 1 0 0 0 ___ Un R D R L à n bits est dans l’un de ses 2n —1 états. En théorie, il peut donc engendrer des suites pseudo-aléatoires de 2'n — 1 bits de long avant de se répéter3. Seul les R D R L avec certaines séquences de dérivation passeront par tous les 2" — 1 états internes ; ils sont appelés R D R L d e p é r io d e m axim ale. La suite de bits produite alors en sortie s’appelle une m -suite. Pour qu’un R D R L soit de période maximale, le polynôme formé par les éléments de la séquence de dérivation + 1 doit être un polynôme primitif modulo 2. Le d eg ré du polynôme est la longueur du registre à décalage. Un polynôme primitif de degré n est un polynôme irréductible qui divise x 2 _1 + 1 mais pas x d + 1 pour tout d qui divise 2n — 1 (voir § 11.3). Pour un aperçu plus mathématique consulter [645, 1651, 1650]. En général, il n’existe pas de moyen de générer des polynômes primitifs modulo 2 de degré donné. Le moyen le plus facile consiste à choisir un polynôme aléatoirement et à vérifier s’il est primitif. C ’est compliqué— à peu près autant que de vérifier qu’un nombre aléatoire est premier— mais il existe de nombreux logiciels mathématiques qui font cela. Quelques méthodes se trouvent dans [982, 981]. Le tableau 16.2 donne une liste de polynômes primitifs modulo 2 de différents degrés [1585, 645, 1651, 1650, 1283, 692]. Par exemple, l’entrée (3 2 ,7 ,5 ,3 ,2 ,1 ,0 ) indique que le polynôme suivant est primitif modulo 2 : x 32 + x 7 + x 5 + x 3 + x 2 + x + 1.
Il est aisé de transformer ceci en un R D R L de période maximale. Le premier nombre est le degré et la taille du R D R L , et le dernier nombre toujours 0, peut être ignoré. Tous les nombres, excepté le 0, spécifient la séquence de dérivation. Il faut compter à partir de la gauche du registre à décalage, c ’est à dire que les termes de faible degré correspondent à des bits de dérivation sur la gauche du registre. Pour continuer avec l’exemple, l’entrée (3 2 ,7 ,5 ,3 ,2 ,1 ,0 ) indique que, si vous prenez un registre à décalage de 32 bits et que vous engendrez le nouveau bit en combinant par ou exclusif les 32e , 7e , 5e , 3e , 2e et 1er bits ensemble (voir la figure 16.4), alors le RDRL aura une période maximale ; il parcourra les 232 —1 valeurs avant de se répéter.
Fig. 16.4 - R D R L à 32 b its d e p é r io d e m a x im a le 3. C ’ est 2” — t et non pas 2n parce q u ’un registre à décalage rem pli de 0 donnera un R D R L qui produit une suite infinie de 0, ce qui n ’est pas particulièrement utile.
398
Chapitre 16
Générateurs de suites aléatoires et chiffrement en continu
T ab. 16.2 - Quelques polynômes primitifs modulo 2 (1,0) (2,1,0) (3,1,0) (4,1,0) (5,2,0) (6,1,0) (7,1,0) (7,3,0) (8 ,4 ,3 ,2 ,0 ) (9,4,0) (10,3,0) (11,2,0) (1 2 ,6 ,4,1 ,0) (13 ,4,3 ,1 ,0 ) (1 4,5,3 ,1 ,0 ) (15,1,0) (1 6,5,3 ,2 ,0 ) (17,3,0) (17,5,0) (17,6,0) (18,7,0) (1 8 ,5 ,2 ,1 ,0 ) (1 9,5,2 ,1 ,0 ) (20,3,0) (21,2,0) (22,1,0) (23,5,0) (2 4,4,3 ,1 ,0 ) (25,3,0) (2 6 ,6 ,2 ,1 ,0 ) (2 7,5,2 ,1 ,0 ) (28,3,0) (29,2,0) (30,6 ,4,1 ,0) (31,3,0) (31,6,0) (31,7,0) (31,13,0) (112,11,6,4,0) (113,9,0) (113,15,0) (113,30,0) (114,11,2,1,0) (115,8,7,5,0)
(3 2 ,7 ,6 ,2 ,0 ) (33,13,0) (33,16,4,1,0) (3 4,8,4 ,3 ,0 ) (3 4 ,7 ,6 ,5 ,2 ,1 ,0 ) (35,2,0) (36,11,0) (3 6 ,6 ,5 ,4 ,2 ,1 ,0 ) (3 7 ,6 ,4 ,1 ,0 ) (3 7 ,5 ,4 ,3 ,2 ,1 ,0 ) (3 8,6,5 ,1 ,0 ) (39,4,0) (4 0 ,5 ,4 ,3 ,0 ) (41,3,0) (4 2,7,4 ,3 ,0 ) (4 2 ,5 ,4 ,3 ,2 ,1 ,0 ) (4 3,6,4 ,3 ,0 ) (44,6 ,5,2 ,0) (4 5 ,4 ,3,1 ,0) (46,8,7 ,6 ,0) (4 6 ,8 ,5 ,3 ,2 ,1 ,0 ) (47,5,0) (4 8 ,9 ,7,4 ,0) (4 8 ,7 ,5 ,4 ,2 ,1 ,0 ) (49,9,0) (4 9 ,6 ,5,4 ,0) (5 0 ,4 ,3,2 ,0) (5 1 ,6 ,3,1 ,0) (52,3,0) (53,6 ,2,1 ,0) (54,8 ,6,3 ,0) (5 4 ,6 ,5 ,4 ,3 ,2 ,0 ) (55,24,0) (55,6 ,2,1 ,0) (5 6,7 ,4 ,2 ,0 ) (57,7,0) (5 7 ,5 ,3,2 ,0) (58,19,0) (142,21,0) (143,5,3,2,0) (144,7,4,2,0) (145,52,0) (145,69,0) (146,5,3,2,0)
(5 8,6,5,1 ,0) (5 9 ,7 ,4 ,2 ,0 ) (5 9 ,6 ,5 ,4 ,3 ,1 ,0 ) (60,1,0) (6 1 ,5 ,2 ,1 ,0 ) (6 2,6,5,3 ,0) (63,1,0) (6 4,4,3,1 ,0) (65,18,0) (6 5,4,3,1 ,0) (6 6,9,8,6 ,0) (6 6 ,8 ,6 ,5 ,3 ,2 ,0 ) (6 7 ,5 ,2 ,1 ,0 ) (68,9,0) (6 8 ,7 ,5 ,1 ,0 ) (6 9,6,5,2 ,0) (7 0,5,3,1 ,0) (71,6,0) (7 1,5,3,1 ,0) (72,10,9,3,0) (7 2 ,6 ,4 ,3 ,2 ,1 ,0 ) (73,25,0) (7 3,4,3,2 ,0) (7 4,7,4,3 ,0) (7 5,6,3,1 ,0) (7 6,5,4,2 ,0) (7 7 ,6 ,5 ,2 ,0 ) (7 8,7,2,1 .0) (79,9,0) (7 9 ,4 ,3 ,2 ,0 ) (8 0,9,4,2 ,0) (8 0 ,7 ,5 ,3 ,2 ,1 ,0 ) (81,4,0) (8 2,9,6,4 ,0) (8 2 ,8 ,7 ,6 ,1 ,0 ) (8 3,7,4,2 ,0) (84,13,0) (8 4 ,8 , 7 , 5 ,3 ,1 ,0 ) (164,12,6,5,0) (165,9,8,3,0) (166,10,3,2,0) (167,6,0) (170,23,0) (172,2,0)
(8 5,8,2,1 ,0) (8 6,6,5,2 ,0) (87,13,0) (87,7,5,1 ,0) (88,11,9,8,0) (8 8 ,8 ,5 ,4 ,3 ,1 ,0 ) (89,38,0) (89,51,0) (89,6,5,3,0) (90,5,3,2 ,0) (91,8,5,1 ,0) (9 1 ,7 ,6 ,5 ,3 ,2 ,0 ) (92,6,5,2 ,0) (93,2,0) (94,21,0) (94,6,5,1 ,0) (95,11,0) (9 5 ,6 ,5 ,4 ,2 ,1 ,0 ) (96,10,9,6,0) (9 6 ,7 ,6 ,4 ,3 ,2 ,0 ) (97,6,0) (98,11,0) (9 8 ,7 ,4 ,3 ,1 ,0 ) (99,7,5,4 ,0) (100,37,0) (100,8,7,2,0) (101,7,6,1,0) (102,6,5,3,0) (103,9,0) (104,11,10,1,0) (105,16,0) (106,15,0) (107,9,7,4,0) (108,31,0) (109,5,4,2,0) (110,6,4,1,0) (111,10,0) (111,49,0) (236,5,0) (250,103,0) (255,52,0) (255,56,0) (255,82,0) (258,83,0)
16.2
399
Registres à décalage à rétroaction linéaire
T ab. 16.2 - Quelques polynômes primitifs modulo 2 (suite) (116,6,5,2,0) (117,5,2,1,0) (118,33,0) (119,45,0) (119,8,0) (120,9,6,2,0) (121,18,0) (122,6,2,1,0) (123,2,0) (124,37,0) (125,7,6,5,0) (126,7,4,2,0) (127,1,0) (127,7,0) (127,15,0) (127,30,0) (127,63,0) (128,7,2,1,0) (129,5,0) (130,3,0) (131,8,3,2,0) (132,29,0) (133,9,8,2,0) (134,57,0) (135,11,0) (135,16,0) (135,22,0) (136,8,3,2,0) (137,21,0) (138,8,7,1,0) (139,8,5,3,0) (140,29,0) (141,13,6,1,0)
(147,11,4,2,0) (148,27,0) (149,10,9,7,0) (150,53,0) (151,3,0) (151,9,0) (151,15,0) (151,31,0) (151,39,0) (151,43,0) (151,46,0) (151,51,0) (151,63,0) (151,66,0) (151,67,0) (151,70,0) (152,6,3,2,0) (153,1,0) (153,8,0) (154,9,5,1,0) (155,7,5,4,0) (156,9,5,3,0) (157,6,5,2,0) (158,8,6,5,0) (159,31,0) (159,34,0) (159,40,0) (160,5,3,2,0) (161,18,0) (161,39,0) (161,60,0) (162,8,7,4,0) (163,7,6,3,0)
(174,13,0) (175,6,0) (175,16,0) (175,18,0) (175,57,0) (177,8,0) (177,22,0) (177,88,0) (178,87,0) (183,56,0) (194,87,0) (198,65,0) (201,14,0) (201,17,0) (201,59,0) (201,79,0) (202,55,0) (207,43,0) (212,105,0) (218,11,0) (218,15,0) (218,71,0) (218,71,0) (218,83,0) (225,32,0) (225,74,0) (225,88,0) (225,97,0) (225,109,0) (231,26,0) (231,34,0) (234,31,0) (234,103,0)
(266,47,0) (270,133,0) (282,35,0)
^ (282,43,0) (286,69,0) (286,73,0) (294,61,0) (322,67,0) (333,2,0) (350,53,0) (366,29,0) (378,43,0) (378,107,0) (390,89,0) (462,73,0) (521,32,0) (521,48,0) (521,158,0) (521,168,0) (607,105,0) (607,147,0) (607,273,0) (1279,216,0) (1279,418,0) (2281,715,0) (2281,915,0) (2281,1029,0) (3217,67,0) (3217,576,0) (4423,271,0) (9689,84,0)
Le code en langage C pour ce R D R L est donné par : i n t RDRL ( )
{
s t a t i c u n s ig n e d l o n g S h i f t R e g i s t e r = 1 ; S h iftR e g is te r = ( (((S h ift R e g is t e r » ~ (S h iftR e g is te r » 6) (S h iftR e g is te r »
4)
“
(S h iftR e g is te r »
2)
'
( S h i f t R e g i s t e r >> 1 ) S h iftR e g is te r ))
& 0x00000001)
31)
/*
N’ im p o r t e q u o i s a u f 0 . * /
400
Chapitre 16
Générateurs de suites aléatoires et chiffrement en continu
« 31) I (S h iftR e g is te r »
1 );
re tu rn S h ift R e g is t e r & 0x00000001;
> Le code est légèrement plus compliqué quand la taille du registre à décalage est plus grande que la taille d ’un mot de l’ordinateur. Remarquez qu’ils ont tous un nombre impair de coefficients. J’en ai donné un si grand nombre parce que les R D R L sont souvent utilisés pour le chiffrement en continu, et je voulais qu’il y ait suffisamment d ’exemples différents pour que des personnes différentes choisissent des polynômes primitifs différents. Puisque si p(x) est primitif x” p ( l /x) l’est aussi, alors chaque entrée de la table représente en fait deux polynômes primitifs. Par exemple, si (a, 6,0) est primitif, alors (a, a — 6,0) est aussi primitif. Si (a, 6, c, d, 0) est primitif, alors (a, a — d, a — c, a — b, 0) est aussi primitif. Mathématiquement : si x a + x b + 1 est primitif, alors x a + x a~b + 1 l’est aussi, si x a + x b + xc + xd + 1 est primitif, alors xa + x a^d + x a~c + x a~b + 1 l’est aussi. Les trinômes primitifs donnent les réalisations logicielles les plus rapides car seuls deux bits du registre à décalage doivent être combinés par ou exclusif. En fait, les polynômes primitifs modulo 2 donnés dans le tableau 16.2 sont clairsem és, ce qui veut dire que la plupart de leur coefficients sont nuls. Les polynômes clairsemés sont toujours plus faibles cryptographiquement, parfois cela suffit pour casser l’algorithme. Il vaut mieux utiliser des polynômes primitifs modulo 2 denses (ceux qui ont beaucoup de coefficients non nuls) pour les applications cryptographiques. Si vous utilisez des polynômes denses, et à plus forte raison si vous les incluez dans la clef, vous pourrez manier des RDRL beaucoup plus petits. Il n’est pas facile de générer des polynômes primitifs modulo 2 denses. En général, pour générer des polynômes primitif de degré k, vous devez connaître la factorisation de 2k — 1. Trois bonnes références sur la génération de polynômes primitifs sont [653, 1296, 1297]. Les R D R L sont des générateurs de suites aléatoires par eux-mêmes mais ils ont des propriétés non aléatoires gênantes. Les suites de bits successifs sont linéaires, ce qui les rend tout sauf utiles pour la cryptographie. Pour un R D R L de taille n, l’état; interne est donné par les n bits précédents de sortie du générateur. Même si le schéma de rétroaction est inconnu, il ne faut que 2n bits consécutifs de la sortie pour le déterminer avec l’algorithme très efficace de Berlekamp-Massey [1086, 1087] (voir § 16.3). De grands nombres aléatoires engendrés à partir de bits successifs de telles suites sont fortement corrélés et, pour certains types d’applications, pas du tout aléatoires. Malgré cela, les R D R L sont souvent utilisés comme briques de base d’algorithmes de chiffrement.
Réalisations logicielles de RDRL Les réalisations logicielles de R D R L sont lentes mais elles sont plus rapides en langage machine. Une solution consiste à faire tourner 16 R D R L (ou 32 selon la taille des mots de votre ordinateur) en parallèle. Ce schéma utilise un tableau de mots dont la longueur
16.2
401
Registres à décalage à rétroaction linéaire
est celle du R D R L , et où chaque position de bit représente un R D R L différent. En supposant que tous les polynômes de rétroaction sont les mêmes, cela peut tourner assez vite. En général, le moyen le plus rapide de mettre à jour des registres à décalage est de multiplier l’état courant par des matrices binaires apropriées [901]. Il est aussi possible de modifier le schéma de rétroaction des R D R L . Le générateur résultant n’est pas meilleur cryptographiquement mais il est toutefois de période maxi male et il est plus facile à réaliser en logiciel [1283]. Au lieu d ’utiliser certains bits pour les combiner par ou exclusif pour former le bit le plus à gauche, certains bits sont combinés par ou exclusif avec la sortie du générateur puis remplacés par ce résultat et, ensuite, la sortie du générateur devient le bit le plus à gauche (voir la figure 16.5). Ceci est parfois appelé con fig u ra tion d e G alois.
-----►
b32
h?
b6 b5 b4 b3 h2 b{
/p A
Eîitde ortie 1
/p A /p A /p A
F ig . 16.5 - R D R L à 32 bits modifié En langage C, on a : # d e f i n e mask 0 x 8 0 0 0 0 0 5 7 s t a t i c u n s ig n e d l o n g S h i f t R e g i s t e r = l ; v o i d seed_RDRL ( u n s i g n e d l o n g s e e d )
f if
( s e e d == 0 ) / *
pou r é v it e r l a ca ta stro p h e * /
seed = 1; S h iftR e g is te r = seed ;
} i n t m od ifie d _ R D R L
(v o id )
f if
(S h ift R e g is t e r & 0x00000001) { S h i f t R e g i s t e r = ( ( S h i f t R e g i s t e r ~ m ask) » retu rn
> e ls e
1)
I 0x8000000;
1;
{
S h iftR e g is t e r » =
1;
retu rn 0;
> } L’avantage ici est que tous les ou exclusif peuvent être faits en une seule opération. Ceci peut aussi être parallélisé et les polynômes de rétroaction peuvent différer. Cette configuration de Galois peut aussi s’avérer plus rapide en réalisation matérielle, surtout dans des réalisation V LSI spécialement conçues. En général, si votre matériel est bon dans les décalages, utilisez une configuration de Fibonacci ; si vous pouvez exploiter le parallélisme, utiliser une configuration de Galois.
40 2
Chapitre 16
16.3
Conception et analyse d’algorithmes de chiffrement en continu
Générateurs de suites aléatoires et chiffrement en continu
La plupart des concptions pratiques d’algorithmes de chiffrement en continu tournent autour des R D R L . Dans les toutes premières années de l’électronique, ils étaient très facile à construire. Un registre à décalage n’est rien d’autre qu’un tableau de bits de mémoire et la rétroaction est juste une série de porte logiques. Même avec les circuits VLSI, un algorithme de chiffrement en continu basé sur un R D R L peut vous donner beaucoup de sécurité avec peu de portes logiques. Le problème des R D R L est que leur réalisations logicielles sont très lentes. Vous devez éviter les polynômes primitifs clairsemés, qui facilitent les attaques par corrélation, et les polynômes primitifs denses donnent des algorithmes inefficaces Tout algorithme de chiffrement en continu sort un bit à la fois ; vous devez le répéter 64 fois pour chiffrer autant que le DES en une itération. En fait, même un R D R L simple tel que le générateur à réduction qui sera décrit un peu plus loin, n’est pas plus rapide que le DES en réalisation logicielle. Cette branche de la cryptographie croît très rapidement et est très influencée politique ment. La plupart des conceptions sont secrètes ; la majorité des systèmes de chiffrement militaires utilisés aujourd’hui est basée sur les R D R L . De fait, la plupart des ordina teurs C r a y (Cray 1, Cray X-MP, Cray Y-M P) possèdent une instruction curieuse du nom de « comptage de la population ». Elle compte les 1 dans un registre et peut être utilisée à la fois pour calculer efficacement la distance de Hamming entre deux mots binaires et pour réaliser une version vectorielle d ’un R D R L . Certains la nomment l’instruction canonique de la NSA, elle est demandée sur presque tous les contrats d ’ordinateur D ’un autre côté, un nombre étonnamment grand de générateurs de codons à base de registres à décalage ont été cassés. Et il est pratiquement certain que les institutions militaire^çje cryptanalyse telle que la NSA en ont cassé beaucoup plus. Il est parfois surprenant de voir les mêmes idées simple revenir encore et encore.
Complexité linéaire Il est souvent plus facile d’analyser les algorithmes de chiffrement en continu que les algorithmes de chiffrement par blocs. Par exemple, une des mesures importantes dans l’analyse des générateurs à base de R D R L est la complexité linéaire. Elle est défi nie comme la taille n du plus petit R D R L qui peut simuler la sortie du générateur Toute suite de bits générée par une machine à nombre d’états fini sur un corps fini a une complexité linéaire finie [1022]. La complexité linéaire est importante parce qu’un algo rithme simple, l’algorithme de Berlekamp-Massey, permet de produire ce RDRL après avoir examiné seulement 2n bits de la suite de bits [1021]. Une fois que vous avez construit ce R D R L , vous avez cassé l’algorithme de chiffrement en continu qui utilise ce générateur. Cette idée a des extensions quand on considère des anneaux au lieu de corps [1309], et quand le flux de codons est vu comme une suite d ’éléments d ’un corps de caractéristique impaire [843]. Une amélioration plus poussée se trouve être la notion de profil de complexité linéaire, qui permet de mesurer la complexité linéaire du flux de codons au fur et à mesure qu’il augmente [1359, 1, 414, 1584]. Il existe un autre algorithme,
16.4-
Chiffrement en continu à base de R D R L
permettant de calculer la complexité linéaire, qui n’est utile que dans des circonstances très spéciales [599, 597, 598, 1347]. Une généralisation de la complexité linéaire est donnée dans [776]. Citons aussi la notion de sphère de complexité [500] et la complexité deux-adique [845]. Dans tous les cas, retenez qu’une complexité linéaire élevée n ’indique pas forcément que le générateur est sûr, mais qu’une complexité linéaire faible dénote un générateur non fiable [1359, 1259].
Immunité à l’attaque par corrélation Les cryptographes essaient d ’obtenir une complexité linéaire élevée en combinant plu sieurs flux de codons d’une manière non linéaire. Le danger ici est que l’un des flux interne— souvent la sortie d ’un certain R D R L — soit corrélé avec la sortie combinée et puisse être attaqué en utilisant l’algèbre linéaire. On appelle souvent cela l ’a t t a q u e p a r c o r r é la t io n ou encore l’attaque « diviser pour régner ». Thomas S lE G E N a montré comment définir précisément l’imunité à l’attaque par corrélation, et la nécessité de trouver un compromis entre l’immunité à l’attaque par corrélation et la complexité linéaire [1456]. L’idée de base derrière l’attaque par corrélation est d ’identifier une corrélation entre la sortie du générateur et la sortie d’un de ses morceaux internes. En observant alors le flux de codons en sortie, on peut obtenir des informations à propos de cette sortie interne. En utilisant cette information et d’autres corrélations, il reste à trouver assez d ’information sur les autres sorties internes pour pouvoir casser entièrement le générateur. Les attaques par corrélations et ses variantes telles que l’ attaque par corrélation rapide, qui offre un compromis entre la complexité de calcul et l’efficacité, ont permis de casser de nombreux générateurs de codons à base de R D R L [1457, 282, 1458, 573, 1638, 1059, 1096, 354, 635, 1062, 1095, 1005]. Quelques idées nouvelles intéressantes au milieu de tout cela se trouvent dans [47, 1643].
Autres attaques Il existe d ’autres attaques générales contre les générateurs de codons. Le t e s t d e c o n s is t e n c e lin é a ir e est une tentative d’identification d’une partie de la clef de chif frement en utilisant des techniques matricielles [1640]. Il y a aussi l ’a t t a q u e d e c o n s is te n ce p a r c o llis io n [40, 43]. L ’a lg o r it h m e d u s y n d r o m e lin é a ir e repose sur la pos sibilité d ’écrire un fragment du flux de sortie sous forme d ’équation linéaire [1638, 1639]. Il y l ’a t t a q u e d e la m e ille u r e a p p r o x im a t i o n a ffin e [500] et l ’a t t a q u e d e la s u it e d é r iv é e [42]. Même les techniques de la cryptanalyse différentielle ont été appliquées aux algorithmes de chiffrement en continu [499], ainsi que celles de la cryptanalyse linéaire [633].
16.4
Chiffrement en continu à base de RDRL
L’approche classique de la conception de générateurs de codons à base de R D R L est simple. Vous commencez par prendre un ou plusieurs R D R L généralement de
404
Chapitre 16
Générateurs de suites aléatoires et chiffrement en continu
longueurs différentes et avec des polynômes primitifs distincts4. La clef est l’état initial des R D R L . Chaque fois qu’un bit est nécessaire, décalez les R D R L d ’un cran (on parle parfois d ’im p u ls io n d ’ h o r lo g e ) . Le bit de sortie est une fonction de préférence non linéaire de certains des bits de sortie des R D R L . Cette fonction est appelée la f o n c t io n d e c o m b in a is o n et le générateur global est appelé un g é n é r a t e u r p a r c o m b i n a is o n 5. La plupart des considérations théoriques sur ce type d’objets sont l’œuvre de S e l m e r et Neal Z i e r l e r [1649]. Des complications ont pu être ajoutées. Certains générateurs ont des horloges de ca dences différentes ; la cadence d ’un générateur dépend parfois de la sortie d’un autre. Toutes ces idées de versions électroniques de machines à chiffrer d’avant guerre ont pour nom g é n é r a t e u r s à h o r lo g e c o n t r ô lé e [643]. Le contrôle d’horloge se fait par action simple si la sortie d ’un R D R L contrôle l’horloge d ’un autre, ou par rétroaction si la sortie d ’un R D R L contrôle sa propre horloge. Bien que ces générateurs soient au moins en théorie vulnérables aux attaques par plongement et corrélation probabiliste [636, 634], beaucoup sont sûr à l’heure qu’il est. On trouvera plus de théorie sur les registres à décalage à horloge contrôlée dans [97]. Ian C A S S E L L S , qui fut à la tête du département de mathématiques pures de Cambridge et qui est un ancien cryptanalyste de Bletchy Park, a dit que « la cryptographie est un mélange de mathématiques et de désordre, et que sans le désordre, les mathématiques peuvent être utilisées contre vous ». Ce qu’il voulait dire est que dans les algorithmes de chiffrement en continu, vous avez besoin d ’une structure mathématique telle que le R D R L pour guarantir une taille maximale et d ’autres propriétés, et ensuite de désordre compliqué et non linéaire pour empêcher autrui d ’obtenir le registre et de le résoudre. Ce conseille vaut aussi pour les algorithmes de chiffrement par blocs. Ce qui suit est un petit nombre de générateurs de codons à base de R D R L qui sont apparus dans la littérature. Je ne sais pas si aucun d ’eux n’a jamais servi dans un produit cryptographique réel. La plupart d’entre eux n ’ont d’intérêt que théorique. Certains ont été cassés, d’autres sont peut être toujours sûrs. Comme les algorithmes de chiffrement en continu sont généralement réalisés en maté riel, les symbole de logique électronique seront utilisé dans les figures. Dans le texte, © désigne le ou exclusif, A le et, V le ou, et -i la négation.
Générateur de G e f f e Ce générateur de codons utilise trois R D R L , combinés de façon non linéaire (voir la figure 16.6) [608]. Les sorties de deux des R D R L servent d ’entrées à un multiplexeur et le troisième R D R L contrôle la sortie du multiplexeur. Si Oi, a2 et a3 sont les sorties des trois R D R L , la sortie du générateur de G e f f e peut être décrite par la relation : b = (oi A a2) © ( ( -iUi) A a3).
Si les polynômes primitifs de rétroaction des trois R D R L ont respectivement des degrés m , n 2 et ris, alors la complexité linéaire du générateur est donnée par: (ni + l)n 2 + n i n 3. 4. Si to u te s les lon g u eu rs son t p rem ières e n tre elles et si les p o ly n ô m e ch oisis p o u r la r étroa ction son t to u s p rim itifs, ie g é n é ra te u r t o ta l e st d e p é rio d e m axim a le. 5. Si le b it de s o r tie n ’est fo n c t io n q u e d ’ un seu l g én éra teu r, o n p arle alors d e g énérateur par
filtre.
16.4
Chiffrement en continu à base de R D R L
405
La période de ce générateur est le plus petit commun multiple des périodes des trois générateurs. En faisant l’hypothèse que les degrés des trois polynômes primitifs de rétroaction sont premier entre eux, la période est égale au produit des périodes des trois R D R L .
a2(t)
Multiplexeur 2 pour 1
------------- ► 0
RDRL-2
Y -------- ► b(t) a3(t)
-------------- ►
RDRL-3
1 Sélection
afft) RDRL-1
F
ig
.
16.6 - Générateur de
G
effe
Bien que ce générateur ait bonne allure sur le papier, il est cryptographiquement faible et vulnérable à une attaque par corrélation [830, 1640]. Si vous passez par les pro babilités, vous constaterez que la sortie du générateur est égale à celle du R D R L -2 dans 75 % des cas. Si les séquences de dérivation sont connues, vous pouvez essayer de deviner la valeur initiale du R D R L -2 et générer le flux de sortie de ce générateur. Vous pouvez alors compter le nombre de fois où la sortie du R D R L est égale à celle du générateur. Si vous avez bien deviné les suites seront égales 75 % du temps, si vous vous êtes trompés, elle ne seront égales que 50 % du temps. De même qu’elle est égale à celle du R D R L -3 dans 75 % des cas. Avec de telles corrélations, le générateur de codons peut être cassé de manière relativement aisée. Par exemple, si les polynômes primitifs n’ont que trois termes chacun et que le polynôme de degré le plus élevé a un degré n, il ne faut alors qu’un segment de 37 x n codons de la suite de sortie pour reconstruire les états internes des trois R D R L [1641],
Générateur de Geffe généralisé Au lieu de choisir entre deux R D R L , on choisi dans ce schéma entre k R D R L où k est une puissance de 2. Il y a k + 1 R D R L au total (voir la figure 16.7). L’horloge du R D R L -1 doit avoir une cadence log2 k fois plus rapide que celles des autres R R L. Bien que ce schéma soit plus compliqué que le générateur de G e f f e , le même type d’attaque par corrélation est possible. Je ne recommande pas ce générateur.
Générateur de
J e n n in g s
Ce schéma utilise un multiplexeur pour combiner deux R D R L [778, 779, 780]. Pour chaque bit de sortie, le multiplexeur, contrôlé par R D R L -1 , choisit un bit de R D R L 2. U y aussi une fonction qui met en correspondance la sortie de R D R L -2 avec l’entrée du multiplexeur (voir la figure 16.8).
Chapitre 16
406
F
ig
.
Générateurs de suites aléatoires et chiffrement en continu
16.7 - Générateur de
G
effe
généralisé
♦ La clef est l’état initial des deux R D R L et la tonction de correspondance. Bien que ce générateur ait de très bonnes propriétés statistiques, il est tombé sous le coup de l’attaque de consistence par collision de Ross A n d e r s o n [40] et l’attaque de consitence linéaire [1640, 444]. N’utilisez pas ce générateur.
Générateur à signal d’arrêt Beth—Piper Ce générateur décrit par la figure 16.9 utilise la sortie d ’un R D R L pour contrôler l’horloge d ’un autre R D R L [158]. L’entrée d’horloge de R D R L -2 est contrôlée par la sortie de R D R L -1 , en sorte que R D R L -2 ne change d ’état au temps t que si la sortie de R D R L -1 était à 1 à l’instant t — 1. Personne n’a pu montrer de résultats à propos de la complexité linéaire de ce générateur
RDRL-1
f
G(t+io) ------ —► ü(t+i j )
H » _k------Sfft)
e
(J)
CD'
Multiplexeur
------------- ^ o
—--------a(t +i h_x)
+
Sk- \W
Kn
=>0
1
n- 1 b{t+n-1)
b(t) RDRL-2
F
ig
. 16.8 -
Générateur de
J e n n in g s
C(t)
16-4
Chiffrement en continu à base de R D R L
F i g . 16.9 - Générateur à signal d’arrêt de B e t h - P iper
dans le cas général. Cependant, il est susceptible d ’une attaque par corrélation [1641].
Générateur à signal d’arrêt alterné Ce générateur utilise trois R D R L de tailles différentes. R D R L -2 est cadencé quand la sortie de R D R L 1 est à 1 ; R D R L -3 est cadencé quand la sortie de R D R L -1 est à 0. La sortie du générateur est le ou exclusif de R D R L -2 et R D R L -3 (voir la figure 16.10) [674]. Ce générateur a une longue période et une grande complexité linéaire. Les auteurs ont trouvé une attaque par corrélations contre R D R L -1 , mais elle n’affaiblit pas substan tiellement le générateur. Il y a eu d ’autres essais de générateurs de codons dans cette voie [1542, 1576, 1484]
Générateur à signal d’arrêt bilatéral Ce générateur utilise deux R D R L , tous deux de taille i (voir la figure 16.11) [1640]. La sortie du générateur est le ou exclusif des sorties de chacun des R D R L . Si la sortie
F
ig
. 1 6 .1 0 -
Générateur à signal d’arrêt alterné
408
Chapitre 16
Générateurs de suites aléatoires et chiffrement en continu
de R D R L -1 au temps t — 1 est 0 et que la sortie au temps t — 2 est 1, alors R D R L -2 ne change pas d ’état au temps t. Inversement, si la sortie de R D R L -2 au temps t — 1 est 0 et la sortie au temps t —2 est 1, et si R D R L -2 a changé d ’état au temps t, alors R D R L -1 ne change pas d ’état au temps t.
F i g . 16.11 - Générateur à signal d’arrêt bilatéral
La complexité linéaire de ce système est approximativement égale à la période. D’après [1640], « aucune redondance de codons évidente n’a été constatée dans ce système ».
Générateur à seuil Ce générateur essaie de pallier les défauts de sécurité des générateurs précédents en utilisant un nombre variable de R D R L [281]. La théorie veut que si vous utilisez un grand nombre de R D R L , il est plus difficile de casser le chiffre. Ce générateur est illustré par la figure 16.12. Prenez la sortie d ’un grand nombre de R D R L (prenez-en un nombre impair). Assurez-vous que les tailles de tous ces R D R L soient premières entre elles et que tous les polynômes de rétroaction soient primitifs — pour maximiser la période. Si plus de la moitié des bits de sortie sont à 1, alors la sortie du générateur est à 1. Si plus de la moitié des bits sont à 0, alors la sortie du générateur est à 0. Avec trois R D R L , la sortie du générateur peut être décrite par : b = (ai A o2) ® (ai A 0 3 ) © (a 2 A a3). C ’est très sim ilaire à un générateur d e G e f f e , ex ce p té q u ’il y a une com p lexité linéaire plus grande :
nin 2 + nl n3 + n 2 n3
où ni, n2 et n3 sont les tailles respectives des premier, second et troisième R D R L . Ce générateur n’est pas extraordinaire. Chaque bit de sortie du générateur donne un peu d ’information sur l’état des R D R L , 0,189 bit pour être exact, et le tout tombe sous le coup d ’une attaque par corrélation. Je ne conseille pas de l’utiliser.
16-4
Chiffrement en continu à base de
409
RDRL
F i g . 16.12 - Générateur à seuil
Générateurs auto-cadencés Les générateurs auto-cadencés sont des générateurs qui contrôlent leur propre horloge. Deux propositions ont été faites, l’une par R u e p p e l (voir la figure 16.13) [1361] et l’autre par C h a m b e r s et G o l l m a n n [313] (voir la figure 16.14). Dans le générateur de R u e p p e l , quand la sortie du R D R L est à 0, le R D R L est cadencé d fois. Quand la sortie du R D R L est à 1, le R D R L est cadencé k fois. Le générateur de C h a m b e r s et G o l l m a n n est plus compliqué mais l’idée est la même. Malheureusement, ces deux générateurs ne sont pas sûrs [1641], malgrés des modifications qui pourraient corriger les problèmes [1364].
F ig . 16.13 - Générateur auto-cadencé de R u e p p e l
F i g . 1 6 .1 4 -
Générateur auto-cadencé de
C hàm bers
et
G
ollm ann
4 10
Chapitre 16
Générateurs de suites aléatoires et chiffrement en continu
Générateur multivitesse à produit scalaire Ce générateur, conçu par M a s s e y et R u e p p e l [1020], utilise deux R D R L cadencés à deux vitesses différentes (voir la figure 16.15). R D R L -2 est cadencé d fois plus vite que R D R L -1 . Puis les bits individuels des deux R D R L sont combinés entre eux par et logique et ensuite combinés par ou exclusif les uns avec les autres pour produire le bit de sortie du générateur.
F
ig
. 1 6 .1 5
- Générateur multivitesse à produit scalaire
Bien que la complexité linéaire soit élevée et que ce générateur possède d’excellentes propriétés statistiques, il tombe encore sous le coup d ’une attaque de consistence li néaire [1641]. Si ni est la longueur de R D R L —1, n2 est la longueur de R D R L -2 , et d est le quotient de vitesse entre les deux, alors l’état interne du générateur peut être reconstruit à partir d ’une suite de bits de sortie de longueur : n\ + n2 + log2 d.
Générateur sommatoire Fruit des travaux Rainer R u e p p e l , ce générateur combine la sortie de deux R D R L dans un additionneur avec retenue [1360, 1359]. Cette opération est fortement non linéaire et, jusqu’à la fin des années 80, ce générateur était ce qui se faisait de mieux en matière de sécurité, mais il est tombé sous le coup de l’attaque par corrélation [1061, 1062, 1097]. De plus, il a été prouvé que c ’est un cas de registre à décalage à rétroaction avec retenue (voir § 17.4) qui peut être cassé [845].
Générateur dynamique Le nom complet est générateur dynamique de suites aléatoires6 [1123]. L’idée est d’avoir deux générateurs par filtre, à seuil, sommatoires, ou autres, alimentés par un ensemble de R D R L et contrôlé par un autre R D R L . 6- On note en abrégé D N R S G pou r « d yn arm c ra n d o m -s eq u e n c e g e n e r a to r ».
16. f
Chiffrement en continu à base de R D R L
411
Opérer d’abord les R D R L . Si la sortie du R D R L —0 est 1 alors calculer la sortie du premier générateur par filtre, si c’est 0, alors calculer la sortie du second générateur par filtre. La sortie finale est la combinaison par ou exclusif des différentes sorties.
Cascade de G o l l m a n n La cascade de G o l l m a n n (voir la figure 16.16) décrite dans [638, 314] est une version renforcée du générateur à signal d’arrêt. Il consiste en une série de R D R L dont l’horloge est contrôlée par le R D R L précédent. Si la sortie de R D R L -1 est 1 à l’instant t — 1, alors R D R L -2 change d ’état. Si la sortie de R D R L —2 est 1 à l’instant t — 1, alors R D R L -3 change d’état, et ainsi de suite. La sortie du R D R L final est la sortie du générateur. Si tous les R D R L ont la même taille, n, la complexité linéaire d’un système de k R D R L est : n(2” — l ) fc—1.
F ig .
16.16 - Cascade de
G ollm ann
Les cascades sont une bonne idée : leur conception est très simple, et elle permettent de générer des suites avec des périodes énormes, des complexités linéaires énormes, et de bonnes propriétés statistiques. Elles sont vulnérables à une attaque appelée v é r r o u illa g e [642], C ’est une technique dans laquelle le cryptanalyste reconstruit l’entrée du dernier registre à décalage de la cascade, puis remonte la cascade registre par re gistre. Cela pose un problème sérieux dans certaines situations en réduisant la longueur effective de la clef de l’algorithme, mais il possible de prendre certaines précautions pour minimiser l’attaque. Des analyses plus poussées ont montré que la suite se rapproche de l’aléatoire quand k grandit [639, 640, 644, 641], Sur la base d ’attaques récentes sur les cascades de G o l l m a n n courtes, je recommande de prendre k supérieur à 15. Vous feriez mieux d’utiliser plus de R D R L de petite taille plutôt que peu de grande taille.
Générateur à réduction Le générateur à réduction [382] repose sur une forme différente de contrôle d ’horloge que celle des générateurs précédents. Prenez deux R D R L , R D R L —1 et R D R L —2. Opérez un cycle d ’horloge sur chacun d ’eux. Si la sortie du R D R L -1 est 1, alors la sortie du générateur est celle du R D R L -2 . Dans le cas contraire, annulez les deux bits, opérez un cycle d ’horloge sur chacun des R D R L , et essayez à nouveau. Cette idée est simple, raisonnablement efficace et semble sûre. Si les polynômes primitif sont clairsemés, le générateur est vulnérable, mais aucun autre problème n’a été décelé.
412
Chapitre 16
Générateurs de suites aléatoires et chiffrement en continu
Même ainsi, c’est récent. Un problème de réalisation vient du fait que la cadence de sortie n’est par régulière ; si le R D R L -1 sort beaucoup de zéros à la suite, le générateur ne sort aucun bit Les auteurs suggèrent d’utiliser une mémoire tampon pour résoudre cela [382] Une réalisation pratique du générateur à réduction est présentée dans [901].
Générateur à auto-réduction Le générateur à réduction [1058] est une variante du générateur à réduction. Au lieu d’utiliser deux R D R L , considérez une paire de bits provenant d ’un seul R D R L . Opérez deux cycle d ’horloge sur un R D R L . Si le premier bit de la paire est 1, la sortie est le second bit. Si le premier bit est 0, jetez les deux bits et recommencez. Si le généra teur à auto-réduction utilise environ deux fois moins de mémoire que le générateur à réduction, il est aussi deux fois moins rapide Si le générateur à auto-réduction semble aussi sûr, il présente encore des comportements inexpliqués et des propriétés inconnues. C ’est un générateur tout nouveau ; consacrez-y du temps.
16.5
A5
L’algorithme de chiffrement en continu A5 sert à chiffrer les messages en téléphonie GSM (dont le nom vient de « Group Spécial Mobile »). C ’est le standard non améri cain pour les téléphones cellulaires numériques. L’algorithme est utilisé pour chiffrer la communication entre le mobile et la borne reliée au réseau. Le reste de la commu nication n’est, pas chiffrée ; la compagnie téléphonique peut facilement espionner vos conversations. Beaucoup d’affaires politiques étranges entourent ce projet. A l’origine, on pensait qu’insérer de la cryptographie en téléphonie G SM nuierait à son exportation dans certains pays. Maintenant, certains rapports offciels mettent en cause A5, impliquant qu’il est si faible que cela peut nuire aux ventes à l’exportation. La rumeur dit que plusieurs services de renseignements de l’OTAN se sont disputés au milieu des années 1980 pour savoir si le chiffrement de GSM devait être solide ou faible. Les allemands voulaient un chiffrement solide commme ils se trouvaient à côté de l’Union Soviétique. Les autres pays ont pris le dessus, et A 5 est de conception française. Nous connaissons la plupart des détails. Une compagnie téléphonique britanique a fournit toute la documentation à l’Université de Bradford en omettant de leur faire signer un contrat de non divulgation. Il y eu des fuites ça et là, et l’algorithme aurait même été posté sur In t e r n e t . Un article décrit A5 [1624], et le code source se trouve à la fin de ce livre. A5 est constitué de trois R D R L , de tailles de registres 19, 22 et 23 ; tous les polynômes primitifs utilisés pour les rétroactions sont clairsemés. Chaque registre est cadencé en fontion de son propre bit du milieu, combiné par ou exclusif avec l’inverse de la fonction de seuil des bits du milieu des trois registres. Habituellement, deux des R D R L opèrent un cycle d’horloge à chaque ronde. Il existe une attaque évidente nécessitant 240 chiffrements : deviner le contenu des deux premiers R D R L et essayez alors de déterminer le troisième R D R L d ’après le flux de codons. (La faisabilité de cette attaque est encore sujette à débats, mais une machine
16.6
413
H ugues X P D / K P D
à rechercher les clefs, actuellement en cours de conception, devrait bientôt clore la discussion [46].) Néanmoins, il apparaît que les idées fondamentales de A 5 sont bonnes. Il est très efficace. Il réussit tous les tests statistiques connus; sa seule faiblesse connue est la taille de ses registres qui sont assez petits pour permettre la recherche exhaustive. Des variantes de A 5 avec des registres à décalage plus longs et des polynômes primitifs plus denses devraient être sûres.
16.6 H u g u e s X P D /K P D Cet algorithme vous est donné par H u g u e s A i r c r a f t C o r p . Il a été incorporé dans des radios tactiques de l’armée et dans des équipements d’orientation vendus à des militaires étrangers. Il fut conçu en 1986 et nommé X P D pour « Exportable Protection Device » qui veut dire appareil de protection exportable. Plus tard, il ne fut plus classé secret et fut rebaptisé K P D pour « Kinetic Protection Device » qui veut dire appareil de protection dynamique [1045, 1044], L’algorithme utilise un R D R L à 61 bits. Il y a 210 polynômes primitifs distincts qui ont été approuvés par la NSA. La clef sélectionne un de ces polynômes (qui sont stockés quelque part en mémoire morte), ainsi que l’état initial du R D R L . Il a huit filtres non linéaires différents, chacun d’eux produit un bit à partir de six dérivations provenant du R D R L . Les bits sont combinés pour générer un octet qui sert à chiffrer ou à déchiffrer le flot de données. Cet algorithme a l’air assez impressionnant, mais je doute qu’il le soit vraiment. La NSA l’autorise à l’exportation, il doit donc exister une attaque avec un nombre d ’opé rations de l’ordre de 240 ou moins. Quelle est-elle?
16.7
Nanoteq
N a n o t e q est une société sud africaine en électronique. Ceci est leur algorithme qui a été adopté par la police sud africaine pour chiffrer leur communications par fax, et certainement pour d’autres utilisations aussi. L’algorithme est plus ou moins décrit dans [903, 904]. Il utilise un R D R L à 127 bits avec un polynôme primitif de rétroaction fixé ; la clef est l’état initial du registre. Les 127 bits du registre sont réduits à un flux de codons au moyen de 25 cellules primitives. Chaque cellule a cinq entrées et une sortie :
f(xi,X 2 ,X3 ,X4 ,X5) =
X\
+
X2 + ( Xi +
X 3) ( x 2
+ X4 + X5) +
+
X4 )(x2 + X3) +
X5
Chaque entrée de la fonction est combinée par ou exclusif avec certains bits de la clef. Il y a aussi une permutation secrète qui dépend de la réalisation, et qui n’est pas détaillée dans l’article. On ne peut se procurer cet algorithme qu’en réalisation matérielle. Est-ce que cet algorithme est sûr? J’en doute. Durant le passage à la démocratie, certains faxs embarassants d ’une station de police à une autre sont parfois apparus dans les journaux libéraux. Cela pourrait très bien être le résultat des efforts des services de rensignement américains, britaniques, ou soviétiques. Ross A n d e r s o n a fait les premiers pas vers la cryptanalyse de cet algorithme dans [47] ; j ’espère voir davantage de résultats arriver bientôt.
4U
Chapitre 16
Générateurs de suites aléatoires et chiffrement en continu
16.8
Rambutan
a m b u t a n est un algorithme britanique conçu par le « Communication Electronics Security Group », soit groupe de sécurité en électronique et en communication. Il n’est
R
vendu que sous forme de module matériel et il est approuvé pour la protection de document classés jusqu’à « confidentiels ». L’algorithme lui-mème est classé secret, et la puce n’est générallement pas disponible dans le commerce. R a m b u t a n a une clef de 112 bits (sans compter les bits de parité) et peut opérer dans trois modes : E C B , C B C , et C FB à huit bits. Cela sous-entend fortement que c ’est un algorithme par blocs, mais les rumeurs ne vont pas dans ce sens. Il est supposé être un algorithme de chiffrement en continu à base de R D R L. Il aurait cinq registres à décalage, chacun d’une taille de 80 bits environ. Les polynômes de rétroaction seraient plutôt clairsemés, avec à peu près 10 dérivations chacun. Chaque registre fournirait quatre entrées à une fonction linéaire très grande et très compliquée qui sortirait un bit à la fois. D ’où vient le nom ? C ’est peut-être du fruit7 qui est épineux et repoussant à l’extérieur et doux et moelleux à l’intérieur. D ’un autre côté, ce n’est peut-être pas la raison.
16.9
Générateurs additifs
Les g é n é r a t e u r s a d d it if s (appelés parfois générateurs de Fibonacci) sontextrême ment efficaces car ils produisent des mots aléatoiresau lieu de bitsaléatoires [864]. A eux seuls, ils ne sont pas sûrs, mais ils peuvent être utilisés comme élément de base de générateurs sûrs. L ’état initial du générateur est un tableau de mots de n bits (mots de 8, 16 ou 32 bits, ou autre) : X i , X ï , ■- ■, X m. Cet état initial est la clef. Le ie mot produit par le générateur est donné par : X t — ( X l—a + X l-b + X t-.c + ••■+ X t—k) modulo 2"
Si les coefficients a,b,c, . . . ,k sont bien choisis, la période de ce générateur est au moins 2n — 1. Une condition nécessaire sur les coefficients est que l’on obtienne un R D R L de longueur maximale lorsqu’on ne considère que les bits de poids faible. Par exemple, (55,24,0) est un polynôme primitif d’après le tableau 16.2. Cela implique que le générateur additif suivant est de longueur maximale : X t = (X j _ 5 5 + X , - 24) modulo 2"
Cela fonctionne dans ce cas parce que le polynome a trois coefficients non nuls. S’il en a plus, d ’autres conditions sont requises pour obtenir un générateur de longueur maximale. Consulter [254] pour les détails.
Fish F ish est un générateur a d d itif basé sur des techniques utilisées dans le générateur à réd u ction [197]. Il p rod u it un flux d e m ots d e 32 b its qui peu t être com bin é par ou 7. N ote du traducteur : le ram boutan en français.
16.9
Générateurs additifs
415
exclusif avec un flux de texte en clair pour produire le texte chiffré, ou avec le flux de texte chiffré pour produire le texte en clair. Lenom vient de « Fibonacci shrinking generator » qui veut dire générateur à réduction de Fibonacci. Commencez par prendre deux générateurs additifs. La clef est constituée des états initiaux de ces générateurs. A z — { A i - 55 + A i Bi =
24) modulo 2 32 52 + -B j-ig) modulo 2 32
Ces suites sont réduites, par paires, selon le bit de poids faible de Bi : s’il vaut 1 , utilisez la paire, s’il vaut 0 ignorez la paire. Notons par Cj la suite des mots de A t utilisés et par Dj la suite des mots de B , utilisés. Ces mots servent par couples, 6 2 , et C 2j + \, I)2j et D 2} f 1 pour former des couples de mots de 32 bits K 2j et K 2]+i en sortie. E 2, = C 2j © (D 2j A D 2j + i ) F2j — D 2j + i © (E2j A C 2j+ 1 ) K 2j = E2j © F2j K 2j+ i = G2j+ i © F2j
Cet algorithme est rapide. Sur un 486 à 33 MHz, une réalisation de Fish en C permet de chiffrer 15 megaoctets de données par seconde. Malheureusement, il n’est pas sûr ; une attaque demande un travail de 2 40 opérations environ [46].
Pike P lK E est une version épurée de F i s h nous venant de Ross A n d e r s o n qui est celui qui
a cassé F ish [46]. Il comprend trois générateurs additifs, ceux-ci par exemple:
= ( Aj _ 5 5 + 2 4 ) modulo 232 (H ,__57 + B i - 7 ) modulo 232 C i = { C i - 58 + C i_ 19) modulo 232
Ai
Bi =
Pour générer le flux de codons, considérez les bits de retenue des trois additions. S’ils sont tous les trois égaux (tous des 0, ou tous des 1), opérez un cycle d’horloge sur les trois générateurs. Si ce n’est pas le cas, n’opérez un cycle d’horloge que sur les deux générateurs dont les bits de retenue sont égaux. Mémorisez le bit de retenue du troisième générateur pour la fois suivante La sortie finale est la combinaison par ou exclusif des sorties des trois générateurs. PlKE est plus rapide que FlSH puisqu’il faut en moyenne 2,75 étapes par sortie au lieu de 3. Il est beaucoup trop récent pour inspirer confiance, mais il fait bonne figure jusqu’ à présent.
Mush Mush est un générateur à réduction mutuelle. C ’est facile à expliquer [1592], Prenez deux générateurs additifs A et B . Si le bit de retenue de A est à 1, opérez un cycle d’horloge sur B . Si le bit de retenue de B est à 1, opérez un cycle d ’horloge sur A .
Chapitre 16
416
Générateurs de suites aléatoires et chiffrement en continu
Opérez un cycle d ’horloge sur A et B et retenez les bits de retenue pour la fois suivante. La sortie finale est la combinaison par ou exclusif des sorties de A et B. Les générateurs les plus faciles à utiliser sont ceux de F i s h : A t = (.4,-55 + A t_ 2 4 ) modulo 232 B , = (£?,_52 + B, _19) modulo 232
En moyenne, il faut trois itérations de générateur pour obtenir un mot en sortie. Si les coefficients des générateurs additifs sont correctement choisis et sont premiers entre eux, la suite de sortie aura une période maximale. Je ne connais aucune attaque ayant réussi, mais sachez que cet algorithme est très récent.
16.10
Gifford
Dabid G i f f o r d a inventé un algorithme de chiffrement en continu et l’a utilisé pour chiffrer des dépêches par câble dans la région de Boston de 1984 jusqu’à 1988 [610, 609, 611]. L’algorithme a un seul registre de 8 octets : B\,B 2 , ■■■,B-j. La clef est l’état initial du registre. L ’algorithme fonction en mode O F B ; le texte en clair n ’affecte pas du tout l’algorithme. (Voir la figure 16.17).
F
ig
.
16.17 -
G
if f o r d
Pour générer un codon c,, joignez B 0 et i?2, joignez B 4 et B7 - Multipliez les deux ensemble pour obtenir un nombre de 32 bits. Le troisième en partant de la gauche est c,. Pour mettre à jour le registre, décalez les bits de B t vers la droite de 1 bit en laissant une copie du bit le plus à gauche en place. Décalez les bits de B 7 vers la gauche de 1
16.11
417
A lg o r ith m e M
en mettant le bit le plus à droite à 0. Combinez par ou exclusif B\ et B 7 ainsi modifiés et B(j. Décaler le registre, dans son état initial, de un octet vers la droite et placez cet octet en première position à gauche. Cet algorithme est resté sûr dînant la durée de son utilisation, mais il fut cassé en 1994 [291]. Il se trouve que le polynôme de rétraction n’est pas primitif et peut-être attaqué de cette manière.
16.11
Algorithme M
Le nom est du à K n u t h [864]. Il s’agit d’une méthode pour combiner deux flux pseudo aléatoires de manière à augmenter leur sécurité. La sortie d’un des générateurs sert à sélectionner une sortie retardée de l’autre de générateur [1006, 1012]. Cela se traduit en C par : # d e f in e TAILLE_TAB (8 1 9 2 ) / * p a r e x e m p le - p l u s c ’ e s t g r a n d , m ieu x c a v a u t * / s t a t i c u n s ig n e d c h a r d e l a y l TAILLE_TAB ] u n s ig n e d c h a r p r n g A ( v o i d ) lo n g p r n g B ( v o i d
)
;
;
;
v o id i n i t _ a l g M ( v o i d
)
I lon g i ; fo r
( i= 0
; i < TAILLE_TAB ; i+ + )
d e la y li]
}
= prngA C )
;
/ * in it_a lgM * /
u n s ig n e d c h a r a l g lM ( v o i d
)
1 lo n g j , v j
;
= prngB O
v = d e la y lj] d e la y lj] retu rn
% TAILLE_TAB ; ;
/*
= prngA O
( v )
/*
o b t e n t i o n l ’ in d e x d a n s d e l a y l ]
o b t e n t io n de l a ;
/* le
*/
v a l e u r a r e n v o y e r */
r e m p la c e r * /
;
} / * a lg lM * /
Ceci est solide dans le sens que si prngA était vraiment aléatoire, on ne pourrait rien apprendre de prngB (et il serait impossible de le cryptanalyser). Il serait possible de cryptanalyser prgnA seulement si sa sortie était accessible dans le bon ordre, (c’est à dire si prngB était d ’abord cryptanalysé), et dans le cas contraire, s’il était vraiment aléatoire, la combinaison serait sûre.
16.12
PKZIP
Roger S C H L A F L Y a conçu l’algorithme de chiffrement intégré dans le programme de compression P K Z IP . C ’est un algorithme de chiffrement en continu qui chiffre les
Chapitre 16
418
Générateurs de suites aléatuires et chiffrement en continu
données octet par octet. Ceci est au moins l’algorithme de la version 2.04g. Je ne peux pas me prononcer pour les version ultérieures, mais à moins que cela ne soit annoncé, vous pouvez supposer qu’elles l’utilisent aussi. L’algorithme utilise des variables de 32 bit initialisées ainsi : K 0 = 305419896 K 2 = 591751049 K 2 = 878082192
Il y a une clef K 3 déduite de K 2. Voici l’algorithme (tous les symboles viennent du C) : Cx = M i ~ K 3
K0 K\ Ki K2 K3
= ct c32(Ko, Mi )
= Ki + (A'o&OxOOOOOOFF) = Ki * 134775813 + 1 = ct c3 2 {K2, K 1 » 24) = ((K 2 12) * {{K 2 12)-1)> » 8
La fonction crc32 prend la valeur précédente et un octet, les combine par ou exclusif et calcule la valeur suivante au moyen du polynôme C R C noté 0xEDB88320. En partique, on peut pré-calculer un tableau T de 256 nombres et le calcul par crc32 devient : crc32(a,6) — (a > > 8)~T[(n& OxFF © 6] Le tableau est pré-calculé selon la définition originelle de crc3 2 : T[i] = crc32(i,0) Pour chiffrer un flux de texte en clair, commencez faire passez les octets de la clef dans l’algorithme pour mettre à jour les clefs. Ignorez le texte chiffré correspondant. Chiffrez alors le texte en clair octet par octet. Douze octets aléatoires sont acollés au début du texte en clair, mais cela n’est pas vraiment important. Le déchiffrement se fait de manière similaire au chiffrement, mis à part qu’il faut prendre Ci à la place de M i à la deuxième étape de l’algorithme.
Sécurité de PKZIP Malheureusement, elle n ’est pas extraordinaire. Une attaque a besoin de 40 à 200 octets de texte en clair connu et prend environ 227 opérations [173]. Vous pouvez la faire en quelques heures avec votre ordinateur personnel. Si le fichier compressé possède une entête standard, ce n’est pas un problème d’obtenir le texte en clair. N’utilisez pas le chiffrement intégré dans P K Z IP .
Chapitre 17
Autres algorithmes de chiffrement en continu et générateurs de suites vraiment aléatoires 17.1
RC4
RC4 est un algorithme de chiffrement en continu à clef de longueur variable développé en 1987 par Ron R i v e s t pour R S A D a t a S e c u r i t y , In c. Il a été durant sept ans une marque déposée, et les détails de l’algorithme n’étaient dévoilés qu’après signature d’un contrat de non divulgation. En septembre 1994, quelqu’un a envoyé anonymement le code source aux abonnés de la liste de courrier électronique « Cypherpunks ». Il s’est rapidement répandu tout autour du monde via les sites ftp d ’iN T E R N E T . Des possesseurs de copies légales de RC4 ont confirmé la compatiblité. R SA D a t a S e c u r i t y , I n c . essaya d ’étouffer l’affaire en prétendant qu’il s’agissait d’un secret de fabrication bien qu’étant devenu public ; c’était trop tard. Il a depuis été disséqué et commenté, distribué à des conférences et enseigné dans les cours de cryptographie. RC4 est simple à décrire. L ’algorithme fonctionne en mode O FB : le flux de codons ne dépend pas du texte en clair. Il a une table- S à 8*8 bits: S o , S i , . . . ,S 25 5 - Les Si forment une permutation des nombres entre 0 et 255, et la permutation dépend de la clef de longueur variable. Il y a deux compteurs i et j , initialisés à zéro. Pour générer un octet aléatoire, procéder ainsi : i = (i + 1) modulo 256 j — (j + Si) modulo 256
Echanger Si et S j . t = (S i + S j ) modulo 256 K = St
420
Chapitre 17
Autres algorithmes de chiffrement en continu
L ’octet K est combiné par ou exclusif avec le texte en clair pour produire le texte chiffré ou bien avec le texte chiffré pour produire le texte en clair. Le chiffrement est rapide, environ 10 fois plus que le DES. L’initialisation est facile aussi. Commencez avec l’identité : Sa — 0,S\ = 1 ,... ,6 2 5 5 = 255. Remplissez un autre tableau de 256 octets avec la clef, en répétant celle-ci suffi samment de fois pour combler le tableau : Kq,K\, . . . , K 2ss- Initialisez l’index j à zéro et effectuez ceci : Pour i variant de 0 à 255, effectuer : j — (j + St + K r) modulo 256 Echanger Si et S3.
R SA D SI prétend que l’algorithme est immune aux cryptanalyse différentielle et li néaire, qu’il n’a pas de cycle court, et qu’il est hautement non linéaire1. La table-S évolue lentement au cours de l’algorithme: i permet d’assurer que chaque élément change et j permet assurer que les éléments changent aléatoirement. L’algorithme est si simple que la plupart des programmeurs peuvent rapidement écrire le code de mé moire. Il devrait être possible de généraliser cette idée à des tables-S 1 et à des mots de tailles plus grandes. La version qui précède est le R C4 à 8 bits. Il n’y a pas de raison de ne pas définir le R C4 à 16 bits avec une table-S 1 à 16*16 bits (100 kilo-octets de mémoire) et des mots de 16 bits. Il vous faudrait itérer beaucoup plus de fois l’étape d ’initialisation, 65536 pour suivre la conception actuelle, mais l’algorithme résultant serait plus rapide. RC4 possède un statut spécial pour l’exportation si la longueur de la clef ne dépasse pas 40 bits (voir § 13.8). Ce statut spécial n ’a rien à voir avec la confidentialité de l’algorithme, bien que R SA D SI l’ai laissé sous entendre durant des années. Le nom est déposé, aussi, toute personne écrivant son propre code doit l’appeler de manière différente. Divers document internes de la R SA D a t a S e c u r i t y , I n c . n’ont toujours pas été rendus publics [1333, 1349]. Quel est le marché avec R C 4 ? Il n’y a plus de secret de fabrication, aussi n ’importe qui peut l ’utiliser. Cependant, R SA D SI poursuivra certainement en justice tous ceux qui incorporent RC4 sans license à des produits commerciaux. Ils ne gagneront pro bablement pas, mais il sera moins cher pour une société d ’acheter une license que de combattre. RC4 fait partie d'une douzaine de produits commerciaux, tels que Lotus Notes, AOCE d’ A p p l e , et Oracle Secure SQL. Il est aussi dans la spécification de téléphones modu laires « Cellular Digital Packet Data » [38].
17.2
SEAL
SEAL est un algorithme de chiffrement en continu efficace sous forme de logiciel conçu chez IBM par Phyl R o g a w a y et Don C o p p e r s m i t h [1352]. L ’algorithme a été conçu pour les processeurs 32 bits : pour bien fonctionner, il lui faut des registres de 32 bits et une mémoire cache de quelques kilo-octets. Au moyen d ’une opération assez lente, 1. (256!
Il n’y existe aucun résultat cryptanalytique public. R C 4 peut se trouver dans environ 21700
x 2562) états possibles, un nom bre incomm ensurable.
17.2
SEAL
421
SEAL calcule au préalable un ensemble de tableaux à partir de la clef. Ces tableaux accélèrent ensuite le chiffrement et le déchiffrement.
Famille de fonctions pseudo-aléatoires Une particularité nouvelle de SEAL est de ne pas être un algorithme traditionnel de chiffrement en continu : c ’est une f a m ille d e f o n c t io n s p s e u d o - a lé a t o ir e s .E t a n t donné une clef k de 160 bits et un mot n de 32 bits, SEA L dilate n jusqu’à une chaîne k(n) de L bits. L peut prendre n’importe quelle valeur inférieure à 64 kilo-octets. SEAL est supposé avoir la propriété suivante : si k est pris aléatoirement, alors k{n) est indistinguable par calcul du résultat d’une fonction aléatoire de L bits appliquée à n.
L’intérêt pour SEAL d’être une famille de fonctions pseudo-aléatoires est que cela le rend utile dans des applications où les algorithmes traditionnels de chiffrement en continu ne le sont pas. Avec la plupart des algorithmes de chiffrement en continu, vous générez une suite de bits dans une seule direction : sachant la clef et une position i, le seul moyen de déterminer le ie bit est de générer tous les bits jusqu’au ie . Mais une famille de fonctions pseudo-aléatoires agit différemment : l’accès à n’importe quelle position dans le flux de codons est aisée. C ’est très utile. Imaginez que vous deviez protéger un disque dur. Vous voulez chiffrer chacun des secteurs de 512 octets. Avec une famille de fonctions pseudo-aléatoires telle que SEAL, vous pouvez chiffrer le contenu du secteur n en le combinant par ou exclusif avec k(n). Tout se passe comme si le disque entier était combiné par ou exclusif avec une longue chaîne pseudo-aléatoire où chaque morceau de cette longue chaîne peut être calculé sans difficulté. Une famille de fonctions pseudo-aléatoires simplifie aussi le problème de synchronisa tion rencontré avec les algorithmes classiques. Supposez que vous deviez chiffrer des messages envoyés par un canal qui perd parfois des messages. Avec une famille de fonc tions pseudo-aléatoires, vous pouvez chiffrer avec k le ne message xn que vous envoyez sous la forme de n suivi de la combinaison par ou exclusif de xn et k(n). Le destinataire n’a pas besoin de stocker d ’état pour retrouver xn, il n’a pas non plus à s’inquiéter de la perturbation du processus de déchiffrement par la perte d ’un message.
Description de SEAL La boucle interne de SEAL est illustrée par la figure 17.1. L ’algorithme repose sur trois tableaux, R, S et T, dérivés de la clef. L’étape de pré-calcul produit ces trois tableaux à partir de la clef k au moyen d ’une procédure basée sur SHA (voir § 18.7). Le tableau T de 2 kilo-octets est une table-S à 9*32 bits. SEAL utilise aussi quatre registres de 32 bits A, B, C et D dont les valeurs initiales dépendent de n, R et T. Ces registres sont modifiés au cours de plusieurs itérations, chacune d’elle comprenant huit rondes. A chaque ronde, 9 bits d’un premier registre [A, B, C ou D) servent d ’index dans le tableau T. La valeur retirée de T est alors ajoutée ou combinée par ou exclusif à un deuxième registre. Le premier registre est décalé circulairement de neuf positions. Dans certaines rondes le second registre (après décalage) subit des modifications suplémentaires en le combinant par ou exclusif avec le premier registre ou en le lui ajoutant. Après huit rondes de ce type, A, B , C et D viennent gonfler le flux de codons, après avoir masqué chacun d ’eux en le combinant
422
Chapitre 17
F
ig
.
Autres algorithmes de chiffrement en continu
17.1 - Boucle interne de SEAL
avec un certain mot de S par addition ou par ou exclusif. L’itération s’achève en ajoutant à A et C des valeurs suplémentaires dépendantes de n, n i, n2, 'ris, n 4 , selon la parité du numéro de l’itération. Les idées importantes de la conception semble être : 1. Utiliser une grande table-S1secrète et dérivée de la clef (T). 2. Alterner des opérations arithmétiques qui ne commutent pas (addition et ou exclusif).
3. Utiliser un état interne maintenu par l’algorithme qui ne se manifeste pas direc tement dans le flot de données (les valeurs des n%qui servent à modifier A et C à la fin de chaque itération). 4. Faire varier la fonction de ronde avec le numéro de la ronde, la fonction d ’itération avec le numéro d’itération. SEAL fait appel à environ cinq opérations élémentaires de la machine pour chiffrer un octet de texte en clair. Il fonctionne à 58 mégaoctets par seconde sur un 486 cadencé à 50 MHz. C ’est l’algorithme de chiffrement le plus rapide du livre. D ’un autre côté, SEAL doit pré-calculer ses tableaux internes à partir de la clef. Ces tableaux occupent en mémoire environ 3 kilo-octets au total et leur calcul requiert à peu près 200 calculs de SHA. SEAL n’est donc pas adapté aux situations où vous n’avez pas de temps pour effectuer le pré-calcul sur la clef, ou la mémoire suffisante pour stocker les tableaux.
17.3
W AKE
Sécurité de SEAL SEAL est un nouvel algorithme et n’est encore le sujet d’aucune cryptanalyse publiée. Cela incite à la prudence. Il semble cependant que SEAL est bien pensé. Ses curiosité ont un sens au bout du compte. Et Don C O P P E R S M IT H est généralement considéré comme le cryptanalyste le plus intelligent du monde.
Brevets et licenses SEAL est en cours de brevetage [384]. Quiconque désire se procurer une license pour utiliser SEAL devrait contacter: Director of Licenses, IBM Corporation, 500 Columbus Ave., Thurnwood, N Y , 10594, États-Unis.
17.3
WAKE
W AK E a été inventé par David W H E E L E R [1591], Il produit un flux de mots de 32 bits qui peut être combiné par ou exclusif avec le texte en clair pour le chiffrement, ou avec le texte chiffré pour le déchiffrement. W AKE fonctionne en mode C FB ; le mot précédent de texte chiffré est utilisé pour produire le codon suivant. Il utilise aussi une table-S1de 256 valeurs de 32 bits. Cette table-S1vérifie une propriété spéciale : les octets de poids fort des 256 valeurs forment une permutation de tous les octets possibles et les trois octets de poids faibles sont aléatoires. Tout d ’abord, générez les valeurs Si de la table-S1à partir de la clef. Initialisez alors quatre registre cto, bo, Co et do avec la clef (ou avec un autre clef). Pour générer un codon K l de 32 bits, appliquez simplement ceci : Ki
dj
Le mot de texte chiffré Ci est obtenu par combinaison par ou exclusif du mot de texte en clair A4, avec Ki. Mettez alors à jour les quatre registres : Gà-j-1 —
7Vd(GEj,dj)
5-i+i — Af(6j ,g j_|_i ) ci+i = M (c i,b i+ 1 ) di+i ■ 4lL(dj,Cj-ri)
La fonction M est donnée par : M( x, y) = (x + y) »
8 ® S^x+y)2ss
Ceci est illustré par la figure 17.2. L ’opération > > est un décalage à droite et non une rotation. Les bits de poids faible de x + y sont les entrées de la table-S1. W H E E L E R propose une procédure pour générer la table-S1, mais elle n’est pas vraiment complète. N’importe quel algorithme générant des octets aléatoires et une permutation aléatoire conviendra. Le principal atout de W A K E est sa rapidité. Cependant il ne résiste pas à une attaque à texte en clair choisi ou à une attaque à texte chiffré choisi. Il est utilisé dans la version courante du programme « Dr. Solomon’s Anti-Virus ».
m
Chapitre 17
F
17.4
ig
.
Autres algorithmes de chiffrement en continu
17.2 - W A K E
Registres à décalage à rétroaction avec retenue
Un registre à décalage à rétroaction avec retenue ou en abrégé R D R R 2, ressemble à un R D R L . Ils ont tous les eux un registre à décalage et une fonction de rétroaction ; la différence est qu’un R D R R a aussi un registre de retenue (voir la figure 17.3). Au lieu de combiner par ou exclusif tous les bits de la séquence de dérivation, ajoutez les bits et le contenu du registre de retenue ensemble. Le résultat modulo 2 devient le nouveau bit. Le résultat divisé par 2 devient le nouveau contenu du registre de retenue. La figure 17.4 présente un exemple de R D R R à 3 bits dérivé au premier et eu deuxième bit. Sa valeur initiale est 0 0 1 et le registre de retenue contient initialement 0. Le bit
2. N ote du traducteur : en anglais, les registres à décalage à rétroaction avec retenue sont appelés « feed ba ck w ith c a r r y shzft r e g iste r s » et sont abrégés « F C S R ».
17.J,
Registres à décalage à rétroaction avec retenue
Registre à décalage Som m e m odulo 2 h
n
bn-l
b,4
b
i
b
ae 2
bl
Somme divisée par 2
F i g . 17.3
Registre à décalage à rétroaction avec retenue
de sortie est le bit le plus à droite du registre. Registre à décalage 0 1 0 1 1 1 0 1 0 0 0 1
0 0 1 0 1 1 1 0 1 0 0 0
1 0 0 1 0 1 1 1 0 1 0 0
Registre de retenue 0 0 0 0 0 0 1 1 1 1 1 0
Notez que l’état interne final (y compris le contenu du registre de retenue) est identique au second état interne. La suite boucle à partir de ce point et sa période est 10. Il faut préciser quelques points. Premièrement, le registre de retenue n’est pas un simple bit ; c’est un nombre. La taille du registre de retenue doit être au moins log2 1 où t est le nombre de dérivations. Il n’y a que deux dérivations dans l’exemple précédent, aussi le registre de retenue ne requiert qu’un seul bit. S’il y avait quatre dérivations, le registre de retenue aurait deux bits, et pourrait valoir 0, 1, 2, ou 3. Ensuite, le R D R R passe initialement par une séquence transitoire avant de se répéter périodiquement. Dans l’exemple précédent, un seul état n’est jamais répété. Pour des R D R R plus grands et plus compliqués, il peut y en avoir plus. Enfin, la période maximale d ’un R D R R n’est pas 2n — 1, n étant la taille du registre à décalage. La période maximale est q — 1 où q est l ’e n t ie r d e c o n n e x io n . Ce nombre identifie la séquence de dérivation, il est donné par : q — 2qi + 2 2Ç2 + 24Q4 + •■•+ 2nqn — 1
Chapitre 17
Autres algorithmes de chiffrement en continu
Somme modulo 2
H h u3
b_2 b, ui
Bit de sortie ►
Somme
Somme divisée par 2 F ig. 17.4 - Un R D R R à 3 bits (Les q, sont bien numérotés de gauche à droite et valent 1 lorsque le bit correspondant du registre à décalage est dérivé, 0 sinon.) q doit être premier et admettre 2 comme racine primitive. On supposera par la suite que q est bien de cette forme. Dans l’exemple précédent, ç = 2 x 0 + 4 x l + 8 x l - 1 = 11. Et 11 est un nombre premier admettant 2 comme racine primitive. La période maximale est donc 10. Tous les états initiaux ne conduisent pas à une période maximale, considérez par exemple le R D R R précédent avec une valeur initiale de 1 0 1 et le registre de re tenue à 4. Registre à décalage Registre de retenue 10 1 4 110 2 111 1 111 1 À partir de là, le registre produit une suite sans fin de un. Tout état initial appartient à l’une des quatre catégories suivantes. 1°) Il fait partie de la période maximale. 2°) Il conduit à la période maximale après une séquence initiale de transition. 3°) Il conduit à une suite infinie de zéros après une éventuelle séquence initiale de transition. 4°) Il conduit à une suite infinie de un après une éventuelle séquence initiale de transition. Il existe une formule mathématique permettant de déterminer ce qu’il adviendra à partir d’un état initial donné, mais il est beaucoup plus facile de le tester. Faites fonctionner le R D R R un moment. (Si m est la taille de la mémoire initiale et t le nombre de dérivations, alors log2 1 + log2 m -I- 1 étapes suffisent.) S’il dégénère en une suite continue de 1 ou de 0 d ’au moins n bits, où n est la taille du R D R R , ne l’utilisez pas. Dans le cas contraire, utilisez le. Comme l’état initial d ’un R D R R dépend de la clef, cela signifie qu’un générateur à base de R D R R aura des clefs faibles. Le tableau 17.1 rassemble tous les entiers de connexion q inférieurs à 10 000 admettant 2 comme racine primitive. Ils donnent tous une période maximale de q —1. Pour obtenir
17.5
Chiffrement en continu à base de R D R R
427
a séquence de dérivation, il suffit de calculer la représentation binaire de q + 1. Par exemple, 9949 se traduit par la dérivation des bits 1, 2, 3, 4, 6, 7, 9, 10, et 13 car 9950 = 213 + 210 + 29 + 27 -f 26 + 24 + 23 + 22 + 21. Le tableau 17.2 rassemble toutes les séquences de dérivation à quatre bit qui donnent in R D R R de taille maximale pour un registre à décalage de 32, 64, 96 ou 128 bits. Les quatres valeurs a,b,c,d donnent toujours un nombre premier q dont 2 est une racine primitive. q=
2 “
+
2b +
2 e +
2d -
1
Chacune de ces séquences de dérivation permet de construire un R D R R de période 7-
1.
L’idée d’utiliser des R D R R pour la cryptographie est encore très récente; elle est actuellement défrichée par Andy K l a p p e r et Mark G o r e s k y [845, 846, 656, 844, 847], Tout comme l’analyse des R D R L est basée sur l’addition des polynômes primitifs modulo 2, l’analyse des R D R R est basée sur ce que l’on appelle les nombre 2-adiques. La théorie dépasse largement le cadre de ce livre, mais il semble exister un analogue 2-adique pour chaque chose. Par analogie à la complexité linéaire, on peut définir la complexité 2-adique. Il y a même un analogue 2-adique de l’algorithme de BerlekampMassey.
17.5
Chiffrement en continu à base de R D R R
Il n’existe pas d’algorithmes de chiffrement en continu à base de R D R R dans la littéra ture ; la théorie est encore trop récente. J’en propose quelques uns ici pour faire avancer les choses. Je me lance dans deux voies différentes : je propose des générateurs à base de R D R R identiques à ceux présentés avec des R D R L , et je propose des générateurs utilisant à la fois des R D R R et des R D R L . II est probablement possible d ’évaluer la sécurité des premiers avec la théorie des nombres 2-adiques; les seconds ne peuvent pas être analysés avec des techniques algébriques, il est probablement possible de les analyser indirectement. Dans tous les cas, il est important de choisir des R D R R et des RDRL dont les périodes soient premières entre elles. Ceci fait partie de l’avenir. Je ne connais aucune réalisation ou analyse de ces idées. Attendez quelques années et consultez alors la littérature avant de leur faire confiance.
Générateurs en cascade Il y a deux façons de mettre des R D R R en cascade dans un générateur : - Cascade de R D R R . Reprendre la cascade de G lieu de R D R L .
o llm an n
- Cascade de R D R L /R D R R . Reprendre la cascade de G ternance de R D R L et de R D R R .
avec des R D R R au
ollm an n
avec une al
Chapitre 17
428
T
ab
.
Autres algorithmes de chiffrement en continu
17.1 - Entiers de connexion pour R D R R de période maximale
2
653
1549
2477
3539
4397
5693
6781
7 717
8861
5
659
1571
2531
3547
4451
5701
6803
7757
8 867
11
661
1619
2539
3 557
4483
5 717
6 827
7789
8923
13
677
1621
2549
3571
4493
5741
6829
7829
8933
19
701
1637
2557
3581
4507
5749
6869
7853
8 963
29
709
1667
2579
3613
4517
5779
6883
7877
8971
37
757
1669
2621
3637
4547
5813
6899
7883
9011
53
773
1693
2659
3643
4603
5827
6907
7901
9029
59 61
787
1733
3659
4621
5843
6917
7907
9 059
797
1741
2677 2683
3 677
4637
5851
6947
7933
9173
67
821
1747
2693
3691
4691
5869
6949
7949
9181
83
827
1787
2699
3701
4723
5923
6971
8053
9203
101 107
829
1861
3709
4 787
8069
9221
1867
3733
4789
5939 5 987
7013
853
2707 2741
7019
8093
9 227
131
859
1877
2789
3779
4813
7027
8117
9283
139
877
1901
2 797
3 797
4877
6011 6029
7043
8123
9293
149
883
1907
2803
3803
4933
6053
7069
8 147
9323
163
907
1931
2819
3851
4957
6067
7109
8171
9341
173
941
1949
2837
3853
4973
6101
7187
8179
9349
179
947
1973
2843
3877
4 987
6131
7211
8219
9371
181
1019
1979
2851
3 907
5003
6173
7219
8221
9397
197
1061 1091
1987 1997
2861
3917
7229
8237
9419
2909
3923
5011 5051
6197
211
6203
7237
8243
9421
227
1109
2939
3931
5059
6211
7243
8269
9 437
269
1117
2 027 2029
2957
3947
5 077
6229
7253
8291
9467
293
1123
2053
2963
3989
5099
6269
7283
8293
9491
317
1171
2069
4 003
5 107
6 277
7307
8363
9533
347
1187
2083
3011 3019
4013
5147
6299
7331
8387
9 539
349
1213
2099
3037
4019
5171
6 317
7349
8429
9547
373
1229
2131
3067
4021
5179
6323
7411
8443
9587
379
1237
2141
3083
4091
5189
6373
7451
8 467
9613
389 419
1259
2213
3 187
4093
5227
6379
7459
8539
9619
1277
2221
3203
4099
5261
6389
7477
8563
9629
421
1283
2237
3253
4133
5309
6397
7499
8573
9643
443
1291
2243
3299
4139
5333
6469
7507
8597
9661
461
1301
2267
3307
4157
5 387
6491
7517
8 627
9677
4 67
1307
4219
5443
6547
7523
8669
9733
1373
2269 2293
3323
491
3 347
4229
5477
6619
7541
8 677
9749
509
1381
2309
3371
4243
5483
6637
7547
8693
9803
523
1427
2333
3413
4253
5501
6653
7549
8699
9851
541
1451
2339
3461
4259
5507
6659
7573
8731
9859
547
1453
2357
3 467
4261
5 557
6691
7589
8741
9883 9901
557
1483
2371
3469
4283
5563
6701
7603
8747
563
1493
2389
3491
4 349
5573
6709
7621
8803
9 907
587
1499
2437
3499
4 357
5651
6733
7643
8 819
613
1523
2459
3 517
4363
5659
6763
7669
8821
9923 9941
619
1531
2467
3533
4 373
5683
6779
7691
8 837
9949
17.5
Chiffrement en continu à base de R D R R
429
Tab. 17.2 - Séquences de dérivation pour R D R R de période maximale (3 2 .6 .3 .2 )
(6 4 ,2 4 ,1 9 ,2 )
(6 4 ,5 9 ,2 8 ,2 )
(9 6 ,5 5 ,5 3 ,2 )
(3 2 .7 .5 .2 )
(6 4 ,2 5 ,3 ,2 )
(6 4 ,5 9 ,3 8 ,2 )
(9 6 ,5 6 ,9 ,2 )
(3 2 .8 .3 .2 )
(6 4 ,2 5 ,4 ,2 )
(6 4 ,5 9 ,4 4 ,2 )
(3 2 .1 3 .8 .2 ) (3 2 .1 3 .1 2 .2 )
(6 4 ,2 5 ,1 1 ,2 ) (6 4 ,2 5 ,1 9 ,2 )
(6 4 ,6 0 ,4 9 ,2 ) (6 4 ,6 1 ,5 1 ,2 )
(3 2 .1 5 .6 .2 )
(6 4 ,2 7 ,5 ,2 )
(6 4 ,6 3 ,8 ,2 )
(3 2 .1 6 .2 .1 )
(6 4 ,2 7 ,1 6 ,2 )
(6 4 ,6 3 ,1 3 ,2 )
(9 6 ,5 8 ,3 5 ,2 )
(3 2 .1 6 .3 .2 )
(6 4 ,2 7 ,2 2 ,2 )
(6 4 ,6 3 ,6 1 ,2 )
(9 6 ,5 9 ,4 6 ,2 )
(3 2 .1 6 .5 .2 ) (3 2 .1 7 .5 .2 )
(6 4 ,2 8 ,1 9 ,2 ) (6 4 ,2 8 ,2 5 ,2 )
(9 6 ,5 6 ,5 1 ,2 ) (9 6 ,5 7 ,3 ,2 ) (9 6 ,5 7 ,1 7 ,2 ) (9 6 ,5 7 ,4 7 ,2 )
(9 6 ,6 0 ,2 9 ,2 ) (9 6 ,1 5 ,5 ,2 )
(9 6 ,6 0 ,4 1 ,2 )
(3 2 .1 9 .2 .1 )
(6 4 ,2 9 ,1 6 ,2 )
(9 6 ,2 1 ,1 7 ,2 )
(9 6 ,6 0 ,4 5 ,2 )
(3 2 .1 9 .5 .2 )
(6 4 ,2 9 ,2 8 ,2 )
(9 6 ,2 5 ,1 9 ,2 )
(9 6 ,6 1 ,1 7 ,2 )
(3 2 .1 9 .9 .2 )
(6 4 ,3 1 ,1 2 ,2 )
(9 6 ,2 5 ,2 0 ,2 )
(9 6 ,6 3 ,2 0 ,2 )
(3 2 .1 9 .1 2 .2 )
(6 4 ,3 2 ,2 1 ,2 )
(9 6 ,2 9 ,1 5 ,2 )
(9 6 ,6 5 ,1 2 ,2 )
(3 2 .1 9 .1 7 .2 )
(6 4 ,3 5 ,2 9 ,2 )
(9 6 ,2 9 ,1 7 ,2 )
(9 6 ,6 5 ,3 9 ,2 )
(3 2 .2 0 .1 7 .2 )
(6 4 ,3 6 ,7 ,2 )
(9 6 ,3 0 ,3 ,2 )
(9 6 ,6 5 ,5 1 ,2 )
(3 2 .2 1 .9 .2 )
(6 4 ,3 7 ,2 ,1 )
(9 6 ,3 2 ,2 1 ,2 )
(9 6 ,6 7 ,5 ,2 )
(3 2 .2 1 .1 5 .2 )
(6 4 ,3 7 ,1 1 ,2 )
(9 6 ,3 2 ,2 7 ,2 )
(9 6 ,6 7 ,2 5 ,2 )
(3 2 .2 3 .8 .2 )
(6 4 ,3 9 ,4 ,2 )
(9 6 ,3 3 ,5 ,2 )
(9 6 ,6 7 ,3 4 ,2 )
(3 2 .2 3 .2 1 .2 ) (3 2 .2 5 .5 .2 )
(6 4 ,3 9 ,2 5 ,2 ) (6 4 ,4 1 ,5 ,2 )
(9 6 ,3 5 ,1 7 ,2 ) (9 6 ,3 5 ,3 3 ,2 )
(9 6 ,6 8 ,5 ,2 ) (9 6 ,6 8 ,1 9 ,2 )
(3 2 .2 5 .1 2 .2 )
(6 4 ,4 1 ,1 1 ,2 )
(9 6 ,3 9 ,2 1 ,2 )
(9 6 ,6 9 ,1 7 ,2 )
(3 2 .2 7 .2 5 .2 )
(6 4 ,4 1 ,2 7 ,2 )
(9 6 ,4 0 ,2 5 ,2 )
(9 6 ,6 9 ,3 6 ,2 )
(3 2 .2 9 .1 9 .2 )
(6 4 ,4 3 ,2 1 ,2 )
(9 6 ,4 1 ,1 2 ,2 )
(9 6 ,7 0 ,2 3 ,2 )
(3 2 .2 9 .2 0 .2 )
(6 4 ,4 3 ,2 8 ,2 )
(9 6 ,4 1 ,2 7 ,2 )
(9 6 ,7 1 ,6 ,2 )
(3 2 .3 0 .3 .2 )
(6 4 ,4 5 ,2 8 ,2 )
(9 6 ,4 1 ,3 5 ,2 )
(9 6 ,7 1 ,4 0 ,2 )
(3 2 .3 0 .7 .2 )
(6 4 ,4 5 ,4 1 ,2 )
(9 6 ,4 2 ,3 5 ,2 )
(9 6 ,7 2 ,5 3 ,2 )
(3 2 .3 1 .5 .2 )
(6 4 ,4 7 ,5 ,2 )
(9 6 ,4 3 ,1 4 ,2 )
(9 6 ,7 3 ,3 2 ,2 )
(3 2 .3 1 .9 .2 )
(6 4 ,4 7 ,2 1 ,2 )
(9 6 ,4 4 ,2 3 ,2 )
(9 6 ,7 7 ,2 7 ,2 )
(3 2 .3 1 .3 0 .2 )
(6 4 ,4 7 ,3 0 ,2 ) (6 4 ,4 9 ,1 9 ,2 )
(9 6 ,4 5 ,4 1 ,2 ) (9 6 ,4 7 ,3 6 ,2 )
(9 6 ,7 7 ,3 1 ,2 ) (9 6 ,7 7 ,3 2 ,2 )
(6 4 .3 .2 .1 )
(6 4 ,4 9 ,2 0 ,2 )
(9 6 ,4 9 ,3 1 ,2 )
(9 6 ,7 7 ,3 3 ,2 )
(6 4 .1 4 .3 .2 )
(6 4 ,5 2 ,2 9 ,2 )
(9 6 ,5 1 ,3 0 ,2 )
(9 6 ,7 7 ,7 1 ,2 )
(6 4 .1 5 .8 .2 )
(6 4 ,5 3 ,8 ,2 )
(9 6 ,5 3 ,1 7 ,2 )
(9 6 ,7 8 ,3 9 ,2 )
(6 4 .1 7 .2 .1 )
(6 4 ,5 3 ,4 3 ,2 )
(9 6 ,5 3 ,1 9 ,2 )
(9 6 ,7 9 ,4 ,2 )
(6 4 .1 7 .9 .2 )
(6 4 ,5 6 ,3 9 ,2 )
(9 6 ,5 3 ,3 2 ,2 )
(9 6 ,8 1 ,8 0 ,2 )
(6 4 .1 7 .1 6 .2 )
(6 4 ,5 6 ,4 5 ,2 )
(9 6 ,5 3 ,4 8 ,2 )
(9 6 ,8 3 ,1 4 ,2 )
(6 4 ,1 9 ,2 ,1 )
(6 4 ,5 9 ,5 ,2 )
(9 6 ,5 4 ,1 5 ,2 )
(9 6 ,8 3 ,2 6 ,2 )
(6 4 .1 9 .1 8 .2 )
(6 4 ,5 9 ,8 ,2 )
(9 6 ,5 5 ,4 4 ,2 )
(9 6 ,8 3 ,5 4 ,2 )
(9 6 .8 3 .6 0 .2 )
(1 2 8 ,3 1 ,2 5 ,2 )
(1 2 8 ,8 1 ,5 5 ,2 )
(1 2 8 ,1 0 5 ,1 1 ,2 )
(9 6 .8 3 .6 5 .2 )
(1 2 8 ,3 3 ,2 1 ,2 )
(1 2 8 ,8 2 ,6 7 ,2 )
(1 2 8 ,1 0 5 ,3 1 ,2 )
(9 6 .8 3 .7 8 .2 )
(1 2 8 ,3 5 ,2 2 ,2 )
(1 2 8 ,8 3 ,6 0 ,2 )
(1 2 8 ,1 0 5 ,4 8 ,2 )
(9 6 .8 4 .6 5 .2 )
(1 2 8 ,3 7 ,8 ,2 )
(1 2 8 ,8 3 ,6 1 ,2 )
(1 2 8 ,1 0 7 ,4 0 ,2 )
(9 6 .8 5 .1 7 .2 )
(1 2 8 ,4 1 ,1 2 ,2 )
(1 2 8 ,8 3 ,7 7 ,2 )
(1 2 8 ,1 0 7 ,6 2 ,2 )
(9 6 .8 5 .3 1 .2 )
(1 2 8 ,4 2 ,3 5 ,2 )
(1 2 8 ,8 4 ,1 5 ,2 )
(1 2 8 ,1 0 7 ,1 0 2 ,2 )
(9 6 .8 5 .7 6 .2 )
(1 2 8 ,4 3 ,2 5 ,2 )
(1 2 8 ,8 4 ,4 3 ,2 )
(1 2 8 ,1 0 8 ,3 5 ,2 )
(9 6 .8 5 .7 9 .2 )
(1 2 8 ,4 3 ,4 2 ,2 )
(1 2 8 ,8 5 ,6 3 ,2 )
(1 2 8 ,1 0 8 ,7 3 ,2 )
(9 6 .8 6 .3 9 .2 )
(1 2 8 ,4 5 ,1 7 ,2 )
(1 2 8 ,8 7 ,5 7 ,2 )
(1 2 8 ,1 0 8 ,7 5 ,2 )
(9 6 .8 6 .7 1 .2 )
(1 2 8 ,4 5 ,2 7 ,2 )
(1 2 8 ,8 7 ,8 1 ,2 )
(1 2 8 ,1 0 8 ,8 9 ,2 )
Chapitre 17
430
T
ab
.
Autres algorithmes de chiffrement en continu
17.2 - Séquences de dérivation pour R D R R de période maximale (suite) (9 6 .8 7 .9 .2 )
(1 2 8 ,4 9 ,9 ,2 )
(1 2 8 ,8 9 ,8 1 ,2 )
(1 2 8 ,1 0 9 ,1 1 ,2 )
(9 6 .8 7 .4 4 .2 )
(1 2 8 ,5 1 ,9 ,2 )
(1 2 8 ,9 0 ,4 3 ,2 )
(1 2 8 ,1 0 9 ,1 0 8 ,2 ) (1 2 8 ,1 1 0 ,2 3 ,2 )
(9 6 .8 7 .4 5 .2 )
(1 2 8 ,5 4 ,5 1 ,2 )
(1 2 8 ,9 1 ,9 ,2 )
(9 6 .8 8 .1 9 .2 )
(1 2 8 ,5 5 ,4 5 ,2 )
(1 2 8 ,9 1 ,1 3 ,2 )
(1 2 8 ,1 1 1 ,6 1 ,2 )
(9 6 .8 8 .3 5 .2 )
(1 2 8 ,5 6 ,1 5 ,2 )
(1 2 8 ,9 1 ,4 4 ,2 )
(1 2 8 ,1 1 3 ,5 9 ,2 )
(9 6 .8 8 .4 3 .2 )
(1 2 8 ,5 6 ,1 9 ,2 )
(1 2 8 ,9 2 ,3 5 ,2 )
(1 2 8 ,1 1 4 ,8 3 ,2 )
(9 6 .8 8 .7 9 .2 )
(1 2 8 ,5 6 ,5 5 ,2 )
(1 2 8 ,9 5 ,9 4 ,2 )
(1 2 8 ,1 1 5 ,7 3 ,2 )
(9 6 .8 9 .3 5 .2 )
(1 2 8 ,5 7 ,2 1 ,2 )
(1 2 8 ,9 6 ,2 3 ,2 )
(1 2 8 ,1 1 7 ,1 0 5 ,2 )
(9 6 .8 9 .5 1 .2 )
(1 2 8 ,5 7 ,3 7 ,2 )
(1 2 8 ,9 6 ,6 1 ,2 )
(1 2 8 ,1 1 9 ,3 0 ,2 )
(9 6 .8 9 .6 9 .2 )
(1 2 8 ,5 9 ,2 9 ,2 )
(1 2 8 ,9 7 ,2 5 ,2 )
(1 2 8 ,1 1 9 ,1 0 1 ,2 )
(9 6 .8 9 .8 7 .2 )
(1 2 8 ,5 9 ,4 9 ,2 )
(1 2 8 ,9 7 ,6 8 ,2 )
(1 2 8 ,1 2 0 ,9 ,2 )
(9 6 .9 2 .5 1 .2 )
(1 2 8 ,6 0 ,5 7 ,2 )
(1 2 8 ,9 7 ,7 2 ,2 )
(1 2 8 ,1 2 0 ,2 7 ,2 )
(9 6 .9 2 .7 1 .2 )
(1 2 8 ,6 1 ,9 ,2 )
(1 2 8 ,9 7 ,7 5 ,2 )
(1 2 8 ,1 2 0 ,3 7 ,2 )
(9 6 .9 3 .3 2 .2 )
(1 2 8 ,6 1 ,2 3 ,2 )
(1 2 8 ,9 9 ,1 3 ,2 )
(1 2 8 ,1 2 0 ,4 1 ,2 )
(9 6 .9 3 .3 9 .2 )
(1 2 8 ,6 1 ,5 2 ,2 )
(1 2 8 ,9 9 ,1 4 ,2 )
(1 2 8 ,1 2 0 ,7 9 ,2 )
(9 6 .9 4 .3 5 .2 )
(1 2 8 ,6 3 ,4 0 ,2 )
(1 2 8 ,9 9 ,2 6 ,2 )
(1 2 8 ,1 2 0 ,8 1 ,2 )
(9 6 .9 5 .4 .2 )
(1 2 8 ,6 3 ,6 2 ,2 )
(1 2 8 ,9 9 ,5 4 ,2 )
(1 2 8 ,1 2 1 ,5 ,2 )
(9 6 .9 5 .1 6 .2 )
(1 2 8 ,6 7 ,4 1 ,2 )
(1 2 8 ,9 9 ,5 6 ,2 )
(1 2 8 ,1 2 1 ,6 7 ,2 )
(9 6 .9 5 .3 2 .2 )
(1 2 8 ,6 9 ,3 3 ,2 )
(1 2 8 ,9 9 ,7 8 ,2 )
(1 2 8 ,1 2 1 ,9 5 ,2 )
(9 6 .9 5 .4 4 .2 )
(1 2 8 ,7 1 ,5 3 ,2 )
(1 2 8 ,1 0 0 ,1 3 ,2 )
(1 2 8 ,1 2 1 ,9 6 ,2 )
(9 6 .9 5 .4 5 .2 )
(1 2 8 ,7 2 ,1 5 ,2 )
(1 2 8 ,1 0 0 ,3 9 ,2 )
(1 2 8 ,1 2 3 ,4 0 ,2 )
(1 2 8 ,1 0 1 ,4 4 ,2 )
(1 2 8 ,1 2 3 ,7 8 ,2 )
(1 2 8 ,7 2 ,4 1 ,2 ) (1 2 8 .5 .4 .2 )
(1 2 8 ,7 3 ,5 ,2 )
(1 2 8 ,1 0 1 ,9 7 ,2 )
(1 2 8 ,1 2 4 ,4 1 ,2 )
(1 2 8 .1 5 .4 .2 )
(1 2 8 ,7 3 ,6 5 ,2 )
(1 2 8 ,1 0 3 ,4 6 ,2 )
(1 2 8 ,1 2 4 ,6 9 ,2 )
(1 2 8 .2 1 .1 9 .2 )
(1 2 8 ,7 3 ,6 7 ,2 )
(1 2 8 ,1 0 4 ,1 3 ,2 )
(1 2 8 ,1 2 4 ,8 1 ,2 )
(1 2 8 .2 5 .5 .2 )
(1 2 8 ,7 5 ,1 3 ,2 )
(1 2 8 ,1 0 4 ,1 9 ,2 )
(1 2 8 ,1 2 5 ,3 3 ,2 )
(1 2 8 .2 6 .1 1 .2 )
(1 2 8 ,8 0 ,3 9 ,2 )
(1 2 8 ,1 0 4 ,3 5 ,2 )
(1 2 8 ,1 2 5 ,4 3 ,2 )
(1 2 8 .2 7 .2 5 .2 )
(1 2 8 ,8 0 ,5 3 ,2 )
(1 2 8 ,1 0 5 ,7 ,2 )
(1 2 8 ,1 2 7 ,1 2 1 ,2 )
Générateurs à combinaison de R D RR Ces générateurs utilisent un nombre variable de R D R L et de R D R R , et toute une variété de fonctions pour les combiner entre eux. L ’opération de ou exclusif détruit les propriétés algébriques des R D R R , aussi, il est sensé de les utiliser pour combiner. Le générateur, illustré par la ligure 17.5, utilise un nombre variable de R D R R . Sa sortie est la combinaison par ou exclusif des sorties des R D R R . Voici générateurs du même type : - Générateur R D R R équitable. Tous les registres sont des R D R R combinés par ou exclusif. — Générateur R D R L /R D R R équitable. Les registres sont un mélange de R D RL et de R D R R combinés par ou exclusif.
Générateur R D R R à seuil. Tous les registres sont des R D R R combinés selon la majorité. Générateur R D R L /R D R R à seuil. Les registres sont un mélange de R D R L et de R D R R combinés selon la majorité
17.5
Chiffrement en continu à base de R D R R
F i g . 17.5
431
- Combinaison de générateurs
- Générateur R D R R sommatoire. Tous Les registres sont des R D R R combinés par addition avec retenue. - Générateur R D R L /R D R R sommatoire. Les registres sont un mélange de R D R L et de R D R R combinés par addition avec retenue.
Cascade de R D R L /R D R R sommatoire/équitable La théorie dit que l’addition avec retenue détruit les propriétés algébriques des R D R L et que l’opération de ou exclusif détruit celles des R D R R . Ce générateur combine ces idées, telles qu’elles sont utilisées dans le générateur R D R L /R D R R sommatoire et le générateur R D R L /R D R R équitable, avec la cascade de G o l l m a n n . Le générateur est une série de tableaux de registres où l’horloge de chaque tableau est contrôlée par la sortie du tableau précédent. La figure 17.6 illustre une couche de ce générateur. Après avoir opéré un cycle d ’horloge sur un premier tableau de R D R L , les résultats sont combinés par addition avec retenue. Si le résultat de cette combinaison est 1, alors on opère un cycle d’horloge sur le tableau suivant, qui composé de R D R R , et les sorties de ces R D R R sont combinées par ou exclusif. Si le résultat de la première combinaison est 0, le tableau de R D R R n’est pas actionné et le résultat est seulement ajouté à la retenue de la ronde précédente. Si le résultat de la deuxième combinaison est 1, alors le troisième tableau est actionné, et ainsi de suite. Ce générateur utilise beaucoup de registres n par m où n est le nombre de couches et m le nombre de registre par couche. Je recommande n = 10 et m ~ 5.
Générateurs à signal d’arrêt alterné Ces générateurs sont des générateurs à signal d’arrêt avec des R D R R à la place de certains R D R L . On peut remplacer de plus l’opération de ou exclusif par une autre fonction de combinaison telle que l’addition avec retenue (voir la figure 17.7).
Chapitre 17
Autres algorithmes de chiffrement en continu
F ig . 17.6 - Mixture de générateurs
- Générateur R D R R à signal d ’arrêt. Les registres 1, 2 et 3 sont des R D RR. La fonction de combinaison est l’opération de ou exclusif.
- Générateur R D R R /R D R L à signal d’arrêt. Le registre 1 est un R D R R , les registres 2 et 3 sont des R D R L . La fonction de combinaison est l’addition avec retenue.
- Générateur R D R L /R D R R à signal d’arrêt. Le registres 1 est un R D R L, les registres 2 et 3 sont des R D R R . La fonction de combinaison est l’opération de ou exclusif.
F i g . 1 7 .7 -
Générateurs à signal d’arrêt alterné
17 6
Registres à décalage à rétroaction non linéaire
Générateurs à réduction Il y a quatre types principaux de générateurs à réduction utilisant des R D R R : - Générateur R D R R à réduction. Un générateur à réduction conventionnel avec des R D R R à la place des R D R L . - Générateur R D R R /R D R L à réduction. Un générateur à réduction avec un R D R L réduisant un R D R R . - Générateur R D R L /R D R R à réduction. Un générateur à réduction avec un R D R R réduisant un R D R L . - Générateur R D R R à auto-réduction. Un générateur à auto-réduction avec un R D R R à la place du R D R L .
17.6
Registres à décalage à rétroaction non linéaire
Il est facile d ’imaginer des séquences de rétroaction plus compliquées que celles des RDRL et des R D R R . Le problème est qu’il n’existe pas de théorie mathématique permettant de les analyser. Vous obtiendrez quelque chose, mais Dieu sait quoi. En particulier, voici quelques problèmes susceptibles d’êtres rencontrés avec les registres à décalage à rétroaction non linéaire : - La suite de sortie risque d ’être biaisée, par exemple si elle contient plus de un que de zéros. - La période maximale peut s’avérer plus faible que prévu. - La période de la suite de sortie peut différer pour des valeurs de départ distinctes. - La suite peut paraître aléatoire pendant un temps, puis se coincer sur la même valeur. (Il est facile d ’éviter cela en combinant par ou exclusif la fonction non linéaire avec le bit le plus à droite.) Le bon côté de l’absence de théorie pour analyser la sécurité des registres à décalage à rétroaction non linéaire est qu’il existe peu d ’outils de cryptanalyse des algorithmes de chiffrement qui les utilisent. On peut utiliser les registres à décalage à rétroaction non linéaire pour chiffrer en continu, mais il faut être prudent. Dans un registre à décalage à rétroaction non linéaire, la fonction de rétroaction peut être ce que vous voulez (voir la figure 17.8). La figure 17.9 illustre un registre à décalage utilisant la fonction de rétroaction suivante : le nouveau bit est à égal au produit du premier et du troisième bit. Init.ialisé avec la valeur 110, il produira la suite d’états internes suivante: 110 0 11 10 1
434
Chapitre 17
Autres algorithmes de chiffrement en continu
0 10 0 0 1 0 0 0 0 0 0
Et ainsi de suite. La suite de sortie est la chaîne des bits les moins significatifs :
0
1
1
0
1
0
0
0
0
0
0
0
________
Ce n’est pas très utile. Cela peut être pire. Initialisé avec 100, il produit les états 010, 001, et boucle à jamais sur 000. Si la valeur initiale est 111, il se répétera à jamais depuis le début. Il existe quelques travaux sur le calcul de la complexité linéaire du produit de deux R D R L [1652, 728, 1366, 632, 660, 661]. Une construction s’appuyant sur le produit de R D R L dans un corps de caractéristique impaire [315] s’est avérée peu sûre [843].
F
ig
.
17.9 - Un registre à décalage à rétroaction non linéaire (probablement pas sûr)
17.7
Autres algorithmes de chiffrement en continu
17.7
435
Autres algorithmes de chiffrement en continu
Beaucoup d ’autres algorithmes de chiffrement en continu sont apparus dans la littéra ture ça et là. En voici quelques uns.
Générateur de Pless Ce générateur est conçu autour des possibilités des bascules bistables JK [1260]. Il consiste en huit R D R L qui commandent quatre bascules bistables JK. Chaque bascule bistable agit comme un combinateur non linéaire pour deux des R D R L . Pour éviter le problème hé au fait que la connaissance de la sortie d’une bascule identifie à la fois la source et la valeur du codon suivant, à chaque impulsion d’horloge, les sorties de trois des quatre bascules sont ignorées. Les sorties sont ensuite mélangées pour produire le flux de codons final. Cet algorithme a été cryptanalysé par l’attaque indépendante de chacune des quatre bascules [1358]. De plus, combiner des bascules bistables JK est cryptographiquement faible et les générateurs de ce type tombent sous le coup des attaques par corréla tion [1457].
Générateur à base d’automates cellulaires Dans [1611, 1610], Steve W o l f r a m propose d ’utiliser un automate cellulaire unidimensionnel comme G PASCS. Une description du mécanisme des automates cellulaires dépasse le cadre de cet ouvrage mais, en bref, le générateur de W o l f r a m consiste en un vecteur de bits a±, ü2 , ..., ük, —, an et une fonction de mise à jour : a'k ~ ak-\ © (d-k V Ofc+l).
Le bit est extrait d ’une des valeurs ; peu importe laquelle. Le comportement de ce générateur a une apparence aléatoire. Toutefois, il existe une attaque à texte en clair connu contre ce type de générateurs [1060]. Cette attaque marche sur un PC avec des valeurs de n jusqu’à 500 bits. De plus, Paul B a r d e l l a prouvé que la sortie d’un automate cellulaire est identique à la sortie d ’un registre à décalage à rétroaction linéaire, et qu’il n’offrait donc pas plus de sécurité [90].
Générateur 1/p Ce générateur fut proposé et ensuite cryptanalysé dans [200]. Si l’état interne du gé nérateur à l’instant t est donné par x t, alors : xt+i = bx, mod p .
La sortie du générateur est donnée par le bit le moins significatif de x t div p, où « div » est la division entière tronquée. Pour une période maximale, les constantes b et p doivent être choisies telles que p soit premier et b soit une racine primitive modulo p. Mal heureusement, ce générateur n’est pas sûr du tou t3. 3. Notez que pou r b = 2, un R D R R d oté d ’un entier de connexion valant p sortira cette suite de bits dans l’ordre inverse.
Chapitre 17
436
Autres algorithmes de chiffrement en continu
crypt(l) L’algorithme de chiffrement original d ’U N IX, C R Y P T ( l) , est un chiffrement en continu basé sur la même technologie que P E n i g m a . Il utilise un seul tambour de 256 éléments et un réflecteur Le tambour et le réflecteur sont tous deux engendrés à partir de la clef. Cet algorithme est nettement plus simple que P E n i g m a allemand de la Seconde Guerre mondiale et, pour un cryptanalyste doué, il est très facile à casser [1578, 1310]. Un programme U N IX du domaine public, appelé « Crypt Breakers Workbench » (CBW), peut être utilisé pour casser des fichiers chiffrés avec C R Y P T ( l) .
Autres schémas Il existe aussi un générateur basé sur le problème des empilements (voir § 19.2) [1365]. C R Y P T O -L E G G O n’est pas sûr. Joan D a e m e n a développé S u b S t r e a m , J a m et S t e p R i g h t U p [405] ; ils sont trop récents pour être commentés. Beaucoup d’autres algorithmes sont décrits dans la litérature, et davantage encore gardé secrets et incor porés à des équipements.
17.8
Approche par la théorie des systèmes
En pratique, la conception d ’algorithmes de chiffrement en continu ressemble beau coup à la conception d ’algorithmes de chiffrement par blocs. Elle implique davantage de théories mathématiques, mais au bout du compte, un cryptographe propose un algorithme et essaye ensuite de le cryptanalyser. Selon Rainer R u e p p e l , il y a quatre approches différentes de la construction d ’algo rithmes de chiffrement en continu [1363, 1364] : - L’approche par la théorie des systèmes. Elle consiste à s’assurer que chaque conception pose un problème difficile et inconnu au cryptanalyste, en utilisant un ensemble de principes et de critères fondamentaux de conception - L’approche par la théorie de l’information. Il s’agit de masquer le plus possible le texte en clair au cryptanalyste. Peu importe la somme de travail qu’il mettra en jeu, il n’obtiendra jamais une seule solution. L’approche par la théorie de la complexité. Elle consiste à baser le cryptosys tème sur, ou à le rendre équivalent à, un problème connu et difficile tel que la factorisation ou le calcul de logarithmes discrets. - L’approche par recherche de l’aléatoire. Il s’agit de générer un problème trop gros pour être résolu en forçant le cryptanalyste à examiner beaucoup de données inutiles dans ses tentatives de cryptanalyse. Ces approches différent par les hypothèses faites sur les capacités du cryptanalyste, la définition d’une cryptanalyse réussie, et la notion de sécurité. La plupart des re cherches dans ce domaine sont théoriques, mais il existe quelques bons algorithmes de chiffrement en continu parmi ceux qui sont impraticables. L’approche par la théorie des système est celle qui a été utilisée pour tous les al gorithmes de chiffrement en continu décrits précédemment ; elle est à l’origine de la
17.9
Approche par la théorie de la complexité
plupart des algorithmes qui sont réalisables en pratique. Un cryptographe conçoit des générateurs de codons dont on peut tester les propriétés de sécurité— période, distri bution des motifs de bits, complexité linéaire, et ainsi de suite— et non des algorithmes basés sur des théories mathématiques. Le cryptographe essaye aussi plusieurs tech niques cryptographiques contre ces générateurs et s’assure qu’ils leur résistent. Au fil des années, cette approche a abouti à un ensemble de critères de conception pour les algorithmes de chiffrement en continu [1438, 106, 1359, 1259]. R u e p p e l les a étudié dans [1364] où il a détaillé les théories sous-jacentes. - Période longue, pas de répétitions. Critères de complexité linéaire : grande complexité linéaire, profil de complexité linéaire, complexité linéaire locale, et ainsi de suite. - Critères statistiques tels que les distributions idéales de fc-uplets. - Confusion : chaque bit des codons doit provenir d’une transformation complexe de tous les bits de la clef ou de la plupart d ’entre eux. - Diffusion: les redondances dans les sous-structures doivent se dissiper dans les statistiques à grande échelle. - Critères de non linéarité pour les fonctions booléennes comme l’immunité à la corrélation d’ordre m, la distance aux fonctions linéaires, le critère d ’avalanche, et ainsi de suite. Cette liste ne se restreint aux algorithmes conçus avec l’approche par la théorie des systèmes ; elle est valable pour tous les algorithmes de chiffrement en continu. Elle est même valable pour les algorithmes de chiffrement par blocs. Le point important avec l’approche par la théorie des systèmes est que les algorithmes sont conçus pour directement satisfaire ces buts. Le problème majeur avec ces cryptosystèmes est qu’on ne rien prouver à propos de leur sécurité ; il n’a jamais été prouvé que ces critères de conception soient nécessaires ou suffisants à la sécurité. Un générateur de codons peut satisfaire tous ces principes de conception et s’avérer malgré tout peu sûr. Un autre peut s’avérer sûr. Il reste quelque chose de magique dans le procédé. D’un autre côté, casser chacun de ces générateurs de codons constitue un problème différent pour le cryptanalyste. S’il existe assez de générateurs, le cryptanalyste n’a peut être pas intérêt à essayer de casser chacun d’eux. Il obtiendra peut être plus de gloire et de renommée en trouvant de meilleurs moyens de factoriser les grands nombres ou de calculer les logarithmes discrets.
17.9
Approche par la théorie de la com plexité
R u e p p e l a aussi détaillé une approche de la conception d’algorithmes de chiffrement en continu basée sur la théorie de la complexité. Ici, le cryptographe essaie d’utiliser la théorie de la complexité pour prouver que ses générateurs sont sûrs. De ce fait, ces
Chapitre 17
Autres algorithmes de chiffrement en continu
générateurs ont tendance à être plus compliqués, ils sont basés sur le même type de problèmes que nous avons déjà vus pour la cryptographie à clef publique. Et, tout comme la cryptographie à clef publique, ils ont tendance à être lents et peu commodes.
Générateur pseudo-aléatoire de nombres de S h a m i r i r utilise l’algorithme R S A comme générateur pseudo-aléatoire de nombres [1424]. Bien que S h a m i r ait montré que prédire la sortie du générateur pseudo-aléatoire de nombres est équivalent à casser R SA , des biais potentiels dans la sortie ont été dé crits dans [1406, 206].
Sham
Générateur de B l u m - M i c a l i La sécurité de ce générateur dépend de la difficulté de calculer des logarithmes dis crets [206]. Soit g un nombre premier et p un nombre premier impair. Un codon, Xo, démarre le processus : Xi+i — gx' mod p. La sortie du générateur vaut 1 si x l < (p — l)/2 , et 0 sinon. Si p est grand assez pour que le calcul de logarithmes discrets modulo p soit infai sable, alors le générateur est sûr. Des résultats théoriques supplémentaires sont décrits dans [1629, 996, 995, 1247, 896, 808].
RSA Le générateur R SA [36, 37] est une variante de [206], Les paramètres initiaux sont N , le produit de deux grands nombres premiers p et ç, un entier e premier avec (p ~ l ) ( ç —1), et un germe aléatoire Xo inférieur à N : Xi+ 1 = xf modulo N.
La sortie du générateur est le bit le moins significatif de xt. La sécurité de ce générateur est basée sur la difficulté de casser le R SA . Si N est assez grand, alors le générateur est sûr. Vous trouverez d’avantage de théorie dans [1571, 1572, 1573, 34, 358].
Blum Blum Shub Actuellement, le générateur le plus simple et le plus efficace est appelé le générateur B l u m B l u m S h u b d ’après les noms de ses inventeurs. Nous utiliserons l’abréviation BBS, bien que de temps à autre il soit appelé « générateur à résidu quadratique » [200]. La théorie sous-jacente au générateur BBS est liée aux résidus quadratiques modulo n (voir § 11.3). Voici comment il fonctionne: Trouvez deux grands nombres premiers p et g qui soient congrus à 3 modulo 4. Le produit de ces nombres n = p x q est un entier de B l u m . Choisissez un autre entier aléatoire x qui soit premier par rapport à n. Calculez Xo = x 2 modulo n. C ’est le germe du générateur.
17.10
Autres approches à la conception d’algorithmes de chiffrement en continuas9
Maintenant, vous pouvez commencer à calculer des bits. Le ie bit pseudo-aléatoire est le bit le moins significatif de x, où Xi =
modulo n.
La propriété la plus étrange de ce générateur est que vous n’avez pas à calculer tous les i — 1 bits précédents pour obtenir le 2e bit. Si vous connaissez p et q, vous pouvez calculer le ie bit directement : bi est le bit le moins significatif de Xi où Xi = Xq ^ m°duIo ((p i)(«/-i)) moc[
n. Cette propriété signifie que vous pouvez utiliser ce générateur pseudo-aleatoire de bits comme un cryptosystème de chiffrement en continu pour des fichiers à accès aléatoire. La sécurité de ce schéma dépend de la difficulté de factoriser n. Vous pouvez rendre n public, ainsi tout le monde peut engendrer des bits en utilisant le générateur. Toutefois, à moins que les cryptanalystes puissent factoriser n, ils ne pourront jamais prédire la sortie du générateur — même sous la forme d ’affirmations telles que « le bit suivant a 51 % de chances d ’être un 1 ». Il y a mieux, le générateur BBS est imprévisible à gauche et imprévisible à droite. Cela signifie que, étant donné une suite engendrée par le générateur, les cryptanalystes ne peuvent pas prédire le bit suivant ou le bit précèdent de la suite. Sa sécurité n’est pas basée sur un générateur de bits compliqué que personne ne comprend, mais sur les mathématiques sous-jacentes à la factorisation de n. Cet algorithme est lent, mais il existe des améliorations. 11 semble que vous puis siez utiliser plus que le bit le moins significatif de Xi comme bit pseudo-aléatoire. D’après [1571, 1572, 1573, 36, 37], si t est la longueur de x lt les log2 é bits les moins si gnificatifs de x.Lpeuvent être utilisés. Le générateur BBS est relativement lent et n’est, pas utile pour le chiffrement en continu. Toutefois, pour des applications de haute sécurité, telles que la génération de clefs, ce générateur est le meilleur.
17.10
Autres approches à la concep tion d’algorithmes de chiffrement en continu
Dans le cadre de l’approche par la théorie de l’information, le cryptanalyste est supposé disposer de ressources illimitées en temps et en puissance de calcul. Le seul chiffrement en continu qui soit sûr contre ce type d ’adversaire est le masque jetable (voir § 1.5). Pour les besoins de l’illustration, faisons l’hypothèse que les masques sont stockés sur des bandes magnétiques. Deux bandes magnétiques, l’une du côté du chiffrement et l’autre du côté du déchiffrement, porteraient la même suite de codons. Pour chiffrer, on combine simplement par ou exclusif le texte en clair avec les bits sur la bande. Pour déchiffrer, on combine par ou exclusif le texte chiffré avec les bits de l’autre bande identique. Comme les suites de codons sont vraiment aléatoires, vous n ’utilisez jamais deux fois la même suite de codons. Si vous brûlez les bandes après vous en être servi, vous avez le niveau de sécurité parfait4. 4. Note du traducteur : cette technique est parfois appelée « bande à usage unique ».
Chapitre 17
440
Autres algorithmes de chiffrement en continu
Un autre chiffre en continu, développé par Claus S c h n o r r , fait l’hypothèse que le cryptanalyste n’a accès qu’à un nombre limité de bits du texte chiffré [1400]. Les résultats sont fortement théoriques et n’ont pas de valeur pratique, du moins pas encore. Pour plus de détails, consultez [1362, 1645, 1202]. Par un chiffrement en continu rendu aléatoire, le cryptographe essaie de s’assurer que le cryptanalyste a un problème de taille non soluble. L’objectif est d’augmenter le nombre de bits que le cryptanalyste doit manipuler, tout en gardant la clef secrète petite. Cela peut être rendu possible en utilisant une grande chaîne aléatoire publique pour le chiffrement et le déchiffrement. La clef spécifierait quelle partie de la chaîne doit être utilisée pour le chiffrement et le déchiffrement. Le cryptanalyste, qui ne connaît pas la clef, devrait utiliser une attaque exhaustive en parcourant toute la chaîne aléatoire. Le niveau de sécurité de ce type de chiffre peut être exprimé comme le nombre moyen de bits que le cryptanalyste doit examiner avant que les chances de trouver la clef ne soient meilleures que le simple tirage au sort.
Chiffre de Rip
v a n
W
in k le
James M
a s s e y et Ingemar I n g e m a r s s o n ont proposé le chiffre de Rip v a n [566], ainsi appelé parce que le destinataire doit recevoir 2n bits du texte chiffré avant de tenter le déchiffrement5. L’algorithme illustré par la figure 17.10 est facile à réaliser, on peut démontrer qu’il est sûr et il est totalement inutilisable. D ’après M a s s e y : « On peut facilement garantir que le cryptanalyste ennemi aura besoin de
W
in k le
milliers d’années pour casser le chiffre, si quelqu’un est prêt à attendre des millions d’années pour lire le texte en clair. » D ’autres travaux partant de cette idée sont décrits
dans [1579, 757].
Flux de bits aléatoires
Canal
Flux de bits___ du texte en clair
Texte en clair
0-20 ans (Le retard est secret et dépend de la clef)
F
ig .
17.10
Chiffre rendu aléatoire de
-i
(multiplexé)
Retard
■é-
Retard
Chiffre de Rip
D
van
W
in k le
iffie
Whietfield D i f f i e est le premier a avoir présenté ce schéma [1364]. Les données sont formées de 2" chaînes aléatoires. La clef k est une chaîne aléatoire de n bits. Pour chiffrer un message, Alice utilise la ke chaîne aléatoire comme masque jetable. Elle envoie le texte chiffré et les 2" chaînes aléatoires sur 2 n + 1 canaux de communication différents. 5. Note du traducteu r: R ip VAN WlNKLE a dorm i pendant 20 ans.
17.11
Chiffrement en continu en cascade
441
Bernard qui connaît k peut facilement choisir le bon masque jetable pour déchiffrer le message. Estelle n’ a pas d’autre choix que d’examiner toutes les chaînes aléatoires les unes après les autres jusqu’à ce qu’elle trouve le bon masque jetable. Toute attaque doit examiner un nombre de bits moyen de l’ordre de 2n. R u e p p e l fait remarquer qu’en envoyant n chaînes aléatoires au lieu de 2", et en utilisant la clef pour spécifier une combinaison linéaire de ces chaînes, la sécurité est la même.
Chiffre rendu aléatoire de M a u r e r Ueli M a u r e r a décrit un schéma basé sur la combinaison par ou exclusif de plusieurs chaînes de bits aléatoires très longues [1041, 1038, 1037]. La clef est l’ensemble des positions de départ dans chaque chaîne. Il se trouve que la presque totale sécurité de ce schéma est prouvable, en calculant la probabilité de le casser selon la quant ité de mémoire dont dispose l’attaquant. M a u r e r prétend que cela serait viable avec environ 100 chaînes aléatoires de 1020 bits. Numériser la surface entière de la Lune serait une façon d’obtenir autant de bits.
17.11
Chiffrement en continu en cascade
Si la performance n’est pas primordiale, rien n’empêche de choisir plusieurs algorithmes de chiffrement en continu et de les mettre en cascade. Il suffit de combiner par ou exclusif toutes les sorties des générateurs avec le texte en clair pour obtenir le texte chiffré. Si les clefs des générateurs sont indépendantes, le résultat de Ueli M a u r e r (voir § 15.7) implique que la sécurité de la cascade est au moins aussi grande que celle du meilleur algorithme de la cascade. Elle est probablement beaucoup plus sûre que cela. Les algorithmes en continu peuvent aussi être combiné de la même manière que les algorithmes par blocs (voir le chapitre 15). On peut mettre en cascade (voir § 15.7) les algorithmes de chiffrement en continu avec d’autres algorithmes en continu ou aussi avec des algorithmes de chiffrement par blocs. Une idée intelligente consiste à utiliser un algorithme, soit en continu, soit par blocs, pour fréquemment changer la clef d’un algorithme rapide de chiffrement en continu (ou même un algorithme par blocs en mode O F B ). Peu importe la faiblesse de l’algorithme rapide puisqu’un cryptanalyste n’aura jamais beaucoup de texte en clair chiffré avec la même clef. Il faut trouver un compromis entre la taille de l’état interne de l’algorithme rapide (ce qui influe sur la sécurité) et la fréquence avec laquelle vous pouvez vous permettre de changer de clef. Le changement de clef doit être assez rapide ; les algorithmes qui prennent un long moment pour mettre en place la clef ne sont pas adaptés pour ce type d ’application. Le changement de clef devrait être indépendant de l’état interne de l’algorithme rapide.
Chapitre 17
17.12
Autres algorithmes de chiffrement en continu
Choisir un algorithme de chiffrement en continu
S’il y a un enseignement à tirer de l’étude du chiffrement en continu, c’est que de nou velles sortes d ’attaques voient le jour avec une régularité alarmante. Les algorithmes de chiffrement en continu reposent souvent sur de considérables théories mathématiques. Ces théories permettent de prouver des propriétés intéressantes à propos de l’algo rithme, mais aussi de trouver de nouvelles attaques. Je m’inquiète pour les algorithmes à base de R D R L pour cette raison. Je préfère les algorithmes qui suivent davantage les traces des algorithmes de chif frement par blocs: transformations non linéaires, grandes tables-iS1, et ainsi de suite. R C 4 est mon préféré, et SEAL arrive tout de suite derrière. Je serait très intéressé de voir des résultats de cryptanalyse sur mes générateurs combinant des R D R L et des R D R R ; cela semble un domaine très fructueux de recherche à creuser pour trouver de réelles conceptions. Vous pouvez utiliser un algorithme par blocs en mode O FB ou C FB pour obtenir un algorithme de chiffrement en continu. Le tableau 17.3 donne des mesures de vitesse de quelques algorithmes à titre de com paraison.
Tab.
17.3 - Vitesses de chiffrement en continu de quelques algorithmes sur un 486SX ____________________________________________ Algorithme Vitesse de chiffrement (en mégaoctets par seconde) A5 5 P IR E 62 R C4 164 SEAL 381
à 33 MHz
17.13
Génération de plusieurs flux à par tir d’un seul générateur pseudo aléatoire de suites
Si vous avez besoin de chiffrer plusieurs canaux de communication en même temps, dans un multiplexeur par exemple, la solution simple consiste à utiliser un générateur pseudo-aléatoire par canal. Cela pose deux problèmes : c’est coûteux en matériel et il faut synchroniser les différents générateurs. Il serait plus simple d ’utiliser un seul générateur. Une solution consiste à donner une cadence plus rapide à l’horloge du générateur. Si vous voulez trois flux indépendants, opérez trois cycles d’horloge et envoyez 1 bit dans chaque canal. Cette technique marche mais vous risquez d ’avoir du mal à cedencer le générateur aussi vite que vous le voudriez. Par exemple, si vous ne pouvez multiplier la cadence du générateur que par 3, vous ne pourrez créer que trois flux. Un autre moyen
17.13 Génération de plusieurs flux à partir d’un seul générateur pseudo-aléatoire de suites 448 consiste à utiliser le même flux pour tous les canaux avec d’éventuels délais. Mais ce n’est pas sûr. Une idée vraiment intelligente [1496], brevetée par la NSA, est illustrée par la fi gure 17.11. Détournez la sortie de votre générateur favori vers un registre à décalage usuel de m bits. A chaque impulsion d ’horloge, décaler le registre de un bit vers la' droite. Pour chaque flux de sortie, combinez par et le registre avec un vecteur de contrôle de m bits, qui identifie de manière unique ce flux, et combinez alors par ou ex clusif les bits ensembles pour obtenir le bit de sortie de ce flux. Si vous voulez produire plusieurs flux en parallèle, vous avez besoin d ’un vecteur de contrôle et d’un tableau logique de et/ou exclusif par flux.
Générateur
Vecteur de contrôle 2
Vecteur de contrôle 1
Sortie de m bits
Vecteur de contrôle n
1 1 et logique
et logique
et logique
bit à bit
bit à bit
bit à bit
ou exclusif
ou exclusif
ou exclusif
bit à bit
bit à bit
bit à bit
Flux 2
Flux n
v Flux 1
F ig. 17.11 - Générateur de plusieurs flux
Il faut être vigilant sur un point. Si un seul des flux est une combinaison linéaire des autres, alors le système peut être cassé. Mais si vous êtes intelligent, c’est, un moyen sûr et facile de résoudre le problème.
Chapitre 17
444
17.14
Autres algorithmes de chiffrement en continu
Générateurs de suites vraiment aléa toires
Parfois, les générateurs pseudo-aléatoires de suites cryptographiquement sûrs ne sont pas suffisants. Il y a de nombreuses circonstances en cryptographie où vous désirez des nombres vraiment aléatoires. La génération de clefs est un des principaux exemples d ’une telle situation. C ’est bien d ’engendrer des clefs cryptographiques aléatoires à partir d ’un générateur pseudo-aléatoire de suite, mais si un adversaire obtient une copie de ce générateur pseudo-aléatoire de suite et de toute autre information secrète que vous auriez utilisée pour produire les nombres, il peut créer les mêmes clefs et casser votre cryptosystème, quel que soit le niveau de sécurité de votre algorithme. Des suites engendrées par un générateur de suites vraiment aléatoires ne peuvent pas être reproduites. Personne, pas même vous, ne peut reproduire la suite de bits à partir de ces générateurs. Il y a un grand débat philosophique quant à savoir si l’une de ces techniques permet réellement de produire des bits vraiment aléatoires. Je ne vais pas m’attarder sur ce débat. L ’objet qui nous occupe ici est de produire des bits qui aient les mêmes propriétés statistiques que des bits aléatoires et qui ne soient pas reproductibles. L’important concernant n’importe quel générateur aléatoire de suites est qu’il ait été testé. Il existe une littérature abondante à ce sujet. Les tests de caractère aléatoire sont décrits dans [864, 106]. Ueli M a u r e r a montré que tous ces tests peuvent être déduits de tentatives de comprimer la suite [1039, 1040]. Si vous pouvez comprimer une suite aléatoire, alors elle n’est pas vraiment aléatoire. De toute façon, ce que nous avons, c ’est une bonne dose de magie noire. Le point prin cipal est d ’engendrer une suite de bits que votre adversaire ne puisse deviner sans une chance inhabituelle. Cela n’a l’air de rien mais c ’est plus difficile que vous ne le pensez. Je ne peux pas prouver qu’une de ces techniques engendre des bits aléatoires, mais ces techniques produisent des suii.es de bits qui ne peuvent être facilement reproduites. Pour plus de détails, voyez [1378, 1377, 512].
Tables RAND En
1955, à l ’époque où les ordinateurs faisaient seulement leur app arition, la société
R and toires
C
o r p o r a t io n
a publié un livre qu i contenait u n m illio n de chiffres aléa
[1300]. L e u r m éthode est décrite dans le livre: « Les chiffres aléatoires de ce livre ont été produits par mélange aléatoire d ’une table de base engendrée par une roulette électronique. Brièvement, un source d ’impulsions de fréquence aléatoire, fournissant en moyenne 100000 impulsions environ par seconde, était connectée environ une fois par seconde par une impulsion de fréquence constante. Des circuits de normalisation des impulsions passaient les impulsions à travers un compteur binaire à 5 cases En principe, la machine était une roulette à 32 cases qui effectuait, en moyenne, 3000 révolutions environ par essai et qui produisait un nombre par seconde. Un convertisseur binaire décimal était utilisé pour convertir 20 des 32 nombres (les 12 autres étaient ignorés) et ne retenait que le dernier chiffre des nombres de deux chiffres ; ce chiffre final alimentait une
17.14
Générateurs de suites vraiment aléatoires
perforatrice IBM pour produire la table finale de chiffres aléatoires sur cartes perforées. » Le livre décrit ensuite les résultats de divers tests de caractère aléatoire des données. Il suggère également comment utiliser le livre pour trouver un nombre aléatoire : « Les lignes de la table des chiffres sont numérotées de 00000 à 19999. Pour toute utilisation de la table, on doit d’abord trouver une position de départ aléatoire. Une procédure habituelle pour réaliser ceci consiste à ouvrir le livre à une page non utilisée de la table de chiffres et choisir en aveugle un nombre de 5 chiffres ; avec le premier chiffre réduit modulo 2 ce nombre détermine la ligne de départ ; les deux chiffres à droite du nombre de 5 chiffres initialement sélectionné sont réduits modulo 50 pour déterminer la colonne de départ parmi la ligne sélectionnée. Pour se prémunir de la tendance qu’ont les livres de toujours s’ouvrir à la même page et de la tendance naturelle qu’ont, les gens de choisir un nombre près du centre de la page, chaque nombre de 5 chiffres utilisé pour déterminer une position de départ doit être marqué afin de ne pas être utilisé une deuxième fois à cette fin. » La matière principale du livre est la table de chiffres aléatoires. Elle les énumère par groupe de 5 chiffres — « 10097 32533 76520 13586 . . . » — à raison de 50 par ligne et de 50 lignes par page. La table continue ainsi sur 400 pages, ce qui, excepté pour une section particulièrement osée à la page 283 qui indique « 69696 », s’avère d’une lecture particulièrement ennuyeuse. Le livre comprend également une table des 100 000 écarts types. Ce qui est intéressant à propos de la table R A N D n’est pas qu’elle contienne un million de chiffres aléatoires, mais qu’elle a été créée avant la révolution informatique. De nombreux algorithmes cryptographiques utilisent des constantes arbitraires — aussi appelées « n o m b r e s m a g i q u e s ». Choisir les nombres magiques à partir de la table RAND garantit qu’ils n’ont pas été choisis pour quelque raison cachée. Par exemple, K h a f r e se sert de la table R A N D .
Utilisation de bruit aléatoire Le meilleur moyen de collecter un grand nombre de bits aléatoires est de se raccorder sur le caractère aléatoire naturel du monde réel. Cette méthode nécessite la plupart du temps du matériel spécialisé, mais il y a des techniques que vous pouvez employer avec les ordinateurs. Trouvez un événement qui a lieu souvent mais aléatoirement : le bruit atmosphérique dépassant un certain niveau, les chutes d’un bambin qui apprend à marcher, etc. Mesurez l’intervalle de temps entre un événement et le suivant. Enregistrez-le. Mesurez l’intervalle de temps entre ce second événement et le troisième. Enregistrez-le égale ment. Si le premier intervalle de temps est plus grand que le second, produisez un 1 comme bit aléatoire. Si le second intervalle de temps enregistré est plus grand que le premier, produisez un 0 comme bit aléatoire. Continuez ainsi pour le bit suivant. Lancez une fléchette sur le journal de votre choix. Comparez la lettre la plus proche de la pointe et la lettre qui précède celle-là. Produisez un 1 si la première suit 1a deuxième dans l’ordre alphabétique, et un 0 sinon.
Chapitre 17
Autres algorithmes de chiffrement en continu
Branchez un compteur Geiger à votre ordinateur, comptez le nombre d ’émissions pro duites durant un intervalle de temps fixé et gardez le dernier bit significatif. Ou encore, mesurez le temps entre deux émissions. (Comme la source radioactive se consume, le temps moyen entre deux émissions s’allonge continuellement. Si vous voulez une source de durée de vie suffisante, prenez le plutonium. Si vous craignez pour votre santé, vous pouvez faire les corrections statistiques appropriées.) G.B. A g n e w a proposé un vrai générateur aléatoire de bits adapté à l’intégration dans une puce VLSI [25]. C ’est une capacité à semi-conducteurs (M ISC pour « Métal Insulator Semiconduction Capacitor »). Deux d’entre elles sont placées à proximité l’une de l’autre et le bit aléatoire est une fonction de la différence de charge entre les deux. Un autre générateur aléatoire de nombre en technologie LSI engendre un flux de bits aléatoires basé sur des instabilités de fréquence d ’un oscillateur en boucle ouverte [537]. Une puce commercialisée par A T & T engendre des nombres aléatoires à partir du même phénomène [73]. M. G u d e a construit un générateur aléatoire de nombres qui collecte des bits aléatoires à partir de phénomènes physiques tels que la décroissance radioactive [669, 670]. Manfield R i c h t e r a développé un générateur de nombres aléatoires basé sur le bruit thermique d ’une diode semiconductrice [1320]. Il paraît que l’interval de temps entre deux émissions lumineuses d’un atome de mercure piégé seraient aléatoires. Exploitez cela. Mieux vaut finalement trouver une société de semi-conducteurs qui fabrique des puces générant des nombres aléatoires ; elles existent. Il y a aussi un générateur de nombres aléatoires qui utilise le disque dur de l’ordinateur [439]. Le générateur mesure le temps nécessaire pour lire un bloc du disque et utilise la variabilité de ce temps comme source de nombres aléatoires. Il filtre les données pour enlever les structures provenant de la quantification, puis effectue une transformée de Fourrier à des vecteurs de nombres. Ceci retire le biais et la corrélation. Finalement il tire les bits aléatoires grâce à des fréquences spectrale entre 0 et n normalisées à l’intervalle de temps unitaire. Une grande part des variations de la vitesse de rotation du disque étant due aux turbulences de l’air, il y a donc un caractère aléatoire propre au système. Il y a pourtant des points noirs. Si vous gardez trop de bits de la sortie, vous utilisez la transformation de Fourrier comme générateur, ce qui risque d ’être prévisble. Et il vaut mieux toujours lire le même bloc du disque pour éviter au filtrage d’avoir à retirer les structures provenant du gestionnaire de disque. Une réalisation de ce système permet de produire environ 100 bits par minute [439].
Utilisation de l’horloge de l’ordinateur Si vous avez besoin d’un seul bit aléatoire (ou de quelques-uns), prenez le bit le moins significatif de n’importe quel registre d ’horloge. Sur un système U N IX, cela peut ne pas être tellement aléatoire à cause de différentes synchronisations potentielles mais cela marchera bien sur un ordinateur personnel. Évitez d’obtenir trop de bits de cette façon : utiliser la même routine plusieurs fois de suite peut facilement biaiser les bits engendrés de cette manière. Par exemple, si chaque exécution de la routine de génération de bit utilise un nombre pair de clics d’horloge, vous obtiendrez une suite infinie de la même valeur de bit de ce générateur. Si chaque exécution nécessite un nombre impair de clics d’horloge, vous obtiendrez une suite infinie de valeurs alternantes de ce générateur. Même si la résonance n’est pas aussi simpliste, le flux de bits résultant sera loin d ’être aléatoire.
17.14
Générateurs de suites vraiment aléatoires
Il existe un générateur de nombres aléatoires fonctionnant de la manière suivante [929] : « Notre générateur de nombres vraiment aléatoires... fonctionne en réglant une alarme et en incrémentant rapidement un compteur dans un registre du microprocesseur jusqu’à l’arrivée d’une interruption. Le contenu du registre est alors combiné par ou exclusif avec un tampon de sortie de un octet (en tronquant ainsi les données du registre à 8 bits). Une fois que le tampon de sortie est rempli, il subit un décalage circulaire vers la droite de 2 bits, ce qui a pour effet de pousser les bits les plus actifs (et aléatoires) de poids faible vers les positions de poids fort. Le procédé entier est répété trois fois. A la fin, chaque bit du tampon a touché un des deux bits les plus aléatoires du registre après interruption. On obtiendra donc n octets aléatoires au bout de 4n interruptions. » Cette méthode est très sensible au caractère aléatoire des interruptions système et à la granularité de l’horloge. La sortie faisait bonne figure au cours de tests sur de réelles machines UNIX.
Mesure de caractéristiques de la vitesse de frappe Les rythmes de frappe au clavier des gens sont aléatoires et en même temps ne le sont pas. Ils possèdent assez d’information pour permettre l’identification, mais ils sont assez aléatoires pour générer des bits aléatoires. Mesurez le temps entre deux frappes de touche successives et prenez ensuite le bit le moins significatif de ces mesures. Cette technique pourrait ne pas marcher sur des terminaux U N IX, parce que les touches utilisées passent à travers toute une série de filtres avant d’atteindre votre programme. Mais elle est adéquate pour les ordinateurs personnels. Idéalement, vous ne devriez collecter qu’un bit aléatoire par touche. En collecter plus pourrait biaiser le résultat en fonction des talents de dactylo de celui qui est au clavier. Toutefois, cette technique est limitée. Bien qu’il soit facile de demander à quelqu’un d’entrer une centaine de mots quand il est temps d ’engendrer une clef, il n’est pas raisonnable de lui demander de taper un roman de 100000 mots pour engendrer un flux de codons pour un masque jetable.
Biais et corrélations Le défaut majeur de tous ces systèmes est qu’il peut y avoir des corrélations et des biais dans les suites engendrées. Le processus physique sous-jacent peut être aléatoire mais il y a de nombreux instruments de mesures entre la partie numérique de l'ordinateur et le dispositif physique. Ces instruments peuvent facilement introduire des biais et des corrélations. Un moyen d’éüminer ce biais est de combiner par ou exclusif plusieurs bits ensemble. Si un bit aléatoire a un biais e en faveur de 0, alors la probabilité du résultat 0 peut être écrite : P ( 0) = 0,5 + e. Combiner par ou exclusif deux de ces bits donne : P(Q) = (0,5 + e)2 + (0,5 - e)2 = 0,5 + 2 x e2.
Chapitre 17
Autres algorithmes de chiffrement en continu
Par le même type de calcul, la combinaison par ou exclusif de 4 bits ddonne : P ( 0) = 0,5 + 8 x e4.
Combiner par ou exclusif m bits convergera exponentiellement vers une probabilité égale de 0 et de 1. Une bien meilleure méthode consiste à retirer tout biais de la source aléatoire. Analysez les paires de bits. Si deux bits sont identiques, jetez-les et analysez la paire suivante. Si les deux bits sont différents, prenez le premier bit comme sortie du générateur. Ceci élimine complètement le biais. D ’autres techniques de réduction du biais reposent sur la compression de données, et les transformées de Fourrier [512], Le défaut potentiel de ces deux méthodes est que s’il y a une c o r r é l a t i o n entre bits adjacents, alors ces méthodes augmentent le biais. Un moyen de corriger cela est d’uti liser plusieurs sources aléatoires. Prenez quatre sources aléatoires et combinez par ou exclusif les bits ; ou prenez deux sources aléatoires et analysez les bits par paires. Par exemple, prenez une source radioactive et branchez un compteur G ei GER à votre ordinateur. Prenez une paire de diodes « bruyantes » et enregistrez un événement chaque fois que le bruit dépasse un certain seuil. Mesurez le bruit atmosphérique. Prenez un bit aléatoire de char-une des sources et combinez-les par ou exclusif pour produire le bit aléatoire. Les possibilités sont infinies. Le simple fait qu’un générateur aléatoire soit biaisé ne le rend pas nécessairement inutilisable. Cela veut seulement dire qu’il est moins sûr. Par exemple, Alice veut engendrer une clef de 112 bits pour le DES T R I P L E , en disposant uniquement d’un générateur avec un biais vers 0 : il produit 55 % de 0 et 45 % de 1. Cela signifie qu’il n’y a que 0,99277 bit d’entropie par bit de la clef, au lieu de 1 bit si le générateur était parfait. Martin, qui essaie de casser la clef, peut optimiser son attaque exhaustive pour essayer la clef la plus probable en premier lieu ( 0 0 0 ... 0) et continuer ainsi vers la clef la moins probable ( 1 1 1 ... l). A cause du biais, Martin peut espérer trouver la clef en 2109 tentatives. S’il n’y avait pas de biais, Martin devrait s’attendre à faire 2111 tentatives. La clef résultante est moins sûre, mais pas de façon appréciable. *
Epuration du caractère aléatoire En général, le meilleur moyen de générer des nombres aléatoires est de se trouver un grand nombre d ’événements apparemment aléatoires et d’en extraire le caractère aléa toire. Les fonctions de hachage sont faites pour cela ; elles sont rapides et traiteront une grande quantité de données avant de faire baisser les performances, tout en améliorant le caractère aléatoire de vos observations. Passez par des fonctions de hachage tout ce qui vous passe sous la main et qui soit un peu aléatoire. Essayez entre autres : - une copie de chaque touche frappée, les commandes de la souris, - le numéro de secteur, la date du jour, et la latence de recherche pour opération sur le disque, - la position courante de la souris, - le numéro de la ligne courante de balayage du moniteur,
17.14
Générateurs de suites vraiment aléatoires
449
- le contenu de l’image affichée, - le contenu de la table d’allocation des fichiers (FA T), des tables du noyau, etc., - les temps d ’accès et de modification du fichier /d e v /t t y , - la charge du processeur, - le temps d’arrivée des paquets du réseau, - l’entrée d ’un microphone, - le contenu du fichier /d e v /a u d io sans micro branché. Si votre système utilise des oscillateurs à quartz différents pour le microprocesseur et l’horloge, essayez de lire la date du jour dans une boucle serrée. Sur certains sys tème (mais pas tous), cela reflétera le tremblement aléatoire de phase entre les deux oscillateurs. Comme le caractère aléatoire de la plupart de ces événements provient de datations, utilisez l’horloge la plus précise possible. Un P C standard utilise une puce d ’horloge Intel 8254 (ou une équivalente) cadencée à 1,1931818 MHz; aussi la lecture directe du compteur vous donne une précision de 838 nanosecondes. Pour ne pas fausser les résultats, évitez d’échantillonner lors d’une interruption. Voici le code en C avec M D 5 (voir § 18.5) comme fonction de hachage : char c h a ineAleat[16]; /* Appelez souvent la fonction suivante sur une variété d ’événements * aléatoires ou pseudo-aléatoires pour brasser la chaîne aléatoire. * L a forme exacte et la longueur de evenAleat n ’importe pas du * moment que son contenu soit un tant soit peu imprévisible.
*/ void b rasserAleat(char *evenAleat, unsigned int evenLong)
f MD5_CTX md5; M D5Init(&md5); MD5MiseAJour(&md5,chaineAleat,siezof(chaineAleat)); MD5MiseAJour(&md5,evenAleat,evenLong); MD5Final(chaineAleat,&md5);
} Après suffisamment d’appels à bra sserA lea t () pour que chaineA leat soit assez aléa toire, vous pouvez en tirer des bits aléatoires. Pour cela, M D 5 nous sert à nouveau, cette fois comme générateur d’octets pseudo-aléatoires en mode compteur. long comptAleat; void genAleat(char *buf, unsigned int longbuf)
f MD5_CTX md5; char t m p [16]; unsigned int n; while(longbuf
!= 0) {
Chapitre 17
450 /*
Autres algorithmes de chiffrement en continu
Passer la chaîne aléatoire dans la fonction de hachage
* avec un compteur.
*/ M D5Init(&md5); MD5MiseAJour(&md5,chaineAleat,siezof(chaineAleat)); MD5MiseAJour(&md5,(unsigned char *)&comptAleat, siezof(comptAleat)); MD5Final(tmp,&md5); comptAleat++; /* Incrémenter le compteur */ /* Copier 16 octets,
ou la quantité requise, mais moins
* que le contenu du tampon de l ’utilisateur.
*/ n = (longbuf < 16) ? longbuf
: 16;
m e m c py(buf,t m p ,n ) ; buf += n; longbuf -= n;
> > La fonction de hachage est ici cruciale pour plusieurs raisons. Elle permet tout d ’abord de générer facilement une quantité arbitraire de données pseudo-aléatoires sans devoir appeler brasserAleat () à chaque fois. Dans les faits, le système se passe élégamment de l’aléatoire parfait à l’aléatoire pratique quand la demande dépasse l’offre. Dans ce cas, il devient théoriquement possible d ’utiliser le résultat d’un appel à genAleatO pour déterminer le résultat de l’appel suivant ou précédent. Mais cela exige d’inverser M D 5, ce qui n’est pas faisable en pratique. Ceci est important car la procédure ignore ce qu’il adviendra du résultat de chaque appel, il se peut qu’un appel serve à générer un nombre aléatoire pour un protocole qui l’enverra en clair, par exemple en réponse à une requête d ’un attaquant. L ’appel suivant peut servir dans une session sans rapport que l’attaquant essaye de pénétrer. Il est clairement important qu’un attaquant ne puisse déduire le résultat d’un appel d ’aucun autre. Il reste un problème. chaineAleat [] doit être suffisament aléatoire avant le premier appel à genAleatO. Si le système a fonctionné quelque temps avec un utilisateur au clavier, il n’y a pas de problème. Mais qu’en est-il d ’un système automatique qui se réinitialise tout seul sans qu’aucune commande au clavier ou à la souris n ’advienne? Ce problème est difficile. Une solution partielle consiste à faire taper au clavier un moment l’utilisateur après la toute première mise en route de la machine et d’en créer un fichier de germes germeAleat [] à utiliser à chaque initialisation de la machine. Mais ne sauver pas sur disque germeAleat [] directement. Un attaquant qui copierait se fichier pourrait déterminer tous les résultats générés par genAleatO après la création du fichier jusqu’au premier appel à brasserAleat (). Pour résoudre ce problème, il faut appliquer la fonction de hachage à germeAleat [] juste avant de le sauver. Quand le système se réinitialise, il charge le fichier de germes, le passe à brasserAleat ( ) et le détruit aussitôt. Malheureusement, il reste la menace du vol du fichier de germes entre la réinitialisation et sa destruction, et son utilisation pour deviner les résultats des futurs appels à genAleatO. Je ne vois pas d’autre solution à ce problème que d’attendre l’arrivée d’événements aléatoires extérieurs après
17.H
Générateurs de suites vraiment aléatoires
la réinitialisation avant d’autoriser des appels à genAleatO.
451
Chapitre 18
Fonctions de hachage à sens unique 18.1
Introduction
Une fonction de hachage à sens unique, H (A i), opère sur un message A i de longueur arbitraire. Elle fournit une valeur de hachage de longueur fixe h. h = H (Ai), où h est de longueur m.
Il existe de nombreuses fonctions qui prennent une entrée de longueur arbitraire et qui fournissent une sortie de longueur fixe, mais les fonctions de hachage à sens unique ont les caractéristiques additionnelles suivantes : Étant donné A i, il est facile de calculer h. Étant donné h, il est difficile de calculer A i. Étant donné A i, il est difficile de trouver un autre message A i' tel que H ( M ) = H (M '). Si Martin pouvait effectuer la partie difficile, cela minerait la sécurité de tout protocole utilisant la fonction de hachage à sens unique. L ’essence même des fonctions de hachage est de fourinir une « empreinte » de A i qui soit unique. Si Alice signait A i en utilisant un algorithme de signature numérique sur H (A i), et si Bernard pouvait produire un Ai' tel que H (A i) = H (Ai'), alors Bernard pourrait prétendre qu’Alice a signé A i'. Dans certaines applications il ne suffit pas que la fonction soit à sens unique ; il faut de plus qu’elle est ait une propriété appelée résistan ce à la collision : Il est difficile de trouver deux messages aléatoires A i et A4' tels que H (A l) = H (A i'). Vous vous rappelez de l’attaque des anniversaires du paragraphe 7.4. Elle ne consiste pas à trouver un autre message A i' tel que I I (A4') = II(A i), mais à trouver deux messages aléatoires A4 et A i' tels que H (A i) — H (A i1).
Chapitre 18
Fonctions de hachage à sens unique
Le protocole suivant, décrit pour la première fois par Gideon Y u v a l [1637], montre comment Alice peut utiliser l’attaque des anniversaires pour duper Bernard si la pro priété supplémentaire n’était pas vérifiée. 1° Alice prépare deux versions d’un contrat, l’une favorable à Bernard, et l’autre qui lui fait faire ce que bon lui semble.
2° Alice apporte des modifications subtiles à chaque document et calcule l’em preinte de chacun L 3° Alice compare les valeurs des ensembles d’empreintes pour chacun des deux documents, pour rechercher une paire qui concorde2. Elle reconstruit les deux documents qui ont la même empreinte.
4° Alice fait signer par Bernard la version du contrat qui lui est favorable en utilisant un protocole où il signe seulement l'empreinte.
5° Plus tard, Alice remplace le contrat signé par Bernard par celui qu’il n’a pas signé. Maintenant elle peut convaincre un juge que Bernard a signé cet autre contrat.
C’est un problème sérieux. (La morale de cette histoire est de toujours faire un petit changement à un document que vous signez.) Il existe des attaques similaires qui peuvent être montées en faisant l’hypothèse d’une attaque des anniversaires réussie. Par exemple, les adversaires peuvent envoyer à un système de contrôle automatique (d’un satellite, peut-être) des messages aléatoires avec des signatures aléatoires. Finalement, l’un de ces messages aléatoires aura une signature valide. Les adversaires n’auraient aucune idée de ce que la commande ferait, mais si leur seul but consistait à fausser le satellite, cela réussirait.
Longueur des empreintes Des fonctions de hachage à sens unique à 64 bits sont juste trop petites pour survivre à une attaque des anniversaires. La plupart des fonctions de hachage à sens unique pratiques produisent des empreintes de 128 bits. Cela oblige toute personne qui essaie l’attaque des anniversaires à calculer 264 empreintes de documents aléatoires pour en trouver deux qui aient la même empreinte. Le N IST, dans son standard de hachage sûr (SHS pour « Secure Hash Standard »), utilise des empreintes de 160 bits. Cela rend l’attaque des anniversaires encore plus difficile, nécessitant le calcul de 280 empreintes aléatoirement. Pour engendrer une empreinte plus longue que le produit de la fonction de hachage, la méthode suivante a été proposée : 1° Engendrez l’empreinte d’un message en utilisant une fonction de hachage à sens unique reprise dans cet ouvrage.
2° Joignez l’empreinte au message. 1. L es c h a n g e m e n ts p e u v e n t co n s is te r à : re m p la ce r u n e s p a c e p a r la c o m b in a is o n « e sp a ce—re to u r en a r r iè re -e sp a ce » , r a jo u te r un o u d e u x e sp a ces avan t les « aller à la lig n e », e tc . E n faisant o u n e fa isan t p as un seul c h a n g e m e n t p arm i 3 2 lignes, A lic e p e u t fa cilem en t en g en d rer 2 32 d o cu m e n ts d ifférents. 2. Si la fo n c t io n d e h a ch ag e p r o d u it des valeurs d e 64 b it s seu lem en t, elle p o u r ra it év en tu ellem en t tro u v e r une p a ire c o n c o r d a n te a v e c 2 32 v ersion s d e ch a q u e d o cu m e n t.
18.2
455
Snefru
3° Engendrez l’empreinte de la jointure du message et de l ’empreinte du message. 4° Créez une grande empreinte constituée de l’empreinte engendrée à l’étape 1 jointe à l’empreinte engendrée à l’étape 3.
5° Répétez les étapes 1 à 3 autant de fois que vous le voulez. Bien que cette méthode n ’ait jamais été prouvée sûre ou non sûre, plusieurs personnes émettent de sérieuses réserves à son propos [1273, 859].
Survol des fonctions de hachage à sens unique Il n’est pas facile de concevoir une fonction qui prenne en entrée un paramètre de longueur variable, et de la rendre à sens unique. Dans la réalité, les fonctions de hachage à sens unique sont inspirées des fo n ctio n s d e com p ression . Ces fonctions qui sont à sens unique, produisent une valeur de longueur n, à partir d ’une entrée de longueur m supérieure à n [1076, 416]. L’entrée de la fonction de compression est un bloc de texte et l’empreinte du bloc précédent (voir la figure 18.1). La sortie est l’empreinte de tous les blocs jusqu’à ce point. C ’est-à-dire que l’empreinte du bloc M.i est donnée par : K =
L’empreinte en cours et le bloc de texte suivant servent de paramètre à l’application suivante de la fonction de compression. L’empreinte du dernier bloc devient l’empreinte de tout le message. M “ i-l
kr
'
Fonction de hachage à sens unique
► hi
F ig. 18.1 - Fonction de hachage à sens unique Le message d ’entrée devrait contenir sous une certaine forme la représentation binaire de la longueur du message en entier. Cette technique prévient un problème de sécurité éventuel, qui résulterait de messages de longueurs différentes pouvant avoir la même empreinte [1076, 416]. Cette technique est parfois appelée ren forcem en t-M D [941], Différents chercheurs ont conjecturé que si une fonction à sens unique est sûre pour un seul bloc, alors cette méthode de hachage d’une suite de longueur quelconque de blocs est aussi sûre, mais rien n’a été prouvé [1147, 1075, 416]. On a beaucoup écrit à propos des fonctions de hachage à sens unique. Pour plus d’indications mathématiques consultez [1033, 793, 791, 1147, 1076, 416, 98, 858, 1275]. La thèse de doctorat de Bart P R E N E E L [1273] est probablement l’exposé le plus complet concernant les fonctions de hachage à sens unique.
18.2 Sn e f r u 3
Snefru est une fonction de hachage à sens unique conçue par Ralph
3. Snefru, à l’ instar de Khufu et Khafre, est un des pharaons d ’Egypte.
M
erkle
[1075].
456
Chapitre 18
S n e f r u calcule des em preintes de
Fonctions de hachage à sens unique
128 ou 256 b its po ur des messages de longueur
arbitraire.
Au départ, le message est découpé en morceaux de (512 — m) bits chacun (m est la longueur de l’empreinte). Si l’empreinte calculée a 128 bits les morceaux sont longs de 384 bits ; si l’empreinte a 256 bits, les morceaux ont 256 bits. Le cœur de l’algorithme est une fonction H qui hache une valeur de 512 bits en une valeur de m bits. La fonction H a été conçue pour qu’il soit facile de calculer l’empreinte d ’une entrée mais qu’il soit impossible en pratique de calculer une entrée qui a une empreinte spécifique. Les m premiers bits de la sortie de H forment l’empreinte du bloc ; le reste est inutilisé. Le bloc suivant est joint à l’empreinte du bloc précédent et haché à nouveau. Le bloc initial est joint à une suite de 0. Après le dernier bloc (si le message n ’a pas une longueur multiple de la taille de bloc, le dernier bloc est complété par une suite de 0), les m premiers bits sont joints à la représentation binaire de la longueur du message et hachés une fois de plus. La fonction H est basée sur une autre fonction E qui est une fonction de chiffrement par bloc réversible qui opère sur des blocs de 512 bits. La valeur de H est donnée par les m derniers bits de la sortie de E combinés par ou exclusif avec les m premiers bits de la sortie de E. La sécurité de S n e f r u dépend de la fonction E qui rend aléatoires les données en plusieurs passes. Chaque passe est composée de 64 rondes de brouillage. Dans chaque ronde, un octet différent des données est utilisé comme entrée d ’une table 5 ; le mot de sortie de la table-5' est combiné par ou exclusif avec les deux mots voisins du message. Les tables-5 sont construites d ’une manière similaire à celles de K h a f r e . Il y a également quelques rotations. A l’origine, S n e f r u était conçu avec deux passes.
Cryptanalyse de Snefru En utilisant la cryptanalyse différentielle, B i h a m et S h a m i r ont prouvé que S n e f r u à 128 bits et à deux passes n’était pas sûr [178]. Leur attaque trouve les paires de messages qui ont la même empreinte en quelques minutes. Pour S n e f r u à 1 2 8 bits, leur attaque est plus efficace que la recherche exhaustive pour quatre passes ou moins. Une attaque des anniversaires contre S n e f r u requiert 264 opérations ; la cryptanalyse différentielle peut trouver une paire de messages ayant la même empreinte en 2 28,5 opérations pour un S n e f r u à trois passes et en 2 44,5 opé rations pour un S n e f r u à quatre passes. Trouver un message ayant une empreinte donnée par recherche exhaustive nécessite 2128 opérations ; la cryptanalyse différen tielle requiert 2 56 opérations pour un S n e f r u à trois passes et 2 88 opérations pour un S n e f r u à quatre passes. Bien que B i h a m et S h a m i r n’aient pas considéré les empreintes à 256 bits, ils éten dirent leur analyse à des empreintes de 224 bits. Par comparaison avec l’attaque des anniversaires, qui requiert 2112 opérations, ils peuvent trouver des messages avec la même empreinte en 212-5 opérations pour un S n e f r u à deux passes, 233 opérations pour un S n e f r u à trois passes et 288 opérations pour un S n e f r u à quatre passes. Actuellement, M e r k l e recommande d’utiliser S n e f r u avec au moins huit passes [1079]. Toutefois, avec autant de passes, l’algorithme est nettement plus lent que M D5 et SHA.
18.3
N - H ash
18.3
457
N—Hash
est un algorithme inventé par des chercheurs de la N i p p o n T é l é p h o n é a n d , les mêmes que ceux qui ont inventé F E A L en 1990 [1111, 1112]. N - H a s h utilise des blocs de message de 128 bits, une fonction de brouillage compliquée similaire à celle de F E A L et produit des empreintes de 128 bits. L’empreinte de chaque bloc de 128 bits est une fonction du bloc et de l’empreinte du bloc précédent : N -H
T
ash
eleg raph
ho = / , où I est une valeur initiale quelconque h i - g ( M i ,h i 1 ) © M , © h i_i.
L’empreinte du message entier est l’empreinte du dernier bloc La valeur initiale quel conque I peut être n’ importe quelle valeur choisie par l'utilisateur (même tous des 0). La fonction g est une fonction compliquée. La figure 18.2 donne un aperçu de l’algo rithme. Au départ, les 64 bits de gauche et les 64 bits de droite de l’empreinte de 128 bits du bloc précédent du message hi- 1 sont échangés; les deux moitiés sont ensuite combinées par ou exclusif avec 1010___ 1010 (sur 128 bits) en binaire et ensuite com binées par ou exclusif avec le bloc courant du message A4 j. Cette valeur passe alors dans N étapes (N — 8 pour les figures) de traitement. L ’autre entrée d ’une étape de traitement est la valeur de l’empreinte précédente combinée par ou exclusif avec une constante binaire parmi huit. Une étape de traitement est illustrée par la figure 18.3. Le bloc de message est coupé en quatre valeurs de 32 bits. L ’empreinte précédente est coupée également en quatre valeurs de 32 bits. La fonction f est donnée par la figure 18.4. Les fonctions So et ,S'i sont les mêmes que pour FE A L : S'ü(c.,b) = décalage circulaire à gauche de 2 bits de ((a + b) mod 256)
5i(a,6) = décalage circulaire à gauche de 2 bits de ((a + 6 + 1 ) mod 256). La sortie d ’une étape de traitement devient l’entrée de l’étape de traitement suivante. Après la dernière étape de traitement, la sortie est combinée par ou exclusif avec A4, et 6 j_ i, et ensuite le bloc suivant est prêt à être haché.
Cryptanalyse de N—Hash Bert DEN B o e r a découvert un moyen de provoquer des collisions dans la fonction de ronde de N- H a s h [1273]. BlHAM et S h a m i r ont utilisé la cryptanalyse différentielle pour casser N - H a s ii à 6 rondes [176, 178]. Leur attaque particulière (il y en a certai nement d’autres) marche pour n’importe quel N qui est divisible par 3, et elle est plus efficace que l’attaque des anniversaires pour tout N inférieur à 15. La même attaque permet de trouver des paires de messages qui ont la même empreinte pour N- H a SII à 12 rondes en 256 opérations au lieu des 264 opérations nécessaires pour une attaque exhaustive. N H a s h à 15 rondes n’est pas vulnérable à la cryptanalyse différentielle qui requiert dans ce cas 272 opérations. Les concepteurs de l’algorithme recommandent d’utiliser N H a s h avec au moins 8 rondes [1112]. Étant donné le peu de sûreté de N - H a s h et de FE A L (et étant donné sa lenteur avec 8 rondes), je conseille d’ utiliser un autre algorithme.
458
Chapitre 18
Fonctions de hachage à sens unique
F i g . 18.2 - Aperçu de N - H ash
18.4
M D4
M D 4 est une fonction de hachage à sens unique conçue par Ron R iv e s t [1329, 1330, 1331]. L ’acronyme « MD » vient de « Message Digest » et l’algorithme produit des empreintes de 128 bits du message d’entrée.
Dans [1330], R iv e s t décrit les objectifs de conception pour l’algorithme: Sécurité. Il est impossible de trouver par le calcul deux messages qui aient la même empreinte. Aucune attaque n’est plus efficace que l’attaque exhaustive. Sécurité directe. La sécurité de M D 4 n’est basée sur aucune hypothèse, telle que la difficulté de la factorisation. Vitesse. M D 4 est adapté pour des réalisations logicielles rapides. Il est
18-4
459
MD4
F ig. 18.3 - Une étape de traitement de N H A SU
basé sur un ensemble de manipulations de bits sur des opérandes de 32 bits.
Simplicité et compacité. MD4 est aussi simple que possible sans grandes structures de données ni programme compliqué. Favorise les architectures « à octet de poids faible en premier ». MD4 est optimisé pour les architectures à microprocesseurs (spécifiquement les processeurs I n t e l ) ; des ordinateurs plus grands et plus rapides feront les transformations nécessaires.
Après que l’algorithme ait été présenté pour la première fois, Bert DEN BOER et Antoon B o sselaers ont cryptanalysé avec succès les deux dernières des trois rondes de l’algo rithme [459]. Ralph M e r k l e a attaqué avec succès les deux premières rondes [459]. Eli B iham décrit une attaque par cryptanalyse différentielle possible contre deux tiers de MD4 [166]. Bien que ces attaques ne puissent pas être étendues à l’algorithme complet, R iv est a renforcé l’algorithme. Le résultat est M D5.
460
Chapitre 18
Fonctions de hachage à sens unique
X
fU p )
S0( X ,, X 2 ) = rot2((X , + X 2 ) mod 256) 5, (X l, X 2) = rot 2((X , + X 2 + 1 ) mod 256) X, et X 2 : entrées de 8 bits
S0 et 5, : résultats de 8 bits rot 2 (7 ’) : décalage circulaire à gauche de 2 bits de T
F ig. 18.4 - Fonction f
18.5
M D5
M D5 est une version améliorée de M D 4 [1391, 1332]. Bien que plus complexe, il est similaire de conception et il produit également des empreintes de 128 bits.
Description de M D5 Après un traitement initial, M D5 manipule le texte d ’entrée par blocs de 512 bits divisés en 16 sous-blocs de 32 bits. La sortie de l’algorithme est un ensemble de 4 blocs de 32 bits qui, joints ensemble, forment une seule empreinte de 128 bits. Tout d ’abord le message est complété de manière à ce que 64 bits de plus amèneraient sa longueur à un multiple de 512. Ce remplissage se fait avec un seul 1 rajouté à la fin du message suivi d ’autant de 0 que nécessaire. Ensuite, une représentation de 64 bits de la longueur totale du message (avant que le remplissage ne soit effectué) est jointe au résultat. Ces deux étapes servent à rendre la longueur du message multiple de 512 bits (ce qui est nécessaire pour la suite de l’algorithme), tout en s’assurant que des messages différents n’auront pas l’air similaires après le remplissage. Quatre variables de 32 bits sont initialisées : A = 0x01234567
18.5
461
MD5
B = 0x89ABCDEF C = 0xFEDCBA98 D = 0x76543210.
On les appelle « variables de chaînage ». Maintenant, la boucle principale de l’algorithme commence. Cette boucle est effectuée autant de fois qu’il y a de blocs de 512 bits dans le message à traiter. Les quatre variables sont copiées dans d ’autres variables A dans A A , B dans B B , C dans C C et D dans D D . La boucle principale a 4 rondes (M D 4 n’avait que 3 rondes), toutes très similaires. Chaque ronde consiste en 16 exécutions d’une opération. Chaque opération calcule une fonction non linéaire de trois des variables A, B , C et D. Ensuite elle ajoute au résultat la quatrième variable, un sous-bloc et une constante. Ce nouveau résultat est ensuite décalé circulairement vers la gauche d’un nombre variable de bits et ensuite ajouté à l’une des A , B, C, D. Finalement ce dernier îésultat remplace l’une des A, B , C, D. Voir les figures 18.5 et 18.6.
F ig .
18.5
-
Boucle principale de M D5
Il y a 4 fonctions non linéaires, une différente pour chaque ronde4 : F (X ,Y ,Z )
=
( X A Y ) V (--X A Z)
G (X ,Y ,Z )
=
( X A Z) V (Y A -
H (X ,Y ,Z )
=
X ® Y ® Z
I{X ,Y ,Z )
=
Y ® (X V iZ ).
Ces fonctions sont conçues de telle manière que si les bits correspondants de X , Y et Z sont indépendants et non biaisés, alors les bits du résultat sont aussiindépendants et non biaisés. La fonction F est la conditionnelle bit à bit : si X , alorsY, sinon Z. La fonction H est l’opérateur de parité bit à bit. 4. Signification des opérateurs logiques : A dén ote le « et logique » logique, V dénote le « ou in clu sif », i dénote la négation et ffi dénote le « ou exclu sif ».
Chapitre 18
462
F ig .
18.6
-
Fonctions de hachage à sens unique
Une opération de M D5
Si M .3 représente le j e sous-bloc du message (j allant de 0 à 15), et si Os représente un décalage circulaire à gauche de s bits, les quatre opérations de base sont : F F{a,b,c,d,M 3 ,s,ti) dénote a — b + ((a + F(b,c,d) + A i 3 -F U) <3 s), GG(a,b,c,d,À4J,s,tl ) dénote a — b + ((a + G(b,c,d) + A i 3 + ti) O s), H H (a,b,c,d,M j ,s,t,) dénote a = b + ((a + H(b,c,d) + M .3 + U ) O s), lI(a,b,c,d,Al 3 ,s,ti) dénote a = b + ((a + I(b,c,d) + A4 3 + tl) O s).
Les 4 rondes (64 étapes) sont données par5 : ronde 1 : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
(A, (D, (C, (B, (A, (D, (C, (B, (A, (D, (c , (B, (A, (D, (C, (B,
B, A, D, C, B, A, D, C, B, A, D, c, B, A, D, C,
c, B, A, D, c, B, A, D, C, B, A, D, c, B, A, D,
D, c, B, A, D, C, B, A, D, C, B, A, D, C, B, A,
M[ 0], M[ 1], M[ 2], M[ 3], M[ 4], M[ 5], M[ 6], M[ 7], M [ 8] , M[ 9] , M[10] , M[ll] , M[12] , M[13] , M[14] , M [15] ,
7, 12, 17, 22, 7, 12, 17, 22, 7, 12, 17, 22, 7, 12, 17, 22,
0xd76aa478) 0xe8c7b756) 0x242070db) Oxclbdceee) Oxf57c0faf) 0x4787c62a) 0xa8304613) Oxfd469501) 0x698098d8) 0x8b44f7af) Oxffff5bbl) 0x895cd7be) 0x6b901122) 0xfd987193) 0xa679438e) 0x49b40821);
ronde 2 : GG (A, B, c , D, M[ 1],
5, Oxf61e2562)
5. N o te d u tr a d u c t e u r : M [j] d é n o t e le j e so u s -b lo c .
18.5
463
MD5
GG (D , GG (C , GG (B , GG (A , GG (D , GG (C , GG (B , GG (A , GG (D , GG ( c , GG (B , GG (A , GG (D , GG (C , GG (B ,
A, D, c, B, A, D, c, B,
B, A, D, C, B, A, D, C,
A, B, D, A, c , D, B, c , A, B, D, A, c , D,
c, B, A, D, c, B, A, D, c, B, A, D, c, B, A,
9 , 0 x c0 4 0 b 3 4 0 ) 14, 0x265e5a51) 2 0 , 0 x e9 b6c7aa) M[ 5 ] , 5 , 0 x d 6 2 f1 0 5 d ) M [1 0 ], 9 , 0x02441453) M[1 5 ] , 1 4 , 0 x d 8 a le 6 8 1 ) M[ 4 ] , 2 0 , 0 x e 7 d 3 fb c 8 ) M[ 6 ] ,
H t ll], M[ 0 ] ,
M[ 9 ] , M [1 4 ], M[ 3 ] , M[ 8 ] , M [13] , M[ 2 ] , M[ 7 ] , M [1 2 ],
5, 9, 14, 20,
0 x 2 1 e lc d e 6 ) 0 x c3 3 7 0 7 d 6 ) 0 x f4 d 5 0 d 8 7 ) 0 x 4 5 5 a l4 e d )
5 , 0xa9e3e905) 9 , O x fc e fa 3 f8) 1 4 , 0 x 6 7 6 f0 2 d 9 ) 2 0 , 0 x 8 d 2 a 4 c 8 a );
ronde 3 : HH HH HH HH HH HH HH HH HH HH HH HH HH HH HH HH
(A , (D , (c , (B , (A , (D , (C , (B ,
B, A, D, c, B, A, D, c, B,
c, B, A, D, c, B, A, D,
D, c, B, A, D, c, B, A,
M[ 5] M[ 8 ] M [ll] M [14]
M[ 1] M[ 4 ] M[ 7] M [10] D, M [13] c , M[ 0] B , M[ 3 ] A, M[ 6] D, M[ 9] c , M [12] B, M [15] A, M[ 2]
4 , 0 x fffa 3 9 4 2 ) u , 0x877l f 681) 16, 0x6d9d6122) 2 3 , 0 x fd e 5 3 8 0 c ) 4 , 0xa4beea44) u , 0 x 4 b d e c fa 9 ) 1 6 , O x f6 b b 4 b 6 0 ) 2 3 , 0 x b e b fb c 7 0 ) 4 , 0x 2 8 9b7ec6) u , 0 x e a a l2 7 f a ) 1 6 , 0 x d 4 e f3 0 8 5 ) 2 3 , 0 x 0 4 8 8 ld 0 5 ) 4 , 0 x d 9 d 4 d 0 39 ) 11, 0xe6db99e5) 16, O x lfa 2 7 c f8) 2 3 , 0xc4a c5 6 65 )
(A , (D , (c , (B , (A , (D , (C , (B ,
A, D, c, B, A, D, c,
(A , (D , (c , (B , (A , (D , (C , (B , (A , (D ,
B , c , D, M[ 0 ] , 6, A, B, c , M[ 7 ] , 1 0 , D, A, B, M [14] , 1 5 , C, D, A, M[ 5 ] , 2 1 , B, c , D, M [12] , 6, A, B, C, M[ 3 ] , 1 0 , D, A, B, M [10] , 1 5 , c , D, A, M[ 1 ] , 2 1 , B, c , D, M[ 8 ] , 6, A, B, c , M [15] , 1 0 ,
c, B, A, D, c, B, A, D,
ronde 4 : 1 1
II II II II II II II II II
O x f4 2 9 2 2 4 4 ) 0 x 4 3 2 a ff97) 0xab9423a7) 0 x fc 9 3 a 0 3 9 ) 0 x 6 5 5 b 5 9 c3 ) 0 x 8 f0 c c c 9 2 ) O x ffe ff4 7 d ) 0 x 8 5 8 4 5 d d l) 0 x 6 fa 8 7 e 4 f) 0 x fe 2 c e 6 e 0 )
Chapitre 18
464 II II II II
II II
(C , D, A, B, (B , C, D, A, (A , B, c , D, (D , A, B, c , ( c , D, A, B, (B , c , D, A,
M[ 6 ] , 1 5 , M [13] , 2 1 , M[ 4 ] , 6, M [ll] , 10, M[ 2 ] , 1 5 , M[ 9 ] , 2 1 ,
Fonctions de hachage à sens unique.
0xa3014314) 0 x 4 e 0 8 1 1 a l) 0 x f7 5 3 7 e 8 2 ) 0 x b d 3 a f2 3 5 ) 0x2ad7d2bb) 0xeb86d391)
Les constantes tz furent choisies de la manière suivante : À l’étape i, L est la partie entière de 232 x abs(sin(*)), où i est exprimé en radian. Après tout cela, A, B, C et D sont ajoutées à AA , B B , C C , D D respectivement et l’algorithme continue avec le bloc suivant de données. Le résultat final est la jointure de AA, B B , C C , D D .
Sécurité de M D5 Ron R i v e s t décrit les améliorations de M D5 par rapport à M D 4 [1332] : 1. Un quatrième ronde a été ajoutée. 2. Chaque étape a maintenant une constante additive unique. 3.
La fonction G de la 2e ronde remplace (X A Y ) V (X A Z) V (Y A Z) par (X A Z ) V ( f A ~'Z), afin de rendre G moins symétrique.
4. Chaque étape ajoute maintenant le résultat de l’étape précédente. Cela favorise un « effet d’avalanche » plus rapide. 5. L’ordre d’accès des sous-blocs est changé dans les 2e et 3e rondes afin de rendre les motifs moins similaires. 6. Le nombre de décalages de chaque ronde a été approximativement optimisé pour obtenir un effet d ’avalanche plus rapide. Les décalages circulaires sont différents d’une ronde à l’autre. Tom BERSON a essayé d ’utiliser la cryptanalyse différentielle contre une seule ronde de M D5 [151] mais son attaque est loin d’être efficace contre les 4 rondes. Une attaque nettement mieux réussie de Bert DEN B o e r et Antoon BOSSELAERS peut produire des collisions en utilisant la fonction de compression de M D5 [460, 1344, 1348]. Cela ne donne pas des attaques pratiques contre des applications concrètes de M D5 et cela ne remet pas en cause l’utilisation de M D5 dans les algorithmes de chiffrement à la L u b y - R a c k o f f (voir § 14.11). Cela veut simplement dire que l’un des principes de conception de M D 5— concevoir une fonction de compression résistante aux collisions a été violé. Même s’il est vrai que « la fonction de compression semble posséder une faiblesse, mais sans conséquence sur la sécurité de la fonction de hachage en pratique », je reste circonspect quant à l’utilisation de M D5
18.6
MD2
18.6
465
M D2
MD2 est encore une autre fonction de hachage à sens unique conçue par Ron R i v e s t [810,1346]. Elle est utilisée, avec M D 5, dans les protocoles PE M (voir § 24.10). La sécurité de M D 2 dépend d’une permutation aléatoire de l’ensemble de tous les octets. Cette permutation est fixée, et dépend des décimales de n. Elle sera noté Sq,Si, . . . ,5255• Pour calculer l’empreinte d ’un message A4, procédez ainsi : 1° Complétez le message avec i octets de valeur i de sorte que sa longueur en octets devienne un multiple de 16. 2
° Accolez une somme de contrôle de 16 octets au message.
3° Initialisez un bloc de 48 octets : X o ,X k, . . . , A 4 7 . Mettez les 16 premiers octets de X à zéro, copiez les 16 premiers octets du message dans les 16 suivants, et remplissez les 16 derniers avec le résultat de la combinaison par ou exclusif du premier tiers de X avec le second tiers de X .
4° Appliquez la fonction de compression : t= 0 Pour j variant de 0 à 17 et k variant de 0 à 47, effectuer: t = X k® S t Xk= t t = (t + j ) modulo 256
5° Copiez le deuxième morceau de 16 octets du message dans le second tiers de X et remplissez le troisième tiers de X avec le résultat de la combinaison par ou exclusif du premier tiers de X avec le second tiers de X . 6°
Exécuter l’étape 4■ Répétez les étapes 5 et 4 avec chaque morceau de 16 octets du message.
7° Les 16 premiers octets de X constituent l ’empreinte du message. Bien qu’aucune faiblesse n’ait été trouvée dans M D2 (consulter [1273]), il est plus lent que la plupart des autres fonctions de hachage à sens unique suggérées.
18.7
Algorithme sûr de hachage SHA
L’Institut national des standards et de la technologie américain ainsi que l’Agence nationale de sécurité américaine ont conçu l’algorithme sûr de hachage (SHA pour « Secure Hash Algorithm ») pour être utilisé dans le D SA (voir § 20.2) [1174]6. D ’après le « Fédéral Register » [542] : « Un standard fédéral de traitement de l’information [américain] (FIPS pour « Fédéral Information Processing Standard ») est proposé pour le standard de hachage sûr (SHS). Cette proposition de standard spécifie un 6. Le standard est le « standard d e hachage sûr » (SHS pou r « S ecu re H a sh S ta n d a rd ») ; SH A est l’algorithm e utilisé dans ce standard.
Chapitre 18
466
Fonctions de hachage à sens unique
algorithme de hachage sûr (SH A) pour être utilisé avec le standard de signature numérique [(DSS)]. De plus, pour les applications ne nécessitant pas de signatures numériques, le SHA doit être utilisé chaque fois qu’un algorithme de hachage sûr est requis pour les applications fédérales. » E t: « Ce standard spécifie un algorithme de hachage sûr (SH A), qui est né cessaire pour garantir la sécurité de l’algorithme de signature numérique (D SA ). Quand un message de n’importe quelle longueur inférieure à 264 est donné en entrée, le SHA produit une sortie de 160 bits appelée mes sage abrégé7. Le message abrégé est alors fourni comme entrée au DSA qui calcule la signature du message. Signer le message abrégé plutôt que le message d’entrée améliore souvent l’efficacité du processus parce qu’ha bituellement le message abrégé est nettement plus court que le message d’entrée. Le même message abrégé doit être obtenu par le vérificateur de la signature quand la version reçue du message est utilisée comme entrée à la fonction SHA. Le SHA est qualifié de sûr parce qu’il est conçu pour qu’il soit impossible de retrouver par le calcul un message correspondant à un message abrégé donné, ou de trouver deux messages différents qui produiraient le même message abrégé. Tout changement à un message en transit produira, avec une très haute probabilité, un message abrégé diffé rent et la vérification de la signature échouera. Le SHA est basé sur des principes similaires à ceux utilisés par le professeur Ronald L. R i v e s t du M IT quand il conçut l’algorithme de message abrégé M D 4 [1330] et est étroitement calqué sur cet algorithme. » SHA produit des empreintes de 160 bits, ce qui est plus long que ce que produit MD5.
Description du SHA Au départ, le message est complété de manière à ce que sa longueur en bits soit un multiple de 512. Le remplissage est exactement le même que celui de M D5 : ajoutez d’abord un 1 suivi d’autant de 0 que nécessaire pour que 64 bits manquent par rapport à un multiple de 512 et enfin une représentation en 64 bits de la longueur du message avant remplissage. Cinq variables (M D 5 avait 4 variables, mais SHA produit une empreinte de 160 bits) sont initialisées de la façon suivante : A B C D E
= 0x67452301 = 0xEFCDAB89 =
0x98BADCFE
= 0x10 3 2 5 4 7 6 = 0xC3D2ElF0.
La boucle principale de l’algorithme commence alors. Elle traite le message 512 bits à la fois et continue tant qu’il y a des blocs de 512 bits. 7. N ote du traducteur : le term e « m e s s a g e a b r ég é » est utilisé ici com m e traduction littérale de l’expression anglaise « m e s s a g e d tg est ». Il s’ agit en fait de ce qui a été appelé tou t au long de cet ouvrage une « e m p r e in te ».
18.7
Algorithme sûr de hachage S H A
467
Premièrement, les 5 variables sont copiées dans des variables différentes : A dans AA , B dans B B , C dans C C , D dans D D et E dans E E .
La boucle principale a 4 rondes de 20 opérations chacune (M D 5 a 4 rondes de 16 opérations chacune). Chaque opération effectue une opération non linéaire sur trois des variables A, B , C et D , et effectue des décalages et des additions similaires à ceux de M D5. L’ensemble des opérations non linéaires de SHA sont données par : ft(X ,Y ,Z ) ft(X ,Y ,Z ) ft(X ,Y ,Z ) ft(X ,Y ,Z )
= (X A Y ) V (~>X A Z), pour t entre 0 et 19, — X © Y © Z , pour t entre 20 et 39, = ( X A Y ) V (X A Z) V (Y A Z ), pour t entre 40 et 59, = X © Y © Z, pour t entre 60 et 79.
Cet algorithme utilise également 4 constantes8 : K t = 0x5A 827999, pour t entre 0 et 19, K t = 0x6ED9EBAl, pour t entre 20 et 39, K t — 0x8FlBBCDC,pour t entre 40 et 59, Kt — 0xCA62ClD6, pour t entre 60 et 79.
Le bloc du message découpé en 16 mots de 32 bits (A4o à A4is) est transformé en 80 mots de 32 bits (Wo à W 79 ) en utilisant l’algorithme suivant9 : Wt — M-t, pour t — 0 à 15, W t = Wt- 3 © Wt s © W t- 1 4 © W t- 1 6 , pour t = 16 à 79.
Si t est le numéro de l’opération (de 1 à 80), A4 , représentele j esous-blocdu message (j allant de 0 à 15), et que Os représente un décalagecirculaire à gauche de s bits, alors la boucle principale ressemble à : Pour t variant de 0 à 79, T E M P = (A o 5) + ft(B ,C ,D ) + E + W t + K t E —D D —C C = (B o 30) B —A A = TEM P.
La figure 18.7 illustre une opération Le décalage des variables a le même effet que l’utilisation de différentes variables à différents endroits dans MD5. Après tout cela, A, B , C, D et E sont ajoutés à AA , B B , C C , D D et E E res pectivement et l’algorithme passe au bloc de données suivant. La sortie finale est la juxtaposition de A A , B B , C C , D D et E E . 8. Si vous vous dem andez d ’où ces constantes viennent: 0x5A827999 — \ A j 4 . 0x6ED9EBAl = v^3/4,
0x8FlBBCDC = \Æ /4 et 0xCA62ClD6 = vT Ô /4 . 9. Une anecdote intéressante : la spécification originale de SH A ne contenait pas le décalage circu laire à gauche. La m odification « corrige une im perfection technique qui rendait le standard moins sûr que prévu » [545]. La N SA a refusé de révéler la nature exacte de cette im perfection.
Chapitre 18
468
Fonctions de hachage à sens unique
F ig. 18.7 - Une opération de SHA
Sécurité de SHA SHA est très similaire à M D4. Les changements principaux sont l’addition d’une étape d’expansion, la sommation de la sortie de l’étape précédente à l’entrée de l’étape sui vante pour obtenir un effet d ’avalanche. Ron R i v e s t a rendu publics les choix de conception de M D5 mais les concepteurs de SHA ne l’ont pas fait. Voici les améliora tions apportées par R lV E S T dans M D 5 par rapport à M D 4 et leur comparaison avec SH A: 1. « Une quatrième ronde a été ajoutée. » SHA fait de même. Toutefois, la 4e ronde de SHA utilise la même fonction / que la 2e ronde. 2. « Chaque étape a maintenant une constante additive unique. » SHA garde le schéma de M D4 en réutilisant la même constante au sein de chaque groupe de 20 opérations. 3. « La fonction G de la 2e ronde remplace (X A Y ) V (X A Z) V (Y A Z) par
( X A i ? ) V (Y A -'Z ), afin de rendre G moins symétrique. » SH A utilise la fonction de M D 4 : (A A Y ) V (X A Z) V (F A Z)
18.8
R IP E -M D
469
4. « Chaque étape ajoute maintenant le résultat de l’étape précédente. Cela favorise un effet d’avalanche plus rapide. » Ce changement a également été effectué dans
SHA. La différence dans SHA est qu’une cinquième variable est ajoutée et non pas B , C ou D qui sont déjà utilisées dans f t. Ce changement subtil rend l’attaque DEN B o e r - B o s s e l a e r s contre M D5 impossible contre SHA. 5. « L ’ordre d’accès des sous-blocs est changé dans les 2e et 3e rondes afin de rendre les motifs moins similaires. » SHA est complètement différent, puisqu’il utilise un code cyclique correcteur d ’erreurs. 6. « Le nombre de décalages de chaque ronde a été approximativement optimisé pour obtenir un effet d’avalanche plus rapide. Les quatre décalages circulaires utilisés dans une ronde sont différents de ceux des autres rondes. » SHA utilise
un décalage circulaire constant dans chaque ronde. Le nombre de décalages est un nombre premier par rapport à la taille des mots, tout comme dans MD4. Cela conduit à la comparaison suivante: SHA ressemble à M D 5 avec l’addition d’une transformation d’« expansion », une ronde supplémentaire et un meilleur effet d ’ava lanche; M D 5 ressemble à M D4 avec un mélange de bit amélioré, une ronde supplé mentaire et un meilleur effet d ’avalanche. Il n’y a pas d’attaque cryptographique connue contre SHA. Et comme il produit une empreinte de 160 bits, il est plus résistant à une attaque exhaustive (y compris l’attaque des anniversaires) que les autres algorithmes couverts par ce chapitre.
18.8
R IP E -M D
R IP E -M D a été développé par le projet R IP E [1316] de la Communauté européenne (voir § 25.7). Cet algorithme est une variante de M D4 conçue pour résister à toutes les attaques cryptanalytiques connues. Les rotations et l’ordre des mots du message sont modifiés. De plus, deux versions de l’algorithme, qui diffèrent seulement par les constantes, sont exécutées en parallèle. Après chaque bloc, la sortie des deux versions est ajoutée aux variables de chaînage. Il semble que cela rende l’algorithme très résistant à la cryptanalyse.
18.9
HAVAL
H AVAL est une fonction de hachage à sens unique de longueur variable [1648]. C’est une variante de M D 5. HAVAL manipule les messages par blocs de 1024 bits, deux fois la taille de M D5. Il utilise des variables de chaînage de 32 bits, deux fois la longueur de celles de M D5. Il a un nombre variable de rondes, de 3 à 5 (chaque ronde a 16 étapes), et il peut produire des empreintes de 128, 160, 192, 224 et 256 bits. HAVAL remplace les fonctions non linéaires simples de M D5 par des fonctions à 7 variables fortement non linéaires. Chaque ronde utilise une seule fonction mais, à chaque étape, une permutation différente est appliquée aux entrées. Il y a un nouvel ordre de traitement des blocs du message et chaque étape (sauf la première) utilise une constante additive différente. Il y a aussi deux rotations.
Chapitre 18
470
Fonctions de hachage à sens unique
Le cœur de l’algorithme est10 : T E M P = (f(j,A ,B ,C ,D ,E ,F ,G ) < 7 ) + (H < 11) + Af[i][r(j)] + K (j); H = G; G = F ; F = E\ E = D ; D = C ; C = B ; B — A ; A — T E M P .
Le nombre variable de rondes et la longueur variable de sortie donnent 15 versions différentes de l’algorithme L’attaque de DEN B o e r et B o s s e l a e r s contre M D5 [460] n’est pas applicable à HAVAL à cause de la rotation appliquée a H .
18.10
Autres fonctions de hachage à sens unique
Ron R i v e s t a conçu une autre fonction de hachage, appelée MD3. Elle avait plusieurs imperfections et elle n’est jamais sortie du laboratoire, bien qu’une description ait récemment été publiée dans [1346]. Un groupe de chercheurs de l ’ University of Waterloo a proposé une fonction de hachage à sens unique basée sur l’exponentiation itérée dans Z j 2593 [26]. Dans ce schéma, un message est divisé en blocs de 593 bits. Les blocs sont successivement soumis à I’ex ponentiation, en commençant par le premier bloc. Chaque exposant est le résultat du calcul avec le bloc précédent ; le premier exposant est donné par un vecteur d ’initiali sation. Ivan D a m g À r d a conçu une fonction de hachage à sens unique basée sur le problème des empilements (voir § 19.2) [416] ; il peut être cassé en 232 opérations environ [294, 1242, 787].
Les automates cellulaires de Steve W o l f r a m [1611] ont été proposés comme base pour des fonctions de hachage à sens unique. Une première réalisation [239] n’est pas sûre [1060, 410]. Une autre fonction de hachage à sens unique, CELLHASH [388, 410] et une version améliorée S u b h a s h [388, 405, 407] sont basées sur des automates cellulaires et sont toutes les deux destinées a des réalisations matérielles. B o o g n i s h mélange les principes de conception de C e l l h a s h avec ceux de M D 4 [405, 409]. S t e p R i g h t U p peut aussi servir de fonction de hachage à sens unique [405]. Claude ScHNORR a proposé une fonction de hachage à sens unique basée sur la trans formée de Fourier discrète, appelée F F T H a s h , au courant de l’été 1991 [1402] ; elle fut cassée quelques mois plus tard par deux groupes indépendants [406, 91]. S c h n o r r a proposé une version révisée, appelée F F T H a s h II (la version précédente fut rebapti sée F F T - H a s h I) [1405] qui fut cassée quelques semaines plus tard [1569]. S c h n o r r a proposé d ’autres modifications [1407, 1408] mais, tel qu’il est maintenant, l’algorithme est nettement plus lent que les autres de ce chapitre. Une autre fonction du nom de
S L 2 [1534] n’est pas sûre [307]. D ’autres travaux théoriques sur la construction de fonction de hachage à sens unique à partir de fonctions à sens unique et de permutations à sens unique sont décrits dans [415, 1147, 1354]. 10. N ote du traducteu r: le lecteur intéressé trouvera la description des intervalles p ou r i e t j , ainsi que la façon de diviser le message M et la signification de la fonction r dans l’ article original [1648].
18.11
18.11
Utilisation d’algorithmes de chiffrement par blocs
471
Utilisation d’algorithmes de chiffre ment par blocs
Il est possible d’utiliser un algorithme de chiffrement par blocs comme fonction de hachage à sens unique. L ’idée est que si nous savons que l’algorithme de chiffrement par blocs est sûr, alors la fonction de hachage à sens unique sera sûre aussi. La méthode la plus évidente consiste à utiliser l’algorithme en mode C B C ou C FB avec une clef et un vecteur d’initialisation fixes, et à prendre le dernier bloc de texte chiffré comme empreinte. Ces méthodes sont décrites dans plusieurs standards utilisant le D E S : avec les deux modes dans [1156], avec le mode C B C dans [57, 58, 65]. Ce n’est pas assez pour les fonctions de hachage à sens unique, bien que cela suffise pour un C A M (voir § 18.14) [33]. Une approche plus intelligente est d ’utiliser les blocs du message comme clef, la valeur précédente d’empreinte étant l’entrée et l’empreinte courante étant la sortie. En fait, les fonctions de hachage proposées sont plus complexes. La taille de bloc est en général la longueur de la clef et la taille de l’empreinte est la taille de bloc. Comme la plupart des algorithmes de chiffrement par blocs ont 64 bits, plusieurs schémas sont conçus pour engendrer une empreinte qui a deux fois la taille d’un bloc. En supposant que la fonction de hachage est correcte, la sécurité du schéma est ba sée sur celle de la fonction de bloc sous-jacente. Il y a cependant des exceptions. La cryptanalyse différentielle contre les fonctions de bloc est plus facile quand elle est uti lisée dans une fonction de hachage que dans un algorithme de chiffrement : la clef est connue, aussi peut-on appliquer certaines astuces ; une seule paire concordante suffit au succès de l’attaque ; et vous pouvez générer au tant de texte en clair que vous voulez. Quelques travaux sur le sujet se trouvent dans [1274, 858, 1324]. Ce qui suit est un résumé des différentes fonctions de hachage à sens unique qui sont parues dans la littérature [937, 1471, 1273]. Les affirmations concernant les attaques contre ces schémas font l’hypothèse que les chiffrements par blocs sous-jacents sont sûrs; autrement dit, que la meilleure attaque contre eux est l’attaque exhaustive. Une mesure qui s’avère utile en matière de fonctions de hachage à base d’algorithme de chiffrement par blocs est le ta u x d e hachage, c ’est à dire le nombre de blocs de n bits du message traités par chiffrement, où n est la taille de bloc dans l’algorithme. Plus ce taux est grand, plus l’algorithme est rapide11.
Schémas où empreintes et blocs ont même taille Le schéma général est le suivant (voir la figure 18.8) : H o — I h , o ù I j{ est un valeur initiale aléatoire, Hi = E a (B ) 0 C.
A, B et C sont à prendre parmi les termes A4», H i - 1 , (A4,; © H i - j), ou une constante
(supposée être 0). Le message est divisé en morceaux de la taille d’un bloc, les A-fr, qui sont traités individuellement. Il y a de plus une sorte de renforcement MD, éventuelle ment la même procédure de remplissage que dans M D5 et SHA. 11. C ette mesure est donnée avec la définition opposée dans [1273], mais la définition donnée ici est plus intuitive et plus largement utilisée. C ela peut être source de confusion.
Chapitre 18
472
F
ig
.
18.8 -
D
Fonctions de hachage à sens unique
a v ie s -
M
eyer
Chacune des trois variables peut prendre une des quatre valeurs possibles, ce qui donne en tout 64 schémas possibles. Bart P r e n e e l les a tous étudiés [1273]. Quinze d ’entre eux sont trivialement faibles car le résultat n’y dépend pas de l’une des entrées. Trente sept d’entre eux ne sont pas sûrs pour des raisons plus subtiles. Le tableau 18.1 donne la liste des douze schéma restants : les quatres premiers résistent à toutes les attaques (voir la figure 18.9) et les huits autres résistent à toutes sauf une attaque du point fixe, qui ne vaut pas la peine de s’inquiéter.
Clef
M, Chiffre
H,.|
p
Af,
<5
Clef Chiffre
F ig .
Clef
— *W“
Chiffre
18.9 - Les quatres fonctions de hachage sûre où empreintes et blocs ont même
taille
Le premier schéma a été décrit dans [1033]. Le troisième a été décrit dans [526, 1111, 1112] et proposé comme standard ISO [1142]. Le cinquième est dû à Cari M e y e r , mais connu sous le nom de D a v i e s - M e y e r dans la littérature [1608, 1609, 434, 1033]. Le dixième a été proposé comme un mode fonction de hachage pour LO K I [278]. Les premier, deuxième, troisième, quatrième, cinquième, et onzième schémas ont un taux de hachage de 1 ; la longueur de la clef est égale à la longueur des blocs. Les autres ont un taux de k /n où k est la longueur de la clef. Cela signifie que si la clef est plus courte que les blocs de l’algorithme, alors les blocs de message ne peuvent pas être plus long que la clef. Il n’est pas recommandé d ’utiliser des blocs de message plus longs que la clef, même si les blocs de l’algorithme de chiffrement sont plus courts que la clef. Si l’algorithme par blocs a comme le DES une propriété de complémentation, ou des clefs faibles, il existe une attaque supplémentaire possible contre les douze schémas.
18.11
Utilisation d’algorithmes de chiffrement par blocs
T a b . 18.1 - Fonctions de hachage sûres où empreintes et blocs ont même taille
H H H H H
= Ehx_ j (Af*) © M i =
( M i © H i-x ) © Al* © l î i -1
= Eh i_1(Mi) © if i-i © Al* = E h,.* (Al* © t fi-i) © Al* — E m ,(H î—i ) © H i - i H — £?M.(Ati © -H*—i) © Al* ffi Hi—i H — E m %(H i- 1) ffi A li H = Em ,(Mi ffi Hi-i) © Hi-1 (Ali) © Ali H = E m ,®h H = (# i-l) © # i-l H, = EM x< £ h x__x(M i) © H i-i H = E^umh-1 (H i- 1) © M i _________
L’attaque n’est pas très dangeureuse et ne vaut pas la peine de s’inquiéter. Cependant, vous pouvez la contrecarrer en fixant les bits 2 et 3 de la clef à « 01 » ou « 10 » [1085, 1113]. Cela réduit bien sûr la longueur de la clef de 2 bits (à 54bits pour leDES par exemple), et aussi le taux de hachage. Les schémas suivants, extraits de la littérature, ne sont pas sûrs. Ce schéma [1293] a été cassé dans [373] : H = E Mx(H i-\) D a v i e s et P
r ic e
ont proposé une variante qu i fait passer le message entier deux fols à
[432, 433]. L ’a ttaque de CO PPER SM ITH m arche sur cette variante [373], Un autre schéma [432, 464] n’est pas sûr non plus [1608] : travers l ’algorithm e
sans dem ander beaucoup plus de calculs
H i = E m & H i-
x( H
)
i-1
Il est m ontré dans [1033] que le schém a suivant n ’est pas sûr (c est une constante) : Lf* = Ec(M i ffi H i- x) © A f i © Hi- !
Davies-Meyer modifié L a i et M a s s e y ont modifié la technique de D a v i e s - M e y e r pour pouvoir l’utiliser avec le chiffre ID E A [941, 937]. ID E A a une taille de bloc de 64 bits et une taille de clef de 128 bits. Ce schéma est :
Ho = / , où I est une valeur initiale quelconque, Hi = % _ llM t( E - i ) -
Cette fonction hache un message par blocs de 64 bits et produit une empreinte de 64 bits (voir la figure 18.10). Il n’existe pas d’attaque connue contre ce schéma qui soit plus facile que l’attaque exhaustive.
Chapitre 18
474
Fonctions de hachage à sens unique
Chiffre |
Clef
i
|
t Airf
F ig .
18.10 -
D
a v ie s -
M
eyer
modifié
Preneel—Bosselaers-Govaerts—Vandewalle Cette fonction de hachage, proposée pour la première fois dans [1277], engendre une empreinte qui a deux fois la longueur de bloc de l’algorithme de chiffrement ; un algo rithme à 64 bits donne une empreinte de 128 bits. Avec un algorithme de chiffrement par blocs à 64 bits, ce schéma produit deux em preintes de 64 bits, Gt et H t, qui sont jointes pour produire une empreinte de 128 bits. Avec la plupart des algorithmes de chiffrement par blocs, la taille de bloc est de 64 bits. Deux blocs de messages adjacents Lt et llt ayant chacun la taille de la clef sont hachés ensemble. Go = I gi H0 =
où
IG est une valeur initiale quelconque,
I h -, o ù I h e s t u n e a u t r e v a le u r in itia le q u e lc o n q u e ,
Gt = E L,©//,_! (H, ffi © Rt © Gt -1© Ht- 1, H, = E l ,® r ,(H t-1 © G ,_ i) ffi Li © G\_i ffi H j_i. L a i a montré des attaques contre ce schéma qui, dans certains cas, rendent l’attaque des anniversaires facilement applicable [937, 935]. P r e n e e l [1273] et C o p p e r s m i t h [377] ont également des attaques contre ce schéma. Ne l’utilisez pas.
Quisquater—Girault Ce schéma, proposé pour la première fois dans [1290], produit également une empreinte qui a deux fois la taille du bloc de chiffrement. Deux blocs L, et lii, chacun de la taille de la clef, sont hachés ensemble. Go — I gi Ho =
où
I g est une valeur initiale quelconque,
I h , où I r
e s t u n e a u t r e v a le u r in it ia le q u e lc o n q u e ,
W i = E l , (G t_ i ffi R t ) ffi R t ffi H t_ i ,
Gj = Efi^W t ffi Lj) ffi G î - i ffi H t—i ffi L , , Hj = W , ffi Gt iCe schéma est apparu dans une ébauche de standard ISO de 1989 [760] mais fut abandonné dans une version ultérieure [761]. Les problèmes de sécurité avec ce schéma furent identifiés dans [1113, 937, 1273, 377]12. Dans certaines circonstances, l’attaque des anniversaires est soluble avec une complexité de 232 au lieu de 264, par attaque exhaustive. N’utilisez pas ce schéma. 12. En fait, la version publiée a été renforcée après que la version présentée à la conférence fut attaquée.
18.11
Utilisation d’algorithmes de chiffrement par blocs
475
LOKI à double bloc Cet algorithme est une variante de Q u i s q u a t e r - G i r a u l t , conçue spécifiquement pour être utilisée avec L O K I [278]. Les paramètres sont les mêmes que dans Q u i s Q U A T E R G
ir a u l t .
Go = Ig , Ho — Ih ,
où où
I g est une valeur initiale quelconque, Ih est une autre valeur initiale quelconque,
W t — Æ ? i , ,© g , i ( G i - 1 © H i ) © H , © H i —1 ,
Gi =
£ 'h ,© jî ,_1(Wi ffi
Li) ffi Gi-
1 ffi
Hi-
1 ffi
Li,
Hx = W i ® G t- i .
Une fois de plus, dans certaines circonstances, l’attaque des anniversaires est aisément soluble [937, 935, 1273, 377, 376]. N’utilisez pas ce schéma.
Davies-Meyer parallèle Il s’agit encore d ’une tentative d ’algorithme de taux de hachage 1 produisant une empreinte deux fois plus longue que les blocs [738]. Go = I g , où I g est une valeur initiale quelconque, H o
=
I h
,
où
I h
est une autre valeur initiale qu elcon qu e,
Gi = ELt®Rz(G i-i ffi Li) ffi Li ffi Hi—1, Hi = E Lt {H i-! ffi Ri) ffi Ri ffi H i - 1 . Malheureusement, ce schéma n’est pas sûr non plus [939, 863]. Il s’avère qu’une fonction d’empreinte de longueur double et de taux de hachage 1 ne peut pas être plus sûre que D a v i e s - M e y e r [863],
Davies-Meyer en tandem et de front Une autre manière de contourner les limitations inhérentes aux chiffrements par blocs avec une clef de 64 bits, est d ’utiliser un algorithme avec une clef de 128 bits et des blocs de 64 bits, tel qu’ID E A (voir § 13.9). Ces deux schémas produisent une empreinte de 128 bits et ont un taux de hachage de 1/2 [941, 937]. Dans ce prem ier schém a, d eu x fon ction s D a v ie s —M e y e r m odifiées travaillent en tan dem (voir la figure 18.11).
Go = Ig , H0 = I h ,
où où
Ig est une valeur initiale quelconque, I h
est une autre valeur initiale quelconque,
W t = EGt- UM i(H i-!), G t ■= G i - i ffi E M t, w , ( G i —1 ),
Hi = W i ffi H i-i.
Le schéma suivant utilise deux fonctions figure 18.12).
D a v ie s - M
eyer
modifiées de front (voir la
G 0 = I , où I est une valeur initiale quelconque, Ho = Ih , o ù Ih est une autre valeur initiale quelconque, g
g
Gi = Gt-i ffi (“ "Gi—i), Hi ~ H ^ 1 ffi E G , - 1, M , {Ht-i).
476
Chapitre 18
F
ig
. 1 8 .1 1 - D
a v ie s -
M
Fonctions de hachage à sens unique
eyer
en tandem
Dans les deux schémas, les deux empreintes de 64 bits G l et IIi sont juxtaposées pour former une unique empreinte de 128 bits. Pour autant que l’on sache, ces algorithmes ont la sécurité idéale pour des fonctions de hachage à 128 bits : trouver un message qui a une empreinte donnée nécessite 2128 tenta tives, et trouver deux messages qui ont la même empreinte nécessite 264 tentatives— en faisant l’hypothèse qu’il n’y pas de meilleur moyen d ’attaquer l’algorithme de chiffre ment par bloc que l’attaque exhaustive, bien entendu.
M D C —2 et M D C —4 M D C -2 et M D C -4 ont été développés par IBM [1085, 1089]. M D C -2 qui est parfois appelé IscMeyer-Schilling est pris en considération pour devenir un standard AN SI et ISO [62, 761] ; une variante a été proposée dans [767]. M D C -4 est spécifié pour le projet R IP E [1316] (voir § 25.7). La spécification utilise le DES comme fonction de bloc (il faut quatre chiffrements DES pour traiter un seul bloc de message de 64 bits), bien qu’en théorie, n’importe quel autre algorithme puisse être utilisé. M D C -2 a un taux de hachage de 1/2 et produit une empreinte qui a deux fois la longueur d ’un bloc de chiffrement. Il est illustré par la figure 18.13. M D C -4 produit aussi une empreinte qui a deux fois la longueur d ’un bloc de chiffrement et a un taux de hachage de 1/4 (voir la figure 18.14. Ces schémas ont été analysés dans [937, 1273]. Ils sont sûr au vu de la puissance actuelle
F i g . 18.12 - D a v ie s - M
eyer
de front
18.11
Utilisation d’algorithmes de chiffrement par blocs
477
F ig . 18.13 - M D C -2 des ordinateurs, mais ils ne sont pas aussi sûrs que ce que leurs concepteurs avaient estimé. Si l’algorithme de chiffrement est le DES, ils ont été examinés sous l’angle de la cryptanalyse différentielle [1273]. M DC -2 et M D C -4 sont tous les deux brevetés [226].
AR La fonction de hachage A R a été développée par A l g o r i t h m i c R e s e a r c h , L t d . et distribuée par ISO à dans un but informatif uniquement [1141]. Sa structure fonda-
F i g . 18.14 - M D C - 4
Chapitre 18
Fonctions de hachage à sens unique
mentale est une variante de l’algorithme par blocs (le DES en l’occurrence) en mode C B C . Les deux derniers blocs de texte chiffré, une constante et le bloc de message courrant sont combinés par ou exclusif puis chiffrés par l’algorithme. L ’empreinte est constituée des deux derniers blocs de texte chiffré calculés. Le message est traité deux fois avec deux clefs différentes, la fonction a donc un taux de hachage de 1 / 2 . La pre mière clef est 0 x 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 , la seconde est 0 x 2 A 4 1 5 2 2 F 4 4 4 6 5 0 2 A , et c vaut 0 x 0 1 2 3 4 5 6 7 8 9 A B C D E F . Le résultat est comprimé en une seule empreinte de 1 2 8 bits. Consulter [752] pour les détails. Ih = E K { M t © 77,_i © 77,_2) © -A4,
Cela a l’air intéressant, mais ce n’est pas sûr. Après le traitement d ’une somme de données considérable, il devient possible de trouver facilement des collisions pour cette fonction de hachage [419].
GOST Cette fonction vient de Russie, elle est spécifiée dans le standard G O S T R 34.11-94 [659]. Elle utilise l’algorithme de chiffrement par blocs G O S T (voir § 14.1), bien qu’en théorie elle fonctionnerait avec n’importe quel algorithme par blocs de 64 bits et de clef de 256 bits. La fonction produit une empreinte de 256 bits. La fonction de compression / ( A i , , / / , _ i ) (dont les deux paramètres sont formés de 256 bits) est définie ainsi : 1° Générer quatre clefs de chiffrement pour G O S T par une combinaison linéaire de M i , de / / , _ i et de quelques constantes. 2° Utilisez chaque clef pour chiffrer un différent morceau de 64 bits de 77,_ i en mode E C B . Stockez les 256 bits résultants dans une variable temporaire S. 3° 77, est une combinaison complexe, bien que linéaire, de S, A4, et //, i . L’empreinte finale de A4 n’est pas l’empreinte du dernier bloc. de chaînage : H n est l’empreinte du dernier bloc de message, ou exclusif de tous les blocs de message, et L est la longueur ces variables et le dernier bloc de remplissage A4' accolé à finale est la suivante :
Il y a en fait trois variable Z est la combinaison par
du message. Etant donné la fin de A4, l’empreinte
H — f ( Z © A f',/(L ,/(A 4 \ 7 7 „)))
La documentation est un peu confuse (et en russe), mais je pense que tout cela est correct. Dans tous les cas, cette fonction de hachage est destinée au standard russe de signature numérique (voir § 20.3).
Autres schémas Ralph M e r k l e a proposé un schéma qui utilise le DES mais il est lent ; il ne traite que 7 bits du message par itération, et chaque itération met en jeu deux chiffrement par le DES [1081, 1076]. Un autre schéma [1644, 1647] n’est pas sûr [1278] ; il fut proposé un temps pour devenir un standard ISO.
18.12
18.12
Utilisation d’algorithmes à clef publique
Utilisation d’algorithmes à clef pu blique
Il est possible d ’utiliser les algorithmes à clef publique en mode de chaînage de blocs pour une signature numérique. Si vous jetiez la clef privée, casser l’empreinte serait aussi difficile que de lire le message sans la clef privée. Par exemple, voici comment le R S A peut être transformé en une fonction de hachage à sens unique. Si A4 est le message à hacher, n le produit de deux nombres premiers p et q, et e un autre grand nombre premier par rapport à (p — l)(q — 1), alors la fonction de hachage H (AI ) sera : H ( M ) = M c mod n. Une solution encore plus simple serait d’utiliser un seul nombre premier fort comme module p. Alors : H (A4) = A4e mod p. Casser ce problème est probablement aussi difficile que de trouver le logarithme discret de e. Si e et p sont assez grands, la fonction de hachage à sens unique est sûre. Le défaut de cet algorithme est qu’il est nettement plus lent que tous les autres déjà décrits ci-dessus. Je ne le recommande pas pour cette raison.
18.13
Choix d’une fonction de hachage à sens unique
Les prétendants semblent être SHA, M D5 et les constructions à base d’algorithmes de chiffrement par blocs ; les autres n ’ont pas été assez étudiés pour concourir. Je vote pour SHA. Les empreintes sont plus longues que celles de M D5, il est plus rapide que les différentes construction à base d’algorithmes de chiffrement par bloc, et il a été développé par la NSA. J’ai confiance dans les capacités des chercheurs de la NSA en matière de cryptanalyse, même si leurs résultats ne sont pas rendus publics. Le tableau 18.2 donne des mesures de vitesse de quelques fonctions de hachage à sens unique à titre de comparaison uniquement.
18.14
Codes d’authentification de messages
Un code d’authentification de messages, C A M en abrégé, est une fonction de hachage à sens unique dépendant d ’une clef. Les C A M ont les mêmes propriétés que les fonctions de hachage à sens unique décrites ci-dessus mais, en plus, elles incluent une clef13. Seul celui qui possède une clef identique peut vérifier l’empreinte. Elles sont très utiles pour prouver l’authenticité sans fournir la confidentialité. Les C A M peuvent servir à l’authentification de fichiers entre des utilisateurs. Elle peut aussi servir à un seul utilisateur pour vérifier que ses fichiers n’ont pas été altérés, par un virus par exemple. Un utilisateur pourrait calculer les empreintes de ces fichiers 13. Ce qui ne veut pas dire que vous pouvez révéler la clef d ’un C A M et vous en servir de fonction de hachage à sens unique.
Chapitre 18
480
Fonctions de hachage à sens unique
T a b . 18.2 - Vitesses de chiffrement en continu de quelques fonctions de hachage à sens
unique sur un 486SX à 33 MHz____________________________________________________
Longueur de l’empreinte Vitesse de chiffrement (en mégaoctets par seconde) 22 D a v i e s - M e y e r de front (avec ID E A ) 128 D a v i e s - M e y e r (avec le D ES) 64 9 11 G OST 256 168 variable HAVAL (3 rondes) 118 variable HAVAL (5 rondes) variable 95 HAVAL (5 rondes) M D2 128 23 236 128 M D4 174 128 M D5 N-H ASH (12 rondes) 128 29 24 N -H ASH (15 rondes) 128 182 R IP E -M D 128 75 SHA 160 48 SN EFRU (4 passes) 128 128 23 SNEFRU (8 passes) Algorithme
avec un C A M et les stocker dans une table. Si l’utilisateur utilisait une fonction de hachage à sens unique à la place, le virus pourrait calculer la nouvelle empreinte après infection et remplacer celle de la table. Un virus ne pourrait pas faire cela avec un C A M parce qu’il ne connaitrait pas la clef. Un moyen facile de transformer une fonction de hachage à sens unique en un CAM consiste à chiffrer l’empreinte avec un algorithme à clef secrète.
C A M par chiffrement par blocs Le moyen le plus simple de réaliser une fonction de hachage à sens unique à clef est de chiffrer un message avec un algorithme de chiffrement par blocs en mode C FB ou CBC. L’empreinte est le dernier bloc chiffré, chiffré une fois de plus en mode C F B ou CBC. Cette méthode est spécifiée dans l’ANSI X 9.9 [65J, l’AN SI X 9.19 [58], l’ISO 87311 [763], l’ISO 9797 [768], et un standard australien [1196]. La cryptanalyse permet de casser ce schéma quand il a peu de rondes et utilise le DES ou F E A L [1206]. Le problème potentiel de sécurité avec cette méthode est que le destinataire doit avoir la clef, et que cette clef lui permet de générer des messages de même empreinte qu’un message donné en déchiffrant à l’envers.
Algorithme d’authenfication de messages Cet un algorithme est un standard ISO [764]. Il produit une empreinte de 32 bits pour les unités centrales possédant une instruction de multiplication rapide [429]. v = v <3 1 e= v © w x = ((((e -f y) modulo 232) V A A C ) x (a; © A U )) modulo 232 — 1
18.14
Codes d’authentification de messages
481
V = ((((e+ x ) modulo 232) V B A D ) x ( y ® M i ) ) modulo 232 — 2 Répéter cela pour chaque bloc de message M i et l’empreinte résultante est la combi naison par ou exclusif de x et y. Les variables u et e proviennent de la clef. A, B , C et D sont des constantes. Cet algorithme est probablement largement utilisé, mais je ne peux pas croire qu’il soit si sûr. Il y a fort longtemps qu’il a été conçu, et il n’est pas très compliqué.
C A M bidirectionnel Ce C A M produit des empreintes de longueur double de celle des blocs de l’algorithme [989]. Commencez par calculer le C A M par chiffrement par blocs en mode C B C ap pliqué au message. Calculez alors le C A M par chiffrement par blocs en mode C B C appliqué au message en prenant les blocs dans l’ordre inverse. L ’empreinte du C A M bi directionnel est obtenu simplement en juxtaposant les deux valeurs. Malheureusement, cette construction n’est pas sûre [1103].
Méthodes de J u e n e m a n Ce C A M est aussi appelé code de détection de manipulations congruentielles quadra tiques (C D M C Q en abrégé) [792, 790]. Divisez tout d’abord le message en blocs de m bits, et appliquez ceci ensuite : / / n = I h °ù I h est la clef secrète, Hi = ( i ïi - 1 + M {)2 modulo p où p est un nombre premier inférieur à 2m —1 et + dénote l’addition entière. J u e n e m a n suggère de prendre n = 16 et p — 231 — 1. Dans [792], il suggère de plus de prendre H i comme clef supplémentaire en faisant commencer le message à H?. Suite à la découverte de nombreuses attaques du type de celle des anniversaires avec Don C o p p e r s m i t h , J u e n e m a n a suggéré de calculer le C D M C Q quatre fois, en pre nant le résultat de chaque itération comme vecteur d’initialisation de la suivante, puis en juxtaposant les résultats pour obtenir une empreinte de 128 bits [793]. Ceci fut da vantage renforcé en opérant les quatre itérations en parallèle et en les liant de manière entrecroisée [789, 791]. Ce schéma a été cassé par C o p p e r s m i t h [380]. Une autre variante [432, 434] remplaçait l’addition par un ou exclusif et utilisait des blocs de taille bien inférieure à p. H 0 étant fixé, cela devenait une fonction de hachage à sens unique sans clef. Après que ce schéma ait été attaqué [614], il fut renforcé en tant que partie intégrante du projet « European Open Shop Information-TeleTrust » [1233], cité dans C C IT X .509 [309], et adopté dans l’ISO 10118 [760, 761], Malheureusement, C o p p e r s m i t h a aussi cassé ce schéma [380]. Certaines recherches ont essayé des ex posants autres que 2 [605], mais aucune n’a été prometteuse.
RIPE-M AC R I P E M A C a été conçu par Bart P r e n e e l [1273] et adopté par le projet R IP E [1316] (voir § 18.8). Il est basé sur l’ISO 9797 [768] et utilise le DES comme fonction de chiffrement de bloc. Il y a deux variantes de R IP E -M A C : l’une utilisant le DES normal, appelée R IP E —M AC1 et l’autre utilisant le DES triple pour une plus grande
Chapitre 18
482
Fonctions de hachage à sens unique
sécurité, appelée R IP E -M AC3. RIPE-JVIAGI utilise un chiffrement DES par blocs de messages de 64 bits ; R IP E - M A C 3 en utilise trois. L ’algorithme consiste en trois parties. Au départ, le message est étendu pour rendre la longueur multiple de 64 bits. Ensuite, le message étendu est divisé en blocs de 64 bits. Une fonction de compression à clef est utilisée pour hacher ces blocs, sous le contrôle d’une clef secrète, en un seul bloc de 64 bits. C ’est cette étape qui utilise soit le DES soit le DES triple. Finalement, la sortie de cette compression est soumise à un autre chiffrement DES avec une autre clef, dérivée de la clef utilisée pour la compression. Voyez [1316] pour les détails.
IBC-Hash IB C -H ash est un autre C A M adopté par le projet R IP E [1316] (voir § 18.8). Il est intéressant car on peut prouver sa sécurité ; la probabilité d’une attaque réussie peut être quantifiée. Malheureusement, chaque message doit être haché avec une clef différente. Le niveau de sécurité choisi impose des contraintes sur la longueur maximale du message, quelque chose qu’aucune autre fonction de ce chapitre ne fait. Étant donné ces considérations, le rapport R IP E recommande de n’utiliser IB C -H ash que pour des longs messages envoyés peut fréquemment. Le coeur de la fonction réside dans la formule suivante : H t - ((A41 modulo p) + v) modulo 2"
La clef secrète est la paire p et v , où p est un nombre premier de n bits et v un nombre aléatoire inférieur à 2n. Les A4, proviennent d’une procédure de remplissage précisément spécifiée. On peut quantifier les probabilités de casser la fonction, que ce soit par collision ou en l’inversant, et l’utilisateur peut choisir le niveau de sécurité en modifiant les paramètres.
C A M à partir d’une fonction de hachage à sens unique Une fonction de hachage à sens unique peut aussi être utilisée comme C A M [1545]. Faites l’hypothèse qu’Alice et Bernard partagent une clef K et qu’Alice veut envoyer à Bernard une C A M pour le message A4. Alice joint A4 et A et calcule la fonction de hachage à sens unique de l’ensemble : H( A ,A4). Cette empreinte est la C A M . Comme Bernard connaît A , il peut reproduire le résultat d ’Alice. Martin, qui ne connaît pas A , ne peut pas le faire. Cette méthode fonctionne avec les techniques de renforcement MD, mais présente de sérieux problèmes. Martin peut toujours ajouter de nouveaux blocs à la fin du message et calculer une empreinte de C A M valide. Cette attaque peut s’éviter en mettant la longueur du message au début, mais P r e n e e l se méfie de ce schéma [1276]. Il vaut mieux mettre la clef à la fin du message : H (A4, A ), mais cela pose aussi certains problèmes [1276], Si H est à sens unique, mais pas sans collisions, Martin peut fabriquer des messages. La meilleure solution est H ( K , A i , K ) ou bien H (A'i ,A4,A2), où K\ et A 2 sont différentes [1545]. P r e n e e l reste encore méfiant vis à vis de cette dernière [1276]. Les constructions suivantes paraissent sûres : H ( K i ,H ( K 2,M))
18.14
Codes d’authentification de messages
483
H(K,H(K,M)) H{K, p, M., K) où p sert à remplir K jusqu’à obtenir un bloc de message.
La meilleure approche consiste à joindre 64 des bits de la clef avec chaque bloc du message. Cela rend la fonction de hachage moins efficace car les blocs du message sont plus petits, mais c ’est beaucoup plus sûr [1276]. Une alternative consiste à utiliser une fonction de hachage à sens unique et un algo rithme de chiffrement à clef secrète. Calculez l’empreinte du fichier, et chiffrez la. Elle est plus sûre que de chiffrer le fichier et de calculer l’empreinte du fichier chiffré, mais elle est vulnérable aux mêmes attaques que l’approche H( Â 4 ,K) [1276].
CAM à partir d’un chiffrement en continu Ce schéma de C A M utilise les chiffrements en continu (voir la figure 18.15) [948]. Un générateur pseudo-aléatoire de bits cryptographiquement sûr démultiplexe le flux de message en deux sous-flux. Si le bit de sortie du générateur de bit kz est 1, alors le bit courant du message m, est envoyé au premier sous-flux; si U vaut 0, est envoyé au deuxième sous-flux. Les sous-flux sont chacun fournis comme entrée à un R D R L différent (voir § 16.2). Le résultat de la C A M est donné simplement par les états finaux des registres à décalage.
F ig. 18.15 - Chiffrement en continu — C A M Malheureusement, cette méthode n ’est pas à l’épreuve de petits changements dans le message [1527]. Par exemple, si vous modifiez le dernier bit du message, il suffit de modifier deux bits de l’empreinte pour en obtenir une fausse; cela est faisable avec une probabilité raisonnable. Les auteurs présentent une alternative plus sûre et plus compliquée.
Chapitre 19
Algorithmes à clef publique 19.1
Introduction
Le concept de cryptographie à clef publique fut inventé par Whitfield D i f f i e et Martin H e l l m a n , et indépendamment par Ralph M e r k l e . L’idée neuve dans le domaine était que les clefs pouvaient être des paires — une clef de chiffrement et une clef de déchiffrement — et qu’il était impossible de générer une clef à partir de l’autre (voir § 2.5). D i f f i e et H e l l m a n ont présenté ce concept pour la première fois en 1976 à la « National Computer Conférence » [493] ; quelques mois après, leur article « New Directions in Cryptography » paraissait dans « IEEE Transactions on Information Theory » [494]1. Depuis 1976, de nombreux algorithmes de cryptographie à clef publique ont été propo sés. Nombre d’entre eux ne sont pas sûrs. Parmi ceux qui sont encore considérés comme sûrs, nombre d’entre eux ne sont pas pratiques. Soit ils ont une clef exagérément grande, soit le texte chiffré est nettement plus long que le texte en clair. Seuls quelques algorithmes sont à la fois sûrs et pratiques. Ces algorithmes sont en général basés sur l’un des problèmes difficiles décrits dans le paragraphe 11.2. De ces algorithmes à clef publique sûrs et pratiques, certains ne sont adaptés qu’à la distribu tion de clefs. D ’autres sont adaptés au chiffrement (et, par extension, à la distribution de clefs). D ’autres ne sont adaptés qu’aux signatures numériques. Seuls trois algo rithmes sont adéquats à la fois pour le chiffrement et les signatures numériques : RSA , E l G a m a l et R a b i n . T o u s ces algorithmes sont lents. Les vitesses de chiffrement et de déchiffrement sont nettement plus faibles que pour les algorithmes à clefs secrètes ; habituellement c’est trop lent pour le chiffrement de données en masse. Les systèmes hybrides (voir § 2.5) permettent d’augmenter la vitesse : un algorithme avec une clef secrète aléatoire sert à chiffrer le message, et un algorithme à clef public sert à chiffrer la clef.
I. D u fait des délais de publication exagérés des « C o m m u n ic a tio n s o f th e A C M », la première contribution de M e r k l e au dom aine ne parut pas avant 1978 [1073].
486
Chapitre 19
Algorithmes à clef publique
Sécurité des algorithmes à clef publique Comme les cryptanalystes ont accès à la clef publique, ils peuvent toujours choisir n’importe quel message à chiffrer. Cela veut dire qu’étant donné C = E k (A4), les cryptanalystes peuvent deviner la valeur de M et aisément vérifier leur pari. C ’est un problème sérieux si le nombre de messages en clair possible est assez petit pour permettre une recherche exhaustive, mais peut être résolu en rajoutant une chaîne de bits aléatoires au message. Cela signifie que des textes en clair identiques donneront des textes chiffrés différents (pour plus de détails concernant ce concept, voir § 23.15). Cela est particulièrement important lorsqu’un algorithme à clef publique sert à chiffrer une clef de session. Estelle peut générer une base de données de toutes les clefs de session possibles chiffrées avec la clef publique de Bernard. Cela représente évidemment une somme énorme de travail et de mémoire, mais pour une clef exportable de 40 bits ou une clef de 56 bits du DES, c’est beaucoup moins que ce qu’il faudrait pour casser la clef publique de Bernard. Une fois qu’Estelle aura généré la base de donnée, elle pourra trouver facilement toutes les clefs de session et lire le courrier électronique de Bernard. Les algorithmes à clef publique sont conçus pour résister aux attaques à texte en clair choisi ; leur sécurité dépend à la fois de la difficulté de déduire la clef privée à partir de la clef publique et de la difficulté de déduire le texte en clair à partir du texte chiffré. Toutefois, la plupart des algorithmes à clef publique sont particulièrement sensibles à ce que l’on appelle une attaque à texte chiffré choisi (voir § 1.1). Dans les système où la signature numérique est l’opération du chiffrement, il est im possible d’empêcher cette attaque à moins d’utiliser des paires de clefs différentes pour le chiffrement et la signature numérique. En conséquence, il est important de considérer le système comme un tout et non pas seulement comme des parties individuelles. Les bons protocoles à clef publique sont conçus de telle manière que les différents participants ne déchiffrent pas n’importe quel message engendré par les autres participants ; la preuve d ’identité est un bon exemple (voir § 5.2).
19.2
Algorithmes à empilement
Le premier algorithme pour le chiffrement à clef publique généralisé fut développé par Ralph M e r k l e et Martin H e l l m a n [715, 1080]. Il ne peut être utilisé que pour le chiffrement bien que S h a m i r ait adapté plus tard le système pour les signatures numériques [1420]. Les algorithmes à empilement2 tirent leur sécurité du problème d ’empilement, un problème TVP —co m p le t. Bien qu’on ait découvert après coup que cet algorithme n’est pas sûr, il vaut la peine d’être examiné parce qu’il montre comment des problèmes À’ P -co rn p le ts peuvent être utilisés pour la cryptographie à clef publique. Le problème d ’empilement est un problème simple. Etant donné un tas d’objets, chacun ayant un poids différent, est-il possible de faire un nouveau tas avec certains de ces objets de telle manière que le nouveau tas pèse un poids donné ? Plus formellement : étant donné un ensemble de valeurs, et une somme S, calculer les valeurs 2. N ote du traducteur : la traduction « p ro b lè m e d ’e m p ile m e n t » a été utilisée pour l’expression anglaise : « k n a p sa ck p ro b lem » que d ’ autres traducteurs ont égalem ent appelé « p ro b lè m e du sa c à dos » [240].
19.2
Algorithmes à empilement
des bi de telle m anière que :
S — b%Mi + 62 M 2 + ... + bnM n.
Les valeurs des bi étant soit 0 soit 1. Un 1 indique que l’élément est dans le nouveau tas ; un 0 indique qu’il n’y est pas. Par exemple, les objets pourraient avoir les poids suivants: 1, 5, 6, 11, 14 et 20. II est possible de créer un tas qui pèse 22; utilisez les objets pesant 5, 6 et 11. Il est impossible de créer un tas qui pèse 24. En général, le temps nécessaire pour résoudre ce problème semble croître exponentiellement avec le nombre d ’objets dans le nouveau tas. L ’idée de base de l ’algorithm e à em pilem ent M
erkle
--H E LLM A N est de coder le mes
sage com m e une solution d ’une suite de problèm es d ’em pilem ent. U n b lo c de texte en clair de longueur égale au nom bre d ’o bjets dans le tas sélectionnerait des objets (les bits du texte en cla ir correspondraient aux valeurs des 6, : un 1 signifierait que l ’objet est présent et u n 0 signifierait que l ’o bjet est absent) et le texte chiffré serait la somme résultante. L a figure
19.1 illustre u n texte en cla ir chiffré avec un exemple de problèm e
d ’empilement.
Texte en clair: Tas: Texte chiffré:
1 1 1
0
0 1
0 10
1 1
1 5 6 11 14 20
1 5 6 11 14
1+5+6+20
5+11+14 =
20
0 0
0
0 11
0 0
0
1 5 6 11 14 20
1 5 6 11 14 20
0 =
5+6 =
30
32
F ig. 19.1
0 0 0 0
0
11
Chiffrement par empilement
Le truc ici est qu’il y a en fait deux problèmes d’empilement, l’un soluble en temps linéaire, l’autre soluble en temps exponentiel seulement. L’empilement facile peut être transformé pour créer un empilement difficile. La clef publique est l’empilement difficile, qui peut être facilement utilisée pour chiffrer des messages mais qui ne peut pas être utilisée pour déchiffrer des messages. La clef privée est l’empilement facile qui donne un moyen simple de déchiffrer les messages. Les gens qui ne connaissent pas la clef privée sont obligés d’essayer de résoudre le problème d ’empilement difficile.
Empilement super-croissant Qu’est-ce qu’un problème d ’empilement facile? Si la liste des poids est une suite super-croissante, alors le problème d ’empilement correspondant est facile à résoudre. Une suite super-croissante est une suite dans laquelle tout terme est plus grand que la somme de tous les termes qui précèdent. Par exemple, {1,3,6,13,27,52} est une suite super-croissante tandis que {1,3,4,9,15,25} ne l’est pas. La solution d ’un empilement super-croissant est facile à trouver. Prenez le poids total et comparez-le avec le plus grand nombre de la suite. Si le poids total est inférieur à ce nombre, alors il n’est, pas dans le tas. Si le poids total est supérieur ou égal au nombre, alors il est dans le tas. Réduisez le poids du tas à créer de ce nombre et passez au plus grand-nombre suivant de la suite. Répétez cela jusqu’à ce que ce soit terminé. Si le poids total a été ramené à 0, alors il y a une solution. Si le poids total n’a pas été annulé, il n’y a alors pas de solution.
488
Chapitre 19
Algorithmes à clef publique
Par exemple, considérez un tas de poids total de 70 à créer et une suite de poids {2,3,6,27,52}. Le poids le plus élevé est 52, ce qui est inférieur à 70, donc 52 est dans le nouveau tas. Retirer 52 à 70 laisse 18. Le poids suivant est 27 qui est plus grand que 18 et donc 27 n ’est pas dans le nouveau tas. Le poids suivant 13 est inférieur à 18, donc 13 est dans le nouveau tas. Retirer 13 à 18 donne 5. Le poids suivant est 6. qui est plus grand que 5, donc 6 n’est pas dans le nouveau tas. Continuer ainsi montre que 2 et 3 se trouvent aussi dans le nouveau tas et le poids est ramené à 0, ce qui indique qu’une solution a été trouvée. Si cela avait été un bloc chiffré par empilement M e r k l e H e l l m a n , alors le texte en clair correspondant au texte chiffré de valeur 70 aurait été 110101. Avec des suites qui ne sont pas super-croissantes, on ne connaît pas d ’algorithme rapide. Le seul moyen de déterminer quels sont les objets dans le nouveau tas est de tester méthodiquement toutes les solutions possibles jusqu’à ce que l’on tombe sur la bonne. Les algorithmes les plus rapides, prenant en compte les heuristiques nécessaires, sont exponentiels en fonction du nombre de poids possibles dans le tas. Ajoutez un poids à la suite des poids et il faut deux fois plus de temps pour trouver la solution. C’est nettement plus difficile qu’avec une suite super-croissante où, si vous ajoutez un poids à la suite, cela ne fait qu’une opération de plus. L ’algorithme M e r k l e H e l l m a n est basé sur cette propriété. La clef privée est une suite de poids super-croissante pour un problème d ’empilement. La clef publique est une suite de poids pour un problème d’empilement normal avec la même solution. M e r k l e et H e l l m a n ont développé une technique pour convertir un problème d’empilement super-croissant en un problème d ’empilement normal. Ils ont fait cela en utilisant l’arithmétique modulaire.
Création de la clef publique à partir de la clef privée Sans entrer dans les détails de la théorie des nombres, voici comment l’algorithme marche : pour obtenir une suite pour empilement normale, prenez une suite pour empi lement super-croissante, par exemple {2,3,6,27,52} et multipliez toutes les valeurs par un nombre n modulo m. Le module doit être un nombre plus grand que la somme de tous les nombres de la suite, 105 par exemple. Le multiplicateur ne doit avoir de fac teur en commun avec aucun nombre de la suite, 31 par exemple. La suite d ’empilement normale serait alors : (2 x 31) mod 105 (3 x 31) mod 105
=
62
=
93
(6 x 31) mod 105 (13 x 31) mod 105
=
81
=
88
(27 x 31) mod 105
=
102
(52 x 31) mod 105
=
37
L ’empilement difficile est alors {62,93,81,88,102,37}. La suite pour empilement super-croissante est la clef privée. La suite pour empilement normale est la clef publique.
19.2
Algorithmes à empilement
489
Chiffrement Pour chiffrer un message binaire, coupez d’abord le message en morceaux de longueur égale au nombre d ’objets dans la suite pour empilement. Ensuite, en prenant la conven tion qu’un 1 indique que l’objet figure dans le tas et qu’un 0 indique que l’objet est absent, calculez le poids total des tas. Par exemple, si le message est 011000110101101110, le chiffrement en utilisant la suite ci-dessus se fait de la façon suivante : message = 011000
110101
101110
011000 donne 93 + 81 = 174 110101 donne 62 + 93 + 88 + 37 = 280 101110 donne 62 + 81 + 88 + 102 = 333 Le texte chiffré sera alors : 174,280,333
Déchiffrement Un destinataire légitime de ce message connaît la suite super-croissante originelle, ainsi que les valeurs n et m utilisées pour la transformer en une suite normale. Pour déchiffrer le message, le destinataire doit d’abord calculer n ~x tel que n x n-1 = 1 (mod m) et ensuite multiplier chaque valeur du texte chiffré par n ' 1 mod m pour retrouver les valeurs du texte en clair. Pour notre exemple, la suite super-croissante est {2,3,6,13,27,52}, m vaut 105 et n vaut 31. Le message chiffré est 174,280,333. Dans ce cas, n ~ x vaut 61 et les valeurs chiffrées doivent donc être multipliées par 61 mod 105. 174 x 61 mod 105 = 9 = 3 + 6, ce qui Correspond à 011000 280 x 61 mod 105 = 70 = 2 -f 3 -f 13 + 52, ce qui correspond à 110101 333 x 61 mod 105 = 48 = 2 + 6 + 13 + 27, ce qui correspond à 101110. Le texte en clair correspondant est
011000
110101
101110.
Réalisations pratiques Avec une suite pour empilement de six éléments, il n’est pas difficile de résoudre le problème même si la suite n’est pas super-croissante. Les vrais empilements contiennent au moins 250 éléments. La valeur de chaque terme de la suite super-croissante est longue de 200 à 400 bits. Le module est choisi pour avoir une longueur comprise entre 100 et 200 bits. Les réalisations concrètes de l’algorithme utilisent un générateur de séquences aléatoires pour produire ces valeurs. Il serait vain d ’essayer de résoudre des empilements tels que ceux-là. Si un ordina teur peut essayer un million de possibilités par seconde, essayer tous les empilements possibles prendrait plus de 1046 années. Même un million de machines travaillant en parallèle ne résoudraient pas le problème avant que le soleil ne se transforme en nova.
490
Chapitre 19
Algorithmes à clef publique
Sécurité des empilements Ce n’est pas un million de machines qui ont cassé le système à empilement mais bien deux cryptographes. Premièrement, H e r l e s t a m remarqua que souvent un bit du texte en clair pouvait être retrouvé [727], Ensuite, S h a m i r a montré que l’algorithme pouvait être cassé dans certaines circonstances [1422, 1423]. Il y eut d ’autres résultats— [1434, 39, 756, 518, 486]— mais aucun ne permettait de casser le système M e r k l e - H e l l m a n général. Finalement, S h a m i r et Z i p p e l [1427, 1425, 1428] trouvèrent des failles dans la transformation qui permettait de reconstruire la suite super-croissante à partir de la suite normale. L’argumentation exacte dépasse le cadre de cet ouvrage, mais un bon résumé peut être trouvé dans [1243, 1254]. A la conférence où les résultats furent présentés dans [490, 492], la démonstration de l’attaque fut réalisée sur l’estrade à l’aide d ’un ordinateur A p p l e II.
Variantes du système à empilement Depuis que le schéma initial M e r k l e - H e l l m a n a été cassé, de nombreux autres sys tèmes à empilement ont été proposés : empilements à itérations multiples, empilement de Graham- Shamir, etc. Ils ont tous été analysés et cassés, en utilisant généralement les mêmes techniques cryptographiques, et ils empilement encombrent l’autoroute de la cryptologie [264, 257, 273, 932, 19, 930, 931, 933, 370, 258, 267, 259]. Un bon aperçu de ces systèmes et de leur cryptanalyse peut être trouvé dans [271, 478, 261, 272]. D ’autres systèmes cryptographiques qui utilisent des idées similaires aux empilements ont été proposés mais ils ont été également cassés. Le cryptosystème L u - L e e [1000, 17] a été cassé dans [24, 616, 874] ; une version modifiée [508] n’est pas sûre non plus [1622]. Les attaques contre le cryptosystème G o o d m a n - M c A u l e y sont décrites dans [648, 649, 271, 272]. Le cryptosystème P i e p r z y k [1256] peut être cassé par des attaques similaires. Le cryptosystème NlEM) [749], basé sur des empilements modulaires, a été cassé dans [349, 788]. Une version plus récente d’empilement à plusieurs étages [7491 n’a pas encore été cassée, mais je ne suis pas optimiste. Une autre variante est décrite dans [298]. Bien qu’il existe encore une variante de l’algorithme à empilement qui est toujours sûre à l’heure actuelle— l’empilement C h o r R i v e s t [360], malgré une « attaque spéciali sée » [745]— la quantité de calculs nécessaires le rend nettement moins utilisable que les autres algorithmes décrits ici. Une variante du nom de système P O W E R L IN E n’est pas sûre [969]. Plus important, étant donné la vitesse à laquelle les autres variantes sont tombées, il ne semble pas prudent d ’avoir confiance en celles-ci.
Brevets L’algorithme M e r k l e H e l l m a n originel est breveté aux Etats-Unis [723] et dans le monde entier (voir le tableau 19.1). P K P octroie des licences d ’exploitation de ce brevet ainsi que d ’autres brevets de cryptographie à clef publique (voir § 25.5). Toute personne intéressée par l’obtention d’une telle licence doit contacter: Robert B. Fougner, D ir e cto r o f L ice n sin g , P u b lic Key P artn ers, 310 N Mary Avenue, Sunnyvale, CA 94086, T e l: +1 (408) 735-5893. Le brevet américain expire le 19 août 1997.
19.3
491
RSA
T
ab
19.1 - Brevets pour l ’empilement Pays Belgique Pays-Bas Grande-Bretagne Allemagne Suède France Allemagne Allemagne Canada Grande-Bretagne Suisse Italie
19.3
M
Numéro 871039 7810063 2006580 2843583 7810478 2405532 2843583 2857905 1128159 2006580 63416114 1099780
erkle
H ellm
an
dans le monde
Date 5 avril 1979 10 avril 1979 2 mai 1979 10 mai 1979 14 mai 1979 8 juin 1979 3 juin 1982 15 juillet 1982 20 juillet 1982 18 août 1982 14 janvier 1983 28 septembre 1985
RSA
Peu après l’algorithme à empilement de M e r k l e , le premier algorithme à clef publique grandeur nature apparut. Il fonctionne pour le chiffrement aussi bien que pour les signatures numériques: R SA [1339, 1340]. De tous les algorithmes à clef publique proposés tout au long de ces années, c ’est de loin le plus facile à comprendre et à réaliser3. C ’est le plus populaire. Baptisé d ’après le nom de ses inventeurs, Ron R i v e s t , Adi S h a m i r et Léonard A d l e m a n , il a résisté depuis à des années de cryptanalyse intensive. Bien que la cryptanalyse n’ait jamais prouvé la sécurité ou la non-sécurité de R SA , cela inspire un certain niveau de confiance dans l’algorithme. Le niveau de sécurité du R S A dépend de la difficulté de factoriser des grands nombres. Les clefs publique et privée sont des fonctions d’une paire de grands nombres premiers (100 à 200 chiffres ou plus encore). Retrouver le texte en clair à partir d ’une des clefs et du texte chiffré est supposé équivalent à la factorisation du produit des deux nombres premiers. Pour engendrer les deux clefs, choisissez deux grands nombres premiers, p et q. Calculez le produit : n - pq.
Choisissez ensuite une clef de chiffrement aléatoire e telle que e et (p — l ) ( ç — 1) soient premiers entre eux. Finalement, utilisez l’algorithme d’Euclide pour calculer la clef de déchiffrement d de telle manière que : ed = 1
(mod (p — l ) ( ç — 1)).
En d ’autres termes : d — e~ x mod ((p — l ) ( ç — 1)).
Remarquez que d et n sont aussi premiers entre eux. Les nombres e et n forment la clef publique, le nombre d est la clef privée. Les deux nombres premiers p et g ne sont plus nécessaires. Ils peuvent être écartés mais jamais révélés. 3. M artin G a r d n e r publia une première description de l’ algorithm e dans sa colonne « M a th em a tica l G a m es » du S c ie n tific A m e r ic a n [602].
Chapitre 19
Algorithmes à clef publique
Pour chiffrer un message m, découpez celui-ci en blocs numériques tels que chaque bloc ait une représentation unique modulo n (avec des données binaires, choisissez la plus grande puissance de 2 inférieure à n). Ainsi, si p et q sont tous deux des nombres premiers de 100 chiffres, alors n aura tout juste moins de 200 chiffres et chaque bloc de message m, doit avoir juste moins de 200 chiffres. Le message chiffré c sera constitué de manière similaire de blocs ct d ’à peu près la même longueur. La formule de chiffrement est simplement : Cî = ml mod n. Pour déchiffrer un message, prenez chaque bloc ct et calculez : m t = cf mod n. Puisque (toutes les opérations étant effectuées modulo n) : cf = ( ml)d = raf* = m *0’- 1h 9 -P + 1 — m l x
= m , x l = mi,
la formule ci-dessus permet de retrouver la message. Ceci est résumé par le tableau 19.2.
T
ab
.
19.2 - Chiffrement R SA
C lef publique : n produit de deux nombres premiers, p et q (p et q doivent rester secrets) e premier par rapport à {p — l ) ( ç — 1) C lef privée : d = e-1 mod ((p — l ) ( ç — 1)) Chiffrement : c = me mod n Déchiffrement : m = cd mod n Le message aurait tout aussi bien pu être chiffré avec d et déchiffré avec e ; le choix est arbitraire. Je n’inclus pas ici la théorie des nombres qui prouve que cela marche; les textes récents sur la cryptographie couvrent cette théorie en détail. Un petit exemple contribuera certainement à rendre tout cela plus clair. Si p = 47 et q — 71 alors : n = pq = 3337. La clef de chiffrement e ne doit pas avoir de facteurs communs avec : (p — l ) ( ç — 1) = 46 = 3220. Choisissez e (aléatoirement) égal à 79. Dans ce cas : d = 79“ 1 mod 3220 = 1019.
Ce nombre a été calculé en utilisant l’algorithme d ’Euclide étendu (voir § 11.3). Publiez e et n et gardez d secret. Jetez p et q. Pour chiffrer le message : m = 688232687966683
19.3
493
RSA
divisons-le d’abord en petits blocs. Des blocs de trois chiffres conviendront dans ce cas-ci. Le message est divisé en 6 blocs rrii tels que : mi
=
688
m2
=
232
m3
=
687
m4
=
966
m5
=
668
me
=
3.
Le premier bloc est chiffré par : 68879 mod 3337 = 1570 = <*. En effectuant la même opération pour tous les blocs, on obtient le message chiffré : c = 1570 2756 2091 2276 2423 158. Pour déchiffrer le message, il faut effectuer les mêmes exponentiations mais en utilisant la clef de déchiffrement 1019. Donc : 15701019 m od 3337 = 688 = m ,. Le reste du message est obtenu de la même manière.
RSA en matériel On a beaucoup écrit sur le sujet des réalisations matérielles du R S A [1325,1480,1462, 1327, 1492, 875, 1231, 94, 1415, 1414, 1355, 1342, 371, 1435, 525, 772]. De bons articles résumés sont [262, 873]. De nombreuses puces différentes qui réalisent le R SA ont été construites [1321, 256, 1108, 1328, 875, 74, 739, 596, 1286, 1565, 510, 1232], Une liste partielle des puces R S A actuellement disponibles, extraite de [157, 262], est donnée par le tableau 19.3. Elles ne sont pas toutes sur le marché.
Vitesse du RSA A sa vitesse maximum, le R S A est environ 1000 fois plus lent que le DES. La réalisation matérielle VLSI la plus rapide du R SA avec un module de 512 bits a un débit de 64 kilo-bits par seconde [262]. Il existe aussi des puces qui effectuent le chiffrement R SA à 1024 bits. Actuellement, des puces qui approcheraient le million de bits par seconde avec un module de 512 bits sont prévues, elles devraient être disponibles en 1995. Certains fabricants ont réalisé le R S A dans les cartes à puce; ces réalisations sont plus lentes. En logiciel, le DES est environ 100 fois plus rapide que le R SA . Ces nombres pourraient changer légèrement, avec les changements de technologie mais le R SA n’approchera jamais la vitesse des algorithmes à clef secrète. Le tableau 19.4 compare les vitesses de quelques réalisations en logiciel de R S A [929].
Chapitre 19
494
T
a b
Vitesse Société d ’horloge Alpha Techn. 25 MHz A T& T 15 MHz British Telecom 10 MHz 5 MHz Business Sim. Ltd. Calmos Syst. Inc. 20 MHz CNET 25 MHz Cryptech 14 MHz Cylink 16 MHz Pijnenburg 25 MHz 8 MHz Sandia Siemens 5 MHz
.
19.3
Algorithmes à clef publique
Puces R SA existantes
Vitesse de transmission par 512 bits 13 K 19 K 5,1 K 3,8 K 28 K 5,3 K 17 K 6,8 K 50 K 10 K 8,5 K
Cycles d ’ horloge par chiffrement de 512 bits 0,98 M 0,4 M 1M 0,67 M 0,36 M 2,3 M 0,4 M 1,2 M 0,256 M 0,4 M 0,03 M
Bits Nombre par de puce transistors Technologie 1024 2g 180 000 l,5 p 298 100000 — 256 2,5p 32 — Réseau logique 2p 593 95 000 1024 100000 lp Réseau logique 120 33 000 1024 150 000 l,5 p 1024 lp 400 000 272 2p 86 000 512 lp 60 000
T a b . 19.4 -
Vitesses de R SA pour différentes longueurs de module avec une clef pu blique de 8 (sur une station SP A R C II,) Chiffrement Déchiffrement Signature Vérification
512 bits 0,03 s 0,16 s 0,16 s 0,02 s
768 bits 0,05 s 0,48 s 0,52 s 0,07 s
1024 bits 0,08 s 0,93 s 0,97 s 0,08 s
Optimisation en logiciel Le chiffrement par R S A est bien plus rapide si vous choisissez bien la valeur de e. Les choix les plus courants sont 3, 17 et 65537 (216 + 1 )4. X .509 recommande 65537 [309], PE M recommande 3 [83], et P K C S # 1 (voir § 24.14) recommande 3 ou 65537 [919]. Aucun problème de sécurité n’interdit de prendre l’une de ces trois valeurs pour e (à condition de combler le message par remplissage avec des valeurs aléatoires— voir le paragraphe suivant), même si tout un groupe d ’utilisateurs utilise la même valeur. Les opérations avec la clef privée peuvent s’exécuter plus rapidement grâce au théorème du reste chinois si vous conservez les valeurs de p et q, ainsi que d ’autres telles que d mod (p — 1), d mod ( q — 1) et q 1 mod p [1294, 1287]. Ces nombres supplémentaires se calculent facilement à partir des clefs publique et privée.
Sécurité de RSA La sécurité de R S A dépend entièrement du problème de la factorisation de grands nombres. Techniquement, ce n’est pas vrai. Il a été conjecturé que la sécurité de RSA dépend du problème de la factorisation de grands nombres. Il n’a jamais été prouvé mathématiquement que vous devez factoriser n pour calculer m à partir de c et e. Il est concevable qu’un tout autre moyen de cryptanalyser R S A soit découvert. Toutefois, 4. Les représentations binaires de ces nombres ne présentent que deux 1, aussi le calcul de leur puissances ne requiert que 17 m ultiplications.
19.3
495
RSA
si cette nouvelle voie permettait aux cryptanalystes de retrouver d, cela pourrait aussi être utilisé comme une nouvelle voie pour la factorisation de grands nombres. Je ne me tracasserais pas trop à ce propos. Il est aussi possible d’attaquer R SA en essayant de deviner la valeur de (p — 1)(q — 1). Cette attaque n’est pas plus facile que la factorisation de n [1618]. Pour les ultra-sceptiques, il y a des variantes de R S A qui ont été prouvées aussi difficiles que la factorisation (voir § 19.5). Voyez également [37], qui montre que même retrouver un seul bit d’information à partir d’un texte chiffré par R SA est aussi difficile que de déchiffrer le message en entier. Factoriser n est l’attaque la plus évidente. Les adversaires auront la clef publique e et le module n. Pour trouver la clef de déchiffrement, d, ils doivent factoriser n. Le para graphe 11.4 décrit l’état de l’art de la technologie de la factorisation. Actuellement, des nombres de 129 chiffres sont à la pointe de ce qui se fait en technologie de factorisation. n doit donc être supérieur à cela. Lisez également le paragraphe 7.2 sur la longueur des clefs publiques. II est certainement possible pour un cryptanalyste d ’essayer toutes les valeurs possibles de d jusqu’à tomber sur la bonne. Cette attaque exhaustive est encore moins efficace que d’essayer de factoriser n. De temps en temps des gens prétendent avoir trouvé un moyen facile de casser RSA, mais leurs revendications ne durent pas. Par exemple, William P a y n e proposait en 1993 une méthode basée sur le petit théorème de F e r m â t [1244]. Malheureusement, cette méthode est aussi plus lente que la factorisation du module. Il y a une autre inquiétude. La plupart des algorithmes usuels de calcul de nombres pre miers p et q sont, probabilistes ; que se passe-t-il si p ou g est composé? Premièrement, vous pouvez les rendre les chances que cela arrive aussi minces que vous le désirez. Et si cela arrive, il y a de grandes chances que le chiffrement et le déchiffrement, ne fonctionnent pas normalement— vous le remarquerez tout de suite. U y a très peu de nombres sur lesquels les algorithmes probabilistes de test de primalité échouent, on les appelle les nombres de Carmichael. Us sont excessivement rares, mais ils ne sont pas sûrs [748]. Honnêtement, je ne m ’en inquiéterais pas.
Attaque à texte chiffré choisi contre le RSA Certaines attaques tirent profit de la réalisation de R S A ; elles ne sont pas dirigées contre l’algorithme lui-même, mais contre le protocole. Ils est important de réaliser qu’il ne suffit pas d’utiliser le R SA , les détails comptent. S c é n a r i o 1 : Estelle, qui écoute la ligne de communication d’Alice, s’arrange pour collecter un message c, chiffré par R S A avec sa clef publique. Estelle veut être capable de lire le message. Mathématiquement, elle veut m tel que :
m = cd. Pour retrouver m, elle choisit d’abord un nombre aléatoire r, tel que r soit, inférieur à n. Elle obtient la clef publique d ’Alice, e. Ensuite elle calcule : x = re mod n
y = xc m od n
Chapitre 19
496
Algorithmes à clef publique
t — r 1 mod n.
Si x = re mod n, alors r = x d mod n. Et donc, t = x ~ d mod n. Maintenant, Estelle fait signer y par Alice avec sa clef privée, déchiffrant ainsi y. Alice doit signer le message, pas l’empreinte du message. Rappelez-vous qu’Alice n ’a jamais vu y avant. Alice envoie à Estelle : u = y d mod n.
Maintenant, Estelle calcule : tu mod n — x ~dyd mod n = x ~ dx dcd mod n = cd mod n = m.
Ce qui lui permet de disposer maintenant de m. S cén ario 2 : Ivan est un notaire informatisé. Si Alice veut un document notarié, elle l’envoie à Ivan. Ivan le signe avec une signature numérique R SA et le renvoie5. Martin veut faire signer par Ivan un message qu’autrement ce dernier refuserait de signer. Peut-être ce message a-t-il une datation factice, ou peut-être que ce message est une mascarade. Peu importe la raison, Ivan ne signerait jamais ce message s’il avait le choix. Appelons ce message m'. Martin choisit une valeur arbitraire x et calcule y — x e mod n. Il peut aisément obtenir e ; c ’est la clef publique d ’Ivan et elle doit être publique pour permettre la vérification de sa signature. Ensuite il calcule m = ym! mod n et envoie m à Ivan pour qu’il le signe. Ivan renvoie rnd mod n. A présent, Martin calcule ( (rad mod ti)x~1) mod n qui est égal à m'd mod n et constitue donc une signature de m'. En fait, il y a diverses manières pour Martin de réaliser la même chose [425, 464, 484]. La faiblesse qu’elles exploitent toutes est. le fait que l’exponentiation préserve la structure multiplicative de l’entrée. C ’est-à-dire : {xm )d mod n — x dm d mod n.
S cén ario 3 : Estelle veut qu’Alice signe « 1 3 . Elle engendre deux messages m i et tels que : m 3 s m im 2 (mod n).
«2
Si elle arrive à faire signer m 1 et m 2 par Alice, Estelle peut calculer la signature de m3 : md = (md mod n)(md mod n) mod n. M o ra lité : N’utilisez jamais le R SA pour signer un document quelconque qui vous est présenté par un inconnu. Le bloc de formatage de la norme ISO 9796 empêche cette attaque.
Attaque par module commun contre le RSA Rendons la vie plus facile et donnons le même n à tout le monde. Ils peuvent avoir des valeurs différentes pour e et d, mais la même valeur de n. Malheureusement, cela 5. O n n ’ utilise pas de fonction de hachage à sens unique ici ; Ivan chiffre le message en son intégralité avec sa clef privée.
19.3
RSA
ne fonctionne pas. Le défaut le plus évident est que si le même message est chiffré avec deux clefs différentes (toutes les deux avec le même module), et que ces deux clefs sont premières entre elles (ce qu’elles sont en général), alors le texte en clair peut être retrouvé sans aucune des deux clefs de déchiffrement [1463]. Soit A4 le message en clair. Les deux clefs de chiffrement sont ei et 6 2 . Le module commun est n. Les deux messages chiffrés sont : C\ --- A4ei mod n Ci — A4 62 mod n.
Le cryptanalyste connaît n, ej, e2, Cj et C2. Voici comment il peut retrouver A4. Comme rq et e 2 sont premiers entre eux, l’algorithme d’Euclide permet de trouver r et s tels que : r x ei + s x e 2 =
1
.
En faisant l’hypothèse que r est négatif (soit r soit s doit l’être), alors l’algorithme d’Euclide peut être utilisé à nouveau pour calculer C ÿ1. Donc : (C f1)~r x C2 = A4 mod n. Il existe deux autres attaques, plus subtiles, contre un tel système. L ’une utilise une méthode probabiliste de factorisation de n. L’autre utilise un algorithme déterministe pour calculer la clef privée de quelqu’un sans factoriser le module. Les deux attaques sont décrites en détail dans [452]. Moralité : Ne partagez jamais n parmi un groupe d’utilisateurs.
Attaque par petit exposant de chiffrement contre le RSA Le chiffrement et la signature sont plus rapides si vous prenez une petite valeur pour e, mais cela risque de ne pas être sûr [705]. Si vous chiffrez e ( e + l ) / 2 messages linéairement dépendants avec des clefs publiques différentes mais la même valeur de e, il est possible d’attaquer le système. S’il n’y a pas autant de messages, ou s’ils sont indépendants, il n’y a pas de problème. Si les messages sont identiques, alors e suffisent. La solution la plus facile consiste à combler les messages par remplissage avec des valeurs aléatoires indépendantes. Cela évite aussi d ’avoir A4e mod n — A4e. La plupart des réalisation de R SA , telles que P E M et P G P (voir § 24.10 et 24.12) par exemple, font cela. Moralité : Comblez les messages par remplissage avec des valeurs aléatoires avant de les chiffrer, assurez vous que A4 a au moins même taille que n.
Attaque par petit exposant de déchiffrement contre le RSA Une autre attaque, de Michael W i E N E R permet de retrouver d quand d est inférieur au quart de la longueur du module et e est inférieur à n [1598]. Ceci n’arrive que rarement si e et d sont choisis aléatoirement, et ne peut pas arriver si e est petit. Moralité : Choisissez une grande valeur pour d.
Chapitre 19
498
Algorithmes à clef publiqw
Leçons apprises M o o r e énumère plusieurs restrictions de l’utilisation du R S A basées sur ces attaques réussies [1 1 2 0 , 1 1 2 1 ]:
- La connaissance d ’une paire chiffrement-déchiffrement d ’exposants pour un mo dule donné permet à l’attaquant de factoriser le module. - La connaissance d’une paire chiffrement-déchiffrement d ’exposants pour un mo dule permet à l’attaquant de calculer d ’autres paires chiffrement-déchiffrement sans devoir factoriser n. - Un module commun ne peut pas être utilisé dans un protocole qui utilise le RSA
dans un réseau de communication6. Les messages doivent être comblés par remplissage avec des valeurs aléatoires pour empêcher les attaques par petit exposant de chiffrement. - L’exposant de déchiffrement choisi pour un protocole doit être grand. Rappelez-vous qu’il n’est pas suffisant d ’avoir un algorithme cryptographique sûr. Tou le cryptosystème doit être sûr et le protocole cryptographique aussi. S’il y a la moindri faille dans une de ces trois zones, le système entier n’est pas sûr.
Attaque sur le chiffrement et la signature par RSA Il est sensé de signer un message avant de le chiffrer (voir § 2.7), mais tout le mondi ne suit pas cette pratique. Avec le R SA , il existe une attaque contre les protocoles qu chiffrent avant de signer [49]. Alice veut envoyer un message à Bernard. Elle commence par le chiffrer avec la cle publique de Bernard, puis le signe avec sa clef privée. Son message chiffré et sigm ressemble à ceci : (A4eB mod riB)dA m od n a
Voilà comment Bernard peut prétendre qu’Alice lui a envoyé A4' et non A4. Comm Bernard connaît la factorisation de % (c’est son module), il peut calculer les loga rithmes discrets modulo n s- H lui suffit alors de trouver x tel que A41 ,x = A4 mod ng.
Il publie alors x e s comme étant sa nouvelle clef publique en gardant tib comme module Il peut ainsi prétendre que Alice lui a envoyé le message A4' chiffré avec ce nouve exposant. Cette attaque est particulièrement pénible dans certaines circonstances. Une fonctio] de hachage ne résoud pas le problème. Cependant, imposer à chaque utilisateur ui exposant de chiffrement fixe le résoud. 6. Ceci doit être évident à partir des deux points précédents.
19.4
P o h l ig - H
499
ellm an
Standards RSA est un standard de facto pratiquement dans le monde entier. L ’Organisation internationale de normalisation a pratiquement créé un standard R S A de signatures numériques; le R S A figure en annexe de l’IS O /IE C 9796 [767]. La communauté bancaire française a standardisé le R SA [514] ainsi que les australiens [1198]. Les EtatsUnis n’ont actuellement pas de standard de cryptographie à clef publique à cause des pressions de la N SA et de problèmes de brevets. De nombreuses sociétés américaines utilisent PK C S (voir § 24.14) qui est un produit de R S A D a r a S e c u r i t y , In c . Une ébauche de standard bancaire ANSI s’appuie sur RSA.
Brevets L’algorithme R SA est breveté aux États-Unis [1341]. Il n’est breveté dans aucun autre pays. P K P offre des licences d ’exploitation de ce brevet ainsi que pour d’autres bre vets de cryptographie à clef publique (voir § 25.5). Le brevet américain expire le 20 septembre 2 0 0 0 .
19.4
Pohlig—Hellman
Le schéma de chiffrement P o h l i g - H e l l m a n [1263] est similaire au R SA . Ce n’est pas un algorithme à clef secrète puisque des clefs différentes sont utilisées pour le chiffrement et le déchiffrement. Ce n’est pas un schéma à clef publique car les clefs se déduisent facilement l’une de l’autre, les clefs de chiffrement et de déchiffrement doivent être toutes deux gardées secrètes. Comme pour le R SA , C = A4e mod n M . = C d mod n,
tel que : ed = 1
(mod « un nombre compliqué »).
Contrairement au R SA , n n’est pas défini en fonction de deux grands nombres pre miers ; il doit faire partie de la clef secrète. Si quelqu’un avait e et n, il pourrait calculer i. Sans la connaissance de e ou d, un adversaire serait obligé de calculer e = (logM C) mod n.
Vous avons déjà vu que c’était un problème difficile.
Brevets ^'algorithme P o h l i g H e l l m a n est breveté aux États-Unis [724] et au Canada. P K P ictroie des licences d’exploitation de ce brevet, ainsi que d ’autres brevets de crypto graphie à clef publique (voir § 25.5).
Chapitre 19
500
19.5
Algorithmes à clef publique
Rabin
La sécurité du schéma de R a b in [1294, 1603] dépend de la difficulté de calculer des racines carrées modulo un nombre composite. Ce problème est équivalent à la factori
sation. Tout d’abord, choisissez deux nombres premiers, p et q, tout deux congrus à 3 modulo 4. Ces nombres premiers forment la clef privée ; n = pq est la clef publique. Pour chiffrer un message, A4 (A4 doit être inférieur à n), calculez simplement C --- A42 mod n.
Déchiffrer un message est aussi facile, mais un peu plus embêtant. Comme les desti nataires connaissent p et q. ils peuvent résoudre les deux congruences en utilisant le théorème du reste chinois. Calculez : Toi = c ( p + D / 4 m o d
p
m 2 — (p ~ C ^ +l)>A) mod p m 3 = c (9 + D /4 m o d g
7714 — (ç — C(9+1)/4) mod q.
Prenez alors des entiers a et b tels que a = q i q 1 mod p) et b = quatres solutions possibles sont les suivantes : A4i M .2 A43 A44
= ( ami + bm3) mod — {ami + bm±) mod = (am 2 + bm3) mod = (am2 + brri/f) mod
p(p~*
mod q).Les
n n
n n.
L’un de ces 4 résultats, A4i, A42, A43 ou A44, est égal à A4. Si le message estdu texte en anglais, il serait facile de choisir le bon A4*. D ’autre part, si le message est une chaîne aléatoire de bits (pour la génération de clefs, par exemple) ou une signature numérique, il n’y a aucun moyen de savoir quel A4* est correct. Un moyen de résoudre ce problème est d ’ajouter une entête connue au début du message.
Williams W illia m s a redéfini les schémas de R a b in pour éliminer leurs limitations [1603]. Dans
son schéma, p et q sont sélectionnés tels que : p= 3
(m od 8)
q= 7
(mod 8)
et
N = pq.
Il y a également un petit entier S , tel que J(S,N) = —1 dans lequel « J » dénote le symbole de Jacobi (voir § 11.3). Les valeurs N et S sont publiques. La clef secrète est k telle que : k = \ x (^ x (p - i ) x (q - i ) + i)-
19.6
501
E lG a m a l
Pour chiffrer un message A l, calculez cj tel que J (A l,N ) — (—l ) Cl. Ensuite, calculez M ' = ( S Cl x A l) mod N . Comme pour le schéma de R a b i n , C = A l '2 mod N . Et C2 = A 1' mod 2. Le message chiffré final est le triplet : (C,C!,C2).
Pour déchiffrer C, le destinataire calcule A i ” en utilisant : Ck = ± A t "
(mod N).
Le signe correct étant donné par c2. Finalement, A l = (S ~Cl x ( - 1 ) C1 x A i ” ) mod N. il l ia m s a modifié ce schéma dans [1605, 1606, 1607]. Au lieu de mettre le message au carré, mettez-le au cube. Les grands nombres premiers doivent être congrus à 1 modulo 3 ; sinon la clef publique et la clef privée sont les mêmes. Mieux encore, il n’y a qu’un déchiffrement possible pour chaque chiffrement. Par rapport au R SA , R a b i n et W il l ia m s ont tous deux l’avantage d ’avoir été prouvés aussi sûrs que la factorisation. Toutefois, ils ne sont absolument pas sûrs dans le cas d’une attaque à texte chiffré choisi. Si vous avez l’intention d’utiliser ces schémas dans des situations où un attaquant peut monter une telle attaque (par exemple, dans un algorithme de signature numérique où l’attaquant peut choisir les messages qu’il fait signer), assurez-vous d ’utiliser une fonction de hachage à sens unique avant de signer. Malheureusement, une fois que vous ajoutez une fonction de hachage à sens unique au système, il n’est plus aussi sûr que la factorisation [630], bien que d’un point de vue pratique, l’ajout de la fonction de hachage ne peut pas affaiblir le système. D’autres variantes de R a b i n se trouvent dans [983, 910, 696, 698, 1441, 999]. Une variante à deux dimensions est décrite dans [867, 889].
W
19.6
ElGamal
Les schémas E l G a m a l [520, 521] peuvent être utilisés à la fois pour les signatures numériques et pour le chiffrement. Il tire sa sécurité de la difficulté de calculer des logarithmes discrets. Pour engendrer une paire de clefs, choisissez d ’abord un nombre premier p et deux nombres aléatoires g et x, tels que g et x soient tous deux inférieurs à p. Ensuite calculez : y — gx mod p. La clef publique est faite de y, g et p. Les valeurs de g et p peuvent être toutes deux partagées par un groupe d ’utilisateurs. La clef privée est x.
Signatures ElGamal Pour signer un message A4, choisissez d ’abord un nombre aléatoire k, tel que k et p — 1 soient premiers entre eux. Ensuite calculez : a = gk mod p
Chapitre 19
502
Algorithmes à clef publique
et utilisez l’algorithme d ’Euclide étendu pour trouver la valeur de b qui satisfait l’équa tion suivante : AA = (xa -f kb) mod (p — 1). La signature est la paire : a et b. La valeur aléatoire k doit être tenue secrète. Pour vérifier une signature, il faut confirmer que : yaab mod p = gM mod p.
Cela est résumé par le tableau 19.5. Tab.
19.5 - Signatures E l G a m a l
C l e f p u b liq u e :
p premier (peut être partagé par un groupe d ’utilisateurs) g < p (peut être partagé par un groupe d’utilisateurs) y — gx mod p c l e f p r iv é e :
x < p S ig n a tu r e :
k choisi aléatoirement et premier avec p — 1 a (signature) = gk mod p b (signature) tel que AA = (xa + kb) mod (p - 1) V é r if ic a t i o n :
La signature est valide si y aab mod p = gM mod p. Il faut prendre une nouvelle valeur de k à chaque chiffrement et à chaque signature, et cette valeur doit être choisie aléatoirement. Si jamais Estelle récupère une valeur de k que Alice a utilisé, elle peut retrouver la clef privée x d ’Alice. Si jamais Estelle récupère deux messages signés ou chiffrés avec la même valeur de k, elle peut retrouver x.
Par exemple, choisissez p = 11 et g = 2. Choisissez la clef privée x = 8. Calculez : y — gx mod p = 28 mod 11 = 3.
La clef publique est faite de y = 3, p = 2 et p = 1 1. Pour authentifier A4 — 5, choisissez d’abord un nombre aléatoire k = 9. Confirmez que pgcd(9,10) = 1. Calculez : a = gk mod p = 29 mod 11 = 6
et utilisez l’algorithme d ’Euclide étendu pour résoudre : JA = (ax + kb) mod (p — 1)
5 = ( 8 x 6 + 9 x 6 ) mod 10. La solution est b = 3 et la signature est la paire a — 6 et b — 3. Pour vérifier la signature, confirmez que : y aab mod p = gM mod p
3663 mod 11 = 25 mod 11.
19.6
503
E lG a m al
Une variante de E l G a m a t , pour les signatures est décrite dans [1382]. Thomas B e t h a inventé une variante du schéma E l G a m a l adaptée aux preuves d ’identité [153]. Il existe des variantes pour la validation de mots de passe [317], et pour l’échange de clefs [773]. Et il en existe bien d ’autres (voir § 20.4).
Chiffrement ElGamal Une modification du schéma E l G a m a l permet le chiffrement. Pour chiffrer un message A4, choisissez d ’abord un nombre aléatoire k tel que k et p — 1 soient premiers entre eux. Ensuite calculez : a = gk mod p b = y kM. mod p.
La paire a et b forme le texte chiffré. Remarquez que la taille du texte chiffré est le double de celle du texte en clair. Pour déchiffrer a et 6, calculez : A4 = b /a x mod p. Puisque ax = gkx (mod p) et que b/ax = ykM / a x = gxkM / g xk = A4 (mod p), tout est en ordre(voir le tableau 19.6). C ’est vraiment la même chose que dans l’échange de clefs deD if f ie - H e l l m a n (voir § 22.1), ceci près que y fait partie de la clef, et que le chiffrement est multiplié par y k.
Tab.
19.6 - Chiffrement E l G a m a l
C l e f p u b liq u e :
p premier (peut être partagé par un groupe d’utilisateurs) g < p (peut être partagé par un groupe d’utilisateurs) y — gx mod p C l e f p r iv é e :
x < p C h iff r e m e n t :
k choisi aléatoirement et premier avec p — 1 a (texte chiffré) = gk mod p b (texte chiffré) = y kA4 mod p D é c h iff r e m e n t :
A4 (texte en clair) = b/ax mod p
Vitesse Le tableau 19.7 donne des exemples de vitesses de réalisations logicielles de E l G am al [929].
Chapitre 19
504
Algorithmes à clef publique
T a b . 19.7 - Vitesses de E l G a m a l pour différentes longueurs de module avec des ex posants de 160 bits (sur une station SP A R C II)
Chiffrement, Déchiffrement Signature Vérification
512 bits 0,33 s 0,24 s 0,25 s 1,37 s
768 bits 0,80 s 0,58 s 0,47 s 5,12 s
1024 bits 1,09 s 0,77 s 0,63 s 9,30 s
Brevets E l G a m a l n’est pas breveté. Mais, avant de démarrer une réalisation de cet algorithme, tenez compte du fait que P K P considère que cet algorithme est couvert par le brevet du système DlFFiE-HELLMAN [720]. Cependant, ce brevet expire le 29 avril 1997, ce qui fera de E l G a m a l le premier algorithme cryptographique à clef publique adapté au chiffrement et aux signatures numériques qui ne soit pas couvert par un brevet aux Etats-Unis. Je suis impatient de voir cela.
19.7
McEliece
En 1978, Robert M c E l ie c e a développé un cryptosystème à clef publique basé sur la théorie des codes algébriques [1049]. L’algorithme fait usage de l’existence d’une classe de codes correcteurs d’erreurs, connus sous le nom de codes de G o p p a . Son idée est de construire un code de G o p p a et de le déguiser en code linéaire général. Il existe un algorithme rapide pour décoder un code de G o p p a , mais décoder des codes linéaires généraux est un problème N P - c o m p l e t . Une bonne description de cet algorithme peut être trouvée dans [1243] ; consultez aussi [1533]. Ce qui suit est un bref résumé. Soit dff(x,y) la distance de H a m m i n g entre x et y. Les nombres n, k et t sont des paramètres du système. La clef privée a trois parties : G' une matrice génératrice k x n pour un code de G o p p a qui peut corriger t erreurs, P une matrice de permutation n x n, S une matrice non singulière k x k. La clef publique est une matrice G, k x n telle que: G = SG ’P. Les messages en clair sont des chaînes de k bits sous la forme de vecteurs àk éléments de Z /2 . Pour chiffrer un message, choisissez un vecteur aléatoire à n éléments deZ j 2, z avec une distance de H a m m i n g inférieure ou égale à t. c = mG + z Pour déchiffrer le texte chiffré, calculez d ’abord c'
= cP 1. Ensuite, en utilisant l’algo
rithme de décodage des codes de G o p p a , trouvez m 't e l que d //( m , G ,c, ) soit inférieure ou égale à t. Finalem ent, calculez m = m 'S _1.
Dans son article originel, M c E l ie c e suggère d ’utiliser n = 1024, t = 50 et k = 524. C ’est le minimum requis pour la sécurité. Bien que cet algorithme fût l’un des premiers algorithmes à clef publique et qu’il n’y ait pas de résultats cryptanalytiques contre cet algorithme, il n’obtint jamais une large
19.8
Cryptosystèmes à courtes elliptiques
505
diffusion dans la communauté cryptographique. Ce schéma est de deux à trois ordres de grandeurs plus rapide que le R S A mais il pose différents problèmes. La clef publique est énorme : 219 bits de long. L’expansion des données est importante : le texte chiffré est deux fois plus long que le texte en clair. Certaines tentatives de cryptanalyse de ce système sont décrites dans [12, 954, 1530, 311]. Aucune d ’entre elles ne fut victorieuse, bien que la similarité entre l’algorithme de M c E l ie c e et les empilements ait inquiété certains. En 1991, deux cryptographes de l’ex-Union soviétique, K o r z h ik et T u r k in ont pré tendu avoir cassé le système avec certains paramètres [882]. Leur article ne contient au cune preuve et beaucoup de cryptographes doutent de leur résultat. Une autre attaque russe, qui ne peut pas s’utiliser directement contre le système M c E l ie c e , est décrite dans [1453, 1454], Des extensions de M c E l ie c e sont présentés dans [426, 1237, 986].
Autres algorithmes basés sur les codes correcteurs d’erreurs li néaires L’algorithme de NlEDERREiTER [1166] est étroitement lié à l’algorithme de M c E l i e c e , et fait l’hypothèse que la clef publique est une matrice aléatoire de vérification de parité d’un code correcteur. La clef privée est un algorithme efficace de décodage pour cette matrice. Un autre algorithme, servant à l’identification et aux signatures numériques, est basé sur le syndrome du décodage [1504] ; consultez [311] pour les commentaires. Un dernier algorithme basé sur les codes correcteurs d ’erreurs [1623] n’est pas sûr [699, 51, 52,1531, 53].
19.8
Cryptosystèmes à courbes elliptiques
Les courbes elliptiques ont été étudiées pendant de nombreuses années et il existe un volume important de publications à ce sujet. En 1985, Neal K o b l i t z et V.S. M il l e r ont proposé indépendamment de les utiliser pour des cryptosystèmes à clef publique [868, 1101]. Ils n ’ont pas inventé un algorithme cryptographique qui utilise les courbes elliptiques mais ils ont réalisé des algorithmes à clef publique existants, tel que D if f ie H e l l m a n , à l’aide de courbes elliptiques. Les courbes elliptiques sont intéressantes parce qu’elles fournissent un moyen de cons truire des « éléments » et des « règles de combinaison » qui produisent des groupes. Ces groupes ont suffisamment de propriétés familières pour construire des algorithmes cryptographiques mais ils n’ont pas certaines propriétés qui faciliteraient la cryptana lyse. Par exemple, il n’y a pas de bonne notion de continuité. C ’est-à-dire qu’il n’y a pas d ’ensemble de petits éléments en fonction desquels un élément quelconque au rait une bonne chance de pouvoir être exprimé par un algorithme simple. D ’où le fait que les algorithmes de calcul indiciel de logarithmes discrets (« index calculus discrète logarithm algorithms ») ne marchent pas. Voyez [1101] pour plus de détails. Les courbes elliptiques sur les corps finis Z j2 n sont particulièrement intéressantes. Les processeurs arithmétiques pour les corps sous-jacents sont faciles à construire et relativement simples à réaliser pour des valeurs de n dans l’intervalle de 130 à 200. Ces systèmes ont le potentiel de fournir des cryptosystèmes à clef publique plus rapides
Chapitre 19
506
Algorithmes à clef publique
avec des clefs plus petites. D e nombreux algorithmes à clef publique, tels que DlFFiEH e l l m a n , E l G a m a l et S c h n o r r , peuvent être réalisés à l’aide de courbes elliptiques sur des corps finis.
Les mathématiques de ces systèmes sont complexes et dépassent le cadre de ce livre. Ceux qui sont intéressés par le sujet sont invités à lire les deux références men tionnées ci-dessus et l’excellent livre de Alfred M e n e z e s [1068]. Deux analogues de R SA fonctionnent avec les courbes elliptiques [890, 457]. D ’autres articles sont [27, 129, 1069, 871, 159, 872, 892, 30, 895, 357, 1070, 29, 915, 916, 913]. Les cryptosys tèmes à courbes elliptiques à clefs de petite taille sont examinés dans [702]. Le « Fa s t E l l ip t ic E n c r y p t i o n » (F E E ) de N e x t C o m p u t e r , I n c . utilise des courbes ellip tiques [392]. Le FEE présente l’avantage de pouvoir utiliser n’importe quelle chaîne de caractères facile à retenir comme clef privée. Il y a aussi des cryptosystèmes à clef publique qui utilisent des courbes hyperelliptiques [870, 869, 1447, 1222].
19.9
LUC
Quelques cryptographes ont développé des généralisations de R SA qui utilisent diffé rents polynômes à la place de l’exponentiation. Une variante appelée K r a v i t z - R e e d , utilisant des polynômes binaires irréductibles [897], n’est pas sûre [454, 591]. Winfried M ü l l e r and Wilfried N ô b a u e r utilisent les polynômes de D i c k s o n [1133, 1134, 976]. Rudolf L i d l et N ô b a u e r ont inspecté sa sécurité [1178, 1179]. (La génération de nombres premiers avec les fonction de L u c a s est commentée dans [980, 978, 979, 600].) Malgré tous ces travaux antérieurs, un groupe de chercheurs de la Nouvelle-Zélande ont tenté en 1993 de breveter ce schéma, lui donnant le nom de LUC [1493, 523, 1494]. Le ne nombre de L u c a s Vn(AA,\) est, défini par: Vn( M , 1 )
=
-
Un _ 2 (A 4 ,l)
Tout le reste de la théorie de nombres de L u c a s est ignorée ici. Une bonne approche mathématique des suites de L u c a s se trouve dans [1318, 1319]. Une description parti culièrement soignée des mathématiques de LU C est donnée dans [1501, 709]. Dans tous les cas, pour générer une paire clef publique/clef privée, commencez par choisir deux grands nombres premiers p et q. Calculez n = pq. La clef de chiffrement e est un nombre aléatoire premier avec p — 1, q — 1 , p + 1 et q + 1. Il y a quatre clefs de déchiffrement possibles (ppcm désigne le plus petit commun multiple) : d= d= d= d=
e~ l mod (ppcm(p -f 1,q + 1)) e ~ 1 mod (ppcm(p + 1,q — 1)) e ~ x mod (ppcm(p — 1,ç + 1)) e-1 mod (ppcm(p — 1,q — 1))
La clef publique est formée de d et n, la clef privée de e et n. Jetez p et q. Pour chiffrer un message AA (AA doit être inférieur à n), calculez : C = Ve(JA,\)
(mod n)
19.10
507
Automates finis
et pour déchiffrer : M = V d(M ,l)
(mod n)
Au mieux, LU C est aussi sûr que R SA . Et un résultat récent, non encore publié, montre comment casser LU C au moins dans certaines réalisations. Je ne lui fait pas confiance.
19.10
Automates finis
Le cryptographe Tao R e n j i a développé un algorithme à clef publique basé sur les automates finis [1312, 1313, 1314, 1315, 667]. De même qu’il est difficile de factoriser le produit de deux grands nombres premiers, il est difficile de factoriser la composition de deux automates finis, spécialement quand l’un d’eux (ou les deux) n’est pas linéaire. La majorité de ces recherches a été menée en Chine dans les années 1980 et publiée en chinois. R e n j i commence à l’écrire en anglais. Son résultat principal dit que certains automates non linéaires (les automates quasi-linéaires) possèdent des inverses faibles si et seulement s’ils ont une certaine structure de matrice à échelons. Cette propriété disparaît s’ils sont composés avec un autre automate, même linéaire. Dans l’algorithme à clef publique, la clef privée est composée d’un automate quasi-linéaire inversible et d’im automate linéaire, et la clef publique correspondante est obtenue en les multipliant terme à terme. Les données sont chiffrées en les passant à travers l’automate publique, et déchiffrées en les passant à travers les inverses de ses composantes (dans certains cas, à condition qu’ils aient été positionnés des états initiaux appropriés). Ce schéma fonctionne à la fois pour le chiffrement et pour les signatures numériques. La performance de ces systèmes se résume ainsi : comme le système M c E l i e c e , ils sont beaucoup plus rapides que le R S A , mais nécessitent des clefs plus longues. La longueur de clef donnant une sécurité similaire au R SA à 512 bits est de 2792 bits, et de 4152 bits pour le R S A à 1024 bits. Dans le premier cas, ce système chiffre 20 869 octets de données par seconde et déchiffre 17117 octets de données par seconde sur un 80486 à 33 MHz. R en ji a publié trois algorithmes. Le premier, FAPK C 0, est un système affaibli qui utilise des composantes linéaires, et est avant tout illustratif. Deux systèmes sérieux, FAPKC1 et FA P K C 2 utilisent une composante linéaire et une composante non li néaire chacun. Le deuxième est plus compliqué et a été développé de manière à per mettre les opérations à base d ’identification. Quand à leur solidité, une somme de travail assez importante leur a été dédiée en Chine (où il y a maintenant plus de 30 instituts publiant des articles de cryptographie). On peut apprécier d’après l’imposante littérature en chinois que le problème a été étudié. Un charme éventuel de FA PK C 1 et F A PK C 2 est qu’ils ne sont encombrés d’aucun brevet américain. Aussi, quand le brevet de D if f ie - H e l l m a n expirera en 1997, ils feront sans doute partie du domaine publique.
Chapitre 20
Algorithmes de signature numérique à clef publique 20.1
Algorithme de signature numérique DSA
En août 1991, l’Institut national des standards et de la technologie américain NIST (« National Institute of Standards and Technology ») proposa l’algorithme de signa ture numérique D SA (« Digital Signature Algorithm ») pour le nouveau standard de signature numérique DSS (« Digital Signature Standard »). D ’après le « Fédéral Register » [541] : « Un standard fédéral de traitement de l’information FIPS (« Fédéral Information Processing Standard ») est proposé pour le standard de signa ture numérique DSS. Cette proposition de standard spécifie un algorithme de signature numérique à clef publique (D S A ) approprié pour les appli cations de signature numérique fédérales. Le DSS proposé utilise une clef publique pour permettre à un destinataire de vérifier l’intégrité des données et de vérifier l’identité de l’expéditeur des données. Le DSS peut aussi être utilisé par une tierce personne pour établir l’authenticité d’une signature et des données qui y sont associées. « Cette proposition de standard adopte un schéma de signature à clef publique qui utilise une paire de transformations pour engendrer et vérifier la valeur numérique appelée signature. » Et: « La proposition de FIPS est le résultat de l’évaluation d ’un certain nombre d’alternatives de techniques de signature numérique. En faisant son choix, le N IST s’est conformé au mandat contenu dans la section 2 du « Computer Security Act » de 1987 indiquant que le N IST développe des standards pour « . . . garantir de manière rentable la sécurité et la confi dentialité des informations fédérales et, parmi les technologies offrant un
510
Chapitre 20
Algorithmes de signature numérique à clef publique
niveau de protection comparable, choisir l’option avec les meilleures carac téristiques opérationnelles et pratiques. » Parmi les facteurs considérés durant ce processus, il y avait le niveau de sécurité offert, la facilité de réalisation à la fois matérielle et logicielle, la facilité d’exportation hors des Etats-Unis, les brevets applicables, l’impact sur la sécurité nationale et la préservation de la loi, et le niveau d’efficacité à la fois pour les fonctions de signature et de vérification. Un certain nombre de techniques furent considérées comme fournissant la protection appropriée pour les systèmes fédéraux. La technique sélection née présente les avantages suivants : - Le N IST escompte qu’elle sera disponible gratuitement. Un plus large usage de cette technique résultant de sa disponibilité dans le domaine public devrait être bénéfique au gouvernement et au public. - La technique sélectionnée permet des réalisations efficaces des opéra tions de signature dans des applications de cartes à puce. Dans ces applications, les opérations de signature sont effectuées avec les mo destes ressources en calcul de la carte à puce, tandis que le processus de vérification est réalisé dans un environnement plus riche en ressources de calculs tels qu’un ordinateur personnel, un module cryptographique matériel, ou un ordinateur central. » Avant que cela ne devienne trop confus, laissez-moi revoir la nomenclature : D SA est l’algorithme, DSS est le standard. Le standard utilise l’algorithme. L’algorithme fait partie du standard.
Réactions à l’annonce L’annonce du N IST a déclenché un maelstrôm de critiques et d’accusations. Mal heureusement, toutes plus politiques qu’académiques. R S A D a t a S e c u r i t y , In c ., pourvoyeur de l’algorithme R SA , conduisit les critiques contre le DSS, exigeant que le R S A soit utilisé dans le standard comme algorithme, et pas un autre. R SA D SI gagne beaucoup d ’argent en vendant des licences d’exploitation de l’algorithme R SA , et un standard de signature numérique exempt de droits affecterait directement ses revenus de base1. Avant que l’algorithme ne soit annoncé, R SA D SI fit campagne contre un « module commun », qui aurait donné la possibilité au gouvernement de falsifier des signatures. Quand l’algorithme fut annoncé sans ce « module commun », R SA D S I l’attaqua sur d’autres bases [161], à la fois dans des lettres adressées au N IST et dans la presse2. De nombreuses grandes sociétés de logiciel qui avaient déjà acquis une licence pour l’algorithme R S A s’opposèrent au DSS. En 1982, le gouvernement américain sollicita des algorithmes à clef publique pour un standard [539]. Après cela, il n ’y eut plus le moindre signe de vie du N IST durant neuf ans. Des sociétés telles qu’IBM , A p p l e , N o v e l l , L o t u s , N o r t h e r n T e l e c o m , M i c r o s o f t , D EC et S u n avaient déjà investi 1. Notez que le D S A pourrait enfreindre certains brevets; j ’y reviendrai 2. Q uatre lettres adressées au N IS T furent publiées dans [1337]. Q uand vous les lisez, gardez à l’esprit qu ’au moins deux des auteurs, R . RlVEST et M. HELLMAN, ont un intérêt financier à ce que le D SS ne soit pas accepté.
20.1
Algorithme de signature numérique D S A
511
des montants importants dans la réalisation de l’algorithme RSA . Ils ne voulaient pas perdre cet investissement. En tout, le N IST avait reçu 109 commentaires à la fin de la première période d’éva luation, le 28 février 1992. Parcourons une à une les critiques contre le D SA : 1. Le D S A ne peut pas être utilisé pour le chiffrement ou la distribution de clefs. C ’est vrai, mais ce n’est pas son objet. C ’est un standard de signature. Il devrait y avoir un standard N IST de chiffrement à clef publique. Le N IST cause un grave préjudice au peuple américain en ne mettant pas sur pieds un standard de chiffrement à clef publique. Il est suspect que le N IST ait proposé un standard de signature numérique qui ne puisse pas être utilisé pour le chiffrement3. Cela ne veut pas dire qu’un standard pour la signature numérique est inutile. 2. Le D SA a été développé par la N SA, et il peut y avoir une brèche secrète dans l’algorithme. La plupart des premiers commentaires relevaient de la paranoïa: « Le refus du N IST de fournir l’information sans justification apparente n’inspire pas confiance dans le DSS, mais renforce l’inquiétude quant à l’existence d’un dessein caché telle la mise en place d’un cryptosystème à clef publique national qui puisse être cassé par le N IST et/ou la NSA. » [161]. Il y eut une objection sérieuse concernant la sécurité du DSS soulevée par Arjen L e n s t r a et Stuart H a b e r des laboratoires « B e l l c o r e ». Elle sera présentée plus avant dans le texte. 3. Le D SA est plus lent que le R S A [809]. C ’est vrai, plus ou moins. Les vitesses de génération de signature sont les mêmes mais la vérification de signature peut être 10 à 40 fois plus lente avec le D SA. La génération de clefs est plus rapide que celle du R SA . La génération de clef est hors de propos ; un utilisateur fait cela rarement. D ’autre part, la vérification de signature est ]’opération la plus usitée. Le défaut de cette critique est qu’il y a plusieurs moyens de jouer avec les pa ramètres de test en fonction du résultat que l’on veut obtenir. Les précalculs peuvent accélérer la génération de signatures du D SA mais ils ne sont pas tou jours réalisables. Les défenseurs du R S A utilisent des nombres optimisés pour rendre leurs calculs plus faciles; les défenseurs du D S A utilisent leurs propres optimisations. Dans tous les cas, les ordinateurs vont toujours de plus en plus vite. Bien qu’il y ait une différence, dans la plupart des applications ce n’est pas notable. 4. Le R SA est un standard de facto. Il y a deux exemples d’une telle plainte. L’une émane de Robert recteur du programme des standards d’IBM [572] :
FOLLETT,
« IBM s’inquiète du fait que le N IST ait proposé un standard avec un schéma de signature numérique différent plutôt que d’adopter un stan dard international. Nous avons été convaincus par les utilisateurs et les 3. E t pourtant, il peu t quand m êm e l’être — voir § 23.3.
di
512
Chapitre 20
Algorithmes de signature numérique à clef publique
organisations d’utilisateurs que des standards internationaux utilisant le R S A seraient un prérequis pour la vente de produits de sécurité dans un avenir très proche. » L ’autre est de Les S h r o y e r , vice-président et directeur des services informatiques et des télécommunications chez MOTOROLA [1450] : « Nous devons avoir un standard de signature unique, robuste et politi quement accepté qui soit utilisable à travers le monde, entre américains et n on- Américains, et entre MOTOROLA et des entités non-M oTOROLA. L’absence d’une autre technologie de signature numérique viable du rant ces huit dernières années a fait de R S A un standard de facto ... M o t o r o l a et de nombreuses autres sociétés ... ont dépensé des mil lions de dollars pour le R SA . Nous sommes inquiets de l’interfonctionnement et du soutien de deux standards différents car cette situation va occasionner des surcoûts, des retards de diffusion et des complications ... » De nombreuses sociétés voulaient que le N IST adopte IS O /IE C 9796, le stan dard international de signature numérique qui utilise le R S A [767]. Bien que ce soit une objection valable, ce n’est pas une justification suffisante pour en faire un standard. Un standard exempt de droits servirait au plus haut point les intérêts du public américain. 5. Le processus de sélection du D SA n’était pas public; il n’a pas bénéficié d’un temps suffisant pour l’analyse. Tout d’abord, le N IST prétendit avoir conçu le D SA ; ensuite ils admirent que la N SA les avait aidés. Finalement, ils confirmèrent que la N SA avait conçu l’algo rithme. Cela inquiétait nombre de gens auxquels la NSA n ’inspire pas confiance. Même ainsi, l’algorithme est public et disponible pour analyse; et le N IST a prolongé la période d’analyse et de commentaires. 6. Le D S A peut enfreindre d ’autres brevets. C ’est possible. Ce sera discuté plus en détail dans la section sur les brevets. 7. La taille de clef est trop petite. C ’était la seule critique valable contre le DSS. La réalisation originale prévoyait un module de 512 bits [1176]. Comme la sécurité de l’algorithme dépend de la difficulté de calculer des logarithmes discrets modulo le module, c ’était inquiétant pour la plupart des cryptographes. Il y a eu des avancées dans le domaine du calcul des logarithmes discrets sur un corps fini et un module de 512 bits est trop court pour une sécurité à long terme (voir § 7.2). D ’après Brian LaMacchia et Andrew O d l y z k o , « ... même des nombres premiers de 512 bits semblent n’offrir qu’une sécurité marginale ... » [945]. Ce n’est pas tout à fait correct — 512 bits offrent une sécurité suffisante aujourd’hui. Mais si votre sécurité doit s’étendre dans la futur, ce n’est pas sûr. En réponse à cette critique, le NIST a rendu variable la taille de clef de 512 à 1024 bits. Nous y reviendrons plus en détail.
20.1
Algorithme de signature numérique D S A
513
Le standard a finalement vu le jour le 19 mai 1994 [1174], Le décret d ’adoption précisait [540] : « Ce standard s’applique à tous les départements et instituts fédéraux pour la protection d’informations non classées... Ce standard doit être inclus dans la conception et la réalisation de schémas de signature à clef publique utilisés par les département et instituts fédéraux ou par d’autres organismes sous contrat avec eux. L’adoption et l’utilisation de ce standard est ouverte aux organismes privés ou commerciaux. » Avant d’inclure ce standard dans votre prochain produit, lisez un peu plus loin la partie concernant les problèmes de brevet.
Description de l’algorithme Le DSA est une variante des algorithmes de signature S c h n o r r et E l G a m a l qui est entièrement décrite dans [1174]. L’algorithme utilise les paramètres suivants: •p — un nombre premier de L bits de long, où L est compris entre 512 et
1024 et est un multiple de 64.4 q = un facteur premier de p — 1, long de 160 bits.
g = /j(p-i)/<7 mod p, où h est n’importe quel nombre inférieur à p — 1 tel que h^p~ l^'q mod p soit plus grand que 1. x = un nombre inférieur à q. y = gx mod p.
De plus, l’algorithme utilise une fonction de hachage à sens unique: H (x). Pour le DSS, c ’est l’algorithme de hachage sûr (« Secure Hash Algorithm ») décrit par le paragraphe 18.7. Les trois premiers paramètres p, q et g sont publics et peuvent êtrecommuns à un réseau d’utilisateurs. La clef privée est x et la clef publique est y. Pour signer un message M. : 1° Alice engendre un nombre aléatoire k inférieur à q. 2° Alice engendre r = ( gk mod p) mod q s = ( k~ 1 ( H ( M ) + xr)) mod q.
Les paramètres r et s forment sa signature ; elle les envoie à Bernard. 3° Bernard vérifie la signature en calculant:
w = s-1 mod q u\ = (H (M ) x w ) mod q u2 = rw mod q v = ((g,“ 1 x yU2) mod p) mod q. 4. Dans le standard original, la longueur de p était fixée à 512 bits [1176]. C e fut la source de nombreuses critiques et le N IS T du changer [1174],
Chapitre 20
514
Algorithmes de signature numérique à clef publique
Si v = r, alors la signature est vérifiée.
Les preuves des relations mathématiques sont fournies dans [1174]. Voyez le ta bleau 20.1 pour un résumé.
T a b .
20.1
-
Signatures DSA
C lef publique : p nombre premier de 512 à 1024 bits q facteur premier de p — 1 de 160 bits g= mod p, où h est inférieur à p — 1 et (hSp O/ç mod p) > 1 (p, q et g peuvent chacun être partagés par un groupe d ’utilisateurs) y = gx mod p C lef privée : x < q (un nombre de 160 bits) Signature : k choisi aléatoirement et inférieur à q r (signature) = ( gk mod p) mod q s (signature) = (fc- 1 (i/(m ) + xr)) mod q Vérification : w = s ~ l mod q Ui = ( H (m ) x w) mod q u2 = rw mod q v = (( gUl x y U2) mod p) mod q Si v = r, alors la signature est vérifiée.
Vitesse et précalculs Le tableau 20.2 donne quelques vitesses de logiciels réalisant le DSA. 20.2 - Vitesses du D S A pour différentes longueurs de module avec un exposant de 160 bits (sur une station S P A R C II )
T a b .
Signature Vérification
512 bits 0,20 s 0,35 s
768 bits 0,43 s 0,80 s
1024 bits 0,57 s 1,27 s
Les réalisations concrètes du D SA peuvent être accélérées grâce aux précalculs. Notez que la valeur de r ne dépend pas du message. Vous pouvez créer une chaîne de valeurs aléatoires k et précalculer la valeur r pour chacune d’entre elles. Vous pouvez aussi précalculer A;'1 pour chacune de ces valeurs k. Ensuite, quand un message arrive, vous pouvez calculer s pour des r et fc-1 donnés. Ce précalcul accélère considérablement le D SA. Le tableau 20.3 donne une comparaison des temps de calcul pour le D S A et le R S A pour une réalisation en carte à puce [I486].
Génération des nombres premiers pour le DSA L enstra
et
H aber
remarquèrent que certains modules sont nettement plus faciles
20.1
515
Algorithme de signature numérique D S A
T ab. 20.3 - Comparaison des temps de calcul pour le R SA et le D SA
Calculs généraux Génération de clef Précalcul Signature Vérification
D SA
RSA
hors-carte (P) 14 s 14 s 0,03 s 16 s 1-5 s hors-carte (P)
sans objet hors-carte (S) sans objet 15 s 1,5 s 1-3 s hors-carte (P)
D SA avec p, q et g communs hors-carte (P) 4s 4s 0,03 s 10 s
Les calculs hors-carte furent effectués sur un ordinateur personnel avec un processeur 80386 cadencé à 33 MHz. « (P) » indique les paramètres publics hors-carte et « (S) » indique les paramètres secrets hors-carte. Les deux algorithmes ont été testés avec un module de 512 bits.
à casser que les autres [961]. Si quelqu’un utilisait l’un de ses modules « faibles », ses signatures pourraient être facilement falsifiées. Ce n’est pas un problème pour deux raisons : primo, les modules pour lesquels cette propriété est vraie sont faciles à détecter. Secundo, ces modules sont si rares que les chances d’en utiliser lors du choix aléatoire d’un module sont négligeables — plus petites en fait que les chances d’engendrer un nombre composé par une méthode probabiliste de génération de nombres premiers. Dans [1174], le N IST recommande la méthode suivante de génération des deux nombres premiers p et q tels que q divise p 1. Le nombre premier p a une longueur de 512 à 1024 bits multiple de 64. Le nombre premier g a 160 bits de long. Soit L — 1 = 160n + b où L est la longueur de p, n et b sont deux nombres, et b est inférieur à 160. 1° Choisissez une chaîne arbitraire d’au moins 160 bits et appelez-la S. Soit g la longueur de S en bits.
2° Calculez U = S H A (S ) © S H A ((S + 1) mod 29), où S H A est l’algorithme de hachage sûr (voir § 18.7). 3° Formez q à partir de U en mettant le bit le plus significatif et le bit le moins significatif tous deux à 1. 4° Vérifiez si q est un nombre premier. 5 ° Si q n’est pas un nombre premier, retournez à l’étape
1.
6° Posez C = 0 et N = 2. 7° Pour k = 0,1,...,n, on a 14 = S H A ((S 4- N + k) mod 29). 8° Calculez W = V0 + Ri x 2160 + ... + Vn- i x 2(n“ 1)* 160 + (14 mod 2 b) x 2nxl6Q et X = W + 2 l ~ 1. Remarquez que X est un nombre de L bits.
516
Chapitre 20
Algorithmes de signature numérique à clef publique
9° Calculez p = X — ((X mod 2q) — 1). Remarquez que p est congru à 1 modulo 2q. 10° Si p < 2 L Ï, alors allez à l’étape 13. 11 ° Vérifiez si p est premier. 12° Si p est premier, allez à l’étape 15. 13 ° Posez C = C + 1 et N = N + n + 1. 14° Si C = 4 096, alors allez à l’étape 1 , sinon allez à l’étape 7. 15° Sauvegardez les valeurs de S et C utilisées pour engendrer p et q. Dans [1174], la variable S est appelée le « germe », C le « compteur », et N l’« offset ». La raison d’être de cet exercice est qu’il existe un moyen public d’engendrer p et q. Rappelez-vous les gens qui s’inquiétaient du fait que des valeurs « faibles » pour p et q permettraient de casser le DSA plus facilement. Pour toute utilisation pratique, cette méthode évite cela. Si quelqu’un vous donne p et q, vous pouvez vous demander d’où ils viennent. Par contre, si quelqu’un vous donne les S et les C qui ont permis d’engendrer les p et les q aléatoires, vous pouvez par vous-même refaire les calculs. L ’utilisation de S H A , une fonction de hachage à sens unique, évite que quelqu’un puisse remonter les calculs à partir de p et g pour générer S et C. La sécurité est meilleure que celle que vous auriez avec le R SA . Avec le R SA , les nombres premiers sont gardés secrets. Quelqu’un peut engendrer un nombre premier factice ou un nombre ayant une forme spéciale qui facilite la factorisation. À moins que vous ne connaissiez la clef privée, vous ne le sauriez pas. Ici, même si vous ne connaissez pas la clef privée, vous pouvez vérifier que p et q ont été engendrés aléatoirement.
Chiffrement ElGamal à l’aide du DSA Selon certaines allégations, le D SA plaisait au Gouvernement américain parce que ce n ’était qu’un algorithme de signature numérique qui ne pouvait pas servir pour le chiffrement. Bien que cela soit vrai, il est possible d’utiliser un appel à la fonction DSA p ou r réaliser un chiffrement E l G a m a l . Faites l’hypothèse que l’algorithme D SA est réalisé par une fonction qui peut être appelée par : D SA sign ( p , q , g , k , x , h , r , s ) .
Vous fournissez les nombres p, q, g, k, x et h et la fonction fournit comme résultat les paramètres r et s. P ou r réaliser le chiffrem ent E l G a m a l d ’un m essage m avec la c le f pu bliqu e y, choisissez un n om bre aléatoire k et appelez : D S A s ig n (p ,p ,g ,k ,0 ,0 ,r ,s ).
La valeur de r fournie est a dans le schéma E l G a m a l . Jetez s. Ensuite appelez : D S A s ig n (p ,p ,y ,k ,0 ,0 ,r , s ) .
Renommez la valeur r en u ; jetez s. Appelez : D S A s ig n (p ,p ,m ,l,u ,0 ,r ,s ).
20.1
Algorithme de signature numérique D S A
517
Jetez r. La valeur de s fournie est b du schéma E l G a m a l . V o u s avez maintenant le texte chiffré constitué de a et b. Le déchiffrement est tout aussi simple. Utilisez la clef secrète x et les messages chiffrés a et b. Appelez : D S A s ig n ( p ,p ,a ,x ,0 ,0 ,r ,s ) . La valeur de r est ax mod p. Appelez-la e. Ensuite appelez : D S A s i g n ( p ,p ,l ,e ,b ,0 ,r ,s ) . La valeur s est le texte en clair du message : m. Cette méthode ne marchera pas avec toutes les réalisations du D SA , dont certaines peuvent fixer les valeurs de p et ç, ou la longueur de certains autres paramètres. Toutefois, si la réalisation est suffisamment générale, il y a un moyen de chiffrer avec une fonction de signature numérique.
Chiffrement RSA à l’aide du DSA Le chiffrement R S A est encore plus facile à réaliser. Avec un module n, un message m et une clef publique e, appelez : D S A s ig n (n ,n ,m ,e ,0 ,0 ,r ,s ). La valeur r fournie est le texte chiffré. Le déchiffrement R S A est la même chose : D S A s ig n (n ,n ,m ,d ,0 ,0 ,r ,s ). La valeur de r est le texte en clair.
Sécurité du DSA Avec 512 bits, le D S A n’était pas assez solide pour la sécurité à long terme. Avec 1024 bits, il l’est. L’Agence nationale de sécurité américaine, dans une première interview à ce sujet, ré pondit à Joe A b e r n a t h y du Houston Chronicle aux allégations concernant l’existence d’une brèche secrète dans le DSS [367] : « En ce qui concerne la présumée brèche secrète dans le DSS, nous trouvons les termes « brèche secrète » quelque peu trompeurs puisqu’ils impliquent que des messages envoyés par le DSS sont chiffrés et que par une brèche secrète quelqu’un pourrait d’une certaine façon déchiffrer (lire) le message à l’insu de l’expéditeur. « Le DSS ne chiffre aucune donnée. Le vrai problème est de savoir si le DSS est susceptible d’être utilisé par quelqu’un pour falsifier une signature et ainsi discréditer tout ie système. Nous affirmons catégoriquement que les probabilités que quiconque — y compris la N SA — falsifie une signature avec le DSS quand il est correctement utilisé et réalisé sont infinitésimales. « De plus, la présumée vulnérabilité par brèche secrète est vraie pour n’importe quel système d’authentification à clef publique, y compris le
518
Chapitre 20
Algorithmes de signature numérique à clef publique
RSA . Faire croire d ’une certaine façon que cela n’affecterait que le DSS (un argument répandu dans la presse) est totalement trompeur. C ’est un problème qui dépend de la réalisation et de comment on sélectionne les nombres premiers. Nous attirons votre attention sur la récente conférence EUROCRYPT, pendant laquelle fut organisée une tribune sur le problème des brèches secrètes dans le DSS. L ’un des chercheurs de B e l l c o r e qui avait initialement allégué de l’existence d ’une brèche secrète faisait partie de la tribune et il nous a semblé que les participants à la tribune — y compris celui de B e l l c o r e — conclurent que la présumée brèche secrète n’était pas un problème pour le DSS. De plus, le consensus semblait général sur le fait que le problème de la brèche secrète était insignifiant et qu’il avait été exagéré par la presse. Toutefois, pour essayer de répondre à l’allégation concernant la brèche secrète, à la demande du N IST, nous avons conçu un processus de génération des nombres premiers qui garantira que l’on puisse éviter le choix des relativement rares nombres premiers faibles qui auraient entraîné une faiblesse dans l’utilisation du DSS. De plus, le N IST a l’intention de permettre des tailles de module allant jusqu’à 1024, ce qui en soi élimine la nécessité d ’utiliser le processus de génération de nombres premiers pour éviter les nombres premiers faibles. Un point supplémentaire très important qui passe souvent inaperçu est qu’avec le DSS les nombres premiers sont publics et donc sujets à l’examen public. Tous les systèmes à clef publique ne fournissent pas cette possibilité d’examen. « L’intégrité de tout système de sécurité de l’information dépend de l’attention apportée à une réalisation correcte. Avec la myriade de vulnéra bilités possibles compte tenu des différences entre les utilisateurs, la NSA a toujours insisté sur les centres de confiance centralisés comme moyen de minimiser les risques dans le système. Bien que nous ayons apporté des mo difications techniques au DSS pour satisfaire les requêtes du N IST pour une approche plus décentralisée, nous insistons quand même sur la partie de la note du « Fédéral Register » pour le DSS qui indique : « Bien que le but de ce standard soit de spécifier les exigences générales de sécurité pour engendrer des signatures numériques, la conformité à ce standard ne garantit pas la sécurité d ’une réa lisation particulière. Les autorités responsables de chaque agence ou département doivent veiller à ce que la réalisation globale offre un niveau de sécurité acceptable Le NIST collaborera avec les utilisateurs gouvernementaux pour veiller à la bonne qualité des réalisations. » Finalement, nous avons lu tous les arguments concernant les insécurités po tentielles avec le DSS et nous restons sceptiques sur leur validité. Le DSS a fait l’objet d’une évaluation en profondeur par la NSA, qui a conduit notre directeur des systèmes de sécurité de l’information à l’adopter pour signer des données non classées traitées par certains systèmes d ’espionnage, et même pour signer des données classées dans des systèmes choisis. Nous pensons que cette approbation parle en faveur de l’absence de toute attaque crédible contre l’intégrité offerte par le DSS, pour autant qu’il soit correc tement utilisé et réalisé. En fonction des exigences techniques et de sécurité
20.1
Algorithme de signature numérique D S A
519
du gouvernement américain pour les signatures numériques, nous pensons que le DSS est le meilleur choix. En fait, le DSS est utilisé dans un pro jet pilote pour le système de messagerie de la défense [« Defense Message System »] afin de garantir l’authenticité de messages électroniques pour des informations vitales de commandement et de contrôle. Le prototype initial inclut la participation de l’état-major, les services de l’armée, des agences de la défense et il est réalisé en collaboration avec le N IST. » Je ne vais pas épiloguer sur l’honnêteté de la N SA. Prenez leurs commentaires comme bon vous semble.
Attaques contre
k
Chaque signature requiert une nouvelle valeur de k, et cette valeur doit être choisie aléatoirement. Si jamais Estelle récupère une valeur de k que Alice a utilisé, éventuel lement en exploitant certaines propriétés du générateur de nombres aléatoires qui a produit k, elle peut retrouver la clef privée x d’Alice. Si jamais Estelle récupère deux messages signés ou chiffrés avec la même valeur de k, elle peut retrouver x (même sans connaître cette valeur de k). Et avec x, Estelle peut falsifier la signature d’Alice de manière indétectable. Dans toute réalisation du D SA, un bon générateur de nombres aléatoires est essentiel pour la sécurité du cryptosystème [1475].
Danger d’un module commun Même si le DSS ne spécifie pas un module commun à partager entre tout le monde, dif férentes réalisations le peuvent. Par exemple, le service des impôts américain (1RS pour « Internai Revenue Service ») envisage d’utiliser le DSS pour la soumission électro nique des déclarations de revenu. Que se passera-t-il s’ils obligent tous les contribuables du pays à utiliser les mêmes p et g? Même si le standard ne requiert pas un module commun, cette réalisation accomplit la même chose. Le danger d’un module commun est qu’il devient une cible tentante. Il est trop tôt pour savoir quelle réalisation du DSS sera adoptée mais il y a certaines raisons de s’inquiéter.
Canal subliminal dans le DSS Gus S i m m o n s a découvert un canal subliminal dans le DSS [1475, 1478] (voir § 23.3). Ce canal subliminal permet aux gens de cacher un message secret dans leur signa ture et ce message peut seulement être lu par une autre personne qui connaît la clef. D’après S i m m o n s , c’est une « coïncidence remarquable » que « les limitations quant à l’introduction d’un canal subliminal, apparemment inhérentes au schéma E l G a m a l , peuvent toutes être surmontées » dans le DSS, et que le DSS « offre l’environnement le plus propice aux communications subliminales découvert à ce jour. » Le N IST et la
NSA n’ont pas fait de commentaires à propos de ce canal subliminal ; personne ne sait même s’ils étaient au courant de son existence. Comme ce canal subliminal permet à un réalisateur peu scrupuleux de laisser fuir un morceau de la clef privée avec chaque signature, il est important de ne jamais utiliser une réalisation du DSS si l’on n’a pris confiance en celui qui l’a faite.
520
Chapitre 20
Algorithmes de signature numérique à clef publique
Brevets David K r a v i t z , qui a travaillé à la N SA, détient un brevet sur le DSS [898]. D’après le N IST [541] : « Le N IST a l’intention de rendre cette technique DSS le monde entier, sans perception de droits, dans l’intérêt pensons que cette technique est brevetable et qu’aucun s’applique au DSS, mais nous ne pouvons pas donner des de cela avant l’émission du brevet. »
disponible dans du public. Nous autre brevet ne garanties fermes
Même ainsi, trois détenteurs de brevets prétendent que le DSA enfreint leur propre brevet: D i f f i e H e l l m a n (voir § 22.1) [720], M e r k l e - H e l l m a n (voir § 19.2) [723] et S c h n o r r (voir § 21.3) [1404]. Le brevet de S C H N O R R est le plus névralgique. Les deux autres expirent en 1997 ; celui de S C H N O R R est valable jusqu’en 2008. L’algorithme de S C H N O R R n’ayant pas été développé avec l’argent du Gouvernement américain, contrairement aux brevets de P K P , le Gouvernement américain n’a aucun droit sur le brevet de S C H N O R R , et celui-ci a breveté son algorithme dans le monde entier. Même si une cour de justice tranche en faveur du D S A , il n’est pas évident que les autres cours de justice de par le monde en feront autant. Est-ce qu’une société internationale va adopter un standard qui pourrait être légal dans un pays mais qui enfreindrait un brevet dans un autre ? Ce problème mettra du temps à être résolu ; au moment d’écrire ces lignes, il n’est même pas encore résolu aux Etats-Unis. En juin 1993, le N IST a proposé d’octroyer une licence d’exploitation exclusive du brevet du D SA à P u b l i c K e y P a r t n e r s [544]. Cet accord a été démenti suite à un tollé général et le standard a vu le jour sans qu’il n’y ait d ’accord. Le N IST a déclaré [540] : « ...Le N IST a fait suivre les protestations concernant d’éventuelles infrac tions de brevet, et a conclu qu’il n’y avait pas de protestation justifiée. » Le standard est officiel, les poursuites judiciaires sont menacées, et personne ne sait que faire. Le N IST a déclaré qu’il viendrait en aide aux personnes poursuivies pour infraction de brevet, si elles utilisent le D SA pour remplir un contrat gouvernemental. Il semble que les autres doivent se débrouiller eux-mêmes. L’AN SI a ébauché un standard bancaire utilisant le D SA [63]. Le NIST travaille à la standardisation du DSA à l’intérieur du gouvernement. S h e l l a fait du D S A son standard international. Je ne connais aucune autre proposition de standard utilisant le DSA.
20.2
Variantes de DSA
Cette variante rend le calcul du signataire plus facile en ne l’obligeant pas à calculer k 1 [1144]. Tous les paramètres sont identiques à ceux de DSA. Pour signer un message AA, Alice génère deux nombres aléatoires k et d, tous les deux inférieurs à q. La signature est donnée par : r = (gk mod p) mod q s = (H (A 4) + xr) x d mod q
20.2
Variantes de D S A
521
t = kd mod q
Bernard vérifie la signature en calculant : w = t /s mod q ui = (H(A4) x w ) mod q u2 = rw mod q
Si r — {{gUl x y u'2) mod p) mod q, alors la signature est vérifiée. La variante suivante rend le calcul plus facile pour le vérificateur [1048, 1631]. Tous les paramètres sont identiques à ceux de DSA. Pour signer un message A4, Alice génère un nombre aléatoire k inférieur à q. La signature est donnée par : r = (gk mod p) mod q s = k x ( H ( M ) + ær)_1 mod q
Bernard vérifie la signature en calculant : Ui = ( H (A4 ) x s) mod q u2 = sr mod q Si r = (( gUl x y U2) mod p ) mod q, alors la signature est vérifiée. Une autre variante permet de vérifier plusieurs signatures à la fois [1144], Si elles sont valides c ’est fini. Si une des signatures n’est pas valide, il reste à la trouver. Malheureusement, cette vaiiante n’est pas sûre ; le signataire, aussi bien que le vérifi cateur, peut facilement créer un ensemble de fausses signatures dont l’ensemble passe la vérification avec succès [984], Il existe aussi une variante de D SA pour la génération des nombres premiers, dans laquelle q et les autres paramètres de la génération sont codés dans p. On ne sait pas encore si ce schéma réduit la sécurité de DSA. 1° Choisissez une chaîne aléatoire S d’au moins 160 bits. Soit g sa longueur en bits.
2° Calculez U = SH A (S) ® S H A ((S + 1) mod 2S), où S H A est l’algorithme de hachage sûr (voir § 18.7). 3° Formez q à partir de U en mettant le bit le plus significatif et le bit le moins significatif tous deux à 1. 4° Vérifiez si q est un nombre premier. 5° Si q n’est pas un nombre premier, retournez à l’étape 1. 6° Mettez q, S, C et SH A (S ) bout à bout pour former p, où C est un mot de 32 zéros.
7° p = p — (p mod q) + 1. 8° p = p + q.
522
Chapitre 20
Algorithmes de signature numérique à clef publique
9° Si la partie de p correspondante à C est 0x7FFFFFFF, retournez à l’étape 1. 10° Vérifiez si p est un nombre premier. 11° Si p n’est pas un nombre premier, retournez à l’étape 7. L’avantage de cette variante est d’éviter le stockage des valeurs de C et S1 utilisées pour générer p et q ; elles se lisent dans p. Pour les applications avec peu de mémoire, comme les cartes à puces, cela peut s’avérer très intéressant.
20.3
Algorithme de signature numérique GOST
Ceci est un standard de signature numérique russe, appelé officielement GOST R 34.10-94 [658]. L’algorithme ressemble beaucoup au D SA , et utilise les paramètres suivants: p = un nombre premier de longueur comprise entre 509 et 512 bits, ou bien entre 1020 et 1024 bits. q — un facteur premier de p — 1 de 254 à 256 bits. a = un nombre inférieur à p — 1 tel que aq mod p = 1. x — un nombre inférieur à q. y = ax mod p.
L’algorithme utilise aussi une fonction de hachage: H (x). Le standard spécifie l’emploi de G O S T R 34.11-94 (voir § 18.11), une fonction basée sur l’algorithme à clef secrète G O S T (voir § 14.1) [659]. Les trois premiers paramètres, p, q et a, sont publics et peuvent être partagés par les utilisateurs d’un réseau. La clef privée est x ; la clef publique est y. Pour signer un message AA, 1° Alice génère un nombre aléatoire k inférieur à q. 2° Alice génère: r = ( ak mod p) mod q s - (xr + k x H (A4)) mod q.
Si H (A4) mod q = 0, Alice fait comme s ’il valait 1. S ir — 0, elle recommence avec une autre valeur de k. La signature est composée de deux nombres : r mod 2256 et s mod 2256. Elle les envoie à Bernard.
3° Pour vérifier la signature, Bernard calcule : v = H (A 4 )q~ 2 mod q Z\ — sv mod q
z2 = ((q — r) x u) mod q u = ((aZl x y 22) mod p) mod q.
20-4
523
Schémas de signature numérique à base de logarithmes discrets Si u = r, alors la signature est vérifiée.
La différence entre ce schéma et le DSA est qu’on pose s = (&” 1 x (xr + H (A 4))) mod q dans le DSA, ce qui conduit à une équation de vérification différente. Il est curieux de fixer la longueur de q à 256 bits. La plupart des cryptographes occidentaux s’étalent mis d ’accord sur les alentours de 160 bits. C ’est peut-être une manière de penser russe qui veut un maximum de sécurité. Le standard est en utilisation depuis 1995, et n’est pas classé « pour utilisations spé ciales », quoi que cela puisse vouloir dire.
20.4
Schémas de signature numérique à base de logarithmes discrets
E l G a m a l , S c h n o r r (voir § 21.3) et DSA sont des schémas de signature numérique très similaires. En fait, ce sont trois exemples d’un schéma général de signature numé rique basé sur le problème des logarithmes discrets. Ces trois schémas et bien d’autres font partie de la même famille [742, 743, 700, 1189]. Choisissez un grand nombre premier p , et prenez q égal à p — 1 ou à un grand facteur premier de p — 1. Choisissez alors un nombre g entre 1 et p tel que gq = 1 (mod p). Tous ces nombres sont publics et peuvent être partagés par un groupe d ’utilisateurs. La clef privée x est inférieure à ç. La clef publique est y = gx mod q. Pour signer un message A4, commencez par tirer un nombre aléatoire k inférieur à q et premier avec q. Si q est premier, n ’importe quel k inférieur à q convient. Calculez d’abord : r = gk mod p
L’équation de signature généralisée devient maintenant : ak = b + e x mod q
Les coefficients a, b et c sont à prendre parmi une variété de termes. Chaque ligne du tableau 20.4 correspond à six possibilités (selon les six permutations de a,b,c).
Tab.
20.4
Permutations possibles de a,b,c (s est la signature et on pose r' ±s ±r' M ±5 1 ± r 'M 1 ±sM ±r'A4 1 ir 's ±r'A4 1 ± r 's ±sA4
=
r mod q)
Pour vérifier la signature, le destinataire doit s’assurer que : r“ = gbyc mod p Ceci s’appelle l’équation de vérification Le tableau 20.5 donne les équations de signature et les équations de vérification cor respondantes que l’on peut obtenir uniquement avec la première ligne du tableau 20.4
Chapitre 20
524
Algorithmes de signature numérique à clef publique
sans tenir compte des ± . Cela fait six schémas de signature différents. En ajoutant des signes négatifs, on arrive à un total de 20 "schémas. En utilisant les autres valeurs possibles pour o, b et c, on obtient 120 schémas en tout.
T
a b
.
20.5 - Schémas de signature numérique à base de logarithmes discrets Equation de signature (1) r'k - - s + fA x mod p (2) r'k - - A4 + sx mod p (3) sk = r' + A4a: mod p (4) sk — A4 + r'x mod p (5) A4 k = s + r'x mod p (6) M k = r' + sx mod p
Equation de vérification rT -= mod p rT mod p rs =-mod p rs =: g M y r> mod p rM mod p = rM mod p =
gsyM =gMys gr'yM gsyr'
E l G a m a l [520, 521] et le D SA [1174] sont essentiellement basés sur l’équation (4). D’autres schémas sont basés sur l’équation (2) [28, 1631]. S C H N O R R [1401, 1403] est étroitement lié à l’équation (5), c ’est aussi le cas d ’un autre schéma [1188]. Une modi fication de l’équation (1) conduit au schéma proposé dans [1632]. Les autres équations sont nouvelles. Il y a plus. Vous pouvez transformer chacun de ces schémas à la manière du D SA en définissant r ainsi: r = (gk mod p) mod q
Gardez la même équation de signature, et modifiez l’équation de vérification ainsi : ui - o _16 mod q U2 = o _1c mod q r — (gUly u2 mod p) mod q (r mod q)a = gby c mod p.
Il existe deux possibilités dans cette veine [742, 743], que vous pouvez appliquez à chacun des 120 schémas, ce qui nous mène à un total de 480 schémas de signature numérique à base de logarithmes discrets. Mais attendez— il y a plus. Des généralisations et des variations supplémentaires per mettent de créer plus de 13000 variantes (elles ne sont pas toutes très efficaces) [742, 743]. Un des intérêts de R SA pour les signatures numériques est ce qui s’appelle la ré cupération de message. En vérifiant une signature R SA , vous calculez A4. Vous comparez alors le message A4 calculé et le message reçu et vérifiez ainsi la validité de la signature. Avec les schémas précédents, vous ne pouvez pas récupérer A4 quand vous calculez la signature ; vous avez besoin d ’un candidat A4 que vous utilisez dans l’équation de vérification. Il se trouve qu’il est possible de construire une variante à récupération de message pour tous les schémas de signature précédents. Pour signer, commencez par calculer r — mgk mod p,
20.5
525
O n g - S c h n o r r - S h a m ir
remplacez ensuite A4 par 1 dans l’équation de signature. Vous pouvez alors construire l’équation de vérification qui permet de calculer A4 directement. Vous pouvez faire de même avec les schémas à la manière D SA : r = (mgk mod p) mod q
Toutes les variantes sont aussi sûres les unes que les autres, il est donc sensé de choisir un schéma qui facilite les calculs. C ’est le calcul des inverses qui ralentit le plus ces schémas. Il se trouve que l’un des schémas permet de calculer à la fois l’équation de signature et l’équation de vérification sans inverse et de récupérer le message. Il s’appelle le schéma P-N EW [1189]. r = mg~k mod p s =r k — r'x mod q
A4 est récupéré (et la signature est vérifiée) ainsi : A4 = gsyT r mod p
Certaines variantes permettent de signer deux ou trois blocs de message à la fois [742] ; d’autres variantes peuvent servir pour les signatures en aveugle [743]. Ceci est un travail de recherche rem arquable. U n m od èle cohérent p erm et d e décrire tous les différents schém as de signature num érique à base de logarithm es discrets. A mon avis, cela m et fin aux querelles d e brevets entre SCHNORR [1404] et DSA [898] : DSA n ’est dérivé ni de SCHNORR, ni d e E l G a m a l . C e sont trois cas particuliers de cette con stru ction générale, qui n ’est pas brevetée.
20.5
Ong—Schnorr—Shamir
Ce schéma de signature utilise des polynômes modulo n [1229, 1230]. Choisissez un grand entier n (il n’est pas nécessaire de connaître la factorisation de n). Ensuite choisissez un nombre entier aléatoire /c, tel que k e t n soient premiers entre eux. Calculez h tel que : h — —k ~ 2 mod n = —(A;- 1 )2 mod n. La clef publique est faite de h et n ; k est la clef privée. Pour signer un message A4, engendrez premièrement un nombre aléatoire r tel que r et n soient premiers entre eux. Ensuite calculez : 51 = 1/2 x (A4 jr + r) mod n 5 2 = k /2 x (A 4 /r — r) mod n. La paire Si et S 2 est la signature. Pour vérifier une signature, confirmez que : (S f + h x S2)
A4
(mod n).
La version du schéma décrite ici est basée sur des polynômes quadratiques. Quand il fut proposé dans [1227], une récompense de 100 $ était offerte pour une cryptanalyse
Chapitre 20
526
Algorithmes de signature numérique à clef publique
réussie. Il a été prouvé qu’il n’est pas sûr [1265, 22] mais les auteurs ne se sont pas découragés. Ils proposèrent une version modifiée basée sur des polynômes cubiques qui n’est pas sûre non plus [1265]. Les auteurs proposèrent alors une version quartique qui fut également cassée [527, 1265]. Une variante qui évite ces problèmes est décrite dans [1143].
20.6
ESIGN
ESIGN est un schéma de signature numérique conçu par N T T J a p o n [1213, 585]. D’après ces auteurs, il est au moins aussi sûr et nettement plus rapide que le R SA et le D SA, avec des longueurs de clef et de signature similaires. La clef privée est une paire de grands nombres premiers p et q. La clef publique est n tel que n = p2 q. H (x) est une fonction de hachage qui opère sur un message m de sorte que H (A4) soit compris entre 0 et A4 II y a aussi un paramètre de sécurité k qui sera décrit plus loin.
1° Alice choisit un nombre aléatoire x, tel que x soit inférieur à pq. 2° Alice calcule: w, le plus petit nombre plus grand que (H(m ) — x k mod n)/pq s = x + (( w /k x k~ x) mod p)pq.
3° Alice envoie s à Bernard. 4° Pour vérifier la signature, Bernard calcule sk mod n. Il calcule aussi a, qui est le plus petit nombre plus grand que le nombre de bits de n divisé par 3. Si H(m) est inférieur ou égal à sk mod n, et si sk mod n est inférieur à H (rn )+ 2 a, alors la signature est considérée valable.
Cet algorithme peut être accéléré par précalcul. Ce précalcul peut être effectué à tout moment et n’a rien à voir avec le message à signer. Après avoir choisi x , Alice peut scinder l’étape 2 en deux étapes partielles. La première peut être précalculée. 2° (a) Alice calcule : u — x k mod n v = 1/(k x k~ l) mod p.
2° (b ) Alice calcule : w — le plus petit entier qui est plus grand que ( H (m) — u)jpq s = x + (wv mod p)pq.
Pour la taille des nombres généralement utilisés, ce précalcul accélère le processus de signature par un facteur 10- Presque tout le travail difficile est fait pendant l’étape de précalcul. Une présentation des opérations d ’arithmétique modulaire qui peuvent être utilisées pour accélérer l’algorithme ESIGN est donnée dans [1627, 1626]. Cet algorithme a également été étendu pour marcher avec des courbes elliptiques [1214].
20.7
Automates cellulaires
527
Sécurité d’ESIGN Quand cet algorithme fut originellement proposé, k valait 2 [1223]. Il fut alors rapide ment cassé par Ernie B r i c k e l l et John D e L a ü R E N T I S [265], qui ont ensuite étendu leur attaque au cas k = 3. Une version modifiée de l’algorithme [1211] fut cassée par S h a m i r [1212]. La variante proposée par [1212] fut cassée dans [1560]. ESIGN est le représentant actuel de cette famille d’algorithmes. Une autre attaque nouvelle [974] ne marche pas contre la variante d’ESIGN. Les auteurs recommandent actuellement les valeurs suivantes pour k : 8, 16, 32, 64, 128, 256, 512 et 1024. Ils recommandent également que p et q aient au moins 192 bits chacun, ce qui donne une longueur d ’au moins 576 bits pour n. (Je pense que n devrait être deux fois plus long.) Avec ces paramètres, les auteurs font l’hypothèse qu’ESlGN est aussi sûr que R SA ou R a b i n . Leurs analyses montrent des comparaisons de vitesse avec R S A , E l G a m a l et D SA qui leur sont favorables [584],
Brevets ESIGN est breveté aux États-Unis [1216], au Canada (brevet n° 255 784), en Angle terre, en France, en Allemagne et en Italie. Toute personne désireuse d’obtenir une licence d ’exploitation pour cet algorithme doit contacter: Intellectual Property Department, NTT, 1-6 Uchisaiwai-cho, 1-chome, Chiyada-ku, 100 Japan.
20.7
Automates cellulaires
Une nouvelle idée originale, étudiée par G u a M [666], est d’utiliser des automates cellu laires dans les cryptosystèmes à clef publique. Ce système est encore bien trop nouveau et n’a pas été étudié exhaustivement mais une analyse préliminaire suggère qu’il pour rait avoir une faiblesse cryptographique similaire à une faille rencontrée dans d’autres cas [564]. Toutefois, c’est un domaine de recherche prometteur. Le propre des auto mates cellulaires est que, même s’ils peuvent être inversés, il est impossible de calculer l’état précédent d’un état arbitraire en renversant les règles pour trouver le successeur. Cela ressemble fortement à une fonction à sens unique à brèche secrète.
20.8
Les autres algorithmes à clef publique
De nombreux autres algorithmes à clef publique ont été proposés et cassés au fil des ans. L’algorithme M a t S IJM O T O I m a i [1029] fut cassé dans [453], L ’algorithme C a d e fut proposé la première fois en 1985, cassé en 1986 [774] et renforcé la même année [290]. En plus de ces attaques, il existe des attaques générales pour décomposer des polynômes sur des corps finis [607]. Tout algorithme dont la sécurité dépend de la composition de polynômes sur des corps finis doit être considéré avec scepticisme, si ce n’est même avec méfiance. L’algorithme Y a g i s a w a combine l’exponentiation modulo p avec l’arithmétique mo dulo p — 1 [1625] ; il fut cassé dans [260]. Un autre algorithme à clef publique, proposé par T s u j i i , K u r o s a w a , I t o h , F u j i o k a et M a t s u m o t o [1556] n’est, pas sûr [959]. Un troisième système, L u c c io M a z z o n e [1003], n’est pas sûr [719]. Un schéma de signature basé sur les permutations birationnelles [1432] a été cassé le lendemain de sa
Chapitre 20
528
Algorithmes de signature mimétique à clef publique
présentation [385]. Tatsuaki O kam o to a plusieurs schémas de signature à son actif: l’un d ’eux est prouvé aussi difficile que le calcul des logarithmes discrets, et un autre est prouvé aussi difficile que le calcul des logarithmes discrets et la factorisation [1214]. D ’autes schémas similaires sont décrits dans [710]. Gustavus S im m ons suggéra d ’utiliser les J-algèbres comme base pour des algorithmes à clef publique [1461, 152]. Cette idée fut abandonnée après que des méthodes efficaces de factorisation des polynômes furent inventées [963]. Des semi-groupes de polynômes spéciaux ont été également étudiés [1621, 973] mais jusqu’à présent il n’en est rien sorti. Harald N ied e r r e it e r . a proposé un algorithme à clef publique basé sur des suites de registres à décalage [1167]. Un autre est basé sur les mots de Lyndon [1482] et un autre sur le calcul propositionnel [818]. Un algorithme à clef publique récent tire sa sécurité du problème de recouvrement de matrice [89]. Tatsuaki O k am o to et Kazuo O hta comparent de nombreux algorithmes de signature numérique dans [1220]. Les perspectives de créer des algorithmes à clef publique radicalement nouveaux et dif férents semblent bien faibles. En 1988, D i f f i e remarqua que la plupart des algorithmes à clef publique sont basés sur l’un des trois problèmes difficiles suivants [490, 492] : : Étant donné un ensemble de nombres uniques, trouver un sous-ensemble dont la somme est TV.
1. L e p r o b lè m e d e s e m p ile m e n t s
2. L e c a lc u l d e lo g a r it h m e s d is c r e t s : Si p est un nombre premier et g et M sont des entiers, trouver x tel que gx = M (mod p). 3. L a fa c t o r is a t io n : Si TV est le produit de deux nombres premiers : a. factoriser TV, b . étant donné les entiers M et C , trouver d tel que M d = C
(mod TV),
c. étant donné les entiers e et C, trouver M tel que M e = C
(mod TV),
d.
étant donné l’entier x, décider s’il existe un entier y tel que x = y 2
(mod TV).
D ’après D iffie [490, 492], le problème du logarithme discret fut suggéré par J. G ill , le problème de factorisation par K n u t h et le problème des em pilem ents par D iffie lui-même. Cette étroitesse des fondements mathématiques de la cryptographie à clef publique est dérangeante. Une percée pour le problème de la factorisation ou celui des logarithmes discrets peut rendre des classes entières d ’algorithmes à clef publique non sûrs. Une telle percée a déjà eu lieu pour le problème des empilements. D i f f i e remarque [490, 492] que ce risque est atténué par deux facteurs : « Les opérations dont la cryptographie à clef publique dépend actuelle ment — multiplication, exponentiation et factorisation — sont toutes des phénomènes arithmétiques fondamentaux. Elles ont été l’objet d’analyses mathématiques intenses pendant des siècles, et l’attention croissante qui a résulté de leur utilisation dans les cryptosystèmes à clef publique a dans l’ensemble renforcé plutôt que diminué notre confiance. « Notre capacité d ’effectuer des opérations arithmétiques sur des grands nombres a augmenté continûment et nous permet maintenant de réaliser nos systèmes avec des nombres suffisamment grands pour n’être plus vul nérables qu’à des percées foudroyantes en factorisation, en logarithmes ou en extraction de racines. »
20.8
Les autres algorithmes à clef publique
529
Comme nous l’avons vu, les algorithmes à clef publique basés sur ces problèmes ne sont pas tous sûrs. La force de tout algorithme à clef ne publique dépend pas seulement la complexité calculatoire du problème sur lequel il est basé ; la difficulté calculatoire d’un problème n’implique pas forcément un algorithme fort. Adi S h a m i r énumère trois raisons pour lesquelles il en est ainsi [1422] : 1. La théorie de la complexité traite en général des instances isolées de problèmes. Un cryptanalyste a en général à résoudre une grande quan tité de problèmes statistiquement reliés plusieurs textes chiffrés avec la même clef. 2. La complexité calculatoire d ’un problème est typiquement mesurée par son comportement en pire cas ou en cas moyen. Pour qu’un problème soit utile à un chiffrement, il doit être difficile à résoudre dans presque tous les cas. 3. Un problème arbitrairement difficile ne peut pas nécessairement être transformé en cryptosystème, et il doit être possible d’insérer une brèche secrète dans le problème de telle manière qu’il y ait un rac courci grâce à celle-ci et seulement grâce à elle.
Chapitre 21
Schémas d’identification 21.1
Feige—Fiat—Shamir
Le schéma d’authentification et de signature numérique d’Amos F i a t et Adi S h a m i r est décrit dans [568, 569]. Uriel F e i g e , A. F i a t et A. S h a m i r ont transformé l’al gorithme en un système de preuve d ’identité à divulgation nulle [546, 547]. C ’est le système de preuve d ’identité à divulgation nulle le mieux connu. Le 9 juillet 1986, les trois auteurs ont soumis une demande de brevet américain [1433]. À cause des applications militaires potentielles, la demande fut examinée par les mili taires. L ’Office des brevets américain avait six mois pour répondre par une autorisation de divulgation. Le 6 janvier 1987, trois jours avant l’expiration du délai, l’Office des brevets et marques a interdit la divulgation à la demande de l’armée. Us affirmèrent que « ... la divulgation ou la publication des informations à ce su jet... seraient nuisibles à la sécurité nationale [américaine] ...» L’ordre fut donné aux auteurs de notifier à tous les Américains auxquels les résultats de la recherche avaient été divulgués que toute divulgation non autorisée pouvait entraîner un emprisonnement de deux ans et/ou une amende de 10000 $. De plus, les auteurs devaient indiquer au commissaire de l’Office des brevets et marques le nom de tous les ressortissants étrangers à qui l’information avait été communiquée. C’était ridicule. Pendant toute la seconde moitié de 1986, les auteurs avaient présenté leurs travaux à des conférences en Israël, en Europe et aux Etats-Unis. Les auteurs eux-mêmes n’étaient pas citoyens américains; tout le travail de recherche avait été effectué au W e i z m a n n I n s t i t u t e en Israël. Le mot s’était répandu dans la communauté académique et la presse. Dans les deux jours l’interdiction de divulgation fut annulée; SHAMIR et d ’autres croient que la NSA a tiré les ficelles de cette annulation bien qu’il n’y ait eu aucun commentaire officiel. Vous trouverez plus de détails concernant cette aventure dans [947].
Schéma d’identification Feige—Fiat-Shamir simplifié Avant d ’émettre quelque clef privée que ce soit, l’arbitre choisit un module aléatoire n qui est le produit de deux grands nombres premiers. Dans la vie réelle, n doit être long d’au moins 512 bits et probablement plus près des 1024 bits. Cet n peut être partagé
532
Chapitre 21
Schémas d’identification
par un groupe de prouveurs1. Pour engendrer la clef publique et la clef privée de Patricia, un arbitre de confiance choisit un nombre v, tel que v soit un résidu quadratique modulo n. En d ’autres termes, choisissez v tel que x 2 = v (mod n) ait une solution et u-1 modulo n existe. C ’est la clef publique. Ensuite, calculez le plus petit s tel que s = V v " 1 (mod n). C’est la clef privée. Le protocole d’identification peut alors se dérouler comme suit : 1° Patricia choisit un nombre aléatoire r tel que r soit inférieur à n. Elle calcule ensuite x = r 2 mod n et envoie x à Victor. 2° Victor envoie un bit aléatoire b à Patricia. 3° Si b = 0, Patricia envoie r à Victor. Si b = 1, Patricia envoie y = (r x s) mod n à Victor. 4° Si b = 0, Victor vérifie que x = r 2 mod n, ce qui prouve que Patricia connaît
/x .
t
Si 6 = 1 ,
Victor vérifie que x — ( y 2 x u) mod n, ce qui prouve que Patricia
connaît \fv~~1.
Ce protocole est une a ccré d ita tio n simple. Patricia et Victor répètent ce protocole t fois, jusqu’à ce que Victor soit convaincu que Patricia connaît s. Il s’agit de la tech nique « couper-et-choisir ». Si Patricia ne connaît pas s, elle peut choisir r de manière
à tromper Victor s’il lui envoie un 0, ou elle peut choisir r de manière à tromper Victor s’il lui envoie un 1. Mais elle ne peut pas faire les deux. Les chances de tromper Victor une fois sont de 50 %. Les chances de le tromper t fois sont de 1 contre 2*. Un autre moyen d ’attaquer le protocole serait pour Victor de se faire passer pour Patricia. Il peut démarrer le protocole avec un autre vérificateur, Valérie. A l’étape 1, au lieu de choisir un r aléatoire, il pourrait juste réutiliser un vieil r qu’il a vu Patricia utiliser. Toutefois, les chances que Valérie choisisse le même b à l’étape 2 que celui choisi par Victor dans le protocole avec Patricia sont de 1 contre 2. Donc, les chances de tromper Valérie sont de 50 %. Les chances de la tromper t fois sont de 1 contre 2É. Pour que cela marche, il est impératif que Patricia ne réutilise pas un r. Si elle le faisait, et si Victor lui envoyait l’autre valeur de bit à l’étape 2, Victor aurait alors les deux réponses de Patricia. Il ne lui resterait alors qu’à en collecter t pour se faire passer pour Patricia.
Schéma d’identification Feige—Fiat—Shamir Dans leurs articles [546, 547], F e i g e , F i a t et S h a m i r montrent comment un montage parallèle peut augmenter le nombre d ’accréditations par rondes et réduire ainsi les interactions entre Victor et Patricia. Au départ, engendrez n comme ci-dessus, c ’est-à-dire comme un produit de deux grands nombres premiers. Pour engendrer les clefs publique et privée de Patricia, choisissez d’abord k nombres différents: Vi,V2,...,Vk, où Vi est un résidu quadratique modulo n. En d ’autres termes, choisissez Vi tel que x 2 = vt (mod n) ait une solution et vf 1 mod n 1. Les ca lcu ls son t plus fa ciles si n est u n en tier d e B lu m , m ais c e n ’est p as nécessaire p o u r la sécurité.
21.1
F e ig e - F
ia t
533
S h a m ir
existe. Cette chaîne Vi,V2 ,.-,Vk est la clef publique. Ensuite calculez les plus petits Si tels que s, = yjv ^ 1 (mod n). Cette chaîne Si,S2, -isfc est la clef privée. Et le protocole se déroule comme suit : 1° Patricia choisit un nombre aléatoire r inférieur à n. Ensuite, elle calcule x — r 2 mod n et envoie x à Victor. 2° Victor envoie une chaîne aléatoire binaire de k bits: bi,l>2 ,...,bk à Patricia. 3° Patricia calcule y = r x (s ,1 x sî? x ••• x s*fc) mod n. Elle multiplie les valeurs des Si entre elles sur la base de la chaîne binaire que Victor lui a envoyée. Si le premier bit de Victor est 1, alors si fait partie du produit, si le premier bit de Victor est 0 alors si ne participe pas au produit. Elle envoie y à Victor.
4° Victor vérifie que x = y 2 x (v*1 x v ^2 x ... x v£h) mod n. Il multiplie les valeurs des Si entre elles sur la base de la chaîne binaire. Si le premier bit est 1, s% participe au produit ; si le premier bit est 0, s x ne participe pas au produit.
Patricia et Victor répètent ce protocole t fois jusqu’à ce que Victor soit certain que Patricia connaît Si,S2 ,—,SkLes chances que Patricia puisse rouler Victor sont de 1 contre 2kt, où t est le nombre de fois qu’ils répètent le protocole. Les auteurs recommandent un rapport de probabilités de 1 contre 220 et suggèrent d ’utiliser k = 5 et t = 4. Si vous êtes plus paranoïaque, augmentez ces nombres.
Un exemple Voyons ce protocole en action sur des petits nombres. Si n = 35 (les deux nombres premiers sont 5 et 7), les résidus quadratiques possibles sont : 1 : x 2 = 1 (mod 35) a comme solutions : x = 4 : x 2 = 4 (mod 35) a comme solutions : x = 9 : x 2 = 9 (mod 35) a comme solutions : x = 11: x 2 = 11 (mod 35) a comme solutions: x 14 : x 2 = 14 (mod 35) a comme solutions : x 15 : x 2 = 15 (mod 35) a comme solutions : x 16 : x 2 = 16 (mod 35) a comme solutions : x 21 : x 2 = 21 (mod 35) a comme solutions : x 25 : x 2 = 25 (mod 35) a comme solutions : x 29: x 2 = 29 (mod 35) a comme solutions: x 30 : x 2 = 30 (mod 35) a comme solutions : x
1,6,29 ou 34. 2,12,23 ou 33. 3,17,18 ou 32. = 9,16,19 ou 26. = 7 ou 28. = 15 ou 20. = 4,11,24 ou 31. = 14 ou 21. = 5 ou 30. = 8,13,22 ou 27. = 10 ou 25.
Les inverses modulo 35 et leurs racines carrées sont : V
1 4 9 11 16 29
v~*
1 9 4 16 11 29
s = \/v~l
1 3 2 4 9 8
Chapitre 21
534
Schémas d’identification
Remarquez que 14,15,21,25 et 30 n’ont pas d ’inverses modulo 35, parce qu’ils ne sont pas premiers par rapport à 35. Cela a un sens, puisqu’il doit y avoir (5—1) x'(7—1)/4 = 6 résidus quadratiques modulo 35 (voir § 11.3). Ainsi, Patricia reçoit la clef publique constituée de k = 4 valeurs : {4,11,16,29}. La clef privée correspondante est {3,4,9,8}. Voici une ronde du protocole: 1° Patricia choisit le nombre aléatoire r = 16, calcule 162 mod 35 = 11 et envoie ce dernier à Victor.
2° Victor envoie à Patricia une chaîne binaire aléatoire {1,1,0,1}. 3° Patricia calcule 16 x ((31) x (41) x (9°) x (81)) mod 35 = 31 et envoie le résultat à Victor. 4° Victor vérifie que 312 x ((41) x (111) x (16°) x (291)) mod 35 = 11. Patricia et Victor répètent le protocole, chaque fois avec un nombre r aléatoire différent, jusqu’à ce que Victor soit satisfait. Avec des petites valeurs comme celles-ci, il n’y a pas vraiment de sécurité, Mais quand n a 512 bits ou plus de long, Victor ne peut rien apprendre de la clef secrète de Patricia, excepté le fait qu’elle la connaît.
Améliorât ions Il est possible de cacher des informations d ’identification dans le protocole. Faites l’hypothèse que / est une chaîne binaire représentant l’identification de Patricia: son nom, son adresse, son numéro de sécurité sociale, sa taille de chapeau, sa limonade préférée, etc. Utilisez une fonction de hachage à s*3ns unique H {x) pour calculer H (I ,j ) où j est un petit nombre aléatoire joint à I. Trouvez un ensemble de plusieurs j tels que H (I ,j) soit un résidu quadratique modulo n. Ces j deviennent Vi,V2 ,-,V k- La clef publique de Patricia est maintenant / et la liste des j . Elle envoie / et la liste des j à Victor avant l’étape 1 du protocole et Victor engendre Vi,V2 ,---,Vk à partir de H (I,j). Ainsi, après que Victor ait terminé avec succès le protocole avec Patricia, il est sûr que quelqu’un qui connaît la factorisation du module a certifié l’association entre I et Patricia en lui donnant les racines carrées des v1 dérivés de I. (Voyez le paragraphe 5.2 concernant le contexte du protocole.) Les auteurs, F e i g e , F i a t et S h a m i r incluent également les remarques suivantes concer nant la réalisation concrète [546, 547] : « Pour des fonctions de hachage non parfaites, il est conseillé de rendre I aléatoire en joignant une longue chaîne aléatoire R. Cette chaîne est choisie par l’arbitre et révélée à Victor avec I. « Dans des réalisations typiques, k doit être compris entre 1 et 18. Des valeurs plus grandes de k peuvent réduire le temps et la complexité des communications en réduisant le nombre de rondes. « La valeur de n doit au moins avoir 512 bits. « Si tous les utilisateurs choisissent leur propre n et le publient dans un fichier public de clefs, ils peuvent se passer d’un arbitre. Toutefois, cette variante similaire au R SA rend le schéma nettement moins pratique. »
21.1
Fe
ig e
F ia t - S
535
h a m ir
Schéma de signature Fiat—Shamir Pour transformer ce schéma d’identification en un schéma de signature, il suffit de transformer Victor en une fonction de hachage. Le premier avantage du schéma de signature numérique F iat —SHAMIR par rapport au R S A est qu’une signature typique ne requiert que 1 % à 4 % de multiplications modulaires. Il est donc nettement plus rapide. Pour ce protocole, nous utiliserons les noms d ’Alice et Bernard. La mise en place est la même que pour le protocole d’identification. Choisissez un entier n produit de deux grands nombres premiers. Engendrez la clef publique vi,V2 ,...,Vk et la clef privée si,s 2,...,sk telle que sx =
v f 1 ( mod n).
1° Alice choisit t nombres aléatoires plus petits que n : r\,r2 ,...,rt et calcule x 2, xt tels que Xi = r\ mod n.
X\,
2° Alice calcule l’empreinte de la juxtaposition du message et de la chaîne des Xi pour engendrer le flux de bits: H (m ,x i,x 2 ,...,xt). Elle utilise les k x t bits de cette chaîne comme valeurs de bij où i va de 1 à t et j va de 1 à k. 3° Alice calcule y i,y 2 ,...,yt tels que: x (sj41 x s*12 x — x sfcfc) mod n.
yi
Elle multiplie les valeurs des Si ensemble en fonction des valeurs aléatoires hl3. Si bu vaut 1, alors si fait partie du produit; si blt vaut 0, alors s i ne fait pas partie du produit. 4 ° Alice envoie à Bernard m, toutes les valeurs des bits bij et toutes les valeurs des yi. Il a déjà la clef publique d’Alice: îq,i;2 ,...,nfc.
5° Bernard calcule zi,z 2 l...,zt tels que: Zi — yf x (v\ %1 x v*2 2 x ... x
mod n.
Une fois de plus, Bernard effectue les multiplications en fonction des valeurs des bij. Remarquez que les zt doivent être égaux aux x.t.
6° Bernard vérifie que les premiers k x t bits de H(rn,zi,z 2 ,...,zt) sont les valeurs b^ qu’Alice lui a envoyées.
Tout comme pour le schéma d’identification, la sécurité de ce schéma de signature est proportionnelle à 1/ 2 kt. Il dépend aussi de la difficulté de factoriser n. F i a t et S h a m i r indiquent qu’il est plus facile de commettre une fausse signature quand la complexité de factoriser n est nettement inférieure à 2kt. Et, à cause des attaques des anniversaires (voir § 18.1), ils recommandent que k x t soit augmenté de 20 à 72 au moins. Ils suggèrent k = 9 et t — 8.
Schéma de signature Fiat—Shamir amélioré Silvio M i c a l i et Adi S h a m i r ont amélioré ie protocole F i a t - S h a m i r dans [1094], Ils choisissent les k premiers nombres premiers pour v\,v2 ,—,Vk- Donc, îq = 2,v2 = 3,^3 = 5, etc.
Chapitre 21
536
Schémas d’identification
C’est la clef publique. La clef privée Si,S2 ,---,Sk est une racine carrée aléatoire, déterminée par: st = J v t 1
(mod n).
Dans cette version, tout le monde doit avoir un n différent. Cette modification rend la vérification de signatures plus aisée. Cela n’affecte pas le temps requis pour engendrer les signatures ni la sécurité de ces signatures.
Autres améliorations Il existe également un schéma d ’identification à N participants basé sur l’algorithme F i a t S h a m i r [268]. Deux autres améliorations du schéma F i a t S h a m i r ont été pro posées dans [1228]. D ’autres variantes sont décrites dans [1370].
Schéma d’identification Ohta—Okamoto Ce protocole est une modification du F e i g e - F i a t S h a m i r , dont la sécurité dépend de la difficulté de la factorisation [1207, 1208]. Les mêmes auteurs ont également décrit un schéma de signature multiple (voir § 23.1) par lequel un certain nombre de gens peuvent signer un message séquentiellement [1209]. Ce schéma a été proposé pour les réalisations de cartes à puce [852].
Brevets F iA T - S h a m i r est breveté [1433]. Toute personne intéressée par une licence d’ex ploitation de l’algorithme doit contacter: Yeda Research and Development, The Weizmann Institute of Science, Rehovot 76100, Israël.
21.2
Guillou—Quisquater
F i a t S h a m i r fut le premier système pratique de preuve d ’identité à divulgation nulle. Il minimisait les calculs requis pour les échanges en augmentant le nombre d ’itérations du protocole et le nombre d ’accréditations par itération. Pour certaines réalisations, telles que les cartes à puce, ce n’est pas l’idéal. Les échanges avec le monde extérieur sont coûteux et la place nécessaire pour stocker chaque accréditation peut rapidement consommer les ressources restreintes de la carte à puce. G u i l l o u et Q u i s q u a t e r ont développé un algorithme d’identification à divulgation nulle plus adapté à de telles situations [671, 1291]. Le nombre d’échanges entre Patricia et Victor et le nombre d ’accréditations en parallèle pour chaque échange sont tout deux maintenus à leur strict minimum : il n’y a qu’un échange d ’une accréditation pour chaque preuve. La quantité de calcul nécessaire pour le schéma G u i l l o u -Q U ISQ U A T E R est, pour le même niveau de sécurité, supérieure d ’un facteur 3 à celle requise pour le schéma F i a t - S h a m i r . Tout comme le F i a t - S h a m i r , cet algorithme d ’identification peut être transformé en un algorithme de signature numérique.
21.2
53 7
G u i l l o u - Q u is q u a t e r
Schéma d’identification Guillou—Quisquater Patricia est une carte à puce qui veut prouver son identité à Victor. L ’identité de Patricia est un ensemble de références : une chaîne de données contenant le nom de la carte, la période de validité, un numéro de compte en banque, et toute autre in formation que l’application justifie. Cette chaîne de bits, appelée J 2, est analogue à la clef publique. D ’autres informations publiques, partagées par toutes les « Patricia » qui pourraient utiliser cette application, sont un exposant v et un module n, où n est le produit de deux nombres premiers secrets. La clef privée est B , calculée telle que JBV = 1 (mod n). Patricia envoie ses références J à Victor. Maintenant elle veut prouver à Victor que ces références sont bien les siennes. Pour ce faire, elle doit convaincre Victor qu’elle connaît B. Voici le protocole: 1° Patricia choisit un nombre entier aléatoire r tel que r soit compris entre 1 et n — 1. Elle calcule T = rv mod n et envoie celui-ci à Victor. 2° Victor choisit un nombre, entier aléatoire d tel que d soit entre 0 et v — 1. Il envoie d à Patricia.
3° Patricia calcule D — rB d mod n et l’envoie à Victor. 4°
Victor calcule T ' = D vJd mod n. Si T = T' (mod n)l ’authentification est réussie.
Les mathématiques ne sont pas si compliquées que cela : T ’ = D vJd = (rB d)v Jd = rvB dvJd = rv(J B v)d = rv ~ T
(mod n),
puisque que B a été construite pour satisfaire : JBV - 1
(mod n).
Schéma de signature Guillou—Quisquater Ce schéma d ’identification peut être converti en un schéma de signature, également adapté aux cartes à puce [672, 673]. La mise en place de la clef publique et celle de la clef privée sont les mêmes que précédemment. Voici le protocole : 1° Alice choisit un nombre entier aléatoire r, tel que r soit compris entre 1 et n — 1. Elle calcule T — rv mod n. 2° Alice calcule d = H ( M ,T ), où M
* 2.
est le message à signer et H (x) est une fonction de hachage à sens unique. La valeur d produite par la fonction de hachage à sens unique doit être comprise entre 0 et v — 1 [1291]. Si la valeur produite par la fonction de hachage n’est pas comprise dans cet intervalle, elle doit être réduite modulo v.
En fait, ces références peuvent constituer une chaîne plus longue et, dans ce cas, la valeur de
J sera la valeur de l’empreinte de l ’identité. C ette com plexité supplém entaire ne m odifie toutefois en
rien le protocole.
Chapitre 21
538
Schémas d’identification
3° Alice calcule D = rB d mod n. La signature est constituée du message AA, des deux valeurs calculées d et D et de ses références J.
4° Bernard calcule T ' = D vJd mod n. H calcule ensuite d' = H(AA,T'). Sid = d', Alice doit connaître B et sa signature est valide.
Multisignatures Que se passe-t-il si plusieurs personnes veulent signer le même document? Il y a une solution facile — chacune d’entre elles signe séparément — mais ce schéma de signature peut faire mieux que cela. Dans l’exemple suivant, Alice et Bernard signent le même document et Christine vérifie les signatures, mais n’importe quel nombre de personnes peuvent être impliquées dans le processus. Comme précédemment, Alice et Bernard ont leurs propres valeurs uniques J et B : Ja et Jb , et B a et B b - Les valeurs n et n sont communes à tout le monde dans le système. 1° Alice choisit un nombre entier aléatoire va tel que ta soit compris entre 1 et n — 1. Elle calcule Ta = r\ mod n et envoie Ta à Bernard. 2° Bernard choisit un nombre entier aléatoire r s tel que ru soit compris entre 1 et n — l. Il calcule Tb = r g mod n et envoie Tb à Alice. 3° Alice et Bernard calculent T = T aT b mod n 4° Alice et Bernard calculent d = H{AA,T), où Ad est le message à signer et H(x) une fonction de hachage à sens unique. La valeur d produite par la fonction de hachage à sens unique doit être comprise entre 0 et v — 1 [722], Si la valeur produite par la fonction de hachage n’est pas comprise dans cet intervalle, elle doit être réduite modulo v.
5° Alice calcule D a =
ta B a
mod n.
6° Bernard calcule D b — r s B g mod n. 7° Alice et Bernard calculent D = D a L>b mod n. La signature est constituée du message AA, des deux valeurs calculées d et D , et de leurs références à tous les deux, Ja et Jb -
8° Christine calcule J = Ja Jb mod n. 9° Christine calcule T ' — D vJ d mod n. Elle calcule ensuite d' — H{AA,T'). Si d = d', alors la multisignature est valide.
Ce protocole peut être étendu à n’importe quel nombre de participants. Quand plu sieurs personnes signent, ils multiplient tous les Tt individuels à l’étape 3 et leurs £)f individuels à l’étape 7. Pour vérifier une multisignature, il faut multiplier tous les J, des signataires à l’étape 8. Soit les signatures sont toutes valides, soit il y en a au moins une fausse.
21.3
Schnorr
Le schéma d ’authentification e t de signature de Claus S c h n o r r [1401, 1403] tire sa sécurité de la difficulté de calculer des logarithmes discrets. Pour engendrer une paire
21.3
539
S ch n orr
de clefs, choisissez deux nombres premiers p et q tels que q est un facteur premier de p — 1. Ensuite, choisissez un a qui ne soit pas égal à 1 et tel que aq = 1 (mod p). Tous ces nombres peuvent être communs à un groupe d’utilisateurs et peuvent être librement publiés. Pour engendrer une paire « clef publique — clef privée » particulière, choisissez un nombre aléatoire inférieur à q. C ’est la clef privée s. Ensuite calculez v = a~s mod p. C’est la clef pubüque.
Protocole d’authentification 1° Patricia choisit un nombre aléatoire r inférieur à q et calcule x — ar mod p. C ’est l!éta.pe de prétraitement qui peut être réalisée bien longtemps avant que Victor ne soit présent. Patricia envoie x à Victor.
2° Victor envoie à Patricia un nombre aléatoire e compris entre 0 et 2* — 1 (je parlerai de t plus loin).
3° Patricia calcule y = (r + s
X
e) mod q et envoie y à Victor.
4° Victor vérifie que x — ayve mod p. La sécurité est basée sur le paramètre t. La difficulté de casser l’algorithme est de l’ordre de 2*. S c h n o r r recommande que p ait environ 512 bits et q environ 140 bits. La valeur de t compatible avec ce niveau de sécurité est t = 72, que S c h n o r r estime assez sûre.
Protocole de signature numérique S c h n o r r peut aussi servir dans un protocole de signature d’un message Ai. La paire « clef publique — clef privée » est la même mais nous ajoutons maintenant une fonction de hachage à sens unique H {Ai).
1° Alice choisit un nombre aléatoire r inférieur à q et calcule x = ar mod p. Ce calcul est l’étape de prétraitement.
2° Alice joint le message à x et calcule l’empreinte du résultat: e = H(M,x). Alice calcule y = (r + se) mod q. La signature est composée de e et y ; elle envoie ces valeurs à Bernard.
3° Bernard calcule z — avve mod p. Il confirme ensuite que l’empreinte du mes sage joint à z donne bien e : e — H(M,z). Si tel est le cas, il considère la signature comme valide.
Dans son article,
Sch n o rr
cite les nouveautés suivantes de son algorithme :
« La plupart des calculs pour la génération de signature peuvent être effec tués lors d’une étape de prétraitement, indépendante du message à signer. Ce calcul peut donc être fait sur le temps d ’inoccupation du processeur
Chapitre 21
540
Schémas d’identification
et il n’affecte pas la vitesse de signature. Une attaque contre cette étape de prétraitement est décrite dans [447] mais je ne pense pas qu’elle soit pratique. « À niveau de sécurité identique, la longueur des signatures est plus petite p o u r S c h n o r r que p o u r
R SA . P a r exem ple, avec u n q de 140 bits, les
signatures n ’ont que 212 bits de long, m oins de la m oitié de la longueur des signatures
R SA . L e s signatures S c h n o r r sont également nettem ent plus
courtes que les signatures E
l
G
am al.
»
Bien sûr les considérations pratiques amènent parfois à abaisser encore le nombre de bits nécessaires à la sécurité de certains schémas : par exemple un schéma d ’identifica tion où le tricheur doit effectuer une attaque en ligne en quelques secondes seulement par rapport à un schéma de signature où le tricheur peut effectuer des années de calcul avant de montrer sa fausse signature. Une modification de cet algorithme, décrite dans [269] et réalisée par Emie B r i c k e l l et Kevin McCuRLEY, améliore sa sécurité.
Brevets est breveté aux États-Unis [1404] et dans de nombreux autres pays. En 1993, P K P a acquis les droits internationaux sur ce brevet (voir § 25.5). Le brevet américain expire le 19 février 2008. Sch n o r r
21.4
Convertir un schéma d’identification en un schéma de signature numérique
Il y a une méthode générale pour transformer un schéma d ’identification en un schéma de signature numérique : remplacez Victor par une fonction de hachage à sens unique. Le message n’est pas haché avant d’être signé ; au lieu de cela, le hachage est incorporé dans l’algorithme de signature. En principe, n ’importe quel schéma d’identification permet de faire cela.
Chapitre 22
Algorithmes d’échange de clefs 22.1
Diffie—Hellman
D i f f i e - H e l l m a n est le premier algorithme à clef publique qui fut inventé [494], Sa sécurité dépend de la difficulté de calculer des logarithmes discrets sur un corps fini par rapport à la facilité de calcul d ’exponentielles dans le même corps. D i f f i e —H e l l m a n peut être utilisé pour la distribution de clefs mais il ne peut pas être utilisé pour chiffrer et déchiffrer des messages. Alice et Bernard peuvent utiliser cet algorithme pour engendrer une clef secrète. Les mathématiques sont simples. Au départ, Alice et Bernard se mettent d’accord sur deux grands entiers, n et g, de telle manière que g soit primitif par rapport à n. Ces deux entiers n’ont pas à être secrets ; Alice et Bernard peuvent convenir de ces nombres sur un canal non sûr. Ils peuvent même être communs à un groupe d’utiüsateurs. Peu importe. Le protocole se déroule ainsi :
1° Alice choisit un grand nombre entier aléatoire x et envoie à Bernard le résultat du calcul: X — gx mod n.
2° Bernard choisit un grand nombre entier aléatoire y et à Alice le résultat du calcul : Y = gv mod n.
3° Alice calcule: k - Y œ mod n. 4 ° Bernard calcule : k' — X v mod n.
Les valeurs k et k' sont toutes deux égales à gxy mod n. Personne ne peut en écoutant la communication calculer cette valeur; celui qui écoute ne connaît que n, g, X et Y . À moins qu’il ne puisse calculer le logarithme discret et retrouver x ou y, il ne peut résoudre le problème. Ainsi k est la clef secrète qu’Alice et Bernard ont calculée indépendamment.
542
Chapitre 22
Algorithmes d’échange de clefs
Le choix de g et n peut avoir un impact substantiel sur la sécurité de ce système. Le nombre (n —1)/2 doit être premier [1263]. Plus important, n doit être grand, la sécurité du système dépend de la difficulté de factoriser des nombres de la taille de n. Et g doit être n’importe quelle racine primitive modulo n ; rien d’empêche de prendre la plus petite valeur de g qui convient (c’est généralement un nombre à un chiffre)1.
Diffie—Hellman avec trois participants et plus Le protocole d ’échange de clefs D i f f i e - H e l l m a n peut être facilement étendu à trois personnes et plus. Alice, Bernard et Christine engendrent ensemble une clef secrète. 1° Alice choisit un grand nombre entier aléatoire x et envoie X — gx mod n à Bernard.
2° Bernard choisit un grand nombre entier aléatoire y et envoie Y — gy mod n Christine.
3° Christine choisit un grand nombre entier aléatoire y et envoie Z — gz mod n Alice.
4° Alice envoie Z' = Z x mod n à Bernard. 5° Bernard envoie X ' = X v mod n Christine. 6° Christine envoie Y ' = Y z mod n Alice. 7° Alice calcule k = Y'x mod n. 8° Bernard calcule k = Z 'v mod n. 9° Christine calcule k = X ' z mod n. La clef secrète, k, est égale à gxyz mod n, et quiconque d’autre écoute la communication ne peut calculer cette valeur. Le protocole peut être aisément étendu à quatre personnes et plus ; il suffit d’ajouter les calculs des participants supplémentaires et les rondes de calcul additionnelles.
Extension de Diffie—Hellman Cet algorithme marche aussi dans les anneaux commutatifs [1263]. S h m u l e y et Kevin ont étudié une variante de l’algorithme dans laquelle le module est un nombre composé [1448, 1046]. V.S. M i l l e r et Neal K o b l i t z ont étendu l’algorithme aux courbes elliptiques [1101, 868]. Taher E l G a m a l a utilisé l’idée de base pour dé velopper un algorithme de chiffrement et de signature numérique (voir § 19.6). Cet algorithme marche également dans le corps de Galois Z / 2 k [1448, 1046]. Certaines réalisations suivent cette approche [884,1633,1634] parce que les calculs sont nettement plus rapides. Toutefois, les calculs cryptanalytiques sont aussi nettement plus rapides et il est donc important de choisir un corps assez grand pour assurer la sécurité. M cC urley
1. En fa it, il n ’est p as n écessaire q u e g so it un e racin e p rim itiv e m o d u lo n , m ais q u e le so u s-g rou p e m u ltip lic a tif q u ’il gén éré m o d u lo n so it g ra n d .
22.1
D if f ie - H
ellm an
543
Hugues Cette variante permet à Alice de générer une clef et de l’envoyer à Bernard [747]. 1° Alice choisit un grand nombre aléatoire x et génère : k = gx mod n. 2° Bernard choisit un grand nombre aléatoire y et envoie à Alice le résultat du cia,cul : Y = gv mod n.
3° Alice envoi à Bernard le résultat du clacul: X
—
Y x mod
n.
4° Bernard calcule: z ~ j/-1 mod n k' = X z mod n.
Si tout se passe bien, k = k'. L’avantage de ce protocole par rapport à D i f f i e - H e l l m a n est qu’il est possible de calculer k avant toute interaction, et Alice peut chiffrer un message avant de contacter Bernard. Elle peut l’envoyer à plusieurs personnes, et interagir ensuite avec eux pour échanger individuellement la clef.
Échange de clefs sans échanger de clef À l’intérieur d ’une communauté d ’utilisateurs, chacun d ’eux pourrait publier une clef publique X = gx mod n dans une base de données partagée. Si Alice veut communiquer avec Bernard, il lui suffit de consulter la clef publique de Bernard et de générer leur clef secrète. Elle peut alors chiffrer un message avec cette clef et l’envoyer à Bernard. Bernard consultera alors la clef publique d ’Alice pour générer 1a, clef secrète et déchiffrer le message. Chaque paire d’utilisateurs possède une unique clef secrète, et aucune communication préalable n’est nécessaire. Les clefs publiques doivent être certifiées pour empêcher l’at taque consistant à altérer la base de données et devraient être changées régulièrement. À part cela, c ’est une idée assez astucieuse.
Brevets L’algorithme d’échange de clefs D i f f i e - H e l l m a n est breveté aux Etats-Unis [720] et au Canada [721], Un groupe appelé « P u b l i c K e y P a r t n e r s » (P K P ) octroie des licences d ’exploitation de ce brevet en même temps que d ’autres brevets de cryptogra phie à clef publique (voir § 25.5). Le brevet américain expire le 29 avril 1997.
Chapitre 22
22.2
Algorithmes d’échange de clefs
Protocole point à point
L ’échange de clefs suivant D i f f i e - H e l l m a n est vulnérable à l’attaque de l’intercepteur. Un moyen de contourner ce problème est d’amener Bernard et Alice à signer leurs messages l’un l’autre [498]. Ce protocole fait l’hypothèse que Alice détient un certificat de la clef publique de Bernard et que Bernard détient un certificat de la clef publique d ’Alice. Ces certificats ont été signés par une autorité de confiance extérieure au protocole. Voici comment Alice et Bernard génèrent une clef secrète k : 1° Alice génère un nombre aléatoire x et l’envoie à Bernard. 2° Bernard génère un nombre aléatoire y. 17 calcule leur clef secrète k selon le protocole D i f f i e - H e l l m a n . Il signe x et y et chiffre le résultat avec k. Il envoie le résultat et y à Alice: y ,E k(SB {x,y)).
3° Alice calcule k à son tour. Elle déchiffre le reste du message de Bernard et vérifie sa signature. Elle envoie alors à Bernard un message consistant de x et y signé, puis chiffré avec leur clef partagée : E k(SA (x,y)).
4° Bernard déchiffre le message et vérifie la signature d’Alice.
22.3
Protocole à trois passes de Shamir
Ce protocole, inventé par S h a m i r mais jamais publié, permet à Alice et Bernard de communiquer confidentiellement sans aucun échange préalable de clefs secrètes ou de clefs publiques [1014]. Il fait l’hypothèse de l’existence d ’un algorithme de chiffrement à clef secrète qui est commutatif, c ’est-à-dire: EA (E B( M ) ) = E
b
(Ea (M )).
La clef secrète d’Alice est A ; la clef secrète de Bernard est B. Alice veut envoyer un message, A4, à Bernard. Voici le protocole : 1° Alice chiffre A i avec sa clef secrète et envoie le texte chiffré à Bernard Ci = E a ( M ) .
2° Bernard chiffre Ci avec sa clef secrète et envoie le texte chiffré à Alice C2 = E b ( E a ( M ) ) .
3° Alice déchiffre C2 avec sa clef secrète et envoie le texte chiffré à Bernard C3 = D
a
(E b (Ea (A4))) = D
a
{Ea {E b {M ))) = E
b
{M ).
22.4
545
COM SET
4° Bernard, déchiffre C3 avec sa clef secrète pour finalement retrouver le texte du
message en clair.
Les masques jetables sont commutatifs et offrent la sécurité parfaite mais ils ne peuvent pas être utilisés pour ce protocole. Avec la technique du masque jetable, les trois messages seraient : Cx =
M® A
C2 = M e A ® B C 3 = M 0 B.
Estelle, qui peut enregistrer ces trois messages quand ils transitent entre Alice et Bernard, peut simplement les combiner par ou exclusif pour retrouver le message : Ci
® C 2 0 C 3 = ( M 0 A) © ( M 0 A © B ) © ( M © B ) = AA.
Manifestement, cela ne marche pas. S h a m i r décrit un algorithme de chiffrement qui est adapté à ce protocole ; celui-ci est similaire au R SA . Soit p un grand nombre premier tel que p — 1 a un grand facteur premier (afin d ’éviter le calcul facile du logarithme discret modulo p). Choisissez une clef de chiffrement e et une clef de déchiffrement d tout comme vous les choisiriez pour le RSA. La clef de chiffrement e doit être première par rapport à p — 1. Calculez d en utilisant l’algorithme d’EüCLiDE de telle manière que de = 1 (mod p — 1). Pour chiffrer un message calculez : C — AAe mod p. Pour déchiffrer un message calculez : AA = Cd mod p.
D ne semble pas y avoir de moyen pour Estelle de retrouver le message AA sans devoir calculer le logarithme discret mais, comme tant d’autres choses en cryptographie à clef publique, cela n’a jamais été prouvé. Ce protocole offre quelque chose que le chiffrement à clef publique simple n’offre pas. Il permet à Alice d’amorcer une communication avec Bernard sans connaître aucunes de ses clefs. Si Alice voulait utiliser un algorithme à clef publique, elle devrait connaître la clef publique de Bernard. Avec le protocole à trois passes de S H A M I R , elle lui en voie seulement un message chiffré. La même chose avec un algorithme à clef publique ressemble à ceci : 1° Alice demande à Bernard (ou au C D C ) sa, clef publique. 2° Bernard (ou le CDCJ envoie à Alice sa clef publique. 3° Alice chiffre AA avec la clef publique de Bernard et lui envoie le résultat. Le protocole de
22.4
Sham
ir
est vulnérable à l’attaque de l’intercepteur.
COM SET
C O M S E T (pour « COMmunications SETup ») est un protocole d’identification mu tuelle et d’échange de clefs développé pour le projet R IP E [1316] (voir § 25.7). En
546
Chapitre 22
Algorithmes d’échange de clefs
utilisant la cryptographie à clef publique, il permet à Alice et Bernard de s’identifier l’un à l’autre par eux-mêmes et aussi d’échanger une clef secrète. Les principes mathématiques sous-jacents à C O M S E T sont basées sur le schéma de R a b in [1294] (voir § 19.5). Le schéma lui-même a été proposé à l’origine dans [230]. Voyez [1316] pour plus de détails.
22.5
Échange de clefs chiffré
Le protocole d’échange de clefs chiffré (E K E pour « Encrypted Key Exchange ») a été conçu par Steve B e l l o v i n et. Michael M e r r i t t [116]. Il offre la confidentialité et l’authentification sur un réseau d’ordinateurs, en utilisant à la fois la cryptographie à clef secrète et la cryptographie à clef publique de façon originale : une clef secrète partagée est utilisée pour chiffrer une clef publique engendrée aléatoirement.
Protocole EKE basique Alice et Bernard (deux utilisateurs, un utilisateur et un ordinateur central, ou toute autre combinaison) partagent un mot de passe commun P. En utilisant le protocole suivant, ils peuvent s’authentifier l’un à l’autre et engendrer une clef commune de session, K . 1° Alice engendre une clef publique aléatoire, K ' . Elle chiffre celle-ci à l’aide d’un algorithme à clef secrète et de la clef P : E p(K' ) . Elle envoie à Bernard: Alice, Ep(K'). 2° Bernard connaît P. Il déchiffre le message pour obtenir K ' . Ensuite, il engendre une clef de session aléatoire, K , et la chiffre avec la clef publique qu ’il vient de recevoir d’Alice et la clef secrète P : E p (EK'(K)). Il envoie le résultat à Alice.
3° Alice déchiffre le message pour obtenir K . Elle engendre une chaîne aléatoire R a et la chiffre avec K et envoie le résultat à Bernard: E k ( R a ). 4° Bernard déchiffre le message pour obtenir Ra- Il engendre une autre chaîne
aléatoire R p, chiffre les deux chaînes avec K et envoie le résultat à Alice : E k {R a ,R b )-
5° Alice déchiffre le message pour obtenir R a et R p. En faisant l’hypothèse que la R a qu’elle, a reçue de Bernard est la même que celle qu’elle a engendrée à l’étape 3, elle chiffre R b avec K et l’envoie à Bernard: E r (R b )-
22.5
Échange de clefs chiffré 6° Bernard déchiffre le message pour obtenir R s - En faisant l’hypothèse que la R b qu’il a reçue d’Alice est la même que celle qu’il a engendrée à l’étape 4, le protocole est terminé. Les deux participants peuvent communiquer en utilisant la clef de session K .
À l’étape 3, Alice et Bernard connaissent tous deux K ' et K . K est la clef de session et elle peut être utilisée pour chiffrer tous les autres messages entre Alice et Bernard. Estelle, qui est entre Alice et Bernard, connaît seulement Ep( K' ) , E p (E k '(K)) et quelques messages chiffrés avec K. Dans d’autres protocoles, Estelle peut essayer de deviner P (les gens utilisent de mauvais mots de passe tout le temps et, si Estelle est maligne, elle peut faire certains paris judicieux) et ensuite essayer ses paris. Dans ce protocole, Estelle ne peut pas tester ses paris sans casser également l’algorithme à clef publique. Et si K ' et K sont choisis aléatoirement, cela peut être un problème insurmontable. La portion « défi réponse » du protocole, de l’étape 3 à l’étape 6, valide le protocole. Les étapes 3 à 5 prouvent à Alice que Bernard connaît K ; les étapes 4 à 6 prouvent à Bernard qu’Alice connaît K . L’échange de datations du protocole K e r b e r o s accomplit la même chose. EKE peut être réalisé grâce à plusieurs algorithmes à clef publique : R SA , E l G a m a l , D iffie -H e l l m a n . Il y a des problèmes de sécurité dans les réalisations utilisant l’al gorithme des empilements (mis à part les problèmes inhérents à cet algorithme) : la distribution normale des messages de texte chiffré vient à l’encontre des bien-faits de
EKE.
Réalisation d’EKE à l’aide du RSA L’algorithme R S A semble être le candidat idéal pour cette application, mais il pose quelques problèmes subtils. Les auteurs recommandent de ne chiffrer que l’exposant de chiffrement à l’étape 1 et d ’envoyer le module en clair. Une explication du raisonnement sous-jacent à cette recommandation, ainsi que d ’autres subtilités liées à l’utilisation du RSA sont décrites dans [116].
Réalisation d’EKE à l’aide d’ElGamal Réaliser E K E à l’aide d’ELGAMAL est évident, il y a même une simplification du protocole basique. En utilisant les notations du paragraphe 19.6, g et p font partie de la clef publique et sont communs à tous les utilisateurs. La clef privée est un nombre aléatoire r. La clef publique est gr mod p. Le message qu’Alice envoie à Bernard à l’étape 1 devient : Alice, gr mod p. Remarquez que cette clef publique n’a pas à être chiffrée avec P. Ce n’est pas vrai en général mais c ’est vrai pour l’algorithme E l G a m a l . Les détails sont donnés dans [116]. Bernard choisit un nombre aléatoire R (c’est pour l’algorithme E l G a m a l et c’est indépendant des nombres aléatoires choisis pour E K E ) et le message qu’il envoie à Alice à l’étape 2 devient : Ep(gR mod p, KgRr mod p).
Voyez le paragraphe 19.6 pour les restrictions dans le choix des variables d’ELGAMAL.
Chapitre 22
548
Algorithmes d’échange de clefs
Réalisation d’EKE à l’aide de Diffie-Hellman Avec le protocole D iF F t E H e l l m a n , K est engendrée automatiquement. Le protocole final est encore plus simple. Une valeur pour g et n est choisie pour tous les utilisateurs du réseau. 1° Alice choisit un nombre aléatoire
ta
et envoie à Bernard :
Alice, gTA mod n. Avec D i f f i e - H
ellm an
, Alice n’a, pas à chiffrer son premier message avec P.
2° Bernard choisit un nombre aléatoire rg et calcule: K = grAXrB mod n. I
Il engendre une chaîne aléatoire R g, puis calcule et envoie à Alice: E P(grB mod n),EK (RB).
3° Alice déchiffre la première moitié du message de Bernard pour obtenir gTB mod n. Ensuite, elle calcule K et utilise K pour déchiffrer R g . Elle engendre une autre chaîne aléatoire R a , chiffre les deux chaînes avec K et envoie le résultat à Bernard: E k {R a ,R b )-
4° Bernard déchiffre le message pour obtenir R a et R g . En faisant l ’hypothèse que la valeur de Rg qu’il a reçue d’Alice est la même que celle qu’il a envoyée à Alice à l’étape 2, ü chiffre R a avec K et envoie le résultat à Alice: E k (R a ). 5° Alice déchiffre le message pour obtenir R a - En faisant l ’hypothèse que la valeur de R a qu’elle a reçue de Berna,rd est la même que celle qu’elle a envoyée à l ’étape S, le protocole est terminé. Les deux participants peuvent communiquer grâce à la clef de session K .
EKE renforcé B e l l o v i n et M e r r i t t suggèrent une amélioration de la portion « défi - réponse » du protocole afin d ’éviter une attaque possible si un cryptanalyste est entré en possession d’une vieille valeur de K . Voyez le protocole de base EKE. A l’étape 3, Alice engendre un autre nombre aléatoire, S a et envoie à Bernard :
E k (R a ,Sa )•
À l’étape 4, Bernard engendre un autre nombre aléatoire S g et envoie à Alice : E k { R a ,R b ,Rg ) -
22.5
549
Échange de clefs chiffré
Alice et Bernard peuvent maintenant tous deux calculer la vraie clef de session S a ffi S p . Cette nouvelle clef est utilisée pour tous les futurs messages entre Alice et Bernard ; K n’est utilisée que comme clef d ’échange de clef. Voyons maintenant le niveau de protection offert. Si Estelle entre en possession de S, cela ne lui donne aucune information sur P car P n’est jamais utilisé pour chiffrer quoi que ce soit qui conduise directement à S. Une attaque cryptanalytique contre K n’est pas possible ; K est seulement utilisée pour chiffrer des données aléatoires et S n’est jamais chiffré seul.
EKE augmenté Le protocole E K E présente un sérieux défaut : les deux parties doivent posséder P. La plupart des systèmes d’authentification à mot de passe stockent une empreinte du mot de passe de l’utilisateur et non le mot de passe lui-même (voir § 3.2). Le protocole EKE augmenté (A -E K E ) utilise une empreinte du mot de passe de l’utilisateur comme clef de surchiffrement dans la variante D i f f i e - H e l l m a n de EKE. L ’utilisateur envoie alors un message supplémentaire basé sur le mot de passe originel, qui certifie l’authenticité de la nouvelle clef de session choisie. Voici comment cela fonctionne. Alice et Bernard veulent s’identifier l’un l’autre et générer une clef de session commune. Ils se mettent d ’accord sur un schéma de signature numérique où tout nombre est susceptible de servir de clef privée, et où la clef publique s’obtient à partir de la clef privée. E l G a m a l et R S A conviennent parfaitement. La clef privée P ' sera le mot de passe d’Alice ou seulement une empreinte de celui-ci. 1° Alice choisit un exposant aléatoire
ta
et envoie :
Ep'{gTA m od n ).
2° Bernard, qui ne connaît que P ' et ne peut pas en déduire P , choisit r& et envoie : Ep'(gTB mod n).
3° Alice et Bernard peuvent tovs les deux calculer la clef de session K = gTAyrB moci n Finalement, Alice prouve qu’elle connaît P lui même, et pas seulement P ', en envoyant : E k (Sp (K)).
Bernard qui connaît à la fois K et P' peut déchiffrer et vérifier la signature. Seule Alice a pu envoyer ce message puisqu’elle est la seule à connaître F ; un intrus qui obtiendrait une copie du fichier de mots de passe de Bernard peut essayer de deviner P, mais ne peut pas signer la clef de session. Le schéma A -E K E ne fonctionne pas avec la variante à clef publique de E K E puisque l’un des participants y choisit la clef et l’impose à l’autre. Cela permet une attaque de l’intercepteur par un attaquant qui a intercepté P.
Applications d’EKE B e l l o v i n et M e r r i t t suggèrent que ce protocole peut être utilisé pour des téléphones publics sûrs [116] :
« Faisons l’hypothèse que des téléphones publics chiffrés sont installés.
550
Chapitre 22
Algorithmes d’échange de clefs
Si quelqu’un veut utiliser l’un de ces téléphones, un moyen d’entrer de l’information doit être fourni. Les solutions conventionnelles ... nécessitent que l’appelant dispose d ’une clef physique, ce qui n’est pas souhaitable dans de nombreuses situations. E K E permet d’utiliser un mot de passe court entré par le clavier, mais utilise une clef de session nettement plus longue pour l’appel. « E K E serait aussi utile pour les téléphones cellulaires. La fraude a été un problème dans l’industrie des téléphones cellulaires ; E K E permet de s’en prémunir (et d’assurer la confidentialité de l’appel) en rendant le téléphone inutilisable si un P IN 2 n’a pas été entré. Comme le PIN n’est pas stocké dans le téléphone, il n’est pas possible d ’en récupérer un à partir d’un combiné volé. » La force principale d’E K E est que la cryptographie à clef secrète et la cryptographie à clef publique sont utilisées ensemble de façon à se renforcer mutuellement : « D ’un point de vue général, EK E fonctionne comme un amplificateur de confidentialité. En effet, il peut être utilisé pour renforcer des systèmes à clef secrète et à clef publique, comparativement faibles, quand ceux-ci sont utilisés ensemble. Considérez, par exemple, la taille de clef nécessaire pour garantir la sécurité quand on utilise un échange de clef exponentiel. Comme L a M a c c h i a et O d l y z k o l’ont montré [945], même des tailles de modules que l’on croyait sûres (à savoir 192 bits) sont vulnérables à une attaque qui ne requiert que quelques minutes de temps d’ordinateur. Mais leur attaque n’est pas réalisable si l’on doit d’abord deviner un mot de passe avant de l’appliquer. « Réciproquement, la difficulté de casser l’échange de clef exponentiel peut être utilisée pour empêcher les paris sur les mots de passe. La faisa bilité des attaques qui devinent les mots de passe dépend de la vitesse à laquelle on peut vérifier un pari. Si effectuer une telle vérification néces site la résolution d ’un échange de clef exponentiel, le temps total, sinon la difficulté conceptuelle, augmente hors de proportion. » EKE est breveté [117].
22.6
Négociation de clef fortifiée
Ce schéma a aussi pour but de protéger la négociation de clefs contre les mots de passe faibles et les attaques de l’intercepteur [48, 994]. Il utilise une fonction de hachage à sens unique de deux variables possédant une propriété très spéciale : elle offre beaucoup de collisions sur la première variable et en pratique aucune sur la seconde : H'(x,y) = H(H(k,x) mod 2m,x ) où H{k,x) est fonction de hachage ordinaire appliquée h, k et x.
Alice et Bernard partagent un mot de passe secret P, et viennent juste d’échanger une clef de session K avec le protocole de D i f f i e - H e l l m a n . Ils utilisent P pour vérifier 2.
N ote du traducteur : PIN est l’abréviation de « P e r s o n a l Id e n tific a tio n N u m b er » pou r « n u m éro
d ’id en tific a tio n p e r s o n n e l ».
22.7
Distribution de clef de conférence et diffusion de secret
551
qu’ils ont la même clef de session (et qu’Estelle n’est pas en train de tenter une attaque de l’intercepteur), sans dévoiler P à Estelle. 1° Alice envoie à Bernard H' (P, K).
2° Bernard calcule H' (P, K) et compare son résultat avec ce qu’il a reçu. S ’ils sont identiques, il envoie à Alice H ' ( H ( P , K ))
3° Alice calcule H' (H( P, K) ) et compare son résultat avec ce qu’elle a reçu. Si Estelle tente l’attaque de l’intercepteur, elle utilise une clef K i avec Alice et une clef K 2 avec Bernard. Pour tromper Bernard à l’étape 2, il faut qu’elle devine le mot de passe et qu’elle envoie H'(P,K-i) à Bernard. Avec une fonction de hachage classique, elle peut essayer les mots de passe usuels pour deviner le bon et réussir à infiltrer le protocole. Mais avec cette fonction de hachage, il existe beaucoup de mots de passe susceptibles de produire la même valeur quand ils sont hachés avec K\. Aussi, quand elle trouve un mot de passe qui convient, elle a de grande chances de ne pas avoir le bon, et Bernard ne se laissera pas duper.
22.7
Distribution de clef de conférence et diffusion de secret
Alice veut diffuser un message A4 à partir d ’un seul émetteur. Toutefois, elle ne veut pas qu’il soit intelligible pour tous les auditeurs. En fait, elle souhaite que seul un ensemble restreint d’auditeurs puissent être en mesure de reconstruire A4. Pour toute autre personne, cela doit être du charabia. Alice peut partager une clef différente (secrète ou publique) avec chaque auditeur. Elle chiffre le message avec une clef aléatoire K . Ensuite, pour chaque auditeur choisi, elle chiffre une copie de K avec la clef partagée avec l’auditeur. Finalement, elle diffuse le message chiffré et toutes les copies de K chiffrées. Bernard, qui écoute, soit essaie de déchiffrer toutes les K chiffrées avec sa clef secrète et cherche un résultat correct ; soit cherche son nom suivi de la clef chiffrée, si Alice ne se préoccupe pas du fait que l’on puisse savoir à qui elle diffuse le message. La cryptographie à clefs multiples convient. Une autre méthode est suggérée dans [356]. Au départ, chaque auditeur partage une clef secrète avec Alice, celle-ci étant plus grande que tout message chiffré diffusé. Toutes les clefs doivent être deux à deux premières entre elles. Elle chiffre le message à l’aide d’une clef aléatoire K . Ensuite, elle calcule un entier R tel que R soit congru à K modulo chaque clef secrète autorisée à lire le message, et congru à 0 modulo chaque clef secrète non autorisée. Par exemple, si Alice veut envoyer le message à Bernard, Christine et Etienne mais pas à David et Francis, elle chiffre le message avec K et calcule ensuite R tel que : R = K (mod K b ) R = K (mod K c ) R = 0 (mod K d )
552
Chapitre 22 R = K R = 0
Algorithmes d’échange de clefs
(mod K e ) (mod K f )-
C ’est un problème d ’algèbre facile, qu’Alice peut certainement résoudre. Quand les auditeurs reçoivent la transmission, ils calculent la clef reçue modulo leur clef secrète. S’ils sont autorisés à lire le message, ils récupèrent la clef K . Sinon, ils ne récupèrent rien du tout. Une troisième façon d ’opérer, en utilisant un schéma à seuil (voir § 3.7) est suggérée par Shimshon B e r k o v i t z dans [148]. Comme pour les autres, chaque auditeur potentiel reçoit une clef secrète. Cette clef est une part dans un schéma à seuil qui n’est pas encore mis en place. Alice garde quelques clefs secrètes pour elle-même afin de rajouter un peu de caractère aléatoire au système. Faisons l’hypothèse qu’il y a A; personnes qui écoutent. Alors pour diffuser A4, Alice chiffre A4 avec la clef K et fait ce qui suit : 1° Alice choisit un nombre aléatoire j . Ce nombre sert à cacher combien d’audi teurs sont visés par le message. Il n’a pas à être très grand; il peut être même aussi petit que 0 .
2° Alice crée un schéma à seuilfk -f j + 1 , 2k + j 4-1) avec : K comme clef secrète ; les clefs secrètes des auditeurs visés comme parts ; les clefs secrètes des auditeurs non visés ne sont pas des parts ; j parts choisies aléatoirement, différentes de toutes les clefs secrètes.
3° Alice émet k + j parts choisies aléatoirement, aucune d ’entre elles n’étant une part décrite à l’étape 2 . 4° Tous les auditeurs qui reçoivent l ’émission ajoutent leur part aux k + j parts
qu’ils ont reçues. Si l ’adjonction de leur part leur permet de calculer le secret, ils obtiennent la clef. Sinon, ils ne l’ont pas.
Une autre approche est décrite dans [8 8 6 , 885, 1203]. Pour une autre approche encore, consultez [1009].
Distribution de clef de conférence Ce protocole permet à un groupe de n utilisateurs de se mettre d’accord sur une clef secrète à travers un réseau de communication peu sûr. Le groupe partage deux grands nombres premiers p et q, et un générateur de même taille que q. 1° L ’utilisateur i, où i varie de 1 à n , choisit un nombre aléatoire r, inférieur à q et diffuse: z, = gr' mod p. 2
° Chaque utilisateur vérifie que z j = 1
(mod p) pour tout j entre 1 et n.
3° L ’utilisateur i diffuse :
X; = {z1+1/Z i-i)T' mod p.
22.7
Distribution de clef de conférence et diffusion de secret
553
4° L ’utilisateur i calcule : K =
i ) nr* x a;”
-1
x
x ••• x Xi- 2 mod p
Tous les indices des calculs du protocole, i,i — l,i — 2 , . . . ,i + 1, sont à prendre modulo n. A la fin du protocole, tous les utilisateurs honnêtes obtiennent le même K . Personne d’autre n’apprend quoi que ce soit. Cependant, ce protocole est vulnérable à l’attaque de l’intercepteur. Un autre protocole, moins beau que celui-ci, est décrit dans [759].
Tatebayashi-Matsuzaki-Newman Ce protocole de distribution de clef convient aux réseaux [1525]. Alice veut générer une clef de session avec Bernard grâce à Ivan, le C D C . Tous les participants connaissent la clef publique n de Ivan. Ivan connaît les deux grands facteurs premiers de n, et peut donc facilement calculer des racines cubiques modulo n. Une grande partie des détails est laissée de côté, mais l’idée est là. 1° Alice choisit un nombre aléatoire
ta
et envoie à Ivan :
r\ mod n. 2
° Ivan informe Bernard que quelqu’un veut échanger une clef avec lui.
3° Bernard choisit un nombre aléatoire r s et envoie à Ivan: rB mod n.
4° Ivan utilise sa clef privée pour retrouver ta
ta
et r s , et envoie à Alice:
® r B.
5° Alice calcule (rA <$rB) ® r A = r B. Elle utilise rB pour communiquer en sécurité avec Bernard.
Ce protocole paraît acceptable, mais il possède un horrible défaut. Christine peut écouter à l’étape 3 et utiliser cette information pour retrouver rB avec l’aide d’un utilisateur complice (David), et d’un Ivan peu suspicieux [1476]. 1° Christine choisit un nombre aléatoire r c et envoie à Ivan : r%r% mod n.
2° Ivan informe David que quelqu ’un veut échanger une clef avec lui. 3° David choisit un nombre aléatoire ru et envoie à Ivan: r\) mod n.
4° Ivan utilise sa clef privée pour retrouver rB et ce qu’il prend pour r c , et envoie à Christine:
(rBrc m od n) © ru-
Chapitre 22
554
Algorithmes d’échange de clefs
5° David envoie ru à Christine. 6°
Christine utilise r c et ru pour retrouver r s - Elle utilise r# pour espionner Alice et Bernard.
Ce n’est pas acceptable.
Chapitre 23
Algorithmes spéciaux pour protocoles 23.1
Cryptographie à clef publique à clefs multiples
Ceci est une généralisation du R S A (voir § 19.3 [220, 215]. Le module n est le produit de deux nombres premiers p et q. Toutefois, au lieu de choisir e et d tels que e x d = 1 (mod (p - 1 ) x (q — 1 )), choisissez t clefs kz telles que : ki x /c2 x ... x
=
1
(mod (p — 1 ) x (q — 1 )).
Comme : jV ffc,xfc2 x ...x k t
ceci est un schéma à clefs multiples tel que décrit dans le paragraphe 3.5. Si, par exemple, il y a 5 clefs, un message chiffré avec kz et k^ peut être déchiffré avec ki, k'2 et k/i i C = M k3* ks mod n M = c kixk2 xk4 m o d n
Cela sert pour les signatures multiples. Imaginez la situation où Alice et Bernard doivent tous les deux signer un document pour le rendre valide. Munissez les de trois clefs : Ki , K 2 et A 3 . Les deux premières sont destinées à Alice et Bernard, une chacun, et la troisième est rendue publique. 1° Alice signe A4 et envoie à Bernard : A4' = M Kl mod n.
2° Bernard peut retrouver A4 à partir de A4' : A4 — A4'K2XKs mod n.
556
Chapitre 23
Algorithmes spéciaux pour protocoles
3° Il peut aussi ajouter sa signature : A i " = AA'k 2 mod n.
4° Tout le monde peut vérifier la signature avec la clef publique : A i = A i " Ks mod n.
Notez qu’une personne de confiance extérieure est nécessaire à la mise en place du système et à la distribution des clefs. Un autre schéma présentant le même problème est décrit dans [482]. Un autre encore se trouve dans [697, 831, 701], mais la vérification y demande un travail proportionnel au nombre de signataires. Des schémas plus récents [223, 1209], basés sur les schémas de preuve à divulgation nulle vient à bout des défauts des systèmes précédents.
23.2
Algorithmes de partage de secret
Plus tôt, au paragraphe 3.7, j ’ai décrit l’idée sous-jacente aux schémas de partage de secret. Les quatre différents algorithmes qui suivent sont tous des cas particuliers d’un schéma théorique général [883].
Schéma du polynôme d’interpolation de L a g r a n g e Adi S h a m ir utilise des équations polynomiales sur un corps fini pour construire un schéma à seuil [1421]. Tout d’abord, choisissez un nombre premier p qui est plus grand que le nombre de parts possibles et plus grand que le plus grand secret possible. Pour partager un secret, engendrez un polynôme arbitraire de degré m — 1. Par exemple, pour créer un schéma à seuil (3,n) (trois parts sont nécessaires pour reconstruire Ai), engendrez un polynôme quadratique : F(x) = (ax2 + bx + Ai) mod p,
où p est un nombre premier plus grand que n’importe quel coefficient. Les coefficients a et b sont choisis aléatoirement ; ils sont tenus secrets et jetés après que les parts aient été distribuées. A i est le message. Le nombre premier doit être rendu public. Les parts sont obtenues en évaluant le polynôme en n points différents : kt = F ( x t).
En d ’autres termes, la première part pourrait être la valeur du polynôme évalué en x — 1, la deuxième part pourrait être la valeur du polynôme évalué en x = 2, etc. Comme le polynôme quadratique a trois coefficients inconnus, a, b et Ai, n’importe quel ensemble de trois parts peut être utilisé pour construire trois équations ; l’algèbre linéaire peut être utilisée pour retrouver Ai. Deux parts ne suffisent pas. Une part ne suffit pas. Quatre ou cinq parts sont redondantes. Par exemple, supposons que A i vaut 11 Pour construire un schéma à seuil (3,5), dans lequel trois personnes parmi cinq peuvent reconstruire Ai, engendrez une équation quadratique (7 et 8 ont été choisis aléatoirement) : F(x) = (7a;2 + 8a; + 11) m od 13.
23.2
Algorithmes de partage de secret
557
Les cinq parts sont : fcj = F ( l ) = 7 + 8 + l l = 0 (mod 13) fc2 = F (2) = 2 8 + 1 6 + 11 = 3 (mod 13) fc3 = F ( 3 ) = 63 + 24 + l l = 7 (mod 13) k4 = F ( 4 ) = 112 + 3 2 + 11 = 12 (mod 13) fc5 = F( 5) = 175 + 40 + 11 = 5 (mod 13). Pour reconstruire A4 à partir de 3 parts, par exemple, ta, ta et k5, il faut résoudre le jeu d’équations linéaires : a x 2 2 + f cx2 + M = 3 a x 3 2 + 6 x 3 + A4 = 7 a x 5 2+ 6 x 5 + M = 5
(mod 13) (mod 13) (mod 13).
La solution sera a = 7, b = 8 et A4 = II. Ainsi, on a retrouvé A4. Ce schéma de partage peut être facilement réalisé avec de grands nombres. Si vous vou lez diviser un message en 30 parts égales de telle manière que 6 d’entre elles quelconques permettent ensemble de reconstruire le message, donnez à chacune des 30 personnes le résultat de l’évaluation du polynôme de degré 5 : F(x) = (ax 6 + bx5 + ex4 + dx3 + ex 2 -f f x + A4) mod p.
Six personnes peuvent calculer les six inconnues (y compris A4) ; cinq personnes ne peuvent rien apprendre de A4. L’aspect le plus époustouflant du partage de secret est que si les coefficients sont choisis aléatoirement, cinq personnes disposant d’une puissance de calcul infinie ne peuvent rien apprendre du message à part sa longueur (que, de toute façon, ils connaissent tous). C’est aussi sûr qu’un masque jetable ; une tentative de recherche exhaustive (c’est-àdire, essayer toutes les combinaisons possible de six parts) révélerait que tout message concevable pourrait être le secret. C ’est vrai pour les quatre schémas de partage de secret présentés ici.
Schéma vectoriel George B l a k l e y a inventé un schéma qui utilise des points dans l’espace [189]. Le message est défini comme un point dans un espace à m dimensions. Chaque part est l’équation d ’un hyperplan de m — 1 dimensions qui inclut ce point. L ’intersection de n’importe quel ensemble de m de ces hyperplans détermine exactement ce point. Par exemple, si trois parts sont nécessaires pour reconstruire le message, alors c ’est un point dans un espace à trois dimensions. Chaque part est un plan différent. Avec une part, vous savez que le point est quelque part sur le plan. Avec deux parts, vous savez que le point est quelque part sur la droite d’intersection des deux plans. Avec trois parts, vous pouvez déterminer le point exactement : c ’est l’intersection des trois plans.
Asmuth—Bloom Ce schéma utilise des nombres premiers [70]. Pour un schéma à seuil-(m,n), choisissez un grand nombre premier p plus grand que A4. Ensuite choisissez n nombres inférieurs kp, dj, d2 , ..., dn tels que: 1. les valeurs des di soient en ordre croissant ; di < dL+i ;
558
Chapitre 23
Algorithmes spéciaux pour protocoles
2. chaque di soit premier par rapport à tous les autres d; ; 3. di x d2 x ... X dm > p X dn—m + 2 ^
m +3 ^ ••• ^ ^n*
Pour distribuer les parts, choisissez une valeur aléatoire r et calculez : A4' = A i + r p .
Les parts sont données par : ki = A4 1 mod d,.
Tout ensemble de m parts peut être utilisé pour reconstruire A i en utilisant le théorème du reste chinois, mais m — 1 parts ne le permettent pas. Voyez [70] pour les détails.
Karnin—G reene—Hellman Le schéma de K a r n in , G r e e n e et H e l l m a n utilise la multiplication matricielle [819]. Choisissez n + 1 vecteurs à m dimensions Vo, Vi, ..., Vn, tels que toute matrice m x rri formée à partir de ces vecteurs ait un rang m. Le vecteur U est le vecteur ligne de dimension m. A4, est le produit matriciel U - Vo- Les parts sont données par les produits matriciels U ■Vi, où i varie de 1 à n. Tout ensemble de m parts peut être utilisé pour résoudre le système de m x m équations linéaires où les inconnues sont les coefficients de U. Connaissant 17, on peut calculer U ■Vq. Tout ensemble de m — 1 parts ne permet pas de résoudre le système d’équations linéaires et ne permet donc pas de retrouver le secret.
Schémas à seuil avancés Les exemples précédents illustrent seulement les schémas à seuil les plus simples : di viser un secret en n parts de telle manière que m parts puissent être utilisées pour reconstruire le secret. Ces algorithmes peuvent être utilisés pour construire des sché mas bien plus compliqués. Les exemples suivants utiliseront l’algorithme de S h a m ir , bien que tout autre algorithme décrit ci-dessus puisse convenir. Pour créer un schéma pour lequel une personne est plus importante que les autres, donnez plus de parts à cette personne. Supposons qu’il faille avoir 5 parts pour recons truire le secret. Si une personne a trois parts différentes tandis que toutes les autres n’en ont qu’une alors cette personne et deux autres peuvent reconstruire le secret. Sans cette personne particulière, il faut cinq personnes pour reconstruire le secret. Deux personnes ou plus peuvent recevoir plusieurs parts. Chaque personne différente peut recevoir un nombre différent de parts. Peu importe la façon dont les parts sont distribuées, rn d ’entre elles quelconques peuvent être utilisées pour reconstruire le se cret. Quelqu’un qui a m — 1 parts, que ce soit une personne ou une assemblée, ne peut pas le reconstruire. Dans d’autres types de schémas, imaginez un scénario dans lequel il y a deux délégations hostiles. Vous pouvez partager un secret de telle manière que deux personnes parmi les sept de la Délégation A et trois personnes parmi les 12 de la Délégation B soient nécessaires pour reconstruire le secret- Construisez un polynôme de degré 3 qui soit le produit d’un polynôme linéaire et. d’un polynôme quadratique. Donnez à chaque membre de la Délégation A une part qui est le résultat d ’une évaluation du polynôme
23.2
Algorithmes de partage de secret
559
linéaire, et donnez à chaque membre de la Délégation B une part qui est le résultat d’une évaluation du polynôme quadratique. Deux parts quelconques de la Délégation A peuvent être utilisées pour reconstruire le polynôme linéaire mais, quel que soit le nombre de parts dont dispose le groupe, personne ne peut obtenir la moindre information sur le secret. La même chose est vraie pour la Délégation B : ils peuvent mettre trois parts en commun pour reconstruire le po lynôme quadratique, mais ils ne peuvent pas obtenir la moindre information nécessaire pour reconstruire le secret. Ce n’est que si les délégations mettent en commun leurs polynômes que ceux-ci peuvent être multipliés entre eux pour reconstruire le secret. En général, tout type de schéma de partage qui peut être imaginé peut être réalisé. Tout ce que vous avez à faire, c ’est trouver un système d’équations qui correspondent au schéma particulier choisi. D ’excellents articles concernant les schémas de partage de secret généralisés sont dans [1468, 1469, 1470].
Partage de secret avec des tricheurs Cet algorithme modifie le schéma à seuil-(m,n) standard pour détecter les tri cheurs [1537]. Cela marche avec n’importe quel schéma, mais je vais l’illustrer en utilisant le schéma de L a g r a n g e . Choisissez un nombre premier p plus grand que n et plus grand que :
(s — l)(ra — l ) / e + m,
où s est le secret le plus grand possible et e est la probabilité de tricher avec succès. Vous pouvez rendre e aussi petit que vous le voulez ; cela ne fait que rendre les calculs plus complexes. Construisez vos parts comme avant, sauf qu’au lieu d ’utiliser 1,2,3,...,n pour les Xi, vous choisirez des nombres aléatoires entre 1 et p — 1 pour les Xi. Maintenant si Martin s’introduit subrepticement dans la réunion de reconstruction du secret avec sa fausse part, celle-ci a une forte probabilité de ne pas être valide. Un secret impossible est, bien sûr, un secret contrefait. Voyez [1537] pour les détails mathématiques. Malheureusement, au moment où Martin est confondu comme tricheur, il apprend quand même le secret (en faisant l’hypothèse qu’il y a m autres parts valides). Un autre protocole, décrit dans [1537, 987], évite cela. L’idée de base est d’avoir une suite de k secrets telle qu’aucun des participants ne sache d’avance quel est le bon secret. Chaque secret est plus grand que le précédent, sauf pour le vrai secret. Les participants combinent leurs parts pour engendrer les secrets les uns après les autres, jusqu’à ce qu’ils créent un secret qui soit inférieur au secret précédent. C ’est le bon. Ce schéma dévoilera les tricheurs tôt dans le processus, avant que le vrai secret ne soit révélé. Il y a des complications quand les participants dévoilent leurs parts une par une ; voyez les articles pour les détails. D ’autres articles sur la détection et les préventions de la tricherie dans les schémas à seuil sont dans [359, 124, 274],
Chapitre 23
560
23.3
Algorithmes spéciaux pour protocoles
Canal subliminal
Ong—Schnorr—Shamir Ce canal subliminal (voir § 4.2), conçu par Gustavus S im m o n s [1464, 1465, 1467], utilise le schéma d ’identification O n g - S c h n o r r - S h a m ir (voir § 20.5). Comme dans le schéma original, l’expéditeur (Alice) choisit un module public n et une clef privée k telle que n et k soient premiers entre eux. Contrairement au schéma original, k est partagé entre Alice et Bernard, le destinataire du message subliminal. La clef publique est calculée de la même façon : h = —k ~ 2 mod n.
Si Alice veut envoyer un message subliminal A4 au moyen du message inoffensif A4', elle vérifie d ’abord que A4' et n sont premiers entre eux et que A4 et n sont premiers entre eux. Alice calcule : 51 = 1/2 x {AA' f A4 + M ) mod n 5 2 = k /2 x {A4'/A i - A4) mod n.
La paire 5 j et S 2 est à la fois la signature du schéma O n g - S c h n o r r -S h a m ir tradi tionnel et le porteur du message subliminal. Gatien, le gardien de prison, peut vérifier l’authenticité du message comme décrit par le schéma de signature O n g -Sc h n o r r —S h a m ir mais Bernard peut faire mieux. Il peut vérifier l’authenticité du message (il est toujours possible que Gatien introduise ses propres messages). Il peut vérifier que: (Sf — S ^/k2) = A4'
(mod n).
Si le message est authentique, le destinataire peut récupérer le message subliminal en utilisant la formule : AA = M '/{ S i + S i k - 1) mod n. C ela m arche, mais rappelez-vou s que le schém a O n g - S c h n o r r —SHAMIR a été cassé.
ElGamal Le deuxième canal subliminal de S im m o n s [1465], décrit dans [1412, 1477], est basé sur le schéma de signature E l G a m a l (voir § 19.6). La génération de clef est la même que pour le schéma de signature E l G a m a l de base. Choisissez d’abord un nombre premier p et deux nombres aléatoires g et r tels que g et r soient tous deux inférieurs à p. Ensuite calculez : K
=
gr m o d p.
La clef publique est constituée de K , g et p. La clef privée est r. En dehors d’Alice, Bernard connaît aussi r ; c ’est la clef qui est utilisée pour envoyer et lire le message subliminal, en plus d ’être la clef utilisée pour signer le message inoffensif.
23.3
561
Canal subliminal
Pour envoyer un message subliminal A4, en utilisant un message inoffensif A4', A4’ , A4 et p doivent être premiers entre eux deux à deux, et AA et p — 1 doivent être premiers entre eux. Alice calcule : X = gM m od p et résout l ’éq u ation suivante par ra p p ort à F (à l ’aide de l ’algoritlune d ’EuCLlDE) :
A4' = (r X + M Y ) mod (p - 1).
Comme dans le schéma E l G a m a l de base, la signature est la paire X et Y . Gatien peut vérifier la signature E l G a m a l . Il vérifie que : K x X Y mod p = gM
(mod p).
Bernard peut reconstruire le message subliminal. Il vérifie tout d’abord que : (gr)x X Y mod p = gM
(mod p).
Si tel est le cas, il accepte alors le message comme licite (ce n’est pas un message de Gatien). Ensuite, pour reconstruire A4, il calcule: A4 — Y ~ 1 (A4' — r X ) mod (p — 1).
Par exemple, soit p — 11 et g = 2. La, clef privée r choisie vaut 8. Cela signifie que la clef publique, que Gatien utilise pour vérifier la signature, vaut gr mod p = 28 mod 11 = 3. Pour envoyer le message subliminal, A4 = 9, en utilisant le message inoffensif A4' = 5, Alice vérifie que 9 et 11 sont premiers entre eux et que 5 et 11 sont premiers entre eux. Elle vérifie également que 9 et 11 — 1 sont premiers entre eux. Ils le sont, donc elle calcule : X = gM mod p = 29 mod 11 - 6.
Ensuite, elle résout l’équation suivante par rapport à Y : 5 = ( 8 x 6 + 9 x F ) mod 10. Ce qui donne F = 3, donc la signature est constituée de la paire: X et F : 6 et 3. Bernard vérifie que : ( gr)x X Y mod p = gM ' (mod p) (28)663 mod 11 = 25 (mod 11). Tel est le cas, donc il récupère le message subliminal en calculant : A4
=
Y ~ 1 (A4' — r X ) mod (p — 1) = 3"_1(5 — 8 x 6 ) mod 10
=
( 7 x 7 ) mod 10 — 49 mod 10 = 9.
Chapitre 23
562
Algorithmes spéciaux pour protocoles
ESIGN Un canal subliminal peut être ajouté à ESIGN [1467] (voir § 20.6). Pour ESIGN, la clef privée est une paire de grands nombres premiers, p et q, et la clef publique est n = p 2 q. Avec un canal subliminal, la clef privée est constituée de trois nombres premiers p, q et r, et la clef publique n est telle que : n — p 2 qr.
La variable r est l’information supplémentaire dont Bernard a besoin pour lire le mes sage subliminal. Pour signer un message normal, Alice choisit d ’abord un nombre aléatoire x inférieur à pqr et calcule : w, qui est le plus petit entier plus grand que ( H (m ) — x k m od n)/pqr s — x + (( w /k x k~ *) mod p)pqr . H (m ) est l’empreinte du message; k est le paramètre de sécurité. La valeur s est la signature. Pour vérifier la signature, Bernard calcule sk mod n. Il calcule aussi a, le plus petit entier plus grand que le nombre de bits de n divisé par 3. Si H(m ) est plus petit ou égal à sk mod n, et si sk mod n est plus petit que H (m ) + 2“ , alors la signature est considérée comme valide Pour envoyer un message subliminal AA en utilisant un message inoffensif A4', Alice calcule s en utilisant A4 au lieu de H(m ). Cela signifie que le message doit être plus petit que p 2qr. Elle choisit ensuite une valeur aléatoire u et elle calcule : x' — A4' + ur.
Ensuite, elle utilise cette valeur x' comme le « nombre aléatoire » x pour signer A4'. Cette deuxième valeur de s est envoyée comme la signature. Gatien vérifie que s (le deuxième s) est une signature valide de AA'. Bernard peut aussi vérifier l’authenticité du message de la même manière. Mais comme il connaît également r, il peut calculer : s = x' + ypqr — A4 + ur + ypqr = A4
(mod r).
Cette réalisation d’un canal subliminal est bien meilleure que les deux précédentes. Dans les réalisation de O n g - S c h n o r r S h a m ir et dans E l G a m a l , Bernard dispose de la clef privée d’Alice. En dehors du fait que Bernard peut lire les messages subliminaux d’Alice, il peut aussi se faire passer pour Alice et signer des documents à sa place. Alice ne peut rien y faire ; sa confiance en Bernard est nécessaire pour mettre en place ce canal subliminal. Le schéma ESIGN ne présente pas de ce défaut. La clef privée d’Alice est l’ensemble des trois nombres premiers p, q et r. La clef secrète de Bernard est seulement constituée de r. Il connaît n = p2 qr, mais pour récupérer p et q, il doit factoriser ce nombre. Si les nombres premiers sont assez grands, Bernard a autant de difficulté à se faire passer pour Alice que Gatien, ou que toute autre personne.
23.3
Canal subliminal
563
DSA Il y a aussi un canal subliminal dans le D SA (voir § 20.1) [1475, 1478, 1477]. En fait, il y en a plusieurs. Le canal subliminal le plus simple comprend le choix de k, qui est censé être un nombre aléatoire de 160 bits. Toutefois, si Alice choisit un k particulier, alors Bernard, qui connaît également la clef privée d ’Aüce, peut reconstruire k. Alice peut envoyer à Bernard un message subliminal de 160 bits dans chaque signature DSA. Toute autre personne peut seulement vérifier la signature. Ce n’est pas si simple. Puisque k doit être aléatoire, Alice et Bernard doivent partager un masque jetable et chiffrer le message subliminal avec le masque jetable pour engendrer k. Il existe des canaux subliminaux dans le D SA qui ne nécessitent pas que Bernard connaisse la clef privée d’Alice. Ils impliquent également le choix de valeurs particu lières pour k mais ils ne permettent pas de transmettre 160 bits d ’information. Le schéma suivant, présenté dans [1475, 1478], permet à Alice et Bernard d’échanger un bit d’information subliminale par message signé : 1° Alice et Bernard se mettent d’accord sur un nombre premier aléatoire P (dif férent du paramètre p du schéma de signature). C ’est leur clef secrète pour le canal subliminal.
2° Alice signe un message inojfensif A i . Si elle veut envoyer à Bernard un bit subliminal à 1, elle s ’assure que le paramètre r de la signature soit un résidu quadratique modulo P. Si elle veut lui envoyer un bit subliminal à 0, elle s ’as sure que le paramètre r ne soit pas un résidu quadratique modulo P. Elle réalise cela en signant le message avec des valeurs aléatoires de k jusqu’à ce qu’elle obtienne une signature où r a la bonne propriété. Comme les résidus quadra tiques et les résidus non quadratiques sont équiprobnbles, cela ne sera pas trop difficile.
3° Alice envoie le message signé à Bernard. 4° Bernard vérifie la signature pour s ’assurer de l ’authenticité du message. Ensuite, il vérifie si r est un résidu quadratique ou non modulo P et récupère ainsi le bit subliminal.
Il existe des moyens d’envoyer plusieurs bits par cette méthode qui implique le fait de rendre r résidu quadratique ou non d’un ensemble de paramètres. Voyez [1475, 1478] pour plus de détails. Ce schéma peut être facilement étendu pour envoyer plusieurs bits subliminaux par signature. Si Alice et Bernard se mettent d’accord sur deux nombres premiers P et Q, Alice peut envoyer deux bits en choisissant un k aléatoire tel que r soit un résidu quadratique ou non modulo P et tel que r soit un résidu quadratique ou non modulo Q. Une valeur aléatoire de k a 25 % de chances de produire un r de la bonne forme. Voici comment Martin, un réalisateur peu scrupuleux du DSS, peut arranger la fuite de 10 bits de la clef privée d ’Alice par document qu’Alice signe : 1° Martin met sa réalisation du DSS dans une puce VLSI résistante à l’investiga tion en sorte que personne ne puisse en examiner le fonctionnement. Il crée un canal subliminal de 14 bits dans sa réalisation du DSS. Pour ce faire, il choisit 14 nombres premiers, et la puce choisit la valeur k telle que r soit ou ne soit
Chapitre 23
564
Algorithmes spéciaux pour protocoles
pas un résidu quadratique modulo chacun des nombres premiers en fonction du message subliminal.
2° Martin distribue ses puces à Alice, Bernard, et toute autre personne qui en veut.
3° Alice signe un message normalement en utilisant sa clef privée de 160 bits y. 4° La puce choisit aléatoirement un bloc de 10 bits de y : les premiers 10 bits, le second groupe de 10 bits, etc. Comme il y a 16 blocs possibles de 10 bits, un nombre de 4 bits permet d’identifier de quel bloc il s ’agit. Cet identificateur de 4 bits plus les 10 bits de la clef forment le message subliminal de 14 bits.
5° La puce essaie des valeurs aléatoires de k jusqu’à ce qu’elle en trouve une avec les bonnes propriétés de résidus quadratiques pour envoyer le message subliminal. Les chances qu’un k soit correct sont de 1 contre 16384. En faisant l’hypothèse que la puce peut tester 10000 valeurs k par seconde, cela prendra moins de 2 secondes pour en trouver une. Ce calcul n’implique pas le message et peut être effectué hors ligne, avant qu’Alice ne veuille signer un message.
6° La puce signe le message normalement en utilisant la valeur k choisie à l’étape 5. 7° Alice envoie sa signature numérique à Bernard ou la publie sur le réseau ou par tout autre moyen.
8° Martin récupère r et, comme il connaît les 14 nombres premiers, il déchiffre le message subliminal.
Ce qui est effrayant, c ’est que même si Alice sait que cela se produit, elle ne peut pas le prouver. Tant que les 14 nombres premiers restent secrets, Martin est à l’abri.
Comment boucher le canal subliminal du DSA L’existence du canal repose sur le fait qu’Alice peut choisir k pour envoyer le message subliminal. Pour boucher le canal, il ne faut interdire à Alice de choisir k. Il faut aussi l’interdire à tout autre personne, qui pourrait imiter la signature d ’Alice si elle pouvait choisir k. La seule solution consiste à amener Alice à générer k conjointement avec une autre personne, appelons la Bernard, sans qu’Alice puisse contrôler un seul bit de k et sans que Bernard puisse connaître un seul bit de k. A la fin du protocole, Bernard doit pouvoir vérifier qu’Alice a bien utilisé le k qu’ils ont généré ensemble. Voici le protocole [1474, 1476, 1477] : 1° Alice choisit k' et envoie à Bernard : u = gk mod p
2° Bernard choisit k" et l ’envoie à Alice. 3° A lice calcule k — k'k" mod (p — 1). Elle utilise k pour signer son message M avec le D SA et envoie à Bernard la signature: r et s. 4° Bernard vérifie que (( uk mod p) mod q) = r. Si c ’est le cas, il sait que k a servi à signer AA.
23.f
Signatures numériques incontestables
565
Après l’étape 4, Bernard sait que r ne contient aucune information subliminale. S’il sert de personne de confiance, il peut certifier que la signature d ’Alice ne contient pas de message subliminal. Les autres doivent croire ce certificat; Bernard ne peut pas prouver ce fait à une troisième personne avec une transscription du protocole. Cela donne un résultat surprenant : si Bernard le veut, il peut utiliser ce protocole pour créer son propre canal subliminal. Bernard peut insérer un message subliminal dans une des signature d ’Alice en choisissant un k vérifiant certaines caractéristiques. Quand S im m o n s a découvert cela, il l’a appelé le « canal du coucou ». Les détails du fonctionnement du canal du coucou, et un protocole à trois passes de génération de k, qui l’évite, sont décrits dans [1479, 1477].
Autres schémas Il existe un autre schéma de signature dans lequel on peut cacher un canal sublimi nal [1464, 1467,1411]. Un protocole pour cacher un canal subliminal dans les protocoles F ia t - S h a m ir et F ia t - F e ig e - S h a m ir , ainsi que les abus possibles à l’aide de ce canal sont décrits dans [483]
23.4
Signatures numériques incontestables
Cet algorithme de signature incontestable (voir § 4.3) est dû à David C h a u m [338, 332]. Au départ, un grand nombre premier p et un élément primitif g sont rendus publics et utilisés par un groupe de signataires. Alice a une clef privée x et une clef publique gx mod p. Pour signer un message, Alice calcule z — m x mod p. C ’est tout ce qu’elle doit faire. La vérification est un petit peu plus compliquée : 1° Bernard choisit deux nombres aléatoires a et b tous deux inférieurs àp et envoie à Alice : c = za(gx)h mod p.
2° Alice calcule a:-1 mod (p — 1) et envoie à Bernard: d — cx
mod p.
3° Bernard vérifie que : d ~ magb
(mod p).
Si tel est le cas, il accepte la signature comme valide.
Imaginez qu’Alice et Bernard ayant effectué ce protocole, Bernard est convaincu qu’Alice a signé le document et il veut en convaincre Christine. Il montre à Christine une transcription du protocole. David veut convaincre Christine que quelqu’un d ’autre a signé ce document. Il crée une fausse transcription du protocole. Il engendre le mes sage de l’étape 1 . Ensuite, il effectue les calculs de l’étape 3 pour engendrer d et la fausse transmission venant de l’autre personne à l’étape 2. Enfin, il crée le message de l’étape 2. Pour Christine, les transcriptions de Bernard et de David sont toutes deux identiques. Elle ne peut pas être convaincue de la validité de la signature, à moins d’effectuer le protocole par elle-même.
Chapitre 23
566
Algorithmes spéciaux pour protocoles
Bien sûr, si elle avait regardé par dessus l’épaule de Bernard pendant l’exécution du protocole, elle aurait été convaincue. Christine doit voir les étapes exécutées dans le bon ordre, tout comme Bernard. Il peut y avoir un problème avec ce protocole de signature, mais je ne connais aucun détail. Je vous prie de consulter la littérature avant de l’utiliser. Un autre protocole offre non seulement le moyen pour Alice de convaincre Bernard de la validité de sa signature, mais il permet aussi à Alice de convaincre Bernard que sa signature n’est pas valide si tel est le cas, et ce à l’aide d ’un protocole interactif à divulgation nulle [335]. Tout comme pour le protocole précédent, un grand nombre premier p et un élément primitif g sont rendus publics et utilisés par un groupe de signataires. Alice dispose d’une clef privée x et d ’une clef publique gx mod p. Pour signer un message Alice calcule z = m æ mod p. Pour vérifier la signature : 1° Bernard choisit deux nombres aléatoires a et b tous deux inférieurs àp et envoie à Alice: c - m agb m od p.
2° Alice choisit un nombre aléatoire q inférieur àp, calcule et envoie à Bernard: si = ( e x gq) mod p ,
S2 — (c x gq)æ mod p.
3 ° Bernard envoie a et b à Alice afin qu ’elle puisse vérifier qu ’il n’a pas triché à
l’étape 1 .
4° Alice envoie q à Bernard, de telle manière qu’il puisse utiliser m x et recons truire S\ et S2 - Si: Si — ( e x gq) m od p s2 = ((
Alice peut également désavouer sa signature z pour un message m. Voyez [335] pour les détails. D’autres protocoles de signatures incontestables sont décrits dans [586, 348]. Lein H a r n et Shoubao Y a n g ont proposé un schéma de signature incontestable en groupe [701].
Signatures incontestables convertibles Un algorithme pour une s i g n a t u r e i n c o n t e s t a b l e c o n v e r t i b l e , qui peut être vérifiée, désavouée et également convertie en signature numérique conventionnelle est donné par [216]. Il est basé sur l’algorithme de signature numérique E l G a m a l . Tout comme pour E l G a m a l , choisissez deux nombres premiers p e t q tels que q divise p — 1. Maintenant, vous devez créer un nombre g inférieur à q. Choisissez un nombre aléatoire h entre 2 et p — 1 , puis calculez : g = h{p~ 1)' q mod p.
Si g vaut 1, choisissez un autre nombre aléatoire h. Sinon, gardez le g obtenu.
23.5
Signatures numériques à vérificateur dédié
567
La clef privée est composée de deux nombres aléatoires différents x et z, tous deux inférieurs à q. La clef publique est constituée de p, q, g, y et u, où : y = gx mod p, u = gz mod p.
Pour calculer la signature incontestable convertible du message m (qui est en fait l’empreinte d’un message), choisissez d’abord un nombre aléatoire t entre 1 et q — 1. Ensuite, calculez : T = (fi mod p et m ' = T tzm mod q. Maintenant, calculez la signature E l G a m a l standard de m'. Choisissez un nombre aléatoire R inférieur à (p — 1) et premier par rapport à p — 1. Ensuite calculez r = gR mod p et utilisez l’algorithme d ’EuCLlDE étendu pour calculer s tel que : m ' = (rx + Rs)
(mod q).
La signature est constituée de la signature E l G a m a l (r,s) et de T. Voici comment Alice vérifie la signature de Bernard : 1° Bernard engendre deux nombres aléatoires a et b. Il calcule c = T Tmagb mod p et envoie le résultat à Alice. 2°
Alice engendre un nombre aléatoire k et calcule hi = cgk mod p et h-2 = h\ mod p puis les envoie tous deux à Bernard.
3° Bernard envoie a et b à Alice. 4° Alice vérifie que c = T Tmagh mod p. Elle envoie k à Bernard.
5° Bernard vérifie que h\ = T Jrnagb 1k mod p et que h2 = yrarsauh+k mod p. Alice peut convertir toutes ses signatures incontestables en signatures normales, en publiant z. Maintenant tout le monde peut vérifier sa signature sans son aide. Les schémas de signature incontestable combinés avec les schémas de partage de secret permettent de créer des s i g n a t u r e s i n c o n t e s t a b l e s c o n v e r t i b l e s r é p a r t i e s [1245]. Une personne peut signer des messages et ensuite répartir la capacité de vérifier si la signature est valide. Elle peut, par exemple, rendre nécessaire la coopération de trois personnes parmi cinq pour convaincre Bernard que la signature est valide. Des améliorations de cette notion permettent de se passer de la participation d’une autorité de confiance [701, 1371],
23.5
Signatures numériques à vérificateur dédié
Voici comment il est possible qu’Alice signe un message et Bernard le vérifie, de sorte que Christine puisse prouver plus tard à David la validité de 1a, signature d ’Alice (voir § 4.4) [337].
Chapitre 23
568
Algorithmes spéciaux pour protocoles
Tout d’abord, un grand nombre premier p et un élément primitif g sont rendus publics et utilisés par un groupe d’utilisateurs. Le produit n de deux nombres premiers est aussi rendu public. Christine possède une clef privée z et une clef publique h = gx mod p. Dans le protocole qui suit, Alice peut signer A4 en convaincant Bernard de la validité de celle-ci, mais sans qu’il puisse lui-même convaincre une troisième personne de ce fait. 1° Alice choisit un nombre aléatoire x et calcule : a = gæ mod p b = hx mod p. Elle calcule l’empreinte H {Ai) de calcule alors:
Ai et celle de a et b juxtaposés, H{a,b). Elle
j = {H ( Ai) © H (o , 6 ) ) 1 / 3 mod n, et envoie a, b et j à Bernard.
2° Bernard choisit deux nombres aléatoires s et t inférieurs à p et envoie à Alice : c = gshf mod p.
3° Alice choisit un nombre aléatoire q inférieur à p et envoie à Bernard : d = gq mod p e = (cd)x mod p.
4° Bernard envoie s et t à Alice. 5° Alice vérifie si gshl = c
(mod p),
et envoie q à Bernard. 6°
Bernard vérifie si d ~ g q (mod p) e /a 9 = asbt (mod p) H { Ai) © H(a,b) = j 1 / 3
(mod n).
Si les trois équivalences sont vraies, il est convaincu de l’authenticité de la signature.
Bernard ne pourra pas convaincre David de l’authenticité de la signature d’Alice avec une transcription de la preuve ci-dessus; mais David peut mener un protocole avec Christine, le vérificateur dédié d’Alice. Voici comment Christine convaint David de la validité de la signature constituée de a et b : 1° David choisit deux nombres aléatoires u et v inférieurs à p et envoie à Christine :
k — guav m od p.
23.6
569
Calcul avec données chiffrées 2° Christine choisit un nombre aléatoire w inférieur à p et envoie à David : l — gw mod p y - ( kl)z m od p.
3° David envoie u et v à Christine. 4 ° Christine vérifie si
(mod p).
guav = k
Elle envoie ensuite w à David.
5° David vérifie si gw = 1
(mod p) y /h w = hubv
(mod p).
Si les deux équivalences sont vraies, il est convaincu de Vauthenticité de la signature.
Dans un autre protocole, Christine peut convertir le protocole de signature à vérifica teur dédié en un protocole de signature numérique conventionnel. Consultez [337] pour les détails.
23.6
Calcul avec données chiffrées
Le problème du logarithme discret Il y a un grand nombre premier p et un générateur g. Alice dispose d ’une valeur particulière pour x et veut connaître e tel que : ge = x
(mod p).
Ceci est normalement un problème difficile et Alice n ’a pas la puissance de calcul né cessaire pour trouver le résultat. Bernard dispose de la puissance de calcul nécessaire — disons qu’il travaille pour le gouvernement, par exemple, ou dans une grande or ganisation informatique. Voici comment Alice peut lui laisser faire les calculs sans lui révéler x [549, 8 ] : 1° Alice choisit un nombre aléatoire r inférieur à p. 2
° Elle calcule: x' = xgr mod p.
3° Elle demande à Bernard de résoudre : ge = x'
(mod p).
4° Bernard calcule e1 et l’envoie à Alice. 5° Alice retrouve e en calculant: e = (e1 — r) mod (p — 1 ).
Il existe des protocoles similaires pour le problème des résidus quadratiques et pour le problème des racines primitives [7, 8 ]. (Voyez aussi § 4.8.)
Chapitre 23
570
23.7
Algorithmes spéciaux pour protocoles
Pile ou face équitable
Le protocole suivant permet à Alice et Bernard de jouer à pile ou face via un réseau de communication (voir § 4.9) [201]. C ’est un exemple du lancement d ’une pièce dans un puits (voir § 4.10). En premier lieu, seul Bernard connaît le résultat du lancer et il le dit à Alice. Plus tard, Alice peut vérifier que Bernard lui a indiqué une valeur correcte du résultat du lancer.
Pile ou face à l’aide de racines carrées Sous-protocole de tirage à pile ou face :
1° Alice choisit deux grands nombres premiers p et q et envoie leur produit n à Bernard.
2° Bernard choisit un nombre entier positif aléatoire r inférieur ou égal à n/2, puis calcule: z = r 2 mod n et envoie z à Alice.
3° Alice calcule les quatre racines carrées de z modulo n. Elle peut le faire parce qu’elle connaît la factorisation de n. Appelons les + x , —x , + y et —y. Appelons x' le plus petit des deux nombres : x mod n —x m od n.
De même, appelons y' le plus petit des deux nombres : y mod n —y mod n.
Remarquez que r est soit égal à x' soit à y1.
4° Alice parie sur r — x' ou r = y' et envoie son pari à Bernard. 5° Si le pari d’Alice est correct, le résultat du lancer est « face », si son pari est faux, le résultat du lancer est « pile ». Bernard annonce le résultat du lancer. Sous-protocole de vérification : 6°
Bernard envoie r à Alice.
Alice n’a aucun moyen de connaître r et son pari est réel. À l’étape 4, elle ne donne à Bernard que 1 bit de son pari (un bit où x' et y' diffèrent) pour éviter qu’il n’ait à la fois x' et y'. Si Bernard avait les deux nombres, il pourrait changer r après l’étape 4.
23.7
571
Pile ou face équitable
Pile ou face à l’aide de l’exponentiation modulo p L’exponentiation modulo un nombre premier p est utilisée comme fonction à sens unique dans le protocole suivant [1317]. Sous-protocole de tirage à pile ou face : 1° Alice choisit un nombre premier p de telle manière que la factorisation de p — 1 soit connue et contienne au moins un grand nombre premier.
2° Bernard choisit deux éléments primitifs h et t dans Z /p . Il les envoie à Alice. 3° Alice vérifie que h et t sont primitifs et choisit un nombre aléatoire x premier par rapport à p — 1. Elle calcule ensuite l’une des deux valeurs : y = hx m od p
ou
y — tx mod p.
Elle envoie y à Bernard. 4° Bernard parie si y est une fonction de h ou de t et envoie son pari à Alice. 5 ° Si le pari de Bernard est correct, le résultat du lancer est « face ». Si le pari
de Bernard est faux, le résultat du lancer est « pile ». Alice annonce le résultat du lancer.
Sous-protocole de vérification : 6°
Alice révèle x à Bernard qui calcule hx mod p et tx mod p à la fois pour vérifier qu 'Alice a joué honnêtement et pour vérifier le résultat du lancer. Il vérifie aussi que x et p — 1 sont premier entre eux.
Pour tricher, Alice doit trouver deux entiers x et x' tels que hx = tx' connaissait de telles valeurs, elle pourrait calculer : logt h — x 'x ^ 1 mod (p — 1 )
et
log^ t = xx
(mod p). Si elle
1
Ce sont des problèmes difficiles. Alice serait capable de faire cela si elle connaissait logt h mais c’est Bernard qui a choisi h et t h l’étape 2. Alice n’a pas d ’autre recours que d ’essayer de calculer le logarithme discret. Alice pourrait aussi tenter de tricher en choisissant un x qui ne soit pas premier par rapport à p — 1 mais Bernard le détecterait à l’étape 6 . Bernard peut tricher si h et t ne sont pas primitifs dans Z /p mais Alice peut facilement le vérifier après l’étape 2 , car elle connaît la factorisation en nombres premiers de p —1 . L’avantage de ce protocole est que si Alice et Bernard veulent jouer plusieurs fois à pile ou face, ils peuvent utiliser les mêmes valeurs de p, h et t. Alice doit juste engendrer un nouvel x et le protocole continue à partir de l’étape 3.
Pile ou face à l’aide d’entiers de B lum Les entiers de B l u m peuvent être utilisés pour un protocole de tirage à pile ou face : 1° Alice engendre un entier de B lu m n, un nombre aléatoire x premier par rapport à n , x o = x 2 mod n et x i = x 2 mod n. Elle envoie n et x\ à Bernard. 2° Bernard parie sur la parité de
xq.
572
Chapitre 23
Algorithmes spéciaux pour protocoles
3 ° Alice envoie x et xq à Bernard.
4 ° Bernard vérifie que n est bien un entier de B l u m 1, et il vérifie que xq =
x 2 mod n et que X\ = x\ mod n. Si toutes les vérifications sont correctes et si son pari est correct, Bernard gagne le jeu.
Il est crucial que n soit un entier de B l u m . Sinon, Alice pourrait trouver un x'q tel que x'o 2 mod n — xq2 mod n = aq, où x'q est également un résidu quadratique. Si Xq était pair et x '0 impair (ou vice versa), Alice pourrait tricher librement.
23.8 Accumulateurs à sens unique Il existe une fonctin d ’accumulateur à sens unique simple (voir § 4.12) [126] : A(xi,y) = z f - i mod n
où n est le produit de deux nombres premiers. Les nombres n et æo doivent être choisis à l’avance d’un commun accord. L’accumulation de y \, ?/2 et jfy est alors donnée par : ((xq 1 mod n )V2 mod n)ya m od n Ce calcul dépend de l’ordre de j/i, ?y2 et 2/3 .
23.9
Divulgation tout ou rien de secrets
Ce protocole permet à plusieurs participants (deux participants au moins sont néces saires pour que le protocole marche) d ’acheter des secrets individuels à un seul et même vendeur (voir § 4.13) [1376, 1181]. Tout d ’abord, voici la définition. Prenez deux chaînes de bits x et y. L ’i n d e x d e b i t s i d e n t i q u e s (abrégé IBI) de a: et y est composé des indices i de bits tels que le ie bit de x soit égal au ie bit de y. Par exemple : x = 110101001011 y = 101010000110
IBI(a;,t/) = { 1 ,4 ,5 ,1 1 }. (Nous lisons les bits de droite à gauche avec l’indice le plus à droite valant 0 .) Voici maintenant le protocole. Alice est le vendeur. Bernard et Christine sont les ache teurs. Alice dispose de k secrets de n bits : S i, S2, ..., S*. Bernard veut acheter le secret Sb et Christine veut acheter le secret Sc. 1° Alice engendre un paire « clef privée-clef publique » et donne la clef publique à Bernard (mais pas à Christine). Alice engendre une autre paire « clef privée-clef publique » et donne la clef publique à Christine (mais pas à Bernard). 1. A lice doit donner à Bernard les facteurs d e n ou exécuter un p rotocole à divulgation nulle pou r le convaincre qu ’ il s’ agit bien d ’un entier de B lu m .
23.9
Divulgation tout ou rien de secrets
573
2° Bernard engendre k nombres aléatoires de n bits, B i, D2, ..., B k et les com munique à Christine. Christine engendre k nombres aléatoires de n bits, Ci, C 2 , ■■■, Ck et les com munique à Bernard.
3° Bernard chiffre Cb (rappelez-vous que Sb est le secret qu’il veut acheter) avec la clef publique d’Alice. Il calcule ZTBI de Cb et du résultat du chiffrement qu’il vient juste d ’effectuer. Il envoie cet IBI à Christine. Christine chiffre B c (rappelez-vous que Sc est le secret qu’elle veut acheter) avec la clef publique d’Alice. Elle calcule /TB [ de B c et du résultat du chiffrement qu’elle vient juste d’effectuer. Elle envoie cet IBI à Bernard.
4° Bernard prend chacun des nombres de n bits B lr B 2, ..., Bk et remplace chaque bit qui n’est pas dans ZTBI qu’il a reçu de Christine par son complément. Il envoie à Alice cette nouvelle liste de nombres de n bits B \ , B ' 2 , ■■■, B'kChristine prend chacun des nombres den bits C i, C2, ..., Ck et remplace chaque bit qui n’est pas dans ZTBI qu’elle a reçu de Bernard par son complément. Elle envoie à Alice cette nouvelle liste de nombres de n bits C 'i, C ' 2 , C'k-
5° Alice déchiffre tous les C'i avec sa clef privée associée à la clef publique qu’elle a donnée à Bernard, ce qui lui donne k nombres de n bits: C " C " 2, ..., C"kElle calcule Si © C "i pour i = 1 à k et envoie les résultats à Bernard. Alice déchiffre tous les B'i avec sa clef privée associée à la clef publique qu’elle a donnée à Christine, ce qui lui donne k nombres de n bits: B " 1 , B " 2 , B " k■ Elle calcule Si © B "i pour i — 1 à fc et envoie les résultats à Christine.
6° Bernard calcule Sb en combinant par ou exclusif Cb avec le be nombre qu’il a reçu d’Alice. Christine calcule Sc en combinant par ou exclusif B c avec le ce nombre qu’elle a reçu d’Alice.
C’est assez compliqué. Un exemple va clarifier tout ça. Alice a les 8 secrets suivants de 12 bits : Si = 1990, S2 = 471, S 3 = 3860, S 4 = 1487, S5 — 2235, S 6 = 3751, S 7 = 2546 et S8 = 4043. Bernard veut acheter S 7 et Christine veut acheter S2. 1° Alice utilise l’algorithme R SA . La paire de clefs qu’elle va utiliser avec Bernard est n = 7387, e = 5145 et d = 777. La paire de clefs qu’elle va utiliser avec Christine est n = 2747, e = 1421 et d = 2261. Elle donne à Bernard et à Christine leur clef publique respective.
2° Bernard engendre 8 nombres aléatoires de 12 bits: Bi = 743, B2 = 1988, £ 3 = 4001, S 4 = 2942, £ 5 = 3421, £ 6 = 2210, £ 7 = 2306 et £ 8 = 222 'et les communique à Christine. Christine engendre 8 nombres aléatoires de 12 bits: Ci — 1708, C 2 = 711, C 3 = 1969, C4 = 3112, C 5 = 4014, C 6 = 2308, C 7 = 2212 et C 8 = 222 et les communique à Bernard.
Chapitre 23
Algorithmes spéciaux pour protocoles
3° Bernard veut acheter S 7 et donc il chiffre C 7 avec la clef publique qu’Alice lui a donnée:
22125145 m o d 7387 = 5928. Maintenant :
2212 = OIOOOIOIOOIOO 5928 = 1011100101000. Et donc /I B I de ces deux nombres est {0,1,4,5,6}. E l’envoie à Christine. Christine veut acheter S2 , donc elle chiffre B 2 avec la clef publique qu’Alice lui a donnée et calcule l IB I de B 2 avec le résultat du chiffrement. Elle envoie {0,1, 2,6,9,10} à Bernard.
4° Bernard prend B\, B2, ..., Bg et remplace chaque bit dont l’indice n’est pas dans {0,1,2,6,9,10} par son complément. Par exemple : B 2 = 111111000100 = 1988 B '2 = 011001111100 = 1660. E envoie B \ , B '2, ..., B'g à Alice. Christine prend C i, C2, ..., Cg et remplace chaque bit dont l’indice n’est pas dans {0,1,4,5,6} par son complément. Par exemple: C 7 = OIOOOIOIOOIOO = 2212 C '7 = 1011100101000 = 5928. Elle envoie C \ , C '2, ..., C'g à Alice.
5° Alice déchiffre tous les C \ avec la clef privée associée à Bernard et combine les résultats par ou exclusif avec les S ,. Par exemple pour i = 7 : 5928777 m o d 7387 = 2212
; 2546 © 2212 = 342.
Elle envoie le résultat à Bernard. Alice déchiffre tous les B'i avec la clef privée associée à Christine et combine les résultats par ou exclusif avec les S ,. Par exemple pour i = 2 :
16602261 m o d 2747 = 1988
; 471 © 1988 = 1555.
Elle envoie le résultat à Christine.
6° Bernard calcule S7 en combinant par ou exclusif C 7 et le I e nombre qu’il a reçu d’Alice:
2212 © 342 = 2546. Christine calcule S 2 en combinant par ou exclusif B 2 et le 2e nombre qu’elle a reçu d’Alice:
1988 © 1555 = 471.
23.10
Cryptosystèmes équitables et à sûreté intégrée
575
Ce protocole marche pour n’importe quel nombre d ’acheteurs. Si Bernard, Christine et David veulent acheter des secrets, Alice donne à chaque acheteur deux clefs publiques, une pour chacun des deux autres. Chaque acheteur reçoit un ensemble de nombres de la part de chaque autre acheteur. Ensuite, ils terminent le protocole avec Alice pour chacun de leurs ensembles de nombres et ils combinent par ou exclusif tous les résultats fournis par Alice pour reconstruire leur secret. Plus de détails sont donnés dans [1376, 1181]. Malheureusement, un couple de participants malhonnêtes peut tricher. Alice et Christine, en s’alliant, peuvent facilement deviner le secret que Bernard est en train d’acheter: si elles connaissent l’IBI de Cb et l’algorithme de chiffrement de Bernard, elles peuvent trouver le b produisant le bon IBI. De plus, Bernard et Christine, en travaillant ensemble, peuvent facilement tous les secrets d ’Alice. Si vous supposez les participants honnêtes, voici un protocole plus facile [393] : 1° Alice chiffre tous les secrets avec R S A et les envoie à Bernard: Ci — Sf mod n.
2° Bernard choisit son secret Cb, tire un nombre aléatoire, et envoie à Alice : C — Cbre mod n.
3° Alice envoie à Bernard: AA' — C'd mod n.
4° Bernard calcule: Sb = A4V-1 inod n.
Si les participants risquent d’être malhonnêtes, Bernard peut faire une preuve à divul gation de sa connaissance d ’un nombre r tel que C' — Cbre mod n et garder b secret jusqu’à ce qu’Alice lui donne AA' à l’étape 3 [249].
23.10
Cryptosystèmes équitables et à sû reté intégrée
Diffie-Hellman équitable Les cryptosystèmes équitables permet de réaliser le dépôt de clefs en logiciel (voir § 4.14). Cet exemple est dû à Silvio M i c a l i [1091, 1090]. Il est breveté [1092, 1093]. Dans le schéma de base D i f f i e - H e l l m a n , un groupe d ’utilisateurs partage un nombre premier p et un générateur g. La clef privée d ’Alice est s et sa clef publique est t — gs mod p. Voici comment rendre D i f f i e - H e l l m a n équitable (cet exemple utilise 5 dépositaires) : 1° Alice choisit 5 nombres entiers S\, S2 , « 3 ,
«4
et .se, chacun inférieur à p. La
clef privée d’Alice est donnée par :
s = (si + s2 + s3 + 54 + Sb) m od p
Chapitre 23
576
Algorithmes spéciaux pour protocoles
et sa clef publique est: t = gs mod p. Alice calcule également:
t, = g s* mod p pour i = 1 à 5. Les parts publiques d’Alice sont les tt et les parts privées sont les s,.
2° Alice envoie une part privée et la part publique correspondante à chaque dépo sitaire. Par exemple, elle envoie Si et t\ au dépositaire n° 1. Elle envoie t au CDC. 3° Chaque dépositaire vérifie que: U = gSx mod p. Si tel est le cas, le dépositaire signe tt et envoie le résultat au C D C . Le dépo sitaire stocke st dans un endroit sûr.
4° Après avoir reçu les 5 parts publiques, le C D C vérifie que : t = (ti x t2 x t3 x t4 x t5) mod p. Si tel est le cas, le C D C approuve la clef publique.
À ce point, le C D C sait que chaque dépositaire a une part valide et qu’ils peuvent reconstruire la clef privée si nécessaire. Toutefois, ni le C D C , ni quatre des cinq dépo sitaires, travaillant ensemble, ne peuvent reconstruire la clef privée d ’Alice. L ’article de M icali [1091, 1090] contient également une procédure pour rendre le R S A équitable et pour combiner un schéma à seuil avec un cryptosystème équitable, tel que m dépositaires parmi n peuvent reconstruire la clef privée.
Diffie-Hellman à sûreté intégrée Tout comme dans le protocole précédent, un groupe d ’utilisateurs partage un nombre premier p et un générateur g. La clef privée d’Alice est s, sa clef publique est t = gs mod p. 1° Le C D C choisit un nombre aléatoire B entre 0 etp —2, et le met en gage selon un protocole de mise en gage (voir § 4-9). 2° Alice choisit un nombre aléatoire A entre 0 et p — 2. Elle envoie gA mod p au CDC. 3° Alice partage A entre les dépositaires en utilisant un schéma de secret réparti vérifiable (voir § 3.7). 4° Le C D C révèle B à Alice. 5 ° Alice vérifie la mise en gage de l’étape
1 . Elle prend alors pour clef publique :
t = gAgB mod p, et pour clef privée :
s = (A + B) m od (p — 1).
2S.11
Preuves à divulgation nulle
577
Les dépositaires peuvent reconstruire A. Comme le C D C connaît B , c’est assez pour reconstruire s. De plus, Alice ne peut se servir d’aucun canal subliminal pour envoyer des informations non autorisées. Ce protocole, qui est décrit dans [957, 834], est en cours de brevetage.
23.11
Preuves à divulgation nulle
Preuve à divulgation nulle de logarithmes discrets Patricia veut prouver à Victor qu’elle connaît un x qui satisfait : Ax = B
(mod p)
où p est un nombre premier et x est premier par rapport à p — 1. Les nombres A, B et p sont publics, et x est secret. Voici comment Patricia peut prouver qu’elle connaît x sans le révéler (voir § 5.1) [343, 342] : 1° Patricia engendre t nombres aléatoires r i ,r 2 , ..., rt où tous les r, sont inférieurs àp — 1 . 2° Patricia calcule hi = Ar’ mod p pour toutes les valeurs de i et envoie ceux-ci à Victor. 3° Patricia et Victor exécutent un protocole de jeu à pile ou face pour engendrer t bits : bi , 6 2 ,..., ht4° Pour tous les t bits, Patricia exécute l ’une des actions : a . si bi =
0, Patricia envoie ri à Victor ;
h. si bi = 1, Patricia envoie à Victor Si plus petite valeur telle que bj — 1.
=
(r*
—rf) mod (p —1),
5 ° Pour tous les t bits, Victor vérifie l’une des deux relations:
a. si bi — 0, il vérifie que A r' = hi
(mod p) ;
b .si bi = 1, il vérifie que A 3* = h^hj1
(mod p).
6° Patricia envoie Z à Victor, où : Z = (x — rj) mod (p — 1).
7° Victor vérifie que : A z = BhJ 1
(mod p).
La probabilité que Patricia puisse tricher est de 2 ~l.
où j est la
Chapitre 23
578
Algorithmes spéciaux pour protocoles
Preuve à divulgation nulle de la capacité à casser le RSA Alice connaît la clef privée de Christine. Peut-être a-t-elle cassé le R S A ; peut-être a-t-elle pénétré par effraction dans la maison de Christine pour voler la clef. Alice veut convaincre Bernard qu’elle connaît la clef de Christine. Toutefois, elle ne veut pas dire à Bernard la valeur de cette clef, ni même déchiffrer un des messages de Christine pour Bernard. Voici un protocole de preuve à divulgation nulle par lequel Alice peut convaincre Bernard qu’elle connaît la clef privée de Christine [888]. La clef publique de Christine est e. Sa clef privée est d. Le module R SA est n. 1° Alice et Bernard se mettent d’accord sur une paire aléatoire k et m telle que: km = e
(mod n).
Il doivent choisir les nombres aléatoirement, en utilisant un protocole de jeu à pile ou face pour engendrer k et ensuite calculer m. Si k et m sont tous deux plus grands que 3, le protocole continue. Sinon, il faut faire un nouveau choix.
2° Alice et Bernard engendrent un texte chiffré aléatoire C. Une fois de plus ils doivent utiliser un protocole de jeu à pile ou face.
3° Alice, en utilisant la clef privée de Christine, calcule : A i — Cd mod n. Ensuite elle calcule: X = Adk mod n et envoie X à Bernard.
4° Bernard vérifie que X rn mod n — C. Si tel est le cas, il croit Alice. Un protocole similaire peut être utilisé pour démontrer la capacité à casser le problème du logarithme discret [502].
Preuve à divulgation nulle que n est un entier de B l u m Il n’existe aucune preuve à divulgation nulle vraiment pratique de n = pq avec p et q premiers et congrus à 3 modulo 4. Mais si vous tolérez que n soit de la forme pTqs, où r et s sont impairs, alors les propriétés qui rendent les entiers de B l u m intéressants en cryptographie tiennent toujours, et il existe une preuve à divulgation que n est de cette forme. Supposez qu’Alice connaisse la factorisation d’un tel entier n. Voici comment ellepeut prouver à Bernard que n est de cette forme [1561]. 1° Alice envoie à Bernard un nombre dont le symbole de Jacobi vaut —1 modulo n. 2° Alice et Bernard se mettent d’accord sur des bits aléatoires: b\J>2 , . . . ,bk3° Ahœ et Bernard se mettent d’accord sur des nombres aléatoires: Xi,X2 , ■■■,Xk4° Pour tout i entre 1 et k, Alice envoie à Bernard la racine carrée modulo n d’un des quatres nombres suivants: x t, —Xi, uxi, —uxi. Le symbole de Jacobi de la racine carrée doit valoir bi.
Alice a une chance sur 2fe de réussir à tricher.
23.12
579
Signatures en aveugle
23.12
Signatures en aveugle
La notion de signatures en aveugle (voir § 5.3) a été inventée par David C h a u m [322] qui a également inventé leur première réalisation [322]. Il utilise l’algorithme R SA . Bernard a une clef publique e, une clef privée d et un module public n. Alice veut que Bernard signe un message m en aveugle. 1° Alice choisit une valeur aléatoire k comprise entre 1 et n. Ensuite elle camoufle m en calculant: t = mke mod n.
2° Bernard signe t : td -- (mke)d mod n. 3° Alice retire le facteur de camouflage de td en calculant : s = td/k mod n.
4° Et le résultat est: s = m d mod n. Cela peut être aisément montré grâce à : td = ( mke)d = m dk {mod n), et donc — = m d x — ~ md k k
(m od n).
C h a u m a inventé une fam ille d ’algorithm es de signatures en aveugle plus com pliqués dans
[326, 325]. Ces signatures sont plus com pliquées à construire, m ais elles sont plus
maléables.
23.13
Transfert inconscient
Dans ce protocole, dû à R a b i n [1298], Alice a 50 % de chances d’envoyer à Bernard deux nombres premiers p et q. Alice ne saura pas si le transfert a réussi ou non (voir § 5 .5 ) 2.
1° Alice envoie à Bernard le produit des deux nombres premiers : n = pq. 2° Bernard choisit un nombre aléatoire x inférieur à n tel que x soit premier par rapport à n. Il envoie à Alice : a = x 2 m o d n.
3° Alice qui connaît p et q, calcule les quatre racines de a : x, n — x, y et n — y. Elle choisit l’une de ces racines aléatoirement et l’envoie à Bernard.
4° Si Bernard reçoit y ou n — y, il peut calculer le plus grand commun diviseur de x + y et n qui est soit p soit q. Ensuite, bien sûr n /p = q . Si Bernard reçoit x ou n — x , il ne peut rien calculer. 2. Ce protocole peut servir à envoyer avec 50 une clef privée RSA.
% de chances n’importe quel message, si p et q révèlent
Chapitre 23
580
Algorithmes spéciaux pour protocoles
Ce protocole présente éventuellement une faiblesse : il se peut que Bernard puisse cal culer un nombre a tel qu’une racine carrée de a permette de factoriser n dans tous les cas.
23.14
Calcul réparti sûr
Le protocole suivant est décrit dans [1375]. Alice connaît un entier i ; Bernard connaît l’entier j . Alice et Bernard, ensemble, veulent savoir si i < j ou si i > j , mais ni Alice ni Bernard ne veulent révéler leur entier à l’autre. Ce cas spécial de calcul réparti sûr (voir § 6.2) est parfois connu sous le nom de p ro b lè m e d u m illionnaire d e Y ao [1629], Pour cet exemple, faites l’hypothèse que i et j sont compris dans l’intervalle de 1 à 100. Bernard a une clef publique et une clef privée. 1° Alice choisit un grand nombre aléatoire x et le chiffre avec la clef publique de Bernard : c
=
E
b
{x
).
2° Alice calcule c — i et envoie le résultat à Bernard. 3° Bernard calcule les 100 nombres suivants: Vu — D b (c — i + u), pour 1 < u < 100. D b est l’algorithme de déchiffrement avec la clef privée de Bernard. Il choisit un grand nombre premier3 p. Il calcule ensuite les 100 nombres sui vants : zu = (yu mod p), pour 1 < u < 100. Il vérifie ensuite que pour tout u / v :
I zu
zv | ^ 2
et pour tout u :
0 < zu < p - 1. Si ce n’est pas vrai, Bernard choisit un autre nombre premier et essaie à nou veau.
4° Bernard envoie à Alice la suite de nombres dans l’ordre exact suivant: Zi, Z2 ,
Zj,Zj+1 + 1, Zj+ 2 + 1, .-.,ZlOO + l ,p
5° Alice vérifie si le i e nombre de la suite est congru à x modulo p. Si tel est le cas, elle conclut que i < j , sinon elle conclut que i > j .
6° Alice indique sa conclusion à Bernard. 3. La taille de p doit être un petit peu plus petite que celle de Alice peut facilement lui indiquer sa taille.
x. Bernard ne connaît pas x mais
23.14
581
Calcul réparti sûr
Toutes les vérifications que Bernard doit effectuer à l’étape 3 servent à garantir qu’au cun nombre n’apparaisse deux fois dans la suite engendrée à l’étape 4. Sinon, si za = Zb, Alice saurait que a < j < b . Le défaut de ce protocole est qu’Alice apprend le résultat du calcul avant que Bernard ne l’apprenne. Rien ne l’empêche de compléter le protocole jusqu’à l’étape 5 et d’ensuite refuser de dire le résultat à Bernard à l’étape 6. Elle peut même mentir à Bernard à l’étape 6.
Exemple du protocole Faites l’hypothèse que le R SA est l’algorithme à clef publique utilisé. La clef publique de Bernard est 7 et sa clef privée est 23 ; n = 55. La valeur secrète i d ’Alice vaut 4 ; la valeur secrète j de Bernard4 vaut 2. 39et c
E B(3 9)= 19.
1°
Alice choisit x
2°
Alice calcule r — i = 19 — 4 = 15.Elle envoie 15 à Bernard.
=
=
3° Bernard calcule les 4 nombres suivants : tn = D b { 15 + jb = £>s(15 + y3 = £ » s (15 + y4 = D B(15 +
1) 2) 3) 4)
= = = =
26 18 2 39.
Il choisit un grand p = 31 et calcule : zi z2 Z3 Z4
= 26 mod 31 = 26 = 18 mod 31 = 18 = 2 mod 31 = 2 = 39 mod 31 — 8.
Il fait toutes les vérifications et confirme que la suite est correcte.
4° Bernard envoie à Alice la suite de nombres suivante dans l’ordre exact: 26,18,2 + 1,8 +- 1,31 = 26,18,3,9,31. 5° Alice vérifie si le 4e nombre de la suite est congru à x modulo p Comme 9 ^ 39 (mod 31), alors i > j . 6° Alice indique le résultat à Bernard. Ce protocole peut servir à construire des protocoles bien plus compliqués. Un groupe de gens peut effectuer une vente aux enchères secrète sur un réseau d’ordinateurs. Ils instaurent un anneau logique entre eux, et déterminent grâce à des comparaisons deux à deux celui qui offre le plus haut prix. Pour empêcher les gens de changer leur offre au milieu des enchères, une sorte de protocole de mise en gage peut être utilisée. S’il s’agit d’enchères au rabais, celui qui a fait la meilleure offre remporte l’objet pour ce prix. S’il s’agit d ’enchères à l’anglaise, alors il remporte l’objet pour le deuxième prix le plus élévé5. Des idées similaires s’appliquent aux marchandages, aux négociations et à l’arbitrage. 4. Faites l’ hypothèse que seules les valeurs 1, 2, 3 et 4 sont possibles pou r i et j . 5. C eci peut être déterminer par une seconde ronde de com paraisons deux à deux.
582
Chapitre 23
23.15
Algorithmes spéciaux pour protocoles
Chiffrement probabiliste
La notion de c h if f r e m e n t p r o b a b i lis t e a été inventée par Shafi G o l d w a s s e r et Silvio MlCALi [626]. Bien que la théorie fasse de ce cryptosystème le plus sûr que l’on ait inventé, sa première réalisation n’était pas pratique [627]. La plupart des réalisations récentes ont changé cela. L’objet du chiffrement probabiliste est d ’éliminer la dernière petite fuite d’information qui peut se produire grâce à la cryptographie à clef publique. Comme les cryptanalystes peuvent toujours chiffrer des messages aléatoires avec la clef publique, ils peuvent obtenir de l’information. En faisant l’hypothèse qu’ils ont le texte chiffré C = E k (.M) et qu’ils essaient de retrouver le texte en clair A4, ils peuvent choisir un message au hasard A4', le chiffrer: C' — E k (AA'). Si C = C, alors ils ont deviné le bon texte en clair. Si l’égalité n’est pas vérifiée, ils n’ont qu’à parier à nouveau. De plus, il n’y a pas d ’information partielle concernant le message original qui transpire. Avec la cryptographie à clef publique, les cryptanalystes peuvent parfois apprendre certaines choses concernant les bits : « le ou exclusif des bits 5, 17 et 39 est 1 », etc. Avec le chiffrement probabiliste, même ce type d ’information demeure caché. Cela n’apporte pas beaucoup d ’information, mais il y a des problèmes potentiels à per mettre aux cryptanalystes de chiffrer des messages aléatoires avec votre clef publique. Quelques informations peuvent fuir vers les cryptanalystes chaque fois qu’ils chiffrent un message. Personne ne sait vraiment combien. Le chiffrement probabiliste essaie d ’éliminer cette fuite d’information. Le but est qu’au cun calcul sur le texte chiffré ou qu’aucun autre texte en clair d’essai, ne donne au cryptanalyste la moindre information concernant le texte en clair correspondant. Dans le cadre du chiffrement probabiliste, l’algorithme de chiffrement est probabiliste plutôt que déterministe. En d’autres termes, il existe un grand nombre de textes chiffrés qui correspondent à un texte en clair donné, et ce texte chiffré particulier utilisé dans n’importe quel chiffrement est choisi aléatoirement. Tous ces textes chiffrés donnent au déchiffrement le même texte en clair. Ci
= E k (A 4 ),C 2 = E k(A 4),C s = E j i ( A 4 ) , ..., C t - Ek{A 4)
A4 = D k (Ci ) , M = D k {C2), A4 = D K (C3), ...,M = D K (Ct)
Avec le chiffrement probabiliste, les cryptanalystes ne peuvent plus chiffrer des textes en clair aléatoires pour trouver le bon. Pour illustrer, faites l’hypothèse que les crypta nalystes ont le texte chiffré Ct = E k (AA). Même s’ils devinent A4 correctement, quand ils calculent E k (A4), le résultat sera un C complètement différent: C3. Ils ne peuvent pas comparer Ct et Cj donc ils ne peuvent pas savoir s’ils ont deviné correctement le texte en clair. C’est quelque chose d ’étonnamment séduisant. Même si les cryptanalystes ont à la fois la clef publique de chiffrement, le texte en clair et le texte chiffré, ils ne peuvent pas prouver que le texte chiffré est bien le chiffrement du texte en clair sans disposer de la clef privée de déchiffrement. Même s’ils essaient une recherche exhaustive, ils ne peuvent que prouver que tout texte en clair concevable est un texte en clair possible. En utilisant ce type de schéma, le texte chiffré sera toujours plus long que le texte en clair. Vous ne pouvez pas l’éviter ; c ’est le résultat du fait que plusieurs textes chiffrés correspondent à un seul et même texte en clair. Le premier schéma de chiffrement
23.15
Chiffrement probabiliste
583
probabiliste [627] donnait un texte chiffré tellement plus long que le texte en clair qu’il n’était pas utilisable en pratique. Toutefois, il existe une réalisation efficace du chiffrement probabiliste due à Manuel B l u m et Shafî G o l d w a s s e r , utilisant le générateur de bits aléatoires B l u m B l u m S h u b (B B S) décrit dans le paragraphe 17.9 [205]. Le générateur BBS est basé sur la théorie des résidus quadratiques. En termes simples, il y a deux nombres premiers p et q qui sont congrus à 3 modulo 4. C ’est la clef privée. Leur produit p x q = n constitue la clef publique6. Pour chiffrer un message A i, choisissez d’abord un x aléatoire, premier par rapport à n. Ensuite calculez : xo = x 2 mod n. Utilisez xo comme germe pour le générateur pseudo-aléatoire de bits BBS et combinez Ai par ou exclusif 1 bit à la fois avec la sortie du générateur. Le générateur produit des bits bi (le bit de poids faible de X » , où X j — X i _ i mod n ) , et on a : M = A i i ,M 2 ,A i 3 ,—, M t C = A ii © b i,A i 2 © b2 ,A iz © 83, ...,A it ffi bt où t est la longueur du texte en clair.
Joignez la dernière valeur calculée x< à la fin du message et vous avez fini. Le seul moyen de déchiffrer le message est de retrouver x 0 et ensuite de mettre en place le même générateur BBS pour le combiner par ou exclusif avec le texte chiffré. Comme le générateur BBS est sûr à gauche, la valeur de x t n’est d ’aucune utilité pour le cryptanalyste. Seul quelqu’un qui connaît p et q peut déchiffrer le message. L’algorithme en C pour retrouver xo à partir de x t est donné par : /*
modexp (x , y , z ) é lè v e x
à la puissance y modulo z .
in t xO ( i n t p , in t q , in t n , in t t , f in t a, b , u, v , w, z ;
*/
in t x t)
/ * on s a it d é jà que p g cd (p , q) == 1 * / (v o id )e u clid e _ e te n d u (p , q , &a, &b) ; u = modexp ( ( p + l ) /4 , t , p - 1 ) ; v = modexp ( ( q + l ) / 4 , t , q - 1 ) ; w = modexp ( x t % p , u , p ) ; z = modexp ( xt % q , v , q ) ; retu rn (b*q*w + a*p*z) % n; > Une fois que vous avez Xo, le déchiffrement est facile. Mettez en place un générateur BBS et combinez par ou exclusif sa sortie avec le texte chiffré. Vous pouvez rendre ce schéma encore plus rapide en utilisant tous les bits sûrs de x,, pas seulement le bit de poids faible. En utilisant cette amélioration, le chiffrement probabiliste B l u m - G o l d w a s s e r est plus rapide que le R S A et il empêche la fuite de 6. Faites attention à vos p et ç, car la sécurité de ce schém a dépend de la difficulté de factoriser n .
584
Chapitre 23
Algorithmes spéciaux pour protocoles
toute information partielle concernant le texte en clair. Vous pouvez également prouver que la difficulté de casser ce schéma est la même que la difficulté de factoriser n. Cependant, ce schéma n ’est pas sûr du tout contre une attaque à texte chiffré choisi. A partir du bit le moins significatif des bons résidus quadratiques, il est possible de calculer la racine carrée de n’importe quel résidu quadratique. Si vous le pouvez, alors vous pouvez factoriser. Pour les détails consultez [1572, 1573, 36, 37].
23.16
Cryptographie quantique
La cryptographie quantique prend sa source à l’incertitude naturelle du monde quan tique. Grâce à elle, vous pouvez créer des canaux de communication qu’il est impossible d ’espionner sans perturber la transmission. Les lois de la physique garantissent la sé curité de ce canal — même si les espions peuvent faire ce qu’ils veulent, même s’ils disposent d ’une puissance de calcul illimitée, même si P = N P . Charles B e n n e t t et Gilles B r a s s a r d ont poussé cette idée aussi loin qu’ils ont pu, en décrivant une distribution de clefs quantique, le jeu à pile ou face quantique, la mise en gage de bits quantiques. Leurs travaux sont décrits dans [138, 139, 133, 135, 134, 143, 136, 398, 144, 396, 247, 519, 142, 140, 248, 397, 400]. Le meilleur aperçu de la cryptographie quantique est donné par [141] ; [1653] est un bon survol vulgarisé. Une bibliographie complète de cryptographie quantique est donnée dans [241]. Cela aurait pu rester à la frontière doucement délirante de la cryptographie, mais B e n n e t t et B r a s s a r d l’ont sérieusement développé et ils ont construit un prototype qui fonctionne [137, 131, 132], Maintenant, nous avons la cryptographie quantique expérimentale.
Asseyez-vous, prenez quelque chose à boire et détendez-vous. Je vais vous expliquer de quoi il s’agit. D ’après la mécanique quantique, les particules ne sont pas localisées. Elles sont en plusieurs endroits à la fois avec des probabilités d’être en ces différents endroits si quelqu’un les cherche. Toutefois, ce n ’est pas avant que le scientifique arrive et qu’il mesure la particule que celle-ci « s’effondre » en un seul endroit. Mais vous ne pouvez pas mesurer tous les aspects d’une particule en même temps : la position et la vitesse, par exemple. Si vous mesurez l’une de ces deux quantités, l’acte même de la mesure détruit toute possibilité de mesurer l’autre quantité. Il y une incertitude fondamentale dans le monde quantique, et il n’y a pas moyen de l’éviter. Cette incertitude peut être utilisée pour engendrer une clef secrète Les photons vibrent pendant leur déplacement. Cette vibration a une certaine direction : de haut en bas, de gauche à droite ou, plus probablement, suivant un certain angle. La lumière solaire normale n ’est pas polarisée : les photons vibrent dans toutes les directions possibles. Quand un grand groupe de photons vibrent tous dans la même direction, ils sont p o larisés. Les filtres à polarisation ne laissent passer que les photons qui sont polarisés dans une certaine direction ; ils arrêtent tout le reste. Par exemple, un filtre à polarisa tion horizontale ne laissera passer que les photons polarisés horizontalement. Tournez le filtre de 90° et seuls les photons polarisés verticalement passeront. Faisons l’hypothèse que vous avez une impulsion de photons polarisés horizontalement. S’ils essaient de traverser un filtre à polarisation horizontale, ils passent tous. Tournez lentement ce filtre vers la position à 90° ; le nombre de photons qui passent devient de plus en plus petit, jusqu’à ce qu’il n’y en ait plus un seul qui passe. C ’est contraire à
23.16
Cryptographie quantique
585
l’intuition. Vous vous attendriez à ce que tourner le filtre ne serait-ce qu’un petit peu bloque tous les photons, puisqu’ils sont polarisés horizontalement. Ce raisonnement serait sensé dans notre monde, mais il ne l’est pas dans celui de la mécanique quantique. Chaque particule a une probabilité de changer brusquement sa polarisation pour être en accord avec l’orientation du filtre. Si l’angle est un petit peu diflérent, il y a une bonne probabilité. Si l’angle est de 90°, la probabilité est 0. Si l’angle est de 45°, la probabilité est de 50 %. La polarisation peut être mesurée dans n’importe quelle base : deux axes à angle droit. Par exemple, la base rectiligne est composée des axes horizontal et vertical, la base diagonale des deux diagonales. Si une impulsion de photon est polarisée et si vous la mesurez dans la même base, vous apprenez quelle est la polarisation. Si vous la mesurez dans une mauvaise base, vous obtenez un résultat aléatoire. Nous allons utiliser cette propriété pour engendrer la clef secrète : 1° Alice envoie à Bernard un train d’impulsions de photons polarisés. Chaque im pulsion est polarisée aléatoirement dans une des quatre directions : horizontale ( ~ ) , verticale ( I ), oblique à gauche ( ^ ) , oblique à droite ( ^ )■ Par exemple, Alice envoie à Bernard: J
J
/
------- \
"
t
~
/
2° Bernard a un détecteur de polarisation. Il peut positionner ce détecteur pour mesurer des polarisations verticales et horizontales & ) ou peut le positionner pour mesurer des polarisations obliques ( X / / ne peut, pas faire les deux; la mécanique quantique ne le laisserait pas faire. Mesurer une direction de polarisation détruit toute possibilité de mesurer l’autre. Il positionne donc son détecteur aléatoirement, par exemple :
x-l*'fxxx + x-f-f À partir de là, quand Bernard positionne son détecteur correctement, il enre gistre la bonne réponse. S ’il positionne son détecteur pour mesurer une pola risation verticale ou horizontale et que l’impulsion est polarisée soit horizon talement soit verticalement, il apprendra de quelle façon Alice a polarisé cette impulsion. S ’il positionne mal son détecteur, il obtiendra un résultat aléatoire. Il ne pourra pas distinguer les cas où il a le bon résultat de ceux pour lesquels il obtient un résultat aléatoire. Dans cet exemple, il pourrait obtenir le résultat :
y 1—
\
\
—
1
3° Bernard indique à Alice, par un canal de communication non sûr, quels posi tionnements il a utilisés.
4° Alice indique à Bernard quels sont les positionnements corrects. Dans notre exemple, le détecteur était correctement positionné pour les impulsions 2, 6, 7 et 9.
Chapitre 23
586
Algorithmes spéciaux pour protocoles
5° Alice et Bernard gardent uniquement les valeurs de polarisations correctement mesurées. Dans notre exemple, ils gardent:
*
1& & & / — & ~ &
En utilisant un code convenu au préalable, de leur côté ces polarisations en bits. Par à droite » pourraient représenter 1, et « pourraient représenter D. Dans le contexte
Alice et Bernard, traduisent chacun exemple, « horizontal » et « oblique vertical » et « oblique à gauche » de notre exemple, ils ont tous deux:
0 0 11.
Ainsi, Alice et Bernard ont engendré 4 bits. Ils peuvent en engendrer autant qu’ils veulent en utilisant ce système. En moyenne, Bernard devinera le bon positionnement dans 50 % des cas et Alice devra donc envoyer 2 x n photons pour engendrer n bits. Ils peuvent utiliser ces bits comme clef secrète pour un algorithme cryptographique conventionnel, ou bien ils peuvent se garantir une confidentialité absolue en engendrant suffisamment de bits pour un masque jetable. S’ils utilisent ce système, Estelle ne peut pas les espionner. Si elle essaie de détecter les impulsions quand elles passent, Bernard le détectera. Son seul espoir est de capturer et mesurer les impulsions et ensuite d ’essayer d’envoyer des impulsions identiques à Bernard. Mais tout comme Bernard, elle doit deviner quel type de polarisation mesurer ; et tout comme Bernard, elle se trompera en moyenne une fois sur deux. Elle ne peut pas éviter d ’envoyer des impulsions erronées à Bernard. Si Estelle fait cela, Alice et Bernard auront des chaînes de bits différentes. C’est pour quoi ils terminent le protocole de la manière suivante : 6° Alice et Bernard comparent quelques bits de leurs chaînes. S ’il y a des dis cordances, ils savent qu’une oreille indiscrète pollue la ligne. S ’il n’y a pas de discordances, ils jettent les bits utilisés pour la comparaison et utilisent ceux qui restent.
Il existe des améliorations de ce protocole qui permettent à Alice et Bernard d’utiliser leurs bits même si Estelle écoute [143,144,199]. Ils pourraient ne comparer que la parité de certains sous-ensembles de bits. S’il n’y a aucune discordance, ils n’ont besoin de jeter qu’un bit par sous-ensemble. Cela permet de détecter les écoutes avec une prababilité de 50 % seulement, mais s’ils le font avec n sous-ensemble, Estelle n’a qu’une chance sur 2” d’écouter la ligne sans se faire détecter. Il n’y a rien qui puisse ressembler à l’écoute passive dans le monde quantique. Si Estelle essaye de récupérer tous les bits, elle perturbera forcément les communications. B e n n e t t et B r a s s a r d ont un prototype qui fonctionne. La dernière fois que j ’en ai entendu parlé, des gens de B r i t i s h T e l e c o m transmettaient des bits sur un lien en fibre optique de 10 kilomètres de long [280, 1255, 1541]. On croit rêver!
Quatrième partie Le monde réel
Chapitre 24
Exemples de réalisation Concevoir des protocoles et des algorithmes est une chose, mais les réaliser dans des systèmes opérationnels en est une autre. En théorie, la théorie et la pratique sont identiques ; en pratique, elles sont différentes. Souvent des idées intéressantes sur papier ne marchent pas dans la pratique. Les exigences sont peut-être trop restrictives ; le protocole est peut-être trop lent. Le chapitre 10 traite de quelques débouchés relatifs à l’utilisation de la cryptographie ; ce chapitre donne des exemples pratiques de ce qui se fait.
24.1
Protocole IBM de gestion de clefs se crètes
A la fin des années 70, IBM a conçu un système complet de gestion de clefs pour la sécurité des communications et des fichiers dans un réseau informatique, qui n’utilise que la cryptographie à clef secrète [517, 1032]. Ce protocole est moins important au niveau de son fonctionnement qu’au niveau de sa philosophie générale : En automatisant la génération, la distribution, l’installation, le stockage, le changement et la destruction des clefs, le protocole a beaucoup progressé pour assurer la sécurité des algorithmes cryptographiques sous-jacents. Ce protocole procure trois choses: communications sûres entre un serveur et divers terminaux, stockage sûr de fichiers sur le serveur et communications sûres entre les serveurs. Ce protocole n ’offre pas vraiment la possibilité de communications directes de terminal à terminal bien qu’il puisse être modifié dans ce but. Chaque serveur dans le réseau est raccordé à un dispositif cryptographique qui réalise tous les chiffrements et les déchiffrements. Chaque serveur a une clef maîtresse KMo et deux variantes K M i et K M 2 , toutes deux sont des variantes simples de KMo- Ces clefs sont utilisées pour chiffrer d ’autres clefs et pour engendrer de nouvelles clefs. Chaque terminal a une clef terminal maîtresse K M T qui est utilisée pour échanger des clefs avec d ’autres terminaux. Le serveur stocke K M T chiffré avec K M i. Toutes les autres clefs, dont celles utilisées pour chiffrer les fichiers de clefs (appelés K N F ), sont stockées chiffrées avec K M 2. La clef maîtresse K M 0 est stockée dans un module de sécurité sans fuite. Actuellement, ce
Chapitre 24
590
Exemples de réalisation
pourrait être une clef R O M ou une carte magnétique, ou bien une entrée dactylogra phiée par l’utilisateur (probablement sous forme d’un texte qui serait ensuite « broyé » pour obtenir une clef). K M j et K M 2 ne sont stockées nulle part dans le système, mais elles sont calculées à partir de KM o chaque fois qu’elles sont nécessaires. Les clefs de session, pour les communications entre serveurs, sont engendrées par un pro cessus pseudo-aléatoire par le serveur. Les clefs utilisées pour chiffrer les fichiers pour archivage (K N F ) sont engendrées de la même manière. Le cœur du protocole est un module résistant à l’investigation appelé mécanisme cryptographique. Du côté du serveur comme du côté du terminal, tous les chiffre ments et les déchiffrements sont réalisés par ce mécanisme cryptographique. Les clefs les plus importantes, celles qui sont utilisées pour engendrer les clefs de chiffrement, sont stockées dans ce module. Ces clefs ne peuvent jamais être lues une fois qu’elles sont stockées. Et elles sont liées à une utilisation : une clef affectée à une tâche ne peut pas être accidentellement utilisée pour autre chose. Ce concept de vecteurs de contrôle de clefs est probablement la contribution la plus significative de ce système. Donald D a v i e s et William P r i c e décrivent en détail ce protocole de gestion de clefs [435],
Une variante Une variante de ce schéma avec clefs maîtresses et clefs de session est décrite dans [1485]. Il est construit autour des nœuds du réseau avec des mécanismes de dépôt de clefs qui peuvent desservir des terminaux. Il est conçu pour : protéger les communications entre n’importe quelle paire d’utilisateurs à des ter minaux ; - protéger les communications à l’aide de courrier électronique chiffré ; - protéger des fichiers personnels ; - permettre de réaliser des signatures numériques. Pour les communications et les transferts de fichiers entre utilisateurs, le schéma utilise des clefs engendrées par le mécanisme de dépôt et envoyées aux utilisateurs chiffrées avec une clef maîtresse. L’identité des utilisateurs est incorporée à la clef pour qu’il soit possible de prouver qu’une clef de session a été utilisée par une paire particulière d’utilisateurs. Ce mécanisme de dépôt de clefs est central à tout le système. Bien que ce système n’utilise pas la cryptographie à clef publique, il offre des possibilités de signature numérique : une clef ne peut être originaire que d’une seule source et elle ne peut être lue que par un seul destinataire donné.
24.2
M ITRENET
L’une des premières réalisations de la cryptographie à clef publique était le système ex périmental M E M O (pour « M ITRE Encrypted Mail Office »). M IT R E est un contrac tant du Département de la Défense américaine — un groupe de réflexion gouverne mental et un ensemble de personnes intelligentes. M E M O était un système de courrier
24-3
R N IS
591
électronique sûr destiné aux utilisateurs du réseau M IT R E N E T , utilisant la cryp tographie à clef publique pour l’échange des clefs et le DES pour le chiffrement des fichiers. Dans le système M E M O , toutes les clefs publiques sont stockées dans un « centre de distribution de clefs publiques », qui forme un nœud à part du réseau. Elles sont stockées dans une E P R O M , pour éviter que quiconque ne les modifie. Les clefs privées sont engendrées par les utilisateurs ou par le système. Pour qu’un utilisateur puisse envoyer des messages en toute sécurité, le système établit en premier lieu un lien de communication sûr avec le « centre de distribution de clefs publiques ». L’utilisateur demande un fichier avec toutes les clefs publiques auprès du « centre ». Si l’utilisateur réussit un test d ’identification en utilisant sa clef privée individuelle, le « centre » envoie cette liste à sa station de travail. Cette liste est chiffrée à l’aide du DES pour garantir l’intégrité du fichier. Le processus utilise le DES pour chiffrer les messages. Le système engendre une clef DES aléatoire pour le chiffrement des fichiers ; l’utilisateur chiffre le fichier avec cette clef DES et il chiffre la clef DES avec la clef publique du destinataire. Le fichier chiffré par le DES et la clef chiffrée par la clef publique sont tous deux envoyés au destinataire. M EM O tient compte du problème de la perte des clefs. Il tient également compte de la vérification de l’intégrité des messages en utilisant des sommes de contrôles. Il n’y a pas de mécanisme d’authentification inclus dans le système. On a montré que la réalisation particulière de cryptographie à clef publique utilisée dans ce système — l’échange de clef D i f f i e - H e l l m a n basé sur Z j 2127 — n’était pas sûre avant même que le système ne soit réalisé (voir § 11.6), bien qu’il soit facile de modifier le système pour utiliser des nombres plus grands. M E M O était destiné principalement à des fins expérimentales et n ’a jamais été rendu opérationnel sur le vrai système M IT R E N E T .
24.3
RNIS
R e s e a r c h a développé un prototype de téléphone terminal RNIS sûr (pour « Réseau numérique à intégration de services » *) [497, 1201, 491, 498]2. La version téléphone n’a pas dépassé le stade de prototype. Le produit final était le Paquet de sécurisation des données (« Packet Data Security Overlay »). Le terminal utilise l’échange de clefs D i f f i e H e l l m a n , les signatures numériques R SA et le chiffrement des données par le DES ; il peut recevoir et émettre la voix et les données à 64 kilo-bits par seconde. B e ll-N o r th e r n
Clefs Une paire « clef publique-clef privée » à long terme est incorporée dans le téléphone. La clef privée est stockée dans une zone du téléphone résistante à l’investigation. La clef publique est utilisée comme identification du téléphone. Ces clefs font partie du téléphone et ne peuvent être altérées en aucune façon. De plus, deux autres clefs publiques sont stockées dans le téléphone. L’une de ces clefs est la clef publique du propriétaire, qui est utilisée pour authentifier les commandes 1. N ote du traducteu r: en anglais on parlera d ’ ISDN p ou r « In teg ra ted S e r v ic e s D ig ita l N etw o rk ». 2. N ote d u traducteur : il est com m ercialisé en France sous le n om de NUMERIS.
Chapitre 24
592
Exemples de réalisation
faites par le propriétaire et peut être changée par une commande signée par le proprié taire. De cette façon, un propriétaire peut céder son téléphone à quelqu’un d’autre. La clef publique du réseau est aussi stockée dans le téléphone. Cette clef est utilisée pour authentifier les commandes envoyées par le dispositif de gestion de clefs du réseau et pour authentifier les appels des utilisateurs sur le réseau. Cette clef peut également être changée par une commande signée par le propriétaire. Cela permet au propriétaire de faire passer son téléphone d’un réseau à un autre. Ces clefs sont considérées comme des clefs à long terme : elles ne sont changées que rarement, ou même jamais. Une paire « clef privée-clef publique » à court terme est aussi stockée dans le téléphone. Cette paire est encapsulée dans un certificat signé par le dispositif de gestion des clefs. Quand deux téléphones établissent une communication, ils échangent leurs certificats. La clef publique du réseau authentifie ces certificats. Cette procédure d’échange et vérification de certificats ne permet que l’établissement d’une communication sûre de poste à poste. Pour établir une communication sûre de personne à personne, le protocole a une étape supplémentaire. La clef privée du proprié taire est stockée dans une « clef matérielle d ’amorce » qui est insérée par le propriétaire dans le téléphone. Cette clef d’amorce contient la clef privée du propriétaire, chiffrée à l’aide d ’un mot de passe connu de lui seul (et non par le téléphone, ni par le dispositif de gestion des clefs du réseau, ni quiconque autre). Elle contient également un certi ficat signé par le dispositif de gestion des clefs du réseau ; ce certificat contient la clef publique du propriétaire et certaines informations le concernant (nom, société, profes sion, niveau d’accès à l’information confidentielle, garniture favorite de pizzas, tendance sexuelle, etc.). Ce certificat est également chiffré. Pour déchiffrer ces informations et les entrer dans le téléphone, le propriétaire entre son mot de passe secret à l’aide du clavier du téléphone. Après que le téléphone a utilisé les informations pour établir la communication, il les efface une fois que le propriétaire a retiré sa clef d ’amorce. Le téléphone stocke également un ensemble de certificats du dispositif de gestion des clefs du réseau. Ces certificats autorisent des utilisateurs particuliers à utiliser certains des particuliers.
Appel Un appel d’Alice vers Bernard se déroule comme suit : 1° Alice insère sa clef d’amorce dans le téléphone et elle entre son mot. de passe. 2° Le téléphone interroge la clef d ’amorce pour déterminer l’identité d’Alice et lui donne la tonalité.
3° Le téléphone vérifie son ensemble de certificats pour vérifier que cet utilisateur particulier est autorisé à utiliser ce téléphone particulier.
4° Alice forme le numéro; le téléphone établit l’appel. 5° Les deux téléphones utilisent un protocole d ’échange de clefs par cryptographie à clef publique pour engendrer une clef de session unique et aléatoire. Toutes les étapes suivantes du protocole seront chiffrées à l’aide de cette clef.
6° Le téléphone d ’Alice transmet son certificat et l’authentification de l ’utilisateur. 7° Le téléphone de Bernard vérifie l ’authenticité des signatures du certificat et de l’authentification de l ’utilisateur en utilisant la clef publique du réseau.
244
S T U -III
593
8° Le téléphone de Bernard amorce une suite de « défis -réponses ». Il demande des réponses signées en temps réel à des défis dépendant du temps3. Une réponse doit être signée avec la clef privée du téléphone d’Alice et l’autre doit être signée avec la clef privée d’Alice.
9° Le téléphone de Bernard sonne, à moins qu’il ne soit déjà en ligne. 10° S ’il est à la maison, Bernard insère sa clef d’amorce dans le téléphone. Son téléphone interroge la clef d’amorce et vérifie le certificat de Bernard comme aux étapes 2 et S.
11° Le téléphone de Bernard transmet son certificat et l’authentification de l ’utili sateur.
12° Le téléphone vérifie l’authenticité des signatures de Bernard comme à l’étape 7 et débute une suite de « défis -réponses » comme à l’étape 8. 13° Les deux téléphones affichent l’identité de l’autre utilisateur et de l’autre télé phone sur leur écran.
14° La conversation confidentielle commence. 15° Quand l’un des participants raccroche, la clef de session est effacée, ainsi que les certificats que le téléphone de Bernard a reçus du téléphone d’Alice et les certificats du téléphone d’Alice reçus du téléphone de Bernard.
Une nouvelle clef DES est utilisée pour chaque appel. Elle n’existe que dans chacun des deux téléphones pour la durée de l’appel et est détruite immédiatement après la fin de la conversation. Si un adversaire capture un ou les deux téléphones impliqués dans une communication, il ne sera pas capable de déchiffrer la moindre communication passée entre ces deux téléphones.
24.4
ST U -III
Le STU (pour « Secure Téléphoné Unit ») est un téléphone sûr conçu par la NSA. Ce terminal a à peu près l’allure et la taille d ’un téléphone normal et peut servir comme tel. Les téléphones sont aussi inviolables, assez pour ne pas être classés s’ils n’ont pas de clef. Ils ont aussi un port de données et peuvent protéger le trafic entre modems ainsi que les communications vocales [1140]. Whitfield D i f f i e parle du STU - III dans [492] : « Pour appeler avec le S T U -III, il suffit d’appeler normalement un autre poste S T U -III, puis d’insérer la clef contenant une variable cryptogra phique et d ’appuyer sur le bouton « sécurité ». Après une attente d ’environ 15 secondes pour réglage cryptographique, chaque téléphone affiche des in formations concernant l’identité et l’autorisation de l’autre partie, puis la conversation peut commencer. « Fait sans précédent, Walter D e e l e y , directeur de la sécurité des commu nications à la N SA, a annoncé le S T U -III ou le système future de sûreté vocale lors d ’un entretien avec The New York Times [286]. L’objectif initial 3. C e qui évite q u ’un adversaire puisseYitiliser des réponses fournies lors d ’ un échange précédent.
Chapitre 24
Exemples de réalisation
de ce nouveau système était de protéger les communications vocales et les transmissions de données à basse vitesse pour le Département américain de la Défense et ses fournisseurs. L’article ne révélait rien à propos de son fonctionnement, mais par la suite, des fuites ont levé le voile. Le nouveau système allait utiliser la cryptographie à clef publique. La nouvelle approche de la gestion de clefs avait été remarquée plus tôt dans [72] et un article parlait de téléphones « reprogrammés une fois par an par une liaison téléphonique sûre », une tournure de phrase qui sug gère l’utilisation d ’un protocole de passage de certificat, similaire à celui décrit dans le paragraphe 24.3, qui minimise le besoin de communications entre les téléphones et le centre de gestion de clefs. De récents rapports ne se sont pas fait attendre, parlant d’un système de gestion de clefs appelé F IR E F L Y qui [1353] « est issu de la technologie de clef publique et est utilisé pour établir une paire de clefs de chiffrement de trafic ». Cette des cription et ce témoignage soumis au Congrès américain par Lee N e u w i r t i i de C y l i n k [1164] suggèrent une combinaison d’échange de clefs et de certi ficats similaire à celle utilisée par le téléphone sûr ISDN, et il est plausible que F IR E F L Y soit aussi basé sur le calcul de puissances modulo n. » Les S T U -III sont fabriqués par A T & T et GE. Entre 300000 et 400000 unités ont été mises en ligne en 1994. Une nouvelle version, l’équipement terminal sûr (ST E pour « Secure Terminal Equipment »), fonctionnera sur les lignes ISDN.
24.5
Kerberos
K e r b e r o s est un protocole d ’authentification à tierce personne de confiance conçu pour les réseaux T C P /I P . Un service K e r b e r o s , résidant dans le réseau, agit comme un arbitre de confiance. K e r b e r o s offre l’authentification sûre en réseau en permettant à une personne d’accéder à différentes machines dans le réseau. K e r b e r o s est basé sur la cryptographie à clef secrète (le DES dans le cas de la réalisation concrète de K e r b e r o s , mais tout autre algorithme pourrait être utilisé) ; K e r b e r o s partage une clef secrète différente avec chaque entité du réseau et la connaissance de cette clef secrète tient lieu de preuve d’identité. K e r b e r o s a initialement été développé au M IT dans le cadre du projet A t h e n a . Le modèle de K e r b e r o s est basé sur le protocole à tierce personne de confiance de N e e d h a m et S c h r o e d e r (voir § 3.3) [1159J. La version originale de K e r b e r o s , V e r s i o n 4, a été spécifiée dans [1100, 1503]4. La V e r s i o n 5, construite par modi fication à partir de la V e r s i o n 4, a été spécifiée dans [877, 1417, 878], La meilleure vue d’ensemble de K e r b e r o s est [1163]. D ’autres articles d’études sont [1389, 1500] et deux bons articles décrivant l’utilisation concrète de K e r b e r o s sont [781, 782].
Le modèle de Kerberos Le protocole de base de K e r b e r o s est esquissé dans le paragraphe 3.3. Dans le modèle de K e r b e r o s il y a des entités — des clients et des serveurs — résidant dans le réseau. 4. Les versions 1 à 3 étaient des versions de développem ent interne.
2 f.5
595
K erb eros
Les clients peuvent être des utilisateurs, mais peuvent également être des programmes indépendants qui doivent faire certaines choses : télé-charger des fichiers, envoyer des messages, accéder à des bases de données, accéder à des imprimantes, obtenir des privilèges administratifs, etc. K er ber o s tient une base de données des clients et de leurs clefs secrètes. Pour un utilisateur humain, la clef secrète est un mot de passe chiffré. Les services du réseau nécessitant une authentification, ainsi que les clients qui désirent utiliser ces services, enregistrent leur clef secrète auprès de K e r b e r o s . Comme K er ber o s connaît la clef secrète de tout le monde, il peut créer des messages pour convaincre une entité de l’identité d’une autre entité. K er ber o s crée également des clefs d e session qui sont données au client et au serveur (ou aux deux clients) et à personne d ’autre. Une clef de session est utilisée pour chiffrer les messages entre deux participants, ensuite elle est détruite. K er ber o s utilise DES pour le chiffrement. La V ersio n 4 fournit un mode nonstandard pour l’authentification. Ce mode est faible : il ne détecte pas certains change ments apportés au texte chiffré (voir § 9.10). La VERSION 5 de utilise le mode C B C .
Fonctionnement de Kerberos Cette section décrit KERBEROS V e r sio n 5. Je soulignerai plus loin les différences entre la V ersion 4 et la V ersio n 5. Le protocole K er b e r o s est simple (voir la figure 24.1). Un client demande à K er b e r o s un ticket pour le serv ice d e d éliv ra n ce d e tickets (ticket S D T ) 5. Ce ticket, appelé « ticket d’obtention de ticket » (T O T ) 6, est envoyé au client, chiffré avec la clef secrète du client. Pour utiliser un serveur particulier, le client demande un ticket pour ce serveur au SD T. En faisant l’hypothèse que tout est en ordre, le S D T envoie au client le ticket demandé. Le client présente alors ce ticket avec un authentifiant au serveur du service désiré. Si rien ne cloche avec les accréditations du client, le serveur laisse le client accéder au service.
(
( Kerberos]
1 \ V
f
-----
/
Client ]-
F ig .
SDT
'
1. Requête pour un T O T 2. T O T 3. Requête pour un ticket de service 4. Ticket de service 5. Requête pour le service
a
5
—
h
Serveur ]
24.1 - Etapes d’authentification
K e rb e ro s
5. N ote du traducteur : en anglais, un tel service est appelé « T ic k e t-G r a n tin g S er v ic e » (T G S ). 6. N ote du traducteur : en anglais, un tel ticket est appelé « T G T » pou r « T ic k e t-G r a n tin g T ic k e t ».
Chapitre 24
596
Exemples de réalisation
Accréditations K e r b e r o s utilise deux types d ’accréditations : les t ic k e t s et les a u t h e n t if ia n t s 7. Un ticket est utilisé pour passer au serveur, de manière sûre, l’identité du client à qui le ticket a été émis. Il contient également des informations que le serveur peut utiliser pour s’assurer que le client qui utilise le ticket est bien celui à qui le ticket a été délivré. Un authentifiant est une accréditation supplémentaire présentée avec le ticket.
T
ab
.
24.1 - Tableau des abréviations utilisées par K
c s a v t Kx
Un ticket K
— client
= = = = =
T x ,y
= = =
A x ,y
=
K x,y {m }K x
erberos
erbero s
serveur adresse réseau du client temps de début et de fin de validité d’un ticket datation clef secrète de x clef de session pour x et y m chiffré avec la clef secrète de x ticket de x pour utiliser y authentifiant de x pour y
ressemble à ceci : Tc.s ~ 5, { c , g , v , K CjS)./y s -
Un ticket est valable pour un seul serveur et un seul client. Il contient le nom du client et son adresse réseau, le nom du serveur, une datation et une clef de session. Cette information est chiffrée avec la clef secrète du serveur. Une fois que le client obtient ce ticket, il peut l’utiliser plusieurs fois pour accéder au serveur, jusqu’à ce que le ticket expire. Le client ne peut pas déchiffrer le ticket (il ne connaît pas la clef secrète du serveur), mais il peut le présenter au serveur sous sa forme chiffrée. Personne ne peut espionner le réseau pour lire ou modifier les tickets qui passent. Un authentifiant K e r b e r o s ressemble à ceci : A Cfs — ( c tj clef)K c,s ■
Le client l’engendre chaque fois qu’il veut utiliser un service du serveur. L’authentifiant contient le nom du client, une datation et une clef de session supplémentaire optionnelle, tous chiffrés avec la clef de session partagés par le client et le serveur. Contrairement à un ticket, il ne peut être utilisé qu’une fois. Toutefois, comme un client peut engendrer les authentifiants suivant ses besoins (il connaît la clef secrète partagée), ce n’est pas un problème. L’authentifiant sert à deux choses. Primo, il contient du texte en clair chiffré avec la clef de session. Cela prouve qu’il connaît également la clef. Mais, ce qui est tout aussi important, le texte en clair scellé contient une datation. Un espion qui enregistre le ticket et l’authentifiant ne peut pas les rejouer deux jours après. 7. Le reste ce cette section utilise les notations utilisées dans les docum ents K erberos — voir le tableau 24.1.
24.5
K erberos
597
Messages de Kerberos Version 5 Le K erberos V ersion 5 a cinq messages: 1. Client vers K e r b e r o s : c,sdt. 2. K erberos vers le client : { K CiSdt} K c,{TCiSdt} K sdt. 3. Client vers le S D T : { A c,a} K cB}ÜfCiS, {Tc s} K s
Ces messages vont maintenant être développé en détails.
Obtention du premier ticket Le client dispose d’une information qui prouve son identité : son mot de passe. Il est clair que nous ne voulons pas que le client envoie son mot de passe sur le réseau. Le protocole K erberos minimise les chances que ce mot de passe soit compromis, tout en empêchant un utilisateur de s’identifier correctement s’il ne connaît pas son mot de passe. Le client envoie un message contenant le nom de l’utilisateur et le nom de son ser veur SD T au serveur d ’authentification K erberos 8. En réalité, l’utilisateur entre probablement juste son nom dans le système, et le programme de connexion envoie la requête. Le serveur d ’authentification K erberos cherche le client dans sa base de données. Si le client est dans la base de données, K erberos engendre une clef de session qui doit être utilisée entre le client et le SD T. C ’est ce qui est appelé un t ic k e t d ’ o b t e n t io n d e t ic k e t (T O T ). K erberos chiffre la clef de session avec 1a. clef secrète du client. Ensuite il crée un T O T pour le client, afin que celui-ci puisse s’authentifier au S D T et chiffre ce dernier ticket à l’aide de la clef secrète du SD T. Le serveur d’authentification envoie les deux messages chiffrés au client. Le client déchiffre alors le premier message et récupère la clef de session. La clef secrète étant une empreinte obtenue par hachage à sens unique de son mot de passe, un utilisa teur légitime n’aura donc aucun problème à effectuer ce déchiffrement. Si l’utilisateur était un imposteur, il ne connaîtrait pas le bon mot de passe et il ne pourrait donc pas déchiffrer la réponse du serveur d’authentification K erberos . L’accès serait refusé et le client ne pourrait pas obtenir le ticket ou la clef de session. Le client garde le T O T et la clef de session et il efface le mot de passe et l’empreinte obtenue par hachage à sens unique. Ces informations sont effacées pour minimiser les confusions possibles. Si un adversaire arrivait à avoir une copie de la mémoire centrale du client, il ne trouverait que le T O T et la clef de session. Ce sont des morceaux d’information qui ont de la valeur mais seulement durant la durée de vie du T O T . Après expiration du T O T , ils n’auront plus d ’utilité. Le client peut alors prouver son identité au S D T pendant la durée de vie du T O T . 8. Il peu t y avoir de nom breux serveurs S D T .
598
Chapitre 24
Exemples de réalisation
Obtention de tickets pour un service Un client doit obtenir un nouveau ticket pour chaque service qu’il désire utiliser. Le S D T délivre des tickets pour un seul serveur à la fois. Quand un client a besoin d’un nouveau ticket, il envoie sa requête au S D T 9. Quand le S D T reçoit la requête, il déchiffre le T O T avec sa clef secrète. Ensuite il utilise la clef de session incluse dans le T O T pour déchiffrer l’authentifiant. Enfin, il compare les informations de l’authentifiant avec les informations dans le ticket, l’adresse réseau du client avec l’adresse d ’où la requête a été envoyée et la datation avec le temps courant. Si tout concorde, il autorise l’exécution de la requête. La vérification des datations est basée sur l’hypothèse que toutes les machines ont synchronisé leurs horloges, du moins à quelques minutes près. Si la datation de la requête est trop lointaine dans le futur ou dans le passé, le S D T considère cette requête comme une ancienne requête rejouée. Le S D T doit également garder la trace de tous les authentifiants actifs, car des requêtes passées peuvent avoir des des datations encore valides. Une requête reçue avec le même ticket et la même datation qu’une autre requête déjà reçue peut être ignorée Le S D T répond à une requête valide en envoyant un ticket valide au client que ce dernier pourra présenter au serveur. Le S D T crée aussi une nouvelle clef de session pour le client et le serveur, chiffrée avec la clef de session partagée par le client et le SD T. Ces deux messages sont alors renvoyés au client. Celui-ci déchiffre le message et extrait la clef de session.
Demande d’un service Maintenant, le client est prêt à s’authentifier auprès du serveur. Il crée un message très similaire à celui qu’il a envoyé au S D T (ce qui est logique puisque le SD T est un service). Le client crée un authentifiant qui contient son nom et son adresse sur le réseau ainsi qu’une datation, le tout chiffré avec la clef de session entre le client et le serveur engendrée par le SD T . La requête contient le ticket reçu de K e r b e r o s (déjà chiffré avec la clef secrète du serveur) et l’authentifiant chiffré. Le serveur déchiffre et vérifie le ticket et l’authentifiant, comme décrit ci-dessus, et vérifie également l’adresse du client et la datation. Si tout concorde, le serveur sait, d’après K E R B E R O S , que le client est bien celui qu’il prétend être. Pour des applications qui nécessitent l’authentification mutuelle, le serveur envoie au client un message en retour qui contient la datation, chiffré avec la clef de session. Ceci prouve que le serveur connaissait la clef secrète du client et qu’il a pu déchiffrer le ticket et donc l’authentifiant. Le client et le serveur chiffrent les futurs messages avec la clef partagée, s’ils le désirent. Comme eux seuls partagent cette clef, ils peuvent tous deux faire l’hypothèse qu’un message récemment reçu et chiffré avec cette clef a bien pour origine l’autre participant.
Kerberos Version 4 La section précédente a décrit K e r b e r o s V e r s i o n 5. K e r b e r o s V e r s i o n 4 dif fère légèrement quant au contenu des messages et à la construction des tickets et des 9. Dans la réalité, le program m e peut faire cela autom atiquem ent et ce sera invisible à l’ utilisateur.
24-5
599
K erberos
authentifiants. Dans K erberos V ersion 4, les cinq messages ressemblent à ceci : 1. Client vers K e r b e r o s : c , s d t . 2. K erberos vers le client: { K csdt] K sdt} K c.
3. Client vers le S D T : {A c,s} K c,sdt, {TCtSdt} K sdt, s. 4. S D T vers le client: { K CjS,{T c s } K s} K C7sdt. 5. Client vers le serveur: { A C^ } K CS, {TCjS} i f 8 T vs — { s , r ,(7, ( 1. / A . Cls ~
,
1/ \s
{c,u,t}/éC)S.
Les messages 1, 3 et 5 sont identiques. Le double chiffrement des tickets pour les messages 2 et 4 a été retiré dans la VERSION 5. Les tickets de la VERSION 5 offrent la possibilité d’avoir des adresses multiples et ils remplacent le champs « life », 1, par un temps de début et de fin de validité du ticket. L’authentifiant de la V ersion 5 offre la possibilité d ’inclure une clef additionnelle.
Sécurité de Kerberos Steve B ellovin et Michael M erritt décrivent diverses vulnérabilités potentielles de K erberos au niveau de la sécurité [115]. Bien que cet article ait été écrit pour les protocoles de laVERSlON 4, nombre de leurs commentaires s’appliquent également à la V ersion 5. Il serait possible d’engranger des anciens authentifiants et de les rejouer. Bien que les datations soient supposées éviter cela, les messages peuvent être rejoués pendant la durée de vie du ticket. Les serveurs sont supposés stocker les tickets valides pour éviter que des messages soient rejoués, mais ce n’est pas toujours possible. De plus, la durée de vie du ticket peut être longue ; huit heures est la moyenne. Les authentifiants dépendent du fait que toutes les horloges du réseau sont plus ou moins synchronisées. Si l’on peut tromper un ordinateur quant à l’heure réelle, alors un ancien authentifiant peut être rejoué sans problème. La plupart des protocoles de maintien du temps en réseau ne sont pas sûrs, ce qui peut donc être un défaut sérieux. K erberos est aussi vulnérable aux attaques de paris de mots de passe. Un intrus peut collectionner les tickets et ensuite essayer de les déchiffrer. Rappelez-vous que l’utilisateur moyen ne choisit généralement pas des bons mots de passe. Si Martin collecte suffisamment de tickets, ses chances de retrouver le mot de passe sont bonnes. L ’attaque, la plus sérieuse peut-être, implique un logiciel malicieux. Le protocole K erb eros repose sur le fait que le logiciel K erberos est digne de confiance. Rien n’empêche Martin de remplacer subrepticement tous les logiciels K erberos clients par une ver sion qui non seulement réalise les protocoles K erberos mais également enregistre les mots de passe. C ’est un défaut commun à tous les logiciels cryptographiques qui sont exécutés sur un ordinateur peu sûr, mais l’utilisation répandue de K erberos dans ces environnements en fait une cible particulièrement attrayante. Des améliorations de K erberos sont à l’étude, comprenant une réalisation de cryptographie à clef publique et une interface à carte à puce pour la gestion de clef.
Chapitre 24
600
Exemples de réalisation
Licences K e r b e r o s n’est pas dans le domaine public, mais le code du M IT est disponible gratuitement . Dans les faits, utiliser ce code dans un environnement U N IX opérationnel est une toute autre histoire. De nombreux magasins vendent des versions de K e r b e r o s , mais vous pouvez obtenir une bonne version gratuite auprès de Cygnus Support, 814 University Ave., Palo Alto, CA, 94301 ; (415) 322-3811 ; fax: (415) 322-3270.
24.6
KryptoKnight
K r y p t o K n i g h t (subtil, n o n ? )10 est un système d ’authentification et de distribution de clef conçu par IBM . C ’est un protocole à clef secrète qui utilise soit le DES en mode C B C (voir § 9.3), soit une version modifiée de M D5 (voir § 18.5). K r y p t o K n i g h t offre quatre services de sécurité : - l ’a uthentification de l ’utilisateur (appelée « Single Sign-On
») ;
- l ’a uthentification à deux particip ants ; la distrib u tion de clefs ;
- l’authentification de l’origine et du contenu des données. Du point de vue de l’utilisateur, K quand même quelques différences : - K
rypto
K
n ig h t
rypto
K
n ig h t
est similaire à K
erberos.
Il y a
utilise une fonction de hachage po ur l ’identification et le chif
frement des tickets ; K
rypto
K
créés p o u r
n ig h t
ne repose pas sur des horloges synchronisées ; il utilise des mots
à l ’occasion p o u r les challenges (voir § 3.3) ;
- Si Alice veut communiquer avec Bernard, K r y p t o K n i g h t donne la possibi lité à Alice d’envoyer un message à Bernard, et à Bernard d’initier le protocole d ’échange de clefs. K r y p t o K n i g h t a des tickets et des authentifiants, tout comme K e r b e r o s . Il a des SD T , mais il les appelle des serveurs d’authentification. Les concepteurs de K r y p t o K n i g h t ont fait des efforts considérables pour réduire le nombre de messages, leurs longueurs ainsi que le volume de chiffrement. Pour plus d ’informations concernant K r y p t o K n i g h t , lisez [1116, 180, 182, 181].
24.7
SESAME
SESAM E (pour « Secure European System for Applications in a Multivendor Environ ment ») est un projet de sécurité de la communauté européenne, financé à 50 pourcent par R A C E (voir paragraphe 25.7), dont l’objectif principal est la production de tech nologie pour l’authentification des utilisateurs avec distribution du contrôle d’accès. 10. N ote du traducteur : en anglais, K ryptoK n ight se prononce com m e K ryptonite.
2f.8
Architecture cryptographique commune d T B M
601
C’est un peu une version européenne de K e r b e r o s . C’est un projet en deux parties : la première est un prototype de base de l’architecture, et la deuxième est un ensemble de projets commerciaux. Les trois entreprises les plus influents dans le développement sont ICL au Royaume-Uni, S i e m e n s en Allemagne et B u l l en France. SESAM E est mi système d ’authentification et d ’échange de clefs [365, 1258, 798, 1051]. Il utilise le protocole de Needham-Schroeder, avec cryptographie à clef publique pour communiquer entre différents domaines sensibles. Le système présente de sérieux défauts à plusieurs niveaux. Au lieu d ’utiliser un vrai algorithme de chiffrement, ils combinent par ou exclusif avec une clef de 64 bits. Pire encore, ils combinent par ou exclusif en mode C B C , ce qui ne chiffre que la moitié du texte en clair. Pour leur défense, ils voulaient utiliser le DES mais le gouvernement français a contesté ; ils ont validé le code avec DES mais l’ont ensuite retiré en espérant que les personnes le rajouteraient- Tout cela ne m ’impressionne guère. L’authentification dans SE SA M E est une fonction sur le premier bloc d ’im message, pas sur le message entier. Ceci a pour effet d’authentifier « Monsieur », et non pas le corps d ’une lettre. La génération de clefs consiste en deux appels vers la fonction rand d’U N IX, qui n’est pas très aléatoire. SE SAM E utilise crc32 et MD5 en tant que fonctions de hachage à sens unique. Bien sûr, SE SA M E est vulnérable
24.8
Architecture mune d’IBM
cryptographique
com
L’architecture cryptographique commune (C C A pour « Common Cryptographie Archi tecture ») a été conçue et développée par IBM afin de fournir des primitives cryptogra phiques pour la confidentialité, l’intégrité, la gestion des clefs et des codes personnels (PIN pour « Personal Identification Number ») [753, 784, 1035, 1036, 951, 754]. Les clefs sont gérées par les vecteurs de contrôle VC (voir § 8.5). Chaque clef a un VC com biné par ou exclusif et n’est jamais séparée du vecteur sauf à l’intérieur d ’un matériel sûr. Le VC est une structure de données fournissant une compréhension intuitive des privilèges associés à une clef particulière. Les bits individuels du VC ont des significations spécifiques pour utiliser et manier chaque clef gérée par la C C A . Le VC est transporté avec la clef chiffrée dans des structures de données appelées bons de clefs. Les bons de clef interne sont utilisés pour exporter et importer des clefs chiffrées entre systèmes. Les clefs dans les bons de clef externe sont chiffrées par les clefs de chiffrement de clefs (K E K pour « Key-encrypting keys »). Ces K E K sont gérées dans les bons de clef interne. Les clefs sont séparées selon leurs usages autorisés. La longueur de clef est aussi précisée et respectée en utilisant les bits du VC. Les clefs de longueur simple ont 56 bits et sont utilisées pour des fonctions telles que la confidentialité et l’authentification de messages. Les clefs de longueur double ont 112 bits et sont utilisées pour la gestion des clefs, les fonctions PIN et autres tâches spéciales. Les clefs peuvent être soit « doubles uniquement », dans ce cas les deux moitiés gauche et droite de la clef doivent être différentes, soit « doubles », et les moitiés peuvent être égales par chance, soit « simples reproduites », alors les moitiés gauches et droites sont égales, soit « simples » et contiennent 56 bits. Les fonctions de la C C A spécifient le matériel à utiliser avec certains types de clefs pour quelques
602
Chapitre 24
Exemples de réalisation
opérations. Le VC est vérifié dans un processeur sûr: il doit être en conformité avec les lois au torisées par la C C A pour chaque fonction C C A . Si le VC passe le test, une variante de la K E K ou M K est obtenue par la combinaison par ou exclusif de la K E K ou M K avec le VC, et la clef du texte en clair est disponible pour une utilisation interne avec la fonction C C A . Quand les nouvelles clefs sont générées, le VC précise les utilisations possibles de la clef générée. Ces combinaisons de types de clefs qui pourraient être utilisées pour attaquer le système ne sont pas générées ou importées dans un système compatible C C A . La C C A utilise une combinaison de cryptographie à clef publique et à clef secrète pour la distribution des clefs. Le K D C partage une clef maîtresse secrète avec chaque utilisateur et chiffre les clefs de séance avec cette clef maîtresse. Les clefs maîtresses sont distribuées en utilisant la cryptographie à clef publique. Les concepteurs du système ont choisi une approche hybride pour deux raisons. La première est la performance. La cryptographie à clef publique est informatiquement intense ; si les clefs de séance sont distribuées en utilisant la cryptographie à clef pu blique, une erreur système peut intervenir. La seconde est la compatibilité récurrente ; ce système peut être recouvert par des schémas à clef secrète avec une interruption minimum. Les systèmes C C A sont conçus pour être interopérables. Pour les systèmes non compa tibles C C A , une fonction de traduction de vecteur de contrôle (C V X L T pour « Control Vector Translate ») permet de passer les clefs entre les deux systèmes. L’initialisation de la fonction C V X L T exige un double contrôle. Les deux parties doivent régler les tables de traduction de façon indépendante. Un tel double contrôle garantit un haut niveau d’assurance concernant l’intégrité et le pédigré de toute clef introduite dans le système. Une clef de type D A T A est fournie pour la compatibilité avec d’autres systèmes. Une clef D A TA est stockée avec un VC qui l’identifie comme étant bien une clef DATA. Les clefs D A TA sont d ’une utilisation très large et doivent donc être considérées avec suspicion et utilisées avec prudence. Les clefs D ATA ne devraient pas être utilisées dans les fonctions de gestion de clefs. Le C D M F (pour « Commercial Data Maskmg Facility ») fournit une version exportable de C C A . Elle a une caractéristique spéciale qui réduit les clefs DES à 40 bits pour l’export (voir § 15.5) [785].
24.9
Environnement d’authentification ISO
La cryptographie à clef publique a été recommandé pour l’environnement d’authenti fication ISO, connu aussi sous l’appellation « protocoles X .509 » [309]. Cet environ nement offre l’authentification à travers plusieurs réseaux. Bien qu’aucun algorithme particulier ne soit spécifié ni pour la sécurité ni pour l’authentification, la spécification recommande le R SA .. Il y a toutefois des aménagements pour permettre l’utilisation de multiples algorithmes et fonctions de hachage. Le protocole X .509 a été introduit pour la première fois en 1988. Après utilisation par le public, il a été révisé en 1993 pour corriger des problèmes de sécurité [1106, 752],
2Jt.9
Environnement d’authentification IS O
603
Certificats La partie la plus importante du protocole X .509 est sa structure pour les certificats à clefs publiques. Chaque utilisateur a un nom distinct. Une a u to rité de certifica tion (C A pour « Certification Authority ») fiable assigne un nom unique à chaque utilisateur et émet un certificat signé contenant le nom et la clef publique de l’utilisateur. La figure 24.2 montre un certificat X .509 [309], Version Numéro de série Identificateur de l’algorithme : —Algorithme —Paramètres Délivreur Période de validité : —Pas avant ... —Pas après ... Sujet Clef publique du sujet : —Algorithme —Paramètres — Clef publique Signature
F i g . 24.2 - Un certificat X.509
Le champ de la version identifie le format du certificat. Le numéro de série est unique dans la C A . Le champ suivant identifie l’algorithme utilisé pour signer le certificat, ainsi que tous les paramètres nécessaires. L’autorité qui délivre est la C A . La période de validité est une paire de dates entre lesquelles le certificat est valide. Le sujet est le nom de l’utilisateur. L’information de clef publique du sujet comprend le nom de l’algorithme, tous les paramètres nécessaires et la clef publique. Le dernier champ est la signature de l’entre la C A . Si Alice veut communiquer avec Bernard, elle doit d’abord trouver son certificat dans une base de données. Puis elle vérifie son authenticité. S’ils utilisent tous deux la même C A , c’est facile. Alice vérifie simplement la signature de la C A sur le certificat de Bernard. S’ils utilisent des C A différentes, c ’est plus compliqué. Imaginez une structure arbo rescente, avec des C A différentes qui certifient d’ autres C A et d ’autres utilisateurs. Au sommet, il y a une C A maîtresse. Chaque C A a un certificat signé par la C A supérieure, ainsi que par la C A inférieure. Alice utilise ces certificats pour vérifier le certificat de Bernard. La figure 24.3 illustre cela. Le certificat d’Alice est certifié par l’C A ^ ; celui de Bernard par l’C A ii. Alice connait la clef publique de I’C A a- L’C A c a un certificat signé par I’C A a , aussi Alice peut le vérifier. L’CA o a un certificat signé par l’C A c . L’C A /j a un certificat signé par l’ C A p- Le certificat de Bernard est signé par l’C A g . En remontant l’arborescence jusqu’à un point de commun, dans ce cas I’C A d , puis en la redescendant
Chapitre 24
604
Exemples de réalisation
jusqu’à Bernard, Alice peut vérifier le certificat de Bernard.
F
ig .
24.3 - Exemple de hiérarchie de certification
Les certificats peuvent être stockés dans des bases de données sur le réseau. Les uti lisateurs peuvent se les envoyer. Quand un certificat expire, il doit être retiré de tous les répertoires publics. Toutefois, la C A émettrice doit garder une copie du certificat. Elle sera nécessaire pour résoudre tout conflit ultérieur qui pourrait se produire. Les certificats peuvent aussi être révoqués, soit parce que la clef de l’utilisateur a été compromise, la clef de la C A a été compromise, soit parce que la C A ne veut plus certifier l’utilisateur. Chaque C A doit garder une liste des certificats révoqués mais non expirés. Quand Alice reçoit un nouveau certificat, elle devrait vérifier qu’il n’a pas été révoqué. Elle peut consulter une base de données sur le réseau de clefs révoquées, mais plus probablement, elle consultera plutôt une liste en mémoire cache locale de clefs révoquées. Il y a sûrement des abus à ce système ; la révocation de clef en est la partie la plus faible.
Les protocoles d’authentification Alice veut communiquer avec Bernard. D ’abord, elle consulte une base de données et elle obtient ce que l’on appelle un « chemin de certification » d ’Alice à Bernard ainsi que la clef publique de Bernard. A partir de là, Alice peut démarrer un protocole d ’authentification uni-, bi- ou tri-directionnel. Le protocole unidirectionnel est une communication simple entre Alice et Bernard. Il établit l’identité d ’Alice et de Bernard ainsi que l’intégrité de toutes les informations qui transitent entre Alice et Bernard. Il empêche également les attaques par blocs rejoués pendant la communication. Le protocole bidirectionnel ajoute une réponse de Bernard. Il établit que Bernard, et non un imposteur, a envoyé la réponse. Il garantit également la confidentialité des deux communications et il empêche les attaques par blocs rejoués.
24-9
Environnement d’authentification IS O
605
Les protocoles uni- et bi-directionnels utilisent tous deux des datations. Un protocole tridirectionnel ajoute un message supplémentaire entre Alice et Bernard, qui permet de se passer de datations (et donc d’heure authentifiée). Le protocole unidirectionnel est donné par : 1° Alice engendre un nombre aléatoire R a 2° Alice construit un message, A4 = (TA,RA,Is,d ) où Ta est la datation d’Alice, I b est l’identité de Bernard et d est une donnée arbitraire. Les données peuvent, par sécurité, être chiffrées avec la clef publique de Bernard E b -
3° Alice envoie (C a ,D a (A4)) à Bernard (C a est le certificat d’Alice; D a est le point commun dans l’arborescence).
4° Bernard vérifie C a et obtient E a - Il vérifie que ces clefs n’ont pas expiré. (E a est la clef publique d’Alice.)
5° Bernard utilise E
a pour chiffrer D a (A4). Il vérifie la signature d’Alice et l’in tégrité des données signées.
6° Bernard vérifie l ’exactitude de I b dans A4. 7 ° Bernard vérifie Ta dans A4 et ainsi s ’assure que le message est d’actualité.
8° Optionnellement, Bernard peut chercher la partie R a de A4 dans une base de données d’anciens nombres aléatoires pour vérifier que ce message n’est pas un ancien message rejoué.
Le protocole bidirectionnel est constitué du protocole unidirectionnel, puis d ’un pro tocole unidirectionnel similaire de Bernard vers Alice. Après l’exécution des étapes 1 à 8 du protocole unidirectionnel, le protocole bidirectionnel continue ainsi : 9° Bernard engendre un autre nombre aléatoire R b 10° Bernard construit un message AA' = (Tb ,Rb ,I a ,R a ,(I),
où T b est la datation de Bernard, I a est l’identité d’Alice et d est une donnée arbitraire. Par sécurité, les données peuvent être chiffrées avec la clef publique d’Alice E a - R a est le nombre aléatoire engendré par Alice à l’étape 1.
11° Bernard envoie D b (AA') à Alice. 12° Alice utilise E
b pour déchiffrer D b {AA'). Elle vérifie la signature de Bernard et l’intégrité des informations signées.
13° Alice vérifie l’exactitude de 1a extraite de AA'. 14° Alice vérifie la datation Tb de A4' et s ’assure que le message est d’actualité. 15° Optionnellement, Alice peut vérifier R b de A4' pour s ’assurer que ce n’est pas un vieux message rejoué.
Le protocole tridirectionnel fait la même chose que le protocole bidirectionnel, mais sans les datations. Les étapes 1 à 15 sont identiques à celles du protocole bidirectionnel avec Ta = Tb — 0. 16° Alice compare le R a qu’elle a reçu au R a qu’elle a envoyé à Bernard à l’étape 3.
606
Chapitre 24
17° Alice envoie
D
a
( R b
)
Exemples de réalisation
à Bernard.
18° Bernard utilise E a pour déchiffrer D a (R b )- Cela permet de contrôler la signa ture d’Alice et l’intégrité des données signées.
19° Bernard compare le R b reçu au R b qu’il a envoyé à Alice à l’étape 10.
24.10
« Privacy-Enhanced Mail » (PEM)
P E M est le standard
I n t e r n e t de « Privacy-Enhanced Mail » adopté par l’« Internet Architecture Board » (IA B ) pour offrir du courrier électronique sûr à travers le réseau I n t e r n e t . Il a initialement été conçu par le groupe « Privacy and Security Research Group » (P S R G ) de l’« Internet Resources Task Force » (IR T F ) et a ensuite été passé au groupe « PEM Research Group » de l’ « Internet Engineering Task Force » (IE TF).
Les protocoles PE M offrent le chiffrement, l’authentification, l’intégrité des messages et la gestion des clefs. Les protocoles P E M complets ont été initialement décrits dans une série de R F C (pour « Requests For Comments ») dans [988] et ensuite révisés dans [989]. Une troisième révision des protocoles [990, 825, 991] est résumée dans [184, 185]. Les protocoles ont été modifiés et améliorés, et les protocoles résultants sont détaillés dans une autre série de R F C [992, 827, 83, 812]. Un autre article de Matthew B lS H O P [186] détaille ces changements. Des rapports de tentatives d ’applications du P E M sont dans [601, 1509, 1526, 81, 355, 1368, 1369]. Voir aussi [1398]. P E M est un standard global. Les procédures et les protocoles P E M sont conçus pour être compatibles avec une large gamme d ’approches de gestion de clefs, y compris les deux schémas à clef secrète et à clef publique pour chiffrer des clefs de chiffrement de données. La cryptographie à clef secrète est utilisée pour le chiffrement du texte des messages. Des algorithmes de hachage cryptographique sont utilisés pour garantir l’intégrité des messages. D ’autres documents supportent les mécanismes de gestion de clefs utilisant des certificats à clef publique ; les algorithmes, les modes et les identifi cateurs associés ; et les détails concernant les formats papier et électronique ainsi que les procédures d ’infrastructure de la gestion des clefs nécessaires pour supporter ces services. PE M n’est prévu que pour certains algorithmes, mais accepte différentes suites d ’al gorithmes que nous préciserons plus tard. Les messages sont chiffrés avec le DES en mode C B C . L’authentification est fournie par ce que l’on appelle « Contrôle d ’intégrité de Messages » (C IM ) et utilise soit M D2 soit M D5 La gestion de clefs à l’aide de clefs secrètes peut utiliser soit le DES en mode E C B soit le DES triple, avec deux clefs (appelé le mode E D E ). P E M supporte aussi les certificats à clef publique pour la gestion des clefs en utilisant l’algorithme R SA (avec une clef d’au plus 1024 bits) et la structure standard de certificat X.509. La cryptographie de bout en bout offre trois « services à confidentialité renforcée » : la confidentialité, l’authentification, l’intégrité des messages. Il n’y a pas de requis spéciaux imposés au système de courrier électronique. P E M peut être incorporé sélec tivement, par site ou par utilisateur, sans affecter le reste du réseau.
2^.10
« Privacy-Enhanced Mail » ( P E M )
607
Documents PEM Les spécifications du PE M proviennent de quatre documents : RFC 1421, P a r t I, M e s s a g e E n c r y p tio n and A u th e n tic a tio n PROCEDURES. C e d ocu m en t définit le chiffrem ent des messages et les procédures d ’authentification nécessaires p o u r offrir sur P I n t e r n e t des services de courrier électroniqu e à confidentialité renforcée.
- R F C 1422, P a r t II, C e r t i f i c a t e - B a s e d K e y M a n a g e m e n t . Ce document définit l’architecture et l’infrastructure de la gestion de clefs basées sur des tech niques de certification à clef publique afin d’offrir des informations sur les clefs aux expéditeurs et aux destinataires de messages. - R F C 1423, P a r t I I I , A l g o r i t h m s , M o d e s , I d e n t i f i e r s . Ce document four nit les définitions, les formats, les références et les citations pour les algorithmes cryptographiques, les modes d ’utilisation, ainsi que les identificateurs et para mètres associés. - R F C 1424, P a r t IV , K e y C e r t i f i c a t i o n a n d R e l a t e d S e r v i c e s . Ce docu ment décrit trois types de services pour le support de P E M : la certification de clef, le stockage de la liste des certificats révoqués (C R L ) et l’accès à cette liste.
Les certificats PEM est compatible avec l’environnement d’authentification décrit dans [309] ; voir aussi [828].PE M est une sur-couche de X .509 ; il établit les procédures et les conven tions pour une infrastructure de gestion de clefs à utiliser avec P E M et, dans le futur, avec d ’autres protocoles (à la fois des suites T C P /I P et ISO). L’infrastructure de gestion de clefs instaure une seule source pour toutes les certifi cations sur P I n t e r n e t . L’« Internet Policy Registration Authority » (IP R A ) édicté tous les règlements qui s’appliquent aux certifications dans la hiérarchie. A partir de la racine IP R A on trouve les « Policy Certification Authorities » (P C A ), dont cha cune instaure et publie ses règlements pour l’enregistrement des utilisateurs ou des organisations. Chaque P C A est certifiée par l’IP R A . En dessous des P C A , les C A certifient les utilisateurs et les entités subordonnées aux organisations (tels que les dé partements, bureaux, filiales). Initialement, la majorité des utilisateurs sont supposés être enregistrés au sein d’une organisation. Certaines P C A sont censées offrir la certification pour les utilisateurs qui ne font pas partie d’une organisation. Pour les utilisateurs qui veulent préserver leur anonymat tout en ayant accès aux avantages du courrier à confidentialité renforcée de PE M , une ou plusieurs P C A sont prévues pour établir les règlements qui permettent l’enregistrement d’utilisateurs ne voulant pas divulguer leur identité.
Messages PEM Le cœur d’un message P E M est son format. La figure 24.4 montre un message chiffré en utilisant la gestion de clefs à clef secrète ; la figure 24.5 montre un message authentifié
Chapitre 24
608
Exemples de réalisation
BEGIN PRIVACY-ENHANCED MESSAGE----Proc-Type: 4,ENCRYPTED Content-Domain: RFC822 DEK-Info: D E S - C B C ,F8143EDE5960C597 Originator-ID-Symmetric: [email protected] o m ,, Recipient-ID-Symmetric: [email protected],ptf-kmc,3 K e y - I n f o : D E S - E C B ,R S A - M D 2 ,9FD3AAD2F2691B9A,B70665BB9BF7CBCDA60195DB94F727D3 Recipient-ID-Symmetric: [email protected],ptf-kmc,4 K e y - I n f o : D E S - E C B ,RS A - M D 2 ,161A3F75DC82EF26,E2EF532C65CBCFF79F83A2658132DB47
LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoHlnvNSIWL9M 8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlKlZ6720dcBWGGsDLpTpSCnpot dXd/H5LMDWnonNvPCwQUHt== END PRIVACY-ENHANCED MESSAGE-----
F
ig
.
24.4 - Exemple de message encapsulé (à clef secrète)
et chiffré utilisant la gestion de clefs à clef publique et la figure 24.6 montre un message authentifié mais non chiffré qui utilise la gestion de clefs à clef publique. Le premier champ est « Proc-Type » qui identifie le type de traitement effectué sur le message. Il y a trois types possibles de messages. L’identificateur « ENCRYPTED » signifie que le message est chiffré et signé. Les identificateurs « MIC-ONLY » et « MIC-CLEAR » indiquerait que le message est signé mais non chiffré. Les messages « MIC-CLEAR » ne sont pas encodés et ils peuvent être lus par des logiciels non-PEM . Les messages « MIC-ONLY » ont besoin d ’un logiciel P E M pour être transformés afin d’être lisibles par un être humain. Un message PE M est toujours signé ; il est optionnellement chiffré. Le champ suivant, « Content-Domain » spécifie le type de message. Il n’a rien à voir avec la sécurité. Le champ « DEK-Info » donne ses informations sur la « Data Exchange Key » (D E K , clef d’échange de données), l’algorithme utilisé pour chiffrer le texte et n’importe quels paramètres associés à cet algorithme de chiffrement. Seul le DES, ou « DES-CBC » est spécifié. Le second sous-champ spécifie l’IV. D ’autres algorithmes pourraient à l’avenir être spécifiés pour PE M ; leur utilisation sera indiquée dans le champ « DEK-Info » et dans d ’autres champs qui identifient les algorithmes. Pour les messages avec gestion de clefs à clef secrète (voir figure 24.4), « O rig in a tor-ID-Symmetric » est le champ suivant, avec trois sous-champs. Le premier sous-champ identifie l’expéditeur par une adresse de courrier électronique unique. Le deuxième souschamp est optionnel et identifie l’autorité qui a émis la clef d ’échange (l’IK décrite ciaprès). Le troisième sous-champ est un sous-champ optionnel « V e rsion /E x p ira tion ». En continuant avec le cas de la gestion de clefs à clef secrète, à chaque destinataire sont associés les deux champs: « R ecipient-ID -Sym m etric » et « K ey-Inf o » . Le champ « R ecipient-ID -Sym m etric » a trois sous-champs; ils identifient le destinataire de la même manière que le champ « O riginator-ID -Sym m etric » identifie l’expéditeur. Le champ « K ey-Inf o » spécifie les paramètres de la gestion de clefs. Ce champ a quatre sous-champs. Le premier sous-champ donne l’algorithme utilisé pour chiffrer la DEK. Comme la gestion de clefs pour ce message est à clef secrète, l’expéditeur et le desti-
24-10
« Privacy-Enhanced Mail » ( P E M )
609
BEGIN PRIVACY-ENHANCED MESSAGE----Proc-Type: 4,ENCRYPTED Content-Domain: RFC822 DEK-Inf o : D E S - C B C ,BFF968AA74691A C 1 Driginator-Certificate: MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGAlUEBhMCVVMxIDAeBgNV BAoTFlJTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQx0DM4MTdaFw05MzA5MDMx0DM4MTZaMEUx CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWNlcml0eSwgSW5jLjEU MBIGAlUEAxMLVGVzdCBVc2VyIDEwWTAKBgRVCAEBAgICAANLADBIAkEAwHZH17i+ yJcqDtjJCowzTdBJrdAiLAnSC+Cnnj0JELyuQiBgkGrgIh3j8/xOfM+YrsyFlu3F LZPVtzlndhYFJQIDAQABMA0GCSqGSIb3DQEBAgUAAlkACKr0PqphJYwlj+YPtcIq iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U/ 5XUXGx7qusDgHQGs7Jk9W8CWlfuSWUgN4w== Key-Info: RSA, I3rRIGXUGWAF8js5wCzRTkdh034PTHdRZY9Tuvm03M+NM7fx6qc5udixps2Lng0+ wGrtiUm/ovtKdinz6ZQ/aQ== Issuer-Certificate: MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGAlUEBhMCVVMxIDAeBgNV BAoTFlJTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDTAL BgNVBAsTBFRMQOEwHhcNOTEwOTAxMDgwMDAwWhcNOTIwOTAxMDc10TU5Wj BRMQsw CQYDVQQGEwJVUzEgMB4GAlUEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4xDzAN BgNVBAsTBkJldGEgMTEPMA0GAlUECxMGTk9UQVJZMHAwCgYEVQgBAQICArwDYgAw XwJYCsnp61QCxYykN10DwutF/jMJ3kL+3PjYyH0wk+/9rLg6X65B/LD4bJHt05XW cqAz/7R7XhjYCmOPcqbdzoACZtHETrKrcJiDYoP+DkZ8klgCk7hQHpbIwIDAQAB MA0GCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8zgoMG0x dD2jMZ/3HsyWKWgSF0eH/AJB3qr9zosG47pyMnTf3aSy2nB07CMxpUVRBcXUpE+x EREZd9++32ofGBIXaiaIn0gVUn00zSYgugiQ077nJLDUj0hQehCizEs5wUJ35a5h MIC-Info: RSA-MD5.RSA, UdFJR8u/TIGhfH65ieewe210W4tooa3vZCvVNGBZirf/7nrgzWDABz8w9NsXSexv Aj RFbHoNPzBuxwmOAFeAOHJszL4yBvhG Recipient-ID-Asymmetric: MFExCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWNlcml0eSwgSW5j LjEPMAOGA HJECxMGQmV0YSAxMQ8wDQYDVQQLEwZ0TlRBUlk=, 66 K ey-Info: R S A , D6BS1ww9CTyHPt S3bMLD+L0hej dvX6QvlHK2ds2sQPEaXhX8EhvVphHYTjwekdWv 7xOZ3Jx2vTAhOYHMcqqCjA== qeWlj/YJ2Uf5ng9yznPbtD0mYloSwIuV9FRYx+gzY+8iXd/NQrXHfi6/MhPfPF3d jIqCJAxvld2xgqQimUzoSla4r7kQQ5c/Iua4LqKeq3ciFzEv/MbZhA== END PRIVACY-ENHANCED MESSAGE-----
FlG. 24.5 - Exemple de message encapsulé chiffré (à clef publique)
nataire doivent partager une clef commune. C ’est ce que l’on appelle l’« Interchange Key » (IK ) qui est utilisée pour chiffrer la D E K . La D E K peut soit être chiffrée avec le DES en mode E CB (dénoté « DES-ECB ») ou avec le DES- triple (dénoté « DES-EDE »). Le deuxième sous-champ spécifie l’algorithme pour le CIM (M IC). Cela peut être soit MD2 (dénoté « RSA-MD2 ») soit M D 5 (dénoté « RSA-MD5 »). Le troisième sous-champ,
Chapitre 24
610
Exemples de réalisation
BEGIN PRIVACY-ENHANCED MESSAGE-------Proc-Type: 4,MIC-ONLY Content-Domain: RFC822 Originator-Certificate: MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGAlUEBhMCVVMxIDAeBgNV BAoTFlJTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQx0DM4MTdaFw05MzA5MDMx0DM4MTZaMEUx CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWNlcml0eSwgSW5jLjEU MBIGAlUEAxMLVGVzdCBVc2VyIDEwWTAKBgRVCAEBAgICAANLADBIAkEAwHZH17i+ yJcqDtjJCowzTdBJrdAiLAnSC+Cnnj0JELyuQiBgkGrgIh3j8/x0fM+YrsyFlu3F LZPVtzlndhYFJQIDAQABMA0GCSqGSIb3DQEBAgUAAlkACKr0PqphJYwlj+YPtcIq iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U/ 5XUXGx7qusDgHQGs7 Jk9W8 CW 1f u SWUgN4w== Issuer-Certificate: MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGAlUEBhMCVVMxIDAeBgNV BAoTFlJTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDTAL BgNVBAsTBFRMQ0EwHhcN0TEw0TAxMDgwMDAwWhcN0TIw0TAxMDcl0TU5WjBRMQsw CQYDVQQGEwJVUzEgMB4GAlUEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4xDzAN BgNVBAsTBkJldGEgMTEPMA0GAlUECxMGTk9UQVJZMHAwCgYEVQgBAQICArwDYgAw XwJYCsnp61QCxYykN10DwutF/jMJ3kL+3PjYyH0wk+/9rLg6X65B/LD4bJHt05XW cqAz/7R7XhjYCmOPcqbdzoACZtHETrKrcJiDYoP+DkZ8klgCk7hQHpbIwIDAQAB MA0GCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8zgoMG0x dD2jMZ/3HsyWKWgSF0eH/AJB3qr9zosG47pyMnTf3aSy2nB07CMxpUWRBcXUpE+x EREZd9++32ofGBIXaialn0gVUn00zSYgugiQ077nJLDUj0hQehCizEs5wUJ35a5h MIC-Info: R S A - M D 5 ,R S A , jV20fH+nnXHU8bnL8kPAad/mSQlTDZlbVuxvZA0VRZ5q5+Ej15bQvqNeqOUNQj r6 EtE7K2QDeVMCyXsdJlA8fA== LSBBIGllc3NhZ2UgZm9yIHVzZSBpbiB0ZXN0aW5nLg0KLSBGb2xsb3dpbmcgaXMg YSBibGFuayBsaW510g0KDQpUaGlzIGlzIHRoZSBlbmQuDQo= END PRIVACY-ENHANCED MESSAGE-----
F i g . 24.6 - Exemple de message M IC -ONLY encapsulé (à clef publique)
la D EK , et le quatrième sous-champ, le CIM , sont tous deux chiffrés avec l’IK. Les figures 24.5 et 24.6 montrent des messages avec une gestion de clefs à clef pu blique (appelée « asymétrique » en nomenclature P E M ). Les en-têtes sont différents. Dans les messages « ENCRYPTED », après le champ « DEK-Info », vient le champ « Originator-Certif icate ». Le certificat est conforme au standard X .509 (voir § 24.9). Le champ suivant est « Key-Info » qui comporte deux sous-champs. Le pre mier spécifie l’algorithme à clef publique utilisé pour chiffrer la D E K ; actuellement seul le R SA est offert. Le second sous-champ est la D EK chiffrée avec la clef publique de l’expéditeur. C’est un champ optionnel, destiné à permettre à l’expéditeur de dé chiffrer son propre message dans le cas où celui-ci serait renvoyé à l’expéditeur par le système de courrier. Le champ suivant « Issuer-Certif icate » est le certificat de celui qui a signé le « Originator-Certif icate ». En continuant avec le cas de la gestion de clefs à clef publique, le champ suivant est « MIC-Info » Le premier sous-champ donne l’algorithme utilisé pour calculer le CIM . Le deuxième sous-champ désigne l’algorithme avec lequel le CIM a été signé. Le
24-10
« Privacy-Enhanced Mail » / P E M )
611
troisième sous-champ contient le C IM signé avec la clef privée de l’expéditeur. Toujours avec la gestion de clefs à clef publique, les champs suivants décrivent les destinataires. « Recipient-ID-Asymmetric » et « Key-Info » sont deux champs pré sents pour chaque destinataire. Le champ « Recipient-ID-Asymmetric » a deux souschamps. Le premier identifie l’autorité qui a émis la clef publique du destinataire ; le second est un sous-champ optionnel « Version/Expiration » Le champ « Key-Info » spécifie les paramètres de la gestion de clefs: le premier sous-champ identifie l’algo rithme utilisé pour chiffrer le message et le second sous-champ est la DEK chiffrée avec la clef publique du destinataire.
Sécurité de PEM Les clefs R S A dans PE M peuvent avoir de 508 à 1024 bits. Cela devrait être assez long pour les besoins de sécurité de n ’importe qui. Une attaque plus probable serait contre le protocole de gestion des clefs. Martin peut voler votre clef privée ne l’écrivez jamais nul part ou bien il peut essayer de vous duper en vous faisant accepter une fausse clef publique. Les règles de certification des clefs de PE M rendent improbable une telle attaque pour autant que les utilisateurs suivent scrupuleusement les bonnes procédures, mais les gens ont une tendance naturelle à être négligents. Une attaque plus insidieuse consisterait pour Martin à modifier la réalisation de P E M qui tourne sur votre système. La réalisation modifiée pourrait subrepticement envoyer à Martin tout votre courrier chiffré avec sa clef publique. Il pourrait même s’envoyer une copie de votre clef privée. Si la réalisation modifiée fonctionne correctement, vous ne serez pas au courant de ce qui se passe. U n’y a pas de vrai moyen de se prémunir contre ce genre d’attaque. Vous pouvez utiliser une fonction de hachage à sens unique pour associer une empreinte à l’exécutable de PEM . Ainsi, chaque fois que vous l’exécutez vous pouvez vérifier l’empreinte pour détecter une modification éventuelle. Mais Martin peut modifier le code de calcul de l’empreinte en même temps qu’il modifie le code de PE M . Vous pourriez calculer l’empreinte de l’empreinte, mais Martin peut modifier cela aussi. En fait, si Martin a accès à votre machine, il peut subvertir la sécurité de PEM . La morale de cette histoire est que vous ne pouvez jamais vraiment faire confiance à un morceau de logiciel si vous ne pouvez pas avoir confiance dans la machine qui l’exécutera. Pour la plupart des gens, ce type de paranoïa est injustifié. Pour d ’autres, c’est très concret.
T IS/P E M r u s t e d I n f o r m a t i o n S y s t e m s , partiellement subventionnée par l’agence « Advan ced Research Projects Agency » du Gouvernement américain, a conçu et réalisé une
T
référence de PE M (T IS /P E M ). Développée pour des plates-formes U NIX, elle a éga lement été portée sous V M S, M S- D O S et MS W i n d o w s . Bien que la spécification P E M n’indique qu’une seule hiérarchie de certification pour l’iN T E R N E T , T IS /P E M autorise l’existence de plusieurs hiérarchies de certification. Les sites peuvent spécifier un ensemble de certificats qui doivent être considérés comme valides, y compris les certificats émis par eux-mêmes. Un site n’est pas obligé de se joindre à la hiérarchie In t e r n e t pour utiliser T IS /P E M .
612
Chapitre 24
Exemples de réalisation
T IS /P E M est actuellem ent disp on ib le p o u r tou tes les organisations et tou s les citoyens am éricains et canadiens qui en fon t la dem ande. T IS /P E M est distribué sous form e de co d e source. Les personnes intéressées doivent co n ta cte r : P r iv a c y -E n h a n c e d M a il, T r u s te d I n fo r m a t io n S y s te m s , I n c . , 3060 W a sh in g ton Road (R t e . 9 7 ) , G len w ood , MD 2 1 7 3 8 , USA; +1 (3 0 1 ) 8 5 4 - 6 8 8 9 ; F a x: +1 (3 0 1 ) 8 5 4 - 5 3 6 3 ; I n t e r n e t : p e m -in fo @ t is .c o m .
RIPEM R IP E M est un programme écrit par Mark R i o r d a n qui réalise les protocoles PEM. Bien que ce programme ne soit pas techniquement pas dans le domaine public, il est disponible publiquement et peut être utilisé sans paiement de royalties pour les appli cations à usage individuel non commerciales. Une licence d’exploitation accompagne la documentation. Le code ne peut pas être exporté hors des Etats-Unis et du Canada. Naturellement, les lois du Gouvernement américain ne s’appliquent pas hors des Etats-Unis et les gens ont ignoré les règles d ’exportation. Le code de R IP E M est disponible à travers le monde entier sur des tableaux d ’affichage. Le R IP E M /S IG , qui ne fait que des signatures digitales, est exportable. A la parution de ce livre, R IPE M n’est pas une réalisation complète des protocoles PE M ; il ne réalise pas les certificats pour les clefs d ’authentification. Avant d’écrire R IP E M , R i o r d a n a écrit un programme similaire appelé R PE M . Ce dernier devait être un programme du domaine public de courrier électronique chiffré. Pour éviter les problèmes de brevet, R i o r d a n avait utilisé l’algorithme de R a b i n (voir § 19.5). Mais P u b l i c K e y P a r t n e r s prétendit que leurs brevets sont assez larges pour couvrir toute la cryptographie à clef publique et a menacé d’attaquer en justice ; R i o r d a n a arrêté de distribuer R PE M . R P E M n ’est plus vraim ent utilisé. Il n ’est pas com patible avec R IPE M . Com m e R IP E M peut être utilisé avec la bénédiction de P u b l i c K e y P a r t n e r s , il n ’y a pas de raison de lui préférer R PE M .
24.11
« Message Security Protocol » (MSP)
Le « Message Security Protocol » (abrégé M SP) est l’équivalent militaire de PEM . Il a été développé par la NSA à la fin des années 80 dans le cadre du programme « Secure Data Network System » (abrégé SDNS). C ’est un protocole compatible X .400 au niveau des applications pour protéger le courrier électronique. Le M SP sera utilisé pour signer et chiffrer les messages au sein du réseau « Defense Message System » (D M S) du Département de la Défense américaine. Le protocole « Preliminary Message Security Protocol » (P M S P ), destiné à être utilisé pour des messages non classés mais sensibles, est une version adaptée pour fonctionner avec X .400 et T C P /I P . Ce protocole est également appelé « Mosaic ». Tout comme pour P E M , les applications logicielles M SP et PM SP sont flexibles et conçues pour adapter une variété d ’algorithmes à des fonctions de sécurité, y compris la signature, le hachage et le chiffrement. P M SP fonctionnera avec la puce C a p s t o n e (voir § 24.17).
24-i 2
« Pretty Good Privacy » (PGP)
24.12
613
« Pretty Good Privacy » (PGP)
P r e t t y G o o d P r i v a c y (P G P ) est un programme gratuit de protection du courrier électronique conçu à l’origine par Philip ZlMMERMANN [1654|J1. P G P utilise IDEA pour le chiffrement, R SA (avec des clefs allant jusqu’à 2047 bits) pour la gestion des clefs et les signatures digitales, et M D5 comme fonction de hachage à sens unique. Les clefs publiques aléatoires P G P utilisent un test de primalité probabiliste et ob tiennent leurs germes initiaux en mesurant les intervalles entre les touches frappées au clavier par l’utilisateur. P G P engendre des clefs ID E A aléatoires en utilisant la méthode présentée dans l’annexe C du document ANSI X 9.17 (voir § 8.1) [57], avec ID E A comme algorithme à clef secrète au lieu du DES. P G P chiffre également la clef privée de l’utilisateur en utilisant l’empreinte d’une phrase clef au lieu d’un mot de passe. Les messages chiffrés par P G P ont une structure de sécurité en couches. La seule chose qu’un cryptanalyste puisse apprendre d ’un message chiffré est l’identité de l’expéditeur, pour autant qu’il connaisse l’identificateur de la clef du destinataire. Ce n’est qu’après que le destinataire a déchiffré le message qu’il peut apprendre qui l’a signé, s’il est signé. Comparez cette approche à P E M qui laisse quand même un bon nombre d’informations dans l’en-tête sous forme non chiffrée concernant l’expéditeur, les destinataires et le message lui-même. L’aspect le plus intéressant de P G P est son approche à la gestion de clefs distribuée (voir § 8.12). Il n’y a pas d ’autorité de certification ; P G P a instauré à la place un climat de confiance. Chaque utilisateur engendre et distribue sa propre clef publique. Les utilisateurs signent mutuellement leur clefs publiques, créant ainsi une communauté d’utilisateurs de P G P interconnectés. Par exemple, Alice peut donner physiquement sa clef publique à Bernard. Il connaît Alice et donc signe sa clef publique. Puis il lui redonne la clef signée et en garde une copie. Quand Alice veut communiquer avec Christine, elle lui envoie une copie de la clef que Bernard a signée. Christine, qui a déjà la clef publique de Bernard (elle l’a eue à un autre moment) et qui fait confiance à Bernard pour certifier les clefs d’autres personnes, vérifie sa signature sur la clef d’Alice et l’accepte. Bernard a présenté Alice à Christine. P G P n ’a pas mis en place de politique en ce qui concerne la confiance ; les utilisateurs sont libres de décider à qui ils font confiance et à qui ils ne font pas confiance. P G P fournit les mécanismes pour associer la confiance aux clefs publiques et pour utiliser cette confiance. Chaque utilisateur a toute une collection de clefs publiques signées qu’il garde dans un fichier appelé a n n e a u d e c le fs p u b liq u e s . Chaque clef de ce réseau a un champ de validité de clef qui indique le niveau auquel l’utilisateur particulier fait confiance en la validité de la clef. Plus le niveau de confiance est élevé, plus l’utilisateur pense que la clef est valide. Un champ de confiance de signature indique le niveau de confiance accordé au signataire pour certifier les clefs publiques d ’autres utilisateurs. Enfin, un champ de confiance du propriétaire indique le niveau auquel l’utilisateur particulier fait confiance au propriétaire de la clef pour signer d’autres clefs publiques ; ce champ est géré manuellement par l’utilisateur. 11. P G P n ’est pas dans le dom aine public. Il porte un copyright de Philip ZlMMERMANN et il est disponible librem ent suivant les termes de la « “ C o p y le ft ” G e n e r a l P u b lic L ic e n s e » de la FREE S o f t w a r e F o u n d a tio n .
Chapitre 24
Exemples de réalisation
La figure 24 7 montre ce à quoi un tel modèle pourrait ressembler pour un utilisateur particulier, Alice. La clef d ’Alice est au sommet, la valeur de confiance du propriétaire est maximum. Alice a signé les clefs de Bernard, Christine, David, Etienne et Francis. Elle fait confiance à Bernard et à Christine, et partiellement confiance à David et à Etienne, pour signer les clefs publiques d ’autres personnes. De même, elle fait confiance à Gabrielle, même si elle n’a pas elle-même signé sa clef.
F
ig
. 2 4 .7
- Modèle de confiance de PGP
Deux signatures dignes de confiance peuvent être suffisantes pour certifier une clef. Alice pense que la clef de Karine est valide car David et Etienne l’ont signée. Ce n’est pas automatique avec P G P ; Alice peut régler son propre niveau de paranoïa. Ce n’est pas parce qu’Alice croit qu’une clef est valide qu’elle doit lui faire confiance pour signer les clefs d’autres personnes. Elle ne fait pas confiance à Francis pour signer les clefs publiques d ’autres personnes, même si elle a elle-même signé sa clef. Elle ne fait pas confiance en la signature de Jean sur la clef de Martin, ni en celle de Karine
24-13
Cartes à puce
615
sur la clef de Nathalie. La clef d ’Olivier ne marche nulle part sur le réseau; peut-être qu’Alice l’a eue sur un serveur de clefs. P G P pense que la clef n’est pas valide ; Alice doit soit déclarer la clef valide, soit décider de faire confiance à l’un des signataires de la clef. Bien entendu, rien n’empêche Alice d’utiliser la clef en laquelle elle n’a pas confiance. Le travail de P G P est de l’alerter que la clef n’est pas digne de confiance, pas d’empêcher les communications. Le lien le plus vulnérable de tout ce système est la révocation de clefs : il est impossible de garantir que personne n’utilisera une clef compromise. Si la clef privée d’Alice est volée, elle peut envoyer ce qu’on appelle un C E R T I F I C A T D E R É V O C A T I O N D E C L E F , mais comme la distribution des clefs est ad hoc et suit largement le bouche à oreille, il n’y a pas de garantie que ce certificat atteindra quiconque a sa clef publique sur son réseau. De plus, comme Alice doit signer le certificat de révocation avec sa clef privée, si elle 1’ a perdue, elle ne peut pas la révoquer. La dernière version de P G P est 2.6.2. Une nouvelle version, P G P 3.0 est prévue pour la fin 1995. Les changements dans la version 3.0 inclut des options pour les algorithmes DES, SH A et de clefs publiques, une séparation du chiffrement et de la signature des paires « clef publique / clef privée », une amélioration des procédures de révocation des clefs, de meilleures fonctions de gestion de réseau de clefs, un A P I pour intégrer P G P dans d ’autres programmes et un code de base complètement réécrit. P G P est disponible sous M S -D O S , U NIX, M a c i n t o s h , A m i g a et A t a r i . Il est gratuit pour un usage personnel, à usage non commercial, et est disponible sur de nombreux sites ftp d’Internet. Pour charger P G P du M IT , accédez à getpgp sur net-dist.mit.edu, répondez aux questions puis transférez et changez le nom dans la séance telnet. Il est aussi disponible sur ftp.ox.ac.uk, ftp.dsi.unimi.it, ftp.demon.co.uk, CO M PU SERVE, A O L , etc. Pour les utilisateurs commerciaux américains, P G P peut être acheté - avec licence - pour à peu près 100 dollars auprès de l’entreprise ViaCrypt, 9033 N 24th Ave., Phoenix, AZ, 85021 ; +1 (602) 944 0773 ; [email protected]. Plusieurs shareware sont disponibles pour aider à l’intégration de P G P sous M S -D O S , WIN DOWS, M a c i n t o s h et UNIX. Il existe plusieurs livres sur P G P [604, 1398, 1502]. Le code source a même été publié dans un livre [1655] dans le seul but de frustrer le Département d ’Etat américain qui soutient encore que le code source est exportable sur papier mais pas électroniquement. En supposant que vous faites confiance à ID E A , P G P est sans aucun doute le système de chiffrement le plus proche de la classe militaire.
24.13
Cartes à puce
Une carte à puce est une carte en plastique de la taille d’une carte de crédit avec une puce électronique. C ’est une vieille idée (les premiers brevets ont été déposés il y a 20 ans), mais des limitations pratiques ne les ont rendues faisables qu’il y a environ cinq ans. Depuis, elles ont littéralement explosé, surtout en Europe. Beaucoup de pays utilisent des cartes à puce dans les cabines téléphoniques. Il y a aussi des cartes de crédit à puce, ainsi que des cartes à puce pour d ’autres usages. Les compagnies américaines de cartes de crédit étudient cette technologie, et d’ici quelques années, les américains auront des cartes à puce dans leurs portefeuilles.
616
Chapitre 24
Exemples de réalisation
Une carte à puce contient un petit ordinateur (habituellement un microprocesseur à 8 bits), de la R A M (à peu près un quart de kilo-octet), de la R O M (environ 6 à 8 kilo-octets) et soit de l’E P R O M ou de l’E E P R O M (quelques kilo-octets). Les générations futures de cartes à puce auront sans aucun doute plus de capacité, mais des limitations physiques rendent son expansion difficile. La carte a ses propres système d’exploitation, programmes et données. (Ce qu’elle n’a pas est la puissance ; ce qu’elle obtient néanmoins lorsqu’on la branche à un lecteur.) De plus, elle est sûre. Dans un monde où vous ne pouvez pas faire confiance à l’ordinateur, au téléphone ou à quoi que ce soit de quelqu’un d’autre, vous pouvez toujours avoir confiance en une carte que vous gardez avec vous dans votre portefeuille. Les cartes à puce peuvent avoir différents protocoles et algorithmes cryptographiques préprogrammés. Elles peuvent être configurées en porte-monnaie électronique et rece voir ou dépenser de l’argent électronique. Elles peuvent opérer avec des protocoles d ’au thentification à divulgation nulle ; elles peuvent avoir leurs propres clefs de chiffrement. Elles pourraient signer des documents, déverrouiller des applications sur ordinateur. Quelques cartes à puce sont censées être inviolables ; cela protège souvent l’institution qui a fournit les cartes. Une banque ne voudrait sûrement pas que vous puissiez pirater ses cartes à puce afin de détourner de l’argent. Les cartes à puce sont très intéressantes et beaucoup d’information à leur sujet sont disponibles. Un bon article sur la cryptographie dans les cartes à puce est [673]. « CARTES » est une conférence qui se tient à Paris chaque mois d’octobre et « CardTech » se tient à Washington, D.C. en avril. Les tenues de deux autres confé rences sur les cartes à puce sont [35, 3]. Il y a des centaines de brevets sur les cartes à puce, la plupart déposés par des entreprises européennes. Un article intéressant sur les applications futures possibles (vérification d ’intégrité, pistes d’audit, protection contre la copie, argent électronique, adressages sûrs) est [1630].
24.14
« Public-Key Cryptography Stan dards » (PKCS)
Les PK C S, standards de la cryptographie à clef publique, sont les fruits d ’une tentative de R S A D a t a S e c u r i t y , I n c . pour fournir une interface standard industrielle pour la cryptographie à clef publique. D ’habitude, ce type de démarche est effectué par ANSI, mais, en considérant la situation politique en ce qui concerne la cryptographie, les gens de R SA D S I ont préféré le faire eux-même. En travaillant en collaboration avec de nombreuses entreprises, ils ont développé une série de standards. Certains sont compatibles avec d’autres, mais pas tous. Ce ne sont pas des standards dans le sens propre du terme ; aucun office de standar disation ne s’est réuni pour voter PK C S. C'est apparemment R SA D SI qui « détient le seul pouvoir de décision sur ses standards, et ils publierons des révisions en temps voulu » [811]. Néanmoins, il y a là beaucoup de choses intéressantes. Si vous ne savez pas quelle syntaxe ou quelle structure de données utiliser pour programmer de la cryptographie à clef publique, ces standards sont sans aucun doute aussi bon que n’importe quel autre. Qui plus est, comme ce ne sont pas de vrais standards, vous pouvez les modifier à volonté afin qu’ils répondent à vos besoins.
24-14
* Public-Key Cryptography Stan-
« dards » ('PKCS )
617
Les lignes suivantes décrivent brièvement chaque P K C S (PK C S # 2 et PK C S # 4 ont été inclus dans P K C S # 1 ) . PKCS # 1 [919] décrit une méthode pour le chiffrement et le déchiffrement R SA , principalement pour construire les signatures et les enveloppes électroniques décrites dans PK C S # 7 . Pour les signatures électroniques, le message est haché puis chiffré avec la clef privée du signataire. Le message et le hachage sont représentés ensemble comme on l’explique dans P K C S # 7 . Pour les enveloppes électroniques (messages chiffrés), le message est d’abord chiffré avec un algorithme à clef secrète, et la clef du message est chiffrée avec la clef publique du destinataire. Les message et clef chiffrés sont représentés ensemble conformément à la syntaxe de P K C S # 7 . Ces deux méthodes sont compatibles avec les standards PE M . P K C S # 1 décrit aussi une syntaxe, identique à celle de X .509 et de PE M , pour les clefs publiques et privées RSA et pour les trois algorithmes de signature (M D 2 et R SA , M D4 et R SA , M D5 et R S A ) signant les certificats. PK C S # 3 [921] décrit une méthode pour appliquer l’échange de clefs de « DiffieHellman ». PKCS # 5 [922] décrit une méthode pour chiffrer des messages avec une clef secrète dérivée d’un mot de passe. Elle utilise soit M D2 soit M D 5 pour dériver la clef du mot de passe, et chiffre avec le DES en mode C B C . Cette méthode est essentiellement vouée à chiffrer les clefs privées quand on les transfère d ’un système informatique vers un autre, mais peut être utilisée pour chiffrer des messages. PK C S # 6 [923] décrit une syntaxe standard pour les certificats à clef publique. La syntaxe est une sur-couche d’un certificat X.509, ainsi ce type de certificat peut être extrait si nécessaire. Bien plus que l’ensemble X .509, des qualités supplémentaires étendent le processus de certification au-delà de la seule clef publique. Celles-ci incluent d’autres informations, telle que l’adresse électronique. PK C S # 7 [924] est une syntaxe générale pour des données qui peuvent être chiffrées ou signées, telles que des enveloppes ou des signatures électroniques. La syntaxe est récursive, ainsi les enveloppes peuvent être empilées, ou quelqu’un peut signer des don nées déjà chiffrées. La syntaxe a aussi d’autres qualités, telle que la datation, pour être authentifiée avec le contenu du message. P K C S # 7 est compatible avec PE M et les messages signés et chiffrés peuvent être convertis en messages P E M sans aucune opéra tion cryptographique, et vice-versa. PK C S # 7 supporte de nombreuses architectures (PE M en est une) pour la gestion de clefs de certificats. PK CS # 8 [925] décrit une syntaxe pour l’information à clef privée (incluant une clef privée et un ensemble de qualités) et une syntaxe pour les clefs privées chiffrées. PK CS # 5 peut être utilisé pour chiffrer l’information à clef privée. PK C S # 9 [92G] définit les types de qualités sélectionnées pour les certificats étendus de PK C S # 6 , les messages signés électroniquement de PK C S # 7 et l’information à clef privée de P K C S # 8 . PK C S # 1 0 [920] décrit une syntaxe standard pour les demandes de certification. Une certification comprend un nom, une clef publique et (en option) un ensemble de qualités, collectivement signés par la personne à la demande de la certification. Les demandes de certification sont envoyées à une autorité de certification qui transforme la demande soit en un certificat à clef publique X.509, soit en un certificat P K C S # 6 . PK C S # 1 1 [927], le bon cryptographique au standard A P I, spécifie une interfaceprogramme appelée « Cryptoki » pour les matériels cryptographiques portables de
Chapitre 24
618
Exemples de réalisation
tout genre. « Cryptoki » présente un modèle commun de logique, permettant aux applications de réaliser des opérations cryptographiques sur du matériel portable sans connaître les détails de la technologie servant de base. Le standard définit aussi le profil des applications : ensembles d ’algorithmes qu’un matériel peut accepter. P K C S # 1 2 [928] décrit une syntaxe pour stocker dans un logiciel les clefs publiques d’un utilisateur, les clefs privées protégées, les certificats et d’autres informations cryp tographiques. Le but est de standardiser un dossier à clef secrète parmi toute une variété d’applications. Ces standards sont détaillés mais pas exhaustifs. Beaucoup de sujets sont hors de leurs champs d ’action : le problème de la nomination, des considérations noncryptographiques concernant la certification, les longueurs de clefs et les conditions de différents paramètres. Ce que le P K C S fournit sont un format pour transférer des données basées sur la cryptographie à clef publique et une infrastructure pour supporter ce transfert.
24.15
Système de paiement électronique universel
Le système de paiement électronique universel (UEPS pour « Universal Electronic Payment System ») est une carte à puce bancaire, à l’origine développée pour les parties rurales de l’Afrique du Sud, mais finalement adoptée par toutes les banques majeures du pays. Au début 1995, environ 2 millions de cartes ont été distribuées dans ce pays. Elle a aussi été adoptée en Namibie et est distribuée par au moins une banque en Russie. Le système procure une carte à débit sûre, bien adaptée dans des régions où le sys tème téléphonique déficient ne permet pas la vérification en ligne. Les clients et les commerçants ont des cartes ; les clients utilisent leurs cartes pour transférer de l’argent vers les commerçants. Ces derniers mettent alors leurs cartes dans un téléphone et déposent l’argent sur leurs comptes bancaires ; les clients peuvent mettre leurs cartes dans un téléphone et transférer de l’argent sur leur carte. Le but n’est pas de garder l’anonymat, mais d’empêcher la fraude. Voici le protocole de communication entre la cliente Alice et le marchand Bernard. (En fait, Alice et Bernard branchent juste leur carte dans une machine et attendent que la transaction se fasse.) Quand Alice a reçu sa carte pour la première fois, on lui a donné une paire de clefs K\ et K 2 ; la banque les calcule à partir de son nom et de quelques fonctions secrètes. Seules les cartes des commerçants ont les secrets nécessaires pour opérer avec les clefs des clients. 1° Alice envoie à Bernard son nom à elle, A, son nom à lui, B , et un nombre aléatoire, Ra, chiffré en utilisant le DES : d ’abord avec K 2 puis avec K\. Elle lui envoie aussi son nom en clair. A , E k 1 ( E k 2 ( A , B , Ra ))•
2° Bernard calcule K i et K 2 à partir du nom d ’Alice. Il déchiffre le message, confirme que A et B sont corrects, puis chiffre le second message en clair d’Alice avec K 2.
24-15
Système de paiement électronique universel
619
E k 2(A, B, Ra ). Bernard n’envoie pas ce message à Alice; 56 bits du texte chiffré deviennent K 3. Bernard envoie à Alice son nom à lui, son nom à elle et un autre nombre aléatoire, R b , chiffré en utilisant le DES : d’abord avec K 3 puis avec K\. E k i (E k 3(B ,A,Rb ))-
3° Alice calcule K 3 de la même manière que Bernard. Elle déchiffre le message de Bernard, confirme que B et A sont corrects, puis chiffre le message en clair de Bernard avec K 3. E k 3(B, A, Rb )Alice n’envoie pas ce message à Bernard; 56 bits du texte chiffré deviennent K, i- Alice envoie à Bernard son nom à elle, son nom à lui et un contrôle digital, C . Ce contrôle contient les noms de l’envoyeur et du destinataire, une date, un contrôle de nombre, un montant et deux C A M , tous chiffrés avec le DES : d’abord avec K 4 puis avec K\. Un des C A M peut être vérifié par la banque d’Alice, et l’autre peut seulement être vérifié par le centre d’autorisation. Alice débite son compte du montant correcte. E Kl (E k 4(A,B,C)). 4 ° Bernard calcule K 4 de la même manière que Alice. Si tous les noms et le contrôle correspondent, il l’accepte pour le paiement.
Un aspect très intéressant de ce protocole est que la clef de chiffrement pour chaque message dépend du message précédent. Chaque message double en tant qu’authentifiant de tous les précédents messages. Ceci implique qu’on ne peut pas rejouer un ancien message ; le destinataire ne pourrait jamais le déchiffrer. Je suis enthousiasmé par cette idée et espère qu’elle sera plus largement utilisée une fois qu’elle sera plus connue. Un autre aspect très intéressant de ce protocole est qu’il oblige les applications à être correctes. Si le concepteur de l’application n ’introduit pas correctement le protocole, il ne marchera pas. Les deux cartes gardent en mémoire le relevé de toutes les transactions. Quand les cartes sont mises en ligne pour communiquer avec la banque (quand le commerçant dépose son argent et que le client en retire), la banque charge ce relevé dans un but de contrôle. La puce résistante à l’investigation empêche les participants d’altérer les données; Alice ne peut pas changer la valeur de sa carte. Des recherches intensives fournissent les données pour identifier et tracer les transactions frauduleuses. U y a des secrets universels dans les cartes (les clefs C A M dans les cartes-clients, les fonctions pour convertir les noms des clients en K± et K 2 dans les cartes-commerçants) mais ils sont supposés être difficile à découvrir.
Chapitre 24
620
Exemples de réalisation
Ce schéma n’est pas supposé être parfait, simplement plus sûr que les traditionnels contrôles sur papier ou cartes de débit. La menace de la fraude ne vient pas de puis sances militaires rivales, mais de clients et commerçants opportunistes. UEPS protège contre ce type d ’abus. L ’échange de messages est un excellent exemple de protocole robuste : chaque message nomme les deux parties, inclut des informations uniques pour confirmer l’actualité et dépend explicitement de tous les messages précédents.
24.16
Clipper
La puce C l i p p e r (aussi appelée M Y K -7 8 T ) a été conçue par la NSA, est du type VLSI résistante à l’investigation et est dédié au chiffrement des conversations vocales ; c’est une des deux puces qui applique le standard de chiffrement par clefs sous dépôt (EES pour « Escrowed Encryption Standard ») du gouvernement américain [1173], VLSI Technologies, Inc. fabrique la puce, et Mykotronx, Inc. la programme. Pour commencer, la puce C l i p p e r sera intégrée dans le modèle 3600 du dispositif de sécurité du téléphone d ’A T & T (voir § 24.18). La puce utilise l’algorithme de chiffrement S K IP J A C K (voir § 13.12), conçu par la NSA et classé algorithme secret de chiffrement de clefs, en mode O F B seulement. L’aspect le plus controversé de la puce C l i p p e r , et de tout l’EES, est le protocole de dépôt de clef (voir § 4.14). Chaque puce a une clef spéciale, qui n’est pas nécessaire pour les messages. Cette clef est utilisée pour chiffrer une copie de la clef utilisée par chaque utilisateur pour chiffrer ses messages. Lors du processus de syncronisation, la puce C l i p p e r émettrice génère et envoie un champ d’accès de respect de la loi (L E A F pour « Law Enforcement Access Field ») à la puce C l i p p e r réceptrice. Le L E A F contient une copie de la clef de séance courante, chiffrée avec une clef spéciale (appelée clef d ’unité). Ceci permet au personnel du gouvernement12 de découvrir la clef de séance et ainsi d’écouter le contenu de la conversation. D ’après le directeur du N IST [802] : « Un système de « dépôt de clefs » est prévu de manière à ce que la « puce C l i p p e r » soit utilisée pour protéger la vie privée des citoyens américains respectueux des lois. Chaque dispositif contenant la puce aura deux « clefs » uniques, des nombres qui seront nécessaires aux agences autorisées du gou vernement pour déchiffrer les messages chiffrés avec le dispositif. Quand le dispositif sera fabriqué, les deux clefs seront déposées séparément dans deux bases de données de dépôt de clefs mises en place par l’attorney général. L’accès à ces clefs sera limité aux officiels du gouvernement qui disposent d’une autorisation légale pour placer une écoute. » Le gouvernement veut aussi encourager la vente de téléphones équipés de cette puce à l’étranger ; personne ne sait ce qui pourrait arriver à ces bases de données de dépôt de clefs. En laissant de côté la politique, la structure interne du LE A F vaut la peine que nous nous y attardions [802, 1174, 1596, 465, 114, 468]. Le LE A F est une chaîne de 128 bits qui contient assez d’informations pour permettre aux services de sécurité de trouver 12. N o te d u tra d u cte u r : il s ’a g it ici d u G o u v e rn e m e n t a m érica in , d u m oin s ju s q u ’ à p résent.
24-16
621
C l ip p e r
la clef de session, K s , en supposant que les deux agences d e d é p ô t de clefs en charge des bases de données coopèrent. Le L E A F contient un identifiant d’unité de 32 bits, U, unique pour la puce C l i p p e r . Il contient aussi la clef de séance courante de 80 bits chiffrée avec la clef d’unité unique de la puce, Kjj, et une somme de contrôle de 16 bits, C , appelée identifiant de dépôt. Cette somme de contrôle est une fonction de la clef de séance, de l’IV et probablement d’autres informations. Ces trois champs sont chiffrés avec une famille fixe de clefs, K f , partagée par toutes les puces C l i p p e r interopérables. La famille de clefs, les modes de chiffrement utilisés, les détails de la somme des contrôles et la structure exacte du L E A F sont tous secrets. Cela ressemble probablement à: E k , ( E K u ( K s ,U,C)) K f est programmé dans la puce C l i p p e r au niveau de l’usine. Cette clef est alors divi sée en deux (voir § 3.5) et est stockée dans deux bases de données de dépôt différentes, gardées par deux agences de dépôt différentes. Si Estelle veut obtenir K s à partir du L E A F , elle doit d’abord déchiffrer le LEAF avec Kp et retrouver U. Puis elle doit présenter un ordre judiciaire à chaque agence de dépôt, qui chacune lui donnera une moitié de K f pour le U donné. Estelle combine par ou exclusif les deux moitiés pour obtenir K f , puis elle utilise K f pour obtenir K s , et K s pour espionner la conversation. La somme de contrôle est conçue de façon à ce que personne ne puisse contourner ce schéma ; la puce C l i p p e r réceptrice ne déchiffrera pas si cette somme de contrôle ne correspond pas. Néanmoins, il n’y a que 216 valeurs possibles de sommes de contrôle, et un faux LE A F avec une somme de contrôle correcte mais avec une mauvaise clef peut être trouvé en à peu près 42 minutes [195]. Ce qui n’est pas d’une très grande efficacité pour les conversations vocales en mode C l i p p e r . D u fait que le protocole d’échange de clefs n’est pas partie intégrante de la puce C l i p p e r , une attaque exaustive de 42 minutes doit être menée après l’échange de clefs ; elle ne peut pas être menée avant l’appel téléphonique. Cette attaque peut fonctionner lors de transmissions de facsimilés ou avec la carte Fortezza (voir § 24.17). En principe, la puce C l i p p e r est résistante à l’investigation « contre des adversaires très sophistiqués et très bien financés » [1174], mais des rumeurs disent que les « Sandia National Laboratories » ont réussi. Même si ces rumeurs sont fausses, je suis persuadé que le plus grand constructeur de puces dans le monde peut violer la puce C l i p p e r ; c’est juste une question de temps avant que quelqu’un avec la bonne combinaison de ressources et d’éthiques n’y arrive. D’énormes problèmes de respect de la vie privée sont associés à ce schéma. Il y a de nombreux groupes défenseurs de la liberté civile qui luttent activement contre tout mécanisme de dépôt de clef qui donnerait le droit au gouvernement d’espionner les citoyens. Mais le problème est que cette idée n’est jamais passée par le Congrès; le NIST a publié le standard de chiffrement par clefs sous dépôt en tant que FIPS [1173], court,-cicuitant ainsi cet irritant processus législatif. A l’heure actuelle, il semble que l’EES meurt d’une mort lente et douce, mais les standards ont leur manière de vous surprendre. Le tableau 24.2 donne la liste des différentes agences participant à ce programme. Quelqu’un veut-il porter un jugement critique sur le fait que les deux agents de dépôts soient dans la branche exécutive, ou sur le fait qu’ils ne connaissent rien à propos des demandes d ’écoutes et ne font que les approuver aveuglément, ou sur le fait que le
Chapitre 24
622
Exemples de réalisation
gouvernement impose un algorithme secret comme un standard commercial?
Tab.
24.2 - A g e n c e s
p a r t ic ip a n t
à l ’ EES
Ministère de la Justice — Sponsor du système et agent de famille de clefs NIST — Directeur de programme et agent de dépôt FBI — Utilisateur du déchiffrement et agent de famille de clefs Ministère des finances — Agent de dépôt NSA — Développeur de programme De toutes façons, l’appication de C l i p p e r soulève déjà assez de problèmes pour s’in terroger de sa valeur en com' de justice. Souvenez-vous, C l i p p e r ne fonctionne qu’en mode O FB. Malgré tout ce qu’on a pu vous dire de contraire, cela ne garantit pas l’intégrité et l’authentification. Imaginez qu’Alice soit en procès et qu’un appel télé phonique chiffré en mode C l i p p e r soit une pièce à conviction. Alice affirme qu’elle n’a jamais fait cet appel ; la voix n’est pas la sienne. L’algorithme de compression du téléphone est si mauvais qu’il est dur de pouvoir reconnaître la voix d’Alice, mais l’ac cusation soutient que comme seule la clef sous dépôt d ’Alice peut déchiffrer l’appel, alors il a dû être passé à partir de son téléphone. Alice affirme que l’appel a été faussé de la manière suivante [993, 1351] : ayant les textes chiffré et en clair, il est possible de les combiner par ou exclusif pour obtenir le flux de codons. Celui-ci peut alors être combiné par ou exclusif avec un texte en clair entièrement différent pour former un texte chiffré faussé, qui peut ensuite être convertit en texte en clair faussé quand il passe par le déchiffrement C l i p p e r . Vrai ou faux, cet argument pourrait facilement instaurer le doute dans l’esprit des jurés afin de ne pas retenir l’appel téléphonique comme preuve. Une autre attaque, appelée attaque « squeeze », permet à Alice de piéger Bernard. Voici comment [577] : Alice appelle Bernard en utilisant C l i p p e r . Elle sauvegarde une copie du L E A F de Bernard ainsi que de la clef de séance. Puis elle appelle Christine (qu’elle sait mise sur écoute). Pendant le réglage des clefs, Alice force la clef de séance à être identique à celle qu’elle a utilisée avec Bernard ; cela exige de pirater le téléphone, mais ce n’est pas dur. Enfin, au lieu de lui envoyer son L E A F , elle envoie celui de Bernard. Le LE A F est valide, donc le téléphone de Christine ne remarquera rien. Maintenant, elle peut dire ce qu’elle veut à Christine; quand la police déchiffrera le LE A F, elle trouvera que c’est celui de Bernard. Même si Bernard n’a pas été piégé par Alice, le simple fait qu’il puisse dire cela en cour de justice contrecarre le but du schéma. Les autorités représentant la loi aux Etats-Unis ne devraient pas pouvoir rassembler des informations dans des enquêtes criminelles qui sont inutiles lors d’un jugement. Même si le dépôt de clefs était une bonne idée, le L E A F en est une mauvaise application.
24.17
Capstone
C a p s t o n e (aussi appelée M Y K -80) est l’autre puce cryptographique VLSI développée par la NSA qui applique le standard de chiffrement par clefs sous dépôt du gouverne ment américain [1173]. C a p s t o n e inclut les fonctions suivantes [1170, 468] :
- L’algorithme
S K IP J A C K
dans les quatre modes basiques: E C B , C B C , C FB et
24-18
Modèle 3600 du dispositif de sécurité du téléphone d’A T & T
623
OFB; - Un algorithme d ’échange de clefs à clef publique K E A , probablement D i f f i e H ellm an ;
- L’algorithme de signature numérique D S A ; - L ’algorithme de hachage sûr SHA ; - Un algorithme d’exponentiation polyvalent ; - Un générateur de nombres aléatoires polyvalent utilisant une vraie source de bruit blanc. C a p s t o n e fournit la fonctionnalité cryptographique nécessaire pour un commerce élec tronique sûr et pour d’autres applications informatiques. La première application de C a p s t o n e est dans la carte P C M C IA appelée « Fortezza ». (Autrefois, elle s’appelait « Tessera » jusqu’à ce qu’une compagnie appelée Tessera, Inc. se plaigne.) La NSA a pensé rallonger la somme des contrôles du L E A F de C a p s t o n e dans les versions de commercialisation des cartes « Fortezza », afin de contrecarrer les attaques exaustives contre le L E A F dont nous avons déjà discuté. A la place, ils ont ajouté une fonction qui annule la carte après 10 mauvais LE A F. Cela ne fait qu’augmenter le temps nécessaire pour trouver un L E A F valide de 10 pourcents, à 46 minutes. Cela ne m’impressionne pas.
24.18
Modèle 3600 du dispositif de sécurité du téléphone d’AT& T
Le dispositif de sécurité du téléphone d ’A T & T (T S D pour « Téléphoné Security Devi ce ») est un téléphone C l i p p e r . En réalité, il existe quatre modèles de T S D . Un premier inclut la puce C l i p p e r , un second renferme un algorithme de chiffrement exportable breveté A T & T , un troisième renferme un algorithme breveté pour un usage domes tique plus un algorithme exportable, et un quatrième inclut les algorithmes C l i p p e r , domestique et exportable. Les T SD utilisent une clef de séance différente à chaque appel téléphonique. Une paire de T S D génère une clef de session en utilisant l’echange de clefs D i f f i e - H e l l m a n , indépendant de la puce C l i p p e r . Comme D i f f i e - H e l l m a n n’intègre pas d’authenti fication, le T SD a deux méthodes pour déjouer une attaque de l’intercepteur. La première est un écran. Le TSD hache la clef de session et affiche cette empreinte sur un petit écran avec un nombre hexadécimal à quatre chiffres. Les personnes qui conversent devraient confirmer que leurs écrans affichent la même chose. La qualité d’écoute est assez bonne pour pouvoir reconnaître la voix de son correspondant. Estelle a toujours une attaque possible. Imaginez-la au beau milieu de la converstation entre Alice et Bernard. Elle utilise un T S D en ligne avec Alice et un T SD modifié en ligne avec Bernard ; entre les deux, elle relie les appels téléphoniques. Alice essaie d’être prudente. Elle génère une clef comme d’habitude, excepté qu’Estelle se fait passer pour Bernard. Estelle obtient la clef, et en utilisant le T S D modifié, elle force la clef qu’elle
624
Chapitre 24
Exemples de réalisation
génère avec Bernard à avoir la même valeur de hachage. Cette attaque ne semble peutêtre pas être probable, mais le T S D utilise une variante du protocole à cliquets pour la déjouer. Le T S D génère des nombres aléatoires en utilisant une source de bruits et un ampli ficateur à rétroaction numérique. Ceci créé un flot de bits, qui est ensuite transformé en bruit blanc par filtrage au moyen d’un processeur de signaux numériques. Malgré tout cela, le manuel du TSD ne parle absolument pas de sécurité. En fait, il dit [75] : « A T & T ne garantit pas que le T SD résistera à une attaque cryptanalytique d ’une transmission chiffrée menée par une agence gouvernementale, ses agents, ou une tierce personne. De plus, A T & T ne garantit pas que le T SD résistera à une attaque utilisant des méthodes qui court-circuitent le chiffrement. »
Chapitre 25
Politique 25.1
« National Security Agency » (NSA)
La NSA(les jeux de mots « No Such Agency » ou « Never Say Anything » 1 ne sont plus souvent utilisés) est l’organisme officiel de sécurité du gouvernement américain. Le pré sident Harry T r u m a n l’a créée en 1952 sous le Département de la Défense et, pendant de nombreuses années, son existence même a été gardée secrète. La NSA renseigne sur les signaux, son mandat est d'écouter et de décoder toutes les communications entrant aux Etats-Unis et en sortant, qui pourraient présenter un intérêt pour la sécurité du pays. Les paragraphes suivants sont extraits de la charte originelle de la NSA, signée par le Président T r u m a n en 1952 puis classée pendant de nombreuses années [1543] : « La mission C O M IN T de l’Agence nationale de sécurité (N SA) est de pro curer une organisation efficace et unifiée ainsi qu’un contrôle des activités de renseignement des communications des Etats-Unis dirigées contre des gouvernements étrangers, afin de prévoir une politique et des procédures opérationnelles adaptées. Tel qu’utilisé dans cette directive, le ternie « ren seignement des communications » ou « C O M IN T » (pour « Communication Intelligence ») comprend toutes les procédures et méthodes utilisées pour l’interception de communications autres que la presse étrangère et les émis sions de propagande, ainsi que l’obtention d ’informations de telles com munications par une autre personne que son destinataire, mais proscrit la censure de même que la production et la dissémination de renseignements. « La nature spéciale des agents du C O M IN T implique qu’ils soient, en tout point, considérés hors du cadre des autres activités générales de ren seignement. Les ordres, directives, politiques ou recommandations d’une quelconque authorité de la Branche Exécutive concernant le rassemble ment, la protection, la sécurité, le maniement, la dissémination ou l’uti lisation de renseignements, et/ou de matériels classés, ne doivent pas être applicables aux agents du C O M IN T , à moins que ce ne soit spécifique ment, mentionné et ordonné par une authorité départementale compétente 1. Note du traducteur : « Surtout pas une telle agence » et « N’avouez jamais rien ».
626
Chapitre 25
Politique
représentée au Bureau. Les autres directives du National Security Council Intelligence au Directeur de la Central Intelligence et les directives qui en découlent doivent être considérées comme non-applicables aux activités du C O M IN T , à moins que le National Security Council ait rendu sa directive spécifiquement applicable au C O M IN T . » La NSA mène de la recherche en cryptologie, à la fois pour concevoir des algorithmes sûrs afin de protéger les communications américaines et pour concevoir des techniques de cryptanalyse permettant d ’écouter les communications des autres. La NSA est connue pour être le plus gros employeur de mathématiciens au monde ; elle est égale ment le plus gros acheteur de matériel informatique au monde. La N SA possède une expertise cryptographique qui est probablement en avance de nombreuses années sur ce qui se fait de mieux dans le domaine public (en algorithmes, mais probablement pas en protocoles), et elle peut certainement casser de nombreux systèmes utilisés en pratique. Mais, pour des raisons de sûreté nationale, presque toutes les informations concernant la NSA, même son budget, sont classées secrètes. (Son budget pourrait s’élever à 13 milliards de dollars par an, incluant la participation militaire dans les projets et le personnel de la N SA, et pourrait employer 16000 personnes.) La NSA utilise sa puissance pour restreindre la disponibilité de la cryptographie au sein du public évitant ainsi que d ’autres nations puissent employer des méthodes de chiffrement que la NSA ne peut pas casser. James MASSEY décrit cette lutte entre la recherche académique et la recherche militaire en cryptographie [1013] : « Si l’on considère que la cryptographie est la prérogative du gouverne ment, on accepte que la plupart de la recherche en ce domaine se déroule derrière des portes closes. Sans aucun doute, le nombre de travailleurs enga gés aujourd’hui dans ce type de recherche cryptologique dépasse largement le nombre de ceux engagés dans la recherche cryptologique ouverte. Ce n’est que depuis 10 ans, en fait, que la recherche cryptologique ouverte se répand. Il y a eu, et il continuera d’y avoir, des conflits entre ces deux com munautés de recherche. La recherche ouverte est une quête commune de la connaissance qui dépend de façon vitale du libre-échange des idées par le biais des présentations lors des conférences ou des publications dans les journaux scientifiques. Mais est-ce qu’une agence gouvernementale, char gée de casser les algorithmes de chiffrement des autres nations, peut en courager la publication d ’un algorithme de chiffrement qu’elle ne peut pas casser? Est-ce qu’un chercheur peut en gardant bonne conscience, publier un tel algorithme qui pourrait miner l’efficacité des casseurs d’algorithmes de chiffrement de son propre gouvernement? On pourrait argumenter que la publication d’un code dont il est prouvé qu’il est sûr forcerait tous les gouvernements à se comporter en gentlemen, mais il faut être conscient du fait que la recherche ouverte en cryptologie est lourde de considérations politiques et éthiques d ’une importance nettement plus grande que dans la plupart des autres domaines scientifiques. Le miracle n’est pas qu’il y ait eu conflits entre les agences gouvernementales et les chercheurs publics en cryptologie mais plutôt que ces conflits (du moins ceux dont on a connais sance) aient été si peu nombreux et si modérés. » Jam es B A M FO R D a écrit un livre fascinant sur la
NSA: « The Puzzle Palace » [86]
25.2
« National Computer Security Center » ( N C S C )
récemment mis à jour par B a m f ORD et Wayne M
adsen
627 [87]
« Commercial COM SEC Endorsement Program » (CCEP) Le C C E P qui est un programme d’approbation commerciale, de nom de code Overtake, est une initiative de la NSA prise en 1984 afin de faciliter le développement d’ordina teurs et de produits de communications munis d’une cryptographie intégrée [92, 1165], Les militaires s’étaient toujours offerts ce genre de choses et cela était très cher. La NSA pensait que si des constructeurs pouvaient vendre des équipements à la fois aux militaires et aux utilisateurs civils, même outre Atlantique, les prix baisseraient et tout le monde en bénificierait. Ils n’habiliteraient plus d’équipement selon le Standard Fédéral 1027 et le C C E P pourrait fournir des équipement cryptographiques approuvés par le gouvernement [711]. La NSA a développé une série de modules cryptographiques pour diverses utilisations. Des Algorithmes différents étaient utilisés dans les modules pour différentes applica tions, et les constructeurs étaient capable de retirer un module et de le remplacer par un autre en fonction du client destinataire. Il y avait des modules à usage militaire (Type I), des modules à usage gouvernemental « non-classé mais sensible » (Type II), des modules destinés aux sociétés (Type III) et des modules destinés à l’export. Le tableau 25.1 résume les différents modules, applications et noms.
Tab.
25.1 - M
Application Voix/données à faible vitesse Ordinateur Données à grande vitesse Prochaine Génération
odules
CCEP
Type I Winster Tepache Foresee Countersign I
Type II Edgeshot Bulletproof Brushstroke Countersign II
Ce programme est toujours en vigueur, mais n’est jamais devenu populaire en dehors du gouvernement. Tous les modules étaient inviolables, tous les algorithmes étaient classés secrets et il fallait vous procurer vos clefs auprès de la NSA. Les sociétés n ’ont jamais aimé l’idée d’utiliser des algorithmes classés secrets dictés par le gouvernement. On pourrait penser que la NSA aurait appris cette leçon et ne se serait pas lancée dans les Clipper, Skipjack et autres puces de chiffrement par clefs sous dépôt.
25.2
« National Computer Center » (NCSC)
Security
Le « National Computer Security Center » est la branche de la NSA responsable des programmes informatiques sûrs du Gouvernement américain. Actuellement, le centre évalue les produits commerciaux de sécurité (à la fois logiciels et matériels), parraine et publie la recherche, développe des directives techniques et offre des conseils, du support et de la formation en général. Le NCSC édite le fameux « O r a n g e B o o k » [471], Son titre exact est « Department of Defense Trusted Computer System Evaluation Criteria » mais c ’est long à dire, et
628
Chapitre 25
le livre a une couverture orange. L ’O
range
B
ook
Politique
tente de définir les exigences en
matière de sécurité, donne au x fabricants d ’o rdinateurs un m oyen o b je ctif de mesurer le niveau de sécurité de leurs systèmes et les aide à personnaliser leurs produits de sécurité. Il se concentre sur la sécurité inform atique et ne dit vraim ent pas grand chose à propos de cryptographie. L ’O r a n g e B o o k définit quatre grandes divisions de niveau de protection de sécurité. Il définit également des classes de protection au sein de certaines de ces divisions. Elles sont résumées dans le tableau 25.2.
T
ab
.
25.2 - O r a n g e B o o k C
la ssific a tio n s
D : Sécurité minimale C : Protection discrète C l : Protection par sécurité discrète C2 : Protection par contrôle d ’accès B : Protection obligatoire B I : Protection par sécurité étiquetée B2 : Protection structurée B3 : Domaines de sécurité A : Protection vérifiée A l : Conception vérifiée Quand les fabricants disent des choses comme « nous offrons la sécurité C2 », c’est de cela qu’ils parlent. Pour plus d’informations à ce propos, lisez [1367]. Le modèle de sécurité informatique utilisé dans ces critères s’appelle le modèle B e l l - L a P a d u l a [108, 107, 109, 110].
Le N CSC a publié toute une série de livres sur la sécurité informatique, parfois appelés les livres arc-en-ciel (« Rainbow Books », les couvertures ont chacune une couleur diffé rente). Par exemple, « Trusted Network Interprétation of the Trusted Computer System Evaluation Criteria » [1148], parfois appelé R e d B o o k , donne une interprétation de I’ O r a n g e B o o k pour les réseaux et les équipements de réseau. Le « Trusted Database Management System Interprétation of the Trusted Computer System Evaluation Crite ria » [1150] — je ne peux même pas commencer à décrire la couleur de sa couverture
— fait la même chose pour les bases de données. Il y a ainsi plus de trente de ces livres l’heure actuelle, certains avec une couverture de couleur hideuse. Pour commander un jeu complet des R a i n b o w B o o k s , écrivez au Director, National Security Agency, INFOSEC Awareness, Attention: C81, 9800 Savage Road, Fort George G. Meade, MD 20755-6000, USA, Tél: +1 (301) 766-8729. Ne leur dites pas que c ’est moi qui vous envoie. à
25.3
« National Institute of Standards and Technology » (NIST)
Le NIST est l’Institut national des standards et de la technologie, une division du Département du Commerce. Avant 19 88 , il était dénommé « Bureau national de nor
25.3
National Institute of Standards and Technology » ('NIST )
629
malisation » (« National Bureau of Standards » (N B S)). Par le biais de son laboratoire « Computer Systems Laboratory » (C SL), le N IST fait la promotion de standards ouverts et de l’interfonctionnement qui, ils l’espèrent, va favoriser le développement économique de l’industrie informatique américaine. cette fin, le N IST publie des standards et des directives qu’il espère voir adoptés par tous les systèmes informa tiques aux Etats-Unis. Les standards officiels sont publiés sous forme de publications dénommées FIPS (« Fédéral Information Processing Standards »). Si vous voulez des copies des FIPS (ou de toute autre publication du N IST), contactez le National Technical Information Service (NTIS), U.S. Department o f Commerce, 5285 Port Royal Road, Springfield, VA 22161, USA, Tél: +1 (703) 487-4650; ou visitez le site gopher. //csrc.ncsl.nist.gov. Quand le Congrès américain a fait passer le « Computer Security Act » en 1987, le NIST fut mandaté pour définir des standards garantissant la sécurité des informations sensibles mais non classées pour les systèmes informatiques gouvernementaux2. Cet acte autorise le N IST à travailler avec d ’autres agences gouvernementales et l’industrie privée pour évaluer les propositions de normalisation technologique. Le N IST publie des standards pour les fonctions cryptographiques. Les agences gou vernementales américaines doivent les utiliser pour les informations sensibles mais non classées. Souvent, le secteur privé adopte également ces standards. Le N IST a publié le DES, le DSS, le SHS et le EES. Tous ces algorithmes ont été développés avec l’aide de la NSA, allant de l’analyse du DES jusqu’au design du DSS et du SHS en passant par l’algorithme Skipjack du EES. Certaines personnes ont critiqué le N IST pour avoir donné trop de contrôle à la NSA sur ces standards, car les intérêts de la NSA ne sont pas forcément les mêmes que ceux du NIST. On ignore à quel point la NSA a influencé la conception et le déve loppement de ces algorithmes. Etant donné les ressources limitées du N IST aussi bien en personnel qu’en budget ou en matériel, l’intervention de la NSA est probablement considérable. La NSA a des ressources significatives à mettre à contribution, y compris des équipements informatiques qui n’ont pas leur pareil. Le « protocole d’accord » (« Mémorandum of understanding » (M O U )) officiel entre les deux agences est le suivant : PROTOCOLE D ’ACCORD ENTRE LE DIRECTEUR DE L’INSTITUT NATIONAL DES STANDARDS ET DE LA TECHNOLOGIE ET LE DIRECTEUR DE L’AGENCE NATIONALE DE SÉCURITÉ QUANT À L’APPLICATION DU DROIT PUBLIC 100-235 Reconnaissant que: « A. En vertu de la section 2 du « Computer Security Act » de 1987 (Droit Public 100-235), (l’acte), l’Institut national des standards et de la techno logie (NIST) est responsable devant le gouvernement fédéral pour : « 1. Développer des standards et des recommandations techniques, de gestion, physiques, et administratifs pour la sécurité et la confidentialité à faible coût des informations sensibles dans les systèmes informatiques fédéraux tels que définis par l’Acte ; et : « 2. S’inspirer à ce propos des recommandations techniques en matière de sécurité informatique de l’Agence nationale de sécurité (NSA) quand 2. Les inform ations classées et les données qui sont définies par le « W a r n e r A m e n d a ie n t » sont sous la ju rid iction de la N SA .
630
Chapitre 25
Politique
cela est approprié, « B. En vertu de la section 3 de l’Acte, le NIST doit coordonner ses ac tivités en étroite collaboration avec les autres agences et services, y compris la NSA, pour garantir : « 1. l’utilisation maximale de tous les programmes, des études et des rapports existants et planifiés ayant trait à la sécurité et à la confidentialité des systèmes informatiques, de façon à éviter des doubles emplois coûteux et inutiles; et, « 2. autant que possible, la cohérence et la compatibilité des standards développés par le NIST dans le cadre de l’ Acte soient avec les standards et les procédures développés pour la protection des informations secrètes (classées) dans les systèmes informatiques fédéraux, « C. en vertu de l’Acte, le Secrétaire d ’Etat au Commerce a la res ponsabilité, qu’il délègue au directeur du NIST, de désigner les membres du Conseil de la sécurité et de la confidentialité informatique (« Computer System Security and Privacy Advisory Board »), dont l’un, au moins, doit appartenir à la NSA « En conséquence, pour servir les objectifs de ce protocole d’accord, le directeur du NIST et le directeur de la NSA conviennent par la présente de ce qui suit : « I. Le NIST s’engage à : « 1. Désigner au moins un représentant choisi par le directeur de la NSA dans le Conseil de la sécurité et de la confidentialité informatique. « 2. S’inspirer des recommandations en matière de sécurité des systèmes informatiques développées par la NSA, pour autant que le NIST considère que de telles recommandations sont compatibles avec les exigences de pro tection d ’informations sensibles dans les systèmes informatiques fédéraux. « 3. Reconnaître la cote résultant de l’évaluation des systèmes sûrs dans le cadre du « programme des critères d’évaluation de la sécurité des systèmes informatiques sûrs » sans requérir une nouvelle évaluation. « 4. Développer des standards de télécommunications sûres pour la pro tection des données informatiques sensibles non classées, en s’inspirant, dans la mesure du possible, de l’expérience et des produits de la NSA et ce, de manière efficace en temps et en argent. « 5. Eviter les doubles emplois là où cela est possible en concluant des accords de soutien mutuel avec la NSA. « 6. Requérir l’aide de la NSA pour toute matière liée aux algorithmes et aux techniques cryptographiques, notamment la recherche, le développe ment, l’évaluation ou l’acceptation. « II. La NSA s’engage à: « 1. Fournir au NIST les recommandations techniques en technologies sûres, en sécurité des télécommunications et en identification individuelle qui peuvent être utilisées, de manière effective quant au coût, pour protéger des données informatiques sensibles. « 2. Mener ou prendre l’initiative de programmes de recherche et dé veloppement en tecnnologies liées à la sécurité, en sécurité des télécommu nications, en techniques cryptographiques et en méthodes d ’identification
25.3
« National Institute of Standards and Technology » ( N I S T j
individuelle. « 3. D ’être à l’écoute des demandes du NIST en matière d ’aide pour toutes les matières liées aux algorithmes et aux techniques cryptogra phiques, notamment la recherche, le développement, l’évaluation ou l’ac ceptation. « 4. Appliquer les standards et participer à l’acceptation des produits pour les applications informatiques de sécurité couvertes par la section 23.15 (10 USC) (l’amendement Warner). « 5. A la requête des agences fédérales, de leur contractants et des autres entités subventionnées par le gouvernement, d’assurer l’évaluation du risque d’attaque par des agents hostiles des systèmes informatiques fédéraux, et de fournir aide technique et recommandations quant aux produits acceptés pour les applications des systèmes de sécurité visant à lutter contre ces attaques. « III. Le NIST et la NSA s’engagent à: « 1. Examiner conjointement les projets pour la sécurité et la confiden tialité des systèmes informatiques soumis au NIST et à la NSA en accord avec la section 6(b) de l’Acte. « 2. Echanger les standards techniques et les recommandations néces saires pour réaliser les objectifs de l’Acte. « 3. Collaborer pour atteindre les objectifs de ce protocole avec la plus grande efficacité possible, en évitant les doubles emplois inutiles. « 4. Entretenir un dialogue ouvert pour garantir que chaque organi sation reste au courant des technologies et des thèmes naissants affectant l’automatisation de la sécurité de l’information dans les systèmes informa tiques. « 5. Créer un groupe de travail technique qui examinera et analysera les sujets d’intérêt mutuel relevant de la protection des informations sensibles ou non classées. Le groupe devrait être composé de six employés fédéraux, trois choisis par le NIST et trois choisis par la NSA et il serait augmenté si nécessaire par des représentants des autres agences. Les sujets pourront être proposés au groupe par le sous-directeur à la sécurité de l’information de la NSA, ou pourront être soulevés et traités par le groupe lui-même avec l’approbation du sous-directeur à la sécurité de l’information de la NSA et du sous-directeur du NIST. Pendant la période d ’évaluation d’un sujet soumis au groupe soit par le sous-directeur à la sécurité de l’information de la NSA soit par le sous-directeur du NIST, le groupe fournira des rapports sur l’état d ’avancement et des plans pour les éventuelles analyses futures. « 6. Echanger des plans de travail sur une base annuelle pour tous les projets de recherche et de développement relevants de la protection des sys tèmes qui traitent des informations sensibles ou non classées, y compris les technologies sûres, pour la préservation de l’intégrité et de la disponibilité des données, la sécurité des télécommunications et les méthodes d’identifi cation individuelles. Les mises à jour des projets seront échangées tous les trimestres et les évaluations des projets seront fournies à l’autre partie sur demande. « 7. Garantir l’analyse par le groupe de travail technique, avant toute
631
632
Chapitre 25
Politique
divulgation publique, de toutes les matières concernant les techniques de sécurité des systèmes développés pour la protection d ’informations sensibles dans les systèmes informatiques fédéraux, afin de garantir qu’ils sont com patibles avec la sécurité nationale des Etats-Unis. Si le NIST et la NSA ne sont pas en mesure de conclure sur un tel sujet dans les 60 jours, l’une des agences peut décider de soumettre le cas au Secrétaire d ’Etat à la Défense ou au Secrétaire d ’Etat au Commerce. Il est convenu qu’un tel cas pourra être soumis pour décision au président [des Etats-Unis] par le biais de la NSC. Aucune action ne devra être entreprise sur un tel cas tant que la décision n’est pas prise. « 8. Spécifier des accords d ’organisation additionnels dans des annexes au présent protocole tels que convenus par la NSA et le NIST. « IV. Chaque partie peut mettre fin au présent protocole d ’accord moyennant un préavis écrit de six mois. Le présent protocole d ’accord entre en application à dater de l’approbation par les deux signataires. » /s i g n é / RAYMOND G. KAM M ER Directeur intérimaire, National Institute o f Standards and Technology, 24 Mars 1989 W . O. STUDEMAN Vice-amiral, U.S. Navy ; Directeur, National Security Agency, 23 Mars 1989
25.4
RSA Data Security, Inc.
R SA D a t a S e c u r i t y , I n c . (R S A D S I)a été fondée en 1982 pour développer, octroyer des licences et commercialiser le brevet R SA . Elle offre quelques produits commerciaux, dont un logiciel mono-station de sécurité pour courrier électronique et diverses biblio thèques cryptographiques (disponibles soit sous forme de code source soit sous forme binaire). R SA D SI commercialise également les algorithmes à clef secrète RC2 et RC4 (voir § 13.8). R SA L a b o r a t o r i e s , un laboratoire de recherche associé à RSADSI, effectue des recherches sur la cryptographie fondamentale et fournit des services de consultation en cryptographie. Toute personne intéressée par ces brevets ou ces produits doit contacter le Director of Sales, RSA Data Security, Inc., 100 Marine Parkway, Redwood City, CA 94065, USA, Tél: +1 (415) 595-8782, Fax: +1 (415) 595-1873.
25.5
« Public Key Partners » (PKP)
Les (PKP) sont « les partenaires de la clef publique ». Les cinq brevets du tableau 25.3 sont détenus par (PKP) de Sunnyvale, Californie, qui est un partenariat entre R SA D SI et C a r o - K a h n , I n c . - compagnie parente de C y l i n k . (R SA D SI détient 65 pourcent des profits et C a r o - K a h n 35 pourcent.) P K P affirme que ces brevets, et plus parti culièrement le 4218 582, s’appliquent à toutes les applications de cryptographie à clef publique. Dans [576], P K P écrit : « Ces brevets [4 200 770, 4 218 582, 4 405 829 et 4 424 414] couvrent toutes
25.5
« Public Key Partners » ( 'P K P )
Ta
b
.
Numéro de brevet 4200 770
25.3 - Les brevets de P u b l i c K Date 29/3/80 19/8/80
ey
Inventeurs H ellm M
4 218 582
633
an
, D
iffie,
Couverture du brevet Echange de clef D iffie - H
er kle
H ellm
Partners
an
, M
er kle
Empilements M
4405 829
20/9/83
R
iv e s t ,
A
d lem an
Sh a m ir ,
4424414
3 /3 /8 4
H ellm
4995082
19/2/91
Sch n o r r
an
, P
o h lig
ellm an
erkle
-H
ellm an
R SA P
o h lig - H e l l m a n
Signatures de S c h n o r r
les méthodes connues dans la pratique de l’art de la clef publique, y compris les variantes connues collectivement sous le nom E l G a m a l . « Du fait de la large acceptation des signatures numériques R SA à travers la communauté internationale, P u b l i c K e y P a r t n e r s appuie for tement son incorporation dans un standard de signature numérique. Nous affirmons à toutes les parties intéressées que P u b l i c K e y P a r t n e r s res pectera tous les règlements d’ ANSI et d ’IEEE en ce qui concerne la dispo nibilité des licences pour pratiquer cet art. Spécifiquement, en soutien au standard de signature numérique R SA qui pourrait être adopté, P u b l i c K e y P a r t n e r s donne par la présente sa garantie que des licences pour pra tiquer l’art des signatures R SA seront octroyées en des termes raisonnables et à des conditions fondées sur des bases non discriminatoires. » La véracité de ceci dépend de votre interlocuteur. Les licences P K P ont principalement été secrètes, il n’y a donc pas de moyens de vérifier si elles sont standard. Bien qu’ils prétendent n’avoir jamais refusé de licence à qui que ce soit, au moins deux compagnies disent s’être vues refuser une telle licence. P K P protège ses brevets de près, attaquant quiconque essaie de se servir de la cryptographie à clef publique sans licence. En partie, cela est dü aux lois américaines sur les brevets. Si vous détenez un brevet et que vous ne pourchassez pas les infractions, vous pouvez perdre votre brevet. Il y a eu beaucoup de discussions quant à savoir si ces brevets sont légaux mais jusqu’à présent c ’en est resté au stade des discussions. Toutes les tentatives de mise en doute des brevets P K P ont été retirées avant que le jugement n’ait, lieu. Je ne vais pas vous donner de conseils légaux en matière de brevets dans cet ouvrage. Peut-être que le brevet R S A ne tiendrait pas devant une cour de justice. Peut-être que les brevets ne s’appliquent pas à toute la cryptographie à clef publique. (Honnêtement, je ne vois pas comment il peuvent couvrir E l G a m a l o u les systèmes cryptographiques à courbe elliptique.) Peut-être que quelqu’un va finalement gagner un procès contre PK P ou R SA D SI. Mais gardez en mémoire que des compagnies qui ont de grands dépar tements juridiques telles que IB M , M i c r o s o f t , L o t u s , A p p l e , N o v e l l , D i g i t a l , N a t i o n a l S e m i c o n d u c t o r , A T & T et S u n ont toutes demandé une licence pour l’utilisation de R SA dans leurs produits, plutôt que d ’intenter un procès en justice. Et
634
Chapitre 25
Politique
des sociétés telles que B o e i n g , S h e l l O ï l , D u P o n t . R a y t h e o n et C i t i c o r p ont toutes acquis des licences pour l’utilisation de R SA à des fins internes. Dans une affaire, P K P a attaqué T R W C o r p o r a t i o n en justice pour avoir utilisé E l G a m a l sans licence. T R W prétendait ne pas avoir besoin d ’une licence. PK P et T R W sont arrivés à un arrangement en juin 1992. Les détails de cet arrangement sont inconnus, mais ils comprenaient un accord de T R W d ’obtenir une licence d ’exploitation des brevets. Ce n’est pas de bonne augure. T R W peut se payer de bons avocats; je crois que s’ils avaient pensé pouvoir gagner le procès sans dépenser des sommes exhorbitantes, ils se seraient battu. Pendant ce temps, P K P avait ses propres problèmes internes. En juin 1994, C a r o K a h n a intenté un procès contre R SA D S I arguant, entre autre, que le brevet RSA est non valide et non remis en cause [386]. Les deux partenaires essaient d ’annuler leur collaboration. Les brevets sont-ils valides ou pas? Les utilisateurs de l’algorithme RSA devront-ils obtenir une licence de C a r o - K a h n ? Qui détiendra le brevet de S c h n o r r ? Une solution sera sans aucun doute trouvée avant que ce livre ne soit publié. Les brevets sont valables pour seulement 17 ans et ne sont pas renouvelables. A partir du 29 mars 1997, l’échange de clef D i f f i e - H e l l m a n (et l’algorithme E l G a m a l ) seront domaine public. Le 20 septembre 2000, R SA entrera dans le domaine public. Notez-le sur vos calendriers.
25.6
« International Association Cryptologie Research » (IACR)
for
L’Association internationale pour la recherche cryptologique ((IACR) pour « International Association for Cryptologie Research ») est l’organisation internatio nale de recherche en cryptographie. Son but déclaré est de faire avancer la théorie et la pratique en cryptologie et dans les domaines associés. N’importe qui peut en devenir membre. L’association parraine deux conférences annuelles, C r y p t o (tenue à Santa Barbara au mois d’août) et E u r o c r y p t (tenue en Europe en mai), et publie trimes triellement le journal « The Journal of Cryptology » et le bulletin « IACR Newsletter ». L’adresse du bureau de l’IA C R change à chaque changement de président. L’adresse ac tuelle est IACR Business Office, Aarhus Science Park, Gustav Wieds Vej 10, DK-8000 Aarhus C, Danemark.
25.7
« RACE Integrity Primitives Evalua tion » (RIPE)
Le programme de recherche et de dévelopement des technologies de communications avancées en Europe (R A C E pour Research and Development in Advanced Commu nication Technologies in Europe R A C E ) a été lancé par la Communauté européenne pour aider les travaux pré-compétitifs et pré-normatifs pour les standards et la tech nologie des communications, avec comme but de promouvoir l’ « Integrated Broadband Communication » (IB C ). Dans le cadre de cet effort, R A C E a établi le projet d’éva luation de procédures d ’intégrité ( RACE Integrity Primitives Evaluation (R IP E ) afin
25.8
« Conditional Access for Europe » (C AFE)
635
de rassembler un ensemble de techniques destinées à satisfaire les niveaux de sécurité de riB C . Six groupes européens à la pointe de la recherche cryptographique sont membres du consortium R IP E : Center for Mathematics and Computer Science, Amsterdam; Siemens A.G. ; Philips Crypto BV ; Royal P T T Nederland NV, P T T Research ; Katholieke Universiteit Leuven ; et Aarhus Universitet. Après des appels d’algorithmes en 1989 et 1991 [1566], 32 soumissions venant du monde entier et un projet d’évaluation de 350 hommes- mois, le consortium a publié « RIPE Integrity Primitives » [1316, 1343]. Le rapport inclut une introduction, une description des concepts d ’intégrité fondamen taux et les primitives suivantes: M D C -4 (voir § 14.11), R IP E -MD (voir § 14.8), R IP E -M A C (voir § 18.14), IB C -H A SH , SK ID (voir § 3.2), R SA , C O M S E T (voir § 16.1), et la génération de clefs RSA .
25.8
« Conditional Access for Europe » (CAFE)
L’Accès conditionnel pour l’Europe (C A F E ) est un projet du programme (E SPR ITde l’Union Européenne. Les travaux ont commencé en décembre 1992 et devraient se finir vers la fin 1995. Ce consortium se divise en des groupes pour des études de marché et des études sociales (« Cardware », « Institut für Sozialforschung »), des fabricants de matériels et de logiciels (« DigiCash », « Gemplus », « Ingenico », « Siemens ») et des cryptographes (« C W I Amsterdam », « P T T Research Netherlands », « SPET », « Sintef Delab Trondheim », « Universities of Arhus », « Hüdesheim and Leuven »). Le but est de développer des systèmes d’accès conditionnels, particulièrement les sys tèmes digitaux de paiement. Les systèmes de paiement doivent pouvoir donner une certitude légale à tout le monde et à tout moment et doivent demander un minimum de confiance - cette certitude ne devrait pas dépendre de la résistance à la falsification d’un quelconque des mécanismes. La machine de base pour C A F E est un portefeuille électronique: un petit ordinateur qui ressemble plus ou moins à une calculatrice de poche. Il y a une pile, un clavier, un écran et un canal infrarouge pour communiquer avec d ’autres portefeuilles. Chaque utilisateur possède et se sert de son portefeuille qui gère ses droits et garanti sa sécurité. Une machine avec un clavier et un écran a un avantage sur la carte à puce ; elle peut fonctionner sans l’aide d ’un terminal. Un utilisateur peut directement rentrer son mot de passe et le montant du paiement. Il n’a pas à donner son portefeuille pour conclure une transaction, ce qui n’est pas le cas avec les cartes de crédit. Les autres caractéristiques sont : - Des transactions « offline ». Le but de ce système est de remplacer les petites transactions d’argent ; un système « online » serait trop encombrant. - Tolérance à la perte. Si un utilisateur perd son portefeuille, si il le casse ou se le fait voler, il peut récupérer son argent. - Est compatible avec plusieurs monnaies.
636
Chapitre 25
Politique
- Une architecture et un système ouverts. Un utilisateur doit être capable de payer
son shopping, le téléphone et les transports publiques en utilisant différents prestateurs de services. Le système doit être compatible entre les différents four nisseurs d’argent électronique et entre les différents types et constructeurs de portefeuilles.
- Coût faible.
Il existe déjà une version logicielle de ce système et le consortium travaille d’arrachepied pour mettre au point un prototype le réalisant en matériel.
25.9
« ISO /IE C 9979 »
Au milieu des années 1980, ISO a essayé de standardiser DES, qui était déjà un stan dard FIPS et ANSI. Après des querelles politiques, ISO a décidé de ne pas standardiser d’algorithmes cryptographiques, mais à la place de les déposer. Seuls des algorithmes de chiffrement peuvent être déposés; les fonctions de compilation et les schémas de signatures ne peuvent pas l’être. Toute entité nationale peut soumettre un algorithme pour inscription. Au jour d’aujourd’hui, seuls trois algorithmes ont été soumis (voir tableau 25.5). Une soumission comprend des informations à propos des applications, des paramètres, de l’exécution, des modes et des vecteurs tests. Une description détaillée est optionnelle ; il est possible de soumettre des algorithmes secrets pour inscription.
T
ab
T
ab
.
25.5
Nom 0001 0002 0003
.
25.4 - IS O /IE C 9979 A
lg o r ith m es d épo sés
Numéro d’inscription B-CRYPT IDEA LUC
Une inscription d’algorithme n’est ni une garantie sur sa qualité, ni son approbation par IS O /IE C . L ’inscription indique tout juste qu’une simple entité nationale veut enregistrer l’algorithme, basé sur un critère considéré par cette entité. Je ne suis pas emballé par cette idée. L ’inscription bloque le processus de standardisa tion. Plutôt que d ’accepter quelques algorithmes, ISO autorise l’inscription de tous les algorithmes, avec si peu de contrôle sur ce qui est inscrit, affirmant qu’un algorithme « IS O /IE C 9979 Registered » est bien mieux qu’il ne parait être. Dans tous les cas, le registre est tenu par le National Computer Centre Ltd., Oxford Road, Manchester, M l 7ED, Royaume-Uni.
5.10
Groupes industriels, de défense des libertés civiles, et professionnelles
55.10
637
Groupes industriels, de défense des libertés civiles, et professionnelles
Electronic Privacy Information Center » (EPIC) ’EPIC est le centre d’information pour la confidentialité électronique et a été fondé en 394 pour attirer l’attention du public sur les problèmes émergents de la confidentialité i relation avec le « National Information Infrastructure », tel que la puce Clipper, la roposition de « Digital Telephony », les numéros et systèmes d ’identité nationale, la Mifidentialité des dossiers médicaux et la vente de données. E P IC mène des procès, 3onsorise des conférences, produit des rapports, publie « E P IC Alert » et mène des unpagnes sur les problèmes de la confidentialité. bute personne désireuse de joindre l’E PIC doit contacter l’Electronic Privacy nformation Center, 666 Pennsylvania Avenue SE, Suite 301, Washington .C. 20003, USA, Tél: +1 202 544-9240, Fax: +1 202 547-5482, Internet: [email protected].
Electronic Fondation Frontier » (EFF) a EFF est la fondation de la frontière électronique et se consacre à la protection es droits civils dans le cyber-espace. En ce qui concerne les règlements du gouverement américain en matière de cryptographie, elle soutient que l’information concerant la cryptographie et son accès sont des droits fondamentaux et qu’ils doivent donc re libres de toute contrainte gouvernementale. Cette fondation a organisé le groupe Digital Privacy and Security Working Group », une coalition de 50 organisations. ■e groupe a fait opposition au projet de loi de « Digital Telephony » et à l’initiative C lip p e r. L’E FF participe également au procès contre les contrôles d ’exportation de t cryptographie [150]. bute personne désireuse de rejoindre les rangs de l’E FF peut contacter l’Electronic rontier Foundation, 1001 G Street NW, Suite 950E, Washington D.C. 0001, USA, Tél: +1 202 347-5400, Fax: +1 202 393-5509, Internet: ff@eff .org.
Association for Computing Machinery » (A C M ) ’A C M qui est l’association pour les machines informatiques, est une organisation îternationale d’industries en informatiques. En 1994, le « U.S. A C M Public Policy lommitt.ee » a produit un excellent rapport sur la politique américaine de crypjgraphie [946]. Ce rapport devrait être lu par quiconque est intéressé par la potique en cryptographie. Il est disponible via ftp anonyme à : in fo .a cm .o rg in reports/acm _crypt_\\ stu d y/acm _crypto_study.ps.
Institute of Electrical qnd Electronics Engineers »(IEEE) i’ IE E E ,
institut des ingénieurs électriciens et électroniciens, est une autre organisation rofessionnelle. L e bureau am éricain en quête et fait des recom m andation s à p ro p o s des uestions sur la confidentialité, com pren an t la p olitiq u e de chiffrem ent, les num éros 'identité et les p rotection s d e la confidentialité sur Internet.
Chapitre 25
638
Politique
« Software Publisher Association » (SPA) La SPA qui est l’association des éditeurs de logiciels, est un syndicat professionnel regroupant plus de 1000 entreprises de logiciels pour micro-ordinateurs. Elles ont fait pression pour faire diminuer les contrôles sur l’exportation de la cryptographie et en tretiennent une liste de produits étrangers de cryptographie disponibles.
25.11
Sci.crypt
S c i .CRY p t est le forum Usenet pour la cryptologie. Il est lu par à peu près 100000 per sonnes à travers le monde entier. La plupart des messages ne veulent rien dire ou sont polémiques, voire les deux ; certains sont de nature politique et le reste consiste princi palement en des demandes d ’informations ou des questions élémentaires. Occasionnel lement, il y a des pépites d’informationsneuves et utiles qui sontadressées auforum. Si vous suivez régulièrement s c i . cryp t, vous apprendrez commentutiliser ce qui s’ap pelle le « tueur de fichiers ». Un autre forum Usenet est le sci.scrypt.research, un forum modéré dévoué aux discus sions sur la recherche cryptologique. Il y a moins de messages et ils sont plus intéres sants.
25.12
Cypherpunks
Les « CYPHERPUNKS » sont un groupe informel de gens intéressés par l’enseignement et l’apprentissage de la cryptographie. Ils expérimentent également la cryptographie et essaient de la mettre en œuvre. De leur point de vue, toute la recherche cryptographique au monde ne sert à rien pour la société si elle n’est pas mise en œuvre. Dans « A Cypherpunk’s Manifesto », E r i c H u g h e s écrit [746] : « Nous, les C y p h e r p u n k s , vouons nos efforts à la construction de systèmes anonymes. Nous protégeons notre vie privée grâce à la cryptographie, avec des systèmes d’envois de courriers anonymes, avec des signatures digitales et avec de l’argent électronique. « Les C y p h e r p u n k s écrivent un algorithme de chiffrement. Nous savons que quelqu’un doit écrire un logiciel pour protéger la vie privée, et comme l’intimité concerne chacun d’entre-nous, nous allons écrire ce programme. Nous publions notre algorithme de chiffrement afin que nos camarades de C y p h e r p u n k s puissent s’entraîner et jouer avec. Notre algorithme de chiffrement est gratuit pour toute utilisation, dans le monde entier. Nous ne nous soucions guère de savoir si vous approuvez ou pas. Nous savons qu’un logiciel ne peut être détruit et que des systèmes largement diffusés ne peuvent pas être arrêtés. » Les personnes souhaitant être incluses dans la liste courrier des C y p h e r p u n k s sur Internet peuvent envoyer un courrier à [email protected].. Ce listing est archivé à ftp.csua.berkeley.edu dans /pub/cypherpunks.
25.13
Brevets
25.13
639
Brevets
La problématique des brevets3 en matière de logiciel dépasse largement le cadre de cet ouvrage. Qu’ils soient bons ou mauvais, ils existent. Les algorithmes, algorithmes cryp tographiques inclus, peuvent être brevetés aux Etats-Unis. IB M détenait les brevets du DES [516]. Presque tous les algorithmes de cryptographie à clef publique sont brevetés. Le N IST a même un brevet pour le D SA . Certains brevets cryptographiques ont été bloqués à la demande de la NSA, dans le cadre des pouvoirs qui lui sont conférés par l’« Invention Secrecy Act » de 1940 et le « National Security Act » de 1947. Ceci veut dire qu’à la place d’un brevet, l’inventeur obtient un ordre de discrétion et il lui est interdit de discuter de son invention avec qui que ce soit. La N SA a une dispense spéciale quand il s’agit de brevets. Elle peut faire une demande de brevet puis bloquer son homologation. Là encore, c’est un ordre de discrétion, mais la NSA est alors à la fois l’inventeur et l’autorité donnant l’ordre. Quand, bien plus tard, l’ordre de discrétion est levé, le « Census Office » octroie le brevet pour les 17 années réglementaires. Ceci protège clairement l’invention tout en la gardant secrète. Si quelqu’un d ’autre invente la même chose, la NSA a déjà fait une demande de brevet. Si personne d’autre ne fait la même invention, alors elle reste secrète. Non seulement ce système est une entorse à tout le processus de délivrance des brevets, qui est censé révéler et protéger les inventions, mais il permet aussi à la NSA de conserver un brevet pendant plus de 17 ans. Le décompte des années commence en effet après que le brevet soit délivré, et non pas quand la demande est enregistrée. Les perspectives d’évolution de ce système, maintenant que les Etats-Unis ont ratifié le G A T T , ne sont pas claires.
25.14
Réglementation américaine à l’ex portation
D’après le gouvernement américain4, la cryptographie peut être une munition. Cela signifie qu’elle est couverte par les mêmes règles qu’un missile anti-tank ou un tank M l A b r a m s . Si vous vendez de la cryptographie aux Etats-Unis à des acheteurs étran gers sans licence d’exportation appropriée, alors vous êtes considéré comme trafiquant d’armes international. A moins que vous ne pensiez qu’un séjour dans un pénitencier fédéral fasse bonne impression dans votre curriculum vitæ, faites attention à cette réglementation. Avec l’avènement de la Guerre Froide en 1949, tous les pays membres de l’OTAN (excepté l’Islande), et plus tard l’Australie, le Japon et l’Espagne, ont formé le « Coordinating Committee for Multilatéral Export Controls » ( C o C o m ). C ’est une organisation 3. N ote du traducteur : les brevets don t il est question dans cette section sont tous américains. 4. N ote du traducteur : toutes les inform ations reprises dans cette section concernent principalement les règles d ’exportation américaines. Elles ne s’ appliquent à vous que si vous devez exporter de la cryptographie hors des Etats-Unis. T outefois ces règles vous concernent mêm e si vous ne vivez pas aux Etats-Unis car elles conditionnent la nature des dispositifs cryptographiques mis à votre disposition dans le reste du m onde (quand ceux-ci sont originaires des Etats-Unis bien sûr). Chaque pays a ses propres réglem entations en m atière de cryptographie. Avant d ’ im porter ou d ’ exporter des dispositifs cryptographiques, prenez les conseils d ’ une personne avisée et spécialisée en ces matières (il est conseillé de consulter un b on avocat).
640
Chapitre 25
Politique
non officielle et non contractuelle, créée pour coordonner les restrictions nationales sur l’exportation de technologies militaires sensibles vers l’Union Soviétique, vers d’autres pays du Pacte de Varsovie et vers la République Populaire de Chine. Des exemples de technologies contrôlées sont les ordinateurs, les machines-outils telles que les fraiseuses et la cryptographie. Le but recherché était de ralentir le transfert de technologie vers ces pays, et par conséquent de maintenir leurs forces armées à un niveau inférieur. Depuis la fin de la Guerre Froide, les pays du C oC om ont réalisé que beaucoup de leurs contrôles étaient obsolètes. Aussi, ils seraient en train de définir un « New Forum », une autre organisation multinationale dont le but sera de stopper le flot de technologies militaires vers des pays que les membres n’apprécient pas particulièrement. De toutes façons, la politique américaine d’exportation des biens stratégiques est dé finie par l’« Export Administration Act », l’« Arms Export Control Act », l’« Atomic Energy Act » et le « Nuclear Non-Proloferation Act » Les contrôles établis par toutes ces législations sont effectués par de nombreuses ordonnances, aucune d’entre-elles n’étant en coordination avec les autres. Plus d’une douzaine d’agences, y compris les services militaires, effectuent des contrôles ; souvent, leurs programmes s’entremêlent ou se contredisent. Les technologies contrôlées apparaissent sur plusieurs listes. La cryptographie a tou jours été classée comme arme de guerre et apparait sur la « U.S. Munitions List » (U SM L), la « International Munitions List » (IM L), la « Commerce Control List » (C C L ) et la « International Industrial List » (HL). Le Département d ’Etat est res ponsable de la USM L ; elle est publiée dans les « International Traffic in Arms Régulations » (IT A R ) [472, 473]. Deux agences gouvernementales contrôlent l’exportation de cryptographie. L ’une est le « Bureau of Export Administration » (B X A ) au Département du Commerce, régie par les « Export Administration Régulations » (E A R ). L’autre est l’ « Office of Defense Trade Controls » (D T C ) du Département d’Etat, régie par les IT A R . A vue de nez, le B X A du Département du Commerce est beaucoup moins exigeant, mais le D T C du Département d ’Etat (qui prend ses conseils techniques et de sécurité nationale auprès de la NSA et qui semble toujours suivre ces conseils) analyse toutes les exportations de cryptographie en premier et peut refuser le transfert de la juridiction au B X A . Les IT A R règlent ces matières5 ; ce changement de dénomination est probablement le résultat d ’un effort de relations publiques destiné à nous faire oublier qu’il s’agit d’armes et de bombes. Historiquement, le D T C était réticent à accorder des licences d’exportation pour des produits de codage supérieurs à un certain niveau — bien qu’il n’ait jamais déclaré publiquement quel était ce niveau. Les paragraphes suivants, qui ont trait à la cryptographie, sont extraits des IT A R [472, 473]6 : « § 120.10 Données techniques. « Données techniques » désigne, pour les besoins de ce sous-chapitre : « (1) Des informations, autres que du logiciel tel que défini par 120.10(d), qui sont nécessaires pour la conception, le développement, la 5. Avant 1990, l’ O ffice de con trôle du com m erce de la défense (« O ffic e o f D e fe n s e Trade C o n tr o ls ») s’appelait l’O ffice de con trôle des armes (« O ffic e o f M u n itio n s C o n tr o ls »). 6- Note du traducteur : la traduction du docum ent qui suit n’a pas de valeur légale. Si vous devez être soum is à cette réglem entation, prenez connaissance du docum ent original et, com m e le dit l’auteur, prenez les conseils d ’ un hom m e de loi qui le com prend.
25.14
Réglementation américaine à l’exportation
production, le traitement, la fabrication, l’assemblage, l’utilisation, la ré paration, l’entretien ou la modification d’articles de défense. Cela inclut, par exemple, les informations sous formes de projets, de dessins, de pho tographies, de plans, de modes d ’emploi ou de documentation. (2) Des informations classées relatives à des articles ou des services de la défense ; « (3) Des informations couvertes par un ordre de préservation du secret de l’invention ; « (4) Le logiciel tel que défini par la section 121.8(f) directement relatif aux articles de défense ; « (5) Cette définition n ’inclut pas les informations relevant des prin cipes généraux scientifiques, mathématiques ou techniques enseignés dans les écoles, collèges et universités du domaine public comme définit au § 120.11. Elle n’inclut pas non plus les informations commerciales de base sur la fonction ou l’objet ni la description globale d’articles de défense. « § 120.11 Domaine public. « Domaine public » désigne toute information qui a été publiée et qui est généralement accessible et disponible au public : « (1) Par la vente en kiosques et en libraires ; « (2) Par les abonnements qui sont disponibles sans restrictions à qui conque désire obtenir ou acheter de l’information publiée ; « (3) Par des mailings de deuxième classe accordés par le gouvernement américain ; « (4) Dans les bibliothèques ouvertes au public ou auprès desquelles le public peut obtenir des documents ; « (5) Par les brevets disponibles dans tout bureau de brevets ; « (6) Par la distribution non restreinte lors de conférences, desémi naires, de foires ou d ’expositions accessibles sans restriction au public, aux Etats-Unis ; « (7) Par la publication publique (c’est-à-dire, une publication non res treinte) sous toute forme (c’est-à-dire, pas nécessairement sous forme pu bliée) après l’approbation du département ou de l’agence concernée du gou vernement américain (voir également § 125.4(b)(13)) ; « (8) Par la recherche fondamentale en sciences et techniques dans des institutions accréditées d’enseignement supérieur aux Etats-Unis, où les ré sultats de recherche sont publiés et largement partagés par la communauté scientifique. La « recherche fondamentale » désigne la recherche élémentaire et expérimentale en sciences et techniques où les résultats sont publiés et largement partagés par la communauté scientifique, bien distincte de la re cherche dont les résultats sont classés secrets pour des raisons de propriété ou par des contrôles spécifiques d’accès et de dissémination du gouverne ment américain. La recherche universitaire ne sera pas considérée comme fondamentale si : « (i) l’université ou ses chercheurs acceptent d ’autres restrictions sur la publication des résultats de leurs projets scientifiques ou techniques, ou « (ii) la recherche a été initiée par le gouvernement américain et des contrôles spécifiques d’accès et de dissémination protégeant les résultats de leurs recherches sont applicables.
641
642
Chapitre 25
Politique
« § 120.17 Exportation « Exporter signifie: « (1) Envoyer ou emporter hors des Etats-Unis de quelque façon que ce soit des documents liés à la défense, à l’exception des connaissances tech niques personnelles qui voyagent de par le déplacement de leur détenteur ; ou « (2) Transférer un enregistrement, un contrôle ou un titre de propriété à une personne étrangère d’un avion, d’un navire, ou d’un satellite repris dans la liste des munitions américaines, que ce soit aux Etats-Unis ou à l’étranger ; ou « (3) Divulguer (oralement ou visuellement) ou transférer au sein des Etats-Unis tout article de défense auprès d ’une ambassade, toute agence ou représentation d ’un gouvernement étranger (par exemple, les représen tations diplomatiques) ; ou « (4) Divulguer (oralement ou visuellement) ou transférer des données techniques à une personne étrangère, que ce soit aux Etats-Unis ou à l’étran ger; ou « (5) Offrir des services liés à la défense à la place de ou pour le bénéfice d ’une personne étrangère, que ce soit aux Etats-Unis ou à l’étranger. « (6) Une fusée de lancement ou sa charge utile ne doivent pas, de par le lancement d ’un tel véhicule, être considérés comme une exportation dans le sens de ce sous-chapitre. Toutefois, pour certains objectifs restreints (voir § 126.1 de ce sous-chapitre), le contrôle de ce sous-chapitre s’applique à la vente et autres transferts d ’articles ou de services de défense. « Partie 121— La liste américaine des munitions « § 121.1 Généralités. La liste américaine des munitions « Catégorie XIII- -Equipements militaires auxiliaires « (1) Les systèmes cryptographiques (y compris ceux de gestion de clef), les équipements, les pièces détachées, les modules, les circuits intégrés, les composants ou logiciels ayant la capacité de garantir la discrétion et la confidentialité des informations ou des systèmes d’informations, excepté les équipement cryptographiques et les logiciels qui sont : « (i) Délimités aux fonctions de décodage spécialement étudiés pour pouvoir utiliser des logiciels protégés contre la copie, pourvu que les fonc tions de déchiffrement ne soient pas accessibles à l’utilisateur. « (ii) Spécifiquement étudiés, développés ou modifiés pour utilisation dans des machines bancaires ou des transactions d ’argent, et uniquement dédiés à de telles transactions. Les machines bancaires ou les transactions d ’argent incluent les guichets automatiques, les imprimantes automatiques de position de compte, les terminaux de points de vente ou les équipements de chiffrage des transactions interbancaires. « (iii) Basés uniquement sur des techniques analogiques pour fournir un chiffrement qui assure la sécurité de l’information dans les applications suivantes... « (iv) Des cartes à puce personnalisées utilisant la cryptographie dont l’usage est limité à des équipements ou des systèmes n’étant pas sous le contrôle de la USML.
25.14
Réglementation américaine à l’exportation
« (v) Limités aux accès contrôlés, tels que les guichets automatiques, les imprimantes automatiques de position de compte ou les terminaux de points de vente, protégés par un mot de passe ou un code d ’identification (Personal Identification Number - PIN) ou des données similaires pour em pêcher l’accès non autorisé aux installations, mais qui ne permettent pas le chiffrement de fichiers ou de textes, mis à part ce qui est directement affecté à la protection du PIN. « (vi) Limités aux authentifications de données qui calculent un « Message Authentication Code » (C A M ) ou un résultat similaire pour s’assurer qu’aucune altération de texte n’est apparue, ou pour identifier l’utilisateur, mais ne permet pas le chiffrement de données, de textes ou d’un autre média autre que ceux nécessaires à l’authentification. « (vii) Limités à des techniques de compression ou de chiffrement de données fixes. « (viii) Limités à la réception d ’émissions radios, télévision à péage ou tout autre émission destinée à un public restreint, sans chiffrement digital et où le déchiffrement digital est limité à la vidéo, à l’audio ou à des fonctions de gestion. « (ix) Des logiciels créés ou modifiés pour se protéger de tout piratage informatique (un virus par exemple). « (2) Des systèmes cryptographiques (y compris ceux de gestion de clef), des équipements, des pièces détachées, des modules, des circuits intégrés, des composants ou logiciels capables de produire des codes correcteurs pour des systèmes ou des équipements spectraux de diffusion. « (3) Des systèmes cryptographiques, des équipements, des pièces dé tachées, des modules, des circuits intégrés, des composants ou des logiciels. « § 125.2 Exportations de données techniques non classées. « (a) Généralités. Une licence (DSP-5) est nécessaire pour l’exportation de données techniques non classées, à moins que l’exportation soit exempte des exigences de licence de ce sous-chapitre. Dans le cas d’une visite d ’usine, les détails des présentations prévues doivent être transmises à l’Office de contrôle du commerce de la défense pour approbation sur le contenu tech nique. Sept copies des données techniques ou des détails des présentations doivent être fournies. « (b) Brevets. Une licence octroyée par l’Office de contrôle du com merce de la défense est nécessaire pour l’exportation de données techniques, chaque fois que les données dépassent ce qui est normalement nécessaire à l’obtention d ’un brevet domestique, ou à l’obtention d’un brevet à l’étran ger quand aucune demande domestique n’est faite. Les requêtes pour les demandes de brevets dans un pays étranger et les requêtes pour l’adjonc tion d’amendements, de modifications ou de suppléments à de tels brevets doivent être conformes aux réglementations de l’Office des brevets et des marques en accord avec l’article 37 CFR partie 5. L ’exportation de données techniques pour l’obtention et l’enregistrement d’un brevet dans des pays étrangers est soumise aux réglementations émises par l’Office des brevets et des marques conformément à l’article 35 U.S.C. 184.
64S
644
Chapitre 25
Politique
« (c) Divulgations. Sauf exemption explicite reprise dans ce souschapitre, une licence est requise pour la divulgation orale, visuelle ou docu mentaire de données techniques par des personnes américaines à des per sonnes étrangères. Une licence est nécessaire indépendamment de la manière dont les données techniques sont transmises (en personne, par téléphone, par courrier, par moyens électroniques, etc.). Une licence est nécessaire pour de telles divulgations par des personnes américaines dans le cadre de visites à des représentations diplomatiques et à des offices consulaires. » Et ainsi de suite. Il y a beaucoup d ’autres informations dans ce document. Si vous avez l’intention d ’exporter de la cryptographie, je vous suggère de vous procurer à la fois une copie du document complet et un homme de loi qui parle ce langage. En réalité, la N SA a le contrôle de l’exportation des produits cryptographiques. Si vous voulez une « Commodity Juridiction » (C J), vous devez soumettre votre produit à l’approbation de la N SA et soumettre votre demande de CJ au Département d ’Etat. Après avoir obtenu l’autorisation du Département d ’Etat, l’affaire passe dans la ju ridiction du Département du Commerce, qui ne s’est jamais vraiment préoccupé de l’exportation de la cryptographie. Toutefois, le Département d’Etat n’accordera jamais une CJ sans l’approbation de la NSA et, pour autant que l’on sache, il n’a jamais refusé ime licence après l’approbation de la NSA. En 1977, un employé de la NSA appelé Joseph A. M e y e r a écrit une lettre — non autorisée, d ’après le compte rendu officiel de l’incident — destinée à l’IEEE, les aver tissant que la présentation prévue de l’article original concernant le R SA violerait la réglementation IT A R . Voici un extrait de « Puzzle Palace » : « Il marquait un point. IT A R couvrait toute « information non classée qui pouvait être utilisée, ou adaptée pour être utilisée, dans la conception, la production, la fabrication, la réparation, la révision, le traitement, l’in génierie, le développement, l’opération, l’entretien ou la reconstruction » des matériels cités, aussi bien que « toute technologie qui permettait l’amé lioration du nec plus ultra ou établissait un nouvel art dans un domaine significatif d ’application militaire aux Etats-Unis ». Et exporter comprenait le transfert d’informations à la fois sous forme écrite ou par des moyens oraux ou visuels, y compris les briefings et les symposiums auxquels des étrangers étaient présents. « Mais, pris à la lettre, les règlements vagues et exagérément étendus sembleraient indiquer que toute personne désirant prendre la parole publi quement ou écrire sur un des sujets repris sur la liste des munitions devrait obtenir l’approbation du Département d’Etat — une perspective peu ré jouissante qui va manifestement à l’encontre du premier amendement et qui n’a pas encore été portée en justice. » En fin de compte, la N SA a désavoué l’acte de M e y e r , et l’article sur le R S A a été présenté comme prévu. Aucune action n ’a été entamée contre ses inventeurs, bien que leurs travaux ont bel et bien amélioré les capacités étrangères de cryptographie plus que tout ce qui a été diffusé depuis. La déclaration suivante de la NSA concerne l’exportation de la cryptographie [367] : « La technologie cryptographique est vitale aux intérêts nationaux de
25.14
Réglementation américaine à l’exportation
645
sécurité. Ceux-ci comprennent les intérêts économiques, militaires et des affaires étrangères « Nous ne sommes pas d’accord avec les implications de l’audience du 7 mai 1992 du « House Judiciary Committee » et les articles récents pa rus dans la presse qui prétendent que les lois d ’exportation américaines empêchent la fabrication et l’utilisation par les firmes américaines d’équi pements de chiffrement de haute tenue. Nous ne connaissons aucun cas de société américaine qui aurait été empêchée de fabriquer et d’utiliser des équipements de chiffrement au sein de ce pays, ou pour un usage par des sociétés américaines ou ses filiales en des localisations hors Etats-Unis. De fait, la N SA a toujours soutenu l’utilisation du chiffrement par les sociétés américaines opérant à l’intérieur et hors de nos frontières pour protéger les informations sensibles. « En ce qui concerne l’exportation vers des pays étrangers, la N SA en tant que composante du Département de la Défense (avec le Département d ’Etat et le Département du Commerce) analyse les licences d’exporta tion pour des technologies de sécurité des informations contrôlées par les « Export Administration Régulations » ou les « International Traffic and Arms Régulations ». Des systèmes similaires de contrôle des exportations sont en place dans tous les pays faisant partie du « Coordinating Committee for Multilatéral Export Controls » (C o C o m ) ainsi que dans de nombreux pays ne faisant pas partie du C o C o m , car ces technologies sont univer sellement considérées comme sensibles. De telles technologies ne sont pas interdites d ’exportation et sont analysées cas par cas. Dans le cadre du processus d’analyse de demandes d’exportation, des licences peuvent être nécessaires pour ces systèmes et celles-ci sont analysées pour déterminer l’impact qu’aurait une telle exportation sur les intérêts de la sécurité na tionale. Les licences d’exportation sont octroyées ou refusées sur la base du type d ’équipement impliqué, de l’utilisation finale prévue et de l’utilisateur final envisagé. « Notre analyse indique que les Etats-Unis sont les leaders mondiaux en matière de fabrication et d ’exportation de technologies de sécurité de l’information. Parmi ces produits cryptologiques soumis à la N SA par le Département du Commerce pour l’obtention d’une licence d’exportation, nous en approuvons régulièrement plus de 90 %. Les licences d ’exportation pour des produits de sécurité de l’information, qui sont sous la juridiction du Département du Commerce, sont traitées et approuvées sans en référer à la N SA ou au Département de la Défense. Ceci inclut les produits qui utilisent des technologies telles que le DSS ou R SA pour offrir des possibi lités d ’authentification et de contrôle d’accès d’ordinateurs ou de réseaux. En fait, de par le passé la NSA a joué un rôle majeur en militant avec succès pour le relâchement des contrôles d’exportation pour le R S A et des technologies similaires utilisées à des fins d ’authentification. De telles tech niques sont extrêmement utiles pour lutter contre les pirates et l’utilisation non autorisée de ressources. » C’est la règle affirmée de la NSA de ne pas restreindre l’exportation des produits d’au thentification, seuls les produits de chiffrement étant concernés. Si vous voulez exporter
646
Chapitre 25
Politique
un produit uniquement d’authentification, l’obtention de l’approbation peut consister juste à montrer que votre produit n’est pas facilement utilisable pour le chiffrement. De plus, les procédures administratives sont nettement plus simples pour les produits d ’authentification que pour les produits de chiffrement. Un produit d ’authentification a besoin de l’approbation du Département d ’Etat ime fois seulement pour le C J ; un produit de chiffrement peut nécessiter une approbation pour chaque révision, ou même pour chaque vente. Sans un CJ, vous devez demander une autorisation d’exportation à chaque fois que vous voulez exporter le produit. Le Département d ’Etat n’approuve pas l’exporta tion de produits avec de puissants chiffrements, même ceux utilisant le DES. Des exceptions isolées incluent les exportations vers des auxiliaires américains à des fins de communications vers les Etats-Unis, les exportations pour quelques applications bancaires et les exportations vers des utilisateurs militaires américains appropriés. La « Software Publishers Association » (SPA ) a négocié avec le gouvernement pour as souplir les restrictions d’exportation de licences . Un arrangement de 1992, entre eux et le Département d ’Etat, a assoupli les règles d’exportation pour les deux algorithmes RC2 et R C 4, pour autant que la clef soit ait 40 bits ou moins. Voyez la section 7.1 pour plus d ’informations. En 1993, Maria C a n t w e l l (D -W A ) a déposé un projet de loi sur ordre de l’industrie informatique pour relâcher les contrôles sur les exportations de logiciels de chiffrement. Le Sénateur Patty M u r r a y (D W A ) a déposé un projet de loi similaire au Sénat. Le projet de C a n t w e l l fut annexé à la législation sur le contrôle des exportations générales passant au Congrès, mais fut supprimé par le « House Intelligence Committe » après un gros effort de pression de la part de la NSA. Quoi qu’ait pu faire la NSA, ce fut très impressionnant ; le comité a voté à l’unanimité la suppression du projet de loi. Je n’arrive pas à me souvenir de la dernière fois où un ensemble de législateurs ont voté à l’unanimité pour quoi que ce soit. En 1995, Dan B e r n s t e in , avec l’aide de l’E FF, a attaqué en justice le gouvernement américain, cherchant ainsi à l’empêcher de restreindre la publication de documents et de logiciels cryptographiques [150]. Le procès a conclu que les lois de contrôle des exportations sont anticonstitutionnelles, une "insupportable contrainte à la parole, en violation avec le Premier Amendement.” Spécifiquement, les charges indiquent que le procédé actuel de contrôle des exportations permet aux bureaucrates de restreindre la publication sans jamais aller en cour de justice, - procure trop peu de procédures de sécurité pour respecter le Premier Amendement, requiert des éditeurs une inscription auprès du gouvernement, créant ainsi une "presse accréditée” , - n’autorise pas la publication générale en exigeant que les destinataires soient individuellement identifiés, est trop vague pour que des personnes ordinaires puissent savoir quelle conduite est autorisée et laquelle ne l’est pas,
25.15
Importation et exportation de cryptographie
- englobe trop de choses car il interdit une conduite qui est clairement protégée (parler à des étrangers aux Etats-Unis, par exemple), - est trop largement appliqué, en interdisant l’exportation de logiciels qui ne contiennent pas de cryptographie, se basant sur la théorie que l’on pourrait ajou ter de la cryptographie plus tard, - viole aisément le Premier Amendement en interdisant un discours privé sur la cryptographie car le gouvernement veut que ce soit son opinion sur la cryptogra phie qui guide le public, - dépasse son autorité accordée par le Congrès pour les lois de contrôle des expor tations, ainsi que celle accordé par la Constitution. Tout le monde pense que statuer sur ce cas prendra plusieurs années et personne ne sait comment cela finira. Entre-temps, le « Computer Security and Privacy Advisory Board », un comité consul tatif officiel du N IST, a voté en mars 1992 pour recommander la révision des règles nationales en matière de cryptographie, y compris les règles d ’exportation. Ils disent que les règlements sont édictés exclusivement par les agences impliquées dans la sécurité nationale, sans consultation des agences concernées par l’encouragement du commerce. Les agences préoccupées par la sécurité nationale font tout leur possible pour s’assurer que ces règlements ne changent pas, mais il va bien falloir qu’ils évoluent.
25.15
Importation et exportation de cryp tographie
Les autres pays ont leurs propres réglementations sur l’importation et l’exporta tion [316]. Ce résumé est incomplet et probablement dépassé. Des pays peuvent avoir une réglementation et l’ignorer, ou ne pas en avoir mais restreindre l’importation, l’ex portation et l’utilisation de toutes façons. - L’Australie impose un certificat d ’importation pour la cryptographie à la seule demande du pays exportateur. - Le Canada ne procède pas à des contrôles d’importations et les contrôles d’ex portations sont similaires à ceux effectués par les Etats-Unis. L’exportation de matériels du Canada peut être sujet à restriction s’ils sont inclus dans l’« Export Control List », conformément à l’ « Export and Import Permits Act ». Le Canada se conforme au règlement du C o C o m en ce qui concerne la technologie crypto graphique. Les systèmes de chiffrement sont décrits dans la catégorie cinq, partie deux de la réglementation des exportations canadiennes. Ces dispositions sont si milaires à la catégorie cinq américaine de l’« Export Administration Régulations ». - La Chine a un plan d’autorisation pour les marchandises importées ; les exporta
teurs doivent déposer un dossier auprès du Ministère du commerce extérieur. Se basant sur la liste chinoise, établie en 1987, des importations et exportations pro hibées ou restreintes, la Chine limite l’importation et l’exportation de systèmes de chiffrement de voix.
Chapitre 25
648
Politique
- La France n’a pas de règlement spécial pour l’importation de la cryptographie, mais il y a des règles concernant la vente et l’utilisation de la cryptographie dans leur pays. Tous les produits doivent être certifiés : soit ils correspondent à une spécification publiée, soit la spécification de l’entreprise propriétaire est commu niquée au gouvernement. Le gouvernement peut aussi demander deux unités pour son propre usage. Les entreprises doivent avoir une autorisation pour vendre de la cryptographie en France ; cette autorisation spécifie le marché cible. Les utilisa teurs doivent avoir une autorisation pour acheter et se servir de la cryptographie ; cette autorisation inclus une clause stipulant que les utilisateurs doivent céder leurs clefs au gouvernement jusqu’à quatre mois après utilisation. Cette restric tion peut être levée dans certains cas : les banques, les entreprises importantes, etc... U n’y a pas de licence d ’exploitation pour la cryptographie exportable des Etats-Unis. - L ’Allemagne suit les directives du C o C o m , exigeant une autorisation pour ex porter la cryptographie. Ils gardent spécifiquement le contrôle des logiciels de cryptographie dans le domaine publique et le marché de masse. - Israël a des restrictions sur l’importation, mais personne ne semble les connaître. - La Belgique, l’Italie, le Japon, la Hollande et le Royaume-Uni se conforment aux directives du C o C o m sur la cryptographie, exigeant une autorisation pour exporter. - Le Brésil, l’Inde, le Mexique, la Russie, l’Arabie-Saoudite, l’Espagne, l’Afrique du Sud, la Suède et la Suisse n’exercent pas de contrôles sur l’importation ou l’exportation de cryptographie.
25.16
Légalité
Est-ce que les signatures numériques sont de vraies signatures? Ont-elles une valeur en justice? Certaines investigations légales préliminaires indiquent que les signatures numériques pourraient satisfaire les critères de signatures liant leur signataire pour la plupart des utilisations, notamment l’utilisation commerciale telle que définie par le « Universal Commercial Code » (U C C ). Une décision du « Government Accounting Office » (G A O ), prise à la requête du N IST, confirme que les signatures numériques satisferaient les standards légaux des signatures manuscrites [366]. Le « Utah Digital Signature Act » a pris effet le 1er mai 1995, procurant un cadre légal pour l’utilisation de signatures digitales dans le système judiciaire. La Californie en mesure les effets, l’Orégon et Washington écrivent encore le leur. Le Texas et la Floride suivent derrière. D ’ici à la publication de ce livre, d’autres Etats auront suivi. L ’ « American Bar Association » (ED I et 1’ « Information Technology Division » de la « Science and Technology Section ») propose un modèle d ’acte que les Etats peuvent utiliser pour leur propre législation. Cet acte tente d’incorporer les signa tures digitales dans l’infrastructure existante légale pour les signatures : le « Uniform Commercial Code », la règlementation de la « United States Fédéral Reserve », la loi commune des contrats et signatures, la « United Nations Convention on Contracts for
25.16
Légalité
649
the International Sale of Goods » et la « United Nations Convention on International Büls of Exchange and International Promissory Committees ». Sont inclus dans cet
acte les responsabilités et les obligations des autorités de certification, les termes de l’accord, de ses limites et de sa politique Aux Etats-Unis, les lois sur les signatures, les contrats et les transactions commerciales sont des lois d’Etat. Le but ultime est un acte fédéral, mais si tout ceci démarre au niveau de l’Etat, il y a moins de chances pour que la NSA vienne gâcher le travail. Même ainsi, la validité des signatures numériques n ’a pas encore été mise en doute en cour de justice ; leur statut légal est encore indéfini. Pour que les signatures numériques aient la même valeur que des signatures manuscrites, elles doivent primo être utilisées pour signer mi document liant le signataire de manière légale et elles doivent secundo être mises en question en justice par l’une des parties. La cour devrait alors juger de la sécurité du schéma de signature et émettre un jugement. Au fil du temps, comme il est de coutume, une jurisprudence émergerait concernant les méthodes de signature numérique et la taille de clef requise pour qu’une signature numérique soit légalement contraignante. Ceci risque de prendre des années. En attendant, si deux personnes veulent utiliser des signatures numériques pour des contrats (ou des bons de commande, ou des demandes de travaux, ou quoique ce soit), il est recommandé qu’elles signent un contrat papier par lequel elles s’accordent à être liées dans le futur par tout document qu’elles signeraient numériquement [1105] Ce document préciserait l’algorithme, la taille de la clef et tout autre paramètre ; il devrait aussi décrire comment les disputes doivent être résolues.
Postface de Matt Blaze Un des plus dangereux aspects de la cryptologie (et par extension, de ce livre), est que vous pouvez presque la mesurer. La connaissance de la longueur de clef, de la méthode de factorisation et des techniques cryptanalytiques rend possible l’estimation (en l’ab sence d’une réelle théorie de la conception d’algorithmes de chiffrement) du « facteur travail » nécessaire pour casser un algorithme de chiffrement particulier. Il est trop tentant d ’abuser de ces estimations, comme si elles n’étaient en général qu’une sécurité adaptée aux systèmes dans lesquels elles sont utilisées. Le monde réel offre à l’atta quant, un menu bien plus riche en options qu’une simple cryptanalyse. Les protocoles d’attaques sont souvent plus inquiétants, le cheval de Troie, les virus, la surveillance électromagnétique, les compromis physiques, le chantage et les intimidations des dé tenteurs de clefs, les bogues des systèmes d’exploitation, les bogues des programmes d’application, les problèmes de matériels, les erreurs de l'utilisateur, les oreilles indis crètes, la corruption et la fouille de poubelles, pour en nommer quelques-uns. Les chiffres et les protocoles de bonne qualité sont des outils importants, mais sont de pauvres substituts à une réflexion sur ce qui est véritablement protégé et sur les différentes manières dont une défense peut s’effondrer (les pirates, après tout, se li mitent rarement aux modèles de menaces propres et bien définis du monde acadé mique). Ross A n d er so n nous donne des exemples de systèmes cryptographiques forts (dans le domaine bancaire) qui ont cédé sous des attaques réelles [44, 45]. Même quand un assaillant n’a accès qu’au texte chiffré, des brèches apparemment mineures dans d’autres parties du système peuvent laisser fuir assez d ’information pour que de bons systèmes cryptographiques deviennent inutiles. Les Alliés pendant la Seconde Guerre Mondiale ont cassé le trafic par E n ig m a allemands en exploitant largement les erreurs des opérateurs [1589]. Une connaissance employée à la N SA ironise, quand on lui demande si le gouvernement peut casser le trafic DES, sur le fait que les vrais systèmes sont si peu sûrs qu’ils n’ont pas besoin de s’en donner la peine. Hélas, il n’existe pas de recette facile pour rendre un système sûr, aucun substitut à une conception soigneuse et critique, avec une attention minutieuse. Les bons systèmes cryptographiques ont la propriété de rendre la vie des assaillants beaucoup plus dure que celle des simples utilisateurs ; ce n’est pas le cas dans la plupart des autres aspects concernant la sécurité des ordinateurs et des communications. Regardez la liste suivante des dix plus grandes menaces à la sécurité des systèmes réels ; toutes sont plus faciles à exploiter qu’à éviter. 1. L’état désastreux du logiciel. Chacun sait que personne ne sait écrire un logiciel. Les systèmes modernes sont complexes, avec des centaines de milliers de lignes de codes ; chacune d ’entre-elles a des chances de compromettre la sécurité. Des
652
Postface de Matt Blaze erreurs fatales peuvent même être très éloignées de la partie dédiée à la protection du logiciel.
2. Protection inefficace contre les attaques de refus de service. Quelques protocoles cryptographiques autorisent l’anonymat. Il peut être spécialement dangereux de déployer des protocoles anonymes s’ils augmentent les opportunités d’interrup tion de service par des vandales non-identifiés ; les systèmes anonymes ont donc besoin d ’être tout particulièrement résistant aux attaques de refus de service. Les réseaux robustes peuvent supporter plus facilement l’anonymat ; pensez que presque personne ne se soucie beaucoup des millions de points d ’entrée anonymes à des réseaux plus robustes tels que le système téléphonique ou le service postal, où il est relativement difficile (ou cher) pour quelqu’un de causer des pannes à grande échelle. 3. Manque de place pour stocker les secrets. Les systèmes cryptographiques pro tègent les secrets importants par des plus petits (clefs). Hélas, les ordinateurs modernes ne sont pas vraiment bons pour protéger même les plus petits secrets. Les stations de travail multi-utilisateurs en réseau peuvent être infiltrées et leurs mémoires compromises. Les unités à utilisateur unique peuvent être volées ou infectées par des virus qui distillent des secrets de façon asynchrone. Les serveurs isolés, où il peut ne pas y avoir d ’utilisateur pour entrer le mot de passe (voir menace n5), sont un problème particuüèrement délicat. 4. Génération aléatoire de nombre peu performante. Les clefs et les variables de session ont besoin de bonnes sources de bits non prévisibles. Un ordinateur qui fonctionne possède en soi beaucoup d’entropie mais fournit rarement des appli cations qui en permettent une exploitation pratique et fiable. Un certain nombre de techniques ont été proposées pour obtenir de vrais nombres aléatoires dans les logiciels (profiter d ’événements imprévisibles comme les dates d ’arrivées des entrées-sorties, les décalages des horloges et les chronomètres et même la turbu lence de l’air à l’intérieur du disque), mais tout ceci est très sensible au moindre changement d ’environnement dans lequel ils sont utilisés. 5. Faibles phrases-mots de passe. La plupart des programmes cryptographiques traitent les problèmes de stockage et de génération de clef en se reposant sur les mots de passe de l’utilisateur, qui sont censés être assez imprévisibles pour être de bonnes clefs et qui sont aussi assez faciles à retenir pour ne pas avoir à être stockés. Alors que les attaques des petits mots de passe avec l’aide du dic tionnaire sont un problème bien connu, on ignore les lignes d’attaque contre des phrases entières de mots de passe. Selon S h a n n o n , un texte anglais présente à peine plus d ’un bit d ’entropie par caractère, ce qui semblerait mettre la plupart des phrases-mots de passe à la portée d ’une recherche exhaustive. On ignore ce pendant comment énumérer les phrases-mots de passe afin d ’exploiter cela. Tant que nous ne comprendrons pas mieux la manière d’attaquer les phrases-mots de passe, nous n’aurons aucune idée de leur robustesse. 6. Une confiance mal placée. La plupart des programmes de cryptographie actuel lement disponibles supposent que l’utilisateur exerce un contrôle direct sur les systèmes auxquels il fait appel et emprunte un chemin sûr. Par exemple, les inter faces vers un programme tel que P G P supposent que la saisie des phrases-mots
Postface de Matt Blaze
653
de passe est toujours opérée par l’utilisateur et par une voie sûre, telle qu’une console locale. Ce n’est pas toujours le cas, bien sûr ; considérez le problème de la lecture de votre courrier chiffré quand vous êtes connecté à un réseau. Ce que l’éditeur de système pense être sûr peut ne pas répondre aux besoins et aux at tentes des utilisateurs, tout particulièrement quand le logiciel peut être contrôlé à distance à travers des réseaux peu sûrs. 7. Des interactions de protocole et de service mal comprises. Au fur et à mesure que les systèmes grossissent et deviennent plus complexes, des fonctionnalités bénignes reviennent fréquemment nous hanter, et il est dur de savoir où chercher l’erreur. INTERNET s’est propagé via une fonction obscure et à l’apparence inno cente qu’est le programme d ’envoi de courrier; combien encore de fonctions dans combien d’autres programmes ont des conséquences inattendues qui attendent juste d ’être découvertes?
8. Une évaluation qui n’est pas réaliste de la menace et des risques. Les experts de la sécurité ont tendance à se concentrer sur les menaces qu’ils connaissent et dont ils savent se protéger. Hélas, les pirates se concentrent sur ce qu’ils savent exploiter, et les deux visions sont rarement identiques. De trop nombreux systèmes « sûrs » sont réalisés sans considérer ce que les pirates sont vraiment susceptibles de faire. 9. Les interfaces qui rendent la sécurité chère et spéciale. Si des fonctions de sécurité peuvent être utilisées, elles doivent être assez pratiques et transparentes pour que les gens puissent les activer. Il est facile de réaliser des mécanismes de chiffrement au seul prix de la performance ou de la facilité d ’emploi, et il est encore plus facile de réaliser des mécanismes qui poussent à l’erreur. La sécurité devrait être plus dure à désactiver qu’à activer ; seulement, peu de systèmes fonctionnent vraiment comme cela. 10. Peu d’engoûment général pour la sécurité. C ’est un problème bien connu de la plupart de ceux qui ont voulu faire fortune en vendant des produits et des services de sécurité. Tant qu’il n’y aura pas une large demande pour une sécurité transparente, les outils et l’infrastructure nécessaires pour la supporter seront chers et maccessibles pour beaucoup d’applications. C ’est en partie un problème de compréhension et d’explication des menaces et des risques dans les applications réelles, mais aussi un défaut des systèmes qui n’incluent pas la sécurité comme une fonction de base mais plutôt comme un additif. Une liste et une discussion plus complètes sur ce type de menaces pourrait facilement remplir un livre de cette taille sans pour autant égratigner la surface du problème. Ce qui les rend spécialement difficiles et dangereuses est qu’il n’existe pas de techniques magiques, mis à part une bonne organisation et une surveillance de tous les instants. La leçon pour un aspirant cryptographe est qu’il faut respecter les limites de l’art. M att B l a z e
New York, NY
Cinquième partie Code source
DES d3des.h /* d3des.h -
* *
Headers and defines for d3des.c
*
Graven Imagery,
1992.
* * Copyright (c) 1988,1989,1990,1991,1992 by Richard Outerbridge *
(GEnie : OUTER; CIS : [71755,204])
*/ #define D2_DES
/* include double-length support */
#define D3_DES
/* include triple-length support */
#ifdef D3_DES #ifndef D2_DES /* D2_DES is needed for D3_DES */
#define D2.DES #endif #endif #define ENO
0
/ * MODE == encrypt */
#define DE1
1
/* MODE == decrypt * /
/ * A useful alias on 68000-ish machines, but NOT USED HERE. */ typedef imion { unsigned long b l o k [2]; unsigned short w o r d [ 4 ] ; unsigned char byte[8]; > M68K; typedef union -[ unsigned long d b l ok[4]; unsigned short d w o rd[8]; unsigned char dbyte[16]; > M68K2 ; extern void deskey(unsigned char *, short); /*
h e x k e y [8]
MODE
DES
658 * Sets the internai key register according to the hexadécimal * key contained in the 8 bytes of hexkey,
according to the DES,
* for encryption or decryption according to MODE.
*/ extern void usekey(unsigned long *); /*
c ookedkey[32]
* Loads the internai key register with the data in cookedkey.
*/ extern void cpkey(unsigned long *); /*
cookedkey [32]
* Copies the contents of the internai key register into the storage * located at fecookedkey[0].
*/ extern void des(unsigned char *, unsigned char *); /*
from[8]
to[8]
* Encrypts/Decrypts (according to the key currently loaded in the * internai key register) one block of eight * into
the
block at address ’t o ’.
bytes at address
They can
’f r o m ’
be the same.
*/ #ifdef D2_DES #define desDkey(a.b)
des2key((a), (b))
extern v oid des2key(unsigned char *, short); /*
h e x k e y [16]
MODE
* Sets
the internai
key registerS according to the hexadécimal
* keyS
contained in the 16 bytes of hexkey, according to the DES,
* for DOUBLE encryption or decryption according to MODE. * NOTE: this clobbers ail three key registers!
*/ extern void Ddes(unsigned char *, unsigned char *); /*
from[8]
to[8]
* Encrypts/Decrypts (according to the keyS currently loaded in the * internai
key registerS) one block of eight bytes
at address ’f r o m ’
* into the
block at address
the
’t o ’ .
They can be
same.
*/ extern void D2des(unsigned char *, unsigned char *); /*
from[16]
to[16]
* Encrypts/Decrypts (according to the keyS currently loaded in the * internai
key registerS) one block of SIXTEEN
bytes at address ’f r o m ’
* into the
block at address ’t o ’.
the
They can be
same.
*/ extern void makekey(char *, unsigned char *); /*
*password,
single-length k e y [8]
* With a double-length default key, this routine hashes a NULL-terminated
659
DES
* string into an eight-byte random-looking key, suitable for use with the * deskeyO
routine.
*/ #define makeDkey(a,b)
make2key((a),(b))
extern void make2key(char *, unsigned char *); /*
*password,
double-length k e y [16]
* With a double-length default key, this routine hashes a NULL-terminated * string into a sixteen-byte random-looking key, suitable for use with the * des2key() routine.
*/ #ifndef D3_DES
/ * D2_DES only */
#define useDkey(a)
use2key((a))
#define cpDkey(a)
cp2key((a))
extern void use2key(unsigned long *); /*
c ookedkey[64]
* Loads the internai key registerS with the data in cookedkey. * NOTE: this clobbers ail three key registers!
*/ extern void cp2key(unsigned long *) ; /*
cookedkey[64]
* Copies the contents of the internai key registerS into the storage * located at ftcookedkey[0].
*/ #else
/* D3_DES too */
#define useDkey(a)
use3key((a))
#define cpDkey(a)
cp3key((a))
extern void des3key(unsigned char *, short); /*
h e x k e y [24]
MODE
* Sets the internai key registerS according to the hexadécimal * keyS contained in the 24 bytes of hexkey,
according to the DES,
* for DOUBLE encryption or decryption according to MODE.
*/ extern void use3key(unsigned long *); /* cookedkey[96] * Loads the 3 internai key registerS with the data in cookedkey.
*/ extern void cp3key(unsigned long *); /*
cookedkey[96]
* Copies the contents of the 3 internai key registerS into the storage * located at &c o o kedkey[0].
*/
660
D ES
extern void make3key(char *, unsigned char *); /*
*password,
triple-length key[24]
* With a triple-length default key, this routine hashes a NULL-terminated * string into a twenty-four-byte random-looking key, suitable for use with * the des3key() routine.
*/ #end^f
/* D3_DES */
#endif
/ * D2.DES */
/* d3des.h V 5 .09 rwo 9208.04 15:06 Graven Imagery
d3des.c /* D3DES (V5.0A) *
* A portable, public domain, version of the Data Encryption Standard.
* * Written with S y m a n t e c ’s THINK (Lightspeed) C by Richard Outerbridge. * Thanks to: Dan Hoey for his excellent Initial and Inverse permutation * code;
Jim Gillogly & Phil Karn for the DES key schedule code; Dennis
* Ferguson, Eric Young and Dana How for comparing notes; and Ray Lau, * for humouring me on.
* * Copyright (c) 1988,1989,1990,1991,1992 by Richard Outerbridge. * .(GEnie : 0UTER; CIS : [71755,204]) Graven Imagery,
1992.
*/ #include "d3des.h" static void
scrunch(unsigned
char *, unsigned
static void
unscrun(unsigned
long *, unsigned
long *); char *);
static void
desfunc(unsigned
long *, unsigned
long *);
static void cookey(unsigned long *); static unsigned
long KnL[32] = { 0L };
static unsigned
long KnR[32] = { 0L >;
static unsigned
long Kn3[32] = { 0L };
static unsigned
char Df_Key[24] = {
0x01,0x23,0x45,0x67,0x89,0xab,0xcd,0xef, Oxf e ,O x d c ,Oxba,0x98,0x76,0x54,0x32,0x10, 0x89,O x a b ,O x c d ,O x e f ,0x01,0x23,0x45,0x67 }; static unsigned short bytebit [8]
= {
0200, 0100, 040, 020, 010, 04, 02, 01 }; static unsigned long bigbyte[24] = { 0 x 8 0 0 0 0 0L,
0 x400000L,
0x200000L,
OxlOOOOOL,
661
DES
0 x 8 0 0 0 0 L,
0 x 4 0000L,
0x20000L,
OxlOOOOL,
0x8000L,
0x4000L,
0x2000L,
OxlOOOL,
0x800L,
0x400L,
0x200L,
OxlOOL,
0x80L,
0x40L,
0x20L,
OxlOL,
0x8L,
0x4L,
Ox2L,
OxlL
>;
/ * Use the key schedule specified in the Standard (ANSI X3.92-1981). */ static unsigned char pci [56] = -( 56, 48, 9,
40, 32, 24, 16,
8,
1,
58, 50, 42, 34, 26,
62, 54,
46, 38, 30, 22, 14,
13,
60, 52, 44, 36, 28,
5,
0, 57, 49, 41, 33, 25, 18, 10,
17,
2, 59, 51, 43,
35,
6, 61, 53, 45, 37, 29,
21,
20, 12,
4, 27, 19, 11,
3 };
static unsigned char totrot[16] = -[ 1,2,4,6,8,10,12,14,15,17,19,21,23,25,27,28 >; static unsigned char pc2[48] = { 13, 16,
10, 23,
22, 18,
11,
0,
4,
40, 51,
30, 36, 46, 54, 29, 39, 50, 44, 32, 47,
3, 25,
2, 27,
7, 15,
5, 20,
9,
6, 26, 19, 12,
14,
1,
43, 48, 38, 55, 33, 52, 45, 41, 49, 35, 28, 31 }; void deskey(key, edf)
/* Thanks to James Gillogly & Phil Karn!
unsigned char * k e y ; short e d f ;
1 int i, j, 1, m, n; unsigned char pclm[56] , pcr[56] ; unsigned long k n [ 3 2 ] ; for ( j = 0; j < 56; j++ ) { 1 = pcl[j] ; m = 1 & 07; pclm[j] = (key[l »
3] & bytebitDn]) ? 1 : 0;
> for( i = 0; i < 16; i++ ) { i f ( edf == DE1 ) m = (15 - i) «
1;
else m = i << 1; n = m + 1; kn[m] = kn[n] for( j = 0;
= OL;
j < 28; j++ ) {
1 =
j + totrot [i] ;
if(
1 < 28 ) pcr[j] = pclm[l] ;
else pcr[j] = pclm[l - 28] ;
> for( j = 28; j < 56; j++ ) { 1 = j + totrot [i] ; if( 1 < 56 ) pcr[j] = pclm[l]; else pcr[j] = pclm[l - 28];
>
*/
DES
662
for( j = 0; j < 24; j++ ) { i f ( pcr [pc2[j]]
) kn[m]
1= bigbyte[j];
i f ( pcr[pc2[j+24]] ) kn[n]
|= bigbyte[j];
} } cookey(kn); return;
> static void cookey(rawl) unsigned long *rawl;
{ unsigned long *cook, ♦rawO; unsigned long d ough[32]; int i; cook = dough; for( i = 0; i < 16; i++, rawl++ ) { rawO = rawl++; = (♦rawO & OxOOfcOOOOL) « ♦cook ♦cook ♦cook ♦cook++ ♦cook ♦cook ♦cook ♦cook++
1= (♦rawO & OxOOOOOfcOL) « 1= (♦rawl & OxOOfcOOOOL) » 1= (♦rawl & OxOOOOOfcOL) » = (♦rawO & 0x0003f000L) « 1= (♦rawO & 0x0000003fL) « 1= (♦rawl & OxOO03fOOOL) » 1= (♦rawl & 0x0000003fL) 1
> u s ekey(dough); return;
> void cpkey(into) unsigned long *into; unsigned long *from, ♦endp; from = KnL, endp = &KnL[ 3 2 ] ; w h i l e ( from < endp ) *into++ = ♦from+t; return;
} void usekey(from) unsigned long *from; unsigned long *to, *endp; to = KnL, endp = & K n L [32]; w h i l e ( to < endp ) *to++ = *from++; return;
}
6; 10; 10; 6; 12; 16; 4;
663
DES
v o id d e s ( in b lo c k ,
o u tb lo c k )
u n s ig n e d c h a r * i n b l o c k ,
* o u tb lo c k ;
u n s ig n e d l o n g w o r k [ 2 ] ; s c r u n c h (in b lo c k , w o rk ); d e s f u n c ( w o r k , K n L ); u n s c r u n (w o r k ,
o u tb lo c k );
retu rn ;
> s t a t i c v o id s c r u n c h (o u to f, in t o ) u n s ig n e d c h a r * o u t o f ; u n s ig n e d l o n g * i n t o ; ♦i n t o ♦i n t o ♦ in to ♦ in t o + + ♦ in to ♦ in to ♦i n t o ♦ in to retu rn ;
= (♦ O U to f++ ft O x f fL ) « 1= (♦ O U to f++ & O x ffL ) « 1= ( ♦ o u t o f ++ & O x f fL ) « 1= C * o u t o f ++ & O x f f L ) ; = ( * o u t o f + + k O x f fL ) « 1= ( * o u t o f + + & O x f fL ) « 1= ( * o u t o f ++ & O x f fL ) « & O x ffL ); 1= ( * o u t o f
24; 16; 8; 24; 16; 8;
> s t a t i c v o id u n s c r u n (o u t o f, in t o ) u n s ig n e d l o n g * o u t o f ; u n s ig n e d c h a r * i n t o ; * in to + + = (u n sig n e d c h a r ) ( ( * o u t o f » * in to + + = (u n s ig n e d c h a r ) ( ( * o u t o f » * i n t o + + = ( u n s ig n e d c h a r ) ( ( * o u t o f »
2 4 ) & O x ffL ) 1 6 ) & O x f fL ) 8 ) k O x f fL )
* in t o + + = ( u n s i g n e d c h a r ) ( * o u t o f ++ * in to + + = (u n sig n e d c h a r ) ( ( * o u t o f »
2 4 ) k O x f fL )
»
1 6 ) k O x f fL )
* in to + + = (u n s ig n e d c h a r ) ( ( * o u t o f » = ( u n s ig n e d c h a r ) ( * o u t o f ♦ in to
8 ) k O x f fL ) k O x ffL )
* in to + + = (u n s ig n e d c h a r ) ( (♦ o u to f
k O x f fL )
retu rn ;
> s t a t i c u n s ig n e d l o n g SP1C64] = { 0 x 0 1 0 1 0 4 0 0 L , OxOOOOOOOOL, OxOOOlOOOOL, 0 x 0 1 0 1 0 4 0 4 L , 0 x 0 1 0 1 0 0 0 4 L , 0 x 0 0 0 1 0 4 0 4 L , 0 x 0 0 0 0 0 0 0 4 L , OxOOOlOOOOL, 0x00000400L , 0x01010400L , 0x01010404L , 0x00000400L , 0 x 0 1 0 0 0 4 0 4 L , 0 x 0 1 0 1 0 0 0 4 L , OxOlOOOOOOL, 0 x 0 0 0 0 0 0 0 4 L , 0x00000404L , 0x01000400L , 0x01000400L , 0x00010400L , 0 x 0 0 0 1 0 4 00 L , OxOlOlOOOOL, OxOlOlOOOOL, 0 x 0 1 0 0 0 4 0 4 L , 0x00010004L, 0x01000004L, 0x01000004L , 0x00010004L, OxOOOOOOOOL, 0 x 0 0 0 0 0 4 0 4 L , 0 x 0 0 0 1 0 4 0 4 L , OxOlOOOOOOL,
DES
664
OxOOOlOOOOL, 0x01010404L, 0x00000004L, 0x01010400L, OxOlOOOOOOL, OxOlOOOOOOL, 0x01010004L, OxOOOlOOOOL, 0x00010400L, 0x00000400L, 0x00000004L, 0x01000404L, 0x01010404L, OxOOO10004L, OxOlOlOOOOL, 0x01000004L, 0x00000404L, 0x00010404L, 0x00000404L, 0x01000400L, 0x01000400L, 0x00010004L, 0x00010400L, OxOOOOOOOOL,
OxOlOlOOOOL, 0x00000400L, 0x01000004L, 0x00010404L, 0x01000404L, 0x01010400L, OxOOOOOOOOL, 0x01010004L >;
static unsigned long SP2 [64] = { 0x80108020L, 0x80008000L, 0x00008000L, OxOOlOOOOOL, 0x00000020L, 0x80100020L, 0x80000020L, 0x80108020L, 0x80108000L, 0x80008000L, OxOOlOOOOOL, 0x00000020L, 0x00108000L, 0x00100020L, 0x80008020L, 0x80000000L, 0x00008000L, 0x00108020L, 0x00100020L, 0x80000020L, OxOOOOOOOOL, 0x00008020L, 0x80108000L, 0x80100000L, OxOOOOOOOOL, 0x00108020L, 0x80100020L, 0x80008020L, 0x80100000L, 0x80108000L, 0x80100000L, 0x80008000L, 0x00000020L, 0x00108020L, 0x00000020L, 0x00008000L, 0x00008020L, 0x80108000L, OxOOlOOOOOL, 0x00100020L, 0x80008020L, 0x80000020L, 0x00108000L, OxOOOOOOOOL, 0x80008000L, 0x80000000L, 0x80100020L, 0x80108020L,
0x00108020L, 0x80008020L, 0x80000000L, 0x80100020L, OxOOOOOOOOL, 0x80100000L, 0x00108000L, 0x00008020L, OxOOlOOOOOL, 0x00008000L, 0x80108020L, 0x80000000L, 0x80000020L, 0x00100020L, 0x00008020L, 0x00108000L };
static unsigned long SP3[64] = { 0x00000208L, 0x08020200L, OxOOOOOOOOL, 0x08000200L, OxOOOOOOOOL, 0x00020208L, 0x00020008L, 0x08000008L, 0x08000008L, 0x08020208L, 0x00020008L, 0x08020000L, 0x08000000L, 0x00000008L, 0x08020200L, 0x00020200L, 0x08020000L, 0x08020008L, 0x08000208L, 0x00020200L, 0x00020000L, 0x00000008L, 0x08020208L, 0x00000200L, 0x08020200L, 0x08000000L, 0x00020008L, 0x00020000L, 0x08020200L, 0x08000200L, 0x00000200L, 0x00020008L, 0x08020208L, 0x08000008L, 0x00000200L, OxOOOOOOOOL, 0x08000208L, 0x00020000L, 0x08000000L, 0x00000008L, 0x00020208L, 0x00020200L, 0x08020000L, 0x08000208L, 0x00000208L, 0x00020208L, 0x00000008L, 0x08020008L,
0x08020008L, 0x08000200L, 0x00020000L, 0x00000208L, 0x00000200L, 0x00020208L, 0x08000208L, 0x08000000L, 0x00000208L, OxOOOOOOOOL, 0x08000200L, 0x08020008L, 0x08020208L, 0x08000008L, 0x08020000L, 0x00020200L >;
static unsigned long SP4 [64] = { 0x00802001L, 0x00002081L, 0x00802080L, 0x0080008IL, OxOOOOOOOOL, 0x00802000L, 0x00000081L, OxOOOOOOOOL, 0x0000000IL, 0x00002000L,
0x00000080L, 0x0000200IL, 0x0080208IL, 0x00800001L, 0x0080200IL,
0x00002081L, 0x0080000IL, 0x00802000L, 0x00800080L, 0x00800000L,
665
DES
0x00000080L, 0x00800000L , 0x00002001L , 0x00002080L, 0 x 0 0 8 0 0 0 8 1 L , OxOOOOOOOlL, 0 x 0 0 0 0 2 0 8 0 L , 0 x 0 0 8 0 0 0 8 0 L , 0 x 0 0 0 0 2 0 0 0 L , 0 x 0 0 8 0 2 0 8 0 L , 0 x 0 0 8 0 2 0 8 I L , 0 x 0 0 0 0 0 0 8 IL , 0x00800080L , 0x00800001L , 0x00802000L , 0x00802081L, 0 x 0 0 0 0 0 0 8 I L , OxOOOOOOOOL, OxOOOOOOOOL, 0 x 0 0 8 0 2 0 0 0 L , 0 x 0 0 0 0 2 0 8 0 L , 0 x 0 0 8 0 0 0 8 0 L , 0 x 0 0 8 0 0 0 8 1 L , OxOOOOOOOlL, 0x0080200IL , 0x0000208IL , 0x00002081L , 0x00000080L, 0 x 0 0 8 0 2 0 8 1 L , 0 x 0 0 0 0 0 0 8 1 L , OxOOOOOOOlL, 0 x 0 0 0 0 2 0 0 0 L , 0x0080000I L , 0x00002001L , 0x00802080L , 0x00800081L , 0x0 0 0 0 20 0 IL ,
0x00002080L , 0x00800000L , 0x00802001L ,
0x00000080L , 0x00800000L , 0x00002000L , 0x00802080L > ; s t a t i c u n s ig n e d l o n g S P 5 [6 4 ] = { 0 x00000100L, 0x02080100L , 0x02080000L , 0x42000100L, 0 x 0 0 0 8 0 0 0 0 L , OxOOOOOlOOL, 0 x 4 0 0 0 0 0 0 0 L , 0 x 0 2 0 8 0 0 0 0 L , 0x4 0 0 8 0 100L, 0x00080000L , 0x02000100L , 0x40080100L , 0x42000100L , 0x42080000L , 0x00080100L , 0x40000000L, 0 x 0 2 0 0 0 0 0 0 L , 0 x 4 0 0 8 0 0 0 0 L , 0 x 4 0 0 8 0 0 0 0 L , OxOOOOOOOOL, 0x40000100L , 0x42080100L , 0x42080100L , 0x02000100L , 0 x 4 2 0 8 0 0 0 0 L , 0 x 4 0 0 0 0 1 0 0 L , OxOOOOOOOOL, 0 x 4 2 0 0 0 0 0 0 L , 0x02080100L ,
0x02000000L , 0x42000000L , 0x00080100L ,
0 x 0 0 0 8 0 0 0 0 L , 0 x 4 2 0 0 0 1 0 0 L , OxOOOOOlOOL, 0 x 0 2 0 0 0 0 0 0 L , 0x40000000L , 0x02080000L , 0x42000100L , 0x40080100L , 0 x 0 2 0 0 0 1 0 0 L , 0 x 4 0 0 0 0 0 0 0 L , 0 x 4 2 0 8 0 0 0 0 L , 0 x 0 2 0 8 0 100L , 0 x 4 0 0 8 0 1 0 0 L , OxOOOOOlOOL, 0 x 0 2 0 0 0 0 0 0 L , 0 x 4 2 0 8 0 0 0 0 L , 0x42080100L , 0x00080100L , 0x42000000L , 0x42080100L, 0 x 0 2 0 8 0 0 0 0 L , OxOOOOOOOOL, 0 x 4 0 0 8 0 0 0 0 L , 0 x 4 2 0 0 0 0 0 0 L , 0 x 0 0 0 8 0 100L, 0 x 0 2 0 0 0 100L, 0 x40000100L , 0x00080000L , OxOOOOOOOOL, 0 x 4 0 0 8 0 OOOL, 0 x 0 2 0 8 0 1 0 0 L , 0 x 4 0 0 0 0 1 0 0 L > ; s t a t i c u n s ig n e d l o n g SP6C64] = { 0 x 2 0 0 0 0 0 1 0 L , 0 x 2 0 4 0 0 0 0 0 L , 0 x 0 0 0 0 4 0 0 0 L , 0 x 2 0 4 0 4 0 10L , 0 x 2 0 4 0 0 0 0 0 L , OxOOOOOOIOL, 0 x 2 0 4 0 4 0 1 0 L , 0 x 0 0 4 0 0 0 0 0 L , 0x20004000L , 0x00404010L , 0x00400000L , 0x20000010L , 0x00400010L , 0x20004000L , 0x20000000L , 0x00004010L , OxOOOOOOOOL, 0 x 0 0 4 0 0 0 1 0 L , 0 x 2 0 0 0 4 0 1 0 L , 0 x 0 0 0 0 4 0 0 0 L , 0 x 0 0 4 0 4 0 0 0 L , 0 x 2 0 0 0 4 0 1 0 L , OxOOOOOOIOL, 0 x 2 0 4 0 0 0 1 0 L , 0 x 2 0 4 0 0 0 1 0 L , OxOOOOOOOOL, 0 x 0 0 4 0 4 0 1 0 L , 0 x 2 0 4 0 4 0 0 0 L , 0x00004010L , 0x00404000L , 0x20404000L , 0x20000000L, 0 x 2 0 0 0 4 0 0 0 L , OxOOOOOOIOL, 0 x 2 0 4 0 0 0 1 0 L , 0 x 0 0 4 0 4 0 0 0 L , 0x20404010L , 0x00400000L , 0x00004010L , 0x20000010L , 0x00400000L , 0x20004000L , 0x20000000L , 0x00004010L, 0x20000010L , 0 x 2 0 4 0 40 10L, 0x00404000L , 0x20400000L , 0 x 0 0 4 0 4 0 1 0 L , 0 x 2 0 4 0 4 0 0 0 L , OxOOOOOOOOL, 0 x 2 0 4 0 0 0 1 0 L , OxOOOOOOIOL, 0 x 0 0 0 0 4 0 0 0 L , 0 x 2 0 4 0 0 0 0 0 L , 0 x 0 0 4 0 4 0 1 0 L , 0 x 0 0 0 0 4 0 0 0 L , 0 x 0 0 4 0 0 0 1 0 L , 0 x 2 0 0 0 4 0 1 0 L , OxOOOOOOOOL, 0 x20404000L , 0x20000000L , 0 x00400010L , 0x20004010L > ; s t a t i c u n s ig n e d l o n g S P 7 [6 4 ] = { 0 x 0 0 2 0 0 0 0 0 L , 0 x 0 4 2 0 0 0 0 2 L , 0 x 0 4 0 0 0 8 0 2 L , OxOOOOOOOOL, 0x00000800L , 0x04000802L , 0x00200802L , 0x04200800L ,
666
DES
0 x 0 4 2 0 0 8 0 2 L , 0 x 0 0 2 0 0 0 0 0 L , OxOOOOOOOOL, 0 x 0 4 0 0 0 0 0 2 L , 0 x00000002L , 0x04000000L , 0 x0 4 2 0 0002L , 0x00000802L , 0x04000800L , 0x00200802L, 0x00200002L , 0x04000800L, 0x04000002L , 0x04200000L , 0x04200800L , 0x00200002L , 0x04200000L , 0x00000800L , 0x00000802L , 0x04200802L, 0x00200800L, 0x00000002L, 0x04000000L, 0x00200800L, 0x04000000L, 0x00200800L, 0x00200000L, 0x04000802L, 0x04000802L , 0x04200002L , 0x04200002L , 0x00000002L , 0x00200002L , 0x04000000L,
0x04000800L , 0x00200000L ,
0x04200800L , 0x00000802L, 0x00200802L , 0x04200800L , 0x00000802L , 0x04000002L , 0x04200802L, 0x04200000L, 0 x 0 0 2 0 0 8 0 0 L , OxOOOOOOOOL, 0 x 0 0 0 0 0 0 0 2 L , 0 x 0 4 2 0 0 8 0 2 L , OxOOOOOOOOL, 0 x 0 0 2 0 0 8 0 2L , 0 x 0 4 2 0 0 0 0 0 L , 0 x 0 0 0 0 0 8 0 0 L , 0 x 0 4 0 0 0002L ,
0 x 0 4 0 0 0 8 0 0 L , 0 x 0 0 0 0 0 8 0 0 L , 0 x0 0 2 0 0 0 0 2 L > ;
s t a t i c u n s ig n e d l o n g S P 8 [6 4 ] = -f 0 x l0 0 0 1 0 4 0 L , OxOOOOlOOOL, 0 x 0 0 0 4 0 0 0 0 L , 0 x l0 0 4 1 0 4 0 L , OxlOOOOOOOL, 0 x l0 0 0 1 0 4 0 L , 0 x 0 0 0 0 0 0 4 0 L , OxlOOOOOOOL, 0 x 0 0 0 4 0 0 4 0 L , 0 x l0 0 4 0 0 0 0 L , 0 x l0 0 4 1 0 4 0 L , 0 x 0 0 0 4 1 0 0 0 L , 0 x l0 0 4 1 0 0 0 L , 0 x 0 0 0 4 1 0 4 0 L , OxOOOOlOOOL, 0 x 0 0 0 0 0 0 4 0 L , 0 x l0 0 4 0 0 0 0 L , 0 x l0 0 0 0 0 4 0 L , OxlOOOlOOOL, 0 x 0 0 0 0 1 0 4 0 L , 0 x 0 0 0 4 1 0 0 0 L , 0 x 0 0 0 4 0 0 4 0 L , 0 x l0 0 4 0 0 4 0 L , 0 x l0 0 4 1 0 0 0 L , 0 x 0 0 0 0 1 0 4 0 L , OxOOOOOOOOL, OxOOOOOOOOL, 0 x l0 0 4 0 0 4 0 L , 0 x l0 0 0 0 0 4 0 L , OxlOOOlOOOL, 0 x 0 0 0 4 1 0 4 0 L , 0 x 0 0 0 4 0 0 0 0 L , 0 x 0 0 0 4 1 0 4 0 L , 0 x 0 0 0 4 0 0 0 0 L , 0 x l0 0 4 1 0 0 0 L , OxOOOOlOOOL, 0 x 0 0 0 0 0 0 4 0 L , 0 x l0 0 4 0 0 4 0 L , OxOOOOlOOOL, 0 x 0 0 0 4 1 0 4 0 L , OxlOOOlOOOL, 0 x 0 0 0 0 0 0 4 0 L , 0 x l0 0 0 0 0 4 0 L , 0 x l0 0 4 0 0 0 0 L , 0 x l0 0 4 0 0 4 0 L , OxlOOOOOOOL, 0 x 0 0 0 4 0 0 0 0 L , 0 x l0 0 0 1 0 4 0 L , OxOOOOOOOOL, 0 x l0 0 4 1 0 4 0 L , O x0 0 0 4 00 4 0 L , 0 x l0 0 0 0 0 4 0 L , 0 x l0 0 4 0 0 0 0 L ,
OxlOOOlOOOL, 0 x l0 0 0 1 0 4 0 L , OxOOOOOOOOL,
0 x l0 0 4 1 0 4 0 L , 0 x 0 0 0 4 1 0 0 0 L , 0 x 0 0 0 4 1 0 0 0 L , 0 x 0 0 0 0 1 0 4 0 L , 0 x 0 0 0 0 1 0 4 0 L , 0 x 0 0 0 4 0 0 4 0 L , OxlOOOOOOOL, 0 x l0 0 4 1 0 0 0 L } ; s t a t i c v o id d e s fu n e (b lo c k , k e y s) u n s ig n e d l o n g * b l o c k , * k e y s ;
{ u n s ig n e d l o n g f v a l ,
w ork , r i g h t ,
le ftt ;
in t rou n d ; le ftt
= b lo c k C O ];
r i g h t = b l o c k [1 ] ; w ork = ( ( l e f t t
»
4)
* r ig h t)
& O xO fO fO fO fL ;
r i g h t ~= w o rk ; le ftt
“ = (w o rk «
w o rk = ( ( l e f t t
4 );
>> 1 6 )
" r i g h t ) & O xO O O O ffffL ;
r i g h t " = w o rk ; le ftt
“ = (w o rk << 1 6 ) ;
w ork = ( ( r i g h t »
“ le ftt)
& 0x33333333L;
r i g h t ~= (w o rk «
2 );
w ork = ( ( r i g h t »
8) * le f t t )
& O xO O ffO O ffL ;
le ftt
2)
“ = w o rk ;
667
DES
leftt ~= work ; right ~= (work « 8); right = ((right « 1) 1 ((right »
31) & IL)) & OxffffffffL;
work = (leftt “ right) & OxaaaaaaaaL; leftt '= work; right "= work; leftt
= ((leftt «
for( round =
1)
I ((leftt » 31)
& IL)) & OxffffffffL;
0; round < 8; round++ ) {
work
= (right «
28)
| (right »
4);
w ork ~= *keys++; fval
= SP7[ work
fval
& 0x3fL];
|= S P 5 [(work »
8) & 0 x 3 f L ] ;
fval
1= SP3[(work »
16) & 0x3fL] ;
fval
|= SPl[(work »
24) & 0 x 3 f L ] ;
work
= right ' *keys++;
fval
1= SP8[ work
fval
& 0x3fL];
1= SP6[(work »
8) & 0 x 3 f L ] ;
fval 1= SP4[(work »
16) & 0 x 3fL];
fval
24) & 0 x 3 f L ] ;
1= SP2[(work »
leftt ~= fval; work
= (leftt «
28)
I (leftt »
work ~= *keys++; fval = SP7[ work
4); & 0x3fL];
fval
|=
SP5[(work »
8) & 0 x 3 f L ] ;
fval
1=
SP3[(work »
16) & 0 x 3fL];
fval
|=
SPl[(work »
24) ft 0 x 3fL];
work
= leftt ' *keys++;
fval
I= S P 8 [ work
& 0 x 3fL];
fval
|=
SP6[(work »
8) & 0 x 3 f L ] ;
fval
1=
SP4[(work »
16) ft 0 x 3 f L ] ;
fval
|=
SP2[(work »
24) & 0 x 3 f L ] ;
right ~= fval;
> right = (right «
31)
I (right »
1);
work = (leftt * right) & OxaaaaaaaaL; leftt "= work; right ~= work; leftt = (leftt « 31) I (leftt » 1); work = ((leftt >> 8) ~ right) & OxOOffOOffL; right *= work; leftt
(work «
8);
work = ((leftt >> 2) “ right) & 0x33333333L; right '= work; leftt “= (work «
2);
work = ((right »
16) “ leftt) & OxOOOOffffL;
leftt “= work; right “= (work « work = ((right » leftt “= work;
16); 4) " leftt) & OxOfOfOfOfL;
668
DES
right “= (work << 4); ♦block++ = right; ♦block = leftt; return;
} ■#ifdef D2_DES void des2key(hexkey, mode)
/♦ stomps on Kn3 too ♦/
unsigned chair ♦hexkey;
/♦ unsigned c h a r [16] ♦/
short mode;
{ short revmod; revmod = (mode == ENO) ? DE1
: ENO;
d eskey(&hexkey[8], rev m o d ) ; cpkey(KnR); deskey(hexkey, mode); /♦ Kn3 = KnL ♦/
c p k e y(Kn3); return;
> void Ddes(from, into) unsigned char ♦from, ♦into;
/♦ unsigned c h a r [8] ♦/
{ unsigned long w o r k [2]; scrunch(from, w o r k ) ; desfunc(work, KnL); desfune(work, KnR) ; desfunc(work, K n 3 ) ; unscrun(work, into); return;
> void D2des(from, into) unsigned char ♦from;
/♦ unsigned char[16]
unsigned char ♦into;
/♦ unsigned c h a r [16] ♦/
i unsigned long ♦right,
+11, swap;
unsigned long leftt [2], bufR[2] ; right = bufR; 11 = ftleftt [1]; scrunch(from, l e f t t ) ; scrunch(&from[8], r i g h t ) ; d esfune(leftt, K n L ) ; de s f u n e(right, K n L ) ; swap = +11; ♦11 = ♦right; ♦right = swap;
♦/
669
DES
d e sfune(leftt, K n R ) ; d esfune(right, K n R ) ; swap = *11 ; *11 = *right; ♦right = swap; d esfune(leftt, K n 3 ) ; d esfune(right, K n 3 ) ; unscrun(leftt,
into);
unscrun(right, feinto[8]); return;
} void makekey(aptr, kptr) char *aptr;
/* NULL-terminated
unsigned char *kptr;
*/
/* unsigned c h a r [8] */
{ unsigned char *store; int first, i; unsigned long savek[96]; cpDkey(savek); des2key(Df_Key, ENO); for( i = 0; i < 8; i++ ) kptrti] = Df_Key[i] ; first = 1; w h i l e ( (*aptr != ’\ 0 ’) Il first ) { store = kptr; for( i = 0; i < 8 && (*aptr != ’\ 0 ’); i++ ) { *store++ ~= *aptr & 0x7f; *aptr++ = ’\ 0 ’;
> Ddes(kptr, kptr); first = 0;
> useDkey(savek); return;
> void ma k e 2 k ey(aptr, kptr) char *aptr;
/* NULL-terminated
unsigned char *kptr;
/* unsigned c h a r [16) */
{ unsigned char *store; int first, i; unsigned long savek[96]; cpDkey(savek); d es2key(Df_Key, ENO); for( i = 0; i < 16; i++ ) kptr[i] = Df_Key[i] ; first = 1; w h i l e ( (*aptr
!= ’\ 0 ’) Il first ) ■[
store = kptr;
*/
670
DES
for( i = 0; i < 16 && (*aptr != ’\ 0 ’); i++ ) { *store++ "= *aptr & 0x7f; *aptr++ = ’\ 0 ’;
> D2des(kptr, kptr); first = 0;
> u s e D k ey(savek); return;
> #ifndef D3_DES
/ * D2_DES only */
void cp2key(into) unsigned long *into;
/* unsigned long[64]
*/
i unsigned long *from, *endp; cpkey(into); into = &into[32]; from = KnR, endp = w h i l e ( from <
& K n R[32];
endp ) *into++ = *from++;
return;
> void use2key(from) unsigned long *from; unsigned long
/* stomps on Kn3 too */ / * unsigned l o n g [64] */ *to, *endp;
u s e k e y (from); from = & f r o m [32]; to = KnR, endp = & K n R[32]; w h i l e ( to < endp ) *to++ = *from++; /* Kn3 = KnL */
c p k e y(Kn3); return;
y #else
/ * D3_DES too */
static void D3des(unsigned char *, unsigned char *); void d es3key(hexkey, mode) unsigned char * hexkey; short mode;
{ unsigned char *first, *third; short revmod; if( mode == ENO ) { revmod = D E 1 ;
/ * unsigned c h a r [24] */
671
DES
first = hexkey; third = fchexkey[16];
> else -[ revmod = ENO; first = & h exkey[16]; third = hexkey;
} deskey(fehexkey[8], revmod); cpkey(KnR); deskey(third, mode); c pkey(Kn3); d e s key(first, mode); return;
} void cp3key(into) unsigned long *i n t o ;
/* unsigned l o n g [96] */
unsigned long *from, *endp; cpkey(into); into = ftinto[32]; from = KnR,
endp =
&KnR[32];
w h i l e ( from
< endp
) *intc++ =*from++;
from = K n 3 , endp = & K n 3 [32]; w h i l e ( from
< endp
) *into++ = *from++;
return;
} void use3key(from) unsigned long *from;
/* unsigned long[96]
*/
1 unsigned long *to, *endp; us e key(from); from = &from[32] ; to = KnR, endp = & K n R[32]; w h i l e ( to < endp ) *to++ - *from++; to = Kn3, endp = &Kn3[32]; w h i l e ( to < endp ) *to++ = *from++; return;
} static void D3des(unsigned char*, unsigned static void D3des(from, into)
/*
c h ar*);
amateur theatrics */
unsigned char *from;
/* unsigned c h a r [24] */
unsigned char *into;
/* unsigned
cha r [24] */
unsigned long swap, l e f t t [2], middl[2], r i g h t [2];
DES
672
scrunch(from, l e f t t ) ; scrunch(&from[8], m i d d l ) ; scrunch(&from[16], right); d e s f u n c(leftt, KnL); desfune(middl, K n L ) ; desfunc(right, KnL); swap = l e f t t [1]; leftt [1] = middl [0]; m i d d l [0] = swap; swap = m i d d l [1]; middl [1] = right [0]; right [0] = swap ; desfunc(leftt, KnR); de sfunc(middl, K n R ) ; de sfunc(right, K n R ) ; swap = leftt [1]; leftt [1] = middl [0]; m i d d l [0] = swap; swap = m i d d l [1]; middl [1] = right [0]; r i g h t [0] = swap; desfunc(leftt, Kn3); d e s f u n e(middl, K n 3 ) ; d e s f u n e(right, K n 3 ) ; u n s c r u n d e f t t , into); u nscrun(middl, feinto[8]); un s c r u n(right, feinto[16]); return;
} void mak e 3 k e y ( a ptr, kptr) char *aptr;
/* NULL-terminated
unsigned char * k p t r ;
*/
/* unsigned c h a r [24] */
f unsigned char *store; int first, i; unsigned long savek[96]; cp3key(savek); des3key(Df_Key, ENO); for( i = 0; i < 24; i++ ) kptr[i]
= Df_Key[i] ;
first = 1 ; while(
(*aptr != ’ \ 0 ’ )
Il first ) {
store = kptr; f o r ( i = 0; i < 24 && (*aptr != ’\ 0 ’); i++ ) { *store++ "= *aptr & 0 x 7 f ; *aptr++ = ’\ 0 ’;
> D3des(kptr, kptr); first = 0;
673
DES
> u s e 3 k e y (s a v e k ); retu rn ;
> # e n d if
/*
D3_DES * /
# e n d if
/*
D2_DES * /
/* V a lid a t io n
sets:
* * S in g le -le n g th k ey , * Key
: 0123
s in g le -le n g t h p la in te x t
-
4567 89ab c d e f
* P la in
: 0123
4567 89ab cd e7
* C ip h e r
: c95 7
4 4 2 5 6 a 5 e d31d
* * D o u b le -le n g th k e y , s i n g le -le n g t h p la in t e x t * Key
: 0123
4567 89ab c d e f f e d c
* P la in
: 0123
4567 89ab cd e7
* C ip h e r
:7 fld
0 a77 8 2 6 b 8 a f f
b a 9 8 7 654 3 2 1 0
* * D o u b le -le n g th k e y , d o u b le -le n g t h p la in t e x t * Key
: 0123
4567 89ab c d e f f e d c
ba98 7654 3210
* P la in
: 0123
4567 89ab c d e f 0123
4567 89ab c d f f
* C ip h e r
: 27a0
8440 406a d f6 0 2 7 8 f
4 7 c f 4 2 d 6 15d7
* * T r ip le -le n g th k ey,
s in g le -le n g t h p la in te x t -
* Key
: 0123
4567 89ab c d e f f e d c
* P la in
: 0123
4567 89ab cd e7
* C ip h e r
: deOb
7 c 0 6 a e 5 e 0 ed 5
b a 9 8 7 6 5 4 3 2 1 0 8 9 a b c d e f 0 1 2 3 4 567
* * T r ip le -le n g t h k e y , d o u b le -le n g t h p la in t e x t * K ey
: 0123
4567 89ab c d e f f e d c
b a 9 8 7 6 5 4 3 2 1 0 8 9 a b c d e f 0123 4 567
* P la in
: 0123
4567 89ab c d e f 0123
4567 89ab c d f f
* C ip h e r
: adOd
lb 3 0 a c l 7 c f 0 7 O e d l
l c 6 3 8 1 e 4 4 d e5
*
* d 3 d e s V 5.0 A rw o 9 2 1 1 .0 9 1 3 :5 5 G ra ven Im a g ery
LOKI 91 loki.i /* *
loki.i - contains the fixed permutation and substitution tables
*
for a 64 bit L0KI89 & LDKI91 implémentations.
* *
Modifications:
*
vl.O
original tables
Aug 1989 lpb
*
v2.0
add various speed/size versions
Apr 1990 lpb
* *
v2.1
install into RCS system for production control 5/90 lpb
v3.0
L0KI89 & L0KI91 now supported
10/92 lpb
*
*
Author: Laurence Brown
*
Aug 1989
Computer Science, UC UNSW, ADFA, Canberra, ACT 2600, Australia.
*
*
Copyright 1989 by Lawrence Brown and UNSW. Ail rights reserved.
*
This program may not be sold or used as inducement to buy a
*
product without the written permission of the author.
*/ / * 32-bit permutation function P */ /*
spécifiés which input bit is permuted to output bits */
/*
31 30 29 ... 2 1 0 respectively (ie in MSB to LSB order) */
char P[32] = { 31,
23, 15, 7, 30, 22,
14, 6,
29,
21, 13, 5, 28, 20,
12, 4,
27,
19, 11, 3, 26, 18,
10, 2,
25,
17, 9, 1, 24, 16, 8, 0
>; /* *
sfn_desc - a desriptor table specifying which irreducible polynomial
*
and exponent
*
the Loki S-box
is to be used for each of the 16 S functions
in
*/ typedef struct -{ short
gen;
/* irreducible polynomial used in
this field */
short
exp;
/* exponent used to generate this
s function */
} sfn_desc;
676
L O K I 91
/* *
sfn - the table specifying the irreducible polys & exponents used
*
in the Loki S-boxes for the Loki algorithm
*/ sfn_desc sfn[] = { /*
101 11 0 1 1 1 * / 3 7 5 , 101111011 * / 3 7 9 ,
/*
110 00 0 1 1 1 * / 3 9 1 ,
31}
/*
110001011 * / 3 9 5 ,
31}
/*
110 00 1 1 0 1 * / 3 9 7 , 3 1 } 1 1 0 011111 * / 4 1 5 , 3 1 } 1 10 10 0 0 1 1 * / 4 1 9 , 3 1 }
/*
/* /*
110101001 * / 4 2 5 , 1 1 0 11 0 0 0 1 * / 4 3 3 ,
/* /*
31} 31}
31} 31} 31}
/*
1 1 0 11 1 1 0 1 * / 4 4 5 , 11 1 00 0 0 1 1 * / 4 5 1 , 1 1 1 00 1 1 1 1 * / 4 6 3 ,
/*
111010111 * / 4 7 1 ,
31}
/* /*
111011101 * / 4 7 7 , 3 1 } 111100111 * / 4 8 7 , 3 1 }
/*
111110011 * / 4 9 9 ,
/* /*
00,
31} 31}
31}
00}
loki. h /* * * *
loki.h - spécifiés the interface to the LOKI encryption routines. This library proviloki routines to expand a key, encrypt and decrypt 64-bit data blocks.
The LOKI D ata Encryption Algorithm
*
is a block cipher which ensures that
*
function of its input and the key.
its output is
a complex
* *
Authors:
*
Lawrie Brown
Aug 1989
Matthew Kwan
Sep 1991
* *
Computer Science, UC UNSW, Australian Defence Force Academy,
*
Canberra, ACT 2600, Australia.
* *
Version:
*
vl.O -
of loki64.o is current 7/89 lpb
*
v2.0 -
of loki64.c is current 9/91 mkwan
*
v3.0 -
now have loki89.c & loki91.c 10/92 lpb
* *
Copyright 1989 by Lawrie Brown and UNSW. Ail rights reserved.
*
This program may not be sold or used as inducement
*
product without the written permission of
* *
Description:
to buy a
the author.
677
L O K I 91
*
The routines provided by the library are:
* *
lokikey(key)
*
- expands a key into subkey, for use
char k e y [8];
in
encryption and decryption opérations.
* *
enloki(b)
*
- main LOKI encryption routine, this
char b [8];
routine
encrypts one 64-bit block b with subkey
* *
deloki(b)
*
- main LOKI decryption routine, this
char b [ 8 ] ;
routine
decrypts one 64-bit block b with subkey
* *
The 64-bit d ata & key blocks used in the algorithm are specified as eight
*
unsigned chars. For the purposes of implementing the LOKI algorithm,
*
these MUST be word aligned with bits are numbered as follows:
* *
[63.-56]
[55..48]
b[0]
b[l]
in
... b[2]
b[3]
b[4]
[7..0] b[5]
b[6]
b[7]
*/ #define LOKIBLK 8
/* Ko of bytes in a LOKI data-block
*/
#define ROUNDS
/* Ko of LOKI rounds
*/
16
typedef unsigned long extern Long extern char #ifdef
Long; /* type spécification for aligned LOKI blocks */
lokikey[2];
/* 64-bit key used by LOKI routines
*loki_lib_ver;/* String with version no. & copyright
STDC
/* déclaré prototypes for library functions
*/ */ */
extern void enloki(char b[LOKIBLK]); extern void deloki(char b[LOKIBLK]); extern void setlokikey(char key[LOKIBLK] ) ; #else
/* else just déclaré library functions extern */
extern void e n l o k i O , d e l o k i O ,
setlokikey() ;
#endif __STDC__
loki91.c /* *
loki91.c - library routines for a 64 bit L0KI89 implémentation
* * Designed b y
Matthew Kwan and
*
Lawrence Brown
*
Modifications:
*
v2.0 - original set of code by mkwan 9/91
*
v3.0 - support both L0KI89 & L0KI91 versions
10/92 lpb
* *
Copyright 1991 by Lawrence Brown and UNSW. Ail rights reserved.
*
This prograin may not be sold or used as inducement to buy a
*
product without the written permission of the author.
*
L O K I 91
678 *
nb: if this program is compiled on a little-endian machine (eg Vax)
*
#define LITTLE_ENDIAN
*
in order to enable the byte swapping
routines
* *
if a detailed trace of L0KI91 function f is required for debugging
*
#define TRACE=n
n=l print blocks, n=2 print fn f also
*
n=3 print individual S-box cales also
* *
these routines assume that the 8-byte char arrays used to pass
*
the 64-bit blocks fall on a word
*
may be read as longwords for efficiency reasons.
boundary, so that the blocks
*
not true, the load & save
If this is
of the parameters will need changing.
*/
#include #include "loki.h"
/* include Interface Spécification header file */
#include "loki.i"
/* include Interface Spécification header file */
/* *
string specifying version and copyright message
*/ char
*loki_lib_ver = "L0KI91 library v3.0, Copyright (C) 1991 Lawrence Brown & UNSW";
Long
loki_subkeys[ROUNDS];
/* subkeys at the 16 rounds */
static Long
f ();
/* déclaré LOKI function f */
static short
sO;
/* déclaré LOKI S-box fn s */
/* *
R0L12(b)
- macro to rotate 32-bit block
b
left by 12 bits
*
R0L13(b)
- macro to rotate 32-bit block
b
left by 13 bits
*/ #define R0L12(b)
b = ((b «
12)
I (b »
20));
#define R0L13(b)
b = ((b «
13)
I (b »
19));
/* *
bswap(b) - exchanged bytes in each longword of a 64-bit data block
*
on little-endian machines where byte order is reversed
*/ #ifdef
LITTLE.ENDIAN
#define bswap(cb) -[ register char
\ c;
\
c = cb[0] ; cb [0] = cb [3] ; cb [3] = c ; c = cb[l] ; cb[l] = cb[2];
cb [2] = c ;
c = c b [4] ; cb[4] = cb [7] ; cb[7] = c; c = cb [5] ; cb [5] = cb [6] ; cb[6] = c;
> #endif
679
L O K I 91
/* *
setlokikey(key) - save 64-bit key for use in encryptions & décryptions
*
and compute sub-keys using the key schedule
*/ void setlokikey(key) char
/* Key to use, stored as an array of Longs
k e y[LOKIBLK];
*/
i register
i;
register Long
KL, KR;
#ifdef LITTLE_ENDIAN /* swap bytes round if little-endian * /
b s w a p(key); #endif #if
TRACE >= 1 fprintf (stderr, "
keyinit(%081x, */,081x) \n “ ,
((Long *)key)[0],
((Long *)key)[l]);
#endif KL = ((Long * ) key)[0]; K R = ((Long *)key) [1]; for (i=0; i
i+=4) {
/ * Generate the 16 subkeys */
loki_subkeys[i] = K L ; R0L12
(KL);
loki_subkeys[i+l] = KL; RDL13 (KL); loki_subkeys[i+2] = KR; R0L12 (KR); loki_subkeys[i+3] = KR; R0L13 (KR);
> Jfifdef LITTLE_ENDIAU bswap(key);
/* swap bytes back if little-endian */
#endif
}
/* * *
enloki(b) - main L0KI91 encryption routine, this routine encrypts one 64-bit block b using the LDKI91 algorithm with loki^subkeys
* * * * *
*
nb: The 64-bit block is passed as two longwords. For the purposes of the L0KI89 algorithm, the bits are numbered: [6362 .. 33 32] [31 30 ... 1 0] The L (left) half is b[0], the R (right) half is b[l]
680
L O K I 91
*/ void enloki
(b)
char
b [LOKIBLK];
{ register
i;
register Long
L, R;
/* left & right data halves
*/
#ifdef LITTLE_ENDIAN bswap(b);
/* swap bytes round if little-endian */
#endif #if
TRACE >= 1 fprintf (stderr, "
enlo k i ( ’/,0 8 1 x , y,081x)\n",
((Long *)b) [0] , ((Long *)b)[l]); #endif L = ((Long * ) b ) [0]; R = ((Long *)b) [1] ; for (i=0; i
{
/* Encrypt with the 16subkeys
*/
L ~= f (R, loki_subkeys[i]); R “= f (L, loki_subkeys[i+1] );
} ((Long *)b) [0] = R;
/* Y = swap(LR)
*/
((Long * ) b ) [1] = L; #if
TRACE >= 1 fprintf (stderr,"
enloki returns "/.081x, %081x\n",
((Long *)b) [0] , ((Long *)b)[l]); #endif #ifdef LITTLE_ENDIAN bswap(b);
/* swap bytes round if little-endian * /
#endif
>
/* *
deloki(b) - main
*
L0KI91 decryption
routine, this routine decrypts one
64-bit block b using the L0KI91 algorithm with loki_subkeys
* *
Decryption uses the same algorithm as encryption, except that
*
the subkeys are used in reverse order.
*/ void deloki(b) char
b [LOKIBLK];
681
L O K I 91
register
i;
register Long
L, R;
/* left ft right data halves
*/
#ifdef LITTLE_ENDIAN bswap(b);
/* swap bytes round if little-endian */
#endif #if
TRACE >= 1 fprintf (stderr, "
deloki(y,081x, °/„081x)\nM ,
((Long *)b)[0],
((Long *)b)[l]);
#endif / * LR = X XOR K */
L = ((Long * ) b ) [0]; R = ((Long * ) b ) [1]; for (i=R0UNDS;
/ * subkeys in reverse order */
i>0; i-=2) {
L ~= f(R, loki_subkeys[i-l]); R ~= f(L, loki_subkeys[i-2]);
1 ((Long * ) b ) [0] = R;
/* Y = LR XOR K */
((Long *)b)[l] = L; #if
TRACE >= 1 fprintf (stderr, "
deloki returns 7,081x, °/.081x\n",
( (Long *)b) [0] , ( (Long *)b) [1] ) ; #endif #ifdef LITTLE.ENDXAK b s w a p ( b );
/* swap bytes round if little-endian */
#endif
}
/* *
f(r, k) - is the complex non-linear LOKI function,
*
whose output
is a complex function of both input data and sub-key.
* *
The d ata is XORed with the subkey, then
expanded into
4 x 12-bit
*
values, which are fed into the S-boxes.
The 4 x 8-bit
outputs
*
from the S-boxes are permuted together to form the
*
which is returned.
32-bit value
* *
In this implémentation the outputs from
*
pre-permuted and stored in lookup tables.
the S-boxes have been
*/ «define M A S K 12 static Long f (r, k)
OxOfff
/ * 12 bit mask for expansion E */
L O K I 91
682 register Long
r;
/* Data value R(i-l) */
Long
k;
/* Key
*/
K(i)
{ Long
a, b, c;
/* 32 bit S-box output, & P output */
a = r ' k;
/* A = R(i-l) XOR K(i) */
/ * want to use slow speed/small size version * / /* B = S(E(R(i-l))'K(i)) */ b = ((Long)s((a
& MASK12))
((Long)s(((a »
8) & MASK12)) «
8)
I
((Long)s(((a »
16) & MASK12)) «
16)
I
((Long)s((((a »
24)
I (a «
perm32(&c, &b, P ) ; #if
) I
TRACE >= 2
8)) & MASK12)) «
24);
/* C = P(S( E(R(i-l)) XOR
K(i))) */
/* If Tracing, dump A, K(i), and f(R(i-l),K(i)) */
fprintf (stderr,"
fC/.081x, %081x) = P.S(*/„081x) = PC/.081x) = •/.081x\n",
r, k, a, b, c ) ; #endif r e t u r n (c);
/* f returns the resuit
C */
}
/* *
s(i) - return S-box value for input i
*/ static short s(i) / * return S-box value for input i */
register Long i;
{ register short short
r, c, v, t; / * exponentiation routine for GF(2“8) */
exp8();
r =
( ( i » 8 ) & Oxc) I (i & 0x3);
/* row value-top 2 & bottom 2 */
c =
(i»2)
/* column value-middle 8 bits
t =
(c + ((r * 17) * Oxff)) & Oxff;
v =
exp8(t, sfn[r].exp, sfn[r].gen); / * Sfn[r] = t “ exp m od gen */
& Oxff;
*/
/* base value for Sfn */
#if TRACE >= 3 fprintf (stderr, "
s(Xlx= [*/,d,’ /,d] ) = 7,x sup ’ /id m o d Xd = ’ /.x\n" ,
i, r, c, t, sfn[r].exp, sfn[r] .gen, v) ; #endif r e t u r n ( v);
} /* *
perm32(out, in, perm) is the général permutation of a 32-bit input
*
block to a 32-bit output block, under the
*
permutation array perm. Each element of perm spécifiés
control of a
*
input bit is to be permuted to the output
*
index as the array ele m e n t .
which
bit with the same
683
L O K I 91
*
*
nb: to set bits in the output word, as mask with a single 1 in it is used. On each step, the 1 is shifted into the next location
*
*/ ffdefine MSB perm32(out,
/* MSB of 32-bit word */
0x80000000L in
perm)
Long
*out;
/* Output 32-bit block
to be permuted
Long
*in;
/* Input
after permutation
char
perm[32];
/* Permutation array
32-bit block
*/ */ */
{ Long
mask = MSB;
/* mask used to set bit in output
*/
register int
i, o, b;
/* input bit no, output bit no, value */
register char
*p = perm;
/ * ptr to permutation array
*/
*out = 0;
/* clear output block */
for (o=0; o<32; o++) { i =(int)*p++;
/* get input bit permuted to output o */
b = (*in »
/ * For each output bit position o */
i)
01;/* value of input bit i */ /* If the input bit i is set */
if (b) *out m ask » =
|= mask;
/*
1;
OR in mask to output i */
/* Shift mas k to next bit
*/
/* *
mult8(a, b, gen) - returns the product of two binary
*
strings a and b using the generator gen as the modulus
*
mult = a * b mod gen
*
gen generates a suitable Galois field in GF(2~8)
*/ #define SIZE 256
/* 256 elements in GF(2~8) */
short mult8(a, b, gen) short
a, b;
/* operands for multiply */
short
gen;
/* irreducible polynomial generating
Galois Field */
{ short
product = 0 ;
while(b != 0) {
/* resuit of multiplication */ /* while multiplier is non-zero */
if (b
& 01)
a « =
1;
if (a
>= SIZE)
b »=
1;
product “= a; /*
a ~= gen;
> return(product);
add multiplicand if LSB of b set */
/*
shift multiplicand one place */
/*
and modulo reduce if needed */
/*
shift multiplier one place
*/
684
L O K I 91
> /* *
exp8( b ase, exponent, gen) - returns the resuit of
*
exponentiation given the base, exponent, generator of GF,
*
exp = base " exp mod gen
*/ short exp8(base, exponent, gen) short short
base; exponent;
/* base of exponentiation /* exponent
short
gen;
/ * irreducible polynomial generating Galois Field * /
short
accum = base;
short
resuit = 1 ;
if (base == 0) r e turn(O); while (exponent
+/ */
/ * superincreasing sequence of base
*/
/ * resuit of exponentiation
*/
/* if zéro base specified then
*/
/ * the resuit is "0" if base = 0
*/
!= 0) { / *
repeat while exponent non-zero * /
if (( exponent & 0x0001) == 0x0001)
/* multiply if exp 1 */
resuit = mult8(result, accum, gen); exponent » = accum =
y return(result);
>
1;
/* shift exponent to next digit */
mult8(accum, accum,
gen);
/ * & square
*/
IDEA usuals.h / * usuals.h - The usual typedefs, etc.
*/ #ifndef USUALS /* Assures no redéfinitions of usual t y p e s . . . * / #define USUALS typedef
unsigned char boolean;
/* values are TRUE or FALSE */
typedef
unsigned char byte;
/* values are 0-255 */
typedef
byte *byteptr; /* pointer to byte */
typedef
char *string;
/* pointer to ASCII character string
typedef unsigned short wordl6; #ifdef
*/
/* values are 0-65535 * /
alpha
typedef unsigned int word32;
/* values are 0-4294967295 */
#else typedef unsigned long word32;
/* values are 0-4294967295 */
#endif #ifndef TRUE #define FALSE 0 #define TRUE (!FALSE) #endif
/* if TRUE not already defined */
#ifndef min
/* if min macro not already defined */
#define min(a.b)
(((a)<(b))
? (a) :(b)
)
#define max(a.b)
(((a)>(b))
? (a) :(b)
)
#endif
/* if min macro not
/ * void for use in pointers
already defined */ */
#ifndef N0_V0ID_STAP. ffdefine VOID
void
#else #define VOID
char
#endif /* Zero-fill the byte buffer. #define fillOCbuffer,count)
*/
memsetC buffer, 0, count )
/* This macro is for burning sensitive data.
Many of the
686
ID E A
file I/O routines use it for zapping buffers */ #define burn(x) fillOCCVOID *)&(x).sizeof(x)) #endif
/* if USUALS not already defined */
randpool.h #include "usuals.h" /* Set this to whatever you need (must be > 512) */ #define RANDPOOLBITS 3072 void randPoolStir(void); void randPoolAddBytes(byte const *buf, unsigned l e n ) ; void randPoolGetBytesCbyte *buf, unsigned len); byte randPoolGetByte(void);
idea.h #ifndef IDEA_H #define IDEA.H
/* *
idea.h - header file for idea.c
*/ #include "usuals.h"
/* typedefs for byte, wordl6, boolean, etc. */
#define IDEAKEYSIZE 16 #define IDEABLOCKSIZE 8 #define IDEAROUNDS 8 #define IDEAKEYLEN (6*IDEAR0UNDS+4)
/* * iv[] is used as a circular buffer.
bufleft is the number of
* bytes at the end which have to be filled in before we crank * the block cipher again.
We do the block cipher opération
* lazily: bufleft may be
0. When we need one more byte, we
* crank the block cipher
and
set bufleft to 7.
* * oldcipherl] holds the previous 8 bytes of ciphertext, for use * by i d e a C f b S y n c O
and P h i l 1s, ahem, unique (not insecure, just
* unusual) way of doing CFB encryption.
*/ struct IdeaCfbContext { byte o ldcipher[8]; byte iv[8] ; wordl6 key[IDEAKEYLEN];
687
ID E A
int bufleft;
>; struct IdeaRandContext { byte o u t b u f [8]; wordl6 key[IDEAKEYLEN]; int bufleft; byte i n ternalbuf[8];
>; void ideaCfbReinit(struct IdeaCfbContext *context, byte const * i v ) ; void ideaCfblnit(struct IdeaCfbContext *context, byte const (key[16])); void ideaCfbSync(struct IdeaCfbContext *context); void ideaCfbDestroy(struct IdeaCfbContext *context); void ideaCfbEncrypt(struct IdeaCfbContext *context, byte const *src, byte *dest, int count); void ideaCfbDecrypt(struct IdeaCfbContext *context, byte const *src, byte *dest, int count); void ideaRandlnit(struct IdeaRandContext *context, byte const
(key[16]),
byte const (seed[8])); byte ideaRandByte(struct IdeaRandContext *c) ; void ideaRandWash(struct IdeaRandContext * c ,
struct IdeaCfbContext *c f b ) ;
void ideaRandState(struct IdeaRandContext *c, byte k e y [16], byte seed[8]); #endif /*
ÎIDEA_H */
idea.c /* * *
idea.c - C source code for IDEA block cipher. IDEA (International Data Encryption Algorithm), formerly known as
*
IPES (Improved Proposed Encryption Standard).
*
Algorithm developed by Xuejia Lai and James L. Massey, of ETH Zurich.
*
This implémentation modified and derived from original C code
*
developed by Xuejia Lai.
*
Zero-based indexing added, names changed from IPES to IDEA.
*
CFB functions added.
Random number routines added.
* *
Extensively optimized and restructured by Colin Plumb.
*
*
There are two adjustments that can be made to this code to
*
speed it up.
*
pays off significantly if selectively set or not s e t .
*
Experiment to see what works best for your machine.
Defaults may be used for PCs.
Only the -DIDEA32
* *
Multiplication: default is inline, -DAVOID_JUMPS uses a
*
différent version that does not do
*
jumps (a few percent worse on a S P ARC), while
any conditional
*
-DSMALL_CACHE takes it out of line
*
within a small on-chip code cache.
to stay
ID E A
688 *
V a x i a b l es: normally,
*
16-bit variables are used, but some
machines (notably RISCs) do not have 16-bit registers,
*
so they do
*
register variables and masks explicitly only where
a great deal of masking.
*
necessary. On a SPARC,
*
performace
for example,
-DIDEA32 uses "int" this boosts
by 307..
* *
The IDEA(tm) block cipher is covered by patents held by ETH and a
*
Swiss company called Ascom-Tech AG.
*
PCT/CH91/00117, the European patent number is EP 0 482 154 Bl, and
*
the U.S. patent number is US005214703.
*
Ascom-Tech AG.
*
use.
*
Profos, Ascom Tech AG, Solothurn Lab, Postfach 151, 4502 S o l o t h u m ,
*
Switzerland, Tel +41 65 242885, Fax +41 65 235761.
The Swiss patent number is IDEA(tm) is a trademark of
There is no license fee required for noncommercial
Commercial users may obtain licensing détails from Dieter
*
*
The IDEA block cipher uses a 64-bit block size, and a 128-bit key
*
size.
*
because ail of the primitive inner opérations are done with 16-bit
*
arithmetic.
*
16-bit words.
It breaks the 64-bit cipher block into four 16-bit words It likewise breaks the 128-bit cipher key into eight
*
*
For further information on the IDEA cipher, see the book:
*
Xuejia Lai,
*
ETH Sériés on Information Processing Ced. J.L. Massey) Vol 1,
"On the Design and Security of Block Ciphers",
*
Hartung-Gorre Verlag, Konstanz, Switzerland,
*
3-89191-573-X.
1992.
ISBN
*
*
This code runs on
*
order to make the
arrays of bytes by taking pairs in big-endian 16-bit words that IDEA uses internally.
*
produces the same
resuit regard]ess of the byte order of the
*
native CPU.
This
*/ #include “idea.h" #include “randpool.h" / * Use > 16-bit temporaries */
#ifdef IDEA32 #define lowl6(x)
((x) & OxFFFF)
typedef unsigned int uintl6;
/* at LEAST 16 bits, maybe more */
#else #define lowl6(x)
(x)
/* this is only ever applied to u i n t l 6 ’s */
typedef wordl6 uintl6; #endif #ifdef _GNUC_ /*
const
simply means there are no side effects for this function,
* which is useful info for the gcc optimizer
*/ #define CONST #else
const__
689
ID E A
#define CONST #endif
/* *
Multiplication, modulo (2**16)+1
* Note that this code is structured on the assumption that * untaken branches are cheaper than taken branches, and the * compiler d o e s n ’t schedule branches.
*/ #ifdef SMALL_CACHE CONST static uintl6 mul(register uintl6 a, register uintl6 b) register word32 p; p = (word32)a * b; if (p) { b = l o w l6(p); a = p»16; return (b - a) + (b < a) ; } else if (a) { return 1-b; } else { return 1-a;
> )■ /* inul * / #endif /* SMALL_CACHE */
/* * Compute the multiplicative inverse of x, modulo 65537, using E u c l i d ’s * algorithm. It is unrolled twice to avoid swapping the registers each * itération, and some subtracts of t have been changed to adds.
*/ CONST static uintl6 mullnv(uintl6 x) uintl6 tO, tl; uintlô q, y; if (x <= 1) return x;
/* 0 and 1 are self-inverse */
tl = OxlOOOlL / x;
/* Since x >= 2, this fits into 16 bits */
y = OxlOOOlL '/. x; if (y = = 1) return lowl6(l-tl); tO = 1; do { q = x / y; x = x 7. y; tO += q * tl; if (x == 1)
ID E A
690 return tO; q = y / x;
y = y ’/. x ; tl += q * tO; > while (y != 1); return lowl6(l-tl); } / * muklnv */
/* * Expand a 128-bit user key to a working encryption key EK
*/ static void ideaExpandKey(byte const *userkey, wordl6 *EK) int i , j ; for (j=0; j<8; j++) { EK[j] = ( u s e r key[0]«8) + userkey [1] ; userkey += 2;
> for (i=0; j < IDEAKEYLEN; j++) { i++; EK[i+7] = EK[i & 7] «
9 I EK[i+l & 7] »
7;
EK += i k 8; i &= 7;
> J /* ideaExpandKey */
/* * Compute IDEA decryption key DK from an expanded IDEA encryption key EK * Note that the input and output may be the same.
Thus, the key is
* inverted into an internai buffer, and then copied to the output.
*/ static void ideaInvertKey(wordl6 const *EK, wordl6 DK[IDEAKEYLEN]) int i; uintl6 tl, t2, t3; wordl6 temp[IDEAKEYLEN]; wordl6 *p = temp + IDEAKEYLEN; tl = m u lInv(*EK++); t2 = -*EK++; t3 = -*EK++; *— p = mulInv(*EK++); *— p = t3; *— p = t2; *— p = tl; for (i = 0; i < IDEAR0UNDS-1; i++) { tl = *EK++;
691
ID E A
*— p = *EK++; * — p = tl; tl = mulInv(*EK++); t2 = -*EK++; t3 = -*EK++;
*— p = mul!nv(*EK++); *— p = t2; *— p = t3; *— p = tl; } tl = ♦EK++; *— *—
p p
= *EK++; = tl;
tl = m u lInv(*EK++); t2 = -*EK++; t3 = - * E K + + ;
* P * P
= mulInv(*EK++);
= t3; *— p = t2; * P = tl; /* Copy and destroy temp copy */ memcpyCDK, temp, sizeof(temp)); bu r n (temp); }■ /* idealnvertKey */
/* * MUL(x,y) computes x = x*y, modulo 0x10001. * tl6 and t32.
Requires two temps,
x is modified, and must me a side-effect-free lvalue.
* y m a y be anything, but unlike x, must be strictly 16 bits even if * lowl6() is #defined. * Ail of these are équivalent - see which is faster on your machine
*/ #ifdef SMALL_CACHE #define MÜL(x,y)
(x = mul(lowl6(x),y))
#else /* !SMALL_CACHE */ #ifdef AV0ID_JUMPS #define MÜL(x,y)
(x = lowl6(x-l), tl6 = lowl6((y)-l), \ t32 = Cword32)x*tl6 + x + tl6 + 1, x = lowl6(t32), \ tl6 = t 3 2 » 1 6 ,
#else /*
x = (x-tl6) + (x
!AV0ID_JUMPS (default) */
#define MÜL(x,y) \ ( (tl6 = (y)) ? \ (x=lowl6(x)) ? \ t32 = (word32)x*tl6, x = lowl6(t32), \ tl6 = t 3 2 » 1 6 ,
\
x = (x-tl6)+(x
: \
(x = l - t l 6 ) \
\
ID E A
692 : \ (x = 1-x)) #endif #endif /*
IDEA encryption/decryption algorithm */
/ * Note that in and out can be the same buffer * / static void ideaCipher(byte const (inbuf[8]), byte (outbuf[8]), wordl6 const *key)
{ register uintl6 xl, x2, x3, x4, s2, s3; wordl6 *in, * o u t ; #ifndef SMALL_CACHE register uintl6 tl6;
/ * Temporaries needed by MÜL macro */
register word32 t32; #endif int r = IDEAROUNDS; in = (wordl6 *)inbuf; xl = *in++;
x2 = *in++;
x3 = *in++;
x4 = *in;
#ifndef HIGHFIRST xl = ( x l » 8 )
I (xl«8) ;
x2 = ( x 2 » 8 )
I (x2«8) ;
x3 = ( x 3 » 8 )
I (x3«8);
x4 = ( x 4 » 8 )
I (x4«8);
#endif do { MUL(xl,*key++) ; x2 += *key++; x3 += *key++; MUL(x4, * key++); s3 = x3; x3 *= xl; MUL(x3, *key++); s2 = x2; x2 "= x4; x2 += x3; MUL(x2, *key++); x3 += x2; xl "= x2;
x4 “= x3;
x2 "= s3;
x3 “= s2;
} while (— r ) ; MUL(xl, *key++); x3 += *key++; x2 += *key++; MUL(x4, *k e y ) ;
693
ID E A
out = (wordl6 *)outbuf; #ifdef HIGHFIRST ♦out++ = x l ; ♦out++ = x3; *out++ = x2; ♦out = x4; #else /♦ .'HIGHFIRST ♦/ xl = lowl6(xl); x2 = 1 o w 16( x 2); x3 = 1 o w 16( x 3); x4 = lowl6(x4); ♦out++ = ( x l » 8 )
I (xl«8);
♦out++ = ( x 3 » 8 )
I (x3«8);
♦out++ = ( x 2 » 8 )
I (x2«8) ;
♦out
I Cx4<<8) ;
= (x4»8)
#endif } /♦ ideaCipher ♦/
/*
*/
#ifdef TEST #include #include
/♦ ♦ This is the number of Kbytes of test data to encrypt. ♦ It defaults to 1 MByte.
♦/ #ifndef BLOCKS #ifndef KBYTES #define KBYTES 1024 #endif #define BLOCKS (64+KBYTES) #endif int main(void) { /♦ Test driver for IDEA cipher ♦/ int i, j, k; byte userkey [16]; wordl6 EK[IDEAKEYLEN], DK[IDEAKEYLEN]; byte XX [8], YY[8] , ZZ[8]; clock_t start, end; long 1; /♦ Make a sample user k ey for testing... ♦/ for(i=0; i<16; i++) userkey[i] = i+1; /♦ Compute encryption subkeys from user key... ideaExpandKey(userkey, EK);
♦/
ID E A
694 p r i n t f ("\nEncryption key subblocks:
”);
for (j=0; j
", j+1) ;
if (j < IDEAROUNDS) for(i=0; i<6; i++) printf (" ’ /.6u" , EK [j *6+i] ) ; else for(i=0;
i<4; i++) printf C
y.6u", EK [j*6+i] ) ;
} /* Compute decryption subkeys from encryption subkeys... */ idealnvertKey(EK, D K ) ; p r i n t f ("\nDecryption key subblocks:
");
for (j=0; j
", j+1);
if (j < IDEAROUNDS) for(i=0;
i<6; i++) printf (" */,6u", DK [j *6+i] ) ;
else for(i=0;
i<4; i++) printf (" V.6u", DK [j *6+i] ) ;
} /* Make a sample plaintext pattern for t e s ting... */ for (k=0; k<8; k++) XX [k] = k; printf("\n Encrypting
y.d
bytes
(*/.ld blocks)...", BL0CKS*16, BLOCKS);
fflush(stdout); start = c l o c k O ; memcpy(YY, XX, 8); for ( 1 = 0 ;
1 < BLOCKS; 1++)
ideaCipher(YY, YY, E K ) ; /* repeated encryption */ memcpy(ZZ, YY, 8); for ( 1 = 0 ;
1 < BLOCKS; 1++)
ideaCipher(ZZ, ZZ, D K ) ; /* repeated decryption */ end = c l o c k O - start; 1 = end
/ (CL0CKS_PER_SEC/1000) + 1;
i = 1/1000; j = 15C1000; 1 = (16 * BLOCKS * (CL0CKS_PER_SEC/1000)) / (end/1000); printf ("Xd.y,03d seconds = V.ld bytes per second\n", i, j, 1); printf("\nX */.3u X X [0], XX [1], printf ("\nY y.3u YY[0] , YY[1] , printf ("\nZ V.3u ZZ[0], ZZ[1],
y.3u y.3u
’ /.3u ’ /.3u
*/.3u y.3u y.3u\n",
XX [2], XX [3], XX [4], XX [5], */.3u y.3u
*/.3u ‘ /.3u
YY[2] , YY[3] , YY[4], YY[5] , 7.3u y,3u
”/,3u */,3u
XX [6] , XX [7]);
y,3u y.3u y.3u\n", YY[6] , YY[7]);
*/,3u "/,3u y,3u\n” ,
ZZ[2], ZZ[3] , ZZ[4] , ZZ[5] ,
ZZ[6] , ZZ[7]);
695
ID E A
/ * Now decrypted ZZ should be same as original XX */ for (k=0; k<8; k++) if (XX [k]
!= ZZ [k] ) {
p r i n t f ("\n\07Error! exit(-l);
Noninvertable encryption.\n");
/* error exit */
> printf (“\nNormal exit A n " ) ; return 0;
/* normal exit */
}- /* main */ #endif /* TEST */
Z * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * /
void ideaCfbReinit(struct IdeaCfbContext *context, byte const *iv) if (iv) memcpy(context->iv, iv, 8); else fillO(context->iv, 8); context->bufleft = 0;
} void ideaCfblnit(struct IdeaCfbContext *context, byte const ideaExpandKey(key,
(key[16]))
context->key);
ideaCfbReinit(context,0);
> void ideaCfbDestroy(struct IdeaCfbContext *context) burn(*context);
> /* * Dkay, explanation time: * Phil invented a unique way of doing CFB t h a t ’s sensitive to semantic * boundaries within the data being encrypted.
One way to phrase
* CFB en/decryption is to say that you XOR the current 8 bytes with * IDEA(previous 8 bytes of ciphertext).
Normally, you repeat this
* at 8-byte intervais, but Phil decided to resync things on the * boundaries between elements in the stream being encrypted.
* * That is, the last 4 bytes of a 12-byte field are en/decrypted using * the first 4 bytes of IDEA(previous 8 bytes of ciphertext), but then * the last 4 bytes of that IDEA computation are thrown away, and the * first 8 bytes of the next field are en/decrypted using
696
ID E A
* IDEA(last 8 bytes of ciphertext).
This is équivalent to using a
* shorter feedback length (if y o u ’re familiar with the général CFB * technique) briefly, and d o e s n ’t weaken the cipher any (using shorter * CFB lengths makes it stronger, actually), it just makes it a bit unusual.
* * Anyway, to accomodate this behaviour, every time we do an IDEA * encrpytion of 8 bytes of ciphertext to get 8 bytes of XOR mask, * we remember the ciphertext.
Then if we have to resync things
* after having processed, say, 2 bytes, we refill the iv buffer * with the last 6 bytes of the old ciphertext followed by the * 2 bytes of new ciphertext stored in the front of the iv buffer.
*/ void ideaCfbSync(struct IdeaCfbContext *context)
{ int bufleft = context->bufleft; if (bufleft) { memmove(context->iv+bufleft, context->iv, 8-bufleft); memcpy(context->iv, context->oldcipher+8-bufleft, bufleft); context->bufleft = 0;
> > /* * Encrypt a buffer of data, using IDEA in CFB mode. * There are more compact ways of writing this, but this is * written for speed.
*/ void ideaCfbEncrypt(struct IdeaCfbContext *context, byte const *src, byte *dest, int count)
{ int bufleft = context->bufleft; byte *bufptr = context->iv + 8-bufleft; /* If there are no more bytes to encrypt that there are bytes * in the buffer, XOR them in and return.
*/ if (count <= bufleft) { context->bufleft = bufleft - count; while (count— ) { *dest++ = *bufptr++ ~= *src++;
> return;
> count -= bufleft; /* Encrypt the first bufleft
(0 to 7) bytes of the input by XOR
* with the last bufleft bytes in the iv buffer.
*/ while (bufleft— ) {
697
ID E A
*dest++ = (*bufptr++
*src++);
> /* Encrypt middle blocks of the input by cranking the cipher, * XORing 8-byte blocks, and repeating until the count * is 8 or less.
*/ while (count > 8) { bufptr = context->iv; memcpy(context->oldcipher, bufptr, 8); ideaCipher(bufptr, bufptr, context->key); bufleft = 8; count -= 8; do { *dest++ = (*bufptr++ *= *src++); } while (— b u f left);
} /* Do the last 1 to 8 bytes */ bufptr = context->iv; memcpy(context->oldcipher, bufptr, 8); ideaCipher(bufptr, bufptr, context->key); context->bufleft = 8-count; do
I *dest++ = (*bufptr++ “= * src++);
> while (— count);
}
/* * Decrypt a buffer of data, using IDEA in CFB mode. * There are more compact ways of writing this, but this is * written for speed.
*/ void ideaCfbDecrypt(struct IdeaCfbContext *context, byte const *src, byte *dest, int count)
{ int bufleft = context->bufleft; static byte *bufptr; byte t; bufptr = context->iv + (8-bufleft); if (count <= bufleft) -f context->bufleft = bufleft - count; while (count— ) { t = *bufptr; *dest++ = t ~ (*bufptr++ = * src++);
> return;
} count -= bufleft; while (bufleft— ) {
ID E A
698 t = *bufptr; *dest++ = t
(*bufptr++ = * src++);
} while (count > 8) { bufptr = context->iv; memcpy(context->oldcipher, bufptr, 8); ideaCipher(bufptr, bufptr, context->key); bufleft = 8; count -= 8; do { t = *bufptr; *dest++ = t " (*bufptr++ = *src++); } while (— bufleft) ;
> bufptr = context->iv; m emcpy(context->oldcipher, bufptr, 8); ideaCipher(bufptr, bufptr, context->key); context->bufleft = 8-count; do { t = *bufptr; *dest++ = t “ (*bufptr++ = * src++); } while (— coun t ) ;
> / ********************************************************************/ /* * Cryptographically strong pseudo-random-number generator. * The design is from Appendix C of ANSI X9.17, * Institution Key Management
"Financial
(Wholesale)", with IDEA
* substituted for the DES.
*/ /* * Initialize a cryptographie random-number generator. * key and seed should be arbitrary.
*/ void ideaRandlnit(struct IdeaRandContext *context, byte const (key[16]), byte const (seed[8]))
{ int i; ideaExpandKey(key, context->key); context->bufleft = 0; m emcpy(context->internalbuf, seed, 8);
>
/* * Read out the R N G ’s state.
699
ID E A
*/ void ideaRandState(struct IdeaRandContext *context, byte k e y [16], byte seed[8]) int i; memcpyCseed, c o n t e x t - > i n t e m a l b u f , 8); for (i = 0; i < 8; i++) { key[2*i] = context->key[i]
»
8;
key[2*i+l] = context->key[i] ;
> > /* * Encrypt the R N G ’s state with the given CFB encryptor.
*/ void ideaRandWash(struct IdeaRandContext *context, struct IdeaCfbContext *cfb)
{ byte k eyseed[16+8]; int i; ideaRandState(context, keyseed, keyseed+16); ideaCfbEncrypt(cfb, keyseed, keyseed, 16+8); ideaRandInit(context, keyseed, keyseed+16); memset(keyseed, 0, 16+8);
} /* * Cryptographie pseudo-random-number generator, used for generating * session keys.
*/ byte ideaRandByte(struct IdeaRandContext *c)
£ int i; if (!c->bufleft) { byte timestamp[8] ; /* Get some true-random noise to help */ randPoolGetBytes(timestamp,
sizeof(timestamp));
/* Compute next 8 bytes of output */ for (i=0; i<8; i++) c->outbuf[i] = c->internalbuf [i] ~ timestamp[i] ; ideaCipher(c->outbuf, c->outbuf, c ->key); /* Compute new seed vector */ for (i=0; i<8; i++)
700
ID E A
c->internalbuf[i] = c->outbuf[i]
~ timestamp[i];
ideaCipher(c->internalbuf, c->internalbuf, c->key); burn(timestamp); c->bufleft = 8;
> return c ->outbuf[— c->bufleft];
> /* end of idea.c */
GOST gost.c /* * The GOST 28147-89 cipher *
* This is based on the 25 Movember 1993 draft translation * by Aleksandr Malchik, with Whitfield Diffie, of the Government * Standard of the U.S.S.R. GOST 28149-89, * Algorithm", effective 1 July 1990.
"Cryptographie Transformation
(Wïiitfield.Diffie®eng.sun.com)
* * That is a draft, and may contain errors, which will be faithfully * reflected here, along with possible exciting new bugs. *
* Some détails have been cleared up by the paper "Soviet Encryption * Algorithm" by Josef Pieprzyk and Leonid Tombak of the University * of Wollongong, New South Wales.
(josef/leoScs.adfa.oz.au)
*
* The standard is written by A. Zabotin (project leader), G.P. Glazkov, * and V.B. Isaeva.
It was accepted and introduced into use by the
* action of the State Standards Committee of the USSFt on 2 June 89 as * No.
1409.
It was to be reviewed in 1993, but whether anyone wishes
* to take on this obligation from the USS R is questionable.
* * This code is placed in the public domain.
*/ /* * If you r ead the standard,
it belabors the point of copying corresponding
* bits from point A to point B quite a b i t .
It helps to understand that
* the standard is uniformly little-endian, although it numbers bits from * 1 rather than 0, so bit n has value 2~(n-l).
The least significant bit
* of the 32-bit words that Eure manipulated in the algorithm is the first, * lowest-numbered, in the bit string.
*/
/* A 32-bit data type */ #ifdef
alpha
/* Any other 64-bit machines? */
typedef unsigned int word32;
GOST
102
#else typedef unsigned long word32; #endif
/* * The standard does not specify the contents of the 8 4
bit->4 bit
* substitution boxes, saying
network
* being set up.
t h e y ’re a parameter of the
For illustration purposes here, I have used
* the first rows of the 8 S-boxes from the DES.
(Note that the
* DES S-boxes are numbered starting from 1 at the msb. * with the rest of the GOST,
In keeping
I have used little-endian numbering.
* T h u s , k8 is S-box 1.
* * Obviously, a careful look at the cryptographie properties of the cipher * must be undertaken before "production" substitution boxes are defined.
* * The standard also does not specify a standard bit-string représentation * for the contents of these blocks.
*/ static unsigned char const k8[16] = { 14, 4, 13, 1, 3, 10, 2, 15, 11 , 8,
6, 12,
5,
9,
0,
static unsigned char const k7[16] = { 3 , 4, 15, 1, 8, 14, 9, 7, 6, 11,
2, 13, 12,
0,
5, 10 >
4,
2,
static unsigned char const k6[16] = { 5, 1, 13, 12, 10, 0, 9, 14, 3, 15 6,
7, u ,
static unsigned char const k 5 [16] = { 7, 13, 14, 3, 6, 9 10, 1, 0, 2,
8,
5, 11, 12,
static unsigned char const k4[16] = { 2, 12, 4, 1, 7, 10, 11 6, 8, 5,
3, 15, 13,
0, 14,
static unsigned char const k3[16] = { 12, 1, 10, 15, 2, 6 8, 0, 13, 9,
3,
4, 14,
7,
static unsigned char const k2[16] = { 4, U , 2, 14, 15, 0, 8 13, 3, 12,
9,
7,
static unsigned char const k l [16] = { 13, 2, 8, 4, 9, 6, 15, U 1, 10,
3, 14,
/* Byte-at-a-time substitution boxes */ static unsigned char k 8 7 [256]; static unsigned char k65[256]; static unsigned char k43[256]; static unsigned char k 2 1 [256];
/* * Build byte-at-a-time subtitution tables. * This must be called once for global setup.
*/ void kboxinit(void)
{ int i; for (i = 0; i < 256; i++) {
5, 10, 5,
7 >
8 >
4, 15 > 9 >
5, 11 > 6,
1 >
0, 12,
7 >
703
GOST
k87[i]
= k8 [i »
4] «
k65 [i]
= k6ti »
4] « 4
4
Ik7[i ft 15]
k43[i]
= k4[i »
4] «
4
Ik3[i & 15]
k21[i]
= k2[i »
4] «
4
Ikl[i & 15]
Ik5[i & 15]
> } /* * Do the substitution and rotation that are the core of the opération, * like the expansion, substitution and permutation of the DES. * It would be possible to perform DES-like optimisations and store * the table entries as 32-bit words, already rotated, but the * efficiency gain is questionable. *
* This should be inlined for maximum speed
*/ #if
GNUC__
inline__ #endif static word32 f(word32 x)
{ /* Do substitutions */ #if 0
k 6 [ x » 2 0 k 15] « k 4 [ x » 1 2 & 15] « k 2 [ x » 4 & 15] «
28 1 k 7 [ x » 2 4 k 15] 20 1 k 5 [ x » 1 6 k 15] « 12 1 k3 [ x » 8 k 15] «
A A
A A
/* This is annoyingly slow */ x = k 8 [ x » 2 8 k 15]
4 1 kl[x
24 16 8
k 15];i
#else /* This is faster */ x = k 8 7 [ x » 2 4 & 255] «
24 I k 6 5 [ x » 1 6 & 255] «
k 4 3 [ x » 8 k 255] «
16 I
8 I k21[x k 255];
#endif /* Rotate left 11 bits */ return x « l l
I x»(32-ll);
> /* * The GOST standard defines the input in terms of bits 1..64, with * bit 1 being the lsb of in[0] and bit 64 being the msb of i n [ l ] . *
* The keys are defined similarly, with bit 256 being the msb of k e y [7]. */ void gostcrypt(word32 const in [ 2 ] , word32 o u t [2], word32 const k e y [8])
{ register word32 ni, n2; /* As named in the GOST */ ni = in [0] ;
GOST
704 n2 = in[l] ; / * Instead of swapping halves, swap names each round */ n2
f ( n l + k e y [0] )
ni
f (n2+key [1] )
n2 ~= f (nl+key [2]) ni “= f (n2+key [3] ) n2 "= f (nl+key [4]) ni "= f ( n 2 + k e y [5]) n2 '= f (nl+key [6]) ni "= f ( n 2 + k e y [7]) n2 “= f ( n l + k e y [0] ) ni "= f (n2+key[l]) n2 '= f ( n l + k e y [2]) ni "= f(n2+key [3]) n2 "= f ( n l + k e y [4]) ni "= f (n2+key [5] ) n2 *= f(nl+key [6]) ni
f ( n 2 + k e y [7] )
n2 *= f (nl+key [0]) ni "= f (n2+key[l]) n2 '= f ( n l + k e y [2]) ni '= f( n 2 + k e y [3]) n2 “= f(nl+key [4]) ni '= f (n2+key [5] ) n2 '= f ( n l + k e y [6]) ni "= f ( n 2 + k e y [7]) n2 -= f (nl+key [7]) ni
f(n2+key [6])
n2
f ( n l + k e y [5])
ni ~= f ( n 2 + k e y [4]) n2 “= f(nl+key [3] ) ni *= f ( n 2 + k e y [2]) n2 ~= f ( n l + k e y [1]) ni *= f ( n 2 + k e y [0]) /* There is n o swap after the last round */ out[0] = n2; out[l] = ni;
}
/* * The ke y schedule is somewhat différent for decryption. * (The key table is used once forward and three times backward.) * You could define an expanded key, or just write the code twice, * as done here.
*/
705
GOST void gostdecrypt(word32 const in[2], word32 o u t [2], word32 const k e y [8]) register word32 ni, n2; /* As named in the GOST */ ni = in [0] ; n2 = in[l] ; n2 '= f(nl+key [0]); ni "= f (n2+key[l]) ; n2 “= f (nl+key [2]) ; ni ~= f ( n 2 + k e y (3]); n 2 '=
f(nl+key [4]);
ni “= f ( n 2 + k e y [5]); n2 ~= f(nl+key [6]); ni “= f( n 2 + k e y [7]); n2 “= f ( n l + k e y [7]); ni "= f(n2+key [6] ) ; n2 "= f ( n l + k e y [5]); ni
f ( n 2 + k e y [4]);
n2 “** f(nl+key [3]); ni "= f ( n 2 + k e y (2]); n2 '= f ( n l + k e y [1] ) ; ni “= f ( n 2 + k e y [0]); n2
f ( n l + k e y [7]);
ni '= f(n 2 + k e y [ 6] ) ; n2 '= f(nl+key [5]); ni “= f(n2+key[4]); n2 "= f(n l + k e y [3]); ni "= f (n2+key [2] ) ; n2 ~= f ( n l + k e y [1]); ni “= f(n2+key [0] ) ; n2 '= f (nl+key [7]) ; ni “= f (n2+key [ 6 ] ) ; n2 “= f (nl+key [5]); ni "= f ( n 2 + k e y [4]); n2 “= f(n l + k e y [3]); ni “= f ( n 2 + k e y [2]); n2 "= f (nl+key [1]) ; ni "= f ( n 2 + k e y [0]); out [0] = n2 ; out[l] = ni;
> /* * The GOST "Output feedback" standard.
It seems d o s e r morally
* to the counter feedback mode some people have proposed for DES.
706
GOST
* The avoidance of the short cycles that are possible in OFB seems * like a Good Thing.
* * Calling it the stream mode makes more sense.
* * The IV is encrypted with the key to produce the initial counter value. * Then, for each output block, a constant is added, modulo 2*32-1 * (0 is represented as all-ones, not all-zeros), to each half of * the counter, and the counter is encrypted to produce the value * to XOR with the output.
* * Le n is the number of b l o c k s .
Sub-block encryption is
* left as an exercise for the user.
Remember that the
* standard defines everything in a little-endian manner, * so you want to use the low bit of g a m m a [0] first.
* * OFB is, of course, self-inverse, so there is only one f u n ction.
*/ / * The constants for addition */ #define Cl 0x01010104 #define C2 0x01010101 void gostofb(word32 const *in, word32 *out, int len, word32 const i v [ 2 ] , word32 const k e y [8])
{ word32 temp [2];
/*
Counter */
word32 g a m m a [2];
/*
Output XOR value * /
/ * Compute starting value for counter */ gostcrypt(iv, temp, key); while (len— ) { temp[0] += C2; if (temp[0] < C2) temp[0]++;
/*
Wrap modulo 2 “32? * /
/ * Make it modulo 2*32-1 */
temp[l] += Cl; if (temp[l] < Cl) temp[l]++;
/*
Wrap modulo 2*32? * /
/ * Make it modulo 2*32-1 */
gostcrypt(temp, gamma, key); *out++ = *in++ ' g a m m a [0]; *out++ = *in++ “ g a m m a [1];
> > /* * The CFB mode is just what y o u ’d expect.
Each block of ciphertext y[] is
* derived from the input x[] by the following pseudocode:
GOST
707
* y[i] = x[i]
* gostcrypt (y [i-l])
* x[i] = y [i] " gostcrypt (y [i-l]) * Where y[-l] is the IV.
* * The IV is modified in place.
Again, len is in *blocks*.
*/ void gostcfbencrypt(word32 const *in, word32 *ont, int len, word32 iv [2], word32 const k e y [8])
{ while (len— ) { gostcrypt(iv,
iv, key);
iv[0] = *out++ *= iv[0]; iv[l] = *out++ *= iv[l] ;
> } void gostcfbdecrypt(word32 const *in, word32 *out, int len, word32 i v [2], word32 const k e y [8]) word32 t; while (len— ) -{ gostcrypt(iv, iv, key); t = *out; *out++ “= iv[0]; iv[0] = t; t = *out; *out++ '= iv [1]; iv[l] = t;
> }
/* * The message suthetication code uses only 16 of the 32 rounds. * There *is* a swap after the 16th round. * The last block should be padded to 64 bits with zéros. * len is the number of *blocks* in the input.
*/ void gostmac(word32 const *in, int len, word32 o u t [2], word32 const k e y [8])
i register word32 ni, n2; /* As named in the GOST * / ni = 0; n2 = 0; while (len— ) { ni ~= *in++;
GOST
708 n2 = *in++; /* Instead of swapping halves, swap names each round */ n2 “= f ( n l + k e y [0]); ni “= f ( n 2 + k e y [1]); n2 “= f ( n l + k e y [2]); ni “= f ( n 2 + k e y [3]); n2 ~= f ( n l + k e y [4]); ni "= f (n2+key [5] ) ; n2 "= f (nl+key [6] ) ; ni "= f ( n 2 + k e y [7]); n2 *= f ( n l + k e y [0]); ni ~= f (n2+key[l]); n2 “= f ( n l + k e y [2]); ni "= f (n2+key [3] ) ; n2 ~= f ( n l + k e y [4]); ni ~= f(n2+key [5]); n 2 ~= f(n l + k e y [6]); ni ~= f(n 2 + k e y [7]);
} out [0] = ni ; outül] = n2;
} #ifdef TEST #include #include /* Designed to cope with 15-bit r a n d Q #define RAND32 ((word32)rand() « int main(void)
{ word32 k e y [8]; word32 plain [2]; word32 c i p h e r [2]; int i, j; kboxinitO ; printf("GOST 21847-89 test driver.\n"); for (i = 0; i < 1000; i++) { for (j = 0; j < 8; j++) keytj] = RAND32; p l a i n [0] = R A N D 3 2 ; p l a i n [1] = RAND32;
implémentations * /
17 “ (word32)rand() «
9
rarndO)
709
GOST
printf ("73d\r", i) ; Cflush(stdout); gostcrypt(plain, cipher, key); for (j = 0; j < 99; j++) gostcrypt(cipher, cipher, key); for (j = 0; j < 100; j++) gostdecrypt(cipher, cipher, key); if (plain[0]
!= c i p h e r [0]
fprintf (st d e r r , "\nError!
Il plain[l]
return 1;
> } printf("Ail tests passed.\n"); return 0;
} (fendif /* TEST */
!= c i p h e r [1]) {
i = 7,d\n", i) ;
Blowfish blowfîsh.c #include #include #include #include #ifdef little_endian
/* Eg: Intel */
#include #endif #include #ifdef little_endian
/* Eg: Intel */
#include #include #endif #ifdef big_endian #include #endif typedef struct { unsigned long S [4] [256] , P[18] ; > blf_ctx; #define MAXKEYBYTES 56 /* 448 bits */ /*// #define little-endian 1 / * Eg: Intel * / #define big_endian 1 /* Eg: Motorola */ void Blowfish_encipher(blf_ctx * c , unsigned long *xl, unsigned long * x r ) ; void Blowfish_decipher(blf_ctx * c ,
unsigned long *xl, unsigned long * xr);
short InitializeBlowfish(blf_ctx *c, char k e y [ ] , short k e ybytes); #define N #define noErr
16 0
#define DATAERROR #define KEYBYTES
-1 8
712
B l o w f is h
unsigned long F(blf_ctx * b c , unsigned long x)
{ unsigned short a; unsigned short b; unsigned short c; unsigned short d; unsigned long
y;
d = x & OxOOFF; x »=
8;
c = x & OxOOFF; x >>= 8; b = x ft OxOOFF; x » = 8; a = x & OxOOFF; /*// y = C (bc->S [0] [a] + bc->S[l] [b] ) ' bc->S [2] [c] ) + b c - > S [3] [d] ; */ y = bc->S[0] [a] + bc->S[l] [b] ; y = y “ bc->S [2] [c] ; y = y + bc->S [3] [d] ; return y;
> void B lowfish_encipher(blf_ctx *c, unsigned long *xl, unsigned long *xr)
{ unsigned long
XI;
unsigned long
Xr;
unsigned long
temp;
short
i;
XI = *xl; Xr = * x r ; for (i = 0; i < N; ++i) { XI = XI ' c->P[i] ; Xr = F(c,Xl)
' Xr;
temp = XI; XI = Xr; Xr = temp;
> temp = XI; XI = Xr; Xr = temp; Xr = Xr " c->P[N] ; XI = XI * c->P [N + 1] ; *xl = XI; *xr = Xr;
713
Bl o w f is h
toid
Blowfish_decipher(blf_ctx *c, unsigned long *xl, unsigned long *xr)
[ unsigned long
XI;
unsigned long
Xr;
unsigned long
temp;
short
i;
XI = *xl; Xr = * x r ; for ( i = N + l ; i > l ;
— i) {
XI = XI " c->P[i] ; Xr = F(c,Xl)
' Xr;
/ * Exchange XI and X r */ temp = XI; XI = Xr; Xr = temp;
> /* Exchange XI and Xr */ temp = XI; XI = Xr; Xr = temp; Xr = Xr “ c->P[i]; XI = XI * c - > P [0]; *xl = XI; *xr = Xr;
> short InitializeBlowfish(blf_ctx *c, char k e y [ ] , short keybytes)
i short short short short
i; j; k; error;
short
numread;
unsigned long
data;
unsigned long
datai;
unsigned long
datar;
unsigned long ks0[] =
-t
0xdl310ba6, 0x98dfb5ac, 0x2ffd72db, 0xd01adfb7, 0xb8elafed, 0x6a267e96, 0xba7c9045, 0xfl2c7f99, 0x24al9947, 0xb3916cf7, 0x801f2e2, 0x858efcl6, 0x636920d8, 0x71574e69, 0xa458fea3, 0xf4933d7e, 0xd95748f, 0x728eb658, 0x718bcd58, 0x82154aee, 0x7b54a41d, 0xc25a59b5, 0x9c30d539, 0x2af26013, 0xc5dlb023, 0x286085f0, 0xca417918, 0xb8db38ef, 0x8e79dcb0, 0x603al80e,
714
B l o w f is h
0x6c9e0e8b, 0xb01e8a3e, 0xd71577cl
0xbd314b27, 0x78af2fda, 0x55605c60,
0xe65525f3, 0xaa55ab94, 0x57489862
0x63e81440, Ox55ca396a, 0x2aabl0b6,
0xb4cc5c34, 0xll41e8ce, 0xal5486af
0x7c72e993,
0x2ba9c55d, 0x741831f6, 0xce5c3ei6
0x9b87931e, 0xafd6ba33, 0x6c24cf5c,
0x7a325381, 0x28958677, 0x3b8f4898
0x6b4bb9af, 0xc4bfe81b, 0x66282193,
0x61d809cc, 0xfb21a991, 0x487cac60
0x5dec8032, 0xef845d5d, 0xe98575bl,
0 x d c 262302, 0xeb651b88, 0x23893e81 0x 2 e 0b4482, 0xa4842004, 0x69c8f04a
Ox9elf9b5e, 0x21c66842, 0xf6e96c9a,
0x670c9c61, 0xabd388f0, 0x6a51a0d2
0xd8542f68, 0x960fa728, 0xab5133a3,
0xb3eel411, 0x636fbc2a,
0xd396acc5, 0xf6d6ff3, 0x83f44239,
0x6eef0b6c, 0xl37a3be4, 0xba3bf050
0x7efb2a98, 0xalfl651d, 0x39af0176,
0x66ca593e, 0x82430e88, 0x8cee8619
0x456f9fb4, 0x7d84a5c3, 0x3b8b5ebe,
0xe06f75d8, 0x85cl2073, 0x401a449f: 0x56cl6aa6, 0x4ed3aa62, 0x363f7706, Oxlbfedf72, 0x429b023d, 0x37d0d724
0xd00al248, 0xdb0fead3, 0x49flc09b,
0x75372c9, 0x80991b7b, 0x25d479d8, 0xf6e8def7, 0xe3fe501a, 0xb6794c3b, 0x976ce0bd, 0x4c006ba, 0xcla94fb6, 0x409f60c4, 0x5e5c9ec2, 0xl96a2463, 0 x 6 8 fb6faf, 0x3e6c53b5, 0xl339b2eb; 0x3b52ec6f, Ox6dfc511f, 0x9b30952c, 0xcc814544, 0xaf5ebd09, 0xbee3d004; 0xde334afd, 0x660f2807, 0xl92e4bb3, 0xc0cba857, 0x45c8740f, 0xd20b5f39; 0xb9d3fbdb, 0x5579c0bd, 0xla60320a, 0x679f25fe,
0xfblfa3cc, 0x8ea5e9f8, 0xdb3222f8,
0x3c75 1 6 d f , 0xfd616bl5, 0x2f501ec8,
0xad0552ab, 0x323db5fa, 0xfd238760,
0x53317b48, 0x3e00df82, 0x9e5c57bb
0xca6f8ca0, Oxla87562e, 0xdfl769db,
0xd6al00c6, 0x402c7279,
0xd542a8f6, 0x287effc3, 0xac6732c6, 0x8c4f5573, Ox695b27bO, 0xbbca58c8, 0xelffa35d, 0xb8f011a0, 0xl0fa3d98,
0xfd2183b8, 0x4afcb56c, 0x2ddld35b,
0x9a53e479, 0xb6f84565, 0xd28e49bc, 0x4bfb9790, 0xelddf2da, 0xa4cb7e33, 0x62fbl341, 0xcee4c6e8, 0xef20cada
0x36774c01, 0xd07e9efe, 0x2bfllfb4,
0x95dbda4d, 0xae909198, 0xeaad8e71.
0x6b93d5a0, 0xd08edld0, 0xafc725e0,
0 x 8 e 3c5b2f, 0x8e7594b7, 0x8ff6e2fb
Oxf2122b64, 0x8888b812, 0x900df01c,
0x4fad5ea0, 0x688fc31c, Oxdlcff191.
0xb3a8clad, 0x2f2f2218, 0xbe0el777,
0xea752dfe, 0x8b021fal, 0xe5a0cc0f,
0xb56f74e8, 0xl8acf3d6, 0xce89e299, 0xb4a84fe0, 0xfdl3e0b7, 0x7cc43b81; 0xd2ada8d9, 0xl65fa266, 0x80957705, 0 x 9 3 cc7314, 0x211al477, 0xe6ad2065: 0x77b5fa86, Oxc75442f5, 0xfb9d35cf, OxebcdafOc, 0x7b3e89a0, 0xd6411bd3; 0xaele7e49, 0x250e2d, 0x2071b35e, 0x226800bb, 0x57b8e0af, 0x2464369b,
0xf009b91e, 0x5563911d, 0x59dfa6aa,
0x78cl4389, 0xd95a537f, 0x207d5ba2,
0x2e5b9c5, 0x83260376, 0x6295cfa9,
0xllc81968, 0x4e734a41, 0xb3472dca,
0x7bl4a94a, 0xlb510052, 0x9a532915,
0xd60f573f, 0xbc9bc6e4, 0x2b60a476,
0x81e67400, Ox8ba6fb5, 0x571be91f,
Oxf296ec6b, 0x2a0dd915, 0xb663652i,
0xe7b9f9b6, Oxff34052e, 0xc5855664,
0x53b02d5d, 0xa99f8fal, 0x8ba4799, 0x6e85076a}; unsigned long ksi [] = { 0x4b7a70e9, 0xb5b32944, 0xdb75092e,
0xc4192623, Oxad6ea6bO, 0x49a7df7d,
0x9cee60b8, 0x8fedb266, 0xecaa8c71, 0x699al7ff, 0x5664526c, 0xc2bl9eel, 0xl93602a5, 0x75094c29, 0xa0591340,
0xe4183a3e, 0x3f54989a, 0x5b429d65,
0x6b8fe4d6, 0x99f73fd6, 0xald29c07,
0xefe830f5, 0x4d2d38e6, 0xf0255dcl,
0x4cdd2086, 0x8470eb26, 0x6382e9c6,
0x21ecc5e, Ox9686b3f, 0x3ebaefc9,
0x3c971814, 0x6b6a70al, 0x687f3584, 0x52a0e286, 0xb79c5305, 0xaa500737, 0x3e07841c, 0x7fdeae5c, 0x8e7d44ec,
0x5716f2b8, 0xb03ada37, 0xf0500c0d,
0xf01clf04, 0x200b3ff, 0xae0cf51a, 0x3cb574b2, 0x25837a58, 0xdc0921bd, 0xdl9113f9, 0x7ca92ff6, 0x94324773, 0x22f54701, 0x3ae5e581, 0x37c2dadc, 0xc8b57634, 0x9af3dda7, 0xa9446146, 0xfd0030e, 0xecc8c73e, 0xa4751e41, 0 x e 2 38cd99, 0x 3bea0e2f, 0x3280bbal, 0xl83eb331, 0x4e548b38, 0x4f6db908,
715
B l o w f is h
0x6f420d03, 0xf60a04bf, 0x2cb81290 , 0x24977c79, 0x5679b072, 0xbcaf89af, Ûxde9a77if, 0xd9930810, 0xb38bael2 , 0xdccf3f2e, 0x5512721f, 0x2e6b7l24, 0x501adde6, 0x9f84cd87, 0x7a584718 , 0x7408dal7, 0xbc9f9abc, 0xe94b7d8c, 0xec7aec3a, 0xdb851dfa, 0x63094366 , 0xc464c3d2, 0xeflcl847, 0x3215d908, 0xdd433b37, 0x24c2bal6, 0xl2al4d43 , 0x2a65c451, 0x50940002, 0xl33ae4dd, 0x71dff89e, 0xl0314e55, 0x81ac77d6 , 0x5f11199b, 0x43556f1, 0xd7a3c76b, 0x3clll83b, 0x5924a509, 0xf28fe6ed , 0x97flfbfa, 0x9ebabf2c, 0xlel53c6e, 0x86e34570, 0xeae96fbl, 0x860e5e0a , 0x5a3e2ab3, 0x771fe71c, 0x4e3d06fa, 0x2965dcb9, 0x99e71d0f, 0x803e89d6 , 0x5266c825, 0x2e4cc978, 0x9cl0b36a, 0xc6150eba, 0x94e2ea78, 0xa5fc3c53 , 0xle0a2df4, 0xf2f74ea7, 0x361d2b3d, 0xl939260f, 0xl9c27960, 0x5223a708 , 0xf71312b6, 0xebadfe6e, 0xeac31f66, 0xe3bc4595, 0xa67bc883, 0xbl7f37dl , 0xl8cff28, 0xc332ddef, 0xbe6c5aa5, 0x65582185, 0x68ab9802, 0xeecea50f , 0xdb2f953b, 0x2aef7dad, 0x5b6e2f84, 0x152lb628, 0x29076170, 0xecdd4775 , 0x6l9f1510, 0xl3cca830, 0xeb61bd96, 0x334fele, 0xaa0363cf, 0xb5735c90, 0x4c70a239, 0xd59e9e0b, 0xcbaadel4, 0xeecc86bc, 0x60622ca7, 0x9cab5cab , 0xb2f3846e, 0x648bleaf, 0xl9bdf0ca, 0xa02369b9, 0x655abb50, 0x40685a32 , 0x3c2ab4b3, 0x319ee9d5, 0xc021b8f7, 0x9b540bl9, 0x875fa099, 0x95f7997e , 0x623d7da8, Oxf837889a, 0x97e32d77, 0xlled935f, 0x16681281, 0xe358829, 0xc7e61fd6, 0x96dedfal, 0x7858ba99, 0x57f584a5, 0xlb227263, 0x9b83c3ff: 0xlac24696, 0xcdb30aeb, 0x532e3054, 0x34c6ffea, 0xfe28ed61, 0xee7c3c73, 0x8fd948e4, 0x6dbc3128, 0x58ebf2ef 0 x 5 d 4al4d9, 0xe864b7e3, Ox42105dl4.
0x203el3e0, 0x45eee2b6, 0xa3aaabea,
0xdb6c4f15, 0xfacb4fd0, 0xc742f442; 0xef6abbb5, 0x654f3bld,
0x41cd2105,
0xd81e799e, 0x86854dc7, 0xe44b476a: 0x3d816250, 0xcf62alf2, 0x5b8d2646, 0xfc8883a0, 0xclc7b6a3, 0x7fl524c3.
0x69cb7492, 0x47848a0b, 0x5692b285,
0x95bbf00, 0xadl9489d, 0xl462bl74, 0x23820e00, 0x58428d2a, 0xc55f5ea, 0xldadf43e, 0x233f7061, 0x3372f092,
0 x8d937e41, 0xd65fecfl,
0x7cde3759, 0xcbee7460, 0x4085f2a7,
0xce77326e, 0xa6078084, 0xl9f8509e,
0x6c223bdb,
0xe8efd855, 0x61d99735, 0xa969a7aa,
0xc50c06c2,
0x9e447a2e, 0xc3453484, 0xfdd56705,
0xele9ec9, 0xdb73dbd3, 0xl05588cd,
0x5a04abfc, 0x800bcadc,
0x675fda79, 0xe3674340, 0xc5c43465,
0x713e38d8, 0x3d28f89e, 0xfl6dff20,
0xl53e21e7, 0x8fb03d4a, 0xe6e39f2b
0xdb83adf7>;
unsigned long ks2[] = { 0xe93d5a68, 0x948140f7, 0xf64c261c,
0x94692934, 0x411520f7, 0x7602d4f7,
0xbcf46b2e, 0xd4a20068, 0xd4082471, 0x3320f46a, 0x43b7d4b7, 0x500061af, 0xle39f62e, 0x97244546, 0xl4214f74, 0xbf8b8840, 0x4d95fcld, 0x96b591af, 0x70f4ddd3, 0x66a02f45, 0xbfbc09ec, 0x3bd9785, 0x7fac6dd0, 0x31cb8504, 0x96eb27b3, 0x55fd3941, 0xda2547e6, 0xabca0a9a, 0x28507825, 0x530429f4, 0xa2c86da, 0xe9b66dfb, 0x68dcl462, 0xd7486900, 0x680ec0a4, 0x27al8dee, 0x4f3ffea2, 0xe887ad8c, 0xb58ce006, 0x7af4d6b6, 0xaacele7c, 0xd3375fec, 0xce78a399, 0x406b2a42, 0x20fe9e35, 0xd9f385b9, 0xee39d7ab, 0x3bl24e8b, 0xldc9faf7, 0x4b6dl856, 0x26a36631, 0xeae397b2, 0x3a6efa74, 0xdd5b4332, 0x6841e7f7, 0xca7820fb, 0xfb0af54e, 0xd8feb397, 0x454056ac, 0xba489527, 0x55533a3a, 0x20838d87, 0xfe6ba9b7, 0xd096954b, 0x55a867bc, 0xall59a58, 0xcca92963, 0x99eldb33, 0xa62a4a56, 0x3f3125f9, 0x5ef47elc, 0x9029317c, Oxfdf8e802, 0x4272f70, 0x80bbl55c, 0x5282ce3 , 0x95cll548, 0xe4c66d22, 0x48cll33f, 0xc70f86dc, 0x7f9c9ee, 0x41041fOf, 0x404779a4, 0x5d886el7, 0x325f51eb, 0xd59bc0dl, 0xf2bccl8f, 0x41113564, 0x257b7834, 0x602a9c60, 0xdff8e8a3, 0xlf636clb, 0xel2b4c2, 0x2el329e, 0xaf664fdl, 0xcadl8115, 0x6b2395e0, 0x333e92el, 0x3b240b62, 0xeebeb922, 0x85b2a20e, 0xe6ba0d99,
716
B l o w f ish
0xde720c8c, 0x2da2f728,
0xd0127845, 0x95b794fd,
0x5449a36f, 0x877d48fa,
0xc39dfd27, 0xf33e8dle,
0x647d0862, 0xe7ccf5f0, 0xa476341, 0x992eff74,
0x3a6f6eab, 0xf4f8fd37,
0xa812dc60, 0xalebddf8,
0x991bel4c, 0xdb6e6b0d,
0xc67b5510, 0x6d672c37,
0x2765d43b, 0xdcd0e804,
Oxf1290dc7, 0xcc00ffa3,
0xb5390f92, 0x690fed0b,
0x667b9ffb, 0xcedb7d9c,
0xa091cf0b, 0xd9155ea3,
0xbbl32f88, 0x515bad24,
0x7b9479bf, 0x763bd6eb,
0x37392eb3, 0xccll5979,
0x8026e297, 0xf42e312d,
0x6842ada7, 0xc66a2b3b,
0xl2754ccc, 0x782efllc,
0x6al24237, 0xb79251e7, 0x6albbe6, 0x4bfb6350, 0xla6bl018, Oxllcaedfa, 0x3d25bdd8, 0xe2elc3c9, 0x44421659, 0xal21386, 0xd90cec6e, 0xd5abea2a, 0x64af674e, 0xda86a85f,
0xbebfe988, 0x64e4c3fe,
0x9dbc8057, 0xf0f7c086,
0x60787bf8, 0x6003604d,
0xdlfd8346, 0xf6381fb0,
0x7745ae04, 0xd736fccc,
0x83426b33, 0xf01eab71,
0xb0804187, 0x3c005e5f,
0x77a057be, 0xbde8ae24,
0x55464299, 0xbf582e61,
0x4e58f48f, 0xf2ddfda2,
0xf474ef38, 0x8789bdc2,
0x5366f9c3, 0xc8b38e74,
0xb475f255, 0x46fcd9b9,
0x7aeb2661, 0x8blddf84,
0x846a0e79, 0x915f95e2,
0x466e598e, 0x20b45770,
0x8cd55591, 0xc902de4c,
0xb90bacel, 0xbb8205d0,
0xlla86248, 0x7574a99e,
0xb77fl9b6, 0xe0a9dc09,
0x662d09al, 0xc4324633, 0xe85alf02, 0x9f0be8c, 0x4a99a025, 0xld6efel0, 0xlab93dld, 0xba5a4df, 0xal86f20f, 0x2868fl69, 0xdcb7da83, 0x573906fe, 0xale2ce9b, 0x4fcd7f52,
0x50115e01, 0xa70683fa,
0xa002b5c4, 0xde6d027,
0x9af88c27, 0x773f8641,
0xc3604c06, 0x61a806b5,
0xf0177a28, 0xc0f586e0,
0x6058aa, 0x30dc7d62, 0xlle69ed7, 0x2338ea63, 0x53c2dd94, 0xc2c21634, 0xbbcbee56, 0x90bcb6de,
0xebfc7dal, 0xce591d76, 0x6f05e409, 0x4b7c0188,
0x39720a3d, 0x7c927c24,
0x86e3725f, 0x724d9db9, 0xlacl5bb4, 0xd39eb8fc,
0xed545578, 0x8fca5b5, 0xd83d7cd3, 0x4dad0fc4, 0xle50ef5e, 0xbl61e6f8, 0xa28514d9, 0x6c51133c,
0x6fd5c7e7, 0x56el4ec4, 0x362abfce, 0xddc6c837,
0xd79a3234, 0x92638212,
0x670efa8e, 0x406000e0>;
unsigned long ks3[] = { 0x3a39ce37, 0xd3faf5cf,
0xabc27737, 0x5ac52dlb, 0x5cb0679e, 0x4fa33742,
0xd3822740, 0x99bc9bbe,
0xd5118e9d, 0xbf0f7315, 0xd62dlc7e, 0xc700c47b,
0xb78clb6b, 0x21al9045,
0xb26eblbe, 0x6a366eb4, 0x5748ab2f, 0xbc946e79,
0xc6a376d2, 0x6549c2c8,
0x530ff8ee, 0x468dde7d, 0xd5730ald, 0x4cd04dc6,
0x2939bbdb, 0xa9ba4650,
0xac9526e8, 0xbe5ee304, 0xalfad5f0, 0x6a2d519a,
0x63ef8ce2, 0x9a86ee22,
0xc089c2b8, 0x43242ef6, 0xa51e03aa, 0x9cf2d0a4,
0x83c061ba, 0x9be96a4d,
0x8fe51550, 0xba645bd6, 0x2826a2f9, 0xa73a3ael,
0x4ba99586, 0xef5562e9,
0xc72fefd3, 0xf752f7da, 0x3f046f69, 0x77fa0a59,
0x80e4a915, 0x87b08601,
0x9b09e6ad, 0x3b3ee593, 0xe990fd5a, 0x9e34d797,
0x2cf0b7d9, 0x22b8b51, 0x96d5ac3a, 0xl7da67d, 0xdlcf3ed6, 0x7c7d2d28, 0xlf9f25cf, 0xadf2b89b,
0x5ad6b472, 0x5a88f54c, 0xe029ac71, 0xe019a5e6,
0x47b0acfd, 0xed93fa9b,
0xe8d3c48d, 0x283b57cc, 0xf8d56629, 0x79132e28,
0x785f0191, 0xed756055,
0xf7960e44, 0xe3d35e8c, 0xl5056dd4, 0x88f46dba,
0x3al6125, 0x564f0bd, 0xc3eb9el5, 0x3c9057a2, 0x97271aec, 0xa93a072a, 0xlb3f6d9b, 0xle6321f5, 0xf59c66fb, 0x26dcf319, 0x7533d928, 0xbl55fdf5, 0x3563482, 0x8aba3cbb, 0x28517711, 0xc20ad9f8, 0xabcc5167, 0xccad925f, 0x4de81751, 0x3830dc8e,
0x379d5862, 0x9320f991, 0xea7a90c2, 0xfb3e7bce,
0x5121ce64, 0x774fbe32,
0xa8b6e37e, 0xc3293d46, 0x48de5369, 0x6413e680,
0xa2ae0810, 0xdd6db224, 0x69852dfd, 0x9072166, 0xb39a460a, 0x6445c0dd, 0x586cdecf, 0xlc20c8ae,
0x5bbef7dd, 0xlb588d40, 0xccd2017f, 0x6bb4e3bb,
0xdda26a7e, 0x3a59ff45,
0x3e350a44, 0xbcb4cdd5, 0x72eacea8, 0xfa6484bb,
0x8d6612ae, 0xbf3c6f47,
0xd29be463, 0x542f5d9e, 0xaec2771b, 0xf64e6370,
0x740e0d8d, 0xe75bl357,
0xf8721671, 0xaf537d5d, 0x4040cb08, 0x4eb4e2cc,
111
B l o w f is h
0x34d2466a, 0xll5af84, 0xelb00428, Ox95983ald, 0x6b89fb4, 0xce6ea048, 0x6f3f3b82, 0x3520ab82, 0xllald4b, 0x277227f8, 0x611560bl, 0xe7933fdc, 0xbb3a792b, 0x344525bd, 0xa08839el , 0x51ce794b, 0x2f32c9b7, 0xa01fbac9, 0xeûlcc87e, 0xbcc7dlf6,
0xcfûlllc3 , 0xale8aac7,
0xla908749, Oxd44fbd9a,
OxdOdadecb, 0xd50ada38, 0x339c32a, 0xc6913667, 0x8df9317c, 0xe0bl2b4f, 0xf79e59b7, 0x43f5bb3a, 0xf2d519ff , 0x27d9459c, 0xbf97222c, 0xl5e6fc2a, 0xf91fc71, 0x9b941525, 0xfae59361, 0xceb69ceb, 0xc2a86459, 0xl2baa8dl, 0xb6cl075e, 0xe3056a0c, 0xl0d25065 , 0xcb03a442, 0xe0ec6e0e, 0xl698db3b, 0x4c98a0be, 0x3278e964, 0x9flf9532 , 0xe0d392df, 0xd3a0342b, 0x8971f21e, 0xlb0a7441, 0x4ba3348c, 0xc5be7120 , 0xc37632d8, 0xdf359f8d, 0x9b992f2e, 0xe60b6f47, 0xfe3flld, 0xe54cda54, 0xledad891, 0xce6279cf, 0xcd3e7e6f, 0xl618bl66, 0xfd2cld05, 0x848fd2c5,
Oxf6fb2299, 0xf523f357, 0xa6327623,
0x93a83531, 0x56cccd02, Oxacf08162,
0x5a75ebb5, 0x6el63697, 0x88d273cc,
Oxde966292, 0x81b949d0, 0x4c50901b,
0x71c65614, 0xe6c6c7bd, 0x327al40a,
0x45eld006, 0xc3f27b9a, 0xc9aa53fd,
0x62a80f00, 0xbb25bfe2, 0x35bdd2f6,
0x71126905, 0xb2040222, 0xb6cbcf7c,
0xcd769c2b, 0x53113ec0, 0xl640e3d3,
0x38abbd60, 0x2547adf0,
0xf746ce76, 0x77afalc5, 0x20756060,
0xba38209c,
0x85cbfe4e, 0x8ae88dd8, 0x7aaaf9b0, 0x4cf9aa7e, 0xl948c25c, 0x2fb8a8c, 0xlc36ae4, 0xd6ebelf9, 0x90d4f869,
0xa65cdea0, 0x3f09252d, 0xc208e69f,
0xb74e6132, 0xce77e25b, 0x578fdfe3, 0x3ac372e6};
/ * Initialize S-boxes without file read. */ for(i = 0; i < 256; ++i){ c->S[0][i]
= ks0[i];
c->S[l][i] = k s l [ i ] ; c->S [2] [i] = ks2 [i] ; c->S[3][i] = k s 3 [ i ] ;
> j = 0; for (i = 0; i < N + 2 ;
++i) {
data = 0x00000000; for (k = 0; k < 4; ++k) { data = (data «
8)
I key[j] ;
j = j + i; if (j >= keybytes) { j = 0;
> } c->P[i] = c->P[i]
* data;
> datai = 0x00000000; datar = 0x00000000; for (i = 0; i < N + 2; i += 2) C Blowfish_encipher(c.fedatal, fcdatar); c->P[i] = datai;
718
B lo w f is h
c->P[i + 1] = datar;
> for (i = 0; i < 4; ++i) { for (j = 0 ;
j < 256; j += 2) {
Blowfish_encipher(c,&datal, ftdatar); c->S[i][j] = datai; c->S[i] [j + 1] = datar;
} > void blf_key(blf_ctx *c, char *k, int len){ InitializeBlowfish(c,k,len);
> void blf_enc(blf_ctx *c, unsigned long *data,
int b l o c k s M
unsigned long *d; int i; d = data; for(i = 0; i < blocks; i++){ B lowfxsh_encipher(c,d,d+l); d += 2;
> > void blf_dec(blf_ctx *c, unsigned long *data, int blocks){ unsigned long *d; int i; d = data; for(i = 0; i < blocks;
i++){
Blowfish_decipher(c,d,d+l); d += 2;
>
y void main(void){ blf_ctx c; char key[] = "AAAAA" ; unsigned long d a t a[10]; int i; for(i = 0; i < 10; i++) data[i] = i; blf_key(&c,key,5); blf_enc(&c,data,5); blf_dec(&c,data,l);
719
B l o w f is h
blf_dec(&c,data+2,4); for(i = 0; i < 10; i += 2) printf("Block XOld decrypts to: y.081x y.081x.\n", i/2, data[i] , data[i+l]);
3-Way 3way.c #define
STRT_E
OxObOb /* round constant of first encryption round
*/
#define
STRT_D
Oxblbl /* round constant of first decryption round
*/
#define
NMBR
#ifdef
alpha
11 / * number of rounds is 11
/* Any other 64-bit machines? * /
typedef unsigned int word32; #else typedef unsigned long word32; #endif /* the program only works correctly if long = 32bits */ / * inverts the order of the bits of a */
void mu(word32 *a)
t int i ; word32 b[3]
;
b[0] = b[l] = b[2] = 0 ; for( i=0 ; i<32 ; i++ )
{ b[0] <<= 1
; b[l] « =
if(a[0]&l)
b[2]
1
if(a[l]fcl) if(a[2]&l) a[0] » = 1
b[l] 1= 1 ; b[0] 1= 1 ; ; a[l] » = 1
; b[2]
«=
1 ;
; a[2]
»=
1 ;
1= 1 ;
> a[0] = b[0]
; a[l] = b[l]
; a[2] = b[2]
;
> void gaimna(word32 *a)
/* the nonlinear step */
t word32 b [3] b[0]
;
= a[0] * (a[l]|(~a[2]))
b[l]
= a[l] ' (a[2] I(~a[0]))
b[2]
= a[2] * (a[0]|('a[l]>)
*/
122
3 -W
a[0] = b[0]
; a[l] = b[l]
; a[2] = b[2]
;
>
void theta(word32 *a)
/* the linear step */
{ word32 b [ 3 ] ; b[0] = a[0]
b[l] = a[l]
-
b[2] = a [2] ‘
a[0] = b[0]
*“• ( a [ 2 ] « 1 6 )
(a[0] » 1 6 )
" (a[l]«16)
(a[l]»16)
(a[l]»24)
" (a[2]«8)
(a[2]»8)
(a[0]«24)
(a [ 2 ] » 1 6 )
* (a[0]«16)
(a [2] » 2 4 )
(a[0]«8)
(a[l]»16)
' (a[2]«16)
(a [2] » 1 6 )
(a[0]«16) * (a[l]«24)
(a [ 2 ] » 2 4 )
' (a[0]«8)
(a[0] » 8 )
(a[0]»16)
" (a[l]«16)
(a[0] » 2 4 )
(a[l]«8)
(a[2]»16) (a[0]»24)
‘ (a[0]«16) ‘ (a[l]«8)
(a[0]»16)
(a[l]«16)
(a[l]»16)
* (a[2]«16)
(a[l]»8) (a[l]»24)
(a[2]«8)
a[l] = b[l]
;
;
a [2] = b[2]
;
void pi_l(word32 *a)
{ » (a[0]»10) * (a[0]«22);
a [2]
= (a[2]«l)
* (a [ 2 ] » 3 1 ) ;
> void pi_2(word32 *a)
{ a[0]
= (a[0]«l)
' (a[0]»31) ;
a [2]
=( a [ 2 ] » 1 0 )
* (a[2]«22);
> void rho(word32 *a)
/* the round function
*/
{ thêta(a) pi_l(a)
; ; ;
gamma(a) pi_2(a)
;
} void rndcon_gen(word32 strt,word32 *rtab) {
/* generates the round constants */
int i ; for(i=0 ; i<=NMBR ; i++ )
{ rtab[i] = strt strt « = 1 ;
;
if( strt&OxlOOOO ) strt “= 0x11011 ;
** 9 **
(a [2] « 2 4 )
>
a[0]
»
î
ay
723
î- W a y
y
y
roid encrypt (word32 *a, word32 *k)
[ Lnt i ; ïord32 rcon [NMBR+1]
;
rndcon_gen(STRT_E,rcon) Cor( i=0 ; K N M B R atO]
“= k[û]
;
; i++ )
* (rcon [i] « 1 6 )
a[l] “= k[l]
;
a [2] ~= k[2]
' rcon[i]
;
;
;
rho(a)
y i[0] “= k[0]
“ (rcontNMBR] « 1 6 )
itl] '= k[l]
;
i[2] “= k[2] * rcontNMBR] b h eta(a)
;
;
;
Y
iroid decrypt(word32 *a, word32 *k)
( int i ; ïord32 ki[3]
;
/* the ‘i nverse’ key
»ord32 rconfNMBR+1] kifO] = ktO] theta(ki) Bu(ki)
;
; ki[l] = ktl]
; kit2] = k[2]
;
;
rndcon_gen(STRT_D,rcon)
;
mu(a) ; for( i=0 ; i
{ a[0]
~= ki[0]
* (rcon [i] « 1 6 )
a[l]
~= ki[l]
;
a [2] '= ki[2] rho(a)
* rcon[i]
;
;
;
> atO] “= kifO]
* (rcon[NMBR] <<16)
a[l] ~= ki[l]
;
a [2] ~= k i [2] * rcontNMBR] theta(a) mu(a)
;
;
> #ifdef TEST
*/
/ * the ‘in v e r s e ’ round constants * /
;
;
;
724
3 -W
#include ttinclude #define RAND32 ((word32)rand() «
17 ' (uord32)rand() «
void printvec(word32 *a)
i. #ifdef
alpha
printf ("*/i08x ’ /,08x */.08x\nM ,a[2] ,atl] ,a[0] ) ; #else printf ( '7.081x 7.081x 7.081x\n",a [2] ,a tl] ,a [0] ) ; #endif
> void m a i n O
{ word32 vector[3], key [3] ,plain [3] ; int i , j ; p r intf(”3-way test run\nM); for (i = 0; i < 10; i++) { for (j = 0; j < 3; j++) { key [j] = RAND32 ; p l a i n [j]=vector tj] = R A N D 3 2 ;
> printf ("7.3d\r", i) ; fflush(stdout); for (j = 0; j < 100; j++) encrypt(vector,key); for (j = 0; j < 100; j++) decrypt(vector.key); if (vector[0] vector[2]
!= plaintO]
Il vectortl]
fprintf (stderr, "\nError!
i = '/.d\n", i);
exit(l);
} > printf("Ail tests passed.\n"); key[0]=4; key[l]=5; k e y [2] =6; vector[0]=l; vectortl] =2; vectorf2]=3; e ncrypt(vector.key); printvec(vector);
> #endif /*
!= plaintl]
!= plain [2] ) t
TEST VALUES
key
: 00000000 00000000 00000000
plaintext
: 00000001 00000001 00000001
Il
9 * randO)
ay
3 -W
725
ay
ciphertext
: ad21ecf7 83ae9dc4 4059c76e
key plaintext
: 00000004 00000005 00000006 : 00000001 00000002 00000003
ciphertext
: cab920cd d6144138 d2f05b5e
key
: bcdef012 456789ab def01234
plaintext
: 01234567 9abcdef0 23456789
ciphertext
: 7 cdb76b2 9cdddb6d 0aa55dbb
key
: cab920cd d6144138 d2f05b5e
plaintext
: ad21ecf7 83ae9dc4 4059c76e
ciphertext
: 15bl55ed 6bl3f17c 478ea871
RC5 rc5.c /* RC5REF.C —
Reference implémentation of RC5-32/12/16 in C.
/ * Copyright (C) 1995 RSA Data Security, Inc.
*/ */
#include #include typedef unsigned long int WORD; /* Should
be 32-bit = 4 bytes
*/
#define w
32
/* word size in bits
*/
#define r
12
/* number
of rounds
*/
#define b
16
/ * number
of bytes in key
*/
#define c
4
#define t
26
WORD S [ t ] ;
/ * number
words in key = ceil(8*b/w)*/
/ * size of table S = 2*(r+l) words
*/
/ * expanded key table
*/
/ * magic constants
WORD P = 0xb7el5163, Q = 0x9e3779b9;
*/
/ * Rotation operators. x must be unsigned, to get logical right shift*/ #define ROTL(x,y)
( ( (x)«(y&(w-l)))
I ((x)»(w-(y&(w-l)))))
#define ROTR(x,y)
C ( ( x ) » (y&(w-1)))
I ((x)«(w-(y&(w-l)))))
void RC5_ENCRYPT(W0RD *pt, WORD *ct) /* 2 WORD input pt/output ct
*/
{ WORD i, A=pt [0] + S [0] , B = p t [1] + S [1] ; for (i=l; i<=r; i++) { A = R0TL(A"B,B)+S[2*i] ; B = R0TL(B“A,A)+S[2*i+1];
> ct[0] = A; ct[l] = B;
> void RC5_DECRYPT(W0RD *ct, WORD *pt) /* 2 WORD input ct/output pt l
*/
WORD i, B = c t [1], A = c t [0]; for (i=r; i>0; i— ) { B = R0TR(B-S[2*i+1],A)-A; A = R0TR(A-S[2*i],B)"B;
y pt[l] = B-S[l] ; pt[0] = A-S[0] ;
void RC5_SETUP(unsigned char *K) /* secret input key K[0...b-1] {
WORD i, j, k, u=w/8, A, B, L[c]; /* Initialize L, then S, then mix key into S */
*/
728
RC5
for (i=b-l,L[c-l]=0; i !=—1 ; i— ) L[i/u] = (L[i/u]«8)+K[i] ; for (S[0]=P,i=l; i
/* 3*t > 3*c */
{ A = S[i] = ROTL(S[i] + (A+B) ,3) ; B = L[j] = ROTL(L[j] + (A+B) , (A+B)) ;
>
void m a i n O { WORD i, j, p t l [2] , p t 2 [2] , ct[2] = {0,0}; unsigned char key[b]; time_t tO, tl; if (sizeof(WORD)!=4) printf ("RC5 error: WORD has '/.d bytes.\n".sizeof (WORD)) ; printf("RC5-32/12/16 examples:\ n ”); for (i=l;i<6;i++) { /* Initialize ptl and key pseudorandomly based on previous ct */ pt 1 [0] =ct [0] ; pt 1 [1] =ct [1] ; for (j=0; j
= ct[0]7.(255-j) ;
/* Setup, encrypt, and decrypt */ RC5_SETUP(key); RC5_ENCRYPT(pt1,c t ) ; RC5_DECRYPT(ct,pt2); / * Print out results, checking for decryption failure */ p r i n t f ("\nJCd. key = ",i); for (j=0; j
” ,key[j]);
plaintext */,.81X V..81X
>
ciphertext X.81X X.81X
ptl[0], ptl[l], ct[0], ct [1] ) ; if (ptl [0] !=pt2 [0] Il ptl[l] !=pt2[l] ) printf("Decryption Error!");
> time (&t0); for (i=l;i<100000;i++) R C5.ENCRYPT(ct,c t ) ; time (fttl); printf ("\n
Time_t for 100000 blocks:
V.ld \ n " , tl-tO) ;
\n",
A5 a5.c static int threshold(rl, r2, r3) unsigned int rl; unsigned int r2; unsigned int r3;
{ int total; total =
(((rl »
9) &
0x1) == 1) +
(((r2 »
11) &
0x1) == 1) +
(((r3 »
11) fc 0x1) == 1);
if (total > 1) return (0); else return (1);
} unsigned long clock_rl(ctl, rl) int ctl; unsigned long rl;
{ unsigned long feedback;
/* * Primitive polynomial x**19 + x**5 + x**2 + x + 1
*/ ctl “= ((rl »
9) & 0x1);
if (ctl)
{ feedback = (rl » rl = (rl «
18) ' (rl »
1) & 0 x7ffff;
if (feedback fe 0x01) rl "= 0x01;
} return (rl);
17) " (rl »
16) ' (rl »
13);
A5
730
unsigned long clock_r2(ctl, r2) int ctl; unsigned long r2;
{ unsigned long feedback;
/* * Primitive polynomial x**22 + x**9 + x**5 + x + 1
*/ ctl '= ((r2 »
11) ft 0x1);
if (ctl)
{ feedback = (r2 » r2 = (r2 «
21) “ (r2 »
20) * (r2 »
16) ~ (r2 »
12);
1) & 0x3fffff;
if (feedback & 0x01) r2 "= 0x01;
} return (r2);
> unsigned long clock_r3(ctl, r3) int ctl; unsigned long r3; unsigned long feedback;
/* * Primitive polynomial x**23 + x**5 + x**4 + x + 1
*/ ctl ~= ((r3 »
11) & 0x1);
if (ctl)
{ feedback = (r3 » r3 = (r3 «
22) * (r3 »
21) * (r3 »
18) “ (r3 »
1) & 0x7fffff;
if (feedback ft 0x01) r3 *= 0x01;
> return (r3);
int keystream(key, frame, alice, bob) */
unsigned char
*key;
/* 64 bit session key
imsigned long
frame;
/* 22 bit frame sequence number
*/
unsigned char
*alice;
/ * 114 bit Alice to Bob key stream
*/
unsigned char
*bob;
/* 114 bit Bob to Alice key stream
*/
C unsigned long rl;
/ * 19 bit shift register */
17);
A5_________________________________________________________________________ 731 */
unsigned long r2;
/* 22 bit shift register
unsigned long r3;
/* 23 bit shift register
*/
int i;
/* counter for loops
*/
int clock_ctl;
/* xored with clock enable on each shift register */
unsigned char *ptr; / * current position in keystream * / unsigned char byte; /* byte of keystream being assembled * / unsigned int bits;
/* number of bits of keystream in byte */
unsigned int bit;
/* bit output from keystream generator * /
/ * Initialise shift registers from session key */ rl = (key[0]
I (key[l] «
r2 = ((key[2] »
3)
8)
I (key [2] «
I (key[3] «
16) ) fe 0x7ffff;
5)
I (key[4] «
13)
I (key[5] «
7)
I (key[7] «
15) ) fe 0x7fffff;
21))
fe 0x3fffff ; r3 = ((keyt5] »
1)
I (key [6] «
/ * Merge frame sequence number into shift register State, by x o r ’ing it * into the feedback path
*/ for (i=0;i<22;i++)
i clock_ctl = threshold(rl, r2, r 2 ) ; rl = clock_rl(clock_ctl, r l ) ; r2 = clock_r2(clock_ctl, r 2 ) ; r3 = clock_r3(clock_ctl, r 3 ) ; if (frame fe 1)
{ rl *= 1; r2 *- 1; r3 *= 1;
> frame = frame »
1;
> / * Rini shift registers for 100 clock ticks to allow frame nimber to * be diffused into ail the bits of the shift registers
*/ for (i=0;i<100;i++)
{ clock_ctl = threshold(rl, r2, r 2 ) ; rl = clock_rl(clock_ctl, rl); r2 = clock_r2(clock_ctl, r 2 ) ; r3 = clock_r3(clock_ctl, r 3 ) ;
> /* Produce 114 bits of Alice->Bob key stream */ ptr = alice;
A5
732 bits = 0; byte = O; for (i=0;i<114;i++)
{ clock_ctl = thresholdCrl, r2, r 2 ) ; rl = clock_rl(clock_ctl, rl); r2 = clock_r2(clock_ctl, r 2 ) ; r3 = clock_r3(clock.ctl, r 3 ) ; bit = ((rl »
18) " (r2 »
byte = (byte «
1)
21) * (r3 »
22)) & 0x01;
I bit;
bits++; if (bits == 8) *ptr = byte; ptr++; bits = 0; byte = 0;
> > if (bits) *ptr = byte; /* Run shift registers for another 100 bits to hide relationship between * Alice->Bob key stream and Bob->Alice key stream.
*/ for (i=0;i<100;i++)
{ clock.ctl = threshold(rl, r2, r 2 ) ; rl = clock_rl(clock_ctl, r l ) ; r2 = clock_r2(clock_ctl, r 2 ) ; r3 « clock_r3(clock_ctl, r 3 ) ;
/ * Produce 114 bits of Bob->Alice key stream */ ptr = bob; bits = 0; byte = 0; for (i=0;i<114;i++)
{ clock.ctl * threshold(rl, r2, r2) ; rl =■ clock_rl(clock_ctl, rl) ; r2 « clock_r2(clock_ctl, r 2 ) ; r3 * clock_r3(clock_ctl, r 3 ) ; bit » ((rl »
18) * (r2 »
byte * (byte « bits++; if (bits "
8)
1)
I bit;
21) " (r3 »
22)) t
0x01;
733
A5
i *ptr = byte; ptr++; bits = 0; byte = 0;
} > if (bits) *ptr = byte; return (0);
>
SEAL seal.c / * SEAL */ #define ALG_OK 0 #define ALG.NOTOK 1 #define WORDS_PER_SEAL_CALL 1024 typedef struct { unsigned long t[520]; /* 512 rounded up to a multiple of 5 + 5*/ unsigned long s [265]; / * 256 rounded up to a multiple of 5 + 5*/ unsigned long r [ 2 0 ] ; /* 16 rounded u p to multiple of 5 * / unsigned long counter; / * 32-bit synch value. */ unsigned long ks_buf[WORDS_PER_SEAL_CALL]; int ks_pos; }- seal_ctx; #define R0T2(x)
(((x) » 2 )
I ((x) «
30))
#define R0T8(x)
(((x) » 8 )
I ((x) «
24))
#define R0T9(x)
(((x) » 9 )
I ((x) «
23))
#define
R0T16(x) (((x) »
16) I
((x) «
16))
#define
R0T24(x) (((x) »
24) I
((x) «
8))
#define
R0T27(x) (((x) »
27) I
((x) «
5))
#define
WORD(cp) ( (cp[0] « 2 4 ) I(cp[l) « 1 6 ) I (cp[2] « 8 ) I(cp[3] ))
#define
Fl(x, y, z)
(((x) & (y)) I ((“ (x)) & (z)))
#define
F2(x, y, z)
((x) ' (y) * (z))
#define
F3(x, y, z)
(((x) & (y)) I ((x)
#define
F4(x, y, z)
((x) ~ (y) ~ (z))
fe (z))
int g(in,i,h) unsigned chaur *in; int i; unsigned long *h;
{ unsigned long h0,hl,h2,h3,h4,a,b,c,d,e,temp; unsigned char *kp;
I ((y) & (z)))
SEAL
736 unsigned long w [ 8 0 ] ; kp =
in;
hO =
WDRD(kp); kp += 4;
hl =
WOR D ( k p ) ; k p += 4;
h2 =
WORD(kp); kp += 4;
h3 =
WORD(kp); kp += 4;
h4 =
W ORD(kp); k p += 4;
w[0] = i; for (i=l;i<16;i++) u[i] = 0; for (i=16;i<80;i++) w[i] = v[i-3] ~w[i-8] ~w[i-14] ~w[i-l6] ; a = hO; b * hl; c = h2; d = h3; e = h4; for(i=0;i<20;i++) { temp = R0T27(a) + Fl(b, c, d) + e + w[i] + 0x5a827999; e = d; d = c; c
= R 0 T 2 ( b ) ; b = a; a = temp;
> for (i=20;i<40;i++) { temp = R0T27(a) + F2(b, c, d) + e + w[i] + 0x6ed9ebal; e = d; d = c; c
= R0T2(b); b = a; a = temp;
> for (i=40;i<60;i++) { temp = R0T27(a) + F3(b, c, d) + e + w[i] + 0x8flbbcdc; e = d; d = c; c = R0T2(b); b = a; a = temp;
> for (i=60;i<80;i++)
{
temp = R0T27(a)
+ F4(b, c, d) + e + w[i] + 0xca62cld6;
e = d; d = c; c
= R0T2(b); b = a; a = temp;
> h[0] = hO+a; h[l] = hl+b; h[2] = h2+c; h[3] = h3+d; h[4] = h4+e; return (ALG_0K);
} unsigned long gamma (a,i) unsigned char *a; int i;
{ unsigned long h [5]; (void) g(a,
i/5, h);
return h[i 7, 5] ;
> int seal_init( seal_ctx *result, unsigned char »key )
{
737
SEAL int i; unsigned long h [ 5 ] ; for (i=0;i<510;i+=5) g(key, i/5, fc(result->t[i])); /* horrible spécial case for the end */ g(key, 510/5, h); for(i=510;i<512;i++) result->t[i] = h[i-510] ; /* 0x1000 mo d 5 is +1, so have horrible spécial case for the staxt */ g(key,
(-1+0x1000)/5, h);
for (i=0;i<4;i++) result->s[i] = h[i+l] ; for (i=4;i<254;i+=5) g(key,
(i+0xl000)/5, &(result->s[i])) ;
/* horrible spécial case for the end */ g(key,
(254+0xl000)/5, h);
for (i=254;i<256;i++) result->s[i] = h [ i - 2 5 4 ] ; /* 0x2000 m o d 5 is +2, so have horrible spécial case at the start */ g(key,
(-2+0x20005/5, h);
for(i=0;i<3;i++) result->r[i] = h[i+2] ; for (i=3;i<13;i+=5) g ( k e y ,(i+0x2000)/5,fe(result->r[i])); /* horrible spécial case for the end */ g (key,
( 1 3 + 0 x 2 0 0 0 /5, h);
for (i=13;i<16;i++) result->r[i] = h[i-13] ; return (ALG_0K);
} int seal(seal_ctx *key, unsigned long in, unsigned long *out)
{ int i , j ,1; unsigned long a,b,c,d,nl,n2,n3,n4.*wp; unsigned short p,q; «p = out; for (1=0;1<4;1++) { a = in
key->r [4*1] ;
b = R0T8(in) * k e y - > r [4*1+1]; c = R0T16(in) * k e y - > r [4*1+2]; d = R0T24(in)
“ k e y - > r [4*1+3];
> for (j=0;j<2;j++) { p= a & 0x7fc; b += key->t [p/4] ; a = R0T9(a) ;
738
SEAL
p = b & 0x7fc; c += k e y ->t[p/4]; b = R0T9(b); p = c & 0x7fc; d += key->t[p/4]; c = R0T9(c) ; p = d & 0x7fc; a += key- > t [ p / 4 ]; d = R0T9(d); ni = d; n2=b; n3=a; n4=c; p = a & 0x7fc; b += key->t[p/4]; a = R0T9(a); p = b & 0x7fc; c += key->t[p/4]; b = R0T9(b); p = c & 0x7fc; d += key->t[p/4]; c = R0T9(c); p = d & 0x7fc; a += key->t [p/4]; d = R0T9(d); /* This generates 64 32-bit words, or 256 bytes of keystream. for Ci=0;i<64;i++) { p = a & 0x7fc; b += key->t[p/4]; a = R0T9(a); b “= a; q = b k 0x7fc; c “= k e y ->t[q/4]; b = R0T9(b); c += b; p = (p+c) & 0x7fc; d += key->t[p/4]; c = R0T9(c); d *= c; q = Cq+d) k 0x7fc; a "= k e y - >t[q/4]; d = R0T9(d);
*/
739
SEAL
a += d; p = Cp+a) & Ox7fc; b ~= key->t[p/4] ; a = R0T9(a); q = Cq+b) & 0x7fc; c += key->t[q/4]; b = R0T9(b); p = (p+c) k Ox7fc; d “= key->t[p/4]; c = RQT9(c); q = (q+d) & 0x7fc; a += k e y - >t[q/4]; d = R0T9(d); *wp =
b + key->s[4*i];
*wp =
c “ key->s[4*i+l] ;
wp++;
*wp =
d + k ey - >s[4*i+2]; wp++;
*vrp =
a
wp++;
key->s [4*i+3] ; wp++;
if(i&l) { a += n3; c += n4; } else { a += ni; c += n2;
} y return (ALG_OK);
>
/ * Added call to refill ks_buf and reset counter and ks_pos. * / void seal_refill_buffer(seal_ctx *c){ seal(c,c->counter,c->ks_buf); c->counter++; c->ks_pos = 0;
} void seal_key(seal_ctx *c, unsigned char *key){ seal_init(c,key); c->counter = 0 ; /* By default, init to zéro.
*/
c->ks_pos = WORDS_PER_SEAL_CALL; / * Refill keystream buffer on next call. * /
> /* This encrypts the next w words with SEAL. */
SEAL void seal_encrypt(seal_ctx * c , unsigned long *data_ptr, int w){ int i; f or (i=0 ;iks_pos>=WORDS_PER_SEAL_CALL) seal_refill_buffer(c); data_ptr[i]~=c->ks_buf[c->ks_pos]; c->ks_pos++;
> > void seal_decrypt(seal_ctx *c, unsigned long *data_ptr, int w) { seal_encrypt(c,data_ptr,w);
> void seal_resynch(seal_ctx *c, unsigned long synch_word){ c->counter = synch_word; c->ks_pos = WORDS_PER_SEAL_CALL;
} void main(void){ seal_ctx sc; unsigned long b u f [1000],t; int i.flag; unsigned char key[] = { 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19 }; p r intf("l\n"); seal_key(&sc,k e y ) ; printf("2\n"); for(i=0;i<1000;i++) buf[i]=0; p rintf("3\n"); seal_encrypt(ftsc,buf,1000); pr intf("4\n"); t = 0; for(i=0;i<1000;i++) t = t " buf[i]; printf ("XOR of buf is 5C081x. \n ” ,t) ; seal_key(&sc,key); seal_decrypt(ftsc,buf,1); seal_decrypt(ftsc,buf+l,999); flag - 0; for(i=0;i<1000;i++) if(buf[i]!=0)flag=l; if(flag) printf("Decrypt failed.\n"); else printf ("Decrypt s u c c e e d e d A n " ) ;
}
Lexique anglais—français All-or-Nothing Disclosure O f Secrets (A N D O S ) : secrets Data Encryption Standard (D ES): Elliptic Curve M ethod (E C M ) : Euler phi function :
divulgation tout ou rien de
standard de chiffrement de données
méthode des courbes elliptiques
fonction d’Euler
Euler totient function :
fonction d’Euler
M A C (Message Authentification Code) : code d ’authentification de messages Number Field Sieve (N FS) :
crible sur corps numérique
Pollard’s M onte Carlo algorithm : Secure Hash Algorithm (SH A ) :
algorithme Monte-Carlo de Pollard
algorithme de hachage sûr
Secure Hash Standard (SHS) :
standard de hachage sûr
absolute rate o f the language :
taux absolu du langage
accréditation :
accréditation
adaptative-chosen-plaintext attack: attaque à texte en clair choisi adaptative, attaque à texte en clair choisi dynamique birthday attack : blob :
attaque des anniversaires
pâté
block chaining :
chaînage de blocs
block cipher : algorithme de chiffrement par blocs block replay :
attaque par blocs rejoués
breakable : vulnérable, cassable brute-force attack : attaque exhaustive chosen-ciphertext attack : attaque à texte chiffré choisi
Lexique anglais-français chosen-key attack : attaque à clef choisie chosen-plaintext attack: attaque à texte en clair choisi, attaque à texte en clair choisi statique chosen-text attack : attaque à texte choisi cipher : algorithme cryptographique, chiffre, chiffrement, code ciphertext : texte chiffré, cryptogramme ciphertext-only attack : attaque à texte chiffré seulement cleartext : texte en clair codebook : livre des codes, carnet de codage coin ffipping : jouer à pile ou face compromise : compromission computationally secure algorithm : algorithme invulnérable par calcul, algorith me fort continued fraction :
fraction continue
cryptanalysis : cryptanalyse cryptanalyst : cryptanalyste cryptographer : cryptographe cryptographie algorithm : algorithme cryptographique, chiffre, chiffrement, code cryptography : cryptographie cryptologist : cryptologue cryptology: cryptologie cryptosystem : système cryptographique, cryptosystème, chiffre, code decrypt (to) : déchiffrer decryption : déchiffrement, décryptage, décodage decryption algorithm : algorithme de déchiffrement designated confirmer signature : dictionary attack :
signature à vérificateur dédié
attaque par dictionnaire
double large prime variation o f the multiple polynomial quadratic sieve : variante à 2 grands facteurs premiers du crible quadratique multipolynomial eavesdropper : oreille indiscrète, espion, mouchard
Lexique anglais-français encrypt (to) : chiffrer encryption: chiffrement, encryption, codage encryption algorithm : algorithme de chiffrement end-to-end encryption :
chiffrement de bout en bout233
entrusted undeniable signature : error extension :
signature incontestable arbitrée
amplification d’erreur
feedback with carry shift register : framing :
registre à décalage à rétroaction avec retenue
encadrement
gloabal déduction : obtentionn globale group signature : hard :
signature collective
difficile, dur
homophonie substitution cipher : chiffre à substitution homophonique, chiffre à substitution simple à représentation multiple host computer :
ordinateur hôte
implémentation : réalisation information déduction : obtention d ’information initialization vector : vecteur d ’initialisation interlock protocol : protocole à cliquets intractable :
non soluble
introducer :
parrain
key: clef key crunching :
broyage de clef186
key management :
gestion des clefs
keyspace : espace des clefs keystream generator : knapsack algorithm : knapsack problem :
générateur de codons algorithme à empilement
problème d ’empilement
known-plaintext attack : attaque à texte en clair connu
linear congruential generators : générateurs linéaires congruentiels
Lexique anglais-français linear feedback shift register : link-by-Iink encryption : linking protocol :
registre à décalage à rétroaction linéaire
chiffrement lien par lien
protocole de filiation
login: accès man-in-the-middle attack : meet-in-the-middle attack :
attaque de l’intercepteur attaque par collisions
message: message mimic function : fonction mimétique minimum-disclosure proof : mix-and-mash :
preuve à divulgation minimale
mélange-et-broie
multiple encryption:
surchiffrement
multiple polynomial quadratic sieve :
crible quadratique multipolynomial
multispeed inner-product generator :
générateur multivitesse à produit scalaire
nonce :
nombre aléatoire
obfuscation :
dissimulation
oblivious transfer :
transfert inconscient
obtention locale : obtention locale one-key algorithm : algorithme à clef secrète one-time pad : masque jetable padding : password :
remplissage mot de passe
plaintext : texte en clair polyalphabetic substitution cipher : chiffre à substitution polyalphabétique polygram substitution cipher : chiffre à substitution simple par polygrammes privacy : vie privée, confidentialité private key : clef privée, clef secrète probabilistic encryption : proxy signature :
chiffrement probabiliste
signature par procuration
public key : clef publique
Lexique anglais-français public-key algorithm : algorithme à clef publique, algorithme à clef révélée quadratic sieve : random noise :
crible quadratique bruit aléatoire, bruit blanc
rate of the language :
taux du langage
receiver: destinataire relativized cryptography :
cryptographie relativisée
restricted algorithm : algorithme restreint reverse engineering:
reconstruction
rotor machine : machine à tambours, machine à rotors sait :
sel, salage
secrecy : confidentialité secret sharing :
partage de secret
secret splitting :
morcellement de secret, répartition de secret
secret-key algorithm : algorithme à clef secrète secure multiparty computation :
calcul réparti sûr
seed : germe self-decimated generator : self-recovering :
générateur auto-cadencé
auto-récupérant
self-shrinking generator :
générateur à auto-réduction
sender : expéditeur, émetteur shrinking generator :
générateur à réduction
simple substitution cipher : chiffre à substitution simple single-key algorithm : algorithme à clef secrète smart card :
carte à puce
stop-and-go generator :
générateur à signal d’arrêt
stream cipher : algorithme de chiffrement en continu strong algorithm : algorithme invulnérable par calcul, algorithme fort strong prime :
nombre premier fort
substitution cipher : chiffre à substitution
Bibliographie superincreasing :
super-croissant
symmetric algorithm : algorithme à clef secrète tap sequence :
séquence de dérivation
threshold generator : threshold scheme : timestamp :
générateur à seuil
schéma à seuil
datation (substantif ), dater (verbe)
timestamping service :
service de datation
total break : cassage complet tractable : trustée:
soluble
dépositaire, fidéicommissaire
uncertainty :
incertitude
unconditionally secure : inconditionnellement sûr, absolument sûr undeniable signature : unicity distance : unicity point :
signature incontestable
distance d’unicité
point d’unicité
work factor : effort working frame :
cadre courant
zero-knowledge proof :
preuve à divulgation nulle
