MXPA06005437A - Metodo de autentificacion de aplicaciones - Google Patents

Abstract

El objetivo de la presente invención consiste en proponer un método de gestión de la seguridad de aplicaciones, puesto en practica con un módulo de seguridad asociado a un equipo móvil. Este objetivo es alcanzado mediante un método de autentificación de al menos una aplicación (APP) que funciona en un equipo (CB) conectado por una red (NET) a un servidor de control (CSE), y dicho equipo (CB) estálocalmente conectado a un módulo de seguridad (SIM), dicha aplicación (APP) es cargada y/o ejecutada por medio de un entorno de ejecución de aplicaciones (AEE) del equipo (CB) y utiliza unos recursos (RES) almacenados en el módulo de seguridad (SIM), que incluye las etapas preliminares siguientes:recepción de datos que incluye al menos el identificador (IMEISV) del equipo (CB) y el identificador (IMSI) del módulo de seguridad (SIM), a través de la red (NET), por el servidor de control (CSE) análisis y verificación por el servidor de control (CSE) de dichos datos, generación de un criptograma (CRY) que incluye una huella (FIN1) de la aplicación (APP), unos datos de identificación del equipo (CB) y del módulo de seguridad (SIM) y unas instrucciones (INS RES) destinadas a dicho módulo, transmisión de dicho criptograma (CRY), a través de la red (NET) y del equipo (CB), al módulo de seguridad (SIM), verificación de la aplicación (APP) mediante una comparación de la huella (FIN1) extraída del criptograma (CRY) recibido con una huella (FIN2) determinada por el módulo de seguridad (SIM), el método estácaracterizado por el hecho de que, durante la inicialización y/o la activación de la aplicación (APP), el módulo de seguridad (SIM) ejecuta las instrucciones (INS_RES) extraídas del criptograma (CRY) y libera, respectivamente bloquea el acceso a ciertos recursos (RES) de dicho módulo de seguridad (SIM) en función del resultado de la verificación propia a esta aplicación (APP) efectuada previamente.

Description

