Brevet FR3087917A1 — publié le 20200501

DOMAINE DE L'INVENTION La présente invention concerne un élément sécurisé, par exemple utilisé dans un terminal hôte d'utilisateur. CONTEXTE DE L'INVENTION Un élément sécurisé, SE, est un composant ou plate-forme matérielle inviolable (typiquement une puce ou une carte à puce) utilisée dans un terminal hôte (typiquement un terminal mobile) et capable d'héberger, de façon sûre, des applications et des données en conformité avec des règles et des exigences de sécurité fixées par des autorités de confiance. Il est classiquement utilisé comme élément esclave d'applications résidentes sur le dispositif hôte ou sur un dispositif externe (typiquement un lecteur), c'est-à-dire esclave dans une relation maître-esclave avec une application équipant le terminal hôte ou le dispositif externe. Un facteur de forme de plus en plus utilisé du SE est l'élément sécurisé embarqué, eSE (pour « embedded Secure Element »). Cet élément sécurisé embarqué est généralement soudé au terminal hôte. Les éléments sécurisés sont programmés selon les applications souhaitées. A titre d'exemple, un eSE peut former l'élément sécurisé nécessaire à de nombreux usages ou services reposant sur une communication NFC (Near Field Communication) mis en oeuvre par un terminal mobile hôte. Par exemple, un service de paiement NFC nécessite des informations bancaires secrètes de l'utilisateur qui sont avantageusement stockées dans l'eSE, à l'abri de tout accès intempestif. C'est aussi le cas d'un service de transport public où l'eSE permet d'identifier l'utilisateur auprès de portiques. Un autre exemple d'élément sécurisé est l'UICC embarquée (pour « Universal Integrated Circuit Card ») qui procure les références d'un abonné pour s'authentifier sur un réseau de téléphonie mobile. Il s'agit par exemple d'un eSE configuré comme une carte SIM (pour « Subscriber Identity Module » - ou module d'identité d'abonné). On parle alors d'eUICC (pour embedded Universal Integrated Circuit Card). Pour faciliter le déploiement de ces multiples applications, on a cherché à faciliter la collaboration entre les fabricants d'éléments sécurisés et les fournisseurs de services. A cette fin, le standard GlobalPlatform a été mis en place. La version actuelle de ce standard est la version 2.3. Dans le cadre de ce standard, plusieurs configurations de SE ont été définies, par exemple une configuration UICC (GlobalPlatform UICC Configuration v2.0) décrivant le comportement du SE pour une application de téléphonie mobile, une configuration eSE 2 (GlobalPlatform Card Secure Element Configuration v1.0 ) décrivant le comportement du SE pour des applications sans contact généralement, une configuration de carte d'identité (GlobalPlatform Card ID Configuration v1.0) décrivant le comportement du SE pour des applications d'identification. 5 Toutes ces configurations définissent comment le SE doit réagir aux commandes qu'il reçoit de l'application maître ou des applications maîtres du terminal hôte. Elles mettent chacune en oeuvre un unique domaine de sécurité d'émetteur (ou principal ou racine), connu sous l'appellation d'ISD (pour « Issuer Security Domain L'ISD est une application de gestion de sécurité accessible par le seul émetteur du 10 SE, grâce à un secret (généralement un jeu de clés cryptographiques) connu de lui seul. Il peut être personnalisé au travers d'opérations de gestion de contenu qui font évoluer son contenu. Par exemple, il peut instancier, en son sein, d'autres domaines de sécurité, dits supplémentaires, accessibles par des fournisseurs de services grâce à des secrets 15 (généralement des clés cryptographiques) propres à chaque domaine et connus du seul fournisseur associé à un domaine. Il peut également installer des fichiers et des applications dans ces différents domaines de sécurité. De façon connue, un eSE configuré pour des applications NFC et soudé à un 20 terminal hôte comprend un ISD représentant le fabricant du terminal hôte, lequel autorise, par l'instanciation de domaines de sécurité supplémentaires, l'installation d'applications de paiement sans contact, d'applications de transport sans contact, provenant de différents fournisseurs. Egalement, un SE configuré comme UICC ou eUICC détenue par un opérateur de 25 téléphonie mobile peut permettre, via l'instanciation de domaines de sécurité supplémentaires dans son ISD, le chargement de différents profils de téléphonie mobile pour accéder, avec par exemple des tarifications différentes, à son ou ses réseaux mobiles. Il est classique que ces différentes configurations (NFC et UICC) soient utilisées par un même utilisateur. Il serait donc préférable de les avoir sur un unique terminal hôte (son 30 téléphone portable par exemple). RESUME DE L'INVENTION Prévoir deux (ou plus) SEs au sein du terminal hôte n'est cependant pas une solution économiquement acceptable. On cherche ainsi à permettre la cohabitation de ces 35 différentes configurations au sein d'un même SE. De même prévoir une configuration mixte capable de supporter des applications NFC et des applications de téléphonie mobile n'apparaît pas acceptable. D'une part, comme ces deux « mondes » sont mis en oeuvre par des propriétaires différents d'éléments sécurisés, il serait nécessaire de leur communiquer le même secret pour pouvoir accéder à l'ISD du SE. 3 Cette approche n'est pas acceptable pour des raisons évidentes de sécurité. D'autre part, une gestion comportementale complexe (en fait mixte) de la configuration mixte devrait être mise en place pour que le SE adopte le comportement « UICC » ou « eSE » selon le cas. Des développements complexes nuisent à la simplicité des SE voulue par GlobalPlatform. 5 Les inventeurs ont ainsi envisagé de permettre le chargement de deux (ou plus) configurations, via deux (ou plus) ISDs, au sein du même SE. Il existe cependant un besoin de garantir l'indépendance des configurations, tout en permettant, le cas échéant, qu'elles utilisent des ressources communes (partagées). Dans ce contexte, l'invention s'intéresse à un élément sécurisé comprenant une 10 pluralité d'applications et un environnement d'exécution pour l'exécution des applications, l'environnement d'exécution étant configuré pour recevoir une commande sur une interface de communication avec l'extérieur de l'élément sécurisé, pour déterminer une application cible pour l'exécution de la commande et pour transmettre, sur l'interface de communication, une réponse à la commande reçue de l'application cible. 15 Selon l'invention, l'élément sécurisé est caractérisé en ce qu'il comprend une pluralité d'interfaces de communication, et en ce que l'environnement d'exécution est configuré pour déterminer l'application cible en fonction de l'interface de communication de réception de la commande et pour autoriser l'accès à une ressource applicative de l'élément sécurisé (c'est-à-dire une 20 ressource utilisable dans l'environnement d'exécution, typiquement une application, une interface de programmation d'application ou API ou encore un package ou fichier élémentaire ELF) pour l'exécution de la commande par l'application cible uniquement si cette ressource applicative est associée à l'interface de communication de réception de la commande. Corrélativement, l'invention concerne également un procédé de traitement dans un 25 élément sécurisé comprenant une pluralité d'interfaces de communication, une pluralité d'applications et un environnement d'exécution pour l'exécution des applications, le procédé comprenant les étapes suivantes : recevoir une commande sur une interface de communication avec l'extérieur de l'élément sécurisé, 30 déterminer une application cible pour l'exécution de la commande en fonction de l'interface de communication de réception de la commande, autoriser l'accès à une ressource applicative de l'élément sécurisé pour l'exécution de la commande par l'application cible uniquement si cette ressource applicative est associée à l'interface de communication de réception de la commande, et 35 transmettre, sur l'interface de communication, une réponse à la commande reçue de l'application cible. Ainsi, autant de « mondes » indépendants peuvent être mis en oeuvre qu'il y a d'interfaces de communication. En effet, l'environnement d'exécution selon l'invention, par exemple au niveau d'une machine virtuelle Java Card (nom commercial) comme décrit par la 4 suite, permet la ségrégation des ressources applicatives disponibles en fonction des interfaces de communication et donc le cloisonnement des « mondes ». Il est ainsi possible de mettre en oeuvre deux ou plusieurs ISD indépendants, et donc deux ou plusieurs configurations de SE indépendantes, en utilisant des interfaces de 5 communication distinctes. Un SE ainsi obtenu peut faire cohabiter plusieurs propriétaires sans qu'ils n'aient à partager un secret, par exemple un opérateur MNO et un fabricant du terminal hôte gérant, respectivement, des aspects cUICC et des aspects eSE de façon indépendante. Des caractéristiques optionnelles de modes de réalisation de l'invention sont 10 définies dans les revendications dépendantes. Dans un mode de réalisation, l'élément sécurisé comprend au moins deux applications de gestion de sécurité définissant deux domaines de sécurité d'émetteur, chaque domaine de sécurité d'émetteur étant associé à une interface de communication différente. En effet, les « configurations » telles que définies par GlobalPlatform sont mises en oeuvre par 15 l'instanciation d'une application première ou principale dite ISD. Aussi, cette disposition permet la mise en oeuvre de plusieurs configurations par le biais de plusieurs ISDs correspondants. Selon une caractéristique particulière, un premier domaine de sécurité d'émetteur est associé à une interface de communication avec contact, par exemple de type ISO/IEC 7816, et un second domaine de sécurité d'émetteur est associé à une interface de 20 communication sans contact, par exemple de type ISO/IEC 14443. Cela permet de distinguer, de façon aisée, deux configurations principales du standard GlobalPlatform. Selon une autre caractéristique particulière, l'environnement d'exécution est configure pour gérer un registre d'état de vie pour chacun des deux domaines de sécurité d'émetteur. Ces états de vie selon GlobalPlatform incluent les états OP_READY, INITIALIZED, 25 SECURED, CM_LOCKED et TERMINATED. Cette disposition permet de gérer l'unique élément sécurisé physique comme une pluralité d'éléments sécurisés apparents, chacun régi par l'ISD d'une configuration chargée. Selon encore une autre caractéristique particulière, un domaine de sécurité et des ressources applicatives associées sont conformes à une des configurations définies par 30 GlobalPlatform (par exemple, configuration eSE, configuration UICC, une configuration carte d'identité, ...). Par exemple, un domaine de sécurité d'émetteur et des ressources applicatives associées sont conformes à la configuration eSE du standard GlobalPlatform. De même (en variante ou en combinaison), un domaine de sécurité d'émetteur et des ressources applicatives associées sont conformes à la configuration UICC du standard GlobalPlatform. L'élément 35 sécurisé ainsi obtenu est conforme au standard GlobalPlatform. Dans un autre mode de réalisation, l'environnement d'exécution comprend un registre associant, à chacune d'une pluralité de ressources applicatives, un identifiant d'application (AID) propre à la ressource applicative et un indicateur représentatif d'une interface de communication associée (et donc d'un ISD ou « monde » associé). Les deux 5 informations peuvent ainsi constituer un identifiant unique pour chaque ressource applicative, conforme aux exigences du standard GlobalPlatform. Selon une caractéristique particulière, le registre comporte au moins une ressource applicative associée à un indicateur commun à plusieurs interfaces de communication. Une 5 telle ressource est donc partagée entre différents « mondes ». Il peut s'agir par exemple de fichiers chargés élémentaires (ELF) communs à plusieurs configurations, chacune d'entre elles pouvant instancier par exemple une application à partir des ELFs communs. Celle disposition permet de réduire la consommation mémoire. Par exemple, les ELFs communs, ou toute autre ressource applicative commune, 10 peut être stockée dans un domaine sécurisé dédié (ou bien encore dans un domaine ISD déjà présent) et visibles dans/par tous les domaines instanciés sur l'élément sécurisé. « visible » signifie ici une accessibilité aux ELFs (ou équivalent) permettant par exemple une instanciation d'une application (à partir de ces ELFs communs) dans un domaine considéré, notamment autre que celui dans lequel sont stockés (rattachés) les ELFs communs. 15 Dans un autre mode de réalisation, l'environnement d'exécution comprend une variable globale mise à une valeur représentative de l'interface de communication de réception de la commande. Cette disposition facilite la gestion de confinement de l'exécution d'une commande dans un « monde » défini par un ISD ou une configuration donnée. En effet, la valeur de cette variable peut être directement comparée à un indicateur marquant chaque 20 ressource, pour savoir si cette dernière est accessible pendant l'exécution courante. Dans un autre mode de réalisation, l'environnement d'exécution comporte un environnement d'exécution conforme au standard GlobalPlatform 2.3 et un système d'exploitation interfaçant l'environnement d'exécution conforme à GlobalPlatform 2.3 avec une plateforme matérielle de l'élément sécurisé. Cette architecture est avantageusement conforme 25 à des pratiques classiques. Dans un mode de réalisation particulier, le système d'exploitation est configuré pour transmettre, à l'environnement d'exécution conforme au standard GlobalPlatform 2.3, toute commande reçue sur une interface de communication, accompagnée d'une indication de l'interface de communication de réception. Cette indication permet à l'environnement 30 d'exécution de mettre à jour la variable globale évoquée plus haut. Selon une caractéristique particulière, le système d'exploitation (OS) comprend une variable locale mise à une valeur représentative de l'interface de communication de réception de la commande. Cette variable locale permet à l'OS de garder trace de l'interface à utiliser pour transmettre la réponse à la commande. 35 Dans un autre mode de réalisation particulier, l'environnement d'exécution conforme au standard GlobalPlatform 2.3 comporte un environnement d'exécution Java Card (nom commercial) formé d'une machine virtuelle Java Card et d'interfaces de programmation applicative Java Card, ladite machine virtuelle Java Card étant configurée pour contrôler que toute ressource applicative (module exécutable, application, API) utilisée pour l'exécution de la 6 commande par l'application cible est associée à l'interface de communication de réception de la commande. Un tel contrôle peut avantageusement être mis en oeuvre dans un module pare-feu (ou « firewall ») de la machine virtuelle. Les fonctionnalités classiques du module pare-feu Java se voient donc étendues, par la présente invention, avec ce nouveau rôle de contrôle. 5 Selon une caractéristique particulière, la machine virtuelle Java Card est configurée, à réception d'une commande accompagnée d'une indication d'interface de communication de réception, pour mettre une variable globale à une valeur représentative de l'interface de communication de réception indiquée. Selon une autre caractéristique particulière, une interface de programmation 10 applicative, API, Java Card est nativement (i.e. dès sa compilation) associée à une (ou plusieurs) interface de communication spécifique, de sorte que cette API Java Card n'est utilisée que pour l'exécution d'une commande par une application cible associée à l'interface de communication spécifique (ou l'une des interfaces associées nativement à l'API). Cette disposition permet d'améliorer la sécurité de l'élément sécurisé. 15 Dans un autre mode de réalisation particulier, l'environnement d'exécution conforme au standard GlobalPlatform 2.3 comporte une interface de programmation système dénommée OPEN dans GlobalPlatform 2.3 configure° pour déterminer l'application cible en fonction de l'interface de communication de réception de la commande. Par exemple, l'OPEN peut déterminer, en connaissant l'interface de communication, un canal logique parmi plusieurs 20 canaux logiques partageant le même numéro, mais établis dans des domaines (ou configurations) différents. Par domaine (ou configuration), on entend un ensemble ou environnement dédié à une interface considérée géré par un ISD dédié à cet ensemble ou environnement. Selon une caractéristique particulière, l'OPEN est configuré pour : 25 accéder à un registre associant, à chacune d'une pluralité de ressources applicatives, un identifiant d'application (AID) propre à la ressource applicative et un indicateur représentatif d'une interface de communication associée, et à réception d'une commande de sélection d'une application identifiée par un identifiant AID inclus dans la commande et reçue sur une interface de communication, 30 sélectionner l'application qui, dans le registre, est associée à l'identifiant AID et à l'interface de communication de réception. Cette sélection tient généralement compte de l'affectation des applications (via leur AID) aux différents canaux logiques lorsque celles-ci sont sélectionnées par une commande SELECT. 35 Dans encore un autre mode de réalisation, l'environnement d'exécution est configuré pour, à réception, sur une deuxième interface de communication, d'une deuxième commande plus prioritaire que la commande en cours d'exécution par l'application cible : 7 suspendre l'exécution de la commande par l'application cible et mémoriser une indication représentative de l'interface de communication de réception de la commande suspendue, puis déterminer une deuxième application cible pour l'exécution de la deuxième 5 commande en fonction de la deuxième interface de communication et contrôler que toute ressource applicative accédée lors de l'exécution de la deuxième commande par la deuxième application cible est associée à la deuxième interface de communication. L'exécution de la commande suspendue peut reprendre au terme de l'exécution de la deuxième commande plus prioritaire. Cela est rendu possible par la mémorisation ou 10 sauvegarde de l'information de l'interface de communication, car cette information est utilisée pour assurer le contrôle dans l'accès aux ressources applicatives. BREVE DESCRIPTION DES FIGURES D'autres particularités et avantages de l'invention apparaîtront encore dans la 15 description ci-après, illustrée par les figures ci-jointes qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures : - la figure 1 illustre, de façon schématique, un système comprenant un élément sécurisé pour la mise en oeuvre de modes de réalisation de l'invention ; - les figures 2 et 2a illustrent des exemples de registre GlobalPlatform pour la 20 mise en oeuvre de modes de réalisation de l'invention ; - la figure 3 illustre, à l'aide d'un ordinogramme, un cycle général d'un élément sécurisé selon un mode de réalisation ; - la figure 4 illustre, à l'aide d'un ordinogramme, des étapes générales réalisées par un système d'exploitation présent dans un élément sécurisé selon des modes de réalisation 25 de l'invention ; et - les figures 5a à 5e illustrent, à l'aide d'ordinogrammes, des étapes générales réalisées par un environnement d'exploitation GlobalPlatform selon des modes de réalisation de l'invention, respectivement à la réception d'une commande APDU, à la réception d'une réponse APDU et à la réception d'une requête d'accès à une ressource applicative lors de l'exécution 30 d'une commande APDU courante. DESCRIPTION DETAILLEE DE L'INVENTION La présente invention s'intéresse à la convergence de configurations, types configurations GlobalPlatform, au sein d'un même élément sécurisé, SE, typiquement un SE 35 embarqué (par soudure ou équivalent) dans un terminal hôte. Une configuration selon GlobalPlaftorm par exemple est une mise en oeuvre du standard GlobalPlatform 2.3 qui détaille le comportement du SE, et plus particulièrement de l'application principale de gestion de sécurité, autrement appelée ISD ou domaine de sécurité 8 d'émetteur dans GlobalPlatform, à diverses sollicitations ou commandes de gestion émises par le terminal hôte. Une configuration est chargée dans le SE, sous forme de package compilé définissant l'ISD, lors do la pré-personnalisation du SE. Aussi, la configuration ne change pas 5 pendant la durée de vie du SE. Soule une personnalisation du SE peut être réalisée par des opérations de gestion de contenus (par exemple chargement, suppression de données telles que dos applications ou dos profils) au sein de l'ISD. Un exemple do configuration de SE est la configuration UICC (décrite dans le document GlobalPlatform UICC Configuration v2.0) qui fournit, au sein de l'ISD, un 10 environnement neutre facilitant la gestion à distance OTA (pour « over-the-air ») de l'UICC pour fournir des services mobiles aux abonnés. La communication entre le terminal hôte et l'UICC est généralement réalisée au travers d'une interface de communication ISO par contact, typiquement selon le protocole ISO/IEC 7816. Un autre exemple de configuration de SE est la configuration eSE (décrite dans le 15 document GlobalPlatform Card Secure Element Configuration v1.0) qui, à l'instar de la configuration UICC, fournit, au sein de l'ISD, un environnement neutre pour le déploiement de services hors téléphonie mobile. Il peut s'agir d'applications de paiement sans contact, d'applications bancaires, d'applications de transport ou équivalent (passage d'un portique d'accès), etc. Dans ce cas, la communication entre le eSE et un lecteur externe (généralement 20 hors équipement hôte) peut être réalisée au travers d'une interface de communication sans contact (via un module sans contact du terminal hôte, par exemple le CLF), typiquement selon le protocole ISO/IEC 14443. Bien entendu, d'autres configurations définissant le comportement d'un ISD peuvent être envisagées dans le cadre de la présente invention, qu'elles soient déjà définies 25 par le standard GlobalPlatform ou non. Chaque configuration, via son ISD et le comportement que celui a en réponse à des sollicitations (commandos), définit donc un « monde » particulier d'élément sécurisé. Par la suite, sauf indication particulière, les termes monde », « configuration » et « ISD » sont utilisés comme synonymes. 30 On parlera notamment de c, monde » UICC pour désigner par exemple la configuration GP UICC et donc l'ISD mis en oeuvre par une telle configuration. De même on parlera de « monde » eSE pour désigner par exemple la configuration GP eSE et donc l'ISD mis en oeuvre par une telle configuration. Un objectif de la présente invention est de permettre la cohabitation fonctionnelle 35 de deux ou plus configurations au sein d'un même SE. Cette cohabitation requiert l'assurance d'une indépendance aussi forte que possible entre les configurations, c'est-à-dire entre les ISD correspondants. L'invention propose d'atteindre cet objectif en configurant l'environnement d'exécution dans lequel les applications et donc les ISDs s'exécutent, de façon appropriée. 9 L'environnement d'exécution est notamment configuré pour associer différentes interfaces de communication du SE à différentes configurations (ou ISDs) respectifs. Il est également configuré de sorte qu'une commande reçue de l'extérieur au travers d'une des interfaces de communication soit exécutée par une application de la configuration associée à l'interface sur 5 laquelle est reçue la commande, et de sorte que cette exécution par l'application ne puisse pas mettre en oeuvre une ressource applicative, telle qu'une autre application ou une API, qui ne soit pas associée à l'interface de communication considérée. Dans ce contexte, il existe un lien direct entre, d'un côté, « monde », configuration, ISD et, de l'autre côté, interface de communication. 10 Dans les exemples qui suivent, il est principalement pris l'exemple de deux configurations ou « mondes », à savoir la configuration GP UICC et la configuration GP eSE, associées respectivement à des interfaces avec contact et sans contact. Dans ces exemples toujours, pour des raisons de simplification de l'illustration, chacun(e) de ces « mondes » ou configurations ou interface de communication est identifié(e) au travers d'un identifiant IND, 15 valant par exemple « 00 » pour le REVENDICATIONS1. Elément sécurisé (100) comprenant une pluralité d'applications (190) et un environnement d'exécution (130, 150, 160) pour l'exécution des applications, l'environnement d'exécution étant configuré pour recevoir une commande (CMD) sur une interface de communication (I) avec l'extérieur (200, 300) de l'élément sécurisé, pour déterminer une application cible pour l'exécution de la commande et pour transmettre, sur l'interface de communication, une réponse (REP) à la commande reçue de l'application cible, l'élément sécurisé étant caractérisé en ce qu'il comprend une pluralité d'interfaces de communication (111, 112), et en ce que l'environnement d'exécution est configuré pour déterminer l'application cible en fonction de l'interface de communication de réception de la commande et pour autoriser l'accès à une ressource applicative de l'élément sécurisé pour l'exécution de la commande par l'application cible uniquement si cette ressource applicative est associée à l'interface de communication de réception de la commande. 2. Elément sécurisé selon la revendication 1, comprenant au moins deux applications de gestion de sécurité définissant deux domaines de sécurité d'émetteur (ISD1, ISD2, ISDn), chaque domaine de sécurité d'émetteur étant associé à une interface de communication différente (111, 112). 3. Elément sécurisé selon la revendication 2, dans lequel un premier domaine de sécurité d'émetteur (ISD1) est associé à une interface de communication avec contact (111), par exemple de type ISO/IEC 7816, et un second domaine de sécurité d'émetteur (ISD2) est associé à une interface de communication sans contact (112), par exemple de type ISO/IEC 14443. 4. Elément sécurisé selon la revendication 2, dans lequel l'environnement d'exécution est configuré pour gérer un registre (174) d'état de vie pour chacun des deux domaines de sécurité d'émetteur (ISD1, ISD2). 5. Elément sécurisé selon la revendication 2, dans lequel un domaine de sécurité d'émetteur (ISD2) et des ressources applicatives associées sont conformes à la configuration eSE du standard GlobalPlatform 2.3, et/ou un domaine de sécurité d'émetteur (ISD1) et des ressources applicatives associées sont conformes à la configuration UICC du standard GlobalPlatform 2.3. 6. Elément sécurisé selon la revendication 1, dans lequel l'environnement d'exécution (130, 150, 160) comprend un registre (174) associant, à chacune d'une pluralité de ressources applicatives, un identifiant d'application (AID) propre à la ressource applicative et un indicateur (IND) représentatif d'une interface de communication associée. 25 7. Elément sécurisé selon la revendication 6, dans lequel le registre (174) comporte au moins une ressource applicative associée à un indicateur commun à plusieurs interfaces de communication. 8. Elément sécurisé selon la revendication 1, dans lequel l'environnement 5 d'exécution (130, 150, 160) comprend une variable globale (163) mise à une valeur représentative de l'interface de communication (I, 111, 112) de réception de la commande. 9. Elément sécurisé selon la revendication 1, dans lequel l'environnement d'exécution comporte un environnement d'exécution (150) conforme au standard GlobalPlatform 2.3 et un système d'exploitation (140) interfaçant l'environnement d'exécution 10 conforme à Global Platform 2.3 avec une plateforme matérielle (110) de l'élément sécurisé. 10. Elément sécurisé selon la revendication 9, dans lequel le système d'exploitation (140) est configuré pour transmettre, à l'environnement d'exécution conforme au standard GlobalPlatform 2.3 (150), toute commande (CMD) reçue sur une interface de communication (I, 111, 112), accompagnée d'une indication (IND) de l'interface de communication de réception. 15 11. Elément sécurisé selon la revendication 9, dans lequel le système d'exploitation (140) comprend une variable locale (141) mise à une valeur représentative de l'interface de communication (I, 111, 112) de réception de la commande. 12. Elément sécurisé selon la revendication 9, dans lequel l'environnement d'exécution conforme au standard GlobalPlatform 2.3 (150) comporte un environnement 20 d'exécution Java Card (160) formé d'une machine virtuelle Java Card (161) et d'interfaces de programmation applicative Java Card (162), ladite machine virtuelle Java Card étant configurée pour contrôler que toute ressource applicative utilisée pour l'exécution de la commande (CMD) par l'application cible est associée à l'interface de communication de réception de la commande. 25 13. Elément sécurisé selon la revendication 12, dans lequel la machine virtuelle Java Card (161) est configurée, à réception d'une commande (CMD) accompagnée d'une indication (IND) d'interface de communication de réception, pour mettre une variable globale (163) à une valeur représentative de l'interface de communication de réception indiquée. 14. Elément sécurisé selon la revendication 12, dans lequel une interface de 30 programmation applicative, API, Java Card (162) est nativement associée à une interface de communication spécifique, de sorte que cette API Java Card n'est utilisée que pour l'exécution d'une commande par une application cible associée à l'interface de communication spécifique. 15. Elément sécurisé selon la revendication 9, dans lequel l'environnement d'exécution conforme au standard GlobalPlatform 2.3 (150) comporte une interface de 35 programmation système (170) dénommée OPEN dans GlobalPlatform 2.3 configurée pour 26 déterminer l'application cible en fonction de l'interface de communication de réception de la commande. 16. Elément sécurisé selon la revendication 15, dans lequel l'OPEN (171) est configuré pour : 5 accéder à un registre (174) associant, à chacune d'une pluralité de ressources applicatives (190), un identifiant d'application (AID) propre à la ressource applicative et un indicateur (IND) représentatif d'une interface de communication associée, et à réception d'une commande de sélection d'une application identifiée par un identifiant AID inclus dans la commande et reçue sur une interface de communication, 10 sélectionner l'application qui, dans le registre, est associée à l'identifiant AID et à l'interface de communication de réception. 17. Elément sécurisé selon la revendication 1, dans lequel l'environnement d'exécution (130) est configure pour, à réception, sur une deuxième interface de communication, d'une deuxième 15 d'exécution par l'application cible : suspendre l'exécution de la commande par l'application commande plus prioritaire que la commande en cours cible et mémoriser une indication représentative de l'interface de communication de réception de la commande suspendue, puis déterminer une deuxième application cible pour l'exécution de la deuxième 20 commande en fonction de la deuxième interface de communication et contrôler que toute ressource applicative accédée lors de l'exécution de la deuxième commande par la deuxième application cible est associée à la deuxième interface de communication. 18. Procédé de traitement dans un élément sécurisé (100) comprenant une pluralité d'interfaces de communication (I, 111, 112), une pluralité d'applications (190) et un 25 environnement d'exécution (130, 150, 160) pour l'exécution des applications, le procédé comprenant les étapes suivantes : recevoir (40) une commande (CMD) sur une interface de communication (I, 111, 112) avec l'extérieur (200, 300) de l'élément sécurisé, déterminer (505) une application cible pour l'exécution de la commande en 30 fonction de l'interface de communication de réception de la commande, autoriser (523) l'accès à une ressource applicative de l'élément sécurisé pour l'exécution de la commande par l'application cible uniquement si cette ressource applicative est associée à l'interface de communication de réception de la commande, et transmettre (48), sur l'interface de communication, une réponse (REP) à la 35 commande reçue de l'application cible.