Method for processing a transaction, apparatus, system and associated program

DE602019069670T2Active Publication Date: 2025-05-07BANKS & ACQUIRERS INT HLDG SAS
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
DE602019069670
Authority / Receiving Office
DE · DE
Patent Type
Patents
Current Assignee / Owner
Priority Date
2018-09-25
Filing Date
2019-09-25
Publication Date
2025-05-07
Estimated Expiration
2039-09-25

AI Technical Summary

Technical Problem

Existing user authentication methods for mobile transactions in 'Card Not Present' (CNP) mode are prone to fraud due to the inability to verify the cardholder's PIN code and the risk of stolen devices being used for fraudulent transactions.

Method used

A method that records user authentications within a distributed database using contextual cryptographic imprints, which are validated within a chain of blocks to ensure the integrity and uniqueness of the authentication, thereby preventing fraudulent transactions.

Benefits of technology

This solution effectively validates user authentication and prevents fraudulent transactions by ensuring that only valid, unique contextual cryptographic imprints can be used for transaction validation, significantly reducing the risk of fraud in mobile transactions.

✦ Generated by Eureka AI based on patent content.
Patent Text Reader
Need to check novelty before this filing date? Find Prior Art

Description

1. Domain

[0001] The invention relates to the field of user authentication. The invention relates more particularly to the authentication of users during transactions involving the implementation of a user device, also called a communication terminal. The invention relates more particularly to user authentication within a distributed database within a communication network. More specifically still, an object of the present technique is to increase the level of security of a data transmission in the context of the processing of a transaction (such as a mobile payment) carried out with a portable communication terminal (for example a smartphone or a tablet). 2. Prior Art

[0002] In general, the number of online payments is constantly increasing. Mobile payments represent a particular type of online payments and a growing share of them. They can be made through payment providers, such as Paypal ™< , or by using traditional banking organizations, using a payment card.

[0003] However, online payments are marked by a relatively high fraud rate. In France, it is estimated that approximately 5% of online payments made over the Internet are fraudulent. These five percent fraudulent payments represent approximately 33% of the total cost of fraud. It is therefore necessary to have means to both identify fraud attempts and block them.

