janvier - février 2005 version 1.01 1 chapitre 2 - sécurité des contenus et échanges auteurs :...
TRANSCRIPT
1Janvier - Février 2005 Version 1.01
Chapitre 2 - Sécurité des contenus et échanges
Auteurs :
Stéphan GUIDARINI – Consultant Senior
Sébastien DESSE – Expert Réseaux et Sécurité
État de l’art de la sécurité informatique
2Janvier - Février 2005 Version 1.01
SommaireSécurité des Contenus & Échanges
Introduction à la cryptographie
Utilisation de la cryptographie
Les protocoles
Les PKI
La réglementation
3Janvier - Février 2005 Version 1.01
Introduction à la cryptographie
Terminologie
Chiffrement à clefs symétriques
Chiffrement à clefs asymétriques
Fonctions de hachage
Longueur des clefs
4Janvier - Février 2005 Version 1.01
Terminologie
Cryptologie = Cryptographie + Cryptanalyse
Chiffrement, Déchiffrement et décryptement:
Texte clair Texte clair
@[+t6`è0à#értdTexte chiffré
Cryptogramme@[+t6`è0à#értd
Texte clair
Chiffrement Déchiffrement
Décryptement ou décryptage
5Janvier - Février 2005 Version 1.01
Cryptographie : Services
Confidentialité
Intégrité
Authentification
Non-répudiation
Authenticité = Authentification + intégrité
6Janvier - Février 2005 Version 1.01
Cryptographie : Mécanismes
Construits au moyen d’outils cryptographiques :
Chiffrement Protocoles d’authentification mutuelle Scellement et signature
7Janvier - Février 2005 Version 1.01
Confidentialité et chiffrement
Deux grandes familles Algorithmes symétriques ou à clef secrète
• Relativement rapide• Utilisés pour le chiffrement de données
Algorithmes asymétriques ou à clef publique• Nécessite beaucoup de ressources• Utilisés pour les échanges de clefs• Utilisés pour la signature
8Janvier - Février 2005 Version 1.01
Chiffrement à clef symétrique
Clef de chiffrement = Clef de déchiffrement La clef doit rester secrète La méthode de distribution de clef est cruciale
9Janvier - Février 2005 Version 1.01
AlgorithmesAlgorithme de chiffrement de flux
« Stream cipher » agit sur 1 bit à la fois RC4 et RC5
• longueur de clef variable (128 bits en général)
Algorithmes de chiffrement par blocs « Block cipher » agit sur des blocs de données (généralement 64 bits) DES Data Encryption Standard (56 bits + 8 de parité = 64 bits) 3DES (EDE : Encrypt-Decrypt-Encrypt)
• 3 clefs distinctes (eff. 168 bits) ou 2 clefs distinctes (eff. 112 bits) IDEA - International Data Encryption Algorithm (128 bits)
• Devrait s’imposer en lieu et place de 3DES dont les performances ne sont plus satisfaisantes et dont la fiabilité commence à être mise en doute
CAST (128 bits) Blowfish (longueur de clef variable –> 448 bits) AES – Advanced Encryption Standard (128, 192, 256 bits)
• Un autre remplaçant potentiel de 3DES dont l’utilisation est de plus en plus répandue
10Janvier - Février 2005 Version 1.01
Cryptographie à clef publique
Diffie & Helman 1976 Découvert par l’armée anglaise 1970
RSA 1978 dérive des travaux de Diffie-HelmanBasée sur des problèmes difficiles à résoudre
Logarithme discrets Factorisation de grand nombres
Clefs de chiffrement et de déchiffrement distinctes Connaître la clef publique ne permet pas de retrouver la clef secrète
correspondante
Algorithmes trop gourmands en ressource pour être utilisés pour chiffrer les données
Utilisés seulement pour l’échange de clefs et la signature
11Janvier - Février 2005 Version 1.01
Diffie-Helman & RSA
Diffie-Helman Génération d’un couple de clefs publique/privée à chaque
session La clef secrète est une combinaison de la clef publique du
tiers et de sa clef privée• Apub = ga mod n ; Bpub = gb mod n => C = gab mod n …
Pas d’authentification
RSA Génération d’un couple de clefs « une fois pour toutes » Transport d’une clef secrète chiffrée avec la clef publique du
destinataire Authentification
12Janvier - Février 2005 Version 1.01
Cryptographie à clef publiqueChiffrement
Chiffrement Clef publique utilisée pour le chiffrement
• Seul le détenteur de la clef privée peut déchiffrer
13Janvier - Février 2005 Version 1.01
Cryptographie à clef publiqueSignature
Signature Clef privée utilisée pour le chiffrement
• Seul son détenteur peut chiffrer• Tout le monde peut déchiffrer
14Janvier - Février 2005 Version 1.01
Exemple
15Janvier - Février 2005 Version 1.01
Longueur des clefs
Longueur clef symétrique != Longueur clef asymétrique
Les algorithmes reposent sur des principes différents et utilisent donc comme clef des éléments présentant des caractéristiques (dont la longueur) différentes
Clefs symétriques Clefs asymétriques
64 bits 512 bits
80 bits 1024 bits
112 bits 2048 bits
128 bits 3072 bits
16Janvier - Février 2005 Version 1.01
Combien de temps pour casser une clef ?
17Janvier - Février 2005 Version 1.01
Fonctions de hachage
Utilisation Contrôle d’intégrité Signature Scellement
Fonctionnement Convertit une chaîne de longueur variable en une empreinte
de taille inférieure et généralement fixe Fonctionnement à sens unique (one-way function)
• Facile à calculer, difficile à inverser• Il est très difficile de créer deux messages différents
ayant la même empreinte
18Janvier - Février 2005 Version 1.01
Hachage - Algorithmes
SHA (Secure Hash Algorithm)SHA-1 (1994) – empreinte de 160 bits
• Corrige une faille (secrète) de SHA • Considéré plus sûr que MD5
SHA-2 (2000) – empreinte de 256, 384 et 512 bits• Empreinte plus grande
MD5 (Message Digest 5) Empreinte de 128 bit Le plus répandu
19Janvier - Février 2005 Version 1.01
Utilisation de la cryptographie
ChiffrementDonnées (Clefs symétriques)Clefs (Clefs publiques)
Scellement (Hachage+Clef symétriques)
Signature (Hachage+Clef pub/privée)
Authentification (Clefs publiques/privées)
Échanges de clefs (DH)
Certificats Sujet traité dans la section PKI…
20Janvier - Février 2005 Version 1.01
Chiffrement
Service Confidentialité
Algorithmes à clefs symétriquesAlgorithmes de chiffrement de flux
• RC4, RC5, …Algorithmes de chiffrement par block
• DES, 3DES, AES, …
21Janvier - Février 2005 Version 1.01
Scellement
ServicesIntégrité des donnéesAuthentification de l’expéditeurDifférent de la signature car ne fournit pas
le service de non répudiation
Fonctionnement Générer un sceau (code d’authentification)
• Aussi appelé MAC : Message Authentication Code Chiffrer le sceau
22Janvier - Février 2005 Version 1.01
Scellement (2)
Dans la pratiqueFonction de hachage utilisée avec une clef
secrète• Keyed-MAC (Keyed-SHA-1 ou Keyed-MD5)
23Janvier - Février 2005 Version 1.01
Signature
Services Intégrité + Authentification Non répudiation
Fonctionnement Chiffrement d’un sceau à l’aide de la clef privée de l’expéditeur
Dans la pratique Fonction de hachage + clef privée de l’expéditeur
MD5-RSA, SHA-1-RSA, …
24Janvier - Février 2005 Version 1.01
Authentification
Basé sur la cryptographie à clefs publiques RSA
Méthode A chiffre un secret avec la clef publique de B B déchiffre ce secret avec sa clef privée B chiffre ce secret avec la clef publique de A A déchiffre le message avec sa clef privée Si le secret reçu est égal au secret envoyé A à authentifié B et B à
authentifié A.
25Janvier - Février 2005 Version 1.01
Échange de clefs
Diffie-Helman Diffie-Helman permet de générer une clef de session sans
que celle-ci ne transite• La durée de vie de la clef est <= à la durée de la
session La clef de session permet l’échange de clefs de chiffrement
secrète et partagée• La durée de vie de cette clef est courte
RSA Échange régulier de clefs de chiffrement secrète et
partagée Transport de la dite clef chiffrée avec la clef publique (RSA)
du destinataire
26Janvier - Février 2005 Version 1.01
En résumé
Cryptographie
A clef partagée A clef publique
Flux
RC4, RC5
Blocks
DES, IDEA, AES
Services
Confidentialité, Authentification*
Diffie-Helman RSA
Services
Confidentialité*, Intégrité, Authentification, Non répudiation*
27Janvier - Février 2005 Version 1.01
Conclusion
Avantages Inconvénients
Cryptographie à clefs secrètes /
symétriques
+ Rapidité de traitement
+ Relativement sûr
- Protection et stockage de la clef secrète- Répudiation possible- Pas d’authentification
Cryptographie à clefs publiques /
asymétriques
+ Permet la signature
+ Permet l’authentification
+ Non répudiation
+ Permet la transmission sur un canal peu sûr d’une clef de chiffrement
- Protection et stockage de la clef privée- Lenteur de la procédure de déchiffrement
28Janvier - Février 2005 Version 1.01
Les protocoles
Niveau OSI But Protocoles
7
ApplicationSécuriser les échanges entre applications (ex : mail)
-HTTPS-SMIME / PGP / PKI
4
Transport
Sécuriser les informations indépendamment du réseau et des applications
-SSL/TLS
3
RéseauApporter des mécanismes de sécurité aux réseaux IP
-IPSEC
2
Liaison de donnéesChiffrer les liaisons PPP -PPTP et L2TP (PPTP+L2F)
29Janvier - Février 2005 Version 1.01
IPsec
IPSEC (IP Security Protocol) Introduction et présentation Les utilisations Fonctionnement et Protocoles Les restrictions
30Janvier - Février 2005 Version 1.01
IPsec – Introduction
IPSEC (IP Security Protocol) Norme définissant une extension de sécurité pour le protocole IP
(IETF – 1992 / RFC 1995 - 1998)• IPv6 est à l’origine IPsec (obligatoire dans IPv6) • IPsec à été porté sur IPv4 où il est optionnel
Permet la création de Réseau Privés Virtuels et la sécurisation des échanges au niveau IP
• Mise en œuvre possible sur tous les équipements réseau• Moyen de protection unique pour tous les échanges de
données sur les réseaux IP
31Janvier - Février 2005 Version 1.01
IPsec - Présentation
Basé sur des mécanismes cryptographiques Sécurité élevée si les algorithmes sont forts Modulaire et ouvert à de nouveaux algorithmes
Services Confidentialité Authentification Intégrité des données Protection contre le rejeu
32Janvier - Février 2005 Version 1.01
Les utilisations
Entre deux passerelles de sécurité VPN LAN-to-LAN, connexion de sites
distants via le réseau Internet Avec un partenaire …
Entre une machine et une passerelle de sécurité
Accès distants via Internet …
Entre deux machines Communiquant via un réseau non sûr Entre un client et un serveur lors d’échange
d’informations sensibles …
Internet
Siège
Agence
VPN
Serveur
VPN
Internet
Siège Nomade
VPN
33Janvier - Février 2005 Version 1.01
Fonctionnement et protocoles
IPsec fait appel à deux mécanismes AH (Authentication Header)
• Intégrité et Authentification des paquets IP• Ajout d’un champ au paquet IP
ESP ( Encapsulating Security Payload)• Confidentialité• Tout comme AH, ESP peut assurer l’authenticité• Création d’un nouveau paquet IP
Pour chaque protocoles (AH et ESP) deux modes sont déclinés
Tunnel et Transport
34Janvier - Février 2005 Version 1.01
Authentication Header (AH)
Services Authentification et Intégrité Protection contre le rejeu
• Option, nécessite IKE pour l’init. des numéros de séquence
Identification du protocole Champ « protocol type » de IP = 51
35Janvier - Février 2005 Version 1.01
AH – Fonctionnement (1)
Calcul des données d’authentification (Integrity Check Value) à partir des champs invariants du datagramme IP final
Les champs susceptibles de varier sont considérés comme nuls.• IPv4 : TOS, TTL, Checksum, …• IPv6 : TOS, IP version, Hop limit, …
Les champs SPI et numéro de séquence de l’entête AH sont inclus dans le calcul
L’ICV peut être une signature ou un code d’authentification faisant intervenir une clef
Dans la pratique, pour des raisons de performance ce sont les codes d’authentification (MAC) qui sont utilisés
36Janvier - Février 2005 Version 1.01
AH – Fonctionnement (2)
Les algorithmes HMAC-MD5, HMAC-SHA-1 (obligatoires) KPDK-MD5, DES-HMAC, …
37Janvier - Février 2005 Version 1.01
AH – Tunnel / Transport
38Janvier - Février 2005 Version 1.01
AH - Remarques
Le destinataire vérifie l’authenticité du datagramme en effectuant les mêmes opérations que l’émetteur et en comparant les données d’authentification
L’absence de confidentialité permet d’utiliser ce protocoles dans des pays où la réglementation est contraignante
Explique (en partie) la présence de deux protocoles distincts (AH et ESP)
39Janvier - Février 2005 Version 1.01
Encapsulating Security Payload (ESP)
Services Intégrité et authentification (comme AH) Protection contre le rejeu (option) Confidentialité
• Confidentialité et authenticité sont configurés indépendamment.
• Il est possible de ne pas mettre en œuvre les mécanismes assurant l’authenticité (mode NULL).
• Il est possible de ne pas mettre en œuvre les mécanismes de chiffrement (mode NULL)
Identification du protocole Champ « potocol type » de IP = 50
40Janvier - Février 2005 Version 1.01
ESP- Fonctionnement (1)
41Janvier - Février 2005 Version 1.01
ESP – Fonctionnement (2)
Les données sont chiffrées et encapsulées entre une entête et un « trailer » ESP
L’authentification fonctionne sur le même principe que pour AH cependant :
L’authentification n’inclus pas l’en-tête IP• Le mode tunnel permet cependant d’avoir l’entête d’origine
chiffrée et authentifiée L’authentification inclus les données chiffrées évitant ainsi d’avoir à
déchiffrer des données non valides
Le champ « en-tête suivant » permet de faire suivre une en-tête AH combinant ainsi AH + ESP
42Janvier - Février 2005 Version 1.01
ESP – Transport / Tunnel
43Janvier - Février 2005 Version 1.01
Composants de IPsec
DLL
IP / IPSEC
Transport
Sockets
IKE Application
SAD
SPD UDP port 500
Ajout, suppression, Modification
Consultation
Consultation
Consultation
Dem
and
e SA
44Janvier - Février 2005 Version 1.01
Security Association (SA)
Structure de données servant à stocker les paramètre de sécurité associés a une connexion sécurisée par IPsec
Une SA est unidirectionnelle• Pour protéger une communication il faut 2 SA(s)
Une SA est identifiée par 3 composantes• L’adresse de destination du datagramme• Le SPI (Security Parameter Index)• L’identifiant de protocole (ESP=50 ou AH=51)
Les SA sont stockées dans une base de données• SAD (Security Association Database)
45Janvier - Février 2005 Version 1.01
ISAKMP / IKE
ISAKMP ( Internet Security Association and Key Management Protocol)
Protocole de gestion des SA et des clefs Inutilisable seul, ISAKMP définit un cadre générique
IKE (Internet Key Exchange) Protocole d’authentification et de gestion des paramètres de
sécurité de IPsec• Négocie les paramètres de sécurité• Authentifie les tiers
Pre-shared key, Digital Certificate• Échange les clefs de session
ISAKMP + SKEME + Oakley = IKE SKEME et Oakley sont des protocoles d’échange de clefs
utilisant (optionnellement) Diffie-Helman
46Janvier - Février 2005 Version 1.01
Security Policy Database (SPD)
Contient une liste de paramètres permettant de déterminer si les paquets sont concernés par IPSec, si ils sont autorisés à passer ou si il doivent être rejetés
une entrée contient :• @source, @dest, protocole, Port source, Port destination,
paramétres IPsec, inbound SA, outbound SA, …
La SPD est configurée par l’administrateur, un utilisateur ou une application.
47Janvier - Février 2005 Version 1.01
Fonctionnement
Flux entrants Le paquet est un paquet IPsec ? A quelle SA fait il référence (SPI) ? Consultation de la SAD pour connaître les paramètres,
authentification et/ou déchiffrement Consultation de la SPD pour s’assurer que le paquet est en accord
avec la politique de sécurité
Flux sortants Consultation de la SPD pour savoir si le paquet est à traiter Récupération des caractéristiques de la SA dans la SAD
• Si la SA n’existe pas, demande à IKE l’établissement d’une nouvelle SA
48Janvier - Février 2005 Version 1.01
Secure Sockets Layers
Couche de sockets sécurisée Procédé de sécurisation des transactions effectuées via Internet, Indépendant du protocole (HTTP, FTP, POP ou IMAP), Couche supplémentaire, permettant d'assurer la sécurité des
données, située entre la couche application et la couche transport SSL est transparent pour l'utilisateur (rien n’a installer sur le poste
de travail,SSL appartenait au départ à Netscape puis a été racheté par l'IETF
(Internet Engineering Task Force)• TLS (Transport Layer Security) utilisé dans la sécurisation des
réseaux wifi
49Janvier - Février 2005 Version 1.01
Secure Sockets Layers (2)
Fonctionnement SSL repose sur un procédé de cryptographie par clef publique
• Dans un premier temps, le client, se connecte au site sécurisé par SSL et lui demande de s'authentifier. Le client envoie également la liste des cryptosystèmes qu'il supporte, triée par ordre décroissant de la longueur des clés.
• Le serveur a réception de la requête envoie un certificat au client, contenant la clé publique du serveur, signée par une autorité de certification (CA), ainsi que le nom du cryptosystème le plus haut dans la liste avec lequel il est compatible (la longueur de la clé de chiffrement - 40 bits ou 128 bits - sera celle du cryptosystème commun ayant la plus grande taille de clé)
50Janvier - Février 2005 Version 1.01
VPN SSL
Le VPN SSL Offre la possibilité de se connecter au réseau de l'entreprise de
manière sécurisée à partir de n'importe quel navigateur web, Les principaux avantages du VPN SSL :
• Pas de coûts d'acquisition de clients VPN, et des coûts d'installations et de maintenances réduits
• Moins sensible au NAT que le protocole IPSec
51Janvier - Février 2005 Version 1.01
VPN SSL (2)
Exemple de mise en oeuvre
52Janvier - Février 2005 Version 1.01
Secure HTTP (S-HTTP)
Protocole HTTP sécurisé Procédé de sécurisation des transactions HTTP
reposant sur une amélioration du protocole HTTP, S-HTTP procure une sécurité basée sur des messages
au-dessus du protocole HTTP• Marquage individuellement des documents HTML à
l'aide de "certificats« S-HTTP est très fortement lié au protocole HTTP et
crypte individuellement chaque message contrairement à SSL qui est indépendant de l’application
Les infrastructures à clefs publiques
54Janvier - Février 2005 Version 1.01
Introduction aux PKI
ICP (Infrastructure à Clé Publique) Assure la sécurité des transactions électroniques et l’échange de
renseignements sensibles grâce à des clés cryptographiques et des certificats
Fait appel à quatre éléments• Une entité appelée « porteur de certificat »
Peut être une personne, une organisation, un équipement
• Une clef privée• Une clef publique• Un certificat numérique
PGP, X.509 ou autre
55Janvier - Février 2005 Version 1.01
Les infrastructures à clefs publiques
PGP (Pretty Good Privacy®) Certificats Modèle de confiance Algorithmes Distribution Utilisation
PKIX – infrastructure X.509 Certificats Algorithmes Architecture Utilisations
56Janvier - Février 2005 Version 1.01
Pretty Good Privacy (PGP)
57Janvier - Février 2005 Version 1.01
PGP – Présentation (1)
Crée par Phil Zimmerman en 1991
1991 aux États-Unis, le projet de loi 266 du Sénat fait réagir le futur auteur de PGP
"La recommandation du Sénat est que les fournisseurs de services de communications électroniques et les fabricants d'équipements de communication électronique devront s'assurer que les systèmes de communication permettent au gouvernement d'obtenir le contenu en clair des communications vocales, des données, et des autres communications dans les cas prévus par la loi"
58Janvier - Février 2005 Version 1.01
PGP – Présentation (2)
PGP à été conçu comme un outil de résistance dans le but de préserver la vie privée des individus
D’abord libre PGP à été ensuite vendu à la société Network Associates Inc. (NAI)
Depuis beaucoup reprochent à la société d’avoir transformé PGP en un outil marketing pour les entreprise
Des erreurs de programmation graves ont remis en cause la confiance qu’avaient les utilisateurs dans l’implémentation PGP de NAI
• NAI abandonne PGP desktop (et son développement), cependant PGP reste au catalogue de McAfee (filiale de NAI)
• Naissance d’une version libre de PGP au travers d’un groupe de travail de l’IETF « OpenPGP » afin de faire de PGP un standard libre
59Janvier - Février 2005 Version 1.01
PGP – Présentation (3)
Les implémentations de OpenPGPL' Alliance OpenPGP
• Dirigée par Phil Zimmerman , qui créa le logiciel PGP en 1991, puis participa aux compagnies PGP Inc. et NAI/PGP Security Inc. (qu'il a quitté à la fin 2000), l‘Alliance OpenPGP cherche à développer le standard de chiffrement du même nom
GnuPG (GPG)• Programme distribué sous licence GNU GPL par la Free
Software Foundation, GnuPG est la version "logiciel libre" de PGP® et compatible avec lui
60Janvier - Février 2005 Version 1.01
Les certificats PGP
Composition Version PGP Clé publique du porteur
• RSA, DSA (Digital Signature Algorithm) Informations sur le porteur
• Nom, identifiant, photo, … Signature du porteur
• Signature de la clé publique avec la clé privée associée dans le certificat (self signature)
Période de validité du certificat• Date de début et date d’expiration
Algorithme de chiffrement préféré• CAST, IDEA ou 3DES
Les algorithmes de chiffrement faibles ne sont pas supportés
61Janvier - Février 2005 Version 1.01
Les certificats PGP
62Janvier - Février 2005 Version 1.01
Exemple de certificat PGP
63Janvier - Février 2005 Version 1.01
Modèles de confiance (1)
3 modèles de confiance « Direct Trust »
• Clef/Certificat obtenue via un canal sûr • Entité clairement identifiée
« Hierarchical Trust »
La confiance en un certificat dépend de la confiance que l’on à en l’autorité de certification qui a signé le certificatmodèle X.509 - PKIX
64Janvier - Février 2005 Version 1.01
Modèles de confiance (2)
3 modèles de confiance (suite) « Web of trust »
• Modèle adopté par PGP• Reprend les concepts des deux modèles précédents
La confiance peut être établie directement La confiance peut être établie entre deux tiers si ils ont tous les deux confiance en
une entité commune (directement ou non) Ce concept se rapproche des mécanisme de la vie, les amis de mes amis sont mes amis…
• Sur chaque clefs sont stockées Une information indiquant si la clef est considérée valide ou non Le degré de confiance placé dans cette clef
Complete Trust, Marginal Trust, Notrust
• PGP défini 4 degrés de validité d’un certificatUltimate : l’utilisateur possède le couple clef publique / privée Valid : une signature « Complete Trust »Marginaly Valid : deux signatures « Marginal Trust »Invalid
65Janvier - Février 2005 Version 1.01
PGP – Les algorithmes
Clef publique / privée RSA, DSA, ElGamal
• Varie suivant les implémentations
Chiffrement IDEA (128 bits), 3DES, …
• Varie suivant les implémentations• La clef de chiffrement est envoyée dans le message
chiffrée avec la clef publique du destinataire
Signature MD5, …
66Janvier - Février 2005 Version 1.01
PGP - Distribution des clefs
Envoi direct
Publication sur un serveur de clefs PGP
67Janvier - Février 2005 Version 1.01
PGP - Remarques
Ne pas oublier que la clef publiée doit avoir été signée par une entité en laquelle vos interlocuteurs ont confiance
En cas de divulgation de la clef privée révoquer immédiatement la clef publique
En cas de perte de la clef privée Rien à faire Pas de révocation possible !
68Janvier - Février 2005 Version 1.01
PGP – Utilisations
Messages électroniques (e-mail) Chiffrement Signature
Fichiers Chiffrement Signature
69Janvier - Février 2005 Version 1.01
Public Key Infrastructure – X(PKIX)
70Janvier - Février 2005 Version 1.01
PKIX - Présentation
Groupe de travail de l’IETF – 1995
Travail sur le développement d’une infrastructure à clé publique basée sur les certificats X.509
Définition du format des certificats X.509v3 et des listes de révocation
Définition des protocoles de publication et de révocation Définition du format des échanges entre les différentes entité
de la PKI Définition du cadre d’utilisation et des usages
71Janvier - Février 2005 Version 1.01
PKIX – Vocabulaire
End-Entities (EE) Utilisateur Final
Digital Certificate (X.509v3) Certificat numérique
Certification Authority (CA) Autorité de certification qui signe les certificats et en assure donc
l’authenticité
Registration Authority (RA) Reçoit et valide les demandes de certificat avant de les transmettre à
l’autorité de certification (CA)
Certificate Repository (CR) Stocke et publie les certificats (X.509)
Certificate Revocation List (CRL) Liste des certificats révoqués, la CRL se situe souvent sur le serveur
de publication (CR)
72Janvier - Février 2005 Version 1.01
Les certificats X.509
Composition Version du certificat (v1, v2 ou V3) La clef publique du porteur Le numéro de série du certificat
• C’est ce numéro qui apparaît dans les listes de révocation Identifiant du porteur « Distinguished Name » (DN)
• Composé de plusieurs section Common name, Email, Organizationnal Unit, Organization, State/Province,
Country Ex : CN=Sebastien Desse, OU=Intégration, O=Company Inc., C=FR
La période de validité du certificat Le nom (X.500) du signataire du certificat (CA) La signature de l’autorité de certification (CA) L’algorithme utilisé pour la signature
73Janvier - Février 2005 Version 1.01
Les certificats X.509
74Janvier - Février 2005 Version 1.01
Exemple de certificat X.509
75Janvier - Février 2005 Version 1.01
PKIX - Le modèle de confiance
76Janvier - Février 2005 Version 1.01
PKIX - Les algorithmes
Clef publique / privée Principalement RSA, DSA, …
Signature MD5, SHA-1, …
Publication LDAPv1, LDAPv2
Chiffrement DES, 3DES, …
• Notamment pour le chiffrement de la Bi-Clef du porteur
77Janvier - Février 2005 Version 1.01
PKIX- Schéma fonctionnel
78Janvier - Février 2005 Version 1.01
PKIX – Demande de certificat
Internet
Annuaire de publicationListe de révocation (CRL)
Autorité de Certification(CA)
Clé Privée del'organisme de
certification
Autorité d'enregistrement(RA)
Utilisateur
1
4
3
2
79Janvier - Février 2005 Version 1.01
PKIX - Architecture
80Janvier - Février 2005 Version 1.01
PKIX – Fonctionnalités
Établissement d’une confiance commune à un groupe de certificats Mise en pratique des politiques de certification Enregistrement des utilisateurs Génération des clés (optionnel) Certification des clés publiques Gestion de la durée de vie des certificats et des clés Archivage des certificats Renouvellement des clés et des certificats Recouvrement des clés de chiffrement symétriques (optionnel) Publication et accessibilité des certificats Vérification des certificats et des signatures Révocation des certificats (CRL) Gestion des co-certificats Horodatage Journalisation
81Janvier - Février 2005 Version 1.01
PKIX - Utilisations
La réglementation en matière de cryptographie
83Janvier - Février 2005 Version 1.01
La réglementation
Le DCSSI : www.scssi.gouv.fr Ex SCSSI
Les textes
Les finalités
Les régimes
Synthèse de la réglementation
A l’étranger
84Janvier - Février 2005 Version 1.01
Le DCSSI
Direction Centrale de Sécurité des Systèmes d’Information
Organisme qui examine les demandes d’autorisation des moyens et prestations cryptologiques
Dépend directement du premier ministre La décision d’agrément relève du Premier Ministre (après
consultation des ministères concernés) L’agrément est lié à l’acceptation d’un cahier des charges Il est délivré pour 4 ans renouvelables
85Janvier - Février 2005 Version 1.01
Les textes
Loi n° 90-1170 du 29 décembre 1990 sur la réglementation des télécommunications
Décret no 99-200 du 17 mars 1999 définissant les catégories de moyens et de prestations de cryptologie dispensées de toute formalité préalable
Décret no 99-199 du 17 mars 1999 définissant les catégories de moyens et de prestations de cryptologie pour lesquelles la procédure de déclaration préalable est substituée à celle d'autorisation
86Janvier - Février 2005 Version 1.01
Les finalités
Utilisation Générale (tout le monde) Collective (pour une catégorie d’utilisateurs) Personnelle
Fourniture gratuite, location ou vente
Exportation Libre en CEE – Réglementée hors CEE
Importation Libre pour les produits provenant de CEE – Réglementée pour les
autres
87Janvier - Février 2005 Version 1.01
Les régimes
Libre : Dispense de formalité préalable Utilisation/Fourniture/Importation/Exportation libres
Déclaration A la DCSSI au mois 1 mois à l’avance 2 types de déclaration
• simplifiée / non simplifiée
Autorisation A la DCSSI qui à 4 mois pour répondre
• l’absence de réponse équivaut à un agrément
88Janvier - Février 2005 Version 1.01
Synthèse de la réglementation
89Janvier - Février 2005 Version 1.01
A l’étranger
Liberté totale Tous les pays européens à l’exception de la France et la
Russie, et plus généralement tous les pays démocratiques
Liberté dans le pays Les Etats-Unis où de fortes restriction existent à
l’exportation
Interdiction sauf autorisation spéciale La France, la Russie, l’Iran, l’Irak et Singapour
Interdiction absolue Dans les dictatures en général
90Janvier - Février 2005 Version 1.01
Conclusion
La sécurité des échanges est sur le point d’arriver à maturité, seule la législation reste un frein à la généralisation du chiffrement même si une prise de conscience à été récemment opérée.
La signature électronique quand à elle se généralisera probablement avec l’arrivée des infrastructures à clefs publiques et la généralisation de l’utilisation des certificats