ES2847751T3 - Infraestructura de clave pública y método de distribución - Google Patents

Abstract

Método implementado por ordenador para la conexión y/o la validación de las identidades respectivas de entidades cooperantes en una red informática, comprendiendo el método las etapas de: recibir (5), en una entidad en la red informática, un certificado digital firmado que comprende: una clave pública asociada a la entidad y que tiene una clave privada correspondiente; y 1un identificador arbitrario asociado con la clave pública; intercambiar el identificador arbitrario y un identificador arbitrario de una entidad cooperante con la entidad cooperante en la red (7); conectar directamente con la entidad cooperante usando la información de dirección de red basada en los identificadores arbitrarios intercambiados proporcionados por un servicio (11) de descubrimiento; realizar un intercambio de certificados digitales entre las entidades, demostrando cada entidad conocimiento de su clave (16) privada respectiva; validar que los identificadores arbitrarios intercambiados coinciden con los identificadores arbitrarios proporcionados en los certificados digitales y validar el conocimiento de las claves privadas; y permitir el establecimiento de una conexión segura entre las entidades si la validación es exitosa para ambas partes (17).

Description

DESCRIPCIÓN

Infraestructura de clave pública y método de distribución

La presente invención se refiere en general a métodos y a sistemas de autenticación y, más particularmente, a una infraestructura de clave pública (PKI) y a la verificación de las partes que desean establecer conexiones seguras para una comunicación basada en ordenador. La invención es particularmente adecuada para su uso por partes cooperantes que desean utilizar el conocimiento de las claves públicas de cada uno antes de establecer una conexión segura. Proporciona una infraestructura para la distribución de claves públicas.

Muchos sistemas usan la criptografía de clave pública como un bloque de construcción para comunicaciones confidenciales. Estos protocolos criptográficos se basan en algoritmos que requieren dos claves matemáticamente emparejadas. La clave pública puede distribuirse libremente, mientras que la clave privada se mantiene en secreto. Durante el uso, cuando los participantes desean establecer una comunicación confidencial usando criptografía de clave pública, intercambian las claves públicas, pero mantienen en secreto sus claves privadas. De esta manera, una de las partes puede usar una clave pública para encriptar los datos en el extremo de transmisión de una conexión, y otra de las partes puede desencriptarlos en el extremo de recepción usando la clave privada secreta. La criptografía de clave pública puede usarse también en una construcción de clave efímera, que permite que las partes acuerden una clave secreta compartida. Este intercambio se firma usando las claves privadas de cada participante, y la clave pública se usa para validar las firmas.

Sin embargo, el uso de la criptografía de clave pública presenta un conjunto común de problemas logísticos:

1. Validación de identidad

¿Cómo podemos estar seguros de que Alice es la misma Alice que creemos que es?

2. Distribución de clave pública

¿Cómo obtenemos el conocimiento de la clave pública de Alice, y cómo obtiene ella el conocimiento de la nuestra? 3. Autenticidad de la clave pública

¿Cómo validamos que la clave pública obtenida para Alice es realmente su clave pública?

La criptografía de clave pública se usa comúnmente en situaciones en las que los ordenadores se conectan unos con otros usando una topología cliente-servidor (por ejemplo, servidor y navegador web) con pocas oportunidades para que el usuario final realice una validación de identidad en la vida real de la parte remota. Una autoridad de certificación (CA) actúa como una tercera parte común de confianza. Dentro del campo de la infraestructura de clave pública (PKI), la CA es responsable de verificar las identidades de los usuarios del sistema. La tarea de la CA es vincular entre sí un nombre y una clave pública, y lo hace emitiendo certificados digitales firmados criptográficamente a los usuarios. La CA que emite el certificado debe ser de confianza para comprobar de manera apropiada la identidad del titular de la clave privada, y debe ser diligente al vincular su clave pública a un nombre pertinente y único en el mundo, determinado, por ejemplo, MyCompany.com o MyCompany Limited.

Esta vinculación nombre-a-clave se realiza debido a que las claves públicas son números enteros grandes, frecuentemente representados con un esquema de codificación binario-a-texto, tal como base 64. Dichos números no pueden ser recordados ni manipulados fácilmente por los usuarios humanos. De esta manera, la manipulación manual de los valores de clave pública es una tarea propensa a la confusión, engorrosa, requiere mucho tiempo, propensa a errores e indeseable para los usuarios finales. Por consiguiente, las autoridades de certificación proporcionan asignaciones pertinentes de nombre único en el mundo a clave pública para los usuarios finales mediante certificados bajo la premisa de que a los seres humanos les resulta más fácil manipular nombres cortos que números largos o texto codificado.

De esta manera, considérese un escenario en el que Bob desea establecer una conexión segura con Alice. El software de punto final de Bob recibe un certificado digital, firmado por una CA de confianza. Si el nombre del certificado coincide con el nombre que ha proporcionado Alice, y el punto final que envió el certificado a Bob puede demostrar que conoce la clave privada correspondiente a la clave pública en el certificado, Bob puede suponer que Alice es la propietaria de este certificado y que Alice es realmente el punto final con el que se está comunicando.

