Documento de Arquitectura Criptográfica — Fintrixs Pay

Documento: DOC-CRYPTO-ARCH-01 Versión: 1.0 Fecha de aprobación: 2026-07-29 Owner: CTO / Security Lead Frecuencia de revisión: Anual + tras cambios significativos Referencias PCI DSS: Req 3.5, 3.6.1.1, 3.6.1.2, 3.6.1.3, 3.7.1-9

1. Propósito

Este documento describe la arquitectura criptográfica implementada por Fintrixs Pay para proteger la Información Cubierta (Cardholder Data — CHD, y Sensitive Authentication Data — SAD) en cumplimiento de PCI DSS v4.0 Requerimiento 3.

Es el documento de referencia obligatorio bajo Req 3.6.1.1 para todo Service Provider.

2. Alcance criptográfico

Componentes del CDE que ejecutan operaciones criptográficas sobre CHD/SAD:

Componente	Rol	Ubicación
`card-vault-service`	Almacenamiento cifrado de PAN + metadata de tarjeta	Namespace `default`, migrará a `pci-cde` (SEC-012)
`tokenization-service`	Emisión y gestión de tokens (tok_pan_, tok_cvv_)	Namespace `default`, migrará a `pci-cde`
`payments-api`	Consumidor de tokens/decrypt para autorización	Namespace `default`, migrará a `pci-cde`
`HashiCorp Vault cluster`	Fuente de todas las claves criptográficas y operaciones sensibles	VPC `fintrix-production-vpc`, droplets dedicados

3. Clasificación de datos

Clase	Ejemplo	Almacenamiento permitido	Cifrado obligatorio
PAN (Primary Account Number)	Número completo de tarjeta	✅ En card-vault-service (cifrado)	✅ AES-256-GCM
PAN truncado	BIN + últimos 4 (`4111 ** ** 1234`)	✅ Cualquier tabla operativa	No requerido
PAN fingerprint	HMAC-SHA256 del PAN	✅ Índice de búsqueda	HMAC con key rotada anualmente
CVV / CVV2 (SAD)	Código de seguridad	⚠️ SOLO hasta autorización, luego destrucción	✅ AES-256-GCM en memoria + purge inmediato
PIN / PIN Block (SAD)	PIN de tarjeta	❌ NO almacenado (Fintrixs no procesa PIN)	N/A
Track 1 / Track 2 (SAD)	Datos de banda magnética	❌ NO almacenado (Fintrixs opera solo online)	N/A
Nombre del portador	Nombre en tarjeta	✅ En card-vault-service (cifrado)	✅ AES-256-GCM
Fecha de expiración	MM/YY	✅ En card-vault-service (cifrado)	✅ AES-256-GCM

Regla dura: ningún servicio fuera de card-vault-service y tokenization-service puede recibir, procesar, almacenar ni loguear PAN o SAD en claro. Cumplimiento verificado con SAST rules + auditoría de logs vía SIEM.

4. Algoritmos aprobados

Solo se permiten los siguientes algoritmos criptográficos, seleccionados de acuerdo con NIST SP 800-131A y PCI DSS v4.0 Anexo A2:

Uso	Algoritmo	Fortaleza	Estándar
Cifrado simétrico de PAN/SAD	AES-256-GCM	256 bits	NIST SP 800-38D
Fingerprint/hash de PAN para búsqueda	HMAC-SHA-256 con key dedicada	256 bits	FIPS 198-1
Firma JWT	RS256 (RSA-2048 + SHA-256) o ES256	2048 / 256 bits	RFC 7518
TLS entre servicios	TLS 1.3 (fallback 1.2 con ECDHE-only cipher suites)	—	NIST SP 800-52 Rev 2
Envelope encryption — DEK	AES-256-GCM (cifrada por KEK)	256 bits	NIST SP 800-38F
Envelope encryption — KEK	Almacenada en Vault transit engine (AES-256-GCM)	256 bits	NIST SP 800-38D
Password hashing (usuarios de la plataforma)	Argon2id (m=64MB, t=3, p=4)	—	RFC 9106

Prohibidos explícitamente:

