UNIVERSITÉ DU QUÉBEC À MONTRÉAL GESTION DES CLÉS PUBLIQUES POUR LES ENTREPRISES DE L ÉCONOMIE SOCIALE ET SOLIDAIRE

Transcription

1 UNIVERSITÉ DU QUÉBEC À MONTRÉAL GESTION DES CLÉS PUBLIQUES POUR LES ENTREPRISES DE L ÉCONOMIE SOCIALE ET SOLIDAIRE PROJET DE RECHERCHE PRÉSENTÉ COMME EXIGENCE PARTIELLE DE LA MAÎTRISE EN GÉNIE LOGICIEL PAR STÉPHANE GRATON HIVER 2010

2

3 Table des matières Table des matières...3 Liste des figures...5 Liste des tableaux...6 Sigles et abréviations Introduction Contexte Objectifs Structure du document Définition du problème Gestion des clés publiques La cryptographie Mécanismes cryptographiques Les familles d algorithmes cryptographiques Normes et standards IETF PKIX RSA PKCS ISO TC 68/SC ISO JTC ANSI X ITU-T NIST L infrastructure à clé publique (ICP) Les composantes de l ICP Les services de gestion offerts par l ICP Les services de sécurité offerts par l ICP Les protocoles de l ICP Le certificat à clé publique La gestion du cycle de vie des clés et des certificats La confiance Les composantes physiques Les solutions d ICP Les produits logiciels RSA Digital Certificate Solution Entrust Authority EJBCA Les observations Les services hébergés Entrust - Managed Services PKI OpenTrust - Software as a Service (SaaS) Les observations Recommandations...64 Page 3 sur 96

4 5.1 «PKI as a Service» Logiciels libres requis Organisation des composantes Modèle de confiance Politiques de certification Gestion des clés cryptographiques Algorithmes asymétriques et longueurs de clés Algorithmes symétriques Fonctions de hachage Génération des clés Stockage des clés Utilisation des clés Période de validité des certificats Certificats des serveurs Web publics Expérimentations Description de l environnement Configurations logicielles Architecture de l ICP Création des entités dans l ICP Génération et installation des certificats SSL Certificat SSL du serveur Web Certificat du client dans le fureteur Web Firefox Activation de l authentification client par certificat Conclusion...91 Bibliographie...93 Page 4 sur 96

5 Liste des figures Figure 1 - Chiffrement d'un message. Source [NETASSI] Figure 2 - Hachage d'un message. Source [NETASSI] Figure 3 - Signature d'un message. Source [NETASSI] Figure 4 - Chiffrement à l aide de la cryptographie symétrique. Source [NETASSI] Figure 5 - Chiffrement à l aide de la cryptographie asymétrique. Source [NETASSI] Figure 6 - Vue globale de l'icp. Traduction de [ENTPKI01] Figure 7 - Les composantes et les entités de l'icp. Source [RFC5280] Figure 8 - Certificat numérique X.509. Source [NETASSI] Figure 9 - Exemple de la structure hiérarchique d'un DN Figure 10 - Cycle de vie des certificats. Traduction de [ADAMS03] Figure 11 - Enregistrement auprès d'une AE Web. Traduction de [ADAMS03] Figure 12 - Exemple d'un chemin de certification à 3 niveaux Figure 13 - Modèle de confiance simple avec AC unique Figure 14 - Modèle de confiance simple avec liste de confiance Figure 15 - Modèle de confiance Hiérarchique Figure 16 - Modèle de confiance en réseau Figure 17 - Modèle de confiance Hybride Figure 18 - Exemples de modules de sécurité Figure 19 - Diagramme d'architecture applicative d'ejbca tiré de [EJBCAFU] Figure 20 - Diagramme d'architecture fonctionnelle d'ejbca. Source [EJBCAFU] Figure 21 - Coûts de l'exploitation d'une ICP à l'interne. Source [ENTTCO] Figure 22 - Architecture Entrust Managed Services PKI. Source [ENTMNG] Figure 23 - Architecture du produit OpenTrust PKI. Source [OPENTR] Figure 24 - Vue globale de la solution proposée Figure 25 - Configurations logicielles des serveurs de l ICP Figure 26 - Modèle de zone réseau proposé Figure 27 - Mécanisme d AE externe d EJBCA. Source [EJBCA] Figure 28 - Les deux niveaux d'ac Figure 29 - Génération des clés. Source Cisco Figure 30 - Carte à puce pour stocker la clé privée. Source Alladin.com Figure 31 - Alerte de sécurité du fureteur Firefox Figure 32 - Environnement pour les expérimentations Page 5 sur 96

6 Figure 33 - Configurations logicielles client et serveur Figure 34 - Modèle de confiance de l'environnement d expérimentation Figure 35 - Création d'une entité dans EJBCA Figure 36 - Signature du certificat SSL du serveur par l'ac Figure 37 - Téléchargement des certificats d'ac Figure 38 - Le certificat du serveur n'est pas reconnu par le fureteur Web Figure 39 - Installation du certificat racine dans FireFox Figure 40 - Le certificat de notre AC racine installé dans Firefox Figure 41 - Page d'accueil du serveur de test Figure 42 - Génération du certificat client Figure 43 - Confirmation de l'installation du certificat client dans Firefox Figure 44 - Le certificat client installé dans Firefox Figure 45 - Connexion au serveur Web avec authentification par certificat Liste des tableaux Table 1 - Algorithmes asymétriques Table 2 - Principales sources normatives pour l'icp Table 3 - Standard PKCS ayant été repris par l'ietf Table 4 - Services de gestion offerts par l ICP. Inspiré de [ADAMS03] Table 5 - Description des services primaires offerts par l ICP. Inspiré de [ADAMS03] Table 6 - Services complémentaires offerts par l ICP. Inspiré de [ADAMS03] Table 7 - Évolution du certificat X Table 8 - Attributs d'un certificat X.509 v Table 9 - Attributs de nommage LDAP standard. Source [RFC4514] Table 10 - Les extensions standards X.509 v Table 11 - Caractéristiques du modèle de confiance simple avec AC unique Table 12 - Caractéristiques du modèle de confiance simple avec liste de confiance Table 13 - Caractéristiques du modèle de confiance Hiérarchique Table 14 - Caractéristiques du modèle de confiance en réseau Table 15 - Caractéristiques du modèle de confiance Hybride Table 16 - Caractéristiques techniques - RSA Certificate Manager Table 17 - Caractéristiques techniques - Entrust Authority Security Manager Table 18 - Caractéristiques techniques - EJBCA Page 6 sur 96

7 Table 19 - Liste des composantes logicielles requises Table 20 - Longueurs de clés recommandées par le NIST. Source [SP800573] Table 21 - Exigences pour le module de sécurité. Source [SP800573] Table 22 - Utilisation des clés par type de certificat Table 23 - Durée de vie suggérée par profil de certificat Table 24 - Attributs des certificats utilisés pour les expérimentations Page 7 sur 96

8 Sigles et abréviations AC AE AEL AES CMP CRL EAL ECDSA DES DN DSA EE EESS FIPS HSM HTTP HTTPS ICP IPSec IETF ISO ISO/IEC ITU ITU-T JKS LDAP LGPL MAC MD5 NIST OCSP OLF Autorité de certification Autorité d enregistrement Autorité d enregistrement locale Advanced Encryption Standard Certificate Management Protocol Certificates Revocation List Evaluation Assurance Level Elliptic Curve Digital Signature Algorithm Data Encryption Standard Distinguished Name Digital Signature Algorithm. End entity (entité d extrémité) Entreprises de l Économie Sociale et Solidaire Federal Information Processing Standard Hardware Security Module HyperText Transfer Protocol Hypertext Transfer Protocol over Secure Socket Layer Infrastructure à clé publique Internet Protocol Security Internet Engineering Task Force International Organization for Standardization ISO / International Electrotechnical Commission International Telecommunication Union ITU - Telecommunication Standardization Sector Java KeyStore Lightweight Directory Access Protocol GNU Lesser General Public License Message Authentication Code Message Digest 5 (algorithme de hachage) National Institute of Standards and Technology Online Certificate Status Protocol Office de la Langue Française Page 8 sur 96

9 PEM PKCS PKI Privacy Enhanced Mail The Public-Key Cryptography Standards Public-Key Infrastructure PKIX Public-Key Infrastructure X.509 RC4 Rivest Cipher 4 RFC RSA SCEP SHA-1 S/MIME SQL SSL VPN W3C XKMS XML Request For Comments Projet en génie logiciel Algorithme de chiffrement à clé publique et de signature inventé par R.Rivest, A.Shamir et l.adleman. Simple Certificate Enrollment Protocol Secure Hash Algorithm Number 1. SHA (algorithme de hachage). Secure/Multipurpose Internet Mail Extensions Structured Query Language Secure Socket Layer Virtual Private Network World Wide Web Consortium XML Key Management Specification Extensible Markup Language Page 9 sur 96

10 1 Introduction Ce rapport présente les résultats d un projet de recherche réalisé dans le cadre de l activité MGL9701 Projet en génie logiciel du programme MGL3822 Maîtrise en génie logiciel de l Université du Québec à Montréal (UQAM). 1.1 Contexte Ce projet de recherche se veut une contribution au chantier sécurité de la Chaire de logiciel libre Finance sociale et solidaire, rattachée au département d informatique de l Université du Québec à Montréal (UQAM). Principalement financée par L Association internationale du logiciel libre pour l économie sociale (AI2L), la Chaire a pour double mission de poser les fondements d une famille de logiciels libres pour la finance sociale et solidaire, ainsi que d étudier les spécificités du développement du logiciel libre en relation avec les meilleures pratiques du génie logiciel [CHAIRE]. Le sujet de ce projet fut proposé par M. Louis Martin, titulaire de la Chaire. Au fait des nouvelles normes et réglementations devant être prises en compte par les logiciels financiers, M. Martin avait identifié certains besoins essentiels en matière de sécurité. Parmi ceux-ci figurait la gestion des clés publiques, un élément à la fois stratégique et essentiel dans le contexte de la finance. Il s agit donc du sujet auquel est consacré ce projet de recherche. Les attentes envers ce projet furent exprimées par une brève mise en contexte, accompagnée d un certain nombre de questionnements concernant la gestion des clés publiques, ainsi que des certificats numériques qui servent à leur distribution : Une entreprise peut-elle émettre et gérer ses propres certificats à clé publique sans faire appel à une autorité de certification commerciale? Quels sont les principales normes et standards de l industrie en la matière? Serait-il envisageable de développer ou de faire appel à une solution en logiciel libre existante pour le faire? Comment faire pour que le certificat SSL d un serveur Web, émis par une autorité de certification interne, soit reconnu par les fureteurs Web des utilisateurs de la communauté? L AI2L pourrait-elle éventuellement agir en tant qu autorité de certification au même titre que des autorités commerciales reconnues? Le principal besoin alors exprimé concernait la gestion des certificats à clé publique utilisés pour sécuriser les échanges de commerce électronique entre les entreprises de l économie sociale et les clients particuliers (B2C), ainsi que les clients et partenaires commerciaux (B2B). Page 10 sur 96

11 1.2 Objectifs Les travaux présentés dans ce document ont pour objectif de fournir un ensemble de recommandations en ce qui a trait à la gestion des clés publiques dans un contexte d entreprises de l économie sociale et solidaire. 1.3 Structure du document Ce rapport est structuré de manière à introduire progressivement, dans un ordre logique, la problématique, soit la gestion des clés publiques, ainsi que l ensemble des concepts inhérents à ce sujet. L assimilation de ces concepts est nécessaire à la compréhension des recommandations émises au terme du projet. Ce document est structuré dans l ordre logique suivant : Définition du problème; Introduction aux concepts inhérents à la gestion des clés publiques : o o o Introduction à la cryptographie; Identification des principaux éléments normatifs; Présentation détaillée de l Infrastructure à clé publique (ICP); Exploration des différentes solutions d ICP offertes aux entreprises : o o Survol des produits logiciels permettant la mise en œuvre d une ICP complète et identification d un produit d ICP en logiciel libre; Regard sur les services d ICP commerciaux hébergés; Présentation des recommandations; Description des expérimentations réalisées dans le cadre du projet; Conclusion. Page 11 sur 96

12 2 Définition du problème Les logiciels qui seront développés par la Chaire de logiciel libre Finance sociale et solidaire, devront être conçus de manière à permettre aux entreprises de respecter les normes internationales en matière de gestion de la sécurité de l information. Pour atteindre cet objectif il faudra dès le début d un projet, s assurer de définir les exigences de sécurité ainsi que les procédures permettant leur mise en œuvre. De cette manière, celles-ci pourront être intégrées dès la phase de conception du logiciel. Une intégration tardive effectuée pendant ou après la mise en œuvre d un logiciel est souvent plus complexe à réaliser, et demande généralement plus d efforts que si elle avait été réalisée lors de la conception initiale [ISO27002]. Pour répondre aux diverses exigences de sécurité, les logiciels devront faire appel à différents services de sécurité tels que l authentification, l autorisation, la confidentialité, l intégrité, l imputabilité et autres. À titre d exemple, il est raisonnable de croire que : l accès aux applications sera contrôlé par une forme d authentification forte; les communications entre applications et utilisateurs devront demeurer confidentielles et intègres; tout accès aux données confidentielles, ainsi qu aux fonctions de nature critique du logiciel sera soumis à une autorisation préalable; les utilisateurs des logiciels ne devront pas pouvoir nier les actions qu ils auront posées; La mise en œuvre de ces services de sécurité est rendue possible grâce à la cryptographie moderne qui offre différents mécanismes de sécurité tels que le chiffrement et la signature numérique. Plusieurs de ces mécanismes sont basés sur des algorithmes cryptographiques asymétriques dits «à clé publique». Bien que très efficace, la cryptographie à clé publique comporte cependant un enjeu majeur, soit la gestion des clés publiques. En effet, l efficacité des mécanismes de sécurité basés sur la cryptographie à clé publique dépend du niveau de certitude que détient l utilisateur d une clé publique quant à l identité de son propriétaire légitime. Les clés publiques sont distribuées à l intérieur de certificats à clé publique. Ce certificat permet de créer une association entre la clé publique qu il contient et l identité de son propriétaire. Ainsi, ceux qui désirent utiliser la clé publique contenue dans un certificat, peuvent s assurer de l identité de son propriétaire, dans la mesure où ils ont confiance en l autorité qui a émis le certificat. En intégrant aux logiciels différents mécanismes de sécurité basés sur la cryptographie à clé publique, cela risque de provoquer l accroissement du nombre de certificats à clé publique requis au sein des entreprises qui utiliseront ces logiciels. Par exemple, le déploiement d un logiciel développé par la Chaire pourrait forcer une entreprise à fournir un certificat à clé publique à chacun de ses employés. Or, la majorité des EESS (Entreprises de l Économie Sociale et Solidaire) ne disposent pas des moyens nécessaires pour réaliser l émission massive de certificats à clé publique. Page 12 sur 96

13 Cette situation place les EESS dans une position délicate où celles-ci devront faire un choix important, et considérer l une des deux options suivantes : 1. Faire l acquisition des certificats à clé publique auprès d une autorité de certification commerciale; 2. Mettre en place les infrastructures nécessaires afin de leur permettre d effectuer elles-mêmes la gestion des certificats à clé publique; Ces deux (2) options comportent des avantages et des inconvénients, ainsi qu un certain niveau de risque pour les EESS. Généralement, ce choix est grandement influencé par l aspect financier et non par l aspect technique. Cependant, les recommandations émises au terme de la présente étude devront respecter les valeurs de l'économie sociale et solidaire partagées par les entreprises qui utiliseront les logiciels développés par la Chaire. Dans ce contexte, l aspect financier de la solution devient un facteur parmi tant d autres, car il faut permettre à la Chaire ainsi qu à l AI2L de respecter des engagements tels que : «contribuer, par la création de logiciels libres, à l'objectif d'une indépendance des entreprises d'économie sociale et solidaire vis-à-vis des producteurs capitalistes du code informatique, pour la gestion de leurs systèmes d'information et dans leurs échanges électroniques;» [AI2L] «faciliter, sur une base nationale et internationale, et grâce aux logiciels libres développés, la mise en réseau d entreprises d'économie sociale et solidaire;» [AI2L] La problématique se résume donc à déterminer comment la Chaire et l AI2L pourront supporter les EESS dans la gestion des clés publiques qui seront nécessaires afin de permettre l utilisation des logiciels développés par la Chaire. Page 13 sur 96

14 3 Gestion des clés publiques Ce chapitre présente différents éléments liés à la gestion des clés publiques. La section 3.1 offre une introduction à la cryptographie, la section 3.2 présente les principaux éléments normatifs encadrant la gestion des clés publiques, et finalement la section 3.3 présente l infrastructure à clé publique. 3.1 La cryptographie La cryptographie se définit comme étant «l ensemble des principes, méthodes et techniques dont l'application assure le chiffrement et le déchiffrement des données, afin d'en préserver la confidentialité et l'authenticité.» [OLF]. Il s agit de l élément technique fondamental sur lequel s appuient les mécanismes traités dans ce projet. La cryptographie offre des services de sécurité tels que la confidentialité, l intégrité, l authentification, l autorisation ainsi que la non-répudiation [SP80021]. Ces services sont réalisés en appliquant des transformations sur les données à protéger. Ces transformations sont réalisées à l aide d une fonction mathématique (algorithme) et d un paramètre (une clé). Cette section offre une introduction aux notions élémentaires de la cryptographie. Une connaissance minimale de ces notions de base est nécessaire à la compréhension des concepts abordés dans le cadre de cette étude. Cette section introduit : Les mécanismes cryptographiques; Les familles d algorithmes cryptographiques (à clé secrète, à clé publique); Page 14 sur 96

