Question Comment sécuriser la clé privée de votre autorité de certification?


Je suis sur le point de mettre en œuvre ma propre autorité de certification (CA) pour un usage interne uniquement.

Il existe maintenant un problème, à savoir que le CA privé ne soit jamais exploité. Donc maintenant, la clé privée est cryptée.

Que pourrait-on faire de plus pour renforcer la sécurité de la clé privée?


23
2017-09-03 15:41


origine


Pouvons-nous obtenir le système d'exploitation sur lequel vous exécutez le serveur Web? Vous pouvez probablement définir les autorisations sur le fichier pour qu'il ne soit lisible par personne, à l'exception de l'application ainsi que du super-utilisateur. - Rilindo
nous courons RHEL - JMW


Réponses:


J'ai travaillé dans une entreprise où la sécurité de la clé de certification était essentielle au succès continu de l'entreprise. À cette fin, la clé a été chiffrée à l’aide d’un protocole personnalisé exigeant la présence de deux personnes au minimum, avec des jetons physiques branchés sur des terminaux pour la déchiffrer (il y avait au moins cinq de ces jetons, deux combinés combinés fonctionneraient). Les terminaux ont été physiquement séparés de la machine avec la clé CA. L'interface utilisée par les utilisateurs pour le déchiffrer était un terminal VT220 qui leur permettait de saisir les jetons de déchiffrement, puis de sélectionner ce qu'ils voulaient «signer» avec la clé (sans jamais leur donner accès à la clé déchiffrée). Ce système signifiait qu'au moins 4 personnes devaient travailler ensemble pour compromettre la clé, deux détenteurs de jetons, le gars ayant accès au centre de données et une autre personne disposant d'un accès root sur le serveur (car la clé déchiffrée n'était jamais stockée sur le serveur). le serveur uniquement en mémoire, vous ne pouvez pas simplement voler la boîte, et les personnes ayant la racine sur ce serveur spécifique ne sont pas autorisées à accéder au contrôleur de domaine).

Si vous souhaitez en savoir plus sur ce type de configuration, Bruce Schneier propose un site formidable consacré à 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 tels systèmes et à créer des infrastructures plus sûres (lisibles par des personnes qui ne portent pas de protège-poches):

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


25
2017-09-03 16:50



Et l’opération à deux touches (ou n’importe quel m parmi m, m> = n, n> 1) est une autre excellente précaution - mais pour mon argent, commencez par créer une pause et ajoutez des raffinements comme celui-ci, en fonction de votre degré de paranoïa (c.-à-d., le coût de l'échec). - MadHatter
Pourquoi la personne ayant un accès root ne peut-elle pas vider le contenu de la mémoire dans un fichier pendant que deux personnes autorisées effectuent leur travail? Cela signifie que le gars avec la racine peut obtenir la clé avec seulement les ressources supplémentaires nécessaires pour récupérer le vidage de la 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 doit pas nécessiter de privilège sur la boîte (ce contrôle est géré par l'exigence any-n-from-m), de sorte que le détenteur du mot de passe root ne devrait pas être là. du tout quand la signature des clés est en cours. Il est nécessaire pour les activités de maintenance du système, mais celles-ci doivent être effectuées selon un script écrit au préalable précis, par une personne autre que le scénariste, et auditées en temps réel par une tierce personne compétente. - MadHatter


Un gros avantage consiste à garder la clé de l'autorité de certification privée sur un ordinateur dédié complètement coupée du réseau. Vous pouvez ensuite signer et éventuellement générer de nouveaux certificats sur cette machine, puis utiliser un support physique pour transférer les nouveaux certificats de la machine de l'autorité de certification.

Une telle configuration inclurait bien sûr également des considérations relatives à la disponibilité physique de la machine, ainsi que des restrictions sur les supports autorisés. Une clé USB très fréquentée n'est probablement pas le meilleur choix ...

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


16
2017-09-03 15:59



Airgap est une excellente précaution de sécurité, et le danger des supports amovibles peut être atténué en configurant la zone de signature pour ne rien autoruner, ne pas autoriser les fichiers binaires SUID ou toute autre manière de confiance. exécutables sur de tels médias. - MadHatter
Cela peut encore être optimisé en utilisant une carte à puce pour générer, stocker et utiliser la clé. Pensez à une carte à puce comme une machine dédiée qui dispose de certaines protections contre la falsification (la puce préfère plutôt casser que d'abandonner 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
J'appuie la proposition de carte à puce, mais il y a un risque. Lorsque la clé ne peut se trouver qu’à un seul endroit, il ne faut qu’un seul élément matériel pour que la clé soit inaccessible. Je pense cependant qu'une ou plusieurs cartes à puce pourraient jouer un rôle important dans la génération sécurisée de clés et les pratiques de stockage. - Slartibartfast
En ce qui concerne le problème autorun. Dans le cas d’un gestionnaire de fichiers gui, il peut également être judicieux d’être explicite à propos de ne pas essayer de faire des aperçus intelligents / miniatures des fichiers listés. Bien qu'il ne s'agisse pas d'un danger en soi, il peut constituer un vecteur d'attaque pour les vulnérabilités existantes. - andol
Si la sécurité est vraiment importante, je choisirais une pile de CD-R non réinscriptibles. - Lie Ryan


J'ai voté pour les deux autres réponses et les commenter, car je pense qu'elles sont toutes les deux excellentes. Si vous décidez d'aller pour les deux, et cela pourrait bien être approprié, je fortement Conseillez des précautions lors de la génération initiale de la clé, car le meilleur moment pour compromettre une clé n'est pas utilisé (de nombreuses précautions standard et répétables peuvent être appliquées), mais au moment de la génération, il est beaucoup plus facile de subvertir le fait d'être unique.

Cet excellent guide pour mener une cérémonie de génération de clédécrit certains des protocoles standard qui peuvent aider à sécuriser la génération de clés, même s’ils se résument essentiellement à (a) la vérification de tous les éléments de vérification par de nombreux auditeurs compétents, qui (b) sont en train de consigner en temps réel tout ce qui est fait (c) protocole prédéterminé écrit par quelqu'un d'autre que l'exécuteur.


15
2017-09-03 17:35



Yepp, bon point sur la clé initiale gén. - andol


Selon votre niveau de gravité, vous devriez envisager d’utiliser la norme FIPS 140-2 (http://en.wikipedia.org/wiki/FIPS_140#Security_levels) du matériel pour stocker les clés de l’AC et les sauvegardes de ces clés. Vous devez disposer d'une autorité de certification racine et d'une autorité de certification intermédiaire pour pouvoir conserver votre autorité de certification racine en mode hors connexion et physiquement sécurisée. 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 n de m le contrôle est important.

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

En outre, le NIST publie 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 votre génération, et votre société doit également disposer d’un système de gestion de la configuration spécifiant les stratégies 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


7
2017-09-04 09:35





Excellente question et d'excellentes réponses aussi.

Gardez à l'esprit que vous avez une avance d'environ 90% sur la plupart des autres utilisateurs simplement en prenant en compte ce problème plutôt que de prendre des risques à l'aveuglette.

Ayant gardé cela à l'esprit et pris les autres conseils ici, je voudrais simplement ajouter: ne vous reposez pas sur vos lauriers; gardez un œil sur les actualités en matière de sécurité et de cryptographie, tant pour les problèmes généraux relatifs à l’émission de certificats, la révocation, le piratage, etc. que ce soit tout à fait sur les vulnérabilités et les 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 obtenir un emploi de nettoyeur de contrat dans votre bâtiment puis mettre un jour le disque contenant votre certificat racine dans ma poche. Vous seriez surpris de voir combien de personnes manquent celui-là.


1
2017-09-04 10:22



Heureux de l'entendre @jmw - comme je l'ai dit, vous avez déjà une avance de 90%, voire de 99% sur la plupart des gens, et vous avez tout à fait raison. Vous seriez choqué par le nombre de personnes qui passent des semaines et des tonnes d’argent à regarder le logiciel sans rien faire pour protéger physiquement les données. - Rob Moir
Merci, vous avez absolument raison: rester informé des nouveaux risques est obligatoire pour tous les administrateurs. :-) sur la sécurité physique: le centre de données, où se trouvent nos serveurs, a une sécurité physique élevée. ainsi, les mots de passe bios && grub sont configurés. la partition où sont stockés les fichiers de l'autorité de certification est également chiffrée. De plus, la clé de l’AC est cryptée. Et Nagios déclencherait des alertes "serveur en panne" en cas de vol physique. Je suis plus préoccupé par les exploits "non physiques". :-) - JMW