Les bonnes pratiques de la génération de bi-clé dans le cadre des certificats numériques

Le chiffrement repose sur la cryptographie symétrique. Dans un monde ouvert et connecté, la cryptographie asymétrique est nécessaire pour chiffrer des secrets, s’authentifier et signer numériquement. L’usage massif du protocole TLS et des certificats X509 amène à générer et utiliser un nombre croissant de paires de clés cryptographiques par les administrateurs pour les machines et les applications et pour les utilisateurs personnes physiques. La bi-clé ou paire de clés publique et privée, est la pierre angulaire de la confiance numérique.

Après avoir rappelé ce qu’est une bi-clé et à quoi elle sert, nous présenterons l’écart constaté entre les recommandations standards et les pratiques en entreprise. Aussi nous donnerons quelques guidelines sur la génération et le transport d’une bi-clé. Enfin nous présenterons comment une solution CLM peut aider à implémenter ces bonnes pratiques dans vos équipes.

La bi-clé : définition et usage

Une bi-clé ou paire de clé cryptographique est une suite de chiffres en deux parties logiques : la clé privée (gardée secrète) et la clé publique (diffusable à tous).

Ces chiffres ne sont pas choisis au hasard. Ils sont liés à des algorithmes de chiffrement/signature (comme RSA ou les courbes elliptiques). La taille de la clé augmente la robustesse des opérations cryptographiques (2048, 4096 bits).

Les bi-clés servent dans beaucoup de protocoles utilisés couramment dans les DSI dont notamment : S/MIME, GPG, EMV, IPsec, PGP, ZRTP, TLS / SSL, SILC, SSH mais également dans Bitcoin. Elles ont pour usage de chiffrer, signer numériquement, s’authentifier.

.Bi-clé et certificats numériques

Au sein des organisations, les objectifs de la sécurité informatique (comme l’intégrité de la donnée, la confidentialité, la non-répudiation des opérations) reposent sur la cryptographie, notamment asymétrique. Le chiffrement par protocole TLS, qui du Web arrive dans tous le SI par la généralisation d’approche type ZéroTrust, l’authentification par certificats et les approches password less, sont des gros consommateurs de moyens cryptographiques et de bi-clés.

L’autorité de certification, interne ou externe, signe et certifie le lien entre une paire de clé cryptographique et une identité numérique au travers de la délivrance d’un certificat numérique, le sésame.

Cette Identité numérique peut être celle d’une personne, morale ou physique, un nom de domaine, …

A l’origine du processus de demande ou de renouvellement de certificats numériques, la bi-clé et la CSR sont des ressources critiques encore trop peu encadrées par des processus clairs et sécurisés pour les demandeurs.

Risques et compromission de la bi-clé

Prenons l’exemple célèbre de la cryptomonnaie Bitcoin, qui est aussi le nom de la technologie de blockchain publique qui lui est associée. Dans Bitcoin et son idéologie libertaire, sans autorité de recouvrement, votre propriété de monnaie numérique, votre identité sur le réseau se résume à la seule possession d’une paire de clé cryptographique. Si on récupère votre clé privée, on vous dépossède de tous vos biens numériques sans espoir de recours. D’où le succès des Hardware wallet de type Ledger.

Une bi-clé compromise et c’est la fin de la confidentialité de vos opérations, de l’intégrité de certaines données et possiblement l’usurpation de votre identité numérique.

Afin de réduire le risque d’usurpation d’identité (certificat émis à tort ou malveillant), de compromission des échanges et des données, voyons les bonnes pratiques sur la génération, le transport et la protection des paires de clés (ou bi-clé) cryptographiques au sein des systèmes d’information.

Cas des certificats wildcard

Les certificats wildcard sont courants. Ils sont pratiques et permettent de faire des économies. Mais leur généralisation peut entrainer des risques importants si on ne porte pas attention à quelques règles.

Un certificat wildcard est un certificat TLS multi-identité ou du moins qui permet d’avoir une grande famille. Plus on multiplie les installations et instance de ce certificat, plus il faut copier et transporter la bi-clé associée à chaque serveur où il est déployé. Le transfert par email, non chiffré, le stockage en clair sur un système de fichier est encore trop fréquent. Si un serveur est compromis, tous les serveurs qui utilisent la même bi-clé ne seront plus protégés. (RecomImpactSystémique-1)

Comment générer sa paire de clé ?

On ne trouve pas cette information dans les articles de blog mais plutôt dans des docs de support, pour les intégrateurs et les développeurs, ect. Pourtant, c’est un point critique de votre sécurité informatique car ces clés doivent respecter des critères d’entropie élevés ou avoir passé des tests primalités sévères. Regardons deux façons de générer sa paire de clé :

Générer et stocker sa paire de clé dans un module sécurisé

