Infrastructures à clés publiques

Trop souvent entendus :
  • le consultant sécu « Comment ça…, votre entreprise n’a pas de PKI ? »
  • mais aussi le bon techos qui a installé en 7 clics sa CA Microsoft sous Windows 2003 « Oui, c’est moi qui ai mis en place la PKI, je ne vais pas m’étendre c’est très compliqué »

Pour essayer d’apporter un peu de lumière sur un grand classique des sujets connexes des réunions IT, je reformule ci-dessous un extrait d’un article de Wikipédia, l’encyclopédie libre.

1- plusieurs appellations pour un même outil :

  • Infrastructure à Clés Publiques (ICP)
  • Infrastructure de Gestion de Clés (IGC)
  • Public Key Infrastructure (PKI)

2- définition : une ICP est un ensemble

3- remarque : la notion de PKI est souvent  galvaudée et  présentée sous une forme complexe accessibles à seuls quelques gourous de la technologie: Le traditionnel écran de fumée derrière lequel certains informaticiens pas si  experts que ça aiment à se protéger. Attention, on oublie souvent l’aspect « procédures humaines » sans quoi la PKI se limite souvent à une brique technique nébuleuse permettant une génération ponctuelle de certificats auto-signés.

Une infrastructure à clés publiques délivre les services suivant pour le compte de ses utilisateurs:

  • enregistrement des utilisateurs (ou équipement informatique) ;
  • génération de certificats ;
  • renouvellement de certificats ;
  • révocation de certificats ;
  • publication de certificats ;
  • publication des listes de révocation (comprenant la liste des certificats révoqués) ;
  • identification et authentification des utilisateurs et équipements (administrateurs ou utilisateurs qui accèdent à l’IGC) ;
  • archivage, séquestre et recouvrement des certificats (option).

Rôle d’une infrastructure de gestion des clés

Une IGC délivre des certificats numériques. Ces certificats permettent d’effectuer des opérations cryptographiques, comme le chiffrement et la signature numérique qui offrent les garanties suivantes lors des transactions électroniques :

  • confidentialité : seul le destinataire (ou le possesseur) légitime d’un bloc de données ou d’un message pourra en avoir une vision intelligible ;
  • authentification : lors de l’envoi d’un bloc de données ou d’un message ou lors de la connexion à un système, on connaît sûrement l’identité de l’émetteur ou l’identité de l’utilisateur qui s’est connecté ;
  • intégrité : on a la garantie qu’un bloc de données ou un message expédié n’a pas été altéré, accidentellement ou intentionnellement ;
  • non-répudiation : l’auteur d’un bloc de données ou d’un message ne peut pas renier son œuvre.

Les IGC permettent l’obtention de ces garanties par l’application de processus de vérification d’identité rigoureux et par la mise en œuvre de solutions cryptographiques fiables (éventuellement évaluées), conditions indispensables à la production et à la gestion des certificats électroniques.

Composants de l’infrastructure de gestion des clés

Les IGC (comme définies par l’IETF) se scindent en 4 entités distinctes :

  • L’autorité de certification (AC ou Certificate Authoirity: CA) qui a pour mission de signer les demandes de certificat (CSR : Certificate Signing Request) et de signer les listes de révocation ( Certificate Revocation List: CRL). Cette autorité est la plus critique.
  • L’autorité d’enregistrement (AE ou Registering Authority: RA) qui a pour mission de générer les certificats, et d’effectuer les vérifications d’usage sur l’identité de l’utilisateur final (les certificats numériques sont nominatifs et uniques pour l’ensemble de l’IGC).
  • L’autorité de dépôt (Repository) qui a pour mission de stocker les certificats numériques ainsi que les listes de révocation (CRL).
  • L’entité finale (End Entity: EE). L’utilisateur ou le système qui est le sujet d’un certificat (En général, le terme « entité d’extrémité »  est préféré au terme « sujet » afin d’éviter la confusion avec le champ Subject).

En complément, on pourra ajouter l’autorité de séquestre, qui n’est pas définie spécifiquement par l’IETF :

  • L’autorité de séquestre (Key Escrow), a un rôle particulier, en effet lorsqu’on génère des certificats de chiffrement, on a l’obligation légale [en France] de fournir aux autorités un moyen de déchiffrer les données chiffrées pour un utilisateur de l’IGC. C’est là qu’intervient le séquestre, cette entité a pour mission de stocker de façon sécurisée les clés de chiffrement qui ont été générées par l’IGC, pour pouvoir les restaurer le cas échéant.

 

Précautions pour le déploiement

Certains experts pensent aujourd’hui que, dans un monde ouvert, il faut prendre certaines précautions avant de déployer une PKI, faute de quoi il y a des risques de pillage. Avant d’aborder les questions techniques, il faut par exemple se demander quels sont les utilisateurs, et si le cadre juridique est prêt.

Lorsque l’entreprise échange beaucoup de données avec des partenaires en extranet, comme c’est le cas des entreprises étendues ou des pôles de compétitivité, la question de la sécurisation de l’interopérabilité se pose.

Dans ces grandes communautés, l’information d’autorité doit être gérée dans des registres de métadonnées publics. Le certificat électronique peut alors être associé, dans le registre, à l’identifiant, afin de circonscrire le patrimoine informationnel partagé par la communauté de pratique.

Voir par exemple : Dictionnaire de métadonnées pour le référentiel des publications CNRS

Par ailleurs, Il est conseillé de déployer les certificats sur support matériel (carte à puce) car le vol de certificat logiciel fait désormais partie des possibilités des malwares.

Répondre

You must be logged in to post a comment.