ES3057636T3 - Method for running secure code, corresponding devices, system and programs - Google Patents

Abstract

La invención se refiere a un método para controlar la ejecución de una aplicación AppO, implementándose el método dentro de la aplicación AppO, ejecutándose la aplicación AppO en un dispositivo electrónico denominado dispositivo en ejecución (B), estando conectado el dispositivo en ejecución (B) a un dispositivo llamante (A) a través de una red de comunicación, comprendiendo el método los siguientes pasos: - Recibir (10), desde el dispositivo llamante (A), una estructura de datos de tiempo de ejecución (StrExec), que comprende al menos una grabación, comprendiendo cada grabación al menos un campo de datos que incluye un nombre de función codificado (CFN_x); - Guardar (20) la estructura de datos de tiempo de ejecución (StrExec) en una zona de memoria específica (MZone); - Para cada grabación actual (CUEnr) de la estructura de datos de tiempo de ejecución (StrExec), implementar (30) una función que lleva un nombre de función decodificado (UCFN_x) correspondiente al nombre de función codificado (CFN_x), cuando la función que lleva un nombre de función decodificado (UCFN_x) de la aplicación AppO puede asociarse con el nombre de función codificado (CFN_x). (Traducción automática con Google Translate, sin valor legal)

Description

[0001] DESCRIPCIÓN

[0002] Método de ejecución de código segurizado, dispositivos, sistema y programas correspondientes

[0003] 1. Campo

[0004] La invención se refiere a la segurización de los dispositivos de usuario. La invención se refiere más en particular a la segurización de terminales de comunicación en el marco de tratamientos realizados de forma remota. En particular, la invención se refiere a la segurización de la ejecución de código con un dispositivo electrónico, denominado dispositivo de ejecución, cuando la ejecución de este código se controla de forma remota con un dispositivo electrónico llamante. Un dispositivo llamante puede adoptar, en particular, la forma de un servidor de tratamiento o un servidor de segurización o un servidor de transacciones. Más en particular, la invención encuentra una aplicación en el marco de una implementación entre un terminal (dispositivo de ejecución) y un servidor (dispositivo llamante), que desea verificar la integridad del dispositivo de ejecución y/o la integridad de un código que debe ser ejecutado por el dispositivo de ejecución. No obstante, la invención puede implementarse en otros tipos de sistemas comprendiendo un dispositivo de ejecución y un dispositivo llamante.

[0005] 2. Técnica anterior

[0006] A medida que los sistemas distribuidos se vuelven omnipresentes, los mecanismos de seguridad deben estar preparados para hacer frente a las crecientes amenazas a las que se enfrentan estos sistemas. Los mecanismos de seguridad existentes para los sistemas distribuidos se basan en la autenticación de los clientes y los servidores y en la protección de los datos en curso de tratamiento o de comunicación con la ayuda de mecanismos de cifrado conocidos en canales segurizados. Estos mecanismos de seguridad no permiten autenticar las ejecuciones de programas en los clientes o los servidores, porque los clientes, los servidores y los programas en curso de ejecución pueden verse comprometidos una vez que los clientes y los servidores hayan superado una fase de autenticación.

[0007] Así, por ejemplo, un terminal de comunicación de un usuario dispone de una aplicación que ha descargado de un servicio de suministro de aplicaciones ("store"). Una vez descargada e instalada en el terminal de comunicación, la aplicación entra en comunicación con un servidor, para la implementación de uno o más servicios. La visión tradicional de una implementación de este tipo se basa en la suposición de que el servidor implementa todos los servicios solicitados por la aplicación del terminal de comunicación. Así, la mayor parte del trabajo de segurización recae en el servidor, que es objeto de todas las precauciones. Ahora bien, cada vez más, los terminales de comunicación de los usuarios realizan operaciones sensibles, tanto con respecto al usuario poseedor del terminal de comunicación como con el o los servidores con los cuales intercambia datos, que pueden resultar extremadamente sensibles (datos de identidad, datos sanitarios o datos relativos a la salud, datos de pagos, etc.).

[0008] Las técnicas existentes que implementan una raíz de confianza (estática "static root trust" o dinámica "dynamic root trust" o de hardware "hardware root trust") basada en la compatibilidad de módulos de plataforma segurizada (TPM, "Trusted Platform Module") constituyen un primer elemento para la validación de la ejecución remota de código en un anfitrión (dispositivo de ejecución) potencialmente no segurizado: la gran mayoría de los terminales de comunicación incluyen TEE ("Trusted Execution Environment", entornos de ejecución confiables) y/o SE ("Secure Element", elementos seguros) que pueden realizar operaciones sensibles. Una raíz de confianza se implementa esencialmente validando la firma de un código ejecutable justo antes de su ejecución. Como tales, estos mecanismos no abordan las posibles vulnerabilidades en el momento de la ejecución en los sistemas de software complejos que invocan a módulos enlazados dinámicamente, de forma local o remota, ni la sustitución dinámica de regiones de ejecutables por componentes maliciosos en el núcleo anfitrión del dispositivo de ejecución (directamente en el sistema operativo).

[0009] Los mecanismos existentes para validar la ejecución remota están destinados a la detección de violaciones de seguridad en un dispositivo de ejecución que ejecuta programas por cuenta de un dispositivo llamante y/o siguiendo las instrucciones del dispositivo llamante. Un enfoque suele consistir en realizar una validación del código justo antes de la ejecución (validación estática). Este enfoque no es suficiente, ya que un módulo de gestión de memoria o de sistema de archivos comprometido puede suministrar el código de origen a la función de verificación durante la ejecución del código comprometido. La validación estática de las ejecuciones también se ve limitada por su incapacidad para resolver los problemas relacionados con la inyección de código en el momento de la ejecución, lo que es típico de algunos virus.

[0010] Ha surgido la necesidad de un mecanismo que valide un proceso en el momento de la ejecución. También ha surgido la necesidad de un mecanismo que permita al dispositivo llamante iniciar la ejecución de código en el dispositivo de ejecución de manera dinámica, es decir, de una manera que consista en cambiar el flujo de ejecución. El problema específico abordado es la autenticación dinámica (es decir, en el momento de la ejecución) del código que se ejecuta en un dispositivo de ejecución, potencialmente no aprobado, a petición de un dispositivo llamante. Tal escenario es típico en el mundo actual de Internet, donde las aplicaciones se ejecutan en los terminales de usuario para responder a una solicitud de un cliente. Las soluciones existentes que abordan este problema o problemas similares suponen la disponibilidad de componentes fiables en el servidor potencialmente no aprobado y las soluciones más prácticas y aceptables disponibles usan el módulo de plataforma segurizada (TPM). Sin embargo, estas soluciones no permiten modificar el flujo de ejecución de un código (en particular, el código remoto), y ello con total seguridad, sin la necesidad de actualizar el software que se ejecuta en el dispositivo de ejecución. Más en particular, en el contexto descrito anteriormente, ninguna solución hace posible ejecutar programas en un dispositivo de manera segurizada, ni siquiera usando plataformas segurizadas. Los enfoques tradicionales para la ejecución remota de código se presentan esencialmente de dos formas:

[0011] - ejecutar código nativo en el dispositivo de ejecución; este código nativo debe descargarse desde el dispositivo llamante al dispositivo de ejecución o generarse con la ayuda de un compilador (en este segundo caso, se trata de un código fuente que se descarga desde el dispositivo llamante al dispositivo de ejecución);

[0012] - o ejecutar una secuencia de instrucciones con la ayuda de un intérprete (en este caso, se trata de un código de secuencia de instrucciones que se descarga desde el dispositivo llamante al dispositivo de ejecución). Ahora bien, cada una de estas soluciones tiene limitaciones, en particular, ejecutar código nativo es arriesgado porque potencialmente permite a los atacantes ejecutar programas arbitrarios y tomar el control del dispositivo de ejecución (este tipo de problema es muy conocido por los compiladores denominados "Just-In-Time", entre ellos WebAssembly, etc.). Además, los intérpretes son lentos y requieren que se implementen todas las funcionalidades pertinentes. Además, las secuencias de instrucciones no se pueden optimizar (a diferencia de un código binario compilado).