15 3.1.1 Mécanismes cryptographiques Le chiffrement Le chiffrement est le mécanisme cryptographique par lequel un message (fichier, courriel, etc.) dit «en clair», est transformé à l aide d un algorithme mathématique et d une clé, de manière à le rendre inintelligible. Le déchiffrement est l opération inverse qui, par un procédé similaire, applique une transformation sur un message chiffré, de manière à le ramener dans sa forme intelligible. Le chiffrement a pour objectif d assurer la confidentialité des données. Chiffrement Déchiffrement Message en clair Message chiffré Message en clair La fonction de hachage Figure 1 - Chiffrement d'un message. Source [NETASSI] La fonction de hachage calcule un haché (une empreinte digitale) de longueur fixe, à partir d un message de longueur variable. Il s agit d une fonction dite à sens unique, car il est impossible de retrouver le message original à partir de son résultat (du haché). Un algorithme de hachage cryptographique doit être facile à appliquer et offrir une faible probabilité de collision. En d autres mots, il doit être facile de calculer le haché d un message, mais extrêmement difficile d arriver à construire un message dont le haché correspond à une valeur prédéterminée [SP80021]. Les fonctions de hachage cryptographique les plus souvent utilisées sont MD5 et SHA-1. Fonction de hachage Message de longueur variable Haché de longueur fixe Figure 2 - Hachage d'un message. Source [NETASSI] Le hachage cryptographique est une opération utilisée par plusieurs mécanismes et protocoles de sécurité, tels que le calcul d un MAC (Message Authentication Code) ou d une signature numérique. Page 15 sur 96

16 La signature numérique Projet en génie logiciel La signature numérique (ou signature électronique) est un mécanisme cryptographique asymétrique qui permet de s assurer de l authenticité ainsi que de l intégrité d un message. Ainsi, après qu un signataire ait apposé sa signature numérique sur un message, il est possible pour quiconque est en possession de la clé publique de ce signataire de vérifier cette signature, afin de s assurer que le message n ait pas été altéré, et qu il est authentique. On peut comparer cette signature à une signature manuscrite apposée sur un document papier. La signature d un message est calculée à l aide d un algorithme mathématique ainsi que de la clé privée du signataire. Pour des raisons de performance, la signature est calculée sur le haché du message plutôt que sur le message lui-même. La production d une signature consiste essentiellement à calculer le haché du message à l aide d un algorithme de hachage cryptographique, puis à chiffrer ce haché à l aide d un algorithme et de la clé privée du signataire. La vérification de la signature quant à elle, s effectue en comparant le haché calculé sur le message, au haché contenu dans la signature obtenue après l avoir déchiffrée à l aide d un algorithme et de la clé publique du signataire. Bien entendu, les opérations de calcul du haché ainsi que de déchiffrement doivent être effectuées à l aide des algorithmes qui ont été utilisés par le signataire. Fonction de hachage Message de longueur variable Message signé avec une clé privée Haché de longueur fixe Message en clair + Signature Clé privée utilisée pour la signature Figure 3 - Signature d'un message. Source [NETASSI] La signature numérique a pour objectif d assurer l authenticité ainsi que l intégrité des données, en plus de permettre la non-répudiation. Page 16 sur 96

17 3.1.2 Les familles d algorithmes cryptographiques Les algorithmes symétriques (à clé secrète) Projet en génie logiciel La famille d algorithmes symétriques, connue sous le nom de cryptographie à clé secrète, constitue la plus ancienne forme de cryptographie. Celle-ci repose sur un principe selon lequel la même clé est utilisée pour effectuer les opérations de chiffrement et de déchiffrement [SP80021]. Ce type de cryptographie a l avantage d être simple et très rapide, mais a pour principal problématique le partage de la clé entre les entités désirant s échanger des messages. La distribution de la clé secrète augmente les risques de divulgation ou de compromission, c'est-à-dire que cette clé secrète tombe entre des mains d individus auxquels celle-ci n était pas destinée. Malgré cette problématique, son utilisation demeure extrêmement répandue. Chiffrement Déchiffrement Message en clair Message chiffré Message en clair Figure 4 - Chiffrement à l aide de la cryptographie symétrique. Source [NETASSI] Il existe aujourd hui deux grandes catégories de chiffrement à clés symétriques, soit le chiffrement par blocs (block cipher), dont les algorithmes les plus populaires sont DES, 3DES, AES et Blowfish, ainsi que le chiffrement par flot (stream cipher) dont l algorithme le plus populaire est RC Les algorithmes asymétriques (à clé publique) La famille d algorithmes asymétriques, connue sous le nom de cryptographie à clé publique, a vu le jour dans les années 70. C est en 1976, lors de la publication du célèbre article «New directions in cryptography» [WHITF76], que Whitfield Diffie et Martin Hellman ont introduit ce concept révolutionnaire. Les auteurs y présentent un protocole par lequel deux entités peuvent convenir d'une clé secrète, uniquement en se basant sur la connaissance préalable de données publiques. Par la suite, trois chercheurs du Massachusetts Institute of Technology (MIT), soit Ronald Rivest, Adi Shamir, and Leonard Adleman (RSA), ont poussé ce concept, ce qui a mené à l élaboration des concepts pratiques qui sont aujourd hui utilisés dans la cryptographie à clé publique. Page 17 sur 96

18 Contrairement au mécanisme cryptographique traditionnel à clé secrète, où la même clé est utilisée à la fois pour le chiffrement et le déchiffrement des données, la cryptographie asymétrique fait appel à une paire de clés. Cette paire de clés comprend une clé dite privée et une clé dite publique. Ces clés sont liées entre elles par une formule mathématique qui fait en sorte qu une opération réalisée avec une des clés ne peut être renversée qu en effectuant l opération inverse à l aide de l autre clé. Par exemple, un message chiffré à l aide d une clé publique ne peut être déchiffré qu à l aide de la clé privée associée. Clé publique Clé privée Chiffrement Déchiffrement Message en clair Message chiffré Message en clair Figure 5 - Chiffrement à l aide de la cryptographie asymétrique. Source [NETASSI] La clé privée doit être conservée de manière sécuritaire, et ne doit être divulguée sous aucun prétexte. Contrairement à la clé secrète utilisée par les algorithmes symétriques, la clé privée d une entité n a pas à être connue des autres entités qui participent aux échanges de messages sécurisés. La clé publique, quant à elle, peut être publiée sans aucun risque, pourvu qu il soit possible de vérifier son authenticité. La cryptographie à clé publique est principalement utilisée pour assurer l intégrité des données, l authentification, la non-répudiation et l échange de clés [SP80021]. Le tableau suivant énumère les principaux algorithmes asymétriques ainsi que l usage pour lequel ceux-ci ont été conçus. Algorithme Chiffrement Signature Échange de clés RSA El Gamal Diffie-Hellman DSA (Digital Signature Algorithm) ECC (Elliptic Curve Cryptosystem) Table 1 - Algorithmes asymétriques Page 18 sur 96

19 3.2 Normes et standards La sécurité des technologies de l information est un domaine relativement complexe qui, comme bien d autres domaines, est voué à une constante évolution. Malgré des efforts collectifs soutenus entourant le développement de standards internationaux, il n existe encore aucune entité internationale faisant office d autorité absolue en la matière. Les normes et standards régissant ce domaine sont établis par plusieurs groupes de travail et organisations reconnues mondialement. Les normes établies par les principaux groupes de travail se réfèrent entre elles, par conséquent, il est difficile d en établir une liste exhaustive. Les normes et standards entourant les ICP n ont que très peu évolué depuis le début des années 2000, mais il n en demeure pas moins qu il est toujours aussi difficile de dresser la liste de tous les éléments normatifs auxquels devrait se conformer une ICP. Le tableau suivant dresse la liste des principales sources normatives applicables à l ICP ainsi qu à son utilisation dans le contexte financier. Source Ref. Description IETF PKIX [PKIX] Groupe de travail PKIX (Public-Key Infrastructure X.509) de l IETF (Internet Engineering Task Force), qui a pour mission d améliorer le fonctionnement de l internet. RSA Laboratories PKCS [RSALABS] Centre de recherche de RSA Security, entreprise fondée par les inventeurs de la cryptographie à clé publique. ISO TC 68/SC 2 [ISOTC68] Comité technique de l ISO (Organisation internationale de normalisation) dédié à la gestion de la sécurité et des opérations bancaires générales. ISO JTC 1 [ISOJTC1] Comité technique de l ISO (Organisation internationale de normalisation) dédié à la standardisation des technologies de l'information. ANSI X9 [ANSIX9] Comité de l ANSI (American National Standards Institute) dédié à la standardisation des opérations bancaires. ITU-T [ITUT] Comité de normalisation de l ITU (International Telecommunication Union). NIST [NISTCSD] Le «Computer Security Division» du NIST (National Institute of Standards and Technology) développe des standards de sécurité informatique. Table 2 - Principales sources normatives pour l'icp Cette section décrit les principaux éléments normatifs régissant la mise en place ainsi que l exploitation d une ICP dans le domaine de la finance. Page 19 sur 96

20 3.2.1 IETF PKIX Fondé en 1995, le groupe de travail PKIX (Public-Key Infrastructure X.509) de l IETF (Internet Engineering Task Force) se consacre au développement de standards visant l encadrement de l infrastructure à clé publique dans le monde de l Internet. Ces standards intègrent d autres standards tels que le format de certificat X.509 développé par l ITU, ainsi que les standards PKCS développés par RSA Laboratories. C est sur ces standards que sont aujourd hui bâties les ICP. Parmi les principaux standards développés par ce groupe, voici ceux qui sont les plus pertinents pour la présente étude :. RFC Certificate and Certificate Revocation List (CRL) Profile. Spécification qui décrit le format du certificat X.509 v3 avec ses extensions, ainsi que le mécanisme de liste de révocation pour son utilisation sur l internet. Cette spécification remplace les RFC 2459, 3280, 4325 et Ce RFC constitue la proposition du groupe de travail PKIX pour l utilisation de l ICP sur l internet [RFC5280]. RFC Online Certificate Status Protocol - OCSP. Spécification qui décrit le protocole Online Certificate Status Protocol (OCSP). Ce protocole permet de déterminer le statut courant d un certificat à clé publique, sans avoir à recourir à l utilisation d une liste de révocation. Le protocole OCSP permet donc à une composante logicielle de faire appel à un tiers de confiance, afin de déterminer si un certificat a fait l objet d une révocation ou non. Ce mécanisme a pour avantage de faciliter la gestion des listes de révocation [RFC2560]. RFC Time-Stamp Protocol (TSP). Spécification qui décrit le protocole d échange avec le service d horodatage Time Stamping Authority (TSA). Le service TSA permet de générer des assertions qui attestent qu une donnée existait à un moment précis dans le temps. Ce service est utilisé par les services de non-répudiation [RFC3161]. RFC Certificate Policy and Certification Practices Framework. Guide de rédaction pour les politiques de certificats (CP) ainsi que les énoncés de pratiques de certification (CPS) d une ICP. Ce document décrit exhaustivement la structure des documents ainsi que leur contenu respectif [RFC3647]. RFC Certificate Management Protocol (CMP). Spécification qui décrit le protocole Certificate Management Protocol (CMP). Le protocole CMP est utilisé pour la création, ainsi que la gestion des certificats x.509v3 à distance. Les composantes de l ICP utilisent ce protocole pour communiquer entre elles. Cette spécification remplace le RFC 2510 [RFC4210]. RFC Certificate Request. Spécification qui décrit le Certificate Request Message Format (CRMF). Ce format est utilisé lors de l acheminement des requêtes de certificats à l autorité de certification [RFC4211]. Cette spécification remplace le RFC Page 20 sur 96

21 3.2.2 RSA PKCS Les standards PKCS (Public-Key Cryptography Standards) ont été établis par RSA Laboratries, en collaboration avec différents développeurs de systèmes sécurisés de partout à travers le monde. L'objectif de cette initiative fut d accélérer le déploiement de la cryptographie à clé publique. Publiées pour la première fois en 1991 à la suite de réunions impliquant un groupe restreint d organisations réceptives à la technologie de la clé publique, les spécifications PKCS ont depuis été largement citées et mises en œuvre. Les contributions de la série PKCS font désormais partie des nombreuses normes et standards tels que ANSI X9, PKIX, SET, S/MIME, et SSL [RSALABS]. Parmi les standards PKCS, voici ceux qui sont les plus pertinents pour la présente étude : PKCS #1 - RSA Encryption Standard. Recommandations concernant l implantation de la cryptographie à clé publique basée sur l algorithme RSA [SP800573]. Ce document définit entre autres les schémas de signature (PKCS #1 v1.5 et PSS) recommandés par le NIST pour réaliser des signatures RSA [SP800573]. PKCS #3 - Diffie-Hellman Key-Agreement Standard. Ce standard décrit une méthode d implantation pour le protocole d établissement de clé Diffie-Hellman, qui permet à deux (2) entités de s entendre sur une clé secrète, sans qu aucun arrangement préalable ne soit requis [PKCS03]. PKCS #7 - Cryptographic Message Syntax Standard. Ce standard décrit une syntaxe générale pour des données sur lesquelles on peut avoir à appliquer des mécanismes cryptographiques tels que la signature numérique [PKCS07]. Cette syntaxe est entre autres utilisée pour le courriel sécurisé S/MIME (Secure / Multipurpose Internet Mail Extensions) [RFC3851] ainsi que le protocole de gestion des certificats PKIX-CMP (Certificate Management Protocol) [RFC4210]. PKCS #10 - Certification Request Syntax Standard. Ce standard décrit le format d une requête de certification contenant le nom de l entité, sa clé publique ainsi que d autres attributs optionnels [PKCS10]. À partir de cette requête, l autorité de certification peut procéder à la création du certificat X.509 de cette entité. Il s agit du format d encodage utilisé pour les CSR (Certificate signing request) généré sur les serveurs (ex. Apache, Tomcat, etc.). PKCS #11 - Cryptographic Token Interface Standard. Ce standard définit une interface de programmation (API) appelée Cryptoki, permettant aux applications de faire appel à un module cryptographique afin de stocker des informations cryptographiques ou réaliser certaines fonctions cryptographiques [PKCS11]. Le standard PKCS #11 est supporté par la majorité des fabricants de modules de sécurité HSM (Hardware Security Modules) et de carte à puce. Page 21 sur 96

22 PKCS #12 - Personal Information Exchange Syntax Standard. Ce standard définit la syntaxe du format de données utilisé pour le transfert d informations personnelles incluant les clés privées, les certificats, ainsi que différents secrets et extensions [PKCS12]. Ce format de donnée est entre autres utilisé par l autorité de certification pour distribuer le certificat à clé publique, ainsi que la clé privée à son propriétaire suite à leur émission. Les informations contenues dans un fichier PKCS #12 sont chiffrées sous une clé symétrique dérivée d un mot de passe. Le tableau suivant énumère les standards PKCS qui ont été repris par le group de travail PKIX de l IETF. RSA PKCS#1 PKCS#5 PKCS#7 PKCS#8 PKCS#10 IETF RFC Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography RFC PKCS #5: Password-Based Cryptography Specification RFC PKCS #7: Cryptographic Message Syntax RFC Public-Key Cryptography Standards (PKCS) #8 : Private-Key Information Syntax Specification Version 1.2 RFC PKCS #10 : Certification Request Syntax Specification Table 3 - Standard PKCS ayant été repris par l'ietf ISO TC 68/SC 2 Fondé en 1948, le comité technique TC 68/SC 2 - Gestion de la sécurité et opérations bancaires générales de l Organisation internationale de normalisation (ISO), est assigné au développement de normes et rapports techniques destinés à l industrie de la finance. Ce comité a aussi pour responsabilité de standardiser l utilisation de la cryptographie à clé publique dans ce secteur de l industrie. Une recherche rapide parmi les travaux réalisés par ce comité a permis d identifier trois (3) normes susceptibles de fournir des recommandations pertinentes sur la mise en œuvre et de l exploitation d une ICP au sein des EESS (Entreprises de l Économie Sociale et Solidaire) : ISO : Gestion de certificats pour les services financiers - Partie 1 : Certificats de clé publique. Cette norme définit un système de gestion de certificats destiné à l industrie de la finance. Elle encadre entre autres la génération, la distribution, la validation, le renouvellement la révocation, ainsi que la récupération des certificats. ISO : Banque - Gestion des certificats - Partie 2 : Extensions des certificats. Cette norme définit un système de gestion de certificats destiné à l industrie de la finance. Elle encadre la définition ainsi que l utilisation des extensions de certificats pour cette industrie. Page 22 sur 96

23 ISO 21188: Infrastructure de clé publique pour services financiers - Pratique et cadre politique. Cette norme établie un cadre d exigences de gestion d ICP basé sur le développement de politiques de certificats (CP) et d énoncés de pratiques de certification (CPS) dans le but de permettre l utilisation de certificats à clés publiques dans le secteur des services financiers. Elle définit également des objectifs de contrôle ainsi que des procédures de gestion de risques ISO JTC 1 Fondé en 1987, le comité technique JCT 1 Technologies de l information de l Organisation internationale de normalisation (ISO), est assigné à la standardisation des technologies de l information. Une recherche rapide parmi les travaux réalisés par ce comité a permis d identifier deux (2) normes susceptibles de fournir des recommandations pertinentes sur la mise en œuvre et de l exploitation d une ICP au sein des EESS (Entreprises de l Économie Sociale et Solidaire) : ISO/IEC : Technologies de l'information Interconnexion de systèmes ouverts (OSI) L'annuaire : Cadre général des certificats de clé publique et d'attribut. Cette norme, aussi publiée sous ITU Recommendation X.509, définie un «framework» d ICP. Il s agit d une des normes sur laquelle s appuie le groupe de travail PKIX de l IETF pour l élaboration de ses standards [ISO9494]. À noter que du côté de l IETF, le RFC 5280 reprend l essentiel de cette norme. Nous privilégions donc l utilisation de [RFC5280] dans le cadre de ce travail. ISO : Technologies de l'information Techniques de sécurité Critères d'évaluation pour la sécurité TI. Cette norme décrit les critères de sécurité des produits des technologies de l information ainsi qu un «framework» qui permet de les évaluer. L évaluation est basée sur un ensemble de critères communs à plusieurs pays industrialisés. Aussi appelée «Common Criteria», celle-ci permet d attribuer aux produits de sécurité un niveau d assurance appelé Evaluation Assurance Level (EAL) représenté sur une échelle à 7 niveaux. Les produits d ICP propriétaires évalués à la section 4 du présent document détiennent tous deux la certification Common Criteria EAL4+. [ISO15408] ANSI X9 L ANSI (American National Standards Institute) est la voie officielle des États-Unis en matière de standards et d évaluation de conformité des systèmes. Depuis sa fondation en 1979, le comité X9 a pour objectif de standardiser les opérations dans le domaine financier. Ce comité contribue activement à d autres comités tels que le TC 68 d ISO. Parmi les nombreux standards développés et maintenus par ce comité, un seul standard semble s avérer pertinent pour la présente étude. Il s agit du standard suivant : ANSI X PKI policy and practices framework. La norme ANSI x9.79 définit les composantes d une ICP. Elle fixe un cadre de pratiques ainsi qu un ensemble d exigences en matière de politiques d ICP. La norme définit les pratiques opérationnelles par rapport aux objectifs de contrôle des systèmes d information du secteur des services financiers. Page 23 sur 96

