Secure transaction signing process

Abstract

A method comprising the following steps, implemented by a signing device: receiving (100) transaction data ($, add) from a terminal indicating a payee and an amount of digital assets to be transferred to the payee; determining (102) a PIN; encrypting the transaction data and the PIN to produce a request (req) comprising the transaction data and the PIN in encrypted form; sending (106) the request (req) to the terminal, which transmits the request (req) to a server; receiving (108) a proof code from the terminal; verifying (110) that the PIN and proof code match; digitally signing (112) the transaction data, provided that the PIN and proof code match, to produce signed transaction data (Trx); and sending (112) the signed transaction data (Trx) to the terminal. Figure for the abstract: Fig. 3

Description

Title of the invention: Secure transaction signing method FIELD OF INVENTION

[0001] The present invention relates to a method for signing transactions. STATE OF THE ART

[0002] Ownership of digital assets such as cryptocurrency is proven by signatures: a user proves this ownership by signing a transaction to be executed; the validity of this signature is then verified, as well as a link between the public verification key and the digital assets to be spent. The public verification key is associated with a private key specific to that user. Thus, a cryptocurrency user must manage their secret private key, and the security of all their funds depends on the secrecy of this key.

[0003] A hardware wallet can be used to store and manage the use of its private key. This solution provides a high level of security. Each time the user wishes to carry out a transaction, they provide the transaction data (amount and beneficiary's "address") to the hardware wallet, so that the latter can sign this transaction data with the private key stored in the hardware wallet. The signed transaction can then be validated, for example, by a blockchain network.

[0004] However, it is important that the user be convinced that the wallet will sign exactly the transaction they requested, and not a modification of it. An attacker could indeed update the transaction data, replacing the transaction beneficiary with another (themselves, for example) and / or increasing the transaction amount, to obtain more money.

[0005] To protect against such attacks, some hardware wallets are equipped with a user interface for entering or verifying this information. If the wallet has a keyboard, the user can use it to enter the transaction details directly on the hardware wallet. A display screen can also be used, either in addition to a keyboard or on its own. In this case, a terminal can be used to enter or select transaction data and then communicate this data to the hardware wallet; this data is then displayed on the hardware wallet's display screen, allowing the user to verify that the requested transaction has not been modified in the meantime by the terminal or by interference with the communication between the terminal and the hardware wallet.

[0006] However, a screen or keyboard has a cost and may be difficult / impractical for some users to use, and furthermore these input / output devices they themselves could be susceptible to an attack in order to alter the transaction parameters. Description of the invention

[0007] A technical problem to be solved is to ensure that a signing device signs transaction data with a good level of confidence without increasing the manufacturing cost of this signing device.

[0008] This technical problem is solved by a process comprising the following steps, implemented by a signing device, such as a physical wallet: • receiving transaction data from a terminal, the transaction data indicating a beneficiary and an amount of digital assets to be transferred to the beneficiary, • Determining a secret code, • Encrypting the transaction data and the secret code using an encryption key, so as to produce a request including the transaction data and the secret code in encrypted form, • Sending the request to the terminal, the terminal being configured to forward the request to a server, the server being configured to: • decrypt the request using a decryption key, in order to recover the transaction data and the secret code, • implement a measure to communicate transaction data in association with the PIN to a terminal user, • receipt of a test code from the terminal after the measure has been implemented, • verification of the correspondence between the secret code and the proof code, • digital signature of transaction data provided that the secret code and the proof code match, so as to produce signed transaction data, • Sending signed transaction data to the terminal.

[0009] The process, which is the first subject of this disclosure, may further include the following optional features, taken alone or in combination whenever technically possible.

[0010] Preferably, the encryption key and the decryption key form an asymmetric key pair.

[0011] Preferably, the transaction data and / or the proof code are received by direct communication between the signing device and the terminal.

[0012] Preferably, the signing device is or includes a smart card.

[0013] Preferably, the request is digitally signed by the signing device, and the server is configured to check whether the request has been digitally signed by the signing device, the measure being implemented on the condition that the check reveals that the request has been digitally signed by the signing device.

[0014] Preferably, the proof code is a code that was entered on the terminal.

[0015] Preferably, the measure includes sending a message containing the data of transaction in association with the secret code to a recipient device.

[0016] Preferably, the receiving device is separate from the terminal.

[0017] Preferably, the transaction data originating from the terminal were sent to the signing device on command of a first terminal application, and the measure includes sending a message including the transaction data in association with the secret code to a second terminal application independent of the first application, the second application being configured to cause a return of the transaction data and the secret code to the user by an output device of the terminal.

[0018] Preferably, the server is configured to generate graphic data and to include the graphic data in the message, the graphic data presenting: characters indicating the beneficiary, the amount and the secret code, and background noise suitable for distorting optical character recognition by a machine.

[0019] Preferably, the server is configured to generate the message in the form of a voice message reproducing the transaction data and the secret code, when the voice message is played by a loudspeaker.

[0020] Preferably, the message is a text message.

[0021] A second object of this disclosure is a computer program product comprising program code instructions for executing the steps of the process as defined above, when this program is executed by a signing device.

[0022] A third object of this disclosure is a system comprising a signing device, a terminal and a server, in which: • The signing device is configured to: receive transaction data from the terminal, the transaction data indicating a beneficiary and an amount of digital assets to be transferred to the beneficiary, determine a secret code, encrypt the transaction data and the secret code using an encryption key, so as to produce a request including the transaction data and the secret code in encrypted form, and send the request to the terminal; • the terminal is configured to forward the request to the server; • the server is configured to: decrypt the request using a decryption key, so as to retrieve the transaction data and the secret code, implement a measure to communicate the transaction data in association with the secret code to a terminal user; • the terminal is configured to send a proof code to the signing device after the measure has been implemented; • The signing device is configured to: verify a match between the secret code and the proof code, digitally sign the transaction data provided that the secret code and the proof code match, so as to produce signed transaction data, and send the signed transaction data to the terminal. DESCRIPTION OF THE FIGURES

[0023] Other features, objectives and advantages of the invention will become apparent from the following description, which is purely illustrative and not limiting, and which should be read in conjunction with the accompanying drawings on which:

[0024] Figures 1 and 2 schematically illustrate a system for signing transactions.

[0025] The [Fig.3] is a flowchart of steps of a process according to an embodiment of the invention.

[0026] Throughout the figures, similar elements bear identical references. DETAILED DESCRIPTION OF THE INVENTION 1) System