(Re-)Présentons les HSM, Hardware Security Module, qui permettent aux organisations, notamment les tiers de confiances, de générer de manière sécurisée des assets cryptographiques et d’effectuer des opérations de type chiffrement, signature, en zone d’exécution protégée. (Nous ne parlerons pas dans cet article de génération de nombre aléatoire 😉). Ils permettent aussi la génération de clés de manières centralisées et sécurisées.

Bien que leurs gammes se soient enrichies pour répondre à une demande croissante, micro HSM, HSM as a service, nombre des assets cryptographiques restent générés de manière purement logiciel, notamment via les librairies type OpenSSL.

Pour le stockage sécurisé, Il y aussi les TPM, Trusted Platform Module dans nos PC ou l’utilisation de device externe, type Token (carte à puce, clé USB sécurisée).

Donc si vous êtes soumis à un référentiel de sécurité normatif, pas d’autre choix que d’utiliser des HSM pour la génération de clés et leur protection.

Certaines clés ne doivent jamais sortir, d’autres sont exportées de manière sécurisée et chiffrée pour être également stockée dans des supports sécurisés.

Générer sa paire de clé de façon logicielle

C’est une pratique très répandue mais pas forcément recommandée.

Pour renforcer la sécurité de clés générées de manière logicielle, il faut respecter des règles de « bonnes conduites », et se référer notamment au référentiel RGS.

Générer sa bi-clé localement (à l’endroit où elle sera utilisée) et limiter les export/transport de cette clé. D’ailleurs le concept de key attestation permet d’attester de la génération locale de la paire de clé. Générer localement et non importée. Ceci afin également de ne pas autoriser la copie de la clé.

Quelques règles de bonnes pratiques et recommandations ANSSI

1. Générer des clés en central, de manière sécurisée, assurer son transport et son stockage de manière chiffrée. (Règle-AcheminemementCléCentral-1)
2. Pas de clé en clair sur le système de fichier.
3. Pas de clé privée envoyée par simple email. (RecomDiffusion-1.)
4. Utilisation de formats chiffrés (type P12). (RègleAcheminemementCléCentral-1)
5. L’usage d’une clé doit être unique. (RègleUsage-1)

Vous pouvez consulter le RGS en cliquant ici

Renforcer sa conformité par l’usage d’un CLM étendu avec autorité de séquestre

Qu’est-ce qu’un CLM ? En quoi cela m’aide dans la génération des clés, des CSR et la demande de certificat ?

Les demandes de certificats numériques au sein des organisation sont hétérogènes. Des machines, des ingénieurs, des administrateurs d’applications, des techniciens, des prestataires, du personnel non-technique. Par conséquent tous les demandeurs ne peuvent ou ne savent proposer une CSR ou générer une bi-clé.

Ayant authentifié préalablement les demandeurs, une solution CLM, tel que BerryCert, va compléter les demandes de certificats en générant les bi-clés en central (RègleGénérationCentralisée-1) ou localement suivant le contexte, ainsi que les CSR, avant de les soumettre à l’officier d’enregistrement pour approbation (RègleEnrôlementIGC-1).

Une fois la demande validée et le certificat récupéré auprès de la PKI, BerryCert va mettre à disposition le certificat et la bi-clé associée, de manière sécurisée, comme un format P12.

Si vous utilisez un certificat widlcard et que BerryCert gère les hosts où il est déployé. Notre protocole propriétaire va générer en central et transporter la bi-clé de manière sécurisée soit de manière logicielle, soit dans un HSM auquel il est adossé.

BerryCert :

• Aide à détecter les certificats auto-signés en usage dans le SI. Ils ne sont pas révocables car non-émis par une AC. Toute compromission peut être désastreuse.
• Apporte aux équipes, utilisateurs et administrateurs une sécurité des processus et un gain de temps.
• Est votre autorité d’enregistrement déléguée et authentifie le demandeur d’une demande signée par une clé privée, de certificat. (RègleEnrôlementPrivatif-1).
• Permet, au travers de ses politiques d’émission, d’imposer le renouvellement de la clé cryptographique au moment du renouvellement de certificat. (RègleRenouvellement-1).
• Offre une fonction d’autorité de séquestre pour les clés générés en central. (RègleRecouvrement-1).

En conclusion

La bi-clé est un asset important de la sécurité informatique. La massification de l’usage des certificats numériques a un impact sur leur gestion. Attention à ne pas vouloir faire vite, simple et pratique et garder à l’esprit les enjeux en cas de compromission d’un asset cryptographique.

Il ne suffit pas uniquement de déployer une « root of trust » au sein de son organisation pour traiter complètement le sujet de la confiance dans les identités et les certificats numériques. Le processus amont de la demande de certificat, la génération de la bi-clé et de la CSR nécessite aussi une attention. Quelques règles de gouvernance et de bonnes pratiques permettent de donner un cadre plus sûr aux utilisateurs et administrateurs.

Là encore, notre solution BerryCert apporte des services complémentaires et essentiels à la bonne gestion des certificat numériques.