Le compte à rebours est lancé pour Keyfactor Tech Days | Réservez votre place dès aujourd'hui !

  • Accueil
  • Blog
  • FIM Certificate Management 2010 et Thales nConnect HSM

FIM Certificate Management 2010 et Thales nConnect HSM

Vous êtes-vous déjà demandé pourquoi les documents indiquent toujours d'utiliser la protection du module lors de l'utilisation conjointe du FIM CM et du HSM de Thales ? Pourquoi utiliser le HSM dans un mode moins sécurisé alors qu'il est conçu pour être un dispositif K de N ?

Récemment, j'ai eu un client qui voulait utiliser la plus grande sécurité possible dans sa mise en œuvre de PKI et de la carte à puce. Il a externalisé ses technologies de l'information et voulait que tous les composants de PKI soient contrôlés par un seul employé et un seul sous-traitant. C'est la meilleure pratique dans cet environnement, car elle permet de sécuriser le système en limitant l'accès.

Le client souhaitait une implémentation 2 sur 6, prenant 2 des 6 cartes à puce programmées pour l'appareil afin de s'authentifier sur l'appareil. Cela a bien fonctionné pour les composants CA et le client a ensuite voulu que les serveurs FIM CM soient configurés de la même manière. Je n'ai trouvé aucune documentation ni aucun article indiquant que le K de N ne fonctionnerait pas pour FIM CM.

L'installation du serveur a été faite avec le K de N pour FIM CM et l'installation et la configuration se sont bien déroulées... ou du moins c'est ce que je pensais. En essayant d'émettre une carte à puce à partir de FIM, le système s'est bloqué lors de l'initialisation de la carte à puce.

À ce stade, le système FIM CM aurait dû demander la phrase de passe et les cartes OCS. Rien n'apparaissait sur le bureau du serveur ou dans la session 0. C'est maintenant que les choses sérieuses commencent.

Après avoir consulté les journaux d'événements et tous les autres journaux de débogage disponibles, il ne semble pas y avoir d'erreurs. Nous avons laissé le système fonctionner pendant 24 heures sur le dialogue d'initialisation de la carte en pensant que le système était peut-être simplement lent. Nous n'avons pas eu de chance. Aucun message d'erreur et aucune indication d'un problème. Quelle est donc la prochaine étape ?

Nous avons décidé d'introduire une demande d'assistance auprès de Microsoft. Après avoir passé plusieurs jours à obtenir des journaux d'événements et de débogage, le technicien a déclaré qu'il ne s'agissait pas d'un problème Microsoft, mais d'un problème Thales. Nous nous sommes donc tournés vers le service d'assistance de Thales.

Thales a demandé davantage de journaux d'événements et de débogage. Au bout d'une semaine, ils ont déclaré qu'il ne s'agissait pas d'un problème Thales, mais d'un problème Microsoft. Retour à la case départ.

En tant que développeur de fournisseurs de services cryptographiques dans une vie antérieure, j'ai décidé de creuser le problème puisque personne chez Thales ou Microsoft ne semblait être en mesure de m'aider. Microsoft n'a jamais testé FIM CM avec aucun type de HSM et Thales n'a jamais testé FIM CM.

Après avoir installé plusieurs composants de débogage et utilisé un débogueur de noyau, j'ai trouvé plusieurs anomalies dans l'implémentation Microsoft de FIM CM et dans l'implémentation Thales du CSP utilisé par FIM CM pour accéder au HSM.

Après quelques jours de recherche, j'ai découvert pourquoi K of N n'a aucune chance de fonctionner avec FIM CM et n'importe quel HSM. Microsoft tente d'ouvrir la session vers le HSM avec un appel CryptAcquireContext avec le drapeau crypt_silent. Cela indique au CSP de ne pas demander les phrases de passe pour les cartes OCS. Le voyant numéro un s'est allumé.

J'ai ensuite constaté que le CSP de Thales renvoie un succès au CryptAcquireContext lorsqu'il accède au HSM. Si l'on se réfère aux spécifications de Microsoft pour le développement du CSP, il est indiqué que lors du CryptAcquireContext, si une phrase de passe est nécessaire et que le drapeau crypt_silent est demandé, un code d'erreur doit être renvoyé. Thales n'a pas respecté les spécifications, puisqu'au moment du CryptAcquireContext, il ne sait pas qu'une phrase d'authentification est nécessaire.

Le FIM CM se bloque lorsque le prochain appel cryptographique est effectué vers le HSM. Microsoft devrait au moins temporiser après un certain temps et Thales devrait corriger le CSP.

Avec Module protect, aucune phrase de passe n'est nécessaire et le système fonctionne.

Vous savez maintenant pourquoi l'utilisation K de N d'un HSM ne fonctionnera pas avec le FIM CM.