Une application très sensible doit protéger plusieurs formes de données différentes, telles que les mots de passe, les cartes de crédit et les documents secrets - et les clés de cryptage, bien sûr.
Comme alternative au développement d'une solution personnalisée autour du chiffrement (standard) et des processus de gestion des clés, l'achat d'un HSM ( module de sécurité matériel ) est à l'étude.
Évidemment, cela dépendrait (au moins en partie) de l'application, de l'entreprise, des types de données, des technologies et du budget spécifiques - mais je voudrais garder ce générique, donc je le laisse à un niveau élevé et j'ignore un workflow.
Supposons simplement qu'il existe des données secrètes qui doivent être chiffrées, et nous recherchons des solutions matérielles pour gérer la complexité et l'insécurité probable de la gestion des clés sur mesure, et atténuer les menaces évidentes contre le chiffrement et les clés basés sur logiciel.
Quels sont les facteurs et critères à prendre en compte lors de la comparaison et de la sélection d'un HSM? Et quelles sont les considérations pour chacun?
Par exemple:
POUR ÊTRE CLAIR : Je ne cherche PAS ici des recommandations de produits, plutôt juste pour savoir comment évaluer tout produit spécifique. N'hésitez pas à nommer les produits dans les commentaires, ou mieux encore dans le chatroom ...
Quelques facteurs techniques qui peuvent être pertinents:
Quelques facteurs non techniques:
Il y en a probablement beaucoup plus.
L'institut SANS a un bon article d'introduction décrivant pourquoi vous pourriez vouloir un HSM, les attributs positifs qu'il (devrait) avoir et certains des inconvénients.
Il semble qu'un fournisseur HSM soit d'accord avec la plupart de cette liste et ait produit sa propre version (non attribuée) version de celle-ci .
Un HSM n'évitera pas la complexité; au contraire, cela ajoutera beaucoup de complexité à l'ensemble du système.
Ce que HSM fait le mieux, c'est la clé stockage: la clé est dans le HSM et n'en sort pas, jamais. Cependant, vous devez toujours vous soucier du cycle de vie clé. Avec une clé "logicielle", stockée dans un fichier ou dans les entrailles du système d'exploitation, les sauvegardes sont une vulnérabilité (vous ne voulez pas que de nombreuses copies de la clé flottent). Avec le HSM, cette vulnérabilité est évitée, mais les sauvegardes deviennent un casse-tête majeur: perdre la clé est aussi un risque majeur, en particulier pour le cryptage (si vous perdez la clé de cryptage, vous perdez les données) . C'est donc un premier élément à rechercher pour HSM: procédures de sauvegarde . J'ai une certaine expérience avec Thales (nCipher) HSM, qui le fait comme ceci: les clés sont en fait stockées sous forme de fichiers cryptés (qui peuvent être enregistrés comme n'importe quel fichier), et la clé de décryptage pour ça = la clé peut être reconstruite avec un quorum de cartes à puce administrateur (dans un nouveau HSM).
HSM effectue rarement un chiffrement symétrique en masse. En fait, cela n'a pas beaucoup de sens de faire un chiffrement symétrique avec un HSM: vous utilisez le chiffrement parce que les données sont confidentielles. Logiquement, si le besoin de confidentialité est tel que la clé symétrique ne doit pas quitter le HSM, les données elles-mêmes ne doivent pas non plus le quitter. De plus, le chiffrement symétrique signifie que le chiffrement et le déchiffrement utilisent la même clé: si cette clé se trouve dans le HSM, le chiffrement et le déchiffrement devront tous les deux passer par là.
Les HSM sont mieux utilisés avec cryptage hybride : le HSM stocke et utilise la clé privée d'un système de cryptage asymétrique; lorsque les données doivent être cryptées, celui qui possède les données génère une clé symétrique aléatoire [~ # ~] k [~ # ~], chiffre les données avec [~ # ~] k [~ # ~], et chiffre [~ # ~] k [~ # ~] avec la clé publique correspondant à la Clé privée stockée HSM. En ce sens, HSM fonctionne comme (surdimensionné, hors de prix) cartes à puce .
Bien sûr, il existe un autre extrême, dans lequel vous intégrez l'ensemble de votre application dans le HSM. Cela nécessite un programmable HSM , et c'est un contexte complètement différent. Thales HSM autorise cela en option (il est appelé "CodeSafe" et "SEE"), qu'ils ne donnent pas gratuitement ... et ne vous attendez pas à exécuter du code traditionnel. Les HSM ont des accélérateurs cryptographiques, mais ils sont par ailleurs des systèmes embarqués assez limités (pensez à 60 MHz ARM CPU au mieux: le blindage HSM est en contradiction avec la dissipation thermique). Vous pouvez insérer du code relativement complexe dans un HSM (qui le permet) mais c'est un effort de programmation spécifique. De plus, certains HSM ne le permettent pas du tout.
Bien que les HSM soient chers, le coût le plus élevé d'un HSM est opérations: ils impliquent de nombreuses procédures d'installation, de configuration, d'exploitation, de restauration et de retrait. Vous aurez besoin de gens. Mon critère principal serait alors: les procédures . Un bon HSM sera livré avec un manuel d'utilisation détaillé qui décrit comment les choses doivent être faites. Ce n'est pas le matériel qui compte, mais la façon dont vous l'utilisez.
Des certifications, comme EAL 4+ ou FIPS 140-2 Level 3, peuvent être requises à des fins réglementaires. Vous choisissez rarement si vous en avez besoin ou non; c'est une exigence du contexte d'utilisation prévu. Obtention une telle certification est un processus très long et coûteux, donc vous ne le ferez pas par vous-même. D'autre part, vous voudrez peut-être élargir votre zone de shopping: si les HSM sont principalement de grandes cartes à puce, les cartes à puce pourraient être utilisables à la place du HSM. A carte à puce 20 EUR peut être FIPS 140-2 niveau 3; il ne calculera qu'un seul déchiffrement RSA-2048 par seconde au lieu de 500, mais cela peut vous suffire.