FR3010214A1

FR3010214A1 - Procede d'authentification de transaction

Info

Publication number: FR3010214A1
Application number: FR1358428A
Authority: FR
Inventors: Emmanuel Ruiz
Original assignee: Individual
Current assignee: Individual
Priority date: 2013-09-03
Filing date: 2013-09-03
Publication date: 2015-03-06
Anticipated expiration: 2033-09-03
Also published as: FR3010214B1

Abstract

L'invention vise un procédé d'authentification de transaction entre deux utilisateurs dudit procédé, comportant des étapes dans lesquelles : - un message d'authentification est généré par un serveur d'authentification à la demande d'un des deux utilisateurs, ledit message d'authentification étant spécifique à chaque transaction à signer, - ledit message d'authentification est transmis par ledit serveur d'authentification, via un réseau de communication, à destination d'un terminal mobile associé à un des utilisateurs, - ledit message est transformé en message sonique ou ultrasonique par ledit terminal, - ledit message sonique ou ultrasonique est émis par ledit terminal et écouté par un autre terminal mobile, associé à l'autre utilisateur, - le message sonique ou ultrasonique reçu est retransmis par le second terminal mobile à destination du serveur d'authentification pour comparaison avec le message attendu et validation.

Description

La présente invention vise un procédé d'authentification d'utilisateur pour procédé de transfert de données. Elle vise plus précisément un procédé d'authentification dite forte, sans contact en champ proche, notamment pour procédé de paiement à distance.

Elle relève du domaine des procédés de transmission de données de manière sécurisée. Préambule et art antérieur On connaît déjà divers procédés d'authentification d'un utilisateur lors d'une transaction de type paiement par carte de crédit, par exemple durant un achat sur un site de e-commerce. Parmi ces procédés, un des plus couramment utilisés à ce jour est le procédé dans lequel, une fois une transaction effectuée et le paiement requis en ligne par l'utilisateur sur un site de e-commerce, ledit utilisateur reçoit de la part de sa banque un code sous forme de SMS sur son téléphone mobile, et doit entrer ce code sur l'interface utilisateur de paiement de sa transaction pour authentifier celle-ci. Le fait que la personne effectuant la transaction dispose du téléphone mobile du titulaire du compte bancaire est considéré comme une preuve suffisante de l'identité de ce titulaire.

De même, lors d'un paiement dans un magasin par carte de crédit, il est courant que l'utilisateur vienne entrer son code secret sur un terminal de paiement pour valider sa transaction. Cette signature par entrée du code secret a cependant l'inconvénient du manque de sécurité engendré par la frappe du code devant d'autres personnes.

D'autres méthodes ont été envisagées pour pallier cet inconvénient, notamment par utilisation de e-carte de crédit, c'est-à-dire d'une carte de crédit à usage unique, dont les données (dites OTP pour "One Time Password") sont générées à la demande de l'utilisateur pour un usage lors d'un unique achat. On connaît encore la technologie des paiements par téléphones équipés pour le procédé de communication en champ proche (en anglais "Near Field Communication", d'où l'acronyme NFC). Dans cette technologie, un terminal émet à très courte distance (1 à 10 cm typiquement) un message haute fréquence électromagnétique vers un terminal récepteur pour transmettre une information de signature électronique. Mais, à ce jour, seuls 3 à 5 % des téléphones mobiles sont compatibles avec la technologie NFC, ce qui limite l'utilisation d'authentification par ce moyen, et restreint, pour des raisons de coût, ses chances de généralisation 5 auprès des commerçants ou clients. Ces différents procédés sont complexes ou manquent de sécurité pour l'utilisateur. Exposé de l'invention 10 L'invention vise à cet effet en premier lieu un procédé d'authentification de transaction entre deux utilisateurs dudit procédé (dits client et commerçant), un premier utilisateur étant doté d'un premier terminal mobile, un second utilisateur étant doté d'un second terminal mobile, au moins un de ces terminaux mobiles comportant des moyens d'émettre un signal en bande 15 audio, et au moins l'autre terminal mobile comportant des moyens de recevoir un signal audio. On utilise donc ici des ondes acoustiques pour échanger des informations entre les deux dispositifs de manière sécurisée. Le procédé comporte des étapes dans lesquelles : - un message d'authentification est généré par un serveur 20 d'authentification à la demande d'un des deux utilisateurs, - ledit message d'authentification est transmis, via un réseau de communication, à destination d'un terminal mobile associé à un des utilisateurs, - ledit message d'authentification est codé sous forme de message 25 sonique ou ultrasonique comportant au moins une partie du message codée sous forme de sons ou d'ultrasons dans la bande de fréquences compatible avec une réception par un téléphone mobile classique, - ledit message sonique ou ultrasonique est émis par ledit terminal mobile et écouté par l'autre terminal mobile, associé à l'autre utilisateur, 30 - le message sonique ou ultrasonique reçu est retransmis par le second terminal mobile à destination du serveur d'authentification pour comparaison avec le message attendu et pour validation.

