FR3003977A1 - Procede de securisation de transactions entre terminaux mobiles - Google Patents

Procede de securisation de transactions entre terminaux mobiles Download PDF

Info

Publication number
FR3003977A1
FR3003977A1 FR1352940A FR1352940A FR3003977A1 FR 3003977 A1 FR3003977 A1 FR 3003977A1 FR 1352940 A FR1352940 A FR 1352940A FR 1352940 A FR1352940 A FR 1352940A FR 3003977 A1 FR3003977 A1 FR 3003977A1
Authority
FR
France
Prior art keywords
transaction
mobile terminal
server
request
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
FR1352940A
Other languages
English (en)
Inventor
Mohammed Achemlal
Chrystel Gaber
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
France Telecom 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 France Telecom SA filed Critical France Telecom SA
Priority to FR1352940A priority Critical patent/FR3003977A1/fr
Publication of FR3003977A1 publication Critical patent/FR3003977A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • 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/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • 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/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/3229—Use of the SIM of a M-device as secure element
    • 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/383—Anonymous user system

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Finance (AREA)
  • Medical Informatics (AREA)
  • Databases & Information Systems (AREA)
  • Computer Hardware Design (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La présente invention concerne un procédé de mise en œuvre d'une transaction entre un premier terminal mobile (1a) et un deuxième terminal mobile (1b) comprenant un module de sécurité (12a, 12b), Le procédé étant caractérisé en ce qu'il comprend les étapes suivantes, mises en œuvre par un serveur (3) connecté au réseau (20) : (a) réception depuis le premier terminal mobile (1a) d'une requête de création d'une transaction ; (b) génération d'un identifiant unique de la transaction ; (c) envoi au premier terminal mobile (1a) d'un message d'identification de la transaction comprenant ledit identifiant unique, destiné à être transmis au deuxième terminal mobile (1b) ; (d) réception depuis le deuxième terminal mobile (1b) d'une requête de poursuite de la transaction ; (e) envoi au deuxième terminal mobile (1b) d'un message de soumission de la transaction ; (f) réception depuis le deuxième terminal mobile (1 b) d'une requête de validation de la transaction. La présente invention concerne également d'autres procédés, un serveur, des terminaux mobile, un système, un produit programme d'ordinateur et un moyen de stockage à cet effet.

Description

DOMAINE TECHNIQUE GENERAL La présente invention concerne le domaine du paiement au moyen de terminaux mobiles.
Plus précisément, elle concerne des procédés pour la mise en oeuvre d'une transaction entre un premier et un deuxième terminal mobile. ETAT DE L'ART Les services évolués de paiement sur mobiles déployés aujourd'hui dans les pays émergeants, comme « Orange Money » offert par France Telecom Orange s'appuient sur une infrastructure réseau d'un opérateur mobile pour assurer un certain nombre de fonctions, notamment celles de sécurité. De façon générale, un « client » qui souhaite mettre en oeuvre une transaction financière, par exemple pour l'achat d'un bien transmet son numéro de téléphone à un « marchand » qui propose ce bien et qui transmet à une plate-forme de services via l'infrastructure de réseau mobile des informations relatives à la transaction. Le service utilise les numéros de téléphone pour identifier le client et le marchand et pour mettre en oeuvre la transaction sur des comptes associés à ces numéros de téléphone. Le montant associé est crédité/débité sur les comptes respectifs du client et du marchand. Dans les procédés connus, des messages transportant les données liées à la réalisation de la transaction sont transportées au sein du réseau opérateur sur un canal bas débit appelé « canal USSD » (« Unstructured Supplementary Service Data », Service supplémentaire pour données non structurées). Le canal USSD a été spécifié à l'origine pour transporter les messages de signalisation dans les réseaux « GSM » (pour « Global System for Mobile communications »). Il ne nécessite qu'un accès GSM de base et les services qui empruntent ce canal sont accessibles à partir de n'importe quel terminal mobile. L'avantage de ce canal est d'être toujours disponible et très réactif. Il est par exemple communément utilisé pour un service de suivi de consommation : la composition d'un code USSD particulier de l'opérateur (le plus souvent un numéro de trois chiffres encadré par des « # ») entraîne la réception par le terminal mobile d'un message indiquant à l'utilisateur le forfait restant. Cette technologie présente toutefois des inconvénients : La sécurité applicative est limitée. Les concepteurs de ces solutions ont en effet pris l'hypothèse que le réseau GSM apporte une sécurité native suffisante pour protéger les données des transactions sur terminaux mobiles. Or, la sécurité apportée par le GSM est limitée à la portion comprise entre le terminal et l'infrastructure réseau, car les messages sont véhiculés en clair sur le coeur de réseau. De plus, dans une situation d'itinérance (le terme habituellement utilisé est le terme anglais « roaming »), ces messages transitent en clair sur les réseaux d'opérateurs tiers. En outre, dans sa version deuxième génération, ou 2G, le réseau GSM n'est pas authentifié par la carte SIM. Il est alors possible d'insérer un équipement réseau pirate entre des terminaux mobiles et l'équipement réseau authentique de sorte à intercepter (et éventuellement modifier) le message contenant les informations de transaction. Cette faiblesse est connue dans la communauté des experts en sécurité mobile et de nombreuses démonstrations dans les colloques spécialisés montrent la faisabilité de cette attaque. La sécurité de cette technologie prend par ailleurs comme hypothèse que le terminal mobile n'est pas infecté par un cheval de Troie. Cette hypothèse est discutable étant donné la multiplication de téléphones intelligents, tels que des smartphones, qui accèdent au réseau Internet et peuvent être infectés de la même manière qu'un ordinateur. Il serait souhaitable de disposer d'une solution de transaction via terminaux mobiles qui résolve tous les inconvénients cités.
PRESENTATION DE L'INVENTION La présente invention se rapporte ainsi selon un premier aspect à un procédé de mise en oeuvre d'une transaction entre un premier terminal mobile et un deuxième terminal mobile via un réseau de communication, le premier et le deuxième terminal mobile comprenant un module de sécurité, Le procédé étant caractérisé en ce qu'il comprend les étapes suivantes, mises en oeuvre par un serveur connecté au réseau : (a) réception depuis le premier terminal mobile d'une requête de création d'une transaction comprenant des données de la transaction, ladite requête étant chiffrée pour le serveur par le module de sécurité du premier terminal mobile ; (b) génération d'un identifiant unique de la transaction et association dudit identifiant unique aux données de la transaction ; (c) envoi au premier terminal mobile d'un message d'identification de la transaction comprenant ledit identifiant unique, ledit message étant destiné à être transmis par le premier terminal au deuxième terminal mobile, ledit message étant chiffré pour le serveur ; (d) réception depuis le deuxième terminal mobile d'une requête de poursuite de la transaction comprenant le message d'identification chiffré et des données d'identification du deuxième terminal mobile, ladite requête étant chiffrée pour le serveur par le module de sécurité du deuxième terminal mobile ; (e) déchiffrement de la requête de poursuite de la transaction et association des données d'identification du deuxième terminal avec l'identifiant unique de la transaction ; (f) envoi au deuxième terminal mobile d'un message de soumission de la transaction comprenant l'identifiant unique de la transaction et les données de la transaction associées à l'identifiant unique, ledit message étant chiffré pour le module de sécurité du deuxième terminal mobile ; (g) réception depuis le deuxième terminal mobile d'une requête de validation de la transaction comprenant ledit identifiant unique, ladite requête étant chiffrée pour le serveur par le module de sécurité du deuxième terminal mobile ; (h) déchiffrement, vérification de la requête de validation et mise en oeuvre de la transaction.
L'utilisation des cartes d'identification d'abonné (les cartes SIM) permet que les terminaux mobiles n'interviennent pas dans le procédé, ce qui élimine tout risque de virus. L'utilisation astucieuse d'un chiffrement asymétrique centré sur un serveur intermédiaire permet en outre de dissimuler au mieux des données de transactions, qui ne sont quasiment jamais accessibles. De plus, ces données sont coupées en deux morceaux (l'un relatif au marchand, et l'autre relatif au client), lesquels ne sont réunis qu'à la fin du procédé pour validation. Cela diminue encore les problèmes de sécurité. En outre, le procédé selon l'invention apparaît comme une alternative intéressante à des solutions connues qui reposent sur l'utilisation du canal USSD. En effet, il est prévu que des réseaux du futur, tels que les réseaux « LTE » (de l'anglais « Long Term Evolution ») abandonnent ce canal de communication bas niveau. Par ailleurs, avec le procédé de l'invention, une transaction entre un premier et un deuxième terminal mobile, qui engage par exemple un client et un marchand ne nécessite plus que le client fournisse au marchand son numéro de téléphone, comme c'est le cas avec des solutions de paiement mobile connues. Le numéro de téléphone reste une donnée privée, qu'il n'est pas forcément souhaitable de communiquer. En outre, fournir son numéro de téléphone peut être problématique pour des femmes, dans certains pays. Selon d'autres caractéristiques avantageuses et non limitatives : - la requête de création de la transaction comprend : un type de la transaction ; un montant de la transaction ; un identifiant du module de sécurité du premier terminal ; la requête de poursuite de la transaction comprend, outre le message d'identification de la transaction chiffré : - un identifiant du module de sécurité du deuxième terminal ; et la requête de validation de la transaction comprend, outre le message d'identification de la transaction chiffré : un statut de la transaction ; le montant de la transaction ; l'identifiant du module de sécurité du deuxième terminal. Ces informations, relatives à la transaction, à l'exécution de celle-ci et aux terminaux impliqués permettent de garantir à la transaction une cohérence aux différents stades de son exécution. Certaines de ces informations sont par ailleurs destinées à être affichées à l'attention des utilisateurs des terminaux. - la requête de création d'une transaction comprend en outre un nombre pseudoaléatoire généré par le module de sécurité du premier terminal ; Ce nombre agit comme un mot de passe à usage unique et apporte une sécurité supplémentaire. - ledit nombre pseudo-aléatoire est transmis avec l'identifiant unique dans chacun des messages et requêtes échangés, l'étape (e) comprenant la comparaison : du nombre pseudo-nombre aléatoire de la requête de création de la transaction dont les données de transaction sont associées à l'identifiant unique contenu dans le message d'identification contenu dans ladite requête de poursuite de la transaction ; avec le nombre pseudo-aléatoire contenu dans le message d'identification contenu dans ladite requête de poursuite de la transaction.
Cette combinaison permet une sécurité maximale au moment de la combinaison des deux moitiés de l'information de transaction. - En outre : la requête de création de la transaction est signée avec une clé privée du module de sécurité du premier terminal ; le message d'identification de la transaction et le message de soumission de la transaction sont signés avec une clé privée du serveur ; la requête de poursuite de la transaction et la requête de validation de la transaction sont signées avec une clé privée du module de sécurité du deuxième terminal.
Cette utilisation astucieuse des signatures garantit l'intégrité des requêtes et messages et prévient tout risque d'usurpation d'identité et de piratage associé. - le procédé comprend en outre une étape (il) d'envoi au deuxième terminal mobile d'un message de confirmation de la transaction, ledit message étant chiffré pour le module de sécurité du deuxième terminal mobile ; et/ou une étape (i2) d'envoi au premier terminal mobile d'un message de confirmation de la transaction, ledit message étant chiffré pour le module de sécurité premier terminal mobile. Grâce à ces messages, le client et le marchand savent de façon toujours sure si la transaction a réussi. - un message de confirmation de la transaction comprend : le statut de la transaction ; le montant de la transaction ; le solde après transaction d'un compte associé au module de sécurité du terminal mobile destinataire du message de confirmation. Ce message permet de connaître ainsi l'impact de la transaction une fois qu'elle a eu lieu. - un message de confirmation de la transaction est signé avec une clé privée du serveur. Cela permet encore de prévenir tout risque d'usurpation d'identité et de piratage. - le message d'identification de la transaction est transmis du premier terminal au deuxième terminal soit via affichage puis lecture qu'un code barre matriciel, soit via communication en champ proche. Cette communication entre le premier terminal et le deuxième terminal de données propres à la transaction permettent d'éviter à l'utilisateur du deuxième terminal de donner son numéro de téléphone à l'utilisateur du premier terminal. En effet, c'est le serveur qui est chargé d'établir une relation entre les données reçues du premier terminal et les données reçues du deuxième terminal. En particulier, c'est le serveur qui détermine que ces données reçues de part et d'autre concernent la même transaction. Ces techniques originales de transmission du message d'identification de la transaction qui nécessitent une proximité entre les deux terminaux rendent impossible l'interception et contribuent à la sécurité du procédé. Selon un deuxième aspect, l'invention concerne un procédé de mise en oeuvre d'une transaction entre un premier terminal mobile et un deuxième terminal mobile via un réseau de communication, le premier et le deuxième terminal mobile comprenant un module de sécurité, le procédé étant caractérisé en ce qu'il comprend les étapes suivantes, mises en oeuvre par le premier terminal mobile : (a) envoi à un serveur connecté au réseau d'une requête de création d'une transaction comprenant des données de la transaction, ladite requête étant chiffrée pour le serveur par le module de sécurité du premier terminal mobile ; (b) réception depuis le serveur d'un message d'identification de la transaction comprenant un identifiant unique de la transaction généré par le serveur et associé aux données de transaction, ledit message étant chiffré pour le serveur par le serveur ; (c) transmission dudit message d'identification de la transaction au deuxième terminal mobile.
Selon un troisième aspect, l'invention concerne un procédé de mise en oeuvre d'une transaction entre un premier terminal mobile et un deuxième terminal mobile via un réseau de communication, le premier et le deuxième terminal mobile comprenant un module de sécurité, le procédé étant caractérisé en ce qu'il comprend les étapes suivantes, mises en oeuvre par le second terminal mobile : (a) réception depuis le premier terminal mobile d'un message d'identification de la transaction comprenant un identifiant unique de la transaction associé dans un serveur connecté au réseau à des données de la transaction, ledit message étant chiffré pour le serveur par le serveur ; (b) envoi au serveur d'une requête de poursuite de la transaction comprenant le message d'identification chiffré et des données d'identification du deuxième terminal mobile, ladite requête étant chiffrée pour le serveur par le module de sécurité du deuxième terminal mobile ; (c) réception depuis le serveur d'un message de soumission de la transaction comprenant l'identifiant unique de la transaction et les données de la transaction associées à l'identifiant unique, ledit message étant chiffré pour le module de sécurité du deuxième terminal mobile par le serveur ; (d) envoi au serveur d'une requête de validation de la transaction comprenant ledit identifiant unique, en vue de la mise en oeuvre de la transaction, ladite requête étant chiffrée pour le serveur par le module de sécurité du deuxième terminal mobile. Selon un quatrième aspect, l'invention concerne un serveur connecté à un premier terminal mobile et à un deuxième terminal mobile (1 b) via un réseau de communication (20), le serveur comprenant: un premier module de réception, agencé pour recevoir depuis le premier terminal mobile une requête de création d'une transaction comprenant des données de la transaction, ladite requête étant chiffrée pour le serveur par le module de sécurité du premier terminal mobile ; un module de génération de d'association, agencé pour générer un identifiant unique de la transaction et pour associer ledit identifiant unique aux données de transaction ; un premier module d'envoi, agencé pour envoyer au premier terminal mobile un message d'identification de la transaction comprenant ledit identifiant unique, ledit message étant destiné à être transmis par le premier terminal au deuxième terminal mobile, ledit message étant chiffré pour le serveur ; un deuxième module de réception, agencé pour recevoir depuis le deuxième terminal mobile une requête de poursuite de la transaction comprenant le message d'identification chiffré et des données d'identification du deuxième terminal mobile, ladite requête étant chiffrée pour le serveur par le module de sécurité du deuxième terminal mobile ; un module de déchiffrement et d'association, agencé pour déchiffrer la requête de poursuite de la transaction et pour associer des données d'identification du deuxième terminal avec l'identifiant unique de la transaction ; un deuxième module d'envoi, agencé pour envoyer au deuxième terminal mobile un message de soumission de la transaction comprenant l'identifiant unique de la transaction et les données de la transaction associées à l'identifiant unique, ledit message étant chiffré pour le module de sécurité du deuxième terminal mobile ; un troisième module de réception, agencé pour recevoir depuis le deuxième terminal mobile une requête de validation de la transaction comprenant ledit identifiant unique, ladite requête étant chiffrée pour le serveur (3) par le module de sécurité du deuxième terminal mobile ; un module de déchiffrement, de vérification et de mise en oeuvre, agencé pour déchiffrer et vérifier la requête de validation et pour mettre en oeuvre la transaction. Ce serveur est l'équipement intermédiaire qui assure de bout en bout le succès de la transaction et sa sécurité. Le fait qu'il gère une base de données améliore par ailleurs la traçabilité. Selon un cinquième aspect, l'invention concerne un premier terminal mobile connecté à un deuxième terminal mobile et à un serveur via un réseau de communication, le premier terminal mobile comprenant : un module d'envoi, agencé pour envoyer au serveur une requête de création d'une transaction comprenant des données de la transaction, ladite requête étant chiffrée pour le serveur par le module de sécurité du premier terminal mobile ; un module de réception, agencé pour recevoir depuis le serveur un message d'identification de la transaction comprenant un identifiant unique de la transaction généré par le serveur et associé aux données de transaction, ledit message étant chiffré pour le serveur par le serveur ; - un deuxième module d'envoi, agencé pour transmettre ledit message d'identification de la transaction au deuxième terminal mobile. Selon un sixième aspect, l'invention concerne un deuxième terminal mobile connecté à un premier terminal mobile et à un serveur via un réseau de communication, le deuxième terminal mobile comprenant : un premier module de réception, agencé pour recevoir depuis le premier terminal mobile un message d'identification de la transaction comprenant un identifiant unique de la transaction associé dans le serveur à des données de la transaction, ledit message étant chiffré pour le serveur par le serveur ; un premier module d'envoi, agencé pour envoyer au serveur une requête de poursuite de la transaction comprenant le message d'identification chiffré et des données d'identification du deuxième terminal mobile, ladite requête étant chiffrée pour le serveur par le module de sécurité du deuxième terminal mobile ; un deuxième module de réception, agencé pour recevoir depuis le serveur un message de soumission de la transaction comprenant l'identifiant unique de la transaction et les données de la transaction associées à l'identifiant unique, ledit message étant chiffré pour le module de sécurité du deuxième terminal mobile par le serveur ; un deuxième module d'envoi, agencé pour envoyer au serveur une requête de validation de la transaction comprenant ledit identifiant unique, en vue de la mise en oeuvre de la transaction, ladite requête étant chiffrée pour le serveur par le module de sécurité du deuxième terminal mobile.
Selon un septième aspect, l'invention concerne un système comprenant au moins un premier terminal mobile selon le cinquième aspect de l'invention, au moins un deuxième terminal mobile selon le sixième aspect de l'invention et un serveur selon le quatrième aspect de l'invention.
Selon un huitième aspect, l'invention concerne un produit programme d'ordinateur comprenant des instructions de code pour l'exécution d'un procédé selon le premier, le deuxième ou le troisième aspect de l'invention de mise en oeuvre d'une transaction entre un premier terminal mobile et un deuxième terminal mobile. Selon un neuvième aspect, l'invention concerne un moyen de stockage lisible par un équipement informatique sur lequel on trouve ce produit programme d'ordinateur.
PRESENTATION DES FIGURES D'autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d'un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels : - la figure 1 est un schéma d'une architecture générale de réseau pour la mise en oeuvre de l'invention ; la figure 2 représente un diagramme flux ou « call flow » entre les différents éléments du réseau lors de la mise en oeuvre d'un procédé selon l'invention.
DESCRIPTION DETAILLEE Architecture En référence à la figure 1, l'invention propose des procédés pour la mise en oeuvre d'une transaction entre un premier terminal mobile la et un deuxième terminal mobile lb connectés via un réseau de communication 20. Ce réseau 20 est par exemple le réseau d'un opérateur commun aux terminaux la, 1 b. Le réseau peut être tout IP (Internet Protocol).
Les terminaux mobiles la, lb peuvent être de n'importe quel type, y compris des téléphones intelligents de type smartphones et des tablettes tactiles. Ils comprennent des modules de sécurité 12a, 12b adaptés pour se connecter au réseau 20. Les modules de sécurité 12a, 12b décrits ici sont des cartes d'identification d'abonné. Par « carte d'identification d'abonné », on entend tout circuit intégré capable d'assurer les fonctions d'identification d'un abonné à un réseau via des données qui y sont stockées, et tout particulièrement une carte « SIM » (de l'anglais « Subscriber Identity Module »), ou une carte « e-UICC » (pour « (embedded)-Universal Integrated Circuit Card ») comprenant des moyens de traitement de données sous la forme d'un microcontrôleur et de la mémoire de type « EEPROM » (pour « Electrically-Erasable Programmable Read-Only Memory »), ou flash. L'invention n'est pas limitée à ce type de module de sécurité. Ainsi, dans un autre exemple de réalisation, le module de sécurité 11 est une zone mémoire sécurisée du terminal mobile tel un composant « TEE » (de l'anglais « Trusted Execution Environment ») embarqué dans le processeur, ou un composant amovible de type microSD (« SD » pour SanDisk q.
A titre d'exemple, dans la figure 1, chaque terminal la, lb est connecté au réseau 20 via une BTS (« Base Transceiver Station ») 2a, 2b. Chaque terminal mobile la, lb comprend un module de traitement de données 11a, 11 b (en particulier un processeur) et une interface 13a, 13b comprenant par exemple un écran et des moyens de saisie tels qu'un clavier, une surface tactile, etc. pour interagir avec l'utilisateur. Alternativement, on peut imaginer un contrôle vocal avec un microphone. De façon générale, dans la suite de la présente description le premier terminal la est le terminal du « marchand » et le deuxième terminal lb est le terminal du « client ».
Dans un autre exemple de réalisation, par exemple pour un transfert d'argent entre un premier utilisateur et un deuxième utilisateur, le premier terminal la est associé à l'utilisateur qui initie le transfert et le deuxième terminal lb à l'utilisateur qui en bénéficie. Le marchand est « celui vient effectuer une transaction », et le client est « celui qui l'accepte ». La transaction peut être n'importe quelle opération qui implique un transfert d'argent depuis un des comptes du marchand ou du client vers le compte de l'autre. On peut par exemple citer les opérations « paiement en face à face », « retrait d'argent » et « dépôt d'argent » (transfert d'argent depuis le marchand vers le client). Il est à noter que le terminal la marchand peut éventuellement servir de point d'accès au réseau 20 pour le terminal lb client dans certaines configurations commerciales, ce qui peut permettre de désactiver la connectivité vers le réseau Internet du terminal lb client pour plus de sécurité. Cela permet par exemple des transactions dans le cas où le terminal lb client ne dispose pas d'une connectivité 3G mais seulement d'une connectivité \Nifi. Le terminal la marchand joue alors un rôle de modem-routeur fournissant le réseau Wifi (ce dernier étant lui-même éventuellement connecté à une BTS via le réseau 3G). Est également connecté au réseau 20 un serveur 3 du réseau. Ce serveur 3 est la plateforme de gestion des transactions, et comprend un module de traitement de données 31, par exemple un processeur et un module de stockage de données 32 tel qu'un disque dur.
Il est à noter que dans le cas dans lequel le terminal lb client se connecte via le terminal la marchand, le réseau 20 peut être un réseau fermé. En conditionnant la connexion à ce réseau 20 fermé à une authentification, il est possible d'en empêcher l'accès à tout tiers. La sécurité est alors maximale.
Principe de l'invention La présente solution permet d'intégrer des fonctions de sécurité à une application de paiement sur mobile qui sont indépendantes de la sécurité du réseau de transport. Des fonctions de chiffrement des données de la transaction et de signature sont en effet réalisées par les modules de sécurité 12a, 12b du marchand et du client. Cela permet ainsi de garantir la sécurité même lorsque les terminaux la, lb ne sont pas totalement de confiance.
Or, un module de sécurité, tel qu'une carte d'identification d'abonné est un dispositif physique de confiance quasi-impossible à infecter par un Cheval de Troie, car l'installation d'applications dans ces cartes est limitée à des entités bien identifiées, et contrôlées par l'opérateur.
La solution comprend trois applications logicielles : une sur les modules de sécurité 12a, 12b qui assure les fonctions de sécurité, la seconde est installée sur les terminaux la, lb (elle utilise les modules de traitement de données 11a, 11 b) et permet l'interfaçage Homme/machine au niveau des interfaces 13a, 13b, et la troisième fonctionne sur le serveur 3. Les informations liées aux transactions sont sécurisées de bout en bout entre les modules de sécurité 12a, 12b et le serveur 3. Toutes les opérations de chiffrement, déchiffrement, signature et vérification de signatures sont en effet effectuées soit par les modules de sécurité 12a, 12b des terminaux mobile la, 1 b, soit par le serveur 3. Le serveur 3, maîtrisé par l'opérateur, dispose de capacités importantes en termes de mémoire et de calcul pour garantir un niveau de sécurité important. Les modules de traitement de données 11a, llb des terminaux mobiles la et lb ne sont pas capables de comprendre ou de modifier une requête ou un message échangé lorsqu'il ou elle est chiffré. Ces derniers peuvent être envoyés sous n'importe quelle forme (SMS, paquet IP, etc.). Ainsi, les transactions n'utilisent plus le canal USSD. La sécurité de canal est remise en cause. Par ailleurs, il est prévu d'abandonner ce canal dans des réseaux futurs. En outre, la sécurité est garantie de bout en bout. C'est un avantage par rapport à des solutions existantes pour lesquelles la sécurité inhérente à la voie radio n'est assurée qu'entre le terminal et l'infrastructure réseau.
Exemple En référence à la figure 2 va être décrit un exemple de réalisation du présent procédé selon l'invention. On comprendra que cet exemple n'est qu'illustratif.
Voici quelques définitions des termes, désignant des informations véhiculées dans les différents messages et requêtes (informations séparées par des « ; » ou des « : » pour plus de lisibilité) qui vont être utilisés par la suite : Nonce : nombre pseudo-aléatoire généré par le module de sécurité 12a du premier terminal la (le marchand). Ce nombre pseudo-aléatoire est un mot de passe à usage unique, ou OTP (pour « One-Time Password »), qui va servir à confirmer que deux requêtes contenant un même identifiant unique de la transaction correspondent à la même transaction.
IDb : identifiant du client, présent dans le module de sécurité 12b du deuxième terminal 1 b. IDa : identifiant du marchand, présent dans le module de sécurité 12a du premier terminal la.
IDta : identifiant de la transaction pour le module de sécurité 12a du premier terminal la. Dans un exemple de réalisation, il correspond au nombre de transactions effectuées par le marchand depuis que ledit module de sécurité 12a a été installé. Cet identifiant est présent dans le module de sécurité 12a du premier terminal la. IDtb : identifiant de la transaction pour le module de sécurité 12b du deuxième terminal 1 b. Dans un exemple de réalisation, il correspond au nombre de transactions effectuées par le client depuis que le module de sécurité 12b a été installé. Cet identifiant est présent dans le module de sécurité 12b du deuxième terminal 1 b. IDts : identifiant de la transaction pour le serveur 3. C'est un numéro unique pour chaque transaction. frnjpKx : requête/message m chiffré avec la clé publique de x. Il est à noter qu'on parle ici de chiffrement asymétrique, c'est-à-dire que la clé publique de x permet à n'importe qui de chiffrer un message pour x, mais cette clé ne permet pas de le déchiffrer. Il faut pour cela une clé spécifique, qui est connue uniquement de l'équipement x (si l'équipement x est le premier ou le deuxième terminal mobile la, 1 b, c'est plus particulièrement son module de sécurité 12, 12b qui stocke et gère la clé publique). De façon alternative, on peut utiliser du chiffrement symétrique, c'est-à-dire que chaque requête/message est signé avec la clé privée de l'équipement destinataire, et déchiffré avec la même clé. Il est alors nécessaire de mettre en oeuvre un échange préalable de leurs clés entre les équipements impliqués via un canal sécurisé. De façon générale, on comprendra que chaque requête/message est chiffré « pour » un équipement, c'est-à-dire avec une clé de l'équipement (le cas échéant de son module de sécurité 12a, 12b), qu'elle soit publique ou privée. Montant : montant de la transaction. TypeTransaction : type de la transaction.
Solde : argent présent sur le compte du marchand ou du client selon les cas après la transaction. En effet, comme expliqué précédemment la transaction se fait d'un compte associé au module de sécurité 12a du premier terminal la à un compte associé au module de sécurité 12b du deuxième terminal 1 b, ou inversement, pour des cas de retrait. SIG(m) : signature de la requête/message m avec la clé privée de l'émetteur. Cela permet de garantir l'intégrité des messages. + : signifie « concaténation ».
Pour chiffrer les messages, on utilise par exemple l'algorithme « RSA » (pour « Rivest Shamir Adleman ») avec des clés de 1024 bits. Pour signer des messages, un haché, ou « hash » est calculé à l'aide d'une fonction de hachage, par exemple « SHA-1 » (pour « Secure Hash Algorithm ») et ce haché peut être également chiffré grâce à l'algorithme RSA avec des clés de 1024 bits. L'invention n'est pas limitée à ces algorithmes ni à ces tailles de clés. Les numéros des échanges présents ci-dessous reprennent les numéros présents sur la figure 2. Le contenu envoyé à la fin de chaque étape est écrit en caractères gras. 1. le marchand ouvre une application dédiée sur l'interface 13a de son terminal la, saisit un code d'identification personnel, ou code « PIN » (pour « Personal Identification Number ») puis choisit la transaction de son choix dans un menu. Il saisit ensuite le montant de la transaction et valide. Cela envoie le montant de la transaction et le type de la transaction au module de sécurité 12a du terminal la; 2. le module de sécurité 12a récupère le montant et le type de la transaction reçus et crée une « requête de création de la transaction » en y ajoutant un identifiant du marchand stocké dans le module de sécurité 12a, un identifiant de la transaction propre au premier terminal la stocké dans le module de sécurité 12a et un nombre aléatoire généré par le module de sécurité 12a. La requête ainsi obtenue est chiffrée avec la clé publique du serveur 3 et signée avec la clé privée du module de sécurité 12a. Toutes les parties du message sont stockées dans le module de sécurité 12a pour une future vérification ; cette requête peut être représentée par : {IDa ; Montant ; TypeTransaction ; IDta ; Nonce ,PKserveur SIG(IDa ; Montant ; TypeTransaction ; IDta ; Nonce) ; 3. le module de traitement de données 11a du terminal la reçoit la requête de création de la transaction envoyée par le module de sécurité 12a et la transmet directement au serveur 3 (étape (a) du procédé). A noter que le terminal la est incapable de comprendre ou de modifier cette requête ; 4. le module de traitement de données 31 du serveur 3 déchiffre la requête reçue au moyen de sa clé privée et vérifie la signature au moyen de la clé publique associée au module de sécurité 12a. Il génère un identifiant unique pour cette transaction IDts (étape (b) du procédé), récupère les informations de la transaction contenues dans la requête de création et les stocke dans une base de données du module de stockage de données 32, en association avec cet identifiant unique IDts. Il crée ensuite un « message d'identification de la transaction » contenant éventuellement l'identifiant du marchand concerné par la transaction, le nombre aléatoire reçu et l'identifiant unique de la transaction présent dans la base de données à l'ajout de cette transaction. Il est à noter que cet identifiant unique est différent de l'identifiant de la transaction envoyé par le marchand. Ce message est envoyé au premier terminal la (le marchand) chiffré avec la clé publique du serveur 3 et signé avec la clé privée du serveur 3 (étape (c) du procédé) ; ce message peut être représenté par {IDa ; IDts ; Nonce ,PKserveur SIG(IDa ; IDts ; Nonce) ; 5. le message d'identification de la transaction reçu par le module de traitement de données lla du terminal la marchand est transmis au module de traitement de données llb du deuxième terminal lb (le client). Cette transmission est mise en oeuvre grâce à l'utilisation d'un code barre matriciel affiché sur l'interface 13a du premier terminal la (ou « QRCode », pour « Quick Response Code ») et lu par une caméra du deuxième terminal 1 b, ou au moyen d'une communication en champ proche, ou « NFC » (pour « Near-Field Communication ») ; 6. le module de traitement de données 11 b du deuxième terminal lb (client) reçoit le message d'identification de la transaction et demande au module de sécurité 12b de lui retourner un identifiant client, IDb, stocké dans le module de sécurité et un identifiant de la transaction, IDtb, propre au module de sécurité 12b du deuxième terminal lb; 7. le module de sécurité 12b du deuxième terminal lb reçoit la demande du module de traitement du deuxième terminal lb et crée une « requête de poursuite de la transaction » contenant l'identifiant du client IDb et l'identifiant de la transaction en cours IDtb. La requête est chiffrée avec la clé publique du serveur 3 et signée avec la clé privée du module de sécurité 12b (la clé privée du client) ; cette requête peut être représentée par : {IDb ; IDtb}PKserveur SIG(IDb ; IDtb) ; 8. le module de traitement de données 11 b du client reçoit la requête de poursuite de la transaction du module de sécurité 12b et la complète avant de l'envoyer au serveur 3 avec le message d'identification de la transaction reçu au cours de l'échange 5 (étape (d) du procédé). Cela permet au client de dire au serveur 3 qu'il veut effectuer la transaction qui concerne ce message d'identification de la transaction. A ce stade, aucune information relative à la transaction en cours, telle que le montant, n'est affichée sur le deuxième terminal lb du client ; l'ensemble requête+message envoyé par le client peut être représenté par : {IDb ; IDtbl ,PKserveur SIG(IDb ; IDtb) ; {IDa ; IDts ; Nonce ,PKserveur SIG(IDm ; IDtsi ; Nonce) ; 9. le serveur 3 reçoit la requête de poursuite de la transaction et le message d'identification de la transaction, déchiffre le message d'identification de la transaction et vérifie la signature. Il met à jour dans sa base de données la transaction référencée par son identifiant unique. L'identifiant unique figure dans le message d'identification joint dans la requête de poursuite de la transaction. La transaction est mise à jour en ajoutant l'identifiant du client et l'identifiant de la transaction propre au deuxième terminal lb (étape (e) du procédé). Il crée ensuite un « message de soumission de la transaction » contenant le nom du marchand, le montant et le type de la transaction. Il est à noter que la présence du nombre pseudo-aléatoire permet de vérifier que les informations relatives à la transaction reçues d'une part du premier terminal la et d'autre part du deuxième terminal lb concernent la même transaction. Le message de soumission de la transaction est chiffré avec la clé publique du client et signé avec la clé privée du serveur 3 et envoyé au deuxième terminal lb (étape (f) du procédé). Ce message peut être représenté par : {NomMarchand : Montant : TypeTransaction ; IDb ; Montant ; TypeTransaction ; IDts; Nonce}pKb + SIG(NomMarchand : Montant : TypeTransaction ; IDb ; Montant ; TypeTransaction ; IDts ; Nonce) ; 10. le message de soumission de la transaction est reçu par le module de traitement de données 11 b du client et est retransmis directement au module de sécurité 12b du deuxième terminal lb; 11. le module de sécurité 12b déchiffre et vérifie la signature du message de soumission de la transaction, A ce stade, le module de sécurité 12b dispose de l'identifiant unique de la transaction, ainsi que du nombre pseudo-aléatoire. Il mémorise les autres informations de la transaction pour une future vérification. Il envoie au module de traitement de données 11 b le nom du marchand, le montant, et le type de la transaction ; 12. Confirmation paiement : l'application mise en oeuvre par le module de traitement de données 11 b affiche, via l'interface 13b, les informations principales de la transaction qui viennent d'être reçues, à savoir le nom du marchand, le montant de la transaction et le type de la transaction. Le client saisit son code PIN pour valider la transaction. La saisie du code PIN est destinée à demander au module de sécurité la création et l'envoi d'une « requête de validation de la transaction ». La requête de validation de la transaction est destinée à demander au serveur d'effectuer la transaction ; 13. le module de sécurité 12b crée la requête de validation de la transaction en indiquant un statut de la transaction, en l'espèce « validé par le client, en attente de mise en oeuvre », l'identifiant du client, le montant de la transaction, l'identifiant unique de la transaction et le nombre aléatoire reçu précédemment. La requête de validation de la transaction est chiffrée avec la clé publique du serveur 3 et signée avec la clé privée du client ; cette requête peut être représentée par : {Statut ; IDb ; Montant ; IDts ; Nonce ,PKserveur SIG(Statut ; IDb ; Montant ; IDts; Nonce) ; 14. le module de traitement de données 11 b reçoit la requête de validation de la transaction du module de sécurité 12b et la transmet au serveur 3 (étape (g) du procédé) ; 15. le serveur 3 déchiffre et vérifie la signature de la requête de validation de la transaction. Il vérifie ensuite que le statut de la transaction est bon, c'est-à-dire que le client a effectivement accepté la mise en oeuvre de cette transaction (dans le cas contraire, le procédé est interrompu). Si le statut correspond à une transaction autorisée, et donc à mettre en oeuvre, le serveur 3 vérifie que la transaction est possible. Par exemple lorsqu'il s'agit de débiter le compte d'un client, il vérifie que le compte associé au client est suffisamment créditeur. Si la transaction est possible, le serveur 3 exécute la transaction (étape (h) du procédé). Il met à jour le statut de la transaction dans la base de données. Le statut est enrichi par le serveur 3 avec des informations relatives au déroulement de la transaction : il indique normalement à ce point « validé par le client, effectué par le serveur », sauf si par exemple le compte n'est pas suffisamment approvisionné. Il indique dans le dernier cas par exemple « validé par le client, refusé par le serveur » et envoie un « message de confirmation de la transaction » au client (étape (il) du procédé). Ce message contient tout d'abord le montant de la transaction, le nouveau solde du client et le type de la transaction codés par exemple au format ASCII. Il contient également le statut mis à jour de la transaction et les autres informations de la transaction permettant au client de vérifier que la confirmation est relative à la bonne transaction. Le message de confirmation de la transaction est chiffré avec la clé publique du client et signé avec la clé privée du serveur 3, il peut être représenté par : {Montant : Solde : TypeTransaction ; Statut ; IDb ; Montant ; IDts ; Nonce}pKb + SIG (Montant : Solde : TypeTransaction ; Statut ; IDb ; Montant ; IDts ; Nonce) ; 16. le module de traitement de données 11 b reçoit et transmet le message de confirmation de la transaction au module de sécurité 12b ; 17. le module de sécurité 12b déchiffre et vérifie le message de confirmation de la transaction. Il vérifie que les informations de la transaction sont identiques à celles qu'il avait enregistrées auparavant. Si c'est le cas et que le statut de la transaction est bon, le module de sécurité 12b envoie au deuxième terminal mobile 1 b, toutes les informations affichables et qui comprennent le montant, le solde, et le type de la transaction. L'application mise en oeuvre par le module de traitement de données 1 1 b affiche via l'interface 13b la confirmation de la transaction avec ces informations ; 18. Demander confirmation : de son côté, le marchand peut demander au serveur 3 si la transaction a bien été validée par le client. A cet effet, il commande au module de sécurité 12a du premier terminal mobile la une « requête pour un message de confirmation de la transaction » ; 19. le module de sécurité 12a crée la requête pour un message de confirmation de la transaction à partir de l'identifiant du marchand, du montant de la transaction, de l'identifiant de la transaction et du nombre aléatoire. Le tout est chiffré avec la clé publique du serveur 3 et signé avec la clé privée du marchand. La requête peut être représentée par : {IDa ; Montant ; IDta ; Nonce}PKserveur + SIG(IDa ; Montant ; IDta ; Nonce) ; 20. le module de traitement de données 11 a du marchand reçoit et envoie directement la requête pour un message de confirmation de la transaction au serveur 3 ; 21. le serveur 3 déchiffre et vérifie la signature de la requête reçue. Il récupère ensuite dans sa base de données toutes les informations de la transaction à partir de l'identifiant unique et du nombre aléatoire. Si la transaction a été validée par le client, il envoie un « message de confirmation de la transaction » (étape (i2) du procédé) comprenant le montant de la transaction et le nouveau solde du compte associé au marchand codés au format ASCII. Il ajoute au message de confirmation de la transaction les informations de la transaction avec notamment le statut, le montant et l'identifiant de la transaction ainsi que l'identifiant du marchand et le nombre pseudo-aléatoire. Le tout est chiffré avec la clé publique du marchand et signé avec la clé privée du serveur 3. Ce message peut être représenté par : {Montant : Solde ; Statut ; IDa ; Montant ; IDta ; Nonce}pKa + SIG(Montant : Solde ; Statut ; IDa ; Montant ; IDta ; Nonce) ; 22. le module de traitement de données 11 a reçoit et transmet directement le message au module de sécurité 12a ; 23. le module de sécurité 12a déchiffre et vérifie la signature du message de confirmation de la transaction. Il commence par vérifier que les informations de la transaction sont identiques à celles qu'il avait stockées au début de la transaction. Si c'est le cas et que le statut de la transaction est bon, alors il envoie au premier terminal mobile la, le montant de la transaction et le nouveau solde du marchand. L'application mise en oeuvre par le module de traitement de données 1 1 a affiche via l'interface 13a ces informations qui confirment la transaction.
Produit programme d'ordinateur Selon un troisième et un quatrième aspects, l'invention concerne un produit programme d'ordinateur comprenant des instructions de code pour l'exécution (en particulier sur le modules de traitement de données 31 du serveur 3) d'un procédé selon le premier aspect de l'invention de mise en oeuvre d'une transaction entre le premier terminal mobile la et le deuxième terminal mobile lb connectés via un réseau de communication 20, ainsi que des moyens de stockage lisibles par un équipement informatique (par exemple le modules de stockage de données 32 du serveur 3) sur lequel on trouve ce produit programme d'ordinateur.30

Claims (15)

  1. REVENDICATIONS1. Procédé de mise en oeuvre d'une transaction entre un premier terminal mobile (1a) et un deuxième terminal mobile (1 b) via un réseau de communication (20), le premier et le deuxième terminal mobile (1a, 1 b) comprenant un module de sécurité (12a, 12b), Le procédé étant caractérisé en ce qu'il comprend les étapes suivantes, mises en oeuvre par un serveur (3) connecté au réseau (20) : (a) réception depuis le premier terminal mobile (1a) d'une requête de création d'une transaction comprenant des données de la transaction, ladite requête étant chiffrée pour le serveur (3) par le module de sécurité (12a) du premier terminal mobile (1a) ; (b) génération d'un identifiant unique de la transaction et association dudit identifiant unique aux données de la transaction ; (c) envoi au premier terminal mobile (1a) d'un message d'identification de la transaction comprenant ledit identifiant unique, ledit message étant destiné à être transmis par le premier terminal (1a) au deuxième terminal mobile (1 b), ledit message étant chiffré pour le serveur (3) ; (d) réception depuis le deuxième terminal mobile (1 b) d'une requête de poursuite de la transaction comprenant le message d'identification chiffré et des données d'identification du deuxième terminal mobile (1 b), ladite requête étant chiffrée pour le serveur (3) par le module de sécurité (12b) du deuxième terminal mobile (1 b) ; (e) déchiffrement de la requête de poursuite de la transaction et association des données d'identification du deuxième terminal avec l'identifiant unique de la transaction ; (f) envoi au deuxième terminal mobile (1 b) d'un message de soumission de la transaction comprenant l'identifiant unique de la transaction et les données de la transaction associées à l'identifiant unique, ledit message étant chiffré pour le module de sécurité (12b) du deuxième terminal mobile (1 b) ; (g) réception depuis le deuxième terminal mobile (1 b) d'une requête de validation de la transaction comprenant ledit identifiant unique, ladite requête étant chiffrée pour le serveur (3) par le module de sécurité (12b) du deuxième terminal mobile (1 b) ; (h) déchiffrement, vérification de la requête de validation et mise en oeuvre de la transaction.
  2. 2. Procédé selon la revendication 1, dans lequel la requête de création de la transaction comprend :un type de la transaction ; un montant de la transaction ; un identifiant du module de sécurité (12a) du premier terminal (1a) ; la requête de poursuite de la transaction comprend, outre le message d'identification de la transaction chiffré : - un identifiant du module de sécurité (12b) du deuxième terminal (1 b) ; et la requête de validation de la transaction comprend, outre le message d'identification de la transaction chiffré : un statut de la transaction ; le montant de la transaction ; l'identifiant du module de sécurité (12b) du deuxième terminal (1 b).
  3. 3. Procédé selon l'une des revendications 1 et 2, dans lequel la requête de création de la transaction comprend en outre un nombre pseudo-aléatoire généré par le module de sécurité (12a) du premier terminal (1a).
  4. 4. Procédé selon la revendication 3, dans lequel ledit nombre pseudoaléatoire est transmis avec l'identifiant unique dans chacun des messages et requêtes échangés, l'étape (e) comprenant la comparaison : du nombre pseudo-nombre aléatoire de la requête de création de la transaction dont les données de transaction sont associées à l'identifiant unique contenu dans le message d'identification contenu dans ladite requête de poursuite de la transaction ; avec le nombre pseudo-aléatoire contenu dans le message d'identification contenu dans ladite requête de poursuite de la transaction.
  5. 5. Procédé selon l'une des revendications 1 à 4, dans laquelle la requête de création de la transaction est signée avec une clé privée du module de sécurité (12a) du premier terminal (1a) ; le message d'identification de la transaction et le message de soumission de la transaction sont signés avec une clé privée du serveur (3) ; la requête de poursuite de la transaction et la requête de validation de la transaction sont signées avec une clé privée du module de sécurité (12b) du deuxième terminal (1 b).
  6. 6. Procédé selon l'une des revendications 1 à 5, comprenant en outre une étape (il) d'envoi au deuxième terminal mobile (1 b) d'un message de confirmation de la transaction, ledit message étant chiffré pour le module de sécurité (12b) du deuxième terminal mobile (1 b) ; et/ou une étape (i2) d'envoi au premier terminal mobile (1a) d'unmessage de confirmation de la transaction, ledit message étant chiffré pour le module de sécurité (12a) premier terminal mobile (1a).
  7. 7. Procédé selon la revendication 6, dans lequel le message de confirmation de la transaction comprend : le statut de la transaction ; le montant de la transaction ; le solde après transaction d'un compte associé au module de sécurité (12a, 12b) du terminal mobile (1a, 1 b) destinataire du message de confirmation.
  8. 8. Procédé selon l'une des revendications 1 à 7, dans lequel le message d'identification de la transaction est transmis du premier terminal (1a) au deuxième terminal (1 b) soit par affichage puis lecture d'un code barre matriciel, soit par communication en champ proche.
  9. 9. Procédé de mise en oeuvre d'une transaction entre un premier terminal mobile (1a) et un deuxième terminal mobile (1 b) via un réseau de communication (20), le premier et le deuxième terminal mobile (1a, 1b) comprenant un module de sécurité (12a, 12b), le procédé étant caractérisé en ce qu'il comprend les étapes suivantes, mises en oeuvre par le premier terminal mobile (1a) : (a) envoi à un serveur (3) connecté au réseau (20) d'une requête de création d'une transaction comprenant des données de la transaction, ladite requête étant chiffrée pour le serveur (3) par le module de sécurité (12a) du premier terminal mobile (1a) ; réception depuis le serveur (3) d'un message d'identification de la transaction comprenant un identifiant unique de la transaction généré par le serveur (3) et associé aux données de transaction, ledit message étant chiffré pour le serveur (3) par le serveur (3) ; (b) transmission dudit message d'identification de la transaction au deuxième terminal mobile (1 b). (c)
  10. 10. Procédé de mise en oeuvre d'une transaction entre un premier terminal mobile (1a) et un deuxième terminal mobile (1 b) via un réseau de communication (20), le premier et le deuxième terminal mobile (1a, 1 b) comprenant un module de sécurité (12a, 12b), le procédé étant caractérisé en ce qu'il comprend les étapes suivantes, mises en oeuvre par le second terminal mobile (1b) :(a) réception depuis le premier terminal mobile (1a) d'un message d'identification de la transaction comprenant un identifiant unique de la transaction associé dans un serveur (3) connecté au réseau (20) à des données de la transaction, ledit message étant chiffré pour le serveur (3) par le serveur (3) ; (b) envoi au serveur (3) d'une requête de poursuite de la transaction comprenant le message d'identification chiffré et des données d'identification du deuxième terminal mobile (1 b), ladite requête étant chiffrée pour le serveur (3) par le module de sécurité (12b) du deuxième terminal mobile (1 b) ; (c) réception depuis le serveur (3) d'un message de soumission de la transaction comprenant l'identifiant unique de la transaction et les données de la transaction associées à l'identifiant unique, ledit message étant chiffré pour le module de sécurité (12b) du deuxième terminal mobile (1 b) par le serveur (3) ; (d) envoi au serveur (3) d'une requête de validation de la transaction comprenant ledit identifiant unique, en vue de la mise en oeuvre de la transaction, ladite requête étant chiffrée pour le serveur (3) par le module de sécurité (12b) du deuxième terminal mobile (1b).
  11. 11. Serveur (3) connecté à un premier terminal mobile (1a) et à un deuxième terminal mobile (1 b) via un réseau de communication (20), le serveur (3) 20 comprenant: un premier module de réception, agencé pour recevoir depuis le premier terminal mobile (1a) une requête de création d'une transaction comprenant des données de la transaction, ladite requête étant chiffrée pour le serveur (3) par le module de sécurité (12a) du premier terminal mobile (1a) ; 25 un module de génération de d'association, agencé pour générer un identifiant unique de la transaction et pour associer ledit identifiant unique aux données de transaction ; un premier module d'envoi, agencé pour envoyer au premier terminal mobile (1a) un message d'identification de la transaction comprenant ledit identifiant unique, 30 ledit message étant destiné à être transmis par le premier terminal (1a) au deuxième terminal mobile (1 b), ledit message étant chiffré pour le serveur (3) ; un deuxième module de réception, agencé pour recevoir depuis le deuxième terminal mobile (1 b) une requête de poursuite de la transaction comprenant le message d'identification chiffré et des données d'identification du deuxième 35 terminal mobile (1 b), ladite requête étant chiffrée pour le serveur (3) par le module de sécurité (12b) du deuxième terminal mobile (1 b) ;un module de déchiffrement et d'association, agencé pour déchiffrer la requête de poursuite de la transaction et pour associer des données d'identification du deuxième terminal avec l'identifiant unique de la transaction ; un deuxième module d'envoi, agencé pour envoyer au deuxième terminal mobile (1 b) un message de soumission de la transaction comprenant l'identifiant unique de la transaction et les données de la transaction associées à l'identifiant unique, ledit message étant chiffré pour le module de sécurité (12b) du deuxième terminal mobile (1b) ; un troisième module de réception, agencé pour recevoir depuis le deuxième terminal mobile (1 b) une requête de validation de la transaction comprenant ledit identifiant unique, ladite requête étant chiffrée pour le serveur (3) par le module de sécurité (12b) du deuxième terminal mobile (1 b) ; un module de déchiffrement, de vérification et de mise en oeuvre, agencé pour déchiffrer et vérifier la requête de validation et pour mettre en oeuvre la transaction.
  12. 12. Premier terminal mobile (1a) connecté à un deuxième terminal mobile (1 b) et à un serveur (3) via un réseau de communication (20), le premier terminal mobile (1a) comprenant : un module d'envoi, agencé pour envoyer au serveur (3) une requête de création d'une transaction comprenant des données de la transaction, ladite requête étant chiffrée pour le serveur (3) par le module de sécurité (12a) du premier terminal mobile (1a) ; un module de réception, agencé pour recevoir depuis le serveur (3) un message d'identification de la transaction comprenant un identifiant unique de la transaction généré par le serveur (3) et associé aux données de transaction, ledit message étant chiffré pour le serveur (3) par le serveur (3) ; un deuxième module d'envoi, agencé pour transmettre ledit message d'identification de la transaction au deuxième terminal mobile (1 b).
  13. 13. Deuxième terminal mobile (1 b) connecté à un premier terminal mobile (1a) et à un serveur (3) via un réseau de communication (20), le deuxième terminal mobile (1 b) comprenant : un premier module de réception, agencé pour recevoir depuis le premier terminal mobile (1a) un message d'identification de la transaction comprenant un identifiant unique de la transaction associé dans le serveur (3) à des données de la transaction, ledit message étant chiffré pour le serveur (3) par le serveur (3) ; un premier module d'envoi, agencé pour envoyer au serveur (3) une requête de poursuite de la transaction comprenant le message d'identification chiffré et desdonnées d'identification du deuxième terminal mobile (1 b), ladite requête étant chiffrée pour le serveur (3) par le module de sécurité (12b) du deuxième terminal mobile (1b) ; un deuxième module de réception, agencé pour recevoir depuis le serveur (3) un message de soumission de la transaction comprenant l'identifiant unique de la transaction et les données de la transaction associées à l'identifiant unique, ledit message étant chiffré pour le module de sécurité (12b) du deuxième terminal mobile (lb) par le serveur (3) ; un deuxième module d'envoi, agencé pour envoyer au serveur (3) une requête de validation de la transaction comprenant ledit identifiant unique, en vue de la mise en oeuvre de la transaction, ladite requête étant chiffrée pour le serveur (3) par le module de sécurité (12b) du deuxième terminal mobile (1 b).
  14. 14. Système comprenant au moins un premier terminal mobile (1a) selon la revendication 12, au moins un deuxième terminal mobile (1 b) selon la revendication 13, et un serveur (3) selon la revendication 11.
  15. 15. Produit programme d'ordinateur comprenant des instructions de code pour l'exécution d'un procédé selon l'une des revendication 1 à 10 de mise en oeuvre d'une transaction entre un premier terminal mobile (1a) et un deuxième terminal mobile (1 b).
FR1352940A 2013-03-29 2013-03-29 Procede de securisation de transactions entre terminaux mobiles Withdrawn FR3003977A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1352940A FR3003977A1 (fr) 2013-03-29 2013-03-29 Procede de securisation de transactions entre terminaux mobiles

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1352940A FR3003977A1 (fr) 2013-03-29 2013-03-29 Procede de securisation de transactions entre terminaux mobiles

Publications (1)

Publication Number Publication Date
FR3003977A1 true FR3003977A1 (fr) 2014-10-03

Family

ID=49054661

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1352940A Withdrawn FR3003977A1 (fr) 2013-03-29 2013-03-29 Procede de securisation de transactions entre terminaux mobiles

Country Status (1)

Country Link
FR (1) FR3003977A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070022058A1 (en) * 2002-08-08 2007-01-25 Fujitsu Limited Wireless computer wallet for physical point of sale (POS) transactions
US20080257952A1 (en) * 2007-04-18 2008-10-23 Andre Luis Zandonadi System and Method for Conducting Commercial Transactions
US20090063312A1 (en) * 2007-08-28 2009-03-05 Hurst Douglas J Method and System for Processing Secure Wireless Payment Transactions and for Providing a Virtual Terminal for Merchant Processing of Such Transactions
US20090235083A1 (en) * 2008-02-20 2009-09-17 Micheal Bleahen System and method for preventing unauthorized access to information

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070022058A1 (en) * 2002-08-08 2007-01-25 Fujitsu Limited Wireless computer wallet for physical point of sale (POS) transactions
US20080257952A1 (en) * 2007-04-18 2008-10-23 Andre Luis Zandonadi System and Method for Conducting Commercial Transactions
US20090063312A1 (en) * 2007-08-28 2009-03-05 Hurst Douglas J Method and System for Processing Secure Wireless Payment Transactions and for Providing a Virtual Terminal for Merchant Processing of Such Transactions
US20090235083A1 (en) * 2008-02-20 2009-09-17 Micheal Bleahen System and method for preventing unauthorized access to information

Similar Documents

Publication Publication Date Title
US11687920B2 (en) Facilitating a fund transfer between user accounts
EP3221815B1 (fr) Procédé de sécurisation d'un jeton de paiement.
EP1683388B1 (fr) Methode de gestion de la sécurité d'applications avec un module de sécurité
EP2619941B1 (fr) Procede, serveur et systeme d'authentification d'une personne
US10778658B1 (en) Communication server and method of secured transmission of messages
EP1459479A2 (fr) Systeme cryptographique de signature de groupe
WO2006021661A2 (fr) Procede d'authentification securisee pour la mise en œuvre de services sur un reseau de transmission de donnees
FR2823400A1 (fr) Dispositif securise d'echange de donnees
EP3446436B1 (fr) Procédé d'obtention par un terminal mobile d'un jeton de sécurité
US10917440B1 (en) Communication server and method of secured transmission of messages
WO2015059389A1 (fr) Procede d'execution d'une transaction entre un premier terminal et un deuxieme terminal
EP2509025A1 (fr) Procédé d'accès à une ressource protégée d'un dispositif personnel sécurisé
WO2013140196A1 (fr) Système de paiement électronique avec meilleure protection de la vie privée via des tiers de confiance
EP2306668B1 (fr) Système et procédé de transaction sécurisée en ligne
Kisore et al. A secure SMS protocol for implementing digital cash system
US8819431B2 (en) Methods and device for electronic entities for the exchange and use of rights
CN113592484A (zh) 一种账户的开立方法、系统及装置
FR3003977A1 (fr) Procede de securisation de transactions entre terminaux mobiles
EP2053553A1 (fr) Procédé et dispositif pour l'échange de valeurs entre entités électroniques portables personnelles
Jemin et al. Credit Card Forgery Identification By Location Using Android Based Monitoring
WO1998010563A2 (fr) Instrument de securisation d'echanges de donnees
Enany Achieving Security in Messaging and Personal Content in Symbian Phones
RU2417444C2 (ru) Способ и система для подтверждения транзакций посредством мобильных устройств
EP2317691B1 (fr) Système et procédé de sécurisation contextuelle et dynamique des échanges de données au travers d'un réseau
WO2014140456A1 (fr) Procédé, dispositif et programme d'ordinateur pour optimiser la création d'un domaine applicatif sécurisé entre un système informatique et une entité électronique

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20141128