ES2207408B1 - Gestor de seguridad para una tarjeta inteligente, tarjeta inteligente, telefono movil y metodo de gestion de seguridad en una tarjeta inteligente. - Google Patents

Abstract

Gestor de seguridad para una tarjeta inteligente, tarjeta inteligente, teléfono móvil y método de gestión de seguridad en una tarjeta inteligente. La invención se refiere a un gestor de seguridad para una tarjeta inteligente, que comprende: - medios para recibir, desde una aplicación residente (A1, A2, A3; AT1, AT2, AT3, AT4) en una tarjeta inteligente, una solicitud de un servicio de seguridad; - medios para comprobar de qué aplicación residente proviene dicha solicitud; - medios para comprobar si dicha aplicación residente está autorizada a acceder al servicio de seguridad; - medios para facilitar dicho servicio de seguridad a la aplicación residente a partir de un módulo de identidad inalámbrico (WIM) (2) de la tarjeta, siempre que dicha aplicación residente esté autorizada a acceder al servicio de seguridad y siempre que la tarjeta inteligente esté dotada de un módulo de identidad inalámbrico (WIM). La invención también se refiere a una tarjeta inteligente, a un teléfono móvil y a un método de gestión de seguridad en una tarjeta inteligente.

Description

Gestor de seguridad para una tarjeta inteligente, tarjeta inteligente, teléfono móvil y método de gestión de seguridad en una tarjeta inteligente.

Campo de la invención

La invención se engloba en el campo de las tarjetas inteligentes, por ejemplo, el de las tarjetas inteligentes usadas en el campo de la telefonía móvil. La invención se refiere especialmente al acceso de datos y funciones sensibles, que afectan a la seguridad, en las tarjetas inteligentes.

Como es sabido, en este campo tecnológico, normalmente se utilizan acrónimos y términos anglosajones para referirse a elementos y conceptos propios del campo. Los acrónimos y términos anglosajones usados en este texto se explicarán a lo largo del texto.

Antecedentes de la invención Conceptos tecnológicos

Una tarjeta inteligente ("smart card") comprende un dispositivo electrónico similar a un PC en cuanto a su arquitectura, pero insertado en una tarjeta de plástico. Las tarjetas inteligentes se basan en un circuito integrado que lleva embebidos los siguientes elementos:

- CPU: Unidad Central de Procesamiento ("Central Processing Unit"). Puede llevar además un criptoprocesador.

- Memoria Volátil: es la unidad de memoria utilizada para el almacenamiento temporal de datos. Suele tratarse de una memoria RAM.

- Memoria No-Volátil: esta memoria almacena datos de forma fija. Es utilizada para el almacenamiento de directorios, ficheros y aplicaciones o programas tal y como ocurre con el disco duro de un PC convencional. Se suele hablar de dos tipos de memoria dentro de este grupo: 1) Memoria ROM: es imborrable y en ella suelen cargarse algunas aplicaciones necesarias para el arranque de la tarjeta; 2) Memoria EEPROM: puede escribirse y borrarse, si bien tiene un tiempo de vida que depende del número de escrituras que se hagan en ella. En esta memoria se suelen almacenar los directorios, ficheros y algunas aplicaciones.

- Unidad de entrada/salida: elemento a través del cual la tarjeta puede comunicarse con un dispositivo externo, por ejemplo, con un terminal móvil, un lector de tarjetas, etc.

La comunicación de la tarjeta inteligente con los diferentes dispositivos externos está basada en comandos de 5 bytes en los que se indica la acción a realizar. En algunas ocasiones el comando va acompañado de datos necesarios para la ejecución de la acción, por ejemplo, la actualización de un fichero en la tarjeta. En otras, es la tarjeta la que debe devolver datos al dispositivo que solicitó la acción, por ejemplo, cuando se trata de la lectura de un fichero.

Tal y como ocurre en un PC, en una tarjeta inteligente es posible instalar varias aplicaciones de cualquier índole, por ejemplo:

- aplicaciones de monedero electrónico;

- aplicaciones de gestión de datos de usuario;

- aplicaciones de seguridad.

Toda la información relativa al funcionamiento y arquitectura de las tarjetas inteligentes se encuentra recogida en los estándares ISO 7816 (de la parte 1 a la parte 9).

Actualmente, los teléfonos móviles suelen incluir una tarjeta inteligente que comprende elementos esenciales para la operación del teléfono. Se puede hablar de un "equipo de usuario" que comprende, tanto en el sistema GSM ("Global System for Mobile Communication") como en el sistema UMTS ("Universal Mobile Telecommunications System" - también llamado "Tercera Generación de Telefonía Móvil"):

- por una parte, un terminal (que es el que muchas veces se denomina "teléfono móvil" y que incluye una carcasa, pantalla, teclado, fuente de alimentación y circuitos diversos); y

- por otra parte, la tarjeta inteligente; se considera que una tarjeta inteligente es un dispositivo físicamente seguro, es decir, es un dispositivo en el que los datos almacenados se encuentran protegidos frente a ataques de terceros que pretendan leerlos, modificarlos, borrarlos o falsearlos sin permiso del propietario de la información. La tarjeta inteligente utilizada deberá tener instalada bien una aplicación SIM si se trata de GSM o bien una aplicación U/SIM si se trata de UMTS.

La invención está relacionada con las siguientes aplicaciones:

Aplicación SIM ("Subscriber Identity Module" - "Módulo de Identificación de Usuario"). Este módulo o aplicación autentica al abonado de la red GSM ante la red y almacena información personal del usuario.

Aplicación USIM ("Universal Subscriber Identity Module" - el Módulo de Identificación de Usuario en el UMTS). Realiza las mismas funciones que la aplicación SIM pero para la red UMTS.