[0013] Por lo tanto, existe la necesidad de una solución de ejecución remota de código que permita tener en cuenta estas problemáticas. El documento del estado de la técnica EP1850261-A1 describe diferentes técnicas de ofuscación de código.

[0014] 3. Compendio

[0015] El método propuesto por los autores de la invención no plantea estos problemas de la técnica anterior. De hecho, se propone un método de control de la ejecución de un código de una aplicación, método implementado por medio de un dispositivo electrónico, denominado dispositivo de ejecución (ResB, B), dentro del cual dicha aplicación es ejecutable.

[0016] Más en particular, se describe un método de control de la ejecución de una aplicación AppO, método implementado dentro de la aplicación AppO, ejecutándose dicha aplicación AppO en un dispositivo electrónico, denominado dispositivo de ejecución, estando dicho dispositivo de ejecución conectado a un dispositivo llamante por medio de una red de comunicación. El método comprende las etapas siguientes:

[0017] - recepción, desde el dispositivo llamante, de una estructura de datos de ejecución, comprendiendo al menos un registro, comprendiendo cada registro al menos un campo de datos comprendiendo un nombre de función codificado;

[0018] - salvaguarda, dentro de un área de memoria específica, de dicha estructura de datos de ejecución;

[0019] - para cada registro actual de la estructura de datos de ejecución implementada de una función que lleva un nombre de función decodificado correspondiente al nombre de función codificado, cuando la función que lleva un nombre de función decodificado de la aplicación AppO puede asociarse al nombre de función codificado. Por lo tanto, es posible implementar una ejecución segurizada de una o más funciones y, al mismo tiempo, garantizar que un dispositivo malicioso no pueda realizar búsquedas o inferencias de la ejecución. El o los resultados de la ejecución de la función que lleva un nombre de función decodificado pueden transmitirse al dispositivo llamante para controlar un flujo de ejecución por parte de dicho dispositivo llamante, con nombres de funciones ocultos. Por lo tanto, un atacante no puede interferir fácilmente ni comprender la naturaleza de las funciones y los resultados que se implementan en el marco del control de la ejecución de las funciones implementadas por el dispositivo llamante.

[0020] Según una característica particular, la etapa de implementación de la función que lleva un nombre de función decodificado correspondiente al nombre de función codificado comprende las etapas siguientes:

[0021] - obtener el nombre de función decodificado a partir del nombre de función codificado de dicho registro actual; - cuando la obtención del nombre de función decodificado a partir del nombre de función codificado es positiva, ejecución de la función que lleva el nombre decodificado.

[0022] De este modo, es posible introducir deliberadamente errores en la estructura de datos de ejecución para desviar la atención de un dispositivo atacante o malicioso.

[0023] Según una característica particular, la etapa de ejecución de la función que lleva un nombre de función decodificado, denominada función actual, comprende las etapas siguientes:

[0024] - opcionalmente, obtener, dentro del registro actual, uno o más parámetros de ejecución de la función actual FCour;

[0025] - intento de ejecución de la función actual FCour con el o los parámetros de ejecución opcionales obtenidos anteriormente, con un mecanismo de excepción en la ejecución;

[0026] - cuando no se produce ninguna excepción en la ejecución, obtener el resultado de la ejecución de la función actual;

[0027] - escribir el resultado de la función actual en un área de memoria específica del registro actual y/o del registro siguiente de la estructura de datos de ejecución.

[0028] De este modo, es posible serializar la ejecución de varias funciones gestionando el posible fallo en la ejecución de estas funciones de una manera sencilla y eficiente.

[0029] Según una realización particular, el método comprende además una etapa de obtención, dentro del registro actual, de al menos una condición previa de ejecución de dicha función actual y la etapa de intento de ejecución de la función actual FCour se activa solo cuando se cumple dicha al menos una condición previa.

[0030] De este modo, la ejecución de funciones no se limita a una simple serie lineal y, por lo tanto, puede tener en cuenta las especificidades del dispositivo de ejecución, de su sistema operativo o de su máquina virtual. Según una realización particular, la etapa de implementación de la función que lleva el nombre de función decodificado correspondiente al nombre de función codificado comprende una etapa de introspección de dicha aplicación, para proporcionar un resultado de introspección positivo cuando una función que lleva el nombre de función decodificado se identifica entre el conjunto de funciones de dicha aplicación.

[0031] De este modo, se garantiza la confidencialidad de los nombres de función.

[0032] Según una característica particular, la etapa de obtención del nombre de función decodificado a partir del nombre de función codificado de dicho registro actual comprende una etapa de búsqueda de la presencia de una función existente a partir de una anotación comprendiendo el nombre de función codificado, estando dicha anotación asociada a la función que lleva el nombre de función decodificado.

[0033] Como resultado, se simplifica el desarrollo de aplicaciones.

[0034] Según una realización particular, dicha etapa de recepción de la estructura de datos de ejecución está precedida por el establecimiento de un enlace de comunicación segurizado.

[0035] Según una característica particular, dicha estructura de datos de ejecución está cifrada y el método comprende una etapa de descifrado de la estructura de datos de ejecución.

[0036] Según otro aspecto, la invención se refiere también a un dispositivo configurado para realizar un control de ejecución de una aplicación AppO, implementándose dicho control dentro de la aplicación AppO, ejecutándose dicha aplicación AppO en un procesador de dicho dispositivo electrónico, denominado dispositivo de ejecución, estando conectado dicho dispositivo de ejecución a un dispositivo llamante por medio de una red de comunicación.

[0037] Un dispositivo de ejecución de este tipo comprende los medios siguientes:

[0038] - recibir, desde el dispositivo llamante, una estructura de datos de ejecución, comprendiendo al menos un registro, comprendiendo cada registro al menos un campo de datos comprendiendo un nombre de función codificado;

[0039] - salvaguardar, dentro de un área de memoria específica, de dicha estructura de datos de ejecución;

[0040] - para cada registro actual de la estructura de datos de ejecución implementada de una función que lleva un nombre de función decodificado correspondiente al nombre de función codificado, cuando la función que lleva un nombre de función decodificado de la aplicación AppO puede asociarse al nombre de función codificado. Según un aspecto complementario, la invención se refiere también a un sistema de ejecución de un código. Un sistema de este tipo comprende al menos un dispositivo llamante que adopta la forma de un dispositivo electrónico de control (denominado dispositivo llamante) como se describió anteriormente y al menos un dispositivo electrónico de ejecución como se describió anteriormente accesible desde el dispositivo llamante. Además, en el marco de la presente invención, se entiende que una etapa de recepción proveniente de un dispositivo corresponde a una etapa de emisión de este dispositivo y a la inversa, de modo que los métodos descritos pueden ser implementados simétricamente por el experto en la materia.

[0041] Según una implementación preferida, las diversas etapas de los métodos según la invención son implementadas por uno o más programas de software o programas informáticos, comprendiendo instrucciones de software destinadas a ser ejecutadas por un procesador de datos de un dispositivo de ejecución según la invención y que están diseñadas para controlar la ejecución de las diversas etapas de los métodos, implementadas en el terminal de comunicación, el dispositivo electrónico de ejecución y/o el dispositivo de control, en el marco de una distribución de los tratamientos que se van a realizar y determinados por un código fuente con una secuencia de instrucciones.

[0042] En consecuencia, la invención también tiene por objeto programas que pueden ser ejecutados por un ordenador o por un procesador de datos, incluyendo estos programas instrucciones para controlar la ejecución de las etapas de los métodos tal como se han mencionado más arriba.

[0043] Un programa puede usar cualquier lenguaje de programación y estar en forma de código fuente, código objeto o código intermedio entre código fuente y código objeto, tal como en una forma parcialmente compilada, o en cualquier otra forma deseable.

[0044] La invención también tiene por objeto un soporte de informaciones legible por un procesador de datos y comprendiendo instrucciones de un programa, tal como se menciona anteriormente.

[0045] El soporte de informaciones puede ser cualquier entidad o dispositivo capaz de almacenar el programa. Por ejemplo, el soporte puede comprender 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 soporte móvil (tarjeta de memoria) o un disco duro o un SSD.

