Introducción a TimeStamping o Sellado de Tiempo - Parte II

Continuando con el Sellado de Tiempo, esta vez he realizado una interpretación y resumen de la RFC 3161 y RFCs asociadas.

Introducción

El sellado de tiempo nació, ya hace cientos de años, por la necesidad de las personas de demostrar autoría de sus teorías y descubrimientos. Hoy en día su aplicabilidad es más amplia pero su principio es el mismo, dar fe de la existencia de un dato desde un determinado momento en el tiempo.

La RFC 3161 confeccionada por IETF (Internet Engineering Task Force) define la implementación del protocolo de Sellado de Tiempo. Es decir, la forma en que se debe realizar el proceso, los medios y el contenido de los mensajes que se manipularan en una operación de Sellado de Tiempo. La RFC es ampliamente usada y es la base de otros estándares de sellado de tiempo, por lo que el buen entendimiento del mismo, asegura en gran medida, una buena comprensión de los restantes.

¿Que es el sellado de tiempo?

El Sellado de Tiempo es un servicio, que permite dar fe de que un dato ha existido desde un momento determinado en el tiempo y que el mismo no ha sido alterado.
En el proceso de sellado de tiempo, según el esquema y la norma que se utilice, actúan mínimamente dos partes, un SOLICITANTE y una AUTORIDAD DE SELLADO DE TIEMPO, TSA por su acrónimo en ingles, que actúa como una tercera parte de confianza (TTP).

¿Cuál es la función de la Autoridad de Sellado de Tiempo?

La función de la Autoridad de Sellado de Tiempo (TSA) es sellar un dato para dejar evidencia, indicando, que el dato ha existido antes de un tiempo particular. Esto puede ser usado, por ejemplo, para verificar que una firma digital fue aplicada a un mensaje antes de que el certificado correspondiente fuera revocado, así permitir a un certificado de clave publica revocado, ser usado para verificar firmas creadas antes del tiempo de revocación. Esta es una operación importante de la infraestructura de clave pública (PKI).
La TSA tiene que firmar cada uno de los mensaje de sellado de tiempo con una clave reservada precisamente para este propósito. Una Autoridad de Sellado de Tiempo (TSA) puede tener distintas claves privadas, por ejemplo: para ordenar diferentes políticas, diferentes algoritmos, diferentes tamaños de claves privadas o para incrementar la performance. El certificado correspondiente tiene que contener solamente una instancia de “extended key usage” como se define en la RFC2459 sección 4.2.1.13.

¿Cuáles son los requisitos necesarios para una TSA?

Como lo indica la RFC 3161, los requisitos de la Autoridad de Sellado de Tiempo (TSA) son los siguientes:

• 1.Usar una fuente de tiempo digna de confianza.
2.Incluir un valor de tiempo fiable, en cada respuesta (TimeStamp Token).
• 3.Incluir un entero único, para cada nuevo TimeStamp Token generado.
• 4.Producir un TimeStamp Token, para cada requerimiento valido recibido de un SOLICITANTE.
• 5.Incluir dentro de cada TimeStamp Token un identificador único para indicar la política de seguridad, por la cual el token fue creado.
• 6.Solamente un sellado de tiempo, tiene la representación de un hash de dato.
• 7.Examinar el OID de la función hash de un solo sentido, resistente a colisiones y verificar que la longitud del valor hash es consistente con el algoritmo de hash.
• 8.No examinar la huella (valor hash del dato) a ser estampado, de ninguna manera (otra verificación que no sea chequear su longitud, como especifica el punto anterior).
• 9.No incluir ninguna identificación de la entidad SOLICITANTE, en el TimeStamp Token.
• 10.Firmar cada TimeStamp Token usando la clave generada exclusivamente para este propósito y tener la clave indicada para el correspondiente certificado.
• 11.Incluir información adicional en el TimeStamp Token, si son consultadas por el SOLICITANTE usando el campo “extension”, solo para las extensiones que son soportadas por la TSA. Si esto no es posible, la TSA debe responder con un mensaje de error.

¿Como se realiza el proceso de Sellado de Tiempo?

Como primer mensaje de este mecanismo, una entidad SOLICITANTE requiere un TimeStamp Token, enviando una solicitud, un TimeStampReq, a la TSA. El TimeStampReq es una estructura de datos formada por los siguientes campos:

• version: define la versión del timestamp requerido.
• messageImprint: el OID del algoritmo hash y el valor hash, del dato a ser sellado.
• reqPolicy: si es incluido, indica la política de la TSA bajo la cual el TimeStamp Token debe ser generado.
• nonce: si es incluido permite al cliente verificar la puntualidad de la respuesta, cuando no esta disponible un reloj de forma local.
• certReq: si esta presente, indica si la respuesta debe o no incluir el certificado público de la TSA.
• extension: es un campo reservado para incluir información adicional al requerimiento en el futuro.

Los requerimientos o mensajes viajan por la red, por alguno de los protocolos de internet, como: HTTP, Socket TCP, Email y FTP.
Como segundo mensaje, la TSA responde enviando una respuesta, un TimeStampResp, a la entidad SOLICITANTE. EL TimeStampResp es una estructura de datos formada por los siguientes campos:

• PKIStatusInfo: es otra estructura de datos interna, que contiene información sobre la presencia del TimeStamp Token. También posee información de depuración en el caso de errores.
  
• TimeStampToken: es otra estructura de datos interna, definida por la RFC 5652- Cryptographic Message Syntax, que contiene los datos (el valor hash del requerimiento) firmados digitalmente por la TSA y el tiempo en el cual el TimeStamp Token fue creado (genTime). Esta estructura es compleja.
  

