Rapport Projet Transversal
Rapport Projet Transversal
Rapport Projet Transversal
Problématique
Etant donné l’accroissement du nombre d’infiltrations et transgressions informatiques, le
niveau de sécurité reposant sur l’authentification par login et mot de passe s’avère être
dépassé, voire même primitif. C’est pour cette raison qu’il faut chercher un autre moyen de
sécurisation de données, notamment quand il s’agit de transactions bancaires ou d’échanges
de données secrètes. Le risque doit être maintenu à zéro.
Solution demandée
Le travail demandé consiste à mettre en place une solution PKI open source EJBCA pour la
génération de certificats en ligne avec un service de publication de ces certificats.
Cette solution portera sur l’étude des infrastructures cryptographiques pour pouvoir choisir
une implémentation qui nous aidera à générer des certificats électroniques puis de les publier
dans un annuaire électronique.
La famille des PKI renferme une multitude de modèles. Dans notre cas, on s’intéresse
particulièrement aux PKI open source EJBCA, celles dont le développement, l’amélioration et
l’acquisition sont ouvertes au grand public.
2. Présentation de EJBCA
EJBCA est une PKI sous licence Open Source (LGPL) développée en Java/J2EE. Elle permet
d’implémenter et concevoir une solution PKI de plusieurs façons, allant du simple et du faible
coût au très complexe et coûteux. EJBCA permet de mettre en œuvre pratiquement n'importe
quel type d'architecture PKI. Chaque composant peut être déployé de manière autonome ou
intégrée dans EJBCA.
Architecture Fonctionnelle
La figure 8 nous servira d’appui pour l’énumération des composants de EJBCA [1].
Figure 1 : Schéma de EJBCA
Composants optionnels
L’interface publique se compte pour un composant optionnel en EJBCA car l’utilisateur peut
consulter les fonctionnalités de son OS et trouver un moyen de récupérer son certificat
Architecture Applicative
Elle fournit les interfaces aux clients et administrateurs pour les appels vers l’autorité de
Certification ou vers l’autorité d’enregistrement.
Une couche applicative
Elle englobe les fonctions métiers de la PKI, elle comprend les éléments suivants :
Les fonctions d’authentification, de gestion de vie des certificats, de journalisation, de
publication
Et de paramétrages de la PKI En complément, elle fournit un gestionnaire de clefs (séquestre
et recouvrement)
Une couche de données :
Qui permet de stocker l’ensemble des données de la PKI dans une base de données
Il possible de connecter un ou plusieurs un annuaire LDAP pour lui adresser les données
publiques de la PKI (utilisateurs, certificats, CRL, etc.)
Architecture Logique
EJBCA est une autorité de certification très populaire et l’une des plus privilégiées
actuellement [2]. Parmi ses caractéristiques de base on note la variété de choix de :
- L’algorithme qui s’étend de SHA-1 avec RSA jusqu’à SHA-256 avec RSA
- Le taille de la clé allant de 1024, 2048 jusqu’à 4096 bits.
- La langue lors de la configuration du système
- L’annuaire de publication (publisher) comme LDAP
- L’Active Directory (AD) et le choix du type du publisher connector (connecteur de
l’éditeur)
- La clef de signature qui peut être soft/hard
Outre ces traits saillants fournis ;
- EJBCA délivre des certificats conformes à la norme X.509 et offre la possibilité
d’intégrer le certificat dans les cartes à puce.
- EJBCA est indépendant des systèmes d’exploitation, des bases de données ou des
serveurs applicatifs
- EJBCA fonctionne sur la plupart des systèmes d’exploitation : Unix, GNU/Linux,
FreeBSD, Solaris, Windows.
- EJBCA utilise un serveur d’application et est compatible avec les grands produits du
marché tels que : Jboss, JonAS, GlassFish, OC4J, WebLogic, WebSphere
- EJBCA est compatible avec les bases de données supportées par les serveurs
d’applications, c’est à dire : MySQL, PostgreSQL, Oracle, DB2, MS-SQL,
Hypersoniq, Derby, Sybase, Informix, Ingres
3. Implémentation de EJBCA et réalisation
On a déployé une PKI complète dans une seule instance. Étant donné que EJBCA a tout intégré, vous
pouvez avoir une seule instance fonctionnante à la fois en tant que CA et RA. Il s'agit d'une solution
très efficace, facile à gérer et économique qui convient à de nombreux déploiements des entreprises.
1. Installation de EJBCA
Dans cette partie on va entamer la phase d’installations des paquetages et des modules
logiciels nécessaires au déploiement de notre PKI. Ensuite, on fera une série de configurations
afin d’adapter l’environnement logiciel à l’environnement matériel.
Environnement matériel
Environnement logiciel
Modules complémentaires
Environnement matériel
Environnement logiciel
Après avoir affecté à chaque variable le chemin correct qui lui convient en configurant le
fichier « profile » se situant sous /etc, on vérifie si ces variables sont bel et bien correctes.
APPSRV_HOME= /opt/jboss
JAVA_HOME =/opt/java
EJBCA_HOME= /opt/ejbca
ANT_HOME=/opt/ant
Afin de permettre à EJBCA d’enregistrer ses données nous créerons une base de données
MYSQL. Cette base de données permettra à l’utilisateur d’EJBCA de bénéficier des
permissions nécessaires pour l’ajout la suppression et la mise à jour des données de la base.
Pour ce faire, nous suivrons ces étapes là en introduisant pour chacune la/les commandes
adéquates :
Tout d’abord, nous créons la base de données et nous l’appelons ejbca, nous créons
avec un administrateur adminmysql et nous lui affectons un mot de passe.
Nous créons ensuite un utilisateur pour la base de données et nous lui accordons tous
les privilèges sur ejbca
Nous faisons une série de tests en ligne de commandes pour nous assurer que la
création de l’utilisateur a réussi.
Si la série de tests se termine avec succès, alors la base de données est fonctionnelle et
l’utilisateur créé dispose de tous ses droits légitimes. En effet l’installation via des
commandes linux est très délicate, c’est pour cette raison qu’il faut entamer des tests.
Configurations sur EJBCA
EJBCA maintient ses configurations statiques sous le répertoire conf. Le répertoire comprend
divers fichiers de configuration (enregistrés sous *.properties.sample), qui doivent être
renommés en *.properties pour devenir actifs. Ces fichiers sont nécessaires pour effectuer les
initialisations et les personnalisations désirées lors du processus d’installation.
Nous allons donc effectuer une série de configuration sur quelques fichiers dont notamment :
ejbca.properties, database.properties, web.properties, install.properties et le fichier ayant pour
emplacement /etc/profile contenant les variables d’environnement.
A ce stage de l’implémentation, nous installons le package EJBCA et nous accordons tous les
droits de propriétés à l’utilisateur système de EJBCA qui s’intitule ejbca lui également.
Ensuite nous nous plaçons sous le répertoire /opt/ejbca/conf, là où se situe le fichier de
configuration ejbca.properties.
Le fichier ejbca.properties est celui qui nous permettra de fixer quelques paramètres
nécessaires pour l’installation de EJBCA server.
Configuration du fichier database.properties
Sur ce fichier, nous fixerons le type de la base de données ainsi que le mapping effectué, son
url, son driver et l’administrateur qui lui sera affecté comme suit :
Database.name=mysql
Datasource.mapping=mySQL
Database.url=jdbc :mysql: //127.0.0.1:3306/ejbca
Database.driver=com.mysql.jdbc.Driver
Database.username=ejbca
Database.password=*****
Dans ce contexte, nous configurerons ce fichier dans la mesure de spécifier des mots de passe
pour le super administrateur de EJBCA qui sera utilisé ultérieurement lorsque le super
administrateur devra importer son accréditation auprès de son navigateur web, du Key-store
(CryptoToken) contenant les certificats p12 de l’administrateur, un mot de passe pour
sécuriser l’accès depuis http server et un DNS hostname. La configuration est la suivante :
Superadmin.password=********
Httpserver.password=********
Httpserver.hostname=localhost
Finalisation de l’installation
Après avoir configuré tous les fichiers nécessaires, nous faisons appel à ANT avec la
commande appropriée qui finalisera le boostrap (installation) de EJBCA. Si cette étape est
franchie avec succès, nous lançons alors notre serveur d’application JBoss puis nous vérifions
le peuplement de notre base de données avec les tables systèmes nécessaires, se comptant au
nombre de 3 6qui assurerons à l’utilisateur une supervision totale de la base.
Fig. Les tables de la base de données
Maintenant que nous nous sommes assurés du bon fonctionnement de JBoss et la création des
tables de la base de données, nous pouvons enfin créer concrètement notre première CA
(Management CA) et notre super administrateur.
Pour ce faire, nous avons recours à ‘ant install’, qui lancera sur la console le déploiement du
fichier server.log . Nous nous assurons de la non existence d’erreurs et enfin nous déployons
EJBCA avec ‘ant deploy’ tout en revérifiant au fur et à mesure le bon fonctionnement de
JBoss et de mysql.
Cette étape de finalisation est très délicate car elle renferme une kyrielle de tests successifs et
répétitifs pour s’assurer qu’aucune erreur n’advienne.
Il ne reste plus qu’à vérifier la disponibilité des ports 8080, 8442 et 8443 pour pouvoir lancer
l’URL de ejbca [ https://127.0.0.1 :8443/ejbca/index.jsp ] sur le navigateur et d’y ajouter le
certificat SuperAdmin.p12.
Tout ceci nous mène à avoir enfin notre interface publique de EJBCA là où les certificats
peuvent être récupérés, qui est illustrée par la figure 10. Et bien évidement, une interface
administration illustrée par la figure 11
Figure 1 : Page publique de EJBCA
EJBCA est maintenant installée et correctement configurée. Elle est gérée par un super
administrateur qui détient tous les supers pouvoir sur cette PKI. Il ne manque plus que
l’élaboration du squelette de la PKI en définissant le AC racine et les AC subordonnées
descendantes de l’AC racine. Dès lors, la procédure de certification se clarifiera et le scénario
du se fera moins flou.
Acteurs de la PKI
La PKI peut être utilisée par deux types d’acteurs : ceux qui voient la médaille et ceux qui
voient le revers de la médaille.
La médaille réfère à la partie visible de la PKI, celle qui peut être consultée publiquement et
elle est modélisée par des pages web publiques que les utilisateurs peuvent consulter.
Le revers de la médaille quant à lui, réfère à la partie secrète et cachée de la PKI et qui n’est
visible que par les utilisateurs à droits administratifs. Cette partie est modélisée par des pages
web administratives comportant les tâches d’administrateurs.
Le super administrateur : C’est à lui et à lui seul que revient le pouvoir et le choix de
tout faire au sujet de la PKI
Le client final : Consulte les pages web pour pouvoir récupérer son certificat ou
bénéficier d’autres services destinés aux utilisateurs.
L’utilisateur final : Il accède aux pages publiques et récupère son certificat après s’être
authentifié, qu’il soit une personne ou un serveur.
Etant donné que notre EJBCA visera particulièrement les personnes et les serveurs, nos
certificats finaux seront paramétrés de la sorte, ainsi que notre stratégie d’hiérarchisation des
CA.
Sur ce, nous avons opté pour une stratégie de partage qui vise à créer deux CA subordonnées
directement liées à notre CA racine qu’on va la créer par la suite. Ces deux CA seront
logiquement signés par la CA racine qui est “SupCom Root CA” et hérite par suite ces
certificats.
Étant donné que les conséquences d'une autorité de certification racine compromise sont si
grandes (jusqu'à et y compris la nécessité de réémettre chaque certificat de la PKI), toutes les
autorités de certification racine doivent être protégées contre tout accès non autorisé. Une
méthode courante pour garantir la sécurité et l'intégrité d'une autorité de certification racine
consiste à la maintenir hors ligne. Une autorité de certification racine hors ligne est une
autorité de certification qui a été isolée de l'accès au réseau et est souvent maintenue dans un
état hors tension. Il n'est mis en ligne que lorsque cela est nécessaire pour des tâches
spécifiques et peu fréquentes, généralement limitées à l'émission ou à la réémission de
certificats autorisant les autorités de certification intermédiaires ou subordonnées.
EJBCA nous permet de mettre le CA racine en mode hors ligne une fois qu’on a terminé la
création et la signature des deux CA subordonnées.
La première est une CA destinée pour générer des certificats personnels d’où son nom
significatif « SupPersonnel Issuing CA » et la deuxième, naturellement, sera dédiée à la
génération de certificats serveurs et elle est nommée « SupServer Issuing CA».
Après avoir élaboré le croquis de notre PKI et défini les paliers de notre architecture, plus
aucune contrainte ne se présente. On procède donc à la définition de nos entités finales qui
réfèrent aux utilisateurs finaux de notre PKI. Si l’utilisateur est une personne, elle sera liée à
« SupPersonnel Issuing CA » sinon elle sera liée à « SupServer Issuing CA» dans le cas où
c’est un serveur.
Pour pouvoir disposer d’un certificat valide et fonctionnel, l’utilisateur devra suivre cet
itinéraire de certification
Il est à noter que notre PKI est à fortiori présenté au marché tunisien. C’est pour cette
raison que la demande d’obtention de certificat doit être manuelle car il en faut des
connaissances et de la conscience techniques pour pouvoir en premier lieu assimiler
l’utilité de la signature et de la certification électroniques, et en deuxième lieu le
moyen d’y parvenir. Une demande manuscrite, s’avère être donc le moyen le plus
simple et facile à comprendre en l’occurrence ; surtout que certaines entreprises
désirant bénéficier d’un certificat, envoi leurs agents commerciaux qui dans la plupart
des cas ne comprennent pas la notion intrinsèque de certification.
La création des profils de certificats est l’étape sans laquelle nous ne pouvons pas créer des
CA subordonnées. Ce profil est une référence irrévocable dans l’identité de la SubCA.
Ce qui fait l’importance et tout le poids du profil de certificat est le taux d’informations
basiques et très importantes qu’il renferme.
En effet, il spécifie :
La création des SubCA est une étape ultérieure à la création du profil de certificat de chacune.
Le certificat de SubCA généré renferme donc toutes les données saisies lors de la création du
profil de certificat mais toutes ces données apparaissent en des champs statiques qui ne sont
plus aptes à être modifiés ainsi que le profil de certificat que nous avons eu à l’appui (voir
annexe 4).
Outre ces informations-là, le certificat contient aussi 3 champs concernant la CRL. Le premier
détermine la périodicité de publication de la CRL qui est d’une CRL par jour, le deuxième
détermine la date butoir de validité de la CRL qui est de 1 jour et le troisième fixe le temps de
chevauchement entre la CRL émise et la CRL en cours d’expiration qui est de 30 minutes.
Ceci dit, 30 minutes avant que la CRL expire, une autre est republiée le même jour. Du coup,
nous gardons une continuité des mises à jour et nous ne risquons pas l’indisponibilité de la
CRL. Sans oublier le champ Subject DN de la SubCA.
La figure 13 représente le certificat de la Sub CA SupPersonnel Issuing CA.
La génération de end entity certificate profile qui correspond au certificate profile associé côté
personne ou serveur. Cette étape nous permet de désigner la vocation des certificats finaux qui
seront issus en définissant ce qu’on appelle le « key usage » et le « Extended Key usage » ou
bien l’usage de la clef et l’usage avancé de la clef car chaque certificat émis est destiné à un
usage spécifique.
Taille de la ci clef = 2048 bits ( elle est estimée largement suffisante pour un certificat final)
Validité= 730 jours (le certificat utilisateur est généralement valide pour 2 ans)
Le tableau 3 illustre nos choix d’usage pour les certificats Personne et Serveur :
Tableau 3: L'usage de la clef et l'usage avancé de la clef pour les Personnes et Serveurs
Client Serveur
Signature électronique Signature électronique
Nous avons dans notre politique hiérarchique bien structurée de génération de certificat selon
des règles bien étudiées. Nous en sommes à la génération de end entity profile qui sont une
sorte de modèle qui précède la génération des certificats finaux. Ce modèle est en revanche
optionnel mais nous avons choisi de l’adopter car il nous donne le choix d’ajouter tous les
champs dont nous avons besoins dans la phase finale de génération de certificats finaux. Il
suffira juste de remplir le formulaire là où les champs sont vides.
La phase de génération des entités finales n’est que la phase de génération de certificats pour
des utilisateurs finaux. Cette étape se réduit à l’insertion des données personnelles du
demandeur de certificat et au choix du format du certificat à savoir, PEM ou P12. Nous avons
choisi l’extension .p12 car le format PKCS#12 est une sorte de format texte qui stocke les
clefs privées et les certificats dans un seul fichier chiffré.
Le format PEM quant à lui, il contient deux fichiers distincts, l’un pour stocker la clef privée
et l’autre pour la clef publique.
Renouvellement de certificat
Le certificat émis peut être sujet au renouvellement si pour quelconque cause il expire. Bien
que le client dispose du droit de s’offrir un nouveau certificat, il peut néanmoins demander le
renouvellement de son certificat. Notre PKI respecte ce choix éventuel de la clientèle et va
jusqu’au bout de leurs caprices. En effet EJBCA a prévu une solution de renouvellement de
certificat qui respecte les auspices de sécurité fomentés au préalable.
La validité temporelle d’un certificat représente la date au-delà de laquelle le certificat n’est
plus valide. Ceci n’empêche pas le fait que certains certificats peuvent devenir non valides
sous certaines circonstances. Dans ce cas, la CA doit révoquer le certificat dans une liste
horodatée dite CRL et la publier sur LDAP.
La figure nous montre comment récupérer une CRL à partir des pages d’administration sous
la rubrique CA Structure & CRRs for CA :
De ce fait, lorsque nous voulons utiliser un certificat, notre système vérifie sa signature et sa
validité en allant chercher l’existence de son numéro de série dans la CRL la plus récente. Si
le numéro de série existe dans la CRL, le certificat est alors révoqué sinon, il est valide.
Les CRL sont régulièrement mises à jour en vue de garantir une meilleure précision des
résultats de recherches et d’actualiser les modifications survenues.
Déploiement de EJBCA