Sin embargo, la suposición de que las partes que están conectadas no pueden validar entre sí sus identidades en persona no es universalmente apropiado. En muchos casos, las partes que se comunican ya se conocen entre sí. Según la PKI convencional, para usar certificados, dichas partes todavía deben padecer los inconvenientes de probar sus identidades a la tercera parte de confianza para una auditoría, o establecer sus propias infraestructuras de emisión de certificados para uso privado.

Las redes privadas virtuales (VPNs) son un ejemplo bien conocido de una clase de conexiones que se establecen frecuentemente con intención mutua entre grupos de participantes bien definidos que invariablemente comparten unos con otros una relación en el mundo real. Debido a que las partes que se conectan se conocen mutuamente entre sí, y cooperan, son capaces de realizar una validación directa y en persona de las identidades de unos y otros.

Por lo tanto, en situaciones relacionadas con partes que cooperan y que se conocen mutuamente, la pregunta que queda por responder es cómo realizar el intercambio de claves públicas. No se requiere necesariamente una tercera parte de confianza (por ejemplo, una CA) para que los participantes confíen en las identidades de unos y otros durante el intercambio de claves públicas, pero si la CA se elimina del proceso, entonces las partes no son capaces de utilizar la asignación nombre-a-clave más fácil de manipular proporcionada convencionalmente por la CA. El documento WO 2007/073603 A se refiere a una PKI basada en sesión con certificados anónimos, en la que un nombre distinguido para las claves públicas certificadas es único y anónimo.

De esta manera, es deseable proporcionar una solución que permita una distribución de claves públicas fiable, sencilla y eficiente entre las partes que puedan y que deseen asumir una responsabilidad en persona para validar las identidades de unos y otros. Dicha solución debería comprender idealmente un identificador fácil de usar, de forma corta, para una clave pública, para proporcionar un mecanismo alternativo para la asignación nombre pertinente-aclave convencional proporcionada por la CA.

Ahora, se ha ideado dicha solución mejorada. De esta manera, según la presente invención, se proporciona una solución tal como se define en las reivindicaciones adjuntas.

Por lo tanto, según la invención, se proporciona un método implementado por ordenador para la conexión a y/o la validación de las identidades respectivas de las entidades cooperantes en una red informática, tal como se define en la reivindicación 1 adjunta.

El método puede proporcionar un mecanismo para el intercambio de claves públicas, la validación de identidades y/o el establecimiento de comunicaciones seguras entre las entidades en una red. La red puede ser cualquier tipo de red electrónica. Puede ser una red inalámbrica. Puede proporcionar un mecanismo para establecer una VPN de una manera sencilla, segura y rápida. Puede describirse como un método de autenticación para el establecimiento de las identidades de los participantes en una PKI. Puede usarse para autenticar las partes asociadas con o registradas para participar en una VPN.

La clave pública es parte de un par de claves pública y privada. El par de claves puede ser generado por la entidad. La entidad puede ser un dispositivo de punto final en una red informática, o un componente de software o un usuario. La entidad puede ser una parte que tiene acceso a una red informática y que desea establecer una comunicación electrónica segura con otra entidad.

Preferiblemente, el identificador es arbitrario de manera que la identidad de la entidad no pueda discernirse únicamente a partir del identificador. Puede hacerse referencia al identificador como identificador aleatorio. El identificador puede usarse como un nombre distinguido en el certificado digital. Puede ser firmado digitalmente en el certificado con la clave pública. El identificador puede ser asignado a, o puede ser asociado con, la clave pública por una autoridad de certificación.

Preferiblemente, el identificador arbitrario es corto en comparación con la clave pública. Esto proporciona la ventaja de que los usuarios humanos pueden manipular y usar más fácilmente el identificador arbitrario.

El certificado digital puede ser generado y/o emitido por una autoridad de certificación (CA). La CA puede emitir el certificado a la entidad en tiempo real. Puede emitirlo como una comunicación máquina-a-máquina entre la entidad y la CA sin la intervención de un usuario. De esta manera, puede ser un proceso totalmente automatizado. La CA puede mantener una base de datos u otro registro para almacenar el identificador y su clave pública correspondiente. De manera adicional o alternativa, el certificado digital puede ser generado en respuesta a una solicitud de firma de certificado (CSR). La CSR puede comprender la clave pública. La CSR puede ser enviada a la CA desde la entidad a través de una red inalámbrica.

De manera adicional o alternativa, el certificado digital puede ser transmitido desde dicha entidad a al menos otra entidad en la red. La transmisión puede realizarse a través de una red informática o de telecomunicaciones. Puede transmitirse de manera inalámbrica.