[0004] One of the problems with mobile transactions is that they are carried out in "card not present" mode (i.e. CNP, for "card not present"In this mode, since no device is responsible for verifying the integrity of the card (such as a payment terminal), it is not possible to verify that the cardholder has the PIN code necessary to validate a transaction: the payment card is not used to carry out the transaction. Only the data written on the card is. This data can be stolen to carry out transactions by fraudsters, possibly using other merchant applications, as part of other mobile payments. Incidentally, the user's communication terminal (which includes all the data of the payment cards used by the user), can also be stolen, giving the thief access to all the user's data and allowing the thief to carry out fraudulent transactions.

[0005] Thus, in order to secure transactions carried out in CNP mode, systems and methods have been proposed to resolve these fraud problems. These methods pose problems of convenience for the user or other security problems. This is for example the method described in patent document WO2012053780. In this document, a verification system and method are described. More particularly, a method and a system using information on the MAC address of a client terminal are described. During a transaction involving a payment, an authentication process is implemented in which the MAC address of the terminal used by the user wishing to make a payment is compared to a reference MAC address, defined or obtained by the banking server, server which must authorize a payment or a transaction.

[0006] This method, while potentially interesting, is nonetheless impractical. First, it requires the user to always use the same device to make a payment (unless multiple devices are authorized to make a transaction). Second, there are many methods for spoofing a device's MAC address.

[0007] Other methods are also available. Some involve providing the user with unique bank card numbers. These numbers are provided based on the customer's needs. This method is attractive but does not eliminate the user's ability to use their own card information to complete transactions. Other methods, currently widely used, involve sending an SMS-type message to the customer making a transaction to ensure that they are the cardholder. The user must enter a password transmitted in the SMS at the time of the transaction. Therefore, the bank ensures with a reasonable probability that the person making the transaction is the user.This method has two disadvantages: firstly, it requires the user to provide their phone number to the bank before any transaction and in a secure manner; secondly, and above all, this method only works if the customer's bank is also the bank that handles the transaction on behalf of the merchant, which is not necessarily the case, especially abroad, precisely where most of the fraud is carried out. Thus, the aforementioned method is not very effective in this case. 3. Summary

[0008] The method proposed by the inventors does not pose these problems of the prior art. Indeed, a method for securing the transaction is proposed based on the recording, within a distributed database, of the user's authentications with his communication terminal. More particularly, the present technique delivers, within a distributed database, user authentications on his communication terminal, these authentications being subsequently used to validate a transaction carried out by the user.

[0009] More particularly, a method for processing a transaction is described, a method implemented by an electronic transaction processing device, accessible via a communication network. According to the invention, such a processing method comprises a transaction processing phase characterized in that it comprises: a step of obtaining a contextual cryptographic fingerprint, previously generated during authentication of a user on a communication terminal; a step of verifying the validity of the contextual cryptographic fingerprint within a blockchain comprising a set of cryptographic fingerprints; a step of validating a transaction when the step of verifying the validity of the contextual cryptographic fingerprint within a blockchain is positive.

[0010] Thus, according to the invention, the problems of the prior art are at least partially resolved by ensuring that a transaction, for example a mobile payment transaction, can be validated by means of successful authentication of the user on his communication terminal and the validation (and not repudiation) of this authentication within a blockchain.

[0011] According to a particular characteristic, a contextual cryptographic fingerprint ( EC ) is materialized by an identification chain ChIEC of the cryptographic fingerprint EC which is obtained from a set D of constituent data (d0,...,dn) in the following manner: ChIEC = F G d 0 , … , dn in which: G is a data mixing function; F is a cryptographic function for calculating the identification string.

[0012] Thus, it is ensured that a contextual cryptographic fingerprint (EC) is not reproducible within the blockchain, and that it is unique, at a given moment, for a set of constituent data.

[0013] According to a particular embodiment, the step of obtaining the contextual cryptographic fingerprint comprises: a step of receiving a location address of the contextual cryptographic fingerprint within the blockchain; a step of obtaining the contextual cryptographic fingerprint at the previously received address.

[0014] Thus, the contextual cryptographic fingerprint cannot be forged.

[0015] According to a particular characteristic, the step of verifying the validity of the contextual cryptographic fingerprint comprises a step of verifying the validity of the block of the blockchain within which the contextual cryptographic fingerprint is inserted.

[0016] This ensures that the contextual cryptographic fingerprint is valid with respect to the block itself.

[0017] According to a particular characteristic, the step of verifying the validity of the contextual cryptographic fingerprint comprises a step of determining that the contextual cryptographic fingerprint is the latest contextual cryptographic fingerprint to date for said user and / or said communication terminal within the blockchain.

[0018] This ensures that only the last available contextual cryptographic fingerprint can be used for transaction validation: this resolves replay problems.

[0019] According to a particular characteristic, the step of verifying the validity of the contextual cryptographic fingerprint comprises: a step of obtaining transaction data from the communication terminal; a step of calculating, from this transaction data, a verification cryptographic fingerprint; a step of comparing the verification cryptographic fingerprint with the contextual cryptographic fingerprint; and a step of validating the contextual cryptographic fingerprint when the comparison is positive.

[0020] This provides the additional possibility of verifying the contextual cryptographic fingerprint against the data that constitutes it.

[0021] According to a particular embodiment, the step of verifying the validity of the contextual cryptographic fingerprint comprises a step of comparing at least one piece of data constituting the contextual cryptographic fingerprint with at least one corresponding piece of data provided by the communication terminal.

[0022] According to a particular embodiment, the method for processing a transaction further comprises a preliminary authentication phase, during which the contextual cryptographic fingerprint is created, said preliminary authentication phase comprising: a step of authenticating the user; a step of obtaining an authentication message, comprising the user authentication confirmation and a set D of constituent data (d0,...,dn) ; a step of calculating the contextual cryptographic fingerprint using the received data;

[0023] According to a particular embodiment, the preliminary authentication phase further comprises: a step of inserting the contextual cryptographic fingerprint into the blockchain; and when the block of the blockchain into which the contextual cryptographic fingerprint has been inserted is validated, a step of transmitting the contextual cryptographic fingerprint to the communication terminal.

[0024] According to another aspect, the invention also relates to an electronic transaction processing device, accessible via a communication network, said device comprising transaction processing means. Such a device comprises: means for obtaining a contextual cryptographic fingerprint, previously generated during authentication of a user on a communication terminal; means for verifying the validity of the contextual cryptographic fingerprint within a blockchain comprising a set of cryptographic fingerprints; means for validating a transaction implemented when the means for verifying the validity of the contextual cryptographic fingerprint within a blockchain provide positive information.

[0025] It is understood, within the framework of the description of the present technique according to the invention, that a step of transmitting information and / or a message from a first device to a second device corresponds at least partially, for this second device to a step of receiving the information and / or the message transmitted, whether this reception and this transmission is direct or whether it is carried out by means of other transport, gateway or intermediation devices, including the devices described herein according to the invention.

[0026] According to a preferred implementation, the different steps of the methods according to the invention are implemented by one or more software or computer programs, comprising software instructions intended to be executed by a data processor of a relay module according to the invention and being designed to control the execution of the different steps of the methods, implemented at the level of the communication terminal, the authentication server and the merchant server.

[0027] Consequently, the invention also relates to programs, capable of being executed by a computer or by a data processor, these programs comprising instructions for controlling the execution of the steps of the methods as mentioned above.

[0028] A program may use any programming language, and may be in the form of source code, object code, or code intermediate between source code and object code, such as in a partially compiled form, or in any other desirable form.

[0029] The invention also relates to an information medium readable by a data processor, and comprising instructions of a program as mentioned above.

[0030] The information carrier may be any entity or device capable of storing the program. For example, the carrier may include a storage medium, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a mobile medium (memory card) or a hard disk or an SSD.

[0031] On the other hand, the information carrier may be a transmissible carrier such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means. The program according to the invention may in particular be downloaded from a network such as the Internet.

[0032] Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to perform or to be used in the performance of the method in question.

[0033] According to one embodiment, the invention is implemented by means of software and / or hardware components. In this regard, the term "module" may correspond in this document to a software component, a hardware component or a set of hardware and software components.

[0034] A software component corresponds to one or more computer programs, one or more sub-programs of a program, or more generally to any element of a program or software capable of implementing a function or a set of functions, as described below for the module concerned. Such a software component is executed by a data processor of a physical entity (terminal, server, gateway, set-top-box, router, etc.) and is likely to access the hardware resources of this physical entity (memories, recording media, communication buses, electronic input / output cards, user interfaces, etc.).

[0035] Similarly, a hardware component is any element of a hardware assembly capable of implementing a function or set of functions, as described below for the module concerned. It may be a programmable hardware component or one with an integrated processor for running software, for example an integrated circuit, a smart card, a memory card, an electronic card for running firmware, etc.

[0036] Each component of the system described above of course implements its own software modules.

[0037] The different embodiments mentioned above can be combined with each other to implement the invention. 4. Figures

[0038] Other characteristics and advantages of the invention will appear more clearly on reading the following description of a preferred embodiment, given as a simple illustrative and non-limiting example, and the appended drawings, among which: there figure 1 describes a system in which the invention is implemented; the figure 2 describes a derived embodiment of the transaction processing method; figure 3 describes a derived embodiment of the transaction processing method; figure 4 illustrates an architecture of a server capable of implementing a transaction processing method; the Figure 5 illustrates an architecture of a client capable of implementing a transaction processing method. 5. Description 5.1. Reminders of the principle

[0039] It has been previously stated that implementing payment transactions in "card not present" mode increases the risk of fraud. The purpose of the present technique is to remedy, at least in part, certain disadvantages of transactions in "card not present" mode. card not present » by introducing an identity verification mechanism, allowing the merchant to be provided with (holder of an online sales service, via a -set- of- merchant- servers-) a confirmation (with reasonable certainty) of the user's identity (and their legitimacy to make the purchase and the resulting payment transaction). In the present technique, a blockchain is implemented, the blockchain recording characteristics of successive user authentications (these characteristics being called contextual cryptographic fingerprints).

[0040] In one embodiment, described in connection with the figure 1, the technique is implemented within a system comprising several different entities, cooperating and each of them implementing a suitable method. More particularly, the system comprises: an authentication server (AuthSrv), implementing a blockchain, in which the authentication proofs of the users are recorded, in a blockchain (BIcCh); a set of communication terminals (TComs), each terminal being owned by a user who uses his communication terminal to make purchases and / or carry out transactions; a set of merchant servers (MerchtSrvs), owned and implemented by one or more providers of goods and / or online services accessible via the communication terminals;

[0041] These servers and terminals exchange data via one or more communications networks (Ntwk) to which they are connected.

[0042] The general principle of the technique consists of transmitting, to the merchant server, a contextual cryptographic fingerprint (Ecc), representative of an authentication (auth) of a user on his communication terminal, this contextual cryptographic fingerprint (Ecc) being able to be verified by the authentication server before validation of the payment transaction by the merchant server and / or a transactional server (banking server, payment server). the issuepayment data). In a first embodiment, the authentication server is able to validate the contextual cryptographic fingerprint transmitted by the (or on behalf of the) communication terminal to the merchant server, thanks to the blockchain (BIcCh) that it implements. In a second embodiment, the authentication server is able to calculate the contextual cryptographic fingerprint of the communication terminal, then transmit it to the merchant server, again thanks to the blockchain (BlcCh) that it implements. This provides a certain assurance of user authentication when the transaction is validated, which significantly reduces the fraud rate of payment methods.

