ES2572810T3 - Descubrimiento y validación de rutas delegadas y distribuidas - Google Patents

Descubrimiento y validación de rutas delegadas y distribuidas Download PDF

Info

Publication number
ES2572810T3
ES2572810T3 ES04811786.5T ES04811786T ES2572810T3 ES 2572810 T3 ES2572810 T3 ES 2572810T3 ES 04811786 T ES04811786 T ES 04811786T ES 2572810 T3 ES2572810 T3 ES 2572810T3
Authority
ES
Spain
Prior art keywords
certificates
trusted
certificate
route
routes
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES04811786.5T
Other languages
English (en)
Inventor
David Engberg
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Assa Abloy AB
Original Assignee
Assa Abloy AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Assa Abloy AB filed Critical Assa Abloy AB
Application granted granted Critical
Publication of ES2572810T3 publication Critical patent/ES2572810T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3265—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Storage Device Security (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Método para proporcionar información de validación de rutas para un sistema, que comprende: determinar (108, 124) unas rutas de confianza entre un subconjunto de certificados del sistema y por lo menos una raíz de confianza, incluyendo dichas rutas de confianza una cadena de autorizaciones desde un certificado de destino a dicho por lo menos un certificado raíz de confianza; almacenar (132) cada una de las rutas de confianza en una tabla antes de una solicitud de información de validación de rutas; recibir (182) unas pruebas del estado de revocación para dicho subconjunto de certificados; caracterizado por que comprende las etapas siguientes: pregenerar dichas pruebas; firmar digitalmente dichas pruebas; almacenar dichas pruebas antes de una solicitud de información de validación de rutas, siendo las pruebas apropiadas para proporcionar validación; y extraer las rutas de confianza almacenadas en la tabla y las pruebas pregeneradas almacenadas como respuesta a una solicitud de información de validación de rutas sin recuperar la información de estado de revocación en tiempo real.

Description

5
10
15
20
25
30
35
40
45
50
55
60
65
DESCRIPCION
Descubrimiento y validacion de rutas delegadas y distribuidas.
Referencia cruzada a solicitudes relacionadas
La presente solicitud reivindica la prioridad con respecto a la solicitud provisional US 60/523.398 presentada el 19 de noviembre de 2003.
Antecedentes de la invencion
1. Campo tecnico
Esta solicitud se refiere al campo de la seguridad y la validacion de datos, y mas particularmente a un metodo para proporcionar informacion de validacion de rutas para un sistema de acuerdo con el preambulo de la reivindicacion 1.
2. Descripcion de las anterioridades
Resulta util poder determinar el estado de un certificado digital, incluyendo la determinacion de si el certificado se emitio de manera valida y/o si el certificado ha sido revocado antes de su expiracion. Existen varias tecnicas para determinar el estado de un certificado digital individual. Por ejemplo, las patentes US n° 5.666.416 y 5.717.758 describen tecnicas para proporcionar el estado de un certificado individual. Se conocen tambien otras tecnicas para diseminar y verificar el estado de un certificado, incluyendo Listas de Revocacion de Certificados (CRL's), las cuales son listas firmadas digitalmente de certificados revocados.
En la verificacion de un certificado digital puede que se requiera tener que confiar en el emisor del certificado digital y/o confiar en el firmante de la informacion de revocacion, que puede ser o no la misma entidad. En el caso de un certificado digital, “confiar en” un emisor y/o un firmante de informacion de revocacion puede referirse al hecho de que el emisor y/o el firmante sea una autoridad conocida que tenga una clave publica valida correspondiente a una clave secreta que fue utilizada para firmar el certificado y/o la informacion de revocacion. Por ejemplo, un usuario puede recibir un certificado digital que este firmado digitalmente por una autoridad, A, y puede recibir tambien una CRL actualizada (que no contiene el certificado digital) firmada por una autoridad diferente, A'. No obstante, el usuario desearfa poder confiar tanto en A como en A' junto con sus claves publicas (correspondientes a las claves secretas utilizadas para firmar el certificado y la CRL) con el fin de poder respetar el certificado.
Existen mecanismos para facilitar la diseminacion y la confianza de autoridades por otro lado desconocidas que emiten certificados e informacion de revocacion. En algunas ocasiones, es posible hacer que una autoridad de confianza firme digitalmente informacion (o, de otra manera, que valide la informacion) para verificar una autoridad que de otro modo serfa desconocida. Despues de esto, la autoridad previamente desconocida puede presentar informacion firmada digitalmente (por ejemplo, un certificado digital y/o informacion de revocacion) que se puede verificar utilizando la clave publica de la autoridad previamente desconocida. Por ejemplo, si un usuario no conoce o conffa en la firma digital de las autoridades A1 y A2, pero el usuario si conoce y conffa en la autoridad A3, entonces el usuario puede obtener (o se le puede presentar) informacion firmada digitalmente por A3 (y por lo tanto avalada por A3) que indica que A1 y A2 son autoridades fiables. Asf, si a dicho usuario se le presentasen un certificado digital firmado por A1 y una CRL (que no incluye el certificado digital) firmada por A2, el usuario utilizarfa la informacion avalada por A3 para verificar la validez del certificado presentado.
Existen tambien mecanismos de anidamiento que se pueden utilizar en casos en los que autoridades avalan a otras autoridades. Por ejemplo, la patente US n. ° 5.717.759 da a conocer una tecnica en la que una primera autoridad, A1, avala una segunda autoridad, A2, la cual avala una tercera autoridad, A3, etcetera, hasta que el anidamiento llega a una autoridad en la que conffa un hipotetico usuario. En algunos casos, la accion de avalar puede incluir proporcionar una forma digital de la autoridad avaladora.
La patente US n° 6.134.550 da a conocer un metodo que construye una cadena de certificacion preferida, tal como una lista de todas las autoridades de certificados en una ruta de confianza mas corta, sobre la base de datos de cadenas de certificacion generados, tales como una tabla de relaciones de confianza entre unidades emisoras de certificados en una comunidad de interes, con el fin de facilitar una rapida determinacion de la validez del certificado por parte de una unidad solicitante. La unidad solicitante lleva a cabo una determinacion de la validez sobre el certificado a validar, basandose en los datos de cadenas de certificados utilizando una o mas bases de datos de directorios comunes o una version de las mismas almacenada en memoria cache.
El documento “Delegated Path Validation and Delegated Path Discovery Protocol Requirements” de PINKAS, D. et al, ISSN: 0000-0003, especifica los requisitos para la Validacion Delegada de Rutas (DPV) y el Descubrimiento Delegado de Rutas (DPD) para Certificados de Claves Publicas. Da a conocer la descarga de validacion de rutas a un servidor y una validacion de certificados en tiempo real.
5
10
15
20
25
30
35
40
45
50
55
60
65
La solicitud de patente US 2002/0046340 A1 da a conocer un centro de autenticacion de validez de certificados VC que, de manera periodica, busca y verifica rutas que se extienden desde una autoridad de certificacion puente a autoridades de certificacion para admision de terminales individuales, y que registra las rutas cuyas verificaciones siguen vigentes, en una base de datos de rutas en asociacion con las respectivas autoridades de certificacion para admision de terminales.
Aunque el anidamiento y otros mecanismos son utiles, en algunos casos puede que a un usuario se le presenten un certificado digital y/o informacion de revocacion y/o alguna otra informacion para los cuales no exista ningun mecanismo directo para determinar si se puede confiar en el firmante del certificado/informacion de revocacion/otra informacion, y por lo tanto es posible que el usuario no pueda determinar si el certificado digital es valido en ese momento. Por consiguiente, resultana util afrontar esta cuestion.
Sumario de la invencion
Dicho mecanismo directo para determinar si se puede confiar en el firmante del certificado/informacion de revocacion/otra informacion se obtiene por el conjunto de las caracterfsticas de la reivindicacion 1.
Segun la presente invencion, la provision de informacion de validacion de rutas para un sistema incluye determinar rutas entre un subconjunto de certificados del sistema y por lo menos un certificado rafz de confianza, almacenar cada una de las rutas en una tabla antes de una solicitud de informacion de validacion de rutas, y extraer la informacion de validacion almacenada en la tabla como respuesta a una solicitud de informacion de validacion de rutas. La provision de informacion de validacion de rutas tambien puede incluir firmar digitalmente la informacion de validacion. La provision de informacion de validacion de rutas tambien puede incluir aplicar restricciones a la informacion de validacion y unicamente proporcionar informacion de validacion que sea acorde con las restricciones. La determinacion de rutas puede incluir construir un grafico dirigido de rafces de confianza y del subconjunto de certificados, y llevar a cabo una busqueda acfclica en profundidad del grafo. La tabla se puede indexar utilizando las rafces de confianza o utilizando los certificados. La provision de informacion de validacion de rutas tambien puede incluir recibir pruebas del estado de revocacion para el subconjunto de certificados, almacenar las pruebas antes de una solicitud de informacion de validacion de rutas, y extraer las pruebas junto con la informacion de validacion como respuesta a una solicitud de informacion de validacion de rutas. La provision de informacion de validacion de rutas tambien puede incluir firmar digitalmente la informacion de validacion y las pruebas. La provision de validacion de rutas tambien puede incluir aplicar restricciones a la informacion de validacion y unicamente proporcionar informacion de validacion que este acorde con las restricciones. La determinacion de rutas puede incluir construir un grafo dirigido de rafces de confianza y del subconjunto de certificados, y llevar a cabo una busqueda acfclica en profundidad del grafo. Las pruebas se pueden almacenar en la tabla que contiene la informacion de validacion. La tabla se puede indexar utilizando las rafces de confianza. La tabla se puede indexar utilizando los certificados. Las pruebas se pueden almacenar en otra tabla que esta separada de la tabla que contiene la informacion de validacion. La otra tabla se puede indexar utilizando las rafces de confianza o utilizando los certificados. El subconjunto de certificados puede incluir rafces de confianza, autoridades que emiten certificados de usuario final, y autoridades que avalan otras autoridades. El subconjunto de certificados tambien puede incluir certificados de usuario final.
Todavfa de acuerdo con la presente invencion, un producto de programa de ordenador que proporcione informacion de validacion de rutas para un sistema incluye un soporte de almacenamiento que contiene codigo ejecutable para el producto de programa de ordenador, codigo ejecutable que determina rutas entre un subconjunto de certificados del sistema y por lo menos un certificado rafz de confianza, codigo ejecutable que almacena cada una de las rutas en una tabla antes de una solicitud de informacion de validacion de rutas, y codigo ejecutable que extrae la informacion de validacion almacenada en la tabla como respuesta a una solicitud de informacion de validacion de rutas. El producto de programa de ordenador tambien puede incluir codigo ejecutable que firma digitalmente la informacion de validacion. El producto de programa de ordenador tambien puede incluir codigo ejecutable que aplica restricciones a la informacion de validacion y que unicamente proporciona informacion de validacion que es acorde con las restricciones. El codigo ejecutable que determina rutas puede construir un grafo dirigido de certificados rafz de confianza y del subconjunto de certificados, y puede llevar a cabo una busqueda acfclica en profundidad del grafo. La tabla se puede indexar utilizando las rafces de confianza. La tabla se puede indexar utilizando los certificados. El producto de programa de ordenador tambien puede incluir codigo ejecutable que recibe pruebas del estado de revocacion para el subconjunto de certificados, codigo ejecutable que almacena las pruebas antes de una solicitud de informacion de validacion de rutas, y codigo ejecutable que extrae las pruebas junto con la informacion de validacion como respuesta a una solicitud de informacion de validacion de rutas. El producto de programa de ordenador tambien puede incluir codigo ejecutable que firma digitalmente la informacion de validacion y las pruebas. El producto de programa de ordenador tambien puede incluir codigo ejecutable que aplica restricciones a la informacion de validacion, y unicamente proporciona informacion de validacion que es acorde con las restricciones. El codigo ejecutable que determina rutas puede construir un grafo dirigido de rafces de confianza y del subconjunto de certificados, y puede llevar a cabo una busqueda acfclica en profundidad del grafo. Las pruebas se pueden almacenar en la tabla que contiene la informacion de validacion. La tabla se puede indexar usando las rafces de confianza o utilizando los certificados. Las pruebas se pueden almacenar en otra tabla que esta separada de la tabla que contiene la informacion de validacion. La otra tabla se puede indexar utilizando las rafces de confianza o usando los certificados. El subconjunto de certificados puede incluir rafces de confianza, autoridades que emiten certificados
5
10
15
20
25
30
35
40
45
50
55
60
de usuario final, y autoridades que avalan a otras autoridades. El subconjunto de certificados tambien puede incluir certificados de usuario final.
Segun todavfa la presente invencion, un servidor incluye un procesador, medios de almacenamiento internos acoplados al procesador, codigo ejecutable, proporcionado en los medios de almacenamiento internos, que determina rutas entre un subconjunto de certificados y por lo menos un certificado rafz de confianza, codigo ejecutable, proporcionado en los medios internos de almacenamiento, que almacena cada una de las rutas en una tabla antes de una solicitud de informacion de validacion de rutas, y codigo ejecutable, proporcionado en los medios de almacenamiento internos, que extrae la informacion de validacion almacenada en la tabla como respuesta a una solicitud de informacion de validacion de rutas. El servidor puede incluir codigo ejecutable, proporcionado en los medios de almacenamiento internos, que firma digitalmente la informacion de validacion. El servidor puede incluir codigo ejecutable, proporcionado en los medios de almacenamiento internos, que aplica restricciones a la informacion de validacion, y que unicamente proporciona informacion de validacion que es acorde con las restricciones. El codigo ejecutable que determina rutas puede construir un grafo dirigido de rafces de confianza y del subconjunto de certificados, y lleva a cabo una busqueda acfclica en profundidad del grafo. La tabla se puede indexar utilizando las rafces de confianza o utilizando los certificados. El servidor puede incluir codigo ejecutable, proporcionado en los medios de almacenamiento internos, que recibe pruebas del estado de revocacion para el subconjunto de certificados, codigo ejecutable, proporcionado en los medios internos de almacenamiento, que almacena las pruebas antes de una solicitud de informacion de validacion de rutas, y codigo ejecutable, proporcionado en los medios de almacenamiento internos, que extrae las pruebas junto con la informacion de validacion como respuesta a una solicitud de informacion de validacion de rutas. El servidor puede incluir codigo ejecutable, proporcionado en los medios de almacenamiento internos, que firma digitalmente la informacion de validacion y las pruebas. El servidor puede incluir codigo ejecutable, proporcionado en los medios de almacenamiento internos, que aplica restricciones a la informacion de validacion y unicamente proporciona informacion de validacion que es acorde a las restricciones. El codigo ejecutable que determina rutas puede construir un grafo dirigido de rafces de confianza y del subconjunto de certificados, y puede llevar a cabo una busqueda acfclica en profundidad del grafo. Las pruebas se pueden almacenar en la tabla que contiene la informacion de validacion. La tabla se puede indexar usando las rafces de confianza o utilizando los certificados. Las pruebas se pueden almacenar en otra tabla que este separada de la tabla que contiene la informacion de validacion. La otra tabla se puede indexar utilizando las rafces de confianza o usando los certificados. El subconjunto de certificados puede incluir rafces de confianza, autoridades que emiten certificados de usuario final, y autoridades que avalan a otras autoridades. El subconjunto de certificados tambien puede incluir certificados de usuario final.
Breve descripcion de los dibujos
La Figura 1 ilustra un servidor no fiable de descubrimiento/validacion delegados de rutas segun una forma de realizacion del sistema que se describe en la presente.
La Figura 2 ilustra un servidor de confianza para descubrimiento/validacion delegados de rutas segun una forma de realizacion del sistema que se describe en la presente.
La Figura 3 ilustra dos areas interconectadas, que contienen, cada una de ellas, informacion local de certificados segun una forma de realizacion del sistema que se describe en la presente.
La Figura 4 ilustra el uso de una red para comunicar informacion de certificados a un usuario de acuerdo con una forma de realizacion del sistema que se describe en la presente.
La Figura 5 es un diagrama de flujo que ilustra el pre-calculo de rutas de confianza segun una forma de realizacion del sistema que se describe en la presente.
La Figura 6 es un diagrama de flujo que ilustra iteraciones a traves de rutas de confianza en relacion con el llenado de una tabla de certificados y rutas de confianza de acuerdo con el sistema que se describe en la presente.
Las Figuras 7A, 7B y 7C ilustran tablas que contienen rutas de confianza y/o pruebas de acuerdo con una forma de realizacion del sistema que se describe en la presente.
La Figura 8 es un diagrama de flujo que ilustra la devolucion de rutas de confianza y/o pruebas pre-calculadas, segun una forma de realizacion del sistema que se describe en la presente.
La Figura 9 es un diagrama de flujo que ilustra un procesado llevado a cabo por un servidor de confianza de descubrimiento/validacion delegados de rutas segun una forma de realizacion del sistema que se describe en la presente.
5
10
15
20
25
30
35
40
45
50
55
60
65
Descripcion detallada de varias formas de realizacion
Se conocen tecnicas para proporcionar informacion del estado de certificados individuales asf como tecnicas para verificar certificados y/o autoridades que firman digitalmente certificados. Vease, por ejemplo, la exposicion que se proporciona en las patentes US n° 5.420.927; 5.604.804; 5.610.982; 6.097.811; 6.301.659; 5.793.868; 5.717.758; 5.717.575; 6.487.658; y 5.717.759. El sistema que se describe en la presente puede utilizar tecnicas que se dan a conocer en una o mas de estas patentes, posiblemente en combinacion con otra u otras tecnicas apropiadas. Las tecnicas que se pueden utilizar incluyen, de manera individual o en cualquier combinacion, CRL's completas, CRL's con particiones, CRL's delta, respuestas de OCSP (individualmente y por grupos), mini CRL's (CRL's comprimidas a nivel de bits), VTokens (cadena hash unidireccional), y diversas versiones de arboles de Merkle o de otros arboles.
Descubrimiento de rutas se refiere al proceso de encontrar una ruta de confianza (relacion de confianza) entre un certificado arbitrario y una de entre las rafces de confianza de un usuario, los cuales son certificados digitales que se corresponden con autoridades en las que conffa un usuario. Una ruta de confianza es una cadena de autorizaciones desde un certificado a otro con un certificado de destino en un extremo y un certificado rafz de confianza en el otro. Por ejemplo, si el certificado C1 se corresponde con una autoridad de confianza A1, y A1 firma C2 para la autoridad desconocida A2 y la autoridad A2 firma el certificado C3 para la autoridad desconocida A3 que firmo el certificado de destino, entonces una ruta de confianza desde C1 (el certificado rafz de confianza) al certificado de destino es C1 a C2, C2 a C3, y C3 al certificado de destino.
En algunos casos, el descubrimiento de rutas se puede llevar a cabo localmente de una manera bastante directa por parte del usuario siempre que todos los certificados de una ruta de confianza esten disponibles localmente. No obstante, en algunos casos, incluyendo aquellos con un modelo de confianza federado que se basa en la certificacion cruzada, puede que los usuarios no dispongan de toda la informacion necesaria para llevar a cabo un descubrimiento de rutas local.
Observese tambien que, incluso cuando se ha encontrado una ruta de confianza completa entre un certificado rafz de confianza y un certificado de destino, puede seguir existiendo la inquietud de que se puedan haber revocado uno o mas de los certificados sobre la ruta de confianza desde la emision de los mismos. Validacion de rutas se refiere a la confirmacion del estado actual de todos los certificados en una ruta de confianza, incluyendo su validez (estado de revocacion) de los certificados y teniendo en cuenta cada una de las reglas y/o restricciones correspondientes al uso de los certificados (por ejemplo, comprobacion de polfticas de seguridad). El ensamblaje de la informacion de estados de revocacion para cada certificado en la ruta de confianza puede resultar relativamente diffcil para algunos usuarios en algunas situaciones (por ejemplo, aquellas correspondientes a valores de configuracion de cortafuegos especiales que eviten el acceso a redes publicas). Por consiguiente, es util poder proporcionar un servicio que pueda verificar un certificado en una unica transaccion. Esto se puede realizar en primer lugar determinando la ruta de confianza, recibiendo informacion de revocacion (y/o informacion de restricciones) sobre los certificados en la ruta de confianza, y procesando la informacion recibida para verificar el certificado de destino.
En referencia a la Figura 1, un servidor no fiable de descubrimiento/validacion delegados de rutas (UDPDV) 30 recibe, como entrada, informacion que identifica uno o mas rafces de confianza (certificados correspondientes a autoridades de confianza) y un identificador correspondiente a un certificado de destino (o quizas alguna otra informacion/datos) que desea validar un usuario. Opcionalmente, el servidor de UDPDV 30 se puede preconfigurar con rafces de confianza ademas de recibir como entrada rafces de confianza, o de manera alternativa a esto ultimo.
Evidentemente, si el usuario ya conffa en una autoridad que emitio el certificado de destino y el usuario tiene acceso a informacion de revocacion fiable para el certificado de destino (y posiblemente el certificado de la autoridad de confianza), entonces el usuario puede verificar el certificado de destino con esa informacion, y puede que no sea necesario utilizar el servidor de UDPDV 30. Por consiguiente, el servidor de UDPDV 30 es util en casos en los que un usuario desea verificar el estado de un certificado de destino para el cual el usuario no conffa en (no conoce) la autoridad que emitio el certificado de destino y/o para el cual el usuario no posee informacion de revocacion fiable sobre el certificado de destino (y posiblemente el certificado de la autoridad que emitio el certificado de destino).
El servidor de UDPDV 30 procesa las entradas que van hacia el mismo, para determinar una o mas rutas de confianza entre el certificado de destino y un certificado rafz de confianza (o bien introducido o bien preconfigurado en el servidor de UDPDV 30, segun se ha descrito anteriormente). Observese que, en muchos casos, tambien puede resultar util confirmar que no se ha revocado ninguno de los certificados en una ruta de confianza (lo cual indica, por ejemplo, compromiso de la clave secreta de una autoridad). En tal caso, puede resultar util hacer que el servidor de UDPDV 30 tambien proporcione pruebas en forma de informacion de revocacion autenticada (por ejemplo, CRL's o respuestas de OCSP). Por consiguiente, en algunas formas de realizacion, el servidor de UDPDV 30 tambien puede proporcionar pruebas para certificados en una ruta de confianza.
Asf, en la forma de realizacion que se da a conocer en la Figura 1, el servidor de UDPDV 30 ensambla la informacion de rutas de confianza para el certificado de destino y, opcionalmente, tambien ensambla informacion de revocacion para elementos de la ruta. La salida del servidor de UDPDV 30 hacia el usuario no se puede autenticar (por ejemplo, firmar) independientemente. Por el contrario, el servidor de UDPDV 30 devuelve todos los elementos
5
10
15
20
25
30
35
40
45
50
55
60
65
individuales de la ruta de confianza (y, opcionalmente, pruebas) al usuario, el cual a continuacion puede verificar independientemente la correccion de la ruta de confianza y la validez de sus elementos (certificados). El funcionamiento del servidor de UDPDV 30 se describe de forma mas detallada en otras secciones del presente documento.
En referencia a la Figura 2, un servidor de confianza para descubrimiento/validacion delegados de rutas 40 recibe, como entrada, rafces de confianza de un usuario y un identificador correspondiente a un certificado de destino (o quizas alguna otra informacion/datos) que desea verificar un usuario. Opcionalmente, el servidor de confianza para descubrimiento/validacion delegados de rutas 40 se puede pre-configurar con rafces de confianza ademas de recibir las rafces de confianza como entrada, o de manera alternativa a esto ultimo.
El servidor de confianza para descubrimiento/validacion delegados de rutas 40 da salida a un resultado que indica si el certificado de destino (u otra informacion/datos) es o no valido. En una forma de realizacion que se describe en la presente, el servidor 40 lleva a cabo su propia autenticacion criptografica de la informacion que se proporciona al usuario. En esta forma de realizacion, el servidor 40 puede firmar respuestas proporcionadas de este modo, lo cual permitirfa que el servidor 40 proporcionase un pequeno volumen de datos al usuario (por ejemplo, “Sf, puede confiar en el certificado X”). No obstante, una implementacion de este tipo preve que el usuario conffe explfcitamente en la integridad y la correccion de las operaciones internas del servidor de confianza para descubrimiento/validacion delegados de rutas 40. Si el servidor 40 se ve comprometido, el servidor 40 se podrfa utilizar de manera inadecuada para autenticar respuestas que validan cualquier certificado, con independencia del origen o el estado actual.
Los servidores 30, 40 se pueden proporcionar mediante estaciones de trabajo informaticas que tengan procesadores y medios internos de almacenamiento para almacenar codigo ejecutable y datos, uno o mas modulos de software proporcionados en un ordenador de proposito general, hardware dedicado, o cualquier combinacion de hardware y software con capacidad de proporcionar la funcionalidad que se describe en la presente. Para el sistema descrito en este documento, el servidor de UDPDV 30 se puede proporcionar por medio de uno o mas servidores ligeros que no necesitan tener capacidades de autenticacion (por ejemplo, claves privadas para firmas digitales).
El servidor de UDPDV 30 se puede configurar periodicamente con listas de informacion de dos tipos. El primer tipo de lista contiene un conjunto de certificados que se pueden usar en la validacion de rutas y, en una forma de realizacion de la presente, representa todos o practicamente todos los certificados accesibles (por ejemplo, por medio de una red) para el servidor de UDPDV 30. En otra forma de realizacion, el primer tipo de lista contiene certificados unicamente para autoridades que emiten certificados e informacion de revocacion, y para autoridades que abalan a dichas autoridades, sin contener necesariamente la totalidad o ni siquiera ninguno de los certificados de usuario final. El primer tipo de listas puede contener certificados rafz autofirmados (certificados rafz de confianza) que actuan como anclas de confianza. Los certificados rafz de confianza pueden ser firmados por autoridades en las que conffa(n) el(los) usuario(s) del sistema. El primer tipo de listas tambien puede contener certificados del emisor (tambien conocido como “autoridad de certificacion”) para autoridades que emiten certificados, autoridades que emiten informacion de revocacion, y/o autoridades que avalan a otras autoridades. En una forma de realizacion, el primer tipo de listas tambien puede contener certificados de usuario final mientras que en otra forma de realizacion, el primer tipo de listas no contiene certificados de usuario final. El primer tipo de listas de certificados se puede usar para proporcionar servicios de descubrimiento de rutas, segun se describe en la presente.
El segundo tipo de lista proporcionado en el servidor de UDPDV 30 puede incluir pruebas pregeneradas del estado del certificado. Cada prueba puede contener el estado de uno o mas certificados (de la primera lista) para un intervalo de tiempo fijado, y la prueba se puede autenticar de manera segura, por ejemplo utilizando una firma digital. Las pruebas se pueden usar para proporcionar servicios de validacion de rutas, segun se describen en alguna otra seccion en el presente documento. Las pruebas pueden ser proporcionadas por cualesquiera medios apropiados, incluyendo CRL's, respuestas de OCSP, VTokens, etcetera.
La comprobacion de una ruta entre un certificado rafz de confianza y un certificado de destino es conocida en la tecnica y esta bien documentada en las normativas sobre certificados (por ejemplo, RFC 3280). No obstante, el tiempo que se tarda en encontrar una ruta de confianza sobre un numero elevado de certificados puede aumentar de manera exponencial segun el numero de certificados del grupo. Esto puede resultar aceptable en algunas situaciones y/o para pequenas colecciones de certificados, aunque puede ser inaceptable en otras situaciones, tales como una gran comunidad de autoridades federadas.
El sistema descrito en la presente esta disenado para llevar a cabo el descubrimiento de rutas en tiempo logarftmico o constante en el momento de una solicitud de descubrimiento, en primer lugar pre-calculando rutas de confianza entre cada certificado rafz de confianza y la totalidad del resto de certificados accesibles, para autoridades que emiten certificados y/o avalan a otras autoridades. Cuando el servidor de UDPDV 30 recibe una lista nueva de certificados (o se acopla a una fuente de certificados nuevos), el servidor puede pre-calcular una matriz de M por N donde M es el numero de rafces de confianza y N es el numero total de certificados. Cada celda de la matriz (por ejemplo, en la fila r1 y columna c1) puede contener una o mas rutas legftimas desde el certificado rafz de confianza especffico indicado por la fila r1 al certificado especffico indicado por la columna c1, o si no, puede contener un
5
10
15
20
25
30
35
40
45
50
55
60
65
conjunto vacfo para indicar que no es posible ninguna ruta. Opcionalmente, cada celda (o cada celda de una tabla analoga) tambien puede contener pruebas apropiadas para proporcionar la validacion.
Cuando llega una solicitud de usuario para verificar un certificado de destino, el servidor de UDPDV 30 utiliza la matriz pre-calculada para buscar el(los) certificado(s) de confianza para el usuario y para buscar la autoridad que emitio el certificado de destino y, opcionalmente, una autoridad que emitio informacion de revocacion para el certificado de destino (en caso de que sea diferente de la autoridad emisora) para hallar una o mas rutas validas entre ellas. Esto se puede llevar a cabo en una busqueda en tiempo constante puesto que las rutas se han pre- calculado y almacenado en el servidor de UDPDV 30. Observese que si hay mas de una ruta de confianza posible o si hay restricciones asociadas a una ruta de confianza (por ejemplo, restricciones de nombres o polfticas) que limitan en cualquier modo el uso de cualquiera de los certificados en la ruta de confianza, entonces es necesario aplicar las polfticas de rutas con respecto a cualquier(cualesquiera) ruta(s) de confianza encontrada(s). Al pre-calcular todas las rutas posibles, el servidor de UDPDV 30 puede ofrecer descubrimiento de rutas para grandes comunidades con un rendimiento y una escalabilidad relativamente altos.
Ademas del descubrimiento de rutas, el servidor de UDPDV 30 tambien puede proporcionar informacion de validacion (pruebas) para elementos (certificados) de una ruta de confianza. En una forma de realizacion, el servidor de UDPDV 30 obtiene las pruebas (por ejemplo, en forma de una CRL o una respuesta de OCSP) en tiempo real para cada elemento (certificado) de una ruta de confianza que a continuacion se proporciona al usuario. Aunque puede resultar posible mejorar el rendimiento almacenando pruebas en memoria cache, puede seguir habiendo potencial para un rendimiento no optimo en el momento de una solicitud cuando se obtienen pruebas en tiempo real. En otra forma de realizacion, puede haber un mecanismo de validacion de rutas en el servidor de UDPDV 30 que reciba a intervalos regulares, pruebas de estado detalladas, pregeneradas, para cada certificado utilizado por el servidor de UDPDV 30 en relacion con la generacion de rutas de confianza. Para esta forma de realizacion, el servidor de UDPDV 30 puede tener la capacidad de acceder rapidamente a toda la informacion de validacion necesaria que se puede proporcionar a partes que conffan sin requerir ningun tiempo de procesado adicional para recuperar la informacion del estado del certificado para su validacion en tiempo real.
Observese tambien que, si las pruebas se envfan sin solicitud previa (pushed) al servidor de UDPDV 30 (por ejemplo, en forma de respuestas de OCSP pre-firmadas), el servidor de UDPDV 30 puede tener acceso local instantaneo al estado de cada certificado en una ruta de confianza. Para algunas formas de realizacion, el servidor de UDPDV 30 confirma el estado de la ruta de confianza antes de devolver la ruta de confianza para la delegacion de rutas. El servidor de UDPDV 30 opcionalmente tambien puede devolver las pruebas de estado al usuario para permitir una validacion completa local de la ruta de confianza por parte del usuario. La naturaleza individualizada, pregenerada, de las pruebas (por ejemplo, respuestas de OCSP pregeneradas) puede permitir un uso eficiente de recursos de red, al mismo tiempo que evita cualesquiera riesgos de seguridad que se puedan asociar a servidores en lfnea, de confianza.
En referencia a la Figura 3, un diagrama 50 muestra una primera area 52 y una segunda area independiente 54. Las areas 52, 54 se pueden interconectar por cualesquiera medios apropiados (por ejemplo, una red o conexion directa) para permitir un intercambio de senales entre ellas. La primera area 52 incluye una pluralidad de certificados 62 a 64. La segunda area 54 incluye una pluralidad de certificados diferentes 66 a 68. La primera area 52 representa una localidad que puede ser gestionada y a la que puede acceder localmente un usuario de ella. De manera similar, la segunda area 54 representa una localidad separada que puede ser gestionada y a la que puede acceder localmente un usuario diferente en ella. Asf, por ejemplo, un usuario del area 52 puede acceder localmente a cualquiera o a la totalidad de los certificados 62 a 64.
En el area 52, el certificado 62 es un certificado rafz (certificado rafz de confianza) auto-certificatorio para una autoridad A1. El certificado 62 tambien certifica el certificado 63 para una autoridad A2, por ejemplo, haciendo que A1 firme el certificado 63. El certificado 63 certifica el certificado 64 para una autoridad A3. Observese que, en este ejemplo, si un usuario conffa en A1, entonces el usuario tambien deberfa confiar en A2 (avalada por A1) y tambien deberfa confiar en A3 (avalada por A2). En el area 54, el certificado 66 es un certificado rafz auto-certificatorio (certificado rafz de confianza) para una autoridad A1'. El certificado 66 tambien certifica al certificado 67 para una autoridad A2', y el certificado 67 certifica al certificado 68 para una autoridad A3'. El certificado 62 se certifica de manera cruzada con el certificado 66, de manera que cada uno de los certificados 62, 66 certifica el otro de los certificados 62, 66.
Si a un usuario en el area 52 se le presenta un certificado de destino firmado por A3', es posible que el usuario no pueda verificar inmediatamente que el certificado de destino es valido en caso de que el usuario del area 52 inicialmente solo tenga conocimiento sobre (y conffe en) A1, A2 y A3. No obstante, observese que la autoridad A2' avala a la autoridad A3', y que la autoridad A1' avala a la autoridad A2'. Observese tambien que la autoridad A1 avala a la autoridad A1'. Asf, suponiendo que un usuario local en el area 52 conffa en A1, entonces existe una ruta de confianza para el usuario desde el certificado 62 al certificado 66 al certificado 67 hacia el certificado 68 hasta el certificado de destino que ha sido firmado por A3'. De este modo, el usuario puede aceptar el certificado de destino firmado por la autoridad A3' gracias a la ruta de confianza desde el certificado de destino al certificado 62 que ha sido firmado por la autoridad de confianza A1. Asf mismo, tal como se describe en alguna otra seccion en la
5
10
15
20
25
30
35
40
45
50
55
60
65
presente, es posible proporcionar informacion de validacion (prueba de validez) para cada uno de los certificados a lo largo de la ruta de confianza, asf como para cualquier autoridad que emitiese informacion de revocacion (en caso de que fuese diferente de la autoridad emisora) de manera que, en el ejemplo el usuario que recibe la ruta de confianza tambien puede recibir informacion de revocacion actualizada para los certificados 62, 66 a 68.
En referencia a la Figura 4, un diagrama 80 ilustra un usuario 82 que recibe informacion de certificacion (e incluye informacion de rutas de confianza y posiblemente informacion de validacion) desde uno o mas de una pluralidad de dispositivos de almacenamiento de datos 84-86 acoplados al usuario 82 por medio de una red 88. En una forma de realizacion de la presente, la red 88 puede ser Internet, aunque pueden utilizarse otras redes adecuadas, incluyendo redes que proporcionan conexiones directas entre el usuario y uno o mas de los dispositivos de almacenamiento de datos 84-86. Observese tambien que el usuario 82 puede almacenar localmente alguna informacion de certificacion. En una forma de realizacion de la presente, al usuario 82 se le pueden presentar uno o mas certificados cuya validez desea determinar el usuario. En algunos casos, el usuario 82 puede determinar la validez de los certificados utilizando datos locales. No obstante, tal como se describe en alguna otra seccion en la presente, puede que sea necesario en otros casos, que el usuario 82 obtenga informacion de certificacion de otras fuentes como los dispositivos de almacenamiento de datos 84-86. En tales casos, entre el usuario y los dispositivos de almacenamiento 84-86, a traves de la red 88 y de una manera directa, se pueden comunicar informacion de certificacion y solicitudes de la misma. Evidentemente, para proporcionar la funcionalidad que se describe en la presente pueden utilizarse cualesquiera tecnicas apropiadas de transmision/solicitud de informacion y de conectividad.
En referencia a la Figura 5, un diagrama de flujo 100 ilustra la inicializacion del servidor de UDPDV 30 para que contenga todas las rutas entre las rafces de confianza (certificados rafz de autoridades de confianza) y otro u otros certificados que emiten certificados y/o avalan otras autoridades. Tal como se describe en alguna otra seccion en la presente, cada una de las rutas de confianza se puede pre-calcular de manera que cuando un usuario presenta un certificado de destino, el servidor de UDPDV puede consultar una tabla, buscar la autoridad que emitio el certificado de destino (o buscar el propio certificado de destino), y proporcionar una ruta de confianza pre-calculada desde el certificado de destino a un certificado rafz de confianza. Tal como tambien se describe en la presente, el servidor de UDPDV 30 puede proporcionar opcionalmente, para los certificados en la ruta de confianza, pruebas que indican que los certificados no han sido revocados.
El procesado para el diagrama de flujo 100 comienza en una primera etapa 102 en la que se construye un grado dirigido para todos los certificados para los cuales se va a almacenar informacion. Un grafo dirigido es un constructo matematico que es bien conocido en la tecnica. Para una forma de realizacion de la presente, se usan todos los certificados de un sistema, incluyendo certificados de usuario final. Para otra forma de realizacion, no se incluyen certificados de usuario final o, alternativamente, se incluyen unicamente algunos certificados de usuario final. En la etapa 102, el grafo dirigido que se construye representa una relacion de confianza entre certificados donde una arista (lfnea de conexion) de grafo indica que una primera autoridad (correspondiente a un certificado conectado por un extremo de la arista) ha avalado a una segunda autoridad (correspondiente a un certificado conectado por el otro extremo de la arista).
Despues de la etapa 102, se encuentra una etapa 104 en la que una variable a modo de fndice, I, se fija igual a uno. La variable a modo de fndice, I, se utiliza para realizar iteraciones a traves de cada uno de los certificados rafz de confianza para el servidor de UDPDV 30. Tal como se describe en alguna otra seccion de la presente, los certificados rafz de confianza se proporcionan como entrada al servidor de UDPDV 30 o estan pre-configurados en este ultimo.
Despues de la etapa 104 se encuentra una etapa de prueba 106 en la que se determinan si la variable a modo de fndice, I, es mayor que el numero de certificados rafz de confianza. En caso afirmativo, entonces se ha completado el procesado. En caso contrario, el control se transfiere desde la etapa de prueba 106 a una etapa 108 para determinar todas las rutas desde el certificado rafz de confianza (correspondiente a la variable a modo de fndice I) a la totalidad del resto de certificados en el grafo dirigido. La etapa 108 se describe de forma mas detallada en algun otro lugar de la presente. Despues de la etapa 108 se encuentra una etapa 112 en la que se incrementa la variable a modo de fndice, I. Despues de la etapa 112, el control se transfiere de vuelta a la etapa de prueba 106, descrita anteriormente.
En referencia a la Figura 6, un diagrama de flujo 120 ilustra mas detalladamente el procesado que se lleva a cabo en relacion con la etapa 108 del diagrama de flujo 100 de la Figura 5. Para cada una de las rafces de confianza, se lleva a cabo una busqueda acfclica en profundidad del grafo dirigido para encontrar todas las rutas de confianza. Para cada certificado que se encuentra en cada ruta, se materializa una entrada en una tabla que indica la ruta de confianza desde el certificado al certificado rafz de confianza.
El procesado comienza en una primera etapa 122, en la que se determina si hay mas rutas a examinar. Observese que, en algunas ocasiones, puede ser posible que exista un certificado rafz de confianza sin ninguna ruta hacia el mismo. No obstante, en la mayorfa de los casos, se espera que cada una de las rafces de confianza tenga por lo menos una ruta hacia la misma. Si en la etapa de prueba 122 se determina que no hay mas rutas a examinar
5
10
15
20
25
30
35
40
45
50
55
60
65
(procesar), entonces el procesado se ha completado. En caso contrario, el control se transfiere desde la etapa de prueba 122 a una etapa 124 en la que se determina la siguiente ruta utilizando la busqueda acfclica en profundidad del grafo dirigido. Despues de la etapa 124 se encuentra una etapa 126 en la que un puntero de certificados, CP, se fija de manera que apunte al extremo de la ruta que se esta examinando (procesando).
Despues de la etapa 126 se encuentra una etapa de prueba 128 que determina si el CP apunta al certificado rafz de confianza, indicando asf que se ha recorrido la ruta completa. En caso afirmativo, entonces el control se transfiere desde la etapa de prueba 128 de vuelta a la etapa 122, descrita anteriormente, para dar inicio a la siguiente iteracion. Si no, el control se transfiere desde la etapa de prueba 128 a una etapa 132 en la que la ruta desde CP al certificado rafz de confianza se registra en la tabla (descrita en alguna otra seccion en la presente) que almacena certificados y rutas de confianza hacia los mismos. En una forma de realizacion, en una parte de la tabla indexada por el certificado al que apunta CP, se registra en la etapa 132 la ruta desde CP al certificado rafz de confianza. Despues de la etapa 132 se encuentra una etapa 134 en la que CP se fija de manera que apunte al certificado previo en la ruta. Asf, CP inicialmente apunta al extremo de la ruta y a continuacion apunta posteriormente a certificados previos de la ruta yendo hacia atras en direccion al certificado rafz de confianza. Despues de la etapa 134, el control se transfiere de nuevo a la etapa de prueba 128, descrita anteriormente.
En referencia a la Figura 7A, una tabla 140 incluye una primera parte 142 indexada por certificados del sistema y que tiene, como elementos, rutas de confianza a cada uno de los certificados. La tabla 140 tambien puede incluir una segunda parte 144 que tambien esta indexada por certificados del sistema. La segunda parte tiene elementos que describen pruebas (por ejemplo, respuestas de OCSP, CRL's, etcetera) que indican el estado de revocacion para cada uno de los certificados correspondientes. En una forma de realizacion que se describe en la presente, las pruebas proporcionadas en la segunda parte 144 se corresponden con el certificado del fndice de manera que, por ejemplo, la entrada de la tabla indexada por C2 se corresponde con una prueba para C2. En otra forma de realizacion, las pruebas proporcionadas en la segunda parte 144 se corresponden con todos los certificados de todas las rutas para una entrada particular de la primera parte 142. Asf, por ejemplo, las pruebas proporcionadas en la segunda parte 144 en relacion con el certificado C2 se corresponden con todos los certificados de las rutas de confianza proporcionadas en la entrada para C2 en la primera parte 142.
En algunas formas de realizacion, puede que resulte posible eliminar una de las partes 142, 144. Asf, por ejemplo, en formas de realizacion con solamente la parte 142, el servidor de UDPDV 30 proporciona rutas de confianza pre- calculadas, aunque no pruebas. Para dichas formas de realizacion, los usuarios o bien pueden renunciar a las pruebas en su totalidad, o bien obtener pruebas en tiempo real, o alguna combinacion de estas opciones (es decir, obtener pruebas para algunos certificados de las rutas pero no para otros). Para formas de realizacion con solamente la parte 144, se pueden determinar rutas de confianza en tiempo real y las pruebas pre-calculadas de la parte 144 pueden ser proporcionadas por el servidor de UDPDV 30.
En referencia a la Figura 7B, otra forma de realizacion utiliza una unica tabla 140' indexada de acuerdo con certificados, en donde tanto las rutas de confianza como las pruebas se proporcionan como elementos de la tabla 140'.
En referencia a la Figura 7C, todavfa otra forma de realizacion ilustra otra configuracion para la tabla 140''. La tabla 140'' se puede indexar de acuerdo con un certificado rafz de confianza particular TR1, TR2... TRN y otros certificados C1, C2,... CN. Los elementos de una entrada de la tabla 140'' contienen rutas de confianza y (opcionalmente) pruebas “P/P” de manera que, por ejemplo, una entrada correspondiente al certificado rafz de confianza TRx y el certificado Cy contiene una o mas rutas de confianza (si es que existe alguna) desde Cy a TRx y, opcionalmente, una o mas pruebas para solamente Cy (en una forma de realizacion) o para todos los certificados de la(s) ruta(s) de confianza (en otra forma de realizacion).
En referencia a la Figura 8, un diagrama de flujo 150 ilustra etapas para el procesado en relacion con el servidor de UDPDV 30 que presta servicio a una solicitud proveniente de un usuario en relacion con una ruta de confianza y, opcionalmente, pruebas para sus certificados. Tal como se describe en algun otro lugar de la presente, al servidor de UDPDV 30 se le puede presentar un certificado de destino particular para el cual el servidor de UDPDV 30 proporciona una ruta de confianza y opcionalmente pruebas que indican el estado de cada certificado en la ruta de confianza. En una forma de realizacion, la ruta de confianza se proporciona a un certificado para una autoridad que emitio el certificado de destino y, opcionalmente, a un certificado para una autoridad que emitio informacion de revocacion para el certificado de destino (en caso de que sea diferente de la autoridad emisora). En otra forma de realizacion, el servidor de UDPDV 30 proporciona una ruta de confianza e informacion de revocacion opcional para el propio certificado de destino.
El procesado comienza en una primera etapa 152 en la que se determina si hay alguna ruta de confianza disponible para el certificado de destino o su emisor. En caso negativo, entonces el control se transfiere desde la etapa 152 a una etapa 154 en la que se lleva a cabo un procesado especial. El procesado especial que se lleva a cabo en la etapa 154 puede incluir publicar un mensaje de error y/o indicar a un usuario de alguna otra manera, que no se ha encontrado ninguna ruta de confianza para el certificado de destino. Despues de la etapa 154 se ha completado el procesado.
5
10
15
20
25
30
35
40
45
50
55
Si en la etapa de prueba 152 se determina que hay rutas de confianza disponibles, entonces el control se transfiere desde la etapa de prueba 152 a una etapa 156 en la que se selecciona la siguiente ruta de confianza para el procesado. En una forma de realizacion de la presente, el sistema puede realizar iteraciones a traves de cada una de las rutas de confianza (proporcionadas por la tabla 140, la tabla 140', o la etapa 140'') para encontrar una ruta de confianza apropiada entre el certificado de destino (o su emisor) y uno o mas de los certificados rafz de confianza. La siguiente ruta de confianza escogida en la etapa 156 se puede seleccionar utilizando cualquiera de entre varios criterios posibles, tales como la ruta mas corta, una ruta que contiene certificados particulares, etcetera.
Despues de la etapa 156 se encuentra una etapa de prueba 158 que determina si existen restricciones sobre la ruta de confianza particular (certificados de la ruta de confianza) seleccionada en la etapa 156. Tal como se describe en alguna otra seccion de la presente, puede haber una o mas restricciones que eviten el uso de una ruta de confianza particular, tales como, por ejemplo, que uno o mas certificados no sean aceptables para ciertas finalidades. Si en la etapa de prueba 158 se determina que existen restricciones que hacen que la ruta de confianza que se esta examinando sea inaceptable, entonces el control se transfiere desde la etapa de prueba 158 de vuelta a la etapa 152, descrita anteriormente. En caso contrario, el control se transfiere desde la etapa de prueba 158 a una etapa 162 en la que se determina si se han solicitado pruebas para los certificados en la ruta de confianza. En caso negativo, entonces el control se transfiere desde la etapa 162 a una etapa 164 en la que la ruta de confianza entre el certificado de destino (o su emisor) y el certificado rafz de confianza se devuelve al usuario. Despues de la etapa 164 se ha completado el procesado.
Si en la etapa de prueba 162 se determina que se han solicitado pruebas, entonces el control se transfiere desde la etapa de prueba 162 a una etapa 166 en la que se obtienen las pruebas (a partir de la tabla 140, la tabla 140', o la tabla 140''). En otras formas de realizacion, las pruebas se pueden obtener en tiempo real. Despues de la etapa 166 se encuentra una etapa 168 en la que se devuelven la ruta de confianza y las pruebas. Despues de la etapa 168 se ha completado el procesado.
Tal como se describe en alguna otra seccion de la presente, en algunos casos, puede que un usuario desee utilizar el servidor 40 de confianza para descubrimiento y validacion delegados y distribuidos de rutas, que devuelve un mensaje firmado (o autenticado de alguna otra manera) que indica si un certificado particular es o no valido. El servidor 40 puede firmar un mensaje que indica que un certificado particular es aceptable o no. El usuario puede basarse en la respuesta firmada de servidor 40 sin conocer o examinar necesariamente la ruta y/o la informacion de validacion de primera mano.
En referencia a la Figura 9, un diagrama de flujo 180 ilustra etapas llevadas a cabo por el servidor 40 en relacion con la construccion y la devolucion de un mensaje firmado que indica que un certificado de destino particular es o no valido. El procesado comienza en una primera etapa 182 en la que la ruta de confianza y las pruebas se obtienen de acuerdo con la descripcion ofrecida en alguna otra seccion de la presente. Despues de la etapa 182 se encuentra una etapa de prueba 184 en la que se examinan la ruta de confianza y las pruebas para determinar si el certificado de destino es valido. La determinacion de la etapa 184 se puede efectuar utilizando la ruta de confianza y pruebas obtenidas en la etapa 182. Si en la etapa de prueba 184 se determina que el certificado de destino es valido, entonces el control se transfiere desde la etapa de prueba 184 a una etapa 186 en la que se crea un mensaje positivo, que indica que el certificado de destino es valido. En caso contrario, si en la etapa de prueba 184 se determina que el certificado de destino no es valido, entonces el control se transfiere desde la etapa de prueba 184 a una etapa 188 en la que se crea un mensaje negativo.
Despues o bien de la etapa 186 o bien de la etapa 188 se encuentra una etapa 192 en la que el mensaje es firmado digitalmente por el servidor 40. Tras la etapa 192 se encuentra una etapa 184 en la que el resultado firmado se devuelve al usuario. Despues de la etapa 194 el procesado se ha completado.
El sistema descrito en la presente se puede implementar utilizando cualquier combinacion apropiada de hardware y/o software, incluyendo software proporcionado en un soporte de almacenamiento (por ejemplo, un disco, una cinta, un CD ROM, una memoria extrafble, etcetera). El software se puede ejecutar sobre hardware especializado, en un ordenador de proposito general, o una combinacion apropiada de los mismos.
Aunque la invencion se ha dado a conocer en relacion con diversas formas de realizacion, se pondran de manifiesto facilmente modificaciones de las mismas para aquellos versados en la materia. Por consiguiente, el alcance de la invencion se expone en las siguientes reivindicaciones.

Claims (11)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    60
    65
    REIVINDICACIONES
    1. Metodo para proporcionar informacion de validacion de rutas para un sistema, que comprende:
    determinar (108, 124) unas rutas de confianza entre un subconjunto de certificados del sistema y por lo menos una rafz de confianza, incluyendo dichas rutas de confianza una cadena de autorizaciones desde un certificado de destino a dicho por lo menos un certificado rafz de confianza;
    almacenar (132) cada una de las rutas de confianza en una tabla antes de una solicitud de informacion de validacion de rutas;
    recibir (182) unas pruebas del estado de revocacion para dicho subconjunto de certificados; caracterizado por que comprende las etapas siguientes: pregenerar dichas pruebas; firmar digitalmente dichas pruebas;
    almacenar dichas pruebas antes de una solicitud de informacion apropiadas para proporcionar validacion; y
    extraer las rutas de confianza almacenadas en la tabla y las respuesta a una solicitud de informacion de validacion de rutas revocacion en tiempo real.
  2. 2. Metodo segun la reivindicacion 1, que ademas comprende:
    aplicar restricciones a la informacion de validacion y proporcionar unicamente informacion de validacion que sea acorde con las restricciones.
  3. 3. Metodo segun cualquiera de las reivindicaciones anteriores, en el que la determinacion de rutas incluye construir un grafo dirigido de rafces de confianza y el subconjunto de certificados y llevar a cabo una busqueda acfclica en profundidad del grafo.
  4. 4. Metodo segun cualquiera de las reivindicaciones anteriores, en el que las pruebas se almacenan en la tabla que contiene la informacion de validacion.
  5. 5. Metodo segun cualquiera de las reivindicaciones anteriores, en el que las pruebas se almacenan en otra tabla que esta separada de la tabla que contiene la informacion de validacion.
  6. 6. Metodo segun cualquiera de las reivindicaciones anteriores, en el que la tabla se indexa utilizando las rafces de confianza o utilizando los certificados.
  7. 7. Metodo, segun la reivindicacion 5, en el que la otra tabla se indexa utilizando las rafces de confianza o utilizando los certificados.
  8. 8. Metodo segun cualquiera de las reivindicaciones anteriores, en el que el subconjunto de certificados incluye rafces de confianza, autoridades que emiten certificados de usuario final, y autoridades que avalan a otras autoridades.
  9. 9. Metodo segun la reivindicacion 8, en el que el subconjunto de certificados ademas incluye certificados de usuario final.
  10. 10. Producto de programa de ordenador previsto en unos medios de almacenamiento internos para su ejecucion en un procesador, que comprende un codigo ejecutable para ejecutar las etapas del metodo segun cualquiera de las reivindicaciones anteriores.
  11. 11. Servidor (30), que comprende: un procesador;
    unos medios de almacenamiento internos acoplados al procesador;
    el producto de programa de ordenador de la reivindicacion 10 previsto en los medios de almacenamiento internos.
    de validacion de rutas, siendo las pruebas
    pruebas pregeneradas almacenadas como sin recuperar la informacion de estado de
ES04811786.5T 2003-11-19 2004-11-19 Descubrimiento y validación de rutas delegadas y distribuidas Active ES2572810T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US52339803P 2003-11-19 2003-11-19
US523398P 2003-11-19
PCT/US2004/039126 WO2005052752A2 (en) 2003-11-19 2004-11-19 Distributed delegated path discovery and validation

Publications (1)

Publication Number Publication Date
ES2572810T3 true ES2572810T3 (es) 2016-06-02

Family

ID=34632777

Family Applications (1)

Application Number Title Priority Date Filing Date
ES04811786.5T Active ES2572810T3 (es) 2003-11-19 2004-11-19 Descubrimiento y validación de rutas delegadas y distribuidas

Country Status (9)

Country Link
US (1) US8707030B2 (es)
EP (1) EP1692596B1 (es)
JP (1) JP2007511983A (es)
KR (1) KR20060097131A (es)
CN (1) CN101124765B (es)
AU (1) AU2004294164B2 (es)
CA (1) CA2544273C (es)
ES (1) ES2572810T3 (es)
WO (1) WO2005052752A2 (es)

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8732457B2 (en) * 1995-10-02 2014-05-20 Assa Abloy Ab Scalable certificate validation and simplified PKI management
US7716486B2 (en) 1995-10-02 2010-05-11 Corestreet, Ltd. Controlling group access to doors
US7660994B2 (en) * 1995-10-24 2010-02-09 Corestreet, Ltd. Access control
US8015597B2 (en) 1995-10-02 2011-09-06 Corestreet, Ltd. Disseminating additional data used for controlling access
US7822989B2 (en) * 1995-10-02 2010-10-26 Corestreet, Ltd. Controlling access to an area
US8261319B2 (en) 1995-10-24 2012-09-04 Corestreet, Ltd. Logging access attempts to an area
US7404080B2 (en) 2001-04-16 2008-07-22 Bjorn Markus Jakobsson Methods and apparatus for efficient computation of one-way chains in cryptographic applications
AU2004239780B2 (en) * 2003-05-13 2009-08-27 Assa Abloy Ab Efficient and secure data currentness systems
WO2005052752A2 (en) 2003-11-19 2005-06-09 Corestreet, Ltd. Distributed delegated path discovery and validation
CA2551819C (en) 2004-01-09 2015-02-24 Corestreet, Ltd. Signature-efficient real time credentials for ocsp and distributed ocsp
US20050154878A1 (en) * 2004-01-09 2005-07-14 David Engberg Signature-efficient real time credentials for OCSP and distributed OCSP
CA2564904C (en) * 2004-04-30 2011-11-15 Research In Motion Limited System and method for handling certificate revocation lists
US7205882B2 (en) * 2004-11-10 2007-04-17 Corestreet, Ltd. Actuating a security system using a wireless device
GB0428596D0 (en) * 2004-12-24 2005-08-10 Qinetiq Ltd Public key infrastructures
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
IL174614A (en) * 2006-03-29 2013-03-24 Yaakov Levy Method of enforcing use of certificate revocation lists
JP5130722B2 (ja) * 2007-01-19 2013-01-30 セイコーエプソン株式会社 認証装置及び方法
US8321841B2 (en) * 2008-01-08 2012-11-27 International Business Machines Corporation Validation framework for service oriented architecture (SOA) application adoption
JP5053179B2 (ja) * 2008-05-30 2012-10-17 株式会社日立製作所 検証サーバ、プログラム及び検証方法
US8595484B2 (en) * 2008-07-29 2013-11-26 Motorola Solutions, Inc. Method and device for distributing public key infrastructure (PKI) certificate path data
US8130146B2 (en) * 2008-07-29 2012-03-06 Motorola Solutions, Inc. Method for measuring the time of arrival of radio signals
US20100036981A1 (en) * 2008-08-08 2010-02-11 Raghavendra Ganesh Finding Hot Call Paths
JP5452099B2 (ja) * 2009-07-01 2014-03-26 株式会社日立製作所 証明書の有効性確認方法、証明書検証サーバ、プログラム及び記憶媒体
CN102053999B (zh) * 2009-10-28 2013-03-13 北京大学 一种基于进程的路径收集方法及系统
US9647925B2 (en) 2014-11-05 2017-05-09 Huawei Technologies Co., Ltd. System and method for data path validation and verification
US10708256B1 (en) * 2015-10-13 2020-07-07 Amazon Technologies, Inc. Identification of trusted certificates
DE102016207294A1 (de) * 2016-04-28 2017-11-02 Siemens Aktiengesellschaft Verfahren und Zertifikatspeicher zur Zertifikatsverwaltung
CN108596618B (zh) * 2018-04-26 2022-03-04 众安信息技术服务有限公司 区块链系统的数据处理方法、装置和计算机可读存储介质
EP3681102B1 (de) * 2019-01-10 2022-03-16 Siemens Aktiengesellschaft Verfahren zur validierung eines digitalen nutzerzertifikats
US11038699B2 (en) * 2019-08-29 2021-06-15 Advanced New Technologies Co., Ltd. Method and apparatus for performing multi-party secure computing based-on issuing certificate

Family Cites Families (145)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4200770A (en) 1977-09-06 1980-04-29 Stanford University Cryptographic apparatus and method
US4218582A (en) 1977-10-06 1980-08-19 The Board Of Trustees Of The Leland Stanford Junior University Public key cryptographic apparatus and method
US4309569A (en) 1979-09-05 1982-01-05 The Board Of Trustees Of The Leland Stanford Junior University Method of providing digital signatures
US4326098A (en) 1980-07-02 1982-04-20 International Business Machines Corporation High security system for electronic signature verification
US4926480A (en) 1983-08-22 1990-05-15 David Chaum Card-computer moderated systems
FR2592510B1 (fr) 1985-12-31 1988-02-12 Bull Cp8 Procede et appareil pour certifier des services obtenus a l'aide d'un support portatif tel qu'une carte a memoire
FR2596177B1 (fr) 1986-03-19 1992-01-17 Infoscript Procede et dispositif de sauvegarde qualitative de donnees numerisees
US4943707A (en) 1987-01-06 1990-07-24 Visa International Service Association Transaction approval system
US4881264A (en) 1987-07-30 1989-11-14 Merkle Ralph C Digital signature system and method based on a conventional encryption function
US5005200A (en) 1988-02-12 1991-04-02 Fischer Addison M Public key/signature cryptosystem with enhanced digital signature certification
US5214702A (en) 1988-02-12 1993-05-25 Fischer Addison M Public key/signature cryptosystem with enhanced digital signature certification
US4944009A (en) 1988-02-25 1990-07-24 Massachusetts Institute Of Technology Pseudo-random sequence generator
US4879747A (en) 1988-03-21 1989-11-07 Leighton Frank T Method and system for personal identification
US4995081A (en) 1988-03-21 1991-02-19 Leighton Frank T Method and system for personal identification using proofs of legitimacy
US4888801A (en) 1988-05-02 1989-12-19 Motorola, Inc. Hierarchical key management system
US5016274A (en) 1988-11-08 1991-05-14 Silvio Micali On-line/off-line digital signing
US5003597A (en) 1989-12-21 1991-03-26 Xerox Corporation Method and apparatus for data encryption
US5136647A (en) 1990-08-02 1992-08-04 Bell Communications Research, Inc. Method for secure time-stamping of digital documents
US5136646A (en) 1991-03-08 1992-08-04 Bell Communications Research, Inc. Digital document time-stamping with catenate certificate
US5315657A (en) 1990-09-28 1994-05-24 Digital Equipment Corporation Compound principals in access control lists
US5396624A (en) 1990-12-20 1995-03-07 Visa International Service Association Account file for off-line transaction authorization
SE470001B (sv) 1991-09-12 1993-10-18 Televerket Förfarande för identifiering och kryptonyckelutbyte mellan två kommunicerande apparater för krypterad trafik
US5340969A (en) 1991-10-01 1994-08-23 Dresser Industries, Inc. Method and apparatus for approving transaction card based transactions
US5157726A (en) 1991-12-19 1992-10-20 Xerox Corporation Document copy authentication
US5261002A (en) 1992-03-13 1993-11-09 Digital Equipment Corporation Method of issuance and revocation of certificates of authenticity used in public key networks and other systems
US5276737B1 (en) 1992-04-20 1995-09-12 Silvio Micali Fair cryptosystems and methods of use
US5315658B1 (en) 1992-04-20 1995-09-12 Silvio Micali Fair cryptosystems and methods of use
USRE36918E (en) 1992-04-20 2000-10-17 Certco Llc Fair cryptosystems and methods of use
US5231666A (en) 1992-04-20 1993-07-27 International Business Machines Corporation Cryptographic method for updating financial records
JP2583010B2 (ja) 1993-01-07 1997-02-19 インターナショナル・ビジネス・マシーンズ・コーポレイション 多層インデックス構造におけるローカルインデックステーブル及び大域インデックステーブルの間の一貫性を維持する方法
US5299263A (en) 1993-03-04 1994-03-29 Bell Communications Research, Inc. Two-way public key authentication and key agreement for low-cost terminals
NL9300566A (nl) 1993-03-31 1994-10-17 Nedap Nv Toegangsverleningssysteem met decentrale autorisaties.
US5351302A (en) 1993-05-26 1994-09-27 Leighton Frank T Method for authenticating objects identified by images or other identifying information
CA2169449A1 (en) 1993-08-13 1995-02-23 Frank Thomson Leighton Secret key exchange
US5432852A (en) 1993-09-29 1995-07-11 Leighton; Frank T. Large provably fast and secure digital signature schemes based on secure hash functions
US5497422A (en) 1993-09-30 1996-03-05 Apple Computer, Inc. Message protection mechanism and graphical user interface therefor
US5371794A (en) 1993-11-02 1994-12-06 Sun Microsystems, Inc. Method and apparatus for privacy and authentication in wireless networks
US5450493A (en) 1993-12-29 1995-09-12 At&T Corp. Secure communication method and apparatus
US5434919A (en) 1994-01-11 1995-07-18 Chaum; David Compact endorsement signature systems
US5825880A (en) 1994-01-13 1998-10-20 Sudia; Frank W. Multi-step digital signature method and system
MX9602773A (es) 1994-01-13 1997-05-31 Bankers Trust Co Sistema criptografico y metodo con aspecto de deposito de plica de clave.
US20020013898A1 (en) 1997-06-04 2002-01-31 Sudia Frank W. Method and apparatus for roaming use of cryptographic values
US5537475A (en) 1994-02-01 1996-07-16 Micali; Silvio Efficient digital signature algorithm and use thereof technical field
US5420927B1 (en) 1994-02-01 1997-02-04 Silvio Micali Method for certifying public keys in a digital signature scheme
US5544322A (en) 1994-05-09 1996-08-06 International Business Machines Corporation System and method for policy-based inter-realm authentication within a distributed processing system
FR2722596A1 (fr) 1994-07-13 1996-01-19 France Telecom Systeme de controle d'acces limites a des places horaires autorisees et renouvables au moyen d'un support de memorisation portable
ATE305682T1 (de) 1994-07-19 2005-10-15 Certco Llc Verfahren zur sicheren anwendung digitaler unterschriften in einem kommerziellen verschlüsselungssystem
US7904722B2 (en) 1994-07-19 2011-03-08 Certco, Llc Method for securely using digital signatures in a commercial cryptographic system
US5499296A (en) 1994-08-22 1996-03-12 Micali; Silvio Natural input encryption and method of use
US5659617A (en) 1994-09-22 1997-08-19 Fischer; Addison M. Method for providing location certificates
US5606617A (en) 1994-10-14 1997-02-25 Brands; Stefanus A. Secret-key certificates
US5615268A (en) 1995-01-17 1997-03-25 Document Authentication Systems, Inc. System and method for electronic transmission storage and retrieval of authenticated documents
US5748738A (en) 1995-01-17 1998-05-05 Document Authentication Systems, Inc. System and method for electronic transmission, storage and retrieval of authenticated documents
EP0723251A3 (en) 1995-01-20 1998-12-30 Tandem Computers Incorporated Method and apparatus for user and security device authentication
US6658568B1 (en) 1995-02-13 2003-12-02 Intertrust Technologies Corporation Trusted infrastructure support system, methods and techniques for secure electronic commerce transaction and rights management
US5553145A (en) 1995-03-21 1996-09-03 Micali; Silvia Simultaneous electronic transactions with visible trusted parties
US6141750A (en) 1995-03-21 2000-10-31 Micali; Silvio Simultaneous electronic transactions with subscriber verification
US6137884A (en) 1995-03-21 2000-10-24 Bankers Trust Corporation Simultaneous electronic transactions with visible trusted parties
US6134326A (en) 1996-11-18 2000-10-17 Bankers Trust Corporation Simultaneous electronic transactions
US5677955A (en) 1995-04-07 1997-10-14 Financial Services Technology Consortium Electronic funds transfer instruments
US20030014629A1 (en) * 2001-07-16 2003-01-16 Zuccherato Robert J. Root certificate management system and method
DE69638307D1 (de) 1995-06-05 2011-01-27 Cqrcert Llc Verfahren und Einrichtung zur digitalen Unterschrift in mehreren Schritten
US5666415A (en) 1995-07-28 1997-09-09 Digital Equipment Corporation Method and apparatus for cryptographic authentication
US7600129B2 (en) 1995-10-02 2009-10-06 Corestreet, Ltd. Controlling access using additional data
US6097811A (en) * 1995-11-02 2000-08-01 Micali; Silvio Tree-based certificate revocation system
US8015597B2 (en) 1995-10-02 2011-09-06 Corestreet, Ltd. Disseminating additional data used for controlling access
US7660994B2 (en) 1995-10-24 2010-02-09 Corestreet, Ltd. Access control
US7337315B2 (en) 1995-10-02 2008-02-26 Corestreet, Ltd. Efficient certificate revocation
US6487658B1 (en) 1995-10-02 2002-11-26 Corestreet Security, Ltd. Efficient certificate revocation
US7822989B2 (en) 1995-10-02 2010-10-26 Corestreet, Ltd. Controlling access to an area
US7716486B2 (en) 1995-10-02 2010-05-11 Corestreet, Ltd. Controlling group access to doors
US7353396B2 (en) 1995-10-02 2008-04-01 Corestreet, Ltd. Physical access control
US5717758A (en) 1995-11-02 1998-02-10 Micall; Silvio Witness-based certificate revocation system
US5717757A (en) 1996-08-29 1998-02-10 Micali; Silvio Certificate issue lists
US5793868A (en) 1996-08-29 1998-08-11 Micali; Silvio Certificate revocation system
US5666416A (en) 1995-10-24 1997-09-09 Micali; Silvio Certificate revocation system
US8732457B2 (en) 1995-10-02 2014-05-20 Assa Abloy Ab Scalable certificate validation and simplified PKI management
US6766450B2 (en) 1995-10-24 2004-07-20 Corestreet, Ltd. Certificate revocation system
US6292893B1 (en) 1995-10-24 2001-09-18 Silvio Micali Certificate revocation system
US5604804A (en) 1996-04-23 1997-02-18 Micali; Silvio Method for certifying public keys in a digital signature scheme
US8261319B2 (en) 1995-10-24 2012-09-04 Corestreet, Ltd. Logging access attempts to an area
US5687235A (en) 1995-10-26 1997-11-11 Novell, Inc. Certificate revocation performance optimization
US6301659B1 (en) 1995-11-02 2001-10-09 Silvio Micali Tree-based certificate revocation system
US5699431A (en) 1995-11-13 1997-12-16 Northern Telecom Limited Method for efficient management of certificate revocation lists and update information
US5774552A (en) 1995-12-13 1998-06-30 Ncr Corporation Method and apparatus for retrieving X.509 certificates from an X.500 directory
US6026163A (en) 1995-12-13 2000-02-15 Micali; Silvio Distributed split-key cryptosystem and applications
US5812670A (en) 1995-12-28 1998-09-22 Micali; Silvio Traceable anonymous transactions
US5615269A (en) 1996-02-22 1997-03-25 Micali; Silvio Ideal electronic negotiations
US5790665A (en) 1996-01-17 1998-08-04 Micali; Silvio Anonymous information retrieval system (ARS)
US5666414A (en) 1996-03-21 1997-09-09 Micali; Silvio Guaranteed partial key-escrow
US5826262A (en) 1996-03-22 1998-10-20 International Business Machines Corporation Parallel bottom-up construction of radix trees
DE19611632A1 (de) 1996-03-25 1997-10-02 Deutsche Telekom Ag Off-Line-Datenstationen mit virtueller On-Line-Fähigkeit
US5742035A (en) 1996-04-19 1998-04-21 Kohut; Michael L. Memory aiding device for credit card pin numbers
US6216231B1 (en) 1996-04-30 2001-04-10 At & T Corp. Specifying security protocols and policy constraints in distributed systems
US5903651A (en) * 1996-05-14 1999-05-11 Valicert, Inc. Apparatus and method for demonstrating and confirming the status of a digital certificates and other data
US5638447A (en) 1996-05-15 1997-06-10 Micali; Silvio Compact digital signatures
US5610982A (en) 1996-05-15 1997-03-11 Micali; Silvio Compact certification with threshold signatures
EP0917781A4 (en) 1996-08-07 2003-08-13 Silvio Micali SIMULTANEOUS ELECTRONIC TRANSACTIONS WITH VISIBLE TRUTH AGENTS
US6119137A (en) 1997-01-30 2000-09-12 Tumbleweed Communications Corp. Distributed dynamic document conversion server
US6502191B1 (en) 1997-02-14 2002-12-31 Tumbleweed Communications Corp. Method and system for binary data firewall delivery
US5790790A (en) 1996-10-24 1998-08-04 Tumbleweed Software Corporation Electronic document delivery system in which notification of said electronic document is sent to a recipient thereof
US6192407B1 (en) 1996-10-24 2001-02-20 Tumbleweed Communications Corp. Private, trackable URLs for directed document delivery
US6385655B1 (en) 1996-10-24 2002-05-07 Tumbleweed Communications Corp. Method and apparatus for delivering documents over an electronic network
US5903882A (en) 1996-12-13 1999-05-11 Certco, Llc Reliance server for electronic transaction system
US20010050990A1 (en) 1997-02-19 2001-12-13 Frank Wells Sudia Method for initiating a stream-oriented encrypted communication
US5982898A (en) 1997-03-07 1999-11-09 At&T Corp. Certification process
US5995625A (en) 1997-03-24 1999-11-30 Certco, Llc Electronic cryptographic packing
US6061448A (en) 1997-04-01 2000-05-09 Tumbleweed Communications Corp. Method and system for dynamic server document encryption
US6044462A (en) 1997-04-02 2000-03-28 Arcanvs Method and apparatus for managing key revocation
EP1010283B1 (en) 1997-07-24 2006-11-29 Tumbleweed Communications Corp. E-mail firewall with stored key encryption/decryption
US5875894A (en) 1997-09-18 1999-03-02 Stromme; Bonnie S. Combined sandwich holder and place mat
US6651166B1 (en) 1998-04-09 2003-11-18 Tumbleweed Software Corp. Sender driven certification enrollment system
US6397329B1 (en) 1997-11-21 2002-05-28 Telcordia Technologies, Inc. Method for efficiently revoking digital identities
FR2774833B1 (fr) 1998-02-09 2003-02-21 France Telecom Protocole de controle d'acces entre une cle et une serrure electroniques
US6134550A (en) 1998-03-18 2000-10-17 Entrust Technologies Limited Method and apparatus for use in determining validity of a certificate in a communication system employing trusted paths
JP3801782B2 (ja) * 1998-06-22 2006-07-26 三菱電機株式会社 証明証収集情報生成装置、証明証検証装置および公開鍵暗号運用システム
US6189103B1 (en) 1998-07-21 2001-02-13 Novell, Inc. Authority delegation with secure operating system queues
US6151675A (en) 1998-07-23 2000-11-21 Tumbleweed Software Corporation Method and apparatus for effecting secure document format conversion
US6397197B1 (en) 1998-08-26 2002-05-28 E-Lynxx Corporation Apparatus and method for obtaining lowest bid from information product vendors
DE69924349T2 (de) 1999-01-28 2006-02-09 International Business Machines Corp. Elektronisches Zugangskontrollsystem und Verfahren
US6671805B1 (en) 1999-06-17 2003-12-30 Ilumin Corporation System and method for document-driven processing of digitally-signed electronic documents
JP2001005793A (ja) * 1999-06-24 2001-01-12 Mitsubishi Electric Corp 事象管理システム
WO2001006701A1 (en) 1999-07-15 2001-01-25 Sudia Frank W Certificate revocation notification systems
WO2001011843A1 (en) 1999-08-06 2001-02-15 Sudia Frank W Blocked tree authorization and status systems
AU6760900A (en) 1999-08-09 2001-03-05 Frank W Sudia Distributed rule enforcement systems
US6725381B1 (en) 1999-08-31 2004-04-20 Tumbleweed Communications Corp. Solicited authentication of a specific user
US20020029200A1 (en) 1999-09-10 2002-03-07 Charles Dulin System and method for providing certificate validation and other services
WO2001025874A2 (en) 1999-10-04 2001-04-12 Os Crypto, Inc. System and methods of providing verified network sessions with visual confirmation
WO2001031588A2 (en) 1999-10-28 2001-05-03 Brivo Systems, Inc. System and method for providing access to an unattended storage device
US6826609B1 (en) 2000-03-31 2004-11-30 Tumbleweed Communications Corp. Policy enforcement in a secure data file delivery system
JP3588042B2 (ja) * 2000-08-30 2004-11-10 株式会社日立製作所 証明書の有効性確認方法および装置
JP3971890B2 (ja) 2000-11-01 2007-09-05 日本電信電話株式会社 署名検証支援装置、署名検証支援方法、及び電子署名検証方法
JP3901463B2 (ja) * 2001-02-21 2007-04-04 日本電信電話株式会社 認証システムアクセス装置及び公開鍵証明証取得方法及び公開鍵証明証無効化確認方法及び、認証システムアクセスプログラム及び公開鍵証明証取得プログラム及び公開鍵証明証無効化確認プログラム及び認証システムアクセスプログラムを格納した記憶媒体及び公開鍵証明証取得プログラムを格納した記憶媒体及び公開鍵証明証無効化確認プログラムを格納した記憶媒体
US6970862B2 (en) 2001-05-31 2005-11-29 Sun Microsystems, Inc. Method and system for answering online certificate status protocol (OCSP) requests without certificate revocation lists (CRL)
JP2003030145A (ja) 2001-07-16 2003-01-31 Fujitsu Ltd 情報処理方法およびプログラム
US7328344B2 (en) 2001-09-28 2008-02-05 Imagitas, Inc. Authority-neutral certification for multiple-authority PKI environments
NL1019722C2 (nl) * 2002-01-09 2003-07-11 Fountain Tech Bv Inrichting en werkwijze voor het verpakken van plaatvormige informatiedragers.
US8195933B2 (en) * 2002-01-10 2012-06-05 International Business Machines Corporation Method and system for computing digital certificate trust paths using transitive closures
WO2003088166A2 (en) * 2002-04-08 2003-10-23 Corestreet, Ltd. Physical access control
US7318155B2 (en) 2002-12-06 2008-01-08 International Business Machines Corporation Method and system for configuring highly available online certificate status protocol responders
AU2004239780B2 (en) 2003-05-13 2009-08-27 Assa Abloy Ab Efficient and secure data currentness systems
JP3894181B2 (ja) * 2003-10-10 2007-03-14 株式会社日立製作所 公開鍵証明書検証の高速化方法、および装置
WO2005052752A2 (en) 2003-11-19 2005-06-09 Corestreet, Ltd. Distributed delegated path discovery and validation
US20050154878A1 (en) 2004-01-09 2005-07-14 David Engberg Signature-efficient real time credentials for OCSP and distributed OCSP
CA2551819C (en) 2004-01-09 2015-02-24 Corestreet, Ltd. Signature-efficient real time credentials for ocsp and distributed ocsp

Also Published As

Publication number Publication date
US20050154918A1 (en) 2005-07-14
WO2005052752A3 (en) 2006-12-28
AU2004294164B2 (en) 2010-06-10
KR20060097131A (ko) 2006-09-13
CN101124765A (zh) 2008-02-13
EP1692596A2 (en) 2006-08-23
CA2544273C (en) 2015-01-13
AU2004294164A1 (en) 2005-06-09
JP2007511983A (ja) 2007-05-10
CA2544273A1 (en) 2005-06-09
WO2005052752A2 (en) 2005-06-09
EP1692596B1 (en) 2016-03-09
CN101124765B (zh) 2013-08-07
US8707030B2 (en) 2014-04-22
EP1692596A4 (en) 2013-10-16

Similar Documents

Publication Publication Date Title
ES2572810T3 (es) Descubrimiento y validación de rutas delegadas y distribuidas
Ni et al. Privacy-preserving smart parking navigation supporting efficient driving guidance retrieval
US6097811A (en) Tree-based certificate revocation system
Wang et al. Storing shared data on the cloud via security-mediator
US7290133B1 (en) Method and apparatus improving efficiency of end-user certificate validation
US7512782B2 (en) Method and system for using a web service license
US20070250700A1 (en) Peer-to-peer contact exchange
CN109005035A (zh) 一种网联汽车远程匿名签发验证通信系统及方法
CN111340485B (zh) 一种用于联盟区块链的数字证书的配置方法、终端和根证书服务器
US9680655B2 (en) Public-key certificate management system and method
ES2906346T3 (es) Divulgación selectiva de atributos y entradas de datos de un registro
Gonzalez et al. Verifying post-quantum signatures in 8 kB of RAM
TW202217620A (zh) 用於憑證驗證之驗證需求文件
Conley Encryption, hashing, ppk, and blockchain: A simple introduction
Fang et al. Blockchain‐based privacy‐preserving valet parking for self‐driving vehicles
Prakasha et al. Efficient digital certificate verification in wireless public key infrastructure using enhanced certificate revocation list
Kurariya et al. Experimentation on Usage of PQC Algorithms for eSign
Noor et al. Secure and transparent public-key management system for vehicular social networks
Bao et al. BAP: A Blockchain-Assisted Privacy-Preserving Authentication Protocol With User-Controlled Data Linkability for VANETs
Sudarsono et al. Anonymous IEEE802. 1X authentication system using group signatures
EP1164746B1 (en) Tree-based certificate revocation system
Fei A Global Authentication System
Fukushima et al. VIGraph–A Framework for Verifiable Information
Tsai Robust distributed reprogramming protocol of wireless sensor networks for healthcare systems
Mouleeswaran et al. Hoarding Mutual Data via Security-Arbiteron the Cloud