MXPA06004835A - Metodo de gestion de la seguridad de aplicaciones con un modulo de seguridad - Google Patents

Abstract

El objetivo de la presente invención consiste en proponer un método de gestión de la seguridad del equipo conjunto, módulo de seguridad, aplicaciones con el fin de limitar los riesgos relacionados con el hecho de que un módulo de seguridad sea utilizado con malas intenciones mediante unas aplicaciones ejecutadas sobre un equipo de tipo y/o de versión de software que no cumplen completamente con los criterios de seguridad establecidos. Este objetivo es alcanzado por un método de gestión de la seguridad de aplicaciones (APP) que funciona en un equipo (CB) conectado a una red (NET), dicha red (NET) es administrada por un servidor de control (CSE) de un operador, dichas aplicaciones utilizan unos recursos (RES) (datos o funciones) almacenados en un módulo de seguridad (SIM) conectado localmente a dicho equipo (CB), que incluye las etapas preliminares siguientes:- recepción de datos que comprenden al menos el tipo y la versión de programa del equipo (CB) y la identidad del módulo de seguridad (SIM), a través de la red, por el servidor de control, - análisis y verificación por el servidor de control (CSE) de dichos datos (ID), generación de un criptograma (J) a partir del resultado de la verificacion sobre dichos datos (ID), y transmision del criptograma (J), a través de la red (NET) y del equipo (CB), al módulo de seguridad (SIM), el método estácaracterizado por el hecho de que el módulo de seguridad (SIM) analiza el criptograma (J) recibido y activa, respectivamente desactiva unos recursos (RES) (datos o funciones) utilizados por al menos una aplicación (APP) instalada en el quipo (CB), dicho criptograma (J) comprendiendo unas instrucciones que condicionan el funcionamiento de la aplicación (APP) según unos criterios establecidos por el proveedor de la aplicación y/o el operador y/o el usuario del equipo.

Description

