Hardware Security Module (HSM): ¿Qué es y para qué sirve?

Uno de los principales problemas derivados del uso de la criptografía para la protección de datos sensibles durante su almacenamiento y su transmisión es la complejidad en la gestión del ciclo de vida de las claves de encriptación (generación, almacenamiento, importación/exportación, distribución, rotación, remplazo, copias de seguridad, revocación, suspensión, destrucción, auditoría, etc.). Debido a que la seguridad del sistema criptográfico debe recaer en la seguridad de la clave (principio de Kerckhoffs), esta clave debe ser gestionada de la forma más segura posible, ya que se supone que el potencial atacante puede conocer o tener acceso al resto de parámetros del sistema criptográfico (algoritmo usado, texto encriptado, texto en claro). Si la clave es comprometida, todo el sistema criptográfico es comprometido («un criptosistema debería ser seguro incluso si todo sobre el sistema, excepto la clave, es de conocimiento público»).

Ciclo de vida de las claves criptográficas. Fuente: NIST Special Publication 800-57 Part 1

En este sentido, una de las alternativas más recomendables para realizar la gestión de las claves criptográficas es mediante el uso de un módulo de seguridad de hardware (Hardware Security Module – HSM). Un HSM (también conocido como Secure Application Module (SAM), Secure Cryptographic Device (SCD), Hardware Cryptographic Device (HCD) o simplemente Cryptographic Module) es un criptoprocesador seguro y resistente a la manipulación (tamper-resistant) diseñado específicamente para proteger el ciclo de vida de las claves criptográficas y ejecutar rutinas de encriptación y desencriptación, proporcionando un alto nivel de seguridad en términos de confidencialidad, integridad y disponibilidad de claves criptográficas y de cualquier dato sensible procesado.

Arquitectura interna de un HSM. Fuente: IBM 4770-001

Los HSMs pueden encontrarse en tarjetas inteligentes (smart cards), dispositivos portables, tarjetas dedicadas (tarjetas criptográficas), dispositivos autocontenidos (appliances) u ofrecidos como un servicio en la nube (HSM-as-a-Service).

Diferentes tipos de HSM: Tarjeta criptográfica, appliance, HSM USB (nano) y tarjeta inteligente (smart card)

Operación de los HSMs

Los HSMs son dispositivos de seguridad que gestionan el ciclo de vida de las claves criptográficas y ejecutan rutinas de cifrado y descifrado de datos. En ese sentido, su operación se puede desglosar de la siguiente manera:

• • Desde el punto de vista físico, el dispositivo debe operar en un entorno seguro.
  • Se cuenta con un canal de comunicación con el exterior para la recepción de datos a cifrar o descifrar. Estos canales suelen estar autenticados y restringidos solamente para el acceso de elementos autorizados. Pueden ser canales locales o remotos.
  • El HSM almacena en su memoria protegida una clave maestra (Master Key) que recibe diferentes nombres dependiendo del fabricante (Local Master Key (LMK), Master File Key (MFK), etc.). Esta clave se encarga de proteger todas las demás claves criptográficas bajo su jerarquía y no se puede exportar en claro fuera del dispositivo. Cualquier intento de acceso de forma no autorizada (ya sea física o lógicamente) a la clave maestra puede activar rutinas de protección del HSM (antitampering).
  • Dependiendo del fabricante, las claves operativas – una vez cifradas con la clave maestra – pueden ser exportadas externamente al dispositivo para ser almacenadas en ficheros o bases de datos. Estas claves cifradas reciben el nombre de criptogramas.
  • Igualmente, el HSM puede ser administrado de forma remota o por consola.
  • Estos dispositivos pueden operar en diferentes niveles de seguridad, dependiendo de las actividades a realizar:
    • Modo no autenticado: Permite la obtención de información no sensible del dispositivo (uso de CPU, memoria, información de configuración de red, etc.)
    • Modo autenticado: Permite la ejecución de tareas sensibles, como la creación, carga o exportación de claves, borrado seguro del dispositivo, creación de usuarios, etc. En este caos, se puede requerir de autenticación dual (dos usuarios se deben autenticar de forma correcta) antes de proceder.
  • Para su operación, usualmente se permite la creación de diferentes usuarios o roles que se deben autenticar previamente para poder ejecutar tareas en el dispositivo.

