web-dev-qa-db-fra.com

Critères de sélection d'un HSM

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:

  • Évidemment, le coût est un facteur, mais existe-t-il différents modèles de tarification? De quoi faut-il tenir compte?
  • Certains produits sont-ils plus adaptés à différentes formes de chiffrement (par exemple, symétrique vs asymétrique, bloc vs flux, etc.)?
  • Idem pour différents workflows et cycles de vie
  • Quel niveau d'assurance, par ex. quel niveau de FIPS 140-2, est requis quand?
  • Attaché au réseau vs attaché au serveur
  • etc

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 ...

47
AviD

Quelques facteurs techniques qui peuvent être pertinents:

  1. Performances - sur tout ce qui compte pour votre application (le cas échéant): chiffrement/déchiffrement/génération/signature de clés, symétrique, asymétrique, EC, ...
  2. Échelle:
    • Y a-t-il une limite au nombre de clés qu'il prend en charge, et cette limite pourrait-elle être un problème?
    • Est-il facile d'ajouter un autre HSM lorsque votre application devient plus exigeante (taille, vitesse, répartition géographique ...)
  3. Redondance - lorsqu'un HSM tombe en panne, quel impact cela a-t-il sur vos opérations, à quel point est-il facile de le remplacer sans perte de service, etc.
  4. Sauvegardes - est-il facile d'automatiser et de restaurer? Avez-vous besoin de protéger indépendamment la confidentialité et/ou l'intégrité de la sauvegarde ou le produit le garantit-il? Quelle est la probabilité que vous vous retrouviez dans une position où vous avez irrémédiablement perdu vos données (combien de facteurs doivent être perdus/oubliés, HSM morts, etc.).
  5. Prise en charge de l'API:
    • MS CAPI/ CNG (facile à programmer à partir d'un environnement Windows);
    • JCA (facile à développer pour utiliser Java. Quelle version est prise en charge?);
    • PKCS # 11 (et une version récente? Large prise en charge à travers les applications, bien qu'il soit livré avec problèmes de sécurité connus );
    • propriétaire du fournisseur (probablement le plus flexible/le plus puissant/le plus sûr si vous savez ce que vous faites, mais augmente le coût pour passer à un autre fournisseur), et bien que C soit probablement une donnée, at-il des liaisons pour votre préféré Langue?
    • une remarque connexe: existe-t-il des conseils sur l'intégration avec votre application (par exemple, SGBD, services OS)?
  6. Prise en charge OS/matériel
  7. Options de gestion - quels outils d'interface graphique/de ligne de commande sont disponibles pour effectuer des tâches de gestion - c'est-à-dire tout ce que vous faites assez rarement pour ne pas vouloir automatiser (génération de clés?; Gestion du facteur d'authentification?). Vos administrateurs doivent-ils être physiquement présents pour mettre en service l'appareil ou effectuer des tâches supplémentaires après la mise en service?
  8. Programmabilité - la plupart de votre développement se fera probablement à l'autre bout de l'une des API, mais il est parfois utile de pouvoir écrire des applications qui s'exécutent sur l'appareil pour plus de flexibilité ou de vitesse (voir réponse de Thomas )
  9. Sécurité physique - dans quelle mesure votre solution doit-elle être résistante aux attaques physiques directes (en tenant compte non seulement du HSM mais de l'ensemble de la solution)? Si, pour une raison quelconque, vous décidez que cela est particulièrement important (votre HSM est exposé mais vos clients ne le sont pas, ou la divulgation des clés est bien pire que le simple fait de pouvoir utiliser les clés à des fins néfastes - ref DigiNotar ?) alors vous voudrez peut-être rechercher une détection et une réponse de sabotage actives, pas seulement une résistance et des preuves de sabotage passives.
  10. Modèle de sécurité logique - des entités malveillantes sur le réseau peuvent-elles abuser de votre HSM? Processus malveillants sur le PC hôte?
  11. Algorithmes - le HSM prend-il en charge la crypto que vous souhaitez utiliser (primitives, modes de fonctionnement et paramètres, par exemple courbes, tailles de clés)?
  12. Options d'authentification - mots de passe; quorums; n-facteurs; carte à puce; OTP; ... Vous devriez probablement au moins rechercher quelque chose qui peut nécessiter une taille de quorum configurable d'utilisateurs jetons + mot de passe authentifiés avant d'autoriser les opérations à l'aide d'une clé.
  13. Options de stratégie - vous souhaiterez peut-être définir des stratégies telles que contrôler si: les clés peuvent être exportées du HSM (encapsulées ou non cryptées); une clé ne peut être utilisée que pour la signature/le cryptage/le décryptage/...; l'authentification est requise pour signer mais pas pour vérifier; etc.
  14. Capacité d'audit - y compris les opérations de type HSM (clé générée, signé quelque chose avec la clé Y) et la gestion des plantages (commentaire de ref g3k). Est-il facile d'intégrer les journaux dans quelque chose comme Splunk (format de journal sain, syslog/snmp/autre réseau accessible - ou du moins non propriétaire - sortie)?
  15. Facteur de forme:
    • réseaattaché (pour les déploiements à plus grande échelle, en particulier lorsque plusieurs applications/serveurs/clients doivent utiliser les clés);
    • burea (pour un usage individuel; les performances, la disponibilité et l'évolutivité ne sont pas un gros problème mais le coût l'est, particulièrement bon si votre solution nécessite beaucoup de personnes ayant besoin d'un accès direct à un HSM);
    • PCI (-express) (moins cher que le réseau connecté; plus d'efforts impliqués pour la mise à disposition de plusieurs applications);
    • jeton USB (mise à niveau facile du serveur; bon marché et lent (et facile à voler!));
    • carte PC (selon le bureau, mais bon pour les utilisateurs d'ordinateurs portables). (Les cartes PC sont maintenant mortes)

Quelques facteurs non techniques:

  1. Certifications - en avez-vous besoin/en voulez-vous parce qu'elles vous donnent confiance dans la sécurité du produit? Ignorer ce dont vous avez besoin pour des raisons réglementaires:
    • FIPS 140-2 fournit une confirmation utile que les algorithmes approuvés par le NIST fonctionnent et ont des tests de réponse connus au moment de l'exécution (consultez la politique de sécurité pour voir les algs qu'ils ont approuvés), mais ne mettez pas beaucoup de stock dedans sinon montrant le le produit est sécurisé; ma règle de base pour la sécurité matérielle de niveau 3 signifie que les personnes ayant seulement quelques minutes d'accès à l'appareil auront du mal à le compromettre. FIPS 140-2 Level 3 est la certification de base pour les HSM - méfiez-vous s'il n'en a pas (bien que cela ne signifie pas que vous devez l'utiliser dans un FIPS).
    • Les évaluations selon les Critères communs sont flexibles dans l'assurance qu'elles fournissent: lisez la cible de sécurité! Il n'y a pas encore de profils de protection HSM décents, donc au moins vous devrez lire la définition du problème de sécurité (menaces et hypothèses) avant d'avoir une idée de ce que l'évaluation fournit.
    • PCI-HSM sera utile si vous êtes dans le secteur concerné
  2. Outre les certifications, à quoi ressemble le fournisseur en matière de sécurité? Avoir des certificats CC EAL4 est un bon point de départ, mais rappelez-vous que Win2k en a aussi ... Font-ils des bruits convaincants sur l'intégrité de la chaîne d'approvisionnement, Secure Software Development Lifecycle, ISO2700x, ou quelque chose comme The Open Group Trusted Technology Provider Framework ?
  3. Aimez-vous la politique du vendeur sur la divulgation?
  4. Support (options, réputation, disponible dans votre langue)
  5. Services - si vous avez une exigence complexe, il peut être avantageux d'impliquer le fournisseur dans votre configuration/programmation.
  6. Documentation:
    • Documentation de haut niveau - Les HSM sont des produits à usage général complexes qui peuvent nécessiter une gestion quelque peu complexe; une bonne documentation est importante pour vous permettre de développer un processus sécurisé et réalisable autour d'eux (voir réponse de Thomas pour plus de discussion).
    • Documentation API - bonne couverture, comprenant de préférence de bons exemples de tâches courantes (et complexes)
  7. Coût (unités + maintenance)
  8. Délai de mise en œuvre
  9. Politique/fréquence des correctifs du fournisseur (+ prise en charge et facilité de mise à niveau du micrologiciel)
  10. Pays de conception et/ou de fabrication - vous pourriez être un gouvernement ou une entreprise qui fait (particulièrement) confiance à certains pays
  11. Stabilité des fournisseurs - sont-ils susceptibles d'être là pour prendre en charge le produit aussi longtemps que vous allez l'utiliser?
  12. Quelle est la feuille de route du produit du fournisseur, contient-elle quelque chose de valeur pour vous, et aurez-vous accès aux futures versions via la mise à niveau du firmware?
  13. À quel point le Swag était bon que vous en soyez sorti à RSA

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 .

37
Michael

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.

23
Thomas Pornin