EESS - Gestion Des Cles Publiques

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
Projet en génie logiciel
Gestion des clés publiques pour les EESS
Table des matières
Table des matières..............................................................................................3
Liste des figures .................................................................................................5
Liste des tableaux...............................................................................................6
Sigles et abréviations .........................................................................................8
1 Introduction............................................................................................. 10
1.1 Contexte.............................................................................................................. 10
1.2 Objectifs .............................................................................................................. 11
1.3 Structure du document......................................................................................... 11
2 Définition du problème........................................................................... 12
3 Gestion des clés publiques ................................................................... 14

3.1 La cryptographie.................................................................................................. 14
3.1.1 Mécanismes cryptographiques.................................................................. 15
3.1.2 Les familles d’algorithmes cryptographiques ............................................. 17
3.2 Normes et standards ........................................................................................... 19
3.2.1 IETF PKIX ................................................................................................ 20
3.2.2 RSA PKCS ............................................................................................... 21
3.2.3 ISO TC 68/SC 2........................................................................................ 22
3.2.4 ISO JTC 1................................................................................................. 23
3.2.5 ANSI X9 ................................................................................................... 23
3.2.6 ITU-T ........................................................................................................ 24
3.2.7 NIST ......................................................................................................... 24
3.3 L’infrastructure à clé publique (ICP) ..................................................................... 26
3.3.1 Les composantes de l’ICP ........................................................................ 27
3.3.2 Les services de gestion offerts par l’ICP.................................................... 28
3.3.3 Les services de sécurité offerts par l’ICP................................................... 29
3.3.4 Les protocoles de l’ICP ............................................................................. 30
3.3.5 Le certificat à clé publique......................................................................... 31
3.3.6 La gestion du cycle de vie des clés et des certificats ................................. 37
3.3.7 La confiance ............................................................................................. 41
3.3.8 Les composantes physiques ..................................................................... 49
4 Les solutions d’ICP................................................................................. 50

4.1 Les produits logiciels ........................................................................................... 50
4.1.1 RSA Digital Certificate Solution ................................................................. 51
4.1.2 Entrust Authority ....................................................................................... 53
4.1.3 EJBCA...................................................................................................... 56
4.1.4 Les observations....................................................................................... 59
4.2 Les services hébergés ......................................................................................... 60
4.2.1 Entrust - Managed Services PKI ............................................................... 61
4.2.2 OpenTrust - Software as a Service (SaaS)................................................ 62
4.2.3 Les observations....................................................................................... 63
5 Recommandations.................................................................................. 64
Page 3 sur 96
5.1 « PKI as a Service » ............................................................................................ 65

5.1.1 Logiciels libres requis................................................................................ 67
5.1.2 Organisation des composantes ................................................................. 69
5.2 Modèle de confiance............................................................................................ 72
5.3 Politiques de certification ..................................................................................... 72
5.4 Gestion des clés cryptographiques ...................................................................... 73
5.4.1 Algorithmes asymétriques et longueurs de clés......................................... 73
5.4.2 Algorithmes symétriques........................................................................... 73
5.4.3 Fonctions de hachage............................................................................... 74
5.4.4 Génération des clés .................................................................................. 74
5.4.5 Stockage des clés..................................................................................... 75
5.4.6 Utilisation des clés .................................................................................... 76
5.4.7 Période de validité des certificats .............................................................. 76
5.5 Certificats des serveurs Web publics ................................................................... 77
6 Expérimentations.................................................................................... 79
6.1 Description de l’environnement ............................................................................ 79
6.1.1 Configurations logicielles .......................................................................... 80
6.1.2 Architecture de l’ICP ................................................................................ 80
6.2 Création des entités dans l’ICP ............................................................................ 82
6.3 Génération et installation des certificats SSL........................................................ 82
6.3.1 Certificat SSL du serveur Web .................................................................. 82
6.3.2 Certificat du client dans le fureteur Web Firefox ........................................ 86
6.3.3 Activation de l’authentification client par certificat ...................................... 89
7 Conclusion .............................................................................................. 91
Bibliographie ..................................................................................................... 93
Page 4 sur 96
Liste des figures
Figure 1 - Chiffrement d'un message. Source [NETASSI] ...................................................... 15

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

Figure 34 - Modèle de confiance de l'environnement d’expérimentation ............................ 80
Figure 35 - Création d'une entité dans EJBCA .......................................................................... 82
Figure 36 - Signature du certificat SSL du serveur par l'AC ................................................... 84
Figure 37 - Téléchargement des certificats d'AC ...................................................................... 85
Figure 38 - Le certificat du serveur n'est pas reconnu par le fureteur Web ........................ 86
Figure 39 - Installation du certificat racine dans FireFox......................................................... 86
Figure 40 - Le certificat de notre AC racine installé dans Firefox.......................................... 87
Figure 41 - Page d'accueil du serveur de test............................................................................ 87
Figure 42 - Génération du certificat client ................................................................................... 88
Figure 43 - Confirmation de l'installation du certificat client dans Firefox............................ 88
Figure 44 - Le certificat client installé dans Firefox................................................................... 89
Figure 45 - Connexion au serveur Web avec authentification par certificat........................ 90
Liste des tableaux
Table 1 - Algorithmes asymétriques............................................................................................. 18

Table 2 - Principales sources normatives pour l'ICP................................................................ 19
Table 3 - Standard PKCS ayant été repris par l'IETF............................................................... 22
Table 4 - Services de gestion offerts par l’ICP. Inspiré de [ADAMS03] ............................... 29
Table 5 - Description des services primaires offerts par l’ICP. Inspiré de [ADAMS03] .... 29
Table 6 - Services complémentaires offerts par l’ICP. Inspiré de [ADAMS03]................... 30
Table 7 - Évolution du certificat X.509 ......................................................................................... 32
Table 8 - Attributs d'un certificat X.509 v3 .................................................................................. 33
Table 9 - Attributs de nommage LDAP standard. Source [RFC4514].................................. 35
Table 10 - Les extensions standards X.509 v3.......................................................................... 37
Table 11 - Caractéristiques du modèle de confiance simple avec AC unique ................... 43
Table 12 - Caractéristiques du modèle de confiance simple avec liste de confiance ...... 44
Table 13 - Caractéristiques du modèle de confiance Hiérarchique ...................................... 45
Table 14 - Caractéristiques du modèle de confiance en réseau ........................................... 46
Table 15 - Caractéristiques du modèle de confiance Hybride................................................ 47
Table 16 - Caractéristiques techniques - RSA Certificate Manager ..................................... 52
Table 17 - Caractéristiques techniques - Entrust Authority Security Manager................... 55
Table 18 - Caractéristiques techniques - EJBCA ...................................................................... 59
Page 6 sur 96
Table 19 - Liste des composantes logicielles requises............................................................ 67

