la confiance et la sécurité

LA CONFIANCE ET LA SÉCURITÉ
IGC INFRASTRUCTURE DE GESTION DE CLEFS ET
TPC TIERS PARTIE DE CONFIANCE
Par Jean Pierre Cabanel
Professeur à l'Institut National Polytechnique
(ENSEEIHT) de Toulouse et
membre du laboratoire IRIT
(Institut de Recherche en Informatique de Toulouse)
LA CONFIANCE ET LA NOTION D’IGC
La notion de confiance est fondamentale dans le cadre de la sécurité informatique, c’est aussi un concept
très difficile à quantifier, et elle est éphémère au sens ou les systèmes de sécurité possèdent une durée de
vie bornée.
Un des exemples, ou la notion de confiance devrait jouer un rôle important concerne l’environnement de la
génération des moyens de signatures et de chiffrement
Une IGC est un système dont la fonction principale est de délivrer des moyens de signatures : Biclefs
de chiffrement asymétrique (RSA ou ECC) et un certificat signé par une autorité de certification (AC).
Pour réaliser cette fonction vis-à-vis de tiers, il faut présenter un certain de niveau de confiance, une carte
d’identité possède une valeur par la signature de l’entité de confiance qui est la préfecture, dans le cadre
des moyens de signature ou de chiffrement nous avons une problématique identique.
Ces deux notions sont donc liées et la réalité de l’une est attachée au niveau de confiance de l’autre.
INTRODUCTION À LA NOTION D’IGC
Une IGC type offre les services de base suivants :

Un système IGC permet de générer des certificats qualifiés X509v3 en RSA ou ECC utilisés pour les
signatures électroniques des personnes ou des serveurs et/ou des moyens de cryptologie pour une
utilisation dans un cadre intranet et/ou extranet et ou Internet

Un Annuaire LDAP d’entreprise ou d’administration, centralisé ou distribué géographiquement

Un Agenda/LDAP accessible par les utilisateurs qui possèdent un certificat signé par l’AC : autorité
de certification de référence, et qui peuvent télécharger les certificats d’autrui pour réaliser un
chiffrement asymétrique, ou connaître l’adresse mail d’un autre utilisateur. L’accès à l’Agenda/LDAP
est réalisé à travers la dichotomie choisie par l’administrateur du système IGC/LDAP.

Une description détaillée des pratiques de certification, véritable règle de fonctionnement (horloge,
distribution des certificats, révocation, renouvellement etc.)
Une unité de système peut être composée des entités suivantes :

Une machine (Signer) centrale dont la fonction principale est la signature des certificats (signature
de l’AC) : Autorité de Certification) avec son propre biclef.

Une machine (Accès) centrale qui permet l’interface avec les utilisateurs, gère la fonction d’agenda
(LDAP) et intègre l’interface pour les Autorités d’Enregistrement (AE).
Un livre blanc
1/6

Les postes des Autorités d’Enregistrement (AE), qui permettent d’enregistrer l’authentification des
utilisateurs désirant des moyens de signature sur l’ IGC central et de révoquer des utilisateurs déjà
enregistrés.

Les bornes (BO) qui permettent de télécharger un moyen de signature dans la carte à puce de
l’utilisateur, dans le cadre des AE.

Un système de sauvegarde permettant de sauvegarder la machine « Accès » et son LDAP
PKI/LDAP
central
Administrateur
Archivage
Serveur
Access
Serveur
Signer
Une entité
décentralisée
A
E
Autorité
d’enregistrement
Borne de
chargement
de cartes à puce
Exemple d’architecture d’une IGC
Les utilisateurs n’accèdent pas directement au Serveur Signer, ils déposent leurs requêtes dans le
Serveur Accès, et le Serveur Signer vient les chercher.
Ceci permet d’améliorer la protection de la clef privée de L’AC : autorité de certification, en effet, la
gestion de la communication entre « Signer » et « Accès » et La machine « Signer » qui ne possède pas
de Système d’exploitation sont des développements spécifiques. La clef privée de l’AC est contenue dans
une carte à puce accédée par le logiciel de « Signer » .Il est fondamental de protéger au mieux la clef
privée de l’AC, elle représente la clef de voute de tout le système.
En effet imaginons que le biclef de l’AC soit connue, alors de vrais faux certificats peuvent être générés, si
le biclefs de l’AC est détruit, alors tout les certificats générés ne sont plus utilisables, car la signature de
l’AC contenu dans les certificats n’est plus vérifiable.
De même, si le biclefs de l’AC n’est pas intègre, cela veut dire que d’autres personnes peuvent
reconstruire un biclefs identique.
La confiance dans la signature électronique d’une personne qui possède un certificat
Signé par une AC, dont le biclefs est corrompue (vol, destruction) est alors prise en défaut, ceci explique
l’importance de la protection du biclefs de l’AC.
Les moyens de signature comprennent un biclefs et un certificat, ils servent à signer des documents, à
s’authentifier, à gérer des droits d’accès, à transporter une clef de chiffrement symétrique ou être utilisés
dans le cadre de protocole de type Diffie-Hellman.
SCHÉMA DE FONCTIONNEMENT D’UNE IGC
CAS GÉNÉRAL DE GÉNÉRATION DE MOYENS DE SIGNATURE
Après initialisation du IGC/LDAP central : création dynamique de la dichotomie de classement des
différents utilisateurs (usine, département, base, escadron etc.) et définition des types de droits d’accès
délivrables à ces derniers, les étapes de génération des moyens de signature sont les suivantes :

