[go: up one dir, main page]

ES2976046T3 - Método para diversificar de manera segura una aplicación genérica almacenada en un procesador seguro de un terminal - Google Patents

Método para diversificar de manera segura una aplicación genérica almacenada en un procesador seguro de un terminal Download PDF

Info

Publication number
ES2976046T3
ES2976046T3 ES20833917T ES20833917T ES2976046T3 ES 2976046 T3 ES2976046 T3 ES 2976046T3 ES 20833917 T ES20833917 T ES 20833917T ES 20833917 T ES20833917 T ES 20833917T ES 2976046 T3 ES2976046 T3 ES 2976046T3
Authority
ES
Spain
Prior art keywords
message
application
app
challenge
msg1
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
ES20833917T
Other languages
English (en)
Inventor
Guillaume Phan
Emmanuel Lepavec
Nicolas Vienne
Olivier Poncelet
Evangelos Spyropoulos
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 France SAS
Original Assignee
Thales DIS France SAS
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 SAS filed Critical Thales DIS France SAS
Application granted granted Critical
Publication of ES2976046T3 publication Critical patent/ES2976046T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/45—Structures or tools for the administration of authentication
    • 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/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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3265—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Computer And Data Communications (AREA)

Abstract

La invención propone un método para diversificar de forma segura una aplicación genérica (11) almacenada en un procesador seguro (10) de un terminal, comprendiendo el método: - Generar a petición de un gestor una aplicación (12) alojada en un procesador de aplicaciones del terminal. , a nivel de un servidor distante (13), un desafío de servidor (SERVER.CHALLENGE); - enviar el desafío del servidor a la aplicación (11); - Generar un primer mensaje (MSG1) en la aplicación (11), siendo el primer mensaje (MSG1) función del desafío del servidor, un desafío de la aplicación y un identificador único (APP.ID) de la aplicación (11); - Enviar el primer mensaje (MSG1) a un servicio de raíz de confianza (112) alojado en un procesador seguro (10) del terminal, generando el servicio de raíz de confianza (112) una atestación del primer mensaje, el atestación que garantiza que el primer mensaje (MSG1) no ha sido modificado y se origina en el procesador seguro (10); - transmitir la atestación del primer mensaje (MSG1) al servidor distante (13) en un mensaje de solicitud de habilitación; - A nivel del servidor distante (13): Verificar que la atestación del primer mensaje (MSG1) ha sido proporcionada por el servicio Raíz de Confianza (112); Verificar que el primer mensaje (MSG1) contenga el desafío del servidor; Devolver a la aplicación (11) una carga útil de habilitación que contiene un segundo mensaje (MSG2) y un certificado de clave pública que contiene la clave pública que se utilizará para verificar la firma del segundo mensaje, estando el segundo mensaje compuesto por el desafío de la aplicación; - A nivel de la aplicación (11), al recibir la carga útil de habilitación: Verificar el certificado de clave pública; Verificar la firma del segundo mensaje; Verificando que el segundo mensaje (MSG2) contenga el desafío de la aplicación. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Método para diversificar de manera segura una aplicación genérica almacenada en un procesador seguro de un terminal
La presente invención se refiere a telecomunicaciones y, en particular, a una habilitación remota y segura de una aplicación genérica (no diversificada) (por ejemplo, UICC integrada, también denominada iUICC, o eUICC para UICC incrustada) cargada y que se ejecuta en una parte de un procesador seguro (SP) de una parte de sistema en chip (SoC) de un dispositivo conectado (es decir, con acceso a la red). El dispositivo (o terminal) es, por ejemplo, un teléfono inteligente, una PDA, un dispositivo de loT, que tiene una conexión a una red celular (2G, 3G, 4G o 5G). Por lo tanto, la aplicación puede ser una aplicación que permita que un elemento seguro se conecte a la red de un MNO (operador de red móvil) con todas las credenciales requeridas. Los documentos WO 2017/082966, US 2011/099367 y US 2015/359026 forman parte de los antecedentes tecnológicos.
Se considera un SoC que incluye un procesador de aplicaciones (AP) principal y un procesador seguro (SP). El AP y el SP están aislados entre sí y solo se comunican entre sí usando protocolos específicos de hardware y seguros. Dicho aislamiento proporciona una mayor seguridad a aplicaciones sensibles cargadas y que se ejecutan en el SP. Las aplicaciones cargadas en el SP se conocen como aplicaciones de SP.
En tal configuración, una aplicación de SP (SP.APP en lo sucesivo) necesita desplegarse en un número de dispositivos/SP, esta SP.APP se carga inicialmente en una forma genérica no diversificada. Es decir, el mismo software y datos (que no contienen ningún identificador o credencial diversificado) se cargan inicialmente en todos los dispositivos/SP.
El problema a resolver es la diversificación segura de identificadores y credenciales para esta forma genérica (no diversificada) de SP.APP cargada en un dispositivo/SP particular, para que posteriormente pueda comunicarse con cada instancia diversificada SP.APP de manera segura.
Un ejemplo típico es la diversificación segura de una iUICC en un SP en un teléfono/dispositivo móvil. El entorno requerido para la invención se refina adicionalmente de la siguiente manera:
- El AP puede ejecutar aplicaciones de alto nivel y proporcionarles acceso a servicios de alto nivel, tales como acceso a la red. En particular, el SoC incluye un módem que permite al AP acceder a la red. Por otro lado, las aplicaciones de SP que se ejecutan en el SP no pueden acceder directamente a la red.
- El SP proporciona un servicio de confianza de raíz (ROT) a las aplicaciones de SP, es decir, un servicio de firma capaz de generar una atestación criptográfica para un mensaje arbitrario (proporcionado por la SP.APP), tal atestación garantiza que el mensaje no se ha modificado y se origina a partir de un SP/dispositivo particular.
- El SP también proporciona un servicio de ID a aplicaciones de SP, que puede usarse para recuperar un SP.ID, es decir, un identificador único unido al SP (es decir, un identificador único del SP en sí o algún fragmento de datos que solo puede ser proporcionado por este SP y ningún otro SP), o algunos datos que permitan generar dicho identificador (unido al SP) o un identificador universalmente único (es decir, independiente del SP). Si no es universalmente único, SP.ID puede ser o puede permitir generar un identificador único dentro del rango de SP fabricado por un marcador de SP dado. El servicio de ID se describe por separado por motivos de claridad, pero en realidad puede incorporarse por el servicio de ROT (por ejemplo, SP.ID podría recuperarse de una atestación generada por el servicio de ROT).
- La aplicación de SP se ha cargado en el SP de manera segura, es decir, la operación de carga ha sido autorizada y garantiza la integridad y el origen de la aplicación de SP, y la aplicación de SP (SP.APP) es un software genuino y autorizado. La invención propone un método para diversificar de forma segura una aplicación genérica almacenada en un procesador seguro de un terminal, comprendiendo el método:
- Generar en la solicitud de una aplicación de administrador alojada en un procesador de aplicaciones del terminal, al nivel de un servidor distante, un desafío de servidor;
- Enviar el desafío de servidor a la aplicación;
- Generar un primer mensaje en la aplicación, siendo el primer mensaje función del desafío de servidor, un desafío de aplicación y un identificador único de la aplicación;
- Enviar el primer mensaje a un servicio de raíz de confianza alojado en un procesador seguro del terminal, generando el servicio de confianza una atestación del primer mensaje, garantizando la atestación que el primer mensaje no se ha modificado y se origina a partir del procesador seguro;
- Transmitir la atestación del primer mensaje al servidor distante en un mensaje de solicitud de habilitación;
- A nivel del servidor distante:
o Verificar que la atestación del primer mensaje ha sido proporcionada por el servicio de raíz de confianza; o Verificar que el primer mensaje contiene el desafío del servidor;
o Devolver a la aplicación una carga útil de habilitación que contiene un segundo mensaje y un certificado de clave pública que contiene la clave pública que se usará para verificar una firma del segundo mensaje, estando compuesto el segundo mensaje del desafío de aplicación;
- A nivel de la aplicación, cuando recibe la carga de habilitación:
o Verificar el certificado de clave pública;
o Verificar la firma del segundo mensaje;
o Verificar que el segundo mensaje contiene el desafío de aplicación. Preferentemente, la carga útil de habilitación también contiene datos adicionales y diversificados adecuadamente del servidor distante.
Ventajosamente, la aplicación es la aplicación de una iUICC.
En una realización preferida, el primer mensaje también contiene una clave pública de la aplicación y el segundo mensaje también contiene un certificado de la aplicación.
La invención está compuesta por los siguientes elementos, como se representa en las figuras 1, 2A y 2B que representan las diferentes etapas del método según la invención:
- Un procesador seguro SP 10 proporcionado por un fabricante de chips;
- Una aplicación genérica (no diversificada) SP.APP 11 almacenada en el SP 10;
- Una aplicación de gestor (MGR 12) que se ejecuta en el procesador de aplicaciones AP y que puede: - Comunicarse con la SP.APP 11,
- Retransmitir mensajes entre la SP.APP 11 y un servicio de habilitación remota/servidor web (RES 13); - El servidor RES 13 que es un servidor distante.
El SP 10, la SP.APP 11 y el MGR 12 son parte del terminal/dispositivo. Se supone que el RES 13 es propiedad de y lo gestiona el proveedor de la SP.APP 11.
El método según la invención comprende diferentes etapas que se explicarán a continuación, mediante el uso de PKI (Infraestructura de Clave Pública) para transmitir mensajes de forma segura y proporcionar integridad.
Como etapa preliminar, ilustrada en la figura 1, la SP.APP tiene que generar un identificador único de la APP.ID. Para hacerlo, la SP.APP 11 primero necesita obtener un identificador único del SP (etapa 100), que se realiza enviando una solicitud a un servicio de ID 101 gestionado por el SP 10. El servicio de ID devuelve el SP.ID que se usa en la etapa 102 por la SP.APP 11 para generar su propio identificador único de APP.ID.
La etapa 102 puede implementarse de varias maneras para garantizar la unicidad del APP.ID. Por ejemplo, si el SP.ID ya es un identificador único, el APP.ID podría ser simplemente igual a SP.ID. Sin embargo, esto no suele ser el caso por las siguientes razones:
- Por razones aplicativas, el APP.ID puede necesitar usar un formato/codificación específico.
- Si el SP.ID es solo único en el contexto de un marcador SP particular, el APP.ID puede incluir adicionalmente un identificador del marcador de SP (más tarde llamado SP.MK.ID) para convertirse en exclusivo independientemente del marcador de SP. Si no se recupera alguno del SP 10, este SP.MK.ID puede proporcionarse por la SP.APP 11 en sí misma. Sin embargo, se observa que la invención no excluye los casos de uso donde dicho SP.MK.ID no sería necesario, por ejemplo, si el SP.ID proporcionado por el servicio de ID 101 ya fuera universalmente único o si la solución aplicativa en general estuviera unida y restringida a un marcador de SP particular.
Entonces la SP.APP espera un desafío de servidor (etapa 103) que será generado más tarde por el RES 13. Las etapas 100 a 103 se pueden realizar la primera vez que se inicia la SP.APP 11.
Posteriormente o simultáneamente a las etapas 100 a 103, el MGR 12 puede solicitar un desafío de servidor de RES 13, que corresponde a la etapa 104 ilustrada en la figura 2A. En la etapa 105, el RES 13 genera un DESAFÍO DE SERVIDOR de desafío aleatorio y lo devuelve al MGR 12. En la etapa 106, el MGR 13 simplemente reenvía DESAFÍO.SERVIDOR a la SP.APP 11. En la etapa 107, la SP.APP 11, en espera, recibe DESAFÍO.SERVIDOR y ahora puede continuar a la etapa 108 donde genera un desafío aleatorio DESAFÍO.APP. En la etapa 110, la SP.APP 11 genera entonces un mensaje MSG1 que incluye la siguiente información:
- DESAFÍO.SERVIDOR;
- DESAFÍO.APP;
- APP.ID;
- Opcionalmente, los datos dependientes de la aplicación MSG1.DATOS que pueden usarse por el RES 13 para generar una carga útil de habilitación;
- Opcionalmente, la información complementaria (por ejemplo SP.MK.ID) que puede usar el RES 13 para forzar una política de aceptación de habilitación.
En la etapa 111, la SP.APP 11 luego obtiene una atestación para el MSG1, que se realiza enviando una solicitud a un servicio 112 de raíz de confianza (ROT) gestionado por el SP 10, ilustrado en la figura 2B.
El servicio de ROT 112 genera y devuelve una atestación que incluye el MSG1 y garantiza que el MSG1 no se ha modificado y se origina a partir del SP 10.
En la etapa 113, la SP.APP 11 simplemente reenvía la atestación al MGR 12. En la etapa 114, el MGR 12 envuelve la atestación en una solicitud de habilitación y la envía al RES 13. La solicitud de habilitación puede contener el SP.MK.ID si es necesario que el RES 13 detecte el formato de la atestación (que es específico del SP 10).
Tras la recepción de la solicitud de habilitación, el RES 13 entonces:
- Verifica en la etapa 115 que la atestación ha sido generada por el servicio de ROT 112 y extrae el MSG1 de la atestación.
o Se supone que el RES 13 conoce la clave pública requerida para verificar la atestación (por ejemplo, comunicada por el marcador de SP 10);
o Opcionalmente, el RES 13 aplica una política de aceptación de habilitación basada en información complementaria presente en el MSG1;
- Verifica en la etapa 116 que el MSG1 (extraído de la atestación) contiene el DESAFÍO.SERVIDOR previamente generado en la etapa 105;
- En la etapa 117 se prepara un mensaje MSG2 que se debe devolver a la SP.APP 11 y que incluye la siguiente información:
o DESAFÍO.APP (extraído del MSG1);
o Opcionalmente, los datos dependientes de la aplicación MSG2.DATOS, posiblemente dependientes del MSG 1. DATOS
- Genera en la etapa 118 una carga útil de habilitación que incluye el MSG2 y garantiza que el MSG2 no se ha modificado y se origina del RES 13. La carga útil de habilitación incluye la siguiente información:
o Un certificado de clave pública (CERT.RES) que contiene la clave pública (PK.RES) que se utilizará para verificar el MSG2.SIG (véase más abajo);
o MSG2;
o La firma MSG2.SIG del MSG2 generado usando SK.RES (equivalente de clave privada de PK.RES).
El RES 13 devuelve la carga útil de habilitación que se reenvía por el MGR 12 a la SP.APP 11 en la etapa 119. Tras la recepción de la carga útil de habilitación, la SP.APP 11 entonces:
- Verifica en la etapa 120 que el RES 13 ha generado la carga útil de habilitación. Para hacerlo, la SP.APP 11:
o Verifica el certificado de CERT.RES presente en la carga útil de habilitación. Se supone que la SP.APP 11 conoce la clave pública requerida para verificar el CERt .RES (incluido en la forma genérica no diversificada de SP.APP 11);
o Extrae la clave pública PK.RES del certificado CERT.RES;
o Verifica la firma MSG2.SIG utilizando la clave pública PK.RES;
- Verifica en la etapa 121 que el MSG2 contiene el DESAFÍO.APP previamente generado en la etapa 108.
Finalmente, en la etapa 122, la carga útil de habilitación se considera que se verifica con éxito y la SP.APP 11 puede usar o almacenar el MSG2.DATOS según sea necesario para completar su inicialización.
Después de la etapa 122, la SP.APP 11 tiene una identidad única APP.ID, ha notificado al RES de su existencia e identidad (APP.ID), y puede haber recibido datos adicionales de RES 13 (MSG2.DATOS), diversificados adecuadamente o que pueden haber sido utilizados por la SP.APP 11 para finalizar la diversificación de sus datos internos.
En una primera variante de la invención, se describe además los contenidos y fines de MSG1.DATOS y MSG2.<d>A<t>OS de la siguiente manera:
- SP.APP 11 genera un par de claves públicas, compuesto por una clave pública (PK.APP) y una clave privada (SK.APP). Se supone aquí que SP.a Pp 11 es capaz de realizar operaciones de criptografía de clave pública. SP.APP 11 incluye entonces la siguiente información en el MSG 1. DATOS:
o PK.APP
- Si RES 13 acepta el mensaje 117 de solicitud de habilitación, incluye la siguiente información en MSG2.DATOS:
o CERT.APP (retención de PK.APP, previamente extraída de MSG1.DATOS) y firmado por RES usando SK.APP.PROVEEDOR (equivalente de clave privada de PK.APP.PROVEEDOR). Este certificado se une a APP.ID (es decir, el APP ID aparece en el certificado).
o CERT.APP.PROVEEDOR que mantiene la clave pública (PK.APP.PROVEEDOR) que se utilizará para verificar CERT.APP. Se supone que este certificado estaba previamente firmado por una autoridad independiente (APP.RAÍZ) relevante para la solución aplicativa.
o Opcionalmente: información dependiente de la aplicación complementaria relevante para SP.APP 11
CERT.APP.PROVEEDOR y CERT.RES son independientes. CERT.RES se usa para asegurar el procedimiento de habilitación, mientras que CERT.APP.PROVEEDOR pertenece a la cadena de certificado usada por SP.APP 11 para autenticarse en sí misma a otras partes en la solución aplicativa.
Tras una verificación exitosa de la Carga útil de habilitación, SP.APP 11 puede almacenar CERT.APP.PROVEEDOR, CERT.APP y cualquier información complementaria proporcionada extraída de MSG2.DATOS según sea necesario.
Al final del procedimiento de habilitación (según esta primera variante), SP.APP 11 también tiene un par de claves públicas (PK.APP, SK.APP) certificado por APP.RAÍZ (es decir, una autoridad relevante para la solución aplicativa) y puede realizar operaciones tales como:
- Comunicar su identidad a otras partes en la solución aplicativa.
- Probar su identidad y/o firmar mensajes enviados a otras partes en la solución aplicativa, usando SK.APP, CERT.APP (unido a APP.ID) y CERT.APP.PROVEEDOR, es decir Sp .APP 11 puede firmar mensajes con SK.APP y otras partes pueden verificar tales firmas usando la cadena de certificado (CERT.APP.PROVEEDOR <-- CERT.APP).
Por lo tanto, en esta primera variante, SP.APP 11 también genera un par de claves (pública/privada). La clave pública y APP.ID se incluyen en el MSG1, entonces RES 13 genera un certificado para la clave pública y lo envía de vuelta a SP.APP 11 en el MSG2.
En una segunda variante de la invención construida sobre la primera variante, existen varias APP.RAÍZ y pueden estar involucradas en la solución aplicativa, en cuyo caso SP.APP 11 puede generar varios pares de claves públicas (PK.APP, SK.APP) y cada uno puede certificarse por una diferente APP.RAÍZ. En este caso, MSG1.DATOS incluiría varias PK.APP y para cada uno, un identificador (ID.RAÍZ) de la APP.RAÍZ que lo certificará. En este caso, MSG2.Datos incluiría varias cadenas de certificado (CERT.APP.PROVEEDOR <-- CERT.APP), una para cada PK.APP, suponiendo que el RES 13 también tiene un CERT.APP.PROVEEDOR para cada APP.RAÍZ indicado en MSG1.DATOS.
Al final del procedimiento de habilitación (según esta segunda variante), SP.APP 11 podrá usar cualquiera de sus pares de claves públicas (PK.APP, SK.APP) y cadenas de certificado relacionadas para comunicarse de forma segura con otras partes en la solución aplicativa.
Por lo tanto, en esta segunda variante, SP.APP genera múltiples pares de claves en lugar de solo uno.
En una tercera variante de la invención construida sobre la primera o la segunda variantes, la cadena de certificado de un CERT.APP a una APP.RAÍZ puede incluir más de dos certificados (es decir, no solo CERT.APP.PROVEEDOR <--CERT.APP), en cuyo caso cada cadena de certificado presente en MSG2.DATOS incluiría un número variable de certificados (es decir, CERT.APP.RAÍZ <-- ... ^ CERT.APP.PROVEEDOR<-- CERT.APP).
Por lo tanto, en esta tercera variante, RES 13 devuelve una cadena de certificados de longitud variable (mayor o igual a dos, en lugar de solo dos certificados: CERT.APP.PROVEEDOR y CERT.APP) para cada clave pública (es decir, caso de jerarquía multinivel).
En una cuarta variante de la invención, MSG2.DATOS incluye información adecuada para sugerir o forzar una APP.ID diferente para SP.APP. Esto significa que RES 13 devuelve una APP.ID alternativa que SP.APP 11 almacenará y usará en lugar de la generada en la etapa 102.
La invención proporciona una solución para la diversificación de una UICC integrada (iUICC) en un SP en un teléfono móvil. Los procedimientos tradicionales de diversificación, tales como los utilizados para la UICC o eUlCC, típicamente implican bases de datos y sistemas de gestión de claves (KMS) que almacenan secretos y secuencias de comandos que deben cargarse en las cartas producidas.
Una iUICC no puede personalizarse en un sitio de producción de la misma manera, porque debe cargarse en un SP, en sí mismo en un SoC, en un terminal que se monta en una fábrica OEM. Por lo tanto, la invención propone una solución para personalizar/diversificar la iUICC de forma remota.
Las ventajas de la invención es que (en caso de que una aplicación iUICC sea SP.APP 11) la iUICC genera sus propios secretos y credenciales para que el RES 13 no tenga que almacenar ningún secreto sobre los múltiples casos iUICC. Solo se requiere que el RES 13 certifique la clave o claves públicas de la iUICC.
La iUICC (SP.APP) genera su propia identidad (APP.ID) basada en la SP.ID. Incluso si al comienzo (antes de habilitar) la iUICC (SP.APP 11) no puede demostrar su identidad, esto todavía proporciona oportunidades para la identificación temprana.
La invención no solo proporciona una solución para la diversificación de una iUICC en un SP 10 en un teléfono móvil, si no que se generaliza en cualquier tipo de SP.APP y cualquier tipo de dispositivo loT que incluya un SP 10. De una manera determinada, también podría aplicarse a la diversificación de una eUICC o chip.

