WO2019145620A1

WO2019145620A1 - Secure system for transactions between terminals

Info

Publication number: WO2019145620A1
Application number: PCT/FR2019/050086
Authority: WO
Inventors: Jean-Marc Seigneur
Original assignee: Réputaction
Priority date: 2018-01-25
Filing date: 2019-01-16
Publication date: 2019-08-01
Also published as: EP3743871A1; FR3077151A1; FR3077151B1

Abstract

Secure system for transactions between terminals, wherein, even in the absence of a connection to a group (6) of servers which are programmed to record transactions in a block chain, a crypto-processor (28) of a payment terminal (20) is capable: - of transmitting to a collection terminal (22) a private key which is the only one able to validly sign a transaction of an object or to transmit the signed transaction, then - of recording, in a secure memory, an identifier of the object which is transferred by the transaction, then - when a new transaction is constructed by the crypto-processor, of comparing the identifier of the object which is transferred by this new transaction to the identifier of the transferred object which is recorded in the secure memory, and - only if these identifiers match, of preventing this new transaction from being transmitted to the collection terminal.

Description

SECURE TRANSACTION SYSTEM BETWEEN TERMINALS

[001] The invention relates to a secure system and method for transactions between terminals. The invention also relates to a payment terminal for the realization of this system as well as an information recording medium for implementing this method.

[002] Known secure systems for transactions between terminals comprise

a set of servers programmed to check and, after verification, record transactions in a blockchain, each block comprising several transactions and a thumbprint of a previous block in the blockchain, each transaction being a digital message which contains at least the following information:

At least one arrival address of this transaction, this arrival address having been constructed from a pair of public / private keys containing a private key and a public key corresponding to this private key,

At least one start address which unambiguously identifies an arrival address of a transaction previously stored in the blockchain,

• an object identifier transferred from the starting address to the arrival address,

A digital signature of the transaction obtained by signing at least the start and end addresses with the private key, this signature enabling the set of servers to verify that this transaction has been generated by a terminal having access to this private key,

a payment terminal able to communicate with the set of servers, this payment terminal being equipped with:

A cryptoprocessor, this cryptoprocessor comprising a secure memory accessible only by the cryptoprocessor,

A transmitter / receiver capable of establishing an information exchange link with another terminal,

a collection terminal able to communicate with the set of servers, this collection terminal being equipped with:

• a microprocessor,

• a memory, and

the set (6) of servers is able to record a first transaction containing a first arrival address and a first object identifier transferred to this first arrival address,

the secure memory comprises a first pair of public / private keys from which the first arrival address has been generated, this first pair of public / private keys comprising: A first private key which is the only one to validly sign a second transaction having a starting address which unambiguously identifies the first address of arrival, and

A first public key corresponding to the first private key,

the collection terminal is able to obtain and store in its memory a second arrival address and a second pair of public / private keys from which the second arrival address has been generated, this second pair of public / private keys comprising a second private key and a second public key corresponding to this second private key,

the cryptoprocessor is able, in response to the reception of the second arrival address, to construct the second transaction, signed with the first private key, between a start address unambiguously identifying the first arrival address and this second address; arrival,

the payment and collection terminals are able to transmit all transactions built or received to the set of servers when they are connected to this set of servers,

- the set of servers is fit, in response to the receipt of any transaction:

• to verify the validity of this received transaction with the signature it contains,

• to verify the absence of double-spending by checking that there is not a transaction of the same object from the same starting address already registered in the blockchain, and

• only if these verifications confirm the validity of the transaction received and the absence of double-spending, to record the transaction received in the blockchain,

- Even in the absence of connection with the set of servers, the payment terminals and collection are able to establish, through their respective transmitters / receivers, an exchange of information between them.

[003] From the state of the art, the following documents are known:

- Andreas M. Antonopoulos: "Mastering Bitcoin - Unlocking Digital Cryptocurrencies", 20/12/2014, O'Reilly Media, Beijing Cambridge Farnham Kôln Sevastopol Tokyo,

- Melanie Swan: "Blockchain: Blueprint for a New Economy", 8/02/2015, O'Reilly,

- W02017 / 145008A1,

-EP2953075A1.

[004] For example, one of these known systems is that developed to transfer cryptocurrency known as "Bitcoin" between terminals. Subsequently, this system is simply called "Bitcoin system". In the Bitcoin system, the set of servers performs operations known as "mining" or "mining" in English.

[005] In these known systems for a transaction between two terminals is performed and validated, it is necessary that the payment terminal builds the transaction, then transmits to the set of servers. The server set checks the validity of the transaction and if the transaction is valid, saves it in the blockchain. This chain of blocks is better known as blockchain.

[006] One of the essential functions of the server set is to prevent fraud. In particular, the known systems are designed to make, if possible, the fraud known as "double-spending" in French or the term "double-spending". This fraud is defined below in the particular case of the Bitcoin system. However, it can be defined similarly in any secure transaction system. In the Bitcoin system, this fraud consists of:

constructing a first transaction which transfers, for example, a cryptocurrency sum X of a first start address, called UTXO ("Unspent Transaction Output") in the Bitcoin system, to a first destination address, called "Bitcoin address" in the Bitcoin system, then

- To build a second transaction that transfers, the same amount X crypto currency from the same first start address to a second arrival Bitcoin address different from the first arrival address.

[007] By doing this, the same X amount of cryptocurrency has been spent twice, which must absolutely be avoided.

[008] In the Bitcoin system initially developed, it is the computer servers of the set that check in particular whether the starting address of the received transaction does not correspond to a starting address already registered in the blockchain. If the starting address of the received transaction has already been used, the set of computer servers considers this transaction invalid and is therefore not registered in the blockchain. Thanks to this, double-spending is made impossible.

[009] Therefore, for the collection terminal to be sure that the transaction to one of its arrival addresses is valid, it must wait for it to be validated by the set of servers, then check that it has been registered in the blockchain. In order for the transaction to be recorded in the blockchain and then verified by the collection terminal, the payment terminal and the collection terminal must each have a connection to this set of servers. Thus, in the Bitcoin system initially developed, the security of a transaction between two terminals could only be guaranteed if these terminals each had a connection to the set of servers. This type of transaction, which requires having a connection to the set of servers to be secure against fraud such as double-spending, is later called "online transaction" or "on-chain transaction" in English.

By cons, the originally developed Bitcoin system did not guarantee the security of a transaction between two terminals without connection to the set of computer servers. This second type of transaction is subsequently called "off-line transaction" or "off-chain transaction" in English. Attention, an offline transaction is not necessarily a transaction when which no connection to an information transmission network exists but only a transaction performed without a connection to the set of computer servers is necessary.

