ES2880012T3 - Método para la autenticación simétrica mutua entre una primera aplicación y una segunda aplicación - Google Patents

Método para la autenticación simétrica mutua entre una primera aplicación y una segunda aplicación Download PDF

Info

Publication number
ES2880012T3
ES2880012T3 ES18713997T ES18713997T ES2880012T3 ES 2880012 T3 ES2880012 T3 ES 2880012T3 ES 18713997 T ES18713997 T ES 18713997T ES 18713997 T ES18713997 T ES 18713997T ES 2880012 T3 ES2880012 T3 ES 2880012T3
Authority
ES
Spain
Prior art keywords
key
application
symmetric key
server
proof
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
ES18713997T
Other languages
English (en)
Inventor
Luis Miguel Huapaya
Anne Marie Praden
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.)
Thales DIS CPL Canada Inc
Thales DIS France SA
Original Assignee
Thales DIS France SA
Safenet Canada Inc
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 Thales DIS France SA, Safenet Canada Inc filed Critical Thales DIS France SA
Application granted granted Critical
Publication of ES2880012T3 publication Critical patent/ES2880012T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • 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/3271—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 using challenge-response
    • H04L9/3273—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 using challenge-response for mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0877—Generation of secret information including derivation or calculation of cryptographic keys or passwords using additional device, e.g. trusted platform module [TPM], smartcard, USB or hardware security module [HSM]
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • 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/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • 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/3218—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 using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • 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/3234—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 additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • 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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/12—Details relating to cryptographic hardware or logic circuitry
    • H04L2209/127—Trusted platform modules [TPM]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Un método (40) para la autenticación simétrica mutua entre una primera aplicación (102) y una segunda aplicación (110), el método comprende: - enviar y/o recibir, mediante un primer servidor (104), como un primer elemento comprendido dentro de una cadena de confianza distribuida, hacia y/o desde al menos un segundo servidor (108), como un segundo elemento comprendido dentro de la cadena de confianza distribuida, al menos una clave simétrica maestra; - enviar (28), mediante el primer servidor, a la primera aplicación, al menos una clave simétrica maestra; - generar (38) dinámicamente, mediante el segundo servidor, una primera clave simétrica derivada utilizando al menos un parámetro de generación de clave y una primera clave simétrica maestra comprendida dentro de al menos una clave simétrica maestra; - enviar (310), mediante el segundo servidor, a la segunda aplicación, la primera clave simétrica derivada y al menos un parámetro de generación de clave el método caracterizado además por - generar (42), mediante la segunda aplicación, una primera prueba de posesión de clave utilizando la primera clave simétrica derivada; - enviar (44), mediante la segunda aplicación, a la primera aplicación, la primera prueba de posesión de clave y al menos un parámetro de generación de clave; - verificar (410) con éxito, mediante la primera aplicación, utilizando al menos un parámetro de generación de clave, la primera clave simétrica maestra y la primera prueba de posesión de clave, que la primera prueba de posesión de clave se ha generado utilizando la primera clave simétrica derivada; - generar (414), mediante la primera aplicación, una segunda prueba de posesión de clave utilizando la primera clave simétrica derivada; - enviar (416), mediante la primera aplicación, a la segunda solicitud, al menos la segunda prueba de posesión de clave; y - verificar (418) con éxito, mediante la segunda aplicación, utilizando la segunda prueba de posesión de clave que la segunda prueba de posesión de clave ha sido generada utilizando la primera clave simétrica derivada, como una clave compartida generada dinámicamente y probada.

Description

