Inicio / Blog / Trusted timestamping

Trusted timestamping

Publicado el 18/11/2014, por Jesús Díaz (INCIBE)
Trusted timestamping

El sellado temporal confiable, o trusted timestamping, es una funcionalidad criptográfica con casos de uso más limitados que los de primitivas más comunes como el cifrado y cálculo de hashes. No obstante, pueden ser muy útiles en múltiples ocasiones. Brevemente, un sello temporal es una marca de tiempo que garantiza que una determinada información existía en el momento indicado.

Sus aplicaciones son varias. Por ejemplo, se puede utilizar para crear visados y apuestas electrónicas de forma que no se pueda modificar su fecha posteriormente (para extender la validez del visado o crear apuestas ganadoras una vez sabido el resultado del evento); para protección de autoría, ya que permite probar que se poseía una información antes de hacerla pública; o para la protección de logs de sistemas de forma que luego no se puedan manipular para alterar la secuencia temporal asociada a un incidente, etc.

Son varios los tipos de sellado temporal confiable. Hay sistemas que incluyen el instante temporal (por ejemplo, fecha y hora UTC); y los hay que establecen una cadena temporal, donde no necesariamente se introduce un instante temporal explícito, sino que se prueba que una determinada información existía antes de otra: esto se conoce como linked timestamping. También hay sistemas que basan toda su seguridad en la confianza puesta en una autoridad, la Time Stamping Authority (TSA) y sistemas descentralizados (p.e., basados en Bitcoin) que no tienen esa dependencia. En este post se verán casos prácticos de sistemas en funcionamiento de los dos últimos tipos.

Sellado convencional: Autoridades confiables y RFC 3161

La solución más clásica es la basada en Time Stamping Authorities. La confianza que se deposita en estas autoridades es similar a la que recae sobre las autoridades de certificación en las PKIs de tipo X.509. Es decir, para una autoridad corrupta sería trivial cambiar los sellos temporales emitidos. De hecho, lo que hace una TSA es firmar las peticiones de sellado temporal que recibe de sus clientes, incluyendo el instante de tiempo en que se emite la firma. Evidentemente, una TSA no devuelve «simplemente» firmas de los datos recibidos.

En el RFC 3161 se establece un total de 11 requisitos para las TSAs. Entre estos requisitos, sobre la información temporal introducida en mensajes enviados por TSAs, destacan los tres primeros:

  1. La TSA debe usar una fuente fiable de tiempo (en este aspecto, el RFC 3628 da indicaciones sobre los requisitos para las TSAs).
  2. La TSA debe incluir un valor temporal fiable para cada token temporal.
  3. La TSA debe incluir un entero único para cada nuevo token temporal generado.

En el RFC 3161 se establece también la sintaxis de las peticiones y las respuestas, el tipo de información temporal (incluyendo información de la precisión proporcionada), y distintas opciones de transporte: e-mail, ficheros, sockets o HTTP, con la posibilidad de incorporar nuevos mecanismos.

En concreto, las respuestas deben tener la siguiente estructura:


TimeStampResp ::= SEQUENCE {
   status PKIStatusInfo,
   timeStampToken TimeStampToken OPTIONAL }

Donde el campo «importante» es el timeStampToken, que contendrá una marca temporal, firmada por la TSA.

Probando con servicios gratuitos

Openssl, proporciona el comando ts (openssl ts), que implementa utilidades para clientes y servidores compatibles con el RFC 3161. Con estos comandos, se puede generar, procesar y verificar peticiones y respuestas. Además, openssl proporciona la utilidad tsget, que implementa un cliente de timestamping que utiliza HTTP(S) como mecanismo de transporte. Por último, hay disponibles autoridades que, también utilizando HTTP(S) como transporte, atienden gratuitamente peticiones de sellado temporal.

Para probar, se puede utilizar time.certum.pl (cuyo certificado raíz, Certum CA, de Unizeto Technologies S.A., viene instalado por defecto en Firefox), o la autoridad de safecreative.org, que permite hasta 5 peticiones diarias gratuitas.

Por ejemplo, si se quiere obtener un sellado temporal del fichero file.txt, se puede hacer como sigue (donde es posible intercambiar la URL de time.certum.pl por la de safecreative.org, o por cualquier otra autoridad que cumpla el RFC 3161):

$ openssl ts -query -data file.txt -cert | tee file.tsq | tsget -h http://time.certum.pl -o file.tsr

Para verificar la respuesta, es importante el modificador -cert, que hará que la autoridad incluya el certificado de firma utilizado. A continuación, se pueden imprimir la petición y la respuesta, o verificar esta última con los siguientes comandos:


# Imprimir la petición en formato texto
$ openssl ts -query -in file.tsq -text
# Imprimir la respuesta en formato texto
$ openssl ts -reply -in file.tsr -text
# Verificar la respuesta utilizando el certificado CA raíz en CA.crt
$ openssl ts -verify -queryfile file.tsq -in file.tsr -CAfile CA.crt