Recently, a solution known as the "Lightning network" has been developed to further guarantee the security of off-line transactions while remaining compatible with the operation of online transactions. This solution is described, for example, in the following article: Joseph Poon and Al: "The Bitcoin Lightning Network: Scalable off-chain instant payment", 14/01/2016, draft version 0.5.9.2, available on-line on the website: https: // lightning. network /.

In summary, this solution is to create a common account on which is transferred an amount in Bitcoin. The amount in Bitcoin can only be validly transferred from this common account to an arrival address if this transaction has been signed at the same time by means of a private key of the payment terminal and a private key of the terminal. collection. In addition, to ensure the security of this off-line transaction, an additional private computer server, called "Watcher Node", is added to the existing set of servers.

In this "Lightning network" solution, a common account must be created online by the payment and collection terminals. Thus, a secure off-line transaction is only possible between a payment terminal and a payment terminal that already knew each other before being disconnected from the set of servers. This solution therefore does not work if, before disconnecting from the set of servers, the payment terminal does not know the payment terminal. In this case, the common account could not be created.

The invention aims to solve the disadvantages of the "Lightning network" solution by ensuring the security of an off-line transaction between a payment terminal and a collection terminal, even if the collection terminal was unknown. before the payment terminal disconnects from the set of servers. In other words, the invention aims at securing an off-line transaction between the payment terminal and the collection terminal without it being necessary, before being disconnected from the set of servers, that these terminals Payment and collection companies need to cooperate with each other to carry out certain on-line operations preparatory to securing the off-line transaction which will then be carried out. In particular, the off-line transaction must be secure against double-spending.

In addition, as the "Lightning network" solution, the off-line transaction must remain compatible with the operation of online transactions. In particular, the arrival address to which the subject of the offline transaction has been transferred must then be able to be used as the starting address of another transaction made, this time, on-line. .

It therefore relates to such a secure system of transactions between terminals according to claim 1. The embodiments of this system may include one or more of the features of the dependent claims.

The invention also relates to a payment terminal specially designed for the realization of the claimed system.

The embodiments of this payment terminal may include one or more of the features of the dependent claims.

The invention also relates to a secure method of transactions between terminals to be implemented in the claimed system.

Finally, the invention also relates to an information recording medium, readable by a cryptoprocessor, wherein the information recording medium includes instructions for implementing the claimed method, when these instructions are executed by the cryptoprocessor.

The invention will be better understood on reading the description which follows, given solely by way of nonlimiting example and with reference to the drawings in which:

FIG. 1 is a schematic illustration of the architecture of a secure system of transactions between terminals;

FIG. 2 is a schematic illustration of a secure memory of a payment terminal used in the system of FIG. 1;

FIG. 3 is a schematic illustration of a memory used in a collection terminal of the system of FIG. 1;

FIG. 4 is a flowchart of a secure method of transactions between terminals implemented in the system of FIG. 1.

[0023] Chapter I: Definitions and Notations:

In the figures, the same references are used to designate the same elements.

In the following description, the features and functions well known to those skilled in the art are not described in detail.

By "public / private key pair" is meant a pair of keys containing a private key and a public key. The public key is different from the private key. The public key makes it possible to encrypt a digital message which is then only decipherable using the private key. The public key also makes it possible to decrypt a cryptogram obtained by encrypting a digital message with the private key. The notions of public key and private key are well known in the field of asymmetric cryptography. Subsequently, we also say that the private key corresponds to the public key and vice versa when it comes to the public and private keys of the same pair of public / private keys.

A point-to-point exchange of information is an information exchange link established via an information transmission network between only two terminals. It is said that a transaction is "off-line", or "off-chain" in English, when a transaction is performed between two terminals without it being necessary for that at least one of terminals is connected to the set of computer servers responsible for validating and recording each transaction in the blockchain.

In contrast, it qualifies transactions "on-line" or "on-chain" in English, any transaction that requires, to be secure, a connection to the set of computer servers. On-line transactions correspond to the most traditional transactions of transaction systems such as the Bitcoin system.

The terminology used to describe the Bitcoin system is that defined in the glossary of Bitcoin developer accessible at the following address:

- https://bitcoin.org/en/developer-glossary for English terms, and

- https://bitcoin.org/en/vocabulary for French terms.

The technical description of the operation of the current Bitcoin system is for example given in the guide "Bitcoin developer guide" available at the following address: https://bitcoin.org/en/developer-guide. Therefore, with regard to the known features and functionality of the Bitcoin system, the reader is referred to the documentations cited above.

By "starting address" of a transaction, denotes a digital data that unambiguously identifies the arrival address of a previous transaction. For example, in the case of a Bitcoin system, the starting address is known as the "Input" ("Input") of a transaction. It then corresponds to the concatenation of an identifier of the previous transaction and an index of an output ("Output index" in English) of this previous transaction. In the Bitcoin system, a start address corresponds to the identifier of a UTXO (Unspent Transaction Output). Attention, with the terminology adopted here, a starting address is not a Bitcoin address because the same Bitcoin address can have several outputs. In the case of the Ethereum system, the starting address corresponds to the address of a starting account.

By "arrival address" of a transaction, there is designated a numerical data that unambiguously identifies the arrival address to which is transferred the object of the transaction. In the Bitcoin system, this corresponds to an output ("Output") of a transaction or to a Bitcoin address if it has only one output. In the Ethereum system, this corresponds to the address of an arrival account.

[0034] Chapter II: Examples of embodiments:

Figure 1 shows a secure system 2 transactions between terminals. The system 2 is described here in the particular case where the object of each transaction is a currency commonly called cryptocurrency. In this embodiment, the cryptocurrency is Bitcoin. Subsequently, only a few Conventional features of the Bitcoin system useful for understanding are recalled. The description focuses primarily on the new changes and features implemented in the conventional Bitcoin system to enable secure off-line transaction between devices.

It is recalled that a transaction is a digital message which typically contains at least the following information:

at least one starting address from which the cryptocurrency transferred to the address or addresses of arrival originates,

an object identifier transferred, that is to say here typically a transferred cryptocurrency amount expressed in Bitcoin or Satochis,

a first script which, when executed by an electronic calculator, determines whether the transaction is valid or not, this first script containing the arrival address to which the cryptocurrency is to be transferred, and

a second script which, when executed by an electronic computer, makes it possible to load the information processed by the first script to determine whether this transaction is valid or not.

In the system 2, the starting address and the arrival address are called, respectively, input ("input") and output ("output"). The start address unambiguously identifies the arrival address of a previous transaction recorded in the blockchain, ie a UTXO. For this purpose, the starting address comprises a Txid identifier of the previous transaction and an output index known as the "output index" which unambiguously identifies the previous transaction.

The arrival address comprises a unique address constructed from a pair of public / private keys. For example, in the Bitcoin system, the private key is used to generate the corresponding public key and the public key is then used to generate the arrival address by implementing a hash function for this purpose. English).

The first script is known as "pubkey script" or "scriptpubkey". The second script is known as "signaturescript" or "scriptsig".

The second script contains the signature of the transaction. This signature is obtained by encrypting a digital fingerprint of the transaction with a private key known only to the payment terminal that generated this transaction. The digital fingerprint is constructed from, in particular, the starting address and the arrival address of the transaction and using a hash function ("hash function" in English). The second script also contains the public key that verifies this signature. In the case of the Bitcoin system, this public key is the same as that used to generate the starting address of this transaction.

When the first script is executed, it allows in particular to check the following two conditions: - Condition 1): the starting address corresponds to the public key loaded into memory by the execution of the second script, and

- Condition 2): the signature loaded by the execution of the second script is a valid signature, that is to say that it could be verified with the help of the public key also loaded by the execution of the second script and the contents of the transaction.

The condition 1) confirms that the starting address is a starting address generated by a payment terminal that contains the public key. Condition 2) confirms that the transaction has been authorized by the payment terminal that contains the private key that corresponds to this public key.

The system 2 comprises:

a network 4 for transmitting information,

a set 6 of computer servers connected to the network 4, and

- electronic terminals between which are exchanged Bitcoins.

The network 4 is here the Internet network on which deploys the global spider web or "World Wide Web." Through this network 4, the different servers of the set 6 as well as the different terminals are connected to each other in the form of a network known as peer-to-peer network or "Peer to Peer "in English.

The set 6 typically includes thousands of computer servers programmed to check transactions between terminals and record valid transactions in a database known as the "block chain". To simplify FIG. 1, only three computer servers 10 to 12 of the set 6 have been represented. The symbol "..." between the servers 11 and 12 indicates that only a portion of the computer servers of the set 6 has been represented.

The chain of blocks is distributed among the many computer servers. For this purpose, each computer server has a memory in which is recorded part or all of the block chain. In FIG. 1, these memories carry the references M _ref , where the index "ref" is equal to the numerical reference assigned to the computer server.

Each block of the block chain comprises several transactions and a digital fingerprint of a previous block of the block chain. Before registering a transaction in a block, the computer server checks the validity of this transaction by executing the first and second scripts it contains. The computer server also verifies that the starting address contained in this transaction has not already been used for a previous transaction already registered in the blockchain. This last check makes it impossible or almost impossible to double-spend.

To perform the various operations necessary for the operation of the system 2, each computer server comprises an electronic computer programmed or configured to perform the method described with reference to Figure 4. In Figure 1, the electronic computer of a computer server wears reference CE _ref , where the index "ref" is equal to the numerical reference assigned to this computer server.

The computer servers of the set 6 are known by the term "miner" or "miner" in English.

The system 2 also includes many terminals capable of carrying out transactions between them. Typically, the number of terminals is ten times or a hundred times or a thousand times greater than the number of computer servers of the set 6. To simplify FIG. 1, only two terminals 20 and 22 are represented.

The terminal 20 is here a payment terminal. This terminal 20 comprises:

a programmable microprocessor 24,

a non-volatile electronic memory 26,

a cryptoprocessor 28,

a transmitter / receiver 30,

a human-machine interface 32, and

- An information transmission bus 34 which allows these different components of the terminal 20 to communicate with each other.

The cryptoprocessor 28 may be in the form of a smart card or a Trusted Platform Module (TPM) or a hardware security module. Cryptoprocessor 28 is a microprocessor specifically designed to be resistant to cryptanalysis attempts such as hidden channel attacks. In particular, it is more resistant to cryptanalysis attempts than the microprocessor 24. In addition, the cryptoprocessor 28 is configured to execute encryption and decryption algorithms as well as public / private key pair generation algorithms.

The cryptoprocessor 28 is for example made from an FPGA ("Field Programmable Gate Array") or an ASIC ("Application-Specific Integrated Circuit") or a programmable microcontroller.

Here, the cryptoprocessor 28 forms what is known as the "Trusted Execution Environment". For example, such cryptoprocessors are marketed by INTEL® under the name "INTEL TXT" ("Intel Trusted Execution Technology") or by GEMALTO® under the acronym HSM ("Hardware Security Module").

The cryptoprocessor 28 includes an internal secure nonvolatile electronic memory 36. The memory 36 is accessible only by the cryptoprocessor 28. Thus, the owner of the terminal 20 can not read and obtain the private keys generated and stored in this memory . In particular, the microprocessor 24 can not access the contents of the memory 36. This memory 36 is intended to contain secret information such as private keys and cryptographic algorithms. It comprises in particular the instructions, executable by the cryptoprocessor 28, for the implementation of the method of FIG. 4. Here, the cryptoprocessor 28 further comprises a cryptanalysis attempt detection mechanism which makes it possible to know whether the cryptoprocessor 28 has been the subject of such cryptanalysis attempts.

The transmitter / receiver 30 is capable of establishing a point-to-point connection 40 of information exchange with another terminal of the system 2. For example here, this link 40 may be:

a wired connection made using a cable such as a USB (Universal Serial Bus) cable, or

- a wireless link such as a link complying with one of the following standards: NFC (Near Field Communication) or Bluetooth.

The link 40 can be established between the terminals 20 and 22 independently of the fact that these terminals are or are not connected at the same time to the network 4. For example, here, it is a direct connection between the terminals 20 and 22 compliant with the Bluetooth standard.

The man-machine interface 32 typically comprises at least one screen for displaying information and means for acquiring information from the user of this human-machine interface. For example, the human-machine interface 30 comprises a touch screen.

The terminal 20 is also able to connect to the set 6 of computer servers via the network 4. For example, the terminal 20 is a smartphone or a computer or laptop.

The terminal 22 is a collection terminal. Here, by way of example, its structure is identical to that of the terminal 20 except that it does not include the cryptoprocessor 28. Subsequently, the components of the terminal 22 identical to those of the terminal 20 bear the same numerical references as those components of the terminal 20 but incremented by the number 20. Thus, in this exemplary embodiment, the terminal 22 is less secure than the terminal 20 since the encryption / decryption operations and the like are performed by the microprocessor 44 which is less secure than the cryptoprocessor 28.

In this embodiment, the system 2 further comprises a computer server 60 of reputation information and a computer server 62 cryptographic certificate revocation. These two servers 60 and 62 are connected to the network 4. Each of the servers 60 and 62 includes:

a programmable microprocessor, respectively 64 and 66, and

a non-volatile electronic memory respectively 68 and 70.

The microprocessor 64 is programmed to store, update and transmit, in response to a request, information on trustworthiness ("trustworthiness" in English) that can be in the terminals of the system 2.

The microprocessor 66 is programmed to store, update and transmit, in response to a request, information on the validity of the cryptographic certificates used in the system 2. In particular, the microprocessor 66 is capable of transmitting, in response to a request, a list containing all the revoked cryptographic certificates.