Authentification forte de l’utilisateur par une AE suivant les « Procédures de certification »
utilisées : contact visuel, documents d’identification, etc. ou authentification faible en demandant
Un livre blanc
2/6
juste une adresse e-mail pour recevoir le certificat, la signature ne garantissant du coup que
l'adresse e-mail.

Connexion en mode sécurisé et avec authentification de l’AE concernée au site du système
IGC/LDAP central (à la machine Accès). Durant cette connexion l’AE va autoriser l’utilisateur à
réaliser une demande de moyen de signature.
Pour cela l’AE édite l’ensemble des informations relatives à l’utilisateur qui seront soit contenues
dans son certificat ou qui seront mémorisées de manière confidentielle, (journalisation et fiche
personnelle).
L’identité de l’AE est mémorisée et la requête de l’AE est sauvegardée sur le site central.

Dans le cadre d’une AE, et à partir d’une borne (BO), connexion en mode sécurisé et avec
authentification de l’utilisateur au site du IGC/LDAP central (à la machine Accès), afin d’obtenir
son moyen de signature dans sa carte à puce.
Après contrôle du système IGC/LDAP, les informations relatives à l’utilisateur et saisies par l’AE
sont alors présentées à l’utilisateur, après accord de ce dernier et acceptation des « Procédures de
certification » en cours,
Le biclefs : clef publique et clé privée, est généré dans la carte à puce du client, introduite dans la
borne
La clef publique, n’est pas confidentielle, elle peut et doit être distribuée aux correspondants, par contre la
clef privée est complètement confidentielle, elle est générée dans la carte à puce, elle n’est pas connue
de l’AC et elle ne doit en aucun cas être connue par un tiers.
Cette clef doit être changée au bout d’un certain temps pour des raisons de sécurité.
La requête utilisateur (signée) accompagnée de la clef publique générée est communiquée au site central.
Le système IGC/LDAP (machine Signer) va après contrôle, générer un certificat et le signer avec sa propre
clef privée (clef de l’AC), ce dernier est téléchargé sur la borne (BO) pour acceptation par l’utilisateur et
chargement dans sa carte à puce.
Après réussite du chargement de la carte à puce le IGC/LDAP mémorise le certificat généré dans le LDAP,
et édite les différents journaux (AE et machine Signer).
A la réception du certificat le système contrôle l’adéquation entre la clef privée de l’utilisateur restée dans
la carte à puce et la clef publique retournée avec la clef privée de l’utilisateur restée dans la carte à puce,
et qui n'en sortira jamais, et la clef publique retournée avec le certificat.
CAS DE RÉVOCATION DES MOYENS DE SIGNATURE
La révocation des moyens de signature d’un utilisateur peut être réalisée soit par l’AE qui a authentifié ce
dernier ou par l’administrateur central. Ces informations sont alors communiquées au LDAP central et les
« CRL » (liste de révocations) sont alors émises vers les différents sites applicatifs qui réalisent un
contrôle d’accès.
CAS DU RENOUVELLEMENT DES MOYENS DE SIGNATURE
Le renouvellement des moyens de signature est réalisé à partir des bornes (BO) chez les AE, la fréquence
de renouvellement peut être choisie par l’administrateur central, et le renouvellement est total : biclefs et
certificat.
INTRODUCTION AUX PROBLÈMES DE SÉCURITÉ DANS UNE IGC
LA PROTECTION DE LA CLEF PRIVÉE DE L’AC
Dans cet exemple, il y a séparation physique entre le processeur Signer qui contient les biclefs de l’AC et
le processeur Accès qui est accédé de l’extérieur de manière contrôlée
Les communications entre les deux processeurs sont toujours contrôlées par le processeur Signer, aucun
trafic ne peut être initialisé par Accès vers Signer.
Les communications entre les deux processeurs sont chiffrées et chaque échange est authentifié. Il existe
un seul port utilisable dans Accès, et le protocole est spécifique.
LA PROTECTION DU SERVEUR ACCÈS
Ce type d’IGC est utilisé en environnement fermé, dans lequel les nouveaux clients sont filtrés par les AE.

