Panorama: confiar sin custodiar#

Todas las demás defensas del manual dependen, en última instancia, de vigilar algo: un cortafuegos vigila el tráfico, un EDR vigila los procesos, un SOC vigila los registros. La criptografía es distinta porque no vigila: apoya sus garantías en la dificultad matemática de ciertos problemas. Bien usada, permite algo que ninguna otra herramienta ofrece —confiar en un dato sin tener que custodiar el canal por el que viaja—. Se puede mandar un mensaje por una red hostil, que cualquiera puede leer y alterar, y aun así garantizar que solo el destinatario lo entiende (confidencialidad), que nadie lo tocó sin que se note (integridad) y que lo escribió quien dice (autenticidad). Esa es la razón por la que la criptografía es un sustrato: las tres propiedades de la tríada CIA tienen en ella su implementación más fuerte.

Pero esa fuerza viene con una trampa, y conviene enunciarla desde el principio porque organiza todo el capítulo: la criptografía casi nunca falla en la matemática. Los algoritmos modernos, bien elegidos, resisten. Lo que falla —una y otra vez, en caso tras caso— es cómo se los implementa y, sobre todo, cómo se gestionan las claves. Un cifrado perfecto con una clave mal guardada no protege nada; una firma impecable validada contra una autoridad comprometida certifica al atacante. La criptografía traslada el problema de la seguridad del algoritmo a la clave, y ahí, en la gestión de la clave, es donde se pierde. El capítulo recorre primero las herramientas y termina en esa lección.

Las tres primitivas#

Casi toda la criptografía aplicada se construye con tres bloques. Confundirlos es el error conceptual más común en seguridad, así que conviene separarlos con nitidez.

El cifrado simétrico (symmetric encryption) usa una sola clave para cifrar y descifrar, compartida entre las partes. Es rápido y eficiente, y por eso es lo que protege el grueso de los datos —un disco cifrado, el contenido de una sesión de red ya establecida—. Su algoritmo de referencia es AES. Su problema es logístico y enorme: para hablar con alguien hay que compartir antes la clave, y compartir una clave secreta con quien todavía no se puede hablar de forma segura es un círculo vicioso.

El cifrado asimétrico (asymmetric encryption, o de clave pública) resuelve ese círculo. Cada parte tiene un par de claves: una pública, que se reparte libremente, y una privada, que se guarda en secreto. Lo que se cifra con una solo se descifra con la otra. Eso permite dos cosas mágicas. Primera: cualquiera puede cifrar un mensaje con la clave pública del destinatario sabiendo que solo él, con su clave privada, podrá leerlo —sin haber acordado nada de antemano—. Segunda, y es la base de la firma: algo cifrado con la clave privada de alguien solo se verifica con su pública, lo que prueba que salió de él. El asimétrico es lento, así que en la práctica no cifra los datos: se usa para acordar de forma segura una clave simétrica, que hace el trabajo pesado. Ese matrimonio —asimétrico para acordar, simétrico para transportar— es exactamente lo que hace el handshake de TLS que la capa de red describió.

La función de hash (hash function) es la tercera primitiva y la más malentendida. Toma una entrada de cualquier tamaño y produce una huella de tamaño fijo, con tres propiedades: la misma entrada da siempre la misma huella; es inviable revertir la huella al dato original; e inviable encontrar dos entradas con la misma huella. Un hash no cifra —no hay clave, no se «des-hashea»—: garantiza integridad, no confidencialidad. Sirve para detectar si algo cambió (comparar huellas), para almacenar contraseñas sin guardarlas en claro, y como pieza de la firma digital. Los de referencia son la familia SHA-2; los viejos MD5 y SHA-1 están rotos para usos de seguridad porque se encontró cómo fabricar colisiones.

flowchart TB
  S["simétrico\n1 clave · rápido\ncifra el grueso de los datos"]
  A["asimétrico\npar público/privado\nacuerda claves · firma"]
  H["hash\nhuella fija · sin clave\nintegridad, NO confidencialidad"]
  S --> TLS["canal cifrado\n(TLS, disco)"]
  A --> PKI["firma digital · PKI\ncertificados · autenticación"]
  A --> TLS
  H --> INT["integridad\ncontraseñas · firma"]

Y aquí el error de categoría que hay que desterrar: cifrar, codificar y hashear son cosas distintas. Codificar —Base64, por ejemplo— no es seguridad: es solo cambiar la representación de un dato para transportarlo, y se revierte trivialmente, cualquiera puede decodificar Base64. Cifrar protege con una clave. Hashear produce una huella irreversible. Tratar un dato codificado como si estuviera protegido es una de las confusiones que la ofensiva explota una y otra vez.

Construcciones: de las primitivas a la confianza aplicada#

Sobre esas tres primitivas se levantan las construcciones que el manual usó sin detenerse a explicarlas.