Table 20 - Longueurs de clés recommandées par le NIST. Source [SP800573].............. 73
Table 21 - Exigences pour le module de sécurité. Source [SP800573]............................... 75
Table 22 - Utilisation des clés par type de certificat ................................................................. 76
Table 23 - Durée de vie suggérée par profil de certificat......................................................... 77
Table 24 - Attributs des certificats utilisés pour les expérimentations.................................. 81
Page 7 sur 96
Sigles et abréviations
AC Autorité de certification
AE Autorité d’enregistrement
AEL Autorité d’enregistrement locale
AES Advanced Encryption Standard
CMP Certificate Management Protocol
CRL Certificates Revocation List
EAL Evaluation Assurance Level
ECDSA Elliptic Curve Digital Signature Algorithm
DES Data Encryption Standard
DN Distinguished Name
DSA Digital Signature Algorithm.
EE End entity (entité d’extrémité)
EESS Entreprises de l’Économie Sociale et Solidaire
FIPS Federal Information Processing Standard
HSM Hardware Security Module
HTTP HyperText Transfer Protocol
HTTPS Hypertext Transfer Protocol over Secure Socket Layer
ICP Infrastructure à clé publique
IPSec Internet Protocol Security
IETF Internet Engineering Task Force
ISO International Organization for Standardization
ISO/IEC ISO / International Electrotechnical Commission
ITU International Telecommunication Union
ITU-T ITU - Telecommunication Standardization Sector
JKS Java KeyStore
LDAP Lightweight Directory Access Protocol
LGPL GNU Lesser General Public License
MAC Message Authentication Code
MD5 Message Digest 5 (algorithme de hachage)
NIST National Institute of Standards and Technology
OCSP Online Certificate Status Protocol
OLF Office de la Langue Française
Page 8 sur 96
PEM Privacy Enhanced Mail

PKCS The Public-Key Cryptography Standards
PKI Public-Key Infrastructure
PKIX Public-Key Infrastructure X.509
RC4 Rivest Cipher 4
RFC Request For Comments
RSA Algorithme de chiffrement à clé publique et de signature inventé par
R.Rivest, A.Shamir et l.Adleman.
SCEP Simple Certificate Enrollment Protocol
SHA-1 Secure Hash Algorithm Number 1. SHA (algorithme de hachage).
S/MIME Secure/Multipurpose Internet Mail Extensions
SQL Structured Query Language
SSL Secure Socket Layer
VPN Virtual Private Network
W3C World Wide Web Consortium
XKMS XML Key Management Specification
XML Extensible Markup Language
Page 9 sur 96
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
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 Introduction à la cryptographie;
o Identification des principaux éléments normatifs;
o Présentation détaillée de l’Infrastructure à clé publique (ICP);
• Exploration des différentes solutions d’ICP offertes aux entreprises :
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;
o 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
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
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
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
3.1.1 Mécanismes cryptographiques
3.1.1.1 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
Figure 1 - Chiffrement d'un message. Source [NETASSI]
3.1.1.2 La fonction de hachage

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
3.1.1.3 La signature numérique

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
3.1.2 Les familles d’algorithmes cryptographiques
3.1.2.1 Les algorithmes symétriques (à clé secrète)

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.
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 RC4.
3.1.2.2 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
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
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
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
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 5280 - 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 4630. Ce RFC constitue la
proposition du groupe de travail PKIX pour l’utilisation de l’ICP sur l’internet
[RFC5280].
• RFC 2560 - 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 3161 - 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 3647 - 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 4210 - 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 4211 - 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 2511.
.
Page 20 sur 96
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
• 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 IETF
PKCS#1 RFC 3447 - Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography
PKCS#5 RFC 2898 - PKCS #5: Password-Based Cryptography Specification
PKCS#7 RFC 2315 - PKCS #7: Cryptographic Message Syntax
PKCS#8 RFC 5308 - Public-Key Cryptography Standards (PKCS) #8 : Private-Key
Information Syntax Specification Version 1.2
PKCS#10 RFC 2986 - PKCS #10 : Certification Request Syntax Specification
Table 3 - Standard PKCS ayant été repris par l'IETF
3.2.3 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 15782-1:2009 - 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 15782-1:2009 - 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
• ISO 21188:2006 - 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.
3.2.4 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 9594-8:2005 - 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 15408-1:2009 - 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]
3.2.5 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 X9.79 - 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
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.
3.2.6 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 9594-8: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 9594-8:2008). Nous privilégions donc l’utilisation du
[RFC5280] dans le cadre de ce travail.
3.2.7 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 SP800-15 - 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 SP800-21 - Guideline for Implementing Cryptography in the Federal
Government. Recommandations générales sur la sélection des
mécanismes cryptographiques.
o SP800-32 - 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
o SP800-57 - 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 140-2 - 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
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 3.3.1 à 3.3.8 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
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
• 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.
3.3.2 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 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.
Publication de certificats 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.
Recouvrement de clés 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
Service Description
son poste de travail.
Séquestre de clés 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 de vérification en Service permettant à un utilisateur de déterminer si un certificat
ligne (OCSP) a fait l’objet d’une révocation, sans avoir à gérer de listes de
révocation (CRL).
Service de vérification hors Service permettant à un utilisateur de récupérer une liste de
ligne (CRL) 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]
3.3.3 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 Description
Authentification Service qui permet à un utilisateur de s’assurer qu’une entité
est réellement qui elle prétend être.
Intégrité 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.
Confidentialité 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 Description
Communication sécurisée 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
Service Description
Horodatage 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.
Notarisation 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.
Non-répudiation 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.
Gestions des privilèges 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]
3.3.4 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.
3.3.4.1 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.
3.3.4.2 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
Les messages du protocole CMP peuvent être véhiculés à l’aide de protocoles

