FR3060818A1 - Securisation de transaction - Google Patents

Securisation de transaction Download PDF

Info

Publication number
FR3060818A1
FR3060818A1 FR1662729A FR1662729A FR3060818A1 FR 3060818 A1 FR3060818 A1 FR 3060818A1 FR 1662729 A FR1662729 A FR 1662729A FR 1662729 A FR1662729 A FR 1662729A FR 3060818 A1 FR3060818 A1 FR 3060818A1
Authority
FR
France
Prior art keywords
user
terminal
transaction
server
stream
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
FR1662729A
Other languages
English (en)
Inventor
Fabrice Jeanne
Patrick Leroy
Christopher Georget
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.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Priority to FR1662729A priority Critical patent/FR3060818A1/fr
Priority to CN201780073985.2A priority patent/CN110383312B/zh
Priority to US16/470,825 priority patent/US20190311349A1/en
Priority to PCT/FR2017/053542 priority patent/WO2018115641A1/fr
Priority to EP17822409.3A priority patent/EP3555829A1/fr
Publication of FR3060818A1 publication Critical patent/FR3060818A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • 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/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3272—Short range or proximity payments by means of M-devices using an audio code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3274—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being displayed on the M-device
    • 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
    • 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/385—Payment protocols; Details thereof using an alias or single-use codes
    • 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

Landscapes

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

Abstract

Un procédé de sécurisation de transaction entre un terminal (11) d'un premier utilisateur (1) et un dispositif (20) d'un second utilisateur (2) par l'intermédiaire d'un serveur (30) d'une entité tierce (3). Le procédé comprend : comparer : - une première suite de codes (101) tirés d'une clé privée associée au second utilisateur (2) transmise du serveur (30) au dispositif de transaction (20), et - une seconde suite de codes (201) reçue par le serveur (30) depuis un terminal (12) du premier utilisateur (1), la comparaison déclenchant, en cas de correspondance entre les deux suites de codes (101 ; 201) associer le premier utilisateur (1), le second utilisateur (2) et la transaction, permettant de délivrer une autorisation de la poursuite de la transaction entre le premier utilisateur (1) et le second utilisateur (2) associés par l'entité tiers (3).

Description

