Principios del diseño seguro de protocolos

El diseño de protocolos seguros presupone un adversario que controla por completo la red. El modelo de Dolev-Yao (1983) especifica que el adversario puede interceptar, leer, retrasar, repetir, eliminar y modificar cualquier mensaje en tránsito. El adversario puede generar mensajes indistinguibles de los de las partes honestas. También puede componer mensajes nuevos a partir de componentes de mensajes conocidos. No puede romper las primitivas criptográficas (descifrar sin la clave ni falsificar firmas). Es fundamental que el adversario tenga recursos computacionales limitados —tiempo polinómico—, pero controle todos los canales de comunicación. La seguridad del protocolo consiste en alcanzar los objetivos de autenticación y secreto incluso frente a este poderoso adversario, dependiendo únicamente de la dificultad computacional de las primitivas subyacentes.

Abadi y Needham (1994) condensaron las lecciones prácticas del diseño de protocolos en un conjunto de principios. (1) Todo mensaje debe indicar lo que significa: la interpretación de un mensaje debe ser autosuficiente y no depender del contexto. (2) Las condiciones para que una entidad realice una acción deben indicarse explícitamente en el protocolo. (3) Si la identidad de una entidad es importante, debe indicarse explícitamente en el mensaje. (4) Hay que dejar claro por qué se utiliza el cifrado: el cifrado proporciona confidencialidad y la firma proporciona autenticación; no se debe utilizar el cifrado como sustituto de la firma. (5) Un mensaje debe cifrarse en la capa del protocolo donde se necesita mantener su secreto. Estos principios evitaron muchos de los fallos de tipo NS.

Los ataques de repetición se encuentran entre las vulnerabilidades de protocolo más comunes. Los mecanismos de frescura garantizan que un mensaje recibido se haya generado recientemente y no se haya repetido desde una sesión anterior. Hay dos enfoques: (1) Nonces (Number used ONCE, números utilizados una sola vez): un desafío-respuesta en el que el receptor envía un valor aleatorio y espera que se repita en la respuesta. La respuesta debe contener el nonce cifrado o firmado, lo que impide que una grabación antigua supere el desafío. (2) Marcas de tiempo: ambas partes incluyen la hora actual; se rechaza un mensaje cuya marca de tiempo sea obsoleta. Las marcas de tiempo requieren relojes sincronizados (Kerberos permite una desviación de 5 minutos). Se prefieren los nonces cuando no se dispone de sincronización de relojes; las marcas de tiempo simplifican la verificación sin estado.

Utilizar la misma clave criptográfica para varios fines crea interacciones peligrosas. Si una clave K se utiliza tanto para cifrado como para autenticación, un adversario podría proporcionar textos cifrados manipulados al mecanismo de autenticación para extraer información. TLS 1.3 evita este problema rigurosamente mediante HKDF-Expand-Label, con etiquetas distintas para cada clave derivada: "c hs traffic" (handshake del cliente), "s hs traffic" (handshake del servidor), "c ap traffic" (aplicación del cliente). Aunque la clave del handshake se vea comprometida, las claves de aplicación derivadas de una rama HKDF diferente siguen siendo seguras. Los diseños de protocolos deben auditar todas las claves para detectar riesgos derivados de usos múltiples y generar claves separadas para fines separados.

Las credenciales de autenticación deben estar vinculadas a la sesión específica en la que se utilizan. Sin esta vinculación, una credencial obtenida en una sesión puede reutilizarse en otra. Técnicas: (1) incluir identificadores de sesión en datos firmados o protegidos con MAC; (2) incluir la transcripción de DH en la firma (enfoque STS); (3) utilizar la clave de sesión derivada mediante HKDF para calcular un MAC sobre la identidad (enfoque SIGMA). Mensaje Finished de TLS 1.3: MAC(server_finished_key, transcript_hash): el MAC cubre la transcripción completa, por lo que reutilizar un Finished de otra sesión falla. Esta vinculación es la que evita los ataques entre sesiones detectados en las primeras versiones de Kerberos y NS.

Los protocolos solo deben divulgar la información mínima necesaria para cumplir su función. Revele las identidades únicamente a quienes las necesiten. No incluya números de serie de certificados ni identificadores que permitan vincular sesiones con identidades, salvo que sea necesario. TLS 1.3 cifra el certificado del servidor, a diferencia de TLS 1.2, donde se transmite en texto plano, lo que reduce la información que puede obtener un espía pasivo. ESNI (Encrypted SNI, ahora ECH — Encrypted Client Hello) cifra la indicación del nombre del servidor para ocultar a qué servidor se conecta el cliente. La divulgación mínima de información también es un principio del diseño de tokens: las claims de JWT solo deben contener lo necesario para la autorización, no registros completos de identidad.

