RSX112 Sécurité et réseaux
|
|
- Solange Cantin
- il y a 8 ans
- Total affichages :
Transcription
1 RSX112 Sécurité et réseaux Module 12 SSL, S/MIME, PGP 1 CNAM /EBU
2 Résumé séance précédente Exercices Partage de secret Sécurisation du réseau SSL 2 CNAM /EBU
3 Protocole SSL Handshake client serveur client_hello server_hello certificate server_key_exchange certificate_request server_hello_done certificate client_key_exchange certificate_verify change_cipher_spec finished change_cipher_spec finished Phase 1 : Négociation de l ID de session, de l algorithme d échange de clé, l algorithme de Hash, l algorithme de chiffrement, et échange des aléas initiaux Phase 2 : Le serveur peut envoyer son certificat et un message d échange de ; il peut demander au client d envoyer un certificat. Le serveur indique la fin de la phase hello. Phase 3 : Le client envoie son certificat si demandé et peut demander une vérification explicite. Le client envoie systématiquement son message d échange de clé. Phase 4 : Initialisation de paramètres et fin du handshake 3 CNAM /EBU
4 Message «Client_Hello» client_hello client_version Version maximale supportée par le client client_random Heure actuelle (4 octets) + peusdo-aléa (28 octets) session_id Vide si le client veut créer une nouvelle session ou Identifiant d une ancienne session, dans laquelle le client veut créer une nouvelle connexion cipher_suites Liste des options cryptographiques supportées par le client, par ordre de préférence Une suite cryptographique contient les spécifications : Des algorithmes d échange de clé, de chiffrement et de hash Les algorithmes définissent implicitement les longueurs de hash, IV et les paramètres des clés (part of the Cipher Spec of the session state) exemple: SSL_RSA_with_3DES_EDE_CBC_SHA compression_methods Liste des méthodes de compression supportées par le client 4 CNAM /EBU
5 Message «Server_Hello» server_hello server_version min(version maximale supportée par le client, version maximale supportée par le serveur) server_random Heure courante + aléa L aléa doit être indépendant de celui du client session_id Identifiant de session choisi par le serveur Si le client veut reprendre une session ancienne : Le serveur vérifie si la session peut être reprise Si oui, il répond avec l ID de session et les deux parties terminent par les messages «finished» Si le client veut une nouvelle session, le serveur génère un nouvel identifiant cipher_suite Suite unique sélectionnée par le serveur à partir de la liste fournie par le client compression_method Méthode de compression unique sélectionnée par le serveur parmi celles proposées par le client 5 CNAM /EBU
6 Méthodes d échange de clés supportées Basées sur RSA (SSL_RSA_with...) La clé secrète (pre-master secret) est chiffrée avec la clé publique RSA du serveur La clé publique du serveur est envoyée au client durant l échange Fixed Diffie-Hellman (SSL_DH_RSA_with ou SSL_DH_DSS_with ) Le serveur a des paramètres DH fixes, contenus dans un certificat signé par une AC Le client peut avoir des paramètres DH fixes, contenus dans un certifcicat signé par une AC ou il peut envoyer des paramètres DH temporaires, non certifiés dans le message client_key_exchange ephemeral Diffie-Hellman (SSL_DHE_RSA_with ou SSL_DHE_DSS_with ) Le serveur et le client génèrent des paramètres DH temporaires (utilisables une seule fois) Le serveur signe ses paramètres DH avec sa clé privée RSA ou DSS Le client peut s authentifier (si le serveur le demande) en signant un hash des messages handshake avec sa clé privée RSA ou DSS anonymous Diffie-Hellman Le serveur et le client génère des paramètres DH temporaires utilisables une seule fois Ils envoient leurs paramètres à l autre sans authentification Fortezza Schéma d échange de clé propriétaire à Fortezza 6 CNAM /EBU
7 Messsages «Server certificate» et «key exchange» certificate Nécessaire pour tout échange de clé sauf pour «anonymous DH» Contient un certificat ou une chaine de certificats X.509 Peut contenir : Une clé publique RSA pour le chiffrement ou Une clé publique RSA ou DSS pour la signature seulement, ou Des paramètres DH fixes server_key_exchange Envoyé uniquement si le certificat ne contient pas suffisamment d information pour réaliser l échange de clés (ex. le certificat ne contient qu une clé RSA de signature) Peut contenir : Une clé publique RSA (exposant et modulo), ou Des paramètres DH (p, g, valeur DH publique), ou Des paramètres Fortezza Signé Si DSS: signature du hash SHA-1 de (client_random server_random server_params) SI RSA: Concaténation et chiffrement avec la clé privée des hashes MD5 et SHA-1 de (client_random server_random server_params) 7 CNAM /EBU
8 Messages «Certificate request» et «server hello done» certificate_request Envoyé si le client doit s authentifier Spécifie que type de certificat est attendu (rsa_sign, dss_sign, rsa_fixed_dh, dss_fixed_dh, ) server_hello_done Envoyé pour indiquer que le serveur a terminé sa part de l échange de clé Après envoie de ce message, le serveur attend al réponse du client Le client doit vérifier que le serveur a fourni un certificat valide et que les paramètres du serveur sont acceptables 8 CNAM /EBU
9 Authentification du client et échange de clé certificate Envoyé seulement si demandé par le serveur Peut contenir Une clé publique RSA ou DSS pour la signature, ou Des paramètres DH fixes client_key_exchange Systématiquement envoyé (mais vide si la méthode d échange de clé est «fixed DH») Peut contenir Un «pre-master secret» chiffré par RSA, ou Les valeurs DH temporaires du client, ou Les paramètres d échange de clé Fortezza certificate_verify Envoyé uniquement si le client envoie un certificat Permet l authentification du client Contient un hash signé de l ensemble des messages «handshake» précédents Si DSS: siganture d un hash SHA-1 Si RSA : concaténation des hashes MD5 et SHA-1 et chiffrement par la clé privée de MD5( master_secret pad_2 MD5( handshake_messages master_secret pad_1 ) ) SHA( master_secret pad_2 SHA( handshake_messages master_secret pad_1 ) ) 9 CNAM /EBU
10 Messages «Finished» finished Envoyé immédiatement après un message «change_cipher_spec» Premier message à utiliser les nouveaux paramètres et algorithmes négociés Utilisé pour vérifier que l échange de clé et l authentification sont corrects Contient les hashes MD5 et SHA-1 de tous les messages «handshake» précédents : MD5( master_secret pad_2 MD5( handshake_messages sender master_secret pad_1 ) ) SHA( master_secret pad_2 SHA( handshake_messages sender master_secret pad_1 ) ) où sender est un code qui identifie si l émetteur est le client ou le serveur (client: 0x434C4E54; serveur: 0x ) 10 CNAM /EBU
11 Initialisation des paramètres pre-master secret Si l échange de clé est basé sur RSA : Il est généré par le client Envoyé au serveur, chiffré par la clé publique RSA du serveur Si l échange de clé est basé sur Diffie-Hellman : pre_master_secret = g xy mod p master secret (48 bytes) master_secret = MD5( pre_master_secret SHA( A pre_master_secret client_random server_random )) MD5( pre_master_secret SHA( BB pre_master_secret client_random server_random )) MD5( pre_master_secret SHA( CCC pre_master_secret client_random server_random )) keys, MAC secrets, IVs MD5( master_secret SHA( A master_secret client_random server_random )) MD5( master_secret SHA( BB master_secret client_random server_random )) MD5( master_secret SHA( CCC master_secret client_random server_random )) key block : client write MAC secret server write MAC secret client write key server write key 11 CNAM /EBU
12 Alternatives pour l échange de clé RSA / pas d authentification du client Le serveur envoie sa clé publique RSA pour le chiffrement dans le message «server_certificate» Le message «server_key_exchange» n est pas envoyé Le client envoie le «pre-master secret» chiffré dans le message «client_key_exchange» Les messages «client_certificate» et «certificate_verify» ne sont pas envoyés ou Le serveur envoie sa clé publique RSA ou DSS dans le message «server_certificate» Le serveur envoie une clé publique RSA temporaire dans le message «server_key_exchange» Le client envoie le «pre-master secret» chiffré dans le message «client_key_exchange» Les messages «client_certificate» et «certificate_verify» ne sont pas envoyés 12 CNAM /EBU
13 Alternatives pour l échange de clé RSA / authentification du client Le serveur envoie sa clé publique RSA pour le chiffrement dans le message «server_certificate» Le message «server_key_exchange» n est pas envoyé Le client envoie sa clé publique de signature RSA ou DSS dans le message «client_certificate» Le client envoie le «pre-master secret» dans le message «client_key_exchange» Le client envoie une signature de l ensemble des messages «handshake» précédents dans le message «certificate_verify» ou Le serveur envoie sa clé publique de signature RSA ou DSS dans le message «server_certificate» Le serveur envoie une clé pub lique RSA temporaire dans le message «server_key_exchange» Le client envoie sa clé publique de signature RSA ou DSS dans le message «client_certificate» Le client envoie le «pre-master secret» chiffré dans le message «client_key_exchange» Le client envoie la signature sur l ensemble des messages «Handshake» précédents dans le message «certificate_verify» 13 CNAM /EBU
14 Alternatives pour l échange de clé fix DH / pas d authentification client Le serveur envoie ses paramètres fixes DH dans le message «server_certificate» Le message «server_key_exchange» n est pas envoyé Le client envoie une clé temporaire DH dans le message «client_key_exchange» Les messages «client_ certificate» et «certificate_verify» ne sont pas envoyés fix DH / authentification du client Le serveur envoie ses paramètres fixes DH dans le message «server_certificate» Le message «server_key_exchange» n est pas envoyé Le client envoie des paramètres DH fixes dans le message «client_certificate» Le message «client_key_exchange» est envoyé vide Le message «certificate_verify» n est pas envoyé 14 CNAM /EBU
15 Alternatives pour l échange de clé ephemeral DH / pas d authentification client Le serveur envoie sa clé publique de signature RSA ou DSS dans le message «server_certificate» Le serveur envoie des paramètres DH temporaires signés dans le message «server_key_exchange» Le client envoie les paramètres DH public temporaires dans le message «client_key_exchange» Les messages «client_certificate» et «certificate_verify» ne sont pas envoyés ephemeral DH / authentification client Le serveur envoie sa clé de signature RSA ou DSS dans le message «server_certificate» Le serveur envoie des paramètres DH temporaires signés dans le message «server_key_exchange» Le client envoie sa clé publique de signature RSA ou DSS dans le message «client_certificate» Le client envoie des paramètre DH temporaires dans le message «client_key_exchange» Le client envoie une signature de l ensemble des messages «Handshake» précédents dans le message «certificate_verify» 15 CNAM /EBU
16 Alternatives pour l échange de clé anonymous DH / pas d authentification client Le message «server_certificate» n est pas envoyé Le serveur envoie (non signé) des paramètres DH temporaires dans le message «server_key_exchange» Le client envoie des paramètres DH temporaires dans le message «client_key_exchange» Les messages «client_certificate» et «certificate_verify» ne sont pas envoyés anonymous DH / authentification client Pas autorisé 16 CNAM /EBU
17 Analyse des protocoles - écoute Toutes les données applicatives sont chiffrées avec une clé temporaire La clé temporaire est dérivée de paramètres aléatoires liés à chaque connexion (aléas client et serveur) et d un secret commun (master secret) par un hash Même si les clés de connexions sont compromises, le «master secret» reste intact Des clés différentes sont utilisées pour chaque direction d échange d une connexion Les algorithmes supportés sont d un bon niveau de sécurité 17 CNAM /EBU
18 Analyse des protocoles Analyse de traffic SSL n a pas pour objectif de protéger contre une analyse de trafic La longueur de bourrage n est pas aléatoire Pas de bourrage si un algorithme de chiffrement de flux est utilisé (option par défaut) Si SSL est utilisé pour protéger du trafic HTTP, un attaquant : Peut trouver la longueur d une requête URL Peut trouver la longueur des données HTML renvoyées Pourrait trouver avec une forte probabilité quelle URL a été demandée 18 CNAM /EBU
19 Analyse des protocoles attaques actives sur la confidentialité Attaque : copier-coller SSL empêche les attaques de type «copier/coller» Des clés différentes sont utilisées dans les deux sens et pour chaque connexion Tous les paquets sont authentifiés par un hash 19 CNAM /EBU
20 Analyse des protocoles attaque de rejeu SSL protège contre les attaques de rejeu en incluant un numéro de séquence dans les calculs de has Empêche de modifier l ordre des messages et leur suppression Les numéros de séquences font 64 bits En pratique, on ne réutilise partiquement jamais le même numéro 20 CNAM /EBU
21 Analyse des protocoles authentification des messages SSL utilise un hash type HMAC Il utilise une version ancienne de HMAC Le hash utilisé est suffisamment sécurisé Le secret du hash fait 128 bits de long Différents secrets de hash sont utilisés pour les différentes directions d échange et les différentes connexions Le hash n intègre pas le numéro de version (compris dans le message) Si le numéro de version est utilisé, il doit être intégré dans le calcul du hash Si le numéro de version n est jamais utilisé, il ne devrait pas être envoyé 21 CNAM /EBU
22 Principe de Horton Il ne faut pas authentifier seulement les données mais également toutes les informations du contexte, desquelles dépendent les traitements et les interprétations des données (i.e., algorithmes, clés, information ajoutée aux en-têtes, etc) 22 CNAM /EBU
23 Attaques sur les suites cryptographiques En SSL 2.0, un attaquant peut forcer l utilisation d un algorithme faible en modifiant la liste des algorithmes supportés dans les messages «hello» SSL 3.0 empêche cela en authentifiant tous les messages «Handshake» avec le «master secret» (dans les messages «finished») Le «master secret» est lui-même authentifié par d autres moyens Côté client Authentification implicite via le certificat serveur Seul le serveur peut déchiffrer le «pre-master secret» chiffré par RSA Seul le serveur only peut calculer le «pre-master secret» à partir des paramètres publics DH du client Authentification explicite par le message server_key_exchange (si envoyé) Les paramètres «ephemeral DH» sont signés par le serveur Côté serveur Authentification explicite par le messge «certificate_verify message» (si envoyé) Le message «certificate_verify» est signé par le client Il intègre le «master secret» 23 CNAM /EBU
24 Attaque MITM 24 CNAM /EBU
25 Attaque MITM SSL authentifie uniquement les paramètres RSA ou DH du serveur dans le message «server_key_exchange» Pas d authentification du contexte (méthode d échange de clé) qui permet d interpréter ces paramètres Pas conforme au principe de Horton! Un correctif : Faire un hash de tous les messages échangés avant le message «server_key_exchange» Include le hash dans la signature du message «server_key_exchange» 25 CNAM /EBU
26 Attaque sur la version SSL Les implémentations SSL 3.0 continuent à supporter SSL 2.0 Un attaquant peut modifier le message «client_hello» pour qu il ressemble à une message «client_hello» de SSL 2.0 Le serveur et le client vont alors utiliser SSL 2.0 SSL 2.0 possède de nombreuses failles de sécurité Notamment, pas de message «finished» pour authentifier la phase «handshake» Cette attaque est difficile à détecter SSL 3.0 peut détecter des changements de version Le «pre-master secret» généré pas des clients pouvant faire du SSL 3.0 : struct{ ProtocolVersion client_version; // latest version supported by the client opaque random[46]; // random bytes } PreMasterSecret; Un serveur SSL 3.0 détecte la modification de version : lorsqu il réalise le protocole «Handshake» en version 2.0 et reçoit un «pre-master secret» qui inclut une version 3.0 comme dernière version supportée par le client 26 CNAM /EBU
27 Attaque sur le Hash Le protocole «SSL Record» utilise HMAC Le protocole «SSL Handshake» utilise un protocole de hash MAC adapté sur certains points certificate_verify hash( master_secret pad_2 hash( handshake_messages master_secret pad_1 ) ) Finished hash( master_secret pad_2 hash( handshake_messages sender master_secret pad_1 ) ) De plus, ces MAC incluent le «master secret» SSL devrait utiliser systématiquement HMAC pour tous les hash 27 CNAM /EBU
28 Synthèse sur les attaques Protocole «SSL Record» Bonne protection contre les attaques d écoute et de modification de trafic Devrait être amélioré contre les attaques d analyse de trafic (i.e., utiliser du bourrage aléatoire) Devrait utiliser la dernière version de HMAC Protocole «SSL Handshake» Certaines attaques actives sont impossibles Modification des suites cryptographiques disponibles Dégradation du numéro de version supporté D autres attaques actives sont encore possibles, en fonction de la façon don l implémentation interprète les spécifications SSL Supprimer les messages «change_cipher_spec» Modifier les méthodes d échange de clé Les calculs MAC devraient être remplacés par HMAC Conclusion SSL 3.0 a été un pas en avant important dans la sécurisation des applications Internet 28 CNAM /EBU
29 TLS vs. SSL Numéro de version MAC Pour TLS, le numéro de version est 3.1 TLS utilise HMAC Le MAC intègre le champ de version de l en-tête «record» Plus de codes d alertes Suites cryptographiques TLS ne supporte pas les méthodes d échange et de chiffrement Fortezza certificate_verify message Le hase n est fait que sur les messages «handshake» En SSL, le hash contient le master_secret et du bourrage 29 CNAM /EBU
30 TLS vs. SSL (suite) Pseudo-random function PRF P_hash(secret, seed) = HMAC_hash( secret, A(1) seed ) où A(0) = seed HMAC_hash( secret, A(2) seed ) HMAC_hash( secret, A(3) seed ) A(i) = HMAC_hash(secret, A(i-1)) PRF(secret, label, seed) = P_MD5(secret_left, label seed) P_SHA(secret_right, label seed) 30 CNAM /EBU
31 Illustration de p_hash 31 CNAM /EBU
32 TLS vs. SSL (suite) finished message PRF( master_secret, client finished, MD5(handshake_messages) SHA(handshake_messages) ) Initialisation des paramètres cryptographiques Le «pre-master secret» est calculé de la même façon que pour SSL master secret PRF( pre_master_secret, master secret, client_random server_random ) key block PRF( master_secret, key expansion, server_random client_random ) Le bourrage est fait avant le chiffrement par bloc Des bourrages de longueur variable sont autorisés (max 255 octets de bourrage) 32 CNAM /EBU
33 Actualités sécurité Clé RSA 1024 bits cassée EPFL Clé faible Factorisation d un nombre de 350 chiffres 11 mois de calcul Google rachète GreenBorder Crée une barrière autour des navigateurs Contrôle les entrées/sorties des navigateurs Loi en Allemagne Interdiction d utiliser des outils «hackers» Mariage de Snort (IDS) et nmap (scanner) Deux failles Cisco dans les librairies SSL (Dos) Article sur les erreurs de programmation les plus répandues CNAM /EBU
34 Sécurisation de la messagerie S/MIME Services Formats de message Gestion des clés PGP Services Format de message Gestion des clés Gestion de la confiance 34 CNAM /EBU
35 S/MIME : introduction Secure / Multipurpose Internet Mail Extension Extension sécurité à MIME Fournit des services similaires à PGP Basé sur une techno RSA Security Standard pour une utilisation commerciale et de société RFC 2630, 2632, CNAM /EBU
36 RFC 822 Définit un format pour des messages texte à envoyer par e- mail Standard Internet Structure de messages conforme à RFC 822 Lignes d en-tête (i.e., from:, to:, cc: ) Ligne blanche Corps du message (texte à envoyer) Exemple Date: Tue, 16 Jan :37:17 (EST) From: Levente Buttyan <buttyan@hit.bme.hu> Subject: Test To: afriend@otherhost.bme.hu Blablabla 36 CNAM /EBU
37 Problèmes avec RFC 822 et SMTP Les fichiers exécutables doivent être convertis en ASCII Différents schémas existent (ex., Unix UUencode) Nécessité d un standard Données texte incluant des caractères spéciaux (ex., texte hongrois) Certains serveurs Rejettent les messages d une taille trop importante Suppriment, ajoutent ou ré-ordonnent les caractères CR et LF Tronquent ou génèrent de nouvelles lignes si elles font plus de 76 caractères Suppriment les espaces de fin (tabs et spaces) Complètent les lignes de message pour obtenir des ligens de longueur constante Convertissent les caractères tab en espaces multiples 37 CNAM /EBU
38 MIME Définit de nouveaux champs d en-tête Définit différents formats de contenu (standardisation de la représentation de contenu multimedia) Définit les encodages de transfert qui protège le contenu de modification par le système de mail 38 CNAM /EBU
39 MIME Nouveaux champs d entête MIME-Version Content-Type Décrit le contenu du corps du message L agent qui reçoit le mail peut choisir la méthode appropriée pour afficher le contenu Content-Transfer-Encoding Indique le type de transformation qui a été utilisée pour représenter le contenu du message Content-ID Content-Description Description de l objet dans le corps du message Utile quand le contenu n est pas lisible (ex., audio data) 39 CNAM /EBU
40 MIME Content types et subtypes text/plain, text/enriched image/jpeg, image/gif video/mpeg audio/basic application/postscript, application/octet-stream multipart/mixed, multipart/parallel, multipart/alternative, multipart/digest (each part is message/rfc822) message/rfc822, message/partial, message/external-body 40 CNAM /EBU
41 MIME Encodages de transfert 7bit 8bit Lignes courtes de caractères ASCII Lignes courtes de caractères non-ascii binary Caractères non-ascii Lignes non nécessairement courtes quoted-printable Les caractères non-ascii sont convertis en nombres hexadécimaux (e.g., =EF) base64 (radix 64) 3 blocs de 8 bits convertis en 4 blocs de 6 bits x-token Encodage non standard 41 CNAM /EBU
42 MIME Exemple MIME-Version: 1.0 From: Nathaniel Borenstein To: Ned Freed Date: Fri, 07 Oct :15: (PDT) Subject: A multipart example Content-Type: multipart/mixed; boundary=unique-boundary-1 This is the preamble area of a multipart message. Mail readers that understand multipart format should ignore this preamble. If you are reading this text, you might want to consider changing to a mail reader that understands how to properly display multipart messages. --unique-boundary-1 Content-type: text/plain; charset=us-ascii Some text --unique-boundary-1 Content-Type: multipart/parallel; boundary=unique-boundary-2 --unique-boundary-2 Content-Type: audio/basic Content-Transfer-Encoding: base64... base64-encoded 8000 Hz single-channel mu-law-format audio data goes here... --unique-boundary-2 Content-Type: image/jpeg Content-Transfer-Encoding: base64... base64-encoded image data goes here... --unique-boundary CNAM /EBU
43 MIME Exemple (suite) --unique-boundary-1 Content-type: text/enriched This is <bold><italic>enriched.</italic></bold><smaller>as defined in RFC 1896</smaller> Isn t it <bigger><bigger>cool?</bigger></bigger> --unique-boundary-1 Content-Type: message/rfc822 From: (mailbox in US-ASCII) To: (address in US-ASCII) Subject: (subject in US-ASCII) Content-Type: Text/plain; charset=iso Content-Transfer-Encoding: Quoted-printable... Additional text in ISO goes here... --unique-boundary CNAM /EBU
44 S/MIME RFC 1847 et 2311 définissent deux nouveaux types MIME : application/pkcs7-signature Utilisé pour la signature dans un message «multipart/signed» Message résultant : deux parties MIME : le contenu du mail (avec le PJ éventuellement) la signature application/pkcs7-mime Utilisé comme format alternatif pour la signature Utilisé pour les messages chiffrés et les messages chiffrés et signés Message résultant : une partie MIME contenant les données (chiffrées) et la signature Utilisation du format PKCS#7 pour les signatures et les données chiffrées Syntaxe générale pour le formatage d information signées ou chiffrées S/MIME chiffre/signe toujours le messages et les PJ Nécessite des certificats X509 Utilise l attribut E du nom du sujet comme identité 44 CNAM /EBU
45 Services S/MIME Données encapsulées (application/pkcs7-mime; smime-type = enveloped-data) Enveloppe digitale «standard» Données signées (application/pkcs7-mime; smime-type = signeddata) Signature numérique standard ( hash et signe ) contenu + signature sont encodés en base64 Données signées / texte en clair (multipart/signed) Signature digitale standard Seule la signature est encodée en base64 Les destinataires sans capacité S/MIME peuvent lire le message mais ne peuvent pas vérifier la signature Données signées et enveloppées signed and encrypted entities may be nested in any order 45 CNAM /EBU
46 Algorithme cryptographiques Fonction de hashage Obligatoire : SHA-1 Possible (destinataire) : MD5 (rétro-compatibilité) Signature numérique Obligatoire : DSS Possible : RSA Chiffrement asymétrique Obligatoire : ElGamal Possible : RSA Chiffrement symétrique Emetteur : Possible : 3DES, RC2/40 Destinataire : Obligatoire : 3DES Possible : RC2/40 46 CNAM /EBU
47 Exemple de données clair signées Exemple Partie MIME à signer 47 CNAM /EBU
48 Contenu d une signature Structure ASN.1 pour les données signées Champ vide dans le cas du format multipart/signed Plusieurs signataires possibles Structure ASN.1 pour les signataires «SignerInfo» Signature 48 CNAM /EBU
49 Données signées PKCS7 Version (Set of) Digest Algorithms Content type Content Info Content Set of certificates Set of CRLs Signer Info Version Signer ID (issuer and ser. no.) Digest Algorithm Authenticated Attributes Digest Encryption Alg. Encrypted digest (signature) 49 CNAM /EBU
50 Signature multiple 50 CNAM /EBU
51 Autre format de signature Contenu MIME intégré dans le champ «contentinfo» du format PKCS#7 Format «enveloppe» Avantage Pas de risque de transcodage Inconvénient Texte non lisible si le destinataire ne sait pas faire du S/MIME 51 CNAM /EBU
52 Données chiffrées Structure ASN.1 pour le type «envelopeddata» du format PKCS#7 52 CNAM /EBU
53 Données chiffrées pour plusieurs destinataires 53 CNAM /EBU
54 Données «enveloppées» PKCS7 Version Originator Info Recipient Info Version Recipient ID (issuer and s.no.) Key Encryption Algorithm Encrypted Key Encrypted Content Info Content type Content Encryption Alg. Encrypted Content 54 CNAM /EBU
55 Données chiffrées et signées Signature avant chiffrement Inverse possible 55 CNAM /EBU
56 Gestion des clés Certificats utilisés par S/MIME : X.509 v3 La gestion des clés est entre la stricte hiérarchie de certification et le modèle de PGP Les certificats sont signés par des autorités de certification (CA) Utilisation de chaines de confiance Les utilisateurs sont responsables de la configuration de leur client pour intégrer la liste des AC de confiance K 56 CNAM /EBU
57 Introduction à PGP PGP - Pretty Good Privacy Application générique destinée à protéger (chiffrer et/ou signer) des fichiers Peut être utilisé pour protéger des s Peut être utilisé par des sociétés aussi bien que des individus Basé sur des algorithmes cryptogtraphiques forts (IDEA, RSA, SHA-1) Disponible gratuitement Version initiale développée par Phil Zimmermann En cours de normalisation dans les standards Internet (RFC 3156) 57 CNAM /EBU
58 PGP : Services Sur les messages Authentification Confidentialité Compression Compatibilité Segmentation et ré-assemblage Gestion des clés Génération, distribution, et révocation de couples de clé publique/privée Génération et transport de clés de session et de vecteurs d initialisation 58 CNAM /EBU
59 Authentification de message Basée sur des signatures Algorithmes supportés : RSA/SHA et DSS/SHA Emetteur hash hash K snd -1 m h σ chif chif Destinataire m h h σ hash hash comparaison comparaison OK / NOK déchif déchif K snd 59 CNAM /EBU
60 Confidentialité de message Chiffrement symétrique en mode CFB avec clé de session et IV aléatoires La clé de session et les IV sont chiffrés avec la clé publique du destinataire Algorithmes supportés : Symétrique : CAST, IDEA, 3DES Asymétrique : RSA, ElGamal Emetteur m Chif. Chif. sy sy prng prng k, iv K rcv Chif. Chif. as as {k, iv} Krcv {m} k 60 CNAM /EBU
61 Compression Appliquée après la signature Suffisamment pour stocker le message en clair et la signature pour vérification ultérieure Possibilité de compresser dynamiquement les messages avant la vérification de signature mais Toutes les implémentations PGP devraient alors utiliser le même algorithme de compression Cependant, différentes versions de PGP utilisent des algorithmes de compression légèrement différents Appliquée avant chiffrement La compression réduit les redondances et rend ainsi la cryptanalyse plus difficile Algorithme supporté : ZIP 61 CNAM /EBU
62 Compatibilité Les messages chiffrés et les signatures peuvent comporter des octets quelconques La plupart des systèmes ne supportent que les caractères ASCII PGP convertit une chaine binaire quelconque en une chaine de caractères ASCII imprimables Conversion radix 64 : 3 blocs de 8 bits deviennent 4 blocs de 6 bits bit value character encoding 6-bit value character encoding 0 A Z 26 a 51 z / (pad) = 62 CNAM /EBU
63 Combinaison des services X := := file file signature? no compress X := := Z(X) Z(X) encryption? no radix radix X := := R64(X) R64(X) yes yes generate generate signature X := := σ(x) σ(x) X generate generate envelop envelop X := :={k} {k} Krcv Krcv {X} {X} k k 63 CNAM /EBU
64 Format d un message PGP session key component signature key ID of K rcv session key k timestamp key ID of K snd leading two octets of hash hash { } Krcv { } Ksnd -1 filename timestamp ZIP { } k R64 message data 64 CNAM /EBU
65 Gestion des clés Un utilisateur peut avoir plusieurs paires de clés privées/publiques Quelle clé privée utiliser pour déchiffrer la clé de session? Quelle clé publique utiliser pour vérifier une signature? Transmettre la clé publique complète à chaque fois n est pas optimal Associer un ID aléatoire à une clé publique alourdirait la gestion des clés L identifiant est constitué des 64 derniers bits de la clé publique Forte probabilité d unicité pour une utilisateur donné 65 CNAM /EBU
66 Génération de nombres aléatoires Nombres aléatoires «vrais» Utilisé pour générer des paires de clés publiques/privées Fournit une source pour initialiser un générateur de nombres pseudo-aléatoire (PRNG) Fournit des données complémentaires pour les PRNG Nombres pseudo-aléatoires Utilisés pour générer des clés de session et de IV 66 CNAM /EBU
67 «Vrais» nombres aléatoires PGP garde en permanence un buffer de 256 octets d aléa A chaque fois que PGP attend une saisie de la part de l utilisateur, il enregistre L heure à laquelle il commence à attendre (32 bits) L heure à laquelle la touche est pressée (32 bits) La valeur de la touche pressée (8 bits) L information enregistrée est utilisée pour générer une clé La clé est utilisée pour chiffrer la valeur courante du buffer d aléa 67 CNAM /EBU
68 Nombres pseudo-aléatoires Basé sur la norme ANSI X9.17 K 1, K 2 DT i 3DES 3DES + 3DES 3DES V i+1 V i + 3DES 3DES R i 68 CNAM /EBU
69 Nombres pseudo-aléatoires dtbuf EE + EE + EE + EE rseed rseed + EE + EE + EE true random bits IV[0..7] K[8..15] K[0..7] Utilisation de CAST-128 au lieu de 3DES avec la clérkey 69 CNAM /EBU
70 Nombres pseudo-aléatoires dtbuf[0..3] = heure courante, dtbuf[4..7] = 0 pre-wash Prendre un hash du message Déjà fait si le message est signé Sinon, utiliser les premiers 4K du message Utiliser le résultat comme clé, un IV nul, et chiffrer (rkey, rseed) previous en mode CFB si (rkey, rseed) previous est vide, le remplir avec du «vrai» aléa Mettre la valeur du résultat dans (rkey, rseed) current post-wash Générer 24 octets supplémentaires comme précédemment mais sans faire de XOR avec des octets de vrai aléa Chiffrer le résultat en mode CFB avec K et IV Mettre le résultat dans (rkey, rseed) previous 70 CNAM /EBU
71 Base des clés privées Utilisée pour stocker les couples clé publique/clé privée d un utilisateur Table où chaque ligne contient les champs suivants : timestamp key ID (indexed) public key encrypted private key user ID (indexed) private key passphrase hash hash enc enc encrypted private key 71 CNAM /EBU
72 Base des clés publiques Utilisée pour stocker les clés publiques des autres utilisateurs Table où chaque ligne contient les champs suivants : timestamp key ID (indexé) public key user ID (indexé, très souvent l adresse ) owner trust signature(s) (avec sa propre clé privée -> autosigné) signature trust(s) key legitimacy 72 CNAM /EBU
73 Gestion de la confiance (1/3) Certificats auto-signés : faible niveau de confiance sur le lien clé publique/identité Chaque utilisateur PGP peut signer les clés publiques d autres utilisateurs Ne le faire que lorsqu on est sûr que la clé publique appartient bien à la bonne personne Procédé type «parrainage» qui renforce la confiance J ai la clé d Alice mais je ne suis pas sûr que ce soit la sienne mais Bob a signé la clé d Alice et je fais confiance à Bob pour avoir vérifié l identité d Alice et je sais que Bob a une clé publique correcte donc je peux probablement être relativement certain que ce sont bien les clés d Alice Possibilité de mettre sur un serveur les certifications faites par un utilisateur Quand un utilisateur télécharge une clé, il récupère également ces certifications 73 CNAM /EBU
74 Gestion de la confiance (2/3) Chaque utilisateur affecte les clés de son magasin local avec un niveau de confiance de son possesseur «owner trust» Unknown (valeur par défaut) None (pas de confiance dans le possesseur) Marginal (confiance limitée) Full (confiance totale) Ultimate (confiance absolue, pour ses propres clés) Confiance dans la signature Calculé par le logiciel Sur la base de certificats locale 74 CNAM /EBU
75 Gestion de la confiance (3/3) Validité de la clé Calculée par le logiciel PGP Si une signature est «ultimate» alors la signature est valide (= 1) Sinon, une somme pondérée est calculée Signature du certificat par des clés «full»a un poids de 1/X Signature du certificat par des clés «marginal»a un poids de 1/Y X et Y sont des paramètres configurables exemple: X=2, Y=4 1 «ultimate», ou 2 «full», ou 1 «full» et 2 «marginal» ou 4 «marginal» pour obtenir une clé valide 75 CNAM /EBU
76 Exemple légitimité de la clé X = 1, Y = 2 G C H B D untrusted / usually untrusted E usually trusted always trusted ultimately trusted (you) signature legitimate F user A I 76 CNAM /EBU L J K M
77 Révocation de clé publique Pourquoi révoquer une clé publique? Compromission (clé privée) re-keying Le possesseur publie un certificat de révocation Format identique à celui d une clé publique Contient la clé publique à révoquer Signé par la clé privée correspondante Publier ce certificat aussi largement et rapidement que possible 77 CNAM /EBU
SSL 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é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é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é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é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é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é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étailWTLS (Wireless Transport Layer Security)
16 WTLS (Wireless Transport Layer Security) Le protocole WTLS (Wireless Transport Layer Security) est un protocole généraliste de sécurisation des échanges sur les liaisons sans fil [WTLS 99]. WTLS s inspire
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étailLe format OpenPGP. Traduit par : Sébastien Person. personseb@yahoo.fr. Matthieu Hautreux. matthieu.hautreux@insa-rouen.fr.
Le format OpenPGP Traduit par : Sébastien Person personseb@yahoo.fr Matthieu Hautreux matthieu.hautreux@insa-rouen.fr Odile Weyckmans odile.weyckmans@insa-rouen.fr Relu et maintenu par : Yvon Benoist benoist@insa-rouen.fr
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é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é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é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étailDivers éléments. Protocoles d'applications. Un agent Utilisateur. MUA - Agents Utilisateurs de Courriel. Simple Mail Transfer Protocol
IUT IUT d'orsay réseaux réseaux Protocoles d'applications Le courrier électronique Divers éléments POP3 IMAP protocole de transport format de l entête, de ses champs, des adresses électroniques standard
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é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é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é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é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é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é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é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é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é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é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é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étailTP 2 : Chiffrement par blocs
USTL - Licence et Master Informatique 2006-2007 Principes et Algorithmes de Cryptographie TP 2 : Chiffrement par blocs Objectifs du TP utiliser openssl pour chiffrer/déchiffrer, étudier le remplissage
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étailManuel des logiciels de transferts de fichiers File Delivery Services
Manuel des logiciels de transferts de fichiers File Delivery Services Editeur La Poste CH SA Technologies de l information Webergutstrasse 12 CH-3030 Berne (Zollikofen) Contact La Poste CH SA Technologies
Plus en détailLes solutions de paiement CyberMUT (Crédit Mutuel) et P@iement CIC. Qui contacter pour commencer la mise en place d une configuration de test?
Les solutions de paiement CyberMUT (Crédit Mutuel) et P@iement CIC Qui contacter pour commencer la mise en place d une configuration de test? CyberMUT Paiement - Paiement CIC Commerce Electronique mailto:centrecom@e-i.com
Plus en détailFTP & SMTP. File Transfert Protocol. Deux applications fondamentales pour le réseau Internet. Un protocole d échange de fichier «au dessus» de TCP :
FTP & SMTP Deux applications fondamentales pour le réseau Internet. File Transfert Protocol Rapide Historique : 1971 : Première version du protocole définit par le M.I.T. 1973 : Première documentation
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étail18 TCP Les protocoles de domaines d applications
18 TCP Les protocoles de domaines d applications Objectifs 18.1 Introduction Connaître les différentes catégories d applications et de protocoles de domaines d applications. Connaître les principaux protocoles
Plus en détailCRYPTOGRAPHIE. Chiffrement par flot. E. Bresson. Emmanuel.Bresson@sgdn.gouv.fr. SGDN/DCSSI Laboratoire de cryptographie
CRYPTOGRAPHIE Chiffrement par flot E. Bresson SGDN/DCSSI Laboratoire de cryptographie Emmanuel.Bresson@sgdn.gouv.fr CHIFFREMENT PAR FLOT Chiffrement par flot Chiffrement RC4 Sécurité du Wi-fi Chiffrement
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étailProtocole SSH-2.0. Tuan-Tu, TRAN. Janvier 2009
Janvier 2009 1 2 Etablissement des clés de session Protection des données échangées 3 Identification par mot de passe Identification par clé publique Identification par hôte 4 Utilisations de Secure Shell
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étailL3 informatique TP n o 2 : Les applications réseau
L3 informatique TP n o 2 : Les applications réseau Sovanna Tan Septembre 2009 1/20 Sovanna Tan L3 informatique TP n o 2 : Les applications réseau Plan 1 Transfert de fichiers 2 Le Courrier électronique
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étailFTP & SMTP. Deux applications fondamentales pour le réseau Internet.
& SMTP Deux applications fondamentales pour le réseau Internet. File Transfer Protocol Protocole d'échange de fichier : envoi / réception de fichiers au dessus de TCP client (machine de l utilisateur)
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é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é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é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é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étailTunnels et VPN. 22/01/2009 Formation Permanente Paris6 86
Tunnels et VPN 22/01/2009 Formation Permanente Paris6 86 Sécurisation des communications Remplacement ou sécurisation de tous les protocoles ne chiffrant pas l authentification + éventuellement chiffrement
Plus en détailSécurité des RO. Partie 6. Sécurisation des échanges. SSL : Introduction. Rappel: Utilités la sécurité à tous les niveaux SSL SSH.
Sécurité des RO Rappel: Utilités la sécurité à tous les niveaux Partie 6 Sécurisation des échanges SSH Application : S-MIME, PGP, Sbox, OTP Présentation Session : SHTTP Transport : SSL, TLS Réseau : authentification
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é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étailInformatique. Les réponses doivent être données en cochant les cases sur la dernière feuille du sujet, intitulée feuille de réponse
Questions - Révision- - 1 er Semestre Informatique Durée de l examen : 1h pour 40 questions. Aucun document n est autorisé. L usage d appareils électroniques est interdit. Les questions faisant apparaître
Plus en détailTrustedBird, un client de messagerie de confiance
TrustedBird, un client de messagerie de confiance Ministère de la défense - DGA / CELAR Laurent CAILLEUX JRES 2009 - NANTES DGA/CELAR 2009 Diapositive N 1 Plan Pourquoi TrustedBird? Concepts de messagerie
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é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é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étailCRYPTOGRAPHIE. Signature électronique. E. Bresson. Emmanuel.Bresson@sgdn.gouv.fr. SGDN/DCSSI Laboratoire de cryptographie
CRYPTOGRAPHIE Signature électronique E. Bresson SGDN/DCSSI Laboratoire de cryptographie Emmanuel.Bresson@sgdn.gouv.fr I. SIGNATURE ÉLECTRONIQUE I.1. GÉNÉRALITÉS Organisation de la section «GÉNÉRALITÉS»
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étailFTPS AVEC UNE APPLIANCE FAST360 EN COUPURE. Table des matières
FTPS AVEC UNE APPLIANCE FAST360 EN COUPURE Table des matières Principes de FTPS... 2 Généralités... 2 FTPS en mode implicite... 2 FTPS en mode explicite... 3 Certificats SSL / TLS... 3 Atelier de tests
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étailCertificats 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étailOWASP Open Web Application Security Project. Jean-Marc Robert Génie logiciel et des TI
OWASP Open Web Application Security Project Jean-Marc Robert Génie logiciel et des TI A1: Injection Une faille d'injection, telle l'injection SQL, OS et LDAP, se produit quand une donnée non fiable est
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étailServeurs de noms Protocoles HTTP et FTP
Nils Schaefer Théorie des réseaux (EC3a) Serveurs de noms Protocoles HTTP et FTP Théorie des réseaux (EC3a) Séance 7 Pourquoi DNS? Internet est une structure hiérarchique et arborescente de réseaux et
Plus en détailProtocoles cryptographiques
MGR850 Hiver 2014 Protocoles cryptographiques Hakima Ould-Slimane Chargée de cours École de technologie supérieure (ÉTS) Département de génie électrique 1 Plan Motivation et Contexte Notations Protocoles
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étailProtocoles d authentification
Sécurité des Réseaux, Master CSI 2 J.Bétréma, LaBRI, Université Bordeaux 1 Protocoles d authentification 1. Authentification simple 2. Authentification mutuelle 3. Clé de session 4. KDC Source 1. Authentification
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étailCryptographie. Master de cryptographie Architectures PKI. 23 mars 2015. Université Rennes 1
Cryptographie Master de cryptographie Architectures PKI 23 mars 2015 Université Rennes 1 Master Crypto (2014-2015) Cryptographie 23 mars 2015 1 / 17 Cadre Principe de Kercho : "La sécurité d'un système
Plus en détailHAUTE DISPONIBILITÉ DE MACHINE VIRTUELLE AVEC HYPER-V 2012 R2 PARTIE CONFIGURATION OPENVPN SUR PFSENSE
HAUTE DISPONIBILITÉ DE MACHINE VIRTUELLE AVEC HYPER-V 2012 R2 PARTIE CONFIGURATION OPENVPN SUR PFSENSE Projet de semestre ITI soir 4ème année Résumé configuration OpenVpn sur pfsense 2.1 Etudiant :Tarek
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étailwww.netexplorer.fr contact@netexplorer.fr
www.netexplorer.fr 05 61 61 20 10 contact@netexplorer.fr Sommaire Sécurité applicative... 3 Authentification... 3 Chiffrement... 4 Traçabilité... 4 Audits... 5 Sécurité infrastructure... 6 Datacenters...
Plus en détailLes Réseaux Privés Virtuels (VPN) Définition d'un VPN
Les Réseaux Privés Virtuels (VPN) 1 Définition d'un VPN Un VPN est un réseau privé qui utilise un réseau publique comme backbone Seuls les utilisateurs ou les groupes qui sont enregistrés dans ce vpn peuvent
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étailLe Passeport Biométrique. Benoit LEGER CISSP ISO 27001-LD
Le Passeport Biométrique Benoit LEGER CISSP ISO 27001-LD Il ne faut pas confondre le vol de titres vierges la contrefaçon (imitation d'un titre officiel) la falsification (modification des données d'un
Plus en détailSIP. Plan. Introduction Architecture SIP Messages SIP Exemples d établissement de session Enregistrement
SIP Nguyen Thi Mai Trang LIP6/PHARE Thi-Mai-Trang.Nguyen@lip6.fr UPMC - M2 Réseaux - UE PTEL 1 Plan Introduction Architecture SIP Messages SIP Exemples d établissement de session Enregistrement UPMC -
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é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étailD31: Protocoles Cryptographiques
D31: Protocoles Cryptographiques Certificats et échange de clés Nicolas Méloni Master 2: 1er semestre (2014/2015) Nicolas Méloni D31: Protocoles Cryptographiques 1/21 Introduction Protocole Diffie Hellman:
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é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étailDéfinition des Webservices Ordre de paiement par email. Version 1.0
Définition des Webservices Ordre de paiement par email Version 1.0 Rédaction, Vérification, Approbation Rédaction Vérification Approbation Nom Date/Visa Nom Date/Visa Nom Date/Visa Historique du document
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étailL envoi d un formulaire par courriel. Configuration requise... 236 Mail Texte... 237 Mail HTML... 242 Check-list... 248
L envoi d un formulaire par courriel Configuration requise... 236 Mail Texte... 237 Mail HTML... 242 Check-list... 248 Chapitre 9 L envoi d un formulaire par courriel L envoi par courriel d informations
Plus en détailIPSEC : PRÉSENTATION TECHNIQUE
IPSEC : PRÉSENTATION TECHNIQUE Ghislaine Labouret Hervé Schauer Consultants (HSC) 142, rue de Rivoli 75001 Paris FRANCE http://www.hsc.fr/ IPsec : présentation technique Par Ghislaine LABOURET (Ghislaine.Labouret@hsc.fr)
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é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é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é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étailCouche application. La couche application est la plus élevée du modèle de référence.
Couche application La couche application est la plus élevée du modèle de référence. Elle est la source et la destination finale de toutes les données à transporter. Couche application La couche application
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étailAccès aux ressources informatiques de l ENSEEIHT à distance
Ecole Nationale Supérieure d Électrotechnique, d Électronique, d Informatique, d Hydraulique et des Télécommunications Accès aux ressources informatiques de l ENSEEIHT à distance Jean-François GINESTE,
Plus en détailProtocoles utilisant des mécanismes d'authentification: TACACS+, RADIUS et Kerberos
Sécurisation des systèmes Protocoles utilisant des mécanismes d'authentification: TACACS+, RADIUS et Kerberos Tarik BOUDJEMAA Sadek YAHIAOUI 2007 2008 Master 2 Professionnel STIC Informatique Sécurisation
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étailSSL/TLS: état des lieux et recommandations
SSL/TLS: état des lieux et recommandations Olivier Levillain Résumé SSL/TLS est un protocole ayant pour but de créer un canal de communication authentié, protégé en condentialité et en intégrité. L'objectif
Plus en détail