24 Bien qu il soit principalement destiné à satisfaire les exigences spécifiques de la communauté financière, ce standard a cependant été très largement adopté dans les autres domaines d affaire utilisant des ICP. Le standard ANSI X9.79 a d ailleurs été adopté par l AICPA/CICA (American and Canadian Institutes for Accountants) dans le cadre de son programme WebTrust qui est utilisé pour évaluer l efficacité des contrôles utilisés par les autorités de certification ITU-T Le groupe ITU-T (Telecommunication Standardization Sector) a pour rôle d établir les standards de télécommunication pour l ITU (International Telecommunication Union). Une des recommandations émises par ce groupe représente un intérêt pour la présente étude, soit : ITU-T Recommendation X.509: Information technology Open systems interconnection The Directory: Public-key and attribute certificate frameworks. Cette norme, aussi publiée sous ISO/IEC :2008 [ISO9594], définit un «framework» d ICP. Il s agit d une des normes sur laquelle s appuie le groupe de travail PKIX de l IETF pour l élaboration de ses standards. À noter que du côté de l IETF, le RFC 5280 reprend l essentiel de cette recommandation (et de son équivalent ISO/IEC :2008). Nous privilégions donc l utilisation du [RFC5280] dans le cadre de ce travail NIST Le NIST (National Institute of Standards and Technology) est une agence américaine dédiée au développement de technologies, de méthodologies et de standards. Les travaux du NIST sont réalisés de concert avec les entreprises américaines afin de contribuer à leur développement économique. La «Computer Security Division» émet différentes publications traitant de différents aspects de la protection des technologies de l information. Plusieurs de ces publications s avèrent d ailleurs être d une grande pertinence pour la présente étude : Publications Spéciales (Série 800). Depuis sa création en en 1990, cette catégorie regroupe les publications relatives à la sécurité des technologies de l information. On y retrouve des publications telles que : o SP Minimum Interoperability Specification for PKI Components. Spécifications minimales en termes d interopérabilité pour les ICP. Cette spécification fût développée lors de l élaboration de l ICP fédérale américaine. o o SP Guideline for Implementing Cryptography in the Federal Government. Recommandations générales sur la sélection des mécanismes cryptographiques. SP Introduction to Public Key Technology and the Federal PKI Infrastructure. Introduction aux différents concepts de l ICP. Cette publication a été développée dans le but d assister les dirigeants d agences fédérales américaines dans leur prise de décision à l effet de mettre en place ou non une ICP. Page 24 sur 96

25 o Projet en génie logiciel SP Recommendation for Key Management. Guide pratique en trois (3) parties qui décrit les bonnes pratiques en matière de gestion et d utilisation des clés cryptographiques. C est d ailleurs sur cette recommandation que certaines autorités de certification commerciales ont récemment procédé au renouvellement de leur certificat racine. Celle-ci stipule qu après 2010, la signature numérique devra être réalisée à l aide d une clé de 2048 bits. Publications FIPS (Federal Information Processing Standards). o FIPS Security Requirements for Cryptographic Modules. Standard cryptographique développé par le gouvernement américain qui permet d évaluer les modules cryptographiques. Cette norme est notamment utilisée pour qualifier les modules cryptographiques utilisés pour le stockage des clés privées des composantes et des utilisateurs de l ICP. Voici une brève description des 4 niveaux de sécurité définis par cette norme : Niveau 1 (le plus faible). Aucun mécanisme de sécurité physique requis (ex. : un logiciel faisant appel à un algorithme cryptographique approuvé sur ordinateur personnel). Niveau 2. Améliore la sécurité du niveau 1 en ajoutant un une exigence d inviolabilité (tamper-evidence). Le boitier de l ordinateur doit pouvoir être barré, et des autocollants doivent permettre de détecter toute ouverture non autorisée. Le module cryptographique doit exiger une authentification basée sur les rôles ou l identité, en plus de détenir la certification Common Criteria EAL2 ou plus. Niveau 3. Améliore la sécurité du niveau 2 en ajoutant des mécanismes physiques qui empêchent tout accès aux paramètres de sécurité critiques du module cryptographique. Ces mécanismes doivent permettre de détecter et de répondre activement à toute tentative d intrusion physique ou de modification du module cryptographique (ex. : boîtier robuste, détection d intrusion provoquant l effacement des paramètres de sécurité critiques, etc.). Le module cryptographique doit exiger une authentification basée sur l identité en plus de détenir la certification Common Criteria EAL3 ou plus. Niveau 4 (le plus élevé). Améliore la sécurité du niveau 3 en ajoutant une enveloppe de protection autour du module cryptographique. Cette enveloppe de protection doit protéger le module cryptographique contre toute compromission pouvant être causée par la fluctuation des conditions environnementales. Le module cryptographique doit exiger une authentification basée sur l identité en plus de détenir la certification Common Criteria EAL4 ou plus. Page 25 sur 96

26 3.3 L infrastructure à clé publique (ICP) Ce chapitre offre une introduction à l infrastructure à clé publique. Souvent désignée par son acronyme anglophone PKI (Public Key Infrastructure), celle-ci constitue en quelque sorte une sous-couche de sécurité, sur laquelle s appuient les services et applications faisant usage de la cryptographie à clé publique. L ICP est constituée de plusieurs de composantes physiques et logicielles, qui sont gouvernées selon un ensemble de politiques et de procédures bien définies. L ICP constitue une pièce importante de la solution à la problématique de la Chaire et de l AI2L, car ses composantes permettent de réaliser la gestion des clés publiques en assurant la prise en charge complète du cycle de vie des certificats à clé publique. De plus, l ICP offre différents services qui vont faciliter l utilisation de la cryptographie à clé publique au sein des EESS (Entreprises de l Économie Sociale et Solidaire). Figure 6 - Vue globale de l'icp. Traduction de [ENTPKI01] Les sections à effectuent un survol de l ICP de manière à identifier ses principales composantes, les différents services de gestion et de sécurité qu elle peut offrir, ainsi que certains enjeux relatifs à son implantation et à son utilisation. Page 26 sur 96

27 3.3.1 Les composantes de l ICP Le groupe PKIX de l IETF propose une vue simplifiée du modèle architectural de l ICP X.509 en la subdivisant en cinq (5) composantes distinctes [RFC 5280], soit : L'entité d extrémité (EE). Abonné et/ou système propriétaire d une clé publique. L'autorité de certification (AC). Composante s acquittant de la signature des certificats numériques servant à la diffusion des clés publiques, ainsi que du maintien du statut de révocation de ceux-ci. L'autorité d'enregistrement (AE). Composante optionnelle à qui l AC délègue certaines fonctions de gestion. L AE est entre autres responsable d effectuer les vérifications concernant l identité des entités d extrémité avant de procéder aux demandes d émission de certificats. L émetteur de liste de révocation de certificats (CRL). Composante qui s acquitte de la génération des listes de révocation de certificats. Cette tâche est souvent réalisée par l AC. Le dépôt. Systèmes distribués où sont stockés les certificats ainsi que les listes de révocation, afin que les utilisateurs puissent les récupérer librement. Ce dépôt prend généralement la forme d un annuaire de type LDAP. Figure 7 - Les composantes et les entités de l'icp. Source [RFC5280] Il existe d autres composantes dont ne fait pas mention l IETF, mais qui peuvent s avérer nécessaires dans certains cas : Page 27 sur 96

28 L'Autorité de Séquestre. Composante ayant pour mission de stocker, de manière sécurisée, les clés de chiffrement qui ont été générées par l'icp. Le séquestre de clés permet aux autorités d obtenir les clés de déchiffrement appartenant aux entités d extrémité de l ICP lorsqu elles désirent déchiffrer des données suspectes. Par exemple, cette composante pourrait permettre à une entreprise de récupérer des données lui appartenant suite au congédiement d un employé. Serveur OCSP. Composante ayant pour mission d effectuer la vérification relative au statut de révocation d un certificat. Ce service répondant à la norme IETF [RFC2560] permet de faciliter la tâche des applications, en leur évitant d avoir à obtenir la liste de révocation provenant des différentes ICP de confiance. Serveur d horodatage. Composante ayant pour mission de garantir électroniquement la date et l heure d une opération selon la méthode décrite dans la norme IETF [RFC3161]. Il faut noter que malgré cette subdivision, il est possible que dans certaines implantations, l AC s acquitte des rôles d autorité d enregistrement, d émetteur de listes de révocation ou d autorité de séquestre. Cependant, lorsque ces rôles sont délégués à des composantes externes, l AC doit avoir en elles une confiance absolue, ce qui implique qu elles doivent être soumises à des politiques de sécurité aussi strictes que l AC elle-même Les services de gestion offerts par l ICP Le tableau suivant décrit sommairement les différents services de gestion qui sont généralement offerts par les ICP. Service Description Enregistrement des abonnés Service par lequel : l AC (ou l AE) procède à l identification, ainsi qu à l authentification de l abonné. l AC procède à l émission du certificat contenant la clé publique de l abonné. En apposant sa signature numérique sur le certificat d un abonné, l AC certifie que la clé publique contenue dans le certificat appartient bel et bien à l abonné identifié par le certificat. Révocation de certificats Publication de certificats Recouvrement de clés Service qui permet de signaler qu un certificat n est plus valide, suite à la perte ou la compromission de la clé privée associée par exemple. Service par lequel l AC rend public le certificat à clé publique des abonnés, de manière à permettre aux utilisateurs de les obtenir au besoin. Service permettant d effectuer une sauvegarde sécurisée de la clé le déchiffrement. Ainsi, les données chiffrées pourraient être récupérées dans l éventualité où un abonné n aurait plus accès à sa clé de déchiffrement, par exemple dans le cas du crash de Page 28 sur 96

29 Service Séquestre de clés Service de vérification en ligne (OCSP) Service de vérification hors ligne (CRL) Description son poste de travail. Service similaire au recouvrement, mais destiné à permettre à un parti autorisé d obtenir la clé de déchiffrement d un abonné, afin de lui permettre de déchiffrer des données ayant été chiffrées pour ce dernier. Ceci permet, entre autres, à une entreprise d avoir accès à des communications privées d un employé. Service permettant à un utilisateur de déterminer si un certificat a fait l objet d une révocation, sans avoir à gérer de listes de révocation (CRL). Service permettant à un utilisateur de récupérer une liste de certificats ayant fait l objet d une révocation (CRL). Cette liste est publiée périodiquement par un service de l ICP (sur un site Web, dans un annuaire LDAP, etc.), puis récupérée par les utilisateurs selon un intervalle défini par une politique de l ICP. Table 4 - Services de gestion offerts par l ICP. Inspiré de [ADAMS03] Les services de sécurité offerts par l ICP L ICP met à la disposition des utilisateurs de la cryptographie à clé publique différents services de sécurité. Le tableau suivant décrit brièvement les trois (3) services de sécurité fondamentaux offerts par la cryptographie à clé publique. Service Authentification Intégrité Confidentialité Description Service qui permet à un utilisateur de s assurer qu une entité est réellement qui elle prétend être. Service qui permet à un utilisateur de s assurer que des données n ont pas été altérées de manière intentionnelle ou non, en transit ou depuis un certain temps. Service qui permet à un utilisateur de s assurer que seule l entité à qui sont destinées les données pourra les interpréter correctement. Table 5 - Description des services primaires offerts par l ICP. Inspiré de [ADAMS03] Le tableau suivant offre une brève description des services complémentaires rendus possibles par l ICP. Contrairement aux trois (3) services fondamentaux décrits précédemment, ces services peuvent être offerts en option par l ICP, ou par des entités externes. Tous ces services ont cependant la propriété d être réalisables en faisant appel aux trois (3) principes fondamentaux décrits ci-haut. Service Communication sécurisée Description Service permettant de transmettre des données entre deux entités (un transmetteur et un receveur), en assurant au moins une des propriétés suivantes : authenticité, intégrité et confidentialité. Parmi les plus répandus, nous pouvons citer : le courriel sécurisé (S/MIME), SSL, VPN, etc. Page 29 sur 96

30 Service Horodatage Notarisation Non-répudiation Gestions des privilèges Description Mécanisme permettant de lier «cryptographiquement» des données à une date/heure précise. Ceci permet de prouver que les données associées existaient après cette date précise. Mécanisme permettant de certifier, hors de tout doute, que les données concernées sont valides et correctes. Ce mécanisme repose sur d autres services de l ICP tels que l authentification et l horodatage. Mécanisme permettant d assurer que les entités d extrémité demeurent honnêtes quant à leurs actions. Les preuves cryptographiques offertes par ce mécanisme font en sorte que celles-ci ne peuvent nier leurs actions, à moins d évoquer la négligence ou le fait que leur clé privée ait été compromise à leur insu. Mécanisme permettant d identifier et de contrôler ce qu une entité est en mesure d accéder et d exécuter dans un environnement spécifique. Table 6 - Services complémentaires offerts par l ICP. Inspiré de [ADAMS03] Les protocoles de l ICP Cette section décrit brièvement les principaux protocoles supportés par les différentes composantes de l ICP. Ces protocoles permettent aux utilisateurs de l ICP de faire appel aux différents services offerts par l ICP OCSP (Online Certificate Status Protocol) Ce protocole développé par le groupe PKIX de l IETF [RFC2560], permet aux clients de faire appel à une autorité de confiance pour réaliser la validation des certificats qu ils utilisent. Il s agit d une alternative intéressante aux listes de révocation de certificats (CRL), car d une part elle permet d alléger et de simplifier le traitement réalisé du côté client, et d autre part de s assurer que la validation est réalisée de manière adéquate en se basant sur liste de révocation à jour. Les messages du protocole OCSP peuvent être véhiculés à l aide de protocoles applicatifs tels que HTTP, SMTP, LDAP et autres PKIX-CMP (Certificate Management Protocol) Ce protocole développé par le groupe PKIX de l IETF [RFC4210], permet aux utilisateurs de l ICP de réaliser à distance certaines opérations de gestion des certificats à clé publique. À l aide de ce protocole, un utilisateur peut donc : S enregistrer auprès de l ICP et recevoir son certificat; Recouvrer ses clés; Effectuer la mise à jour de ses clés; Renouveler son certificat; Effectuer une demande de révocation; Etc. Page 30 sur 96

31 Les messages du protocole CMP peuvent être véhiculés à l aide de protocoles applicatifs tels que HTTP, SMTP, FTP et autres SCEP (Simple Certificate Enrollment Protocol) Ce protocole développé par Cisco Systems permet d automatiser le déploiement des certificats X.509 sur des équipements réseau (ex. VPN IPSec). Ce protocole fait appel aux formats définis par les standards PKCS #7 (PKCS07) et PKCS #10 (PKCS10). Le protocole SCEP permet de réaliser les opérations suivantes : Récupérer les clés publiques des AC et des AE; S enregistrer auprès de l ICP; Effectuer une demande de certificat; Récupérer une CRL (liste de révocation de certificats); Les messages du protocole SCEP sont véhiculés à l aide du protocole HTTP XKMS (XML Key Management Specification) Ce protocole développé conjointement par le Microsoft, Verisign, WebMethods et le W3C (World Wide Web Consortium) [XKMS], permet la distribution ainsi que l enregistrement des clés publiques en faisant appel à la syntaxe XML. Ce protocole a été conçu afin d être compatible avec XML-SIG (XML Signatures). Le protocole XKMS est en fait composé de deux protocoles, soit : X-KISS (XML Key Information Service Specification); X-KRSS (XML Key Registration Service Specification); Les messages du protocole XKMS sont véhiculés à l aide du protocole SOAP (Simple Object Access Protocol) TSP (Time-Stamp Protocol) Ce protocole développé par le groupe PKIX de l IETF [RFC4210], permet aux utilisateurs de l ICP d échanger avec le service d horodatage Time Stamping Authority (TSA). Le service TSA permet de générer des assertions qui attestent qu une donnée existait à un moment précis dans le temps. Ce service est utilisé par les services de non-répudiation. Les messages du protocole TSP sont véhiculés à l aide du protocole applicatif HTTP Le certificat à clé publique Le certificat à clé publique ou «certificat numérique» est un «document électronique délivré par une autorité de certification, qui garantit l'authenticité des clés publiques contenues dans un annuaire» [OLF]. On le compare souvent à une carte d'identité numérique qui permet d'identifier une entité au même titre qu un permis de conduire ou qu un passeport. On utilise le certificat numérique pour transporter la clé publique des entités. Celui-ci permet de créer l association entre la clé publique et le nom de l entité à qui appartient cette clé. Page 31 sur 96

32 Le certificat numérique prend donc la forme d un bloc de données structuré, répondant à un format normalisé. Bien qu il existe plusieurs formats de certificats (ex. : X.509, PGP, SPKI, etc.), le format X.509 est aujourd hui la norme de l industrie qui permet d assurer l interopérabilité entre les différents systèmes. La figure suivante illustre la structure d un certificat répondant à la norme X.509. Figure 8 - Certificat numérique X.509. Source [NETASSI] Publiée en 1988 par l Union internationale des télécommunications (ITU-T), et ISO/IEC , la norme X.509 faisait partie des recommandations X.500 sur les annuaires. Cette norme a évolué depuis son introduction, et depuis 1995, le groupe de travail PKIX de l IETF s affaire au développement des standards internet supportant le standard X.509. Les travaux du groupe PKIX ont conduit l élaboration de standards qui constituent aujourd hui la référence en matière d ICP. Le tableau suivant résume l évolution du format X.509 depuis sa publication initiale. Année Version Évolution 1988 X.509 Version 1 Création du standard assumant une hiérarchie d autorités de certification émettrices de certificats X.509 Version 2 Ajout de deux champs supplémentaires : issueruniqueidentifier; subjectuniqueidentifier; Cet ajout avait pour objectif de permettre la réutilisation des noms dans le temps X.509 Version 3 Version la plus récente et la plus utilisée. Ajout du support pour les extensions telles que KeyUsage et AlternativeNames. Table 7 - Évolution du certificat X.509 Page 32 sur 96