MÉTODO DE GESTIÓN DE LA SEGURIDAD DE APLICACIONES CON UN MODULO DE SEGURIDAD DESCRIPCIÓN DE LA INVENCIÓN La presente invención se refiere al ámbito de las redes móviles llamadas también redes celulares . Se refiere mas particularmente a la gestión de la seguridad de las aplicaciones utilizadas 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) 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 manera segura y única cada abonado que desee conectarse a una red móvil. Cada teléfono móvil, llamado equipo móvil a continuación, 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 dispuesto sobre una red del tipo GSM (Global System for Ref.: 172279 Mobile Communications) , GPRS (General Packet Radio System) o UMTS (Universal Mobile Telecommunications System) . Además, un equipo móvil se caracteriza por una versión de software SVN (Software Versión Number) que indica el estado de actualización del software de base 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 (SV?) proporciona una nueva identificación, llamada IMEISV (International Mobile Equipment Identifier and Software Versión ?umber) . 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 material de un usuario en una red IP (Internet Protocol) y la versión de programa puede ser transmitida por unos protocolos de capa superior basados en el IP . Las normas ETSI (Instituto Europeo de Estándares de Telecomunicaciones) ("European Telecommúnications 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 transferido de un equipo móvil a otro. Durante la puesta en servicio de un equipo móvil, mas particularmente durante su conexión a la red de un operador, unas informaciones que. comprenden 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. El documento EP0757502 describe un método de cierre de un módulo de identificación de usuario cuando el identificador físico del equipo móvil IMEI está en una lista negra. Cuando el equipo móvil se conecta a la red móvil, transmite el identificador IMEI a un centro de gestión. Este último verifica por comparación el identificador recibido con el contenido de una base de datos en la que el operador registra los identificadores de equipos móviles robados o defectuosos. Si un identificador recibido está presente en esa base de datos, el centro de gestión transmite un mensaje que contiene una orden de bloqueo al equipo móvil relacionado. Esta orden, después de verificar su autenticidad, es transmitida al módulo de identificación que ejecuta un procedimiento de cierre impidiendo toda conexión • ulterior del equipo móvil con la red. El documento US5864757 describe un método de activación de un combinado móvil con un módulo de abonado basado en la utilización de una clave propia al combinado que produce un código correspondiente a un identificador del módulo de abonado . El combinado incluye una clave única inviolable. Durante su activación, el centro de gestión del operador transmite un mensaje al combinado que sirve para que el operador calcule una clave específica utilizando la clave única del combinado. Esa nueva clave es utilizada en combinación con un identificador de la red o del módulo de abonado para generar una palabra de control que es confrontada con un código almacenado en el módulo de abonado. Si la contraseña de control concuerda con el código del módulo de abonado, el combinado es activado. Los métodos descritos en esos dos documentos tratan exclusivamente aspectos que necesitan una identificación física del equipo móvil, basada por ejemplo en el identificador IMEI . Cuando se ponen en práctica esos métodos, sus efectos se centran únicamente en el bloqueo/desbloqueo del módulo de abonado y/o del equipo móvil para impedir cualquier conexión del equipo móvil con la red. Actualmente un equipo móvil ofrece al usuario, además de su función usual de establecimiento de conversaciones telefónicas a través de un acceso a una red móvil, el uso 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 . Se trata de garantizar el hecho de que el módulo de abonado funcione sólo con un equipo móvil de un tipo y versión de programa debidamente autorizado o homologado por el operador y/o por los proveedores de aplicaciones. Por funcionamiento del módulo de abonado, se entiende su capacidad para permitir la utilización de servicios solicitados por un usuario mediante la ejecución de un número de aplicaciones de software instaladas previamente en una memoria del equipo móvil y que utilizan el módulo de abonado como medio de protección. Estas aplicaciones ejecutadas en el equipo móvil utilizan 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 a las funciones relacionadas con la seguridad. El módulo de abonado puede de este modo 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 respetadas en el equipo móvil en cuestión o los derechos del usuario del equipo móvil son insuficientes. Los documentos citados anteriormente no cubren los aspectos lógicos relativos a un conjunto de equipos móviles como por ejemplo unas informaciones relativas a unas aplicaciones de software instaladas, un número de versión de software o también una referencia de tipo o de modelo del equipo móvil, etc. Se trata por lo tanto de disponer de un método de gestión determinado de los recursos del módulo de abonado con el fin de activar/desactivar de una manera selectiva las aplicaciones o funciones de aplicaciones que utilizan estos recursos. Sin embargo no es deseable que estas operaciones impidan que el equipo móvil acceda a la red mediante el bloqueo total del módulo de abonado. El objetivo de la presente invención es el de proponer un método de gestión de la seguridad del conjunto equipo móvil, módulo de abonado, aplicaciones con el fin de limitar los riesgos relacionados con el hecho de que un módulo de abonado sea utilizado con malas intenciones por las aplicaciones ejecutadas sobre un equipo móvil de tipo y/o de versión de programa que no cumplen con algunos criterios de seguridad preestablecidos. Otro objetivo consiste en proteger al usuario del equipo móvil así como a los proveedores de aplicaciones referentes contra los abusos resultantes de una clonación del equipo móvil y/o del módulo de abonado. Estos objetivos son alcanzados por un método de gestión de la seguridad de aplicaciones que funciona en un equipo conectado a una red, dicha red es administrada por un servidor de control de un operador, las aplicaciones que utilizan recursos (datos o funciones) almacenados en un módulo de seguridad conectado localmente al equipo, comprendiendo las etapas preliminares siguientes: recepción de datos comprendiendo al menos el tipo y _ la versión de programa del equipo y de la identidad del módulo de seguridad, a través de la red, por el servidor de control, - análisis y verificación de dichos datos por el servidor de control, generación de un criptograma a partir del resultado de la verificación sobre dichos datos, y transmisión del criptograma, a través de la red y el equipo, al módulo de seguridad, dicho método es caracterizado por el hecho de que el módulo de seguridad analiza el criptograma recibido y activa, respectivamente desactiva unos recursos (datos o funciones) utilizados por al menos una aplicación instalada en el equipo, el criptograma comprende instrucciones que condicionan el funcionamiento de la aplicación según unos criterios preestablecidos por el proveedor de la aplicación y/o el operador y/o el usuario del equipo. Los recursos del módulo de abonado son bloqueados de manera determinada, esto con el objetivo de bloquear o reducir la función de algunas aplicaciones. No se bloquean directamente unas aplicaciones del equipo: se actúa de forma indirecta sobre las aplicaciones, es decir que el efecto de bloqueo se va a manifestar únicamente cuando el equipo intente ejecutar estas aplicaciones. Este método se aplica preferiblemente a la red móvil. Por consiguiente, el equipo es un equipo móvil, como por ejemplo un equipo de telefonía móvil o teléfono móvil. El módulo de seguridad es un módulo de abonado insertado en el teléfono móvil del tipo tarjeta SIM (subscriber identity module) . Este conjunto se conecta a una red móvil del tipo GSM (Global System for Mobile Communications) , GPRS (General Packet Radio System) , UMTS (Universal Mobile Telecommúnications System) u otra, gestionada por un servidor de control de un operador. Unas aplicaciones de software son instaladas en el equipo móvil y configuradas para utilizar unos recursos (datos o funciones) presentes en el módulo de abonado. Por lo que estas solo pueden ser utilizadas en su integridad si las condiciones de seguridad son satisfactorias según de los 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, según las instrucciones enviadas 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 al buen funcionamiento de una aplicación instalada en el equipo móvil . Los datos de estos recursos pueden comprender informaciones tales como un número de cuenta, los programas (en forma de código que puede ser instalado en el equipo móvil) , unas claves de codificación/descodificación, de los derechos de acceso a un contenido, etc. 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 servidor de control tiene una función esencial de gestión de los elementos de confianza o de seguridad relacionados con el conjunto equipo móvil/módulo abonado. Este interpreta los datos que le son transmitidos por el equipo móvil con el fin de controlar o limitar la utilización de aplicaciones, funciones o recursos disponibles por medio del 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 el IMEISV y el IMSI decide, según ciertos criterios, si se debe enviar una nueva instrucción al módulo de abonado para redefinir 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 instalado sobre el equipo móvil, a la descarga de nuevas aplicaciones sobre 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. También están relacionados con distintos riesgos asociados al material o a los programas utilizados que el operador y/o el proveedor de aplicaciones y/o el usuario del equipo móvil desean tener en cuenta. El método según la invención se ejecuta en general en cada conexión del equipo móvil a la red o después de cada actualización de la versión de software del equipo móvil o de la del módulo de abonado o también de la de recursos sobre el módulo de abonado. También se puede ejecutar la activación durante cada activación o desactivación de una aplicación sobre el equipo móvil . Según una variante, esta puede ser ejecutada periódicamente a un ritmo establecido por el servidor de control o después de cada puesta en funcionamiento de una aplicación sobre el equipo móvil. Según otra variante, el módulo de abonado no va a recibir un nuevo mensaje del centro de control mientras que el identificador IMEISV del equipo móvil permanece igual . Durante la reinicialización del módulo de abonado, es preferible bloquear cierto número de recursos hasta la llegada del criptograma. De este modo, si el equipo móvil quiere interceptar el criptograma y no transmitirlo al módulo abonado, todos o parte de los recursos (datos o funciones) del módulo de abonado no serán disponibles para las aplicaciones ejecutadas en el equipo móvil. Según el tipo de realización, ciertos recursos del módulo de abonado utilizados por unas aplicaciones de bajo nivel de seguridad, pueden ser puestas en funcionamiento por omisión antes de la llegada del criptograma. Este es el caso también de unos recursos necesarios para la obtención del acceso a la red, sin lo cual no se podría conseguir el envió del criptograma por esa misma red. Cuando el módulo de abonado verifica la validez del criptograma, este identifica también de forma indirecta el equipo móvil y se asegura de que los datos provengan efectivamente del servidor de control. Dicho de otra manera, por medio de este criptograma, el servidor de control asegura implícitamente al módulo de abonado que el tipo y la versión de software del equipo móvil han sido tomados en cuenta antes de transmitir las instrucciones al módulo abonado. Estas últimas se encargan de esta manera, si llega el caso, de dar o negar la autorización de utilización completa o parcial de ciertas aplicaciones del equipo móvil. El equipo móvil tiene una función de relevo en esta etapa de verificación, estableciendo un dialogo casi directo entre el módulo de abonado y el servidor de control . De este modo la seguridad de los mensajes intercambiados es asegurada de principio a fin entre el servidor de control y el módulo de abonado por el entorno de ejecución de las aplicaciones puestas en práctica sobre el equipo móvil . Por lo que dicho equipo no puede "hacer trampas" o transformar los datos con respecto al módulo de abonado. La presente invención se refiere también a un módulo de seguridad que comprende unos recursos destinados a ser accedidos localmente mediante al menos una aplicación instalada en un equipo conectado a una red, el equipo que comprende los medios de lectura y de transmisión de datos, comprendiendo al menos el tipo y la versión de software del equipo y el identificador del módulo de seguridad, y dicho módulo estáa caracterizado por el hecho de que comprende unos medios de recepción, de análisis y de ejecución de instrucciones contenidas en un criptograma, y las instrucciones condicionan el funcionamiento de la aplicación según unos criterios preestablecidos por el proveedor de dicha aplicación y/o el operador y/o el usuario del equipo. Este módulo de seguridad es utilizado por ejemplo como módulo de abonado o tarjeta SIM conectado a un equipo móvil . La invención será mejor entendida 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 1 ilustra un diagrama de bloques que muestra las distintas partes del equipo móvil y del servidor, empleadas durante el intercambio de los datos de identificación y del criptograma. - la figura 2 representa un diagrama de bloques del conjunto equipo móvil/módulo abonado, con las interacciones entre los distintas partes durante el funcionamiento de una aplicación. La figura 1 muestra el conjunto de equipo móvil (CB) y módulo de abonado (SIM) que transmite a través de una red móvil (NET) unos datos de identificación (ID) que el servidor de control (CSE) verifica. Este último reenvía un criptograma (J) hacia el módulo de abonado a través del equipo móvil (CB) . El equipo móvil (CB) incluye una o varias aplicaciones de software (APP) que funcionan en un entorno de ejecución (AEE) . Estas aplicaciones provienen ya sea de un proveedor de aplicaciones (FA) asociado al servidor de control (CSE) del operador, o bien son programadas de origen por el fabricante del equipo móvil . El módulo de abonado incluye unos recursos (RES) utilizados por las aplicaciones de software (APP) . La figura 2 muestra que el funcionamiento de las aplicaciones (APP) del equipo móvil (CB) depende directamente de los recursos (RES) disponibles en el módulo de abonado. En ausencia de recursos adecuados, la aplicación puede, o no empezar, o bien funcionar de forma muy limitada con unos parámetros por omisión que pueden generar mensajes de error que inducen al usuario a realizar acciones correctivas necesarias como por ejemplo cambiar de equipo móvil (CB) o de módulo de abonado (SIM) . El equipo móvil (CB) se identifica, por ejemplo en cada solicitud de conexión a la red, al servidor de control (CSE) a través de la red móvil (NET) transmitiendo preferiblemente informaciones específicas a un equipo móvil: IMEISV (International Mobile Equipment Identity and Software Versión Number) y un código propio a un módulo de abonado: IMSI (Internacional Mobile Subscriber Identity) . El primer número IMEISV es una serie de 16 cifras que contiene principalmente un código de homologación del fabricante del equipo móvil, un número de serie que identifica físicamente el equipo móvil de manera única y la versión de software instalada sobre el equipo móvil .en cuestión. El segundo número IMSI es una serie de 15 cifras e incluye un código atribuido por el operador con el que un usuario ha suscrito un abono que permite identificar a un abonado de manera única. Para los equipos móviles realizados según las normas anteriores establecidas por ETSI (European Telecommúnications Standards Institute) , la combination del número IMEI compuesto por una serie de 15 cifras y del número SVN compuesto por una serie de 2 cifras proporciona también las informaciones necesarias para la realización del método. Durante la identificación de un equipo móvil, el servidor de control (CSE) analiza y verifica los datos (ID) transmitidos, comparándolos con el contenido de una lista negra (datos que rechazar) o de una lista blanca (datos aceptados) . Un banco de datos permite afinar, si se necesita, la identificación de un abonado y determinar sus particularidades tales como servicios autorizados, pagos del abono y/o servicios efectuados o no, período de abono, perfil de seguridad asociado al equipo móvil utilizado, aplicaciones instaladas sobre el equipo móvil, recursos disponibles sobre el módulo de seguridad, preferencias del usuario del equipo móvil, etc. Los resultados de esta verificación son posteriormente utilizados con el fin de determinar un criptograma, llamado ficha (J) , que el servidor de control (CSE) transmite al equipo móvil (CB) . Se debe señalar que el servidor de control (CSE) puede ser distinto del operador móvil y la solicitud que proviene de un equipo móvil será enviada hacia esa autoridad de control . El entorno de ejecución de aplicaciones (AEE) del equipo móvil (CB) transmite la ficha (J) tal cual, sin alterarla, al módulo de abonado, el equipo móvil (CB) solo tiene una función de relevo. Si la ficha (J) es válida, el módulo de abonado puede liberar, respectivamente bloquear ciertos recursos (RES) . La o las aplicaciones (APR) pueden ejecutarse de este modo según los criterios impuestos por el servidor de control (CSE) . Efectivamente, la ficha (J) incluye o es acompañada por unas instrucciones particulares con destino hacia el módulo de abonado que pueden condicionar el funcionamiento de una u otra de las aplicaciones (APR) del equipo móvil (CB) . Por ejemplo la ejecución de transacciones financieras puede ser limitada cuando el abonado esta conectado a otra red que la red a la que está abonado, por ejemplo en un país diferente a su domicilio (roaming) debido a ciertos criterios de seguridad o de preferencias del abonado o de preferencias del proveedor del servicio financiero o de restricciones legales vigentes en el país en cuestión. En otro caso, cuando un módulo de abonado es insertado en un equipo móvil (CB) no reconocido o no homologado por el operador, la ficha (J) devuelta por el servidor de control (CSE) puede bloquear unos recursos (RES) del módulo de abonado y, de esta manera impedir o alterar, la -ejecución de la o de las aplicaciones (APP) . En el caso de una posible clonación del equipo móvil (CB) y/o del módulo de abonado (SIM) , los resultados de la verificación con el banco de datos incluirán unas instrucciones que dependen de los riesgos que el operador acepta tomar con los teléfonos móviles clonados . Por ejemplo, la ficha (J) generada en consecuencia puede o bien bloquear todos los recursos (RES) del módulo de abonado, o bien limitar su utilización en el tiempo y/o crear un mensaje de advertencia para el abonado a través del ambiente de ejecución de las aplicaciones (AEE) . La ficha (J) puede por ejemplo estar asociada a una firma generada por medio de una clave privada RSA, (Rivest, Shamir, Adelman) KRSA_Pri a partir de un conjunto de datos que comprenden, por ejemplo, el IMSI, el IMEISV, las referencias de los recursos del módulo de abonado, un contador. Solo el servidor de control conocería esta clave, mientras que el módulo de abonado conocería su parte pública KRSA_pub. La ventaja de utilizar claves asimétricas reside en el hecho de que la clave que sirve para crear firmas no se encuentra al exterior del servidor de control (CSE) . Por supuesto, otros algoritmos de claves asimétricas tales como por ejemplo DSA (Digital Signature Algorithm) , y ECC (Elliptic Curve Cryptography) pueden constituir alternativas a RSA. Se puede preferir el uso de algoritmo de claves simétricas por razones de sencillez, de rapidez de las verificaciones o de costos de fabricación y de puesta en práctica más reducidos. En ese caso, el servidor (CSE) y el módulo de abonado conocerían la clave, por ejemplo un algoritmo IDEA (Algoritmo Internacional de Codificación de Datos) (International Data Encryption Algorithm) podría ser utilizado para firmar el conjunto (IMSI, IMEISV, referencias de los recursos del módulo de abonado, contador) . Como alternativa al algoritmo IDEA, unos algoritmos tales co o, por ejemplo, TDES (Estándar de Codificación Triple de Datos) (Triple Data Encryption Standard) y AES (Estándar de Codificación Avanzada) (Advanced Encryption Standard) pueden ser utilizados también. En estas dos variantes de claves asimétricas y simétricas, el módulo de abonado verifica la concordancia de los distintos campos que aparecen en la ficha (J) , en particular controla el contador (CRT) comparándolo con un contador correspondiente memorizado en la tarjeta mantenida al día regularmente. Este contador permite evitar el uso doble de una misma ficha (J) dirigida al módulo de abonado con el fin de impedir un ataque de repetición (replay attack) .

Una variante del contador consiste en utilizar un imprevisto aleatorio (número aleatorio) generado por el módulo de abonado. Este imprevisto aleatorio es transmitido con los datos enviados al servidor de control . Este último reenvía este imprevisto aleatorio en el criptograma de respuesta y el módulo de abonado puede verificar si se trata efectivamente de un nuevo mensaje. Mas habitualmente, con el fin de evitar todo riesgo de uso de un antiguo criptograma, este último comprende una variable predecible por el módulo de abonado, sea un contador o un imprevisto aleatorio. El módulo de abonado considera también las referencias de_los recursos (RES) para los que autoriza o no la utilización mediante las aplicaciones ejecutadas en el equipo móvil (CB) . El módulo de abonado no conoce tal como son las referencias de aplicaciones (APR) instaladas en el equipo móvil (CB) . Efectivamente, ciertas aplicaciones más globales poseen una interfaz relativamente abierta que les permite ser utilizadas por cualesquiera aplicaciones secundarias externas. Por ejemplo, sobre una aplicación general de pago se pueden añadir aplicaciones particulares en función del modo de pago utilizado. El módulo de abonado no puede basarse únicamente en las referencias de sus propios recursos (RES) (datos o funciones) . Al aceptar los riesgos relacionados con un equipo móvil, el operador realiza una elección sabiendo cuáles son los recursos (RES) del módulo de abonado utilizados por tal (es) aplicación (es) (APR) ejecutadas en el equipo móvil (CB) . En otra variante la firma realizada con la ayuda de una clave del tipo RSA o IDEA puede ser reemplazada por un bloque generado con una clave compartida HMAC (Keyed-Hashing for Mensaje Authentication) a partir del conjunto (IMSI, IMEISV, referencias de recursos del módulo de abonado, contador) . HMAC es un mecanismo para la autentificación de mensajes mediante 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 es decir que la misma clave se encuentra en el servidor de control (CSE) y en el módulo de abonado. Esta clave presente a la vez en el servidor de control (CSE) y en el módulo de abonado puede ser cargada durante la personalización del módulo de abonado o durante la instalación de ciertos recursos en el módulo de abonado. Según las opciones, cada recurso o grupo de recursos del módulo de abonado puede estar asociado a una clave diferente, o la clave puede ser global para el conjunto de recursos y único para un módulo de abonado proporcionado. Para mas seguridad, cuando el módulo de abonado ha recibido una ficha (J) , este puede retransmitir al servidor de control (CSE) , a través del equipo móvil (CB) y la red móvil (NET) , un mensaje de confirmación (CF) demostrando la buena recepción y el tratamiento adecuado de la ficha (J) por el módulo de abonado. La confirmación (CF) incluye al menos un código de éxito o de error de la operación así como un contador, similar al de la ficha (J) , que sirve para la protección contra los ataques repetidos. Este mensaje permite también al servidor de control (CSE) actualizar el contador asociado al módulo de abonado. En una variante de la invención, el equipo móvil puede ser reemplazado por un equipo no móvil tal como un descodificador de televisión de pago o un ordenador. El __servidor__.de.. control. __recibe_ por__ parte _de - un módulo de seguridad, el equivalente del módulo de abonado, el identificador del equipo conectado a la red y el identificador del módulo de seguridad. En respuesta, el servidor efectúa las verificaciones tales como se han descrito anteriormente y reenvía un criptograma al módulo de seguridad. Esta respuesta va a liberar o bloquear 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 (19)

REIVINDICACIONES

1. Un método de gestión de la seguridad de aplicaciones (APP) que funciona en un equipo (CB) conectado a una red (NET) , la red (NET) es administrada por un servidor de control (CSE) de un operador, las aplicaciones utilizan unos recursos (RES) (datos o funciones) almacenados en un módulo de seguridad (tarjeta SIM) conectado localmente al equipo (CB) , que incluye las siguientes etapas preliminares: - recepción de datos que comprenden al menos el tipo y la versión del software del equipo (CB) y la identidad- del módulo de seguridad (SIM) , a través de la red, por el servidor de control, análisis y verificación por el servidor de control (CSE) de dichos datos (ID) , generación de un criptograma (J) a partir del resultado de la verificación sobre los datos (ID) , y la transmisión del criptograma (J) , a través de la red (NET) y del equipo (CB) , al módulo de seguridad (SIM) , el método está caracterizado porque el módulo de seguridad (SIM) analiza el criptograma (J) recibido y activa, respectivamente desactiva unos recursos (RES) (datos o funciones) utilizados por al menos una aplicación (APP) instalada en el equipo (CB) , el criptograma (J) comprende unas instrucciones que condicionan el funcionamiento de la aplicación (APP) según unos criterios establecidos por el proveedor de la aplicación y/o el operador y/o el usuario del equipo .

2. El método de conformidad con la reivindicación" 1, caracterizado porque el equipo (CB) es un equipo móvil de telefonía móvil.

3. El método de conformidad con la reivindicación 1, caracterizado porque la red es una red móvil del tipo GSM, GPRS o UMTS.

4. El método de conxo m±dad— con las reivindicaciones 1 y 2-, caracterizado porque el módulo de seguridad (SIM) es un módulo de abonado insertado en el equipo móvil de telefonía móvil de tipo tarjeta SIM.

5. El método de conformidad con las reivindicaciones 1 a 4, caracterizado porque la identificación del conjunto equipo móvil/módulo de abonado (SIM) es efectuada a partir del identificador (IMEISV) del equipo móvil (CB) y del número de identificación del módulo de abonado (IMSI) propio a un abonado a la red móvil.

6. El método de conformidad con la reivindicación 1 a 5, caracterizado porque los criterios definen los limites de utilización de una aplicación (APP) según unos riesgos asociados a dicha aplicación (APP) y al tipo y a la versión de software del equipo móvil que el operador y/o el proveedor de aplicaciones y/o el usuario del equipo móvil desean tener en cuenta.

7. El método de conformidad con las reivindicaciones 1 a 6, caracterizado porque este es ejecutado después de cada conexión del equipo móvil a la red.

8. El método de conformidad con las reivindicaciones 1 a 6, caracterizado porque este es ejecutado después de cada actualización de la versión de software del equipo móvil .

9. El método de conformidad con las reivindicaciones 1 a 6, caracterizado porque este es ejecutado después, de cada activación o desactivación de una aplicación sobre el equipo móvil.

10. El método de conformidad con las reivindicaciones 1 a 6, caracterizado porque este es ejecutado después de cada actualización de la versión de software del módulo de abonado.

11. El método de conformidad con las reivindicaciones 1 a 6, caracterizado porque este es ejecutado después de cada actualización de recursos sobre el módulo de abonado.

12. El método de conformidad con las reivindicaciones 1 a 6, caracterizado porque este es ejecutado periódicamente a un ritmo establecido por el servidor de control .

13. El método de conformidad con las reivindicaciones 1 a 6, caracterizado porque este es ejecutado después de cada puesta en funcionamiento de aplicación en el equipo móvil . 1 . El método de conformidad con cualquiera de las reivindicaciones precedentes, caracterizado porque el módulo de abonado (SIM) , anteriormente para la ejecución de las instrucciones proporcionadas por el criptograma (J) , compara el identificador (IMEISV) del equipo móvil (CB) con el que ha recibido previamente e inicia la operación de verificación solamente si el identificador (IMEISV) ha cambiado. — — --15-. El método de conformidad con las reivindicaciones 1 a 5, caracterizado porque el servidor de control (CSE) , antes de la transmisión del criptograma (J) , compara el identificador (IMEISV) del equipo móvil con el que ha recibido previamente e inicia la operación de verificación sólo si el identificador (IMEISV) ha cambiado. 16. El método de conformidad con las reivindicaciones 1 a 15, caracterizado porque el criptograma (J) esta constituido por un mensaje codificado por el servidor de control (CSE) con la ayuda de una clave de encriptación asimétrica o simétrica a partir de un conjunto de datos comprendiendo, entre otros datos, el identificador (IMEISV) del equipo móvil (CB) , el número de identificación del módulo de abonado (IMSI) , unas referencias de recursos (RES) del módulo de abonado (SIM) y una variable predecible (CRT) . 17. El método de conformidad con las reivindicaciones 1 a 16 caracterizadb porque el módulo de abonado transmite al servidor de control (CSE) , a través del equipo móvil (CB) y la red móvil (NET) , un mensaje de confirmación (CF) cuando el módulo de abonado (SIM) ha recibido el criptograma (J) , el mensaje atestigua la buena recepción y el tratamiento adecuado del criptograma (J) por el módulo de abonado (SIM) . 18 El método de conformidad con la reivindicación 1, caracterizado porque_ el equipo es un descodificador dce televisión de pago o un ordenador al cual está conectado el módulo de seguridad. 19. Un módulo de seguridad que comprende recursos (RES) destinados a ser localmente accedidos por al menos una aplicación (APP) instalada en un equipo (CB) conectado ala red (NET) , el equipo comprende medios de lectura y de transmisión de datos, que comprende al menos el identificador (IMEISV) del equipo y el identificador (IMSI) del módulo de seguridad, el módulo está caracterizado porque comprende los medios de recepción de análisis y ejecución' de instrucciones contenidos en un criptograma (J) , las instrucciones condicionan el funcionamiento de la aplicación (APP) según los criterios preestablecidos por el proveedor de la aplicación (APP) y/o el usuario del equipo (CB) . 20. El módulo de seguridad de conformidad con la reivindicación 19, caracterizado porque constituye un módulo de abonado del tipo "tarjeta SIM" 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 del equipo conjunto, módulo de seguridad, aplicaciones con el fin de limitar los riesgos relacionados con el hecho de que un módulo de seguridad sea utilizado con malas intenciones mediante unas aplicaciones ejecutadas sobre un equipo de tipo y/o de versión de software que no cumplen completamente con los criterios de seguridad establecidos . Este objetivo es alcanzado p'or un método de gestión de la _seguridad_de_ _aplicaciones (APP) _ que funciona en un equipo (CB) conectado a una red (NET) , dicha red (NET) es administrada por un servidor de control (CSE) de un operador, dichas aplicaciones utilizan unos recursos (RES) (datos o funciones) almacenados en un módulo de seguridad (SIM) conectado localmente a dicho equipo (CB) , que incluye las etapas preliminares siguientes: recepción de datos que comprenden al menos el tipo y la versión de programa del equipo (CB) y la identidad del módulo de seguridad (SIM) , a través de la red, por el servidor de control, análisis y verificación por el servidor de control (CSE) de dichos datos (ID) , generación de un criptograma (J) a partir del resultado de la verificación sobre dichos datos (ID) , y transmisión del criptograma (J) , a través de la red (NET) y del equipo (CB) , al módulo de seguridad (SIM) , el método está caracterizado por el hecho de que el módulo de seguridad (SIM) analiza el criptograma (J) recibido y activa, respectivamente desactiva unos recursos . (RES) (datos o funciones) utilizados por al menos una aplicación (APP) instalada en el equipo (CB) , dicho criptograma (J) comprendiendo unas instrucciones que condicionan el funcionamiento de la aplicación (APP) según unos criterios establecidos por el proveedor de la aplicación y/o el operador y/o el usuario del equipo.