RSX112 Sécurité et réseaux

Dimension: px
Commencer à balayer dès la page:

Download "RSX112 Sécurité et réseaux"

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 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étail

Protocole industriels de sécurité. S. Natkin Décembre 2000

Protocole 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étail

Sommaire 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 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étail

Action Spécifique Sécurité du CNRS 15 mai 2002

Action 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étail

Cours 14. Crypto. 2004, Marc-André Léger

Cours 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étail

SSL/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 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étail

Le protocole sécurisé SSL

Le 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étail

WTLS (Wireless Transport Layer Security)

WTLS (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étail

Cryptologie. 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 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étail

Le 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. 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étail

Chapitre 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 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étail

Skype (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 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

La Technologie Carte à Puce EAP TLS v2.0

La 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étail

Sécurité des réseaux IPSec

Sé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étail

Divers éléments. Protocoles d'applications. Un agent Utilisateur. MUA - Agents Utilisateurs de Courriel. Simple Mail Transfer Protocol

Divers é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étail

SSH, le shell sécurisé

SSH, 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étail

La sécurité des réseaux. 9e cours 2014 Louis Salvail

La 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étail

Architectures PKI. Sébastien VARRETTE

Architectures 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étail

Devoir Surveillé de Sécurité des Réseaux

Devoir 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étail

Introduction à 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 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étail

Cryptographie. Cours 3/8 - Chiffrement asymétrique

Cryptographie. 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étail

Le protocole SSH (Secure Shell)

Le 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étail

FORMATION SUR «CRYPTOGRAPHIE APPLIQUEE

FORMATION 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étail

Signature électronique. Romain Kolb 31/10/2008

Signature é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étail

Certificats (électroniques) : Pourquoi? Comment? CA CNRS-Test et CNRS

Certificats (é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étail

Du 03 au 07 Février 2014 Tunis (Tunisie)

Du 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étail

Livre blanc. Sécuriser les échanges

Livre 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étail

TP 2 : Chiffrement par blocs

TP 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étail

SSL. 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. 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étail

Manuel des logiciels de transferts de fichiers File Delivery Services

Manuel 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étail

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?

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? 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étail

FTP & SMTP. File Transfert Protocol. Deux applications fondamentales pour le réseau Internet. Un protocole d échange de fichier «au dessus» de TCP :

FTP & 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étail

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

I.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étail

18 TCP Les protocoles de domaines d applications

18 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étail

CRYPTOGRAPHIE. Chiffrement par flot. E. Bresson. Emmanuel.Bresson@sgdn.gouv.fr. SGDN/DCSSI Laboratoire de cryptographie

CRYPTOGRAPHIE. 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étail

Aristote 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 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étail

Protocole SSH-2.0. Tuan-Tu, TRAN. Janvier 2009

Protocole 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étail

Gestion des Clés. Pr Belkhir Abdelkader. 10/04/2013 Pr BELKHIR Abdelkader

Gestion 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étail

L3 informatique TP n o 2 : Les applications réseau

L3 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étail

Richard 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 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étail

FTP & SMTP. Deux applications fondamentales pour le réseau Internet.

FTP & 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étail

Windows Server 2008 Sécurité ADMINISTRATION ET CONFIGURATION DE LA SECURITE OLIVIER D.

Windows 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étail

EMV, S.E.T et 3D Secure

EMV, 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étail

titre : CENTOS_CUPS_install&config Système : CentOs 5.7 Technologie : Cups 1.3.7 Auteur : Charles-Alban BENEZECH

titre : 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étail

Mieux 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 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étail

Les 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 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étail

Tunnels et VPN. 22/01/2009 Formation Permanente Paris6 86

Tunnels 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étail

Sé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. 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étail

Tunnels. Plan. Pourquoi? Comment? Qu est-ce? Quelles solutions? Tunnels applicatifs ESIL INFO 2005/2006. Sophie Nicoud Sophie.Nicoud@urec.cnrs.

Tunnels. 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étail

La sécurité dans les grilles

La 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étail

Informatique. Les réponses doivent être données en cochant les cases sur la dernière feuille du sujet, intitulée feuille de réponse

Informatique. 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étail

TrustedBird, un client de messagerie de confiance

TrustedBird, 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étail

Public Key Infrastructure (PKI)

Public 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étail

Université de Reims Champagne Ardenne. HTTPS, SSL, SSH, IPSEC et SOCKS. Présenté par : BOUAMAMA Mohamed Nadjib AZIZ Xerin

Université 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étail

Les certificats numériques

Les 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étail

CRYPTOGRAPHIE. Signature électronique. E. Bresson. Emmanuel.Bresson@sgdn.gouv.fr. SGDN/DCSSI Laboratoire de cryptographie

CRYPTOGRAPHIE. 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étail

Gestion des certificats digitaux et méthodes alternatives de chiffrement

Gestion 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

FTPS AVEC UNE APPLIANCE FAST360 EN COUPURE. Table des matières

FTPS 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»

«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étail

Certificats X509 & Infrastructure de Gestion de Clés. Claude Gross CNRS/UREC

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étail

OWASP 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 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étail

Les fonctions de hachage, un domaine à la mode

Les 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étail

Serveurs de noms Protocoles HTTP et FTP

Serveurs 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étail

Protocoles cryptographiques

Protocoles 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étail

Sécurité WebSphere MQ V 5.3

Sé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étail

Protocoles d authentification

Protocoles 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étail

Gestion 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

Gestion 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étail

Cryptographie. Master de cryptographie Architectures PKI. 23 mars 2015. Université Rennes 1

Cryptographie. 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étail

HAUTE 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 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étail

CA 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 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étail

www.netexplorer.fr contact@netexplorer.fr

www.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étail

Les Réseaux Privés Virtuels (VPN) Définition d'un VPN

Les 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étail

La citadelle électronique séminaire du 14 mars 2002

La 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étail

Le Passeport Biométrique. Benoit LEGER CISSP ISO 27001-LD

Le 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étail

SIP. Plan. Introduction Architecture SIP Messages SIP Exemples d établissement de session Enregistrement

SIP. 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étail

Sécurité des réseaux sans fil

Sé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étail

Perso. SmartCard. Mail distribution. Annuaire LDAP. SmartCard Distribution OCSP. Codes mobiles ActivX Applet. CRLs

Perso. 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étail

D31: Protocoles Cryptographiques

D31: 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étail

Utilisation des certificats X.509v3

Utilisation 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étail

Modè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 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étail

Définition des Webservices Ordre de paiement par email. Version 1.0

Dé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étail

1. Présentation de WPA et 802.1X

1. 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étail

L 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 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étail

IPSEC : PRÉSENTATION TECHNIQUE

IPSEC : 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étail

Réseaux Privés Virtuels

Ré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étail

PUBLIC 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é 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étail

Routeur 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. 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étail

Une introduction à SSL

Une 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étail

Couche 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. 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étail

Le protocole RADIUS Remote Authentication Dial-In User Service

Le 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étail

Accès aux ressources informatiques de l ENSEEIHT à distance

Accè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étail

Protocoles utilisant des mécanismes d'authentification: TACACS+, RADIUS et Kerberos

Protocoles 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étail

Sé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 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étail

SSL/TLS: état des lieux et recommandations

SSL/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