El identificador arbitrario puede no ser único a nivel mundial. Sin embargo, preferiblemente, es exclusivo de la entidad emisora en el sentido de que la CA no asociará ese mismo identificador con ninguna otra clave pública. La CA puede mantener un registro de sólo adición, a largo plazo, de todos los identificadores que ha generado, y las claves públicas a las que se asignaron esos identificadores.

Preferiblemente, el identificador es arbitrario en el sentido de que carece de sentido, y preferiblemente no está ligado, o no se genera con referencia, a la identidad de un usuario o de un punto final. Esto proporciona la ventaja de que una tercera parte no puede identificar al propietario de un certificado digital solo con el conocimiento del identificador. Debido a que el identificador no es un valor secreto, y está destinado a ser compartido, puede transferirse a través de un canal de comunicación no seguro, y no es necesario mantener el mismo confidencial.

Preferiblemente, el método comprende además la etapa de generar el identificador arbitrario usando:

i) un diccionario;

ii) una función hash o de confusión;

iii) una prioridad según orden de llegada;

iv) una fuente de datos aleatoria o pseudo-aleatoria; y/o

v) un contador incremental.

Preferiblemente, el intercambio de identificadores puede realizarse en persona o de alguna otra manera que permita la detección de un ataque hombre-en-el-medio.

La entidad proporciona una indicación del conocimiento de la clave privada asociada a la clave pública. La indicación del conocimiento puede ser proporcionada a una autoridad de certificación como parte de una solicitud de firma de certificado; a al menos a otra entidad como parte de un proceso de validación; y/o a un componente de servicio de descubrimiento dispuesto para proporcionar servicios de directorio, registro y/o reenvío a múltiples entidades en una red informática.

El componente (DS) de servicio de descubrimiento puede ser un componente de software. Puede proporcionar una capacidad de reenvío de tráfico entre entidades en la red. Las entidades en la red pueden usar el DS para registrar su presencia en la red. El DS puede proporcionar a otras entidades información de accesibilidad relacionada con las entidades en la red. El DS puede facilitar la conexión de una entidad a al menos otra entidad. El DS puede configurarse para almacenar y/o mostrar al menos un identificador asociado a una entidad en la red. El DS puede proporcionar un libro o registro de direcciones que una entidad puede usar para almacenar información, incluyendo identificadores arbitrarios, relacionada con otras entidades en la red.

La CA puede requerir una demostración desde la entidad de que tiene la clave privada que corresponde a dicha clave pública. La CA puede emitir un desafío aleatorio (por ejemplo, un valor de un solo uso) a la entidad. La entidad puede firmar el desafío con una clave privada y envía la firma de vuelta a la CA. Esto puede permitir a la entidad proporcionar evidencia de que la entidad es la propietaria de la clave privada para la clave pública.

También según la invención, se proporciona un sistema implementado por ordenador dispuesto y configurado para realizar el método de cualquier realización descrita anteriormente, tal como se define en las reivindicaciones adjuntas. De esta manera, las realizaciones de la invención proporcionan una infraestructura de clave pública ligera que facilita la distribución de claves públicas entre partes que desean y que son capaces de verificar las identidades de cada una de las mismas.

Cabe señalar que cualquier característica descrita anteriormente con relación a un aspecto de la invención puede estar presente también en uno o más de otros aspectos de la invención. Por ejemplo, una característica descrita anteriormente con relación a un método de la invención puede ser aplicable también a un sistema de la invención. Estos y otros aspectos de la presente invención serán evidentes a partir de, y se dilucidarán con referencia a, las realizaciones descritas en el presente documento. A continuación, se describirá una realización de la presente invención, solamente a modo de ejemplo, y con referencia a los dibujos adjuntos, en los que:

La Figura 1 ilustra un proceso de emisión de certificado realizado por una tercera parte que actúa como una autoridad de certificación según una realización ilustrativa de la invención.

La Figura 2 ilustra un intercambio manual de números de identidad cortos (SINs) realizado según una realización ilustrativa de la invención.

La Figura 3 ilustra un intercambio de clave pública automático realizado según una realización ilustrativa de la invención.

La Figura 4 muestra una captura de pantalla según una realización ilustrativa de la invención, e ilustra un sistema usado por las partes que desean conectarse entre sí.

En adelante, se usan los siguientes términos:

• Certificado

Un bloque de datos digital a prueba de manipulaciones, no falsificable, emitido por una CA que indica que una clave pública de un usuario final pertenece a un SIN seleccionado por la misma CA.

• Autoridad de certificación (CA)

Una tercera parte de confianza entre EPs que es responsable de emitir cadenas SIN únicas.

• Solicitud de firma de certificado (CSR)

La CSR es un bloque de texto encriptado que contiene la clave pública seleccionada por el solicitante.

• Servicio de descubrimiento (DS).

Un sistema que proporciona servicios de directorio, servicios de registro y servicios de reenvío de tráfico a EPs. • Punto final (EP)

