Que signifie PKI ?

PKI est un acronyme utilisé pour décrire l’infrastructure à clé publique. Il s’agit de la technologie derrière les certificats numériques. Un certificat numérique remplit un objectif similaire à un permis de conduire ou à un passeport : c’est une pièce d’identité qui prouve votre identité et vous confère certains droits. Un certificat numérique permet à son propriétaire de chiffrer, signer et authentifier. En conséquence, la PKI est la technologie qui vous permet de chiffrer des données, de signer numériquement des documents et de vous authentifier à l’aide de certificats.

Les entreprises ont un certain nombre d’exigences en ce qui concerne la mise en œuvre d’infrastructures à clé publique efficaces. Tout d’abord, si les utilisateurs ne peuvent pas tirer parti du chiffrement et des signatures numériques dans les applications, une PKI n’a pas de valeur. Par conséquent, la plus importante contrainte imposée à une PKI est la transparence. Le terme transparence signifie que les utilisateurs n’ont pas à comprendre comment la PKI gère les clés et les certificats pour profiter des services de chiffrement et de signature numérique. Une PKI efficace est transparente. Outre la transparence des utilisateurs, une entreprise doit mettre en œuvre les éléments suivants dans une PKI pour fournir les services requis de gestion des clés et des certificats :

• Certificats de clé publique
• Un référentiel de certificats
• Révocation de certificat
• Sauvegarde et récupération de clés
• Prise en charge de la non-répudiation des signatures numériques
• Mise à jour automatique des paires de clés et des certificats
• Gestion des historiques de clés
• Prise en charge de la certification croisée
• Un logiciel côté client interagissant avec tout ce qui précède de manière sécurisée, cohérente et digne de confiance

Remarque : Le terme « côté client » fait référence aux clients d’applications et aux serveurs d’applications. Les exigences de PKI sont les mêmes pour les clients d’application et les serveurs, et tous deux sont des « clients » des services d’infrastructure.

Toutes ces exigences doivent également être remplies pour obtenir une PKI automatique, transparente et utilisable.

Pour que la cryptographie à clé publique soit utile, les utilisateurs doivent être assurés que les autres parties avec lesquelles ils communiquent sont « en sécurité », c’est-à-dire que leurs identités et clés sont valides et dignes de confiance. Pour fournir cette assurance, tous les utilisateurs d’une PKI doivent avoir une identité enregistrée.

Ces identités sont stockées dans un format de certificat de clé publique numérique X.509 standard. Les autorités de certification (AC) représentent les personnes, les processus et les outils pour créer des certificats numériques qui lient en toute sécurité les noms des utilisateurs à leurs clés publiques. Lors de la création de certificats, les AC agissent comme des agents de confiance dans une PKI. Tant que les utilisateurs font confiance à une AC et à ses stratégies d’émission et de gestion des certificats, ils peuvent approuver les certificats émis par l’AC. Il s’agit en fait de la confiance tierce.

Les AC créent des certificats pour les utilisateurs en signant numériquement un ensemble de données qui comprend les informations suivantes (et des éléments supplémentaires) :

1. Le nom de l’utilisateur au format d’un nom distinctif (ND). Le ND spécifie le nom de l’utilisateur et tous les attributs supplémentaires requis pour identifier l’utilisateur de manière unique (par exemple, le ND peut contenir le numéro d’employé de l’utilisateur).
2. Une clé publique de l’utilisateur. La clé publique est requise pour que d’autres puissent effectuer le chiffrement pour l’utilisateur ou vérifier la signature numérique de l’utilisateur.
3. La période de validité (ou durée de vie) du certificat (une date de début et une date de fin).
4. Les opérations spécifiques pour lesquelles la clé publique doit être utilisée (que ce soit pour chiffrer des données, vérifier des signatures numériques ou les deux).

