Brevet FR3038417A1 — publié le 20170106

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 10 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 15 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. 20 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 25 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 30 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 dans ce document présente un inconvénient majeur en ce qu'elle nécessite une modification 35 complexe du système d'autorisation de transaction du serveur de la banque. 3038417 2 L'invention propose une solution pour vérifier un code de sécurité qui ne présente pas cet inconvénient. 5 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 dynamique de sécurité comportant : - un module de communication apte à recevoir des données de 10 transaction bancaires comportant un identifiant et un premier code dynamique de sécurité généré par un dispositif associé à cet identifiant à partir d'une donnée temporelle ou d'un compteur du nombre de premiers codes dynamiques de sécurité générés par ledit dispositif ; - un module de génération d'un deuxième code dynamique de 15 sécurité à partir dudit identifiant et d'une donnée temporelle ou d'un compteur du nombre de deuxièmes codes dynamiques de sécurité générés par ledit module pour cet identifiant ; - un module de comparaison des premier et deuxième codes dynamiques de sécurité ; 20 - le module de communication étant apte à envoyer à un serveur, et ce uniquement en cas d'égalité des premier et deuxième codes dynamiques de sécurité, les données de transaction précitées dans lesquelles le code dynamique de sécurité est remplacé par un code statique de sécurité associé au dispositif, ce serveur étant configuré pour 25 vérifier la validité dudit code statique de sécurité pour autoriser ou refuser ladite transaction. Corrélativement, l'invention propose un procédé de vérification d'un code dynamique de sécurité comportant : - une étape de réception de données de transaction bancaires 30 comportant un identifiant et un premier code dynamique de sécurité généré par un dispositif associé à cet identifiant à partir d'une donnée temporelle ou d'un compteur du nombre de premiers codes dynamiques de sécurité générés par ce dispositif ; - une étape de génération d'un deuxième code dynamique de 35 sécurité à partir dudit identifiant et d'une donnée temporelle ou d'un 3038417 3 compteur du nombre de deuxièmes codes dynamiques de sécurité générés par ce module pour cet identifiant ; - une étape de comparaison des premier et deuxième codes dynamiques de sécurité ; 5 - une étape d'envoi à un serveur, et ce uniquement en cas d'égalité des premier et deuxième codes dynamiques, des données de transaction précitées dans lesquelles ledit code dynamique de sécurité est remplacé par un 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, et d'une façon générale, l'invention propose selon ce premier aspect, 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 30 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 35 sécurité comportant : 3038417 4 - un serveur de vérification de code dynamique de sécurité tel que mentionné ci-dessus ; - le serveur configuré pour vérifier la validité dudit code statique de sécurité pour autoriser ou refuser ladite transaction ; et 5 - un module d'interface apte à recevoir des données de transaction comportant soit un code statique de sécurité soit un code dynamique de sécurité et à transmettre lesdites données de transaction : - au serveur de vérification de code dynamique de sécurité selon l'invention si les données de transaction comportent un code 10 dynamique de sécurité ; ou - au serveur configuré pour vérifier la validité dudit code statique de sécurité si les données de transaction comportent un code statique de sécurité. Autrement dit, dans ce mode de réalisation, l'invention propose un 15 module d'interface apte à rediriger les données de transaction soit vers le serveur selon l'invention soit vers le serveur configuré pour vérifier la validité dudit code statique de sécurité (par exemple le serveur bancaire) en fonction du type dynamique/statique du code de sécurité compris dans les données de transaction. 20 Ce module d'interface offre aux opérateurs une solution modulaire pour intégrer le serveur de vérification de code dynamique de sécurité selon l'invention dans les réseaux interbancaires existants. Dans un mode particulier de réalisation, le serveur de vérification de code dynamique de sécurité est implémenté dans le serveur configuré 25 pour vérifier la validité du code statique de sécurité (par exemple un serveur bancaire). Dans un mode particulier de réalisation, le module d'interface selon l'invention est également implémenté dans le serveur configuré pour vérifier la validité du code statique de sécurité. 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 ; 3038417 5 - le serveur de vérification de code dynamique de sécurité selon l'invention étant apte à vérifier la validité du code dynamique de sécurité généré par ladite carte ; - le serveur configuré pour vérifier la validité du code statique de 5 sécurité étant apte à vérifier le code statique de sécurité de cette 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 10 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. 15 Dans les modes de réalisation décrits ci-dessus, lorsque le serveur de vérification de code dynamique de sécurité selon l'invention vérifie la validité du code dynamique de sécurité pour la transaction, il sollicite le serveur configuré pour autoriser ou refuser la transaction pour que celui-ci vérifie le code statique de sécurité. 20 Dans une autre variante conforme à l'invention, lorsque le serveur vérifie la validité du code dynamique de sécurité il envoie directement un message au serveur réalisant la transaction, sans solliciter le serveur configuré pour autoriser ou refuser la transaction, typiquement le serveur bancaire. 25 Plus précisément, selon ce deuxième aspect, l'invention concerne un serveur de vérification de code dynamique de sécurité comportant : - un module de communication apte à recevoir, dans un réseau de communication, des données de transaction comportant un identifiant et un premier code dynamique de sécurité généré par un dispositif associé à 30 cet identifiant à partir d'une donnée temporelle ou d'un compteur du nombre de premiers codes dynamiques de sécurité générés par ce dispositif, ces données de transaction étant destinées à un serveur configuré pour vérifier la validité d'un code statique de sécurité pour autoriser ou refuser ladite transaction ; - un module de génération d'un deuxième code dynamique de sécurité à partir de l'identifiant et d'une donnée temporelle ou d'un 3038417 6 compteur du nombre de deuxièmes codes dynamiques de sécurité générés par ce module pour cet identifiant ; - un module de comparaison des premier et deuxième codes dynamiques de sécurité ; 5 - le module de communication étant apte à envoyer à un serveur apte à réaliser la transaction, et ce uniquement en cas d'égalité des premier et deuxième codes dynamiques, un message d'autorisation pour réaliser ladite transaction, le serveur de vérification de code dynamique de sécurité étant 10 implémenté dans un équipement d'interface entre le réseau et le serveur configuré pour vérifier la validité d'un code statique de sécurité. Corrélativement, l'invention concerne un procédé de vérification de code dynamique de sécurité comportant : - une étape de réception, dans un réseau de communication, de 15 données de transaction comportant un identifiant et un premier code dynamique de sécurité généré par un dispositif associé à cet identifiant à partir d'une donnée temporelle ou d'un compteur du nombre de premiers codes dynamiques de sécurité générés par ce dispositif, les données de transaction étant destinées à un serveur configuré pour vérifier la validité 20 d'un code statique de sécurité pour autoriser ou refuser la transaction ; - une étape de génération d'un deuxième 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 le module pour cet identifiant ; 25 - une étape de comparaison des premier et deuxième codes dynamiques de sécurité ; - une étape d'envoi, à un serveur apte à réaliser la transaction, et ce uniquement en cas d'égalité des premier et deuxième codes dynamiques, d'un message d'autorisation pour réaliser la transaction, 30 ce procédé étant mis en oeuvre dans un équipement d'interface entre le réseau et le serveur configuré pour vérifier la validité d'un code statique de sécurité. L'invention vise aussi un système de vérification d'un code de sécurité comportant : 3 0 3 8 4 1 7 7 - 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 cette carte pour réaliser une transaction ; - un serveur de vérification de code dynamique de sécurité selon ce 5 deuxième aspect de l'invention apte à vérifier la validité du code dynamique de sécurité généré par ladite carte et à envoyer un message d'autorisation de la transaction à un serveur apte à réaliser la transaction, uniquement lorsque la validité dudit code dynamique a été vérifiée. Dans un mode de réalisation ce système comporte : 10 - un terminal permettant à un utilisateur de se connecter au serveur pour réaliser la transaction, le terminal comportant une interface homme-machine permettant audit utilisateur de saisir les données de ladite transaction dont le code dynamique de sécurité généré par la carte pour cette transaction ; 15 - ledit 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 20 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 25 en oeuvre dans un serveur ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre 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 30 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 35 ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. 3038417 8 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. 5 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. 10 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. 15 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 20 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é 25 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 oeuvre par un module d'interface du système de la figure 4; 30 - 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 ; 35 - la figure 9 représente une table pouvant être utilisée par un serveur de vérification de code dynamique de sécurité ; 3038417 9 - la figure 10 représente sous forme d'organigramme des étapes mises en oeuvre 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 5 un serveur de vérification de code dynamique de sécurité ; - la figure 12 représente sous forme d'organigramme des étapes mises en oeuvre par un serveur de vérification de code dynamique de sécurité qui utilise la table de la figure 11. 10 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. 15 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 20 téléphonie mobile, mettant en oeuvre 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 25 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 30 1000. La carte comporte en outre un code statique de sécurité CVV, celui- ci pouvant être ou ne pas être imprimé sur la carte. Pour plus de renseignements sur : - le code statique de sécurité CVV, l'homme du métier peut consulter le document [REFCVV] ; 35 - le numéro de compte bancaire PAN, l'homme du métier peut consulter le document [REFPAN]. 3038417 10 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é DCCV1 en appliquant une fonction cryptographique secrète à 5 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é DCCV1 est varié de façon périodique, selon une période prédéterminée. 10 Au contraire, le code statique de sécurité CVV est constant dans le temps. La carte à microcircuit 1000 comporte un écran 1100 d'affichage de ce code dynamique de sécurité DCCV1. Cet écran peut comporter par exemple 3 ou 4 zones élémentaires selon la taille de ce code dynamique. 15 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é DCCV1. Ce bouton-poussoir ou tout moyen équivalent (bouton capacitif, ...) pour allumer ou éteindre l'écran 1100 est 20 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 25 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. 30 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 35 d'authentification et d'autorisation des transactions bancaires. 3038417 11 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é CVV de la carte à microcircuit 1000. Le serveur 5000 de vérification de code dynamique de sécurité est 5 conforme à l'invention. Il comporte notamment : - un module 5100 apte à obtenir la date courante, soit en utilisant des moyens internes, soit par exemple à partir d'un autre équipement ou d'un autre réseau, par des moyens de communications sans fil ou filaires ; - un module 5200 de communication apte à recevoir des données 10 de transaction bancaires DT(DCCV1) comportant, le numéro de compte bancaire PAN, la date d'expiration EXP de la carte et le premier code dynamique de sécurité DCCV1 calculé par la carte à microcircuit 1000 pour une transaction ; - un module 5300 de génération d'un deuxième code dynamique de 15 sécurité DCCV2 pour cette transaction en ligne en utilisant le numéro de compte bancaire PAN, une fonction cryptographique secrète et une donnée temporelle ; - un module 5400 de comparaison des premier et deuxième codes dynamiques de sécurité ; 20 - un module 5800 apte à recevoir le code statique de sécurité CVV d'une carte à microcircuit ou à générer ce code statique CVV 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 ; - le module de communication 5200 étant apte à envoyer au 25 serveur bancaire 6000, et ce uniquement en cas d'identité des premier et deuxième codes dynamiques DCCV1, DCCV2, les données de transaction reçues du serveur 3000 dans lesquelles la code dynamique de sécurité DCCV1 est remplacé par le code statique de sécurité CVV obtenu par le module 5800. 30 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é CVV pour autoriser ou refuser la transaction. Il est fondamental de noter que cette vérification utilise le code statique de sécurité CVV de sorte que le serveur bancaire 6000 n'a pas besoin de 35 mettre en oeuvre les fonctions de calcul du deuxième code dynamique de sécurité DCCV2. 3038417 12 En référence à la figure 3, nous supposerons qu'un utilisateur se connecte, en utilisant le terminal 2000 au site Web marchand 3000 pour réaliser une transaction, et que cet utilisateur saisit (étape E10) dans une page Web émise par le site marchand 3000 ou par le serveur 5000 des 5 données de transaction DT(DCCV1) comportant: - les informations PAN de la carte 1000; - la date EXP d'expiration de la carte 1000 ; et - le code dynamique de sécurité DCCV1 affiché sur l'écran 1100 au moment de cette transaction. 10 Ces données de transaction DT(DCCV1) 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 15 communications entrantes ni pour les communications sortantes du serveur 5000 ; un autre format peut être utilisé. Au cours, d'une étape E30, le serveur de vérification 5000 génère un deuxième code dynamique DCCV2 pour la transaction, à partir des données reçues à l'étape E20 et d'un paramètre temporel. 20 Au cours d'une étape E40, le serveur de vérification 5000 vérifie si ce deuxième code dynamique DCCV2 est égal au premier code dynamique DCCV1 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 25 de transaction reçues du serveur 3000 dans lesquelles le code dynamique de sécurité DCCV1 est remplacé par le code statique de sécurité CVV de la carte 1000. Ces données de transaction modifiées sont notées DT(CVV). De façon connue, l'établissement bancaire qui opère le serveur bancaire 6000 peut être identifié par un code BIN correspondant aux premiers 30 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 35 bancaire 6000 des données de transaction modifiées DT(CW) avec un 3038417 13 code de sécurité statique CVV 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 5 DT(CVV) 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. 10 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. 15 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 20 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. 25 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é CVV soit un code dynamique de sécurité DCVVi, et à décider du traitement de ces données de transaction en fonction du critère statique/dynamique du code de sécurité. 30 Plus, précisément, en référence à la figure 5, le module d'interface 5500 détermine au cours d'une étape F10 site code de sécurité compris dans les données de transaction DT est un code statique de sécurité CVV ou un code dynamique de sécurité DCVV1 ; et - Si le code est un code dynamique de sécurité, le module 35 d'interface transmet ces données de transaction DT(DCVVi) au serveur 5000 de vérification de code dynamique de sécurité pour que celui-ci 3038417 14 vérifie le code dynamique de sécurité DCCV1 (étapes E30 et E40) et transmette les données de transaction DT(CW) comportant le code statique de sécurité CVV au serveur 6000 (étape E50) ; - Si le code est un code statique de sécurité, le module d'interface 5 transmet ces données de transaction DT(CVV) 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. Description détaillée d'un troisième et d'un quatrième modes de 10 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 15 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. 20 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 25 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 CVV. 30 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 35 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 DCVVi et 3038417 15 DCVV2 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é DCCV1 par le code statique de sécurité CVV pour vérification de ce code par le serveur bancaire 6000. 5 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 à 10 l'utilisateur. Description détaillée d'un sixième mode de réalisation de l'invention Dans un mode particulier de réalisation de l'invention, le serveur 15 5000 de vérification de code dynamique de sécurité est également apte à vérifier le code statique de sécurité CW associé à un compte bancaire PAN. A cet effet, et comme représenté à la figure 9, le serveur 5000 gère une table 5600 dans laquelle il mémorise, pour chaque numéro de compte 20 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é CVV (mode « S ») ou sur le code dynamique de sécurité DCVVi (mode « D »). Le serveur 5000 mémorise dans cette table 5600, le code dynamique de sécurité CVV au moins pour les cartes à microcircuits 1000 pour lesquelles 25 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 à 30 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é DCCV1, utilise au moins pendant un certain temps, le code statique de sécurité CVV. L'utilisateur peut faire une telle demande en particulier lorsque 35 l'afficheur 1100 de la carte à microcircuit 1000 est hors d'usage ou lorsque la batterie de cette carte est insuffisamment chargée. 3038417 16 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é CVV* à durée de vie limitée comme décrit ultérieurement en référence au septième mode de réalisation de l'invention. 5 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 10 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é CVV au serveur 7000 pour que celui-ci le transmette au serveur 5000 de vérification de code dynamique de sécurité. 15 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é DCCV1 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 20 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 CVV 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 25 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é CVV : 30 - 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é 35 atteint. 3038417 17 La figure 10 représente sous forme d'organigramme un procédé mis en oeuvre 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 5 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. 10 Dans cet exemple le code statique de sécurité CVV 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é CVV 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 15 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 20 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. 25 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é CVV est vérifié. 30 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é CVV mémorisé dans la table 5600 (étape G50). Sinon, le serveur 5000 calcule un code dynamique de sécurité DCCV2 et vérifie la transaction sur la base de ce code dynamique de 35 sécurité (étape G60). En cas de succès, et selon le mode de réalisation de l'invention, le serveur 5000 : 3038417 18 - 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é DCCV1 par avec le code statique de sécurité 5 CVV au serveur bancaire 6000. Dans ce mode de réalisation, les architectures décrites aux figures 2, 4, 6 et 7 peuvent être utilisées : le serveur 5000 de vérification de code dynamique de sécurité peut être ou non associé à un module d'interface 5500, chacune des entités 5000 et 5500 pouvant éventuellement être 10 implémentée dans le serveur bancaire 6000. Description détaillée d'un septième mode de réalisation de l'invention 15 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é CVV* à durée limitée, et en association avec ce code, un critère TL permettant de déterminer jusqu'à quand ce 20 code statique de sécurité CVV* 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. 25 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é CVV* à durée de vie limitée au moyen d'une clef cryptographique par exemple. 30 La génération du code statique de sécurité CVV* à 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é CVV* à durée de vie limitée est ensuite 35 communiqué au détenteur de la carte à microcircuit 1000, par exemple 3038417 19 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 5 statique de sécurité CVV* à durée de vie limitée à des moyens de communication à champ proche de la carte à microcircuit 1000 et le code CVV* 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. 10 En référence à la figure 12, ce code statique de sécurité CVV* à durée de vie limitée peut être reçu par le serveur 5000 de vérification de code dynamique de sécurité 5000 du serveur 7000 au cours d'une étape H10. Dans le mode de réalisation décrit ici, le serveur 5000 de 15 vérification de code dynamique de sécurité obtient l'information TL de durée de vie au cours d'une étape H20. En pratique, cette information peut être calculée par le serveur 5000 ou par le serveur 7000 de gestion de la sécurisation, préférentiellement à partir de règles de calcul propres au détenteur de la carte à microcircuit 1000 et mémorisées par le serveur 20 7000. Lorsque le serveur 5000 de vérification de code dynamique de sécurité est sollicité pour vérifier une transaction (étape H30), il commence, dans ce mode de réalisation par générer un code dynamique de sécurité DCCV2 (étape H40) et à vérifier si le code de sécurité CS reçu 25 dans les données de transactions est identique à ce code (étape H50). Si tel est le cas, en fonction du mode de réalisation de l'invention, le serveur 5000 (étape H60) : - envoie directement un message au serveur 3000 du site marchand pour valider la transaction ; ou 30 - transmet les données de transaction au serveur bancaire 6000 après avoir remplacé le code dynamique de sécurité CS par avec le code statique de sécurité CVV de la carte 1000. Lorsque le code de sécurité dynamique DCCV2 calculé à l'étape H40 est différent du code de sécurité CS compris dans les données de 35 transaction, le serveur 5000 vérifie (étape H70) si ce code de sécurité correspond au code statique de sécurité CVV* à durée de vie limitée pour 3038417 20 ce compte PAN et, en fonction du paramètre TL, si ce code est encore valable. Bien entendu, il est possible de commencer par vérifier à l'étape H50 si le code de sécurité CS correspond au code statique de sécurité CVV* à durée de vie limitée, et si ce n'est pas le cas, à l'étape H70 si si le 5 code de sécurité CS correspond au code dynamique de sécurité DCCV2 généré à l'étape H40. Quoiqu'il en soit, en cas de succès de cette double vérification, le serveur 5000 exécute l'étape H60 précédemment décrite pour autoriser la transaction, soit directement, soit indirectement. 10 Sinon, le serveur 5000 de vérification du code de sécurité dynamique envoie (étape H80) un message au serveur 3000 du site marchand pour refuser la transaction. En variante, et comme mentionné précédemment, le serveur de vérification 5000 peut envoyer au serveur bancaire 6000 des données de transaction modifiées DT(CVV) avec un 15 code de sécurité statique CVV faux pour déclencher le refus de la transaction par le serveur bancaire. L'utilisation d'un code statique de sécurité CVV* à durée de vie limitée peut notamment permettre au détenteur de la carte à microcircuit 1000 de prêter sa carte pour une durée limitée, un nombre de 20 transactions ou un montant maximum de transactions. Comme dans les autres modes de réalisation, les architectures décrites aux figures 2, 4, 6 et 7 peuvent être utilisées : le serveur 5000 de vérification de code dynamique de sécurité peut être ou non associé à un module d'interface 5500, chacune des entités 5000 et 5500 pouvant 25 éventuellement être implémentée dans le serveur bancaire 6000. Variantes possibles communes à tous les modes de réalisation L'invention a été décrite ci-dessus dans le contexte particulier d'une 30 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 35 d'ouverture de porte, un code d'accès à un site Web. 3038417 21 Dans les modes de réalisation décrits précédemment, la génération du code dynamique de sécurité DCVVi par la carte et du code dynamique de sécurité DCCV2 utilisent un paramètre temporel. L'homme du métier comprendra que ces paramètres temporels doivent être synchronisés pour 5 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 à 10 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 15 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é 20 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 25 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 : 30 [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é ». [REFCVV] : en.wikipedia.org/wiki/card_security_code [REFPAN] : en.wikipedia.org/wiki/Bank_card_number 35 REVENDICATIONS1. Serveur (5000) de vérification de code dynamique de sécurité 5 comportant : - un module (5200) de communication apte à recevoir des données de transaction bancaires (DT(DCCV1)) comportant un identifiant (PAN) et un premier code dynamique de sécurité (DCCV1) généré par un dispositif (1000) associé à cet identifiant à partir d'une donnée temporelle ou d'un 10 compteur du nombre de premiers codes dynamiques de sécurité (DCCV1) générés par ledit dispositif (1000) ; - un module (5300) de génération d'un deuxième 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 15 de sécurité (DCCV2) générés par ledit module (5300) pour ledit identifiant (PAN) ; - un module (5400) de comparaison des premier et deuxième codes dynamiques de sécurité ; - ledit module de communication (5200) étant apte à envoyer à un 20 serveur (6000), et ce uniquement en cas d'égalité des premier et deuxième codes dynamiques (DCCV1, DCCV2), lesdites données de transaction dans lesquelles ledit code dynamique de sécurité (DCCV1) est remplacé par un code statique de sécurité (CVV) associé audit dispositif (1000), ledit serveur (6000) étant configuré pour vérifier la validité dudit 25 code statique de sécurité (CVV) pour autoriser ou refuser ladite transaction. 2. Serveur (5000) de vérification de code dynamique de sécurité selon la revendication 1, caractérisé en ce que le dit serveur est configuré 30 pour envoyer un message de refus de ladite transaction à un serveur configuré pour réaliser la transaction (3000) si lesdits premier et deuxième codes dynamiques (DCCV1, DCCV2) sont différents. 3. Module d'interface (5500) apte à recevoir des données de 35 transaction comportant soit un code statique de sécurité (CVV) soit un 3038417 23 code dynamique de sécurité (DCVVi) et à transmettre lesdites données de transaction : - à un serveur (5000) de vérification de code dynamique de sécurité selon la revendication 1 ou 2 si lesdites données de transaction 5 comportent un code dynamique de sécurité (DCW1) ; ou - à un serveur (6000) configuré pour vérifier la validité du code statique de sécurité (CW) pour autoriser ou refuser ladite transaction si lesdites données de transaction comportent un code statique de sécurité (CW). 10 4. Système (10) de vérification d'un code de sécurité comportant : - un serveur (5000) de vérification de code dynamique de sécurité selon l'une quelconque des revendications 1 à 3 ; - un serveur (6000) configuré pour vérifier la validité dudit code 15 statique de sécurité (CW) pour autoriser ou refuser ladite transaction ; et - un module d'interface (5500) selon la revendication 3. 5. Système selon la revendication 4 dans lequel ledit serveur (5000) de vérification de code dynamique de sécurité est implémenté dans ledit 20 serveur (6000) configuré pour vérifier la validité dudit code statique de sécurité (CVV). 6. Système selon la revendication 5 dans lequel ledit module d'interface (5500) est implémenté dans ledit serveur (6000) configuré 25 pour vérifier la validité dudit code statique de sécurité (CW). 7. Système selon l'une quelconque des revendications 4 à 6 caractérisé en ce qu'il comporte : - une carte à microcircuit (1000) comportant, un code statique de 30 sécurité (CW) et un écran (1400) pour afficher un code dynamique de sécurité (DCCV1) 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é dudit code dynamique de sécurité (DCCV1) généré par ladite carte ; 35 - ledit serveur (6000) configuré pour vérifier la validité dudit code statique de sécurité (CW) étant apte à vérifier la validité dudit code 3038417 24 statique de sécurité (CCV) de ladite carte pour autoriser ou refuser ladite transaction. 8. Système selon la revendication 7 caractérisé en ce qu'il 5 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 10 sécurité (DCCV1) 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. 15 9. Procédé de vérification d'un code dynamique de sécurité comportant : - une étape (E20) de réception de données de transaction bancaires (DT(DCCV1)) comportant un identifiant (PAN) et un premier code dynamique de sécurité (DCCV1) généré par un dispositif (1000) associé à 20 cet identifiant à partir d'une donnée temporelle ou d'un compteur du nombre de premiers codes dynamiques de sécurité (DCCV1) générés par ledit dispositif (1000) ; - une étape (E30) de génération d'un deuxième code dynamique de sécurité (DCCV2) à partir dudit identifiant (PAN) et d'une donnée 25 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 (E40) de comparaison des premier et deuxième codes dynamiques de sécurité ; 30 - une étape (E50) d'envoi à un serveur (6000), et ce uniquement en cas d'égalité des premier et deuxième codes dynamiques (DCCV1, DCCV2), desdites données de transaction dans lesquelles ledit code dynamique de sécurité (DCCV1) est remplacé par un code statique de sécurité (CVV) associé audit dispositif (1000), ledit serveur (6000) étant configuré pour 35 vérifier la validité dudit code statique de sécurité (CVV) pour autoriser ou refuser ladite transaction. 3038417 25 10. Serveur (5000) de vérification de code dynamique de sécurité : - un module (5200) de communication apte à recevoir, dans un réseau de communication (4000), des données de transaction (DT(DCCV1)) comportant un identifiant (PAN) et un premier code 5 dynamique de sécurité (DCCV1) généré par un dispositif (1000) associé à cet identifiant à partir d'une donnée temporelle ou d'un compteur du nombre de premiers codes dynamiques de sécurité (DCCV1) générés par ledit dispositif (1000), lesdites données de transaction étant destinées à un serveur (6000) conflguré pour vérifier la validité d'un code statique de 10 sécurité (CVV) pour autoriser ou refuser ladite transaction ; - un module (5300) de génération d'un deuxième 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 15 (PAN) ; - un module (5400) de comparaison des premier et deuxième codes dynamiques de sécurité ; - ledit module de communication (5200) étant apte à envoyer à un serveur (3000) apte à réaliser ladite transaction, et ce uniquement en cas 20 d'égalité des premier et deuxième codes dynamiques (DCCV1, DCCV2), un message d'autorisation pour réaliser ladite transaction, ledit serveur (5000) de vérification de code dynamique de sécurité étant implémenté dans un équipement (5000) d'interface entre ledit réseau (4000) et ledit serveur (6000) configuré pour vérifier la validité 25 d'un code statique de sécurité (CVV). 11. Système (10) de vérification d'un code de sécurité comportant : - une carte à microcircuit (1000) comportant, un code statique de sécurité (CVV) et un écran (1400) pour afficher un code dynamique de 30 sécurité (DCCV1) généré par ladite carte pour réaliser une transaction ; - un serveur (5000) de vérification de code dynamique de sécurité selon la revendication 10 apte à vérifier la validité dudit code dynamique de sécurité (DCCV1) généré par ladite carte et à envoyer un message d'autorisation de ladite transaction à un serveur (3000) apte à réaliser 35 ladite transaction, uniquement lorsque la validité dudit code dynamique a été vérifiée. 3038417 26 12. Système selon la revendication 11 caractérisé en ce qu'il comporte : - un terminal (2000) permettant à un utilisateur de se connecter audit 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é (DCCV1) 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). 13. Procédé de vérification de code dynamique de sécurité 15 comportant : - une étape (E20) de réception, dans un réseau de communication (4000), de données de transaction (DT(DCCV1)) comportant un identifiant (PAN) et un premier code dynamique de sécurité (DCCV1) généré par un dispositif (1000) associé à cet identifiant à partir d'une donnée temporelle 20 ou d'un compteur du nombre de premiers codes dynamiques de sécurité (DCCV1) générés par ledit dispositif (1000), lesdites données de transaction étant destinées à un serveur (6000) configuré pour vérifier la validité d'un code statique de sécurité (CVV) pour autoriser ou refuser ladite transaction ; 25 - une étape (E30) de génération d'un deuxième 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) ; 30 - une étape (E40) de comparaison des premier et deuxième codes dynamiques de sécurité ; - une étape (E46) d'envoi, à un serveur (3000) apte à réaliser ladite transaction, et ce uniquement en cas d'égalité des premier et deuxième codes dynamiques (DCCV1, DCCV2), d'un message d'autorisation pour 35 réaliser ladite transaction, 3038417 27 ledit procédé étant mis en oeuvre dans un équipement (5000) d'interface entre ledit réseau (4000) et ledit serveur (6000) configuré pour vérifier la validité d'un code statique de sécurité (CVV). 5 14. Programme d'ordinateur comportant des instructions pour mettre en oeuvre les étapes d'un procédé de vérification de code dynamique de sécurité selon la revendication 9 ou 13 lorsque ce programme est exécuté par un ordinateur. 10 15. 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 9 ou 13.