33 Lors de l émission d un certificat, l AC insère la clé publique de l entité dans le certificat, puis elle y appose sa signature numérique. En plus de permettre de contrôler l intégrité et l authenticité du certificat, cette signature atteste qu au meilleur des connaissances de l AC, la clé publique qu il contient appartient bel et bien à l entité pour laquelle a été émis le certificat. Ainsi, avant d utiliser la clé publique contenue dans ce certificat, les utilisateurs pourront s assurer que l entité pour laquelle a été émis le certificat est réellement en possession de la clé privée associée. Le tableau suivant décrit brièvement chacun des attributs d un certificat X.509 v3. Attribut Version SerialNumber Issuer Validity Subject SubjectPublicKeyInfo Extensions Signature Description Numéro de version du standard X.509 auquel répond le certificat. Numéro d identification du certificat. Ce numéro unique permet d identifier le certificat parmi tous les certificats émis par une AC. Identité de l AC ayant émis le certificat. Période de validité du certificat. Il s agit de l intervalle de temps durant laquelle l AC s engage à maintenir le statut de validité du certificat. Identité de l entité à qui appartient la clé publique contenue dans le certificat. Clé publique de l entité ainsi que l algorithme associé (ex. : RSA). Attribut permettant d ajouter d autres attributs sans affecter la définition de la structure du certificat. Signature apposée par l AC ainsi que l identifiant de l algorithme ainsi que de la fonction de hachage utilisé pour signer le certificat. Table 8 - Attributs d'un certificat X.509 v3 Les sections qui suivent abordent trois (3) importants concepts liés aux certificats à clé publique soit les classes de certificats pouvant être gérés par une AC, le nommage, c'est-à-dire la manière de nommer le propriétaire ainsi que l AC émettrice d un certificat, et finalement les extensions qui permettent d ajouter des attributs supplémentaires au certificat Les classes de certificats Le groupe de travail PKIX de l IETF fait état de l existence de deux (2) classes de certificats à clés publiques [RFC5280], soit : Les certificats d entités d extrémité (end-entity). Certificats émis par une AC, pour des entités qui ne sont pas des émetteurs de certificats. Les certificats d AC. Certificats émis par une AC, pour des entités qui sont elles-mêmes des AC capables d émettre des certificats à clé publique. Les certificats d AC peuvent aussi être classés en trois (3) sous-catégories, soit : o Les certificats autoémis (self-issued certificates). Certificats dont l émetteur et le sujet représentent la même entité. Une AC pourrait, par exemple, utiliser ce type de certificat durant l'opération de rotation de clés, afin d offrir la confiance de l ancienne clé vers la nouvelle. Page 33 sur 96

34 o o Les certificats autosignés (self-signed certificates). Cas spécial de certificats autoémis, où la clé privée utilisée par l AC pour signer le certificat correspond à la clé publique contenue dans ce même certificat. Une autorité de certification à la racine d un chemin de certification va générer puis signer elle-même sa propre clé puisqu il n existe aucune AC au-dessus de celle-ci. Les certificats croisés (cross-certificates). Certificat d AC pour lequel l émetteur et le sujet sont des entités différentes. Ce certificat permet de reconnaitre l existence d une autre AC dans un modèle de confiance en réseau Le nommage Les attributs «Subject» et «Issuer» identifient respectivement l entité propriétaire de la clé publique qu il contient, ainsi que l AC émettrice du certificat. La valeur de ces attributs est spécifiée sous la forme d un «distinguished name» (DN), définit par la norme X.501. Il s agit en fait de la méthode de nommage utilisée par les annuaires X.500 ainsi que LDAP (Lightweight Directory Access Protocol) [RFC4510], dont l usage est aujourd hui très répandu. Cette méthode de nommage permet de représenter, à l aide d une chaine de caractères, le nom unique d une entité. Ce nom correspond à la position de l entrée dans un modèle hiérarchique qui décrit l environnement dans lequel existe l entité. Le DN représente le chemin absolu qui permet de retrouver l entité dans la hiérarchie. Ayant pour point de départ l entité elle-même, le chemin exprimé par cette notation permet de remonter jusqu à la racine de la hiérarchie en parcourant chacune des entrées intermédiaires (nœuds). Dans l exemple suivant, le DN identifie le certificat de l entité «Serveur1», émis par «AC1», une AC de l ICP de l organisation «AI2L.org» : CN=Serveur1, OU=Certs, OU=AC1, OU=ICP, O=AI2L.org Le diagramme suivant illustre la structure du DN dans son environnement. Figure 9 - Exemple de la structure hiérarchique d'un DN Dans l exemple précédant, les attributs utilisés pour nommer chacune des entrées du DN sont définis dans le standard LDAP. Ces attributs tirent leurs origines de la norme X.500. Page 34 sur 96

35 Le tableau suivant énumère les attributs standard couramment utilisés pour nommer les entrés dans un annuaire. String X.500 Attribute Type CN commonname ( ) L localityname ( ) ST stateorprovincename ( ) O organizationname ( ) OU organizationalunitname ( ) C countryname ( ) STREET streetaddress ( ) DC domaincomponent ( ) UID userid ( ) Table 9 - Attributs de nommage LDAP standard. Source [RFC4514] Les extensions Les premiers déploiements d ICP ont démontré que les informations offertes par les attributs de base des certificats X.509 n offraient pas suffisamment d information. Les utilisateurs des certificats n étaient pas en mesure d obtenir suffisamment d information sur l émetteur, l entité d extrémité ou la clé publique elle-même [BL-03]. Le mécanisme d extension a donc été développé afin de permettre à l AC d ajouter des attributs supplémentaires aux certificats X.509 v3 lors de leur émission. Une AC peut donc optionnellement utiliser les extensions standards définies par la norme X.509, ou bien définir au besoin ses propres extensions. Une extension se compose de trois éléments de données, soit : Un identifiant; Un indicateur de criticité; Des données associées; L indicateur de criticité permet d indiquer aux utilisateurs du certificat s ils ont l obligation de traiter cette extension, ou s ils peuvent tout simplement l ignorer. Selon la norme X.509 v3, un utilisateur qui ne reconnait pas une extension marquée par l AC comme étant critique ne peut accepter ce certificat. Le tableau suivant offre une brève description des extensions standards qui sont décrites en détail dans la spécification [RFC5280]. Extension Authority Key Identifier Subject Key Identifier Key Usage Description Permet d identifier la clé publique correspondant à la clé de signature utilisée par l AC pour signer le certificat. Une AC peut détenir plusieurs jeux de clés, suite à des renouvellements par exemple. Permet d identifier la clé publique que contient le certificat. Une entité peut détenir plus d une paire de clés. Permet de restreindre l utilisation de la clé publique contenue dans un certificat à des opérations spécifiques telles que : digitalsignature; Page 35 sur 96

36 Extension Certificate Policies Policy Mappings Subject Alternative Name Issuer Alternative Name Subject Directory Attribute Basic Constraints Name Constraints Policy Constraints Extended Key Usage CRL Distribution Point Description nonrepudiation; keyencipherment; dataencipherment; keyagreement; keycertsign; crlsign; encipheronly; decipheronly; Permet de spécifier la liste des politiques applicables à l émission ainsi qu à l utilisation du certificat. Les politiques définissent les règles d applicabilité du certificat dans un domaine particulier. Permet de spécifier des équivalences entre des politiques de deux domaines de certification. Permet de spécifier un nom alternatif afin de désigner l entité à qui appartient la clé publique (ex. : adresse de courriel, nom DNS, etc.). Permet de spécifier un nom alternatif afin de désigner l AC ayant émis le certificat (ex. : adresse de courriel, nom DNS, etc.). Permet de spécifier des attributs supplémentaires concernant l entité propriétaire de la clé publique. Permet de spécifier s il s agit d un certificat d AC ainsi que la longueur maximale du chemin de certification permis sous ce certificat. Cette extension permet donc de restreindre le nombre d AC subordonné dans la hiérarchie d AC. Permet de spécifier l espace de nommage dans lequel devra se retrouver l ensemble des entités pour qui l AC émettra des certificats. Applicable uniquement aux certificats d AC. Permet de contrôler l application des politiques sur les certificats émis par l AC. Applicable uniquement aux certificats d AC. Permet de spécifier les conditions d utilisation prévues pour le certificat. Peut remplacer ou complémenter l extension «Key Usage». Le groupe PKIX a défini les conditions d utilisation suivantes : id_kp_serverauth; id_kp_clientauth; id_kp_codesigning; id_kp_ protection; id_kp_ipsecendsystem; id_kp_ipsectunnel; id_kp_ipsecuser; id_kp_timestamping; OCSPSigning; Permet de spécifier comment la liste de révocation de l AC émettrice peut être obtenue. La valeur spécifiée prend la forme Page 36 sur 96

37 Extension Description d une liste d URI (LDAP, HTTP, etc.). Projet en génie logiciel Inhibit anypolicy Permet de contrôler l application de la politique «Wildcard» anypolicy. Applicable uniquement aux certificats d AC. Freshest CRL Permet de spécifier comment obtenir la liste de révocation la plus récente. Similaire à l extension «CRL Distribution Point», mais conçue pour être utilisée avec les Delta CRL. Table 10 - Les extensions standards X.509 v La gestion du cycle de vie des clés et des certificats Un des principaux rôles de l ICP est de s acquitter de la gestion complète du cycle de vie des clés et des certificats. Le cycle de vie des clés et des certificats se divise en trois (3) phases distinctes, soit : Initialisation. Phase initiale du cycle de vie durant laquelle une entité effectue des démarches pour s abonner à l ICP. Émis. Phase durant laquelle le certificat d une entité a été émis et est considéré comme étant valide. Annulation. Phase finale du cycle de vie durant laquelle le certificat d une entité devient invalide. Figure 10 - Cycle de vie des certificats. Traduction de [ADAMS03] Cette section décrit brièvement chacun des processus pouvant être exécutés dans le cadre des différentes phases, telles qu exposées dans [ADAMS03]. Page 37 sur 96

38 Phase «Initialisation» Enregistrement C est lors du processus d enregistrement qu est réalisé l ensemble des vérifications quant à l identité de l entité d extrémité qui désire s abonner à l ICP. Les vérifications à réaliser sont dictées par les politiques de l ICP. Le processus d enregistrement peut être réalisé de différentes manières. La figure suivante illustre un scénario d enregistrement réalisé à partir d un fureteur Web auprès d une autorité d enregistrement. Figure 11 - Enregistrement auprès d'une AE Web. Traduction de [ADAMS03] À noter que dans ce type de scénario, la requête de certificat qui est réalisée par l entité d extrémité nécessite la spécification d un mot de passe. Ce mot de passe aura préalablement été communiqué à l entité d extrémité par l AE suite à l enregistrement. L enregistrement peut aussi s effectuer en contactant directement l AC. L utilisation d une AE est un choix d implantation qui se justifie en fonction des besoins et de la configuration de l ICP. De plus, il faut savoir qu il est aussi possible de réaliser l enregistrement en fournissant un CSR (Certificate Signinig Request) ou en utilisant un protocole tel que SCEP (Simple Certificate Enrollment Protocol), utilisé par différents manufacturiers d équipement réseau Génération de la paire de clés C est par ce processus qu est générée la paire de clés (privée et publique) d une entité d extrémité. Cette génération peut s effectuer tant du côté de l entité d extrémité ellemême, que du côté de l AC. La technique à utiliser peut varier en fonction de différents facteurs. Par exemple, lorsque la paire de clés sera utilisée pour des fins de nonrépudiation, il est préférable d effectuer la génération du côté de l entité d extrémité, car de cette manière, on s assure que seule cette dernière aura eu en sa possession la clé privée. Page 38 sur 96

39 Création du certificat et distribution de la clé et du certificat C est par ce processus que l entité d extrémité reçoit son certificat ayant été signé par l AC, ainsi que la clé privée associée lorsque cette dernière fut générée par l AC. Des protocoles tels que CMP (Certificate Management Protocol) ou SCEP (Simple Certificate Enrollment Protocol), ainsi que des formats tels que PKCS 7 ou 10, sont souvent utilisés dans le cadre de ce processus Dissémination du certificat C est par ce processus que le certificat d une entité d extrémité est publié afin que les utilisateurs de l ICP puissent l utiliser. De façon générale, cette opération consiste à placer le certificat dans un dépôt public, qui prend généralement la forme d un annuaire LDAP (Lightweight Directory Access Protocol). Il arrive cependant que le certificat soit distribué automatiquement avec un document sur lequel une entité a apposé sa signature. Cette technique a pour avantage de faciliter la tâche de l utilisateur qui désire procéder à la validation de la signature Sauvegarde de la clé C est par ce processus que la clé privée d une entité d extrémité peut être confiée à une autorité de confiance, afin de constituer une copie de sauvegarde. Cette technique offre à une entité d extrémité la possibilité de récupérer sa clé privée dans le cas où celle-ci deviendrait inaccessible (perte ou corruption). De cette manière, l entité pourrait récupérer des données ayant été chiffrées à l aide de sa clé publique. À noter que la sauvegarde de clé ne devrait être appliquée qu aux clés destinées au chiffrement. La sauvegarde de clés de signature n offre aucun avantage puisque les signatures sont vérifiées à l aide de la clé publique, et que l entité devrait être la seule à détenir cette clé Phase «Émis» Récupération du certificat C est par ce processus qu un utilisateur de l ICP peut obtenir le certificat d une entité d extrémité afin de chiffrer des données destinées à cette entité, ou de valider une signature ayant été apposée par celle-ci Validation du certificat C est par ce processus qu un utilisateur de l ICP s assure de la validité du certificat d une entité d extrémité. Le processus de validation implique un certain nombre de vérifications telles que : construction et la validation du chemin de certification; vérification de l intégrité du certificat; vérification de l intervalle de validité du certificat; vérification du statut du certificat (révoqué ou non) à partir d une liste de révocation ou en faisant appel au protocole OCSP (Online Certificate Status Protocol); vérification du respect des politiques d utilisation du certificat; Page 39 sur 96

40 Ce n est qu après avoir réalisé l ensemble de ces validations avec succès que l utilisateur peut utiliser la clé publique de l entité pour réaliser des opérations cryptographiques Recouvrement de clés C est par ce processus qu une entité d extrémité peut récupérer sa clé privée après que celle-ci ait été perdue ou endommagée Mise à jour des clés C est par ce processus qu une entité d extrémité peut procéder à l obtention de nouvelles clés avant que celles-ci n arrivent à échéance. Lors de cette opération, l AC procède à la génération d une nouvelle paire de clés, ainsi que d un nouveau certificat pour cette entité Phase «Annulation» Expiration du certificat C est par ce processus que le certificat d une entité d extrémité arrive à échéance. Si l'on ne pose aucune action, le certificat de l entité ne sera tout simplement plus valide lorsque celui-ci atteindra la fin de sa période de validité. Il est aussi possible de procéder automatiquement au renouvellement du certificat, qui consiste à réémettre un nouveau certificat contenant la même clé, ou bien à procéder à une mise à jour des clés Révocation du certificat C est par ce processus que le certificat d une entité d extrémité peut être annulé avant qu il arrive à échéance (expiration naturelle). Ce processus peut être initié par l entité d extrémité elle-même, après avoir suspecté la compromission de sa clé privée, ou par un administrateur d une entreprise, suite au départ d un employé par exemple Historique de clés C est par ce processus que la clé d une entité d extrémité est conservée afin de permettre de déchiffrer des données après la période de validité du certificat contenant la clé publique correspondante. L historique de clés peut tout aussi bien être conservé du côté de l entité d extrémité que du côté de l AC Archive de clés C est par ce processus que les clés de chiffrement de données et de vérification de signatures d une entité d extrémité sont conservées afin de permettre à des tiers de confiance de procéder ultérieurement à certaines vérifications. Ce mécanisme est normalement utilisé conjointement avec les services d horodatage et de notarisation. Page 40 sur 96

41 3.3.7 La confiance D un point de vue technique, la génération de certificats à clé publique constitue en soi une opération relativement simple. Il existe aujourd hui des logiciels (ex. OpenSSL) qui permettent d émettre des certificats sans trop d efforts. Ces logiciels peuvent être téléchargés librement et gratuitement sur l internet. Il est ainsi possible, pour quiconque désirant générer des certificats, d installer ce type de logiciel sur son poste de travail personnel, de créer sa propre autorité de certification, et ainsi procéder à la génération de certificats à clé publique. Les certificats générés par ces autorités de certification improvisées sont tout aussi valides que ceux ayant été générés par une autorité de certification reconnue. Ils respectent le standard X.509 et peuvent être utilisés par les différents systèmes de sécurité faisant usage de la cryptographie à clé publique. Le respect du standard X.509 permet d assurer une compatibilité d un point de vue technique, mais n offre que très peu de valeur en termes de sécurité. Bien que les certificats générés de cette manière puissent satisfaire des besoins liés à un usage personnel, tel que le chiffrement de fichiers par exemple, il en est autrement pour des opérations plus critiques, telles que des échanges entre partenaires d affaires, ou des transferts de fonds entre des institutions financières. C est la notion de «confiance» qui confère à un certificat numérique toute sa valeur en termes de sécurité. Le niveau de confiance que l on accorde à une autorité de certification qui a émis un certificat à clé publique permet d évaluer le niveau de risque associé à l utilisation de ce certificat. Le niveau de confiance que l'on peut accorder à une infrastructure à clé publique est basé sur les politiques de certification ainsi que sur l'intégrité de ses AC. Cette intégrité découle de la protection de sa clé de signature. Cette clé sert à signer les certificats à clé publique des entités d extrémité de l ICP. De plus, dans le cas d une AC racine, cette clé de signature est aussi utilisée pour signer sa propre clé publique. Lorsque la clé de signature d une AC est compromise, cela signifie que tous les certificats signés par cette AC ainsi que par les AC subordonnées, deviennent aussitôt suspectes, et ainsi la crédibilité de l'icp est détruite. Cette section effectue un survol des modèles de confiance ainsi que du mécanisme de validation qui permet d établir le niveau de confiance d un utilisateur envers un certificat Le chemin de certification Un des rôles de l ICP est d offrir l assurance aux utilisateurs que la clé publique contenue dans un certificat numérique appartient bel et bien à l entité pour qui a été émis le certificat. L obtention de cette assurance comporte les deux implications suivantes : 1. L utilisateur doit être en mesure de remonter le chemin de certification qui atteste de l authenticité du certificat de l entité d extrémité (Certification Path Construction). 2. L utilisateur doit valider chacun des certificats composant le chemin de certification, afin de s assurer de la validité du certificat de l entité d extrémité (Certificate Path Validation). Page 41 sur 96

