WO2017109405A1 - Procédé d'authentification - Google Patents

Procédé d'authentification Download PDF

Info

Publication number
WO2017109405A1
WO2017109405A1 PCT/FR2016/053604 FR2016053604W WO2017109405A1 WO 2017109405 A1 WO2017109405 A1 WO 2017109405A1 FR 2016053604 W FR2016053604 W FR 2016053604W WO 2017109405 A1 WO2017109405 A1 WO 2017109405A1
Authority
WO
WIPO (PCT)
Prior art keywords
authentication
server
transaction data
dcw
security code
Prior art date
Application number
PCT/FR2016/053604
Other languages
English (en)
Inventor
Stéphane GIRODON
Original Assignee
Oberthur Technologies
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 filed Critical Oberthur Technologies
Priority to US16/064,940 priority Critical patent/US10909530B2/en
Priority to EP16829414.8A priority patent/EP3394812A1/fr
Priority to CN201680081572.4A priority patent/CN108701304B/zh
Publication of WO2017109405A1 publication Critical patent/WO2017109405A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/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

Definitions

  • the authentication method comprises sending, to the access server, a positive authentication message transaction data if the validity of the DCW code is verified successfully during said cooperation.
  • the authentication method is such that: the authentication server determines whether the smart card is of the DCW type from a PAN identifier included in the received transaction data; and
  • the authentication server prevents the realization of a 3DS authentication of said smart card.
  • programs mentioned in this presentation may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form , or in any other desirable form.
  • FIG. 6 represents an example of a table stored in a memory of the server ACS represented in FIGS. 1A and 4, according to a particular embodiment of the invention
  • the present invention relates to the authentication mechanisms and relates more particularly to an authentication from a security code of a smart card.
  • the invention implements, for example, an authentication server able to receive, from a service access server, an authentication request comprising transaction data associated with an authentication server. Smartcard ; determining whether a security code included in the transaction data is of the DCVV type; and if so, detecting that no 3DS authentication must be performed to authenticate said card and to cooperate with a verification server to check the validity of the security code DCW.
  • the user of the terminal T represented in FIG. 1A is here able to communicate, via an RI communications network such as the Internet for example, with an access server SW controlling access to the service S.
  • an access server SW controlling access to the service S.
  • the terminal T is able to send, to the access server SW, transaction data DT associated with the smart card C, for example to carry out a financial transaction (purchase %) with the service S.
  • the data of DT transactions include, for example, the PAN ID, the exp expiration date, and the CSC security code.
  • the server SW is for example a web server, walking or other type, able to manage the access of users to the web server S in question.
  • the service S can be any.
  • the service S is a marching service.
  • the processor 10 controlled by the computer program PG1 here implements a number of modules shown in FIG. 3, namely: a reception module M2, a transmission module M4 and a determination module M6.
  • the reception module M2 is able to receive the transaction data DT associated with the smart card C during a transaction with the access server SW.
  • the transmission module M4 is able to transmit the transaction data DT to the directory server 3DS SDIR to request authentication of the transaction according to the 3DS protocol.
  • the determination module M6 is able to determine, from a message received from the authentication server, that no authentication according to the 3DS protocol must be performed if the smart card is of the DCVV type.
  • the table TB comprises at least one correspondence between a PAN identifier and a DN data, said DN data indicating whether the bank card C associated with said PAN is DCW type.
  • the server ACS is able, from said data DN, to determine if the bank card C is of the DCVV type.
  • the server ACS can thus determine, from the table TB, whether the security code CSC included in the transaction data DT is of type DCVV. It is assumed here that the table TB identifies, for example, DN data in association with three identifiers PAN1, PAN2 and PAN3.
  • the access server SW implements a control method by executing the computer program PG1, and the server ACS. hereby implements an authentication method by executing the computer program PG2.
  • the transaction is a financial transaction, corresponding by example to a payment. It will be understood that other implementations are conceivable within the scope of the invention.
  • the SDIR server may optionally send a 3DS authentication refusal message to the access server SW.
  • the ACS server prevents the realization of a 3DS authentication of the bank card C.
  • the ACS server is configured to block performing a 3DS authentication for the transaction being authenticated.
  • the present invention is advantageous in that it makes it possible to dispense with the authentication mechanism according to the 3DS protocol when it is possible to authenticate the user of the transaction by verifying a dynamic security code DCW generated by the card. user's smart card (when said card is of DCW type).
  • the authentication according to the 3DS protocol has certain disadvantages, in particular in that it can cause discomfort for some users sometimes leading to the abandonment of the current transaction.
  • the invention makes it possible to inhibit the 3DS mechanism while maintaining a high level of security by verifying, where possible, a DCW code. Thanks to the invention, it is possible to facilitate the authentication of a user, and therefore access to a service.

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)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (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

Procédé d'authentification
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 qu'Internet 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 qu'il 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 DCVV.
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 DCVV.
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 œuvre 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 1A 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 1B 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 1A 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 1A 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 1A 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 DCVV (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 DCVV ; 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 DCVV. 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 1A 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 « 3DS Directory 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 1B.
Selon le mode de réalisation illustré en figure 1B, 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 1A 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. Les 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 DCVV.
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 DCVV. 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 CVV, 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 MR1 et une interface de communication INT1.
Dans l'exemple envisagé ici, la mémoire M RI 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 œuvre 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 DCVV.
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 DCVV. 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 DCVV. 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 M 26. 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 DCVV. 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 RQl. Dans un exemple particulier, la requête d'authentification RQl 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 (C10) 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 (C10) 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 terminal 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 DCVV. 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

REVENDICATIONS
1. 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, blocage (D13 ; C51) de la réalisation d'une authentification 3DS de ladite carte à puce 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é 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.
5. Procédé selon l'une quelconque des revendications 1 à 4, 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). Procédé selon la revendication 5, 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 DCVV, 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 DCVV.
7. Procédé selon l'une quelconque des revendications 1 à 6, 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.
8. Procédé selon l'une quelconque des revendications 1 à 6, 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.
9. Procédé selon l'une quelconque des revendications 1 à 8, 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.
10. Procédé de contrôle mis en œuvre 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.
11. Procédé selon la revendication 10, 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.
12. Procédé selon la revendication 10 ou 11, 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.
13. 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 à 12 lorsque ledit programme est exécuté par un ordinateur.
14. Support d'enregistrement (MR1 ; 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 à 12.
15. 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 bloquer la réalisation d'une authentification 3DS de ladite carte à puce ; 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.
16. 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.
PCT/FR2016/053604 2015-12-22 2016-12-21 Procédé d'authentification WO2017109405A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US16/064,940 US10909530B2 (en) 2015-12-22 2016-12-21 Authentication method
EP16829414.8A EP3394812A1 (fr) 2015-12-22 2016-12-21 Procédé d'authentification
CN201680081572.4A CN108701304B (zh) 2015-12-22 2016-12-21 认证方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1563034 2015-12-22
FR1563034A FR3045877B1 (fr) 2015-12-22 2015-12-22 Procede d'authentification

Publications (1)

Publication Number Publication Date
WO2017109405A1 true WO2017109405A1 (fr) 2017-06-29

Family

ID=56068985

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2016/053604 WO2017109405A1 (fr) 2015-12-22 2016-12-21 Procédé 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)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102017222434A1 (de) * 2017-12-12 2019-06-13 Audi Ag Verfahren zur Authentifizierung eines Kraftfahrzeugs
US11704632B2 (en) * 2020-12-17 2023-07-18 Marqeta, Inc. Computer transaction security with delegated decisions

Citations (3)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7761374B2 (en) * 2003-08-18 2010-07-20 Visa International Service Association Method and system for generating a dynamic verification value
US7740168B2 (en) * 2003-08-18 2010-06-22 Visa U.S.A. Inc. 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
IN2014KN00998A (fr) * 2011-10-12 2015-09-04 C Sam Inc
US9978062B2 (en) * 2013-05-15 2018-05-22 Visa International Service Association Mobile tokenization hub
SG10201800626RA (en) * 2013-07-24 2018-02-27 Visa Int Service Ass Systems and methods for interoperable network token processing
US10496986B2 (en) * 2013-08-08 2019-12-03 Visa International Service Association Multi-network tokenization processing
WO2015038551A1 (fr) * 2013-09-10 2015-03-19 Visa International Service Association Mise en service et personnalisation d'applications de paiement mobile sur un dispositif mobile
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

Patent Citations (3)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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] *