FIG. 2 represents in more detail the contents of the memory 36. The memory 36 comprises:

a list L _Rep ,

- a list L _Rev ,

a cryptographic certificate C _y20 containing a public key K _pub2 o,

a private key K _pr20 corresponding to the public key K _pub2 o,

a list L _u of transaction data already used.

The list L _Rep comprises, associated with terminal identifiers of the system 2, a confidence index. The higher the numerical value of this confidence index, the more reliable the terminal associated with this index is. For example, all the terminals of the system 2 equipped with a cryptoprocessor which has not been corrupted have a higher index of confidence than the terminals which, like the terminal 22, are devoid of cryptoprocessor. Whenever a terminal equipped with a cryptoprocessor is the victim of a cryptanalysis attempt, this information is transmitted to the server 60 and the index of confidence of this terminal is decreased. The confidence index of a terminal is also decreased each time it is used to defraud or to attempt to defraud.

The list L _Rev includes a list of revoked cryptographic certificates. These revoked cryptographic certificates are no longer usable.

The certificate C _y20 contains the public key K _pub2 and a signature obtained by encrypting the information contained in this certificate using the private key of the microprocessor manufacturer 28. Thus, it is possible to verify that the cryptoprocessor 28 is an authentic cryptoprocessor manufactured by a known manufacturer.

The list L _u contains transaction data already used to generate and perform an off-line transaction. This L _u list is used here to prevent double-spending for off-line transactions.

FIG. 3 represents in more detail the contents of the memory 46 of the terminal 22. The memory 46 here comprises in particular:

- the list L _Rep ,

- the L _Rev list,

a cryptographic certificate C _y22 containing a public key K _pub22 , and

a private key K _pr22 corresponding to the public key K _pub22 .

For example, the cryptographic certificate C _y22 is signed using a private key from the manufacturer of the terminal 22 or the microprocessor 44.

The operation of the system 2 will now be described with reference to the method of FIG. 4. Thereafter, to simplify the explanations, the taxes levied on each transaction, in particular by the servers of the set 6, are considered as zero and ignored. However, the skilled person is capable to apply the teaching given above in cases where such taxes are not zero, as is the case in practice at present.

Initially, during a step 100, the cryptoprocessor 28 generates a pair of public / private keys containing a public key K _pubi and a private key K _pa . For example, the cryptoprocessor 28 first generates the key K _pa in a random or pseudo-random manner or by any other means and then it constructs the key K _pubi from the key K _p n. Then, the cryptoprocessor 28 builds, only from the key K _pubi , an arrival address @i able to receive Bitcoins.

In a step 101, a transaction Ti signed to transfer X Bitcoins to the address @i is built and transmitted to the set 6. This transaction Ti can be built by a third party terminal. The transaction Ti can also be constructed by the terminal 20 itself, which then transfers online Bitcoins X it already had to the address @i.

Subsequently, to simplify the description, it is assumed that the transaction Ti has a single entry and a single output known by the acronym UTXO ("Unspent Transaction output").

In a step 102, in response to the receipt of the transaction Ti, the computer servers of the set 6 verify it by executing the first and second scripts of this transaction Ti. In particular, the servers of the set 6 ensure that the starting address contained in this transaction Ti has not already been used for another transaction already recorded in the blockchain. If the transaction Ti is valid, then the computer servers of the set 6 register it in the blockchain. Otherwise, that is, if the IT servers determine that the transaction Ti is invalid, it is not registered in the blockchain.

In a step 104, regardless of the terminal that created the transaction Ti, the cryptoprocessor 28 connects to the set 6 and verifies that the transaction Ti has been recorded in the blockchain so that the cryptoprocessor 28 is sure to have X bitcoins on the @i address. If so, the cryptoprocessor 28 stores in the memory 36 that the transfer of the X Bitcoins from the @i address is now allowed both on-line and off-line. Otherwise, this authorization is not stored in the memory 36 so that the cryptoprocessor 28 prevents the creation of any off-line transaction for the purpose of transferring X Bitcoins from the @i address.

Steps 100, 101, 102 and 104 are performed, for example, as described in the Bitcoin system. They are therefore not described in more detail.

In a step 106, the cryptoprocessor 28 connects to the server 60 and updates the list _{Rep Rep} from the information downloaded from this server 60. In this step, the cryptoprocessor 28 also connects to the server 62 and updates the list L _Rev from the information downloaded from the server 62. Similarly, the terminal 22 can also update the lists L _Rep and L _Rev stored in its memory 46. In a step 108, the terminal 20 disconnects from the set 6. For example, here, it is considered that the terminal 20 is disconnected from the network 4. From this moment, it is also considered that the terminal 22 is also disconnected from the set 6. For example, the terminals 20 and 22 are on a desert island without access means to the network 4. It is also assumed that, under these conditions, the terminal 20 wishes to transfer to the terminal 22 , all the X Bitcoins still available at @i via an offline transaction.

For this purpose, during a step 110, the terminals 20 and 22 establish the link 40 between them via the transceiver 30 and 50. During this step, the terminals 20 and 22 exchange their certificates. cryptographic C _y20 and C _y22 . The cryptoprocessor 28 and the terminal 22 then check whether the certificates, respectively, C _y22 and C _y20 received belong to the list L _Rev. If so, that is, if one of the terminals 20 and 22 determines that the received certificate has been revoked, the process stops and, for example, the link 40 is interrupted. No off-line transactions between terminals 20 and 22 are then performed.

Otherwise, that is to say if it has been determined that the certificates C _y22 and C _y20 have not been revoked then, from now on, all the messages transmitted from the terminal 20 to the terminal 22 are encrypted with the key K _pub22 and all messages transmitted from the terminal 22 to the terminal 20 are encrypted with the key K _pub2 o. In addition, each time the terminal 20 sends a message to the terminal 22, this message is signed with the key K _pr20 so that the terminal 22 can also verify the authenticity of this message with the key K _pub20 received. Conversely, the messages transmitted from the terminal 22 to the terminal 20 are also signed with the key K _pr22 so that the terminal 20 can verify the authenticity with the key K _pub20 received. If ever the authenticity of a message exchanged between the terminals 20 and 22 can not be verified, then the process is interrupted and no transaction between the terminals 20 and 22 is performed. At this point, the link 40 between the terminals 20 and 22 is said to be secure because, on the one hand, it is encrypted and, on the other hand, the exchanged messages are authenticated.

During a step 112, the terminal 22 transmits its identifier to the terminal 20 and the cryptoprocessor 28 verifies, using the identifier received, the confidence index associated with the terminal 22 in the list L _Rep . If the confidence index associated with the terminal 22 is less than a predetermined threshold S1, no transaction is made between the terminals 20 and 22. For example, the process stops and the link 40 is interrupted. In the opposite case, the process continues with a step 116.

