FR2991082A1

FR2991082A1 - Gestion d'applications

Info

Publication number: FR2991082A1
Application number: FR1254801A
Authority: FR
Inventors: Sylvain Fromager; Louis-Philippe Goncalves; Cyrille Pepin; Igor Vujic
Original assignee: Morpho SA
Current assignee: Idemia Identity & Security France Fr
Priority date: 2012-05-24
Filing date: 2012-05-24
Publication date: 2013-11-29
Anticipated expiration: 2032-05-24
Also published as: FR2991082B1; WO2013175096A1

Abstract

La description concerne notamment un dispositif électronique agencé pour stocker des applications, pour associer plusieurs applications à un groupe, et pour associer à un groupe d'applications un paramètre de définition d'accessibilité des applications du groupe. Le dispositif comprend un circuit de traitement de commande de définition d'accessibilité d'une application. Le circuit est agencé pour définir l'accessibilité de l'application. Le circuit est de surcroît agencé, lorsque l'application appartient au groupe d'applications, pour définir l'accessibilité de toute autre application du groupe en fonction du paramètre de définition d'accessibilité des applications du groupe. La description concerne également un procédé, un programme d'ordinateur et un support de stockage correspondants.

Description

GESTION D'APPLICATIONS L'invention concerne le domaine de la gestion d'applications. L'invention concerne notamment la gestion d'applications enregistrées sur des dispositifs électroniques tels que les cartes à puce. Une carte à puce est généralement munie d'un microcontrôleur doté de mémoires. Ces mémoires peuvent comprendre une mémoire volatile, par exemple de type RAM, une mémoire non volatile réinscriptible, par exemple de type EEPROM ou Flash, et éventuellement une mémoire non volatile non réinscriptible, par exemple de type ROM. Le microcontrôleur est généralement doté d'un microprocesseur et d'une interface d'entrée sortie, qui peut être une interface à contact (par exemple via les contacts électriques d'un module de carte à puce), une interface sans contact (par exemple lorsque la carte à puce est équipée d'une antenne), ou une combinaison d'interfaces à contact et sans contact. Une carte à puce est généralement dotée d'un système d'exploitation (souvent stocké en mémoire ROM), et a souvent la capacité de contenir des applications (généralement en mémoire ROM ou Flash), telles que des applications de porte monnaie électronique, de contrôle d'accès physique, de contrôle d'accès à un réseau de communication, de sécurisation d'emails, de débit, de crédit, de fidélité, de PKI, etc. La spécification EMV (Europay MasterCard Visa) est un standard international spécifiant l'interface de communication d'une carte de paiement avec un système d'acceptation. Elle définit un mécanisme de blocage et de déblocage d'une application par un système d'acceptation afin de faire cesser toute utilisation (ou ne permettre qu'une utilisation partielle) de cette application par un porteur. Ceci peut se produire par exemple en cas de perte de la carte (on peut par exemple prévoir que lors de l'insertion dans un terminal d'une carte déclarée perdue ou volée, le terminal ait une liste des cartes perdues ou volées, et bloque automatiquement la carte si elle fait partie de cette liste), ou bien lorsqu'un nombre limite de tentatives infructueuses de saisie d'un code confidentiel de la carte a été atteint.

Il est connu d'émettre des cartes dites "co-brandées". Il s'agit par exemple de cartes de paiement disposant d'une co-marque en plus de celle de la banque émettrice. La carte co-brandée peut par exemple offrir des avantages particuliers lors d'achats chez la co-marque. Techniquement, le fait que la carte soit co-brandée peut se traduire non seulement par une personnalisation graphique différente (se traduisant par exemple par la présence de différents logos imprimés sur le corps de carte), mais également par la présence de différentes applications sur la carte. Certaines applications peuvent être conçues par une société titulaire d'une première marque (par exemple une banque, un opérateur de téléphonie mobile, un opérateur de transports publics, etc.) d'autres applications pouvant être par exemple conçues par une société titulaire d'une deuxième marque (par exemple un commerçant, une compagnie aérienne, une compagnie de chemin de fers, etc.). Le plus souvent, un émetteur unique contrôle néanmoins toutes les applications. La présence de différentes applications d'origines diverses sur une même carte à puce augmente la complexité de la gestion par un émetteur des applications d'une carte d'un porteur donné. L'émergence de cartes dites "dual interface" proposant des applications pouvant fonctionner à la fois via une interface contact et via une interface sans contact et proposant également un mécanisme d'activation et de désactivation des applications pour une interface donnée accroît également la complexité de la gestion des applications présentes dans une carte. De surcroît, les services proposés aux porteurs sont d'une quantité et d'une diversité croissantes. Ces services correspondent souvent à des applications chargées sur la carte. L'émetteur a souvent tendance à charger par précaution toutes les applications possibles lors de l'émission de la carte. Le porteur n'est cependant pas nécessairement abonné à tous ces services (ou tout simplement pas intéressé par l'ensemble des services). Les besoins du porteur en termes de services sont susceptibles d'évoluer durant la période de validité de la carte. Il est donc souhaitable, pour l'émetteur, de pouvoir gérer de façon simple l'accessibilité des applications, et notamment leur blocage et déblocage ainsi que leur activation et désactivation pour chaque interface disponible. Cependant, à l'heure actuelle, l'accessibilité de chaque application doit être contrôlée soit individuellement soit globalement, sans réelle flexibilité. La norme ISO 7816-7 permet de contrôler l'accès à des données stockées sur une carte à puce grâce au langage SCQL (Smart Card Query Language) dérivé du SQL. Cependant, cette norme ne s'intègre pas avec des applications de carte à puce existantes telles que des applications EMV, et ne s'intéresse pas spécifiquement à l'accessibilité des applications d'une carte à puce dans le contexte considéré.

L'invention vise à améliorer la situation. Un aspect de l'invention concerne un dispositif électronique agencé pour stocker des applications, pour associer plusieurs applications à un groupe, et pour associer à un groupe d'applications un paramètre de définition d'accessibilité des applications du groupe, le dispositif comprenant un circuit de traitement de commande de définition d'accessibilité d'une application, le circuit étant agencé pour définir l'accessibilité de l'application, le circuit étant de surcroît agencé, lorsque l'application appartient au groupe d'applications, pour définir l'accessibilité de toute autre application du groupe en fonction du paramètre de définition d'accessibilité des applications du groupe. Ce dispositif est avantageux en ce qu'il permet une gestion simplifiée (par groupe) de l'accessibilité de plusieurs applications (en une seule transaction, de manière transparente). Il ne nécessite pas de modifier l'interface du dispositif (ainsi, lorsque l'interface est normalisée, celle-ci n'a pas besoin d'être changée, seul le comportement du dispositif en réponse à des commandes étant modifié). Ceci est particulièrement avantageux dans le contexte de la norme EMV. Ce dispositif permet notamment de fournir des services dynamiquement sans une émission d'un nouveau dispositif. Il suffit pour cela de charger à l'avance différentes applications correspondant aux différents services envisageables, et de les rendre accessibles lorsque c'est nécessaire. Un aspect de l'invention concerne un procédé de gestion d'applications d'un dispositif électronique comprenant un groupe d'applications associé à un paramètre de définition d'accessibilité des applications du groupe, le procédé comprenant : /a/ la réception par le dispositif d'une commande de définition d'accessibilité d'une application, /b/ la définition de l'accessibilité de l'application, /c/ la vérification de l'appartenance éventuelle de l'application au groupe d'applications, /d/ en cas d'appartenance augroupe, la définition de l'accessibilité de toute autre application du groupe en fonction du paramètre de définition d'accessibilité des applications du groupe. Ce procédé est avantageux, ainsi que le dispositif selon un aspect de l'invention, notamment en ce qu'il permet une gestion simplifiée (par groupe) de l'accessibilité de plusieurs applications (en une seule transaction, de manière transparente).