® RÉPUBLIQUE FRANÇAISE
INSTITUT NATIONAL DE LA PROPRIÉTÉ INDUSTRIELLE © N° de publication :
(à n’utiliser que pour les commandes de reproduction)
©) N° d’enregistrement national
060 818
62729
COURBEVOIE
©) Int Cl8 : G 06 Q 20/02 (2017.01), G 06 Q 20/40, 20/12, 20/16, 20/32, 30/06
DEMANDE DE BREVET D'INVENTION A1
©) Date de dépôt : 19.12.16. ©) Demandeur(s) : ORANGE Société anonyme — FR.
(30) Priorité :
©) Inventeur(s) : JEANNE FABRICE, LEROY PATRICK
et GEORGET CHRISTOPHER.
(43) Date de mise à la disposition du public de la
demande : 22.06.18 Bulletin 18/25.
(56) Liste des documents cités dans le rapport de
recherche préliminaire : Se reporter à la fin du
présent fascicule
@) Références à d’autres documents nationaux ©) Titulaire(s) : ORANGE Société anonyme.
apparentés :
©) Demande(s) d’extension : @) Mandataire(s) : CABINET PLASSERAUD.
SECURISATION DE TRANSACTION.
FR 3 060 818 - A1
Un procédé de sécurisation de transaction entre un terminal (11 ) d'un premier utilisateur (1 ) et un dispositif (20) d'un second utilisateur (2) par l'intermédiaire d'un serveur (30) d'une entité tierce (3). Le procédé comprend: comparer:
- une première suite de codes (101 ) tirés d'une clé privée associée au second utilisateur (2) transmise du serveur (30) au dispositif de transaction (20), et
- une seconde suite de codes (201 ) reçue par le serveur (30) depuis un terminal (12) du premier utilisateur (1), la comparaison déclenchant, en cas de correspondance entre les deux suites de codes (101 ; 201) associer le premier utilisateur (1 ), le second utilisateur (2) et la transaction, permettant de délivrer une autorisation de la poursuite de la transaction entre le premier utilisateur (1) et le second utilisateur (2) associés par l'entité tiers (3).
Figure FR3060818A1_D0001
Figure FR3060818A1_D0002
Sécurisation de transaction
L’invention relève du domaine de la sécurité des échanges de données au cours de transactions.
Pour renforcer la sécurité, il est connu de multiplier les vérifications lors de transactions distantes. Par exemple, un client souhaitant payer en ligne une commande à un marchand peut devoir entrer un code à usage unique, ou OTP pour « One Time Password » en anglais, pour confirmer une transaction. Généralement, de tels OTP ont une durée de validité courte, de l’ordre de quelques minutes, et deviennent obsolètes après une seule utilisation. Les OTP sont transmis par un intermédiaire, souvent l’organisme bancaire du client, au moyen d’un texto sur un téléphone du client, ou SMS pour « Short Message Service » en anglais.
L’usage des OTP permet de dispenser le client d’entrer un code lié durablement à son moyen de paiement, par exemple un code du type code PIN (PIN pour « Personal Identification Numher » en anglais) de carte à puce ou un cryptogramme inscrit sur une carte de paiement. Ainsi, même si un tiers ou le marchand lui-même a accès aux données transmises, ces dernières sont insuffisantes pour utiliser le moyen de paiement.
Cependant, l’envoi d’un OTP au client n’est déclenché qu’à réception d’une requête de la part du marchand à l’intermédiaire. Pour être établie, une telle requête nécessite au préalable que le client fournisse au marchand des données sensibles telles que l’identité de son organisme bancaire, un identifiant du moyen de paiement, un nom, un prénom, etc. Outre les informations bancaires, le client doit souvent fournir d’autres données sensibles telles que des données personnelles : adresse physique de livraison, adresse postale de facturation, courriel, numéros de téléphone, informations de livraison telles que des digicodes, heures de présence au domicile, etc.
L’usage d’un OTP ne protège pas contre l’interception de la plupart des données sensibles généralement fournies au cours d’une transaction.
En particulier, lorsque le client utilise un ordinateur ou une connexion non sécurisés pour passer sa commande, la protection des données sensibles ne peut être assurée.
L’invention vient améliorer la situation.
La demanderesse propose un procédé de sécurisation de transaction initialisée entre un premier terminal de communication à disposition d’un premier utilisateur et un dispositif de transaction d’un second utilisateur par l’intermédiaire d’un serveur d’une entité tierce. Le procédé comprend :
comparer :
- une première suite de codes transmise avec un premier flux de données associé à la transaction, du serveur de l’entité tierce au dispositif de transaction du second utilisateur, les données du premier flux comprenant la première suite de codes tirés d’une clé privée associée au second utilisateur, et
- une seconde suite de codes reçue avec un second flux de données par le serveur de l’entité tierce depuis un deuxième terminal de communication à disposition du premier utilisateur, ledit deuxième terminal transmettant le second flux en réponse à la réception du premier flux, la comparaison déclenchant, en cas de correspondance entre les deux suites de codes, associer le premier utilisateur, le second utilisateur et la transaction, permettant de délivrer une autorisation de la poursuite de la transaction entre le premier utilisateur et le second utilisateur associés par l’entité tiers.
Un tel procédé permet au premier utilisateur d’entamer une transaction avec le second utilisateur, par exemple une commande d’un objet à livrer, sur le premier terminal. Le premier terminal et/ou une partie du réseau utilisé peuvent ne pas être sécurisés, être mal sécurisés ou avoir un niveau de sécurité inconnu de la part du premier utilisateur. L’utilisateur peut néanmoins préférer utiliser un ordinateur d’un cybercafé pour un meilleur confort de navigation plutôt que d’utiliser un smartphone dont l’écran est plus petit (« smartphone » est utilisé ici au sens de « ordiphone » en français). Ainsi, le smartphone peut être utilisé en tant que deuxième terminal. Il est alors inutile pour l’utilisateur d’entrer les données sensibles, notamment les données bancaires et personnelles, sur le premier terminal. Autrement dit, la transaction est possible sans que les données sensibles ne transitent via le premier terminal ou une portion de réseau dont la sécurisation est inconnue.
Selon un autre aspect, la demanderesse propose un serveur d’une entité tierce pour sécuriser une transaction initialisée entre un premier terminal de communication à disposition d’un premier utilisateur et un dispositif de transaction d’un second utilisateur, le serveur étant apte à communiquer avec un deuxième terminal de communication à disposition du premier utilisateur et avec le dispositif de transaction du second utilisateur, le serveur comportant :
- un comparateur :
- d’une première suite de codes transmise avec un premier flux de données associé à la transaction, par un émetteur du serveur de l’entité tierce au dispositif de transaction du second utilisateur, les données du premier flux comprenant la première suite de codes tirés d’une clé privée associée au second utilisateur, et
- d’une seconde suite de codes reçue avec un second flux de données par un récepteur du serveur de l’entité tierce depuis un deuxième terminal de communication à disposition du premier utilisateur, ledit deuxième terminal transmettant le second flux en réponse à la réception du premier flux, le comparateur étant apte, en cas de correspondance entre les deux suites de codes, à associer le premier utilisateur, le second utilisateur et la transaction, déclenchant
- un dispositif d’autorisation de la poursuite de la transaction entre le premier utilisateur et le second utilisateur associés, par l’intermédiaire de l’entité tiers.
Selon un autre aspect, la demanderesse propose un procédé de validation de transaction initialisée entre un premier terminal de communication à disposition d’un premier utilisateur et un dispositif de transaction d’un second utilisateur, mis en œuvre par un deuxième terminal de communication à disposition du premier utilisateur. Le procédé comprend : insérer dans un second flux de données une seconde suite de codes en réponse à une réception d’une première suite de codes associée à la transaction par le dispositif de transaction du second utilisateur dans un premier flux de données provenant d’un serveur d’une entité tierce, la seconde suite de codes étant tirée d’une clé privée associée au second utilisateur, le second flux étant apte à être transmis depuis le deuxième terminal au serveur de l’entité tierce.
Selon un autre aspect, la demanderesse propose un terminal de communication apte à communiquer avec un serveur et comprenant un dispositif de validation. Le dispositif de validation comporte :
un générateur de flux insérant dans un second flux de données une seconde suite de codes en réponse à une réception d’une première suite de codes associée à la transaction par le dispositif de transaction du second utilisateur dans un premier flux de données provenant d’un serveur d’une entité tierce, la seconde suite de codes étant tirée d’une clé privée associée au second utilisateur, le second flux étant apte à être transmis par un transmetteur du deuxième terminal au serveur de l’entité tierce.
Selon un autre aspect, la demanderesse propose un programme informatique comportant des instructions pour la mise en œuvre de l’un et/ou l’autre des procédés lorsque ce programme est exécuté par un processeur.
Les caractéristiques suivantes peuvent, optionnellement, être mises en œuvre. Elles peuvent être mises en œuvre indépendamment les unes des autres ou en combinaison les unes avec les autres :
- Le premier flux est transmis en continue en réponse à une requête du dispositif de transaction adressée au serveur, et est interrompue à la clôture de la transaction. La transmission en continue du premier flux contenant la première suite de codes permet de répéter la comparaison jusqu’à détecter un niveau de correspondance suffisant entre une première suite transmise et une seconde suite reçu.
- La première suite de codes du premier flux prend la forme d’un contenu multimédia. Ainsi, si le second terminal est doté de capteur, il sera inutile de connecter le premier terminal 11 et le second terminal 12 l’un à l’autre via une connexion physique ou sans fil pour que le premier utilisateur lisant la première suite de code reçu saisisse sur son deuxième terminal une deuxième suite de code qui sera transmise dans un deuxième flux.
- La comparaison de la première suite de codes et de la seconde suite de codes comprend : vérifier que le niveau de correspondance de la seconde suite avec la première suite est supérieur à une valeur seuil de correspondance prédéfinie et inférieure à 100%. Ceci permet d’identifier une correspondance entre la première et la deuxième suites de codes malgré des erreurs de transmission pouvant avoir lieu entre la transmission du premier flux au dispositif de transaction du second utilisateur et la réception du second flux depuis le second terminal du premier utilisateur.
- Le premier flux et/ou le second flux sont chacun transmis via un canal sécurisé, respectivement entre le serveur de l’entité tierce et le dispositif de transaction du second utilisateur, respectivement entre le deuxième terminal du premier utilisateur et le serveur de l’entité tierce. Cette précaution supplémentaire permet de complexifier les tentatives d’un tiers mal intentionné. En ralentissant suffisamment l’interception et l’interprétation des échanges par un tel tiers, il devient probable que la transaction soit clôturé avant que le tiers puisse utiliser les données interceptées. Or, à la clôture de la transaction, les données échangées deviennent inutilisables.
- L’autorisation de la poursuite de la transaction comprend :
- envoyer une demande de confirmation de la transaction au deuxième terminal du premier utilisateur depuis le serveur de l’entité tierce,
- réceptionner une confirmation de la transaction sur le serveur de l’entité tierce depuis le deuxième terminal du premier utilisateur,
- envoyer une confirmation de la transaction au dispositif de transaction du second utilisateur depuis le serveur de l’entité tierce.
Ceci permet par exemple d’éviter de transmettre des données bancaires propres au premier utilisateur, au second utilisateur. Les conséquences éventuelles pour le premier utilisateur d’une mauvaise sécurisation des données stockées et/ou échangées par le second utilisateur sont limitées.
- Le second flux comprend des données de capture d’un contenu multimédia via au moins un capteur du deuxième terminal, la seconde suite de codes étant incluse dans les données de capture du contenu multimédia. Ainsi, si le premier terminal reçoit la première suite de code dans un contenu multimédia qu’il reproduit, il sera inutile de connecter le premier terminal et le second terminal l’un à l’autre via une connexion physique ou sans fd pour que le premier utilisateur lisant la première suite de code reçu saisisse sur son deuxième terminal une deuxième suite de code qui sera transmise dans un deuxième flux.
- Le procédé de validation comprend en outre : capturer un contenu multimédia contenu dans le premier flux, reçu par le premier terminal du dispositif de transaction, et reproduit par le premier terminal, la capture étant réalisée via au moins un capteur du deuxième terminal, le contenu multimédia incluant la première suite de codes. Ainsi, si le premier terminal reçoit la première suite de code dans un contenu multimédia qu’il reproduit, il sera inutile de connecter le premier terminal et le second terminal l’un à l’autre via une connexion physique ou sans fd pour que le premier utilisateur lisant la première suite de code reçu saisisse sur son deuxième terminal une deuxième suite de code qui sera transmise dans un deuxième flux.
- La capture du contenu multimédia reproduite par le premier terminal comprend l’une au moins des opérations suivantes :
- photographier et/ou filmer, au moyen d’un capteur optique du deuxième terminal, un écran d’affichage du premier terminal affichant une succession d’images fixes ou animées, ou une vidéo ;
- capter, au moyen d’un microphone du deuxième terminal, du son émis par un haut-parleur du premier terminal.
Les capteurs optiques et microphones sont généralement présents sur les appareils connus à disposition des utilisateurs, notamment les téléphones intelligents. Il est alors inutile pour le premier utilisateur d’acquérir un terminal ou des équipements dédiés.
- Le procédé de validation comprend en outre, entre la capture du contenu multimédia et la transmission de l’au moins une partie de la première suite de codes, une opération de déchiffrage des codes contenus dans le contenu multimédia capturé par le deuxième terminal, le second flux apte à être transmis comprenant la seconde suite de codes sous forme déchiffrée et tirée du contenu multimédia capturé. La quantité de données à transmettre depuis le deuxième terminal est alors réduite.
D’autres caractéristiques, détails et avantages de l’invention apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels :
- la figure 1 montre un système pour la mise en œuvre d’un procédé selon un ou plusieurs modes de réalisation de l’invention, et
- la figure 2 montre un diagramme illustrant un ensemble de procédés proposés selon un ou plusieurs modes de réalisation de l’invention.
Les dessins et la description ci-après contiennent, pour l’essentiel, des éléments de caractère certain. Ils pourront donc non seulement servir à mieux faire comprendre la présente invention, mais aussi contribuer à sa définition, le cas échéant.
Dans la description détaillée ci-après de modes de réalisation de l’invention, de nombreux détails spécifiques sont présentés pour apporter une compréhension plus complète. Néanmoins, l’homme du métier peut se rendre compte que des modes de réalisation peuvent être mis en pratique sans ces détails spécifiques. Dans d’autres cas, des caractéristiques bien connues ne sont pas décrites en détail pour éviter de compliquer inutilement la description.
On entend ici par « réseau » une ou plusieurs liaisons permettant le transport de données entre des systèmes informatiques, des terminaux et/ou tous types d’équipement électroniques ou informatiques.
La figure 1 représente des interactions entre trois entités distinctes et généralement distantes les unes des autres : un premier utilisateur 1, un second utilisateur 2 et une entité tierce 3. Le premier utilisateur 1 dispose d’un premier terminal 11 de communication et d’un deuxième terminal 12 de communication. Le second utilisateur 2 dispose d’une unité 20, aussi appelée dispositif de transaction. L’entité tierce 3 dispose d’un serveur 30.
Le système comprend les éléments suivants : les terminaux il, 12, l’unité 20 et le serveur 30. Les éléments précités mettent en œuvre des procédés respectifs. Les procédés peuvent donc pour l’essentiel être mis en œuvre par des moyens informatiques. Dans un souci de cohérence et de clarté, les procédés sont décrits ensuite dans leur ensemble afin de mieux appréhender la manière dont les éléments interagissent en fonctionnement. L’homme du métier comprend que les éléments bien distincts ci-avant sont prévus pour fonctionner ensembles et présentant des liens entre eux. Il en est de même pour les aspects procédé de l’invention.
Dans l’exemple d’application prévu ici, le premier utilisateur 1 est une personne souhaitant acheter un article via Internet et se faire livrer à domicile. Le second utilisateur 2 est un commerçant gérant un point de vente, par exemple via un site internet commercial, et souhaitant vendre un article au premier utilisateur 1. L’entité tierce 3 est distincte du premier utilisateur 1 et du second utilisateur 2. L’entité tierce 3 assure le rôle de tiers de confiance entre le premier utilisateur 1 et le second utilisateur 2. L’entité tierce 3 peut, par exemple, être une banque. Dans le présent contexte, le terme « banque » s’entend au sens général d’intermédiaire commercial et/ou financier et ne doit pas être assimilé à un statut légal ou réglementaire particulier.
Dans le contexte de l’invention, le premier terminal 11 désigne un terminal par lequel le premier utilisateur 1 ne souhaite pas faire transiter des données qu’il considère sensibles, par exemple lorsqu’il a des doutes quant à la bonne sécurisation des données qui y sont entrées. Par exemple, le premier terminal 11 peut être prêté au premier utilisateur 1 ou être connecté à un réseau du type Wifi public dont le premier utilisateur 1 ne maîtrise pas les caractéristiques de sécurité. Le deuxième terminal 12 désigne, au contraire, un terminal de confiance pour le premier utilisateur 1. Par exemple, le deuxième terminal 12 peut être un téléphone ou un ordinateur personnel du premier utilisateur 1 et être relié à un réseau de confiance. Les termes « de confiance » se comprennent ici dans leur sens relatif par comparaison avec le premier terminal 11, étant entendu qu’aucun terminal connecté ne peut assurer une sécurité absolue des données qui y sont entrées.
Dans l’exemple illustré par la figure 1, le premier terminal 11 est un ordinateur tandis que le deuxième terminal 12 est un smartphone (« smartphone » étant ici équivalent à « ordiphone », ou « téléphone intelligent »). En variante, les terminaux 1, 2 sont d’un autre type.
Le premier terminal 11 comprend des moyens de communication, aussi nommé transmetteur de transactions, aptes à mettre en communication le premier terminal 11 avec l’unité 20, par exemple via le réseau Internet. Les moyens de communication impliquent des protocoles de transferts de données par paquets (comme par exemple le protocole IP (en anglais, « Internet Protocol »)).
Le premier terminal 11 comprend en outre plusieurs interfaces d’entrée/sortie, tel qu’une interface graphique incluant un écran 111, et un haut-parleur 112. Les interfaces d’entrée/sortie peuvent être intégrées au premier terminal 1 ou être déportés, par exemple au moyen de périphériques reliés au premier terminal 11.
Le deuxième terminal 12 comprend des moyens de communication aptes à mettre en communication le deuxième terminal 12 avec le serveur 30, par exemple via le réseau Internet. Les moyens de communication impliquent des protocoles de transferts de données par paquets. Le deuxième terminal 12 comprend en outre des moyens de communication compatibles avec un réseau de télécommunication du type téléphonie mobile, par exemple compatibles GSM, GPRS, EDGE, 3G, 4G ou LTE. D’autres moyens pourront être envisagés. Le deuxième terminal 12 comprend aussi des interfaces d’entrée/sortie, ici des capteurs, par exemple un capteur optique 121 et un microphone 122.
Les interfaces d’entrée/sortie peuvent être intégrées au deuxième terminal 12 ou être déportés, par exemple au moyen de dispositifs communicants avec le deuxième terminal 12.
Chacun du premier terminal 11 et du deuxième terminal 12 inclut plusieurs dispositifs, ou unités, parmi lesquels respectivement une interface de transaction 115 et un dispositif de validation 125, chacun incluant un ou plusieurs processeurs qui commandent les opérations du premier terminal 11, respectivement du deuxième terminal 12, comme une unité centrale (CPU) ou un autre processeur matériel, et une mémoire associée (par exemple, une mémoire vive (RAM), une mémoire morte (ROM), une mémoire cache et/ou une mémoire flash, ou tout autre medium de stockage apte au stockage de code logiciel sous forme d’instructions exécutables par un processeur ou de structures de données accessibles par un processeur) couplée de manière opérationnelle au(x) processeur(s).
Chacun du premier terminal 11 et du deuxième terminal 12 inclut un système d’exploitation et des programmes, composants, modules, applications sous forme de logiciels exécutés par le(s) processeur(s), qui peuvent être, dans un ou plusieurs modes de réalisation, stockés dans une mémoire non-volatile.
L’homme du métier peut se rendre compte que bien que le système proposé soit décrit dans ses différents modes de réalisation avec le premier terminal 1 de type ordinateur et le deuxième terminal 12 de type smartphone, différents modes de réalisation du système proposé peuvent être mis en œuvre en utilisant différentes combinaisons de types de terminaux de communication, notamment incluant des tablettes.
L’unité 20 et le serveur 30 incluent chacun un ou plusieurs processeurs, comme une unité centrale (CPU) ou un autre processeur matériel, et une mémoire associée (par exemple, une mémoire vive (RAM), une mémoire morte (ROM), une mémoire cache et/ou une mémoire flash, ou tout autre medium de stockage apte au stockage de code logiciel sous forme d’instructions exécutables par un processeur ou de structures de données accessibles par un processeur) couplée de manière opérationnelle au(x) processeur(s). L’unité 20 et le serveur 30 incluent chacun un système d’exploitation et des programmes, composants, modules, applications sous forme de logiciels exécutés par le(s) processeur(s), qui peuvent être, dans un ou plusieurs modes de réalisation, stockés dans une mémoire non-volatile.
L’unité 20 comprend des moyens de communication avec le serveur 30 de l’entité tierce 3 d’une part et avec le premier terminal 11 du premier utilisateur 1 d’autre part. Ainsi, le serveur 30 comprend un émetteur permettant la transmission du premier flux 100 entre le serveur 30. L’unité 20 comprend un premier transmetteur apte à recevoir le premier flux 100 depuis l’émetteur du serveur 30. L’unité 20 comprend en outre un deuxième transmetteur, dit transmetteur de transactions, permettant les échanges entre l’unité 20 et le premier terminal 11. Ainsi, le premier flux 100 sera reçu du serveur 30 par le premier transmetteur de l’unité 20 puis, éventuellement, émis par le deuxième transmetteur de l’unité vers le premier terminal 11.
ίο
L’unité 20 comprend une partie en arrière-plan (ou « back-end » en anglais) incluant le(s) processeur(s) et les moyens de communication avec le serveur 30 de l’entité tierce 3. L’unité 20 comprend une partie en frontale (ou « front-end » en anglais). La partie frontale inclut, ici, un site web accessible via Internet par le premier utilisateur 1, c’est-à-dire une interface utilisateur.
Le serveur 30 comprend des moyens de communication avec le deuxième terminal 12 du premier utilisateur 1 d’une part et avec l’unité 20 du second utilisateur 2 d’autre part. Ainsi, le serveur 30 comprend un récepteur apte à attendre la réception de données depuis le deuxième terminal 12 du premier utilisateur 1 (notamment le second flux 200 d’écrit après), et un émetteur apte à transmettre des données au deuxième terminal 12, l’émetteur pouvant distinct ou commun à l’émetteur mentionné ci-avant.
Dans l’exemple décrit ici, les canaux de communication entre le serveur 30 de l’entité tierce 3 et le deuxième terminal 12 du premier utilisateur 1, ainsi que les canaux de communication entre le serveur 30 (ou premier transmetteur) de l’entité tierce 3 et la partie arrière-plan de l’unité 20 du second utilisateur 2, sont sécurisés.
Dans un mode de réalisation particulier, le dispositif de transaction 20 comporte un comparateur de suites de codes comparant une première suite de codes transmise dans un premier flux du dispositif de transaction depuis un serveur de l’entité tierce à une seconde suite de code reçue dans un second flux reçu depuis un deuxième terminal du premier utilisateur. Le dispositif de transaction 20 comporte, en particulier, un premier transmetteur émettant le premier flux au serveur de l’entité tierce et/ou un récepteur recevant le second flux. Le dispositif de transaction 20 comporte, notamment, un dispositif d’autorisation autorisant la poursuite de la transaction entre le premier utilisateur et le second utilisateur par l’intermédiaire de l’entité tierce. Eventuellement, le dispositif de transaction 20 comporte une interface utilisateur permettant au premier utilisateur au moyen de son premier terminal d’initialiser une transaction avec le second utilisateur, tel qu’un site web. Dans ce mode de réalisation particulier, par comparaison aux modes de réalisation décrits ci-après, la comparaison des codes et/ou l’autorisation sont réalisées par le dispositif de transaction 20 plutôt que par le serveur 30 de l’entité tierce 3.
En référence à la figure 2, les procédés débutent lorsqu’une transaction est préalablement entamée. Par exemple, le premier utilisateur 1, en tant que client du second utilisateur 2, sélectionne sur le site internet un ensemble de un ou plusieurs articles qu’il souhaite acquérir. Cet ensemble, habituellement appelé « panier », comprend un ensemble d’informations considérées comme non sensibles. Par exemple, des identifiants d’articles, des quantités d’articles, des dates de disponibilité, des dates de livraison possibles et/ou des prix d’articles. Ici, le panier ne comprend pas d’information bancaire ou personnelle relatives au premier utilisateur 1. Autrement dit, à ce stade, le premier utilisateur 1 n’est pas identifié et est sensiblement anonyme du point de vue de l’unité 20 et du second utilisateur 2. Aucune donnée sensible n’a transité par le premier terminal 11 et les canaux de communication reliant le premier terminal 11 à l’unité 20, potentiellement non sécurisés.
En variante, le premier utilisateur 1 peut accepter de transmettre des données personnelles, par exemple en s’identifiant auprès du site internet du second utilisateur 2. Ceci peut, par exemple, permettre à l’unité 20 du second utilisateur 2 de s’adapter au premier utilisateur 1 en adaptant la navigation sur le site internet à des préférences préenregistrées ou en suggérant des articles en fonction de préférences du premier utilisateur 1. Dans ce cas, quelques données personnelles telles qu’un identifiant et un mot de passe peuvent être entrées sur le premier terminal 11. Néanmoins, les données bancaires du premier utilisateur 1 n’y sont pas entrées.
Lorsque le panier est validé, c’est-à-dire que le premier utilisateur 1 indique qu’il souhaite maintenant régler ses achats, la transaction est entamée. Cet état initial correspond à l’opération référencée 1001 en figure 2. Dans l’exemple d’application proposé ici, l’opération 1001 est mise en œuvre dès la validation du panier. En variante, le second utilisateur 2 peut proposer au premier utilisateur 1 la mise en œuvre du système selon l’invention comme un choix parmi d’autres méthodes de transactions, par exemple des méthodes connues en elles-mêmes. Ainsi, le premier utilisateur 1 peut choisir le niveau de sécurisation de ses données, par exemple en fonction de sa confiance pour le premier terminal 11. En cas de choix possible dans les méthodes transaction, l’opération 1001 est mise en œuvre lorsque le premier utilisateur 1 choisi une méthode selon l’invention.
La transaction est initialisée par l’opération 1001.
Dans une opération 1002, l’unité 20 transmet au serveur 30 une requête comprenant un identifiant de la transaction initialisée et un identifiant de l’unité 20. L’identifiant de l’unité 20 peut être intégré à l’identifiant de la transaction, par exemple au moyen d’un numéro unique de transaction dont une portion correspond à un identifiant de l’unité 20. L’identifiant de la transaction permet notamment de distinguer, par la suite, deux transactions simultanées issues d’une même unité 20.
La requête peut en outre être accompagnée de la fourniture de données relatives à la transaction en cours, par exemple le prix à payer. Dans ce cas, le serveur 30 mémorise les données relatives à la transaction en cours afin de les appeler ultérieurement pour confirmer ou infirmer la transaction. En variante, les données relatives à la transaction en cours peuvent être transmises de l’unité 20 au serveur 30 au cours d’une opération ultérieure.
La requête peut aussi comprendre une liste de type de données que le second utilisateur 2 souhaite obtenir. Une telle liste peut comprendre une classification du type de données souhaitées. Par exemple, l’obtention par le second utilisateur 2 d’une adresse de livraison peut être classée comme un type de données impératif, c’est-à-dire en l’absence de laquelle l’unité 20 ne confirmera pas la transaction. Dans le cas où une adresse de livraison n’est pas obtenue, la transaction ne peut pas aboutir. Au contraire, l’obtention d’un numéro de téléphone du premier utilisateur 1 peut être classée comme facultative. En variante, la requête est dépourvue de liste de données souhaitées. Une telle liste peut être établie à titre général pour toute transaction, par exemple lors de la souscription du second utilisateur 2 aux services de l’entité tierce 3, ou ultérieurement lors de la vérification de la transaction. Une telle liste peut aussi ne pas être établie.
Dans une opération 1003, le serveur 30 génère une première suite 101 de codes propre à la transaction. Ue serveur 30 comprend donc un générateur de codes.
Dans l’exemple décrit ici, la première suite 101, ou série, de codes est générée pour chaque transaction. Ue générateur de codes est un générateur de nombres pseudo-aléatoires (ou PRNG pour « PseudoRandom Numher Generator » en anglais). Ue générateur met en œuvre un algorithme apte à générer des codes dynamiques issus d’une graine propre à chaque second utilisateur 2. Ua graine est tirée d’une clé privée du second utilisateur 2. Ue générateur de codes peut générer un nombre quasi-infini et sensiblement en continu composé d’une suite de codes. Ainsi, la suite de codes peut aussi être vue comme un code dynamique. Ua suite de codes peut par exemple être générée sensiblement en continu pendant toute la durée de la transaction.
Ainsi, l’opération 1003 de génération de suite de codes débute à réception de la requête depuis l’unité 20 et peut se poursuivre jusqu’à la fin de la transaction et concurremment aux opérations décrites ci-après.
Générer une suite de codes en continu, ou un code dynamique permet de complexifier le décodage par un tiers mal intentionné. Or le code devient inutile à l’issu de la transaction. Il suffit donc que le code reste indéchiffrable le temps de la transaction.
En variante, d’autres types de générateurs de codes peuvent être mis en œuvre pour générer une première suite 101 de codes.
Dans une opération 1004, le serveur 30 transmet à l’unité 20 la première suite 101 de codes. Ici, la première suite 101 est transmise dans un premier flux 100 de données transmis du serveur 30 à l’unité 20. Le premier flux 100 transite par un canal sécurisé entre le serveur 30 et l’unité 20. Le premier flux 100 est sensiblement continu (sous forme de « streaming » en anglais) jusqu’à la fin de la transaction, aux défauts et erreurs près dans la communication entre le serveur 30 et l’unité 20. Autrement dit, en fonction de la qualité de la communication, des parties de la première suite 101 peuvent être manquantes à réception par l’unité 20.
La première suite 101 est en outre mémorisée par le serveur 30. La première suite 101 est enregistrée associée à des données identifiant la transaction.
Dans une opération 1005, l’unité 20 transmet au premier terminal 11 le premier flux 100 reçu de l’unité 20, incluant la première suite 101. Autrement dit, l’unité 20 fait office de relais entre le serveur 30 et le premier terminal 11. Le premier flux 100 est aussi sensiblement continu entre le serveur 30 et l’unité 20. Des défauts et erreurs dans la communication entre le serveur 30 et l’unité 20 et entre l’unité 20 et le premier terminal 11 peuvent entraîner des pertes entre la première suite 101 générée par le serveur 3 et la première suite 101 réceptionnée par le premier terminal 11. De telles pertes peuvent être considérées comme négligeables. Néanmoins, l’éventualité de telles pertes sera prise en compte dans la suite.
Dans une opération 1006, à réception du premier flux 100 par le premier terminal 11, le premier terminal 11 est agencé pour diffuser un contenu multimédia 130 incluant au moins une partie de la première suite 101 de codes. Le contenu multimédia 130 peut comprendre, par exemple, du son, des images fixes, des images animées, des vidéos ou une combinaison de tels médiums. Dans l’exemple décrit ici, le contenu multimédia 130 est diffusé via l’écran 111 et/ou le hautparleur 112 du premier terminal 11.
Dans l’exemple décrit ici, la première suite 101 est encodée en un contenu multimédia 130 par le serveur 30 lui-même après la génération des codes et avant transmission à l’unité 20. Ainsi, la première suite 101 est présente sous forme de contenu multimédia 130 dès sa transmission à l’unité 20 du second utilisateur 2 dans le premier flux 100. Le contenu multimédia 130 est diffusé en streaming par le serveur 30 jusqu’au premier terminal 11 en passant par l’unité 20. En variante, la première suite 101 peut être encodée en un contenu multimédia 130 o posteriori, par exemple par l’unité 20 avant d’être transmis au premier terminal 11.
Dans une étape 1007, le contenu multimédia 130 diffusé par le premier terminal 11 est capturé par le deuxième terminal 12. Dans l’exemple décrit ici, la capture comprend :
- photographier et/ou filmer, au moyen du capteur optique 121 du deuxième terminal 12, l’écran d’affichage 111 du premier terminal 11 affichant une succession d’images fixes ou animées, ou une vidéo, et/ou
- capter, au moyen du microphone 122 du deuxième terminal 12, du son émis par le haut-parleur 112 du premier terminal 11.
Les capteurs du deuxième terminal 12 mis à contribution sont choisis compatibles avec le type de contenu multimédia 130 (sons, images fixes, images animées, vidéos ou combinaison des formes précédentes).
Dans l’exemple d’application décrit ci-avant, le second utilisateur 2 utilise son smartphone pour capter le contenu diffusé par l’ordinateur du cybercafé.
Optionnellement, le contenu multimédia 130 capté par le deuxième terminal 12 est stocké au moins temporairement dans une mémoire du terminal 12, par exemple une mémoire tampon.
Dans une opération 1008, le deuxième terminal 12 transmet au serveur 30 de l’entité tierce 3 un second flux 200 de données. Le deuxième terminal 12 comprend un transmetteur apte à transmettre, depuis le terminal 12 au serveur 30, le second flux 200. La transmission peut être réalisée en continu (mode streaming). Le second flux 200 de données comprend une seconde suite 201 de codes. La seconde suite 201 de code est tirée du contenu multimédia 130 tel que capté par le deuxième terminal 12. La seconde suite 201 de codes comprend au moins partiellement la première suite de code 101. Les différences entre la première suite 101 et la seconde suite 201 correspondent aux pertes d’informations successives, à savoir ici les pertes d’information dues aux défauts de communication entre le serveur 30 et l’unité 20, aux défauts de communication entre l’unité 20 et le premier terminal 11 et à la perte d’information due au passage du contenu multimédia 130 du premier terminal 11 au deuxième terminal 12 par diffusion-capture. La seconde suite 201 peut donc être vue comme une partie d’une suite de codes tirée du contenu multimédia 130 capté par les capteurs 121 et/ou 122, et validée par le dispositif de validation 125 du deuxième terminal 12. Le dispositif de validation 125 comporte un générateur de flux insérant dans le second flux 200 de données la seconde suite de codes 20 f en réponse à la réception de la première suite fOf.
En effet, la transmission des données par diffusion et capture d’un contenu multimédia peut générer une perte d’information substantielle. Néanmoins, il est inutile de connecter le premier terminal 11 et le deuxième terminal 12 l’un à l’autre via une connexion physique ou sans fd. Le premier utilisateur 1 peut ainsi s’assurer que le premier terminal 11 et le deuxième terminal 12 ne communiquent pas informatiquement. Le risque pour la sécurité du deuxième terminal 12 et celle des données auxquelles il est possible d’accéder par l’intermédiaire du deuxième terminal 12 est ainsi réduit. Le deuxième terminal 12 ne transmet aucune information au premier terminal 11. La transmission par diffusion-capture est à sens unique. En outre, la transmission par transmission-capture d’un contenu multimédia nécessite des composants et logiciels généralement disponibles sur les terminaux usuels (haut-parleur, écran, microphone, capteur optique et logiciels correspondants). Les risques d’incompatibilité entre le premier terminal 11 et le deuxième terminal 12, notamment les moyens de connexion, sont aussi réduits.
Dans une opération 1009, la seconde suite 201 de codes est extraite du contenu multimédia 130. Autrement dit, le contenu multimédia 130 est déchiffré, totalement ou partiellement, de manière à obtenir la seconde suite 201 de codes.
Dans des modes de réalisation, l’opération 1009 est mise en œuvre, au moins en partie, par le deuxième terminal 12, avant la mise en œuvre de l’opération 1008, soit avant la transmission de la seconde suite 201 au serveur 30. Dans ce cas au moins, le deuxième terminal 12 est équipé d’un module de déchiffrage, aussi nommé dispositif de déchiffrage ou déchiffreur. Le déchiffreur peut prendre la forme d’une application ou d’un logiciel installés sur le deuxième terminal 12. Un tel déchiffreur peut, par exemple, être implémenté dans le dispositif de validation 125 ou, selon le mode de réalisation, mis en œuvre par le dispositif de validation 125 du deuxième terminal 12 et par l’intermédiaire d’une application préalablement installée sur le deuxième terminal 12. Ainsi, des terminaux existants peuvent être rendus conformes au deuxième terminal 12 selon l’invention par une modification logicielle (« software ») sans qu’il soit nécessaire d’intervenir matériellement sur le terminal (« hardware »). En outre, des améliorations peuvent être apportées par des mises à jour du logiciel. De telles applications peuvent être fournies par l’entité tierce 3 fournissant le service. De préférence, lorsqu’un déchiffrage est effectué par le deuxième terminal 12, le déchiffrage est partiel. Ainsi, la quantité de données transmises au serveur 3 est faible et le déchiffrage complet reste centralisé sur le serveur 30.
Ensuite, lors de la mise en œuvre de Eopération 1008 de transmission du second flux 200 au serveur 30, le second flux 200 peut comprendre la seconde suite 201 sous forme au moins partiellement déchiffrée. La transmission peut être réalisée via un canal sécurisé entre le deuxième terminal 12 et le serveur 30. Dans de tels modes de réalisation, la quantité de données transmise depuis le deuxième terminal 12 au serveur 30 est faible, ce qui peut être particulièrement souhaitable, par exemple lorsque la quantité de données reçue et/ou transmise influe sur les coûts supportés par le second utilisateur 2, par exemple dans le cadre d’un abonnement de téléphonie mobile.
Dans des modes de réalisation, l’opération 1009 est mise en œuvre par le serveur 30, après la mise en œuvre de l’opération 1008 et à réception du second flux 200 depuis le deuxième terminal 12. Dans ce cas, le deuxième terminal 12 peut être dépourvu de déchiffreur. Le second flux 200 peut comprendre par exemple le contenu multimédia 130 sous une forme brute, non déchiffrée, telle que captée par le deuxième terminal 12. Le second flux 200 comprend des données de capture du contenu multimédia 130. Le serveur 30 comprend un déchiffreur. Dans de tels modes de réalisation, la puissance de calcul du dispositif de validation 125, du deuxième terminal 12 n’est pas utilisée pour le déchiffrage et reste donc disponible pour d’autres usages. En outre, le déchiffreur peut être localisé de manière centralisée sur le serveur 30. En centralisant le module de déchiffrage sur le serveur 30, des caractéristiques de codage du contenu multimédia peuvent rester en partie secrètes, accessibles seulement à l’entité tierce 3, ce qui complexifie la tâche de tiers mal intentionnés.
Après les opérations 1008 et 1009, l’opération 1010 est mise en œuvre. Dans l’opération 1010, la première suite 101 de codes et la seconde suite 201 de codes sont comparées l’une à l’autre. Le serveur 30 comprend un module de comparaison, aussi nommé dispositif de comparaison ou comparateur. Le comparateur peut prendre la forme d’une application ou d’un logiciel installés sur le serveur 30. Un tel comparateur peut, par exemple, être implémenté dans le serveur 30 ou mis en œuvre par le serveur 30 par l’intermédiaire d’une application préalablement installée sur le serveur 30. Dans l’exemple décrit ici, le serveur 30 vérifie que le niveau de correspondance de la seconde suite 201 avec la première suite 101 est supérieur à une valeur seuil C de correspondance prédéfinie, par exemple exprimée en pourcentage. La valeur seuil C est sélectionnée de manière à détecter une identité théorique des codes de la seconde suite 201 et des codes de la première suite 101 tout en tenant compte des erreurs de transmission pouvant avoir lieu entre la transmission du premier flux 100 à l’unité 20 du second utilisateur 2 (opération 1004) et la réception du second flux 200 (opération 1008) depuis le deuxième terminal 12 du premier utilisateur 1. Autrement dit, l’utilisation d’une valeur seuil C inférieure à 100%, qui correspondrait à une identité parfaite, permet de tenir compte des pertes d’information décrites ci-avant. La valeur seuil C peut être sélectionnée égale à (100 - X) %, où la valeur de X est sélectionnée en fonction de la qualité des moyens de communication mis en œuvre, par exemple proportionnelle à la somme des pourcentages de pertes par erreur de transmission de chacune des transmission depuis la transmission du premier flux 100 à l’unité 20 du second utilisateur 2 jusqu’à la réception du second flux 200 depuis le second terminal 12 du premier utilisateur 1.
Lorsque le niveau de correspondance est suffisant, ici supérieur à la valeur seuil C, alors une opération 1011 est mise en œuvre.
Optionnellement, le serveur 30 peut mettre en œuvre, par exemple préalablement à l’opération 1010, une vérification de la validité de la seconde suite 200 de codes reçue, par exemple en fonction des règles de génération pseudo-aléatoire. Même avant d’avoir identifié la transaction et l’unité 20 correspondant au second flux 200 reçu, une analyse des codes permet de vérifier si les codes sont compatibles avec les règles de génération pseudo-arbitraires mises en œuvre à la génération des codes. Une incompatibilité indique au contraire une corruption de la transaction. Des mesures de sécurité peuvent être prises en conséquence, notamment la fin de la transaction si cette dernière peut être identifiée par la suite (opération 1020). Ainsi, la sécurité contre les fraudes est encore améliorée.
Dans l’exemple représenté en figure 2, l’opération 1010 est répétée jusqu’à ce qu’à détecter un niveau de correspondance suffisant entre une première suite 101 transmise (opération 1004) et une seconde suite 201 reçu (opération 1008). Ceci est particulièrement avantageux en combinaison avec un fonctionnement en continu du procédé : lorsque la suite de codes est générée de manière sensiblement continue, le premier flux 100 ainsi que le second flux 200 peuvent aussi être transmis sensiblement en continu (en mode « streaming »). Une rupture temporaire du circuit de transmission de la suite de codes n’interrompt pas le processus.
Dans des modes de réalisation, lorsqu’aucune correspondance suffisante d’une seconde série 201 n’est atteinte avec une première série 101, il peut être mis fin au processus pour le second flux 200 reçu. De même, lorsqu’aucune correspondance suffisante d’une première série 101 n’est atteinte avec une seconde série 201, il peut être mis fin au processus pour la transaction correspondante. Dans l’exemple décrit ici, les transactions initialisées au niveau du serveur 30 (opération 1003) et les second flux 200 reçus par le serveur 30 (opération 1008) ne sont pas encore associés les uns aux autres par le serveur 3 (opération ultérieure 1011). Dans de tels cas, l’arrêt des itérations de comparaisons (opération 1010) et l’arrêt de la transaction (opérations 1003 et 1004) sont traités de manière distincte.
Dans l’opération 1015 représentée en figure 2, la condition d’arrêt des itérations et de la fin du processus peut par exemple être basée sur une durée de validité présumée. Par exemple, un chronomètre est lancé à réception du second flux 200 (opération 1008). Si la durée écoulée dépasse une durée prédéterminée, alors il est mis fin au processus de comparaison (opération 1010). Le second flux 200 est alors ignoré. Dans ce cas au moins, le serveur 30 est équipé d’une horloge. L’opération 1015 peut aussi limiter le nombre d’itérations, par exemple au moyen d’un compteur d’itérations. D’autres conditions peuvent être mises en œuvre au cours de l’opération 1015. De préférence, un message d’erreur et/ou d’interruption de la transaction est envoyé en réponse au deuxième terminal 12 à l’origine du second flux 200.
Lors de l’initialisation de la transaction par le serveur 3, un chronomètre peut aussi être lancé (opérations 1003 et 1004). Si la durée écoulée dépasse une durée prédéterminée, alors il est mis fin aux processus de génération de codes et de transmission du premier flux (100) (opérations 1003 et 1004). Dans ce cas au moins, le serveur 30 est équipé d’une horloge. De préférence, un message d’erreur et/ou d’interruption de la transaction est envoyé en réponse à l’unité 20 à l’origine de la requête (opération 1002). Ainsi, après initialisation de la transaction, le serveur 3 attend un retour d’un deuxième appareil 12 (non encore identifié) en réponse à la transaction. En cas d’absence de réponse satisfaisante (une seconde série 201 de codes correspondant à la première série 101), il est mis fin à la transaction (opération 1020).
Dans l’opération 1011, le premier utilisateur 1, le second utilisateur 2, et la transaction courante sont associés. Le serveur 30 identifie le premier utilisateur 1 comme étant le client du second utilisateur 2 dans la transaction courante. Par cette association, l’entité tierce 3 peut assurer le rôle d’intermédiaire de confiance entre le premier utilisateur 1 et le second utilisateur 2 dans le cadre de la transaction. Afin d’identifier le premier utilisateur 1, le serveur 30 peut recevoir un identifiant du premier utilisateur 1 transmis par le deuxième terminal 12, par exemple inclus dans le second flux 200 de données.
Dans une opération 1012, la poursuite de la transaction est autorisée entre le premier utilisateur 1 et le second utilisateur 2 par l’intermédiaire du serveur 30, et donc de l’entité tierce 3. Dans des modes de réalisation, l’autorisation est mise en œuvre par le serveur 30. Le serveur 30 comporte un dispositif d’autorisation autorisant la poursuite de la transaction entre le premier utilisateur 1 et le second utilisateur 2 associés, par l’intermédiaire de l’entité tierce 3.
Dans de premiers modes de réalisation, l’opération 1012 d’autorisation de poursuite de la transaction comprend la transmission de données depuis le deuxième terminal 12 du premier utilisateur 1 jusqu’à l’unité 20 du second utilisateur 2 en passant par le serveur 30 faisant office de relai. Ainsi, le premier utilisateur 1 peut transmettre des données sensibles, par exemple bancaires et/ou personnelles, sans passer par le premier terminal 1 potentiellement non sécurisé.
Dans de seconds modes de réalisation, le serveur 30 transmet des données sensibles relatives au premier utilisateur 1 à l’unité 20 de manière au moins partiellement automatique. Par exemple, le serveur 30 peut avoir accès à certaines au moins des données sensibles du premier utilisateur
1. Le premier utilisateur 1 peut avoir fourni à l’entité tierce 3 certaines des données sensibles préalablement à la transaction, par exemple lors d’une souscription au service par le premier utilisateur 1. Par exemple, le premier utilisateur peut avoir fourni à l’entité tierce une adresse de livraison par défaut et des coordonnées bancaires. De telles données sont stockées sur une ou plusieurs bases de données accessibles au serveur 30. Le premier utilisateur 1 peut aussi avoir donné une autorisation préalable au serveur 30 de transmettre lesdites données de manière automatisée dès qu’une transaction est autorisée. Dans ce cas, le serveur 30 peut être dispensé de demander une confirmation supplémentaire au premier utilisateur 1 à chaque transaction. L’autorisation de la poursuite de la transaction peut comprendre : envoyer des données sensibles relatives au premier utilisateur 1 à l’unité 20 du second utilisateur 2 depuis le serveur 30 de l’entité tierce 3.
De tels modes de réalisation sont particulièrement avantageux lorsque l’entité tierce 3 contrôlant le serveur 30 est un organisme tel qu’un organisme bancaire habituel du premier utilisateur 1.
Souvent pour des raisons réglementaires, les organismes bancaires disposent de certaines au moins des informations bancaires et personnelles relatives au premier utilisateur 1. Dans de tels cas, le serveur 30 peut, plutôt que de transmettre les coordonnées bancaires à l’unité 20, transmettre une confirmation de la transaction à l’unité 20. Les échanges financiers peuvent alors être réalisés a posteriori : l’entité tierce 3 faits alors en outre fonction d’intermédiaire financier. Par exemple, l’entité tierce 3 peut se substituer au premier utilisateur 1 en tant que payeur vis-à-vis du second utilisateur 2 et regrouper les paiements de plusieurs transactions de plusieurs premiers utilisateurs en un paiement unique, par exemple par un paiement périodique de l’ensemble des transactions confirmées durant une période antérieure. De même, le serveur 30 peut facturer chaque premier utilisateur 1 en regroupant plusieurs transactions d’un même premier utilisateur 1.
Dans de troisièmes modes de réalisation, le serveur 30 peut transmettre au deuxième terminal 12 du premier utilisateur 1 une demande de confirmation de la transaction. Une telle demande peut comprendre, par exemple, une référence de la transaction, un prix correspondant à la transaction et optionnellement des demandes d’informations complémentaires de la part du second utilisateur 2 telle que cela a été décrit ci-avant (courriel, numéro de téléphone, etc.). A réception de la confirmation de la transaction depuis le deuxième terminal 12 du premier utilisateur 1, le serveur 30 peut à son tour transmettre une confirmation de la transaction à l’unité 20 du second utilisateur 2, optionnellement accompagnées de données complémentaires fournies par le premier utilisateur 1 via le deuxième terminal 12.
Dans tous les cas, le serveur 30 peut optionnellement transmettre une confirmation de la transaction au premier utilisateur 1 via le deuxième terminal 12.
Il est mis fin au processus dans l’opération 1020. L’opération 1020 indique la fin du processus, que la transaction soit finalement réalisée ou annulée.
Le serveur 30 peut, à tout moment, recevoir un refus de confirmation, soit une infirmation, de la transaction de la part du premier utilisateur 1 et/ou de la part du second utilisateur 2. Dans ce cas, il est mis fin au processus par l’opération 1020, optionnellement après avoir transmis des messages d’annulation de la transaction au premier utilisateur 1 et/ou au second utilisateur 2.
Lorsqu’une transaction se termine (opération 1020), quelle que soit son issue, la génération de codes et la transmission des flux peuvent être stoppées. Ainsi, le premier flux 100 est transmis en continue en réponse à une requête du dispositif de transaction 20 adressée au serveur 3, et est interrompue à la clôture de la transaction. Par clôture de la transaction, on entend ici soit une réalisation, soit une annulation de la transaction. Les codes mémorisés peuvent être effacés. Ainsi, les comparaisons de l’opération 1010 peuvent être limitées aux transactions actives pour associer chaque second flux 200 reçu par le serveur 30 à une transaction active.
En fonction des modes de réalisation choisis ou des combinaisons de modes de réalisation, certains actes, actions, évènements ou fonctions de chacune des méthodes et procédés décrits dans le présent document peuvent être effectués ou se produire selon un ordre différent de celui dans lequel ils ont été décrits, ou peuvent être ajoutés, fusionnés ou bien ne pas être effectués ou ne pas se produire, selon le cas. En outre, dans certains modes de réalisation, certains actes, actions ou évènements sont effectués ou se produisent concurremment et non pas successivement.
Sauf mention contraire ou incompatibilité manifeste, les caractéristiques de chacun des modes de réalisation et variantes décrits ci-dessus peuvent être mises en œuvre ensemble, ou séparément, ou bien se substituer les uns aux autres.
La présente description divulgue un ensemble de possibilités techniques sans considération d’ordre règlementaire. Bien entendu, la mise en œuvre de l’invention est adaptée aux règlementations applicables. Par conséquent, la présente description ne saurait être interprétée comme une quelconque admission ou incitation au non-respect d’une réglementation, en particulier des réglementations applicables dans les domaines bancaires, financiers et fiscaux et dans les domaines de la conservation et de la transmission de données.
L’invention ne se limite pas aux exemples de procédés, serveurs, terminaux, systèmes et programmes décrits ci-avant, seulement à titre d’exemple.