Un dispositivo de computación que pertenece a un usuario final en posesión de uno o más pares de claves pública/privada.

• Usuario final o usuarios finales

Propietarios y operadores de puntos finales

• Infraestructura de clave pública (PKI)

Un conjunto de software, personas, políticas y procedimientos necesarios para crear, gestionar, distribuir, usar, almacenar y revocar certificados digitales.

• Número de identidad corto (SIN)

Un identificador no secreto, seleccionado aleatoriamente (de manera arbitraria) por una CA para ser usado como un nombre distinguido en un certificado digital. Cada SIN es exclusivo de una clave pública determinada. Las expresiones 'SIN' y 'nombre distinguido' pueden usarse indistintamente. El valor está diseñado de manera que sea de corta longitud (en comparación con una clave pública completa) y está firmado digitalmente en un certificado con la clave pública de un EP. Cabe señalar que el uso de la expresión “SIN” no implica que se usen sólo dígitos numéricos en el nombre distinguido. La invención no está limitada en este sentido. Por ejemplo, el SIN puede comprender números, letras, símbolos, etc., o cualquier combinación de los mismos.

La invención proporciona una infraestructura de clave pública ligera que facilita la distribución de claves públicas entre partes que desean y que son capaces de verificar las identidades de cada una de las mismas. La invención proporciona un nombre de formato corto conveniente que puede ser distribuido en lugar de la clave pública completa por el usuario final, y combina esto con un requisito de que el usuario final realice una validación de identidad (en contraposición a una tercera parte de confianza como en las soluciones convencionales).

Puede hacerse referencia a las partes como “puntos finales”, “entidades”, “participantes” o “usuarios”, pero, en esencia, pueden ser cualquier parte que tenga acceso a una red informática y que desee establecer una comunicación electrónica segura con otra parte. Las partes deben tener cierto conocimiento relacionado con el mundo real, unas de las otras, hasta el punto en el que sean capaces de validar las identidades de las demás. Las partes pueden incluir cualquier tipo de recurso basado en ordenador, tales como dispositivos de computación o recursos basados en software. Por razones de conveniencia, en adelante se usará la expresión “punto final”.

Después de haber verificado las identidades de cada una de las partes, las partes son capaces de establecer una conexión segura para la comunicación. La manera o el tipo de conexión que se establece después de la verificación no está dictada por la invención. Puede utilizarse cualquier método o protocolo de comunicación adecuado. La invención supone también que cada punto final está en posesión de al menos un par de claves pública/privada. El par de claves es generado por los propios puntos 1 finales.

Una realización de la invención en uso puede describirse en términos generales como sigue:

1. Solicitud de certificado (véase la Figura 1):

un punto final envía una CSR a una CA; la CSR incluye la clave pública del punto final y una demostración de que el punto final conoce la clave 1,2 privada correspondiente. Es importante señalar que no es necesario que la CSR incluya ninguna información relativa a la identidad en el mundo real del punto final;

2. La CA crea y firma el certificado digital (véase la Figura 1):

la CA genera un SIN para la clave pública; la CA genera un nuevo certificado en respuesta a la recepción de la CSR 3. que incluye la clave pública del punto final y el valor SIN exclusivo como el nombre distinguido; el certificado firmado digitalmente se devuelve al punto final en respuesta a la CSR; la CA mantiene una base de datos para registrar el SIN y su clave 4 pública correspondiente. Opcionalmente, la CA actualiza y firma y vuelve a publicar un árbol hash de Merkle actualizado en aras de la transparencia. Las etapas 1 y 2 son realizadas por cada punto final que desea usar la infraestructura de clave pública de la invención, pero no se usan dos SINs idénticos dentro de la infraestructura; 3. Las partes que desean conectarse unas con otras intercambian los nombres distinguidos en sus certificados (véase la Figura 2)

Las partes intercambian sus SINs usando medios o métodos de comunicación que son resistentes a ataques hombreen-el-medio, o al menos detectables como tales; estos pueden ser un intercambio en persona; dichos métodos de comunicación hacen uso del conocimiento de las partes, unas de otras, por ejemplo, número de teléfono, reconocimiento facial/de voz, etc.

4. Los puntos finales contactan: (véase la Figura 3)

Los softwares en los puntos finales de Alice y Bob contactan con un servicio de descubrimiento que facilita una conexión directa; el software realiza un intercambio de certificados durante el cual cada propietario de certificado demuestra tener conocimiento de su clave privada respectiva al firmar un valor de un solo uso suministrado por la otra parte

5. Verificación de identidad

Los softwares en los puntos finales comprueban que el nombre distinguido en el certificado que han recibido coincide con el que se proporcionó en la etapa 3; validan que el certificado procede de la CA de confianza, y validan el conocimiento de la clave privada; de esta manera, los softwares están preparados, antes del intercambio de certificados, para esperar un valor particular, por ejemplo, FNQH como un nombre distinguido en un certificado para un punto final determinado. El software mantiene un libro de direcciones u otro registro que almacena los nombres distinguidos para los puntos finales que un usuario “conoce”, por ejemplo, el software de Bob almacena el nombre distinguido de FNQH para Alice. De esta manera, si Bob recibe a continuación un certificado que pretende proceder de Alice con un nombre distinguido de FFEF, su software sabe que debe descartar la comunicación.