Also Published As

Publication number Publication date
US20190005490A1 (en) 2019-01-03
CN108701304B (zh) 2021-09-03
US10909530B2 (en) 2021-02-02
FR3045877A1 (fr) 2017-06-23
CN108701304A (zh) 2018-10-23
FR3045877B1 (fr) 2018-07-27
EP3394812A1 (fr) 2018-10-31

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&#39;un dispositif electronique, et dispositif electronique correspondant
EP3446436B1 (fr) Procédé d&#39;obtention par un terminal mobile d&#39;un jeton de sécurité
WO2016034810A1 (fr) Gestion de ticket électronique
WO2020064890A1 (fr) Procede de traitement d&#39;une transaction, dispositif, systeme et programme correspondant
WO2017203146A1 (fr) Procede de securisation d&#39;un dispositif electronique, et dispositif electronique correspondant
EP3394812A1 (fr) Procédé d&#39;authentification
WO2001086601A1 (fr) Procede pour authentifier un objet portatif, objet portatif correspondant, et appareil pour mettre en oeuvre le procede
EP3234848B1 (fr) Procede d&#39;envoi d&#39;une information de securite et dispositif electronique apte a mettre en oeuvre un tel procede
EP3588418A1 (fr) Procédé de réalisation d&#39;une transaction, terminal, serveur et programme d ordinateur correspondant
WO2020128240A1 (fr) Traitement d&#39;un service de tickets electroniques
FR3061586A1 (fr) Procede de controle d&#39;habitudes d&#39;utilisation et dispositif electronique apte a mettre en œuvre un tel procede
FR3052895A1 (fr) Procede d&#39;envoi d&#39;une information de securite
EP3395042B1 (fr) Serveur d&#39;authentification pour le contrôle d&#39;accès a un service
EP3570238B1 (fr) Procédé de réalisation d&#39;une transaction, terminal, serveur et programme d&#39;ordinateur correspondant
FR3055761A1 (fr) Procede de controle d&#39;un dispositif electronique et dispositif electronique correspondant
WO2008053095A1 (fr) Entite electronique portable et procede de blocage, a distance, d&#39;une fonctionnalite d&#39;une telle entite electronique portable
WO2017005644A1 (fr) Procédé et système de contrôle d&#39;accès à un service via un média mobile sans intermediaire de confiance
WO2018011514A1 (fr) Procédé de contrôle d&#39;un dispositif électronique pour traiter une transaction
WO2020148492A1 (fr) Autorisation du chargement d&#39;une application dans un élément de sécurité
FR3076027A1 (fr) Securisation du traitement d&#39;une transaction
FR2857135A1 (fr) Systeme de paiement electronique et procede correspondant
FR2998398A1 (fr) Procede d&#39;activation d&#39;un service en ligne a partir d&#39;un equipement mobile

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16829414

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2016829414

Country of ref document: EP