Du chiffrement aux applications : Principes, standards et mise en œuvre Jean-Luc Parouty Sécurité des Systèmes d'information Jean-Luc.Parouty@ibs.fr www. i b s. f r
2 Sommaire Introduction 1. L'information, entité stratégique 2. Risques 3. Apports du chiffrement 4. Principes algorithmiques 5. Exemples d'algorithmes 6. Sûreté, risques et confiance 7. Problèmatique des clefs 8. Modèle à base de certificats (X509) 9. Infrastructure de gestion de clefs (IGC) 10. SSL 11. HTTPS 12. Tunnels SSL Bibliographie
3 Introduction Conception en clair Evolution des usages (usagers) Démocratisation de l internet, confiance aveugle.. Usages à enjeux (Commerce, etc.) 0 papier (Web, messagerie, etc.) Evolution des enjeux Evolution des risques Nécessitée de sécuriser les échanges Contraintes économique Contraintes légales
4 1. L information, entité stratégique Dans un tel contexte d infocratie, l organisation devient totalement dépendante de son système d information, celui-ci devient une entité stratégique. Celui qui contrôle les/ses informations détient un avantage. On peut distinguer plusieurs types de contrôle: Contrôle actif (celui de l attaquant ): Ex.: Modifier une donnée Contrôle passif (celui du défenseur): Ex.: Vérifier une donnée
5 1.1 Aspects fondamentaux de l information Confidentialité Intégrité Libre accès aux services Éviter les interruptions, les entraves Concept propre aux systèmes/services Habilitation Protection vis-à-vis des modifications Détecter une éventuelle altération frauduleuse ou accidentelle Disponibilité Maintenir le secret d une information Protection lors de la conservation, du transfert ou du calcul d une information Complément indispensable à l authentification Qui peut faire quoi? Gestion des privilèges / Politique de sécurité Authentification Identification forte de l interlocuteur/acteur Qui est là?
6 1.2 Exemple Considérons un pot de confiture, posé en haut d une étagère La grand mère peut : Saisir le pot (disponibilité) Lire l étiquette «confiture de fraise» (non confidentialité) Ouvrir le pot et prendre de la confiture (non intégrité) Les enfants : Ne savent pas lire l étiquette (confidentialité) Ne peuvent pas ouvrir le pot pour en manger (intégrité) Ne peuvent pas atteindre le pot sur l étagère (non disponibilité) Attaque possible : monter sur un tabouret
7 2. Risques Tout système d information voit ses données potentiellement exposées à deux types de risques: L erreur La malveillance Ces risques peuvent concerner l ensemble des aspects fondamentaux de nos données
8 2.1 Risques induits par la technique Les risques sont aggravés par l évolution des techniques. Traitements automatiques Complexité croissantes des systèmes La capacité des outils disponibles permet de traiter automatiquement et rapidement des volumes considérables de données. L interconnexion des systèmes et la faible diversité génétique augmente les risques épidémiques Exemple : CodeRed / IIS
9 2.2 Théorèmes de base Deux règles fondamentales à ne jamais oublier : Au sein d une chaîne, c est toujours l élément le plus fragile qui conditionne la résistance de l ensemble et Si quelque chose peut flancher alors cela surviendra inexorablement, de la pire manière qui soit et au pire moment qui soit (lois de Murphy, ou LEM )
10 2.3 Enjeux, risques et réponses «Sniffer» un réseau via un kit ou exploiter une faille ne demande que peu d efforts http://www.google.com Plus l enjeux sera important, plus les moyens mis en œuvre par les pirates le seront la protection absolue d un système est impossible. Règle des 80-20
11 3. Apports du chiffrement Des techniques permettant de mieux garantir l intégrité, la confidentialité et l authenticité des informations sont recherchées depuis l antiquité. Le chiffrement est aujourd hui la solution la plus efficace et la plus accessible. L intégrité peut être vérifiée avec une simple fonction de hachage. L intégrité et l authenticité peuvent être garanties par l utilisation d une signature électronique. La confidentialité nécessite l utilisation d une fonction de chiffrement. Les garanties reposent sur le fait que les algorithmes utilisés sont réputés comme étant très solides. Un algorithme est réputé solide lorsque les techniques à mettre en oeuvre pour tromper ou résoudre celui-ci sont hors de portée de l attaquant potentiel. Remarque : L habilitation et la disponibilité ne sont pas directement concernés par le chiffrement.
12 3.1 Terminologie Cryptologie : Science des messages secrets. Peut se décomposer en deux disciplines pour ainsi dire complémentaires ;-) : Cryptographie (du grec : caché et. : écrire) Art de transformer un message clair en un message inintelligible par celui qui ne possède pas les clefs de chiffrement Cryptanalyse Art d'analyser un message chiffré afin de le décrypter Tatouage, Stéganographie (du grec : couvert et. : écrire) A l inverse de la cryptographie, on ne va pas chercher à rendre le message inintelligible, mais plutôt à le camoufler dans un support (image, texte, mp3, vidéo, etc.) de manière à masquer sa présence. Exemple : Le terme de tatouage sera utilisé pour une action consistant à camoufler une indication de propriété (images) Le terme de stéganographie sera employé pour décrire une action consistant à transmettre un message à l insu d un observateur Chiffrement Opération consistant à transformer via des fonctions mathématiques et des clefs, un texte initial («en clair») en un ensemble de codes incompréhensibles. Déchiffrement Opération inverse du chiffrement. Obtenir la version originale d'un message qui a été précédemment chiffré en connaissant les fonctions mathématiques et les clefs utilisées lors du chiffrement Décryptement Restauration de données ayant fait l objet d un chiffrement, à leur état premier ("en clair"), sans disposer des clefs théoriquement nécessaires
13 4. Principes 4.1 Fonction de hachage 4.2 Chiffrement à clef symétrique 4.3 Chiffrement à clef publique/privée 4.4 Signature électronique 4.5 Signature et chiffrement 4.6 Chiffrement hybride
14 4.1 Fonction de hachage Fonctions unidirectionnelles MD2, MD4, MD5, SHA, RIPE-MD, HAVAL, etc.
15 4.2 Chiffrement à clef symétrique Algorithmes rapides DES, 3DES, RC2, RC4, IDEA, MMB, AES, etc.
16 4.2 Chiffrement à clef symétrique Comment partager les clés? Un secret partagé en est-il encore un?
17 4.3 Chiffrement à clef publique/privée Ces algorithmes de chiffrement utilisent 2 clefs Un texte chiffré avec l une des clef ne pourra être déchiffré qu avec l autre clef Le principe d utilisation va consister à conserver l une des clefs, qui restera privée, tandis que l autre sera diffusée de manière publique (accessible à tous) Exemple : Seule Alice aura pu chiffrer le message (avec sa clef privé), que Bob à réussi à déchiffrer avec la clef publique d Alice. L authenticité du message et son intégrité sont [donc] supposés valides
18 4.3 Chiffrement à double clefs Inversement, seule Alice pourra déchiffrer (facilement), avec sa clef privée, le message que Bob à chiffré avec la clef publique d Alice. La confidentialité du message de Bob à Alice peut donc être supposée bonne.
19 4.4 Signature électronique Alice veut diffuser un document signé : Une fonction de hachage est appliquée au document (md5, par exemple) Le condensat est chiffré avec sa clef privé, via un algorithme à double clefs (rsa, par exemple) Un nouveau document est constitué, composé du document initial et de la signature
20 4.4 Signature électronique (suite) Bob, va vérifier la signature : La même fonction de hachage est appliquée au document La signature est déchiffrée, via la clef publique d Alice, le condensat initial est retrouvé Les deux condensats sont comparés : Identique : le document d Alice n a probablement pas du être modifié Différents : le document n est certainement pas l original
21 4.5 Signature et chiffrement
22 4.6 Chiffrement hybride Les algorithmes de chiffrement à double clés sont très lents, comparés aux algorithmes symétriques. On va donc utiliser un modèle hybride, où la clef secrète sera seule chiffrée avec l algorithme à clef publique. Le meilleur des deux mondes pour le meilleur et pour le pire, aussi
23 5. Algorithmes 5.1 Chiffrement bit à bits 5.2 Chiffrement par bloc 5.3 Solidité des algorithmes symétriques 5.4 Diffie-Hellman 5.5 RSA 5.6 A propos des nombres premiers
24 5.1 Chiffrement bit à bits Chiffrement idéal, si la clef est au moins aussi longue que le texte à chiffrer Plus lent que les algorithmes à blocs
25 5.2 Chiffrement par bloc Famille d algorithmes les plus usités. Rapide et relativement simples à implémenter ou à fondre DES, 3DES, IDEA, AES, etc.
26 5.2.1 DES / Triple DES L'algorithme DES, Data Encryption Standard, a été créé dans les laboratoires de la firme IBM Corp. Il est devenu le standard du NIST en 1976 et a été adopté par le gouvernement en 1977. C'est un chiffrement qui transforme des blocs de 64 bits avec une clé secrète de 56 bits au moyen de permutations et de substitutions. Le DES est considéré comme étant accessible.
27 5.2.1 DES / Triple DES Le tripledes (3DES) est en fait l'algorithme DES appliqué trois fois sur les données. Il a été conçu par Whitfield Diffie, Martin Hellman et Walt Tuchmann en 1978. L'algorithme utilise une taille de clé comprise entre 128 bits et 192 bits. La taille des blocs est de 8 octets (64 bits). Il y a plusieurs modèles au tripledes pour chiffrer le texte clair. Le tripledes a été approuvé FIPS (Federal Information Processing Standards) par le NIST et donc peut être utilisé par les organisations gouvernementales.
28 5.2.2 Rijndael / AES Rijndael, a symmetric key cypher designed by Joan Daemen and Vincent Rijmen, both of Belgium Selected by NIST as the proposed Advanced Encryption Standard (AES) replacing DES. Rijndael is based on arithmetic in the Galois eld of 28 elements, GF( 28 ).
29 5.2.2 Rijndael / AES «The cipher has a variable block length and key length. We currently specified how to use keys with a length of 128, 192, or 256 bits to encrypt blocks with al length of 128, 192 or 256 bits (all nine combinations of key length and block length are possible). Both block length and key length can be extended very easily to multiples of 32 bits. Rijndael can be implemented very efficiently on a wide range of processors and in hardware.»
30 5.2.3 AES versus DES Quelques chiffres : 128-bits : 3.4 x 1038 clés possibles 192-bits : 6.2 x 1057 clés possibles 256-bits : 1.1 x 1077 clés possibles Soit 1021 fois plus de clés pour l'aes/128 bits que pour le DES (56 bits) En supposant que l'on puisse construire une machine qui pourrait craquer une clé DES en 1 seconde (donc qui puisse calculer 255 clés par seconde), cela prendrait encore 149 mille milliards d'années pour craquer une clé AES
31 5.2.4 Rijndael A propos de Rijndael : http://rijndael.com/ http://www.esat.kuleuven.ac.be/~rijmen/rijndael/index.html http://home.ecn.ab.ca/~jsavard/crypto/co040801.htm
32 5.3 Solidité des algorithmes symétriques Bien que la preuve de l absence de faille d un code soit impossible, il est néanmoins possible de faire des algorithmes sûrs. La manière la plus basique d attaquer un système de cryptage à clés est d essayer toute les combinaisons de clés jusqu à trouver la bonne (brute force). Cette méthode n est cependant guère utilisable que pour les algorithmes symétriques pouvant être câblés: Longueur des clefs Combinaisons Système 32 bits 109 PC 1012 Universités 56 bits Ex: DES 1016 Hard dédié 250.000 64 bits 1019 Hard dédié++ 128 bits Ex: IDEA 1038-256 bits Ex: AES/256 bits 1077-40 bits Ex: RC4-40
33 5.4 Diffie-Hellman Premier algorithme à clef publique, proposé en 1976 Permet de partager une clef symétrique de session Particulièrement intéressant pour dés lors que l on est en mode «connecté»
34 5.4.1 Description Soit n et g, connus de tous : n : «grand nombre premier» g : «primitive mod n» Alice construit Xa et X tel que : Xa : «grand nombre aléatoire» X = gxa mod n Hé hé Bob construit Ya et Y tel que : Ya : «grand nombre aléatoire» Y = gya mod n Hé hé Alice envoie X humpff :-( Y Bob envoie Alice calcule k : k = YXa mod n = (gya)xa mod n = gya.xa Bob calcule k : k = XYa mod n = (gxa)ya mod n = gxa.ya k est désormais un secret partagé par Alice et Bob, et servira de clef de session Chiffrement symétrique avec la clef k
35 5.4.2 Man in the middle attack Soit n et g, connus de tous : n : «grand nombre premier» g : «primitive mod n» Alice construit Xa et X tel que : Xa : «grand nombre aléatoire» X = gxa mod n Hé hé Daniel construit Ya et Y tel que : Ya : «grand nombre aléatoire» Y = gya mod n Il renvoie Y a Alice Daniel construit Xa et X tel que : Xa : «grand nombre aléatoire» X = gxa mod n Il renvoie X a Bob Alice envoie X Niark niark ;-) Daniel envoie Y Alice calcule ka : ka = Y Xa mod n = (gya )Xa mod n = gya.xa ka = XYa mod n = (gxa)ya mod n = gxa.ya kb = YXa mod n = (gya)xa mod n = gya.xa Hé hé Daniel envoie X Bob envoie Y Bob calcule ka et kb ka Bob construit Ya et Y tel que : Ya : «grand nombre aléatoire» Y = gya mod n ka est désormais un secret partagé par Alice et Daniel, kb un secret partagé entre Daniel et Bob Bob calcule k : kb = X Ya mod n = (gxa )Ya mod n = gxa.ya kb
36 5.5 RSA Proposé en 1978 par Ron Rivest, Adi Shamir, and Leonard Adleman. Premier algorithme parfaitement adapté à la signature et au chiffrement. Relativement simple à comprendre et à implémenter. Etudié depuis longtemps, connu et peu être considéré comme robuste. Basé sur la difficulté à factoriser de grands nombres (plusieurs centaines de chiffres)
37 5.5.1 Description Soit : t c Le texte à chiffrer Le texte chiffré p, q Grand nombres premiers n n = pq e Clef de chiffrement, telle que : e relativement premier à (p-1)(q-1) d Clef de déchiffrement, tel que : de 1 mod (p-1)(q-1) Note : Il suffit de trouver un entier x, tel que : d = ( x(p-1)(q-1) + 1 ) / e soit un entier et de prendre la valeur de d Chiffrement : Déchiffrement : c = (t^e) mod pq t = (c^d) mod pq Clef publique : n,e Clef privée : d (et n)
38 5.5.2 Exemple Alice : On prend p=61 et q=53 n=p.q=3233 On prend e=17 note : 3120 mod 17 =9, donc e est premier à (p-1)(q-1) Cherchons : d = ( x(p-1)(q-1) + 1 ) / e Pour x=15, on a d=2753 Clef privée d Alice : d=2753 Clef publique d Alice : n=3233, e=17 Note : Pour vos calculs sur des grands chiffres vous pouvez utiliser «bc» (Linux) ou l Applet suivante
39 5.5.2 Exemple Bob envois un message chiffré à Alice Alice reçoit le cryptogramme Message : t = 65 (lettre A ) Cyptogramme : c = 2790 Chiffrement : c = (te) mod p.q = 6517 mod 3233 = 2790 Déchiffrement : t = cd mod p.q = 27902753 mod 3233 = 65 Envoie de c = 2790 Réception de t = 65 Ma clef privée: d=2753 c=2790 Clef publique d Alice : p.q=3233, e=17
40 6. Sûreté, risques et confiance
41 7. Problèmatique des clefs Système à base de chiffrement symétrique Un tel système nécessitera un très grand nombre de clefs Pour n entités interagissant, il faudra n(n-1)/2 clefs L arrivée d un nouvel acteur impliquera de générer et distribuer n clés supplémentaires Cette gestion des clés est inadaptée sur une échelle importante : les problèmes d administration deviennent rapidement insurmontables.
42 7. Problèmatique des clefs Système utilisant un chiffrement asymétriques Chaque acteur possède un couple de clés. Clé publique Clé privée La clé privée devra toujours rester avec son propriétaire tandis que sa clé publique devra pouvoir être diffusée/accessible. On pourra utiliser pour cela un annuaire publique (par exemple un annuaire LDAP) Un nouvel utilisateur aura uniquement besoin de son couple de clés et de publier sa clé publique dans l annuaire pour pouvoir communiquer avec l ensemble des autres entités.
43 7. Problèmatique des clefs Ce type de système introduit un problème inédit, celui de la publication, en toute confiance, de la clé publique. Cette publication doit offrir l assurance que : la clé obtenue,est bien celle appartenant à la personne avec qui les échanges sont envisagés ; le détenteur de cette clé est «digne de confiance» ; la clé est toujours valide. Cette notion de confiance est résolue avec les certificats et les autorités de certification.
44 8. Modèle à base de certificats (X509) 8.1 Le Certificat 8.2 Construction d un certificat 8.3 Certificat X509 8.4 L Autorité de Certification (AC) 8.5 Arbre de certification 8.6 Formats et standards 8.7 Exemple : Authentification par certificat
45 8.1 Le Certificat C est un document comprenant une clef publique et des informations connexes, signé par une tierce partie, «l autorité de certification». Dans la norme X509, l ISO définit le certificat comme : " la clé publique d un utilisateur, à laquelle est jointe d autres données, rendue infalsifiable à l aide du chiffrement par la clef privée de l autorité de certification qui a généré ce certificat ". La validité de cette signature et la confiance en l autorité de certification sont les principales limites de la confiance accordable aux informations du certificat, et donc à la clef publique contenue.
46 8.2 Construction d un certificat
47 8.3 Certificat X509 Il existe plusieurs formats de certificats Le modèle d authentification de l ISO à définit le format X509 Data Signature Version: Serial Number: Signature Algorithm: Issuer: Version du type de certificat X509 de série au sein du CA (garantie d unicité) Algorithme de signature utilisé Identité de l emetteur (Distinguished Name) de l'autorité de certification qui a émis ce certificat. Validity Not Before: xx Not After : xx Période de validité du certificat, date de début et de fin. Subject: Identité de du propriétaire (Distinguished Name) du certificat Subject Public Key: Public key algorithm : Informations sur la clef publique et paramètres de celle-ci X509v3 extensions: Extension name i: Valeur extension i Extensions optionnelles possibles avec la version X509v3. Signature algorithm: Signature Algorithme de signature Signature
48 8.3 Certificat X509 La norme X509v3 propose un certain nombre d extensions, permettant de spécifier un certain nombre d'informations spécifiques aux différents usages possibles d un certificat. Par exemple : X509v3 Basic Constraint : Indique s'il s'agit du certificat d'une Autorité de Certification ou non, c'est-à-dire permettant d'émettre des certificats. X509v3 Key Usage : Permet de préciser (ie de restreindre) les fonctions disponibles via ce certificat. Libre aux applications d en tenir compte ou non ;-) X509v3 subjectaltname: Noms alternatifs du propriétaire du certificat (alias du «subject») X509v3 issueraltname: Noms alternatifs de l émetteur du certificat (alias du «issuer») X509v3 CRL Distribution Points : URI de la Certificat Revocation List (CRL), permettant de connaître le statut de ce certificat
49 8.3 Certificat X509 Chaque extension peut être qualifiée de critique (ou non) Une extension marquée critical est impérative Une application traitant un certificat dont une extension marquée critical lui est inconnue doit ignorer le certificat. En cas d utilisation, key Usage et Basic Constraint doivent être marqués critical. Remarque : Nous atteignons les limites du modèle où la gestion de l habilitation et de l authentification se mélangent.
50 8.3 Certificat X509 OpenSSL> pkcs7 -inform der -in dt.p7b -print_certs -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 36 (0x24) Signature Algorithm: md5withrsaencryption Issuer: C=DE, O=Deutsche Telekom AG, OU=T-TeleSec Trust Center, CN=Deutsche Telekom Root CA 1 Validity Not Before: Jul 9 11:34:00 1999 GMT Not After : Jul 9 23:59:00 2019 GMT Subject: C=DE, O=Deutsche Telekom AG, OU=T-TeleSec Trust Center, CN=Deutsche Telekom Root CA 1 Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:d0:dd:9b:0c:a0:17:44:44:0f:af:21:40:73:67: 56:f0:3e:69:68:11:ba:d9:37:f2:81:ae:c3:24:ac: 69:a1:cd:fc:a6:18:55:56:ff:8b:9f:32:c1:db:e7: 78:2c:39:db:60:81:41:a5:ef:d3:cd:80:8d:18:3c: e2:52:0c:0b:9f:f7:64:9e:e5:a0:f0:b8:61:62:f4: bf:e0:a3:da:58:2b:fd:15:04:6b:bd:3a:9e:7c:9d: f2:3d:d8:e4:95:c3:ec:4e:c2:f1:65:ab:0c:4b:ec: 47:82:5b:e2:e1:50:75:d8:f6:61:b4:18:5c:ed:33: a0:4b:1e:83:fb:4f:84:bc:79 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 14:31:E2:7F:9C:CA:12:95:FB:F1:70:20:DB:4D:28:13:71:42:61:C6 X509v3 Basic Constraints: CA:TRUE, pathlen:5 X509v3 Key Usage: critical Certificate Sign, CRL Sign Signature Algorithm: md5withrsaencryption 9d:1d:10:fa:93:c8:1d:64:20:45:5e:9c:6f:05:6d:a3:52:7f: a7:a8:87:65:b3:67:9a:36:86:78:72:16:15:ff:d7:45:73:28: 01:86:88:9d:91:ea:de:d6:29:0b:0c:3e:a3:99:74:40:0c:cc: ec:10:e0:64:fc:70:b6:ba:39:12:27:f2:5e:00:50:b5:0b:d6: 4a:df:a9:6f:f4:b3:09:28:80:fc:d2:1e:c4:ec:70:46:85:4c: de:45:b0:01:95:38:ac:16:9f:46:4a:ee:2d:cb:bd:cb:65:b1: 3a:e5:a6:4b:04:4b:0e:33:ff:1c:7b:c8:84:84:47:e1:5a:64: 46:4a OpenSSL>
51 8.4 L Autorité de Certification (AC) Pour être valide, un certificat doit être signé par une Autorité de Certification. L autorité de certification possède ses propre clefs, publique et privée et son propre certificat, qui peut être auto-signé ou délivré par une autre AC. N'importe qui peut se déclarer Autorité de Certification. La confiance en l autorité de certification est essentielle. La compromission de celle-ci équivaut à la compromission de l ensemble des clefs L AC se porte garante de la véracité des informations du certificat quelle délivre. L AC est de fait un tiers de confiance
52 8.5 Chaîne de certification Un CA peut cautionner un autre CA en signant son certificat. Il est ainsi possible de mettre en place des relations de confiance hiérarchiques (ou croisées) entre des CA. Dans le cas d'une relation hiérarchique, un CA «racine» délivre un certificat à un ou plusieurs autres CA, qui pourront, à leur tour délivrer des certificats à d'autres CA et ainsi de suite Pour vérifier la validité d un certificat, il faudra disposer de l ensemble des certificats des CA de la hiérarchie On appelle chaîne de certification, l'ensemble des Certificats nécessaires pour valider la généalogie d'un certificat donné.
53 8.5 Chaîne de certification
54 8.5 Chaîne de certification La confiance accordée à un CA est héritée par toutes les CA fils. Remarque : Faire confiance à un CA racine, revient à faire confiance à l ensemble des CA la même hiérarchie. Il est possible de définir une relation de confiance croisée. Dans ce cas, les deux organismes signent chacun le certificat de l autre.
55 8.6 Formats et standards Afin de permettre les échanges entre les différents acteurs (CA, utilisateurs, etc.) des formats de données ont été définis : PKCS-1 : PKCS-2 : PKCS-3 : PKCS-4 : PKCS-5 : PKCS-6 : PKCS-7 : PKCS-8 : PKCS-9 : PKCS-10 : PKCS-11 : PKCS-12 : PKCS-13 : PKCS-14 : PKCS-15 : RSA Cryptography Specifications Version 2 (RFC 2437) inclus dans PKCS#1 Diffie-Hellman Key Agreement Standard Version 1.4 inclus dans PKCS#1 Password-Based Cryptography Standard Version 2 Extended-Certificate Syntax Standard Version 1.5 Cryptographic Message Syntax Standard Version 1.5 (RFC2315) Private-Key Information Syntax Standard Version 1.2 Selected Attribute Types Version 2.0 Certificate Signing Request (CSR) (RFC 2314) Cryptographic Token Interface Standard Version 2.10 Personnal Information Exchange Syntax Standard Version 1.0 Elliptic Curve Cryptography Standard Version 1.0 Pseudorandom Number Generation Standard Version 1.0 Cryptographic Token Information Format Standard Version 1.1
56 8.7 Encodage L encodage des certificats X509 ainsi que ces différents types de données utilisent un encodage appelé DER (Distinguished Encoding Rules) qui est un sous-ensemble de l'encodage BER (Basic Encoding Rules). Le format DER n est pas compatible avec les applications «textes», telle que la messagerie (encodage binaire). Le format PEM (Privacy Enhanced Mail) permet de rés oudre le problème, en utilisant l'encodage base 64.
57 8.7 Exemple : Authentification
58 8.7 Exemple : Authentification
59 9. Infrastructure de gestion de clefs (IGC) 9.1 L Autorité d Enregistrement 9.2 L Opérateur de Certification 9.3 Service de publication 9.4 Service de Validation 9.5 Service de Séquestre 9.6 Politique de certification 9.7 Gestion des clés privées 9.8 Scénario type de demande de certificat
60 9. Infrastructure de Gestion de clés (IGC) Un certificat peut être comparé à une carte d'identité. Dans le cas d'une carte d'identité, la personne fera sa demande à la mairie de sa commune, qui procédera à la vérification des informations fournies. La demande est alors transmise à la préfecture qui procédera à l'émission de la carte d'identité. Dans le cas des certificats électroniques, le CA peut être comparé à la préfecture (représentant l état) qui assume la responsabilité des pièces d'identité qu'elle délivre. L'ensemble des procédures (demande, contrôle, émission, ) permettant de gérer les cartes d'identité devra donc être présente pour la gestion des certificats électroniques. Elles sont mises en œuvre à travers une infrastructure qui est l IGC. Terminologie : 3 termes pour une même chose : «Infrastructure à Clés Publiques» (ICP) «Public Key Infrastructure» (PKI) «Infrastructure de Gestion de Clefs» (IGC)
61 9. Infrastructure de Gestion de clés (IGC) L IGC est constituée de l'ensemble des matériels, logiciels, personnes, règles et procédures nécessaire à une Autorité de Certification pour créer, gérer et distribuer des certificats X509. «Une IGC est donc une structure à la fois technique et administrative permettant une mise en place, lors de l échange de clef, de relations de confiance entre des entités morales et/ou physiques et/ou logiques.» Les fonctions principales d'une IGC sont : Émettre et révoquer des certificats Diffuser/publier les certificats (annuaire) Éventuellement, fournir un service de séquestre et de recouvrement des clés privées
62 9. Infrastructure de Gestion de clés (IGC) Une IGC est constituée de : Une autorité de certification (AC) Une autorité d'enregistrement (AE) Un opérateur de certification (OC) Un service de diffusion des certificats Un service de validation Un service de séquestre de clés (option)
63 9.1 L Autorité d Enregistrement L AE est le «guichet» des demandes concernant les certificats Elle a pour tâche principale de recevoir et de traiter les demandes de : Création Renouvellement Révocation Pour cela, elle doit : Assurer le contrôle des données identifiant le demandeur de certificat, Valider les demandes de révocation, Assurer le bon recouvrement des certificats lors des renouvellement L'AE propose en général 2 types de services : Des service tournés vers les utilisateurs, permettant à ces derniers de faire leurs demandes de certificats. Un service de gestion, réservés aux opérateurs de l'ae, leur permettant de traiter les demandes.
64 9.2 L Opérateur de Certification L'Autorité de Certification délègue à l'opérateur de Certification toutes les opérations nécessitant la clé privée du CA : création et distribution sécurisée des certificats, révocation, etc. L'OC gère en collaboration avec l autorité d enregistrement le cycles de vie des certificats (renouvellement, etc.) Pour des raisons de sécurité, l'opérateur de Certification n'est en général pas connecté au réseau. En effet la compromission de la clef privée de l'ac étant le risque majeur dans une IGC, tout doit être fait pour l'éviter. Cela entraîne en particulier que le transfert des requêtes entre l'ae et l'oc n'est pas automatique. En outre, la sécurisation physique de l'oc doit également être étudié avec soin.
65 9.3 Service de publication Les certificats issus dune IGC doivent être accessibles à tous ceux qui en ont besoin Pour cela, les certificats sont publiés dans un annuaire librement accessible (en lecture ;-) Cet annuaire peux également contenir le certificat de l'ac et les listes de révocations (CRL) Des annuaires LDAP sont généralement utilisés pour cette fonction.
66 9.4 Service de Validation Il est parfois souhaitable d invalider un certificat : perte ou vol de la clé privée associée fin de mandat du propriétaire Expiration, etc. Le cas de la péremption est déjà résolu par l intégration au sein même du certificat de la date d expiration (validity). Dans les autres cas, l IGC doit procéder à la révocation des certificats concernés. Tout utilisateur d un certificat doit donc avoir la possibilité de vérifier que ce certificat est valide à un instant donné. Un service de validation doit ainsi être mis à disposition par toute IGC.
67 9.4 Service de Validation La méthode la plus utilisée à ce jour consiste à publier une «liste noire» des certificats révoqués : la Certificate Revocation List, (CRL). Une CRL a un format standardisé et comporte la liste des numéros de série des certificats révoqués. Elle est signée par le CA. Pour des raisons de performances, il est possible de la scinder en plusieurs sous-listes. Sa diffusion peut se faire par l annuaire du service de publication ou tout autre moyen. Elle peut être référencée au sein de chaque certificat émis (extension X509v3)
68 9.4 Service de Validation La technique des CRL est mal adaptée : Lourdeur en cas de listes importantes Délais de diffusion Le délais de révocation effectif d un certificat peut être une contrainte de sécurité critique. Pour combler ces limitations, un nouveau protocole est proposé : OCSP. Tout client OCSP pourra vérifier la validité d un certificat donné en interrogeant un serveur OCSP. Cela devrait permettre une diffusion quasi instantanée dés l annonces de révocation.
69 9.5 Service de Séquestre La perte d une clef peut avoir un coût important : Perte de la capacité de signature L émission d une nouvelle clef permet de retrouver la capacité de signature. Mis à part, le temps de certification et de propagation du nouveau certificat, le coût est raisonnable. Perte de la capacité de déchiffrement Toute donnée chiffrée via la clef publique sera réputée perdu Le coût de la perte devient extrême (d autant que ne seront probablement chiffrée que les choses essentielles ) Le séquestre des clefs va consister à archiver au sein de l IGC, les couples de clefs publiques/privées. Hormis le problème de sécurité supplémentaire que cela induit, il est à noter que le séquestre de la clef privée retirera toute valeur légale à la signature associée. Légalement, la clef privée ne peut être partagée.
70 9.6 Politique de certification La sécurité d un site ou d un système ne peut se mettre en place que par le biais d une politique de sécurité, préalablement définie. La mise en place d une IGC nécessite une «définition de politiques de certification» : «un ensemble de règles indiquant, ce pour quoi le certificat est applicable et par qui, et quelles sont les conditions de leur mise en oeuvre au sens juridique, administratif et technique». La règle de base étant avant tout que les certificats et les moyens de mise en oeuvre soient définis en fonction de l utilisation que l on veut en faire. Note : Ces éléments sont extraits du tutorial «Certificats X509 et Infrastructure de Gestion de Clés» JRES 2001 - CNRS/UREC CRU
71 9.6 Politique de certification Les facteurs principaux à prendre en compte sont : Étude de la population/des utilisateurs à qui est destiné le certificat en tenant compte à la fois des caractéristiques des utilisateurs, de l utilisation qui sera faite du certificat (signature, chiffrement entre entités morales et/ou physiques, accès à des applications sécurisées) et de la mise en place des critères d attribution. Étude des moyens de collecte des informations, de leur validation et de la création des certificats. Définition de la durée de vie des clefs (privée, publique et/ou de session), des certificats, de la consolidation de ceux-ci, de la gestion des listes de révocations. Étude des moyens de distribution des certificats via des communications sécurisées de type «VPN» ou sur un support style «carte de crédit» avec récupération en main propre ou par un agent de sécurité sur site. Sécurité des IGC au sens implantation physique, et sécurité des annuaires supports des informations publiques en tenant compte de l infrastructure, de l administration et du coût de gestion.
72 9.6 Politique de certification Les facteurs principaux à prendre en compte sont (suite) : Définition des services nécessitant une haute disponibilité (exemple : gestion des listes de révocation). Prise en compte de la nécessité d un recouvrement des clefs privées et de l interaction avec l autorité suprême et/ou avec d autres communautés (interopérabilité pour certifications croisées). Étude du support matériel/logiciel du certificat chez l utilisateur en tenant compte de la vétusté des postes de travail et en prévoyant des évolutions aisées. Prise en compte de l impact sur les structures existantes : physiques et organisationnelles. Définition de la formation/information des acteurs.
73 9.6 Politique de certification La Déclaration des Pratiques de Certification (DPC) a pour but de décrire les détails des processus techniques mise en oeuvre au sein des différentes composantes de l'igc (CA, RA,...), conformément à la Politique de Certification. En résumé : la Politique de Certification (PC) spécifie des objectifs de sécurité qu'il est nécessaire d'atteindre pour la sécurisation de l'application utilisatrice des services de l'igc la Déclaration des Pratiques de Certification (DPC) spécifie les moyens mises en oeuvre pour atteindre ces objectifs. Les politiques de certifications peuvent permettre d'établir des normes communes d interopérabilité et des critères d assurance communs entre plusieurs organismes.
74 9.7 Gestion des clés privées La gestion d une clef privée incombe à son propriétaire. De son comportement dépendra toute la confiance que l on pourra faire à l IGC. Plusieurs espaces de stockages peuvent êtres envisagés : Disque dur Carte à puce Token, etc. Un effort tout particulier doit être fait dans la formation et la responsabilisation des détenteurs de certificats ainsi que dans le choix du support.
75 9.8 Scénario type de demande de certificat
76 10. SSL 10.1 Introduction 10.2 Présentation de SSL 10.3 Fonctionnalités 10.4 Protocole SSL
77 10.1 Introduction La sécurisation des échanges peut se faire à plusieurs niveaux : IP, via IPSec Toutes les applications reposant sur IP profitent de la sécurisation des couches basses. Cela implique néanmoins une refonte de l infrastructure IP, et la granularité d IPSec n est pas l utilisateur final (si l on considère la connectivité réseau comme une ressource système et non utilisateur, auquel cas d un point de vue applicatif, IPSec n est pas suffisant). Applicatif : Au dessus de TCP/IP Implique de repenser l application et son protocole. L impact est nul pour les autres applications. Le travail est à refaire pour chaque application La granularité est intrinsèquement l application, soit l utilisateur.
78 10.2 Présentation de SSL Défini par par Netscape et intégré au browser Expérimentation interne Diffusé en 1994, dans sa version 2 Version actuelle : v3 Supporte les certificats X509 Standard à l IETF au sein du groupe Transport Layer Security (TLS) SSLv3 TLSv1 (RFC 2246)
79 10.3 Fonctionnalités SSL peut proposer plusieurs modes de fonctionnement : Confidentialité des échanges : Seul le serveur dispose d un certificat et la certification n est pas vérifiée par le client (CA inconnu). Dans ce mode, la communication entre le serveur et le client peut néanmoins être chiffrée, mais il n y a pas d authentification possible des parties en présences. Confidentialité des échanges et authentification du serveur : Seul le serveur dispose d un certificat,reconnu par le client (CA connu) et le certificat est établi au nom du serveur. La communication est alors chiffrée et le client peut authentifier le serveur avec lequel il communique. Chiffrement et authentification mutuelle : Le serveur et le client disposent l un et l autre d un certificat, dûment vérifiés. La communication est chiffrée et une authentification mutuelle du serveur et du client est possible. Remarque : L information d authentification SSL n est pas toujours intégrée par l application et une authentification traditionnelle peut parfois être utilisée en plus. portages Version(cas 1.08 des Jean-Luc Parouty sauvages)
80 10.4 Protocole SSL A l issu d une phase de négociation (Handshake) le client et le serveur disposeront d une clef secrète à usage unique qui sera utilisée pour le chiffrement symétrique de la session. Durant cette «poignée de main», les parties peuvent s authentifier. L intégrité des échanges est garantie par l emplois d une fonction de hachage. Le choix des algorithme ainsi que les longueurs de clefs sont négociables. La clef secrète symétrique sera périodiquement renouvellée.
CLIENT Client Hello - version du protocole SSL ; - nombre aléatoire : client_random ; - identificateur de session : session_id ; - algorithmes de chiffrements choisies par le client ; - algorithmes de compression choisies par le client. Server Hello - version du protocole SSL - nombre aléatoire : serveur_random - identificateur de session : session_id - un algorithme de chiffrement - un algorithme de compression.. Server Certificate - Certificat du serveur - Chaîne de certification SERVER 81 10.4 Protocole SSL (Handshake) Certificate Request (optionnel) Demande du certificat client (optionnel) Server Hello Done Fin de la session Hello du serveur
Client Hello Server Hello Server Certificate Certificate Request (optionnel) CLIENT Server Hello Done Client Certificate (si requis) - Certificat du client - Chaîne de certification Client Key Exchange - PreMasterSecret chiffré à l aide de la clé publique du serveur. Certificate Verify (optionnel) -message chiffré avec la clef privé du client «c est bien moi» SERVER 82 10.4 Protocole SSL (Handshake) Change Cipher Spec Signale le changement des paramètres de sécurité Lesquels deviennent effectifs Finished Fin du HandShake Début des échanges chiffrés avec les nouveaux paramètres négociés
Client Hello Server Hello Server Certificate Certificate Request (optionnel) CLIENT Server Hello Done Client Certificate (si requis) Client Key Exchange Certificate Verify (optionnel) Change Cipher Spec SERVER 83 10.4 Protocole SSL (Handshake) Finished Change Cipher Spec Signale le changement des paramètres de sécurité Lesquels deviennent effectifs Finished Fin du HandShake Début des échanges chiffrés avec les nouveaux paramètres négociés
84 10.4 protocolle SSL SSL offre un service de session Il est possible de reprendre une session, même en cas de rupture TCP : le client envoie un «Client Hello» en utilisant le session_id. Si le serveur trouve cet identificateur dans son cache des sessions, il retourne un «Server Hello» avec le même identificateur de session, puis restaure en interne les propriétés de cette session (en particulier la clef de chiffrement symétrique commune aux deux parties). Il peut aussi forcer une nouvelle négociation SSL handshake en utilisant un nouvel identificateur. Les données sont découpées en Record lesquels sont accompagnés d un condensa et chiffrés.
85 11. HTTPS Utilisation la plus populaire de SSL Beaucoup d informations transitent par HTTP HTTP possède son propre système d authentification, basé sur des mots de passe HTTPS permettra de protéger tout le contenu HTTP : Documents à destinations des browsers URLs des documents Données des formulaires Cookies Login/Password du protocole http. L authentification SSL dispense : L utilisateur d utiliser des mots de passes Le développeur de gérer une mécanique d authentification complexe et potentiellement non sûr L exploitant du système de gérer des login/mot de passe
86 11.1 A propos du serveur APACHE Apache est le serveur le plus populaire du moment Disponible sous Windows et la plupart des Unix (Linux) Structure modulaire Version 2.x Intègre désormais le module SSL en standard Très bien documenté (mieux que OpenSSL)
87 11.2 Configuration Principales directives concernant le certificat du serveur : SSLCertificateFile Certificat du serveur SSLCertificateKeyFile Clés privée du serveur SSLPassPhraseDialog Mode de soumission de la passphrase pour accéder à la clé privée. Si la clé privée est protégée par une passphrase, celle-ci devra être saisie manuellement lors de chaque redémarrage du serveur. Il est possible de spécifier un programme qui se substituera au mécanisme standard d Apache. Pour cela, il lui suffit d écrire dans stdout, la passphrase. L absence de passphrase est également une solution
88 11.2 Configuration Principales directives concernant les certificats : SSLVerifyDepth Longueur maximum de la chaîne de certification du client. SSLCACertificateFile Certificats des CA reconnus pour la vérification des certificats clients. C est une simple concaténation dans un fichier au format PEM SSLCACertificatePath Certificats des CA reconnus pour la vérification des certificats clients. Chaque certificat est dans un fichier «.crt» indépendant. Ils doivent être installés avec un Makefile distribué avec Apache. L idée étant de pouvoir accéder directement à un certificat depuis le DN de l autorité de certification via un jeu de liens. (le Makefile se trouve dans le répertoire par défaut de SSLCACertificatePath).
89 11.2 Configuration Principales directives concernant les certificats (suite) : SSLCACertificateChainFile Chaîne de certification. Lors du «Handshake»SSL, le serveur envoie au client son certificat serveur, accompagné de la chaîne de certification (ie: la liste des certificats de chaque autorité de certification depuis l autorité racine jusqu à l autorité ayant émis le certificat serveur). SSLCARevocationFile Liste des certificats révoqués. C est une simple concaténation au format PEM des CRL SSLCARevocationPath Liste des certificats révoqués Chaque CRL est dans un fichier indépendant, installé via le Makefile (cf SSLCACertificatePath)
90 11.2 Configuration Directive de gestion du cache de session Afin de ne pas relancer une renégociation complète lors de chaque requête, Apache peut utiliser un cache de session. SSLSessionCache Méthode utilisée pour le partage du cache entre les différents processus. Exemple : SSLSessionCache dbm:logs/ssl_scache SSLSessionCacheTimeout Durée de conservation des informations dans le cache, en secondes. Si un client tente de reprendre une session inactive depuis cette durée, le serveur forcera la renégociation SSL. La valeur par défaut est de 300 secondes. SSLMutex Sémaphore pour l accès au cache. Exemple : SSLMutex file:/var/log/ssl_mutex
91 11.2 Configuration Directive concernant le Chiffrement SSLEngine Mise en route du chiffrement (on) Exemple : SSLEngine on SSLCipherSuite Liste des algorithmes de chiffrement négociables par le serveur. Il est notamment possible de spécifier un chiffrement null (debugging)
92 11.3 VirtualHosts SSL Le client vérifie qu il y a bien cohérence entre le nom du serveur interrogé et le CommonName du certificat. Chaque serveur virtuel doit donc posséder son propre certificat. La session SSL étant négociée avant la session HTTP, il est impossible au serveur de choisir le bon certificat, l entête HTTP n étant pas encore vue. Différents serveurs virtuels HTTPS ne pourront donc cohabiter qu en utilisant différents numéros de ports (adresses IP) En général, on définit un serveur virtuel, sur le port par défaut HTTPS (443). Les directives Listen et VirtualHost doivent alors le mentionner.
93 11.4 Contrôle d accès Vérification du certificat client obligatoire : SSLVerifyClient require Ne pourront accéder à la partie concernée du serveur, que les clients présentant un certificat valide : Certificat client émis par un CA reconnu par le serveur cf. directive SSLCACertificate Chaîne de certification de taille correcte cf. directive SSLVerifyDepth Certificat non révoqué cf. directive SSLCARevocationPath
94 11.4 Contrôle d accès Filtrage des certificats valides SSLRequire <expression> L expression spécifiée doit être vérifiée pour que l accès soit autorisé. Cette expression peut s appliquer sur un ensemble de variables héritée de la session SSL Exemple : SSLRequire (%{SSL_CLIENT_S_DN_O} eq "IETF" ) \ and %{REMOTE_ADDR} =~ m/^160\.120\.54\.[0-9]+$/ ) Cela implique des conventions de nomage communes à l ensemble des CA et risque d induire un mélange des genres entre l authentification et l habilitation.
95 11.4 Contrôle d accès Accès nominatif On va spécifier dans un fichier la liste des identifiants (Distinguish Name) des personnes autorisées. Cette méthode est une adaptation de la restriction d accès classique par login/mot de passe Exemple de configuration Dans la section à protéger : SSLVerifyClient require SSLOptions +FakeBasicAuth SSLRequireSSL AuthName "Authentification individuelle requise" AuthType Basic AuthUserFile /usr/local/apache/conf/htpasswd require valid-user # Authentification client requise # Translation «dn en login» # Nom du fichier contenant les dn # autorisés Le fichier htpasswd, contenant les dn autorisés : /C=FR/O=INRIA/CN=Alice Dupont:xxj31ZMTZzkVA /C=FR/O=CNRS/OU=UREC/CN=Bob Watson/EMAIL=bob.watson@urec.cnrs.fr:xxj31ZMTZzkVA /C=FR/O=INRIA/OU=INRIALPES/CN=hab-serv:xxj31ZMTZzkVA Remarque : Pour une question de syntaxe, le mot de passe «xxj31zmtzzkva» doit être respecté, même s il est dénié de sens C est en fait la chaîne «password» chiffrée via crypt cf. perl -e 'print crypt("password","xx"), "\n";' ).
96 11.5 CGI L utilisation de certificats utilisateurs est un plus considérable pour la réalisation d applications cotés serveur. Il est possible pour le cgi de récupérer directement et de manière transparente l ensemble des paramètres d authentification. La vérification du certificat est opérée par le serveur Le serveur peut propager facilement les information du certificat vers le cgi, grâce à la directive : SSLOption +StdEnvVars L application est totalement déchargée de la tâche d authentification (exit, les mots de passe, etc.)
97 Bibliographie Quelques grandes références L incontournable du chiffrement, le «Schneier» : «Applied Cryptography, 2nd edition» Bruce Schneier (Wiley) Unité Réseau du CNRS (UREC) http://www.urec.cnrs.fr OpenSSL : http://www.openssl.org http://www.shininglightpro.com (version win32) Les standards : http://www.ietf.org
98 Bibliographie et aussi : PKIX Working Group http://www.imc.org/ietf-pkix/index.html PKI Forum http://www.pkiforum.org/ The Open source PKI Book http://ospkibook.sourceforge.net/docs/ospki-2.4.6/ospki/ospki-book.htm The PKI Page http://www.pki-page.org/ Serveur de RSA http://www.rsasecurity.com The SSL Protocol http://home.netscape.com/eng/ssl3/ssl-toc.html http://developer.netscape.com/tech/security/ssl/howitworks.html Serveur DCSSI http://www.scssi.gouv.fr/ Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure http://www.counterpane.com/pki-risks.html
99 Bibliographie et pour finir (à compléter) Un site francophone intéressant http://www.uqtr.ca/~delisle/crypto
100 Epilogue Quelques Implementations MD5, 8 lignes #!/usr/bin/perl -ih9t4c`>_-jxf8nms^$#)4=@<,$18%"0x4!`l0%p8*#q4``04``04#!p`` @A=unpack N4C24,unpack u,$^i;@k=map{int abs 2**32*sin$_}1..64;sub L{($x=pop) <<($n=pop) 2**$n-1&$x>>32-$n}sub M{($x=pop)-($m=1+~0)*int$x/$m}do{$l+=$r=read STDIN,$_,64;$r++,$_.="\x80"if$r<64&&!$p++;@W=unpack V16,$_."\0"x7;$W[14]=$l*8 if$r<57;($a,$b,$c,$d)=@a;for(0..63){$a=m$b+l$a[4+4*($_>>4)+$_%4],m&{(sub{$b&$c $d&~$b},sub{$b&$d $c&~$d},sub{$b^$c^$d},sub{$c^($b ~$d)})[$z=$_/16]}+$w[($a[ 20+$z]+$A[24+$z]*($_%16))%16]+$K[$_]+$a;($a,$b,$c,$d)=($d,$a,$b,$c)}$v=a;for( @A[0..3]){$_=M$_+${$v++}}}while$r>56;print unpack(h32,pack V4,@A),"\n«SHA, 8 lignes #!/usr/bin/perl -id9t4c`>_-jxf8nms^$#)4=l/2x?!:@gf9;mgkh8\;o-s*8l'6 @A=unpack"N*",unpack u,$^i;@k=splice@a,5,4;sub M{($x=pop)-($m=1+~0)*int$x/$m}; sub L{$n=pop;($x=pop)<<$n 2**$n-1&$x>>32-$n}@F=(sub{$b&($c^$d)^$d},$S=sub{$b^$c ^$d},sub{($b $c)&$d $b&$c},$s);do{$l+=$r=read STDIN,$_,64;$r++,$_.="\x80"if$r< 64&&!$p++;@W=unpack N16,$_."\0"x7;$W[15]=$l*8 if$r<57;for(16..79){push@w,l$w[$_ -3]^$W[$_-8]^$W[$_-14]^$W[$_-16],1}($a,$b,$c,$d,$e)=@A;for(0..79){$t=M&{$F[$_/ 20]}+$e+$W[$_]+$K[$_/20]+L$a,5;$e=$d;$d=$c;$c=L$b,30;$b=$a;$a=$t}$v='a';@A=map{ M$_+${$v++}}@A}while$r>56;printf'%.8x'x5."\n",@A
101 Epilogue Quelques Implementations Diffie-Hellman, en C #include <stdio.h> /* Usage: dh base exponent modulus */ typedef unsigned char u;u m[1024],g[1024],e[1024],b[1024];int n,v,d,z,s=129;a( u *x,u *y,int o){d=0;for(v=s;v--;){d+=x[v]+y[v]*o;x[v]=d;d=d>>8;}}s(u *x){for( v=0;(v<s-1)&&(x[v]==m[v]);)v++;if(x[v]>=m[v])a(x,m,-1);}r(u *x){d=0;for(v=0;v< S;){d =x[v];x[v++]=d/2;d=(d&1)<<8;}}m(u *x,u *y){u X[1024],Y[1024];bcopy(x,X,S );bcopy(y,y,s);bzero(x,s);for(z=s*8;z--;){if(x[s-1]&1){a(x,y,1);s(x);}r(x);a(y,y,1);s(y);}}h(char *x,u *y){bzero(y,s);for(n=0;x[n]>0;n++){for(z=4;z--;)a(y,y,1);x[n] =32;y[S-1] =x[n]-48-(x[n]>96)*39;}}p(u *x){for(n=0;!x[n];)n++;for(;n< S;n++)printf("%c%c",48+x[n]/16+(x[n]>159)*7,48+(x[n]&15)+7*((x[n]&15)>9)); printf("\n");}main(int c,char **v){h(v[1],g);h(v[2],e);h(v[3],m);bzero(b,s);b[ S-1]=1;for(n=S*8;n--;){if(e[S-1]&1)M(b,g);M(g,g);r(e);}p(b);} Diffie-Hellman, en perl #!/usr/bin/perl -- -export-a-crypto-system-sig Diffie-Hellman-2-lines ($g,$e,$m)=@argv,$m die"$0 gen exp mod\n";print`echo "16dio1[d2%Sa2/d0<X+d *La1=z\U$m%0]SX$e"[$g*]\EszlXx+p dc`
102 Epilogue Quelques Implementations Génération de clés RSA, en perl #!/usr/bin/perl $k=768;$e=sprintf'%x',65537;print"please enter a LOT of random junk.\n" ;$a=<stdin>;print"working. This may take a while.\n";for(1..(length($a)1)){$b[$_&31]^=unpack('c',substr($a,$_,1));$b[$_&31]=(($b[$_&31]<<5) ($b [$_&31]>>3))&255;}for(0..255){$c[$_]=$_;}$a=$d=$f=0;for(0..255){$a=($a+ $c[$_]+$b[$a&31])&255;($c[$_],$c[$a])=($c[$a],$c[$_]);}open(f,' dc'); select F;print"16dio[$e+]sa";for(1..50){for(1..$k/32){printf'%02X',&g;} print"sr";}for(1,2){printf'%02x',&g 128;for(2..$k/16){printf'%02X',&g;} print"d$e%-2+d2%0=asp";}print"[d2%sa2/d0<x+d*la1=zlp%0]sx[lr*]sz[1+q]sq[ la1+sa0sc]sa[laxlb1+sb]sb[ld1+sdlrddsssr1lp1-2/lxx+1+lp%99scd0=a2=bclcla +32>C]sC[LsSrld1-dsd0<D]sD[le1+se0ddsasbsdlCxlDxlP2 $e*+splc99=elb32=elp 2 $e*-led1>qq]se_1selexsq_1selplexsp[p=]plpp[q=]plqp[n=]p*p[e=]p$e p1-lp 1-lq1-**1+$e/[d=]Pp\n";close(F);sub g{$d=($d+1)&255;$f=($f+$c[$d])&255;( $c[$d],$c[$f])=($c[$f],$c[$d]);return($c[($c[$d]+$c[$f])&255]);} Chiffrement RSA, en perl #!/usr/bin/perl -sp0777i<x+d*lmla^*ln%0]dsxx++lmln/dsm0<j]dsj $/=unpack('h*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lk[d2%sa2/d0$^ixp" dc`;s/\w//g;$_=pack('h*',/((..)*)$/)