Productos y servicios.
| Autor | José Luis Ferrer Gomila. |
| Cargo | Doctor en Informática. Ingeniero de Telecomunicaciones. Profesor de Ingeniería Telemática en la Universitat de les Illes |
| Páginas | 49-74 |
SERVICIO DE SELLADO TEMPORAL: ESTANDARIZACIÓN EN INTERNET
El texto que se expone a continuación es el documento del grupo de trabajo PKIX Working Group, que intenta especificar un futuro estándar en relación al servicio de sellado temporal. Esta versión fue hecha pública el mes de enero del presente año. Su vigencia es de 6 meses, y antes de su expiración debe publicarse una nueva versión o convertirse en propuesta de estándar. Sus autores son C. Adams (de la empresa Entrust Technologies), P. Cain (de BBN), D. Pinkas (de Bull) y R. Zuccherato (de Entrust Technologies). La traducción es libre y se han eliminado aquellos aspectos más técnicos que no son relevantes para la comprensión del mismo.
“Internet X.509 Public Key Infrastructure Time Stamp Protocol (TSP)”
Copyright (C) The Internet Society (1999). All Rights Reserved
Estado del documento
Este documento es un borrador de Internet (Internet-Draft) y está en plena consonancia con todo lo previsto en la Sección 10 de la RFC 20261. Los borradores de Internet son documentos de trabajo del Internet Engineering Task Force (IETF), sus áreas, y sus grupos de trabajo. Nótese que otros grupos también pueden distribuir documentos de trabajo como borradores de Internet.
Los borradores de Internet son documentos válidos por un máximo de seis meses y pueden ser actualizados, substituidos, o quedar obsoletos por otros documentos en cualquier momento. No es apropiado utilizar borradores de Internet como material de referencia o citarlos de otra forma distinta a “trabajo en curso”. Se puede acceder a la lista de borradores de Internet en curso en http://www.ietf.org/ietf/1id-abstracts.txt
Resumen
El servicio de sellado temporal respalda declaraciones de prueba de que unos datos existían antes de un instante de tiempo concreto. Este documento describe el formato de una petición enviada a una Autoridad de Sellado Temporal (AST) y de la respuesta que se devuelve. También establece varios requisitos de seguridad relevantes para la operación de la AST, en relación al procesado de las peticiones para generar las respuestas. Una AST puede ser operada como un servicio de Tercera Parte de Confianza (TTP, por Trusted Third Party), aunque otros modelos operacionales pueden ser apropiados, por ejemplo una organización puede necesitar una AST para usos internos de sellado temporal.
Los servicios de no repudio [ISONR] requieren de la capacidad para establecer la existencia de unos datos antes de un instante de tiempo específico. Este protocolo puede utilizarse como un bloque de construcción para dar soporte a tales servicios. En un anexo se proporciona un ejemplo de como probar que una firma digital fue generada durante el período de validez de un certificado de clave pública.
-
Introducción
Para asociar unos datos con un punto particular en el tiempo, puede necesitarse el uso de una Autoridad de Sellado Temporal (AST). Esta Tercera Parte de Confianza proporciona una “prueba de existencia” para estos datos particulares en un instante de tiempo.
El papel de la AST es sellar temporalmente unos datos para establecer la evidencia que indique el día y hora en que existían los datos. Entonces este servicio puede utilizarse, por ejemplo, para verificar que una firma digital se aplicó a un mensaje antes de que el correspondiente certificado fuera revocado, permitiendo así que un certificado de clave pública revocado pueda ser utilizado para verificar firmas realizadas antes del instante de revocación. Esta es una operación importante de la infraestructura de clave pública.
La AST también puede utilizarse para indicar la hora de entrega cuando una fecha límite es crítica, o para indicar la hora de una transacción para las entradas en un registro. Realizar un listado exhaustivo de posibles usos de una AST queda fuera del alcance de este documento.
Este estándar no establece los requisitos globales de seguridad para la operación de una AST, de igual manera que otros estándares PKIX no establecen tales requisitos para la operación de una AC (Autoridad de Certificación). Más bien, se prevé que una AST dará a conocer a sus clientes potenciales las políticas que implementa para asegurar la generación del sello temporal precisa, y los clientes sólo utilizarán los servicios de una AST si piensan que estas políticas satisfacen sus necesidades.
-
La AST
La AST es una TTP que crea tokens2 de sellado temporal con el fin de indicar que unos datos existían en un instante particular en el tiempo. En este documento una “petición válida” debe interpretarse como aquella que se puede decodificar correctamente, es de la forma que se especifica en la Sección 2.4, y procede de un subscriptor soportado por la AST.
2.1. Requisitos de la AST
Una AST debe:
-
utilizar una fuente de tiempo confiable.
-
incluir un valor de tiempo confiable para cada token de sellado temporal.
-
incluir un entero único para cada nuevo token de sellado temporal generado.
-
producir un token de sellado temporal tras la recepción de una petición válida de un solicitante, cuando sea posible.
-
incluir en cada token de sellado temporal un identificador que indique de forma única la política de seguridad bajo la que se ha generado el token.
-
sellar temporalmente sólo una representación hash3 de los datos, es decir, una huella de los datos asociada con una función hash unidireccional resistente a colisiones, identificada de forma única por un OID4.
-
examinar el OID de la función hash unidireccional resistente a colisiones y verificar que la longitud del valor hash sea consistente con el algoritmo hash.
-
no examinar la huella que se sella temporalmente de ninguna forma (más que la de
verificar su longitud, como se especifica en el punto anterior).
-
no incluir ninguna identificación de la entidad solicitante en los tokens de sellado temporal.
-
firmar cada token de sellado temporal utilizando una clave generada exclusivamente a tal efecto y que esta propiedad de la clave esté indicada en el correspondiente certificado.
-
incluir información adicional en el token de sellado temporal, si el solicitante lo pide utilizando el campo de extensiones, sólo para las extensiones que la AST soporta. Si esto no es posible, la AST debe responder con un mensaje de error.
2.2. Transacciones de la AST
Como primer mensaje de este mecanismo, la entidad solicitante pide un token de sellado temporal con el envío de una petición (que es o incluye un TimeStampReq, como se define posteriormente) a la AST. Como segundo mensaje, la AST responde enviando una respuesta (que es o incluye un TimeStampResp, como se define posteriormente) a la entidad solicitante.
Después de recibir la respuesta (que es o incluye un TimeStampResp, como se define posteriormente), la entidad solicitante debe verificar el campo de error devuelto en la respuesta y si no hay ningún error debe verificar los distintos campos contenidos en el TimeStampToken y la validez de la firma digital del TimeStampToken. En particular, debe verificar que lo que fue sellado temporalmente se corresponde con lo que se había solicitado a ser sellado temporalmente. El solicitante debe verificar que el TimeStampToken contiene el identificador de certificado correcto de la AST, la huella de los datos correcta y el OID del algoritmo de hash correcto. Después debe verificar la corrección respecto del tiempo de la respuesta, verificando o bien la fecha incluida en la respuesta comparada con una referencia de tiempo local fiable, si se dispone de alguna, o bien el valor del nonce (un número aleatorio grande con una elevada probabilidad de que fue generado por el cliente una sola vez) incluido en la respuesta comparándolo con el valor incluido en la petición. Para más detalles acerca de la detección de ataques de repetición, véase la sección de consideraciones de seguridad (punto 6). Si alguna de las verificaciones anteriores falla, debe rechazarse el TimeStampToken.
Después, dado que el certificado de la AST puede haber sido revocado, debería verificarse el status del certificado (por ejemplo verificando la CRL5 apropiada) para verificar que el certificado todavía es válido. A continuación, la aplicación del cliente debería verificar el campo “política” para determinar si la política bajo la que se emitió el token es aceptable o no para la aplicación.
2.3. Identificación de la AST
La AST debe firmar cada mensaje de sellado temporal con una clave reservada específicamente a tal efecto. Una AST puede disponer de distintas claves privadas, por ejemplo para dar cabida a distintas políticas, diferentes algoritmos, diferentes tamaños de clave o para mejorar su rendimiento. El correspondiente certificado sólo debe contener una instancia de la extensión con el campo que especifica el uso de la clave, como se define en [RFC2459] Sección 4.2.1.13 con el campo KeyPurposeID teniendo el valor id-kp-timeStamping. Esta extensión debe ser marcada como crítica.
2.4. Formatos de la petición y de la respuesta
2.4.1. Formato de la petición
Una petición, TimeStampReq, es una estructura que contiene los siguiente campos:
- version: es un valor entero (actualmente 1) que describe la versión de la petición de sellado temporal.
- messageImprint: este campo contiene a su vez dos subcampos.
- hashAlgorithm: es un OID del algoritmo de hash, que debería ser un algoritmo hash conocido (unidireccional y resistente a colisiones). Esto significa que debería ser undireccional y resistente a colisiones. La AST debería verificar si el algoritmo hash dado se considera o no suficiente (basado en el estado actual del conocimiento en el área del criptoanálisis y el estado actual en el arte de los recursos computacionales, por ejemplo). Si la AST no reconoce el algoritmo hash o sabe que el algoritmo hash es débil (una decisión que se deja a discreción de cada AST particular), entonces la AST debería rechazar proporcionar el token de sellado temporal, retornando un pkiStatusInfo de bad_alg.
- hashedMessage: debería contener el hash de los datos a...
Para continuar leyendo
Solicita tu prueba