ES2956245T3 - Elemento multiconfiguración seguro y método asociado - Google Patents

Elemento multiconfiguración seguro y método asociado Download PDF

Info

Publication number
ES2956245T3
ES2956245T3 ES19205507T ES19205507T ES2956245T3 ES 2956245 T3 ES2956245 T3 ES 2956245T3 ES 19205507 T ES19205507 T ES 19205507T ES 19205507 T ES19205507 T ES 19205507T ES 2956245 T3 ES2956245 T3 ES 2956245T3
Authority
ES
Spain
Prior art keywords
application
communication interface
command
hardware element
execution
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES19205507T
Other languages
English (en)
Inventor
Vincent Guerin
Matthieu Boisde
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Idemia France SAS
Original Assignee
Idemia France SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Idemia France SAS filed Critical Idemia France SAS
Application granted granted Critical
Publication of ES2956245T3 publication Critical patent/ES2956245T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/35—Protecting application or service provisioning, e.g. securing SIM application provisioning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3227—Aspects of commerce using mobile devices [M-devices] using secure elements embedded in M-devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/086—Access security using security domains

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Hardware Design (AREA)
  • Strategic Management (AREA)
  • Accounting & Taxation (AREA)
  • Stored Programmes (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Computer And Data Communications (AREA)

Abstract

Elemento seguro utilizado en un terminal host, que comprende varias interfaces de comunicación (111, 112) con el exterior, varias aplicaciones (190) y un entorno de ejecución (130, 150, 160). Al menos dos aplicaciones son dominios de seguridad del emisor (ISD1, ISD2) que crean instancias de dos configuraciones de GlobalPlatform, generalmente las configuraciones GP UICC y eSE. El entorno de ejecución está configurado para recibir un comando (CMD) en una interfaz de comunicación (I), determinar una aplicación de destino para la ejecución de este comando en función de esta interfaz de comunicación y transmitir, en esta misma interfaz, una respuesta (REP) al comando. . La invención garantiza la independencia de las dos configuraciones al disponer que el entorno de ejecución no autoriza el acceso a un recurso de aplicación del elemento seguro para la ejecución del comando por parte de la aplicación de destino sólo si este recurso de aplicación está asociado con la comunicación. interfaz que recibe el comando. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Elemento multiconfiguración seguro y método asociado
CAMPO DE LA INVENCIÓN
La presente invención hace referencia a un elemento seguro, por ejemplo, utilizado en un terminal anfitrión de usuario.
CONTEXTO DE LA INVENCIÓN
Un elemento seguro, SE, es un componente o plataforma de hardware inviolable (normalmente un chip o una tarjeta inteligente) utilizado en un terminal anfitrión (normalmente un terminal móvil) y capaz de alojar de forma segura aplicaciones y datos de conformidad con las normas y requisitos de seguridad establecidos por autoridades de confianza.
Normalmente se utiliza como elemento esclavo de aplicaciones residentes en el dispositivo anfitrión o en un dispositivo externo (normalmente un lector), es decir, un esclavo en una relación maestro-esclavo con una aplicación instalada en el terminal anfitrión o en el dispositivo externo.
Un factor de forma cada vez más popular del SE es el elemento seguro integrado eSE (eSE) (por "embedded Secure Elément"). Este elemento seguro integrado suele estar soldado al terminal anfitrión.
Los elementos seguros se programan en función de las aplicaciones deseadas.
A modo de ejemplo, un eSE puede constituir el elemento seguro necesario para muchos usos o servicios basados en una comunicación NFC (Near Field Communication) implementados por un terminal móvil anfitrión. Por ejemplo, un servicio de pago NFC requiere la información bancaria secreta del usuario, que se almacena de forma ventajosa en el eSE, protegida de cualquier acceso no autorizado. Este es también el caso de un servicio de transporte público, en el que el eSE permite identificar al usuario ante los pórticos.
Otro ejemplo de elemento seguro es la UICC integrada (por "Universal Integrated Circuit Card"), que proporciona las credenciales de un abonado para autenticarse en una red de telefonía móvil. Se puede tratar, por ejemplo, de un eSE configurado como una tarjeta SIM (por "Subscriber Identity Module" - o módulo de identidad de abonado). Es lo que se conoce como eUICC (por "embedded Universal Integrated Circuit Card").
Para facilitar el despliegue de estas múltiples aplicaciones, se buscó facilitar la colaboración entre los fabricantes de elementos seguros y los proveedores de servicios. Para ello se introdujo el estándar GlobalPlatform. La versión actual de este estándar es la 2.3.
En el marco de este estándar, se han definido varias configuraciones SE, por ejemplo una configuración UICC (GlobalPlatform UICC Configuration v2.0) que describe el comportamiento del SE para una aplicación de telefonía móvil, una configuración eSE (GlobalPlatform Card Secure Element Configuration v1.0) que describe el comportamiento del SE para aplicaciones sin contacto en general, y una configuración de tarjeta de identidad (GlobalPlatform Card ID Configuration v1.0) que describe el comportamiento del SE para aplicaciones de identificación. Todas estas configuraciones definen cómo debe reaccionar el SE a las órdenes que recibe de la(s) aplicación(es) maestra(s) del terminal anfitrión. Cada una de ellas implementa un único dominio de seguridad emisor (o principal o raíz), conocido bajo la denominación ISD (por "Issuer Security Domain").
La ISD es una aplicación de gestión de seguridad a la que sólo puede acceder el emisor del SE, utilizando un secreto (generalmente un conjunto de claves criptográficas) que sólo él conoce.
Se puede personalizar mediante operaciones de gestión de contenidos que permiten que su contenido evolucione. Por ejemplo, puede instanciar, interiormente, otros dominios de seguridad, denominados adicionales, accesibles por los proveedores de servicios gracias a secretos (generalmente claves criptográficas) específicos de cada dominio y conocidos únicamente por el proveedor asociado a un dominio.
También puede instalar ficheros y aplicaciones en estos diferentes dominios de seguridad.
De forma conocida, un eSE configurado para aplicaciones NFC y soldado a un terminal anfitrión incluye un ISD que representa al fabricante del terminal anfitrión, el cual autoriza, mediante la instanciación de dominios de seguridad adicionales, la instalación de aplicaciones de pago sin contacto y aplicaciones de transporte sin contacto de diferentes proveedores.
Asimismo, un SE configurado como UICC o eUlCC propiedad de un operador de telefonía móvil puede permitir, por medio de la instanciación de dominios de seguridad adicionales en su ISD, la carga de diferentes perfiles de telefonía móvil para el acceso, con diferentes tarifas, por ejemplo, a su(s) red(es) móvil(es).
Es habitual que estas configuraciones diferentes (NFC y UICC) sean utilizadas por el mismo usuario. Por lo tanto, sería preferible tenerlas en un único terminal anfitrión (su teléfono móvil, por ejemplo). La publicación de la solicitud de patente FR2945143A1 describe un método de administración de aplicaciones en el que se selecciona un grupo de una o más aplicaciones de modo que una de las aplicaciones del grupo pueda ser utilizada por un dispositivo con el fin de realizar una transacción sin contacto con un lector externo.
RESUMEN DE LA INVENCIÓN
Sin embargo, prever dos (o más) SE dentro del terminal anfitrión no es una solución económicamente aceptable. De este modo se busca permitir que estas configuraciones diferentes coexistan dentro de un mismo SE.
Del mismo modo, no se consideraría aceptable prever una configuración mixta capaz de soportar tanto aplicaciones NFC como de telefonía móvil. Por una parte, dado que estos dos "mundos" son implementados por diferentes propietarios de elementos seguros, sería necesario comunicarles el mismo secreto para poder acceder al ISD del SE. Este enfoque no es aceptable por razones obvias de seguridad. Por otra parte, habría que establecer una gestión compleja del comportamiento (en realidad mixto) de la configuración mixta para que el SE adopte el comportamiento "UICC" o "eSE" según el caso. Los desarrollos complejos van en detrimento de la simplicidad del SE que pretende GlobalPlatform.
De este modo, los inventores han considerado permitir la carga de dos (o más) configuraciones, por medio de dos (o más) ISD, dentro de un mismo SE. Sin embargo, existe una necesidad de garantizar la independencia de las configuraciones, permitiéndoles, en caso necesario, utilizar recursos comunes (compartidos) cuando proceda.
En este contexto, la invención hace referencia a un elemento seguro que comprende varias aplicaciones y un entorno de ejecución para ejecutar las aplicaciones, estando configurado el entorno de ejecución para recibir una orden a través de una interfaz de comunicación con el exterior del elemento seguro, determinar una aplicación de destino para la ejecución de la orden y transmitir, a través de la interfaz de comunicación, una respuesta a la orden recibida de la aplicación de destino.
De acuerdo con la invención, el elemento seguro se caracteriza por que comprende varias interfaces de comunicación,
y por que el entorno de ejecución se configura para determinar la aplicación de destino en función de la interfaz de comunicación para la recepción de la orden y para autorizar el acceso a un recurso de aplicación del elemento seguro (es decir, un recurso que se puede utilizar en el entorno de ejecución, normalmente una aplicación, una interfaz de programación de aplicaciones o API o incluso un paquete o fichero elemental ELF) para la ejecución de la orden por parte de la aplicación de destino únicamente si este recurso de aplicación está asociado a la interfaz de comunicación para la recepción de la orden.
Correlativamente, la invención también hace referencia a un método de procesamiento en un elemento seguro que comprende varias interfaces de comunicación, varias aplicaciones y un entorno de ejecución para la ejecución de las aplicaciones, comprendiendo el método los siguientes etapas:
recibir una orden en una interfaz de comunicación con el exterior del elemento seguro,
determinar una aplicación de destino para la ejecución de la orden en función de la interfaz de comunicación para la recepción de la orden,
autorizar el acceso a un recurso de aplicación del elemento seguro para la ejecución de la orden por parte de la aplicación de destino sólo si este recurso de aplicación esté asociado a la interfaz de comunicación para la recepción da la orden, y
transmitir, a través de interfaz de comunicación, una respuesta a la orden recibida de la aplicación de destino.
De este modo, se pueden implementar tantos "mundos" independientes como interfaces de comunicación existan. En efecto, el entorno de ejecución de acuerdo con la invención, por ejemplo, a nivel de una máquina virtual Java Card (nombre comercial) según se describe a continuación, permite segregar los recursos de aplicación disponibles en función de las interfaces de comunicación y, por tanto, particionar los "mundos".
Por lo tanto, es posible implementar dos o más ISD independientes, y por lo tanto dos o más configuraciones de SE independientes, utilizando interfaces de comunicación distintas.
Un SE obtenido de este modo puede permitir la coexistencia de varios propietarios sin tener que compartir un secreto, por ejemplo, un operador de MNO y un fabricante de terminales anfitrión que gestionen, respectivamente, los aspectos eUICC y eSE de forma independiente.
Las características opcionales de las formas de realización de la invención se definen en las reivindicaciones dependientes.
De acuerdo con la invención, el elemento seguro comprende al menos dos aplicaciones de gestión de seguridad que definen dos dominios de seguridad emisores, estando cada dominio de seguridad emisor asociado a una interfaz de comunicación diferente. En efecto, las "configuraciones" tal como las definidas por GlobalPlatform se implementan mediante la instanciación de una aplicación primera o principal denominada ISD. Igualmente, esta disposición permite la implementación de varias configuraciones a través de varios ISD correspondientes.
De acuerdo con una característica particular, un primer dominio de seguridad emisor se asocia a una interfaz de comunicación con contacto, por ejemplo, del tipo ISO/IEC 7816, y un segundo dominio de seguridad emisor se asocia a una interfaz de comunicación sin contacto, por ejemplo, del tipo ISO/IEC 14443. Esto permite distinguir fácilmente entre dos configuraciones principales del estándar GlobalPlatform.
De acuerdo con otra característica particular, el entorno de ejecución se configura para gestionar un registro de estados de vida para cada uno de los dos dominios de seguridad emisores. Estos estados de vida de acuerdo con GlobalPlatform incluyen los estados OP_READY, INITIALIZED, SECURED, CM_LOCKED y TERMINATED. Esta disposición permite que el único elemento seguro físico se gestione como varios elementos seguros aparentes, cada uno gobernado por la ISD de una configuración cargada.
De acuerdo con otra característica particular, un dominio de seguridad y los recursos de aplicación asociados se ajustan a una de las configuraciones definidas por GlobalPlatform (por ejemplo, la configuración eSE, la configuración UICC, la configuración de una tarjeta de identidad, etc.). Por ejemplo, un dominio de seguridad emisor y los recursos de aplicación asociados se ajustan a la configuración eSE del estándar GlobalPlatform. Del mismo modo (como variante o en combinación), un dominio de seguridad emisor y los recursos de aplicación asociados se ajustan a la configuración UICC del estándar GlobalPlatform. El elemento seguro obtenido de este modo se ajusta al estándar GlobalPlatform.
De acuerdo con la invención, el entorno de ejecución comprende un registro que asocia, a cada uno de los varios recursos de aplicación, un identificador de aplicación (AID) específico del recurso de aplicación y un indicador representativo de una interfaz de comunicación asociada (y por tanto de un ISD o "mundo" asociado). De este modo, ambas informaciones pueden constituir un identificador único para cada recurso de aplicación, conforme a las exigencias del estándar GlobalPlatform.
De acuerdo con una característica particular, el registro tiene al menos un recurso de aplicación asociado a un indicador común a varias interfaces de comunicación. Un recurso de este tipo se comparte, por tanto, entre diferentes "mundos". Se puede tratar, por ejemplo, de ficheros elementales cargados (ELF) comunes a varias configuraciones, cada una de las cuales puede instanciar, por ejemplo, una aplicación a partir de los ELF comunes. Esta disposición permite reducir el consumo de memoria.
Por ejemplo, los ELF comunes, o cualquier otro recurso de aplicación común, se puede almacenar en un dominio seguro dedicado (o incluso en un dominio ISD ya existente) y ser visibles en/por todos los dominios instanciados a través del elemento seguro. "Visible" significa en este caso una accesibilidad a los ELF (o equivalente) que permite, por ejemplo, instanciar una aplicación (a partir de estos ELF comunes) en un dominio determinado, en particular uno distinto de aquel en el que se almacenan (adjuntan) los ELF comunes.
En otra forma de realización, el entorno de ejecución comprende una variable global establecida en un valor representativo de la interfaz de comunicación para la recepción de la orden. Esta disposición facilita la gestión del confinamiento de la ejecución de la orden dentro de un "mundo" definido por un ISD o una configuración determinada. En efecto, el valor de esta variable se puede comparar directamente con un indicador que marca cada recurso, para saber si este último es accesible durante la ejecución en curso.
En otra forma de realización, el entorno de ejecución tiene un entorno de ejecución conforme con el estándar GlobalPlatform 2.3 y un sistema operativo que interconecta el entorno de ejecución conforme con GlobalPlatform 2.3 con una plataforma de hardware del elemento seguro. Esta arquitectura se ajusta de forma ventajosa a las prácticas convencionales.
En una forma de realización particular, el sistema operativo se configura para transmitir, al entorno de ejecución conforme con el estándar GlobalPlatform 2.3, cualquier orden recibida en una interfaz de comunicación, acompañada de una indicación de la interfaz de comunicación para la recepción. Esta indicación permite al entorno de ejecución actualizar la variable global mencionada anteriormente.
De acuerdo con una característica particular, el sistema operativo (SO) comprende una variable local establecida en un valor representativo de la interfaz de comunicación para la recepción de la orden. Esta variable local permite al SO seguir la pista de la interfaz que se utilizará para transmitir la respuesta a la orden.
En otra forma de realización particular, el entorno de ejecución conforme con el estándar GlobalPlatform 2.3 tiene un entorno de ejecución Java Card (nombre comercial) formado por una máquina virtual Java Card e interfaces de programación de aplicaciones Java Card, estando configurada dicha máquina virtual Java Card para controlar que cualquier recurso de aplicación (módulo ejecutable, aplicación, API) utilizado para la ejecución de la orden por parte de la aplicación de destino esté asociado a la interfaz de comunicación para la recepción de la orden. Un control de este tipo se puede implementar de forma ventajosa en un módulo cortafuegos (o "firewall")de la máquina virtual. La presente invención amplía por tanto las funcionalidades clásicas del módulo cortafuegos de Java con este nuevo papel de control.
De acuerdo con una característica particular, la máquina virtual Java Card se configura, al recibir una orden acompañada de una indicación de interfaz de comunicación para la recepción, para establecer una variable global en un valor representativo de la interfaz de comunicación para la recepción indicada.
De acuerdo con otra característica particular, una interfaz de programación de aplicaciones, API, Java Card se asocia de forma nativa (es decir, en cuanto se compila) a una (o más) interfaces de comunicación específicas, de forma que esta API Java Card sólo se utiliza para la ejecución de una orden por parte de una aplicación de destino asociada a la interfaz de comunicación específica (o a una de las interfaces asociadas de forma nativa a la API). Esta disposición permite mejorar la seguridad del elemento seguro.
En otra forma de realización particular, el entorno de ejecución conforme con el estándar GlobalPlatform 2.3 tiene un sistema de interfaz de programación denominado OPEN en GlobalPlatform 2.3 configurado para determinar la aplicación de destino en función de la interfaz de comunicación para la recepción de la orden. Por ejemplo, conociendo la interfaz de comunicación, OPEN puede determinar un canal lógico de entre varios canales lógicos que comparten el mismo número, pero establecidos en diferentes dominios (o configuraciones). Por dominio (o configuración), se entiende un conjunto o entorno dedicado a una interfaz determinada gestionada por un ISD dedicado a este conjunto o entorno.
De acuerdo con una característica particular, el OPEN se configura para:
acceder a un registro que asocia, con cada uno de los varios recursos de aplicación, un identificador de aplicación (AID) específico del recurso de aplicación y un indicador representativo de una interfaz de comunicación asociada, y
al recibir una orden de selección de una aplicación identificada por un identificador AID incluido en la orden y recibido en una interfaz de comunicación, seleccionar la aplicación que, en el registro, está asociada con el identificador AID y con la interfaz de comunicación para la recepción.
En general, esta selección tiene en cuenta la asignación de las aplicaciones (por medio de su AID) a los diferentes canales lógicos cuando se seleccionan mediante una orden SELECT.
En todavía otra forma de realización, el entorno de ejecución se configura para recibir, en una segunda interfaz de comunicación, una segunda orden con una prioridad más alta que la orden que se está ejecutando actualmente por parte de la aplicación de destino:
suspender la ejecución de la orden por parte de la aplicación de destino y memorizar una indicación representativa de la interfaz de comunicación para la recepción de la orden suspendida, y a continuación determinar una segunda aplicación de destino para la ejecución de la segunda orden en función de la segunda interfaz de comunicación y comprobar que cualquier recurso de aplicación al que se acceda durante la ejecución de la segunda orden por parte de la segunda aplicación de destino esté asociado a la segunda interfaz de comunicación.
La ejecución de la orden suspendida se puede reanudar una vez que se haya ejecutado la segunda orden de mayor prioridad. Esto es posible gracias a la memorización o salvaguardado de información de la interfaz de comunicación, ya que esta información se utiliza para garantizar el control del acceso a los recursos de aplicación.
BREVE DESCRIPCIÓN DE LAS FIGURAS
Otras particularidades y ventajas de la invención se pondrán de manifiesto con la siguiente descripción, ilustrada por las figuras adjuntas, que ilustran ejemplos de formas de realización sin ninguna naturaleza restrictiva. En las figuras: • la figura 1 ilustra de forma esquemática un sistema que comprende un elemento seguro para la implementación de las formas de realización de la invención;
• las figuras 2 y 2a ilustran ejemplos de registros de GlobalPlatform para la implementación de las formas de realización de la invención;
• la figura 3 ilustra, con la ayuda de un ordinograma, un ciclo general de un elemento seguro en una forma de realización;
• la figura 4 ilustra, con la ayuda de un ordinograma, las etapas generales realizadas por un sistema operativo presente en un elemento seguro de acuerdo con las formas de realización de la invención; y
• las figuras 5a a 5c ilustran, con la ayuda de ordinogramas, etapas generales llevadas a cabo por un entorno operativo GlobalPlatform de acuerdo con formas de realización de la invención, respectivamente con la recepción de una orden APDU, a la recepción de una respuesta APDU y a la recepción de una solicitud de acceso a un recurso de aplicación durante la ejecución de una orden APDU en curso.
DESCRIPCIÓN DETALLADA DE LA INVENCIÓN
La presente invención hace referencia a la convergencia de configuraciones, como las configuraciones de GlobalPlatform, dentro de un único elemento seguro, SE, normalmente un SE integrado (mediante soldadura o equivalente) en un terminal anfitrión.
Una configuración GlobalPlaftorm, por ejemplo, es una implementación del estándar GlobalPlatform 2.3 que detalla el comportamiento del SE, y más concretamente de la aplicación principal de gestión de seguridad, también denominada ISD o dominio de seguridad emisor en GlobalPlatform, ante diversas solicitaciones u órdenes de gestión emitidas por el terminal anfitrión.
Se carga una configuración en el SE, en forma de paquete compilado que define el ISD, durante la personalización previa del SE. Igualmente, la configuración no cambia durante la vida útil del SE. El SE sólo se puede personalizar mediante operaciones de gestión de contenidos (por ejemplo, cargar o eliminar datos como por ejemplo aplicaciones o perfiles) dentro del ISD.
Un ejemplo de configuración de SE es la configuración UICC (descrita en el documento GlobalPlatform UICC Configuration v2.0) que proporciona, dentro del ISD, un entorno neutral que facilita la gestión remota OTA (por "overthe-air") de la UICC para proporcionar servicios móviles a los abonados. La comunicación entre el terminal anfitrión y la UICC se consigue generalmente a través de una interfaz de comunicación ISO basada en contactos, que suele utilizar el protocolo ISO/IEC 7816.
Otro ejemplo de configuración SE es la configuración eSE (descrita en el documento GlobalPlatform Card Secure Element Configuration v1.0) que, al igual que la configuración UICC, proporciona un entorno neutral dentro de la ISD para el despliegue de servicios distintos de la telefonía móvil. Se puede tratar de aplicaciones de pago sin contacto, aplicaciones bancarias, aplicaciones de transporte o equivalentes (paso por un pórtico de acceso), etc. En este caso, la comunicación entre el eSE y un lector externo (generalmente fuera del equipo anfitrión) se puede realizar a través de una interfaz de comunicación sin contacto (por medio de un módulo sin contacto del terminal anfitrión, por ejemplo, el CLF), normalmente según el protocolo ISO/IEC 14443.
Por supuesto, se pueden prever otras configuraciones que definan el comportamiento de un ISD en el marco de la presente invención, estén o no ya definidas por el estándar GlobalPlatform.
Cada configuración, por medio de su ISD y de su comportamiento en respuesta a las solicitaciones (órdenes), define por tanto un "mundo" particular de elemento seguro. En lo sucesivo, salvo indicación particular, los términos "mundo", "configuración" y "ISD" se utilizarán como sinónimos.
En particular, se habla de "mundo" UICC para designar, por ejemplo, la configuración GP UICC y, por tanto, el ISD implementado por una configuración de este tipo. Del mismo modo, se habla de "mundo" eSE para designar, por ejemplo, la configuración GP eSE y, por tanto, la ISD implementada por dicha configuración.
Uno de los objetivos de la presente invención es permitir que dos o más configuraciones coexistan funcionalmente dentro del mismo SE. Esta coexistencia requiere que se garantice la mayor independencia posible entre las configuraciones, es decir, entre los ISD correspondientes.
La invención propone alcanzar este objetivo configurando de forma adecuada el entorno de ejecución en el que se ejecutan las aplicaciones y, por tanto, los ISD. En particular, el entorno de ejecución se configura para asociar diferentes interfaces de comunicación del SE con diferentes configuraciones respectivas (o ISD). También se configura de forma que una orden recibida externamente a través de una de las interfaces de comunicación sea ejecutada por una aplicación de la configuración asociada a la interfaz en la que se recibe la orden, y de forma que esta ejecución por parte de la aplicación no pueda utilizar un recurso de aplicación, como por ejemplo otra aplicación o una API, que no esté asociada a la interfaz de comunicación en cuestión.
En este contexto, existe una relación directa entre, por un lado, el "mundo", la configuración, la ISD y, por otro lado, la interfaz de comunicación.
En los ejemplos siguientes, se toman principalmente como ejemplo dos configuraciones o "mundos", en concreto, la configuración GP UICC y la configuración GP eSE, asociadas a interfaces con y sin contacto, respectivamente. De nuevo en estos ejemplos, para simplificar la ilustración, cada uno de estos "mundos" o configuraciones o interfaz de comunicación se identifica mediante un identificador IND, por ejemplo "00" para el "mundo"/configuración UICC (y por tanto la interfaz con contacto) y "01" para el "mundo"/configuración eSE (y por tanto la interfaz sin contacto).
Por supuesto, la presente invención no se limita a este ejemplo de identificador digital, y se puede utilizar cualquier otro identificador, de naturaleza variada.
La figura 1 ilustra de forma esquemática un sistema 1 que comprende un elemento seguro 100 para la implementación de formas de realización de la invención.
El elemento seguro SE 100 se integra, por ejemplo, en un terminal anfitrión 200, que está equipado con un módulo de comunicación frontal sin contacto (CLF) (por "contact-less front-end") 210 para comunicarse con un lector externo CL 300. El terminal anfitrión 200 y el lector externo 300 son de tipos conocidos y, por lo tanto, no se describen con más detalle.
En este ejemplo, el elemento seguro 100 consta de una plataforma de hardware o circuito integrado 110, una BIOS 120 y un entorno de ejecución 130 para la ejecución de aplicaciones o "applets" 190. Estas aplicaciones tienen varios dominios de seguridad emisores, ISD1 a ISDn, dentro de los cuales otras aplicaciones APP o SSD pueden ser o haber sido instanciadas a partir de ficheros elementales cargados (ELF). En el ejemplo utilizado a lo largo de este documento, un primer ISD, denominado ISD1, se ajusta a la configuración UICC de GlobalPlatform y un segundo ISD, denominado ISD2, se ajusta a la configuración eSE de GlobalPlatform.
De una manera conocida per se, la plataforma de hardware 110 tiene un microprocesador, memorias (de acceso aleatorio y de sólo lectura) para almacenar programas informáticos y/o datos de ejecución, interfaces de comunicación que permiten el intercambio de datos entre el microprocesador y el exterior del SE 100 y posiblemente para alimentar el SE, y un bus que conecta estos diferentes componentes.
En el ejemplo de la figura, la plataforma hardware 110 implementa dos interfaces de comunicación 111, 112, una por contacto iSo/IEC 7816 con el terminal anfitrión 200 y la otra sin contacto ISO/IEC 14443 o NFC (por "Near Field Communication") con el lector externo 300. La interfaz sin contacto 112 se puede comunicar con el lector externo 300 por medio del módulo CLF 210 del terminal anfitrión 200, en cuyo caso el enlace SE 100-terminal 200 es conforme con el protocolo SWP (por "Single Wire Protocol"), o alternativamente se puede comunicar directamente con el lector externo 300 sin pasar por el módulo CLF 210 del terminal anfitrión 200.
Éste es sólo un ejemplo. En particular, se puede implementar un mayor número de interfaces.
Es a través de estas interfaces de comunicación 111, 112 que el SE 100 recibe órdenes del exterior (ya sea del terminal anfitrión 200 o del lector 300).
La interfaz con contacto 111 se utiliza normalmente para los intercambios entre el terminal anfitrión 200 y las aplicaciones de telefonía móvil contenidas en el "mundo" UICC gestionado por el ISD1, mientras que la interfaz sin contacto 112 se utiliza normalmente para los intercambios entre un lector externo 300 y las aplicaciones distintas de telefonía móvil contenidas en el "mundo" eSE gestionado por el ISD2.
La BIOS 120 proporciona la interfaz entre la capa de hardware 110 del SE 100 y los componentes nativos del SE, como por ejemplo el entorno de ejecución 130 que se describe más adelante. La BIOS 120 es convencional en este caso.
La presente invención proporciona un entorno de ejecución 130 adaptado para determinar una aplicación de destino para la ejecución de una orden recibida en función de la interfaz de comunicación para la recepción de la orden y para autorizar el acceso a un recurso de aplicación del elemento seguro (por ejemplo, una aplicación 190 o una API 172 de GlobalPlatform) para la ejecución de la orden por parte de la aplicación de destino sólo si este recurso de aplicación está asociado a la interfaz de comunicación para la recepción de la orden.
Al realizar estas operaciones, la ejecución de una orden recibida se limita a un "mundo" de recursos de aplicación que se define para la interfaz de comunicación en cuestión, ya sea el "mundo" UICC o el mundo "eSE" en el ejemplo utilizado en este caso a título ilustrativo. Al asociar diferentes configuraciones (o "mundos") con diferentes interfaces de comunicación, el SE 100 permite ahora ejecutar varias configuraciones diferentes de forma independiente. De esta forma, es posible la coexistencia de varias configuraciones dentro de un mismo elemento seguro.
El entorno de ejecución 130 consta de un sistema operativo SO 140 y un entorno de ejecución de alto nivel 150, por ejemplo un entorno de ejecución conforme con el estándar GlobalPlatform 2.3.
El sistema operativo 140 realiza las operaciones convencionales de un SO de elemento seguro, a saber, en particular recibir una orden en una interfaz de comunicación con el exterior del elemento seguro, transmitirla al entorno de ejecución GlobalPlatform 150 para obtener una respuesta y, a continuación, transmitir, a través de la misma interfaz de comunicación, esta respuesta obtenida en este caso.
Normalmente, las órdenes enviadas al entorno de ejecución GlobalPlatform 150 son órdenes APDU.
La interacción entre el sistema operativo 140 y el entorno de ejecución GlobalPlatform 150 es normalmente de un único subproceso (o "single-threaded"), lo que significa que el sistema operativo 140 no transmite ninguna nueva orden APDU recibida al entorno de ejecución GlobalPlatform 150 hasta que se haya completado la ejecución de la orden anterior.
En una forma de realización con gestión de prioridad, esto puede ser ligeramente diferente, y esta regla de único subproceso se puede omitir para órdenes de alta prioridad. Por ejemplo, si una orden recibida es detectada por el SO 140 como de mayor prioridad que una orden que se está ejecutando actualmente, el SO 140 puede decidir pasar esta nueva orden al entorno de ejecución GlobalPlatform 150 para su ejecución inmediata. La ejecución de la orden en curso se suspende hasta que la nueva orden se haya ejecutado.
Normalmente, el SE 100 tiene sólo una interfaz de comunicación con el exterior. Igualmente, para una orden en curso, el sistema operativo 140 siempre conoce la interfaz de comunicación para la recepción de la orden y que se debe utilizar para transmitir la respuesta APDU obtenida a cambio.
En el contexto de la invención en el que se proporcionan varias interfaces de comunicación 111, 112, el SO 140 puede memorizar, en una variable local o global, un identificador IND de la interfaz de comunicación en la que se recibió la orden en curso (y, por lo tanto, el "mundo" UICC o eSE correspondiente). Por ejemplo, la variable toma el valor 00 si la interfaz está con contacto (es decir, para el "mundo" UICC) y toma el valor 01 si la interfaz está sin contacto (es decir, para el "mundo" eSE). Por supuesto, se pueden implementar otros valores, en particular con un mayor número de interfaces en competencia.
Esta variable permite realizar un seguimiento de la interfaz que se utilizará para enviar la respuesta que se obtendrá.
Además, en el caso de la forma de realización con gestión de prioridades, este identificador memorizado en la variable se puede copiar en otra variable (o de forma más general en una lista FILO) cuando se suspende una orden en curso (debido al tratamiento prioritario de otra orden). Esta copia permite seguir la pista de la interfaz de recepción de la orden suspendida a lo largo de la toda la ejecución de la orden más prioritaria. De este modo, al final de esta última, el identificador copiado se puede volver a introducir en la variable local o global para permitir al SO 140 utilizar la interfaz de comunicación correcta a la hora de transmitir la respuesta a la orden previamente suspendida.
La(s) variable(s) utilizada(s) en este caso para memorizar las interfaces de comunicación utilizadas pueden ser locales 141 al SO 140 o pueden ser variables globales 163 utilizadas por parte del entorno de ejecución GlobalPlatform 150 (y más particularmente el entorno Java Card contenido en el mismo).
En este último caso, el SO 140 simplemente transmite la orden APDU recibida al entorno de ejecución GlobalPlatform 150, que puede controlar la ejecución de este orden como se describe a continuación para confinarlo al "mundo" UICC o eSE asociado a la interfaz mencionada en la variable.
En el primer caso, el SO 140 transmite la orden APDU recibida junto con una indicación de la interfaz de comunicación para la recepción, normalmente el valor IND (aunque son posibles otras indicaciones). Esta indicación permite al entorno de ejecución GlobalPlatform 150 rellenar una variable global 163 descrita más adelante, para indicar la interfaz de comunicación en la que se recibió la orden en curso. Una vez más, esto permite seguir la pista del "mundo" UICC o eSE en el que se debe circunscribir la ejecución de la orden en curso.
El entorno de ejecución GlobalPlatform 150 tiene, en el ejemplo de la figura, un entorno de ejecución (o "runtime environment") multiaplicación 160 y un conjunto de bibliotecas GlobalPlatform 170 para la gestión y ejecución seguras de aplicaciones 190.
El entorno de ejecución multiaplicación 160 normalmente es un entorno de ejecución Java Card (nombre comercial) formado por una máquina virtual (VM) Java Card 161 y varias API nativas definidas por el estándar Java Card, denominadas en este caso APIs Java Card 162. Una máquina virtual de este tipo admite canales lógicos, lo que significa que se pueden seleccionar varias aplicaciones simultáneamente por medio de canales lógicos distintos (identificados dentro de las órdenes y respuestas APDU).
La VM Java Card 161 recibe órdenes APDU del SO 140, posiblemente acompañadas de la indicación de las interfaces de comunicación para la recepción de estas órdenes. En este caso, la VM Java Card 161 actualiza la variable global 163 con la indicación de interfaz relativa a la orden en curso: "00" para la interfaz con contacto (es decir, el "mundo" UICC) y "01" para la interfaz sin contacto (es decir, el "mundo" eSE).
En la forma de realización con gestión de prioridades, la VM Java Card 161 también puede declarar otras variables globales (o de forma más general una cola FILO) para memorizar indicaciones de interfaz relativas a una o más órdenes de prioridad inferior que se suspenden (y cuya ejecución se reanuda posteriormente).
El entorno de ejecución Java Card 160 se carga, en forma compilada, en el SE 100 durante su configuración previa. Este entorno no está sujeto a cambios durante la vida útil del SE.
Sin embargo, por motivos de seguridad, puede ser útil que el acceso a algunas API Java Card 162 sea limité a algunos "mundos" (o ISD) y, por tanto, se prohíba a otros. En este caso, estas APIs 162 se pueden marcar como pertenecientes a tal o cual "mundo" en cuanto se compilan, en un formato que pueda ser reconocido por la VM Java Card 161 para impedir el acceso a ellas en caso necesario.
Por ejemplo, una API Java Card puede estar dedicada a la interfaz de comunicación sin contacto NFC 112 (y, por tanto, al "mundo" eSE), en cuyo caso es preferible que no sea accesible por las aplicaciones de telefonía móvil del "mundo" UICC. El identificador de una API 162 de este tipo accesible únicamente por una aplicación de telefonía no móvil (eSE "mundo") se puede entonces completar (prefijo o sufijo) con el indicador IND = "01".
De forma similar, una API Java Card de tipo caja de herramientas ("Toolkit") ETSI solo es utilizada por aplicaciones de telefonía móvil (es decir, el "mundo" UICC), y no debe ser accesible para las aplicaciones del "mundo" eSE. El identificador de una API 162 accesible únicamente por una aplicación de telefonía móvil ("mundo" UICC) se puede completar entonces con el indicador IND = "00".
Por último, algunas APIs accesibles por todos los "mundos" se pueden marcar con la ayuda del identificador común IND = "02" o incluso no marcarse en absoluto. Los identificadores de grupo también se pueden utilizar para marcar APIs como accesibles por un subconjunto (o grupo) de configuraciones instaladas en el SE.
Por supuesto, se pueden tener en cuenta otros valores y un mayor número de interfaces.
El conjunto de bibliotecas GlobalPlatform 170 definido por el estándar GlobalPlatform (GP) tiene un entorno GP conocido bajo la denominación OPEN 171, APIs GP 172 y un marco de confianza ("trusted framework" en lengua anglosajona) GP 173.
De manera conocida, el OPEN 171 proporciona funciones para la selección de aplicaciones 190 (incluidos los dominios de seguridad) que se ocupan de las órdenes SELECT recibidas, la distribución de las órdenes APDU recibidas por la VM Java Card 161 a las aplicaciones de destino, la protección de las órdenes y las respuestas (correspondiente a la noción, bien conocida por los expertos en la técnica, de canales seguros), la gestión de canales lógicos durante la selección de aplicaciones múltiples, la gestión del contenido del SE (por ejemplo, verificación, carga, instalación, eliminación de contenido como por ejemplo ficheros ELF y aplicaciones) o incluso la gestión de la seguridad del SE (para cambiar los estados de vida de los dominios de seguridad, incluidos los dominios de seguridad emisores).
Para gestionar el contenido del SE 100, incluidos los dominios de seguridad, el OPEN 171 mantiene actualizado un registro 174 (almacenado, por ejemplo, por la VM Java Card 161) que enumera los paquetes (o ficheros ELF) cargados en memoria, normalmente paquetes de APIs 190 o paquetes de API GP 172, así como las aplicaciones 190 instanciadas a partir de estos paquetes. Estos paquetes, aplicaciones y APIs se reagrupan bajo la denominación de recursos de aplicación.
El registro 174 es, por ejemplo, una lista de AID que identifica estos recursos de aplicación y vincula cada uno de ellos al dominio de seguridad al que pertenece (ya sea el ISD o un denominado dominio suplementario (SSD)).
De acuerdo con la invención, para permitir controlar el acceso o incluso la ejecución de recursos de aplicación en una configuración particular (por ejemplo, "mundo" UICC o eSE), el registro 174 asocia, con el identificador de aplicación (AID) específico de un paquete, API o aplicación, el indicador IND representativo del "mundo" en cuestión: IND = "00" para un recurso de aplicación dedicado al "mundo" UICC (interfaz con contacto), "01" para el "mundo" eSE (interfaz sin contacto) o "02" para un recurso de aplicación común a ambos "mundos".
Igualmente, cuando se cargan paquetes y se instalan aplicaciones 190 gestionadas por el OPEN 171, este último crea una nueva entrada en el registro 174 a partir del AID de estos recursos de aplicación, asociándole, a efectos de la invención, el indicador que representa la interfaz de recepción de las órdenes de carga/instalación (indicador rellenado en la variable global 163 en el momento de la carga/instalación). De manera conocida per se, se crea una nueva entrada en el registro para cada módulo ejecutable o "paquete" presente en un fichero elemental ELF cargado (estos módulos ejecutables incluyen por tanto las APIs) y para cada aplicación instalada (por tanto, instanciada) a partir de estos módulos.
Es sobre la base de este registro, y más concretamente de este indicador, que, como se describirá más adelante, la VM Java Card 161 puede realizar una comprobación de contención en la ejecución de una orden por parte de una aplicación de destino en la configuración UICC o eSE correspondiente a la interfaz 111 o 112 utilizada (como se indica en la variable global 163).
El registro 174 también puede memorizar un estado de vida de los dominios de seguridad como se define en el estándar GlobalPlatform. En particular, en el contexto de la invención, por lo tanto, puede ser necesario que el registro 174 memorice el estado de vida de dos (o más) ISD (y, por tanto, diferentes configuraciones o "mundos") durante la vida del SE 100. El control de estos estados de vida de los ISD es responsabilidad del OPEN 171, que actúa en respuesta a las órdenes de gestión del SE recibidas del propietario de la configuración correspondiente.
Se advierte por lo tanto que el SE de acuerdo con la invención permite gestionar independientemente el estado de vida de las diferentes configuraciones que aloja. Por ejemplo, si se desea bloquear las comunicaciones NFC (del mundo "eSE"), es posible cambiar el estado de vida del ISD2 "eSE" a CARD_LOCKED según GlobalPlatform (para un bloqueo temporal) o incluso TERMINATED (para un bloqueo permanente). Al mismo tiempo, el ISD1 puede seguir funcionando en el estado de vida SECURED. Del mismo modo, si desea bloquear las funciones de telefonía móvil, el estado de vida útil de ISD1 "UICC" se puede establecer en Ca Rd_LOCKED o TERMINATED.
La figura 2 ilustra un ejemplo de un registro 174 con algunas entradas. Una entrada corresponde a un recurso de aplicación, por ejemplo, un módulo ejecutable (biblioteca GP o API GP 172, por ejemplo) en un ELF, una aplicación instanciada 190.
En este ejemplo, dos aplicaciones tienen el mismo identificador AID "A0000031010" pero se instancian en las dos configuraciones UICC y eSE distintas: la primera en el "mundo" UICC ya que el registro 174 asocia el indicador IND "00" con el AID de la aplicación (primera línea), la segunda en el mundo eSE ya que el indicador IND utilizado es "01" (segunda línea).
Del mismo modo, ambos "mundos" pueden acceder al recurso de aplicación AID "A0000036001", cuyo indicador IND es común a ambos "mundos" por medio de su valor "02".
Se remarca que el identificador 1740 resultante de la concatenación del AID y del indicador IND es, en última instancia, único en la SE 100. La identificación de los recursos de la aplicación mediante identificadores únicos es conforme, por tanto, con el estándar GlobalPlatform.
La figura 2a ilustra una variante del registro 174 en la que el indicador IND se compone de dos bits (o valores o booleanos), indicando cada bit a qué interfaz está asociada al recurso de aplicación en cuestión. Por ejemplo, el primer bit indica si el "mundo" asociado con la interfaz con contacto (en este ejemplo, el "mundo" de la UICC) está asociado con el recurso de aplicación, mientras que el segundo bit indica si el "mundo" asociado con la interfaz sin contacto está asociado con el recurso de aplicación. Un indicador "11" indica, por tanto, que el recurso de aplicación es común a los "mundos" UICC y eSE.
Por supuesto, el número de bits se puede adaptar al número de "mundos" o configuraciones implementadas simultáneamente en el SE 100.
Volviendo a la figura 1, el OPEN 171 tiene una parte común 171-02 para los diferentes "mundos" implementados en el SE 100. Consiste principalmente en las funciones introducidas anteriormente (distribución de órdenes, selección de aplicación, gestión de contenidos, etc.).
No obstante, el OPEN 171 ofrece servicios específicos para determinados "mundos". Por ejemplo, el OPEN 171 proporciona servicios para cifrar canales OTA, por ejemplo de acuerdo con el protocolo SCP80, que sólo utilizan las aplicaciones de telefonía móvil (por lo tanto el "mundo" UICC). Por el contrario, algunos servicios son específicos de la gestión de la interfaz de comunicación sin contacto NFC, por ejemplo para definir comportamientos por defecto (por lo tanto el "mundo" eSE).
Igualmente, el OPEN 171 también tiene servicios dedicados a mundos específicos, por ejemplo los servicios 171-00 dedicados al "mundo" UICC (para la interfaz con contacto) y los servicios 171-01 dedicados al "mundo" eSE (para la interfaz sin contacto). El OPEN 171 se configura entonces, durante el tratamiento una orden recibida, para autorizar o no el acceso a sus servicios en función de la interfaz indicada en la variable global 163: por ejemplo, si ésta indica la interfaz sin contacto 112 (por medio del valor "01"), entonces sólo se podrán invocar los servicios 171-01 y 171-02 para el tratamiento de la orden en curso.
Las APIs GP 172 forman un conjunto de servicios o bibliotecas utilizadas por las 190 aplicaciones para comunicarse con el mundo exterior de forma estandarizada. Son estos servicios, por ejemplo, los que permiten descifrar las órdenes APDU recibidos o cifrar los datos de respuesta.
Por lo tanto, las APIs GP 172 son recursos de aplicación a los que llaman las 190 aplicaciones que ejecutan una orden. Igualmente, estas APIs están diseñadas para ser específicas de una configuración (o ISD) concreta.
Por ejemplo, el estándar GlobalPlatform define dos paquetes de APIs GP, uno general (org.globalpatform) y otro específico del dominio sin contacto (org.globalpatform.contacless). Cada configuración tiene su propio paquete API GP.
El paquete de servicios GlobalPlatform "org.globalplatform.contactless" accesible por las aplicaciones del "mundo" eSE (para la interfaz sin contacto) ofrece multitud de servicios, entre los que se incluyen, a modo de ejemplos no restrictivos, el acceso a un registro GlobalPlatform dedicado al "mundo" sin contacto (GPCLRegistry), un marco (framework) de eventos que permite notificar a las aplicaciones la aparición de eventos.
El paquete de servicios GlobalPlatform "org.globalplatform", al que pueden acceder todas las aplicaciones, ofrece otros servicios, entre los que se incluye, a modo de ejemplo no restrictivo, el servicio compartido de PIN (por "Personal Identification Number") conocido bajo la denominación "GlobalPIN", que permite en particular la verificación de un código PIN introducido por un usuario, la gestión del número de intentos posibles, el número de intentos restantes, etc.
Igualmente, en el ejemplo de los "mundos" UICC y eSE, se carga un paquete general API GP 1720 en la memoria del SE para el "mundo" UICC, mientras que se cargan dos paquetes para el "mundo" eSE, uno general 1721-1 y otro específico para sin contacto 1721-2.
Esto significa, por ejemplo, que en el registro 174 de la figura 2 , cada paquete cargado se marca con el indicador IND del "mundo" UICC o eSE correspondiente. Por ejemplo, se cargan dos paquetes API GP generales del AID "A0000035350", uno para el mundo UICC "00", el otro para el mundo eSE "01" (véanse las líneas 3 y 4), y el paquete APl GP sin contacto del AID "A0000037700" se carga únicamente para el mundo eSE "01" (véase la última línea).
El acceso a estas APIs GP está bajo el control de la VM Java Card 161 que, de acuerdo con el valor que tome la variable global 163, autoriza o no su ejecución en el marco de la ejecución de una orden en curso.
Por último, el marco de confianza ("trusted framework") GP 173 ofrece en particular servicios de comunicación segura entre aplicaciones 190. En este caso, la correcta ejecución de estos servicios está controlada, como se verá más adelante, por la VM Java Card 161 que sólo puede, de acuerdo con la invención, autorizar a una aplicación a comunicarse con una aplicación de su "mundo". Igualmente, en este caso, la VM Java Card 161 se basa en el valor tomado por la variable global 163 para autorizar o no una comunicación entre dos aplicaciones.
El entorno de ejecución 130 descrito de este modo permite la implementación independiente de dos (o más) configuraciones GlobalPlatform cargadas en el SE 100 durante una fase de pre-personalización del mismo.
Una primera configuración C1, por ejemplo, la configuración UICC de GlobalPlatform, se implementa en el SE 100, instanciando un primer dominio de seguridad emisor ISD1. Se trata de una aplicación de gestión de seguridad que tiene privilegios elevados (en comparación con otras aplicaciones 190) para acceder al OPEN 171 en particular. Esta configuración C1 (y por tanto el ISD1) está asociada a la interfaz ISO 111 con contacto. En el ejemplo dado anteriormente, este "mundo" UICC se identifica con la ayuda del valor IND = "00" en la variable global 163 y el registro 174.
Una segunda configuración C2, por ejemplo, la configuración eSE de GlobalPlatform, se implementa en el SE 100, instanciando un segundo dominio de seguridad emisor ISD2, también con privilegios elevados para acceder al OPEN 171. Esta configuración C2 (y por tanto el ISD2) está asociada a la interfaz sin contacto 112. En el ejemplo dado anteriormente, este "mundo" eSE se identifica utilizando el valor IND = "01" en la variable global 163 y en el registro 174.
La figura muestra a modo de ejemplo una configuración adicional Cn, que se puede asociar a otra interfaz de comunicación.
Los mecanismos para gestionar estos ISD y sus contenidos siguen siendo convencionales. En particular, la carga de ficheros ELF elementales, la instalación de aplicaciones APP y la instanciación de dominios de seguridad SSD adicionales son posibles gracias al conjunto de órdenes de gestión. Sin embargo, estos mecanismos están bajo el control del OPEN 171 descrito anteriormente, que tiene en cuenta la interfaz de comunicación utilizada (indicada en la variable global 163) para dirigirse a ISD1 o ISD2 (o ISDn) y actualizar el registro 174 en función del "mundo" afectado por una orden de gestión.
La figura 3 ilustra el ciclo general de un SE 100. La figura 4 ilustra, con ayuda de un ordinograma, las etapas generales realizadas por el SO 140 de acuerdo con las formas de realización de la invención. Las figuras 5a a 5c ilustran, con la ayuda de ordinogramas, etapas generales realizadas por el entorno operativo GP 150 de acuerdo con formas de realización de la invención, respectivamente con la recepción de una orden APDU, con la recepción de una respuesta APDU y con la recepción de una solicitud de acceso a un recurso de aplicación durante la ejecución de una orden APDU en curso.
Con referencia a la figura 3 , la fabricación del SE 100 antes de su suministro ("issuance") a un usuario final tiene una operación de personalización previa 30 durante la cual las funciones nativas del SE se cargan en la memoria del SE 100. Esta operación se realiza generalmente por medio de la interfaz ISO 111 del SE 100.
En particular, el SO 140 descrito anteriormente se compila y, a continuación, se carga en la memoria del SE 100. Este 50 140 es capaz de realizar las operaciones descritas con referencia a la figura 4.
También se cargan en la memoria del SE 100 la VM Java Card 161 y las APIs Java Card 162 nativas. La VM Java Card 161 contribuye a las operaciones descritas con referencia a las figuras 5, en particular para controlar la ejecución de una orden en curso al autorizar o no autorizar el acceso a los recursos de aplicación en función del valor contenido en la variable global 163 (por ejemplo, en función del "mundo" UICC o eSE considerado, es decir, la interfaz de comunicación 111 o 112 que recibe la orden).
La VM de la tarjeta Java 161 y las APIs Java Card 162 nativas se compilan antes de cargarse. En particular, las APIs Java Card 162 nativas se marcan, cuando se compilan, como visibles desde uno, otro o varios "mundos" (UICC C1 o eSE C2 en el ejemplo de la figure 1) como se describió anteriormente. De este modo, el acceso a los recursos de tipo API Java Card para la ejecución de una orden en curso también puede ser controlado por la VM Java Card 161 en función del "mundo" actual (identificado en la variable global 163).
El OPEN 171 y el marco 173 también se cargan en la memoria del SE 100.
Finalmente, los ELF de las configuraciones GP UICC C1 y eSE C2 junto con los ELF de las APIs GP correspondientes (1720 para la configuración UICC C1 y 1721 -1 y 1721 -2 para la configuración eSE C2) se cargan en la memoria del SE 100. A continuación, los dominios de seguridad emisores ISD1 e ISD2 y cualquier otra aplicación 190 planificada se instancian a partir de los ELFs cargados.
Como se mencionó anteriormente, estas cargas e instancias van acompañadas de la creación de las entradas correspondientes en el registro GP 174, con el "mundo" al que pertenecen marcado: una entrada por módulo ejecutable (por ejemplo, una biblioteca/API GP 172) y una entrada por aplicación 190 instanciada (incluidos los ISD).
51 el OPEN 171 crea automáticamente estas entradas durante estas operaciones, el indicador IND (véanse las figuras 2 y 2a) se fija en un valor representativo de la interfaz 111 con contacto, ya que es la que se utiliza para las órdenes de carga de ficheros ELF y de instalación de aplicaciones. Por lo tanto, todas las entradas se marcan inicialmente mediante el indicador IND = "00". En este caso, una orden propietaria puede permitir forzar el indicador IND a otro valor ("01" en el ejemplo) para los recursos (módulo ejecutable, aplicación) correspondientes al "mundo" eSE (para la interfaz sin contacto), o incluso a un valor común ("02" en el ejemplo) para los recursos compartidos.
Una vez prepersonalizado el SE 100, donde cada módulo ejecutable o aplicación se marca como perteneciente a uno (o más) "mundos", el SE 100 se emite ("issued") en la etapa 31, por ejemplo, integrado en un terminal anfitrión 200. Para esta operación, el(los) estado(s) de vida de los ISD instalados en el SE 100 se cambian al estado "SECURED", tal y como se define en el estándar GlobalPlatform. Esta operación se realiza bien enviando una orden ad hoc al OPEN 171, o bien enviando órdenes propietarias que modifiquen directamente el estado de vida de los ISD en el registro 174.
En una forma de realización, cada uno de los ISD (y, por tanto, cada "mundo" o configuración) tiene su propio estado de vida. En efecto, cada ISD corresponde a una configuración independiente distinta que, para un observador externo, parece un elemento seguro distinto. La invención permite, por tanto, gestionar ciclos de vida diferentes para estos diferentes elementos seguros aparentes.
Alternativamente, sin embargo, un único estado de vida puede ser implementado para todos (o alternativamente un subgrupo) de los ISD del SE 100, por ejemplo, para el ISD1.
Después de la transmisión, el SE 100 se puede utilizar (etapa 32) en el terminal anfitrión 200. Las etapas de las figuras 4 y 5 que se describen a continuación hacen referencia a operaciones realizadas por el SE 100 durante su utilización.
Los ISD que forman la SE 100 pueden pasar gradualmente a un estado de vida "TERMINATED" durante su utilización. Cuando todos los ISD se marcan como finalizados, el SE 100 ya no se puede utilizar (etapa 33).
En la etapa 32, el SE 100 se utiliza normalmente como esclavo en una relación maestro-esclavo con una aplicación residente instalado en el terminal anfitrión 200 o el lector sin contacto 300 (o de forma más general cualquier dispositivo externo). En otras palabras, el SE 100 recibe órdenes, normalmente APDU, de la aplicación residente y responde con las correspondientes respuestas, normalmente APDU.
Con referencia a la figura 4, el SO 140 recibe, por tanto, en la etapa 40, una orden APDU CMD en una interfaz de comunicación I, por ejemplo, la interfaz sin contacto 112, para solicitar una aplicación 190 de la configuración eSE C2.
Como el SO 140 es de único subproceso (o "single thread"), en la etapa 41 se determina si ya hay una orden que se está ejecutando actualmente por parte del entorno de ejecución GP 150.
Si no es el caso, el SO 140 establece la variable local 141 o la variable global 163 (dependiendo de la forma de realización) en un valor IND representativo de la interfaz para la recepción de la orden I. En el ejemplo, la variable toma el valor "01" porque la interfaz I es la interfaz sin contacto 112. Esta es la etapa 42.
Después de la etapa 42, el SO 140 transmite la orden CMD recibida al entorno de ejecución GP 150 para su ejecución. Esta es la etapa 43.
Preferiblemente, la orden va acompañada de la indicación IND representativa de la interfaz I, por ejemplo "01" en el ejemplo. Esta indicación permite a la VM Java Card 161 ajustar la variable global 163 al valor correcto para limitar la ejecución de la orden CMD al "mundo" correcto, es decir, el "mundo" (o configuración) asociado a la interfaz de comunicación a través de la cual se recibió la orden CMD. Este "mundo" (o configuración) también se denomina "mundo" (o configuración) actual o activo.
En presencia de una orden que ya se está ejecutando (salida "sí" de la prueba 41), el SO 140 determina, en la etapa 44, si la orden CMD recibida tiene una prioridad superior que la que se está ejecutando actualmente. Esta determinación también puede comprobar si la prioridad de la orden CMD recibida es superior a un umbral de prioridad para desencadenar un procedimiento de priorización (el umbral de prioridad se puede definir de forma absoluta -es decir, con un valor de prioridad fijo- o relativa a la orden que se está ejecutando actualmente -por ejemplo, N niveles de prioridad por encima de la orden que se está ejecutando actualmente-).
La etapa 44 es opcional en el sentido de que el SO 140 puede no llevar a cabo un mecanismo de priorización de órdenes (en cuyo caso no se realiza la etapa 44).
Si no es el caso (la orden CMD no tiene mayor prioridad), el SO 140 espera el final de la orden que se está ejecutando actualmente (y posiblemente otras órdenes ya recibidas y suspendidas por el momento, que pueden tener mayor prioridad) en la etapa 45 antes de pasar a la etapa 42 que tiene por objetivo configurar el SO 140 en el "mundo" correspondiente a la orden CMD antes de transmitir esta última para su ejecución (etapa 43).
Por ejemplo, el SO 140 puede crear una cola de órdenes recibidas, pero aún no procesadas. Esta cola puede ser del tipo FIFO (por "First In, First Out"). En una forma de realización, se puede tener en cuenta un nivel de prioridad de las órdenes recibidas para ordenar las órdenes que esperan dentro de la cola por orden de prioridad (la orden de mayor prioridad sale primero).
Si es el caso (orden CMD con mayor prioridad), el SO 140 decide dar prioridad a la nueva orden CMD recibida sobre la que se está ejecutando actualmente. Para ello, el SO 140 guarda el estado de la variable local 141 o de la variable global 163 (según el caso) para la orden que se está ejecutando actualmente. El valor de la variable puede, por ejemplo, almacenarse en una cola FILO (primera entrada, última salida), que permite anidar de forma recursiva varias órdenes de mayor prioridad. Esta es la etapa 46 antes de pasar a la etapa 42 ya descrita para configurar el SO 140 en el "mundo" correspondiente a la orden CMD antes de transmitir esta última para su ejecución (etapa 43).
La ejecución de la orden CMD transmitida al entorno de ejecución GP 150 tiene como resultado, para el SO 140, la recepción, en la etapa 47, de una respuesta APDU REP desde el entorno de ejecución GP 150 (generalmente de la VM Java Card 161).
En la etapa 48, el SO 140 utiliza el valor almacenado en la variable (local 141 o global 163) para averiguar la interfaz I en la que transmitir la respuesta REP a la aplicación residente.
En el caso de que se haya implementado el mecanismo de priorización (es decir, cuando la cola FILO no esté vacía), a la etapa 48 le sigue la etapa 49, durante la cual el SO 140 restaura la variable local 141 o global 163 para la última orden suspendida. Esto implica establecer esta variable en el primer valor de la cola FILO.
Haciendo referencia ahora a las figuras 5a a 5c, el entorno operativo GP 150 recibe tres tipos de mensajes que inducen un procesamiento distinto en relación con la presente invención: en primer lugar, una orden CMD transmitida por el SO 140, en segundo lugar, una respuesta APDU resultante de la ejecución de la orden CMD, y en tercer lugar, una solicitud de acceso a un recurso de aplicación durante la ejecución de la orden CMD en curso (a veces se reciben varias solicitudes durante la ejecución de la misma orden CMD).
En la etapa 500, la VM Java Card 161 recibe la orden CMD del SO 140, posiblemente acompañada de la indicación IND que representa la interfaz I de recepción de la orden.
En la etapa 501, la VM Java Card 161 determina si ya se está ejecutando una orden, en cuyo caso se implementa el mecanismo de priorización de órdenes.
Si es el caso, la VM Java Card 161 guarda (etapa 502) el valor de la variable global 163, por ejemplo, en una cola FILO (como se describió anteriormente en relación con la etapa 46).
Si no es el caso, o después de la etapa 502, la VM Java Card 161 pasa a la etapa opcional 503 (en caso de que el 5 0 140 no haya actualizado la variable global 163), en la que establece la variable global 163 en el valor IND que acompaña a la orden CMD, es decir, en el valor "01" del ejemplo ("mundo" o configuración eSE utilizando la interfaz sin contacto).
El procesamiento posterior (figuras 5a a 5c) se lleva a cabo entonces mientras sólo un "mundo" (o configuración) está "activo" o "actual", tal como se indica ahora en la variable global 163.
La orden CMD se pasa al OPEN 171 en la etapa 504 para determinar (etapa 505) la aplicación de destino que debe ejecutar esta orden.
De forma conocida, las órdenes de tipo SELECT son ejecutadas por el propio OPEN 171 en un proceso de selección de una aplicación. Las demás órdenes son ejecutadas por una de las aplicaciones 190 que el OPEN 171 identifica utilizando el canal lógico indicado en la orden CMD.
51 se trata de una orden SELECT que indica uno de los 20 canales lógicos disponibles en el formato APDU, el OPEN 171 la ejecuta en la etapa 506. La ejecución consiste en que el OPEN 171 determina si el AID indicado en la orden SELECT corresponde a una entrada del registro 174 y si esta entrada (es decir, la aplicación) es seleccionable.
Dada la variedad de configuraciones (o "mundos") en el SE 100 de acuerdo con la invención, el OPEN 171 también tiene en cuenta el "mundo" activo, es decir, el valor actual IND almacenado en la variable global 163. Por ejemplo, el OPEN 171 puede concatenar el AID indicado en la orden con el valor actual IND ("01" en el ejemplo) para formar un identificador único para la entrada en el registro 174 (véase la figura 2 , por ejemplo). De este modo, si una entrada del registro 174 coincide con este identificador único y es seleccionable, el OPEN 171 la selecciona asignándole el canal lógico indicado en la orden SELECT.
En otras palabras, el OPEN 171 accede al registro 174 que asocia con cada uno de varios recursos de aplicación, un identificador de aplicación (AID) específico del recurso de aplicación y un indicador representativo de una interfaz de comunicación asociada, y selecciona, con la recepción de la orden de selección de una aplicación identificada por un identificador AID y recibida a través de la interfaz de comunicación I, la aplicación que, en el registro, está asociada con el identificador AID y con la interfaz de comunicación para la recepción.
En el caso de una orden distinta de la orden SELECT, la determinación de la aplicación de destino en la etapa 505 consiste en identificar el canal lógico indicado en la orden CMD para el "mundo" activo tal como se indica en la variable global 163. En efecto, si veinte canales lógicos están disponibles en el formato de órdenes APDU, estos canales se duplican en las diferentes (dos o incluso más) configuraciones disponibles en el SE 100. Esta situación de acuerdo con la invención resulta de la correspondencia/asociación "mundo"-interfaz (un mundo por interfaz) y del hecho de que hay duplicación de canales lógicos por interfaz. Igualmente, el OPEN 171 sólo debe elegir el canal lógico vinculado con el "mundo" activo (es decir, asociado a la interfaz de comunicación utilizada para la recepción de la orden CMD).
La aplicación de destino es entonces la aplicación seleccionada para el canal lógico determinado de este modo en el "mundo" activo.
De este modo, el OPEN 171 determina la aplicación de destino en función de la interfaz de comunicación I en la que se recibe la orden CMD.
El OPEN 171 transmite entonces la orden CMD a la aplicación de destino por medio de este canal lógico específico. Esta es la etapa 507.
La ejecución de la orden CMD, sea del tipo SELECT o no, conduce a la generación de una respuesta REP. Por lo tanto, en la etapa 510, la VM Java Card 161 recibe una respuesta REP de la aplicación de destino que ejecutó la orden CMD.
A continuación, la VM Java Card 161 transmite esta respuesta REP al SO 140 en la etapa 511.
A continuación, en la etapa 512, la VM Java Card 161 restaura el primer valor de la lista FILO en la variable global 163 (de forma similar a la etapa 49 descrita anteriormente). La etapa 512 permite al entorno de ejecución GP 150 actualizar la indicación que representa el "mundo" actual para la orden o órdenes suspendidas cuya ejecución se reanudará tras el procesamiento de la orden CMD.
La ejecución de la orden CMD (normalmente una orden que no sea SELECT) a veces requiere acceso a recursos fuera de la aplicación de destino, por ejemplo, acceso a otras aplicaciones 190, acceso a APIs GP 172 o Java Card 162.
Este es el caso de las órdenes de gestión de contenido del SE ("Card Content Management command") procesadas por el ISD de la configuración activa. Por ejemplo, la instalación de un nuevo paquete (nuevos ELF) se puede realizar con referencia a otros ficheros ELF ya cargados en el SE 100, que es necesario copiar.
Este es también el caso con las órdenes a aplicaciones instaladas en los ISD que requieren servicios de otras aplicaciones para ejecutarse (mecanismo de uso compartido o "sharing").
Estas distintas órdenes también pueden requerir el acceso a APIs para requisitos de protocolo (protocolo SWP por medio de una API Java Card), requisitos criptográficos (protocolo SCP80 por medio de una API GP), etc.
De acuerdo con la invención, el acceso a dichos recursos de aplicación del SE 100 para la ejecución de la orden CMD por parte de la aplicación de destino sólo se autoriza si estos recursos de aplicación son accesibles para la configuración activa, es decir, si están asociados a la interfaz de comunicación I para la recepción de la orden, tal como se indica en la variable global 163. Por lo tanto, para cada solicitud de acceso a dichos recursos, la VM Java Card 161 realiza un control de acceso. Este control puede ser operado normalmente por un cortafuegos (o "firewall") Java Card dentro de la VM Java Card 161. Como ya se vio anteriormente, la presente invención amplía las funcionalidades clásicas del cortafuegos con esta nueva función de control de acceso.
Un control de este tipo también lo realiza el OPEN 171, por ejemplo, cuando trata de acceder a sus propios servicios 171-00 a 171-02.
Igualmente, en la etapa 520, que tiene lugar durante la ejecución de la orden CMD (es decir, entre las etapas 504 y 510), la VM Java Card 161 detecta una solicitud de acceso a un recurso de aplicación. Esta solicitud procede de la ejecución de la orden CMD por parte de la aplicación de destino en el entorno de ejecución Java Card 160 (JCRE por "Java Card Runtime Environment").
En el registro 174, este recurso de aplicación solicitado corresponde a un AID con el indicador IND añadido.
En la etapa 521, la VM Java Card 161 recupera el valor de la variable global 163, que indica la configuración activa, es decir, la configuración eSE en el ejemplo (IND = "01").
En la etapa 522, la VM Java Card 161 comprueba que el recurso de aplicación solicitado es accesible en la configuración activa, en este caso la configuración eSE. Por ejemplo, puede comprobar que el indicador IND del recurso solicitado se corresponde con el valor tomado por la variable global 163, o que se trata de un valor común que engloba la interfaz indicada por la variable global 163.
Por ejemplo, si la variable global 163 se establece en 01 (interfaz sin contacto), los recursos con un indicador IND de "01" o "02" (en el caso de la figura 2) son accesibles (o "01" u "11" en el caso de la figura 2a).
Si es el caso, la ejecución de la orden CMD puede continuar autorizando el acceso al recurso solicitado (etapa 523).
Si no es el caso, la VM Java Card 161 deniega el acceso al recurso solicitado (etapa 524). Esta denegación puede conducir al fracaso de la ejecución de la orden CMD si la aplicación de destino que la ejecuta no sabe cómo gestionar esta denegación. En el caso contrario (la aplicación de destino gestiona la denegación), la ejecución de la orden CMD puede continuar.
Durante la ejecución de una misma orden CMD se pueden emitir varias solicitudes de acceso a otros recursos.

Claims (16)

REIVINDICACIONES
1. Elemento de hardware seguro (100) que comprende varias aplicaciones (190) y un entorno de ejecución (130, 150, 160) para ejecutar las aplicaciones, estando configurado el entorno de ejecución para recibir una orden (CMD) en una interfaz de comunicación (I) con el exterior (200, 300) del elemento hardware seguro, para determinar una aplicación de destino para la ejecución de la orden utilizando un recurso de aplicación entre varios recursos de aplicación del elemento de hardware seguro, y para transmitir, a través de la interfaz de comunicación, una respuesta (REP) a la orden recibida de la aplicación de destino,
el elemento hardware seguro se caracteriza por que comprende varias interfaces de comunicación (111, 112) y varias aplicaciones de gestión de la seguridad que definen varios dominios de seguridad emisores (ISD1, ISD2, ISDn), estando asociado cada dominio de seguridad emisor respectivamente a una interfaz de comunicación diferente (111, 112);
por que el entorno de ejecución (130, 150, 160) comprende un registro (174) que asocia, con cada recurso de aplicación de entre los varios recursos de aplicación, un identificador de aplicación (AID) específico del recurso de aplicación y un indicador (IND) representativo de una interfaz de comunicación asociada, en donde el registro asocia además, con cada aplicación de entre las varias aplicaciones (190), un identificador de aplicación (AID) específico de la aplicación y un indicador (IND) representativo de una interfaz de comunicación asociada;
y por que el entorno de ejecución se configura para determinar la aplicación de destino en función de la interfaz de comunicación para recibir la orden y para autorizar el acceso a un recurso de aplicación del elemento de hardware seguro para la ejecución de la orden por parte de la aplicación de destino sólo si este recurso de aplicación está asociado a la interfaz de comunicación para la recepción de la orden.
2. Elemento de hardware seguro de acuerdo con la reivindicación 1, en el que un primer dominio de seguridad emisor (ISD1) se asocia con una interfaz de comunicación de contacto (111), por ejemplo del tipo ISO/IEC 7816, y un segundo dominio de seguridad emisor (ISD2) se asocia con una interfaz de comunicación sin contacto (112), por ejemplo del tipo ISO/IEC 14443.
3. Elemento de hardware seguro de acuerdo con la reivindicación 1, en el que el entorno de ejecución se configura para gestionar un registro de estado de vida (174) para cada uno de los dos dominios de seguridad emisores (ISD1, ISD2).
4. Elemento de hardware seguro de acuerdo con la reivindicación 1, en el que un dominio de seguridad emisor (ISD2) y los recursos de aplicación asociados se ajustan a la configuración eSE del estándar GlobalPlatform 2.3, y/o un dominio de seguridad emisor (ISD1) y los recursos de aplicación asociados se ajustan a la configuración UICc del estándar GlobalPlatform 2.3.
5. Elemento de hardware seguro de acuerdo con la reivindicación 1, en el que el registro (174) tiene al menos un recurso de aplicación asociado a un indicador común a varias interfaces de comunicación.
6. Elemento de hardware seguro de acuerdo con la reivindicación 1, en el que el entorno de ejecución (130, 150, 160) comprende una variable global (163) ajustada a un valor representativo de la interfaz de comunicación para la recepción de la orden (I, 111, 112).
7. Elemento de hardware seguro de acuerdo con la reivindicación 1, en el que el entorno de ejecución tiene un entorno de ejecución (150) conforme con el estándar GlobalPlatform 2.3 y un sistema operativo (140) que interconecta el entorno de ejecución conforme con GlobalPlatform 2.3 con una plataforma de hardware (110) del elemento de hardware seguro.
8. Elemento de hardware seguro de acuerdo con la reivindicación 7, en el que el sistema operativo (140) se configura para transmitir, al entorno de ejecución conforme con el estándar GlobalPlatform 2.3 (150), cualquier orden (CMD) recibida en una interfaz de comunicación (I, 111, 112), acompañada de una indicación (IND) de la interfaz de comunicación para la recepción.
9. Elemento de hardware seguro de acuerdo con la reivindicación 7, en el que el sistema operativo (140) comprende una variable local (141) ajustada a un valor representativo de la interfaz de comunicación para la recepción de la orden (I, 111, 112).
10. Elemento de hardware seguro de acuerdo con la reivindicación 7, en el que el entorno de ejecución (150) conforme con el estándar GlobalPlatform 2.3 tiene un entorno de ejecución Java Card (160) formado por una máquina virtual Java Card (161) y unas interfaces de programación de aplicaciones Java Card (162), estando configurada dicha máquina virtual Java Card para controlar que cualquier recurso de aplicación utilizado para la ejecución de la orden (CMD) por parte de la aplicación de destino esté asociado a la interfaz de comunicación para la recepción de la orden.
11. Elemento de hardware seguro de acuerdo con la reivindicación 10, en el que la máquina virtual Java Card (161) se configura, al recibir una orden (CMD) acompañada de una indicación de interfaz de comunicación para la recepción (IND), para establecer una variable global (163) en un valor representativo de la interfaz de comunicación para la recepción indicada.
12. Elemento de hardware seguro de acuerdo con la reivindicación 10, en el que una interfaz de programación de aplicación, API, Java Card (162) se asocia de forma nativa a una interfaz de comunicación específica, de forma que esta API Java Card se utiliza únicamente para la ejecución de una orden por parte de una aplicación de destino asociada a la interfaz de comunicación específica.
13. Elemento de hardware seguro de acuerdo con la reivindicación 7, en el que el entorno de ejecución conforme con el estándar GlobalPlatform 2.3 (150) tiene una interfaz de programación del sistema (170) denominada OPEN en GlobalPlatform 2.3 configurada para determinar la aplicación de destino en función de la interfaz de comunicación para la recepción de la orden.
14. Elemento de hardware seguro de acuerdo con la reivindicación 13, en el que el OPEN (171) se configura para: acceder a un registro (174) que asocia, a cada uno de varios recursos de aplicación (190), un identificador de aplicación (AID) específico del recurso de aplicación y un indicador (IND) representativo de una interfaz de comunicación asociada, y
al recibir una orden de selección de una aplicación identificada por un identificador AID incluido en la orden y recibido en una interfaz de comunicación, seleccionar la aplicación que, en el registro, está asociada con el identificador AID y con la interfaz de comunicación para la recepción.
15. Elemento de hardware seguro de acuerdo con la reivindicación 1, en el que el entorno de ejecución (130) se configura para que, al recibir, en una segunda interfaz de comunicación, una segunda orden con mayor prioridad que la orden que se está ejecutando actualmente por parte de la aplicación de destino:
suspender la ejecución de la orden por parte de la aplicación de destino y memorizar una indicación representativa de la interfaz de comunicación para la recepción de la orden suspendida, y a continuación
determinar una segunda aplicación de destino para la ejecución de la segunda orden en función de la segunda interfaz de comunicación y comprobar que cualquier recurso de aplicación al que se acceda durante la ejecución de la segunda orden por parte de la segunda aplicación de destino esté asociado a la segunda interfaz de comunicación.
16. Método de procesamiento en un elemento de hardware seguro (100) que comprende varias interfaces de comunicación (I, 111, 112), varias aplicaciones (190), varios recursos de aplicación, y un entorno de ejecución (130, 150, 160) para la ejecución de las aplicaciones utilizando un recurso de aplicación de entre los varios recursos de aplicación, en donde el elemento de hardware seguro (100) comprende además varias aplicaciones de gestión de seguridad que definen varios dominios de seguridad emisores (ISD1, ISD2, ISDn), estando asociado cada dominio de seguridad emisor respectivamente a una interfaz de comunicación diferente (111, 112), en el que el entorno de ejecución (130, 150, 160) comprende un registro (174) que asocia, a cada recurso de aplicación de entre los varios recursos de aplicación, un identificador de aplicación (AID) específico del recurso de aplicación y un indicador (IND) representativo de una interfaz de comunicación asociada, donde el registro asocia además, con cada aplicación de entre las varias aplicaciones (190), un identificador de aplicación (AID) específico de la aplicación y un indicador (IND) representativo de una interfaz de comunicación asociada, comprendiendo el método los siguientes etapas: recibir (40) una orden (CMD) en una interfaz de comunicación (I, 111, 112) con el exterior (200, 300) del elemento hardware seguro,
determinar (505) una aplicación de destino para la ejecución de la orden en función de la interfaz de comunicación para la recepción de la orden,
autorizar (523) el acceso a un recurso de aplicación del elemento de hardware seguro para la ejecución de la orden por parte de la aplicación de destino sólo si este recurso de aplicación está asociado a la interfaz de comunicación para la recepción de la orden, y
transmitir (48), a través de la interfaz de comunicación, una respuesta (REP) a la orden recibida de la aplicación de destino.
ES19205507T 2018-10-30 2019-10-25 Elemento multiconfiguración seguro y método asociado Active ES2956245T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1860058A FR3087917B1 (fr) 2018-10-30 2018-10-30 Element securise multi-configurations et procede associe

Publications (1)

Publication Number Publication Date
ES2956245T3 true ES2956245T3 (es) 2023-12-15

Family

ID=65685644

Family Applications (1)

Application Number Title Priority Date Filing Date
ES19205507T Active ES2956245T3 (es) 2018-10-30 2019-10-25 Elemento multiconfiguración seguro y método asociado

Country Status (4)

Country Link
US (1) US11039318B2 (es)
EP (1) EP3648491B1 (es)
ES (1) ES2956245T3 (es)
FR (1) FR3087917B1 (es)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2945143B1 (fr) * 2009-05-04 2012-07-06 Bnp Paribas Procede et systeme d'activation d'applications de paiement sans contact
US9461996B2 (en) * 2010-05-07 2016-10-04 Citrix Systems, Inc. Systems and methods for providing a single click access to enterprise, SAAS and cloud hosted application
US8965827B2 (en) * 2011-03-30 2015-02-24 Computer Sciences Corporation Rules execution platform system and method
KR20130012243A (ko) * 2011-07-08 2013-02-01 주식회사 케이티 특수 권한 기반의 내장 ｓｉｍ의 ｍｎｏ 변경방법 및 그를 위한 내장 ｓｉｍ과 기록매체

Also Published As

Publication number Publication date
FR3087917B1 (fr) 2020-10-30
US11039318B2 (en) 2021-06-15
EP3648491A1 (fr) 2020-05-06
US20200137565A1 (en) 2020-04-30
EP3648491B1 (fr) 2023-06-28
FR3087917A1 (fr) 2020-05-01

Similar Documents

Publication Publication Date Title
ES2708696T3 (es) Método para el cambio del operador de red móvil en una SIM integrada basado en un privilegio especial
CN103460186B (zh) 用于更新数据载体的方法
ES2702470T3 (es) Objeto portátil seguro
US8959340B2 (en) Method for accessing and transferring data linked to an application installed on a security module associated with a mobile terminal, and associated security module, management server and system
KR20190131712A (ko) 복수의 프로세서들과 연결된 보안 모듈의 제어 방법 및 이를 구현한 전자 장치
US9980128B2 (en) Method for modifying rights to security domain for smartcard, and server, smartcard, and terminal for same
CN111125795B (zh) 用于集成电路卡的防篡改设备
ES2778697T3 (es) Servidor de seguridad de soporte lógico
KR20130006257A (ko) 내장 ｓｉｍ에서의 키 관리방법, 및 그를 위한 내장 ｓｉｍ과 기록매체
ES2409807A2 (es) Método para gestionar comunicación sin contacto en un dispositivo de usuario
WO2009066271A2 (en) Virtual security access module
ES2956245T3 (es) Elemento multiconfiguración seguro y método asociado
ES2216947T3 (es) Transportador de datos portatil y procedimiento de utilizacion del mismo en una serie de aplicaciones.
ES2925180T3 (es) Configuración de un módulo de identidad de abonado incorporado
EP3456075B1 (en) Method of managing a secure element
CN105790946B (zh) 建立数据通道的方法、系统及相关设备
CN107851044B (zh) 适于从第一应用传送第一数据以供第二应用使用的集成电路卡
US8978050B2 (en) Program calling method, and mobile device
JP6305284B2 (ja) 携帯可能電子装置
KR102319834B1 (ko) 몇 개의 소프트웨어 컨테이너들을 포함하는 변조 방지 디바이스에서 권한들을 관리하는 방법
US20240129743A1 (en) Method for personalizing a secure element
EP4134858A1 (en) Management of applications on multiple secure elements
JP6421648B2 (ja) セキュア化パケットのセキュリティ確認方法，ｕｉｃｃおよびコンピュータプログラム
CN118246040A (zh) 电子设备的保护
JP2018116724A (ja) 携帯可能電子装置