FR3025631A1 - Selection securisee d'une application dans une carte a puce ou equivalent - Google Patents

Abstract

L'invention concerne un procédé d'accès à une application d'une carte à puce ou équivalent, offrant une sélection sécurisée de l'application à l'aide d'une commande SELECT. L'invention prévoit d'utiliser un identifiant AID qui est dynamiquement renouvelé à chaque nouvelle commande SELECT. L'identifiant AID comporte une partie fixe FixAID d'identification de l'application à sélectionner et une partie dynamique DynAID de vérification. Cette partie dynamique DynAID est calculée à partir d'au moins une variable dynamique partagée secrètement, par exemple à l'aide d'une fonction de hachage appliquée au résultat d'une concaténation de FixAID avec une valeur de hachage dynamique et récursive et avec une valeur de compteur dynamique. Une réponse de l'application sélectionnée à la commande SELECT comprend également une valeur de confirmation dynamique, afin de sécuriser la confirmation de la sélection effective de l'application. L'au moins une variable dynamique secrètement partagée est alors mise à jour.

Description

1 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 au moins une application, et généralement plusieurs applications. La présente invention concerne plus particulièrement un procédé d'accès à une telle application avec une sélection sécurisée de l'application. CONTEXTE DE L'INVENTION Un type d'élément sécurisé (« Secure Element » selon la terminologie anglo- saxonne) est la carte à puce amovible ou embarquée, par exemple une carte UICC ou eUICC (pour « embedded Universel 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.

Il est classique que de telles cartes à puce 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 la carte à puce é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 ont défini une commande de sélection d'application, généralement une version de la commande SELECT. C'est le cas de la norme ISO/IEC 7816-4, de la norme « Global Platform Card Specification » 30 ou encore de la norme « ETSI, Smart Cards ; UICC-Terminal Interface ; Physical and logical characteristics » (Release 9, 2010). Cette commande de sélection comprend un identifiant de l'application à sélectionner, généralement dénoté AID pour « Application IDentifier ». Dans les normes susvisées, cet identifiant comprend de 1 à 16 octets, le premier octet 35 définissant généralement le format de l'AID (format propriétaire ou selon une norme).

3025631 2 Dans la norme EMV (pour « Europay, MasterCard and Visa »), l'identifiant AID est composé d'un identifiant RID sur cinq octets et d'un identifiant PIX de taille variable. L'identifiant RID (pour « registered application provider identifier ») identifie le propriétaire de l'application et est généré par une autorité d'enregistrement ISO/IEC 5 7816-5. L'identifiant PIX (pour « proprietary application identifier extension ») permet à un même propriétaire de distinguer entre les différentes applications qu'il offre. A réception de la commande SELECT par la carte à puce, elle est traitée par un gestionnaire de carte interne à ladite carte à puce pour sélectionner de façon effective l'application identifiée par le paramètre AID. Cette sélection effective consiste 10 en ce que le gestionnaire de carte va par la suite router, à cette application, l'ensemble des commandes entrantes reçues depuis le terminal externe sur le canal de communication. L'application peut ainsi être accédée sur le canal de communication, par le terminal externe, tant que l'application n'est pas désélectionnée, ce qui peut se produire par exemple lorsqu'une autre application est sélectionnée à l'aide d'une 15 nouvelle commande SELECT. La Figure 1 illustre des communications entre un terminal externe (Master), par exemple un téléphone mobile, et une carte à puce (Slave) équipée d'un gestionnaire de carte et de deux applications, l'une A de paiement, l'autre B relative à un service de transport. Dans cet exemple, un utilisateur effectue l'achat d'un titre de 20 transport avant de l'utiliser. La commande SELECT A comprenant l'identifiant AID de l'application A est reçue par la carte à puce ; le gestionnaire de carte la retransmettant à l'application A identifiée dans la commande. L'application A accuse réception de la commande, ce qui clôt l'opération de sélection de l'application.

25 Les commandes suivantes (excepté notamment un nouvelle commande SELECT ou une commande traitée par le gestionnaire de carte) sont alors routées par le gestionnaire de carte vers l'application A sélectionnée, sans que ces commandes n'aient à renseigner un identifiant d'application. Dans l'exemple, trois commandes sont nécessaires pour réaliser l'achat du titre de transport (Commande#1-3 et Réponse#1-3). Puis, l'utilisateur souhaite accéder au réseau de transport en activant un service approprié, ce qui déclenche la sélection de l'application B de transport par l'envoi d'une commande SELECT B incluant l'identifiant AID de l'application B. La commande #4 permettant de vérifier la validité du titre de transport est ensuite envoyée. La réponse #4 autorise ou non l'accès au service de transport.

3025631 3 L'identifiant AID est une information publique car elle transite en clair sur le canal de communication entre le terminal externe et la carte à puce. Ainsi, une personne mal intentionnée y a facilement accès et peut utiliser cette information pour tenter de sélectionner de façon malveillante une application de la carte à puce. Cette 5 situation est actuellement acceptée par l'industrie des cartes à puce. Elle n'est cependant pas satisfaisante car les personnes mal intentionnées peuvent sélectionner une application pour réaliser des actions non souhaitées. Ces actions ne mènent pas nécessairement à une réalisation avec succès des actions non souhaitées. Par exemple, pour une application de paiement, l'initiation d'une 10 transaction conduit à l'incrément du compteur de transactions, même si ladite transaction n'est pas utilisée. La Figure 2 illustre le cas d'une personne mal intentionnée interrompant une transaction financière par la sélection d'une autre application. L'utilisateur est alors dans l'incapacité d'acheter un titre de transport comme souhaité.

15 Dans cet exemple, la personne mal intentionnée envoie une commande SELECT B après la commande #1 alors que la transaction financière n'est pas terminée. La carte à puce sélectionne alors de façon effective l'application B, et les commandes suivantes #2 et #3 sont transmises à cette dernière application, résultant en des réponses #2 et #3 erronées. Le titre de transport n'est donc pas acheté.

20 L'accès au réseau de transport est alors refusé (Réponse #4 annonce un échec). La Figure 3 illustre un autre cas où la personne mal intentionnée, connaissant l'AID de l'application B de transport, tente d'obtenir un voyage gratuit. Elle sélectionne l'application B à l'aide d'une commande SELECT B, puis 25 envoie une ou des commandes appropriées permettant d'obtenir une réponse positive. Ces différents exemples montrent que la sélection fallacieuse d'une application peut conduire au traitement impropre de commandes cibles. De même, la situation actuellement acceptée par l'industrie des cartes à puce n'est pas à même de garantir un accès restreint des applications aux seules personnes autorisées.

30 Dans ce contexte, la présente invention vise à résoudre tout ou partie de ces inconvénients.

3025631 4 RESUME DE L'INVENTION Selon des modes de réalisation de l'invention, il est prévu un procédé d'accès à une application d'un élément sécurisé comprenant au moins une application, le procédé comprenant, au niveau de l'élément sécurisé, les étapes suivantes : 5 recevoir, d'un terminal externe, une commande de sélection d'une application, la commande de sélection comprenant un identifiant de l'application à sélectionner ; et sélectionner ladite application identifiée par la commande de sélection de sorte à router, vers ladite application sélectionnée, une nouvelle commande reçue subséquemment du terminal externe ; 10 le procédé étant caractérisé en ce qu'il comprend une étape consistant à vérifier l'identifiant de l'application contenu dans la commande de sélection à l'aide d'au moins une variable dynamique secrètement partagée entre l'élément sécurisé et le terminal externe, de sorte à autoriser la sélection de l'application uniquement en cas de vérification positive.

15 Ce procédé est mis en oeuvre dans l'élément sécurisé. Ainsi, ces modes de réalisation prévoient également un élément sécurisé comprenant au moins une application et une interface de communication pour recevoir, d'un terminal externe, une commande de sélection d'une application, la commande de sélection comprenant un identifiant de l'application à sélectionner, l'élément sécurisé étant configuré pour 20 sélectionner ladite application identifiée par la commande de sélection de sorte à router, vers ladite application sélectionnée, une nouvelle commande reçue subséquemment du terminal externe ; l'élément sécurisé étant caractérisé en ce qu'il est configuré pour vérifier l'identifiant de l'application contenu dans la commande de sélection à l'aide d'au moins 25 une variable dynamique secrètement partagée entre l'élément sécurisé et le terminal externe, de sorte à autoriser la sélection de l'application uniquement en cas de vérification positive. De façon classique, toutes les commandes reçues subséquemment et jusqu'à une nouvelle commande de sélection comprenant l'identifiant d'une autre application, 30 sont routées vers l'application sélectionnée. C'est le rôle notamment d'un gestionnaire présent dans l'élément sécurisé. L'utilisation de la variable dynamique secrètement partagée pour autoriser la sélection de l'application signifie notamment que l'identifiant de l'application contenu dans la commande reçue est basé sur (généré à partir de) cette variable dynamique 35 secrètement partagée entre l'élément sécurisé et le terminal externe.

3025631 5 Ainsi, compte tenu du caractère dynamique de l'identifiant utilisé dans la commande de sélection, le procédé peut en outre comprendre l'étape suivante : recevoir, du terminal externe, une autre commande de sélection de la même application, ladite autre commande comprenant un autre identifiant de l'application à 5 sélectionner qui est différent dudit identifiant de la commande de sélection. Cette autre commande de sélection peut être reçue de façon décorrélée à la première commande de sélection. Egalement, d'autres applications pourront avoir été sélectionnées dans l'intervalle entre ces deux commandes de sélection de la même application. Cette disposition montre ainsi que l'identifiant d'application utilisé dans la commande de 10 sélection change à chaque commande de sélection de la même application. Cet identifiant est donc dynamique puisqu'il dépend directement de la variable dynamique secrètement partagée. Du point de vue du terminal externe, des modes de réalisation de l'invention prévoient un procédé d'accès à une application d'un élément sécurisé comprenant au 15 moins une application, le procédé comprenant, au niveau d'un terminal externe à l'élément sécurisé, une étape consistant à envoyer, à l'élément sécurisé, une commande de sélection d'une application de sorte qu'une nouvelle commande envoyée subséquemment à l'élément sécurisé est routée vers ladite application sélectionnée, la commande de sélection comprenant un identifiant de l'application à 20 sélectionner ; le procédé étant caractérisé en ce qu'il comprend en outre une étape consistant à générer l'identifiant de l'application contenu dans la commande de sélection à l'aide d'au moins une variable dynamique secrètement partagée entre l'élément sécurisé et le terminal externe.

25 Ce procédé est mis en oeuvre dans le terminal externe. Ainsi, ces modes de réalisation prévoient également un dispositif comprenant une interface de communication pour envoyer, à un élément sécurisé comprenant au moins une application, une commande de sélection d'une application de sorte qu'une nouvelle commande envoyée subséquemment à l'élément sécurisé est routée vers ladite 30 application sélectionnée, la commande de sélection comprenant un identifiant de l'application à sélectionner ; le dispositif étant caractérisé en ce qu'il est configuré pour générer l'identifiant de l'application contenu dans la commande de sélection à l'aide d'au moins une variable dynamique secrètement partagée entre l'élément sécurisé et le dispositif.

3025631 6 Egalement, compte tenu du caractère dynamique de l'identifiant utilisé dans la commande de sélection, le procédé peut en outre comprendre l'étape suivante : envoyer, à l'élément sécurisé, une autre commande de sélection de la même application, ladite autre commande comprenant un autre identifiant de l'application à 5 sélectionner qui est différent dudit identifiant de la commande de sélection. D'autres applications pourront avoir été sélectionnées dans l'intervalle entre ces deux commandes de sélection de la même application. Cette disposition montre ainsi que l'identifiant d'application utilisé dans la commande de sélection change à chaque commande de sélection de la même application. Cet identifiant est donc dynamique 10 puisqu'il dépend directement de la variable dynamique secrètement partagée. La présente invention permet ainsi de sécuriser la sélection d'applications dans un élément sécurisé en rendant secret et variable (c'est-à-dire dynamique) l'identifiant de chaque application, à tout instant de la vie de l'élément sécurisé. Cette mise au secret de l'identifiant est en effet obtenue par l'utilisation de la variable 15 dynamique secrètement partagée entre les deux entités, à partir de laquelle la vérification de validité de l'identifiant est conduite. D'autres caractéristiques de l'élément sécurisé, du terminal externe et des procédés selon des modes de réalisation sont décrites dans les revendications dépendantes, essentiellement à l'aide d'une terminologie de procédé, transposable par 20 conséquent à l'élément sécurisé et au terminal externe. Dans un mode de réalisation, l'identifiant de l'application comprend une partie fixe FixAID d'identification de l'application à sélectionner et une partie dynamique DynAID de vérification, ladite partie dynamique DynAID étant basée sur la variable dynamique secrètement partagée. Ainsi la vérification autorisant ou non la sélection de 25 l'application sur l'élément sécurisé peut être effectuée à partir de la partie dynamique seulement. Dans un mode de réalisation, la variable dynamique secrètement partagée, par exemple une valeur de hachage (hash), est mise à jour à chaque sélection effective de l'application. La valeur initiale du hash/de la variable ainsi que les valeurs 30 de mise à jour (éventuellement la façon dont elles sont déterminées) peuvent être initialement convenues de façon secrète entre l'élément sécurisé et le terminal externe. En outre, la variable dynamique secrètement partagée h(i) telle qu'utilisée pour l'identifiant de l'application à sélectionner peut comprendre une valeur de hachage calculée à partir d'une valeur de hachage précédente h(i-1) secrètement 35 partagée et utilisée pour un précédent identifiant de l'application lors d'une précédente 3025631 7 sélection de l'application, généralement lors de la précédente sélection effective de l'application. En d'autres termes, la valeur de hachage est récursive. Egalement, la valeur initiale de cette valeur de hachage peut être connue uniquement de l'élément sécurisé et du terminal externe, peu important que l'algorithme de mise à jour de cette 5 valeur de hachage soit public ou non. Ces dispositions contribuent à la sécurisation du mécanisme de sélection d'une application dans l'élément sécurisé. Dans un mode de réalisation, l'élément sécurisé met à jour la variable dynamique secrètement partagée dès que ladite vérification de l'identifiant de 10 l'application est positive. Cette disposition contribue à conserver une synchronisation, entre le terminal externe et l'élément sécurisé, de la variable dynamique partagée. Dans un mode de réalisation, la variable dynamique secrètement partagée est fonction d'un secret partagé entre l'élément sécurisé et le terminal externe, et fonction d'une variable distincte qui est dynamique. Dans les exemples qui suivent, cette 15 variable distincte peut être un compteur, éventuellement public. Le secret partagé est par exemple une clé de chiffrement symétrique ou un paramètre d'une fonction de hachage utilisée dans la génération de l'identifiant AID. Dans un mode de réalisation, la vérification ou génération de l'identifiant de l'application comprend le calcul d'une valeur dynamique d'identifiant DynVal selon la 20 formule suivante : DynVal = xLMB ( hash ( H ) ), où xLMB (y) est une fonction qui renvoie x octets de y (par exemple le ou les x octets de gauche de y) ; hash () est une fonction de hachage ; et H est une valeur formée au moins en partie à partir de la variable dynamique secrètement partagée.

25 La fonction de hachage peut être une fonction prenant optionnellement en paramètre le secret partagé évoqué précédemment, tel une clé (e.g. : HMAC pour « Keyed-Hash Message Authentication Code » en terminologie anglaise), et la variable distincte dynamique, telle un compteur. Comme il sera décrit ci-après, H peut notamment être le résultat d'une 30 concaténation entre au moins la partie fixe FixAID de l'identifiant contenu dans la commande de sélection et la variable dynamique secrètement partagée. Cette disposition permet un calcul et une vérification d'identifiant relativement simple à mettre en oeuvre. Selon un mode de réalisation particulier, H = S / h / C où est la fonction de 35 concaténation ; S est une valeur connue de l'élément sécurisé et du terminal externe ; 3025631 8 h est une valeur de hachage et C est une variable distincte dynamique de type compteur mise à jour à chaque sélection effective de l'application. Selon un mode de réalisation encore plus particulier, h vaut la valeur hash ( S / h / C) obtenue lors de la précédente itération du calcul de la valeur dynamique 5 DynVal. Cette valeur précédente constitue ainsi la valeur de la variable dynamique secrètement partagée, c'est-à-dire connue uniquement du terminal et de l'élément sécurisé, qui est mise à jour à chaque itération. Cette configuration simple à mettre en oeuvre en termes de calculs accroît la sécurité de la sélection d'application selon l'invention, notamment grâce à l'utilisation d'une valeur h récursive.

10 Selon un mode de réalisation particulier, la variable distincte dynamique est mise à jour avec une valeur de mise jour fonction de hash ( H ), en cas de sélection effective de l'application , par exemple en ajoutant la valeur zRMB ( hash ( H ) ), où zRMB (y) est une fonction qui renvoie z octets de droite de y (par exemple le ou les z octets de droite de y).

15 Selon un mode de réalisation particulier, S vaut la partie fixe FixAID de l'identifiant contenu dans la commande de sélection. En utilisant cette valeur déjà partagée entre le terminal externe et l'élément sécurisé, on limite l'utilisation de mémoire dans ce dernier. Dans un mode de réalisation, la vérification de l'identifiant de l'application 20 comprend en outre la comparaison de la valeur dynamique DynVal avec la partie dynamique DynAID de l'identifiant contenu dans la commande de sélection. Cette disposition illustre le rôle de vérification joué par la partie dynamique DynAID, notamment pour valider l'authenticité de l'identifiant dynamique utilisé. Dans un mode de réalisation, la vérification de l'identifiant de l'application est 25 effectuée par l'application identifiée par la partie fixe FixAID de l'identifiant contenu dans la commande de sélection. Cette disposition permet de décharger le gestionnaire de carte de ces traitements spécifiques à chaque application. En outre, cette disposition garantit une sécurité accrue car les variables dynamiques secrètement partagées sont ainsi stockées par chaque application concernée, au lieu d'un stockage 30 centralisé dans l'élément sécurisé. Dans un mode de réalisation, le procédé peut en outre comprendre, en cas de vérification positive (et donc d'autorisation de sélection de l'application), la génération et la transmission, au terminal externe, d'une réponse confirmant la sélection effective de l'application, ladite réponse comprenant une valeur de confirmation fonction de 35 ladite variable dynamique secrètement partagée.

3025631 9 De façon symétrique sur le terminal externe, le procédé peut en outre comprendre les étapes suivantes : recevoir, de l'élément sécurisé, une réponse confirmant la sélection effective de l'application, ladite réponse comprenant une valeur de confirmation fonction de 5 ladite variable dynamique secrètement partagée ; et vérifier la valeur de confirmation contenue dans la réponse à l'aide de la variable dynamique secrètement partagée. Ces dispositions contribuent à conserver une synchronisation de la variable dynamique secrètement partagée, entre le terminal externe et l'élément sécurisé.

10 En outre, elles permettent au terminal externe d'être informé de façon sécurisée de la sélection effective de l'application. L'accès à l'application est ainsi sécurisé. Une personne mal intentionnée n'ayant pas connaissance de la variable dynamique secrètement partagée ne pourra, en effet, pas générer une réponse avec 15 une valeur de confirmation correcte, car cette dernière change à chaque itération. Ainsi, le terminal validant la valeur de confirmation est sûr que l'application est effectivement sélectionnée dans l'élément sécurisé. Il peut donc envoyer des commandes subséquentes à l'application sélectionnée sans risque de détournement de celles-ci dans l'élément sécurisé.

20 Dans un mode de réalisation, le terminal externe met à jour la variable dynamique secrètement partagée lorsque la vérification de la valeur de confirmation est positive. Cette disposition garantit la synchronisation de la variable dynamique partagée. Comme illustré par la suite, il peut en faire de même pour mettre à jour une variable distincte dynamique (non nécessairement secrète), tel un compteur.

25 Dans un mode de réalisation, de façon similaire à la valeur dynamique d'identifiant DynVal, la vérification ou génération de la valeur de confirmation comprend le calcul d'une valeur dynamique de confirmation DynAck selon la formule suivante : DynAck = zRMB ( hash ( H ) ), où zRMB (y) est une fonction qui renvoie z octets de y (par exemple le ou les 30 z octets de droite de y) ; hash (.) est une fonction de hachage ; et H est une valeur formée au moins en partie à partir de la variable dynamique secrètement partagée, par exemple H= S/ h /C comme décrit ci-dessus. Ainsi H peut être le même pour les calculs de DynAck et DynVal. A titre illustratif, xLMB renvoie les x octets de gauche et zRMB renvoir les z 35 octets de droite. Ainsi, on peut choisir x+z = le nombre d'octets de hash ( H ). Il en 3025631 10 résulte que Dyn Val et DynAck forment l'intégralité de hash ( H ) : Dyn Val / DynAck = hash ( H ). On notera toutefois que l'ensemble de ces informations ne devient accessible à une personne malveillante (qui scrute les échanges de messages) que lorsque ces valeurs deviennent périmées.

5 Si x+z est strictement inférieur au nombre d'octets de hash ( H ), hash ( H ) = Dyn Val I Reste / DynAck, où Reste représente les octets de la valeur de hash ( H ) qui ne transitent jamais dans le couple commande/réponse. Cette configuration accroît encore plus la sécurité du système, notamment dans les exemples décrits par ailleurs où hash ( H ) forme la nouvelle valeur de la variable dynamique secrètement partagée.

10 Dans un mode de réalisation, la mise à jour, par le terminal externe, de la variable dynamique secrètement partagée comprend les étapes suivantes : obtenir une valeur courante de la variable dynamique secrètement partagée à partir de laquelle l'identifiant de l'application est généré ; calculer une valeur de mise à jour de la variable dynamique secrètement 15 partagée, typiquement celle prévue pour remplacer la valeur courante si la sélection de l'application s'avère effective ; et si la valeur de confirmation contenue dans la réponse n'est pas correcte, infirmant la sélection effective de l'application par l'élément sécurisé, définir la valeur de mise à jour comme nouvelle valeur courante de la variable dynamique secrètement 20 partagée. Cette disposition permet de resynchroniser le terminal externe avec l'élément sécurisé, par exemple lorsque une désynchronisation a lieu en raison de la non réception d'une réponse confirmant une précédente sélection effective de l'application, ou d'une commande tronquée suite à des problèmes de communication.

25 En effet, dans ce cas de désynchronisation, le terminal externe n'a pas mis à jour la variable dynamique partagée et utilise donc une valeur courante de variable erronée. Le processus ci-dessus permet ainsi d'obtenir confirmation que la sélection effective a bien eu lieu : soit une confirmation est directement obtenue en réponse, assurant que la valeur courante de la variable dynamique secrètement partagée est 30 bonne ; soit la réponse infirme la sélection de l'application, indiquant que ladite valeur courante est erronée, auquel cas celle-ci doit être mise à jour. Cependant, il se peut aussi que le traitement n'ait pas abouti, ou simplement que le terminal était déjà désynchronisé. En de telles circonstances, le terminal sera intéressé à obtenir les données de synchronisation courantes, c'est-à-dire la valeur 35 courante des variables partagées pour vérifier s'il doit ou non mettre à jour sa variable 3025631 11 dynamique secrètement partagée. Il est décrit dans le présent document un mécanisme permettant d'obtenir les données de synchronisation (valeurs courantes des variables partagées). Sans ce mécanisme, le terminal pourrait demeurer désynchronisé s'il l'est.

5 On constatera que le processus de synchronisation proposé peut avoir lieu à n'importe quelle commande de sélection émise par le terminal externe. Ainsi pour réaliser la sélection de l'application, le terminal externe doit à nouveau faire une demande de sélection en utilisant la nouvelle valeur courante de la variable dynamique secrètement partagée, alors mise à jour. Ainsi, le procédé au 10 niveau du terminal externe peut comprendre en outre, postérieurement à l'étape de définition, une étape consistant à envoyer, à l'élément sécurisé, une autre commande de sélection de l'application en utilisant un identifiant de l'application généré à partir de la valeur courante nouvellement définie de la variable dynamique secrètement partagée.

15 L'invention a également pour objet un produit programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes d'un des procédés décrits précédemment lorsque ledit programme est exécuté sur un ordinateur. Le produit programme d'ordinateur selon l'invention présente des avantages 20 similaires à ceux exposés précédemment en lien avec les procédés. BREVE DESCRIPTION DES FIGURES D'autres avantages, buts et caractéristiques particulières de la présente invention ressortiront de la description qui va suivre faite, dans un but explicatif et 25 nullement limitatif, en regard des dessins annexés, dans lesquels : La Figure 1 illustre des communications selon l'art antérieur entre un terminal externe (Master) et une carte à puce (Slave) ; La Figure 2 illustre l'intervention d'une personne mal intentionnée dans le processus de la Figure 1 pour interrompre une transaction financière par la sélection 30 d'une autre application ; La Figure 3 illustre un autre cas de détournement du processus de la Figure 1 par une personne mal intentionnée ; La Figure 4 illustre, de manière simplifiée, un exemple de système dans lequel des modes de réalisation de la présente invention peuvent être mis en oeuvre ; 3025631 12 La Figure 5 illustre un exemple d'architecture matérielle pour le ou les équipements constitutifs du système décrit en référence à la Figure 4 ; et La Figure 6 illustre une mise en oeuvre de l'invention pour sécuriser la sélection et l'accès à une application App C d'une carte à puce, selon des modes de 5 réalisation de l'invention. DESCRIPTION DETAILLEE DE L'INVENTION La Figure 4 illustre, de manière schématique, un exemple de système dans lequel des modes de réalisation de la présente invention peuvent être mis en oeuvre.

10 Dans cet exemple, l'élément sécurisé est une carte à puce 10 comportant un gestionnaire de carte 12 et trois applications App A 14, App B 16, App C 18, par exemple des applets SIM Toolkit exécutables dans un environnement applicatif JavaCard. Comme décrit précédemment, le gestionnaire de carte 12 officie comme sélecteur d'application (en fonction d'une commande SELECT reçue d'un terminal 15 externe 20 dans le cas du protocole APDU) et donc comme organe de routage de commandes reçues ultérieurement sur le même canal de communication avec le terminal externe 20. Le gestionnaire de carte 12 et les applications (ou applets) 14, 16, 18 peuvent consister en des programmes informatiques exécutés par un processeur de la carte à 20 puce 10. Le terminal externe 20 est, dans cet exemple, un lecteur de carte à puce permettant de communiquer avec la carte à puce 10. A titre d'exemple, le terminal externe 20 est un terminal de paiement, un téléphone mobile dans lequel la carte à puce 10 est installée ou une borne de lecture de cartes à puce. De façon connue en 25 soi, la communication entre le terminal externe 20 et la carte à puce 10 peut être filaire, par exemple selon la norme ISO/IEC 7816 via des contacts affleurant la carte 10, ou peut être sans fil, par exemple selon la norme ISO/IEC 14443 ou encore la norme NFC en utilisant des antennes de communication sans fil. Le protocole APDU peut être utilisé pour ces communications, bien que l'invention s'applique également à d'autres 30 types de protocole. Selon l'invention, l'identifiant d'application AID utilisé dans la commande SELECT est dynamique, en ce qu'il est dynamiquement renouvelé à chaque nouvelle commande SELECT, c'est-à-dire qu'il change à chaque nouvelle commande de sélection de la même application. Pour sécuriser le processus de sélection de 35 l'application, l'invention prévoit l'utilisation d'au moins une variable dynamique (c'est-à- 3025631 13 dire changeante dans le temps) qui est secrètement partagée entre le terminal externe 20 et la carte à puce 10, variable dynamique partagée sur la base de laquelle l'identifiant d'application AID selon l'invention est formé. Dans un mode de réalisation, cette variable dynamique secrètement partagée peut être calculée ou formée à partir 5 d'une variable dynamique (qui peut être publique) et d'un secret partagé entre le terminal et la carte. Bien entendu, selon le processus dynamique de calcul de l'identifiant AID, une même valeur d'identifiant pourra être réutilisée plusieurs fois au cours de la vie de l'application et de la carte à puce 10, pour autant qu'elle ne soit pas consécutive et que 10 la variable dynamique secrètement partagée garantisse qu'il ne soit pas possible de prédire quand une valeur particulière d'identifiant pourra être utilisée. Comme il ressortira de la description ci-dessous, le terminal externe 20 est donc configuré pour supporter des mécanismes de génération d'un identifiant AID dynamique selon l'invention et des mécanismes de vérification de réponses 15 dynamiques envoyées par les applications sélectionnées. Symétriquement, ces applications de la carte à puce 10 sont donc configurées pour supporter des mécanismes de vérification de la partie dynamique des identifiants AID dynamiques reçus et pour générer des réponses dynamiques au terminal externe 20.

20 Une valeur initiale de l'au moins une variable dynamique secrètement partagée peut notamment être échangée entre le terminal externe 20 et la carte 10 lors d'un processus initial, par exemple lors de l'installation de l'application à laquelle cette variable dynamique secrètement partagée est associée. Puis, lors de la vie de la carte à puce 10, cette dernière et le terminal externe 20 font évoluer de façon identique la 25 valeur de cette variable dynamique secrètement partagée (par exemple en fonction d'une variable dynamique et d'un secret) afin le terminal externe 20 et la carte 10 puissent identifier de façon identique une même application lorsqu'une commande SELECT est émise. Cette évolution symétrique peut néanmoins souffrir d'une désynchronisation 30 qui pourra être corrigée comme décrit par la suite dans des modes de réalisation de l'invention. Bien que l'exemple de la Figure 4 illustre le cas d'un seul terminal externe 20, les modes de réalisation de l'invention décrits par la suite s'appliquent également au cas où au moins une variable dynamique associée à une application donnée est 35 secrètement partagée entre la carte à puce 10 et une pluralité de terminaux externes 3025631 14 20 avec lesquels la carte à puce 10 peut être amenée à communiquer. Dans ce cas, il convient d'assurer une synchronisation sécurisée de la valeur de la variable dynamique entre l'ensemble des terminaux externes 20, dès lors que l'un d'entre eux procède à une mise à jour de cette valeur comme décrit par la suite. Cette 5 synchronisation peut être assurée par les terminaux externes entre eux, par la carte à puce 10 ou par toute autre entité d'un réseau de communication auquel sont connectés les terminaux externes. La Figure 5 illustre un exemple d'architecture matérielle de chaque équipement constitutif du système décrit en référence à la Figure 4.

10 Dans cet exemple, l'équipement, c'est-à-dire la carte à puce 10 ou le terminal externe 20, comprend un bus de communication auquel sont reliés : - une unité de traitement -ou microprocesseur- notée CPU (sigle de Central Processing Unit en terminologie anglo-saxonne) ; - une ou plusieurs mémoires non volatile par exemple ROM (acronyme de 15 Read Only Memory en terminologie anglo-saxonne) pouvant constituer un support au sens de l'invention, c'est-à-dire pouvant comprendre un programme informatique comprenant des instructions pour la mise en oeuvre d'un procédé selon un mode de réalisation de l'invention ; cette mémoire non volatile peut également être une mémoire EEPROM (acronyme de ElectricallyErasable Read Only Memory en terminologie 20 anglo-saxonne) ou encore une mémoire Flash ; - une mémoire vive ou mémoire cache ou mémoire volatile par exemple RAM (acronyme de Random Access Memory en terminologie anglo-saxonne) comprenant des registres adaptés à l'enregistrement des variables et paramètres créés et modifiés au cours de l'exécution du programme précité ; lors de la mise en oeuvre de l'invention, 25 les codes d'instructions du programme stocké en mémoire morte ROM sont chargés en mémoire RAM en vue d'être exécutés par l'unité de traitement CPU ; - une interface de communication adaptée à transmettre et à recevoir des données, par exemple via un réseau de télécommunications ou une interface de lecture/écriture d'un élément sécurisé ; 30 - une interface d'entrées/sorties I/O (pour Input/Output en terminologie anglo- saxonne), par exemple un écran, un clavier, une souris ou un autre dispositif de pointage tel qu'un écran tactile ou une télécommande ; cette interface I/O permet à l'utilisateur d'interagir avec le système au cours de la mise en oeuvre du procédé via une interface graphique.

3025631 15 Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans l'équipement ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité de traitement est susceptible de communiquer des instructions à tout élément de l'équipement directement ou par 5 l'intermédiaire d'un autre élément de cet équipement. La Figure 6 illustre un exemple de mise en oeuvre de l'invention permettant de sécuriser la sélection d'une application App A dans la carte à puce 10 lors d'un accès à cette application. Comme évoqué précédemment, la carte à puce 10 et le terminal externe 20, 10 par exemple un téléphone mobile embarquant la carte à puce, conviennent au préalable, par exemple lors de l'installation de l'application App A, d'une valeur initiale d'au moins une variable dynamique qu'ils vont partager secrètement, d'éventuellement autres valeurs initiales pour d'autres variables dynamiques (par exemple un compteur) et de modalités d'évolution dynamique de cette variable. Cette variable ou ensemble 15 de variables dynamiques est propre à l'application App A, signifiant qu'il y a autant d'ensembles de variables dynamiques qu'il y a d'applications sélectionnables sur la carte 10. Par exemple, la carte à puce 10 et le terminal externe 20 définissent une valeur initiale d'une variable dynamique secrètement partagée, une valeur initiale d'un 20 compteur et définissent des fonctions f et g utilisées lors de la sélection de l'application App A selon l'invention. A noter que les mêmes fonctions f et g peuvent être utilisées par plusieurs applications de la carte à puce 10, notamment par l'ensemble des applications. Dans la suite, on dénote par l'indice « i » l'itération courante de sélection 25 d'une application (à chaque nouvelle sélection de l'application, l'indice i est incrémenté de 1). AID(i) est donc l'identifiant d'application courant, alors que AID(i-1) est le dernier identifiant utilisé. Il est à noter que cette procédure visant à définir les informations initiales est notamment mise en oeuvre à chaque fois qu'un canal sécurisé est ouverte entre la 30 carte et le terminal. A cette occasion, l'identité (par exemple un numéro de série SN) de la carte est soit explicitement, soit implicitement fournie au terminal, afin que ce dernier puisse par exemple retrouver les valeurs courantes des variables partagées, valeurs courantes qui constituent donc les valeurs initiales pour le nouveau canal sécurisé.

3025631 16 Dans un mode de réalisation, cette identification de la carte par le terminal peut se faire par une commande de type GET DATA ou par lecture de l'AIR (« Answer To Reset », une des premières réponses reçue de la carte lors de sa mise sous tension par le terminal).

5 Une identification implicite est également possible, par exemple lors du processus de personnalisation de la carte à puce. Les valeurs courantes des variables partagées (permettant de synchroniser le terminal et la carte) sont par exemple stockées dans une base de données en association avec l'identité de la carte concernée. La base de données peut être 10 stockée dans le terminal lui-même ou dans un serveur commun (« entité de réseau » évoquée plus haut) à plusieurs terminaux. Si le terminal est incapable de récupérer ces valeurs courantes/initiales, il peut être prévu que la réponse à la commande GET DATA ci-dessus renvoie également des informations permettant de déterminer ces valeurs courantes/initiales, par exemple 15 la réponse à la commande peut contenir ces valeurs courantes/initiales codées à l'aide d'une clé de chiffrement symétrique. Egalement ces valeurs peuvent être incluses dans une réponse à une commande SELECT qui a échoué, comme évoqué par la suite. Ainsi, en l'absence de ces valeurs courantes/initiales, le terminal peut envoyer une commande SELECT qui 20 identifie l'application souhaitée mais qu'il sait erronée car il n'a pu calculer l'AID dynamique, et ainsi recevoir en réponse les valeurs courantes/initiales à désormais utiliser. Dans un mode de réalisation, l'identifiant AID comprend une partie fixe FixAID d'identification de l'application à sélectionner et une partie dynamique DynAID de 25 vérification, ladite partie dynamique DynAID étant basée sur l'au moins une variable dynamique secrètement partagée. Comme il ressortira de la description qui suit, la partie fixe FixAID est utilisée par la carte à puce pour identifier l'application à sélectionner, alors que la partie dynamique DynAID est utilisée pour vérifier la légitimité de l'émetteur de la commande SELECT qui comprendrait l'identifiant AID dynamique.

30 Par exemple, l'identifiant AID peut comprendre jusqu'à 16 octets, par exemple 12 octets dont les M premiers définissent FixAID et les N derniers définissent DynAID. Dans l'exemple repris par la suite, M = 8 où FixAID est formé de la concaténation d'un RID (identifiant de fournisseur sur cinq octets) et d'un identifiant ID d'application pour le propriétaire (sur trois octets) : 3025631 17 AID dynamique 16 octets FixAID DynAID M (p.ex. 8 octets) N (p.ex. 4 octets) RID ID PIX 5 octets 3 octets 4 octets La partie fixe FixAID est connue de la carte à puce et du terminal externe dès l'installation de l'application concernée. Dans une variante, la carte à puce peut informer un terminal externe auquel elle est connectée, de l'ensemble des applications 5 dont elle dispose, en listant notamment les couples {RID,ID}. Dans un mode de réalisation, f(S,h,C) = 4LMB ( hash (S1hIC)) où la fonction 4LMB sélectionne les quatre octets de gauche d'une variable ; la fonction hash est une fonction de hachage, type SHA-256 ou fonction HMAC K (K étant une clé cryptographique secrètement partagée) ; est la fonction de concaténation ; S est une 10 valeur fixe connue de la carte 10 et du terminal externe 20 ; et h et C sont deux variables dynamiques partagées au sens de l'invention, c'est-à-dire générées de façon similaire par le terminal externe 20 et la carte 10, le cas échéant à partir de deux valeurs initiales h(0) et C(0) convenues au préalable. Dans les exemples ci-dessous, h est secrètement partagée alors que C ne l'est pas nécessairement.

15 Bien entendu d'autres fonctions (que 4LMB) retournant tout ou partie des octets de hash (S / h / C) peuvent être utilisées. S, h et C sont spécifiques à une application donnée, et donc peuvent être mémorisées par cette application. S peut prendre n'importe quelle valeur. En variante, S = FixAID. 20 h est une valeur de hachage, c'est-à-dire obtenue à l'aide d'une fonction de hachage, par exemple sur 32 octets. h peut être une valeur de hachage calculée à partir d'une valeur de hachage précédente secrètement partagée et utilisée pour un précédent identifiant de l'application lors d'une précédente sélection de l'application, c'est-à-dire une valeur de 25 hachage récursivement mise à jour, nécessitant de convenir d'une valeur initiale h(0). Par exemple, h = hash (S / h / C) obtenue lors de la précédente invocation de la fonction f, c'est-à-dire généralement lors du précédent calcul de la partie dynamique DynAID, que ce soit sur le terminal externe 20 pour identifier l'application à sélectionner par la commande SELECT, ou sur la carte 10 pour vérifier la validité d'un 3025631 18 identifiant dynamique AID reçu. En effet, la fonction f, comme il ressortira des explications ci-dessous, est utilisée par le terminal externe 20 pour générer l'identifiant AID à indiquer dans la commande SELECT, alors qu'elle est utilisée par la carte 10 pour vérifier l'identifiant AID contenu dans une commande SELECT reçue, de sorte à 5 autoriser la sélection de l'application uniquement en cas de vérification positive. En faisant référence aux itérations I' de sélection d'une application : h(i) = hash ( S I h(i-1) I C(i-1) ) En variante, h(i) = hash ( S / C(i-1) ), situation dans laquelle h(i) est donc indépendant de h(i-1). Dans cette configuration, la fonction de hachage hash peut 10 dépendre d'un secret (une clé K par exemple), de sorte que h(i) est finalement une variable dynamique secrètement partagée. En variante, h(i) = hash ( S / h(i-1) ). De la même manière, la fonction de hachage hash peut dépendre d'un secret (une clé K par exemple), de sorte que h(i) est finalement une variable dynamique secrètement partagée.

15 La valeur h(0) correspond par exemple à une valeur aléatoire, ou est fonction de S. Cette valeur est instanciée lors de la personnalisation de la carte 10, et partagée par la carte 10 et le terminal externe 20. C est un compteur qui est mis à jour à chaque sélection effective de l'application associée, prenant initialement la valeur C(0). Dans un mode de réalisation, 20 la valeur de mise à jour du compteur C dynamique est fonction de l'au moins une variable dynamique secrètement partagée afin notamment de rendre difficilement prédictible la nouvelle valeur de C pour une entité étrangère. Par exemple, lors de cette mise à jour, C est augmenté de la valeur de un ou plusieurs octets composant la valeur de hachage h (secrètement partagée) utilisée dans la fonction f pour générer 25 l'AID dynamique, par exemple de la valeur de l'octet le plus à droite : C(i) = C(i-1) + 1 RMB ( h(i) ) + 1, où 1RMB est la fonction retournant l'octet le plus à droite. Bien entendu d'autres fonctions (que 1RMB) retournant tout ou partie des octets de h(i) peuvent être utilisées. Compte tenu de la taille de la variable C, par exemple sur quatre octets, une 30 opération « modulo » est mise en place pour éviter un débordement. Dans un mode de réalisation, g(S,h,C) = 8RMB ( hash (S / h / C)) avec 8RMB la fonction retournant les huit octets les plus à droite. Bien entendu d'autres fonctions (que 8RMB) retournant tout ou partie des octets de hash(S1hIC) peuvent être utilisées.

3025631 19 Comme il ressortira des explications ci-dessous, cette fonction g est utilisée par la carte 10 pour générer une valeur de confirmation (qui dépend donc de l'au moins une variable dynamique secrètement partagée. La valeur de confirmation est donc secrète) qu'elle renseigne dans une réponse à la commande SELECT, notamment 5 pour confirmer la sélection effective de l'application souhaitée. Symétriquement, le terminal externe 20 va l'utiliser pour vérifier que la valeur de confirmation reçue dans une telle réponse à la commande SELECT est correcte, auquel cas la sélection effective de l'application souhaitée est confirmée. Une fois ces différents éléments définis entre le terminal externe 20 et la carte 10 à puce 10, le procédé de l'exemple de la Figure 6 débute, pour l'itération courante « i », à l'étape 600 où le terminal externe 20 reçoit, par exemple d'un utilisateur, un événement requérant l'utilisation de l'application App A 14 de la carte à puce 10. Cet événement déclenche ainsi la formation d'une commande SELECT par le terminal externe 20.

15 A l'étape 602, le terminal externe 20 calcule une nouvelle partie dynamique DynAID(i) associée à l'application App A, compte tenu des valeurs courantes des variables dynamiques partagées. Notamment, le terminal 20 calcule DynAID(i) à l'aide de la fonction f et des valeurs courantes de la variable dynamique secrètement partagée h(i-1) et du compteur dynamique partagé C(i-1) : 20 DynAID(I) = f (S,h(i-1),C(i-1)) Cette opération peut être effectuée en deux étapes: h*(i) = hash ( S I h(i-1) I C(i-1) ) DynAID(I) = 4LMB ( h*(t) ) Le symbole `"' est utilisé ici pour désigner une nouvelle valeur temporaire 25 calculée pour une variable dynamique partagée (ici pour l'itération « i »). L'affectation effective de cette nouvelle valeur à la variable dynamique partagée n'est réalisée que lorsque la sélection de l'application par la commande SELECT est devenue effective. Cela est expliqué plus en détails par la suite. Dans un mode de réalisation, S=FixAID, la fonction de hachage est SHA-256 30 et la valeur de hachage h est récursive. Ainsi, h*(i) = SHA-256 ( FixAID, h(i-1), C(i-1) ), par exemple SHA-256 ( FixAID / h(i-1) / C(i-1) ). Dans un mode de réalisation, S=FixAID, la fonction de hachage est HMAC K, avec K une clé de chiffrement symétrique secrètement partagée, et la valeur de hachage h est récursive. Ainsi, h*(i) = HMAC K ( FixAID / h(i-1) / C(i-1) ).

3025631 20 Dans un autre mode de réalisation, la valeur DynAID(i) n'est pas liée à la valeur DynAID(i-1), c'est-à-dire de l'itération précédente. Par exemple, avec S=FixAID, la fonction de hachage HMAC K et la valeur de hachage h non récursive mais calculée à chaque itération : 5 h*(i) = HMAC K (i) = hash ( K , S I C(i-1)), et hash est une fonction de hachage, par exemple SHA-1 ou SHA-256. Puis à l'étape 604, le terminal 20 génère l'identifiant dynamique AID pour l'application App A : AID = RID 1 ID 1 DynAID(i), où RID et ID sont associés à l'application App A.

10 Il génère aussi une valeur temporaire C* du compteur C, qui correspond à la prochaine valeur à utiliser si la présente sélection de l'application s'avère être effectivement réalisée. Comme décrit dans un exemple ci-dessous, C* = C + 1RMB ( h* ) + 1 = C(i-1) + 1RMB ( h(i) ) + 1.

15 A l'étape 606, le terminal 20 génère et envoie, à la carte à puce 10, une commande de sélection de l'application App A, contenant l'identifiant dynamique AID ainsi généré. A l'étape 608, le gestionnaire de carte 12 vérifie la partie fixe FixAID de l'identifiant AID reçu. En particulier, il vérifie qu'il existe bien, dans la carte 10, une 20 application portant l'identifiant ID pour le propriétaire RID, c'est-à-dire l'application App A. En cas de vérification négative, le gestionnaire 12 retourne un message d'erreur (non représenté, par exemple la réponse SW 1 = 6A et SW 2 = 82 [voir la norme ISO/IEC 7816-4 pour les champs SW 1 et SW 2]) au terminal externe 20, ce qui 25 met fin au traitement. Si la vérification de FixAID est positive, le gestionnaire 12 envoie une commande de vérification de la partie dynamique DynAID à l'application App A identifiée par la partie fixe FixAID. C'est l'étape 610. Aux étapes 612 et 614, l'application App A vérifie que la partie dynamique 30 DynAID(i) reçue est correcte. Pour ce faire, l'application App A effectue le même calcul que celui réalisé par le terminal externe 20 pour générer DynAID à l'étape 612, mais cette fois-ci avec les valeurs courantes que l'application App A possède pour les variables dynamiques partagées.

3025631 21 Ainsi, elle calcule DynAIDCheck(i) = f (S,h(i-1),C(i-1)), avec S, h et C tels que couramment stockés par l'application App A. Cette opération peut être effectuée en deux étapes: h*(i) = hash ( S I h(i-1) I C(i-1) ) 5 DynAIDCheck(i) = 4LMB ( h*(i) ) A l'étape 614, l'application App A compare DynAIDCheck(i) avec DynAID(i) reçu. Si les deux valeurs sont différentes, l'application App A retourne un message d'erreur au gestionnaire de carte 12 (par exemple un message avec le statut SW 1 = 10 6A et SW 2 = 82) afin qu'il ne sélectionne pas l'application App A. Le gestionnaire 12 émet à son tour un message d'erreur (par exemple avec les mêmes valeurs SW 1 = 6A et SW 2 = 82) au terminal externe 20, mettant fin au traitement, à l'exception du mécanisme de resynchronisation tel qu'expliqué par la suite. Dans un mode de réalisation, le message d'erreur retourné au terminal en 15 réponse à la commande SELECT qui a échoué (par exemple uniquement une première commande SELECT dans un nouveau canal sécurisé) peut inclure les valeurs courantes h(i-1) et C(i-1), de préférence chiffrées à l'aide d'une clé de chiffrement symétrique secrète. Ces informations permettent au terminal de récupérer les valeurs initiales des variables dynamiques partagées, comme évoqué plus haut.

20 Si les deux valeurs sont égales, la vérification de la partie dynamique DynAID(i) est positive, et un message de statut de vérification positive est envoyé au gestionnaire de carte 12 à l'étape 616, lui permettant de sélectionner de façon effective l'application App A (étape 618). La sélection effective de l'application App A consiste par exemple à ce que le gestionnaire de carte 12 est maintenant autorisé à transmettre 25 toute nouvelle commande reçue du terminal externe 20 vers l'application App A (autres qu'une nouvelle commande SELECT). Il est à noter que cette vérification et le message de statut qui s'en suit ne doivent pas impacter les traitements d'une autre application qui est actuellement sélectionnée dans la carte 10. En effet, s'il en était autrement, ce mécanisme de 30 vérification et de message de statut serait un moyen d'interférer dans les traitements de cette autre application. En parallèle à l'étape 619, l'application App A qui vient de valider la partie dynamique DynAID(i) met à jour ses registres mémorisant les variables dynamiques partagées : 35 h(i) = h*(i) 3025631 22 C(i) = C(i-1) + 1RMB ( h(i) ) + 1. h n'a pas besoin d'être mis à jour dans les modes de réalisation où DynAID(i) ne dépend pas de la valeur de hachage h(i-1) utilisée pour la génération de DynAID(i1), h(i) étant calculé à la volée. En d'autres termes, lorsque DynAID(i) n'est pas lié à la 5 valeur DynAID(i-1) de l'itération précédente. Bien entendu, cette étape 619 peut être effectuée après l'étape 620 décrite ci- dessous où les valeurs h(i-1) et C(i-1) sont utilisées, notamment lorsque ces variables consistent, chacune, en une seule valeur en mémoire : h h* et C C + 1RMB(h) + 1.

10 Cependant, dans la mesure où la valeur h* peut être utilisée lors de l'étape 620 ci-dessous, la mise à jour 619 peut également avoir lieu avant l'étape 620 même lorsque les variables C et h consistent en une seule valeur en mémoire. La mise à jour peut être réalisée par une opération atomique de sorte à ce que les deux valeurs soient mise à jour ensemble, sans risque qu'une perturbation 15 puisse conduire à un décalage d'itération : h= h* CTmp = C 1RMB ( h ) + 1 IF CTMp > 'FF FF FF FF' CTMp = ( CTMp MODULO 'FF FF FF FF') - 1 20 C = CTMP En parallèle également, à l'étape 620, l'application App A calcule une valeur de confirmation de sélection qui est synchronisée avec la partie dynamique DynAID(i) courante afin que seuls le terminal externe 20 et la carte 10 en aient connaissance. Notamment la valeur de confirmation DynAck est calculée à partir des 25 variables dynamiques partagées : DynAck(i) = g (S,h(i-1),C(i-1)) = 8RMB (h*(i) ), h*(i) ayant déjà été calculé pour DynAIDCheck. Bien entendu, d'autres fonctions (que 8RMB) peuvent être utilisées pour retourner tout ou partie des octets de h*(i). On note ici que h*(i) = DynAID(i) DynAck(i) = DynAIDCheck(i) DynAck(i).

30 A titre illustratif, dans un mode de réalisation où S=FixAID, la fonction de hachage est SHA-256 et la valeur de hachage h est récursive, h*(i) = SHA-256 ( FixAID, h(i-1), C(i-1) ), par exemple SHA-256 ( FixAID / h(i-1) / C(i-1) ). A l'étape 622, l'application App A (éventuellement via le gestionnaire 12) envoie, au terminal externe 20, une réponse de sélection confirmant la sélection de 35 l'application App A, la réponse incluant la valeur DynAck(i).

3025631 23 Par exemple, la réponse peut être formatée en champs BER-TLV selon la norme ISO/IEC 7816-4, comme suit : Champ Longueur Description Corps de '6F' ... - la réponse '84' ... FixAID `A5' ... Données propriétaires 'BFOC' ... Par exemple le numéro de série de la carte concaténé à la valeur du compteur dynamique : SN 1C '9F01' 8 Valeur de confirmation Statut SW 1 1 '90' SW 2 1 '00' Aux étapes 624 et 626, le terminal externe 20 vérifie que la valeur de 5 confirmation DynAck(i) reçue est correcte. Pour ce faire, le terminal externe 20 effectue le même calcul que celui réalisé par la carte 10 pour générer DynAck à l'étape 620, mais avec les valeurs courantes que le terminal externe 20 possède pour les variables dynamiques partagées. Ainsi, le terminal externe 20 calcule DynAckCheck(i) = g (S,h(i-1),C(i-1)), avec 10 S, h et C tels que couramment stockés par le terminal externe 20. Comme h*(i) a déjà été calculé pour DynAID, DynAckCheck(i) = 8RMB ( h*(i)). Bien entendu, d'autres fonctions (que 8RMB) peuvent être utilisées pour retourner tout ou partie des octets de h*(i). A l'étape 626, le terminal externe 20 compare DynAckCheck(i) avec DynAck(i) 15 reçu. Si les deux valeurs sont identiques, cela signifie que l'application App A a bien été sélectionnée et que le terminal externe 20 peut interagir avec l'application App A. Par exemple, le terminal externe 20 peut ainsi envoyer d'autres commandes à la carte 10 que l'application App A ainsi sélectionnée va traiter.

20 Par exemple, le terminal externe 20 peut envoyer la commande GET DATA conforme au standard ISO/IEC 7816-4 pour tester que l'application App A a bien été sélectionnée par le gestionnaire de carte 12. Ainsi, suite à une comparaison positive à l'étape 626, le terminal externe 20 met à jour, à l'étape 628, les variables dynamiques partagées qu'il stocke localement, 3025631 24 de façon similaire à ce qui a été décrit ci-dessus pour l'étape 619. On note d'ailleurs que C* ayant déjà été calculé (voir l'étape 604), cette étape 628 peut se résumer à : h= h* C= ( C* MODULO 'FF FF FF FP ) - 1 5 Puis les deux valeurs temporaires h*et C* sont réinitialisées à zéro. Ainsi, h* et C* associés à l'application App A valent zéro uniquement lorsque la sélection effective de l'application App A a été valablement confirmée. Si les deux valeurs DynAckCheck(i) avec DynAck(i) sont différentes, cela signifie que soit une personne malintentionnée tente de corrompre le système, soit le 10 terminal externe 20 et la carte 10 sont désynchronisés, par exemple parce que la précédente réponse incluant la valeur de confirmation DynAck n'a pas été reçue par le terminal externe 20 (ce peut être dû à une perturbation sur le canal de communication). Si les valeurs temporaires h* et C* sont non nulles, il est probable que le terminal externe 20 et la carte 10 sont désynchronisés. Dans ce cas, à l'étape 630, le 15 terminal externe 20 affecte les valeurs temporaires h* et C* aux variables h et C, respectivement. Cette opération permet de resynchroniser les deux entités. Puis les deux valeurs temporaires h*et C* sont réinitialisées à zéro. Ce mécanisme de resynchronisation est ainsi mis en oeuvre automatiquement à n'importe quelle itération « i » de sélection de l'application App A.

20 Le procédé peut décider automatiquement de reboucler à l'étape 600 afin de procéder à une nouvelle tentative de sélection de l'application App A, à partir des nouvelles valeurs h et C. En variante, le terminal externe 20 peut indiquer à l'utilisateur que la sélection de l'application App A n'a pas eu lieu mais que le terminal externe 20 s'est resynchronisé avec la carte 10 et ainsi inviter l'utilisateur à déclencher à nouveau 25 le processus de sélection de l'application App A. La nouvelle tentative de sélection de l'application App A devrait se dérouler avec succès s'il y avait uniquement une désynchronisation entre les deux entités. Le succès de cette nouvelle tentative permet ainsi au terminal externe 20 de valider, a posteriori, le succès d'une précédente tentative de sélection (celle pour laquelle h* et 30 C* avaient été générés, mais aucune valeur de confirmation n'avait été reçue). En revanche, si l'une au moins des valeurs temporaires h* et C* est nulle, il est probable qu'une personne malveillante tente de corrompre le système. Un message d'erreur peut alors être retourné à l'utilisateur (étape 632). Comme le processus de la Figure 6 est réalisé à chaque nouvelle commande 35 de sélection d'une même fonction alors que les valeurs h et C évoluent 3025631 25 dynamiquement, le terminal externe 20 envoie, à l'élément sécurisé 10, une nouvelle commande de sélection de la même application App A comprenant un autre identifiant AID de l'application à sélectionner qui est différent de l'identifiant de la commande de sélection précédemment envoyée.

5 Bien que la description ci-dessus montre l'application App A réaliser les étapes de vérification 612, 614 et de réponse dynamique 620, celles-ci pourraient en variante être réaliser par le gestionnaire de carte 12 pour le compte des applications. Il est à noter également que si les normes ISO/IEC 7816, EMV, Global Platform, etc. susvisée autorisent le gestionnaire de carte 12 à sélectionner des 10 applications en utilisant partiellement les identifiants AID reçus, le gestionnaire de carte 12 dans les modes de réalisation de l'invention s'appuie sur l'entièreté des identifiants AID reçus pour effectuer la sélection des applications. En effet, à la fois la partie fixe FixAID et la partie dynamique DynAID sont nécessaires à l'ensemble du processus de sélection sécurisé selon l'invention.

15 Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas. Par exemple, le compteur dynamique pourrait être incrémenté d'un pas de 1 à chaque vérification effectuée avec succès. Notamment, ce compteur pourrait ou non boucler, selon que la limite supérieure est atteinte. 20

Claims (25)

1. REVENDICATIONS1. Procédé d'accès à une application d'un élément sécurisé comprenant au moins une application, le procédé comprenant, au niveau de l'élément sécurisé, les étapes suivantes : recevoir, d'un terminal externe, une commande de sélection d'une application, la commande de sélection comprenant un identifiant de l'application à sélectionner ; et sélectionner ladite application identifiée par la commande de sélection de sorte à router, vers ladite application sélectionnée, une nouvelle commande reçue subséquemment du terminal externe ; le procédé étant caractérisé en ce qu'il comprend un étape consistant à vérifier l'identifiant de l'application contenu dans la commande de sélection à l'aide d'au moins une variable dynamique secrètement partagée entre l'élément sécurisé et le terminal externe, de sorte à autoriser la sélection de l'application uniquement en cas de vérification positive.
2. 2. Procédé d'accès à une application d'un élément sécurisé comprenant au moins une application, le procédé comprenant, au niveau d'un terminal externe à l'élément sécurisé, une étape consistant à envoyer, à l'élément sécurisé, une commande de sélection d'une application de sorte qu'une nouvelle commande envoyée subséquemment à l'élément sécurisé est routée vers ladite application sélectionnée, la commande de sélection comprenant un identifiant de l'application à sélectionner ; le procédé étant caractérisé en ce qu'il comprend en outre une étape consistant à générer l'identifiant de l'application contenu dans la commande de sélection à l'aide d'au moins une variable dynamique secrètement partagée entre l'élément sécurisé et le terminal externe.
3. 3. Procédé selon la revendication, 1 ou 2, dans lequel l'identifiant de l'application comprend une partie fixe FixAID d'identification de l'application à sélectionner et une partie dynamique DynAID de vérification, ladite partie dynamique DynAID étant basée sur la variable dynamique secrètement partagée.
4. 4. Procédé selon l'une des revendications 1 à 3, dans lequel la variable dynamique secrètement partagée est mise à jour à chaque sélection effective de l'application.
5. 5. Procédé selon l'une des revendications 1 à 4, dans lequel la variable dynamique secrètement partagée telle qu'utilisée pour l'identifiant de l'application à 3025631 27 sélectionner comprend une valeur de hachage calculée à partir d'une valeur de hachage précédente secrètement partagée et utilisée pour un précédente identifiant de l'application lors d'une précédente sélection de l'application.
6. 6. Procédé selon la revendication 1, dans lequel l'élément sécurisé met 5 à jour la variable dynamique secrètement partagée dès que ladite vérification de l'identifiant de l'application est positive.
7. 7. Procédé selon la revendication 1 à 6, dans lequel la variable dynamique secrètement partagée est fonction d'un secret partagé entre l'élément sécurisé et le terminal externe, et fonction d'une variable distincte qui est dynamique. 10
8. 8. Procédé selon l'une des revendications 1 à 7, dans lequel la vérification ou génération de l'identifiant de l'application comprend le calcul d'une valeur dynamique d'identifiant DynVal selon la formule suivante : DynVal = xLMB ( hash ( H ) ), où xLMB (y) est une fonction qui renvoie x octets de y ; hash () est une 15 fonction de hachage ; et H est une valeur formée au moins en partie à partir de la variable dynamique secrètement partagée.
9. 9. Procédé selon la revendication 8, dans lequel H=SI hl C où I est la fonction de concaténation ; S est une valeur connue de l'élément sécurisé et du terminal externe ; h est une valeur de hachage et C est une variable distincte 20 dynamique mise à jour à chaque sélection effective de l'application.
10. 10. Procédé selon la revendication 9, dans lequel h vaut la valeur hash (S I h I C) obtenue lors de la précédente itération du calcul de la valeur dynamique DynVal.
11. 11. Procédé selon la revendication 9 ou 10 en dépendance de la 25 revendication 3, dans lequel S vaut la partie fixe FixAID de l'identifiant contenu dans la commande de sélection.
12. 12. Procédé selon la revendication 8 ou 9, dans lequel la variable distincte dynamique est mise à jour avec une valeur de mise à jour fonction de hash ( H ), en cas de sélection effective de l'application. 30
13. 13. Procédé selon les revendications 3 et 8 en dépendance de la revendication 1, dans lequel la vérification de l'identifiant de l'application comprend en outre la comparaison de la valeur dynamique DynVal avec la partie dynamique DynAID de l'identifiant contenu dans la commande de sélection.
14. 14. Procédé selon la revendication 3 en dépendance de la revendication 35 1, dans lequel la vérification de l'identifiant de l'application est effectuée par 3025631 28 l'application identifiée par la partie fixe FixAID de l'identifiant contenu dans la commande de sélection.
15. 15. Procédé selon la revendication 1, comprenant en outre, en cas de vérification positive, la génération et la transmission, au terminal externe, d'une 5 réponse confirmant la sélection effective de l'application, ladite réponse comprenant une valeur de confirmation fonction de ladite variable dynamique secrètement partagée.
16. 16. Procédé selon la revendication 2, comprenant en outre les étapes suivantes : 10 recevoir, de l'élément sécurisé, une réponse confirmant la sélection effective de l'application, ladite réponse comprenant une valeur de confirmation fonction de ladite variable dynamique secrètement partagée ; et vérifier la valeur de confirmation contenue dans la réponse à l'aide de la variable dynamique secrètement partagée. 15
17. 17. Procédé selon la revendication 16, dans lequel le terminal externe met à jour la variable dynamique secrètement partagée lorsque la vérification de la valeur de confirmation est positive.
18. 18. Procédé selon l'une des revendications 15 à 17, dans lequel la vérification ou génération de la valeur de confirmation comprend le calcul d'une valeur 20 dynamique de confirmation DynAck selon la formule suivante : DynAck = zRMB ( hash ( H )), où zRMB (y) est une fonction qui renvoie z octets de y ; hash (.) est une fonction de hachage ; et H est une valeur formée au moins en partie à partir de la variable dynamique partagée. 25
19. 19. Procédé selon la revendication 17, dans lequel la mise à jour, par le terminal externe, de la variable dynamique secrètement partagée comprend les étapes suivantes : obtenir une valeur courante de la variable dynamique secrètement partagée à partir de laquelle l'identifiant de l'application est généré ; 30 calculer une valeur de mise à jour de la variable dynamique secrètement partagée ; et si la valeur de confirmation contenue dans la réponse n'est pas correcte, définir la valeur de mise à jour comme nouvelle valeur courante de la variable dynamique secrètement partagée. 3025631 29
20. 20. Procédé selon la revendication 19, comprenant en outre, postérieurement à l'étape de définition, une étape consistant à envoyer, à l'élément sécurisé, une autre commande de sélection de l'application en utilisant un identifiant de l'application généré à partir de la valeur courante nouvellement définie de la variable 5 dynamique secrètement partagée.
21. 21. Procédé selon la revendication 1, comprenant en outre l'étape suivante : recevoir, du terminal externe, une autre commande de sélection de la même application, ladite autre commande comprenant un autre identifiant de l'application à sélectionner qui est différent dudit identifiant de la commande de sélection. 10
22. 22. Procédé selon la revendication 2, comprenant en outre l'étape suivante : envoyer, à l'élément sécurisé, une autre commande de sélection de la même application, ladite autre commande comprenant un autre identifiant de l'application à sélectionner qui est différent dudit identifiant de la commande de sélection.
23. 23. Elément sécurisé comprenant au moins une application et une 15 interface de communication pour recevoir, d'un terminal externe, une commande de sélection d'une application, la commande de sélection comprenant un identifiant de l'application à sélectionner, l'élément sécurisé étant configuré pour sélectionner ladite application identifiée par la commande de sélection de sorte à router, vers ladite application sélectionnée, une nouvelle commande reçue subséquemment du terminal 20 externe ; l'élément sécurisé étant caractérisé en ce qu'il est configuré pour vérifier l'identifiant de l'application contenu dans la commande de sélection à l'aide d'au moins une variable dynamique secrètement partagée entre l'élément sécurisé et le terminal externe, de sorte à autoriser la sélection de l'application uniquement en cas de 25 vérification positive.
24. 24. Dispositif comprenant une interface de communication pour envoyer, à un élément sécurisé comprenant au moins une application, une commande de sélection d'une application de sorte qu'une nouvelle commande envoyée subséquemment à l'élément sécurisé est routée vers ladite application sélectionnée, la 30 commande de sélection comprenant un identifiant de l'application à sélectionner ; le dispositif étant caractérisé en ce qu'il est configuré pour générer l'identifiant de l'application contenu dans la commande de sélection à l'aide d'au moins une variable dynamique secrètement partagée entre l'élément sécurisé et le dispositif. 3025631 30
25. 25. Produit programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une des revendications 1 à 22, lorsque ledit programme est exécuté sur un ordinateur.