Où stocker la clé privée?
Supposons que je souhaite que certaines parties de mon logiciel soient cryptées. Par exemple, les informations d'identification pour une base de données, etc. J'ai besoin de stocker ces valeurs quelque part, mais le faire en texte clair permettrait à un attaquant d'obtenir facilement un accès non autorisé.
Cependant, si je crypte du texte en clair, où puis-je stocker la clé? Tout ce à quoi le logiciel a accès, un attaquant déterminé aurait accès, quel que soit le niveau d'obscurcissement:
- Supposons que la clé est protégée par le modèle de sécurité du système de fichiers; mais qu'en est-il des superutilisateurs (malveillants) ou des plateformes qui n'offrent pas une telle fidélité?
- Ou la clé est codée en dur dans des binaires logiciels, mais elle pourrait toujours être décompilée et qu'en est-il des logiciels open source ou du code interprété?
- Si la clé est générée, un tel algorithme devrait être déterministe (vraisemblablement), puis le même problème s'applique à la graine.
- etc.
La cryptographie n'est aussi solide que le maillon le plus faible de sa chaîne et cela semble assez lâche! En supposant que c'est le bon outil pour le travail (faites-moi plaisir), alors comment sécuriser ces informations de manière robuste?
Concernant le bon outil pour le travail: Probablement, dans - par exemple - le cas de l'accès aux services (bases de données, serveurs d'authentification, etc.), vous restreindriez l'accès à ce niveau avec un compte de service, peut-être avec un certain niveau de service l'audit, etc. et donc avoir les informations d'identification en texte clair n'est pas une telle inquiétude.
Cependant, cela me semble encore insuffisant: je ne veux pas que quelqu'un fouille là où il ne devrait pas être!
Tout d'abord, je ne me considérerais pas comme un expert en sécurité, mais j'ai été en mesure de répondre à cette question. Ce que j'ai découvert m'a un peu surpris: Il n'existe pas de système complètement sécurisé. Eh bien, je suppose qu'un système complètement sécurisé serait celui où les serveurs sont tous éteints :)
Quelqu'un qui travaillait avec moi à l'époque a décrit la conception d'un système sécurisé en termes de élever la barre aux intrus. Ainsi, chaque couche de sécurisation diminue la possibilité d'une attaque.
Par exemple, même si vous pouviez parfaitement sécuriser la clé privée, le système n'est pas complètement sécurisé. Mais, utiliser correctement les algorithmes de sécurité et être à jour avec les correctifs relève la barre. Mais, oui, un super ordinateur suffisamment puissant et disposant de suffisamment de temps peut casser le chiffrement. Je suis sûr que tout cela est compris, je vais donc revenir à la question.
La question est claire, je vais donc essayer d'aborder chacun de vos points:
Supposons que la clé est protégée par le modèle de sécurité du système de fichiers; mais qu'en est-il des superutilisateurs (malveillants) ou des plateformes qui n'offrent pas une telle fidélité?
Oui, si vous utilisez quelque chose comme Windows Key Store ou une clé privée TLS chiffrée par mot de passe, vous êtes exposé aux utilisateurs qui ont le mot de passe (ou l'accès) aux clés privées. Mais je pense que vous conviendrez que cela met la barre plus haut. Les listes de contrôle d'accès du système de fichiers (si elles sont implémentées correctement) offrent un assez bon niveau de protection. Et vous êtes en mesure de vérifier personnellement et de connaître vos super utilisateurs.
Ou la clé est codée en dur dans des binaires logiciels, mais elle pourrait toujours être décompilée et qu'en est-il des logiciels open source ou du code interprété?
Oui, j'ai vu des clés codées en dur dans les binaires. Encore une fois, cela élève un peu la barre. Quelqu'un qui attaque ce système (s'il s'agit de Java) doit comprendre que Java produit du code d'octets (etc.) et doit comprendre comment le décompiler, lisez-le. Si vous utilisez un langage qui écrit directement pour le code machine, vous pouvez voir que cela élève la barre un peu plus haut. Ce n'est pas une solution de sécurité idéale, mais pourrait fournir un certain niveau de protection.
Si la clé est générée, un tel algorithme devrait être déterministe (vraisemblablement), puis le même problème s'applique à la graine.
Oui, essentiellement, l'algorithme devient alors les informations de clé privée pour créer la clé privée. Il faudrait donc maintenant le protéger.
Donc, je pense que vous avez identifié un problème central avec toute politique de sécurité, la gestion des clés . La mise en place d'une politique de gestion des clés est essentielle pour fournir un système sécurisé. Et, c'est un sujet assez large .
La question est donc de savoir à quel point votre système (et, par conséquent, la clé privée) doit-il être sécurisé? À quelle hauteur, dans votre système, la barre doit-elle être relevée?
Maintenant, si vous êtes prêt à payer, il y a des gens qui proposent des solutions. Nous avons fini par utiliser un HSM (Hardware Security Module) . Il s'agit essentiellement d'un serveur inviolable qui contient une clé matérielle. Cette clé peut ensuite être utilisée pour créer d'autres clés utilisées pour le chiffrement. L'idée ici est que (si elle est configurée correctement), la clé ne quitte jamais le HSM. Les HSM coûtent beaucoup. Mais dans certaines entreprises (la protection des données de carte de crédit, disons), le coût d'une violation est beaucoup plus élevé. Donc, il y a un équilibre.
De nombreux HSM utilisent des cartes-clés de maintenance et d'administration des fonctionnalités. Un quorum de cartes-clés (disons 5 sur 9) doit être physiquement inséré dans le serveur afin de changer une clé. Donc, cela élève la barre assez haut en n'autorisant une brèche que si un quorum de super utilisateurs collusion.
Il existe peut-être des solutions logicielles qui offrent des fonctionnalités similaires à un HSM, mais je ne suis pas au courant de ce qu'elles sont.
Je sais que cela ne fait que répondre à la question, mais j'espère que cela vous aidera.
Ce que vous voulez ne peut pas être fait.
Supposons que la clé est protégée par le modèle de sécurité du système de fichiers; mais qu'en est-il des superutilisateurs (malveillants) ou des plateformes qui n'offrent pas une telle fidélité?
Vous voulez essentiellement une protection contre les personnes malveillantes. Dans votre modèle, à un moment donné, quelqu'un aura accès à la clé. Et si cette personne est malveillante? Et si VOUS êtes malveillant? Vous voyez, le problème comme vous le dites est insoluble, sauf en n'ayant pas du tout de clé.
Ne travaillez donc pas avec les informations d'identification de la base de données, mais avec d'autres mécanismes d'authentification. Mais quoi qu'il arrive, quelqu'un à un moment donné a besoin d'accéder aux données et que quelqu'un peut être malveillant.
C'est l'un de ces problèmes qui ne peut pas vraiment être résolu au même niveau qu'il a été créé. Nous devrons revenir en arrière sur quelques philosophies fondamentales et suivre la cascade dans l'espoir d'une résolution.
La première philosophie est de "ne jamais faire confiance au client" et la relation étroite "si vous voulez vraiment garder un secret, ne le dites à personne!"
Un exemple simple est les informations d'identification de la base de données, comme vous l'avez mentionné. De toute évidence, vous voulez que votre client y ait accès, mais pas tout étranger Internet aléatoire, vous avez donc besoin d'une sorte de système d'identité/de vérification/de connexion. Mais le principe de base de la dissimulation est un problème: si l'utilisateur lui-même doit posséder un secret, mais que vous ne voulez pas qu'il sache ce qu'est ce secret, tout ce que vous pouvez faire est de le cacher ou de le rendre difficile à ouvrir " le paquet secret ". Mais ils peuvent toujours le savoir, alors vous feriez mieux d'avoir un plan de sauvegarde!
La solution la plus simple est "ne fais pas ça". Utilisez les informations d'identification du compte de l'utilisateur pour autoriser l'accès au niveau client à la base de données pour le logiciel, et c'est tout. Si le client devient malveillant, le pire des cas devrait être que le client puisse bousiller ses propres données. C'est ça. Votre base de données et votre système devraient maintenant, au plus, contenir des entrées indésirables de ce client, uniquement pour ce client, sans que personne d'autre (vous y compris) ne souffre du chaos.
Il existe des cas d'utilisation spécifiques où vous voulez simplement que les logiciels déployés fassent quelque chose mais que tout le monde ne puisse pas se connecter et faire les mêmes choses, mais pour cela, vous ne cachez que des secrets et la seule bonne raison de le faire est simplement de réduire les maux de tête ou l'activité du système. Si vos informations cachées deviennent de notoriété publique, il vaut mieux ne pas casser le jeu, au pire ennuyeux.
Si vous êtes dans l'un de ces cas d'utilisation étroits, il s'agit simplement d'obscurcissement, qui consiste à faire preuve de créativité. C'est un peu comme Code Golf, vraiment - sauf que c'est vous qui créez le puzzle. C'est tout ce que c'est vraiment - un puzzle. Et les gens aiment résoudre des énigmes, alors encore une fois, il vaut mieux être ok quand quelqu'un le comprend.
Mais pour la majorité des choses dans le monde, il est préférable de fonctionner sans se soucier d'avoir à garder un secret de l'utilisateur. Au lieu de cela, la meilleure pratique consiste à simplement laisser l'utilisateur découvrir le secret, à se donner la responsabilité de le protéger (son nom d'utilisateur et son mot de passe, par exemple) et à limiter le risque de ce qui se passe si le secret est divulgué ou est utilisé de manière abusive.
Dans de véritables contextes cryptographiques/de sécurité de "gestion des clés", la réponse "où stocker la clé privée" est "ailleurs!" Le chiffrement est une protection point à point, et le chiffrement par clé publique-privée est conçu pour protéger les informations en transit dans le temps et l'espace. La clé privée est intrinsèquement vulnérable, et la protéger n'est pas vraiment une question de chiffrement qui se chevauchent - elle la protège complètement contre l'accès. Et si le système doit y accéder, le système lui-même doit être sécurisé - et vous ne pouvez pas le faire sur la machine d'un client. Ils peuvent toujours exécuter une machine virtuelle, vider la RAM, renifler leur trafic réseau, installer un proxy ou une carte réseau virtuelle, décompiler les exécutables ... ne vous impliquez pas volontairement dans cette bataille perdue.
Maintenant, si vous devez faire quelque chose comme DRM, où votre besoin de stocker un secret est en fait basé sur le contrôle de l'utilisation du logiciel lui-même, c'est une autre situation entièrement .
TLDR: Ne gardez pas les secrets de l'utilisateur, gardez les secrets AVEC l'utilisateur.
L'un des systèmes que j'utilise actuellement fonctionne de cette façon.
- Je commence par un formulaire de connexion du service d'authentification. Il utilise une authentification à deux facteurs pour s'assurer que je suis bien ce que je prétends être.
- Je reçois un certificat SSL temporaire que je peux utiliser pour accéder au service protégé. Le service conserve une trace des certificats qu'il accepte.
- Mes échanges sont cryptés par ce certificat contre les écoutes. Essayer de le casser n'est pas très utile car il expirera.
- Le certificat expire rapidement (dans plusieurs heures), mais pas trop rapidement pour que je n'ai pas besoin de fournir un mot de passe pour chaque interaction.
- Le certificat peut être révoqué instantanément de l'autre côté.
Bien sûr, le service protégé est quelque part hors de ma portée. Il pourrait s'exécuter sur ma machine sous un autre compte (et éventuellement dans un conteneur), mais j'ai des privilèges de superutilisateur et je pourrais alors essayer de contourner les restrictions.
Fondamentalement, si vous avez un superutilisateur malveillant, tous les paris sont désactivés. Et vous devriez supposez la présence d'un superutilisateur malveillant dans votre modèle de menace.
Vous devez donc isoler votre service protégé de la machine accessible au client. Déplacez le service protégé vers une machine accessible uniquement via le réseau. Placez vos clients sur des machines virtuelles qui les empêchent d'atteindre le reste de la machine physique sur laquelle s'exécute votre service protégé.
Si votre service protégé n'est pas assez précieux pour pouvoir commander de telles mesures, optez pour le magasin de clés cryptées que le système d'exploitation vous offre: Windows, Linux et OSX ont tous deux des implémentations de porte-clés.