Un aspect de l'invention concerne un programme d'ordinateur comprenant une série d'instructions qui, lorsqu'elles sont exécutées par un processeur, mettent en oeuvre le procédé selon un aspect de l'invention.

Un aspect de l'invention concerne un support de stockage non transitoire lisible par ordinateur stockant un programme d'ordinateur selon un aspect de l'invention. D'autres aspects, buts et avantages de l'invention apparaîtront de manière non limitative à la lecture de la description de quelques uns de ses modes de réalisation. L'invention sera également mieux comprise à l'aide des dessins, sur lesquels : - la figure 1 illustre un procédé de blocage d'application(s) ; - la figure 2 illustre trois groupes d'applications selon un mode de réalisation de l'invention ; - la figure 3 illustre le résultat d'une action de blocage d'application(s) ou d'une action de déblocage d'application(s) sur les groupes d'applications représentés sur la figure 2 ; - la figure 4 illustre un diagramme d'état montrant les différentes transitions d'état possibles pour une application selon un mode de réalisation possible ; - la figure 5 illustre un dispositif selon un mode de réalisation de l'invention. Un mode de réalisation possible concerne un dispositif électronique agencé pour stocker des applications. Le dispositif électronique peut être notamment une carte à puce (carte SIM, carte bancaire, carte de santé, permis de conduire électronique, passeport électronique, visa électronique, carte d'accès PKI, token sécurisé, clé USB sécurisée, carte mémoire, carte SecureMMC, etc.). La figure 5 illustre un exemple d'un tel dispositif (une carte à puce bancaire) ainsi qu'un terminal de paiement POS dans lequel ce dispositif peut être inséré afin de réaliser une transaction. La transaction peut être un paiement, une opération de maintenance, ou encore une mise à jour de points de fidélité (d'autres types de transactions sont évidemment envisageables). Selon un mode de réalisation, le dispositif est alimenté en énergie par l'extérieur, par exemple par un terminal POS (et ne possède pas de source d'énergie intégrée).

Selon un mode de réalisation, le dispositif comprend une mémoire (telle qu'une mémoire non volatile de type EEPROM, Flash ou ROM) stockant des applications. Ces applications peuvent être par exemple chargées dans le dispositif lors de sa fabrication. Selon un mode de réalisation, le dispositif comprend un circuit (tel qu'un processeur associé à un système d'exploitation stocké dans une mémoire non volatile) permettant de stocker des applications dans le dispositif. Ainsi, le dispositif peut soit pré-stocker (par exemple lors de la fabrication du dispositif) des applications, soit simplement disposer de fonctions pour charger (ou supprimer) des applications à la demande, soit à la fois pré-stocker des applications en mémoire et de surcroît disposer de fonctions pour ajouter d'autres applications, ou retirer des applications. Un système d'exploitation du dispositif peut ainsi comprendre des commandes de chargement d'application dans le dispositif. A titre d'exemple, les dispositifs de type carte à puce java permettent de charger des applications JavaCard. On peut ainsi, une fois le dispositif distribué à un utilisateur, charger une application dans ce dispositif en envoyant au dispositif une ou plusieurs commandes de chargement d'application prenant en paramètre d'entrée le code binaire de l'application à charger. L'application peut être par exemple une application de type applet (telle que par exemple une applet Javacard, une applet .Net, ou encore une applet Multos). L'application peut également être une application ne consistant qu'en des données (sans code exécutable), qui peut être chargée sur une carte dite "native" (ne disposant pas d'interpréteur d'applet, ou dont l'interpréteur est verrouillé après fabrication afin d'interdire tout chargement ultérieur d'applet). Par exemple, l'application peut comprendre un répertoire, tel qu'un répertoire de type DF (au sens de la norme ISO 7816-4), le DF étant identifié par exemple par un identifiant d'application (AID, de l'anglais "Application IDentifier", au sens de la norme ISO 7816-4), le DF comprenant des données pouvant être stockées par exemple dans des fichiers de type EF (au sens de la norme ISO 7816-4). Les applications peuvent être par exemple des applications de type EMV.

