FR3038419A1 - Serveur et procede de verification de code de securite - Google Patents

Serveur et procede de verification de code de securite Download PDF

Info

Publication number
FR3038419A1
FR3038419A1 FR1556122A FR1556122A FR3038419A1 FR 3038419 A1 FR3038419 A1 FR 3038419A1 FR 1556122 A FR1556122 A FR 1556122A FR 1556122 A FR1556122 A FR 1556122A FR 3038419 A1 FR3038419 A1 FR 3038419A1
Authority
FR
France
Prior art keywords
security code
security
server
code
dynamic
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.)
Granted
Application number
FR1556122A
Other languages
English (en)
Other versions
FR3038419B1 (fr
Inventor
Stephane Girodon
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.)
Idemia France SAS
Original Assignee
Oberthur Technologies 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 Oberthur Technologies SA filed Critical Oberthur Technologies SA
Priority to FR1556122A priority Critical patent/FR3038419B1/fr
Publication of FR3038419A1 publication Critical patent/FR3038419A1/fr
Application granted granted Critical
Publication of FR3038419B1 publication Critical patent/FR3038419B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H04L63/0846—Network architectures or network communication protocols for network security for authentication of entities using passwords using time-dependent-passwords, e.g. periodically changing passwords
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip

Landscapes

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

Abstract

Ce serveur (5000) de vérification de code de sécurité comportant : - un module (5200) de communication apte à recevoir des données de transaction comportant un identifiant et un code de sécurité associé à un dispositif (1000) associé à cet identifiant pour réaliser une transaction ; - un module (5300) configuré pour générer un code dynamique de sécurité à partir de cet identifiant et d'une donnée temporelle ou d'un compteur du nombre de deuxièmes codes dynamiques de sécurité générés par ce module (5300) pour cet identifiant ; - un module (5400) de comparaison configuré pour déterminer que le résultat de la comparaison est positif si et seulement si le code de sécurité correspond au code dynamique de sécurité ou à un code statique de sécurité à durée de vie limitée généré par un serveur (7000) de gestion de la sécurisation pour cet identifiant ; - ledit serveur étant configuré pour permettre ou interdire directement ou indirectement la réalisation de la transaction en fonction du résultat de cette comparaison.

Description

