¿Se ha preguntado alguna vez por qué los documentos siempre dicen que se utilice el módulo de protección cuando se utilizan juntos el FIM CM y el HSM de Thales? ¿Por qué utilizar el HSM en un modo menos seguro cuando está diseñado para ser un dispositivo K de N?
Recientemente, tuve un cliente que quería utilizar la mayor seguridad posible en su implementación de PKI y tarjetas inteligentes. Subcontrataron los servicios informáticos y querían que todos los componentes de PKI estuvieran controlados por un empleado y un contratista. Esta es la mejor práctica en este entorno, ya que mantiene la seguridad del sistema al limitar el acceso.
El cliente quería una implementación 2 de 6, tomando 2 de las 6 tarjetas inteligentes programadas para el dispositivo para autenticar al dispositivo. Esto funcionó bien para los componentes CA y el cliente quería que los servidores FIM CM se configurasen de la misma manera. No encontré documentación o artículos que dijeran que la K de N no funcionaría para FIM CM.
La configuración del servidor se hizo con la K de N para FIM CM y la instalación y configuración fueron bien... o eso pensé. Al tratar de emitir una tarjeta inteligente de FIM, el sistema se detuvo en la inicialización de la tarjeta inteligente.
En este punto, el sistema FIM CM debería haber estado pidiendo la frase de contraseña y las tarjetas OCS. No aparecía nada en el escritorio del servidor ni en la sesión 0. Ahora empieza la verdadera diversión.
Después de revisar los registros de eventos y cualquier otro registro de depuración disponible, no parecía haber ningún error. Dejamos que el sistema funcionara durante 24 horas en el diálogo de inicialización de la tarjeta pensando que tal vez el sistema sólo era lento. No hubo suerte. Ningún mensaje de error y ninguna indicación de un problema. ¿Cuál es el siguiente paso?
Decidimos abrir una solicitud de asistencia a Microsoft. Después de varios días de obtener registros de eventos y depuración, el técnico declaró que no era un problema de Microsoft, sino de Thales. Así que nos dirigimos al servicio de asistencia de Thales.
Thales pidió más registros de eventos y depuración. Al cabo de una semana, declararon que no era un problema de Thales, sino de Microsoft. Vuelta a empezar.
Como desarrollador de proveedores de servicios criptográficos en una vida pasada, decidí profundizar en el problema, ya que nadie en Thales o Microsoft parecía ser capaz de ayudar. Microsoft nunca probó FIM CM con ningún tipo de HSM y Thales nunca probó con FIM CM.
Tras instalar varios componentes de depuración y utilizar un depurador de kernel, encontré varias discrepancias tanto en la implementación de Microsoft de FIM CM como en la implementación de Thales del CSP utilizado por FIM CM para acceder al HSM.
Después de unos días de investigación he descubierto por qué K de N no tiene ninguna posibilidad de trabajar con FIM CM y cualquier HSM. Microsoft intenta abrir la sesión al HSM con una llamada CryptAcquireContext con la bandera crypt_silent activada. Esto indica al CSP que no solicite las contraseñas de las tarjetas OCS. Se enciende la luz número uno.
Entonces descubrí que el CSP de Thales devuelve un éxito al CryptAcquireContext cuando se accede al HSM. Volviendo a las especificaciones de Microsoft para el desarrollo de CSP, dice que durante el CryptAcquireContext si se necesita una frase de contraseña y se solicita la bandera crypt_silent, entonces se debe devolver un código de error. Thales no cumplió con las especificaciones, ya que en el momento del CryptAcquireContext no saben que se necesita una frase de contraseña.
FIM CM se colgará cuando se realice la siguiente llamada criptográfica al HSM. Microsoft debería, al menos, desconectar tras un periodo de tiempo y Thales debería corregir el CSP.
Con Module protect, no se necesita una frase de contraseña y el sistema funciona.
Ahora ya sabe por qué el uso K de N de un HSM no funcionará con FIM CM.
