Verificar una firma bien

Un servicio de CifraLab recibe un mensaje firmado junto con la clave pública para verificarlo, y acepta el mensaje si la firma cuadra con esa clave. El agujero es enorme: un atacante genera su propio par de claves, firma el mensaje que quiera con su privada, y adjunta su pública. La firma «es válida» —cuadra con la clave que vino pegada— pero no prueba nada sobre el origen, porque el que verifica confió en la clave que le dio el propio mensaje. Verificar una firma solo tiene sentido contra una clave en la que ya confías por otra vía: una clave fijada de antemano, o un certificado que una autoridad de confianza vincula a esa identidad. El arreglo es verificar contra la clave esperada, no contra la que llega adjunta.

El fallo es cerrar el círculo con el atacante dentro: el mensaje trae su propia clave de verificación, así que cualquiera «firma válido».

Otro servicio firma con una clave RSA de 1024 bits que lleva años en uso. El tamaño de clave no es un detalle: las claves que se consideraban suficientes hace una década hoy están al alcance, y una firma hecha con una clave débil se puede llegar a falsificar sin tener la privada. Lo mismo pasa con algoritmos de firma que ya se dieron por superados. El criterio es usar tamaños y algoritmos vigentes —RSA de al menos 2048 bits, o curvas elípticas modernas— y tratar el material de firma como algo que caduca: se revisa y se renueva, no se deja «porque siempre funcionó». El arreglo es migrar a una clave de tamaño y algoritmo actuales y retirar la vieja.

El fallo no está en el acto de firmar: está en firmar con una llave que el tiempo ya volvió forzable.

Un tercer servicio lee del propio mensaje qué algoritmo usar para verificar la firma, y acepta lo que el mensaje declare —incluido un valor que significa «sin firma»—. Eso deja al atacante elegir el camino más débil: declara un algoritmo roto, o directamente «ninguno», y la comprobación pasa sin firma real. Quien verifica no puede delegar en el mensaje la decisión de cómo comprobarse: el algoritmo de verificación se fija en el servicio, de antemano, y una firma que llega con otro algoritmo o sin él se rechaza. El arreglo es fijar el algoritmo esperado en el verificador y no aceptar que el mensaje lo cambie.

Es el mismo patrón del módulo anterior disfrazado: el que verifica confía en un dato que controla el atacante, esta vez el algoritmo en vez de la clave.

Viste tres formas de que una firma «válida» no pruebe nada: confiar en la clave adjunta, firmar con una clave débil y dejar que el mensaje elija el algoritmo. Abre el laboratorio, recorre esas tres verificaciones y lee el código que la auditoría anotó al cerrar la sala.