Arquitectura HSM de AWS Payment Cryptography - Profundizando en la infraestructura de cifrado de pagos conforme a PCI DSS

AWS Payment Cryptography es un servicio HSM gestionado especializado en la industria de pagos que proporciona cifrado y tokenización conforme a PCI DSS de forma serverless. Este artículo profundiza en los mecanismos técnicos del cifrado de pagos, incluyendo la generación de bloques PIN, la gestión de claves DUKPT y la diferenciación con CloudHSM.

Por qué la industria de pagos necesita HSM gestionados

El procesamiento criptográfico de pagos con tarjeta de crédito requiere módulos de seguridad física denominados PCI PTS HSM. Tradicionalmente, los procesadores de pagos instalaban HSM dedicados on-premises, asumiendo costos operativos anuales de decenas de millones de yenes. La carga operativa es extremadamente alta, incluyendo actualizaciones de firmware del HSM, rotación de claves y control de acceso físico. AWS Payment Cryptography fue diseñado para resolver este problema, proporcionando una infraestructura HSM gestionada que cumple con PCI DSS Level 1 y PCI PIN Security. Los usuarios solo necesitan llamar a la API para ejecutar operaciones criptográficas específicas de pagos como el cifrado de números de tarjeta (PAN), la generación y verificación de bloques PIN, y el cálculo de MAC (Message Authentication Code). Al eliminar la necesidad de gestionar el ciclo de vida del HSM desde la adquisición hasta la eliminación, se elimina la mayor barrera para la migración al cloud de los sistemas de pago. La tarificación es por uso basada en llamadas API, con un costo de 1.00 USD mensual por clave activa y operaciones criptográficas desde 1.00 USD por cada 10,000 operaciones.

Mecanismo criptográfico de generación y verificación de bloques PIN

El PIN introducido en cajeros automáticos o terminales de tarjeta nunca se transmite en texto plano. El PIN se convierte a un formato llamado bloque PIN y fluye por la red en estado cifrado. De los formatos de bloque PIN definidos en ISO 9564, Payment Cryptography soporta Format 0 (ISO-0), Format 1 (ISO-1), Format 3 (ISO-3) y Format 4 (ISO-4). Format 0 es el método más extendido que combina PIN y PAN mediante operación XOR. Por otro lado, Format 4 es el formato más reciente basado en cifrado AES, cuya adopción avanza con la obsolescencia de 3DES. Con la API TranslatePinData de Payment Cryptography, se puede ejecutar de forma segura la conversión entre diferentes formatos en el lado del servidor. La verificación del PIN utiliza la API VerifyPinData, donde el descifrado y la verificación se completan dentro del HSM, eliminando el riesgo de que el PIN en texto plano quede expuesto en memoria. La latencia de una sola llamada API es normalmente inferior a 50 milisegundos, cumpliendo ampliamente los requisitos de pagos en tiempo real.

Por qué la gestión de claves DUKPT sustenta la seguridad de terminales

DUKPT (Derived Unique Key Per Transaction) es un esquema de gestión de claves que deriva una clave criptográfica única por transacción para cada terminal de pago. En el terminal solo se inyecta la clave inicial (IPEK) derivada de la BDK (Base Derivation Key), y la BDK en sí no se almacena en el terminal. Como se generan claves derivadas adicionales a partir de la IPEK en cada transacción, incluso si una clave se filtra, las transacciones pasadas y futuras no se ven afectadas. Payment Cryptography completa la derivación de claves DUKPT dentro del HSM. Se genera la BDK con la API CreateKey y se deriva la IPEK por terminal con la API DeriveKey. Además del DUKPT basado en 3DES, también soporta DUKPT basado en AES-256 (ANSI X9.24-3), permitiendo la operación paralela durante el período de migración. Se pueden generar hasta aproximadamente 1 millón de claves derivadas a partir de una sola BDK, soportando redes de terminales a gran escala. En Azure Payment HSM, la derivación de claves DUKPT debe implementarse en el lado de la aplicación, lo que difiere en filosofía de diseño respecto a Payment Cryptography donde se completa mediante API.

Patrones de implementación de tokenización y protección de datos de tarjeta

PCI DSS v4.0 requiere la protección mediante cifrado o tokenización al almacenar números de tarjeta (PAN). En una implementación típica de tokenización con Payment Cryptography, el PAN se cifra con la API EncryptData y el texto cifrado se almacena como token en DynamoDB. Durante el procesamiento del pago, se descifra con la API DecryptData y se envía a la red de pagos. En este esquema, el PAN en texto plano existe temporalmente en la memoria del servidor de aplicaciones, por lo que se recomienda un diseño que utilice el entorno de ejecución de Lambda para minimizar el tiempo de vida en memoria. Los algoritmos de cifrado disponibles incluyen AES-256-CBC, AES-256-ECB y 3DES-CBC, que se seleccionan según los requisitos de la red de pagos. Con FPE (Format Preserving Encryption), un PAN de 16 dígitos se puede cifrar en otra cadena numérica de 16 dígitos, permitiendo introducir la tokenización sin modificar el esquema de base de datos existente. El efecto de reducir el alcance de conformidad PCI DSS es significativo, reduciendo considerablemente los componentes del sistema sujetos a auditoría.

Diferenciación con CloudHSM - La frontera entre cifrado de propósito general y especializado en pagos

AWS cuenta con dos servicios HSM: CloudHSM y Payment Cryptography. CloudHSM es un HSM de propósito general con certificación FIPS 140-2 Level 3 que puede ejecutar operaciones criptográficas arbitrarias a través de interfaces estándar como PKCS#11, JCE y OpenSSL. Por otro lado, Payment Cryptography es un HSM dedicado a pagos con certificación PCI PTS HSM que proporciona APIs específicas de pagos como operaciones de bloques PIN, derivación de claves DUKPT y cálculo de MAC. El criterio de selección es claro: si el objetivo principal es el cifrado de tarjetas o la verificación de PIN, se elige Payment Cryptography; si el objetivo es cifrado de propósito general como terminación TLS o firma de código, se elige CloudHSM. También hay diferencias en costos. CloudHSM tiene facturación por hora por clúster con un mínimo de aproximadamente 1,500 USD mensuales, mientras que Payment Cryptography es completamente de pago por uso, con aproximadamente 100 USD para 1 millón de operaciones mensuales. La ventaja en costos es notable para procesadores de pagos con bajo volumen de transacciones. Una configuración que utiliza ambos servicios, separando roles entre cifrado de pagos y cifrado de propósito general, también es práctica.

Directrices de diseño para la implementación en producción de Payment Cryptography

Para la implementación en producción, primero se determina la estrategia de importación de claves. Para la migración desde HSM on-premises existentes, se recomienda el protocolo TR-34. TR-34 es un esquema de intercambio de claves asimétricas basado en RSA que logra una migración segura sin exponer las claves en texto plano. La API ImportKey soporta TR-34 de forma nativa. En cuanto a disponibilidad, el servicio se replica automáticamente dentro de la región, pero en configuraciones multi-región, las claves se importan individualmente en cada región y el failover se controla en la capa de aplicación. Para auditoría, todas las llamadas API se registran en CloudTrail, facilitando el cumplimiento del requisito 10 de PCI DSS. La migración es más realista de forma gradual: confirmar la precisión de la conversión de bloques PIN y la verificación MAC en un entorno de pruebas, operar en paralelo y luego cambiar a producción. Libros relacionados (Amazon) también son una referencia útil.