DESCRIPCIÓN
Método para la autenticación simétrica mutua entre una primera aplicación y una segunda aplicación
Campo de la invención:
La invención se refiere en general a un método para la autenticación simétrica mutua entre una primera aplicación y una segunda aplicación.
La presente invención puede ser especialmente aplicable a una red de computación en la nube en la que un servidor admite una de las primeras y segundas aplicaciones, como p. ej., un Enclave Mediado por Hardware (o HME), como Intel (Marca registrada) Software Guard eXtensions (o SGX), que puede llevar a cabo una Función Virtual de Red (o NVF).
Dentro de la presente descripción, un HME incluye un código seguro para ser ejecutado por un procesador, como p. ej., una Unidad Central de Procesamiento (o CPU), que ofrece confidencialidad e integridad tanto al código como a los datos dentro del enclave, de modo que el único código que accede los datos dentro del enclave es el código seguro dentro del enclave. El propio procesador hace cumplir dicha garantía, independientemente en particular del Sistema Operativo (o OS) anfitrión. En otras palabras, cualquier otro código (incluyendo el código de nivel de kernel) que se ejecute con cualquier nivel de privilegio (incluyendo el privilegio de administrador/raíz) no accede al código seguro dentro del enclave.
La presente invención puede ser especialmente aplicable a un campo de radiocomunicación móvil en el que un terminal móvil, como p. ej., un (teléfono) móvil, como entidad independiente o en cooperación con un dispositivo(s), como p. ej., un Elemento Seguro (o SE), que admite una de las primeras y segundas aplicaciones.
Dentro de la presente descripción, un SE es un objeto inteligente que incluye un chip(s) que protege, como componente(s) a prueba de manipulaciones, el acceso a los datos almacenados y que está destinado a comunicar datos con un dispositivo(s), como p. ej., un dispositivo anfitrión SE, tal como un teléfono (móvil).
La presente invención puede ser especialmente aplicable a dos o más servidores de tipo Módulo de Seguridad de Hardware (o HSM), como servidores que pueden proporcionar una o más claves. Los servidores de tipo HSM están conectados preferiblemente entre sí a través de un mecanismo seguro de intercambio de datos, como p. ej., un mecanismo de cadena de bloques, que permite que un servidor de tipo HSM independiente establezca confianza entre sí.
Estado de la técnica:
Se sabe que se autentica mutuamente entre dos aplicaciones mediante el uso de una tecnología de Infraestructura de Clave Pública (o PKI).
Sin embargo, tal tecnología PKI es muy costosa de implementar, ya que necesita configurar, en la fabricación, un dispositivo que admita cada aplicación mientras proporciona al dispositivo un par de claves, es decir, una clave privada y una clave pública correspondiente.
Además, tal tecnología PKI es muy lenta de operar ya que se debe implementar un proceso pesado que implica una comunicación con una autoridad de certificación para verificar el no repudio del dispositivo.
Finalmente, tal tecnología PKI basada en una criptografía asimétrica se conoce como no resistente a la computación cuántica. Como se conoce per se, la criptografía asimétrica significa que se utiliza una clave pública para el cifrado y una clave privada correspondiente que es distinta de la clave pública se utiliza para el descifrado.
Existe la necesidad de una solución alternativa que sea menos costosa, más rápida y más segura que la solución conocida que utiliza una tecnología PKI. El documento US2010306531 describe la autenticación mutua en la cadena de confianza utilizando un HSM y pruebas de conocimiento cero. El documento US2013179695 describe la autenticación de un dispositivo antes de transmitir contenido digital al dispositivo. Una clave se deriva del ID del dispositivo y la clave maestra y se utiliza como prueba de posesión.
Compendio de la invención:
La invención propone una solución para satisfacer la necesidad especificada anteriormente en la presente memoria al proporcionar un método para la autenticación simétrica mutua entre una primera aplicación y una segunda aplicación. La presente invención se refiere a un método según la reivindicación 1 y un sistema correspondiente según la reivindicación 11. Las realizaciones preferidas se definen en las reivindicaciones dependientes.
Según un aspecto, el método comprende las siguientes etapas. Un primer servidor, como un primer elemento comprendido dentro de una cadena de confianza distribuida, envía y/o recibe de al menos un segundo servidor, como un segundo elemento comprendido dentro de la cadena de confianza distribuida, al menos una clave simétrica maestra. El primer servidor envía a la primera aplicación al menos una clave simétrica maestra. El segundo servidor genera dinámicamente una primera clave simétrica derivada utilizando al menos un parámetro de generación de clave y una primera clave simétrica maestra comprendida dentro de al menos una clave simétrica maestra. El segundo servidor envía a la segunda aplicación la primera clave simétrica derivada y al menos un parámetro de generación de clave. La segunda aplicación genera una primera prueba de posesión de clave utilizando la primera clave simétrica derivada. La segunda aplicación envía a la primera aplicación la primera prueba de posesión de clave y al menos un parámetro de generación de clave. La primera aplicación verifica con éxito utilizando al menos un parámetro de generación de clave, la primera clave simétrica maestra y la primera prueba de posesión de clave, que la primera prueba de posesión de clave se ha generado utilizando la primera clave simétrica derivada. La primera aplicación genera una segunda prueba de posesión de clave utilizando la primera clave simétrica derivada. La primera aplicación envía a la segunda aplicación al menos la segunda prueba de posesión de clave. La segunda aplicación verifica con éxito utilizando la segunda prueba de posesión de clave que la segunda prueba de posesión de clave ha sido generada utilizando la primera clave simétrica derivada, como una clave compartida probada y generada dinámicamente.
El principio consiste en utilizar un primer y un segundo servidores, como p. ej., servidores de tipo HSM, comprendidos dentro de una cadena de confianza (distribuida). El primer servidor proporciona a la primera aplicación una (o más) claves simétricas maestras intercambiadas entre los servidores. El segundo servidor proporciona a la segunda aplicación una primera clave simétrica derivada que el segundo servidor genera sobre la marcha sobre la base de uno o varios parámetros y una primera clave simétrica maestra proporcionada a la primera aplicación por el primer servidor. La segunda aplicación genera con la primera clave simétrica derivada una primera prueba de posesión de clave. La segunda aplicación transmite a la primera aplicación la primera prueba de posesión de clave acompañada con los parámetros utilizados para generar la primera clave simétrica derivada. La primera aplicación verifica si la primera prueba de posesión de clave se ha generado o no con la primera clave simétrica derivada mientras que utiliza la primera clave simétrica maestra, la primera prueba de posesión de clave y los parámetros utilizados para generar la primera clave simétrica derivada. Solo si la primera aplicación verifica que la primera prueba de posesión de clave se ha generado con la primera clave simétrica derivada, la primera aplicación sabe que la segunda aplicación posee la primera clave simétrica derivada que se ha generado dinámicamente. La primera aplicación genera con la primera clave simétrica derivada una segunda prueba de posesión de clave. La primera aplicación envía a la segunda aplicación al menos la segunda prueba de posesión de clave. La segunda aplicación verifica si la segunda prueba de posesión de clave se ha generado o no con la primera clave simétrica derivada mientras que utiliza la primera clave simétrica derivada. Solo si la segunda aplicación verifica que la segunda prueba de posesión de clave se ha generado con la primera clave simétrica derivada, la segunda aplicación sabe que la primera y la segunda aplicaciones comparten ambas la primera clave simétrica derivada que se ha generado dinámicamente.
La solución se basa en una clave simétrica generada dinámicamente, para realizar una autenticación mutua entre la primera y la segunda aplicación utilizando una criptografía simétrica. Como se conoce per se, la criptografía simétrica significa que se utiliza la misma clave tanto para el cifrado como para el descifrado.
Así, contrariamente a la tecnología PKI conocida, la solución no necesita configurar, en la fabricación, un dispositivo que admita cada una de las primeras y segundas aplicaciones al tiempo que proporciona al dispositivo cualquier clave.
La solución es rápida, p. ej., menos de algunas décimas de microsegundos, para operar ya que la solución de la invención se basa en una criptografía simétrica y la clave simétrica utilizada para autenticarse mutuamente entre la primera y la segunda aplicaciones es dinámica, es decir, cuando las dos aplicaciones se utilizan en el campo.
La solución es segura ya que cada una de las primera y segunda aplicaciones asegura, después de una verificación, que la otra de las primera y segunda aplicaciones posee la clave simétrica generada dinámicamente.
La solución es más segura que la solución conocida que utiliza la tecnología PKI, ya que la solución de la invención se basa en una criptografía simétrica que se conoce notablemente por ser más resistente a la computación cuántica. Por lo tanto, la solución mejora mediante la utilización de una criptografía simétrica la seguridad con respecto a la solución basada en PKI conocida.
Cabe señalar que un mecanismo utilizado para intercambiar datos de forma segura, como p. ej., una clave simétrica maestra utilizada para generar la clave simétrica generada dinámicamente, entre el primer y el segundo servidores, como elementos de la cadena de confianza distribuida, puede basarse en cualquier tecnología segura de intercambio de datos, como p. ej., una tecnología de cadena de bloques.
Breve descripción de los dibujos:
Las características y ventajas adicionales de la invención serán evidentes a partir de una descripción detallada de una realización preferida de la invención, dada como un ejemplo indicativo y no limitativo, junto con los siguientes dibujos:
- La Figura 1 ilustra un diagrama simplificado de una realización de un sistema que comprende un primer y un segundo HSM, un servidor en la nube que soporta una primera aplicación y un dispositivo cliente que soporta una segunda aplicación, y que está adaptado para implementar una realización particular de un método para la autenticación simétrica mutua entre la primera y la segunda aplicación basada en una primera clave simétrica derivada que se ha generado dinámicamente, según la invención;
- La Figura 2 representa un flujo de mensajes simplificado entre la primera aplicación y el primer HSM de la figura 1, en el que el primer HSM, como una primera raíz de confianza dentro de la cadena de confianza, proporciona a la primera aplicación una o varias claves simétricas maestras después de haberse autenticado con éxito la primera solicitud y/o verificado con éxito una certificación de la primera aplicación, según la invención;
- La Figura 3 es un flujo de mensajes simplificado entre la segunda aplicación y el segundo HSM de la figura 1, en el que el segundo HSM, como una segunda raíz de confianza dentro de la cadena de confianza, genera dinámicamente la primera clave simétrica derivada basada en una primera clave simétrica maestra compartida entre los HSM y la primera aplicación y proporciona a la segunda aplicación la primera clave simétrica derivada después de haber autenticado satisfactoriamente la segunda aplicación y/o verificado con éxito una certificación de la segunda aplicación, según la invención; y
- La Figura 4 es un flujo de mensajes simplificado entre la primera y la segunda aplicación de la figura 1, en la que cada una de las dos aplicaciones demuestra que la otra de las dos aplicaciones posee la primera clave simétrica derivada que se ha generado previamente sobre la marcha basada en una primera clave simétrica maestra que, por un lado, se comparte de forma segura entre los HSM y, por otro lado, se proporciona a la primera aplicación, según la invención.
Descripción detallada:
En la presente memoria se considera una realización ejemplar en la que el método de la invención para la autenticación simétrica mutua entre una primera y una segunda aplicación es implementado por dos servidores de tipo HSM, como dos servidores, un HME, como la primera aplicación, admitido por un servidor en la nube, como un primer dispositivo, y una aplicación móvil, como la segunda aplicación, admitida por un teléfono móvil, como un segundo dispositivo.
Según otra u otras realizaciones ejemplares (no representadas), el método de la invención para la autenticación simétrica mutua entre una primera y una segunda aplicación es implementado por un servidor de tipo HSM, una primera aplicación admitida por un primer dispositivo y una segunda aplicación admitida por un segundo dispositivo (o el primer dispositivo). En otras palabras, el servidor de tipo HSM no coopera con ningún otro servidor de tipo HSM, es decir, las dos aplicaciones son administradas por un mismo servidor de tipo HSM. Según tal realización o realizaciones ejemplares, el servidor de tipo HSM está adaptado para realizar las funciones que llevan a cabo los dos servidores de tipo HSM y que se describen a continuación.
Naturalmente, la realización que se describe a continuación en la presente memoria es sólo para fines ilustrativos y no se considera que reduzca el alcance de la invención.
La Figura 1 muestra esquemáticamente un sistema 100 que incluye un HME 102, un primer HSM 104, una aplicación móvil 110 y un segundo HSM 108.
Un servidor 101 en la nube está comprendido dentro de una red informática en la nube (no representada).
El servidor 101 en la nube posiblemente en un centro de datos admite una aplicación anfitrión.
El servidor 101 en la nube incluye una o varias CPU (no representadas), como medios de procesamiento de datos, una o varias memorias (no representadas), como medios de almacenamiento de datos, y una o varias interfaces de Entrada/Salida (I/O) (no representadas) que están todas internamente conectadas entre sí.
La memoria del servidor en la nube almacena un Sistema Operativo (o OS).
La aplicación anfitrión aloja el HME 102, como una primera aplicación. La aplicación anfitrión coopera con e1HME 102 que es parte (o subconjunto) de la aplicación anfitrión. El HME 102, cuando se ejecuta, puede realizar una Función Virtual de Red (o NVF).
El HME 102, como p. ej., Intel SGX, ha de ser ejecutado por una CPU de servidor en la nube o un procesador dedicado (o microprocesador) en el servidor 101 en la nube.
El HME 102 está conectado, a través de una o varias entidades de red intermedias (no representadas), sobre un enlace 103 preferiblemente bidireccional, al primer HSM 104.
El primer HSM 104 es operado por un primer proveedor de servicios (o en su nombre).
El primer HSM 104 está conectado, sobre un enlace bidireccional 105, a un mecanismo 106 de cadena de bloques o cualquier otro mecanismo seguro de intercambio de datos.
El primer HSM 104 incluye una o varias CPU (no representadas), como medios de procesamiento de datos, una o varias memorias (no representadas), como medios de almacenamiento de datos, y una o varias interfaces de I/O (no representadas) que están todas conectadas internamente entre sí.
La primera memoria HSM almacena un OS.
El primer HSM 104 es preferiblemente capaz de generar y almacenar una o varias claves simétricas maestras, como un primer conjunto de claves simétricas maestras.
La primera memoria HSM almacena preferiblemente una o varias claves criptográficas que se utilizan para facilitar un mecanismo seguro de alta velocidad que permite demostrar que el HME 102 satisface una o varias condiciones o restricciones de seguridad predeterminadas, para proporcionar de forma segura y fiable a1HME 102 el primer conjunto de llaves maestras simétricas.
El primer HSM 104 es capaz de proporcionar al HME 102 una o varias claves simétricas maestras, preferiblemente solo si existe una restricción o restricciones de seguridad predeterminadas (como p. ej., una o varias finalizaciones con éxito de la verificación de una certificación, una autenticación de la primera aplicación y/o se satisface una autenticación de la primera aplicación, como se describe a continuación) relacionada con el destinatario de la clave o claves simétricas maestras. Cuando se proporcionan dos o más claves simétricas maestras, el primer HSM 104 envía las claves simétricas maestras en asociación con su Identificador Único Universal (o UUID) respectivo o similar, como datos relacionados con un identificador único relacionado con cada clave simétrica maestra que es incluido dentro de un conjunto de claves simétricas maestras en asociación con cada clave simétrica maestra. Un teléfono (móvil) 111 (o el servidor 101 en la nube u otro servidor en la nube en otra realización del método de la invención) admite la aplicación móvil 110, como una segunda aplicación.
La aplicación móvil 110 está conectada, a través de una o varias entidades de red intermedias (no representadas), sobre un enlace 109 preferiblemente bidireccional, al segundo HSM 108.
El segundo HSM 108 es operado preferiblemente por un segundo proveedor de servicios (o un proveedor de infraestructura) (o en su nombre) que es distinto del primer proveedor de servicios.
Los diferentes proveedores de servicios no se conocen entre sí.
Alternativamente, en lugar de dos proveedores de servicios diferentes, el primer 104 y el segundo 108 HSM son operados por un mismo proveedor de servicios.
Cada proveedor de servicios tiene sus propios HSM con sus propia(s) clave o claves maestras simétricas respectivas.
El segundo HSM 108 está conectado, sobre un enlace bidireccional 107, al mecanismo 106 de cadena de bloques (o cualquier otro mecanismo seguro de intercambio de datos).
El segundo HSM 108 incluye una o varias CPU (no representadas), como medios de procesamiento de datos, una o varias memorias (no representadas), como medios de almacenamiento de datos, y una o varias interfaces de I/O (no representadas) que están todas conectadas entre sí.
La segunda memoria HSM almacena un OS.
El segundo HSM 108 es preferiblemente capaz de generar y almacenar una o varias claves simétricas maestras, como un segundo conjunto de claves simétricas maestras. El segundo conjunto de claves simétricas maestras es distinto del primer conjunto de claves simétricas maestras.
La segunda memoria HSM almacena preferiblemente una o varias claves criptográficas que se utilizan para facilitar un mecanismo seguro de alta velocidad que permite demostrar que la aplicación móvil 110 satisface una o varias restricciones de seguridad predeterminadas, para proporcionar de forma segura y fiable a la aplicación móvil 110 la primera clave simétrica derivada.
Según una característica esencial de la invención, el segundo HSM 108 está configurado para generar dinámicamente un primer simétrico derivado utilizando p. ej. un nonce (valor de seguridad), como un aleatorio que el segundo HSM 108 ha generado previamente y que se utiliza solo una vez, como un parámetro de generación de claves, y una primera clave simétrica maestra.
Para aumentar la dificultad (y por lo tanto para mejorar la seguridad) para generar dinámicamente una primera clave simétrica derivada, un(otros) parámetro(s) de generación de claves, como p. ej., datos relacionados con un identificador único relacionado con una Función de Derivación de Clave predeterminada (o KDF) para ser utilizado por el segundo HSM 108 y el HME 102, pueden añadirse.
La primera clave simétrica maestra se incluye dentro del primer o segundo conjunto de claves simétricas maestras. La primera clave simétrica maestra puede haber sido generada previamente por el segundo HSM 108 o el primer HSM 104.
La primera clave simétrica maestra se intercambia de forma segura entre el primer 104 y el segundo 108 HSM sobre el mecanismo 106 de cadena de bloques (o cualquier otro mecanismo seguro de intercambio de datos).
El mecanismo 106 de cadena de bloques o cualquier otro mecanismo seguro de intercambio de datos permite intercambiar datos de forma segura, como p. ej., una clave o claves simétricas maestras posiblemente acompañada de un UUID asociado correspondiente (u otros datos relacionados con un identificador único relacionado con cada clave simétrica maestra), entre los primeros 104 y los segundos 108 HSM (entre otros).
El mecanismo 106 de cadena de bloques o cualquier otro mecanismo seguro de intercambio de datos permite que el primer HSM 104 relacionado con el primer proveedor de servicios establezca confianza con el segundo HSM 108 relacionado con el segundo proveedor de servicios. Por tanto, el primer HSM 104 y el segundo HSM 108 intercambian de forma segura uno o varios conjuntos de claves simétricas maestras y posiblemente (una) otra(s) clave(s). La otra u otras claves se utilizan preferiblemente para facilitar y, por lo tanto, acelerar un mecanismo para permitir que el HME 102 y/o la aplicación móvil 110 satisfagan una o varias restricciones de seguridad predeterminadas, de modo que se les proporcione una clave o claves simétricas maestras que incluyen la primera clave simétrica maestra (para el HME 102) por el primer HSM 104 y/o la primera clave simétrica derivada (para la aplicación móvil 110) por el segundo HSM 108.
El mecanismo 106 de cadena de bloques o cualquier otro mecanismo seguro de intercambio de datos permite que cada HSM 104 o 108 se conecte de forma segura a otro HSM 108 o 104 e intercambie datos, como p. ej., cada otro conjunto de claves simétricas maestras, de tal manera que, en cualquier momento dado, cada HSM 104 o 108 almacena el conjunto de claves simétricas maestras de todos los diferentes HSM 108 o 104 a lo largo de la cadena de confianza distribuida.
El segundo HSM 108 establece, a través del mecanismo 106 de cadena de bloques (o cualquier otro mecanismo seguro de intercambio de datos), confianza con el primer HSM 104 y viceversa, es decir, el primer HSM 104 establece, a través del mecanismo 106 de cadena de bloques (o cualquier otro mecanismo seguro de intercambio de datos), confianza con el segundo HSM 108.
El primer HSM 104 constituye un primer elemento comprendido dentro de una cadena de confianza distribuida. El segundo HSM 108 constituye un segundo elemento que es distinto del primer elemento y está comprendido dentro de la cadena de confianza distribuida.
Cada uno del primer HSM 104 y el segundo HSM 108 puede obtener de forma segura cualquier conjunto de claves simétricas maestras generadas por el otro del primer HSM 104 y el segundo HSM 108.
Según una característica esencial de la invención, el segundo HSM 108 está configurado para proporcionar a la aplicación móvil 110 la primera clave simétrica derivada, como clave simétrica generada dinámicamente, el parámetro o parámetros de generación de claves que se han utilizado para generar la primera clave simétrica derivada, y preferiblemente (aunque no sea obligatorio) datos relacionados con un identificador único relacionado con la primera clave simétrica maestra (que han sido utilizados para generar la primera clave simétrica derivada). El teléfono 111 incluye una o varias CPU (no representadas), como medios de procesamiento de datos, una o varias memorias (no representadas), como medios de almacenamiento de datos, y una o varias interfaces de I/O (no representadas) que están todas internamente conectadas entre sí. La memoria del teléfono almacena un OS.
La aplicación móvil 110 debe ser ejecutada por una CPU de teléfono o un procesador dedicado (o microprocesador, como p. ej., el de un SE) en el teléfono 111.
La aplicación móvil 110 puede estar soportada por un chip SE (no representado).
La invención no impone ninguna restricción en cuanto a un tipo de SE, cuando está presente.
El SE puede ser un chip incorporado, como p. ej., una Tarjeta de Circuito Integrado Universal integrada (o eUICC) o una Tarjeta de Circuito Integrado Universal integrada (o iUICC), dentro de un terminal, como un dispositivo anfitrión SE, o un chip que está acoplado al terminal, como un dispositivo anfitrión SE, e incluido dentro de una tarjeta inteligente (u otro medio). Por lo tanto, el chip puede ser fijado o extraído de su dispositivo anfitrión, como p. ej., un teléfono móvil.
La invención no impone ninguna restricción en cuanto a una clase del tipo SE.
El SE puede tener diferentes factores de forma.
Como SE extraíble, puede ser una tarjeta tipo Módulo de Identidad de Suscriptor (o SIM), un Módulo Extraíble Seguro (o SRM), un dongle (mochila) inteligente del tipo USB (acrónimo de "Bus Universal en Serie"), una tarjeta (micro-) de tipo Digital Segura (o SD) o una Tarjeta de tipo Multimedia (o MMC) o cualquier tarjeta de formato para acoplar a un dispositivo anfitrión, como dispositivo para autenticar a un usuario.
El chip o los chips SE puede incorporar al menos parte del componente o componentes del teléfono, como p. ej., un procesador de banda base, un procesador o procesadores de aplicación y/u otro u otros componentes electrónicos. Alternativamente, el o los chips SE incluyen un Entorno de Ejecución Fiable (o TEE), como un área segura de un procesador de teléfono (o terminal) y un entorno de tiempo de ejecución seguro.
El o los chips SE están preferiblemente incorporados, posiblemente de una manera extraíble, dentro de una Placa de Circuito Impreso (o PCB) del teléfono 111, como un dispositivo anfitrión SE.
Según una característica esencial de la invención, la aplicación móvil 110 está adaptada para generar, utilizando la primera clave simétrica derivada, p. ej. un primer nonce cifrado y/o una función hash cifrada del primer nonce o similar, como primera prueba de posesión de clave.
Para generar la primera prueba de posesión de clave, la aplicación móvil 110 utiliza un primer algoritmo de cifrado predeterminado, como p. ej., un Estándar de Cifrado Avanzado (o AES), un Estándar de Cifrado de Datos (o DES) o un 3DES, con la primera clave simétrica derivada. Como se conoce per se, un primer algoritmo de descifrado correspondiente es el primer algoritmo de cifrado.
La aplicación móvil 110 puede enviar, sobre un enlace bidireccional 113, a1HME 102 la primera prueba de posesión de clave junto con el o los parámetros de generación de claves que se han utilizado para generar la primera clave simétrica derivada. La aplicación 110 móvil preferiblemente puede enviar, además de la primera prueba de posesión de clave y el parámetro o parámetros de generación de clave, datos relacionados con un identificador único relacionado con la primera clave simétrica maestra.
La aplicación móvil 110 puede recibir, sobre el enlace bidireccional 113, desde e1HME 102 una segunda prueba de posesión de clave posiblemente junto con otros datos.
Según una característica esencial de la invención, la aplicación móvil 110 está adaptada para verificar, utilizando la segunda prueba de posesión de clave (recibida), si la segunda prueba de posesión de clave se ha generado o no utilizando la primera clave simétrica derivada.
Para llevar a cabo dicha verificación mientras se utilizan los datos recibidos, la aplicación móvil 110, p. ej., descifra, p. ej., la función hash cifrada (recibida) del segundo nonce utilizando un segundo algoritmo de descifrado predeterminado (que es preferiblemente el segundo algoritmo de cifrado utilizado por e1HME 102) y la primera clave simétrica derivada, para obtener la función hash del segundo nonce, como una segunda referencia para emparejar. La aplicación móvil 110, p. ej., descifra, p. ej., el segundo nonce cifrado (recibido) utilizando un segundo algoritmo de descifrado predeterminado (que es preferiblemente el segundo algoritmo de cifrado utilizado por e1HME 102) y la primera clave simétrica derivada. Entonces, la aplicación móvil 110, por ejemplo genera una función hash del segundo nonce y compara la función hash del segundo nonce con la segunda referencia. Si la función hash del segundo nonce no coincide con la segunda referencia, la verificación falla. De lo contrario, es decir, si la función hash del segundo nonce coincide con la segunda referencia, la verificación se realiza correctamente.
En caso de fallo de verificación, si la segunda prueba de posesión de clave no se ha generado utilizando la primera clave simétrica derivada, entonces la aplicación móvil 110 no puede autenticar o probar que e1HME 102 posee la primera clave simétrica derivada. En tal caso de fallo de verificación, la aplicación móvil 110 no puede confiar en el HME 102.
De lo contrario, es decir, en caso de verificación exitosa, si la segunda prueba de posesión de clave se ha generado utilizando la primera clave simétrica derivada, entonces la aplicación móvil 110 autentica (o prueba) con éxito que el HME 102 posee la primera clave simétrica derivada. En tal caso de verificación exitosa, la aplicación móvil 110 puede confiar en el HME 102.
La aplicación móvil 110 puede enviar, sobre un enlace bidireccional 113, a1HME 102 la primera prueba de posesión de clave junto con el parámetro o parámetros de generación de clave que se han utilizado para generar la primera clave simétrica derivada. La aplicación móvil 110 preferiblemente puede enviar, además de la primera prueba de posesión de clave y el parámetro o parámetros de generación de clave, datos relacionados con un identificador único relacionado con la primera clave simétrica maestra.
De acuerdo con una característica esencial de la invención, el HME 102 está adaptado para verificar, utilizando la primera prueba de posesión de clave (recibida), el parámetro o parámetros de generación de clave (recibidos) y la primera clave simétrica maestra que es preferiblemente (pero no obligatoria) identificada por los datos recibidos, si la primera prueba de posesión de clave se ha generado o no utilizando la primera clave simétrica derivada.
Para llevar a cabo tal verificación mientras se utilizan los datos recibidos, e1HME 102 identifica la primera clave simétrica maestra utilizando los datos recibidos y, p. ej., descifra, p. ej. la función hash cifrada (recibida) del primer nonce utilizando un primer algoritmo de descifrado predeterminado (que es el primer algoritmo de cifrado utilizado por la aplicación móvil 110) y la primera clave simétrica derivada, para obtener la función hash del primer nonce, como una primera referencia a emparejar. El HME 102 identifica la primera clave simétrica maestra utilizando los datos recibidos y, p. ej., descifra, p. ej. el primer nonce cifrado (recibido) utilizando un primer algoritmo de descifrado predeterminado (que es el primer algoritmo de cifrado utilizado por la aplicación móvil 110) y la primera clave simétrica derivada. Entonces, el HME 102, p. ej., genera una función hash del primer nonce y compara la función hash del primer nonce con la primera referencia. Si la función hash del primer nonce no coincide con la primera referencia, entonces la verificación falla. De lo contrario, es decir, si la función hash del primer nonce coincide con la primera referencia, la verificación se realiza correctamente.
Como resultado de la verificación, si la primera prueba de posesión de clave no se ha generado utilizando la primera clave simétrica derivada, entonces el HME 102 no puede autenticar o probar que la aplicación móvil 110 posee la primera clave simétrica derivada. En tal caso de fallo, el HME 102 no puede confiar en la aplicación móvil 110. De lo contrario, es decir, como resultado de la verificación, si la primera prueba de posesión de clave se ha generado utilizando la primera clave simétrica derivada, el HME 102 autentica (o prueba) con éxito que la aplicación móvil 110 posee la primera clave simétrica derivada. En tal caso de éxito, e1HME 102 puede confiar en la aplicación móvil 110.
Según una característica esencial de la invención, el HME 102 está adaptado para generar, utilizando la primera clave simétrica derivada, p. ej. un segundo nonce cifrado y/o una función hash cifrada del segundo nonce o similar, como una segunda prueba de posesión de clave.
Para generar la segunda prueba de posesión de clave, la aplicación móvil 110 utiliza un segundo algoritmo de cifrado predeterminado, como p. ej., un AES, un DES o un 3DES, con la primera clave simétrica derivada. Como se conoce per se, un segundo algoritmo de descifrado correspondiente es el segundo algoritmo de cifrado.
El segundo algoritmo de cifrado puede ser distinto del primer algoritmo de cifrado o idéntico al primer algoritmo de cifrado.
Si falla al menos una autenticación de la primera prueba de posesión de clave y/o la segunda prueba de posesión de clave, entonces la primera y la segunda aplicación no se autentican mutuamente.
Por el contrario, si una autenticación de la primera prueba de posesión de clave y una autenticación de la segunda prueba de posesión de clave se realizan correctamente, entonces la primera y la segunda aplicación se autentican mutuamente (con éxito).
Como se muestra en la Figura 2, el primer HSM 104 proporciona, preferiblemente de forma segura, es decir, después de haber verificado que el HME 102 satisface una o varias restricciones de seguridad predeterminadas, el HME 102 con una o varias claves simétricas maestras, como un primer conjunto de claves simétricas maestras. Tal verificación segura de que el HME 102 satisface una o varias restricciones de seguridad predeterminadas permite establecer una confianza previa entre el HME 102 y el primer HSM 104. E1HME 102 está así anclado al primer HSM 104, de tal manera que existe un fuerte vínculo de confianza entre e1HME 102 y el primer HSM 104. El servidor 101 en la nube (más exactamente la aplicación anfitrión) lanza una ejecución de1HME 102 enviando al HME 102 una solicitud 22 de lanzamiento correspondiente.
El HME 102 se ejecuta mientras se lleva a cabo uno o varios procesos de seguridad predeterminados, como p. ej., un proceso de certificación de la aplicación, un proceso de autenticación de la aplicación y/o un proceso de autenticación del usuario, utilizando una o varias claves.
Los procesos de seguridad predeterminados pueden incluir un proceso de certificación de la aplicación utilizando p. ej., una clave asimétrica predeterminada almacenada de forma segura por e1HME 102 y un algoritmo de certificación predeterminado, tal como un algoritmo de Código de Autenticación de Mensajes (o MAC).
Los procesos de seguridad predeterminados pueden incluir un proceso de autenticación de código (o aplicación) utilizando, p. ej., una clave de autenticación predeterminada almacenada de forma segura por e1HME 102 y un algoritmo de autenticación predeterminado.
Los procesos de seguridad predeterminados pueden incluir un proceso de autenticación de usuario utilizando p. ej., una clave de autenticación de usuario predeterminada almacenada de forma segura por e1HME 102 y un algoritmo de autenticación de usuario predeterminado.
El HME 102 envía al primer HSM 104 uno o varios mensajes 24 que incluyen un informe de certificación, datos de autenticación de código y/o datos de autenticación de usuario, como datos enviados.
El primer HSM 104 verifica 26 si los datos enviados (recibidos) coinciden o no con el resultado o resultados esperados (o predeterminados) del proceso de seguridad, como p. ej., un resultado esperado del proceso de certificación de la aplicación, un resultado esperado del proceso de autenticación de la aplicación y/o un resultado esperado del proceso de autenticación del usuario.
Si los datos enviados no coinciden con el resultado o resultados esperados del proceso de seguridad, entonces el primer HSM 104 no verifica el proceso o procesos de seguridad que debe cumplir e1HME 102. El primer HSM 104 puede enviar un mensaje (no representado) al HME 102 incluyendo un código de error o un código de fallo. Tal código de error o código de fallo permite informar al HME 102 que el HME 102 no satisface los procesos de seguridad requeridos.
De lo contrario, es decir, solo si los datos enviados coinciden con el resultado o resultados esperados del proceso de seguridad, el primer HSM 104 verifica con éxito el proceso o los procesos de seguridad que se deben cumplir, como p. ej., verifica con éxito la certificación del HME 102, autentica con éxito e1HME 102 y/o autentica con éxito a un usuario de HME 102.
Una vez verificado con éxito, el primer HSM 104, como primera raíz de confianza dentro de la cadena de confianza distribuida, envía al HME 102 uno o varios mensajes 28 que incluyen el primer conjunto de claves simétricas maestras (y/o el segundo conjunto de claves simétricas maestras), como una prueba o pruebas de seguridad, como p. ej., una prueba de autenticidad e integridad del HME 102, una prueba de un HME 102 autenticado y/o una prueba de un usuario HME autenticado. El primer HSM 104 establece así confianza con e1HME 102.
Una vez que el HME 102 ha recibido, como una prueba o pruebas de seguridad, el primer conjunto de claves simétricas maestras (y/o el segundo conjunto de claves simétricas maestras), e1HME 102 puede establecer autenticación mutua (y por lo tanto confianza) con la aplicación móvil 110 (y/o cualquier otra aplicación móvil) gestionada por el segundo HSM 108.
Como se muestra en la Figura 3, el segundo HSM 108 proporciona, preferiblemente de forma segura, es decir, después de haber verificado que la aplicación móvil 110 satisface una o varias restricciones de seguridad predeterminadas, la aplicación móvil 110 con la primera clave simétrica derivada.
Tal verificación segura de que una o varias restricciones de seguridad predeterminadas son satisfechas por la aplicación móvil 110 permite establecer una confianza previa entre la aplicación móvil 110 y el segundo HSM 108. La aplicación móvil 110 está así anclada al segundo HSM 108, de tal manera que existe un vínculo de confianza entre la aplicación móvil 110 y el segundo HSM 108.
El teléfono 111 (más exactamente la aplicación anfitrión) lanza una ejecución de la aplicación móvil 110 enviando a la aplicación móvil 110 una solicitud 32 de lanzamiento correspondiente.
La aplicación móvil 110 se ejecuta mientras se lleva a cabo uno o varios procesos de seguridad predeterminados, como p. ej., un proceso de certificación de la aplicación, un proceso de autenticación de la aplicación y/o un proceso de autenticación de usuario, utilizando una o varias claves.
Los procesos de seguridad predeterminados pueden incluir un proceso de certificación de la aplicación utilizando p. ej., una clave asimétrica predeterminada almacenada de forma segura por la aplicación móvil 110 y un algoritmo de certificación predeterminado, tal como un algoritmo MAC.
Los procesos de seguridad predeterminados pueden incluir un proceso de autenticación de código (o aplicación) utilizando p. ej., una clave de autenticación predeterminada almacenada de forma segura por la aplicación móvil 110 y un algoritmo de autenticación predeterminado.
Los procesos de seguridad predeterminados pueden incluir un proceso de autenticación de usuario utilizando p. ej., una clave de autenticación de usuario predeterminada almacenada de forma segura por la aplicación móvil 110 y un algoritmo de autenticación de usuario predeterminado.
La aplicación móvil 110 envía al segundo HSM 108 uno o varios mensajes 34 que incluyen un informe de certificación, datos de autenticación de código y/o datos de autenticación de usuario, como datos enviados.
El segundo HSM 108 verifica 34 si los datos enviados (recibidos) coinciden o no con el resultado o resultados esperados (o predeterminados) del proceso de seguridad, como p. ej., un resultado esperado del proceso de certificación de la aplicación, un resultado esperado del proceso de autenticación de la aplicación y/o un resultado esperado del proceso de autenticación del usuario.
Si los datos enviados no coinciden con el resultado o resultados esperados del proceso de seguridad, entonces el segundo HSM 108 no verifica el proceso o procesos de seguridad que debe satisfacer la aplicación móvil 110. El segundo HSM 108 puede enviarse a la aplicación móvil 110 un mensaje 36 que incluye un código de error o un código de fallo. Tal código de error o código de fallo permite informar a la aplicación móvil 110 que la aplicación móvil 110 no satisface el proceso o procesos de seguridad requeridos.
De lo contrario, es decir, solo si los datos enviados coinciden con el resultado o resultados esperados del proceso de seguridad, el segundo HSM 108 verifica con éxito el proceso o procesos de seguridad que han de ser satisfechos, como p. ej., verifica con éxito la certificación de la aplicación móvil 110, autentica con éxito la aplicación móvil 110 y/o autentica con éxito un usuario de la aplicación móvil 110.
Una vez que la aplicación móvil 110 satisface (con éxito) el proceso o procesos de seguridad requeridos, el segundo HSM 108 genera 38 dinámicamente una primera clave simétrica derivada (que es única) utilizando p. ej., un nonce que es preferiblemente grande, es decir, más de 256 bits, como un parámetro o parámetros de generación de clave utilizados para generar la primera clave simétrica derivada, y una primera clave simétrica maestra que se selecciona preferiblemente del segundo (o primer) conjunto de claves simétricas maestras(cuando este último incluye dos o más claves simétricas maestras).
Una vez que se genera la primera clave simétrica derivada, el segundo HSM 108, como una segunda raíz de confianza dentro de la cadena de confianza distribuida, envía a la aplicación móvil 110 uno o varios mensajes 310 que incluyen, como una prueba o pruebas de seguridad, como p. ej., una prueba de autenticidad e integridad de la aplicación móvil 110, una prueba de una aplicación móvil autenticada 110 y/o una prueba de un usuario autenticado de la aplicación móvil 110, la primera clave simétrica derivada, el parámetro o parámetros de generación de claves y posiblemente los datos relacionados con un identificador único relacionado con la primera clave simétrica maestra. El segundo HSM 108 establece así confianza con la aplicación móvil 110.
Una vez que la aplicación móvil 110 ha recibido, como una prueba o pruebas de seguridad, la primera clave simétrica derivada, el parámetro o parámetros de generación de clave y posiblemente los datos relacionados con un identificador único relacionado con la primera clave simétrica maestra, la aplicación móvil 110 puede establecer autenticación mutua (y por lo tanto confianza) con el HME 102 (y/o cualquier otro HME) gestionado por el primer HSM 104.
La Figura 4 representa una realización ejemplar de mensajes 40 intercambiados entre la aplicación móvil 110 y el HME 102.
Se supone que el HME 102 ha recibido, como una prueba o pruebas de seguridad, el segundo conjunto de claves simétricas maestras en asociación con un UUID correspondiente respectivo, como datos relacionados con un identificador único relacionado con cada clave simétrica maestra (incluida en el segundo conjunto de claves simétricas maestras).
Se supone además que la aplicación móvil 110 ha recibido, como una prueba o pruebas de seguridad, la primera clave simétrica derivada, el parámetro o parámetros de generación de clave y el UUIDx de la primera clave simétrica maestra, como datos relacionados con un identificador único relacionado con la primera clave simétrica maestra. Se supone además que la primera clave simétrica derivada se ha generado utilizando, p. ej., un nonce grande, como un parámetro de generación de claves único.
Se supone además que la primera clave simétrica maestra está incluida dentro del segundo conjunto de claves simétricas maestras que ha sido previamente generado por el segundo HSM 108 y transmitido o propagado al primer HSM 104.
En primer lugar, la aplicación móvil 110 genera 42 una primera prueba de posesión de clave utilizando la primera clave simétrica derivada.
Para generar la primera prueba de posesión de clave, la aplicación móvil 110 puede generar un primer nonce y luego cifrar el primer nonce utilizando la primera clave simétrica derivada. La aplicación móvil 110 puede generar además preferiblemente una función hash del primer nonce y luego cifrar la función hash del primer nonce utilizando la primera clave simétrica derivada. La función hash cifrada del primer nonce permite que e1HME 102 genere una primera referencia para hacer coincidir durante una verificación de la primera prueba de posesión de clave.
Una vez que se genera la primera prueba de posesión de clave, la aplicación móvil 110 envía a1HME 102 uno o varios mensajes 44 incluyendo el primer nonce cifrado, como la primera prueba de posesión de clave, preferiblemente la función hash cifrada del primer nonce, el UUIDx de la primera clave simétrica maestra y el nonce grande, como el parámetro de generación de claves que se ha utilizado para generar la primera clave simétrica derivada.
Una vez que el HME 102 recibe el mensaje 44, el HME 102 identifica 46, basándose en el UUIDx de la primera clave simétrica maestra, la primera clave simétrica maestra que se ha utilizado para generar la primera clave simétrica derivada.
Una vez que se identifica la primera clave simétrica maestra, el HME 102 genera 48 la primera clave simétrica derivada utilizando la primera clave simétrica maestra y el nonce grande, como el parámetro de generación de claves. El HME 102 utiliza el algoritmo de generación de claves predeterminado que es utilizado por el segundo HSM 108 para generar la primera clave simétrica derivada.
Una vez que se genera la primera clave simétrica derivada, el HME 102 verifica 410 utilizando el parámetro de generación de claves, la primera clave simétrica maestra (identificada) y la primera prueba de posesión de clave, si la primera prueba de posesión de clave se ha generado o no utilizando la primera clave simétrica derivada.
Para realizar tal verificación 410, el HME 102 descifra, p. ej., el primer nonce cifrado utilizando la primera clave simétrica derivada, para obtener el primer nonce en texto sin formato. A continuación, e1HME 102 genera una función hash del primer nonce y compara la función hash (recién generada) del primer nonce con la primera referencia recibida para hacer coincidir.
Si la comparación falla, es decir, la función hash del primer nonce no coincide con la primera referencia recibida para ser emparejada, entonces la primera prueba de posesión de clave no se ha generado utilizando la primera clave simétrica derivada y el HME 102 no puede autenticar la aplicación móvil 110. E1HME 102 puede enviar un mensaje 412 que incluye un código de error o un código de fallo. Tal código de error o código de falla permite informar a la aplicación móvil 110 que el HME 102 no puede autenticar la aplicación móvil 110.
Si la comparación es exitosa, es decir, la función hash del primer nonce coincide con la primera referencia recibida para ser emparejada, entonces la primera prueba de posesión de clave se ha generado utilizando la primera clave simétrica derivada y el HME 102 autentica con éxito la aplicación móvil 110.
Una vez que la aplicación móvil 110 se autentica con éxito, el HME 102 genera 414 una segunda prueba de posesión de clave utilizando la primera clave simétrica derivada.
Para generar la segunda prueba de posesión de clave, el HME 102 puede generar un segundo nonce y luego cifrar el segundo nonce utilizando la primera clave simétrica derivada. El HME 102 puede generar además preferiblemente una función hash del segundo nonce y luego cifrar la función hash del segundo nonce utilizando la primera clave simétrica derivada. La función hash cifrada del segundo nonce permite que la aplicación móvil 110 genere una segunda referencia para hacer coincidir durante una verificación de la segunda prueba de posesión de clave.
Una vez que se genera la segunda prueba de posesión de clave, el HME 102 envía a la aplicación móvil 110 uno o varios mensajes 416 que incluyen el segundo nonce cifrado, como la segunda prueba de posesión de clave, y preferiblemente (pero no obligatoriamente) la función hash cifrada del segundo nonce.
Una vez que se recibe la segunda prueba de posesión de clave, la aplicación móvil 110 verifica 418 utilizando al menos la segunda prueba de posesión de clave, si la segunda prueba de posesión de clave se ha generado o no utilizando la primera clave simétrica derivada.
Para realizar tal verificación 418, la aplicación móvil 110 descifra, p. ej., el segundo nonce cifrado utilizando la primera clave simétrica derivada, para obtener el segundo nonce en texto sin formato. Entonces, la aplicación móvil 110 genera una función hash del segundo nonce y compara la función hash (recién generada) del segundo nonce con la segunda referencia recibida para hacer coincidir.
Si la comparación falla, es decir, la función hash del segundo nonce no coincide con la segunda referencia recibida para ser hecha coincidir, entonces la segunda prueba de posesión de clave no se ha generado utilizando la primera clave simétrica derivada y la aplicación móvil 110 no puede autenticar el HME 102. La aplicación móvil 110 puede enviar un mensaje 420 que incluye un código de error o un código de fallo. Tal código de error o código de fallo permite informar al HME 102 que la aplicación móvil 110 no puede autenticar e1HME 102.
Si la comparación es exitosa, es decir, la función hash del segundo nonce coincide con la segunda referencia recibida para ser hecha coincidir, entonces la segunda prueba de posesión de clave se ha generado utilizando la primera clave simétrica derivada y la aplicación móvil 110 autentica con éxito e1HME 102.
Una vez que la aplicación móvil 110 autentica con éxito el HME 102, la aplicación móvil 110 y e1HME 102 autentican 422 con éxito mutuamente probando mutuamente que el HME 102 y la aplicación móvil 110 poseen cada uno la primera clave simétrica derivada, como una clave compartida así generada y probada dinámicamente.
La red de la cadena de confianza incluye así, además del primer HSM 104 y el segundo HSM 108, e1HME 102 y la aplicación móvil 110, como elementos adicionales de la cadena de confianza.
La primera clave simétrica derivada puede ser válida durante un primer período de vida predeterminado, tal como cada hora o 30 minutos.
El segundo HSM 108 puede generar una segunda clave simétrica derivada que es distinta de la primera clave simétrica derivada cambiando la primera clave simétrica maestra y/o uno o varios parámetros que se han utilizado para generar la primera clave simétrica derivada.
El HME 102 y la aplicación móvil 110 pueden generar (no representado) por separado una clave de sesión basada, p. ej., en el primer nonce y/o el segundo nonce, como datos que pueden haber sido utilizados para generar la primera prueba de posesión de clave y/o la segunda prueba de posesión de clave respectivamente y que son compartidos por el HME 102 y la aplicación móvil 110.
Una vez que el HME 102 y la aplicación móvil 110 comparten la misma clave de sesión basada en datos compartidos, como p. ej., la primera clave simétrica derivada y/o los datos utilizados para demostrar que la otra aplicación posee la primera clave simétrica derivada, el HME 102 y la aplicación móvil 110 pueden realizar transacciones de forma continua y segura (mientras que utilizan la clave de sesión).
La clave de sesión se puede cifrar utilizando una segunda clave simétrica maestra que sea distinta de la primera clave simétrica maestra. La segunda clave simétrica maestra se comparte entre el primer HSM 104 y el segundo HSM 108.
El HME 102 (o la aplicación móvil 110) puede enviar a la aplicación móvil 110 (o a1HME 102 respectivamente) uno o varios mensajes (no representados) que incluyen, como información de clave de sesión, una clave de sesión que está cifrada previamente utilizando una segunda clave simétrica maestra que es distinta de la primera clave simétrica maestra, datos relacionados con un identificador único relacionado con la segunda clave simétrica maestra y/o un período de vida predeterminado durante el cual la clave de sesión es válida. Tal información de clave de sesión se inserta preferiblemente en el encabezado de cada mensaje, ya que el contenido del encabezado no está cifrado, es decir, en texto sin formato.
El primer HSM 104, el segundo HSM 108, un tercer HSM que está comprendido dentro de la cadena de confianza distribuida aunque es distinto del primer 104 y el segundo 108 HSM pueden enviarse a una tercera aplicación, que es distinta del HME 102 y la aplicación móvil 110, el primer conjunto de claves maestras simétricas y/o el segundo conjunto de claves maestras simétricas. Y el HME 102 o la aplicación móvil 110 envía a la tercera aplicación la información de la clave de sesión, para intercambiarla de forma segura con la tercera aplicación mientras que utiliza la misma clave de sesión. Tal transmisión de información de clave de sesión permite propagar la información de clave de sesión a la tercera aplicación. Tal transmisión de información clave de sesión permite asegurar la portabilidad de la comunicación desde la primera o segunda aplicación a la tercera aplicación, en particular en el contexto de un balanceo de carga útil o un balanceo de carga útil virtual. La comunicación con la tercera aplicación estará asegurada mientras que utiliza la información de la clave de sesión en cada intercambio de datos. La tercera aplicación utilizará entonces la información de la clave de sesión para descifrar los datos que recibirá la tercera aplicación y para cifrar los datos que se enviarán desde la tercera aplicación.
Cualquier proveedor de servicios, cualquier usuario final y/o cualquier aplicación que utilice una o varias de las claves simétricas maestras administradas dentro de la cadena de confianza de HSM, como p. ej., la primera clave simétrica maestra, puede confiar en que la clave o claves simétricas maestras en cuestión no pueden ser comprometidas, ni siquiera por los propios proveedores de servicios involucrados.
La solución de la invención permite ofrecer preferiblemente una confidencialidad e integridad de alta seguridad del código/datos seguros (como p. ej., el HME).
La solución de la invención permite ofrecer preferiblemente un mecanismo de certificación de alta velocidad que utiliza claves simétricas. Tal mecanismo de certificación de alta velocidad permite que dos puntos finales, al menos uno de los cuales termina dentro de un HME (o similar), como código/datos seguros, establezcan rápidamente la confianza entre sí utilizando criptografía simétrica de alta velocidad.
La solución de la invención permite ofrecer un aislamiento de alta seguridad de un código/datos seguros (como, p. ej., el HME) frente a un código menos seguro (o inseguro) (como, p. ej., la aplicación móvil). Tal aislamiento permite que el código sensible y la información sensible se alojen dentro de una carga útil virtual mientras se mantiene a salvo de los ataques de canal lateral y los ataques de personas internas malintencionadas, tales como los administradores de la nube.
La solución de la invención permite ofrecer una forma para que los proveedores de servicios independientes establezcan confianza entre sí, de tal manera que una aplicación o aplicaciones y posiblemente una carga útil o cargas útiles seguras se ejecuten en un sistema (con un servidor o servidores de tipo HSM) operado por un proveedor de servicios puede establecer confianza (es decir, certificación) con otra u otras aplicaciones y otra u otras cargas seguras que se ejecutan en otro sistema (con otro u otros servidores de tipo HSM) operado por otro proveedor de servicios. La solución de la invención permite que la confianza se extienda a través de un sistema ampliamente distribuido al tiempo que implica un código seguro (como p. ej., un HME) y una red de servidor de tipo HSM.
La solución de la invención permite ofrecer repudios de dos caras, es decir, la primera aplicación sabe que la segunda aplicación es la auténtica y viceversa.
La solución de la invención no necesita ninguna medición, es decir, ninguna firma basada en una tecnología PKI.
La solución de la invención es simple y segura ya que se basa en un cifrado simétrico que utiliza una clave derivada dinámicamente.
La solución de la invención es rápida ya que se basa en una criptografía simétrica.

