Comment sécuriser la clé privée de votre CA?

24

Je suis sur le point d'implémenter ma propre autorité de certification (CA) pour un usage interne uniquement.

Maintenant, il y a un problème, à savoir que la CA privée ne doit jamais être exploitée. Donc, en ce moment, la clé privée est cryptée.

Que pourrait-on faire d'autre pour améliorer la sécurité de la clé privée?

security certificate-authority private-key

— JMW
source

Pouvons-nous obtenir le système d'exploitation sur lequel vous exécutez le serveur Web? Vous pourriez probablement définir les autorisations sur le fichier afin qu'il ne soit pas lisible par quiconque, sauf par l'application ainsi que le superutilisateur.

— Rilindo

nous courons RHEL

— JMW

25

J'ai travaillé dans une entreprise où la sécurité de la clé CA était essentielle au succès continu de l'entreprise. À cette fin, la clé a été chiffrée à l'aide d'un protocole personnalisé qui nécessitait qu'au moins 2 personnes soient présentes avec des jetons physiques connectés aux terminaux pour la déchiffrer (il y avait au moins 5 de ces jetons, 2 combinés fonctionneraient). Les terminaux ont été physiquement séparés de la machine réelle avec la clé CA. L'interface dont disposaient les utilisateurs qui l'ont décryptée était un terminal VT220 qui leur permettait de saisir les jetons de décryptage puis de sélectionner ce qu'ils voulaient `` signer '' avec la clé (sans jamais leur donner accès à la clé décryptée). Ce système signifiait qu'au moins 4 personnes devraient travailler ensemble pour compromettre la clé, deux détenteurs de jetons, le gars qui avait accès au centre de données,

Si vous êtes intéressé par plus de détails sur ce type de configuration, Bruce Schneier a un excellent site couvrant la conception et la mise en œuvre de la sécurité informatique:

http://www.schneier.com/

Il a également publié un très bon livre Applied Cryptography qui m'a aidé à comprendre les principes fondamentaux de systèmes comme celui-ci et à concevoir des infrastructures plus sécurisées (lisibles par les personnes qui ne portent pas de protège-poche):

http://www.schneier.com/book-applied.html

— polynôme
source

2