Aplicación WIM ("Wireless Identity Module" - "Módulo de Identidad Inalámbrico"). Esta aplicación o módulo realiza funciones de seguridad, almacena y procesa información de usuario necesaria para la identificación y autenticación del usuario y de los servidores a los que se conecta. Se utiliza principalmente en el entorno WAP (WAP: "Wireless Application Protocol" - arquitectura de protocolos que permite a los usuarios acceder a información almacenada en servidores de forma instantánea y desde su teléfono o dispositivo móvil) aunque podría también utilizarse en otros entornos no-WAP. Cuando desde un terminal se conecta a un servidor usando WAP, se recibe del servidor ficheros escritos en un lenguaje especial llamado WML, similar al HTML que se utiliza en Internet. Estos ficheros son interpretados por el cliente WAP. Es posible incluir en estos ficheros órdenes dirigidas al terminal además de texto para el usuario. Entre estas órdenes figuran aquellas que le solicitan la realización de servicios de seguridad (funciones de seguridad como operaciones criptográficas, obtención de datos relacionados con la seguridad como claves y certificados...). Cuando el terminal recibe este tipo de órdenes, prepara los datos necesarios y accede al módulo WIM para realizar las funciones criptográficas o para obtener la información sensible que se solicita. Una vez obtenido el resultado del módulo WIM, el terminal lo devuelve al servidor utilizando el protocolo WAP.

Pasamos a comentar con más detalle las aplicaciones SIM, USIM y WIM mencionadas en lo anterior:

Aplicación U/SIM

Se trata del Módulo de Identificación de Usuario de la red GSM/DCS 1800 (SIM) o UMTS (USIM). Entre sus funciones más importantes se encuentran las siguientes:

- Almacena la clave del usuario necesaria para su identificación en red.

- Lleva a cabo los algoritmos para la autentificación del usuario en la red correspondiente.

- Calcula las claves para cifrar la comunicación.

- Gestiona los PINs y sus claves de desbloqueo.

- Almacena y gestiona información del operador.

- Almacena y gestiona información del usuario: agenda, mensajes cortos, etc.

Toda la información sobre la aplicación SIM se encuentra recogida en el estándar GSM 11.11. La información relativa a la aplicación USIM se encuentra recogida en los estándares: 3GPP 31.101 y 3GPP 31.102.

Aplicaciones U/SIM Toolkit ("U/SIM Application Toolkit") es una funcionalidad soportada sobre una aplicación U/SIM. En un primer momento los terminales móviles sólo eran capaces de enviar comandos a las tarjetas, mientras que las tarjetas sólo eran capaces de responder a comandos recibidos desde el terminal móvil. Posteriormente se produjo una evolución en los terminales móviles y en las tarjetas que permitía a ambos tanto el envío de comandos como su recepción. De este modo se logró que una aplicación U/SIM fuese capaz de solicitar a un terminal móvil el envío de un mensaje corto, la realización de una llamada, etc. Esta funcionalidad permite, por tanto, desarrollar aplicaciones que residan en la tarjeta (es decir, que han sido cargadas en la tarjeta, de forma remota o localmente) y que manejen los periféricos del teléfono móvil (display, teclado, envío de mensajes cortos, realización de llamadas, etc.) abriendo las puertas a nuevas aplicaciones que aporten valor añadido al equipo móvil.

Estas aplicaciones existentes en la tarjeta y capaces de enviar comandos al terminal móvil se conocen con el nombre de "Aplicaciones SIM Toolkit" cuando se soportan sobre SIM y "Aplicaciones USIM Toolkit" cuando se soportan sobre USIM.

Las Aplicaciones U/SIM Toolkit son una característica opcional tanto de las aplicaciones SIM como USIM. Los procedimientos de alto nivel, contenidos y codificación de los comandos, están convenientemente especificados en la norma GSM 11.14 para aplicación SIM ó 3GPP TS 31.111 para aplicación USIM.

Aplicación WIM

Para comprender el funcionamiento de la aplicación WIM hay que tener en cuenta el concepto "canal de comunicaciones seguro". Decimos que un canal de comunicaciones es seguro cuando cumple los siguientes cuatro requisitos:

- Confidencialidad

- Integridad

- Autenticidad

- No repudio

Confidencialidad: decimos que existe confidencialidad cuando un tercero no puede enterarse del contenido de las transacciones entre dos entidades. Conseguimos confidencialidad cifrando los datos, para lo cual se utilizan tanto algoritmos simétricos como asimétricos.

Integridad: Decimos que existe integridad cuando un tercero no puede modificar el contenido de las transacciones entre dos entidades. Conseguimos integridad calculando el valor hash de los datos. Un valor hash es el resultado de aplicar sobre los datos una operación matemática que le dota de las siguientes particularidades: 1) no pueden deducirse los datos a partir del valor del hash; y 2) datos distintos (por pequeña que sea la modificación) originan hash distintos. Para averiguar si unos datos han sido modificados en el viaje a través del canal, deben ir acompañados de su valor hash. En el receptor se calcula de nuevo el valor hash de los datos recibidos, si ambos coinciden, los datos no fueron modificados.

Autenticidad: Decimos que existe autenticidad cuando el emisor y el receptor (las entidades que participan en la comunicación) demuestran que son quienes dicen ser. Para garantizar esta autenticidad, se utiliza la criptografía asimétrica. Cada usuario dispone de dos claves:

- la clave privada, conocida sólo por el poseedor de la misma

- la clave pública, que el usuario intercambia con otros usuarios para poder descifrar los datos cifrados con la clave privada.

