Jorge Dávila y Luis F. PardoIntroducción
El Servicio Digital de Tiempo que se describe en esta ponencia se divide en dos partes bien diferenciadas: por una parte está compuesto por un Servidor de Tiempos bajo el protocolo NTP que actúa a nivel Stratum 1, y por otra de un generador de Sellos Digitales de Tiempo.
El servidor NTP Stratum 1 consiste en un emisor de paquetes IP con información horaria sobre el valor del tiempo universal actual UTC[2] a través del protocolo NTP[3]. El nivel de operación es Stratum 1 porque el servidor obtiene sus señales de tiempo a partir de un equipo hardware dedicado[4] que está sincronizado con la escala UTC con una precisión dentro del microsegundo.
El servicio para la emisión de Sellos Digitales de Tiempo es una funcionalidad completamente nueva, que se encuadra dentro del esquema general de las Autoridades de Certificación; es decir, se trata de una instalación que debido a su construcción y gestión públicamente refrendadas, puede ser depositaria de la confianza colectiva en cuanto a la veracidad, exactitud y relevancia de lo que afirma en sus certificados.
El servicio digital de tiempos emite certificados digitales denominados "Sellos Digitales de Tiempo", mediante los cuales se puede vincular fehacientemente un hecho con la escala universal de tiempos (UTC). El hecho fundamental que se vincula es la existencia de un objeto digital y su reconocimiento por parte de la Autoridad de Certificación en un determinado instante de tiempo.
El emisor de los Sellos Digitales de Tiempo sólo declara en sus certificados que tuvo conocimiento indirecto de la existencia de un objeto digital en un determinado instante UTC.
La necesidad de un Servicio Confiable de Tiempos
El tiempo es un argumento irreversible que afecta globalmente a todas las actividades humanas y es componente clave para todas las relaciones causales entre procesos. Las relaciones de dependencia entre unos hechos y otros son función del orden en el que se realizan cada uno de ellos y suelen ser manifestación de las relaciones causales que los unen.
Por este motivo, cualquier versión telemática de los procesos que hoy realizamos por otros medios, habrá de disponer de un mecanismo que permita poner de manifiesto esa misma dependencia temporal. Consideremos, por ejemplo, el caso de la celebración de un examen o prueba evaluatoria. En este tipo de escenarios, todos los participantes deben tener las mismas oportunidades, por lo que se les reúne simultáneamente en un mismo lugar, se les plantean las mismas preguntas y se les otorga el mismo tiempo para confeccionar sus respuestas. Al final del periodo marcado, las respuestas de cada uno de los participantes no podrán ser ya modificadas por nadie ya que eso iría en contra del principio de igualdad de oportunidades.
En este tipo de situaciones es necesaria la intervención de una Autoridad que pueda certificar que cada respuesta al examen planteado fue firmada por su autor y fue presentada dentro del plazo. Una vez emitido el documento que afirma tales hechos, ni el contenido de las respuestas, ni la autoría de las mismas, ni el momento en que se produjo la entrega deberán poder modificarse sin que con ello se invalide automáticamente el "sello" emitido por la Autoridad de Certificación.
Consideremos otro caso más, el de un Concurso Público de Ofertas. En este caso, varias compañías presentan sus opciones como respuesta a un mismo pliego de exigencias, y hacen sus cuentas para presentar una oferta que les pueda hacer ganar el concurso.
Actualmente, sus propuestas, convenientemente firmadas por sus representantes legales, se meten en sobres que se cierran y sellan para, posteriormente, ser entregados en depósito ante el organismo titular del concurso. Cuando han sido presentadas todas las opciones dentro de un mismo plazo de tiempo marcado por las normas del concurso, se reúnen en un acto público todas las partes involucradas para verificar el estado inalterado de los sellos, y luego abrir los sobres haciendo así su contenido público. Si alguien pudiese abrir los sobres antes de que se termine el plazo de presentación de ofertas, el transgresor podría conocer información privilegiada que le permitiría ganar fraudulentamente el concurso.
Si alguien pudiese sustituir o modificar una oferta previa incluyendo algo nuevo después de que haya terminado el plazo de presentaciones, también dispondría de información privilegiada que posiblemente se habría filtrado desde sus oponentes ya que éstos se encuentran más relajados al creer que nada puede hacerse ya para modificar las opciones presentadas.
En el primer caso, en el del examen, además del documento con las respuestas, todos los participantes deberían hacerse con un sello de tiempo que pueda, posteriormente, probar ante cualquiera, que ese documento existía en el momento de ser entregado, y que lo fue dentro del plazo estipulado para ello. A partir de ese instante, su contenido no podrá modificarse sin que con ello no se invalide el sello. Si surgiese cualquier disputa posterior, cualquiera podría verificar que el sello está intacto y que el documento que tiene delante es realmente el que se presentó a la salida del examen. Ni el examinador ni el examinado pueden ponerse de acuerdo para cambiar las respuestas ya que no son capaces de reconstruir un sello válido.
En este caso del concurso público, lo mejor sería no tener que entregar en modo alguno, las propuestas antes de que deban ser abiertas y hechas públicas. Para poder hacerlo así, tan sólo es necesario que exista un mecanismo confiable que pruebe la existencia de cada una de las propuestas con anterioridad al final del plazo de presentación, de modo que también nadie pueda modificarlas con posterioridad y antes de hacerlas públicas resolviendo automáticamente el concurso.
Este mecanismo insinuado en los párrafos anteriores es lo que denominamos un Sello de Tiempo, cuya única finalidad es probar que en un determinado instante de tiempo, todos los agentes involucrados declararon disponer o disponían de un determinado documento; en un caso las respuestas del examen, y en otro de una oferta secreta.
Cómo construir un Servicio Digital de Tiempos
Los elementos fundamentales que son necesarios para la construcción de un servicio que sea capaz de emitir Sellos Digitales de Tiempo son tres:
- Una fuente segura de tiempos que siga la escala UTC o equivalente. La fuente debe ser tal que no pueda ser alterada por nadie de modo inadvertido e indetectable, y cuya alteración suponga perjuicios a la colectividad superiores a los beneficios que pudieran obtenerse.
- Una identidad digital propia y adecuadamente protegida en cuanto a su unicidad, secreto e intransferibilidad.
- Una conexión a prueba de fallos a una red pública de ámbito global.
Como fuente de tiempos, nuestro sistema utiliza un reloj hardware de alta estabilidad y precisión que nos permite conocer el tiempo UTC con una precisión mejor que el microsegundo, y con una estabilidad de 32 s/año[5]. Este reloj lo mantenemos sincronizado cada segundo con las señales de referencia procedentes de varios satélites de la constelación Navstar que constituye el alma del sistema GPS, y que son visibles desde la ubicación geográfica del servidor[6].
El sistema de posicionamiento global GPS está basado en una constelación de veinticuatro satélites artificiales que orbitan alrededor del planeta en seis órbitas distintas. Cada uno de ellos dispone a bordo de dos relojes atómicos de cesio que en todo momento marcan el tiempo universal y emiten una señal horaria marcando el comienzo de cada segundo de tiempo universal.
La constelación Navstar está controlada por diez estaciones de seguimiento terrestres dispuestas alrededor del planeta. Cada una de ellas dispone de varios relojes atómicos sincronizados según UTC y son las que se encargan de maniobrar los satélites para que se mantengan en todo momento dentro de sus órbitas teóricas y para adelantar o atrasar los relojes atómicos que llevan abordo los satélites. Este proceso de sincronización mantiene la sincronía global del sistema en el rango de los 130 nanosegundos.
El funcionamiento del sistema GPS se basa en medir la distancia que separa a cualquier punto del espacio de cada uno de los satélites que se ven en cada momento por encima del horizonte. Según sea el tiempo que tarda la señal horaria en llegar al punto de observación se puede estimar la distancia que nos separa de cada uno de los satélites. Dado que todos ellos se mantienen en un órbita perfectamente conocida, los detectores GPS pueden calcular su posición respecto a ese geoide de referencia.
En nuestro caso, sólo estaríamos interesados en las señales de tiempo y con un solo satélite nos bastaría, sin embargo, utilizando todo el sistema GPS podemos combinar las señales de varios satélites (entre 4 y 6) para generar una única señal de sincronismo. Dado que la instalación del Servidor Digital de Tiempos es fija, cualesquiera desviaciones desaforadas en la posición de la estación según el sistema GPS pondría en alerta al sistema sobre la fiabilidad real de las señales de sincronización.
Utilizando los flancos de subida de las señales horarias provenientes de varios satélites unas vez corregidas según la posición de observación, podemos sincronizar el reloj hardware de alta estabilidad que constituye el alma del servicio, manteniéndolo en todo momento sincronizado con el tiempo universal en menos de un microsegundo.
El servicio digital de Tiempos es una Autoridad de Certificación que posee una identidad digital propia, que está compuesta por una serie de claves públicas RSA y DSA que representan los diferentes Sellos de Tiempo que puede emitir. Las claves privadas asociadas a las anteriores claves, se almacenan, convenientemente cifradas, en los discos fijos del equipo. La activación del servicio así como el descifrado de las claves privadas necesarias para poder emitir sellos, se hace bajo el control de un elemento criptográfico a prueba de intrusiones; en nuestro caso, bajo el control de una tarjeta inteligente única que hace las veces de módulo de seguridad.
La prestación del servicio se hace de modo público a través de la red Internet. En nuestro prototipo actual hay una interfaz Web que emite distintos tipos de sellos en http://tictac.fi.upm.es y lo hace a través de formularios html. Sin embargo, la utilización de este tipo de servicios en procesos completamente automáticos nos ha llevado a ubicar un servicio específico y siguiendo un protocolo propio en el puerto 1616.
A través de este puerto y servicio, cualesquiera otras aplicaciones podrán obtener sellos de tiempo así como la información pública necesaria para la interacción con este servicio (claves públicas de los sellos, certificados digitales de identidad, configuración de los sellos, etc.).
Funcionamiento del Servicio de Sellado Digital de Tiempos (SSDT)
Cada uno de los formularios que se reciben en el servidor http lanza la ejecución de un CGI encargado de poner en ejecución un proceso, denominado Formateador que se encarga de supervisar la correcta estructura de la solicitud. En el caso de que esto sea así, se lanza otro proceso, el Firmador, que será el encargado de emitir el sello. Para ello, el proceso Firmador requiere incluir los datos del futuro sello en la secuencia de la autoridad emisora por lo que envía un mensaje a un módulo, denominado Secuenciador, y queda a la espera de su respuesta.
Según sea el flujo de peticiones, podrán ser varios los pares de procesos Formatedor-Firmador que se encuentren a la espera de su posición en la secuencia. Por su parte, el proceso Secuenciador, que es único dentro del sistema, acepta los valores que le entregan los Firmadores de uno en uno y los incluye en la secuencia después de obtener la hora UTC del reloj hardware del sistema. El orden de solicitud de secuencia se respeta, por lo que los procesos Firmadores que antes hayan solicitado, antes obtendrán su respuesta.
Una vez que un proceso Firmador recibe su número de secuencia, ya tiene todos los elementos necesarios parea componer el Sello de Tiempo, por lo que calcula su valor hash y procede al cálculo de la firma digital que le da su validez. Una vez hecho esto, el proceso Firmador lo devuelve al solicitante a través de la conexión que lanzó la ejecución del CGI de partida.
Este proceso normal de funcionamiento puede quedar interrumpido o alterado por diversas circunstancias; una de ellas es la pérdida de la señal de sincronización con el sistema GPS. En este caso, el sistema cierra sus puertas al exterior y no acepta nuevas peticiones hasta que el hardware le vuelva a informar de su correcto estado de sincronía. Esta precaución no sería, en principio, necesaria ya que el reloj hardware utilizado es suficientemente estable como para mantener su sincronía con la escala UTC durante varios meses dentro de un margen de precisión más que aceptable.
Otro factor que puede bloquear la entrada de solicitudes de sellos es que haya demasiados procesos Firmadores en ejecución; tanto si están a la espera de lugar en la secuencia, como si están dedicados al cálculo de las firmas digitales de los sellos. Esta precaución está encaminada a proteger al sistema software de picos de demanda, fortuitos o intencionados, que pudieran poner en riesgo la continuidad del servicio.
Por último, mencionar una última precaución en cuanto a las solicitudes. Tanto el interfaz http como el servicio específico a la escucha en el puerto 1616, el tamaño de las solicitudes está limitado a 1 kByte y su formato es estricto. Con ello se pretende proteger al sistema de posibles solicitudes "gigantes" que podrían comprometer la integridad del sistema si éste intenta procesarlas. Cualquier fallo en el formato o cualquier extralimitación en su tamaño conduce al borrado de lo recibido y al cierre unilateral de la conexión solicitante.
Estructura de un Sello de Tiempo
Los elementos básicos de un sello de tiempo son:
- Datos sobre la Identidad de la Autoridad Emisora (Identidad Jurídica, Clave Pública a utilizar en la verificación del sello, Número de bit de la clave, y el algoritmo de firma digital + función hash utilizados.).
- Tipo de solicitud cursada (si es un Valor Hash o un Documento, cuál es su valor y Datos de referencia.)
- Parámetros del Secuenciador (valores hash Anterior, Actual y Siguiente)
- Fecha y Hora UTC.
- Firma Digital de todo lo anterior con la clave pública y esquema de firma digital especificados al principio.
Nuestro prototipo admite dos tipos distintos de solicitudes: aquellas en las que el solicitante envía un documento y solicita que aparezca íntegro en el cuerpo del sello, y otra, más anónima, en la que lo que envía es un presunto valor hash de algún objeto digital que el solicitante probablemente posee.
En ambos casos, la longitud máxima de la solicitud de sello no debe superar los 1024 bytes de longitud, por lo que la primera modalidad sólo sirve para textos relativamente cortos. Sin embargo, puede resultar útil para el usuario ya que deja a su criterio qué es lo que quiere matasellar temporalmente; por ejemplo, el texto a sellar podría ser:
"Sofía Mazagatos entrega sus respuestas firmadas al examen de la asignatura S.P.I., con valor MD5 = 29a2fa33dca39b6d9a2bc0748a335f33, como parte del examen de esa asignatura a los profesores encargados del examen"
A continuación podemos ver cual es la respuesta, en formato humanamente legible, que se obtiene del servidor TicTac para otro tipo de texto:
Certificado:
Datos Firma:
version: 0
Identidad del firmante:
Servicio Digital de Tiempo
Facultad de Informatica - UPM
Madrid - Spain
http:\\tictac.fi.upm.es
Identidad de la Clave: f208f543a56a7f1f6585d57dd90fb5a3
Numero Bits Clave: 1024
Algoritmo de Firma: md5WithRSAEncryption
Algoritmo Hash: md5
Datos Solicitud:
Tipo: Documento
Documento:
El servicio de Sellado Digital de Tiempos es una iniciativa del
Laboratorio de Criptologia de la Facultad de Informatica de la
Universidad Politecnica de Madrid
Referencia:
Presentacion Jornadas Tecnicas
de RedIris 1998
Datos Encadenamiento:
Hash Anterior: 00000000000000000000000000000000
Hash Actual: b04fa5d98dd622db74fdfc86aac6349d
Hash Siguiente: 29a2fa33dca39b6d9a2bc0748a335f33
Fecha: 1998/299 (1998/10/26)
Hora: 18:08:42,137329
Firma:
c2:25:07:05:51:cc:bf:9f:83:92:67:7c:2d:13:50:34:d5:bf
5a:52:f0:61:0c:e0:9f:93:4a:a1:76:06:1c:f2:1a:35:0e:e8
8c:0d:5a:d3:4e:8e:40:92:c9:d8:95:35:83:35:26:de:56:7b
94:1c:d6:e4:85:65:68:80:d7:5a:5a:6f:7f:b3:97:0e:7c:8a
bb:d5:ad:a9:67:66:7c:a8:5f:c8:01:9b:df:92:0e:01:4c:93
2d:04:94:0e:ea:dc:f9:e1:44:af:91:52:b4:6f:52:e4:df:63>
ce:cf:a9:f5:0c:75:16:72:97:9d:f2:f6:98:85:a8:88:4d:60
d4:22
Tal y como versa este sello, la afirmación a la que se refiere, fue recibida por el servidor TicTac el 26 de Octubre de 1998 a las 18 horas, 8 minutos y 42, 137329 segundos del Tiempo Universal.
El secuenciador y la Publicidad
Cualquier Autoridad de Certificación persigue satisfacer los niveles de seguridad necesarios para ganarse la confianza de los demás agentes de la red. Para ello, su construcción y funcionamiento se hacen tan públicos como sea necesario para evitar la sensación de "caja negra" a sus potenciales clientes. En lo que a su funcionamiento se refiere, toda Autoridad de Certificación declara públicamente cual va a ser su proceder en aquellos casos en los que dará servicio y renuncia explícitamente a cualquier otro tipo de funcionamiento. Estos compromisos son los que constituyen la denominada "Política de Certificación" de la autoridad.
Además de todo esto, las Autoridades de Certificación asumen un riesgo considerable al convertirse automáticamente en objetivo natural de numerosos enemigos que van desde los que quieren robarle su identidad para poder emitir sellos falsos, a los que quieren forzar al servicio a funcionamientos que se salgan de lo públicamente declarado, hasta los que ponen en duda su credibilidad argumentando oscuras y complejas confabulaciones de la Autoridad de Certificación con otros agentes partidistas.
En nuestro caso, el Servicio Digital de Tiempos se defiende de estos peligros recurriendo a la irreversibilidad del secuenciador y a la publicidad de sus resultados. El módulo secuenciador es el encargado de ampliar en un elemento más una secuencia pública construida a través del cálculo iterado de una función hash, de sentido único, como es, en nuestro caso, el MD5. Cada día, la secuencia se inicializa con el valor nulo en sus registros de encadenamiento. Cuando llega una solicitud de secuencia, utiliza el valor de la solicitud como mensaje para calcular un nuevo estado de los registros de encadenamiento a partir del estado anterior. De este modo, la llegada de una solicitud modifica el estado de la secuencia de modo irreversible.
La irreversibilidad de este proceso nace de la resistencia criptográfica de la función hash utilizada ya que es fácil calcular la función en una dirección pero computacionalmente imposible en la otra. Sin embargo, esta cualidad no impide que el propio secuenciador pudiese mantener varias secuencias simultáneas y diferentes con fines nada confesables. Este proceder o sospecha de proceder, sería una de las primeras críticas que lanzarían los detractores maledicientes del servicio.
Para zanjar estas críticas, cualquier cambio en el estado del secuenciador se publica inmediatamente en el fichero histórico de la secuencia en curso, por lo que podría ser observado por cierto número de testigos imparciales que podrían hablar en su defensa. Para convertir las secuencias en documentos imputables a la Autoridad de Certificación que constituye el Servicio Digital de Tiempos, ésta firma y difunde, al final de cada día, el fichero histórico en el que se indican cuales han sido los elementos de la secuencia producida ese día y en que instantes de tiempo se produjeron los cambios de estado.
Este fichero contiene varios de los datos que componen los Sellos de Tiempo (hashes anterior y posterior, fecha y hora UTC) pero no permiten traslucir ninguna información relativa al valor (hash actual) que provocó ese elemento de la secuencia y, por lo tanto, no permitiría reconstruir parcialmente el sello de tiempo que lleva asociado cada uno de los cambios de estado que forman la secuencia.
Además de poder demostrar la autenticidad de un sello verificando su firma digital, con estos ficheros históricos también podemos comprobar que su emisión está reflejada en el registro del día en que se emitió y que se encuentra distribuido en numerosos puntos de la red pública.
La aparición de un sello dentro de la secuencia publicada y firmada por la Autoridad de Certificación emisora, es una garantía de que, ni siquiera ella podría generar sellos falsos con posterioridad a la publicación de la secuencia diaria.
Para poder hacer esto, tanto la agencia emisora como para cualquier otro agente, se enfrentan a un proceso que es computacionalmente imposible, pues requeriría la inversión de una función hash y la retirada de todas las copias de la secuencia genuina que hay distribuidas por la red. Lo más que podría hacer una autoridad corrupta sería emitir a sabiendas un sello falso, pero nunca podría incluirlo en una secuencia pública ya firmada y distribuida.
Por este motivo, el Servicio Digital de Sellos de Tiempo no guarda, como tal, copia de sus secuencias, sino que deja a otros elementos de la red que mantengan públicamente copias de ellas. La Autoridad de Certificación que constituye el Servicio Digital de Sellos de Tiempo se libera de los registros históricos diarios del secuenciador tan pronto como termina el día al que se refiere y las ha firmado con una identidad (clave privada) específica para tal fin.
Notas
- Los resultados de este proyecto son parte de los desarrollos realizados dentro del proyecto TEL97-1145, Titulado: "Proyecto Piloto de una Red de Terceras Partes Confiables" incluido dentro del programa de Aplicaciones y Servicios Telemáticos.
- Universal Time Coordinates
- Network Time Protocol a veces denominado Stratum 0 por servir de elemento de referencia a los equipos que actúan en el nivel Stratum 1.
- Precisión del Oscillator: 5 x 10-8 s, Estabilidad: 1 ppm, de 0°C a +50°C. Precisión temporal: 1 microsegundo respecto a UTC. Entrada del receptor GPS: 1,575 MHz (L1). Capacidad de seguimiento de satélites: 6 canales.
- La configuración de la constelación Navstar asegura que en todo momento son visibles al menos cuatro satélites desde cualquier lugar del mundo que tenga una visión total del horizonte
Jorge Dávila Muro y Luis F. Pardo Fincias
Facultad de Informática-UPM
Laboratorio de Criptología
jdavila [at] fi [dot] upm.es lfern [at] dilmun [dot] ls.fi.upm.es