Le processus d'authentification comprend deux facteurs de sécurité : le premier est le nom de l'utilisateur et le code PIN, qui garantit l'identité de l'utilisateur, et le second consiste dans un code sonique ou ultrasonique qui garantit la proximité et la possession des dispositifs qui interviennent dans la transaction. Il s'agit bien d'une authentification en champ proche. Dans une mise en oeuvre particulière, la transformation du message d'authentification en message sonique ou ultrasonique est réalisée au niveau du serveur d'authentification avant transmission au terminal mobile, Dans une mise en oeuvre plus particulière, le serveur d'authentification est alors par exemple de type IVR ("Interactive Voice Response server"). Dans une mise en oeuvre alternative, la transformation (codage et éventuellement brouillage) du message d'authentification en message sonique ou ultrasonique est réalisée au niveau du terminal mobile. Dans une mise en oeuvre particulière, le message d'authentification est de type à usage unique (OTP), spécifique à chaque transaction à signer. Cette disposition garantit une sécurité accrue de la transaction. Dans une mise en oeuvre particulière, le procédé comporte une étape de validation des canaux de communication soniques ou ultrasoniques entre les deux terminaux mobiles. De cette manière, le procédé s'adapte aux conditions existantes au niveau du commerçant et du client, et optimise la force de l'authentification en fonction de ces canaux de communication disponibles. Il est notamment capable d'utiliser éventuellement les capacités ultrasonores des terminaux, si ceux-ci en sont dotés. Dans une première mise en oeuvre, un premier terminal mobile, dit "terminal de paiement du commerçant" étant supposé doté de moyens d'écouter un message sonique ou ultrasonique et de le retransmettre à destination d'un serveur dit "serveur d'authentification", et un second terminal mobile, de type téléphone mobile, dit "téléphone mobile du client", étant supposé doté d'une application logicielle adaptée à transformer (codage et éventuellement brouillage) un message reçu du serveur d'authentification, le procédé comporte notamment des étapes suivantes : - étape 301 : le terminal de paiement du commerçant émet une demande d'autorisation de transaction à destination du serveur d'authentification, - étape 302: le serveur d'authentification, vérifie les moyens de communication soniques ou ultrasoniques existants entre le terminal de paiement du commerçant et le téléphone mobile du client, - étape 303 : dans le cas où les deux terminaux sont capables d'émettre et de recevoir des messages soniques ou ultrasoniques, le serveur d'authentification obtient ou génère un mot de passe à usage unique, puis coupe alors ce mot de passe en au moins deux segments, et envoie certains de ces segments au terminal de paiement, et les autres segments au téléphone mobile du client, au moins une partie de ces segments du mot de passe à usage unique étant transformé (codé et éventuellement brouillé) par le terminal de paiement ou le téléphone mobile en messages soniques ou ultrasoniques dans la bande de fréquence compatible avec les moyens d'émission dudit terminal de paiement et avec les moyens de réception d'un téléphone mobile typique, - le terminal de paiement et le téléphone mobile émettent les messages soniques ou ultrasoniques correspondants aux segments de mot de passe qu'ils ont reçu du serveur d'authentification, - étape 304: le téléphone mobile du client, et le terminal de paiement écoutent lesdits messages soniques ou ultrasoniques et les enregistrent, puis transmettent ces enregistrements au serveur d'authentification, - étape 305 : le serveur d'authentification, reçoit les enregistrements des messages soniques ou ultrasoniques de la part du téléphone mobile du client et du terminal de paiement du commerçant, il décode ces messages soniques ou ultrasoniques pour en extraire les segments du message original, et compare ce message une fois reconstitué avec le mot de passe original pour validation. Dans une autre mise en oeuvre, le second terminal mobile, de type téléphone mobile, dit "téléphone mobile du client", étant supposé doté d'une application logicielle adaptée à transformer un message reçu d'un serveur associé au générateur d'authentification, dit "serveur d'authentification", en message sonique ou ultrasonique ayant éventuellement subi une distorsion volontaire (brouillage), le premier terminal mobile, dit "terminal de paiement du commerçant" étant supposé doté de moyens d'écouter un message sonique ou ultrasonique et de le retransmettre à destination du serveur d'authentification et doté de moyens de générer un mot de passe à usage unique, le procédé comporte notamment des étapes suivantes : - étape 401 : le terminal de paiement du commerçant émet une demande d'autorisation de transaction à destination du serveur d'authentification et initialise la transaction, - étape 402: le terminal de paiement vérifie les moyens de communication soniques ou ultrasoniques existants entre le terminal de paiement du commerçant et le téléphone mobile du client, - étape 403 : dans le cas favorable, le terminal de paiement coupe le mot de passe généré par le serveur d'authentification en au moins deux segments, envoie au téléphone mobile du client certains de ces segments par l'intermédiaire du serveur d'authentification, et les autres segments par voie sonique ou ultrasonique, - étape 404 : le téléphone mobile du client écoute le message sonique ou ultrasonique reçu du terminal de paiement et l'enregistre, puis transmet cet enregistrement et le segment de message reçu au terminal de paiement via ledit serveur d'authentification, - étape 405 : le terminal de paiement reçoit les informations de la part du téléphone mobile du client, en extrait le message original, et compare ce message une fois reconstitué avec le mot de passe original. Plus particulièrement dans ce cas, dans l'étape 404, la transmission de 25 l'enregistrement et du segment de message reçu est effectuée par l'intermédiaire du serveur d'authentification. Alternativement, dans l'étape 404, une partie au moins de l'enregistrement et du segment de message reçu est émise sous forme sonique ou ultrasonique par le téléphone mobile du client vers le terminal de 30 paiement. Dans une variante, le message d'authentification à usage unique fourni par le serveur d'authentification est codé par le serveur d'authentification lui- même sous forme de message sonique ou ultrasonique, le serveur d'authentification, étant en relation avec un server de type VoIP (voix sur IP), c'est-à-dire capable de générer des appels téléphoniques et des signaux dans une bande de fréquences audibles et ultrasoniques.