[0027] With reference to [Fig.1] and [Fig.2], a system comprises a signing device 1, a terminal 2 and a server 3. 1.1) Signatory device

[0028] The signatory device 1 includes a communication interface 10, a memory 12 and a processor 14.

[0029] The communication interface 10 is designed to communicate directly with the terminal 2. By "directly", we mean that this communication is carried out in an ad hoc manner, without going through a remote server or more generally a remote network.

[0030] For this purpose, the communication interface 10 includes a physical port suitable for being electrically connected to a port of terminal 2 and / or an antenna for exchanging radio waves with an antenna of terminal 2, via any protocol: near field (NFC), Bluetooth, Wi-Fi, etc.

[0031] Memory 12 stores at least one Wsk private key whose function is to prove ownership of digital assets. As will be seen later, this private key is used to sign transactions. The memory can store several private keys of this type; the private keys can then be derived from the same master key also stored in memory 12. Preferably, memory 12 is contained within a secure element of the signing device 1. In this way, data storage is secure.

[0032] In one embodiment, the digital assets are cryptocurrency (for example, bitcoins).

[0033] Preferably, the signing device 1 is a hardware wallet. Unlike software wallets, which are applications installed on a computer or smartphone, hardware wallets are dedicated devices, often resembling USB keys or smart cards, which keep private keys offline and safe from cyberattacks.