Claims (11)

REIVINDICACIONES
1. Un método (40) para la autenticación simétrica mutua entre una primera aplicación (102) y una segunda aplicación (110),
el método comprende:
- enviar y/o recibir, mediante un primer servidor (104), como un primer elemento comprendido dentro de una cadena de confianza distribuida, hacia y/o desde al menos un segundo servidor (108), como un segundo elemento comprendido dentro de la cadena de confianza distribuida, al menos una clave simétrica maestra;
- enviar (28), mediante el primer servidor, a la primera aplicación, al menos una clave simétrica maestra;
- generar (38) dinámicamente, mediante el segundo servidor, una primera clave simétrica derivada utilizando al menos un parámetro de generación de clave y una primera clave simétrica maestra comprendida dentro de al menos una clave simétrica maestra;
- enviar (310), mediante el segundo servidor, a la segunda aplicación, la primera clave simétrica derivada y al menos un parámetro de generación de clave el método caracterizado además por
- generar (42), mediante la segunda aplicación, una primera prueba de posesión de clave utilizando la primera clave simétrica derivada;
- enviar (44), mediante la segunda aplicación, a la primera aplicación, la primera prueba de posesión de clave y al menos un parámetro de generación de clave;
- verificar (410) con éxito, mediante la primera aplicación, utilizando al menos un parámetro de generación de clave, la primera clave simétrica maestra y la primera prueba de posesión de clave, que la primera prueba de posesión de clave se ha generado utilizando la primera clave simétrica derivada;
- generar (414), mediante la primera aplicación, una segunda prueba de posesión de clave utilizando la primera clave simétrica derivada;
- enviar (416), mediante la primera aplicación, a la segunda solicitud, al menos la segunda prueba de posesión de clave; y
- verificar (418) con éxito, mediante la segunda aplicación, utilizando la segunda prueba de posesión de clave que la segunda prueba de posesión de clave ha sido generada utilizando la primera clave simétrica derivada, como una clave compartida generada dinámicamente y probada.
2. Método según la reivindicación 1, en el que, antes de enviar a la primera aplicación al menos una clave simétrica maestra, el primer servidor, como primera raíz de confianza dentro de la cadena de confianza distribuida, verifica (26) con éxito la certificación de la primera aplicación y/o autentica con éxito la primera aplicación, al menos una clave simétrica maestra así proporcionada se convierte en una prueba de autenticidad e integridad de la primera solicitud y/o una prueba de una primera aplicación autenticada; y/o
antes de enviar a la segunda aplicación la primera clave simétrica derivada, el segundo servidor, como segunda raíz de confianza dentro de la cadena de confianza distribuida, verifica (34) con éxito la certificación de la segunda aplicación y/o autentica con éxito la segunda aplicación, la primera clave simétrica derivada así proporcionada que se convierte en una prueba de autenticidad e integridad de la segunda aplicación y/o una prueba de una segunda aplicación autenticada.
3. Método según la reivindicación 1 o 2, en el que, el primer servidor envía y/o recibe al menos una clave simétrica maestra, el primer servidor envía y/o recibe además datos relacionados con un identificador único relacionado con cada uno de al menos una clave simétrica maestra, y la segunda aplicación recibe y envía al menos un parámetro de generación de clave, la segunda aplicación recibe y envía además datos relacionados con un identificador único relacionado con la primera clave simétrica maestra.
4. Método según cualquier reivindicación anterior, en el que la primera clave simétrica derivada es válida durante un primer período de vida predeterminado.
5. Método según cualquier reivindicación anterior, en el que el segundo servidor genera una segunda clave simétrica derivada que es distinta de la primera clave simétrica derivada cambiando al menos un parámetro de generación de clave comprendido dentro de al menos un parámetro de generación de clave y/o la primera clave simétrica maestra.
6. Método según cualquier reivindicación anterior, en el que la primera prueba de posesión de clave incluye un primer nonce cifrado y/o una función hash cifrada del primer nonce.
7. Método según cualquier reivindicación anterior, en el que la segunda prueba de posesión de clave incluye un segundo nonce cifrado y/o una función hash cifrada del segundo nonce.
8. Método según cualquier reivindicación anterior, en el que la primera aplicación y la segunda aplicación generan por separado una clave de sesión basada en la primera prueba de posesión de clave y/o la segunda prueba de posesión de clave.
9. Método según cualquier reivindicación anterior, en el que la primera aplicación envía a la segunda aplicación, como información de clave de sesión, al menos un elemento de un grupo que comprende:
- una clave de sesión que se cifra previamente utilizando una segunda clave simétrica maestra que es distinta de la primera clave simétrica maestra;
- datos relacionados con un identificador único relacionado con la segunda clave simétrica maestra;
- un período de vida predeterminado durante el cual la clave de sesión es válida.
10. Método según cualquier reivindicación anterior, en el que el método comprende además:
- el primer servidor, el segundo servidor o un tercer servidor envía a una tercera aplicación al menos una clave simétrica maestra, siendo el tercer servidor, como un tercer elemento comprendido dentro de la cadena de confianza distribuida, distinto del primer servidor y del segundo servidor, siendo la tercera aplicación distinta de la primera aplicación y la segunda aplicación; y
- la primera aplicación o la segunda aplicación envía a la tercera aplicación, la información de clave de sesión recibida, para intercambiarla de forma segura con la tercera aplicación mientras se usa la clave de sesión.
11. Un sistema para la autenticación simétrica mutua entre una primera aplicación y una segunda aplicación, comprendiendo el sistema un primer servidor, un segundo servidor, la primera aplicación y la segunda aplicación, en el que el sistema está adaptado para realizar las etapas del método de cualquiera de las reivindicaciones 1 a 10.
ES18713997T 2017-06-14 2018-04-04 Método para la autenticación simétrica mutua entre una primera aplicación y una segunda aplicación Active ES2880012T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP17305728 2017-06-14
PCT/EP2018/058641 WO2018228732A1 (en) 2017-06-14 2018-04-04 Method for mutual symmetric authentication between a first application and a second application