Operación de un HSM

Tipos de HSM

Dependiendo de las necesidades, los dispositivos HSM se pueden catalogar en dos tipos:

• HSM de propósito general (General Purpose HSM): Dispositivos HSM que incluyen una gran variedad de algoritmos de encriptación estándar (simétricos, asimétricos y funciones de hash) con soporte para interconectividad vía API empleando Public-Key Cryptography Standard (PKCS) #11, Microsoft Cryptographic Application Programming Interface (CAPI), Cryptography API Next Generation (CNG), Java Cryptography Architecture (JCA), Java Cryptography Extension (JCE) y otros. Estos dispositivos suelen ser usados en entornos de PKI, canales de HTTPS, DNSSEC, protección de datos sensibles genéricos y billeteras de criptomonedas, entre otros.
• HSM transaccional y para pagos (Transaction and Payment HSM): Dispositivos HSM específicos para la protección de transacciones de pago que incluyen el uso de PIN (generación, gestión, validación y translación del bloque de PIN (PIN Block) en transacciones realizadas en TPVs y cajeros automáticos), la protección de transferencias electrónicas de fondos (EFT), la generación de datos para bandas magnéticas y chips EMV en procesos de producción y personalización de tarjetas, el procesamiento de transacciones de pago con tarjetas débito y crédito y la validación de tarjetas, usuarios y criptogramas. Estos dispositivos normalmente proveen soporte criptográfico para las aplicaciones de pago de la mayoría de marcas de tarjetas y sus interfaces de interconexión suelen ser más limitadas que los HSM de uso genérico.

Validación de los niveles de seguridad de los dispositivos HSM

Con el fin de validar los niveles de seguridad de este tipo de dispositivos se han definido una serie de estándares internacionales dentro de los cuales se encuentran:

• FIPS (Federal Information Processing Standard) 140-2 y 140-3 (Security Requirements for Cryptographic Modules): Es un estándar orientado a la validación de la efectividad del hardware criptográfico. A pesar de ser un estándar federal de EEUU y Canadá, es reconocido a nivel mundial tanto en el sector gubernamental como en el privado. Esta certificación define cuatro niveles de seguridad, del más bajo (Nivel 1) al más restrictivo (Nivel 4):
  • Nivel 1: Incluye requerimientos básicos de seguridad (al menos un algoritmo o una función aprobada deben ser usados), permitiendo que los componentes de software y firmware del módulo criptográfico sean ejecutados en un sistema de propósito general usando un sistema operativo no evaluado. No se incluyen mecanismos de seguridad física. Ejemplo: tarjeta de encriptación de un ordenador personal.
  • Nivel 2: Este nivel mejora la seguridad del nivel 1 exigiendo el uso de mecanismos para la detección de manipulación no autorizada (tamper-evidence) y autenticación basada en roles. Las implementaciones de software deben ejecutarse en un sistema operativo aprobado como EAL2 de Common Criteria.
  • Nivel 3:  Este nivel exige requerimientos adicionales para resistir ante manipulaciones no autorizadas (tamper-resistance), respuesta ante tales manipulaciones (borrado de parámetros de seguridad) y autenticación basada en identidades. Igualmente, se requiere una separación lógica entre interfaces mediante las cuales los parámetros críticos de seguridad ingresan y egresan del sistema. Las claves privadas solamente pueden importarse o exportarse de forma encriptada.
  • Nivel 4: Este último nivel incluye protección avanzada contra intrusiones (tamper-active) y está diseñado para productos que operan en entornos desprotegidos físicamente.
