TERMINAL DE TELECOMUNICACION CON DOS ESPACIOS DE EJECUCION.

Dispositivo informático con interfaz de usuario, que comprende unos medios de realización de una serie de aplicaciones,

incluyendo estos medios en particular un primer espacio de ejecución máquina virtual/perfil de funcionamiento (100, P1, 200, P2 ) y un segundo espacio de ejecución máquina virtual/perfil de funcionamiento (100, P1, 200, P2), estando los dos espacios de ejecución albergados por un mismo medio físico de tratamiento (400) que está dispuesto para ser no escindible en dos partes sin destrucción de este medio físico de tratamiento (400), alojando cada espacio de ejecución unas aplicaciones (110, 120, 130, 140, 220, 230), caracterizado porque las aplicaciones (110, 120, 130, 210, 220, 230) del segundo espacio de ejecución (100, P1, 200, P2) son unas aplicaciones no modificables por el usuario, mientras que las aplicaciones (110, 120, 130, 210, 220, 230) del primer espacio de ejecución (100, P1, 200; P2) son unas aplicaciones modificables por el usuario, de manera que las aplicaciones del segundo espacio de ejecución (100, P1, 200, P2) son unas aplicaciones con grado de seguridad específicamente más elevado que el de las aplicaciones del primer espacio de ejecución (100, P1, 200, P2); y porque la máquina virtual del segundo espacio de ejecución (100, P1, 200, P2) es distinta del primer espacio de ejecución (100, P1, 200, P2), estando cada una de estas dos máquinas virtuales asociada a un solo perfil de funcionamiento

Terminal de telecomunicación con dos espacios de ejecución.

La presente invención se refiere a la ejecución de programas y aplicaciones, en un dispositivo informático con interfaz de usuario (teclado, pantalla, tarjeta de sonido, zona táctil, ratón, etc...), por ejemplo sobre una pasarela doméstica, una máquina de venta (máquina pública por ejemplo) o también en un terminal de telecomunicaciones (del PC-ordenador personal-al teléfono móvil).

Se conocen diferentes enfoques para la implementación de aplicaciones en los terminales de telecomunicaciones.

Así, el perfil MIDP 2.0., en máquina virtual, utiliza una política de seguridad basada en unos estándares abiertos, simple de utilizar, que no requiere nada del usuario, que tiene en cuenta las necesidades de cada parte interviniente, del desarrollo en la ejecución, (se separan los conceptos de usuario, de operador, de OEM, de tercero de confianza).

Permite proteger la integridad y verificar el origen de las aplicaciones durante la telecarga y la ejecución de éstas, controlar el acceso a los recursos críticos según una política de seguridad, advertir al usuario de lo que ocurre, y puede incluso requerirle su opinión.

La toma en cuenta de la política de seguridad se realiza bastante simplemente, a nivel de una API a proteger, mediante la selección del método "check permission" de la clase "Midlet" (figura 2).

Esto requiere que la función de selección de archivo MIDP no sea accesible directamente desde los programas MIDP (función protegida).

La política de seguridad de MIDP 2.0 está muy adaptada a las necesidades de las diversas partes intervinientes. La posibilidad de solicitar la opinión del usuario según un cierto número de criterios (siempre, una vez, para una sesión, nunca) es muy ventajosa.

Sin embargo, su implementación plantea dos tipos de problemas.

En primer lugar, la ejecución del procedimiento protegido se realiza en el mismo espacio de ejecución que el programa que llama, lo cual facilita el riesgo de "fugas". Si se imagina así un servicio de cifrado llamado por dos midlets simultáneamente, nada garantiza, si no se pone demasiada atención, que un midlet pueda recuperar el contenido de la clave privada utilizada por el otro midlet.

El primer problema es por tanto una falta de seguridad, en particular para las aplicaciones con riesgo tales como el pago, la firma o también por ejemplo las aplicaciones DRM.

Unos ejercicios han mostrado por otra parte que, con un error de implementación, se podría hacer caso omiso de este sistema de permisos.

El segundo problema del perfil MIDP es planteado por las especificaciones del perfil MIDP mismo. No está adaptado a la comprobación formal de programas. Esto plantea un problema en ciertos sectores (en particular bancarios) en los que un midlet no puede ser modelizado por unos métodos formales, y por tanto no puede ser certificado por estos métodos.

En otros términos, no existe una técnica que permita probar, mediante métodos formales, la validez con respecto a unas especificaciones de un programa programado en este perfil.