[0043] According to the present technique, in one embodiment, a cryptographic fingerprint is issue of a data structure which includes: constituent data: data relating to authentication such as a timestamp, a sender (e.g. communication terminal identifier), a receiver (e.g. identifier of an authentication service); optionally a number of blocks having confirmed the cryptographic fingerprint provided (number of validation blocks); and possibly other contextual information: IP address, geographical position, previous cryptographic fingerprint (of the user), etc.).

[0044] The fingerprint itself is an identification string (cryptographic fingerprint identifier), resulting from a calculation performed on the data used to create the cryptographic fingerprint listed above. This cryptographic fingerprint (identification string) can, once this calculation has been performed, be integrated into the data structure described above. This data structure can, depending on the case, be stored by the authentication server in a database specifically dedicated to this purpose, be integrated into the blockchain, or even be deleted, if it is not necessary to have access to this data.

[0045] A reference cryptographic fingerprint (the implementation of which is described below) may also include (and / or be derived from) data relating to user authentication (biometric signatures, identifier signature, password signature, etc.). A contextual cryptographic fingerprint may include (and / or be derived from) a reference (for example in the form of an identification string) to a previous cryptographic fingerprint.

[0046] Either D all the constituent (initiating) data (d0,...,dn) of the cryptographic fingerprint EC. Let F be the cryptographic function for calculating the identification string ChIEC which is considered the cryptographic fingerprint EC. Either G a data mixing function. The identification string ChIEC of the cryptographic fingerprint EC is calculated as follows: ChIEC = F G d 0 , … , dn