Claims (1)

  1. REIVINDICACIONES
    Un método para diversificar de forma segura una aplicación genérica (11) almacenada en un procesador seguro (10) de un terminal, comprendiendo dicho método:
    -Generar en la solicitud de una aplicación de gestor (12) alojado en un procesador de aplicaciones de dicho terminal, al nivel de un servidor distante (13), un desafío de servidor (DESAFÍO.SERVIDOR);
    -Enviar dicho desafío de servidor a dicha aplicación (11);
    -Generar un primer mensaje (MSG1) en dicha aplicación (11), siendo dicho primer mensaje (MSG1) función de dicho desafíoa de servidor, un desafío de aplicación y un identificador único (APP.iD) de dicha aplicación (11);
    -Enviar dicho primer mensaje (MSG1) a un servicio de raíz de confianza (112) alojado en un procesador seguro (10) de dicho terminal, dicho servicio de raíz de confianza (112) que genera una atestación de dicho primer mensaje, garantizando dicha atestación que dicho primer mensaje (MSG1) no se ha modificado y se origina a partir de dicho procesador seguro (10);
    -Transmitir dicha atestación de dicho primer mensaje (MSG1) a dicho servidor distante (13) en un mensaje de solicitud de habilitación;
    -A nivel de dicho servidor distante (13):
    oVerificar que dicha atestación de dicho primer mensaje (MSG1) ha sido proporcionada por dicho servicio de raíz de confianza (112);
    oVerificar que dicho primer mensaje (MSG1) contiene dicho desafío de servidor; oDevolver a dicha aplicación (11) una carga útil de habilitación que contiene un segundo mensaje (MSG2) y un certificado de clave pública que contiene la clave pública que se usará para verificar una firma de dicho segundo mensaje (MSG2), estando compuesto dicho segundo mensaje (MSG2) de dicho desafío de aplicación;
    -A nivel de dicha aplicación (11), cuando recibe dicha carga útil de habilitación:
    oVerificar dicho certificado de clave pública;
    oVerificar dicha firma de dicho segundo mensaje;
    oVerificar que dicho segundo mensaje (MSG2) contiene dicho desafío de aplicación.
    Un método según la reivindicación 1 en donde dicha carga útil de habilitación también contiene datos adicionales y diversificados adecuadamente de dicho servidor distante (13).
    Un método según las reivindicaciones 1 o 2 en donde dicha aplicación (11) es la aplicación de una iUlCC.
    Un método según cualquiera de las reivindicaciones 1 a 3 en donde dicho primer mensaje (MSG1) también contiene una clave pública (PK.APP) de dicha aplicación y en el que dicho segundo mensaje (MSG2) también contiene un certificado de dicha aplicación.