L'invention vise sous un second aspect un terminal de paiement, un téléphone mobile ou un serveur d'authentification, mettant en oeuvre un procédé tel qu'exposé.

Présentation des figures Les caractéristiques et avantages de l'invention seront mieux appréciés grâce à la description qui suit, description qui expose les caractéristiques de l'invention au travers d'un exemple non limitatif d'application. La description s'appuie sur les figures annexées qui représentent : Figure 1 : un schéma des éléments mis en oeuvre dans le procédé, Figure 2 : un schéma des étapes du procédé dans un premier mode de mise en oeuvre, Figure 3 : un schéma des étapes de procédé dans une variante de ce premier mode de mise en oeuvre, Figure 4 : un schéma des étapes de procédé dans un second mode de mise en oeuvre, Figure 5 : un schéma des étapes de procédé dans un troisième mode de mise en oeuvre.

Description détaillée d'un mode de réalisation de l'invention Comme on le voit sur la figure 1, l'invention trouve sa place dans le cadre d'une transaction entre un premier utilisateur 10 appelé commerçant dans la suite de la description, et un second utilisateur 11 appelé client dans la suite de la description.

Le commerçant 10 est supposé dote d'un terminal de paiement 12 comportant des moyens de communication, via un réseau 14, par exemple de type GSM / filaire, avec un serveur d'authentification 13 capable de fournir des autorisations de transactions. Dans le présent exemple de réalisation, le terminal de paiement 12 du commerçant 10 est également supposé doté d'un haut-parleur 16 adapté à émettre un message sonique ou ultrasonique en bande compatible avec la bande de fréquences d'émission et / ou de réception d'un téléphone mobile.