applicatifs tels que HTTP, SMTP, FTP et autres.
3.3.4.3 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.
3.3.4.4 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).
3.3.4.5 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.
3.3.5 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
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

9594-8, 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.
1993 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.
1996 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
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 Description
Version Numéro de version du standard X.509 auquel répond le certificat.
SerialNumber Numéro d’identification du certificat. Ce numéro unique permet
d’identifier le certificat parmi tous les certificats émis par une AC.
Issuer Identité de l’AC ayant émis le certificat.
Validity 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.
Subject Identité de l’entité à qui appartient la clé publique contenue dans le
certificat.
SubjectPublicKeyInfo Clé publique de l’entité ainsi que l’algorithme associé (ex. : RSA).
Extensions Attribut permettant d’ajouter d’autres attributs sans affecter la
définition de la structure du certificat.
Signature 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.
3.3.5.1 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
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.
o 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.
3.3.5.2 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
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 (2.5.4.3)
L localityName (2.5.4.7)
ST stateOrProvinceName (2.5.4.8)
O organizationName (2.5.4.10)
OU organizationalUnitName (2.5.4.11)
C countryName (2.5.4.6)
STREET streetAddress (2.5.4.9)
DC domainComponent (0.9.2342.19200300.100.1.25)
UID userId (0.9.2342.19200300.100.1.1)
Table 9 - Attributs de nommage LDAP standard. Source [RFC4514]
3.3.5.3 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 Description
Authority Key Identifier 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.
Subject Key Identifier Permet d’identifier la clé publique que contient le certificat. Une
entité peut détenir plus d’une paire de clés.
Key Usage 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
• nonRepudiation;
• keyEncipherment;
• dataEncipherment;
• keyAgreement;
• keyCertSign;
• cRLSign;
• encipherOnly;
• decipherOnly;
Certificate Policies 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.
Policy Mappings Permet de spécifier des équivalences entre des politiques de
deux domaines de certification.
Subject Alternative Name 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.).
Issuer Alternative Name Permet de spécifier un nom alternatif afin de désigner l’AC
ayant émis le certificat (ex. : adresse de courriel, nom DNS,
etc.).
Subject Directory Attribute Permet de spécifier des attributs supplémentaires concernant
l’entité propriétaire de la clé publique.
Basic Constraints 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.
Name Constraints 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.
Policy Constraints Permet de contrôler l’application des politiques sur les
certificats émis par l’AC. Applicable uniquement aux certificats
d’AC.
Extended Key Usage 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_emailProtection;
• id_kp_ipsecEndSystem;
• id_kp_ipsecTunnel;
• id_kp_ipsecUser;
• id_kp_timeStamping;
• OCSPSigning;
CRL Distribution Point 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
d’une liste d’URI (LDAP, HTTP, etc.).
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 v3
3.3.6 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
3.3.6.1 Phase « Initialisation »
3.3.6.1.1 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.
3.3.6.1.2 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é elle-
mê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 non-
ré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
3.3.6.1.3 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.
3.3.6.1.4 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.
3.3.6.1.5 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é.
3.3.6.2 Phase « Émis »
3.3.6.2.1 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.
3.3.6.2.2 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
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.
3.3.6.2.3 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.
3.3.6.2.4 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é.
3.3.6.3 Phase « Annulation »
3.3.6.3.1 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.
3.3.6.3.2 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.
3.3.6.3.3 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.
3.3.6.3.4 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
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.
3.3.7.1 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
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
3.3.7.2 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
Cette section décrit les modèles de confiance les plus répandus, ainsi que leurs
avantages et inconvénients respectifs.
3.3.7.2.1 Modèle simple avec AC unique

Caractéristique Valeur
Nombre d’AC en relation Une seule.
Types de relations entre AC n/a
Ajout d’une nouvelle AC n/a
Complexité associée à la Très faible complexité en raison du fait qu’il n’existe qu’une
création du chemin de seule AC. Tous les certificats sont émis par cette AC.
certification
Résilience face à la Impact désastreux. Tous les certificats émis par cette AC
compromission d’une 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
3.3.7.2.2 Modèle simple avec liste de confiance

Nombre d’AC en relation Plusieurs
Types de relations entre AC Aucun. L'utilisateur gère lui-même la liste des certificats des
autorités de certification en qui il a « confiance ».
Ajout d’une nouvelle AC L‘utilisateur ajoute lui-même le certificat de la nouvelle AC dans
sa liste de confiance.
Complexité associée à la Très faible complexité en raison du fait qu’il n’y a pas de
création du chemin de chemin de certification. Les seuls certificats acceptés sont ceux
certification qui ont été émis par les AC dont les certificats se trouvent dans
la liste de confiance.
Résilience face à la Très difficile à gérer en raison du fait que l’utilisateur ne sera
compromission d’une AC 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
3.3.7.2.3 Modèle Hiérarchique

Types de relations entre AC Supérieure à subordonnée.
Ajout d’une nouvelle AC Facile en émettant un nouveau certificat à la nouvelle AC à
partir d’une AC existante.
Complexité associée à la Faible complexité en raison du fait que chaque AC n’a qu’un
création du chemin de seul et unique supérieur. Il s’agit d’une opération déterministe.
certification
Résilience face à la • AC Racine : Impact désastreux. Tous les certificats émis par
compromission d’une AC 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
3.3.7.2.4 Modèle en réseau

Nombre d’AC en relation Plusieurs.
Types de relations entre AC « Peer-to-Peer ».
Ajout d’une nouvelle AC Facile. La nouvelle AC échange son certificat avec une autre
AC déjà membre du réseau.
Complexité associée à la Élevée en raison du fait qu’il s’agit d’une opération non
création du chemin de déterministe, puisqu’il peut exister plusieurs chemins possibles.
certification Certains chemins peuvent s’avérer être invalides ou amener à
tourner en rond.
Résilience face à la Faible impact en raison de ses multiples points de confiance
compromission d’une AC 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
3.3.7.2.5 Modèle Hybride

