ES2962485T3 - Aprovisionamiento seguro de claves - Google Patents

Aprovisionamiento seguro de claves Download PDF

Info

Publication number
ES2962485T3
ES2962485T3 ES18807672T ES18807672T ES2962485T3 ES 2962485 T3 ES2962485 T3 ES 2962485T3 ES 18807672 T ES18807672 T ES 18807672T ES 18807672 T ES18807672 T ES 18807672T ES 2962485 T3 ES2962485 T3 ES 2962485T3
Authority
ES
Spain
Prior art keywords
key
secret
provisioning
certificate
asymmetric
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
ES18807672T
Other languages
English (en)
Inventor
Fabien Gremaud
Nicolas Fischer
Karine Villegas
Jean-Bernard Fischer
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.)
Nagravision SARL
Original Assignee
Nagravision SARL
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 Nagravision SARL filed Critical Nagravision SARL
Application granted granted Critical
Publication of ES2962485T3 publication Critical patent/ES2962485T3/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/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—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 digital signatures
    • 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/006—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving public key infrastructure [PKI] trust models
    • 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/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • 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/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)

Abstract

Los métodos y dispositivos de acuerdo con la divulgación se relacionan con el suministro seguro de una o más claves o pares de claves para proteger datos secretos para, o asociados con, un dispositivo informático. El dispositivo suele ser un dispositivo informático con al menos un procesador o módulo de procesamiento configurado para ejecutar una o más aplicaciones utilizando los datos secretos. La presente divulgación garantiza el aprovisionamiento seguro de claves al garantizar que cada clave en un par de claves, o al menos una clave entre una pluralidad de claves, esté asociada con un dispositivo o módulo de hardware que sea distinto del dispositivo o módulo de hardware asociado con el otras claves o las restantes. Para el aprovisionamiento de claves asimétricas, esto se relaciona con la utilización de firmas digitales verificadas por dispositivos separados. Para el aprovisionamiento de claves simétricas, esto se relaciona con la utilización de una función de derivación de claves secretas que funcionará con semillas secretas que se ingresan desde dos fuentes separadas. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Aprovisionamiento seguro de claves
Campo
La presente divulgación se refiere a métodos y a dispositivos para el aprovisionamiento seguro de una clave o claves para proteger datos secretos para, o asociados con, un dispositivo configurado para ejecutar una o más aplicaciones que usan los datos secretos.
Antecedentes
Los dispositivos responsables de implementar uno o más procedimientos usando datos protegidos o secretos pueden estar asociados con una identidad de código único u otros datos asociados, habitualmente en forma de un secreto único que es habitualmente el secreto raíz del dispositivo, conocido como raíz de confianza (RoT). RoT es un conjunto de funciones en un entorno informático de confianza, en el que aspectos relacionados con el ordenador, es decir el dispositivo, o su seguridad se abordan mediante hardware y mejoras o procedimientos de software asociados. Por tanto, pueden ser instrucciones incorporadas de las que siempre confía el sistema operativo (OS) del módulo. La RoT puede ser un motor de cálculo independiente que controla la seguridad de credenciales específicas de dispositivo, a las que puede accederse a partir del identificador o datos secretos únicos de dispositivo a través de la RoT. Por tanto, los datos secretos o únicos de dispositivo deben protegerse con el fin de que esas credenciales específicas no se vean comprometidas por un atacante.
Un ejemplo de tales dispositivos puede ser un dispositivo de sistema en un chip (SoC), que puede producirse inicialmente sin una identidad única. Esta se proporciona posteriormente por un sistema durante el ciclo de vida de producción del SoC/dispositivo. Pueden usarse diversos protocolos de gestión de claves para proteger la identidad única de un SoC/dispositivo, tales como pares de claves simétricas y asimétricas o una combinación de ambas, que se implementan para el SoC o dispositivo. Esto incluye habitualmente procedimientos que usan infraestructura de clave pública (PKI) como clave y sistema de gestión de certificados de claves para la protección, recuperación y copia de seguridad de claves. Sin embargo, la seguridad de identidad de dispositivo y/o claves asociadas con el SoC/dispositivo puede verse comprometida si hackea o ataca el propio dispositivo responsable de las claves, permitiendo de ese modo acceso a la identidad única o clave durante y/o después del procedimiento de aprovisionamiento y gestión de claves existente, o bien por un impostor o bien mediante otros tipos de ataques. Se dan a conocer soluciones de la técnica anterior en los documentos WO 03/091858 A2 y US 2005/154889A1. Por este motivo, existe una necesidad de un método mejorado y robusto de aprovisionamiento de claves que proporcione medidas de protección contra clonación y suplantación de dispositivo, cuando la seguridad del dispositivo se ve comprometida.
El objetivo anterior se logra por medio del juego adjunto de reivindicaciones.
Breve descripción de los dibujos
Ahora se describen diversas realizaciones a modo de ejemplo con fines de explicación e ilustración, con referencia a los dibujos adjuntos en los que:
la figura 1 es un esquema que representa una primera realización de la divulgación para el aprovisionamiento de claves asimétricas para un dispositivo;
la figura 2 es un esquema que representa una segunda realización de la divulgación para el aprovisionamiento de claves asimétricas para un dispositivo;
la figura 3 es un esquema que representa una tercera realización para mostrar un sistema de gestión de claves para el aprovisionamiento de claves para un dispositivo; y
la figura 4 es un ejemplo de implementación de un dispositivo según las realizaciones descritas.
Descripción detallada de los dibujos
En resumen, los métodos y dispositivos según la divulgación se refieren al aprovisionamiento seguro de una o más claves o pares de claves para proteger datos secretos para, o asociados con, un dispositivo informático. El dispositivo es normalmente un dispositivo informático con al menos un procesador o módulo de procesamiento configurado para ejecutar una o más aplicaciones que usan los datos secretos. En un aspecto principal, la presente divulgación garantiza el aprovisionamiento de claves seguro garantizando que cada clave en un par de claves, o al menos una clave de una pluralidad de claves, está asociada con un dispositivo o módulo de hardware que es distinto del/de los dispositivo(s) o módulo de hardware asociados con las otras claves o claves restantes.
El dispositivo informático para el que se generan claves puede ser un sistema en un chip, que comprende un módulo de confianza de hardware incorporado tal como la raíz de confianza (RoT). Por ejemplo, los datos secretos del dispositivo pueden ser un código o identificador único que está incorporado en el módulo de confianza, y tales datos secretos puede necesitarlos el dispositivo o un sistema o módulo externo para cargar las credenciales específicas de dispositivo respectivo que permiten el acceso a una o más aplicaciones (por ejemplo, un derecho para televisión de pago). Por tanto, los datos secretos de dispositivo deben protegerse usando una o más claves de modo que las credenciales específicas de dispositivo no se clonan o manipulan por un atacante.
Una primera realización de la presente divulgación se refiere a un método seguro de aprovisionamiento de claves asimétricas en un dispositivo que puede ejecutar aplicaciones que usan datos secretos. En los métodos y sistemas existentes, esto se implementa habitualmente usando algoritmos de claves asimétricas bien conocidos (por ejemplo, RSA, DSA, etc.), mediante lo cual la infraestructura de clave pública (PKI) genera las claves pública y privada que después se gestionan pro el sistema de gestión de claves (KMS). Sin embargo, tal como se mencionó anteriormente, los procedimientos existentes no evitan que los atacantes obtengan acceso a las claves clonando o suplantando el dispositivo, ya que este procedimiento de generación de claves asimétricas se ejecuta totalmente dentro de la PKI usando el dispositivo clonado.
Para superar este problema, la primera realización usa algoritmos de generación de par de claves asimétricas adaptados y una infraestructura de intercambio de claves que requiere autenticación de la identidad del dispositivo a partir de al menos otro dispositivo, por ejemplo externo. De una manera preferida, esto tiene lugar implementando o empleando una autoridad de certificado (CA) en o asociada con el propio dispositivo (denominado en el presente documento primer dispositivo por claridad) y un dispositivo externo que actúa como CA independiente para verificar la identidad de, o verificar una clave pública asociada con, el dispositivo en cuestión.
Con respecto a PKI, se sabe que un certificado, o un certificado de clave pública también conocido como certificado digital o certificado de identidad, es un documento electrónico usado para demostrar la propiedad de una clave pública. El certificado incluye información sobre la clave, información sobre la identidad de su propietario (habitualmente denominado sujeto) y la firma digital de una entidad que ha verificado el contenido del certificado (denominada emisor o autoridad de certificado). Por tanto, un certificado digital certifica la propiedad de una clave pública. Esto garantiza al menos dos etapas de verificación de identidad de dispositivo o certificado de la clave pública usando al menos dos entidades diferentes. Como resultado, aunque el primer dispositivo se vea comprometido, la verificación de las claves no puede completarse satisfactoriamente y, por tanto, no puede usarse la clave asimétrica o par de claves para ningún procesamiento adicional, sin hacer en primer lugar que se confirme su identidad por ambos dispositivos (primero y externo en este ejemplo en cuestión).
Una segunda realización de la presente divulgación se refiere a un método de aprovisionamiento de claves simétricas en un dispositivo. En los métodos y sistemas existentes, esto se implementa habitualmente mediante algoritmos de claves simétricas (por ejemplo DES, AES, etc.), o una función de derivación de claves (KDF) que deriva su(s) clave(s) a partir de una(s) semilla(s) secreta(s), es decir que son el punto inicial de un módulo de generación de números aleatorios, por ejemplo. Sin embargo, surge un problema similar al descrito anteriormente en relación con la realización anterior cuando se usan algoritmos de generación de claves conocidos para claves simétricas. Con las KDF, puede generarse una semilla secreta dentro del propio dispositivo, y después procesarse por la KDF para generar la clave. Cuando la KDF se basa únicamente en un valor interno y secreto, es decir que ninguna sal externa que pueda aportar entropía y diversificación, esto presenta desafíos similares ya que no puede garantizarse la seguridad del dispositivo frente a ataques mediante clonación o suplantación del dispositivo, lo cual puede dar como resultado un acceso no autorizado para generar y, de hecho, usar claves generadas.
Para superar este problema, la segunda realización de esta divulgación implementa un método que obtiene al menos una semilla secreta a partir de una fuente segura externa, además del dispositivo para una KDF, que entonces se usa para generar claves simétricas. En un aspecto preferido, se genera una semilla secreta en el propio dispositivo, y la segunda se proporciona a partir de una fuente externa, que también puede contener información adicional (por ejemplo, identificador único, otras claves, etc.). En este caso, un primer dispositivo puede conectarse a la fuente segura configurada para generar la segunda semilla secreta requerida para la generación de claves simétricas. Entonces pueden implementarse diversas medidas de seguridad y protocolos de intercambio de claves para confirmar la identidad del primer dispositivo y permitir la transferencia segura de la semilla secreta desde la fuente segura hasta el primer dispositivo, preferiblemente a través de otro dispositivo tal como un módulo de seguridad de hardware (HSM) para transportar las claves. Como resultado, aunque el primer dispositivo se vea comprometido, no obtendrá acceso a todas las entradas que requiere la KDF para la generación de claves simétricas a menos que se confirme la identidad del primer dispositivo y pueda descifrar información recibida a partir de la fuente segura.
Realizaciones adicionales de la presente divulgación se extienden a, e incluyen, el aprovisionamiento de claves usando una combinación de métodos de generación de claves tanto asimétricas como simétricas tal como se describió anteriormente.
Una tercera realización de la presente divulgación se refiere a un método de gestión de claves seguras para el dispositivo. Esto se refiere a gestionar la transferencia, almacenamiento, acceso y generación de claves seguras en un KMS para su almacenamiento seguro. Se trata de proporcionar una manera segura de incluir o generar las claves asimétricas y/o simétricas, en las que al menos una clave o una clave en un par de claves se ha verificado y/o generado en asociación con al menos un dispositivo o fuente distinto del primer dispositivo.
Ahora se describen algunas realizaciones específicas a modo de ilustración con referencia a los dibujos adjuntos en los que números de referencia iguales se refieren a características iguales.
La figura 1 es un esquema que representa la primera realización haciendo referencia al aprovisionamiento de claves asimétricas seguro para proteger secretos de dispositivo. En esta realización, un primer dispositivo 102 que puede ejecutar aplicaciones que requieren el uso de una identidad única o identidad secreta se conecta a través de una red de comunicación inalámbrica o cableada a al menos otro dispositivo 108 externo. El primer dispositivo 102 puede estar configurado para procesar un algoritmo de generación de claves asimétricas predefinido, tal como RSA, DSA, etc., para generar un par de claves asimétricas. También puede generarse mediante un módulo externo y después enviarse al dispositivo. Entonces, cada uno del dispositivo 102 y el/los dispositivo(s) 108 externo(s) firmará y verificará certificados digitales para la clave asimétrica pública generada. La verificación de dos factores de firmas o certificados digitales garantiza que se verifica la identidad del dispositivo que emite la clave pública por dos fuentes de hardware independientes, es decir el dispositivo 102 y el módulo 108 externo. Esto garantiza que no pueden verificarse claves asimétricas para su acceso o cifrado adicional si cualquiera de los dos dispositivos está comprometido.
Tal como se observa en la figura 1, un ejemplo de implementación de la realización comprende un dispositivo 102 (también denominado primer dispositivo en el presente documento) que incluye preferiblemente un módulo 104 de RoT y un módulo 106 de almacenamiento programable una sola vez (OTP) en la RoT 104. El dispositivo 102 está acoplado en comunicación a un segundo dispositivo, que es preferiblemente un HSM 108 en un entorno o instalación de fabricación.
La RoT 104 puede estar configurada para implementar una PKI para generar claves asimétricas y simétricas mediante algoritmos de claves conocidos o usando una KDF. La RoT 104 y el HSM 108 se implementan como CA, con la funcionalidad de verificar el origen de los datos o una clave. Cada uno está configurado para tener sus claves de firma de PKI respectivas, indicadas en el presente documento como rot_pkiSignKey, rot_hsmSignKey, que les permiten generar firmas o certificados digitales. La RoT 104 también contiene una clave pública de H<s>M 108, indicada en el presente documento como hsm_pkiRootPubKey, y HSM [108] contiene una clave pública de la RoT 104, indicada en el presente documento como rot_pkiRootPubKey, que pueden usarse para acceder a datos respectivos uno de otro, para autorizar certificados firmados por las claves de firma correspondientes.
En la etapa S1002, la RoT 102 genera en primer lugar las claves asimétricas mediante un algoritmo de claves asimétricas (por ejemplo RSA, DSA, etc.) y almacena claves asimétricas tanto públicas como privadas asociadas con el dispositivo, indicadas en el presente documento como rotPubUKey, rotPrivUKey, respectivamente, en el almacenamiento 106 OTP. Tal como se mencionó anteriormente, estas claves también pueden generarse a partir de un módulo adicional asociado con el dispositivo que puede generar claves basándose en la generación de números aleatorios.
En la etapa S1004, pueden implementarse medidas adicionales para garantizar la seguridad de claves públicas, en las que el almacenamiento 106 OTP puede proporcionar la rotPubUKey a la RoT 104 para firmarse con la clave de firma rot_pkiSignKey. Esto genera un primer certificado, indicado en el presente documento como rotPubUKeyRoTCertificate, asociado con rotPubUKey, que entonces se envía desde la RoT 104 hasta el HSM 108. En la etapa S1006, el HSM 108 verifica el primer certificado con la rot_pkiRootPubKey de la RoT 104, y de ese modo la identidad del dispositivo 102.
En la etapa S1008, una vez que la verificación es satisfactoria, entonces el HSM 108 firma rotPubUKey, que se extrae a partir del certificado verificado, es decir rotPubUKeyRoTCertificate con su clave de firma rot_hsmSignKey, creando de ese modo un segundo certificado, indicado en el presente documento como rotPubUKeyHsmCertificate. En la etapa S1010, el rotPubUKeyHsmCertificate se envía a la RoT 104 para verificarse con hsm_pkiRootPubKey del HSM 108.
En la etapa S1012, una vez que la verificación en S1010 es satisfactoria, se hace que el primer y segundo certificados, es decir rotPubUKeyHsmCertificate, rotPubUKeyRoTCertificate tal como se obtienen a partir de las etapas anteriores, estén disponibles para su almacenamiento y/o uso adicional en el dispositivo 102 o se incluyen en un KMS u otro módulo de almacenamiento para su uso adicional.
Por tanto, el método de generación de claves asimétricas requiere verificar la firma digital asociada con la clave asimétrica pública de dispositivo usando dos dispositivos independientes. Esta implementación también requiere el uso de claves de firma a partir de dos dispositivos independientes para esto. El segundo dispositivo no está limitado a un HSM y puede usarse cualquier dispositivo siempre que pueda realizar la tarea de firmar y verificar certificados digitales.
Una implementación alternative y relacionada de la primera realización puede implicar el uso de dos o más dispositivos en la que la firma y verificación de la clave asimétrica pública puede procesarse dos o más veces para proporcionar capas adicionales de seguridad. Por tanto, la realización no se limita a que el primer dispositivo esté conectado únicamente a un dispositivo externo.
Una implementación a modo de ejemplo del dispositivo según la primera realización incluye un dispositivo 102 que tiene una o más unidades 104 de procesamiento, una unidad 106 de memoria y puertos para enviar y recibir datos, y que está acoplado en comunicación a al menos un HSM 108. Entonces, el dispositivo 102 está configurado para ejecutar al menos las siguientes funciones, que también se muestran a modo de ejemplo en la descripción anterior en relación con la primera realización:
(a) generar un par de claves de cifrado asimétricas para el dispositivo; comprendiendo el par de claves una clave pública de dispositivo y una clave privada de dispositivo. Por ejemplo, el par de claves asimétricas se genera preferiblemente usando una función física no clonable, PUF. Preferiblemente, el par de claves de cifrado asimétricas no se almacena en memoria, sino que, en vez de eso, se regenera usando la PUF;
(b) firmar digitalmente la clave pública de dispositivo para generar un primer certificado;
(c) transmitir el primer certificado a un primer módulo de hardware para su verificación;
(d) si la verificación del primer certificado es satisfactoria, recibir un segundo certificado a partir del primer módulo de hardware, firmándose el segundo certificado digitalmente por el primer módulo de hardware;
(e) verificar el segundo certificado en el dispositivo;
(f) en respuesta a que la verificación sea satisfactoria; proporcionar el primer y segundo certificados para su almacenamiento y/o uso adicional.
Una implementación a modo de ejemplo del HSM 108 para la primera realización incluye un HSM 108 que está acoplado en comunicación al dispositivo 102 e incluye uno o más módulos de procesamiento configurados para: (a) recibir un primer certificado a partir del dispositivo, generándose el primer certificado firmando digitalmente una clave pública de dispositivo de un par de claves de cifrado asimétricas del dispositivo;
(b) verificar el primer certificado en el módulo de hardware;
(c) si la verificación es satisfactoria, firmar digitalmente la clave pública de dispositivo para generar un segundo certificado;
(d) transmitir el segundo certificado al dispositivo para su verificación y, si la verificación es satisfactoria, hacer que el primer y segundo certificados estén disponibles para su almacenamiento y/o uso adicional.
La figura 2 es un esquema según la segunda realización de la divulgación para aprovisionamiento de claves simétricas seguro para proteger datos secretos o código(s) único(s) de dispositivo. En un aspecto, esta realización puede implementarse conectando un dispositivo 202, denominado en el presente documento primer dispositivo 202, a través de una red, que puede ser inalámbrica o cableada, con al menos otro dispositivo 208 externo. Como en la primera realización, el dispositivo 202 está asociado con una RoT 204 Con el fin de generar una clave simétrica, una KDF secreta que se implementa dentro de la RoT 204 del primer dispositivo está configurada para generar claves simétricas a partir de al menos dos entradas. Por ejemplo, estas entradas pueden estar en forma de al menos dos semillas secretas que se obtienen a partir de al menos dos dispositivos o fuentes diferentes. Sin el aprovisionamiento de al menos una semilla secreta a partir de un dispositivo externo o una fuente que es diferente a la otra de las al menos dos semillas secretas, el primer dispositivo 202 no podrá implementar o aplicar la KDF secreta para generar las claves simétricas. Pueden emplearse protocolos de intercambio seguro adicionales para garantizar la transferencia segura de una semilla secreta externa a partir de un dispositivo externo. El primer dispositivo podrá acceder a, y descifrar, las semillas secretas externas si puede confirmarse su identidad usando al menos dos fuentes diferentes, una de las cuales es externa al primer dispositivo 202.
Tal como se observa en la figura 2, el dispositivo 202, que en el presente documento también se denomina primer dispositivo 202, puede incluir componentes y estructura similares al dispositivo 102 de la figura 1, es decir una RoT 204, un almacenamiento 206 OTP, etc. Además de esto, el dispositivo 202 está acoplado en comunicación a otro dispositivo, que puede ser un HSM 208, y también acoplado en comunicación a una fuente 210 segura que es externa al dispositivo 202, y preferiblemente al HSM 208. La fuente 210 segura está preferiblemente acoplada en comunicación con el HSM 208. El HSM 208 también se denomina segundo HSM, que puede ser la misma entidad o una entidad diferente de la del HSM 108 de la figura 1, en esta realización.
El segundo HSM 208 puede estar configurado para tener ya acceso o puede obtener de manera segura la clave pública de un HSM adicional, tal como, por ejemplo, el primer HSM 108 de la figura 1, que puede ser una de las CA responsables de la verificación de un par de claves asimétricas generado para el dispositivo 202. Además, el segundo HSM 208 puede contener la rot_pkiRootPubKey de la RoT 204 y la propia clave pública del HSM 208, indicada en el presente documento como hsmKey, con el fin de implementar protocolos de intercambio de claves en el dispositivo 202 basándose en una PKI para la autenticación y transferencia de datos y claves entre la fuente 210 segura y el dispositivo 202.
El HSM 208 permite vincular un secreto generado único de la RoT, con una imagen de personalización generada única durante la producción, también denominado asociación posterior, obtenido por ejemplo usando la fuente 210 segura descrita anteriormente. En un ejemplo de implementación preferido, la fuente 210 segura puede estar configurada para proporcionarle claves de aprovisionamiento, provisioningKeys, una primera semilla secreta, denominada rotSecretSeed, que es un identificador único para el dispositivo durante la producción, la hsmKey pública del segundo HSM 208 y una clave de firma de aprovisionamiento denominada pkiRootProvisioningSignKey, usada para cualquier dato que tiene que enviarse al dispositivo [202] a partir de la fuente [210] segura.
La RoT 204 en el dispositivo 202 comprende además claves de aprovisionamiento públicas, indicadas como pkiRootProvisioningPubKey para la verificación de firmas a partir de la fuente 210 segura, y también está configurada para almacenar de manera segura al menos una semilla adicional denominada en el presente documento segunda semilla, indicada como rotSecretGlobalKey. Preferiblemente, esta es una clave global secreta rotSecretGlobalKey única para el dispositivo, que se obtiene, se almacena o se genera dentro de un módulo de confianza dentro del dispositivo 202. La RoT 204 también está configurada para implementar una KDF secreta para generar las claves simétricas.
Con el fin de generar claves simétricas, la RoT 204 requiere entradas que permiten implementar una KDF. En una implementación preferida de la segunda realización, estas entradas son la primera semilla secreta, rotSecretSeed, la segunda semilla secreta rotSecretGlobalKey y una clave asimétrica pública, es decir rotPubUKey perteneciente al dispositivo 202. Para esta realización, se supone que el par de claves asimétricas rotPubUKey, rotPrivUKey y los certificados rotPubUKeyHsmCertificate, rotPubUKeyRoTCertificate para el dispositivo 202 se han generado anteriormente para el dispositivo 202, por ejemplo, mediante las etapas expuestas con respecto a la figura 1. Por tanto, dado que a la RoT 204 ya se le han proporcionado rotPubUKey y rotSecretGlobalKey, la RoT 204 requiere la rotSecretSeed a partir de la fuente 210 segura con el fin de generar claves simétricas.
Pueden implementarse protocolos seguros para garantizar el suministro seguro de la primera semilla secreta desde la fuente 210 segura hasta la RoT 204.
Un ejemplo de cómo se realiza este procedimiento para la segunda realización puede explicarse de la siguiente manera. En la etapa S2002, el dispositivo 202 envía rotPubUKeyHsmCertificate, rotPubUKeyRoTCertificate al segundo HSM208 para confirmar la identidad del dispositivo 202 que ha emitido la rotPubUKey para protocolos de intercambio de claves. En un ejemplo, estos certificados pueden ser los mismos que los certificados mencionados en la primera realización de la figura 1. El segundo HSM 208 verifica ambos certificados usando las claves públicas, rot_pkiRootPubKey, hsm_pkiRootPubKey de la RoT 204 y un primer HSM, que puede ser el mismo que el HSM 108 de la figura 1. Una vez que las verificaciones de ambos certificados son satisfactorias, el segundo HSM 208 puede extraer rotPubUKey para su uso adicional.
En la etapa S2004a, la fuente 210 segura garantiza la seguridad de la primera semilla secreta rotSecretSeed, que, en una realización preferida, puede estar asociada con un secreto o identidad de dispositivo único, cifrando la rotSecretSeed con provisioningKeys.
Entonces, en la etapa S2004b, la fuente 210 segura firma provisioningKeys con la clave de firma de aprovisionamiento, indicada en el presente documento como pkiRootProvisioningSignKey, generando una firma, y después cifra la clave de aprovisionamiento firmada con la clave pública hsmKey del segundo HSM 208.
Entonces, en la etapa S2004c, se envía la clave de aprovisionamiento firmada y cifrada, indicada como [provisioningKeys, sign] hsmKey, al segundo HSM 208.
En la etapa S2004d, el segundo HSM208 descifra la clave de aprovisionamiento firmada con hsmKey y la cifra con rotPubUKey del dispositivo 202. Entonces, puede descifrarse mediante rotPrivUKey del par de claves asimétricas del dispositivo 202 y verificarse mediante la clave pública pkiRootProvisioningPubKey. Por tanto, el segundo HSM 208 ha descifrado la clave de aprovisionamiento firmada con su propia clave privada antes de volver a cifrarla con la clave pública de dispositivo y es responsable de la transferencia segura de estas claves de aprovisionamiento al dispositivo 202 que implementa la KDF secreta. Usar un HSM tal como el HSM 208 garantiza ventajosamente basarse en al menos dos elementos para generar las claves simétricas.
Entonces, en la etapa S2006, se envía la clave de aprovisionamiento cifrada, indicada en el presente documento mediante [provisioningKeys, sign]rotPubUKey, a la RoT 204.
En la etapa S2010, se descifra mediante la rotPrivUKey, y después se verifica la firma de clave de aprovisionamiento usando la pkiRootProvisioningPubKey. Entonces, tras el descifrado y la verificación satisfactorios en la RoT 204, se hace que provisioningKeys estén disponibles para la RoT 204 para su uso adicional.
En paralelo con las etapas S2006 y S2010 anteriores, la fuente 210 segura envía la rotSecretSeed, cifrada mediante las provisioningKeys, indicada en el presente documento mediante [rotSecretSeed]provisioningKey, a la RoT 204 en la etapa [S2008].
Dado que ahora se le habrá proporcionado a la RoT 204 acceso a provisioningKeys, puede verificar y descifrar la [rotSecretSeed], lo cual se realiza en la etapa S2012. Esto hace que la rotSecretSeed esté disponible para la generación de claves simétricas mediante una KDF secreta en la RoT [204].
Entonces, en la etapa S2014, la RoT 204 usa la rotSecretSeed, rotSecretGlobalKey y rotPubUKey para generar las claves simétricas rotSymUKeySign, rotSymUKeyDecrypt con la KDF secreta.
Entonces, en la etapa S2016, se almacenan las claves simétricas generadas en la RoT 204, el almacenamiento [206] OTP o pueden enviarse a un KMS para su uso adicional.
Por tanto, el método de generación de claves simétricas según la segunda realización implica una KDF secreta que requiere al menos una semilla secreta a partir de una fuente 210 segura externa, además de una semilla secreta a partir del dispositivo 202 que ejecuta aplicaciones que requieren los secretos que están protegidos por esas claves. La presente divulgación no está limitada a una única fuente segura, y pueden acoplarse múltiples fuentes seguras al dispositivo 202 que contiene las semillas secretas respectivas requeridas para la generación de claves simétricas mediante una KDF secreta en la RoT 204.
Además, cualquier dispositivo que puede realizar la tarea de firmar y autorizar certificados digitales tal como se explicó anteriormente para el transporte seguro de las claves de aprovisionamiento, puede usarse como, o en lugar del, HSM 208 para el aprovisionamiento seguro de la semilla secreta al dispositivo [202].
Por ejemplo, una implementación alternativa de la segunda realización puede implicar el dispositivo 202 acoplado con una fuente externa secreta cualquiera. En este caso, se necesitará implementar un mecanismo de intercambio de claves y datos seguro para la transferencia segura de la semilla secreta a partir de esta fuente secreta externa individual. Entonces, la fuente segura individual puede necesitar implementar, en un aspecto, las funciones tanto del HSM [208] como de la fuente [210] segura tal como se describe en la figura 2.
En un ejemplo de implementación, el dispositivo 202 incluye una unidad de memoria, una o más unidades de transceptor y una o más unidades de procesamiento, y está acoplado en comunicación a un HSM 208, y el dispositivo 202 está configurado para:
(a) recibir a partir de un segundo módulo de hardware una clave de aprovisionamiento cifrada con una clave pública de dispositivo de un par de claves asimétricas que se ha verificado usando un primer y/o segundo certificados, en el que la clave de aprovisionamiento se descifra usando una clave privada de dispositivo del par de claves asimétricas asociado con el dispositivo y;
(b) recibir a partir de una fuente externa segura, una primera semilla secreta firmada mediante la clave de aprovisionamiento, en el que la primera semilla secreta se verifica y descifra usando las claves de aprovisionamiento descifradas; y
(c) generar una clave o claves de cifrado simétricas usando una función de derivación de claves secreta con entradas que comprenden la primera semilla secreta, la clave pública de dispositivo y una segunda semilla secreta; en el que la segunda semilla secreta se obtiene, se almacena o se genera en el dispositivo;
(d) en el que las unidades de procesamiento del dispositivo 202 incluyen opcionalmente el dispositivo 102 de la primera realización.
En un ejemplo adicional, el HSM 208 está acoplado en comunicación al dispositivo 202, e incluye uno o más módulos de procesamiento configurados para:
(a) verificar una clave pública de dispositivo de un par de claves asimétricas asociado con el dispositivo usando un primer y/o segundo certificados del par de claves asimétricas para el dispositivo respectivo;
(b) recibir una clave de aprovisionamiento a partir de una fuente segura, estando la fuente segura acoplada en comunicación con el dispositivo y el módulo de hardware;
(c) en respuesta a una verificación satisfactoria del primer y/o segundo certificados, transmitir la clave de aprovisionamiento cifrada con la clave pública de dispositivo al dispositivo para su descifrado, en el que la clave de aprovisionamiento permite que el dispositivo use una primera semilla secreta recibida a partir de la fuente segura para generar una clave simétrica con una segunda semilla secreta almacenada o generada por el dispositivo.
Una tercera realización de la divulgación implica la inclusión segura de claves asimétricas y/o simétricas asociadas con un dispositivo para ejecutar aplicaciones que requieren secretos, con un KMS. En la figura 3 se muestra un ejemplo de la inclusión segura de claves de cifrado asimétricas y/o simétricas asociadas con un dispositivo en un KMS.
En una realización preferida, el dispositivo 302 puede ser, en un ejemplo, el dispositivo 102 en la figura 1 y/o el dispositivo 202 en la figura 2.
Tal dispositivo 302 está acoplado en comunicación a un KMS 304, que comprende al menos una base de datos 306 y un almacenamiento 308 de memoria, junto con al menos un módulo 310 de procesamiento para ejecutar una KDF. El KMS 304, en un aspecto preferido, está preconfigurado para tener acceso a una semilla, por ejemplo rotSecretGlobalKey, que está asociada con el dispositivo 302 para la generación de las claves simétricas; las claves de PKI públicas, tales como rot_pkiRootPubKey, hsm_pkiRootPubKey del dispositivo [302]; y al menos un HSM, que puede ser, por ejemplo, el HSM 108 en la figura 1 y/o el HSM 208 en la figura 2. El hSm es preferiblemente uno que ha sido responsable de la verificación previa de claves asimétricas públicas del dispositivo 302. Adicionalmente, el KMS 304 también está configurado para contener una KDF, que es preferiblemente la misma que la KDF secreta mencionada en la figura 2 y se requiere para la generación de claves simétricas asociadas con el dispositivo 302. El KMS 304 también está configurado para obtener una semilla secreta adicional usando protocolos de comunicación segura a partir de una fuente externa, que puede ser similar a la fuente 210 segura en la figura 2, para su almacenamiento en la base 306 de datos.
En la etapa S3002, el dispositivo 302 envía sus certificados anteriormente generados rotPubUKeyRoTCertificate, rotPubUKeyHsmCertificate al KMS 304.
En la etapa S3004, el KMS 304 verifica los certificados con sus claves públicas respectivas, es decir rot_pkiRootPubKey, hsm_pkiRootPubKey, para obtener acceso a la rotPubUKey del dispositivo 302.
Entonces, en la etapa S3006, el KMS 304 está configurado para generar las claves simétricas del dispositivo 302 ejecutando la KDF asociada con el dispositivo 302 en el módulo 310 de procesamiento. Esto se calcula con la rotSecretSeed a partir de la base 306 de datos, y la rotSecretGlobalKey y rotPubUKey.
En la etapa S3008, después de haberse generado las claves simétricas rotSymUKeySign, rotSymUKeyDecrypt, se transfieren con rotPubUKey a la memoria 308 para su uso adicional.
Por consiguiente, tal como se muestra a modo de ejemplo en la presente divulgación en las figuras 1, 2 y 3, las claves para el cifrado para un dispositivo que ejecuta aplicaciones que requieren datos secretos, ya sean asimétricas o simétricas, se proporcionan usando o bien certificados digitales (en el caso de la primera realización) o bien semillas secretas para cifrado (en el caso de la segunda realización) generados a partir de al menos una fuente de hardware segura adicional, además del propio dispositivo. Esto garantiza que las claves no son vulnerables a un ataque mediante suplantación del dispositivo o clonación del dispositivo o HSM usado en el procedimiento anterior. Si se clona o bien el dispositivo o bien de hecho el HSM, el procedimiento requiere entradas de ambas fuentes, de modo que o bien la autenticación fallará (en la primera realización) ya que no se emitirán las CA para verificar la identidad del dispositivo, o bien de hecho no puede ejecutarse una KDF (en la segunda realización) ya que no podrá obtenerse o bien las claves o bien la semilla secreta.
La figura 4 ilustra un diagrama de bloques de una implementación de un dispositivo 400 informático dentro del cual puede ejecutarse un conjunto de instrucciones, para hacer que el dispositivo informático realice una cualquiera o más de las metodologías comentadas en el presente documento. En implementaciones alternativas, el dispositivo informático puede estar conectado (por ejemplo, conectado en red) a otras máquinas en una red de área local (LAN), una intranet, una extranet o Internet. El dispositivo informático puede funcionar con la capacidad de un servidor o una máquina de cliente en un entorno de red de cliente-servidor, o como una máquina homóloga en un entorno de red entre homólogos (o distribuido). El dispositivo informático puede ser un ordenador personal (PC), un ordenador de tipo tableta, un descodificador (STB), un asistente digital personal (PDA), un teléfono celular, un aparato de web, un servidor, un enrutador de red, conmutador o puente, o cualquier máquina que pueda ejecutar un conjunto de instrucciones (secuenciales o de otro modo) que especifican acciones que debe tomar la máquina.
Además, aunque sólo se ilustra un único dispositivo informático, también se interpretará que el término “dispositivo informático” incluye cualquier colección de máquinas (por ejemplo, ordenadores) que ejecutan, de manera individual o conjunta, un conjunto (o múltiples conjuntos) de instrucciones para realizar una cualquiera o más de las metodologías comentadas en el presente documento.
El ejemplo de dispositivo 400 informático incluye un dispositivo 402 de procesamiento, una memoria 404 principal (por ejemplo, memoria de sólo lectura (ROM), memoria de tipo flash, memoria de acceso aleatorio dinámica (DRAM) tal como DRAM síncrona (SDRAM) o DRAM de tipo Rambus (RDRAM), etc.), una memoria 406 estática (por ejemplo, memoria de tipo flash, memoria de acceso aleatorio estática (SRAM), etc.), y una memoria secundaria (por ejemplo, un dispositivo 418 de almacenamiento de datos), que se comunican entre sí a través de un bus 430.
El dispositivo 402 de procesamiento representa uno o más procesadores de propósito general tales como un microprocesador, unidad central de procesamiento o similar. Más particularmente, el dispositivo 402 de procesamiento puede ser un microprocesador de ordenador de conjunto de instrucciones complejas (CISC), microprocesador de ordenador de conjunto de instrucciones reducidas (RISC), microprocesador de palabras de instrucciones muy largas (VLIW), procesador que implementa otros conjuntos de instrucciones o procesadores que implementan una combinación de conjuntos de instrucciones. El dispositivo 402 de procesamiento también puede ser uno o más dispositivos de procesamiento de propósito especial tales como un circuito integrado específico de aplicación (ASIC), una matriz de compuertas programable en el campo (FPGA), un procesador de señales digitales (DSP), procesador de red o similar. El dispositivo 402 de procesamiento está configurado para ejecutar la lógica de procesamiento (instrucciones 422) para realizar las operaciones y etapas comentadas en el presente documento. El dispositivo 400 informático puede incluir además un dispositivo 408 de interfaz de red. El dispositivo 400 informático también puede incluir una unidad 410 de visualización de vídeo (por ejemplo, un elemento de visualización de cristal líquido (LCD) o un tubo de rayos catódicos (CRT)), un dispositivo 412 de entrada alfanumérico (por ejemplo, un teclado o pantalla táctil), un dispositivo 414 de control de cursor (por ejemplo, un ratón o pantalla táctil) y un dispositivo 416 de audio (por ejemplo, un altavoz).
El dispositivo 418 de almacenamiento de datos puede incluir uno o más medios 428 de almacenamiento legibles por máquina (o, más específicamente, uno o más medios de almacenamiento legibles por ordenador no transitorios) en los que están almacenados uno o más conjuntos 422 de instrucciones que implementan una cualquiera o más de las metodologías o funciones descritas en el presente documento. Las instrucciones 422 también pueden residir, completa o al menos parcialmente, dentro de la memoria 404 principal y/o dentro del dispositivo 402 de procesamiento durante la ejecución de las mismas por el sistema 400 informático, constituyendo además la memoria 404 principal y el dispositivo 402 de procesamiento medios de almacenamiento legibles por ordenador.
Los diversos métodos descritos anteriormente pueden implementarse mediante un programa informático. El programa informático puede incluir código informático dispuesto para indicar a un ordenador que realice las funciones de uno o más de los diversos métodos descritos anteriormente. El programa informático y/o el código para realizar tales métodos puede proporcionarse a un aparato, tal como un ordenador, en uno o más medios legibles por ordenador o, más generalmente, un producto de programa informático. Los medios legibles por ordenador pueden ser transitorios o no transitorios. El uno o más medios legibles por ordenador pueden ser, por ejemplo, un sistema electrónico, magnético, óptico, electromagnético, de infrarrojos o de semiconductor, o un medio de propagación para la transmisión de datos, por ejemplo para descargar el código a través de Internet. Alternativamente, el uno o más medios legibles por ordenador pueden adoptar la forma de uno o más medios legibles por ordenador físicos tales como semiconductor o memoria de estado sólido, una cinta magnética, un disquete informático extraíble, una memoria de acceso aleatorio (RAM), una memoria de sólo lectura (ROM), un disco magnético rígido y un disco óptico, tal como un CD-ROM, CD-R/W o DVD.
En una implementación, los módulos, componentes y otras características descritas en el presente documento pueden implementarse como componentes diferenciados o integrarse en la funcionalidad de componentes de hardware tales como ASICS, FPGA, DSP o dispositivos similares.
Un “componente de hardware” es un componente físico tangible (por ejemplo, no transitorio) (por ejemplo, un conjunto de uno o más procesadores) que puede realizar determinadas operaciones y puede estar configurado o dispuesto de una determinada manera física. Un componente de hardware puede incluir una lógica o conjunto de circuitos dedicado que está configurado de manera permanente para realizar determinadas operaciones. Un componente de hardware puede ser o incluir un procesador de propósito especial, tal como una matriz de compuertas programable en el campo (FPGA) o un ASIC. Un componente de hardware también puede incluir un conjunto de circuitos o lógica programable que está temporalmente configurado mediante software para realizar determinadas operaciones.
Por consiguiente, debe entenderse que la expresión “componente de hardware” abarca una entidad tangible que puede estar físicamente construida, permanentemente configurada (por ejemplo, cableada) o temporalmente configurada (por ejemplo, programada) para funcionar de una determinada manera o realizar determinadas operaciones descritas en el presente documento.
Además, los módulos y componentes pueden implementarse como firmware o conjunto de circuitos funcional dentro de dispositivos de hardware. Además, los módulos y componentes pueden implementarse en cualquier combinación de dispositivos de hardware y componentes de software, o únicamente en software (por ejemplo, código almacenado o implementado de otro modo en un medio legible por máquina o en un medio de transmisión).
A menos que se mencione específicamente lo contrario, tal como resulta evidente a partir de la siguiente discusión, se aprecia que, a lo largo de toda la descripción, las discusiones que usan términos tales como “recibir”, “determinar”, “obtener”, “enviar”, “implementar” o similares, se refieren a las acciones y procedimientos de un sistema informático, o dispositivo informático electrónico similar, que manipula y transforma datos representados como cantidades físicas (electrónicas) dentro de los registros y memorias del sistema informático para dar otros datos representados de manera similar como cantidades físicas dentro de las memorias o registros de sistema informático u otros dispositivos de almacenamiento, transmisión o visualización de información de este tipo.
Debe entenderse que se pretende que la descripción anterior sea ilustrativa y no restrictiva. Muchas otras implementaciones resultarán evidentes para los expertos en la técnica tras leer y entender la descripción anterior. Aunque la presente divulgación se ha descrito con referencia a ejemplos de implementación específicos, se reconocerá que la divulgación no se limita a las implementaciones descritas, sino que puede ponerse en práctica con modificación y alteración dentro del espíritu y alcance de las reivindicaciones adjuntas. Por consiguiente, la memoria descriptiva y los dibujos deben considerarse en un sentido ilustrativo en vez de un sentido restrictivo. Por tanto, el alcance de la divulgación debe determinarse con referencia a las reivindicaciones adjuntas, junto con el alcance completo de equivalentes al que tienen derecho tales reivindicaciones.

