Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
SERVER AND METHOD FOR VERIFYING SECURITY CODE
Document Type and Number:
WIPO Patent Application WO/2017/001757
Kind Code:
A1
Abstract:
This server (5000) for verifying security code comprises: - a communication module (5200) able to receive transaction data comprising an identifier and a security code associated with a device associated with this identifier so as to carry out a transaction; - a control module able to determine whether said security code should be verified by comparing it with a dynamic security code or with a static security code; - a module (5300) configured to generate, under the first hypothesis, a dynamic security code on the basis of the identifier and of a temporal datum or of a counter of the number of second dynamic security codes generated by this module for this identifier; - a comparison module (5400) configured to compare the security code either with the dynamic security code or with a static security code associated with this identifier and stored by the server; - said server being configured to allow or disallow directly or indirectly the carrying out of the transaction as a function of the result of this comparison.

Inventors:
GIRODON STÉPHANE (FR)
Application Number:
PCT/FR2016/051587
Publication Date:
January 05, 2017
Filing Date:
June 28, 2016
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
OBERTHUR TECHNOLOGIES (FR)
International Classes:
G06Q20/36; G06Q20/34
Foreign References:
US20080110983A12008-05-15
US20060278698A12006-12-14
Attorney, Agent or Firm:
DELUMEAU, François et al. (FR)
Download PDF:
Claims:
REVENDICATIONS

1. Serveur (5000) de vérification de code de sécurité comporte : - un module (5200) de communication apte à recevoir des données de transaction (DT) comportant un identifiant (PAN) et un code de sécurité (CW, DCCVi) associé à un dispositif (1000) associé à cet identifiant pour réaliser une transaction ;

- un module de contrôle apte à déterminer si ledit code de sécurité doit être vérifié en le comparant à un code dynamique de sécurité (DCCV2) ou à un code statique de sécurité (CW) ;

- un module (5300) configuré pour générer, dans la première hypothèse un code dynamique de sécurité (DCCV2) à partir dudit identifiant (PAN) et d'une donnée temporelle ou d'un compteur du nombre de deuxièmes codes dynamiques de sécurité (DCCV2) générés par ledit module (5300) pour ledit identifiant (PAN) ;

- un module (5400) de comparaison configuré pour comparer le code de sécurité soit avec ledit code dynamique de sécurité (DCCV2) soit avec un code statique de sécurité associé avec ledit identifiant (PAN) et mémorisé par ledit serveur ;

- ledit serveur (5000) étant configuré pour permettre ou interdire directement ou indirectement la réalisation de ladite transaction en fonction du résultat de ladite comparaison. 2. Serveur (5000) de vérification de code de sécurité selon la revendication 1 caractérisé en ce qu'il comporte en outre :

- un module (5800) apte à générer à l'aide d'un algorithme cryptographique, le code statique de sécurité (CW) associé audit identifiant (PAN) en utilisant une clef secrète.

3. Serveur (5000) de vérification de code de sécurité selon la revendication 1 ou 2, configuré pour vérifier une condition d'utilisation (TL) dudit code statique de sécurité (CW) avant de le comparer avec ledit code de sécurité, ladite condition d'utilisation pouvant notamment être constituée par :

- une date limite d'utilisation dudit code statique de sécurité (CW) ; - la non réception d'un message prédéterminé ; ou

- le fait que ledit code statique de sécurité (CW) n'a pas été utilisé pour un nombre ou un montant cumulé de transactions. 4. Serveur (5000) de vérification de code de sécurité selon l'une quelconque des revendications 1 à 3, dans lequel ledit code de sécurité doit par défaut être vérifié en le comparant audit code dynamique de sécurité (DCCV2). 5. Système de vérification d'un code de sécurité comportant :

- un serveur (5000) de vérification de code de sécurité selon l'une quelconque des revendications 1 à 5 ; et

- un serveur (7000) de gestion de la sécurisation configuré pour envoyer audit serveur (5000) de vérification de code de sécurité un message indiquant, pour un identifiant donné, si ledit code de sécurité doit être vérifié en le comparant à un code dynamique de sécurité (DCCV2) ou à un code statique de sécurité (CW).

6. Système de vérification d'un code de sécurité selon la revendication 5, dans lequel ledit serveur (7000) de gestion de la sécurisation est apte à envoyer ledit code statique de sécurité (CW) et/ou ladite condition d'utilisation (TL) audit serveur (5000) de vérification de code de sécurité.

7. Système de vérification d'un code de sécurité selon la revendication 6, dans lequel ledit serveur (7000) de gestion de la sécurisation est apte à envoyer un code statique de sécurité (CW*) à durée de vie limitée.

8. Système selon l'une quelconque des revendications 5 à 7 dans lequel ledit serveur (5000) de vérification de code de sécurité est configuré pour déterminer ladite condition d'utilisation (TL) à partir de la date de réception dudit message.

9. Système selon l'une quelconque des revendications 5 à 8 caractérisé en ce qu'il comporte : - une carte à microcircuit (1000) comportant, un code statique de sécurité (CW) et un écran (1400) pour afficher un code dynamique de sécurité (DCCVi) généré par ladite carte pour réaliser une transaction ;

- ledit serveur (5000) de vérification de code dynamique de sécurité étant apte à vérifier la validité du code statique de sécurité de ladite carte et celle dudit code dynamique de sécurité (DCCVi) généré par ladite carte.