Publications (1)

Publication Number Publication Date
ES2880012T3 true ES2880012T3 (es) 2021-11-23

Family

ID=59579551

Family Applications (1)

Application Number Title Priority Date Filing Date
ES18713997T Active ES2880012T3 (es) 2017-06-14 2018-04-04 Método para la autenticación simétrica mutua entre una primera aplicación y una segunda aplicación

Country Status (7)

Country Link
US (1) US11196722B2 (es)
EP (1) EP3613169B1 (es)
JP (1) JP6896940B2 (es)
KR (1) KR102469979B1 (es)
CN (1) CN110800248B (es)
ES (1) ES2880012T3 (es)
WO (1) WO2018228732A1 (es)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10270748B2 (en) 2013-03-22 2019-04-23 Nok Nok Labs, Inc. Advanced authentication techniques and applications
CA3029619C (en) * 2016-07-01 2022-12-06 American Express Travel Related Services Company, Inc. Systems and methods for validating transmissions over communication channels
DE102017216974A1 (de) * 2017-09-25 2019-05-16 Bundesdruckerei Gmbh Dataculestruktur und Verfahren zum manipulationssicheren Speichern von Daten
US11868995B2 (en) 2017-11-27 2024-01-09 Nok Nok Labs, Inc. Extending a secure key storage for transaction confirmation and cryptocurrency
US11831409B2 (en) 2018-01-12 2023-11-28 Nok Nok Labs, Inc. System and method for binding verifiable claims
GB201811263D0 (en) * 2018-07-10 2018-08-29 Netmaster Solutions Ltd A method and system for managing digital using a blockchain
US12041039B2 (en) * 2019-02-28 2024-07-16 Nok Nok Labs, Inc. System and method for endorsing a new authenticator
US11792024B2 (en) 2019-03-29 2023-10-17 Nok Nok Labs, Inc. System and method for efficient challenge-response authentication
US20210056053A1 (en) * 2019-08-19 2021-02-25 Cryptography Research, Inc. Application authentication and data encryption without stored pre-shared keys
US11552802B2 (en) * 2020-04-15 2023-01-10 Salesforce, Inc. Stateless mutual authentication between services
US11711213B2 (en) * 2020-07-23 2023-07-25 PolySign, Inc. Master key escrow process
US11973861B2 (en) * 2022-02-09 2024-04-30 Northrop Grumman Systems Corporation Secure key generation
US12021860B2 (en) * 2022-05-23 2024-06-25 Bank Of America Corporation Systems and methods for multi-stage, identity-based, digital authentication

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2788909B1 (fr) * 1999-01-27 2004-02-20 France Telecom Procede d'authentification ou de signature a nombre de calculs reduit
US8146141B1 (en) 2003-12-16 2012-03-27 Citibank Development Center, Inc. Method and system for secure authentication of a user by a host system
US8146142B2 (en) * 2004-09-03 2012-03-27 Intel Corporation Device introduction and access control framework
CN1797266A (zh) * 2004-12-21 2006-07-05 赛孚耐（北京）信息技术有限公司 软硬件之间的安全通讯方法及装置
US7900247B2 (en) * 2005-03-14 2011-03-01 Microsoft Corporation Trusted third party authentication for web services
US7861078B2 (en) * 2005-10-14 2010-12-28 Juniper Networks, Inc. Password-authenticated asymmetric key exchange
US20100138652A1 (en) * 2006-07-07 2010-06-03 Rotem Sela Content control method using certificate revocation lists
US8892887B2 (en) * 2006-10-10 2014-11-18 Qualcomm Incorporated Method and apparatus for mutual authentication
US8332923B2 (en) * 2007-01-19 2012-12-11 Toshiba America Research, Inc. Kerberized handover keying
CN102017510B (zh) * 2007-10-23 2013-06-12 赵运磊 自封闭联合知识证明和Diffie-Hellman密钥交换方法与结构
CA2621147C (en) * 2008-02-15 2013-10-08 Connotech Experts-Conseils Inc. Method of bootstrapping an authenticated data session configuration
KR101514840B1 (ko) * 2008-06-11 2015-04-23 삼성전자주식회사 휴대 방송 시스템에서의 암호화 키 분배 방법 및 이를 위한시스템
US20100306531A1 (en) * 2009-05-29 2010-12-02 Ebay Inc. Hardware-Based Zero-Knowledge Strong Authentication (H0KSA)
US8612771B2 (en) * 2012-01-06 2013-12-17 Netflix, Inc. Verifying authenticity of playback device
US20150113283A1 (en) * 2012-06-23 2015-04-23 Pomian & Corella Protecting credentials against physical capture of a computing device
US10305900B2 (en) * 2013-10-15 2019-05-28 Telefonaktiebolaget Lm Ericsson (Publ) Establishing a secure connection between a master device and a slave device
CN103731261B (zh) * 2014-01-09 2017-01-18 西安电子科技大学 加密重复数据删除场景下的密钥分发方法
AU2015214079C1 (en) * 2014-02-05 2017-01-19 Apple Inc. Uniform communication protocols for communication between controllers and accessories
US9509502B2 (en) * 2014-03-13 2016-11-29 Intel Corporation Symmetric keying and chain of trust
RU2710897C2 (ru) * 2014-08-29 2020-01-14 Виза Интернэшнл Сервис Ассосиэйшн Способы безопасного генерирования криптограмм
WO2016190903A2 (en) * 2014-12-29 2016-12-01 Vasco Data Security, Inc. Method and apparatus for securing a mobile application
US9602288B1 (en) * 2015-03-27 2017-03-21 Amazon Technologies, Inc. Enhanced data security through uniqueness checking
CN105141602A (zh) * 2015-08-18 2015-12-09 西安电子科技大学 基于收敛加密的文件所有权证明方法