Derivación de claves y contraseñas. Guardar contraseñas como hash directo no alcanza, por dos razones. Si dos usuarios tienen la misma contraseña, tienen el mismo hash —y un atacante que roba la base los ve iguales y ataca a ambos de una—; y como el hash es rápido de calcular, se pueden probar miles de millones de candidatos por segundo. La respuesta son las funciones de derivación de claves (Key Derivation Functions, KDF) con sal (salt): un valor aleatorio único por usuario que se mezcla con la contraseña antes de hashear —así dos contraseñas iguales dan huellas distintas y las tablas precalculadas dejan de servir— y un algoritmo deliberadamente lento (bcrypt, scrypt, Argon2) que hace que probar cada candidato cueste tiempo. La diferencia entre un almacén de contraseñas que resiste y uno que cae en horas es exactamente esta construcción. Cuando la Parte 4 mostró el crackeo de hashes tras un volcado, lo que decide si el ataque prospera es si la organización usó una KDF lenta con sal o un hash rápido y pelado.

Firma digital y PKI. La firma combina hash y asimétrico: se hashea el documento y se cifra la huella con la clave privada del firmante; cualquiera verifica rehaciendo el hash y descifrando la huella con la pública. Eso da integridad (si el documento cambió, las huellas no coinciden) y autenticidad (solo el dueño de la privada pudo firmar). Pero queda una pregunta: ¿cómo sé que esa clave pública es realmente de quien dice? La respuesta es la infraestructura de clave pública (Public Key Infrastructure, PKI): una jerarquía de autoridades de certificación (Certificate Authorities, CA) que firman certificados —afirmaciones de que «esta clave pública pertenece a esta identidad»—, de modo que confiar en la CA raíz permite confiar, por cadena, en todo lo que firmó. Esa cadena de confianza es lo que hace funcionar TLS (el certificado del servidor) y también la autenticación por certificados del Active Directory que la Parte 4 recorrió. Y su punto débil es estructural: quien controla una CA puede certificar mentiras; por eso las fallas de esa Parte no rompían la criptografía, abusaban de quién podía emitir certificados y para qué.

Kerberos como criptografía aplicada. El protocolo de autenticación del Active Directory es un caso de estudio de todo lo anterior en movimiento: usa cifrado simétrico para proteger sus tickets y para probar identidad sin mandar la contraseña por la red. Y ahí la elección del algoritmo importa de forma tangible. La Parte 4 mostró que los tickets cifrados con el viejo RC4 son crackeables sin conexión —se prueban contraseñas contra el ticket hasta que una descifra— mientras que los cifrados con AES resisten ese ataque; y que la mera presencia de RC4 en la telemetría es una firma de manipulación. Es la lección de este capítulo hecha carne: no falló Kerberos, falló seguir aceptando un algoritmo que la matemática ya había dejado atrás. La misma diferencia —viejo roto contra moderno sólido— reaparece cada vez que un sistema arrastra criptografía obsoleta por compatibilidad.

Los límites: dónde falla de verdad#

El capítulo cierra donde empezó, con la advertencia que ordena todo. La criptografía no es magia y tiene límites concretos que hay que respetar.

El primero es el principio de Kerckhoffs, ya citado en los principios: la seguridad de un sistema criptográfico debe residir solo en la clave, nunca en el secreto del algoritmo. De ahí la regla práctica más repetida de la disciplina —no inventes tu propia criptografía—: los algoritmos estándar son fuertes porque miles de expertos llevan décadas intentando romperlos sin lograrlo; una construcción casera no auditada casi siempre esconde un defecto fatal que su autor no ve. El segundo límite es que la criptografía protege el dato en tránsito y en reposo, pero no mientras se lo usa: en el momento en que un programa descifra algo para procesarlo, ese algo está en claro en la memoria —que es, no por casualidad, donde LSASS guarda las credenciales y donde el volcado las cosecha—.

Y el tercero, el que engloba a todos, es la gestión de claves. Una clave es tan buena como su custodia: si se guarda en el código fuente, en un archivo de configuración legible, en un repositorio, o si nunca se rota, el cifrado más fuerte del mundo no vale nada, porque el atacante no ataca el algoritmo, se lleva la clave. La mayoría de los desastres criptográficos reales no son roturas matemáticas: son claves filtradas, certificados mal validados, algoritmos obsoletos no retirados y aleatoriedad insuficiente al generar los secretos. La criptografía es el sustrato de confianza más sólido de la seguridad —y, como todo sustrato, sostiene lo que se apoya bien sobre él y no perdona lo que se apoya mal.

Referencias#

  • Las tres primitivas (cifrado simétrico, asimétrico y funciones de hash), la firma digital y la infraestructura de clave pública son material fundacional de criptografía; su ordenamiento como el sustrato de confianza verificable de la tríada CIA y la insistencia en la distinción cifrar/codificar/hashear son enriquecimiento propio.
  • Las funciones de derivación de claves con sal conectan con el crackeo de hashes tras el volcado de credenciales; la PKI y la cadena de confianza, con la autenticación por certificados del Active Directory y con el certificado TLS de la capa de red; Kerberos como criptografía aplicada (RC4 crackeable frente a AES), con la Parte 4.
  • El principio de Kerckhoffs, la regla de no inventar criptografía propia y la centralidad de la gestión de claves son la aplicación al sustrato criptográfico de los principios de 0.1. La composición de estas garantías en un sistema completo se trata en la arquitectura de seguridad.