Claims (1)

  1. REIVINDICACIONES
    Método de proporcionar un par de claves asimétricas para proteger datos secretos para un dispositivo, estando el dispositivo configurado para ejecutar aplicaciones que usan los datos secretos y estando acoplado en comunicación a un primer módulo de hardware, comprendiendo el método:
    generar el par de claves asimétricas para el dispositivo; comprendiendo el par de claves asimétricas una clave pública de dispositivo y una clave privada de dispositivo;
    firmar digitalmente la clave pública de dispositivo en el dispositivo para generar un primer certificado; enviar el primer certificado al primer módulo de hardware;
    verificar el primer certificado en el primer módulo de hardware, y, en respuesta a que la verificación sea satisfactoria, firmar digitalmente la clave pública de dispositivo en el primer módulo de hardware para generar un segundo certificado;
    enviar el segundo certificado al dispositivo;
    verificar el segundo certificado en el dispositivo; y
    en respuesta a que la verificación sea satisfactoria, hacer que el primer y segundo certificados estén disponibles para su almacenamiento y/o uso adicional.
    Método según la reivindicación 1, en el que el primer certificado se firma mediante una clave de firma de dispositivo, y el segundo certificado se firma mediante una clave de firma de primer módulo de hardware, para su autenticación respectiva; y opcionalmente en el que el primer y segundo certificados se almacenan en una memoria del dispositivo o se envían a un sistema de gestión de claves para su almacenamiento y uso adicional.
    Método según la reivindicación 1 ó 2, proporcionando el método además una clave simétrica para proteger datos secretos para el dispositivo, estando el dispositivo acoplado en comunicación a un segundo módulo de hardware, comprendiendo el método:
    recibir en el segundo módulo de hardware el primer y/o segundo certificados para verificar la clave pública de dispositivo del par de claves asimétricas asociado con el dispositivo respectivo;
    recibir en el segundo módulo de hardware una clave de aprovisionamiento a partir de una fuente segura, estando la fuente segura acoplada en comunicación con el dispositivo y el segundo módulo de hardware; y, si la verificación del primer y/o segundo certificados es satisfactoria, comprendiendo el método además: enviar la clave de aprovisionamiento cifrada con la clave pública de dispositivo al dispositivo, en el que la clave de aprovisionamiento se descifra usando una clave privada de dispositivo del par de claves asimétricas;
    enviar una primera semilla secreta firmada mediante la clave de aprovisionamiento desde la fuente externa hasta el dispositivo, en el que la primera semilla secreta se verifica y descifra usando las claves de aprovisionamiento descifradas; y
    calcular la clave simétrica usando una función de derivación de claves secretas en el dispositivo, comprendiendo las entradas de la función de derivación de claves secretas la primera semilla secreta, la clave pública de dispositivo y una segunda semilla secreta, en el que la segunda semilla secreta se obtiene, se almacena o se genera en el dispositivo.
    Método según la reivindicación 3, que comprende además,
    firmar la clave de aprovisionamiento con una clave de firma de aprovisionamiento en la fuente segura; enviar la clave de aprovisionamiento firmada al segundo módulo de hardware usando una clave de segundo módulo de hardware;
    en el segundo módulo de hardware, extraer la clave de aprovisionamiento firmada y cifrar la clave de aprovisionamiento firmada con la clave pública de dispositivo;
    en el dispositivo, descifrar la clave de aprovisionamiento con la clave privada de dispositivo del par de claves asimétricas y verificar la firma de la clave de aprovisionamiento usando una clave pública asociada con la clave de aprovisionamiento que está disponible para el dispositivo.
    5. Método según la reivindicación 3 ó 4, en el que la primera semilla secreta es un identificador único para el dispositivo y la segunda semilla secreta es una clave global secreta única para el dispositivo y opcionalmente generada dentro de un módulo de confianza dentro del dispositivo.
    6. Método según una cualquiera de las reivindicaciones anteriores, en el que el dispositivo es un sistema en un chip, SoC, que comprende un módulo de confianza para la generación y/o almacenamiento de una o más claves de cifrado y/o semillas secretas para una o más funciones de derivación de claves, y en el que el primer y/o segundo módulos de hardware son módulos de seguridad de hardware en un entorno o instalación de fabricación.
    7. Método según una cualquiera de las reivindicaciones anteriores, en el que el método comprende además incluir de manera segura claves de cifrado asimétricas y simétricas asociadas con el dispositivo en un sistema de gestión de claves, estando el dispositivo acoplado en comunicación con el sistema de gestión de claves, comprendiendo el método las etapas de:
    obtener un primer y/o segundo certificados para verificar la clave pública de dispositivo del par de claves asimétricas asociado con el dispositivo respectivo, en el que el primer y segundo certificados para la clave pública de dispositivo se obtienen usando el método según cualquiera según una cualquiera de las reivindicaciones 1 ó 2;
    verificar la clave pública de dispositivo en el sistema de gestión de claves;
    obtener la primera semilla secreta, originándose la primera semilla secreta a partir de la fuente segura y comprendiendo un identificador único para el dispositivo, y obtener la segunda semilla secreta, estando la segunda semilla secreta asociada de manera única con el dispositivo, en el que las etapas de obtener la primera y segunda semillas secretas se implementan usando el método según una cualquiera de las reivindicaciones 3 a 7;
    ejecutar una función de derivación de claves secretas asociada con el dispositivo respectivo en el sistema de gestión de claves para calcular una clave simétrica, en el que las entradas de la función de derivación de claves incluyen: la primera semilla secreta a partir de la fuente segura, segunda semilla secreta a partir del dispositivo y la clave pública de dispositivo extraída;
    almacenar la clave simétrica calculada y la clave pública de dispositivo del par de claves asimétricas en el sistema de gestión de claves.
    8. Dispositivo configurado para ejecutar aplicaciones que usan datos secretos, estando el dispositivo acoplado en comunicación a al menos un módulo de seguridad de hardware, comprendiendo el dispositivo una unidad de memoria, una o más unidades de transceptor y una o más unidades de procesamiento, estando la una o más unidades de procesamiento configuradas para:
    generar un par de claves asimétricas para el dispositivo y almacenar el par de claves en una memoria; comprendiendo el par de claves una clave pública de dispositivo y una clave privada de dispositivo firmar digitalmente la clave pública de dispositivo en el dispositivo para generar un primer certificado; transmitir el primer certificado a un primer módulo de hardware para su verificación;
    si la verificación del primer certificado es satisfactoria, recibir un segundo certificado a partir del primer módulo de hardware, firmándose el segundo certificado digitalmente por el primer módulo de hardware; verificar el segundo certificado en el dispositivo; y
    en respuesta a que la verificación del segundo certificado sea satisfactoria, proporcionar el primer y segundo certificados para su almacenamiento y/o uso adicional.
    9. Dispositivo según la reivindicación 8, estando las unidades de procesamiento configuradas además para:
    recibir, a partir de un segundo módulo de hardware, una clave de aprovisionamiento cifrada con la clave pública de dispositivo del par de claves asimétricas que se ha verificado usando un primer y/o segundo certificados, en el que la clave de aprovisionamiento se descifra usando la clave privada de dispositivo del par de claves asimétricas asociado con el dispositivo y;
    recibir, a partir de una fuente externa segura, una primera semilla secreta firmada mediante la clave de aprovisionamiento, en el que la primera semilla secreta se verifica y descifra usando las claves de aprovisionamiento descifradas; y
    calcular una clave o claves de cifrado simétricas usando una función de derivación de claves secretas, comprendiendo las entradas de la función de derivación de claves secretas la primera semilla secreta, la clave pública de dispositivo y una segunda semilla secreta; en el que la segunda semilla secreta se obtiene, se almacena o se genera en el dispositivo.
    Módulo de seguridad de hardware acoplado en comunicación a un dispositivo para el aprovisionamiento de un par de claves asimétricas para proteger datos secretos para el dispositivo, estando el dispositivo configurado para ejecutar aplicaciones que usan los datos secretos, comprendiendo el módulo de seguridad de hardware uno o más módulos de procesamiento configurados para:
    recibir un primer certificado a partir del dispositivo, generándose el primer certificado firmando digitalmente una clave pública de dispositivo en el dispositivo de un par de claves de cifrado asimétricas del dispositivo; verificar el primer certificado en el módulo de seguridad de hardware;
    si la verificación es satisfactoria, firmar digitalmente la clave pública de dispositivo mediante el módulo de seguridad de hardware para generar un segundo certificado; y
    transmitir el segundo certificado al dispositivo para su verificación.
    Módulo de seguridad de hardware según la reivindicación 10, acoplado además en comunicación al dispositivo para el aprovisionamiento de una clave simétrica para proteger datos secretos para el dispositivo, estando el uno o más módulos de procesamiento del módulo de seguridad de hardware configurados para:
    verificar la clave pública de dispositivo del par de claves asimétricas asociado con el dispositivo usando un primer y/o segundo certificados del par de claves asimétricas para el dispositivo respectivo;
    recibir una clave de aprovisionamiento a partir de una fuente segura, estando la fuente segura acoplada en comunicación con el dispositivo y el módulo de seguridad de hardware; y, en respuesta a una verificación satisfactoria del primer y/o segundo certificados, transmitir la clave de aprovisionamiento cifrada con la clave pública de dispositivo al dispositivo para su descifrado, en el que la clave de aprovisionamiento permite que el dispositivo use una primera semilla secreta recibida a partir de la fuente segura para generar la clave simétrica con una segunda semilla secreta almacenada o generada por el dispositivo.
