FR3053549A1 - Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants. - Google Patents

Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants. Download PDF

Info

Publication number
FR3053549A1
FR3053549A1 FR1656240A FR1656240A FR3053549A1 FR 3053549 A1 FR3053549 A1 FR 3053549A1 FR 1656240 A FR1656240 A FR 1656240A FR 1656240 A FR1656240 A FR 1656240A FR 3053549 A1 FR3053549 A1 FR 3053549A1
Authority
FR
France
Prior art keywords
obtaining
user device
private key
authentication
communication terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1656240A
Other languages
English (en)
Other versions
FR3053549B1 (fr
Inventor
Remi GERAUD
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Banks and Acquirers International Holding SAS
Original Assignee
Ingenico Group SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ingenico Group SA filed Critical Ingenico Group SA
Priority to FR1656240A priority Critical patent/FR3053549B1/fr
Priority to US16/314,174 priority patent/US10922679B2/en
Priority to CA3029154A priority patent/CA3029154A1/fr
Priority to EP17733483.6A priority patent/EP3479518A1/fr
Priority to PCT/EP2017/066365 priority patent/WO2018002351A1/fr
Publication of FR3053549A1 publication Critical patent/FR3053549A1/fr
Application granted granted Critical
Publication of FR3053549B1 publication Critical patent/FR3053549B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/352—Contactless payments by cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0873—Details of the card reader
    • G07F7/0893—Details of the card reader the card reader reading the card in a contactless manner
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/72—Signcrypting, i.e. digital signing and encrypting simultaneously

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Signal Processing (AREA)
  • Finance (AREA)
  • Algebra (AREA)
  • Mathematical Physics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Computing Systems (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Analysis (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Power Engineering (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention se rapporte à un procédé d'authentification d'au moins une donnée, procédé mis en œuvre lors d'une transaction de paiement intervenant entre un terminal de communication d'un commerçant et un dispositif d'utilisateur, procédé du type comprenant l'authentification par le terminal de communication d'au moins un message m générée par le dispositif d'utilisateur, par l'intermédiaire d'une liaison de données sans fils en champs proche. Un tel procédé comprend, au sein du dispositif d'utilisateur : - une étape d'obtention (10), à partir du message m, d'une donnée aléatoire t et d'une fonction de hachage H, d'un code d'authentification S1 ; - une étape d'obtention (20), à partir du message m, de la donnée aléatoire t, d'une clé publique Z du terminal de communication, d'une première clé privée x du dispositif d'utilisateur et du code d'authentification S1, d'un premier composant de signature S2 ; une étape d'obtention (30), à partir du message m, de la donnée aléatoire t, de la clé publique de Z du terminal de communication, d'une deuxième clé privée y du dispositif d'utilisateur et du code d'authentification S1, d'un deuxième composant de signature s3; - une étape de transmission (40), au terminal de communication, du code d'authentification S1, et des deux composants de signature S2 et S3.

Description

© N° de publication : 3 053 549 (à n’utiliser que pour les commandes de reproduction)
©) N° d’enregistrement national : 16 56240 ® RÉPUBLIQUE FRANÇAISE
INSTITUT NATIONAL DE LA PROPRIÉTÉ INDUSTRIELLE
COURBEVOIE © Int Cl8 : H 04 L 9/32 (2017.01), G 06 Q 20/40
DEMANDE DE BREVET D'INVENTION A1
©) Date de dépôt : 30.06.16. (© Priorité : (© Demandeur(s) : INGENICO GROUP Société anonyme — FR.
@ Inventeur(s) : GERAUD REMI.
©) Date de mise à la disposition du public de la demande : 05.01.18 Bulletin 18/01.
©) Liste des documents cités dans le rapport de recherche préliminaire : Se reporter à la fin du présent fascicule
(© Références à d’autres documents nationaux apparentés : ©) Titulaire(s) : INGENICO GROUP Société anonyme.
©) Demande(s) d’extension : © Mandataire(s) : CABINET PATRICE VIDON.
DE DONNEES DE PAIEMENT, DISPOSITIFS ET PROGRAMMES
PROCEDE D'AUTHENTIFICATION CORRESPONDANTS.
FR 3 053 549 - A1 ©J L'invention se rapporte à un procédé d'authentification d'au moins une donnée, procédé mis en oeuvre lors d'une transaction de paiement intervenant entre un terminal de communication d'un commerçant et un dispositif d'utilisateur, procédé du type comprenant l'authentification par le terminal de communication d'au moins un message m générée par le dispositif d'utilisateur, par l'intermédiaire d'une liaison de données sans fils en champs proche. Un tel procédé comprend, au sein du dispositif d'utilisateur:
- une étape d'obtention (10), à partir du message m, d'une donnée aléatoire t et d'une fonction de hachage H, d'un code d'authentification Si ;
- une étape d'obtention (20), à partir du message m, de la donnée aléatoire t, d'une clé publique Z du terminal de communication, d'une première clé privée x du dispositif d'utilisateur et du code d'authentification Si d'un premier composant de signature S2; une étape d'obtention (30), à partir du message m, de la donnée aléatoire t, de la clé publique de Z du terminal de communication, d'une deuxième clé privée y du dispositif d'utilisateur et du code d'authentification S·, d'un deuxième composant de signature s3;
- une étape de transmission (40), au terminal de communication, du code d'authentification S·, et des deux composants de signature S2 et S3.
Figure FR3053549A1_D0001
Figure FR3053549A1_D0002
ι
Procédé d'authentification de données de paiement, dispositifs et programmes correspondants.
1. Domaine
L'invention se rapporte au domaine de la sécurisation des données échangées par l'intermédiaire d'un protocole de transmission de données sans contact. La technique se rapporte plus particulièrement à la transmission de données de type NFC, dans laquelle on effectue une transmission entre un premier dispositif et un deuxième dispositif séparés d'une distance de l'ordre d'une dizaine de centimètre au plus. La technique ne s'applique pas et n'est pas destinée à s'appliquer dans le cadre de techniques de transmission de données de type WiFi, WiMax, LTE, dont les technologies de transmission sont différentes.
2. Art Antérieur
De nombreux dispositifs de la vie quotidienne sont aptes à communiquer et à échanger des données entre eux. Une part croissante de dispositifs utilisent, pour ce faire, des protocoles d'échange de données dit en champ proches ou encore NFC. Parfois, ces techniques de transmission de données sont également appelées RFID. Cette appellation n'est pas correcte puisque NFC signifie communication en champ proche, tandis que RFID se rapporte à des moyens d'identification par fréquence radio. Les deux utilisent des signaux radio pour toutes sortes de fins de repérage et de suivi, en remplaçant parfois des codes à barres. Toutes deux utilisent des moyens de transmission de données à courte portée.
Or, l'utilisation de ce type de technologie suscite encore des craintes et des interrogations de la part des utilisateurs. Nombreux sont ceux qui n'accordent pas ou peu confiance à ces technologies, plus particulièrement lorsqu'il s'agit de les utiliser à des fins de traitement de données personnelles et/ou confidentielles. C'est par exemple le cas du paiement. Relativement récemment, des dispositifs de paiement sans contact ont fait leur apparition. Il s'agit par exemple des cartes de paiement sans contact qui permettent d'effectuer un paiement (dont le montant est généralement plafonné) en apposant (ou en rapprochant) la carte de paiement d'un terminal de paiement compatible. Il s'agit également des terminaux de communication, qui intègrent également des puces sans contact : ces puces (également appelées contactless chip) et qui offrent des capacités d'échange de données aux terminaux de communication, capacités qui peuvent être utilisées pour effectuer des paiements, un peu comme si le terminal de communication imitait le comportement d'une carte de paiement sans contact. De nombreuses rumeurs, souvent infondées, laissent entendre qu'une communication ou qu'un paiement réalisé sans contact serait peu sûr. Il est également souvent rapporté que les dispositifs seraient peu sécurisés et qu'il serait possible de récupérer les données qui sont contenus dans ces dispositifs à l'insu de l'utilisateur. Bien que ces rumeurs soient souvent sans fondement, il existe cependant des risques lors de la transmission de données entre les dispositifs et notamment lors de la transmission de données de paiement. Les risques, cependant, ne proviennent pas de la technologie employée, en ellemême (NFC), mais généralement de l'utilisateur lui-même. Ainsi par exemple, dans le cas d'un terminal de communication utilisant l'interface NFC pour effectuer un paiement, il est possible que l'utilisateur ait installé une application peu sure, voire une application malveillante, dont l'objectif est d'utiliser des données de paiement à des fins de fraudes. La situation est la même du côté du terminal du commerçant.
Par exemple, dans le cadre d'une communication entre un dispositif d'utilisateur (un terminal de communication de type smartphone) et un terminal de paiement, notamment en utilisant des protocoles NFC pour le paiement, il est nécessaire que le dispositif et le terminal authentifie des données. À cette fin, le dispositif met en œuvre un protocole d'authentification avec le terminal (par exemple un terminal de paiement, une borne d'un marchand, ou tout autre dispositif approprié). Le terminal contrôle que la phase d'authentification a réussi et dans le cas contraire refuse la transaction ou déclenche une alerte, ou met en œuvre tout autre comportement jugé approprié dans une telle situation.
Dans les scénarios typiques, le terminal effectuant ces contrôles est, un dispositif sécurisé (comme un terminal de paiement). Il a été conçu pour prévenir la plupart des types possibles d'intrusion, tant matérielles que logicielles. Mais si le terminal de paiement est un dispositif tiers (terminal de communication de type tablette, smartphone, écran), alors la sécurité de ce terminal de communication (tiers) ne peut pas être garantie, pas plus que l'origine des applications installées sur ce terminal (par le commerçant lui-même). Si le commerçant n'est pas vigilant, il se peut que les applications installées sur ce terminal soient frauduleuses.
On présente ci-après un cas de dysfonctionnement possible, mis en œuvre lors d'un paiement entre un terminal de communication et un dispositif d'utilisateur. On appelle V le vérificateur (par exemple le terminal ou l'appareil du marchand) et P le prouveur (dispositif de l'utilisateur : smartphone, tablette).
Les protocoles de paiement travaillent habituellement de la façon suivante, au cours de la transaction : V demande à P de signer numériquement des données. P signe les données, conformément à ce qui est demandé par V et transmet les données signées à V. Cette signature est vérifiée par V, et si elle est correcte, alors la transaction est acceptée et transférée dans le reste de la chaîne de traitement des paiements. Une telle procédure est appelée un défi-réponse (challenge response) et est utilisée par exemple par les spécifications EMV.
Le problème auquel il est proposé de remédier est le suivant : si V fonctionne sur un dispositif non sécurisé (i.e. un terminal de type tablette, PC ou autre, auquel on a adjoint des fonctionnalités de paiement) qui est infecté par un logiciel malveillant (installé par le commerçant ou par un tiers mal intentionné), alors ce logiciel peut abuser le terminal du client P. Un tel abus peut par exemple prendre la forme d'une succession de transactions (invisibles). Ceci peut être réalisé par exemple lorsque le terminal du commerçant force le dispositif de l'utilisateur à signer des messages arbitraires. Le dispositif de l'utilisateur, en position « d'esclave », est alors obligé de signer ces données. Le logiciel malveillant installé sur le terminal du commerçant se sert ensuite de ces données signées pour créer des transactions frauduleuses.
C'est le paradoxe de ces traitements cryptographiques : il est certain que les traitements réalisés sont bons (car ils mettent en œuvre des traitements cryptographiques), en revanche, l'utilisation qui est faite des résultats de ces traitements cryptographiques ne peut pas être garantie.
3. Résumé
L'invention ne pose pas ces problèmes de l'art antérieur. Plus particulièrement, l'invention apporte une solution simple à la problématique préalablement identifiée. Cette solution est entièrement compatible avec les dispositifs matériels existants.
Plus particulièrement, il est proposé un procédé d'authentification d'au moins une donnée, procédé mis en œuvre lors d'une transaction de paiement intervenant entre un terminal d'un commerçant et un dispositif d'utilisateur, procédé qui comprend la création d'un triplet d'authentification, comprenant un code d'authentification et deux composants de signature, ce triplet étant construit par la dispositif d'utilisateur et n'étant vérifiable que par le terminal du commerçant.
Pour ce faire, il est divulgué un procédé d'authentification d'au moins une donnée, procédé mis en œuvre lors d'une transaction de paiement intervenant entre un terminal de communication d'un commerçant et un dispositif d'utilisateur, procédé du type comprenant l'authentification par le terminal de communication d'au moins un message m générée par le dispositif d'utilisateur, par l'intermédiaire d'une liaison de données sans fils en champs proche, procédé caractérisé en ce qu'il comprend, au sein du dispositif d'utilisateur :
une étape d'obtention, à partir du message m, d'une donnée aléatoire t et d'une fonction de hachage H, d'un code d'authentification ;
une étape d'obtention, à partir du message m, de la donnée aléatoire ζ d'une clé publique Z du terminal de communication, d'une première clé privée x du dispositif d'utilisateur et du code d'authentification S2, d'un premier composant de signature S2 ; une étape d'obtention, à partir du message m, de la donnée aléatoire t, de la clé publique de Z du terminal de communication, d'une deuxième clé privée y du dispositif d'utilisateur et du code d'authentification S2, d'un deuxième composant de signature S3;
une étape de transmission, au terminal de communication, du code d'authentification
S2, et des deux composants de signature S2etS3.
Un tel procédé permet de créer un triplet qui peut être transmis au terminal de communication pour permettre une vérification, en aveugle, de la validité (et de la connaissance) par le dispositif d'utilisateur, du message m.
Selon un autre aspect, il est également divulgué un procédé d'authentification qui comprend, au sein du terminal de communication :
une étape d'obtention, à partir du premier composant de signature S2, d'une clé publique X du dispositif d'utilisateur, d'une clé privée z du terminal de communication, et du code d'authentification S2, d'une première valeur de référence, notée U[rl]; une étape d'obtention, à partir du deuxième composant de signature S3, d'une clé publique Y du dispositif d'utilisateur, de la clé privée z, et du code d'authentification Slt d'une deuxième valeur de référence, notée U[r2] ;
une étape de vérification que la première valeur de référence U[rl] est égale à la deuxième valeur de référence U[r2] ; et, lorsque les deux valeurs sont égales : une étape de vérification que la valeur H(U[r2I) et/ou H(U[rl]) est égale à S2. une étape de délivrance d'une assertion d'authentification lorsque l'étape de vérification précédente est positive.
Ainsi, sans avoir fait référence au message, il est possible de vérifier la validité du triplet reçu.
Selon un mode de réalisation particulier, le procédé comprend, pour ledit dispositif d'utilisateur, préalablement à ladite étape d'obtention d'un code d'authentification, une phase de détermination d'un ensemble de paramètres de chiffrement, comprenant :
une étape d'obtention d'un groupe de Schnor (G) et d'un générateur de ce groupe (g) ; une étape d'obtention de la première clé privée (x), ladite clé privée étant un élément du groupe G ;
une étape d'obtention de la deuxième clé privée (y), ladite clé privée étant un élément du groupe G ;
une étape de calcul, à partir de la première clé privée (x), d'une clé publique X telle que X est une exponentiation du générateur g par la clé privée x, X=gx ; une étape de calcul, à partir de la première clé privée (y), d'une clé publique Y telle que Y est une exponentiation du générateur g par la clé privée y, Y=gy.
Selon un mode de réalisation particulier, le procédé comprend, pour ledit terminal de communication du commerçant, préalablement à ladite étape d'obtention d'une première valeur de référence, une phase de détermination d'un ensemble de paramètres de chiffrement, comprenant :
une étape d'obtention d'un groupe de Schnor (G) et d'un générateur de ce groupe (g) ; une étape d'obtention de la clé privée (z), ladite clé privée étant un élément du groupe G;
une étape de calcul, à partir de la clé privée (z), d'une clé publique Z telle que Z est une exponentiation du générateur g par la clé privée z, Z=gz.
Selon un mode de réalisation particulier :
l'étape d'obtention du code d'authentification S2 met en œuvre le calcul suivant : S2 =
H(m||t), ou | | est l'opérateur de concaténation ;
l'étape d'obtention du premier composant de signature S2 met en œuvre le calcul suivant : S2 = l'étape d'obtention du deuxième composant de signature S3 met en œuvre le calcul suivant : S3 = (ml lt)Zysl.
Selon un mode de réalisation particulier :
l'étape d'obtention de la première valeur de référence U[rl] met en œuvre le calcul suivant : U[rl] = s2Xzsl ;
l'étape d'obtention de la deuxième valeur de référence U[r2] met en œuvre le calcul suivant :U[r2] = s3Yzsl.
Selon un autre aspect, il est également divulgué un dispositif d'utilisateur comprenant une unité de traitement général, une mémoire, dispositif comprenant une unité de traitement sécurisé et une mémoire sécurisée et au moins un circuit reconfigurable de traitement de transaction de paiement avec un terminal de communication comprenant notamment une authentification d'une donnée, ledit dispositif d'utilisateur comprenant :
des moyens d'obtention, à partir du message m, d'une donnée aléatoire t et d'une fonction de hachage H, d'un code d'authentification S2 ;
des moyens d'obtention, à partir du message m, de la donnée aléatoire t, d'une clé publique Z du terminal de communication, d'une première clé privée x du dispositif d'utilisateur et du code d'authentification S2, d'un premier composant de signature S2 ; des moyens d'obtention, à partir du message m, de la donnée aléatoire t, de la clé publique de Z du terminal de communication, d'une deuxième clé privée y du dispositif d'utilisateur et du code d'authentification S2, d'un deuxième composant de signature S3i des moyens de transmission, au terminal de communication, du code d'authentification S2, et des deux composants de signature S2 etS3.
Un tel dispositif d'utilisateur se présente généralement sous la forme d'un terminal de communication de type téléphone intelligent.
Selon un autre aspect, il est également divulgué un terminal de commerçant comprenant une unité de traitement général, une mémoire, terminal caractérisé comprenant une unité de traitement sécurisé et une mémoire sécurisée et au moins un circuit reconfigurable de traitement de transaction de paiement avec un dispositif d'utilisateur comprenant notamment une authentification d'une donnée, ledit terminal de commerçant comprenant :
des moyens d'obtention, à partir du premier composant de signature S2, d'une clé publique X du dispositif d'utilisateur, d'une clé privée z du terminal de communication, et du code d'authentification Slt d'une première valeur de référence, notée U[rl]; des moyens d'obtention, à partir du deuxième composant de signature S3, d'une clé publique Y du dispositif d'utilisateur, de la clé privée z, et du code d'authentification Slt d'une deuxième valeur de référence, notée U[r2] ;
des moyens de vérification que la première valeur de référence U[rl] est égale à la deuxième valeur de référence U[r2] ; et, lorsque les deux valeurs sont égales : des moyens de vérification que la valeur H(U[r2]) et/ou H(U[rl]) est égale à des moyens de délivrance d'une assertion d'authentification lorsque l'étape de vérification précédente est positive.
Un tel terminal de commerçant peut se présenter sous la forme d'un terminal de type smartphone ou tablette. Un tel terminal peut également se présenter sous la forme d'un terminal de paiement auquel on adjoint les moyens précédemment décrits.
Selon une implémentation préférée, les différentes étapes des procédés selon l'invention sont mises en œuvre par un ou plusieurs logiciels ou programmes d'ordinateur, comprenant des instructions logicielles destinées à être exécutées par un processeur de données d'un module relais selon l'invention et étant conçu pour commander l'exécution des différentes étapes des procédés.
En conséquence, l'invention vise aussi un programme, susceptible d'être exécuté par un ordinateur ou par un processeur de données, ce programme comportant des instructions pour commander l'exécution des étapes d'un procédé tel que mentionné ci-dessus.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations lisible par un processeur de données, et comportant des instructions d'un programme tel que mentionné ci-dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Selon un mode de réalisation, l'invention est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme module peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.
Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.).
De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (firmware), etc.
Chaque composante du système précédemment décrit met bien entendu en œuvre ses propres modules logiciels.
Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en œuvre de l'invention.
4. Dessins
D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :
la figure 1 présente un synoptique de la technique proposée pour la création d'éléments de signature à destination du terminal du commerçant ; la figure 2 présente un synoptique de la technique proposée pour la vérification d'éléments de signature reçus d'un dispositif d'utilisateur ;
la figure 3 représente schématiquement un terminal de communication du commerçant selon la présente ;
la figure 4 décrit représente schématiquement un dispositif d'utilisateur selon la présente.
5. Description
5.1. Principe général
Comme explicité précédemment, le principe général de l'invention consiste notamment à intégrer, en plus d'un schéma de défi-réponse (ou à la place de ce schéma), une ou plusieurs opérations additionnelles. La présente invention propose une modification protocolaire qui permet de résister aux attaques des terminaux comprenant des logiciels malveillants. À titre secondaire, cette modification protocolaire permet également de protéger les terminaux des commerçants eux-mêmes contre des réponses non sollicités provenant d'autres appareils (c'est à dire des appareils malveillants qui tenteraient d'attaquer un terminal de commerçant authentique). Cette modification protocolaire offrant ainsi une couche supplémentaire de protection contre d'autres types d'attaques (DoS Déniai of Serverce, Concurency Attacks - attaques par concurrence d'accès aux ressources-).
Classiquement, lorsqu'une transaction de paiement est effectuée entre un terminal d'un commerçant et un dispositif d'utilisateur, un processus de type challenge/response (défi/réponse en français) est mis en œuvre afin que le terminal du commerçant identifie ίο (authentifie) le dispositif d'utilisateur (et vice versa) par l'intermédiaire de l'échange d'un message m. La présente technique permet de se passer d'un schéma de ce type. Il n'est ainsi plus nécessaire de réaliser un processus de type « défi réponse ». La technique mise en œuvre n'est donc pas une technique de type « défi-réponse » (qui est un processus interactif) ; il ne s'agit pas non plus d'une nouvelle signature (qui est vérifiable publiquement) ; il ne s'agit pas non plus d'un code d'authentification de message (qui n'est possible qu'en cas de partage d'une clé secrète).
Plus particulièrement, l'approche retenue par la présente technique est de faire en sorte que le dispositif de l'utilisateur puisse prouver qu'il a légitimement signé le message « m » (les données) à authentifier, sans pour autant avoir à transmettre ce message (le message peut par exemple être connu de part et d'autre : par le terminal du commerçant et par le dispositif d'utilisateur. Ainsi, au lieu de signer de manière traditionnelle le message et de le transmettre (c'est-à-dire de transmettre le message signé), on adopte une stratégie de transmission de preuve de signature de ce message (qui peut être complémentaire soit à la transmission de ce message, soit au partage de la connaissance du message entre le terminal du commerçant et le dispositif d'utilisateur).
On suppose que le terminal du commerçant n'est pas sécurisé en tant que tel (il s'agit d'un téléphone, d'une tablette ou d'un PC), mais qu'il dispose de ressources de sécurisation. Ces ressources de sécurisation peuvent par exemple prendre la forme d'un secure element SE (élément sécurisé en français), d'un Trusted Execution Environment - TEE (environnement d'exécution sécurisé en français) ou encore d'un autre composant matériel ou logiciel dédié. On suppose, pour les explications qui vont suivre, que l'application de paiement du terminal du commerçant s'appelle TPC, et qu'elle comprend un module de vérification (d'identification) appelé V (il s'agit par exemple d'un SE, d'un TEE ou plus généralement d'une unité de traitement sécurisée, qui peut même être distante, c'est-à-dire non présente dans le terminal). On suppose également qu'il existe une application de paiement sur le dispositif d'utilisateur DU, et que le dispositif de l'utilisateur (DU) comprend un module de preuve (de confirmation d'identité) appelé P (il s'agit par exemple d'un SE, d'un TEE ou plus généralement d'une unité de traitement sécurisée). Dans un autre mode de réalisation, le dispositif d'utilisateur peut être une carte de paiement classique, dans laquelle on a effectué des modifications protocolaires et matérielles permettant de mettre en œuvre la présente technique.
D'une manière générale, la présente technique combine les principes de signatures de Schnorr et d'échange de clés Diffie-Hellman (pour l'hypothèse d'absence de solution calculatoire). Toutefois, à la différence des signatures de Schnorr (qui comprend un couple de données), la technique mise en œuvre utilise une signature comprenant un triplet de données.
L'utilisation d'un tel triplet, en lieu et place d'un couple (tel que défini dans la signature de Schnorr) permet de de créer (de manière sécurisée) une restriction supplémentaire : seul un destinataire particulier peut vérifier la signature (à la différence des signatures de Schnorr qui sont publiquement vérifiables).
Par ailleurs, à la différence du procédé classique de Schnorr, la technique repose sur l'utilisation d'un couple de clé privées et d'un couple de clé publiques, qui est mis à la disposition du dispositif d'utilisateur (et/ou du module de preuve).
On décrit, en relation avec les figures 1 et 2, la technique proposée authentifiant des données entre un terminal de communication d'un commerçant et un dispositif d'utilisateur.
Comme explicité précédemment, on suppose que V et P ont chacun, par leurs propres moyens, obtenus la connaissance des données à authentifier (le message m). Lors de la mise en œuvre conjointe des applications de paiement TPC et DU, le procédé mis en œuvre est le globalement le suivant :
le module P calcule (10), à partir du message m, d'une donnée aléatoire t et d'une fonction de hachage H, un code d'authentification ;
le module P calcule (20), à partir du message m, de la donnée aléatoire t, d'une clé publique Z de V, d'une première clé privée x de P et du code d'authentification S2, un premier composant de signature S2 ;
le module P calcule (30), à partir du message m, de la donnée aléatoire t, de la clé publique de V, d'une deuxième clé privée de P et du code d'authentification S2, un deuxième composant de signature S3 ;
le module P transmet (40), au terminal du commerçant (ou au module V), le code d'authentification S2, et les deux composants de signature S2 et S3.
Ces étapes, effectuées sur le dispositif d'utilisateur (ou le module P) sont mises en œuvre sur la base d'une part de clés privées (deux) à disposition du dispositif d'utilisateur et d'une clé publique du terminal du commerçant. Dans cet exemple, on suppose que m est connu de part et d'autre avant, et c'est juste l'aléa t qui est transmis, avec (S^ S& S3) qui « signe » le message.
La clé publique du terminal du commerçant est soit transmise par le terminal du commerçant à l'initialisation de la transaction de paiement, soit obtenue, par exemple à partir d'une base de données, accessible depuis le dispositif d'utilisateur. La donnée aléatoire t est, quant à elle, unilatéralement choisie par le dispositif d'utilisateur. Il va de soi que cette clé publique devrait, selon les bonnes pratiques, être certifiée par une autorité reconnue. Toutefois cela n'est pas nécessaire au fonctionnement de l'invention, et n'est même pas utile dans certaines applications. La clé publique utilisée pour le destinataire de la signature n'est pas nécessairement la clé publique du terminal commerçant. Ce pourrait être par exemple celle du processeur de paiement (le module V), le terminal ne faisant que relayer l'information.
À partir des données reçues (Slt S2 et S3 ), le terminal du commerçant (ou le module V, ou un destinataire distant), va vérifier (en réalisant un calcul sur ces données) qu'elles sont bien synonymes de la connaissance (par le dispositif d'utilisateur ou par P) du message m.
Pour ce faire, le terminal du commerçant (ou le module V) :
calcule (50), à partir du premier composant de signature S2, de la clé publique X (correspondant à la clé privée x), de sa propre clé privée z, et du code d'authentification S2, une première valeur de référence, notée U[rl] calcule (60), à partir du deuxième composant de signature S3, de la clé publique Y (correspondant à la clé privée y), de sa propre clé privée z, et du code d'authentification S2, une deuxième valeur de référence, notée U[r2];
vérifie (70) que la première valeur de référence U[rl] est égale à la deuxième valeur de référence U[r2] ; et, lorsque les deux valeurs sont égales :
vérifie (80) que la valeur H(U[r2]) est égale à
Lorsque l'étape de vérification (80) est positive, le procédé délivre une assertion d'authentification. En fonction du résultat de cette vérification le procédé une étape de transmission (90), par le terminal de communication, d'une donnée de validation de transaction à un système de traitement de transaction de paiement (STTP).
Ainsi, lorsque les deux vérifications précédentes sont vraies, on en déduit que le dispositif d'utilisateur (ou le module P) connaît le message m. Pour mettre en œuvre le procédé tel que décrit précédemment, dans le cadre d'une opération de paiement intervenant entre le dispositif d'utilisateur et le terminal du commerçant, selon la présente, il n'est nécessaire de ne disposer (en commun) que deux éléments :
la fonction de hachage H : cette fonction de hachage est utilisée par le module P pour calculer le premier code d'authentification Si et par le module V pour vérifier que le hachage de U[r2] est égal au premier code d'authentification S2 ; Le module V et le module P partage donc la connaissance de cette fonction de Hachage ;
des paires de {clés publiques ; clés privées} qui sont utilisées pour créer les éléments de signatures ;
le message m : le message m est déterminé par le terminal du commerçant et par le dispositif d'utilisateur ;
À l'aide de la technique proposé, il n'est pas nécessaire que le dispositif d'utilisateur transmette la valeur de ce message m au terminal du commerçant : il suffit qu'il transmette la preuve qu'il en a connaissance. Comme le message m ne transite pas par le réseau, il ne peut pas être intercepté et modifié. II n'est donc pas possible de modifier les composantes de la transaction de paiement.
Par ailleurs, à l'aide de cette technique, seul le terminal du commerçant (ou le module V) est en mesure de vérifier la validité des données transmises par le dispositif d'utilisateur (ou le module P). De plus, il n'est même pas nécessaire que le terminal du commerçant (ou le module V), dispose du message m. En effet, dans la technique proposée, le message m n'est pas utilisé par le commerçant : seul le code d'authentification Si est utilisé. Dès lors, le code d'authentification Si peut être utilisé comme preuve de la validité de la transaction de paiement, sans qu'il soit nécessaire, pour le terminal du commerçant, d'avoir connaissance de ce message. Ainsi, le code d'authentification de message Si peut, en fonction de mode de réalisation, prendre la place des codes d'authentification traditionnellement utilisés dans les protocoles de paiement, et plus particulièrement dans les protocoles de paiement mis en œuvre dans la cadre des spécifications EMV. On comprend, à lecture de ce qui précède, que les procédés mis en œuvre tant dans le terminal du commerçant que dans le dispositif d'utilisateur, sont indépendants. On comprend également que le terminal du commerçant et le dispositif d'utilisateur sont indépendant l'un de l'autre. Dès lors, il est possible de mettre en œuvre les procédés et dispositifs décrits dans un système qui comprendra un dispositif d'utilisateur et un terminal de commerçant effectuant une transaction de paiement.
5.2. Mode de réalisation
Dans ce mode de réalisation purement illustratif, la technique proposée consiste, notamment en une modification des signatures de Schnorr, adaptée pour deux utilisateurs (terminal du commerçant et dispositif d'utilisateur). La sécurité de la technique proposée est notamment basée sur l'hypothèse Décisionnelle Diffie-Hellman (DDH) qui est une hypothèse de dureté de calcul basée sur des groupes cycliques (« Decisional Diffie-Hellman assumption » en anglais).
Dans ce mode de réalisation, préalablement à la mise en œuvre du protocole d'échange sécurisé, on suppose que deux phases d'installation ont été réalisées : une du côté du terminal du commerçant et une du côté du dispositif de l'utilisateur.
En premier lieu, la technique proposée est mise en œuvre en se basant sur un groupe G convenant à la problématique des signatures de Schnorr, avec un générateur g.
Un groupe de Schnorr est un sous-groupe de Z* le groupe multiplicatif des entiers modulos p pour un nombre premier p. Pour générer un tel groupe, on génère p, q, et r tels que p=qr+l, avec p et q étant des nombres premiers. Pour obtenir le générateur g de ce groupe, on applique la méthode suivante :
pour chaque entier h strictement supérieur à 1 et strictement inférieur à p :
si hr = 1 (mod p) alors passer à l'entier suivant ;
sinon, la valeur g = hr (mod p) est un générateur sous-groupe de Z* d'ordre q;
Ce groupe possède une ainsi une taille donnée. La taille de ce groupe et ses autres paramètres sont typiquement déterminés préalablement. Dans un mode de réalisation particulier, la taille du groupe G est de l'ordre de 21024 (nombre 2 élevé à la puissance 1024) : cela signifie que la taille du nombre premier p est de l'ordre de 21024.
Dans ce mode de réalisation, le groupe G et le générateur g correspondant ont fait l'objet d'un paramétrage préalable, tant dans le dispositif du client que dans le terminal du commerçant. Ce paramétrage préalable peut avoir été fait par exemple avant l'installation de l'application de paiement du côté du commerçant ou de l'application de paiement du côté du
Dans d'autres modes de réalisation, ce paramétrage est réalisé lors de la transaction de paiement. Le terminal du commerçant et le dispositif d'utilisateur s'entendent sur les paramètres du groupe. Dans ce cas, compte tenu du fait que le groupe est renégocié à chaque transaction la taille de ce groupe peut être réduite, par exemple de moitié (2512) ou plus (2 255).
5.2.1. Phase d'installation du côté du dispositif de l'utilisateur
Le dispositif de l'utilisateur, qui est par exemple un terminal de communication de type smartphone, une tablette, est également équipé d'un SE ou d'un TEE (agissant comme une unité de traitement sécurisé). On rappelle que dans ce mode de réalisation, le client souhaite régler avec son dispositif. Ce dispositif dispose donc des données nécessaires à la réalisation d'un paiement. Il peut s'agir, dans un mode de réalisation spécifique, de données de carte bancaire (nom du porteur, numéro de Carte PAN, date de validité, code de vérification). Il peut également d'agir d'autres données, en fonction des modes de réalisation.
Dans le cadre de la présente technique, la phase d'installation consiste ainsi notamment à déposer, dans le SE ou le TEE du dispositif de l'utilisateur (appelé également module P), les clés privées x et y utilisée pour construire les éléments de signatures.
Cette installation peut typiquement être mise en œuvre par l'installation d'une application de paiement, comme cela est le cas de l'application de paiement installée sur le terminal du commerçant.
Sur la base de ce groupe G et du générateur sélectionné g :
le dispositif d'utilisateur (ou le module de preuve P) obtient ou génère une clé privée comprenant deux nombres entiers premiers (x,y) et, sur la base de cette clé privée, calcule une clé publique (X,Y), dans laquelle :
x = gx;
Y = gv;
Ainsi, dans ce mode de réalisation, les deux nombres entiers premiers (x,y) constituent chacun une clé privée du dispositif d'utilisateur tandis que les deux nombres entiers X et Y constituent chacun la clé publique correspondant à ces deux clés privées.
Dans ce mode de réalisation, les deux paires de clés privées/clé publiques ont fait l'objet d'un paramétrage préalable dans le dispositif du client. Ce paramétrage préalable peut avoir été fait par exemple avant l'installation de l'application de paiement du côté du dispositif d'utilisateur.
Dans d'autres modes de réalisation, la sélection de ces clés est réalisée lors de la transaction de paiement. Avant d'initier la transaction de paiement, le dispositif d'utilisateur effectue le choix de ses couples {clés privées/clés publiques}, sur la base du groupe G et du générateur g. Lorsque l'ensemble des paramètres est négocié au moment de la transaction (Groupe G, générateur g, clés publiques et privées) les tailles de ces paramètres peuvent avantageusement être réduites, du fait de la relative unicité des paramètres en eux-mêmes : ils ne sont en effet utilisés que pour une transaction, ce qui limite de manière importante les possibilités de fraude de la part d'un attaquant.
Une possibilité avantageuse est d'installer ces clés (et paramètres de groupes) en même temps qu'une application bancaire : par exemple l'application bancaire du client. En effet, avec le développement des applications bancaires (application qui permettent de gérer ses comptes depuis un smartphone o une tablette), une solution intéressante, tant pour le client que pour la banque, peut consister à disposer d'une application bancaire qui permette également de réaliser des paiements. Dans ce cas, les données nécessaires au paiement ne sont pas nécessairement des données de carte bancaire, mais peuvent être des données spécifiquement préparées par l'application bancaire de la banque, voire spécifiquement préparée, au moment du paiement, par l'établissement financier lui-même (c'est à dire par un serveur auquel l'application bancaire du client est connectée).
Pour effectuer un paiement, dans ce cas particulier, le client ouvre son application bancaire; sélectionne le fait qu'il souhaite effectuer un paiement; saisit un éventuel code confidentiel (ou s'authentifie par exemple par voie biométrique); et appose son dispositif sur le terminal du commerçant. L'application bancaire réagit aux requêtes du terminal du commerçant (comme explicité dans la présente) et le paiement est effectué. Pour la banque, comme pour le client, les bénéfices sont réels, tant en termes de sécurité de la transaction (faite par l'application bancaire), qu'en termes de fidélisation du client (qui n'est plus obligé d'effectuer un paiement avec une application tierce, dont il n'a pas de garantie, par exemple au niveau de la sécurité et de la confidentialité des données transmises et traitées).
Pour la mise en œuvre de cette technique, il importe que le terminal du commerçant ait connaissance des clés publiques X et Y : soit le dispositif d'utilisateur fournit ces clés lors de la transaction, soit le terminal du commerçant est à même d'obtenir ces clés auprès d'un tiers de confiance. Dans ce dernier cas, selon la présente, le dispositif d'utilisateur dispose d'un identifiant unique (Uid), lequel est associé, auprès du tiers de confiance, au deux clés publiques X et Y. Lorsque le terminal du commerçant souhaite obtenir ces clés publiques, il transmet, au tiers de confiance, une requête d'obtention des clés en se basant sur l'identifiant (Uid) du dispositif d'utilisateur. Préalablement à cette transmission, le dispositif d'utilisateur a transmis son identifiant unique au terminal du commerçant (par exemple lors de l'initialisation de la transaction).
5.2.2. Phase d'installation du côté du terminal du commerçant
Sur la base de ce groupe G et du générateur sélectionné g :
le terminal du commerçant (ou le module de vérification V) obtient ou génère une clé privée z, (nombre premier entier aléatoire) et sur la base de cette clé privée, calcule une clé publique Z, telle que : Z = gz ;
Dans ce mode de réalisation, la paire de clé privée/clé publique a fait l'objet d'un paramétrage préalable dans le terminal du commerçant. Ce paramétrage préalable peut avoir été fait par exemple avant l'installation de l'application de paiement du côté du terminal du commerçant.
Comme précédemment, dans d'autres modes de réalisation, la sélection de ces clés peut être réalisée lors de la transaction de paiement.
De même, comme précédemment, le dispositif d'utilisateur prend connaissance de la clé publique Z du terminal du commerçant. Soit le terminal du commerçant transmet cette clé directement au dispositif du client, soit le dispositif du client utilise un identifiant unique du terminal du commerçant (Cid) pour obtenir cette clé publique auprès d'un tiers de confiance.
Dans un mode de réalisation spécifique, la phase d'installation est réalisée lors de l'installation d'une application de paiement sur un terminal de communication (de type smartphone, tablette, ou ordinateur) du commerçant, ledit terminal de communication étant équipé d'un TEE et/ou d'un SE (également appelé module V). Ce mode de réalisation présente l'avantage de ne pas avoir à communiquer la clé privée z au terminal de communication en tant que tel : cette donnée n'est communiquée qu'au SE ou au TEE. Ainsi, on assure que le terminal de communication (et surtout les éventuelles applications frauduleuse de ce terminal), ne puisse pas avoir accès à cette clé privée.
5.2.3. Déroulé de l'authentification
Dans ce mode de réalisation, l'authentification est mise en œuvre de la manière suivante :
le module P effectue une transformation du message m, sous une forme numérique, afin que ce message m corresponde à un élément du groupe G : pour ce faire, le message m est transformé en binaire (représentation binaire du message m) et la forme binaire est utilisée pour obtenir une forme numérique, la forme numérique correspondant à un élément du groupe G ; d'autres méthodes peuvent être envisageables en fonctions des applications ;
le module P sélectionne aléatoirement (ou pseudo aléatoirement) un élément t du groupe G ;
le module P calcule, à partir du message m, de la donnée aléatoire t et de la fonction de hachage H, un code d'authentification selon la formule suivante : o Sj = H(m||t), ou | | est l'opérateur de concaténation ;
le module P calcule, à partir du message m, de la donnée aléatoire ζ de la clé publique
Z, de la première clé privée x de P et du code d'authentification S2, le premier composant de signature S2, selon la formule suivante : o S2 le module P calcule, à partir du message m, de la donnée aléatoire ζ de la clé publique
Z, de la deuxième clé privée y de P et du code d'authentification S2, le deuxième composant de signature S3 ; o S3 = (mllt)Zysl le module P transmet, au terminal du commerçant (ou au module Vj, le code d'authentification S2, et les deux composants de signature S2 et S3.
Ainsi, le dispositif d'utilisateur n'a pas transmis le message m, ni même une version signée de celui-ci car ce dernier se trouve être concaténé avec un aléa (t), avant d'être haché pour produire S2. Dès lors, un attaquant, qui intercepterait par exemple le code d'authentification S2, ne pourrait pas, à partir de celui-ci, inférer le contenu du message m.
Les méthodes de calcul des valeurs S2, S2 et S3 utilisent x et y (qui sont privées et donc connues du signataire seul, c'est-à-dire le dispositif d'utilisateur), et de Z (qui est la clé publique du destinataire, c'est-à-dire le terminal de paiement). Essentiellement, S2 et S3 sont des quantités créées à partir de ces trois informations et du message m. L'exponentiation garantit la protection des clés privées, et la multiplication du message par la quantité exponentiée protège son contenu.
De son côté, le terminal du commerçant reçoit les données S2, S2 et S3. Sur la base de ces données, il va déterminer (avec un doute raisonnable), que ces données correspondent bien aux résultats de calculs effectués sur la base du message m.
Pour ce faire, le terminal du commerçant met en œuvre les étapes suivantes : calcule, à partir du premier composant de signature S2, de la clé publique X (correspondant à la clé privée x), de sa propre clé privée Z, et du code d'authentification S2, une première valeur de référence, notée U[rl] o U[rlj = s2Xzsl calcule, à partir du deuxième composant de signature S3, de la clé publique Y (correspondant à la clé privée y), de sa propre clé privée Z, et du code d'authentification S2, une deuxième valeur de référence, notée U[r2]; o U[r2] = s3Yzsl vérifie que la première valeur de référence U[rl] est égale à la deuxième valeur de référence U[r2] ; et, lorsque les deux valeurs sont égales : vérifie que la valeur H(U[r2]) est égale à S2.
Si la valeur de H(U[r2]) est égale à S2, alors le terminal du commerçant dispose d'une information d'une certitude suffisante pour estimer que le dispositif d'utilisateur est bien en possession du message m et que celui-ci est authentique. Dès lors, le terminal du commerçant peut terminer la transaction (par exemple il peut transmettre S2 au système de paiement pour validation de la transaction).
Explicité autrement, Le terminal du commerçant effectue les calculs suivants : o U[rl] = s2Xzsl = (m | | t)ZA(x SI) XA(-z SI) = (m| |t)gA(z x SI) gA(-z x SI) = (m| |t) et
U[r2] = s3Y zsl = (m | | t)ZA(y SI) YA(-z SI) = [m| | t)gA(yz SI) gA(-yz SI) = (m| |t)
Ainsi, l'authentification des données transmises, lors d'une opération de paiement, entre un terminal d'un commerçant et un dispositif d'utilisateur, en utilisant une communication en champs proche (NFC), permet de valider une transaction de manière sécuritaire.
5.3. Autres caractéristiques et avantages
On décrit, en relation avec la figure 3, un terminal de communication mis en œuvre pour réaliser une authentification de données dans le cadre d'un processus de paiement, selon le procédé décrit préalablement.
Par exemple, le terminal de communication, faisant office de terminal de paiement, comprend une mémoire 31 comprenant notamment une mémoire tampon, une unité de traitement général 32, équipée par exemple d'un microprocesseur, et pilotée par un programme d'ordinateur 33, et une unité de traitement sécurisée 34 (notée V précédemment), pilotée par un programme d'ordinateur 35, ces unités de traitement mettant en œuvre le procédé d'authentification tels que décrit précédemment pour effectuer un paiement auprès du commerçant.
À l'initialisation, les instructions de code du programme d'ordinateur 35 sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur de l'unité de traitement sécurisée 34. L'unité de traitement 34 reçoit en entrée au moins un code d'authentification et deux éléments de signature. Le microprocesseur de l'unité de traitement sécurisée 34 met en œuvre les étapes du procédé d'authentification, selon les instructions du programme d'ordinateur 35 pour fournir, à l'unité de traitement générale 32, une donnée représentative de validation de transaction et le cas échéant transmettre, à un système de traitement, une donnée de validation de transaction. L'unité de traitement générale 32 effectue un traitement de ces données pour les transmettre à un dispositif d'un client (par exemple un smartphone, une tablette) dans le cadre d'une transaction de paiement.
Pour cela, le terminal de communication comprend, outre la mémoire tampon 31, des moyens de communications, tels que des modules de communication réseau, des moyens de transmission de donnée et des circuits de transmission de données entre les divers composants du terminal de communication.
Ces moyens peuvent se présenter sous la forme d'un processeur particulier implémenté au sein du terminal de communication. Selon un mode de réalisation particulier, ce dispositif met en œuvre une application spécifique qui est en charge de la réalisation des transactions, cette application étant par exemple fournie par le fabricant du processeur en question afin de permettre l'utilisation dudit processeur ou par un fournisseur de solution de paiement pour des terminaux ouverts. Pour ce faire, le processeur comprend des moyens d'identification uniques. Ces moyens d'identification uniques permettent d'assurer l'authenticité du processeur.
Par ailleurs, le dispositif comprend en outre les moyens de communication en champs proches, dits NFC et des moyens de transmission et de réception de données en provenance de réseaux de communications. Ces moyens se présentent également comme des interfaces de communications permettant d'échanger des données sur des réseaux de communication, des moyens d'interrogations et de mise à jour de base de données.
On décrit, en relation avec la figure 4, un dispositif d'utilisateur mis en œuvre pour réaliser une authentification de données dans le cadre d'un processus de paiement, selon le procédé décrit préalablement.
Par exemple, le dispositif d'utilisateur comprend une mémoire 41 constituée d'une mémoire tampon, une unité de traitement général 42, équipée par exemple d'un microprocesseur, et pilotée par un programme d'ordinateur 43, et une unité de traitement sécurisée 44 (notée P, précédemment), pilotée par un programme d'ordinateur 45, ces unités de traitement mettant en œuvre le procédé d'authentification tels que décrit précédemment pour effectuer un paiement auprès du commerçant.
À l'initialisation, les instructions de code du programme d'ordinateur 45 sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur de l'unité de traitement sécurisée 44. L'unité de traitement sécurisée 44 reçoit en entrée, un message m dont il est nécessaire de prouver la connaissance. Le microprocesseur de l'unité de traitement sécurisée 44 met en œuvre les étapes du procédé d'authentification, selon les instructions du programme d'ordinateur 45 pour fournir, à l'unité de traitement générale 42, au moins un code d'authentification et deux éléments de signature à transmettre à un terminal de commerçant. L'unité de traitement générale 42 effectue la transmission de ces données.
Pour cela, le dispositif d'utilisateur comprend, outre la mémoire tampon 41, des moyens de communications, tels que des modules de communication réseau, des moyens de transmission de donnée et des circuits de transmission de données entre les divers composants du dispositif d'utilisateur.
Ces moyens peuvent se présenter sous la forme d'un processeur particulier implémenté au sein du dispositif d'utilisateur. Selon un mode de réalisation particulier, ce dispositif met en œuvre une application spécifique qui est en charge de la réalisation des transactions, cette application étant par exemple fournie par le fabricant du processeur en question afin de permettre l'utilisation dudit processeur ou par un fournisseur de solution de paiement pour des terminaux ouverts. Pour ce faire, le processeur comprend des moyens d'identification uniques. Ces moyens d'identification uniques permettent d'assurer l'authenticité du processeur.
Par ailleurs, le dispositif comprend en outre les moyens de communication en champs proches, dits NFC et des moyens de transmission et de réception de données en provenance de réseaux de communications. Ces moyens se présentent également comme des interfaces de communications permettant d'échanger des données sur des réseaux de communication, des moyens d'interrogations et de mise à jour de base de données.

Claims (1)

  1. Revendications
    Procédé d'authentification d'au moins une donnée, procédé mis en œuvre lors d'une transaction de paiement intervenant entre un terminal de communication d'un commerçant et un dispositif d'utilisateur, procédé du type comprenant l'authentification par le terminal de communication d'au moins un message m générée par le dispositif d'utilisateur, par l'intermédiaire d'une liaison de données sans fils en champs proche, procédé caractérisé en ce qu'il comprend, au sein du dispositif d'utilisateur :
    une étape d'obtention (10), à partir du message m, d'une donnée aléatoire tet d'une fonction de hachage H, d'un code d'authentification ;
    une étape d'obtention (20), à partir du message m, de la donnée aléatoire t, d'une clé publique Z du terminal de communication, d'une première clé privée x du dispositif d'utilisateur et du code d'authentification S2, d'un premier composant de signature S2 ; une étape d'obtention (30), à partir du message m, de la donnée aléatoire t, de la clé publique de Z du terminal de communication, d'une deuxième clé privée y du dispositif d'utilisateur et du code d'authentification S2, d'un deuxième composant de signature S3i une étape de transmission (40), au terminal de communication, du code d'authentification S2, et des deux composants de signature S2 etS3.
    Procédé d'authentification selon la revendication 1, caractérisé en ce qu'il comprend, au sein du terminal de communication :
    une étape d'obtention (50), à partir du premier composant de signature S2, d'une clé publique X du dispositif d'utilisateur, d'une clé privée z du terminal de communication, et du code d'authentification S2, d'une première valeur de référence, notée U[rl]; une étape d'obtention (60), à partir du deuxième composant de signature S3, d'une clé publique Y du dispositif d'utilisateur, de la clé privée z, et du code d'authentification S2, d'une deuxième valeur de référence, notée U[r2] ;
    une étape de vérification (70) que la première valeur de référence U[rl] est égale à la deuxième valeur de référence U[r2] ; et, lorsque les deux valeurs sont égales :
    une étape de vérification (80) que la valeur H(U[r2]) et/ou H(U[rl]) est égale à S2. une étape de délivrance d'une assertion d'authentification lorsque l'étape de vérification précédente est positive.
    Procédé d'authentification selon la revendication 1, caractérisé en ce qu'il comprend, pour ledit dispositif d'utilisateur, préalablement à ladite étape d'obtention (10) d'un code d'authentification, une phase de détermination d'un ensemble de paramètres de chiffrement, comprenant :
    une étape d'obtention d'un groupe de Schnor (G) et d'un générateur de ce groupe (g) ; une étape d'obtention de la première clé privée (x), ladite clé privée étant un élément du groupe G ;
    une étape d'obtention de la deuxième clé privée (y), ladite clé privée étant un élément du groupe G ;
    une étape de calcul, à partir de la première clé privée (x), d'une clé publique X telle que X est une exponentiation du générateur g par la clé privée x, X=gx ; une étape de calcul, à partir de la première clé privée (y), d'une clé publique Y telle que Y est une exponentiation du générateur g par la clé privée y, Y=gy.
    Procédé d'authentification selon la revendication 2, caractérisé en ce qu'il comprend, pour ledit terminal de communication du commerçant, préalablement à ladite étape d'obtention (50) d'une première valeur de référence, une phase de détermination d'un ensemble de paramètres de chiffrement, comprenant :
    une étape d'obtention d'un groupe de Schnor (G) et d'un générateur de ce groupe (g) ; une étape d'obtention de la clé privée (z), ladite clé privée étant un élément du groupe G;
    une étape de calcul, à partir de la clé privée (z), d'une clé publique Z telle que Z est une exponentiation du générateur g par la clé privée z, Z=gz.
    Procédé d'authentification selon la revendication 3, caractérisé en ce que :
    l'étape d'obtention (10) du code d'authentification S2 met en œuvre le calcul suivant :
    S, = H(m||t), ou | | est l'opérateur de concaténation ;
    l'étape d'obtention (20) du premier composant de signature S2 met en œuvre le calcul suivant : S2 = l'étape d'obtention (30) du deuxième composant de signature S3 met en œuvre le calcul suivant : S3
    Procédé d'authentification selon la revendication 4, caractérisé en ce que :
    l'étape d'obtention (50) de la première valeur de référence U[rl] met en œuvre le calcul suivant : U[rl] = s2Xzsl ;
    l'étape d'obtention (60) de la deuxième valeur de référence U[r2] met en œuvre le calcul suivant :U[r2] = s3Yzsl.
    Dispositif d'utilisateur comprenant une unité de traitement générale, une mémoire, dispositif caractérisé en ce qu'il comprend une unité de traitement sécurisée et une mémoire sécurisée et au moins un circuit reconfigurable de traitement de transaction de paiement avec un terminal de communication comprenant notamment une authentification d'une donnée, ledit Dispositif d'utilisateur comprenant :
    des moyens d'obtention, à partir du message m, d'une donnée aléatoire t et d'une fonction de hachage H, d'un code d'authentification S2 ;
    des moyens d'obtention, à partir du message m, de la donnée aléatoire t, d'une clé publique Z du terminal de communication, d'une première clé privée x du dispositif d'utilisateur et du code d'authentification S2, d'un premier composant de signature S2 ; des moyens d'obtention, à partir du message m, de la donnée aléatoire t, de la clé publique de Z du terminal de communication, d'une deuxième clé privée y du dispositif d'utilisateur et du code d'authentification S2, d'un deuxième composant de signature S3i des moyens de transmission, au terminal de communication, du code d'authentification S2, et des deux composants de signature S2 etS3.
    Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution d'un procédé d'authentification selon la revendication 1, lorsqu'il est exécuté sur un ordinateur.
    1/2
FR1656240A 2016-06-30 2016-06-30 Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants. Active FR3053549B1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
FR1656240A FR3053549B1 (fr) 2016-06-30 2016-06-30 Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants.
US16/314,174 US10922679B2 (en) 2016-06-30 2017-06-30 Method for authenticating payment data, corresponding devices and programs
CA3029154A CA3029154A1 (fr) 2016-06-30 2017-06-30 Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants
EP17733483.6A EP3479518A1 (fr) 2016-06-30 2017-06-30 Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants
PCT/EP2017/066365 WO2018002351A1 (fr) 2016-06-30 2017-06-30 Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1656240 2016-06-30
FR1656240A FR3053549B1 (fr) 2016-06-30 2016-06-30 Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants.

Publications (2)

Publication Number Publication Date
FR3053549A1 true FR3053549A1 (fr) 2018-01-05
FR3053549B1 FR3053549B1 (fr) 2018-07-27

Family

ID=57583156

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1656240A Active FR3053549B1 (fr) 2016-06-30 2016-06-30 Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants.

Country Status (5)

Country Link
US (1) US10922679B2 (fr)
EP (1) EP3479518A1 (fr)
CA (1) CA3029154A1 (fr)
FR (1) FR3053549B1 (fr)
WO (1) WO2018002351A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109347635A (zh) * 2018-11-14 2019-02-15 中云信安（深圳）科技有限公司 一种基于国密算法的物联网安全认证系统及认证方法
CN111639187B (zh) * 2019-03-01 2023-05-16 上海数眼科技发展有限公司 一种基于知识图谱的知识问答验证码生成系统及方法
US20230065643A1 (en) * 2021-09-01 2023-03-02 Capital One Services, Llc Devices and techniques to perform entropy-based randomness via a contactless card

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8700729B2 (en) * 2005-01-21 2014-04-15 Robin Dua Method and apparatus for managing credentials through a wireless network
US8290433B2 (en) * 2007-11-14 2012-10-16 Blaze Mobile, Inc. Method and system for securing transactions made through a mobile communication device
US20140032345A1 (en) * 2012-07-30 2014-01-30 Bank Of America Corporation Authentication Using Transaction Codes on a Mobile Device
FR3030828A1 (fr) * 2014-12-22 2016-06-24 Orange Procede de securisation de transactions sans contact

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
NYBERG K ET AL: "MESSAGE RECOVERY FOR SIGNATURE SCHEMES BASED ON THE DISCRETE LOGARITHM PROBLEM", DESIGNS, CODES AND CRYPTOGRAPHY, KLUWER ACADEMIC PUBLISHERS, BOSTON, US, vol. 7, no. 1-02, 1 January 1996 (1996-01-01), pages 61 - 81, XP000905401, ISSN: 0925-1022 *
RENAUD LIFCHITZ: "Hacking the NFC credit cards for fun and debit ;)", HACKITO ERGO SUM 2012, 12 April 2012 (2012-04-12), XP055358533, Retrieved from the Internet <URL:https://www.epiguard.ch/shop/ProdukteDetails/HES-2012-contactless-payments-insecurity.pdf> [retrieved on 20170324] *
VAN ELS ET AL: "THE ADVANCED COMPUTING SYSTEMS ASSOCIATION Risks and Potentials of Using EMV for Internet Payments Risks and Potentials of using EMV for Internet Payments", USENIX WORKSHOP ON SMARTCARD TECHNOLOGY CHICAGO, 10 May 1999 (1999-05-10), XP055358695, Retrieved from the Internet <URL:http://static.usenix.org/publications/library/proceedings/smartcard99/full_papers/herreweghen/herreweghen.pdf> [retrieved on 20170324] *

Also Published As

Publication number Publication date
CA3029154A1 (fr) 2018-01-04
US10922679B2 (en) 2021-02-16
US20190228402A1 (en) 2019-07-25
WO2018002351A1 (fr) 2018-01-04
EP3479518A1 (fr) 2019-05-08
FR3053549B1 (fr) 2018-07-27

Similar Documents

Publication Publication Date Title
EP2820795B1 (fr) Procede de verification d&#39;identite d&#39;un utilisateur d&#39;un terminal communiquant et systeme associe
EP1908215A1 (fr) Procédé de contrôle de transactions sécurisées mettant en oeuvre un dispositif physique unique à bi-clés multiples, dispositif physique, système et programme d&#39;ordinateur correspondants
EP3221815A1 (fr) Procédé de sécurisation d&#39;un jeton de paiement.
EP3032799A1 (fr) Procédé d&#39;authentification d&#39;un utilisateur, serveur, terminal de communication et programmes correspondants
EP3479518A1 (fr) Procede d&#39;authentification de donnees de paiement, dispositifs et programmes correspondants
FR3092927A1 (fr) Procédé de traitement d&#39;une transaction de paiement, dispositif, système et programmes correspondants
CN104320261B (zh) 金融智能卡上实现身份认证的方法、金融智能卡和终端
EP2306668B1 (fr) Système et procédé de transaction sécurisée en ligne
EP3479325B1 (fr) Procédé d&#39;authentification de données de paiement, dispositifs et programmes correspondants.
EP3588418A1 (fr) Procédé de réalisation d&#39;une transaction, terminal, serveur et programme d ordinateur correspondant
EP3095223B1 (fr) Méthode de transmission de données chiffrées, méthode de réception, dispositifs et programmes d&#39;ordinateur correspondants
CA2973836A1 (fr) Procede de traitement de donnees par un dispositif electronique d&#39;acquisition de donnees, dispositif et programme correspondant
EP3570238B1 (fr) Procédé de réalisation d&#39;une transaction, terminal, serveur et programme d&#39;ordinateur correspondant
WO2019038323A1 (fr) Procédé d&#39;authentification d&#39;un utilisateur auprès d&#39;un serveur d&#39;authentification
EP2084679A1 (fr) Entite electronique portable et procede de blocage, a distance, d&#39;une fonctionnalite d&#39;une telle entite electronique portable
EP3371760A1 (fr) Procédé de verification d&#39;identité lors d&#39;une virtualisation
EP3029878B1 (fr) Procédé de transmission de secret à durée de vie limitée pour réaliser une transaction entre un terminal mobile et un équipement
WO2021028639A1 (fr) Procede de transmission d&#39;une information numerique
FR3007929A1 (fr) Procede d&#39;authentification d&#39;un utilisateur d&#39;un terminal mobile
FR2984648A1 (fr) Dispositif electronique individuel et procede de reponse par un dispositif electronique individuel a une sollicitation

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20180105

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6

TP Transmission of property

Owner name: BANKS AND ACQUIRERS INTERNATIONAL HOLDING, FR

Effective date: 20211202

PLFP Fee payment

Year of fee payment: 7

PLFP Fee payment

Year of fee payment: 8

PLFP Fee payment

Year of fee payment: 9