IBS. Du chiffrement aux applications : Sécurité des Systèmes d'information. Principes, standards et mise en œuvre. Jean-Luc Parouty. www. i b s.
|
|
- Nathalie Dumas
- il y a 8 ans
- Total affichages :
Transcription
1 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 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 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 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 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 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 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 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 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 Enjeux, risques et réponses «Sniffer» un réseau via un kit ou exploiter une faille ne demande que peu d efforts 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 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 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 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 Fonction de hachage Fonctions unidirectionnelles MD2, MD4, MD5, SHA, RIPE-MD, HAVAL, etc.
15 Chiffrement à clef symétrique Algorithmes rapides DES, 3DES, RC2, RC4, IDEA, MMB, AES, etc.
16 Chiffrement à clef symétrique Comment partager les clés? Un secret partagé en est-il encore un?
17 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 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 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 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 Signature et chiffrement
22 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 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 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 Chiffrement par bloc Famille d algorithmes les plus usités. Rapide et relativement simples à implémenter ou à fondre DES, 3DES, IDEA, AES, etc.
26 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 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 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 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 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 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 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 Rijndael A propos de Rijndael :
32 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é bits 1019 Hard dédié bits Ex: IDEA bits Ex: AES/256 bits bits Ex: RC4-40
33 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 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 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 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 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 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 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 = 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 40 6. Sûreté, risques et confiance
41 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 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 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 44 8. Modèle à base de certificats (X509) 8.1 Le Certificat 8.2 Construction d un certificat 8.3 Certificat X L Autorité de Certification (AC) 8.5 Arbre de certification 8.6 Formats et standards 8.7 Exemple : Authentification par certificat
45 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 Construction d un certificat
47 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 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 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 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: GMT Not After : Jul 9 23:59: 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: (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 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 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 Chaîne de certification
54 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 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 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 Exemple : Authentification
58 Exemple : Authentification
59 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 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 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 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 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 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 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 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 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 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 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 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 CNRS/UREC CRU
71 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 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 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 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 Scénario type de demande de certificat
76 SSL 10.1 Introduction 10.2 Présentation de SSL 10.3 Fonctionnalités 10.4 Protocole SSL
77 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 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 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 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.
81 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 Protocole SSL (Handshake) Certificate Request (optionnel) Demande du certificat client (optionnel) Server Hello Done Fin de la session Hello du serveur
82 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 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
83 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 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 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 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 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 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 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 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 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 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 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 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 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 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/ =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 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 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) OpenSSL : (version win32) Les standards :
98 98 Bibliographie et aussi : PKIX Working Group PKI Forum The Open source PKI Book The PKI Page Serveur de RSA The SSL Protocol Serveur DCSSI Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure
99 99 Bibliographie et pour finir (à compléter) Un site francophone intéressant
100 100 Epilogue Quelques Implementations MD5, 8 lignes #!/usr/bin/perl 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[ unpack(h32,pack V4,@A),"\n«SHA, 8 lignes #!/usr/bin/perl 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 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 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*',/((..)*)$/)
Certificats X509 & Infrastructure de Gestion de Clés. Claude Gross CNRS/UREC
Certificats X509 & Infrastructure de Gestion de Clés Claude Gross CNRS/UREC 1 Confiance et Internet Comment établir une relation de confiance indispensable à la réalisation de transaction à distance entre
Plus en détailAristote Groupe PIN. Utilisations pratiques de la cryptographie. Frédéric Pailler (CNES) 13 janvier 2009
Aristote Groupe PIN Utilisations pratiques de la cryptographie Frédéric Pailler (CNES) 13 janvier 2009 Objectifs Décrire les techniques de cryptographie les plus courantes Et les applications qui les utilisent
Plus en détailSommaire Introduction Les bases de la cryptographie Introduction aux concepts d infrastructure à clés publiques Conclusions Références
Sommaire Introduction Les bases de la cryptographie Introduction aux concepts d infrastructure à clés publiques Conclusions Références 2 http://securit.free.fr Introduction aux concepts de PKI Page 1/20
Plus en détailCertificats (électroniques) : Pourquoi? Comment? CA CNRS-Test et CNRS
Certificats (électroniques) : Pourquoi? Comment? CA CNRS-Test et CNRS Nicole Dausque CNRS/UREC CNRS/UREC IN2P3 Cargèse 23-27/07/2001 http://www.urec.cnrs.fr/securite/articles/certificats.kezako.pdf http://www.urec.cnrs.fr/securite/articles/pc.cnrs.pdf
Plus en détailChapitre 7. Sécurité des réseaux. Services, attaques et mécanismes cryptographiques. Hdhili M.H. Cours Administration et sécurité des réseaux
Chapitre 7 Sécurité des réseaux Services, attaques et mécanismes cryptographiques Hdhili M.H Cours Administration et sécurité des réseaux 1 Partie 1: Introduction à la sécurité des réseaux Hdhili M.H Cours
Plus en détailCryptologie. Algorithmes à clé publique. Jean-Marc Robert. Génie logiciel et des TI
Cryptologie Algorithmes à clé publique Jean-Marc Robert Génie logiciel et des TI Plan de la présentation Introduction Cryptographie à clé publique Les principes essentiels La signature électronique Infrastructures
Plus en détailArchitectures PKI. Sébastien VARRETTE
Université du Luxembourg - Laboratoire LACS, LUXEMBOURG CNRS/INPG/INRIA/UJF - Laboratoire LIG-IMAG Sebastien.Varrette@imag.fr http://www-id.imag.fr/~svarrett/ Cours Cryptographie & Securité Réseau Master
Plus en détailCours 14. Crypto. 2004, Marc-André Léger
Cours 14 Crypto Cryptographie Définition Science du chiffrement Meilleur moyen de protéger une information = la rendre illisible ou incompréhensible Bases Une clé = chaîne de nombres binaires (0 et 1)
Plus en détailUtilisation des certificats X.509v3
En pratique Utilisation des certificats X.509v3 Commerce électronique, avec HTTPS (HTTP/SSL) Authentification SSL/TLS par certificat, obligatoire pour le serveur Authentification optionnelle pour le client
Plus en détailI.1. Chiffrement I.1.1 Chiffrement symétrique I.1.2 Chiffrement asymétrique I.2 La signature numérique I.2.1 Les fonctions de hachage I.2.
DTIC@Alg 2012 16 et 17 mai 2012, CERIST, Alger, Algérie Aspects techniques et juridiques de la signature électronique et de la certification électronique Mohammed Ouamrane, Idir Rassoul Laboratoire de
Plus en détailSSL ET IPSEC. Licence Pro ATC Amel Guetat
SSL ET IPSEC Licence Pro ATC Amel Guetat LES APPLICATIONS DU CHIFFREMENT Le protocole SSL (Secure Socket Layer) La sécurité réseau avec IPSec (IP Security Protocol) SSL - SECURE SOCKET LAYER Historique
Plus en détailLes certificats numériques
Les certificats numériques Quoi, pourquoi, comment Freddy Gridelet 9 mai 2005 Sécurité du système d information SGSI/SISY La sécurité : quels services? L'authentification des acteurs L'intégrité des données
Plus en détailLe protocole sécurisé SSL
Chapitre 4 Le protocole sécurisé SSL Les trois systèmes de sécurisation SSL, SSH et IPSec présentés dans un chapitre précédent reposent toutes sur le même principe théorique : cryptage des données et transmission
Plus en détailRichard MONTBEYRE Master 2 Professionnel Droit de l Internet Administration Entreprises. La banque en ligne et le protocole TLS : exemple
Richard MONTBEYRE Master 2 Professionnel Droit de l Internet Administration Entreprises La banque en ligne et le protocole TLS : exemple 1 Introduction Définition du protocole TLS Transport Layer Security
Plus en détailAnnexe 8. Documents et URL de référence
Documents et URL de référence Normes et standards Normes ANSI ANSI X9.30:1-1997, Public Key Cryptography for the Financial Services Industry: Part 1: The Digital Signature Algorithm (DSA) (revision of
Plus en détailWindows Server 2008 Sécurité ADMINISTRATION ET CONFIGURATION DE LA SECURITE OLIVIER D.
2013 Windows Server 2008 Sécurité ADMINISTRATION ET CONFIGURATION DE LA SECURITE OLIVIER D. Table des matières 1 Les architectures sécurisées... 3 2 La PKI : Autorité de certification... 6 3 Installation
Plus en détailCertificats et infrastructures de gestion de clés
ÉCOLE DU CIMPA "GÉOMÉTRIE ALGÉBRIQUE, THÉORIE DES CODES ET CRYPTOGRAPHIE" ICIMAF et Université de la Havane 20 novembre - 1er décembre 2000 La Havane, Cuba Certificats et infrastructures de gestion de
Plus en détailPerso. SmartCard. Mail distribution. Annuaire LDAP. SmartCard Distribution OCSP. Codes mobiles ActivX Applet. CRLs
HASH LOGIC s e c u r i t y s o l u t i o n s Version 1.0 de Janvier 2007 PKI Server Une solution simple, performante et économique Les projets ayant besoin d'une infrastructure PKI sont souvent freinés
Plus en détailLa sécurité des Réseaux Partie 7 PKI
La sécurité des Réseaux Partie 7 PKI Fabrice Theoleyre Enseignement : INSA Lyon / CPE Recherche : Laboratoire CITI / INSA Lyon Références C. Cachat et D. Carella «PKI Open Source», éditions O REILLY Idealx,
Plus en détailLivre blanc. Sécuriser les échanges
Livre blanc d information Sécuriser les échanges par emails Octobre 2013 www.bssi.fr @BSSI_Conseil «Sécuriser les échanges d information par emails» Par David Isal Consultant en Sécurité des Systèmes d
Plus en détailPolitique de certification et procédures de l autorité de certification CNRS
Politique de certification et procédures de l autorité de certification CNRS V2.1 1 juin 2001 Jean-Luc Archimbaud CNRS/UREC Directeur technique de l UREC Chargé de mission sécurité réseaux informatiques
Plus en détailProtocole industriels de sécurité. S. Natkin Décembre 2000
Protocole industriels de sécurité S. Natkin Décembre 2000 1 Standards cryptographiques 2 PKCS11 (Cryptographic Token Interface Standard) API de cryptographie développée par RSA labs, interface C Définit
Plus en détailLe protocole SSH (Secure Shell)
Solution transparente pour la constitution de réseaux privés virtuels (RPV) INEO.VPN Le protocole SSH (Secure Shell) Tous droits réservés à INEOVATION. INEOVATION est une marque protégée PLAN Introduction
Plus en détailSignature électronique. Romain Kolb 31/10/2008
Romain Kolb 31/10/2008 Signature électronique Sommaire I. Introduction... 3 1. Motivations... 3 2. Définition... 3 3. La signature électronique en bref... 3 II. Fonctionnement... 4 1. Notions requises...
Plus en détailJournées MATHRICE "Dijon-Besançon" DIJON 15-17 mars 2011. Projet MySafeKey Authentification par clé USB
Journées MATHRICE "Dijon-Besançon" DIJON 15-17 mars 2011 1/23 Projet MySafeKey Authentification par clé USB Sommaire 2/23 Introduction Authentification au Système d'information Problématiques des mots
Plus en détailCadre de Référence de la Sécurité des Systèmes d Information
Cadre de Référence de la Sécurité des Systèmes d Information POLITIQUE DE CERTIFICATION AC EXTERNES AUTHENTIFICATION SERVEUR Date : 12 décembre 2011 Version : 1.1 État du document : Validé Reproduction
Plus en détailPolitique de Certification Autorité de Certification Signature Gamme «Signature simple»
Responsable de la Sécurité de l Information --------- Politique de Certification Autorité de Certification Signature Gamme «Signature simple» Date : 22 septembre 2010 Version : 1.2 Rédacteur : RSI Nombre
Plus en détailSÉCURITÉ DU SI. Mini PKI. Denoun Jérémy De Daniloff Cyril Bettan Michael SUJET (3): Version : 1.0
M I N I - P K I SRS Epita Promo 2009 SÉCURITÉ DU SI SUJET (3): Mini PKI Version : 1.0 Denoun Jérémy De Daniloff Cyril Bettan Michael 1 4-1 6 r u e v o l t a i r e 9 4 2 3 0 K r e m l i n B i c ê t r e
Plus en détailSécurité des réseaux sans fil
Sécurité des réseaux sans fil Francois.Morris@lmcp.jussieu.fr 13/10/04 Sécurité des réseaux sans fil 1 La sécurité selon les acteurs Responsable réseau, fournisseur d accès Identification, authentification
Plus en détailAction Spécifique Sécurité du CNRS 15 mai 2002
Action Spécifique Sécurité du CNRS 15 mai 2002 Sécurité du transport Ahmed Serhrouchni ENST-PARIS Plan. Typologie des solutions Protocole SSL/TLS Introduction Architecture Ports et applications Services
Plus en détailMieux comprendre les certificats SSL THAWTE EST L UN DES PRINCIPAUX FOURNISSEURS DE CERTIFICATS SSL DANS LE MONDE
Mieux comprendre les certificats SSL THAWTE EST L UN DES PRINCIPAUX FOURNISSEURS DE CERTIFICATS SSL DANS LE MONDE sommaire MIEUX COMPRENDRE LES CERTIFICATS SSL...1 SSL et certificats SSL : définition...1
Plus en détailGestion des certificats digitaux et méthodes alternatives de chiffrement
Gestion des certificats digitaux et méthodes alternatives de chiffrement Mai 2011 Julien Cathalo Section Recherches Cryptographie à clé publique Invention du concept : 1976 (Diffie, Hellman) Premier système
Plus en détail«La Sécurité des Transactions et des Echanges Electroniques»
Séminaire «Journées d Informatique Pratique JIP 2005» Département Informatique, ISET Rades 31 Mars, 1et 2 Avril 2005 «La Sécurité des Transactions et des Echanges Electroniques» Présenté par: Mme Lamia
Plus en détailLa sécurité dans les grilles
La sécurité dans les grilles Yves Denneulin Laboratoire ID/IMAG Plan Introduction les dangers dont il faut se protéger Les propriétés à assurer Les bases de la sécurité Protocoles cryptographiques Utilisation
Plus en détailDevoir Surveillé de Sécurité des Réseaux
Année scolaire 2009-2010 IG2I L5GRM Devoir Surveillé de Sécurité des Réseaux Enseignant : Armand Toguyéni Durée : 2h Documents : Polycopiés de cours autorisés Note : Ce sujet comporte deux parties. La
Plus en détailLa citadelle électronique séminaire du 14 mars 2002
e-xpert Solutions SA 29, route de Pré-Marais CH 1233 Bernex-Genève Tél +41 22 727 05 55 Fax +41 22 727 05 50 La citadelle électronique séminaire du 14 mars 2002 4 info@e-xpertsolutions.com www.e-xpertsolutions.com
Plus en détailModèle de sécurité de la Grille. Farida Fassi Master de Physique Informatique Rabat, Maroc 24-27 May 2011
Modèle de sécurité de la Grille Farida Fassi Master de Physique Informatique Rabat, Maroc 24-27 May 2011 2 Plan Introduction a la sécurité sur la Grille de Calcul Grid Security Infrastructure (GSI) Authentification
Plus en détailGestion des Clés. Pr Belkhir Abdelkader. 10/04/2013 Pr BELKHIR Abdelkader
Gestion des Clés Pr Belkhir Abdelkader Gestion des clés cryptographiques 1. La génération des clés: attention aux clés faibles,... et veiller à utiliser des générateurs fiables 2. Le transfert de la clé:
Plus en détailSécurisez votre serveur Web Internet Information Services de Microsoft (MS IIS) avec un certificat numérique de thawte thawte thawte thawte thawte
Sécurisez votre serveur Web Internet Information Services de Microsoft (MS IIS) avec un certificat numérique de thawte UN GUIDE ÉTAPE PAR ÉTAPE, pour tester, acheter et utiliser un certificat numérique
Plus en détailPolitique de Certification et Déclaration des pratiques de certifications de l autorité Tunisian Server Certificate Authority PTC BR
Page : 1/67 Agence Nationale de Certification Electronique Politique de Certification et Déclaration des pratiques de certifications de l autorité Tunisian Server Certificate Rev 00 Rev 01 Mise à jour
Plus en détailPUBLIC KEY INFRASTRUCTURE. Rappels PKI PKI des Impôts PKI de la Carte de Professionnel de Santé
PUBLIC KEY INFRASTRUCTURE Rappels PKI PKI des Impôts PKI de la Carte de Professionnel de Santé Rappels PKI Fonctionnement général Pourquoi? Authentification Intégrité Confidentialité Preuve (non-répudiation)
Plus en détailDu 03 au 07 Février 2014 Tunis (Tunisie)
FORMATION SUR LA «CRYPTOGRAPHIE APPLIQUEE ET SECURITE DES TRANSACTIONS ELECTRONIQUES» POUR LES OPERATEURS ET REGULATEURS DE TELECOMMUNICATION Du 03 au 07 Février 2014 Tunis (Tunisie) CRYPTOGRAPHIE ET SECURITE
Plus en détailSSH, le shell sécurisé
, le shell sécurisé Objectifs : 1. Présenter le protocole et les outils associés Sébastien JEAN Pourquoi 1/2? Les services standards ne supportent que peu de propriétés de sécurité souvent l identification,
Plus en détailCIBLE DE SECURITE CSPN DU PRODUIT PASS. (Product for Advanced SSO)
CIBLE DE SECURITE CSPN DU PRODUIT PASS (Product for Advanced SSO) Préparé pour : ANSSI Préparé par: Thales Communications & Security S.A. 4 Avenue des Louvresses 92622 GENNEVILLIERS CEDEX France This document
Plus en détailPolitique de Certification de l'ac "ALMERYS SIGNATURE AND AUTHENTICATION CA NC" Référentiel : Sous-Référentiel : Référence : Statut :
Politique de Certification de l'ac "ALMERYS SIGNATURE AND PL Politique Référentiel : Sous-Référentiel : Référence : Statut : Sécurité PKI PKA017 OID 1.2.250.1.16.12.5.41.1.7.3.1 Validé Validé par : Fonction
Plus en détailDéfinition d une ICP et de ses acteurs
Chapitre 2 Définition d une ICP et de ses acteurs Infrastructure à clé publique Comme son nom l indique, une infrastructure à clé publique est un ensemble de moyens matériels, de logiciels, de composants
Plus en détailSécurité des réseaux IPSec
Sécurité des réseaux IPSec A. Guermouche A. Guermouche Cours 4 : IPSec 1 Plan 1. A. Guermouche Cours 4 : IPSec 2 Plan 1. A. Guermouche Cours 4 : IPSec 3 Pourquoi? Premier constat sur l aspect critique
Plus en détailSSL. Secure Socket Layer. R. Kobylanski romain.kobylanski@inpg.fr. janvier 2005 - version 1.1 FC INPG. Protocole SSL Application avec stunnel
SSL Secure Socket Layer R. Kobylanski romain.kobylanski@inpg.fr FC INPG janvier 2005 - version 1.1 1 Protocole SSL 2 SSL/TLS Encapsule des protocoles non sécurisés (HTTP IMAP...) dans une couche chiffrée
Plus en détailFORMATION SUR «CRYPTOGRAPHIE APPLIQUEE
FORMATION SUR «CRYPTOGRAPHIE APPLIQUEE ET SECURITE DES TRANSACTIONS ELECTRONIQUES : STANDARDS, ALGORITHMES DE HACHAGE ET PKI» DU 22 AU 26 JUIN 2015 TUNIS (TUNISIE) CRYPTOGRAPHIE APPLIQUEE ET SECURITE DES
Plus en détailGestion des clés. Génération des clés. Espaces de clés réduits. Mauvais choix de clés. Clefs aléatoires. Phrases mots de passe
Génération des clés Gestion des clés Espaces de clés réduits Codage restreint, caractères choisis, clés faibles, Mauvais choix de clés Lettre, mnémotechnique, attaque par dictionnaire Clefs aléatoires
Plus en détailTunnels. Plan. Pourquoi? Comment? Qu est-ce? Quelles solutions? Tunnels applicatifs ESIL INFO 2005/2006. Sophie Nicoud Sophie.Nicoud@urec.cnrs.
Tunnels ESIL INFO 2005/2006 Sophie Nicoud Sophie.Nicoud@urec.cnrs.fr Plan Pourquoi? Comment? Qu est-ce? Quelles solutions? Tunnels applicatifs 2 Tunnels, pourquoi? Relier deux réseaux locaux à travers
Plus en détailDISTANT ACESS. Emna TRABELSI (RT3) Chourouk CHAOUCH (RT3) Rabab AMMAR (RT3) Rania BEN MANSOUR (RT3) Mouafek BOUZIDI (RT3)
DISTANT ACESS Emna TRABELSI (RT3) Chourouk CHAOUCH (RT3) Rabab AMMAR (RT3) Rania BEN MANSOUR (RT3) Mouafek BOUZIDI (RT3) TABLE DES MATIERES I. PRESENTATION DE L ATELIER...2 1. PRESENTATION GENERALE...2
Plus en détailSSL/TLS: Secure Socket Layer/Transport Layer Secure Quelques éléments d analyse. GRES 2006 Bordeaux 12 Mai 2006. Ahmed Serhrouchni ENST-PARIS CNRS
SSL/TLS: Secure Socket Layer/Transport Layer Secure Quelques éléments d analyse GRES 2006 Bordeaux 12 Mai 2006 Ahmed Serhrouchni ENST-PARIS CNRS Plan Introduction (10 minutes) Les services de sécurité
Plus en détailAutorité de Certification OTU
Référence du document : OTU.PC.0002 Révision du document : 1.2 Date du document : 22/11/2013 Classification Public Autorité de Certification OTU Politique de Certification www.atosworldline.com Politique
Plus en détailTP HTTP. Université Pierre Mendès France U.F.R. Sciences de l Homme et de la Société Master IC²A
Université Pierre Mendès France U.F.R. Sciences de l Homme et de la Société Master IC²A TP HTTP TP HTTP Master IC 2 A 2014/2015 Christian Bulfone / Jean-Michel Adam 1/11 Câblage et configuration du réseau
Plus en détailSécurité WebSphere MQ V 5.3
Guide MQ du 21/03/2003 Sécurité WebSphere MQ V 5.3 Luc-Michel Demey Demey Consulting lmd@demey demey-consulting.fr Plan Les besoins Les technologies Apports de la version 5.3 Mise en œuvre Cas pratiques
Plus en détailIntroduction à la sécurité Cours 8 Infrastructure de clés publiques. Catalin Dima
Introduction à la sécurité Cours 8 Infrastructure de clés publiques Catalin Dima 1 Gestion des clés La gestion des clés concerne : La distribution de clés cryptographiques, Les mécanismes utilisés pour
Plus en détailPublic Key Infrastructure (PKI)
Public Key Infrastructure (PKI) Introduction Authentification - Yoann Dieudonné 1 PKI : Définition. Une PKI (Public Key Infrastructure) est une organisation centralisée, gérant les certificats x509 afin
Plus en détailEMV, S.E.T et 3D Secure
Sécurité des transactionsti A Carte Bancaire EMV, S.E.T et 3D Secure Dr. Nabil EL KADHI nelkadhi@club-internet.fr; Directeur du Laboratoire L.E.R.I.A. www.leria.eu Professeur permanant A EPITECH www.epitech.net
Plus en détailCryptographie. Cours 3/8 - Chiffrement asymétrique
Cryptographie Cours 3/8 - Chiffrement asymétrique Plan du cours Différents types de cryptographie Cryptographie à clé publique Motivation Applications, caractéristiques Exemples: ElGamal, RSA Faiblesses,
Plus en détailPOLITIQUE DE CERTIFICATION DE L'AC KEYNECTIS SSL RGS * (authentification serveur) Date : 12/08/2011
POLITIQUE DE CERTIFICATION DE L'AC KEYNECTIS SSL RGS * (authentification serveur) Date : 12/08/2011 POLITIQUE DE CERTIFICATION : AC KEYNECTIS SSL RGS * (AUTHENTIFICATION SERVEUR) Objet: Ce document consiste
Plus en détailPKI PKI IGC IGC. Sécurité des RO. Partie 4. Certificats : pourquoi?
Sécurité des RO Partie 4 PKI IGC Anas ABOU EL KALAM anas.abouelkalam@enseeiht.fr PKI IGC 2 Certificats : pourquoi? chiffrement & signatures supposent l authenticité des clés publiques, disponibles sur
Plus en détailFORMATIONS 2010. www.ineovation.fr
Infrastructures à clefs publiques/pki X.509 Sécurité de la Voix sur IP Technologie IPSec VPN Introduction à la cryptographie Sécuriser un système Unix ou Linux Version 1.0: 17 MAI 2010 1 1 Infrastructures
Plus en détailLes infrastructures de clés publiques (PKI, IGC, ICP)
Les infrastructures de clés publiques (PKI, IGC, ICP) JDLL 14 Octobre 2006 Lyon Bruno Bonfils 1 Plan L'utilisation des certificats Le rôle d'un certificat Les autorités de confiance Le
Plus en détailPolitique de Certification - AC SG TS 2 ETOILES Signature
- AC SG TS 2 ETOILES Signature Référence V1.0 Octobre 2010 OID 1.2.250.1.124.7.1.2.3.1 Table des matières 1. INTRODUCTION...8 1.1. Présentation générale... 8 1.2. Identification du document... 8 1.3. Entités
Plus en détailROYAUME DU MAROC Politique de certification - Autorité de Certification Externe -
ROYAUME DU MAROC Politique de certification - Autorité de Certification Externe - BKAM, tous droits réservés Page 1 sur 45 Table des matières 1 INTRODUCTION... 8 1.1 Présentation générale... 8 1.2 Définitions
Plus en détailCERTEUROPE ADVANCED V4 Politique de Certification V1.0 Diffusion publique
Page 1 / 63 POLITIQUE DE CERTIFICATION Autorité de certification «CERTEUROPE ADVANCED CA V4» Authentification serveur Identification (OID) : Authentification Serveur SSL/TLS Niveau * : 1.2.250.1.105.18.1.1.0
Plus en détailUne introduction à SSL
Une introduction à SSL Felip Manyé i Ballester 6 juin 2009 Plan Introduction et concepts de base 1 Introduction et concepts de base Buts et enjeux de SSL Concepts de base 2 Certificats X.509 Protocole
Plus en détailLes Protocoles de sécurité dans les réseaux WiFi. Ihsane MOUTAIB & Lamia ELOFIR FM05
Les Protocoles de sécurité dans les réseaux WiFi Ihsane MOUTAIB & Lamia ELOFIR FM05 PLAN Introduction Notions de sécurité Types d attaques Les solutions standards Les solutions temporaires La solution
Plus en détailLa Technologie Carte à Puce EAP TLS v2.0
La Technologie Carte à Puce EAP TLS v2.0 Une sécurité forte, pour les services basés sur des infrastructures PKI, tels que applications WEB, VPNs, Accès Réseaux Pascal Urien Avril 2009 Architectures à
Plus en détailCryptographie et fonctions à sens unique
Cryptographie et fonctions à sens unique Pierre Rouchon Centre Automatique et Systèmes Mines ParisTech pierre.rouchon@mines-paristech.fr Octobre 2012 P.Rouchon (Mines ParisTech) Cryptographie et fonctions
Plus en détailLes fonctions de hachage, un domaine à la mode
Les fonctions de hachage, un domaine à la mode JSSI 2009 Thomas Peyrin (Ingenico) 17 mars 2009 - Paris Outline Qu est-ce qu une fonction de hachage Comment construire une fonction de hachage? Les attaques
Plus en détailRouteur Chiffrant Navista Version 2.8.0. Et le protocole de chiffrement du Réseau Privé Virtuel Navista Tunneling System - NTS Version 3.1.
Routeur Chiffrant Navista Version 2.8.0 Et le protocole de chiffrement du Réseau Privé Virtuel Navista Tunneling System - NTS Version 3.1.0 Cibles de sécurité C.S.P.N Référence : NTS-310-CSPN-CIBLES-1.05
Plus en détailLes risques liés à la signature numérique. Pascal Seeger Expert en cybercriminalité
Les risques liés à la signature numérique Pascal Seeger Expert en cybercriminalité Présentation Pascal Seeger, expert en cybercriminalité Practeo SA, Lausanne Partenariat avec Swisscom SA, Zurich Kyos
Plus en détailCA SIC Directives de certification Certificate Practice Statement (CPS) du SIC Customer ID CA 1024 Level 2
CA SIC Directives de certification Certificate Practice Statement (CPS) du SIC Customer ID CA 1024 Level 2 Version 2.2 / Decembre 2012 1 Notes Les informations de ce document vous sont fournies sans garantie
Plus en détailFonctionnement des PKI. - 3 - Architecture PKI
Fonctionnement des PKI - 3 - Architecture PKI Plan Introduction Architecture et composantes Analogie : carte d'identité nationale Entités et rôles respectifs Gestion/Cycle de vie des certificats Demande
Plus en détailServices de Confiance numérique en Entreprise Conférence EPITA 27 octobre 2008
Services de Confiance numérique en Entreprise Conférence EPITA 27 octobre 2008 1 Sommaire Introduction Intervenant : Gérald Grévrend Présentation d Altran CIS Le sujet : les services de confiance numérique
Plus en détailEJBCA Le futur de la PKI
EJBCA Le futur de la PKI EJBCA EJBCA c'est quoi? EJBCA est une PKI (Public Key infrastructure) ou IGC (Infrastructure de gestion de clés) sous licence OpenSource (LGPL) développée en Java/J2EE. EJBCA bien
Plus en détailRéseaux Privés Virtuels
Réseaux Privés Virtuels Introduction Théorie Standards VPN basés sur des standards VPN non standards Nouvelles technologies, WiFi, MPLS Gestion d'un VPN, Gestion d'une PKI Introduction Organisation du
Plus en détailProcessus 2D-Doc. Version : 1.1 Date : 16/11/2012 Pôle Convergence AGENCE NATIONALE DES TITRES SECURISÉS. Processus 2D-Doc.
Page 1 sur 16 PROCESSUS 2D-DOC...1 1. ARCHITECTURE GLOBALE...4 1.1. 1.2. Les rôles... 4 Les étapes fonctionnelles... 5 1.2.1. Etape 1 : la création du code à barres... 5 1.2.2. Etape 2 : l envoi du document...
Plus en détailtitre : CENTOS_CUPS_install&config Système : CentOs 5.7 Technologie : Cups 1.3.7 Auteur : Charles-Alban BENEZECH
2012 Les tutos à toto CUPS server - install and configure Réalisée sur CentOS 5.7 Ecrit par Charles-Alban BENEZECH 2012 titre : CENTOS_CUPS_install&config Système : CentOs 5.7 Technologie : Cups 1.3.7
Plus en détailSécurité de l'information
Sécurité de l'information Sylvain Duquesne Université Rennes 1, laboratoire de Mathématiques 24 novembre 2010 Les Rendez-Vous Mathématiques de l'irem S. Duquesne (Université Rennes 1) Sécurité de l'information
Plus en détailEJBCA PKI. Yannick Quenec'hdu Reponsable BU sécurité
EJBCA PKI Yannick Quenec'hdu Reponsable BU sécurité EJBCA EJBCA est une PKI (Public Key infrastructure) ou IGC (Infrastructure de gestion de clés) sous licence OpenSource (LGPL) développée en Java/J2EE.
Plus en détailLa sécurité des réseaux. 9e cours 2014 Louis Salvail
La sécurité des réseaux 9e cours 2014 Louis Salvail Échanges de clés authentifiés Supposons qu Obélix et Astérix, qui possèdent des clés publiques certifiées PK O et PK A, veulent établir une communication
Plus en détailCryptologie à clé publique
Cryptologie à clé publique La cryptologie est partout Chacun utilise de la crypto tous les jours sans forcément sans rendre compte en : - téléphonant avec un portable - payant avec sa carte bancaire -
Plus en détailPascal Gachet Travail de diplôme 2001. Déploiement de solutions VPN : PKI Etude de cas
Travail de diplôme 2001 Déploiement de solutions VPN : Département E+I Filière : Télécommunication Orientation : Réseaux et services Professeur responsable : Stefano Ventura Date : 20 décembre 2001 : Remerciements
Plus en détail1. Présentation de WPA et 802.1X
Lors de la mise en place d un réseau Wi-Fi (Wireless Fidelity), la sécurité est un élément essentiel qu il ne faut pas négliger. Effectivement, avec l émergence de l espionnage informatique et l apparition
Plus en détailPOLITIQUE DE CERTIFICATION AC RACINE JUSTICE
POLITIQUE DE CERTIFICATION AC RACINE JUSTICE OID du document : 1.2.250.1.120.2.1.1.1 Nombre total de pages : 42 Statut du document : Projet Version finale Nom Alain GALLET Fonction Rédaction Responsable
Plus en détailLe protocole RADIUS Remote Authentication Dial-In User Service
Remote Authentication Dial-In User Service CNAM SMB 214-215 Claude Duvallet Université du Havre UFR des Sciences et Techniques Courriel : Claude.Duvallet@gmail.com Claude Duvallet 1/26 Objectifs du cours
Plus en détailA. À propos des annuaires
Chapitre 2 A. À propos des annuaires Nous sommes familiers et habitués à utiliser différents types d'annuaires dans notre vie quotidienne. À titre d'exemple, nous pouvons citer les annuaires téléphoniques
Plus en détailHASH LOGIC. Web Key Server. Solution de déploiement des certificats à grande échelle. A quoi sert le Web Key Server? A propos de HASHLOGIC
HASH LOGIC s e c u r i t y s o l u t i o n s Version 1.0 de Janvier 2007 Web Key Server Solution de déploiement des certificats à grande échelle A propos de HASHLOGIC HASHLOGIC est Editeur spécialisé dans
Plus en détailUniversité de Reims Champagne Ardenne. HTTPS, SSL, SSH, IPSEC et SOCKS. Présenté par : BOUAMAMA Mohamed Nadjib AZIZ Xerin
2007 2008 Université de Reims Champagne Ardenne Sécurité dans TCP/IP HTTPS, SSL, SSH, IPSEC et SOCKS Présenté par : BOUAMAMA Mohamed Nadjib AZIZ Xerin 1 Protocole HTTPS HTTPS signifie Hypertext Transfer
Plus en détailGestion des Clés Publiques (PKI)
Chapitre 3 Gestion des Clés Publiques (PKI) L infrastructure de gestion de clés publiques (PKI : Public Key Infrastructure) représente l ensemble des moyens matériels et logiciels assurant la gestion des
Plus en détailINF 4420: Sécurité Informatique Cryptographie II
: Cryptographie II José M. Fernandez M-3106 340-4711 poste 5433 Aperçu Crypto II Types de chiffrement Par bloc vs. par flux Symétrique vs. asymétrique Algorithmes symétriques modernes DES AES Masque jetable
Plus en détailNORMES TECHNIQUES POUR UNE INTEROPERABILITE DES CARTES D IDENTITE ELECTRONIQUES
Représentant les avocats d Europe Representing Europe s lawyers NORMES TECHNIQUES POUR UNE INTEROPERABILITE DES CARTES D IDENTITE ELECTRONIQUES Normes techniques pour une interopérabilité des cartes d
Plus en détailSkype (v2.5) Protocol Data Structures (French) Author : Ouanilo MEDEGAN http://www.oklabs.net
Skype (v2.5) Protocol Data Structures (French) Author : Ouanilo MEDEGAN http://www.oklabs.net : Champ Encodé SKWRITTEN() : Champ Variable défini Précédemment & définissant l état des champs à suivre ECT
Plus en détail