Le client 11 est supposé doté d'un terminal mobile 15 de type téléphone mobile ou tablette ou TPE ou caisse enregistreuse, doté de moyens de communication via un réseau de communications 14, par exemple GSM, avec divers services à distance. Ce téléphone mobile 15 comporte naturellement un microphone capable de recevoir un signal audio et un speaker pour émettre un signal audio, dans une bande de fréquences comportant la bande de fréquence audible par l'oreille humaine et ultrasonique. L'invention est destinée à être mise en oeuvre sous forme logicielle. Ledit logiciel est installé, dans le présent exemple non limitatif de mise en oeuvre, pour partie dans le serveur d'authentification 13, et pour partie dans le terminal 15 de paiement 12 du commerçant 10. Dans une variante de réalisation, une partie du logiciel est également installée dans le téléphone mobile 15 du client 11, sous forme par exemple d'application smartphone de type "apps". 20 Mode de fonctionnement Dans un premier mode de mise en oeuvre, illustré par la figure 2, le procédé d'authentification de transaction comporte cinq étapes principales, pour valider un paiement réalisé par le client 11 chez le commerçant 10. Dans cette mise en oeuvre, le téléphone mobile 15 du client 11 est 25 supposé doté d'une application logicielle adaptée à transformer (coder et éventuellement brouiller) tout ou partie de l'OTP émis par le serveur d'authentification 13, en message sonique ou ultrasonique. Le serveur d'authentification 13 est celui qui génère le mot de passe à usage unique (OTP). 30 De même, dans cette première mise en oeuvre, le terminal de paiement 12 est supposé doté de moyens d'écouter un message sonique ou ultrasonique et de le retransmettre à destination du serveur d'authentification 13.

Dans une première étape 301, le terminal de paiement 12 du commerçant 10 émet une demande d'autorisation de transaction à destination du serveur d'authentification 13. Dans une seconde étape 302, le serveur d'authentification 13 vérifie les moyens de communication existants entre le terminal de paiement 12 du commerçant 10 et le téléphone mobile 15 du client 11. Cette étape consiste à vérifier lesquels des deux terminaux 12, 15 sont capables d'émettre et/ou de recevoir des messages soniques ou ultrasoniques. À cet effet, dans le présent exemple nullement limitatif, le serveur d'authentification, ici associé à un serveur de type VoIP, émet des sons ou ultrasons via le réseau de communication TCP/IP à destination du terminal de paiement 12 du commerçant et via le réseau de téléphonie mobile, ici GSM, à destination du téléphone mobile 15 du client 11, afin de reconnaître les voies de communication audio disponibles entre le terminal de paiement 12 et le téléphone mobile 15. Le serveur détermine de la sorte les voies de communication audio possibles entre le terminal de paiement 12 et le téléphone mobile 15, c'est-à-dire concrètement entre le haut-parleur du terminal de paiement 12 et le microphone du téléphone mobile 15, et/ou entre le haut-parleur du téléphone mobile 15 et le microphone du terminal de paiement 12. Lors de la détermination des voies de communication possibles, le serveur d'authentification 13 teste également la capacité de chacun des terminaux mobiles en émission et en réception de message dans le domaine sonore et ultrasonore. De la sorte, le système peut utiliser au mieux les capacités de chaque groupe de deux terminaux, et s'adapter aux téléphones mobiles plus anciens, qui ne possèdent pas de capacité ultrasonore. Le test peut être réalisé lors de chaque transaction, le procédé permet de s'adapter également à des variations dans le temps des capacités des terminaux mobiles, ou à des conditions d'environnement sonore difficiles (bruits extérieurs etc.). Dans ces cas, le codage du message est avantageusement réalisé dans les fréquences les mieux reçues par les terminaux mobiles et / ou les moins bruitées.