Le dispositif électronique est agencé pour associer plusieurs applications à un groupe. Par exemple, le dispositif peut stocker une liste chaînée de toutes les applications du même groupe. Le dispositif peut stocker plusieurs listes chaînées, s'il y a plusieurs groupes. Au lieu de la liste chaînée, le dispositif peut évidemment utiliser pour chaque groupe toute autre technique adaptée, telle qu'une liste simple, un vecteur, un tableau, etc. Les groupes peuvent comprendre des intersections, ou ne pas en avoir. Ainsi, il est possible qu'une application donnée appartienne à plusieurs groupes à la fois, ou au contraire qu'une application ne puisse appartenir qu'à au plus un groupe. Il est possible qu'une ou plusieurs applications n'appartiennent à aucun groupe et ne soient considérées que de façon isolée. Au lieu d'une liste (ou technique équivalente), il est possible d'associer à chaque application zéro, un ou plusieurs identifiants de groupe. Ainsi, une application peut n'être associée à aucun identifiant de groupe (et ainsi n'appartenir à aucun groupe), être associée à un seul identifiant de groupe (et donc appartenir à ce seul groupe), ou être associée à plusieurs identifiants de groupe (et appartenir à plusieurs groupes à la fois). Les identifiants en question peuvent être stockés dans l'application elle-même (par exemple dans un en-tête de fichier, ou dans les données de l'application, ou à la fin ou au début de ces données, ou à tout emplacement adapté), ou de manière séparée, dans un fichier associé à cette application. Selon un mode de réalisation, le dispositif comprend, en plus du groupe d'applications considéré, au moins une application qui n'est pas dans le groupe. Cette autre application se trouve soit dans un autre groupe, soit hors de tout groupe. Selon un mode de réalisation, toutes les applications du dispositif, à savoir toutes les applications du ou des groupe(s) défini(s) par le dispositif et toutes les applications qui sont hors de ce ou ces groupe(s) mais pourraient y être associées, sont de même type. Des exemples de types d'application sont par exemple, les applications de type applet Javacard, de type applet .NET, de type applet Multos, de type application EMV, ou encore de type application au sens de la norme ISO 7816-5. Tout logiciel du dispositif qui ne peut être associé à un groupe (parce qu'il n'est pas de type adapté, ou parce que son accessibilité ne peut être définie de la façon précisée ci-après) n'est alors pas une application au sens de ce mode de réalisation. Ce mode de réalisation peut être combiné avec l'un quelconque des autres modes de réalisation décrits dans la présente demande. Selon un mode de réalisation, le dispositif est agencé pour désinstaller ou supprimer des applications. La procédure de désinstallation ou suppression peut être prévue, lorsque la ou les application(s) supprimée(s) condui(sen)t à un groupe ne comprenant plus qu'une seule voire aucune application, pour supprimer le groupe ou du moins pour extraire l'éventuelle dernière application du groupe et la traiter comme une application isolée (et éventuellement conserver en parallèle un groupe vide). Un groupe peut rassembler par exemple toutes les applications issues de la même entité. Dans le cas d'une carte "co-brandée" entre une banque et une compagnie aérienne, le dispositif peut ainsi prévoir un groupe pour les applications de la compagnie aérienne, un autre groupe pour les applications de la banque, et un dernier groupe pour des applications partagées entre la banque et la compagnie aérienne. Le dispositif peut également ne prévoir que deux groupes, certaines applications (partagées entre la banque et la compagnie aérienne) appartenant aux deux groupes à la fois. D'autres classifications sont possibles. Un groupe peut rassembler les applications selon le niveau de sécurité qu'elles exigent, par exemple il est possible de prévoir un groupe d'applications très sensibles (susceptibles de dévoiler par exemple des numéros de comptes bancaires, ou de permettre des opérations sur des comptes bancaires du porteur), un groupe d'applications modérément sensibles (susceptible par exemple de dévoiler des informations sur des préférences d'utilisateur en termes de services), et un groupe d'applications non sensibles (qui ne sont susceptibles de dévoiler que des informations publiques). Toute sorte de classification autre est a priori envisageable. Le dispositif électronique est agencé pour associer à un groupe d'applications un paramètre (également qualifié d'attribut). Ce paramètre est un paramètre de définition d'accessibilité. Ce paramètre permet de définir l'accessibilité des applications du groupe. Ce paramètre peut ainsi être utilisé pour la configuration de l'accessibilité de toutes les applications du groupe. Le groupe peut comprendre plusieurs paramètres d'accessibilité afin de configurer différents aspects de l'accessibilité des applications du groupe.

Selon un mode de réalisation, le ou les paramètre(s) de définition d'accessibilité des applications du groupe est (sont) stocké(s) dans le groupe. Selon un mode de réalisation, le ou les paramètre(s) de définition d'accessibilité des applications du groupe est (sont) stocké(s) dans le dispositif, avec le groupe (mais pas dans le groupe), par exemple dans un objet distinct du groupe mais qui lui est lié. Le dispositif comprend un circuit de traitement de commande de définition d'accessibilité d'une application donnée (à distinguer d'un éventuel traitement de commande de définition d'accessibilité d'un groupe d'applications). Ce circuit peut être un circuit en électronique câblée, un circuit électronique de type FPGA ou similaire, ou encore l'association d'un processeur (tel qu'un processeur de carte à puce) avec un logiciel (tel qu'un système d'exploitation de carte à puce approprié, stocké en mémoire EEPROM, Flash ou ROM). Le circuit est agencé pour définir l'accessibilité de l'application. Ainsi, lorsque le dispositif reçoit une commande de définition d'accessibilité d'une application, le circuit peut la traiter et définir l'accessibilité de l'application en conséquence. La commande de définition d'accessibilité peut être une commande qui définit l'accessibilité d'une application à titre principal. Par exemple, il peut s'agir d'une commande de blocage de l'application qui a pour effet de bloquer l'application. Mais la commande de définition d'accessibilité peut être une commande qui ne définit l'accessibilité qu'à titre accessoire. Par exemple, il peut s'agir d'une commande d'authentification (telle qu'une commande de vérification de code PIN), qui, après un certain nombre de tentatives d'authentification erronées (par exemple après présentation de trois codes PIN qui ne correspondent pas au code PIN stocké dans le dispositif) a pour effet de bloquer l'application alors qu'elle était précédemment inaccessible (faute d'authentification correcte) mais débloquée (c'est-à-dire qu'elle serait devenue accessible sous réserve d'une authentification correcte, alors qu'elle ne peut plus devenir accessible une fois bloquée, à moins par exemple d'une invocation d'une éventuelle commande de déblocage). Le circuit est de surcroît agencé, lorsque l'application appartient au groupe d'applications, pour définir l'accessibilité de toute autre application du groupe en fonction du paramètre de définition d'accessibilité des applications du groupe. Ainsi, lorsque l'application n'appartient à aucun groupe, la commande de définition d'accessibilité peut se comporter comme une commande de définition d'accessibilité selon l'état de l'art. En revanche, le circuit comprend du code exécutable ou de l'électronique dédiée, de manière à ce que, lorsque l'application appartient à un groupe, le traitement de la commande par le circuit conduise à définir l'accessibilité de toute autre application du groupe.

Un mode de réalisation possible concerne un dispositif électronique dont le circuit de traitement de commande de définition d'accessibilité d'une application est agencé pour traiter une commande comprenant un paramètre d'identification d'une application, et pour appliquer la commande à l'application identifiée par le paramètre d'identification. La commande de définition d'accessibilité des applications d'un groupe peut par exemple comprendre un paramètre de type AID (Application IDentifier de la norme ISO 7816-4), ce qui la conduit à opérer sur l'application ayant pour AID l'AID fourni en argument.

Cependant, selon un autre mode de réalisation, la commande de définition d'accessibilité d'une application n'identifie pas explicitement l'application à laquelle elle a vocation à s'appliquer. Par exemple, une commande SELECT (selon la norme ISO 7816-4) ou SELECT_AID (selon la norme ISO 7816-4) peut avoir été invoquée préalablement afin de sélectionner l'application pertinente. La commande de définition d'accessibilité d'une application peut alors opérer sur l'application courante (l'application sélectionnée par la commande SELECT ou SELECT_AID). Un mode de réalisation possible concerne un dispositif électronique dont le circuit de traitement de commande de définition d'accessibilité d'une application est agencé pour traiter une commande comprenant un paramètre de définition d'accessibilité. Le circuit est agencé pour définir l'accessibilité des applications d'un groupe auquel appartient (éventuellement) l'application en fonction du paramètre de définition d'accessibilité. Le circuit de traitement de commande de définition d'accessibilité d'une application est de surcroît agencé, de manière conventionnelle, pour définir l'accessibilité de l'application objet de la commande en fonction de ce paramètre de définition d'accessibilité de la commande. Lorsque l'application appartient au groupe d'applications, le circuit définit l'accessibilité de toute autre application du groupe en fonction non seulement du paramètre de définition d'accessibilité des applications du groupe, mais également en fonction du paramètre de définition d'accessibilité de la commande. La commande de définition d'accessibilité d'une application peut, par exemple, comprendre un paramètre pouvant prendre les valeurs BLOCK ou UNBLOCK. Ainsi, selon la valeur du paramètre, la commande peut bloquer ou débloquer l'application considérée. Cependant, il est également possible de n'utiliser aucun paramètre de définition d'accessibilité. Par exemple, selon un mode de réalisation, le dispositif est agencé pour mettre en oeuvre deux commandes distinctes, l'une pour le blocage, l'autre pour le déblocage. Selon un autre mode de réalisation, le dispositif est agencé pour mettre en oeuvre une commande qui n'utilise pas de paramètre de définition d'accessibilité, mais qui est agencée pour vérifier l'état courant de l'application considérée. La commande est alors agencée pour faire passer l'application à l'état débloqué (si elle était bloquée), et réciproquement pour faire passer l'application à l'état bloqué (si elle était débloquée).

II est possible d'utiliser, dans une commande de définition d'accessibilité d'une application, à la fois un paramètre d'identification d'une application et un paramètre de définition d'accessibilité. Un mode de réalisation possible concerne un dispositif électronique dans lequel un paramètre de définition d'accessibilité des applications d'un groupe est un paramètre de blocage des applications du groupe, c'est-à-dire plus précisément que le circuit du dispositif est agencé pour traiter une commande de définition d'accessibilité d'une application appartenant à un groupe dont un paramètre d'accessibilité des applications du groupe est un paramètre de blocage des applications du groupe.

Le paramètre de définition d'accessibilité des applications du groupe peut prendre, par exemple, les valeurs GRP_ATTRIB_BLOCAGE, GRP_ATTRIB_DEBLOCAGE et GRP_ATTRIB_BLOCAGE_DEBLOCAGE. Dans ce cas, dans un mode de réalisation possible, toute commande de définition d'accessibilité d'une application, commande qui, lors du traitement consécutif à sa réception, induit le blocage de l'application (soit implicitement, soit compte tenu d'un paramètre de définition d'accessibilité explicite), induit le blocage de toutes les applications du groupe lorsque le paramètre de définition d'accessibilité des applications du groupe a soit la valeur GRP_ATTRIB_BLOCAGE, soit la valeur GRP_ATTRIB_BLOCAGE_DEBLOCAGE. De même, dans un mode de réalisation possible, toute commande de définition d'accessibilité d'une application, qui, lors du traitement consécutif à sa réception, induit le déblocage de l'application, induit le déblocage de toutes les applications du groupe lorsque le paramètre de définition d'accessibilité des applications du groupe a soit la valeur GRP_ATTRIB_DEBLOCAGE, soit la valeur GRP_ATTRIB_BLOCAGE_DEBLOCAGE. Enfin, dans un mode de réalisation possible, toute commande de définition d'accessibilité d'une application, qui, lors du traitement consécutif à sa réception, induit le blocage ou le déblocage de l'application, n'induit ni le blocage ni le déblocage de toute application du groupe (autre que l'application visée par la commande de définition d'accessibilité d'une application), lorsqu'aucun des paramètres de définition d'accessibilité des applications du groupe n'a une valeur qui correspond à l'une des valeurs : GRP_ATTRIB_BLOCAGE, GRP_ATTRIB_DEBLOCAGE et G R P_ATT R I B_B LOCAG E_DE BLOCAG E.

Toute application du groupe (autre que l'application visée par la commande de définition d'accessibilité d'une application) reste alors dans l'état de blocage dans lequel elle se trouvait précédemment à la réception de la commande (à moins qu'elle n'appartienne également à un autre groupe auquel appartient également l'application objet de la commande, et que cet autre groupe soit associé à des paramètres qui induisent un changement d'état de blocage). Un mode de réalisation possible concerne un dispositif électronique comprenant une interface sans contact. L'interface sans contact peut être par exemple une interface ISO 14443 ou toute interface NFC. On pourrait de la même manière utiliser une interface Wi-Fi, Bluetooth ou encore ZigBee. Selon ce mode de réalisation, un paramètre de définition d'accessibilité des applications d'un groupe (ou du moins l'un de ces paramètres) est un paramètre d'activation d'interface sans contact pour les applications du groupe. En d'autres termes, le circuit du dispositif est agencé pour traiter une commande de définition d'accessibilité d'une application appartenant à un groupe dont un paramètre d'accessibilité des applications du groupe est un paramètre d'activation d'interface sans contact pour les applications du groupe. Le paramètre de définition d'accessibilité des applications du groupe peut prendre, par exemple, les valeurs : GRP_ATTRIB_ACTIVATION_INTERFACE_CL, GRP_ATTRIB_DESACTIVATION_INTERFACE_CL, et GRP_ATTRIB_ACTIVATION_DESACTIVATION_INTERFACE_CL. Dans ce cas, dans un mode de réalisation possible, toute commande de définition d'accessibilité d'une application, commande qui, lors du traitement consécutif à sa réception, induit l'activation de l'interface sans contact pour l'application (soit implicitement, soit compte tenu d'un paramètre de définition d'accessibilité explicite), induit l'activation de l'interface sans contact pour toutes les applications du groupe lorsque le paramètre de définition d'accessibilité des applications du groupe a l'une des valeurs : GRP_ATTRIB_ACTIVATION_INTERFACE_CL et GRP_ATTRIB_ACTIVATION_DESACTIVATION_INTERFACE_CL. De cette façon, toutes les applications du groupe peuvent utiliser l'interface sans contact pour communiquer. De même, dans un mode de réalisation possible, toute commande de définition d'accessibilité d'une application, qui, lors du traitement consécutif à sa réception, induit la désactivation de l'interface sans contact pour l'application, induit la désactivation de l'interface sans contact pour toutes les applications du groupe lorsque le paramètre de définition d'accessibilité des applications du groupe a l'une des valeurs : GRP_ATTRIB_DESACTIVATION_INTERFACE_CL et GRP_ATTRIB_ACTIVATION_DESACTIVATION_INTERFACE_CL. De cette façon, plus aucune des applications du groupe ne peut utiliser l'interface sans contact pour communiquer. Enfin, dans un mode de réalisation possible, toute commande de définition d'accessibilité d'une application, qui, lors du traitement consécutif à sa réception, induit l'activation ou la désactivation de l'interface sans contact pour l'application, n'induit ni l'activation ni la désactivation de l'interface sans contact pour toute application du groupe (autre que l'application visée par la commande de définition d'accessibilité d'une application), lorsqu'aucun des paramètres de définition d'accessibilité des applications du groupe n'a une valeur qui correspond à l'une des valeurs : GRP_ATTRIB_ACTIVATION_INTERFACE_CL, GRP_ATTRIB_DESACTIVATION_INTERFACE_CL et GRP_ATTRIB_ACTIVATION_DESACTIVATION_INTERFACE_CL. Toute application du groupe (autre que l'application visée par la commande de définition d'accessibilité d'une application) reste alors dans l'état d'activation de l'interface sans contact dans lequel elle se trouvait précédemment à la réception de la commande (à moins qu'elle n'appartienne également à un autre groupe auquel appartient également l'application objet de la commande, et que cet autre groupe soit associé à des paramètres qui induisent un changement d'état d'accessibilité par interface sans contact). La commande d'activation ou de désactivation de l'interface sans contact peut être par exemple une commande conventionnelle de type PUT DATA avec le tag `DF 30' tel que spécifié dans les spécifications CB ou MasterCard (notamment M/ChipTM Advance et PayPassTM M/Chip4 v1.4). Ainsi, il n'est pas nécessaire de déroger au standard et l'on conserve l'interopérabilité. Cependant, le traitement de la commande standard est modifié puisque l'on active ou désactive le cas échéant d'autres applications que celle qui était initialement visée, simplifiant ainsi les opérations d'activation ou de désactivation grâce à une définition adaptée de groupes d'applications. L'interface sans contact du dispositif peut (notamment lorsque le dispositif est une carte à puce de paiement) être utilisée par exemple pour le paiement de faibles montants par un porte monnaie électronique sans contact, ou encore pour le paiement de billets de transports en commun en mode sans contact. Certains modes de réalisation de l'invention permettent ainsi de désactiver simplement l'interface sans contact pour plusieurs applications, par exemple en prévision de l'expédition du dispositif (par exemple une carte à puce). Ainsi, durant le transport du dispositif (par exemple dans une enveloppe postale), il n'est pas possible d'accéder aux applications considérées, alors que sans désactivation cela pourrait être possible sans même avoir à ouvrir l'enveloppe. Il est possible de prévoir par exemple qu'à la première utilisation en mode contact, ou à la première utilisation en mode sans contact à l'aide d'une application prévue à cet effet et dont l'interface sans contact n'est pas désactivée, les interfaces sans contact des applications considérées soient réactivées. Par exemple, dans le cas d'un porte monnaie électronique (tel qu'un porte monnaie électronique de type allemand Geldkarte, français Moneo, belge Proton, ou Hongkongais Octopus), un serveur (tel qu'un serveur de paiement e-Moneo) peut être modifié de manière à définir les applications appartenant à un même groupe, et peut être programmé de manière à définir le ou les paramètre(s) de définition d'accessibilité des applications du groupe. Lors de l'utilisation d'une carte bancaire, il est connu pour un terminal de paiement de demander à un serveur bancaire un script APDU (c'est-à-dire une série de commandes selon la norme ISO 7816-4) que le terminal peut faire exécuter par le dispositif. Le script peut par exemple comprendre une commande PUT DATA avec le tag `DF 30' afin de réactiver l'interface sans contact d'une application. Toutes les applications du même groupe peuvent alors voir leur interface sans contact automatiquement réactivée (selon la valeur des paramètres de définition d'accessibilité des applications du groupe), sans avoir à modifier les interfaces ni les protocoles de communication, mais seulement, le cas échéant, les données et instructions échangées afin de changer l'accessibilité des applications (les nombreux échanges de l'état de l'art étant remplacés par un seul échange). Un mode de réalisation possible concerne un dispositif électronique comprenant une interface contact. L'interface contact peut être par exemple une interface de carte à puce traditionnelle (ISO 7816-3 à cinq contacts VCC, GND, CLK, 10 et RST), une interface USB conventionnelle, ou une interface USB de carte à puce (ISO 7816-3 USB). On pourrait de la même manière utiliser toute autre interface contact de type série (RS232, etc.), de type parallèle, ou des interfaces de type réseau (Ethernet, etc.), des interfaces "Firewire" (IEEE 1394), PS2, etc.

Selon ce mode de réalisation, un paramètre de définition d'accessibilité des applications d'un groupe (ou du moins l'un de ces paramètres) est un paramètre d'activation d'interface contact pour les applications du groupe. En d'autres termes, le circuit du dispositif est agencé pour traiter une commande de définition d'accessibilité d'une application appartenant à un groupe dont un paramètre d'accessibilité des applications du groupe est un paramètre d'activation d'interface contact pour les applications du groupe. Le paramètre de définition d'accessibilité des applications du groupe peut prendre, par exemple, les valeurs : GRP_ATTRIB_ACTIVATION_INTERFACE_CT, GRP_ATTRIB_DESACTIVATION_INTERFACE_CT, et GRP_ATTRIB_ACTIVATION_DESACTIVATION_INTERFACE_CT.

Dans ce cas, dans un mode de réalisation possible, toute commande de définition d'accessibilité d'une application, commande qui, lors du traitement consécutif à sa réception, induit l'activation de l'interface contact pour l'application (soit implicitement, soit compte tenu d'un paramètre de définition d'accessibilité explicite), induit l'activation de l'interface contact pour toutes les applications du groupe lorsque le paramètre de définition d'accessibilité des applications du groupe a l'une des valeurs : GRP_ATTRIB_ACTIVATION_INTERFACE_CT et GRP_ATTRIB_ACTIVATION_DESACTIVATION_INTERFACE_CT. De cette façon, toutes les applications du groupe peuvent utiliser l'interface contact pour communiquer. De même, dans un mode de réalisation possible, toute commande de définition d'accessibilité d'une application, qui, lors du traitement consécutif à sa réception, induit la désactivation de l'interface contact pour l'application, induit la désactivation de l'interface contact pour toutes les applications du groupe lorsque le paramètre de définition d'accessibilité des applications du groupe a l'une des valeurs : GRP_ATTRIB_DESACTIVATION_INTERFACE_CT et GRP_ATTRIB_ACTIVATION_DESACTIVATION_INTERFACE_CT. De cette façon, plus aucune des applications du groupe ne peut utiliser l'interface contact pour communiquer. Enfin, dans un mode de réalisation possible, toute commande de définition d'accessibilité d'une application, qui, lors du traitement consécutif à sa réception, induit l'activation ou la désactivation de l'interface contact pour l'application, n'induit ni l'activation ni la désactivation de l'interface contact pour toute application du groupe (autre que l'application visée par la commande de définition d'accessibilité d'une application), lorsqu'aucun des paramètres de définition d'accessibilité des applications du groupe n'a une valeur qui correspond à l'une des valeurs : GRP_ATTRIB_ACTIVATION_INTERFACE_CT, GRP_ATTRIB_DESACTIVATION_INTERFACE_CT, et GRP_ATTRIB_ACTIVATION_DESACTIVATION_INTERFACE_CT. Toute application du groupe (autre que l'application visée par la commande de définition d'accessibilité d'une application) reste alors dans l'état d'activation de l'interface contact dans lequel elle se trouvait précédemment à la réception de la commande (à moins qu'elle n'appartienne également à un autre groupe auquel appartient également l'application objet de la commande, et que cet autre groupe soit associé à des paramètres qui induisent un changement d'état d'accessibilité par interface contact). L'interface contact est utile par exemple lors de l'insertion d'un dispositif de type carte à puce dans une terminal de paiement ou dans un distributeur de billets conventionnel. Ceci est avantageux, notamment en ce que le comportement des applications est rigoureusement identique à celui prévu dans l'état de l'art. Par exemple, une application dont l'interface contact est activée (respectivement désactivée) par un procédé selon un mode de réalisation de l'invention se comporte exactement de la même manière qu'une application dont l'interface sans contact a été activée (respectivement désactivée) selon un procédé de l'état de l'art. Il en est de même pour une application dont l'interface sans contact a été activée ou désactivée, ainsi que pour une application qui a été bloquée ou débloquée. Seule la manière dont l'accessibilité de ces applications est gérée est modifiée, ce qui améliore grandement l'interopérabilité par rapport à une solution propriétaire (telle qu'une solution qui prévoirait par exemple une commande spéciale, non standard, pour changer l'accessibilité de tout un groupe d'applications).

Une même application peut être bloquée (ou débloquée), et simultanément être autorisée à accéder (ou interdite d'accès) à une interface sans contact, et simultanément être autorisée à accéder (ou interdite d'accès) à une interface contact. Lorsqu'une application est bloquée, elle peut ainsi conserver son autorisation (état "activé") ou interdiction (état "désactivé") de communiquer à travers chacune des interfaces (contact ou sans contact) qui lui sont théoriquement accessibles, et lorsque l'application est à nouveau débloquée, ses droits vis-à-vis de chacune des interfaces sont ainsi conservés. Une application peut être interdite de communications sur certaines interfaces (par exemple sur une interface sans contact) mais autorisée sur d'autres (par exemple sur une interface contact).

Réciproquement, une application désactivée vis-à-vis d'une voire de toutes les interfaces peut conserver son état de blocage. Ainsi, lorsqu'elle est réactivée, l'application se trouve dans l'état de blocage (bloquée ou débloquée) dans lequel elle se trouvait avant son éventuelle désactivation (ou du moins dans l'état de blocage dans lequel elle avait été précédemment placée).

Un groupe d'applications peut comprendre (ou être associé à) tout ou parties des paramètres suivants de définition d'accessibilité des applications du groupe : GRP_ATTRIB_BLOCAGE, GRP_ATTRIB_DEBLOCAGE, GRP_ATTRIB_BLOCAGE_DEBLOCAGE, GRP_ATTRIB_ACTIVATION_INTERFACE_CL, GRP_ATTRIB_DESACTIVATION_INTERFACE_CL, GRP_ATTRIB_ACTIVATION_DESACTIVATION_INTERFACE_CL, GRP_ATTRIB_ACTIVATION_INTERFACE_CT, GRP_ATTRIB_DESACTIVATION_INTERFACE_CT, et GRP_ATTRIB_ACTIVATION_DESACTIVATION_INTERFACE_CT. Ces paramètres sont ici représentés sous la forme de chaînes de caractères (et peuvent être utilisés sous cette forme dans un programme d'ordinateur), mais toutes autres chaînes de caractères choisies arbitrairement, ou toutes valeurs numériques arbitraires (par exemple les valeurs d'octets '00' à '08') conviendraient également. Il est également possible de prévoir d'autres paramètres de définition d'accessibilité des applications du groupe (en plus des neuf paramètres ci-dessus). La figure 4 illustre un diagramme d'état montrant les différentes transitions d'état possibles pour une application selon un mode de réalisation de l'invention, dans lequel un dispositif dispose d'une interface sans contact, qui peut être activée ou désactivée pour chaque application (certaines applications pouvant ainsi l'utiliser, d'autres non). Le dispositif dispose également de la faculté de bloquer ou débloquer une application. Selon un mode de réalisation dans lequel le dispositif prend la forme d'une carte à puce (notamment d'une carte à puce de type EMV), l'activation et la désactivation peuvent s'opérer durant les phases dites de PRÉPARATION (en anglais PERSONALIZATION) et d'UTILISATION (en anglais USER), alors que le blocage et le déblocage ne peuvent être effectués qu'en phase d'UTILISATION. Cependant, il est possible, lors de la personnalisation de la carte, de placer par défaut une application (chargée durant la personnalisation) dans un état par défaut "bloqué" ou "débloqué". Lorsqu'une application est désactivée, elle retourne un code d'erreur en réponse à une commande SELECT selon la norme ISO 7816-4. Il n'est alors pas possible d'accéder à l'application. Lorsque l'application est réactivée (après avoir été dans un état "désactivé"), elle retrouve l'état de blocage (ou déblocage) dans lequel elle se trouvait précédemment. Lorsqu'une application est bloquée, une commande SELECT sur cette application retourne un code d'erreur, cependant il reste possible d'obtenir certaines informations sur cette application.

Un mode de réalisation possible concerne un procédé de gestion d'applications d'un dispositif électronique. Le dispositif comprend un groupe d'applications. Le groupe est associé à un paramètre de définition d'accessibilité des applications du groupe.

Le procédé comprend la réception par le dispositif d'une commande de définition d'accessibilité d'une application.

Le procédé comprend la définition de l'accessibilité de l'application. Par exemple, si la commande de définition d'accessibilité d'une application était une commande de vérification de code PIN, et si c'était la troisième fois consécutive qu'un PIN erroné était présenté, le procédé peut bloquer l'application protégée par ce PIN (la rendant inaccessible). Le procédé comprend une vérification de l'appartenance éventuelle de l'application au groupe (c'est-à-dire à au moins l'un des groupes s'il y en a plusieurs). Afin de vérifier si l'application appartient à un groupe, le procédé peut, lorsque le dispositif reçoit la commande, identifier l'application concernée par cette commande (qui est indiquée soit de façon implicite soit de façon explicite). Le procédé peut alors vérifier si l'application est associée à un (ou plusieurs) identifiant(s) de groupe(s) (dans ce cas elle appartient à un ou plusieurs groupes). L'association de l'application à un identifiant de groupe peut être réalisée, par exemple, en stockant les éventuels identifiants de groupes dans l'application proprement dite, ou dans un fichier contigu formaté de manière particulière, ou dans tout autre emplacement approprié. Alternativement, pour vérifier si l'application appartient à un groupe, le procédé peut vérifier le contenu de tous les groupes à la recherche de l'application. Par exemple, chaque groupe peut prendre la forme d'une liste ou d'un vecteur stockant les identifiants des applications qu'il contient. Le procédé peut parcourir toutes les listes à la recherche d'un identifiant de l'application et reconstituer ainsi l'ensemble des groupes auxquels l'application appartient. Le procédé comprend, lorsque l'application appartient au groupe d'applications, la définition de l'accessibilité de toute autre application du groupe en fonction du paramètre de définition d'accessibilité des applications du groupe. Plus précisément, une fois que le ou les groupe(s) éventuel(s) au(x)quel(s) l'application appartient est(sont) identifié(s), le procédé peut extraire le ou les paramètre(s) de définition d'accessibilité du groupe (c'est-à- dire des applications du groupe), pour chacun des groupes. Le procédé peut alors définir l'accessibilité de toute application appartenant à l'un quelconque des groupes auxquels appartient l'application considérée (c'est-à-dire l'application faisant l'objet de la commande de définition d'accessibilité d'une application, commande qui a été reçue et traitée par le procédé).

Un mode de réalisation possible concerne un procédé dans lequel la commande de définition d'accessibilité d'une application reçue comprend un paramètre d'identification d'une application, la commande étant appliquée à l'application identifiée par le paramètre d'identification.

L'application est alors explicitement identifiée dans la commande. L'identifiant d'application est par exemple un AID ou un FID (FID est l'acronyme de "File IDentifier", et correspond à un identifiant de fichier de deux octets spécifié dans la norme ISO 7816-4), présent dans les paramètres d'entrée de la commande.

Mais l'application peut également être identifiée implicitement. L'application peut notamment avoir fait l'objet d'une sélection préalable à l'aide d'une commande SELECT selon la norme ISO 7816-4, ou être la seule application pouvant être concernée par cette commande.

Un mode de réalisation possible concerne un procédé dans lequel la commande de définition d'accessibilité d'une application reçue comprend un paramètre de définition d'accessibilité, la commande définissant l'accessibilité des applications d'un groupe auquel appartient l'application en fonction du paramètre de définition d'accessibilité de la commande.

Un mode de réalisation possible concerne un procédé dans lequel le paramètre de définition d'accessibilité des applications du groupe est un paramètre de blocage des applications du groupe. Le procédé peut alors rechercher parmi les paramètres de définition 30 d'accessibilité des applications de chaque groupe auquel appartient l'application, les paramètres qui se rapportent au blocage d'application. Ces paramètres indiquent par exemple qu'au cas où il est demandé de bloquer une application du groupe, il convient de bloquer toutes les applications du groupe. Ces paramètres indiquent également, par exemple, qu'au cas où il est demandé de débloquer une application du groupe, il convient de débloquer toutes les applications du groupe. Le procédé opère alors de la sorte. Il est possible qu'une application à laquelle la commande reçue doit être appliquée appartienne à plusieurs groupes, et qu'une autre application, 10 appartenant à l'un de ces groupes, appartienne également à au moins un autre de ces groupes. Si ces groupes sont associés à un (ou des) paramètre(s) de définition d'accessibilité des applications de groupe qui conduisent à des actions différentes, cela ne pose en général pas de problème. 15 En effet, si l'un des groupes prescrit qu'en cas de blocage d'une application du groupe, il convient de bloquer toutes les applications du groupe, alors qu'un autre groupe prescrit qu'en cas de blocage d'une application du groupe, il n'est pas nécessaire de bloquer les autres applications du groupe, alors une application, autre que l'application objet de la commande de 20 définition d'accessibilité, qui appartiendrait aux deux groupes, serait finalement bloquée, sans que cela ne soit contradictoire avec les prescriptions d'aucun des deux groupes. En effet, le fait qu'il ne soit pas nécessaire de bloquer une application n'interdit pas nécessairement le blocage de cette application. Cependant, il est concevable que deux groupes (ou plus) soient associés 25 à des prescriptions plus complexes et contradictoires, et que deux applications appartiennent chacune aux deux groupes. Par exemple, un groupe pourrait prescrire le blocage tandis que l'autre groupe prescrirait le déblocage. Ceci est concevable par exemple en cas de paramètre spécifiant qu'en cas de blocage d'une application du groupe, toutes les autres applications du groupe doivent 30 être débloquées (ou inversement qu'en cas de déblocage d'une application du groupe, toutes les autres applications du groupe doivent être bloquées).

Selon un mode de réalisation possible, les groupes sont ordonnés, par exemple selon leur ordre de création, ou selon tout ordre jugé opportun. Les prescriptions des premiers groupes (par exemple les plus anciens, ou les moins prioritaires) sont mises en oeuvre en premier, et celles des derniers groupes (par exemple ceux qui ont été créé le plus récemment, ou encore les plus prioritaires) sont mises en oeuvre en dernier (et sont donc déterminantes en cas de conflit avec des prescriptions d'autres groupes). Ainsi, une application, distincte de l'application objet de la commande reçue, et appartenant à plusieurs groupes (auxquels appartient également l'application objet de la commande reçue), pourrait être successivement bloquée puis débloquée (éventuellement plusieurs fois), dans le cadre du traitement d'une même commande de définition d'accessibilité d'une application par un procédé selon l'invention. Une banque émettrice d'une carte bancaire peut par exemple nouer des relations avec des partenaires normaux et des partenaires privilégiés. Il est ainsi possible de prévoir que lorsque le procédé active une interface pour des applications de la banque, il l'active également pour des applications des partenaires privilégiés (mais pas pour les applications des partenaires normaux), et réciproquement. Le procédé peut ainsi s'appuyer sur un groupe contenant certaines applications de la banque et certaines applications des partenaires privilégiés, et un paramètre de groupe donnant instruction au procédé d'activer toutes les applications du groupe lorsque l'une quelconque des applications du groupe est activée (pour une interface donnée). Cependant, il est également possible de prévoir que lorsque le procédé active une application sécurisée de la banque, toutes les applications non sécurisées soient désactivées. Le procédé peut ainsi s'appuyer sur un groupe comprenant les applications sécurisées de la banque ainsi que la totalité des applications non sécurisées, le groupe étant associé à un ou plusieurs paramètres précisant que lorsqu'une des applications sécurisée de la banque est activée sur une certaine interface, les applications non sécurisées doivent être désactivées sur cette même interface. Ce groupe peut entrer en conflit avec le groupe précédent, mais peut être jugé prioritaire. Ainsi, les applications du partenaire privilégié pourraient être dans un premier temps toutes activées, puis le deuxième groupe conduirait à la désactivation de celles qui ne sont pas sécurisées. Un procédé plus perfectionné pourrait être optimisé afin de s'affranchir des étapes intermédiaires d'activation et de désactivation d'une application donnée, pour ne retenir que celle(s) qui doi(ven)t être finalement mise(s) en oeuvre. Selon un mode de réalisation, le procédé met en oeuvre une notification de conflit potentiel dans le cas où des groupes, compte tenu de leur intersection non réduite à une seule application, et compte tenu de leurs paramètres de définition d'accessibilité des applications du groupe, sont susceptibles de conduire à un apparent conflit des définitions d'accessibilité. Si ce conflit est lié à une erreur (par exemple une erreur humaine lors de la définition des paramètres), le dispositif permet ainsi d'aider à la détection de telles erreurs. Mais il peut ne pas s'agir d'une erreur. Ainsi, il est concevable que des paramètres apparemment en conflit correspondent en fait à une technique permettant de définir les groupes et les paramètres de façon plus concise, ou au contraire moins concise mais plus simple à définir car plus intuitive. L'apparent conflit ne serait alors en fait que la traduction d'une simple commodité de définition des groupes.

Selon un mode de réalisation, le procédé interdit que des groupes dont l'intersection n'est pas réduite à une seule application, comportent des conflits entre paramètres de définition d'accessibilité des applications du groupe (par exemple, un paramètre d'un groupe prescrivant un blocage alors qu'un paramètre d'un autre groupe prescrit le déblocage), quand bien même il serait possible de résoudre ce conflit (par exemple en classant les groupes d'une manière précédemment exposée). Cette interdiction peut être mise en oeuvre lors de la définition des groupes ou des paramètres du groupe, c'est-à-dire que lorsque le dispositif reçoit l'instruction de créer un groupe, ou d'enregistrer un paramètre pour un groupe existant, et lorsque cette création ou cet enregistrement conduirait à une situation de conflit, le dispositif peut renvoyer un code d'erreur et ne pas traiter l'instruction. Il se peut que les groupes et leurs paramètres aient été pré-chargés lors de la fabrication du dispositif. Ceci ne laisse pas à un procédé de vérification de création de groupe (et/ou de vérification d'enregistrement de paramètre(s) de groupe) l'opportunité de s'opposer à la création de tels groupes. Dans ce cas, le dispositif peut renvoyer une erreur lorsqu'il traite une commande de définition d'accessibilité d'une application et lorsque le traitement de cette commande l'amène, compte tenu des groupes auxquels cette application appartient et des paramètres de ces groupes, à appliquer des définitions d'accessibilité contradictoires. La figure 1 illustre un procédé mettant en oeuvre le blocage d'une application d'une carte à puce EMV par un terminal. Les échanges entre la carte à puce et le terminal selon ce procédé sont identiques à ceux d'un procédé de l'état de l'art. Le procédé se distingue de l'état de l'art par le traitement de la commande de blocage. Dans ce procédé, le terminal commence par envoyer une commande SELECT à la carte. La carte lui répond en envoyant un FCI (File Control Information), ainsi qu'un mot d'état (ou "Status Word" en anglais), contenant des informations sur le déroulement de la commande SELECT. Si la commande SELECT s'est bien déroulée, le terminal envoie alors une commande GET PROCESSING OPTIONS à la carte. La carte lui répond en envoyant un AIP et un AFL, ainsi qu'un mot d'état '90 00', ce qui signifie que la commande s'est bien passée. Le terminal envoie alors une ou des commande(s) READ RECORD à la carte. La carte lui répond en renvoyant le contenu de l'enregistrement du fichier concerné, ainsi qu'un mot d'état '90 00', ce qui signifie que la 25 commande s'est bien passée. Le terminal envoie alors deux commandes GENERATE AC (la seconde mettant en oeuvre une communication en ligne) à la carte. La carte lui répond en renvoyant les cryptogrammes demandés, ainsi qu'un mot d'état '90 00' pour chaque commande, ce qui signifie que chaque commande s'est bien 30 passée. Enfin, le terminal envoie une commande APPLICATION BLOCK à la carte. La carte lui répond avec un mot d'état '90 00', ce qui signifie que la commande s'est bien passée (l'application a été bloquée à la demande du terminal). Cependant, d'autres applications ont également (le cas échéant) été bloquées ou débloquées, selon les groupes créés dans la carte à puce (ce qui n'est pas prévu dans les techniques connues de l'état de l'art). Le long protocole ci-dessus n'a donc eu besoin d'être effectué qu'une seule fois, indépendamment du nombre d'applications finalement bloquées ou débloquées. Evidemment, dans des cas plus complexes, il peut être nécessaire d'envoyer plusieurs commandes de blocage (ou de déblocage, d'activation d'interface, ou de désactivation d'interface), éventuellement à destination de plusieurs applications, pour parvenir au résultat escompté. Cependant le nombre de commandes est néanmoins réduit (il ne peut être qu'au plus égal au nombre de commandes requis par l'état de l'art).

Un mode de réalisation possible concerne un procédé dans lequel le dispositif comprend une interface sans contact, et dans lequel le paramètre de définition d'accessibilité des applications du groupe est un paramètre d'activation d'interface sans contact pour les applications du groupe. Le traitement des paramètres de définition d'accessibilité de l'interface sans contact par les applications du groupe peut s'opérer d'une façon semblable à ce qui a été décrit ci-dessus vis-à-vis des paramètres de blocage et de déblocage. En particulier, les conflits éventuels pouvant apparaître en cas d'appartenance de l'application à plusieurs groupes dont l'intersection ne se réduit pas à cette application peuvent être réglés comme indiqué précédemment (par exemple par une gestion des priorités, ou par un envoi de messages d'erreur). Un mode de réalisation possible concerne un procédé dans lequel le dispositif comprend une interface contact, et dans lequel le paramètre de 30 définition d'accessibilité des applications du groupe est un paramètre d'activation d'interface contact pour les applications du groupe.

Le traitement des paramètres de définition d'accessibilité de l'interface contact par les applications du groupe peut s'opérer d'une façon semblable à ce qui a été décrit ci-dessus vis-à-vis des paramètres de blocage et de déblocage. En particulier, les conflits éventuels pouvant apparaître en cas d'appartenance de l'application à plusieurs groupes dont l'intersection ne se réduit pas à cette application peuvent être réglés comme indiqué précédemment (par exemple par une gestion des priorités, ou par un envoi de messages d'erreur).

Les figures 2 et 3 illustrent trois groupes d'applications, et le résultat d'une action de blocage d'application ou d'une action de déblocage d'application sur ces groupes d'applications. Le groupe 1 comprend deux applications A et D, et il est associé à un paramètre de définition d'accessibilité des applications du groupe 15 GRP_ATTRIB_BLOCAGE. Le groupe 2 comprend deux applications A (également comprise dans le groupe 1) et E, et il est associé à un paramètre de définition d'accessibilité des applications du groupe GRP_ATTRIB_BLOCAGE_DEBLOCAGE. Le groupe 3 comprend quatre applications A (également comprise dans 20 les groupes 1 et 2), B, C et D (également comprise dans le groupe 1), et il est associé à un paramètre de définition d'accessibilité des applications du groupe GRP_ATTRIB_DEBLOCAGE. La figure 3 contient deux tableaux. Le premier (tableau du haut) se rapporte à une action de blocage sur 25 l'une des applications A, B, C, D ou E (indiquée sur l'axe vertical). En réponse à cette action de blocage, certaines des applications, indiquées horizontalement dans la ligne correspondante, sont également bloquées (elles sont marquées d'un "BLO"), d'autres restent dans leur état antérieur bloqué ou débloqué (elles sont marquées d'un "-"). 30 Le deuxième (tableau du bas) se rapporte à une action de déblocage sur l'une des applications A, B, C, D ou E (indiquée sur l'axe vertical). En réponse à cette action de déblocage, certaines des applications, indiquées horizontalement dans la ligne correspondante, sont également débloquées (elles sont marquées d'un "DEB"), d'autres restent dans leur état antérieur bloqué ou débloqué (elles sont marquées d'un "-"). L'action consistant à bloquer une application (à l'aide d'une commande envoyée au dispositif) peut avoir pour conséquence le blocage des autres applications du ou des groupes au(x)quel(s) elle appartient, selon la valeur de l'attribut de blocage de ce(s) groupe(s).

Ainsi, si le procédé bloque l'application A, le procédé bloquera aussi, de manière automatique, toutes les applications des groupes qui contiennent l'application A et qui ont les attributs : GRP_ATTRIB_BLOCAGE ou GRP_ATTRIB_BLOCAGE_DEBLOCAGE. Il s'agit en l'occurrence des applications des groupes 1 et 2, à savoir, en plus de l'application A, des applications D et E. Si le procédé débloque l'application A, le procédé débloquera aussi, de manière automatique, toutes les applications des groupes qui contiennent l'application A et qui ont les attributs GRP_ATTRIB_DEBLOCAGE ou G RP_ATT RI B_B LOCAG E_DE BLOCAG E.

Il s'agit en l'occurrence des applications des groupes 2 et 3, à savoir, en plus de l'application A, des applications B, C, D et E. Lorsqu'un groupe a pour seul attribut GRPATTRIB_BLOCAGE, si le procédé bloque une application de ce groupe, le procédé bloquera aussi toutes les autres applications de ce groupe. Si le procédé débloque une application de ce groupe, les autres applications de ce groupe ne seront pas débloquées (sauf par exemple si elles appartiennent à un autre groupe contenant l'application débloquée et ayant un attribut GRP_ATTRIB_DEBLOCAGE ou GRPATTRIB_BLOCAGE_DEBLOCAGE). Lorsqu'un groupe a pour seul attribut GRPATTRIB_DEBLOCAGE, si le procédé débloque une application de ce groupe, le procédé débloquera également toutes les autres applications de ce groupe. Si le procédé bloque une application de ce groupe, les autres applications de ce groupe ne seront pas bloquées (sauf si elles appartiennent à un autre groupe contenant l'application débloquée et ayant un attribut GRP_ATTRIB_BLOCAGE ou GRP_ATTRIB_BLOCAGE_DEBLOCAGE). Lorsqu'un groupe a pour seul attribut GRP_ATTRIB_BLOCAGE_DEBLOCAGE, si le procédé bloque une application de ce groupe, le procédé bloquera également toutes les autres applications de ce groupe. Si le procédé débloque une application de ce groupe, le procédé débloquera aussi toutes les autres applications de ce groupe. Un mode de réalisation possible de l'invention concerne un programme d'ordinateur comprenant une série d'instructions qui, lorsqu'elles sont exécutées par un processeur, mettent en oeuvre le procédé selon un mode de réalisation de l'invention. Il peut s'agir en particulier d'un programme écrit dans un langage de programmation de carte à puce, tel qu'un langage assembleur de composants tels que les composants de type ST19, ST22 ou ST23 de la société STMicroelectronics, ou encore les composants SLE66 ou SLE88 de la société Infineon. Il peut également s'agir d'un langage de plus haut niveau, tel que le langage C (pour lequel il existe des compilateurs pour de très nombreux composants de cartes à puce), voire un langage d'encore plus haut niveau tel que C# ou Java. Ce programme peut être intégré à un système d'exploitation de cartes à puce conventionnel afin de permettre à la carte à puce de mettre en oeuvre un procédé selon un mode de réalisation de l'invention.

Un mode de réalisation possible concerne un support de stockage non transitoire lisible par ordinateur stockant un programme d'ordinateur selon un mode de réalisation possible de l'invention. Il peut s'agir notamment de la mémoire d'une carte à puce, telle qu'une mémoire EEPROM, Flash ou ROM.

Les modes de réalisation décrits en relation avec le procédé selon l'invention peuvent être transposés au dispositif selon l'invention, ainsi qu'aux programmes d'ordinateur et aux supports de stockage du programme selon l'invention, et réciproquement.

Claims

REVENDICATIONS1. Dispositif électronique agencé pour stocker des applications, pour associer plusieurs applications à un groupe, et pour associer à un groupe d'applications un paramètre de définition d'accessibilité des applications du groupe, le dispositif comprenant un circuit de traitement de commande de définition d'accessibilité d'une application, le circuit étant agencé pour définir l'accessibilité de l'application, le circuit étant de surcroît agencé, lorsque l'application appartient au groupe d'applications, pour définir l'accessibilité de toute autre application du groupe en fonction du paramètre de définition d'accessibilité des applications du groupe.
2. Dispositif selon la revendication 1, dont le circuit de traitement de commande de définition d'accessibilité d'une application est agencé pour traiter une commande comprenant un paramètre d'identification d'une application, et pour appliquer la commande à l'application identifiée par le paramètre d'identification.
3. Dispositif selon l'une des revendications précédentes, dont le circuit de traitement de commande de définition d'accessibilité d'une application est agencé pour traiter une commande comprenant un paramètre de définition d'accessibilité, le circuit étant agencé pour définir l'accessibilité des applications d'un groupe auquel appartient l'application en fonction du paramètre de définition d'accessibilité de la commande.
4 Dispositif selon l'une des revendications précédentes, dans lequel un paramètre de définition d'accessibilité des applications d'un groupe est un paramètre de blocage des applications du groupe.5 Dispositif selon l'une des revendications précédentes, comprenant une interface sans contact, dans lequel un paramètre de définition d'accessibilité des applications d'un groupe est un paramètre d'activation d'interface sans contact pour les applications du groupe. 6 Dispositif selon l'une des revendications précédentes, comprenant une interface contact, dans lequel un paramètre de définition d'accessibilité des applications d'un groupe est un paramètre d'activation d'interface contact pour les applications du groupe. 7. Procédé de gestion d'applications d'un dispositif électronique comprenant un groupe d'applications associé à un paramètre de définition d'accessibilité des applications du groupe, le procédé comprenant : /a/ la réception par le dispositif d'une commande de définition d'accessibilité d'une application, /b/ la définition de l'accessibilité de l'application, /c/ la vérification de l'appartenance éventuelle de l'application au groupe d'applications, /d/ en cas d'appartenance au groupe, la définition de l'accessibilité de toute autre application du groupe en fonction du paramètre de définition d'accessibilité des applications du groupe. 8. Procédé selon la revendication 7, dans lequel la commande de définition d'accessibilité d'une application reçue comprend un paramètre d'identification d'une application, la commande étant appliquée à l'application identifiée par le paramètre d'identification. 9. Procédé selon la revendication 7 ou 8, dans lequel la commande de définition d'accessibilité d'une application reçue comprend un paramètre de définition d'accessibilité, la commande définissant l'accessibilité des applications d'un groupe auquel appartient l'application en fonction du paramètre de définition d'accessibilité de la commande.10 Procédé selon l'une des revendications 7 à 9, dans lequel le paramètre de définition d'accessibilité des applications du groupe est un paramètre de blocage des applications du groupe. 11. Procédé selon l'une des revendications 7 à 10, dans lequel le dispositif comprend une interface sans contact, et dans lequel le paramètre de définition d'accessibilité des applications du groupe est un paramètre d'activation d'interface sans contact pour les applications du groupe. 12. Procédé selon l'une des revendications 7 à 11, dans lequel le dispositif comprend une interface contact, et dans lequel le paramètre de définition d'accessibilité des applications du groupe est un paramètre d'activation d'interface contact pour les applications du groupe. 13. Programme d'ordinateur comprenant une série d'instructions qui, lorsqu'elles sont exécutées par un processeur, mettent en oeuvre le procédé selon l'une des revendications 7 à 12. 14. Support de stockage non transitoire lisible par ordinateur stockant un programme d'ordinateur selon la revendication 13.