MÉTODO DE AUTENTIFICACION DE APLICACIONES DESCRIPCIÓN DE LA INVENCIÓN La presente invención se refiere al ámbito de las redes móviles llamadas también redes celulares. Esta se refiere más particularmente a la gestión de la seguridad de aplicaciones, puesta en practica con un módulo de seguridad asociado a un equipo móvil de telefonía móvil. El módulo de seguridad de un teléfono móvil o portátil es conocido bajo la denominación de "tarjeta SIM" (Subscriber Identity Module, por su acepción en inglés) que constituye el elemento central de la seguridad de estos teléfonos. El operador de telefonía introduce, en el momento de la fabricación y/o durante una fase de personalización, un número llamado IMSI (International Mobile Subscriber Identification) que sirve para identificar de una manera segura y única cada abonado gue desee conectarse a una red móvil. Cada teléfono móvil, llamado equipo móvil de aquí en adelante, es identificado físicamente por un número almacenado en una memoria no volátil del equipo móvil. Este número, llamado IMEI, (International Mobile Equipment Identifier) contiene una identificación del tipo de equipo móvil y un número de serie que sirve para identificar de manera única un equipo móvil proporcionado en una red del tipo GSM (Global System for Mobile Communications) , GPRS Ref. : 172280 (General Packet Radio System) o UMTS (Universal Mobile Telecommunications System) . Ademas, un equipo móvil es caracterizado por una versión de programa SVN (Software Versión Number) que indica el estado de actualización del software básico instalado sobre el equipo móvil. La combinación de la identificación del tipo y del número de serie del equipo móvil con la versión de software (SVN) proporciona una nueva identificación, llamada IMEISV (International Mobile Equipment Identifier and Software Versión Number) . El mismo concepto de identificación se aplica también al WLAN (Wireless LAN) o al cable TV bidireccional . El identificador físico puede ser una dirección MAC (Media Access Control) que corresponde a la dirección única que identifica la configuración del equipo de un usuario en una red IP (Internet Protocol) y la versión de software puede ser transmitida por protocolos de capa superior basados en la IP. Las normas ETSI Instituto Europeo de Estándares de Telecomunicaciones ("European Telecommunications Standards Institute") , definen una estación móvil (MS, mobile station) compuesta por un equipo móvil (ME, mobile equipment) y un módulo de abonado (SIM, subscriber identity module) . Este módulo de abonado es en general móvil, es decir que puede ser o bien retirado o trasladado de un equipo móvil a otro. Durante la puesta en servicio de un equipo móvil, mas particularmente durante la conexión de un operador a la red, unas informaciones que .incluyen los datos de identificación son intercambiadas entre el equipo móvil y el centro de gestión del operador que autoriza o no su utilización. Actualmente un equipo móvil ofrece al usuario, además de su función usual de establecimiento de conversaciones telefónicas mediante un acceso a una red móvil, la utilización de varios otros servicios suplementarios de valor añadido tales como la consulta de diversas informaciones, las operaciones bancarias a distancia, el comercio electrónico, el acceso a un contenido multimedia, etc. . Estos -Servicios evolucionados necesitan un nivel de seguridad cada vez más elevado para preequipar a los usuarios contra los fraudes eventuales causados por terceros que intentan aprovecharse de los fallos de seguridad que pueden aparecer en los equipos móviles . Una verificación es por lo tanto necesaria al menos a dos niveles: por una parte al nivel del propio equipo móvil y por otra parte al nivel de las aplicaciones de software que permiten el funcionamiento de los diferentes servicios propuestos por el operador o por terceros . Estas aplicaciones son descargadas en general desde el servidor de un proveedor de aplicaciones, lo que implica la necesidad de verificar esta descarga. Se trata por lo tanto de garantizar que el módulo de abonado proporcione unas informaciones solamente a unas aplicaciones autorizadas una vez que el servidor de control ha reconocido que ese módulo puede funcionar con el equipo móvil en el que está insertado. El módulo de abonado puede contener* informaciones confidenciales tales como un número dé cuenta bancario o una contraseña. Una aplicación que funciona en el equipo móvil se encargará de utilizar esos datos personales con el fin de proporcionar el servicio esperado. Sin embargo, una aplicación puede desviar esos datos personales con otros fines que el dialogo con el proveedor de aplicación relacionado. Lo que puede llegar a ser un perjuicio importante para el propietario del módulo de abonado. Estas aplicaciones ejecutadas en el equipo móvil utilizan unos recursos disponibles en el módulo de abonado. Por recursos, se entienden diversas funciones y datos necesarios para el buen funcionamiento de una aplicación. Algunos de estos recursos pueden ser comunes a varias aplicaciones, en particular las funciones referentes a la seguridad. El módulo de abonado puede así bloquear o alterar el funcionamiento de ciertas aplicaciones para las que las condiciones de seguridad establecidas por el operador y/o los proveedores de aplicaciones no son respetados en el equipo móvil en cuestión o los derechos del usuario del equipo móvil son insuficientes . El documento FR2831362 describe un método de transacción protegida entre un teléfono móvil provisto de una tarjeta SIM y un servidor de aplicaciones. El objetivo de este método es proteger los derechos referentes al uso de aplicaciones descargadas desde el servidor por medio de la tarjeta SIM. Según este método, una relación de confianza es establecida en primer lugar entre el servidor y la tarjeta SIM mediante el intercambio protegido de claves públicas, después se efectúa una compra de una aplicación por la transmisión de un fichero de solicitud por el equipo móvil al servidor. Este codifica parcialmente o totalmente la aplicación y transmite al equipo móvil un criptograma formado por la clave de codificación y una orden, todo eso codificado con una clave pública conocida por la tarjeta SM. Cuando el equipo móvil recibe el criptograma, este es descodificado y la clave es almacenada en la tarjeta SIM. La ejecución de la orden activa la descarga en el equipo móvil de la aplicación parcial o totalmente codificada por el servidor. Una vez descargada, la aplicación es descodificada por la clave almacenada en la tarjeta SIM y posteriormente instalada en el equipo móvil . Según este método, los derechos de uso de la aplicación en el equipo móvil son protegidos debido a la relación de confianza establecida inicialmente entre el equipo y el servidor, y que es anterior a la transacción. La función realizada por el servidor se centra aquí preferentemente en la gestión de los derechos o DRM (Digital Rights Management) de los usuarios de una aplicación en un equipo móvil. La solución desarrollada a continuación es orientada de preferencia hacia la gestión de riesgos (Risk Management) tomados en cuenta por el operador, el proveedor de aplicación o el usuario con respecto a una aplicación. El objetivo de la presente invención consiste en proponer un método de autentificación de la o las aplicaciones en un equipo móvil tanto durante su descarga como durante su ejecución. Se trata de limitar los riesgos referentes al hec_hp__.de que se utilice un módulo de abonado con malas intenciones o bien mediante unas aplicaciones que no cumplen ciertos criterios de seguridad, o mediante unos equipos móviles que no cumplen ciertos criterios de seguridad preestablecidos . Otro objetivo consiste en proteger al usuario del equipo móvil así como a los proveedores de aplicaciones relacionados contra los abusos producidos por el uso de aplicaciones no autorizadas. Estos objetivos son alcanzados por un método de autentificación de al menos una aplicación que funciona en un equipo conectado por una red a un servidor de control, dicho equipo está localmente conectado a un módulo de seguridad, dicha aplicación es cargada y/o ejecutada por medio de un entorno de ejecución de aplicaciones del equipo y utiliza unos recursos almacenados en el módulo de seguridad, comprendiendo las etapas preliminares siguientes : recepción de datos comprendiendo al menos el identificador del equipo y el identificador del módulo de seguridad, a través de la red, por el servidor de control, análisis y verificación por el servidor de control de dichos datos, generación de un criptograma que incluye una huella de la aplicación, unos datos de identificación del equipo y del módulo de seguridad y unas instrucciones destinadas a dicho módulo, transmisión de dicho criptograma, a través de la red y el equipo, al módulo de seguridad, verificación de la aplicación comparando la huella extraída del criptograma recibido con una huella determinada por el módulo de seguridad, dicho método está caracterizado por el hecho de que, durante la inicialización y/o la activación de la aplicación, el módulo de seguridad ejecuta las instrucciones extraídas del criptograma y libera, respectivamente bloquea el acceso a ciertos recursos de dicho módulo de seguridad en función del resultado de la verificación propia a esta aplicación efectuada previamente . Los recursos del módulo de seguridad son bloqueados o liberados de manera determinada, esto con el fin de hacer que ciertas aplicaciones sean utilizables o no. No se bloquean o liberan directamente unas aplicaciones del equipo móvil: se actúa de forma indirecta sobre las aplicaciones, es decir que el efecto de bloqueo o de liberación se manifestara únicamente cuando el equipo móvil intente ejecutar estas aplicaciones . Este método se aplica preferiblemente a la red móvil. En consecuencia, el equipo es, por ejemplo, un equipo de telefonía móvil y el módulo de seguridad un módulo de abonado o tarjeta SIM. Este conjunto se conecta a una red móvil del tipo GSM..(Global System for Mobile Communications) , GPRS (General Packet Radio Service) , UMTS (Universal Mobile Telecommunications System) u otro, gestionado por un servidor de control de un operador. Las aplicaciones de software son instaladas en el equipo móvil y configuradas de manera que se utilicen unos recursos (datos o funciones) presentes en el módulo de abonado. Por lo que estas solo pueden ser utilizadas en conjunto cuando las condiciones de seguridad son satisfactorias según unos criterios preestablecidos por el operador y/o el proveedor de aplicaciones . Esta verificación de criterios está a cargo del servidor de control. La aplicación, siguiendo las instrucciones mandadas por el servidor de control, está finalmente a cargo del módulo de seguridad que puede dejar libre o bloquear el acceso a unos recursos necesarios para el buen funcionamiento de una aplicación instalada en el equipo móvil. Los datos de estos recursos pueden comprender unas informaciones tales como unos números de cuentas, unos programas (en forma de código que puede ser instalado en el equipo móvil) , unas claves de codificación/descodificación, unos derechos de acceso a un contenido, etcétera. Las funciones de estos recursos pueden comprender algoritmos criptográficos, procesos de verificación, procesos de generación de firmas digitales, procesos de codificación, procesos de autentificación, procesos de validación de datos, procesos de control de acceso, procesos de salvaguarda de datos, procesos de pago, etcétera. El método según la invención se basa en el hecho de que se asocia un criptograma a una aplicación que condiciona el uso de la aplicación en un equipo móvil conectado a una red. A diferencia del método descrito en el documento FR2831362, no se necesita la codificación parcial o total de la aplicación, antes de la descarga en el equipo móvil. Efectivamente, según el método de la invención, la conexión entre el servidor y el módulo de seguridad (o módulo de abonado) sirve para controlar de manera óptima sus recursos y decidir su puesta en servicio o no con respecto a las aplicaciones ejecutadas en el equipo móvil. La orden recibida desde el servidor, durante el proceso del documento citado, permite controlar la utilización de la aplicación instalada en el equipo móvil, mientras que en el presente método, esta permite activar o desactivar los recursos del módulo de seguridad. Por ejemplo, cuando se desactivan unos recursos, la aplicación funcionará de forma "mínima" dejando al usuario un número reducido de posibilidades. En un ejemplo de realización, esta reducción puede aplicarse al importe máximo autorizado para la compra de servicios y además, solo se podrían obtener estos servicios en un lugar determinado (centro comercial^ nivel, estación, aeropuerto,, etc.) En un primer modo de realización, el criptograma es transmitido al módulo de abonado durante la carga de la aplicación. En un segundo modo de realización, es la aplicación la que va buscar el criptograma sobre el servidor de control durante su primera utilización. El método de autentificación según la invención se aplica también durante la ejecución de una aplicación por el equipo móvil, lo que permite estar seguro, con la ayuda del módulo de abonado, de que esta aplicación está autorizada a acceder a ciertos recursos (datos o funciones) contenidos en dicho módulo de abonado. En particular, el módulo de abonado puede verificar regularmente el criptograma asociado a una aplicación durante la ejecución de dicha aplicación.