Claims (15)

  1. Revendications
    1. Procédé de sécurisation de transaction initialisée entre un premier terminal (11) de communication à disposition d’un premier utilisateur (1) et un dispositif de transaction (20) d’un second utilisateur (2) par l’intermédiaire d’un serveur (30) d’une entité tierce (3), le procédé comprenant :
    comparer :
    - une première suite de codes (101) transmise avec un premier flux (100) de données associé à la transaction, du serveur (30) de l’entité tierce (3) au dispositif de transaction (20) du second utilisateur (2), les données du premier flux (100) comprenant la première suite de codes (101) tirés d’une clé privée associée au second utilisateur (2), et
    - une seconde suite de codes (201) reçue avec un second flux (200) de données par le serveur (30) de l’entité tierce (3) depuis un deuxième terminal (12) de communication à disposition du premier utilisateur (1), ledit deuxième terminal (12) transmettant le second flux (200) en réponse à la réception du premier flux (100), la comparaison déclenchant, en cas de correspondance entre les deux suites de codes (101 ; 201) associer le premier utilisateur (1), le second utilisateur (2) et la transaction, permettant de délivrer une autorisation de la poursuite de la transaction entre le premier utilisateur (1) et le second utilisateur (2) associés par l’entité tiers (3).
  2. 2. Procédé selon la revendication 1, dans lequel le premier flux (100) est transmis en continue en réponse à une requête du dispositif de transaction (20) adressée au serveur (3), et est interrompue à la clôture de la transaction.
  3. 3. Procédé selon l’une des revendications précédentes, dans lequel la première suite de codes (101) du premier flux (100) prend la forme d’un contenu multimédia (130).
  4. 4. Procédé selon l’une des revendications précédentes, dans lequel la comparaison de la première suite de codes (101) et de la seconde suite de codes (201) comprend :
    - vérifier que le niveau de correspondance de la seconde suite (201) avec la première suite (101) est supérieur à une valeur seuil (C) de correspondance prédéfinie et inférieure à 100%.
  5. 5. Procédé selon l’une des revendications précédentes, dans lequel le premier flux (100) et/ou le second flux (200) sont chacun transmis via un canal sécurisé, respectivement entre le serveur (30) de l’entité tierce (3) et le dispositif de transaction (20) du second utilisateur (2), respectivement entre le deuxième terminal (12) du premier utilisateur (1) et le serveur (30) de l’entité tierce (3).
  6. 6. Procédé selon l’une des revendications précédentes, dans lequel l’autorisation de la poursuite de la transaction comprend :
    - envoyer une demande de confirmation de la transaction au deuxième terminal (12) du premier utilisateur (1) depuis le serveur (30) de l’entité tierce (3),
    - réceptionner une confirmation de la transaction sur le serveur (30) de l’entité tierce (3) depuis le deuxième terminal (12) du premier utilisateur (1),
    - envoyer une confirmation de la transaction au dispositif de transaction (20) du second utilisateur (2) depuis le serveur (30) de l’entité tierce (3).
  7. 7. Procédé selon l’une des revendications précédentes, dans lequel le second flux (200) comprend des données de capture d’un contenu multimédia (130) via au moins un capteur (121, 122) du deuxième terminal (12), la seconde suite de codes (201) étant incluse dans les données de capture du contenu multimédia (130).
  8. 8. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications 1 à 7, lorsque ce programme est exécuté par un processeur.
  9. 9. Serveur (30) d’une entité tierce (3) pour sécuriser une transaction initialisée entre un premier terminal (11) de communication à disposition d’un premier utilisateur (1) et un dispositif de transaction (20) d’un second utilisateur (2), le serveur (30) étant apte à communiquer avec un deuxième terminal (12) de communication à disposition du premier utilisateur (1) et avec le dispositif de transaction (20) du second utilisateur (2), le serveur (30) comportant :
    - un comparateur :
    - d’une première suite de codes (101) transmise avec un premier flux (100) de données associé à la transaction, par un émetteur du serveur (30) de l’entité tierce (3) au dispositif de transaction (20) du second utilisateur (2), les données du premier flux (100) comprenant la première suite de codes (101) tirés d’une clé privée associée au second utilisateur, et
    - d’une seconde suite de codes (201) reçue avec un second flux (200) de données par un récepteur du serveur (30) de l’entité tierce (3) depuis un deuxième terminal (12) de communication à disposition du premier utilisateur (1), ledit deuxième terminal (12) transmettant le second flux (200) en réponse à la réception du premier flux (100), le comparateur étant apte, en cas de correspondance entre les deux suites de codes (101 ; 201), à associer le premier utilisateur (1), le second utilisateur (2) et la transaction, déclenchant
    - un dispositif d’autorisation de la poursuite de la transaction entre le premier utilisateur (1) et le second utilisateur (2) associés, par l’intermédiaire de l’entité tiers (3).
  10. 10. Procédé de validation de transaction initialisée entre un premier terminal (11) de communication à disposition d’un premier utilisateur (1) et un dispositif de transaction (20) d’un second utilisateur (2), mis en œuvre par un deuxième terminal (12) de communication à disposition du premier utilisateur (1), le procédé comprenant : insérer dans un second flux (200) de données une seconde suite de codes (201) en réponse à une réception d’une première suite de codes (101) associée à la transaction par le dispositif de transaction (20) du second utilisateur (2) dans un premier flux de données (100) provenant d’un serveur (30) d’une entité tierce (3), la seconde suite de codes (201) étant tirée d’une clé privée associée au second utilisateur (2), le second flux (200) étant apte à être transmis depuis le deuxième terminal (12) au serveur (30) de l’entité tierce (3).
  11. 11. Procédé selon la revendication 10 comprenant en outre :
    - capturer un contenu multimédia (130) contenu dans le premier flux (100), reçu par le premier terminal (11) du dispositif de transaction (20), et reproduit par le premier terminal (11), la capture étant réalisée via au moins un capteur (121, 122) du deuxième terminal (12), le contenu multimédia (130) incluant la première suite de codes (101).
  12. 12. Procédé selon la revendication 11, dans lequel la capture du contenu multimédia (130) reproduite par le premier terminal (11) comprend l’une au moins des opérations suivantes :
    - photographier et/ou frimer, au moyen d’un capteur optique (121) du deuxième terminal (12), un écran d’affichage (111) du premier terminal (11) affichant une succession d’images fixes ou animées, ou une vidéo ;
    - capter, au moyen d’un microphone (122) du deuxième terminal (12), du son émis par un hautparleur (112) du premier terminal (11).
  13. 13. Procédé selon l’une des revendications 11 et 12, comprenant en outre, entre la capture du contenu multimédia (130) et la transmission de l’au moins une partie de la première suite de codes (101), une opération de déchiffrage des codes contenus dans le contenu multimédia (130) capturé par le deuxième terminal (12), le second flux (200) apte à être transmis comprenant la seconde suite de codes (201) sous forme déchiffrée et tirée du contenu multimédia (130) capturé.
  14. 14. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications 10 à 13, lorsque ce programme est exécuté par un processeur.
  15. 15. Terminal (12) de communication apte à communiquer avec un serveur (30) et comprenant 5 un dispositif de validation (125) comportant :
    un générateur de flux insérant dans un second flux (200) de données une seconde suite de codes (201) en réponse à une réception d’une première suite de codes (101) associée à la transaction par le dispositif de transaction (20) du second utilisateur (2) dans un premier flux de données (100) provenant d’un serveur (30) d’une entité tierce (3), la seconde suite de codes (201) étant
    10 tirée d’une clé privée associée au second utilisateur (2), le second flux (200) étant apte à être transmis par un transmetteur du deuxième terminal (12) au serveur (30) de l’entité tierce (3).
    2/2
