Nota: Este artículo ha sido publicado originalmente en el blog de Advantio en idioma inglés.

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

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.

Figura 1. Diagrama esquemático de un módulo de seguridad de hardware (HSM). Fuente: University of Patras.

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

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

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 (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:

EstándarRequisitos relacionadosComentarios
PCI DSS v3.2.13.5.x
3.6.x
4.x
El estándar PCI DSS no requiere de forma específica el uso de dispositivos HSM para la gestión de las claves de encriptación empleadas para la protección de datos de tarjeta durante su almacenamiento y transmisión. No obstante, el uso de estos dispositivos facilita los procesos de almacenamiento seguro de las claves (3.5.3 y 3.6.3), generación de claves (3.6.1), distribución de claves (3.6.2), rotación/criptoperiodos (3.6.4), remplazo de claves (3.6.5), implementación de "dual control" y "split knowledge" (3.6.6), prevención de sustitución de claves (3.6.7) y gestión de custodios (3.6.8), así como la gestión de claves para la protección de canales de transmisión de datos de tarjetas (4.x).
PCI PIN v3.01-xEl estándar PCI PIN exige que:
- Los datos del PIN sean procesados en dispositivos HSM y certificados como PCI HSM o FIPS 140-2 Level 3 o superior.
- Todas las claves criptográficas usadas para la encriptación/desencriptación del PIN deben ser generadas en dispositivos certificados como PCI HSM, FIPS 140-2 Level 3 o superior o empleando un generador de números aleatorios alineado con NIST 800-22.
- Los procesos de inyección de claves (Key Injection) deben ser realizados con dispositivos certificados como PCI HSM o FIPS 140-2 Level 3 o superior.
PCI P2PE v3.04A-1
5-1
El estándar PCI P2PE exige que:
- Los dispositivos empleados en el entorno de desencriptación sean HSMs certificados como PCI HSM o FIPS 140-2 Level 3 o superior.
- Todas las claves criptográficas usadas para la encriptación/desencriptación de datos de tarjetas deben ser generadas en dispositivos certificados como PCI HSM, FIPS 140-2 Level 3 o superior o empleando un generador de números aleatorios alineado con NIST 800-22.
- Los procesos de inyección de claves (Key Injection) deben ser realizados con dispositivos certificados como PCI HSM o FIPS 140-2 Level 3 o superior.
PCI 3DS v1.0P2-6.1.2El estándar PCI 3DS requiere que aquellas entidades que ofrecen servicios de Access Control Server (ACS) o Directory Server (DS) empleen un HSM certificado PCI HSM o FIPS 140-2 Level 3 o superior.
Para entidades que ofrecen servicios como 3DS Server (3DSS) no es obligatorio el uso de HSM pero es altamente recomendado.
PCI Card Production (Logical) v2.08.5 (Key generation)
8.7 (Key loading)
8.14 (Key-Management Security Hardware)
El estándar PCI Card Production (Logical) requiere que se empleen HSMs certificados como PCI HSM o FIPS 140-2 Level 3 o superior para los procesos de generación de claves, carga de claves (key loading) y protección de datos sensibles.

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:

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 que ninguno de estos proveedores ofrece al día de hoy.

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.

Avatar

Autor: David Acosta

Asesor de Seguridad Calificado (QSA) para PCI DSS, P2PE, PIN, 3DS, TSP y PIN.
CISSP Instructor, CISA, CISM, CRISC, CHFI Trainer, CEH, OPST, BS25999 LA.