CA3161315A1 - Procede et systeme, dispositif et terminal de paiement utilisant des donnees personnelles - Google Patents

Procede et systeme, dispositif et terminal de paiement utilisant des donnees personnelles Download PDF

Info

Publication number
CA3161315A1
CA3161315A1 CA3161315A CA3161315A CA3161315A1 CA 3161315 A1 CA3161315 A1 CA 3161315A1 CA 3161315 A CA3161315 A CA 3161315A CA 3161315 A CA3161315 A CA 3161315A CA 3161315 A1 CA3161315 A1 CA 3161315A1
Authority
CA
Canada
Prior art keywords
payment
transaction
personal information
terminal
condition
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
Application number
CA3161315A
Other languages
English (en)
Inventor
David Naccache
Michel Leger
Elena Trichina
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Banks and Acquirers International Holding SAS
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Publication of CA3161315A1 publication Critical patent/CA3161315A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • 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/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • 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/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G06Q20/207—Tax processing
    • 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/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • 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/388—Payment protocols; Details thereof using mutual authentication without cards, e.g. challenge-response
    • 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/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • 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/405—Establishing or using transaction specific rules
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • 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/3226—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 a predetermined code, e.g. password, passphrase or PIN
    • 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/3271—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 challenge-response
    • H04L9/3273—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 challenge-response for mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/50—Secure pairing of devices

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un procédé de transaction électronique pour un système comprenant un dispositif de paiement 3 ou 4 associé à utilisateur et un terminal de paiement 1. Le dispositif de paiement 3 ou 4 et le terminal de paiement 1 réalisent un échange de clef cryptographique 500 avant de réaliser une étape de transaction 501. Le dispositif de paiement comporte une information personnelle PI relative à l'utilisateur. Le terminal de paiement comporte une politique de transaction comportant une condition relative à l'information personnelle PI. Le procédé comporte une étape de vérification 510, 520, 530, préalablement à l'étape de transaction 501, pour vérifier la condition de la politique de transaction relative à l'information personnelle de manière sécurisée en utilisant la clef cryptographique.

Description

Description Titre de l'invention : PROCEDE ET SYSTEME, DISPOSITIF
ET TERMINAL DE PAIEMENT UTILISANT DES DONNEES
PERSONNELLES
[0001] Domaine Technique
[0002] La présente invention se rapporte à un procédé, un système, un dispositif et un terminal de paiement utilisant des données personnelles. Plus généralement, l'invention se rapporte à une amélioration de paiements électroniques sécurisés.
[0003] Arrière-Plan Technologique
[0004] Une transaction électronique permet la vente ou l'achat de biens ou de services en utilisant des moyens de paiement électroniques. Le présent document se rapporte plus particulièrement aux transactions initiées sur un point de vente et réalisées sur un appareil disposant de moyens pour sécuriser de telles transactions. Pour mettre en oeuvre ce type de transaction, un dispositif de paiement mémorise des identifiants de paiement, tel qu'une carte bancaire (magnétique, à contact ou sans contact), un téléphone mobile ou une montre intelligente, afin d'être présenté à un terminal de paiement qui vérifie l'authenticité du moyen de paiement et valide la transaction. Dans les transactions actuelles, seules l'authentification des moyens de paiement et la capacité de paiement sont vérifiés. De nombreux protocoles de paiement existent. A titre d'exemple non limitatif, le protocole EMV (issu des initiales des sociétés fondatrices Europay international, Mastercard international et Visa international) spécifie l'interopérabilité entre des cartes bancaires et des terminaux de paiement en autorisant de nombreuses variantes de mise en oeuvre : avec ou sans contact, avec paiement comptant ou à crédit, avec ou sans code PIN, avec des niveaux de sécurité variables suivant le type de transaction ou selon l'émetteur de la carte, etc.
[0005] Par ailleurs, des conditions de paiement peuvent être conditionnées selon certaines données personnelles d'un acheteur et certaines transactions peuvent également être légalement interdites selon de telles données personnelles.
Lorsqu'elles existent, ces conditions de transaction sont généralement vérifiées par un vendeur lors de l'achat. Des consommateurs non résidants peuvent être désireux de ne pas payer certaines taxes imposées sur la vente de produits, tel que par exemple la TVA (Taxe sur la Valeur Ajoutée en France). Pour cela, ils doivent justifier de leur état ou faire une demande de détaxation postérieure à un achat. Un contrôle de l'âge de l'acheteur peut être requis pour obtenir une réduction de tarif ou une autorisation d'achat. Ce type de contrôle n'est réalisable que si un vendeur est présent ou, si un tel achat est réalisé sur un distributeur automatique, en faisant confiance aux données qui sont indiquées par l'acheteur.
Un vendeur peut en outre omettre de vérifier de telles données personnelles ou se faire tromper par un acheteur mal intentionné, tout comme un distributeur automatique.
[0006] Il existe un besoin pour réaliser des transactions conditionnées par des données personnelles d'un titulaire de moyen de paiement afin d'appliquer un tarif approprié ou d'autoriser une transaction de manière sure et automatisée en fonction de données personnelles d'un acheteur muni de moyens de paiement électroniques.
[0007] Résumé de l'Invention
[0008] L'invention propose d'améliorer les transactions électroniques sur un point de vente en vérifiant de manière sécurisée l'authenticité d'une ou plusieurs informations personnelles d'un acheteur sans que celui-ci n'ait à produire de justificatif à un vendeur. A cet effet, un dispositif de paiement comporte au moins une information personnelle qui est présentée de manière certifiée à un terminal de paiement. Le terminal de paiement est adapté pour mettre en oeuvre une politique de transaction qui prend en compte une ou plusieurs informations personnelles pour autoriser ou refuser de finaliser une transaction.
[0009] L'invention propose un procédé de transaction électronique entre un dispositif de paiement associé à un compte bancaire d'un utilisateur et un terminal de paiement associé à un compte bancaire acquéreur dans lequel le dispositif de paiement et le terminal de paiement réalisent au moins un échange de clef cryptographique avant de réaliser une étape de transaction au cours de laquelle la transaction est validée ou rejetée. Le dispositif de paiement comporte au moins une information personnelle relative à l'utilisateur. Le terminal de paiement comporte au moins une politique de transaction comportant une condition relative à l'au moins une information personnelle. Le procédé comporte une étape de vérification, préalablement à l'étape de transaction, pour vérifier la condition de la politique de transaction relative à l'information personnelle de manière sécurisée en utilisant la clef cryptographique.
[0010] Selon un premier mode de réalisation, l'étape de vérification peut consister en que le dispositif de paiement envoie l'information personnelle accompagnée d'une signature cryptographique réalisée à l'aide de l'information personnelle et de la clef cryptographique afin d'authentifier l'information personnelle. Le terminal 1.0 de paiement peut vérifier la condition de la politique de transaction après avoir authentifier l'information personnelle.
[0011] Selon une variante de ce premier mode de réalisation, préalablement à
l'envoi de l'information personnelle, le terminal de paiement peut envoyer une requête au dispositif de paiement pour provoquer l'envoi de l'information personnelle par ce dernier.
[0012] Selon un deuxième mode de réalisation, l'étape de vérification peut consister en ce que le terminal de paiement envoie une requête de vérification de la politique de transaction au dispositif de paiement la requête étant signée à
l'aide de la clef cryptographique. La vérification de la condition de la politique de transaction peut être réalisée par le dispositif de paiement, après avoir authentifier la requête à l'aide de la clef cryptographique, qui élabore et transmet un message de validation ou d'invalidation au terminal de paiement en fonction de la condition et de l'information personnelle.
[0013] Selon un mode particulier, le montant de la transaction peut être modifié par le terminal de paiement en fonction du résultat de l'étape de vérification.
[0014] Préférentiellement, l'échange de clef cryptographique peut être réalisé
lors d'une étape d'authentification mutuelle.
[0015] L'invention propose également un procédé de transaction électronique mis en oeuvre par un microprocesseur d'un dispositif de paiement associé à un compte bancaire d'un utilisateur destiné à coopérer avec un terminal de paiement associé à un compte bancaire acquéreur afin de réaliser une étape de transaction au cours de laquelle la transaction est validée ou rejetée, ledit procédé comportant une étape pour échanger avec le terminal de paiement au moins une clef cryptographique. Le dispositif de paiement comporte au moins une information personnelle relative à l'utilisateur enregistrée dans une mémoire de données. Le procédé comporte une étape de vérification d'une condition d'une politique de transaction relative à l'information personnelle est vérifiée de manière sécurisée en utilisant la clef cryptographique.
[0016] Selon un premier mode de réalisation, l'étape de vérification peut comporter l'envoi d'un message contenant l'information personnelle accompagnée d'une 1.0 signature cryptographique réalisée à l'aide de l'information personnelle et de la clef cryptographique afin d'authentifier ladite information personnelle.
[0017] Selon un deuxième mode de réalisation, l'étape de vérification de la condition de la politique de transaction peut comporter une étape préalable pour authentifier une requête émise par le terminal de paiement contenant la condition de la politique de transaction, la requête étant signée à l'aide de la clef cryptographique, et une étape d'envoi d'un message de validation ou d'invalidation en fonction de la condition et de l'information personnelle.
[0018] En outre, l'invention propose un procédé de transaction électronique mis en oeuvre par un microprocesseur d'un terminal de paiement, associé à un compte bancaire acquéreur, destiné à coopérer avec un dispositif de paiement associé
à
un compte bancaire d'un utilisateur. Ledit procédé comporte une étape pour échanger au moins une clef cryptographique avec le dispositif de paiement et une étape de transaction au cours de laquelle la transaction est validée ou rejetée. Le terminal de paiement comporte au moins une politique de transaction comportant une condition relative à au moins une information personnelle relative à l'utilisateur du dispositif de paiement. Le procédé comporte une étape de vérification pour requérir la vérification de la condition de la politique de transaction relative à l'information personnelle en utilisant la clef cryptographique, et l'étape de transaction est mise en oeuvre si et seulement si la condition est vérifiée.
[0019] Selon un premier mode de réalisation, au cours de l'étape de vérification, le procédé peut comporter une étape pour recevoir un message incluant l'information personnelle accompagnée d'une signature cryptographique réalisée à l'aide de l'information personnelle et de la clef cryptographique et une étape pour vérifier la condition de la politique de transaction après avoir authentifié
l'information personnelle à l'aide de la clef cryptographique.
[0020] Selon une variante de ce premier mode de réalisation, le procédé peut comporter une étape pour élaborer et transmettre une requête au dispositif de paiement afin d'obtenir l'information personnelle.
[0021] Selon un deuxième mode réalisation, l'étape de vérification peut consister à
élaborer et transmettre une requête de vérification de la politique de transaction au dispositif de paiement, la requête étant signée à l'aide de la clef cryptographique.
[0022] Selon un mode de réalisation particulier, le procédé peut comporter une étape pour modifier le montant de la transaction en fonction du résultat de la vérification de la condition préalablement à la validation de la transaction.
[0023] Selon un autre aspect, l'invention propose un système de transaction électronique comprenant un dispositif de paiement associé à un compte bancaire d'un utilisateur et terminal de paiement associé à un compte bancaire acquéreur dans lequel le dispositif de paiement et le terminal de paiement sont configurés pour réaliser un échange d'au moins une clef cryptographique avant de réaliser une étape de transaction au cours de laquelle la transaction est validée ou rejetée. Le dispositif de paiement comporte au moins une information personnelle relative à l'utilisateur et le terminal de paiement comporte au moins une politique de transaction comportant une condition relative à l'au moins une information personnelle. Le dispositif et le terminal de paiement sont configurés pour réaliser une étape de vérification entre l'étape d'échange de clef cryptographique et l'étape de transaction au cours de laquelle la condition de la politique de transaction relative à l'information personnelle est vérifiée de manière sécurisée à l'aide de la clef cryptographique.
[0024] Selon un premier mode de réalisation, le dispositif de paiement peut être configuré pour transmettre au terminal de paiement un message contenant l'information personnelle signé à l'aide de l'information personnelle et de la clef
25 6 cryptographique afin d'authentifier l'information personnelle et le terminal de paiement peut être configuré pour vérifier la condition après avoir authentifier l'information personnelle à l'aide de la clef cryptographique.
[0025] Selon une variante de ce premier mode de réalisation, le terminal de paiement peut être configuré pour élaborer et transmettre une requête au dispositif de paiement afin d'obtenir l'information personnelle.
[0026] Selon un deuxième mode de réalisation, le terminal de paiement peut être configuré pour élaborer et transmettre au dispositif de paiement une requête de vérification de la condition de la politique de transaction signée à l'aide de la clef cryptographique. Le dispositif de paiement peut être configuré pour authentifier ladite requête à l'aide de la clef cryptographique avant de vérifier la condition en réponse à la requête de vérification et pour renvoyer un message de validation ou d'invalidation au terminal de paiement en fonction de la condition et de l'information personnelle.
[0027] Selon un mode de réalisation particulier, le terminal de paiement peut être configuré pour modifier le montant de la transaction en fonction du résultat de l'étape de vérification.
[0028] Également, l'invention propose un dispositif de paiement associé à un compte bancaire d'un utilisateur destiné à coopérer avec un terminal de paiement pour réaliser une transaction électronique, ledit dispositif de paiement étant configuré
pour échanger au moins une clef cryptographique avec le terminal de paiement.
Le dispositif de paiement comporte au moins une information personnelle relative à l'utilisateur, et le dispositif de paiement est configuré pour réaliser une étape de vérification d'une condition d'une politique de transaction relative à
l'information personnelle de manière sécurisée à l'aide de la clef cryptographique
[0029] Selon un premier mode de réalisation, le dispositif de paiement peut être configuré pour envoyer au terminal de paiement l'information personnelle dans un message signé à l'aide de l'information personnelle et de la clef cryptographique afin d'authentifier l'information personnelle
[0030] Selon un deuxième mode de réalisation, le dispositif de paiement peut être configuré pour vérifier la condition de la politique de transaction en réponse à la réception d'une requête de vérification contenant la condition, ladite requête étant signée et transmise par le terminal de paiement à l'aide de la clef cryptographique, et pour élaborer et transmettre un message de validation ou d'invalidation au terminal de paiement en fonction de la condition et de l'information personnelle.
[0031] Préférentiellement, le dispositif de paiement peut être un dispositif compris dans la liste suivante : carte à puce conforme à la norme IS07816 et/ou à la norme 14443, téléphone portable ou tablette comprenant une capacité de paiement sécurisé, montre intelligente comprenant des fonctionnalités de 1.0 paiement, ordinateur sécurisé comprenant une interface de communication avec ou sans contact et comprenant une capacité de paiement sécurisé.
[0032] En outre, l'invention propose un terminal de paiement associé à un compte bancaire acquéreur destiné à coopérer avec un dispositif de paiement associé à