Arrière-plan de l'invention
La présente invention se situe dans le domaine des mécanismes de vérification des codes de sécurité. L'invention peut en particulier être utilisée pour vérifier des codes de sécurité tels que numéros de documents d'identité, des identifiants de sécurité sociale, des codes d'ouverture de porte, ou des codes d'accès à un site Web. L'invention trouve en outre une application privilégiée pour vérifier des codes de sécurité utilisés dans des transactions bancaires, par exemple des applications de paiement en ligne.
On connaît en particulier dans le domaine des transactions bancaires, des cartes à microcircuit associées à des comptes bancaires, les opérations et transactions en ligne effectuées au moyen d'une telle carte étant sécurisées en utilisant un code de sécurité associé à la carte.
Le plus souvent, ces codes de sécurité sont dit statiques, ce qui signifie qu'ils sont constants dans le temps, autrement dit que leur valeur reste identique pendant toute la durée de vie de la carte.
Un problème connu avec ces cartes bancaires est qu'il est relativement aisé de dérober le code de sécurité statique, notamment lorsque celui-ci est imprimé sur la carte bancaire.
Le document [REFAA] propose une solution pour sécuriser des transactions en ligne au moyen d'une carte bancaire, dans laquelle le code de sécurité affiché sur la carte et saisi par l'utilisateur pour effectuer une transaction est un code de sécurité dynamique, le système de traitement informatique du service financier de transactions en ligne étant apte à vérifier la validité de ce code de sécurité dynamique en fonction d'un paramètre temporel pour valider ou non la transaction.
Malheureusement, la solution proposée interdit toute transaction avec la carte à microcircuit si celle-ci n'est pas en mesure de générer ou de présenter le code de sécurité dynamique, par exemple si l'afficheur de la carte à microcircuit est hors d'usage ou si la batterie de la carte est insuffisamment chargée. L'invention propose une solution pour vérifier un code de sécurité qui ne présente pas cet inconvénient.
Objet et résumé de l'invention
Plus précisément, et selon un premier aspect, l'invention concerne un serveur de vérification de code de sécurité comportant : - un module de communication apte à recevoir des données de transaction comportant un identifiant et un code de sécurité associé à un dispositif associé à cet identifiant pour réaliser une transaction ; - un module configuré pour générer un code dynamique de sécurité à partir dudit identifiant et d'une donnée temporelle ou d'un compteur du nombre de deuxièmes codes dynamiques de sécurité générés par ledit module pour ledit identifiant ; - un module de comparaison configuré pour déterminer que le résultat de ladite comparaison est positif si et seulement si ledit code de sécurité correspond audit code dynamique de sécurité ou à un code statique de sécurité à durée de vie limitée généré par un serveur de gestion de la sécurisation pour ledit identifiant ; - ledit serveur de vérification de code de sécurité étant configuré pour permettre ou interdire directement ou indirectement la réalisation de ladite transaction en fonction du résultat de ladite comparaison.
Corrélativement, l'invention concerne un procédé de vérification de code de sécurité comportant : - une étape de réception de données de transaction comportant un identifiant et un code de sécurité associé à un dispositif associé à cet identifiant pour réaliser une transaction ; - une étape de génération d'un code dynamique de sécurité à partir dudit identifiant et d'une donnée temporelle ou d'un compteur du nombre de deuxièmes codes dynamiques de sécurité générés par ledit module pour ledit identifiant ; - une étape de comparaison dont le résultat est positif si et seulement si ledit code de sécurité correspond audit code dynamique de sécurité ou à un code statique de sécurité à durée de vie limitée généré par un serveur de gestion de la sécurisation pour ledit identifiant ; - ladite transaction étant permise ou interdite en fonction du résultat de ladite comparaison.
Ainsi, et d'une façon générale, l'invention propose un serveur (et le procédé associé) configuré pour autoriser une transaction par un dispositif si les données de transaction comportent un code dynamique de sécurité compatible avec le moment de la transaction ou avec un code statique de sécurité à durée de vie limitée correspondant à ce dispositif. L'utilisation d'un code statique de sécurité à durée de vie limitée permet avantageusement au détenteur du dispositif de prêter ce dispositif à un tiers pour une durée limitée, un nombre de transactions ou un montant maximum de transactions.
Dans un mode particulier de réalisation, le serveur de vérification de code de sécurité selon l'invention comporte une table qui associe à l'identifiant du dispositif : - le code statique de sécurité à durée de vie limitée généré par ledit serveur de gestion de la sécurisation pour cet identifiant ; et - un critère d'utilisation dudit code statique de sécurité à durée de vie limitée.
Ce critère d'utilisation peut notamment être constitué par : - une date limite d'utilisation du code statique de sécurité à durée de vie limitée ; - le fait que ledit code statique de sécurité à durée de vie limitée n'a pas été utilisé pour un nombre ou un montant cumulé de transactions.
Conformément à l'invention, si le critère d'utilisation du code statique à durée de vie limitée n'est pas satisfait, par exemple parce que la date limite d'utilisation de ce code est dépassée, la transaction ne peut être permise que si le code de sécurité compris dans les données de transaction correspond à un code dynamique de sécurité calculé par le serveur de vérification de code de sécurité pour cette transaction.
Dans un mode particulier de réalisation de l'invention, le serveur de vérification de code dynamique de sécurité comporte en outre un module de communication apte à envoyer à un serveur, et ce uniquement si le résultat de la comparaison est positif, lesdites données de transaction dans lesquelles ledit code de sécurité est remplacé par un code statique de sécurité associé audit dispositif, ce serveur étant configuré pour vérifier la validité dudit code statique de sécurité pour autoriser ou refuser ladite transaction.
Ainsi, dans ce mode de réalisation, l'invention propose de vérifier la validité du code de sécurité de la transaction en amont du serveur configuré pour autoriser ou refuser la transaction, et lorsque la validité du code de la transaction est vérifiée de substituer ce code de sécurité par un code statique de sécurité pour que celui-ci soit vérifié par ce serveur.
Ce code statique est le code constant associé au dispositif dès l'origine et normalement prévu pour être associé à vie au dispositif. Dans le cas d'une carte bancaire, ce code statique peut en particulier être imprimé sur la carte.
Le serveur configuré pour autoriser ou refuser la transaction n'a donc pas besoin d'être modifié pour être en mesure de vérifier les codes dynamiques de sécurité ni les codes statiques de sécurité à durée de vie limitée.
En particulier, lorsque l'invention est utilisée dans le domaine bancaire, les serveurs bancaires n'ont pas à être modifiés, la vérification du code dynamique de sécurité ou du code statique de sécurité à durée de vie limitée s'effectuant en amont dans le réseau.
Cette solution est très avantageuse car elle ne nécessite aucune autre modification dans la chaîne de transaction, puisqu'in fine, l'autorisation ou le refus de la transaction reste sous la responsabilité du serveur en fin de chaîne, le serveur bancaire par exemple.
Dans un mode particulier de réalisation, le serveur de vérification de code de sécurité conforme à l'invention est configuré pour envoyer un message de refus de la transaction à un serveur apte à réaliser la transaction si les premier et deuxième codes dynamiques sont différents.
Ainsi, dans ce mode de réalisation, le serveur configuré pour vérifier la validité du code statique de sécurité pour autoriser ou refuser la transaction, le serveur bancaire par exemple, n'est pas sollicité. L'invention vise aussi un système de vérification d'un code de sécurité comportant : - un serveur de vérification de code de sécurité tel que mentionné ci-dessus; et - un serveur de gestion de la sécurisation configuré pour générer ledit code statique de sécurité à durée de vie limitée et envoyer ce code au titulaire dudit dispositif et au serveur de vérification de code de sécurité.
Le titulaire du dispositif, par exemple de la carte bancaire peut contacter ce dispositif lorsqu'il souhaite prêter temporairement sa carte à un tiers.
Dans un mode particulier de réalisation, le serveur de gestion de la sécurisation génère le code statique de sécurité à durée de vie limitée à partir de règles de calcul propres au titulaire du dispositif.
Dans un mode particulier de réalisation, le système selon l'invention comporte : - une carte à microcircuit comportant, un code statique de sécurité et un écran pour afficher un code dynamique de sécurité généré par ladite carte pour réaliser une transaction ; - le serveur de vérification de code dynamique de sécurité selon l'invention étant apte à vérifier la validité du code statique de sécurité à durée de vie limitée de ladite carte et celle du code dynamique de sécurité généré par ladite carte.
Dans un mode de réalisation, ce système comporte: - un terminal permettant à un utilisateur de se connecter à un serveur pour réaliser la transaction, ce terminal comportant une interface homme-machine permettant à l'utilisateur de saisir les données de la transaction dont ledit code dynamique de sécurité généré par la carte pour cette transaction ; - le serveur pour réaliser la transaction étant apte à transmettre ces données de transaction au serveur de vérification de code dynamique de sécurité selon le protocole ISO 8583 et à recevoir selon ce protocole un message d'autorisation de ladite transaction en provenance de ce serveur.
Dans un mode particulier de réalisation, les différentes étapes du procédé de vérification d'un code dynamique de sécurité selon le premier aspect ou le deuxième aspect de l'invention sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre dans un serveur ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de vérification d'un code dynamique de sécurité tel que décrit ci-dessus.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de codes source, codes objet, ou de codes intermédiaires entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, RAM, PROM, EPROM, CD ROM, DVD ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Brève description des dessins
Des caractéristiques et avantages particuliers de la présente invention ressortiront de la description détaillée faite aux figures dans lesquelles : - la figure 1 représente un dispositif permettant d'effectuer des transactions, en l'espèce une carte à microcircuit ; - la figure 2 représente un premier système de vérification de code de sécurité conforme à mode de réalisation de l'invention ; - la figure 3 représente sous forme d'organigramme les principales étapes d'un procédé de vérification de code de dynamique de sécurité conforme à mode de réalisation de l'invention ; - la figure 4 représente un deuxième système de vérification de code de sécurité conforme à mode de réalisation de l'invention ; - la figure 5 représente sous forme d'organigramme des étapes mises en œuvre par un module d'interface du système de la figure 4 ; - les figures 6 et 7 représentent le système de vérification de code de sécurité de la figure 4 selon deux architectures alternatives ; - la figure 8 représente sous forme d'organigramme les principales étapes d'un procédé de vérification de code de dynamique de sécurité conforme à autre mode de réalisation de l'invention ; - la figure 9 représente une table pouvant être utilisée par un serveur de vérification de code dynamique de sécurité ; - la figure 10 représente sous forme d'organigramme des étapes mises en œuvre par un serveur de vérification de code dynamique de sécurité qui utilise la table de la figure 9 ; - la figure 11 représente une autre table pouvant être utilisée par un serveur de vérification de code dynamique de sécurité ; - la figure 12 représente sous forme d'organigramme des étapes mises en œuvre par un serveur de vérification de code dynamique de sécurité qui utilise la table de la figure 11.
Description détaillée d'un premier mode de réalisation de l'invention
Ce mode de réalisation est décrit dans le contexte particulier d'une application financière, plus précisément d'une application de paiement en ligne.
La figure 1 représente un dispositif 1000 permettant d'effectuer des transactions en ligne.
Dans les modes de réalisation décrits ci-après, le dispositif 1000 est une carte à microcircuit (en anglais smartcard) de paiement. En variante, la dispositif 1000 peut être constitué par un terminal, par exemple de téléphonie mobile, mettant en œuvre une application permettant de réaliser des transactions.
Dans le mode de réalisation décrit ici, la carte à microcircuit 1000 est conforme à la norme IS07816. Elle comporte en particulier une interface à contacts 1300. La carte à microcircuit 1000 est par exemple au format ID-1 (dimensions : 85,60 x53,98 mm) et d'épaisseur 0.76 mm environ. Elle est par exemple en matière plastique.
De façon connue, le nom NOM du titulaire de la carte à microcircuit, un numéro de compte bancaire PAN (par exemple à 16 chiffres), une date d'expiration EXP sont imprimés et/ou embossés sur la carte à microcircuit 1000. La carte comporte en outre un code statique de sécurité CW, celui-ci pouvant être ou ne pas être imprimé sur la carte. Pour plus de renseignements sur : - le code statique de sécurité CW, l'homme du métier peut consulter le document [REFCW] ; - le numéro de compte bancaire PAN, l'homme du métier peut consulter le document [REFPAN].
Cette carte à microcircuit 1000 comporte un contrôleur 1200 comportant un module apte à fournir la date courante, par exemple une horloge CLK, ce contrôleur 1200 étant apte à calculer un code dynamique de sécurité DCCVi en appliquant une fonction cryptographique secrète à des paramètres comportant le numéro de compte bancaire PAN et un paramètre temporel.
Dans le mode de réalisation décrit ici, le code dynamique de sécurité DCCVi est varié de façon périodique, selon une période prédéterminée.
Au contraire, le code statique de sécurité CW est constant dans le temps.
La carte à microcircuit 1000 comporte un écran 1100 d'affichage de ce code dynamique de sécurité DCCVi. Cet écran peut comporter par exemple 3 ou 4 zones élémentaires selon la taille de ce code dynamique.
Dans le mode de réalisation décrit ici, la carte à microcircuit 1000 comporte en outre une batterie non représentée et un bouton poussoir 1400 pour allumer ou éteindre l'écran d'affichage 1100 et donc le code dynamique de sécurité DCCVi. Ce bouton-poussoir ou tout moyen équivalent (bouton capacitif, ...) pour allumer ou éteindre l'écran 1100 est optionnel. L'écran d'affichage 1100 peut se trouver sur la face de la carte à microcircuit 1000 opposée à celle où sont imprimés et/ou embossés le numéro de carte bancaire PAN et la date d'expiration EXP. En variante, ils sont sur la même face.
La figure 2 représente un terminal utilisateur 2000 muni d'une interface homme-machine HMI, par exemple un ordinateur personnel, un téléphone intelligent (en anglais smartphone) ou une tablette, un serveur 3000 d'un site Web marchand, le système bancaire 6000 de l'entité émettrice de la carte à microcircuit 1000, et un dispositif 5000 de vérification de code dynamique de sécurité conforme à l'invention.
Dans le mode de réalisation décrit ici, le terminal 2000 accède au site Web marchand 3000 par le réseau Internet ; le site Web marchand 3000, le système bancaire 6000 et le dispositif 5000 de vérification communiquent via un réseau interbancaire 4000.
Le système bancaire 6000 comporte un module 6100 d'authentification et d'autorisation des transactions bancaires. D'une façon générale, le dispositif 5000 de vérification de code dynamique de sécurité vise à sécuriser le code statique de sécurité CW de la carte à microcircuit 1000.
Le serveur 5000 de vérification de code dynamique de sécurité est conforme à l'invention. Il comporte notamment : - un module 5100 apte à obtenir la date courante, soit en utilisant des moyens internes, soit par exemple à partir d'un autre équipement ou d'un autre réseau, par des moyens de communications sans fil ou filaires ; - un module 5200 de communication apte à recevoir des données de transaction DT comportant, le numéro de compte bancaire PAN, la date d'expiration EXP de la carte et un code de sécurité associé à cet identifiant pour réaliser une transaction ; - ledit module de communication 5200 étant apte à recevoir un code statique de sécurité CW* à durée de vie limitée généré par le serveur 7000 de gestion de la sécurisation pour ledit identifiant PAN ; - un module 5800 apte à recevoir le code statique de sécurité CW d'une carte à microcircuit ou à générer ce code statique CW en utilisant le numéro de compte bancaire PAN de la carte, sa date d'expiration EXP et une clef secrète à l'aide d'un algorithme cryptographique ; - un module 5300 de génération d'un deuxième code dynamique de sécurité DCCV2 pour cette transaction en ligne en utilisant le numéro de compte bancaire PAN, une fonction cryptographique secrète et une donnée temporelle ; - un module 5400 de comparaison configuré pour déterminer que le résultat de ladite comparaison est positif si et seulement si le code de sécurité compris dans les données de transaction bancaires correspond au code dynamique de sécurité DCCV2 ou au code statique de sécurité à durée de vie limitée CW, le serveur 5000 étant configuré pour permettre ou interdire directement ou indirectement la réalisation de ladite transaction en fonction du résultat de ladite comparaison.
Dans le mode de réalisation décrit ici, lorsque le résultat de l'étape de comparaison est positif, le serveur 5000 envoie, au serveur bancaire 6000, les données de transaction reçues du serveur 3000 en remplaçant le code de sécurité de ces données par le code statique de sécurité CW obtenu par le module 5800.
De façon connue, le serveur bancaire 6000 comporte un module 6100 d'authentification et de sécurisation des transactions apte à vérifier le code statique de sécurité CW pour autoriser ou refuser la transaction. Il est fondamental de noter que cette vérification utilise le code statique de sécurité CW de sorte que le serveur bancaire 6000 n'a pas besoin de mettre en œuvre les fonctions de calcul du deuxième code dynamique de sécurité DCCV2.
Dans un mode de réalisation décrit ici, et comme représenté à la figure 11, le serveur 5000 de vérification de code dynamique de sécurité mémorise dans une table 5700, au moins pour certains comptes bancaires PAN, un code statique de sécurité CW* à durée limitée, et en association avec ce code, un critère TL permettant de déterminer jusqu'à quand ce code statique de sécurité CW* peut être valablement utilisé.
Ce critère de durée de vie TL peut notamment être : - un nombre maximum de transactions ; - associée à un montant maximum cumulé de transactions ; ou - une date limite d'utilisation.
Dans le mode de réalisation décrit ici, le détenteur de la carte à microcircuit 1000 peut contacter le serveur 7000 de gestion de la sécurisation pour lui demander, après authentification, de générer un code statique de sécurité CW* à durée de vie limitée au moyen d'une clef cryptographique par exemple.
La génération du code statique de sécurité CW* à durée de vie limitée peut éventuellement nécessiter une interaction avec le détenteur de la carte à microcircuit 1000, au moyen de son terminal via un site Web ou par un serveur vocal par exemple.
Le code statique de sécurité CW* à durée de vie limitée est ensuite communiqué au détenteur de la carte à microcircuit 1000, par exemple par un serveur vocal, par SMS, par email ou via une interface Web de ce serveur 7000 affichée sur l'écran du terminal utilisateur 2000.
Dans un mode particulier de réalisation, le terminal utilisateur 2000 possède une application et un module apte à communiquer le code statique de sécurité CW* à durée de vie limitée à des moyens de communication à champ proche de la carte à microcircuit 1000 et le code CW* est présenté à l'utilisateur sur l'écran 1100 de la carte. La carte peut éventuellement utiliser un bouton pour permettre l'établissement de cette communication à champ proche.
En référence à la figure 12, ce code statique de sécurité CW* à durée de vie limitée peut être reçu par le serveur 5000 de vérification de code dynamique de sécurité 5000 du serveur 7000 au cours d'une étape H10.
Dans le mode de réalisation décrit ici, le serveur 5000 de vérification de code dynamique de sécurité obtient l'information TL de durée de vie au cours d'une étape H20. En pratique, cette information peut être calculée par le serveur 5000 ou par le serveur 7000 de gestion de la sécurisation, préférentiellement à partir de règles de calcul propres au détenteur de la carte à microcircuit 1000 et mémorisées par le serveur 7000.
Lorsque le serveur 5000 de vérification de code dynamique de sécurité est sollicité pour vérifier une transaction (étape H30), il commence, dans ce mode de réalisation par générer un code dynamique de sécurité DCCV2 (étape H40) et à vérifier si le code de sécurité CS reçu dans les données de transactions est identique à ce code (étape H50).
Si tel est le cas, en fonction du mode de réalisation de l'invention, le serveur 5000 (étape H60) : - envoie directement un message au serveur 3000 du site marchand pour valider la transaction ; ou - transmet les données de transaction au serveur bancaire 6000 après avoir remplacé le code dynamique de sécurité CS par avec le code statique de sécurité CW de la carte 1000.
Lorsque le code de sécurité dynamique DCCV2 calculé à l'étape H40 est différent du code de sécurité CS compris dans les données de transaction, le serveur 5000 vérifie (étape H70) si ce code de sécurité correspond au code statique de sécurité CW* à durée de vie limitée pour ce compte PAN et, en fonction du paramètre TL, si ce code est encore valable. Bien entendu, il est possible de commencer par vérifier à l'étape H50 si le code de sécurité CS correspond au code statique de sécurité CW* à durée de vie limitée, et si ce n'est pas le cas, à l'étape H70 si si le code de sécurité CS correspond au code dynamique de sécurité DCCV2 généré à l'étape H40.
Quoiqu'il en soit, en cas de succès de cette double vérification, le serveur 5000 exécute l'étape H60 précédemment décrite pour autoriser la transaction, soit directement, soit indirectement.
Sinon, le serveur 5000 de vérification du code de sécurité dynamique envoie (étape H80) un message au serveur 3000 du site marchand pour refuser la transaction. En variante, et comme mentionné précédemment, le serveur de vérification 5000 peut envoyer au serveur bancaire 6000 des données de transaction modifiées DT(£W) avec un code de sécurité statique CW faux pour déclencher le refus de la transaction par le serveur bancaire. L'utilisation d'un code statique de sécurité CW* à durée de vie limitée peut notamment permettre au détenteur de la carte à microcircuit 1000 de prêter sa carte pour une durée limitée, un nombre de transactions ou un montant maximum de transactions.
En référence à la figure 3, nous supposerons qu'un utilisateur se connecte, en utilisant le terminal 2000 au site Web marchand 3000 pour réaliser une transaction, et que cet utilisateur saisit (étape E10) dans une page Web émise par le site marchand 3000 ou par le serveur 5000 des données de transaction DT(DCCVi) comportant: - les informations PAN de la carte 1000 ; - la date EXP d'expiration de la carte 1000 ; et - le code dynamique de sécurité DCCVi affiché sur l'écran 1100 au moment de cette transaction.
Ces données de transaction DT(DCCVi) sont transmises par le site marchand 3000 au serveur 5000 de vérification, dans une requête d'autorisation de transaction au format IS08583. Le serveur 5000 reçoit cette requête au cours d'une étape E20. L'utilisation du format IS08583 n'est obligatoire ni pour les communications entrantes ni pour les communications sortantes du serveur 5000 ; un autre format peut être utilisé.
Le serveur 5000 étant est sollicité pour vérifier une transaction, le procédé se poursuit à partir de l'étape H30 déjà décrite.
Le module 6100 d'authentification et de sécurisation des transactions du serveur bancaire 6000 vérifie les données de transaction DT(CW) reçues du serveur de vérification 5000 au cours d'une étape H60 pour autoriser ou refuser la transaction.
Si le serveur bancaire 6000 autorise la transaction, il envoie un message d'autorisation au serveur du site marchand 3000 qui délivre les biens ou services correspondants à l'utilisateur.
Si le serveur bancaire 6000 refuse la transaction, il envoie un message de refus de transaction au serveur du site marchand 3000. L'autorisation ou le refus est envoyée au serveur du site marchand dans un message de réponse d'autorisation au format ISO 8583.
Description détaillée d'un deuxième mode de réalisation de l'invention
La figure 4 représente un système 10 de vérification de code de sécurité comportant : - un serveur 5000 de vérification de code dynamique de sécurité et un serveur bancaire 6000 tels que décrits précédemment en référence aux figures 2 et 3 ; et - un module d'interface 5500 conforme à l'invention.
Ce module d'interface 5500 est apte à recevoir des données de transaction DT d'un serveur de site marchand 3000 comportant soit un code statique de sécurité CW, soit un code de sécurité statique à durée de vie limitée CW*, soit un code dynamique de sécurité DCWi, et à décider du traitement de ces données de transaction en fonction du type du code de sécurité.
Plus, précisément, en référence à la figure 5, le module d'interface 5500 détermine au cours d'une étape F10 si le code de sécurité compris dans les données de transaction DT est un code statique de sécurité CW, un code statique de sécurité à durée de vie limitée CW*, ou un code dynamique de sécurité DCWi ; et - Si le code est un code dynamique de sécurité ou un code statique de sécurité à durée de vie limitée CW*, le module d'interface transmet ces données de transaction DT(DCWi) au serveur 5000 de vérification de code dynamique de sécurité pour que celui-ci vérifie le code dynamique de sécurité DCCVi et transmette les données de transaction DT(CW) comportant le code statique de sécurité CW au serveur 6000 ; - Si le code est un code statique de sécurité, le module d'interface transmet ces données de transaction DT(CW) au serveur bancaire 6000 pour que celui-ci réalise directement le traitement décrit précédemment.
Description détaillée d'un troisième et d'un quatrième modes de réalisation de l'invention
Dans le mode de réalisation de la figure 4, le module d'interface 5500 et le serveur 5000 de vérification de code dynamique de sécurité sont implémentés dans des équipements indépendants du serveur bancaire 6000.
Dans un autre mode de réalisation de l'invention représenté à la figure 6, le module d'interface 5500 reste un équipement indépendant du serveur bancaire 6000 mais le serveur 5000 de vérification de code dynamique de sécurité est implémenté dans le serveur bancaire.
Dans un autre mode de réalisation de l'invention représenté à la figure 7, le module d'interface 5500 et le serveur 5000 de vérification de code dynamique de sécurité sont implémentés dans le serveur bancaire 6000.
Dans ces deux modes de réalisation, il est préférable que les fonctions du module d'interface 5500 et du serveur 5000 de vérification du code dynamique de sécurité ne soient pas intégrées dans le module 6100 d'authentification et de sécurisation des transactions en charge de la vérification du code statique de sécurité statique CW.
Description détaillée d'un cinquième mode de réalisation de l'invention
Dans le mode de réalisation décrit précédemment, lorsque le serveur 5000 de vérification de code dynamique de sécurité détermine que le résultat de l'étape de comparaison est positif, il envoie les données de transaction au serveur bancaire 6000 en remplaçant le code de sécurité présent dans la transaction par le code statique de sécurité CW pour vérification de ce code par le serveur bancaire 6000.
Dans un cinquième mode de réalisation de l'invention représenté en référence à la figure 8 dans lequel il n'est pas nécessaire d'impliquer le serveur bancaire 6000, le serveur 5000 envoie directement un message d'autorisation au serveur du site marchand 3000 au cours d'une étape E46 pour que celui-ci délivre les biens ou services correspondants à l'utilisateur.
Description détaillée d'un sixième mode de réalisation de l'invention
Dans un mode particulier de réalisation de l'invention, le serveur 5000 de vérification de code dynamique de sécurité est également apte à vérifier le code statique de sécurité CW associé à un compte bancaire PAN. A cet effet, et comme représenté à la figure 9, le serveur 5000 gère une table 5600 dans laquelle il mémorise, pour au moins un numéro de compte bancaire PAN, un mode de vérification « S/D » indiquant si la vérification d'une transaction doit porter sur le code statique de sécurité CW (mode « S ») ou sur le code dynamique de sécurité DCWi (mode « D »). Le serveur 5000 mémorise dans cette table 5600, le code dynamique de sécurité CW au moins pour les cartes à microcircuits 1000 pour lesquelles le mode de vérification est le mode statique « S ».
Le mode de vérification S/D peut être modifié par le serveur 5000 sur réception d'un message en provenance d'un serveur 7000 de gestion de la sécurisation représenté à la figure 2.
Dans le mode de réalisation décrit ici, le détenteur de la carte à microcircuit 1000 peut contacter le serveur 7000 de gestion de la sécurisation pour lui demander que la vérification de ses transactions, par défaut réalisée en utilisant le code dynamique de sécurité DCCVi, utilise au moins pendant un certain temps, le code statique de sécurité CW. L'utilisateur peut faire une telle demande en particulier lorsque l'afficheur 1100 de la carte à microcircuit 1000 est hors d'usage ou lorsque la batterie de cette carte est insuffisamment chargée.
On notera que dans de telles circonstances, l'utilisateur peut également demander au serveur 7000 de générer un code statique de sécurité CW* à durée de vie limitée comme décrit ultérieurement en référence au septième mode de réalisation de l'invention.
Dans le mode particulier de réalisation décrit ici, le serveur 7000 de gestion de la sécurisation possède des moyens pour authentifier l'utilisateur pour prendre en compte le changement de mode de vérification et le transmettre au serveur 5000 de vérification de code dynamique. Ces moyens d'authentification peuvent notamment utiliser un mot de passe, un mécanisme de défi ou des fonctions cryptographiques.
Dans un mode particulier de réalisation, l'utilisateur peut, après authentification, communiquer son code statique de sécurité CW au serveur 7000 pour que celui-ci le transmette au serveur 5000 de vérification de code dynamique de sécurité.
Dans le mode particulier de réalisation décrit ici, le mode de vérification est par défaut le mode de vérification « D » basé sur le code dynamique de sécurité DCCVi et le basculement dans le mode de vérification statique n'est que temporaire. A cet effet, dans le mode de réalisation décrit ici, la table 5600 comporte une colonne « TL » dans laquelle le serveur 5000 de vérification de code dynamique mémorise un critère permettant de déterminer si la vérification du code statique CW est toujours autorisée.
Ce critère peut par exemple être une date limite fournie au serveur 5000 par le serveur 7000 de gestion de la sécurisation ; une telle date peut aussi être calculée par le serveur 5000 à partir de la date de réception du message en provenance de ce serveur 7000.
En variante, le serveur 5000 de vérification de code dynamique de sécurité peut réaliser des vérifications basées sur le code statique de sécurité CW : - jusqu'à recevoir un message prédéterminé du serveur 7000 de gestion de la sécurisation ; ou - tant qu'un nombre prédéterminé de transactions n'a pas été dépassé ; ou - tant qu'un montant cumulé total de transactions n'a pas été atteint.
La figure 10 représente sous forme d'organigramme un procédé mis en œuvre par le serveur 5000 de vérification de code dynamique de sécurité dans ce mode de réalisation.
Au cours d'une étape G10, le serveur 5000 initialise le mode de vérification au mode dynamique « D » pour les comptes bancaires PAN concernés.
Si le serveur 5000 reçoit (étape G20) un message MSG du serveur 7000 pour un compte PAN, il bascule le mode de vérification au mode statique.
Dans cet exemple le code statique de sécurité CW pour ce compte PAN est communiqué au serveur 5000 dans le message MSG.
En variante, le serveur 5000 calcule le code statique de sécurité CW comme décrit précédemment en utilisant son module 5800 en utilisant le numéro de compte bancaire PAN de la carte, sa date d'expiration EXP et une clef secrète à l'aide d'un algorithme cryptographique.
La table 5600 est mise à jour avec le code statique de sécurité reçu du serveur 7000 ou calculé par le serveur 5000 et avec le critère TL permettant de déterminer si la vérification basée sur le code statique est autorisée.
Comme mentionné précédemment ce critère peut être constitué par une durée reçue du serveur 7000 ou lié à la réception d'un message du serveur 7000 pour rebasculer dans le mode dynamique « D », un montant total cumulé ou nombre maximum de transactions autorisées.
Si au cours d'une étape G30, le serveur 5000 est sollicité pour vérifier une transaction pour un compte bancaire PAN, il vérifie dans la table 5600 (étape G40), si le mode de vérification pour ce compte PAN est le mode statique « S » et le critère TL pour réaliser des vérifications sur la base du code statique de sécurité CW est vérifié.
Si ces deux conditions sont réunies, le serveur 5000 de vérification de code dynamique de sécurité vérifie la transaction sur la base du code statique de sécurité CW mémorisé dans la table 5600 (étape G50).
Sinon, le serveur 5000 calcule un code dynamique de sécurité DCCV2 et vérifie la transaction sur la base de ce code dynamique de sécurité (étape G60). En cas de succès, et selon le mode de réalisation de l'invention, le serveur 5000 : - envoie directement un message au serveur 3000 du site marchand pour valider la transaction ; ou - transmet les données de transactions après avoir remplacé le code dynamique de sécurité DCCVi par avec le code statique de sécurité CW au serveur bancaire 6000.
Dans ce mode de réalisation, les architectures décrites aux figures 2, 4, 6 et 7 peuvent être utilisées : le serveur 5000 de vérification de code dynamique de sécurité peut être ou non associé à un module d'interface 5500, chacune des entités 5000 et 5500 pouvant éventuellement être implémentée dans le serveur bancaire 6000.
Variantes possibles communes à tous les modes de réalisation L'invention a été décrite ci-dessus dans le contexte particulier d'une application de paiement en ligne. Elle peut s'appliquer : - pour d'autres applications financières ; mais aussi - dans d'autres dès lors qu'il s'agit de vérifier un code de sécurité saisi par un utilisateur par exemple pour vérifier un numéro de document d'identification d'identité, un identifiant de sécurité sociale, un code d'ouverture de porte, un code d'accès à un site Web.
Dans les modes de réalisation décrits précédemment, la génération du code dynamique de sécurité DCWi par la carte et du code dynamique de sécurité DCCV2 utilisent un paramètre temporel. L'homme du métier comprendra que ces paramètres temporels doivent être synchronisés pour permettre la comparaison de ces codes. En pratique, pour palier à ces problèmes de synchronisation, le serveur peut générer plusieurs deuxièmes codes de sécurité en utilisant différents paramètres temporels, une transaction étant autorisée dès lors que l'un de ces deuxièmes codes de sécurité correspond au code dynamique de sécurité reçu de la carte à microcircuit.
En variante, le paramètre temporel peut être remplacé par un compteur incrémenté : - du côté de la carte à microcircuit 1000 à chaque fois la carte génère un nouveau code dynamique de sécurité, par exemple lorsque l'utilisateur appuie sur le bouton poussoir 1400 ; et - du côté du serveur 5000 de vérification de code dynamique de sécurité à chaque fois que celui-ci génère de son côté un code dynamique de sécurité pour vérifier la validité d'un code dynamique de sécurité généré par la carte à microcircuit 1000. Là encore, l'homme du métier comprendra que ces compteurs doivent être synchronisés pour permettre la comparaison de ces codes. En pratique, pour palier à ces problèmes de synchronisation, le serveur peut générer plusieurs deuxièmes codes de sécurité en utilisant différentes valeurs de compteur, une transaction étant autorisée dès lors que l'un de ces deuxièmes codes de sécurité correspond au code dynamique de sécurité reçu de la carte à microcircuit. Références : [REFAA] : Demande de brevet européen n° EP 2 568 448 publiée le 13 mars 2013 pour une « carte de crédit ou de débit avec un code de sécurité ».
[REFCW] : en.wikipedia.org/wiki/card_security_code [REFPAN] : en.wikipedia.org/wiki/Bank_card_number

Claims (13)

  1. REVENDICATIONS
    1. Serveur (5000) de vérification de code de sécurité comporte : - un module (5200) de communication apte à recevoir des données de transaction (DT) comportant un identifiant (PAN) et un code de sécurité (CW, DCCVi) associé à un dispositif (1000) associé à cet identifiant pour réaliser une transaction ; - un module (5300) configuré pour générer un code dynamique de sécurité (DCCV2) à partir dudit identifiant (PAN) et d'une donnée temporelle ou d'un compteur du nombre de deuxièmes codes dynamiques de sécurité (DCCV2) générés par ledit module (5300) pour ledit identifiant (PAN) ; - un module (5400) de comparaison configuré pour déterminer que le résultat de ladite comparaison est positif si et seulement si ledit code de sécurité (CW, DCCVi) correspond audit code dynamique de sécurité (DCCV2) ou à un code statique de sécurité (CW*) à durée de vie limitée généré par un serveur (7000) de gestion de la sécurisation pour ledit identifiant (PAN) ; - ledit serveur (5000) étant configuré pour permettre ou interdire directement ou indirectement la réalisation de ladite transaction en fonction du résultat de ladite comparaison.
  2. 2. Serveur (5000) de vérification de code selon la revendication 1 caractérisé en ce qu'il comporte une table (5600) qui associe audit identifiant (PAN) : - ledit un code statique de sécurité (CW*) à durée de vie limitée généré par ledit serveur (7000) de gestion de la sécurisation pour ledit identifiant (PAN) ; et - un critère (TL) d'utilisation dudit code statique de sécurité (CW*) à durée de vie limitée.
  3. 3. Serveur (5000) de vérification de code de sécurité selon la revendication 2, dans lequel ledit critère (TL) d'utilisation est constituée par : - une date limite d'utilisation dudit code statique de sécurité à durée de vie limitée (CW*) ; - le fait que ledit code statique de sécurité à durée de vie limitée (CW*) n'a pas été utilisé pour un nombre ou un montant cumulé de transactions.
  4. 4. Système de vérification d'un code de sécurité comportant : - un serveur (5000) de vérification de code de sécurité selon l'une quelconque des revendications 1 à 3 ; et - un serveur (7000) de gestion de la sécurisation configuré pour générer ledit code statique de sécurité (CW*) à durée de vie limitée et envoyer ce code au titulaire dudit dispositif (1000) et audit serveur (5000) de vérification de code de sécurité.
  5. 5. Système de vérification d'un code de sécurité selon la revendication 4, caractérisé en ce que ledit serveur (7000) de gestion de la sécurisation génère ledit code statique de sécurité (CW*) à durée de vie limitée à partir de règles de calcul propres audit titulaire.
  6. 6. Système selon l'une quelconque des revendications 4 ou 5 caractérisé en ce que ledit serveur (7000) de gestion de la sécurisation génère le code statique de sécurité (CW*) à durée de vie limitée au moyen d'une clef cryptographique.
  7. 7. Système selon l'une quelconque des revendications 4 à ôcaractérisé en ce qu'il comporte : - une carte à microcircuit (1000) comportant, un code statique de sécurité (CW) et un écran (1400) pour afficher un code dynamique de sécurité (DCCVi) généré par ladite carte pour réaliser une transaction ; - ledit serveur (5000) de vérification de code dynamique de sécurité étant apte à vérifier la validité du code statique de sécurité à durée de vie limitée (CW*) de ladite carte et celle dudit code dynamique de sécurité (DCCVi) généré par ladite carte.
  8. 8. Système selon la revendication 7 caractérisé en ce qu'il comporte : - un terminal (2000) permettant à un utilisateur de se connecter à un serveur (3000) pour réaliser ladite transaction, ledit terminal (2000) comportant une interface homme-machine permettant audit utilisateur de saisir les données de ladite transaction dont ledit code dynamique de sécurité (DCCVi) généré par ladite carte pour cette transaction ; - ledit serveur (3000) pour réaliser la transaction étant apte à transmettre lesdites données de transaction audit serveur (5000) de vérification de code dynamique de sécurité selon le protocole ISO 8583 et à recevoir selon ce protocole un message d'autorisation de ladite transaction en provenance de ce serveur (5000).
  9. 9. Système selon la revendication 8 caractérisé en ce que ledit serveur (7000) de gestion de la sécurisation communique ledit code statique de sécurité (CW*) à durée de vie limitée au détenteur de la carte à microcircuit 1000, par exemple par un serveur vocal, par SMS, par email ou via une interface Web de ce serveur 7000 affichée sur un écran du terminal (2000).
  10. 10. Système selon la revendication 9 dans lequel ledit terminal (2000) possède un module apte à communiquer le code statique de sécurité (CW*) à durée de vie limitée à des moyens de communication à champ proche de la carte à microcircuit (1000), ledit (code CW*) étant affiché sur un écran (1100) de la carte.
  11. 11. Procédé de vérification de code de sécurité comportant : - une étape (E20) de réception de données de transaction (DT) comportant un identifiant (PAN) et un code de sécurité (CW, DCCVi) associé à un dispositif (1000) associé à cet identifiant pour réaliser une transaction ; - une étape (E30) de génération d'un code dynamique de sécurité (DCCV2) à partir dudit identifiant (PAN) et d'une donnée temporelle ou d'un compteur du nombre de deuxièmes codes dynamiques de sécurité (DCCV2) générés par ledit module (5300) pour ledit identifiant (PAN) ; - une étape (H50, H70) de comparaison dont le résultat est positif si et seulement si ledit code de sécurité (CW, DCCVi) correspond audit code dynamique de sécurité (DCCV2) ou à un code statique de sécurité (CW*) à durée de vie limitée généré par un serveur (7000) de gestion de la sécurisation pour ledit identifiant (PAN) ; - ladite transaction étant permise ou interdite en fonction du résultat de ladite comparaison.
  12. 12. Programme d'ordinateur comportant des instructions pour mettre en oeuvre les étapes d'un procédé de vérification de code dynamique de sécurité selon la revendication 11 lorsque ce programme est exécuté par un ordinateur.
  13. 13. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de vérification de code dynamique de sécurité selon la revendication 11.
