FR 3045877 A1 20170623 FR 1563034 A 20151222 1 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 « Primaly 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 Verification 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 3045877 2 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. 5 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é 10 A cet effet, la présente invention concerne un procédé d'authentification mis en oeuvre 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 ; 15 - 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. 20 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, 25 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. 30 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 DCVV 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 : 3045877 3 - 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. 5 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 10 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. 15 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. 20 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 25 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, 30 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 3045877 4 - 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, 5 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 oeuvre par un serveur d'accès à un service, comprenant : 10 - 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, 15 qu'aucune authentification selon le protocole 3DS ne doit être réalisée si la carte à puce est de type DCVV. 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 20 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. 25 Dans un mode particulier de réalisation, les différentes étapes du procédé d'authentification mis en oeuvre 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 oeuvre par le serveur d'accès comme défini ci-avant sont déterminées 30 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 oeuvre dans un serveur, ou plus généralement dans un ordinateur, ce programme 3045877 5 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 5 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. 10 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 disc) ou un disque dur. 15 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 20 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 25 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 lA 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 30 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 ; 3045877 6 la figure 3 représente schématiquement des modules mis en oeuvre dans le serveur d'accès représenté en figure lA 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 5 mode de réalisation particulier de l'invention ; la figure 5 représente schématiquement des modules mis en oeuvre 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 10 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 oeuvre 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 15 la figure 8 représente, sous la forme d'un diagramme, des étapes mises en oeuvre 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 20 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é 25 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 30 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 DCVV (ou carte DCW) une carte à puce apte à générer des codes dynamiques de sécurité DCW. Les codes DCW sont 3045877 7 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 5 transaction en cours à partir d'un code de sécurité dynamique DCW (pour « Dynamic Card Verification 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, 10 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 oeuvre 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 15 à 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 20 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 25 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 30 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é. 3045877 8 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 Directoty Server» en anglais) noté ici SDIR, un serveur de contrôle d'accès ACS (pour « Access control 5 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. 10 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 CVV 15 pour « Card Verification Value ») figurant sur la carte ou un code dynamique (DCW pour « Dynamic Card Verification 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 20 un réseau de communications R1 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 25 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 30 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. 3045877 9 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 5 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 10 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 15 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 20 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. 25 Dans l'exemple envisagé ici, la mémoire MR1 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 30 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. 3045877 10 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 5 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 10 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 15 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. 20 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 25 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. 30 Le processeur 20 piloté par le programme d'ordinateur PG2, met ici en oeuvre 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. 3045877 11 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 5 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 10 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 oeuvre étant envisageables dans le cadre de l'invention. 15 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 oeuvre un procédé de contrôle en exécutant le programme d'ordinateur PG1, et le serveur ACS met ici en oeuvre 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 20 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 oeuvre 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 25 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. 30 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. 3045877 12 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 5 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. 10 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 15 la requête d'authentification RQ2 au cours d'une étape de réception D10. Le serveur ACS détermine (D11) 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 (D11) 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 20 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 D11 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 25 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 30 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é. 3045877 13 Si, en revanche, il est déterminé en D11 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é 5 du code de sécurité CSC. Selon un mode de réalisation particulier, si le code de sécurité est de type DCW (D11), 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 10 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 15 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 à 20 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é DCVV é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 25 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 30 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é DCVV présent dans les données de transaction DT a été vérifié ou non avec succès. 3045877 14 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 5 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 10 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- 15 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 20 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, 25 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. 30 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é 3045877 15 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- 5 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 10 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 D11 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 15 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 20 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. 25 On comprendra au vu de ce qui précède que, selon la mise en oeuvre 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 DCVV 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, 30 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 3045877 16 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 5 en oeuvre 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 10 code de sécurité DCVV 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 oeuvre le mécanisme d'inhibition de l'authentification 3DS 15 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- 20 avant ne constituent que des exemples non limitatifs de mise en oeuvre 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. REVENDICATIONS1. Procédé d'authentification mis en oeuvre 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 (D11 ; 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. 20 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 25 - uniquement dans l'affirmative, le serveur d'authentification détermine (D11 ; 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 30 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 35 serveur d'authentification autorise (D12) la réalisation d'une authentification 3DS de ladite carte à puce. 3045877 18 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). 5 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 10 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), 15 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. 3045877 19 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) 5 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 10 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 15 provenance du serveur de contrôle, d'un message de vérification positive d'un code de sécurité DCVV 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 20 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 25 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 (MR1 ; MR2) lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur (PG1 ; PG2) comprenant des instructions pour 30 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 35 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 DCVV ; et 3045877 20 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 5 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 10 à 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 15 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.