un compte bancaire d'un utilisateur pour réaliser une transaction électronique dans lequel le terminal de paiement est configuré pour échanger au moins une clef cryptographique avec le dispositif de paiement avant de mettre en oeuvre une étape de transaction au cours de laquelle la transaction est validée ou rejetée. Le terminal de paiement comporte au moins une politique de transaction comprenant une condition relative à au moins une information personnelle enregistrée dans une mémoire du dispositif de paiement, ladite information personnelle étant relative à l'utilisateur. Le terminal de paiement est configuré
pour mettre en uvre une étape de vérification, avant l'étape de transaction, au cours de laquelle la condition de la politique de transaction relative à
l'information personnelle est vérifiée de manière sécurisée à l'aide de la clef cryptographique.
[0033] Selon un premier mode de réalisation, le terminal de paiement peut être configuré pour recevoir un message contenant l'information personnelle signé à

l'aide de l'information personnelle et de la clef cryptographique par le dispositif de paiement. Le terminal de paiement peut être configuré pour vérifier la condition après avoir authentifier l'information personnelle à l'aide de la clef cryptographique.
[0034] En variante du premier mode de réalisation, le terminal de paiement peut "être configuré pour élaborer et transmettre une requête au dispositif de paiement afin d'obtenir l'information personnelle.
[0035] Selon un deuxième mode de réalisation, le terminal de paiement peut être configuré pour élaborer et transmettre au dispositif de paiement une requête de vérification de la condition de la politique de transaction signée à l'aide de la clef cryptographique. Le terminal de paiement peut être configuré pour terminer la transaction suite à un message de validation ou d'invalidation renvoyé par le dispositif de paiement en fonction de la condition et de l'information personnelle.
[0036] Selon un mode de réalisation particulier, le terminal de paiement peut être configuré pour modifier le montant de la transaction en fonction du résultat de l'étape de vérification.
[0037] Préférentiellement, ledit terminal de paiement peut être compris dans la liste de dispositifs suivante : terminal de point de vente pour carte à puce, téléphone portable ou tablette comprenant une capacité d'enregistrement de paiement sécurisé, caisse enregistreuse comprenant une capacité d'enregistrement de paiement sécurisé.
[0038] Brève Description des figures
[0039] L'invention sera mieux comprise et d'autres caractéristiques et avantages de celle-ci apparaîtront à la lecture de la description suivante de modes de réalisation particuliers de l'invention, donnés à titre d'exemples illustratifs et non limitatifs, et faisant référence aux dessins annexés, parmi lesquels :
[0040] [Fig.1] illustre un système de paiement électronique concerné par l'invention,
[0041] [Fig.2] illustre une carte à puce selon l'invention,
[0042] [Fig.3] illustre un téléphone portable utilisé comme moyen de paiement selon l'invention,
[0043] [Fig.4] illustre un terminal de paiement selon l'invention,
[0044] [Fig.5] représente un schéma de paiement modifié selon un premier exemple de réalisation de l'invention,
[0045] [Fig.6] représente un schéma de paiement modifié selon un deuxième exemple de réalisation de l'invention.
[0046] Description détaillée
[0047] La figure 1 illustre un système de paiement électronique sécurisé
utilisé selon l'état de la technique et utilisé pour mettre en oeuvre l'invention. Le système de la figure 1 comporte un terminal de paiement 1 capable de communiquer d'une part avec un serveur bancaire 2 et d'autre part avec un dispositif de paiement 3 ou 4.
Ce type de système est communément utilisé pour effectuer des opérations de paiement depuis un point de vente, tel que défini dans de nombreuses normes 1.0 de services de paiement, par exemple dans la norme EMV qui est la plus largement utilisée et qui comporte de nombreuses possibilités de mise en uvre.
Le terminal de paiement 1 peut être amené à réaliser des transactions hors ligne ou en ligne c'est-à-dire de manière déconnectée ou connectée avec le serveur bancaire 2. Le dispositif de paiement 3 est classiquement une carte à
puce 3 ou un téléphone portable 4, voire tout autre dispositif électronique capable d'émuler le fonctionnement d'une carte à puce de manière sécurisée, tel que par exemple une montre intelligente qui est une extension d'un téléphone portable sous forme d'une montre bracelet, ou encore tout type d'ordinateur ayant les mêmes capacités ou fonctionnalités.
[0048] A titre d'exemple, la figure 2 illustre fonctionnellement une carte bancaire 3, ou carte à puce, qui comporte un microprocesseur 31 contrôlant un bus central 32 pour échanger des données avec une mémoire 33, un crypto-processeur 34, une interface de communication à contact 35 et une interface de communication sans contact 36. L'interface de communication à contact 35 est par exemple compatible avec la norme IS07816. L'interface de communication sans contact 36 est par exemple une interface de communication en champ proche, de type NFC (de l'anglais Near Field Contactless) compatible avec la norme IS014443.
Bien que de nombreuses cartes de paiement disposent de ces deux types d'interface de communication 35 et 36, certaines cartes ne disposent que d'une seule interface de communication avec ou sans contact. Pour l'invention, l'important est que la carte à puce 3 dispose d'au moins une interface de communication avec ou sans contact.
[0049] La mémoire 33 peut être segmentée en mémoire volatile de type RAM (de l'anglais Random Access Memory), en mémoire de programme non inscriptible de type ROM (de l'anglais Read-Only Memory) et en mémoire non volatile de type EEPROM (de l'anglais Electrically-Erasable Programmable Read-Only Memory) ou Flash. Un système d'exploitation sécurisé est mis en uvre par le microprocesseur 31 pour garantir la sécurité des informations mémorisées dans la mémoire 33 de la carte à puce 3. Ainsi, le microprocesseur 31 peut autoriser l'accès en lecture ou en écriture de certaines zones de la mémoire à des commandes provenant de l'une des interfaces de communication 35 ou 36.
1.0 D'autres zones de la mémoire 33 ne peuvent être accessibles qu'au microprocesseur 31 ou au crypto-processeur 34. Certaines données peuvent être rendues accessibles par le microprocesseur 31 depuis l'extérieur de manière conditionnelle.
[0050] De nombreuse variantes d'architecture de carte à puce sont connues et l'homme du métier peut à loisir utiliser une architecture différente ou similaire de celle décrite sur la figure 2. Néanmoins, l'homme du métier prendra soin de n'utiliser que des architectures de carte sécurisées de manière suffisante pour l'application aux services bancaires et notamment conforme aux spécifications d'une norme de transaction bancaire, telle que par exemple et non limitativement la norme EMV.
[0051] Selon l'invention, une information personnelle PI est stockée dans la partie non volatile de la mémoire 33 lors de la personnalisation de la carte à puce concomitamment à des données relatives à un compte bancaire auquel la carte à
puce est associée. L'information personnelle PI est relative au titulaire du compte bancaire. Elle peut être relative à son âge, à sa date de naissance, à son lieu de résidence ou consister en tout autre information personnelle qui peut être utilisée lors d'une transaction selon l'invention. L'information personnelle PI peut être stockée dans une zone de mémoire accessible en lecture directement depuis l'une des interfaces de communication 35 ou 36 tout en étant protégée en écriture afin qu'elle ne puisse être altérée après la personnalisation par une personne non autorisée. Cependant, de manière préférée, l'information personnelle PI est stockée dans une zone de la mémoire 33 qui n'est pas directement accessible depuis l'une des interfaces de communication 35 ou 36.
Dans une variante, l'information personnelle PI n'est pas du tout accessible depuis l'extérieur. L'utilisation de cette information personnelle PI sera décrite plus loin dans la présente description.
[0052] La figure 3 illustre de manière fonctionnelle un téléphone portable 4 utilisable comme dispositif de paiement. A titre d'exemple, le téléphone portable 4 est un téléphone portable de type intelligent, communément nommé sous l'appellation anglo-saxonne snnartphone , qui comporte un microprocesseur 41 relié à
travers un bus central 42 à une mémoire volatile 43, une mémoire non volatile 44, une interface utilisateur 45, une carte SIM 46, une interface de radiocommunication 47, une interface de proximité 48 et un élément sécurisé
49.
D'autres éléments peuvent également faire partie du téléphone portable 4 mais ne sont pas représentés car ils ne concernent pas directement l'invention. A
titre d'exemple, ces autres éléments peuvent comprendre un microphone, un haut-parleur, un vibreur, une caméra, un lecteur de carte mémoire, une interface de communication filaire par exemple de type USB, une batterie ou encore tout autre élément intégrable dans un téléphone portable. De plus, le téléphone portable 4 décrit à l'aide la figure 3 correspond à un type de téléphone préféré
non limitatif. Notamment, en variante, il est possible que le téléphone portable 4 ne comporte pas l'élément sécurisé 49 ni la carte SIM 46.
[0053] Le microprocesseur 41 est le coeur du téléphone portable 4 qui gère l'intégralité des éléments le constituant via le bus central 42 à partir de programmes enregistrés dans la mémoire non volatile 44 en utilisant la mémoire volatile 43 comme mémoire de travail. La mémoire non volatile 44 est par exemple composée de mémoire de type ROM et de mémoire électriquement effaçable de type EEPROM ou de type Flash. Parmi les programmes mémorisés, le système d'exploitation du téléphone portable 4 permet de gérer les différentes fonctionnalités en faisant appel à des programmes spécifiques qui permettent de produire différentes commandes à destination des différents éléments du téléphone 4. Dans le mode de réalisation préféré selon la figure 3 qui inclue la carte SIM 46 et l'élément sécurisé 49, le système d'exploitation n'est pas sécurisé en tant que tel car la sécurisation de données et d'opérations sensibles peut se faire dans la carte SIM 46 et/ou dans l'élément sécurisé 49. Selon une variante qui ne comporte pas de carte SIM 46, ni d'élément sécurisé 49, il est nécessaire d'avoir un système d'exploitation sécurisé qui permet de restreindre les accès en lecture, écriture et exécution à certaines zones de la mémoire afin de garantir la sécurisation de certains programmes et notamment les programmes de transactions bancaires.
[0054] L'interface utilisateur 45 est préférentiellement un écran tactile pouvant également inclure un lecteur d'empreinte digitale. Dans une variante minimaliste, l'interface utilisateur peut se limiter à un écran d'affichage et un clavier.
De 1.0 nombreuses autres variantes sont également possibles pour un homme du métier sans que cela limite la portée de l'invention.
[0055] La carte SIM 46 (de l'anglais Subscriber Identity Module) est communément utilisée pour mémoriser des identifiants d'accès à un réseau de téléphonie mobile (non représenté) et pour sécuriser l'accès audit réseau. Typiquement la carte SIM 46 est une carte à puce servant à authentifier le téléphone sur le réseau de téléphonie selon l'une des normes de téléphonie, une telle carte est par exemple conforme à la norme IS07816 et à la norme ETSI TS 102 221. Selon le mode préféré de réalisation, la carte SIM 46 assure uniquement son rôle de communication avec le réseau de téléphonie mobile.
[0056] L'interface de radiocommunication 47 est une interface radio programmable multi fréquences disposant de circuits de modulation, de démodulation, d'encodage et de décodage pouvant se configurer de différentes manières afin de communiquer sur une bande de fréquence et selon un protocole de communication choisi par le microprocesseur 41 en fonction d'informations contenue dans la carte SIM 46. Cette interface est compatible avec plusieurs standards de radio téléphonie, tel que 2G, 3G, 4G et/ou avec des standards de communication radio de plus courte portée tel que, par exemple les standards WiFi ou Bluetooth. Par cette interface de radiocommunication, il est possible d'échanger de la voix et des données.
[0057] L'interface de proximité 48 est une interface de type CLF (de l'anglais Contactless Front-End) tel que défini dans la norme ETSI TS 102 613, afin de permettre au téléphone portable de réaliser des communications en champ proche de type NEC, qui sont compatibles avec la norme IS014443. Grace à
cette interface le téléphone portable 4 peut émuler le fonctionnement d'une cade à puce sans contact ou d'un lecteur de carte à puce sans contact. Le contrôle de cette interface de proximité se fait par l'intermédiaire du bus central 42 ou par un port de communication spécifique destiné à être directement relié à une carte SIM comme défini dans la norme ETSI TS 102 613.
[0058] L'élément sécurisé 49 est un circuit intégré indépendant qui contient un processeur sécurisé, une mémoire d'exécution et un stockage inviolable à
l'instar d'une carte à puce. L'élément sécurisé 49 comporte un premier port de 1.0 communication relié au bus central 42 et un deuxième port de communication relié au port de communication spécifique de l'interface de proximité 48.
Lorsque le téléphone 4 est éteint, l'élément sécurisé 49 peut être alimenté
directement par l'interface de proximité 48 à partir du champ électromagnétique servant à la communication. L'élément sécurisé 49 peut mémoriser des données et des programmes de manière sécurisé. Il peut également les exécuter en toute sécurité. Cet élément sécurisé 49 peut contenir et exécuter des programmes sécurisés à l'identique de ceux exécutable par la carte à puce 3 décrite précédemment, notamment pour réaliser des opérations de paiement. Selon un mode de réalisation préféré, l'élément sécurisé contient l'information personnelle Pl.
[0059] Selon une variante dans laquelle le téléphone portable 4 ne dispose pas d'élément sécurisé 49, la carte SIM 46 peut être une carte multi-applications intégrant une application bancaire et l'information personnelle Pl. A cet effet, la carte SIM peut être conforme à la norme ETSI TS 102 613 et disposer d'une liaison directe avec l'interface de proximité 48 via son port de communication spécifique ou effectuer des échanges de données avec le terminal de paiement 1 via l'interface de radiocommunication 47. La carte SIM 46 peut ainsi remplacer l'élément sécurisé 49 et assurer à sa place les différentes fonctions décrites précédemment.
[0060] Selon une autre variante, le téléphone portable 4 ne dispose pas d'élément sécurisé 49 ni de carte SIM 46. Selon cette variante, le téléphone 4 dispose d'un système d'exploitation sécurisé, d'un programme d'application bancaire et l'information personnelle PI est stockée dans une zone protégée de la mémoire non volatile 44.
[0061] De manière alternative, le téléphone portable 4 peut être remplacé par tout autre dispositif électronique comportant un microprocesseur disposant de tout ou partie des éléments décrits en relation avec la figure 3. A titre d'exemple non limitatif, un tel dispositif peut être une tablette, une montre intelligente, ou un ordinateur portable. Il convient toutefois que le dispositif électronique dispose d'une capacité de sécurisation en lecture, en écriture et en exécution des programmes et des données pour pouvoir recevoir une application de paiement 1.0 sécurisée et une interface de communication avec ou sans contact qui permette de communiquer avec le terminal de paiement 1.
[0062] La figure 4 illustre de manière fonctionnelle un terminal de paiement 1 destiné
à recevoir des paiements sous la forme de transactions électroniques. Le terminal de paiement 1 peut être un terminal de point de vente ou terminal POS
(de l'anglais Point Of Sale) sécurisé, c'est-à-dire intégré dans un boîtier structurellement renforcé contre toute tentative malveillante d'atteinte à son intégrité mais peut également être placé dans un distributeur automatique de produit ou être inclu dans une caisse enregistreuse de magasin, ou encore être émulé sur un téléphone portable intelligent de type smartphone .
[0063] A titre d'exemple non limitatif, le terminal de paiement 1 comporte un microprocesseur 101 relié à travers un bus central 102 à une mémoire volatile 103, une mémoire non volatile 104, un écran 105, un clavier 106, une carte SAM

107, une imprimante 108, une interface de communication 109 avec et/ou sans contact, un lecteur de carte à puce 110 à contact, une interface de communication de proximité 111. D'autres éléments peuvent également faire partie du terminal de paiement 1 mais ne sont pas représentés car ils ne concernent pas directement l'invention. A titre d'exemple, ces autres éléments peuvent comprendre une batterie, une carte SIM, un lecteur de carte à mémoire ou encore tout autre élément intégrable dans un terminal de paiement. De plus, le terminal de paiement 1 décrit correspond à un terminal de type POS préféré
non limitatif. Notamment, en variante, il est possible que le terminal de paiement 1soit simplifié ou énnulé sur un téléphone portable sécurisé et ne pas comporter d'interface de communication de proximité 111, de lecteur de carte à puce 110, d'imprimante 108 ou de carte SAM 107. En outre, l'écran 105 et le clavier 106 peuvent être remplacés par un écran tactile ou tout autre type d'interface homme machine permettant d'interagir avec un utilisateur.
[0064] Le microprocesseur 101 est le c ur du terminal de paiement 1 qui gère l'intégralité des éléments le constituant via le bus central 102 à partir de programmes mémorisés dans la mémoire non volatile 104 en utilisant la mémoire volatile 103 comme mémoire de travail. La mémoire non volatile 104 est par exemple composée de mémoire de type ROM et de mémoire électriquement 1.0 effaçable de type EEPROM ou de type Flash. Parmi les programmes enregistrés dans la mémoire non volatile 104, nous pouvons citer un système d'exploitation sécurisé mis en oeuvre par le microprocesseur 101 pour garantir la sécurité
des informations mémorisées dans la mémoire 104. Ainsi, l'accès en lecture et/ou en écriture à certaines zones de mémoire n'est possible que sous le contrôle du microprocesseur 101 à partir de l'une des l'interfaces de communication 109.
[0065] La mémoire non volatile 104 comporte également des programmes exécutables par le microprocesseur 101 destinés à la réalisation de transactions bancaires. Ces programmes comportent un certain nombre de sous programmes capables de supporter différentes options de transaction qui dépendent du type de carte bancaire, de l'émetteur de la carte bancaire, et aussi de paramètres particuliers qui peuvent par exemple être définis par un marchand qui utilise ledit terminal de paiement 1. Parmi les sous programmes, certains peuvent être respectivement relatif à des politiques de transaction (en anglais Transaction Policies) qui définissent des conditions particulières de paiement, par exemple des vérifications électroniques à effectuer suivant le type de carte, un seuil de paiement au-delà duquel la banque doit être contactée pour autoriser ou refuser la transaction, des conditions relatives à l'entrée ou saisie d'un code de vérification ou à des vérifications complémentaires paramétrables par le marchand disposant dudit terminal 1.
[0066] L'écran 105 permet aux utilisateurs du terminal de paiement 1 de visualiser des informations lors de l'exécution d'une transaction. Le clavier 106 permet à
son utilisateur d'indiquer au terminal de paiement 1 des informations de transaction tel que par exemple le montant de la transaction ou l'entrée d'un code d'identification personnel ou PIN (de l'anglais Personnal Identification Number).
L'imprimante 108 sert à éditer un reçu de transaction à destination du débiteur et/ou du marchand. Dans une variante, l'imprimante 108 n'est pas présente et le reçu de transaction peut être envoyé sous la forme d'un message électronique à
chacune des parties à la transaction ou à une autre machine reliée au terminal de paiement 1 qui effectuera l'édition en lieu et place dudit terminal 1.
[0067] La carte SAM 107 (de l'anglais Secure Access Module) est un module d'accès sécurisé ou module d'application sécurisé. La carte SAM garantie une 1.0 sécurisation de la transaction et des informations sensibles du terminal de paiement 1. La carte SAM 107 peut mémoriser et produire des clefs cryptographique et/ou mettre en oeuvre des algorithmes de calculs cryptographiques nécessaires pour la mise en oeuvre d'une politique de sécurité, par exemple pour réaliser un processus d'authentification forte réalisé lors d'une transaction. La carte SAM 107 est une carte à puce insérée dans un lecteur interne non représenté du terminal de paiement 1. Selon une variante, la carte SAM 107 peut être remplacée par un élément sécurisé ou par le microprocesseur 101 si celui-ci comporte un processeur cryptographique et un système d'exploitation sécurisé permettant de garantir une sécurisation suffisante des informations sensibles.
[0068] L'interface de communication 109 permet au terminal de communiquer avec le serveur bancaire 2. Suivant le type de terminal de paiement 1, une telle interface de communication 109 supporte classiquement des communications dites filaires par exemple suivant le protocole d'internet et/ou des communication de type radiocommunication, par exemple selon un protocole de radiotéléphonie 3G ou 4G. Le chiffrage des communications effectuée par l'intermédiaire de l'interface de communication 109 est préférentiellement effectué par la carte SAM 107. Selon une variante, une communication entre un dispositif de paiement 4 et le terminal de paiement 1 peut être réalisée par l'intermédiaire de l'interface de communication 109.
[0069] Le lecteur de carte à puce 110 est un lecteur de carte à puce conforme à la norme IS07816 afin de recevoir une carte bancaire 3 et de communiquer avec elle par contacts électriques. L'interface de proximité 111 est un lecteur de carte sans contact conforme à la norme IS014443 qui permet de communiquer avec une carte bancaire 3 ou tout autre dispositif de paiement 4 sans contact disposant d'une interface de proximité compatible avec ladite norme IS014443.
[0070] Selon un mode préféré de l'invention, la mémoire 104 du terminal de paiement 1 comporte un ou plusieurs sous-programmes correspondant à une ou plusieurs politiques de transaction Pol(PI) afin de prendre en considération l'information personnelle PI mémorisée dans le dispositif de paiement 3 ou 4.
De telles politiques de transaction peuvent être justifiée d'un point de vue légal ou d'un point de vue commerciale. Chaque politique de transaction Pol(PI) comporte une condition relative à une information personnelle PI qui conditionne la réalisation d'une transaction suivant que ladite condition soit vérifiée ou non par ladite information personnelle Pl. En vérifiant la conformité de l'information personnelle PI à la condition de la politique de transaction Pol(PI), le terminal de paiement 1 permet d'éviter d'avoir à justifier auprès d'un vendeur la véracité
de ces informations en produisant par exemple une pièce d'identité. Ainsi, il est possible de réaliser des transactions conditionnées par des informations personnelles sans que la présence d'un vendeur soit nécessaire et donc de réaliser ce type de transaction à l'aide de machines de distribution.
[0071] A titre d'exemple non limitatif, quelques politiques de vérification d'information personnelles sont indiquées. Une première politique de transaction Pol(PI) peut être relative à un âge minimum du porteur du dispositif de paiement pour pouvoir effectuer une transaction sur un produit à distribution restreinte légalement.
Par exemple, une vente peut être refusée à un mineur. Cette première politique permet, par exemple, à un distributeur de cigarettes ou de boissons alcoolisées de vérifier l'âge du client sans qu'il soit nécessaire d'avoir recours à une personne pour effectuer ladite vérification. Une deuxième politique de transaction Pol(PI) peut être relative à une remise commerciale en fonction de l'âge de la personne dans le cadre d'une promotion commerciale pour favoriser une clientèle jeune ou séniore. Par exemple, si le titulaire de la carte à moins de vingt-cinq ans ou plus de soixante-cinq ans, le terminal de paiement 1 peut vérifier l'information personnelle PI correspondant à l'âge du porteur du dispositif de paiement et calculer une remise de dix pour cent sur un montant d'une transaction. Une troisième politique de transaction Pol(PI) peut consister à
détaxer les personnes étrangères afin d'éviter des opérations postérieures de détaxation. Avec cette troisième politique, le terminal de paiement 1 peut, par exemple, vérifier une information personnelle PI correspondant au pays de résidence du porteur du dispositif de paiement et déduire le montant des taxes si l'information personnelle PI correspond à un pays pour lequel la détaxation est applicable. L'adresse peut également être utilisée à titre commercial dans une quatrième politique de transaction Pol(PI) qui provoque des remises commerciales à des personnes résidant dans des zones géographiques de promotion commerciales. Selon cette quatrième politique, le terminal vérifie une information personnelle PI correspondant à l'adresse ou au code postal du porteur du dispositif de paiement puis calcule une remise commerciale si l'adresse de résidence correspond à une zone géographique de promotion commerciale. De nombreuses autres politiques peuvent être envisagées dès lors que certaines informations personnelles sont présentes dans le dispositif de paiement. De très nombreuses variantes sont envisageables dès lors qu'une transaction peut être conditionnée par une information personnelle Pl.
[0072] La vérification de la conformité de l'information personnelle PI à la condition de la politique de transaction Pol(PI) peut se faire de différente manière.
Selon l'invention, l'authenticité de l'information personnelle PI est vérifiée préalablement à la vérification de la conformité à ladite condition. Les figure 5 et 6 illustrent deux techniques de vérification. Pour ces deux figures 5 et 6, on considère conjointement le terminal de paiement 1 et le serveur bancaire 2. En effet, pour certaines opérations d'authentification, le terminal de paiement 1 devient transparent et ne sert que de relai ou passerelle entre un dispositif de paiement 3 ou 4 et le serveur bancaire 2. Pour les descriptions des figures 5 et 6, on considère un terminal de paiement 1 de type lecteur de carte à puce, en liaison avec un dispositif de paiement 3 de type carte bancaire. Néanmoins, toutes les variantes de terminal bancaire ou de dispositif de paiement 3 ou 4 peuvent se substituer au système décrit.
[0073] Sur la figure 5, un premier exemple de procédé d'utilisation de l'information personnelle est décrit. Le terminal de paiement 1 et le dispositif de paiement mettent en oeuvre leurs programmes de transaction respectifs incluant les sous-programmes relatifs aux différentes étapes du procédé qui va être décrit et notamment les sous-programmes relatifs à la mise en oeuvre des politiques de transaction Pol(PI). Dans ce premier exemple, le terminal de paiement 1 et le dispositif de paiement 3 réalisent une étape d'authentification mutuelle 500, tel que défini dans un protocole de paiement bancaire, par exemple le protocole EMV. Au cours de cette étape d'authentification mutuelle 500, le dispositif de paiement 3 et le terminal de paiement 1 peuvent s'échanger des clefs publiques, des certificats, un secret, réaliser un challenge, déterminer une clef de session et, éventuellement, échanger un code PIN. Le but de l'étape d'authentification 500 est de permettre, d'une part, au terminal de paiement 1 de vérifier que le dispositif de paiement 3 est un dispositif de paiement autorisé et, d'autre part, au dispositif de paiement 3 de vérifier que le terminal de paiement 1 est un terminal de paiement autorisé et, éventuellement, que le titulaire du dispositif de paiement valide la transaction sur le terminal de paiement 1. Pour plus de détails, l'homme du métier se reportera aux différentes normes de transaction de paiement existantes. Dans le cadre de l'invention, toute norme de transaction peut se substituer à la norme EMV et il n'est pas nécessaire d'avoir une authentification mutuelle dès lors qu'au moins une clef cryptographique soit échangée entre le terminal de paiement 1 et dispositif de paiement 3.
[0074] Selon l'état de la technique, une étape de transaction 501 vient après l'étape d'authentification mutuelle 500. Au cours de l'étape de transaction 501, le terminal de paiement 1 et le dispositif de paiement 3 échangent les données de transaction, tel que par exemple le montant de la transaction, et exécute chacune des sous-programme d'analyse de risque hors ligne, éventuellement complétée par une analyse de risque en ligne en communiquant avec le serveur bancaire 2 puis finalisent la transaction soit en refusant la transaction soit en l'acceptant et en mémorisant de part et d'autre la transaction réalisée.
[0075] Selon l'invention, une étape de vérification de l'information personnelle PI est ajoutée entre l'étape d'authentification mutuelle 500 et l'étape de transaction 501.

L'application de la politique de transaction Pol(PI) peut ensuite être exécutée préalablement à ou au moment de l'étape de transaction 501. Dans l'exemple de la figure 5, le terminal de paiement 1 envoie une requête 510 demandant une ou plusieurs informations personnelles PI au dispositif de paiement 3. Suite à
cette requête 510, le dispositif de paiement 3 renvoie une réponse 520 contenant l'information personnelle PI demandée accompagnée d'une donnée d'authentification Sig(PI) de l'information personnelle Pl. Puis, le terminal de paiement 1, vérifie la donnée d'authentification de l'information personnelle PI
dans une étape 530 et, si celle-ci est authentifiée, vérifie que l'information 1.0 personnelle est conforme à la condition de la politique de transaction Pol(PI). La politique de transaction Pol(PI) est ensuite appliquée en fonction de la vérification préalablement ou au cours de l'étape de transaction 501.
[0076] La requête de 510 peut être envoyée de plusieurs manières, voire envoyée de manière implicite. Selon un premier mode de réalisation conforme au protocole EMV la requête 510 n'est pas envoyée. Lors de l'étape d'authentification mutuelle 500, Des informations relatives aux possibilités du terminal de paiement 1 peuvent être envoyées au dispositif de paiement 3 de sorte que ce dernier soit informé du protocole à appliquer vis-à-vis du terminal de paiement 1. Parmi les informations envoyées, le terminal de paiement 1 indique qu'une donnée personnelle PI est requise pour finaliser la transaction. A l'issue de l'étape d'identification mutuelle 500, le terminal de paiement 1 effectue une remise à

zéro à chaud du dispositif de paiement 3, également connu sous la terminologie anglaise Hot Reset . Suite au signal de remise à zéro, le dispositif de paiement 3 émet une réponse 520 qui correspond à un message de type ATR
(de l'anglais Answer To Reset) complété par l'information personnelle PI et par une signature Sig(PI) de l'information personnelle Pl. Préférentiellement la signature Sig(PI) est une signature cryptographique de la donnée personnelle PI, par exemple une signature telle que définie dans la norme PKCS#1 en utilisant une clef cryptographique qui peut être une clef de chiffrement commune, ou une structure de chiffrement à clef publique, partagée par le dispositif de paiement 3 et le terminal de paiement 1. De très nombreux types de signatures sont possibles, à titre d'exemple complémentaire non limitatif, un MAC (de l'anglais Message Authentication Code) tel que défini dans la publication RFC 2104 :

HMAC : Keyed-Hashing for Message Authentication peut également être utilisé. L'important est que la clef cryptographique utilisée par le dispositif de paiement 3 permette au terminal de paiement 1 de s'assurer de l'authenticité
de la donnée personnelle PI au cours de l'étape 530. L'information personnelle PI
étant considérée authentique, le terminal de paiement vérifie si ladite information personnelle PI est conforme à la condition de la politique de transaction Pol(PI).
[0077] Selon un deuxième mode de réalisation, le terminal de paiement 1 envoie une requête 510 sous la forme d'une commande de type APDU (de l'anglais Application Protocole Data Unit) définie dans la norme IS07816 pour lire 1.0 l'information personnelle Pl. Parmi les commandes APDU utilisables pour la requête 510, l'homme du métier peut utiliser, à titre d'exemple non limitatif, les commandes GET DATA, READ BINARY et READ RECORD permettent de lire une information dans un dispositif de paiement 3. En réponse à l'une de ces commandes identifiant l'information personnelle PI ou une zone contenant ladite information PI, le dispositif de paiement répond en envoyant un message de réponse 520 contenant l'information personnelle PI accompagnée d'un certificat ou d'une signature cryptographique Sig(PI) pour permettre au terminal de paiement d'authentifier ladite information personnelle PI au cours de l'étape 530.
Le certificat ou la signature cryptographique est réalisé(e) par exemple selon l'une des techniques décrites précédemment. L'information personnelle PI étant considérée authentique, le terminal de paiement vérifie si ladite information personnelle PI est conforme à la condition de la politique de transaction Pol(PI).
[0078] La figure 6 illustre un deuxième exemple de procédé d'utilisation de l'information personnelle Pl. Le terminal de paiement 1 et le dispositif de paiement 3 mettent en oeuvre leurs programmes de transaction respectifs incluant les sous-programmes relatifs aux différentes étapes du procédé qui va être décrit et notamment les sous-programmes relatifs à la mise en oeuvre des politiques de transaction Pol(PI). Dans ce deuxième exemple, le terminal de paiement 1 et le dispositif de paiement 3 réalisent une étape d'authentification mutuelle 500 et une étape de transaction 501, tel que précédemment défini selon un protocole de paiement électronique. Une vérification de l'information personnelle PI, est rajoutée entre l'étape d'authentification mutuelle 500 et l'étape de transaction 501 avant d'appliquer la politique de transaction préalablement à
ou au moment de l'étape de transaction 501. Dans le cadre de l'invention, toute norme de transaction peut se substituer à la norme EMV et il n'est pas nécessaire d'avoir une authentification mutuelle dès lors qu'au moins une clef cryptographique soit échangée entre le terminal de paiement 1 et dispositif de paiement 3.
[0079] Dans ce deuxième exemple, le terminal de paiement 1 envoie une requête 610 de vérification de l'information personnelle PI au dispositif de paiement indiquant une condition à vérifier vis-à-vis de l'information personnelle PI
pour 1.0 appliquer la politique de transaction Pol(PI). Au cours d'une étape 620, le dispositif de paiement 3 vérifie que l'information personnelle PI correspond à
la condition envoyée dans la requête 610. Le dispositif de paiement 3 renvoie une réponse 630 au terminal de paiement 1 contenant le résultat de la vérification. Le terminal de paiement 1 applique ensuite la politique de transaction Pol(PI) en fonction du résultat de la vérification préalablement ou au cours de l'étape de transaction 501. Ainsi, l'information personnelle PI peut rester confidentielle car la seule information donnée est que l'information personnelle PI satisfait la condition de la politique de transaction.
[0080] La requête 610 de vérification peut être envoyé à l'aide d'une APDU de type VERIFY qui dispose d'un certain nombre de champs de données qui spécifient l'information personnelle PI à vérifier et la condition de la politique de transaction Pol(PI). En outre, afin de garantir une confidentialité des données personnelles, la requête 610 peut comporter également une signature réalisée à l'aide d'une clef cryptographique partagée par le terminal de paiement 1 et le dispositif de paiement 3. La signature est réalisée par exemple sur la totalité des bits de la requête qui correspondent à la condition. La condition peut comporter une valeur et une relation entre la valeur et l'information personnelle Pl. A titre d'exemple, pour une information personnelle PI correspondant à un âge ou une date de naissance, la valeur peut être l'âge ou la date de naissance limite et la relation peut être une comparaison à cet âge ou date de naissance du type inférieur ou supérieur . Si l'information personnelle est un lieu de résidence, par exemple un pays, un code postal ou une adresse, la relation peut être du type égal ou différent .
[0081] A la réception de la requête 610, le dispositif de paiement 3 met en uvre un sous-programme de vérification au cours de l'étape 620. Ainsi le dispositif de paiement contrôle que la signature de la requête 610 est conforme à la condition demandée. Cette première vérification permet de s'assurer que la requête est bien émise par le terminal de paiement 1 qui est considéré comme un dispositif autorisé à faire une telle vérification. Une fois la vérification de la requête effectuée avec succès, le microprocesseur 31 du dispositif de paiement 3 lit dans 1.0 sa mémoire 33 l'information personnelle PI spécifiée dans la requête 610. Puis, le dispositif de paiement 3 effectuer la comparaison demandée de l'information personnelle PI avec la valeur indiquée. La comparaison effectuée, le dispositif de paiement va ensuite préparer et renvoyer une réponse 630 correspondant au résultat de ladite comparaison. Le résultat est de type binaire à savoir la condition est vérifiée ou la condition n'est pas vérifiée et la réponse 630 peut correspondre à un message de réponse à la commande VERIFY validant ou invalidant la comparaison effectuée de manière sécurisée. De manière optionnelle la réponse peut également être signée à l'aide de la clef cryptographique. Le terminal de paiement 1 applique ensuite la politique de transaction Pol(PI) en fonction du résultat de la vérification, préalablement ou au cours de l'étape de transaction 501.
[0082] L'homme du métier peut remarquer que le deuxième exemple de mise en oeuvre de l'invention permet en outre de conserver l'information personnelle PI
dans le dispositif de paiement. Cela permet de garder confidentiel l'information personnelle PI qui peut être une information sensible, tel que par exemple l'adresse du titulaire.
[0083] Dans d'autres modes de réalisation, plusieurs informations personnelles peuvent être présentes dans le dispositif de paiement 3 et plusieurs politiques de transaction Pol(PI) peuvent être utilisées lors d'une même transaction. Selon un mode particulier de mise en oeuvre, il est possible de répéter les étapes 510 à
530 ou 610 à 630 autant de fois qu'il est nécessaire. Selon un autre exemple de mise en oeuvre, il est possible d'utiliser des commandes plus complexes adressant plusieurs informations personnelles et/ou plusieurs conditions de manière simultanée.
[0084] Dans les exemples des figures 5 et 6, les APDU utilisées doivent être définies aussi bien dans le dispositif de paiement 3 que dans le terminal de paiement 1. A
cet effet, l'homme du métier comprendra qu'il est nécessaire de codifier et normaliser de telles fonctionnalités pour pouvoir les utiliser.
[0085] Selon une variante, il est possible de ne pas utiliser d'interfaces de communication conforme aux normes IS07816 ou IS014443. C'est notamment le cas lorsque le dispositif de paiement correspond au téléphone portable 4.
1.0 Dans ce cas, la transaction peut se faire en utilisant un protocole de communication radiofréquence, par exemple conforme à la norme IEEE 802.11 plus connue sous le nom de Wifi. La sécurisation de la transaction peut se faire en utilisant, par exemple, un canal encrypté en utilisant un procédé de transaction similaire à celui décrit précédemment. Les exemples de réalisation décrit à l'aide des figures 5 et 6 peuvent s'appliquer de manière similaire tout en prenant en compte que les messages échangés entre le terminal de paiement 1 et le téléphone portable 4 seront fait selon un autre protocole d'échange de données qui n'utilise pas nécessairement des APDU.
[0086] Quel que soit le mode de réalisation mis en oeuvre, l'utilisation d'une certification de l'information personnelle PI permet de garantir au niveau de la transaction que l'information est authentique. A cet effet, l'information personnelle PI est mémorisée dans le dispositif de paiement 3 par un tiers autorisé, tel que par exemple un établissement bancaire, et la certification effectuée par le dispositif de paiement vaut certification par le tiers autorisé.

Claims

Revendications [Revendication 1] Procédé de transaction électronique entre un dispositif de paiement (3, 4) associé à un compte bancaire d'un utilisateur et un terminal de paiement (1) associé à un compte bancaire acquéreur dans lequel le dispositif de paiement (3, 4) et le terminal de paiement (1) réalisent au moins un échange de clef cryptographique (500) avant de réaliser une étape de transaction (501) au cours de laquelle la transaction est validée ou rejetée, caractérisé en ce que :
- le dispositif de paiement comporte au moins une information personnelle io (PI) relative à l'utilisateur ;
- le terminal de paiement comporte au moins une politique de transaction (Pol(Pl)) comportant une condition relative à l'au moins une information personnelle (PI) ;
et en ce que le procédé comporte une étape de vérification (510, 520, 530, 610, 620, 630), préalablement à l'étape de transaction (501), pour vérifier la condition de la politique de transaction relative à l'information personnelle de manière sécurisée en utilisant la clef cryptographique.
[Revendication 2] Procédé selon la revendication 1 pour lequel, l'étape de vérification consiste en que le dispositif de paiement (3, 4) envoie (520) l'information personnelle accompagnée d'une signature cryptographique (Sig(Pl)) réalisée à l'aide de l'information personnelle et de la clef cryptographique afin d'authentifier l'information personnelle et en ce que le terminal de paiement (1) vérifie (530) la condition de la politique de transaction après avoir authentifier l'information personnelle.
[Revendication 3] Procédé selon la revendication 2 pour lequel, préalablement à l'envoi (520) de l'information personnelle (PI), le terminal de paiement (1) envoie (510) une requête au dispositif de paiement pour provoquer l'envoi de l'information personnelle (PI) par ce dernier.
[Revendication 4] Procédé selon la revendication 1 pour lequel, l'étape de vérification consiste en ce que le terminal de paiement (1) envoie (610) une requête de vérification de la politique de transaction (Pol(Pl)) au dispositif de paiement (3, 4) la requête étant signée à l'aide de la clef cryptographique, et en ce que la vérification (620) de la condition de la politique de transaction est réalisée par le dispositif de paiement (3, 4), après avoir authentifier la requête à l'aide de la clef cryptographique, qui élabore et transmet (630) un message de validation ou d'invalidation au terminal de paiement en fonction de la condition et de l'information personnelle (PI).
[Revendication 5] Procédé selon l'une des revendications 1 à 4, dans lequel le montant de la transaction est modifié par le terminal de paiement en fonction du résultat de l'étape de vérification.
[Revendication 6] Procédé selon l'une des revendications 1 à 5, dans lequel 1.0 l'échange de clef cryptographique est réalisé lors d'une étape d'authentification mutuelle.
[Revendication 7] Procédé de transaction électronique mis en uvre par un microprocesseur d'un dispositif de paiement (3, 4) associé à un compte bancaire d'un utilisateur destiné à coopérer avec un terminal de paiement (1) associé à un compte bancaire acquéreur afin de réaliser une étape de transaction (501) au cours de laquelle la transaction est validée ou rejetée, ledit procédé comportant une étape pour échanger avec le terminal de paiement (1) au moins une clef cryptographique (500), caractérisée en ce que le dispositif de paiement comporte au moins une information personnelle (PI) relative à l'utilisateur enregistrée dans une mémoire de données, et en ce que le procédé comporte une étape de vérification (510, 520, 530, 610, 620, 630) d'une condition d'une politique de transaction relative à l'information personnelle est vérifiée de manière sécurisée en utilisant la clef cryptographique.
[Revendication 8] Procédé selon la revendication 7 pour lequel, l'étape de vérification comporte l'envoi (520) d'un message contenant l'information personnelle accompagnée d'une signature cryptographique (Sig(Pl)) réalisée à l'aide de l'information personnelle et de la clef cryptographique afin d'authentifier ladite information personnelle.
[Revendication 9] Procédé selon la revendication 7 pour lequel, l'étape de vérification (620) de la condition de la politique de transaction comporte une étape préalable pour authentifier une requête émise par le terminal de paiement (1) contenant la condition de la politique de transaction, la requête étant signée à l'aide de la clef cryptographique, et une étape d'envoi (630) d'un message de validation ou d'invalidation en fonction de la condition et de l'information personnelle (PI).
[Revendication 10] Procédé de transaction électronique mis en uvre par un microprocesseur d'un terminal de paiement (1), associé à un compte bancaire acquéreur, destiné à coopérer avec un dispositif de paiement (3, 4) associé à
un compte bancaire d'un utilisateur, ledit procédé comportant une étape pour échanger au moins une clef cryptographique (500) avec le dispositif de paiement (3, 4), une étape de transaction (501) au cours de laquelle la 1.0 transaction est validée ou rejetée, caractérisée en ce que le terminal de paiement comporte au moins une politique de transaction (Pol(Pl)) comportant une condition relative à au moins une information personnelle (PI) relative à l'utilisateur du dispositif de paiement, en ce que le procédé
comporte une étape de vérification (510, 520, 530, 610, 620, 630) pour requérir la vérification de la condition de la politique de transaction relative à
l'information personnelle en utilisant la clef cryptographique, et en ce que l'étape de transaction est mise en oeuvre si et seulement si la condition est vérifiée.
[Revendication 11] Procédé selon la revendication 10 dans lequel, au cours de l'étape de vérification, le procédé comporte une étape pour recevoir (520) un message incluant l'information personnelle accompagnée d'une signature cryptographique (Sig(Pl)) réalisée à l'aide de l'information personnelle et de la clef cryptographique et une étape pour vérifier (530) la condition de la politique de transaction après avoir authentifié l'information personnelle à
l'aide de la clef cryptographique.
[Revendication 12] Procédé selon la revendication 10 ou 11, le procédé
comportant une étape pour élaborer et transmettre (510) une requête au dispositif de paiement afin d'obtenir l'information personnelle (PI).
[Revendication 13] Procédé selon la revendication 10 dans lequel, l'étape de vérification consiste à élaborer et transmettre (610) une requête de vérification de la politique de transaction (Pol(Pl)) au dispositif de paiement (3, 4), la requête étant signée à l'aide de la clef cryptographique.

[Revendication 14] Procédé selon l'une des revendications 10 à
13, le procédé comportant une étape pour modifier le montant de la transaction en fonction du résultat de la vérification de la condition préalablement à la validation de la transaction.
[Revendication 15] Système de transaction électronique comprenant un dispositif de paiement (3, 4) associé à un compte bancaire d'un utilisateur et terminal de paiement (1) associé à un compte bancaire acquéreur dans lequel le dispositif de paiement (3, 4) et le terminal de paiement (1) sont configurés pour réaliser un échange d'au moins une clef cryptographique (500) avant de réaliser une étape de transaction (501) au cours de laquelle la transaction est validée ou rejetée, caractérisée en ce que le dispositif de paiement (3,4) comporte au moins une information personnelle (PI) relative à l'utilisateur et le terminal de paiement (1) comporte au moins une politique de transaction (Pol(Pl)) comportant une condition relative à l'au moins une information personnelle (PI), et en ce que le dispositif et le terminal de paiement sont configurés pour réaliser une étape de vérification (510, 520, 530, 610, 620, 630) entre l'étape d'échange de clef cryptographique (500) et l'étape de transaction (501) au cours de laquelle la condition de la politique de transaction (Pol(Pl)) relative à l'information personnelle (PI) est vérifiée de manière sécurisée à l'aide de la clef cryptographique.
[Revendication 16] Système selon la revendication 15, dans lequel le dispositif de paiement (3, 4) est configuré pour transmettre au terminal de paiement (520) un message contenant l'information personnelle (PI) signé
(Sig(Pl)) à l'aide de l'information personnelle et de la clef cryptographique afin d'authentifier l'information personnelle (PI) et dans lequel le terminal de paiement (1) est configuré pour vérifier (530) la condition après avoir authentifier l'information personnelle à l'aide de la clef cryptographique.
[Revendication 17] Système selon la revendication 16, dans lequel le terminal de paiement est configuré pour élaborer et transmettre (510) une requête au dispositif de paiement afin d'obtenir l'information personnelle.
[Revendication 18] Système selon la revendication 15, dans lequel le terminal de paiement (1) est configuré pour élaborer et transmettre (610) au dispositif de paiement (3, 4) une requête de vérification de la condition de la politique de transaction (Pol(Pl)) signée à l'aide de la clef cryptographique et dans lequel le dispositif de paiement (3, 4) est configuré pour authentifier ladite requête à l'aide de la clef cryptographique avant de vérifier (620) la condition en réponse à la requête de vérification et pour renvoyer (630) un message de validation ou d'invalidation au terminal de paiement (1) en fonction de la condition et de l'information personnelle.
[Revendication 19] Système selon l'une des revendications 15 à
18, dans lequel le terminal de paiement (1) est configuré pour modifier le montant de la transaction en fonction du résultat de l'étape de vérification.
lo [Revendication 20] Dispositif de paiement (3, 4) associé à un compte bancaire d'un utilisateur destiné à coopérer avec un terminal de paiement (1) pour réaliser une transaction électronique, ledit dispositif de paiement (3, 4) étant configuré pour échanger au moins une clef cryptographique (500) avec le terminal de paiement (1), caractérisée en ce que le dispositif de paiement (3, 4) comporte au moins une information personnelle (PI) relative à
l'utilisateur, et en ce que le dispositif de paiement (3,4) est configuré pour réaliser une étape de vérification (510, 520, 530, 610, 620, 630) d'une condition d'une politique de transaction (Pol(Pl)) relative à l'information personnelle (PI) de manière sécurisée à l'aide de la clef cryptographique.
[Revendication 21] Dispositif selon la revendication 11, dans lequel le dispositif de paiement (3,4) est configuré pour envoyer au terminal de paiement (1) l'information personnelle (PI) dans un message signé (Sig(Pl)) à
l'aide de l'information personnelle (PI) et de la clef cryptographique afin d'authentifier l'information personnelle.
[Revendication 22] Dispositif selon la revendication 20, dans lequel le dispositif de paiement est configuré pour vérifier (620) la condition de la politique de transaction (Pol(Pl)) en réponse à la réception d'une requête de vérification contenant la condition, ladite requête étant signée et transmise par le terminal de paiement (1) à l'aide de la clef cryptographique, et pour élaborer et transmettre (630) un message de validation ou d'invalidation au terminal de paiement (1) en fonction de la condition et de l'information personnelle.

[Revendication 23] Dispositif selon l'une des revendications 20 à 22, dans lequel le dispositif de paiement (3,4) est un dispositif compris dans la liste suivante : carte à puce conforme à la norme IS07816 et/ou à la norme 14443, téléphone portable ou tablette comprenant une capacité de paiement sécurisé, montre intelligente comprenant des fonctionnalités de paiement, ordinateur sécurisé comprenant une interface de communication avec ou sans contact et comprenant une capacité de paiement sécurisé.
[Revendication 24] Terminal de paiement (1) associé à un compte bancaire acquéreur destiné à coopérer avec un dispositif de paiement (3,4) associé à
lo un compte bancaire d'un utilisateur pour réaliser une transaction électronique dans lequel le terminal de paiement (1) est configuré pour échanger au moins une clef cryptographique (500) avec le dispositif de paiement avant de mettre en oeuvre une étape de transaction (501) au cours de laquelle la transaction est validée ou rejetée, caractérisée en ce que le terminal de paiement (1) comporte au moins une politique de transaction (Pol(PI)) comprenant une condition relative à au moins une information personnelle (PI) enregistrée dans une mémoire du dispositif de paiement, ladite information personnelle (PI) étant relative à l'utilisateur, et en ce que le terminal de paiement (1) est configuré pour mettre en uvre une étape de vérification (510, 520, 530, 610, 620, 630), avant l'étape de transaction (501), au cours de laquelle la condition de la politique de transaction relative à l'information personnelle est vérifiée de manière sécurisée à l'aide de la clef cryptographique.
[Revendication 25] Terminal selon la revendication 24, dans lequel le terminal de paiement (1) est configuré pour recevoir un message contenant l'information personnelle (PI) signé (Sig(PI)) à l'aide de l'information personnelle et de la clef cryptographique par le dispositif de paiement et dans lequel le terminal de paiement (1) est configuré pour vérifier (530) la condition après avoir authentifier l'information personnelle à l'aide de la clef cryptographique.
[Revendication 26] Terminal selon la revendication 25, dans lequel le terminal de paiement (1) est configuré pour élaborer et transmettre (510) une requête au dispositif de paiement (3, 4) afin d'obtenir l'information personnelle (PI).

[Revendication 27] Terminal selon la revendication 24, dans lequel le terminal de paiement (1) est configuré pour élaborer et transmettre (610) au dispositif de paiement (3, 4) une requête de vérification de la condition de la politique de transaction (Pol(Pl)) signée à l'aide de la clef cryptographique, et dans lequel le terminal de paiement (1) est configuré pour terminer la transaction suite à un message de validation ou d'invalidation renvoyé par le dispositif de paiement en fonction de la condition et de l'information personnelle.
[Revendication 28] Terminal selon l'une des revendications 24 à
27, dans lequel le terminal de paiement (1) est configuré pour modifier le montant de la 1.0 transaction en fonction du résultat de l'étape de vérification.
[Revendication 29] Terminal selon l'une des revendications 24 à
28, dans lequel ledit terminal de paiement (1) est compris dans la liste de dispositifs suivante : terminal de point de vente pour carte à puce, téléphone portable ou tablette comprenant une capacité d'enregistrement de paiement sécurisé, caisse enregistreuse comprenant une capacité d'enregistrement de paiement sécurisé.
CA3161315A 2019-12-13 2020-12-11 Procede et systeme, dispositif et terminal de paiement utilisant des donnees personnelles Pending CA3161315A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FRFR1914352 2019-12-13
FR1914352A FR3104779B1 (fr) 2019-12-13 2019-12-13 Procede et systeme, dispositif et terminal de paiement utilisant des donnees personnelles
PCT/FR2020/052395 WO2021116625A1 (fr) 2019-12-13 2020-12-11 Procede et systeme, dispositif et terminal de paiement utilisant des donnees personnelles

Publications (1)

Publication Number Publication Date
CA3161315A1 true CA3161315A1 (fr) 2021-06-17

Family

ID=70456862

Family Applications (1)

Application Number Title Priority Date Filing Date
CA3161315A Pending CA3161315A1 (fr) 2019-12-13 2020-12-11 Procede et systeme, dispositif et terminal de paiement utilisant des donnees personnelles

Country Status (5)

Country Link
US (1) US20230004965A1 (fr)
EP (1) EP4074004A1 (fr)
CA (1) CA3161315A1 (fr)
FR (1) FR3104779B1 (fr)
WO (1) WO2021116625A1 (fr)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2681391A1 (fr) * 2007-02-09 2008-08-14 Business Intelligent Processing Systems, Plc Systeme et procede de realisation de transactions de paiement, de verification de l'age, de verification de l'identite et de gestion des taxes
FR3012645A1 (fr) * 2013-10-24 2015-05-01 Orange Procede d'execution d'une transaction entre un premier terminal et un deuxieme terminal

Also Published As

Publication number Publication date
WO2021116625A1 (fr) 2021-06-17
FR3104779B1 (fr) 2024-03-29
EP4074004A1 (fr) 2022-10-19
US20230004965A1 (en) 2023-01-05
FR3104779A1 (fr) 2021-06-18

Similar Documents

Publication Publication Date Title
EP2455922B1 (fr) Procédé et système de transaction NFC
EP2873045B1 (fr) Entite electronique securisee pour l'autorisation d'une transaction
EP2695353B1 (fr) Test de la résistance d'un module de sécurité d'un dispositif de télécommunication couple a un circuit nfc contre des attaques par détournement de canal de communication
CN106296174A (zh) 一种基于hce技术的小额支付卡装置及其实现方法
FR2964285A1 (fr) Protection d'un canal de communication d'un dispositif de telecommunication couple a un circuit nfc contre un deroutement
CA2946143C (fr) Procede de traitement de donnees transactionnelles, dispositif et programme correspondant
FR2757661A1 (fr) Procede de transfert securise de donnees par un reseau de communication
FR2923635A1 (fr) Systeme pour des transactions de commerce electronique, dispositif electronique portatif, reseau de communication, produit programme d'ordinateur et methode correspondants.
WO2007006771A1 (fr) Procede et dispositif d'autorisation de transaction
EP3234848A1 (fr) Procede d'envoi d'une information de securite et dispositif electronique apte a mettre en oeuvre un tel procede
EP1323140B1 (fr) Procede pour fournir des donnees d'identification d'une carte de paiement a un usager
CA3161315A1 (fr) Procede et systeme, dispositif et terminal de paiement utilisant des donnees personnelles
EP2824625B1 (fr) Méthode de réalisation de transaction, terminal et programme d'ordinateur correspondant
EP2075726A1 (fr) Outil utilisable pour l'authentification de documents, procédés d'utilisation de l'outil et de documents produits par le ou les procédés
EP1354288B1 (fr) Procede utilisant les cartes de paiement electroniques pour securiser les transactions
FR3057689A1 (fr) Procede et systeme de fourniture de jeton dans un systeme d'emulation de carte hote comportant un premier et un second dispositifs
EP3291188B1 (fr) Procédé de contrôle d'un dispositif électronique et dispositif électronique correspondant
WO2020128240A1 (fr) Traitement d'un service de tickets electroniques
EP3358493A1 (fr) Procédé pour la sécurité d'une opération électronique
FR2828966A1 (fr) Procede pour communiquer de facon securisee des donnees d'identification d'une carte de paiement
KR20060093196A (ko) 모바일 환전신청방법 및 시스템과 이를 위한 모바일 환전처리 서버 및 무선단말기와 기록매체
FR2967513A1 (fr) Serveur de transaction nfc