[0047] The calculation function F and the mixing function G are not specifically detailed and depend on the operational implementation conditions of the blockchain at the authentication servers. The G function is a data mixing function of the type concatenation function, hexadecimal addition, multiplication, decimal modulo, hexadecimal modulo or binary modulo, rotation (decimal, hexadecimal, binary), etc. The function F can for example be a hash function (for example the MD5 function or the SHA1 function) of the result of the function G. The hash fingerprint (or "hash value") obtained thus forms a cryptographic condensate representative of the constituent data, without it being possible to find these constituent data from this hash fingerprint. In the following and in the preceding, we mainly use the term "cryptographic fingerprint" (EC) to refer to the identification string of the latter (i.e. the identifier of the cryptographic fingerprint ChIEC ) , which allows this cryptographic imprint to be identified within the blockchain.

[0048] Generally speaking, the proposed technique is based on several phases of creation and processing of authentication data.

[0049] In a first registration phase, a user has completed the necessary steps to register online for a service, which service may manage the user's authentication. For example, this registration may take place when the user activates his or her communication terminal for the first time. In this registration phase, the user provides the entity acting as the authentication server with the data necessary for registration (surname, first name) and future authentication (password and / or fingerprints and / or iris and / or other biometric or other data).

[0050] The authentication server stores these elements securely. In addition, according to this technique,the authentication server can calculate, from these elements, a reference cryptographic fingerprint. This reference cryptographic fingerprint, calculated by the authentication server (according to methods identical to those presented previously), can be inserted into a chain of blocks (and transmitted, in return to the communication terminal which records it in a secure memory space). This is normally the same chain of blocks as that which is used to globalize the successive authentications of users with respect to the authentication server (or the farm of authentication servers).As previously explained, the blockchain is not normally a public blockchain, but rather a private blockchain, reserved for the use of the authentication server (or all authentication servers) and optionally certain merchant servers (online sales servers) having access to this blockchain. The conditions for sharing this blockchain with merchant servers will be explained later, within the framework of a particular embodiment of the invention. Alternatively, the reference cryptographic fingerprint can be calculated by the communication terminal itself and transmitted to the authentication server (optionally with the data constituting it).

[0051] In any case, at the end of this registration phase, the authentication server(s) have the elements necessary for user authentication. When the user starts or uses their mobile terminal, they perform an authentication action with respect to the authentication server. This authentication action is either explicit (an authentication service explicitly requires the user to authenticate on their terminal) or implicit (during the use or startup of the terminal, authentication to the service has been performed, for example when unlocking the communication terminal or during a default connection to a given service, via the communication terminal, for example, an email service, a centralized authentication service).More specifically, implicit authentication is performed, for example, when the communication terminal is started when the user enters a password or provides biometric data: the authentication server, via a message it receives from the communication terminal, is informed that the user has been correctly authenticated on the communication terminal. Other explicit or implicit authentication modes may also be implemented: this involves confirming or informing the server that authentication on the communication terminal or with an online service has been carried out correctly.

[0052] According to the present technique, these methods have in common the fact that the communication terminal performs an authentication of the user, locally or in cooperation with the authentication server(s), with respect to a certain number of authenticated data (and / or characteristics). More particularly, the terminal and / or the server compares the data (and / or characteristics) provided by the user with reference data. The reference data are obtained during the registration phase (see previously) and stored in secure memory (on the communication terminal and / or on the authentication server). During implicit or explicit authentication, the fact of having performed a valid authentication is recorded within the authentication server, after the reception of a message by the authentication server.

[0053] The message received by the authentication server contains, on the one hand, authentication validation data (for example, password hash or fingerprint or iris signature, or even cryptographic fingerprint) which are accompanied or associated with contextual data (for example, the date, time of authentication, a possible identification of the communication terminal, serial number, IMEI, etc. and / or other relevant contextual data). This data is used by the authentication server to calculate a "contextual" cryptographic fingerprint, as explained above. This contextual cryptographic fingerprint (potentially different from the reference cryptographic fingerprint) is inserted into the blockchain (and is optionally linked to a previous cryptographic fingerprint of the user).The contextual cryptographic fingerprint (or a reference to the contextual cryptographic fingerprint, e.g. a URL) is then returned to the communication terminal, which stores it in secure memory (e.g. in the same memory slot as the reference cryptographic fingerprint).

