Brevet FR2926938A1 — publié le 20090731

Procédé d'authentification et de signature d'un utilisateur auprès d'un Service applicatif, utilisant un téléphone mobile comme second facteur en complément et indépendamment d'un premier facteur La présente invention concerne un procédé permettant l'utilisation d'un téléphone mobile pour authentifier un utilisateur de façon forte auprès d'un Service applicatif et pour signer numériquement une transaction avec ce Service applicatif. 1 o On prendra à titre d'exemple dans la suite de cette description le cas où le Service applicatif est un service de banque à distance, mais il faut bien comprendre que cet exemple n'est absolument pas limitatif, et que tout autre Service applicatif accédé par un utilisateur pourra être sécurisé à l'aide du procédé selon l'invention. Dans l'état actuel de la technique, l'authentification d'un utilisateur auprès d'un Service applicatif est effectuée à l'aide d'un seul facteur d'authentification, typiquement constitué par un mot de passe (ou par un code PIN) attribué par le Service applicatif à l'utilisateur après son enregistrement auprès du service. A ce stade, l'utilisateur pourra donc s'authentifier auprès du Service applicatif en fournissant son identifiant d'utilisateur et son code mot de passe. La communication du mot de passe au Service applicatif est supposée démontrer 20 qu'on est bien en présence de l'utilisateur légitime. Mais on sait que cela reste une authentification faible pour plusieurs raisons : le mot de passe est forcément suffisamment court pour que l'utilisateur puisse le mémoriser - si de plus, l'utilisateur est libre de choisir lui-même le mot de passe, on sait qu'il fait 25 souvent un choix simpliste, c'est-à-dire relativement facile à deviner un tel procédé d'authentification est enfin vulnérable à des attaques au moyen de � spywares � (logiciels espion installés à l'insu de l'utilisateur sur son poste de travail et qui capte à la source le mot de passe lorsque l'utilisateur le saisit) ou encore à des attaques de type � phishing � où l'utilisateur croit communiquer son 30 mot de passe au Service applicatif légitime alors qu'il a en réalité été mis en contact avec un service hostile ou compromis enfin si le mot de passe devait être compromis d'une façon ou d'une autre, il n'est pas évident que l'utilisateur s'en aperçoive à temps pour empêcher une fraude ou même des fraudes répétées. D'où l'idée bien connue d'utiliser en complément d'un premier facteur d'authentification, le mot de passe, un second facteur d'authentification censé démontrer qu'un dispositif matériel en possession de l'utilisateur participe effectivement à chaque transaction d'authentification ou de signature. Dans ce cadre, le mot de passe est souvent un nombre décimal, typiquement de 4 à 8 chiffres, et on l'appelle alors un PIN. L'utilisateur est ainsi capable de se prémunir du risque d'usurpation de son identité en o s'apercevant qu'il n'est plus en possession du dispositif matériel en question. Il pourra alors faire bloquer son identifiant. On voit que le choix du type de dispositif matériel n'est pas indifférent quant au niveau de sécurité atteint : idéalement, le dispositif doit être utilisé fréquemment et l'utilisateur doit s'en dessaisir le moins souvent possible. 15 Avec le taux d'équipement en téléphonie mobile atteint de nos jours, un aspect de l'invention prévoit de faire du téléphone mobile de l'utilisateur ce dispositif constituant le second facteur d'authentification. Mais cela ne suffit pas : il convient aussi de passer d'une authentification statique où c'est une même donnée d'authentification qui sert à chaque fois à une authentification 2 o dynamique où la donnée d'authentification n'est utilisable qu'une seule fois. La question est ici de savoir comment générer un tel authentifiant dynamique et comment cela démontre l'implication effective du téléphone mobile de l'utilisateur. L'état de l'art montre qu'il faut prévoir un secret propre à chaque téléphone mobile et une application pour générer les authentifiants dynamiques, après la saisie du PIN, par 25 utilisation du secret et d'une donnée de diversification, typiquement une horloge, un compteur ou un Défi en provenance du Service applicatif. Cela soulève toutefois plusieurs questions qui ne semblent pas encore avoir trouvé de réponse globale : - que faire pour être en position de résister à des contestations abusives :30 d'utilisateurs (non-répudiation) ? comment les utilisateurs pourront-ils raisonnablement faire confiance à l'application mentionnée et comment est-elle installée sur les téléphones mobiles des utilisateurs ? d'où vient le secret mentionné et comment est-il protégé ? Par ailleurs, il est intéressant de voir dans quelle mesure on peut bâtir une solution de signature à partir d'une solution de simple authentification. En fait, la problématique de la signature se décompose en deux parties : est-on certain que la signature émane de l'utilisateur supposé ? - comment matérialiser l'accord de l'utilisateur en le reliant aux ternies de la transaction signée ? La première partie se réduit à l'authentification de l'utilisateur par le Service applicatif qui aura à traiter la transaction. L'état de l'art montre que pour traiter la seconde partie, il faut présenter les termes de la transaction à l'utilisateur et obtenir de sa part une réponse, l'accord ou la signature, qui devra 15 dépendre de ces termes et du processus de son authentification. Cette exigence fonctionnelle est appelée par les anglo-saxons � what you sign is what you see �, soit : � ce qu'on signe est ce qu'on voit �. Autrement dit, on pourrait dire qu'une signature est un authentifiant contextuel. Un but de la présente invention est par conséquent de proposer un procédé 20 d'authentification et de signature capable de répondre à la totalité de la problématique décrite ci-dessus et ainsi d'augmenter significativement la sécurité des transactions par rapport aux mécanismes connus dans l'état de la technique. Le principe de l'invention consiste non seulement à utiliser le téléphone mobile de l'utilisateur pour mettre en oeuvre un second facteur d'authentification d'un utilisateur auprès 25 d'un Service applicatif, mais également à mettre en oeuvre une Application de confiance chargée par un Tiers de confiance à bord du téléphone mobile de l'utilisateur ou d'une carte SIM insérée dans le téléphone mobile de l'utilisateur. Cela permettra d'aboutir à une authentification forte de l'utilisateur, et permettra également de signer de façon sûre les transactions effectuées par cet utilisateur. 3o La description complète du procédé montrera que le partage de responsabilité prévue entre le Service applicatif d'une part et le Tiers de confiance d'autre part permet de respecter l'exigence de non-répudiation, aucune partie concernée n'étant en position d'être � juge et partie � : chaque Service applicatif est responsable de l'identité de l'utilisateur (� connaît ton client �), attribue un identifiant et un PIN, ce PIN constituant le premier facteur d'authentification au sens de la présente invention, et enregistre auprès du Tiers de confiance le numéro de mobile de l'utilisateur, conformément à la déclaration de ce dernier, - le Tiers de confiance gère le second fadeur d'authentification et à ce titre est responsable de l'Application de confiance. Il est vrai que l'exigence de non-répudiation est encore plus forte dans le cas de la signature d'une transaction par un utilisateur que dans le cas d'une simple authentification de celui-ci. On verra que le procédé de signature de la présente invention respecte effectivement cette exigence accrue en empêchant la génération d'une signature valide en cas de � clonage � de l'Application de confiance et du secret propre au téléphone mobile de 15 l'utilisateur, c'est-à-dire en cas de reproduction par copie de ces éléments dans un autre téléphone mobile. Bien entendu, pour mettre en oeuvre le principe de l'invention, il sera nécessaire d'adapter le téléphone mobile et notamment son logiciel interne, et de pourvoir le serveur exécutant le Service applicatif de logiciels complémentaires spécifiques, dont l'écriture à partir 2 o du procédé décrit ici seront à la portée de l'homme du métier. L'invention concerne par conséquent un procédé d'authentification et un procédé de signature tels que définis dans les revendications qui sont incorporées ici par référence. Dans le détail, l'invention concerne en particulier un procédé d'authentification à deux facteurs d'un utilisateur auprès d'un Service applicatif s'exécutant sur un serveur applicatif, 25 caractérisé en ce que le premier facteur d'authentification est un Code d'authentification PIN connu uniquement de l'utilisateur et du Service Applicatif, et en ce que le second facteur d'authentification est le Terminal de Communication Mobile de l'utilisateur sur lequel aura été installée une Application de confiance obtenue d'un Tiers de confiance ou certifiée par lui, ladite Application de confiance étant apte à générer à l'aide dudit Code d'authentification PIN et d'une :3 o Clé secrète partagée uniquement avec le Tiers de confiance, un Code d'authentification à usage unique OTP pour chaque authentification de l'utilisateur auprès du Service applicatif. Grâce aux moyens utilisés dans ce procédé d'authentification, il est alors possible d'authentifier un utilisateur de façon forte auprès d'un Service applicatif, en procédant selon les étapes suivantes : - suite à la saisie de son Code d'authentification PIN par l'utilisateur, une étape de génération d'un Code d'authentification à usage unique OTP à l'aide de l'Application de confiance installée sur le Terminal de Communication Mobile de l'utilisateur ; - une étape de communication du Code d'authentification à usage unique OTP ainsi obtenu au Service applicatif ; - une étape de transmission par le Service applicatif du Code d'authentification à 1 o usage unique sous une forme réduite au Tiers de confiance ; - une étape de vérification du Code d'authentification à usage unique OTP par le Tiers de confiance ; - une étape de notification du résultat de l'authentification par le Tiers de confiance au Service applicatif. 15 Selon une première variante du procédé, le premier facteur d'authentification, à savoir le Code d'authentification PIN, est fourni à l'utilisateur par le Service applicatif de manière sécurisée. Mais il est également possible que le Code d'authentification PIN soit choisi par l'utilisateur et communiqué au Service applicatif de manière sécurisée. De façon similaire, la Clé secrète peut être créée par le Tiers de confiance et 20 communiquée de manière sécurisée à l'Application de confiance, mais il est également possible qu'elle soit générée par l'Application de confiance elle-même et communiquée au Tiers de confiance de manière sécurisée. Selon l'invention, l'Application de confiance est obtenue d'un Tiers de Confiance ou certifiée par lui, et elle est installée sur le Terminal de Communication Mobile de l'utilisateur 25 préalablement à toute authentification de l'utilisateur. Selon un aspect de l'invention, la Clé secrète n'est partagée qu'avec l'Application de confiance qui s'exécute sur le Terminal de Communication Mobile, et avec le Tiers de confiance, mais elle n'est pas accessible au Service applicatif, ce qui garantit l'indépendance entre les deux facteurs d'authenticité utilisés. 30 Le Code d'authentification à usage unique OTP est un code unique pour chaque transaction, généré dynamiquement par l'Application de confiance et ensuite communiqué par l'utilisateur au Service applicatif, sans être communiqué au Tiers de confiance. Il est généré par l'Application de confiance après saisie par l'utilisateur du Code d'authentification PIN sur le Terminal de Communication Mobile. Avant d'utiliser le procédé d'authentification dans des transactions concrètes d'authentification d'un utilisateur, il est nécessaire d'inscrire cet utilisateur auprès du Tiers de confiance. Cette étape d'inscription se décompose de la façon suivante : - inscrire l'utilisateur auprès du serveur du Tiers de confiance ; télécharger et installer l'Application de confiance dans le Terminal de Communication Mobile; enfin, activer ladite Application de confiance afin de la rendre fonctionnelle pour les opérations d'authentification subséquentes de l'utilisateur auprès du serveur applicatif. De façon plus détaillée, les phases allant de l'inscription de l'utilisateur à l'activation peuvent être effectuées via un Service applicatif et comportent alors les étapes suivantes : 5 - une étape de dédaration de son Numéro de Mobile par l'utilisateur auprès du Service applicatif ; - une étape consistant à demander par le Service applicatif l'inscription de l'utilisateur auprès du Tiers de confiance en lui communiquant le numéro de Mobile de l'utilisateur ; - une étape d'attribution à l'utilisateur par le Tiers de confiance d'un Code d'authenticité suivie 2 o d'une étape d'envoi de ce Code d'authenticité au Service applicatif ; - une étape de communication du Code d'authenticité à l'utilisateur par le Service applicatif ; - une étape d'envoi par le Tiers de confiance d'un message de type SMS à l'utilisateur, ledit message de type SMS contenant les paramètres permettant de charger et d'installer l'Application de confiance sur le Terminal de Communication Mobile ; 25 -une étape de chargement et d'installation de l'Application de confiance sur le Terminal de Communication Mobile de l'utilisateur ; - une étape d'activation de l'Application de confiance après vérification du Code d'authenticité, - une étape de génération par l'Application de confiance d'une Clé secrète ; - une étape de transmission sécurisée de la Clé secrète et desdits paramètres au serveur du 3 0 Tiers de confiance ; - une étape de vérification des éléments reçus par le Tiers de confiance et d'Initialisation des registres de l'utilisateur ; - une étape d'envoi par le Tiers de confiance d'un message de confirmation d'activation à l'Application de confiance. Mais les phases allant de l'inscription de l'utilisateur à l'activation peuvent aussi être effectuées directement auprès d'un Tiers de confiance, et elles comportent alors les étapes suivantes : - une étape d'Inscription de l'utilisateur auprès du Tiers de confiance ; :L o - une étape de déclaration de son Numéro de Mobile par l'utilisateur auprès du Tiers de confiance et de validation de celui-ci ; - une étape de communication à l'utilisateur par le Tiers de confiance d'un Code d'authenticité ; - une étape d'envoi par le Tiers de confiance d'un message de type SMS à l'utilisateur _1 5 contenant les paramètres lui permettant de charger et installer l'Application de confiance sur son Terminal de Communication Mobile ; - une étape de chargement et d'installation de l'Application de confiance sur le Terminal de Communication Mobile de l'utilisateur ; - une étape d'activation de l'Application de confiance après vérification du Code d'authenticité ; 2 0 - une étape de génération par l'Application de confiance d'une Clé secrète ; - une étape de transmission sécurisée de la Clé secrète et desdits paramètres au serveur du Tiers de confiance ; - une étape de vérification des éléments reçus par le Tiers de confiance et d'Initialisation des registres de l'utilisateur ; 2 5 - une étape d'envoi d'un message de confirmation d'activation à l'Application de confiance par le Tiers de confiance. Selon un premier mode de réalisation de l'invention, l'Application de confiance est chargée et installée dans une mémoire du Terminal de Communication Mobile, de façon à la _3 o rendre exécutable par un microprocesseur du Terminal de Communication Mobile. En variante, l'Application de confiance est chargée et installée dans une mémoire de la carte SIM, de façon à la rendre exécutable par le microprocesseur de la carte SIM ou du Terminal de Communication Mobile. L'invention concerne aussi un procédé de signature d'une transaction entre un serveur applicatif et un utilisateur préalablement enregistré et authentifié auprès dudit serveur applicatif. Ce procédé de signature comporte les étapes suivantes : - une étape consistant à préparer au niveau du serveur applicatif un � Bon à exécuter � (BAE) représentatif de la transaction à signer, suivie de la transmission du � Bon à exécuter � et du Numéro de Mobile de l'utilisateur au serveur du Tiers de confiance; - une étape consistant à générer au niveau du serveur du Tiers de confiance un Défi aléatoire puis une étape consistant à préparer et envoyer au Terminal de Communication Mobile de l'utilisateur le � Bon à exécuter � et le Défi ; - après acceptation du � Bon à exécuter� par l'utilisateur et saisie de son Code PIN, une étape consistant à calculer au niveau de l'Application de confiance une Réponse (R4) à :L5 l'envoi du � Bon à exécuter � par le Tiers de confiance ; - après saisie de la Réponse (R4) par l'utilisateur sur le service applicatif, calcul par le Serveur applicatif d'une Réponse réduite (Resp r) ; - transmission par le Serveur applicatif du Numéro de Mobile et de la Réponse réduite précédemment calculée, au Serveur du Tiers de confiance ; 20 - au niveau du Serveur du Tiers de confiance, calcul d'un Résultat (R6) et en fonction de la valeur dudit Résultat (R6), indiquer au Serveur applicatif si l'utilisateur a valablement signé le � Bon à exécuter � ou non. Il est à noter que l'étape d'authentification préalable de l'utilisateur pour mettre en oeuvre ce procédé de signature peut être l'authentification à deux facteurs indépendants 2 5 conforme à la présente invention, ou un autre type d'authentification. L'invention sera mieux comprise en se référant à la description qui suit ainsi qu'aux figures, dans lesquelles : - la figure 1 représente un organigramme du procédé d'inscription d'un utilisateur et 30 de son Terminal de Communication Mobile auprès du service applicatif ; - la figure 2 représente un organigramme du procédé d'authentification d'un utilisateur préalablement enregistré auprès du Service applicatif, mettant en oeuvre un Tiers de confiance et le Terminal de Communication Mobile de l'utilisateur, selon l'invention ; - la figure 3 représente un organigramme d'un procédé de signature selon l'invention ; la figure 4 représente un organigramme du procédé de réinscription d'un utilisateur auprès du Service applicatif, dans le cas où une inscription préalable a été compromise ; o la figure 5 représente un organigramme d'un procédé de désinscription d'un utilisateur auprès d'un Service applicatif. Avant de décrire l'invention de façon plus détaillée, il est utile de définir un certain nombre de termes utilisés dans la suite de la description. 15 Service applicatif : Service souhaitant utiliser la présente invention pour authentifier de manière forte ses utilisateurs. Il peut notamment s'agir d'un service de Banque en ligne, par exemple au moyen dintemet et / ou via d'autres canaux. Ce Service applicatif est exécuté sur un serveur qui héberge l'application, et auquel les utilisateurs viennent se connecter. 20 PIN pour � Personal Indentification Number � en terminologie anglo-saxonne: il s'agit d'un Code d'authentification auprès d'un Service applicatif et qui est propre à chaque utilisateur. C'est donc un secret, connu seulement de l'utilisateur et du Service applicatif, et il constitue le premier des deux facteurs de l'authentification forte de la présente solution. Ce Code PIN est géré entièrement par le Service applicatif et non par le Tiers de confiance. 25 Identifiant utilisateur : identifiant de l'utilisateur auprès d'un Service applicatif. Il s'agit typiquement d'une chaine de caractères alphanumériques. Numéro de Mobile : numéro par lequel le Terminal de Communication Mobile, ou 30 Mobile de l'utilisateur est identifié de manière unique sur les réseaux de téléphonie mobile (plus précisément, le Numéro de Mobile est lié à une et une seule carte SIM ; lorsque celle-d est insérée dans un Mobile, celui-ci peut être joint au moyen du Numéro de Mobile, par un appel entrant ou un SMS par exemple). Ce numéro sert aussi d'identifiant de l'utilisateur auprès du Tiers de confiance. C'est typiquement son numéro de téléphone lorsque le Terminal de Communication Mobile est un téléphone mobile. Terminal de Communication Mobile, ou Mobile : au sens de la présente demande de brevet, on désigne par Terminal de Communication Mobile ou Mobile, tout appareil électronique portable disposant au moins d'un microprocesseur, d'une mémoire, d'un dispositif d'affichage et pouvant se connecter à un réseau de téléphonie numérique sans fil, :L o notamment de type GSM, CDMA, UMTS ou autre, et accessible via un Numéro de Mobile. En pratique, il s'agira le plus souvent d'un terminal de téléphonie mobile ayant des capacités d'exécution de code de type java, et des capacités de communication de données. Comme cela apparaitra dans la suite, le Mobile équipé de l'Application de confiance et d'une Clé secrète constitue le second facteur de l'authentification forte selon la présente solution. 15 Application de confiance : il s'agit d'une application, typiquement de type java, installée sur le Mobile ou sur la carte SIM de celui-ci, et qui permet à l'utilisateur de s'authentifier et / ou de signer une transaction selon la présente solution. Notons que cette Application de confiance nécessite une Clé secrète qui est stockée sur le Mobile et qui n'est 20 accessible qu'à l'Application de confiance. Clé secrète : il s'agit d'un secret fort généré aléatoirement sur le Mobile et transmis de manière sécurisée au Tiers de confiance. On verra qu'à l'issue du processus d'installation et d'activation de l'Application de confiance sur le Mobile, Application de confiance et Tiers de 25 confiance partagent ce même secret fort. A noter que ce secret fort pourrait être généré par le Tiers de confiance et transmis à l'Application de confiance de manière sécurisée. A noter également que le qualificatif � fort � signifie que l'entropie du secret est suffisante pour résister à toute attaque par force brute (ce qui n'est pas le cas pour un secret faible, à l'exemple d'un mot de passe classique). :30 Tiers de confiance : service gérant les Mobiles inscrits et à ce titre gérant notamment le procédé d'installation et d'activation de l'Application de confiance et contribuant à la vérification des 01V (pour � One -rime Password � en terminologie anglo-saxonne) et des Signatures en confirmant en particulier l'implication du second facteur qu'est le Mobile. Le Tiers de confiance est une entité indépendante de celle offrant le Service applicatif. SMS (pour � Short Message Service � en terminologie anglo-saxonne): message court envoyé au Mobile identifié par le Numéro de Mobile. La sécurité du réseau téléphonique numérique mobile (réseau de type fermé), garantie par les opérateurs, permet de garantir que i o seul le Mobile doté d'une carte SIM liée au Numéro de Mobile destinataire du SMS recevra le message. SMS de type push wap : SMS spécifique comportant un message descriptif et une URL de téléchargement. A la réception d'un tel SMS, le Mobile affiche une sollicitation à 15 destination de l'utilisateur en l'invitant à télécharger la ressource (par exemple un jeu ou une application quelconque) sur son Mobile. Identifiant de retrait ou ID retrait : identifiant technique, alias transitoire du Numéro de Mobile, indiqué en paramètre de l'URL envoyée au Mobile via un message de type 2 o SMS ou SMS push wap. Activation de l'Application de confiance : il s'agit d'une phase postérieure au téléchargement et à l'installation de l'Application de confiance sur le terminal mobile de communication, et qui termine le procédé d'installation et d'activation de l'Application de 25 confiance lors de sa première exécution sur le Mobile. Lors de cette activation, une Clé secrète (Ks) est générée par l'Application de confiance, stockée localement dans le Mobile, et transmise de manière sécurisée au Tiers de confiance. Alternativement la Clé secrète (Ks) peut être reçue de manière sécurisée du Tiers de confiance et installée dans l'Application de confiance. .3o Code d'authenticité : élément différenciant, dont le but est de donner les moyens à l'utilisateur de vérifier que l'Application de confiance installée provient effectivement du Tiers de confiance. Ce code est fourni à l'utilisateur au moment de la déclaration au Tiers de confiance du Numéro de Mobile par l'utilisateur, et il est affiché lors de l'Activation de l'Application de confiance. Si ce code ne correspond pas ou est absent, l'utilisateur a la responsabilité de ne pas utiliser l'Application de confiance et de contacter le Serveur Applicatif, car il y a suspicion de fraude. 0W ou � One Mime Password � en terminologie anglo-saxonne : authentifiant dynamique ou code généré dynamiquement par l'Application de confiance de la présente solution après saisie par l'utilisateur de son PIN sur le Mobile. Ce code OTP est unique pour L o chaque authentification et doit être communiqué par l'utilisateur pour s'authentifier auprès du Service applicatif. HMAC : un Code d'authentification de message (ou MAC, pour � message authentication code �), par exemple l'algorithme HMAC-SHA1, mais tout autre algorithme de 15 calcul de MAC sûr peut également convenir. La notation C = HMAC(M, K) désigne le Code d'authentification du message M, généré à l'aide de la dé K. Ce code C ne peut être généré à partir de M que si l'on connait la clé K, cela garantit donc à la fois l'intégrité de M et son authenticité. Inversement, on ne peut pas remonter à la dé K connaissant M et C. 20 Compteur : variable interne, stockée dans le Mobile (Compteur mobile) et dans le serveur du Tiers de confiance (Compteur base) et permettant de diversifier les OTP générés. Lorsqu'un OTP est généré, la valeur du compteur du mobile est incrémentée et lorsqu'Il est validé, la valeur du compteur est mise à jour sur le Tiers de confiance. 25 Défi : code généré aléatoirement par le Tiers de confiance lors du procédé de signature. Comme on le verra par la suite, le Défi est envoyé avec le � bon à exécuter � ou BAE à l'Application de confiance par l'Intermédiaire d'un message de type SMS. Il permet d'éviter le rejeu des signatures, mais il joue également le rôle d'un secret temporaire car même un attaquant qui aurait réussi à voler les deux facteurs d'authentification aura besoin en plus du 30 Défi pour pouvoir générer une Réponse valide. Réponse : réponse calculée par l'Application de confiance à partir du BAE, du PIN, de la Clé secrète et du Défi. La fourniture d'une Réponse correcte par le Mobile prouve la mise en oeuvre des deux facteurs d'authentification, en présence du BAE, et donc manifeste le consentement de l'utilisateur sur le contenu du BAE. Notons que la Réponse n'est pas rejouable, car le Défi permet de diversifier les Réponses. Bon à exécuter ou BAE : ensemble de données sur lesquelles le Service applicatif demande à l'utilisateur de s'engager lors du procédé de signature. Le BAE pourra, selon les cas, être envoyé directement à l'utilisateur en utilisant un message de type SMS, ou pourra être 1 o récupéré directement sur un serveur par l'Application de confiance en utilisant une URL récupérée du SMS envoyé par le Service applicatif. Dans le cas où le BAE est présenté à l'utilisateur à l'aide de SMS, il sera limité en taille. Description détaillée de la solution proposée par l'invention: 15 Le procédé selon l'invention va maintenant être décrit plus en détail en référence aux figures. Le procédé global comporte plusieurs procédés, à savoir un procédé d'inscription préalable de l'utilisateur (Figure 1) pour qu'il puisse utiliser l'invention, des procédés d'exploitation qui permettent d'authentifier l'utilisateur (Figure 2), puis de signer des 20 transactions auprès du Service applicatif (Figure 3). Le procédé global comporte également un procédé de réinscription (Figure 4) auprès du Service applicatif, au cas où une précédente inscription aurait été annulée, et un procédé de désinscription (Figure 5) lorsque l'utilisateur ne souhaite plus se servir de son Mobile pour effectuer des transactions auprès du Service applicatif. 25 On se réfère à la Figure 1 pour décrire le procédé d'inscription de l'utilisateur auprès du Service applicatif. Ce procédé d'inscription comporte une phase d'enregistrement du Mobile auprès du Service applicatif, une phase d'installation d'une Application de confiance sur le Mobile, et une phase d'Activation de l'Application de confiance. 30 Procédé d'inscription : phase d'enregistrement du Mobile : On suppose que chaque utilisateur est déjà inscrit auprès d'un Serveur applicatif qui lui a attribué un Identifiant utilisateur et un PIN, comme cela est le cas dans les procédés 5 d'authentification les plus couramment utilisés actuellement. A ce stade, l'utilisateur pourra s'authentifier auprès du Serveur applicatif en fournissant son Identifiant utilisateur et son PIN. Mais il s'agit d'une authentification faible, basée sur un seul facteur, le PIN. Pour compléter ce premier facteur, secret connu du seul utilisateur, par un second facteur, basé sur un dispositif matériel en possession de l'utilisateur, le procédé d'enregistrement prévoit que l'utilisateur dédare de façon formelle son Numéro de Mobile auprès du Serveur applicatif 5. Cette déclaration va permettre au Serveur applicatif d'associer le Mobile à l'utilisateur, en une étape indiquée par la référence 4. Le Serveur applicatif 5 n'a pas nécessairement les moyens de s'assurer que l'utilisateur est bien titulaire du Numéro de mobile dédaré, par conséquent l'utilisateur est responsable de sa déclaration. Cest pourquoi, il est de préférence prévu que l'utilisateur signe cette dédaration en ligne, au moyen d'une signature électronique d'une fiabilité suffisante, ou de façon traditionnelle (courrier ou formulaire signé en face à face). Sur la base de cette déclaration, le Serveur applicatif 5 inscrit (étape 6) le Mobile 2 o déclaré auprès du Tiers de confiance. Dans l'étape notée 8, le serveur du Tiers de Confiance vérifie si le Mobile est déjà inscrit et activé dans sa base de données. Si le Mobile n'est pas déjà activé, le Tiers de confiance attribue un Code d'authenticité qui est transmis (étape 10) au Service applicatif et déclenche la phase d'installation de l'Application de confiance sur le Mobile, qui sera elle-même 25 suivie par la phase d'activation de l'Application de confiance. Le Serveur applicatif 5 confirme auprès de l'utilisateur la prise en compte de sa déclaration et communique à l'utilisateur le Code d'authenticité en l'avertissant qu'il va recevoir sur son Mobile un message de type SMS, par exemple un SMS de type push wap lui permettant d'installer une Application de confiance sur son Mobile qui affichera ce Code 3o d'authenticité lors de sa première exécution. Si l'application une fois installée n'affiche pas le Numéro de Mobile de l'utilisateur et le Code d'authenticité annoncé, l'utilisateur aura la responsabilité de ne pas procéder à l'Activation. Procédé d'inscription : phase d'installation de l'Application de confiance : 5 Suite à l'inscription du Numéro de Mobile par le Serveur applicatif, le Tiers de confiance 7 émet un SMS de type push wap ou autre (étape 14 sur la figure 1) destiné au Mobile nouvellement inscrit. Le SMS contient notamment une URL comportant un ID retrait, alias temporaire et confidentiel du Numéro de Mobile de l'utilisateur et à usage unique. _L o Par l'arrivée de ce SMS, l'utilisateur est invité au moyen d'une alerte (étape 16) à télécharger l'Application de confiance à l'URL véhiculée par le SMS. A réception (18) de l'accord de l'utilisateur, envoi (20) par le Terminal de Communication Mobile d'un message d'accord de téléchargement de l'Application de confiance au serveur du Tiers de confiance. 15 Le Tiers de confiance sollicité via cette URL par le Mobile (étape 22) : récupère l'ID retrait et vérifie qu'une Activation est bien en cours pour le Mobile correspondant ; génère dynamiquement une version personnalisée et de préférence signée de l'Application de confiance comportant le Numéro de Mobile, l'ID retrait et le Code 20 d'authenticité. La version personnalisée de l'Application de confiance dépend aussi éventuellement du type de Mobile. Une fois téléchargée sur le Mobile (étape 24), l'Application de confiance est ensuite installée dans le Mobile (étape 26) après vérification de l'intégrité et de la signature du code constituant cette Application de confiance. 25 Si l'application était déjà installée, il convient de la réinstaller en purgeant toutes les données précédemment créées localement dans le Mobile par cette application. Pour que l'Application de confiance puisse être signée et que le système d'exploitation du Mobile en tienne correctement compte, il est préférable de se baser au minimum sur le standard MIDP 2.0 ou équivalent. 30 Procédé d'inscription : phase d'Activation de l'Application de confiance : L'Activation intervient lors de la première exécution de l'Application de confiance et sert à générer une Clé secrète Ks qui sera d'une part communiquée de manière sécurisée au Tiers de confiance et d'autre part mémorisée localement dans le Mobile (3) avec un Compteur au niveau Mobile (noté Compteur mobile) initialisé à 0. L'Activation de l'Application de confiance suppose un acte volontaire et donc responsable de l'utilisateur : pour procéder à l'Activation, il devra par exemple saisir le Code d'authenticité, ce qui a le mérite de l'obliger à en prendre activement connaissance, ce qui 1 o favorise sa vigilance. Ainsi, lors de la première exécution, l'Application de confiance indique qu'on est en phase d'Activation, affiche le Numéro de Mobile et le Code d'authenticité et invite l'utilisateur (étape 28) à procéder à la confirmation de l'Activation en saisissant le Code d'authenticité (étape 30) si les données affichées sur le Mobile sont conformes, à savoir que : :L5 c'est effectivement le Numéro de Mobile qu'il avait dédaré auprès du Serveur applicatif (étape 4) ; c'est bien le Code d'authenticité attendu (étape 12). Si ce n'est pas le cas, l'utilisateur est invité à ne pas procéder à l'Activation et à signaler cette anomalie ou tentative de fraude auprès du Serveur applicatif. 20 Lorsque la saisie effectuée (étape 30) par l'utilisateur correspond au Code d'authenticité, l'Application de confiance tire un aléa qui servira comme Clé secrète Ks pour les opérations ultérieures d'authentification et / ou de signature, comme cela sera décrit plus loin. Cette dé secrète doit être communiquée de façon sure au Tiers de Confiance. A cet effet, l'Application de confiance : 2.5 - constitue un message contenant l'ID retrait, le Code d'authenticité, la Clé secrète et un éventuel � padding � ou bourrage, chiffre ce message avec la clé publique du Tiers de confiance, cette information étant contenue en dur dans le code de l'Application de confiance, et poste ou communique par un autre moyen le message chiffré ainsi obtenu au 3o Tiers de confiance (étape 32). A réception du message chiffré (ou bloc chiffré), le Tiers de confiance (étape 34) : déchiffre le message reçu au moyen de sa dé privée, de façon à extraire la Clé secrète Ks générée dans le Mobile, et partager cette même Clé secrète entre le Mobile et le serveur du Tiers de confiance ; vérifie que l'ID retrait correspond bien à un Mobile en cours d'Activation ; - vérifie le Code d'authenticité extrait du message déchiffré ; initialise à 0 un Compteur, noté Compteur base, au niveau du serveur du Tiers de confiance ; récupère et mémorise la Clé secrète Ks et le Compteur base en cas de vérifications positives ; :t o répond le cas échéant positivement à l'Application de confiance (étape 36), en transmettant au Terminal de Communication Mobile un message de bonne fin de l'activation de l'Application de confiance. En cas de Réponse positive, l'Application de confiance mémorise localement dans le Mobile la Clé secrète et le Compteur mobile initialisé à O. L'utilisateur est enfin informé (étape 15 38) que l'Application de confiance est activée et que le service d'authentification est désormais ouvert. Procédé d'authentification 20 On se réfère à la figure 2 pour décrire la phase d'exploitation du procédé d'authentification selon l'invention, l'Activation de l'Application de confiance ayant déjà été faite. L'utilisateur du Mobile 3 souhaite s'authentifier auprès d'un Service applicatif 5 pour lequel il conne son Identifiant utilisateur et son PIN. En tenant compte du fait que les Services applicatifs ne mémorisent pas toujours le 25 PIN en clair dans une base de donnée même protégée, nous introduisons ci-après une fonction H qui donne la valeur mémorisée en lieu et place du PIN à partir du PIN (et éventuellement d'autres données connues du Service applicatif, mais elles ne seront pas détaillées afin de ne pas alourdir inutilement le texte). Typiquement H est une fonction de hash (d'où la notation), il est en effet souhaitable de ne pas pouvoir effectuer facilement la fonction inverse, mais H peut 3o également être la fonction identité si le serveur applicatif peut accéder au PIN de l'utilisateur en clair dans sa base de données (fonction identité signifie que H(x) = x). O-après, PIN désigne la valeur du PIN tel que saisi par l'utilisateur, H(PIN) désigne le résultat de la fonction H appliquée à PIN et HPIN représente la valeur substitutive au PIN telle que mémorisée par le Service applicatif (sauf erreur de saisie, HPIN devrait avoir la même valeur que H(PIN)). L'utilisateur lance (étape 40) l'Application de confiance sur son Mobile, qui lui demande son code PIN (étape 42), et en réponse l'utilisateur saisit son PIN (étape 44). L'Application de confiance, dans l'étape référencée 46 : - calcule un OTP selon une fonction Fi prenant en compte (Compteur mobile, H(PIN), Clé secrète Ks) - incrémente le Compteur mobile - et affiche l'OTP (étape 48) sur l'écran du Mobile. L'utilisateur saisit (étape 50) l'Identifiant utilisateur et l'OTP sur le Service applicatif, par l'intermédiaire de l'interface utilisateur du Service applicatif, qui peut être une interface de type connexion intemet, un serveur vocal, ou tout autre interface appropriée. Sur la base de l'Identifiant utilisateur, déjà stocké dans sa base de données (étape 4), 15 le Service applicatif détermine (étape 52) le Numéro de Mobile et HPIN. Puis le Service applicatif calcule un OTP réduit, noté 07P r = F2(HPIN, OTP), qui est donc obtenu selon une fonction F2 appliquée à HPIN et à l'OTP tel que transmis par l'utilisateur dans l'étape 50. Le Service applicatif soumet alors (étape 54) le Numéro de Mobile et l'OTP_r au 2 o serveur du Tiers de confiance. Par rapport au Numéro de Mobile préalablement inscrit (étape 6, figure 1), le Tiers de confiance détermine la valeur du Compteur base. Par ailleurs, il retrouve la Clé secrète Ks, enregistrée à l'étape 34, Figure 1. Ensuite, (étape 56), le Tiers de confiance : 25 - calcule une valeur Incrément, égale au résultat d'une fonction F3 appliquée à (Compteur base, Clé secrète Ks, 07P r) incrémente Compteur base de la valeur de Incrément et renvoie (étape 58) au Service applicatif un message � 0K � Si Incrément > 0, signifiant que l'utilisateur a bien été authentifié à la fois par son PIN et par l'OTP :3o généré dans le Mobile et transmis sous forme réduite au Tiers de Confiance. Dans le cas contraire, un message � Non Ok �, ou NOK, est transmis au Service applicatif, qui relaie ce message OK ou NOK à l'utilisateur (étape 62). Exemple d'un mode de réalisation des fonctions Fi, F2 et F3 : Un 07P est calculé à partir de deux éléments : - un Indicateur, noté Ind - et un Discriminant, noté Dis. L'Indicateur est un nombre entier strictement plus petit qu'un paramètre maxInd et en 1 o fait égal à Compteur mobile modulo maxInd. Si un utilisateur lire au moins un nombre maxInd d'OTP sans les faire valider positivement auprès du Tiers de confiance alors le compteur de celui-ci, Compteur base, se retrouve désynchronisé par rapport au compteur, Compteur mobile, de l'Application de confiance : aucun nouvel OTP ne pourra être validé sans qu'on ait au préalable resynchronisé :L 5 le compteur du Tiers de confiance par rapport à celui de l'Application de confiance. Le Discriminant est la partie discriminante de l'OTP, c'est à dire celle qu'il est impossible de générer sans connaître à la fois le Compteur, le PIN et la Clé secrète Ks. En fin de compte, OTP = Ind + maxInd*Dis Dans la variante décrite ci-après, basée sur un "chiffrement" basique (mais suffisant) 2 o par XOR (le OU Exclusif), il est nécessaire que le Discriminant puisse prendre toutes les valeurs possibles d'un nombre entier sur N bits. Exemple : si l'on veut que les OTP tiennent sur 7 chiffres décimaux, il peut être judicieux de réserver 18 bits au Discriminant : - maxInd sera alors de 38 (au-delà, un OTP généré risque de ne pas tenir sur 7 25 chiffres décimaux et en-deçà, on n'utilise pas de façon optimale toute la capacité de la présente solution) maxDis, valeur maximale du Discriminant, sera de 262144 (soit 2 à la puissance 18). 30 Fonction Fi : Fi (Compteur mobile, H(PIN), Clé secrète) : Ind = Compteur mobile modulo maxInd On calcule deux messages M1, M2 tels que : M1 = HMAC(Ind, H(PIN)) M2 = HMAC(Compteur mobile, Clé secrète) Puis on calcule M'l et M2 définis par : M'l = M1 modulo maxDis M2 = M2 modulo maxDis Ce qui a pour effet de raccourcir la longueur de M1, M2 ; Et on calcule M3 = M'l XOR M2 Puis la fonction retourne Ind + M3 * maxInd Fonction F2: F2 (HPIN, OTP) : Ind = OTP modulo maxInd 5 A3 = OTP / maxInd On calcule Al = HMAC(Ind, HPIN) Puis A'l =Al modulo maxDis Et A4 = A3 XOR A'l Ensuite Retourner Ind + A4 * maxInd. 20 Fonction F3 : F3 (Compteur base, Clé secrète, OTP_r) : Ind = OTP r modulo maxInd T4 = OTP _r / maxInd 2.5 On calcule un Incrément = Ind - (Compteur base modulo maxInd) Si Incrément Procédé de signature On se réfère à la figure 3 pour décrire le procédé de signature selon l'invention. Supposons que l'utilisateur du Mobile souhaite valider un ensemble de données générées par le Service applicatif et fasse une demande de signature (étape 64) au Service applicatif. Ces données peuvent être notamment un ordre de paiement ou bien un contrat. L'authentification à deux facteurs évoquée au paragraphe précédent permet de démontrer que l'on est bien en présence de l'utilisateur de manière fiable, mais on ne peut pas démontrer que l'utilisateur a visualisé et validé une ou plusieurs données particulières ; c'est l'objet du procédé 1 o de signature. Pour la mise en oeuvre du procédé de signature, on part du principe que l'Activation du Mobile de l'utilisateur a déjà été réalisée préalablement. En outre, durant tout le procédé de signature, l'utilisateur est considéré comme étant déjà correctement authentifié sur le Service applicatif (par le procédé d'authentification de la présente solution ou bien par un autre procédé d'authentification, voire par une simple 15 identification sans authentification), et on suppose qu'il souhaite valider un ensemble de données. Dans l'étape référencée 66, le Service applicatif prépare l'ensemble des données à valider en fonction des éléments qu'il conne (par exemple identité, adresse de l'utilisateur, numéro de compte, taux, tarif...) et des éléments qu'il demande à l'utilisateur (montant, 2 o durée,...) et en déduit un bon à exécuter (BAE) comportant les données essentielles sur lesquelles on demande à l'utilisateur de s'engager. On pourra également indure dans ce BAE un hash du document d'origine contenant l'ensemble des données. Le Service applicatif transmet au Tiers de confiance le BAE et le Numéro de Mobile de l'utilisateur (étape 68). 25 Le Tiers de confiance détermine (étape 70) une donnée aléatoire appelée Défi. Il envoie à l'Application de confiance un SMS (étape 76) contenant le BAE et le Défi ou communique à l'Application de confiance les éléments qui lui permettront de récupérer le BAE et le Défi. Une fois le BAE présenté à l'utilisateur (étape 80), il lui est demandé sil souhaite le signer ou pas. 30 Ce dernier peut choisir de ne pas signer le BAE, ou bien il peut choisir de le signer. 21 Dans ce dernier cas, l'utilisateur saisit le PIN (étape 82), et l'Application de confiance, dans l'étape 84 : - calcule Réponse = F4 (BAE, Défi, H(PIN), Clé secrète Ks), - et affiche Réponse pour l'utilisateur. L'utilisateur saisit Réponse sur le Service applicatif (étape 88). Le Service applicatif détermine par rapport à l'Identifiant utilisateur et sa demande de validation en cours le BAE et HPIN. Le Service applicatif calcule (étape 90) une Réponse réduite, telle que: Resp_r = F5 (BAE, Réponse, HPIN). Dans l'étape 92, le Service applicatif soumet Numéro de Mobile et Resp_r au Tiers de confiance. Par rapport au Numéro de Mobile préalablement enregistré (étape 4, figure 1), le Tiers de confiance détermine le Défi et la Clé secrète Ks. Le Tiers de confiance (étape 94) : :L5 - calcule Résultat = F6 (Défi, Resp_r, Clé secrète Ks), renvoie Résultat au Service applicatif, - efface le Défi en cas de résultat positif. En cas de résultat négatif, un échec de signature est inscrit en regard de l'identifiant de l'utilisateur, et on pourra prévoir un blocage de toute signature au bout de 3 échecs par 2 0 exemple. Notons que Résultat est un booléen, qui indique si la validation est correcte ou pas. Ainsi, une validation correcte indique : - qu'il y a bien eu saisie du code PIN correct de l'utilisateur, ET qu'il y a bien eu mise en oeuvre de la Clé secrète Ks de l'Application de 25 confiance installée sur le Mobile, - ET qu'il y a bien eu utilisation du Défi envoyé au Mobile, ET que tous ces éléments sont liés au BAE. Partant de ce résultat, le Service applicatif peut considérer qu'il y a bien eu volonté effective et explicite de l'utilisateur de valider le contenu du BAE et de manifester son :3 0 consentement sur son contenu. Exemple de réalisation des fonctions F4, F5 et F6 : Contrairement aux fonctions de génération d'OTP, il y a cette fois-d utilisation d'un mécanisme de Défi/Réponse, et celui-d ne fait pas intervenir de notion de Compteur. Le seul paramètre est donc la valeur maximale de Réponse, qui est un nombre entier strictement plus petit qu'un paramètre maxResp. Exemple : si on veut que la Réponse tienne sur 6 chiffres décimaux, maxResp vaut 1000000. :t o Fonction F4 : F4 (BAE, Défi, H(PIN), Clé secrète) : On calcule M1, M2 tels que : M1 = HMAC(BAE, H(PIN)) M2 = HMAC(Défi+BAE, Clé secrète) 15 Puis on calcule M'l, M2 tels que : M'l = M1 modulo maxResp M2 = M2 modulo maxResp Retourner M'l XOR M2. 20 Fonction F5 : F5 (BAE, Réponse, HPIN) : On calcule Al = HMAC(BAE, HPIN ) Puis A'l =Al modulo maxResp Retourner Réponse XOR Fonction F6 : F6 (Défi, BAE, Resp_r, Clé secrète) : On calcule 12 = HMAC(Défi+BAE, Clé secrète) Puis T2 =12 modulo maxResp 3o Retourner le booléen (T2 == Resp_r). Ce booléen prend la valeur � VRAI � Si T2 et Réponse _r sont égaux, et prend la valeur � FAUX � sinon. 25 Procédé de gestion du cycle de vie Concernant le cycle de vie, les processus permettant la mise en place et l'utilisation opérationnelle de la solution ont été décrits (figures 1 et 2), il reste à décrire certains autres cas liés au cycle de vie. Les cas suivants peuvent apparakre: perte, oubli du code PIN par l'utilisateur -changement du Mobile avec conservation du Numéro de Mobile o -désinstallation de l'Application de confiance par erreur ou accident changement du Numéro de Mobile - vol ou perte du Mobile (et de la carte SIM associée) - erreur sur le Numéro de Mobile lors de l'enregistrement initial arrêt volontaire du service par l'utilisateur. :L 5 Traitons tout de suite les cas liés au code PIN : la présente solution ne gérant pas à proprement parler ce PIN, tout le cycle de vie lié au PIN est du ressort du Service applicatif, comme déjà connu. Le Service applicatif doit donc mettre en place un procédé lié à la perte et l'oubli du code PIN (renvoi ou réinitialisation du code PIN). Le plus souvent, cette problématique est d'ailleurs déjà traitée par le Service applicatif dans la mesure où le PIN 2 o pouvait servir précédemment comme moyen d'authentification faible (à un seul facteur). Pour pouvoir répondre aux autres cas, deux procédés particuliers sont définis : la réinscription et la désinscription de l'utilisateur. La réinscription est décrite en rapport avec la figure 4, qui est similaire à la figure 1 correspondant à l'inscription. Par conséquent les mêmes étapes ont été désignées par les 2 5 mêmes numéros de référence. La réinscription, pour un Numéro de Mobile donné, consiste à placer au niveau du Tiers de confiance le Mobile dans un état correspondant à l'enregistrement initial, comme schématisé par l'étape 108: la Clé secrète est effacée du serveur, un nouveau Code d'authenticité est généré (étape 10) et communiqué au Service applicatif, le Compteur mobile 3o est réinitialisé (étape 26), et un SMS de type PUSH WAP comportant un nouvel ID retrait est 24 envoyé (étape 14) au mobile pour déclencher une réinstallation. Seul le Numéro de Mobile n'est pas effacé du Serveur de confiance. La désinscription est décrite en rapport avec la figure 5. Elle consiste, pour un Numéro de Mobile donné transmis par le Service applicatif (étape 144), à effacer du serveur du Tiers de confiance l'ensemble des données liées au Mobile (étape 146). Ce dernier se retrouve donc dans un état inconnu ou non inscrit. Il est à noter que la possession du Mobile sur lequel l'Application de confiance est installée et activée permet de tirer des OTP qui sont valides dès lors que le PIN saisi est le bon et aussi longtemps que le Tiers de confiance n'a pas reçu une demande de réinscription ou de o désinscription. Mais il faut faire attention au fait qu'une demande de réinscription peut aboutir si le Mobile est toujours muni de la carte SIM et que le Numéro de Mobile est toujours actif pour cette carte SIM. En cas de perte ou de vol de la carte SIM, il est donc recommandé de demander une désinscription. Pour les autres cas, une réinscription peut suffire, et évite d'avoir 5 à repasser par la phase d'enregistrement (processus lourd car il faut fournir le Numéro de Mobile de manière fiable au Service applicatif). Partant de ce constat, il est possible de proposer les règles suivantes concernant les processus à adopter en fonction du cas de figure : Motif Action Perte, oubli du code PIN A traiter avec le Service applicatif Changement du Mobile avec Réinscription conservation du Numéro de Mobile Désinstallation de l'Application de Réinscription confiance par erreur ou accident Changement du Numéro de Enregistrement du nouveau Numéro Mobile de Mobile Éventuellement (si l'utilisateur n'a plus accès à l'ancien Numéro de Mobile) : désinscription de l'ancien Numéro de Mobile Vol ou perte du Mobile (et de la Désinscription carte SIM associée) Erreur sur le Numéro de Mobile Désinscription, suivi d'un lors de l'enregistrement initial Enregistrement Arrêt volontaire du service par Désinscription l'utilisateur Il est à noter que dans la description ci-dessus, l'Application de confiance est stockée dans une mémoire du Mobile. Dans une variante de la mise en oeuvre de l'invention, on peut néanmoins installer l'Application de confiance sur la carte SIM (pour � Subscriber Identity Module �) du Mobile où elle peut alors s'exécuter. Avantages de l'invention : L'invention permet de répondre aux buts visés, en proposant un procédé o d'authentification forte et de signature auprès d'un Serveur applicatif, basé sur l'utilisation de deux facteurs indépendants, à savoir un code PIN de l'utilisateur sous la responsabilité du Service applicatif, comme déjà connu dans l'Etat de la technique, et le Mobile de l'utilisateur doté d'une Application de confiance et d'une Clé secrète, ces deux éléments étant sous la responsabilité d'un Tiers de confiance. :L5 L'état de l'art prévoit la mise en oeuvre d'une application et d'un secret dans le Mobile de l'utilisateur mais comme déjà évoqué des questions restent en suspens : - d'où vient le secret et comment est-il protégé ? - comment assurer l'intégrité de l'application ? Le procédé d'inscription dans la phase d'Activation de la présente invention prévoit 2 o que cette Clé secrète jouant le rôle générique du secret mentionné est tirée aléatoirement par l'Application de confiance puis communiquée au Tiers de confiance, chiffrée par une dé publique du Tiers de confiance. Dès lors que l'intégrité de l'Application de confiance est assurée (ce qui fait l'objet de la question suivante), on empêche ainsi toute interception de la Clé secrète lors de sa communication au Tiers de confiance. Par ailleurs, le respect du standard 25 MIDP 2.0 ou équivalent permet à l'Application de confiance de mémoriser des données sur le Mobile tout en en interdisant en principe tout accès à quiconque en dehors de l'Application de confiance elle-même (à noter malgré tout un risque au moins théorique d'accès à ces données en intervenant au niveau du système d'exploitation du Mobile : nous y reviendrons plus loin en évoquant le risque de � clonage �). L'intégrité de l'Application de confiance est assurée dans le cadre de la présente invention grâce aux caractéristiques suivantes : - il reste possible d'installer une application susceptible de tenter de jouer le rôle de l'Application de confiance mais celle-ci ne permettra pas d'usurper l'identité de l'utilisateur par méconnaissance de la Clé secrète ; de plus, à supposer que l'installation d'une telle application malveillante intervient alors que le Mobile de l'utilisateur a été déclaré auprès du Tiers de confiance et avant Activation de l'Application de confiance par l'utilisateur : l'application malveillante qui aurait été installée à la place de l'Application de confiance ne pourra pas faire accepter de Clé secrète au Tiers de confiance par méconnaissance de l'ID retrait (communiqué au seul Mobile de l'utilisateur par SMS push wap ou équivalent) et / ou du Code d'authenticité (communiqué à l'utilisateur via le Service applicatif, donc via un autre _L 5 canal que le Mobile). -après installation et Activation et sauf à ce qu'elle soit signée par le Tiers de confiance, il n'est plus possible de modifier l'Application de confiance autrement que par effacement et remplacement de l'application (apport sécuritaire du standard MIDP 2.0 JAVA), mais dans ce cas, la Clé secrète est effacée, ce qui a pour effet de 20 rendre inopérant cette nouvelle application vis-à-vis du Tiers de confiance. Parmi les autres questions relatives à l'état de l'art antérieur, on relève l'exigence de la non-répudiation. Le partage de responsabilité entre le ou les Services applicatifs et le Tiers de confiance prévu par la présente invention garantit qu'aucune partie ne pourra être en position de � juge 25 & partie� : ni un Service applicatif qui connaît certes le PIN (ou le HPIN) de chacun de ses utilisateurs, car il ne pourra pas connaître la Clé secrète nécessaire à la génération d'OTP ou de Signatures (en fait, même une attaque par force brute ne lui permettra pas de déduire la Clé secrète à partir d'observations d'OTP et / ou de Signatures) ; :3o par ailleurs, pas plus que quiconque, un Service applicatif n'est en mesure de porter atteinte à l'intégrité de l'Application de confiance (la modification de l'Application de confiance aurait pu permettre de récupérer directement la Clé secrète et l'installation d'une fausse Application de confiance aurait pu permettre de procéder à une Activation et donc de récupérer indirectement la Clé secrète) ni le Tiers de confiance qui connaît certes la Clé secrète de chacun des utilisateurs car il ne pourra pas connakre le PIN (ou HPIN) de ceux-ci auprès des différents Services applicatifs (en effet, il ne reçoit pas directement les OTP et les Signatures produits par l'Application de confiance, il ne reçoit qu'une forme réduite de ces données où justement l'influence du PIN aura été effacée) ; on suppose néanmoins que le Tiers de confiance ne pourra pas se permettre d'installer une Application de confiance comportant délibérément une porte dérobée et ainsi tromper de façon démontrable la confiance qui lui est faite, les Services applicatifs ayant un droit d'audit. Grâce à ces éléments caractéristiques, l'invention apporte une solution d'authentification capable de résister aux éventuelles tentatives de contestation abusives d'utilisateurs. On voit que l'invention apporte une réelle étanchéité entre les données gérées 15 respectivement par les Services applicatifs et le Tiers de confiance : d'où une réelle indépendance entre les deux facteurs d'authentification. Pour supporter la fonction de signature, on a vu qu'il fallait garantir que � ce qu'on signe est ce qu'on voit � (� what you sign is what you see �.) L'un des aspects de la présente invention prévoit l'envoi par le Tiers de confiance d'un 2 o SMS au Mobile de l'utilisateur signataire, ce SMS comportant un BAE et un Défi. L'application de confiance présente le BAE à l'utilisateur qui signe en saisissant son PIN, l'Application de confiance générant alors la Signature ou techniquement la Réponse au Défi. Cela apporte une solution effective à l'exigence du � ce qu'on signe est ce qu'on voit �. En effet, même si n'importe qui peut envoyer un SMS à l'utilisateur signataire : 25 soit, l'Application de Confiance est réveillée et prend en charge le traitement mais d'une part, l'utilisateur n'acceptera de signer que s'il valide le BAE présenté, ce qui empêche donc de faire signer n'importe quoi à l'insu de l'utilisateur, et d'autre part, si le SMS n'est pas envoyé par le Tiers de confiance, il ny a aucune chance de générer une Signature valide puisqu'on ne connaît pas alors le Défi positionné par le Tiers de 3o confiance et envoyé par SMS au seul mobile de l'utilisateur soit, une autre application s'en trouve réveillée : même dans l'hypothèse où celle-d est malveillante, elle ne pourra pas générer une Signature valide car elle n'a pas accès à la Clé secrète. Revenons ici au risque théorique de � donage � de l'Application de confiance. On se rend compte qu'une Application de confiance clonée avec ses données, notamment la Clé secrète, sur un Mobile autre que celui de l'utilisateur légitime ne pourra malgré tout pas réussir à générer une Signature valide : le Défi est en effet nécessaire or il n'est envoyé par SMS par le Tiers de confiance qu'au Mobile de l'utilisateur (en fait, le Mobile de l'utilisateur est celui qui contient sa carte SIM et celle-ci n'est pas clonable). o Enfin sur un plan pratique et non plus seulement quant à la sécurité du procédé, on voit que la présente invention présente l'avantage d'être peu contraignante à déployer. En effet, moyennant des adaptations limitées, il est possible de renforcer un système d'authentification préexistant à un seul facteur d'authentification (un mot de passe) en le transformant en un système d'authentification à deux facteurs selon la présente invention, et 15 ceci en préservant l'enregistrement déjà fait des utilisateurs (� connais ton client � avec attribution d'un identifiant et d'un mot de passe) . Pour ce faire, il suffit que le Service applicatif gestionnaire du système d'authentification initial : s'abonne auprès du Tiers de confiance en adaptant quelque peu ses traitements informatiques 20 et complète l'enregistrement des utilisateurs par la mise en oeuvre du procédé d'inscription pour la phase d'enregistrement du Mobile. Dans ce cadre, il est néanmoins recommandé que le Service applicatif oblige ses utilisateurs à renouveler leurs mots de passe (qui deviennent à cette occasion des PINs) car les anciens mots de passe peuvent avoir été préalablement compromis. 25 A noter que plusieurs Services applicatifs différents et indépendants, donc potentiellement gérés par des sociétés différentes, peuvent très bien renforcer chacun de leur côté leur système d'authentification préexistant comme indiqué d-dessus et ceci sans conflits entre eux : le premier Service applicatif qui inscrit le Mobile d'un utilisateur auprès du Tiers de 3o confiance entraîne l'installation et l'Activation de l'Application de confiance dans le Mobile de l'utilisateur, 30 - les suivants bénéficient directement de l'installation et de l'Activation déjà faite. Pour finir, il faut souligner que dans une variante de la présente invention, l'Application de confiance peut être installée dans la carte SIM de l'utilisateur, ce qui apporte alors une sécurité encore accrue. Mais cela n'est pas indispensable pour atteindre une sécurité largement suffisante (il n'y a pas de � sécurité absolue �) et sans utiliser directement la carte SIM on obtient ainsi une solution déployable en totale indépendance des opérateurs de téléphonie mobile. REVENDICATIONS 1. Procédé d'authentification à deux facteurs d'un utilisateur auprès d'un Service applicatif s'exécutant sur un serveur applicatif (5), caractérisé en ce que le premier facteur d'authentification est un Code d'authentification PIN connu uniquement de l'utilisateur et du Service Applicatif, et en ce que le second facteur d'authentification est le Terminal de Communication Mobile (3) de l'utilisateur sur lequel aura été installée une Application de confiance obtenue d'un Tiers de confiance ou certifiée par lui, ladite Application de confiance 1 o étant apte à générer à l'aide dudit Code d'authentification PIN et d'une clé secrète (Ks) partagée uniquement avec le Tiers de confiance, un Code d'authentification à usage unique (OTP) pour chaque authentification de l'utilisateur auprès du Service applicatif. 2. Procédé d'authentification selon la revendication 1, caractérisé en ce que 15 l'authentification d'un utilisateur auprès d'un Service applicatif comporte les étapes suivantes : - suite à la saisie de son Code d'authentification PIN par l'utilisateur, une étape (46) de génération d'un Code d'authentification à usage unique (01P) à l'aide de l'Application de confiance installée sur son Terminal de Communication Mobile (3) ; - une étape (50) de communication du Code d'authentification à usage unique (OTP) 20 ainsi obtenu au Service applicatif ; - une étape (54) de transmission par le Service applicatif du Code d'authentification à usage unique (OTP) sous une forme réduite au Tiers de confiance ; - une étape (56) de vérification du Code d'authentification à usage unique (OTP) par le Tiers de confiance ; 25 - une étape (58) de notification du résultat de l'authentification par le Tiers de confiance au Service applicatif. 3. Procédé d'authentification selon la revendication 1, caractérisé en ce que le premier facteur d'authentification, à savoir le Code d'authentification PIN, est fourni à l'utilisateur par le 30 Service applicatif de manière sécurisée. 4. Procédé d'authentification selon la revendication 1, caractérisé en ce que le premier facteur d'authentification, à savoir le Code d'authentification PIN, est choisi par l'utilisateur et communiqué au Service applicatif de manière sécurisée. 5. Procédé d'authentification selon la revendication 1, caractérisé en ce que la Clé secrète (Ks) est créée par le Tiers de confiance et communiquée de manière sécurisée à l'Application de confiance. 6. Procédé d'authentification selon la revendication 1, caractérisé en ce que la Clé 1 o secrète (Ks) est générée par l'Application de confiance et communiquée au Tiers de confiance de manière sécurisée. 7. Procédé d'authentification selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte, préalablement à l'authentification de l'utilisateur, une étape 15 d'inscription de l'utilisateur auprès du Serveur (7) du Tiers de confiance, ladite inscription comportant des étapes consistant à: - inscrire (2, 4, 6, 8, 10, 12) l'utilisateur auprès du serveur (7) du Tiers de confiance ; télécharger et installer (14, 16, 18, 20, 22, 26, 28, 30) l'Application de confiance dans le Terminal de Communication Mobile (3); 20 - activer (32, 34, 36, 38) ladite Application de confiance afin de la rendre fonctionnelle pour les opérations d'authentification subséquentes de l'utilisateur auprès du serveur applicatif (5). 8. Procédé d'authentification selon la revendication 7, caractérisé en ce que les 25 phases d'inscription jusqu'à l'activation d'un utilisateur auprès d'un Tiers de confiance sont effectuées via un Service applicatif et comportent les étapes suivantes : - une étape (2) de déclaration de son Numéro de Mobile par l'utilisateur auprès du Service applicatif ; - une étape (6) consistant à demander par le Service applicatif l'inscription de l'utilisateur 30 auprès du Tiers de confiance en lui communiquant le Numéro de Mobile de l'utilisateur ;- une étape (8) d'attribution à l'utilisateur par le Tiers de confiance d'un Code d'authenticité suivie d'une étape (10) d'envoi de ce Code d'authenticité au Service applicatif ; - une étape (12) de communication du Code d'authenticité à l'utilisateur par le Service applicatif ; - une étape (14) d'envoi par le Tiers de confiance d'un message de type SMS à l'utilisateur, ledit message de type SMS contenant les paramètres permettant de charger et d'installer l'Application de confiance sur le Terminal de Communication Mobile ; - une étape (26) de chargement et d'installation de l'Application de confiance sur le Terminal de Communication Mobile de l'utilisateur ; - une étape d'activation de l'Application de confiance après vérification (28,30) du Code d'authenticité, - une étape de génération par l'Application de confiance d'une Clé secrète ; - une étape (32) de transmission sécurisée de la Clé secrète et desdits paramètres au serveur du Tiers de confiance ; - une étape (34) de vérification des éléments reçus par le Tiers de confiance et dinitialisation des registres de l'utilisateur ; - une étape (36) d'envoi par le Tiers de confiance d'un message de confirmation d'activation à l'Application de confiance. 9. Procédé d'authentification selon la revendication 7, caractérisé en ce que les phases d'inscription et d'activation d'un utilisateur sont effectuées directement auprès d'un Tiers de confiance et comportent les étapes suivantes : - une étape (6) d'inscription de l'utilisateur auprès du Tiers de confiance ; - une étape (8) de déclaration de son Numéro de Mobile par l'utilisateur auprès du Tiers de confiance et de validation de celui-ci ; - une étape (10) de communication à l'utilisateur par le Tiers de confiance d'un Code d'authenticité ; - une étape (14) d'envoi par le Tiers de confiance d'un message de type SMS à l'utilisateur contenant les paramètres lui permettant de charger et installer l'Application de confiance sur 30 son Terminal de Communication Mobile ;- une étape (26) de chargement et d'installation de l'Application de confiance sur le Terminal de Communication Mobile de l'utilisateur ; - une étape d'activation de l'Application de confiance après vérification (28,30) du Code d'authenticité ; - une étape de génération par l'Application de confiance d'une Clé secrète ; - une étape (32) de transmission sécurisée de la Clé secrète et desdits paramètres au serveur du Tiers de confiance ; - une étape (34) de vérification des éléments reçus par le Tiers de confiance et d initialisation des registres de l'utilisateur ; - une étape (36) d'envoi d'un message de confirmation d'activation à l'Application de confiance par le Tiers de confiance. 10. Procédé d'authentification selon la revendication 8 ou la revendication 9, caractérisé en ce que l'Application de confiance est chargée et installée dans une mémoire du Terminal de Communication Mobile, de façon à la rendre exécutable par un microprocesseur du Terminal de Communication Mobile. 11. Procédé d'authentification selon la revendication 8 ou la revendication 9, caractérisé en ce que l'Application de confiance est chargée et installée dans une mémoire de la carte SIM, de façon à la rendre exécutable par le microprocesseur de la carte SIM ou du Terminal de Communication Mobile. 12. Procédé d'authentification selon la revendication 8 ou la revendication 9, caractérisé en ce l'étape d'Activation de l'Application de confiance est exécutée lors de la première exécution de l'Application de confiance et comporte les étapes suivantes : - Affichage (28) sur l'écran du Terminal de Communication Mobile du Code d'authenticité, pour vérification par l'utilisateur de sa conformité avec le Code d'authenticité affiché lors de l'étape d'enregistrement du Terminal de Communication Mobile ; - A réception (30) par le Terminal de Communication Mobile d'une confirmation par l'utilisateur de la concordance du Code d'authenticité affiché avec le Code d'authenticité attendu ;- Génération par l'Application de confiance d'une Clé secrète (Ks) ; - Construction d'un message, à partir de l'identifiant de retrait, de la Clé secrète (Ks), et du Code d'authenticité ; - Chiffrement dudit message à l'aide de la dé publique du Tiers de confiance ; - Positionnement à zéro d'un compteur (compteur mobile) de mots de passe à usage unique (0TP) du Terminal de Communication Mobile ; - Transmission (32) du message ainsi chiffré au serveur (7) du Tiers de confiance ; - à réception par le serveur du Tiers de confiance, déchiffrement (34) dudit message chiffré, à l'aide de la clé privée du Tiers de confiance, de façon à extraire la Clé secrète (Ks) 1 o générée dans le Mobile et partager cette même Clé secrète (Ks) entre l'Application de confiance et le serveur du Tiers de confiance ; - Vérification du Code d'authenticité extrait du message déchiffré ; -Positionnement à zéro d'un compteur (Compteur base) de mots de passe à usage unique (OTP) au niveau du serveur du Tiers de Confiance ; 15 -Transmission (36) au Terminal de Communication Mobile d'un message de bonne fin de l'activation de l'Application de confiance. 13. Procédé d'authentification selon l'une quelconque des revendications précédentes, caractérisé en ce que l'authentification d'un utilisateur à l'aide du second facteur 20 d'authentification comporte : - une étape (40) consistant pour l'utilisateur à lancer sur son Terminal de Communication Mobile (3) l'Application de confiance préalablement activée et à saisir (42,44) son Code PIN sur ledit Terminal de Communication Mobile (3); - une étape (46) consistant à calculer le Code d'authentification à usage unique (OTP) 25 dans le Terminal de Communication Mobile (3) au moyen de l'Application de confiance, puis à afficher (48) le Code d'authentification à usage unique (OTP) ainsi calculé sur l'écran du Terminal de Communication Mobile; - une étape (50) consistant à demander à l'utilisateur de saisir au niveau du serveur applicatif (5) son identifiant (ID) et le Code d'authentification à usage unique (OTP) ainsi 30 calculé ,- au niveau du serveur applicatif (5), une étape (52) consistant à récupérer le Numéro de Mobile et HPIN à partir de l'identifiant mémorisé de l'utilisateur, puis à calculer un mot de passe réduit (OTP_r) et à transmettre (54) le Numéro de Mobile et le mot de passe réduit (OTP_r) au serveur (7) du Tiers de confiance ; - au niveau du serveur (7) du Tiers de confiance, une étape (56) consistant à calculer une valeur Incrément puis à incrémenter la valeur dudit compteur (Compteur base) de la valeur Incrément calculée, puis une étape (58) consistant à renvoyer au serveur applicatif un signal OK si l'Incrément est supérieur à zéro, ou un signal NON OK dans le cas contraire; - au niveau du serveur applicatif (5), si le signal reçu du serveur (7) du Tiers de 1 o confiance est OK, une étape (62) consistant à notifier à l'utilisateur que son authentification auprès du Service applicatif (15) est réussie, et dans le cas contraire, à notifier à l'utilisateur que son authentification à échoué et lui refuser l'accès au Service applicatif (15). 14. Procédé d'authentification selon la revendication 13, caractérisé en ce que le Code 15 d'authentification à usage unique (OTP) est calculé selon une fonction (Fi) du Code d'authentification PIN ou de H(PIN), du compteur (Compteur mobile) du Terminal de Communication Mobile et de la Clé secrète (Ks) partagée avec le serveur du Tiers de confiance. 15. Procédé d'authentification selon la revendication 14, caractérisé en ce que le mot 20 de passe réduit (OTP_r) est calculé selon une fonction (F2) de HPIN et du Code d'authentification à usage unique (OTP). 16. Procédé d'authentification selon la revendication 14, caractérisé en ce que la valeur Incrément est calculée selon une fonction (F3) de la valeur du compteur 25 (Compteur base) du serveur du Tiers de Confiance, de la Clé secrète (Ks) et du mot de passe réduit (0TP_r). 17. Procédé de signature d'une transaction entre un serveur applicatif (5) et un utilisateur préalablement enregistré et authentifié auprès dudit serveur applicatif (5) 30 conformément à un procédé d'authentification selon l'une quelconque des revendications 1 à 16, caractérisé en ce qu'il comporte les étapes suivantes :- une étape (66) consistant à préparer au niveau du serveur applicatif (5) un � Bon à exécuter� (BAE) représentatif de la transaction à signer, suivie de la transmission (68) du � Bon à exécuter � et du Numéro de Mobile de l'utilisateur au serveur (7) du Tiers de confiance; - une étape (70) consistant à générer au niveau du serveur (7) du Tiers de confiance un Défi aléatoire, puis une étape (76) consistant à préparer et envoyer au Terminal de Communication Mobile (3) de l'utilisateur le � Bon à exécuter� et le Défi ; - après acceptation (82) du � Bon à exécuter� par l'utilisateur et saisie de son Code PIN, une étape (84) consistant à calculer au niveau de l'Application de confiance une Réponse 1 o (R4) à l'envoi du � Bon à exécuter � par le Tiers de confiance ; - après saisie (88) de la Réponse (R4) par l'utilisateur sur le Service applicatif, calcul (90) par le Serveur applicatif d'une Réponse réduite (Resp_r) ; - transmission (92) par le serveur applicatif (5) du Numéro de Mobile et de la Réponse réduite (Resp_r) précédemment calculée, au Serveur (7) du Tiers de confiance ; 15 - au niveau du serveur (7) du Tiers de confiance, calcul (94) d'un Résultat (R6) et en fonction de la valeur dudit Résultat (R6), indiquer au Service applicatif (5) si l'utilisateur a valablement signé le � Bon à exécuter � ou non. 18. Procédé de signature selon la revendication 17, caractérisé en ce que ladite 20 Réponse (R4) à l'envoi du � Bon à exécuter � par le Tiers de confiance, est calculée par l'Application de confiance selon une fonction (F4) du � Bon à exécuter �, du Défi, de PIN, et de la Clé secrète (Ks). 19. Procédé de signature selon la revendication 17, caractérisé en ce que ladite 25 Réponse réduite (Resp_r) est calculée par le Service applicatif selon une fonction (F5) de H(PIN), du � Bon à exécuter �, de ladite Réponse (R4 ). 20. Procédé de signature selon la revendication 17, caractérisé en ce que ledit Résultat (R6) est une fonction booléenne (F6) du Défi, de la Clé secrète (Ks), et de la Réponse réduite 30 (Resp_r).