Introduction la scurit Cours 8 Infrastructure de cls publiques

Catalin Dima

Gestion des cls

La gestion des cls concerne : La distribution de cls cryptographiques, Les mcanismes utiliss pour lassociation identitcl La gnration, la maintenance et la rvocation de cls. Le stockage scuris long terme des cls de dchiffrement (obligation lgale en France). Problmatique : Comment associer une cl publique une (reprsentation dune) identit ? Comment reprsenter une identit (nommage) ? Comment scuriser la cration des identits ? Comment limiter les dgts provoqus par la perte dune cl secrte ? Comment informer temps tous les membres de la communaut de cette perte ?
2

Public key infrastructure (PKI)

Systme permettant aux agents de reconnatre quelle cl publique appartient qui. Services fournis par la PKI : Vrication didentit et cration de certicats Rvocation des cls Test dappartenence de certicats Recouvrement des cls de dchiffrement Composants dune PKI : Authorit de certication (CA). Authorit denregistrement (RA). Authorit de dpot (Repository). Authorit de recouvrement.

Composants dune PKI

Authorit denregistrement (RA) : Vrie lidentit du demandeur de certicat. Authorit de certication (CA) : Signe les certicats. Signe les rvocations de certicats. Peut tre la mme que la RA. Autorit de dpot (Repository) : Maintient les certicats dans un rpertoire public de certicats. Maintient une liste de rvocation de certicats (CRL) dans le rpertoire des certicats. La CRL est vrie activement par les clients ou par les services de validation. Autorit de recouvrement : Protge certaines cls prives pour rcupration ultrieure. Clients.
4

Clients et mode demploi

Actions entreprendre par Alice pour joindre la PKI : Gnration de sa paire cl prive/cl publique. Transport de sa cl publique la RA : Certicate Signing Request divers formes. La RA vrie quAlice est bien celle qui prtend ltre ( dnir selon les implmentations !) et informe la CA. La CA dlivre le certicat stipulant Cette cl KA appartient bien Alice. Le Repository rcupre et stocke ce certicat, mis disposition pour tout le monde. Maintenant tout Bob peut rcuprer (soit chez le Repository, soit dune autre manire !) le certicat dAlice Si Bob fait conance la CA, peut accepter comme valide le certicat, et authentier diverses conversations avec Alice. Cel implique bien sr la possesion de la cl publique de la CA, pour bien vrier la signature digitale sur le certicat !

CSR en BouncyCastle
Classe PKCS10CertificationRequest. Constructeur : PKCS10CertificationRequest(signatureAlgorithm, subject, pubkey, attributes, signingKey). signingKey est la cl prive correspondant la cl publique certicat auto-sign. attributes peut tre null. Mthode verify() vrier la requte autosigne. Mthode getPublicKey() pour retrouver la cl signer. Mthode getCertificationRequestInfo() qui renvoie un objet de type CertificationRequestInfo. Mthode getSubject() de cette classe, permettant de retrouver le propritaire de la cl publique signer. Mthode getAlgorithmIdentifier() pour retrouver lalgorithme pour lequel la cl est utilisable.

Chanes de conance
Deux approches : Construction dune hirarchie dauthentication, o la cl publique de la racine serait gnralement reconnu. Graphe arbitraire de la relation dauthentication des certicats, en sappuyant sur la connaissance individuelle des certicateurs. Modle de conance directe : tous les utilisateurs sous-scrivent la mme CA. Tous les certicats pourront tre placs dans le mme rpertoire. Les certicats pourront tre retransmis dutilisateur utilisateur.

Chanes de conance
Modle de conance hirarchique : pour des grandes communauts dutilisateurs. Nombre de CA qui fournissent chacune sa propre cl publique une fraction dutilisateurs. Arbre de conance : certicats racine, certicats qui authentient des certicats qui authentient... La validit dun certicat feuille est vrie en traant en arrire le chemin de conance, jusqu ce quon trouve un certicat dune authorit laquelle on fait conance. Exemple : X.509.

Rvocation de cl/certicat
Liste de rvocation de certicats (CRL) signe et maintenue par la CA. Utilisation : Les clients vrient eux-mmes activement les CRLs (ventuellement en utilisant une mmoire cache). Raisons pour la rvocation : La cl prive de lutilisateur est suppose compromise. Lutilisateur nest plus certi par la CA. Le certicat de la CA est suppos compromis. La validit de lassociation identit-cl publique nest pas garantie (erreurs dans la RA). Chaque CA maintient une liste de certicats rvoqus mais non expirs quelle signe. Il ne faut pas confondre rvocation et date limite !

CRL en Java et BouncyCastle

Classe java.security.cert.X509CRL encapsulant une CRL gnre par un serveur de CRL. Mthodes : verify(PublicKey), getIssuerX500Principal(). Mthode de recherche X509CRLEntry getRevokedCertificate(BigInteger serialNumber) ou getRevokedCertificate(X509Certificate certificate). La classe X509CRLEntry contient getRevocationDate() et getSerialNumber(). La classe CertificateFactory permet de rcuprer une CRL sur un ux dentre laide de la mthode generateCRL(InputStream).

10

CRL en BouncyCastle
Classe org.bouncycastle.x509.X509V2CRLGenerator permettant de crer des CRL. Constructeur X509V2CRLGenerator(). Mthode addCRLEntry(userCertificate, revocationDate, raison), le userCertificate est un BigInteger qui reprsente le Serial Number du certicat. Les raisons sont des entiers membres statiques de la classe CRLReason, dans lordre : unspecified=0, keyCompromise, cACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold, removeFromCRL, privilegeWithdrawn, aACompromise Mthode gnrant une CRL : X509CRL generate(java.security.PrivateKey key). Autres mthodes : setIssuerDN(issuer), setThisUpdate(date), setNextUpdate(java.util.Date date), setSignatureAlgorithm(signatureAlgorithm).