10. Système selon la revendication 9 caractérisé en ce qu'il comporte :

- un terminal (2000) permettant à un utilisateur de se connecter à un serveur (3000) pour réaliser ladite transaction, ledit terminal (2000) comportant une interface homme-machine permettant audit utilisateur de saisir les données de ladite transaction dont ledit code dynamique de sécurité (DCCVi) généré par ladite carte pour cette transaction ;

- ledit serveur (3000) pour réaliser la transaction étant apte à transmettre lesdites données de transaction audit serveur (5000) de vérification de code dynamique de sécurité selon le protocole ISO 8583 et à recevoir selon ce protocole un message d'autorisation de ladite transaction en provenance de ce serveur (5000).

11. Procédé de vérification de code de sécurité comportant :

- une étape (E20) de réception de données de transaction (DT) comportant un identifiant (PAN) et un code de sécurité (CW, DCCVi) associé à un dispositif (1000) associé à cet identifiant pour réaliser une transaction ;

- une étape (G40) de contrôle pour déterminer si ledit code de sécurité doit être vérifié en le comparant à un code dynamique de sécurité (DCCV2) ou à un code statique de sécurité (CW) ;

- une étape pour générer, dans la première hypothèse un code dynamique de sécurité (DCCV2) à partir dudit identifiant (PAN) et d'une donnée temporelle ou d'un compteur du nombre de deuxièmes codes dynamiques de sécurité (DCCV2) générés par ledit module (5300) pour ledit identifiant (PAN) ;

- une étape de comparaison dudit code de sécurité soit avec ledit code dynamique de sécurité (DCCV2) soit avec un code statique de sécurité associé avec ledit identifiant (PAN); - la réalisation de ladite transaction étant permise ou interdite en fonction du résultat de ladite comparaison.

12. Programme d'ordinateur comportant des instructions pour mettre en œuvre les étapes d'un procédé de vérification de code dynamique de sécurité selon la revendication 11 lorsque ce programme est exécuté par un ordinateur.

13. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de vérification de code dynamique de sécurité selon la revendication 11.

Description:
Serveur et procédé de vérification de code de sécurité

Arrière-plan de l'invention

La présente invention se situe dans le domaine des mécanismes de vérification des codes de sécurité.

L'invention peut en particulier être utilisée pour vérifier des codes de sécurité tels que numéros de documents d'identité, des identifiants de sécurité sociale, des codes d'ouverture de porte, ou des codes d'accès à un site Web.

L'invention trouve en outre une application privilégiée pour vérifier des codes de sécurité utilisés dans des transactions bancaires, par exemple des applications de paiement en ligne.

On connaît en particulier dans le domaine des transactions bancaires, des cartes à microcircuit associées à des comptes bancaires, les opérations et transactions en ligne effectuées au moyen d'une telle carte étant sécurisées en utilisant un code de sécurité associé à la carte.

Le plus souvent, ces codes de sécurité sont dit statiques, ce qui signifie qu'ils sont constants dans le temps, autrement dit que leur valeur reste identique pendant toute la durée de vie de la carte.

Un problème connu avec ces cartes bancaires est qu'il est relativement aisé de dérober le code de sécurité statique, notamment lorsque celui-ci est imprimé sur la carte bancaire.

Le document [REFAA] propose une solution pour sécuriser des transactions en ligne au moyen d'une carte bancaire, dans laquelle le code de sécurité affiché sur la carte et saisi par l'utilisateur pour effectuer une transaction est un code de sécurité dynamique, le système de traitement informatique du service financier de transactions en ligne étant apte à vérifier la validité de ce code de sécurité dynamique en fonction d'un paramètre temporel pour valider ou non la transaction.

Malheureusement, la solution proposée interdit toute transaction avec la carte à microcircuit si celle-ci n'est pas en mesure de générer ou de présenter le code de sécurité dynamique, par exemple si l'afficheur de la carte à microcircuit est hors d'usage ou si la batterie de la carte est insuffisamment chargée.

L'invention propose une solution pour vérifier un code de sécurité qui ne présente pas cet inconvénient.

Objet et résumé de l'invention

Plus précisément, et selon un premier aspect, l'invention concerne un serveur de vérification de code de sécurité comportant :

- un module de communication apte à recevoir des données de transaction comportant un identifiant et un code de sécurité associé à un dispositif associé à cet identifiant pour réaliser une transaction ;

- un module de contrôle apte à déterminer si ce code de sécurité doit être vérifié en le comparant à un code dynamique de sécurité ou à un code statique de sécurité ;

- un module configuré pour générer, dans la première hypothèse un code dynamique de sécurité à partir de l'identifiant et d'une donnée temporelle ou d'un compteur du nombre de deuxièmes codes dynamiques de sécurité générés par ledit module pour ledit identifiant;

- un module de comparaison configuré pour comparer le code de sécurité soit avec ledit code dynamique de sécurité soit avec un code statique de sécurité associé avec ledit identifiant et mémorisé par ledit serveur ;

- ledit serveur étant configuré pour permettre ou interdire directement ou indirectement la réalisation de ladite transaction en fonction du résultat de ladite comparaison.

Corrélativement, l'invention concerne un procédé de vérification de code de sécurité comportant :

- une étape de réception de données de transaction comportant un identifiant et un code de sécurité associé à un dispositif associé à cet identifiant pour réaliser une transaction ;