Otro perfil, el perfil STIP, está más especialmente adaptado para el acceso a unos API orientados en cuanto a la seguridad, tales como el acceso a la SIM.

Las máquinas virtuales STIP (figura 3) permiten hacer funcionar los programas especialmente escritos para el perfil STIP.

La otra fuerza de STIP es que su modelo de programación y sus API se prestan bien para el análisis según los métodos formales. Esto ha permitido por otra parte conectar el medio bancario a su diseño, puesto que la conformidad del código a las especificaciones puede ser comprobada de manera formal.

También el perfil STIP, utilizado en el medio bancario, está, por sus limitaciones, adaptado a la comprobación de programas.

Sin embargo, el perfil STIP ha sido concebido para unos sistemas cerrados (no se telecargan impunemente unas aplicaciones de las que no se tiene confianza).

Así, no se aplica ningún modelo de seguridad (en la versión 2.1.1. de la especificación), y por tanto cualquier aplicación STIP (stiplet) puede acceder a cualquier API de tipo STIP ya implementada.

El perfil STIP no está por tanto adaptado para la realización de terminales en los que un usuario es susceptible de telecargar y utilizar unas aplicaciones corrientes tales como juegos o aplicaciones utilitarias diversas.

La invención tiene por objetivo proponer una configuración que permita, en un terminal de telecomunicaciones, utilizar a la vez unas aplicaciones de usuario diversas, y a la vez unas aplicaciones que requieran un alto nivel de seguridad.

La invención prevé además facilitar la programación y la utilización de aplicaciones, en particular facilitando la certificación del buen funcionamiento de las aplicaciones nuevamente programadas.

Se conoce ciertamente el principio de los teléfonos móviles que albergan dos máquinas virtuales en la forma física de dos procesadores, uno constituido por el terminal mismo y el otro constituido por la tarjeta SIM.

La tarjeta SIM verifica unas exigencias de seguridad elevadas, mientras que el procesador de terminal mismo y su contenido son accesibles por el usuario.

Sin embargo, dicha implementación adolece asimismo de ciertos inconvenientes importantes.

Se conoce asimismo a partir del documento WO 00/43878 un dispositivo de acuerdo con el preámbulo de la reivindicación 1.

Así, otro objetivo de la invención es proponer un dispositivo, asociado en red o no, en el que un espacio segurizado y un espacio no segurizado son ambos aprovechados, por ejemplo permitiendo que el espacio segurizado acceda a las interfaces de usuario tales como teclado o pantalla en lugar del espacio no segurizado, y por el contrario permitir por ejemplo que el espacio no segurizado acceda a una comunicación segurizada con un operador conocido para garantizar dicha seguridad. Se citará en particular, como dicho operador de seguridad, los operadores de telefonía, en particular móvil, los bancos, los proveedores de objetos multimedia de difusión selectiva o de pago, los operadores de provisión de servicio contra firma electrónica a través de dicho dispositivo.

Unos proveedores de objetos multimedia de difusión selectiva son en particular los "DRM" (Digital Rights Management, gestión de los derechos bajo licencia), servidores que suministran un contenido típicamente musical, de vídeo o de juego, bajo licencia, y en forma de un fichero previsto para ser leído bajo diversas obligaciones, por ejemplo un cierto número de veces.

Un objetivo de la invención es proponer dichos medios en los que, además, se pueda tener la certidumbre de que los dos espacios de ejecución asociados (uno con seguridad más elevada que el otro) sean efectivamente los que estaban destinados o autorizados a ser asociados uno al otro ab initio.

Estos objetivos se alcanzan según la invención gracias a un dispositivo informático con interfaz de usuario según la reivindicación 1.

Otras características, objetivos y ventajas de la invención se pondrán más claramente de manifiesto a partir de la lectura de la descripción detallada siguiente, dada haciendo referencia a las figuras adjuntas, en las que:

- la figura 1 es un esquema que ilustra una implementación MIDP según la técnica anterior;

- la figura 2 es un esquema que ilustra la utilización de medios de protección en dicha implementación MIDP;

- la figura 3 es un esquema que ilustra una implementación STIP, de acuerdo con la técnica anterior;

- la figura 4 ilustra una configuración funcional de un terminal de acuerdo con la invención, según una variante preferida.

El modo particular de realización que se describirá ahora permite beneficiarse de lo mejor de las dos técnicas MIDP y STIP, dadas a título de ejemplo, en el seno de un entorno de ejecución coherente.

