Brevet FR3038419A1 — 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 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 303 84 19 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 10 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 configuré pour générer un code dynamique de sécurité 15 à 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 ledit identifiant ; - un module de comparaison configuré pour déterminer que le résultat de ladite comparaison est positif si et seulement si ledit code de 20 sécurité correspond audit code dynamique de sécurité ou à un code statique de sécurité à durée de vie limitée généré par un serveur de gestion de la sécurisation pour ledit identifiant ; - ledit serveur de vérification de code de sécurité étant configuré pour permettre ou interdire directement ou indirectement la réalisation de 25 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 30 identifiant pour réaliser une transaction ; - une étape de génération d'un code dynamique de 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 ledit identifiant ; 35 - une étape de comparaison dont le résultat est positif si et seulement si ledit code de sécurité correspond audit code dynamique de 3038419 3 sécurité ou à un code statique de sécurité à durée de vie limitée généré par un serveur de gestion de la sécurisation pour ledit identifiant ; - ladite transaction étant permise ou interdite en fonction du résultat de ladite comparaison. 5 Ainsi, et d'une façon générale, l'invention propose un serveur (et le procédé associé) configuré pour autoriser une transaction par un dispositif si les données de transaction comportent un code dynamique de sécurité compatible avec le moment de la transaction ou avec un code statique de sécurité à durée de vie limitée correspondant à ce dispositif. L'utilisation d'un code statique de sécurité à durée de vie limitée permet avantageusement au détenteur du dispositif de prêter ce dispositif à un tiers pour une durée limitée, un nombre de transactions ou un montant maximum de transactions. Dans un mode particulier de réalisation, le serveur de vérification 15 de code de sécurité selon l'invention comporte une table qui associe à l'identifiant du dispositif : - le code statique de sécurité à durée de vie limitée généré par ledit serveur de gestion de la sécurisation pour cet identifiant ; et - un critère d'utilisation dudit code statique de sécurité à durée de 20 vie limitée. Ce critère d'utilisation peut notamment être constitué par : - une date limite d'utilisation du code statique de sécurité à durée de vie limitée ; - le fait que ledit code statique de sécurité à durée de vie limitée n'a 25 pas été utilisé pour un nombre ou un montant cumulé de transactions. Conformément à l'invention, si le critère d'utilisation du code statique à durée de vie limitée n'est pas satisfait, par exemple parce que la date limite d'utilisation de ce code est dépassée, la transaction ne peut être permise que si le code de sécurité compris dans les données de 30 transaction correspond à un code dynamique de sécurité calculé par le serveur de vérification de code de sécurité pour cette transaction. Dans un mode particulier de réalisation de l'invention, le serveur de vérification de code dynamique de sécurité comporte en outre un module de communication apte à envoyer à un serveur, et ce uniquement si le 35 résultat de la comparaison est positif, lesdites données de transaction dans lesquelles ledit code de sécurité est remplacé par un code statique 3 0 3 84 1 9 4 de sécurité associé audit dispositif, ce serveur étant configuré pour vérifier la validité dudit code statique de sécurité pour autoriser ou refuser ladite transaction. Ainsi, dans ce mode de réalisation, l'invention propose de vérifier la 5 validité du code de sécurité de la transaction en amont du serveur configuré pour autoriser ou refuser la transaction, et lorsque la validité du code de la transaction est vérifiée de substituer ce code de sécurité par un code statique de sécurité pour que celui-ci soit vérifié par ce serveur. Ce code statique est le code constant associé au dispositif dès 10 l'origine et normalement prévu pour être associé à vie au dispositif. Dans le cas d'une carte bancaire, ce code statique peut en particulier être imprimé sur la carte. 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 15 dynamiques de sécurité ni les codes statiques de sécurité à durée de vie limitée. 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é ou du code statique de sécurité à durée de 20 vie limitée 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. 25 Dans un mode particulier de réalisation, le serveur de vérification de code de sécurité conforme à l'invention est configuré pour envoyer un message de refus de la transaction à un serveur apte à réaliser la transaction si les premier et deuxième codes dynamiques sont différents. Ainsi, dans ce mode de réalisation, le serveur configuré pour vérifier 30 la validité du code statique de sécurité pour autoriser ou refuser la transaction, le serveur bancaire par exemple, n'est pas sollicité. L'invention vise aussi un système de vérification d'un code de sécurité comportant : - un serveur de vérification de code de sécurité tel que mentionné 35 ci-dessus; et 303 8 4 1 9 5 - un serveur de gestion de la sécurisation configuré pour générer ledit code statique de sécurité à durée de vie limitée et envoyer ce code au titulaire dudit dispositif et au serveur de vérification de code de sécurité. 5 Le titulaire du dispositif, par exemple de la carte bancaire peut contacter ce dispositif lorsqu'il souhaite prêter temporairement sa carte à un tiers. Dans un mode particulier de réalisation, le serveur de gestion de la sécurisation génère le code statique de sécurité à durée de vie limitée à 10 partir de règles de calcul propres au titulaire du dispositif. Dans un mode particulier de réalisation, le système selon l'invention comporte : - une carte à microcircuit comportant, un code statique de sécurité et un écran pour afficher un code dynamique de sécurité généré par ladite carte pour réaliser une transaction ; - le serveur de vérification de code dynamique de sécurité selon l'invention étant apte à vérifier la validité du code statique de sécurité à durée de vie limitée de ladite carte et celle du code dynamique de sécurité généré par ladite carte. Dans un mode de réalisation, ce système comporte: - un terminal permettant à un utilisateur de se connecter à un serveur pour réaliser la transaction, ce terminal comportant une interface homme-machine permettant à l'utilisateur de saisir les données de la transaction dont ledit code dynamique de sécurité généré par la carte pour cette transaction ; - le serveur pour réaliser la transaction étant apte à transmettre ces données de transaction au serveur de vérification de code dynamique de sécurité selon le protocole ISO 8583 et à recevoir selon ce protocole un message d'autorisation de ladite transaction en provenance de ce serveur. Dans un mode particulier de réalisation, les différentes étapes du procédé de vérification d'un code dynamique de sécurité selon le premier aspect ou le deuxième aspect de l'invention sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur 35 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 3038419 6 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 5 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 10 ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, RAM, PROM, EPROM, 15 CD ROM, DVD ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier 20 téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. 25 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 : 30 - la figure 1 représente un dispositif permettant d'effectuer des transactions, en l'espèce une carte à microcircuit ; - la figure 2 représente un premier système de vérification de code de sécurité conforme à mode de réalisation de l'invention ; - la figure 3 représente sous forme d'organigramme les principales 35 étapes d'un procédé de vérification de code de dynamique de sécurité conforme à mode de réalisation de l'invention ; 303 8 4 1 9 7 - 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; 5 - 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 ; 10 - la figure 9 représente une table pouvant être utilisée par un serveur de vérification de code dynamique de sécurité ; - la figure 10 représente sous forme d'organigramme des étapes mises en oeuvre par un serveur de vérification de code dynamique de sécurité qui utilise la table de la figure 9 ; 15 - la figure 11 représente une autre table pouvant être utilisée par 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. 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 la 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 interface à contacts 1300. La carte à microcircuit 1000 est par exemple au 303 8 4 1 9 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. 3038419 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. Le serveur 5000 de vérification de code dynamique de sécurité est 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 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 DT comportant, le numéro de compte bancaire PAN, la date d'expiration EXP de la carte et un code de sécurité associé à cet identifiant pour réaliser une transaction ; 25 - ledit module de communication 5200 étant apte à recevoir un code statique de sécurité CVV* à durée de vie limitée généré par le serveur 7000 de gestion de la sécurisation pour ledit identifiant PAN ; - 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 30 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 génération d'un deuxième code dynamique de sécurité DCCV2 pour cette transaction en ligne en utilisant le numéro de compte bancaire PAN, une fonction cryptographique secrète et une 35 donnée temporelle ; 3038419 10 - un module 5400 de comparaison configuré pour déterminer que le résultat de ladite comparaison est positif si et seulement si le code de sécurité compris dans les données de transaction bancaires correspond au code dynamique de sécurité DCCV2 ou au code statique de sécurité à 5 durée de vie limitée 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. Dans le mode de réalisation décrit ici, lorsque le résultat de l'étape de comparaison est positif, le serveur 5000 envoie, au serveur bancaire 10 6000, les 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 un mode de réalisation décrit ici, 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 25 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. 30 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. 35 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 303 8 4 1 9 11 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 5 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 10 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. En référence à la figure 12, ce code statique de sécurité CVV* à 15 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 vérification de code dynamique de sécurité obtient l'information TL de 20 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 7000. 25 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 dans les données de transactions est identique à ce code (étape H50). 30 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 - transmet les données de transaction au serveur bancaire 6000 35 après avoir remplacé le code dynamique de sécurité CS par avec le code statique de sécurité CVV de la carte 1000. 303 8 4 1 9 12 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 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 5 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é CW* à durée de vie limitée, et si ce n'est pas le cas, à l'étape H70 si si le code de sécurité CS correspond au code dynamique de sécurité DCCV2 10 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. Sinon, le serveur 5000 de vérification du code de sécurité 15 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(CW) avec un code de sécurité statique C\N faux pour déclencher le refus de la 20 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 transactions ou un montant maximum de transactions. 25 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 données de transaction DT(DCCV1) comportant: 30 - 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. Ces données de transaction DT(DCCV1) sont transmises par le site 35 marchand 3000 au serveur 5000 de vérification, dans une requête 303 8 4 1 9 13 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 1S08583 n'est obligatoire ni pour les communications entrantes ni pour les communications sortantes du 5 serveur 5000; un autre format peut être utilisé. Le serveur 5000 étant est sollicité pour vérifier une transaction, le procédé se poursuit à partir de l'étape H30 déjà décrite. Le module 6100 d'authentification et de sécurisation des transactions du serveur bancaire 6000 vérifie les données de transaction 10 DT(CVV) reçues du serveur de vérification 5000 au cours d'une étape H60 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 qui délivre les biens ou services correspondants à l'utilisateur. 15 Si le serveur bancaire 6000 refuse la transaction, il envoie un message de refus de transaction au serveur du site marchand 3000. 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. 20 Description détaillée d'un deuxième mode de réalisation de l'invention La figure 4 représente un système 10 de vérification de code de sécurité comportant : 25 - un serveur 5000 de vérification de code dynamique de sécurité et un serveur bancaire 6000 tels que décrits précédemment en référence aux figures 2 et 3 ; et - un module d'interface 5500 conforme à l'invention. Ce module d'interface 5500 est apte à recevoir des données de 30 transaction DT d'un serveur de site marchand 3000 comportant soit un code statique de sécurité CVV, soit un code de sécurité statique à durée de vie limitée CVV*, soit un code dynamique de sécurité DCVVi, et à décider du traitement de ces données de transaction en fonction du type du code de sécurité. 35 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 303 8 4 1 9 14 dans les données de transaction DT est un code statique de sécurité CVV, un code statique de sécurité à durée de vie limitée CVV*, ou un code dynamique de sécurité DCVVi ; et - Si le code est un code dynamique de sécurité ou un code statique 5 de sécurité à durée de vie limitée CVV*, le module 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 vérifie le code dynamique de sécurité DCCV1 et transmette les données de transaction DT(CVV) comportant le code statique de sécurité CVV au serveur 6000; 10 - Si le code est un code 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 précédemment. Description détaillée d'un troisième et d'un quatrième modes de 15 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 20 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. 25 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 30 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. 35 Description détaillée d'un cinquième mode de réalisation de l'invention 303 8 4 1 9 15 Dans le mode de réalisation décrit précédemment, lorsque le serveur 5000 de vérification de code dynamique de sécurité détermine que le résultat de l'étape de comparaison est positif, il envoie les données 5 de transaction au serveur bancaire 6000 en remplaçant le code de sécurité présent dans la transaction par le code statique de sécurité CVV pour vérification de ce code par le serveur bancaire 6000. Dans un cinquième mode de réalisation de l'invention représenté en référence à la figure 8 dans lequel il n'est pas nécessaire d'impliquer le 10 serveur bancaire 6000, le serveur 5000 envoie directement un message d'autorisation au serveur du site marchand 3000 au cours d'une étape E46 pour que celui-ci délivre les biens ou services correspondants à l'utilisateur. 15 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 5000 de vérification de code dynamique de sécurité est également apte à vérifier le code statique de sécurité CVV associé à un compte bancaire 20 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 au moins un 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é 25 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 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 9 16 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 septiè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 3038419 17 - 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 les comptes bancaires PAN concernés. 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 9 18 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. 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 10 dynamique de sécurité peut être ou non associé à un module d'interface 5500, chacune des entités 5000 et 5500 pouvant éventuellement être implémentée dans le serveur bancaire 6000. Variantes possibles communes à tous les modes de réalisation 15 L'invention a été décrite ci-dessus dans le contexte particulier d'une application de paiement en ligne. Elle peut s'appliquer : - pour d'autres applications financières ; mais aussi - dans d'autres dès lors qu'il s'agit de vérifier un code de sécurité 20 saisi par un utilisateur par exemple pour vérifier un numéro de document d'identification d'identité, un identifiant de sécurité sociale, un code d'ouverture de porte, un code d'accès à un site Web. Dans les modes de réalisation décrits précédemment, la génération 25 du code dynamique de sécurité DCVV1 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 permettre la comparaison de ces codes. En pratique, pour palier à ces problèmes de synchronisation, le serveur peut générer plusieurs 30 deuxièmes codes de sécurité en utilisant différents paramètres temporels, une transaction étant autorisée dès lors que l'un de ces deuxièmes codes de sécurité correspond au code dynamique de sécurité reçu de la carte à microcircuit. 35 En variante, le paramètre temporel peut être remplacé par un compteur incrémenté : 303 84 1 9 19 - du côté de la carte à microcircuit 1000 à chaque fois la carte génère un nouveau code dynamique de sécurité, par exemple lorsque l'utilisateur appuie sur le bouton poussoir 1400 ; et - du côté du serveur 5000 de vérification de code dynamique de 5 sécurité à chaque fois que celui-ci génère de son côté un code dynamique de sécurité pour vérifier la validité d'un code dynamique de sécurité généré par la carte à microcircuit 1000. Là encore, l'homme du métier comprendra que ces compteurs doivent être synchronisés pour permettre la comparaison de ces codes. En 10 pratique, pour palier à ces problèmes de synchronisation, le serveur peut générer plusieurs deuxièmes codes de sécurité en utilisant différentes valeurs de compteur, une transaction étant autorisée dès lors que l'un de ces deuxièmes codes de sécurité correspond au code dynamique de sécurité reçu de la carte à microcircuit. 15 Références : [REFAA] : Demande de brevet européen n° EP 2 568 448 publiée le 13 mars 2013 pour une « carte de crédit ou de débit avec un code de sécurité ». 20 [REFCVV] : en .wi ki pedia .org/wi ki/ca rd_secu rity_code [REFPAN] : en .wikipedia .org/wiki/Bank_card_number REVENDICATIONS1. Serveur (5000) de vérification de code de sécurité comporte : - un module (5200) de communication apte à recevoir des données 5 de transaction (DT) comportant un identifiant (PAN) et un code de sécurité (ON, DCCV1) associé à un dispositif (1000) associé à cet identifiant pour réaliser une transaction ; - un module (5300) configuré pour générer un code dynamique de sécurité (DCCV2) à partir dudit identifiant (PAN) et d'une donnée 10 temporelle ou d'un compteur du nombre de deuxièmes codes dynamiques de sécurité (DCCV2) générés par ledit module (5300) pour ledit identifiant (PAN) ; - un module (5400) de comparaison configuré pour déterminer que le résultat de ladite comparaison est positif si et seulement si ledit code de 15 sécurité (CVV, DCCV1) correspond audit code dynamique de sécurité (DCCV2) ou à un code statique de sécurité (CVV*) à durée de vie limitée généré par un serveur (7000) de gestion de la sécurisation pour ledit identifiant (PAN) ; - ledit serveur (5000) étant configuré pour permettre ou interdire 20 directement ou indirectement la réalisation de ladite transaction en fonction du résultat de ladite comparaison. 2. Serveur (5000) de vérification de code selon la revendication 1 caractérisé en ce qu'il comporte une table (5600) qui associe audit 25 identifiant (PAN) : - ledit un code statique de sécurité (CVV*) à durée de vie limitée généré par ledit serveur (7000) de gestion de la sécurisation pour ledit identifiant (PAN) ; et - un critère (TL) d'utilisation dudit code statique de sécurité (CVV*) 30 à durée de vie limitée. 3. Serveur (5000) de vérification de code de sécurité selon la revendication 2, dans lequel ledit critère (TL) d'utilisation est constituée par : 35 - une date limite d'utilisation dudit code statique de sécurité à durée de vie limitée (CVV*) ; 3038419 21 - le fait que ledit code statique de sécurité à durée de vie limitée (CVV*) n'a pas été utilisé pour un nombre ou un montant cumulé de transactions. 4. 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 à 3; et - un serveur (7000) de gestion de la sécurisation configuré pour générer ledit code statique de sécurité (CVV*) à durée de vie limitée et envoyer ce code au titulaire dudit dispositif (1000) et audit serveur (5000) de vérification de code de sécurité. 5. Système de vérification d'un code de sécurité selon la revendication 4, caractérisé en ce que ledit serveur (7000) de gestion de la sécurisation génère ledit code statique de sécurité (CVV*) à durée de vie limitée à partir de règles de calcul propres audit titulaire. 6. Système selon l'une quelconque des revendications 4 ou 5 caractérisé en ce que ledit serveur (7000) de gestion de la sécurisation 20 génère le code statique de sécurité (CVV*) à durée de vie limitée au moyen d'une clef cryptographique. 7. Système selon l'une quelconque des revendications 4 à 6caractérisé en ce qu'il comporte : 25 - une carte à microcircuit (1000) comportant, un code statique de sécurité (CVV) 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é du code statique de sécurité à durée de vie 30 limitée (CVV*) de ladite carte et celle dudit code dynamique de sécurité (DCCV1) généré par ladite carte. 8. Système selon la revendication 7 caractérisé en ce qu'il comporte : 35 - un terminal (2000) permettant à un utilisateur de se connecter à un serveur (3000) pour réaliser ladite transaction, ledit terminal (2000) 3038419 22 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 à 5 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). 10 9. Système selon la revendication 8 caractérisé en ce que ledit serveur (7000) de gestion de la sécurisation communique ledit code statique de sécurité (CVV*) à durée de vie limitée au détenteur de la carte à microcircuit 1000, par exemple par un serveur vocal, par SMS, par email ou via une interface Web de ce serveur 7000 affichée sur un écran du 15 terminal (2000). 10. Système selon la revendication 9 dans lequel ledit terminal (2000) possède un module apte à communiquer le code statique de sécurité (CVV*) à durée de vie limitée à des moyens de communication à champ proche de la carte à microcircuit (1000), ledit (code CVV*) étant affiché sur un écran (1100) de la carte. 11. Procédé de vérification de code de sécurité comportant : - une étape (E20) de réception de données de transaction (DT) 25 comportant un identifiant (PAN) et un code de sécurité (CVV, DCCV1) associé à un dispositif (1000) associé à cet identifiant pour réaliser une transaction ; - une étape (E30) de génération d'un code dynamique de sécurité (DCCV2) à partir dudit identifiant (PAN) et d'une donnée temporelle ou 30 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 (H50, H70) de comparaison dont le résultat est positif si et seulement si ledit code de sécurité (CVV, DCCV1) correspond audit code dynamique de sécurité (DCCV2) ou à un code statique de sécurité 35 (CVV*) à durée de vie limitée généré par un serveur (7000) de gestion de la sécurisation pour ledit identifiant (PAN) ; 3 0 3 84 1 9 23 - 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.