Con el fin de garantizar el origen de los datos, uno de los procedimientos más utilizados consiste en calcular el valor hash de los datos y cifrarlo con la clave privada del emisor. El emisor enviará los datos del mensaje, el valor del hash cifrado (conocido con el nombre de "firma digital") y su clave pública. De este modo el receptor podrá descifrar el valor hash y recalcularlo a partir de los datos garantizando al mismo tiempo que el mensaje no fue modificado y que el emisor del mismo está en posesión de la clave privada cuya clave pública ha utilizado al descifrar.

Sin embargo, esto no suele ser suficiente, es necesario conocer que el poseedor de este par de claves es la entidad con la que realmente queremos comunicar.

Para ello se utilizan los certificados digitales. Un certificado recoge un conjunto de datos identificativos de una entidad (física o jurídica) junto a la clave pública de la misma. La particularidad de los certificados reside en el hecho de que son firmados digitalmente por entidades de confianza que reciben el nombre de Autoridades de Certificación (en adelante CA) y que validan que los datos recogidos en el certificado sean correctos.

No repudio: Decimos que un canal garantiza no-repudio cuando una entidad que realiza una transacción a través del mismo no puede desdecirse ante terceras personas (por ejemplo, un juez). Técnicamente se realiza utilizando la misma tecnología que para garantizar la autenticidad con la salvedad del tipo de datos recogidos en el certificado. Por ejemplo, el DNI/NIF de la entidad que realizó la transacción recogido en el certificado que adjuntó a la misma le vincula directamente como ejecutor de la misma.

En el entorno WAP, es necesaria esta seguridad dado que permite el desarrollo de servicios importantes, tales como las aplicaciones bancarias. Para la consecución de la misma se utiliza la aplicación WIM (Wireless Identity Module).

La aplicación WIM es un módulo de seguridad que almacena pares de claves (basadas en algoritmos de criptografía asimétrica) y que realiza con ellas funciones relacionadas con la seguridad del usuario como son cálculo de firma digital, verificación de firma, descifrado de claves de sesión, etc. Almacena además certificados de usuario y de CAs de confianza. Se considera además un dispositivo físicamente seguro porque dispone de mecanismos de protección hardware que impiden la modificación o extracción de información del mismo.

Cuando una tarjeta inteligente contiene la aplicación SIM o USIM y la aplicación WIM, recibe el nombre de tarjeta SWIM o USWIM.

Una aplicación WIM puede utilizarse también en un entorno no-WAP, con las mismas funcionalidades.

Los procedimientos de alto nivel, contenidos y codificación de los comandos, están convenientemente especificados en las normas WAP-160-19991105 para WAP 1.2 y WAP-198-20000218 para WAP 1.2.1.

Estado de la técnica

Las tarjetas inteligentes denominadas U/SWIM (Universal/Subscriber Wireless Identity Module) disponen de, al menos, 2 aplicaciones cargadas en su interior:

- una aplicación U/SIM para autenticación del usuario en la red GSM/UMTS y almacenamiento de datos del usuario relacionados con la red; y

- una aplicación WIM, módulo de seguridad que almacena pares de claves (basadas en algoritmos de criptografía asimétrica) y realiza con ellas funciones relacionadas con la seguridad del usuario como son cálculo de firma digital, verificación de firma, descifrado de claves de sesión, etc. Este módulo almacena además certificados de usuario y de CAs de confianza. Se puede decir que este módulo almacena y gestiona la seguridad del usuario en cuanto a su identidad personal y protección.

Mientras que el módulo WIM es sólo accesible a través del protocolo WAP cuando convive con la aplicación U/SIM, sobre dicha aplicación U/SIM es posible la carga de las aplicaciones de usuario de propósito general denominadas "Aplicaciones U/SIM Toolkit" accesibles a través de diferentes canales, por ejemplo, mediante mensajes cortos y mediante la propia interacción entre el terminal y el usuario. Estas aplicaciones pueden ejecutar funciones de seguridad tanto simétricas como asimétricas, pero en cualquier caso independientes de las implementadas por el módulo WIM.

Esta falta de interconexión plantea un problema al usuario y a los diseñadores de aplicaciones. Por ejemplo, si un cliente desea acceder a servicios de consulta de su banco a través de un servicio basado en mensajes cortos y a través de otro servicio basado en WAP, estará obligado a gestionar informaciones diferentes en cuanto al acceso seguro a dicho servicio. Sus claves privadas y certificados, los cuales le ayudan a identificarse, serán siempre diferentes, y los certificados de las CAs de confianza podrán ser los mismos pero en ningún caso compartir espacio de almacenamiento, esto es, la información deberá encontrarse duplicada en la tarjeta U/SWIM.

En la figura 1 se ha representado una posible arquitectura funcional de una tarjeta inteligente SWIM ó USWIM de acuerdo con el estado de la técnica. Sobre el soporte físico (ICC: tarjeta chip o "Integrated Circuit Card", llamado UICC cuando se trata del sistema UMTS) 1 conviven un módulo WIM 2, un módulo U/SIM 3, una máquina virtual 4, librerías genéricas 5 (que incluyen una librería criptográfica 6), una librería U/SIM Toolkit 7, aplicaciones genéricas (A1, A2) y aplicaciones U/SIM Toolkit (AT1, AT2, AT3). (En programación, una librería es un conjunto de funciones que una aplicación puede usar; se agrupan en estas librerías las funciones más utilizadas).