Nombre d’AC en relation Plusieurs.
Types de relations entre AC • Supérieure à subordonnée.
• « Peer-to-Peer ».
Ajout d’une nouvelle AC Facile. L’AC d’un domaine échange son certificat avec une AC
d’un autre domaine.
Complexité associée à la Élevée en raison du fait qu’il s’agit d’une combinaison entre les
création du chemin de modèles hiérarchiques et réseaux. Il est donc difficile de trouver
certification un chemin valide.
Résilience face à la Faible impact en raison des considérations énoncées pour le
compromission d’une AC modèle réseau. De plus, les utilisateurs peuvent se fier sur leur
autorité locale pour le signalement d’une compromission.
Remarques 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
3.3.7.3 Les politiques

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.
3.3.7.3.1 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
3.3.7.3.2 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.
3.3.8 Les composantes physiques
Cette section décrit brièvement les composantes physiques nécessaires à la mise en

œuvre d’une ICP.
3.3.8.1 É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.).
3.3.8.2 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 140-2 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
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 4.1.1 à 4.1.3 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 4.2.3 présente certaines observations faites sur ces solutions.
Page 50 sur 96
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 RSA Security

Produit RSA Certificate Manager
Version actuelle 6.8
Référence http ://www.rsa.com/node.aspx?id=1224
Plateformes Solaris™ 10 (Sparc™)
supportées Red Hat Linux
Windows® 2003 R2 SP2
Standards de • X.509 v3 (incluant toutes les extensions standards)
certificats • PKIX
supportés • SSL
• S/MIME
• IPSec
• SET
• Extended Validation
Page 51 sur 96
Certifications de Common Criteria EAL4+

l’industrie Federal Bridge CA (FBCA)
IdenTrust Certification
Caractéristiques de Comprends un dépôt de certificats de type LDAP intégré.
l’annuaire 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
Caractéristiques de X.509 CRLs et CRLs avec extensions
l’ICP Nombre illimité de d’AC subordonnées dans la chaîne de confiance
(ICP hiérarchique)
Caractéristiques de Certificats X.509 v1 et v3
certificats 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
Support RSA
cryptographique DSA P-256, P-384, et P-521
ECDSA
SHA-1 et SHA-2
Chiffrement Stockage des clés privées de l’AC dans des équipements de type
matériel 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 140-1 niveau 1 à 3 (via nCipher, SafeNet,
Utimaco, Thales, AEP et/ou autre équipements PKCS#11)
Modèle tarifaire 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 ://www.securehq.com:
Nombre Prix par Total pour le maximum
d’utilisateurs utilisateur d’utilisateurs
1-500 26.40$ 13 200.00$
501-1 000 22.92$ 22 920.00$
5 001-10 000 12.46$ 124 600.00$
50 001-100 000 7.69$ 769 000.00$
1 000 000 et + 3.86$ + de 3 860 000.00$
Table 16 - Caractéristiques techniques - RSA Certificate Manager
Page 52 sur 96
4.1.2 Entrust Authority
Le produit de gestion de certificats numériques d’Entrust fût introduit en 1994.

Maintenant rendu à sa 7iè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
Le tableau suivant présente les caractéristiques techniques du produit Entrust Authority

Security Manager.
Éditeur Entrust
Produit Entrust Authority Security Manager
Version actuelle 7.0
Référence http ://www.entrust.com/pki/
Plateformes Microsoft® Windows® Server 2003 Standard
supportées 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
Standards de Émission de certificats pour utilisateurs, équipements et applications
certificats supportant le standard de certificat X.509.
supportés 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.
Certifications de Common Criteria EAL4+
l’industrie
Caractéristiques de Interopérable avec annuaires LDAP (incluant Microsoft Active Directory)
l’annuaire
Caractéristiques de Liste de révocation (CRL) X.509 et CRL avec extensions
l’ICP 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)
Caractéristiques de Certificats X.509 v1 et v3
certificats 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
Support RSA (jusqu’à 6144-bits)
Page 54 sur 96
cryptographique DSA 1024

Elliptic Curve DSA signing
AES-256, DES, Triple-DES, CAST, IDEA
SHA-1, SHA-256
Chiffrement Stockage des clés privées de l’AC dans des équipements de type
matériel 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 140-1 niveau 1 à 3 (via nCipher, SafeNet)
Modèle tarifaire 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

100 39 350.00$
1 000 81 750.00$
10 000 343 750.00$
100 000 1 439 750.00$
1 000 000 5 653 750.00$
Table 17 - Caractéristiques techniques - Entrust Authority Security Manager
Page 55 sur 96
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
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
Le tableau suivant présente les caractéristiques techniques du produit EJBCA.
Éditeur PrimeKey Solutions

