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/rfc3161RFC 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