Por ejemplo, la inserción de un módulo de abonado de un usuario en otro equipo - móvil influirá sobre el funcionamiento de ciertas aplicaciones sin impedir el establecimiento de comunicaciones telefónicas tradicionales. Esta barrera actúa en cierto modo como un filtro destinado a eliminar equipos móviles no autorizados, o también aplicaciones procedentes de fuentes no aceptadas por el operador o un proveedor de aplicación asociado. Una modificación de la aplicación por terceros es detectada también por el módulo de abonado que se negará a ejecutar ciertas órdenes recibidas, generando así el bloqueo o unas..limitaciones de. la_ej_ecución jde la aplicación. El servidor de control tiene por lo tanto una función esencial de control de los elementos de confianza o de seguridad referentes al conjunto equipo móvil/módulo de abonado. Este interpreta los datos transmitidos por el equipo móvil con el fin de controlar o limitar la utilización de aplicaciones gracias a los recursos (datos o funciones) almacenados en el módulo de abonado. El servidor que recibe las informaciones de identidad de un equipo móvil y de su módulo de abonado y que comprende los identificadores IMEISV y el IMSI decide, en función de ciertos criterios, si se debe enviar una nueva instrucción al módulo de abonado para volver a definir un nuevo perfil de protección que define los recursos del módulo de abonado que pueden ser utilizados por las aplicaciones ejecutadas en el equipo móvil. Los criterios pueden referirse, por ejemplo, a la actualización de la versión de software instalada en el equipo móvil, a la descarga de nuevas aplicaciones en el equipo móvil, al periodo de actualización del perfil de protección, al número de conexiones a la red, a la tecnología utilizada para el acceso a la red, a la identidad de la red de acceso utilizada. Estos también están relacionados con distintos riesgos asociados al material o a los softwares utilizados que el operador y/o el proveedor de aplicaciones y/o el usuario del equipo móvil deseen tener en cuenta. La verificación del criptograma puede efectuarse durante la primera puesta en funcionamiento o durante la primera utilización de una aplicación o en cada puesta en funcionamiento de ésta. Según una variante, ésta puede ser ejecutada periódicamente a un ritmo establecido según unas instrucciones procedentes del servidor de control . Durante una carga de una aplicación en un equipo móvil, el criptograma asociado gue acompaña la aplicación incluye en general una huella de la propia aplicación, es decir un bloque de datos calculado a partir del código de la aplicación con la ayuda de una función matemática unidireccional de comprobación aleatoria. Cuando el módulo de abonado verifica la validez del criptograma, éste identifica también, de forma indirecta, el equipo móvil y se asegura de . que los datos proceden efectivamente del servidor de control. En otras palabras, mediante este criptograma, el servidor de control asegura implícitamente al módulo de abonado de que se han tornado en cuenta el tipo y la versión de programa del equipo móvil, de que la carga de la aplicación ha sido controlada y de que la aplicación es auténtica. Según unas instrucciones recibidas previamente, el módulo de abonado decidirá si autorizar o rechazar unas solicitudes o unas órdenes que provienen de la aplicación. El equipo móvil tiene una función de relevo en esta etapa de verificación mediante el establecimiento de un dialogo casi directo entre el módulo de abonado y el servidor de control. De esta manera, la seguridad de los mensajes intercambiados está garantizada de principio a fin entre el servidor de control y el módulo de abonado, a través del entorno de ejecución de las aplicaciones del equipo móvil. Por lo que este no puede "hacer trampas" o transformar los datos respecto al módulo de abonado. La presente invención se refiere también a un módulo de seguridad que incluye unos recursos destinados a ser accedidos localmente mediante al menos una aplicación instalada en un equipo conectado a una red, dicho equipo comprendiendo unos medios de lectura y de transmisión de datos comprendiendo al menos el identificador del equipo y el identificador del módulo de seguridad, dicho módulo está caracterizado por el hecho de que comprende unos medios de recepción, de almacenamiento y de análisis de un criptograma que contiene entre otros datos una huella de dicha aplicación y unas instrucciones, unos medios de verificación de dicha aplicación y unos medios de extracción y de ejecución de las instrucciones contenidas en el criptograma que liberan o bloquean ciertos recursos según el resultado de la verificación de la aplicación. Este módulo de seguridad es utilizado por ejemplo como módulo de abonado o tarjeta SIM conectado a un equipo móvil . Se comprenderá mejor la invención gracias a la descripción detallada siguiente y que se refiere a las figuras anexas proporcionadas a modo de ejemplo en ningún caso limitativo, a saber: la figura la ilustra un esquema funcional que muestra el proceso de instalación de una aplicación según un primer modo de realización donde el criptograma es entregado a través del entorno de ejecución de aplicaciones. la figura Ib ilustra el proceso de verificación del criptograma según el modo de la figura la. la figura le ilustra el proceso de ejecución de la aplicación que utiliza los recursos del módulo de abonado según el modo de la figura la. la figura 2a ilustra un esquema funcional que muestra el proceso de instalación de una aplicación según un segundo modo en el que la aplicación sola es descargada. - la figura 2b ilustra el proceso de verificación donde la aplicación solicita un criptograma al servidor de control según el modo de la figura 2a. la figura 2c ilustra el proceso de ejecución de la aplicación que utiliza los recursos del módulo de abonado según el modo de la figura 2a. la figura 3a ilustra un esquema funcional que muestra el proceso de instalación de una aplicación según un tercer modo donde la aplicación sola es descargada. la figura 3b ilustra el proceso de verificación donde la aplicación solicita un criptograma y una huella de la aplicación al servidor de control según el modo de la figura 3a. la figura 3c ilustra el proceso de ejecución de la aplicación que utiliza los recursos del módulo de abonado según el modo de la figura 3a. la figura 4 ilustra la estructura de un ejemplo de criptograma. Los esquemas funcionales de las figuras la, Ib, le, 2a, 2b, 2c, 3a, 3b, 3c muestran un conjunto equipo móvil (CB) módulo de abonado (tarjeta SIM) que contiene unos recursos (RES) conectado por una red móvil (NET) a un servidor de control (CSE) administrado por un operador. Este servidor (CSE) está conectado a uno o varios proveedores de aplicaciones (FA) . El equipo móvil (CB) incluye una o varias aplicaciones (APR) de software que funcionan en un entorno de ejecución (AEE) . Estas aplicaciones (APP) provienen, o bien del proveedor de aplicaciones (FA) asociado al servidor de control (CSE) del operador, o, pueden ser programadas al origen por el fabricante del eguipo móvil (CB) . En este último caso, a veces resulta necesario descargar unas actualizaciones que son verificadas también por el módulo de abonado (tarjeta SIM) . Según el primero modo de realización ilustrado por las figuras la, Ib, le, el criptograma (CRY) de una aplicación (APP) es entregado al módulo de abonado (SIM) por el entorno de ejecución de aplicaciones (AEE) durante el proceso de instalación de la aplicación (APP) . La figura la ilustra el proceso de instalación al que el equipo móvil (CB) transmite en primer lugar unos datos que sirven para la identificación (ID) del módulo de abonado (SIM) que el servidor de control (CSE) verifica. Esa identificación (ID) es efectuada a partir del identificador (IMSI) del módulo de abonado (SIM) y del identificador (IMEISV) único del equipo móvil (CB) . Una aplicación (APP) es posteriormente descargada desde el servidor (CSE) acompañada por un criptograma (CRY) que será transmitido hacia el módulo de abonado (SIM) a través del entorno de ejecución (AEE) para una verificación tal y como es ilustrado en la figura Ib. Se debe tener en cuenta que el operador considera al proveedor (FA) digno de confianza, es decir que las aplicaciones (APP) son homologadas y funcionan sin producir ninguna perjuicio al usuario y/o al operador. El método según la invención se aplica a varias formas de aplicaciones (APP) ejecutadas en distintos tipos de entorno de ejecución (AEE) . Por ejemplo, varios teléfonos móviles poseen unas funcionalidades obtenidas a partir de aplicaciones Java que son ejecutadas por una máquina virtual (VM) Java que sirve de procesador y de entorno. La descripción siguiente se basa en el ejemplo de aplicaciones Java. Por supuesto, otros entornos o sistemas de explotaciones tales como Symbian OS, Windows, Palm OS, Linux etc., pueden ser utilizados como soporte de aplicaciones. Durante su ejecución, ver figura le, una aplicación Java solicita el módulo de abonado (SIM) , ésta informa de ello al entorno de ejecución (AEE) dirigiéndole las solicitudes u órdenes (CMD) . El entorno de ejecución (AEE) calcula la huella (FIN2) de la aplicación (APP) y la envía al módulo de abonado (SIM) . El criptograma (CRY) que ha sido generado por el servidor de control (CSE) y posteriormente cargado en el equipo móvil (CB) con la aplicación (APP) (o separadamente) , es almacenado en el módulo de abonado (SIM) . Este último verifica primero que posee efectivamente los datos necesarios que le van a permitir decidir si debe responder a las solicitudes u órdenes (CMD) de la aplicación (APP) . Esos datos, que se definen como derechos cargados a partir del servidor de control (CSE) durante la carga de la aplicación (APP) , permiten controlar el funcionamiento de la aplicación (APP) . En caso de ausencia de estos derechos, la aplicación (APP) no podrá utilizar los recursos (RES) (datos o funciones) del módulo de abonado (SIM) . En caso de que estos derechos estén presentes, el módulo de abonado (SIM) verifica la huella (FINÍ) generada por el criptograma (CRY) almacenado comparándola con la huella (FIN2) asociada a la aplicación (APP) y proporcionada por el entorno de aplicación (AEE) . Este criptograma (CRY) puede estar constituido en forma de bloque codificado por una clave privada del tipo RSA (Rivest, Shamir, Adelman) . Este bloque representado por la figura 4 contiene por ejemplo, entre otros datos, el identificador IMSI (ID_SIM) del módulo (SIM) de abonado, el identificador IMEISV (ID_CB) del equipo móvil (CB) , un identificador (ID_APP) de la aplicación, la huella (FINÍ) de la aplicación (APP) , unos identificadores SIM (RESJD) , unos recursos (RES) y unas instrucciones (INS_RES) de bloqueo/liberación de los recursos SIM. Solo el servidor, de control (CSE) conocería esta clave privada, mientras que el módulo de abonado (SIM) conocería su parte pública. La ventaja de utilizar claves asimétricas reside en el hecho de que la clave que sirve para crear unos criptogramas no se encuentra al exterior del servidor de control (CS?) . Por supuesto, otros algoritmos de claves asimétricas tales como por ejemplo DSA (Digital Signature Algorithm) , y ECC (Elliptic Curve Cryptography) pueden constituir unas alternativas a. RSA El uso de un algoritmo de claves simétricas puede ser el preferido por razones de simplicidad, rapidez de las verificaciones o por unos costos de fabricación y de puesta en funcionamiento mas reducidos. En ese caso, el servidor (CSE) conocería la clave así como el módulo de abonado (SIM) , por ejemplo se podría utilizar un algoritmo IDEA (International Data Encryption Algorithm) para firmar el bloque (IMSI, IMEISV, identificador de la aplicación, huella de la aplicación, identificadores de los recursos SIM, instrucciones de bloqueo/liberación de los recursos SIM) . Como alternativa al algoritmo IDEA, también se pueden utilizar algoritmos tales como por ejemplo, TDES (Triple Data Encryption Standard) y AES (Advanced Encryption Standard) . En estas dos variantes de claves asimétricas y simétricas, el módulo de abonado (SIM) verifica la concordancia de los diferentes campos que aparecen en el criptograma (CRY) , en particular controla los identificadores de aplicaciones (ILYAPP) y las huellas de aplicaciones (FINÍ) que están autorizadas o no a utilizar sus recursos (RES) (datos o funciones) . En una variante, el criptograma (CRY) puede incluir un contador que sirve para impedir el doble uso de un mismo criptograma enviado al módulo de abonado (SIM) (replay attack) . Efectivamente dos aplicaciones del mismo tipo pueden tener el mismo identificador y la misma huella (FINÍ) . En este caso, el módulo de abonado (SIM) controlará también el valor de ese contador en comparación con el de un contador de referencia almacenado y actualizado regularmente. Una variante del contador consiste en utilizar un imprevisto aleatorio (número aleatorio) generado por el módulo de abonado (SIM) . Este imprevisto aleatorio es transmitido con los datos enviados al servidor de control (CSE) . Este último reenvía este imprevisto aleatorio en el mensaje de respuesta y el módulo de abonado (SIM) puede verificar si se trata efectivamente de un nuevo mensaje. Más habitualmente, con el fin de evitar todo riesgo de uso de un antiguo criptograma (CRY) , ésta última comprende una variable predecible por el módulo de abonado (SIM) , sea un contador o un imprevisto aleatorio .