Solution EJBCA
Version actuelle 3.9.3
Référence http ://www.ejbca.org/
Plateformes Plateformes Java™ J2EE 1.3 (EJB 2.0).
supportées Serveurs d’applications :
• Jboss;
• Weblogic;
• Glassfish;
• OC4J;
• Websphere.
Standards de Émission de certificats pour utilisateurs, équipements et applications
certificats supportant le standard de certificat X.509 et Card Verifiable Certificates
supportés (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.
Certifications de Aucune.
l’industrie
Caractéristiques de Mécanisme de publication flexible permettant le stockage des certificats
l’annuaire 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).
Caractéristiques de Suit les standards X509 et PKIX (RFC 3280) lorsqu’applicables.
l’ICP 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.
Caractéristiques de Certificats X.509 v3
certificats Longueur de clés allant jusqu’à 4096-bit pour authentification.
Configuration flexible des DN de certificats.
Page 58 sur 96
Certificats S/MIME.
Signature d’objets (Java™, ActiveX®).
Extensions PKIX v3
Certificats Netscape, Mozilla, Microsoft® Internet Explorer, etc.
Certificats pour authentification par carte à puce.
Support RSA (jusqu’à 4096-bits)
cryptographique Elliptic Curve DSA signing
MD5, SHA-1, SHA-256
Chiffrement API modulaire pour équipements de type Hardware Security Module
matériel (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.
Modèle tarifaire Gratuit. Offert en logiciel libre sous licence LGPL, donc libre de toute
redevance pour utilisation, amélioration ou redistribution.
Table 18 - Caractéristiques techniques - EJBCA
4.1.4 Les observations
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
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 4.2.1 et 4.2.2 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
4.2.3 présente certaines observations faites sur ce type de solutions.
Page 60 sur 96
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
• 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.
4.2.2 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
L’offre OpenTrust PKI est disponible en trois différentes formes, soit :

• 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.
4.2.3 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 celles-
ci 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
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
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 4.1.3 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
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 5.1.1 présente la liste des logiciels libres qui permettront la mise en œuvre
d’une ICP dans le « cloud » communautaire des EESS. La section 5.1.2 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
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 Produit
Système d’exploitation Linux (distribution au choix)
ICP (AC, EA, OCSP) EJBCA
http://www.ejbca.org/
Serveur d’applications J2EE Jboss
http://www.jboss.org/
Java Runtime Environment Sun Java SE Development kit
http://java.sun.com/
Base de données PostgreSQL
http://www.postgresql.org/
Annuaire LDAP ApacheDS
http://directory.apache.org/
Serveur de signature SignServer
(Horodatage et Notarisation) http://www.signserver.org/
Serveur Web Apache HTTP Server
http://httpd.apache.org/
Pare-feu applicatif ModSecurity
http://www.modsecurity.org/
Table 19 - Liste des composantes logicielles requises
5.1.1.1 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.
5.1.1.2 EJBCA
Ce produit d’ICP est décrit en détail dans la section 4.1.3. 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
5.1.1.3 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.
5.1.1.4 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.
5.1.1.5 PostgreSQL
PostgreSQL est un puissant système de gestion de base de données (SGBD) objet-
relationnelle 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.
5.1.1.6 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.
5.1.1.7 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].
5.1.1.8 Apache http Server

Tout comme le système d’exploitation Linux, le serveur Web Apache s’impose de lui-
mê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
5.1.1.9 ModSecurity
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].
5.1.2 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 5.1.2.1 décrit la configuration des composantes logicielles des serveurs de
l’ICP et la section 5.1.2.2 propose un modèle pour la répartition de ces serveurs sur le
réseau.
5.1.2.1 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
5.1.2.2 Répartition des serveurs sur le réseau

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
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
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.
Figure 28 - Les deux niveaux d'AC
5.3 Politiques de certification

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
5.4 Gestion des clés cryptographiques