Como se puede observar en la figura 1, la tarjeta presenta una arquitectura multi-aplicación en la que conviven diferentes tipos de aplicaciones. Las aplicaciones U/SIM Toolkit (AT1, AT2, AT3) suelen ser codificadas y cargadas en la tarjeta por entidades diferentes del fabricante de la tarjeta. Esto hace que suelan ser implementadas en "lenguaje interpretado" (un lenguaje de programación que no necesita ser compilado para ser ejecutado; debe ser ejecutado por un software especial llamado "máquina virtual") y, por tanto, necesiten de la máquina virtual para su ejecución (con el término "máquina virtual" nos referimos a un software que se comporta como una computadora independiente con su propio sistema operativo; ejecuta programas escritos en el lenguaje interpretado que puede comprender). Aprovechando la existencia de la máquina virtual 4 en la tarjeta, pueden ejecutarse también sobre ella aplicaciones de propósito general o genéricas (A1, A2) escritas en "lenguaje interpretado". Existen diferentes máquinas virtuales para la implementación de estas aplicaciones, por ejemplo, la máquina virtual Java Card. Los diferentes tipos de aplicaciones que, por tanto, suelen encontrarse sobre una tarjeta U/SWIM son:

- Aplicaciones Genéricas (A1, A2): Aplicaciones de propósito general escritas normalmente en lenguaje interpretado que se apoyan en librerías de funciones genéricas (5) para realizar las funciones necesarias sobre la tarjeta. Podría tratarse, por ejemplo, de una aplicación de monedero electrónico.

- Aplicaciones (U/SIM) Toolkit (AT1, AT2, AT3): Aplicaciones escritas normalmente en lenguaje interpretado que utilizan el estándar U/SIM Application Toolkit para la implementación de servicios de valor añadido para el usuario. Suele tratarse de aplicaciones diseñadas por el Operador de Telefonía Móvil para proveer de una interfaz más amigable a sus servicios corporativos: servicios de información de noticias, bolsa, tráfico, etc. Estas aplicaciones suelen apoyarse sobre las librerías genéricas (5) (para la realización de funciones generales) y en librerías U/SIM Toolkit (7) (para la realización de funciones relacionadas con el estándar U/SIM Application Toolkit).

- Aplicaciones nativas: Aplicaciones de uso específico de acuerdo a un estándar concreto. No suelen ejecutarse sobre una máquina virtual sino directamente sobre la plataforma hardware para aumentar su eficiencia. En la tarjeta ilustrada en la figura 1, se trata de las aplicaciones WIM (2), U/SIM (3) y de la máquina virtual (4).

En la tarjeta ilustrada existen, por lo tanto, dos módulos diferentes para proporcionar seguridad:

- la librería criptográfica 6: se trata de una librería perteneciente a la librería genérica 5 que acompaña a la máquina virtual 4. La máquina virtual seleccionada podría no proporcionar ninguna y en ese caso sería necesario crearla a tal efecto para que todas las aplicaciones ejecutadas sobre la máquina virtual que necesiten seguridad no se vean obligadas a implementar sus propias funciones y almacenar la información necesaria.

- el módulo WIM 2: este módulo es sólo accesible a través del cliente WAP del terminal y es capaz de realizar funciones de seguridad basadas en diferentes algoritmos de cifrado tanto simétrico como asimétrico. Sobre todo presenta una importante ventaja frente a la librería criptográfica 6 antes mencionada: se trata de un dispositivo "tamper-resistant", esto es, dotado de una protección hardware que impide que la información almacenada en el mismo sea extraída o modificada de forma fraudulenta.

Utilizando los dos módulos se presenta además el problema de la diversidad de claves. Un mismo usuario poseerá para su identificación personal diferentes claves en función de si la autenticación se realiza en WAP o en alguna aplicación ejecutada sobre la máquina virtual. Cuando la autenticación se realiza en WAP, la identificación personal se hace en base al WIM 2. Cuando la autenticación se hace en una aplicación residente en la tarjeta, sobre la máquina virtual 4, no se hace en base al módulo WIM 2 sino, por ejemplo, en base a la librería criptográfica 6. La figura 2 refleja, de forma esquemática, acceso a funciones de seguridad desde una aplicación residente, según el estado de la técnica. Como se puede ver, en un primer paso S21, la aplicación residente A1 solicita a la librería criptográfica 6 la realización de una operación criptográfica; en el paso S22, la librería criptográfica devuelve el resultado de la operación.

Se considera deseable que un mismo usuario pueda poseer diferentes identidades pero sólo un par de claves para gestionar su autenticación en todas ellas, sobre todo teniendo en cuenta que cuando se trata de autenticación, antes de utilizar las claves se suele comprobar la autenticidad del usuario con un código PIN de al menos 4 dígitos; si el usuario tiene muchas claves, se puede ver obligado a recordar todos los códigos PIN asociados a sus claves.

Descripción de la invención

Por tanto, sería deseable poder utilizar un solo módulo de seguridad en la tarjeta, accesible desde todos las aplicaciones residentes en la misma (aplicaciones Toolkit, aplicaciones genéricas,...) y también (en el caso de la telefonía móvil) desde el cliente WAP, residente en el terminal del teléfono móvil (con aplicaciones residentes nos referimos a aplicaciones que han sido cargadas -remota o localmente- en la tarjeta; existen otras aplicaciones, por ejemplo, el cliente WAP, que no están cargadas en la tarjeta inteligente sino en el terminal del teléfono móvil).

Dadas las importantes ventajas presentadas por el módulo WIM, puede ser éste el módulo seleccionado para realizar la labor.

Por lo tanto, por un lado se debe suministrar una interfaz para que cualquier aplicación en la tarjeta, por ejemplo, una aplicación SIM Toolkit, pueda emplear la información de identidad y protección del usuario almacenada en el módulo WIM, e incluso solicitar al mismo la ejecución de los servicios de seguridad. Por otro lado, se hace necesario autentificar a las aplicaciones que usan el módulo en función de las operaciones solicitadas al mismo; las aplicaciones cargadas en la tarjeta inteligentetendrán procedencia muy diversa dado que pueden ser creadas por terceras empresas para fines muy diversos. Las funciones de seguridad y la información almacenada en el módulo WIM son muy sensibles y no puede permitirse a cualquier aplicación acceder a las mismas, por ello será necesario autentificar a cada aplicación antes de realizar los servicios solicitados, en función del riesgo asociado.