La signature de l’AC sur un certificat signifie que toute falsification du contenu du certificat sera facilement détectée. La signature de l’AC sur un certificat est comme un sceau de détection des falsifications sur un flacon de pilules. Toute falsification du contenu d’un certificat est facilement détectée. Tant que la signature de l’AC sur un certificat peut être vérifiée, le certificat est intègre. L’intégrité d’un certificat peut être déterminée en vérifiant la signature de l’AC ; les certificats sont donc intrinsèquement sécurisés et peuvent être distribués de manière totalement publique (par exemple, via des systèmes de répertoires accessibles au public).

Les utilisateurs qui récupèrent une clé publique à partir d’un certificat peuvent être assurés que la clé publique est valide. Autrement dit, les utilisateurs peuvent être sûrs que le certificat et sa clé publique associée appartiennent à l’entité spécifiée par le nom distinctif. Les utilisateurs peuvent également avoir confiance dans le fait que la clé publique est toujours dans sa période de validité définie. En outre, les utilisateurs sont assurés que la clé publique peut être utilisée en toute sécurité de la manière prévue par l’AC.

La PKI est un élément essentiel de la stratégie informatique. La PKI est importante, car la technologie basée sur les certificats aide les organisations à établir une signature, un chiffrement et une identité fiables entre les personnes, les systèmes et les objets.

Avec l’évolution des modèles économiques qui deviennent de plus en plus dépendants des transactions électroniques et des documents numériques, et alors que le nombre des appareils compatibles Internet connectés aux réseaux d’entreprise augmente, le rôle d’une infrastructure à clé publique ne se limite plus à des systèmes isolés tels que la messagerie sécurisée, les cartes à puce pour l’accès physique ou le trafic Web chiffré. On attend désormais des PKI qu’elles prennent en charge un plus grand nombre d’applications, d’utilisateurs et d’appareils dans des écosystèmes complexes. En outre, avec des réglementations gouvernementales et sectorielles plus strictes en matière de sécurité des données, les systèmes d’exploitation et les applications d’entreprise traditionnels dépendent plus que jamais d’une infrastructure à clé publique organisationnelle pour garantir la confiance.

Qu’est-ce que le vol d’autorité de certification ou de clés privées racines ?

Le vol d’autorité de certification (CA) ou de clés privées racines permet à un attaquant de prendre le contrôle de l’infrastructure à clé publique (PKI) d’une organisation et d’émettre de faux certificats, comme cela a été fait dans l’attaque Stuxnet. Une telle exposition peut contraindre à révoquer et réémettre tout ou partie des certificats précédemment émis. Une altération à la racine, comme le vol d’une clé privée racine, détruit la confiance de votre PKI et peut facilement vous conduire à établir une nouvelle infrastructure d’autorités de certification émettrices racine et secondaires. Cela peut être très coûteux en plus d’endommager l’identité d’une entreprise.

L’intégrité des clés privées d’une organisation, dans toute l’infrastructure, de la racine aux autorités de certification émettrices, constitue le socle de confiance de son infrastructure à clé publique et, en tant que telle, elle doit être protégée. La pratique recommandée et reconnue pour sécuriser ces clés critiques consiste à utiliser un module matériel de sécurité (HSM) certifié FIPS 140-2 Niveau 3, un dispositif inviolable qui satisfait aux normes de sécurité et d’assurance les plus élevées.

PKI et SSL, bien que différents, sont deux solutions basées sur des certificats qui établissent la « confiance » avec des certificats émis par une autorité de certification (CA) – qu’il s’agisse de confiance publique (SSL) ou privée (PKI).

La PKI fournit un cadre complet qui comprend du matériel, des logiciels ou encore des politiques. Une PKI comprend également une AC qui délivre les certificats numériques pour établir la confiance. En règle générale, cette AC est régie en interne selon des politiques et des procédures qui correspondent aux niveaux de sécurité et d’assurance requis de l’organisation.

SSL est l’un des principaux cas d’utilisation de PKI. Il implique également une AC qui émet des certificats, mais cette dernière doit être reconnue par les navigateurs comme étant une AC de confiance publique. Et s’il existe de nombreux cas d’utilisation de PKI, l’objectif du SSL est de sécuriser les données sensibles transférées via des communications en ligne, comme les transactions bancaires en ligne ou les transactions de commerce électronique.

Les principaux cas d’utilisation de PKI peuvent être déterminés en examinant les applications qui utilisent le plus couramment des certificats numériques, par exemple :

Cas d’utilisation traditionnels

Ces applications critiques pour l’entreprise montrent clairement que la PKI est un élément informatique stratégique.

• Certificats SSL pour les sites et services destinés au public
• Réseaux privés et réseaux privés virtuels (VPN)
• Applications et services basés sur le Cloud public
• Applications privées basées sur le cloud
• Sécurité des e-mails
• Authentification des utilisateurs professionnels
• Authentification de périphérique
• Authentification privée basée sur le cloud
• Signature de document/message
• Signature de code

(Voir les détails dans le tableau ci-dessous.)

Cas d’utilisation nouveaux et émergents

Nous avons également noté une résurgence de PKI suite à certains cas d’utilisation liés à DevOps qui entraînent un taux d’adoption accru, par exemple :

• Services basés sur le Cloud
• Mobile grand public
• Internet des Objets (IoT)
• Applications mobiles axées sur le consommateur
• Politiques BYOD (apportez votre propre périphérique) et gestion interne des appareils mobiles
• e-commerce

(Voir les détails dans le tableau ci-dessous.)

Certains experts prévoient d’autres cas d’utilisation dans le futur à mesure que la technologie et l’intelligence artificielle évoluent constamment.

La différence entre les clés privées et publiques est que l’une est utilisée pour chiffrer, tandis que l’autre est utilisée pour déchiffrer.

Une clé publique est utilisée pour chiffrer les informations. Elle les rend illisibles pour quiconque n’en est pas le destinataire prévu. Ce destinataire détient ensuite une clé privée avec laquelle il peut déchiffrer les informations.

Aussi, une clé publique est accessible au public pour un ensemble d’utilisateurs qui auraient besoin d’envoyer des informations de manière confidentielle. Par exemple, la clé publique d’une personne serait disponible pour ses collègues au sein d’une organisation via un répertoire partagé. Inversement, une clé privée est accessible uniquement par la personne recevant les informations, qui serait donc la seule personne capable de déchiffrer avec succès ce qui a été chiffré.

Ensemble, les clés publiques et privées garantissent que les informations, les données et les communications sont chiffrées avant d’être ensuite transmises et déchiffrées en toute sécurité par la partie appropriée.

Une entreprise doit être en mesure de récupérer des données chiffrées lorsque les utilisateurs perdent leurs clés de déchiffrement. Cela signifie que l’entreprise à laquelle appartient l’utilisateur a besoin d’un système de sauvegarde et de récupération des clés de déchiffrement.

Il existe deux raisons pour lesquelles la sauvegarde et la récupération de clés sont si importantes pour les entreprises :

1. Les utilisateurs oublient souvent les mots de passe. Perdre des données peut être catastrophique pour une entreprise lorsque les utilisateurs oublient les mots de passe nécessaires pour accéder à leurs clés de déchiffrement. Des informations précieuses seraient perdues à jamais s’il n’était pas possible de récupérer ces clés en toute sécurité. De plus, à moins que les utilisateurs ne sachent qu’ils peuvent toujours récupérer leurs données chiffrées (même s’ils oublient leurs mots de passe), certains utilisateurs ne crypteront pas leurs informations les plus précieuses et les plus sensibles de peur de les perdre, et ce, même s’il s’agit d’informations ayant besoin de la plus grande protection.
2. Les utilisateurs peuvent perdre, briser ou corrompre les périphériques dans lesquels leurs clés de déchiffrement sont stockées. Par exemple, si les clés de déchiffrement d’un utilisateur sont stockées sur une carte magnétique, le champ magnétique sur la carte peut se voir corrompu. Encore une fois, la perte permanente de ces clés de déchiffrement peut être désastreuse. Les utilisateurs ne peuvent pas récupérer les données chiffrées à moins que leurs clés de déchiffrement ne soient sauvegardées.

La différence entre la sauvegarde de clé et le séquestre de clé

Les exigences commerciales pour la sauvegarde et la récupération de clés peuvent être complètement séparées des exigences d’application de la loi pour le séquestre de clés… un sujet largement discuté dans les médias.

• Le séquestre de clé signifie qu’un tiers (tel qu’un agent fédéral) peut obtenir les clés de déchiffrement nécessaires pour accéder aux informations chiffrées. Le but du séquestre des clés est de favoriser l’application de la loi. Il fait l’objet de nombreux débats en raison de la distinction fine entre l’intérêt public (comme la sécurité nationale) et la liberté individuelle et la vie privée.
• Les principales exigences de sauvegarde et de restauration se concentrent sur les besoins commerciaux fondamentaux qui existent, quelles que soient les exigences en matière d’application de la loi.

Quelles clés nécessitent une sauvegarde ?

Les seules clés nécessitant une sauvegarde sont les clés de déchiffrement des utilisateurs. Tant qu’un agent de confiance (par exemple, l’AC) sauvegarde en toute sécurité les clés de déchiffrement des utilisateurs, la sécurité n’est pas compromise et les données de l’utilisateur peuvent toujours être récupérées. Cependant, les clés de signature n’ont pas les mêmes exigences que les clés de déchiffrement. Comme décrit dans la section suivante, la sauvegarde des clés de signature va à l’encontre d’une exigence de base d’une PKI.

La répudiation se produit lorsqu’un individu nie toute implication dans une transaction. Par exemple, lorsqu’une personne prétend qu’une carte de crédit a été volée, elle rejette toute responsabilité pour les transactions effectuées avec cette carte à tout moment après avoir signalé le vol.

La non-répudiation signifie qu’un individu ne peut pas nier avec succès sa participation à une transaction. Dans le monde du papier, la signature d’un individu le lie juridiquement à ses transactions (frais de carte de crédit, contrats commerciaux, etc.). La signature empêche la répudiation de ces transactions.

Dans le monde électronique, la signature manuscrite est remplacée par une signature numérique. Tous les types de commerce électronique nécessitent des signatures numériques, car le commerce électronique rend obsolètes les signatures manuscrites traditionnelles.

La clé privée de signature

La condition la plus fondamentale pour la non-répudiation est que la clé utilisée pour créer des signatures numériques (la clé de signature) soit générée et stockée en toute sécurité sous le contrôle exclusif de l’utilisateur à tout moment. Sauvegarder la clé de signature n’est pas acceptable. Contrairement aux paires de clés de chiffrement, il n’existe aucune exigence technique ou commerciale pour sauvegarder ou restaurer les paires de clés de signature précédentes lorsque les utilisateurs oublient leurs mots de passe ou perdent, brisent ou corrompent leurs clés de signature. Dans de tels cas, les utilisateurs peuvent générer de nouvelles paires de clés de signature et les utiliser pour la suite.

Le besoin de deux paires de clés

Il est difficile de prendre en charge simultanément la sauvegarde et la récupération de clés et la non-répudiation. Pour prendre en charge la sauvegarde et la récupération des clés, les clés de déchiffrement doivent être sauvegardées en toute sécurité. Mais pour prendre en charge la non-répudiation, les clés utilisées pour la signature numérique ne peuvent pas être sauvegardées et doivent être sous le contrôle exclusif de l’utilisateur à tout moment.

Pour répondre à ces exigences, une PKI doit prendre en charge deux paires de clés pour chaque utilisateur. À tout moment, un utilisateur doit disposer d’une paire de clés actuelle pour le chiffrement et le déchiffrement, et une seconde paire de clés pour la signature numérique et la vérification de signature. Au fil du temps, les utilisateurs disposeront de nombreuses paires de clés qui doivent être gérées de manière appropriée.

Les paires de clés cryptographiques ne doivent pas être utilisées indéfiniment. Elles doivent être mises à jour au fil du temps. En conséquence, chaque organisation doit se poser deux questions importantes :

1. Mettre à jour les paires de clés des utilisateurs - Le processus de mise à jour des paires de clés doit être transparent pour les utilisateurs. Cette transparence signifie que les utilisateurs n’ont pas à comprendre quelle mise à jour de clés doit avoir lieu et qu’ils ne subiront jamais de « déni de service » car leurs clés ne sont plus valides. Pour garantir la transparence et éviter les dénis de service, les paires de clés des utilisateurs doivent être automatiquement mises à jour avant leur expiration.
2. Maintenir, le cas échéant, l’historique des paires de clés précédentes - Lorsque les paires de clés de chiffrement sont mises à jour, l’historique des clés de déchiffrement précédentes doit être conservé. Cet « historique des clés » permet aux utilisateurs d’accéder à l’une de leurs clés de déchiffrement antérieures pour déchiffrer les données. (Lorsque les données sont chiffrées avec la clé de chiffrement d’un utilisateur, seule la clé de déchiffrement correspondante – la clé jumelée – peut être utilisée pour le déchiffrement). Pour garantir la transparence, le logiciel côté client doit gérer automatiquement l’historique des clés de déchiffrement des utilisateurs.

L’historique des clés doit également être géré de manière sécurisée par le système de sauvegarde et de récupération des clés. Cela permet de récupérer les données chiffrées en toute sécurité, quelle que soit la clé publique de chiffrement utilisée pour chiffrer les données à l’origine (et, par extension, quel que soit le moment où les données ont été chiffrées).

Lorsqu’une paire de clés de signature est mise à jour, la clé de signature précédente doit être détruite en toute sécurité. Cela empêche toute autre personne d’accéder à la clé de signature, ce qui est acceptable, car il n’est pas nécessaire de conserver les clés de signature précédentes.

Comme mentionné précédemment, la CA agit en tant que tiers de confiance qui émet des certificats aux utilisateurs. Les entreprises doivent également distribuer ces certificats, afin qu’ils puissent être utilisés par les applications. Les référentiels de certificats stockent les certificats pour que les applications puissent les récupérer au nom des utilisateurs.

Le terme « référentiel » fait référence à un service en réseau qui permet la distribution de certificats. Au cours des dernières années, le consensus dans l’industrie informatique a été que la meilleure technologie pour les référentiels de certificats est fournie par des systèmes de répertoires compatibles avec le protocole LDAP (Lightweight Directory Access Protocol). Le LDAP définit le protocole standard pour accéder aux systèmes de répertoires.

Plusieurs facteurs motivent cette position consensuelle :

• Le stockage des certificats dans des répertoires et la récupération des certificats par les applications au nom des utilisateurs offrent la transparence requise pour une utilisation dans la plupart des entreprises
• De nombreuses technologies de répertoires prenant en charge le LDAP peuvent être mises à l’échelle pour :
  • prendre en charge un très grand nombre d’entrées ;
  • répondre efficacement aux demandes de recherche grâce à leurs méthodes de stockage et de récupération d’informations ;
  • être distribué sur tout le réseau pour répondre aux exigences des organisations, même les plus distribuées.

En outre, les répertoires qui prennent en charge la distribution de certificats peuvent stocker d’autres informations sur l’entreprise. Comme indiqué dans la section suivante, la PKI peut également utiliser le répertoire pour distribuer les informations de révocation de certificat.

En plus de vérifier la signature de l’autorité de certification sur un certificat (comme indiqué précédemment dans « Quels sont les rôles des certificats et des autorités de certification ? »), le logiciel d’application doit également s’assurer que le certificat est toujours digne de confiance au moment de l’utilisation. Les certificats qui ne sont plus dignes de confiance doivent être révoqués par l’autorité de certification. Il existe de nombreuses raisons pour lesquelles un certificat peut devoir être révoqué avant la fin de sa période de validité. Par exemple, la clé privée (la clé de signature ou la clé de déchiffrement) correspondant à la clé publique dans le certificat peut être compromise. Autrement, la politique de sécurité d’une organisation peut imposer que les certificats des employés quittant l’organisation doivent être révoqués.

Dans ces situations, les utilisateurs du système doivent être informés que l’utilisation continue du certificat n’est plus considérée comme sûre. Le statut de révocation d’un certificat doit être vérifié avant chaque utilisation. En conséquence, une PKI doit intégrer un système de révocation de certificats évolutif. L’AC doit être en mesure de publier en toute sécurité des informations concernant l’état de chaque certificat dans le système. Le logiciel d’application, au nom des utilisateurs, doit ensuite vérifier les informations de révocation avant chaque utilisation d’un certificat.

La combinaison de la publication et de l’utilisation cohérente des informations de révocation de certificats constitue un système de révocation complet. Le moyen le plus courant de distribuer les informations de révocation de certificats consiste pour l’AC à créer des listes de révocation de certificats (LRC) sécurisées et à publier ces LRC dans un système de répertoires. Les LRC précisent les numéros de série uniques de tous les certificats révoqués.

Avant d’utiliser un certificat, l’application côté client doit vérifier la LRC appropriée pour déterminer si le certificat est toujours digne de confiance. Les applications côté client doivent vérifier les certificats révoqués de manière cohérente et transparente au nom des utilisateurs.

La certification croisée étend les relations d’approbation tierces entre les domaines d’autorité de certification. Par exemple, deux partenaires commerciaux, chacun avec sa propre AC, peuvent souhaiter valider les certificats émis par l’AC de l’autre partenaire. Une grande organisation distribuée peut également exiger plusieurs AC dans diverses régions géographiques. La certification croisée permet à différents domaines d’AC d’établir et de maintenir des relations électroniques fiables.

Le terme de certification croisée fait référence à deux opérations :

1. Établissement d’une relation de confiance entre deux autorités de certification (rarement exécuté). Dans le cas de la certification croisée bilatérale, deux AC échangent en toute sécurité leurs clés de vérification. Ce sont les clés utilisées pour vérifier les signatures des AC sur les certificats. Pour terminer l’opération, chaque AC signe la clé de vérification de l’autre AC dans un certificat appelé « certificat croisé ».
2. Vérification de la fiabilité d’un certificat utilisateur signé par une AC croisée (exécuté fréquemment). Soit. Pour l’opération effectuée par le logiciel côté client, on parle souvent d’un « parcours dans une chaîne de confiance ». La « chaîne » fait référence à une liste de validations de certificats croisés qui sont « parcourues » (ou suivies) de la clé de l’AC de l’utilisateur vérificateur à la clé de l’AC requise pour valider le certificat de l’autre utilisateur. Lorsque vous parcourez une chaîne de certificats croisés, chaque certificat croisé doit être vérifié pour s’assurer qu’il est toujours approuvé. Les certificats d’utilisateur doivent pouvoir être révoqués ; il en va de même pour les certificats croisés. Cette exigence est souvent négligée dans les discussions concernant la certification croisée.

Lorsqu’elles discutent des exigences relatives aux PKI, les entreprises négligent souvent l’exigence d’un logiciel côté client. (Par exemple, de nombreuses personnes se concentrent uniquement sur le composant « AC » lors de la discussion sur les PKI). En fin de compte, cependant, la valeur d’une PKI est liée à la capacité des utilisateurs à utiliser le chiffrement et les signatures numériques. Pour cette raison, la KPI doit inclure un logiciel côté client qui fonctionne de manière cohérente et transparente entre les applications sur le bureau (e-mail, navigation Web, formulaires électroniques, chiffrement de fichiers/dossiers, etc.).

Une mise en œuvre cohérente et facile à utiliser des PKI dans le logiciel côté client réduit les coûts d’exploitation de PKI. De plus, les logiciels côté client doivent être activés sur le plan technologique pour prendre en charge tous les éléments d’une PKI. La liste suivante résume les exigences que les logiciels côté client doivent respecter pour garantir que les utilisateurs d’une entreprise reçoivent une PKI utilisable et transparente (et donc acceptable).

• Certificats de clé publique Pour fournir une confiance tierce, toutes les applications compatibles PKI doivent utiliser des certificats de manière cohérente et fiable. Le logiciel côté client doit valider la signature de l’AC sur les certificats et s’assurer que les certificats ne dépassent pas leur période de validité.
• Sauvegarde et récupération de clés Pour garantir la protection des utilisateurs contre la perte de données, la PKI doit prendre en charge un système de sauvegarde et de récupération des clés de déchiffrement. En raison des coûts administratifs, il est inacceptable que chaque application fournisse sa propre sauvegarde et récupération de clé. Au lieu de cela, toutes les applications client compatibles PKI doivent interagir avec un seul et unique système de sauvegarde et de récupération de clés. Les interactions entre le logiciel côté client et le système de sauvegarde et de récupération de clés doivent être sécurisées et la méthode d’interaction doit être cohérente dans toutes les applications compatibles PKI.
• Prise en charge de la non-répudiation Pour fournir une prise en charge de base de la non-répudiation, le logiciel côté client doit générer les paires de clés utilisées pour la signature numérique. En outre, le logiciel côté client doit garantir que les clés de signature ne sont jamais sauvegardées et restent sous le contrôle des utilisateurs à tout moment. Ce type de prise en charge doit être cohérent dans toutes les applications compatibles PKI.
• Mise à jour automatique des paires de clés Pour activer la transparence, les applications côté client doivent lancer automatiquement la mise à jour des paires de clés des utilisateurs. Cela doit être fait conformément aux politiques de sécurité de l’organisation. Il est inacceptable que les utilisateurs sachent que leurs paires de clés doivent être mises à jour. Pour répondre à cette exigence dans toutes les applications compatibles PKI, le logiciel côté client doit mettre à jour les paires de clés de manière transparente et cohérente.
• Gestion des historiques de clés Pour permettre aux utilisateurs d’accéder facilement à toutes les données chiffrées pour eux (quel que soit le moment où elles ont été chiffrées), les applications compatibles PKI doivent avoir accès à l’historique des clés des utilisateurs. Et le logiciel côté client doit être en mesure de récupérer en toute sécurité l’historique des clés des utilisateurs.
• Référentiel de certificats évolutif Pour minimiser les coûts de distribution des certificats, toutes les applications compatibles PKI doivent disposer d’un référentiel de certificats commun et évolutif.

Prise en charge de nouvelles applications

Il est souvent difficile pour les applications d’utiliser des PKI. Selon le rapport 2019 sur les tendances en matière de PKI et d’IoT du Ponemon Institute , les deux principaux défis auxquels les organisations continueront de faire face, en ce qui concerne l’habilitation des applications à utiliser une PKI, sont l’incapacité d’une PKI existante à prendre en charge de nouvelles applications et l’incapacité à modifier les applications existantes.

(Voir les détails dans le tableau ci-dessous.)

Absence de propriété explicite

La même enquête a également révélé que le principal défi du déploiement de la PKI reste l’absence de propriété explicite de la fonction PKI. Mais dans l’environnement PKI d’aujourd’hui, une gestion appropriée est nécessaire, surtout si l’on tient compte de ce qui suit :

• L’infrastructure est distribuée et de nombreux certificats sont délivrés à de nombreux individus, lieux et objets
• Nous devons sécuriser plus de « choses » que jamais et gérer des certificats dont la durée de validité est plus courte
• Les certificats sécurisent les applications métiers critiques et les pannes peuvent être coûteuses et difficiles à diagnostiquer

Pour obtenir une bonne visibilité sur les certificats de votre infrastructure, il faut non seulement centraliser la gestion des PKI au sein d’un service spécifique, mais également avec un outil logiciel qui fournit une seule console pour la surveillance des certificats et la création de rapports.

Il existe plusieurs normes et réglementations différentes, en particulier au niveau régional et/ou gouvernemental, mais les deux certifications de sécurité les plus importantes lors du déploiement de PKI sont :

• Common Criteria EAL Niveau 4+
• FIPS 140-2, niveau 3