Crypto Casino
Torrent Gear
Cómo funciona el cifrado de datos en los sistemas de pago
Los sistemas de pago operan con los datos más sensibles: PAN (número de tarjeta), caducidad, CVV/CVC, tokens 3-DS, datos bancarios, ID de billetera. Su filtración son las multas, la retirada del merchant de los bancos/PSP y la pérdida financiera directa. La protección se construye en múltiples capas: cifrado en canal (TLS), cifrado y/o tokenización en almacenamiento, administración de claves rigurosa y módulos de hardware de confianza (HSM). A continuación, todo el «transportador» de seguridad con un lenguaje simple.
Ladrillos de base
Criptografía simétrica
Algoritmos: AES-GCM/CTR/CBC (en los pagos, el estándar de facto es AES-GCM).
Ventajas: alta velocidad, llaves compactas.
Contras: es necesario negociar con seguridad la clave y IV/nonce.
Criptografía asimétrica
Algoritmos: RSA-2048/3072, ECC (P-256/384, Ed25519).
Uso: intercambio/envoltura de claves, firmas, PKI, certificados TLS.
Pros: no requiere un secreto general de antemano.
Contras: más lento que el cifrado simétrico.
Идея Perfect Forward Secrecy (PFS)
Las claves de sesión se negocian por ECDHE efímero. Incluso si la clave privada del servidor se filtra una vez, las sesiones pasadas no serán encriptables.
Cifrado «en ruta»: TLS 1. 2/1. 3
1. Apretón de manos (TLS handshake): el cliente y el servidor acuerdan versiones/cifrados, el servidor presenta un certificado (PKI), intercambia claves efímeras (ECDHE) → nace una clave simétrica de sesión.
2. Datos: transmitidos en modos AEAD (AES-GCM/ChaCha20-Poly1305) con autenticación.
3. Optimizaciones: TLS 1. 3 reduce las rondas, admite la resunción; 0-RTT utilizan con precaución (sólo solicitudes idempotentes).
4. Práctica de pago: prohibimos la SSLv3/TLS1. 0/1. 1, incluimos TLS1. 2/1. 3, OCSP stapling, HSTS, títulos de seguridad estrictos.
Encriptación «en almacenamiento»: at nat
Opciones
Encriptación completa de volúmenes/DAB (TDE): se introduce rápidamente, protege contra el acceso «frío» al medio, pero no contra fugas a través de una aplicación comprometida.
Bit/Field-Level (FLE): se cifran los campos individuales (PAN, IBAN). Granular, pero más difícil de implementar e indexar.
Cifrado de almacenamiento de formato (FPE): útil cuando se necesita la vista «16 dígitos como 16 dígitos».
Tokenización: PAN es reemplazado por un token (una cadena sin sentido); El PAN real se almacena en token vault bajo protección reforzada. Cuando se paga/devuelve, se utiliza un token → el merchant no procesa las tarjetas «crudas».
Idea clave
En almacenamiento, lo más importante no es «qué algoritmo», sino dónde yacen las llaves y quién puede desintoxicar. Por eso...
Administración de claves: KMS, HSM y sobres
Jerarquía de claves (envelope encryption)
Root/KEK (Key Encryption Key): alta clase de protección, almacenada y ejecutada en HSM.
DEK (Data Encryption Key): cifra datos/lotes/tablas específicos; El mismo está encriptado por el KEK.
Rotación: normas para la rotación programada y no programada (en caso de incidente) de KEK/DEK; la versión de claves se especifica en los metadatos de texto cifrado.
HSM (Hardware Security Module)
Módulo de hardware certificado (por ejemplo, FIPS 140-2/3) que almacena y realiza operaciones con claves dentro de sí mismo.
No emite claves privadas al exterior, admite límites/políticas de uso, auditoría.
Se utiliza para: generación de claves, envoltura DEK, 3-DS de claves de servidor, claves EMV, operaciones PIN, firma de mensajes.
KMS
Centraliza la política de claves, versionamiento, accesos, registros y API.
En conjunto con HSM implementa encryption envelope y rotación automática.
Estándares de tarjetas y especificidades de la industria
PCI DSS (y lógica de minimización)
Idea principal: no almacenar CVV, minimizar el área de procesamiento PAN (scope).
Siempre que sea posible - dar entrada PAN en Hosted Fields/Iframe PSP → el merchant no tiene acceso a los datos crudos.
Los logs, los backups, los volcado son las mismas reglas que el prod: enmascarar, cifrar, retencionar.
EMV, PIN и POS
EMV chip/contacto-less: criptogramas a nivel de tarjeta/terminal, protección contra la clonación de la banda de magos.
Unidades PIN e ISO 9564: El PIN está cifrado desde el pin-pad hasta el procesador, funciona con HSM (transferencias pin, zonas clave).
DUKPT (Derived Unique Key Per Transaction): en POS, cada pago está cifrado con una clave única derivada de BDK → el compromiso de un mensaje no arrastra a los demás.
PCI P2PE: esquema de encriptación «de extremo a extremo» certificado de pin-pad a proveedor de descifrado.
3-D Secure (2. x)
La autenticación del titular de la tarjeta → menos frod/charjback.
La criptografía se utiliza para firmar mensajes, intercambiar claves ACS/DS/3DS Server; claves privadas generalmente en HSM.
Modelos de arquitectura de protección de datos
Opción A (merchant en línea con PSP):- El navegador → HTTPS → Hosted Fields PSP (PAN no llega al merchant).
- PSP devuelve payment token.
- La DAB de merchant almacena el token + los últimos 4 dígitos y el BIN (para UX y reglas).
- Devoluciones/repeticiones - sólo por token.
- Secretos/claves - en KMS, claves privadas TLS/3-DS - en HSM.
- La aplicación ↔ API es TLS/mTLS.
- Campos sensibles - FLE/FPE o tokenización; vault está aislado.
- Acceso a la desintoxicación - sólo por los roles de servicio con «cuatro ojos», la operación - a través de HSM.
- Pin-pad → DUKPT/P2PE → procesando.
- Las claves de arranque del terminal son a través de inyectores clave/HSM protegidos.
- Registro, protección de dispositivos anti-tamper.
Rotación, auditoría e incidentes
Rotación de claves: planificada (una vez en X mes) y por evento (compromiso). Rewrap DEK bajo el nuevo KEK sin descifrar los datos del usuario.
Revistas inmutables: quién y cuándo accedió a la desintoxicación/claves; firma de registros.
Runbook de compromiso: revoke/rotate inmediato, relanzamiento de certificados, bloque de claves API, notificación de socios, retrospectiva.
Errores frecuentes y cómo evitarlos
1. «Estamos cifrando el DB, significa que está bien».
No. La aplicación comprometida lee los datos en abierto. Se necesita tokenización/FLE y el principio de los derechos más pequeños.
2. Almacenamiento de CVV.
No puedes. El CVV no se almacena nunca, ni siquiera encriptado (por PCI DSS).
3. Claves junto a los datos.
No puedes. Las claves están en KMS/HSM, el acceso es por roles, un mínimo de privilegios, cuentas individuales.
4. No hay rotación/versiones.
Siempre versione las claves, almacene 'key _ version' en los metadatos de texto cifrado.
5. TLS sólo en el perímetro.
Cifre detrás de CDN/WAF y dentro de un plan de datos (servis→servis, webhooks).
6. Tokenización «para la especie».
Si detokenize puede cualquier servicio - esto no es protección. Limite a un círculo estrecho y audite las llamadas.
7. Backups/descargas analíticas no contabilizadas.
El cifrado y el enmascaramiento deben extenderse a los backups, snapshots, vitrinas BI, registros.
Lista de comprobación de la implementación (breve)
Canal
TLS 1. 2/1. 3, PFS, mTLS para interiores y webhooks, HSTS, headers de seguridad estrictos.
Almacenamiento
Tokenización PAN, prohibición de almacenamiento CVV.
FLE/FPE para campos críticos; TDE como capa base.
Claves
KMS + HSM, envelope encryption (KEK/DEK), rotación/versiones, registros inmutables.
Arquitectura
Hosted Fields/SDK PSP, minimizando la zona PCI.
La separación de roles/redes, el fideicomiso cero, los secretos son sólo a través del administrador secreto.
Operaciones
Pentest/Red Team en el perímetro y la lógica empresarial.
DLP/CTI-monitoreo de ciruelas, capacitación del personal.
Runbook на compromise: revoke/rotate/notify.
Mini preguntas frecuentes
¿Qué es mejor para PAN: cifrado o tokenización?
En la venta, la tokenización (minimiza el scope). En vault - cifrado con HSM/KMS.
¿Necesita un certificado EV para un dominio de pago?
No es obligatorio. Más importante es el perfil TLS correcto, mTLS, claves en HSM y disciplina.
Puede utilizar 0-RTT en TLS 1. ¿3 para pagos?
Para los idempotentes GET - sí. Para POST, es mejor apagar o limitar.
¿Cómo almacenar los «últimos 4» y BIN?
Separado del PAN; no se trata de datos sensibles cuando se aislan correctamente, pero observe el enmascaramiento en los logotipos/BI.
El cifrado en los sistemas de pago no es un solo tumbler, sino un ecosistema: TLS/PFS en el canal, tokenización y/o FLE en almacenamiento, gestión de claves rigurosa a través de KMS + HSM, estándares de la industria (PCI DSS, EMV, 3-DS), rotación y auditoría. Esta arquitectura multicapa hace altamente improbable la fuga de datos de tarjetas, simplifica las auditorías y, lo que es más importante, mantiene la confianza de los bancos, los socios de pago y los usuarios.