Also Published As

Publication number Publication date
KR20200013764A (ko) 2020-02-07
WO2018228732A1 (en) 2018-12-20
JP6896940B2 (ja) 2021-06-30
KR102469979B1 (ko) 2022-11-25
EP3613169A1 (en) 2020-02-26
CN110800248A (zh) 2020-02-14
EP3613169B1 (en) 2021-03-17
CN110800248B (zh) 2022-11-22
US20200177563A1 (en) 2020-06-04
US11196722B2 (en) 2021-12-07
JP2020526146A (ja) 2020-08-27

Similar Documents

Publication Publication Date Title
ES2880012T3 (es) Método para la autenticación simétrica mutua entre una primera aplicación y una segunda aplicación
US9467430B2 (en) Device, method, and system for secure trust anchor provisioning and protection using tamper-resistant hardware
US10965453B2 (en) System and method for authenticated encryption based on device fingerprint
ES2701873T3 (es) Servicio de inicio de sesión único distribuido
ES2601505T3 (es) Identificación de teléfono móvil y autenticación de comunicación
US9838870B2 (en) Apparatus and method for authenticating network devices
KR101237632B1 (ko) 토큰과 검증자 사이의 인증을 위한 네크워크 헬퍼
US20220103369A1 (en) Security system and related methods
ES2687238T3 (es) Método de arquitectura de arranque de seguro basado en autenticación de resumen basada en contraseña
US20190089546A1 (en) System and method for distribution of identity based key material and certificate
US10680816B2 (en) Method and system for improving the data security during a communication process
BRPI0607359B1 (pt) Auto-iniciação segura para comunicações sem fio
ES2659580T3 (es) Procedimiento de comprobación de la preservación de privacidad entre tres partes que se comunican entre sí
BR112019013584A2 (pt) Endereçamento de um ambiente de execução confiável usando a chave de assinatura
ES2634024A1 (es) Método seguro para compartir datos y controlar el acceso a los mismos en la nube
WO2018202109A1 (zh) 一种证书请求消息发送方法、接收方法和装置
ES2926968T3 (es) Una primera entidad, una segunda entidad, un nodo intermedio, métodos para establecer una sesión segura entre una primera y una segunda entidad, y productos de programa informático
CN111836260B (zh) 一种认证信息处理方法、终端和网络设备
CN111835691B (zh) 一种认证信息处理方法、终端和网络设备
Costea et al. Secure opportunistic multipath key exchange
Parrinha et al. Flexible and low-cost HSM based on non-volatile FPGAs
ES2909011T3 (es) Sistemas y métodos para recibir y transmitir señales de comunicación
Li et al. A cloud based dual-root trust model for secure mobile online transactions
RU2771928C2 (ru) Безопасный обмен данными, обеспечивающий прямую секретность
CN114124377B (zh) 一种量子密钥的传输方法、装置、系统及存储介质