- une étape de contrôle pour déterminer si ledit code de sécurité doit être vérifié en le comparant à un code dynamique de sécurité ou à un code statique de sécurité ;

- une étape pour générer, dans la première hypothèse un code dynamique de sécurité à partir de l'identifiant et d'une donnée temporelle ou d'un compteur du nombre de deuxièmes codes dynamiques de sécurité générés par ledit module pour cet identifiant ;

- une étape de comparaison dudit code de sécurité soit avec ledit code dynamique de sécurité soit avec un code statique de sécurité associé avec cet identifiant ;

- la réalisation de ladite transaction étant permise ou interdite en fonction du résultat de cette comparaison.

Ainsi, et d'une façon générale, l'invention propose un serveur (et le procédé associé) configuré pour autoriser une transaction par un dispositif si les données de transaction comportent un code dynamique de sécurité compatible avec le moment de la transaction ou, dans certaines circonstances, un code statique de sécurité correspondant à ce dispositif.

Pour des raisons de sécurité, il est important de contrôler une condition d'utilisation du code statique de sécurité et lorsque cette condition n'est pas remplie, de comparer le code de sécurité reçu dans les données de transaction avec un code dynamique de sécurité généré pour cette transaction par le serveur selon l'invention.

Dans un mode préféré de réalisation, le serveur selon l'invention mémorise la condition d'utilisation du code statique de sécurité dans une table. Par exemple cette condition peut être remplie tant que :

- une date limite d'utilisation du code statique de sécurité n'a pas expirée ; ou

- tant que le serveur selon l'invention n'a pas reçu un message prédéterminé lui indiquant de ne plus autoriser la transaction sur la base de la vérification du code statique de sécurité ; ou

- tant que let code statique de sécurité n'a pas été utilisé pour un nombre ou un montant cumulé prédéterminé de transactions.

Dans un mode particulier de réalisation de l'invention, le serveur de vérification de code de sécurité selon l'invention comporte un module apte à générer à l'aide d'un algorithme cryptographique, le code statique de sécurité associé audit identifiant en utilisant une clef secrète.

Lorsque le code statique de sécurité est celui d'une carte bancaire, l'algorithme prend aussi en compte la date d'expiration de cette carte.

Dans un mode particulier de réalisation de l'invention, le serveur de vérification de code dynamique de sécurité comporte en outre un module de communication apte à envoyer à un serveur, et ce uniquement en cas d'égalité du code de sécurité et dudit deuxième code dynamique de sécurité, lesdites données de transaction dans lesquelles ledit code de sécurité est remplacé par le code statique de sécurité associé au dispositif, ce serveur étant configuré pour vérifier la validité du code statique de sécurité pour autoriser ou refuser la transaction.

Ainsi, dans ce mode de réalisation, l'invention propose de vérifier la validité du code dynamique de sécurité pour la transaction en amont du serveur configuré pour autoriser ou refuser la transaction, et lorsque la validité du code dynamique est vérifiée de substituer ce code dynamique de sécurité par un code statique de sécurité pour que celui-ci soit vérifié par ce serveur.

Le serveur configuré pour autoriser ou refuser la transaction n'a donc pas besoin d'être modifié pour être en mesure de vérifier les codes dynamiques de sécurité.

En particulier, lorsque l'invention est utilisée dans le domaine bancaire, les serveurs bancaires n'ont pas à être modifiés, la vérification du code dynamique de sécurité s'effectuant en amont dans le réseau.

Cette solution est très avantageuse car elle ne nécessite aucune autre modification dans la chaîne de transaction, puisqu'in fine, l'autorisation ou le refus de la transaction reste sous la responsabilité du serveur en fin de chaîne, le serveur bancaire par exemple.

Dans un mode particulier de réalisation, le serveur de vérification de code de sécurité conforme à l'invention est configuré pour envoyer un message de refus de la transaction à un serveur apte à réaliser la transaction si les premier et deuxième codes dynamiques sont différents.

Ainsi, dans ce mode de réalisation, le serveur configuré pour vérifier la validité du code statique de sécurité pour autoriser ou refuser la transaction, le serveur bancaire par exemple, n'est pas sollicité.

L'invention vise aussi un système de vérification d'un code de sécurité comportant :

- un serveur de vérification de code de sécurité tel que mentionné ci-dessus; et

- un serveur de gestion de la sécurisation configuré pour envoyer au serveur de vérification de code de sécurité un message indiquant, pour un identifiant donné, si ledit code de sécurité doit être vérifié en le comparant à un code dynamique de sécurité ou à un code statique de sécurité.

Dans un mode particulier de réalisation, le serveur de gestion de la sécurisation est apte à envoyer le code statique de sécurité et/ou ladite condition d'utilisation au serveur de vérification de code de sécurité.

Ce mode de réalisation est avantageux lorsque le serveur de vérification de code de sécurité selon l'invention n'a pas de module apte à générer le code statique de sécurité associé à un dispositif, par exemple quand il ne possède pas la clef secrète nécessaire à l'algorithme cryptographique.

Dans un mode particulier de réalisation de l'invention, le serveur de vérification de code de sécurité est configuré pour déterminer la condition d'utilisation à partir de la date de réception de ce message.

Dans un mode particulier de réalisation, le système selon l'invention comporte :