5.4.1 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 SP800-57 [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.
5.4.2 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
5.4.3 Fonctions de hachage
Il existe plusieurs fonctions de hachage. Le standard FIPS 180-3 [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é.
5.4.4 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
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 3.2.7 que la norme FIPS 140-2 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é Niveau de sécurité FIPS 140-2 requis

AC 3
OCSP 3
AE 2
Entité d’extrémité 1
Table 21 - Exigences pour le module de sécurité. Source [SP800573]
La section 3.3.8.2 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
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 Key Usage Certificate Signing
Off-line CRL Signing
CRL Signing
Extended Key Usage -
OCSP Key Usage Digital Signature
Extended Key Usage OCSPSigning
Signature de code Key Usage Digital Signature
Extended Key Usage Code Signing
SSL Serveur Key Usage Digital Signature
Key Encipherment
Extended Key Usage Server Authentication
Entité d’extrémité Key Usage Digital Signature
Key Encipherment
Non-repudiation
Extended Key Usage Client Authentication, Email Protection
Table 22 - Utilisation des clés par type de certificat
5.4.7 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
Profil de certificat Durée de vie

AC racine 20 ans
AC intermédiaire 10 ans
Serveur OCSP 2 ans
Signature de code 2 ans
Serveur SSL 2 ans
Entité d’extrémité 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
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
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 6.1.1 décrit la configuration logicielle du poste client ainsi que du serveur
hébergeant l’ICP. La section 6.1.2 décrit l’architecture de l’ICP ainsi que les certificats
utilisés pour mener les expérimentations.
Page 79 sur 96
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.
6.1.2 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
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 CN=RootCA1, O=AI2L.org
DN de l’émetteur CN=RootCA1, O=AI2L.org
Validité 20 ans
Clé publique RSA (2048 bits)
Key Usage Digital Signature, Key certificate sign, CRL sign.
Algorithme de signature SHA1WithRSAEncryption
Autorité de certification émettrice pour serveurs SSL
DN du sujet CN=AI2L.org CA pour Serveurs SSL, O=AI2L.org
Validité 10 ans
Autorité de certification émettrice pour utilisateurs
DN du sujet CN=AI2L.org CA Classe-1, O=AI2L.org
Validité 10 ans
Entité d’extrémité Serveur
DN du sujet CN=www.serveur1.ai2l.org, O=AI2L.org
DN de l’émetteur CN=AI2L.org CA pour Serveurs SSL, O=AI2L.org
Validité 2 ans
Key Usage Digital Signature, Key encipherment
Client
DN du sujet CN=Utilisateur1, O=AI2L.org
DN de l’émetteur CN=AI2L.org CA Classe-1, O=AI2L.org
Validité 2 ans
Key Usage Digital Signature, Non-repudiation, Key encipherment
Table 24 - Attributs des certificats utilisés pour les expérimentations
Page 81 sur 96
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 « www.serveur1.ai2l.org »
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 6.3.1
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 6.3.2 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.
6.3.1 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 (www.openssl.org), 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
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) []:www.serveur01.ai2l.org
Email 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
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
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 cert.pem (le certificat à clé publique);
o key.pem (la clé privée);
o 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 :
https://www.serveur1.ai2l.org/
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
Figure 38 - Le certificat du serveur n'est pas reconnu par le fureteur Web
6.3.2 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
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
La figure suivante illustre la saisie des informations dans le formulaire standard offert par
EJBCA pour récupérer puis installer le certificat d’une entité dans le fureteur Web
Firefox.
Figure 42 - Génération du certificat client
Après avoir saisi les informations puis avoir appuyé sur « OK », EJBCA a demandé de
spécifier certaines informations sur le profil de certificat à utiliser lors de la génération.
L’utilisation d’un profil de certificat personnalisé aurait permis d’éviter cette saisie qui
pourrait semer la confusion chez les utilisateurs.
Figure 43 - Confirmation de l'installation du certificat client dans Firefox

Après avoir appuyé sur « OK », le certificat fut téléchargé puis installé automatiquement.
Le fureteur Web a alors confirmé l’installation du certificat.
Page 88 sur 96
La figure suivante démontre que le certificat client de l'entité « Utilisateur1 » fût installé
avec succès dans la liste des certificats appartenant à l’utilisateur du fureteur.
Figure 44 - Le certificat client installé dans Firefox
6.3.3 Activation de l’authentification client par certificat
Afin de tester l’utilisation du certificat client de l’utilisateur nouvellement installé dans le

fureteur Web, il a fallu procéder à l’activation l’authentification client par certificat au
niveau du serveur Web. Pour ce faire, il a suffi de réaliser les quelques étapes
suivantes :
1. Créer le fichier contenant la chaine de certificats qui permettra au serveur

d'authentifier les clients.
La chaine de certificat se compose du certificat de l’AC racine « CN=RootCA1,
O=AI2L.org » ainsi que du certificat de l’AC intermédiaire ayant signée le
certificat des clients, c'est-à-dire « CN=AI2L.org CA Classe-1, 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 »
tel qu’illustré par la Figure 37.
Les deux (2) fichiers PEM téléchargés ont été concaténés dans un nouveau
fichier nommé client_ca_chain.pem.
2. Copier le fichier client_ca_chain.pem dans le répertoire /etc/apache2/ssl.
3. Éditer le fichier /etc/apache2/sites-available/default-ssl afin d’ajuster les

paramètres suivants :
SSLCACertificateFile /etc/apache2/ssl/client_ca_chain.pem
SSLVerifyClient require
SSLVerifyDeapth 2
Page 89 sur 96
4. Redémarrer le serveur à l’aide de la commande suivante :

sudo /etc/init.d/apache2 restart
5. À l’aide d’un fureteur Web, accéder à la page d’accueil du site :
https://www.serveur1.ai2l.org/
Lors de l’établissement de la session SSL avec le serveur Web, ce dernier a demandé
au client de s’authentifier à l’aide de son certificat. Le fureteur Web a demandé de
choisir le certificat à utiliser parmi la liste des certificats personnels installés.
Figure 45 - Connexion au serveur Web avec authentification par certificat
Après avoir sélectionné le certificat puis avoir appuyé sur « OK », l’établissement de la

session SSL s’est poursuivi et l’authentification fut réalisée avec succès.
Page 90 sur 96
7 Conclusion
En conclusion, depuis son introduction dans les années ’70, la cryptographie à clé
publique a permis de développer de nombreuses solutions de sécurité. Cependant, la
gestion des clés publiques représente toujours un défi de taille pour les entreprises.
Pour effectuer cette gestion, on doit recourir à une infrastructure à clé publique. Cette
infrastructure est constituée de composantes matérielles et logicielles. Son exploitation
est encadrée par des politiques ainsi que des procédures très strictes dont l'objectif est
d’assurer son intégrité afin qu’elle demeure digne de confiance.
Cette étude a démontré que les entreprises peuvent aujourd’hui recourir à différentes
solutions en matière de gestion de clés publiques. Une entreprise peut donc :
• faire l’acquisition de certificats à clé publique auprès d’une autorité de
certification commerciale;
• gérer elle-même ses certificats en faisant appel à une infrastructure hébergée;
• mettre en place sa propre infrastructure qui lui permet de gérer ses propres
certificats à l’interne.
Depuis bon nombre d’années, plusieurs groupes de travail s’affairent à définir des
normes et des standards en la matière. Ces initiatives ont eu pour effet de favoriser
l’interopérabilité entre les différentes composantes de l’ICP et les systèmes de sécurité
qui les utilisent. Les entreprises ont maintenant plus de facilité à mettre en œuvre des
solutions techniques interopérables, car les produits logiciels offerts respectent ces
standards.
Les travaux réalisés dans le cadre de cette étude ont aussi permis d’identifier un produit
d’ICP complet, offert en logiciel libre qui répond aux principaux standards de l’industrie.
Le produit logiciel EJBCA est suffisamment complet et flexible pour répondre à la
majorité des besoins d’une entreprise en matière de gestion des clés publiques. D’un
point de vue technique, nous avons fait la preuve qu’il est possible de mettre en œuvre,
à très peu de frais, une ICP entièrement constituée de composantes en logiciel libre.
Les enjeux entourant l’ICP sont principalement liés à son exploitation. Le développement
et la maintenance des politiques et des procédures d’exploitation de l’ICP nécessitent
différents domaines d’expertise. L’ICP agissant à titre de tiers de confiance a certaines
responsabilités envers ses abonnés et utilisateurs. L’exploitation d’une ICP n’est donc
tout simplement pas à la portée de toutes les entreprises.
La mise en œuvre et l’exploitation d’une ICP interne ne permettent cependant pas de
répondre à tous les besoins de l’entreprise en matière de certificats. Le modèle de
confiance Web basé sur une liste de confiance exige que le certificat racine d’une
autorité de certification soit installé à même le fureteur du client pour que ce dernier
puisse se connecter, sans avertissement de sécurité, à un serveur détenant un certificat
ayant été émis par cette autorité. Or, seuls les certificats racines d’autorités de
certification reconnues sont éligibles à être distribués avec les fureteurs Web. Très peu
d’entreprises ont la volonté ainsi que la capacité de se soumettre à une telle certification,
ainsi que de faire des démarches auprès des éditeurs de fureteurs Web pour que leur
certificat racine soit distribué avec ceux-ci. L’exploitation d’une ICP interne ne permet
donc pas de générer des certificats destinés aux serveurs Web sécurisés accessibles au
grand public.
Page 91 sur 96
À la lumière des faits recueillis dans le cadre de ce projet de recherche ainsi que des
résultats obtenus lors des diverses expérimentations, il fut possible d’émettre un
ensemble de recommandations adressant spécifiquement les besoins des EESS. Parmi
ces recommandations nous pouvons citer :
• Bénéficier des avantages du « cloud computing » en offrant le « PKI as a
service ». Mettre en œuvre une ICP communautaire, entièrement constituée de
produits en logiciel libre. Cette ICP permettra aux EESS de gérer elles-mêmes
leurs certificats à clé publique de manière centralisée, via l’internet;
• Utiliser un modèle de confiance hiérarchique simple;
• Définir les politiques de l’ICP dès le départ, sans procéder à une certification
externe. Ceci pourra toutefois être réalisé dans le futur si jamais le besoin en
était justifié;
• Acquérir les certificats SSL des serveurs Web sécurisés accessibles au grand
public auprès d’une autorité de certification commerciale reconnue;
• Utiliser les algorithmes cryptographiques RSA (2048 bits), Diffie-Helleman et
SHA-1, afin de garantir un niveau robustesse adéquat, ainsi qu’un niveau
d’interopérabilité optimal;
• Stocker la clé privée (de signature) des AC à l’intérieur d’un module de sécurité
matériel (HSM) répondant minimalement aux exigences de la norme FIPS 140-2
niveau 3;
L’application de ces recommandations offrira aux EESS l’opportunité de réduire les
coûts d’acquisition de certificats, ainsi que leur niveau de dépendance envers les
autorités de certification commerciales. Cette stratégie repose sur la centralisation de
l’expertise et des installations, ainsi que sur le partage des coûts de mise en œuvre et
d’exploitation de la solution. En prime, les EESS s’engageront sur une voie plus verte,
car le concept de « cloud computing » permettra de réduire la consommation d’énergie
ainsi que du nombre de serveurs physiques requis, limitant ainsi les effets négatifs de
leurs activités sur l’environnement.
Page 92 sur 96
Bibliographie
Livres
[ADAMS03] Adams, C., & Lloyd, S. (2003). Understanding PKI : Concepts, Standards, and
nd
Deployment Considerations (2 Edition)
Boston, MA : Pearson Education inc.
[HOUSL01] Housley, R., Polk, T., (2001). Planning for PKI – Best Practices Guide for
Deploying Public Key Infrastructure.
New York, NY : John Wiley & Sons inc.
Articles
[WHITF76] WHITFIELD, Diffie et MARTIN E. Hellman

New Directions in Cryptography
IEEE Transactions on information theory, VOL. IT-22, NO. 6,
November 1976
Normes et standards
[FIPS180] FIPS PUB 180-3 - Secure Hash Standard (SHS)

Octobre 2008
[ISO15408] ISO/IEC 15408 Technologies d’e l'information – Techniques de sécurité –
Critères d'évaluation pour la sécurité TI
2009
[ISO27002] ISO/IEC 27002 Technologies de l'information – Code de pratique pour le
management de la sécurité de l’information
2005
[ISO9594] ISO/IEC 9594-8 X.509 ITU-T Recommendation X.509 | ISO/IEC 9594-8
Information Technology – Open Systems Interconnection – The
Directory: Public Key and Attribute Certificate Frameworks.
2005
[PKCS01] PKCS #1 - RSA Encryption Standard.
RSA Laboratories
Juin 2002
[PKCS03] PKCS #3 - Diffie-Hellman Key-Agreement Standard.
RSA Laboratories
Novembre 1993
[PKCS07] PKCS #7 - Cryptographic Message Syntax Standard.
RSA Laboratories
Novembre 1993
[PKCS10] PKCS #10 - Certification Request Syntax Standard.
RSA Laboratories,
Mai 2000
[PKCS11] PKCS #11 - Cryptographic Token Interface Standard.
Page 93 sur 96
RSA Laboratories.
Avril 2009
[PKCS12] PKCS #12 - Personal Information Exchange Syntax Standard.
RSA Laboratories.
Juin 1999
[RFC2560] RFC 2560 - X.509 Internet Public Key Infrastructure Online Certificate Status
Protocol - OCSP.
Juin 1999
[RFC3161] RFC 3161 - Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP).
Août 2001
[RFC3647] RFC 3647 - Internet X.509 Public Key Infrastructure Certificate Policy and
Certification Practices Framework.
Novembre 2003.
[RFC3851] RFC 3851 - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1
Message Specification.
Juillet 2004
[RFC4210] RFC 4210 - Internet X.509 Public Key Infrastructure Certificate Management
Protocol (CMP).
Septembre 2005
[RFC4211] RFC 4211 - Internet X.509 Public Key Infrastructure Certificate Request
Septembre 2005
[RFC4510] RFC 4211 - Lightweight Directory Access Protocol (LDAP): Technical
Specification Road Map
Juin 2006
[RFC4514] RFC 4514- Lightweight Directory Access Protocol (LDAP): String Representation
of Distinguished Names
Juin 2006
[RFC5280] RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile.
Mai 2008
[SP800107] NIST SP 800-107 - Recommendation for Applications Using Approved Hash
Algorithms
Février 2009
[SP80021] NIST SP 800-21 - Guideline for Implementing Cryptography In the Federal
Government
Décembre 2005
[SP800571] NIST SP 800-57 - Recommendation for Key Management – Part 1 : General
Mars 2007
[SP800573] NIST SP 800-57 - Recommendation for Key Management – Part 3: Application-
Specific Key Management Guidance
Décembre 2009
Page 94 sur 96
Sites Web
[AI2L] http://ai2l.org/
Association Internationale du Logiciel Libre pour l'Économie Sociale.
Page d’accueil.
[ANSIX9] http://www.x9.org
Page d’accueil du comité ANSI X9
[CHAIRE] http://www.chaire-logiciel-libre.uqam.ca
Chaire de logiciel libre – Finance sociale et solidaire. Page d’accueil.
[COPPO09] http://www.chaire-logiciel-libre.uqam.ca/IMG/pdf/CloudComputing.pdf
Cloud Computing for Social Economy SMEs – Deploying Open Source Social
and Solidarity Financial Services Applications, Grace Coppola, Dec. 2009
[EJBCA] http://www.ejbca.org
Page d’accueil du projet.
[EJBCAFU] http://www.ossir.org/sur/supports/2008/Presentation-EJBCA-FR_1.1.pdf
EJBCA : Le futur de la PKI
[ENTMNG] http://download.entrust.com/resources/download.cfm/23676/Entrust-Managed-
Services-
Entrust. 3 elements that comprise a high quality PKI … and how you can get it
for less.
[ENTPKI01] http://download.entrust.com/resources/download.cfm/21720/Entrust_and_you_
new_version.pdf/?start
Introduction to Entrust PKI
[ENTTCO] http://download.entrust.com/resources/download.cfm/23826/Entrust-Managed-
Services-PKI_TCO.pdf/?
Entrust. Why outsourcing your PKI provides the best value. A Total Cost of
Ownership analysis
[HETUM09] http://www.chaire-logiciel-
libre.uqam.ca/IMG/pdf/Cartographie_securite_logiciel_libre.pdf
Cartographie des solutions de sécurité dans le monde du logiciel libre,
Michel Hétu, Dec. 2009
[ISOJTC1] http://www.iso.org/iso/fr/standards_development/technical_committees/list_of_i
so_technical_committees/iso_technical_committee.htm?commid=45020
Page du groupe technique ISO JTC 1
[ISOTC68] http://www.iso.org/iso/fr/standards_development/technical_committees/list_of_i
so_technical_committees/iso_technical_committee.htm?commid=49670
Page du groupe technique ISO TC 68 SC 2
[ITUT] http://www.itu.int/ITU-T/index-fr.html
Page d’accueil du groupe ITU-T
[NETASSI] http://www.apprendre-en-ligne.net/crypto/bibliotheque/PDF/IntroToCrypto.pdf
Introduction à la cryptographie
Network Associates, Inc.
[NISTCSD] http://csrc.nist.gov/index.html
NIST Computer Security Division
[NSS2002] http://nsslabs.com/test-reports/NSS-PKI-ED5.pdf
Public Key Infrastructure – Group Test (Edition 5)
The NSS Group, 2002
Page 95 sur 96
[OPENTR] http://www.opentrust.com/index.php?option=com_content&view=article&id=85
&Itemid=87&lang=fr
OpenTrust PKI
[PKIX] http://www.ietf.org/dyn/wg/charter/pkix-charter.html
Page d’accueil du groupe de travail PKIX (Public-Key Infrastructure X.509)
[PRIMEKEY] http://www.primekey.se/Products/EJBCA+PKI
PrimeKey EJBCA PKI
[RSALABS] http://www.rsa.com/rsalabs/node.asp?id=2124
RSA Laboratories – Standards PKCS.
[WIKISHA] http://en.wikipedia.org/wiki/SHA_hash_functions
Wikipedia. SHA hash functions
[XKMS] http://www.w3.org/TR/xkms/
W3C, XML Key Management Specification (XKMS)
Page 96 sur 96