La solución completa se puede definir como un "gestor de seguridad" que reciba las peticiones de las aplicaciones sobre la realización de servicios de seguridad (funciones de seguridad (operaciones criptográficas) y/u obtención de información/datos (de identidad y protección de usuario, certificados, etc.)), verifique la procedencia de dichas peticiones, compruebe la autorización de las aplicaciones para realizar los servicios que solicitan, lleve a cabo la solicitud (podría implicar más de un acceso al módulo WIM y/o otros módulos) y devuelva el resultado de la misma a la aplicación que lo solicitó.

Aunque la necesidad del gestor de seguridad surge, al menos parcialmente, a raíz de los servicios que actualmente se implementan utilizando Aplicaciones SIM Toolkit, puede ser conveniente diseñar el gestor de seguridad de modo que pueda ser utilizado por cualesquiera aplicación cargada sobre la tarjeta inteligente (también en los casos en los que no exista aplicación U/SIM ni U/SIM Toolkit en la tarjeta). Es decir, se ha desarrollado una invención aplicable a tarjetas inteligentes en general, y no exclusivamente a tarjetas U/SIM.

Un primer aspecto de la invención se refiere a un gestor de seguridad para una tarjeta inteligente, para proporcionar servicios de seguridad a aplicaciones residentes en la tarjeta inteligente, comprendiendo dichos servicios de seguridad funciones criptográficas y/o obtención de datos relacionados con la seguridad de un propietario de la tarjeta (por ejemplo, claves, certificados, etc.). Según la invención, el gestor de seguridad comprende:

a-

medios para recibir una solicitud de un servicio de seguridad, desde una aplicación residente en una tarjeta inteligente;

b-

medios para comprobar de qué aplicación residente proviene dicha solicitud;

c-

medios para comprobar si dicha aplicación residente está autorizada a acceder al servicio de seguridad;

d-

medios para facilitar dicho servicio de seguridad a la aplicación residente a partir de un Módulo de Identidad Inalámbrico (WIM) de la tarjeta, siempre que dicha aplicación residente esté autorizada a acceder al servicio de seguridad y siempre que la tarjeta inteligente esté dotada de un Módulo de Identidad Inalámbrico (WIM).

La necesidad de autorización dependerá del servicio solicitado, esto es, habrá servicios de riesgo muy alto, acceso a los cuales requiere una autorización, y otros de riesgo muy bajo que, a lo mejor, no necesitan autorización; en general, esto puede ser configurable para satisfacer los requerimientos de, por ejemplo, el operador de una red de telefonía móvil. La funcionalidad de autenticación como tal puede ser inherente al gestor de seguridad que decidirá cómo la aplica. A través del gestor de seguridad puede solicitarse la realización de un conjunto de funciones de seguridad (funciones criptográficas) o la obtención de información relacionada con la seguridad, es decir, la realización de un "servicio de seguridad". En función de los niveles de riesgo asociados con los diferentes servicios que pueden proporcionarse, pueden establecerse diferentes niveles de protección (todos ellos basados en la autentificación del origen de la solicitud del servicio). Por ejemplo, supongamos un gestor de seguridad que proporciona dos funciones de seguridad, por ejemplo, cifrado y cálculo de firma digital, además de permitir la obtención de los certificados de usuario. Un determinado propietario de este gestor de seguridad (se entiende como tal al emisor final de la tarjeta, por ejemplo, un operador de una red de telefonía móvil) puede decidir dotarlo de la siguiente configuración:

1)

Establecer tres niveles de seguridad:

Nivel 0: sin protección;

Nivel 1: proporcionar password;

Nivel 2: proporcionar prueba de posesión de clave privada; y

2)

Proteger las funcionalidades del gestor de seguridad del siguiente modo:

Cifrado: Nivel 1

Cálculo de firma digital: Nivel 2

Obtención de certificados de usuario: Nivel 0

Una vez configurado de este modo, las aplicaciones que soliciten al gestor de seguridad algún certificado de usuario no deberán autentificarse, aquellas que requieran del gestor de seguridad el cifrado de un conjunto de datos deberán presentarle una password autorizada y aquellas que soliciten el cálculo de una firma digital deberán demostrar estar en posesión de una clave privada cuya clave pública haya sido certificada por una CA de confianza para el operador.

Como su propio nombre indica, los niveles de seguridad y sus correspondencias deberán ser configurables. Lo antes expuesto se trata sólo de un ejemplo.

Es decir, si el servicio de seguridad (la función criptográfica o la información) solicitado lo requiere, se debe autentificar a la aplicación solicitante; el gestor de seguridad deberá verificar si el servicio solicitado requiere o no autentificación y si la requiere, realizar la comprobación correspondiente.

Los medios "a"-"d" mencionados pueden realizarse de muchas formas y dependerán enormemente del tipo de software utilizado en la tarjeta inteligente, si dispone o no de máquina virtual y del lenguaje de programación entendido por dicha máquina virtual. Pero, en general, en lo que se refiere a los medios "a", "b" y "d", el gestor de seguridad no será más que una librería con funciones invocadas desde las aplicaciones residentes.

Otro aspecto de la invención se refiere a una tarjeta inteligente, que comprende:

- al menos una aplicación residente;

- un gestor de seguridad de acuerdo con la invención; y opcionalmente, un Módulo de Identificación de Usuario (U/SIM).

Una o varias de las aplicaciones residentes pueden ser una aplicación U/SIM Toolkit (U/SAT).