[0046] Por otra parte, el soporte de informaciones puede ser un soporte 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 o por otros medios. El programa según la invención puede descargarse, en particular, en una red de tipo Internet.

[0047] Como alternativa, el soporte de informaciones puede ser un circuito integrado en donde está incorporado el programa, estando el circuito adaptado para ejecutar, o para ser usado en su ejecución, el método en cuestión. Según una realización, la invención se implementa por medio de componentes de software y/o hardware. En este sentido, el término "módulo" puede corresponder en este documento tanto a un componente de software como a un componente de hardware o a un conjunto de componentes de hardware y software.

[0048] Un componente de software corresponde a uno o varios programas informáticos, uno o varios subprogramas de un programa o, de manera más general, a cualquier elemento de un programa o de un software capaz de implementar una función o un conjunto de funciones, según lo que se describe más adelante 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, descodificador, enrutador, etc.) y es capaz de acceder a los recursos de hardware de esta entidad física (memorias, soportes de registro, buses de comunicación, tarjetas electrónicas de entrada/salida, interfaces de usuario, etc.).

[0049] De la misma manera, un componente de hardware corresponde a cualquier elemento de un conjunto de hardware capaz de implementar una función o un conjunto de funciones, según lo que se describe más adelante para el módulo en cuestión. Puede tratarse de un componente de hardware programable o con un procesador integrado para la ejecución de software, por ejemplo, un circuito integrado, una tarjeta inteligente, una tarjeta de memoria, una tarjeta electrónica para la ejecución de un firmware, etc.

[0050] Obviamente, cada componente del sistema descrito anteriormente implementa sus propios módulos de software.

[0051] Las diferentes realizaciones mencionadas anteriormente se pueden combinar entre sí para implementar la invención.

[0052] 4. Dibujos

[0053] Otras características y ventajas de la invención se apreciarán con mayor claridad tras la lectura de la siguiente descripción de una realización preferida, proporcionada a modo de mero ejemplo ilustrativo y no limitativo, y de los dibujos adjuntos, entre los que:

[0054] - la figura 1 describe un sistema en donde se puede implementar la invención;

[0055] - la figura 2 describe el principio general del método objeto de la invención;

[0056] - la figura 3 describe una realización específica del método de tratamiento;

[0057] - la figura 4 presenta la estructura de la aplicación de origen;

[0058] - la figura 5 ilustra una arquitectura de un dispositivo llamante capaz de implementar un método de tratamiento de la invención;

[0059] 5. Descripción de las realizaciones

[0060] 5.1. Recordatorios sobre el principio

[0061] Como se ha explicado anteriormente, el principio general de la invención consiste en transmitir, a un dispositivo de ejecución (B), un conjunto de instrucciones (Elnstr) y/u órdenes, de forma remota, desde un dispositivo llamante (A). En lo que sigue y en lo anterior, se considera que un dispositivo electrónico de ejecución, un dispositivo de ejecución, un terminal y un cliente hacen referencia al dispositivo de ejecución (B). Del mismo modo, se considera que un dispositivo llamante, un dispositivo electrónico llamante, un servidor y un dispositivo de control hacen referencia al dispositivo llamante (A). El dispositivo llamante (A) y el dispositivo de ejecución (B) pueden ser remotos y estar conectados a través de una red de comunicación. El dispositivo llamante (A) y el dispositivo de ejecución (B) pueden estar integrados dentro de un único dispositivo electrónico.

[0062] En una realización específica, descrita a continuación, el dispositivo llamante (A) es un servidor, que desea garantizar el cumplimiento (con ciertos requisitos, en particular en términos de integridad y de seguridad) de un dispositivo de ejecución (B), que es un terminal de comunicación.

[0063] Por lo tanto, se produce una situación en donde un dispositivo electrónico llamante desea que un dispositivo electrónico llamado realice una o más funciones, en particular para verificar que el dispositivo de ejecución (B) cumple ciertos criterios en términos de seguridad. Un objetivo de la invención es asegurar que la ejecución de estas funciones de forma remota esté garantizada, tanto para la parte llamante como para la parte llamada, y que las medidas de seguridad permitan evitar que un dispositivo electrónico de un tercero, denominado dispositivo fraudulento, pueda requerir la ejecución por parte del dispositivo de ejecución (B) cuando no está autorizado para hacerlo. Un objetivo es también garantizar que el dispositivo de ejecución (B) cumpla con ciertos requisitos del dispositivo llamante (en particular en términos de actualización). Por último, el objetivo es permitir una cierta evolución de los requisitos del dispositivo llamante o minimizar los riesgos de reproducibilidad, tanto en el dispositivo de ejecución (B) como en un dispositivo intermedio de "terceros". Antes de describir en detalle los diversos mecanismos que permiten lograr estos resultados, se describe la arquitectura técnica en donde se implementa la invención, en relación con la figura 1.

[0064] Un dispositivo electrónico A, denominado llamante, comprende un procesador (P), una memoria (M) y medios de transmisión de datos (TRD). Estos medios de transmisión de datos (TRD) pueden presentarse en varias formas, como se explica a continuación. Un dispositivo electrónico B, denominado llamado, comprende un procesador, una memoria y medios de transmisión de datos. Estos medios de transmisión de datos pueden presentarse en varias formas, como se explica a continuación. Dependiendo de las realizaciones, los dispositivos A y/o B también pueden comprender componentes (opcionales) de hardware y/o software para la visualización (Disp), la introducción de datos (KBD) y la impresión (IMP).

[0065] Los medios de transmisión pueden presentarse, por ejemplo, en la forma de un BUS de datos, estando conectado este bus de datos, de manera monodireccional o bidireccional entre el procesador del dispositivo A y el procesador del dispositivo B. Alternativamente, se pueden implementar dos buses de transmisión monodireccionales: uno que permite la transmisión del dispositivo A al dispositivo B y otro que permite la transmisión del dispositivo B al dispositivo A.

[0066] En otras situaciones, los medios de transmisión de datos pueden adoptar la forma de interfaces de comunicación de redes. Por ejemplo, el procesador (del dispositivo A y/o del dispositivo B) está conectado, por medio de un bus de datos, a uno o más componentes de emisión/recepción de datos usando una o más tecnologías de transmisión cableadas o inalámbricas. En al menos una situación, el dispositivo A y/o el dispositivo B se presentan en la forma de un SOC ("System on Chip" en inglés, "sistema en chip") que tiene todos los componentes necesarios para la implementación del dispositivo.

[0067] En una realización, el dispositivo B está integrado en el dispositivo A, como un componente adicional del mismo. En una realización, el dispositivo A está integrado en el dispositivo B, como un componente adicional del mismo. En una realización complementaria a otras posibles realizaciones, el dispositivo de ejecución (B) dispone de un procesador segurizado y/o una memoria segurizada (Msec), lo que le permite implementar funciones criptográficas. Más en particular, el dispositivo B está en condiciones de realizar tratamientos de cifrado y descifrado de datos, en particular recibidos del dispositivo A. El dispositivo de ejecución (B) comprende, por ejemplo, dentro de su procesador y/o de su memoria, registros específicos (RS) para el tratamiento de los datos recibidos. En particular, los datos recibidos, después de haber sido demodulados y/o decodificados, según la forma en que se reciban, se colocan en un conjunto específico de registros (y/o áreas de memoria). Los datos se colocan en estos registros (ya se trate de datos de parametrización de función o de datos de nombres de función, como se ha explicado). El procesador del dispositivo B lleva a cabo tratamientos de control y/o de certificación sobre los datos colocados en este conjunto específico de registros (y/o áreas de memoria) antes de llevar a cabo una acción para usar estos datos. El uso de dichos registros específicos permite garantizar que los datos recibidos (del dispositivo A) o de otro dispositivo, por ejemplo, fraudulento, no se vean comprometidos y puedan usarse en el marco de la implementación de una o más funciones que deben ser implementadas por el dispositivo B, normalmente en nombre del dispositivo A.