EESS - Gestion Des Cles Publiques

Transféré par

Droits d'auteur :

Formats disponibles

EESS - Gestion Des Cles Publiques

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

EESS - Gestion Des Cles Publiques

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSITÉ DU QUÉBEC À MONTRÉAL

GESTION DES CLÉS PUBLIQUES

Table des matières

Table des matières..............................................................................................3

Liste des figures .................................................................................................5

Liste des tableaux...............................................................................................6

Sigles et abréviations .........................................................................................8

3 Gestion des clés publiques ................................................................... 14

4 Les solutions d’ICP................................................................................. 50

5.1 « PKI as a Service » ............................................................................................ 65

Liste des figures

Figure 1 - Chiffrement d'un message. Source [NETASSI] ...................................................... 15

Figure 33 - Configurations logicielles client et serveur............................................................. 80

Liste des tableaux

Table 1 - Algorithmes asymétriques............................................................................................. 18

Table 19 - Liste des composantes logicielles requises............................................................ 67

PEM Privacy Enhanced Mail

1.3 Structure du document

3 Gestion des clés publiques

3.1.1 Mécanismes cryptographiques

Figure 1 - Chiffrement d'un message. Source [NETASSI]

3.1.1.2 La fonction de hachage

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

3.1.1.3 La signature numérique

