Brevet FR3037753A1 — publié le 20161223

DOMAINE DE L'INVENTION L'invention concerne le domaine général des communications et notamment des mécanismes permettant de sélectionner une application dans un élément sécurisé comportant plusieurs applications. La présente invention trouve une application particulière dans le contexte des normes régissant le domaine du logiciel embarqué, dont la norme GlobalPlatform Card, définie notamment par le document « GlobalPlatform Card Specification Version 2.2.1 » est un exemple. CONTEXTE DE L'INVENTION Un élément sécurisé (« Secure Element » selon la terminologie anglo-saxonne) peut être de type carte à puce, par exemple une carte UICC ou eUICC (pour « embedded Universal Integrated Circuit Card », soit carte de circuit intégré universelle embarquée) largement utilisée dans le domaine des réseaux mobiles sous l'appellation de carte SIM, ou de type eSE (pour « embedded Secure Element »). De façon générale un élément sécurisé peut être amovible, par exemple embarqué au sein d'un dispositif mobile portable de type carte à puce, téléphone mobile, voiture, etc, ou fixe ou portable. Il comporte au moins un microprocesseur et au moins une mémoire. Il est classique que de tels éléments sécurisés comportent une ou plusieurs applications pouvant communiquer avec l'extérieur sur un ou plusieurs canaux de communication, par exemple une application de paiement avec un terminal externe de paiement, une application de téléphonie mobile avec un terminal mobile, une application de transport urbain avec un lecteur externe du réseau urbain, etc. Une application est configurée pour traiter des commandes qu'elle reçoit d'un terminal ou dispositif externe et pour générer des réponses associées et les lui envoyer. L'intelligence et les ressources de communication de l'élément sécurisé étant limitées, seule une application est généralement active à la fois, c'est-à-dire sélectionnée pour recevoir et traiter les commandes suivantes entrantes (donc envoyées par le terminal externe) sur le canal de communication où l'activation a lieu. Pour permettre cette sélection, les normes mettent généralement en oeuvre une sélection explicite de l'application en définissant une commande de sélection d'application, généralement une version de la commande SELECT identifiant l'application à sélectionner à l'aide d'un identifiant unique d'application dénoté AID pour « Application IDentifier ». Il existe cependant des applications qui ne supportent pas le mécanisme de sélection SELECT par AID. D'autres mécanismes ont donc été développés pour pallier ce problème et permettre l'identification et la sélection implicite de telles applications dans l'élément sécurisé à 3037753 2 réception d'un message, typiquement sous forme d'APDU (unité de donnée de protocole d'application). La norme GlobalPlatform Card prévoit par exemple de définir éventuellement un algorithme de reconnaissance de message pour une application donnée lors de son installation. 5 Notamment, deux algorithmes sont proposés en variante l'un de l'autre : un algorithme de reconnaissance par chaîne de caractères et un algorithme de reconnaissance par masque binaire, comme expliqué dans la section 6.5 du document « GlobalPlatform Contactless Services Card Specification v2.2 - Amendment C Version 1.1.1 ». Ainsi, si aucune application n'est couramment sélectionnée dans l'élément sécurisé, la 10 réception d'un message déclenche l'exécution des algorithmes de reconnaissance associés aux applications. Ces applications sont testées les unes après les autres selon un ordre de priorité. Cet ordre est généralement basé sur des priorités statiques attribuées aux applications lors de leurs installations (généralement selon l'ordre d'installation). Il existe toutefois, dans la norme GlobalPlatform, un outil permettant de déclarer une 15 priorité volatile pour une seule application à la fois ou pour un groupe d'applications (dans ce cas des règles de priorité à l'intérieur de ce groupe font qu'une seule application au final aura concrètement cette affectation de priorité volatile), cette priorité volatile supplantant les priorités statiques. La priorité volatile est stockée en mémoire volatile pour la durée d'une session courante de communication jusqu'à ce que l'application passe, par exemple, soit à l'état 20 désactivé (« deactivated » en anglais) ou bien, par exemple, jusqu'à ce que l'on ait un redémarrage de la carte ou « card reset » (reset de l'interface sans contact notamment) ou bien, par exemple, jusqu'à ce que l'on ait une coupure d'alimentation de l'élément sécurisé (power off).. En cas de reconnaissance du message grâce à l'algorithme (c'est-à-dire que le 25 résultat obtenu est celui attendu : une correspondance binaire entre un motif et une partie du message pour l'algorithme de reconnaissance par chaîne de caractères ; un résultat égal à 0 pour l'algorithme de reconnaissance par masque binaire), l'application associée est sélectionnée pour exécuter le message reçu. Si aucune application n'est finalement sélectionnée, que ce soit par le mécanisme 30 explicite de sélection à l'aide de la commande SELECT ou par le mécanisme implicite de sélection à l'aide des algorithmes de reconnaissance associés aux applications installées, un processus de sélection par défaut d'une application est proposé. Dans le cadre de la norme GlobalPlatform Card, une application par défaut peut avoir été définie pour chaque canal logique sans contact, à l'aide d'un paramètre 'CF', dit de 35 sélection implicite. Cette application par défaut est alors sélectionnée pour autant qu'elle ait été déclarée comme telle (`CF'), et déclarée sélectionnable et active au sens de la norme. Un niveau supplémentaire d'application par défaut prévu dans la norme GlobalPlatform Card conduit à ce qu'en l'absence d'une application déclarée « par défaut » à l'aide du paramètre 'CF', une application (qui est unique) ayant le privilège « Card Reset » est 3037753 3 alors sélectionnée si elle existe. Le privilège « Card Reset » n'est cependant valable que sur le canal logique de base (noté '0'). Ce mécanisme de sélection d'une application dans un élément sécurisé n'est pas sans inconvénient. 5 Une infrastructure dans laquelle l'élément sécurisé et une application cible sont utilisés peut s'avérer hétérogène. Par exemple, dans une infrastructure d'un réseau de transport public, de nouveaux portiques d'accès équipés de nouveaux lecteurs peuvent être installés et cohabiter avec des lecteurs d'ancienne génération qui n'ont pas nécessairement le même format de message. Le mécanisme actuel de sélection implicite d'application ne permet 10 pas d'accepter une telle hétérogénéité, sauf à ce qu'une partie des lecteurs ne soit plus opérationnelle. Dans un contexte de flexibilité d'utilisation, il existe donc un besoin d'améliorer la sélection implicite d'applications sur un élément sécurisé. Selon la norme, le mécanisme de sélection d'une application par défaut est limité à 15 une seule application pour un canal logique, déclarée soit à l'aide du paramètre `CF', soit à l'aide du privilège « Card Reset » pour le canal logique de base. Pour permettre la désignation d'une nouvelle application par défaut, il est nécessaire de supprimer le caractère `CF' ou « Card Reset » de l'application définie couramment par défaut. Or, le paramètre `CF' ou le privilège « Card Reset » n'est pas modifiable au cours de la 20 vie de l'application installée. Il peut donc s'avérer nécessaire de supprimer cette application et d'installer la nouvelle application en configurant correctement le paramètre `CF' ou en lui attribuant le privilège « Card Reset ». Pour réaliser ces opérations, il y a lieu d'ouvrer un canal sécurisé utilisant un jeu de clés secrètes et d'exécuter une procédure sécurisée. Ces multiples opérations sont lourdes et 25 donc un frein à une gestion dynamique des applications sélectionnables par défaut dans un élément sécurisé. Dans un contexte de flexibilité d'utilisation, il existe donc un besoin d'améliorer la déclaration et la sélection d'applications par défaut sur un élément sécurisé. 30 RESUME DE L'INVENTION La présente invention vise à résoudre tout ou partie de ces inconvénients. Selon un premier aspect de l'invention, un procédé de sélection d'une application installée dans un élément sécurisé multi-applications, comprend les étapes suivantes, dans l'élément sécurisé : 35 recevoir au moins un message ; exécuter une procédure principale de sélection d'une application à partir dudit message reçu ; si aucune application n'est sélectionnée à l'issue de la procédure principale, sélectionner une application par défaut, 3037753 4 procédé dans lequel la sélection d'une application par défaut comprend les étapes suivantes, dans l'élément sécurisé : obtenir une liste ordonnée d'une ou plusieurs applications installées dans l'élément sécurisé, chaque application étant associée, en mémoire, à un paramètre de sélection respectif 5 défini dans des paramètres de protocole sans contact (par exemple identifiés par la valeur/le tag 'AO' dans GlobalPlatform) de ladite application installée conformément à la norme GlobalPlatform Card ; parcourir la liste ordonnée en vérifiant si le paramètre de sélection associé à l'application parcourue indique une première valeur prédéfinie ; 10 sélectionner l'application de plus grand ordre dont le paramètre de sélection associé indique ladite première valeur prédéfinie. Corrélativement, l'invention vise également un élément sécurisé comportant une pluralité d'applications en mémoire, ainsi que : une interface de communication configurée pour recevoir au moins un message ; 15 un module de sélection d'application configuré pour exécuter une procédure principale de sélection d'une application à partir dudit message reçu, et si aucune application n'est sélectionnée à l'issue de la procédure principale, sélectionner une application par défaut, dans lequel le module de sélection pour sélectionner une application par défaut est configuré pour : 20 obtenir une liste ordonnée d'une ou plusieurs applications installées dans l'élément sécurisé, chaque application étant associée, en mémoire, à un paramètre de sélection respectif défini dans des paramètres de protocole sans contact de ladite application installée conformément à la norme GlobalPlatform Card ; parcourir la liste ordonnée en vérifiant si le paramètre de sélection associé à 25 l'application parcourue indique une première valeur prédéfinie ; sélectionner l'application de plus grand ordre dont le paramètre de sélection associé indique ladite première valeur prédéfinie. L'invention permet alors une gestion dynamique des applications sélectionnables par défaut. Celle-ci est obtenue grâce à l'usage d'une valeur particulière dans le paramètre 30 d'algorithme de reconnaissance de la norme GlobalPlatform Card, qui permet d'indiquer, selon un ordre de priorité des applications installées, l'application par défaut à sélectionner de préférence. En effet, comme décrit par la suite, de simples opérations dynamiques d'activation/désactivation des applications ou d'affectation/désaffectation d'une priorité volatile 35 aux applications permet de définir, de façon dynamique, une application sélectionnable par défaut de façon prioritaire. D'autres caractéristiques du procédé et du dispositif selon des modes de réalisation sont décrites dans les revendications dépendantes, essentiellement à l'aide d'une terminologie 3037753 5 de procédé, transposables à l'élément sécurisé. L'élément sécurisé incorporant l'invention peut être intégré ou logé dans un système plus complexe, tel un téléphone mobile. A titre d'exemple, le téléphone mobile peut comporter une antenne de communication sans contact utilisée par l'interface de communication sans contact dont l'élément sécurisé est 5 doté. Ainsi, le message peut être reçu via une interface de communication sans contact. Dans un mode de réalisation, ladite liste d'applications est ordonnée en fonction de priorités affectées auxdites applications, une priorité statique étant affectée à chaque application lors de son installation et une priorité volatile, supérieure à toute priorité statique, 10 étant affectée, en mémoire volatile de l'élément sécurisé, à au plus une application ou à un groupe d'applications (et via des règles de priorité (comme défini par exemple dans la norme GlobalPlatform) à l'intérieur de ce groupe une seule application au final aura cette affectation), et le procédé comprend en outre une étape de modification de l'affectation de la priorité 15 volatile d'une première application ou premier groupe d'applications à une deuxième application ou deuxième groupe d'applications. Cette modification peut être effectuée juste avant une nouvelle procédure de sélection d'une application par défaut. Cette disposition illustre la gestion dynamique et souple d'une application sélectionnable par défaut qui soit favorite. En effet, la modification du caractère de 20 priorité volatile peut être réalisée à l'aide d'une simple midlet (application créé à l'aide de la plateforme MIDP Java) utilisant des API (interfaces de programmation d'application) dédiées, sans ouvrir de session sécurisée. Au contraire, les techniques connues, notamment la norme GlobalPlatform Card, ne permettent de définir, de façon obligatoire, qu'une seule application sélectionnable par défaut (par le tag 'CF') sans facilité de la modifier à la demande, si ce n'est 25 de supprimer celle-ci au travers d'opérations lourdes nécessitant l'ouverture d'une session sécurisée. Dans un mode de réalisation, toute application installée dans l'élément sécurisé présente un état parmi un état actif (ou activé ; on parle d'application activée) dans lequel l'application est sélectionnable et un état inactif (ou désactivée ; on parle d'application 30 désactivée) dans lequel l'application n'est pas sélectionnable, et le procédé comprend en outre une étape de modification de l'état de l'ensemble des applications installées, sauf une application présentant un état actif, vers l'état inactif. Ainsi toutes les applications sauf une sont désactivée. Si celle-ci présente un paramètre de sélection indiquant ladite première valeur prédéfinie, alors cette application est 35 sélectionnée par défaut. La disposition ci-dessus illustre donc encore une fois une gestion dynamique et souple des applications sélectionnables par défaut, par la simple activation/désactivation d'applications, dès lors que leurs paramètres de sélection respectifs ont été configurés au préalable pour indiquer ladite première valeur prédéfinie. 3037753 6 Dans un mode de réalisation, le procédé comprend en outre, lors du parcours de la liste ordonnée, une étape de vérification de si le paramètre de sélection associé à une application parcourue indique une deuxième valeur prédéfinie ; procédé dans lequel, s'il est vérifié que le paramètre de sélection associé à l'une des 5 applications indique ladite deuxième valeur prédéfinie, ladite sélection de l'application de plus grand ordre est désactivée. En particulier, aucune application n'est sélectionnée sur la base du critère vérifiant si le paramètre de sélection indique la première valeur prédéfinie. Cette disposition améliore la gestion dynamique des applications sélectionnables par défaut. 10 Dans un mode de réalisation, le procédé comprend la sélection d'une application prédéfinie si aucune application de plus grand ordre n'est sélectionnée à l'issue du parcours de la liste ordonnée. Dans un mode de réalisation, ledit paramètre de sélection associé à une application est identifié par la valeur '83' dans les paramètres de protocole sans contact identifiés par la 15 valeur 'AO' dans la norme GlobalPlatform Card. Dans un mode de réalisation particulier, ladite première valeur prédéfinie est formée d'un identifiant d'algorithme et d'un paramètre d'algorithme ; et ledit identifiant formant la première valeur prédéfinie est différent des identifiants '01' et '02' désignant respectivement un algorithme de reconnaissance par chaîne de caractères et un algorithme de reconnaissance 20 par masque binaire conformément à la norme GlobalPlatform Card. Selon une caractéristique particulière, la deuxième valeur prédéfinie est formée du même identifiant d'algorithme que ladite première valeur prédéfinie et d'un paramètre d'algorithme différent. Ces dispositions conservent une compatibilité avec la norme GlobalPlatform Card. 25 Selon un mode de réalisation, le message reçu est une commande SELECT[by name] définie par la spécification Javacard ou équivalent, et la procédure principale de sélection comporte la sélection d'une application identifiée dans la commande SELECT[by name] reçue, si une telle application existe dans l'élément sécurisé. 30 Le procédé amélioré de sélection d'une application par défaut selon le deuxième aspect de l'invention fait ainsi suite à une sélection explicite infructueuse d'une application dans la carte à puce. De même, selon un mode de réalisation, le message reçu est différent d'une commande SELECT[by name] définie par la sépcification Javacard ou équivalent et le 35 paramètre de sélection associé à chaque application de la liste ordonnée identifie au moins un algorithme de reconnaissance à appliquer au message reçu pour déterminer si l'application associée peut être sélectionnée, et 3037753 7 la procédure principale de sélection comporte les étapes suivantes, lors du parcours de la liste ordonnée et tant qu'aucune application n'est sélectionnée à l'aide d'un algorithme de reconnaissance : exécuter, sur le message reçu, le ou les algorithmes de reconnaissance 5 indiqués par le paramètre de sélection associé à l'application parcourue ; sélectionner l'application parcourue uniquement si le résultat de l'un des algorithmes de reconnaissance est positif. Le procédé amélioré de sélection d'une application par défaut selon le deuxième aspect de l'invention fait ainsi suite à une sélection implicite infructueuse d'une application dans 10 l'élément sécurisé. Comme indiqué plus haut, l'élément sécurisé obtient en pratique une liste ordonnée qui peut comprendre une ou plusieurs applications pour lesquelles aucun algorithme de reconnaissance n'a été défini. Dans ce cas, le paramètre de sélection peut être considéré comme nul ou vide afin de permettre la mise en oeuvre des traitements décrits par la suite. Selon une caractéristique particulière, le message reçu différent d'une commande 15 SELECT[by name] est exécuté par l'application sélectionnée. Selon un mode de réalisation, ledit message est du type unité de donnée de protocole d'application ou APDU conforme à la norme ISO 7816-4. Selon un mode de réalisation, le procédé comprend, en outre, l'étape suivante : sélectionner une application installée dans l'élément sécurisé uniquement si 20 l'application est paramétrée comme active et sélectionnable dans l'élément sécurisé, et est autorisée à accéder à une interface de communication (par exemple sans contact) de l'élément sécurisé. Selon un autre aspect, un procédé de sélection d'une application cible installée dans 25 un élément sécurisé multi-applications, comprend les étapes suivantes, dans l'élément sécurisé : a) recevoir au moins un message ; b) obtenir un paramètre de sélection associé, en mémoire, à une application cible, le paramètre de sélection indiquant au moins deux algorithmes de reconnaissance de message à 30 appliquer au message reçu pour déterminer si l'application cible peut être sélectionnée ; c) exécuter, sur le message reçu, les algorithmes de reconnaissance indiqués par le paramètre de sélection associé à l'application cible ; d) sélectionner l'application cible uniquement si le résultat de l'un des algorithmes de reconnaissance est positif. 35 Corrélativement, l'invention vise également un élément sécurisé comportant une pluralité d'applications en mémoire, ainsi que : une interface de communication configurée pour recevoir au moins un message ; un module d'obtention de paramètres configuré pour obtenir un paramètre de sélection associé, en mémoire, à une application cible, le paramètre de sélection indiquant au 3037753 8 moins deux algorithmes de reconnaissance de message à appliquer au message reçu pour déterminer si l'application cible peut être sélectionnée ; un processeur configuré pour exécuter, sur le message reçu, les algorithmes de reconnaissance indiqués par le paramètre de sélection associé à l'application cible ; 5 un module de sélection d'application configuré pour sélectionner l'application cible uniquement si le résultat de l'un des algorithmes de reconnaissance est positif. L'invention offre une plus grande flexibilité d'utilisation des applications installées dans un élément sécurisé. En effet, grâce à l'invention telle que définie ci-dessus, la sélection implicite et 10 l'utilisation d'une même application par des lecteurs hétérogènes est rendue possible dans un élément sécurisé. Cela est obtenu par la mise en oeuvre d'un nouveau paramètre de sélection indiquant au moins deux algorithmes de reconnaissance, permettant ainsi la sélection implicite de la même application selon ces algorithmes distincts, alors que les techniques connues, et notamment la norme GlobalPlatform Card, ne permettent de définir, de façon obligatoire, qu'un 15 seul algorithme de reconnaissance au maximum. D'autres caractéristiques du procédé et du dispositif selon des modes de réalisation sont décrites dans les revendications dépendantes, essentiellement à l'aide d'une terminologie de procédé, transposables au dispositif, ici un élément sécurisé. L'élément sécurisé incorporant l'invention peut être intégré ou logé dans un système plus complexe, tel un téléphone mobile. 20 A titre d'exemple, le téléphone mobile peut comporter une antenne de communication sans contact utilisée par une interface de communication sans contact dont l'élément sécurisé est doté. Selon un mode de réalisation, le procédé comprend, en outre, les étapes suivantes : obtenir une liste ordonnée d'une ou plusieurs applications installées dans l'élément 25 sécurisé incluant l'application cible, chaque application étant associée, en mémoire, à un paramètre de sélection respectif, le paramètre de sélection identifiant au moins un algorithme de reconnaissance à appliquer au message reçu pour déterminer si l'application associée peut être sélectionnée ; parcourir la liste ordonnée et exécuter les étapes c) et d) pour chaque application 30 parcourue, tant qu'aucune application n'est sélectionnée. Ce parcours de la liste conduit à récupérer le paramètre de sélection de chaque application parcourue afin d'exécuter les étapes c) et d). Cette disposition offre un mécanisme déterministe de sélection implicite d'une application parmi plusieurs applications. 35 A noter qu'en pratique, une liste ordonnée peut être obtenue, laquelle liste une ou plusieurs applications pour lesquelles aucun algorithme de reconnaissance n'a été défini. Dans ce cas, le paramètre de sélection associé est considéré comme étant vide ou nul. Selon un mode de réalisation, le procédé comprend, en outre, l'étape suivante : 3037753 9 sélectionner une application par défaut si aucune application de la liste ordonnée n'est sélectionnée à l'issue du parcours de ladite liste ordonnée. En particulier, la sélection d'une application par défaut peut comprendre, lors du parcours de la liste ordonnée, une étape de vérification de si le paramètre de sélection associé 5 à chaque application parcourue indique une première valeur prédéfinie ; et comprendre une étape de sélection de l'application de plus grand ordre (parmi l'ensemble des applications) dont le paramètre de sélection associé indique ladite première valeur prédéfinie. L'utilisation de cette première valeur prédéfinie dans une liste ordonnée permet de 10 mettre en place une gestion dynamique des applications sélectionnables par défaut, au contraire des techniques connues, notamment la norme GlobalPlatform Card, qui ne permettent de définir, de façon obligatoire, qu'une seule application sélectionnable par défaut sans facilité de la modifier à la demande. Selon une caractéristique particulière, ladite liste d'applications est ordonnée en 15 fonction de priorités affectées auxdites applications, une priorité statique étant affectée à chaque application lors de son installation et une priorité volatile, supérieure à toute priorité statique, étant affectée, en mémoire volatile de l'élément sécurisé, à au plus une application ou à un groupe d'applications (et via des règles de priorité (comme défini par exemple dans la norme GlobalPlatform) à l'intérieur de ce groupe une seule application au final aura cette 20 affectation), et le procédé comprend en outre une étape de modification de l'affectation de la priorité volatile d'une première application ou premier groupe d'applications à une deuxième application ou deuxième groupe d'applications. Cette disposition illustre la gestion dynamique et souple d'une application 25 sélectionnable par défaut qui soit favorite. En effet, la modification du caractère de priorité volatile peut être réalisée à l'aide d'une simple midlet (application créé à l'aide de la plateforme MIDP Java) utilisant des API (interfaces de programmation d'application) dédiées, sans ouvrir de session sécurisée. Au contraire, les techniques connues, notamment la norme GlobalPlatform Card, ne permettent de définir, de façon obligatoire, qu'une seule application 30 sélectionnable par défaut (par le tag 'CF') sans facilité de la modifier à la demande, si ce n'est de supprimer celle-ci au travers d'opérations lourdes nécessitant l'ouverture d'une session sécurisée. Selon une caractéristique particulière, le procédé peut comprendre en outre, lors du parcours de la liste ordonnée, une étape de vérification de si le paramètre de sélection associé 35 à une application parcourue indique une deuxième valeur prédéfinie, et s'il est vérifié que le paramètre de sélection associé à l'une des applications indique ladite deuxième valeur prédéfinie, ladite sélection de l'application de plus grand ordre est désactivée. En particulier, aucune application n'est sélectionnée sur la base du critère vérifiant si le paramètre de sélection indique la première valeur prédéfinie. 3037753 10 Cette disposition contribue à une gestion dynamique plus efficace des applications sélectionnables, en permettant notamment un basculement aisé entre la mise en oeuvre de la sélection d'une application par défaut selon l'invention et la mise en oeuvre de la sélection d'une application par défaut selon les techniques connues telles GlobalPlatform Card. 5 Par exemple, le procédé peut comprendre en outre, la sélection d'une application prédéfinie si aucune application de plus grand ordre n'est sélectionnée à l'issue du parcours de la liste ordonnée. Dans le cas de GlobalPlatform Card par exemple, il s'agit de la sélection d'une application ayant soit le paramètre `CF' pour tout canal logique, soit le privilège « Card Reset » pour le seul canal logique de base. 10 Selon un mode de réalisation de l'invention, le procédé comprend en outre la sélection d'aucune application si l'application par défaut n'est ni active, ni sélectionnable dans l'élément sécurisé, ni autorisée à accéder à une interface de communication (par exemple sans contact) de l'élément sécurisé. Cette disposition permet de ne sélectionner de façon effective qu'une application qui est apte et autorisée à traiter des messages échangés avec un lecteur externe. 15 Selon un mode de réalisation de l'invention, le procédé comprend, en outre, une étape préalable d'installation de l'application cible à réception d'une commande INSTALL conforme à la norme GlobalPlatform Card, la commande INSTALL incluant ledit paramètre de sélection associé à l'application cible. En particulier, le paramètre de sélection associé à une application peut inclure le 20 paramètre identifié par la valeur '83' dans les paramètres de protocole sans contact définis pour ladite application conformément à la norme GlobalPlatform Card. Selon une caractéristique particulière, le paramètre de sélection associé à une application inclut un unique identifiant d'algorithme et au moins un paramètre d'algorithme, parmi : 25 i) un identifiant d'algorithme égal à la valeur '01' et des paramètres associés, pour désigner un unique algorithme de reconnaissance par chaîne de caractères. Cet identifiant est conforme à la norme GlobalPlatform Card, ii) un identifiant d'algorithme égal à la valeur '02' et des paramètres associés, pour désigner un unique algorithme de reconnaissance par masque binaire. Cet identifiant est 30 conforme à la norme GlobalPlatform Card, iii) éventuellement un identifiant d'algorithme commun auxdites première et deuxième valeurs prédéfinies et un paramètre associé différentiant les deux valeurs prédéfinies. Cet identifiant est mis en oeuvre lorsque le mécanisme de sélection d'une application par défaut fait intervenir ces première et deuxième valeurs prédéfinies, 35 iv) un identifiant d'algorithme égal à une autre valeur que l'identifiant de i), ii) et iii) et des paramètres associés comprenant une liste d'identifiants d'algorithme et de paramètres associés selon i) et/ou ii) et/ou éventuellement iii). Cette valeur d'identifiant permet de définir, via les paramètres associés, par exemple au moins deux algorithmes de reconnaissance pour l'application cible ci-dessus notamment. 3037753 11 Ces diverses dispositions permettent de conserver la compatibilité avec la norme GlobalPlatform Card. Selon un mode de réalisation, ledit message est du type unité de donnée de protocole d'application ou APDU conforme à la norme ISO 7816-4. 5 Selon un mode de réalisation, ledit message est différent d'une commande SELECT[by name] définie par la spécification Javacard ou équivalent. En effet, la sélection implicite d'application a lieu lorsque la commande n'explicite pas une telle sélection. Selon un mode de réalisation, le procédé comprend, en outre, l'étape suivante : sélectionner une application installée dans l'élément sécurisé uniquement si 10 l'application est paramétrée comme active et sélectionnable dans l'élément sécurisé, et est autorisée à accéder à une interface de communication (par exemple sans contact) de l'élément sécurisé. Selon un mode de réalisation, le message reçu est exécuté par l'application sélectionnée. Le message permet ainsi de sélectionner implicitement l'application nécessaire à 15 son exécution. L'invention a également pour objet un produit programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes de l'un des procédés décrits précédemment lorsque ledit programme est exécuté sur un ordinateur. Un tel produit programme d'ordinateur selon l'invention présentant des avantages similaires à ceux exposés 20 précédemment en lien avec les procédés. BREVE DESCRIPTION DES FIGURES D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après, illustrée par les dessins ci-joints, dans lesquels : 25 - les Figures la à lc illustrent des paramètres spécifiques sans contact, renseignés dans la commande INSTALL d'une application selon la norme GlobalPlatform ; - la Figure 2 illustre, à l'aide d'un logigramme, la gestion de différents mécanismes de sélection d'une application dans un élément sécurisé selon la norme GlobalPlatform ; - la Figure 3 illustre une situation où la sélection implicite d'une application est 30 défaillante lors de la mise en oeuvre de la norme GlobalPlatform, notamment à raison d'une hétérogénéité des lecteurs accédant à l'élément sécurisé ; - la Figure 4 illustre, sur le modèle de la Figure lc, un exemple de signalisation des paramètres d'installation d'une application dans l'élément sécurisé, incorporant un mode de réalisation de l'invention ; 35 - la Figure 5 illustre l'amélioration de la sélection implicite d'une application dans la situation de la Figure 3, par la mise en oeuvre d'un mode de réalisation de l'invention ; et - les Figures 6 et 6b illustrent, à l'aide d'un logigramme, la gestion de la sélection d'une application dans l'élément sécurisé basée sur l'utilisation de la signalisation de la Figure 3, selon un mode de réalisation de l'invention. 3037753 12 DESCRIPTION DETAILLEE DE L'INVENTION Les applications fonctionnant sans contact, type NFC (pour Near Field Communication - communication par champ proche) connaissent un fort développement dans 5 le domaine des éléments sécurisés, tels les cartes à puce (UICC ou eUICC), les eSE, etc. Un lecteur émet un champ électromagnétique à proximité d'un élément sécurisé, lui-même embarqué (éventuellement de façon amovible) dans un dispositif mobile (par exemple un téléphone mobile). Le champ électromagnétique peut être détecté par une interface de communication sans contact prévue dans l'élément sécurisé, à l'aide d'une antenne de 10 communication prévue soit dans l'élément sécurisé lui-même, soit dans le dispositif mobile et reliée à l'élément sécurisé (via des contacts électriques par exemple). Un exemple d'application sans contact est celle autorisant l'accès à un réseau de transport en commun : un élément sécurisé est fourni à l'abonné lors de la souscription d'un abonnement, et permet l'accès au service de transport par exemple en passant des portiques 15 dotés de lecteurs sans contact. Aujourd'hui, un élément sécurisé dédié à un service de transport d'une ville n'est pas opérationnel dans une autre ville car le réseau de transport, l'opérateur du service, les lecteurs et l'application ne sont pas les mêmes. Compte tenu du grand nombre de services aujourd'hui accessibles, les utilisateurs 20 possèdent un grand nombre d'éléments sécurisés correspondants. Un besoin est donc né de disposer d'éléments sécurisés dans lesquels plusieurs applications sont installées. La norme GlobalPlatform Card décrit une procédure pour initier une transaction sur une interface sans contact, c'est-à-dire un échange de messages entre un lecteur sans contact et un élément sécurisé, généralement de type carte à puce sans contact, en particulier pour des 25 plateformes mobiles multi-applications. Un objectif de cette procédure est d'identifier et sélectionner l'application à utiliser, vers laquelle le trafic (les messages reçus du lecteur) est routé. Cette procédure inclut une procédure de sélection explicite d'une application et une procédure de sélection implicite d'une application, ces deux procédures étant exclusives l'une 30 de l'autre. Enfin, en cas d'échec de ces procédures principales de sélection, une procédure de sélection implicite d'une application par défaut est exécutée. En détails, la procédure de sélection explicite comporte l'envoi, par le lecteur, d'une commande SELECT comportant un identifiant d'application, AID. Cette commande, de type APDU, est définie dans la norme susvisée, mais également dans la norme ISO/IEC 7816-4. 35 A réception de la commande, l'environnement GlobalPlatform dans l'élément sécurisé (environnement dénoté « OPEN » dans la norme) localise une application cible à l'aide de l'AID, parmi une liste des applications installées. 3037753 13 Puis, l'application cible localisée devient un candidat valide pour la sélection si elle est activée (ACTIVATED selon la norme) et sélectionnable au sens de la norme GlobalPlatform, et est configurée pour accéder à l'interface sans contact. Si l'application localisée n'est pas un candidat valide, l'OPEN continue à chercher un 5 autre candidat valide. En cas de vérifications des conditions ci-dessus, l'OPEN sélectionne alors l'application cible valide. Si cette dernière refuse la sélection, l'OPEN tente de localiser une application suivante qui vérifie l'AID en retournant à l'étape ci-dessus de localisation tant que la fin de la liste n'est pas atteinte. 10 En revanche, la procédure de sélection implicite débute à réception d'un message qui est différent d'une commande identifiant explicitement l'application cible, donc différent d'une commande SELECT introduite ci-dessus. En effet, cette procédure est dédiée aux sessions ou transactions qui ne débutent pas avec une commande SELECT. Le premier message d'une session ou transaction est reçu sur un canal logique de 15 base, par exemple s'il s'agit d'un message de type APDU. En variante, le message peut être d'un autre type (non-APDU), par exemple une commande utilisée dans la norme DESFire. La procédure de sélection implicite met en oeuvre, s'il existe, un algorithme de reconnaissance de message. Pour ce faire, l'environnement GlobalPlatform de l'élément sécurisé, c'est-à-dire 20 l'OPEN, obtient une liste ordonnée d'applications installées dans l'élément sécurisé. Les applications peuvent avoir été installées en association avec la définition d'un algorithme de reconnaissance à appliquer au message pour déterminer si cette application peut être sélectionnée. La liste d'applications est ordonnée en fonction de priorités affectées auxdites 25 applications. En effet, une priorité statique est affectée à chaque application lors de son installation. En outre, une priorité volatile, supérieure à toute priorité statique, peut être affectée à au plus une application ou à un groupe d'applications (dans ce cas des règles de priorité à l'intérieur de ce groupe font qu'une seule application au final aura concrètement cette affectation de priorité volatile). Cette priorité volatile est définie à l'aide d'un paramètre en 30 mémoire volatile de l'élément sécurisé, pour la durée d'une session de communication courante. Aussi, cette priorité volatile reste valable jusqu'à ce que l'application passe, par exemple, soit à l'état désactivé (« deactivated » en anglais) ou bien, par exemple, jusqu'à ce que l'on ait un redémarrage de la carte ou « card reset » (reset de l'interface sans contact 35 notamment) ou bien, par exemple, jusqu'à ce que l'on ait une coupure d'alimentation de l'élément sécurisé (power off). Ainsi, l'OPEN parcourt la liste ordonnée pour rechercher une application qui est (i) soit sélectionnable au sens de la norme GlobalPlatform, (ii) soit ACTIVATED et configurée pour accéder à l'interface sans contact, et (iii) soit associée avec un algorithme de reconnaissance 3037753 14 de message qui fournisse un résultat positif sur le message reçu par l'élément sécurisé. L'algorithme de reconnaissance est donc exécuté sur ledit message reçu. En cas de vérification de ces conditions, l'OPEN sélectionne alors l'application. Si cette dernière refuse la sélection, l'OPEN continue le parcours de la liste tant qu'aucune 5 application n'est effectivement sélectionnée ou tant que la fin de la liste n'est pas atteinte. Tel que défini dans la norme, l'algorithme de reconnaissance de message fournit la capacité d'identifier et de sélectionner une application sans contact ne supportant pas les commandes SELECT basées sur l'AID, sur la base d'un canal logique de base de l'interface sans contact. La sélection implicite de l'application est réalisée sur le message reçu (ou une 10 partie de ce message) correspond à un jeu de paramètres définis en association avec cette application (auquel cas le résultat de l'algorithme est positif). La définition de cet algorithme et des paramètres associés est réalisée lors de l'installation de l'application correspondante. La procédure pour charger et installer une application dans l'élément sécurisé est basée sur la commande INSTALL définie dans la norme 15 susvisée. Cette commande contient un grand nombre de paramètres permettant le fonctionnement de l'application, et notamment des paramètres spécifiques à son utilisation avec l'interface sans contact. La définition de l'algorithme de reconnaissance de message fait partie de ces derniers paramètres. La Figure la représente les paramètres spécifiques sans contact, renseignés dans la 20 commande INSTALL d'une application. Ces paramètres sont listés sous forme de structure TLV (tag-length-value, pour étiquette-longueur-valeur) comprennent des paramètres de protocole sans contact, identifié par l'étiquette `A0', eux-mêmes définis sous forme de structures TLV, et représentés par la Figure lb. Parmi ces derniers, les paramètres définissant l'algorithme de reconnaissance de 25 message sont identifiés par l'étiquette '83' et définis en détails dans la section 6.5 du document « GlobalPlatform Contactless Services Card Specification v2.2 - Amendment C Version 1.1.1 ». Ces paramètres sont au format LV (length-value) comme montrés en Figure lc. Notamment, leur valeur inclut un unique identifiant d'algorithme et au moins un paramètre d'algorithme, parmi : 30 i) un identifiant d'algorithme égal à la valeur '01' et des paramètres associés, pour désigner un unique algorithme de reconnaissance par chaîne de caractères. Des détails de mise en oeuvre sont fournis sur la Figure, ii) un identifiant d'algorithme égal à la valeur '02' et des paramètres associés, pour désigner un unique algorithme de reconnaissance par masque binaire. Des détails de mise en 35 oeuvre sont fournis sur la Figure. Ce format ne permet de définir qu'un seul algorithme de reconnaissance en association avec une application que l'on installe, à l'aide de la structure TLV suivante Tag [EF] (Longueur) Tag [A0] (Longueur) Tag [83] (Longueur) [Algo ID - Algo Param] déclinable en uniquement l'une ou l'autre des deux structures TLV suivantes : 3037753 15 [EF] (Longueur) [A0] (Longueur) [83] (Longueur) [[01] [Offset] [Pattern]] [EF] (Longueur) [A0] (Longueur) [83] (Longueur) [[02] [Reference data] [Mask]] Si ni la procédure principale de sélection explicite par commande de type SELECT, ni la procédure principale de sélection implicite par algorithme de reconnaissance de message, 5 n'aboutit à la sélection effective d'une application, une procédure de sélection d'une application par défaut est mise en oeuvre. Pour ce faire, l'OPEN recherche une application installée qui est candidate pour une sélection « par défaut » quelque soit le type de l'interface. Cette application est celle qui a été installée dans l'élément sécurisé, avec un 10 paramètre de sélection implicite, noté 'CF' dans la norme GlobalPlatform, correctement déclaré pour le canal logique utilisé. En l'absence d'une telle application dotée d'un paramètre 'CF' correctement déclaré, l'application ayant un privilège « Card Reset » au sens de la norme est identifiée si le canal logique utilisé est celui de base. L'application 'CF' ou « Card Reset » ainsi identifiée devient un candidat valide pour la 15 sélection si elle est ACTIVATED, sélectionnable au sens de la norme et configurée pour accéder à l'interface sans contact. En l'absence de candidat valide pour la sélection, aucune application n'est sélectionnée. Si le canal logique utilisé est celui de base, il reste alors ouvert. Sinon, l'application est effectivement sélectionnée par l'OPEN. Si cette dernière refuse 20 la sélection, aucune application n'est sélectionnée et le canal logique, s'il est de base, reste ouvert. Bien entendu, dès lors que le canal logique de base reste ouvert sans qu'aucune application n'ait été sélectionnée, les mécanismes décrits ci-dessus sont à nouveau exécutés lorsqu'un nouveau message (par exemple une commande APDU) est reçu sur ce même canal 25 logique de base. La Figure 2 illustre, à l'aide d'un logigramme, la gestion de ces différents mécanismes de sélection d'une application dans l'élément sécurisé. L'algorithme de la Figure 2 comporte trois blocs de traitement correspondant respectivement à : 30 - une procédure principale de sélection explicite à partir d'une commande SELECT reçue. C'est le bloc 2A ; - une procédure principale de sélection implicite à l'aide d'un algorithme de reconnaissance de message. C'est le bloc 2B ; - une procédure de sélection d'une application par défaut. C'est le bloc 2C. 35 A l'étape 200, un message ou commande APDU est tout d'abord reçu sur un canal logique sans contact. A l'étape 205, il est déterminé s'il s'agit d'une commande SELECT indiquant un AID. 3037753 16 Dans l'affirmative, une liste ordonnée (selon des priorités respectives) des applications installées dans l'élément sécurisé est parcourue à l'étape 210 pour déterminer les candidats valides pour la sélection. A l'étape 215, il est déterminé si au moins un candidat valide a été identifié (s'ils sont 5 plusieurs, ils sont considérés dans l'ordre des priorités de la liste 210). Dans la négative, le traitement se poursuit à l'étape 230 décrite par la suite. Dans l'affirmative, l'OPEN procède à la sélection du candidate valide de plus haute priorité à l'étape 220. Si un refus de sélection est reçu de l'application sélectionnée (test 225), le traitement vérifie s'il reste des candidats non traités (étape 226) pour considérer le candidat 10 valide suivant (étape 227) dans l'ordre des priorités de la liste 210. L'opération de sélection 220 est alors menée sur ce nouveau candidat. S'il ne reste plus aucun candidat valide à considérer à l'étape 226, on détermine à l'étape 228 une règle courante de gestion. En effet, il peut être utilisé différentes règles de gestion. Par exemple une première règle R1 peut convenir que si tous les candidats valides 15 refusent leur sélection, on procède à la sélection d'une application par défaut selon le bloc 2C, c'est-à-dire en poursuivant le traitement à l'étape 230 décrite par la suite. Une deuxième règle R2 peut convenir que si tous les candidats valides refusent leur sélection, un message d'erreur SW=6999 est émis (étape 229). Selon cette deuxième règle, s'il existe des candidats valides, aucune sélection d'une application par défaut n'est envisagée. 20 Si aucun refus à l'étape 220 n'est reçu (sortie « oui » du test 225), l'application est effectivement sélectionnée et le traitement prend fin à l'étape 295. Dans la négative du test 205 (APDU reçu différent de la commande SELECT), la procédure de sélection implicite est menée, consistant à parcourir la liste ordonnée des applications installées lors de l'étape 235 pour déterminer les applications candidates valides 25 (dont notamment l'algorithme de reconnaissance donne un résultat positif sur le message APDU reçu à l'étape 200). De façon similaire aux étapes 215-229, ces différentes applications candidates sont testées (étapes 240 puis 250-252) à la sélection (étape 245) jusqu'à sélection effective de l'une d'entre elles (sortie 295). Si aucune sélection n'est effective alors que toutes les applications 30 candidates valides ont été testées (test 251 négatif), un message d'erreur SW=6999 est émis (étape 254) en cas d'application de la règle R2 ; sinon (application de la règle R1) le traitement se poursuit à l'étape 230 marquant le début de la procédure de sélection d'une application « par défaut ». De même si aucun candidat valide n'existe (test 240 négatif), le traitement se poursuit à l'étape 230. 35 A l'étape 230, il est alors déterminé si une application « par défaut » a été déclarée, c'est-à-dire si l'une des applications installées a été désignée comme telle par le paramètre 'CF' associé ou dispose du privilège « Card Reset ». Dans la négative, aucune application n'est finalement sélectionnée et le canal logique, si de base, reste ouvert, à l'étape 255, avant que le traitement ne prenne fin (étape 295). 3037753 17 Dans l'affirmative, l'application est testée à la sélection (étape 260). Si un refus de sélection est reçu de l'application ainsi sélectionnée (test 265), aucune application n'est finalement sélectionnée et le canal logique, si de base, reste ouvert, à l'étape 255, avant que le traitement ne prenne fin (étape 295). En revanche, si aucun refus n'est reçu (test 265 positif), 5 l'application est effectivement sélectionnée et le traitement prend fin à l'étape 295. Ces mécanismes ne sont toutefois pas satisfaisants. Il est largement connu que les infrastructures déployées deviennent généralement hétérogènes avec le temps. C'est notamment le cas d'infrastructures permettant l'accès à un service de transport public dans lesquelles les portillons d'accès munis de lecteur d'élément 10 sécurisé (pour l'abonnement) sont régulièrement mais progressivement renouvelés, mis à jour, et ne reposent pas tous sur les mêmes formats de communication (le premier message d'initiation d'une transaction peut varier d'un lecteur à l'autre). En raison de l'évolution (modification, mise à jour) de l'infrastructure, l'application correspondante embarquée dans l'élément sécurisé peut s'avérer ne plus être opérationnelle. 15 En présence de plusieurs applications dans l'élément sécurisé, la sélection implicite de l'application ad hoc par l'algorithme de reconnaissance associé devient alors excessivement délicate, en particulier du fait qu'un seul algorithme à la fois (un seul couple {identifiant d'algorithme et paramètres associés}) ne peut être défini à l'installation de l'application, limitant de fait les lecteurs opérationnels avec cette carte à puce. 20 Dans l'exemple de la Figure 3, si un premier lecteur READER 1 envoie une commande COMMAND _1 d'un premier type différent d'une commande SELECT pour sélectionner l'application de transport installée (APPLICATION 1), celle-ci doit avoir l'algorithme de reconnaissance paramétré (soit selon un motif de chaîne de caractères soit selon un masque binaire) sur cette COMMAND _1 pour que la sélection s'effectue. 25 Mais si un autre lecteur, READER 2 qui peut être un tout nouveau lecteur installé, ayant un comportement différent du premier lecteur READER 1 envoie une commande COMMAND _2 d'un type différent de COMMAND 1, pour sélectionner la même application de transport, alors cette dernière ne peut être effectivement sélectionnée puisque l'algorithme de reconnaissance n'est pas paramétré en conséquence. 30 La même situation se produit pour d'autres lecteurs, READER N, opérant selon un format (pour la commande COMMAND N) différent du lecteur READER 1. Or, la seule solution existante pour permettre de sélectionner implicitement cette application depuis un lecteur autre que READER 1 consisterait à réinstaller l'application ou à en instancier une nouvelle version en définissant cette fois-ci l'algorithme de reconnaissance 35 (c'est-à-dire les paramètres associés) en lien avec la commande du nouveau lecteur à utiliser. Cette solution paraît peu réaliste soit parce qu'il serait nécessaire de réinstaller en permanence l'application, soit parce qu'il serait nécessaire d'installer un grand nombre d'instances de la même application pour refléter l'ensemble de l'hétérogénéité de l'infrastructure, auquel cas un problème de saturation de mémoire pourrait vite survenir. 3037753 18 Il existe donc un besoin d'améliorer cette situation pour offrir une plus grande flexibilité d'utilisation des éléments sécurisés, notamment dans des contextes d'infrastructures hétérogènes à raison par exemple de déploiements en cours. D'un autre côté, la sélection implicite d'une application par défaut n'est également pas 5 satisfaisante. Le mécanisme proposé par la norme GlobalPlatform ne permet de définir qu'une unique application « par défaut » par canal logique à l'aide du paramètre `CF' (voire à l'aide du privilège « Card Reset » pour le canal logique de base), qui sera sélectionnée en cas d'échec de la procédure principale (implicite ou explicite) de sélection d'une application. 10 Toutefois, il peut être souhaitable de modifier cette application « par défaut » en fonction d'un contexte d'utilisation, ou bien dans le temps. Or, la norme GlobalPlatform ne propose aucun mécanisme permettant de basculer d'une application par défaut à une autre. Des solutions possibles seraient alors soit d'utiliser une application midlet (pour Mobile Information Device profile, c'est-à-dire un profile Java pour applications embarquées) 15 sur le dispositif mobile embarquant l'élément sécurisé, soit de désinstaller l'application déclarée « par défaut » afin d'en déclarer une nouvelle (lors d'une nouvelle installation) à l'aide du paramètre `CF'. Le recours à une application midlet requiert toutefois le stockage de certificats de l'éditeur de l'application midlet dans le dispositif mobile, ce qui est difficilement envisageable 20 pour des raisons de sécurité. L'approche par désinstallation paraît également problématique dans un contexte où la gestion dynamique des applications sur l'élément sécurisé est recherchée. Notamment, une désinstallation et réinstallation nécessite l'ouverture de sessions sécurisées, lourdes à mettre en oeuvre. 25 Il existe donc également un besoin d'améliorer cette situation pour permettre une gestion dynamique des applications sélectionnables par défaut au sein d'un élément sécurisé, qui ne soit pas lourde et complexe. Les deux besoins identifiés ci-dessus peuvent être résolu indépendamment ou ensemble par les mécanismes de l'invention tels que résumés plus haut et exposés par la suite 30 en référence à des modes de réalisation particuliers. Une solution proposée par les inventeurs est d'étendre la signalisation existante, par exemple dans GlobalPlatform, pour autoriser une flexibilité et une gestion dynamique de la sélection d'applications dans l'élément sécurisé, tout en conservant une compatibilité avec la norme actuellement définie. 35 Il est notamment proposé d'étendre le paramètre '83' définissant l'algorithme de reconnaissance de message selon GlobalPlatform (au sein des paramètres de protocole sans contact). Pour ce faire, les deux identifiants d'algorithme '01' et '02' déjà existants (Figure 1c) sont complétés d'un ou plusieurs identifiants permettant respectivement d'améliorer la sélection 3037753 19 d'applications par algorithme de reconnaissance ou d'améliorer la gestion dynamique des applications par défaut. La Figure 4 illustre, sur le modèle de la Figure lc, un exemple de signalisation des paramètres d'installation d'une application dans l'élément sécurisé (c'est-à-dire dans la 5 commande INSTALL), incorporant un mode de réalisation de l'invention où deux nouveaux identifiants d'algorithme sont introduits pour le paramètre '83'. Bien entendu d'autres modes de réalisation peuvent envisager l'introduction uniquement de l'un ou l'autre de ces deux nouveaux identifiants. Le premier identifiant d'algorithme, prenant la valeur '7E' sur la Figure (mais toute 10 autre valeur non déjà utilisée dans la norme peut convenir), permet de gérer un statut de « application sélectionnable par défaut » à l'application alors installée. En utilisant ce nouvel identifiant, il est ainsi possible de définir comme sélectionnables par défaut un grand nombre d'applications installées, et non plus uniquement une seule application (celle désignée par le paramètre `CF' ou celle ayant le privilège « Card Reset » pour le canal logique de base). En 15 outre, positionner ce paramètre et l'associer à la possibilité de jouer, par exemple, sur la priorité volatile de l'application ou bien, par exemple, sur l'activation/désactivation des applications, via l'utilisation, par exemple, d'une association MIDLET et/ou dispositif d'applications CRS (pour Contactless Registry Service définit dans la norme GlobalPlatform) et/ou CREL (pour Contactless Registry Event Listener, définit dans la norme Global Platform) permet d'obtenir, 20 dans l'élément sécurisé, une gestion dynamique de l'application ou des applications sélectionnables par défaut. Les paramètres d'algorithme associés à ce nouvel identifiant permettent de définir concrètement ce statut « sélectionnable par défaut », par exemple en renseignant la valeur '01' correspondant au statut « SET SELECTION » 25 Comme, dans le traitement classique (Figure 2), la liste des applications est parcourue dans l'ordre de priorité des applications (étape 235, tenant compte des priorités statiques et de la priorité volatile), il est possible de mettre en place, à l'aide de ce paramètre `7E', la sélection de l'application de plus grand ordre (en d'autres termes, la première application parcourue) dont le paramètre de sélection associé indique la valeur attendue, ici 30 '7E01'. Ceci est décrit par la suite en lien avec les Figures 6 et 6b. Bien entendu, de même que la sous-valeur '7E' n'est qu'un exemple, l'autre sous-valeur '01' n'est également qu'un exemple, et d'autres valeurs disponibles peuvent être utilisées en variante. Dans un mode de réalisation, on définit également un statut de désactivation de cette fonctionnalité de sélection de l'application de plus grand ordre sur la base de la valeur du 35 paramètre de sélection. Pour permettre une gestion aisée, ce statut de désactivation peut être défini au niveau de n'importe quelle application (par exemple nouvellement installée dans la carte), ce qui évite des opérations de suppression d'applications déjà installées ayant un statut « sélectionnable par défaut ». 3037753 20 Ce statut de désactivation peut être obtenu en utilisant une autre valeur pour les paramètres de sélection, par exemple '00' pour ce statut « CANCEL SELECTION » comme montré sur la Figure. Ainsi, si le paramètre de sélection associé à une application parcourue indique '7E00', ladite sélection de l'application de plus grand ordre est désactivée. En 5 particulier, aucune application n'est sélectionnée sur la base du critère vérifiant si le paramètre de sélection égale '7E01'. A nouveau, de même que la sous-valeur '7E' n'est qu'un exemple, l'autre sous-valeur '00' n'est également qu'un exemple, et d'autres valeurs disponibles peuvent être utilisées en variante. En cas de désactivation de ce mécanisme de sélection et également si celui-ci 10 n'aboutit pas à la sélection d'une application, l'algorithme classique (selon GlobalPlatform) de sélection d'une application par défaut est alors mis en oeuvre si la règle de gestion R1 est utilisée. L'utilisation de la règle R2 peut, comme vu plus haut, conduire à l'émission d'un message '6999' en cas de refus de sélection de l'ensemble des applications candidates valides. Le deuxième identifiant d'algorithme introduit dans ce mode de réalisation de 15 l'invention prend la valeur '7F' sur la Figure (mais toute autre valeur non déjà utilisée peut convenir). Il permet d'indiquer au moins deux algorithmes de reconnaissance de message à appliquer au message reçu pour déterminer si l'application associée peut être sélectionnée. Ce mécanisme, décrit plus en détail par la suite en référence aux Figures 6 et 6b, permet ainsi une plus grande flexibilité de sélection d'une même application par des équipements (lecteurs) 20 d'infrastructure hétérogènes. La liste des algorithmes de reconnaissance associés à l'application alors installée est définie par les paramètres d'algorithme associés à ce nouvel identifiant, par deux ou plus occurrences des paires [identifiant d'algorithme '01' ou '02' - paramètres d'algorithme] définies dans Global Platform. 25 Le cas échéant, si le mécanisme de sélection d'une application par défaut basé sur l'identifiant '7E' ci-dessus est mis en place, ces paramètres d'algorithme pour '7F' peuvent également comporter une occurrence [7E' - paramètre d'algorithme '00' ou '01'] pour indiquer le statut de « sélectionnable par défaut » de l'application installée. En d'autres termes, le paramètre '7F' ainsi introduit permet la concaténation d'une 30 pluralité de paires [identifiant d'algorithme - paramètres d'algorithme associés] pour l'application installée. Cela signifie que l'application peut désormais être sélectionnée de façon implicite par plusieurs types de commande. Cela est illustré par la Figure 5 reprenant la situation de la Figure 3. Désormais, l'application APPLICATION _1 a été installée en association avec une 35 pluralité d'algorithmes de reconnaissance définis respectivement pour les commandes COMMAND 1, COMMAND 2, ..., COMMAND N. Ainsi, lorsque les commandes COMMAND _2 et COMMAND _N sont reçues par l'élément sécurisé, le résultat d'un des algorithmes de reconnaissance est positif autorisant la sélection effective de l'application APPLICATION _1 (si 3037753 21 elle est active et sélectionnable dans l'élément sécurisé, et est autorisée à accéder à une interface sans contact de l'élément sécurisé). Le nouveau format proposé dans la Figure 4 pour la commande INSTALL offre désormais une large palette de définitions d'algorithmes de sélection des applications par 5 structures TLV (à comparer aux deux définitions actuellement possibles pour GlobalPlatform), par exemple les définitions suivantes non exhaustives (à partir du paramètre '83' uniquement) : [83] (Longueur) [01][Offset][Pattern] [83] (Longueur) [02][Reference Data][Mask] [83] (Longueur) [7E][00] 10 [83] (Longueur) [7E][01] [83] (Longueur) [7F] (Longueur) [01][Offset][Pattern] [83] (Longueur) [7F] (Longueur) [02][Reference Data][Mask] [83] (Longueur) [7F][02] [7E][00] [83] (Longueur) [7F][02] [7E][01] 15 [83] (Longueur) [7F] (Longueur) [01][Offset 1][Pattern 1] (Longueur) [01][Offset 2][Pattern 2] définissant ainsi deux algorithmes de reconnaissance par chaîne de caractères [83] (Longueur) [7F] (Longueur) [01][Offset][Pattern] (Longueur) [02][Reference Data][Mask] définissant ainsi deux algorithmes de reconnaissance, l'une par chaîne de caractères et l'autre par masque binaire 20 [83] (Longueur) [7F] (Longueur) [01][Offset][Pattern] [02] [7E][00] [83] (Longueur) [7F] (Longueur) [01][Offset][Pattern] [02] [7E][01] [83] (Longueur) [7F] (Longueur) [01][Offset 1][Pattern 1] (Longueur) [01][Offset 2][Pattern 2] [02][7E1101] (Longueur) [02][Reference Data 1][Mask 1] mélangeant ainsi trois algorithmes de reconnaissance par chaîne de caractères et par 25 masque binaire [83] (Longueur) [7F] (Longueur) [02][Reference Data 1][Mask 1] (Longueur) [02][Reference Data 2][Mask 2] ... (Longueur) [02][Reference Data n][Mask n] définissant ainsi n algorithmes de reconnaissance par masque binaire [83] (Longueur) [7F] (Longueur) [01][Offset 1][Pattern 1] (Longueur) [01][Offset 2][Pattern 2] ... 30 (Longueur) [01][Offset n][Pattern n] définissant ainsi n algorithmes de reconnaissance par chaîne de caractères [83] (Longueur) [7F] (Longueur) [01][Offset 1][Pattern 1] (Longueur) [01][Offset 2][Pattern 2] ... (Longueur) [01][Offset n][Pattern n] (Longueur) [02][Reference Data 1][Mask 1] (Longueur) [02][Reference Data 2][Mask 2] ... (Longueur) [02][Reference Data m][Mask m] 35 mélangeant ainsi n algorithmes de reconnaissance par chaîne de caractères avec m algorithmes de reconnaissance par masque binaire. Bien entendu, de nombreuses autres définitions sont possibles. 3037753 22 A noter que la présence « conditionnelle » des identifiants d'algorithme indique que ceux-ci sont mutuellement exclusif les uns des autres. En d'autres termes, seul un de ces identifiants doit être présent. La présence « optionnelle » des paramètres au sein de l'algorithme '7F' n'indique, 5 quant à elle, aucune restriction sur leur utilisation. Les Figures 6 et 6b illustrent, à l'aide d'un logigramme, la gestion de la sélection d'une application dans l'élément sécurisé basée sur l'utilisation de la signalisation de la Figure 5, selon un mode de réalisation de l'invention. Les étapes reprenant les mêmes références que des étapes de la Figure 2 sont 10 identiques à ces dernières. L'algorithme des Figures 6 et 6b comporte quatre blocs de traitement correspondant respectivement à : - une procédure principale de sélection explicite à partir d'une commande SELECT reçue. C'est le bloc 2A, identique à la Figure 2 ; 15 - une procédure principale de sélection implicite à l'aide d'un algorithme de reconnaissance de message. C'est le bloc 6B, qui, dans des modes de réalisation de l'invention, doit traiter l'extension '7F' évoquée précédemment. Ce bloc 6B peut correspondre au bloc 2B lorsque l'extension '7F' n'est pas mise en oeuvre ; - une procédure de sélection implicite d'une application par défaut selon des modes 20 de réalisation de l'invention. C'est le bloc 6D qui se base sur l'extension '7E' évoquée précédemment. Ce bloc 6D peut être omis lorsque l'extension '7F' n'est pas mise en oeuvre (comme prévu sur la Figure 2 par exemple) ; - une procédure de sélection d'une application par défaut. C'est le bloc 2C, identique à la Figure 2. 25 En détails, les étapes 200 de réception d'un message APDU et 205 de détermination de s'il s'agit d'une commande SELECT sont identiques à celles de la Figure 2. En cas de commande SELECT, la procédure principale de sélection explicite 2A est mise en oeuvre de façon identique à la Figure 2. Si aucune application n'est effectivement sélectionnée à l'issue de cette procédure principale 2A (incluant le cas où aucune application candidate n'est 30 détectée), la procédure de sélection implicite d'une application par défaut 6D va être mise en oeuvre comme décrite par la suite. Pour ce faire, à l'étape 600, une variable TARGET_UIS désignant l'application par défaut qui est cible pour cette sélection implicite 6D est initialisée à NULL et une variable PR indiquant la nature de la procédure principale de sélection est mise à FALSE (PR=FALSE si la procédure principale utilisée est une procédure de sélection explicite ; 35 PR=TRUE s'il s'agit d'une procédure de sélection implicite). Outre la valeur d'initialisation NULL, la variable TARGET_UIS peut prendre une valeur identifiant une application par défaut installée (par exemple via un identifiant unique d'application) ou prendre une valeur CANCEL lorsque cette procédure de sélection 6D est désactivée. Puis la liste ordonnée des applications va être parcourue à l'étape 235. 3037753 23 Si en revanche, le message reçu n'est pas une commande SELECT, la procédure principale de sélection implicite 6B est mise en oeuvre. Elle comporte une étape initiale 602 d'initialisation des variables TARGET UIS (à NULL) et PR à TRUE (pour indiquer qu'une procédure principale de sélection implicite est mise 5 en oeuvre). Puis la liste ordonnée des applications est parcourue à l'étape 235. Tant qu'il y a des applications candidates non parcourues (sélection initiale 605 de l'application de plus haute priorité, puis test 251), on traite chacune d'entre elles dans l'ordre de la liste (sélection 252). Pour ce faire, on détermine s'il existe un algorithme de reconnaissance associé à l'application couramment parcourue et qui n'ait pas encore été traité (test 610). Il 10 s'agit en pratique de tester si un identifiant d'algorithme (sous le paramètre '83') n'a pas encore été traité. Dans la négative, on passe à l'application candidate suivante via les étapes 251 et 252. Si un tel identifiant n'a pas encore été traité, sa valeur est déterminée à l'étape 615. 15 En cas de valeur invalide (c'est-à-dire différent de '01', '02', '7E' ou '7F'), on retourne à l'étape 251 pour traiter les applications candidates non encore considérées. Si sa valeur est '7F', on retourne à l'étape 610 pour considérer les différentes paires [identifiant d'algorithme - paramètres d'algorithme associés] définies dans les paramètres associés à l'extension '7F'. 20 Si sa valeur est l'une des valeurs conventionnelles '01' ou '02', la valeur de PR est testée à l'étape 620 pour déterminer s'il est opportun d'effectuer la procédure principale de sélection implicite 6B. En effet, cette dernière est, selon la norme GlobalPlatform, exclusive de la procédure principale de sélection explicite 2A. Aussi, si PR=FALSE (défini lors de l'étape 600), les algorithmes de reconnaissance de message par chaîne de caractères ou masque 25 binaire ne doivent pas être exécutés. Ainsi, en cas de test 620 (PR=TRUE ?) négatif, le procédé retourne à l'étape 610 afin de parcourir tous les identifiants définis pour l'application courante et de déterminer si cette application peut être sélectionnée par défaut (car définie ainsi via l'identifiant '7E'). En revanche, si le test 620 est positif signifiant qu'aucune procédure principale de 30 sélection explicite 2A n'a été exécutée, le test 625 sert à discriminer entre les deux identifiants '01' et '02' afin d'exécuter, sur le message reçu en entrée (étape 200), l'algorithme de reconnaissance correspondant (étapes 630 et 635 respectivement). L'étape suivante, 640, consiste à déterminer si le résultat de l'exécution de l'algorithme est positif au sens de la norme GlobalPlatorm, auquel cas l'OPEN teste la sélection de l'application courante à l'étape 245. 35 Selon le résultat obtenu (refus ou non de sélection - test 250), le traitement se termine à l'étape 295 (si sélection effective) ou se poursuit à l'étape 610 (si refus de sélection). Si le résultat de l'exécution de l'algorithme est négatif à l'étape 640, le traitement se poursuit directement à l'étape 610. 3037753 24 Ainsi, se termine la procédure principale de sélection implicite 6B au cours de laquelle, tant qu'aucune application n'est effectivement sélectionnée, chaque application de la liste est parcourue et testée aux fins de sélection si un algorithme de reconnaissance de message défini en association avec cette application s'avère être positif. 5 Si en définitive aucune application n'est sélectionnée au cours de l'une ou l'autre des procédures principales de sélection 2A et 6B, la procédure de sélection implicite d'une application par défaut 6D est lancée lorsque la règle de gestion R1 est utilisée (test 253). Sinon, un message '6999' est émis (étape 254). La procédure de sélection implicite d'une application par défaut 6D est constituée de 10 deux parties, l'une imbriquée dans la boucle parcourant l'ensemble des algorithmes de reconnaissance définis pour les applications de la liste ordonnée, et l'autre exploitant le résultat de cette boucle. Comme la procédure principale de sélection implicite 6B a échouée, toutes les applications de la liste ont été testées au cours de la boucle 251-252. 15 Pour chacune des applications parcourues, si l'identifiant d'algorithme testé à l'étape 615 vaut '7E', la valeur du paramètre associé est testée à l'étape 645. Si cette valeur vaut 'CANCEL SELECTION', la variable TARGET_UIS est mise à `CANCEL' afin de désactiver la sélection d'une application par défaut selon la procédure 6D proposée par la présente invention. Il s'agit de l'étape 650, suite à laquelle le traitement 20 retourne à l'étape 610. Si la valeur du paramètre associé à l'identifiant '7E' vaut 'SET SELECTION', la valeur de la variable TARGET_UIS est testée à l'étape 655. Si cette valeur de la variable TARGET_UIS est 'CANCEL' (valeur mise à l'étape 650) ou l'identifiant d'une application `XXXX' (sortie « non » du test), alors le traitement passe à 25 l'algorithme de reconnaissance suivante à l'étape 610. Si cette valeur est 'NULL', l'application courante est l'application de plus grand ordre dans la liste parcourue pour laquelle le paramètre associé à '7E' vaut 'SET SELECTION', c'est-à-dire l'application de plus grand ordre pour la sélection implicite par défaut. Aussi, la variable TARGET_UIS prend la valeur de l'identifiant `XXXX' de l'application courante, à l'étape 660. 30 Puis le traitement se poursuit à l'étape 610. Au final, lorsque toutes les applications ont été parcourues (sortie « non » au test 605), la variable TARGET_UIS peut prendre trois valeurs : - 'NULL' si aucune algorithme '7E' n'a été défini pour une application avec une valeur `CANCEL SELECTION' ou 'SET_SELECTION' ; 35 - 'CANCEL' si au moins une application possède un algorithme de reconnaissance associé de type '7E' dont le paramètre est 'CANCEL SELECTION'. Dans ce cas, aucune application ne doit être sélectionnée par défaut en utilisant ce mécanisme de l'invention reposant sur l'identifiant '7E' ; et 3037753 25 - `XXXX' identifiant l'application de plus grand ordre pour laquelle l'algorithme '7E' associé comporte un paramètre mis à 'SET SELECTION'. Dans ce cas, aucune application n'a été installée avec un paramètre '7E' associé désactivant le mécanisme de sélection implicite d'une application par défaut 6B. 5 Compte tenu de ces diverses valeurs possibles, la suite de la procédure 6B comporte, suite à l'étape 665 consistant à déterminer si la variable TARGET_UIS identifie une application (valeur `XXXX'). Si tel est le cas, cette application est testée à la sélection à l'étape 670 similaire aux étapes 220 et 245. En cas de succès (test 680), le traitement prend fin (étape 295) En cas d'échec (test 680) ou si TARGET_UIS ne désigne pas une application, le 10 traitement se poursuit par la procédure de sélection d'une application par défaut 2C selon les mécanismes classiques GlobalPlatform, notamment basée sur le paramètre `CF' et/ou le privilège « Card Reset ». Si cette procédure échoue, le canal logique, si de base, reste ouvert, à l'étape 255, avant que le traitement ne prenne fin (étape 295). Il a été vu ci-dessus que le tag '7E' permet d'étendre la sélection implicite d'une 15 application par défaut à un plus grand nombre d'applications possibles. La combinaison de ce tag avec le mécanisme de priorité volatile procure d'avantage de dynamisme et de souplesse dans la gestion de l'application sélectionnée par défaut. En effet, l'application doté de la priorité volatile et ayant son tag '7E' égal à '01' sera sélectionnée par défaut. Or cette propriété de priorité volatile peut aisément être modifiée 20 (notamment sans recours à des sessions sécurisées) à l'aide d'une simple midlet : par exemple, une utilisation peut ouvrir un menu interactif dans le dispositif hôte et sélectionner l'application qu'il souhaite vouloir devenir implicitement sélectionnable par défaut. Ainsi, la présente invention permet de facilement modifier l'application sélectionnée par défaut de façon prioritaire. 25 A titre d'exemple, l'utilisation, d'une association MIDLET et/ou dispositif d'applications CRS et/ou CREL permet de définir et modifier la propriété de priorité volatile. La CREL est dédiée aux applications sans contact installées sur l'élément sécurisé. Lors de leur installation, ces applications peuvent référencer la CREL (via un paramètre dédié), c'est-à-dire s'enregistrer auprès de celle-ci. Grâce à ce référencement, la CREL peut agir 30 directement sur les applications, notamment sur les registres pilotant ces applications, pour par exemple supprimer le caractère de priorité volatile à une application, activer/désactiver une ou plusieurs applications, etc. La CRS est dédiée au management d'applications sans contact installées sur l'élément sécurisé. Elle fournit à l'utilisateur des moyens qui lui permettent notamment de 35 récupérer une liste de toutes les applications (applications seules ou groupes d'applications), permettent d'activer ou désactiver des applications, permettent de changer la priorité ou priorité volatile des applications sur l'interface sans contact. 3037753 26 Outre la gestion dynamique via la priorité volatile, une gestion dynamique de l'application sélectionnée par défaut peut également s'appuyer sur d'autres mécanismes simples. Par exemple, un utilisateur peut invoquer le dispositif CREL et/ou CRS via une midlet 5 pour désactiver toutes les applications sans contact, sauf celle souhaitée qui aura en outre son tag '7E' mis à '01'. Cette application sera donc implicitement sélectionnable, de façon préférentielle à toute application (par contact ou non) qui dispose du tag `CF' ou de l'attribut « Card Reset ». Dans un autre exemple, un événement particulier peut déclencher automatiquement, 10 via une middlet et/ou via une CRS et/ou via la CREL, la désactivation de toutes les applications sans contact, hormis celle souhaitée qui disposera d'un tag '7E' mis à '01'. A titre illustratif, cet événement particulier peut être un événement de géolocalisation obtenu par le dispositif hôte permettant de rendre active et sélectionnable par défaut l'application de transport en commun de la zone géographique dans laquelle se situe l'élément sécurisé. 15 Les exemples qui précèdent montrent qu'un paramétrage approprié des paramètres de protocole sans contact pour les applications installées, en utilisant une ou plusieurs des extensions proposées ci-dessus offre un contrôle amélioré et plus complet du processus de sélection implicite des applications dans la carte à puce, sans nécessiter la présence de certificats ou autorisations des fournisseurs des applications. 20 Ces exemples ne sont que des modes de réalisation de l'invention qui ne s'y limite pas. Par exemple, dans ces exemples, le paramètre '7E00' ou '7E01' de sélection d'une application par défaut est défini au sein du paramètre '83' de la Figure lb. En variante, le paramètre '7E00' ou '7E01' peut être défini au sein de tout autre paramètre parmi les paramètres de protocole sans contact (c'est-à-dire les paramètres de la Figure lb) ou 25 constituer, en soi, un nouveau paramètre parmi les paramètres de protocole sans contact. REVENDICATIONS1. Procédé de sélection d'une application installée dans un élément sécurisé multi-applications, comprenant les étapes suivantes, dans l'élément sécurisé : recevoir au moins un message ; exécuter une procédure principale de sélection d'une application à partir dudit message reçu ; si aucune application n'est sélectionnée à l'issue de la procédure principale, sélectionner une application par défaut, procédé dans lequel la sélection d'une application par défaut comprend les étapes suivantes, dans l'élément sécurisé : obtenir une liste ordonnée d'une ou plusieurs applications installées dans l'élément sécurisé, chaque application étant associée, en mémoire, à un paramètre de sélection respectif défini dans des paramètres de protocole sans contact de ladite application installée conformément à la norme GlobalPlatform Card ; parcourir la liste ordonnée en vérifiant si le paramètre de sélection associé à l'application parcourue indique une première valeur prédéfinie ; sélectionner l'application de plus grand ordre dont le paramètre de sélection associé indique ladite première valeur prédéfinie. 2. Procédé selon la revendication 1, dans lequel ladite liste d'applications est ordonnée en fonction de priorités affectées auxdites applications, une priorité statique étant affectée à chaque application lors de son installation et une priorité volatile, supérieure à toute priorité statique, étant affectée, en mémoire volatile de l'élément sécurisé, à au plus une application ou à un groupe d'applications, et le procédé comprenant en outre une étape de modification de l'affectation de la priorité volatile d'une première application ou premier groupe d'applications à une deuxième application ou deuxième groupe d'applications. 3. Procédé selon la revendication 1 ou 2, dans lequel toute application installée dans l'élément sécurisé présente un état parmi un état actif dans lequel l'application est sélectionnable et un état inactif dans lequel l'application n'est pas sélectionnable, et le procédé comprend en outre une étape de modification de l'état de l'ensemble des applications installées, sauf une application présentant un état actif, vers l'état inactif. 4. Procédé selon l'une des revendications 1 à 3, comprenant, en outre, lors du parcours de la liste ordonnée, une étape de vérification de si le paramètre de sélection associé à une application parcourue indique une deuxième valeur prédéfinie ; procédé dans lequel, s'il est vérifié que le paramètre de sélection associé à l'une des applications indique ladite deuxième valeur prédéfinie, ladite sélection de l'application de plus grand ordre est désactivée. 3037753 28 5. Procédé selon l'une des revendications 1 à 4, comprenant, en outre, la sélection d'une application prédéfinie si aucune application de plus grand ordre n'est sélectionnée à l'issue du parcours de la liste ordonnée. 6. Procédé selon l'une des revendications 1 à 5, dans lequel ledit paramètre de 5 sélection associé à une application est identifié par la valeur '83' dans les paramètres de protocole sans contact identifiés par la valeur 'AO' dans la norme GlobalPlatform Card. 7. Procédé selon la revendication 6, dans lequel ladite première valeur prédéfinie est formée d'un identifiant d'algorithme et d'un paramètre d'algorithme ; et ledit identifiant formant la première valeur prédéfinie est différent des identifiants '01' et '02' 10 désignant respectivement un algorithme de reconnaissance par chaîne de caractères et un algorithme de reconnaissance par masque binaire conformément à la norme GlobalPlatform Card. 8. Procédé selon la revendication 7 en dépendance de la revendication 4, dans lequel la deuxième valeur prédéfinie est formée du même identifiant d'algorithme que ladite 15 première valeur prédéfinie et d'un paramètre d'algorithme différent. 9. Procédé selon l'une des revendications 1 à 8, dans lequel le message reçu est une commande SELECT[by name] définie par la spécification Javacard ou équivalent, et la procédure principale de sélection comporte la sélection d'une application identifiée dans la commande SELECT[by name] reçue, si une telle application existe dans l'élément 20 sécurisé . 10. Procédé selon l'une des revendications 1 à 8, dans lequel le message reçu est différent d'une commande SELECT[by name] définie par la spécification Javacard ou équivalent, et le paramètre de sélection associé à chaque application de la liste ordonnée identifie au moins un algorithme de reconnaissance à appliquer au message reçu pour 25 déterminer si l'application associée peut être sélectionnée, et la procédure principale de sélection comporte les étapes suivantes, lors du parcours de la liste ordonnée et tant qu'aucune application n'est sélectionnée à l'aide d'un algorithme de reconnaissance : exécuter, sur le message reçu, le ou les algorithmes de reconnaissance 30 indiqués par le paramètre de sélection associé à l'application parcourue ; sélectionner l'application parcourue uniquement si le résultat de l'un des algorithmes de reconnaissance est positif. 11. Procédé selon la revendication 10, dans lequel le message reçu différent d'une commande SELECT[by name] est exécuté par l'application sélectionnée. 35 12. Procédé selon l'une quelconque des revendications 1 à 11, dans lequel ledit message est du type unité de donnée de protocole d'application ou APDU conforme à la norme ISO 7816-4. 13. Procédé selon l'une quelconque des revendications 1 à 12, comprenant, en outre, l'étape suivante : 3037753 29 sélectionner une application installée dans l'élément sécurisé uniquement si l'application est paramétrée comme active et sélectionnable dans l'élément sécurisé, et est autorisée à accéder à une interface de communication de l'élément sécurisé. 14. Elément sécurisé comportant une pluralité d'applications en mémoire, ainsi 5 que : une interface de communication configurée pour recevoir au moins un message ; un module de sélection d'application configuré pour exécuter une procédure principale de sélection d'une application à partir dudit message reçu, et si aucune application n'est sélectionnée à l'issue de la procédure principale, sélectionner une application par défaut, 10 dans lequel le module de sélection pour sélectionner une application par défaut est configuré pour : obtenir une liste ordonnée d'une ou plusieurs applications installées dans l'élément sécurisé, chaque application étant associée, en mémoire, à un paramètre de sélection respectif défini dans des paramètres de protocole sans contact, identifiées par la valeur `A0', de ladite 15 application installée conformément à la norme GlobalPlatform Card ; parcourir la liste ordonnée en vérifiant si le paramètre de sélection associé à l'application parcourue indique une première valeur prédéfinie ; sélectionner l'application de plus grand ordre dont le paramètre de sélection associé indique ladite première valeur prédéfinie. 20 15. Produit programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 13, lorsque ledit programme est exécuté sur un ordinateur.