11

Vrication en ligne des CRL

La ncessit de vrier en ligne la validit dun certicat peut ouvrir la porte des attaques DoS contre les CRL. Une CRL est fournie toute entire qui le demande le client doit la parser pour vrier si un certicat est rvoqu. Cela peut poser problme aussi du point de vue de lintimit ! Variante : protocole OCSP Un serveur OCSP rpond des demandes de vrication de validit de certicats, en renvoyant une conrmation signe de ltat dun certicat un moment donn. Tout systme PKI a une latence sur lauthenticit : Cela permet dutiliser des caches CRL, ou de rponses OCSP.

12

OCSP en BouncyCastle
Classe OCSPReqGenerator, constructeur sans paramtres. Insertion de certicats vrier : addRequest(certId), argument de type CertificateID, Argument constructible avec CertificateID(CertificateID.HASH_SHA1, issuerCert, serialnumber). Dnir setRequestorName(X500Principal requestorName). Gnration de la requte : OCSPReq generate() (non-signe), ou generate(signingAlgorithm, privatekey, X509Certificate[] chain, provider) (requte signe). Classe OCSPReq encapsulant une requte : Mthode Req[] getRequestList(), renvoyant un tableau de Req dont la mthode CertificateID getCertID() permet de retrouver le Serial Number pour chaque certicat composant la requte. Test dauthentication : boolean verify(publickey, sigProvider).

13

OCSP en BouncyCastle
Construction dune rponse laide de la classe BasicOCSPRespGenerator : Constructeur BasicOCSPRespGenerator(publickey). Rajout dune rponse identie par le Serial Number : addResponse(CertificateID certID, CertificateStatus certStatus). Interface CertificateStatus implmente dans deux classes : RevokedStatus, UnknownStatus et un membre statique, GOOD. Constructeurs RevokedStatus(revocationDate, int reason) et UnknownStatus(). Gnration de la rponse : BasicOCSPResp generate(signingAlgorithm, privatekey, X509Certificate[] chain, Date thisUpdate, provider). Retrouver les certicats dans une rponse de type BasicOCSPResp : X509Certificate[] getCerts(provider) ensuite il faut vrier que le certicat pour lequel on a demand la rponse se trouve dans cette liste. mais contenant que des certicats. Vrier la signature : boolean verify(publickey, sigProvider). Ncessaire dajouter des nonces dans les requtes et les vrier dans les rponses pour viter des attaques de rejeu.
14

Rseau de conance
Inclut les systmes de conance directe et hirarchique. Se base sur lide que plus dinformation implique plus de conance. Un certicat peut tre co-sign par plusieurs authenticateurs. Exemple : PGP (Pretty Good Privacy (P. Zimmermann), utilise pour la condentialit des e-mails. Utilise une infrastructure de cls publiques bas sur les certicats. Les certicats se basent sur une notion de conance : zro, partiel et complet. Les diffrentes signatures pour une seule cl pourraient avoir des niveaux diffrents de conance. Les certicats peuvent mme tre auto-signs. Une signature digitale devient une forme dintroduction de lassociation identit/cl authentie. Plus de chemins de certication, plus de conance dans la cl. Exemple...

15

Projet PKI
Objectif : crer un ensemble dapplications client-serveur implmentant une PKI. Protocle denregistrement dun client auprs de sa RA. Protocle hors-ligne sinon pbs. dattaque Man-In-The-Middle, ou ncessit dutiliser une autre infrastructure de connexion scurise. Protocle de demande et dobtention dun certicat sign par sa CA. Aprs la gnration dune nouvelle cl publique client. Protocle de communication entre clients. Peut engendrer une change de certicats entre interlocuteurs, au dmarrage. Ou peut se baser sur un autre protocle de rcupration du certicat de linterlocuteur, auprs dun rpertoire des certicats. Exemple : utiliser Needham-Schroeder pour la cration dune cl de session. Politique de gestion de la CRL : Implmentation des deux mthodes : demande priodique de CRL et vrication dappartenance dans la CRL et vrication par OCSP lors de chaque nouvelle connexion. Protocole dnir pour demander le rajout dun certicat dans une CRL. Implmentation du protocole Needham-Schroder pour une application de type chat scuris, avec une gestion de type PKI des cls et gnration de cl de session partir de la nonce NB .
16

Travail demand
Travail en binome. Fichiers source (et ventuellement un jar) avec votre implmentation. Attention la portabilit ! Rapport contenant les points suivants : Description (formalise comme vu en cours) des protocles de communication, avec analyse de la scurit du protocle (assertions !). Description de limplmentation de chaque protocle. Description de larchitecture de votre application (clients/serveurs) Conguration ncessaire et manipulation. Description de votre plan de travail : comment avez-vous conu les phases dimplmentation, quand avez-vous pens commencer et quand nir chaque phase, et ensuite comment cela sest rellement pass. Questions diverses : difcults particulires rencontres, aide externe, discussions que vous avez eu avec dautres binmes ou dans des groupes de discussions, etc. Soutenance : prsentation de votre implmentation. Prvoir une petite application qui montrerait toutes les diverses fonctionnalits implments. Soutenances : premire semaine aprs les examens.
17