ES18807672T 2017-12-29 2018-11-30 Aprovisionamiento seguro de claves Active ES2962485T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP17306984.0A EP3506560A1 (en) 2017-12-29 2017-12-29 Secure provisioning of keys
PCT/EP2018/083213 WO2019129459A1 (en) 2017-12-29 2018-11-30 Secure provisioning of keys

Publications (1)

Publication Number Publication Date
ES2962485T3 true ES2962485T3 (es) 2024-03-19

Family

ID=61598829

Family Applications (1)

Application Number Title Priority Date Filing Date
ES18807672T Active ES2962485T3 (es) 2017-12-29 2018-11-30 Aprovisionamiento seguro de claves

Country Status (4)

Country Link
US (1) US20200344075A1 (es)
EP (2) EP3506560A1 (es)
ES (1) ES2962485T3 (es)
WO (1) WO2019129459A1 (es)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3506552A1 (en) * 2017-12-29 2019-07-03 Nagravision S.A. Secure installation of application keys
US20210374724A1 (en) * 2018-10-19 2021-12-02 Bell Identification B.V. Secure digital wallet processing system
US11245680B2 (en) * 2019-03-01 2022-02-08 Analog Devices, Inc. Garbled circuit for device authentication
US11416639B2 (en) 2020-06-29 2022-08-16 Nuvoton Technology Corporation PQA unlock
EP3952201A1 (en) * 2020-08-07 2022-02-09 ABB Schweiz AG Trust establishment through certificate management in open platform communications unified architecture
US11574079B2 (en) * 2021-05-27 2023-02-07 Nuvoton Technology Corporation Multi-stage provisioning of secret data
US20230205895A1 (en) * 2021-12-29 2023-06-29 Arm Limited Methods and apparatus for provisioning a device

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1215386C (zh) * 2002-04-26 2005-08-17 St微电子公司 根据量子软计算控制过程或处理数据的方法和硬件体系结构
US20050154889A1 (en) * 2004-01-08 2005-07-14 International Business Machines Corporation Method and system for a flexible lightweight public-key-based mechanism for the GSS protocol
US7787627B2 (en) * 2005-11-30 2010-08-31 Intel Corporation Methods and apparatus for providing a key management system for wireless communication networks
SG10201603367TA (en) * 2016-04-27 2017-11-29 Huawei Int Pte Ltd Method and system for authentication with asymmetric key