[0068] En el marco de la invención, se supone que el dispositivo de ejecución (B) dispone de una aplicación de origen OApp, que se ha descargado de una tienda de aplicaciones ("store"). El editor de esta aplicación es un proveedor de servicios que, en particular, implementa el dispositivo A.

[0069] Según la invención, tal como se presentó anteriormente, el dispositivo de ejecución (B) usa una tienda de aplicaciones ("store") para obtener la aplicación de origen OApp. Según la realización y las condiciones de implementación operativas, la aplicación de origen OApp es ejecutada directamente por el sistema operativo del terminal de comunicación (se trata entonces de una aplicación nativa) o se ejecuta por medio de una máquina virtual (MV).

[0070] La aplicación de origen OApp se distribuye de forma abierta en la tienda de aplicaciones. Esta aplicación de origen OApp comprende un conjunto de funciones predefinidas (FPD1,... FPDn). Dentro de este conjunto predefinido de funciones, se distinguen dos tipos de función: el primer tipo comprende funciones de "sobrecarga" (FSc) cuya finalidad es sobrecargar funciones del sistema operativo o funciones de la máquina virtual (MV) en donde opera la aplicación. Estas funciones de sobrecarga (FSc) se limitan a llamar a una función de base y devuelven el resultado de esa función de base. Por ejemplo, puede tratarse de funciones relacionadas con la obtención de la fecha, la hora, el modelo de terminal, la carga de la batería, el número de versión de este o aquel componente de software o hardware, etc. Estas funciones están sobrecargadas para las necesidades de la aplicación de origen. El segundo tipo comprende funciones "de negocio" (FM) implementadas específicamente para las necesidades de la aplicación de origen. Por ejemplo, estas pueden ser funciones de tratamiento específico o funciones de cálculo. El editor de la aplicación de origen define estas funciones para sus necesidades, con el objetivo de implementar un servicio o una parte de un servicio definido por él.

[0071] La aplicación de origen comprende también funciones de comunicación (FCs) específicas, que permiten intercambiar datos, por ejemplo en forma serializada, con el dispositivo llamante (A). Estas funciones de comunicación pueden comprender funciones de protocolo clásico, tales como abrir un flujo http, establecer un enlace segurizado, transmitir una solicitud y recibir una respuesta.

[0072] Para resolver los problemas relacionados con la seguridad de la aplicación, la seguridad de los intercambios y la seguridad del dispositivo de ejecución (B), la implementación de una llamada de función (que puede ser remota) proveniente de un dispositivo llamante comprende las etapas siguientes, descritas en relación con las figuras 2 y 3, que se implementan, después del establecimiento de un enlace de transmisión de datos segurizado, denominado enlace segurizado:

[0073] - recepción (10), por medio del enlace segurizado (LSec), desde el dispositivo llamante (A), de una estructura de datos de ejecución (StrExec);

[0074] - salvaguarda (20), dentro de un área de memoria específica (MZone, M, Msec), de dicha estructura de datos de ejecución (StrExec);

[0075] - para cada registro actual (CUEnr) de la estructura de datos de ejecución (StrExec), implementación (30) de las etapas siguientes:

[0076] - obtener (31) un nombre de función codificado (CFN);

[0077] - decodificar (32) el nombre de función codificado (CFN), suministrando un nombre de función actual, denominado nombre decodificado (UCFN);

[0078] - buscar (33) la presencia de una función existente con la ayuda del nombre de función decodificado (UCFN), para proporcionar un resultado de búsqueda (ReR);