En otra variante el criptograma (CRY) generado con la ayuda de una clave del tipo RSA o IDEA puede ser reemplazado por un bloque generado con una clave compartida HMAC (Keyed-Hashing for Mensaje Authentication) a partir del conjunto (IMSI, IMEISV, identificador de la aplicación, huella de la aplicación, identificadores de los recursos SIM, instrucciones de bloqueo/liberación de los recursos SIM) .. HMAC es un mecanismo para la autentificación de mensajes por la utilización de funciones de comprobación aleatoria criptográficas tales como MD5 (Message Digest) o SHA-1 (Secure Hash Algorithm) , en combinación con una clave compartida. Esta clave presente a la vez en el servidor de control (CSE) y en el módulo de abonado (SIM) puede ser cargada durante la personalización del módulo de abonado (SIM) o durante la instalación de algunos recursos (RES) en el módulo de abonado (SIM) . Según las opciones, a cada recurso (RES) o grupo de recursos del módulo de abonado (SIM) puede estar asociada una clave diferente, o también, la clave puede ser global para el conjunto de recursos (RES) y única para un módulo de abonado (SIM) determinado. El criptograma (CRY) permite por lo tanto que el módulo de abonado (SIM) conozca el o los recursos (RES) que puede ser liberados o bloqueados en el módulo de abonado (SIM) para el equipo móvil (CB) correspondiente.