• Common Criteria (ISO/IEC 15408): Common Criteria for Information Technology Security Evaluation es un estándar de certificación reconocido internacionalmente para la seguridad de productos de TI y sistemas. Fue desarrollado por Canadá, Francia, Alemania, Países Bajos, Reino Unido y EEUU en los años noventa. Los productos evaluados bajo Common Criteria se catalogan en niveles (Evaluation Assurance Level – EAL), siendo EAL1 el más bajo y EAL 7 el más estricto.
• Payment Card Industry (PCI) PTS HSM Security Requirements (PCI HSM): El estándar PCI HSM hace parte del grupo de estándares PIN Transaction Security (PTS) del PCI SSC y define los controles de seguridad necesarios durante los procesos de fabricación, envío, uso y desmantelamiento de los dispositivos HSM empleados en transacciones financieras.

Adicionalmente, algunos países han desarrollado normativas específicas para la gestión de claves y algoritmos en dispositivos HSM que pueden requerir certificaciones especiales, como es el caso de Alemania (DK), Francia (CB MEPS), Australia (APCA CECS) o Italia.

Dispositivos HSM y su relación con los estándares del PCI SSC

La criptografía es uno de los mecanismos básicos empleados para la protección de los datos transaccionales relacionados con tarjetas de pago. Debido a ello, muchos de los controles de los estándares del PCI SSC (PCI DSS, PCI PIN, PCI P2PE, PCI 3DS, PCI Card Production, etc.) requieren que exista una gestión formal de las claves criptográficas y – en algunos casos – obligan a usar HSMs específicos y certificados.

A continuación se enumeran algunos de los estándares del PCI SSC y sus requerimientos en términos de uso de dispositivos HSM:

Igualmente, las certificaciones de estos dispositivos suelen tener un periodo de validez, con el fin de gestionar su ciclo de vida. Dependiendo del programa y/o del estándar, el uso de dispositivos expirados suele estar restringido.

Las fechas de validación y expiración de estos dispositivos se pueden encontrar en los siguientes enlaces:

Dispositivos PCI HSM: https://listings.pcisecuritystandards.org/assessors_and_solutions/pin_transaction_devices?agree=true

Dispositivos FIPS (NIST Cryptographic Module Validation Program): https://csrc.nist.gov/Projects/cryptographic-module-validation-program/validated-modules/search

Controles adicionales para la proteccion de HSMs en entornos PCI

Bajo ciertos escenarios, algunos dispositivos (generalmente dispositivos certificados en PCI HSM) requiren de controles físicos adicionales en entornos restringidos (restricted environments) para mitigar problemas que no son gestionados a través de sus controles nativos. En estos casos, es muy importante validar tanto con el vendedor de la solución como en los listados la necesidad de estos controles. Usualmente, los controles requeridos para estos entornos restringidos se alinean con el estándar ISO 13491-2:2023 Financial services — Secure cryptographic devices (retail)Part 2: Security compliance checklists for devices used in financial transactions, que deben ser validados de forma adicional a los controles propios tanto del HSM como del estándar aplicable a la operación del dispositivo.

Entrada de dispositivo Thales 10K en el sitio del PCI SSC. Nótese el campo «Additional Information»

Información adicional de la validación PCI HSM en donde se indica que el dispositivo debe ser desplegado en un entorno restringido (ISO 13491-2)

Política de seguridad de PCI HSM en donde se indica el uso de un entorno restringido

Administración remota en dispositivos HSM

Durante años, uno de los principales problemas de los dispoitivos HSM (principalmente de aquellos en formato appliance) fue la ausencia de interfaces seguras para su administración, operación y gestión de claves criptográficas. Tradicionalmente, se hacía uso de terminales genéricas (tipo VT-100) o de ordenadores multipropósito, lo cual añadía un punto de riesgo en el proceso, ya que era posible que material sensible se transmitiera y/o almacenara en las terminales usadas. Estas terminales solían conectarse a través de puertos seriales, paralelos, USB o incluso puertos ethernet exclusivos. Esta tarea solía ser bastante engorrosa, ya que requería de acceso físico al HSM (que usualmente se encontraba en un centro de datos), así como la interacción de diferentes personas/roles para garantizar el control dual.