- une carte à microcircuit comportant, un code statique de sécurité et un écran pour afficher un code dynamique de sécurité généré par ladite carte pour réaliser une transaction ;

- le serveur de vérification de code dynamique de sécurité selon l'invention étant apte à vérifier la validité du code statique de sécurité de ladite carte et celle du code dynamique de sécurité généré par ladite carte.

Dans un mode de réalisation, ce système comporte:

- un terminal permettant à un utilisateur de se connecter à un serveur pour réaliser la transaction, ce terminal comportant une interface homme-machine permettant à l'utilisateur de saisir les données de la transaction dont ledit code dynamique de sécurité généré par la carte pour cette transaction ;

- le serveur pour réaliser la transaction étant apte à transmettre ces données de transaction au serveur de vérification de code dynamique de sécurité selon le protocole ISO 8583 et à recevoir selon ce protocole un message d'autorisation de ladite transaction en provenance de ce serveur.

Dans un mode particulier de réalisation, les différentes étapes du procédé de vérification d'un code dynamique de sécurité selon le premier aspect ou le deuxième aspect de l'invention sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œ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 d'un procédé de vérification d'un code dynamique de sécurité tel que décrit ci-dessus.

Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de codes source, codes objet, ou de codes intermédiaires entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.

L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.

Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, RAM, PROM, EPROM,

CD ROM, DVD ou un disque dur.

D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.

Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.

Brève description des dessins

Des caractéristiques et avantages particuliers de la présente invention ressortiront de la description détaillée faite aux figures dans lesquelles :

- la figure 1 représente un dispositif permettant d'effectuer des transactions, en l'espèce une carte à microcircuit ;

- la figure 2 représente un premier système de vérification de code de sécurité conforme à mode de réalisation de l'invention ; - la figure 3 représente sous forme d'organigramme les principales étapes d'un procédé de vérification de code de dynamique de sécurité conforme à mode de réalisation de l'invention ;

- la figure 4 représente un deuxième système de vérification de code de sécurité conforme à mode de réalisation de l'invention ;

- la figure 5 représente sous forme d'organigramme des étapes mises en œuvre par un module d'interface du système de la figure 4 ;

- les figures 6 et 7 représentent le système de vérification de code de sécurité de la figure 4 selon deux architectures alternatives ;

- la figure 8 représente sous forme d'organigramme les principales étapes d'un procédé de vérification de code de dynamique de sécurité conforme à autre mode de réalisation de l'invention ;

- la figure 9 représente une table pouvant être utilisée par un serveur de vérification de code dynamique de sécurité ;

- la figure 10 représente sous forme d'organigramme des étapes mises en œuvre par un serveur de vérification de code dynamique de sécurité qui utilise la table de la figure 9 ;

- la figure 11 représente une autre table pouvant être utilisée par un serveur de vérification de code dynamique de sécurité.

Description détaillée d'un premier mode de réalisation de l'invention

Ce mode de réalisation est décrit dans le contexte particulier d'une application financière, plus précisément d'une application de paiement en ligne.

La figure 1 représente un dispositif 1000 permettant d'effectuer des transactions en ligne.

Dans les modes de réalisation décrits ci-après, le dispositif 1000 est une carte à microcircuit (en anglais smartcard) de paiement. En variante, le dispositif 1000 peut être constitué par un terminal, par exemple de téléphonie mobile, mettant en œuvre une application permettant de réaliser des transactions.

Dans le mode de réalisation décrit ici, la carte à microcircuit 1000 est conforme à la norme IS07816. Elle comporte en particulier une interface à contacts 1300. La carte à microcircuit 1000 est par exemple au format ID-1 (dimensions : 85,60 x53,98 mm) et d'épaisseur 0.76 mm environ. Elle est par exemple en matière plastique.

De façon connue, le nom NOM du titulaire de la carte à microcircuit, un numéro de compte bancaire PAN (par exemple à 16 chiffres), une date d'expiration EXP sont imprimés et/ou embossés sur la carte à microcircuit 1000. La carte comporte en outre un code statique de sécurité CW, celui- ci pouvant être ou ne pas être imprimé sur la carte. Pour plus de renseignements sur :

- le code statique de sécurité CW, l'homme du métier peut consulter le document [REFCW] ;

- le numéro de compte bancaire PAN, l'homme du métier peut consulter le document [REFPAN].

Cette carte à microcircuit 1000 comporte un contrôleur 1200 comportant un module apte à fournir la date courante, par exemple une horloge CLK, ce contrôleur 1200 étant apte à calculer un code dynamique de sécurité DCCVi en appliquant une fonction cryptographique secrète à des paramètres comportant le numéro de compte bancaire PAN et un paramètre temporel.

Dans le mode de réalisation décrit ici, le code dynamique de sécurité DCCVi est varié de façon périodique, selon une période prédéterminée.

Au contraire, le code statique de sécurité CW est constant dans le temps.

La carte à microcircuit 1000 comporte un écran 1100 d'affichage de ce code dynamique de sécurité DCCVi. Cet écran peut comporter par exemple 3 ou 4 zones élémentaires selon la taille de ce code dynamique.