[0079] - cuando el resultado de búsqueda es positivo (34) (lo que indica así la presencia de una función que lleva el nombre decodificado (UCFN), denominada entonces función actual (FCour), implementación (35) de una etapa de ejecución comprendiendo:

[0080] - opcionalmente, obtener (35-10) dentro del registro actual (CUEnr), uno o más parámetros de ejecución (PExec) de la función actual FCour;

[0081] - intento de ejecución (35-11) de la función actual FCour con los parámetros de ejecución opcionales (PExec) obtenidos anteriormente, con un mecanismo de excepción al ejecutarse;

[0082] - cuando no se activa ninguna excepción en la ejecución, obtener (35-12) el resultado de ejecución (RExec) de la función actual (FCour);

[0083] - escribir (35-13) el resultado (RExec) de la función actual (FCour) en un área de memoria específica del registro actual (CUEnr) y/o del siguiente registro de la estructura de datos de ejecución.

[0084] Las etapas 31 a 34, tal como se explica a continuación, pueden implementarse de forma independiente durante la creación de una función específica, denominada función de ejecución corriente arriba de la función. La función de ejecución se implementa entonces en la etapa de ejecución 35.

[0085] Así pues, el método descrito permite garantizar que una aplicación maliciosa, instalada en el dispositivo de ejecución (B), no pueda recibir información sobre los tratamientos implementados por la aplicación de origen. El método descrito también permite la evolución de la aplicación de origen, en particular al permitir la ejecución de funciones, simples o complejas, que no se planificaron originalmente. El método descrito también permite garantizar, para el dispositivo llamante, que las funciones realmente ejecutadas por la aplicación son de hecho las funciones que esperaba el dispositivo llamante.

[0086] 5.2. Estructura de datos de ejecución

[0087] Algunas de las ventajas se obtienen al usar la estructura de datos de ejecución (también denominada estructura de ejecución segurizada) que recibe la aplicación de origen y se registra en un área de memoria disponible para la aplicación de origen. El área de memoria está preferiblemente protegida (ya sea por software o por hardware). Sin embargo, incluso en ausencia de protección, se obtienen los beneficios que proporciona la implementación del método propuesto. De hecho, la estructura de datos de ejecución comprende un conjunto de registros, cada registro del conjunto de registros comprende un nombre de función codificado (CFN) y una serie de parámetros de entrada (IPSx) (siendo esta serie de parámetros de entrada opcional) y uno o más campos de resultados (RESx). Por ejemplo, el nombre de función codificado tiene la forma de una firma, cifrada o no, del nombre de función decodificado. El nombre de función decodificado no se expone en la estructura de datos de la ejecución. En la [tabla 1] se proporciona un ejemplo de una estructura de ejecución segurizada.

[0088] [tabla 1]

[0091]

[0093] A partir de la lectura de lo anterior, se puede entender que la estructura de datos de ejecución también es una estructura de control de flujo. En el ejemplo de la tabla 1, se llama a la función codificada n n.º 1 (CFN_1), después se llama a la función codificada n n.º 2 (CFN_2), luego nuevamente se llama a la función codificada n n.º 1 (CFN_1) y, finalmente, se llama a la función codificada n n.º 4 (CFN_4). Los parámetros de entrada y, en su caso, los resultados de la ejecución de la función y o de la función anterior también se usan para ejecutar la función siguiente. Por lo tanto, los resultados de ejecución de las funciones pueden transmitirse al dispositivo llamante, para controlar el flujo de ejecución y comprobar la precisión de los resultados intermedios obtenidos por el dispositivo llamado, y al mismo tiempo el dispositivo llamado puede usar los resultados de la ejecución de las funciones para parametrizar la ejecución de las funciones siguientes. La transmisión de los resultados de ejecución del flujo puede ser directa (es decir, en cuanto se ejecute la función), o bien llevarse a cabo al final de la ejecución del flujo de ejecución, en el marco de la transmisión de una estructura de datos de recapitulación al dispositivo llamante.

[0094] En condiciones operativas, la estructura de datos de ejecución es más compleja que el ejemplo ilustrado anteriormente. De hecho, la estructura de datos de ejecución también puede comprender mecanismos de control del flujo de ejecución, lo que permite, por ejemplo, la implementación condicional de las funciones según los resultados de las ejecuciones anteriores, permitiendo así la ejecución inteligente de las funciones según las especificaciones del dispositivo llamante. Por lo tanto, gracias a esta técnica, es posible que el dispositivo de ejecución (B) ejecute un nuevo código de aplicación (es decir, al menos nuevo en su encadenamiento, o incluso completamente nuevo, según los parámetros suministrados), sin la necesidad de actualizar la aplicación de origen. La [tabla 2] es otro ejemplo de una estructura de ejecución segurizada.

[0095] [tabla 2]

[0098]

[0100] En esta tabla se añaden dos columnas. Más en particular, para cada función codificada, se pueden implementar una o más condiciones previas a la ejecución opcionales (PreEx_x). Lo mismo ocurre para las posteriores a la ejecución (PosrEx_x). De forma ventajosa y opcional, estas condiciones de ejecución se someten a cifrado (por acción del dispositivo llamante) y se descifran sobre la marcha (por acción del dispositivo de ejecución), por ejemplo, durante la obtención del nombre de función decodificado (etapa 32) o durante la obtención de los parámetros de ejecución (etapa 35-10).

[0101] En otra realización, el control del flujo de ejecución puede llevarse a cabo en el dispositivo llamante. Más en particular, la estructura de ejecución segurizada comprende un único registro a la vez. Cada vez que se ejecuta la función contenida en la estructura de ejecución segurizada, el resultado se transmite inmediatamente al dispositivo llamante, que toma decisiones según este resultado y transmite al dispositivo de ejecución (B) una nueva estructura de ejecución segurizada, comprendiendo uno o más registros. La ventaja en este caso es que se dispone de una mayor flexibilidad en el control de la ejecución.

[0102] En al menos una realización, en lugar de llamar a las funciones sucesivamente por orden, por ejemplo, según el flujo de ejecución de la tabla 2, se define una composición monádica para crear una función específica (denominada función resultante) que se comporte como la composición de las funciones para llamar, según el flujo de ejecución esperado. Así se garantiza que se ejecute toda la función resultante (incluso si se producen errores durante la ejecución, la función resultante está en condiciones de completarse) y se consigue que esta función resultante sea más eficaz.

[0103] Por ejemplo, se usa una mónada de Kleisli que usa errores de agregados (por lo tanto, se pueden detectar varios errores) para implementar dicha función resultante.

[0104] Así, por ejemplo, la aplicación de origen dispone de un controlador de composición. Este controlador usa la tabla de ejecución (por ejemplo, Tabla 1, Tabla 2) para construir una función resultante que comprenda el conjunto de las funciones de la tabla de ejecución y en su caso una serie de estructuras condicionales asociadas (por ejemplo, tabla 2). Esta función específica, construida en tiempo real por el controlador de composición, tiene como objetivo implementar la lista de funciones de la tabla y, al mismo tiempo, permitir una gestión eficaz de cualquier error que pueda producirse durante la ejecución de las funciones de la tabla de ejecución. Además de las mónadas, también se pueden implementar estructuras de tipo "try-catch" según las realizaciones y el lenguaje usado.

[0105] Normalmente, puede producirse un error cuando el dispositivo llamante ordena la ejecución de una función (por ejemplo, F1) al dispositivo de ejecución. Esta función, que el dispositivo llamante sabe que existe, en teoría toma tres parámetros como entrada en una versión X. El dispositivo llamante recibe la tabla de ejecución e intenta ejecutar la función F1 con los tres parámetros suministrados. Desafortunadamente, la "versión" Y de la función F1 en posesión del dispositivo de ejecución requiere cuatro parámetros. Como la aplicación de origen no tiene este cuarto parámetro, el intento de ejecución F1 produce un error. Sin un mecanismo de composición y/o interceptación, una situación de este tipo conduciría a la interrupción de la función resultante y, por lo tanto, a la imposibilidad de implementar las otras funciones de la función resultante. Gracias a la técnica de gestión de la función resultante, es posible ejecutar el conjunto de las funciones, según el flujo de ejecución deseado, incluso si la totalidad o parte del conjunto de funciones de la tabla de ejecución provoca errores de ejecución. Además, estos errores de ejecución se detectan y se insertan en la estructura de resultados transmitida por la aplicación de origen.

[0106] Además, el controlador (o la función de origen) suministra, según las realizaciones, una versión serializada de las funciones que se ejecutan, también en la estructura de resultados, con el fin de que el contenido de estas funciones pueda ser objeto de autenticación.

[0107] 5.3. Segurización de la ejecución por introspección

[0108] Entre las etapas importantes del método descrito anteriormente se identifica la decodificación (32) del nombre de función codificado (CFN), que suministra un nombre de función actual, denominado nombre decodificado (UCFN) y la búsqueda (33) de la presencia de una función existente con la ayuda del nombre de función decodificado (UCFN). Dependiendo de las condiciones de implementación operativas, estas dos etapas pueden consistir en una sola etapa.

[0109] En una primera realización, el nombre de función codificado consiste en una firma de un nombre de función, conocido por el dispositivo llamante. De hecho, según la invención, el gestor de la aplicación de origen está vinculado, al menos en parte, al servicio proporcionado por el dispositivo llamante. Por lo tanto, el dispositivo llamante está en condiciones de conocer el conjunto de las funciones predefinidas (FPD1,... FPDn) en la aplicación de origen y de hacerlo con antelación. Por lo tanto, el dispositivo llamante (o más bien el gestor del dispositivo llamante) puede, a partir del conjunto de funciones predefinidas (FPD1,... FPDn) en la aplicación de origen, deducir una estructura a partir de los datos del nombre de función codificado (CFN). La transformación de un nombre de función predefinido (FPD_x) en un nombre de función codificado (CFN_x) se lleva a cabo, en esta realización, por la aplicación de un algoritmo de firma (ASig). Puede tratarse de una firma simple (obtenida, por ejemplo, por medio de una función hash clásica), o de una firma particular en la que interviene una función criptográfica y una clave de cifrado, tal como, por ejemplo, una clave de cifrado de sesión obtenida durante el establecimiento del enlace de transmisión de datos segurizado. Por lo tanto, la transformación de un nombre de función predefinido (FPD_x) en un nombre de función codificado (CFN_x) se lleva a cabo de antemano o en tiempo real, siendo la segunda solución la más eficiente desde el punto de vista de la seguridad.

[0110] En cualquier caso, cuando recibe la estructura de ejecución segurizada, la aplicación de origen del dispositivo de ejecución (B) realiza, en esta realización, un descifrado opcional, que proporciona una firma no cifrada. Basándose en esta firma no cifrada, en esta primera realización, se realiza una decodificación de la firma y se usa un mecanismo de introspección (reflexividad) para permitir que la función sea buscada o llamada inmediatamente basándose en su nombre decodificado, si es correcto. De manera adicional, se implementa un mecanismo de anotación del código dentro de la aplicación de origen. Esto nos permite asignar a cada función una etiqueta que persistirá hasta el oscurecimiento (incluso si el oscurecimiento realiza el cifrado en cadena y otras manipulaciones, la reflexividad garantiza que el propio programa pueda leer sus propias cadenas). Estos dos mecanismos (reflexividad y anotación) se usan para facilitar la ejecución de funciones, incluidas funciones nuevas, nunca llamadas anteriormente, al tiempo que evitan el problema de "analizar" una orden que se transmitiría en texto plano. De este modo, es posible llamar a una función en el momento de la ejecución conociendo su nombre (y suministrándole los parámetros). Sin embargo, este enfoque plantea dos problemas que se resuelven con la técnica descrita anteriormente:

[0111] - no es conveniente autorizar la llamada de todas las funciones, porque conllevaría una falta de seguridad: lo anterior se resuelve usando una firma (en su caso criptográfica) del nombre de la función, que se verifica antes de realizar la llamada, como se explicó anteriormente.

[0112] - durante el uso del oscurecimiento (ofuscación), se modifican los nombres de función.

[0113] Para aportar una solución al segundo problema, se usa un mecanismo de anotación que permite asignar a cada función una etiqueta que persiste hasta el oscurecimiento (incluso si el oscurecimiento realiza un cifrado de cadena y otras manipulaciones, la reflexividad garantiza que el propio programa pueda seguir leyendo sus propias cadenas de caracteres en la ejecución). Ambos problemas se pueden resolver elegantemente con la misma solución, es decir, la firma en sí misma. El uso de anotaciones proporciona otra capa de protección, ya que no se pueden invocar funciones sin anotaciones (incluso si un atacante pudiera adivinar el nombre de una función ofuscada y falsificar una firma criptográfica de esa función ofuscada...).

[0114] Así pues, en resumen, al diseñar la aplicación de origen se agrega una anotación, similar a:

[0115] @remote (code = H)

[0116] Esta anotación añade la función a la que se desea poder autorizar llamadas con el mecanismo descrito en la presente solicitud. El código H es (por ejemplo) el hash del nombre de función según lo decidido por el diseñador de la aplicación de origen y corresponde a un nombre de función codificado CFN.

[0117] En esta realización, para llamar a la función UCFN correspondiente a la anotación CFN, el dispositivo llamante transmite el código H (firmado) (como un nombre de función codificado en la estructura de datos de ejecución segurizada). La aplicación de origen del dispositivo de ejecución (B) verifica la firma y, cuando la firma es válida, usa la reflexividad para buscar una función UCFN con la anotación correspondiente (es decir, con la anotación H correspondiente a la CFN). Después, usando nuevamente la reflexividad, se llama a esta función UCFN. Por lo tanto, esta realización requiere pocas modificaciones en la forma en que se diseña la aplicación de origen. En otra realización, un mecanismo de declaración ofrece la posibilidad de asociar un código H (un nombre de función codificado CFN) con un nombre de función decodificado (UCFN). Aunque esta técnica no es óptima en comparación con el uso de anotaciones, también permite garantizar una cierta protección de los nombres de las funciones: hay una tabla dentro de la aplicación. Comprende tantos registros como funciones cuya ejecución se desee autorizar por medio del método descrito anteriormente. Cada registro comprende dos campos: un campo comprendiendo el nombre de función codificado CFN y un registro comprendiendo un cifrado (una versión cifrada) del nombre de función decodificado (UCFN). Esta versión cifrada del nombre de función decodificado se denomina CCFN. En esta realización, por lo tanto, en lugar de usar el mecanismo de reflexividad dos veces, se usa solo una vez. La [tabla 3] es un ejemplo de estructura de declaración.

[0118] [tabla 3]

[0121]

[0123] En esta realización se cuenta con dos versiones del nombre de función: una versión correspondiente a la firma (en su caso encriptada), CFN, y una versión cifrada CCFN. En la ejecución, el núcleo de aplicación de la aplicación de origen recibe el nombre de función codificado (y cifrado) CFN_x y, como se indicó anteriormente, verifica que la firma sea válida. Si la firma (correspondiente al nombre de función codificado CFN_x) es válida, busca en la estructura declarativa la versión cifrada del nombre de función CCFN_x correspondiente al nombre de función codificado CFN_x. Una vez que se obtiene la versión cifrada del nombre de función CCFN_x, el núcleo de aplicación descifra esta versión cifrada (en memoria RAM, el resultado del descifrado no se copia en una memoria masiva) y usa este resultado para la operación de introspección que proporciona el nombre real de la función (CFN) a la que, por lo tanto, se llama. La operación de descifrado del nombre de función se lleva a cabo ventajosamente por medio de una clave, por ejemplo, una clave privada específica, realizándose el cifrado a su vez en el momento de la compilación de la aplicación de origen, con la ayuda de una clave pública generada por el compilador o el editor de enlaces, por ejemplo. Por su parte, la clave privada, por ejemplo, se transmite después del establecimiento del enlace de transmisión de datos segurizado con el dispositivo llamante. Por lo tanto, el dispositivo de ejecución (B) (y la aplicación de origen) no están en posesión de esta clave privada y, por lo tanto, no pueden implementar el tratamiento de la estructura de ejecución segurizada antes de haber recibido esta clave privada del dispositivo llamante.

[0124] 5.4. Puesta a disposición de las funciones de la aplicación de origen

[0125] Como se explicó anteriormente, la ejecución de una función por medio de la estructura de ejecución segurizada solo es posible si esta función está autorizada para ejecutarse. Para ello, se han presentado dos realizaciones particulares:

[0126] - un mecanismo de anotación, cuyo objeto es, de alguna manera, vincular la función UCFN con un nombre de función codificado CFN: con esta realización, si una función UCFN no está anotada con su nombre de función codificado CFN, no se puede invocar por medio de la estructura de ejecución segurizada. Así se permite limitar drásticamente las posibilidades de llamada por esta vía y, por lo tanto, aumenta la seguridad de la aplicación; y/o

[0127] - un mecanismo de registro declarativo, basado en el uso de una tabla específica, que asocia el nombre de función codificado y el nombre de función cifrado con dos métodos diferentes, con la ventaja de que es posible por esta vía actualizar esta tabla específica, que se puede recibir directamente del dispositivo llamante, en el momento de la ejecución, lo que no es posible hacer con las anotaciones;

[0128] - además de las funciones "anotadas", se dispone de un único punto de entrada, una función "meta", que toma como entrada el nombre de función codificado CFN y los argumentos (por ejemplo, en forma de matriz) y usa la reflexividad (introspección), como se describió anteriormente para llamar a esta o aquella función o método; Por supuesto, todos los mecanismos descritos anteriormente se pueden combinar para obtener una aplicación de origen maleable con la que el dispositivo llamante pueda hacer ejecutar con total seguridad numerosas funciones, planificadas o no planificadas de antemano.

[0129] 5.5. Garantía de ejecución por parte del dispositivo de ejecución

[0130] Entre los requisitos que pueden surgir durante la implementación de la presente técnica, la garantía de que el código ejecutado es correcto es, sin duda, uno de los más importantes. Por lo tanto, para garantizar que el programa se ejecutó según lo planeado, se implementa el uso de la composición monádica. Así, además de los posibles mensajes de error detectados durante la ejecución y del resultado devuelto, el seguimiento de la ejecución se puede (firmar y) devolver al dispositivo llamante. También es posible serializar el programa ensamblado (función resultante) y enviarlo para su inspección al dispositivo llamante: tal implementación no es necesariamente eficiente, en particular desde el punto de vista del uso de los recursos de la red, sin embargo, el uso de la composición monádica para obtener la función resultante hace posible esta solución.

[0131] 5.6. Enlace segurizado entre el dispositivo llamante y el dispositivo de ejecución

[0132] El establecimiento del enlace de transmisión de datos segurizado se implementa por medio del núcleo de aplicación de la aplicación de origen, de forma independiente, en el arranque de la aplicación de origen en el dispositivo de ejecución. Más en particular, en el arranque de la aplicación de origen se implementa el siguiente método:

[0133] - el núcleo de aplicación carga los parámetros de aplicación en un área de memoria (segurizada), si aún no están cargados (o están en memoria caché);

[0134] - el núcleo de aplicación carga el módulo (de comunicación) comprendiendo el conjunto de funciones de comunicación;

[0135] - el núcleo de aplicación busca los parámetros y valores de conexión dentro del área de memoria (segurizada); - en relación con el dispositivo llamante y el módulo de comunicación, el núcleo de aplicación establece el enlace de transmisión de datos segurizado, comprendiendo, por ejemplo:

[0136] - definir los parámetros para cifrar y descifrar datos dentro de una sesión, por ejemplo, http/http2 segurizada por el protocolo SSL y/o TLS;

[0137] - definir una clave de sesión, derivada de pares de claves privadas/claves públicas en posesión del núcleo de aplicación y del dispositivo llamante.

[0138] La sesión se puede establecer directamente entre la aplicación de origen y el dispositivo llamante. También se puede establecer con un dispositivo intermedio, presente en la red de comunicación, con el que la aplicación de origen determina los parámetros de conexión al dispositivo llamante, para después iniciar una sesión con el dispositivo llamante.

[0139] Independientemente del modo usado, al final de este arranque, la aplicación de origen ha establecido, con el dispositivo llamante, una sesión de comunicación segurizada, lo que permite al dispositivo llamante transmitir estructuras de ejecución segurizadas, tal como se describió anteriormente, a la aplicación de origen.

[0140] De manera complementaria, la aplicación de origen puede establecer una sesión de comunicación con un dispositivo electrónico complementario, por ejemplo, un dispositivo electrónico de verificación (dispositivo de verificación (C)) que es el destinatario de los resultados de las ejecuciones de las funciones implementadas por el dispositivo de ejecución. El establecimiento de esta sesión sigue las mismas etapas que las descritas anteriormente y el dispositivo de verificación (C) ocupa el lugar del dispositivo llamante (A) para la verificación (y en su caso la autenticación) de los resultados de la ejecución. En tal caso, el dispositivo llamante (A) desempeña el papel de un dispositivo de transmisión de órdenes mientras que el dispositivo de verificación (C) lleva a cabo las operaciones de verificación y/o certificación y/o autenticación de los resultados obtenidos. 5.7. Estructuración de la aplicación de origen

[0141] La figura 4 presenta la estructura de la aplicación de origen tal como se implementa en el marco de la invención. La aplicación de origen comprende:

[0142] - un núcleo de aplicación (CoreB), cuya función importante es tratar las estructuras de datos recibidas desde el dispositivo llamante, como se explicó anteriormente;

[0143] - un conjunto de funciones predefinidas (FPD1,... FPD<N>); cada función predefinida del conjunto de funciones predefinidas comprende un nombre de función real;

[0144] - un controlador de ejecución (CtrilEx), que en particular se encarga del control del flujo de ejecución cuando se implementa esta funcionalidad, y gestiona la implementación de la etapa 35 descrita anteriormente;

[0145] - un conjunto de funciones de comunicación (FCs) que permiten la transmisión y recepción de datos con el dispositivo llamante, siendo este conjunto de funciones de comunicación implementado de forma independiente por el núcleo de aplicación de la aplicación, en el marco de los intercambios con el dispositivo llamante y/o en el marco de los intercambios con otros servicios "autorizados";

[0146] - un módulo de cifrado (Cyf), que permite cifrar y descifrar datos;

[0147] - un módulo de tratamiento (TrTM) de estructuras de datos de ejecución, siendo dichas estructuras de datos de ejecución, como se explicó anteriormente, recibidas del dispositivo llamante; este módulo puede fusionarse en el núcleo de aplicación;

[0148] - un módulo de búsqueda (Rech), dentro de una estructura de datos, de nombres de funciones reales según los nombres de funciones codificados (nombres de funciones codificados presentes en la o las estructuras de datos de ejecución), según el método descrito anteriormente; este módulo puede fusionarse en el núcleo de aplicación.

[0149] Cabe señalar que, según la invención, la aplicación de origen no tiene API. La aplicación de origen no expone una interfaz de aplicación remota que comprenda un acceso (directo) a funciones ocultas. La aplicación no está en condiciones de recibir una llamada de función (que puede ser remota) desde un dispositivo llamante, excepto con el mecanismo descrito anteriormente. Por lo tanto, la aplicación, por medio de sus funciones de comunicación, está en condiciones de recibir una estructura de datos de ejecución, que toma la forma, por ejemplo, de un flujo JSON, XML, CSV u otro, comprendiendo este flujo un conjunto de nombres de funciones ocultas y parámetros, que en su caso se someten a cifrado con la ayuda de una clave de cifrado resultante de la creación del enlace de comunicación segurizado.

[0150] También debe tenerse en cuenta que la implementación de la invención, para todas sus realizaciones, puede llevarse a cabo en un dispositivo electrónico comprendiendo tanto un dispositivo electrónico de ejecución como un dispositivo electrónico de control como se describió anteriormente. También debe tenerse en cuenta que todas las características de las realizaciones se pueden combinar para producir los efectos esperados y, en particular, para permitir la ejecución de funciones o encadenamientos de funciones que no están necesariamente planificados de antemano y esto sin tener que modificar la aplicación de origen.

[0151] 5.8. Descripción de una realización específica

[0152] En una realización adaptada al tratamiento de transacciones que implementan datos sensibles (datos biométricos, firmas de voz, huellas digitales, datos de salud, datos de pagos), el terminal de comunicación de un usuario está provisto de una aplicación cuyo objeto, al menos en algunas funciones, puede ser la manipulación de dichos datos. Por ejemplo, la aplicación en cuestión puede ser una aplicación de pago o una aplicación bancaria. En el marco de esta realización, el gestor del servicio pone a disposición en una tienda de aplicaciones una aplicación de origen. Para evitar que se extraigan datos importantes de la aplicación de origen, y con el objeto de garantizar la seguridad e integridad de los datos tratados por la aplicación de origen, la aplicación de origen cumple con la descripción descrita anteriormente.

[0153] En condiciones operativas, el dispositivo llamante es, por ejemplo, un servidor bancario o un servidor de transacciones que manipula los datos de pago. Durante la ejecución de la aplicación, se implementa el método descrito anteriormente. Este método permite al servidor bancario controlar la aplicación de origen instalada en el terminal de comunicación del usuario, las órdenes en cuestión se insertan en la estructura de ejecución que se transmite, por medio del enlace de transmisión segurizado, a la aplicación de origen del terminal de comunicación. El propósito de esta transmisión puede ser verificar el correcto funcionamiento de la aplicación de origen y/u obtener información en el terminal de comunicación del usuario y/o ejecutar código comercial. Al recibir esta estructura de ejecución, la aplicación implementa el método descrito anteriormente para transmitir el o los resultados de la ejecución de las funciones al servidor bancario. Este último está entonces en condiciones de analizar los resultados obtenidos. Las órdenes transmitidas al terminal de comunicación y el análisis de los resultados obtenidos pueden tener varios propósitos. En particular, puede tratarse de verificar que el terminal de comunicación se encuentra en un estado aceptable para poder implementar otras funciones. A modo de ejemplo, el propósito de las órdenes (y, por lo tanto, de las funciones ejecutadas) puede ser determinar cuál es la versión del sistema operativo instalada, cuál es la versión de la máquina virtual instalada, cuáles son las horas y fechas del terminal de comunicación, cuáles son las versiones de las bibliotecas de cifrado y/o de las bibliotecas de comunicación o cuáles son los estados de los elementos de segurización (SE, TEE). Esta primera serie de órdenes y los resultados que se proporcionan permiten así al servidor bancario estimar un estado de riesgo del terminal de comunicación y, por ejemplo, permiten decidir si continuar o no con las operaciones realizadas con el terminal de comunicación. Dependiendo de la aparición de nuevas vulnerabilidades, las órdenes que el servidor bancario transmite al terminal de comunicación pueden variar con el tiempo. Por ejemplo, si se descubre una vulnerabilidad en una biblioteca de compresión de datos, el servidor bancario puede integrar en las órdenes que transmite al terminal de comunicación una orden para comprobar la versión de la biblioteca de compresión.

[0154] Como se explicó anteriormente, las órdenes también pueden materializar una nueva función, que no existía anteriormente, que es el resultado de la combinación de todas las funciones de la estructura de ejecución. Las funciones unitarias (UFCN) de la estructura de ejecución pueden comprender entonces un conjunto comprendiendo funciones de negocio específicas de la aplicación y/o funciones de base del sistema operativo y/o de la máquina virtual para formar una única función que no existía anteriormente. Con una implementación de este tipo, se entiende que un atacante, incluso si dispone de informaciones sensibles en el terminal de comunicación, no estará en condiciones de conocer el encadenamiento lógico implementado gracias a la estructura de ejecución y, por lo tanto, no estará en condiciones de comprender el funcionamiento real de la aplicación.

[0155] Además, otra ventaja de esta forma de proceder radica en el hecho de que el servidor bancario puede, a sabiendas, introducir llamadas a funciones innecesarias en la estructura de ejecución, cuyo único objetivo es perturbar el análisis del comportamiento de la aplicación. Por lo tanto, gracias a esta implementación, se dispone de una aplicación muy segurizada, capaz de resistir los ataques de manera más efectiva.

[0156] Además, en un modo de implementación particular, las órdenes tienen como objetivo actualizar la aplicación de origen. Las funciones disponibles en la aplicación de origen pueden comprender entonces funciones para compilar y editar enlaces que, cuando son controladas por el dispositivo llamante, toman, en la estructura de datos de transmisión, un código fuente o un código parcialmente compilado, que es compilado por la aplicación de origen para actualizar su propia estructura de aplicación.

[0157] 5.9. Otras características y ventajas

[0158] En relación con la figura 5, se presenta una arquitectura simplificada de un dispositivo electrónico de ejecución capaz de llevar a cabo el tratamiento y la ejecución de código según el método descrito anteriormente. Un dispositivo electrónico de ejecución comprende una memoria 51 (y/o en su caso segurizada y/o dos memorias separadas, una segurizada y otra no), una unidad de tratamiento 52 equipada, por ejemplo, con un microprocesador (y/o en su caso segurizado y/o dos procesadores separados, uno segurizado y otro no), y controlada por el programa informático 53, que implementa el método tal como se describe anteriormente. En al menos una realización, la invención se implementa al menos parcialmente en forma de una aplicación AppO instalada en este dispositivo. Dicho dispositivo comprende:

[0159] - medios de recepción, desde el dispositivo llamante, de una estructura de datos de ejecución, comprendiendo al menos un registro, comprendiendo cada registro al menos un campo de datos comprendiendo un nombre de función codificado;

[0160] - medios de salvaguarda, dentro de un área de memoria específica, de dicha estructura de datos de ejecución; - medios, usados para cada registro actual de la estructura de datos de ejecución, para la implementación de una función que lleva un nombre de función decodificado correspondiente al nombre de función codificado, cuando la función que lleva un nombre de función decodificado de la aplicación AppO puede asociarse al nombre de función codificado.

[0161] Para la ejecución de las funciones que se le han confiado, el dispositivo comprende también los medios de implementación del conjunto de las etapas mencionadas anteriormente, ya sea en forma de hardware, cuando se dedican componentes específicos a estas tareas, o en forma de software en relación con uno o varios microprogramas que se ejecutan en uno o varios procesadores del dispositivo de ejecución.

Claims (10)

1. REIVINDICACIONES

1. Método de control de la ejecución de una aplicación AppO, método implementado dentro de la aplicación AppO, ejecutándose dicha aplicación AppO en un dispositivo electrónico, denominado dispositivo de ejecución (B), estando dicho dispositivo de ejecución (B) conectado a un dispositivo llamante (A) por medio de una red de comunicación, comprendiendo dicho método las etapas siguientes:

- recibir (10) desde el dispositivo llamante (A), de una estructura de datos de ejecución (StrExec), comprendiendo al menos un registro, comprendiendo cada registro al menos un campo de datos comprendiendo un nombre de función codificado (CFN_x);

- salvaguardar (20), dentro de un área de memoria específica (MZone), de dicha estructura de datos de ejecución (StrExec);

- para cada registro actual (CuEnr) de la estructura de datos de ejecución (StrExec), implementar (30) una función que lleva un nombre de función decodificado (UCFN_x) correspondiente al nombre de función codificado (CFN_x), cuando la función que lleva un nombre de función decodificado (UCFN_x) de la aplicación AppO se puede asociar al nombre de función codificado (CFN_x),

caracterizado por que el método comprende también la etapa siguiente:

transmitir, a dicho dispositivo llamante, un resultado de ejecución (RExec) de la función que lleva un nombre de función decodificado (UCFN_x) de manera que controle un flujo de ejecución por parte de dicho dispositivo llamante.

2. Método de control de la ejecución de una aplicación según la reivindicación 1, caracterizado por que la etapa de implementación (30) de la función que lleva un nombre de función decodificado (UCFN_x) correspondiente al nombre de función codificado (CFN_x) comprende las etapas siguientes:

- obtener (31) el nombre de función decodificado (UCFN_x) a partir del nombre de función codificado (CFN_x) de dicho registro actual (CUEnr);

- cuando la obtención (31) del nombre de función decodificado (UCFN_x) a partir del nombre de función codificado (CFN_x) es positiva (34), ejecución (35) de la función que lleva el nombre decodificado (UCFN_x).

3. Método de control de la ejecución de una aplicación según la reivindicación 2, caracterizado por que la etapa de ejecución (35) de la función que lleva un nombre de función decodificado (UCFn_x), denominada función actual (FCour), comprende las etapas siguientes:

- opcionalmente, obtener (35-10) dentro del registro actual (CUEnr), de uno o más parámetros de ejecución (PExec) de la función actual FCour;

- intento de ejecución (35-11) de la función actual FCour con el o los parámetros de ejecución (PExec) opcionales obtenidos anteriormente, con un mecanismo de excepción en la ejecución;

- cuando no se activa ninguna excepción en la ejecución, obtener (35-12) el resultado de ejecución (RExec) de la función actual (FCour);

- escribir (35-13) el resultado (RExec) de la función actual (FCour) en un área de memoria específica del registro actual y/o del registro siguiente de la estructura de datos de ejecución.

4. Método de control de la ejecución de una aplicación según la reivindicación 3, caracterizado por que comprende además una etapa de obtención (35-101), dentro del registro actual (CUEnr), de al menos una condición previa de ejecución de dicha función actual y por que la etapa de intento de ejecución (35-11) de la función actual FCour se activa solo cuando se cumple dicha al menos una condición previa.

5. Método de control de la ejecución de una aplicación según la reivindicación 1, caracterizado por que la etapa de implementación (30) de la función que lleva el nombre de función decodificado (UCFN_x) correspondiente al nombre de función codificado (CFN_x) comprende una etapa de introspección de dicha aplicación, suministrando un resultado de introspección positivo cuando una función que lleva el nombre de función decodificado (UCFN_x) se identifica entre el conjunto de funciones de dicha aplicación.

6. Método de control de la ejecución de una aplicación según la reivindicación 2, caracterizado por que la etapa de obtención (31) del nombre de función decodificado (UCFN_x) a partir del nombre de función codificado (CFN_x) de dicho registro actual (CUEnr) comprende una etapa de búsqueda (33) de la presencia de una

función existente a partir de una anotación comprendiendo el nombre de función codificado (CFN_x), estando dicha anotación asociada a la función que lleva el nombre de función decodificado (UCFN_x).

7. Método según la reivindicación 1, caracterizado por que dicha etapa de recepción (10) de la estructura de datos de ejecución está precedida por el establecimiento de un enlace de comunicación segurizado (LSec).

8. Método según la reivindicación 1, caracterizado por que dicha estructura de datos de ejecución está cifrada y por que el método comprende una etapa de descifrado de la estructura de datos de ejecución.

9. Dispositivo configurado para realizar un control de ejecución de una aplicación AppO, estando dicho control implementado dentro de la aplicación AppO, ejecutándose dicha aplicación AppO en un procesador de dicho dispositivo electrónico, denominado dispositivo de ejecución (B), estando dicho dispositivo de ejecución (B) conectado a un dispositivo llamante (A) por medio de una red de comunicación, comprendiendo dicho dispositivo de ejecución (B) los medios siguientes:

- recibir (10) desde el dispositivo llamante (A), de una estructura de datos de ejecución (StrExec), comprendiendo al menos un registro, comprendiendo cada registro al menos un campo de datos comprendiendo un nombre de función codificado (CFN_x);

- salvaguardar (20), dentro de un área de memoria específica (MZone), de dicha estructura de datos de ejecución (StrExec);

- para cada registro actual (CuEnr) de la estructura de datos de ejecución (StrExec), implementar (30) una función que lleva un nombre de función decodificado (UCFN_x) correspondiente al nombre de función codificado (CFN_x), cuando la función que lleva un nombre de función decodificado (UCFN_x) de la aplicación AppO se puede asociar al nombre de función codificado (CFN_x),

caracterizado por que el dispositivo comprende también el medio siguiente:

transmitir, a dicho dispositivo llamante, un resultado de ejecución (RExec) de la función que lleva un nombre de función decodificado (UCFN_x) de manera que controle un flujo de ejecución por parte de dicho dispositivo llamante.

10. Producto de programa informático descargable desde una red de comunicación y/o almacenado en un soporte legible por ordenador y/o ejecutable por un microprocesador, caracterizado por que comprende instrucciones de código de programa para la ejecución de un método según la reivindicación 1, cuando se ejecuta en un ordenador.