FR1556122A 2015-06-30 2015-06-30 Serveur et procede de verification de code de securite Active FR3038419B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1556122A FR3038419B1 (fr) 2015-06-30 2015-06-30 Serveur et procede de verification de code de securite

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1556122A FR3038419B1 (fr) 2015-06-30 2015-06-30 Serveur et procede de verification de code de securite

Publications (2)

Publication Number Publication Date
FR3038419A1 true FR3038419A1 (fr) 2017-01-06
FR3038419B1 FR3038419B1 (fr) 2017-07-28

Family

ID=54608655

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1556122A Active FR3038419B1 (fr) 2015-06-30 2015-06-30 Serveur et procede de verification de code de securite

Country Status (1)

Country Link
FR (1) FR3038419B1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115243262A (zh) * 2022-07-04 2022-10-25 广东艾科智泊科技股份有限公司 一种防盗仿的遥控开闸方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060278698A1 (en) * 2005-06-13 2006-12-14 Robert Lovett System, method and program product for account transaction validation
US20090173782A1 (en) * 2008-01-04 2009-07-09 Muscato Michael A Dynamic Card Validation Value
US20100029093A1 (en) * 2006-09-29 2010-02-04 Tokyo Electron Limited Plasma oxidizing method, plasma processing apparatus, and storage medium

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060278698A1 (en) * 2005-06-13 2006-12-14 Robert Lovett System, method and program product for account transaction validation
US20100029093A1 (en) * 2006-09-29 2010-02-04 Tokyo Electron Limited Plasma oxidizing method, plasma processing apparatus, and storage medium
US20090173782A1 (en) * 2008-01-04 2009-07-09 Muscato Michael A Dynamic Card Validation Value

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115243262A (zh) * 2022-07-04 2022-10-25 广东艾科智泊科技股份有限公司 一种防盗仿的遥控开闸方法