Dans le mode de réalisation décrit ici, la carte à microcircuit 1000 comporte en outre une batterie non représentée et un bouton poussoir 1400 pour allumer ou éteindre l'écran d'affichage 1100 et donc le code dynamique de sécurité DCCVi. Ce bouton-poussoir ou tout moyen équivalent (bouton capacitif, ...) pour allumer ou éteindre l'écran 1100 est optionnel. L'écran d'affichage 1100 peut se trouver sur la face de la carte à microcircuit 1000 opposée à celle où sont imprimés et/ou embossés le numéro de carte bancaire PAN et la date d'expiration EXP. En variante, ils sont sur la même face. La figure 2 représente un terminal utilisateur 2000 muni d'une interface homme-machine HMI, par exemple un ordinateur personnel, un téléphone intelligent (en anglais smartphone) ou une tablette, un serveur 3000 d'un site Web marchand, le système bancaire 6000 de l'entité émettrice de la carte à microcircuit 1000, et un dispositif 5000 de vérification de code dynamique de sécurité conforme à l'invention.

Dans le mode de réalisation décrit ici, le terminal 2000 accède au site Web marchand 3000 par le réseau Internet ; le site Web marchand 3000, le système bancaire 6000 et le dispositif 5000 de vérification communiquent via un réseau interbancaire 4000.

Le système bancaire 6000 comporte un module 6100 d'authentification et d'autorisation des transactions bancaires.

D'une façon générale, le dispositif 5000 de vérification de code dynamique de sécurité vise à sécuriser le code statique de sécurité CW de la carte à microcircuit 1000.

Dans le mode de réalisation décrit ici, le serveur 5000 de vérification de code dynamique de sécurité comporte :

- un module 5100 apte à obtenir la date courante, soit en utilisant des moyens internes, soit par exemple à partir d'un autre équipement ou d'un autre réseau, par des moyens de communications sans fil ou filaires ;

- un module 5200 de communication apte à recevoir des données de transaction bancaires DT comportant, le numéro de compte bancaire PAN, la date d'expiration EXP de la carte et un code de sécurité pour une transaction ;

- un module 5800 apte à recevoir le code statique de sécurité CW de cette carte 1000 ou à générer ce code statique CW en utilisant le numéro de compte bancaire PAN de la carte, sa date d'expiration EXP et une clef secrète à l'aide d'un algorithme cryptographique ;

- un module 5300 de contrôle apte à déterminer si le code de sécurité compris dans les données de transaction reçues par le module

5200 doit être vérifié en le comparant à ce code statique de sécurité CW ou à un code dynamique de sécurité DCCV 2 généré par le module 5300 pour cette transaction en utilisant le numéro de compte bancaire PAN, une fonction cryptographique secrète et une donnée temporelle ;

- un module (5400) de comparaison configuré pour comparer le code de sécurité compris dans les données de transaction bancaires soit avec le code dynamique de sécurité DCCV 2 soit avec le code statique de sécurité CW, le serveur 5000 étant configuré pour permettre ou interdire directement ou indirectement la réalisation de ladite transaction en fonction du résultat de ladite comparaison.

Dans le mode de réalisation décrit ici, lorsque la comparaison se fait sur la base du code dynamique de sécurité, et lorsque le serveur 5000 détermine que le code de sécurité compris dans les données de transaction correspond au code dynamique DCCV 2 , calculé par le serveur 5000 pour cette transaction, il envoie, au serveur bancaire 6000, les données de transaction reçues du serveur 3000 en remplaçant le code de sécurité de ces données par lé code statique de sécurité CW obtenu par le module 5800.

De façon connue, le serveur bancaire 6000 comporte un module 6100 d'authentification et de sécurisation des transactions apte à vérifier le code statique de sécurité CW pour autoriser ou refuser la transaction. Il est fondamental de noter que cette vérification utilise le code statique de sécurité CW de sorte que le serveur bancaire 6000 n'a pas besoin de mettre en œuvre les fonctions de calcul du deuxième code dynamique de sécurité DCCV 2 .

Dans le mode de réalisation décrit ici, et comme représenté à la figure 9, le serveur 5000 gère une table 5600 dans laquelle il mémorise, pour chaque numéro de compte bancaire PAN, un mode de vérification « S/D » indiquant si la vérification d'une transaction doit porter sur le code statique de sécurité CW (mode « S ») ou sur le code dynamique de sécurité DCWi (mode « D »). Le serveur 5000 mémorise dans cette table 5600, le code dynamique de sécurité CW au moins pour les cartes à microcircuits 1000 pour lesquelles le mode de vérification est le mode statique « S ».

Le mode de vérification S/D peut être modifié par le serveur 5000 sur réception d'un message en provenance d'un serveur 7000 de gestion de la sécurisation représenté à la figure 2.

Dans le mode de réalisation décrit ici, le détenteur de la carte à microcircuit 1000 peut contacter le serveur 7000 de gestion de la sécurisation pour lui demander que la vérification de ses transactions, par défaut réalisée en utilisant le code dynamique de sécurité DCCVi, utilise au moins pendant un certain temps, le code statique de sécurité CW. L'utilisateur peut faire une telle demande en particulier lorsque l'afficheur 1100 de la carte à microcircuit 1000 est hors d'usage ou lorsque la batterie de cette carte est insuffisamment chargée.

On notera que dans de telles circonstances, l'utilisateur peut également demander au serveur 7000 de générer un code statique de sécurité CW * à durée de vie limitée comme décrit ultérieurement en référence au sixième mode de réalisation de l'invention.