Subsequently, it is assumed that the terminal 22 is associated with a confidence index greater than the threshold Si. Moreover, to simplify the explanations, it is assumed that all the X Bitcoins are transferred from the terminal 20 to the terminal 22. From now on, all the message exchanges between the terminals 20 and 22 are made via the secure link 40. In step 116, the cryptoprocessor 28 acquires via the man-machine interface 32 the choice of the user between two options, respectively, "anonymous transaction" and "non-anonymous transaction".

During a step 118, the cryptoprocessor 28 generates a number N _i pulled randomly or pseudo-random and transmits this number N _ai to the terminal 22. Preferably, this number N _ai is transmitted to the terminal 22 by a other means of communication than the link 40 to avoid the attack known as "man in the middle". For example, the number N _ai is displayed on the screen of the terminal 20 in the form of a QR-code and the terminal 22 is used to scan this QR-Code and thus acquire the number N _ai . The number N _ai is then included in all the messages exchanged between the terminals 20 and 22 via the link 40. This makes it possible to avoid the implementation of a "replay" attack.

Then, during a step 120, the cryptoprocessor 28 acquires via the man-machine interface 32 a confirmation that the X Bitcoins associated with the address @i must be transferred to the terminal 22.

In response, during a step 124, if the user has selected the "anonymous transaction" option, the cryptoprocessor 28 compares the key K _pa to the content of the list L _u . If the key K _p n belongs to the list L _u the process stops and the transaction between the terminals 20 and 22 is not performed. Indeed, if the key K _pa already belongs to the list L _u it means that the X Bitcoins associated with the address @i have already been spent. The interruption of the transaction in this case therefore prevents double-spending. If the key K _pil does not belong to the list L _u , the process continues with a step 126.

In step 126, the cryptoprocessor 28 transmits to the terminal 22 the key K _p n, the key K _pubi , the Bitcoins amount transferred to the terminal 22, and the address @ 1. Therefore, the terminal 22 is capable of constructing a signed and valid transaction from the starting address address @i to another destination address. Thus, the X bitcoins associated with the address @ i have been transferred from the terminal 20 to the terminal 22. Moreover, in this case, this transaction is anonymous because it leaves no trace in the blockchain even after a Valid transaction from the address @i to another address @ ₂ was built by the terminal 22, then registered in the blockchain when the terminal 22 is connected again to the set 6.

Then, during a step 128, once this information has been transmitted to the terminal 22, the cryptoprocessor 28 prohibits the realization of any new transactions for the purpose of transferring the same X Bitcoins that those transferred during the step 126. For this purpose, the cryptoprocessor 28 records in the list L _u an identifier of the transferred object, that is to say here transferred X Bitcoins. In this embodiment, the key K _p n, the key K _pU bi or the address @ i unambiguously identify these transferred X Bitcoins. Thus, here, the cryptoprocessor 28 records these keys K _p n, K _pubi and the address @i in the list L _u contained in the memory 36. At the end of step 120, if the user had selected the "non-anonymous transaction" option, during a step 130, the terminal 22 obtains a pair of public / private keys K _pUb 2 / Kp _r2 and an address @ ₂ constructed from the key K _pub2 . For example, here, the terminal 22 generates and stores these data as described with reference to step 100.

At the end of step 130, the @ ₂ address is then transmitted to the terminal 20.

In response to the reception of the address @ ₂ , during a step 132, the cryptoprocessor 28 compares the keys K _pri , K _pubi and the address @i to the content of the list L _u . If one of the keys K _p n, K _pubi and the address @i belongs to the list L _u , the process stops and the transaction between the terminals 20 and 22 is not performed. Indeed, as already explained next to step 124, this means that the X Bitcoins associated with the address @i have already been spent. The interruption of the transaction in this case therefore prevents double-spending. If the keys K _p n, K _pubi and the address @i do not belong to the list L _u , the process continues with a step 136.

In step 136, the cryptoprocessor 28 builds a transaction T ₂ having as the starting address address @i and as address of arrival the address @ ₂ and an amount of X Bitcoins. This transaction is built in the same way as for a conventional online transaction. In particular, it is signed with the key K _p n.

At the end of step 136, the cryptoprocessor 28 transmits the transaction T ₂ to the terminal 22.

In a step 138, once the transaction T ₂ has been transmitted to the terminal 22, the cryptoprocessor 28 prohibits the realization of any new transactions for the purpose of transferring the same X bitcoins that those transferred at the time. step 136. For this purpose, the cryptoprocessor 28 proceeds as described with reference to step 128. Thus, the address @i _, the keys K _p n and K _pubi and the amount transferred are recorded in the list L _u of the memory 36.

Once the transaction has been made between the terminals 20 and 22, during a step 150, the link 40 is interrupted. Typically, in step 150, the terminals 20 and 22 each display a message on the screens, respectively, of the man-machine interfaces 32 and 52 to indicate to the users of these terminals that the transaction has been correctly performed and that the This is now over.

Subsequently, in the case where the option "anonymous transaction" had been selected, in a step 152, the terminal 22 builds a transaction T ₃ from the address @i to another address @ ₃ . The transaction T ₃ is signed with the key K _p n received during the step 126. Then, when the terminal 22 connects again to the set 6 of servers, it transmits the transaction T ₃ to the computer servers of the together 6 to be registered in the blockchain. The terminal 22 can build such a valid transaction because it is in possession of the key K _p n.

In the case where the option "non-anonymous transaction" had been selected, during a step 154, the terminal 22 connects to the servers 6 and informs them of the transaction T ₂ received during step 136. The transaction T ₂ is then verified by these computer servers and then recorded in the blockchain.

In parallel, after step 150, each time the terminal 20 wishes to perform a new transaction offline or online with a collection terminal, in a step 156, the cryptoprocessor 28 checks if the Bitcoins that the user wants to spend do not match those already spent on the off-line transaction. For example, for this, before building each new transaction, the cryptoprocessor 28 proceeds first as described in steps 124 and 132. Then, only if the starting address and public / private keys used to build this new transaction are not already in the list L _u , so this new transaction is allowed.

[00101] Chapter III: Variants:

[00102] Variations of the structure of the secure transaction system:

Alternatively, the cryptoprocessor 28 is not integrated within the terminal 20 but connected to the terminal 20 via an information exchange link. In this case, the cryptoprocessor 28 may be located several tens of centimeters or tens of meters or hundreds of meters from the terminal 20.

The certificate C _y22 of the terminal 22 may be signed by the terminal 22 and not by a known manufacturer of the terminal 22 or the microprocessor 44.

The terminal 22 may also include a cryptoprocessor such as the cryptoprocessor 28. In this case, the steps described above are performed by the cryptoprocessor of the terminal 22 rather than by the microprocessor 44.

