Vers une infrastructure de gestion de clés pour Rennes 1

1. Vers une infrastructure de gestion de clés pour Rennes 1 Signature et chiffrement sont à la mode • Qu’est-ce c’est ? • Pourquoi ? • Comment ?

2. Chiffrement symétrique 1/2 • crypt(key,crypt(key,msg))=msg message cryptogramme message cryptogramme

3. Chiffrement asymétrique • Deux clefs fabriquées ensemble et qui respectent : • Ce qui est chiffré avec une des clés ne peut être déchiffré que par l’autre clef. crypt(key1,crypt(key2,msg))=msg • La connaissance d’une des clés ne permet pas de déduire l’autre.

4. Chiffrement asymétrique • On décide arbitrairement de rendre publique une des clefs, l’autre est privée. • Confidentialité : on chiffre avec la clef publique du destinataire, seul le titulaire de la clef privée associée à la clef publique peut déchiffrer. • Signature : on chiffre une empreinte du message avec la clef privée de l’émetteur. Cette empreinte peut être déchiffré et recalculée par quiconque avec la clef publique de l’émetteur.

5. Chiffrement symétrique Chiffrement asymétrique Clé pub(destinataire) déchiffrement symétrique déchiffrement asymétrique Clé priv(destinataire) RAND

6. empreinte Chiffrement asymétrique empreinte déchiffement asymétrique Clé priv(émetteur) Clé pub(émetteur)

7. Chiffrement asymétrique PB : Tout repose sur la confiance dans la provenance de la clef publique ? • Si celui qui forge une signature a forgé la clef publique de sa victime ? • Autrement dit si celui qui souhaite écouter les messages de votre correspondant vous a remis une fausse clef publique pour cette personne ? • Exemple SSH

8. Certificat X509 • Solution : une autorité est chargée de signer les clefs publiques : elle chiffre (avec sa clef privée) une empreinte de : • L’identité de son titulaire, personne, serveur ou application (Distinguished Name of Subject) • La clef publique • Les informations relatives à l’usage de cette clef, (période de validité, type des opérations possibles, etc). • L’ensemble est appelé certificat X509. Les certificats X509 font l’objet d’une norme : ITU-T X509 international standard V3 1996, RFC2459

9. Certificat X509 • On s’assure de la provenance d’une clef publique en vérifiant la signature qui y a été apposée à l’aide de la clef publique de l’autorité de certification (CA). • Plus besoin de faire directement confiance à toutes les clefs publiques en circulation mais seulement à celles des autorités de certification.

10. Période De Validité Attributs Nom de l’AC Signature De l’AC Certificat X509 Le certificat établit un lien fort entre le nom (DN) de son titulaire et sa clé publique Clef publique Nom

11. Les usages • Messagerie S/MIME : signature (certificat de l’émetteur) et/ou chiffrement (certificat du destinataire) • SSL ou TLS : en particulier HTTPS pour chiffrer les sessions du client et authentifier le serveur. Plus rarement authentifier le client. • SSL POPS, IMAPS, LDAPS, SMTP/TLS, … • VPN et IPsec

12. Applications • Applications de confiance (applet JAVA, pilote Windows XP, …) • Sécurisation des processus « web services » en particulier les serveurs d’authentification (SSO) • Horodatage • Signature • E-commerce • Dématérialisation de procédure administrative (Workflow) • E-Vote

13. SSL: Secure socket Layer • A ce jour, probablement le domaine d’application le plus utilisé. • Utiliser une couche avec chiffrement et authentification au dessus de TCP/IP • Applicable à toutes les applications sur TCP (sans réécriture de celles-ci)

14. Principes généraux de SSL HTTP POP IMAP LDAP HTTP POP IMAP LDAP Communication sécurisée X509 X509 SSL SSL TCP TCP IP IP

15. Protéger les clefs privées • module de chiffrement du navigateur (netscape) ou du système (windows NT + IE). En général 3DES • Supports de clés cryptographique : token USB, Cartes à puce (personnalisables mais impose un lecteur)

16. Cartes à puce et certificats • Il existe toute sorte de cartes à puce, certaines extrêmement sophistiquées. • Certaines peuvent générer elle même un bi-clef. Dans ce cas la clef privée ne quitte jamais la carte à puce. • Une API (PKCS11 ou MS Crypto API) permet d’accéder à des fonctions de signature/chiffrement sans accéder à la clé elle-même.

17. Objectifs de l’IGC • La technologie est relativement simple mais le déploiement est réputé très lourd : • L’enjeu est de formaliser le degré de confiance requis pour mettre en œuvre le niveau de sécurité qui en découle. • Prouver un niveau de sécurité est plus difficile que de mettre en œuvre celui-ci.

18. Les services de l’IGC • L’émission de certificat n’est pas le seul service de l’IGC • vérifie l’identité du titulaire lors de l’émission de certificat • publie le certificat, • assure le renouvellement, • révoque les certificats invalidés, • assure parfois le recouvrement de la clef privée.

19. Révocation • Accepteriez vous d’utiliser une carte bancaire si vous ne pouviez par y faire opposition, même en cas de vol ? • Les CRL : la liste des certificats révoqués, liste signée par la CA • Mal implémenté dans les navigateurs • Pas encore de CRL incrémentale. • Alternative : OCSP • La révocation est une limite théorique au modèle des PKIs.

20. Architecture de l’IGC • On distingue différents composants dans une IGC : • Autorité de certification AC (certificat authority) • Autorité d’enregistrement AE (registry authority) • Interface utilisateur (Enrolment Entity)

21. Autorité de certification • C’est une organisation qui délivre des certificats à une population. • Il existe des autorités privées (intranet d’une entreprise), organisationnelles (CRU, CNRS), corporative (notaires), commerciales (Thawte, Verisign, …), très commerciales (microsoft), institutionnelles, etc

22. L’autorité de certification • Protège la clé privée de la AC (bunker informatique) • Vérifie les demandes de certificats (Certificat Signing Request) provenant des AE • Génère les certificats et les publie • Génère les listes de certificats révoqués (Certificat Revocation List)

23. L’autorité d’enregistrement • Vérifie l’identité des demandeurs de certificats et les éléments de la demande. Exemple : • L’email présent dans le DN est-il l’email canonique ? • Le demandeur a-t-il le droit de disposer d’un certificat de signature ? • Transmet les demandes valides par un canal sûr à l’AC (demandes signées par l’opérateur de la AC) • Recueille et vérifie les demandes de révocation

24. Délégation de l’AE • Le CRU propose à partir de Septembre la délégation d’une AE aux établissements qui le demanderaient. • Relation contractuelle incluant un énoncé de la politique d’enregistrement : • Vérification automatique du email • Rapport direct de confirmation de l’origine de la demande (rapport facial / téléphonique) • Utilisation de la carte professionnelle.

25. Aspect légaux de la signature • Validité de l’écrit électronique et reconnaissance juridique de la signature électronique • Le cadre est défini par la loi du 13 mars 2000, décret du 30 mars 2001, décret du 18 avril 2002 et l’arrêté du 31 mai 2002. • Obligation de dématérialisation des procédures

26. Type de signature

27. informe Rapport de certification informe Accrédite 2ans Rapport d’évaluation Rapport d’évaluation Qualifie 1ans Premier Ministre PC Target of evaluation Certifie Qualifié DCSSI Cofrac Présumée fiable Certifié Agrée organisme accrédité CESTI Commande 1 an max Prestataire de certification Editeur 2 ans renouvelable Vends Vends Acrédité DPC Dispositif de signature X509 Critère commun Signe un acte/document Achète Utilisateur