42 La complexité de ces opérations dépend entre autres du modèle de confiance de l ICP. La validation du chemin de certification s effectue selon un algorithme défini dans la norme X.509. En résumé, les utilisateurs doivent être en mesure d obtenir et de valider chacun des certificats constituant le chemin de certification du certificat à vérifier. Ce n est qu après avoir complété cette validation avec succès que les utilisateurs sont assurés de l authenticité du certificat de l entité. Figure 12 - Exemple d'un chemin de certification à 3 niveaux Les modèles de confiance Le modèle de confiance, souvent appelé «Architecture de l ICP», est le modèle qui définit les relations qui existent entre différentes autorités de certifications de l ICP. Il existe plusieurs modèles de confiance de niveaux de complexité différents. La complexité du modèle de confiance a un impact direct sur la facilité qu auront les utilisateurs à s assurer de la validité d un certificat à clé publique. Selon [HOUSL01], les modèles de confiance peuvent être différenciés en fonction des caractéristiques suivantes : Le nombre d AC mis en relation; Les types de relations qui existent entre les différentes AC; La facilité avec laquelle une nouvelle AC peut être ajoutée à l ICP; Le niveau de complexité associé à la construction du chemin de certification; L impact de la compromission d une AC; Page 42 sur 96

43 Cette section décrit les modèles de confiance les plus répandus, ainsi que leurs avantages et inconvénients respectifs Modèle simple avec AC unique Caractéristique Nombre d AC en relation Types de relations entre AC Ajout d une nouvelle AC Complexité associée à la création du chemin de certification Résilience face à la compromission d une AC Valeur Une seule. n/a n/a Très faible complexité en raison du fait qu il n existe qu une seule AC. Tous les certificats sont émis par cette AC. Impact désastreux. Tous les certificats émis par cette AC doivent être révoqués. L ICP n est plus utilisable tant que tous les certificats n ont pas été réémis. Remarques Modèle peu évolutif. Table 11 - Caractéristiques du modèle de confiance simple avec AC unique Figure 13 - Modèle de confiance simple avec AC unique Page 43 sur 96

44 Modèle simple avec liste de confiance Caractéristique Nombre d AC en relation Types de relations entre AC Ajout d une nouvelle AC Complexité associée à la création du chemin de certification Résilience face à la compromission d une AC Valeur Plusieurs Projet en génie logiciel Aucun. L'utilisateur gère lui-même la liste des certificats des autorités de certification en qui il a «confiance». L utilisateur ajoute lui-même le certificat de la nouvelle AC dans sa liste de confiance. Très faible complexité en raison du fait qu il n y a pas de chemin de certification. Les seuls certificats acceptés sont ceux qui ont été émis par les AC dont les certificats se trouvent dans la liste de confiance. Très difficile à gérer en raison du fait que l utilisateur ne sera jamais avisé de la révocation d un certificat d AC se trouvant dans sa liste de confiance. Remarques Modèle très simple, peu évolutif et difficile à gérer. Entre autres utilisé par les fureteurs Web. Table 12 - Caractéristiques du modèle de confiance simple avec liste de confiance Figure 14 - Modèle de confiance simple avec liste de confiance Page 44 sur 96

45 Modèle Hiérarchique Caractéristique Types de relations entre AC Ajout d une nouvelle AC Complexité associée à la création du chemin de certification Résilience face à la compromission d une AC Valeur Supérieure à subordonnée. Projet en génie logiciel Facile en émettant un nouveau certificat à la nouvelle AC à partir d une AC existante. Faible complexité en raison du fait que chaque AC n a qu un seul et unique supérieur. Il s agit d une opération déterministe. AC Racine : Impact désastreux. Tous les certificats émis par cette AC, ainsi que les AC subordonnées doivent être révoquées. L ICP n est plus utilisable tant que tous les certificats n ont pas été réémis. Subordonnée : Impact limité. Seuls les certificats émis par l AC subordonnée, ainsi que par les AC subordonnées à celle-ci doivent être révoqués. Remarques L opération hors-ligne de l AC racine permet de grandement limiter les risques de compromission de cette AC. Table 13 - Caractéristiques du modèle de confiance Hiérarchique Figure 15 - Modèle de confiance Hiérarchique Page 45 sur 96

46 Modèle en réseau Caractéristique Nombre d AC en relation Valeur Plusieurs. Types de relations entre AC «Peer-to-Peer». Ajout d une nouvelle AC Complexité associée à la création du chemin de certification Résilience face à la compromission d une AC Projet en génie logiciel Facile. La nouvelle AC échange son certificat avec une autre AC déjà membre du réseau. Élevée en raison du fait qu il s agit d une opération non déterministe, puisqu il peut exister plusieurs chemins possibles. Certains chemins peuvent s avérer être invalides ou amener à tourner en rond. Faible impact en raison de ses multiples points de confiance distincts. L AC ayant émis le certificat à l AC compromise n a qu à révoquer ce certificat et celle-ci sera automatiquement exclue du réseau. Remarques Les certificats émis dans ce modèle sont plus complexes. Il est plus difficile de gérer les politiques en fonction du type de certificat émis. Table 14 - Caractéristiques du modèle de confiance en réseau Figure 16 - Modèle de confiance en réseau Page 46 sur 96

47 Modèle Hybride Caractéristique Nombre d AC en relation Types de relations entre AC Ajout d une nouvelle AC Complexité associée à la création du chemin de certification Résilience face à la compromission d une AC Remarques Valeur Plusieurs. Supérieure à subordonnée. «Peer-to-Peer». Facile. L AC d un domaine échange son certificat avec une AC d un autre domaine. Élevée en raison du fait qu il s agit d une combinaison entre les modèles hiérarchiques et réseaux. Il est donc difficile de trouver un chemin valide. Faible impact en raison des considérations énoncées pour le modèle réseau. De plus, les utilisateurs peuvent se fier sur leur autorité locale pour le signalement d une compromission. Il est tout de même préférable de conserver un faible nombre de relations de type certification croisées entre les domaines. Table 15 - Caractéristiques du modèle de confiance Hybride Figure 17 - Modèle de confiance Hybride Page 47 sur 96

48 Les politiques Projet en génie logiciel Il a été mentionné précédemment que l ICP est constituée de plusieurs composantes qui sont gouvernées selon un ensemble de politiques et de procédures bien définies. Ces politiques et procédures sont décrites dans deux (2) documents, soit : La politique de certification (CP); L énoncé des pratiques de certification (CPS). Ces deux documents sont d une importance capitale pour une ICP, car ils constituent en quelque sorte le contrat qui définit les rôles et responsabilités de l AC envers les entités d extrémité, les utilisateurs, ainsi que les autres AC avec qui elle a établi des liens de certification croisés. De plus, ces documents constituent des intrants importants lors des audits internes et externes. Cette section a pour objectif de présenter brièvement ces deux documents La politique de certification (CP) La politique de certification, abrégée par le sigle CP (dérivé de son nom anglophone «Certificate Policy»), définit l ensemble des politiques applicables aux types de certificats émis par l autorité de certification. La norme X.509 définit le CP comme étant : «un ensemble de règles nommées qui indiquent l applicabilité d un certificat à une communauté particulière et/ou à une classe d applications ayant des exigences de sécurité communes» [RFC3647] Les utilisateurs peuvent donc consulter cette politique afin de déterminer si un certificat émis par une AC peut être utilisé pour réaliser une opération spécifique. Par exemple, une AC, par le biais d une de ses règles, peut restreindre de manière explicite, l utilisation d un certificat en fonction du niveau de confiance qui peut lui être attribué. Ainsi, dans un contexte de commerce électronique, un certificat pourrait être utilisé pour authentifier un abonné uniquement dans le cadre d une transaction dont l enjeu financier est inférieur à un certain montant. La CP décrit donc l aspect contractuel qui définit les responsabilités et obligations de l AC, des entités d extrémité, des utilisateurs, ainsi que de tout autre parti susceptible d intervenir dans le cycle de vie des certificats émis par l AC. On y précise les conditions d utilisation des certificats, ainsi que les responsabilités assumées par l AC dans ce contexte. Le niveau de détail et de précision que doit comporter la CP est déterminé par le niveau d assurance que l AC doit offrir pour les certificats émis sous cette politique. Le RFC 3647, offre un support à la rédaction de la CP. On y explique les différents concepts impliqués et on y propose une table des matières couvrant l ensemble des éléments devant y figurer. En résumé, la CP décrit ce qui doit être fait afin de satisfaire les objectifs d affaires, les exigences légales, la culture organisationnelle corporative [HOUSL01]. Plusieurs AC peuvent être gouvernées selon une CP commune, et une CP peut définir plusieurs politiques. La CP permet entre autres de déterminer si les règles d une AC conviennent au modèle d une autre AC au moment d effectuer une certification croisée. La CP constitue un intrant important de l audit réalisé lors de la certification. Page 48 sur 96

49 L énoncé des pratiques de certification (CPS) L énoncé de pratiques de certification, abrégée par le sigle CPS (dérivé de son nom anglophone «Certification Practice Statement»), définit l ensemble des procédures opérationnelles employées par l AC, dans le cadre de la gestion du cycle de vie des certificats. Celui-ci décrit comment l AC réalise les opérations afin de répondre adéquatement aux objectifs énoncés dans la CP. Les procédures opérationnelles décrites dans la CPS d une AC devraient être suffisamment détaillées, de manière à permettre à un utilisateur de juger de l efficacité et de la rigueur avec laquelle les opérations sont réalisées. Cet élément peut influencer la décision concernant le fait d établir ou non un lien de certification croisée entre deux AC. Comme pour la CP, le RFC 3647, offre un support à la rédaction de la CPS. On y explique les différents concepts impliqués et on y propose une table des matières couvrant l ensemble des éléments. La CPS constitue aussi un intrant important du processus d accréditation Les composantes physiques Cette section décrit brièvement les composantes physiques nécessaires à la mise en œuvre d une ICP Équipement informatique Une ICP est constituée de plusieurs composantes logicielles qui peuvent résider sur un (1) ou plusieurs serveurs physiques. Ces serveurs doivent être reliés à un réseau informatique, afin de permettre aux utilisateurs ainsi qu aux applications d accéder aux différents services. La nature critique des données gérées par l ICP exige que ces serveurs résident dans un lieu physique sécurisé, dont l accès est contrôlé de manière stricte par différents mécanismes (registre d accès, caméras de surveillance, etc.) Module de sécurité La protection de la clé de signature de l autorité de certification constitue un des enjeux majeurs de l ICP. Afin d assurer un niveau de protection optimal de cette information, il est fortement recommandé de faire appel à un module de sécurité matériel de type HSM (Hardware Security Module) pour la génération et le stockage des clés. Ce module de sécurité doit répondre aux exigences de la norme FIPS du NIST (National Institute of Standards and Technology). Il s agit d une composante matérielle qui offre des fonctions cryptographiques et qui est munie de différents mécanismes de protection la rendant à tout fin pratique inviolable. Toute tentative d intrusion provoque l effacement immédiat des paramètres de sécurité critiques du module. HSM externe avec interface réseau HSM interne PC Card Type 2 Figure 18 - Exemples de modules de sécurité Page 49 sur 96

50 4 Les solutions d ICP 4.1 Les produits logiciels Depuis les années 90, l ICP est considérée comme étant la technologie ultime en matière de sécurité, mais son coût élevé ainsi que sa grande complexité ont eu pour effet de ralentir considérablement son adoption au sein des entreprises. Aujourd hui, malgré le fait que les technologies de base sur lesquels s appuie l ICP n aient guère changé depuis ce temps, l ICP tend à être déployée dans de plus en plus d entreprises. Ce phénomène s explique en partie par l espace grandissant qu occupe la sécurité au sein des technologies de l information, ainsi qu aux efforts qui ont depuis été consacrés à faciliter sa mise en œuvre. Plusieurs éditeurs offrent aujourd hui des produits d ICP très complet et relativement facile à déployer. Cette section a pour objectif d identifier un produit d ICP en logiciel libre qui sera susceptible de satisfaire les besoins de la Chaire et de l AI2L. Afin de s assurer de la pertinence de ce produit, celui-ci fut comparé à deux (2) produits propriétaires, offerts par des éditeurs commerciaux réputés dans ce domaine. Des travaux de recherche ont permis d identifier le produit d ICP en logiciel libre EJBCA comme étant un candidat intéressant pour la présente étude. Les raisons ayant motivé ce choix sont les suivantes : Entièrement écrit en Java; Respecte les normes et standards de l industrie; Offre une architecture très flexible; Offre un haut niveau de fonctionnalités; Les produits propriétaires avec lesquelles celui-ci a été comparé, ont quant à eux été sélectionnés en fonction de la réputation de leurs éditeurs. Il s agit donc de : RSA Digital Certificate Solution; Entrust Authority Security Manager. À noter que cette étude comparative est basée sur la documentation publiée sur les sites web des éditeurs, ainsi que sur une étude réalisée par le laboratoire indépendant «NSS Labs» en 2002 [NSS2002]. Notre étude fut réalisée dans le but d identifier les écarts fonctionnels entre le produit en logiciel libre EJBCA et les produits propriétaires qui constituent habituellement le «nec plus ultra» des ICP. Les sections à explorent deux produits d ICP propriétaires, ainsi qu un produit d ICP en logiciel libre dans le but d en comparer les principales caractéristiques. La section présente certaines observations faites sur ces solutions. Page 50 sur 96

51 4.1.1 RSA Digital Certificate Solution Le produit offert par RSA est composé de modules interopérables qui permettent d effectuer la gestion des certificats numériques. Celui-ci permet de créer un environnement où il est possible d authentifier et de protéger les communications ainsi que les transactions électroniques. Les principaux modules offerts par ce produit sont les suivants : RSA Certificate Manager. Ce module permet de gérer les certificats numériques. Celui-ci est conçu de manière à permettre aux entreprises de réaliser efficacement des transactions électroniques sécurisées. Il permet aux entreprises de mieux gérer le développement, ainsi que le déploiement de services de commerce électronique en offrant un service d automatisation, ainsi qu une gestion centralisée des clés cryptographiques et des certificats numériques. RSA Registration Manager. Ce module agit en collaboration avec le module RSA Certificate Manager. Celui-ci s acquitte du processus d inscription en gérant les grands volumes de demandes de certificats provenant des entités d extrémité. Il permet de s assurer de la légitimité des demandes en validant l identité des demandeurs ainsi que de l entité d extrémité. RSA Key Recovery Manager (optionnel). Ce module permet de conserver, de manière sécurisée, les clés privées des entités d extrémité en vue de rencontrer des exigences réglementaires, ou d être en mesure de récupérer des documents chiffrés suite à un crash ou à un litige. Le tableau suivant présente les caractéristiques techniques du module RSA Certificate Manager, soit la base du produit d ICP offert par RSA. Éditeur Produit Version actuelle 6.8 Référence Plateformes supportées Standards de certificats supportés RSA Security RSA Certificate Manager http :// Solaris 10 (Sparc ) Red Hat Linux Windows 2003 R2 SP2 X.509 v3 (incluant toutes les extensions standards) PKIX SSL S/MIME IPSec SET Extended Validation Page 51 sur 96

52 Certifications de l industrie Caractéristiques de l annuaire Caractéristiques de l ICP Caractéristiques de certificats Support cryptographique Chiffrement matériel Modèle tarifaire Common Criteria EAL4+ Federal Bridge CA (FBCA) IdenTrust Certification Comprends un dépôt de certificats de type LDAP intégré. Publication vers un annuaire de type LDAP v2/v3 ou X.500. Recherche de certificats S/MIME via LDAP/SSL-LDAP Vérification du statut des certificats via SSL-LDAP SSL-LDAP entre toutes les composantes ICP X.509 CRLs et CRLs avec extensions Nombre illimité de d AC subordonnées dans la chaîne de confiance (ICP hiérarchique) Certificats X.509 v1 et v3 Certificats RSA, DSA et ECDSA Longueur de clés allant jusqu à 4096-bit pour l authentification Configuration flexible des DN de certificats Certificats S/MIME Signature d objets (Java, ActiveX ) Extensions PKIX v3 Extensions SET Certificats Firefox et Microsoft Internet Explorer RSA DSA P-256, P-384, et P-521 ECDSA SHA-1 et SHA-2 Stockage des clés privées de l AC dans des équipements de type Hardware Security Module (HSM) et clonage/archivage des clés de l AC se trouvant dans le HSM à l aide d équipements PKCS #11. Sécurité des clés FIPS niveau 1 à 3 (via ncipher, SafeNet, Utimaco, Thales, AEP et/ou autre équipements PKCS#11) Le prix du module RSA Certificat Manager est fixé en fonction du nombre d utilisateurs du système. Voici, à titre d exemple, quelques chiffres tirés du site http :// Nombre d utilisateurs Prix par utilisateur Total pour le maximum d utilisateurs $ $ $ $ $ $ $ $ et $ + de $ Table 16 - Caractéristiques techniques - RSA Certificate Manager Page 52 sur 96