[0054] Alternatively, a link or reference to the contextual cryptographic fingerprint may be transmitted to the communication terminal. This contextual cryptographic fingerprint constitutes proof of successful authentication of the communication terminal. Receipt of this proof by the communication terminal (having this contextual cryptographic fingerprint recorded on the communication terminal, or having a link or reference to this contextual cryptographic fingerprint), validates the fact (the state), of being correctly authenticated by the authentication server and validates the state of the recording of this authentication within the blockchain.

[0055] More particularly, depending on the embodiments, the contextual cryptographic fingerprint is only transmitted to the communication terminal when the current block of the blockchain (in which the contextual cryptographic fingerprint is recorded) is validated (i.e. complete and the closure of this current block is cryptographically validated and verified), and a new block (at least) is created in the blockchain. More particularly, in these implementations, the contextual cryptographic fingerprint is only delivered to the communication terminal when it is assured that it is no longer modifiable within the blockchain. This lack of possibility of modification is only provided, from the point of view of the blockchain, when the current block is complete and validated, and a new block is “opened” to record the following authentications (and / or registrations).In other words, the transmission to the communication terminal of the contextual cryptographic fingerprint (or a link or reference to it) is not immediate and essentially depends on the time taken by the system as a whole to close the current block of the blockchain (a relatively short time, moreover, if we refer to the number of authentications carried out each day).

[0056] Once the contextual cryptographic fingerprint (or its link or reference) is received by the communication terminal, it can be used in the context of implementing transactions between the communication terminal and one or more providers of goods and / or services with whom the user (of the communication terminal) wishes to carry out transactions.

[0057] More specifically, when implementing a transaction from the communication terminal (an example implementation is described later), the contextual cryptographic fingerprint is used to prove the user's authentication (and presence at the same time). Several methods can be implemented to achieve this authentication validation objective. Generally speaking, these methods share the following characteristics: the user identifies himself to the supplier of goods and / or services (via a login / password pair, implicit or explicit authentication or by other means); the user makes a selection of goods or services that he wishes to acquire; the user performs a payment action, including in particular the provision of payment data (for example payment card data); the merchant server receives the payment data and initiates a payment transaction, which requires obtaining authorization from a transactional server (bank server or issuer server); when the transactional server responds positively to the payment request transmitted by the merchant server, the transaction is validated and the payment made.

[0058] In the present technique, these steps are modified and the contextual cryptographic fingerprint is used to prove the presence of the user, or even to validate the transaction itself. More specifically, the contextual cryptographic fingerprint is transmitted in addition to (or instead of) the payment data. The communication terminal transmits the contextual cryptographic fingerprint to the merchant server (the transmission method can be direct or indirect, as explained later). The merchant server receives this cryptographic fingerprint and transmits it to the authentication server (the authentication server can be the transaction server in this case, although this is not mandatory).

[0059] Depending on the embodiments, the method of transmitting the contextual cryptographic fingerprint may be direct or indirect. When the transmission is direct, the communication terminal transmits this contextual cryptographic fingerprint in a message to the merchant server. The merchant server therefore comes into possession of the contextual cryptographic fingerprint via the communication terminal itself. This method has the advantage of limiting the interactions between the merchant server and, for example, the authentication server or another server. Since the contextual cryptographic fingerprint of the communication terminal is (initially) received directly from the authentication server and stored securely on the communication terminal, it is reasonably believed that it cannot be compromised and that it retains its value as proof of authentication.When the transmission is indirect, the communication terminal transmits to the merchant server a link (for example a URL or a URI) pointing to this contextual cryptographic fingerprint. The advantage is that the communication terminal does not have the contextual cryptographic fingerprint. Even if the communication terminal is compromised, the contextual cryptographic fingerprint is secure at the authentication server. When the merchant server receives the link to the contextual cryptographic fingerprint (link that directs it to the authentication server (or the transactional server or other and / or to the blockchain)), it is possible to verify the validity of the contextual cryptographic fingerprint within the blockchain.Thus, this second possibility is advantageous when the blockchain is accessible to several identified actors (such as the authentication server, the merchant server and / or the transactional server). The transmitted link (reference) allows access to the blockchain, managed by the transactional server(s).

