FR 3038418 A1 20170106 FR 1556121 A 20150630 0 3 84 1 8 1 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 interdit toute transaction avec la carte à microcircuit si celle-ci n'est pas en mesure de générer ou 35 de présenter le code de sécurité dynamique, par exemple si l'afficheur de 3 0 3 84 1 8 2 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. 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 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 3 0 3 84 1 8 3 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é 5 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 10 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 15 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 20 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 25 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 30 à 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 35 vérification de code dynamique de sécurité comporte en outre un module de communication apte à envoyer à un serveur, et ce uniquement en cas 3 0 3 84 1 8 4 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 5 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 10 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é. 15 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, 20 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 25 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 30 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 35 un identifiant donné, si ledit code de sécurité doit être vérifié en le 303 8 4 1 8 5 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 5 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 10 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 15 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 20 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 25 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 30 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 35 aspect ou le deuxième aspect de l'invention sont déterminées par des instructions de programmes d'ordinateurs. 303 84 18 6 En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis 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 5 é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 10 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. 15 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 20 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 25 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 30 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 ; 35 - 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 ; 3038418 7 - 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 5 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; - 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 ; 10 - 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é ; 15 - 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 un serveur de vérification de code dynamique de sécurité. 20 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 25 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, 30 le dispositif 1000 peut être constitué par un terminal, par exemple de 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 1S07816. Elle comporte en particulier une 35 interface à contacts 1300. La carte à microcircuit 1000 est par exemple au 303 8 4 1 8 8 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 5 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é 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 10 consulter le document [REFCVV] ; - 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 15 horloge CLK, ce contrôleur 1200 étant apte à calculer un code dynamique de sécurité DCCV1 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 20 sécurité DCCV1 est varié de façon périodique, selon une période prédéterminée. 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 25 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. 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 30 dynamique de sécurité DCCV1. 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 35 sont sur la même face. 303 8 4 1 8 9 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é 5 é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 10 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é CVV de 15 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 20 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 ; 25 - un module 5800 apte à recevoir le code statique de sécurité CVV de cette carte 1000 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 ; - un module 5300 de contrôle apte à déterminer si le code de 30 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é CVV ou à un code dynamique de sécurité DCCV2 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 ; 35 - un module (5400) de comparaison conflguré pour comparer le code de sécurité compris dans les données de transaction bancaires soit 3038418 10 avec le code dynamique de sécurité DCCV2 soit avec le code statique de sécurité CVV, 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. 5 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 DCCV2, calculé par le serveur 5000 pour cette transaction, il envoie, au serveur bancaire 6000, les 10 données de transaction reçues du serveur 3000 en remplaçant le code de sécurité de ces données par le code statique de sécurité CVV 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 15 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 mettre en oeuvre les fonctions de calcul du deuxième code dynamique de sécurité DCCV2. 20 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é CVV (mode « S ») ou sur le code dynamique de 25 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 le mode de vérification est le mode statique « S ». Le mode de vérification S/D peut être modifié par le serveur 5000 30 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 35 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. 303 8 4 1 8 11 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 5 é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 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 10 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 15 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é. 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 20 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 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 25 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 peut aussi être calculée par le serveur 5000 à partir de la date de réception du message en provenance de ce serveur 7000. 30 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 : - jusqu'à recevoir un message prédéterminé du serveur 7000 de gestion de la sécurisation ; ou 35 - tant qu'un nombre prédéterminé de transactions n'a pas été dépassé ; ou 3038418 12 - 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 oeuvre par le serveur 5000 de vérification de code dynamique de 5 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 10 7000 pour un compte PAN, il bascule le mode de vérification au mode statique. 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é 15 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 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 20 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 25 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 30 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é. 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). 35 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 303 8 4 1 8 13 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 5 - 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é CVV 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 10 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(DCCV1) comportant: - les informations PAN de la carte 1000; 15 - 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. Ces données de transaction DT(DCCV1) sont transmises par le site marchand 3000 au serveur 5000 de vérification, dans une requête 20 d'autorisation de transaction au format 1S08583. Le serveur 5000 reçoit cette requête au cours d'une étape E20. L'utilisation du format 1S08583 n'est obligatoire ni pour les communications entrantes ni pour les communications sortantes du serveur 5000 ; un autre format peut être utilisé. 25 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 30 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 DCCV2 pour la transaction, à partir des données reçues à l'étape E20 et d'un paramètre temporel. 35 Au cours d'une étape E40, le serveur de vérification 5000 vérifie si ce code dynamique DCCV2 est égal au code de sécurité compris dans les 3038418 14 données de transaction à savoir le 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 5 de transaction reçues du serveur 3000 dans lesquelles le code 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 chiffres du 10 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 15 bancaire 6000 des données de transaction modifiées DT(0,./) 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 20 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. 25 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. 30 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 35 sécurité comportant : 303 8 4 1 8 15 - 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. 5 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é. 10 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é CVV ou un code dynamique de sécurité DCVVi ; et - Si le module d'interface 5500 détermine que le code est un code 15 statique de sécurité, le module d'interface 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. Ce mode de réalisation permet de diminuer la charge de calcul du serveur 5000 puisqu'une partie des données de transaction sont 20 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é DCVVi, le module d'interface transmet ces données de transaction DT(DCVVi) au serveur 5000 de vérification de code dynamique de sécurité. S'il s'avère que la table 5600 mémorise une 25 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. 30 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é 35 sont implémentés dans des équipements indépendants du serveur bancaire 6000. 3038418 16 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. 5 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 10 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. 15 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 20 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 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é CW pour 25 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 30 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 35 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é 303 8 4 1 8 17 mémorise dans une table 5700, au moins pour certains comptes bancaires PAN, un code statique de sécurité ON* à 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é CVV* peut être valablement utilisé. 5 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 à 10 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. La génération du code statique de sécurité CVV* à durée de vie 15 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 communiqué au détenteur de la carte à microcircuit 1000, par exemple 20 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é CVV* à durée de vie limitée à des moyens de 25 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. Ce code statique de sécurité CW* à durée de vie limitée peut être 30 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 35 par le serveur 7000. 3038418 18 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 : 5 - 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. 10 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 15 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 à 20 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 25 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é 30 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 35 valeurs de compteur, une transaction étant autorisée dès lors que l'un de 303 84 1 8 19 ces deuxièmes codes de sécurité correspond au code dynamique de sécurité reçu de la carte à microcircuit. Références : 5 [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 10 REVENDICATIONS1. 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é (CVV, DCCV1) 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é 10 doit être vérifié en le comparant à un code dynamique de sécurité (DCCV2) ou à un code statique de sécurité (CVV) ; - 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 15 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 20 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. 25 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é (CVV) associé audit identifiant (PAN) en utilisant une clef secrète. 30 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é (CVV) avant de le comparer avec ledit code de sécurité, ladite condition d'utilisation pouvant notamment être 35 constituée par : - une date limite d'utilisation dudit code statique de sécurité (CVV) ; 3038418 21 - la non réception d'un message prédéterminé ; ou - le fait que ledit code statique de sécurité (CVV) n'a pas été utilisé pour un nombre ou un montant cumulé de transactions. 5 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é (CVV). 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é (CVV) 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é (CVV*) à 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 : 303 8 4 1 8 22 - une carte à microcircuit (1000) comportant, un code statique de sécurité (CVV) et un écran (1400) pour afficher un code dynamique de sécurité (DC0/1) généré par ladite carte pour réaliser une transaction ; - ledit serveur (5000) de vérification de code dynamique de sécurité 5 étant apte à vérifier la validité du code statique de sécurité de ladite carte et celle dudit code dynamique de sécurité (DCCV1) généré par ladite carte. 10. Système selon la revendication 9 caractérisé en ce qu'il comporte : 10 - 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é (DCCV1) généré par ladite carte pour cette transaction ; 15 - 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). 20 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é (CVV, DCCV1) associé à un dispositif (1000) associé à cet identifiant pour réaliser une 25 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é (CVV) ; - une étape pour générer, dans la première hypothèse un code 30 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 35 code dynamique de sécurité (DCCV2) soit avec un code statique de sécurité associé avec ledit identifiant (PAN); 3 0 3 84 1 8 23 - 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 5 mettre en oeuvre 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 10 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.