Una observación: al imprimir la petición, se ve que los datos enviados para sellar no son directamente el contenido del fichero, sino su hash. Por defecto, openssl utiliza SHA1, aunque esto se puede controlar especificando el algoritmo de hashing a utilizar (por ejemplo -sha256 o -sha512). Esto es especialmente importante, ya que un sellado temporal debería ser robusto al paso del tiempo y, en este caso, la elección de una función hash adecuada es esencial. La siguiente figura muestra un ejemplo de respuesta:


Status info:
Status: Granted.
Status description: unspecified
Failure info: unspecified
TST info:
Version: 1
Policy OID: 1.2.616.1.113527.2.2.5
Hash Algorithm: sha1
Message data:
0000 - 63 bb fe a8 2b 88 80 ed-33 cd b7 62 aa 11 fa b7 c...+...3..b....
0010 - 22 a9 0a 24  "..
$ Serial number: 0x038D7EA78B6DAC
Time stamp: Oct 22 09:23:43 2014
GMT Accuracy: 0x01 seconds, unspecified millis, unspecified micros
Ordering: no
Nonce: 0x975E8BC93BAA2694
TSA: DirName:/C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum
Time-Stamping Authority Extensions:

Sellado distribuido con Bitcoin

Con la llegada de Bitcoin han aparecido también servicios que hacen uso de su novedosa infraestructura para crear timestamps. En estos servicios, siguiendo el modelo descentralizado de Bitcoin, no es necesario confiar en ninguna autoridad central, sino en las propiedades criptográficas de Bitcoin.

Aunque, en este caso, el objetivo es normalmente incluir una función de los datos a sellar dentro de la cadena de bloques de Bitcoin, la forma de hacerlo varía de unas propuestas a otras.

Por ejemplo, BTProof crea direcciones de Bitcoin a partir de los datos que se quieren sellar. Estas direcciones no son direcciones «normales», ya que no tienen par de claves pública y privada asociadas (dado que no se han generado siguiendo el procedimiento «habitual»). Por lo tanto, una vez hecho un pago a esa dirección, ésta aparecerá en la cadena de bloques y, dado que no hay una clave privada asociada, no se podrá gastar el dinero contenido en ella y la transacción no podrá ser «podada», por lo que siempre aparecerá en la cadena de bloques.

Para verificar los timestamps, es suficiente con repetir el proceso para obtener la dirección, y consultarla en la cadena de bloques (por ejemplo, mediante blockexplorer). El bloque en el que se haya introducido la transacción asociada incluirá la fecha en la que fue añadido a la cadena.

Otra opción parecida es Crypto Stamp. En este caso, se sigue un procedimiento parecido, pero para minimizar el número de transacciones a realizar, se juntan todos los datos a sellar de un mismo día utilizando un árbol Merkle (lo cual implica un tiempo de sellado de al menos un día), y de su raíz se deriva la dirección de Bitcoin a la que realizar el pago.

- Arbol Merkle del sellado temporal para el mensaje «Crypto Stamp is born» -

El hecho de agrupar todas las transacciones (para su sellado temporal) de un mismo día en un único árbol Merkle tiene varias implicaciones. Por un lado, la precisión máxima del sello temporal es de un día. Por otro, se reduce el número de transacciones, abaratando el coste del servicio y minimizando las transacciones «dust» (término que se utiliza en Bitcoin para transacciones con un importe muy bajo).

Por último, y lo más importante, para verificar un sellado temporal es necesario tener información del árbol Merkle en el que ha sido incluido el hash del contenido sellado, a partir del cual se puede derivar la dirección Bitcoin a la que se ha hecho el pago. Crypto Stamp almacena esta información en un fichero .csp (Crypto Stamp Proof), que se puede descargar y procesar con utilidades disponibles desde la propia página web.

Dada la naturaleza de Bitcoin, es inevitable que todos los servicios basados en este sistema tengan un coste asociado. No obstante, los hay que son prácticamente gratuitos. En el caso de BTProof, tiene un coste mínimo de 1 satoshi (aproximadamente 0.00000001 bitcoins, unos 0.000003€ al cambio actual), aunque es aconsejable utilizar cantidades algo mayores ya que, para evitar congestiones en la red, los mineros y clientes principales tienden a ignorar transacciones tan pequeñas. En Crypto Stamp, el pago hecho para la transacción es de 0.00000001 BTC que, junto con la tasa necesaria para los mineros, corren a cargo del propio servicio.

Tanto BTProof como Crypto Stamp ofrecen APIs para interactuar con sus servicios.

Soluciones integrales

Como se ha indicado al principio, esta funcionalidad criptográfica tiene importantes aplicaciones. De hecho, existen múltiples productos que incorporan esta funcionalidad como parte de una solución más completa (para emitir facturas electrónicas enviadas por email, contratos, etc.). Entre estos productos y servicios, los hay españoles, como eGarante, que permite, entre otros servicios, obtener gratuitamente un sellado temporal de un email simplemente poniendo en copia a mailsigned@egarante.com; evicertia, que permite registro y tres certificaciones gratuitas, a modo de prueba, además de las suscripciones de pago; y la ya mencionada safecreative.