Preferably, the terminal 22 verifies the confidence index of the terminal 20 and / or the certificate C _y20 transmitted by this terminal 20. In the case where the confidence index of the terminal 20 is lower than the threshold Si or in the the case where the certificate C _y20 would be revoked, the terminal 22 can interrupt the process of Figure 4 so that the transaction between the terminals 20 and 22 is not performed. For example, for this, the cryptoprocessor of the terminal 22 performs the same operations as those described in steps 110 and 112 in the particular case of the cryptoprocessor 28. Moreover, if the terminal 22 is equipped with a cryptoprocessor it can also be used in as a payment terminal. For example, it is programmed to be able to function as the terminal 20. In this case, it can in turn perform an off-line transaction using as a means of payment the X Bitcoins it has previously received from the terminal 20. For this purpose, in the case of an anonymous transaction, it transmits offline the key K _p n, which it has previously received from the terminal 20, to another collection terminal. In the case of a non-anonymous transaction, the terminal 22 can generate another signed transaction with this key K _p n associated with the address @i still not used.

The payment terminal 20 is not obliged to verify that the certificate of the collection terminal 22 is not revoked. The payment terminal 20 is not obliged to check the confidence index of the terminal 22.

The memory 36 may be replaced by a secure volatile memory, for example, of the INTEL® SGK type. In this case, the security level is lower but still acceptable. Indeed, in the event of a power failure of the memory 36, the list L _u , the key K _pa and the key K _pubi are erased. Therefore, the terminal 20 is unable to build a new signed transaction using the address @i as the starting address because the key K _{p has} been erased. Thus, the loss of the list L _u following a power failure does not completely question the security of the transaction system.

[00110] Similarly, the memory 46 may be replaced by a volatile memory.

The server 60 can be omitted. In this case, step 112 is also omitted.

The server 62 may be omitted. In this case, step 110 is omitted.

In a simplified variant, the signature of the messages exchanged between the terminals 20 and 22 is omitted.

The messages exchanged between the terminals 20 and 22 via the link 40 may be protected by other encryption methods such as, for example, symmetric encryption instead of asymmetric encryption as previously described.

The messages exchanged between the terminals 20 and 22 may also include additional information such as a current date, a price, information on a purchased product or others.

In a simplified embodiment, the messages exchanged between the terminals 20 and 22 via the link 40 are not encrypted. The absence of encryption of the link 40 is especially conceivable when the transaction T ₂ is transmitted from the terminal 20 to the terminal 22.

Alternatively, the link 40 is not a point-to-point link but a point-to-multipoint link. For example, the link 40 is then established according to WIFI or other standard.

The link 40 can also be established via a long-distance information transmission network such as the network 4. In this case, the terminals 20 and 22 do not need to be located in the vicinity. from each other to implement the method described with reference to Figure 4.

The collection terminal or the collection terminal may be composed of several mechanically independent parts of each other and connected to each other via information exchange links. For example, only the transmitter / receiver 50 is located near the terminal 20. The other components of the terminal 22 are deported several meters or several tens of meters away from the transceiver 50.

[00120] Variants of the process: [00121] Alternatively, initially, steps 100 to 104 are repeated several times to transfer Bitcoins to several different arrival addresses. From then on, the cryptoprocessor 28 can build off-line:

a transaction between several of these arrival addresses and the address @ ₂ provided by the terminal 22 during the step 136, or

transmit the public / private keys and the addresses associated with the terminal 20 during the step 126.

In another variant, during step 102, the transaction Ti constructed has several outputs and therefore several arrival addresses. In this case, during step 136, the cryptoprocessor 28 can construct a transaction T ₂ having a single or several starting addresses each identifying a respective arrival address of this transaction Ti and the arrival address @ ₂ provided by the terminal 22. In this embodiment, the starting addresses used by the transaction T ₂ are registered in the list L _u and a new use of the key K _p n is prohibited only if this new use consists in constructing a new transaction between at least one of the departure addresses already used and a new arrival address.

When the transaction Ti has several arrival addresses @ "it is also possible to associate with each of these arrival addresses a private key K _pri respective. In this case, the transfer of the private key K _pri from the terminal 20 to the terminal 22 makes it possible to transfer, anonymously, the amount in Bitcoins associated with the address corresponding to the key K _pri . What has been previously described to prevent double-spending in the case of the transfer of the key K _p n applies to the transfer of each key K _pri .

In step 136, the cryptoprocessor 28 can also build a transaction T ₂ which has several addresses of arrival. For example, if the starting @i address is associated with X Bitcoins and the transaction T ₂ only needs to transfer X-

Y Bitcoins to the terminal 22, then the cryptoprocessor 28 builds a transaction T ₂ which transfers XY Bitcoins from the address @i to the address of arrival @ ₂ and which transfers Y Bitcoins from the address @i to the address d arrival @i. When this transaction T ₂ is subsequently stored in the blockchain, the amounts associated with addresses @i and @ ₂ in the blockchain will become, respectively, Y and XY Bitcoins. For example, as long as this transaction T ₂ has not been registered in the blockchain and verified by the cryptoprocessor 28 during a new iteration of the step 104, the Y Bitcoins associated with the address @i can not not be spent offline because the corresponding T ₂ transaction has not been verified yet. However, alternatively, if the collection terminal is ready to accept the risk that the payment terminal will never reconnect to the set 6 and therefore the transaction T ₂ is never recorded in the blockchain, the

Y Bitcoins associated with the @i address can be spent offline. The Y Bitcoins can also be transferred to an address @ ₄ associated with a private key K _pr4 generated in advance by the terminal 20. In this latter case, the Y Bitcoins associated with the address @ ₄ can be transferred offline to a other collection terminal through an anonymous transaction as previously described if the collection terminal is willing to accept the risk that the payment terminal will never reconnect to the set 6 and therefore the transaction T ₂ is never recorded in the chain of blocks. If the payment terminal does not reconnect, the remaining Y Bitcoins will also be lost to the payment terminal owner. Double-spending is prohibited even in this case.

The initial transmission of a public key K _pub2 o can also be achieved by other means than through the link 40. For example, the terminal 20 displays on its screen a QR-code containing the key K _pub2 o and the number N _ai . The terminal 22 then scans this QR-code to acquire these data.

The number N _ai can also be transmitted by telephone. For example, the number N _ai is displayed on the screen of the terminal 20. Next, the user of the terminal 20 calls the user of the terminal 22 and communicates by telephone the number displayed on the screen of the terminal 20. In response in order for the off-line transaction to be performed, the user of the terminal 22 enters in the terminal 22 the number N _ai that has been communicated to him verbally. In the latter case, the terminals 20 and 22 do not need to be close to each other to perform an off-line transaction. It is also possible to transmit the number N _ai by SMS ("Small Message Service") or others.

[00127] Step 118 may be omitted. In this case, the messages exchanged between the terminals 20 and 22 do not include the number N _ai .

