FR3123741A1 - procédé de traitement d’une transaction, dispositif et programme correspondant. - Google Patents
procédé de traitement d’une transaction, dispositif et programme correspondant. Download PDFInfo
- Publication number
- FR3123741A1 FR3123741A1 FR2105933A FR2105933A FR3123741A1 FR 3123741 A1 FR3123741 A1 FR 3123741A1 FR 2105933 A FR2105933 A FR 2105933A FR 2105933 A FR2105933 A FR 2105933A FR 3123741 A1 FR3123741 A1 FR 3123741A1
- Authority
- FR
- France
- Prior art keywords
- transaction
- user
- communication device
- dton
- terminal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000003672 processing method Methods 0.000 title 1
- 238000004891 communication Methods 0.000 claims abstract description 160
- 238000000034 method Methods 0.000 claims abstract description 46
- 238000010200 validation analysis Methods 0.000 claims description 79
- 230000005540 biological transmission Effects 0.000 claims description 30
- 230000015654 memory Effects 0.000 claims description 16
- 238000012795 verification Methods 0.000 claims description 10
- 230000006870 function Effects 0.000 claims description 9
- 238000004590 computer program Methods 0.000 claims description 6
- 230000004044 response Effects 0.000 claims description 3
- 230000003213 activating effect Effects 0.000 claims description 2
- 238000012545 processing Methods 0.000 description 26
- 238000002360 preparation method Methods 0.000 description 13
- 230000007246 mechanism Effects 0.000 description 7
- 238000002604 ultrasonography Methods 0.000 description 7
- 230000004913 activation Effects 0.000 description 6
- 230000036541 health Effects 0.000 description 6
- 230000008569 process Effects 0.000 description 6
- 230000008901 benefit Effects 0.000 description 5
- 238000012937 correction Methods 0.000 description 4
- 238000003780 insertion Methods 0.000 description 4
- 230000037431 insertion Effects 0.000 description 4
- 230000000977 initiatory effect Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000012790 confirmation Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 241001422033 Thestylus Species 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000013479 data entry Methods 0.000 description 1
- 238000013502 data validation Methods 0.000 description 1
- 239000000645 desinfectant Substances 0.000 description 1
- 238000010494 dissociation reaction Methods 0.000 description 1
- 230000005593 dissociations Effects 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 230000003203 everyday effect Effects 0.000 description 1
- 239000003999 initiator Substances 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 238000004377 microelectronic Methods 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000000053 physical method Methods 0.000 description 1
- 238000003860 storage Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/08—Access security
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Technology Law (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Debugging And Monitoring (AREA)
Abstract
L’invention se rapporte à un procédé d’exécution d’une transaction entre un terminal de mise en œuvre de transaction (TProf) et un dispositif de communication (Dton) qui est situé à proximité du terminal de mise en œuvre de transaction (TProf). Un tel procédé comprend une étape de préparation (A10) de la transaction à exécuter au sein terminal de mise en œuvre de transaction (TProf), délivrant un ensemble de données intermédiaires d’exécution de transaction ; une étape de transmission (A20) des données intermédiaires d’exécution de transaction au dispositif de communication (Dton) ; et une étape d’exécution (A30) de la transaction par le dispositif de communication (Dton) à l’aide de ladite au moins une donnée intermédiaire d’exécution de transaction et d’au moins une donnée personnelle (Sgn, PIN) de l’utilisateur qui détient le dispositif de communication (Dton), ladite exécution délivrant un résultat d’exécution transmis (A40) au terminal de mise en œuvre de transaction (TProf). Fig. 1.
Description
1. Domaine de l’invention
L’invention se rapporte au domaine de la sécurisation de traitements informatiques. Le domaine de l’invention concerne plus précisément à la sécurisation de traitement réalisés au moins en partie par l’intermédiaire de deux dispositifs informatiques distincts, possédés respectivement par deux entités également distinctes. L’invention vise plus particulièrement à sécuriser la mise en œuvre d’un traitement de données confidentielles, par exemple au cours d’une transaction menée entre un dispositif initiateur de la transaction et un dispositif d’exécution, au moins partielle, de la transaction. Les transactions visées par la présente peuvent être de divers types, comme par exemple des signatures électroniques, des validations d’accès, des transactions de paiement, des transactions de validation de données.
2. Art antérieur
Antérieurement, lorsqu’une transaction doit être menée pour un bénéficiaire (i.e. commerçant, notaire, etc.), qui souvent est un professionnel, ce bénéficiaire requiert l’utilisation, par une personne (souvent une personne physique), d’un terminal dédié à la transaction. Ce terminal est utilisé par la personne pour confirmer la transaction qui est menée, par exemple en apposant une signature sur ce terminal ou encore en saisissant un code secret, et ce, souvent, postérieurement à l’insertion, dans ce terminal dédié, d’un dispositif transactionnel possédé par l’utilisateur (carte de paiement, carte d’accès).
Cette manière de mettre en œuvre des transactions pose problème. D’une part elle pose un problème de sécurité des données traitées : il existe peu de terminaux réellement en mesure de garantir la sécurité des données fournies par l’utilisateur : tant celles fournies par le dispositif transactionnel (carte de paiement, carte d’accès) lorsque celui-ci est inséré dans le terminal du bénéficiaire professionnel, que celles saisies par l’utilisateur lui-même pour confirmer son autorisation ou son authentification, confirmation nécessaire à la mise en œuvre de la transaction. Parmi les terminaux qui garantissent cette sécurité on peut principalement penser aux terminaux de paiement conformes aux normes PCI.
Cependant, à cause notamment de la numérisation, tant de l’économie que des actions réalisées dans la vie courante, de plus en plus d’actes et de transactions sont réalisées sur des terminaux qui ne sont pas nécessairement sécurisés d’une part et qui à la base ne sont pas des terminaux prévus ou pensés pour réaliser de telles transactions d’autre part. Par exemple, pour la signature d’actes notariés, il est de plus en plus fréquent d’utiliser des signatures numérisées, effectuées par l’utilisateur sur une tablette de saisie (de type Wacom™ par exemple) directement connectée à l’ordinateur du notaire. De même, pour la livraison de colis, il est fréquent de devoir apposer sa signature sur un terminal du livreur pour valider la bonne réception du colis ou du pli qui est livré, et ce sans que l’utilisateur n’ait conscience ou connaissance du degré de sécurisation du terminal qui lui est présenté. Ceci est d’autant plus vrai que l’arrivée massive de terminaux à bas coûts, en provenance de pays de production peu regardant sur la qualité de fabrication ou de sécurisation (logicielle et matérielle) des terminaux vendus, expose de plus en plus de personnes à des tentatives de fraude, d’escroquerie de la part d’individus mal intentionnés : ces individus profitent de la faiblesse sécuritaire des terminaux en circulation pour y injecter des applications malveillantes, dans l’objectif d’obtenir des données personnelles ou confidentielles.
A ces problèmes de sécurité des données, on peut également ajouter les problèmes récents liés à la sécurité sanitaire : l’utilisation de dispositifs fournis par les bénéficiaires professionnels nécessitent que ces derniers mettent en place des protocoles pour assurer la sécurité des personnes. Ces protocoles sont souvent lourds et augmentent le temps nécessaire à la mise en œuvre de la transaction. Par exemple, dans le cas d’un notaire, celui-ci est obligé d’effectuer un nettoyage du stylet utilisé pour la signature avant utilisation par tout signataire. De même, le professionnel disposant d’un terminal de paiement, ou d’un terminal de signature pour la livraison de pli ou de colis, a théoriquement l’obligation d’appliquer une solution désinfectante sur le terminal entre chaque client. Dans les faits, ces obligations ne sont pas nécessairement remplies et elles ajoutent un sentiment d’insécurité sanitaire à la présence réelle d’une certaine insécurité de transaction, en fonction des situations rencontrées.
Il existe donc un besoin de fournir aux utilisateurs une méthode de réalisation de transaction qui permette de répondre aux problématiques posées, tout en assurant une sécurisation des données échangées.
Des solutions ont été proposées, notamment dans le domaine du paiement. Par exemple le document US10147094B2 poursuit l’objectif de proposer une méthode de paiement basée sur la connectivité d’un réseau de communication auquel un terminal de communication d’un utilisateur est connecté, pour permettre à cet utilisateur de valider une transaction en saisissant un code d’identification personnel associé à son terminal de communication. Le problème de cette méthode est qu’elle ne permet pas d’utiliser un moyen de paiement (e.g. carte de crédit) pour effectuer la transaction chez le professionnel (e.g. le commerçant). Le document US10127532B1, pour sa part, décrit une méthode de réalisation d’une transaction de paiement dans laquelle le terminal de communication de l’utilisateur est utilisé pour détecter une intention de paiement et mettre en œuvre la transaction. Cependant, cette méthode de réalisation de transaction est basée uniquement sur la capacité de l’utilisateur à vouloir engager une transaction de paiement.
Aucune de ces solutions cependant ne résout à la fois le problème de sécurisation de la mise en œuvre de la transaction du point de vue du professionnel bénéficiaire (notamment, pour reprendre l’exemple du paiement, pour que le commerçant personne physique s’assure que l’utilisateur dispose de la capacité à mener la transaction) tout en garantissant à cet utilisateur que le dispositif utilisé par le professionnel bénéficiaire n’est pas inutilement mis en connaissance de données confidentielles (e.g. signatures numérisées, codes confidentiels, etc.).
3. Résumé de l’invention
L’invention a été réalisée en tenant compte de ces problèmes de l’art antérieur. Plus particulièrement, la présente divulgation porte sur un procédé d’exécution d’une transaction entre un terminal de mise en œuvre de transaction d’un professionnel et un dispositif de communication d’utilisateur qui est situé à proximité du terminal de mise en œuvre de transaction du professionnel. Un tel procédé comprend une étape de préparation de la transaction à exécuter au sein terminal de mise en œuvre de transaction du professionnel, délivrant au moins une donnée intermédiaire d’exécution de transaction ; une étape de transmission de ladite au moins une donnée intermédiaire d’exécution de transaction au dispositif de communication d’utilisateur ; et une étape d’exécution de la transaction par le dispositif de communication d’utilisateur à l’aide de ladite au moins une donnée intermédiaire d’exécution de transaction et d’au moins une donnée personnelle de l’utilisateur qui détient le dispositif de communication d’utilisateur, ladite exécution délivrant un résultat d’exécution transmis au terminal de mise en œuvre de transaction d’un professionnel.
Ainsi, à la différence de l’art antérieur, le professionnel est en mesure de vérifier, lors de la construction, de la mise en œuvre et de l’exécution de la transaction, que l’utilisateur dispose de la capacité à et des moyens pour réaliser cette transaction. De son côté, l’utilisateur est en mesure de s’assurer que le terminal du professionnel n’entre pas en possession d’informations personnelles, notamment par exemple des signatures numérisées ou des mots de passe ou des codes confidentiels.
Selon une caractéristique particulière l’étape d’exécution de la transaction par le dispositif de communication d’utilisateur à l’aide de ladite au moins une donnée intermédiaire d’exécution de transaction et d’au moins une donnée personnelle de l’utilisateur qui détient le dispositif de communication d’utilisateur comprend une étape d’obtention, par le dispositif de communication d’utilisateur, d’au moins une donnée en provenance d’un dispositif transactionnel additionnel en possession de l’utilisateur.
Ainsi, l’utilisateur est en mesure d’utiliser sa carte de paiement directement sur son terminal de communication, devant le marchand, qui est en mesure de vérifier que son client effectue un paiement à l’aide de cette carte de paiement.
Selon une caractéristique particulière, l’étape d’obtention, par le dispositif de communication d’utilisateur, de ladite au moins une donnée en provenance du dispositif transactionnel additionnel en possession de l’utilisateur comprend :
- une étape d’émission, par le dispositif de communication d’utilisateur, d’une requête d’obtention de données transactionnelles, ladite étape d’émission utilisant une interface de communication en champs proche du dispositif de communication d’utilisateur ;
- une étape de réception, par le dispositif de communication d’utilisateur, d’une réponse à ladite requête d’obtention de données transactionnelles par l’intermédiaire de interface de communication en champs proche du dispositif de communication d’utilisateur.
Ainsi, le terminal de communication de l’utilisateur joue un rôle actif dans la mise en œuvre de la transaction, en requérant de lui-même les données transactionnelles.
Selon une caractéristique particulière l’étape d’exécution de la transaction par le dispositif de communication d’utilisateur à l’aide de ladite au moins une donnée intermédiaire d’exécution de transaction et d’au moins une donnée personnelle de l’utilisateur qui détient le dispositif de communication d’utilisateur comprend :
- une étape de réception de ladite au moins une donnée intermédiaire d’exécution de transaction par le dispositif de communication d’utilisateur ;
- une étape de configuration dynamique du dispositif de communication d’utilisateur, en fonction de ladite au moins une donnée intermédiaire d’exécution, ladite étape de étape de configuration dynamique comprenant une étape d’exécution, au sein d’un espace mémoire dédié dudit dispositif de communication d’utilisateur, d’une application de validation pour la saisie de la dite au moins une donnée personnelle de l’utilisateur qui détient le dispositif de communication d’utilisateur ;
- une étape de réception, par l’application de validation, d’au moins une donnée saisie par ledit utilisateur ;
- une étape de validation, par l’application de validation, de la transaction en fonction de ladite au moins une donnée saisie par ledit utilisateur et desdites données intermédiaires, délivrant un résultat de validation.
Ainsi, l’utilisateur est en mesure de saisir le code PIN de sa carte bancaire, directement sur son terminal de communication.
Selon une caractéristique particulière, postérieurement à l’étape de validation, par l’application de validation, de la transaction en fonction de ladite au moins une donnée saisie par ledit utilisateur et desdites données intermédiaires, le procédé comprend :
- une étape de transmission desdites données intermédiaires et dudit résultat de validation, à un serveur transactionnel auquel le dispositif de communication d’utilisateur est connecté par l’intermédiaire de l’application de validation,
- une étape de validation, par le serveur transactionnel, desdites données intermédiaires et dudit résultat de validation, comprenant une vérification des opérations cryptographiques de validation effectuées par ladite l’application de validation ;
- une étape de transmission, au terminal de mise en œuvre de transaction d’un professionnel, dudit résultat de validation de transaction, lorsque la vérification des opérations cryptographiques de validation délivre un résultat positif.
Ainsi, la transaction est traitée en toute sécurité, par exemple par l’intermédiaire du serveur bancaire correspondant à la banque de l’utilisateur ou de celui du commerçant, et cette transaction peut être immédiatement traitée, sans délai.
Selon une caractéristique particulière l’étape étape de préparation de la transaction à exécuter au sein terminal de mise en œuvre de transaction du professionnel comprend :
- une étape d’obtention, à partir d’un dispositif transactionnel additionnel en possession de l’utilisateur, d’au moins une clé de chiffrement destinée à être transmise au dispositif de communication d’utilisateur ; et
- une étape d’insertion, au sein de ladite au moins une donnée intermédiaire d’exécution, de ladite au moins une clé de chiffrement obtenue.
Ainsi, l’utilisateur peut également choisir d’insérer sa carte bancaire dans le terminal de paiement du commerçant, lorsque c’est possible. La saisie du code pin de la carte bancaire s’éffectuant tout de même sur le terminal de communication de l’utilisateur à partir de données de sa carte bancaires, transmises à partir du terminal de paiement du commerçant, ce qui est techniquement rassurant pour le commerçant.
Selon une caractéristique particulière l’étape de transmission de ladite au moins une donnée intermédiaire d’exécution de transaction au dispositif de communication d’utilisateur comprend :
- une étape d’activation d’une interface de communication du terminal de mise en œuvre de transaction d’un professionnel, pour la transmission par l’intermédiaire d’un canal principal ;
- une étape de transmission, par l’intermédiaire de l’interface de communication, d’un fichier comprenant ladite au moins une donnée intermédiaire.
Selon une caractéristique particulière l’interface de communication activée pour la transmission du fichier comprenant ladite au moins une donnée intermédiaire appartient au groupe comprenant :
- une interface sonore, configurée pour émettre le fichier préalablement encodé sous la forme d’un signal ultrasonore ;
- un écran du terminal de mise en œuvre de transaction d’un professionnel, configurée pour afficher le fichier préalablement encodé sous la forme d’un code bidimensionnel ;
- une interface de transmission de données par l’intermédiaire d’un réseau de communication, configurée pour transmettre le fichier préalablement encodé sous la forme d’un message.
Selon un autre aspect, l’invention se rapporte également à un système d’exécution d’une transaction, système comprenant un terminal de mise en œuvre de transaction d’un professionnel et un dispositif de communication d’utilisateur qui est situé à proximité du terminal de mise en œuvre de transaction du professionnel. Un tel système comprend des moyens de préparation de la transaction à exécuter implémentés au sein terminal de mise en œuvre de transaction du professionnel, délivrant au moins une donnée intermédiaire d’exécution de transaction ; des moyens de transmission de ladite au moins une donnée intermédiaire d’exécution de transaction au dispositif de communication d’utilisateur ; et des moyens d’exécution de la transaction implémentés au sein du dispositif de communication d’utilisateur à l’aide de ladite au moins une donnée intermédiaire d’exécution de transaction et d’au moins une donnée personnelle de l’utilisateur qui détient le dispositif de communication d’utilisateur, ladite exécution délivrant un résultat d’exécution et des moyens de transmission du résultat d’exécution au terminal de mise en œuvre de transaction d’un professionnel.
Selon une implémentation préférée, les différentes étapes des procédés selon l'invention sont mises en œuvre par un ou plusieurs logiciels ou programmes d'ordinateur, comprenant des instructions logicielles destinées à être exécutées par un processeur de données d'un dispositif d’exécution selon l'invention et étant conçu pour commander l'exécution des différentes étapes des procédés, mis en œuvre au niveau d’un terminal de communication, d’un dispositif électronique d’exécution et/ou d’un dispositif de contrôle, dans le cadre d’une répartition des traitements à effectuer et déterminés par un code source scripté et/ou un code compilé.
En conséquence, l’invention vise aussi des programmes, susceptibles d’être exécutés par un ordinateur ou par un processeur de données, ces programmes comportant des instructions pour commander l'exécution des étapes des procédés tel que mentionnés ci-dessus.
Un programme peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.
L’invention vise aussi un support d'informations lisible par un processeur de données, et comportant des instructions d'un programme tel que mentionné ci-dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un support mobile (carte mémoire) ou un disque dur ou un SSD.
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 exemple de réalisation, l'invention est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.
Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, set-top-box, routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.).
De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (firmware), etc.
Chaque composante du système précédemment décrit met bien entendu en œuvre ses propres modules logiciels.
Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en œuvre de l'invention.
4. Brève description des figures
D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante d’un exemple de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :
- la décrit un système dans lequel la divulgation peut être mise en œuvre ;
- la décrit le principe général de la méthode objet de la divulgation ;
- la illustre une architecture d’un terminal électronique professionnel apte à mettre en œuvre un procédé objet de la divulgation.
5. Description d’un exemple de réalisation
Comme indiqué précédemment, la divulgation décrit une méthode consistant à requérir, auprès d’un dispositif de communication d’un utilisateur, la mise en œuvre au moins partielle d’une transaction qui doit être menée pour le compte d’un initiateur (il peut s’agir d’un commerçant, d’un notaire, d’un livreur, d’un dispositif de validation d’accès, etc.), qui dispose ou implémente un dispositif de communication d’utilisateur (dispositif de paiement, dispositif de signature, terminal de contrôle d’accès, etc.), considéré pour diverses raisons comme impliquant une problématique de sécurité. En d’autres termes, il est proposé une technique de dissociation d’exécution de transaction : la transaction est initialisée sur un terminal d’un professionnel et est complétée (exécutée, finalisée) sur un terminal d’un utilisateur, pour que celui-ci puisse saisir, en toute sécurité, les données confidentielles permettant de valider cette transaction.
Ainsi, afin de permettre au professionnel de s’assurer de la capacité de l’utilisateur à effectuer la transaction tout en permettant à l’utilisateur de ne pas fournir au professionnel des données personnelles et/ou confidentielles, la méthode consiste à mettre à contribution un terminal de communication de l’utilisateur (typiquement son terminal de communication mobile de type smartphone ou tablette) pour exécuter une portion de la transaction initiée par le terminal du professionnel. Pour ce faire, selon la présente divulgation, le terminal du professionnel transmet au terminal de l’utilisateur, des données particulières, permettant au terminal utilisateur de poursuivre l’exécution de la transaction. Cette poursuite de l’exécution de la transaction peut consister en une validation de celle-ci (par exemple en effectuant une opération de signature et/ou une ou plusieurs opérations cryptographiques), ou bien encore en une vérification de validation de données confidentielles.
Quoi qu’il en soit, le problème principal dans la modification protocolaire proposée, consiste notamment : à assurer la sécurité des données échangées (afin d’éviter leur interception) ; à assurer la non répudiation des données échangées (afin d’éviter toute modification non souhaitée, tant du côté du terminal du professionnel que du terminal d’utilisateur). En effet, il est indispensable que la modification protocolaire n’induise pas de faille de sécurité permettant de modifier la transaction.
La décrit un système dans lequel la technique proposée peut être mise en œuvre. Un tel système (SystET) comprend un terminal d’un professionnel (TProf), le terminal du professionnel comprenant des moyens d’exécution de transaction. Un tel terminal (TProf) est décrit en relation avec la . Un tel système comprend également un dispositif de communication d’utilisateur (DTon), dispositif physique appartenant à un utilisateur, et prenant généralement la forme d’une tablette ou d’un smartphone, ce dispositif étant portable et à dispositif de l’utilisateur lorsqu’il se trouve physiquement chez ou en présence du professionnel qui utilise le terminal de professionnel (TProf). Ce système peut également comprendre, en fonction des réalisations, un serveur transactionnel (ServT). Le serveur transactionnel est dans ce cas à minima accessible par l’intermédiaire d’un réseau de communication pour le terminal de professionnel (TProf) et/ou le dispositif de communication d’utilisateur (DTon). En fonction des modes de réalisation, le système comprend également un dispositif transactionnel additionnel (DTa) (carte d’accès, carte de crédit) notamment lorsque la mise en œuvre de la transaction nécessite l’utilisation d’un tel dispositif transactionnel additionnel (transaction pour accéder à des locaux, transaction de paiement par carte bancaire, carte de crédit).
La décrit le principe général de la méthode objet de la divulgation. Plus particulièrement, la méthode de réalisation de transaction comprend :
- une étape de préparation (A10) de la transaction, mise en œuvre au sein du terminal du professionnel (TProf) ; cette étape de préparation de la transaction comprend, notamment l’obtention d’un identifiant (unique) du terminal du professionnel ; cet identifiant unique sert de base à l’initialisation de la transaction (il est stocké/obtenu au sein du terminal du professionnel (TProf), ou transmis au terminal du professionnel (TProf) par l’intermédiaire du serveur transactionnel (ServT)) ; cette étape de préparation de la transaction peut également comprendre l’obtention de données en provenance d’un dispositif transactionnel additionnel (DTa) lorsqu’un tel dispositif est nécessaire à la réalisation de la transaction (cette étape d’obtention de données comprend par exemple l’insertion d’une carte en possession de l’utilisateur dans le terminal du professionnel ou bien l’obtention de données sans contact entre cette carte en possession de l’utilisateur et le terminal du professionnel) ; la préparation de la transaction peut comprendre également la génération d’un (pré)identifiant unique de transaction, permettant de tracer et localiser celle-ci ; l’ensemble {« identifiant (unique) du terminal du professionnel » ; « (pré)identifiant unique de transaction »} forme des données intermédiaires (IntDat) ; elles peuvent être sécurisées par l’intermédiaire d’un chiffrement ; la préparation de la transaction comprend également, en fonction de la mise en œuvre opérationnelle, d’autres étapes, comme exposé dans les modes de réalisation par la suite, pouvant comprendre la mise en œuvre d’autres données à transmettre au dispositif de communication d’utilisateur (DTon), ces autres données étant ajoutées à l’ensemble des données intermédiaires (IntDat) ; les données intermédiaires (IntDat) peuvent être reçues, par le dispositif de communication d’utilisateur (DTon), soit de la part du terminal de professionnel (TProf) ou par l’intermédiaire du serveur transactionnel (ServT) ;
- une fois la transaction préparée (à divers degrés, en fonction de la mise en œuvre opérationnelle), le dispositif de communication d’utilisateur (DTon) de l’utilisateur est dynamiquement configuré (A20), à l’aide de l’ensemble des données intermédiaires (IntDat), reçues sur le dispositif de communication d’utilisateur (DTon) de l’utilisateur ;
- pour ensuite valider (A30) cette transaction (e.g. exécuter/clôturer celle-ci) ; la validation de la transaction comprend, pour l’utilisateur, l’interaction avec une application de validation de transaction AppVT installée sur son terminal : cette interaction peut comprendre notamment, la saisie d’une ou de plusieurs données confidentielles sur l’application de validation de la transaction (signature numérisée Sgn, code confidentiel PIN, etc.) et/ou l’utilisation sur le dispositif de communication d’utilisateur (DTon), du dispositif transactionnel additionnel (DTa) pour obtenir des données en provenance de celui-ci, lorsqu’un tel dispositif est nécessaire à la réalisation de la transaction (que ce dispositif transactionnel additionnel (DTa), lorsqu’un tel dispositif est nécessaire à la réalisation de la transaction, ait été ou non utilisé pour préparer la transaction) ; l’application de validation de transaction AppVT installée sur le terminal est préférentiellement exécutée dans un espace sécurisé de la mémoire du dispositif de communication d’utilisateur (DTon) et préférentiellement, cette application est téléchargée à partir d’un réseau de communication uniquement sur demande, en fonction des données intermédiaires reçues (i.e. les données intermédiaires reçues déterminent au moins en partie la configuration et l’exécution de l’application de validation de transaction AppVT) et est exécutée immédiatement après téléchargement dans la mémoire vive du dispositif de communication d’utilisateur (DTon) ; selon une variante, lorsque l’application de validation de transaction AppVT est déjà présente (pré-téléchargée par l’utilisateur), celle-ci est configurée en fonction des données intermédiaires reçues ; préférentiellement, cette application de validation de transaction AppVT bloque l’utilisation du dispositif de communication d’utilisateur (DTon) en obtenant un accès exclusif aux ressources d’exécution du dispositif de communication d’utilisateur (DTon) et limite l’utilisation de celui-ci à des saisie sur l’écran tactile et optionnellement, à l’obtention de données par l’intermédiaire d’une interface de communication en champs proches, lorsqu’une telle interface est nécessaire à l’exécution (validation) de la transaction ; la configuration de l’application de validation de transaction AppVT est effectuée en fonction des données intermédiaire reçues : les données intermédiaires permettent de construire une structure de données chargée en mémoire vive qui contraint l’exécution de l’application de validation de transaction, notamment en termes d’interfaces de communication à utiliser (ultrasonore, caméra, champs proche, WAN, WLAN) : le fonctionnement de l’application est simple et direct et permet la saisie, la validation, la correction et l’annulation – l’annulation par exemple provoque la fermeture de l’application et la déchargement des données de la mémoire vive ; l’application de validation de transaction AppVT est construite par le fabricant du terminal de professionnel (TProf) (ou un affilié ou un partenaire) pour répondre aux besoins spécifiques de validation que ce fabricant souhaite adresser : l’application ne sera bien entendu pas la même pour une validation de réception de colis ou pour une validation de transaction d’accès ou une transaction de paiement ; L’application met en œuvre des opération cryptographiques (qui sont décrites par la suite) et notamment un chiffrement des données saisies par l’utilisateur en fonction des données intermédiaires (qui peuvent comprendre des clés de chiffrement) ou en fonction des clés contenues dans la configuration de l’application lorsque celle-ci est téléchargée et exécutée à la volée par le terminal de communication.
- Une fois la transaction validée, le dispositif de communication d’utilisateur (DTon) de l’utilisateur communique (A40) cette information de validation (InfoVal) au terminal du professionnel (TProf), soit directement, en transmettant une donnée de validation en ce sens à celui-ci, soit indirectement, par l’intermédiaire du serveur transactionnel (ServT) qui se charge de communiquer ensuite la donnée de validation au terminal du professionnel. Lorsqu’un serveur transactionnel est utilisé (ce qui n’a pas de caractère obligatoire), la validation comprend une étape de transmission des données intermédiaires et du résultat de validation, au serveur transactionnel auquel le dispositif de communication d’utilisateur (Dton) est connecté par l’intermédiaire de l’application de validation (AppVT), puis une étape de validation, par le serveur transactionnel, des données intermédiaires et du résultat de validation, comprenant une vérification des opérations cryptographiques de validation effectuées par ladite l’application de validation (AppVT) et une étape de transmission, au terminal de mise en œuvre de transaction d’un professionnel (TProf), du résultat de validation de transaction, lorsque la vérification des opérations cryptographiques de validation délivre un résultat positif.
Ces quatre étapes, mises en œuvre de façon ordonnée au sein du système présenté en , permettent d’assurer à la fois la sécurité des données saisies par l’utilisateur (ces données ne sont pas fournies en tant que telles au professionnel), tout en assurant au professionnel, présent au moment de la mise en œuvre de ces étapes, que l’utilisateur est bien en capacité de réaliser cette transaction (i.e. qu’il possède la capacité de le faire et éventuellement les outils nécessaires, i.e. le du dispositif transactionnel additionnel (DTa)). De plus, dans un contexte sanitaire sensible, cette mise en œuvre permet d’éviter à l’utilisateur d’entrer en contact avec le matériel du professionnel.
On présente, en relation avec la , une architecture simplifiée d’un terminal électronique de professionnel (TProf) apte à effectuer le traitement d’initiation de transaction tel que présenté précédemment. Un terminal électronique de professionnel comprend un premier module électronique comprenant une mémoire 31, une unité de traitement 32 équipée par exemple d’un microprocesseur, et pilotée par un programme d’ordinateur 33. Le terminal électronique de professionnel peut comprendre également un deuxième module électronique comprenant une mémoire sécurisée 34, qui peut être fusionnée avec la mémoire 31 (comme indiqué en pointillés, dans ce cas la mémoire 31 est une mémoire sécurisée), une unité de traitement sécurisée 35 équipée par exemple d’un microprocesseur sécurisée et de mesure physiques de protection (protection physique autour de la puce, par treillis, vias, etc. et protection sur les interfaces de transmission de données), et pilotée par un programme d’ordinateur 36 spécifiquement dédié à cette unité de traitement sécurisée 35, ce programme d’ordinateur 36 mettant en œuvre toute ou partie du procédé de traitement d’une transaction tel que précédemment décrit. Le groupe composé de l’unité de traitement sécurisée 35, de la mémoire sécurisée 34 et du programme d’ordinateur dédié 36 constitue le module sécurisé (PS) du dispositif électronique. Dans au moins un exemple de réalisation, la présente technique est mise en œuvre sous la forme d’un ensemble de programmes installé en partie ou en totalité sur cette portion sécurisée du terminal de traitement ou d’initialisation de transaction. Dans au moins un autre exemple de réalisation, la présente technique est mise en œuvre sous la forme d’un composant dédié (CpX) pouvant traiter des données des unités de traitement et installé en partie ou en totalité sur la portion sécurisée du terminal électronique de professionnel. Par ailleurs, le terminal électronique de professionnel comprend également des moyens de communication (CIE) se présentant par exemple sous la forme de composants réseaux (WiFi, 3G/4G/5G, filaire) qui permettent au terminal électronique de professionnel de recevoir des données (I) en provenance d’entités connectées à un ou plusieurs réseaux de communication et des transmettre des données traitées (T) à de telles entités.
Un tel terminal électronique de professionnel comprend, en fonction des modes de réalisation :
- des moyens d’obtention de données en provenance de dispositifs transactionnels présentés des utilisateurs (carte d’accès, carte de transaction, etc. ; ces moyens peuvent se présenter, par exemple, sous la forme de lecteur de cartes à puces, ou encore de lecteurs de cartes sans contact de type NFC ou de type RFID) ;
- des moyens de saisie, permettant au professionnel de saisir une ou plusieurs données pour la mise en œuvre de la transaction, lorsque cela est nécessaire (clavier de saisie physique, écran, clavier de saisie virtuel) ;
- des moyens de traitement des données obtenues par les moyens d’obtention de données en provenance des dispositifs transactionnels et des moyens de traitement des données saisies par le professionnel ; ces moyens sont matérialisés par exemple sous la forme d’un composant spécifique ;
- des moyens de traitement d’une transaction, comprenant des moyens d’initialisation de transaction ;
- des moyens de fourniture de données à un ou plusieurs serveurs transactionnels connectés au terminal électronique de professionnel : ces moyens se présentent typiquement sous la forme d’interfaces de communication réseau, de type interface filaire (RTC, Ethernet) ou interface sans fil (3G/4G, Wifi) ;
- des moyens de fourniture de données à un dispositif de mise en œuvre de transaction, appartenant à un utilisateur (e.g. smartphone, tablette) : ces moyens de fourniture de données peuvent se présenter, par exemple, sous la forme d’un écran, sur lequel ces données sont affichées, ou encore d’un composant d’émission d’ultrasons (buzzer ultrasonore), ou encore d’un composant d’émission de données radio en champ proche ;
Comme explicité précédemment, ces moyens sont mis en œuvre par l’intermédiaire de modules et/ou de composants, par exemple, mais non nécessairement sécurisés. Ils permettent ainsi d’assurer la sécurité des transactions réalisées tout en garantissant une plus grande maintenabilité du dispositif.
Le dispositif de communication d’utilisateur (DTon), pour sa part, se présente généralement comme un terminal de communication de type mobile (i.e. smartphone, tablette) qui est en possession de l’utilisateur au moment de la réalisation de la transaction en présence du professionnel. Un tel dispositif comprend outre les moyens usuels, des moyens de mise en œuvre de transaction, selon le procédé précédemment décrit. Ces moyens se présentent sous la forme d’une application exécutée sur le terminal, lui conférant la qualité de dispositif de communication d’utilisateur (DTon). Dans un exemple de réalisation particulier, cette application est une application configurée dynamiquement sur le terminal de l’utilisateur. Plus particulièrement, cette application est configurée dynamiquement à la réception, sur le dispositif de mise en œuvre de transaction, des données intermédiaires comprenant l’identifiant unique du terminal du professionnel et le (pré)identifiant unique de transaction et ; lorsque nécessaire, une donnée d’instanciation. A réception de ces données, l’application est dynamiquement configurée et exécutée. Elle affiche, à destination de l’utilisateur, les données relatives à la transaction (comme par exemple un identifiant ou un nom du professionnel concerné ou autre comme décrit dans les modes de réalisation suivants).
Plusieurs exemples de réalisation de la méthode objet de la divulgation sont décrits par la suite
Exemple de réalisation 1 : livraison d’un colis par un livreur
On décrit, dans cet exemple de réalisation, l‘exécution d’une transaction dissociée dans le cadre d’une livraison d’un colis réalisée par un livreur (professionnel) chez un particulier (utilisateur). Le livreur est équipé d’un terminal électronique de livraison (il s’agit du terminal du professionnel). Dans cet exemple de réalisation, une fois les étapes administratives effectuées (i.e. vérification de l’identité de l’utilisateur par le livreur, notamment, inspection de l’état du colis par l’utilisateur), le processus de traitement de transaction dissociée est mis en œuvre, selon les étapes précédemment décrites en relation avec la .
Plus particulièrement, dans cet exemple de réalisation :
- la préparation de la transaction par le terminal du professionnel (livreur) comprend l’obtention de l’identifiant du terminal au sein d’une mémoire de ce terminal du professionnel et la préparation, par le processeur de traitement, d’un identifiant de transaction ; En plus, une donnée représentative d’une adresse de localisation (sur le réseau de communication ou dans une boutique applicative) d’une application instantanée à instancier sur le dispositif de communication d’utilisateur (i.e. le terminal mobile ou la tablette) de l’utilisateur est obtenue, par exemple au sein de la mémoire du terminal du professionnel, formant l’ensemble des données intermédiaires ; Une étape de protection d’au moins certaines de ces données est mise en œuvre : l’identifiant du terminal et l’identifiant de transaction sont chiffrés ; À partir de l’ensemble des données intermédiaires, un fichier de transmission de ces données est construit ; le fichier de transmission de ces données peut prendre la forme : d’un fichier image, comprenant un QR Code ou encre d’une séquence ultrasonore modulée ; Le fichier image est affiché sur le terminal du professionnel ; la séquence ultrasonore est émise à partir du terminal du professionnel (on note que ces deux formes de transmission de l’information au dispositif de communication d’utilisateur peuvent être mise en œuvre simultanément) ; La préparation de la transaction est ainsi finalisée ; Dans cet exemple de réalisation, le QR-Code ou la séquence ultrasonore modulée représente le canal de transmission principal des données intermédiaires ;
- Le dispositif de communication d’utilisateur (le terminal mobile ou la tablette) de l’utilisateur reçoit le fichier des données intermédiaires en provenance du terminal du professionnel (soit par lecture du QR-Code, soit par réception de la séquence ultrasonore) ; Les données sont décodées (en fonction du format de codage de données utilisé) et le dispositif de communication d’utilisateur (DTon) de l’utilisateur est configuré (configuration dynamique) : une requête est transmise par le dispositif de l’utilisateur à l’adresse de localisation d’une application instantanée avec en paramètre les données identifiant du terminal du professionnel et identifiant de transaction ; l’application instantanée est immédiatement téléchargée et exécutée sur le dispositif de communication d’utilisateur (DTon) ; Cette application instantanée affiche une interface utilisateur comprenant : les informations relatives au colis, obtenues à partir d’un serveur transactionnel (ServT) de la société de livraison (ou d’un autre serveur transactionnel) et une zone de signature (permettant à l’utilisateur de signer avec le doigt ou avec un stylet sur l’écran tactile de son terminal) et un triplet de boutons (« annulation », « correction », « validation ») ; Ceci achève la fin de la configuration dynamique du dispositif d’utilisateur ;
- S’ensuit l’étape de validation de la transaction, consistant pour l’utilisateur à effectuer sa signature sur l’écran de son dispositif (avec un doigt ou avec un stylet), puis à valider cette saisie en sélectionnant le bouton « validation » ; Un message est affiché à destination de l’utilisateur pour l’informer la saisie ;
- Une fois cette saisie/validation effectuée par l’utilisateur, l’application instantanée effectue une validation de la transaction en calculant un hachage de la signature de l’utilisateur, en codant l’image de la signature à l’aide d’une clé, obtenue par exemple à partir du hachage réalisé, puis en ajoutant ces données (hash de la signature, image de la signature) aux données intermédiaires ; L’ensemble des données résultantes est transmis au serveur transactionnel (ServT), et l’application instantanée est désinstallée ; Le serveur transactionnel (ServT) réceptionne les données transmises par l’application instantanée et transmet un message à destination du terminal du livreur l’informant de la validation de la transaction.
Ainsi, grâce à cette mise en œuvre, l’utilisateur a été en mesure de réceptionner son colis, tout en évitant d’une part de saisir des informations sensibles sur le terminal du professionnel et d’autre part en sécurisant la transmission de ces données, par voie de chiffrement notamment, au serveur transactionnel. L’utilisateur n’a pas non plus eu besoin d’entrer en contact physique avec le terminal du professionnel, préservant la sécurité sanitaire. Également, aucune application n’est définitivement installée sur le dispositif de l’utilisateur, l’application instantanée résidant uniquement en mémoire volatile du dispositif de l’utilisateur.
Exemple de réalisation 2 : accès à des locaux protégés par un terminal d’accès
On décrit, dans cet exemple de réalisation, l‘exécution d’une transaction dissociée dans le cadre d’un accès à des locaux protégés, par l’intermédiaire d’un terminal d’accès (terminal du professionnel) à carte, par une personne souhaitant accéder à ces locaux (utilisateur). Le terminal du professionnel est équipé d’un lecteur de cartes à puce, qui est utilisé par l’utilisateur pour accéder aux locaux. Le terminal d’accès peut être connecté à un réseau de communication (par exemple un réseau mobile) et il dispose de données relatives à l’utilisateur (notamment un numéro de téléphone, qu’il peut utiliser pour transférer une notification au terminal de l’utilisateur).
Le processus de traitement de transaction dissociée est mis en œuvre, selon les étapes précédemment décrites en relation avec la , postérieurement à la demande d’accès aux locaux formulée par l’utilisateur (par exemple en insérant sa carte d’accès dans le lecteur du terminal d’accès, ou bien par tout moyen utilisable sur le terminal d’accès, comme un bouton physique par exemple) :
- la préparation de la transaction par le terminal d’accès comprend l’obtention de l’identifiant du terminal d’accès au sein d’une mémoire de ce terminal et la préparation, par le processeur de traitement, d’un identifiant de transaction ; En plus, si n’est déjà fait, un message d’insertion de carte d’accès est affiché à destination de l’utilisateur ; celui-ci insère alors sa carte d’accès au sein du lecteur de cartes à puce ; la préparation de la transaction se poursuit alors par une interrogation de la carte d’accès par le terminal d’accès, afin d’obtenir une clé publique de la carte d’accès notamment ; cette clé publique est insérée dans l’ensemble de données intermédiaires ; l’ensemble de données intermédiaires, après d’éventuelles opérations de contrôles complémentaires (notamment contrôle de la validité de la carte d’accès), est alors chiffré en utilisant une clé privée du terminal d’accès ; un fichier de transmission de ces données intermédiaires chiffrées est construit, et le fichier est transmis au terminal de l’utilisateur par l’intermédiaire du réseau de communication auquel le terminal d’accès est connecté ; Dans cet exemple de réalisation, le réseau de communication représente le canal de transmission principal des données intermédiaires ;
- le dispositif DTon de l’utilisateur reçoit le fichier des données intermédiaires en provenance du terminal d’accès, par exemple par l’intermédiaire d’un SMS ou d’un autre message transmis sur le réseau de communication ; Les données du fichier sont déchiffrées à l’aide de la clé publique du terminal d’accès (cette clé publique a été transmise au dispositif Dton par ailleurs, comme explicité plus loin) et le dispositif de communication d’utilisateur (DTon) de l’utilisateur est dynamiquement configuré : une application de saisie de code PIN, avec en paramètre les données identifiant du terminal du terminal d’accès et identifiant de transaction est exécutée sur le dispositif de communication d’utilisateur (DTon) ; Cette application affiche une interface utilisateur de saisie de code PIN comprenant : les informations relatives à l’accès, obtenues à partir des données intermédiaires et une zone de saisie de code PIN (permettant à l’utilisateur de saisir le code confidentiel de la carte d’accès qu’il a inséré dans le terminal d’accès) et un triplet de boutons (« annulation », « correction », « validation ») ; Cette application de saisie est par exemple préinstallée par l’utilisateur ou bien disponible nativement sur le dispositif de communication d’utilisateur (DTon) ; Ceci achève la configuration dynamique du dispositif d’utilisateur ;
- S’ensuit l’étape de validation de la transaction, consistant pour l’utilisateur à effectuer la saisie du code PIN sur l’écran de son dispositif, puis à valider cette saisie en sélectionnant le bouton « validation » ; Un message est affiché à destination de l’utilisateur pour l’informer la saisie ;
- Une fois cette saisie/validation effectuée par l’utilisateur, l’application effectue une validation de la transaction en effectuant une opération de chiffrement du code PIN saisi à l’aide de la clé publique de la carte présente dans les données intermédiaires reçues ; ce PIN chiffré est ajouté aux données intermédiaires déchiffrées initialement reçues et un chiffrement de l’ensemble est ensuite réalisé avec la clé publique du terminal d’accès ; L’ensemble des données résultantes est transmis au terminal d’accès par exemple par l’intermédiaire d’un message de type SMS, et l’application de saisie de code PIN est arrêtée ;
- Le terminal d’accès réceptionne les données transmises par l’application, les déchiffre à l’aide de sa clé privée, vérifie que les données intermédiaire sont correctes et transmet le code PIN chiffré à la carte à puce insérée dans le lecteur de cartes à puce du terminal d’accès ; la carte à puce de l’utilisateur déchiffre le code PIN à l’aide de sa clé privée et vérifie la validité de celui-ci : si le code PIN saisi est valide, la carte à puce peut former un certificat à destination du terminal d’accès en réponse à la requête de validation ; le terminal d’accès réceptionne ce certificat le vérifie et autorise l’accès aux locaux.
Ainsi, grâce à cette mise en œuvre, l’utilisateur a été en mesure d’accéder aux locaux protégés par le terminal d’accès, tout en évitant d’une part de saisir des informations sensibles sur le terminal d’accès lui-même et d’autre part en sécurisant la transmission de ces données, par voie de chiffrement notamment, au terminal d’accès. L’utilisateur n’a pas non plus eu besoin d’entrer en contact physique avec le terminal d’accès, préservant la sécurité sanitaire.
Pour cette mise en œuvre, on suppose que le terminal de l’utilisateur dispose de la clé publique du terminal d’accès, clé qui lui est communiquée séparément. Pour ce faire, plusieurs variantes sont envisagées. Une première variante consiste à installer la clé publique du terminal d’accès lors de la configuration du terminal de communication de l’utilisateur : cette configuration peut être réalisée par l’autorité qui gère l’accès aux locaux protégés par le terminal d’accès. Cette clé publique peut être inscrite au sein d’un certificat qui est installé dans une zone mémoire protégée du terminal de communication de l’utilisateur. L’avantage de cette mise en œuvre est qu’elle permet, pour l’autorité qui gère l’accès aux locaux protégés, d’assurer que chaque terminal d’utilisateur est identifié et que la clé publique du terminal d’accès ne circule pas inutilement.
Une deuxième variante consiste à diffuser la clé publique du terminal d’accès au moment de la mise en œuvre de la transaction dissociée. Dans ce cas de figure, la clé publique du terminal d’accès est transmise au terminal de communication de l’utilisateur en utilisant un canal de transmission différent de celui utilisé pour la transmission des données intermédiaires. Ce canal de transmission est appelé canal auxiliaire et il est utilisé pour sécuriser la transmission de cette clé publique. Ce canal de transmission auxiliaire peut typiquement prendre la forme d’un signal ultrasonore modulé, le signal codant un enregistrement de données comprenant d’une part la clé publique du terminal d’accès (cette clé publique peut être une clé de session, temporaire) et d’autre part une donnée de vérification de conformité. Dans cette deuxième variante, le procédé de transmission de cette clé publique est la suivant : lorsque l’utilisateur insère sa carte d’accès dans le lecteur de carte du terminal d’accès, le terminal d’accès, lors l’étape de préparation de la transaction, diffuse, en utilisant le canal auxiliaire (i.e. par voie ultrasonore), l’enregistrement de données comprenant la clé publique du terminal d’accès. Cette diffusion n’est réalisée qu’après l’insertion de la carte d’accès dans le lecteur du terminal d’accès et que le terminal d’accès a vérifié la validité de cette carte d’accès (par exemple qu’elle ne fait pas partie d’une liste de cartes bannies, ou qu’elle n’est pas désactivée – trop ancienne). Le terminal de communication de l’utilisateur capte cette diffusion et acquiert l’enregistrement de données comprenant la clé publique du terminal d’accès et la donnée de vérification de conformité. Cette diffusion, par le terminal d’accès, peut être cyclique (c’est-à-dire être répétée), jusqu’à la transmission, par le terminal d’accès, des données intermédiaires de la transaction au terminal de communication de l’utilisateur (par l’intermédiaire du canal principal, i.e. SMS ou autre type de transmission sur le réseau de communication). L’avantage de cette mise en œuvre est qu’elle permet au terminal d’accès de définir des clés temporaires dont l’usage est limité à une seule transaction : en effet, la clé publique du terminal est alors une clé de session et la clé privée correspondante est également une clé de session. Qui plus est, la transmission de cette clé n’étant initiée qu’à partir du moment ou la carte d’accès de l’utilisateur est insérée dans le lecteur du terminal d’accès, cette clé peut être spécifiquement dédiée à la carte d’accès de l’utilisateur.
En fonction des variantes de réalisation, il peut être envisagé d’inverser les rôles des canaux de communication : le canal principal peut être le canal ultrasonore, utilisé pour transmettre les données intermédiaires de transaction et le canal secondaire peut être le réseau de communication, utilisé pour transmettre la clé publique du terminal d’accès.
Exemple de réalisation 3 : paiement à l’aide d’un terminal de paiement
On décrit, dans cet exemple de réalisation, l‘exécution d’une transaction dissociée dans le cadre d’un paiement, par l’intermédiaire d’un terminal de paiement (terminal du professionnel) à carte, par une personne souhaitant effectuer un paiement de biens ou de services (utilisateur) chez un commerçant. Le terminal du professionnel (terminal de paiement) est généralement équipé d’un lecteur de cartes à puce, dont l’utilisation n’est pas nécessaire dans le cadre de cet exemple de réalisation. Le terminal de paiement est connecté à un réseau de communication (par exemple un réseau mobile ou le réseau de communication du commerce, e.g. réseau Wifi, Ethernet) et il peut disposer de données relatives à l’utilisateur (notamment un numéro de téléphone, dans le cadre d’un compte de fidélité par exemple). En fonction des variantes, l’insertion de la carte de paiement de l’utilisateur dans le terminal de paiement peut être requise : auquel cas, les traitements mis en œuvre sont identiques au deuxième exemple de réalisation et la puce de la carte de paiement est utilisée dans le lecteur de cartes à puce du terminal de paiement pour effectuer une transaction de paiement à la place d’une transaction d’accès. Dans ce troisième exemple de réalisation, l’insertion de la carte de paiement dans le terminal de paiement n’est pas nécessaire : la carte de paiement est utilisée par le terminal de communication de l’utilisateur DTon, comme cela est décrit par la suite.
Le processus de traitement de transaction dissociée est mis en œuvre, selon les étapes précédemment décrites en relation avec la , postérieurement à la demande de paiement formulée par le commerçant (par exemple en requérant le paiement des biens ou des services à l’utilisateur) :
- la préparation de la transaction par le terminal de paiement comprend l’obtention de l’identifiant du terminal de paiement (au sein d’une mémoire de ce terminal ou par l’intermédiaire du serveur transactionnel auquel le terminal de paiement est connecté, décrit par la suite) et la préparation, par le processeur de traitement sécurisé du terminal de paiement, d’un identifiant de transaction ; la préparation de la transaction comprend également l’ajout, aux données intermédiaires, des données de montant des achats, date, heure, etc. ; l’ensemble de données intermédiaires, après d’éventuelles opérations de contrôles complémentaires, est alors chiffré en utilisant une clé privée du terminal de paiement ; un fichier de transmission de ces données intermédiaires chiffrées est construit, et le fichier est transmis au terminal Dton de l’utilisateur par l’intermédiaire du réseau de communication auquel le terminal de paiement est connecté ; Dans cet exemple de réalisation, le réseau de communication représente le canal de transmission principal des données intermédiaires ;
- le dispositif DTon de l’utilisateur reçoit le fichier des données intermédiaires en provenance du terminal de paiement, par exemple par l’intermédiaire d’un SMS ou d’un autre message transmis sur le réseau de communication ; Les données du fichier sont déchiffrées à l’aide de la clé publique du terminal de paiement (cette clé publique a été transmise au dispositif Dton par ailleurs, comme explicité dans le deuxième exemple de réalisation) et le dispositif de communication d’utilisateur (DTon) de l’utilisateur est dynamiquement configuré : une application de validation de transaction de paiement (par exemple l’application bancaire de l’utilisateur, préinstallée sur son terminal), avec en paramètre les données identifiant du terminal du terminal de paiement et pré-identifiant de transaction est exécutée sur le dispositif de communication d’utilisateur (DTon) ; Cette application affiche les données de la transaction à destination de l’utilisateur, comme si l’utilisateur visualisait l’écran du terminal de paiement; Cette application de saisie est par exemple préinstallée par l’utilisateur ou bien disponible nativement sur le dispositif de communication d’utilisateur (DTon) ; Ceci achève la configuration dynamique du dispositif d’utilisateur ;
- S’ensuit l’étape de validation de la transaction, consistant pour l’utilisateur à :
- Apposer sa carte de paiement au dos de son terminal de communication, qui dans cet exemple de réalisation est une carte sans contact (NFC) ; cette apposition entraine la lecture des données de la carte bancaire sur le terminal de communication de l’utilisateur (numéro de carte, date, cvv, nom) et déclenche l’affichage d’une interface utilisateur de saisie de code PIN comprenant : les informations relatives à l’accès, obtenues à partir des données intermédiaires et une zone de saisie de code PIN (permettant à l’utilisateur de saisir le code confidentiel de sa carte de paiement) et un triplet de boutons (« annulation », « correction », « validation ») ;
- Effectuer la saisie du code PIN sur l’écran de son dispositif, puis à valider cette saisie en sélectionnant le bouton « validation » ; Un message est affiché à destination de l’utilisateur pour l’informer la saisie ;
- Optionnellement, apposer à nouveau sa carte de paiement au dos de son terminal de communication, afin que la carte vérifie la validité du code PIN saisit et fournisse un certificat de transaction.
- Une fois cette saisie/validation effectuée par l’utilisateur, l’application effectue une validation de la transaction en générant un certificat de transaction à l’aide des données de la carte bancaire, et en fonction du nombre de fois où la carte a été apposée au dos du terminal de communication de l’utilisateur ; les données de transaction et le certificat de transaction sont alors transmis au serveur transactionnel ;
- Le serveur transactionnel valide la transaction reçue de la part du terminal de communication de l’utilisateur et transmet, au terminal de paiement du commerçant des données de confirmation de la transaction ;
- Le terminal de paiement réceptionne les données transmises par le serveur transactionnel : le commerçant est alors informé de la validation de la transaction.
Ainsi, grâce à cette mise en œuvre, l’utilisateur a été en mesure de réaliser le paiement de ses achats, tout en évitant d’une part de saisir des informations sensibles sur le terminal de paiement lui-même (qui comme cela a été rappelé précédemment peut être un simple terminal de communication comprenant des fonction de paiement pour le commerçant, comme par exemple des terminaux de communication avec des lecteurs de carte additionnels de type Square™, se branchant sur le terminal de communication) et d’autre part en sécurisant la transmission de ces données, par voie de chiffrement notamment, au serveur transactionnel directement, sans passer par le terminal du commerçant. L’utilisateur n’a pas non plus eu besoin d’entrer en contact physique avec le terminal du commerçant, préservant la sécurité sanitaire.
Exemple de réalisation 4 : paiement à l’aide d’un terminal de paiement
Comme dans le précédent exemple de réalisation, le principe est ici encore de dissocier la réalisation de la transaction en utilisant trois entité distinctes, comme explicité précédemment. La méthode est à nouveau destinée à permettre de réaliser un paiement entre un marchand physique (i.e. se trouvant dans une boutique) et un client (utilisateur), qui est également physiquement dans la boutique du marchand et qui souhaite réaliser un paiement pour des biens ou des services qu’il achète.
Le processus de traitement de transaction dissociée est mis en œuvre, selon les étapes précédemment décrites, postérieurement à la demande de paiement formulée par le commerçant (par exemple en requérant le paiement des biens ou des services à l’utilisateur)
- Le terminal de paiement obtient, en provenance du serveur transactionnel, des données relatives à l’établissement bancaire auprès duquel le commerçant est enregistré, notamment, un identifiant lié au terminal de paiement, à partir d’un compte du commerçant ;
- Le terminal de paiement du commerçant transmet, au dispositif Dton, d’au moins « une clé d’activation sécurisée » (ou une paire de clé d’activation) qui forment les données intermédiaires, obtenue notamment à partir de l’identifiant lié au terminal de paiement ; La transmission de cette clé est réalisée, selon un premier exemple de réalisation, par l’intermédiaire d’un signal transmis du terminal de paiement du commerçant à destination du dispositif Dton, qui se trouve physiquement à côté du commerçant (et de son terminal de paiement). (i.e. QR-Code ou Ultrason ou « proxy transactionnel cloud, serveur transactionnel », i.e. réseau de transmission de données) ;
o La réception de cette (ces) clé(s), faisant office de données intermédiaires, entraine l’activation de l’application AppV sur le terminal de communication de l’utilisateur. Cette application est préinstallée par l’utilisateur, ou encore il s’agit de l’application de sa banque, ou alors il s’agit d’une application instantanée à usage unique, comme dans le cas de la réception d’un colis présenté précédemment ;
- En plus de la réception de la clé d’activation sécurisée, l’application AppV du terminal de communication de l’utilisateur reçoit « les paramètres du marchand », à utiliser pour effectuer la transaction (qui comprennent notamment par exemple une « limite plancher ») ;
o Une « limite plancher » est un montant, par exemple en euros, au-dessus duquel les transactions par carte de crédit doivent être autorisées (c’est-à-dire faire l’objet d’une autorisation par le réseau de carte bancaire).
o dans cet exemple de réalisation, on oblige à ce que la transaction soit autorisée par le réseau ;
- Un mécanisme d’acquisition (« acquiring service ») opère la transaction à partir d’un serveur transactionnel de comptes marchands (donc en provenance de la banque) en lien avec le terminal de communication de l’utilisateur et l’application AppV, comme explicité précédemment ;
- Un mécanisme de compensation (« clearing service ») identifie, à partir des données transactionnelles obtenues, une méthode qui permette de valider la transaction ; le statut de la transaction est communiqué au terminal (de paiement) du marchand et le crédit (i.e. la somme d’argent) est inscrit sur le compte bancaire du marchand ; Ce mécanisme de compensation est opéré à partir d’un serveur transactionnel de la banque du marchand ;
- Le terminal du marchand reçoit, en provenance du serveur transactionnel qui a exécuté la transaction (i.e le serveur mettant en œuvre le mécanisme de compensation), un résultat de cette transaction (sous la forme d’un message chiffré). Le résultat de la transaction est sécurisé par l’utilisation de la (ou des) clé d’activation qui ont été transmises au terminal de communication par le terminal de paiement.
Ainsi, dans cet exemple de réalisation, le procédé consolidé mis en œuvre est le suivant :
- Une étape (préalable) de souscription est mise en œuvre par le marchand (optionnelle pour l’utilisateur, notamment pour instant App côté client) ;
- Le marchand sélectionne la méthode de paiement idoine sur le terminal de paiement (et saisit ou reçoit le montant à payer à partie de la caisse enregistreuse) ;
- en fonction des conditions de mise en œuvre opérationnelles, l’utilisateur peut insérer sa carte dans le terminal de paiement (i.e. par exemple en fonction du montant de la transaction à exécuter) ; le mécanisme mis en œuvre permet au client de saisir son PIN sur son terminal de communication ;
- Le terminal de paiement reçoit une information de la part du serveur transactionnel, notamment l’identifiant de la transaction et la (ou les) clé(s) pour le processus de validation de transaction ; il requiert ces données auprès du serveur transactionnel ;
- L’application du terminal de communication de l’utilisateur est activée (et téléchargée au s’il s’agit d’une application instantanée) – l’activation peut être manuelle (démarrage par l’utilisateur ou automatique (notification, i.e. application en arrière-plan, avec réseau de données du terminal de communication) ou bien être subséquente à la transmission d’une information par le terminal de paiement du marchand (QR scanné par l’utilisateur, sur écran terminal de paiement ultrasons émis à partir du buzzer du terminal de paiement et reçus par le terminal de communication, NFC).
o En même temps qu’elle est activée, l’application du terminal de communication de l’utilisateur reçoit l’identifiant de la transaction et la (ou les) clé(s) (soit de la part du terminal de paiement du marchand, soit de la part du serveur transactionnel : lorsqu’il c’est le serveur transactionnel, celui-ci est informé du terminal de communication par l’intermédiaire de l’identifiant du terminal de communication de l’utilisateur (par exemple son numéro de téléphone).
- Sur la base de l’l’identifiant de transaction et de la clé (ou des clés) le terminal de communication de l’utilisateur transmet une requête d’obtention de données de transaction et de paramètres de paiement (du marchand) au mécanisme d’acquisition (pour recevoir la limite plancher notamment) du serveur transactionnel ;
o Le dispositif Dton dispose alors du montant à régler et de l’identification du marchand : cela permet d’assurer que les informations affichées sur le terminal du marchand (et/ou la caisse enregistreuse) sont identiques à celles visualisées sur le terminal de communication de l’utilisateur ;
o En d’autres termes, le serveur transactionnel comprend des moyens de détermination d’l’identifiant de transaction et des moyens de génération de clé pour pouvoir échanger des données de manière sécurisée avec le terminal de communication de l’utilisateur pour le compte du marchand et il dispose d’une sauvegarde des paramètres du marchand, tels qu’associés au terminal de paiement de celui-ci ; l’avantage complémentaire procuré est que le terminal du commerçant peut être dénué de fonctions complexes de traitement de transaction, ces fonctions complexes étant gérées au niveau du serveur transactionnel d’une part et du terminal de communication de l’utilisateur d’autre part ;
- Ensuite, l’application du terminal de communication procède à la mise en œuvre de la transaction (comme explicité dans les deuxièmes et troisièmes exemples de réalisation).
- L’application du terminal de communication et le serveur transactionnel complètent la transaction EMV.
- Ensuite, un traitement de réseau de paiement est mis en œuvre (card network) : le serveur transactionnel transmet un message de complétion de la transaction au mécanisme de compensation (qui se charge de transférer le montant de la transaction sur le compte du marchand) ;
- Le mécanisme de compensation transmet le message de complétion de la transaction au terminal de paiement du marchand ;
- Le serveur transactionnel informe également l’application du terminal de communication que la transaction est complétée.
Claims (10)
- Procédé d’exécution d’une transaction entre un terminal de mise en œuvre de transaction d’un professionnel (TProf) et un dispositif de communication d’utilisateur (Dton) qui est situé à proximité du terminal de mise en œuvre de transaction du professionnel (TProf), procédé caractérisé en ce qu’il comprend une étape de préparation (A10) de la transaction à exécuter au sein terminal de mise en œuvre de transaction du professionnel (TProf), délivrant au moins une donnée intermédiaire d’exécution de transaction ; une étape de transmission (A20) de ladite au moins une donnée intermédiaire d’exécution de transaction au dispositif de communication d’utilisateur (Dton) ; et une étape d’exécution (A30) de la transaction par le dispositif de communication d’utilisateur (Dton) à l’aide de ladite au moins une donnée intermédiaire d’exécution de transaction et d’au moins une donnée personnelle (Sgn, PIN) de l’utilisateur qui détient le dispositif de communication d’utilisateur (Dton), ladite exécution délivrant un résultat d’exécution transmis (A40) au terminal de mise en œuvre de transaction du professionnel (TProf).
- Procédé selon la revendication 1, caractérisé en ce que l’étape d’exécution (A30) de la transaction par le dispositif de communication d’utilisateur (Dton) à l’aide de ladite au moins une donnée intermédiaire d’exécution de transaction et d’au moins une donnée personnelle (Sgn, PIN) de l’utilisateur qui détient le dispositif de communication d’utilisateur (Dton) comprend une étape d’obtention, par le dispositif de communication d’utilisateur (Dton), d’au moins une donnée en provenance d’un dispositif transactionnel additionnel (DTa) en possession de l’utilisateur.
- Procédé selon la revendication 2, caractérisé en ce que l’étape d’obtention, par le dispositif de communication d’utilisateur (Dton), de ladite au moins une donnée en provenance du dispositif transactionnel additionnel (DTa) en possession de l’utilisateur comprend :
- une étape d’émission, par le dispositif de communication d’utilisateur (Dton), d’une requête d’obtention de données transactionnelles, ladite étape d’émission utilisant une interface de communication en champs proche (NFC) du dispositif de communication d’utilisateur (Dton) ;
- une étape de réception, par le dispositif de communication d’utilisateur (Dton), d’une réponse à ladite requête d’obtention de données transactionnelles par l’intermédiaire de interface de communication en champs proche (NFC) du dispositif de communication d’utilisateur (Dton). - Procédé selon la revendication 1, caractérisé en ce que l’étape d’exécution (A30) de la transaction par le dispositif de communication d’utilisateur (Dton) à l’aide de ladite au moins une donnée intermédiaire d’exécution de transaction et d’au moins une donnée personnelle (Sgn, PIN) de l’utilisateur qui détient le dispositif de communication d’utilisateur (Dton) comprend :
- une étape de réception de ladite au moins une donnée intermédiaire d’exécution de transaction par le dispositif de communication d’utilisateur (Dton) ;
- une étape de configuration dynamique du dispositif de communication d’utilisateur (Dton), en fonction de ladite au moins une donnée intermédiaire d’exécution, ladite étape de étape de configuration dynamique comprenant une étape d’exécution, au sein d’un espace mémoire dédié dudit dispositif de communication d’utilisateur (Dton), d’une application de validation (AppVT) pour la saisie de la dite au moins une donnée personnelle (Sgn, PIN) de l’utilisateur qui détient le dispositif de communication d’utilisateur (Dton) ;
- une étape de réception, par l’application de validation (AppVT), d’au moins une donnée saisie par ledit utilisateur ;
- une étape de validation, par l’application de validation (AppVT), de la transaction en fonction de ladite au moins une donnée saisie par ledit utilisateur et desdites données intermédiaires, délivrant un résultat de validation. - Procédé d’exécution selon la revendication 4, caractérisé en ce que postérieurement à l’étape de validation, par l’application de validation (AppVT), de la transaction en fonction de ladite au moins une donnée saisie par ledit utilisateur et desdites données intermédiaires, le procédé comprend :
- une étape de transmission desdites données intermédiaires et dudit résultat de validation, à un serveur transactionnel auquel le dispositif de communication d’utilisateur (Dton) est connecté par l’intermédiaire de l’application de validation (AppVT),
- une étape de validation, par le serveur transactionnel, desdites données intermédiaires et dudit résultat de validation, comprenant une vérification des opérations cryptographiques de validation effectuées par ladite l’application de validation (AppVT) ;
- une étape de transmission, au terminal de mise en œuvre de transaction d’un professionnel (TProf), dudit résultat de validation de transaction, lorsque la vérification des opérations cryptographiques de validation délivre un résultat positif. - Procédé d’exécution selon la revendication 1, caractérisé en ce que l’étape étape de préparation (A10) de la transaction à exécuter au sein terminal de mise en œuvre de transaction du professionnel (TProf) comprend :
- une étape d’obtention, à partir d’un dispositif transactionnel additionnel (DTa) en possession de l’utilisateur, d’au moins une clé de chiffrement destinée à être transmise au dispositif de communication d’utilisateur ; et
- une étape d’insertion, au sein de ladite au moins une donnée intermédiaire d’exécution, de ladite au moins une clé de chiffrement obtenue. - Procédé d’exécution selon la revendication 1, caractérisé en ce que l’étape de transmission (A20) de ladite au moins une donnée intermédiaire d’exécution de transaction au dispositif de communication d’utilisateur (Dton) comprend :
- une étape d’activation d’une interface de communication du terminal de mise en œuvre de transaction d’un professionnel (TProf), pour la transmission par l’intermédiaire d’un canal principal ;
- une étape de transmission, par l’intermédiaire de l’interface de communication, d’un fichier comprenant ladite au moins une donnée intermédiaire. - Procédé d’exécution selon la revendication 7, caractérisé en ce que l’interface de communication activée pour la transmission du fichier comprenant ladite au moins une donnée intermédiaire appartient au groupe comprenant :
- une interface sonore, configurée pour émettre le fichier préalablement encodé sous la forme d’un signal ultrasonore ;
- un écran du terminal de mise en œuvre de transaction d’un professionnel (TProf), configurée pour afficher le fichier préalablement encodé sous la forme d’un code bidimensionnel ;
- une interface de transmission de données par l’intermédiaire d’un réseau de communication, configurée pour transmettre le fichier préalablement encodé sous la forme d’un message. - Système d’exécution d’une transaction, système comprenant un terminal de mise en œuvre de transaction d’un professionnel (TProf) et un dispositif de communication d’utilisateur (Dton) qui est situé à proximité du terminal de mise en œuvre de transaction du professionnel (TProf), système caractérisé en ce qu’il comprend des moyens de préparation de la transaction à exécuter implémentés au sein terminal de mise en œuvre de transaction du professionnel (TProf), délivrant au moins une donnée intermédiaire d’exécution de transaction ; des moyens de transmission de ladite au moins une donnée intermédiaire d’exécution de transaction au dispositif de communication d’utilisateur (Dton) ; et des moyens d’exécution de la transaction implémentés au sein du dispositif de communication d’utilisateur (Dton) à l’aide de ladite au moins une donnée intermédiaire d’exécution de transaction et d’au moins une donnée personnelle (Sgn, PIN) de l’utilisateur qui détient le dispositif de communication d’utilisateur (Dton), ladite exécution délivrant un résultat d’exécution et des moyens de transmission du résultat d’exécution au terminal de mise en œuvre de transaction du professionnel (TProf).
- 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’exécution d’une transaction selon l’une des revendications 1 à 8, lorsqu’il est exécuté sur un ordinateur.
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2105933A FR3123741A1 (fr) | 2021-06-04 | 2021-06-04 | procédé de traitement d’une transaction, dispositif et programme correspondant. |
| EP22734521.2A EP4348459A1 (fr) | 2021-06-04 | 2022-06-03 | Procédé de traitement d'une transaction, dispositif et programme correspondant |
| CA3220060A CA3220060A1 (fr) | 2021-06-04 | 2022-06-03 | Procede de traitement d'une transaction, dispositif et programme correspondant. |
| PCT/EP2022/065178 WO2022254002A1 (fr) | 2021-06-04 | 2022-06-03 | Procédé de traitement d'une transaction, dispositif et programme correspondant. |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2105933 | 2021-06-04 | ||
| FR2105933A FR3123741A1 (fr) | 2021-06-04 | 2021-06-04 | procédé de traitement d’une transaction, dispositif et programme correspondant. |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR3123741A1 true FR3123741A1 (fr) | 2022-12-09 |
Family
ID=77913177
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR2105933A Pending FR3123741A1 (fr) | 2021-06-04 | 2021-06-04 | procédé de traitement d’une transaction, dispositif et programme correspondant. |
Country Status (4)
| Country | Link |
|---|---|
| EP (1) | EP4348459A1 (fr) |
| CA (1) | CA3220060A1 (fr) |
| FR (1) | FR3123741A1 (fr) |
| WO (1) | WO2022254002A1 (fr) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20170186016A1 (en) * | 2014-07-10 | 2017-06-29 | Roam Data, Inc. | Method for managing a transaction, corresponding server, computer program product and storage medium |
| US20180204206A1 (en) * | 2013-09-25 | 2018-07-19 | Christian Flurscheim | Systems and methods for incorporating qr codes |
| US10127532B1 (en) | 2015-08-19 | 2018-11-13 | Square, Inc. | Customized transaction flow |
| US10147094B2 (en) | 2014-12-17 | 2018-12-04 | Mastercard International Incorporated | Method to enable consumers to make purchases at point of sale devices using their mobile number |
| US20190066089A1 (en) * | 2017-08-25 | 2019-02-28 | Mastercard International Incorporated | Secure transactions using digital barcodes |
-
2021
- 2021-06-04 FR FR2105933A patent/FR3123741A1/fr active Pending
-
2022
- 2022-06-03 EP EP22734521.2A patent/EP4348459A1/fr active Pending
- 2022-06-03 CA CA3220060A patent/CA3220060A1/fr active Pending
- 2022-06-03 WO PCT/EP2022/065178 patent/WO2022254002A1/fr active Application Filing
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20180204206A1 (en) * | 2013-09-25 | 2018-07-19 | Christian Flurscheim | Systems and methods for incorporating qr codes |
| US20170186016A1 (en) * | 2014-07-10 | 2017-06-29 | Roam Data, Inc. | Method for managing a transaction, corresponding server, computer program product and storage medium |
| US10147094B2 (en) | 2014-12-17 | 2018-12-04 | Mastercard International Incorporated | Method to enable consumers to make purchases at point of sale devices using their mobile number |
| US10127532B1 (en) | 2015-08-19 | 2018-11-13 | Square, Inc. | Customized transaction flow |
| US20190066089A1 (en) * | 2017-08-25 | 2019-02-28 | Mastercard International Incorporated | Secure transactions using digital barcodes |
Also Published As
| Publication number | Publication date |
|---|---|
| CA3220060A1 (fr) | 2022-12-08 |
| EP4348459A1 (fr) | 2024-04-10 |
| WO2022254002A1 (fr) | 2022-12-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3113099B1 (fr) | Conteneur de paiement, procédé de création, procédé de traitement, dispositifs et programmes correspondants | |
| US11443301B1 (en) | Sending secure proxy elements with mobile wallets | |
| WO2015103971A1 (fr) | Procédé et système pour vérifier des transactions à l'aide d'une carte intelligente | |
| CA2971635A1 (fr) | Procede de traitement d'une transaction a partir d'un terminal de communication | |
| EP3163487B1 (fr) | Procédé de sécurisation de traitement de données transactionnelles, terminal et programme d'ordinateur correspondant | |
| EP3857413A1 (fr) | Procede de traitement d'une transaction, dispositif, systeme et programme correspondant | |
| CN112753042A (zh) | 提供身份存储浏览器的***、方法和计算机程序产品 | |
| EP3349160B1 (fr) | Procédé de transmission de données, dispositif et programme correspondant | |
| WO2016207715A1 (fr) | Gestion securisee de jetons électroniques dans un telephone mobile. | |
| EP3991381B1 (fr) | Procédé et système de génération de clés de chiffrement pour données de transaction ou de connexion | |
| EP3542335B1 (fr) | Procédé de traitement de données transactionnelles, terminal de communication, lecteur de cartes et programme correspondant | |
| EP3588418A1 (fr) | Procédé de réalisation d'une transaction, terminal, serveur et programme d ordinateur correspondant | |
| EP2824625B1 (fr) | Méthode de réalisation de transaction, terminal et programme d'ordinateur correspondant | |
| EP4348459A1 (fr) | Procédé de traitement d'une transaction, dispositif et programme correspondant | |
| WO2021116627A1 (fr) | Procede, serveur et systeme d'authentification de transaction utilisant deux canaux de communication | |
| FR3023640A1 (fr) | Procede de gestion d'une transaction, serveur, produit programme d'ordinateur et medium de stockage correspondants. | |
| EP3570238B1 (fr) | Procédé de réalisation d'une transaction, terminal, serveur et programme d'ordinateur correspondant | |
| EP3371760A1 (fr) | Procédé de verification d'identité lors d'une virtualisation | |
| FR2985148A1 (fr) | Methode d'appairage d'equipements electroniques | |
| WO2017005644A1 (fr) | Procédé et système de contrôle d'accès à un service via un média mobile sans intermediaire de confiance | |
| EP4016427A1 (fr) | Procede pour la creation d'un instrument de paiement au profit d'un tiers beneficiaire | |
| FR3020166A1 (fr) | Procedes de traitement de donnees transactionnelles, dispositifs et programmes correspondants | |
| FR2976385A1 (fr) | Procede pour definir une transaction a effectuer au moyen d'un serveur | |
| FR2912579A1 (fr) | Procede de transfert securise via un reseau de communication d'un flux monetaire, systeme de transfert et produit programme correspondants |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20221209 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |