Les solutions basées sur des infrastructures à clés publiques (PKI) poursuivent leur envolée : le nombre de sites ayant migré vers le HTTPS atteint des records inédits, les entreprises utilisent les certificats numériques comme facteur d’authentification des utilisateurs et des machines, et le S/MIME s’impose à la fois comme solution de chiffrement d’e-mails et comme moyen de valider l’origine des messages pour mieux lutter contre le hameçonnage. Mais, l’intérêt du chiffrement et de l’authentification trouve rapidement ses limites sans une bonne gestion des clés.
À chaque émission de certificat numérique, depuis une autorité de certification ou par auto signature, une paire de clés privées/publiques doit être générée. Comme le veulent les bonnes pratiques, vos clés privées doivent rester en sécurité et… privées ! Imaginez ce qu’il se passerait si un tiers mettait la main sur ces clés. Suivant le type de certificats, une personne malintentionnée pourrait créer des sites Web de rançonnage où s’afficherait, dans la barre d’adresse, le certificat de votre entreprise. Cette personne pourrait également s’authentifier sur les réseaux de votre entreprise en se faisant passer pour vous, afin de signer des applications ou des documents en votre nom, ou de lire vos e-mails chiffrés.
Or, bien souvent, vos clés privées correspondent à l’identité de vos employés (et constituent, par conséquent, une extension de l’identité de votre entreprise). Dans un scénario d’identification biométrique, protéger ses clés revient à protéger ses empreintes digitales. Vous ne laisseriez pas un pirate faire main basse sur vos empreintes digitales, alors pourquoi l’autoriseriez-vous à s’emparer de votre clé privée ?
Dans ce billet, nous évoquerons les moyens de protéger et stocker vos clés privées. Comme vous pourrez le voir, les solutions peuvent légèrement varier suivant le type de certificats et leur usage (les bonnes pratiques applicables aux certificats SSL/TLS diffèrent de celles des certificats pour les utilisateurs finaux).
Magasin de certificats et de clés des systèmes d’exploitation/navigateurs
Exemples : Windows Certificate Store, Mac OS Keychain
Plusieurs systèmes d’exploitation et navigateurs proposent des magasins de certificats de clés. Ces bases de données logicielles stockent votre paire de clés publiques/privées en local sur votre machine, comme faisant partie intégrante d’un certificat. Ce type de stockage de clés est assez répandu. Beaucoup d’applications recherchent automatiquement la clé à cet endroit, vous évitant ainsi à chaque fois de rechercher manuellement le fichier de certificat. C’est donc une solution plutôt conviviale pour l’utilisateur.
Autre atout : cette solution est relativement simple à personnaliser. Vous pouvez activer/désactiver l’option « d’exportabilité » de la clé privée, activer un niveau de protection forte pour la clé privée (avec une invite de saisie de mot de passe à chaque utilisation de votre certificat), et créer des sauvegardes si la clé privée est exportable. La fonction d’itinérance de profil permet aux utilisateurs sous Windows de lier le certificat à leur profil afin de l’utiliser sur n’importe quelle machine où ils s’identifient avec ce profil.
Si vous optez pour cette méthode de stockage, certains points sont à prendre en considération. Tout d’abord, même si vous indiquez que votre clé privée n’est pas exportable, certains outils sont capables de contourner cette protection (la non-exportabilité n’étant pas garantie à 100 %). De plus, si un tiers accède à votre compte Windows alors que vous n’aviez pas activé la protection forte de la clé privée (l’utilisation de votre certificat n’est, dans ce cas, pas soumise à la saisie d’un mot de passe), il peut tout à fait utiliser votre certificat. Enfin, si votre clé privée est marquée comme étant exportable, rien n’empêche un autre utilisateur sur votre machine de l’exporter. En effet, même avec l’option de protection de la clé privée activée, cet utilisateur n’aurait pas à saisir de mot de passe pour exporter la clé.
Dernière remarque, Chrome et Internet Explorer utilisent le magasin de certificats Windows (Windows Certificate Store), tandis que Firefox utilise son propre magasin de certificats (fourni par Mozilla). En clair, si vous importez votre certificat dans le magasin Windows, Chrome et IE le trouveront automatiquement, mais pas Firefox.
Principales utilisations :
- Les applications de signature numérique (Adobe Acrobat, Microsoft Outlook et Office rechercheront dans le magasin de certificats [utilisateur] Windows).
- Microsoft IIS (serveur Windows) recherche également les certificats SSL dans le magasin de certificats [machine] Windows.
- Suivant la façon dont elle est configurée, l’authentification client (utilisateur ou machine) recherche principalement dans le magasin de certificats Windows.
- La signature de code Windows (pour la signature d’applications ou de pilotes).
Fichiers .pfx et .jks (magasins de clés)
Les fichiers PKCS#12 (.pfx ou .p12) et .jks* (créés par l’outil de création de clés Java) contiennent votre paire de clés publiques/privées. Contrairement aux magasins de clés des systèmes d’exploitation et navigateurs stockés en local, ces fichiers peuvent être stockés quasiment n’importent où, y compris sur les serveurs distants. Ils sont par ailleurs toujours protégés par mot de passe (ainsi, à chaque fois que vous souhaitez utiliser votre clé privée, vous devez saisir un mot de passe). Autre avantage : comme il s’agit de simples fichiers, vous pouvez facilement distribuer plusieurs copies si plusieurs personnes ont besoin d’utiliser le certificat.
Si vous décidez de stocker votre fichier sur un serveur distant, pensez à limiter l’accès à ce serveur. Une personne qui s’y introduirait pourrait en effet utiliser votre certificat. De même, méfiez-vous de la facilité avec laquelle ces fichiers peuvent être dupliqués et distribués. Au-delà de l’aspect pratique, une personne malintentionnée qui accéderait à votre magasin de clés pourrait sans difficulté en faire une copie et l’emporter. Mais pour utiliser la copie du fichier, le mot de passe de la clé privée reste nécessaire. D’où l’intérêt d’utiliser des mots de passe forts comportant plus de 15 caractères, et mélangeant minuscules, majuscules, chiffres et caractères spéciaux. Autre aspect à prendre en considération : cette option de stockage fait peser de lourdes responsabilités sur les épaules de l’utilisateur final, qui décide alors de l’emplacement du fichier et des conditions de stockage.
Si vous ne pouvez utiliser ni équipement cryptographique ni magasin de clés Windows (décrit plus haut), mais que vous souhaitez renforcer la sécurité (au lieu de vous contenter d’un fichier de stockage des clés sur votre machine), vous pouvez stocker ces fichiers sur une clé USB que vous conserverez en lieu sûr. Si vous avez beaucoup de documents à signer, cette solution manquera de commodité ; vous préférerez alors conserver le fichier en local pour y accéder plus facilement.
Principales utilisations :
- Signature de code Windows ou Java.
- Le portail ESG (Electronic Submission Gateway) de la FDA et l’IDES (Service International d’Echange de Données ) de l'IRS (fisc américain) utilisent tous deux les fichiers .pfx pour sécuriser les communications avec les services publics.
- Certains serveurs Web (ex. : Apache Tomcat ou Jboss).
*Note : Java semblerait avoir prévu d’évoluer du JKS au PKCS#12 pour ses magasins de clés par défaut, mais aucune date de lancement n’a encore été annoncée.
Clés et cartes à puce (smartcard) cryptographiques
Comme indiqué plus haut, le stockage de votre clé privée sur un support matériel offre un niveau de sécurité renforcée. Il y a cependant une grande différence entre les clés et cartes à puce cryptographiques, et les dispositifs de stockage amovibles ou autres clés USB standard. Avec un module matériel cryptographique, la clé est générée sur le matériel lui-même et ne peut être exportée. En clair, la clé privée ne quitte jamais le module, ce qui complique fortement les tentatives d’accès et de compromission.
Remarque : pour renforcer la sécurité d’une clé privée générée ailleurs que sur le matériel cryptographique, il suffit d’importer un fichier .pfx sur celui-ci, puis de supprimer le .pfx original.
L’utilisation d’une clé cryptographique exigera la saisie d’un mot de passe chaque fois que vous voudrez utiliser votre certificat. Par conséquent, si votre clé tombe dans les mains d’un tiers, celui-ci aura besoin de votre mot de passe pour l’utiliser. Le stockage de votre clé sur un matérial cryptographique vous permet d’utiliser sans risque un même certificat sur plusieurs machines, sans avoir à en faire plusieurs copies ni à réitérer la procédure d’import/export. Les modules matériels de cryptographie peuvent également vous aider à respecter les normes FIPS requises par certaines réglementations sectorielles et publiques.
D’autres points devront, bien entendu, être pris en compte si vous optez pour cette voie… vous avez tiqué la première fois que j’ai prononcé le terme « matériel » ? Hormis la gestion des clés, sachez que cette méthode risque de ne pas fonctionner avec les builds automatisés, car on vous demandera de saisir un mot de passe à chaque fois que le certificat sera utilisé. Il n’y a par ailleurs aucun moyen de sauvegarder le certificat puisque la clé privée ne peut être exportée (c’est le revers de cette sécurité renforcée). Enfin, cette solution de stockage risque de ne pas être adaptée à certains scénarios marginaux — notamment avec certaines appliances spécifiques qui ne prennent pas en charge les clés ou les cartes à puce, ou lorsque les employés ne peuvent physiquement accéder à l’ordinateur, mais utilisent un terminal distant.
Principales utilisations :
Generally, all use cases mentioned above for OS/browser keystores (Document Signing, Code Signing, Client Authentication, Windows IIS) are supported by crypto tokens or smart cards - as long as there’s a driver on the crypto token that can make a connection to your OS/browser certificate store, it can serve the same purpose. However, this might not always be practical (e.g. webservers, automated build processes for code signing that require a password each time a signature is applied).
En général, tous les cas d’utilisation de magasins de clés des systèmes d’exploitation/navigateurs évoqués précédemment (signature de documents, signature de code, authentification client, Windows IIS) sont pris en charge par les cartes à puce ou les clés cryptographiques. La condition ? Le module cryptographique doit comporter un pilote permettant d’établir la connexion avec le magasin de certificats de votre système d’exploitation/navigateur. Ce mode de fonctionnement risque cependant de se révéler peu commode (les serveurs Web et les processus de build automatisés exigeront, pour la signature de code, un mot de passe à chaque fois qu’une signature est appliquée). Pourquoi utilise-t-on des clés cryptographiques ? Essentiellement pour respecter les exigences de conformité, ces clés étant :
- requis pour la signature de code à validation étendue (EV), conformément aux recommandations du CA/Browser Forum ;
- recommandés pour la signature de code standard, conformément aux exigences minimales du conseil de sécurité des autorités de certification. Les autorités de certification ont l’obligation de recommander un module cryptographique matériel comme première option d’émission. Si le certificat n’est pas délivré sur un module matériel cryptographique, l’autorité de certification doit demander au client de confirmer qu’il stockera la clé privée sur un dispositif matériel amovible (qui sera retiré lorsqu’aucun processus de signature n’est en cours) ;
- requis pour garantir la confiance publique des signatures numériques dans les produits Adobe, conformément aux exigences de la liste AATL (Adobe Approved Trust List).
- certaines réglementations sectorielles spécifiques, comme le Titre 21 du Code of Federal Regulations (CFR) de la Food and Drug Administration (FDA) et les exigences du bureau fédéral des ingénieurs en matière de signatures numériques, exigent souvent que la clé privée soit conservée par son propriétaire, et uniquement par celui-ci. Le stockage sur un module matériel cryptographique répond à ces exigences.
Modules matériels de sécurité (HSM)
Les modules HSM offrent une alternative intéressante pour le stockage des clés sur un support matériel cryptographique. Cette solution mérite d’être étudiée, si vous ne souhaitez pas dépendre exclusivement des clés, ou que leur manque de commodité vous rebute. Alors que les clés semblent plus adaptées aux utilisateurs finaux pour des applications manuelles ou ponctuelles (signature de volumes inférieurs de documents ou de code, authentification sur des VPN ou d’autres réseaux), les modules HSM, qui utilisent des API, peuvent prendre en charge des workflows et des builds automatisés. Ils permettent également de respecter les normes de conformité FIPS et sont souvent mieux classés que les clés.
Généralement, ces modules HSM sont des appliances physiques que l’on trouve sur site. Ils mobilisent des ressources internes à la fois pour les administrer et pour contrôler leur conformité avec les exigences de base et les SLA. Leurs coûts élevés et la consommation importante de ressources ont parfois freiné leur adoption par le passé. Heureusement, l’émergence ces dernières années de modules HSM basés dans le cloud offre les avantages propres aux modules HSM sur site, sans les contraintes d’une maintenance en interne.
Peut-être avez-vous entendu parler du coffre-fort de clés Microsoft Azure qui permet de protéger vos clés cryptographiques dans le module HSM Microsoft basé dans le cloud. Une petite entreprise n’a pas toujours la capacité d’acheter et de gérer ses propres modules HSM. Si c’est votre cas, cette solution – qui peut par ailleurs être intégrée avec certaines AC publiques comme GlobalSign – pourra vous convenir.
Si la signature de documents vous intéresse, vous avez probablement entendu parler de notre nouveau service de signature numérique qui utilise aussi des modules HSM cloud pour le stockage des clés privées. Notez également au passage que ce nouveau service prend en charge les identités de signature individuelles. Auparavant, dans la plupart des scénarios de signature numérique à base de modules HSM, on ne pouvait utiliser qu’une identité au niveau du « département » ou de l’« entreprise » (ex. : Comptabilité, Marketing, Finance…), et non une identité par individu (exemple. Jean Dupont). Concrètement, les entreprises qui avaient besoin d’identifiants pour leurs employés devaient se contenter de clés, dont la gestion peut se révéler assez problématique comme nous l’avons vu plus haut. Avec ce nouveau service, vous pouvez activer des signatures numériques par employé sans avoir de matériel à gérer (et sans crainte que vos employés perdent leur module matériel).
Sécuriser les documents internes dans les services financiers
Principales utilisations :
- Importants volumes de signatures de documents ou de code
- SSL (suivant la configuration serveur)
- Infrastructure d’AC pour l’exécution d’une AC maison (AC racine, AC secondaire, serveur d’horodatage RFC 3161) — l’une pourra être hors ligne, et l’autre en ligne (l’AC racine étant généralement hors ligne)
Prospective : les modes de stockage de clés nouvelle génération
Les options de stockage de clés évoquées plus haut sont des méthodes traditionnelles utilisées depuis des années. Manifestement, comme tout ce qui touche à la sécurité informatique, l’Internet des Objets (IoT) exerce également une influence sur le stockage des clés. De nouvelles solutions idoines voient donc le jour.
Devant la prolifération d’appareils en ligne qui doivent pouvoir s’authentifier et communiquer en toute sécurité, les développeurs et fabricants sont nombreux à se tourner vers les solutions à base d’infrastructure de clés publiques (PKI). Ces solutions font naître de nouvelles réflexions, exigences et technologies pour la protection des clés privées. Voici les deux tendances que nous avons vu émerger.
Modules plateforme de confiance (TPM, Trusted Platform Modules)
Les TPM ne sont pas nouveaux, mais leur utilisation pour protéger les clés privées s’est généralisée. Un TPM peut être utilisé pour stocker (envelopper) la clé racine et protéger les autres clés créées par une application. Les clés de l’application ne peuvent être utilisées sans le TPM, ce qui en fait une méthode d’authentification très utile pour les terminaux (type ordinateurs portables et serveurs), mais aussi pour les fabricants d’objets connectés. Si de nombreux ordinateurs portables intègrent aujourd’hui des modules TPM, leur usage en entreprise est encore loin d’être généralisé. On les retrouve cependant en nombres dans l’IoT où ils servent de racine de confiance matérielle pour sécuriser l’identité des appareils.
L’Internet des Objets a engendré une difficulté supplémentaire : avec autant d’objets communiquant de manière anonyme entre eux, les hackers n’ont aucune peine à intercepter les communications ou à se faire passer pour ces appareils. Il est toutefois possible d’introduire une puce en amont du processus de fabrication, afin de l’utiliser pour protéger la clé cryptographique de l’appareil et son identité.
Pendant la fabrication, l’appareil génère une paire de clés privées et publiques. La clé publique est envoyée à l’autorité de certification pour la signature et l’émission d’un certificat numérique. La clé privée ne quitte jamais l’appareil ; elle est stockée de manière sécurisée sur la puce et ne peut être ni exportée, ni copiée, ni détruite. Le certificat est désormais l’identité de l’appareil, et la clé privée protégée constitue sa racine de confiance matérielle.
Nous avons travaillé en étroite collaboration avec notre partenaire Infineon sur le développement de solutions IoT associant l’identité des appareils basée sur une PKI avec des racines de confiance sur TPM. Pour en savoir plus, n’hésitez pas à consulter notre preuve de concept : Securely authenticating to and controlling hardware using GlobalSign's cloud-based Certificate Services and Infineon's OPTIGA™ TPM.
Fonctions physiques inclonables (PUF, Physically Unclonable Functions)
La technologie des fonctions physiques inclonables (PUF) représente un changement de paradigme pour la protection des clés. Au lieu de stocker les clés (ce qui les rend vulnérables aux attaques physiques), les clés sont dérivées des propriétés physiques uniques de la mémoire SRAM d’une puce et n’existent qu’à l’allumage. Ainsi, au lieu de stocker la clé privée de manière sécurisée, la clé peut-être régénérée plusieurs fois à la demande (pendant toute la durée de vie de l’appareil). L’utilisation d’une PUF SRAM offre la garantie d’avoir des clés uniques puisqu’elles utilisent les particularités de l’état aléatoire des bits d’un bloc de SRAM.
En conjonction avec un environnement d’exécution de confiance (TEE, Trusted Execution Environment), la technologie PUF apporte une réponse attrayante aux besoins du marché en solutions de protection des clés à la fois économiques, faciles à intégrer et ultra sécurisées. L’association de la technologie PUF avec les infrastructures PKI permet d’obtenir une solution d’identité complète.
Notre partenaire Intrinsic ID a créé un système d’assignation des clés de ce type à base d’une PUF SRAM. Ce système produit des identités matérielles qui s’apparentent à des empreintes digitales ancrées dans le matériel, et présentent les caractéristiques d’être uniques, inviolables et inclonables. Nos services de certification permettent d’ensacher ces empreintes digitales dans les identités numériques et d’y ajouter des fonctionnalités de PKI. Au final, chaque appareil se retrouve doté d’une paire de clés uniques et inclonables qui ne sont pas stockées sur l’appareil lorsque celui-ci est éteint. La même clé peut cependant être régénérée à la demande. Cela protège l’appareil (et la sécurité de ce dernier) contre les attaques, mêmes lorsque celui-ci est éteint.
Pour en savoir plus sur notre solution conjointe d’identité matérielle dans l’IoT, visionnez notre dernier Webinaire : Strong Device Identities through SRAM PUF-based Certificates.
Ne perdez pas les clés (privées) de votre château !
Le stockage des clés privées n’a pas à relever d’un art occulte. La meilleure solution pour vous dépendra in fine des utilisateurs de certificats et de la finalité d’utilisation, des réglementations de conformité, des coûts, de votre environnement actuel et des ressources disponibles en interne. J’espère que ce billet vous aidera dans vos choix.
Vous avez des questions sur l’une des méthodes présentées ci-dessus ou avez besoin d’aide pour choisir la méthode la mieux adaptée à vos besoins ? Appelez-nous !
