ES2963328T3 - Procedimiento para verificar la integridad de un código de aplicación, dispositivo y producto de programa informático correspondientes - Google Patents
Procedimiento para verificar la integridad de un código de aplicación, dispositivo y producto de programa informático correspondientes Download PDFInfo
- Publication number
- ES2963328T3 ES2963328T3 ES19180688T ES19180688T ES2963328T3 ES 2963328 T3 ES2963328 T3 ES 2963328T3 ES 19180688 T ES19180688 T ES 19180688T ES 19180688 T ES19180688 T ES 19180688T ES 2963328 T3 ES2963328 T3 ES 2963328T3
- Authority
- ES
- Spain
- Prior art keywords
- application
- fingerprint
- current
- code
- secure
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 153
- 238000004590 computer program Methods 0.000 title claims description 8
- 238000005457 optimization Methods 0.000 claims abstract description 83
- 230000008569 process Effects 0.000 claims abstract description 83
- 230000015654 memory Effects 0.000 claims abstract description 72
- 238000010200 validation analysis Methods 0.000 claims abstract description 16
- 238000009434 installation Methods 0.000 claims description 20
- 230000006870 function Effects 0.000 claims description 12
- 238000012795 verification Methods 0.000 claims description 5
- 230000005540 biological transmission Effects 0.000 claims description 3
- 239000000725 suspension Substances 0.000 claims description 3
- 238000004891 communication Methods 0.000 claims description 2
- 238000013475 authorization Methods 0.000 claims 2
- 238000001514 detection method Methods 0.000 claims 2
- 230000003213 activating effect Effects 0.000 claims 1
- 238000012545 processing Methods 0.000 abstract description 10
- 238000012986 modification Methods 0.000 description 12
- 230000004048 modification Effects 0.000 description 12
- 238000013459 approach Methods 0.000 description 6
- 230000000903 blocking effect Effects 0.000 description 6
- 230000007246 mechanism Effects 0.000 description 6
- 230000001681 protective effect Effects 0.000 description 3
- 230000000295 complement effect Effects 0.000 description 2
- 238000013479 data entry Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000011282 treatment Methods 0.000 description 2
- 101100217298 Mus musculus Aspm gene Proteins 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000011900 installation process Methods 0.000 description 1
- 238000004377 microelectronic Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
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/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
-
- 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/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
- G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
- G06F11/1004—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's to protect a block of data words, e.g. CRC or checksum
-
- 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/121—Restricting unauthorised execution of programs
-
- 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/56—Computer malware detection or handling, e.g. anti-virus arrangements
- G06F21/562—Static detection
- G06F21/565—Static detection by checking file integrity
-
- 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/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/577—Assessing vulnerabilities and evaluating computer system security
-
- 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/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
- G06F2221/033—Test or assess software
-
- 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/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
- G06F9/45516—Runtime code conversion or optimisation
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Multimedia (AREA)
- Technology Law (AREA)
- Computing Systems (AREA)
- Virology (AREA)
- Bioethics (AREA)
- Quality & Reliability (AREA)
- Storage Device Security (AREA)
- Stored Programmes (AREA)
Abstract
La técnica propuesta se refiere a un método para determinar la validez de un código de una aplicación (App), implementándose el método dentro de un dispositivo electrónico que comprende un procesador de procesamiento, una memoria no segura y una memoria segura. Este método comprende al menos una iteración de los siguientes pasos: - un paso de cargar (11) la aplicación en la memoria no segura, entregando un código de aplicación actual (CAC); - una etapa de determinar (12) una huella digital de dicho código de aplicación actual, entregando una huella digital actual (Emp_C) asociada con la aplicación; - una etapa de obtención (13), dentro de la memoria segura, una huella digital de referencia (Emp_Rf) asociada con la aplicación; - una etapa de comparar (14) la huella actual (Emp_C) con la huella de referencia (Emp_Rf); y- cuando dicha huella digital actual (Emp_C) es idéntica a dicha huella digital de referencia (Emp_Rf), un paso de validación (15) del código de aplicación actual, que comprende: - un paso de ejecutar un proceso de optimización (151) del código de aplicación actual de dicha aplicación, entregando un código de aplicación optimizado (CAD); - una etapa de determinar (152) una huella de dicho código de aplicación optimizada (CAO), entregando una huella posterior a la optimización (Emp_PO) asociada con dicha aplicación; - una etapa de registrar (153) dicha huella digital posterior a la optimización (Emp_PO) en dicha memoria segura, como una nueva huella digital de referencia asociada a dicha aplicación. (Traducción automática con Google Translate, sin valor legal)
Description
DESCRIPCIÓN
Procedimiento para verificar la integridad de un código de aplicación, dispositivo y producto de programa informático correspondientes
1. Campo de la invención
El campo de la invención es el de los dispositivos electrónicos utilizados para implementar aplicaciones desoftware.Más particularmente, la invención se refiere a los dispositivos utilizados para realizar operaciones que implican o se refieren a objetos confidenciales (tales como transacciones de pago, por ejemplo) y que, como tales, deben cumplir con ciertos requisitos de seguridad definidos en particular en el marco de normas o certificaciones.
2. Técnica anterior
Algunos dispositivos electrónicos, como los terminales de pago, por ejemplo, están diseñados específicamente, tanto enhardwarecomo ensoftware,para ofrecer la protección más óptima posible de los datos confidenciales que puedan introducirse o almacenarse allí. Para garantizar un nivel de seguridad suficiente, se han creado normas y se han desarrollado procedimientos de certificación destinados a establecer la conformidad de dichos dispositivos con estas normas. A modo de ejemplo, el uso de terminales de pago está sujeto a una reglamentación de seguridad obligatoria e impuesta: por lo tanto, se debe certificar que estos terminales cumplen con las normas PCI (por “Payment Card Industry”), como por ejemplo con la norma PCI-PED (por “Payment Card Industry - Pin Entry Device”). Estas normas definen los requisitos de seguridad tanto en el diseño físico delhardwarecomo en la parte desoftwareimplementada en estos dispositivos. Por ejemplo, los datos confidenciales generalmente deben estar encriptados y su procesamiento está sujeto a protocolos criptográficos. Por lo general, también se requiere el uso de componentes desoftwareque solo puedan implementarse dentro de procesadores seguros, inaccesibles para terceros.
Una contrapartida a este importante nivel de seguridad consiste en que la flexibilidad de uso que ofrecen dichos dispositivos sigue siendo limitada. Hacer certificar una aplicación para poder autorizarla a ser ejecutada en el nivel del procesador seguro del dispositivo suele llevar mucho tiempo y ser restrictivo. En un mundo rico en diversos equipos electrónicos, como teléfonos móviles, asistentes personales o microordenadores, existe una necesidad similar de flexibilidad en los dispositivos electrónicos destinados a ser utilizados para realizar operaciones que involucren objetos confidenciales o estén relacionadas con éstos, también designan como dispositivos seguros. Se sabe que los sistemas operativos comúnmente designados como abiertos ofrecen una gran cantidad de aplicaciones útiles y fáciles de usar que es interesante poder implementar para satisfacer esta necesidad de flexibilidad en los dispositivos seguros. Además, cada vez más dispositivos electrónicos seguros incluyen, además del procesador seguro, un procesador no seguro capaz de ejecutar aplicaciones de terceros, por ejemplo, descargables en una plataforma de distribución puesta a disposición por el fabricante del dispositivo electrónico. Esta apertura a aplicaciones desoftwaredistintas de las que están rigurosamente protegidas tiene la desventaja de poner potencialmente en peligro la seguridad de los datos introducidos en el dispositivo seguro. Así, una aplicación maliciosa podría espiar y traicionar los procesos de seguridad del equipo, con el fin de recuperar información confidencial. Una aplicación maliciosa también podría imitar la apariencia de una aplicación legítima (por ejemplo, una aplicación de pago) para engañar a un usuario y recuperar así su información confidencial. Existen soluciones para limitar estos riesgos y cumplir con los requisitos de seguridad predefinidos. Por ejemplo, los paquetes de instalación de las aplicaciones disponibles en la plataforma de distribución del fabricante se pueden firmar electrónicamente mediante una clave criptográfica del fabricante. A continuación, el dispositivo electrónico verifica la firma del paquete de instalación en el momento de la instalación de la aplicación. Por lo tanto, en el momento de su instalación, la aplicación se considera fiable porque su origen está certificado y porque se ha distribuido a través de una plataforma conocida y, a priori, una garantía de cierta calidad: antes de ofrecerse para su distribución en la plataforma del fabricante, se supone que la aplicación ha sido probada y validada como segura desde el punto de vista de la seguridad. Sin embargo, dichas medidas no garantizan la integridad del código ejecutable de la aplicación durante toda su vida útil, desde su instalación hasta su actualización o su eliminación del dispositivo electrónico. De hecho, es probable que el código de una aplicación se corrompa (por ejemplo, esté contaminado por secuencias de ejecución maliciosas) una vez instalada la aplicación, sin que esto se detecte. Por otro lado, cualquier modificación del código de una aplicación fuera del momento de su instalación o actualización no es necesariamente el resultado de una operación maliciosa: la modificación puede ser, por ejemplo, el resultado de una operación legítima de optimización de código implementada por el sistema operativo del dispositivo electrónico. Por ejemplo, el sistema operativo Android™ incorpora procesos para optimizar el código de las aplicaciones en función de su uso. Por lo tanto, no debe considerarse que dichas modificaciones pongan en tela de juicio la integridad del código de aplicación, en la medida en que sean el resultado de operaciones conocidas, controladas y autorizadas.
Por lo tanto, es necesario proponer soluciones destinadas a garantizar que la integridad del código de una aplicación se conserve durante toda su vida útil, en particular mucho después de que se haya instalado en un dispositivo electrónico. Estas soluciones deberían, en particular, permitir verificar la validez del código de una aplicación, incluso cuando este código esté sujeto a una optimización continua que pueda modificarlo. En los documentos EP 3026560, EP 3 026 558, EP 2 362 314 y WO 2016/105927 se proporcionan ejemplos relevantes de la técnica anterior que ilustran la determinación de la validez de un código desoftwareinstalado o reinstalado en un dispositivo y capaz de evolucionar y ser optimizado durante la ejecución de una aplicación que se ejecuta en este dispositivo, teniendo como objeto dicha determinación de validez garantizar la integridad del código desoftwareutilizando un valor dehashcalculado, una suma de control o cualquier otra huella digital de código como valor de referencia.
3. Compendio de la invención
La técnica propuesta ofrece una solución que no presenta al menos algunos de los problemas de la técnica anterior, gracias a un procedimiento original para determinar la validez de un código de aplicación. Este procedimiento se implementa dentro de un dispositivo electrónico que comprende un procesador de tratamiento, una memoria no segura y una memoria segura. Según la técnica propuesta, este procedimiento comprende al menos una iteración de las siguientes etapas:
- una etapa de carga de dicha aplicación en dicha memoria no segura, proporcionando un código de aplicación actual;
- una etapa de determinación de una huella digital de dicho código de aplicación actual, proporcionando una huella digital actual asociada a dicha aplicación;
- una etapa de obtención, dentro de dicha memoria segura, de una huella digital de referencia asociada a dicha aplicación;
- una etapa de comparación de dicha huella digital actual con dicha huella digital de referencia; y
- cuando dicha huella digital actual es idéntica a dicha huella digital de referencia, una etapa de validación de dicho código de aplicación actual, que comprende una etapa de ejecución de un proceso para optimizar el código de aplicación actual de dicha aplicación, proporcionando un código de aplicación optimizado.
De esta manera, la validez del código de una aplicación se puede verificar en cualquier momento durante la vida útil de la aplicación, incluso mucho después de que se haya instalado en el dispositivo electrónico. De esta manera, también se garantiza que la ejecución de un proceso para optimizar el código de la aplicación se lleve a cabo en un código de aplicación en buen estado, que no haya sido objeto de modificaciones no autorizadas. Por lo tanto, las modificaciones que resultan de la ejecución del proceso de optimización en este código, que son modificaciones autorizadas y aceptadas que no ponen en duda la validez del código de aplicación, proporcionan un código de aplicación optimizado que también puede considerarse en buen estado (es decir, válido).
En un modo de realización particular, dicha etapa de validación del código de aplicación actual también comprende:
- una etapa de determinación de una huella digital de dicho código de aplicación optimizado, proporcionando una huella digital posterior a la optimización asociada a dicha aplicación;
- una etapa de registro de dicha huella digital posterior a la optimización en dicha memoria segura, como una nueva huella digital de referencia asociada a dicha aplicación.
De esta manera, cualquier modificación autorizada del código de aplicación conduce a la actualización, en la memoria segura del dispositivo electrónico, de la huella digital de referencia asociada al código de aplicación. Por lo tanto, el procedimiento para determinar la validez del código de aplicación puede implementarse regularmente durante toda la vida útil de la aplicación, y el mecanismo para verificar la integridad del código según la técnica propuesta sigue siendo fiable y robusto, incluso cuando el código de aplicación está sujeto a una optimización continua.
En un modo de realización particular, dicho procedimiento para determinar la validez de un código de una aplicación comprende una etapa de inicialización de dicha huella digital de referencia, implementada durante la instalación de dicha aplicación en dicho dispositivo electrónico.
Según una característica particular de este modo de realización, dicha etapa de inicialización de la huella digital de referencia comprende:
- una etapa de verificación de una firma de al menos un paquete de instalación de dicha aplicación; y
- cuando dicha verificación de firma sea positiva:
- una etapa de obtención de una primera huella digital de referencia para dicha aplicación;
- una etapa de registro de dicha primera huella digital de referencia en dicha memoria segura.
De esta manera, una huella digital de referencia inicial, que corresponde a la primera huella digital de referencia almacenada en la memoria segura para la aplicación en cuestión, se determina en un momento en que el código de la aplicación se considera válido, ya que este momento coincide con una fase de instalación de la aplicación que ya integra sus propios mecanismos para verificar la integridad del código.
En un modo de realización particular, dicho procedimiento para determinar la validez de un código de aplicación comprende, cuando dicha huella digital actual es diferente de dicha huella digital de referencia, una etapa para implementar al menos una medida de protección.
Por lo tanto, los cambios no autorizados en la aplicación se detectan y se pueden implementar varias medidas para proteger los datos introducidos o registrados en el dispositivo electrónico.
Según una característica particular de este modo de realización, dicha al menos una medida de protección pertenece al grupo que comprende:
- mostrar un mensaje de alerta en una pantalla de dicho dispositivo electrónico;
- bloquear cualquier transmisión de datos a dicha aplicación;
- bloquear dicha aplicación;
- bloquear dicho dispositivo electrónico.
Por lo tanto, el dispositivo electrónico dispone de varios medios que pueden usarse solos o de manera complementaria, para advertir a un usuario de que una aplicación ha sido objeto de modificaciones no autorizadas y, si es necesario, hacer que esta aplicación no funcione. Estos medios pueden incluir el bloqueo parcial o total de la aplicación infractora. Ante una situación considerada particularmente crítica, por ejemplo, dicho bloqueo puede extenderse al dispositivo electrónico en su conjunto.
En un modo de realización particular, la huella digital actual y la huella digital de referencia asociadas a dicha aplicación se determinan mediante la implementación de una función dehash.
Por lo tanto, la huella digital actual asociada a la aplicación y la huella digital de referencia asociada a la aplicación son huellas digitales dehash,y la función dehashutilizada se puede elegir para limitar el tamaño ocupado por estas huellas digitales en la memoria del dispositivo electrónico.
En un modo de realización particular, dicho procedimiento para determinar la validez de un código de una aplicación comprende, antes de dicha etapa de ejecución de un proceso de optimización, una etapa de verificación de la integridad del código del proceso de optimización, que comprende:
- una etapa consistente en determinar una huella digital del código de dicho proceso de optimización, proporcionando una huella digital actual asociada a dicho proceso de optimización;
- una etapa de obtención, en dicha memoria segura, de una huella digital de referencia asociada a dicho proceso de optimización;
- una etapa de comparación de dicha huella digital actual asociada al proceso de optimización con dicha huella digital de referencia asociada al proceso de optimización; y
- cuando la huella digital actual asociada al proceso de optimización es idéntica a la huella digital de referencia asociada al proceso de optimización, la implementación de dicha etapa de ejecución del proceso de optimización; - cuando la huella digital actual asociada al proceso de optimización es diferente de la huella digital de referencia asociada al proceso de optimización, la suspensión de dicha etapa de ejecución del proceso de optimización. De esta manera, el código del proceso de optimización está sujeto en sí mismo a una verificación de integridad, cuyo resultado condiciona la ejecución de este proceso. De este modo se garantiza que el proceso de optimización en sí no esté corrupto antes de autorizar su ejecución.
Según otro aspecto, la técnica propuesta también se refiere a un dispositivo electrónico que incluye un procesador de tratamiento, una memoria no segura y una memoria segura. Un dispositivo electrónico de este tipo también comprende:
- medios para cargar una aplicación en dicha memoria no segura, proporcionando un código de aplicación actual; - medios para determinar una huella digital de dicho código de aplicación actual, proporcionando una huella digital actual asociada a dicha aplicación;
- medios para obtener, dentro de dicha memoria segura, una huella digital de referencia asociada a dicha aplicación;
- medios para comparar la huella digital actual con la huella digital de referencia; y
- medios para validar dicho código de aplicación actual implementado cuando dicha huella digital actual es idéntica a dicha huella digital de referencia, comprendiendo dichos medios de validación medios para ejecutar un proceso para optimizar el código de aplicación actual de dicha aplicación, proporcionando un código de aplicación optimizado.
En un modo de realización particular, dichos medios de validación del código de aplicación actual también comprenden:
- medios de determinación de una huella digital de dicho código de aplicación optimizado, proporcionando una huella digital posterior a la optimización asociada a dicha aplicación;
- medios de registro de dicha huella digital posterior a la optimización en dicha memoria segura, como una nueva huella digital de referencia asociada a dicha aplicación.
En un modo de realización particular, el dispositivo electrónico de entrada de datos es un terminal de pago. Por lo tanto, un terminal de pago de este tipo, protegido mediante la implementación de las técnicas anteriormente descritas, es capaz de resistir los ataques que consisten en modificar una aplicación durante su instalación o después de su instalación, o durante su actualización. Por lo tanto, al autorizar a un usuario a instalar una aplicación abierta, es posible evitar un acto malicioso que consista en infectar esta aplicación, con el fin de contaminar el terminal de pago con una aplicación de terceros o un servicio no autorizado. De este modo, es posible combinar la apertura que proporciona la instalación de múltiples aplicaciones y la seguridad necesaria para la implementación de los datos de pago.
Según una implementación preferida, las diversas etapas del procedimiento para determinar la validez de un código de una aplicación según la técnica propuesta se implementan mediante uno o más programas desoftwareo programas informáticos, que comprenden instrucciones desoftwaredestinadas a ser ejecutadas por un procesador de datos de acuerdo con la técnica propuesta y que están diseñadas para controlar la ejecución de las diversas etapas de los procedimientos.
En consecuencia, la técnica propuesta también se refiere a un programa que puede ser ejecutado por un ordenador o por un procesador de datos, y en particular un procesador seguro, comprendiendo este programa instrucciones para controlar la ejecución de las etapas de un procedimiento tal como se ha mencionado más arriba.
Este programa puede usar cualquier lenguaje de programación y estar en forma de código fuente, código objeto o código intermedio entre el código fuente y el código objeto, tal como en una forma parcialmente compilada o en cualquier otra forma deseable.
La técnica propuesta también se refiere a un soporte de información legible por un procesador de datos, y que comprende instrucciones de un programa tal como se ha mencionado más arriba.
El soporte de información puede ser cualquier entidad o dispositivo capaz de almacenar el programa. Por ejemplo, el soporte puede incluir un medio de almacenamiento, tal como una ROM, por ejemplo un CD ROM o una ROM de circuito microelectrónico, o un medio de registro magnético, por ejemplo, un disco duro.
Por otro lado, el soporte de información puede ser un soporte transmisible tal como una señal eléctrica u óptica, que puede transmitirse a través de un cable eléctrico u óptico, por radio o por otros medios. En particular, el programa según la técnica propuesta se puede descargar en una red de tipo Internet.
Alternativamente, el soporte de información puede ser un circuito integrado en el que se incorpora el programa, estando adaptado el circuito para ejecutar el procedimiento en cuestión o para ser utilizado en la ejecución del mismo.
Según un modo de realización, la técnica propuesta se implementa por medio de componentes desoftwarey/ohardware.En este contexto, el término “módulo” puede corresponder en este documento tanto a un componente desoftwarecomo a un componente dehardwareo a un conjunto de componentes dehardwareysoftware.
Un componente desoftwarecorresponde a uno o más programas informáticos, uno o más subprogramas de un programa o, de manera más general, a cualquier elemento de un programa osoftwarecapaz de implementar una función o un conjunto de funciones, de acuerdo con lo que está descrito más abajo para el módulo en cuestión. Dicho componente desoftwarees ejecutado por un procesador de datos de una entidad física (terminal, servidor, pasarela, enrutador, etc.) y es capaz de acceder a los recursos dehardwarede esta entidad física (memorias, medios de registro, buses de comunicación, tarjetas electrónicas de entrada/salida, interfaces de usuario, etc.).
Del mismo modo, un componente dehardwarecorresponde a cualquier elemento de un conjunto dehardware(ohardware) capaz de implementar una función o un conjunto de funciones, de acuerdo con lo que está descrito más abajo para el módulo en cuestión. Se puede tratar de un componente dehardwareprogramable o un componente con un procesador integrado para ejecutarsoftware,por ejemplo, un circuito integrado, una tarjeta inteligente, una tarjeta de memoria, una tarjeta electrónica para ejecutar un firmware, etc.
Obviamente, cada componente del sistema anteriormente descrito usa sus propios módulos desoftware.
Los diversos modos de realización arriba mencionados se pueden combinar entre sí para implementar la invención.
4. Lista de las figuras
Otras características y ventajas de la invención se evidenciarán con la lectura de la siguiente descripción de un modo de realización preferido de la técnica propuesta, dado como un ejemplo ilustrativo simple y no limitativo, y los dibujos adjuntos, en los que:
- la figura 1 ilustra las etapas implementadas para llevar a cabo el procedimiento para determinar la validez de un código de aplicación, de acuerdo con un modo de realización particular de la técnica propuesta;
- la figura 2 describe un ejemplo de un dispositivo electrónico de entrada de datos capaz de implementar la técnica propuesta, en un modo de realización particular de la técnica propuesta.
5. Descripción detallada
5.1. Principio general y presentación de un modo de realización
El principio general de la técnica propuesta consiste en verificar la validez del código de una aplicación, después de que se haya instalado en un dispositivo electrónico. La verificación de la validez, también designada como verificación de integridad en este análisis, significa garantizar que el código de la aplicación no esté sujeto a cambios no autorizados que puedan tener un origen malicioso. Estos cambios no autorizados podrían, por ejemplo, permitir a un atacante recuperar de manera fraudulenta información confidencial almacenada o introducida en el dispositivo electrónico, sin el conocimiento del usuario (como por ejemplo información de pago). Por otro lado, no se considera que los cambios autorizados en el código de la aplicación, como los que resulten de un proceso de optimización conocido y legítimo, pongan en tela de juicio la validez o integridad del código de la aplicación. Según la técnica propuesta, la verificación de la validez del código de una aplicación se implementa preferentemente de forma regular. De este modo, las posibilidades de detectar una modificación no autorizada de la aplicación aumentan a lo largo de su vida útil, es decir, entre el momento de su instalación en una versión determinada en el dispositivo electrónico y el momento de su posterior actualización en otra versión o de su eliminación del dispositivo electrónico. Más particularmente, se propone condicionar la ejecución de un proceso para optimizar el código de la aplicación, también designado como código de aplicación actual, a la verificación previa de que este código de aplicación actual es realmente válido. Por lo tanto, se garantiza que el proceso de optimización actúe sobre un código integrado, lo que permite considerar que el código de aplicación optimizado producido por el proceso de optimización también está integrado.
En relación con lafigura 1se presenta un ejemplo de implementación del procedimiento para determinar la validez de un código de una aplicaciónApp,en un modo de realización particular de la técnica propuesta. La aplicaciónAppse instala dentro de un dispositivo electrónico que comprende un procesador de tratamiento, una memoria segura y una memoria no segura. Más adelante se proporciona una descripción más detallada de un dispositivo electrónico capaz de implementar dicho procedimiento en un modo de realización particular. El procedimiento incluye al menos una iteración de las etapas que se describen a continuación.
En primer lugar se implementa una etapa 11 de carga de la aplicación en la memoria no segura del dispositivo. Al final de esta etapa, el procesador de tratamiento tiene acceso a un código de aplicación actualCACde la aplicación, lo que le permite ejecutar dicha aplicación en caso dado.
El procesador de tratamiento determina entonces, en una etapa 12, una huella digitalEmp_Cdel código de aplicación actual. Según una característica particular, esta huella digital, que corresponde a una huella digital actual asociada a dicha aplicación, se obtiene aplicando una función dehash(por ejemplo, la función MD5 o la función SHA1) al código de aplicación actualCAC.La huella digital dehash(o “valor dehash")obtenida forma así un condensado criptográfico representativo del código de aplicación actual, sin que sea posible encontrar (obtener mediante operación inversa) el código de aplicación actual a partir de esta huella digital dehash.
En una etapa 13, el procesador de tratamiento también obtiene, dentro de la memoria segura, una huella digital de referenciaEmp_Rfasociada a la aplicaciónApp.En un modo de realización particular de la técnica propuesta, esta huella digital de referencia ha podido ser inicializada por primera vez durante la instalación de la aplicación en el dispositivo electrónico (o durante el proceso de instalación, o inmediatamente después). Según una característica particular de este modo de realización, la huella digital de referenciaEmp_Rfse determina en particular después de verificar la firma de al menos un paquete de instalación de la aplicación, y luego se registra en una memoria segura. En un ejemplo, cuando las huellas digitales se determinan mediante la aplicación de una función dehash,obviamente se usa la misma función dehashpara determinar la huella digital de referenciaEmp_Rfy para determinar la huella digitalEmp_Cdel código de aplicación actual. El procesador de tratamiento puede obtener la huella digital de referencia mediante un procesador seguro, que tiene acceso exclusivo a la memoria segura, para garantizar la confidencialidad e integridad de los datos registrados en la memoria segura.
Las etapas 12 y 13 pueden implementarse en paralelo, o una tras otra en cualquier orden.
Una vez que se conocen la huella digital actualEmp_Cy la huella digital de referenciaEmp_Rf,el procesador de tratamiento las compara en una etapa 14.
Cuando la huella digital actualEmp_Ces idéntica a la huella digital de referenciaEmp_Rf, se implementa una etapa de validación 15 del código de aplicación actualCAC.A través de esta etapa se confirma la integridad del código de aplicación: en otras palabras, la implementación de esta etapa significa que el código de aplicación actual no ha sido objeto de cambios no autorizados. Por lo tanto, el código se considera correcto, no está corrupto, está validado y, por lo tanto, puede estar sujeto a varios tratamientos autorizados. Según la técnica propuesta, la etapa de validación incluye en particular una etapa de ejecución de un proceso 151 para optimizar el código de aplicación actual de dicha aplicación, proporcionando un código de aplicación optimizado CAO. Esto garantiza que la optimización del código se lleve a cabo en un código inicialmente íntegro.
En el modo de realización particular presentado en relación con la figura 2, se llevan a cabo dos etapas adicionales 152 y 153 durante la etapa de validación 15 del código de aplicación actual. La etapa 152 es una etapa de determinación de una huella digital del código de aplicación optimizado, proporcionando una huella digital posterior a la optimizaciónEmp_POasociada a dicha aplicación; La etapa 153 corresponde a una etapa de registro de esta huella digital posterior a la optimizaciónEmp_POen la memoria segura del dispositivo electrónico, como una nueva huella digital de referencia asociada a dicha aplicación. De hecho, dado que se ha verificado que el código de aplicación actualCACes válido (íntegro), lo que ha permitido autorizar su optimización, y dado que se considera que las modificaciones realizadas por el proceso de optimización no ponen en tela de juicio la integridad del código, el código de aplicación optimizadoCAO, que corresponde al nuevo código de la aplicación, se considera en sí mismo íntegro. Por lo tanto, se calcula una nueva huella digital de referencia sobre la base de este código optimizado, que reemplaza, en una memoria segura, a la antigua huella digital de referencia que ha quedado obsoleta. Por lo tanto, durante una próxima implementación del procedimiento para determinar la validez, o una siguiente iteración de las etapas que lo componen, la huella digital actual de la aplicación se comparará con la última huella digital de referencia registrada en la memoria segura. Sin embargo, las etapas 152 y 153 no se implementan sistemáticamente. Así, por ejemplo, no es necesario determinar y registrar después una nueva huella digital de referencia si el proceso de optimización no implica ninguna modificación del código en el que se lanza (por ejemplo, porque la aplicación ya ha alcanzado un nivel óptimo de optimización en vista del uso actual de la misma por parte del usuario, o porque el código de la aplicación ya se ha optimizado poco antes, y una nueva optimización demasiado cercana en el tiempo a una optimización anterior no tiene necesariamente efecto).
En un modo de realización particular, cuando se establece al final de la etapa de comparación 14 que la huella digital actualEmp_Ces diferente de la huella digital de referenciaEmp_Rf,se ejecuta una etapa 16 para implementar al menos una medida de protección. Esta etapa de implementación de al menos una medida de protección tiene como objetivo, como mínimo, alertar al usuario de que el código de la aplicación App instalada en el dispositivo electrónico ha sido objeto de una modificación no autorizada. Cuando proceda, las medidas de protección implementadas también pueden consistir en bloquear cualquier transmisión de datos a la aplicación infractoraApp,bloquear el acceso de la aplicaciónAppal contenido de cualquier memoria del dispositivo electrónico, bloquear parcial o totalmente la aplicaciónAppo incluso bloquear el dispositivo electrónico en su conjunto. Estas diversas medidas de protección, que constituyen otros tantos modos de realización particulares de la técnica propuesta, pueden implementarse independientemente unas de otras o de manera complementaria.
En un modo de realización, el código del proceso de optimización está sujeto en sí mismo a una verificación de su integridad antes de cualquier implementación de este proceso. De hecho, en la medida en que el proceso de optimización sea necesario para analizar el código de las aplicaciones instaladas en el dispositivo electrónico y esté autorizado a realizar cambios en el código de estas aplicaciones, se trata de un proceso particularmente crítico. Si bien el proceso de optimización generalmente se considera seguro en el momento de la instalación (porque el paquete de instalación en el que se incluye está firmado electrónicamente con una clave criptográfica del fabricante del dispositivo electrónico, por ejemplo, y esta firma se verifica en el momento de la instalación), se debe tener cuidado de garantizar que el código de este proceso de optimización en sí mismo no haya sido objeto posteriormente de cambios no autorizados (y en particular de origen malicioso). Para garantizar este hecho, se puede adoptar el mismo principio general que se aplica para determinar la validez del código de la aplicaciónApp.Por lo tanto, se pueden implementar las siguientes etapas antes de iniciar el proceso de optimización:
- determinar una huella digital actual del código del proceso de optimización;
- obtener, dentro de la memoria segura del dispositivo electrónico, una huella digital de referencia asociada al proceso de optimización; y
- comparar la huella digital actual del código del proceso de optimización con la huella digital de referencia asociada al proceso de optimización.
El proceso de optimización solo se lleva a cabo si de esta comparación resulta que la huella digital actual es idéntica a la huella digital de referencia. De lo contrario, el código del proceso de optimización se considera poco fiable: por lo tanto, no se ejecuta y, a continuación, se pueden implementar medidas de protección adecuadas para advertir al usuario o incluso bloquear parcial o completamente el dispositivo electrónico.
5.2 Implementación del procedimiento
El procedimiento se ha descrito en el caso general en relación con un dispositivo electrónico que comprende un procesador de tratamiento. La técnica propuesta se puede aplicar más específicamente a dispositivos electrónicos como el que se describe más adelante en relación con la figura 2, que comprenden dos procesadores: un procesador seguro y un procesador no seguro. El interés de estos dispositivos radica en su capacidad para poder implementar no solo aplicaciones seguras, en el sentido de que la mayoría de las veces han sido certificadas por una organización fiable y que están autorizadas a ser ejecutadas por el procesador seguro, sino también aplicaciones de terceros, no necesariamente certificadas, que se ejecutan en el procesador no seguro.
El procesador seguro tiene acceso a la memoria segura, y la combinación de estos dos elementos forma un entorno de ejecución seguro dentro del dispositivo. Por entorno de ejecución seguro se entiende la seguridad que puede ser tanto dehardwarecomo desoftware,incluyendo en particular la implementación de diversas técnicas de protección (constitución física de la carcasa protectora de los componentes seguros, circuitos electrónicos grabados en la masa o multicapas, cifrado de datos, etc.). Esta seguridad también se basa en el uso, a nivel del procesador seguro, de un sistema operativo seguro, en el sentido de que cuenta con un conjunto de medios (de control, de restricción de acceso, criptográficos, etc.) destinados a hacerlo menos vulnerable y a protegerlo eficazmente contra los diversos tipos de ataques que podría sufrir. Por el contrario, el sistema operativo implementado dentro del procesador no seguro del dispositivo electrónico es un sistema que puede describirse como un “sistema abierto”, en el sentido de que el acceso suficiente a este sistema está ampliamente distribuido, lo que favorece el desarrollo de numerosas aplicaciones. Estas aplicaciones, cuando se instalan en el dispositivo electrónico, se cargan en una memoria no segura a la que tiene acceso el sistema operativo abierto. El concepto de sistema operativo abierto incluye no solo los sistemas operativos verdaderamente abiertos, como los sistemas UNIX y LINUX originales, sino también los sistemas que están ampliamente disponibles en el mercado, como las distintas versiones del sistema Android™, por ejemplo. Algunos de estos sistemas operativos, como Android™, por ejemplo, tienen funciones de optimización de código que se ejecutan en segundo plano, lo que puede corresponder al proceso de optimización anteriormente descrito. Estos procesos de optimización consisten, por ejemplo, en optimizar continuamente el código ejecutable de las aplicaciones instaladas en función del uso que se haga del mismo, y así posibilitar la generación de un código de aplicación más eficiente a lo largo del tiempo para las partes de las aplicaciones que se utilizan con más frecuencia.
En este contexto, el procedimiento según la técnica propuesta puede iniciarse e implementarse de varias maneras, que se presentan a continuación.
Según un primer enfoque, que corresponde a un modo de realización particular, la implementación del procedimiento para determinar la validez del código de una aplicación se controla mediante un proceso seguro dedicado ejecutado dentro del procesador seguro. Este proceso seguro “escucha” constantemente las operaciones realizadas por el procesador no seguro en segundo plano. Cuando el proceso seguro dedicado detecta que se solicita al procesador no seguro que ejecute el proceso de optimización, genera una interrupción del proceso de optimización (interrupción delsoftwareo directamente delhardware),que luego se suspende hasta que se confirme la integridad del código de aplicación a nivel del procesador seguro. El procesador seguro, que también tiene acceso a la memoria no segura, determina la huella digital actual asociada a la aplicación, obtiene la huella digital de referencia dentro de la memoria segura y compara estas dos huellas digitales. Si son idénticas, el procesador seguro proporciona datos de validación del código de aplicación durante la etapa de validación (por ejemplo, en forma de datos binarios booleanos) y autoriza la reanudación del proceso de optimización a nivel del procesador no seguro.
Según otro enfoque, que corresponde a otro modo de realización particular, es un proceso dedicado ejecutado dentro del procesador no seguro el que desencadena la implementación del procedimiento para determinar la validez del código de una aplicación. Más particularmente, antes de cualquier ejecución del proceso de optimización, este proceso dedicado realiza una llamada a un proceso o un programa dedicado correspondiente del procesador seguro, de modo que este último determina la huella digital actual asociada a la aplicación (ya sea por sus propios medios, mediante un acceso a la memoria no segura, o porque el proceso de llamada dedicado ejecutado a nivel del procesador no seguro le transmite esta información), obtiene la huella digital de referencia asociada a la aplicación dentro de la memoria segura, y luego compara estos dos huellas. Si son idénticas, el procesador seguro proporciona datos de validación del código de aplicación al procesador no seguro durante la etapa de validación y, a continuación, se desencadena la ejecución del proceso de optimización a nivel del procesador no seguro.
Por lo tanto, en el contexto de un dispositivo electrónico que comprende un procesador seguro y un procesador no seguro, se hace una distinción entre dos posibles enfoques principales para implementar la técnica propuesta: un enfoque según el cual se implementa una suspensión de la ejecución del proceso de optimización ya iniciado a nivel del procesador no seguro mientras no se establezca la integridad del código actual de la aplicación que ha de ser optimizada, y un enfoque según el cual el proceso de optimización solo se activa si ya se ha establecido la integridad del código actual de la aplicación que ha de ser optimizada. Sea cual sea el enfoque elegido, las etapas que se consideran críticas desde el punto de vista de la seguridad permanecen dentro del alcance exclusivo del procesador seguro. Éstas incluyen etapas que requieren acceso a la memoria segura (como la etapa de obtención de la huella digital de referencia asociada a la aplicación), la etapa de comparación de las huellas digitales actuales y de referencia, y la etapa de validación del código de aplicación actual que proporciona los datos de validación. Por su parte, la etapa de determinación de la huella digital del código de aplicación actual puede implementarse igualmente bien mediante el procesador seguro o mediante el procesador no seguro.
5.3 Dispositivo
La figura 2 muestra esquemáticamente la estructura de un dispositivo electrónicoDEen un modo de realización particular de la técnica propuesta. En la figura 2 solo se muestran los componentes necesarios para entender la presente técnica. Por lo tanto, ciertos componentes que generalmente forman parte de un dispositivo electrónico, como un terminal de pago, se han omitido deliberadamente. Este modo de realización corresponde al anteriormente presentado, según el cual el dispositivo electrónicoDEcomprende un procesador seguroPSy un procesador no seguroPNS.Además, un programa informáticoPGincluye instrucciones para ejecutar las etapas del procedimiento para determinar la validez de un código de aplicación. Cuando se inicializa el dispositivo electrónico, las instrucciones de código del programa informáticoPGse cargan, por ejemplo, en una memoria antes de ejecutarse, normalmente mediante el procesador seguroPS.
El dispositivo electrónicoDEtambién incluye una memoria segura (o protegida)MSy una memoria no seguraMNS.Por “memoria segura” se entiende una memoria cuyo acceso al contenido está protegido por un mecanismo de seguridad adecuado. Un mecanismo de este tipo permite, por ejemplo, verificar la identidad y/o la autenticidad de un solicitante que desee acceder a los datos registrados en la memoria segura en cuestión. Normalmente, la memoria seguraMSestá conectada al procesador seguroPSque tiene acceso a su contenido. El procesador seguro PS es, en particular, capaz de implementar un mecanismo para proteger los datos en la memoria segura, que incluye, por ejemplo, la eliminación de los datos en caso de una violación de la integridad de los datos. El mecanismo de seguridad también puede serhardware(capa física que cubre la memoria para proteger su lectura, etc.). El procesador no seguroPNS,por su parte, no tiene acceso al contenido de la memoria seguraMS.La memoriaMNS,por otro lado, es una memoria no segura. En otras palabras, el acceso al contenido de la memoriaMNSno está protegido, a diferencia del acceso al contenido de la memoriaMS.Por lo tanto, tanto el procesador seguroPScomo el procesador no seguroPNSpueden acceder al contenido de la memoria no seguraMNS.
Según un modo de realización de la técnica propuesta, el procesador seguro recibe, por ejemplo, como información de entrada según la cual un proceso para optimizar una aplicaciónAppcargada en la memoria no seguraMNSdel dispositivo electrónicoDEdebe ejecutarse o acaba de iniciarse a nivel del procesador no seguroPNS.El procesador seguroPSimplementa entonces las etapas del procedimiento para determinar la validez de un código de aplicación, de acuerdo con las instrucciones del programa informáticoPG,y en la salida notifica los datos para validar el código de la aplicaciónApp(por ejemplo, datos binarios de tipo booleano). Con este fin, como ya se ha explicado anteriormente, el procesador seguroPScompara una huella digital actual asociada a la aplicaciónAppcon una huella digital de referenciaEmp_Rfque obtiene en la memoria seguraMS.La huella digital actual asociada a la aplicaciónAppse determina, por su parte, a partir del código de aplicación cargado en la memoria no seguraMNS.La determina el propio procesador seguroPSo el procesador no seguroPNS,que luego la transmite al procesador seguroPS.Si no se establece la validez del código de la aplicaciónApp,el proceso de optimización de la aplicaciónAppno se completa, ya sea porque este proceso de optimización ni siquiera se ejecuta (no se inicia) o porque se suspende incluso antes de que haya empezado a realizar cambios en el código de la aplicaciónApp(por ejemplo, mediante una interrupción delsoftwaredel procesador seguro). Por otro lado, cuando la huella digital actual asociada a la aplicaciónAppes idéntica a dicha huella digital de referenciaEmp_Rf,el código de la aplicaciónAppse considera íntegro (válido) y, a continuación, el proceso de optimización puede completarse para proporcionar, posiblemente, un código de aplicación optimizado para la aplicaciónApp.
En un modo de realización particular, el dispositivo electrónicoDEtambién comprende medios para implementar la técnica propuesta, en particular:
-medios de carga de una aplicación en dicha memoria no segura, proporcionando un código de aplicación actual;
- medios de determinación de una huella digital de dicho código de aplicación actual, proporcionando una huella digital actual asociada a dicha aplicación;
- medios de obtención, dentro de dicha memoria segura, de una huella digital de referencia asociada a dicha aplicación;
- medios para comparar la huella digital actual con la huella digital de referencia; y
- medios para validar dicho código de aplicación actual implementados cuando dicha huella digital actual es idéntica a dicha huella digital de referencia, comprendiendo dichos medios de validación medios para ejecutar un proceso para optimizar el código de aplicación actual de dicha aplicación, proporcionando un código de aplicación optimizado.
En un modo de realización particular, el dispositivo electrónico es un terminal de pago.
Claims (9)
1. Procedimiento para determinar la validez de un código de aplicación (App), implementándose dicho procedimiento dentro de un dispositivo electrónico que comprende un procesador no seguro, un procesador seguro, una memoria no segura y una memoria segura, y caracterizado por que dicho procedimiento comprende al menos una iteración de las siguientes etapas:
- una etapa de carga (11) de dicha aplicación en dicha memoria no segura, proporcionando un código de aplicación actual (CAC); y
- tras la detección, mediante el procesador seguro, de una solicitud para implementar, mediante el procesador no seguro, un proceso para optimizar dicho código de aplicación actual:
- una etapa de generación, mediante dicho procesador seguro, de una interrupción de dicho proceso de optimización;
- una etapa de determinación (12), mediante dicho procesador seguro, de una huella digital de dicho código de aplicación actual, proporcionando una huella digital actual (Emp_C) asociada a dicha aplicación;
- una etapa de obtención (13), mediante dicho procesador seguro, dentro de dicha memoria segura, de una huella digital de referencia (Emp_Rf) asociada a dicha aplicación;
- una etapa de comparación (14), mediante dicho procesador seguro, de la huella digital actual (Emp_C) con la huella digital de referencia (Emp_Rf); y
- cuando dicha huella digital actual (Emp_C) es idéntica a dicha huella digital de referencia (Emp_Rf), una etapa de validación (15), mediante dicho procesador seguro, de dicho código de aplicación actual, que comprende: - una etapa para proporcionar una autorización para reanudar la ejecución de dicho proceso de optimización (151) del código de aplicación actual de dicha aplicación, proporcionando dicha ejecución un código de aplicación optimizado (CAO);
- una etapa de determinación (152) de una huella digital de dicho código de aplicación optimizado (CAO), proporcionando una huella digital posterior a la optimización (Emp_PO) asociada a dicha aplicación;
- una etapa de registro (153) de dicha huella digital posterior a la optimización (Emp_PO) en dicha memoria segura, como una nueva huella digital de referencia asociada a dicha aplicación.
2. Procedimiento según la reivindicación 1, caracterizado por que comprende una etapa de inicialización de dicha huella digital de referencia, implementada durante la instalación de dicha aplicación en dicho dispositivo electrónico.
3. Procedimiento según la reivindicación 2, caracterizado por que dicha etapa de inicialización de la huella digital de referencia comprende:
- una etapa de verificación de una firma de al menos un paquete de instalación de dicha aplicación; y
- cuando dicha verificación de firma sea positiva:
- una etapa de obtención de una primera huella digital de referencia para dicha aplicación;
- una etapa de registro de dicha primera huella digital de referencia en dicha memoria segura.
4. Procedimiento según la reivindicación 1, caracterizado por que comprende, cuando dicha huella digital actual es diferente de dicha huella digital de referencia, una etapa de implementación de al menos una medida de protección.
5. Procedimiento según la reivindicación 4, caracterizado por que dicha al menos una medida de protección pertenece al grupo que comprende:
- mostrar un mensaje de alerta en una pantalla de dicho dispositivo electrónico;
- bloquear cualquier transmisión de datos a dicha aplicación;
- bloquear dicha aplicación;
- bloquear dicho dispositivo electrónico.
6. Procedimiento según la reivindicación 1, caracterizado por que la huella digital actual y la huella digital de referencia asociadas a dicha aplicación se determinan mediante la implementación de una función dehash.
7. Procedimiento según la reivindicación 1, caracterizado por que comprende, antes de dicha etapa de ejecución de un proceso de optimización, una etapa de verificación de la integridad del código del proceso de optimización, que comprende:
- una etapa de determinación de una huella digital del código de dicho proceso de optimización, proporcionando una huella digital actual asociada a dicho proceso de optimización;
- una etapa de obtención, en dicha memoria segura, de una huella digital de referencia asociada a dicho proceso de optimización;
- una etapa de comparación de dicha huella digital actual asociada al proceso de optimización con dicha huella digital de referencia asociada al proceso de optimización; y
- cuando la huella digital actual asociada al proceso de optimización es idéntica a la huella digital de referencia asociada al proceso de optimización, la implementación de dicha etapa de ejecución del proceso de optimización; - cuando la huella digital actual asociada al proceso de optimización es diferente de la huella digital de referencia asociada al proceso de optimización, la suspensión de dicha etapa de ejecución del proceso de optimización.
8. Dispositivo electrónico que comprende un procesador no seguro, un procesador seguro, una memoria no segura y una memoria segura, y caracterizado por que dicho dispositivo comprende:
- medios de carga de una aplicación en dicha memoria no segura, proporcionando un código de aplicación actual; - medios de detección, mediante el procesador seguro, de una solicitud para implementar, mediante el procesador no seguro, un proceso para optimizar dicho código de aplicación actual, activando dicha detección:
- medios de generación, mediante dicho procesador seguro, de una interrupción de dicho proceso de optimización;
- medios de determinación, mediante dicho procesador seguro, de una huella digital de dicho código de aplicación actual, proporcionando una huella digital actual asociada a dicha aplicación;
- medios de obtención, mediante dicho procesador seguro, dentro de dicha memoria segura, de una huella digital de referencia asociada a dicha aplicación;
- medios para comparar, mediante dicho procesador seguro, la huella digital actual con la huella digital de referencia; y
- medios para validar, mediante dicho procesador seguro, dicho código de aplicación actual implementado cuando dicha huella digital actual es idéntica a dicha huella digital de referencia, comprendiendo dichos medios de validación:
- medios para proporcionar una autorización para reanudar la ejecución de dicho proceso de optimización del código de aplicación actual de dicha aplicación, proporcionando dicha ejecución un código de aplicación optimizado;
- medios de determinación de una huella digital de dicho código de aplicación optimizado (CAO), proporcionando una huella digital posterior a la optimización asociada a dicha aplicación;
- medios de registro de dicha huella digital posterior a la optimización en dicha memoria segura, como una nueva huella digital de referencia asociada a dicha aplicación.
9. Producto de programa informático que puede descargarse desde una red de comunicación y/o almacenarse en un medio legible por ordenador y/o ejecutarse mediante un microprocesador, caracterizado por que incluye instrucciones de código de programa para ejecutar un procedimiento para determinar la validez de un código de aplicación según una cualquiera de las reivindicaciones 1 a 7, cuando se ejecuta en un ordenador.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1856056A FR3083343B1 (fr) | 2018-06-29 | 2018-06-29 | Procede de determination d'une validite d'un code applicatif, dispositif et produit programme d'ordinateur correspondants. |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2963328T3 true ES2963328T3 (es) | 2024-03-26 |
Family
ID=65031343
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES19180688T Active ES2963328T3 (es) | 2018-06-29 | 2019-06-17 | Procedimiento para verificar la integridad de un código de aplicación, dispositivo y producto de programa informático correspondientes |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US11443031B2 (es) |
| EP (1) | EP3588359B1 (es) |
| CA (1) | CA3047681A1 (es) |
| ES (1) | ES2963328T3 (es) |
| FR (1) | FR3083343B1 (es) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE102018212686A1 (de) * | 2018-07-30 | 2020-01-30 | Siemens Aktiengesellschaft | Verfahren zum Betreiben einer Rechenanlage |
| GB2579034B (en) * | 2018-11-15 | 2021-05-05 | Trustonic Ltd | Software installation method |
| EP3696698A1 (en) * | 2019-02-18 | 2020-08-19 | Verimatrix | Method of protecting a software program against tampering |
| FR3116922B1 (fr) * | 2020-12-01 | 2023-06-16 | Banks And Acquirers Int Holding | Procédé de configuration d’un terminal de paiement, terminal de paiement associé. |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7356668B2 (en) * | 2004-08-27 | 2008-04-08 | Microsoft Corporation | System and method for using address bits to form an index into secure memory |
| EP2026558A1 (en) | 2007-07-30 | 2009-02-18 | Sony United Kingdom Limited | Transport stream module for digital television receiver |
| EP2362314A1 (en) * | 2010-02-18 | 2011-08-31 | Thomson Licensing | Method and apparatus for verifying the integrity of software code during execution and apparatus for generating such software code |
| US8549504B2 (en) * | 2010-09-25 | 2013-10-01 | Intel Corporation | Apparatus, method, and system for providing a decision mechanism for conditional commits in an atomic region |
| US8566935B2 (en) * | 2011-05-12 | 2013-10-22 | At&T Intellectual Property I, L.P. | Balancing malware rootkit detection with power consumption on mobile devices |
| EP3026558A1 (en) * | 2014-11-28 | 2016-06-01 | Thomson Licensing | Method and device for providing verifying application integrity |
| EP3026560A1 (en) * | 2014-11-28 | 2016-06-01 | Thomson Licensing | Method and device for providing verifying application integrity |
| US9798559B2 (en) * | 2014-12-27 | 2017-10-24 | Mcafee, Inc. | Trusted binary translation |
| WO2016126023A1 (en) * | 2015-02-03 | 2016-08-11 | Samsung Electronics Co., Ltd. | Broadcast apparatus and method of authenticating broadcast data |
-
2018
- 2018-06-29 FR FR1856056A patent/FR3083343B1/fr active Active
-
2019
- 2019-06-17 ES ES19180688T patent/ES2963328T3/es active Active
- 2019-06-17 EP EP19180688.4A patent/EP3588359B1/fr active Active
- 2019-06-20 CA CA3047681A patent/CA3047681A1/en active Pending
- 2019-06-28 US US16/456,533 patent/US11443031B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| FR3083343B1 (fr) | 2023-05-26 |
| CA3047681A1 (en) | 2019-12-29 |
| EP3588359B1 (fr) | 2023-08-30 |
| EP3588359A1 (fr) | 2020-01-01 |
| US20200004952A1 (en) | 2020-01-02 |
| FR3083343A1 (fr) | 2020-01-03 |
| US11443031B2 (en) | 2022-09-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2963328T3 (es) | Procedimiento para verificar la integridad de un código de aplicación, dispositivo y producto de programa informático correspondientes | |
| EP2854066B1 (en) | System and method for firmware integrity verification using multiple keys and OTP memory | |
| KR100851631B1 (ko) | 보안 모드 제어 메모리 | |
| US10516533B2 (en) | Password triggered trusted encryption key deletion | |
| TWI607376B (zh) | 用於處理改變依照統一可延伸韌體介面計算裝置中之系統安全資料庫及韌體儲存區請求的系統及方法 | |
| EP3207485B1 (en) | Code pointer authentication for hardware flow control | |
| US8006095B2 (en) | Configurable signature for authenticating data or program code | |
| Parno et al. | Bootstrapping trust in modern computers | |
| US7139915B2 (en) | Method and apparatus for authenticating an open system application to a portable IC device | |
| US7010684B2 (en) | Method and apparatus for authenticating an open system application to a portable IC device | |
| TWI567580B (zh) | 用於防止惡意軟體執行的方法與系統 | |
| US8375219B2 (en) | Program and operation verification | |
| KR20170095161A (ko) | 시큐어 시스템 온 칩 | |
| CN110990084B (zh) | 芯片的安全启动方法、装置、存储介质和终端 | |
| US20090288161A1 (en) | Method for establishing a trusted running environment in the computer | |
| ES2773042T3 (es) | Mecanismo para actualizar software | |
| KR20070102489A (ko) | 충분히 유효한/현재의 코드를 보장하고 강제하는 최종방어선 | |
| TW201500960A (zh) | 在配有適用統一可延伸韌體介面(uefi)之韌體之計算裝置中的安全性變數變化檢測技術 | |
| CN105426750A (zh) | 一种嵌入式系统的启动方法及嵌入式装置 | |
| US10776493B2 (en) | Secure management and execution of computing code including firmware | |
| Almohri et al. | Process authentication for high system assurance | |
| Frazelle | Securing the Boot Process: The hardware root of trust | |
| Frazelle | Securing the boot process | |
| Msgna et al. | Secure application execution in mobile devices | |
| Chevalier et al. | Bootkeeper: Validating software integrity properties on boot firmware images |