[0034] However, it should be noted that the digital assets to which a private key relates are not necessarily stored within themselves by the signing device 1; the signing device 1 may in fact only store the right to use them (the private key). For example, when the digital assets are cryptocurrency, they are stored in a blockchain, which is essentially a database distributed across several network devices.

[0035] Memory 12 also stores a program comprising code instructions executable by the processor.

[0036] The processor 14 of the signatory device 1 is configured to execute the program. This execution causes the implementation of steps of a process which will be described later.

[0037] The signing device 1 is devoid of a display screen and keyboard. Preferably, the signing device comprises a biometric sensor as its sole means of data entry.

[0038] In some embodiments, the signing device 1 is in the form of a single module. The signing device 1 is, for example, a smart card or a USB key.

[0039] In other embodiments, the signatory device 1 comprises two modules: • a processing module that includes memory 12 and processor 14, and • a removable interconnection module relative to the processing module, and including communication interface 10.

[0040] The interconnect module is designed to be electrically connected to the processing module, so that data received by the communication interface 10 is transferred to the processor 14 and / or the memory 12, and vice versa, so that the processor 14 can cause data to be sent outside the signing device 1 via communication interface 10. The interconnection module can also be detached from the processing module.

[0041] By way of example, the processing module is a smart card, and the interconnection module includes a slot to receive at least part of the smart card, thus establishing physical communication between them.

[0042] Regardless of the form of the signatory device 1 (in a single module or in several modules), communications between the signatory device 1 and the terminal are direct, as previously indicated, without going through a remote server. Thus, communications between these two devices are intended to take place on a local scale, between devices owned by the same user. 1.2) Terminal

[0043] Terminal 2 includes a first communication interface 20 for communicating with the signatory device 1, a memory 22, at least one processor 24, a human-machine interface 26, and, optionally, a second communication interface 28 for communicating with the server 3.

[0044] The first communication interface 20 is designed to communicate directly with the communication interface 10 of the signing device 1. This communication can be achieved through electrical contact and / or radio waves (for example, via NFC near-field communication). When the signing device 1 is a smart card or a USB key, the terminal 2 may include a slot into which the signing device can be inserted to establish electrical contact between the port of the signing device 1 and a port of the terminal 2.

[0045] The memory 22 also stores at least one application comprising code instructions executable by the processor 24. In one embodiment, the memory stores two applications independent of each other: a first application A and a second application B.

[0046] The processor or processors 24 are configured to execute the application or applications A, B. This execution triggers steps that will be described later. For example, the same processor executes applications A and B. Alternatively, two different processors execute applications A and B, respectively. Either processor may be equipped with a secure enclave.

[0047] The human-machine interface 26 includes an output device, typically a display screen, to provide information to a user visually, and optionally a speaker to provide information to a user audibly.

[0048] The human-machine interface 26 further includes an input device enabling a user of terminal 2 to detect user actions that may be processed by application A during its execution. For example, the input device is or includes a touch-sensitive element, forming a touch screen with the display screen.

[0049] Terminal 2 is for example a generic smartphone or laptop, customized with application A, or even with application B (we will see later that application B can alternatively be installed in a device that is separate from terminal 2).

[0050] The second communication interface 28 is for communicating with the server 3. It may be different from the first communication interface 20. The second communication interface may be of any type: wired (Ethernet) or wireless radio (cellular, Wi-Fi, etc.). 1.3) Server 3

[0051] The server 3 includes a communication interface 30, a memory 32 and at least one processor 34.

[0052] The communication interface 30 is suitable for communicating with the second communication interface of terminal 2, or with another receiving device having the same components as those described above.

[0053] Memory 32 stores a program comprising code instructions executable by the processor or each processor 34.

[0054] The processor or processors 34 are configured to execute the program. This execution causes the implementation of steps which will be described later. 2) Transaction signing process