6. Conexión o fallo:

Si la etapa 5 de validación es exitosa para ambas partes, la conexión puede establecerse; si no, el intento de conexión falla.

Lo indicado anteriormente se describe más detalladamente como sigue.

El punto final genera un par de claves pública/privada y envía una solicitud de firma de certificado (CSR) a una tercera parte que actúa como autoridad de certificación (CA). La CSR incluye la clave 1 pública del participante. La CA selecciona arbitrariamente un identificador aleatorio o pseudo aleatorio a emparejar con la clave 3 pública del punto final. En adelante, se hará referencia al identificador como un número de identidad corto (SIN) y se usa como un nombre distinguido.

El SIN arbitrario no es único a nivel mundial, tal como un nombre de dominio o un nombre de empresa, por ejemplo. Sin embargo, es exclusivo de la CA emisora en el sentido de que la CA no asociará ese mismo identificador con ninguna otra clave pública durante su tiempo de vida. La CA mantiene un registro de sólo adición, a largo plazo, de todos los SINs que ha generado, y las claves públicas a las que se asignaron 4 esos identificadores.

El SIN asignado es arbitrario en el sentido de que carece de sentido, y no está ligado, o no se genera con referencia, a la identidad de un usuario o de un punto final. Esto es importante, ya que el SIN carece de sentido en un contexto del mundo real. No es necesario mantener el SIN en secreto y puede compartirse a través de un medio de comunicación no seguro.

La longitud de una clave pública convierte en poco práctica la compartición manual entre seres humanos. Según la invención, la CA sirve para crear una asignación entre una clave pública y un nombre legible corto o un número que puede intercambiarse con más facilidad que una clave pública. Se pretende que la longitud del SIN sea más corta en comparación con la clave pública. Esto proporciona una ventaja significativa a un usuario final en el sentido de que un SIN puede ser comunicado fácilmente y puede intercambiarse de manera más conveniente entre seres humanos que las claves públicas completas. Por lo tanto, cuanto más corto es el SIN, más fácil es para un ser humano recordarlo, manipularlo y detectar falsificaciones. El uso de un SIN arbitrario como un nombre distinguido en un certificado proporciona un mecanismo fácil de usar para el intercambio de claves públicas.

Generación de SIN

El SIN puede generarse de una diversidad de maneras, incluyendo, por ejemplo:

1. Manteniendo un contador de números enteros en la CA e incrementando el mismo después de generar un nuevo certificado; el valor del contador puede usarse como el SIN en el certificado.

2. Como en el punto 1 anterior, pero aplicando una función hash al número para crear una cadena alfanumérica única (“única” con respecto a los certificados que ha emitido previamente el CA).

3. Recopilando la entropía desde un generador de números pseudo aleatorio y generando una nueva cadena alfanumérica para cada certificado; comprobando toda la base de datos de nombres emitidos previamente para garantizar que la cadena generada aleatoriamente nunca no se usado antes.

4. Como en el punto 1, o el punto 3; convirtiendo la salida en una secuencia única de cadenas de palabras usando un diccionario de gran tamaño de palabras cortas, fáciles de memorizar (“único” con respecto a los certificados que la CA ha emitido previamente).

5. Un identificador puede ser asignado según el orden de llegada;

por ejemplo, un usuario anónimo puede solicitar un identificador determinado (nombre o “ identificador”) y, siempre que el identificador de solicitud no haya sido registrado anteriormente, puede ser asignado.

En una realización ilustrativa, la CA mantiene un contador de números enteros y usa una biblioteca para convertir cada número en una cadena alfanumérica según una asignación uno-a-uno. A modo de ejemplo, podría usarse el siguiente "diccionario" (ABCDEFGHJKUXYZ23456789) de 22 caracteres para producir cadenas alfanuméricas. Se han eliminado los caracteres de aspecto similar que puede confundirse fácilmente unos con otros (por ejemplo, el número 1 y la letra I). Con 22 caracteres y, por ejemplo, 10 posiciones de caracteres, esto proporciona un total de 26.559.922.791.424 permutaciones posibles. La persona experta apreciará fácilmente que el número de permutaciones puede aumentarse aumentando el número de posiciones o el tamaño del conjunto de caracteres. En un enfoque alternativo, los números enteros pueden asignarse a un diccionario de palabras de gran tamaño. Se produce un nombre de certificado que podría parecerse, por ejemplo, a "oportunidad sueño padre rock". Con una lista de palabras que tiene una longitud de 970 palabras, y con 4 posiciones, son posibles un total de 885.292.810.000 permutaciones.