FR1662729A 2016-12-19 2016-12-19 Securisation de transaction Pending FR3060818A1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
FR1662729A FR3060818A1 (fr) 2016-12-19 2016-12-19 Securisation de transaction
CN201780073985.2A CN110383312B (zh) 2016-12-19 2017-12-13 实现交易安全的方法和系统
US16/470,825 US20190311349A1 (en) 2016-12-19 2017-12-13 Securing transactions
PCT/FR2017/053542 WO2018115641A1 (fr) 2016-12-19 2017-12-13 Sécurisation de transaction
EP17822409.3A EP3555829A1 (fr) 2016-12-19 2017-12-13 Sécurisation de transaction

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1662729A FR3060818A1 (fr) 2016-12-19 2016-12-19 Securisation de transaction
FR1662729 2016-12-19

Publications (1)

Publication Number Publication Date
FR3060818A1 true FR3060818A1 (fr) 2018-06-22

Family

ID=58314470

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1662729A Pending FR3060818A1 (fr) 2016-12-19 2016-12-19 Securisation de transaction

Country Status (5)

Country Link
US (1) US20190311349A1 (fr)
EP (1) EP3555829A1 (fr)
CN (1) CN110383312B (fr)
FR (1) FR3060818A1 (fr)
WO (1) WO2018115641A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005107849A (ja) * 2003-09-30 2005-04-21 Nec Corp 決済支援システムおよび決済支援方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070143230A1 (en) * 2003-06-30 2007-06-21 Selvanathan Narainsamy Transaction verification system
FR2959896B1 (fr) * 2010-05-06 2014-03-21 4G Secure Procede d'authentification d'un utilisateur requerant une transaction avec un fournisseur de service
CN103944734A (zh) * 2014-04-25 2014-07-23 天地融科技股份有限公司 数据安全交互方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005107849A (ja) * 2003-09-30 2005-04-21 Nec Corp 決済支援システムおよび決済支援方法