Also Published As

Publication number Publication date
FR3038419B1 (fr) 2017-07-28

Similar Documents

Publication Publication Date Title
EP2873045B1 (fr) Entite electronique securisee pour l'autorisation d'une transaction
EP3168769B1 (fr) Procédé d'aide à l'authentification d'un utilisateur, serveur et programme d'ordinateur correspondants
FR2989799A1 (fr) Procede de transfert d'un dispositif a un autre de droits d'acces a un service
FR2923635A1 (fr) Systeme pour des transactions de commerce electronique, dispositif electronique portatif, reseau de communication, produit programme d'ordinateur et methode correspondants.
WO2017001757A1 (fr) Serveur et procede de verification de code de securite
EP3417592B1 (fr) Système d'authentification d'un utilisateur auprès d'un serveur
EP2369780B1 (fr) Procédé et système de validation d'une transaction, terminal transactionnel et programme correspondants.
WO2017093182A1 (fr) Methode de paiement et dispositif utilisant cette methode
WO2008104704A1 (fr) Systeme de paiement electronique comportant un terminal mobile incorporant un porte-monnaie electronique et un serveur
FR3038419A1 (fr) Serveur et procede de verification de code de securite
FR3038417A1 (fr) Serveur et procede de verification de code dynamique de securite
WO2008065271A2 (fr) Procede et systeme de retrait d'argent a l'aide d'un telephone mobile
EP3261014B1 (fr) Procédé d'envoi d'une information de sécurité
FR2945141A1 (fr) Procede et systeme de gestion d'une application de paiement mobile sans contact mettant en oeuvre une verification de code personnel
FR2927453A1 (fr) Procede et systeme de distribution de billets de banque a partir d'un distributeur de billets
CA2912935A1 (fr) Procede de generation et d'affichage d'un cryptogramme pour une carte de paiement, carte de paiement
EP3757921A1 (fr) Procédé et système pour valider un enrôlement d'une personne sur un dispositif biométrique
EP3395042B1 (fr) Serveur d'authentification pour le contrôle d'accès a un service
FR3011111A1 (fr) Securisation d'une transmission de donnees d'identification
EP2204765B1 (fr) Dispositif portable permettant à un individu d'obtenir et utiliser un titre dématérialisé
FR3029318A1 (fr) Procede et dispositif pour securiser les operations bancaires electroniques
EP2448235B1 (fr) Entité électronique gérant un crédit d'utilisation d'une ressource dont l'accès est contrôlé par un dispositif de contrôle
EP3637321A1 (fr) Recharge d'une batterie embarquée dans une carte à puce
WO2014020244A1 (fr) Procédé de paiement sécurisé et dispositif en vue de la mise en œuvre dudit procédé
FR2961332A1 (fr) Borne et procede de distribution de tickets electroniques

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20170106

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 6

PLFP Fee payment

Year of fee payment: 7

PLFP Fee payment

Year of fee payment: 8

CA Change of address

Effective date: 20230220

CD Change of name or company name

Owner name: IDEMIA FRANCE, FR

Effective date: 20230220

PLFP Fee payment

Year of fee payment: 9

PLFP Fee payment

Year of fee payment: 10