DES, 3DES, RC4, MD5, SHA-1, RSA-1024, DH < 2048
TLS 1.0 y 1.1 (bloqueados a nivel de Kong y Vault)
Cifrados no autenticados (AES-CBC sin HMAC, AES-ECB)

5. Modelo de key management

5.1 Jerarquía de claves

                    ┌─────────────────────────────────────┐
                    │   Shamir Master Key                  │
                    │   (Vault seal key)                   │
                    │   AES-256, split 5-of-5 threshold 3 │
                    │   Nunca escrita a disco              │
                    └───────────────┬─────────────────────┘
                                    │ unseal
                                    ▼
                    ┌─────────────────────────────────────┐
                    │   Vault Root Key                     │
                    │   (interno de Vault Barrier)         │
                    │   Cifra el keyring                    │
                    └───────────────┬─────────────────────┘
                                    │
                    ┌───────────────┼───────────────┐
                    ▼               ▼               ▼
        ┌───────────────────┐  ┌─────────────┐  ┌──────────────┐
        │  KEK (Key         │  │  KEK        │  │  KEK         │
        │  Encrypting Key)  │  │  fingerprint│  │  tokenization│
        │  card-vault-svc   │  │  HMAC       │  │  service     │
        │  transit/keys/kek-│  │  transit/   │  │  transit/    │
        │  card-vault       │  │  keys/hmac- │  │  keys/kek-   │
        │                   │  │  pan-fpr    │  │  tokenization│
        │  AES-256-GCM      │  │  HMAC-256   │  │  AES-256-GCM │
        │  Rotación: 12 mes │  │  Rot: 12 m  │  │  Rot: 12 m   │
        └────────┬──────────┘  └─────────────┘  └──────┬───────┘
                 │                                       │
                 │ envuelve DEK                          │ envuelve DEK
                 ▼                                       ▼
        ┌───────────────────┐                  ┌──────────────────┐
        │  DEK (Data        │                  │  DEK             │
        │  Encrypting Key)  │                  │  tokenized_data  │
        │  Generada por     │                  │  Generada por    │
        │  registro         │                  │  registro        │
        │  AES-256-GCM      │                  │  AES-256-GCM     │
        │  1 por card_id    │                  │  1 por token_id  │
        └───────────────────┘                  └──────────────────┘

5.2 Ubicación física y lógica de cada clave

Clave	Almacenamiento	Formato	Backup	Retención
Shamir shares (5)	Custodios humanos (papel + sobre sellado + caja fuerte)	ASCII base64	2 shares en escrow (caja fuerte oficina + notario)	Vida del sistema
Vault Root Key	RAM del proceso Vault (nunca a disco)	Binario	N/A (se regenera al re-key)	Hasta próximo re-key
KEKs (transit engine)	Vault Raft storage (cifrado con Root Key)	Vault-managed	Snapshot diario en DO Spaces (WORM)	Historial completo (Vault mantiene versiones anteriores para decrypt)
DEKs	Junto al dato cifrado en Postgres (columna `dek_ciphertext`)	Base64 del ciphertext	Junto con backup de DB	Vida del registro
HMAC key (fingerprint)	Vault transit engine (`hmac-pan-fpr`)	Vault-managed	Snapshot Vault	Rotación anual sin re-hash de datos existentes

5.3 Cryptoperiod y rotación

Definido según NIST SP 800-57 Parte 1 Rev 5:

Clave	Cryptoperiod	Trigger de rotación
Shamir Master Key	3 años	Cambio de custodio, compromiso sospechado, evento de re-key programado
KEK card-vault-service	12 meses	Cron automático 1° de enero, o compromiso sospechado
KEK tokenization-service	12 meses	Cron automático 1° de enero, o compromiso sospechado
HMAC key (fingerprint)	12 meses	Cron automático 1° de febrero
DEK por registro	Vida del registro	Se genera nueva por cada nuevo tarjeta guardada; se descarta cuando se borra el registro
TLS certificates	90 días	Automático vía cert-manager
JWT signing keys	6 meses	Manual documentado + graceful rollover 30 días

5.4 Split knowledge y Dual Control (PCI DSS 3.7.6)

Implementación vía Shamir Secret Sharing:

La Master Key de Vault se divide en 5 shares con threshold 3 (necesitás 3 personas para unseal).
Cada share es entregada a un custodio distinto físicamente presente durante la ceremonia.
Ningún custodio conoce la master key completa (split knowledge ✅).
Ninguna operación sensible de Vault puede realizarse con menos de 3 custodios (dual control ✅ — el término PCI "dual" se cumple con ≥2, acá excedemos requerimiento).

Custodios designados:

#	Rol	Custodio	Acuerdo firmado
1	CTO	`[NOMBRE_CUSTODIO_A]`	`KEY-CUSTODIAN-AGREEMENT-A.pdf`
2	Security Lead	`[NOMBRE_CUSTODIO_B]`	`KEY-CUSTODIAN-AGREEMENT-B.pdf`
3	CEO / Cabeza legal	`[NOMBRE_CUSTODIO_C]`	`KEY-CUSTODIAN-AGREEMENT-C.pdf`
4	Escrow físico (oficina)	2 personas requeridas para acceder a caja fuerte	`ESCROW-D-PHYSICAL-ACCESS-LOG.pdf`
5	Escrow legal externo	Notaría `[NOMBRE_NOTARIA]`	`ESCROW-E-NOTARIAL-DEED.pdf`

PENDIENTE completar: los custodios A, B, C con nombres reales requieren decisión del CTO + firma de los acuerdos de custodio.

6. Ciclo de vida de las claves (PCI DSS 3.7.1 a 3.7.9)

6.1 Generación (Req 3.7.1)

Toda clave se genera dentro de Vault mediante el CSPRNG del kernel Linux (/dev/urandom, respaldado por getrandom(2)).
Los Shamir shares se generan en RAM del proceso Vault durante vault operator init; nunca se escriben a disco.
Ceremonia formal documentada en KEY-CEREMONY-RUNBOOK.md (video + firma de asistentes + logs de comandos ejecutados).

6.2 Distribución segura (Req 3.7.2)

Shamir shares: entregadas físicamente en sobre sellado, firmado por el custodio receptor. Nunca se transmiten electrónicamente.
KEKs y DEKs operacionales: nunca salen del proceso Vault (transit engine encrypt-as-a-service).
Los servicios (card-vault, tokenization) NUNCA reciben la KEK — envían el plaintext a Vault y reciben ciphertext.

6.3 Almacenamiento seguro (Req 3.7.3)

Master Key: en RAM únicamente. Al parar Vault, se pierde y requiere unseal.
Shamir shares: papel en sobre sellado en caja fuerte (2 shares) + custodios personales (3 shares).
KEKs: Vault Raft storage cifrado por Barrier + KEK del proceso.
DEKs: cifradas por KEK correspondiente, almacenadas junto al ciphertext en Postgres.

6.4 Rotación al fin del cryptoperiod (Req 3.7.4)

Automatizada: cron job (vault-key-rotation-cron) ejecuta vault write transit/keys/{name}/rotate en la fecha programada.
Re-encryption diferida: los datos existentes se re-encriptan on-read con la nueva versión (o mediante batch job en ventana off-peak).
Todo evento de rotación queda en Vault audit log (inmutable, replicado a DO Spaces WORM).
Ver runbook KEY-ROTATION-PROCEDURE.md.

6.5 Retirement y sustitución (Req 3.7.5)

Compromiso sospechado → activación del INCIDENT-KEY-COMPROMISE.md runbook.
Acciones inmediatas: vault write transit/keys/{name}/rotate + revocación de versión comprometida + re-encryption forzada de todos los datos + notificación a stakeholders en <4h.

6.6 Prevención de sustitución no autorizada (Req 3.7.7)

Vault Access Policies (vault-policies/) restringen update, rotate, delete solo a la policy crypto-admin que requiere autenticación con AppRole + MFA + firma de 2 admins (Vault Sentinel policy).
Audit log inmutable registra todo intento con entity_id, client_token, remote_address, request_id.

6.7 Acuerdo formal de custodios (Req 3.7.8)

Cada custodio firma KEY-CUSTODIAN-AGREEMENT.pdf que incluye:
- Descripción de responsabilidades
- Compromiso de no revelar la share bajo ninguna circunstancia
- Procedimiento de handoff en caso de renuncia/cambio de rol
- Consecuencias legales de violación (cláusulas de confidencialidad + penal)
Archivo firmado se conserva en el drive legal + copia en escrow notarial.