[0060] Regardless of the method used (direct or indirect), the merchant server (or the authentication server or the transaction server) verifies the validity of the contextual cryptographic fingerprint provided, within the blockchain, in particular by verifying whether the contextual cryptographic fingerprint provided is valid given the block in which it is inserted (first verification) and optionally whether the contextual cryptographic fingerprint provided is the user's latest contextual cryptographic fingerprint (second verification).For the first verification, the server that performs the verification obtains from the provided contextual cryptographic fingerprint, data relating to the authentication: timestamp, sender (for example communication terminal identifier), receiver (for example identifier of an authentication service), and a number of blocks having confirmed the provided contextual cryptographic fingerprint (number of validation blocks) and possibly other context information: IP address, geographical position, previous cryptographic fingerprint (of the user), etc.). The server is able, from this data, to verify that it provides (after calculation) a fingerprint identical to the provided contextual cryptographic fingerprint.

[0061] For the second verification, the contextual fingerprint is linked to a previous fingerprint (i.e., either the previous contextual fingerprint or the reference fingerprint).

[0062] In a first variant, distinct from or complementary to the second variant, the different contextual cryptographic fingerprints of a user are chained together within the blockchain, thus forming, as such, a chain within the blockchain: the successive contextual cryptographic fingerprints are used to create a current contextual cryptographic fingerprint. More particularly, in this scheme, the reference contextual cryptographic fingerprint is considered to be the fingerprint at time t0 (i.e., at user registration). The contextual cryptographic fingerprint calculated at time t1 (t1>t0), during user authentication), takes into account the reference cryptographic fingerprint (for example by being integrated (as constituent data) in the calculation of the contextual cryptographic fingerprint calculated at time t1).The contextual cryptographic fingerprint calculated at time t2 (t2>t1>t0), during user authentication, takes into account the previous cryptographic fingerprint (for example by integrating the contextual cryptographic fingerprint calculated at time t1) and so on. In this case, we have an additional security measure ensuring that a user's old contextual cryptographic fingerprint cannot be reused. This chain is called a contextual cryptographic fingerprint chain. It is unitary and associated with a single user / communication terminal pair. It is representative of a timeline (time line) of successive authentications carried out by the user for his communication terminal and ensures that at a given time, a single contextual cryptographic fingerprint can be used to validate a transaction (i.e. the last one, in the sense of the latest contextual cryptographic fingerprint).Therefore, it is very difficult (if not impossible) to attempt to reuse an old contextual cryptographic fingerprint of the user (by a replay attack for example).

[0063] In a second variant, distinct from or complementary to the first, the contextual cryptographic fingerprint is systematically linked to the reference cryptographic fingerprint. More particularly, the contextual cryptographic fingerprint is calculated from the user's reference cryptographic fingerprint. Thus, when it verifies the contextual cryptographic fingerprint, the verification entity (authentication server, merchant server, transaction server) is able to also verify the authenticity of the reference cryptographic fingerprint, using the registration data it possesses. 5.2. Description of a first embodiment

[0064] The first embodiment is explained in relation to the figure 2It includes a first phase called authentication and a second phase called transaction processing.

[0065] The first phase of authentication includes: a step E10 of authenticating the user on his communication terminal or with the authentication server, this authentication step taking place between for example an authentication application (AuthAp) and the user; this step can be consecutive to an explicit authentication request or be implicit (controlled by the use of the communication terminal); a step E20 of transmitting, to the authentication server, an authentication message, comprising the confirmation of authentication of the user and additional data; optionally a step E30 of transmitting a request from the authentication server in order to obtain additional data if these are not transmitted with the authentication message; and optionally, a step E40 of transmitting these additional data;a step E50 of calculating a contextual cryptographic fingerprint using the data received from the communication terminal; a step E60 of inserting the contextual cryptographic fingerprint into the blockchain; and when the block of the blockchain into which the contextual cryptographic fingerprint has been inserted is validated, a step E70 of transmitting the contextual cryptographic fingerprint to the communication terminal (according to one of the transmission modes previously described, direct or indirect, via an address locating the fingerprint within the blockchain); ;

[0066] Once this authentication phase is completed, the communication terminal has a contextual cryptographic fingerprint (or an address to it) and the authentication server has this contextual cryptographic fingerprint as well. As previously indicated, this authentication phase can be iterated several times before the communication terminal initiates the transaction processing phase (in which case the communication terminal has the latest contextual cryptographic fingerprint, i.e. the last one created).

[0067] The second phase of transaction processing includes: a transmission step T10 by the communication terminal of a transaction validation request, comprising the contextual cryptographic fingerprint (or its reference) to the merchant server; this step may follow the validation of a shopping cart on the merchant's site for example or may follow the provision, by the payment terminal, of payment data to a transactional server (the merchant server then being replaced by a transactional server); a transmission step T20, by the merchant server (or the transactional server), of the contextual cryptographic fingerprint to the authentication server; a verification step T30, of the validity of the contextual cryptographic fingerprint by the authentication server;and when the contextual cryptographic fingerprint is valid, a step T40 of transmission to the merchant server (or to the transactional server) of a message validating the contextual cryptographic fingerprint; a step T50 of transmission, to the communication terminal, of a transaction validation message.;