Las dos huellas utilizadas (FINÍ, respectivamente FIN2) son elementos determinantes ya que constituyen un medio de control criptográfico de la aplicación (APP) por el equipo móvil (CB) y por el módulo de abonado (SIM) . Tal control es necesario para impedir que una aplicación de terceros se autentifique con un criptograma (CRY) determinado. Efectivamente, si el criptograma A autentifica la aplicación A ante el módulo de abonado A en un equipo móvil A, hay que evitar que otra aplicación B se autentifique indebidamente con ese mismo criptograma A ante el módulo de abonado A en el equipo móvil A. Según una variante, la huella de la aplicación (FINÍ) incluida en el criptograma (CRY) sigue confidencial de principio a fin entre el servidor de control (CSE) y el módulo de abonado (SIM) . Con este fin, la huella (FINÍ) es codificada por el servidor de control (CSE) y descodificada por el módulo de abonado (SIM) . Además, la aplicación (APR) puede estar personalizada para una carga establecida para que la huella (FINÍ) incluida en el criptograma (CRY) y la huella (FIN2) de la aplicación (APR) calculada por el entorno de ejecución (AEE) se mantengan idénticas pero dependan de la identidad del equipo móvil (CB) . Tal medida es necesaria si se quiere impedir que una aplicación de terceros se autentifique con una huella determinada en otro entorno de ejecución de aplicaciones (AEE) cuya interfaz con el módulo de abonado (SIM) estaría comprometida. Efectivamente, si la huella A autentifica la aplicación A ante el módulo de abonado A en un equipo móvil A, hay que evitar que otra aplicación B se autentifique indebidamente con esa misma huella A ante el módulo de abonado B en el equipo móvil B. Según otra variante, cada aplicación (del tipo Java) es acompañada por dos criptogramas : un criptograma Java destinado a la máquina virtual (VM) y un criptograma (CRY) destinado al módulo de abonado (SIM) . Estos dos criptogramas comprenden entre otras cosas la misma huella de aplicación (llamada aquí FIN2) que es la del código de la aplicación Java. De este modo, cuando el módulo de abonado (SIM) debe verificar el criptograma (CRY) de una aplicación, este espera de la máquina virtual (VM) la huella (FIN2) asociada a la aplicación (APR) en cuestión que seguramente habrá calculado anteriormente. La huella de la aplicación es transmitida por el equipo móvil (CB) al módulo de abonado (SIM) . Esta huella no proviene del servidor de control, es calculada por el entorno de ejecución de aplicaciones (AEE) del equipo móvil (CB) después de la descarga de la aplicación (APR) . En cambio, el equipo móvil (CB) transmite el criptograma (CRY) previamente cargado sobre la aplicación desde el servidor de control al módulo de abonado. Por lo que, este último puede verificar la huella recibida en comparación. El equipo móvil (CB) no puede hacer trampas mientras no conoce la huella esperada por el módulo de abonado (SIM) ; en ese caso, la función de cálculo de la huella, que es habitualmente una función de comprobación aleatoria, necesitaría ser reversible o bien encontrar otra huella que genere el mismo criptograma (CRY) lo cual es casi imposible. La figura Ib muestra el proceso de verificación del criptograma (CRY) que puede ser efectuado o bien regularmente, por ejemplo antes de cada solicitud de la aplicación (APR) referida, o preferiblemente, una sola vez antes de su instalación o antes de su primera utilización. Si el criptograma (CRY) es válido, el módulo de abonado (SIM) transmite un mensaje de aceptación (OK) al entorno de ejecución (AEE) . La aplicación (APR) puede entonces dirigir sus solicitudes o pedidos (CMD) al módulo de abonado (SIM) a través del entorno de ejecución (AEE) y utilizar los recursos (RES) del módulo de abonado (SIM) . Este último acepta los pedidos (CMD) transmitiendo las respuestas (RSP) adecuadas a la aplicación (APP) a través del entorno de ejecución (AEE) , ver figura le. En caso de criptograma (CRY) no válido, el módulo de abonado (SIM) transmite un mensaje de rechazo (NOK) al entorno de ejecución (AEE) . En tal caso el entorno de ejecución (AEE) puede, o bien cancelar el proceso de instalación de la aplicación (APP) , o la aplicación (APP) es instalada y sus solicitudes o sus órdenes (CMD) enviadas al módulo de abonado (SIM) a través, del entorno de ejecución (AEE) seguirán sin respuesta (RSP) y no se podrán utilizar los recursos (RES) del módulo de abonado (SIM) . En ambos casos de aceptación y de rechazo (OK y NOK) el entorno de ejecución de aplicación (AEE) puede pasar la respuesta al servidor de control (CSE) . El módulo de abonado puede de esta manera reenviar indirectamente una confirmación (CF) de recepción del criptograma (CRY) al servidor de control (CSE) y permitir un control de principio a fin de la operación, ver figura Ib. La confirmación (CF) incluye al menos un código de éxito o de error de la operación así como un contador que sirve para la protección contra unos ataques de repetición. Este mensaje permite también al servidor de control (CSE) actualizar el contador asociado con el módulo de abonado (SIM) . Según el segundo modo de realización ilustrado por las figuras 2a, 2b, 2c, la aplicación (APP) es descargada sola, después de la identificación (ID) del equipo móvil (CB) , sin criptograma (CRY) , ver figura 2a. Durante el proceso de verificación, figura 2b, la aplicación (APP) solicita, durante su lanzamiento por el usuario, un criptograma (CRY) que comprende los derechos de utilización de recursos (RES) por dicha aplicación. Este criptograma (CRY) es descargado, desde el servidor (CSE) de control, directamente por la aplicación (APP) que lo transmite al módulo de abonado (SIM) a través del entorno de ejecución (AEE) . El módulo de abonado (SIM) transmite una confirmación (CF) de recepción del criptograma (CRY) al servidor (CSE) , a través de la aplicación (APP) y no a través del entorno de ejecución (AEE) como en el caso del primer modo de realización. En ese modo, el entorno de ejecución (AEE) tiene solo una función de relevo entre la aplicación (APP) y el módulo de abonado (SIM) . El proceso de ejecución de la aplicación (APP) después de una verificación del criptograma (CRY) , ver figura 2c, se desarrolla de la misma manera que en el primer modo ilustrado por la figura le y descrito anteriormente. Las figuras 3a, 3b, 3c muestran una tercera variante en la que la aplicación APP es descargada sola, después de una identificación (ID) del equipo móvil (CB) , desde el servidor de control (CSE) o desde un servidor intermedio de descarga de aplicaciones (APP) ver figura 3a. Durante el proceso de verificación (figura 3b) , la aplicación carga el criptograma (CRY) y la huella (FIN2) directamente a partir del servidor (CSE) o desde un servidor intermedio de descarga de aplicaciones (APP) . En ese caso, a diferencia de las dos variantes precedentes, el entorno de aplicación (AEE) ya no calcula la huella (FIN2) que es calculada por una unidad externa o bien por el servidor de control CSE, o por un servidor intermedio de descarga de aplicaciones (APP) . El proceso de ejecución de la aplicación (APP) después de la verificación del criptograma (CRY) , ver figura 3c, se desarrolla de la misma manera que en los dos modos precedentes ilustrados por las figuras le y 2c. Se puede preferir este tercer modo de realización ya que su ventaja consiste en no solicitar ninguna modificación del entorno de ejecución (AEE) tal y como es definido en la actualidad para las aplicaciones Java instaladas en los teléfonos móviles, es decir que no se necesita ninguna modificación de las normas existentes. Además, la obligación de la primera variante que requiere que los dos criptogramas utilicen la misma huella desaparece ya que los procesos de verificación del criptograma (CRY) y el de la instalación de la aplicación son totalmente independientes . Con el fin de personalizar las huellas calculadas en las aplicaciones, una posibilidad consiste en añadir al código de la aplicación, antes de su carga en el equipo móvil, un dato diferente para cada equipo móvil. De este modo, cuando la huella es calculada por el entorno de aplicación del equipo móvil, esta huella es única y no puede servir a otro equipo móvil . El criptograma por supuesto va a ser calculado por el servidor de control con base en unos datos de origen de la aplicación y a este dato único. En una variante de la invención, el equipo móvil puede ser reemplazado por un equipó no móvil tal como un descodificador de televisión de pago o un ordenador. Unas aplicaciones pueden ser descargadas en el equipo a partir de un servidor a través de una red de telecomunicaciones . Un criptograma asociado a la aplicación es almacenado en el módulo de seguridad y verificado durante la puesta en servicio o durante cada puesta en funcionamiento de aplicación. El resultado de esta verificación condiciona el funcionamiento de la aplicación mediante la liberación o el bloqueo de los recursos en el módulo de seguridad. Se hace constar que con relación a esta fecha, el mejor método conocido por la solicitante para llevar a la práctica la citada invención, es el que resulta claro de la presente descripción de la invención.