Se constituye el perfil "usuario", el perfil MIDP. Este perfil es muy popular en el mundo móvil para la creación de juegos y de aplicaciones utilitarias diversas. El usuario puede así telecargar y ejecutar unas aplicaciones que encuentra en la red, como lo haría con un teléfono MIDP corriente. El perfil MIDP incluye por tanto en este caso unas aplicaciones colocadas y activadas por el usuario mismo.

El perfil...

1. Dispositivo informático con interfaz de usuario, que comprende unos medios de realización de una serie de aplicaciones, incluyendo estos medios en particular un primer espacio de ejecución máquina virtual/perfil de funcionamiento (100, P1, 200, P2 ) y un segundo espacio de ejecución máquina virtual/perfil de funcionamiento (100, P1, 200, P2), estando los dos espacios de ejecución albergados por un mismo medio físico de tratamiento (400) que está dispuesto para ser no escindible en dos partes sin destrucción de este medio físico de tratamiento (400), alojando cada espacio de ejecución unas aplicaciones (110, 120, 130, 140, 220, 230), caracterizado porque las aplicaciones (110, 120, 130, 210, 220, 230) del segundo espacio de ejecución (100, P1, 200, P2) son unas aplicaciones no modificables por el usuario, mientras que las aplicaciones (110, 120, 130, 210, 220, 230) del primer espacio de ejecución (100, P1, 200; P2) son unas aplicaciones modificables por el usuario, de manera que las aplicaciones del segundo espacio de ejecución (100, P1, 200, P2) son unas aplicaciones con grado de seguridad específicamente más elevado que el de las aplicaciones del primer espacio de ejecución (100, P1, 200, P2); y porque la máquina virtual del segundo espacio de ejecución (100, P1, 200, P2) es distinta del primer espacio de ejecución (100, P1, 200, P2), estando cada una de estas dos máquinas virtuales asociada a un solo perfil de funcionamiento.

2. Dispositivo según la reivindicación 1, caracterizado porque las aplicaciones (110, 120, 130, 210, 220, 230) del segundo espacio de ejecución (100, P1, 200, P2) son unas aplicaciones modificables por un operador de seguridad que pertenece al grupo constituido por los operadores de telefonía, bancos, proveedores de objetos multimedia de difusión selectiva o de pago, operadores de provisión de servicios contra firma electrónica por medio de dicho dispositivo.

3. Dispositivo según la reivindicación 1 ó 2, caracterizado porque constituye un terminal telefónico.

4. Dispositivo según la reivindicación 3, caracterizado porque constituye un terminal de telefonía móvil.

5. Dispositivo según cualquiera de las reivindicaciones anteriores, caracterizado porque comprende unos medios de comunicación (130, 230, 300) entre los dos espacios de ejecución (100, P1, 200, P2).

6. Dispositivo según la reivindicación 5, caracterizado porque los medios de comunicación (130, 230, 300) entre los dos espacios de ejecución están previstos para permitir una aplicación (130, 230) de uno de los dos espacios de ejecución para recurrir a unos medios de tratamiento del segundo espacio de ejecución (100, P1, 200, P2).

7. Dispositivo según cualquiera de las reivindicaciones anteriores, caracterizado porque cada uno de los dos espacios de ejecución incluye por lo menos una API distinta (120, 130, 220, 230).

8. Dispositivo según la reivindicación 5, caracterizado porque los medios de comunicación incluyen una API "stub" (130, 230) que tiene por función recurrir a unos recursos del espacio de ejecución opuesto (100, P1, 200, P2), utilizando estos recursos una selección en cuanto al acceso a ellos mismos en función de aplicación (100, 210) que los llama.

9. Dispositivo según la reivindicación 5, caracterizado porque los medios de comunicación entre los dos espacios de ejecución (100, P1, 200, P2) incluyen unos medios que utilizan una serialización/deserialización o un marshalling/unmarshalling.

10. Dispositivo según cualquiera de las reivindicaciones anteriores, caracterizado porque uno de los dos espacios de ejecución (100, P1, 200, P2) incluye un perfil de tipo STIP.

11. Dispositivo según cualquiera de las reivindicaciones anteriores, caracterizado porque uno de los dos espacios de ejecución (100, P1, 200, P2) incluye un perfil MIDP.

12. Dispositivo según cualquiera de las reivindicaciones anteriores, caracterizado porque los perfiles (P1, P2) de cada uno de los dos espacios de ejecución (100, P1, 200, P2) son respectivamente un perfil STIP y un perfil que forma parte del grupo constituido por los perfiles STIP, MIDP, OSGI, y ".net".