Brevet FR3029318A1 — publié le 20160603

Arrière-plan de l'invention L'invention se rapporte au domaine général de la sécurisation des opérations bancaires électroniques. Dans ce document la notion d'opération bancaire est à prendre au sens large. Elle vise toute transaction électronique faisant intervenir un compte bancaire, par exemple, un accès à un compte en ligne, un paiement en ligne... Aujourd'hui, pour certaines opérations bancaires effectuées en relation à une carte bancaire, il se peut que la banque du titulaire de cette carte mette en oeuvre une authentification du titulaire au moyen de son terminal mobile. Cette authentification peut consister à envoyer un SMS au mobile du titulaire, pour l'inviter à répondre ou à reboucler l'opération grâce à un code reçu dans le SMS. L'utilisateur du terminal mobile qui reçoit ce SMS doit ressaisir le code reçu ou une information correspondante, par exemple, par une page web associée à l'opération bancaire affichée sur un ordinateur, et le renvoyer à la banque pour donner son consentement à réaliser l'opération. Cette fonctionnalité assure la collusion entre le terminal mobile du porteur de la carte bancaire (information présente à la banque) et l'utilisateur du service en ligne. Cela signifie que l'utilisateur qui a saisi les informations de la carte bancaire en ligne est également en possession du mobile du porteur de la carte bancaire. Fort de ces informations, la banque peut estimer que la probabilité que l'utilisateur du service en ligne soit effectivement le porteur de la carte bancaire (son client) est grande et ainsi déléguer de la confiance dans l'opération en cours. Un problème est que le vol du terminal mobile du client et la connaissance des codes visés ci-dessus sont suffisants pour réaliser une transaction. Les inventeurs ont constaté que les solutions existantes n'assurent pas la collusion entre les trois éléments suivants : mobile-utilisateur-carte bancaire ; en ce sens que le serveur bancaire ne sait pas si l'utilisateur légitime, son terminal mobile, et sa carte bancaire sont dans un même espace et collaborent à la réalisation de la transaction. En effet, aujourd'hui la carte bancaire, bien qu'étant dotée d'un module de communication, ne participe pas à la transaction. Le serveur bancaire ne peut donc pas être assuré que le numéro de la carte saisi sur le terminal a été subtilisé et saisi par un tiers malveillant ou si c'est le porteur légitime de la carte qui a saisi le numéro de la carte sur le terminal. L'invention vient améliorer la situation. Objet et résumé de l'invention (voir les revendications à la fin) Plus particulièrement, et selon un premier aspect, l'invention concerne un procédé mis en oeuvre par un terminal, ce procédé comportant : une étape d'obtention d'au moins une information pour la réalisation d'une opération bancaire associée à une carte bancaire et devant être effectuée par un serveur bancaire ; une étape d'envoi de l'information au serveur ; cette information étant obtenue de la carte bancaire par un module de communication courte distance du terminal. Corrélativement, l'invention vise un terminal comportant : un module d'obtention d'au moins une information pour la réalisation d'une opération bancaire associée à une carte bancaire et devant être effectuée par un serveur bancaire; un module d'envoi de l'information au serveur; le module d'obtention comporte un module de communication courte distance pour obtenir l'information de la carte bancaire. Selon un deuxième aspect, l'invention vise un procédé mis en oeuvre par un serveur bancaire comportant : une étape de réception, en provenance d'un terminal, d'une information fournie à ce terminal par une carte bancaire; une étape de vérification de la validité de l'information ; et une étape d'autorisation ou d'interdiction d'une opération bancaire associée à la carte bancaire et devant être effectuée par le serveur en fonction du résultat de la vérification. Corrélativement, l'invention vise un serveur bancaire comportant : - un module de réception, en provenance d'un terminal, d'une information fournie à ce terminal par une carte bancaire; un module de vérification de la validité de l'information ; et un module d'autorisation ou d'interdiction d'une opération bancaire associée à la carte bancaire et devant être effectuée par le serveur en fonction du résultat de la vérification. Selon un troisième aspect, l'invention vise un procédé mis en oeuvre sur une carte bancaire apte à communiquer avec un terminal, ce procédé comprenant les étapes suivantes : une étape de stockage d'une information connue d'un serveur bancaire ; et une étape de communication courte distance avec le terminal pour transmettre l'information à destination du terminal en vue d'un traitement par le serveur bancaire lors d'une opération bancaire. Corrélativement, l'invention vise une carte bancaire apte à communiquer avec un terminal, comportant : un module de stockage d'une information connue d'un serveur bancaire ; et un module de communication courte distance avec le terminal apte à transmettre l'information à destination du terminal en vue d'un traitement par le serveur bancaire lors d'une opération bancaire. Ainsi, et d'une façon générale, l'invention propose d'intégrer la carte bancaire dans le mécanisme de sécurisation et se distingue donc avantageusement de l'art antérieur en ce qu'elle accroît la sécurité des opérations bancaires par une « collusion mobile-porteur-carte », le serveur bancaire pouvant vérifier si le porteur (ou utilisateur) de la carte et du terminal (téléphone mobile, tablette tactile, ordinateur personnel...) donne son consentement à l'opération en les rapprochant l'un de l'autre. En effet, si le terminal ou la carte bancaire sont volés, ils ne le sont que très rarement de façon concomitante. En d'autres mots, la solution proposée contraint la carte bancaire et le terminal à être dans un même espace, une même zone géographique. Conformément à l'invention, le terminal utilise une technique de communication courte distance pour obtenir une information générée par la carte bancaire. L'invention permet ainsi au serveur bancaire qui reçoit cette information du terminal de s'assurer que l'utilisateur du terminal est à proximité de la carte bancaire. Cette proximité prouve que l'utilisateur du terminal est en procession de la carte bancaire. Dans un mode particulier de réalisation de l'invention, l'information est à durée de vie limitée. L'invention permet ainsi d'accroitre la sécurité de cette information en prouvant que la communication courte distance entre le terminal et la carte bancaire est effectuée dans une période assez courte. Dans un mode particulier de réalisation de l'invention, l'information est communiquée au terminal par la carte bancaire au moyen d'une communication sans contact. En variante, on pourrait utiliser un câble court, par exemple de quelques centimètres pour relier le terminal et un lecteur de carte dans laquelle est insérée la carte bancaire. Dans un mode particulier de réalisation de l'invention, l'information comporte un défi et un chiffré, par exemple une signature, calculé par la carte bancaire à partir de ce défi. Le serveur bancaire vérifie le chiffré calculé par la carte bancaire. On entend ici par « chiffré » le résultat d'un calcul, par exemple une cryptographie mettant en oeuvre un secret (clé de chiffrement privée ou publique) que possède la carte bancaire, que peut vérifier le serveur bancaire. Dans un mode particulier de réalisation de l'invention, l'information comporte une valeur choisie dans une liste de valeurs préalablement fournie par le serveur bancaire. De préférence, la carte bancaire supprime, chaque fois après l'envoi, cette valeur de la liste. Par conséquent, le serveur bancaire vérifie cette information en vérifiant si la valeur reçue du terminal est mémorisée. En variante, le serveur bancaire recalcule la valeur par une fonction mathématique du type fonction de hachage connue par l'homme du métier pour la carte bancaire. Dans un mode particulier de réalisation de l'invention et afin d'accroitre la sécurité du mécanisme, le terminal envoie au serveur bancaire au moins une information complémentaire, par exemple, le numéro de la carte, la valeur de vérification de la carte (CVV), la date d'expiration de la carte, etc. Dans un mode particulier de réalisation de l'invention, le terminal envoie au serveur un message d'instruction comportant une donnée d'authentification du terminal éventuellement accompagnée par un ordre pour effectuer l'opération bancaire. Par exemple, cet ordre consiste à demander au serveur d'autoriser un paiement électronique, un accès à une application dite de banque à domicile, etc. La donnée d'authentification est, par exemple, un code d'accès à la banque à domicile, un code confidentiel propre au titulaire de la carte, etc. La présente invention peut notamment être mise en oeuvre selon deux modes particulières. Dans un premier mode, l'invention est mise en oeuvre après que l'utilisateur ait initié une transaction et que le serveur ait envoyé au terminal une requête afin d'obtenir le consentement de l'utilisateur pour effectuer cette transaction. Dans ce mode de réalisation, le serveur authentifie le terminal avant d'autoriser l'opération bancaire. Ceci permet de sécuriser l'invention dans le cas peu probable d'un vol concomitant de la carte et du terminal. Dans ce premier mode de réalisation, le message d'instruction comporte l'information et est envoyé au serveur sur réception d'une requête du serveur, cette requête comportant au moins une caractéristique de l'opération bancaire reçue par le serveur d'une entité participant à l'opération. L'invention permet ainsi d'informer l'utilisateur du terminal d'au moins une caractéristique de l'opération. Cette caractéristique peut être, par exemple, un montant d'un paiement électronique, un numéro d'une transaction électronique, etc. Dans un deuxième mode, l'invention n'est pas mise en oeuvre sur réception d'une requête du serveur pour vérifier la volonté de l'utilisateur d'autoriser une opération particulière, mais spontanément par l'utilisateur. On présente ci-après deux modes de réalisation de ce deuxième mode. Dans une première variante du deuxième mode, le message d'instruction pour confirmer l'opération n'est pas envoyé par le terminal au serveur en même temps que l'information. Le serveur envoie donc au terminal un message d'invitation comportant une durée offerte à l'utilisateur du terminal pour confirmer l'opération. Le serveur effectue cette opération sur réception d'un message de confirmation reçu du terminal avant l'expiration de cette durée. L'invention permet ainsi d'accorder à l'utilisateur du terminal une durée limitée pour réaliser l'opération. Dans une deuxième variante du deuxième mode, le message d'instruction comporte l'information. Le serveur n'envoie pas de message d'invitation au terminal. Dans un mode particulier de réalisation de l'invention, le message d'instruction comporte au moins une caractéristique de l'opération bancaire. Cette caractéristique peut être, par exemple, un montant d'un paiement électronique, un numéro d'une transaction électronique, un montant de virement bancaire, etc. L'invention permet ainsi à l'utilisateur du terminal de saisir par lui-même les caractéristiques de l'opération. Dans ce mode particulier de réalisation de l'invention, le serveur bancaire vérifie au moins une caractéristique de l'opération du message d'instruction avant d'autoriser l'opération. Par exemple, cette caractéristique permet de vérifier si un virement de compte à compte est autorisé. Dans un mode particulier de réalisation de l'invention, la vérification par le serveur des caractéristiques de l'opération consiste à comparer au moins une caractéristique saisie par le porteur du terminal avec au moins une caractéristique du même type reçue d'une entité participant à l'opération. L'invention permet ainsi d'éliminer le risque de fraude dans lequel, par exemple, le commerçant falsifie le montant de la transaction. Dans un mode particulier de réalisation de l'invention, le terminal reçoit, en provenance du serveur bancaire, un acquittement positif indiquant l'accomplissement de l'opération. Les avantages et caractéristiques particuliers du terminal et du serveur selon l'invention sont identiques à ceux des procédés décrits ci-dessus et ne seront pas rappelés ici. Dans un mode particulier de réalisation, les différentes étapes des procédés sont déterminées par des instructions de programmes d'ordinateur. En conséquence, l'invention vise aussi des programmes d'ordinateur sur des supports d'informations, ces programmes étant susceptible d'être mis en oeuvre dans un ordinateur, ces programmes comportant des instructions adaptées à la mise en oeuvre des étapes par un terminal ou mise en oeuvre par un serveur tels que décrits ci-dessus. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi des supports d'information lisibles par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Les supports d'information peuvent être n'importe quel entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, les supports d'informations peuvent être des supports transmissibles tels qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet. Alternativement, les supports d'informations peuvent être des circuits intégrés dans lesquels les programmes sont incorporés, les circuits étant adaptés pour exécuter ou pour être utilisé dans l'exécution des procédés en question. Brève description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : - la figure 1 représente un serveur, un terminal et une carte bancaire conformes à un mode particulier de réalisation de l'invention; - la figure 2A représente, sous forme d'organigramme, les principales étapes d'un procédé mis en oeuvre par le terminal de la figure 1, les principales étapes d'un procédé mis en oeuvre par la carte bancaire de la figure 1 et les principales étapes d'un procédé mis en oeuvre par le serveur de la figure 1 dans un premier mode de réalisation de l'invention; et - les figures 2B et 2C représentent, sous forme d'organigramme, les principales étapes d'un procédé mis en oeuvre par le terminal de la figure 1, les principales étapes d'un procédé mis en oeuvre par la carte bancaire de la figure 1 et les principales étapes d'un procédé mis en oeuvre par le serveur de la figure 1 dans deux variantes particulières d'un deuxième mode de réalisation de l'invention. Description détaillée d'un mode de réalisation La figure 1 représente, dans un mode particulier de réalisation de l'invention, un terminal mobile TM, un serveur bancaire SB et une carte bancaire CB. La carte bancaire CB comporte un processeur 10, une mémoire vive de type RAM 12, une mémoire morte de type ROM 13 comportant un programme d'ordinateur PG1 et une mémoire non volatile réinscriptible 14 de type flash. Cette mémoire non volatile 14 peut comporter une information, par exemple, une information à durée de vie limitée IS. La carte bancaire CB comporte également un module de communication courte distance MCC constitués, dans cet exemple par un module de communication courte distance sans fil, à champ proche, de type NFC. Ce module de communication courte distance est adapté pour communiquer avec un module MCC correspondant d'un terminal mobile TM. Conformément à l'invention, la carte bancaire CB est apte à envoyer par son module de communication courte distance MCC l'information à durée de vie limitée IS au terminal mobile TM pour que celui-ci la transmette au serveur bancaire SB. Ce mécanisme permet au serveur bancaire SB de déterminer de façon certaine que le terminal mobile TM et la carte bancaire CB se trouvent alors à proximité l'un de l'autre, autrement dit en collusion. Par conséquent, l'information à durée de vie limitée IS, peut être d'un type quelconque, du moment qu'elle permet au serveur bancaire SB de s'assurer de la proximité de la carte bancaire CB légitime, par rapport au terminal mobile TM. Dans un mode de réalisation, l'information IS peut être un couple constitué par un défi et une signature sur ce défi calculée par le processeur 10 de la carte bancaire CB, le serveur bancaire SB ayant un module pour vérifier la validité de cette signature à partir du défi reçu de la carte CB en utilisant un algorithme similaire ou compatible avec celui de la carte bancaire CB utilisée pour générer la signature. En variante, l'information IS mémorisée par la carte bancaire CB peut être une valeur pseudo-dynamique générée par cette carte CB, le serveur bancaire SB étant apte à vérifier dans une table, si une telle valeur est associée à la carte bancaire CB. Le terminal mobile TM comporte, dans cet exemple, un processeur 100, une mémoire vive de type RAM 102, une mémoire morte de type ROM 103, un module de communication courte distance MCC compatibles avec celui de la carte bancaire CB et un module de communication général MCT, compatibles avec celui MCS du serveur bancaire SB. Dans un mode de réalisation décrit ici, la mémoire morte 104 comporte un programme d'ordinateur PG2 et une application APP permettant à l'utilisateur du terminal mobile TM de donner instruction au serveur bancaire SB d'effectuer une opération bancaire O. Cette application APP est embarquée sur le terminal mobile TM, pouvant être lancée systématiquement par une requête émise par le serveur SB ou lancée spontanément par l'utilisateur du terminal mobile TM. Le programme d'ordinateur PG2 sera décrit ultérieurement en référence aux figures 2A à 2C dans trois modes de réalisation différents de l'invention. Ce programme PG2 permet de mettre en oeuvre les instructions correspondant en particulier aux étapes E05 à E40 ou F20 à F40. Le serveur bancaire SB comporte, dans cet exemple, l'architecture matérielle d'un ordinateur. Il comporte notamment un processeur 200, une mémoire vive de type RAM 202 et une mémoire morte de type ROM 204 comportant un programme d'ordinateur PG3. Le programme d'ordinateur PG3 comporte des instructions pour mettre en oeuvre, notamment, les étapes référencées G03 à G60 en référence aux figures 2A à 2C. Le serveur bancaire SB comporte un module de communication général MCS compatible avec celui MCT du terminal mobile TM. Le serveur bancaire SB comporte également un module MVD apte à vérifier la validité de l'information à durée de vie variable IS reçue du terminal mobile TM, celui-ci l'ayant lui-même reçu d'un module de communication courte distance MCC de la carte bancaire CB. D'une façon générale, le serveur bancaire SB est apte à autoriser ou à interdire une opération bancaire 0 sur la base de la vérification de cette information IS. Il comporte à cet effet un module MAO pour obtenir le résultat de la vérification et autoriser ou interdire en conséquence de cette opération bancaire O. L'opération bancaire 0 peut être de différents types. Il peut s'agir en particulier de la consultation d'un compte bancaire associé à la carte bancaire CB par l'utilisateur du terminal mobile TM, via une interface de l'application APP. Il peut aussi s'agir d'une transaction, par exemple un achat que le serveur bancaire SB effectue en coopération avec une entité externe E par exemple un site marchand. Dans le mode de réalisation décrit ici, le serveur bancaire SB et cette entité E communiquent par les modules de communication généraux MCT, MC. En référence à la figure 2A, nous allons maintenant décrire les principales étapes d'un premier mode de réalisation de l'invention. On rappelle que, d'une façon générale, que l'invention permet au serveur bancaire SB, d'autoriser une opération bancaire 0, lorsqu'il sait que la carte bancaire CB de l'utilisateur est effectivement à proximité de son terminal mobile TM au moment où il reçoit du terminal mobile TM l'information à durée de vie limitée IS générée par la carte bancaire CB. Dans ce premier mode de réalisation de la figure 2A, l'utilisateur du terminal mobile TM reçoit une requête de la banque RQ1 avant d'approcher sa carte bancaire CB de son terminal mobile TM. Dans un deuxième mode de réalisation des figures 2B et 2C, au contraire, l'utilisateur approche son terminal mobile TM de la carte bancaire CB sans avoir reçu de requête du serveur bancaire SB. Dans le mode de la figure 2A, on suppose que le serveur bancaire SB demande à l'utilisateur de confirmer une opération bancaire O. Plus précisément, dans cet exemple, il s'agit d'une transaction entre le serveur bancaire SB et une entité E externe constituée par exemple par un site marchand. On suppose par exemple que l'utilisateur du terminal mobile TM utilise un ordinateur conventionnel muni d'un navigateur pour effectuer un achat auprès du site marchand E et que l'utilisateur souhaite effectuer un paiement comportant certaines caractéristiques (type d'article acheté, montant, ...). Au moment où l'utilisateur valide son achat, le site marchand E envoie au moins une caractéristique 101 de cette transaction 0, par exemple le prix (le montant de l'opération), au serveur bancaire SB, cette caractéristique 101 étant reçue par le serveur SB au cours d'une étape 25 G03. Au cours d'une étape G05, le serveur bancaire SB envoie une requête RQ1 au terminal mobile TM de l'utilisateur, cette requête RQ1 comportant la caractéristique 101 de la transaction 0 et, de façon implicite ou explicite une demande pour qu'une information à durée de vie limitée IS générée par la carte bancaire CB de l'utilisateur lui soit communiquée. 30 Cette requête RQ1 est reçue par le terminal mobile TM au cours d'une étape E05. Dans le scénario décrit ici, un message s'affiche sur l'écran du terminal mobile TM invitant l'utilisateur à approcher sa carte bancaire CB de son terminal mobile TM. De façon connue, il s'établit une communication courte distance entre les moyens MCC du terminal mobile TM et de la carte bancaire CB. Un protocole est défini entre la carte bancaire 35 CB et le terminal mobile TM par lequel le terminal mobile TM demande (étape E10) une information à durée de vie limitée IS à la carte bancaire CB, la carte bancaire CB renvoyant cette information IS au terminal mobile TM au cours d'une étape E15. Cet échange entre le terminal mobile TM et la carte bancaire CB peut être déclenché automatiquement dès lors que le terminal mobile TM reçoit la requête RQ1 envoyée par le serveur bancaire SB. Nous supposerons, dans cet exemple, que l'information à durée de vie limitée IS est constituée par un couple comportant un défi généré par la carte bancaire CB et une signature de ce défi. Lorsque le terminal mobile TM reçoit ce couple, il envoie, au serveur bancaire SB, au cours d'une étape E20, un message d'instruction RP1 en réponse à la requête RQ1, cette réponse comportant l'information à durée de vie limitée IS, un ordre ICO pour autoriser le serveur bancaire SB à effectuer le paiement et dans cet exemple une donnée d'authentification IA du terminal mobile TM. Ce message d'instruction RP1 est reçue par le serveur bancaire SB, au cours d'une étape G10. Au cours d'une étape G20, le serveur bancaire SB vérifie la validité de l'information à durée de vie limitée IS. Cette vérification consiste, dans cet exemple, à calculer une signature du défi reçu du terminal mobile TM, et à vérifier que cette signature correspond effectivement à celle calculée par la carte bancaire CB et reçue du terminal mobile TM. Dans le mode de réalisation décrit ici, le serveur bancaire SB authentifie le terminal mobile TM grâce aux données IA. Nous supposerons que cette vérification et cette authentification sont positives et que le serveur bancaire SB envoie, au cours d'une étape G45, un message à l'entité E pour valider le paiement. Dans le mode de réalisation décrit ici, le serveur bancaire SB envoie au cours d'une étape G60, un acquittement positif au terminal mobile TM, cet acquittement AP étant reçu par le terminal mobile TM au cours d'une étape E30, afin que l'utilisateur du terminal mobile TM prenne connaissance de la réalisation effective de la transaction O. Dans le mode de réalisation décrit ici, le terminal mobile TM génère une alerte au cours d'une étape E40 lorsqu'il reçoit cet acquittement positif AP. Nous allons maintenant décrire une première variante du deuxième mode de réalisation de l'invention en référence à la figure 2B. Dans cet exemple, et contrairement au premier mode de la figure 2A, l'opération de rapprochement du terminal mobile TM et de la carte CB s'effectue sans que le terminal mobile TM ne reçoive une demande de de confirmation de transaction du serveur bancaire SB. Ainsi, au cours d'une étape E10, l'utilisateur rapproche sa carte bancaire CB du terminal mobile TM, une communication courte distance se met en place de sorte que la carte bancaire CB envoie une information à durée de vie limitée IS au terminal mobile TM. Dans cet exemple, cette information à durée de vie limitée IS est une valeur pseudo- dynamique générée par la carte bancaire CB. Dans le mode de réalisation décrit ici, sur réception de cette information IS (étape E15 déjà décrite), le terminal mobile TM communique cette information IS à la banque SB au cours d'une étape F20. On remarque, que cette information à durée de vie limitée IS n'est pas accompagnée, dans cet exemple d'une caractéristique de transaction. Cette information IS est reçue par le serveur bancaire au cours d'une étape G11. Au cours de l'étape G20 déjà décrite, le serveur bancaire SB vérifie la validité de cette information IS. Dans cet exemple, la vérification consiste à rechercher, dans une table du serveur bancaire SB, la présence de la valeur générée par la carte bancaire CB en association avec un identifiant de la carte CB ou du terminal mobile TM. Dans ce mode de réalisation, après avoir vérifié la validité de l'information à durée de vie limitée IS, le serveur bancaire SB envoie, au cours d'une étape G30, un message d'invitation M au terminal mobile TM pour lui indiquer que l'utilisateur peut déclencher une transaction 0 pendant une période T donnée. Cette période T n'est en aucun cas corrélée à la durée de vie de l'information IS. Ce message M est reçu par le terminal mobile TM au cours d'une étape F30. Nous supposerons, là encore, que l'utilisateur effectue un paiement auprès d'un site marchand E, et que le serveur bancaire SB reçoit de ce site E, un montant I01 de transaction. Dans cet exemple, il n'y a pas de requête particulière envoyée par le serveur bancaire SB au terminal mobile TM lorsque le serveur bancaire SB reçoit ce montant 101 de transaction du site marchand E. L'utilisateur ayant reçu, au cours de l'étape F30, un message d'invitation M lui indiquant qu'il peut effectuer une opération pendant une période T, nous supposerons, dans cet exemple, que l'utilisateur utilise l'application APP de son terminal mobile TM pour envoyer, au serveur bancaire SB, un message d'instruction RQ2 comportant un montant de transaction 102, et un ordre ICO pour autoriser le serveur bancaire SB à effectuer le paiement pour ce montant. Dans l'exemple de réalisation décrit ici, ce message d'instruction RQ2 comporte en outre des données d'identification IA du terminal mobile TM. Au cours d'une étape G50, le serveur bancaire SB vérifie que le message RQ2 a été reçu dans la durée T comptée à partir de l'émission du message d'invitation M. Si c'est le cas, le serveur bancaire SB vérifie également d'une part l'authentification du terminal mobile TM et d'autre part que le montant 102 saisi sur le clavier du terminal mobile TM correspond effectivement au montant 101 reçue du site marchand E. Si cette vérification s'avère positive, le serveur SB envoie, au cours d'une étape G45, un message OK au site marchand E pour autoriser la transaction. Comme dans le scénario de la figure 2A, nous supposerons que le serveur bancaire SB envoie (étape E60) un acquittement positif AP au terminal mobile TM et que celui-ci génère une alerte pour l'utilisateur. Dans le scénario de la figure 2C conforme lui à une deuxième variante du deuxième mode de l'invention, nous supposerons cette fois que l'opération bancaire 0 correspond à la consultation du compte bancaire de l'utilisateur sur le serveur bancaire SB lui-même. Conformément à l'invention, lorsque l'utilisateur souhaite consulter son compte, il approche sa carte bancaire CB de son terminal mobile TM et une communication courte distance s'établit, une information à durée de vie limitée IS générée par la carte bancaire CB est transmise au serveur bancaire SB, de sorte que celui-ci peut garantir que l'utilisateur du terminal mobile TM était en possession de sa carte bancaire CB au moment de cette opération. Dans ce scénario, une fois que le terminal mobile TM reçoit l'information à durée de vie limitée IS (étape E15), il envoie un message d'instruction RQ2 au serveur bancaire SB (étape F40), ce message d'instruction RQ2 comportant l'information à durée de vie limitée IS, une caractéristique d'opération 102 correspondant à un numéro de compte en banque de l'utilisateur, un ordre ICO pour exécuter cette opération et dans cet exemple, une donnée d'authentification 1A du terminal mobile TM. Au cours d'une étape G20, le serveur bancaire SB vérifie la donnée d'authentification IA du terminal mobile TM, la validité de l'information à durée de vie limitée IS, et si ces vérifications sont positives, permet la consultation du compte bancaire conformément à la caractéristique d'opération 102. REVENDICATIONS1. Procédé mis en oeuvre par un terminal (TM) comportant : - une étape (E10) d'obtention d'au moins une information (IS) pour la réalisation d'une opération bancaire (0) associée à une carte bancaire (CB) et devant être effectuée par un serveur bancaire (SB); - une étape (E20, F20) d'envoi de ladite information (IS) audit serveur ; ce procédé étant caractérisé en ce que ladite au moins une information (IS) est obtenue de ladite carte bancaire (CB) par un module (MCC) de communication courte distance dudit terminal (TM). 2. Procédé selon la revendication 1, caractérisé en ce que ladite étape (E10) d'obtention est effectuée par un module (MCC) de communication sans contact. 3. Procédé selon la revendication 2, caractérisé en ce que ladite au moins une information (IS) comporte un défi et un chiffré calculé par ladite carte (CB) à partir de ce défi. 4. Procédé selon la revendication 2 ou 3, caractérisé en ce que ladite au moins une information (IS) comporte une valeur choisie par ladite carte (CB) dans une liste de valeurs préalablement fournie par ledit serveur bancaire (SB). 5. Procédé mis en oeuvre par un serveur bancaire (SB), caractérisé en ce qu'il comporte : - une étape (G10) de réception, en provenance d'un terminal (TM), d'une information (IS) fournie audit terminal (TM) par une carte bancaire (CB); - une étape (G20) de vérification de la validité de ladite information (IS) ; et - une étape (G25) d'autorisation ou d'interdiction d'une opération bancaire (0) associée à ladite carte bancaire (CB) et devant être effectuée par ledit serveur (SB) en fonction du résultat de ladite étape (G20) de vérification. 6. Procédé selon la revendication 5, caractérisé en ce que ladite information (IS) comporte un défi et un chiffré dudit défi calculé par ladite carte (CB) et en ce que ladite étape (G20) de vérification comporte la vérification dudit chiffré. 7. Procédé selon la revendication 5, caractérisé en ce que ladite information (IS) comporte une valeur choisie par ladite carte (CB) dans une liste de valeurs préalablement fournie par ledit serveur (SB) ; et en ce que ladite étape (G20) de vérification comporte une étape consistant à vérifier si ladite valeur est mémorisée pour ladite carte par ledit serveur (SB). 8. Procédé mis en oeuvre sur une carte bancaire (CB) apte à communiquer avec un terminal (TM), caractérisé en ce qu'il comprend les étapes suivantes : une étape de stockage d'une information (IS) connue d'un serveur bancaire (SB), une étape de communication courte distance avec ledit terminal (TM) pour transmettre l'information (IS) à destination dudit terminal (TM) en vue d'un traitement par ledit serveur bancaire (SB) lors d'une opération bancaire. 9. Terminal (TM) comportant : - un module (MCT) d'obtention d'au moins une information (IS) pour la réalisation d'une opération bancaire (0) associée à une carte bancaire (CB) et devant être effectuée par un serveur bancaire (SB); et un module (MCT) d'envoi de ladite information (IS) audit serveur (SB); ce terminal (TM) étant caractérisé en ce qu'il comporte un module (MCC) de communication courte distance pour obtenir ladite au moins une information (IS) de ladite carte bancaire (CB). 10. Serveur bancaire (SB) comportant : - un module (MCS) de de réception, en provenance d'un terminal (TM), d'une information (IS) fournie audit terminal (TM) par une carte bancaire (CB); et - un module (MVD) de vérification de la validité de ladite information (IS) ; - un module (MAO) d'autorisation ou d'interdiction d'une opération bancaire (OB) associée à ladite carte bancaire (CB) devant être effectuée par ledit serveur (SB) en fonction du résultat de ladite étape (G20) de vérification. 11. Carte bancaire (CB) apte à communiquer avec un terminal (TM), comportant : - un module (14) de stockage d'une information (IS) connue d'un serveur bancaire (SB), - un module (MCC) de communication courte distance avec ledit terminal (TM) apte à transmettre l'information (IS) à destination dudit terminal (TM) en vue d'un traitement par dudit serveur bancaire (SB) lors d'une opération bancaire. 12. Programme d'ordinateur (PG2) comportant des instructions pour l'exécution des étapes du procédé mis en oeuvre par un terminal (TM) selon l'une quelconque des revendications 1 à 4, lorsque ledit programme est exécuté par un processeur. 13. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur (PG2) comprenant des instructions pour l'exécution des étapes du procédé mis en oeuvre par un terminal (TM) selon l'une quelconque des revendications 1 à 4. 14. Programme d'ordinateur (PG3) comportant des instructions pour l'exécution des étapes du procédé mis en oeuvre par un serveur bancaire (SB) selon l'une quelconque des revendications 5 à 7, lorsque ledit programme est exécuté par un processeur. 15. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur (PG3) comprenant des instructions pour l'exécution des étapes du procédé mis en oeuvre par un serveur bancaire (SB) selon l'une quelconque des revendications 5 à 7. 16. Programme d'ordinateur (PG1) comportant des instructions pour l'exécution des étapes du procédé mis en oeuvre par une carte bancaire (CB) selon la revendication 8, lorsque ledit programme est exécuté par un processeur. 17. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur (PG1) comprenant des instructions pour l'exécution des étapes du procédé mis en oeuvre par une carte bancaire (CB) selon la revendication 8.