Brevet FR3091395A1 — publié le 20200703

Description Titre de l'invention : PROCÉDÉ ET DISPOSITIF POUR DES PAIEMENTS PUSH SÉCURISÉS Domaine technique [0001] La présente description concerne de façon générale le domaine des paiements, et en particulier des procédés et des dispositifs pour effectuer des paiements du type "push", connus aussi sous le nom de paiements initiés par le payeur. Technique antérieure [0002] Dans un environnement de paiement par carte, un paiement est initié par l'authentification du détenteur de la carte au niveau du point de vente. On utilise un acquéreur pour lancer une demande d'autorisation de paiement, demande qui est envoyée à l'émetteur de la carte. L'émetteur de la carte décide du résultat de la transaction (autorisation). La position de l'acquéreur rend difficile une fraude initiée par le commerçant, puisque les commerçants malveillants peuvent être bloqués et éjectés du système au début du processus d'autorisation. En outre, les informations du compte du commerçant sont gérées par l'acquéreur, qui est aussi en charge du règlement des fonds sur la base des comptes tenus dans son système, rendant ici encore la fraude plus difficile. [0003] Les paiements sans carte correspondant à des transferts bancaires rapides entre comptes offrent une alternative aux paiements par carte. Le SEPA (de l'anglais Single Euro Payments Area - Région Unique de Paiement en Euros) est une initiative d'intégration de paiements de l'Union Européenne visant à simplifier les transferts bancaires entre comptes en euros. Les transferts SEPA sont basés sur un numéro IBAN (de l'anglais International Bank Account Number - Numéro de Compte Bancaire International) identifiant le compte bénéficiaire. Deux schémas de transfert par virement SEPA ont été proposés, connus sous le nom de SCT (SEPA Credit Transfer - Virement SEPA) et SCT Inst (SEPA Instant Credit Transfer - Virement SEPA Instantané). Le schéma de paiement SCT assure des transferts relativement rapides, alors que le schéma SCT Inst promet un virement instantané d'un compte vers un autre, généralement en moins de 10 secondes, ou avec un maximum de 20 secondes dans des circonstances exceptionnelles. [0004] Toutefois, il y a une difficulté technique pour garantir la sécurité des paiements dans le cas de paiements initiés par le payeur sur la base de transferts SEPA ou d'autres types de paiement push. Résumé de l'invention [0005] Un objet de modes de réalisation de la présente description est de répondre au moins 2 partiellement à un ou plusieurs besoins dc l'art antérieur. [0006] Selon un premier aspect, on prévoit un procédé pour effectuer un paiement push initié par un payeur vers un compte bancaire de bénéficiaire, comprenant : recevoir, par un premier serveur à partir d'un deuxième serveur associé à un bénéficiaire, des attributs de bénéficiaire comprenant au moins un numéro dc compte du compte bancaire de bénéficiaire, et une signature d'attributs de bénéficiaire ; vérifier, par le premier serveur, la signature d'attributs de bénéficiaire sur la base des attributs de bénéficiaire reçus du deuxième serveur ; et lancer, par le premier serveur, le paiement push vers le compte bancaire de bénéficiaire si la vérification de la signature d'attributs de bénéficiaire a réussi. [0007] Selon un mode de réalisation, le lancement du paiement push par le premier serveur comprend la génération d'un message de lancement de paiement comprenant le numéro de compte du compte bancaire dc bénéficiaire. [0008] Selon un mode de réalisation, le procédé comprend en outre la génération, par un registre de bénéficiaires, de la signature d'attributs de bénéficiaire sur la base d'attributs de bénéficiaire fournis par un dispositif de bénéficiaire, et la mémorisation de la signature d'attributs dc bénéficiaire au niveau du deuxième serveur. [0009] Selon un mode de réalisation, la vérification dc la signature d'attributs de bénéficiaire comprend : générer, par le premier serveur, une autre signature d'attributs de bénéficiaire sur la base des attributs de bénéficiaire reçus du deuxième serveur et d'une clé privée ; et comparer l'autre signature d'attributs de bénéficiaire à la signature d'attributs de bénéficiaire reçue du deuxième serveur. [0010] Selon un mode de réalisation, le procédé comprend en outre la déduction, par le premier serveur, de la clé privée à partir d'une clé maître sur la base d'un identifiant d'un registre de bénéficiaires. [0011] Selon un mode de réalisation, la signature d'attributs de bénéficiaire est générée en appliquant une première fonction de hachage aux attributs de bénéficiaire pour générer une première valeur de condensé et en générant une signature d'attributs de bénéficiaire en chiffrant la première valeur de condensé sur la base d'une clé privée. [0012] Selon un mode de réalisation, le procédé comprend en outre : appliquer, par le premier serveur, une deuxième fonction de hachage, qui est la même que la première fonction de hachage, aux attributs de bénéficiaire reçus pour générer une deuxième valeur de condensé ; déchiffrer la signature d'attributs de bénéficiaire reçue sur la base d'une clé publique pour générer une autre valeur de condensé ; et comparer la deuxième valeur de condensé à l'autre valeur de condensé pour vérifier la signature d'attributs de bénéficiaire. [0013] Selon un mode de réalisation, le numéro de compte du bénéficiaire est un IBAN (Numéro de Compte Bancaire International). 3 100141 Selon un mode de réalisation, le paiement push est un Virement Instantané de Région Unique de Paiement en Euros (SCT Inst), [0015] Selon un autre aspect, on prévoit un serveur de paiement agencé pour : recevoir, à partir d'un deuxième serveur associé à un bénéficiaire, des attributs de bénéficiaire comprenant au moins un numéro de compte d'un compte bancaire de bénéficiaire, et une signature d'attributs de bénéficiaire ; vérifier la signature d'attributs de bénéficiaire sur la base des attributs de bénéficiaire reçus du deuxième serveur ; et lancer un paiement push vers le compte bancaire de bénéficiaire si la vérification de la signature d'attributs de bénéficiaire a réussi. [0016] Selon encore un autre aspect, on prévoit un système de paiement push comprenant : le serveur de paiement susmentionné ; et un registre de bénéficiaires agencé pour générer la signature d'attributs de bénéficiaire sur la base d'attributs de bénéficiaire fournis par un dispositif de bénéficiaire. [0017] Selon un mode de réalisation, le registre de bénéficiaires est agencé pour mémoriser des attributs de bénéficiaires associés à une pluralité de bénéficiaires. Brève description des dessins [0018] Ces caractéristiques et avantages, ainsi que d'autres, seront exposés en détail dans la description suivante de modes de réalisation particuliers faite à titre non limitatif en relation avec les figures jointes parmi lesquelles : [0019] [fig.1] la figure 1 représente schématiquement un exemple de système de paiement push ; [0020] W8.21 la figure 2 représente schématiquement un système de paiement push selon un exemple de réalisation de la présente description ; [0021] [fig.31 la figure 3 est un organigramme illustrant des étapes dans un procédé de réa- lisation d'un paiement push selon un exemple de réalisation de la présente description ; [0022] [fig.4] la figure 4 représente schématiquement un serveur de paiement de la figure 2 plus en détail selon un exemple de réalisation de la présente description ; [0023] [fig.51 la figure 5 représente schématiquement des processus de génération et de véri- fication de signature selon un exemple de réalisation de la présente description ; et [0024] [fig.61 la figure 6 représente schématiquement des processus de génération et de véri- fication de signature selon une variante de réalisation par rapport à la figure 5. Description des modes de réalisation 100251 Bien que dans la description qui suit des modes de réalisation soient décrits sur la base du schéma de paiement SCT Inst, il sera clair pour l'homme de l'art que les techniques décrites ici pourraient s'appliquer à d'autres types de paiements sans carte initiés par le payeur. 100261 La figure 1 illustre schématiquement un exemple de système de paiement push 100 basé sur le schéma de paiement SCT Inst. Afin de lancer un paiement entre un compte bancaire de payeur au niveau d'une banque de payeur (PAYER BANK) 102 et un compte bancaire de bénéficiaire au niveau d'une banque de bénéficiaire (PAYEE BANK) 104, un message de lancement de paiement (PAYMENT INITIATION MESSAGE) est généré par un serveur (PAYER BANK FRONT-END) 106 de la banque du payeur, qui sera appelé dans la suite serveur de paiement. Par exemple, le payeur utilise une application de paiement, s'exécutant sur un dispositif de payeur (PAYER DEVICE) 108 comme un dispositif mobile ou un PC, pour donner instruction à sa banque, par l'intermédiaire du serveur de paiement 106, de lancer le transfert de fonds vers un bénéficiaire possédant un ou plusieurs dispositifs de bénéficiaire (PAYEE DEVICE(S)) 110. Comme cela est représenté par une flèche 111 entre le dispositif de payeur 108 et le ou les dispositifs de bénéficiaire 110, des informations de transaction peuvent être envoyées à partir du ou des dispositifs de bénéficiaire 110 vers le dispositif de payeur 108, comme le montant de la transaction, le nom/identifiant, ID, du commerçant, la date/heure de la transaction, etc. Cependant, d'autres données de transaction plus sensibles comme des détails d'un compte, ne sont par exemple pas transmises sur cette interface. [0027] La banque 102 du payeur connaît le payeur qui est associé au dispositif de payeur 108 et par conséquent est capable d'identifier le compte de payeur à partir duquel les fonds doivent provenir. La banque 102 du payeur a aussi besoin des détails du compte, comme l'IBAN du compte du bénéficiaire afin de lancer le paiement. Lorsqu'un paiement doit être lancé, les détails de la transaction (TX DETAILS), comprenant l'IBAN du bénéficiaire, sont par exemple communiqués par lesdits un ou plusieurs dispositifs de bénéficiaire 110 à un fournisseur de services de paiement (PSP) 112. Le PSP 112 est une entité qui assure des services de paiement pour un ou plusieurs bénéficiaires, comme des commerçants, associés au(x) dispositif(s) de bénéficiaire 110. Le serveur 106 est par exemple chargé de contacter le PSP 112 associé au(x) dispositif(s) de bénéficiaire 110 afin d'obtenir l'IBAN du bénéficiaire. L'échange entre le serveur de paiement 106 et le PSP 112 se fait par exemple via un espace d'interopérabilité (INTEROP SPACE) 114, qui correspond à l'infrastructure technique et au cadre réglementaire qui permettent d'exécuter des paiements dans le système, comprenant la mise en oeuvre d'un protocole associé à des paiements qui définit la manière dont des paiements doivent être réalisés (quelles sont les données échangées, etc.). Ce protocole est par exemple défini de telle sorte que plus qu'un seul PSP et plus qu'un seul frontal bancaire 106 puissent exister et communiquer entre eux. L'échange sur l'espace d'interopérabilité 114 est par exemple lancé après une interaction sur l'interface 1 1 1 entre le dispositif de payeur 108 et le dispositif de bénéficiaire 110. [0028] Si un fraudeur était capable d'intercepter l'échange entre le serveur de paiement 106 et le PSP 112, les informations IBAN du bénéficiaire fournies par le PSP 112 au serveur de paiement 106 pourraient être modifiées pour indiquer un compte détenu par le fraudeur, et le paiement résultant pourrait être effectué vers ce compte à la place du compte correct. En outre, le système IBAN couvre divers pays, comprenant l'Europe, le Moyen-Orient, l'Afrique du Nord et les Caraïbes, et ainsi une fois qu'un transfert frauduleux a été réalisé, par exemple vers un compte à l'extérieur de l'espace d'interopérabilité 114, il peut être difficile ou impossible de récupérer les fonds. [0029] La figure 2 illustre schématiquement un système de paiement push 200 basé sur le schéma de paiement SCT Inst selon un exemple de réalisation de la présente description. Les éléments du système de la figure 2 qui sont similaires à des éléments de la figure 1 portent les mêmes références numériques et ne seront pas décrits de nouveau en détail. Le dispositif de payeur 108 est par exemple mis en oeuvre par le dispositif décrit en relation avec la figure 2 de la demande de brevet international publiée sous le numéro W02015/120949. [0030] Par rapport au système 100 de la figure 1, le système 200 comprend en plus un registre de bénéficiaires (PAYEE REGISTER) 202 capable de communiquer avec le PSP 112 et/ou avec lesdits un ou plusieurs dispositifs de bénéficiaire 110, et dans certains cas avec le serveur de paiement 106, comme cela est représenté par une flèche 204. Par exemple, le registre de bénéficiaires 202 correspond à un serveur connecté à un réseau de communication comme le réseau Internet permettant des communications avec des serveurs associés à de nombreuses banques. Le registre de bénéficiaires 202 mémorise par exemple des attributs de bénéficiaires et/ou des signatures d'attributs de bénéficiaires associés à une pluralité de bénéficiaires enregistrés. Ces attributs et/ou signatures de bénéficiaires ont par exemple été générés et mémorisés dans le registre de bénéficiaires 202 pendant un processus d'inscription décrit plus en détail ci-après. [0031] Le registre de bénéficiaires 202 correspond par exemple à une entité de confiance dans le système de paiement 200 qui s'engage dans une relation légale et commerciale avec une pluralité de bénéficiaires, mais qui ne joue pas de rôle direct dans le processus de paiement. Le registre 202 assume par exemple la responsabilité de l'enregistrement de bénéficiaires, comme des commerçants, et pour cela il peut appliquer un processus d'approbation comme le processus connu dans la technique sous le nom de KYC (Know Your Customer - Connaissez Votre Client) pour vérifier les attributs du bénéficiaire. [0032] Par exemple, pour s'inscrire sur le registre de bénéficiaires 202, le bénéficiaire fournit, pendant le processus d'inscription, des attributs de bénéficiaire (ATTRIBUTES) au registre de bénéficiaires 202, comprenant au moins le numéro de compte bancaire du bénéficiaire, comme un IBAN. Les attributs de bénéficiaire comprennent aussi par exemple au moins un identifiant du bénéficiaire, qui pourrait être un 6 nom, un numéro d'identifiant, ID, ou un autre identifiant, etc. Comme cela est représenté par des flèches 206 et 208, dans certains modes de réalisation les attributs sont fournis à partir desdits un ou plusieurs dispositifs de bénéficiaire 110 au registre de bénéficiaires 202 via le PSP 112. En variante, comme cela est représenté par une flèche en trait interrompu 210, les attributs pourraient être fournis directement à partir desdits un ou plusieurs dispositifs de bénéficiaires 110 au registre de bénéficiaires 202. [0033] Le registre de bénéficiaires 202 répond par exemple en générant une signature d'attributs de bénéficiaire (PAS) sur la base d'au moins le numéro de compte bancaire ou l'IBAN du bénéficiaire. Cette signature est par exemple fournie au PSP 112. Comme cela est représenté par une flèche 212, dans certains modes de réalisation le PAS est fourni par le registre de bénéficiaires 202 directement au PSP 112. En variante, comme cela est représenté par des flèches en trait interrompu 214 et 216, lesdits un ou plusieurs dispositifs de bénéficiaire 110 peuvent relayer la signature vers le PSP 112. [0034] Bien que cela ne soit pas illustré en figure 2, dans certains cas le système de paiement 200 peut comprendre de multiple registres de bénéficiaires 202. Par exemple, chaque banque pourrait établir un registre de bénéficiaires pour ses clients. [0035] Les attributs de bénéficiaire peuvent inclure certains ou la totalité des éléments présentés dans le tableau suivant. Les colonnes P2M et P2P indiquent, en utilisant un "x", le cas où l'élément correspondant est pertinent pour des paiements de personne à commerçant (P2M) et/ou pour des paiements de personne à personne (P2P). [0036] 7 [Tableauxl] Élément P2M P2P Description ID du registre de bene- ficiaires x x Identifie de manière unique le registre de bénéficiaires dans le système de paiement dans le cas où il y a de multiples registres ID du commerçant x Identifie de manière unique un commerçant dans le registre de bénéficiaires Nom du bénéficiaire x x Nom du commerçant ou nom de la personne Pays du bénéficiaire x Code de pays, par exemple tel que défini dans la spécification "ISO 3166-1 alpha-2" Ligne d'adresse du hé- néficiaire x Adresse du bénéficiaire BIC du bénéficiaire x x Code d'identifiant bancaire de la banque du bénéficiaire IBAN du bénéficiaire x x IBAN du compte bancaire du bénéficiaire MCC x Code de catégorie de commerçants, correspondant à un code utilisé pour classer les types de marchandises ou de services d'un commerçant URL du commerçant x Localisateur de ressource universel du commerçant [0037] Dans certains modes de réalisation, les attributs du bénéficiaire sont communiqués entre des entités dans le système 200 en utilisant une structure XML (eXtensible Markup Language - Langage de Marquage Extensible), ou une structure de carte de bits dans laquelle un bit est affecté à chaque attribut, et si l'attribut est présent, le bit est à un. En plus ou à la place, d'autres structures peuvent être prises en charge, comme JSON (JavaScript Object Notation - Notation d'Objets par Script Java). La signature d'attributs de bénéficiaire peut être générée sur la base de certains ou de la totalité des attributs listés dans le tableau susmentionné, et est par exemple générée sur la base d'au moins le numéro de compte bancaire du bénéficiaire comme l'IBAN. Dans certains modes de réalisation, la signature est générée sur la base d'une chaîne de bits formée par la concaténation des divers attributs formant les attributs du bénéficiaire, comprenant dans certains cas des bits indiquant la présence de chaque attribut comme cela a été indiqué précédemment. [0038] La flèche 204 entre le serveur de paiement 106 dc la banque du payeur et le registre 8 de bénéficiaires 202 représente par exemple un échange d'une valeur secrète, comme une clé cryptographique privée ou publique, entre ces entités, permettant que la signature soit vérifiée par le serveur de paiement 106, comme on va le décrire plus en détail ci-après. [0039] Dans certains modes de réalisation, le registre de bénéficiaires 202 est un registre de commerçants mémorisant des attributs et/ou des signatures d'attributs associés à des commerçants enregistrés qui sont autorisés à recevoir des paiements de clients. Dans un tel cas, lesdits un ou plusieurs dispositifs de bénéficiaire 110 peuvent correspondre à des équipements de points de vente. [0040] En plus ou à la place, le registre de bénéficiaires 202 peut être un service fourni par une ou plusieurs banques permettant à leurs clients de s'enregistrer comme béné- ficiaires, cela leur permettant de recevoir des transferts de fonds à partir de tiers. [0041] On va maintenant décrire plus en détail le fonctionnement du système de paiement push 200 en faisant référence à la figure 3. [0042] La figure 3 est un organigramme représentant des étapes dans un procédé de réa- lisation d'un paiement push utilisant le système 200 de la figure 2 selon un exemple de réalisation. Ce procédé est par exemple mis en oeuvre par le serveur de paiement 106 associé à la banque 102 du payeur. [0043] On supposera qu'avant qu'un paiement quelconque soit effectué au bénéficiaire, le bénéficiaire s'est enregistré sur le registre de bénéficiaires 202, et qu'une signature d'attributs de bénéficiaire (PAS) correspondante a été mémorisée auprès du fournisseur de services de paiement 112. [0044] On supposera aussi que le payeur a indiqué, en utilisant le dispositif de payeur 108, une intention d'effectuer un paiement au bénéficiaire. Par exemple, le payeur se trouve à la caisse d'un magasin et choisit de régler la note en utilisant un paiement push initié par le payeur. [0045] Dans une étape 301, le serveur de paiement 106 de la banque 102 du payeur identifie par exemple le PSP 112 associé au bénéficiaire et contacte le PSP 112. Il existe de nombreuses manières pour que le serveur de paiement 106 puisse identifier le PSP 112. Par exemple, dans le cas d'un paiement associé à un commerce mobile, une URL du PSP 112 est par exemple incluse dans un code QR présent sur la page de paiement du commerçant. Le dispositif de payeur 108 est par exemple utilisé pour scanner le code QR, et l'URL est utilisée par le serveur de paiement 106 pour contacter le PSP 112. En variante, le PSP 112 pourrait être identifié en utilisant une application du commerçant s'exécutant sur le dispositif de payeur 108, ou par une communication électronique reçue d'un équipement de point de vente du commerçant. Le PSP 112 est par exemple associé à un identifiant, et par exemple possède un certificat X.509 délivré par une autorité de certificats CA (Certificate Authority) et vérifié à chaque transaction. 9 [0046] Dans une étape 302, le serveur de paiement 106 reçoit par exemple du PSP 112 les attributs du bénéficiaire, accompagnés de la signature d'attributs de bénéficiaire correspondante délivrée par le registre de bénéficiaires 202. Comme cela a été indiqué précédemment, cette signature a par exemple été générée sur la base de certains ou de la totalité des attributs du bénéficiaire, et est par exemple au moins basée sur numéro de compte du bénéficiaire. Dans certains cas, elle est aussi générée sur la base d'au moins un identifiant du bénéficiaire. Les attributs du bénéficiaire et la signature d'attributs de bénéficiaire sont par exemple transmis par le PSP 112 au serveur de paiement 106 accompagnés des détails de la transaction. Les détails de la transaction sont par exemple fournis par lesdits un ou plusieurs dispositifs de bénéficiaire 110 pendant r initialisation de la transaction, et comprennent par exemple au moins le montant de la transaction et un identifiant du bénéficiaire. [0047] Dans une étape 303, le serveur de paiement 106 vérifie par exemple les attributs du bénéficiaire sur la base dc la signature d'attributs de paiement. Cette vérification implique par exemple de recalculer la signature sur la base des attributs reçus à partir du PSP 112, et de comparer la signature recalculée à la signature reçue du PSP 112. Si les signatures concordent, les attributs de bénéficiaire sont considérés comme valides. Dans certains modes de réalisation, la génération de la signature est basée sur une valeur de hachage ou de condensé, générée sur la base des attributs de bénéficiaire, comme cela est décrit plus en détail ci-après. [0048] Dans une étape 304, si les attributs de bénéficiaire ont été validés, le paiement est par exemple exécuté. Cela implique par exemple la génération, par le serveur de paiement 106, d'un message de lancement de paiement (PAYMENT INITIATION MESSAGE), qui est fourni à la banque 102 du payeur afin de lancer le paiement, par exemple sous la forme d'un transfert SCT. Ce message de lancement de paiement inclut par exemple les détails du compte du bénéficiaire. [0049] La figure 4 illustre schématiquement le serveur de paiement 106 de la figure 2 plus en détail selon un exemple de réalisation. [0050] Le serveur de paiement 106 comprend par exemple un dispositif de traitement 402 comprenant un ou plusieurs coeurs de traitement (P) sous le contrôle d'instructions mémorisées dans une ou plusieurs mémoires d'instructions (INSTR MEM) 404, les instructions mettant par exemple en oeuvre certaines ou la totalité des étapes de la figure 3 décrites précédemment. Le serveur de paiement 106 comprend aussi par exemple un ou plusieurs dispositifs de stockage de données (MEMORY) 406 mémorisant une base de données de payeurs enregistrés (PAYER DATABASE), correspondant par exemple à des clients de la banque 102 du payeur. Lesdits un ou plusieurs dispositifs de stockage de données 406 par exemple mémorisent aussi temporairement les attributs de payeur (PAYER ATTRIBUTES) communiqués par le PSP 112. Le serveur de paiement 106 comprend par exemple une interface de communications (COMMS INTERFACE) 408 permettant des communications avec le PSP 112 et avec d'autres éléments dans le système 200. Dans certains modes de réalisation, le serveur de paiement 106 comprend aussi un circuit cryptographique (CRYPTO) 410. [0051] Le registre de bénéficiaires 202 est par exemple mis en oeuvre par des éléments si- milaires à ceux du serveur de paiement 106 de la figure 4, excepté que lesdits un ou plusieurs dispositifs de stockage 406 mémorisent par exemple une base de données de bénéficiaires indiquant des attributs de bénéficiaires et/ou des signatures d'attributs de bénéficiaires. [0052] On va maintenant décrire des exemples d'éléments se trouvant au niveau du registre de bénéficiaires 202 et au niveau du serveur de paiement 106 pour la génération et la vérification de signatures d'attributs de bénéficiaires en faisant référence aux figures 5 et 6. [0053] La figure 5 illustre schématiquement une génération et une vérification de signature selon un premier exemple basé sur une cryptographie asymétrique. [0054] Le registre de bénéficiaires 202 met en oeuvre par exemple, en utilisant un circuit matériel ou en utilisant du logiciel exécuté par un dispositif de traitement, un algorithme cryptographique (CRYPTO) 502. Par exemple, l'opération cryptographique est réalisée en utilisant le circuit cryptographique 410 du registre de bénéficiaires 106. Les attributs de bénéficiaire PA, comprenant au moins le numéro de compte du bénéficiaire, sont par exemple signés de manière cryptographique sur la base d'une clé privée de bureau d'enregistrement de bénéficiaire (PRIVATE KEY (PRC)) du certificat de bureau d'enregistrement de bénéficiaire PRC afin de générer une signature d'attributs de bénéficiaire (PAS). Par exemple, comme cela est illustré en figure 5, les attributs de bénéficiaire sont utilisés pour générer une valeur de condensé (TX DIGEST) en appliquant une fonction de hachage unidirectionnelle (ONE-WAY HASH) 504. Cette valeur de condensé est ensuite chiffrée par l'algorithme cryptographique 502 sur la base de la clé privée du certificat de bureau d'enregistrement de bénéficiaire PRC afin de générer la signature d'attributs de bénéficiaire PAS. Cette signature est par exemple ajoutée aux attributs de paiement formant le texte en clair (PLAIN TEXT (PA)). Les attributs de paiement et la signature PAS sont ensuite par exemple transmis au PSP 112 et mémorisés par celui-ci, à partir duquel ils peuvent être fournis au serveur de paiement 106, comme cela est représenté par une flèche 506 en figure 5. [0055] Le serveur de paiement 106 applique par exemple le même algorithme crypto- graphique (CRYPTO) 502' aux attributs de paiement PA' reçus et à la signature d'attributs de bénéficiaire (PAS) reçue. Par exemple, le texte en clair reçu (PLAIN TEXT (PA')) est utilisé pour générer une valeur de condensé (RX DIGEST) sur la base 11 des attributs reçus en appliquant une fonction de hachage unidirectionnelle (ONE-WAY HASH) 504', qui est par exemple la même fonction que la fonction de hachage unidirectionnelle 504 appliquée par le registre de bénéficiaires 202. Le PAS' reçu est déchiffré en utilisant l'algorithme cryptographique 502' sur la base de la clé publique (PUBLIC KEY (PRC)) du certificat de bureau d'enregistrement de bénéficiaire PRC pour générer une valeur de condensé RX DIGEST'. La valeur RX DIGEST' est par exemple comparée par un comparateur (COMPARATOR) 510 à la signature RX DIGEST pour déterminer si la vérification a réussie, c'est-à-dire si les condensés concordent, ou a échoué c'est-à-dire si un ou plusieurs bits diffèrent. Si la vérification a réussi, les attributs de paiement reçus PA' peuvent être utilisés pour exécuter le paiement, tandis que si la vérification échoue, les attributs de paiement reçus PA' sont par exemple supprimés. [0056] La figure 6 illustre schématiquement une génération et une vérification de signature selon un autre exemple basé sur une cryptographie symétrique. [0057] Une autorité de confiance (TRUSTED AUTHORITY) 602 du système de paiement émet par exemple une clef maitre MKTA à la fois vers le registre de bénéficiaires 202 et le serveur de paiement 106. [0058] Le registre de bénéficiaires 202 met en oeuvre par exemple, en utilisant un circuit matériel ou en utilisant du logiciel exécuté par un dispositif de traitement, une fonction de déduction de clé (KDF) 604 et un algorithme de chiffrement (ENCRYPTION ALGORITHM) 606. Par exemple, ces opérations sont au moins partiellement réalisées en utilisant le circuit cryptographique 410 du registre de bénéficiaires 106. La fonction de déduction de clé est utilisée pour déduire une clé MKPR à partir de la clé maitre MKTA, sur la base d'un identifiant (REGISTRAR ID) associé au registre de bénéficiaires 202. Les attributs de bénéficiaire PA, comprenant au moins le numéro de compte bénéficiaire, sont ensuite chiffrés sur la base de la clé MKPR afin de générer la signature d'attributs de bénéficiaire (PAS) mémorisée au niveau du PSP 112. Cette signature est par exemple un code MAC (Message Authentication Code - code d'authentification de message) ou un code HMAC (Hashed MAC - MAC haché). [0059] Le serveur de paiement 106 applique par exemple la même fonction de déduction de clé et le même algorithme de chiffrement, représentés par des blocs 608 et 610. Par exemple, ces opérations sont au moins partiellement réalisées en utilisant le circuit cryptographique 410 du serveur de paiement 106. La clé MKPR est par exemple déduite de la clé maitre MKTA, sur la base de l'identifiant (REGISTRAR ID) associé au registre de bénéficiaires 202. Cet identifiant est par exemple envoyé au serveur de paiement 106 avec le reste des données de transaction. Les attributs de paiement PA' reçus du PSP 112 sont chiffrés sur la base de la clé MKPR. La signature résultante PAS" est par exemple comparée (COMPARISON) à la signature PAS' reçue du PSP 12 112, comme cela est représenté par un bloc 612, et le résultat (RESULT) indique si la vérification a réussi, c'est-à-dire si les signatures concordent, ou a échoué, c'est-à-dire si un ou plusieurs bits diffèrent entre les signatures. [0060] Un avantage des modes de réalisations décrits ici est qu'un paiement push peut être mis en oeuvre avec une sécurité améliorée sans augmenter fortement la complexité du système par rapport à des solutions de paiement push existantes. [0061] Avec la description ainsi faite d'au moins un mode de réalisation illustratif, diverses altérations, modifications et améliorations apparaîtront facilement à l'homme de l'art. Par exemple, il sera clair pour l'homme de l'art que bien qu'on ait décrit deux exemples de génération et de vérification de signature en relation avec les figures 5 et 6, d'autres solutions seraient possibles. [0062] En outre, alors que la figure 6 illustre un exemple dans lequel l'Autorité de Confiance fournit la clé MKTA au registre de bénéficiaires 202, et le registre de bénéficiaires 202 déduit la clé MKPR, dans des variantes de réalisation, l'Autorité de Confiance fournit directement la clé MKPR au registre de bénéficiaires 202. [0063] En outre, il sera clair pour l'homme de l'art que les divers éléments décrits en relation avec les divers modes de réalisation pourraient être combinés, dans des variantes de réalisation, selon diverses combinaisons. 13 [Revendication 1] [Revendication 2] [Revendication 3] [Revendication 4] [Revendication 5] [Revendication 6]