[0055] With reference to [Fig.3], a process implemented by the system described above comprises the following steps.

[0056] In step 200, terminal 2 detects that a user requests the execution of a digital asset transaction. For example, this request is made via a menu of the first application A, displayed on the display screen of terminal 2, and with which the user has interacted.

[0057] In particular, the first application A of terminal 2 detects at step 200 an entry or selection, by the user of terminal 2, of a beneficiary and an amount of digital assets to be transferred to that beneficiary.

[0058] The first application A of terminal 2 generates transaction data indicative of the beneficiary and the amount. For example, the beneficiary can be characterized by an address add, and the amount by a value denoted $ in the following.

[0059] In step 202, the first application A of terminal 2 commands the signing device 1 to send a request to sign the transaction data. The signature request includes the data add and $. The signature request is transmitted via a communication channel previously established between the communication interface 10 of the signatory device 1 and the first communication interface 20 of the terminal 2.

[0060] In a step 100, the signing device 1 receives the signature request via its communication interface 10; the signature request is transmitted to the processor 14.

[0061] In step 102, before proceeding with a signature, the signing device 1 first determines a secret code, denoted PIN. The secret code is, for example, generated by the signing device 1 randomly or pseudo-randomly, so that the generated secret code varies with each new signature request received by the signing device 1.

[0062] In a step 104, the signing device 1 encrypts the transaction data and the secret code using an encryption key Spk, so as to produce a request re(l) including the transaction data and the secret code in encrypted form.

[0063] The encryption key is a public key of the server 3, which was provided to the signing device 1 during a preliminary step, for example at the factory.

[0064] The encryption performed can be of the following form:

[0065] req - AendSpk, $ + add+PIN)

[0066] where Aenc is a cryptographic encryption function.

[0067] In addition to encryption, the signing device 1 can implement a digital signature at step 104, so that the resulting re(!) request is not only encrypted, but also digitally signed, which makes it possible to certify that the re(!) request was produced by the signing device 1.

[0068] In a step 106, the signing device 1 sends the request re^ to terminal 2.

[0069] In step 204, terminal 2 transmits the request to server 3. This transmission is for example caused by the first application A.

[0070] In step 300, server 3 receives the request re <I.

[0071] In step 302, the server decrypts the re^ request using a key of Ssk decryption forms an asymmetric key pair with the Spk encryption key, so as to recover the transaction data and the secret code in plaintext.

[0072] The decryption can be represented by the formula below:

[0073] 5 + add + PIN = Dec\(Ssk, req)

[0074] where Decv is a cryptographic decryption function.

[0075] The Ssk decryption key is a private key of server 3 stored in its memory 32 and not communicated outside of server 3.

[0076] Server 3 can also check whether the re^ request has been digitally signed by the signing device 1. This check can be implemented using a key The public key is either provided by the signing device 1 via a certificate or retrieved from a database where the public key is associated with an identifier specific to the signing device 1. Preferably, this verification is performed before decryption step 302. If this is not possible, the process can be interrupted. If the verification is successful, the server performs the decryption step 302.

[0077] In step 304, the server implements a measure to communicate the transaction data in association with the secret code to a user of terminal 2. This step can be implemented in various ways.

[0078] In some embodiments, measure 304 includes the server 3 sending a message containing the transaction data in association with the code, the message being sent to a recipient device. The recipient device in question may have been previously enrolled with the server during a preliminary enrollment step, thus allowing the server 3 to know that it is associated with the signing device from which the request originates, i.e., L, which implicitly assumes that the recipient device is in the user's possession.

[0079] The message sent in step 304 can also take different forms.

[0080] In some variants, the message is a text message. The text message may be an email sent to a previously enrolled address considered to belong to the legitimate owner of the signing device 1. The second application B is then an internet browser or an email-type messaging application, through which the user can view the email sent to the recipient device via the previously enrolled address. Alternatively, the text message is an SMS, sent to a previously enrolled telephone number. The second application B is then an SMS messaging application on the recipient device.