53 4.1.2 Entrust Authority Le produit de gestion de certificats numériques d Entrust fût introduit en Maintenant rendu à sa 7 ième édition, Entrust Authority est toujours un leader de sa catégorie. Entrust Authority prend en charge le cycle de vie complet des certificats numériques. Il rend possibles le chiffrement, la signature numérique et l authentification de manière transparente à travers un grand nombre d applications et de plateformes. Modulaire et complètement intégrée, l ICP d Entrust repose sur la composante Entrust Authority Security Manager, qui constitue l autorité de certification responsable de l émission des certificats numériques des entités d extrémité. Entrust Authority comporte aussi d autres composantes optionnelles qui permettent de satisfaire d autres besoins plus spécifiques en matière de sécurité d entreprise. Les composantes d Entrust Authority sont les suivantes : Entrust Authority Security Manager. Composante à la base de l ICP d Entrust. Celle-ci s acquitte de l émission et de la gestion des certificats numériques. Entrust Authority Administration Services. Service d administration Web qui permet une administration déléguée et distribuée de l ICP. Cette application offre une sécurité de bout en bout, et force la signature numérique de chacune des transactions administratives. Entrust Authority Auto-enrollment Server. Composante optionnelle qui, en combinaison avec Entrust Entelligence Security Provider pour Windows, offre la capacité d inscrire automatiquement les utilisateurs et postes de travail Windows à l ICP. Entrust Authority Roaming Server. Composante permettant aux utilisateurs d avoir accès à de l information sensible, à partir de n importe où dans le monde, sans avoir à fournir de certificat lors de l établissement d une connexion sécurisée. Entrust Authority Security Manager Proxy. Composante qui permet aux utilisateurs de communiquer avec l autorité de certification (AC) à travers l internet, sans avoir à apporter de modification aux règles des coupe-feu. Entrust Authority Enrollment Server for Web. Composante qui, en collaboration avec la composante Entrust Authority Security Manager, permet d émettre des certificats à clé publique aux applications ainsi qu aux équipements. Entrust Authority Enrollment Server for VPN. Il s agit d un serveur qui, en collaboration avec la composante Entrust Authority Security Manager, émet des certificats numériques aux passerelles VPN, clients à accès distant, ainsi qu aux routeurs. Page 53 sur 96

54 Le tableau suivant présente les caractéristiques techniques du produit Entrust Authority Security Manager. Éditeur Produit Version actuelle 7.0 Référence Plateformes supportées Standards de certificats supportés Certifications de l industrie Caractéristiques de l annuaire Caractéristiques de l ICP Caractéristiques de certificats Support Entrust Entrust Authority Security Manager http :// Microsoft Windows Server 2003 Standard Microsoft : Windows Server 2003 Enterprise Microsoft Windows 2000 Server Microsoft Windows 2000 Advanced Server Sun Solaris 9 and 8 HP -UX 11i IBM AIX 5.1 Émission de certificats pour utilisateurs, équipements et applications supportant le standard de certificat X.509. Supporte les standards de certificats tels que : CRL PKIX-CMP PKCS#7/10 SCEP Permet l interopérabilité avec les applications intégrant les concepts d ICP tels que les VPN, les navigateurs Web, le courrier électronique et les applications de commerce électronique. Common Criteria EAL4+ Interopérable avec annuaires LDAP (incluant Microsoft Active Directory) Liste de révocation (CRL) X.509 et CRL avec extensions Nombre illimité d AC subordonnée dans la chaîne de confiance (ICP hiérarchique) Support pour certification d égal à égal (peer-to-peer) et certification croisée hiérarchique d AC (hierarchical crosscertification of CAs) Certificats X.509 v1 et v3 Certificats RSA, DSA et ECDSA Longueur de clés allant jusqu à 4096-bit pour authentification Configuration flexible des DN de certificats Certificats S/MIME Signature d objets (Java, ActiveX ) Extensions PKIX v3 Extensions SET Certificats Firefox et Microsoft Internet Explorer RSA (jusqu à 6144-bits) Page 54 sur 96

55 cryptographique DSA 1024 Elliptic Curve DSA signing AES-256, DES, Triple-DES, CAST, IDEA SHA-1, SHA-256 Chiffrement matériel Modèle tarifaire Projet en génie logiciel Stockage des clés privées de l AC dans des équipements de type Hardware Security Module (HSM) et clonage/archivage des clés de l AC se trouvant dans le HSM à l aide d équipements PKCS #11. Sécurité des clés FIPS niveau 1 à 3 (via ncipher, SafeNet) Le prix de l ICP Authority Security Manager d Entrust est fixé en fonction du nombre d utilisateurs du système. Voici, à titre d exemple, quelques chiffres tirés d une étude menés par le groupe NSS en 2002 : Nombre d utilisateurs Total $ $ $ $ $ Table 17 - Caractéristiques techniques - Entrust Authority Security Manager Page 55 sur 96

56 4.1.3 EJBCA Entièrement écrit en Java/J2EE, EJBCA est un produit d ICP en logiciel libre sous licence LGPL. Enregistré auprès de SourceForge.net en 2001, le projet EJBCA est principalement financé par la firme Suédoise PrimeKey Solutions, un éditeur de logiciels libres spécialisé en ICP. Cet éditeur propose donc le produit EJBCA qu elle décrit comme étant le chef de file en matière d ICP en logiciel libre. PrimeKey soutient que le produit EJBCA est installé et utilisé dans de grandes entreprises comptant plusieurs milliers d employés, ainsi que dans des entreprises faisant l émission de plusieurs millions de certificats [PRIMEKEY]. De plus, toujours selon PrimeKey, il semblerait que certaines installations d EJBCA aient été certifiées, confirmant ainsi d une certaine façon, la conformité du produit à de hauts standards tels qu ETSI ou WebTrust. L objectif du projet EJBCA est d offrir un produit d ICP hautement paramétrable, offrant les composantes de bases d une ICP. Cette ICP permet la gestion des certificats à clé publique, tout en assurant une délégation complète des droits d administration. Il s agit d un produit pouvant offrir un haut niveau de performance, de disponibilité et d extensibilité [PRIMEKEY]. Le produit EJBCA à l avantage d être totalement indépendant des systèmes d exploitation, des SGBD et des serveurs d applications. Son architecture Web 3 tiers est très bien adaptée aux infrastructures actuelles des entreprises. En plus de l interface Web standard, EJBCA offre aussi une interface SOAP, ainsi qu une interface par ligne de commande qui facilite l intégration et l automatisation de certaines opérations. Le diagramme suivant illustre l architecture applicative à 3 tiers d EJBCA. Figure 19 - Diagramme d'architecture applicative d'ejbca tiré de [EJBCAFU] En plus des fonctions de base offertes par la plupart des produits d ICP propriétaires, EJBCA offre un serveur OCSP, un serveur d horodatage, ainsi qu un serveur de signature. [EJBCAFU] Page 56 sur 96

57 Voici la liste des composantes offertes par EJBCA qui permettent de réaliser l ensemble des opérations du cycle de vie des certificats : Autorité de certification (AC). Composante à la base de l ICP EJBCA. Celle-ci s acquitte de l émission et de la gestion des certificats numériques. Autorité d enregistrement (AE). Composante qui s acquitte du processus d inscription des entités d extrémité. Celle-ci est responsable des fonctions qui lui sont déléguées par l AC en vertu de la politique de certification. Autorité d enregistrement locale (AEL). Composante qui permet aux personnes, aux machines ou aux agents logiciels d effectuer des demandes de certificats. Dépôts. Composantes qui stockent les éléments publics de l ICP tels que les certificats et les listes de certificats qui ont été révoqués (CRL), de manière à les rendre disponibles aux utilisateurs. Toutes les fonctions offertes par EJBCA peuvent être administrées à l aide d une interface Web, dont l accès peut être contrôlé à l aide d un mécanisme d authentification forte par certificat. EJBCA a été construit de manière à répondre rapidement et sans développement complémentaire, aux contraintes liées aux certificats de l entreprise. Il permet donc de créer des profils de certificat, des formulaires de requête, des cinématiques fonctionnelles, ainsi que de personnaliser des cartes à puce ou des «dongles» USB [EJBCAFU]. Le diagramme suivant illustre les quatre (4) niveaux fonctionnels d EJBCA. Figure 20 - Diagramme d'architecture fonctionnelle d'ejbca. Source [EJBCAFU] Page 57 sur 96

58 Le tableau suivant présente les caractéristiques techniques du produit EJBCA. Éditeur Solution PrimeKey Solutions EJBCA Version actuelle Référence Plateformes supportées Standards de certificats supportés Certifications de l industrie Caractéristiques de l annuaire Caractéristiques de l ICP Caractéristiques de certificats http :// Plateformes Java J2EE 1.3 (EJB 2.0). Serveurs d applications : Jboss; Weblogic; Glassfish; OC4J; Websphere. Émission de certificats pour utilisateurs, équipements et applications supportant le standard de certificat X.509 et Card Verifiable Certificates (CVC) utilisés par EU EAC epassports. Supporte les standards tels que : CRL (Certificate Revocation Lists); PKIX-CMP; PKCS#7/10; SCEP (Simple Certificate Enrollment Protocol). Ceci permet l interopérabilité avec les applications intégrant les concepts d ICP tels que les VPN, les navigateurs Web, le courrier électronique et les applications de commerce électronique. Exportation des certificats client et serveur en format PKCS12, JKS ou PEM. Aucune. Mécanisme de publication flexible permettant le stockage des certificats et listes de révocation (CRL) dans une base de données SQL, un annuaire LDAP et/ou d autres sources de données personnalisées. Support pour annuaires LDAP v3 (et Microsoft Active Directory). Suit les standards X509 et PKIX (RFC 3280) lorsqu applicables. Supporte un sous-ensemble du standard Certificate Management Protocol (CMP) (RFC 4210 et RFC 4211). Supporte les requêtes XKMS version 2 synchrone. Supporte le protocole OCSP (Online Certificate Status Protocol RFC 2560), incluant l extension Authority Info Access (AIA). Supporte les Certificate Revocation Lists (CRLs). Supporte multiples AC et multiples niveaux d AC. Supporte l auto-inscription des clients Windows. Certificats X.509 v3 Longueur de clés allant jusqu à 4096-bit pour authentification. Configuration flexible des DN de certificats. Page 58 sur 96

59 Support cryptographique Chiffrement matériel Modèle tarifaire Certificats S/MIME. Signature d objets (Java, ActiveX ). Extensions PKIX v3 Certificats Netscape, Mozilla, Microsoft Internet Explorer, etc. Certificats pour authentification par carte à puce. RSA (jusqu à 4096-bits) Elliptic Curve DSA signing MD5, SHA-1, SHA-256 API modulaire pour équipements de type Hardware Security Module (HSM). Support Built in pour ncipher, PrimeCardHSM, Eracom (maintenant SafeNet), SafeNet Luna, Utimaco CryptoServer, AEP Keyper, ARX CoSign et autres équipements HSM offrant une librairie PKCS#11. Gratuit. Offert en logiciel libre sous licence LGPL, donc libre de toute redevance pour utilisation, amélioration ou redistribution Les observations Table 18 - Caractéristiques techniques - EJBCA Après avoir effectué un survol rapide de ces trois (3) produits d ICP, nous pouvons constater que ceux-ci : Comportent des caractéristiques techniques similaires; Offrent l ensemble des services de base que doit offrir une ICP; Respecte les standards de l industrie (ex. : X.509 v3, CRL, PKIX, SCEP, etc.); Supporte un nombre illimité d autorités de certification subordonnées; Supportent les principaux algorithmes cryptographiques (Ex. RSA, DSA, SHA-1, SHA-2, etc.); Supportent des longueurs de clés RSA de plus de 2048 bits; Supportent les annuaires de type LDAP v3; Permettent l utilisation d un module cryptographique (HSM); D un point de vue technique, il est clair que ces trois (3) produits sont aptes à remplir leur mission, et à répondre à la majorité des besoins auxquels doit répondre une ICP. Cette comparaison a cependant permis de faire ressortir l existence de deux (2) différences importante entre les produits propriétaires et EJBCA, soit : 1. Le produit EJBCA n a fait l objet à ce jour d aucune certification en termes de sécurité. Les produits propriétaires ont tous deux fait l objet d une certification selon la norme Common Criteria (ISO/IEC 15408); 2. Le produit EJBCA étant offert sous licence LGPL, celui-ci offre donc toutes les libertés fondamentales associées au logiciel libre. Son utilisateur est donc libre de l exécuter, de l adapter, de l améliorer et de le redistribuer sans aucune redevance. Il s agit d un avantage marqué de cette solution sur les solutions propriétaires. Page 59 sur 96

60 Le produit EJBCA semble donc représenter un candidat de choix pour la Chaire et l AI2L. Sa grande flexibilité permettrait la mise en œuvre d une ICP bien adaptée aux besoins des entreprises de l économie sociale et solidaire. De plus, son ouverture permettrait à la Chaire d y apporter des ajouts ainsi que des améliorations au besoin. 4.2 Les services hébergés L exploitation d une ICP au sein d une entreprise demeure une activité complexe qui demande une grande rigueur. Outre les frais de licences associés à l utilisation des produits d ICP, cette solution implique des efforts et des coûts d implantation et d exploitation qui sont souvent mal évalués. Il faut cependant savoir qu il existe d autres options à ce niveau. Depuis quelques années, certains éditeurs de produits d ICP, ainsi certaines autorités de certification commerciales l ont compris, car ils font davantage la promotion de leurs services clé en main, où les composantes d ICP résident chez eux plutôt que dans l entreprise. Figure 21 - Coûts de l'exploitation d'une ICP à l'interne. Source [ENTTCO] Les sections et explorent les solutions d ICP offertes par certains éditeurs de produits d ICP dans le but de comprendre leur fonctionnement. Nous devons tenir compte de ce mode d exploitation, car celui-ci pourrait représenter une alternative intéressante pour les EESS (Entreprises de l Économie Sociale et Solidaire). La section présente certaines observations faites sur ce type de solutions. Page 60 sur 96

61 4.2.1 Entrust - Managed Services PKI La solution Managed Services PKI offerte par Entrust permet aux entreprises de bénéficier du contrôle offert par l exploitation d une ICP interne, sans avoir à faire l acquisition, le déploiement ainsi que l exploitation d un produit d ICP. Selon Entrust, cette solution offre les principaux avantages suivants : Mise en place rapide. Aucun déploiement requis; Faible investissement initial. Il n est pas nécessaire de mettre en place des installations sécurisées et autres mécanismes de protection; Facturation à la demande. Les entreprises paient que pour ce dont elles ont besoin. Fiabilité. Cette solution permet de bénéficier d une infrastructure complètement redondante, offrant surveillance, sauvegarde robuste ainsi qu un plan de recouvrement en cas de désastre exceptionnel. La figure suivante offre une vue de haut niveau de l architecture de la solution, où on peut voir que l ICP réside entièrement dans les installations sécurisées d Entrust. L entreprise accède aux différents services de l ICP via l Internet. Figure 22 - Architecture Entrust Managed Services PKI. Source [ENTMNG] La solution d Entrust est offerte en différents modèles de services permettant ainsi d offrir un haut niveau de flexibilité. Les modèles offerts sont les suivants : Service partagé. Solutions à faibles coûts où une même autorité de certification est partagée par plusieurs entreprises. Cette AC offre un ensemble de politiques préétablies. Page 61 sur 96

62 Service dédié. Les certificats sont émis par un CA dédié à l entreprise. Cette solution permet donc de personnaliser les certificats ainsi que les politiques (CP et CPS). Service d autorité racine. Solution qui permet à une entreprise de posséder sa propre AC racine, à laquelle il est possible de rattacher des CA subordonnés situés à l extérieur de chez Entrust. La solution «Managed Service PKI» offre donc un niveau de fonctionnalités et de contrôle similaire à une implantation maison, sans avoir à se préoccuper des infrastructures de sécurité, ainsi que des procédures rigoureuses exigées par l ICP. Une entreprise doit payer pour chacun des certificats gérés par cette solution OpenTrust - Software as a Service (SaaS) Fondée en 2001, l entreprise européenne OpenTrust se spécialise dans les logiciels de sécurité informatique basés sur la confiance. Dans la gamme de produits offerts par cette entreprise, on retrouve OpenTrust PKI, un produit d ICP comparable aux trois (3) produits précédemment observés au chapitre 4. Figure 23 - Architecture du produit OpenTrust PKI. Source [OPENTR] Page 62 sur 96

63 L offre OpenTrust PKI est disponible en trois différentes formes, soit : Projet en génie logiciel Produit logiciel. Le produit est entièrement déployé dans les infrastructures de l entreprise; Solution hébergée. Le produit est entièrement déployé dans les infrastructures d OpenTrust, de manière à offrir à l entreprise une ICP dédiée. Software as a Service (SaaS). Le produit est entièrement déployé dans les infrastructures d OpenTrust, de manière à offrir à l entreprise une ICP qui est partagée avec d autres entreprises. Contrairement à Entrust, le site OpenTrust n offre malheureusement que très peu de détails quant à ses offres de services hébergés et SaaS. Il aurait été intéressant d en connaître un peu plus sur la flexibilité offerte par la solution hébergée, ainsi que sur la gestion de la sécurité dans l environnement partagée SaaS Les observations En ayant pris connaissance des offres de ces deux (2) entreprises en matière de solutions d ICP sous forme d un service hébergé, nous pouvons réaliser les deux constats suivants : C est possible de le faire. À premier abord, en ayant connaissance de l aspect critique de l ICP en termes de sécurité, il ne semblait pas évident qu une telle solution puisse être exploitée dans un nuage (cloud). Nous venons de constater qu il est possible de le faire dans un environnement contrôlé, répondant à certaines exigences de sécurité. Cette option comporte des avantages intéressants. L implantation ainsi que l exploitation d une ICP au sein d une entreprise implique des coûts initiaux substantiels, une expertise spécialisée, ainsi que la mise en place d installations sécurisées. Or, l hébergement permet de centraliser les installations, de manière à libérer les utilisateurs de cette lourdeur inhérente à l ICP. Il va de soit que la gestion des certificats à clé publique n est pas le «core business» des EESS (Entreprises de l Économie Sociale et Solidaire). Par contre, ces entreprises ne peuvent négliger l aspect de confiance offert par les certificats, c est pourquoi cellesci n ont d autres choix que de faire selon les règles de l art. C est dans cette situation bien précise que la solution de l hébergement prend tout son sens. Elle permet de bénéficier d une infrastructure de confiance fiable avec un minimum d efforts et d investissements. La mise en place d une ICP centralisée, dans laquelle une AC est partagée par plusieurs entreprises, devrait permettre de réaliser une économie d échelle considérable, tout en simplifiant la tâche des administrateurs TI des entreprises. Page 63 sur 96

