ES2917183T3 - Dispositivo móvil que tiene un entorno de ejecución seguro - Google Patents

Dispositivo móvil que tiene un entorno de ejecución seguro Download PDF

Info

Publication number
ES2917183T3
ES2917183T3 ES16816621T ES16816621T ES2917183T3 ES 2917183 T3 ES2917183 T3 ES 2917183T3 ES 16816621 T ES16816621 T ES 16816621T ES 16816621 T ES16816621 T ES 16816621T ES 2917183 T3 ES2917183 T3 ES 2917183T3
Authority
ES
Spain
Prior art keywords
secure
application
mobile
execution
mobile device
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
ES16816621T
Other languages
English (en)
Inventor
Min Hlaing
Abdul Aziz Sm Sohiduzzaman Sk
Sriram Ramachandran
Véronique Charpeignet
Patrice Angelini
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 ES2917183T3 publication Critical patent/ES2917183T3/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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • 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/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G06F21/14—Protecting executable software against software analysis or reverse engineering, e.g. by obfuscation
    • 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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action
    • 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/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/72—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in cryptographic circuits
    • G06F21/725—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in cryptographic circuits operating on a secure reference time value
    • 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/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/74—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • 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/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2149—Restricted operating environment
    • 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/04—Masking or blinding
    • 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/16—Obfuscation or hiding, e.g. involving white box

Abstract