L’accès des AE est contrôlé par une authentification forte : carte à puce spécifique, identifiant
spécifique, certificat qualifié, signature de son certificat par l’AE avant de le présenter au serveur
Accès et chiffrement souhaité pour les communications.

L’accès des Bornes pour le renouvellement des certificats est contrôlé à partir d’une authentification
(certificat et signature du certificat). Dans le cas de la création initiale d’un certificat et du
chargement dans la carte à puce, l’accès est contrôlé par un ensemble de mécanismes. Les
Un livre blanc
3/6
communications entre une Borne et le serveur Accès sont chiffrées. Les Bornes sont aussi gérées
par les AE, cela améliore la sécurité mais rend plus lourd l’exploitation du système.
LES AUTORITÉS D’ENREGISTREMENT
Les AE communiquent avec le serveur Accès, afin de fournir au point central l’ensemble des informations
concernant l’utilisateur, ces dernières sont de trois types :
-
Les informations propres au certificat
-
Les informations relatives à l’identification de l’utilisateur
-
Les informations sur les droits d’accès (si utilisation)
Une AE est gérée par le serveur Accès, et elle utilise une carte à puce qualifiée AE, avec son identifiant.
Dans cet exemple, les fonctions de base d’une AE sont les suivantes :
-
Après identification d’un utilisateur, émission pour ce dernier d’un formulaire représentant une
requête certifiée de certificat au serveur Accès.
-
Révocation d’un utilisateur
-
Consultation du journal des AE qui présente les informations sur l’ensemble des certificats
demandés et générés.
Chaque certificat utilisateur contiendra l’identifiant de l’AE d’authentification.
L’accès des AE est contrôlé par une authentification : carte à puce (code PIN à 8 caractères) spécifique,
identifiant spécifique, certificat qualifié, signature de son certificat par l’AE (clef privée gardée en
mémoire) avant de le présenter au serveur Accès et chiffrement souhaité pour les communications.
Le serveur accès contrôle la signature de l’AC du certificat (intégrité du certificat), sa qualification AE, la
signature du certificat par l’AE (authentification du propriétaire) et son existence dans le LDAP (existence
non révoquée).
On peut en plus imaginer que
l’intégrité de l’authentification d’une AE pendant la durée de sa
communication avec le serveur Accès soit sauvegardée, par un mécanisme de référence dynamique, afin
d’éviter toute pénétration d’une communication après la phase d’authentification de l’AE par Accès.
L’introduction de virus et autre code malveillant peut se faire par l’intermédiaire des cartes à puces des
clients, dans les bornes ou en utilisation sur leurs PC en contrôlant les listes de révocations etc., dans ce
cas Accès et les AE sont infectés.
Signer et sauvegarder devraient pouvoir être épargnés.
NÉCESSITÉ D’UNE ADMINISTRATION ET D’UNE TRAÇABILITÉ DES OPÉRATIONS.
Il doit exister plusieurs journaux mémorisant l’ensemble des opérations et des informations :

Le journal des AE qui mémorise par AE, les opérations, l’état du certificat, et les informations
associées.

Le journal central qui compile l’ensemble des informations relatives aux AE, plus celles relatives à
l’administrateur du site.

La base des certificats qui mémorise uniquement les informations contenues dans les certificats et
leurs états.
Ces journaux et l’ensemble des deux systèmes Signer et Accès doivent être régulièrement sauvegardés et
archivés afin de pouvoir restaurer l’IGC dans le cas de panne ou de malveillance.
LES RÉVOCATIONS ET LES CRL
Les AE et l’administrateur central peuvent révoquer un certificat.
L’information de révocation est automatiquement mémorisée dans les différents journaux et l'annuaire
LDAP.
Le Signer génère alors une CRL et la signe, cette dernière peut être émise vers les administrations de
serveurs applicatifs, de mails ou vers les utilisateurs.
LA NOTION DE TPC : TIERCE PARTIE DE CONFIANCE
La loi du 26 juillet 1996, introduit la notion de TPC. Nous analysons les principales fonctions relatives à
l’utilisation d’une IGC générateur de moyens de signature ou de chiffrement.
Le certificat d’un utilisateur, ne possède de réalité que par la signature de L’AC, donc par sa clef privée.
Il apparaît alors un certains nombre de questions attachées à la fonction IGC :
Comment avoir confiance dans la clef privée de L’AC, ou comment avoir confiance dans une clef de
chiffrement fournie. Cela pose principalement plusieurs types de questions :
Un livre blanc
4/6

La première relève des potentialités que des intrus auraient de corrompre ou de connaitre la clef
de l’AC

La seconde traite de l’intégrité des hommes qui gèrent l’IGC