ES20833917T 2020-01-24 2020-12-23 Método para diversificar de manera segura una aplicación genérica almacenada en un procesador seguro de un terminal Active ES2976046T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP20305059.6A EP3855328A1 (en) 2020-01-24 2020-01-24 A method for securely diversifying a generic application stored in a secure processor of a terminal
PCT/EP2020/087805 WO2021148223A1 (en) 2020-01-24 2020-12-23 A method for securely diversifying a generic application stored in a secure processor of a terminal

Publications (1)

Publication Number Publication Date
ES2976046T3 true ES2976046T3 (es) 2024-07-22

Family

ID=70613725

Family Applications (1)

Application Number Title Priority Date Filing Date
ES20833917T Active ES2976046T3 (es) 2020-01-24 2020-12-23 Método para diversificar de manera segura una aplicación genérica almacenada en un procesador seguro de un terminal

Country Status (6)

Country Link
US (1) US12034870B2 (es)
EP (2) EP3855328A1 (es)
KR (1) KR20220132532A (es)
CN (1) CN114930325A (es)
ES (1) ES2976046T3 (es)
WO (1) WO2021148223A1 (es)

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8700893B2 (en) * 2009-10-28 2014-04-15 Microsoft Corporation Key certification in one round trip
US8661257B2 (en) * 2010-05-18 2014-02-25 Nokia Corporation Generic bootstrapping architecture usage with Web applications and Web pages
CN102594558B (zh) * 2012-01-19 2014-08-06 东北大学 一种可信计算环境的匿名数字证书系统及验证方法
WO2014097517A1 (ja) * 2012-12-21 2014-06-26 日本電気株式会社 無線通信システム、無線アクセスネットワークノード、通信デバイス、及びコアネットワークノード
CN105101194B (zh) * 2014-04-28 2019-07-09 华为技术有限公司 终端安全认证方法、装置及系统
US9363087B2 (en) * 2014-10-02 2016-06-07 Microsoft Technology Licensing, Inc. End-to-end security for hardware running verified software
US10164953B2 (en) * 2014-10-06 2018-12-25 Stmicroelectronics, Inc. Client accessible secure area in a mobile device security module
CN107924437A (zh) * 2015-06-17 2018-04-17 瑞典爱立信有限公司 用于使得能够实现凭证的安全供应的方法以及相关无线装置和服务器
WO2017082966A1 (en) * 2015-11-09 2017-05-18 Intel IP Corporation Integrated universal integrated circuit card on mobile computing environments
KR102293683B1 (ko) * 2017-02-13 2021-08-26 삼성전자 주식회사 eSIM 접근 제어 방법 및 장치
CN109495429B (zh) * 2017-09-12 2020-08-07 华为技术有限公司 一种鉴权方法、终端及服务器
CN109714168B (zh) * 2017-10-25 2022-05-27 阿里巴巴集团控股有限公司 可信远程证明方法、装置和系统
US11671265B2 (en) * 2019-10-25 2023-06-06 John A. Nix Secure configuration of a secondary platform bundle within a primary platform
US20220166620A1 (en) * 2020-11-20 2022-05-26 At&T Intellectual Property I, L.P. Access Network Facilitated Per Application Instance Secure Communication