[0081] In other variants, the message is a voice message generated by server 3 capable of audibly reproducing the transaction data and code to the user when the voice message is played through a speaker on the recipient device. In this case, the second application B can be an audio player to play the voice message so that it is reproduced by the speaker on the recipient device.

[0082] In other variants, the server 3 generates graphical data containing characters indicating the beneficiary, the amount, and the PIN, and also containing background noise designed to interfere with optical character recognition (OCR). The graphical data may comprise a single image containing all this information, or several images in which this information is distributed. The server 3 includes the graphical data in the message to be sent to the recipient device. Such graphical data has the advantage of strengthening the security of the process against attacks that would attempt to intercept and modify the message.

[0083] The sending of the message containing the transaction data and the code may be preceded by the server sending the recipient device a link to a web page displaying or providing access to the transaction data in association with the code. The user of the recipient device must then access the page via a web browser, and it is only subsequently that the message containing the transaction data and the code is downloaded to the recipient device.

[0084] Different types of recipient devices are also possible. In some variants, the recipient device is separate from terminal 2, which increases the attack surface and therefore makes the process more secure. In other variants, the message recipient device is terminal 2, which was used to initiate the transaction signature request with the signing device 1, as described above.

[0085] When the message recipient is terminal 2, the message can be addressed to the terminal's second application B, independent of the first application A used previously. The message is not received by the first application A. The second application B then outputs the transaction data and code to the user via a terminal output device (display screen or speaker, depending on the implemented variant). This separation between the two applications also increases the attack surface of the process. Furthermore, this separation indirectly reduces the associated risk. Indeed, if an attack were to occur, it would be less "massive" since it would only affect one application A and B configuration out of all possible configurations.

[0086] In step 206, the first application A of terminal 2 detects that the user has entered a proof code, denoted PIN' (and assumed to correspond to the secret code in a normal case). This detection may follow the display of a prompt to that effect on the display screen of terminal 2, this display being caused by the first application A, for example after the transaction data has been sent to the signing device in step 202.

[0087] In a step 208, the first application A of terminal 2 causes the entered PIN' test code to be sent to the signing device 1, via the first communication interface 20.

[0088] In step 108, the signing device receives the proof code.

[0089] In step 110, the signing device checks if the PIN secret code and the code PIN' test results correspond.

[0090] If the PIN secret code and the PIN' proof code match, the signing device proceeds to step 112.

[0091] In step 112, the signing device 1 digitally signs the transaction data using its private key Wsk, so as to produce Trx-signed transaction data. This step is known from the prior art. This signature can be represented by the following formula:

[0092] Trx-Sigi^Wsk, $ + add)

[0093] where Sign is a cryptographic digital signature function.

[0094] In a step 114, the signing device sends the Trx signed transaction data to terminal 2.

[0095] Terminal 2 receives the signed transaction data Trx in a step 210. Terminal 2 can then issue a request for validation of the signed transaction data in order to carry out the actual transfer of the amount of digital asset 5 to the beneficiary with the address add. In one embodiment, the signed transaction data is validated by network equipment ("miners") having access to a blockchain constituting a distributed database (blockchain), and is recorded in the blockchain.

[0096] If, on the other hand, the PIN secret code and the PIN' proof code do not match, the signing device 1 does not implement step 112 of the digital signature. The aforementioned asset transfer cannot be validated in the absence of a signature.

[0097] Additionally, the signing device 1 can also implement a countermeasure if the PIN and the PIN' proof code do not match. An example of such a countermeasure is as follows: the signing device updates an error counter that it stores, then compares the error counter to a predefined threshold. If the counter reaches the threshold, the signing device locks itself, thus preventing any further signing. The same counter is reset to zero when the PIN and the PIN' proof code match (unless the counter has reached the threshold). Other ways of implementing this

