Verificar un expediente probatorio

Qué contiene el expediente

Los nombres de archivo están en inglés y no cambian con el idioma del documento, para que un programa de verificación busque un nombre fijo en lugar de cinco grafías.

• manifest.json enumera cada archivo con su tamaño y su SHA-256.
• events.json contiene la cadena: cada evento con su número de orden, su momento, su contenido, el hash del eslabón anterior, su propio hash de cadena y un sello.
• proofs.json contiene las rutas desde los eventos hasta la raíz de su hora.
• anchors/ contiene, por cada raíz horaria, el sello de tiempo tal como lo emitió el servicio de sellado de tiempo, como token RFC 3161.
• seals.json contiene las claves públicas con las que se verifican los sellos.
• El documento probatorio en dos formas, para leer, además del mensaje tal como se envió y el aviso tal como se entregó al servicio de envío.

Las cuatro comprobaciones

Se apoyan unas en otras: la primera muestra que los archivos no han cambiado, la última que la cadena ya existía en un momento que estableció un tercero.

• Los archivos frente al manifiesto. Calcule el SHA-256 de cada archivo y compárelo con la lista. Si uno difiere, el expediente se modificó después de registrarse.
• La cadena. Cada evento lleva el hash del anterior, y el primero lleva un valor inicial que ata la cadena a una entrega de un remitente. Por eso una secuencia correcta de eventos no puede trasladarse a otra entrega.
• Los sellos. Cada sello recae sobre los bytes en bruto del hash de cadena, con ECDSA sobre P-256 y SHA-256. Lo verifica con openssl dgst y la clave pública del expediente.
• El sello de tiempo. La raíz de la hora se presentó a un servicio de sellado de tiempo; el token en anchors/ se verifica con openssl ts y el certificado de ese servicio.

Qué acredita una comprobación y qué no

La cadena y los sellos acreditan que nada ha cambiado desde el registro. No acreditan cuándo existía el registro, porque los hashes son nuestros y las horas figuran en nuestros propios datos. Para eso está el sello de tiempo: un tercero vio la raíz de esa hora y firmó sobre ella.

Los sellos son nuestros. El expediente no acredita quién custodia la clave, y así lo dice él mismo. Por eso el certificado del servicio de sellado de tiempo se obtiene de ese servicio y no de nosotros; de lo contrario estaría comprobando nuestra cadena con un eslabón nuestro.

Si falta el directorio anchors/, no hay sello de tiempo externo para ese periodo, y el documento probatorio lo dice con todas las letras. La cadena queda entonces fija respecto de sí misma, pero el momento en que existía no se ha establecido de forma independiente.

Si pone el aviso conservado junto al ejemplar que llegó al destinatario, las cabeceras difieren y también el SHA-256. Eso no indica una modificación posterior: el servicio de envío añade cabeceras propias al salir. Lo comparable es el contenido, y el hash del manifiesto acredita que el archivo conservado no ha cambiado desde entonces.

Qué necesita

Openssl y alguna forma de leer JSON, nada más. La cadena y los sellos se comprueban sin red alguna. Para el sello de tiempo necesita una vez el certificado del servicio, que obtiene de ese mismo servicio.

Las líneas de comando exactas están en format.md dentro del expediente, incluidas las dos opciones en las que una comprobación falla sin que nada esté mal: la raíz se pasa como digest y no como archivo, y el token se lee con la opción para un token suelto.