La tarjeta inteligente puede comprender al menos una librería criptográfica que puede proporcionar servicios de seguridad a aplicaciones residentes en la tarjeta inteligente. En tal caso, el gestor de seguridad puede estar configurado de modo que si una aplicación residente solicita un servicio de seguridad y si la tarjeta inteligente no está dotada de un Módulo de Identidad Inalámbrico (WIM), el gestor de seguridad facilita dicho servicio de seguridad a la aplicación a partir de la librería criptográfica.

La tarjeta inteligente puede comprender un Módulo de Identidad Inalámbrico (WIM).

La tarjeta inteligente puede comprender una interfaz (por ejemplo, una interfaz Java) de acceso al Módulo de Identidad Inalámbrico (WIM) sólo accesible por el gestor de seguridad. Preferiblemente, desde las aplicaciones residentes, el Módulo de Identidad Inalámbrico (WIM) solamente es accesible a través del gestor de seguridad.

Otro aspecto de la invención se refiere a un teléfono móvil que comprende un terminal y, además, una tarjeta inteligente de acuerdo con la invención.

Otro aspecto de la invención se refiere a un método de gestión de seguridad en una tarjeta inteligente. De acuerdo con la invención, cuando se recibe (en lo que podemos llamar un "gestor de seguridad") una solicitud de un servicio de seguridad de una aplicación residente en la tarjeta inteligente, se llevan a cabo las siguientes operaciones:

a-

se comprueba desde qué aplicación residente proviene dicha solicitud;

b-

se comprueba si dicha aplicación residente está autorizada a acceder al servicio de seguridad;

c-

si dicha aplicación residente está autorizada a acceder al servicio de seguridad, se facilita dicho servicio de seguridad a la aplicación a partir del Módulo de Identidad Inalámbrico (WIM) (si la tarjeta tiene tal módulo; si no lo tiene, se puede facilitar el servicio de seguridad desde una librería criptográfica).

Para comprobar si la aplicación residente está autorizada a acceder al servicio de seguridad solicitado, se empieza preferiblemente por comprobar si el servicio de seguridad solicitado requiere una autorización determinada de acceso y si requiere dicha autorización determinada, se comprueba que la aplicación residente tiene dicha autorización determinada y si no tiene dicha autorización determinada, no se facilita el servicio de seguridad a la aplicación. Si el servicio de seguridad solicitado no requiere ninguna autorización determinada para acceso al servicio, se considera que todas las aplicaciones están autorizadas a acceder al servicio de seguridad.

En un principio, la invención no tiene que afectar la manera en la que el cliente WAP accede al módulo WIM desde el terminal. Su comportamiento puede seguir siendo el mismo; lo que cambia es que el módulo WIM ya no sólo será accesible para una aplicación residente en el terminal sino también para una aplicación residente en la propia tarjeta inteligente.

Breve descripción de los dibujos

A continuación se pasa a describir de manera muy breve una serie de dibujos que ayudan a comprender mejor la invención y algunas de las cuales se relacionan expresamente con realizaciones de dicha invención que se presentan como ejemplos ilustrativos y no limitativos de ésta.

La figura 1 es una posible representación esquemática de la configuración de una tarjeta inteligente U/SWIM según el estado de la técnica.

La figura 2 representa, de forma esquemática, el proceso de acceso a funciones de seguridad desde una aplicación residente, según el estado de la técnica.

La figura 3 es una representación esquemática de la configuración de una tarjeta inteligente U/SWIM según una realización preferida de la invención.

La figura 4 es una representación esquemática de la estructura lógica del sistema, según una realización preferida de la invención.

La figura 5 representa, de forma esquemática, el proceso de acceso a funciones de seguridad desde una aplicación residente, según una realización preferida de la invención.

La figura 6 es una representación esquemática de la configuración de una tarjeta inteligente según otra realización preferida de la invención.

La figura 7 es una representación esquemática de la configuración de una tarjeta inteligente similar a la de la figura 6 pero que incluye, además, un módulo U/SIM y aplicaciones Toolkit.

Descripción de una realización preferida de la invención

Tal y como se ha comentado, la invención parte de la idea de utilizar un módulo de seguridad principal cargado en la tarjeta inteligente, siendo dicho módulo de seguridad accesible desde todas las aplicaciones posibles residentes en la tarjeta (aplicaciones Toolkit, aplicaciones genéricas, ...). Dadas las importantes ventajas presentadas por el módulo WIM, es preferible que éste sea el módulo seleccionado para realizar la labor. Ahora bien, el hecho de que el gestor de seguridad utilice principalmente el módulo WIM para proporcionar las funciones de seguridad y la identidad del usuario no significa que excluya totalmente la utilización de la librería criptográfica. Una librería criptográfica puede proporcionar funciones de seguridad de menor importancia que las realizadas por el módulo WIM pero útiles al fin y al cabo y el gestor de seguridad podría utilizarlas para dotarse de mayor funcionalidad. Esto es, en la situación preferida el gestor de seguridad proporcionará a las aplicaciones un conjunto de funciones de seguridad (realizadas por WIM y por la librería criptográfica) y una serie de informaciones de identidad (proporcionadas sólo por el módulo WIM).

De acuerdo con una realización preferida de la invención, se han creado dos nuevos elementos y se ha configurado una tarjeta tal y como se ilustra en la figura 3 (esta tarjeta tiene muchos elementos en común con la tarjeta conocida ilustrada en la figura 1; estos elementos comunes llevan las mismas referencias numéricas que en la figura 1):