La troisième analyse les procédures humaines et techniques qui régissent le fonctionnement de
l’IGC et la consistance de la clef de l’AC
La notion de TPC propose d’organiser les solutions à ces questions.
La protection physique du site du TPC ainsi que sa protection vis-à-vis des accès réseaux, sont un des
premiers éléments à traiter dans la conception d’un TPC.
Sans s’étendre sur la protection physique des bâtiments du TPC, ils doivent garantir une protection élevée
contre la pénétration d’intrus humains ou de rayonnement : sas d’entrée, pas de fenêtres, système
d'alarmes, salle protégée sur le plan électromagnétique, etc.
Sur le plan des accès réseaux, aucun accès direct à des machines contenant ou qui génèrent des clefs
privées ne sont acceptés.
Le deuxième point, relève des accréditations des personnes qui gèrent le TPC, en effet, la confiance des
utilisateurs envers les moyens générés par le TPC, est confortée si le système est sous le contrôle de
structure étatique.au sommet de la hiérarchie, ceci n’est pas le cas en France.
Les procédures de génération sont un des points clefs du TPC, elles vont décrire les différentes étapes de
génération, le nombre de personnes qui vont intervenir et dans quel ordre.
Les moyens informatiques utilisés, leurs différents constituants autorisés vont être décrits, la technique
cryptologique utilisée va être contrôlée afin de garantir la consistance des clefs générées.
Les relations avec les clients sont aussi codifiées afin de structurer les échanges et éviter les litiges :
politique de certification.
L’ensemble de ces mesures doivent alors passer les tests d’intrusion et d’analyse de sécurité : chaine des
éléments physiques utilisés et des enchainements des procédures.
La fonction de TPC se retrouve soit en interne d’entreprise ou d’entité administrative soit comme système
destiné et ouvert au public.
CONCLUSION
La question de la sécurité d’un système IGC et TPC est très difficile.
Même dans le cas d’une utilisation en environnement fermé : clients connus et authentifiés et clients
nouveaux contrôlés par une AE, le système possède des failles.
Ceci est particulièrement grave, car dans ce cas, c’est le système à la base de la confiance qui est pris en
défaut.
L’utilisation de support mobile de données : carte à puce, clefs USB etc. utilisés dans des environnements
différents de celui du système IGC_TPC ou sur des PC utilisés dans des environnements
différents, engendre des risques d‘attaque et de destruction de plusieurs entités du système global,
La confiance est alors relative au système en lui-même : sécurité de l’ensemble IGC/TPC, mais aussi à
l’environnement d’utilisation des moyens de signature ou de chiffrement et donc au comportement des
utilisateurs.
GLOSSAIRE
AC
Autorité de Certification
AE
Autorité d’Enregistrement
CRL
Certificate Revocation List
ECC
Elliptic Curve Cryptography
IGC
Infrastructure de Gestion de Clés
LDAP
Lightweight Directory Access Protocol
RSA
Rivest, Shalir et Adelman
TPC
Tiers Partie de Confiance
Un livre blanc
5/6
A PROPOS DE L’AUTEUR
Jean-Pierre Cabanel est Professeur à l'Institut National Polytechnique (ENSEEIHT) de
Toulouse et membre du laboratoire IRIT (Institut de Recherche en Informatique de
Toulouse), équipe Université. Il anime un groupe de recherche sur le futur des
télécommunications. Ses travaux récents traitent de l’autonomie des vecteurs aériens
et spatiaux.
Jean-Pierre Cabanel est Docteur d’état de l’Université Paul Sabatier (Toulouse) en
1982. Il travaille en premier au sein du laboratoire IBM de Yorktown (USA), avant de
retrouver les projets « pilotes »de l’INRIA dans le cadre du laboratoire de l’IRIT.
Il anime avec le Professeur Guy Pujolle le « Working Group » 6.4 de l’IFIP sur les LAN
et PABX et organise plusieurs congrès au sein de Sup Telecom. Paris.
Il travaille ensuite sur la problématique de la sécurité des systèmes de communication : PKI : Private Key
Infrastructure, et TPC : Tierce Partie de Confiance, etc. en collaboration avec le DCSSI : Direction Centrale
de la Sécurité des systèmes d’Informations.
Les idées émises dans ce livre blanc n’engagent que la responsabilité de leurs auteurs et pas celle de Forum ATENA.
La reproduction et/ou la représentation sur tous supports de cet ouvrage, intégralement ou partiellement est autorisée à
la condition d'en citer la source comme suit :
© Forum ATENA 2011 – La confiance et la sécurité
Licence Creative Commons
-
Paternité
Pas d’utilisation commerciale
Pas de modifications
L'utilisation à but lucratif ou commercial, la traduction et l'adaptation sous quelque support que ce soit sont interdites
sans la permission écrite de Forum ATENA.
Un livre blanc
6/6