Brevet FR3089653A1 — publié le 20200612

Description Titre de l'invention : Technique d'authentification d'un utilisateur [0001] L'invention se rapporte au domaine général des télécommunications. [0002] L'invention concerne plus particulièrement une technique d'authentification d'un uti- lisateur d'un terminal pour un service. Elle trouve une application particulièrement intéressante dans le cadre de la mise en oeuvre d'un service, hébergé dans un élément de sécurité matériel ou encore logiciel. Ce service requiert une authentification préalable de l'utilisateur par saisie d'un code de service pour réaliser le service. [0003] A cet effet, une entité mémorise le code de service afin de pouvoir vérifier l'identité de l'utilisateur quand cela est nécessaire. [0004] De nouvelles techniques d'authentification de l'utilisateur sont développées sur les terminaux. Plus précisément, des techniques de type biométrique peuvent être mises en oeuvre pour authentifier l'utilisateur. [0005] Dans l'architecture actuelle connue des terminaux mobiles fonctionnant sous le système d'exploitation Android, il n'est actuellement pas possible à un service tiers, c'est-à-dire qui n'est pas mis en oeuvre par le fabricant du terminal, s'exécutant sur un élément de sécurité d'interagir avec des moyens de vérification biométrique du terminal, afin de mettre en oeuvre une authentification biométrique. En effet, dans cette architecture, les services tiers n'ont. pas accès à une connexion physique ou à un canal sécurisé entre l'élément de sécurité et les moyens de vérification biométrique pour supporter une telle interaction. [0006] Il est ainsi impossible pour un service tiers s'exécutant sur l'élément de sécurité, matériel ou bien logiciel, ce terminal fonctionnant sous Android, de proposer une authentification de l'utilisateur par biométrie pour autoriser un usage du service en complément d'une authentification par code de service. [0007] Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des améliorations. [0008] Selon un premier aspect, l'invention a pour objet un procédé d'authentification d'un utilisateur d'un terminal pour un service en fonction d'un code de service, mis en oeuvre par une application s'exécutant sur le terminal. Ce procédé comprend : [0009] - commander un déchiffrement d'un chiffré du code de service, ledit déchiffrement étant conditionné par une authentification biométrique réussie de l'utilisateur ; [0010] - déterminer une donnée d'authentification en fonction du déchiffré du code de service pour vérification en fonction d'une donnée d'authentification attendue. [0011] La technique proposée permet ainsi d'authentifier un utilisateur d'un terminal par biométrie pour autoriser l'usage d'un service, en complément à une authentification par code de service. Il s'agit par exemple d'une vérification d'une empreinte digitale 2 de l'utilisateur. [0012] Grâce à la technique proposée, le service, hébergé dans un élément de sécurité matériel ou logiciel au niveau du terminal, ne nécessite pas d'être modifié afin de prendre en compte ce nouveau type d'authentification. Du point de vue du service, le fonctionnement reste identique, l'application s'exécutant sur le terminal fournissant au service une donnée d'authentification conforme à une authentification par code de service. Le déploiement de la technique proposée dans les terminaux est ainsi simple à réaliser. [0013] De plus, la technique proposée est mise en oeuvre par un module logiciel (l'application) exécuté par un processeur du terminal et ne nécessite pas de modifications d'architecture du terminal, pour permettre à l'application de communiquer avec un capteur hiométrique. La donnée hiométrique de l'utilisateur peut ainsi rester mémorisée dans une zone mémoire sécurisée du terminal et n'est pas fournie à l'application. Ce module logiciel n'implémente aucun traitement de nature hiométrique et n'est pas directement relié à un module de reconnaissance/vérification hiométrique. [0014] L'application dispose uniquement du code de service pour l'application sous forme chiffrée et obtient de manière transitoire le déchiffré du code de service (plus précisément le déchiffré du chiffré du code de service correspondant ainsi au code de service) uniquement lors d'une vérification réussie de la donnée hiométrique associée à l'utilisateur. Par transitoire, on entend que le déchiffré du code de service est uniquement disponible pour déterminer la donnée d'authentification et n'est pas mémorisé de manière durable par l'application. Le fonctionnement de l'application mis en oeuvre pour une authentification par code de service est maintenu. Le déchiffré est par exemple obtenu d'un conteneur sécurisé du terminal, permettant de mettre en oeuvre des opérations cryptographiques et de conditionner ces opérations à des critères, tels qu'une authentification biométrique de l'utilisateur. Ainsi l'application commande un déchiffrement d'un chiffré du code de service au conteneur sécurisé et obtient en retour du conteneur un déchiffré du code de service chiffré, une fois la vérification biométrique de l'utilisateur effectuée. [0015] A titre d'exemple, le service est un service de paiement bancaire à partir d'un terminal mobile. Ce service est mis en oeuvre par l'intermédiaire d'une interface sans contact de type NFC (pour « Near Field Communication ») par une fonction de paiement hébergée dans un élément de sécurité matériel, tel qu'une carte SIM (de type NFC), ou dans un élément de sécurité logiciel (par exemple pour un service de paiement basé sur HCE pour « Host Card Emulation »). [0016] Les différents modes ou caractéristiques de réalisation mentionnés ci-après peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, au procédé d'authentification tel que défini précédemment. 3 [0017] Dans un mode de réalisation particulier, le procédé d'authentification comprend : [0018] - commander un chiffrement du code de service lors d'une phase préalable à l'authentification de l'utilisateur et mémoriser le chiffré du code de service. [0019] Ccttc phase préalable correspond à une phase d' initialisation de l'application afin de pouvoir mettre en oeuvre une authentification biométrique pour le service. L'application commande ainsi à un conteneur sécurisé de chiffrer le code de service et reçoit en retour le chiffré du code de service. Ce chiffré est sauvegardé dans une mémoire du terminal accessible par l'application. Cette dernière ne dispose donc pas du code de service de manière durable. Seul le conteneur sécurisé peut ensuite déchiffrer ce chiffré du code de service. L'application n'a pas accès au matériel cryptographique utilisé pour chiffrer (et donc déchiffrer) le code de service. Aucun tiers n'est susceptible d'obtenir le code de service par analyse de zones mémoire associées à l'application. [0020] Dans un mode de réalisation particulier alternatif ou cumulatif au mode de réalisation précédent, le procédé d'authentification comprend : [0021] - commander une génération d'une clé secrète lors d'une phase préalable à l'authentification de l'utilisateur, une utilisation de ladite clé secrète pour une opération de chiffrement ou déchiffrement nécessitant une authentification biométrique réussie de l'utilisateur. [0022] Ccttc phase préalable correspond à une phase d' initialisation de l'application afin de pouvoir mettre en oeuvre une authentification biométrique. L'application commande ainsi au conteneur sécurisé de générer une clé secrète dont l'utilisation pour une opération cryptographique est conditionnée par une authentification biométrique réussie de l'utilisateur. Cette clé secrète est mémorisée dans le conteneur sécurisé. L'application ne dispose pas de droits lui permettant d'y accéder. [0023] Selon une caractéristique particulière du procédé d'authentification, la génération de la clé secrète est conditionnée par une authentification biométrique réussie de l'utilisateur.. [0024] Ceci permet de garantir que la clé secrète a bien été générée pour une donnée bio- métrique correspondant à l'utilisateur. [0025] Dans un mode de réalisation particulier, la donnée d'authentification est en outre dé- terminée en fonction d'un défi. [0026] Dans un mode de réalisation particulier, la donnée d'authentification est en outre dé- terminée en fonction d'une clé à usage limité. [0027] Selon un deuxième aspect, l'invention concerne un terminal configuré pour au- thentifier un utilisateur dudit terminal pour un service en fonction d'un code de service. Ce terminal comprend un processeur configuré pour : [0028] - commander un déchiffrement d'un chiffré du code de service, ledit déchiffrement étant conditionné par une authentification hiométriquc réussie de l'utilisateur ; [0029] - déterminer une donnée d'authentification en fonction du déchiffré du code de service pour vérification en fonction d'une donnée d'authentification attendue.. [0030] Les avantages énoncés pour le procédé d'authentification selon le premier aspect sont transposables directement à un terminal. [0031] Cc terminal peut bien entendu comporter en termes structurels les différentes caracté- ristiques relatives au procédé d'authentification tel que décrit précédemment, qui peuvent être combinées ou prises isolément. [0032] Selon un troisième aspect, l'invention concerne un programme pour un terminal, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé d'authentification précédemment décrit mises en oeuvre par un terminal, lorsque ce programme est exécuté par cc terminal et un support d'enregistrement lisible par un terminal sur lequel est enregistré un programme pour un terminal. [0033] Les avantages énoncés pour le procédé d'authentification selon le premier aspect sont transposables directement au programme pour un terminal et au support d'enregistrement. [0034] La technique d'authentification d'un utilisateur pour un service sera mieux comprise à l'aide de la description suivante de modes de réalisation particuliers, en référence aux dessins annexés sur lesquels : [0035] [fig.la] la figure la représente un système dans lequel est mis en oeuvre le procédé d'authentification d'un utilisateur pour un service dans un premier mode de réalisation particulier ; [0036] [fig.lb] la figure lb représente un système dans lequel est mis en oeuvre le procédé d'authentification d'un utilisateur pour un service dans un deuxième mode de réalisation particulier ; [0037] [fig.2] la figure 2 illustre des étapes d'un procédé d'authentification d'un utilisateur pour un service selon un mode de réalisation particulier ; [0038] [fig.3] la figure 3 représente un terminal dans un mode de réalisation particulier. [0039] La figure la représente un système dans lequel est mis en oeuvre le procédé d'authentification pour un service dans un premier mode de réalisation particulier. Dans ce premier mode de réalisation particulier, le service correspond à un service bancaire de paiement. [0040] Ce système comprend : [0041] - un terminal mobile 1 ; [0042] - un élément de sécurité 2 ; [0043] - un terminal de paiement 3. [0044] Dans ce premier mode de réalisation particulier, l'élément de sécurité 2 est un élément de sécurité matériel hébergé au niveau du terminal. Cet élément de sécurité 2 peut en particulier être inséré dans le terminal. [0045] Le terminal mobile 1 comprend une application mobile 15, configure° pour obtenir d'un utilisateur un code personnel PIN (pour « Personal Identification Number ») associé à un service, également appelé code de service, au moyen d'une interface homme-machine 105 (représentée sur la figure 3) du terminal mobile 1. L'utilisateur a choisi un code de service 21 qui est mémorisé de manière sécurisée par l'intermédiaire de l'application mobile 15 dans l'élément de sécurité 2. Ce code de service 21 correspond à une suite de chiffres, par exemple de 4 chiffres, et est associé à un service 20 s'exécutant dans l'élément de sécurité 2. A titre d'exemple illustratif, dans cc mode de réalisation particulier, le service 20 est une application bancaire de paiement permettant de dématérialiser une carte de paiement via l'application mobile 15. Une fois la carte bancaire dématérialisée, le terminal mobile 1 peut être utilisé pour effectuer des paiements sans contact, par exemple NFC (pour « Wear Field Communication »). On se place par la suite dans le cas de cette application bancaire de paiement. [0046] Dans ce premier mode de réalisation particulier, pour réaliser un paiement sans contact, le terminal de paiement 3 envoie une demande de paiement par l'intermédiaire de l'interface sans contact NFC à l'application bancaire de paiement 20. L'identité de l'utilisateur doit alors être vérifiée au moyen de la connaissance du code de service. Une donnée aléatoire, connue sous le nom de challenge ou encore de défi, est transmise à l'application mobile 15. L'application mobile 15 demande à l'utilisateur de saisir le code de service par l'intermédiaire de l'interface homme-machine 105. A l'aide du code de service et du défi, l'application mobile 15 calcule une donnée d'authentification et la transmet à l'application bancaire de paiement 20. Cette dernière vérifie alors que la donnée d'authentification est conforme à celle attendue, cette vérification prouvant que l'utilisateur connait le code de service et authentifiant ainsi l'utilisateur. [0047] On souligne ici que l'application mobile 15 ne mémorise pas le code de service en dehors de la mise en oeuvre de cette phase d'authentification de l'utilisateur. Le code de service est uniquement mémorisé de manière transitoire dans une mémoire de travail et non de manière durable. [0048] Dans ce premier mode de réalisation particulier, l'élément de sécurité 2 est par exemple un élément de sécurité matériel tel qu'une carte SIM (pour « Subscriber Identi ty Module »), une carte de type « eUICC » (pour « embedded Universal Integrated Circuit Card »), également appelée « eSIM » (pour « embedded Subscriber Identity Module ») ou carte SIM inamovible, un eSE (pour « embedded Secure Element »). [0049] Dans un deuxième mode de réalisation, représenté sur la figure lb, le système 6 comprend : [0050] - un terminal mobile 1, comprenant un élément de sécurité 2 ; [0051] - un terminal de paiement 3 ; [0052] - une infrastructure 4 HCE (pour « Hos! Card Emulation »). [0053] Dans ce deuxième mode de réalisation particulier, l'élément de sécurité 2 est un élément de sécurité logiciel. En variante, l'élément de sécurité peut également être un élément de sécurité matériel, tel que décrit précédemment. [0054] Le terminal mobile 1 comprend une application mobile 15, configure° pour obtenir d'un utilisateur un code de service, au moyen d'une interface homme-machine 105 du terminal mobile 1. Un code de service choisi par l'utilisateur est obtenu par l'application mobile 15 et mémorisé de manière sécurisée dans l'infrastructure 4. Cc code de service 41 correspond à une suite de chiffres, par exemple de 4 chiffres, et est associé à un service 20 s'exécutant dans l'élément de sécurité 2. A titre d'exemple illustratif, dans ce mode de réalisation particulier, le service 20 est une application bancaire de paiement permettant de dématérialiser une carte de paiement via l'application mobile 15. Une fois la carte bancaire dématérialisée, le terminal mobile 1 peut être utilisé pour effectuer dès paiements sans contact, par exemple NFC (pour « Wear Field Communication »). On se place par la suite dans le cas de cette application bancaire de paiement. [0055] Dans ce deuxième mode de réalisation particulier, pour réaliser un paiement sans contact, le terminal de paiement 3 envoie une demande de paiement par l'intermédiaire de l'interface sans contact NFC à l'application bancaire de paiement 20. L'identité de l'utilisateur doit alors être vérifiée au moyen de la connaissance du code de service. Une ou plusieurs clés à usage unique SUK (pour « Single Use Key ») sont alors transmises à l'application mobile 15. Cette clé ou ces clés peuvent également être à usage limité. L'application mobile 15 demande à l'utilisateur de saisir le code de service par l'intermédiaire de l'interface homme-machine 105. A l'aide du code de service et de la ou des clés à usage unique, l'application mobile 15 calcule une donnée d'authentification (correspondant à une clé de session SK pour « Session Key ») et la transmet à l'application bancaire de paiement 20. Cette dernière construit un ou des cryptogrammes de paiement à partir de la donnée d'authentification et le ou les relaie à l'infrastructure HCE 4 pour vérification que le ou les cryptogrammes de paiement sont conformes à ceux attendus et par conséquent que la donnée d'authentification est conforme à celle attendue, cette vérification prouvant que l'utilisateur connait le code de service et authentifiant ainsi l'utilisateur. [0056] De même que dans le premier mode de réalisation particulier, l'application mobile 15 ne mémorise pas le code de service en dehors de la mise en oeuvre de cette phase d'authentification de l'utilisateur. Le code de service est uniquement mémorisé de 7 manière transitoire dans une mémoire de travail et non de manière durable. [0057] Le terminal mobile 1 et l'élément de sécurité 2 forment un dispositif utilisateur. [0058] Dans la suite de la description, le système d'exploitation s'exécutant sur le terminal mobile 1 est un système Android, de version 6 ou supérieure. [0059] Le terminal mobile 1 comprend en outre un capteur biométrique 102 (représenté sur la figure 3). Ce capteur biométrique 102 est par exemple configure pour capturer une empreinte digitale d'un utilisateur qui pose son doigt sur le capteur. Aucune limitation n'est attachée à ce type de capteur biométrique. En effet, la technique proposée peut être mise en oeuvre avec d'autres capteurs biométriques s'appuyant par exemple sur la reconnaissance faciale ou vocale. [0060] Le terminal mobile 1 comprend en outre un conteneur sécurisé 10 de stockage de clés Android (« Android Key Store » en anglais). Un système d'exploitation Android de version 6 ou supérieure garantit en effet une implémentation sécurisée, de nature matérielle, de r Android Key Store. Cc conteneur 10 permet de créer et mémoriser de manière sécurisée des clés cryptographiques. Une fois de telles clés créées et mémorisées, elles peuvent être utilisées pour des opérations cryptographiques sans exportation des clés. Des restrictions d'utilisation de ces clés peuvent également être définies. Il est ainsi possible de restreindre quand ou comment une clé est utilisée, par exemple en fonction d'une authentification biométrique de l'utilisateur, ou bien de restreindre l'utilisation d'une clé à un mode cryptographique donné. En particulier, l'authentification de l'utilisateur peut être une authentification par empreinte digitale 12. [0061] Une interface de programmation application 13 (ou API pour « Application Pro- gramming Interface ») permet à une application, telle que l'application mobile 15, d'interagir avec le conteneur 10. Par l'intermédiaire de cette interface de programmation 13, l'application mobile 15 et le conteneur sécurisé 10 coopèrent pour mettre en oeuvre le procédé d'authentification. Notamment, l'application mobile 15 envoie des commandes au conteneur sécurisé 10 et reçoit des réponses à cette commande. Ce fonctionnement est détaillé par la suite en relation avec la figure 2. [0062] Pour mettre en oeuvre la technique proposée, l'application 15 mémorise (ou accède à une zone mémoire qui comprend) un chiffré du code de service 16, noté pin_c, et le conteneur sécurisé 10 comprend une clé secrète K_pin 11 pour laquelle une utilisation pour une opération cryptographique est conditionnée par une authentification biométrique réussie de l'utilisateur. [0063] Le procédé d'authentification d'un utilisateur d'un terminal pour un service en fonction d'un code de service, mis en oeuvre dans un dispositif utilisateur, va maintenant être décrit en relation avec la figure 2 dans un système tel que représenté à la figure la. Plus précisément, le procédé d'authentification est mis en oeuvre : 8 [0064] - sur le terminal 1 par l'application mobile 15 s'exécutant sur le terminal en co- opération avec le conteneur sécurisé 10 ; [0065] - sur l'élément de sécurité 2 par une application mettant en oeuvre le service 20 s'exécutant sur l'élément de sécurité. [0066] Par la suite, le service désigne l'application mettant en oeuvre le service. [0067] On se place par la suite dans le cas où l'utilisateur a réalisé au préalable un enre- gistrement biométrique (désigné également sous le nom d'enrôlement biométrique), plus précisément avec une empreinte digitale, en utilisant le capteur biométrique 102 du terminal 1 et le conteneur sécurisé 10 , plus précisément « Android Key Store », sur le terminal 1 avec un système d'exploitation Android de version 6 ou supérieure. [0068] Une première phase P1 préalable à une authentification de l'utilisateur pour un service 20 en fonction d'un code de service défini par l'utilisateur est décrite en relation avec la figure 2. Cette première phase permet à l'application mobile 15 d'obtenir un chiffré du code de service 16 destiné à être utilisé lors d'authentifications ultérieures de l'utilisateur. Le code de service défini et saisi par l'utilisateur par l'intermédiaire d'une interface homme-machine du terminal 1 est transmis par ailleurs par l'application mobile 15 au service 20 pour mémorisation. [0069] Lors de cette première phase, dans une étape FI , l'application mobile 15 obtient le code de service saisi par l'utilisateur par l'intermédiaire d'une interface homme-machine 105 du terminal 1. Toujours dans cette étape Fl, l'application mobile 15 commande par un message MI au conteneur sécurisé 10 de générer une clé secrète K_pin 11 à laquelle est associée une condition requise pour une utilisation de cette clé pour une opération cryptographique, à savoir une authentification biométrique réussie de l'utilisateur. Une utilisation de cette clé secrète pour une opération de chiffrement ou déchiffrement nécessite une authentification biométrique réussie de l'utilisateur. [0070] Dans une étape El, le conteneur sécurisé 10 reçoit la commande MI et l'exécute. Plus précisément, le conteneur sécurisé 10 génère cette clé secrète K_pin et la mémorise dans le conteneur sécurisé en association avec la condition reçue, à savoir une authentification biométrique réussie de l'utilisateur. Cette clé secrète K_pin est uniquement connue du conteneur sécurisé 10 et n'est pas divulguée à l'application mobile 15. [0071] Dans un mode de réalisation particulier, la génération de la clé secrète est conditionnée par une authentification biométrique réussie de l'utilisateur. [0072] Dans une étape F2, l'application mobile 15 commande par un message M2 au conteneur sécurisé 10 un chiffrement du code de service à l'aide de la clé secrète générée K_pin. [0073] Dans une étape E2, le conteneur sécurisé 10 reçoit cette commande M2, authentifie l'utilisateur par l'intermédiaire du capteur biométrique 102 et chiffre le code de service 9 à l'aide de la clé secrète K_pin pour obtenir un chiffré du code de service pin c lorsque la condition associée à la clé secrète est vérifiée. Ainsi, l'opération de chiffrement est conditionnée par une authentification biométrique réussie de l'utilisateur. [0074] Toujours dans cette étape E2, le conteneur sécurisé 10 envoie (message M3) à l'application mobile 15 le chiffré du code de service pin c. [0075] Dans une étape F3, le chiffré du code de service est reçu par l'application mobile 15 dans le message M3. L'application mobile 15 mémorise le chiffré du code de service pin c dans une zone mémoire 16. [0076] Dans une étape F4, l'application mobile 15 transmet (message M4) au service 20 le code de service saisi par l'utilisateur pour mémorisation. Il est ici souligné que cette étape F4 peut être exécutée indépendamment dc l'exécution des étapes F2 et F3. [0077] A l'issue de cette première phase PI, l'application mobile 15 dispose du chiffré du code de service pin c, le conteneur sécurisé 10 dispose d'une clé secrète K_pin dont l'utilisation pour une opération cryptographique est conditionnée par une authentification biométrique réussie de l'utilisateur et le service 20 dispose du code dc service pin. L'application mobile 15 ne dispose pas dc la clé secrète permettant de déchiffrer le chiffré du code de service. [0078] Une deuxième phase P2 d'authentification de l'utilisateur pour un service 20 en fonction d'un code de service est décrite en relation avec la figure 2. [0079] Pour réaliser un paiement sans contact, le terminal de paiement 3 envoie une demande de paiement par l'intermédiaire de l'interface sans contact NFC 103 au service 20. Cette demande de paiement est reçue par le service 20 dans une étape 010. L'identité de l'utilisateur doit alors être vérifiée par le service par une preuve de la connaissance du code de service par l'utilisateur. [0080] Dans une étape 011, le service 20 envoie à l'application mobile 15 une demande de vérification MIO du code de service, cette demande comprenant un défi. [0081] Cette demande de vérification MIO est reçue par l'application mobile 15 dans une étape F10. Toujours dans cette étape F10, l'application mobile 15 obtient le chiffré du code de service pin_c par lecture de la zone mémoire 16 et commande par un message MI1 au conteneur sécurisé 10 un déchiffrement du chiffré du code de service. On rappelle que ce déchiffrement (qui entraîne une utilisation de la clé secrète pour une opération cryptographique) est conditionné par une authentification biométrique réussie de l'utilisateur. [0082] Par exemple, dans le cas d'une vérification par empreinte digitale, dans une étape E10, le conteneur sécurisé 10 en coopération avec le capteur biométrique 102 d'empreinte digitale demande à l'utilisateur de présenter une empreinte digitale puis vérifie (par exemple par une analyse des minuties ou points singuliers locaux) l'identité de l'utilisateur en fonction d'une empreinte digitale de référence définie au préalable par l'utilisateur. [0083] Lorsque l'authentification hiométrique de l'utilisateur n'est pas réussie, le conteneur sécurisé 10 transmet à l'application mobile 15 une notification de refus de déchiffrement du chiffré du code de service. Le traitement de la demande de paiement peut alors se poursuivre par une demande de saisie par l'utilisateur du code de service par l'intermédiaire de l'interface homme-machine 105. [0084] Dans le cas contraire, lorsque l'authentification biométrique de l'utilisateur est réussie, dans une étape El 1, le conteneur sécurisé 10 déchiffre le chiffré du code de service à l'aide de la clé secrète K pin et envoie dans un message M12 le code de service obtenu à l'application mobile 15. [0085] Dans une étape F11, l'application mobile 15 reçoit dans le message M12 le code de service obtenu par déchiffrement du chiffré du code de service (également appelé déchiffré du code de service par abus de langage). [0086] Dans une étape F12, l'application mobile 15 détermine une donnée d'authentification en fonction d'un défi et du déchiffré du code de service et transmet la donnée d'authentification déterminée dans un message M13 au service 20 pour vérification. [0087] Le service 20 vérifie alors en fonction d'une donnée d'authentification attendue si la donnée d'authentification reçue est correcte. La donnée d'authentification attendue est déterminée par le service 20 en fonction du défi et du code de service 21. [0088] Cette vérification prouve que l'utilisateur cannait le code de service et authentifie ainsi l'utilisateur pour le service. Ce résultat est fourni au terminal de paiement 3 en réponse à la demande de paiement. A l'issue de cette deuxième phase P2, l'utilisateur a été authentifié (par biométrie ou par code de service) par le service 20. Elle est de nouveau exécutée lorsqu'une nouvelle authentification de l'utilisateur pour le service est requise. [0089] Le procédé d'authentification d'un utilisateur d'un terminal pour un service en fonction d'un code de service, mis en oeuvre dans un dispositif utilisateur a été décrit en relation avec la figure 2 dans un système tel que représenté à la figure la (premier mode de réalisation). Cette description est aisément transposable à un système tel que représenté à la figure lb (deuxième mode de réalisation). Les étapes mises en oeuvre sont similaires à celles décrites précédemment en relation avec le premier mode de réalisation (sous réserve des adaptations nécessaires liées aux différences d'architecture). En particulier, le code de service défini et saisi par l'utilisateur par l'intermédiaire d'une interface homme-machine du terminal 1 est obtenu par l'application mobile 15 pour mémorisation dans une infrastructure 4 à l'étape F4. [0090] A l'étape F12, l'application mobile 15 détermine une donnée d'authentification en fonction d'une ou de clés à usage unique et du déchiffré du code de service et transmet la donnée d'authentification déterminée dans un message M13 au service 20. 11 [0091] A l'étape 012, le service 20 construit un ou des cryptogrammes de paiement à partir de la donnée d'authentification et le ou les relaie à l'infrastructure HCE 4 pour vérification que le ou les cryptogrammes de paiement sont conformes à ceux attendus et par conséquent que la donnée d'authentification est conforme à celle attendue, cette vérification prouvant que l'utilisateur cannait le code de service 41 et authentifiant ainsi l'utilisateur. [0092] Cette vérification prouve que l'utilisateur cannait le code de service et authentifie ainsi l'utilisateur pour le service. A l'issue de cette deuxième phase P2, l'utilisateur a été authentifié (par biométrie ou par code de service) par l'intermédiaire du service 20 par l'infrastructure HCE 4. Elle est de nouveau exécutée lorsqu'une nouvelle authentification de l'utilisateur pour le service est requise. [0093] On constate que de la même manière que pour une authentification par code de service saisi par l'utilisateur, l'application mobile 15 ne mémorise pas le code de service en dehors de la mise en oeuvre de cette phase d'authentification de l'utilisateur. Le code de service est uniquement mémorisé de manière transitoire dans une mémoire de travail du terminal et non de manière durable. [0094] Ainsi, la mise en oeuvre de la technique proposée s'appuie : [0095] - une application mobile 15 associée au service 20, ce dernier étant hébergé dans un élément de sécurité 2 matériel ou logiciel, localement, cette application mobile 15 étant principalement en charge de l'interface avec l'utilisateur pour mettre en oeuvre le service. L'application mobile 15 dialogue de manière sécurisée avec le service 20 ; [0096] - un capteur biométrique 102 du terminal ; [0097] - des fonctions biométriques et cryptographiques d'un conteneur sécurisé 10, tel que l'Android Key Store. [0098] Aucune modification du service, ni de l'architecture du terminal, ni de l'élément de sécurité ne sont par ailleurs requises pour supporter une authentification biométrique de l'utilisateur dans la mise en oeuvre de ce service. Ceci facilite la mise en oeuvre de la technique d'authentification proposée. [0099] La technique d'authentification proposée permet ainsi lors de la mise en oeuvre du service de proposer une authentification biométrique tout en restant compatible avec une authentification par code de service. [0100] Les exemples illustratifs ont été donnés sur la base d'un service de paiement. Aucune limitation n'est attachée à ce type de service, la technique étant aisément transposable tout type de service dans lequel un utilisateur est authentifié en fonction d'un code de service. [0101] Le mode de réalisation décrit comprend dans la première phase, une étape Fl au cours de laquelle l'application mobile 15 commande par un message MI au conteneur sécurisé 10 de générer une clé secrète K_pin 11 à laquelle est associée une condition 12 requise pour une utilisation de cette clé pour une opération cryptographique, et unc étape F2, au cours de laquelle l'application mobile 15 commande par un message M2 au conteneur sécurisé 10 un chiffrement du code de service à l'aide de la clé secrète générée K pin. Dans un autre mode de réalisation, ces deux étapes peuvent être fusionnées en une seule étape au cours de laquelle l'application mobile 15 commande au conteneur sécurisé 10 de générer une clé secrète K pin 11 à laquelle est associée une condition requise pour une utilisation de cette clé pour une opération cryptographique et un chiffrement du code de service à l'aide de la clé secrète générée K pin. Dans cet autre mode de réalisation, les étapes El et E2 sont également fusionnées et une seule réponse est envoyée à l'application mobile 15. Plus précisément, le conteneur sécurisé 10 reçoit la commande de générer unc clé secrète K_pin 11 à laquelle est associée une condition requise pour une utilisation de cette clé pour une opération cryptographique et un chiffrement du code de service à l'aide de la clé secrète générée K_pin et l'exécute. Le conteneur sécurisé 10 génère cette clé secrète K_pin et la mémorise dans le conteneur sécurisé en association avec la condition reçue, à savoir une authentification hiométrique réussie de l'utilisateur. Puis le conteneur sécurisé 10 authentifie l'utilisateur par l'intermédiaire du capteur hiométrique 102 et chiffre le code de service à l'aide de la clé secrète K_pin pour obtenir un chiffré du code de service pin c lorsque la condition associée à la clé secrète est vérifiée. Le chiffré du code de service pin c est alors envoyé par le conteneur sécurisé 10 à l'application mobile 15. [0102] Le mode de réalisation décrit comprend une étape Fl de commande de génération d'une clé secrète lors d'une phase préalable à l'authentification de l'utilisateur, une utilisation de ladite clé secrète pour une opération de chiffrement ou déchiffrement nécessitant une authentification biométrique réussie de l'utilisateur. Dans un autre mode de réalisation, cette clé secrète a été configurée dans le conteneur sécurisé 10 lors de l'initialisation de ce dernier. [0103] Aucune limitation n'est attachée à ces différents modes de réalisation et l'homme du métier est à même d'en définir d'autres permettant à une application mobile disposant d'un chiffré du code de service de commander un déchiffrement de ce chiffré en conditionnant ce déchiffrement à une authentification biométrique réussie de l'utilisateur. [0104] La figure 3 illustre de manière schématique un terminal 1 dans un mode de réa- lisation particulier. [0105] Le terminal 1 comprend notamment : [0106] - un processeur 100 pour exécuter des instructions de code de modules logiciels ; [0107] - une zone mémoire 106, configurée pour mémoriser un programme qui comprend des instructions de code pour mettre en oeuvre des étapes du procédé d'authentification d'un utilisateur pour un service ; [0108] - une mémoire de stockage 107, configurée pour stocker des données utilisées lors de 13 la mise en oeuvre du procédé d'authentification d'un utilisateur ; [0109] - une mémoire de stockage 108, configurée pour mémoriser notamment le chiffré du code de service 16. [0110] Le terminal 1 comprend également : [0111] - son système d'exploitation Android 101 ; [0112] - l'application mobile 15 ; [0113] - le conteneur sécurisé 10 ; [0114] - un capteur biométrique 102 ; [0115] - un module d'émission/réception sans contact 103, de type NFC ; [0116] - l'interface homme-machine 105. [0117] Dans le premier mode de réalisation, le terminal 1 comprend en outre une interface de communication 104, configurée pour communiquer avec un élément de sécurité 2, dans lequel s'exécute le service 20. [0118] L'application mobile 15 est configurée pour : [0119] - commander un déchiffrement d'un chiffré du code de service, ce déchiffrement étant conditionné par une authentification biométrique réussie de l'utilisateur ; [0120] - déterminer une donnée d'authentification en fonction du déchiffré du code de service pour vérification en fonction d'une donnée d'authentification attendue. [0121] Dans le premier mode de réalisation, la donnée d'authentification est déterminée en fonction d'un défi. [0122] Dans le deuxième mode de réalisation, la donnée d'authentification est déterminée en fonction d'une ou de plusieurs clés à usage unique. [0123] Le conteneur sécurisé 10 est configuré pour : [0124] - recevoir de l'application mobile 15 une commande de déchiffrement d'un chiffré du code de service, ce déchiffrement étant conditionné par une authentification biométrique réussie de l'utilisateur ; [0125] - authentifier de manière biométrique un utilisateur [0126] - en fonction du résultat de cette authentification biométrique, déchiffrer le chiffré du code de service et envoyer à l'application 15 le chiffré déterminé. [0127] Dans un mode de réalisation particulier, l'application mobile 15 est également configurée pour commander un chiffrement du code de service lors d'une phase préalable à l'authentification de l'utilisateur et mémoriser le chiffré du code de service. [0128] Dans ce mode de réalisation particulier, le conteneur sécurisé 10 est également configuré pour recevoir de l'application mobile 15 une commande de chiffrement d'un code de service, pour chiffrer le code de service et pour envoyer le chiffré du code de service à l'application mobile 15. [0129] Dans un mode de réalisation particulier, l'application mobile 15 est également configurée pour commander au conteneur sécurisé 10 une génération d'une clé secrète 14 lors d'une phase préalable à l'authentification de l'utilisateur, une utilisation de ladite clé secrète pour une opération de chiffrement ou de déchiffrement nécessitant une authentification biométrique réussie de l'utilisateur. [0130] Dans ce mode dc réalisation particulier, le conteneur sécurisé 10 est également configuré pour recevoir de l'application mobile 15 une commande de génération d'une clé secrète, une utilisation de cette clé secrète pour une opération de chiffrement ou déchiffrement nécessitant une authentification hiométriquc réussie de l'utilisateur, pour générer une telle clé secrète et pour envoyer à l'application mobile 15 un acquittement, indiquant que la clé secrète a bien été générée. [0131] Dans un mode de réalisation particulier, la génération de la clé secrète est conditionnée par une authentification hiométrique réussie de l'utilisateur. [0132] Le conteneur sécurisé 10 correspond dans le mode dc réalisation décrit au module Android Key Store. D'autres modes de réalisation sont également envisageables pour d'autres formes de conteneurs sécurisés, supportant les fonctions décrites précédemment. [0133] Il est ici souligné que le terminal 1 comprend également d'autres modules de traitement, non représentés sur la figure 3, configurés pour mettre en oeuvre les différentes fonctions de ce terminal. [0134] La technique d'authentification d'un utilisateur pour un service est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et/ou logiciels, apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit précédemment pour le module concerné. [0135] Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel. Un tel composant logiciel est stocké en mémoire puis chargé et exécuté par un processeur de données d'une entité physique et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc). [0136] De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware). Il peut s'agir d'un composant matériel programmable ou non, avec ou sans processeur intégré pour l'exécution de logiciel. Il s'agit par exemple d'un circuit intégré, d'une carte à puce, d'une carte électronique pour l'exécution d'un micrologiciel (firmware), etc. [0137] Dans un mode de réalisation particulier, le module 15 est configuré pour mettre en oeuvre des étapes du procédé d'authentification précédemment décrit, mises en oeuvre par un terminal. Il s'agit de préférence de modules logiciels comprenant des instructions logicielles pour faire exécuter celles des étapes (ou des actions) du procédé d'authentification précédemment décrit, mises en oeuvre par un terminal. L'invention concerne donc aussi : [0138] - un programme pour un terminal, comprenant des instructions de code de programme destinées à commander l'exécution des étapes (ou des actions) du procédé d'authentification précédemment décrit, lorsque ledit programme est exécuté par ce terminal ; [0139] - un support d'enregistrement lisible par un terminal sur lequel est enregistré le programme pour un terminal. [0140] Les modules logiciels peuvent être stockés dans ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal électrique, optique ou radio, ou un réseau de télécommunication. 16