Claims (18)

1. REIVINDICACIONES Habiéndose descrito la invención como antecede, se reclama como propiedad lo contenido en las siguientes reivindicaciones : 1. Un método de autentificación de al menos una aplicación (APP) que funciona en un equipo (CB) conectado por una red (NET) a un servidor dé control (CSE) , el equipo (CB) está localmente conectado a un módulo de seguridad (SIM) , la aplicación (APP) es cargada y/o ejecutada por medio de un entorno de ejecución de aplicaciones (AEE) del equipo (CB) y utiliza unos recursos (RES) almacenados en el módulo de seguridad (SIM) , que incluye las etapas preliminares siguientes: recepción de datos comprendiendo al menos el identificador (IMEISV) del equipo (CB) y el identificador (IMSI) del módulo de seguridad (SIM) , a través de la red (NET) , por el servidor de control (CSE) análisis y verificación por el servidor de control (CSE) de dichos datos, generación de un criptograma (CRY) comprendiendo una huella (FINÍ) de la aplicación (APP) , unos datos que identifican el equipo (CB) y el módulo de seguridad (SIM) y unas instrucciones (INS RES) destinadas a dicho módulo, transmisión del criptograma (CRY) , a través de la red (NET) y el equipo (CB) , al módulo de seguridad (SIM) , verificación de la aplicación (APP) mediante una comparación de la huella (FINÍ) extraída del criptograma (CRY) recibido con una huella (FIN2) determinada por el módulo de seguridad (SIM) , el método está caracterizado porque, durante la inicialización y/o la activación de la aplicación (APP) , el módulo de seguridad (SIM) ejecuta las instrucciones (INS_RES) extraídas del criptograma (CRY) y libera, respectivamente bloquea el acceso a ciertos recursos (RES) del módulo de seguridad (SIM) en función del resultado de la verificación propia a esta aplicación (APP) efectuada previamente.
2. 2. El método de conformidad con la reivindicación 1, caracterizado por el hecho de que el equipo es un equipo móvil (CB) de telefonía móvil.
3. 3. El método de conformidad con la reivindicación 1, caracterizado porque la red (NET) es una red móvil del tipo GSM o GPRS o UMTS .
4. 4. El método de conformidad con la reivindicación 1 ó 2, caracterizado por el hecho de que el módulo de seguridad (SIM) es un módulo de abonado insertado en el equipo móvil (CB) de telefonía móvil de tipo tarjeta SIM.
5. 5. El método de conformidad con la reivindicación 1 ó 4, caracterizado porque la identificación (ID) del conjunto equipo móvil (CB) /módulo de abonado (SIM) es efectuada a partir del identificador (IMEISV) del equipo móvil (CB) y del identificador (IMSI) del módulo de abonado (SIM) propio a un abonado a la red (NET) .
6. 6. El método de conformidad con la reivindicación 1, caracterizado porque las instrucciones incluidas en el criptograma (CRY) recibido por el módulo de seguridad (SIM) condicionan la utilización de las aplicaciones (APR) según unos criterios preestablecidos por el operador y/o el proveedor de aplicaciones (FA) y/o el usuario del equipo.
7. 7. El método de conformidad con la reivindicación 6, caracterizado por el hecho de que los criterios definen limites de utilización de una aplicación (APR) según riesgos asociados al software de dicha aplicación (APR) o al material del equipo (CB) que el operador desea tener en cuenta.
8. 8. El método de conformidad con la reivindicación 1, caracterizado porque la verificación de la aplicación (APR) con el criptograma (CRY) se efectúa durante la primera puesta en funcionamiento o durante la primera utilización de la aplicación (APP) .
9. 9. El método de conformidad con la reivindicación 1, caracterizado porque la verificación de la aplicación (APP) con el criptograma (CRY) se efectúa periódicamente a un ritmo establecido según instrucciones provenientes del servidor de control (CSE) .
10. 10. El método de conformidad con la reivindicación 1, caracterizado porque la verificación de la aplicación (APP) con el criptograma (CRY) se efectúa durante cada puesta en funcionamiento de la aplicación (APP) en el equipo (CB) .
11. 11. El método de conformidad con la reivindicación
12. I, caracterizado porque el criptograma (CRY) es generado con la ayuda de una clave de codificación asimétrica o simétrica a partir de un conjunto de datos que contiene, entre otros datos, el identificador (IMEISV) del equipo (CB) , el identificador (IMSI) del módulo de seguridad (SIM) , un identificador de la aplicación (APR) , la huella (FINÍ) de la aplicación (APP) calculada con una función unidireccional de comprobación aleatoria, unos identificadores (RESJD) de los recursos del módulo de seguridad (SIM) y unas instrucciones (INS_RES) de bloqueo/liberación de los recursos (RES) del módulo de seguridad (SIM) . 12. El método de conformidad con la reivindicación
13. II, caracterizado porque el criptograma (CRY) incluye una variable predecible por el módulo de seguridad (SIM) que evita el doble uso de un mismo criptograma (CRY) , y el valor de la variable es controlado por el módulo de seguridad (SIM) mediante una comparación con el de un valor de referencia almacenado en el módulo y actualizado regularmente. 13. El método de conformidad con la reivindicación 1, caracterizado por el hecho de que el módulo de seguridad (SIM) transmite al servidor de control (CSE) , a través del equipo (CB) y la red (NET) , un mensaje de confirmación (CF) cuando el módulo de seguridad (SIM) ha aceptado o rechazado un criptograma (CRY) de una aplicación (APP) .
14. 14. El método de conformidad con la reivindicación 1, caracterizado porque el criptograma (CRY) es transmitido al módulo de seguridad (SIM) al mismo tiempo que la aplicación (APP) es cargada en el equipo (CB) a través del entorno de ejecución de las aplicaciones (AEE) .
15. 15. El método de conformidad con la reivindicación 1, caracterizado porque la aplicación (APP) , una vez cargada en el equipo (CB) desde el servidor (CSE) de control a través de la red (NET) , solicita un criptograma (CRY) al servidor (CSE) durante su inicialización y transmite dicho criptograma (CRY) al módulo de seguridad (SIM) , y el mensaje de confirmación (CF) de aceptación o de rechazo del criptograma (CRY) es transmitido por el módulo de seguridad (SIM) al servidor a través de la aplicación (APP) .
16. 16. El método de conformidad con la reivindicación 1, caracterizado porque el equipo es un descodificador de televisión de pago o un ordenador al que está conectado el módulo de seguridad.
17. 17. Un módulo de seguridad que comprende los recursos (RES) destinados a ser accedidos localmente mediante al menos una aplicación (APP) instalada en un equipo (CB) conectada a una red (NET) , el equipo (CB) comprende los medios de lectura y de transmisión de datos que comprenden al menos el identificador (IMEISV) del equipo (CB) y el identificador (IMSI) del módulo de seguridad (SIM) , el módulo está caracterizado porque comprende medios de recepción, de almacenamiento y de análisis de .un criptograma (CRY) que contiene entre otros datos una huella (FINÍ) de la aplicación (APP) y unas instrucciones (INS_RES) , unos medios de verificación de dicha aplicación (APP) , y unos medios de extracción y de ejecución de las instrucciones (INS_RES) contenidas en el criptograma (CRY) mediante la liberación o el bloqueo de ciertos recursos (RES) , según el resultado de la verificación de la aplicación (APP) .
18. 18. El módulo de seguridad de conformidad con la reivindicación 17, caracterizado porque es del tipo "módulo de abonado" o "tarjeta SIM" destinado a estar conectado a un equipo móvil . RESUMEN DE LA INVENCIÓN El objetivo de la presente invención consiste en proponer un método de gestión de la seguridad de aplicaciones, puesto en practica con un módulo de seguridad asociado a un equipo móvil. Este objetivo es alcanzado mediante un método de autentificación de al menos una aplicación (APP) que funciona en un equipo (CB) conectado por una red (NET) a un servidor de control (CSE) , y dicho equipo (CB) está localmente conectado a. un módulo de seguridad (SIM) , dicha aplicación (APP) es cargada y/o ejecutada por medio de un entorno de ejecución de aplicaciones (AEE) del equipo (CB) y utiliza unos recursos (RES) almacenados en el módulo de seguridad (SIM) , que incluye las etapas preliminares siguientes: recepción de datos que incluye al menos el identificador (IMEISV) del equipo (CB) y el identificador (IMSI) del módulo de seguridad (SIM) , a través de la red (NET) , por el servidor de control (CSE) análisis y verificación por el servidor de control (CSE) de dichos datos, generación de un criptograma (CRY) que incluye una huella (FINÍ) de la aplicación (APP) , unos datos de identificación del equipo (CB) y del módulo de seguridad (SIM) y unas instrucciones (INS RES) destinadas a dicho módulo, transmisión de dicho criptograma (CRY) , a través de la red (NET) y del equipo (CB) , al módulo de seguridad (SIM) , verificación de la aplicación (APP) mediante una comparación de la huella (FINÍ) extraída del criptograma (CRY) recibido con una huella (FIN2) determinada por el módulo de seguridad (SIM) , el método está caracterizado por el hecho de que, durante la inicialización y/o la activación de la aplicación (APP) , el módulo de seguridad (SIM) ejecuta las instrucciones (INS_RES) extraídas del criptograma (CRY) y libera, respectivamente bloquea el acceso a ciertos recursos (RES) de dicho módulo de seguridad (SIM) en función del resultado de la verificación propia a esta aplicación (APP) efectuada previamente.