Antes de que pueda emitirse el certificado, la CA pueden requerir que el punto final que ha suministrado la clave pública esté también en posesión de la clave privada correspondiente. Por lo tanto, la CA requiere una demostración desde el punto final de que tiene la clave privada correcta. La CA emite un desafío aleatorio (por ejemplo, un valor de un solo uso) al punto final. El punto final firma el desafío con su clave privada y envía la firma de vuelta a la CA junto con su CSR 2. Esto proporciona evidencia de que el punto final es propietario de la clave privada y no está tratando de engañar a la CA para que firme una clave pública que no es propiedad del punto final.

A continuación, el certificado digital es creado y firmado por la CA 3 y es devuelto al punto final o a la entidad 5 que lo solicitó. Típicamente, esto sucede casi en tiempo real y como una comunicación máquina-a-máquina entre el punto final y la CA sin la participación del usuario final. El proceso de generación/emisión de certificado puede ser totalmente automatizado y puede ser realizado casi instantáneamente, sin necesidad de ninguna interacción con el usuario para solicitar y recibir un certificado emitido. El certificado digital incluye la clave pública del punto final y el SIN generado por la CA como el nombre distinguido del certificado. El punto final almacena el certificado, junto con la clave privada correspondiente que ha generado, para su uso 6 futuro.

Cada punto final que desea conectarse con otros a través de la infraestructura de la invención obtiene también al menos un certificado desde la CA. A partir de entonces, cuando los puntos finales desean conectarse, pueden asumir para ellos mismos la responsabilidad de la validación de identidad (emparejando un nombre distinguido con una identidad en el mundo real, y decidiendo con qué nombres distinguidos está dispuesto a comunicarse su software) intercambiando los nombres 19 distinguidos en sus certificados en persona, y fuera de banda desde el canal de comunicaciones protegido.

Con el fin de conectarse entre sí, los puntos finales registran su presencia en la red con un servicio 11 de descubrimiento, tal como se muestra en la Figura 4 y en la etapa 10 de la Figura 3. Cada punto final proporciona al DS su certificado emitido por la CA, junto con una demostración del conocimiento de la clave privada asociada a la clave pública en el certificado. El DS 11 registra las ubicaciones de red respectivas a los puntos 12 finales y/o la información de accesibilidad relacionada con los mismos.

Los puntos finales que desean establecer una conexión intercambian los nombres distinguidos desde sus certificados digitales respectivos para realizar la validación (véase la Figura 2). Los dos puntos finales (por ejemplo, Alice y Bob) deben asegurarse de que los certificados respectivos que han recibido proceden genuinamente de la fuente esperada. El nombre distinguido no es un valor secreto y puede cambiarse abierta y libremente. Sin embargo, cada punto final debe ser capaz de decir, con un alto grado de certeza, que el nombre distinguido que han recibido verbal o visualmente procede en realidad del otro punto final. Esto es posible debido a que los usuarios tienen cierto conocimiento o evidencia anterior relacionado con las identidades de unos y otros, por ejemplo, Alice conoce el número de teléfono de Bob, o conoce su aspecto/su voz, o se han conocido en persona.

La Figura 2 muestra el intercambio de SINs en una realización ilustrativa de la invención. Los usuarios pueden transmitir sus nombres distinguidos usando cualquier método de comunicación seleccionado. Sin embargo, con el fin de garantizar que la transmisión no ha sido interceptada por un ataque hombre-en-el-medio, los medios de comunicación en tiempo real son preferidos para el intercambio de SINs. Las conversaciones telefónicas o los intercambios de SINs en persona dificultan la interceptación y la alteración de los nombres distinguidos por parte de un actor malicioso durante un intercambio. Si debe producirse un intercambio de nombres distinguidos entre ordenadores en lugar de entre seres humanos, un administrador puede publicar una lista de nombres distinguidos en una URL de confianza a la que puede hacer referencia el software.

Según la invención, no se recomienda el intercambio de nombres distinguidos a través de terceras partes en tiempo no real, ya que expone potencialmente los puntos finales a un ataque hombre-en-el-medio que podría ver el nombre distinguido alterado antes de que llegue a su destino. La mensajería instantánea, el correo electrónico y los mensajes de texto son métodos de comunicación inseguros en los que la integridad del mensaje no está garantizada y, de esta manera, proporcionan a las partes no autorizadas la posibilidad de interceptar y alterar el nombre 19 distinguido en tránsito durante un intercambio. Si el destinatario no puede detectar la manipulación, la seguridad del método se ve socavada y ambas partes están potencialmente expuestas a un ataque hombre-en-el-medio. Cabe señalar que el flujo de datos representado en la Figura 2 ilustra un intercambio unidireccional de nombres 19 distinguidos. Sin embargo, con el fin de realizar la autenticación mutua, todos los puntos finales en un grupo determinado deben intercambiar completamente sus nombres distinguidos.