Dans le mode particulier de réalisation décrit ici, le serveur 7000 de gestion de la sécurisation possède des moyens pour authentifier l'utilisateur pour prendre en compte le changement de mode de vérification et le transmettre au serveur 5000 de vérification de code dynamique. Ces moyens d'authentification peuvent notamment utiliser un mot de passe, un mécanisme de défi ou des fonctions cryptographiques.

Dans un mode particulier de réalisation, l'utilisateur peut, après authentification, communiquer son code statique de sécurité CW au serveur 7000 pour que celui-ci le transmette au serveur 5000 de vérification de code dynamique de sécurité.

Dans le mode particulier de réalisation décrit ici, le mode de vérification est par défaut le mode de vérification « D » basé sur le code dynamique de sécurité DCCVi et le basculement dans le mode de vérification statique n'est que temporaire.

A cet effet, dans le mode de réalisation décrit ici, la table 5600 comporte une colonne « TL » dans laquelle le serveur 5000 de vérification de code dynamique mémorise un critère permettant de déterminer si la vérification du code statique CW est toujours autorisée.

Ce critère peut par exemple être une date limite fournie au serveur 5000 par le serveur 7000 de gestion de la sécurisation ; une telle date peut aussi être calculée par le serveur 5000 à partir de la date de réception du message en provenance de ce serveur 7000.

En variante, le serveur 5000 de vérification de code dynamique de sécurité peut réaliser des vérifications basées sur le code statique de sécurité CW :

- jusqu'à recevoir un message prédéterminé du serveur 7000 de gestion de la sécurisation ; ou

- tant qu'un nombre prédéterminé de transactions n'a pas été dépassé ; ou - tant qu'un montant cumulé total de transactions n'a pas été atteint.

La figure 10 représente sous forme d'organigramme un procédé mis en œuvre par le serveur 5000 de vérification de code dynamique de sécurité dans ce mode de réalisation.

Au cours d'une étape G10, le serveur 5000 initialise le mode de vérification au mode dynamique « D » pour tous les comptes bancaires PAN.

Si le serveur 5000 reçoit (étape G20) un message MSG du serveur 7000 pour un compte PAN, il bascule le mode de vérification au mode statique.

Dans cet exemple le code statique de sécurité CW pour ce compte PAN est communiqué au serveur 5000 dans le message MSG.

En variante, le serveur 5000 calcule le code statique de sécurité CW comme décrit précédemment en utilisant son module 5800 en utilisant le numéro de compte bancaire PAN de la carte, sa date d'expiration EXP et une clef secrète à l'aide d'un algorithme cryptographique.

La table 5600 est mise à jour avec le code statique de sécurité reçu du serveur 7000 ou calculé par le serveur 5000 et avec le critère TL permettant de déterminer si la vérification basée sur le code statique est autorisée.

Comme mentionné précédemment ce critère peut être constitué par une durée reçue du serveur 7000 ou lié à la réception d'un message du serveur 7000 pour rebasculer dans le mode dynamique « D », un montant total cumulé ou nombre maximum de transactions autorisées.

Si au cours d'une étape G30, le serveur 5000 est sollicité pour vérifier une transaction pour un compte bancaire PAN, il vérifie dans la table 5600 (étape G40), si le mode de vérification pour ce compte PAN est le mode statique « S » et le critère TL pour réaliser des vérifications sur la base du code statique de sécurité CW est vérifié.

Si ces deux conditions sont réunies, le serveur 5000 de vérification de code dynamique de sécurité vérifie la transaction sur la base du code statique de sécurité CW mémorisé dans la table 5600 (étape G50).

Sinon, le serveur 5000 calcule un code dynamique de sécurité

DCCV 2 et vérifie la transaction sur la base de ce code dynamique de sécurité (étape G60). En cas de succès, et selon le mode de réalisation de l'invention, le serveur 5000 :

- envoie directement un message au serveur 3000 du site marchand pour valider la transaction ; ou

- transmet les données de transactions après avoir remplacé le code dynamique de sécurité DCCVi par avec le code statique de sécurité CW au serveur bancaire 6000.

En référence à la figure 3, nous allons décrire plus précisément ce deuxième cas en supposant qu'un utilisateur se connecte, en utilisant le terminal 2000 au site Web marchand 3000 pour réaliser une transaction, et que cet utilisateur saisit (étape E10) dans une page Web émise par le site marchand 3000 ou par le serveur 5000 des données de transaction DT(DCCVi) comportant:

- les informations PAN de la carte 1000 ;

- la date EXP d'expiration de la carte 1000 ; et

- le code dynamique de sécurité DCCVi affiché sur l'écran 1100 au moment de cette transaction.

Ces données de transaction DT(DCCVi) sont transmises par le site marchand 3000 au serveur 5000 de vérification, dans une requête d'autorisation de transaction au format IS08583. Le serveur 5000 reçoit cette requête au cours d'une étape E20.

L'utilisation du format IS08583 n'est obligatoire ni pour les communications entrantes ni pour les communications sortantes du serveur 5000 ; un autre format peut être utilisé.

Le serveur 5000 étant est sollicité pour vérifier une transaction, le procédé se poursuit à l'étape G30. Le serveur 5000 exécute l'étape G40 et détermine dans cet exemple que le mode de vérification actif est le mode dynamique « D ».

