FR3045877A1 - Procede d'authentification - Google Patents
Procede d'authentification Download PDFInfo
- Publication number
- FR3045877A1 FR3045877A1 FR1563034A FR1563034A FR3045877A1 FR 3045877 A1 FR3045877 A1 FR 3045877A1 FR 1563034 A FR1563034 A FR 1563034A FR 1563034 A FR1563034 A FR 1563034A FR 3045877 A1 FR3045877 A1 FR 3045877A1
- Authority
- FR
- France
- Prior art keywords
- authentication
- server
- dcw
- transaction data
- security code
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 31
- 238000012795 verification Methods 0.000 claims abstract description 45
- 238000004590 computer program Methods 0.000 claims description 14
- 238000001514 detection method Methods 0.000 claims description 7
- 230000005540 biological transmission Effects 0.000 claims description 5
- 230000004044 response Effects 0.000 claims description 3
- 230000007246 mechanism Effects 0.000 description 15
- 230000003068 static effect Effects 0.000 description 4
- 238000004891 communication Methods 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 238000010586 diagram Methods 0.000 description 2
- 230000005764 inhibitory process Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 102100028043 Fibroblast growth factor 3 Human genes 0.000 description 1
- 101001128138 Homo sapiens NACHT, LRR and PYD domains-containing protein 2 Proteins 0.000 description 1
- 101001128135 Homo sapiens NACHT, LRR and PYD domains-containing protein 4 Proteins 0.000 description 1
- 101001109455 Homo sapiens NACHT, LRR and PYD domains-containing protein 6 Proteins 0.000 description 1
- 101000982939 Homo sapiens PAN2-PAN3 deadenylation complex catalytic subunit PAN2 Proteins 0.000 description 1
- 101001113056 Homo sapiens PAN2-PAN3 deadenylation complex subunit PAN3 Proteins 0.000 description 1
- 101000742934 Homo sapiens Retinol dehydrogenase 14 Proteins 0.000 description 1
- 102100024061 Integrator complex subunit 1 Human genes 0.000 description 1
- 101710092857 Integrator complex subunit 1 Proteins 0.000 description 1
- 108050002021 Integrator complex subunit 2 Proteins 0.000 description 1
- 102100031897 NACHT, LRR and PYD domains-containing protein 2 Human genes 0.000 description 1
- 102100031898 NACHT, LRR and PYD domains-containing protein 4 Human genes 0.000 description 1
- 102100022696 NACHT, LRR and PYD domains-containing protein 6 Human genes 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000002401 inhibitory effect Effects 0.000 description 1
- 238000004377 microelectronic Methods 0.000 description 1
- 230000008569 process Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/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/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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4018—Transaction verification using the card verification value [CVV] associated with the card
-
- 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/0892—Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Computer Security & Cryptography (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Strategic Management (AREA)
- Finance (AREA)
- Computer Networks & Wireless Communication (AREA)
- Microelectronics & Electronic Packaging (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computing Systems (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Telephonic Communication Services (AREA)
Abstract
L'invention concerne un procédé d'authentification mis en œuvre par un serveur d'authentification (ACS) comprenant : réception, en provenance d'un serveur d'accès (SW) à un service (S), d'une requête d'authentification comprenant des données de transaction (DT) associées à une carte à puce ; détermination de si un code de sécurité inclus dans les données de transaction est de type DCVV ; et, dans l'affirmative, détection qu'aucune authentification 3DS ne doit être réalisée et coopération avec un serveur de vérification (SV) pour vérifier la validité du code de sécurité DCVV.
Description
Arrière-plan de l'invention
La présente invention se situe dans le domaine des mécanismes d'authentification et porte plus particulièrement sur une authentification à partir d'un code de sécurité d'une carte à puce. L'invention peut en particulier être utilisée pour contrôler l'accès d'un utilisateur à un service en ligne accessible via un réseau de télécommunications tel quinternet par exemple.
Les transactions financières réalisées à distance (en ligne ou par téléphone par exemple), en utilisant une carte bancaire, présentent des risques de fraude plus importants que lorsque l'utilisateur se présente dans un point de vente avec sa carte bancaire. Ces risques de fraude tiennent du fait qui) y a toujours un risque que les données d'une carte bancaire soit dérobées et utilisées de façon malveillante à l'insu du titulaire légitime de la carte bancaire. Plus particulièrement, il existe un risque qu'un fraudeur subtilise l'identifiant bancaire PAN (pour « Primary Account Number»), le date d'expiration de la carte bancaire, ainsi que le code de sécurité statique (désigné sous l'appellation CW pour « Card Vérification Value ») figurant généralement au dos de la carte.
Afin de renforcer la sécurité des transactions financières à distance, un protocole d'authentification dit 3DS pour « 3-D Secure » a été développé. Ce protocole prévoit l'envoi d'un code secret à l'utilisateur, via par exemple un email ou un SMS, afin d'authentifier l'utilisateur lorsque ce dernier tente de réaliser une transaction à distance avec sa carte bancaire.
Le protocole d'authentification 3DS bien connu de l'homme du métier permet de réduire les risques de fraude lors d'une transaction financière à distance, mais ce protocole présente aussi certains inconvénients. Lors d'une phase d'authentification 3DS sur Internet par exemple, une fenêtre s'ouvre généralement dans le navigateur Internet de l'utilisateur pour inviter ce dernier à saisir le code secret qu'il vient de recevoir par SMS ou email. Cette phase trouble parfois l'utilisateur qui peut dans certains cas perdre confiance et abandonner la transaction en cours, en particulier s'il a un doute sur l'authenticité de cette fenêtre d'invitation. Par ailleurs, l'utilisateur n'est pas toujours en mesure de recevoir le code secret qui lui a été adressé dans le cadre du protocole 3DS, ou bien n'a pas le temps ou l'envie de saisir ce code secret lorsque l'invitation lui en est faite.
Un besoin existe aujourd'hui pour un mécanisme d'authentification permettant de sécuriser efficacement une transaction à puce tout limitant les inconvénients évoqués ci-avant.
Objet et résumé de l'invention / Résumé A cet effet, la présente invention concerne un procédé d'authentification mis en œuvre par un serveur d'authentification, comprenant : - réception, en provenance d'un serveur d'accès à un service, d'une requête d'authentification comprenant des données de transaction associées à une carte à puce ; - détermination de si un code de sécurité inclus dans les données de transaction est de type DCW ; et - dans l'affirmative, détection qu'aucune authentification 3DS ne doit être réalisée et coopération avec un serveur de vérification pour vérifier la validité du code de sécurité DCW.
La présente invention est avantageuse en ce qu'elle permet de s'affranchir du mécanisme d'authentification selon le protocole 3DS lorsqu'il est possible d'authentifier l'utilisateur de la transaction en vérifiant un code de sécurité dynamique DCW généré par la carte à puce de l'utilisateur (lorsque ladite carte est de type DCW). Comme exposé ci-avant, l'authentification selon le protocole 3DS présente certains inconvénients, notamment en ce qu'elle peut causer une gêne pour certains utilisateurs entraînant parfois l'abandon de la transaction en cours. L'invention permet d'inhiber le mécanisme 3DS tout en maintenant un niveau de sécurité élevé grâce à la vérification, lorsque cela est possible, d'un code DCW. Grâce à l'invention, il est possible de faciliter l'authentification d'un utilisateur, et donc son accès à un service.
Selon un mode de réalisation particulier, le procédé d'authentification comprend l'envoi, au serveur d'accès, d'un message d'authentification positive des données de transaction si la validité du code DCW est vérifiée avec succès lors de ladite coopération.
Selon un mode de réalisation particulier, le procédé d'authentification est tel que : - le serveur d'authentification détermine si la carte à puce est de type DCW à partir d'un identifiant PAN compris dans les données de transaction reçues ; et - uniquement dans l'affirmative, le serveur d'authentification détermine que le code de sécurité est de type DCW.
Selon un mode de réalisation particulier, si le code de sécurité est de type DCW, le serveur d'authentification empêche la réalisation d'une authentification 3DS de ladite carte à puce.
Selon un mode de réalisation particulier, si le code de sécurité est de type CW et si le serveur d'authentification détermine, à partir des données de transaction, qu'il est autorisé de procéder à une authentification 3DS, le serveur d'authentification autorise la réalisation d'une authentification 3DS de ladite carte à puce.
Selon un mode de réalisation particulier, la carte à puce est une carte bancaire, et les données de transactions comprennent un identifiant PAN et un date d'expiration de ladite carte bancaire.
Selon un mode de réalisation particulier, ladite coopération comprend : - envoi, au serveur de vérification, des données de transaction comprenant le code de sécurité de type DCW, l'identifiant bancaire PAN et la date d'expiration ; et - réception, en réponse audit envoi, du résultat de la vérification de validité du code DCW.
Selon un mode de réalisation particulier, la carte à puce est une carte bancaire et le serveur d'authentification est un serveur de contrôle d'accès, dans lequel, si le code de sécurité est déterminé comme étant de type DCW, le serveur de contrôle d'accès réalise les étapes suivantes : - vérification, à partir des données de transaction, de si une authentification 3DS peut être réalisé pour la carte bancaire ; et - dans l'affirmative, réalisation d'une authentification selon le protocole 3DS de ladite carte bancaire.
Selon un mode de réalisation particulier, la carte à puce est une carte bancaire et le serveur d'authentification est un serveur annuaire 3DS, dans lequel, si le code de sécurité est déterminé comme étant de type DCW, le serveur annuaire 3DS réalise les étapes suivantes : - vérification, à partir des données de transaction, de si une authentification 3DS peut être réalisée pour la carte bancaire ; et - dans l'affirmative, transmission des données de transaction à un serveur de contrôle d'accès pour causer la réalisation d'une authentification de ladite carte bancaire selon le protocole 3DS.
Selon un mode de réalisation particulier, le serveur d'authentification se configure, seulement si un paramètre reçu du serveur d'accès avec les données de transaction est dans un état prédéfini, pour détecter qu'aucune authentification 3DS ne doit être réalisée si un code de sécurité inclus dans les données de transaction est de type DCW. L'invention concerne également un procédé de contrôle mis en œuvre par un serveur d'accès à un service, comprenant : - réception de données de transaction associées à une carte à puce lors d'une transaction avec le serveur d'accès ; - transmission des données de transaction à un serveur d'authentification pour demander une authentification de la transaction selon le protocole 3DS ; et - détermination, à partir d'un message reçu du serveur d'authentification, qu'aucune authentification selon le protocole 3DS ne doit être réalisée si la carte à puce est de type DCW.
Selon un mode de réalisation particulier, le serveur d'accès détermine que l'authentification est réalisée avec succès sur réception, en provenance du serveur de contrôle, d'un message de vérification positive d'un code de sécurité DCW compris dans les données de transaction.
Selon un mode de réalisation particulier, le serveur d'accès envoie, au serveur d'authentification, un paramètre avec les données de transaction, ledit paramètre étant dans un état prédéfini pour indiquer qu'aucune authentification 3DS ne doit être réalisée si un code de sécurité inclus dans les données de transaction est de type DCW.
Dans un mode particulier de réalisation, les différentes étapes du procédé d'authentification mis en œuvre par le serveur d'authentification comme défini ci-avant sont déterminées par des instructions de programmes d'ordinateurs.
De même, selon un mode de réalisation particulier, les différentes étapes du procédé de contrôle mis en œuvre par le serveur d'accès comme défini ci-avant 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 (ou support d'enregistrement), ce programme étant susceptible d'être mis en œuvre dans un serveur, ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes de l'un au moins des procédés tels que définis ci-avant. L'invention vise aussi un support d'enregistrement (ou support d'informations) lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. A noter que les programmes mentionnés dans le présent exposé peuvent utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
De plus, les supports d'enregistrement mentionnés ci-avant peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur. D'autre part, les supports d'enregistrement peuvent correspondre à 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, les supports d'enregistrement peuvent correspondre à 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 D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures: - la figure IA représente schématiquement un système comprenant un terminal, un serveur d'accès à un service, un serveur annuaire 3DS, un serveur ACS et un serveur de vérification DCW, conformément à un mode de réalisation particulier de l'invention ; - la figure IB représente schématiquement une carte à puce selon un mode de réalisation particulier de l'invention ; - la figure 2 représente schématiquement la structure d'un serveur d'accès selon un mode de réalisation particulier de l'invention ; - la figure 3 représente schématiquement des modules mis en œuvre dans le serveur d'accès représenté en figure IA et 2, conformément à un mode de réalisation particulier de l'invention ; - la figure 4 représente schématiquement la structure d'un serveur ACS selon un mode de réalisation particulier de l'invention ; - la figure 5 représente schématiquement des modules mis en œuvre dans le serveur ACS représenté en figures IA et 4, conformément à un mode de réalisation particulier de l'invention ; - la figure 6 représente un exemple de table enregistrée dans une mémoire du serveur ACS représenté en figures IA et 4, conformément à un mode de réalisation particulier de l'invention ; - la figure 7 représente, sous la forme d'un diagramme, des étapes mises en œuvre notamment par le serveur d'accès, le serveur annuaire 3DS et le serveur ACS, conformément à un mode de réalisation particulier de l'invention ; et - la figure 8 représente, sous la forme d'un diagramme, des étapes mises en œuvre notamment par le serveur d'accès, le serveur annuaire 3DS et le serveur ACS, conformément à une variante du mode de réalisation illustré en figure 7.
Description détaillée de plusieurs modes de réalisation
Comme déjà indiquée, la présente invention concerne les mécanismes d'authentification et porte plus particulièrement sur une authentification à partir d'un code de sécurité d'une carte à puce.
Afin de sécuriser les transactions à distance, une solution consiste à utiliser des cartes bancaires aptes à générer, et à afficher sur un écran de la carte, un code de sécurité dynamique (appelé DCW) qui change au cours de la vie de la carte. Le système de traitement informatique du service financier de la transaction est apte à vérifier la validité de ce code dynamique de sécurité, en fonction par exemple d'un paramètre temporel, pour valider ou non la transaction. L'utilisation d'un tel code dynamique de sécurité permet de s'assurer que l'utilisateur a réellement en sa possession la carte bancaire concernée au moment de la transaction. S'il est dérobé, le code dynamique de sécurité a une utilité limitée dans la mesure où la validité de ce code n'est que temporaire.
Dans le présent exposé, on appellera carte à puce DCW (ou carte DCW) une carte à puce apte à générer des codes dynamiques de sécurité DCW. Les codes DCW sont connus de l'homme du métier et ne seront donc pas décrits plus en détail dans le présent exposé. L'invention propose d'améliorer les mécanismes d'authentification existants en inhibant le protocole d'authentification 3DS lorsqu'il est possible d'authentifier une transaction en cours à partir d'un code de sécurité dynamique DCW (pour « Dynamic Card Vérification Value »), dans le cas où un tel code dynamique peut être est généré par la carte à puce de l'utilisateur.
Il convient de noter que la notion de transaction est ici entendue au sens large et comprend par exemple, dans le domaine bancaire, tout type de transaction financière, telle que par exemple une transaction de paiement, une transaction de transfert, ou encore une consultation d'un compte bancaire. L'invention, selon différents modes de réalisation, met par exemple en œuvre un serveur d'authentification apte à recevoir, en provenance d'un serveur d'accès à un service, une requête d'authentification comprenant des données de transaction associées à une carte à puce ; à déterminer si un code de sécurité inclus dans les données de transaction est de type DCW ; et dans l'affirmative, à détecter qu'aucune authentification 3DS ne doit être réalisée pour authentifier ladite carte et à coopérer avec un serveur de vérification pour vérifier la validité du code de sécurité DCW. L'invention, selon un mode de réalisation particulier, vise également un serveur d'accès apte à recevoir des données de transaction associées à une carte à puce lors d'une transaction avec le serveur d'accès ; à transmettre les données de transaction à un serveur d'authentification pour demander une authentification de la transaction selon le protocole 3DS ; et à déterminer, à partir d'un message reçu du serveur d'authentification, qu'aucune authentification selon le protocole 3DS ne doit être réalisée si la carte à puce est de type DCW. Le serveur d'accès peut par exemple déterminer que les données de transaction sont authentiques à partir d'un message, reçu du serveur d'authentification, indiquant qu'un code DCW inclus dans les données de transaction a été vérifié avec succès. D'autres aspects et avantages de la présente invention ressortiront des exemples de réalisation décrits ci-dessous en référence aux dessins mentionnés ci-avant.
Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité.
La figure IA représente, de manière schématique, un système SY selon un mode de réalisation particulier de l'invention. Le système SY comprend dans cet exemple un terminal T, un serveur d'accès SW, un serveur annuaire 3DS (ou « 3DSDirectory Server» en anglais) noté ici SDIR, un serveur de contrôle d'accès ACS (pour « Access control Server») et un serveur SV de vérification, selon un mode de réalisation particulier de l'invention.
Le système SY permet dans cet exemple de contrôler l'accès d'un utilisateur à un service S. Dans l'exemple envisagé ici, un utilisateur tente d'utiliser le service S, à l'aide d'une carte à puce C représentée en figure IB.
Selon le mode de réalisation illustré en figure IB, et comme exposé dans les exemples de réalisation qui suivent, la carte à puce C est ici une carte bancaire comportant des données de carte bancaire, à savoir un identifiant bancaire PAN (pour « Primary Account Number»), un date d'expiration EXP et un code de sécurité CSC de carte. On comprendra que le code de sécurité CSC peut être un code statique (code CW pour « Card Vérification Value ») figurant sur la carte ou un code dynamique (DCW pour « Dynamic Card Vérification value ») pouvant être généré par la carte.
La carte bancaire C est par exemple conforme au protocole EMV. D'autres types de cartes à puce peuvent être envisagés dans le cadre de l'invention. L'utilisateur du terminal T représenté en figure IA est ici apte à communiquer, via un réseau de communications RI tel qu'internet par exemple, avec un serveur d'accès SW contrôlant l'accès au service S. Au cours d'une transaction, le terminal T est apte à envoyer, au serveur d'accès SW, des données de transaction DT associées à la carte à puce C, par exemple pour réaliser une transaction financière (achat...) avec le service S. Lès données de transaction DT comprennent par exemple l'identifiant PAN, la date EXP d'expiration et le code de sécurité CSC.
Le serveur SW est par exemple un serveur Web, de type marchant ou autre, apte à gérer l'accès d'utilisateurs au serveur Web S en question. On comprendra que le service S peut être quelconque. Selon un exemple particulier, le service S est un service marchant.
Le serveur d'accès SW est apte à coopérer avec un serveur annuaire 3DS SDIR pour déclencher si possible une authentification selon le protocole 3DS de l'utilisateur lors d'une transaction. Pour ce faire, le serveur d'accès SW est apte à transmettre, au serveur annuaire 3DS SDIR, les données de transactions DT pour demander l'authentification de la transaction en cours.
Le serveur de contrôle d'accès ACS est apte, à partir des données de transaction DT reçues, à déterminer si une authentification 3DS de la transaction doit être réalisée. Le serveur de contrôle ACS détermine si cette authentification 3DS doit être réalisée à partir des données de transactions DT transmises par le serveur annuaire 3DS SDIR. Selon un mode de réalisation particulier, le serveur ACS est configuré pour détecter qu'aucune authentification 3DS ne doit être réalisée si le code de sécurité CSC inclus dans les données de transaction DT est de type DCW.
Dans l'exemple envisagé ici, si aucune authentification 3DS ne doit être réalisée, le serveur ACS est en outre configuré pour coopérer avec le serveur de vérification SV pour vérifier la validité du code de sécurité CSC de type DCW. Si l'authentification du code de sécurité CSC est positive, le serveur ACS envoie alors au serveur d'accès SW, via le serveur annuaire 3DS SDIR, un message d'authentification positive des données de transaction DT. Selon un exemple particulier, ce message d'authentification positive indique en outre au serveur d'accès SW qu'aucune authentification 3DS n'est réalisée, au moyen par exemple d'un paramètre prévu à cet effet dans ledit message.
Selon un exemple de réalisation particulier, si le code de sécurité CSC est un code statique de type CW, le serveur ACS est configuré pour détecter qu'une authentification 3DS doit être réalisée en association avec les données de transaction DT reçues. Le serveur de contrôle d'accès ACS réalise alors l'authentification 3DS selon le protocole 3DS bien connu de l'homme du métier.
La figure 2 représente schématiquement la structure du serveur d'accès S selon un mode de réalisation particulier de l'invention. Dans cet exemple, le serveur d'accès SW comprend un processeur 10, une mémoire non volatile MRI et une interface de communication INT1.
Dans l'exemple envisagé ici, la mémoire MRI est une mémoire non volatile réinscriptible ou une mémoire morte (ROM), cette mémoire constituant un support d'enregistrement (ou support d'informations) conforme à un mode de réalisation particulier, lisible par le serveur d'accès SW, et sur lequel est enregistré un programme d'ordinateur PG1 conforme à un mode de réalisation particulier. Ce programme d'ordinateur PG1 comporte des instructions pour l'exécution des étapes d'un procédé de contrôle selon un mode de réalisation particulier.
Le processeur 10 piloté par le programme d'ordinateur PG1, met ici en oeuvre un certain nombre de modules représentés en figure 3, à savoir : un module de réception M2, un module de transmission M4 et un module de détermination M6.
Selon un mode de réalisation particulier, le module de réception M2 est apte à recevoir les données de transaction DT associées à la carte à puce C lors d'une transaction avec le serveur d'accès SW. Le module de transmission M4 est apte à transmettre les données de transaction DT au serveur annuaire 3DS SDIR pour demander une authentification de la transaction selon le protocole 3DS. Le module de détermination M6 est apte à déterminer, à partir d'un message reçu du serveur d'authentification, qu'aucune authentification selon le protocole 3DS ne doit être réalisée si la carte à puce est de type DCW.
La figure 4 représente schématiquement la structure du serveur de contrôle d'accès ACS selon un mode de réalisation particulier de l'invention. Dans cet exemple, le serveur ACS comprend un processeur 20, une mémoire non volatile MR2, une interface de communication INT2 et une mémoire non volatile MR4 comprenant une table TB.
Dans l'exemple envisagé ici, la mémoire MR2 est une mémoire non volatile réinscriptible ou une mémoire morte (ROM), cette mémoire constituant un support d'enregistrement (ou support d'informations) conforme à un mode de réalisation particulier, lisible par le serveur ACS, et sur lequel est enregistré un programme d'ordinateur PG2 conforme à un mode de réalisation particulier. Ce programme d'ordinateur PG2 comporte des instructions pour l'exécution des étapes d'un procédé d'authentification selon un mode de réalisation particulier.
Dans un exemple particulier, la table TB comprend au moins une correspondance entre un identifiant PAN et une donnée DN, ladite donnée DN indiquant si la carte bancaire C associée audit PAN est de type DCW. Le serveur ACS est apte, à partir de ladite donnée DN, à déterminer si la carte bancaire C est de type DCW. Le serveur ACS peut ainsi déterminer, à partir de la table TB, si le code de sécurité CSC inclus dans les données de transaction DT est de type DCW. On suppose ici que la table TB identifie par exemple des données DN en association avec trois identifiant PAN1, PAN2 et PAN3.
Dans un exemple particulier, chaque donnée DN peut prendre deux états distincts indiquant que l'identifiant PAN correspondant est associé respectivement à une carte bancaire de type DCW et CW.
Le processeur 20 piloté par le programme d'ordinateur PG2, met ici en œuvre un certain nombre de modules représentés en figure 5, à savoir : un module de réception M20, un module de détermination M22, un module de détection M24 et un module de vérification M26.
Selon un mode de réalisation particulier, le module de réception M20 est apte à recevoir, en provenance du serveur d'accès SW, une requête d'authentification comprenant des données de transaction DT associées à la carte à puce C. Le module de détermination M22 est configuré pour déterminer si le code de sécurité CSC inclus dans les données de transaction DT est de type DCW. Si le code de sécurité CSC est déterminé comme étant de type DCW : o le module de détection M24 est configuré pour détecter qu'aucune authentification 3DS ne doit être réalisée ; et o le module de vérification M26 est configuré pour coopérer avec le serveur de vérification SV pour vérifier la validité du code de sécurité DCW.
On comprendra que la définition des modules M2 à M6 illustrés en figure 3 et des modules M20 à M26 illustrés en figure 5 ne constitue qu'un exemple non limitatif de réalisation de l'invention, d'autres mises en œuvre étant envisageables dans le cadre de l'invention.
Un mode de réalisation particulier de l'invention est à présent décrit en référence à la figure 7. Plus précisément, le serveur d'accès SW met ici en œuvre un procédé de contrôle en exécutant le programme d'ordinateur PG1, et le serveur ACS met ici en œuvre un procédé d'authentification en exécutant le programme d'ordinateur PG2.
On suppose à présent qu'un utilisateur tente de réaliser une transaction avec le serveur d'accès SW (ou plus précisément avec le service S) en utilisant sa carte bancaire C. Dans un exemple particulier, la transaction est une transaction financière, correspondant par exemple à un paiement. On comprendra que d'autres mises en œuvre sont envisageables dans le cadre de l'invention.
Au cours d'une étape d'envoi A2, le terminal T de l'utilisateur envoie au serveur d'accès SW des données de transaction DT associées à la carte bancaire C. Dans cet exemple, les données de transactions DT comprennent l'identifiant PAN, le code d'accès CSC et la date EXP d'expiration de la carte C. Pour ce faire, l'utilisateur saisit par exemple au préalable tout ou partie des données de transaction DT sur son terminal T en réponse à une invitation du service S.
Le serveur d'accès SW reçoit les données de transaction DT lors d'une étape de réception B2. Le serveur d'accès SW envoie (B4) ensuite les données de transaction DT au serveur annuaire 3DS SDIR dans une requête d'authentification RQ1. Dans un exemple particulier, la requête d'authentification RQ1 requière une authentification selon le protocole 3DS.
Suite à la réception (C4) des données de transaction DT, le serveur annuaire 3DS SDIR détermine (C6), à partir de tout ou partie des données de transaction DT (par exemple à partir de l'identifiant PAN), s'il est autorisé de procéder à une authentification 3DS pour la transaction en cours. Dans un exemple particulier, le serveur SDIR réalise la détermination C6 à partir d'une liste d'identifiants PAN exclus du mécanisme 3DS ou à partir d'une liste d'identifiants PAN autorisés à utiliser le mécanisme 3DS. S'il est déterminé en C6 qu'une authentification 3DS n'est pas autorisé, le procédé prend fin (C8). Le serveur SDIR peut éventuellement envoyer un message de refus d'authentification 3DS au serveur d'accès SW.
Si, en revanche, le serveur annuaire 3DS SDIR détermine (CIO) qu'il est autorisé de réaliser une authentification 3DS en association avec les données de transaction DT reçues, ledit serveur SDIR envoie (CIO) au serveur ACS une requête d'authentification RQ2 comprenant les données de transaction DT.
Le serveur de contrôle d'accès ACS reçoit les données de transaction DT inclus dans la requête d'authentification RQ2 au cours d'une étape de réception D10.
Le serveur ACS détermine (DU) ensuite, à partir des données de transaction DT, si le code de sécurité CSC est de type DCW. Dans un exemple particulier, le serveur ACS détermine (DU) si le code de sécurité CSC est un code DCW à partir de l'identifiant PAN inclus dans les données de transaction DT. Selon un exemple particulier, le serveur ACS utilise la table TB pour déterminer, à partir de l'identifiant PAN, si le code de sécurité est de type DCW. S'il est déterminé en DU que le code CSC de la carte C n'est pas un code dynamique DCW, le procédé d'authentification de l'invention prend fin (D12). Au cours de l'étape D12, le serveur ACS peut réaliser une authentification 3DS de la transaction (si cela est possible), ou envoyer un message de refus d'une transaction 3DS (si une authentification selon le protocole 3DS n'est pas possible).
Selon un mode de réalisation particulier, si le code de sécurité CSC est un code statique de type CW et si le serveur ACS détermine, à partir des données de transaction, qu'il est autorisé de procéder à une authentification 3DS, le serveur ACS autorise (D12) la réalisation d'une authentification 3DS de ladite carte bancaire. Au cours d'une telle authentification 3DS, l'utilisateur peut recevoir via un SMS ou email un code secret sur un terminal (T ou autre), et être invité sur son terminai T à saisir ce code secret afin d'être authentifié par le serveur ACS. Le protocole 3DS étant bien connu de l'homme du métier, il ne sera pas décrit plus en détail dans le présent exposé par souci de simplicité.
Si, en revanche, il est déterminé en DU que le code de sécurité CSC est de type DCW, le serveur ACS : - détecte (D13) qu'aucune authentification 3DS ne doit être réalisée, et - coopère (D14-D20) avec le serveur de vérification SV pour vérifier la validité du code de sécurité CSC.
Selon un mode de réalisation particulier, si le code de sécurité est de type DCW (DU), le serveur ACS empêche la réalisation d'une authentification 3DS de la carte bancaire C. Autrement dit, lorsque la carte bancaire C est de type DCW, le serveur ACS est configuré pour bloquer la réalisation d'une authentification 3DS pour la transaction en cours d'authentification.
Selon un exemple particulier, lors de ladite coopération D14-D20, le serveur ACS envoie (D14) au serveur de vérification SV, les données de transaction DT comprenant le code de sécurité CSC de type DCW, l'identifiant bancaire PAN et la date EXP d'expiration. Une fois ces données reçues (E14), le serveur de vérification vérifie (E16) la validité du code de sécurité dynamique CSC. Le serveur de vérification vérifie par exemple la validité du code de sécurité dynamique CSC en générant un deuxième code DCW et en comparant celui-ci avec le code de sécurité dynamique CSC reçu en E14. Dans un exemple particulier, le serveur de vérification SV obtient ce deuxième code DCW en appliquant une fonction cryptographique à l'identifiant PAN, à la date EXP d'expiration et à une donnée temporelle. D'autres exemples de vérification d'un code de sécurité dynamique de type DCW sont envisageables. Le calcul et la vérification de la validité d'un code de sécurité DCW étant connus en soi, ils ne seront pas décrits plus en détail dans le présent exposé.
Le serveur de vérification SV envoie (E18) ensuite le résultat de la vérification E16 (ici dans un message M2) au serveur ACS.
Le serveur ACS reçoit le résultat M2 de la vérification de validité du code de sécurité CSC lors d'une étape de réception D20. Le serveur ACS envoie (D22) ensuite, au serveur annuaire 3DS SDIR, un message M4 d'authentification positive des données de transaction DT si la vérification E16 de validité du code de sécurité CSC a été passée avec succès. Dans le cas contraire, le serveur ACS envoie (D22) un message M4 d'authentification négative au serveur annuaire 3DS SDIR. Dans un exemple particulier, le message M4 spécifie si le code de sécurité DCW présent dans les données de transaction DT a été vérifié ou non avec succès.
Une fois reçu (C22), le serveur annuaire 3DS SDIR transfère (C24) au serveur d'accès SW le message M4 indiquant si l'authentification sur la base du code de sécurité dynamique CSC a été passée avec succès.
Le serveur d'accès SW détermine (B26) si l'authentification de la transaction est passée avec succès à partir du message M4 reçu préalablement à l'étape de réception B24. On comprendra que le serveur d'accès SW peut être configuré pour réaliser tout traitement approprié en fonction du résultat de l'authentification.
Selon un mode de réalisation particulier, s'il est déterminé (B26) que l'authentification est passée avec succès, le serveur d'accès SW autorise (B26) la transaction en cours avec l'utilisateur. Dans le cas contraire, le serveur d'accès SW refuse (B26) la transaction.
La présente invention est avantageuse en ce qu'elle permet de s'affranchir du mécanisme d'authentification selon le protocole 3DS lorsqu'il est possible d'authentifier l'utilisateur de la transaction en vérifiant un code de sécurité dynamique DCW généré par la carte à puce de l'utilisateur (lorsque ladite carte est de type DCW). Comme exposé ci-avant, l'authentification selon le protocole 3DS présente certains inconvénients, notamment en ce qu'elle peut causer une gêne pour certains utilisateurs entraînant parfois l'abandon de la transaction en cours. L'invention permet d'inhiber le mécanisme 3DS tout en maintenant un niveau de sécurité élevé grâce à la vérification, lorsque cela est possible, d'un code DCW. Grâce à l'invention, il est possible de faciliter l'authentification d'un utilisateur, et donc l'accès à un service.
On comprendra que le mode de réalisation décrit ci-avant en référence à la figure 7 ne constitue qu'un exemple non limitatif de réalisation de l'invention, divers variantes de réalisation étant envisageables dans le cadre de l'invention.
Selon un mode de réalisation particulier, une fois l'étape de vérification E16 réalisée, le serveur de vérification SV (ou l'un parmi le serveur ACS, le serveur annuaire 3DS SDIR et le serveur d'accès SW) envoie (E18) en outre un message M6 au terminal T (ou à un autre terminal) de l'utilisateur. A partir du message M6 reçu (A30), l'utilisateur est alors apte à déterminer le résultat de l'authentification du code de sécurité CSC (de type DCW) par le serveur de vérification SV.
Selon un mode de réalisation particulier, le serveur ACS inclut dans son message M4 d'authentification positive un paramètre indiquant au serveur d'accès SW qu'aucune authentification selon le protocole 3DS n'a été réalisée. A partir de ce paramètre, le serveur d'accès SW peut ainsi en déduire que le mécanisme d'authentification 3DS a été bloqué mais que l'authentification a néanmoins été réalisée avec succès grâce à une vérification d'un code de sécurité DCW.
Un autre mode de réalisation est à présent décrit en référence à la figure 8. Dans ce mode de réalisation, les étapes A2, B2, B4 et C4 sont réalisées comme déjà décrites ci-avant en référence au mode de réalisation illustré en figure 7. Le mode de réalisation illustré en figure 8 diffère du mode de réalisation précédent en ce que c'est cette fois le serveur annuaire 3DS SDIR qui détermine (C50), à partir des données de transaction DT, si la carte bancaire C est de type DCW et, dans l'affirmative, qui détecte (C51) qu'aucune authentification selon le protocole 3DS ne doit être réalisée et qui coopère (C52) alors avec le serveur ACS, ou directement avec le serveur de vérification SV, pour vérifier la validité du code de sécurité dynamique CSC. L'étape de détermination C50 et l'étape de détection C51 sont réalisées de façon analogue aux étapes respectives DU et D13 décrites ci-avant en référence à la figure 7.
Comme illustré en figure 8, suite à l'étape de détection C51, le serveur annuaire 3DS SDIR envoie (C52) au serveur de vérification SV une requête de vérification RQ10 comprenant les données de transaction DT. Alternativement, le serveur annuaire 3DS SDIR envoie (C52) la requête de vérification RQ10 au serveur ACS qui transmets (D52) celle-ci au serveur de vérification SV.
Le serveur de vérification SV vérifie (E16) la validité du code de sécurité dynamique CSC comme déjà décrit en référence à la figure 7.
Au cours d'une étape d'envoi E54, le serveur de vérification SV envoie ensuite un message M8 d'authentification positive ou négative (selon le résultat de E16) des données de transaction DT au serveur annuaire 3DS SDIR, éventuellement par l'intermédiaire du serveur ACS qui transfère (D54) alors ledit message.
On comprendra au vu de ce qui précède que, selon la mise en œuvre de l'invention, c'est le serveur annuaire 3DS SDIR ou le serveur ACS qui détermine, à partir des données de transaction DT, si la carte bancaire C est de type DCW et, dans l'affirmative, qui détecte qu'aucune authentification selon le protocole 3DS ne doit être réalisée et qui cause la vérification de la validité du code de sécurité dynamique CSC de la carte C. Aussi, le serveur annuaire 3DS SDIR et le serveur ACS peuvent chacun constituer un serveur d'authentification au sens de l'invention.
Selon une variante des modes de réalisation précédents, le serveur d'authentification de l'invention se configure, seulement si un paramètre reçu du serveur d'accès SW avec les données de transaction DT est dans un état prédéfini, pour détecter qu'aucune authentification 3DS ne doit être réalisée lorsqu'un code de sécurité inclus dans les données de transaction est de type DCW. Autrement dit, à partir d'un paramètre envoyé par le serveur d'accès SW, le serveur d'authentification de l'invention (i.e. le serveur annuaire 3DS SDIR ou le serveur ACS selon le cas) est apte à déterminer s'il doit mettre en œuvre le mécanisme d'inhibition du mécanisme d'authentification 3DS selon l'invention. Dans un exemple particulier, si ce paramètre est dans un premier état prédéterminé, le serveur d'authentification tente systématiquement de déclencher une authentification 3DS, et si ledit paramètre est dans un deuxième état prédéterminé, le serveur d'authentification inhibe le mécanisme 3DS si une authentification sur la base d'un code de sécurité DCW est possible.
Selon un mode de réalisation particulier, le serveur d'authentification de l'invention (i.e. le serveur annuaire 3DS SDIR ou le serveur ACS selon le cas), détermine, à partir de données d'historique (bancaire par exemple) enregistrées en association avec l'identifiant PAN, s'il doit mettre en œuvre le mécanisme d'inhibition de l'authentification 3DS conformément à l'invention. Le serveur d'authentification peut ainsi juger, pour la transaction en cours, un niveau de risque et en déduire s'il est nécessaire de réaliser une authentification 3DS (éventuellement en supplément d'une vérification d'un code de sécurité DCW, selon la configuration choisie).
Un homme du métier comprendra que les modes de réalisation et variantes décrits ci-avant ne constituent que des exemples non limitatifs de mise en œuvre de l'invention. En particulier, l'homme du métier pourra envisager une quelconque adaptation ou combinaison des modes de réalisation et variantes décrits ci-avant afin de répondre à un besoin bien particulier.
Claims (17)
- REVENDICATIONS1. Procédé d'authentification mis en œuvre par un serveur d'authentification (ACS ; SDIR), comprenant : - réception (D10 ; C4), en provenance d'un serveur d'accès (SW) à un service (S), d'une requête d'authentification (RQ2 ; RQ1) comprenant des données de transaction (DT) associées à une carte à puce (C) ; - détermination (DU ; C50) de si un code de sécurité (CSC) inclus dans les données de transaction est de type DCW ; et - dans l'affirmative, détection (D13 ; C51) qu'aucune authentification 3DS ne doit être réalisée et coopération (D14 ; C52) avec un serveur de vérification (SV) pour vérifier la validité du code de sécurité DCW.
- 2. Procédé selon la revendication 1, comprenant l'envoi (D22 ; C56), au serveur d'accès (SW), d'un message (M4 ; M8) d'authentification positive des données de transaction si la validité du code DCW est vérifiée avec succès lors de ladite coopération.
- 3. Procédé selon la revendication 1 ou 2, dans lequel : - le serveur d'authentification (ACS ; SDIR) détermine si la carte à puce est de type DCW à partir d'un identifiant PAN compris dans les données de transaction (DT) reçues ; et - uniquement dans l'affirmative, le serveur d'authentification détermine (DU ; C50) que le code de sécurité est de type DCW.
- 4. Procédé selon l'une quelconque des revendications 1 à 3, dans lequel si le code de sécurité (CSC) est de type DCW, le serveur d'authentification empêche la réalisation d'une authentification 3DS de ladite carte à puce.
- 5. Procédé selon l'une quelconque des revendications 1 à 4, dans lequel si le code de sécurité est de type CW et si le serveur d'authentification détermine, à partir des données de transaction, qu'il est autorisé de procéder à une authentification 3DS, le serveur d'authentification autorise (D12) la réalisation d'une authentification 3DS de ladite carte à puce.
- 6. Procédé selon l'une quelconque des revendications 1 à 5, dans lequel la carte à puce est une carte bancaire, et les données de transactions (DT) comprennent un identifiant PAN et un date d'expiration (EXP) de ladite carte bancaire (C).
- 7. Procédé selon la revendication 6, dans lequel ladite coopération comprend : - envoi (D14), au serveur de vérification (SV), des données de transaction (DT) comprenant le code de sécurité de type DCW, l'identifiant bancaire PAN et la date d'expiration (EXP) ; et - réception (D20), en réponse audit envoi, du résultat (M2) de la vérification de validité du code DCW.
- 8. Procédé selon l'une quelconque des revendications 1 à 7, dans lequel la carte à puce (C) est une carte bancaire et le serveur d'authentification est un serveur de contrôle d'accès (ACS), dans lequel, si le code de sécurité (CSC) est déterminé comme étant de type DCW, le serveur de contrôle d'accès (ACS) réalise les étapes suivantes : - vérification (D12), à partir des données de transaction (DT), de si une authentification 3DS peut être réalisé pour la carte bancaire ; et - dans l'affirmative, réalisation (D12) d'une authentification selon le protocole 3DS de ladite carte bancaire.
- 9. Procédé selon l'une quelconque des revendications 1 à 7, dans lequel la carte à puce est une carte bancaire et le serveur d'authentification est un serveur annuaire 3DS (SDIR), dans lequel, si le code de sécurité (CSC) est déterminé comme étant de type DCW, le serveur annuaire 3DS (SDIR) réalise les étapes suivantes : - vérification (C50), à partir des données de transaction, de si une authentification 3DS peut être réalisée pour la carte bancaire ; et - dans l'affirmative, transmission des données de transaction à un serveur de contrôle d'accès pour causer la réalisation d'une authentification de ladite carte bancaire selon le protocole 3DS.
- 10. Procédé selon l'une quelconque des revendications 1 à 9, dans lequel, le serveur d'authentification se configure, seulement si un paramètre reçu du serveur d'accès (SW) avec les données de transaction (DT) est dans un état prédéfini, pour détecter qu'aucune authentification 3DS ne doit être réalisée si un code de sécurité (CSC) inclus dans les données de transaction est de type DCW.
- 11. Procédé de contrôle mis en oeuvre par un serveur d'accès (SW) à un service, comprenant : - réception (B2) de données de transaction (DT) associées à une carte à puce (C) lors d'une transaction avec le serveur d'accès ; - transmission (B4) des données de transaction à un serveur d'authentification (ACS ; SDIR) pour demander une authentification de la transaction selon le protocole 3DS ; et - détermination (B26 ; B58), à partir d'un message reçu (M4 ; M8) du serveur d'authentification, qu'aucune authentification selon le protocole 3DS ne doit être réalisée si la carte à puce est de type DCW.
- 12. Procédé selon la revendication 11, dans lequel le serveur d'accès détermine (B26 ; B58) que l'authentification est réalisée avec succès sur réception (B26 ; B58), en provenance du serveur de contrôle, d'un message de vérification positive d'un code de sécurité DCW compris dans les données de transaction.
- 13. Procédé selon la revendication 11 ou 12, dans lequel le serveur d'accès envoie, au serveur d'authentification, un paramètre avec les données de transaction, ledit paramètre étant dans un état prédéfini pour indiquer qu'aucune authentification 3DS ne doit être réalisée si un code de sécurité inclus dans les données de transaction est de type DCW.
- 14. Programme d'ordinateur (PG1 ; PG2) comportant des instructions pour l'exécution des étapes d'un procédé de configuration selon l'une quelconque des revendications 1 à 13 lorsque ledit programme est exécuté par un ordinateur.
- 15. Support d'enregistrement (MRI ; MR2) lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur (PG1 ; PG2) comprenant des instructions pour l'exécution des étapes d'un procédé selon l'une quelconque des revendications 1 à 13.
- 16. Serveur d'authentification (SA ; SS), comprenant : - un module de réception (M20) apte à recevoir, en provenance d'un serveur d'accès à un service, une requête d'authentification comprenant des données de transaction associées à une carte à puce ; - un module de détermination (M22) pour déterminer si un code de sécurité inclus dans les données de transaction est de type DCW ; et - un module de détection (M24) et un module de vérification (M26), dans lequel, si le code de sécurité est déterminé comme étant de type DCW : o le module de détection est configuré pour détecter qu'aucune authentification 3DS ne doit être réalisée ; et o le module de vérification est configuré pour coopérer avec un serveur de vérification pour vérifier la validité du code de sécurité DCW.
- 17. Serveur d'accès (SW) à un service, comprenant : - un module de réception (M2) pour recevoir des données de transaction associées à une carte à puce lors d'une transaction avec le serveur d'accès ; - un module de transmission (M4) pour transmettre les données de transaction à un serveur d'authentification pour demander une authentification de la transaction selon le protocole 3DS ; et - un module de détermination (M6) pour déterminer, à partir d'un message reçu du serveur d'authentification, qu'aucune authentification selon le protocole 3DS ne doit être réalisée si la carte à puce est de type DCW.
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1563034A FR3045877B1 (fr) | 2015-12-22 | 2015-12-22 | Procede d'authentification |
| EP16829414.8A EP3394812A1 (fr) | 2015-12-22 | 2016-12-21 | Procédé d'authentification |
| PCT/FR2016/053604 WO2017109405A1 (fr) | 2015-12-22 | 2016-12-21 | Procédé d'authentification |
| CN201680081572.4A CN108701304B (zh) | 2015-12-22 | 2016-12-21 | 认证方法 |
| US16/064,940 US10909530B2 (en) | 2015-12-22 | 2016-12-21 | Authentication method |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1563034A FR3045877B1 (fr) | 2015-12-22 | 2015-12-22 | Procede d'authentification |
| FR1563034 | 2015-12-22 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3045877A1 true FR3045877A1 (fr) | 2017-06-23 |
| FR3045877B1 FR3045877B1 (fr) | 2018-07-27 |
Family
ID=56068985
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1563034A Active FR3045877B1 (fr) | 2015-12-22 | 2015-12-22 | Procede d'authentification |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US10909530B2 (fr) |
| EP (1) | EP3394812A1 (fr) |
| CN (1) | CN108701304B (fr) |
| FR (1) | FR3045877B1 (fr) |
| WO (1) | WO2017109405A1 (fr) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111465968A (zh) * | 2017-12-12 | 2020-07-28 | 奥迪股份公司 | 用于对机动车进行授权的方法 |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11704632B2 (en) | 2020-12-17 | 2023-07-18 | Marqeta, Inc. | Computer transaction security with delegated decisions |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080110983A1 (en) * | 2006-11-15 | 2008-05-15 | Bank Of America Corporation | Method and apparatus for using at least a portion of a one-time password as a dynamic card verification value |
| EP1978479A1 (fr) * | 2007-04-06 | 2008-10-08 | Groupement Des Cartes Bancaires "Cb" | Cryptogramme dynamique |
| US20150327071A1 (en) * | 2014-05-07 | 2015-11-12 | Sanjeev Sharma | Enhanced data interface for contactless communications |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7740168B2 (en) * | 2003-08-18 | 2010-06-22 | Visa U.S.A. Inc. | Method and system for generating a dynamic verification value |
| US7761374B2 (en) * | 2003-08-18 | 2010-07-20 | Visa International Service Association | Method and system for generating a dynamic verification value |
| US8359630B2 (en) * | 2007-08-20 | 2013-01-22 | Visa U.S.A. Inc. | Method and system for implementing a dynamic verification value |
| US20100179909A1 (en) * | 2009-01-14 | 2010-07-15 | Jubin Dana | User defined udk |
| US9105027B2 (en) * | 2009-05-15 | 2015-08-11 | Visa International Service Association | Verification of portable consumer device for secure services |
| US10255601B2 (en) * | 2010-02-25 | 2019-04-09 | Visa International Service Association | Multifactor authentication using a directory server |
| EP2767110A4 (fr) * | 2011-10-12 | 2015-01-28 | C Sam Inc | Plateforme mobile d'activation de transaction sécurisée à plusieurs étages |
| WO2014186635A1 (fr) * | 2013-05-15 | 2014-11-20 | Visa International Service Association | Concentrateur de tokénisation pour mobile |
| CA2918788C (fr) * | 2013-07-24 | 2020-06-16 | Visa International Service Association | Systemes et procedes destines au traitement de jeton de reseau interoperable |
| US10496986B2 (en) * | 2013-08-08 | 2019-12-03 | Visa International Service Association | Multi-network tokenization processing |
| US10223694B2 (en) * | 2013-09-10 | 2019-03-05 | Visa International Service Association | Mobile payment application provisioning and personalization on a mobile device |
| US20150161612A1 (en) * | 2013-12-05 | 2015-06-11 | Mastercard International Incorporated | Method and system for network based dynamic cvc authentication |
| US20150371234A1 (en) * | 2014-02-21 | 2015-12-24 | Looppay, Inc. | Methods, devices, and systems for secure provisioning, transmission, and authentication of payment data |
| US10102529B2 (en) * | 2014-03-05 | 2018-10-16 | Mastercard International Incorporated | Method and system for secure consumer identification |
| US10360558B2 (en) * | 2015-03-17 | 2019-07-23 | Ca, Inc. | Simplified two factor authentication for mobile payments |
| EP3073429A1 (fr) * | 2015-03-26 | 2016-09-28 | Gemalto Sa | Procédé permettant de valider un code de sécurité dynamique dans une transaction bancaire |
-
2015
- 2015-12-22 FR FR1563034A patent/FR3045877B1/fr active Active
-
2016
- 2016-12-21 WO PCT/FR2016/053604 patent/WO2017109405A1/fr active Application Filing
- 2016-12-21 CN CN201680081572.4A patent/CN108701304B/zh active Active
- 2016-12-21 EP EP16829414.8A patent/EP3394812A1/fr not_active Withdrawn
- 2016-12-21 US US16/064,940 patent/US10909530B2/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080110983A1 (en) * | 2006-11-15 | 2008-05-15 | Bank Of America Corporation | Method and apparatus for using at least a portion of a one-time password as a dynamic card verification value |
| EP1978479A1 (fr) * | 2007-04-06 | 2008-10-08 | Groupement Des Cartes Bancaires "Cb" | Cryptogramme dynamique |
| US20150327071A1 (en) * | 2014-05-07 | 2015-11-12 | Sanjeev Sharma | Enhanced data interface for contactless communications |
Non-Patent Citations (1)
| Title |
|---|
| MARIANNE CROWE ET AL: "Is Payment Tokenization Ready for Primetime? Perspectives from Industry Stakeholders on the Tokenization Landscape", 11 June 2015 (2015-06-11), XP055307538, Retrieved from the Internet <URL:https://www.bostonfed.org/-/media/Documents/PaymentStrategies/tokenization-prime-time.pdf> [retrieved on 20161004] * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111465968A (zh) * | 2017-12-12 | 2020-07-28 | 奥迪股份公司 | 用于对机动车进行授权的方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| FR3045877B1 (fr) | 2018-07-27 |
| CN108701304B (zh) | 2021-09-03 |
| US10909530B2 (en) | 2021-02-02 |
| WO2017109405A1 (fr) | 2017-06-29 |
| CN108701304A (zh) | 2018-10-23 |
| EP3394812A1 (fr) | 2018-10-31 |
| US20190005490A1 (en) | 2019-01-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3113099B1 (fr) | Conteneur de paiement, procédé de création, procédé de traitement, dispositifs et programmes correspondants | |
| EP3455812B1 (fr) | Procédé de sécurisation d'un dispositif electronique, et dispositif electronique correspondant | |
| EP3446436B1 (fr) | Procédé d'obtention par un terminal mobile d'un jeton de sécurité | |
| WO2017203146A1 (fr) | Procede de securisation d'un dispositif electronique, et dispositif electronique correspondant | |
| WO2020064890A1 (fr) | Procede de traitement d'une transaction, dispositif, systeme et programme correspondant | |
| WO2017109405A1 (fr) | Procédé d'authentification | |
| EP3234848B1 (fr) | Procede d'envoi d'une information de securite et dispositif electronique apte a mettre en oeuvre un tel procede | |
| EP3588418A1 (fr) | Procédé de réalisation d'une transaction, terminal, serveur et programme d ordinateur correspondant | |
| FR3052895B1 (fr) | Procede d'envoi d'une information de securite | |
| FR3076014A1 (fr) | Controle d'integrite d'un dispositif electronique | |
| WO2020128240A1 (fr) | Traitement d'un service de tickets electroniques | |
| FR3061586A1 (fr) | Procede de controle d'habitudes d'utilisation et dispositif electronique apte a mettre en œuvre un tel procede | |
| EP3395042B1 (fr) | Serveur d'authentification pour le contrôle d'accès a un service | |
| EP3570238B1 (fr) | Procédé de réalisation d'une transaction, terminal, serveur et programme d'ordinateur correspondant | |
| FR3055761A1 (fr) | Procede de controle d'un dispositif electronique et dispositif electronique correspondant | |
| FR3044789A1 (fr) | Procede d'autorisation d'une transaction | |
| FR3076027A1 (fr) | Securisation du traitement d'une transaction | |
| WO2018011514A1 (fr) | Procédé de contrôle d'un dispositif électronique pour traiter une transaction | |
| FR3122010A1 (fr) | Gestion de la mémoire dans un dispositif de traitement de transactions | |
| WO2020148492A1 (fr) | Autorisation du chargement d'une application dans un élément de sécurité | |
| FR2857135A1 (fr) | Systeme de paiement electronique et procede correspondant | |
| FR2993424A1 (fr) | Procede de fourniture de donnees d'identification d'un utilisateur et procede d'identification d'un utilisateur | |
| FR2998398A1 (fr) | Procede d'activation d'un service en ligne a partir d'un equipement mobile |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20170623 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| CD | Change of name or company name |
Owner name: IDEMIA FRANCE, FR Effective date: 20180618 |
|
| CJ | Change in legal form |
Effective date: 20180618 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |
|
| PLFP | Fee payment |
Year of fee payment: 6 |
|
| PLFP | Fee payment |
Year of fee payment: 7 |
|
| PLFP | Fee payment |
Year of fee payment: 8 |
|
| PLFP | Fee payment |
Year of fee payment: 9 |