64 5 Recommandations Cette section présente un ensemble de recommandations sur la gestion ainsi que l utilisation des clés publiques au sein des EESS (Entreprises de l Économie Sociale et Solidaire). La Chaire de logiciel libre Finance sociale et solidaire pourra donc s appuyer sur ces recommandations afin de : 1. Soutenir les EESS dans la mise en place de l infrastructure nécessaire à la gestion des clés publiques; 2. Faire bon usage de la cryptographie à clé publique dans les logiciels qu elle va développer; Ces recommandations ont été élaborées de manière à répondre à la problématique initiale, tout en respectant les objectifs que se sont fixées la Chaire et l AI2L. Voici donc les prémisses sur lesquelles ont été basées les recommandations : Faire appel à un produit d ICP en logiciel libre qui peut être exploité dans un environnement partagé. «choix d une solution libre pour la gestion de l authentification et de l autorisation possiblement dans un cadre fédéré (une seule infrastructure partagée par plusieurs opérateurs);» [CHAIRE] Identifier le contexte d exploitation optimal. «étude des différents contextes d exploitation des logiciels produits et recommandations pour une utilisation optimale.» [CHAIRE] Guider la mise en œuvre et l exploitation de l ICP. «de favoriser le développement d une famille de logiciels libres compatibles entre eux et adaptés à la distribution de produits ou la prestation de services financiers, pour des institutions financières et des entreprises d économie sociale et solidaire, ou socialement responsables, de même que leur mise à disposition et leur accessibilité;» [AI2L] Limiter la dépendance technologique et commerciale envers les autorités de certification externes. «de contribuer, par la création de logiciels libres, à l objectif d une indépendance des entreprises d économie sociale et solidaire vis-à-vis des producteurs capitalistes du code informatique, pour la gestion de leurs systèmes d information et dans leurs échanges électroniques;» [AI2L] La section 5.1 présente une recommandation concernant la mise en œuvre d une infrastructure qui permettra aux EESS d effectuer elles-mêmes la gestion de leurs clés publiques. Les sections 5.2 à 5.5 présentent des recommandations concernant la gestion des clés publiques dans cette infrastructure. Page 64 sur 96

65 5.1 «PKI as a Service» Les travaux réalisés dans le cadre de ce projet de recherche ont permis d explorer différentes options en termes de gestion des clés publiques. Nous avons constaté que les solutions d ICP propriétaires, qu elles soient exploitées à l interne ou à l externe, créent un lien de dépendance envers le fournisseur. D autre part, bien que le produit d ICP en logiciel libre EJBCA offre toute la liberté souhaitée, sa mise en œuvre et son exploitation à l interne au sein de chacune des organisations, est loin de représenter une solution optimale. En disposant des informations récoltées tout au long de cette étude, voyons maintenant comment il est possible d élaborer une solution répondant aux objectifs de la Chaire et de l AI2l cités précédemment : Faire appel à un produit d ICP en logiciel libre qui peut être exploité dans un environnement partagé. Le produit d ICP en logiciel EJBCA exploré à la section permet de déployer une ICP complète d une grande flexibilité, offrant l ensemble des services normalement offerts par les ICP propriétaires. De plus, son architecture 3 tiers se prête parfaitement au modèle d exploitation centralisé; Identifier le contexte d exploitation optimal. L exploitation d une ICP requiert une expertise particulière ainsi que la mise en place d un certain nombre de contrôles et de procédures afin d assurer son intégrité. Un déploiement centralisé permettra de concentrer l expertise à un seul endroit et ainsi réduire les coûts d exploitation. De plus, le survol des solutions d ICP hébergé présenté à la section 4.2, a permis de constater que l exploitation d une ICP à l extérieur de l entreprise simplifie grandement les opérations des entreprises qui font appel à ces services. Guider la mise en œuvre et l exploitation de l ICP. En tenant compte des présentes recommandations, la Chaire sera apte à réaliser ou, à tout le moins, à supporter la réalisation de la mise en œuvre de l ICP. Limiter la dépendance technologique et commerciale envers les autorités de certification externes. L exploitation d une ICP partagée permettra aux EESS de gérer elles-mêmes la majorité des certificats dont elles auront besoin. Ces certificats pourront être utilisés par tous les logiciels et mécanismes de sécurité qui seront offerts aux EESS par la Chaire. En répondant à ces objectifs, nous réalisons que la solution se dessine d elle-même. En effet, tout semble indiquer que l exploitation d une ICP centralisée entièrement constituée de composantes en logiciel libre constituerait la solution idéale pour le contexte de la Chaire et de l AI2L, mais surtout des EESS. Comme une solution n est jamais parfaite, il faut souligner l exploitation d une ICP interne comporte certaines limitations. En effet, les certificats émis par cette ICP ne pourront être utilisés pour sécuriser les sites Web ouverts au grand public, à moins que l ICP ne se soumettre à une certification annuelle exigée par les éditeurs de fureteurs. Par conséquent, l exploitation d une ICP interne ne pourra, dans un premier temps, briser totalement la relation de dépendance de chacune des EESS envers une AC reconnue. Page 65 sur 96

66 La mise en œuvre d une ICP centralisée constitue l occasion parfaite pour tirer profit de la «virutalisation» des serveurs. Une étude préliminaire réalisée par la Chaire en 2009 a conclu que l utilisation du «cloud computing» au sein d une communauté telle que les EESS, représentait une option intéressante [COPPO09]. L ICP pourrait donc être la première composante à être offerte sous la forme d un SaaS (Software as a Service), hébergée dans un «cloud» communautaire déployé par la Chaire. La figure suivante offre une vue globale de la solution proposée. Figure 24 - Vue globale de la solution proposée La section présente la liste des logiciels libres qui permettront la mise en œuvre d une ICP dans le «cloud» communautaire des EESS. La section décrit brièvement la manière dont ces composantes devront être agencées afin de former une ICP répondant aux besoins des EESS. Page 66 sur 96

67 5.1.1 Logiciels libres requis La communauté du logiciel libre offre actuellement toutes les composantes logicielles requises afin de mettre en œuvre une ICP complète dans le «cloud» communautaire des EESS. Cette section présente brièvement les principales composantes qui constituent la solution. Composante Système d exploitation ICP (AC, EA, OCSP) Serveur d applications J2EE Java Runtime Environment Base de données Annuaire LDAP Serveur de signature (Horodatage et Notarisation) Serveur Web Pare-feu applicatif Produit Linux (distribution au choix) EJBCA Jboss Sun Java SE Development kit PostgreSQL ApacheDS SignServer Apache HTTP Server ModSecurity Table 19 - Liste des composantes logicielles requises Linux (distribution au choix) La plateforme Linux s impose d elle-même. Ce système d exploitation de style Unix, offert en logiciel libre, constitue la plateforme idéale pour le déploiement d une ICP. La plateforme Linux offre à la fois performance, robustesse et fiabilité. De plus, toutes les composantes logicielles requises pour mettre en œuvre la solution proposée sont compatibles avec ce système d exploitation. Une distribution telle que SELinux, recommandée dans le cadre de travaux réalisés par la Chaire [HETUM09], convient parfaitement à ce type d utilisation EJBCA Ce produit d ICP est décrit en détail dans la section Des travaux réalisés dans le chantier sécurité de la Chaire font aussi référence au produit EJBCA pour la gestion des certificats à clé publique [HETUM09]. Page 67 sur 96

68 JBoss JBoss est un serveur d application J2EE en logiciel libre reconnu et largement utilisé par la communauté de développeurs d application Web d entreprise. Pour s exécuter, les composantes logicielles d ICP EJBCA doivent être déployées dans un serveur J2EE. JBoss est un des nombreux serveurs d applications supportés par le produit EJBCA Java SE Development Kit Le SDK (Software Development Kit) permet de développer et d exécuter des applications écrites en langage Java. Les composantes d ICP EJBCA, de même que le serveur d application JBoss ont besoin de l interpréteur Java pour s exécuter PostgreSQL PostgreSQL est un puissant système de gestion de base de données (SGBD) objetrelationnelle en logiciel libre qui a fait ses preuves depuis plus de 15 ans. Il s agit d un SGBD de grade commercial offrant toute la puissance, la robustesse, ainsi que la fiabilité attendue d un tel système. PostgreSQL est compatible avec les composantes d ICP d EJBCA ainsi que le système d exploitation Linux ApacheDS ApacheDS est un serveur d annuaire entièrement écrit en Java qui supporte le standard LDAPv3. Ce service d annuaire a d ailleurs été retenu par la Chaire lors de travaux réalisés dans son chantier architectural [CHAIRE]. ApacheDS sera utilisé pour la publication des certificats ainsi que des listes de révocations de l ICP SignServer Membre de la famille d EJBCA, SignServer est un «framework» applicatif auquel les applications peuvent déléguer l exécution de certaines opérations cryptographiques. SignServer offre des services tels que : Service d horodatage conforme au [RFC3161]; Service de signature de documents (PDF, XML, ODF, etc.); Service de validation de documents XML; Service de validation de certificats à l aide de CRL ou d OCSP; Dans l ICP des EESS, cette composante sera principalement utilisée pour son service d horodatage ainsi que pour réaliser la signature dans le cadre des opérations de notarisation. Des travaux réalisés dans le chantier sécurité de la Chaire font aussi référence au produit SignServer pour la notarisation [HETUM09] Apache http Server Tout comme le système d exploitation Linux, le serveur Web Apache s impose de luimême. Il s agit certainement du serveur Web le plus populaire. Ce serveur Web sera utilisé en mode mandataire inverse (reverse-proxy). Installé dans la zone démilitarisée (DMZ) du réseau, le serveur Web avec module mod_proxy, permettra de rehausser la sécurité des applications Web de l ICP, tout en cachant leur répartition sur le réseau interne. Page 68 sur 96

69 ModSecurity Projet en génie logiciel ModSecurity est un pare-feu applicatif qui protège les applications Web de différentes attaques. Ce module offre des fonctions de surveillance, de journalisation, et d analyse en temps réel du trafic HTTP. Ce module peut être installé en mode autonome, ou intégré au serveur Web Apache. Le mode intégré est recommandé, car ainsi il se greffe à une composante essentielle de l architecture Web, soit le serveur mandataire inverse (reverse-proxy). Des travaux réalisés dans le chantier sécurité de la Chaire font aussi référence au produit ModSecurity à titre de pare-feu applicatif [HETUM09] Organisation des composantes Cette section décrit brièvement la manière dont devraient être organisées les différentes composantes de l ICP dans le «cloud» communautaire des EESS. L objectif n est pas de définir la solution complète, mais plutôt de proposer un modèle de base sur lequel la Chaire pourra s appuyer pour élaborer la solution finale. La section décrit la configuration des composantes logicielles des serveurs de l ICP et la section propose un modèle pour la répartition de ces serveurs sur le réseau Configuration logicielle des serveurs Le diagramme suivant illustre la configuration logicielle de chacun des types de serveurs qui composeront l ICP. Figure 25 - Configurations logicielles des serveurs de l ICP Au moment de planifier l implantation, il faudra utiliser les dernières versions stables de chacun des logiciels, en s assurant de respecter les contraintes de compatibilité qui pourraient exister. Page 69 sur 96

70 Répartition des serveurs sur le réseau Projet en génie logiciel Afin de bien séparer les fonctions et d établir les points de contrôle de sécurité requis [HETUM09], il est fortement recommandé de créer des zones réseau dans lesquels seront répartis les serveurs sur lesquels s exécuteront les composantes logicielles de sécurité. La figure suivante illustre le modèle de zone réseau proposé. Figure 26 - Modèle de zone réseau proposé Le modèle proposé est constitué de trois (3) zones distinctes soit : DMZ (Zone démilitarisée). Zone tampon entre le réseau interne et l internet. C est dans cette zone que seront déployés les serveurs mandataires inverses avec pare-feu applicatif, ainsi que les services d annuaire LDAP qui serviront uniquement à la publication des listes de révocation (CRL) et des certificats à clé publique; Zone de production. Zone réseau dans laquelle seront déployées les applications qui seront développées par la Chaire, ainsi que les composantes d ICP du produit EJBCA, autres que les AC. Zone de sécurité. Zone réseau hautement sécurisée où résideront les serveurs de base de données des composantes de l AC, les serveurs de journaux, ainsi que les AC émettrices. La présence de pare-feu entre les zones permet de contrôler le trafic réseau qui circule entre celles-ci. À noter que pour des raisons de sécurité, l AC racine ne devra pas être connectée au réseau. Il pourrait en fait simplement s agir d un ordinateur portable doté d un lecteur de carte à puce, entreposé dans une chambre forte lorsqu il n est pas utilisé. Page 70 sur 96

71 Il sera préférable de placer les AC émettrices dans la zone sécurité pour les raisons suivantes : Les AC sont des composantes critiques qui ne devraient pas être accessibles de l internet; Seuls les administrateurs de l ICP ayant un niveau de privilège élevé devraient avoir accès aux AC. L enregistrement des abonnées sera réalisé exclusivement à travers les AE. Afin de restreindre le trafic qui entre dans la zone de sécurité où résidera l AC, les AC émettrices iront elles-mêmes, de façon périodique, lire les requêtes de signature dans la zone de production où résideront les AE. Figure 27 - Mécanisme d AE externe d EJBCA. Source [EJBCA] Ce mécanisme est rendu possible grâce au «External RA API» offert par le produit EJBCA. La Chaire devra cependant développer sa propre interface AE, qui consiste en une petite application Web qui fera appel à cette API. Page 71 sur 96

72 5.2 Modèle de confiance La mise en place d une autorité de certification unique pour toute une communauté permet d adopter un modèle de confiance simple, soit le modèle hiérarchique. En partageant une même racine : Les EESS n auront pas à établir de certifications croisées entre elles; Les échanges avec les entreprises externes pourront être facilités en établissant des liens de certification croisés avec l autorité racine (modèle hybride); Ce modèle n empêche cependant pas une entreprise de créer et de gérer sa propre autorité de certification à l interne afin de répondre à des besoins particuliers. Le modèle de confiance hiérarchique de l ICP communautaire comportera deux niveaux d AC, soit : Le niveau racine; niveau le plus élevé de hiérarchie d AC de l ICP. Cette autorité de certification devra signer elle-même son certificat à clé publique, car il n existe aucune autre AC au dessus d elle; Le niveau émetteur; niveau situé sous le niveau racine. Ce niveau contiendra les AC qui réaliseront l émission des certificats des entités d extrémité ainsi que des AC subordonnées; La figure suivante illustre les deux (2) niveaux d AC de l ICP dont le 2ième niveau comporte une AC responsable d émettre des certificats pour les entités d extrémité tels que les personnes, les équipements réseaux, les serveurs Web internes, etc., ainsi qu une AC responsable d émettre des certificats pour des AC subordonnées. 5.3 Politiques de certification Figure 28 - Les deux niveaux d'ac Le comité de gestion de l ICP devra développer l ensemble des politiques de certification de l ICP, ainsi que son énoncé de pratiques de certification, conformément aux recommandations émises par le groupe PKIX [RFC3647]. Ces politiques devront être rédigées de manière à satisfaire les besoins de l ensemble des EESS. Page 72 sur 96

73 5.4 Gestion des clés cryptographiques Algorithmes asymétriques et longueurs de clés L ICP devra faire appel à des algorithmes cryptographiques reconnus, et utiliser des clés de longueurs suffisamment grandes, afin d assurer un niveau de robustesse adéquat des mécanismes de sécurité. Il est donc suggéré de suivre les recommandations émises par le NIST à cet effet. La publication spéciale SP [SP800573] définit les algorithmes ainsi que la taille des clés à utiliser par les utilisateurs ainsi que les composantes d une ICP. Table 20 - Longueurs de clés recommandées par le NIST. Source [SP800573] À l heure actuelle, la combinaison des algorithmes RSA et Diffie-Helleman avec des clés ayant une longueur de 2048 bits constitue un choix judicieux qui répondra à la majorité de besoins Algorithmes symétriques Lorsque l utilisation de la cryptographie symétrique s impose, l utilisation de l algorithme de chiffrement par bloc AES-128 (Advanced Encryption Standard) est recommandée [SP800573]. Page 73 sur 96

74 5.4.3 Fonctions de hachage Il existe plusieurs fonctions de hachage. Le standard FIPS [FIPS180] décrit deux familles d algorithme de hachage, soit : SHA-1; SHA-2 (SHA-224, SHA-256, SHA-384, SHA-512); De ces algorithmes, SHA-1 est encore aujourd hui celui qui est le plus utilisé par les systèmes de sécurité [WIKISHA], par contre il s agit aussi du plus faible. Bien qu une faille de sécurité ait été identifiée en 2005, cet algorithme fait toujours partie de la liste des algorithmes recommandés par le NIST [SP800107]. Malgré le fait que le NIST recommande aux agences américaines de ne plus utiliser SHA-1 pour la signature numérique dans les applications développées après 2010 [SP800107], son utilisation demeure acceptable en entreprise, car SHA-1 offre encore un niveau de robustesse adéquat pour celles-ci, et qu il existe encore beaucoup de systèmes qui ne supportent pas la famille SHA-2. Même si EJBCA supporte la famille d algorithme de hachage SHA-2, il est tout de même recommandé d utiliser l algorithme SHA-1 pour des raisons d interopérabilité avec les systèmes de sécurité Génération des clés Bien que l AC soit apte à générer les paires de clés des entités d extrémité ainsi que des AC intermédiaires, il faut privilégier une approche où le matériel cryptographique est généré par son propriétaire. Par exemple, au moment de configurer un serveur Web sécurisé, l administrateur du serveur procède à la génération de la paire de clés, ainsi que du CSR (Certificate signing request) qu il acheminera par la suite à l AC afin qu'elle puisse procéder à la signature. Après avoir réalisé la signature, l AC retourne le certificat à clé publique à l administrateur du serveur Web qui procède à son installation. Figure 29 - Génération des clés. Source Cisco Cette approche est jugée plus sécuritaire, en raison du fait que la clé privée n a jamais eu à quitter l endroit où celle-ci a été générée. Cette même technique s applique aussi au matériel réseau ainsi qu aux utilisateurs faisant appel à la cryptographie à clé publique. Page 74 sur 96

