Brevet FR3086414A1 — publié le 20200327

Procédé de traitement d'une transaction, dispositif, système et programme correspondant 1. Domaine L'invention se rapporte au domaine de l'authentification d'utilisateurs. L'invention se rapporte plus particulièrement à l'authentification d'utilisateurs lors de transactions impliquant la mise en oeuvre d'un dispositif d'utilisateur, également appelé terminal de communication. L'invention porte plus particulièrement sur l'authentification d'utilisateur au sein d'une base de données distribuée au sein d'un réseau de communication. Plus spécifiquement encore, un objet de la présente technique est d'augmenter le niveau de sécurité d'une transmission de données dans le cadre du traitement d'une transaction (telle qu'un paiement mobile) réalisé avec un terminal de communication portable (par exemple un smartphone ou une tablette). 2. Art Antérieur D'une manière générale, le nombre de paiements en ligne est en constante augmentation. Les paiements mobiles représentent un type particulier des paiements en ligne et une part croissante de ceux-ci. Ils peuvent être effectués par le biais de fournisseurs de paiement, tels que PaypalTM, ou en faisant appel à des organisations bancaires traditionnelles, en utilisant une carte bancaire de paiement. Cependant, le paiement en ligne est marqué par un taux de fraude relativement élevé. En France, on estime qu'environ 5% des paiements en ligne effectués sur Internet sont frauduleux. Ces paiements frauduleux de cinq pour cent représentent environ trente-trois pour cent du coût total de la fraude. Il est donc nécessaire d'avoir des moyens d'une part d'identifier les tentatives de fraude et d'autre part de bloquer ces tentatives. Un des problèmes dans les transactions par mobile est qu'elles sont effectuées en mode "carte non présente" (c.-à-d. CNP, pour "card not present" en anglais). Dans ce mode, aucun dispositif n'étant chargé de vérifier l'intégrité de la carte (comme par exemple un terminal de paiement), il n'est pas possible de vérifier que le détenteur de la carte possède le code PIN nécessaire pour valider une transaction : la carte de paiement n'est pas utilisée pour effectuer la transaction. Seules les données inscrites sur la carte le sont. Ces données peuvent être volées pour effectuer des transactions par des fraudeurs, éventuellement en utilisant d'autres applications marchandes, dans le cadre d'autres paiements mobiles. Accessoirement, le terminal de communication de l'utilisateur (qui comprend toutes les données des cartes de paiement 2 utilisées par celui-ci), peut également être volé, donnant accès au voleur à l'ensemble des données de l'utilisateur et permettant au voleur d'effectuer des transactions frauduleuses. Ainsi, dans le but de sécuriser les transactions effectuées en mode CNP, des systèmes et des méthodes ont été proposés pour résoudre ces problèmes de fraude. Ces méthodes posent 5 des problèmes de commodité pour l'utilisateur ou d'autres problèmes de sécurité. C'est par exemple la méthode décrite dans le document de brevet W02012053780. Dans ce document, un système et une méthode de vérification sont décrits. Plus particulièrement un procédé et un système utilisant des informations sur l'adresse MAC d'un terminal client sont décrits. Lors d'une transaction impliquant un paiement, un processus d'authentification est mis en oeuvre dans 10 lequel l'adresse MAC du terminal utilisé par l'utilisateur souhaitant effectuer un paiement est comparée à une adresse MAC de référence, définie ou obtenue par le serveur bancaire, serveur qui doit autoriser un paiement ou une transaction. Cette méthode, bien que potentiellement intéressante, est néanmoins peu pratique. En effet, d'une part, cette méthode oblige l'utilisateur à toujours utiliser le même appareil pour 15 effectuer un paiement (sauf à définir plusieurs appareils autorisés à effectuer une transaction). D'un autre côté, il existe de nombreuses méthodes pour falsifier une adresse MAC d'un périphérique. D'autres méthodes sont également disponibles. Certains impliquent de fournir à l'utilisateur des numéros de cartes bancaires uniques. Ces numéros sont fournis en fonction des 20 besoins du client. Cette méthode est intéressante mais ne supprime pas la possibilité pour l'utilisateur d'utiliser ses propres informations de carte pour effectuer des transactions. D'autres méthodes, actuellement largement utilisées, consistent à transmettre un message de type SMS au client qui effectue une transaction pour s'assurer qu'il est le porteur de la carte. L'utilisateur doit saisir, au moment de la transaction, un mot de passe transmis dans le SMS. Par conséquent, la 25 banque s'assure avec une probabilité raisonnable que celui qui effectue la transaction est l'utilisateur. Cette méthode présente deux inconvénients : d'une part, elle oblige l'utilisateur à fournir son numéro de téléphone à la banque avant toute transaction et de manière sécurisée ; d'autre part, et surtout cette méthode ne fonctionne que si la banque du client est également la banque qui gère la transaction pour le compte du commerçant, ce qui n'est pas nécessairement le 30 cas, surtout à l'étranger, là précisément où la plus grande partie de la fraude est réalisée. Ainsi, la méthode susmentionnée n'est pas très efficace dans ce cas. 3 3. Résumé La méthode proposée par les inventeurs ne pose pas ces problèmes de l'art antérieur. En effet, il est proposé une méthode de sécurisation de la transaction basée sur l'enregistrement, au sein d'une base de données distribuée, des authentifications de l'utilisateur auprès de son 5 terminal de communication. Plus particulièrement, la présente technique délivre, au sein d'une base de données distribuée, des authentifications d'utilisateurs sur son terminal de communication, ces authentifications étant par la suite utilisée pour valider une transaction réalisée par l'utilisateur. Plus particulièrement, il est décrit un procédé de traitement d'une transaction, procédé 10 mis en oeuvre par un dispositif électronique de traitement de transactions, accessible par l'intermédiaire d'un réseau de communication. Selon l'invention, un tel procédé de traitement comprend une phase de traitement de transaction caractérisée en ce qu'elle comprenant : une étape d'obtention d'une empreinte cryptographique contextuelle, préalablement générée au cours d'une authentification d'un utilisateur sur un terminal de 15 communication ; une étape de vérification de validité de l'empreinte cryptographique contextuelle au sein d'une chaine de blocs comprenant un ensemble d'empreintes cryptographiques ; une étape de validation d'une transaction lorsque l'étape de de vérification de validité de l'empreinte cryptographique contextuelle au sein d'une chaine de blocs est positive. 20 Ainsi, selon l'invention, on résout au moins partiellement les problématiques de l'art antérieur en s'assurant qu'une transaction, par exemple une transaction de paiement mobile, puisse être validée par l'intermédiaire d'une authentification réussie de l'utilisateur sur son terminal de communication et la validation (et non répudiation) de cette authentification au sein d'une chaine de blocs. 25 Selon une caractéristique particulière, une empreinte cryptographique contextuelle (EC) est matérialisée par une chaine d'identification ChIEC de l'empreinte cryptographique EC qui est obtenue à partir d'un ensemble D de données constitutrices (d0,...,dn) de la manière suivante : ChlEC = F (G (d0,...,dn)) dans laquelle : 30 - G est une fonction de mélange de données ; - F est une fonction cryptographique de calcul de la chaine d'identification. 4 Ainsi, on assure qu'une empreinte cryptographique contextuelle (EC) n'est pas reproductible au sein de la chaine de blocs, et qu'elle est unique, à un instant donné, pour un ensemble de données constitutrices. Selon un mode de réalisation particulier, l'étape d'obtention de l'empreinte 5 cryptographique contextuelle comprend : une étape de réception d'une adresse de localisation de l'empreinte cryptographique contextuelle au sein de la chaine de blocs ; une étape d'obtention de l'empreinte cryptographique contextuelle à l'adresse précédemment reçue. 10 Ainsi, l'empreinte cryptographique contextuelle ne peut pas être falsifiée. Selon une caractéristique particulière, l'étape de vérification de validité de l'empreinte cryptographique contextuelle comprend une étape de vérification de la validité du bloc de la chaine de blocs au sein de laquelle l'empreinte cryptographique contextuelle est insérée. Ainsi, on assure que l'empreinte cryptographique contextuelle est valide par rapport au 15 bloc lui-même. Selon une caractéristique particulière, l'étape de vérification de validité de l'empreinte cryptographique contextuelle comprend une étape de détermination que l'empreinte cryptographique contextuelle est la dernière empreinte cryptographique contextuelle en date pour ledit utilisateur et/ou ledit terminal de communication au sein de la chaine de blocs. 20 Ainsi, on assure qu'in ne puisse utiliser, pour une validation de transaction, que la dernière empreinte cryptographique contextuelle disponible : on résout ainsi les problèmes de rejeux. Selon une caractéristique particulière, l'étape de vérification de validité de l'empreinte cryptographique contextuelle comprend : 25 une étape d'obtention de données de transaction, en provenance du terminal de communication ; une étape de calcul, à partir de ces données de transaction, d'une empreinte cryptographique de vérification ; une étape de comparaison de empreinte cryptographique de vérification avec l'empreinte 30 cryptographique contextuelle ; et 5 une étape de validation de l'empreinte cryptographique contextuelle lorsque la comparaison est positive. Ainsi, on offre la possibilité supplémentaire de vérifier l'empreinte cryptographique contextuelle par rapport aux données qui la constituent. 5 Selon un mode de réalisation particulier, l'étape de vérification de validité de l'empreinte cryptographique contextuelle comprend une étape de comparaison d'au moins une donnée de constitution de l'empreinte cryptographique contextuelle avec au moins une donnée correspondante fournie par le terminal de communication. Selon un mode de réalisation particulier, le procédé de traitement d'une transaction 10 comprend en outre une phase préliminaire d'authentification, au cours de laquelle l'empreinte cryptographique contextuelle est créée, ladite phase préliminaire d'authentification comprenant : une étape d'authentification de l'utilisateur ; une étape d'obtention d'un message d'authentification, comprenant la confirmation d'authentification de l'utilisateur et un ensemble D de données constitutrices (d0,...,dn) ; 15 une étape de calcul de l'empreinte cryptographique contextuelle à l'aide des données reçues ; Selon un mode de réalisation particulier, la phase préliminaire d'authentification comprend en outre : une étape d'insertion de l'empreinte cryptographique contextuelle au sein de la chaine de 20 blocs ; et lorsque le bloc de la chaine de bloc au sein duquel l'empreinte cryptographique contextuelle a été insérée est validé, une étape de transmission de l'empreinte cryptographique contextuelle au terminal de communication. Selon un autre aspect, l'invention se rapporte également à un dispositif électronique de 25 traitement de transactions, accessible par l'intermédiaire d'un réseau de communication, ledit dispositif comprenant des moyens de traitement comprenant de transaction. Un tel dispositif comprend : des moyens d'obtention d'une empreinte cryptographique contextuelle, préalablement générée au cours d'une authentification d'un utilisateur sur un terminal de 30 communication ; 6 des moyens de vérification de validité de l'empreinte cryptographique contextuelle au sein d'une chaine de blocs comprenant un ensemble d'empreintes cryptographiques ; des moyens de validation d'une transaction mis en oeuvre lorsque les moyens de vérification de validité de l'empreinte cryptographique contextuelle au sein d'une chaine 5 de blocs fournissent une information positive. Il est entendu, dans le cadre de la description de la présente technique selon l'invention, qu'une étape de transmission d'une information et/ou d'un message d'un premier dispositif à un deuxième dispositif, correspond au moins partiellement, pour ce deuxième dispositif à une étape de réception de l'information et/ou du message transmis, que cette réception et cette 10 transmission soit directe ou qu'elle s'effectue par l'intermédiaire d'autres dispositifs de transport, de passerelle ou d'intermédiation, y inclus les dispositifs décrits dans la présente selon l'invention Selon une implémentation préférée, les différentes étapes des procédés selon l'invention sont mises en oeuvre par un ou plusieurs logiciels ou programmes d'ordinateur, comprenant des 15 instructions logicielles destinées à être exécutées par un processeur de données d'un module relais selon l'invention et étant conçu pour commander l'exécution des différentes étapes des procédés, mis en oeuvre au niveau du terminal de communication, du serveur d'authentification et du serveur marchand. En conséquence, l'invention vise aussi des programmes, susceptibles d'être exécutés par 20 un ordinateur ou par un processeur de données, ces programmes comportant des instructions pour commander l'exécution des étapes des procédés tel que mentionnés ci-dessus. Un 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. 25 L'invention vise aussi un support d'informations lisible par un processeur de données, et comportant des instructions d'un programme 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, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen 30 d'enregistrement magnétique, par exemple un support mobile (carte mémoire) ou un disque dur ou un SSD. 7 D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. 5 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. Selon un mode de réalisation, l'invention est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce 10 document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels. Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en oeuvre une fonction ou un ensemble de fonctions, 15 selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, set-top-box, routeur, etc) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc). 20 De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un 25 micrologiciel (firmware), etc. Chaque composante du système précédemment décrit met bien entendu en oeuvre ses propres modules logiciels. Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en oeuvre de l'invention. 30 4. Figures 8 D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 décrit un système dans lequel l'invention est mise en oeuvre ; 5 la figure 2 décrit un mode de réalisation dérivé du procédé de traitement de transaction ; la figure 3 décrit un mode de réalisation dérivé du procédé de traitement de transaction ; la figure 4 illustre une architecture d'un serveur apte à mettre en oeuvre un procédé de traitement de transaction ; la figure 5 illustre une architecture d'un client apte à mettre en oeuvre un procédé de 10 traitement de transaction. 5. Description 5.1. Rappels du principe Il a été exposé précédemment que la mise en oeuvre de transaction de paiement en mode « carte non présente » augmente le risque de fraude. L'objet de la présente technique est de 15 remédier, au moins en partie, à certains inconvénients des transactions en mode « carte non présente » en introduisant un mécanisme de vérification d'identité, permettant de fournir au marchand (détenteur d'un service de vente en ligne, par l'intermédiaire d'un -ensemble deserveur-s- marchand-s-) une confirmation (avec une certitude raisonnable) de l'identité de l'utilisateur (et de sa légitimité à effectuer l'achat et la transaction de paiement résultante). Dans 20 le cadre de la présente technique, on met en oeuvre une chaine de blocs, la chaine de blocs enregistrant des caractéristiques d'authentifications successives d'utilisateurs (ces caractéristiques étant appelées des empreintes cryptographiques contextuelles). Dans un mode de réalisation, décrit en relation avec la figure 1, la technique est mise en oeuvre au sein d'un système comprenant plusieurs entités différentes, coopérant et mettant 25 chacune d'entre elles en oeuvre une méthode adaptée. Plus particulièrement, le système comprend : un serveur d'authentification (AuthSrv), mettant en oeuvre une chaine de blocs, dans laquelle les preuves d'authentification des utilisateurs sont enregistrées, dans une chaine de blocs (B1cCh); 9 un ensemble de terminaux de communication (TComs), chaque terminal étant possédé par un utilisateur qui utilise son terminal de communication pour effectuer des achats et/ou réaliser des transactions ; un ensemble de serveurs marchands (MerchtSrvs), détenus et mis en oeuvre par un ou 5 plusieurs fournisseurs de biens et/ou de services en lignes accessibles par l'intermédiaire des terminaux de communications ; Ces serveurs et terminaux échangent des données par l'intermédiaire d'un ou plusieurs réseaux de communications (Ntwk) auxquels ils sont connectés. Le principe général de la technique consiste à transmettre, au serveur marchand, une 10 empreinte cryptographique contextuelle (Ecc), représentative d'une authentification (auth) d'un utilisateur sur son terminal de communication, cette empreinte cryptographique contextuelle (Ecc) pouvant être vérifiée par le serveur d'authentification avant validation de la transaction de paiement par le serveur marchand et ou un serveur transactionnel (serveur bancaire, serveur de rissuer des données de paiement). Dans un premier mode de réalisation, le serveur 15 d'authentification est en mesure de valider l'empreinte cryptographique contextuelle transmise par le (ou pour le compte du) terminal de communication au serveur marchand, et ce grâce à la chaine de blocs (B1cCh) qu'il met en oeuvre. Dans un deuxième mode de réalisation, le serveur d'authentification est en mesure de calculer l'empreinte cryptographique contextuelle du terminal de communication, puis de la transmettre au serveur marchand, toujours grâce à la 20 chaine de blocs (B1cCh) qu'il met en oeuvre. On dispose ainsi d'une certaine assurance de l'authentification de l'utilisateur lorsque la transaction est validée, ce qui permet de réduire de manière importante le taux de fraude des moyens de paiement. Selon la présente technique, dans un mode de réalisation, une empreinte cryptographique est issue d'une structure de données qui comprend : 25 des données constitutrices : des données relatives à l'authentification comme un horodatage, un émetteur (par exemple identifiant de terminal de communication), un récepteur (par exemple identifiant d'un service d'authentification); optionnellement un nombre de blocs ayant confirmé l'empreinte cryptographique fournie (nombre de blocs de validation); 30 et éventuellement d'autres informations de contexte : adresse IP, position géographique, empreinte cryptographique précédente (de l'utilisateur), etc.). 10 L'empreinte en tant que telle est une chaine d'identification (identifiant de l'empreinte cryptographique), résultant d'un calcul effectué sur les données de constitution de l'empreinte cryptographique précédemment listées. Cette empreinte cryptographique (chaine d'identification) peut une fois ce calcul effectué, être intégrée à la structure de données 5 précédemment décrite. Cette structure de données peut, selon les cas être conservée par le serveur d'authentification dans une base de données spécifiquement dédiée à cet effet, être intégrée dans la chaine de blocs, ou encore être supprimée, s'il n'est pas nécessaire de disposer d'un accès à ces données. Une empreinte cryptographique de référence (dont la mise en oeuvre est décrite par la 10 suite) peut également comprendre (et/ou être issue) des données relatives à l'authentification de l'utilisateur (signatures biométriques, signature d'identifiant, signature de mot de passe, etc.). Une empreinte cryptographique contextuelle peut comprendre (et/ou être issue d') une référence (par exemple sous la forme d'une chaine d'identification) à une empreinte cryptographique précédente. 15 Soit D l'ensemble des données constitutrices (initiatrices) (d0,...,dn) de l'empreinte cryptographique EC. Soit F, la fonction cryptographique de calcul de la chaine d'identification ChlEC qui est considérée comme l'empreinte cryptographique EC. Soit G une fonction de mélange (mixité) de données. La chaine d'identification Ch/EC de l'empreinte cryptographique EC est calculée de la manière suivante : 20 ChlEC = F (G (d0,...,dn)) La fonction de calcul F et la fonction de mixité G ne sont pas spécifiquement détaillées et dépendent des conditions de mise en oeuvre opérationnelle de la chaine de blocs au niveau des serveurs d'authentification. La fonction G est une fonction de mélange de données du type fonction de concaténation, addition hexadécimale, multiplication, modulo décimale, module 25 hexadécimale ou modulo binaire, rotation (décimale, hexadécimale, binaire), etc. La fonction F peut par exemple être une fonction de hachage (par exemple la fonction MD5 ou la fonction SHA1) du résultat de la fonction G. L'empreinte de hachage (ou « valeur de hash ») obtenue forme ainsi un condensat cryptographique représentatif des données constitutrices, sans qu'il soit possible de retrouver ces données constitutrices à partir de cette empreinte de hachage. Dans la 30 suite et dans ce qui précède, on utilise principalement le terme « empreinte cryptographique » (EC) pour se référer à la chaine d'identification de celle-ci (c'est-à-dire à l'identifiant de 11 l'empreinte cryptographique ChIEC), qui permet d'identifier cette empreinte cryptographique au sein de la chaine de blocs. D'une manière générale, la technique proposée est basée sur plusieurs phases de création et de traitement de données d'authentification. 5 Dans une première phase d'inscription, un utilisateur a effectué les démarches nécessaires à son inscription en ligne à un service, lequel service peut gérer l'authentification de l'utilisateur. Par exemple, cette inscription peut avoir lieu lorsque l'utilisateur active son terminal de communication pour la première fois. Dans cette phase d'inscription, l'utilisateur fournit, à l'entité jouant le rôle de serveur d'authentification, les données nécessaires à l'inscription (nom, 10 prénom) et à la future authentification (mot de passe et/ou empreintes digitales et/ou iris et/ou autres données biométriques ou autres). Le serveur d'authentification stocke ces éléments de manière sécurisée. De plus, selon la présente technique, le serveur d'authentification peut calculer, à partir de ces éléments, une empreinte cryptographique de référence. Cette empreinte cryptographique de référence, 15 calculée par le serveur d'authentification (selon des modalités identiques à celles présentées précédemment), peut être insérée dans une chaine de blocs (et transmise, en retour au terminal de communication qui l'enregistre dans un espace mémoire sécurisé). Il s'agit normalement de la même chaine de blocs que celle qui est utilisée pour globaliser les authentifications successives des utilisateurs vis-à-vis du serveur d'authentification (ou de la ferme de serveurs 20 d'authentification). Comme exposé précédemment, la chaine de blocs n'est pas, normalement, une chaine de blocs publique, mais plutôt d'une chaine de blocs privée, réservée à l'usage du serveur d'authentification (ou de l'ensemble des serveurs d'authentification) et optionnellement de certains serveurs marchands (serveurs de ventes en ligne) disposant d'un accès à cette chaine de blocs. Les conditions de partage de cette chaine de blocs avec des serveurs marchands seront 25 exposées par la suite, dans le cadre d'un mode de réalisation particulier de l'invention. Alternativement, l'empreinte cryptographique de référence peut être calculée par le terminal de communication lui-même et transmise au serveur d'authentification (avec optionnellement les données constitutrice de celle-ci). Quoi qu'il en soit, à l'issue de cette phase d'inscription le ou les serveurs 30 d'authentification possèdent les éléments nécessaires à l'authentification de l'utilisateur. Lorsque l'utilisateur démarre ou utilise son terminal mobile, il effectue une action d'authentification vis-à- 12 vis du serveur d'authentification. Cette action d'authentification est soit explicite (un service d'authentification requiert explicitement l'authentification de l'utilisateur sur son terminal) soit implicite (au cours de l'utilisation ou du démarrage du terminal, une authentification au service a été réalisée, par exemple lors du déverrouillage du terminal de communication ou lors d'une 5 connexion par défaut à un service donné, par l'intermédiaire du terminal de communication, par exemple service de messagerie électronique, service d'authentification centralisé). Plus particulièrement une authentification implicite est par exemple réalisée au démarrage du terminal de communication lorsque l'utilisateur saisit un mot de passe ou fournit des données biométriques : le serveur d'authentification, par le biais d'un message qu'il reçoit de la part du 10 terminal de communication, est informé du fait que l'utilisateur a été correctement authentifié sur le terminal de communication. D'autres modes d'authentification explicites ou implicites peuvent également être mis en oeuvre : il s'agit de confirmer ou d'informer le serveur que l'authentification sur le terminal de communication ou auprès d'un service en ligne s'est correctement déroulée. 15 Selon la présente technique, ces méthodes ont en commun le fait que le terminal de communication effectue une authentification de l'utilisateur, en local ou en coopération avec le ou les serveurs d'authentification, par rapport à un certain nombre de données (et/ou de caractéristiques) authentifiées. Plus particulièrement, le terminal et/ou le serveur confronte les données (et/ou caractéristiques) fournies par l'utilisateur avec des données de référence. Les 20 données de référence sont obtenues lors de la phase d'inscription (voir précédemment) et stockées en mémoire sécurisée (sur le terminal de communication et/ou sur le serveur d'authentification). Lors de l'authentification implicite ou explicite, le fait d'avoir effectué une authentification valide est enregistré au sein du serveur d'authentification, postérieurement à la réception d'un message par le serveur d'authentification. 25 Le message reçu par le serveur d'authentification contient d'une part des données de validation de l'authentification (par exemple hash du mot de passe ou signature de l'empreinte digitale ou d'iris, voire empreinte cryptographique) qui sont accompagnées ou associées à des données contextuelles (par exemple la date, l'heure de l'authentification, une identification éventuelle du terminal de communication, numéro de série, IMEI, etc. et/ou d'autres données 30 contextuelles pertinentes). Ces données sont utilisées, par le serveur d'authentification, pour calculer une empreinte cryptographique « contextuelle », comme exposé précédemment. Cette 13 empreinte cryptographique contextuelle (différente potentiellement de l'empreinte cryptographique de référence) est insérée dans la chaine de blocs (et est optionnellement liée à une empreinte cryptographique précédente de l'utilisateur). L'empreinte cryptographique contextuelle (ou une référence à l'empreinte cryptographique contextuelle, par exemple une URL) 5 est ensuite retournée au terminal de communication, qui la stocke dans une mémoire sécurisée (par exemple dans le même slot mémoire que l'empreinte cryptographique de référence). Alternativement un lien ou une référence vers l'empreinte cryptographique contextuelle peut être transmise au terminal de communication. Cette empreinte cryptographique contextuelle constitue la preuve de l'authentification réussie du terminal de communication. La 10 réception de cette preuve par le terminal de communication (le fait d'avoir cette empreinte cryptographique contextuelle enregistrée sur le terminal de communication, ou le fait d'avoir un lien ou une référence vers cette empreinte cryptographique contextuelle), valide le fait (l'état), d'être correctement authentifié par le serveur d'authentification et valide l'état de l'enregistrement de cette authentification au sein de la chaine de blocs. 15 Plus particulièrement, en fonction des modes de réalisation, l'empreinte cryptographique contextuelle n'est transmise au terminal de communication que lorsque le bloc courant de la chaine de blocs (dans lequel l'empreinte cryptographique contextuelle est enregistré) est validé (c'est-à-dire complet et que la fermeture de ce bloc courant est cryptographiquement validée et vérifiée), et qu'un nouveau bloc (au moins) est créé dans la chaine de blocs. Plus particulièrement, 20 dans ces implémentations, l'empreinte cryptographique contextuelle n'est délivrée au terminal de communication que lorsque l'on est assuré que celle-ci n'est plus modifiable au sein de la chaine de blocs. Cette absence de possibilité de modification n'est apportée, du point de vue de la chaine de blocs, que lorsque le bloc courant est complet et validé, et qu'un nouveau bloc est « ouvert » pour enregistrer les authentifications (et/ou inscriptions) suivantes. En d'autres 25 termes, la transmission, au terminal de communication, de l'empreinte cryptographique contextuelle (ou d'un lien ou d'une référence vers celle-ci), n'est pas immédiate et dépend essentiellement du temps mis par le système dans son intégralité à fermer le bloc courant de la chaine de blocs (temps au demeurant relativement court, si l'on se rapporte au nombre d'authentifications réalisées chaque jour). 30 Une fois que l'empreinte cryptographique contextuelle (ou son lien ou sa référence) est reçue par le terminal de communication, celle-ci peut être utilisée dans le cadre de la mise en 14 oeuvre de transactions entre le terminal de communication et un ou plusieurs fournisseurs de biens et/ou de services avec qui l'utilisateur (du terminal de communication) souhaite effectuer des transactions. Plus particulièrement, lors de la mise en oeuvre d'une transaction à partir du terminal de 5 communication (un exemple de mise en oeuvre est décrit par la suite), l'empreinte cryptographique contextuelle est utilisée pour faire la preuve de l'authentification de l'utilisateur (et de sa présence par la même occasion). Plusieurs méthodes peuvent être mise en oeuvre pour atteindre cet objectif de validation de l'authentification. D'une manière générale, ces méthodes partagent les caractéristiques suivantes : 10 l'utilisateur s'identifie auprès du fournisseur de biens et/ou de services (par l'intermédiaire d'un couple login/mot de passe, authentification implicite ou explicite ou par d'autres moyens); l'utilisateur effectue une sélection de biens ou de services dont il souhaite faire l'acquisition ; 15 l'utilisateur effectue une action de paiement, comprenant notamment la fourniture de données de paiement (par exemple de données de carte de paiement) ; le serveur marchand réceptionne les données de paiement et initie une transaction de paiement, celle-ci nécessitant l'obtention d'une autorisation en provenance d'un serveur transactionnel (serveur bancaire ou serveur de l'issuer); 20 lorsque le serveur transactionnel répond positivement à la requête de paiement transmise par le serveur marchand, la transaction est validée et le paiement effectué. Selon la présente technique, ces étapes sont modifiées et l'empreinte cryptographique contextuelle est utilisée pour prouver la présence de l'utilisateur, voire pour valider la transaction elle-même. Plus particulièrement, l'empreinte cryptographique contextuelle est transmise en plus 25 (ou à la place) des données de paiement. Le terminal de communication transmet l'empreinte cryptographique contextuelle au serveur marchand (la méthode de transmission peut être directe ou indirecte, comme cela est expliqué par la suite). Le serveur marchand reçoit cette empreinte cryptographique et la transmet au serveur d'authentification (le serveur d'authentification peut être le serveur transactionnel dans le cas présent, bien que cela ne soit pas obligatoire). 30 En fonction des modes de réalisation, la méthode de transmission de l'empreinte cryptographique contextuelle peut être directe ou indirecte. Lorsque la transmission est directe, 15 le terminal de communication transmet cette l'empreinte cryptographique contextuelle dans un message à destination du serveur marchand. Le serveur marchand entre donc en possession de l'empreinte cryptographique contextuelle par l'intermédiaire du terminal de communication lui-même. Cette méthode présente l'intérêt de limiter les interactions entre le serveur marchand et 5 par exemple le serveur d'authentification ou un autre serveur. Dans la mesure où l'empreinte cryptographique contextuelle du terminal de communication est (initialement) reçue directement depuis le serveur d'authentification et stockée de manière sécurisée sur le terminal de communication, on estime raisonnablement que celle-ci ne peut pas être compromise et qu'elle conserve sa valeur en tant que preuve d'authentification. Lorsque la transmission est indirecte, le 10 terminal de communication transmet au serveur marchand un lien (par exemple une URL ou une URI) pointant vers cette l'empreinte cryptographique contextuelle. L'avantage est que le terminal de communication ne possède pas l'empreinte cryptographique contextuelle. Même si le terminal de communication est compromis, l'empreinte cryptographique contextuelle est sécurisée au niveau du serveur d'authentification. Lorsque le serveur marchand reçoit le lien vers l'empreinte 15 cryptographique contextuelle (lien qui le dirige vers le serveur d'authentification (ou le serveur transactionnel ou autre et/ou vers la chaine de blocs)), il lui est possible de vérifier la validité de l'empreinte cryptographique contextuelle au sein de la chaine de blocs. Ainsi, cette deuxième possibilité est avantageuse lorsque la chaine de blocs est accessible à plusieurs acteurs identifiés (comme par exemple le serveur d'authentification, le serveur marchand et/ou le serveur 20 transactionnel). Le lien (la référence) transmise permet d'accéder à la chaine de bloc, gérée par le ou les serveurs transactionnels). Quelle que soit la méthode employée (directe ou indirecte), le serveur marchand (ou le serveur d'authentification ou le serveur transactionnel) vérifie la validité de l'empreinte cryptographique contextuelle fournie, au sein de la chaine de blocs, notamment en vérifiant si 25 l'empreinte cryptographique contextuelle fournie est valide compte tenu du bloc au sein de laquelle elle est-insérée (première vérification) et optionnellement si l'empreinte cryptographique contextuelle fournie est la dernière empreinte cryptographique contextuelle en date de l'utilisateur (deuxième vérification). Pour la première vérification, le serveur qui effectue la vérification, obtient à partir de l'empreinte cryptographique contextuelle fournie, des données 30 relatives à l'authentification : horodatage, émetteur (par exemple identifiant de terminal de communication), récepteur (par exemple identifiant d'un service d'authentification), et un 16 nombre de blocs ayant confirmé l'empreinte cryptographique contextuelle fournie (nombre de blocs de validation) et éventuellement d'autres informations de contexte : adresse IP, position géographique, empreinte cryptographique précédente (de l'utilisateur), etc.). Le serveur est en mesure, à partir de ces données de vérifier qu'elles fournissent (après calcul) une empreinte 5 identique à l'empreinte cryptographique contextuelle fournie. Pour la deuxième vérification, l'empreinte cryptographique contextuelle est liée à une empreinte cryptographique précédente (c'est-à-dire soit l'empreinte cryptographique contextuelle précédente soit l'empreinte cryptographique de référence). Dans une première variante, les différentes empreintes cryptographiques contextuelles 10 d'un utilisateur sont chainées les unes avec les autres au sein de la chaine de blocs, formant ainsi, en tant que telles, une chaine à l'intérieur de la chaine de blocs : les empreintes cryptographiques contextuelles successives sont utilisées pour créer une empreinte cryptographique contextuelle courante. Plus particulièrement, dans ce schéma, l'empreinte cryptographique contextuelle de référence est considérée comme l'empreinte au temps tO (c'est-à-dire à l'inscription de 15 l'utilisateur). L'empreinte cryptographique contextuelle calculée au temps t1 (t1>t0), lors de l'authentification de l'utilisateur), tient compte de l'empreinte cryptographique de référence (par exemple en étant intégré (en tant que donnée constitutive) dans le calcul de l'empreinte cryptographique contextuelle calculée au temps t1). L'empreinte cryptographique contextuelle calculée au temps t2 (t2>t1>t0), lors de l'authentification de l'utilisateur, tient compte de 20 l'empreinte cryptographique précédente (par exemple en intégrant l'empreinte cryptographique contextuelle calculée au temps t1) et ainsi de suite. On dispose dans ce cas d'une mesure de sécurité supplémentaire assurant qu'une ancienne empreinte cryptographique contextuelle d'un utilisateur ne puisse être réutilisée. Cette chaine est appelée chaine d'empreintes cryptographiques contextuelles. Elle est unitaire et associé à un seul couple utilisateur/terminal 25 de communication. Elle est représentative d'une timeline (ligne temporelle) d'authentifications successives réalisées par l'utilisateur pour son terminal de communication et assure qu'à un instant donné, une seule empreinte cryptographique contextuelle peut être utilisée pour valider une transaction (i.e. la dernière). De ce fait, il est très difficile (voire impossible) de tenter de réutiliser une ancienne empreinte cryptographique contextuelle de l'utilisateur. 30 Dans une deuxième variante, l'empreinte cryptographique contextuelle est systématiquement liée à l'empreinte cryptographique de référence. Plus particulièrement, 17 l'empreinte cryptographique contextuelle est calculée à partir de l'empreinte cryptographique de référence de l'utilisateur. Ainsi, lorsqu'elle vérifie l'empreinte cryptographique contextuelle, l'entité de vérification (serveur d'authentification, serveur marchand, serveur transactionnel) est en mesure de vérifier également l'authenticité de l'empreinte cryptographique de référence, à 5 l'aide des données d'inscription qu'elle possède. 5.2. Description d'un premier mode de réalisation Le premier mode de réalisation est explicité en relation avec la figure 2. Il comprend une première phase dite d'authentification et une deuxième phase dite de traitement de transaction. Le première phase d'authentification comprend : 10 - une étape d'authentification E10 de l'utilisateur sur son terminal de communication ou auprès du serveur d'authentification, cette étape d'authentification ayant lieu entre par exemple une application d'authentification (AuthAp) et l'utilisateur ; cette étape peut être consécutive à une demande explicite d'authentification ou être implicite (commandée par l'utilisation du terminal de communication); 15 - une étape de transmission E20, au serveur d'authentification, d'un message d'authentification, comprenant la confirmation d'authentification de l'utilisateur et des données complémentaires ; - optionnellement une étape de transmission E30 d'une requête en provenance du serveur d'authentification en vue d'obtenir des données complémentaires si celles-ci ne sont pas 20 transmises avec le message d'authentification ; - et optionnellement, une étape E40 de transmission de ces données complémentaires - une étape de calcul E50 d'une empreinte cryptographique contextuelle à l'aide des données reçues en provenance du terminal de communication ; - une étape d'insertion E60 de l'empreinte cryptographique contextuelle au sein de la 25 chaine de blocs ; et - lorsque le bloc de la chaine de bloc au sein duquel l'empreinte cryptographique contextuelle a été insérée est validé, une étape de transmission E70 de l'empreinte cryptographique contextuelle au terminal de communication (selon l'un des modes de transmission préalablement décrit, direct ou indirect, par l'intermédiaire d'une adresse de 30 localisation de l'empreinte au sein de la chaine de blocs) ; 18 Une fois cette phase d'authentification terminée, le terminal de communication dispose d'une empreinte cryptographique contextuelle (ou d'une adresse vers celle-ci) et le serveur d'authentification dispose de cette empreinte cryptographique contextuelle également. Comme indiqué précédemment, cette phase d'authentification peut être itérée plusieurs fois avant que le 5 terminal de communication n'initie la phase de traitement de transaction (auquel cas le terminal de communication dispose de la dernière empreinte cryptographique contextuelle en date). La deuxième phase de traitement de transaction comprend : une étape de transmission T10 par le terminal de communication, d'une requête de validation de transaction, comprenant l'empreinte cryptographique contextuelle (ou sa 10 référence) au serveur marchand ; cette étape peut être consécutive à la validation d'un panier d'achat sur le site du marchand par exemple ou encore être consécutive à la fourniture, par le terminal de paiement de données de paiement à un serveur transactionnel (le serveur marchand étant alors remplacé par un serveur transactionnel); une étape de T20 de transmission, par le serveur marchand (ou le serveur transactionnel), 15 de l'empreinte cryptographique contextuelle au serveur d'authentification ; une étape de vérification T30, de la validité de l' empreinte cryptographique contextuelle par le serveur d'authentification ; et lorsque l'empreinte cryptographique contextuelle est valide, une étape de transmission T40 au serveur marchand (ou au serveur transactionnel) d'un message de validation de 20 l'empreinte cryptographique contextuelle une étape de T50 de transmission, au terminal de communication, d'un message de validation de transaction. Ainsi, dans ce mode de réalisation, l'empreinte cryptographique contextuelle est utilisée pour faire la preuve de l'authentification de l'utilisateur (et de sa présence « récente » par la 25 même occasion). Le terminal de communication transmet l'empreinte cryptographique contextuelle au serveur marchand qui l'utilise pour vérifier sa validité auprès du serveur d'authentification. L'étape de vérification T30, de la validité de l'empreinte cryptographique contextuelle peut se limiter à constater la validité du bloc dans laquelle l'empreinte cryptographique 30 contextuelle est enregistrer et ainsi se baser sur le caractère de confiance de la chaine de blocs, sans autre forme de vérification plus complexe. Cette vérification peut également comprendre le 19 calcul, à l'aide des données transmises par le terminal de communication (en sus de l'empreinte cryptographique contextuelle) d'une empreinte cryptographique de vérification et la comparaison de cette empreinte cryptographique de vérification avec l'empreinte cryptographique contextuelle fournie. Astucieusement, la vérification de la validité comprend une vérification du 5 fait que l'empreinte cryptographique contextuelle est la dernière en date pour l'utilisateur et/ou le terminal de communication. Par ailleurs, la vérification comprend la vérification de l'identité d'au moins une des données ayant servi à créer l'empreinte cryptographique contextuelle avec une donnée en possession du serveur qui effectue cette vérification (comme par exemple un hash d'une donnée de carte bancaire et/ou un hash d'une donnée biométrique et/ou un hash d'un mot 10 de passe et/ou d'un login). L'implémentation effective de cette vérification est dépendante des conditions opérationnelles de mise en oeuvre. Lorsque la vérification est positive, l'empreinte est validée (c'est-à-dire qu'une donnée, par exemple un booléen) valide l'authenticité de l'empreinte (et/ou du bloc dans laquelle elle est insérée). 5.3. Description d'un deuxième mode de réalisation 15 Dans ce deuxième mode de réalisation, la chaine de blocs est partagée avec les serveurs marchand (soit directement soit par l'intermédiaire d'un serveur transactionnel). La phase d'authentification est identique à celle décrite en relation avec la figure 2 et n'est pas décrite à nouveau (la seule différence étant la réception E71, par le terminal de communication, d'une adresse (@) à laquelle se situe l'empreinte cryptographique contextuelle (plutôt que sa 20 transmission directe). Ainsi, la phase de traitement de transaction, décrite en relation avec la figure 3, comprend alors : une étape de transmission 110 par le terminal de communication, d'une requête de validation de transaction, comprenant l'adresse de l'empreinte cryptographique contextuelle au serveur marchand ; 25 une étape de 120 de transmission, par le serveur marchand, à un serveur transactionnel de l'adresse de l'empreinte cryptographique contextuelle ; ou o une étape de 121 d'accès, par le serveur marchand, à l'adresse de la chaine de blocs comprenant l'empreinte cryptographique contextuelle ; une étape de vérification 130, de la validité de l'empreinte cryptographique contextuelle 30 par le serveur transactionnel ; ou 20 o une étape de vérification 131, de la validité de l'empreinte cryptographique contextuelle par le serveur marchand ; lorsque l'empreinte cryptographique contextuelle est valide, une étape de transmission 140 par le serveur transactionnel, au serveur marchand, d'un message de validation de I' 5 empreinte cryptographique contextuelle, si le serveur transactionnel est en coupure du serveur marchand (sinon, une étape de vérification 141 par la serveur marchand lui-même) ; une étape 150 de transmission, au terminal de communication, d'un message de validation de transaction. 10 Ainsi, dans ce mode de réalisation, l'empreinte cryptographique contextuelle est utilisée pour faire la preuve de l'authentification de l'utilisateur, de manière indirecte, sans faire appel au serveur d'authentification, qui conserve sa seule fonction d'authentification des utilisateurs sur leurs terminaux. Le terminal de communication transmet l'adresse de l'empreinte cryptographique contextuelle au serveur marchand qui l'utilise pour vérifier sa validité (soi 15 directement soi à l'aide du serveur transactionnel). Ce mode de réalisation présente l'avantage de ne pas mettre l'empreinte cryptographique contextuelle à disposition du terminal de communication, augmentant ainsi la sécurité (car diminuant le risque de vol de cette empreinte cryptographique contextuelle). L'étape de vérification de la validité de l'empreinte cryptographique contextuelle est la 20 même que pour le premier mode de réalisation et peut être unique ou multiple, en fonction du chainage ou non de cette empreinte cryptographique contextuelle avec une empreinte cryptographique précédente (de référence ou contextuelle). 5.4. Dispositif pour la mise en oeuvre de l'invention On présente, en relation avec la figure 4, une architecture simplifiée d'un serveur 25 d'authentification apte à gérer des empreintes contextuelles en conjonction avec des dispositifs mobiles. Un serveur d'authentification comprend une mémoire 41, une unité de traitement 42 équipée par exemple d'un microprocesseur, et pilotée par le programme d'ordinateur 43, mettant en oeuvre le procédé tel que précédemment décrit. Dans au moins un mode de réalisation, l'invention est mise en oeuvre sous la forme d'une application installée sur un serveur. 30 Un tel serveur comprend : 21 des moyens d'obtention d'une empreinte cryptographique contextuelle, préalablement générée au cours d'une authentification d'un utilisateur sur un terminal de communication ; des moyens de vérification de validité de l'empreinte cryptographique contextuelle au 5 sein d'une chaine de blocs comprenant un ensemble d'empreintes cryptographiques ; des moyens de validation d'une transaction lorsque les moyens de vérification de validité de l'empreinte cryptographique contextuelle au sein d'une chaine de blocs fournissent une réponse positive. On présente, en relation avec la figure 5, une architecture simplifiée d'un dispositif mobile 10 apte à effectuer des transactions à l'aide d'une empreinte contextuelle. Un tel dispositif mobile comprend une mémoire 51, une unité de traitement 52 équipée par exemple d'un microprocesseur, et pilotée par le programme d'ordinateur 53, mettant en oeuvre le procédé selon l'invention. Dans au moins un mode de réalisation, l'invention est mise en oeuvre sous la forme d'une application mobile installée sur un dispositif mobile en possession de l'utilisateur. Un 15 tel dispositif mobile comprend : des moyens de génération d'une empreinte cryptographique contextuelle ou de référence ; des moyens de transmission de ladite empreinte cryptographique et/ou de données de constitution de cette empreinte à un serveur d'authentification ; 20 des moyens de réalisation de transaction de paiement auprès d'un serveur marchand, comprenant la mise en oeuvre des moyens de transmission d'une empreinte cryptographique contextuelle et/ou d'un lien vers une empreinte cryptographique contextuelle; des moyens de réception d'une donnée représentative de la validation de la transaction 25 par ledit serveur. Ces moyens se présentent sous la forme d'une application logicielle spécifique, ou encore sous la forme de composants matériels dédiés, tel qu'un élément de sécurisation (SE) ou un environnement d'exécution sécurisé. L'élément de sécurisation peut se présenter sous la forme d'une carte Sim, USim, UICC, ou encore un composant de sécurité spécifique, greffé sur la carte 30 mère du terminal de communication. Plus particulièrement, dans au moins un mode de réalisation, ces moyens se présentent sous la forme de plusieurs composants matériels auxquels 22 sont adjoint plusieurs composants logiciels. Plus particulièrement, les moyens d'émission sont par exemple compris dans un composant sécurisé qui comprend par exemple un accès plus ou moins direct à un contrôleur d'émission/réception, permettant d'interroger directement un serveur. Ce composant sécurisé est en charge de la détermination au moins partielle d'un paramètre de calcul 5 du code de certification. Les autres composants du terminal de communication ont fait l'objet d'une REVENDICATIONS1. Procédé de traitement d'une transaction, procédé mis en o=uvre par un dispositif électronique de traitement de transactions, accessible par l'intermédiaire d'un réseau de communication, ledit procédé de traitement comprenant une phase de traitement de transaction caractérisée en ce qu'elle comprenant : une étape d'obtention (T10, T20, 110, 120, 121) d'une empreinte cryptographique contextuelle, préalablement générée au cours d'une authentification d'un utilisateur sur un terminal de communication ; une étape de vérification (T30, 130) de validité de l'empreinte cryptographique contextuelle au sein d'une chaine de blocs comprenant un ensemble d'empreintes cryptographiques ; une étape de validation (T40, 140) d'une transaction lorsque l'étape de de vérification (T30, 130) de validité de l'empreinte cryptographique contextuelle au sein d'une chaine de blocs est positive. 2. Procédé de traitement d'une transaction selon la revendication 1, caractérisé en ce qu'une empreinte cryptographique contextuelle (EC) est matérialisée par une chaine d'identification Ch/EC de l'empreinte cryptographique EC qui est obtenue à partir d'un ensemble D de données constitutrices (d0,...,dn) de la manière suivante : ChlEC = F (G (d0,...,dn)) dans laquelle : - G est une fonction de mélange de données ; - F est une fonction cryptographique de calcul de la chaine d'identification. 3. Procédé de traitement d'une transaction selon la revendication 1, caractérisé en ce que l'étape d'obtention de l'empreinte cryptographique contextuelle comprend : - une étape de réception d'une adresse de localisation de l'empreinte cryptographique contextuelle au sein de la chaine de blocs ; 24 une étape d'obtention de l'empreinte cryptographique contextuelle à l'adresse précédemment reçue. 4. Procédé de traitement d'une transaction selon la revendication 1, caractérisé en ce que 5 l'étape de vérification (T30, 130) de validité de l'empreinte cryptographique contextuelle comprend une étape de vérification de la validité du bloc de la chaine de blocs au sein de laquelle l'empreinte cryptographique contextuelle est insérée. 5. Procédé de traitement d'une transaction selon la revendication 1, caractérisé en ce que 10 l'étape de vérification (T30, 130) de validité de l'empreinte cryptographique contextuelle comprend une étape de détermination que l'empreinte cryptographique contextuelle est la dernière empreinte cryptographique contextuelle en date pour ledit utilisateur et/ou ledit terminal de communication au sein de la chaine de blocs. 15 6. Procédé de traitement d'une transaction selon la revendication 1, caractérisé en ce que l'étape de vérification (T30, 130) de validité de l'empreinte cryptographique contextuelle comprend : une étape d'obtention de données de transaction, en provenance du terminal de communication ; 20 une étape de calcul, à partir de ces données de transaction, d'une empreinte cryptographique de vérification ; une étape de comparaison de empreinte cryptographique de vérification avec l'empreinte cryptographique contextuelle ; et une étape de validation de l'empreinte cryptographique contextuelle lorsque la 25 comparaison est positive. 7. Procédé de traitement d'une transaction selon la revendication 1, caractérisé en ce que l'étape de vérification (T30, 130) de validité de l'empreinte cryptographique contextuelle comprend une étape de comparaison d'au moins une donnée de constitution de 30 l'empreinte cryptographique contextuelle avec au moins une donnée correspondante fournie par le terminal de communication. 25 8. Procédé de traitement d'une transaction selon la revendication 1, caractérisé en ce qu'il comprend en outre une phase préliminaire d'authentification, au cours de laquelle l'empreinte cryptographique contextuelle est créée, ladite phase préliminaire 5 d'authentification comprenant : une étape d'authentification E10 de l'utilisateur ; une étape d'obtention E20 d'un message d'authentification, comprenant la confirmation d'authentification de l'utilisateur et un ensemble D de données constitutrices (d0,...,dn) ; une étape de calcul E50 de l'empreinte cryptographique contextuelle à l'aide des données 10 reçues ; 9. Procédé de traitement d'une transaction selon la revendication 8, caractérisé en ce que la phase préliminaire d'authentification comprend en outre : 15 une étape d'insertion E60 de l'empreinte cryptographique contextuelle au sein de la chaine de blocs ; et lorsque le bloc de la chaine de bloc au sein duquel l'empreinte cryptographique contextuelle a été insérée est validé, une étape de transmission E70 de l'empreinte cryptographique contextuelle au terminal de communication. 20 10. Dispositif électronique de traitement de transactions, accessible par l'intermédiaire d'un réseau de communication, ledit dispositif comprenant des moyens de traitement comprenant de transaction et caractérisé en ce qu'il comprend : des moyens d'obtention d'une empreinte cryptographique contextuelle, préalablement 25 générée au cours d'une authentification d'un utilisateur sur un terminal de communication ; des moyens de vérification de validité de l'empreinte cryptographique contextuelle au sein d'une chaine de blocs comprenant un ensemble d'empreintes cryptographiques ; des moyens de validation d'une transaction mis en oeuvre lorsque les moyens de 30 vérification (T30, 130) de validité de l'empreinte cryptographique contextuelle au sein d'une chaine de blocs fournissent une information positive. 26 11. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution d'un procédé selon la revendication 1, lorsqu'il est exécuté 5 sur un ordinateur.