Terminal multipropósito conectada a un HSM

Con la entrada de PCI HSM v3, se permite el uso de administración remota de los dispositivos HSM. En este caso, en vez de utilizar una conexión local al dispositivo, se emplea una conexión remota (generalmente ethernet) entre el dispositivo u¡y una ubicación central segura en donde se encuentra la consola. Como se puede deducir, el objetivo es evitar los desplazamientos físicos a los centros de datos, asegurar los canales de transmisión de datos y evitar el almacenamiento no controlado de datos sensibles en dispositivos inseguros y es ampliamente usada en entornos de HSMs en la nube.

Esta funcionalidad puede ser provista por el propio dispositivo (como parte de su certificación PCI HSM) o a través de un dispositivo externo denominado Remote Administration Platform (RAP):

Funcionalidad de administración remota en Thales 10K

Certificación como Remote Administration Platform (RAP)

Los detalles de la implementación y de los controles de seguridad adicionales para la administración remota se pueden encontrar en la documentación del fabricante, en los estándares de seguridad (principalmente PCI HSM) o en las preguntas de uso frecuente técnicas (Technical FAQs), principalmente de PCI PIN y P2PE.

Servicios de HSM en cloud y HSM-as-a-Service (HSMaaS)

De forma adicional al modelo de HSM desplegados localmente en la organización (on-premises), muchos proveedores de servicios en cloud y fabricantes de dispositivos HSM están ofreciendo servicios de Hardware Security Module «as a Service» o gestionados. Este nuevo modelo ofrece muchas ventajas frente al modelo tradicional, incluyendo alta escalabilidad, disponibilidad y opciones adicionales de integración. Algunos ejemplos de estos servicios son:

• Microsoft Azure: Azure Dedicated HSM y Azure Key Vault
• Google Cloud Platform: Cloud HSM y Cloud Key Management Service
• Amazon Web Services: AWS Key Management Service (KMS), AWS CloudHSM y AWS Payment Cryptography (servicio validado en PCI PIN y P2PE)
• IBM Cloud Hardware Security Module
• Utimaco HSM-as-a-Service (servicio validado en PCI PIN y P2PE)
• nCipher nShield-as-a-Service
• Thales CipherTrust Cloud Key Manager

Sin embargo, es importante tener en cuenta que el uso de estos servicios gestionados o en cloud ofrecen dispositivos HSM de propósito general que pueden ser útiles para su integración con entornos PCI DSS pero no para el uso en entornos PCI PIN, PCI P2PE o PCI 3DS, ya que estos estándares requieren HSMs transaccionales con soporte criptográfico especial y controles adicionales de seguridad física y del ciclo de vida del dispositivo. En ese sentido, antes de contratar este tipo de servicios es muy importante que la entidad valide si existen requisitos de cumplimiento (tales como PCI PIN, P2PE, etc.) y el tipo de funcionalidades requeridas por la operación.

Flujograma para la selección de un servicio de HSM en la nube. Fuente: Microsoft

Conclusión

Bruce Schneier, en su libro Applied Cryptography decía: «La gestión de las claves criptográficas es la parte más difícil de la criptografía y a menudo el talón de Aquiles de un sistema seguro». Una forma segura y no tan complicada de realizar esta gestión es empleando módulos de seguridad de hardware (HSM). Estos dispositivos permiten la gestión segura de claves, el procesamiento de datos sensibles de forma segura y cumplen con requerimientos estrictos de seguridad certificables y son una alternativa segura al uso de librerías criptográficas genéricas de software, agregando capas de protección física y lógica que permiten la protección de los procesos criptográficos.