Also Published As

Publication number Publication date
EP3555829A1 (fr) 2019-10-23
CN110383312B (zh) 2023-05-16
CN110383312A (zh) 2019-10-25
WO2018115641A1 (fr) 2018-06-28
US20190311349A1 (en) 2019-10-10

Similar Documents

Publication Publication Date Title
EP2715631B1 (fr) Procede de paiement a distance, a partir d'un dispositif utilisateur, d'un panier d'achat sur un serveur marchand et systeme associe
EP3168769B1 (fr) Procédé d'aide à l'authentification d'un utilisateur, serveur et programme d'ordinateur correspondants
EP3857413A1 (fr) Procede de traitement d'une transaction, dispositif, systeme et programme correspondant
FR3061971A1 (fr) Procede d'authentification en deux etapes, dispositif et programme d'ordinateur correspondant
FR3060818A1 (fr) Securisation de transaction
EP2747444A1 (fr) Procédé pour accéder à un service proposé par un serveur distant à l'aide d'un code QR
EP3107023A1 (fr) Procédé, dispositif et programme d'authentification sans fil d'un terminal de payment
EP2172896A1 (fr) Méthode de gestion d'une valeur dans un dispositif à prépaiement
EP2897095B1 (fr) Procédé de sécurisation d'une transaction réalisée par carte bancaire
WO2018029564A1 (fr) Systeme et procede d'authentification sans mot de passe d'un utilisateur d'un systeme applicatif par un serveur central
EP4348459A1 (fr) Procédé de traitement d'une transaction, dispositif et programme correspondant
WO2021044102A1 (fr) Procédé pour activer des droits d'accès à un service auquel a souscrit un abonné
EP4320534A1 (fr) Méthode de contrôle d'accès à un bien ou service distribué par un réseau de communication de données
EP3900293A1 (fr) Procédé et système de sécurisation d'opérations, et poste utilisateur associé
WO2010125318A1 (fr) Procede de suspension et d'activation d'un service dans un reseau mobile
FR3081246A1 (fr) Procede de realisation d'une transaction, terminal, serveur et programme d'ordinateur correspondant
OA18272A (en) Methods of implementing a transaction via a mobile terminal.
FR2945173A1 (fr) Procede d'authentification d'un terminal de communication mobile lors d'un acces a une plateforme de services via un reseau mobile
EP3062538A1 (fr) Procédé d'authentification, procédé d'autorisation d'accès, terminal, serveur, composant radio-étiquette, produit, produit programme d'ordinateur et support de stockage correspondant
EP2425388A1 (fr) Procede de taxation et d'acces a un service depuis un terminal de communication mobile
OA17954A (en) Method for implementing a transaction via a mobile terminal
FR3024258A1 (fr) Securication d'une transaction pour un ou plusieurs produits et/ou services
WO2013124582A1 (fr) Procede pour generer un coupon electronique sous forme de fichier electronique attestant un droit a l'utilisateur qui le detient
WO2016034812A1 (fr) Sécurisation de clés de cryptage pour transaction sur un dispositif dépourvu de module sécurisé
FR3007921A1 (fr) Procede de validation d'une transaction

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20180622

RX Complete rejection