CA3029154A1 - 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 PDFInfo
- Publication number
- CA3029154A1 CA3029154A1 CA3029154A CA3029154A CA3029154A1 CA 3029154 A1 CA3029154 A1 CA 3029154A1 CA 3029154 A CA3029154 A CA 3029154A CA 3029154 A CA3029154 A CA 3029154A CA 3029154 A1 CA3029154 A1 CA 3029154A1
- Authority
- CA
- Canada
- Prior art keywords
- obtaining
- private key
- authentication
- terminal
- message
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 71
- 238000004891 communication Methods 0.000 claims abstract description 71
- 238000012545 processing Methods 0.000 claims description 25
- 230000005540 biological transmission Effects 0.000 claims description 21
- 238000004364 calculation method Methods 0.000 claims description 14
- 230000006870 function Effects 0.000 claims description 14
- 238000012795 verification Methods 0.000 claims description 14
- 230000015654 memory Effects 0.000 claims description 13
- 238000004590 computer program Methods 0.000 claims description 10
- 230000008569 process Effects 0.000 description 17
- 238000011282 treatment Methods 0.000 description 12
- 238000009434 installation Methods 0.000 description 8
- 230000004044 response Effects 0.000 description 5
- 230000008901 benefit Effects 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 238000010200 validation analysis Methods 0.000 description 4
- 239000000463 material Substances 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 208000004995 necrotizing enterocolitis Diseases 0.000 description 3
- 201000002120 neuroendocrine carcinoma Diseases 0.000 description 3
- 230000006399 behavior Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 101150073426 Ctsj gene Proteins 0.000 description 1
- 206010016275 Fear Diseases 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000003339 best practice Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000003203 everyday effect Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000004377 microelectronic Methods 0.000 description 1
- ZRHANBBTXQZFSP-UHFFFAOYSA-M potassium;4-amino-3,5,6-trichloropyridine-2-carboxylate Chemical group [K+].NC1=C(Cl)C(Cl)=NC(C([O-])=O)=C1Cl ZRHANBBTXQZFSP-UHFFFAOYSA-M 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
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/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/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/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
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 NEC, 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.
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 NEC, 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 NEC. Parfois, ces techniques de transmission de données sont également appelées RFID. Cette appellation n'est pas correcte puisque NEC 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 elle-même (NEC), mais généralement de l'utilisateur lui-même. Ainsi par exemple, dans le cas d'un terminal de communication utilisant l'interface NEC 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 NEC pour le paiement, il est nécessaire que le dispositif et le terminal authentifie des données. A cette fin, le dispositif met en oeuvre 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 oeuvre 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 oeuvre lors d'un paiement entre un terminal de communication et un dispositif d'utilisateur. On appelle "V" le
é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 NEC. Parfois, ces techniques de transmission de données sont également appelées RFID. Cette appellation n'est pas correcte puisque NEC 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 elle-même (NEC), mais généralement de l'utilisateur lui-même. Ainsi par exemple, dans le cas d'un terminal de communication utilisant l'interface NEC 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 NEC pour le paiement, il est nécessaire que le dispositif et le terminal authentifie des données. A cette fin, le dispositif met en oeuvre 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 oeuvre 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 oeuvre lors d'un paiement entre un terminal de communication et un dispositif d'utilisateur. On appelle "V" le
3 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 oeuvre 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 oeuvre 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
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 oeuvre 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 oeuvre 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
4 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 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, 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 Si ;
- une étape 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 Si, d'un premier composant de signature 52;
- 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 Si, d'un deuxième composant de signature 53;
- une étape de transmission, au terminal de communication, du code d'authentification Si, et des deux composants de signature 52 et 53.
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 52, d'une clé
publique X du dispositif d'utilisateur, d'une clé privée z du terminal de communication, et du code d'authentification Si, d'une première valeur de référence, notée Ufrii;
- une étape d'obtention, à partir du deuxième composant de signature 53, d'une clé
publique Y du dispositif d'utilisateur, de la clé privée z, et du code d'authentification Si, d'une deuxième valeur de référence, notée 142] ;
- une étape de vérification que la première valeur de référence Iffrii est égale à la deuxième valeur de référence 142] ; et, lorsque les deux valeurs sont égales :
- une étape de vérification que la valeur H(142]) et/ou H(1./1rii) est égale à Si.
- une étape de délivrance d'une assertion d'authentification lorsque l'étape de
Pour ce faire, il est divulgué 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, 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 Si ;
- une étape 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 Si, d'un premier composant de signature 52;
- 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 Si, d'un deuxième composant de signature 53;
- une étape de transmission, au terminal de communication, du code d'authentification Si, et des deux composants de signature 52 et 53.
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 52, d'une clé
publique X du dispositif d'utilisateur, d'une clé privée z du terminal de communication, et du code d'authentification Si, d'une première valeur de référence, notée Ufrii;
- une étape d'obtention, à partir du deuxième composant de signature 53, d'une clé
publique Y du dispositif d'utilisateur, de la clé privée z, et du code d'authentification Si, d'une deuxième valeur de référence, notée 142] ;
- une étape de vérification que la première valeur de référence Iffrii est égale à la deuxième valeur de référence 142] ; et, lorsque les deux valeurs sont égales :
- une étape de vérification que la valeur H(142]) et/ou H(1./1rii) est égale à Si.
- une étape de délivrance d'une assertion d'authentification lorsque l'étape de
5 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=e.
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 Si met en oeuvre le calcul suivant :
=
H(mlit), ou I I est l'opérateur de concaténation ;
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=e.
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 Si met en oeuvre le calcul suivant :
=
H(mlit), ou I I est l'opérateur de concaténation ;
6 - l'étape d'obtention du premier composant de signature 52 met en oeuvre le calcul suivant : 52 = (Mi I t)Zel ;
- l'étape d'obtention du deuxième composant de signature 53 met en oeuvre le calcul suivant : 53 = I I tesl.
Selon un mode de réalisation particulier :
l'étape d'obtention de la première valeur de référence Iffrii met en oeuvre le calcul suivant : Ufrii = s2X-zsi ;
- l'étape d'obtention de la deuxième valeur de référence Ufr2J met en oeuvre le calcul suivant :142] = s3y-zsl.
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 Si ;
- 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 Si, d'un premier composant de signature 52;
- 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 Si, d'un deuxième composant de signature 53;
- des moyens de transmission, au terminal de communication, du code d'authentification Si, et des deux composants de signature 52 et 53.
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
- l'étape d'obtention du deuxième composant de signature 53 met en oeuvre le calcul suivant : 53 = I I tesl.
Selon un mode de réalisation particulier :
l'étape d'obtention de la première valeur de référence Iffrii met en oeuvre le calcul suivant : Ufrii = s2X-zsi ;
- l'étape d'obtention de la deuxième valeur de référence Ufr2J met en oeuvre le calcul suivant :142] = s3y-zsl.
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 Si ;
- 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 Si, d'un premier composant de signature 52;
- 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 Si, d'un deuxième composant de signature 53;
- des moyens de transmission, au terminal de communication, du code d'authentification Si, et des deux composants de signature 52 et 53.
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
7 comprenant notamment une authentification d'une donnée, ledit terminal de commerçant comprenant :
- des moyens d'obtention, à partir du premier composant de signature 52, d'une clé
publique X du dispositif d'utilisateur, d'une clé privée z du terminal de communication, et du code d'authentification Si, d'une première valeur de référence, notée Ufrii;
- des moyens d'obtention, à partir du deuxième composant de signature .53, d'une clé
publique Y du dispositif d'utilisateur, de la clé privée z, et du code d'authentification Si, d'une deuxième valeur de référence, notée 142] ;
- des moyens de vérification que la première valeur de référence Ufrii est égale à la deuxième valeur de référence Ufry ; et, lorsque les deux valeurs sont égales :
- des moyens de vérification que la valeur H(142]) et/ou H(1./1rii) est égale à Si.
- 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 oeuvre 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.
- des moyens d'obtention, à partir du premier composant de signature 52, d'une clé
publique X du dispositif d'utilisateur, d'une clé privée z du terminal de communication, et du code d'authentification Si, d'une première valeur de référence, notée Ufrii;
- des moyens d'obtention, à partir du deuxième composant de signature .53, d'une clé
publique Y du dispositif d'utilisateur, de la clé privée z, et du code d'authentification Si, d'une deuxième valeur de référence, notée 142] ;
- des moyens de vérification que la première valeur de référence Ufrii est égale à la deuxième valeur de référence Ufry ; et, lorsque les deux valeurs sont égales :
- des moyens de vérification que la valeur H(142]) et/ou H(1./1rii) est égale à Si.
- 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 oeuvre 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.
8 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 disc) 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 oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'a 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 oeuvre 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 oeuvre 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.
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 oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'a 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 oeuvre 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 oeuvre 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.
9 Chaque composante du système précédemment décrit met bien entendu en oeuvre ses propres modules logiciels.
Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en oeuvre 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. A 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 "Denial of Seryerce", 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 oeuvre 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 oeuvre n'est donc pas une technique de type défi-réponse (qui est un processus interactif) ; il ne 5 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
Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en oeuvre 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. A 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 "Denial of Seryerce", 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 oeuvre 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 oeuvre n'est donc pas une technique de type défi-réponse (qui est un processus interactif) ; il ne 5 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
10 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
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
11 modifications protocolaires et matérielles permettant de mettre en oeuvre 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 oeuvre 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 oeuvre conjointe des applications de paiement TPC et DU, le procédé mis en oeuvre 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 Si ;
- 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 Si, un premier composant de signature 52;
- 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 Si, un deuxième composant de signature 53;
- le module P transmet (40), au terminal du commerçant (ou au module V), le code d'authentification Si, et les deux composants de signature 52 et 53.
Ces étapes, effectuées sur le dispositif d'utilisateur (ou le module P) sont mises en oeuvre sur la base d'une part de clés privées (deux) à disposition du dispositif d'utilisateur et
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 oeuvre 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 oeuvre conjointe des applications de paiement TPC et DU, le procédé mis en oeuvre 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 Si ;
- 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 Si, un premier composant de signature 52;
- 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 Si, un deuxième composant de signature 53;
- le module P transmet (40), au terminal du commerçant (ou au module V), le code d'authentification Si, et les deux composants de signature 52 et 53.
Ces étapes, effectuées sur le dispositif d'utilisateur (ou le module P) sont mises en oeuvre sur la base d'une part de clés privées (deux) à disposition du dispositif d'utilisateur et
12 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 (Si, 52, 53) 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.
A partir des données reçues (Si, 52 et 53), 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 52, de la clé
publique X
(correspondant à la clé privée x), de sa propre clé privée z, et du code d'authentification Si, une première valeur de référence, notée Iffrii - calcule (60), à partir du deuxième composant de signature 53, de la clé
publique Y
(correspondant à la clé privée y), de sa propre clé privée z, et du code d'authentification Si, une deuxième valeur de référence, notée 1.4.21;
vérifie (70) que la première valeur de référence Iffrii est égale à la deuxième valeur de référence 1421; et, lorsque les deux valeurs sont égales :
- vérifie (80) que la valeur H(142) est égale à Si.
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 oeuvre le
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.
A partir des données reçues (Si, 52 et 53), 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 52, de la clé
publique X
(correspondant à la clé privée x), de sa propre clé privée z, et du code d'authentification Si, une première valeur de référence, notée Iffrii - calcule (60), à partir du deuxième composant de signature 53, de la clé
publique Y
(correspondant à la clé privée y), de sa propre clé privée z, et du code d'authentification Si, une deuxième valeur de référence, notée 1.4.21;
vérifie (70) que la première valeur de référence Iffrii est égale à la deuxième valeur de référence 1421; et, lorsque les deux valeurs sont égales :
- vérifie (80) que la valeur H(142) est égale à Si.
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 oeuvre le
13 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 142] est égal au premier code d'authentification Si ; 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 ;
A 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é. Il 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 S1 est utilisé. Dès lors, le code d'authentification S1 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 S1 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 oeuvre dans la cadre des spécifications EMV. On comprend, à lecture de ce qui précède, que les procédés mis en oeuvre 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
- 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 142] est égal au premier code d'authentification Si ; 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 ;
A 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é. Il 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 S1 est utilisé. Dès lors, le code d'authentification S1 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 S1 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 oeuvre dans la cadre des spécifications EMV. On comprend, à lecture de ce qui précède, que les procédés mis en oeuvre 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
14 oeuvre 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 oeuvre 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 oeuvre 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 Zpx 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+1, 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 à / et strictement inférieur à p:
= si hr E 1 (mo d p) alors passer à l'entier suivant ;
= sinon, la valeur g = hr (mo d p) est un générateur sous-groupe de Zpx 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 (2256).
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 10 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
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 oeuvre 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 oeuvre 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 Zpx 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+1, 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 à / et strictement inférieur à p:
= si hr E 1 (mo d p) alors passer à l'entier suivant ;
= sinon, la valeur g = hr (mo d p) est un générateur sous-groupe de Zpx 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 (2256).
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 10 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
15 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 oeuvre 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 = el ;
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
Cette installation peut typiquement être mise en oeuvre 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 = el ;
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
16 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 oeuvre 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
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 oeuvre 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
17 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.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.
18 5.2.3. Déroulé de l'authentification Dans ce mode de réalisation, l'authentification est mise en oeuvre 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 Si selon la formule suivante :
o Si = H(m l i t), ou l l est l'opérateur de concaténation ;
- le module P calcule, à partir du message m, de la donnée aléatoire t, de la clé publique Z, de la première clé privée x de P et du code d'authentification Si, le premier composant de signature 52, selon la formule suivante :
o 52 = (111 I I t)Zel - le module P calcule, à partir du message m, de la donnée aléatoire t, de la clé publique Z, de la deuxième clé privée y de P et du code d'authentification Si, le deuxième composant de signature 53;
o 53 = (Mi I t)Zs1 - le module P transmet, au terminal du commerçant (ou au module V), le code d'authentification Si, et les deux composants de signature 52 et 53.
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 Si. Dès lors, un attaquant, qui intercepterait par exemple le code d'authentification Si, ne pourrait pas, à partir de celui-ci, inférer le contenu du message m.
Les méthodes de calcul des valeurs 51, 52 et 53 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, 52 et 53 sont
- 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 Si selon la formule suivante :
o Si = H(m l i t), ou l l est l'opérateur de concaténation ;
- le module P calcule, à partir du message m, de la donnée aléatoire t, de la clé publique Z, de la première clé privée x de P et du code d'authentification Si, le premier composant de signature 52, selon la formule suivante :
o 52 = (111 I I t)Zel - le module P calcule, à partir du message m, de la donnée aléatoire t, de la clé publique Z, de la deuxième clé privée y de P et du code d'authentification Si, le deuxième composant de signature 53;
o 53 = (Mi I t)Zs1 - le module P transmet, au terminal du commerçant (ou au module V), le code d'authentification Si, et les deux composants de signature 52 et 53.
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 Si. Dès lors, un attaquant, qui intercepterait par exemple le code d'authentification Si, ne pourrait pas, à partir de celui-ci, inférer le contenu du message m.
Les méthodes de calcul des valeurs 51, 52 et 53 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, 52 et 53 sont
19 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 51, 52 et 53. 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 oeuvre les étapes suivantes :
- calcule, à partir du premier composant de signature 52, de la clé
publique X
(correspondant à la clé privée x), de sa propre clé privée Z, et du code d'authentification Si, une première valeur de référence, notée Iffrii O Utrij = S2Xzsi - calcule, à partir du deuxième composant de signature 53, de la clé
publique Y
(correspondant à la clé privée y), de sa propre clé privée Z, et du code d'authentification Si, une deuxième valeur de référence, notée 1.4.2] ;
0 utrzi = s3y-zsi.
- vérifie que la première valeur de référence Iffrii est égale à la deuxième valeur de référence 142); et, lorsque les deux valeurs sont égales :
- vérifie que la valeur H(142]) est égale à Si.
Si la valeur de H(142]) est égale à Si, 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 Si au système de paiement pour validation de la transaction).
Explicité autrement, Le terminal du commerçant effectue les calculs suivants :
0 Utrij = s2X-z5i = (m I I t)ZA(x 51) X^(-z Si) =
(m I I t)g^(z x 51) g^(- z x 51) =
(ml lt) et O utrzi =
= (m I I t)ZA(y 51) YA(-z 51) =
[m I I t)g^(yz 51) g^(-yz 51) =
(ml lt) 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 (NEC), permet de valider une transaction de manière 5 sécuritaire.
5.3. Autres caractéristiques et avantages On décrit, en relation avec la figure 3, un terminal de communication mis en oeuvre pour réaliser une authentification de données dans le cadre d'un processus de paiement, selon le procédé décrit préalablement.
10 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 15 en oeuvre le procédé d'authentification tels que décrit précédemment pour effectuer un paiement auprès du commerçant.
A 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
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 51, 52 et 53. 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 oeuvre les étapes suivantes :
- calcule, à partir du premier composant de signature 52, de la clé
publique X
(correspondant à la clé privée x), de sa propre clé privée Z, et du code d'authentification Si, une première valeur de référence, notée Iffrii O Utrij = S2Xzsi - calcule, à partir du deuxième composant de signature 53, de la clé
publique Y
(correspondant à la clé privée y), de sa propre clé privée Z, et du code d'authentification Si, une deuxième valeur de référence, notée 1.4.2] ;
0 utrzi = s3y-zsi.
- vérifie que la première valeur de référence Iffrii est égale à la deuxième valeur de référence 142); et, lorsque les deux valeurs sont égales :
- vérifie que la valeur H(142]) est égale à Si.
Si la valeur de H(142]) est égale à Si, 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 Si au système de paiement pour validation de la transaction).
Explicité autrement, Le terminal du commerçant effectue les calculs suivants :
0 Utrij = s2X-z5i = (m I I t)ZA(x 51) X^(-z Si) =
(m I I t)g^(z x 51) g^(- z x 51) =
(ml lt) et O utrzi =
= (m I I t)ZA(y 51) YA(-z 51) =
[m I I t)g^(yz 51) g^(-yz 51) =
(ml lt) 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 (NEC), permet de valider une transaction de manière 5 sécuritaire.
5.3. Autres caractéristiques et avantages On décrit, en relation avec la figure 3, un terminal de communication mis en oeuvre pour réaliser une authentification de données dans le cadre d'un processus de paiement, selon le procédé décrit préalablement.
10 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 15 en oeuvre le procédé d'authentification tels que décrit précédemment pour effectuer un paiement auprès du commerçant.
A 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
20 d'authentification et deux éléments de signature. Le microprocesseur de l'unité de traitement sécurisée 34 met en oeuvre 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.
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.
21 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 oeuvre 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 NEC 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 oeuvre 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 oeuvre le procédé d'authentification tels que décrit précédemment pour effectuer un paiement auprès du commerçant.
A 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 oeuvre 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.
Par ailleurs, le dispositif comprend en outre les moyens de communication en champs proches, dits NEC 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 oeuvre 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 oeuvre le procédé d'authentification tels que décrit précédemment pour effectuer un paiement auprès du commerçant.
A 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 oeuvre 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.
22 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 oeuvre 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 NEC 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.
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 oeuvre 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 NEC 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 (8)
1. 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, 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 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.
- 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.
2. 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 S1, d'une première valeur de référence, notée U[r,1];
- 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 S1, 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[r1]
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[r1) est égale à S1.
- une étape de délivrance d'une assertion d'authentification lorsque l'étape de vérification précédente est positive.
- 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 S1, d'une première valeur de référence, notée U[r,1];
- 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 S1, 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[r1]
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[r1) est égale à S1.
- une étape de délivrance d'une assertion d'authentification lorsque l'étape de vérification précédente est positive.
3. 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=g x ;
- 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=g y.
- 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=g x ;
- 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=g y.
4. 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=g z.
- 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=g z.
5. Procédé d'authentification selon la revendication 3, caractérisé en ce que :
- l'étape d'obtention (10) du code d'authentification S1 met en oeuvre le calcul suivant :
S1 = H(m¦¦ t), ou ¦¦ est l'opérateur de concaténation ;
- l'étape d'obtention (20) du premier composant de signature S2 met en oeuvre le calcul suivant : S2 =(m¦¦t)Z xs1;
- l'étape d'obtention (30) du deuxième composant de signature S3 met en oeuvre le calcul suivant : S3 = (m¦¦t)Z ys1.
- l'étape d'obtention (10) du code d'authentification S1 met en oeuvre le calcul suivant :
S1 = H(m¦¦ t), ou ¦¦ est l'opérateur de concaténation ;
- l'étape d'obtention (20) du premier composant de signature S2 met en oeuvre le calcul suivant : S2 =(m¦¦t)Z xs1;
- l'étape d'obtention (30) du deuxième composant de signature S3 met en oeuvre le calcul suivant : S3 = (m¦¦t)Z ys1.
6. 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[r1] met en oeuvre le calcul suivant : U[r1] = S2X-zs1;
- l'étape d'obtention (60) de la deuxième valeur de référence U[r2] met en oeuvre le calcul suivant :U[r2]= s3Y-zs1.
- l'étape d'obtention (50) de la première valeur de référence U[r1] met en oeuvre le calcul suivant : U[r1] = S2X-zs1;
- l'étape d'obtention (60) de la deuxième valeur de référence U[r2] met en oeuvre le calcul suivant :U[r2]= s3Y-zs1.
7. 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 S1;
- 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 S1, 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 S1, d'un deuxième composant de signature S3 ;
- des moyens de transmission, au terminal de communication, du code d'authentification S1, et des deux composants de signature S2 et S3.
- 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 S1;
- 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 S1, 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 S1, d'un deuxième composant de signature S3 ;
- des moyens de transmission, au terminal de communication, du code d'authentification S1, et des deux composants de signature S2 et S3.
8. 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.
Applications Claiming Priority (3)
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. |
PCT/EP2017/066365 WO2018002351A1 (fr) | 2016-06-30 | 2017-06-30 | Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants |
Publications (1)
Publication Number | Publication Date |
---|---|
CA3029154A1 true CA3029154A1 (fr) | 2018-01-04 |
Family
ID=57583156
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA3029154A Pending CA3029154A1 (fr) | 2016-06-30 | 2017-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 (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109347635A (zh) * | 2018-11-14 | 2019-02-15 | 中云信安(深圳)科技有限公司 | 一种基于国密算法的物联网安全认证***及认证方法 |
CN111639187B (zh) * | 2019-03-01 | 2023-05-16 | 上海数眼科技发展有限公司 | 一种基于知识图谱的知识问答验证码生成***及方法 |
Family Cites Families (4)
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 |
-
2016
- 2016-06-30 FR FR1656240A patent/FR3053549B1/fr active Active
-
2017
- 2017-06-30 WO PCT/EP2017/066365 patent/WO2018002351A1/fr unknown
- 2017-06-30 EP EP17733483.6A patent/EP3479518A1/fr not_active Ceased
- 2017-06-30 US US16/314,174 patent/US10922679B2/en active Active
- 2017-06-30 CA CA3029154A patent/CA3029154A1/fr active Pending
Also Published As
Publication number | Publication date |
---|---|
US10922679B2 (en) | 2021-02-16 |
WO2018002351A1 (fr) | 2018-01-04 |
FR3053549A1 (fr) | 2018-01-05 |
FR3053549B1 (fr) | 2018-07-27 |
EP3479518A1 (fr) | 2019-05-08 |
US20190228402A1 (en) | 2019-07-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP3032799B1 (fr) | Procédé d'authentification d'un utilisateur, serveur, terminal de communication et programmes correspondants | |
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'ordinateur correspondants | |
EP2619941A1 (fr) | Procede, serveur et systeme d'authentification d'une personne | |
FR3013541A1 (fr) | Procede et dispositif pour la connexion a un service distant | |
EP2509025A1 (fr) | Procédé d'accès à une ressource protégée d'un dispositif personnel sécurisé | |
FR3092927A1 (fr) | Procédé de traitement d'une transaction de paiement, dispositif, système et programmes correspondants | |
CA3029154A1 (fr) | Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants | |
EP3991381B1 (fr) | Procédé et système de génération de clés de chiffrement pour données de transaction ou de connexion | |
EP2306668B1 (fr) | Système et procédé de transaction sécurisée en ligne | |
EP3479325B1 (fr) | Procédé d'authentification de données de paiement, dispositifs et programmes correspondants. | |
EP3588418A1 (fr) | Procédé de réalisation d'une transaction, terminal, serveur et programme d ordinateur correspondant | |
EP3273398B1 (fr) | Procédé de traitement de données par un dispositif électronique d'acquisition de données, dispositif et programme correspondant | |
EP3095223B1 (fr) | Méthode de transmission de données chiffrées, méthode de réception, dispositifs et programmes d'ordinateur correspondants | |
EP3570238B1 (fr) | Procédé de réalisation d'une transaction, terminal, serveur et programme d'ordinateur correspondant | |
FR3070516A1 (fr) | Procede d'authentification d'un utilisateur aupres d'un serveur d'authentification | |
EP2084679A1 (fr) | Entite electronique portable et procede de blocage, a distance, d'une fonctionnalite d'une telle entite electronique portable | |
EP4014466A1 (fr) | Procede de transmission d'une information numerique | |
WO2022117789A1 (fr) | Procédé de transmission de données, dispositif et programme correspondant | |
FR3007929A1 (fr) | Procede d'authentification d'un utilisateur d'un terminal mobile | |
FR2888437A1 (fr) | Procede et systeme de controle d'acces a un service d'un fournisseur d'acces implemente sur un serveur multimedia, module, serveur, terminal et programmes pour ce systeme | |
EP3029878A1 (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 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
EEER | Examination request |
Effective date: 20220628 |
|
EEER | Examination request |
Effective date: 20220628 |
|
EEER | Examination request |
Effective date: 20220628 |
|
EEER | Examination request |
Effective date: 20220628 |
|
EEER | Examination request |
Effective date: 20220628 |
|
EEER | Examination request |
Effective date: 20220628 |