[0068] Thus, in this embodiment, the contextual cryptographic fingerprint is used to prove the user's authentication (and their "recent" presence at the same time). The communication terminal transmits the contextual cryptographic fingerprint to the merchant server which uses it to verify its validity with the authentication server.

[0069] The verification step T30 of the validity of the contextual cryptographic fingerprint may be limited to ascertaining the validity of the block in which the contextual cryptographic fingerprint is recorded and thus be based on the trustworthiness of the blockchain, without any other more complex form of verification. This verification may also include the calculation, using the data transmitted by the communication terminal (in addition to the contextual cryptographic fingerprint), of a verification cryptographic fingerprint and the comparison of this verification cryptographic fingerprint with the contextual cryptographic fingerprint provided. Cleverly, the validity verification includes a verification of the fact that the contextual cryptographic fingerprint is the latest one for the user and / or the communication terminal.Furthermore, the verification includes verifying the identity of at least one of the data used to create the contextual cryptographic fingerprint with a piece of data in the possession of the server that performs this verification (such as, for example, a hash of a bank card data item and / or a hash of a biometric data item and / or a hash of a password and / or a login). The effective implementation of this verification is dependent on the operational conditions of implementation. When the verification is positive, the fingerprint is validated (i.e., a piece of data, for example, a boolean) validates the authenticity of the fingerprint (and / or the block in which it is inserted). 5.3. Description of a second embodiment