Et le fonctionnement à deux touches (ou n'importe quel n de m, m> = n, n> 1) est une autre excellente précaution - mais pour mon argent, laissez d'abord un espace, et ajoutez des raffinements comme celui-ci en fonction de votre degré de paranoïa (c.-à-d. le coût de l'échec).

— MadHatter prend en charge Monica le

1

Pourquoi la personne avec un accès root ne peut-elle pas vider le contenu de la mémoire dans un fichier pendant que deux personnes autorisées font leur travail? Cela signifie que le gars avec root peut obtenir la clé avec seulement les ressources supplémentaires nécessaires pour obtenir le vidage de mémoire de la machine.

— Slartibartfast

Le contrôle d'accès physique audité est aussi important pour ce type de sécurité que le contrôle d'accès logique audité. L'opération de signature ne devrait pas nécessiter de privilège sur la boîte (ce contrôle est géré par l'exigence any-n-from-m), donc le détenteur du mot de passe root ne devrait pas être là du tout lorsque la signature de clé est en cours. (S) il sera nécessaire pour les activités de maintenance du système, mais celles-ci doivent être effectuées selon un script pré-écrit précis, par une personne autre que le scénariste, et auditées en temps réel par un tiers compétent.

— MadHatter prend en charge Monica le

16

Un gros avantage est de garder la clé CA privée sur un ordinateur dédié complètement coupée du réseau. Vous devez ensuite signer et éventuellement générer de nouveaux certificats sur cette machine, puis utiliser un support physique pour transférer les nouveaux certificats hors de la machine CA.

Une telle configuration inclurait bien sûr également des considérations concernant la disponibilité physique de la machine, ainsi que des restrictions sur les médias autorisés. Une clé USB bien voyagée n'est probablement pas le meilleur choix ...

(C'est d'ailleurs un exemple très clair du compromis entre sécurité et commodité.)

— andol
source

Airgap est une excellente précaution de sécurité, et le danger des supports amovibles peut être atténué en définissant la case de signature pour ne rien exécuter automatiquement, autoriser les binaires SUID ou de toute autre manière faire confiance aux exécutables sur ces supports.

— MadHatter prend en charge Monica le

Cela peut être encore optimisé en utilisant une carte à puce pour générer, stocker et utiliser la clé. Considérez une carte à puce comme une machine dédiée dotée de certaines protections contre la falsification (en gros, la puce préfère casser plutôt que de renoncer à la clé, ce qui est difficile à faire avec un système plus complexe) et qui a une interface suffisamment simple pour que le la pile de protocoles aurait pu être vérifiée correctement.

— Simon Richter le

J'appuie la suggestion de carte à puce, mais il y a un risque. Lorsque la clé ne peut se trouver qu'au même endroit, un seul élément matériel doit échouer pour rendre la clé inaccessible. Je pense qu'une ou plusieurs cartes à puce pourraient cependant constituer un élément important dans une pratique sécurisée de génération et de stockage de clés.

— Slartibartfast le

Concernant le problème de l'exécution automatique. Dans le cas d'un gestionnaire de fichiers gui, il peut également être conseillé d'être explicite à ce sujet en n'essayant pas de faire des aperçus / miniatures intelligents des fichiers répertoriés. Bien qu'il ne soit pas un danger en soi, il peut être un vecteur d'attaque pour les vulnérabilités existantes.

— andol

Si la sécurité est vraiment importante, j'irais avec un tas de CD-R à écriture unique.

— Lie Ryan

15

J'ai voté pour les deux autres réponses et commenté celles-ci, car je pense qu'elles sont toutes les deux excellentes. Si vous décidez d'opter pour les deux, et cela pourrait bien être approprié, je vous conseille vivement de faire attention à la génération initiale de la clé, car le meilleur moment pour compromettre une clé n'est pas utilisé (où de nombreuses précautions standard et reproductibles peuvent être appliqué) mais au moment de la génération, ce qui étant une fois unique est beaucoup plus facile à renverser.

Cet excellent guide pour la conduite d'une cérémonie de génération de clés décrit certains des protocoles standard qui peuvent aider à sécuriser la génération de clés, bien qu'ils se résument principalement à (a) faire en sorte que tout soit attesté par plusieurs auditeurs compétents, qui (b) font des enregistrements contemporains de tout ce qui est fait (c) selon un protocole prédéterminé écrit par une personne autre que l'exécuteur testamentaire.

— MadHatter soutient Monica
source

Yepp, bon point sur la génération de clé initiale.

— andol

7

En fonction de votre sérieux, vous devez envisager d'utiliser du matériel FIPS 140-2 ( http://en.wikipedia.org/wiki/FIPS_140#Security_levels ) pour stocker les clés CA et les sauvegardes de ces clés. Vous devez avoir une autorité de certification racine et une autorité de certification intermédiaire afin de pouvoir conserver votre autorité de certification racine hors ligne et sécurisée physiquement. La racine n'est nécessaire que pour renouveler ou signer de nouvelles autorités de certification intermédiaires, tandis que les autorités de certification intermédiaires restent en ligne pour les opérations quotidiennes. Comme d'autres l'ont suggéré, la génération et la gestion de clés sécurisées avec un contrôle n de m sont importantes.

Le VeriSign (maintenant Symantec) CPS est une bonne référence pour la façon dont une autorité de certification commerciale génère et protège ses clés. Regardez les chapitres 5 et 6, en particulier: http://www.verisign.com/repository/cps/ . (J'ai travaillé chez VeriSign pendant plusieurs années)

En outre, le NIST a plusieurs bonnes publications sur la gestion des clés ( http://csrc.nist.gov/publications/drafts/800-57/Draft_SP800-57-Part1-Rev3_May2011.pdf ) et la génération, et votre entreprise devrait également avoir un CPS qui spécifie les politiques et les pratiques que vous utilisez pour gérer votre autorité de certification. L'IETF fournit un bon modèle: http://www.ietf.org/rfc/rfc2527.txt

— Poiré
source

1

Grande question et quelques bonnes réponses aussi.

Gardez à l'esprit que vous avez environ 90% d'avance sur la plupart des autres personnes simplement en considérant ce problème plutôt qu'en chargeant aveuglément.

Ayant gardé cela à l'esprit et pris les autres conseils ici, j'ajouterais simplement: ne vous reposez pas sur vos lauriers; Gardez un œil sur l'actualité de la sécurité et de la cryptographie pour les problèmes généraux liés à la délivrance, à la révocation, au craquage de certificats, etc. et surtout aux vulnérabilités et problèmes liés aux produits spécifiques que vous utilisez pour générer et gérer vos clés.

Enfin: la sécurité physique. Faire quelque chose de «preuve de piratage» n'est d'aucune aide si je peux simplement obtenir un emploi de nettoyeur de contrat dans votre bâtiment et mettre un jour le disque contenant votre certificat racine dans ma poche. Vous seriez surpris du nombre de personnes qui manqueraient celui-là.

— Rob Moir
source

Heureux de l'entendre @jmw - comme je l'ai dit, vous êtes déjà en avance sur 90% ou peut-être même 99% de la plupart des gens, et il semble que vous ayez tout en main. Vous seriez choqué par le nombre de personnes qui passent des semaines et des tonnes d'argent à regarder le côté logiciel des choses sans rien faire pour sécuriser physiquement les données.

— Rob Moir

Merci, vous avez absolument raison: rester informé des nouveaux risques est obligatoire pour chaque administrateur. :-) sur la sécurité physique: le datacenter, où se trouvent nos serveurs, a une sécurité physique élevée. il y a donc des mots de passe bios && grub configurés. la partition où sont stockées les informations de l'AC est également chiffrée. en outre, la clé CA elle-même est cryptée. Et les nagios déclencheraient des alertes "serveur en panne" en cas de vol physique. Je suis plus préoccupé par les exploits "non physiques". :-)

— JMW