Also Published As

Publication number Publication date
EP4094174B1 (en) 2024-02-07
US20230037536A1 (en) 2023-02-09
EP3855328A1 (en) 2021-07-28
US12034870B2 (en) 2024-07-09
CN114930325A (zh) 2022-08-19
WO2021148223A1 (en) 2021-07-29
EP4094174A1 (en) 2022-11-30
KR20220132532A (ko) 2022-09-30

Similar Documents

Publication Publication Date Title
TWI573473B (zh) 在無線通訊裝置中之電子用戶識別模組的安全儲存
EP2630816B1 (en) Authentication of access terminal identities in roaming networks
US10575168B2 (en) Method and electronic device for providing communication service
US8938621B2 (en) Computing device integrity protection
ES2452699T3 (es) Habilitación de un servicio en un equipo electrónico
JP2015133707A (ja) 機械対機械通信を可能にするための方法および機器
KR20100056566A (ko) 가상 가입자 식별 모듈
JP2014527379A (ja) 共有エフェメラル・キー・データのセットを用いるエクスチェンジを符号化するためのシステム及び方法
CN109417545A (zh) 用于下载网络接入简档的技术
WO2019041166A1 (zh) 更新固件的方法及相关装置
CN110073681B (zh) 用于物联网设备的方法、装置和计算机可读介质
JP7631284B2 (ja) 認証情報の設定を仲介するための装置及び方法
ES2833351T3 (es) Un método para sustituir al menos un parámetro de autenticación para autenticar un elemento de seguridad, y elemento de seguridad correspondiente
CN104660567A (zh) D2d终端接入认证方法、d2d终端及服务器
RU2016149497A (ru) Обеспечение безопасности связи с расширенными мультимедийными платформами
JP2015534408A (ja) 端末とリモートサーバとの間の、サードパーティのポータルを介した相互認証の方法
CN102752754A (zh) 用户识别卡锁数据进行安全认证的方法及移动终端
ES2976046T3 (es) Método para diversificar de manera segura una aplicación genérica almacenada en un procesador seguro de un terminal
US10700854B2 (en) Resource management in a cellular network
CN112805702A (zh) 仿冒app识别方法及装置
US12120522B2 (en) Provision of application level identity
US20230379717A1 (en) Credential handling of an iot safe applet
CN114124394A (zh) 一种认证凭证的生成、设备认证方法及装置
WO2017076257A1 (zh) 一种app认证的系统和方法
JP2008233965A (ja) 携帯端末装置とそのプログラム、及び、改竄防止システムと改竄防止方法