Dans le cas où le terminal de paiement 12 n'est pas capable d'écouter des signaux soniques, le procédé est détaillé plus bas (étapes 303' à 306'). Dans le cas où les deux terminaux 12, 15 sont capables d'émettre et de recevoir des messages soniques, dans une étape 303, le serveur d'authentification 13 génère un mot de passe à usage unique. Alternativement, le serveur d'authentification 13 ne génère pas lui-même ce mot de passe à usage unique, mais le reçoit d'un service de gestion de mots de passe, éventuellement distant. Ce service de gestion de mots de passe est alors adapté à générer un mot de passe à usage unique, et à authentifier un tel mot de passe lorsqu'il est reçu. Le serveur d'authentification 13 coupe alors ce mot de passe en segments de façon aléatoire, et envoie certains de ces segments au terminal de paiement 12, et les autres segments au téléphone mobile 15 du client. Dans le présent exemple de mise en oeuvre, le mot de passe est coupé en deux segments de longueurs éventuellement différentes. Dans une variante, il est scindé en multiples segments. Toujours dans cette étape 303, chacun de ces segments du mot de passe à usage unique est transformé par le terminal de paiement 12 et le téléphone mobile 15 en messages soniques ou ultrasoniques dans la bande de fréquence compatible avec les moyens d'émission dudit terminal de paiement 12 et avec les moyens de réception d'un téléphone mobile typique. Le terminal de paiement 12 et le téléphone mobile 15 émettent les messages soniques ou ultrasoniques correspondants aux segments de mot de passe qu'ils ont reçu du serveur d'authentification 13.

Dans une étape 304, le téléphone mobile 15 du client 11, et le terminal de paiement 12 écoutent lesdits messages soniques ou ultrasoniques et les enregistrent, puis transmettent ces enregistrements au serveur d'authentification 13. Enfin, dans une étape 305, le serveur d'authentification 13 reçoit les 30 enregistrements des messages soniques de la part du téléphone mobile 15 du client 12 et du terminal de paiement 12 du commerçant 10. Le serveur d'authentification 13 transforme ces messages soniques ou ultrasoniques de façon inverse pour en extraire les segments du message original, et compare ce message une fois reconstitué avec le mot de passe original. Le serveur d'authentification 13 notifie alors au client 11 via son téléphone mobile 15 et au commerçant 10 via son terminal de paiement 12 la réussite ou l'échec de la signature de la transaction. Dans une variante de cette mise en oeuvre, dans le cas où le terminal de paiement est capable de recevoir des messages soniques ou ultrasoniques, et où le téléphone mobile est doté d'une application logicielle spécifique, l'ensemble du mot de passe est envoyé au téléphone mobile 15 du client 11. Il est alors émis sous forme sonique ou ultrasonique et reçu par le terminal de paiement 12, qui le renvoie vers le serveur d'authentification 13 via le réseau TCP/IP pour validation. Il s'agit alors d'un mode de mise en oeuvre similaire à la première mise en oeuvre du procédé, telle que décrite plus haut, en renversant les rôles du terminal de paiement 12 et du téléphone mobile 15. Après l'étape 302 de détermination par le serveur d'authentification, des voies de communication audio possibles entre le terminal de paiement 12 et le téléphone mobile 15, lorsque le terminal de paiement est capable seulement d'émettre des messages soniques, mais pas de les recevoir, le procédé comporte, dans un exemple non limitatif de mise en oeuvre, des étapes suivantes (voir figure 3) Dans une étape 303', le serveur d'authentification 13 génère un tel mot de passe à usage unique. Alternativement, le serveur d'authentification 13 ne génère pas lui-même ce mot de passe à usage unique, mais le reçoit d'un service de gestion de mots de passe, éventuellement distant. Ce service de gestion de mots de passe est alors adapté à générer un mot de passe à usage unique, et à authentifier un tel mot de passe lorsqu'il est reçu. Le mot de passe à usage unique, usuellement une suite de caractères ou de chiffres, est envoyé au terminal de paiement 12 du commerçant 10, et transformé par ledit terminal de paiement en message sonique ou ultrasonique dans la bande de fréquence compatible avec les moyens d'émission dudit terminal de paiement 12 et avec les moyens de réception d'un téléphone mobile typique. Il s'agit ici d'un message comportant au moins une partie codée sous forme de sons ou/et d'ultrasons, non audibles ou audibles par l'homme mais entrant dans la bande de fréquences reçue correctement par un téléphone mobile classique du marché. Simultanément, le serveur d'authentification, appelle le téléphone mobile 15 du client 11, qui décroche, de manière à être prêt à recevoir le message sonique. Dans une étape 304', le terminal de paiement 12 émet le message sonique par l'intermédiaire de son haut-parleur. Dans une étape 305', le téléphone mobile 15 du client 11 écoute ledit message sonique par son microphone, et l'enregistre, puis le transmet au serveur d'authentification 13. Enfin, dans une étape 306', le serveur d'authentification 13 reçoit l'enregistrement du message sonique de la part du téléphone mobile 15 du client 12, le transforme de façon inverse pour en extraire le message original, et compare ce message avec le message émis à destination du terminal de paiement 12 chez le commerçant 11. Le serveur d'authentification 13 notifie alors au client 11 via son téléphone mobile 15 et au commerçant 10 via son terminal de paiement 12 la réussite ou l'échec de la signature de la transaction.

Dans un second mode de mise en oeuvre, illustré par la figure 4, le procédé d'authentification de transaction comporte encore cinq étapes principales, pour valider un paiement réalisé par le client 11 chez le commerçant 10. Dans cette seconde mise en oeuvre, le téléphone mobile 15 du client 11 est encore supposé doté d'une application logicielle adaptée à transformer ou brouiller un OTP reçu du serveur d'authentification 13 en message sonique ou ultrasonique. De même, dans cette seconde mise en oeuvre, le terminal de paiement 12 est encore supposé doté de moyens d'écouter un message sonique ou ultrasonique et de le retransmettre à destination du serveur d'authentification 13. Il est également supposé ici doté de moyens de transformer (coder et éventuellement brouiller) un mot de passe à usage unique Dans une première étape 401, le terminal de paiement 12 du commerçant 10 émet une demande d'autorisation de transaction à destination du serveur d'authentification 13 et initialise la transaction. Dans une seconde étape 402, le terminal de paiement 12 vérifie les moyens de communication existants entre le terminal de paiement 12 du commerçant 10 et le téléphone mobile 15 du client 11. Cette étape consiste à vérifier si les deux terminaux 12, 15 sont capables d'émettre et de recevoir des messages soniques ou ultrasoniques, et de préciser dans quelles bandes de fréquences acoustiques ils sont capables de communiquer en émission et réception, et éventuellement quelles sont les bandes les plus efficaces. Dans le cas favorable, dans une étape 403, le terminal de paiement 12 génère un mot de passe à usage unique. Le terminal de paiement 12 coupe alors ce mot de passe en segments de façon aléatoire, et envoie au téléphone mobile 15 du client 11 certains de ces segments par l'intermédiaire du serveur d'authentification 13, et les autres segments par voie sonique ou ultrasonique au client 11. Dans le présent exemple de mise en oeuvre, le mot de passe est coupé en deux segments de longueurs éventuellement différentes. Dans une variante, il est scindé en multiples segments. Dans une étape 404, le téléphone mobile 15 du client 11 écoute le message sonique ou ultrasonique reçu du terminal de paiement et l'enregistre, puis transmet cet enregistrement et le segment de message reçu par l'intermédiaire du serveur d'authentification 13 au terminal de paiement 12 via ledit serveur d'authentification 13. Alternativement, une partie ou la totalité de ces informations est émise sous forme sonique ou ultrasonique par le téléphone mobile 15 du client 11 vers le terminal de paiement 12. Enfin, dans une étape 405, le terminal de paiement 12 reçoit les informations de la part du téléphone mobile 12 du client 11, en extrait le message original, et compare ce message une fois reconstitué avec le mot de passe original. Le serveur d'authentification 13 notifie alors au client 11 via son téléphone mobile 15 et au terminal de paiement 12 la réussite ou l'échec de la signature de la transaction.

Dans une troisième mode de mise en oeuvre, illustré par la figure 5, le procédé d'authentification de transaction concerne un cas où ni le téléphone mobile 15 du client 11, ni le terminal de paiement 12 ne sont dotés d'applications spécifiques pour mettre en oeuvre le procédé. De cette manière, le procédé est utilisable très facilement, y compris par des personnes désirant effectuer une transaction et non équipées d'applications spécifiques. Le serveur d'authentification 13 est, quant à lui, associé à un serveur de type serveur IVR ("Interactive Voice Response"), générer et recevoir des 10 messages sonores. De même, dans cette troisième mise en oeuvre, le terminal de paiement 12 est encore supposé doté de moyens d'écouter un message sonique et de le retransmettre à destination du serveur d'authentification 13. Il s'agit ici typiquement d'un téléphone typique. 15 Dans une première étape 501, le terminal de paiement 12 du commerçant 10 appelle le serveur d'authentification 13. Dans une étape 502, il émet une demande d'autorisation de transaction en envoyant son identifiant de terminal de paiement, le numéro de téléphone du client et le montant de la transaction qui doit être réalisée. 20 Dans une étape 503, le serveur d'authentification 13 vérifie les données reçues, génère un mot de passe à usage unique et appelle le numéro du téléphone mobile du client. Dans une étape 504, le client entre un code de validation (de type code pin de carte de crédit) sur son téléphone mobile 15 qui envoie ces données au 25 serveur d'authentification 13. Dans une étape 505, le terminal de paiement 12 et le téléphone mobile 15 sont rapprochés et le mot de masse codé sous forme sonique par le serveur d'authentification de type IVR est transmis entre eux. Le serveur d'authentification 13 reçoit le message tel que reçu. 30 Le serveur d'authentification 13 notifie alors dans une étape 506 au client 11 via son téléphone mobile 15 et au terminal de paiement 12 la réussite ou l'échec de la signature de la transaction.