Clé privée utilisée

Figure 3 - Signature d'un message. Source [NETASSI]

3.1.2 Les familles d’algorithmes cryptographiques

3.1.2.1 Les algorithmes symétriques (à clé secrète)

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

3.1.2.2 Les algorithmes asymétriques (à clé publique)

Contrairement au mécanisme cryptographique traditionnel à clé secrète, où la même clé

Clé publique Clé privée

Figure 5 - Chiffrement à l’aide de la cryptographie asymétrique. Source [NETASSI]

Algorithme Chiffrement Signature Échange de

3.2 Normes et standards

Source Ref. Description

3.2.1 IETF PKIX

Fondé en 1995, le groupe de travail PKIX (Public-Key Infrastructure X.509) de l’IETF

3.2.2 RSA PKCS

• PKCS #1 - RSA Encryption Standard. Recommandations concernant

• PKCS #3 - Diffie-Hellman Key-Agreement Standard. Ce standard décrit une

• PKCS #7 - Cryptographic Message Syntax Standard. Ce standard décrit une

• PKCS #10 - Certification Request Syntax Standard. Ce standard décrit le

• PKCS #11 - Cryptographic Token Interface Standard. Ce standard définit une

• PKCS #12 - Personal Information Exchange Syntax Standard. Ce standard

3.2.3 ISO TC 68/SC 2

Fondé en 1948, le comité technique TC 68/SC 2 - Gestion de la sécurité et opérations

• ISO 21188:2006 - Infrastructure de clé publique pour services financiers -

3.2.4 ISO JTC 1

Fondé en 1987, le comité technique JCT 1 – Technologies de l’information de

Bien qu’il soit principalement destiné à satisfaire les exigences spécifiques de la

Le groupe ITU-T (Telecommunication Standardization Sector) a pour rôle d’établir les

o SP800-57 - Recommendation for Key Management. Guide pratique en

3.3 L’infrastructure à clé publique (ICP)

Figure 6 - Vue globale de l'ICP. Traduction de [ENTPKI01]

3.3.1 Les composantes de l’ICP