La negociación de versiones es una superficie de ataque habitual: un adversario elimina o modifica el ClientHello para obligar a ambas partes a utilizar una versión de protocolo más antigua y débil. Defensas: (1) negociación autenticada de versiones: incluir la versión negociada en la transcripción firmada (Finished de TLS cubre el ClientHello, incluida la versión); (2) indicadores de degradación: TLS 1.3 establece bytes mágicos en ServerHello.Random al degradar a TLS 1.2, lo que permite al cliente detectar la degradación; (3) prevención de la intolerancia a versiones: los servidores deben rechazar ClientHellos malformados sin recurrir silenciosamente a una versión anterior; (4) SCSV: TLS_FALLBACK_SCSV indica al servidor que el cliente está reintentando con una versión inferior, lo que permite al servidor rechazar las degradaciones ilegítimas.

Los mensajes del protocolo deben quedar comprometidos desde el primer intercambio. La no maleabilidad significa que un adversario no puede modificar un texto cifrado o una firma y conseguir que se valide en un contexto diferente. AEAD proporciona no maleabilidad del texto cifrado: cualquier modificación invalida la etiqueta de autenticación. En el nivel del protocolo, el hash de la transcripción garantiza que el intercambio Finished al final del handshake quede comprometido con cada mensaje enviado. Esto evita los ataques de cortar y pegar: combinar mensajes de dos sesiones distintas no puede producir un valor Finished válido para ninguna de las dos sesiones. Los esquemas de compromiso (compromisos mediante hash) extienden esta propiedad a los flujos de protocolo que requieren comprometerse antes de revelar la información.

Los protocolos complejos suelen fallar en los límites de la máquina de estados. Si una transición de estado es ambigua —¿qué ocurre si el mensaje 3 llega antes que el mensaje 2?, ¿qué ocurre si llega un tipo de mensaje inesperado?—, las implementaciones pueden divergir y crear incoherencias que un adversario puede aprovechar. Las especificaciones del protocolo deben definir: la máquina de estados completa (todos los estados y las transiciones válidas), el comportamiento ante entradas inesperadas (rechazarlas con un error específico o ignorarlas silenciosamente), los tiempos de espera y los límites de retransmisión, y la limpieza de la sesión. SSL/TLS sufrió históricamente divergencias entre las máquinas de estados de sus implementaciones: CVE-2014-0160 (Heartbleed) fue, en esencia, un fallo de la máquina de estados en el que una solicitud heartbeat se procesaba en un estado donde la memoria no estaba correctamente acotada.

Los protocolos criptográficos rara vez se utilizan de forma aislada. Un protocolo AKE establece una clave de sesión que posteriormente utiliza un protocolo de la capa de aplicación. Si el protocolo AKE y el protocolo de aplicación se diseñan de forma independiente, sin tener en cuenta la componibilidad, sus interacciones pueden comprometer la seguridad. El marco Universal Composability (UC) (Canetti, 2001) proporciona un modelo riguroso para la composición de protocolos: un protocolo es UC-secure si sigue siendo seguro al componerse arbitrariamente con otros protocolos UC-secure. TLS 1.3, Signal y Noise buscan ofrecer seguridad componible. En la práctica: utilice la vinculación de canal (exporte el hash de la transcripción) para vincular la sesión AKE con la autenticación posterior de la aplicación y evitar el reenvío de credenciales entre sesiones establecidas mediante el mismo protocolo AKE.

Los diseñadores de protocolos repiten una y otra vez las mismas clases de errores. (1) Criptografía casera: implementar cifradores de bloque, MAC o derivación de claves personalizados sin revisión por expertos. (2) Confianza implícita: suponer el origen de un mensaje basándose en el contexto de red en lugar de en una prueba criptográfica. (3) Seguridad opcional: hacer configurable el cifrado o la autenticación, lo que conduce inevitablemente a una degradación. (4) Tokens de larga duración sin revocación: emitir JWTs o claves de sesión con una vigencia prolongada y sin ningún mecanismo de revocación. (5) Ignorar el canal de errores: no autenticar los mensajes de error permite al adversario inyectar errores para influir en el comportamiento del protocolo. (6) Utilizar el cifrado para autenticar: cifrar los datos no autentica su origen sin un MAC o una firma.

El diseño seguro de protocolos aplica principios establecidos: el modelo de adversario Dolev-Yao (un adversario que controla la red), los principios de Abadi-Needham (identidad explícita y mensajes autosuficientes), la frescura mediante nonces o marcas de tiempo, la separación de claves mediante HKDF con etiquetas distintas, la vinculación de las credenciales de autenticación a la sesión, la divulgación mínima de información, la prevención de degradaciones mediante la autenticación de la transcripción, la no maleabilidad mediante AEAD y el hash de la transcripción, máquinas de estados claras con gestión de errores definida y componibilidad mediante demostraciones de seguridad en el modelo UC. Las infracciones de estos principios son el origen de casi todas las vulnerabilidades criptográficas conocidas en el nivel de protocolo.