Al recibir la respuesta, la entidad SOLICITANTE, debe verificar el campo estado de error (PKIStatus), retornado en la respuesta. Sino existen errores, esta debe verificar varios campos contenidos en el TiemStamp Token y la validez de la firma digital del TimeStamp Token. En particular, se deberá verificar que lo que fue sellado corresponde a lo que fue solicitado para ser sellado (messageImprint == hasedMessage). El SOLICITANTE debe verificar que el TimeStamp Token contiene el certificado identificador de la TSA (Chain TSA Certificates), el valor hash correcto y el OID correcto del algoritmo hash. A continuación deberá verificar la puntualidad de la respuesta verificando el tiempo incluido en la respuesta, contra una referencia confiable de hora local. Si cualquiera de las verificaciones falla, el TimeStamp Token debe ser rechazado.
Dado que el certificado de la TSA pudo haber sido revocado, el estado del certificado deberá ser chequeado (CRLs), para verificar que el certificado es valido.
Luego la aplicación cliente debe chequear la política, para determinar si esta corresponde con el token que fue emitido para la aplicación.

¿Que estándares se pueden utilizar?

Dentro de los estándares que definen como implementar el sellado de tiempo se encuentran:
Internet X.509 Public Key Infrastructure Time-Stamp Protocol.
ANSI ASC X9.95 Standard.
ISO/IEC 18014.
Restricciones de seguridad ETSI TS 101 861.

¿Que guías existen para la creación de políticas TSAs?

Existe documentación que se puede referenciar a la hora de confeccionar políticas para Autoridades de Sellado de Tiempo.
RFC 3628 - Policy Requirements for Time Stamping Authorities (TSAs).
ETSI TS 102 023 - Policy requirements for time-stamping authorities

Referencias

RFC 3161: http://tools.ietf.org/html/rfc3161
RFC 5652: https://tools.ietf.org/html/rfc5652
RFC 3628: http://www.ietf.org/rfc/rfc3628.txt
ANSI ASC X9.95: http://en.wikipedia.org/wiki/ANSI_ASC_X9.95_Standard
Trusted timestamping: http://en.wikipedia.org/wiki/Trusted_timestamping#Classification

Introducción a TimeStamping o Sellado de Tiempo - Parte I

El timestamping es un servicio que se utiliza como una entidad externa de confianza, su funcion es dar fe, de que un dato ha existido desde un determinado momento en el tiempo, y que el mismo no ha sido modificado, esto se consigue a través de la respuesta de la TSA (Autoridad de Sellado de Tiempo). Dicha respuesta es asociada posteriormente por el requestor (solicitante del sellado de tiempo) al dato que se quiere dar fe de su existencia.

El sellado de tiempo es descrito por la RFC 3161 - Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP). La RFC describe los aspectos generales del protocolo, requerimientos de la TSA (Autoridad de Sellado de Tiempo), formato de los mensajes, como se deben realizar las transacciones, métodos de transporte y consideraciones de seguridad.
Este servicio se puede utilizar con datos que han sido firmados digitalmente o no. Ya que lo que se utiliza es su huella (valor hash) que se obtiene de aplicar una función hash a los datos o conjunto de datos que se quieren estampar.

Algunas de las cosas sobre las que se debe tener claridad para evitar confusiones son:

• El documento a estampar no viaja hasta la autoridad de sellado de tiempo, solo lo hace su digesto (valor del hash) a través de un mensaje de requerimiento, TimeStampReq.
  
• Una de sus funciones es determinar la existencia de un dato desde un instante en el tiempo, cuando dice dato, dice cualquier tipo de datos, inclusive una firma digital.
  
• TimeStamping es un servicio que puede ser transportado por varios protocolos de internet como: Email,HTTP y TCP.
  
• La respuesta de la TSA, el TimestampResp, es una estructura de datos la cual contiene otras estructuras de datos, como por ejemplo el TimestampToken. Este ultimo a su vez, en uno de sus campos, contiene firmado digitalmente (con la clave privada de la TSA) el valor hash del dato que fue enviado previamente por el requestor (quien solicita el sellado de tiempo). Y el campo "genTime", el tiemstamp (YYYYMMDDHHMMSS.Z) del momento en que se realiza el sellado

Cosas que me parecieron, importante a tener en cuenta son:

• El master clock o fuente de tiempo para la TSA debe ser de referencia legal para la región de la misma. Es decir, un master clock certificado por algún organismo nacional o internacional. Los instrumentos de mayor precisión, considerados de straum 1 dentro el protocolo NTP, pueden ser GPS de gran exactitud
• Cada dato que llegue a la TSA debe ser firmado digiltamente con su clave privada.
• El algoritmo que genera el hash de los datos debe ser de un solo sentido (inyectivo), bien conocido y resistente a colisiones.
• Una TSA puede tener varias firmas digitales dependiendo de la cantidad de políticas que se posean en la misma.
• Las respuestas TimestampResp, poseen una estructura de datos opcional ,PKIFailureInfo, la cual puede brindar información muy valiosa a la hora de detectar errores.
• La clave de firma de la TSA, debe ser lo suficientemente larga para asegurar un ciclo de vida mas bien largo. Aquí se debería considerar o evaluar cada cierto tiempo, la evolución de la tecnologías que hagan mas eficiente ataques de diccionarios, de colisión y otros que vayan surgiendo en el tiempo.
• Las ventanas de tiempo entre una solicitud y una respuesta deberían considerarse a la hora de detectar ataques Man in the Middle

Por ahora, esto es lo mas importante que me ha quedado de la RFC, seguiré ampliando en otro post.