1) Se ha creado un gestor de seguridad 8 a través del cual pueda solicitarse la realización de cualquier función de seguridad y/o la obtención de información de seguridad (claves, certificados...) por las aplicaciones residentes en la tarjeta. El gestor de seguridad es accesible desde todo tipo de aplicaciones residentes en la tarjeta inteligente. Aportará sencillez y transparencia a la realización de los servicios de seguridad por parte de la aplicación llamante (la que solicita un servicio de seguridad) y autenticará a las aplicaciones solicitantes (en caso de ser necesario).

2) Por otra parte, se ha creado una interfaz Java 9 para acceso al módulo WIM 2, sólo accesible a través del gestor de seguridad 8 utilizando mecanismos disponibles por la máquina virtual Java Card.

Según esta realización preferida de la invención, el gestor de seguridad está preparado para trabajar con la librería criptográfica proporcionada por el API de la máquina virtual para Java Card además de con el módulo WIM. De este modo, la interfaz de seguridad para las aplicaciones residentes en la tarjeta siempre será la misma, exista o no el módulo WIM 2 (no todas las tarjetas inteligentes llevan cargada una aplicación WIM). La interfaz Java 9 proporciona una interfaz de programación que le dota de visibilidad exterior. Está diseñada para que solamente pueda ser accesible desde el gestor de seguridad 8. De este modo, no podrán realizarse ataques fraudulentos al módulo WIM 2 que le vuelvan vulnerable, ya que el gestor de seguridad 8 dispone de medios para controlar la procedencia de cada solicitud de un servicio de seguridad (operación criptográfica u obtención de información de identidad y protección) y de medios para comprobar si la aplicación de la que proviene la solicitud está autorizada a acceder al servicio solicitado. La interfaz Java 9 puede opcionalmente aportar una funcionalidad añadida a la ya aportada por las propias funciones del módulo WIM, simplificando la gestión de dichas funciones, por ejemplo.

El gestor de seguridad centraliza todas las operaciones relacionadas con servicios de seguridad (operaciones criptográficas, acceso a claves,...) a realizar para las aplicaciones residentes en la tarjeta. Cualquier aplicación podrá acceder a él para solicitar el servicio de seguridad que necesite. En caso de que una aplicación WIM esté presente en la tarjeta, estos servicios serán realizados utilizando la interfaz Java 9 mencionado anteriormente principalmente. Algunos servicios de seguridad complementarias pueden ser realizados utilizando la librería criptográfica. (Si la tarjeta no tiene el módulo WIM 2, el gestor de seguridad 8 se encargará de redirigir todas las solicitudes a la librería criptográfica 6).

Si la función criptográfica/información solicitada lo requiere, el gestor de seguridad 8 debe autentificar a la aplicación solicitante; de este modo se garantiza aún más la integridad del módulo WIM. Las aplicaciones interpretadas, tanto las aplicaciones Toolkit (AT1, AT2, AT3, AT4) como las aplicaciones genéricas (A1, A2) pueden ser codificadas por terceros. Esto hace que no pueda ser garantizado el uso no fraudulento de la tarjeta por parte de las mismas.

La autenticidad de una aplicación es, sobre todo, necesaria en operaciones del tipo firma de No-Repudio, dado que se compromete la identidad legal del usuario. En estas operaciones suele ser necesario además un PIN (código de 4 a 8 cifras) que sólo conoce el usuario. Cuando para realizar una operación criptográfica sea además necesaria información a proporcionar por el usuario, será la aplicación solicitante la encargada de pedir la información al usuario y remitirla al gestor de seguridad.

La figura 4 ilustra, de forma esquemática, la estructura lógica del sistema según una realización preferida de la invención; tal y como se puede observar, las aplicaciones genéricas (A1,...) y las aplicaciones Toolkit (AT1,...) residentes en la tarjeta inteligente tienen acceso a las funciones de seguridad/información sólo a través del gestor de seguridad 8. En cambio, el cliente WAP 10 tiene acceso directo al módulo WIM, igual que en el estado de la técnica. Es decir, según esta realización preferida de la invención, el gestor de seguridad no interviene en los servicios de seguridad solicitados por el cliente WAP. También puede ser que determinadas aplicaciones en otras tarjetas tengan acceso directo al módulo WIM, de forma análoga a lo que ocurre con el cliente WAP, a través de un mecanismo U/SIM Toolkit llamado "Múltiple Card" cuyos procedimientos y comandos se encuentran convenientemente explicados en la norma GSM 11.14 a partir de la Release 98 (ésta incluida) para SIM y 3GPP TS 31.111 para USIM.

La figura 5 representa, de forma esquemática, el proceso de acceso a servicios de seguridad desde una aplicación residente, según una realización preferida de la invención (en la que existe un módulo WIM en la tarjeta inteligente y una librería criptográfica):

- En un primer paso S1, la aplicación genérica (A1) o Toolkit (AT1) solicita al gestor de seguridad 8 la realización de una función criptográfica.

- Como respuesta a la solicitud, en el paso S2 el gestor de seguridad 8 solicita a la aplicación (A1/AT1) una identificación para comprobar si está o no autorizada para solicitar la realización de la función (preferiblemente, antes de solicitar la identificación, el gestor de seguridad comprueba si la función criptográfica solicitada requiere o no autentificación; si requiere autentificación se pide la identificación a la aplicación y se continúa con el proceso descrito; si no requiere autentificación, el gestor de seguridad podría pasar directamente al paso S4).

- En el paso S3 la aplicación (A1/AT1) facilita su identificación al gestor de seguridad.

- Suponiendo que la aplicación (A1/AT1) está autorizada, en el paso S4 el gestor de seguridad solicita, a través de la interfaz Java 9 (no ilustrada en la figura 5), que el módulo WIM 8 realice la función criptográfica solicitada. También se podría solicitar la ejecución de funciones de seguridad complementarias que se realizarían utilizando la librería criptográfica.

