Qué se firma exactamente.

Una firma digital no firma un documento. Firma una secuencia exacta de bytes. Entre esos bytes y lo que una persona ve en pantalla hay formatos, estructuras y programas que interpretan, y en ese espacio ocurrieron la mayoría de los ataques prácticos contra firmas de documentos de las últimas dos décadas. La criptografía estaba intacta; lo que falló fue la respuesta a una pregunta en apariencia simple: qué se firmó, exactamente.

CMS: el sobre de la firma

Casi todas las firmas de documentos, en PDF y en muchos otros formatos, se empaquetan en una estructura llamada CMS (Cryptographic Message Syntax), heredera del estándar PKCS #7 de RSA Laboratories y especificada hoy en el RFC 5652. Su variante para firmar se llama SignedData, y su estructura merece verse por dentro.

El punto clave está en los atributos firmados. Cuando existen, y en la práctica siempre existen, la firma no se calcula sobre el resumen del documento sino sobre un pequeño conjunto de atributos codificados en DER, uno de los cuales, messageDigest, contiene ese resumen. Es un resumen de dos niveles: el documento queda atado al atributo, y el atributo a la firma. Eso permite firmar, junto con el contenido, datos sobre la propia firma.

• contentType impide que una firma sobre un tipo de contenido se reinterprete como firma sobre otro.
• signingCertificateV2, definido en el RFC 5035, contiene el resumen del certificado del firmante. Sin él, alguien podría reemplazar el certificado adjunto por otro que contenga la misma clave pública pero un titular o una política diferentes, y la firma seguiría verificando. Los formatos de firma avanzada lo exigen.
• signingTime es la hora que declara el equipo del firmante. Está firmada, pero sólo prueba lo que el firmante dijo, no cuándo ocurrió. La prueba de tiempo viene de un sello de tiempo de un tercero, en los atributos no firmados.

La firma dentro de un PDF

Un PDF firmado contiene la estructura CMS dentro del propio archivo. Eso plantea un problema circular: la firma debe cubrir el archivo, pero el archivo contiene la firma. La norma ISO 32000 lo resuelve dejando un hueco. El diccionario de firma reserva un espacio de tamaño fijo, la entrada /Contents, que se llena con la estructura CMS en hexadecimal, y declara en /ByteRange qué bytes del archivo se resumieron: todo, salvo el hueco.

El filtro de la firma indica el formato del contenido. En las firmas avanzadas europeas, el perfil PAdES usa ETSI.CAdES.detached: una firma CMS separada, con los atributos que exigen las normas de firma avanzada, sobre los bytes del rango.

Revisiones incrementales: el documento que sigue cambiando

PDF permite modificar un archivo sin reescribirlo: los cambios se agregan al final, como una nueva revisión que redefine los objetos alterados. Es lo que posibilita que varias personas firmen el mismo documento, una tras otra, sin invalidar las firmas anteriores: cada firma cubre su revisión y todas las previas, y lo que viene después queda fuera de su rango.

Esa misma flexibilidad es la superficie de ataque. Si una revisión posterior puede cambiar lo que se muestra, un documento puede exhibir contenido nuevo mientras la firma anterior sigue verificando, porque los bytes que cubre no cambiaron. Las normas prevén controles. Una firma de certificación puede declarar, con permisos DocMDP, qué cambios se admiten después: ninguno, sólo completar formularios, o también anotaciones. Y el validador debe comparar las revisiones y advertir cualquier cambio no permitido.

En 2019, un equipo de la Universidad del Ruhr en Bochum probó las tres primeras técnicas contra 22 visores de escritorio y 7 servicios de validación en línea: 21 visores y 5 servicios fueron vulnerables a al menos una. En 2021 el mismo grupo presentó los ataques de sombra, que no violan ninguna regla del formato sino que abusan de los cambios permitidos. Los fabricantes corrigieron la mayoría de los casos, pero la lección perdura: la seguridad de una firma en un documento depende tanto del validador como del algoritmo.

XML y otros formatos

Las firmas XML, base del perfil XAdES, enfrentan el mismo problema con otra forma. Como un mismo documento XML puede escribirse de muchas maneras equivalentes, la firma se calcula después de una canonicalización, y cubre referencias a partes del documento seleccionadas mediante transformaciones. Si el verificador comprueba la firma sobre un elemento y la aplicación procesa otro con el mismo nombre en otro lugar, el resultado es un ataque de envoltura de firma, una familia que afectó a sistemas de inicio de sesión único durante años. El principio de defensa es el mismo: la aplicación debe usar exactamente lo que el verificador verificó.

← Todas las notas