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

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

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.

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.

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

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

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

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

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.

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

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

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

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)

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

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)

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.

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.

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.

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.

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)

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

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)

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

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.

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

Présomption de fiabilité Type de signature Type de signature Validité Présomption de fiabilité Signature électronique Identification du signataire et intégrité du document non Signature électronique sécurisée Idem + Signature personnelle sous contrôle exclusif sécurisée présumée fiable Signature sécurisée, utilisant des moyens certifiés et des certificats qualifiés oui

Présumée fiable Target of evaluation PC Qualifié Certifié 1 an max Premier Ministre Accrédite 2ans informe Rapport de certification PC Target of evaluation Qualifie 1ans informe Certifie Qualifié DCSSI Cofrac Rapport d’évaluation Présumée fiable Rapport d’évaluation 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