- En el paso S5, el módulo WIM 2 devuelve el resultado de la función al gestor de seguridad 8.

- En el paso S6, el gestor de seguridad 8 devuelve el resultado a la aplicación residente (A1, AT1) que solicitó la función.

La figura 6 refleja una configuración de una tarjeta inteligente según una realización parecida a la que se refleja en la figura 3, pero que no incluye ni una máquina virtual, ni un módulo U/SIM; la tarjeta incluye aplicaciones genéricas (A1, A2, A3) pero no aplicaciones Toolkit. La figura 7 refleja una configuración similar a la de la figura 6, pero incorporando un módulo U/SIM 3 y aplicaciones Toolkit (AT1, AT2). (Los elementos que las realizaciones expuestas en las figuras 6 y 7 tienen en común con la realización de la figura 3 llevan las mismas referencias numéricas).

A lo largo de la presente descripción y reivindicaciones la palabra "comprende" y variaciones de la misma, como "comprendiendo", no pretende excluir otros pasos o componentes.

Claims (15)

1. Un gestor de seguridad para una tarjeta inteligente, para proporcionar servicios de seguridad a aplicaciones residentes en la tarjeta inteligente, comprendiendo dichos servicios de seguridad funciones criptográficas y/o obtención de datos relacionados con la seguridad de un propietario de la tarjeta, caracterizado porque el gestor de seguridad (8) comprende:

- medios para recibir una solicitud de un servicio de seguridad, desde una aplicación residente (A1, A2, A3; AT1, AT2, AT3, AT4) en una tarjeta inteligente;

- medios para comprobar de qué aplicación residente proviene dicha solicitud;

- medios para comprobar si dicha aplicación residente está autorizada a acceder al servicio de seguridad;

- medios para facilitar dicho servicio de seguridad a la aplicación residente a partir de un Módulo de Identidad Inalámbrico (WIM) (2) de la tarjeta, siempre que dicha aplicación residente esté autorizada a acceder al servicio de seguridad y siempre que la tarjeta inteligente esté dotada de un Módulo de Identidad Inalámbrico (WIM).

2. Una tarjeta inteligente, que comprende:

- al menos una aplicación residente (A1, A2, A3; AT1, AT2, AT3, AT4); caracterizada porque además comprende

- un gestor de seguridad (8) según la reivindicación 1.

3. Una tarjeta inteligente según la reivindicación 2, caracterizada porque además incluye un Módulo de Identificación de Usuario (U/SIM) (3).

4. Una tarjeta inteligente según cualquiera de las reivindicaciones 2 y 3, caracterizada porque al menos una de las aplicaciones residentes es una aplicación Toolkit (U/SAT).

5. Una tarjeta inteligente según cualquiera de las reivindicaciones 2-4, caracterizada porque comprende al menos una librería criptográfica (6) que puede proporcionar servicios de seguridad a aplicaciones residentes en la tarjeta inteligente.

6. Una tarjeta inteligente según la reivindicación 5, caracterizada porque el gestor de seguridad está configurado de modo que si una aplicación residente solicita un servicio de seguridad y si la tarjeta inteligente no está dotada de un Módulo de Identidad Inalámbrico (WIM), el gestor de seguridad facilita dicho servicio de seguridad a la aplicación a partir de la librería criptográfica (6).

7. Una tarjeta inteligente según cualquiera de las reivindicaciones 2-6, caracterizada porque además comprende un Módulo de Identidad Inalámbrico (WIM) (2).

8. Una tarjeta inteligente según cualquiera de las reivindicaciones 2-7, caracterizada porque comprende una interfaz (9) de acceso al Módulo de Identidad Inalámbrico (WIM) sólo accesible a través del gestor de seguridad (8).

9. Una tarjeta inteligente según la reivindicación 8, caracterizada porque la interfaz (9) de acceso al Módulo de Identidad Inalámbrico (WIM) es una interfaz Java.

10. Una tarjeta inteligente según cualquiera de las reivindicaciones 8 y 9, caracterizada porque desde las aplicaciones residentes, el Módulo de Identidad Inalámbrico (WIM) solamente es accesible a través de dicha interfaz (9) de acceso.

11. Un teléfono móvil que comprende un terminal, caracterizado porque además comprende una tarjeta inteligente según cualquiera de las reivindicaciones 2-10.

12. Un método de gestión de seguridad en una tarjeta inteligente, caracterizado porque cuando se recibe una solicitud de un servicio de seguridad desde una aplicación residente (A1, A2, A3; AT1, AT2, AT3, AT4) en la tarjeta inteligente, se llevan a cabo las siguientes operaciones:

- se comprueba desde qué aplicación residente proviene dicha solicitud;

- se comprueba si dicha aplicación residente está autorizada a acceder al servicio de seguridad;

- si dicha aplicación residente está autorizada a acceder al servicio de seguridad, se facilita dicho servicio de seguridad a la aplicación a partir del Módulo de Identidad Inalámbrico (WIM) (2).

13. Un método según la reivindicación 12, caracterizado porque para comprobar si la aplicación residente está autorizada a acceder al servicio de seguridad solicitado se empieza por comprobar si el servicio de seguridad solicitado requiere una autorización determinada de acceso y si requiere dicha autorización determinada de acceso, se comprueba que la aplicación residente tiene dicha autorización determinada de acceso y si no tiene dicha autorización determinada de acceso, no se facilita el servicio de seguridad a la aplicación.

14. Un método según cualquiera de las reivindicaciones 12 y 13, caracterizado porque el servicio de seguridad comprende una función criptográfica.

15. Un método según cualquiera de las reivindicaciones 12 y 13, caracterizado porque el servicio de seguridad comprende la obtención de datos relacionados con la seguridad de un propietario de la tarjeta.