Tal como se muestra en la Figura 2, por ejemplo, Alice establece una conexión en el mundo real con Bob y le solicita su SIN. Esta podría ser una conexión telefónica, un encuentro cara a cara o una relación mucho más profunda. Es importante destacar que Alice tiene una confianza en el mundo real de que, cuando Bob comunica su SIN 19, tiene una posibilidad razonable de detectar una parte maliciosa que manipula el valor 7. Si Alice no puede estar segura de que el SIN no ha sido expuesto ni sometido a manipulación durante la comunicación, Alice descarta el SIN de Bob y usa un medio de comunicación más apropiado para volver a solicitar el SIN 8. Si, por el contrario, está segura de que el SIN no ha sido expuesto o alterado, introduce el valor del SIN 19 de Bob en su software DS, junto con una nota o un indicador 18 de que este SIN pertenece a Bob 9.

Una vez que los puntos finales han intercambiado los nombres distinguidos, el servicio 11 de descubrimiento ayuda a cada punto final a localizar, y a conectarse con, otros puntos finales que han afirmado mutuamente que desean conectarse, de manera que a continuación puedan presentar unos a otros sus certificados respectivos. Esto se explica en la Figura 3. Por ejemplo, Alice contacta con el servicio de descubrimiento y solicita información de accesibilidad para un nombre distinguido que ha recibido desde Bob 13. Suponiendo que Bob ha realizado una solicitud similar al DS usando el nombre distinguido que ha obtenido desde Alice, el servicio 11 de descubrimiento proporcionará a cada punto final la información 14 de accesibilidad necesaria, de manera que puedan intentar 15 establecer una conexión de red directa e iniciar un intercambio de certificados. Si los puntos finales no pueden establecer con éxito una conexión directa entre sí, los puntos finales pueden ponerse en contacto entre sí usando un servicio de reenvío de tráfico proporcionado como un componente del DS 16.

Para ilustrar el proceso anterior, supóngase que Alice le dice a Bob (por ejemplo, a través del teléfono o en persona) que el nombre distinguido en su certificado es AFF9. Debido a que Bob conoce a Alice de alguna manera en el mundo real, por ejemplo, se han conocido en persona, Bob puede estar seguro de que, si ve un certificado auténtico procedente de una CA confiable mutua con un nombre distinguido de AFF9, entonces la clave pública firmada en ese certificado pertenece a Alice. Independientemente del punto final que envió a Bob un certificado con un nombre distinguido de AFF9, debe tener también acceso a la clave privada correspondiente, de lo contrario cuando sea requerido por Bob para demostrar el conocimiento de la clave privada (por ejemplo, mediante la firma de un valor aleatorio de un solo uso seleccionado por Bob) no podrá hacerlo, permitiendo a Bob detectar un intento de suplantación usando el certificado de Alice.

De esta manera, los puntos finales son capaces de verificarse unos a otros usando su conocimiento en el mundo real los unos de los otros. Los nombres distinguidos fáciles de usar, cortos, facilitan su intercambio entre usuarios humanos a través de certificados firmados digitalmente.

Tal como se muestra en la Figura 3, una vez intercambiadas las claves públicas, y los puntos finales tienen un canal de comunicación establecido entre unos y otros, los puntos finales pueden realizar una comunicación segura mediante cualquier método o protocolo conocido. Por ejemplo, pueden usarse un algoritmo de intercambio de claves (tal como ECDHE) y un algoritmo de firma (tal como EdDSA) de manera fiable para establecer un secreto compartido, y permitir de esta manera una comunicación confidencial entre los puntos 17 finales.

De esta manera, en comparación con el enfoque convencional, la invención proporciona:

• una menor dependencia de terceras partes de confianza para realizar la validación de identidad

• un novedoso uso de CSR que no contiene información acerca del solicitante

• un novedoso uso de la CA para generar un valor SIN que sirve como un nombre distinguido que se asocia a una clave pública en respuesta a una solicitud de firma de certificado (CSR)

• un requisito de que los usuarios en el mundo real realicen la validación de identidad entre ellos mismos

• un requisito de que los usuarios en el mundo real intercambien manualmente los nombres distinguidos en sus certificados antes de que se produzca la comunicación

• un servicio de descubrimiento que proporciona información de direcciones de red a los puntos finales en base a los nombres distinguidos

• un servicio de descubrimiento que proporciona también una capacidad de reenvío de tráfico entre los puntos finales en el caso en el que no consiguen establecer una conexión de red directa entre sí por cualquier motivo.