Also Published As

Publication number Publication date
WO2019129459A1 (en) 2019-07-04
EP3732821C0 (en) 2023-11-08
EP3732821B1 (en) 2023-11-08
US20200344075A1 (en) 2020-10-29
EP3732821A1 (en) 2020-11-04
EP3506560A1 (en) 2019-07-03

Similar Documents

Publication Publication Date Title
ES2962485T3 (es) Aprovisionamiento seguro de claves
US11323276B2 (en) Mutual authentication of confidential communication
ES2872101T3 (es) Gestión de claves distribuidas para entornos de ejecución confiables
US11533297B2 (en) Secure communication channel with token renewal mechanism
US10461933B2 (en) Methods for secure credential provisioning
US9912485B2 (en) Method and apparatus for embedding secret information in digital certificates
US9467430B2 (en) Device, method, and system for secure trust anchor provisioning and protection using tamper-resistant hardware
US11063753B2 (en) Secure distribution of device key sets over a network
EP3497878B1 (en) Apparatus and methods for distributed certificate enrollment
US20150242614A1 (en) Provisioning of security credentials
EP2711859B1 (en) Secured computing system with asynchronous authentication
TW201502844A (zh) 用於遠端證明之系統、方法及裝置
CN106027503A (zh) 一种基于tpm的云存储数据加密方法
KR20130056199A (ko) 보안 키 생성
KR20160076731A (ko) 스마트 그리드 기기 인증 방법
GB2577122A (en) Establishing a protected communication channel
KR20200101020A (ko) 컨소시엄 블록체인 참가 노드 간의 인증 방안
ES2552707B1 (es) Método y dispositivo para control de acceso de escritura a un recurso en una red RELOAD
EP3769462A1 (en) Secure distribution of device key sets over a network