[00128] Step 126 can be simplified. For example, during this step, only the key K _p n is transmitted to the terminal 22. Then, from the key K _p n received, the terminal 22 generates the public key K _pubi and the address @i. Indeed, in the Bitcoin system, the generation algorithms, from a private key, the corresponding public key and Bitcoin address are public algorithms known to all terminals. In particular, it is not absolutely necessary to transfer, in addition to the key K _p n, the amount transferred from Bitcoins.

[00129] To identify transferred X Bitcoins, other information than that previously described may be recorded in the list L _u . For example, according to a first variant, only the key K _p n or the key K _pubi or the address @i is stored in the list L _u . According to a second variant, the identifier of the transferred X Bitcoins is obtained by applying a bijective transformation to at least one of the elements selected from the group consisting of the key K _p n, the key K _pubi and the address @i. In the case of a non-anonymous transaction, the transaction T ₂ can be registered in the list L _u . On the other hand, it is also possible to save in the list L _u less elements than what has been described previously. For example, alternatively, the amount of the transaction is not recorded in the list L _u . Thus, there are many possible embodiments of steps 128 and 138. The steps, such as verification steps 124, 132, and 156, must be adapted to the implemented embodiment of steps 128 and 138. In a variant, the arrival addresses, such as the @i and @ ₂ addresses, can be generated solely from the private key of the public / private key pair or only from the public key of this pair. or at the same time from the private key and the public key of this pair.

The terminal 22 can generate the keys K _pub2 and K _pr2 and the address @ ₂ before step 130. For example, the keys K _pub2 and K _pr2 and the address @ ₂ are generated before the terminal 22 disconnects from the server set 6 or before the link 40 is established. In this case, the step 130 consists simply of obtaining, from the memory 46, the keys K _pub2 and K _pr2 and the address @ ₂ previously generated.

The step 154 can be triggered automatically as soon as the terminal 22 connects for the first time to the computer servers of the set 6 after the completion of step 138.

In another variant, the transaction T ₂ built by the terminal 20 is also stored in the memory 36. Then, as soon as the terminal 20 connects to a computer server of the set 6, the cryptoprocessor 28 automatically transmits it. also this transaction T ₂ to this set 6 of computer servers. It should be noted that it is not a problem to transmit the same transaction T ₂ twice to the set 6 of computer servers. Indeed, only the transaction T ₂ received first will then be recorded in the block chain and all copies of this transaction T ₂ received later will be ignored.

Alternatively, an off-line transaction can also be performed between the terminals 20 and 22 even if, at the same time, these terminals are connected or have the opportunity to connect to the set of 6 servers. For example, in this case, during step 116, the user has the choice between three options:

- perform an "anonymous" off-line transaction as previously described,

perform a "non-anonymous" off-line transaction as previously described, and

- perform an online transaction in a conventional way.

[00135] In another variant, the "anonymous transaction" option is omitted. In this case, steps 116, 124, 126, 128 and 152 are omitted. Conversely, the option "non-anonymous transaction" can be omitted. In this case, steps 116, 130 to 138 and 154 are omitted.

To free up space in the memory 36, the keys K _pri , K _pubi and the address @i can be erased, for example, when the cryptoprocessor 28 finds that the transaction T ₂ has been recorded in the chain blocks. From this moment on, the cryptoprocessor 28 can also erase the keys K _p n, K _pubi and the address @i and / or the transaction T ₂ of the list L _u .

The previous embodiments have been described in the particular case of a system complying with the specifications of the Bitcoin system. However, the teaching given here can be transposed without difficulty to any transaction system between terminals using a chain of blocks in a manner similar to that described in the case of the Bitcoin system. In particular, what has been described here applies to any transaction system using a blockchain in which transactions are recorded, transactions each having a start address and an arrival address and an object identifier transferred between these addresses. For example, we know the cryptocurrency transfer system known as the "Ether". This system is subsequently called "Ethereum" system. The operating principles of the Ethereum system are similar to those implemented in the Bitcoin system. Thus, what has been described here can also be implemented in the Ethereum system. In the Ethereum system, the arrival and departure addresses are account addresses that can be credited or debited. The amount of Ethers available on an account is equal to the difference between the inputs and outputs of Ethers on this account. In the Ethereum system, to prevent double-spending, each transaction has a serial number. It is not possible to register in the block chain two transactions from the same starting address and each with the same order number. In addition, a transaction is invalid if the amount to be debited to an account is greater than the amount available on that account. In the Ethereum system, the transferred object is identified, for example, by the combination of the starting address and the amount transferred and possibly the amount available after the transfer. It is therefore these data which are recorded in the list L _u of the payment terminal once the off-line transaction between the terminals has been completed. Preferably, the order number of the off-line transaction carried out is also recorded in the memory 36. The amount transferred is useful for verifying, even in the case of off-line transactions, that the cumulative amount of the transactions carried out does not exceed the amount of Ether available on the account. Then, to prevent double-spending, the transmission of the transaction T ₂ to the terminal 22 is authorized only if the amount available at this starting address is greater than or equal to the amount transferred by this transaction T ₂ , the amount available to the customer. starting address being obtained from the list L _u . For this, for example, the transaction T ₂ is first constructed and the verification that it does not lead to spend more than the available amount is performed after. In particular, it will be noted that in the Ethereum system the same private key K _pa can be used to sign several valid transactions from the same starting address @i from the moment when:

- the transaction numbers assigned to each of these transactions are not identical, and

- the cumulative amount of these transactions does not exceed the amount available on the account identified by the address @i.

This is why when the anonymous option is chosen in the case of Ethereum, it is useful to transfer not only the private key but also the transaction number and the amount available to save them in the payment terminal to be able to realize off-line transactions after receipt.

So far, secure transaction systems have been described in the particular case where the object of the transaction is cryptocurrency. However, what has been described works regardless of the purpose of the transaction. For example, the identifier of a cryptocurrency amount described up to now may be replaced by the identifier of a title deed on a tangible or intangible good such as a patent or the identifier of a contract or the identifier of any other object that may be the subject of a transaction between two terminals.

[00139] Chapter IV: Advantages of the embodiments described here:

[00140] The system 2 makes it possible to secure an off-line transaction made between the terminals 20 and 22 without the need for the identity or an arrival address of the terminal 22 to be known before the terminals 20 and 22. 22 are disconnected from the set of servers.

This system 2 allows both in-line transactions that off-line, without it being necessary to change the processes executed by the set of 6 servers. In other words, this system 2 retains the advantages of existing systems. In particular, off-line transactions are as secure as in-line transactions and double-spending is made impossible. Note also that the system works even if the POS terminal is devoid of cryptoprocessor and this without compromising the security of transactions between terminals 20 and 22.

[00142] The fact of transferring the private key K _pa and, if necessary the address @i, allows an anonymous transaction between the terminals 20 and 22 and this while remaining compatible with the current Bitcoin system.