Cabe señalar que las realizaciones indicadas anteriormente ilustran en lugar de limitar la invención, y que las personas expertas en la técnica serán capaces de diseñar muchas realizaciones alternativas sin apartarse del alcance de la invención tal como se define en las reivindicaciones adjuntas. En las reivindicaciones, cualquier signo de referencia colocado entre paréntesis no deberá interpretarse como limitativo de las reivindicaciones. Las expresiones "que comprende" y "comprende", y similares, no excluyen la presencia de elementos o etapas distintas de las enumeradas en cualquier reivindicación o en la memoria descriptiva en su conjunto. En la presente memoria descriptiva, "comprende" significa "que incluye o que consiste en" y "que comprende" significa "que incluye o que consiste en". La referencia singular a un elemento no excluye la referencia plural a dichos elementos y viceversa. La invención puede implementarse por medio de hardware que comprende diversos elementos distintos, y por medio de un ordenador programado de manera adecuada. En una reivindicación de dispositivo que enumera diversos medios, varios de estos medios pueden estar materializados en un único elemento de hardware. El simple hecho de que determinadas medidas se mencionen en reivindicaciones dependientes mutuamente diferentes no indica que no pueda usarse una combinación de estas medidas de manera ventajosa.

Claims (14)

REIVINDICACIONES

1. Método implementado por ordenador para la conexión y/o la validación de las identidades respectivas de entidades cooperantes en una red informática, comprendiendo el método las etapas de:

recibir (5), en una entidad en la red informática, un certificado digital firmado que comprende:

una clave pública asociada a la entidad y que tiene una clave privada correspondiente; y

un identificador arbitrario asociado con la clave pública;

intercambiar el identificador arbitrario y un identificador arbitrario de una entidad cooperante con la entidad cooperante en la red (7);

conectar directamente con la entidad cooperante usando la información de dirección de red basada en los identificadores arbitrarios intercambiados proporcionados por un servicio (11) de descubrimiento;

realizar un intercambio de certificados digitales entre las entidades, demostrando cada entidad conocimiento de su clave (16) privada respectiva;

validar que los identificadores arbitrarios intercambiados coinciden con los identificadores arbitrarios proporcionados en los certificados digitales y validar el conocimiento de las claves privadas; y

permitir el establecimiento de una conexión segura entre las entidades si la validación es exitosa para ambas partes (17).

2. Método según la reivindicación 1, en el que el identificador es arbitrario de manera que:

la identidad de la entidad no puede discernirse únicamente a partir del identificador; y/o

su generación es aleatoria o pseudoaleatoria; y/o

la selección del identificador no está relacionada con la identidad de la entidad o la clave pública.

3. Método según la reivindicación 1 o 2, en el que el certificado digital:

es generado y/o es emitido por una autoridad (3) de certificación; y/o

es generado en respuesta a una solicitud de firma de certificado.

4. Método según cualquier reivindicación anterior y que comprende además la etapa de generar el identificador arbitrario usando:

i) un diccionario;

ii) una función hash o de confusión;

iii) una fuente de datos aleatoria o pseudo-aleatoria;

iv) por orden de llegada; y/o

v) un contador incremental.

5. Método según cualquiera de las reivindicaciones anteriores y que comprende además la etapa de:

en el que el intercambio de identificadores (7) arbitrarios se realiza en persona o de alguna otra manera que permita o que facilite la detección de un ataque hombre-en-el-medio, o reduzca la probabilidad de dicho ataque.

6. Método según cualquiera de las reivindicaciones anteriores, en el que la indicación del conocimiento de la clave privada se proporciona:

a una autoridad de certificación como parte de una solicitud de firma de certificado; y/o

al componente de servicio de descubrimiento dispuesto para proporcionar servicios de directorio, registro y/o de reenvío a múltiples entidades en una red informática.

7. Método según cualquiera de las reivindicaciones anteriores en el que el identificador arbitrario es corto en comparación con la clave pública.

8. Sistema implementado por ordenador dispuesto y configurado para realizar el método según cualquiera de las reivindicaciones anteriores.

9. Sistema según la reivindicación 8, en el que el sistema comprende:

una autoridad de certificación dispuesta para generar el certificado digital y el identificador arbitrario asociado con la clave pública.

10. Sistema según la reivindicación 9 en el que la autoridad de certificación está dispuesta y configurada para generar el certificado digital en respuesta a una solicitud de firma de certificado recibida desde la entidad.

11. Sistema según la reivindicación 10, en el que la autoridad de certificación está dispuesta y configurada para: mantener un registro (4) de certificados digitales generados por la autoridad de certificación; y/o

emitir y/o transmitir el certificado digital a la entidad (5).

12. Sistema según la reivindicación 10 u 11, en el que el servicio (11) de descubrimiento está dispuesto para proporcionar servicios de directorio, registro y/o reenvío a múltiples entidades en la red informática.

13. Sistema según la reivindicación 12, en el que el servicio (11) de descubrimiento está dispuesto y configurado para acceder a y/o actualizar un registro de entidades en respuesta a una solicitud de registro desde una entidad en la red.

14. Sistema según las reivindicaciones 12 o 13, en el que el servicio (11) de descubrimiento está dispuesto para: registrar la ubicación de una entidad en una red informática en base al registro realizado usando el certificado digital; y/o

presentar las entidades, unas a las otras.