75 5.4.5 Stockage des clés La protection de la clé privée représente un enjeu critique de la cryptographie à clé publique. Le niveau de protection requis est proportionnel à l impact que pourrait avoir la compromission de cette clé. Par exemple, la compromission de la clé privée utilisée pour sécuriser des échanges courriel aura beaucoup moins d impact que la compromission de la clé privée d une AC. Nous avons vu à la section que la norme FIPS du NIST permet de qualifier les modules cryptographiques utilisés pour le stockage des clés. Le tableau suivant décrit le niveau de sécurité minimal requis pour le stockage des clés privées de chacun des profils d entités de l ICP [SP800573] : Propriétaire de la clé privé AC 3 OCSP 3 AE 2 Entité d extrémité 1 Niveau de sécurité FIPS requis Table 21 - Exigences pour le module de sécurité. Source [SP800573] La section présentait deux (2) types de modules de sécurité qui pourraient satisfaire les besoins des composantes de l ICP. Cependant, afin de tirer pleinement avantage des différents mécanismes de sécurité offerts par les applications qui seront mis en place par la Chaire, les EESS devraient considérer l utilisation de la carte à puce pour le stockage des clés privées des administrateurs et utilisateurs bénéficiant de privilèges élevés. Figure 30 - Carte à puce pour stocker la clé privée. Source Alladin.com Les cartes à puce offrent un niveau de sécurité physique très élevé. Plusieurs modèles supportent l interface standard PKCS#11, garantissant ainsi la compatibilité avec les applications. La carte à puce offre un moyen efficace de protéger les clés privées et permet de réaliser une authentification forte à deux facteurs, en utilisant les certificats générés par l ICP. Page 75 sur 96

76 5.4.6 Utilisation des clés Une clé cryptographique ne devrait être utilisée que pour une seule fin (par exemple pour le chiffrement, l authentification, l emballage de clé, la génération de nombres aléatoires, ou la signature numérique) [SP800571]. Par conséquent, il est préférable de définir plusieurs profils de certificats correspondants aux différentes utilisations. Le tableau suivant décrit les profils de certificats qui devraient permettre de combler l ensemble des besoins des EESS : Profil de certificat Extension Valeurs AC OCSP Signature de code SSL Serveur Entité d extrémité Key Usage Extended Key Usage - Key Usage Extended Key Usage Key Usage Extended Key Usage Key Usage Extended Key Usage Key Usage Extended Key Usage Certificate Signing Off-line CRL Signing CRL Signing Digital Signature OCSPSigning Digital Signature Code Signing Digital Signature Key Encipherment Server Authentication Digital Signature Key Encipherment Non-repudiation Client Authentication, Protection Table 22 - Utilisation des clés par type de certificat Période de validité des certificats On appelle «cryptoperiod» la période durant laquelle l utilisation d une clé spécifique est permise [SP800571]. Il est important de choisir des valeurs qui conviennent à l utilisation prévue pour une clé donnée, car cette valeur permet de fixer certaines limites (ex. : quantité de données pouvant être chiffrées à l aide de la clé, impact lié à la compromission de la clé, etc.) Cette valeur doit être déterminée en tenant compte des risques liés à l utilisation de la clé (ex. : robustesse du mécanisme de sécurité utilisé, niveau de sensibilité des données qu elle sert à protéger, etc.) [SP800571]. Par conséquent, il est présentement difficile d émettre des recommandations spécifiques quant à la durée de vie des certificats à clé publique des EESS. Par contre, il est tout de même possible de suggérer certaines valeurs susceptibles de convenir à leurs besoins. Le tableau suivant contient des valeurs suggérées, basées sur les pratiques courantes de certaines autorités de certification reconnues. Page 76 sur 96

77 Profil de certificat AC racine AC intermédiaire Serveur OCSP Signature de code Serveur SSL Entité d extrémité Durée de vie 20 ans 10 ans 2 ans 2 ans 2 ans 2 ans Table 23 - Durée de vie suggérée par profil de certificat 5.5 Certificats des serveurs Web publics À la base, les certificats à clé publique qui seront générés par l ICP communautaire des EESS ne seront reconnus que par les membres de la communauté. En cas de besoin, il sera éventuellement possible d étendre cette reconnaissance en faisant appel à l un des mécanismes suivants : 1. Établir un lien de confiance avec d autres entreprises en échangeant les certificats racines, c'est-à-dire en établissant un lien de certification croisé; 2. En devenant une autorité de certification reconnue par la communauté du Web, en se conformant à des règles d opérations très strictes, afin d obtenir une certification telle que WebTrust; Devenir une autorité de certification reconnue implique des coûts ainsi que des efforts considérables qui ne pourraient être justifiés que si l EESS décidait d exploiter le service d ICP commercialement. Dans le contexte actuel, le seul besoin justifiant l utilisation de certificats émis par une autorité de certificat reconnue est la présentation envers le grand public. Il est inacceptable pour un site internet corporatif sécurisé destiné au grand public, d utiliser un certificat serveur émis par une autorité de certification non reconnue. La raison est fort simple, c est qu un tel certificat ne sera pas reconnu par le fureteur web de l utilisateur. Un message de sécurité lui sera présenté lors de l établissement de la connexion au site Web. La figure suivante illustre le mécanisme d alerte de sécurité du fureteur Firefox. Figure 31 - Alerte de sécurité du fureteur Firefox Page 77 sur 96

78 Afin d éviter cette situation, les EESS devront faire l acquisition des certificats SSL destinés aux serveurs web publics auprès d une autorité de certification reconnue. À noter que, bien qu il s agisse d une pratique peu courante, les EESS pourraient éventuellement décider d émettre, via leur ICP communautaire, un certificat à clé publique à chacun de leurs clients. Ces certificats pourraient par exemple servir à l authentification des clients qui accèdent aux applications web de l entreprise. Page 78 sur 96

79 6 Expérimentations Ce chapitre décrit les expérimentations menées dans le cadre de ce projet. Des travaux pratiques furent réalisés, afin de démontrer comment la Chaire et les EESS pourront utiliser les certificats à clé publique émis par l ICP, afin de sécuriser des applications web internes, ou partagées par les membres de la communauté des EESS. La section 6.1 décrit l infrastructure ayant été mise en place afin de produire les certificats nécessaires aux expérimentations. Les sections 6.2 et 6.3 décrivent la marche à suivre pour utiliser les certificats à clé publique dans un contexte d application web en configurant adéquatement un serveur web Apache et un fureteur web FireFox. 6.1 Description de l environnement Les expérimentations ont été réalisées dans un environnement fermé, constitué d un poste client Windows XP et d un serveur Linux. Sur le serveur Linux fut déployé EJBCA, ainsi que les autres composantes logicielles requises afin d offrir les services de gestion des clés publiques. Sur ce même serveur fut aussi installé un serveur Web Apache, utilisé pour démontrer l utilisation des certificats à clé publique avec le protocole SSL. Figure 32 - Environnement pour les expérimentations La section décrit la configuration logicielle du poste client ainsi que du serveur hébergeant l ICP. La section décrit l architecture de l ICP ainsi que les certificats utilisés pour mener les expérimentations. Page 79 sur 96

80 6.1.1 Configurations logicielles La figure ci-dessous illustre l agencement des composantes logicielles installées sur les deux ordinateurs utilisés pour réaliser les expérimentations. Figure 33 - Configurations logicielles client et serveur Les composantes logicielles ont été installées en suivant les procédures d installation disponibles sur les sites internet des éditeurs Architecture de l ICP L ICP fût configurée de manière à refléter les recommandations émises au chapitre précédant La création de trois (3) AC a permis de créer un modèle de confiance hiérarchique à 2 niveaux tel que recommandé à la section 5.2. La Figure 34 illustre le modèle de confiance hiérarchique à deux (2) niveaux créés à l aide de l instance d EJBCA installée sur le serveur Linux. Ce modèle comprend l AC racine, ainsi que deux (2) AC émettrices subordonnées, soit une AC pour l émission des certificats destinés aux utilisateurs et une autre AC pour l émission des certificats destinés aux serveurs SSL. Figure 34 - Modèle de confiance de l'environnement d expérimentation Page 80 sur 96

81 Le tableau ci-dessous contient les valeurs des principaux attributs des certificats X.509v3 émis via l ICP pour réaliser les expérimentations. Autorité de certification racine DN du sujet DN de l émetteur Validité Clé publique Key Usage Algorithme de signature CN=RootCA1, O=AI2L.org CN=RootCA1, O=AI2L.org 20 ans RSA (2048 bits) Digital Signature, Key certificate sign, CRL sign. SHA1WithRSAEncryption Autorité de certification émettrice pour serveurs SSL DN du sujet DN de l émetteur Validité Clé publique Key Usage Algorithme de signature CN=AI2L.org CA pour Serveurs SSL, O=AI2L.org CN=RootCA1, O=AI2L.org 10 ans RSA (2048 bits) Digital Signature, Key certificate sign, CRL sign. SHA1WithRSAEncryption Autorité de certification émettrice pour utilisateurs DN du sujet DN de l émetteur Validité Clé publique Key Usage Algorithme de signature Entité d extrémité Serveur DN du sujet DN de l émetteur Validité Clé publique Key Usage Algorithme de signature Client DN du sujet DN de l émetteur Validité Clé publique Key Usage Algorithme de signature CN=AI2L.org CA Classe-1, O=AI2L.org CN=RootCA1, O=AI2L.org 10 ans RSA (2048 bits) Digital Signature, Key certificate sign, CRL sign. SHA1WithRSAEncryption CN= O=AI2L.org CN=AI2L.org CA pour Serveurs SSL, O=AI2L.org 2 ans RSA (2048 bits) Digital Signature, Key encipherment SHA1WithRSAEncryption CN=Utilisateur1, O=AI2L.org CN=AI2L.org CA Classe-1, O=AI2L.org 2 ans RSA (2048 bits) Digital Signature, Non-repudiation, Key encipherment SHA1WithRSAEncryption Table 24 - Attributs des certificats utilisés pour les expérimentations Page 81 sur 96

82 6.2 Création des entités dans l ICP Pour réaliser les expérimentations, il a fallu procéder à la création de deux (2) profils d entités d extrémité dans l ICP, soit une entité nommée « correspondant au serveur Web, ainsi qu une entité client nommée «Utilisateur1». La création des profils de ces entités fut réalisée à l aide de la fonction «Gestion de profils d entités» offerte par la console d administration d EJBCA. Figure 35 - Création d'une entité dans EJBCA Pour procéder à la création d un profil d entité dans l ICP, il faut fournir un certain nombre d informations de base telles que le nom de l entité, son common name (CN), le nom de l AC qui devra procéder à l émission du certificat, etc. Le nom et le mot de passe qui sont spécifiés lors de la création du profil permettront par la suite à l entité d extrémité de récupérer son certificat à clé publique. 6.3 Génération et installation des certificats SSL Après avoir ajouté les profils des deux (2) entités d extrémité dans l ICP, il fut possible de procéder à la création de leurs certificats à clé publique respectifs. La section décrit la méthode utilisée pour créer le certificat du serveur web Apache en générant les clés directement sur la machine où s exécute le serveur. La section décrit la technique utilisée pour récupérer le certificat à clé publique ainsi que la clé privée de l utilisateur ayant été généré de manière centralisée par l AC Certificat SSL du serveur Web La génération des clés du serveur fût réalisée en place, c'est-à-dire sur le serveur où s exécute le serveur Web qui utilisera la clé privée. Pour ce faire, nous avons fait appel à OpenSSL ( une boîte à outils pratique, offrant une interface ligne de commande qui permet entre autres de réaliser rapidement différents types d opérations cryptographiques. OpenSSL permet de réaliser en une seule étape, la génération des clés cryptographiques ainsi que la création de la requête de signature de certificat (CSR). Au moment de l exécution de cette commande, il faut fournir certaines informations sur l identité de l entité, ainsi que le mot de passe servant à protéger la clé privée. Page 82 sur 96

83 Exemple 1 - Génération des clés et de la demande de signature de certificat Openssl req new newkey rsa :2048 keyout key.pem nodes out csr.pem Generating a 2048 bit RSA private key writing new private key to 'key.pem' You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank Country Name (2 letter code) [AU]:ca State or Province Name (full name) [Some-State]:qc Locality Name (eg, city) []:Montreal Organization Name (eg, company) [Internet Widgits Pty Ltd]:AI2L.org Organizational Unit Name (eg, section) [] : Common Name (eg, YOUR name) []: Address [] : Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:Passw0rd An optional company name []: Les fichiers key.pem et csr.pem créés lors de l exécution de cette commande contiennent respectivement la clé privée de l entité ainsi que la demande de signature de certificat à clé publique en format PKCS#10. L étape suivante consiste à faire signer le certificat par l AC. Pour ce faire, il a suffi d accéder au site Web public de notre ICP, puis d utiliser la fonction «Create Certificate from CSR». Pour réaliser cette opération, il fallait avoir en main les informations suivantes : Nom et mot de passe de l entité d extrémité faisant la demande de signature de certificat. Ces informations ont été spécifiées lors de la création du profil d entité par l administrateur (voir la section 6.2). Ces informations sont généralement communiquées à l entité d extrémité de vive voix ou par courriel de façon automatisée. La requête de signature de certificat (CSR) générée à l aide d OpenSSL (fichier csr.pem). EJBCA permet de procéder en utilisant le fichier directement ou en copiant son contenu (format texte) dans le champ du formulaire prévu à cet effet. Une fois ces informations saisies, il ne restait plus qu à appuyer sur le bouton «OK» afin que l AC valide les informations et procède à la signature du certificat à clé publique. Une fois la signature complétée, une boite de dialogue standard du fureteur Web a invité à sauvegarder le fichier cert.pem contenant le certificat à clé publique. Page 83 sur 96

84 Figure 36 - Signature du certificat SSL du serveur par l'ac Lorsqu un certificat SSL serveur est émis par une autorité de certification émettrice intermédiaire, il faut configurer la chaine de certificat complète au niveau du serveur Web Apache. En d autres mots, il faut fournir au serveur Web tous les certificats de la hiérarchie d AC qui sont nécessaires à la validation de son propre certificat. Ainsi, le serveur pourra transmettre cette chaine de certificats aux clients lors de l établissement de la connexion (handshake), afin de leur permettre d authentifier son certificat. Dans le modèle de confiance à deux (2) niveaux, la chaine de certificat se compose donc des certificats de l AC racine «CN=RootCA1, O=AI2L.org», ainsi que de l AC intermédiaire ayant signée le certificat du serveur, c'est-à-dire «CN=AI2L.org CA pour Serveurs SSL, O=AI2L.org». Ces certificats ont été téléchargés en format PEM (Privacy Enhanced Mail) à partir du site Web public de l ICP, à l aide de la fonction «Fetch CA & OCSP Certificates». Page 84 sur 96

85 Figure 37 - Téléchargement des certificats d'ac Le serveur Web Apache demande à ce que tous les certificats d AC de la chaine soient placés les uns à la suite des autres dans un même fichier PEM. Il a donc fallu concaténer les deux fichiers PEM téléchargés dans un nouveau fichier nommé server_ca_chain.pem. Une fois cette étape franchie, il ne nous restait plus qu à compléter la configuration du serveur Web Apache afin qu il puisse utiliser ces certificats. Pour ce faire, il suffit de réaliser les quelques opérations suivantes : 1. Créer le répertoire /etc/apache2/ssl et placer les fichiers suivants : o o o cert.pem (le certificat à clé publique); key.pem (la clé privée); server_ca_chain.pem (la chaine de certificats); 2. Éditer le fichier /etc/apache2/sites-available/default-ssl afin d ajuster les paramètres suivants : SSLCertificateFile /etc/apache2/ssl/cert.pem SSLCertificateKeyFile /etc/apache2/ssl/key.pem SSLCertificatePathChainFile /etc/apache2/ssl/server_ca_chain.pem 3. Redémarrer le serveur à l aide de la commande suivante : sudo /etc/init.d/apache2 restart 4. À l aide d un fureteur Web, accéder à la page d accueil du site : Lors de la tentative de connexion, le fureteur Web Firefox nous signale qu il lui est impossible de procéder à la validation du certificat serveur. Ce comportement était attendu puisque le certificat racine de notre ICP permettant de valider le certificat du serveur n avait pas encore été installé au niveau du fureteur Web. Page 85 sur 96

86 Figure 38 - Le certificat du serveur n'est pas reconnu par le fureteur Web Certificat du client dans le fureteur Web Firefox La toute première étape dans la configuration du client Web Firefox consistait à y installer le certificat de notre autorité de certification racine, afin de permettre de connecter à notre serveur Web de façon normal, c'est-à-dire sans avertissement du genre à celui illustré par la Figure 38. Pour ce faire, il a suffi d accéder au site Web public de notre ICP, puis d utiliser de nouveau la fonction «Fetch CA & OCSP Certificates» telle qu illustré par la Figure 37, afin d installer le certificat de l AC racine «CN=RootCA1, O=AI2L.org» en cliquant simplement sur le lien «Download to Firefox». Figure 39 - Installation du certificat racine dans FireFox Après avoir accepté le certificat de notre AC racine en confirmant que celui-ci serait utilisé pour identifier de sites Web, le certificat a été installé dans le fureteur et se retrouvait parmi les certificats racine des autorités de certification reconnues telle qu en témoigne la figure suivante : Page 86 sur 96

87 Figure 40 - Le certificat de notre AC racine installé dans Firefox Suite à l installation de notre certificat racine, il a été possible d accéder à la page principale de notre serveur de test sécurisé, et ce, sans aucun avertissement de la part du fureteur Web. Figure 41 - Page d'accueil du serveur de test La prochaine étape consistait à démontrer comment l ICP permettra de bénéficier de l authentification par certificat offert par le protocole SSL. Nous avons donc procédé à l installation d un certificat client dans le fureteur Firefox, et ce, simplement en faisant appel à la fonction «Create Browser Certificate» offerte par le site Web public de notre ICP. Pour réaliser cette opération, nous n avons eu besoin que du nom et du mot de passe spécifiés lors de la création du profil d entité à la section 6.2. Ces informations sont généralement communiquées à l entité d extrémité de vive voix ou de par courriel de façon automatisée. Page 87 sur 96