Le serveur 5000 entre donc dans la procédure de vérification des codes dynamiques (étape G60). Le procédé se poursuit alors par l'étape E30 de la figure 3.

Au cours de cette étape E30, le serveur de vérification 5000 génère un code dynamique DCCV 2 pour la transaction, à partir des données reçues à l'étape E20 et d'un paramètre temporel.

Au cours d'une étape E40, le serveur de vérification 5000 vérifie si ce code dynamique DCCV 2 est égal au code de sécurité compris dans les données de transaction à savoir le premier code dynamique DCCVi calculé par la carte à microcircuit 1000.

Si ces codes dynamiques sont égaux, le serveur de vérification 5000 envoie, au cours d'une étape E50, au serveur bancaire 6000, les données de transaction reçues du serveur 3000 dans lesquelles le code de sécurité DCCVi est remplacé par le code statique de sécurité CW de la carte 1000. Ces données de transaction modifiées sont notées DT(CW). De façon connue, l'établissement bancaire qui opère le serveur bancaire 6000 peut être identifié par un code BIN correspondant aux premiers chiffres du numéro PAN.

Dans le mode de réalisation décrit ici, si les codes dynamiques sont différents, le serveur de vérification 5000 envoie un message de refus de la transaction au serveur du site marchand 3000 au cours d'une étape E45. En variante, le serveur de vérification 5000 peut envoyer au serveur bancaire 6000 des données de transaction modifiées DT(£WJ avec un code de sécurité statique CW faux pour déclencher le refus de la transaction par le serveur bancaire.

Le module 6100 d'authentification et de sécurisation des transactions du serveur bancaire 6000 vérifie les données de transaction DT(CW) reçues du serveur de vérification 5000 au cours d'une étape E60 pour autoriser ou refuser la transaction.

Si le serveur bancaire 6000 autorise la transaction, il envoie un message d'autorisation au serveur du site marchand 3000 au cours d'une étape E70 qui délivre les biens ou services correspondants à l'utilisateur.

Si le serveur bancaire 6000 refuse la transaction, il envoie un message de refus de transaction au serveur du site marchand 3000 au cours d'une étape E80.

L'autorisation ou le refus est envoyée au serveur du site marchand dans un message de réponse d'autorisation au format ISO 8583.

Description détaillée d'un deuxième mode de réalisation de l'invention

La figure 4 représente un système 10 de vérification de code de sécurité comportant : - un serveur 5000 de vérification de code dynamique de sécurité et un serveur bancaire 6000 tels que décrits précédemment en référence aux figures 2 et 3 ; et

- un module d'interface 5500 conforme à l'invention.

Ce module d'interface 5500 est apte à recevoir des données de transaction DT d'un serveur de site marchand 3000 comportant soit un code statique de sécurité CW soit un code dynamique de sécurité DCWi, et à décider du traitement de ces données de transaction en fonction du critère statique/dynamique du code de sécurité.

Plus, précisément, en référence à la figure 5, le module d'interface

5500 détermine au cours d'une étape F10 si le code de sécurité compris dans les données de transaction DT est un code statique de sécurité CW ou un code dynamique de sécurité DCWi ; et

- Si le module d'interface 5500 détermine que le code est un code statique de sécurité, le module d'interface transmet ces données de transaction DT(CW) au serveur bancaire 6000 pour que celui-ci réalise directement le traitement décrit en référence aux étapes E60 à E80 de la figure 3. Ce mode de réalisation permet de diminuer la charge de calcul du serveur 5000 puisqu'une partie des données de transaction sont directement traitées par le serveur bancaire 6000.

- Si le module d'interface 5500 détermine que le code est un code dynamique de sécurité DCWi, le module d'interface transmet ces données de transaction DT(DCWi) au serveur 5000 de vérification de code dynamique de sécurité. S'il s'avère que la table 5600 mémorise une information selon laquelle il convient d'effectuer une vérification sur la base d'un code statique de sécurité, le serveur 5000 détecte un usage anormal et peut prendre des mesures pour bloquer toute transaction ultérieure avec la carte. Description détaillée d'un troisième et d'un quatrième modes de réalisation de l'invention

Dans le mode de réalisation de la figure 4, le module d'interface 5500 et le serveur 5000 de vérification de code dynamique de sécurité sont implémentés dans des équipements indépendants du serveur bancaire 6000. Dans un autre mode de réalisation de l'invention représenté à la figure 6, le module d'interface 5500 reste un équipement indépendant du serveur bancaire 6000 mais le serveur 5000 de vérification de code dynamique de sécurité est implémenté dans le serveur bancaire.

Dans un autre mode de réalisation de l'invention représenté à la figure 7, le module d'interface 5500 et le serveur 5000 de vérification de code dynamique de sécurité sont implémentés dans le serveur bancaire 6000.

Dans ces deux modes de réalisation, il est préférable que les fonctions du module d'interface 5500 et du serveur 5000 de vérification du code dynamique de sécurité ne soient pas intégrées dans le module 6100 d'authentification et de sécurisation des transactions en charge de la vérification du code statique de sécurité statique CW. Description détaillée d'un cinquième mode de réalisation de l'invention