[0070] In this second embodiment, the blockchain is shared with the merchant servers (either directly or through a transactional server). The authentication phase is identical to that described in relation to the figure 2 and is not described again (the only difference being the reception E71, by the communication terminal, of an address (@) at which the contextual cryptographic fingerprint is located (rather than its direct transmission). Thus, the transaction processing phase, described in relation to the figure 3 , then includes: a step I10 of transmission by the communication terminal of a transaction validation request, comprising the address of the contextual cryptographic fingerprint to the merchant server; a step I20 of transmission, by the merchant server, to a transactional server of the address of the contextual cryptographic fingerprint; or o a step I21 of access, by the merchant server, to the address of the blockchain comprising the contextual cryptographic fingerprint; a step I30 of verification of the validity of the contextual cryptographic fingerprint by the transactional server; or o a step I31 of verification of the validity of the contextual cryptographic fingerprint by the merchant server;when the contextual cryptographic fingerprint is valid, a transmission step I40 by the transactional server, to the merchant server, of a validation message of the contextual cryptographic fingerprint, if the transactional server is disconnected from the merchant server (otherwise, a verification step I41 by the merchant server itself); a transmission step I50, to the communication terminal, of a transaction validation message.;

[0071] Thus, in this embodiment, the contextual cryptographic fingerprint is used to prove the user's authentication, indirectly, without using the authentication server, which retains its sole function of authenticating users on their terminals. The communication terminal transmits the address of the contextual cryptographic fingerprint to the merchant server which uses it to verify its validity (either directly or using the transaction server). This embodiment has the advantage of not making the contextual cryptographic fingerprint available to the communication terminal, thus increasing security (because it reduces the risk of theft of this contextual cryptographic fingerprint).

[0072] The step of verifying the validity of the contextual cryptographic fingerprint is the same as for the first embodiment and may be single or multiple, depending on whether or not this contextual cryptographic fingerprint is chained with a previous cryptographic fingerprint (reference or contextual). 5.4. Device for implementing the invention

[0073] We present, in relation to the figure 4 , a simplified architecture of an authentication server capable of managing contextual fingerprints in conjunction with mobile devices. An authentication server comprises a memory 41, a processing unit 42 equipped for example with a microprocessor, and controlled by the computer program 43, implementing the method as previously described. In at least one embodiment, the invention is implemented in the form of an application installed on a server. Such a server comprises: means for obtaining a contextual cryptographic fingerprint, previously generated during authentication of a user on a communication terminal; means for verifying the validity of the contextual cryptographic fingerprint within a blockchain comprising a set of cryptographic fingerprints; means for validating a transaction when the means for verifying the validity of the contextual cryptographic fingerprint within a blockchain provide a positive response.

[0074] We present, in relation to the Figure 5, a simplified architecture of a mobile device capable of carrying out transactions using a contextual fingerprint. Such a mobile device comprises a memory 51, a processing unit 52 equipped for example with a microprocessor, and controlled by the computer program 53, implementing the method according to the invention. In at least one embodiment, the invention is implemented in the form of a mobile application installed on a mobile device in the possession of the user. Such a mobile device comprises: means for generating a contextual or reference cryptographic fingerprint; means for transmitting said cryptographic fingerprint and / or data constituting this fingerprint to an authentication server; means for carrying out a payment transaction with a merchant server, comprising the implementation of the means for transmitting a contextual cryptographic fingerprint and / or a link to a contextual cryptographic fingerprint; means for receiving data representative of the validation of the transaction by said server.

[0075] These means are in the form of a specific software application, or in the form of dedicated hardware components, such as a security element (SE) or a secure execution environment. The security element may be in the form of a SIM card, USim, UICC, or a specific security component, grafted onto the motherboard of the communication terminal. More particularly, in at least one embodiment, these means are in the form of several hardware components to which several software components are added. More particularly, the transmission means are for example included in a secure component which includes for example more or less direct access to a transmission / reception controller, making it possible to directly interrogate a server. This secure component is responsible for at least partially determining a parameter for calculating the certification code.The other components of the communication terminal have been described in connection with the proposed embodiment.

Claims

1. Method for processing a transaction, the method being implemented by an electronic device for processing transactions, accessible via a communication network, said method comprising a transaction processing phase characterised in that it comprises: - a step (T10, T20, I10, I20, I21) of obtaining a contextual cryptographic fingerprint, previously generated during an authentication of a user on a communication terminal; - a step (T30, I30) of verifying the validity of the contextual cryptographic fingerprint in a blockchain comprising a set of cryptographic fingerprints, said step (T30, I30) of verifying the validity of the contextual cryptographic fingerprint comprising a step of determining that the contextual cryptographic fingerprint is the latest contextual cryptographic fingerprint for said user and / or said communication terminal, in the blockchain; - a step (T40, I40) of validating a transaction when the step (T30, I30) of verifying the validity of the contextual cryptographic fingerprint in the blockchain is positive.

2. Method for processing a transaction according to claim 1, characterised in that a contextual cryptographic fingerprint (EC), of set of cryptographic fingerprints, is embodied by a chain ChIEC for identification of the cryptographic fingerprint EC which is obtained on the basis of a set D of constituent data (d0,...,dn) in the following manner: ChIEC = F G d 0 , … , dn wherein: - G is a data-mixing function; - F is a cryptographic function for calculating the identification chain.

3. Method for processing a transaction according to claim 1, characterised in that the step of obtaining the contextual cryptographic fingerprint comprises: - a step of receiving an address of location of the contextual cryptographic fingerprint in the blockchain; - a step of obtaining the contextual cryptographic fingerprint at the address previously received.

4. Method for processing a transaction according to claim 1, characterised in that the step (T30, I30) of verifying the validity of the contextual cryptographic fingerprint comprises a step of verifying the validity of the block of the blockchain into which the contextual cryptographic fingerprint is inserted.

5. Method for processing a transaction according to claim 1, characterised in that the step (T30, I30) of verifying the validity of the contextual cryptographic fingerprint comprises: - a step of obtaining transaction data, coming from the communication terminal; - a step of calculating, on the basis of this transaction data, a verification cryptographic fingerprint; - a step of comparing the verification cryptographic fingerprint to the contextual cryptographic fingerprint; and - a step of validating the contextual cryptographic fingerprint when the comparison is positive.

6. Method for processing a transaction according to claim 1, characterised in that the step (T30, I30) of verifying the validity of the contextual cryptographic fingerprint comprises a step of comparing at least one piece of data for constituting the contextual cryptographic fingerprint to at least one corresponding piece of data provided by the communication terminal.

7. Method for processing a transaction according to claim 1, characterised in that it further comprises a preliminary authentication phase, during which the contextual cryptographic fingerprint is created, said preliminary authentication phase comprising: - a step E10 of authenticating the user; - a step E20 of obtaining an authentication message, comprising the confirmation of the authentication of the user and a set D of constituent data (d0,...,dn); - a step E50 of calculating the contextual cryptographic fingerprint using the data received.

8. Method for processing a transaction according to claim 7, characterised in that the preliminary authentication phase further comprises: - a step E60 of inserting the contextual cryptographic fingerprint into the blockchain; and - when the block of the blockchain into which the contextual cryptographic fingerprint has been inserted is validated, a step E70 of transmitting the contextual cryptographic fingerprint to the communication terminal.

9. Electronic device for processing transactions, accessible via a communication network, said device comprising means for processing a transaction and characterised in that it comprises: - means for obtaining a contextual cryptographic fingerprint, previously generated during an authentication of a user on a communication terminal; - means for verifying the validity of the contextual cryptographic fingerprint in a blockchain comprising a set of cryptographic fingerprints; verifying the validity of the contextual cryptographic fingerprint comprising determining that the contextual cryptographic fingerprint is the latest contextual cryptographic fingerprint for said user and / or said communication terminal, in the blockchain; - means for validating a transaction implemented when the means (T30, I30) for verifying the validity of the contextual cryptographic fingerprint in the blockchain provide a positive piece of information.

10. Computer program product downloadable from a communication network and / or stored on a support readable by computer and / or executable by a microprocessor, characterised in that it comprises program code instructions for the execution of a method according to claim 1, when it is executed on a computer.