The fact of encrypting the messages exchanged between the terminals 20 and 22 via the link 40 increases the security of the system.

[00144] The fact of signing the messages exchanged between the terminals 20 and 22 also increases the security of the system.

Claims

1. Secure system for transactions between terminals, this system comprising:

a set of servers programmed to check and, after verification, record transactions in a blockchain, each block comprising several transactions and a thumbprint of a previous block in the blockchain, each transaction being a message which contains at least the following information:

a payment terminal (20) able to communicate with the set of servers, this payment terminal being equipped with:

A cryptoprocessor (28), this cryptoprocessor comprising a secure memory (36) accessible only by the cryptoprocessor,

A transmitter / receiver (30) capable of establishing an information exchange link with another terminal,

a collection terminal (22) able to communicate with the set of servers, this payment terminal being equipped with:

A microprocessor (44),

A memory (46), and

A transmitter / receiver (50) able to establish an information exchange link with another terminal,

the secure memory (36) comprises a first pair of public / private keys from which the first arrival address has been generated, this first pair of public / private keys comprising:

A first private key which is the only one to validly sign a second transaction having a starting address which unambiguously identifies the first address of arrival, and

A first public key corresponding to the first private key, the collection terminal (22) is capable of obtaining and storing in its memory (46) a second arrival address and a second pair of public / private keys from which the second arrival address has been generated, this second pair of public / private keys having a second private key and a second public key corresponding to this second private key,

the cryptoprocessor (28) is able, in response to the reception of the second arrival address, to construct the second transaction, signed with the first private key, between a start address unambiguously identifying the first destination address and this second address of arrival,

the payment and collection terminals (20, 22) are capable of transmitting any transactions that are built or received to the set (6) of servers when they are connected to this set of servers,

the set (6) of servers is fit, in response to the receipt of any transaction:

even if there is no connection with the set of servers, the payment and collection terminals (20, 22) are able to establish, via their respective transmitters / receivers, an exchange link (40). information between them, characterized in that even if there is no connection with the set of servers, the cryptoprocessor (28) is capable of:

to transmit to the collection terminal (22), via the information exchange link, the first private key or the second signed transaction constructed by the cryptoprocessor, and then

- To record, in the secure memory, a second identifier of the object transferred by the second transaction to prevent any new transfer of the same object from the first arrival address, and then

when a new transaction is constructed by the cryptoprocessor, comparing the identifier of the object transferred by this new transaction to the second identifier of the transferred object stored in the secure memory, and

- Only in the case where the identifier of the object transferred by this new transaction corresponds to the second identifier of the transferred object stored in the secure memory, to prohibit the transmission of this new transaction to the collection terminal.

The system of claim 1, wherein: the microprocessor of the collection terminal is a cryptoprocessor, this cryptoprocessor comprising a secure memory accessible only by the cryptoprocessor,

the memory of the collection terminal is the secure memory of the cryptoprocessor of the collection terminal.

3. System according to claim 1 or 2, wherein the set of servers is able to verify the absence of double-spending by verifying only that the starting address of the received transaction is not equal to an address of already saved in the blockchain.

4. Terminal (20) payment for the realization of a system according to any one of claims 1 to 3, wherein the terminal (20) payment is able to communicate with the set of servers, this terminal of payment being equipped:

the secure memory (36) is able to include a first pair of public / private keys from which the first arrival address has been generated, this first pair of public / private keys comprising:

A first public key corresponding to the first private key,

the payment terminal (20) is able to transmit all transactions built to the set (6) of servers when it is connected to this set of servers,

even if there is no connection with the set of servers, the payment terminal (20) is able to establish, via its transmitter / receiver, an information exchange link (40) with the terminal ( 22) cashing,

characterized in that even if there is no connection with the set of servers, the cryptoprocessor (28) is capable of:

to transmit to the collection terminal (22), via the information exchange link (40), the first private key or the second signed transaction constructed by the cryptoprocessor, and then - To record, in the secure memory (36), a second identifier of the object transferred by the second transaction to prevent any further transfer of the same object from the first arrival address, and then

when a new transaction is constructed by the cryptoprocessor (28), comparing the identifier of the object transferred by this new transaction to the second identifier of the transferred object stored in the secure memory, and

5. Terminal according to claim 4, wherein the cryptoprocessor (28) is adapted to transmit to the terminal (22) encashment, through the link (40) exchange of information, the first private key.

6. Terminal according to any one of claims 4 to 5, wherein the payment terminal is able to encrypt the transmission, through the exchange of information exchange, the first private key or the second signed transaction.

7. Terminal according to any one of claims 4 to 6, wherein the payment terminal is adapted to sign the transmission, via the exchange of information exchange, the first private key or the second signed transaction.

Terminal according to any one of claims 4 to 7, wherein the cryptoprocessor (28) is capable of:

- in the absence of connection with the set of servers, to build and save in its secure memory the first transaction, then

- After the transmission of the first private key or the second signed transaction, in response to a connection with the set of servers, to automatically transmit the first transaction recorded to the set of servers.

9. Terminal according to any one of claims 4 to 8, wherein the secure memory is a non-volatile memory.

A secure transaction method between terminals for implementation in a system according to any one of claims 1 to 3, wherein:

the set of servers records (104) a first transaction containing a first arrival address and a first object identifier transferred to this first arrival address, the cryptoprocessor of the payment terminal stores (102) in its secure memory a first pair of public / private keys from which the first arrival address has been generated, this first pair of public / private keys comprising:

A first public key corresponding to the first private key,

the collection terminal obtains and records (130) in its memory, a second arrival address and a second pair of public / private keys from which the second arrival address has been generated, this second pair of keys public / private with a second private key and a second public key corresponding to this second private key,

in the absence of connection with the set of servers, the payment and collection terminals (20, 22) establish (110), via their respective transmitters / receivers, an information exchange link between them, characterized in that, even in the absence of connection with the set of servers,

the cryptoprocessor transmits (126, 136) to the collection terminal, via the information exchange link, the first private key or the second signed transaction constructed by the cryptoprocessor, then

the cryptoprocessor registers (128, 138), in the secure memory, a second identifier of the object transferred by the second transaction able to prevent any new transfer of the same object from the first arrival address, and then

when a new transaction is constructed by the cryptoprocessor, the cryptoprocessor compares (124, 132, 156) the identifier of the object transferred by this new transaction to the second identifier of the transferred object stored in the secure memory, and

- only in the case where the identifier of the object transferred by this new transaction corresponds to the second identifier of the transferred object stored in the secure memory, the cryptoprocessor prohibited (124, 132, 156) the transmission of this new transaction to the collection terminal.

11. Information storage medium (36), readable by a cryptoprocessor, characterized in that said information recording medium comprises instructions for carrying out a method according to claim 10 when said instructions are executed by the cryptoprocessor.