6.8 Políticas documentadas (Req 3.7.9)

Este documento (DOC-CRYPTO-ARCH-01) + KEY-MANAGEMENT-PROCEDURE.md + DATA-RETENTION-DELETION-PROCEDURE.md cumplen el requerimiento de políticas documentadas.
Revisión anual obligatoria; próxima revisión: 2027-07-29.

7. Separación producción vs. pruebas (Req 3.6.1.4 / 6.5.5)

Vault opera con namespaces separados:
- namespace: prod — usado por servicios en pci-cde namespace de K8s
- namespace: staging — usado por servicios en cluster fintrix-staging-k8s
Cada namespace tiene su propia jerarquía completa de KEKs.
Nunca se copian claves prod → staging ni viceversa.
Los datos de test NUNCA contienen PAN real; se usan test cards de Visa/MC/Amex documentadas en TEST-CARDS-INVENTORY.md.

8. Inventario de dispositivos criptográficos

Dispositivo	Tipo	Ubicación	Función	Serial / ID
Vault cluster (3 nodos)	Software Cryptographic Module	DO droplets en `fintrix-production-vpc`	Master key management, transit encrypt, PKI	`vault-01`, `vault-02`, `vault-03`
DO Spaces bucket (WORM)	Object storage con object-lock	`fintrix-vault-audit-nyc3`	Audit log inmutable	Bucket ID: `[TO_FILL]`
Postgres card_vault DB	Sistema de almacenamiento cifrado	DOKS `pci-cde` namespace, StatefulSet	Storage de PAN cifrado	Cluster ID: `[TO_FILL]`

Nota sobre HSM: No se utiliza HSM físico. La decisión está documentada como compensating control:

Vault OSS implementa AES-256-GCM (algoritmo NIST-approved), Shamir Secret Sharing para split knowledge, audit log inmutable, y rotación automatizada. La ausencia de FIPS 140-2 validated hardware se compensa con: (a) uso exclusivo de algoritmos aprobados NIST SP 800-131A, (b) audit log WORM con retención 365 días, (c) segmentación del cluster Vault en nodos dedicados sin otras cargas, (d) roadmap para migración a HSM cloud (Fortanix DSM o Vault Enterprise HSM binary) en Q4 2026 tras evaluación de volumen post-certificación.

9. Historial de revisiones

Versión	Fecha	Autor	Cambios
1.0	2026-07-29	Security Lead	Documento inicial. Cubre Preguntas 25/27/28 del cuestionario ControlCase.

10. Aprobaciones

Rol	Nombre	Firma	Fecha
CTO	`[TO_FILL]`
Security Lead	`[TO_FILL]`
CEO	`[TO_FILL]`

Documentos relacionados:

Documento de Arquitectura Criptográfica — Fintrixs Pay ​

1. Propósito ​

2. Alcance criptográfico ​

3. Clasificación de datos ​

4. Algoritmos aprobados ​

5. Modelo de key management ​

5.1 Jerarquía de claves ​

5.2 Ubicación física y lógica de cada clave ​

5.3 Cryptoperiod y rotación ​

5.4 Split knowledge y Dual Control (PCI DSS 3.7.6) ​

6. Ciclo de vida de las claves (PCI DSS 3.7.1 a 3.7.9) ​

6.1 Generación (Req 3.7.1) ​

6.2 Distribución segura (Req 3.7.2) ​

6.3 Almacenamiento seguro (Req 3.7.3) ​

6.4 Rotación al fin del cryptoperiod (Req 3.7.4) ​

6.5 Retirement y sustitución (Req 3.7.5) ​

6.6 Prevención de sustitución no autorizada (Req 3.7.7) ​

6.7 Acuerdo formal de custodios (Req 3.7.8) ​

6.8 Políticas documentadas (Req 3.7.9) ​

7. Separación producción vs. pruebas (Req 3.6.1.4 / 6.5.5) ​

8. Inventario de dispositivos criptográficos ​

9. Historial de revisiones ​

10. Aprobaciones ​