[0098] In the foregoing, an embodiment was discussed in which the encryption key and the decryption key form an asymmetric key pair. This aspect contributes to the security of the process. However, in other embodiments, the encryption key and the decryption key could be identical, in which case the 104 encryption and 302 decryption are symmetric, for example, an AES encryption / decryption.

Claims

Demands

1. A method comprising the following steps, implemented by a signing device, such as a hardware wallet: • receiving (100) transaction data ($, add) from a terminal, the transaction data indicating a payee and an amount of digital assets to be transferred to the payee, • determining (102) a secret code (PIN), • encrypting the transaction data and the secret code using an encryption key, so as to produce a request (req) comprising the transaction data and the secret code in encrypted form, • sending (106) the request (req) to the terminal, the terminal being configured to transmit the request (req) to a server, the server (3) being configured to: • decrypt the request using a decryption key, so as to recover the transaction data and the secret code,• implement a measure to communicate the transaction data in association with the PIN to a terminal user, • receive (108) a proof code from the terminal after the measure has been implemented, • verify (110) that the PIN and proof code match, • digitally sign (112) the transaction data provided that the PIN and proof code match, so as to produce signed transaction data (Trx), • send (112) the signed transaction data (Trx) to the terminal.

2. A method according to the preceding claim, wherein the encryption key and the decryption key form an asymmetric key pair.

3. A method according to any one of the preceding claims, wherein the transaction data and / or the proof code are received by direct communication between the signing device and the terminal.

4. A method according to any one of the preceding claims, wherein the signing device is or comprises a smart card.

5. A method according to any one of the preceding claims, wherein the request (req) is digitally signed by the signing device, and the server is configured to check whether the request has been digitally signed by the signing device, the measure being implemented on the condition that the check reveals that the request has been digitally signed by the signing device.

6. A method according to any one of the preceding claims, wherein the proof code is a code that was entered on the terminal.

7. A method according to any one of the preceding claims, wherein the measure includes sending a message comprising the transaction data in association with the secret code to a recipient device.

8. Method according to the preceding claim, wherein the receiving device is separate from the terminal.

9. A method according to claim 7, wherein: • the transaction data from the terminal were sent to the signing device on command from a first application (A) of the terminal, • the measure includes sending a message including the transaction data in association with the secret code to a second application (B) of the terminal independent of the first application (A), the second application (B) being configured to cause a restitution of the transaction data and the secret code to the user by an output device of the terminal.

10. A method according to any one of claims 7 to 9, wherein the server is configured to generate graphic data and to include the graphic data in the message, the graphic data having: • characters indicating the beneficiary, the amount and the secret code, and • background noise suitable for distorting optical character recognition by a machine.

11. A method according to any one of claims 7 to 9, wherein the server is configured to generate the message under

12.

13.

14. A voice message containing the transaction data and the secret code, when the voice message is played through a loudspeaker. A method according to any one of claims 7 to 9, wherein the message is a text message. Product computer program comprising program code instructions for executing the steps of the process according to any one of the preceding claims, when this program is executed by a signing device. A system comprising a signing device (1), a terminal (2) and a server (3), in which: the signing device (1) is configured to: • receive transaction data from the terminal, the transaction data indicating a beneficiary and an amount of digital assets to be transferred to the beneficiary, • determine a secret code, • Encrypt the transaction data and the secret code using an encryption key, so as to produce a request including the transaction data and the secret code in encrypted form, • send the request to the terminal, terminal (2) is configured to forward the request to server (3), Server (3) is configured to: • decrypt the request using a decryption key, in order to recover the transaction data and the secret code, • implement a measure to communicate transaction data in association with the PIN to a terminal user, terminal (2) is configured to send a proof code to the signing device after the measure has been implemented, the signing device (1) is configured to: • verify that the secret code and the proof code match, digitally sign the transaction data provided that the secret code and the proof code match, so as to produce signed transaction data, send the signed transaction data to the terminal (2).