Un mecanismo para asegurar una aplicación móvil para su ejecución en un dispositivo móvil. El mecanismo incluye la carga de una parte no controlada de la aplicación móvil desde un proveedor de aplicaciones no controlado al dispositivo móvil, operando un servidor de aprovisionamiento clave para generar claves asociadas con un entorno de ejecución confiable, transmitiendo las claves asociadas con el entorno de ejecución confiable a el dispositivo móvil y en un servidor de directorio clave, autenticar el dispositivo móvil, y al autenticar el dispositivo móvil, transmitir una parte confiable de la aplicación móvil que incluye una aplicación confiable al dispositivo móvil e instalar la parte confiable de la aplicación móvil en la aplicación móvil en la aplicación móvil Dispositivo móvil, proporcionando así un entorno de ejecución confiable. Se revelan otros sistemas y métodos. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Dispositivo móvil que tiene un entorno de ejecución seguro
Antecedentes de la invención
La presente invención se refiere de forma general a dispositivos móviles, y más especialmente a proporcionar dispositivos móviles con entornos de ejecución seguros y a la gestión de seguridad de aplicaciones seguras cargadas y ejecutadas en dispositivos móviles a lo largo de todo el ciclo de vida de tales aplicaciones seguras.
En la breve historia de los dispositivos de comunicaciones móviles, los dispositivos han evolucionado rápidamente de estar principalmente o incluso exclusivamente dedicados a la comunicación por teléfono móvil, a ser dispositivos multipropósito extraordinariamente potentes. Con desarrollos técnicos recientes, ahora es posible utilizar dispositivos móviles, por ejemplo, teléfonos móviles, para aplicaciones dispares tales como pago, billetes de transporte, programas de fidelización, acceso a cuentas bancarias, control de acceso físico a edificios u oficinas, etc. La comunicación de campo cercano es una tecnología que permite que estas nuevas funciones sean posibles en dispositivos móviles.
La seguridad es un criterio importante para muchas de estas funciones; por ejemplo, con frecuencia es un factor necesario para que un programa comercial exitoso pueda tener confianza de que las transacciones móviles son seguras y no son interceptadas fácilmente por atacantes que desean robar información tal como números de cuenta, patrones de transacciones, datos personales o claves criptográficas utilizadas en la realización de las transacciones seguras.
Los entornos de ejecución seguros (TEE), que son áreas seguras del procesador principal de un dispositivo móvil, proporcionan un mecanismo para una seguridad mejorada de aplicaciones que se ejecutan en determinados dispositivos móviles. Los entornos de ejecución seguros se implementan en hardware. Un TEE proporciona un entorno de ejecución aislado para aplicaciones seguras, proporcionando de este modo un mayor nivel de seguridad.
GlobalPlatform™ publica especificaciones para informática segura en tecnología de chip seguro, incluyendo proporcionar un entorno de ejecución seguro (TEE) estandarizado, que incluye un área segura en el procesador principal que asegura que los datos sensibles se almacenan, procesan y protegen en un entorno seguro. GlobalPlatform proporciona una interfaz de programa de aplicaciones (API) estándar a través de la cual los programas de aplicación, también conocidos como aplicaciones, pueden acceder a la funcionalidad segura proporcionada por las áreas de procesador seguras de entornos de ejecución seguros de GlobalPlatform.
Un ejemplo de una solución de TEE comercial es la tecnología ARM TrustZone de ARM Ltd., Cambridge, Reino Unido. Arm, TrustZone, http://www.arm.com/products/processors/technologies/trustzone/. La tecnología TrustZone está estrechamente integrada en procesadores al tiempo que extiende el entorno seguro fuera del procesador, por ejemplo, a periféricos tales como memoria y bloques criptográficos, para permitir la seguridad de todo el sistema en aplicaciones conscientes de seguridad, por ejemplo, en aplicaciones seguras.
El documento US-2012/159148 A1 describe un método para desplegar un administrador de servicios seguro local dentro de un elemento seguro de una tarjeta inteligente sin contacto. El elemento de seguridad es un componente de una tarjeta inteligente sin contacto incorporado en una tarjeta inteligente sin contacto. Se utiliza un algoritmo de criptografía asimétrica para generar pares de claves privadas-públicas. Las claves privadas se almacenan en el elemento seguro y son accesibles por una aplicación de software de administrador de servicios seguros (TSM) o una aplicación de software de control en el elemento de seguridad. Un ordenador no TSM con acceso a la clave pública cifra y luego transmite aplicaciones de datos o software de aplicación encriptadas al elemento seguro, donde la aplicación de software de TSM descifra e instala la aplicación de software al elemento seguro para fines de transacción. Sin embargo, esta descripción no se centra en el problema principal resuelto por esta invención.
A su vez, el documento US-2014/040622 A1 describe una aplicación de entorno seguro que está bloqueada y que es inaccesible, y que se desbloquea y se recupera utilizando un protocolo seguro y fácil de utilizar. Las aplicaciones que tienen entorno de seguridad están protegidas con una frase de contraseña. El almacén de claves de seguridad de la aplicación en el dispositivo se bloquea. El almacén de claves está cifrado con una clave de recuperación que únicamente está en forma cifrada en el dispositivo y no puede ser descifrada ni el usuario puede acceder a la misma. Como tal, el usuario no puede desbloquear el almacén de claves en el dispositivo y, por lo tanto, no puede desbloquear la aplicación. La aplicación puede desbloquearse utilizando un mecanismo de recuperación que es muy seguro en todas las comunicaciones entre el dispositivo móvil y el servidor del proveedor de servicios. Al mismo tiempo, el mecanismo de recuperación es fácil de llevar a cabo para el usuario final. Este documento no se centra en el problema abordado por la presente invención.
Desafortunadamente, muchos dispositivos móviles no están equipados con tecnología que implementa entornos de ejecución seguro en el hardware. Sin embargo, esto no disminuye la necesidad de proporcionar una funcionalidad de computación segura en la forma de un entorno de ejecución seguro en tales dispositivos más limitados. De lo contrario, las aplicaciones que se ejecutan en el dispositivo son vulnerables a malware y a una amplia gama de ataques posibles que pueden revelar información secreta del usuario del dispositivo o provocar pérdidas económicas al usuario o a los proveedores de servicios.
De lo anterior será evidente que sigue existiendo a necesidad de un método mejorado para proporcionar un mecanismo flexible, conveniente y potente para proporcionar un entorno de ejecución confiable seguro a dispositivos no provistos de áreas seguras implementadas en el hardware de sus procesadores. Idealmente, tal solución es compatible con las implementaciones de hardware de soluciones de entorno de ejecución seguro, por ejemplo, como proporciona GlobalPlatform, de modo que puedan desarrollarse aplicaciones que se ejecutan en entornos de ejecución seguros basados en procesador, así como en un mecanismo alternativo que no requiera tal hardware. De lo anterior será evidente que sigue existiendo la necesidad de un método mejorado para proporcionar las mejoras de seguridad acordes con un TEE implementado en hardware en dispositivos móviles que carezcan de las características de hardware específicas de un TEE de hardware.
Resumen de la invención
Los aspectos de las realizaciones de la presente invención se refieren en general a un método para hacer segura una aplicación móvil para su ejecución en un dispositivo móvil como se describe en las reivindicaciones adjuntas.
Breve descripción de los dibujos
La Figura 1 es un diagrama de bloques que ilustra un entorno en el que las aplicaciones móviles pueden cargarse en un dispositivo informático móvil desde una tienda de aplicaciones y utilizarse para acceder a servicios desde un proveedor de servicios (SP).
La Figura 2 es un esquema de alto nivel que ilustra más detalles de la red de la Figura 1.
La Figura 3 es un diagrama de bloques que ilustra componentes de hardware de un dispositivo móvil de las Figuras 1 y 2. La Figura 4 es un diagrama de bloques que ilustra módulos de software y datos ilustrativos que pueden almacenarse en la memoria del dispositivo móvil de las Figuras 1,2 y 3, incluyendo datos que deben protegerse de ataques. La Figura 5 es un diagrama de flujo que ilustra las etapas de cargar una aplicación móvil en un dispositivo móvil de las Figuras 1,2, 3 y 4, e inicializar aspectos de seguridad de tal aplicación móvil según una realización.
La Figura 6 es un diagrama de bloques que ilustra una realización de un dispositivo móvil con un entorno de ejecución seguro para aplicaciones móviles según una realización.
La Figura 7 es un diagrama de bloques que ilustra la relación entre aplicaciones seguras y áreas de almacenamiento seguras.
La Figura 8 es un diagrama de conexión que ilustra conexiones entre el dispositivo móvil en el que se carga una aplicación móvil y un concentrador de administrador de servicios seguro para realizar la diversificación de claves utilizada en el aprovisionamiento de la aplicación segura de la Figura 6.
La Figura 9 es un diagrama de secuencia de temporización que ilustra la diversificación de claves que permite el aprovisionamiento seguro de una aplicación segura.
La Figura 10 es un diagrama de flujo de datos que ilustra el uso de una clave de criptografía de caja blanca a partir del proceso ilustrado en la Figura 9 como una raíz segura para hacer seguro el almacenamiento para la aplicación segura de la Figura 6.
La Figura 11 es un diagrama de secuencia temporal que ilustra el cifrado de partes de la memoria de tiempo de ejecución para evitar la extracción maliciosa de datos de un volcado de memoria de tiempo de ejecución.
La Figura 12 es un diagrama de flujo que ilustra un mecanismo de una realización para detectar la manipulación de una aplicación segura.
La Figura 13 es un diagrama de flujo que ilustra un mecanismo para una realización en la que se utiliza un control de integridad de reloj para salvaguardar contra ataques de alteración de reloj.
La Figura 14 es un gráfico de una ruta de ejecución que ilustra una ejecución ilustrativa de una aplicación móvil en la que se inspeccionan tiempos de ejecución de bucles seleccionados de duración conocida para determinar la posible manipulación utilizando, por ejemplo, un depurador.
La Figura 15 es un diagrama de flujo que ilustra la aleatorización de la ruta de ejecución durante el tiempo de ejecución en el que se inspecciona la duración de ejecución aleatorizada para determinar una posible manipulación.
Descripción detallada de la invención
En la descripción detallada que sigue se hace referencia a los dibujos adjuntos, que muestran, a modo de ilustración, realizaciones específicas en las que puede ponerse en práctica la invención. Estas realizaciones se describen con detalle suficiente para permitir que los expertos en la técnica pongan en práctica la invención. Debe entenderse que, aunque sean diferentes, las diversas realizaciones de la invención no son necesariamente mutuamente excluyentes. Por ejemplo, una característica, estructura o rasgo particular descrito en la presente memoria en relación con una realización puede implementarse dentro de otras realizaciones. Por lo tanto, la descripción detallada que sigue no debe interpretarse en sentido limitativo, y el ámbito de la presente invención está definido por las reivindicaciones adjuntas interpretadas adecuadamente. En los dibujos, números similares se refieren a la misma o similar funcionalidad en las varias vistas.
En una realización de la invención, se presenta una tecnología que proporciona un mecanismo mediante el cual un entorno de ejecución seguro (TEE) en dispositivos móviles que no están provistos de mecanismos de hardware para soportar un entorno de ejecución seguro. El mecanismo presentado permite que se desarrollen aplicaciones seguras en las que pueden confiar usuarios finales y proveedores de servicios, al tiempo que se desarrollan contra interfaces de programador de aplicaciones de entornos de ejecución seguro soportados por hardware estándar, permitiendo de este modo una fácil portabilidad de aplicaciones desarrolladas para el mecanismo descrito en la presente memoria a tales entornos de ejecución seguros basados en hardware.
La Figura 1 es una ilustración esquemática de una red 111 que conecta un dispositivo móvil 103 a uno o más servidores 113 de proveedor de servicios remoto (SP). Los SP pueden proporcionar cualquiera de muchos servicios posibles. Ejemplos típicos incluyen banca en línea, comercio en línea, instrucción en línea, votación en línea, etc. Como un lector de este documento aprecia, en estos ejemplos, la seguridad de las transacciones es extremadamente importante.
Un usuario 101 opera un dispositivo móvil 103 para interactuar con uno de los servidores de SP 113 a través de la red. Dichas interacciones se realizan de forma ventajosa utilizando programas de aplicación de propósito especial descargados al dispositivo móvil 103. Dichos programas de aplicación de propósito especial, también conocidos como aplicaciones, proporcionan al usuario un entorno rico en características a través del cual el usuario 101 interactúa con aplicaciones de servidor. El usuario puede obtener las aplicaciones desde una tienda de aplicaciones 115. Ejemplos de tiendas 115 de aplicaciones incluyen la tienda de aplicaciones proporcionada por Apple Inc., Cupertino, California, EE. UU., para aplicaciones para los dispositivos IOS tales como iPhone y iPad, la tienda de aplicaciones Google Play proporcionada por Google Inc., Mountain View, California, EE. UU.
Como lector de este documento aprecia, para muchas transacciones en línea, la seguridad es de suma importancia. Por lo tanto, las propias aplicaciones deben ser seguras y los datos gestionados por las aplicaciones deben estar protegidos.
La Figura 2 es un esquema de alto nivel que ilustra más detalles de la red 111. Cada dispositivo móvil 103 de abonado comunica con los otros dispositivos de la red a través de un operador 117 de red móvil (MNO) del que el usuario 101 del dispositivo 103 es un abonado, por ejemplo, el MNO 117 puede ser el proveedor de servicios de telefonía móvil.
Si los proveedores de servicios (SP) individuales tuvieran que interactuar con cada operador de red móvil individual para la transmisión de mensajes, gestión de aplicaciones, provisión de servicios y provisión de mecanismos de seguridad, ya sea como parte de transacciones o como parte de despliegue, se produciría el caos. Por lo tanto, se introduce en GlobalPlatform un actor central conocido como administrador de servicios seguro (TSM) para gestionar la comunicación entre los SP y los MNO.
La Figura 2 proporciona un ejemplo de cómo el administrador de servicios seguro (TSM) podría desempeñar un papel junto con los proveedores de servicios (SP) y los operadores de red móvil (MNO). Cada TSM 1191, que es una combinación de hardware informático 119-C y software (no ilustrado), establece un enlace entre proveedores de servicios (SP) 115 y operadores de red móvil (MNO) 117. Cada TSM puede conectar múltiples MNO a múltiples SP. A la inversa, un SP 115 o MNO 117 dados pueden conectarse a un TSM 119 o a múltiples TSM 119.
La Figura 3 es una ilustración esquemática de un dispositivo móvil 103. El dispositivo móvil 103 puede incluir un procesador 201 conectado a través de un bus 202 a una memoria 203 de acceso aleatorio (RAM), a una memoria 204 de solo lectura (ROM) y a una memoria 205 no volátil (NVM). El dispositivo móvil 103 incluye además una interfaz de entrada/salida 207 para conectar el procesador 201, de nuevo de forma típica a través del bus 202, a una antena 211 mediante la cual el dispositivo móvil 103 puede estar conectado a un ordenador anfitrión o a otro dispositivo periférico.
La NVM 205 puede incluir programas informáticos 301 como se ilustra en la Figura 4. Aunque aquí se ilustra que los programas informáticos 301 están todos colocalizados en la NVM 205, en la práctica real no hay tal restricción, ya que los programas pueden estar repartidos en múltiples memorias e incluso instalarse temporalmente en la RAM 203. Además, el dispositivo móvil 103 puede incluir múltiples ROM o NVM. Los programas 301 incluyen programas de sistema operativo, así como programas de aplicación cargados en el dispositivo móvil 103. La NVM 205 de las aplicaciones móviles 215 también puede contener datos privados, tales como una clave privada 212 o una clave secreta compartida 209, almacenada ya sea en su forma básica o en cantidades derivadas, así como otra información 214 privada del usuario, tal como números de cuenta. A continuación en la memoria se describe un mecanismo para asegurar tales datos.
Los programas 301 del dispositivo móvil 103 pueden incluir un módulo 213 de criptografía, un módulo 217 de comunicaciones y el sistema operativo OS 219.
1 En esta descripción se hace referencia a varios elementos relacionados por n-E, n-C y n-S, respectivamente. E corresponde a entidad, C a ordenador y S a software. Por lo tanto, n-E es la entidad n-E, que opera el ordenador n-C, que se ejecuta según las instrucciones n-S. Por ejemplo, la entidad administrador 119-E de servicios seguro opera un ordenador 119-C que ejecuta un software de administración de servicios seguro. Para facilitar la descripción a veces se hace referencia a estos elementos mediante el número n, por ejemplo, TSM 119. A menos que el contexto deje claro otra cosa, esto debe tenerse en cuenta de forma típica como una referencia a los tres elementos que realizan sus papeles respectivos, por ejemplo, que el ordenador de administrador 119-C de servicios seguro realiza alguna acción ordenada por el software en el software 119-S de administrador de servicios seguro.
Como se ha explicado anteriormente en la presente memoria, las aplicaciones móviles 215 pueden utilizarse para operar en datos muy sensibles, por ejemplo, acceso de cuentas bancarias en línea, y proporcionar acceso a datos secretos. Para hacer segura tal aplicación móvil 215, se proporciona una tecnología que divide la aplicación móvil 215 en dos partes que se denominan en la presente memoria una parte no segura y otra parte segura. La parte no segura es esa parte que se ejecuta en un entorno de ejecución rico (REE) 501 proporcionado por la plataforma móvil, por ejemplo, iOS o Android. La parte no segura puede, por lo tanto, proporcionar una experiencia de usuario rica proporcionada por la plataforma móvil mientras que el desarrollador y el proveedor de servicios no tienen que preocuparse por fallos de seguridad de esa parte. En otras palabras, se considera seguro descargar la distribución de la parte no segura en un distribuidor que no es seguro, por ejemplo, una tienda de aplicaciones.
Por otro lado, las partes seguras son partes de una aplicación móvil 215 para las que se requieren medidas de seguridad. Esas partes se descargan desde un sitio seguro a través de un canal seguro y se hacen adicionalmente seguras mediante criptografía.
La Figura 5 es un diagrama de flujo que ilustra las etapas de carga e inicialización de una aplicación móvil segura 215 según una realización. Un usuario 101 (u otro actor tal como un operador de red móvil 117) instala una parte no segura en la NVM 205 de un dispositivo móvil 103, etapa 551. Como se ilustra en la Figura 5, la etapa inicial 551 puede consistir en descargar la parte no segura de una tienda de aplicaciones, por ejemplo, la App Store de Apple Inc. para dispositivos IOS o Google Play para dispositivos Android. Los detalles de las partes no seguras se tratan junto con la Figura 6 que sigue.
La carga y hacer segura la parte seguro de la aplicación móvil 215 puede hacerse en el primer uso de la aplicación móvil 215, etapa 553, de forma típica bajo la supervisión del módulo 509 de arranque. En una subetapa 555, la parte segura se descarga desde un servidor seguro conocido como servidor de aprovisionamiento, por ejemplo, el administrador 119 de servicios seguro, el proveedor de servicios o una entidad delegada del proveedor de servicios que puede autentificarse. Los detalles de los componentes de la parte segura de una aplicación móvil 215 se tratan junto con la Figura 6; debe señalarse, sin embargo, que cada aplicación móvil 215 consiste en una o más aplicaciones seguras 519.
La carga de las partes seguras y no seguras de la aplicación móvil 215 puede venir seguida de una etapa 557 que asocia estas partes de alguna forma, de modo que la invocaciones de método de la parte no segura llegue a las aplicaciones seguras 219 esperadas, y la etapa de asociación puede incluir una etapa de enlace.
El mecanismo para hacer seguras las partes seguras y los datos almacenados en el almacenamiento seguro asociado a las aplicaciones seguras 219 se basa en claves criptográficas. Durante la ejecución inicial de la aplicación móvil, se ejecuta una etapa 559 de aprovisionamiento de claves para obtener las claves necesarias. La etapa 559 de aprovisionamiento de claves se describe con mayor detalle a continuación, por ejemplo, junto con las Figuras 8 y 9.
A continuación, una vez cargadas las partes seguras y vinculadas con las partes no seguras, se ejecuta la aplicación móvil 215, etapa 561.
La Figura 6 ilustra una realización para proporcionar un entorno de ejecución seguro para aplicaciones móviles 215. A alto nivel, una aplicación móvil 215 consiste en dos partes, una parte no segura y una parte segura. La primera puede descargarse desde una fuente no segura y no necesita hacerse segura. La parte no segura incluye elementos de la aplicación móvil 215 que se ejecutan en un entorno 501 de ejecución rico (REE) proporcionado por el OS de la plataforma móvil, así como partes de infraestructura del entorno de ejecución seguro que no es necesario hacer seguras. Las partes seguras se cargan desde fuentes seguras, se aseguran criptográficamente y luego se ejecutan a través de un entorno 503 de ejecución de software (TEE soft) seguro que se incorpora a la aplicación móvil 215.
Un interpretador 515 de máquina virtual del OS de la plataforma móvil interpreta las instrucciones de las partes no seguras de la aplicación móvil 215.
Las plataformas móviles, tales como teléfonos inteligentes, proporcionan un entorno 501 de ejecución rico (REE). El REE 501 proporciona un repertorio extenso y flexible de funcionalidades desde las cuales pueden construirse aplicaciones móviles 215 potentes, atractivas y útiles. Cualquier usuario de un teléfono inteligente puede utilizar el teléfono para muchas cosas y se proporcionan interfaces de usuario inteligentes para la variedad de aplicaciones que un usuario puede utilizar diariamente. Aunque el REE proporciona un entorno de ejecución rico y potente, el REE deja el dispositivo vulnerable a ataques que pueden comprometer información sensible o valiosa del usuario del dispositivo. La tecnología descrita en la presente memoria proporciona un mecanismo mediante el cual estos riesgos de seguridad se mitigan introduciendo el TEE soft 503 en la aplicación móvil 215.
Las partes no seguras cargadas en la etapa 551 incluyen las partes de la aplicación móvil 215 que se ejecutan en el REE 501. Estos componentes 507 de REE incluyen una aplicación 505 de cliente, un BootStrapModule 509un proxy 511 de REE y una API 513 de aplicación segura. El BootStrapModule 509 contiene instrucciones para el aprovisionamiento de claves de orden desde el servidor de aprovisionamiento, la carga inicial de componentes seguros y la vinculación de los componentes. El proxy 511 de REE proporciona un mecanismo mediante el cual la aplicación móvil 215 puede interactuar con servidores externos, en particular, el administrador 119 de servicios seguro. El proxy 511 de REE interactúa además con un dominio 529 de seguridad de emisor (ISD). Puede administrarse un área de memoria asignada para aplicaciones de GlobalPlataform específicas en áreas seguras denominadas dominios de seguridad (SD). Los dominios de seguridad son representantes en el dispositivo de las autoridades fuera del dispositivo. Los dominios de seguridad (SD) soportan servicios de seguridad tales como manejo de claves, cifrado, descifrado, generación de firma digital y verificación para aplicaciones de las entidades asociadas con cada SD, por ejemplo, el administrador de servicios seguro. Cada SD se establece en nombre de un actor particular, por ejemplo, el emisor de la tarjeta (dominio de seguridad de emisor), un proveedor de aplicaciones (dominio de seguridad de aplicación) o un TSM (SD TSM). Los SD se establecen para aislar las claves y otra información segura de un actor a otros actores y viceversa.
Por lo tanto, el ISD, el dominio de seguridad de emisor, es un dominio de seguridad en el dispositivo móvil asociado al emisor del dispositivo y se utiliza para gestionar las claves asociadas al emisor. El ISD 529 puede descargarse al dispositivo móvil 103 durante la carga inicial de la aplicación móvil en la etapa 551.
El API 513 de aplicación segura puede ser, por ejemplo, una implementación de la API de cliente GlobalPlatform como se define en la Especificación API de Cliente TEE v1.0, gPD_SPE_007, GlobalPlatform, diciembre de 2011 (http://www.globalplatform.org/specificationsdevice.asp). La parte no segura de la aplicación móvil 215 accede a las partes seguras de la aplicación móvil 215 utilizando la API 513 de aplicación segura. En GlobalPlatform, se implementa un entorno de ejecución seguro (TEE) en hardware y se accede al mismo mediante aplicaciones utilizando la API de cliente GlobalPlatform. En una realización, la API 513 de aplicación segura se implementa para emular la API de cliente GlobalPlatform, de modo que una aplicación móvil 215 pueda escribirse una vez y ejecutarse en un dispositivo que tenga una implementación de hardware de un TEE o utilizando un TEE Soft 503 como se describe en la presente memoria. Por lo tanto, a través de la implementación de la API de aplicación segura 513 como una emulación de API de cliente GlobalPlatform, la aplicación móvil 215 se lleva fácilmente a un dispositivo que implementa la plataforma TEE de GlobalPlatform.
La API 513 de aplicación segura puede descargarse al dispositivo móvil 103 durante la carga inicial de la aplicación móvil en la etapa 551.
Por lo tanto, para superar los riesgos de seguridad del REE 501, se proporciona un entorno de ejecución seguro 503 de software (TEE Soft) en la aplicación móvil 215. La infraestructura de TEE Soft 503 se descarga con los componentes de REE 507 en la etapa 551 de descarga inicial.
Una máquina virtual 517 de TEE Soft (VM de TEE Soft) es un componente central del TEE Soft 503. La VM 517 de TEE Soft puede descargarse en la etapa 551 de descarga inicial. La VM 517 de TEE Soft proporciona una capa de emulación dentro de la aplicación móvil 215. La VM 517 de TEE Soft ejecuta un conjunto de instrucciones que es distinto del conjunto de instrucciones del entorno anfitrión por lo que no debe confundirse con el interpretador 515 de la máquina virtual nativa de la máquina. Los programas que se ejecutan en el TEE Soft 503, por ejemplo, las aplicaciones seguro, se compilan frente a este conjunto especial de instrucciones y los binarios de aplicación seguro 519 resultantes son interpretados por la VM 517 de TEE Soft.
Todo el sistema de TEE Soft 503 se ejecuta dentro de la VM 517 de TEE Soft para asegurar el aislamiento de ejecución desde la aplicación del cliente 505. Cuando la aplicación 505 del cliente solicita acceso a recursos protegidos por el TEE Soft 503, hace llamadas en la API 513 de aplicación segura. La VM 517 de TEE Soft recupera estas solicitudes y envía estas solicitudes a una aplicación segura 519 correspondiente.
Como se ha explicado anteriormente, la aplicación segura 519 se compila frente a un conjunto de instrucciones interpretable por la VM 517 de TEE Soft. Para acceder a la funcionalidad del TEE 503, la aplicación segura utiliza llamadas a un núcleo 527 de TEE a través de una API de 525 aplicación segura interna.
Una función importante de un entorno de ejecución seguro es aislar elementos de datos que deben estar protegidos de componentes no seguros, tales como la aplicación 505 del cliente. Por lo tanto, el TEE Soft 503 incluye almacenamiento seguro 523. Una parte del almacenamiento seguro 523 está asociada a cada aplicación segura 519. La Figura 7 es un diagrama de bloques que ilustra la relación entre aplicaciones seguras 519 y áreas 523 de almacenamiento seguro. Los datos almacenados en las áreas de almacenamiento seguro 523 se cifran con claves de cifrado de datos, por ejemplo, claves 701 de almacenamiento de aplicaciones seguras, respectivamente. Las claves 701 de almacenamiento de aplicaciones seguro se proporcionan a las aplicaciones seguras 519 como resultado de la etapa 559 de aprovisionamiento de claves, que se describe con mayor detalle a continuación.
Además, la personalización de la aplicación móvil 215 durante la etapa 559 de aprovisionamiento de claves incluye proporcionar al TEE Soft 503 material 521 de clave criptográfica personalizado que se utiliza para recibir de forma segura la aplicación segura 519 y para derivar la clave 701 de almacenamiento de aplicaciones seguro para cada aplicación segura 519.
La Figura 8 es un diagrama de conexión que ilustra conexiones entre el dispositivo móvil 103 en el que se carga una aplicación móvil y un concentrador 605 de administrador de servicios seguro para realizar la diversificación de claves utilizada en el aprovisionamiento de la aplicación segura de la Figura 6.
Un dispositivo móvil 103 está conectado a un administrador 119 de servicio seguro y como se representa en la Figura 2, la conexión puede ser a través de un operador 117 de red móvil.
El administrador 119 de servicio seguro puede estar colocalizado con varios servidores relacionados, por ejemplo, un servidor 601 de aprovisionamiento de claves y un servidor 603 de directorio de claves, en lo que podemos denominar en la presente memoria un concentrador 605 del administrador de servicios seguro. Estos componentes del concentrador 605 del administrador de servicios seguro cooperan con el dispositivo móvil 103 para proporcionar un TEE 503 de software para mejorar la seguridad de la aplicación móvil 215.
La función principal del servidor 601 de aprovisionamiento de claves es generar claves de criptografía de caja blanca y una clave de cifrado de Pin inicial (IPEK) que se utilizan en el aprovisionamiento de la aplicación segura 519 que corresponde a los componentes 507 de REE de la aplicación móvil 215. La criptografía de caja blanca se describe en S. Chow, P. Eisen, J. Johnson, P.C. Van Oorschot, “White-Box Cryptography and a AES Implementation” . En el 9° Annual Workshop on Selected Areas in Cryptography (SAC 2002), 15-16 de agosto de 2002, y en Jlilien Bringer, Herve Chabanne, y Emmanule Dottax, “White Box Cryptography: A New Attempt, Cryptology ePrint Archive” , Informe 2006/468, 2006.
Una clave privada, Pr.K.Kps, está asociada al servidor de aprovisionamiento de claves para permitirle firmar las claves que produce.
La función principal del servidor 603 de directorio de claves es mantener una base de datos de claves de IPEK asociada con identificadores únicos para el TEE 503 de software para una instanciación particular de la aplicación móvil 215 que se ejecuta en un dispositivo 103 particular. Este directorio, que puede ser una tabla de base de datos, se denomina en la presente memoria directorio 607 de claves. El identificador único para el TEE de software se denomina en la presente memoria ID de TEE y se describe con mayor detalle más adelante. Dado un ID de TEE particular, el servidor de directorio de claves puede proporcionar un cliente de interrogación, por ejemplo, el administrador 119 de servicios seguro, con el IPEK correspondiente.
La función principal del administrador 119 de servicios seguro en el contexto de proporcionar una aplicación segura 519 a un dispositivo móvil 103 es recibir desde el dispositivo móvil 103 una solicitud para la aplicación segura 519. La solicitud incluye un mecanismo mediante el cual el dispositivo móvil 103, específicamente la aplicación móvil 215, puede identificarse por sí misma y demostrar su autenticidad, es decir, proporcionando el ID de TEE y el IPEK. En una realización, como se describe en la presente memoria más adelante, el IPEK es proporcionado por el dispositivo móvil 103 en forma de un hash.
La Figura 9 es un diagrama de secuencia temporal que ilustra la diversificación de claves que permite el aprovisionamiento seguro de una aplicación segura. Como etapa preliminar (no mostrada) los componentes de REE de la aplicación móvil 215 se descargan al dispositivo móvil 103, por ejemplo, desde una tienda de aplicaciones.
Etapa 701. La aplicación móvil 215, específicamente los componentes de REE de la aplicación móvil 215, determina un identificador único (ID de TEE) para la aplicación móvil 215 como se ejecuta en el dispositivo móvil 103. En otras palabras, el ID de TEE depende tanto de la aplicación como del dispositivo. En una realización, el ID de TEE se calcula para depender de un identificador único universal (UUID) asignado a la aplicación y a una huella digital de dispositivo del dispositivo móvil 103. Estas pueden utilizarse, por ejemplo, para producir un hash o pueden concatenarse para crear el ID de TEE.
La huella del dispositivo puede calcularse como un hash, por ejemplo, SHA1, de una concatenación del identificador de aplicación, un identificador de OS único, la serie de radio del dispositivo móvil 103 y el IMEI del dispositivo móvil 103. El identificador de aplicación es el nombre del paquete de la aplicación (com.companyname.appname como ejemplo). El identificador de OS único es el parámetro proporcionado por el OS subyacente, tal como AndroidID para el OS Android y el UUID de volumen en iOS. La serie de radio es el número de serie de la unidad de radio en el dispositivo móvil. El IMEI, la identidad internacional del equipo de estación móvil, es un número único asignado a un dispositivo móvil y se especifica en la especificación 3GPP TS 23.003 del Proyecto de Colaboración de 3a Generación.
Etapa 703. El ID de TEE se transmite desde la aplicación móvil 215 al servidor 601de aprovisionamiento de claves.
Etapa 705. El servidor 601 de aprovisionamiento de claves recibe el ID de TEE desde la aplicación móvil 215 y genera una clave de cifrado de PIN inicial (IPEK) para asociarse con el ID de TEE y una clave de criptografía de caja blanca dinámica (clave de WBC, Km).
En una realización preferida, el IPEK es una clave de AES-256 aleatoria única generada por el servidor 601 de aprovisionamiento de claves. AES-256 es una versión de la norma de cifrado avanzada que utiliza claves de 256 bits.
La criptografía de caja blanca está fuera del ámbito de este documento. Sin embargo, los siguientes puntos destacados son útiles para comprender la tecnología presentada en la presente memoria. La criptografía de caja blanca se utiliza para proteger materiales distribuidos que se distribuyen más allá de la aplicación de control de acceso del distribuidor. Por ejemplo, en el presente contexto, un dispositivo móvil está más allá del control del emisor del dispositivo, así como más allá del control de los proveedores de servicios que pueden distribuir aplicaciones para su uso en el dispositivo móvil. La criptografía de caja blanca utiliza técnicas de ofuscación para proteger materiales distribuidos. En la Etapa 3 (705) se crea un binario de biblioteca de criptografía de caja blanca (WBC) para contener una clave de ES-128 aleatoria única que incluye un hash del ID de TEE, la clave de WBC que está oculta en un mensaje cifrado de AES utilizando técnicas de criptografía de caja blanca.
Etapa 707. La clave de IPEK se cifra mediante el servidor 601 de aprovisionamiento de claves utilizando la clave de WBC.
Etapa 709. El ID de TEE y la clave de IPEK se transmiten al servidor 603 de directorio de claves.
Etapa 711. El servidor 603 de directorio de claves asocia el ID de TEE y la clave de IPEK y los almacena en el directorio 607 de claves.
Etapa 713. En paralelo con el envío del ID de TEE y la clave de IPEK al servidor 603 de directorio de claves, el servidor 601 de aprovisionamiento de claves transmite la biblioteca de claves de WBC y la clave de IPEK cifrada a la aplicación móvil 215.
Etapa 715. La aplicación móvil 215 instala la biblioteca de WBC. Al instalar la biblioteca de WBC, la aplicación móvil 215 puede utilizar la biblioteca para descifrar información cifrada utilizando la biblioteca, en este caso la clave de IPEK.
Etapa 717. La aplicación móvil 215 utiliza la biblioteca de WBC para descifrar la clave de IPEK.
Etapa 719. La clave de IPEK se almacena en el dominio de seguridad del emisor (ISE) 529, que se descargó con los componentes no seguro de la aplicación móvil 215 en la etapa 551 de la Figura 5.
Etapa 723. La aplicación móvil 215 transmite el ID de TEE y un hash del TEEID utilizando el IPEK (HMAC (TEEID, IPEK) al administrador 605 de servicios seguro.
Etapa 725. El administrador 605 de servicios seguro reenvía el ID de TEE y el hash (HMAC (TEEID, IPEK) al servidor 603 de directorio de claves para la verificación de que hay una coincidencia. A medida que el servidor 603 de directorio de claves mantiene una tabla (etapa 711, anterior) de ID de TEE e IPEK correspondiente, el servidor 603 de directorio de claves puede verificar que el hash transmitido desde la aplicación móvil 215 al administrador 605 de servicios seguro en la etapa 723 coincide con el hash que se esperaría del IPEK correcto.
Etapa 727. Si el servidor 603 de directorio de claves ha confirmado la correspondencia del IPEK y el ID de TEE, el servidor 603 de directorio de claves transmite el IPEK de vuelta al administrador de servicios seguro.
Etapa 729. El administrador 605 de servicios seguro almacena el IPEK. El administrador 605 de servicios seguro también cifra el TA 519 utilizando una clave de sesión generada utilizando el IPEK.
Etapa 731. El administrador 605 de servicios seguro transmite el TA 519 cifrado a la aplicación móvil 215.
Etapa 733. La aplicación móvil 215 descifra el TA 519 utilizando la clave de sesión generada a partir del IPEK e instala el TA 519 en el TEE Soft 503.
De este modo, se ha completado la aplicación móvil 215 para incluir los componentes seguro, el material de la clave 521 y el TA 519, así como los componentes no seguro descargados inicialmente.
Como se señaló anteriormente, el almacenamiento seguro 523 correspondiente a cada aplicación segura 519 está protegido por una clave 701 de almacenamiento de aplicaciones segura (TA_SK). La Figura 10 es un diagrama de flujo que ilustra la generación de estas claves de almacenamiento.
Etapa 1001. Se genera un secreto aleatorio inicial (IRS) mediante la aplicación móvil 215.
Etapa 1003. El IRS se cifra mediante la aplicación móvil 215 utilizando la clave de criptografía de caja blanca dinámica (WBK) de la Figura 9, etapa 705, y proporcionada a la aplicación móvil en la etapa 713.
Etapa 1005. El IRS cifrado es almacenado por la aplicación móvil 215 en el almacenamiento de archivos gestionado por la aplicación móvil 215 en la NVM 205.
En una realización alternativa, las etapas 1001 a 1005 son sustituidos por la entrada de un PIN por parte del usuario. El PIN no se almacena. Más bien, como se explica en la etapa 1009 a continuación, debe volver a introducirse correctamente en cada ejecución, o la clave de almacenamiento calculada no coincidiría con la clave de almacenamiento utilizada en la primera ejecución.
Etapa 1007. En paralelo a las etapas 1001-1005, se calcula una huella digital de dispositivo (DFP) mediante la aplicación móvil 215. La DFP puede calcularse mediante el SHA1 de la concatenación del identificador de aplicación, el identificador de OS único, el número de serie de radio y el número IMEI del dispositivo.
Las etapas anteriores de la Figura 10 se llevan a cabo de forma ventajosa una vez con resultados, es decir, IRS y DFP encriptados, almacenados en la NVM 205. Las etapas que siguen son etapas de tiempo de ejecución que se utilizan cuando se accede al almacenamiento seguro.
Etapa 1009. En el tiempo de ejecución, para cada TA 519 la clave 701 de almacenamiento de TA (TA_SK) se calcula utilizando, por ejemplo, una función de obtención de claves basada en HMAC, especificada en RFC 5869 [ETF, HMAC-based Extract-and-Expand Key Derivation Function (http://tools.ietf.org/html/rfc5869)], acceso 3 de septiembre de 2015). Las entradas a la función HASH incluyen el IRS, dPP y UUID del TA 519. En la realización alternativa que utiliza un PIN de usuario, se solicita al usuario el PIN. El PIN originalmente introducido no se almacena. Sin embargo, como para cada ejecución, el PIN se utiliza para calcular la clave de almacenamiento de TA, debe especificarse el PIN correcto para que el TA_SK correcto se calcule en la etapa 1009 en ejecuciones posteriores.
Etapas 1013. Cuando una aplicación segura 519 busca acceso a su almacenamiento 523 correspondiente, la aplicación segura 701 utiliza su clave de almacenamiento TA_SK 701 para cifrar o descifrar contenidos almacenados o recuperados del almacenamiento seguro 523.
Una vulnerabilidad a atacar frente a una aplicación móvil 215 es atacar áreas de memoria en la RAM utilizada por la aplicación móvil 215 durante su ejecución. Un atacante puede realizar una descarga de memoria de datos almacenados en la RAM 203 durante la ejecución de la aplicación móvil 215 e intentar recuperar información sensible, tal como números de cuenta, claves criptográficas, identificadores personales, etc. de lo que se almacena en la RAM 203.
Para impedir dicho ataque, una realización del presente documento cifra partes de la memoria de tiempo de ejecución utilizada por la aplicación móvil 215 para evitar la recuperación de datos significativos de una memoria de tiempo de ejecución. La Figura 11 es un diagrama de secuencia temporal que ilustra esta realización. Cada aplicación segura 519 ejecutada dentro del TEE Soft 515 puede acceder a la RAM 203 desde un montón o pila. El montón o pila para cada TA 519 está separado y aislado del montón o pila de cualquier otra aplicación segura 519.
Como se ha explicado anteriormente en la presente memoria, junto con la Figura 9, por ejemplo, el servidor 601 de aprovisionamiento de claves genera una biblioteca de criptografía de caja blanca que incluye una clave de WBC, Km, y transmite esta biblioteca a la aplicación móvil 215, etapas 705 y 713. La aplicación móvil 215 instala la biblioteca de WBC en la etapa 715.
Según la presente realización, la aplicación segura cifra los datos almacenados en la RAM 203 cifrando los datos utilizando una clave de un solo uso (OTK):
E = Texto sin formato XOR OTK
La OTK se obtiene de la siguiente forma:
Etapa 1101: El TA 519 genera un nonce de forma que sea único para cada ejecución de la aplicación segura 519. En una realización preferida, la OTK se genera utilizando un nonce. Sin embargo, pueden utilizarse mecanismos alternativos para generar la OTK, en cuyo caso puede no ser necesario un nonce.
Etapa 1103: El TA 519 genera la clave de tiempo de ejecución Kr utilizando un generador de números aleatorios. En una realización preferida, la OTK se genera utilizando una clave aleatoria. Sin embargo, pueden utilizarse mecanismos alternativos para generar la OTK, en cuyo caso puede no ser necesaria una clave aleatoria Kr. En cada operación 1104 de almacenamiento, se genera la OTK asociada a la localización de memoria y la ejecución particular de la aplicación segura 519, se enmascaran para su almacenamiento, el texto sin formato que se almacenará en la RAM se cifra utilizando la OTK, y la OTK se descarta.
Etapa 1105: Se genera la OTK. En una realización preferida, la OTK se genera utilizando la fórmula:
OTK = ENC(mem_aaWr|| counter|| nonce, Kr)
Donde,
mem_addr es la dirección inicial de la(s) página(s) de memoria a cifrar,
counter es un contador que (1) se restablece en cada ejecución del TA 519 y se incrementa en cada acceso de memoria, y ENC es una función de cifrado en la que la concatenación dir_mem || counter || nonce se cifra utilizando la clave Kr Etapa 1107: La OTK se enmascara. En la realización preferida, el TA 519 enmascara la OTK utilizando la clave de WBC, Km :
OTKm = OTK XOR Km
[0001] Etapa 1109 y 1111: La OTK enmascarada, OTKm, se almacena en la RAM 203.
[0002] Etapa 1113: El texto sin formato de la cantidad a almacenar se enmascara utilizando la OTK:
E = Texto sin formato XOR OTK;
[0003] Etapas 1115 y 1117: la cantidad enmascarada E se transfiere y almacena en la RAM 203.
Etapa 1119: la OTK se descarta. Por lo tanto, la clave real (OTK) utilizada para enmascarar el texto sin formato antes del almacenamiento en la RAM nunca se retiene; en vez de ello, solo se retiene la versión enmascarada OTKm de la OTK y solo puede utilizarse si primero se desenmascara con éxito.
En cambio, en cada operación para leer un valor almacenado en la RAM 203, la OTK enmascarada se recupera y se desenmascara, la cantidad cifrada se descifra a texto sin formato y la OTK se descarta, etapa 1121.
Etapa 1123: el TA 519 recupera la OTK enmascarada, es decir, OTKm, almacenada previamente durante la operación de escritura.
Etapa 1125: la OTK se desenmascara de OTKm utilizando la clave de caja blanca Km.
Etapa 1127: se recupera la cantidad cifrada E.
Etapa 1129: la cantidad cifrada E se descifra en texto sin formato:
Texto sin formato = E XOR OTK
Etapa 1131: la OTK se descarta de nuevo.
Por lo tanto, se presenta una técnica que protege la RAM de tiempo de ejecución frente a ataques que utilizan descargas dememoria para diferenciar de forma malintencionada información confidencial de la aplicación móvil.
Una aplicación de software ejecutada por una máquina virtual es vulnerable a los ataques que se basan en la alteración de la instanciación estática o de tiempo de ejecución de la aplicación. Por ejemplo, un atacante puede inspeccionar la aplicación y alterar la aplicación en un intento de extraer contenidos protegidos manipulados por la aplicación y manipular el comportamiento de la aplicación para hacer que se revelen contenidos protegidos directamente o en una forma que haga posible que el atacante diferencie contenidos protegidos.
Para frustrar tales ataques, las realizaciones de la presente tecnología adoptan una o más de varias técnicas.
Una primera de tales técnicas, que se ilustra en la Figura 12, es proporcionar una Comprobación de integridad de la aplicación. Cuando se instala una aplicación segura 519 de la aplicación móvil 215 por primera vez en el TEE Soft 503, la máquina virtual de TEE Soft 517 calcula un valor de comparación, por ejemplo, un valor hash correspondiente a la aplicación segura 519, etapa 1201. El valor de comparación puede ser un código hash MAC HMAC-SHA256 calculado sobre el binario de la aplicación segura 519. El valor de comparación se almacena entonces en un contenedor seguro, por ejemplo, antes del binario de TA 519, etapa 1203.
En cada ejecución, cuando el TA 519 es cargado nuevamente por la máquina virtual de TEE Soft 517, se hace el mismo cálculo del valor de comparación sobre el binario y se compara con el valor de comparación almacenado calculado de la primera carga (denominado “valor actual” ), etapa 1205. En la etapa 1207 se toma la decisión de si los valores de comparación almacenados y actuales difieren. Si son iguales, la máquina virtual 517 de TEE Soft cargará y ejecutará el TA 519. Si difieren, la máquina virtual 517 de TEE Soft rechaza cargar el TA 519 y emite una acción correctiva, tal como notificar a un usuario, emisor o proveedor de servicios el ataque potencial, etapa 1209.
En otro posible ataque a una aplicación móvil 215, un atacante altera la tasa de reloj o realiza un cambio de tiempo; siendo este último de especial preocupación para aplicaciones de DRM de gestión de derechos digitales. Por lo tanto, para impedir tales ataques, en otra realización, puede verificarse el TA 519 de forma adicional o alternativa utilizando una técnica de verificación de integridad de reloj. La Figura 13 es un diagrama de flujo que ilustra la técnica de verificación de integridad de reloj.
Para impedir los ataques de alteración de reloj, tras la instalación de la parte segura de la aplicación móvil 215, por ejemplo, en la etapa 555 o complementaria a la etapa 555, se mide el tiempo de ejecución de determinadas instrucciones de la parte segura, por ejemplo, llamadas de la máquina virtual 517 de la TEE Soft 503 a funciones específicas en la API segura interna 525, etapa 1301, y se registran en un almacenamiento seguro 1303, etapa 1302. La verificación de reloj 1305 se realiza cuando se ejecuta la aplicación móvil 215. La máquina virtual 517 de TEE Soft se inicia, etapa 1307, cuando se ejecuta la aplicación móvil 215 y la máquina virtual 517 de TEE Soft mantiene un seguimiento del recuento de instrucciones, etapa 1309. Periódicamente, la máquina virtual 517 de TEE Soft realiza una comprobación 1311 de verificación de reloj, mediante la búsqueda del reloj del sistema, etapa 1313, calculando el tiempo esperado desde el recuento de instrucciones, etapa 1315 y comparando el reloj del sistema frente al tiempo esperado, etapa 1317. Si la diferencia entre el tiempo esperado y el tiempo del sistema está fuera de intervalo con respecto a algún umbral predeterminado, puede tomarse alguna acción correctiva, etapa 1319, por ejemplo, detener la aplicación móvil 215 o establecer restricciones en las que la aplicación móvil 215 pueda acceder a los recursos de hardware. En una realización, si un número n de instrucciones llevara una determinada cantidad de tiempo t y que, por lo tanto, después de haber sido rastreado a un recuento de instrucciones particular, por ejemplo, m*n, se esperaría que el tiempo de ejecución sería m*t. Una desviación más allá de un umbral particular desencadenaría la acción correctiva.
Los ataques contra una aplicación móvil 215 pueden incluir el uso de técnicas de depuración para inspeccionar funciones críticas de una aplicación móvil 215 mientras son ejecutadas por una máquina virtual 515. Las realizaciones de la tecnología descrita en la presente memoria también pueden incluir una técnica para impedir tales ataques de inspección que evitan las técnicas antidepuración mediante el análisis comparativo de bucles cortos y largos añadidos a una aplicación segura 519 durante la instalación de la aplicación segura 519. La Figura 14 es una secuencia temporal que ilustra el concepto.
La Figura 14 ilustra una parte crítica 1401, por ejemplo, el código de criptografía, de una aplicación segura 519 que debe protegerse del ataque. Se añade un segmento de código 1403 a la parte crítica 1401. La parte crítica contiene múltiples rutas posibles y varios bucles. Por ejemplo, un primer bucle 1405 contiene un bloque corto 1407 y un bloque largo 1409. Si la ruta de ejecución para el primer bucle es a través del bloque corto de 1407, la ejecución de un número dado de iteraciones del primer bucle 1405 será mucho más corta que si la ejecución pasa a través del bloque largo 1409. De forma similar, los bucles 2 a n 1411 pueden hacerse que se ejecuten a través del bloque corto 1413 o el bloque largo 1415, afectando nuevamente al tiempo de ejecución total.
Cualquiera que sea la ruta de ejecución utilizada para el segmento 1403 de código esta estará determinada por un número aleatorio que indicaría qué bloques deben ejecutarse y para cuántas iteraciones.
Conociendo los tiempos de ejecución de bloques para bloques cortos y largos y el número de iteraciones para cada bucle, es posible predecir el tiempo transcurrido esperado entre diversas localizaciones, puntos de inspección, en el código. Por ejemplo, si se espera que un bloque largo 1409 lleve t ciclos y un bloque corto, 0,5*t ciclos, y se sabe que se espera que el Bucle 1 1405 ejecute el bloque corto n veces, puede precedirse que la diferencia de tiempo entre el Tiempo b en el punto de inspección 1417 y el Tiempo a en el punto inicial 1419 debe ser n*t. Una desviación podría ser indicativa de que el código ha sido pausado por un depurador algún tiempo durante la ejecución del Bucle 1. De forma similar, con Tiempos c y d en los puntos de inspección 1421 y 1423, respectivamente.
La Figura 15 es un diagrama de flujo que ilustra el uso del mecanismo de la Figura 14 para aleatorizar la ruta de ejecución durante el tiempo de ejecución en el que se inspecciona la duración de ejecución aleatorizada para determinar una posible manipulación.
Etapa 1501: Se genera un número aleatorio, R, que se utiliza para determinar las rutas de ejecución a través del segmento 1403 de código ficticio añadido.
Etapa 1503: Se utiliza el número aleatorio R para determinar las rutas de ejecución. Por ejemplo, diferentes bits de R pueden indicar si se ejecutan bloques largos o bloques cortos para diversos bucles. Otros bits pueden indicar el número de iteraciones.
Etapa 1505: Las rutas de ejecución, incluyendo si se ejecutan bloques cortos o largos y el número de iteraciones, se utilizan para determinar los tiempos de llegada esperados en varios puntos de inspección identificados.
Etapa 1507: Los tiempos de llegada esperados, indexados por el punto de inspección, así como los tiempos de ejecución totales esperados, es decir, después de la ejecución del código crítico 1401 a proteger en el punto 1423 de inspección, se registran idealmente en alguna forma protegida tal como en el almacenamiento seguro 523.
Etapa 1509: Durante la ejecución de la aplicación segura:
Etapa 1511: En cada punto de inspección, el tiempo de llegada en el punto de inspección se compara con el tiempo de llegada esperado. Si hay una desviación más allá de un umbral predeterminado (Etapa 1513), se toma una acción correctiva (Etapa 1515).
Si no, es decir, si la desviación es aceptablemente pequeña, la ejecución continúa 1517, hasta que se encuentra el siguiente punto de inspección en la etapa 1511.
Por lo tanto, si en algún punto durante la ejecución de la aplicación segura se pausa la ejecución, por ejemplo, utilizando un depurador, los tiempos de ejecución se verían perturbados y los tiempos de llegada no coincidirían con los tiempos de llegada esperados. Eso desencadenaría una condición para la que se tomaría una acción correctiva.
Con fines ilustrativos se describe la tecnología presentada en la presente memoria como puede utilizarse en un dispositivo móvil 103. Sin embargo, la tecnología presentada es aplicable a cualquier dispositivo electrónico programable con una necesidad de un entorno de ejecución confiable seguro.
De lo anterior será evidente que se ha presentado una tecnología que mejora la seguridad de las aplicaciones que se ejecutan en un dispositivo móvil proporcionando mecanismos que introducen un entorno de ejecución seguro en aplicaciones móviles, de forma que pueda esperarse un mayor nivel seguridad cuando se utiliza un dispositivo móvil para ejecutar tales aplicaciones móviles para manipular datos confidenciales que se almacenan en el dispositivo móvil o a los que se accede en servidores remotos utilizando el dispositivo móvil. Estas mejoras se logran de forma robusta, flexible y económica, que no requiere modificación del hardware del dispositivo móvil, sino que mejora la seguridad asociada con el funcionamiento del hardware del dispositivo móvil.
Aunque se han descrito e ilustrado realizaciones específicas de la invención, la invención no se limitará a las formas o disposiciones específicas de las partes descritas e ilustradas. La invención está limitada únicamente por las reivindicaciones.

Claims (1)

  1. REIVINDICACIONES
    Método para hacer segura una aplicación móvil (215) para su ejecución en un dispositivo móvil (103), que comprende:
    - dividir la aplicación móvil (215) en una parte no segura y una parte segura, consistiendo la parte segura en una o más aplicaciones seguras (519),
    - descargar un entorno (503) de ejecución seguro de software y un entorno (501) de ejecución rico y cargar el entorno (503) de ejecución seguro de software en la aplicación móvil (215); - cargar la parte no segura de la aplicación móvil (215) desde un proveedor de aplicaciones no seguro al dispositivo móvil, en donde dicha parte no segura incluye elementos de la aplicación móvil que se ejecutan en un entorno (501) de ejecución rico de una plataforma móvil del dispositivo móvil y las piezas de infraestructura del entorno de ejecución segura que no es necesario hacer seguras,
    - cargar la parte segura de la aplicación móvil desde un proveedor de aplicaciones segura al dispositivo móvil, en donde dicha parte segura se ejecuta en el entorno (503) de ejecución seguro de software de la aplicación móvil,
    - asociar y unir la parte no segura a la parte segura, de modo que las invocaciones de la parte no segura llegan a la parte segura,
    - una vez que la parte segura se ha cargado y enlazado con la parte no segura, se ejecuta la aplicación móvil (215),
    - durante la ejecución inicial de la aplicación móvil, ejecutar un mecanismo (601) de aprovisionamiento de claves para proporcionar material de claves criptográficas personalizadas al entorno de ejecución seguro de software para hacer segura la parte segura y hacer seguros algunos datos almacenados en almacenamiento seguro asociado con las aplicaciones seguras (519).
    Método para hacer segura la aplicación móvil (215) para su ejecución en el dispositivo móvil según la reivindicación anterior, en donde la carga de la parte segura de la aplicación móvil en el dispositivo móvil comprende las siguientes etapas:
    la aplicación móvil genera un ID de entorno de ejecución seguro, ID de TEE, a partir de un identificador de la aplicación móvil y una huella digital de dispositivo del dispositivo móvil; dicha generación de entorno de ejecución segura, ID de TEE, es transmitida por la aplicación móvil (215) a un servidor (603) de aprovisionamiento de claves;
    operar el servidor (603) de aprovisionamiento de claves para generar claves a asociar al ID de entorno de ejecución seguro TEE y transmitir a un director de claves el ID de de entorno de ejecución seguro TEE y las claves generadas y, al dispositivo móvil, las claves generadas; estando configurado el proveedor de aplicaciones seguro para recibir el ID de TEE y un hash del ID de TEE calculado a partir de las claves generadas enviadas por el dispositivo móvil y para autentificar el dispositivo móvil a través del servidor director de claves;
    tras la autentificación exitosa del dispositivo móvil (103), operar el proveedor de aplicaciones segura para transmitir la parte segura de la aplicación móvil (215) que incluye una aplicación segura al dispositivo móvil (103); y
    estando configurado el dispositivo móvil (103) para instalar la parte segura de la aplicación móvil en el dispositivo móvil.
    Método para hacer segura la aplicación móvil (215) para su ejecución en el dispositivo móvil (103) según las reivindicaciones anteriores, en donde la parte no segura de la aplicación móvil comprende:
    una aplicación (505) de cliente ejecutable en el entorno de ejecución rico del dispositivo móvil (501); y
    un interpretador (515) de aplicaciones seguro para un conjunto de instrucciones en el que pueden implementarse aplicaciones seguras.
    Método para hacer segura la aplicación móvil (215) para su ejecución en el dispositivo móvil (103) según las reivindicaciones anteriores, en donde la aplicación segura se implementa en el conjunto de instrucciones interpretables por el interpretador (515) de aplicaciones seguro.
    Método para hacer segura la aplicación móvil (215) para su ejecución en el dispositivo móvil (103) según las reivindicaciones anteriores, en donde el material de claves criptográficas comprende una clave de cuadro blanco “clave WBC” y una clave de cifrado de pin inicial “ IPEK” y en donde el método comprende además cifrar la IPEK utilizando la clave WBC antes de transmitir las claves asociadas a la aplicación móvil al dispositivo móvil y en donde la versión cifrada de la IPEK se transmite al dispositivo móvil.
    6. Método para hacer segura la aplicación móvil (215) para su ejecución en el dispositivo móvil (103) según la reivindicación anterior, en donde la parte segura de la aplicación móvil se cifra con una clave de sesión generada a partir de la clave de cifrado de pin inicial “ IPEK” antes de la transmisión por el proveedor de servidor seguro al dispositivo móvil.
    7. Método para hacer segura la aplicación móvil (215) para su ejecución en el dispositivo móvil (103) según las reivindicaciones anteriores, en donde la parte no segura de la aplicación móvil incluye una interfaz de programa de aplicación que implementa una funcionalidad análoga a una implementación de hardware de un entorno de ejecución seguro.
    8. Método para hacer segura la aplicación móvil (215) para su ejecución en el dispositivo móvil (103) según cualquiera de las reivindicaciones anteriores, que comprende además:
    asociar la aplicación segura a un almacenamiento seguro confiable seguro; y
    almacenar un secreto aleatorio inicial en almacenamiento seguro del dispositivo móvil; y en cada acceso de datos en el almacenamiento seguro de la aplicación segura, generar una clave de datos de almacenamiento segura “TA_SK” para cifrar datos almacenados en el almacenamiento seguro asociado a la aplicación segura utilizando un “ IRS” , secreto aleatorio inicial, una huella del dispositivo y un identificador único “ UUID” para la aplicación segura.
    9. Método para hacer segura la aplicación móvil (215) para su ejecución en el dispositivo móvil (103) según las reivindicaciones anteriores, que comprende además:
    durante la ejecución de la aplicación segura:
    determinar una clave de tiempo de ejecución de un solo uso, Kr, asociada con esa ejecución particular de la aplicación segura;
    cuando se almacena una cantidad en la memoria de tiempo de ejecución utilizada por la aplicación segura durante esa ejecución particular de la aplicación segura, enmascarar la cantidad utilizando la clave de tiempo de ejecución de un solo uso, Kr; y
    cuando se recupera una cantidad de la memoria de tiempo de ejecución utilizada por la aplicación segura durante esa ejecución particular de la aplicación segura, desenmascarar la cantidad utilizando la clave de tiempo de ejecución de un solo uso, Kr.
    10. Método para hacer segura la aplicación móvil (215) para su ejecución en el dispositivo móvil (103) según las reivindicaciones anteriores, que comprende además:
    en una primera ejecución de la aplicación segura que tiene una forma compilada para la ejecución o interpretación, calcular un primer valor basado en la forma compilada de la aplicación segura y almacenar ese valor basándose en la forma compilada de la aplicación segura;
    en las ejecuciones posteriores de la aplicación segura, realizar el mismo cálculo basado en la forma compilada de la aplicación segura para producir un segundo valor basado en la forma compilada de la aplicación segura, comparar el primer y el segundo valor, y tomar una acción correctiva si el primer y segundo valor no son iguales.
    11. Método para hacer segura la aplicación móvil (215) para su ejecución en el dispositivo móvil (103) según las reivindicaciones anteriores, que comprende además defenderse frente a un potencial ataque de cambio de tiempo:
    determinando el tiempo de ejecución esperado para instrucciones particulares de la aplicación móvil en la primera ejecución del entorno de ejecución seguro por software;
    almacenar el tiempo de ejecución esperado para dichas determinadas instrucciones; durante la posterior ejecución del entorno de ejecución seguro por software:
    seguir el recuento de instrucciones;
    buscar periódicamente el reloj del sistema;
    calcular el tiempo de ejecución esperado desde el recuento de instrucciones actual; comparar el reloj del sistema actual con el tiempo de ejecución esperado;
    y
    si la comparación indica una desviación inaceptable, tomar una acción correctiva.
    12. Método para hacer segura la aplicación móvil (215) para su ejecución en el dispositivo móvil (103) según la reivindicación 11, en donde las instrucciones particulares son llamadas a funciones de una interfaz de programa de aplicación.
    13. Método para hacer segura la aplicación móvil (215) para su ejecución en el dispositivo móvil (103) según cualesquiera reivindicaciones anteriores, que comprende además:
    modificar una parte crítica de una aplicación segura con una sección de código ficticio que tiene una pluralidad de bucles cada uno de los cuales puede ejecutarse como un bucle corto o como un bucle largo;
    asignar una pluralidad de puntos de inspección en la sección de código ficticio y adyacente a dicha parte crítica de la aplicación segura;
    al ejecutar la aplicación segura, determinar una ruta de ejecución a través del código ficticio en donde la ruta de ejecución ejecuta un número definido de bucles cortos y largos; determinar los tiempos de llegada esperados para cada punto de inspección; y
    tras la llegada de un punto de inspección, comparar el tiempo de llegada real con el tiempo de llegada esperado y tomar una acción correctiva si la desviación entre el tiempo de llegada real y el tiempo de llegada esperado está más allá de un umbral predeterminado.
ES16816621T 2015-12-11 2016-12-09 Dispositivo móvil que tiene un entorno de ejecución seguro Active ES2917183T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP15306989.3A EP3179690A1 (en) 2015-12-11 2015-12-11 Mobile device having trusted execution environment
PCT/EP2016/080527 WO2017098024A1 (en) 2015-12-11 2016-12-09 Mobile device having trusted execution environment

Publications (1)

Publication Number Publication Date
ES2917183T3 true ES2917183T3 (es) 2022-07-07

Family

ID=55027656

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16816621T Active ES2917183T3 (es) 2015-12-11 2016-12-09 Dispositivo móvil que tiene un entorno de ejecución seguro

Country Status (8)

Country Link
US (1) US10878083B2 (es)
EP (2) EP3179690A1 (es)
JP (1) JP6888011B2 (es)
KR (1) KR102217501B1 (es)
CN (1) CN108781210B (es)
BR (1) BR112018011782A2 (es)
ES (1) ES2917183T3 (es)
WO (1) WO2017098024A1 (es)

Families Citing this family (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11424931B2 (en) * 2016-01-27 2022-08-23 Blackberry Limited Trusted execution environment
KR102604046B1 (ko) * 2016-11-28 2023-11-23 삼성전자주식회사 전자 기기의 프로그램 관리 방법 및 장치
US10972265B2 (en) * 2017-01-26 2021-04-06 Microsoft Technology Licensing, Llc Addressing a trusted execution environment
US10897360B2 (en) 2017-01-26 2021-01-19 Microsoft Technology Licensing, Llc Addressing a trusted execution environment using clean room provisioning
US10897459B2 (en) 2017-01-26 2021-01-19 Microsoft Technology Licensing, Llc Addressing a trusted execution environment using encryption key
US10528749B2 (en) * 2017-03-20 2020-01-07 Huawei Technologies Co., Ltd. Methods and apparatus for containerized secure computing resources
CN109218260B (zh) 2017-07-03 2020-11-06 深圳市中兴微电子技术有限公司 一种基于可信任环境的认证保护系统及方法
US11403540B2 (en) * 2017-08-11 2022-08-02 Google Llc On-device machine learning platform
CN109787943B (zh) * 2017-11-14 2022-02-22 华为技术有限公司 一种抵御拒绝服务攻击的方法及设备
US10872144B1 (en) * 2017-12-07 2020-12-22 Ent. Services Development Corporation Lp Systems and methods for secure processing of data streams having differing security level classifications
US10911236B2 (en) * 2017-12-13 2021-02-02 Paypal, Inc. Systems and methods updating cryptographic processes in white-box cryptography
US10922441B2 (en) * 2018-05-04 2021-02-16 Huawei Technologies Co., Ltd. Device and method for data security with a trusted execution environment
EP3830733A4 (en) * 2018-07-27 2022-04-27 BicDroid Inc. PERSONALIZED AND CRYPTOGRAPHICALLY SECURE ACCESS CONTROL IN A TRUSTED EXECUTION ENVIRONMENT
US11206130B2 (en) * 2018-07-31 2021-12-21 Nxp B.V. Customizing cryptographic keys between multiple hosts
US10908935B1 (en) * 2018-08-02 2021-02-02 Raytheon Company Estimation of guest clock value based on branch instruction count and average time between branch instructions for use in deterministic replay of execution
EP3608806A1 (en) * 2018-08-09 2020-02-12 Gemalto Sa Anti cloning for white box protected data
US11132440B2 (en) 2018-11-01 2021-09-28 Foundation Of Soongsil University-Industry Cooperation Hybrid trust execution environment based android security framework, android device equipped with the same and method of executing trust service in android device
CN113168476A (zh) 2018-11-30 2021-07-23 百可德罗德公司 操作系统中个性化密码学安全的访问控制
KR102137894B1 (ko) * 2018-12-18 2020-07-24 서울여자대학교 산학협력단 커널 무결성 검사 장치 및 방법
CN109739522B (zh) * 2019-01-03 2022-02-18 中国—东盟信息港股份有限公司 一种适用于eSIM应用的TEE OS适配系统
US11646870B2 (en) * 2019-01-23 2023-05-09 International Business Machines Corporation Securing mobile device by RAM-encryption
CN113614720A (zh) * 2019-03-13 2021-11-05 华为技术有限公司 一种动态配置可信应用程序访问控制的装置和方法
CN110543764B (zh) * 2019-09-11 2021-07-23 飞腾信息技术有限公司 片上系统内存防护方法、密码加速引擎及内存防护装置
US11416619B1 (en) 2019-09-24 2022-08-16 Sprint Communications Company L.P. Trusted boot-loader authentication
CN110855667B (zh) * 2019-11-14 2023-04-07 宁夏吉虎科技有限公司 一种区块链加密方法、装置及系统
CN111881467B (zh) * 2020-06-12 2022-10-28 海光信息技术股份有限公司 利用安全处理器保护文件的方法、装置、cpu和计算机设备
CN111740824B (zh) * 2020-07-17 2020-11-17 支付宝(杭州)信息技术有限公司 可信应用管理方法及装置
KR102390381B1 (ko) * 2020-11-25 2022-04-25 고려대학교 산학협력단 시뮬레이션 데이터 기반 웹 페이지 로드 시간 예측 장치, 방법 및 이를 수행하기 위한 프로그램을 기록한 기록매체
CN112506531A (zh) * 2020-12-11 2021-03-16 中国科学院信息工程研究所 软件安装方法、装置、电子设备和存储介质
FR3118223B1 (fr) * 2020-12-17 2023-11-17 Tages Methode d’association d’un programme logiciel executable avec une plateforme informatique
CN114021141A (zh) * 2021-10-29 2022-02-08 中国银联股份有限公司 一种电子设备、可信应用调用方法、装置、设备及介质
CN115017495B (zh) * 2021-11-09 2023-08-08 荣耀终端有限公司 定时校验方法、电子设备和可读存储介质
SE2250289A1 (en) * 2022-03-03 2023-09-04 Crunchfish Digital Cash Ab Preventing fraudulent use by cloning of a trusted application
CN114553603B (zh) * 2022-04-25 2022-07-29 南湖实验室 一种基于隐私计算的新型数据可信解密的方法
WO2024075929A1 (ko) * 2022-10-04 2024-04-11 삼성전자 주식회사 신뢰 실행 환경을 제공하기 위한 전자 장치

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030037237A1 (en) * 2001-04-09 2003-02-20 Jean-Paul Abgrall Systems and methods for computer device authentication
EP2060101B1 (en) * 2006-09-07 2018-02-07 Nokia Technologies Oy Managing information relating to secure module applications
US8352749B2 (en) * 2010-12-17 2013-01-08 Google Inc. Local trusted services manager for a contactless smart card
KR101744748B1 (ko) * 2011-01-05 2017-06-09 한국전자통신연구원 화이트박스 암호 테이블을 이용한 콘텐츠 보호 장치, 콘텐츠 암호화 및 복호화 장치
US20140040622A1 (en) * 2011-03-21 2014-02-06 Mocana Corporation Secure unlocking and recovery of a locked wrapped app on a mobile device
US9317689B2 (en) * 2012-06-15 2016-04-19 Visa International Service Association Method and apparatus for secure application execution
US11228427B2 (en) * 2014-02-11 2022-01-18 Ericsson Ab System and method for securing content keys delivered in manifest files
CN104134038B (zh) * 2014-07-31 2016-11-23 浪潮电子信息产业股份有限公司 一种基于虚拟平台的安全可信运行保护方法
US9871821B2 (en) * 2014-11-11 2018-01-16 Oracle International Corporation Securely operating a process using user-specific and device-specific security constraints
CN104765612B (zh) 2015-04-10 2018-05-08 武汉天喻信息产业股份有限公司 一种访问可信执行环境、可信应用的系统及方法
EP3086585B1 (en) * 2015-04-23 2019-12-11 Nxp B.V. Method and system for securing data communicated in a network
US10114958B2 (en) * 2015-06-16 2018-10-30 Microsoft Technology Licensing, Llc Protected regions
US10178164B2 (en) * 2015-08-31 2019-01-08 Visa International Service Association Secure binding of software application to communication device

Also Published As

Publication number Publication date
CN108781210B (zh) 2021-11-09
WO2017098024A1 (en) 2017-06-15
US20190005229A1 (en) 2019-01-03
BR112018011782A2 (pt) 2018-12-04
KR20180093038A (ko) 2018-08-20
JP2019505887A (ja) 2019-02-28
EP3179690A1 (en) 2017-06-14
EP3387813B1 (en) 2022-04-20
JP6888011B2 (ja) 2021-06-16
EP3387813A1 (en) 2018-10-17
US10878083B2 (en) 2020-12-29
CN108781210A (zh) 2018-11-09
KR102217501B1 (ko) 2021-02-18

Similar Documents

Publication Publication Date Title
ES2917183T3 (es) Dispositivo móvil que tiene un entorno de ejecución seguro
US10395012B2 (en) Media client device authentication using hardware root of trust
US11018847B2 (en) Device keys protection
Zhao et al. Providing root of trust for ARM TrustZone using on-chip SRAM
US8225110B2 (en) Cryptographic protection of usage restrictions in electronic devices
ES2904501T3 (es) Implementación de un almacenamiento seguro con protección de integridad
US10482252B2 (en) Method for protecting the confidentiality and integrity of firmware for an Internet of Things device
CN108429719B (zh) 密钥保护方法及装置
US20200252207A1 (en) Software encryption
CN109328352A (zh) 靶向安全软件部署
JP2007512787A (ja) トラステッド・モバイル・プラットフォーム・アーキテクチャ
WO2015042981A1 (zh) 加解密处理方法、装置和设备
CN108702353B (zh) 接收电子实体内的数据的方法及相关联的电子实体
EP3048553B1 (en) Method for distributing applets, and entities for distributing applets
Jung et al. A secure platform model based on ARM platform security architecture for IoT devices
Cooijmans et al. Secure key storage and secure computation in Android
JP6199712B2 (ja) 通信端末装置、通信端末関連付け方法、及びコンピュータプログラム
CN116050537A (zh) 联邦学习方法、装置、可读存储介质及电子设备
ES2770006T3 (es) Método para gestionar una aplicación
Ribeiro et al. DBStore: A TrustZone-backed Database Management System for Mobile Applications.
CN111651740A (zh) 一种面向分布式智能嵌入式系统的可信平台共享系统
CN114600102A (zh) 用于保护共享对象的装置和方法
JP2018026651A (ja) プログラムを保護する方法
Sitawarin iOS Security
Areno et al. Secure mobile authentication and device association with enhanced cryptographic engines