Dans le premier mode de réalisation décrit en référence aux figures 1 à 3 et dans le deuxième mode de réalisation décrit en référence aux figures 4 et 5, lorsque le serveur 5000 de vérification de code dynamique de sécurité détermine que les codes de sécurité dynamiques DCWi et DCW 2 sont égaux (résultat du test E40 positif), il envoie les données de transaction (étape E50) au serveur bancaire 6000 en remplaçant le code dynamique de sécurité DCCVi par le code statique de sécurité CW pour vérification de ce code par le serveur bancaire 6000.

Dans un cinquième mode de réalisation de l'invention représenté en référence à la figure 8 dans lequel il n'est pas nécessaire d'impliquer le serveur bancaire 6000, le serveur 5000 envoie directement un message d'autorisation au serveur du site marchand 3000 au cours d'une étape E46 pour que celui-ci délivre les biens ou services correspondants à l'utilisateur.

Description détaillée d'un sixième mode de réalisation de l'invention Dans un mode particulier de réalisation, et comme représenté à la figure 11, le serveur 5000 de vérification de code dynamique de sécurité mémorise dans une table 5700, au moins pour certains comptes bancaires PAN, un code statique de sécurité CW * à durée limitée, et en association avec ce code, un critère TL permettant de déterminer jusqu'à quand ce code statique de sécurité CW * peut être valablement utilisé.

Ce critère de durée de vie TL peut notamment être :

- un nombre maximum de transactions ;

- associée à un montant maximum cumulé de transactions ; ou

- une date limite d'utilisation.

Dans le mode de réalisation décrit ici, le détenteur de la carte à microcircuit 1000 peut contacter le serveur 7000 de gestion de la sécurisation pour lui demander, après authentification, de générer un code statique de sécurité CW * à durée de vie limitée au moyen d'une clef cryptographique par exemple.

La génération du code statique de sécurité CW * à durée de vie limitée peut éventuellement nécessiter une interaction avec le détenteur de la carte à microcircuit 1000, au moyen de son terminal via un site Web ou par un serveur vocal par exemple.

Le code statique de sécurité CW * à durée de vie limitée est ensuite communiqué au détenteur de la carte à microcircuit 1000, par exemple par un serveur vocal, par SMS, par email ou via une interface Web de ce serveur 7000 affichée sur l'écran du terminal utilisateur 2000.

Dans un mode particulier de réalisation, le terminal utilisateur 2000 possède une application et un module apte à communiquer le code statique de sécurité CW * à durée de vie limitée à des moyens de communication à champ proche de la carte à microcircuit 1000 et le code CW* est présenté à l'utilisateur sur l'écran 1100 de la carte. La carte peut éventuellement utiliser un bouton pour permettre l'établissement de cette communication à champ proche.

Ce code statique de sécurité CW* à durée de vie limitée peut être reçu par le serveur 5000 de vérification de code dynamique de sécurité 5000 du serveur 7000 avec l'information TL de durée de vie. Cette information peut être calculée par le serveur 5000 ou par le serveur 7000 de gestion de la sécurisation, préférentiellement à partir de règles de calcul propres au détenteur de la carte à microcircuit 1000 et mémorisées par le serveur 7000. Variantes possibles communes à tous les modes de réalisation

L'invention a été décrite ci-dessus dans le contexte particulier d'une application de paiement en ligne. Elle peut s'appliquer :

- pour d'autres applications financières ; mais aussi

- dans d'autres dès lors qu'il s'agit de vérifier un code de sécurité saisi par un utilisateur par exemple pour vérifier un numéro de document d'identification d'identité, un identifiant de sécurité sociale, un code d'ouverture de porte, un code d'accès à un site Web.

Dans les modes de réalisation décrits précédemment, la génération du code dynamique de sécurité DCWi par la carte et du code dynamique de sécurité DCCV 2 utilisent un paramètre temporel. L'homme du métier comprendra que ces paramètres temporels doivent être synchronisés pour permettre la comparaison de ces codes. En pratique, pour palier à ces problèmes de synchronisation, le serveur peut générer plusieurs deuxièmes codes de sécurité en utilisant différents paramètres temporels, une transaction étant autorisée dès lors que l'un de ces deuxièmes codes de sécurité correspond au code dynamique de sécurité reçu de la carte à microcircuit.

En variante, le paramètre temporel peut être remplacé par un compteur incrémenté :

- du côté de la carte à microcircuit 1000 à chaque fois la carte génère un nouveau code dynamique de sécurité, par exemple lorsque l'utilisateur appuie sur le bouton poussoir 1400 ; et

- du côté du serveur 5000 de vérification de code dynamique de sécurité à chaque fois que celui-ci génère de son côté un code dynamique de sécurité pour vérifier la validité d'un code dynamique de sécurité généré par la carte à microcircuit 1000.

Là encore, l'homme du métier comprendra que ces compteurs doivent être synchronisés pour permettre la comparaison de ces codes. En pratique, pour palier à ces problèmes de synchronisation, le serveur peut générer plusieurs deuxièmes codes de sécurité en utilisant différentes valeurs de compteur, une transaction étant autorisée dès lors que l'un de ces deuxièmes codes de sécurité correspond au code dynamique de sécurité reçu de la carte à microcircuit.

Références :

[REFAA] : Demande de brevet européen n° EP 2 568 448 publiée le

13 mars 2013 pour une « carte de crédit ou de débit avec un code de sécurité ».

[REFCW] : en.wikipedia.org/wiki/card_security_code

[REFPAN] : en.wikipedia.org/wiki/Bank_card_number