Dans une variante de cette troisième mise en oeuvre, le serveur vérifie les moyens de communication, de façon analogue à ce qui a été décrit pour la première mise en oeuvre, Dans une autre variante, le serveur scinde le mot de passe sonique en multiples segments et les envoie sur les différentes voies de communication validées, de façon analogue à ce qui a été décrit pour la seconde mise en oeuvre du procédé. Dans toute la description qui précède, il a été fait référence à une transaction de type paiement d'un achat. Il est clair que le procédé décrit s'applique plus largement à tout type d'authentification en champ proche, permettant à deux terminaux de communiquer de façon sécurisée.

Claims

REVENDICATIONS1. Procédé d'authentification de transaction entre deux utilisateurs dudit procédé, un premier utilisateur étant doté d'un premier terminal mobile, un second utilisateur étant doté d'un second terminal mobile, au moins un de ces terminaux mobiles (12, 15) comportant des moyens d'émettre un signal en bande audio, et au moins l'autre terminal mobile comportant des moyens de recevoir un signal audio, caractérisé en ce qu'il comporte des étapes dans lesquelles : - un message d'authentification est généré par un serveur d'authentification (13) à la demande d'un des deux utilisateurs, - ledit message d'authentification est transmis, via un réseau de communication, à destination d'un terminal mobile associé à un des utilisateurs, - ledit message d'authentification est codé sous forme de message sonique ou ultrasonique comportant au moins une partie du message codée 15 sous forme de sons et/ou d'ultrasons dans la bande de fréquences compatible avec une réception par un téléphone mobile classique, - ledit message sonique est émis par ledit terminal mobile et écouté par l'autre terminal mobile, associé à l'autre utilisateur, - le message sonique reçu est retransmis par le second terminal mobile 20 à destination du serveur d'authentification (13) pour comparaison avec le message attendu et pour validation.
2. Procédé selon la revendication 1, caractérisé en ce que la transformation du message d'authentification en message sonique ou 25 ultrasonique est réalisée au niveau du serveur d'authentification (13) avant transmission au terminal mobile.
3. Procédé selon la revendication 1, caractérisé en ce que la transformation du message d'authentification en message sonique ou 30 ultrasonique est réalisée au niveau du terminal mobile.
4. Procédé selon l'une quelconque des revendications 1 à 3, dans lequel le message d'authentification est de type à usage unique (OTP), spécifique à chaque transaction à signer.
5. Procédé selon l'une quelconque des revendications 1 à 2, caractérisé en ce qu'il comporte une étape de validation des canaux de communication soniques ou ultrasoniques entre les deux terminaux mobiles (12, 15).
6. Procédé selon l'une quelconque des revendications 1 à 5, le second terminal mobile (15), de type téléphone mobile, dit "téléphone mobile du client", étant supposé doté d'une application logicielle adaptée à transformer un message reçu d'un serveur dit serveur d'authentification (13) en message sonique, et le premier terminal mobile (12), dit "terminal de paiement du commerçant" étant supposé doté de moyens d'écouter un message sonique ou ultrasonique et de le retransmettre à destination du serveur d'authentification (13), caractérisé en ce qu'il comporte notamment des étapes suivantes : - étape 301 : le terminal de paiement (12) émet une demande d'autorisation de transaction à destination du serveur d'authentification (13), - étape 302: le serveur d'authentification (13) vérifie les moyens de communication soniques ou ultrasoniques existants entre le terminal de paiement (12) et le téléphone mobile (15) du client (11), - étape 303: dans le cas où les deux terminaux mobiles (12, 15) sont capables d'émettre et de recevoir des messages soniques ou ultrasoniques, le serveur d'authentification (13) obtient un mot de passe à usage unique, puis coupe alors ce mot de passe en au moins deux segments, et envoie certains de ces segments au terminal de paiement (12), et les autres segments au téléphone mobile 15 du client, au moins une partie de ces segments du mot de passe à usage unique étant transformée par le terminal de paiement (12) et le téléphone mobile (15) en messages soniques ou ultrasoniques dans la bande de fréquence compatible avec les moyens d'émission dudit terminal de paiement (12) et avec les moyens de réception d'un téléphone mobile typique.- le terminal de paiement (12) et le téléphone mobile (15) émettent les messages soniques correspondants aux segments de mot de passe qu'ils ont reçu du serveur d'authentification (13), - étape 304: le téléphone mobile (15) du client, et le terminal de paiement (12) écoutent lesdits messages soniques ou ultrasoniques et les enregistrent, puis transmettent ces enregistrements au serveur d'authentification (13), - étape 305 : le serveur d'authentification (13) reçoit les enregistrements des messages soniques ou ultrasoniques de la part du téléphone mobile (15) du client et du terminal de paiement (12), il décode ces messages soniques pour en extraire les segments du message original, et compare ce message une fois reconstitué avec le mot de passe original pour validation.
7. Procédé selon la revendication 6, caractérisé en ce que, dans le cas où le terminal de paiement est capable de recevoir des messages soniques ou ultrasoniques, et où le téléphone mobile est doté d'une application logicielle spécifique, l'ensemble du mot de passe est envoyé au téléphone mobile (15) du client (11), puis émis sous forme sonique ou ultrasonique et reçu par le terminal de paiement (12), qui le renvoie vers le serveur d'authentification (13) via le réseau TCP/IP pour validation.
8. Procédé selon l'une quelconque des revendications 1 à 5, le second terminal mobile 15, de type téléphone mobile, dit "téléphone mobile du client", étant supposé doté d'une application logicielle adaptée à transformer un message reçu d'un serveur d'authentification (13) associé au générateur d'authentification, dit "serveur d'authentification ", en message sonique ou ultrasonique, le premier terminal mobile (12), dit "terminal de paiement du commerçant" étant supposé doté de moyens d'écouter un message sonique et de le retransmettre à destination du serveur d'authentification (13), ledit serveur d'authentification étant doté de moyens de générer un mot de passe à usage unique, caractérisé en ce qu'il comporte notamment des étapes suivantes :- étape 401 : un premier terminal mobile, dit "terminal de paiement" (12) émet une demande d'autorisation de transaction à destination du serveur d'authentification (13) et initialise la transaction, - étape 402: le terminal de paiement (12) vérifie les moyens de communication soniques ou ultrasoniques existants entre le terminal de paiement (12) du commerçant et le téléphone mobile (15) du client, - étape 403 : dans le cas favorable, le terminal de paiement (12) coupe le mot de passe généré par le serveur d'authentification (13) en au moins deux segments, envoie au téléphone mobile (15) du client certains de ces segments par l'intermédiaire du serveur d'authentification (13), et les autres segments par voie sonique ou ultrasonique, - étape 404: le téléphone mobile (15) du client écoute le message sonique ou ultrasonique reçu du terminal de paiement et l'enregistre, puis transmet cet enregistrement et le segment de message reçu au terminal de paiement (12) via ledit serveur d'authentification (13), - étape 405: le terminal de paiement (12) reçoit les informations de la part du téléphone mobile (15) du client, en extrait le message original, et compare ce message une fois reconstitué avec le mot de passe original.
9. Procédé selon la revendication 8, caractérisé en ce que, dans l'étape 404, la transmission de l'enregistrement et du segment de message reçu est effectuée par l'intermédiaire du serveur d'authentification (13)
10. Procédé selon la revendication 8, caractérisé en ce que, dans l'étape 25 404, une partie au moins de l'enregistrement et du segment de message reçu est émise sous forme sonique ou ultrasonique par le téléphone mobile (15) du client vers le terminal de paiement (12).