ES2949313T3 - Método de carga de un recurso informático en un dispositivo electrónico, módulo electrónico y programa informático correspondiente - Google Patents

Método de carga de un recurso informático en un dispositivo electrónico, módulo electrónico y programa informático correspondiente Download PDF

Info

Publication number
ES2949313T3
ES2949313T3 ES16202743T ES16202743T ES2949313T3 ES 2949313 T3 ES2949313 T3 ES 2949313T3 ES 16202743 T ES16202743 T ES 16202743T ES 16202743 T ES16202743 T ES 16202743T ES 2949313 T3 ES2949313 T3 ES 2949313T3
Authority
ES
Spain
Prior art keywords
certificate
current
data block
address
loading
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
ES16202743T
Other languages
English (en)
Inventor
Christophe Auffray
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.)
Banks and Acquirers International Holding SAS
Original Assignee
Banks and Acquirers International Holding 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 Banks and Acquirers International Holding SAS filed Critical Banks and Acquirers International Holding SAS
Application granted granted Critical
Publication of ES2949313T3 publication Critical patent/ES2949313T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • 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
    • 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/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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Mathematical Physics (AREA)
  • Storage Device Security (AREA)
  • Stored Programmes (AREA)

Abstract

La invención se refiere a un método para cargar un recurso informático, mediante un dispositivo que comprende un procesador y una RAM, realizándose dicha carga dentro de dicha RAM de dicho dispositivo desde una memoria masiva, registrándose dicho recurso en dicha memoria masiva a través de al menos un bloque de datos. Un método de este tipo comprende las siguientes etapas: - obtener (100) al menos una dirección (Adr 1, Adr 2,.... Adr N) correspondiente a al menos un bloque de datos (DBloc 1, DBloc 2,..., DBloc N) dentro del cual el recurso está registrado al menos parcialmente; y para dicha al menos una dirección actual (Adr i) obtenida previamente: - carga (110) de un bloque de datos actual (DBloc i) según dicha dirección actual (Adr i); - obtener (120) al menos un certificado de referencia (CertR i) del bloque de datos actual (DBloc i); - obtener (130) al menos un certificado vigente (CertC i) del bloque de datos actual (DBloc i); - entrega (140) de una aserción de validez (ArV i) basada en dicho certificado de referencia (CertR i) y el certificado vigente (CertC i). (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Método de carga de un recurso informático en un dispositivo electrónico, módulo electrónico y programa informático correspondiente
1. CAMPO TÉCNICO
La presente técnica se refiere al campo de la gestión de la carga y ejecución de aplicaciones de software en un terminal. Más en particular, la presente técnica se refiere a la aceleración de la carga de aplicaciones seguras para un procesador de un terminal, cuyo procesador puede ser en sí mismo seguro. La invención tiene como objetivo permitir una carga más rápida de aplicaciones en la memoria. La invención se refiere aún más concretamente a la carga de aplicaciones en un terminal tal como, por ejemplo, un terminal de pago, que dispone de capacidades de procesamiento relativamente reducidas.
2. ANTECEDENTES
Los terminales electrónicos, tales como teléfonos inteligentes, denominados smartphones, tabletas digitales (táctiles) o terminales de pago incorporan frecuentemente aplicaciones, algunas de las cuales pueden ser aplicaciones sensibles (tal como aplicaciones que permiten una identificación, una autenticación o incluso un pago). Resulta que este tipo de aplicaciones por lo general se graban dentro de una memoria tipo “flash” (“instantánea”), por ejemplo, bajo una forma encriptada. Lo que antecede es común y se debe a la naturaleza de las aplicaciones implicadas. Conviene señalar que una memoria "flash" es una memoria de masa de semiconductores que es regrabable. Por lo tanto, es una memoria que tiene algunas de las características de una memoria de acceso aleatorio pero cuyos datos son persistentes, incluso cuando está apagada. Por lo tanto, una memoria instantánea almacena los bits de datos en células de memoria y los datos se conservan en memoria cuando se apaga la fuente de alimentación eléctrica de la memoria.
La memoria "flash" o instantánea en donde se pueden almacenar las aplicaciones puede ser incluso una memoria protegida: de este modo, dicha memoria puede disponer de mecanismos físicos de protección que permitan detectar un posible intento de intrusión (tal como, por ejemplo, la instalación de sondas para espiar las señales que pasan por el componente electrónico). De lo que antecede se deduce que la memoria en cuestión (es decir, el propio componente electrónico) a menudo tiene un ancho de banda relativamente bajo. Ello significa, por ejemplo, que los tiempos de carga son relativamente largos: por un lado, el componente puede ser lento en sí mismo y, por otro lado, los procesos para verificar la integridad de los datos cargados ralentizan la carga.
Además, el problema que se acaba de describir para una aplicación también puede existir para el sistema operativo del terminal en su conjunto. De este modo, por ejemplo, todos los ficheros ejecutables de un sistema Linux (del tipo Android™) se cargan completamente en la memoria RAM cuando se inicia este sistema. Lo que antecede significa que cuando se dispone de componentes de memoria relativamente económicos, la carga y puesta en marcha del sistema son muy largas, sin mencionar siquiera el proceso de verificación de la integridad de los datos del sistema.
Cuando se pone en práctica un proceso de verificación de integridad de los datos del sistema, se verifica la autenticidad de los ejecutables antes de cargarlos en memoria RAM y esto sobre todo el ejecutable y sus datos, lo que ralentiza aún más el arranque del dispositivo. La solicitud de patente US201113166849A da a conocer la verificación de una firma de un recurso para todos los bloques de dicho recurso durante su carga.
Por tanto, es necesario disponer de una solución para cargar en memoria una aplicación o datos (por lo general denominados recursos) que permita no tener que cargar en memoria todo un recurso para verificar su autenticidad.
3. SUMARIO
La invención no plantea estos problemas de la técnica anterior. Más en particular, la invención proporciona una solución sencilla al problema identificado con anterioridad. Más en particular, la técnica se refiere a un método de carga de un recurso informático, mediante un dispositivo que comprende un procesador y una memoria de acceso aleatorio, realizándose dicha carga dentro de dicha memoria de acceso aleatorio de dicho dispositivo a partir de una memoria de masa, siendo grabado dicho recurso en dicha memoria de masa por intermedio de al menos un bloque de datos.
Dicho método comprende las etapas siguientes:
- obtención de al menos una dirección correspondiente a al menos un bloque de datos dentro del cual se registra al menos parcialmente el recurso;
y para dicha al menos una dirección actual obtenida con anterioridad:
- carga de un bloque de datos actual en función de dicha dirección actual;
- obtención de al menos un certificado de referencia del bloque de datos actual;
- obtención de al menos un certificado actual del bloque de datos actual;
- emisión de una aseveración de validez en función de dicho certificado de referencia y del certificado actual. De este modo, la presente técnica permite, por un lado, acelerar la carga de recursos, y por otro lado, limitar el gasto energético cargando únicamente los recursos necesarios en un instante dado.
Según una característica particular, cuando dicha aseveración de validez es positiva, dicho método comprende una etapa de copia de dicho bloque de datos actual dentro de la memoria RAM de dicho dispositivo.
De este modo, la carga y el posterior uso de los recursos están protegidas.
Según una característica particular, dicha etapa de obtención de dicha al menos una dirección comprende:
- una etapa de intercepción de una solicitud de obtención de dicho recurso;
- una etapa de determinación, en función de una lista de recursos, de dicha al menos una dirección de dicho recurso.
Por lo tanto, mediante el uso de un mecanismo de intercepción, la puesta en práctica del método de la presente técnica es transparente para la aplicación que se solicita.
En función de una característica particular, dicha lista de recursos se encuentra registrada dentro de una memoria protegida de dicho dispositivo.
De este modo, el acceso a la lista de recursos se hace más complejo y permite asegurar el proceso de carga.
Según una característica particular, dicha etapa de obtención de al menos un certificado de referencia del bloque de datos actual comprende una etapa de búsqueda de dicho certificado de referencia dentro de una lista de recursos, en función de dicha dirección actual.
De este modo, el certificado de referencia está protegido en la propia lista de recursos.
Según una característica particular, dicha etapa de obtención de al menos un certificado de referencia del bloque de datos actual comprende una etapa de extracción de dicho certificado de referencia, a partir de los datos del bloque de datos actual, datos cargados desde dicha dirección actual.
De este modo, el certificado de referencia acompaña al bloque de datos a cargar y no ocupa demasiado espacio en la lista de los recursos.
Según una característica particular, dicha etapa de obtención de al menos un certificado de referencia del bloque de datos actual comprende una etapa de carga de dicho certificado de referencia a partir de una dirección de dicho certificado de referencia, obteniéndose dicha dirección de dicho certificado de referencia a partir de una lista de recursos de los que al menos una entrada está asociada a dicha dirección actual y a dicha dirección de dicho certificado de referencia.
De este modo, un intruso debe, para tener éxito en su intrusión, tanto lograr sustituir el bloque de datos como lograr localizar y sustituir el certificado de referencia que se adjunta al mismo.
Según otro aspecto, la presente técnica también se refiere a un módulo electrónico de carga de un recurso informático dentro de un dispositivo que comprende un procesador y una memoria de acceso aleatorio, realizándose dicha carga dentro de dicha memoria de acceso aleatorio de dicho dispositivo a partir de una memoria de masa, siendo registrado dicho recurso en dicha memoria de masa a través de al menos un bloque de datos. Según la presente técnica, dicho módulo comprende medios:
- de obtención de al menos una dirección correspondiente a al menos un bloque de datos dentro del cual se registra al menos parcialmente el recurso;
- de carga de un bloque de datos actual en función de dicha dirección actual;
- de obtención de al menos un certificado de referencia del bloque de datos actual;
- de obtención de al menos un certificado actual del bloque de datos actual;
- de emitir una aseveración de validez en función de dicho certificado de referencia.
Según una puesta en práctica específica, las diferentes etapas de los métodos, según la invención, son puestas en prácticas por uno o más software o programas informáticos, que comprenden instrucciones de software destinadas a ser ejecutadas por un procesador de un dispositivo informático, tal como un terminal, según la invención y estar diseñado para controlar la ejecución de las diversas etapas de los métodos.
En consecuencia, la invención también se refiere a un programa, capaz de ser ejecutado por un ordenador o por un procesador de datos, comprendiendo este programa instrucciones para controlar la ejecución de las etapas de un método tal como el mencionado con anterioridad.
Este programa puede utilizar 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 forma parcialmente compilada, o en ninguna otra forma deseable.
La invención también se refiere a un medio de información legible por un procesador de datos y que comprende instrucciones de programa tal como se mencionó con anterioridad.
El portador de información puede ser cualquier entidad o dispositivo capaz de almacenar el programa. Por ejemplo, el medio puede comprender un soporte de almacenamiento, tal como una memoria ROM, por ejemplo, un CD ROM o una memoria ROM de circuito microelectrónico, o incluso un medio de grabación magnético, por ejemplo, un disquete (floppy disc) o un disco duro.
Por otro lado, el medio de información puede ser un medio transmisible tal como una señal eléctrica u óptica, que puede encaminarse a través de un cable eléctrico u óptico, por radio u otros medios. En particular, el programa según la invención puede descargarse desde una red de tipo Internet.
De manera alternativa, el soporte de información puede ser un circuito integrado en donde se incorpora el programa, estando adaptado el circuito para ejecutar o para ser utilizado en la ejecución del método en cuestión.
De conformidad con una forma de realización, la invención se pone en práctica por medio de componentes de software y/o de hardware. Desde esta perspectiva, el término "módulo" puede corresponder, en este documento, también a un componente de software, a un componente de hardware o a un conjunto de componentes de hardware y de software. Un componente de software corresponde a uno o más programas informáticos, uno o más subprogramas de un programa, o más por lo general, a cualquier elemento de un programa o software capaz de poner en práctica una función o un conjunto de funciones, tal como se describe a continuación para el módulo en cuestión. Dicho componente de software es ejecutado por un procesador de datos de una entidad física (terminal, servidor, pasarela, enrutador, etc.) y es probable que acceda a los recursos de hardware de esta entidad física (memorias, soportes de grabación, bus de comunicación, tarjetas electrónicas de entradas/salidas, interfaces de usuario, etc.).
Del mismo modo, un componente de hardware corresponde a cualquier elemento de un conjunto material (o hardware) capaz de poner en práctica una función o un conjunto de funciones, según lo que se describe a continuación para el módulo en cuestión. Puede ser un componente de hardware que se pueda programar o que tenga un procesador integrado para ejecutar software, por ejemplo, un circuito integrado, una tarjeta inteligente, una tarjeta de memoria, una tarjeta electrónica para ejecutar un microsoftware (firmware), etc.
Por supuesto, cada componente del sistema descrito con anterioridad pone en práctica sus propios módulos de software.
Las diversas formas de realización mencionadas con anterioridad se pueden combinar entre sí para la puesta en práctica de la invención.
4. DIBUJOS
Otras características y ventajas de la invención aparecerán más claramente con la lectura de la siguiente descripción de una forma de realización preferente, proporcionada a modo de ejemplo sencillo, ilustrativo y no limitativo, y de los dibujos adjuntos, entre los cuales:
- la Figura 1 es un ejemplo de un problema planteado;
- la Figura 2 muestra un diagrama de bloques de la técnica propuesta, en donde se compara un certificado de referencia con un certificado actual con el fin de determinar la validez de un bloque de datos cargado de manera dinámica al recibir una solicitud para la obtención de un recurso;
- la Figura 3 representa una primera forma de realización de la técnica de almacenamiento y carga, en donde la lista de recursos incluye un certificado de referencia para cada bloque de datos;
- la Figura 4 describe una segunda forma de realización de la técnica de almacenamiento y carga, en donde cada bloque de datos va seguido de un certificado de referencia;
- la Figura 5 describe una tercera forma de realización de la técnica de almacenamiento y carga, en donde todos los certificados se registran en un lugar compartido, para el conjunto de los certificados, según un orden aleatorio o semialeatorio; la lista de los recursos incluye tanto la dirección del bloque de datos como la dirección del certificado;
- la Figura 6 describe un dispositivo, tal como un terminal de pago, capaz de poner en práctica un recurso según la presente técnica.
5. DESCRIPCIÓN
5.1. Recordatorios del principio
Se recuerda que uno de los problemas a los que la presente técnica quiere dar solución está ligado a la necesidad de realizar una carga completa de los recursos para verificar la autenticidad de estos antes de su uso. El término recursos, en el presente documento, se refiere tanto a datos de código ejecutable (es decir, aplicaciones) como a datos utilizados por este código ejecutable (datos de aplicación).
Para comprender mejor el problema resuelto, se describe, con referencia a la Figura 1, un ejemplo, puramente ilustrativo, al que se puede aplicar la presente técnica.
De este modo, se supone una aplicación A1, que se ejecuta en un procesador (por ejemplo, un procesador seguro) de un terminal de pago. Esta aplicación A1 desea acceder a un material criptográfico (por ejemplo, una clave de cifrado) MC registrado en una memoria física MEMdel terminal. Este material criptográfico MC es, a su vez, parte de un fichero FIL que se registra dentro de un espacio específico ES de la memoria MEM. Para poder acceder al material criptográfico MC, la aplicación A1 recurre al sistema operativo OSu (por ejemplo, mediante un mecanismo de interrupción), que realiza una carga del fichero FIL en la memoria RAM para que la aplicación A1 pueda acceder al mismo y extraer el material criptográfico MC. La carga del fichero FIL en la memoria está precedida por la verificación de la autenticidad de este fichero FIL. Esta verificación de autenticidad se realiza en todo el fichero FIL. De este modo, por ejemplo, un material criptográfico (una clave) cuya longitud sería de un megabyte y que se encuentra almacenada en un fichero compuesto por otros veinte materiales de la misma longitud requiere la verificación y carga del conjunto del fichero para poder acceder a un único hardware. Lo que antecede da como resultado una pérdida consecuente de tiempo, así como una pérdida igualmente consecuente de energía (pérdida que conduce a una reducción de la autonomía general del terminal).
Este ejemplo permite comprender, de manera sencilla, el problema al que la técnica quiere dar solución. Es bastante obvio que los casos reales de puesta en práctica son relativamente más complejos.
La técnica propuesta permite solucionar los problemas antes mencionados o al menos limitar, en gran medida, el tiempo necesario para la carga de datos cuya autenticidad deberá ser verificada. La técnica se describe con relación a la Figura 2. En general, tras la recepción (10), desde una aplicación solicitante (AppReq), de la solicitud de obtención de un recurso (ReqRes) (por ejemplo, el material criptográfico), el sistema (SYST) (operando o cargando):
- obtiene (100) al menos una dirección (Adn, Adr2, ..., AdrN) correspondiente a al menos un bloque de datos (DBloc1, DBloc2, ..., DBIocn) dentro del cual está presente el recurso; y
- para cada una de las direcciones (Adn, Adr2, ..., AdrN) obtenidas con anterioridad:
- la carga (110) de un bloque de datos actual (Deloci) correspondiente a una dirección actual (Adri);
- la obtención (120) de al menos un certificado de referencia (CertRi) del bloque de datos actual (DBloci); - la obtención (130) de al menos un certificado actual (CertCi) del bloque de datos actual (DBloci);
- la emisión ( 140) de una aseveración de validez (ArV) en función de dicho certificado de referencia (CertRi) y del certificado actual (CertCi);
Cuando un certificado actual no se corresponde con un certificado de referencia para una determinada dirección, la aseveración de validez es negativa. Por lo tanto, el bloque cargado se rechaza y no se copia en la memoria de acceso aleatorio. Por lo tanto, este bloque no se utiliza. Cuando el certificado actual es igual al certificado de referencia, la aseveración de validez es positiva; el bloque se copia en la memoria RAM y se puede utilizar.
Cuando un recurso requiere la carga de varios bloques de datos (porque el recurso es mayor que el volumen de un bloque), basta que una sola aseveración de validez sea negativa para que todos los bloques sean rechazados. Por lo tanto, el recurso no se carga en la memoria. Pueden darse entonces dos casos: o bien la solicitante (es decir, la aplicación o el sistema de carga) es capaz de gestionar la ausencia del recurso requerido y la ejecución continúa con normalidad; o bien, la solicitante no puede gestionar la ausencia del recurso y la ejecución finaliza con una excepción que conduce a la finalización de la acción de la solicitante (finalización de la aplicación o finalización del sistema).
Según una forma de realización particular, cuando una aseveración es negativa para un bloque actual, se vuelve a cargar el bloque actual, es decir, es objeto de lectura por segunda vez los datos correspondientes a este bloque. A continuación, se calcula un nuevo certificado sobre los datos objeto de lectura por segunda vez. Cuando la aseveración vuelve a ser negativa, el bloque actual se rechaza de manera definitiva. Dicha técnica, de doble verificación, permite protegerse contra lecturas erróneas, debidas, por ejemplo, a una degradación de la memoria física.
De este modo, esta técnica permite controlar solamente los datos útiles y no toda la información almacenada en el soporte físico. Lo que antecede da como resultado un ahorro de tiempo significativo, por ejemplo, al acceder a un recurso protegido (datos guardados en una memoria protegida) o al cargar completamente un sistema (por ejemplo, al iniciar un terminal). La autenticación solamente se realiza en el recurso (aplicación o datos) necesario para la operación. De este modo, los recursos se controlan solamente a medida que se utilizan y no todos en una sola y misma pasada.
A continuación, se describen formas de realización específicas de la presente técnica. Presentan varias formas de realizar la carga de recursos, bajo demanda, dependiendo de cómo se registre el certificado de referencia. Estas diferentes formas de realización permiten dar respuesta a problemas de acceso a los recursos o almacenamientos diferentes.
5.2. Descripción de una forma de realización
En esta forma de realización, se pone en práctica la técnica descrita con anterioridad para acelerar la puesta en marcha de un terminal de pago. A todos los efectos, se recuerda que un terminal de pago tiene la forma de un dispositivo que comprende una caja y al menos una tarjeta electrónica denominada placa base. Un terminal de pago también incluye un procesador de procesamiento seguro y una memoria protegida. Este procesador seguro y esta memoria protegida están dispuestos dentro de un recinto seguro en el terminal. El terminal de pago también incluye un teclado (por lo general un teclado que comprende teclas físicas) y una pantalla. El teclado se utiliza a menudo para realizar operaciones de entrada (por parte del comerciante, por ejemplo, para realizar la entrada de un importe a pagar por el usuario, y por parte del usuario, por ejemplo, para introducir un código confidencial de tarjeta bancaria). La pantalla se utiliza para realizar una visualización de datos, siendo estos datos, por ejemplo, los datos que permiten la interacción con el comerciante o con el usuario. Se ponen en práctica mecanismos para asegurar el control exclusivo de la pantalla y del teclado durante las operaciones de pago.
El terminal de pago también incluye, de manera opcional, un procesador no seguro, a veces denominado procesador multimedia o procesador de aplicaciones, y una memoria que tampoco es segura, utilizada por este procesador de aplicaciones. El procesador de aplicaciones por lo general está a cargo de ejecutar aplicaciones relacionadas con funciones de pago. De este modo, el encargado del tratamiento de la aplicación puede, por ejemplo, encargarse de la ejecución de las denominadas aplicaciones de fidelización o incluso de aplicaciones publicitarias.
Para funcionar, el terminal de pago cuenta con un software denominado sistema operativo. El sistema operativo por lo general se carga, cuando se inicia el terminal, desde una memoria de masa en donde se almacena. Además, en la mayoría de los casos, el sistema operativo utilizado es un sistema de tipo Linux. Dicho tipo de sistema se presta bien a una puesta en práctica de la presente técnica: de hecho, en sistemas del tipo Linux, todos los ficheros ejecutables del sistema se cargan completamente en la memoria de acceso aleatorio al inicio. La autenticidad de todos los ejecutables se verifica antes de cargarlos en la memoria RAM y ello sobre la totalidad de los ejecutables y de sus datos, lo que ralentiza el inicio del dispositivo. De hecho, debido a la criticidad de las operaciones realizadas en el terminal de pago, es necesario verificar esta autenticidad en el momento de la puesta en marcha. Este requisito se deriva en particular de las normas y especificaciones aplicadas por los fabricantes de terminales: el cumplimiento de estas normas permite recibir certificaciones que a menudo son esenciales para poder vender el terminal de pago a los clientes.
Por lo tanto, para poder reducir el tiempo de puesta en marcha del terminal, en esta forma de realización se utiliza un cargador de arranque (programa de carga) que pone en práctica esta técnica. Este programa de carga realiza, de forma tradicional, la carga de los recursos en memoria de acceso aleatorio. Las Figuras 3 y 4 ilustran la siguiente descripción, según dos formas de realización diferentes.
Para ello, el gestor de arranque dispone de una lista de recursos a cargar (LisRes). Esta lista de recursos está escrita dentro (o accesible desde) un sector de arranque (STRT) de un volumen físico (PHYS) de una memoria de masa del terminal de pago. Más concretamente, esta lista (ReadRes) se registra de forma segura (y posiblemente encriptada): contiene los recursos a cargar, el orden en que se cargan estos recursos; para cada uno de estos recursos, la lista incluye al menos una dirección de ubicación (Adri, Adr2, etc.) (en el volumen físico) correspondiente a un bloque de datos (DBloci, DBI0C2, etc.). En función de la magnitud del recurso, es posible que se requieran varias direcciones de bloque.
Además, para cada bloque, un certificado de referencia (CertRi) puede estar presente dentro de la lista de estos recursos (LisRes). Un certificado de referencia suele tener la forma de una firma digital. Esta firma digital se obtiene de la siguiente manera: se cifran los datos correspondientes al bloque (con una función hash que se puede conocer en sí misma) que entrega una huella y se aplica un cifrado a dicha huella que entrega la firma digital encriptada (o certificado).
De manera alternativa, es posible no tener, en la lista de estos recursos (LisRes), un certificado de referencia (CertRi) para cada bloque de datos. En este caso, los bloques de datos están firmados digitalmente y contienen sus propias firmas, tal como se muestra en la Figura 4. Cada bloque de datos tiene la forma de un conjunto de datos que comprende, por un lado, datos de recursos y, por otro lado, una firma digital (CertRi) de los datos de este recurso. Esta firma digital es el resultado:
- de una función hash aplicada a los datos del bloque, proporcionando un resultado de dicha función hash;
- de una función de cifrado de clave privada del resultado obtenido con anterioridad de dicha función hash.
El primer caso, la Figura 3, en donde el certificado de referencia (CertRi) está asociado a cada bloque de la lista de estos recursos (LisRes) tiene una ventaja en términos de seguridad porque el certificado está disponible directamente. Sin embargo, esta forma de realización requiere más espacio en el sector de arranque, lo que puede causar problemas en algunas configuraciones de hardware en donde este espacio es poco importante.
La alternativa, la Figura 4, tiene la ventaja de no requerir demasiado espacio en el sector del arranque. Los datos del bloque se firman digitalmente con anterioridad y se integran en el bloque en el momento de su escritura (durante la fabricación del terminal o durante su parametraje). Por otro lado, esta solución podría ser un poco menos segura: es posible que un intruso, que tendría conocimiento de la clave privada utilizada para cifrar los elementos resultantes de la función hash, pudiera realizar tanto la reposición de los datos del bloque como la reposición del certificado de este mismo bloque, y esto teniendo que gestionar una sola ubicación en el medio físico.
Es por ello que se puede contemplar una segunda alternativa, tal como se describe en la Figura 5. En esta segunda alternativa, la lista de recursos (LisRes) incluye una dirección de ubicación para cada bloque, tal como en el primer y segundo caso. Además, la lista de recursos (LisRes) contiene, para cada bloque, una dirección de ubicación del certificado. El módulo de carga realiza entonces, por una parte, una carga de los datos del bloque en la dirección indicada para estos datos y una carga del certificado correspondiente a estos datos del bloque en la dirección indicada para este certificado. De forma complementaria, los certificados se disponen, sobre el soporte físico, en direcciones que no necesariamente corresponden al orden de los bloques, y ello es así con el fin de no permitir el descubrimiento del certificado de forma iterativa. El posicionamiento de los certificados sobre el soporte físico se realiza por tanto según un orden aleatorio o pseudoaleatorio, en una zona de posicionamiento predeterminada. Con esta segunda alternativa se resuelven los problemas de las dos primeras formas de realización. Por supuesto, este tercer caso solamente es interesante cuando la longitud de las direcciones donde se almacenan los certificados es menor que el tamaño del propio certificado. Si este no es el caso (es decir, el tamaño del certificado es menor o igual que el tamaño de la dirección), la primera forma de realización sigue siendo la más interesante.
Cualquiera que sea la alternativa elegida, el gestor de carga realiza una carga de los recursos, en el orden indicado en la lista de recursos, cargando los bloques correspondientes a estos recursos y comprobando la autenticidad de estos bloques (emisión de una aseveración de autenticidad). Cuando un bloque no es auténtico, no se copia a la memoria RAM. En un modo de carga segura, la carga se detiene tan pronto como una aseveración de autenticidad es negativa.
En términos concretos, cada bloque es objeto de lectura de forma independiente: el bloque en cuestión se pasa como entrada, por el módulo de carga, a un módulo de verificación. El módulo de verificación realiza una serie de cálculos basados en el bloque recibido. El módulo de verificación también toma como entrada un número de bloque o una dirección; el número (o dirección) se utiliza para la obtención datos de referencia a nivel de lista. Este dato de referencia puede ser un certificado de referencia (certificado correspondiente al elemento resultante de la función hash del bloque de datos al que se aplica una función criptográfica de clave pública o privada): en este caso, el certificado es una firma digital. Tal como se describió con anterioridad, el certificado de referencia se puede integrar directamente en la lista. En cuyo caso, el módulo de verificación realiza un cálculo criptográfico similar sobre los datos del bloque: calcula un hash sobre los datos del bloque actual y aplica una función criptográfica de clave pública o privada sobre dicho elemento hash. El módulo obtiene así un certificado actual y compara este certificado actual con el certificado de referencia. Si los dos coinciden, la aseveración de validez es positiva. De lo contrario, la aseveración de validez es negativa y se cancela la carga. La ventaja de esta forma de realización es que no reduce el espacio de almacenamiento de cada bloque de datos.
En la primera alternativa, el bloque de datos pasado al módulo de verificación ya incluye su propia firma digital precalculada (precalculada en fábrica, por ejemplo, durante la instalación del software o durante la configuración de los parámetros). Por lo tanto, no es necesario realizar este cálculo. La firma digital se extrae de los datos y se descifra: se obtiene así un elemento hash descifrado (este es el certificado de referencia). A partir de ese momento, el módulo de verificación realiza un cálculo hash sobre los datos actuales del bloque (es por tanto el certificado actual). Si los dos coinciden, se emite una aseveración de validez positiva. De lo contrario, se emite una aseveración de validez negativa. La ventaja de esta forma de realización es que no se necesitan certificados de referencia pregrabados en la lista, lo que permite tener más espacio de almacenamiento en la zona de arranque.
En la segunda alternativa, el módulo de verificación extrae el certificado de su dirección, proporcionada en la lista, y realiza cálculos similares o idénticos a los ya realizados con anterioridad, con el fin de entregar las aseveraciones de autenticidad.
5.3. Otras características y beneficios
En relación con la Figura 6, se describe un dispositivo, tal como un terminal de pago o un teléfono inteligente. Dicho dispositivo está configurado para poner en práctica una carga de recursos según el método descrito con anterioridad.
Por ejemplo, el dispositivo comprende una memoria 61 que consiste en una memoria intermedia, una unidad de procesamiento 62, equipada, por ejemplo, con un microprocesador, y controlada por el programa informático 63, poniendo en práctica un método de carga de recursos.
En la inicialización, las instrucciones de código del programa informático 63 se cargan, por ejemplo, en una memoria antes de ser ejecutadas por el procesador de la unidad de procesamiento 62. La unidad de procesamiento 62 recibe como entrada al menos un dato representativo de un identificador de recurso a cargar. El microprocesador de la unidad de procesamiento 62 pone en práctica las etapas del método de carga de recursos, según las instrucciones del programa informático 63 para copiar, en la memoria de acceso aleatorio, el contenido de uno o más bloques de datos registrados en un medio físico mediante verificación, bloque a bloque, de la autenticidad de estos, con el fin de cargar, en un momento dado, solamente los bloques cuyo uso se requiera en relación con el recurso solicitado.
Para ello, el dispositivo comprende, además, de la memoria intermedia 61, medios de comunicación, medios de transmisión de datos y eventualmente un procesador de cifrado. Cuando se pone en práctica un procesador de cifrado, de manera ventajosa es un procesador seguro, que tiene acceso a una memoria protegida (Msec) dentro de la cual se registra una lista de recursos. Esta lista de recursos es accesible al procesador de cifrado con el fin de permitir una comparación de un certificado de referencia y de un certificado actual, registrándose el certificado de referencia en el momento de la inicialización o parametrización del dispositivo. Para ello, el procesador del tratamiento incluye medios de identificación únicos. Estos medios únicos de identificación permiten asegurar la autenticidad del procesador.
Además, el dispositivo comprende, un circuito electrónico que permite la gestión e interrupción de las solicitudes de acceso a los recursos, con el fin de que estas solicitudes se procesen únicamente cuando los recursos en cuestión hayan sido verificados según el método de gestión descrito con anterioridad.

Claims (6)

REIVINDICACIONES
1. Método de carga de un recurso informático, mediante un dispositivo que comprende un procesador y una memoria de acceso aleatorio, realizándose dicha carga dentro de dicha memoria de acceso aleatorio de dicho dispositivo a partir de una memoria de masa, siendo grabado dicho recurso en dicha memoria de masa a través de al menos un bloque de datos, caracterizado dicho método porque comprende las etapas siguientes, para cada uno de los al menos un bloque de datos:
- obtención (100) de al menos una dirección (Adn, Adr2, ..., AdrN) correspondiente a al menos un bloque de datos (DBloci, DBloc2, ..., DBIOCN) dentro del cual se registra parcialmente el recurso; comprendiendo dicha etapa de obtención (100) dicha al menos una dirección (Adri, Adr2, ..., AdrN):
- una etapa de intercepción de una solicitud de obtención de dicho recurso;
- una etapa de determinación, en función de una lista de recursos (LisRes), de dicha al menos una dirección (Adri, Adr2, ..., AdrN) de dicho recurso, siendo grabada dicha lista de recursos (LisRes) dentro de una memoria protegida (Msec) de dicho dispositivo;
y para dicha al menos una dirección actual (Adri) previamente obtenida:
- carga (110) de un bloque de datos actual (DBloci) en función de dicha dirección actual (Adri);
- obtención (120) de al menos un certificado de referencia (CertRi) del bloque de datos actual (DBloci), siendo dicho certificado de referencia una firma digital encriptada de dicho bloque de datos actual;
- obtención (130) de al menos un certificado actual (CertCi) del bloque de datos actual (DBloci), siendo dicho certificado actual una firma digital encriptada de dicho bloque de datos actual;
- emisión (140) de una aseveración de validez (ArV) en función de dicho certificado de referencia (CertRi) y el certificado actual (CertCi), cuando dicho certificado de referencia y dicho certificado actual sean idénticos;
- copia de dicho bloque de datos actual (DBloci) dentro de la memoria RAM de dicho dispositivo, cuando dicha aseveración de validez (ArVi) es positiva.
2. Método de carga según la reivindicación 1, caracterizado porque dicha etapa de obtención (120) de al menos un certificado de referencia (CertRi) del bloque de datos actual (DBloci) comprende una etapa de búsqueda de dicho certificado de referencia (CertRi) dentro de una lista de recursos (LisRes), en función de dicha dirección actual (Adri).
3. Método de carga según la reivindicación 1, caracterizado porque dicha etapa de obtención (120) de al menos un certificado de referencia (CertR) del bloque de datos actual (DBloc) comprende una etapa de extracción de dicho certificado de referencia (CertR), a partir de los datos del bloque de datos actual (DBloc), datos cargados en dicha dirección actual (Adr).
4. Método de carga según la reivindicación 1, caracterizado porque dicha etapa de obtención (120) de al menos un certificado de referencia (CertR) del bloque de datos actual (DBloc) comprende una etapa de carga de dicho certificado de referencia (CertR) a partir de una dirección de dicho certificado de referencia (AdrCi), obteniéndose dicha dirección de dicho certificado de referencia (AdrCi) a partir de una lista de recursos (LisRes) de los cuales al menos una entrada está asociada a dicha dirección actual (Adr) y a dicha dirección de dicho certificado de referencia (AdrCi).
5. Módulo electrónico de carga de un recurso informático dentro de un dispositivo que comprende un procesador y una memoria de acceso aleatorio, realizándose dicha carga dentro de dicha memoria de acceso aleatorio de dicho dispositivo a partir de una memoria de masa, siendo grabado dicho recurso en dicha memoria de masa por intermedio de al menos un bloque de datos, comprendiendo dicho módulo medios:
- de obtención de al menos una dirección (Adr, etc.) correspondiente a al menos un bloque de datos (DBloc, etc.) dentro del cual se registra parcialmente el recurso, cuyos medios de obtención de dicha al menos una dirección (Adr, etc.) ponen en práctica medios:
- de intercepción de una solicitud de obtención de dicho recurso;
- de determinación, en función de una lista de recursos (LisRes), de dicha al menos una dirección (Adri, ...,) de dicho recurso, grabándose dicha lista de recursos (LisRes) en una memoria protegida (Msec) de dicho dispositivo;
- de carga de un bloque de datos actual (DBloc) en función de dicha dirección actual (Adr).
- de obtención de al menos un certificado de referencia (CertRi) del bloque de datos actual (DBIoci), siendo dicho certificado de referencia una firma digital encriptada de dicho bloque de datos actual;
- de obtención de al menos un certificado actual (CertCi) del bloque de datos actual (DBIoci), siendo dicho certificado actual una firma digital encriptada de dicho bloque de datos actual;
- de emisión de una aseveración de validez (ArVi) en función de dicho certificado de referencia (CertRi) y de dicho certificado actual (CertCi), cuando dicho certificado de referencia y dicho certificado actual sean idénticos;
- de copiar dicho bloque de datos actual (DBIoci) dentro de la memoria de acceso aleatorio de dicho dispositivo.
6. Producto de programa informático descargable desde una red de comunicación y/o almacenado en un medio legible por ordenador y/o ejecutable por un microprocesador, caracterizado porque comprende instrucciones de código de programa para la ejecución de un método de carga según la reivindicación 1, cuando se ejecuta en un ordenador.
ES16202743T 2015-12-07 2016-12-07 Método de carga de un recurso informático en un dispositivo electrónico, módulo electrónico y programa informático correspondiente Active ES2949313T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1561948A FR3044786B1 (fr) 2015-12-07 2015-12-07 Procede de chargement d'une ressource informatique au sein d'un dispositif electronique, module electronique et programme d'ordinateur correspondant

Publications (1)

Publication Number Publication Date
ES2949313T3 true ES2949313T3 (es) 2023-09-27

Family

ID=55862873

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16202743T Active ES2949313T3 (es) 2015-12-07 2016-12-07 Método de carga de un recurso informático en un dispositivo electrónico, módulo electrónico y programa informático correspondiente

Country Status (5)

Country Link
US (1) US10567176B2 (es)
EP (1) EP3179400B1 (es)
CA (1) CA2950841A1 (es)
ES (1) ES2949313T3 (es)
FR (1) FR3044786B1 (es)

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0882339B1 (en) * 1995-06-29 2011-01-19 Igt Electronic casino gaming system with improved play capacity, authentication and security
US6463535B1 (en) * 1998-10-05 2002-10-08 Intel Corporation System and method for verifying the integrity and authorization of software before execution in a local platform
AUPQ321699A0 (en) * 1999-09-30 1999-10-28 Aristocrat Leisure Industries Pty Ltd Gaming security system
CN1423766A (zh) * 2000-02-17 2003-06-11 通用仪器公司 提供安全控制软件或固件代码下载和接收下载代码的计算装置的安全操作的方法和装置
US7203841B2 (en) * 2001-03-08 2007-04-10 Igt Encryption in a secure computerized gaming system
US20040054952A1 (en) * 2002-09-13 2004-03-18 Morrow James W. Device verification system and method
US6782477B2 (en) * 2002-04-16 2004-08-24 Song Computer Entertainment America Inc. Method and system for using tamperproof hardware to provide copy protection and online security
DE10350993A1 (de) * 2003-10-30 2005-05-25 Siemens Ag Firmware-Plagiat-Erkennung
CN101226569A (zh) * 2007-01-19 2008-07-23 国际商业机器公司 在虚拟机中验证代码模块的方法及装置
EP2224740A1 (en) * 2009-02-27 2010-09-01 Nxp B.V. Detecting occlusion
DE102010002472A1 (de) * 2010-03-01 2011-09-01 Robert Bosch Gmbh Verfahren zum Verifizieren eines Speicherblocks eines nicht-flüchtigen Speichers
US8782435B1 (en) * 2010-07-15 2014-07-15 The Research Foundation For The State University Of New York System and method for validating program execution at run-time using control flow signatures
US20120331303A1 (en) * 2011-06-23 2012-12-27 Andersson Jonathan E Method and system for preventing execution of malware
JP6181004B2 (ja) * 2014-06-20 2017-08-16 株式会社東芝 メモリ管理装置、プログラム、及び方法

Also Published As

Publication number Publication date
CA2950841A1 (fr) 2017-06-07
FR3044786A1 (fr) 2017-06-09
FR3044786B1 (fr) 2018-07-13
EP3179400A1 (fr) 2017-06-14
EP3179400B1 (fr) 2023-04-12
US20170163428A1 (en) 2017-06-08
US10567176B2 (en) 2020-02-18

Similar Documents

Publication Publication Date Title
US9535712B2 (en) System and method to store data securely for firmware using read-protected storage
US11113404B2 (en) Securing operating system configuration using hardware
RU2388051C2 (ru) Случайный пароль, автоматически формируемый базовой системой ввода-вывода (bios) для защиты устройства хранения данных
JP5007867B2 (ja) 安全な環境におけるプロセッサ実行を制御するための装置
CN103914658B (zh) 终端设备的安全启动方法及终端设备
EP3644181A1 (en) Embedded program secure boot method, apparatus and device, and storage medium
CN103069384A (zh) 用从储存设备加载的操作系统代码安全地引导主机设备的主机设备和方法
US10536274B2 (en) Cryptographic protection for trusted operating systems
US20150058979A1 (en) Processing system
TW201500960A (zh) 在配有適用統一可延伸韌體介面(uefi)之韌體之計算裝置中的安全性變數變化檢測技術
JP2007133875A (ja) コードイメージを安全に更新してブーティングする方法及び装置
BRPI0801772B1 (pt) Método implementado por computador, sistema de tratamento de informação e meio de armazenamento legível por computador
NO335189B1 (no) Sikkert databehandlingssystem
US20220382874A1 (en) Secure computation environment
US20150242630A1 (en) Systems and methods for securing bios variables
CN110020561B (zh) 半导体装置和操作半导体装置的方法
US20200202004A1 (en) Secure initialization using embedded controller (ec) root of trust
US10642984B2 (en) Secure drive and method for booting to known good-state
US20160350537A1 (en) Central processing unit and method to verify mainboard data
KR20170102285A (ko) 보안 요소
Ruan et al. Boot with integrity, or don’t boot
CN101213556B (zh) 评估令牌实现的计算机系统的机制
ES2949313T3 (es) Método de carga de un recurso informático en un dispositivo electrónico, módulo electrónico y programa informático correspondiente
KR20050061287A (ko) 서브시스템 장치를 마더보드에 바인딩하는 방법 및 구조물
WO2016024967A1 (en) Secure non-volatile random access memory