A method of signing a transaction in plain text, implemented in a hardware cryptocurrency wallet.

Abstract

A method for signing a transaction in plaintext using a crypto-asset hardware (HW) wallet comprising a secure processor (SPROC), the method comprising the steps of providing the transaction (RTRAN) to the secure processor in raw form, and, using the secure processor, executing a move command within the transaction to find a target segment, executing a termination command to extract the transaction data from the transaction, formatting the transaction data with the formatting data, and displaying the formatted transaction data (FTDATA1) on a secure screen (DISP1). Abbreviated figure: Fig. 1

Description

Title of the invention: Method for signing a transaction in plain text implemented in a hardware wallet for crypto-assets. Technical field

[0001] The present invention relates to a method for signing a transaction using a hardware wallet comprising a secure processor, volatile memory and a secure screen controlled by the secure processor. Background

[0002] The present invention relates to hardware wallets for crypto-assets, commonly referred to as "hardware wallets," and clear signing techniques. Hardware wallets for crypto-assets are specialized physical devices designed to securely store private keys and sign transactions on blockchains. These wallets are equipped with a secure processor, often in the form of an electronic chip of the type called a "secure element," which is specifically designed to perform cryptographic operations while being protected against various software and hardware attacks. Hardware wallets for crypto-assets allow for "cold" signing of transactions, that is, offline signing, which means that the private key used to sign the transaction is never permanently exposed to an insecure network or a potentially compromised device.This ensures a high level of security by preventing malicious actors from accessing the private key.

[0003] In a typical use case, the transactions to be signed are generated by a host device such as a personal computer, smartphone, or tablet. The host device is connected to the internet and serves as an interface for preparing the transaction. The hardware wallet is then connected to the host device via a local connection, which can be USB, Bluetooth®, or NFC (Near Field Communication). This connection allows the host device to transmit the raw transaction, in binary form, to the hardware wallet. The hardware wallet's secure processor then handles the signing process using the securely stored private key. The signing is performed entirely within the hardware wallet, ensuring that the private key is never exposed externally. Thus, even if the host device is compromised by malware, the private key remains protected.

[0004] Hardware wallets are generally equipped with a secure screen, controlled directly by the secure processor. This screen allows the user to verify essential transaction details before signing it. The information displayed may include the transaction amount, the currency, or the relevant blockchain (e.g., by (e.g., Bitcoin, Ethereum), the recipient's address, and the transaction fees. This step is crucial to ensure the user is fully informed and explicitly consents to the transaction. To authorize the transaction, the user interacts with the hardware wallet, typically by pressing a physical button or using a touchscreen interface, after authenticating by entering a PIN. This action confirms the user has verified the information and wishes to proceed.

[0005] Active user involvement and the provision of clear information play a crucial role in the security of the process. This verification step is often referred to by the acronym "WYSIWYS" for "What You See Is What You Sign." This principle ensures that the user can verify the exact semantic content of the transaction before signing it, thus reducing the risk of fraud or error.

[0006] Verifying the transaction content has therefore become a major concern due to the increasing number of attacks targeting what is known as the "presentation layer," in other words, the user interface that displays transaction information. Malicious actors may attempt to manipulate this layer to display false information, inducing the user to sign a transaction different from the one they believe they are authorizing. Providing a secure screen is a solution that addresses this problem, provided that the essential transaction information can be extracted for display.

[0007] For standard transactions, the secure processor is generally capable of analyzing the binary string constituting the received raw transaction and identifying predetermined locations where the essential data to be displayed is located. This process is known as "clear signing," which allows raw transactions to be analyzed to extract the information necessary for user consent.

[0008] However, a challenge remains when dealing with complex transactions, particularly those involving smart contracts. Analyzing smart contract transactions for the purpose of signing them in plaintext is indeed much more complex. These transactions can vary considerably in structure and content, and essential data may be located in different positions depending on the smart contract and the function being called. Furthermore, each smart contract may have its own Application Binary Interface (ABI), which defines how the data must be structured to interact with the contract.

[0009] To manage this diversity, it is necessary to develop specific analysis programs for each type of smart contract and transaction. These programs, often called "plugins" or "extension modules," are small applications installed on the hardware wallet. They allow for the analysis of transactions. specific to a particular smart contract, to extract essential data and display it to the user. The applicant has, for example, developed plugins dedicated to certain popular smart contracts.

[0010] However, these plugins occupy a significant portion of the non-volatile memory space in the hardware wallet and are only suitable for a specific type of transaction. Furthermore, the position of critical data fields can vary from one transaction to another, necessitating frequent updates to these plugins. Each change to the smart contract's ABI also requires a plugin update and a new security audit to ensure that the plugin remains secure and functional. This requirement represents a significant burden for companies developing smart contracts, as it entails substantial costs and effort to keep these plugins up to date.

[0011] Furthermore, there are millions of smart contracts deployed on blockchains, and several thousand of them are used daily by hardware wallet owners. It is not realistic to develop and install a plugin for each smart contract or each type of transaction.

[0012] The EIP-712 (Ethereum Improvement Proposal 712) standard is also known. EIP-712 defines a method for structuring, hashing, and signing typed data on Ethereum. It allows the message structure to be described clearly and decoded for a better user experience. Thanks to EIP-712, signed messages can be presented to the user in a readable and verifiable form. However, the EIP-712 standard is designed to sign messages that are not broadcast on a blockchain and is not usable for transactions.

[0013] There is therefore a need to find a simple and inexpensive solution in terms of memory resources to enable hardware wallets to have a transaction parser allowing plaintext signing with many types of transactions, including those involving a function call to a smart contract, without the need to develop and install numerous specific plugins. Such a solution would allow users to verify essential transaction information, including that intended for complex smart contracts, directly on the secure screen of their hardware wallet, thereby enhancing security and trust in the process. Summary

[0014] Embodiments relate to a method for signing a transaction in plaintext using a hardware crypto-asset wallet, the hardware wallet comprising a secure processor and a secure screen controlled by the secure processor, the method comprising the steps of: providing the transaction to the secure processor in raw form comprising a block of binary data structured comprising segments of a defined length; provide the secure processor with at least one transaction data descriptor relating to a transaction data item to be displayed in plain text to a user, the transaction data descriptor comprising: at least one move command in the structured binary data block, enabling the secure processor to reach at least one target segment from a starting segment, at least one termination command indicating to the secure processor the location and extent of the transaction data in or from the target segment, and transaction data formatting, enabling the transaction data to be made intelligible to a user;and, using the secure processor: execute the move command to find the target segment, execute the terminate command to extract the transaction data from the structured binary data block, and format the transaction data with the formatting data; display the formatted transaction data on the secure screen; receive approval from a user, via an approval method controlled by the secure processor; and generate a transaction signature using a private key.

[0015] According to one embodiment, the method comprises steps consisting of successively providing the secure processor with a plurality of transaction data descriptors, the secure processor displaying on the secure screen in formatted form each formatted transaction data targeted by a transaction data descriptor.

[0016] According to one embodiment, a subsequent transaction data descriptor is provided to the secure processor only after the secure processor has memorized the transaction data extracted from the structured binary data block using a previous transaction data descriptor.

[0017] According to one embodiment, the secure processor temporarily stores a transaction data descriptor in volatile memory and then erases it from volatile memory after using it to extract from the structured binary data block the transaction data targeted by the transaction data descriptor.

[0018] According to one embodiment, the method includes a step of providing the secure processor with an overall hash of all the transaction data descriptors provided to it, and steps of iteratively calculating, using the secure processor, an internal hash of all the transaction data descriptors provided to it, and then verifying that the iterative internal hash is equal to the overall hash.

[0019] According to one embodiment, the method further comprises the steps of providing the secure processor with a block of information including transaction information; using the secure processor, verifying in the raw transaction initial information present in the information block; and display on the secure screen information present in the information block, which may include all or part of the initial information.

[0020] According to one embodiment, the information verified by the secure processor includes at least one of the following: a blockchain identifier, a smart contract address, and a function selector in the smart contract.

[0021] According to one embodiment, the global hash is included in the information block.

[0022] According to one embodiment, the information block includes a signature of all the data it includes including the global hash, the signature being generated using a private key from a certification authority, and including a verification step, by the secure processor, of the signature using a public key from the certification authority.

[0023] According to one embodiment, the method comprises a step of developing a plurality of transaction data descriptors comprising move and terminate commands expressed in a high-level language, the transaction data descriptors being stored in a key / value structured file; a step of converting the transaction data descriptors into binary, where each move and terminate command is converted into a binary format; and a step of communicating the transaction data descriptors to the secure processor in their binary form.

[0024] According to one embodiment, the transaction data descriptors are communicated to the secure processor in their binary form encapsulated in APDUs conforming to the ISO7816 standard.

[0025] According to one embodiment, the step of developing a plurality of transaction data descriptors further includes a step of calculating an overall hash of the set of transaction data descriptors.

[0026] According to one embodiment, a move command within the structured binary data block is selected from a group of move commands for which a location within the structured binary data block corresponds to the location of a segment. The group of move commands comprises: a first command, moving a specified number of segments from a current location to a new location; a second command, moving a specified number of segments from a current location to a new location; and a third command, moving a segment within an array composed of elements. The command specifies the number of segments in each element of the array and implicitly designates or explicitly one or more elements of the array must be reached in order to reach one or more new locations.

[0027] According to one embodiment, a transaction data descriptor includes a binary path comprising a combination of at least two of said first, second and third move commands.

[0028] According to one embodiment, a termination command is chosen from a group of termination commands comprising: a first termination command indicating that the segment reached contains the transaction data to be extracted, and a second termination command indicating that the segment reached contains a number indicating the length of the transaction data to be extracted, the transaction data to be extracted immediately following this number.

[0029] According to one embodiment, the method also includes a third termination command that can be combined with the first or second termination command, indicating that transaction data identified by the first or second termination command should be clipped to retain only bytes of the transaction data between a first and last byte specified in the command.

[0030] Embodiments also relate to a method of signing a transaction in plain text, implemented by means of a secure processor, the transaction comprising a structured binary data block comprising segments each defining a location, the method comprising the use of at least one move command in the structured binary data block, in order to reach at least one target segment from which data to be displayed in plain text to a user can be extracted from the binary data block, the move command being executable by the secure processor and chosen from the set of move commands comprising: a first command, to move, from a current location, a determined number of segments specified by the command, to reach a new location;a second command, to move, from a current location, a number of segments determined by a number that is read at the current location, to reach a new location; and a third command, to move within an array composed of elements, the command specifying the number of segments that each element of the array comprises and implicitly or explicitly specifying one or more elements of the array to be reached in order to reach one or more new locations.

[0031] According to one embodiment, the method includes the use of at least two of the movement commands from the command set.

[0032] According to one embodiment, the method includes the use of the three movement commands of the command set.

[0033] According to one embodiment, the method also includes the use of at least one termination command executable by the secure processor, the termination command being chosen from the set of commands comprising: a first termination command indicating that the segment reached contains the transaction data to be extracted, and a second termination command indicating that the segment reached contains a number indicating the length of the transaction data to be extracted, the data to be extracted immediately following this number.

[0034] According to one embodiment, the method includes the use of the first and second termination commands.

[0035] According to one embodiment, the method also includes the use of a third termination command that can be combined with the first or second termination command, the third termination command indicating that transaction data identified by the first or second termination command should be cut to retain only bytes of the transaction data between a first and last byte specified in the command.

[0036] According to one embodiment, the method comprises, following a step of transmitting the transaction comprising the structured binary data block to the secure processor, a step of transmitting said at least one move command to the secure processor followed by a step of executing the command by the secure processor to extract the data to be displayed in plain text.

[0037] According to one embodiment, the secure processor stores the movement command in volatile memory for the duration of its execution, then erases the command from volatile memory after using it.

[0038] According to one embodiment, the method comprises a step of providing the secure processor with a series of transaction data descriptors relating to data to be displayed in plain text, each transaction data descriptor comprising at least one move command, at least one termination command, and transaction data formatting data, enabling the transaction data to be made intelligible to a user; a step of providing the secure processor with an overall hash of all the transaction data descriptors; a step of calculating, by means of the secure processor, an internal hash of all the transaction data descriptors provided to it; and a step of verifying by the secure processor that the internal hash is equal to the overall hash.

[0039] Embodiments also relate to a set of commands executable by a secure processor, comprising at least one move command, in a binary data block of a crypto-asset transaction that is structured in segments, each defining a location, said at least one command of displacement enabling the secure processor to reach at least one target segment from which data, the display of which to a user is essential to the security of a transaction, can be extracted from the binary data block, said at least one displacement command being chosen from the displacement command group comprising a first command, of displacement, from a current location, of a determined number of segments specified by the command, to reach a new location; a second command, of displacement, from a current location, of a number of segments determined by a number which is read at the current location, to reach a new location;and a third command, for moving within an array composed of elements, the command specifying the number of segments that each element of the array comprises and implicitly or explicitly specifying one or more elements of the array to be reached in order to reach one or more new locations.

[0040] According to one embodiment, the command set includes at least two movement commands chosen from said first, second and third movement commands.

[0041] According to one embodiment, the command set includes the first, second and third movement commands.

[0042] According to one embodiment, the command set further includes at least one termination command executable by the secure processor, said at least one termination command being chosen from the group of termination commands comprising: a first termination command indicating that the segment reached contains the transaction data to be extracted, which occupies the entire segment, and a second termination command indicating that the segment reached contains a number indicating the length of the transaction data to be extracted, the data to be extracted immediately following this number.

[0043] According to one embodiment, the command set includes the first and second termination commands.

[0044] According to one embodiment, the command set also includes a third termination command that can be combined with the first or second termination command, the third termination command indicating that transaction data identified by the first or second termination command should be trimmed to retain only bytes of the transaction data between a first and last byte specified in the command.

[0045] Embodiments also relate to a secure processor configured to execute at least one move command, within a structured block of binary data comprising segments each defining a location, in order to reach at least one target segment from which data to be displayed to a user can be extracted from the binary data block, said at least one move command being chosen from the following commands: a first command, to move, from a current location, a determined number of segments specified by the command, to reach a new location; a second command, to move, from a current location, a number of segments determined by a number that is read at the current location, to reach a new location; and a third command, to move within an array composed of elements, the command specifying the number of segments that each element of the array comprises and implicitly or explicitly specifying one or more elements of the array to be reached to reach one or more new locations.

[0046] According to one embodiment, the processor is configured to execute at least two move commands chosen from said first, second and third move commands.

[0047] According to one embodiment, the processor is for executing the first, second and third move commands.

[0048] According to one embodiment, the processor is configured to execute at least one termination command chosen from the following commands: a first termination command indicating that the segment reached contains the transaction data to be extracted, which occupies the entire segment, and a second termination command indicating that the segment reached contains a number indicating the length of the transaction data to be extracted, the data to be extracted immediately following this number.

[0049] According to one embodiment, the processor is configured to execute the first and second termination commands.

[0050] According to one embodiment, the processor is configured to execute a third termination command that can be combined with the first or second termination command, the third termination command indicating that transaction data identified by the first or second termination command should be parsed to retain only bytes of the transaction data between a first and last byte specified in the command. Summary description of the drawings

[0051] Examples of implementations of the clear text signature method for a transaction according to the present invention will be described below by way of non-limiting agreement, in relation to the accompanying figures, among which:

[0052] - Fig. 1 shows a hardware wallet and its environment, configured for to implement the process,

[0053] - Figure 2 shows the structure of a transaction descriptor block comprising a transaction information block and transaction data descriptors,

[0054] - [Fig. 3] is a sequence diagram showing processing steps of a transaction via the hardware wallet by means of a transaction descriptor block,

[0055] - [Fig. 4] is a flowchart showing design and implementation steps work of a transaction descriptor block,

[0056] - [Fig. 5] shows an example of a raw transaction,

[0057] - [Fig. 6] shows a structured binary data block present in the transaction raw [Fig.5],

[0058] - Figure 7 shows an example of a transaction information block present in a transaction descriptor block,

[0059] - [Fig.8] shows examples of movement commands and commands termination features present in a descriptor within a transaction data descriptor,

[0060] - Figures 9, 10 and 11 show examples of descriptors of transaction data, and

[0061] - Figure 12 shows transaction data extracted from the binary data block of the [Fig.6] presented in a formatted form to a hardware wallet user. Detailed description

[0062] Figure 1 represents a hardware wallet (HW) and its environment, the assembly being configured to implement the plaintext signing process according to the present invention. The environment closest to the hardware wallet comprises an HDV host device, for example a PC, a mobile phone, or a tablet, to which the hardware wallet is intended to be connected.

[0063] The hardware wallet HW is configured to implement the process, or any other existing or future hardware wallet. The hardware wallet HW includes a secure processor SPROC, an ICOM communication interface controlled by a microcontroller MC, for example of the USB, Bluetooth® or NFC (Near Field Communication) type, a secure display DISP1, a VB transaction validation button controlled by the secure processor, a secure non-volatile memory MEM1, for example of the ROM or FLASH type, and a secure volatile memory MEM2, for example of the RAM type.

[0064] The MEM1 memory includes a hardware wallet operating system (OS), at least one API application program configured to allow the secure processor to sign transactions related to at least one type of BCN blockchain, for example Ethereum, and at least one KO private key of an account of crypto-assets on the BCN blockchain. The API application program includes a PARS parser (extractor) function configured to process transaction descriptors described later, this function including the execution of move and terminate commands in a block of binary data, these commands being present in the transaction descriptors.

[0065] The SPROC secure processor can be a secure element, that is, a dedicated hardware chip designed to store and manipulate sensitive data, such as cryptographic keys, in an ultra-secure manner, protected against software and hardware attacks. The secure processor can thus perform cryptographic operations, including signing a transaction using the KO private key, without exposing the private key externally.

[0066] The VB button can be a physical button or a touch-sensitive key on the display. The DISP1 display is preferably controlled exclusively by the secure processor, with the MC microcontroller dedicated exclusively to managing the ICOM communication interface.

[0067] The HDV host device includes an APROC application processor running CSW companion software, and a DISP2 screen controlled by the application processor. The CSW companion software and the DISP2 screen allow a USR to prepare transactions destined for the BCN blockchain and to use the HW hardware wallet to sign such transactions. The DISP2 screen is considered insecure in that a USR never has an absolute guarantee that the HDV host device has not been infected by malware that has taken control of the APROC processor and is using the DISP2 screen to display altered information, in order to induce the USR to accept the hardware wallet signing a transaction that is not the one presented to it on the DISP2 screen.

[0068] Let us now consider that a USR user wants to use the HW hardware wallet to sign a "function call" transaction for a smart contract with a complex structure. The user configures the HW hardware wallet and the HDV host device so that these two devices are connected by an LK1 data link provided by the ICOM communication interface and the MC microcontroller. The way in which the transaction is generated can vary depending on the context and the user's interactions. In some cases, the transaction can be generated by the host device's CSW companion software. For example, the user selects an action (e.g., "send tokens" or "interact with a contract"), and the companion software generates the transaction including the contract address, the function selector, and the function's encoded parameters.In other cases, the transaction can be sent to the host device by a decentralized web application known as a "dApp". The host device receives the transaction prepared by the decentralized web application. Often, this is done via a web browser or an extension, such as a browser extension or mobile app that acts as a bridge between the user and decentralized applications (dApps) on blockchains like Ethereum. The decentralized web application encodes the smart contract call, including the function selector and necessary data, and transmits the transaction to the host device. In yet another scenario, the transaction is sent by a third-party server to the host device. The third-party server generates the transaction and sends it to the host device. For example, in a decentralized exchange (DEX), a swap aggregator (a platform that compares and optimizes cryptocurrency swaps between multiple liquidity sources) generates a transaction specific to the exchange's smart contract. The third-party server encodes the parameters and transmits the raw transaction to the host device.

[0069] In any of these cases mentioned above by way of non-limiting examples, the transaction received by or generated by the host device is then sent to the hardware wallet HW by the host device HDV in raw binary RTRAN form.

[0070] The hardware wallet, through the plaintext signing process according to the present invention, which will be described below, displays essential transaction details to the user (USR) on the secure DISP1 screen, allowing the user to verify the transaction before manually approving it by pressing the VB validation button. Once the transaction is approved by the user, the secure processor SPROC generates a hash of the raw transaction. This hash represents a unique cryptographic summary of the transaction data. The hardware wallet then uses the private key KO to sign the hash, which itself never leaves the hardware wallet. The secure processor then returns the STRAN signature of the transaction to the host device HDV. This signature proves that the transaction has been approved by the user (USR) and owner of the private key.The host device then includes the signature in the transaction and sends it to the BCN blockchain for validation and inclusion in a block. This process ensures that the private key remains protected while allowing a cryptographically verifiable signature.

[0071] The raw RTRAN transaction and the STRAN signature are exchanged between the hardware wallet and the host device as binary data. This exchange can be carried out, in certain embodiments, via an exchange of Application Protocol Data Units (APDUs) as defined by the ISO 7816 standard, and more specifically of CAPDU commands and RAPDU responses. In this case, the binary data is broken down into chunks that are encapsulated in the APDU commands or responses and placed in the "payload" field of these commands or responses. On the wallet side Hardware, the secure SPROC processor manages the APDU exchange protocol and ensures the encapsulation of outgoing data in APDUs and the decapsulation of incoming data.

[0072] According to the method, the clear text signing of a transaction also includes the sending, by the HDV host device, to the hardware wallet (HW), in addition to the sending of the raw RTRAN transaction, of a TDES transaction descriptor relating to the transaction in question. This transaction descriptor allows the hardware wallet to parse the raw RTRAN transaction without understanding its meaning, and to extract transaction data from it, then display it in a formatted form understandable to the user so that the user can give their informed consent to the signing of the transaction.

[0073] As illustrated in [Fig. 2], the transaction descriptor TDES optionally includes a transaction information block TINFO followed by transaction data descriptors DES1, DES2, DES3,... DESN, in a number equal to the number of transaction data TDATA1, TDATA2, TDATA3,... TDATAN that are to be displayed in plain text to the user. The TINFO information block includes standard transaction information, examples of which will be described later.

[0074] According to an optional but advantageous aspect of the process in terms of security, the TINFO information block includes a SIGN signature of all the information it contains. This signature is preferably generated by an external secure processor holding a private key of a certification authority. This external secure processor is, for example, a hardware security module HSM1 shown in [Fig. 1], which will be described later. The certification authority may be the manufacturer of the hardware wallet itself. The SIGN signature is intended to be verified by the secure processor SPROC using a PUBK public key of the certification authority, which is provided to the secure processor when the hardware wallet is put into service and which it holds in its MEM1 memory ([Fig. 1]).

[0075] Still referring to [Fig. 2], according to another optional but advantageous aspect of the process in terms of security, the TINFO transaction information block also includes an INSHASH hash generated from all the data present in the transaction data descriptors DES1, DES2, DES3,... DESn, preferably respecting the order in which the descriptors are provided to the hardware wallet. This hash can, like the SIGN signature, be generated by the aforementioned external secure processor. The INSHASH hash is intended to be verified by the SPROC secure processor during steps described later. In the case where the INSHASH hash is intended, it is advantageous in terms of security for the SIGN signature to be generated by including this hash in the input data used to generate it. This signature, in addition to the information contained in the TINFO block, is used to counter a potential attack on DES transaction data descriptors. Such an attack could, for example, consist of deleting a DES descriptor, replacing it with another, or adding a descriptor.

[0076] Each transaction data descriptor DES (DES1, DES2, DES3, ..., DESN) refers to a transaction data item that is to be displayed to the user in an intelligible form. This transaction data is present in a structured binary data block included in the raw transaction. In the case of an Ethereum transaction, this structured binary data block corresponds to the transaction's CALLDATA block minus the SELECTOR function selector located in the first position of the CALLDATA block, as will be seen later.

[0077] Each transaction data descriptor includes on the one hand a binary path descriptor BPATH (BPATH1, BPATH2, BPATH3,.. ..BPATHN) and on the other hand formatting data FORM (FORM1, FORM2, FORM3,....FORMN).

[0078] Each BPATH binary path descriptor includes at least one NCMD move command and at least one TCMD termination command, examples of which will be described later. These move and termination commands are executed by the PARS function of the APL application program. The NCMD move commands allow the secure processor to navigate through the structured binary data block until it finds the location containing the TDATA transaction data (TDATA1, TDATA2, TDATA3, ..., TDATAN) targeted by the binary path descriptor. Once the location of the TDATA transaction data has been found, the TCMD termination command provides instructions for extracting the TDATA transaction data that is to be displayed to the user from the location reached by means of the move commands.

[0079] The PARS function of the API application program then uses the FORM formatting data to obtain a formatted transaction data FTDATA (FTDATA1, FTDATA2, FTDATA3,.... FTDATAN) which the secure processor then displays to the user by means of the secure DISP1 screen, thus achieving the "clear signing" objective of the present invention.

[0080] The FORM formatting data includes, in particular, labels such as "address", "recipient", "action", "token", "expiration date", etc., which allow the user to identify the nature of TDATA transaction data extracted using the BPATH binary path descriptor present in the DES transaction data descriptor. It also includes information enabling the secure processor to transform the raw transaction data for display it in an understandable format. For example, data of type "date" must be presented to the user in a form that allows them to understand that date.

[0081] The NCMD and TCMD move and termination commands present in the BPATH binary path descriptors are generic and allow the description of any binary path for a given type of function call transaction to a smart contract whose transaction data may have lengths that vary from one transaction to another. They are based on the structuring of the binary data block into segments ("chunks") of the same length, and on the type of data that the data block may contain (e.g., static data, indexed dynamic data, array element), each segment being considered as a location.These commands provide instructions to the secure processor on the number of locations to traverse from a starting location to reach a target location containing the transaction data—or target data—targeted by the binary path descriptor, and instructions on how the target data should be extracted, namely its exact location in the target segment, and / or its size, and / or the location of the first byte of the data and / or the location of its last byte, etc.

[0082] This structuring of the binary data block may be specific to the type of blockchain considered. For example, in an Ethereum transaction, the division of the uninterrupted binary data chains of the CALLDATA block into 32-byte segments is a construct inherent to the Ethereum protocol and to the way in which data is encoded in a transaction, in accordance with the ABI (Application Binary Interface) encoding specification.

[0083] Move and termination commands are low-level commands in that they merely provide movement instructions within the binary data block that the secure processor must follow without interpreting the data it contains. Their generic nature lies in the fact that they take into account data of variable size, the variability of which is not known a priori but is indicated in the structured binary data block of the raw transaction. Examples of commands will be described later.

[0084] As a result, the PARS function, configured to execute the move and termination commands, is itself generic and allows the secure SPROC processor to "blindly" extract any transaction data from any location in the structured binary data block of the raw transaction, without understanding the meaning of this data, and then display some of it in a form intelligible to the user through formatting data.

[0085] The PARS function integrated into the API application program, in combination with the provision of the TDES transaction descriptor to the hardware wallet, It therefore advantageously replaces prior art plugins applicable to only one type of transaction. This function alone can cover an unlimited number of transactions for a given type of smart contract, thus replacing an unlimited number of plugins that would need to be developed to achieve the same result.

[0086] Indeed, there is no strict theoretical limit to the number of functions that a smart contract can contain. The number of different transactions that can be sent to the same smart contract is therefore practically unlimited, but depends on several factors:

[0087] - a smart contract has a maximum size, for example, 24 kB (24,576 bytes) on Ethereum is limited by the deployment size limit. Each function adds instructions to the contract code, so the more functions there are, the closer the contract gets to this limit.

[0088] - the functions consume gas during their execution. A contract with Using numerous complex functions can become expensive. Function call management can also become inefficient if the contract is overloaded.

[0089] - the function call via the SELECTOR function selector also defines There is a limit. A smart contract can have up to 4,294,967,296 (2³²) different selectors, because a selector is based on a 4-byte truncated Keccak-256 hash. Each selector corresponds to a possible call, but this requires the contract to have the associated functions.

[0090] In summary, a smart contract can contain a large number of functions, limited primarily by the size of the code. The clear signing method according to the present invention therefore offers an advantageous solution for implementing "clear signing" in the context of such a diverse range of functions and transactions that the hardware wallet may be required to sign.

[0091] Another advantage of the method is a very low occupation of the memory space of the hardware wallet, which does not need to keep the DES transaction data descriptors in memory after using them to extract and format the transaction data to be presented to the user.

[0092] This will be better understood by referring to [Fig.3], which shows an example of implementation of the clear signature process according to the present invention.

[0093] At an SI step, the HDV host device generates or receives a transaction that it must have signed by the hardware wallet, and generates the raw RTRAN form of this transaction. Based on the information contained in this transaction, which allows it to identify the transaction, the host device will search a BCKMEM storage medium shown in [Fig. 1], for example a backend server, for the corresponding TDES transaction descriptor. In this example, it is assumed that the TDES descriptor does not includes three transaction data descriptors DES1, DES2, DES3 after the TINFO information block.

[0094] At an S10 step, the HDV host device provides the raw RTRAN transaction to the secure SPROC processor of the hardware wallet HW.

[0095] At an SI step 1, the secure processor stores the raw RTRAN transaction in volatile memory MEM2.

[0096] At an S20 step, the host device provides the TINFO block to the secure processor.

[0097] At an S21 step, the secure processor verifies the SIGN signature present in the TINFO block, using the PUBK public key it possesses, and interrupts the processing of the transaction if the verification is not conclusive.

[0098] At step S22, the secure processor verifies certain information data present in the TINFO block, by referring to the raw received transaction. It thus ensures that the received transaction is consistent, for example, with the CONTRACT_ADDR, SELECTOR, and CHAIN_ID data, and interrupts transaction processing if the verification is inconclusive.

[0099] At step S23, the secure processor stores in MEM2 memory certain information from the TINFO block, considered together to form useful UTINFO information that is to be displayed to the user. This information is predefined in the API application program executed by the secure processor. Examples include CHAIN_ID, OPERATION_TYPE, and CREATOR_NAME information.

[0100] At an S24 step, the secure processor stores in MEM2 memory the INSHASH hash present in the TINFO block.

[0101] At an S25 step, the secure processor initializes a calculation function for an internal INTHASH hash.

[0102] At an S30 step, the secure processor receives the DES1 descriptor.

[0103] At step S31, the secure processor executes the displacement commands and NCMD termination, TCMD present in the BPATH1 binary path descriptor of the DES1 transaction data descriptor, to find the location of a TDATA1 transaction data item in the raw transaction (more precisely in the structured binary data block that the raw transaction contains), and then extract it from that location.

[0104] At an S32 step, the secure processor uses the FORM1 formatting data to transform the TDATA1 transaction data into FTDATA1 formatted transaction data.

[0105] At an S33 step, the secure processor stores the formatted transaction data FTDATA1 in MEM2 memory.

[0106] At an S34 step, the secure processor updates the internal INTHASH hash from the data present in the DES1 descriptor.

[0107] At an S40 step, the secure processor receives the DES2 descriptor.

[0108] At step S41, the secure processor executes the displacement commands and NCMD termination, TCMD present in the BPATH2 binary path descriptor of the DES2 transaction data descriptor, to find the location of a TDATA2 transaction data item in the raw transaction, and then extract it from that location.

[0109] At an S42 step, the secure processor uses the F0RM2 formatting data to transform the TDATA2 transaction data into FTDATA2 formatted transaction data.

[0110] At an S43 step, the secure processor stores the FTDATA2 formatted transaction data in MEM2 memory.

[0111] At step S44, the secure processor updates the internal INTHASH hash from the data present in the DES2 descriptor

[0112] At an S50 step, the secure processor receives the DES3 descriptor.

[0113] At step S51, the secure processor executes the move commands and NCMD termination, TCMD present in the BPATH3 binary path descriptor of the DES3 transaction data descriptor, to find the location of a TDATA3 transaction data item in the raw transaction, and then extract it from that location.

[0114] At an S52 step, the secure processor uses the F0RM3 formatting data to transform the TDATA3 transaction data into FTDATA3 formatted transaction data.

[0115] At an S53 step, the secure processor stores the FTDATA3 formatted transaction data in MEM2 memory.

[0116] At step S54, the secure processor updates the internal INTHASH hash from the data present in the DES3 descriptor

[0117] In one embodiment, the secure processor temporarily stores the DES1 descriptor in MEM2 memory during the extraction of the TDATA1 transaction data, but does not retain it afterward. It therefore erases it from MEM2 memory after extracting the TDATA1 transaction data. The secure processor does the same with the DES2 and DES3 descriptors. Thus, the process does not require any permanent use of volatile memory.

[0118] After the last update of the internal hash INTHASH, the secure processor verifies that the internal hash INTHASH is equal to the external hash INSHASH that was present in the TINFO block and has been stored. If the verification is unsuccessful, the secure processor interrupts the transaction processing.

[0119] The iterative calculation of the internal INTHASH hash at steps S34, S44, and S54 can be carried out in various ways known to those skilled in the art. The internal INTHASH hash must be calculated in the same way as the external INSHASH hash. For example, a sequential hash is updated using the SHA256 function as new data arrives, starting from a base value that may or may not be zero.Various other methods can be used, for example by XOR accumulation hashing where successive data are combined via an XOR operation before applying the hash function to the cumulative result; by Rolling Hash using an algorithm to update the hash by adding and removing elements; by Merkle tree, by hashing the data in pairs and then hashing the pairs hierarchically to produce a cumulative hash at the top of the tree; by arithmetic cumulative hashing in which the numeric values ​​of successive hashes are combined before hashing the total result; by block hashing; by global hashing of a list of all individual hashes, etc.

[0120] If the comparison of the two hashes is conclusive, during an S70 step, the secure processor displays on the DISP1 screen the useful information UTINFO which was stored in the S23 step as well as the transaction data FTDATA1, FTDATA2, FTDATA3 which was also stored in the S33, S43, S53 steps.

[0121] Thus, thanks to this information and after verifying it, the USR user can, during an S80 step, give his informed consent to the signing of the transaction by pressing the VB validation button.

[0122] Upon detection of this express validation, the secure processor generates the STRAN signature of the transaction at step S81 and sends it to the HDV host device at step S82. The host device can then place the transaction on the relevant blockchain.

[0123] Figure 4 describes the design and registration steps of a TDES transaction descriptor:

[0124] At step S100 of the TDES transaction descriptor creation, a programmer PROG ([Fig. 1]), which may be a person or a machine, defines the TINFO block and the DES transaction data descriptors relating to the TDATA transaction data to be displayed to the user. The NCMD move and TCMD terminate commands of the BPATH binary path descriptor are expressed in a high-level language and stored on a key / value type medium, for example, a JSON file. An example of a high-level language, which will be described later to designate these low-level commands, includes, for example, terms such as TUPLE, REF and ARRAY, STATIC_LEAF, DYNAMIC_LEAF, and SLICE.

[0125] At step S110, a CONV converter program ([Fig. 1]) is used to convert the TDES transaction descriptor into a binary format, for example, the TLV (Tag-Length-Value) format. This conversion is performed while preserving the uniqueness of the move and terminate commands, which remain individualized and are simply expressed in binary according to a specific encoding known to the PARS function, instead of being expressed as words such as TUPLE, REF and ARRAY, STATIC_LEAF, DYNAMIC_LEAF and SLICE.

[0126] At an S120 step of securing the TDES transaction descriptor, the transaction descriptor in binary form is provided to the hardware security module HSM1, which calculates the INSHASH hash and the SIGN signature and inserts them into the TINFO block. As mentioned above, if the SIGN signature is generated taking into account the INSHASH hash, the latter is inserted into the TINFO field before the SIGN signature is generated and inserted into the TINFO field.

[0127] At an S130 step of recording the TDES transaction descriptor, the secure descriptor is recorded in the BCKMEM storage medium.

[0128] Thus, as described above, when the HDV host device receives and identifies a transaction to be signed at an S140 step, the host device searches for and finds in the BCKMEM storage medium the TDES transaction descriptor corresponding to an S150 step.

[0129] At step S150, the host device provides the hardware wallet (HW) with the raw RTRAN transaction encapsulated in APDUs. Then, at step S160, the host device provides the hardware wallet with the TDES transaction descriptor in binary form, encapsulated in APDUs.

[0130] Figure 5 shows a real-world example of a raw RTRAN transaction expressed in hexadecimal characters, in this case an Ethereum transaction. The transaction comprises a first sequence of characters forming the transaction envelope (underlined portion in the figure) followed by the CALLDATA block. The latter is shown in Figure 6 without the envelope.

[0131] The envelope contains the general information necessary to process the transaction and precedes the CALLDATA block. It does not contain any specific instructions for the smart contract.

[0132] The CALLDATA block is the section of the transaction that contains the instructions and parameters for the smart contract, and which will be parsed using the plaintext signature method according to the present invention, in order to present the user with certain transaction data it contains. The first four bytes of the CALLDATA block form the function selector SELECTOR. This selector identifies the specific smart contract function to be called.

[0133] The envelope contains information that the secure processor can analyze without needing the method according to the present invention. This information includes, for example, the following:

[0134] - Transaction version: 02. Meaning: This is an EIP-1559 transaction (type 2), which introduces improved fee mechanisms with the differentiation between the "Base Fee" and the "Priority Fees".

[0135] - Total transaction size: f90150. Meaning: this size is encoded in RLP (Recursive Length Prefix). This information indicates the length of the complete envelope.

[0136] - Chain ID: 01. Meaning: here, the value 1 represents the Ethereum blockchain mainnet.

[0137] - Nonce: 81eb. Meaning: the value is Oxeb (i.e., 235 in decimal). This indicates The transaction number sent by the sender (the address sending this transaction). "81" indicates that the following data is a byte, "eb" is the value of the nonce, which is 235 in decimal.

[0138] - MaxFeePerGas: 8502540be400. Meaning: "85" is the RLP prefix which indicates The following data is 5 bytes long. "02540be400" is the actual 5-byte value (in hexadecimal). After removing the prefix 85, we get 0x2540be400, which is the actual value of MaxFeePerGas. The hexadecimal value 0x2540be400 corresponds to 10 Gwei (in wei). This is the maximum amount the issuer is willing to pay per unit of gas. Note that "Ox" is a standard prefix used to indicate that a number is expressed in base 16 (hexadecimal).

[0139] - MaxPriorityFeePerGas: 85174876e800. Meaning: "85" is the RLP prefix indicating that the following data is 5 bytes long. "174876e800" is the actual 5-byte value (in hexadecimal). The value 0xl74876e800 corresponds to 1 Gwei. This represents the priority fee offered to miners for including the transaction quickly.

[0140] - Gas Limit: 82abel. Meaning: the hexadecimal value Oxabel corresponds 44,001 units of gas. This is the limit of gas consumption allowed for this transaction.

[0141] - To (Destination): 940bb4d3e88243f4a057db77341e6916b0e449bl58. Meaning: the recipient's address is 0x0bb4d3e88243f4a057db77341e69 16b0e449bl58. Here, it is a smart contract address.

[0142] - Value: 80. Meaning: amount of Ether sent. The value 0x80 corresponds to 0 Ether (no direct fund transfer).

[0143] - Calldata Length: b90124. Meaning: the value 0x124 indicates that the data The CALLDATA files have a length of 292 bytes.

[0144] The following section, corresponding to the CALLDATA block, is shown in [Fig. 6]. The first part of the CALLDATA block is the function selector "af68b302", expressed in hexadecimal. This selector, which systematically occupies the first 4 bytes (i.e., 8 hexadecimal characters), is separated from the rest of the block in [Fig. 6] to illustrate that the structuring of the block into 32-byte segments, conforming to the ABI standard, begins after this selector. Each 32-byte block represents a value or a pointer, respecting the alignment defined by the ABI.

[0145] This constant in the selector size allows the secure processor to consistently identify the selector. The secure processor therefore does not need the transaction descriptor to perform this partitioning. It simply applies a segmentation rule after the first 4 bytes: "identify the first 4 bytes as the function selector and divide the remainder into fixed 32-byte blocks".

[0146] Figure 7 shows the TINFO information block present in a comprehensible form. in the TDES descriptor of this transaction, which is in practice communicated to the secure processor in binary form. The structure of this field and its content were determined at the TDES transaction descriptor creation stage in step S100 described above. In contrast, the INSHASH hash and the SIGN signature were generated in step S120 by the HSM1 hardware security module.

[0147] The TINFO block includes a TINFO1 section containing the information CONTRACT_ADDR, SELECTOR, and CHAIN_ID, which, as seen above, are preferably verified by the secure processor. To this end, the secure processor compares the CONTRACT_ADDR and CHAIN_ID information with that found in the transaction envelope (see the description in [Fig. 5] above). Furthermore, it compares the value of the function selector SELECTOR with that found at the beginning of the CALLDATA block, as seen above.

[0148] The TINFO block also includes a TINFO2 section which includes, for example, the following information:

[0149] - OPERATION_TYPE: type of operation performed by the transaction (for example, "Mint", "Swap").

[0150] - CREATOR_NAME: name of the creator of the smart contract or application associate.

[0151] - CREATOR_LEGAL_NAME: legal name of the entity or company that created the CONTRACT.

[0152] - CREATOR_URL: URL providing information about the creator or the contract clever.

[0153] - DEPLOY_DATE: date on which the smart contract was deployed on the blockchain.

[0154] These fields are not included in the raw transaction. They are additional metadata obtained by the PROG designer who generated the transaction descriptor. As seen above, the TINFO information displayed by the Secure processors can include information from section TINFO1 and information from section TINFO2. In some embodiments, only information from section TINFO1 or section TINFO2 is displayed.

[0155] Figure 8 shows an example of NCMD displacement commands and TCMD termination. These commands are designated by an arbitrarily chosen term which here has a mnemonic connotation, which will form the high-level command used in step S100 of the creation of the TDES transaction descriptor to form the BPATH binary path descriptor.

[0156] Three NCMD displacement commands are distinguished:

[0157] - TUPLE(int offset)

[0158] - REF

[0159] - ARRAY(int itemSize, option int start, option int end)

[0160] Three TCMD termination commands are also distinguished:

[0161] - STATIC_LEAF

[0162] - DYNAMIC_LEAF

[0163] - SLICE (option int start, option int end)

[0164] Some of these commands are accompanied by a variable mentioned in parentheses. The term "int" means that this variable is an integer. The term "option" means that this variable is optional and therefore may not be specified in the command, in which case the command is executed in a manner explained later.

[0165] We will now describe the actions involved in executing each of these commands, namely how each command is executed by the secure processor using the PARS function. The PARS function is configured to initiate movement at a starting point corresponding to the first segment of the structured binary data block. A "current location" variable Ec is initialized to a predetermined value, for example, Ec = 0. This variable is incremented by means of the movement commands until a target segment, or several target segments, are reached. If the initial value Ec is equal to 0, the position Ec of the first segment of the structured binary data block is equal to 1, the position of the second segment is equal to 2, and so on. The "current location" variable Ec then designates the location that is reached after each execution of a command.

[0166] Description of the execution of movement commands:

[0167] - TUPLE(int offset)

[0168] This command instructs the secure processor to move N segments from the current location Ec, with N = "offset", to reach a new current location Ec' = Ec + N. For example TUPLE(3) means "increment the current position by 3 segments", i.e. Ec = Ec + 3.

[0169] - REF

[0170] This command instructs the secure processor to read the value written to the binary data block at the current location and use that value as a displacement offset from the current location Ec, i.e., Ec' = Ec + offset, where offset = "value read at location Ec". The value read at the current location can refer to a number of locations or a number of bytes. In the context of rEthereum, it refers to a number of bytes that is a multiple of 32, i.e., a number of 32-byte segments.

[0171] - ARRAY(int itemSize, option int start, option int end)

[0172] This array navigation command specifies that each array element comprises a number of segments defined by the variable "itemSize". This command also optionally designates the "start" position of the first array element to be accessed and / or the "end" position of the last array element to be accessed. For example, "itemSize" = 2 means that each array element occupies two segments of the binary data block, "start" = 0 designates the first array element, and "end" = 3 designates the fourth array element. This command can access a single array element, namely the first segment of that element if the element occupies multiple segments, or multiple array elements, namely the first segments of several of those elements if they occupy multiple segments.In the context of rEthereum, this command is used when a current location is reached that contains an integer indicating the number of elements in the array. Also in the context of rEthereum, this current location is the one immediately preceding the first segment of the array.

[0173] The optional parameter "start" specifies an index in the array of the first element to be extracted, while the optional parameter "end" specifies an index in the array of at least one first element to be extracted. If the parameter "start" is not defined, the secure processor must extract elements from the array starting with the first element. If the parameter "end" is not defined, the secure processor must extract, starting with the first element defined as described above, all remaining elements of the array up to the last element. If both the parameters "start" and "end" are not defined, the secure processor selects all elements of the array.If the "start" and "end" parameters are equal, the secure processor selects only one element from the array whose first segment has index "start" and contains a number of segments equal to "itemSize". Finally, a "start" parameter. or a negative "end" indicates that the positions of the array elements should be calculated starting from the end of the array. If the length of the array is "{length}", the offset must therefore be replaced by {length-lstartl} or {length-lendl}.

[0174] As just stated, in the context of Ethereum the array begins after the current location segment Ec, the contents of which indicate the length of the array, which is therefore calculated from location Ec + 1. Since the first segment has an index of zero, the subsequent segments to be reached will therefore be at locations Ec' equal to Ec + 1 + offset, with "offset" equal to:

[0175] {start*itemSize},

[0176] {start*itemSize + itemSize],

[0177] {start*itemSize + 2*itemSize],

[0178] and so on until 1 + {start*itemSize + n*itemSize] equals "end".

[0179] Examples for an Ethereum CALLDATA:

[0180] Example 1. Consider the command ARRAY(itemSize = 1) which indicates that an array is located after the current location, that the size of each element in the array is equal to 1 segment, and that all elements of the array are to be extracted because the parameters "start" and "end" are undefined. If the current location is Ec, the safe processor reads the contents of the segment located at that location Ec. This value is the number of elements in the array. Assuming, for example, that this value is equal to 3, this means that the array comprises three elements of 1 segment each at locations Ec + 1, Ec + 2, and Ec + 3.These three locations can be binary path endpoints, but if the ARRAY command is followed by another move command, that other move command will apply from these three new locations, resulting in a "split" of the binary path into multiple binary paths to which all subsequent move commands, as well as the final termination command, will apply.

[0181] Example 2. The ARRAY(itemSize = 2) command applied to the location Ec in which the value 3 can be read, causes the secure processor to select the first segments of each element of the array at locations Ec + 1, Ec + 3, Ec + 5.

[0182] Example 3. Consider the command ARRAY(itemSize = 2, start = 1, end = 3). Here, the size "itemSize" of each element in the array is 2 segments, or a pair of segments. This command instructs the safe processor to move to elements 1 through 3 of the array. If the current location is Ec, the safe processor reads the contents of the segment at location Ec, which indicates the number of elements in the array. For the sake of example, this value will be assumed to be 5. The segments designated by the command therefore have respective offsets of 1 + {1*2], 1 + {1*2 + 2}, 1 + {1*2 + 2*2}, i.e. 3, 5, 7, i.e. Ec + 3, Ec + 5 and Ec + 7. The first element of the array with an index equal to 0 is not selected because it is not designated by the command, the parameter "start" being equal to 1. With a command ARRAY(itemSize = 2, start = 0, end = 3), the segments to be reached would be at locations Ec + 1, Ec + 3, Ec + 5 and Ec + 7.

[0183] If the transaction data to be extracted is located in the segment(s) reached by the ARRAY command, the ARRAY command can be followed by a STATIC_LEAF or SLICE termination command described later. If the transaction data to be extracted is located in a segment following the segment reached, or if the transaction data to be extracted is located in segments following each segment reached (as in the case of ItemSizol), the TUPLE(in offset) command can be used to reach these subsequent segments of the array elements targeted by the command. This command will then be followed by the STATIC_LEAF command described later to read the data present in this or these subsequent segments, which can itself be followed by the SLICE command to read only a portion of this or these segments.

[0184] From the foregoing, it follows that a binary path can be defined with a single command or a combination of the commands just presented. Furthermore, the ARRAY command can point to one or more segments. When the ARRAY command causes the secure processor to select multiple segments, which represents a kind of "splitting" of the binary path into several terminations, it remains possible to include in the definition of the binary path other move commands as shown above with an example. In this case, the subsequent move command(s) apply to all terminations of the binary path, as do the termination commands. Two successive ARRAY commands can also be used in the case of a binary path comprising nested arrays.

[0185] Description of the execution of termination commands:

[0186] STATIC_LEAF: This command means that the segment contains a static value. The secure processor extracts the entire contents of the segment.

[0187] DYNAMIC_LEAF: This command means that the segment contains a dynamically encoded value, for example, the length of the useful data in bytes followed by a data field of the specified length. The secure processor then reads this value and selects as many bytes as it contains, starting from the first byte following the value. The target data obtained with this command can therefore be longer than a segment. This command allows, for example, after the ARRAY command, the extraction of target data that extends over several segments of an element of an array or several segments of several elements of an array.

[0188] SLICE (int start option, int end option)

[0189] The SLICE termination command can be provided after the STATIC_LEAF or DYNAMIC_LEAF commands to allow the target data, whose nature (static or dynamic) is defined by these two preceding commands, to be split. It is followed by two optional parameters, "start" and "end". The first is an integer defining the position, within the target data (whose size can therefore be greater than one segment), of the first byte of the data to be extracted. The second is an integer defining the position, within the target data, of the last byte of the data to be extracted. This command thus instructs the secure processor to "split" the target data to select only bytes from a byte at position "start" to a byte at position "end". For example: "split the target data from the byte "start" to the byte "end".If either the "start" or "end" parameter is negative, it means that the positions of the bytes to be retained are determined starting from the end of the target data.

[0190] By way of example, Figures 9, 10 and 11 show respectively examples of transaction data descriptors DES1, DES2, DES3 corresponding to transaction data to be displayed in plain text to the user.

[0191] The following formatting data is distinguished in the DES1 descriptor:

[0192] name: "Token",

[0193] type: "RAW",

[0194] param: {

[0195] value: {

[0196] type_family: uint,

[0197] type_size: 32 bytes,

[0198] These commands mean, for the secure processor, that the transaction data to be extracted will be displayed to the user as "Token" type data. The other components of the formatting data specify to the secure processor how to process this raw data to make it readable. When the type is not "RAW", the secure processor formats the data with the information in the primitive type. There are various primitive types, for example, "string", "uint", "address", etc., these concepts being known to those skilled in the art.

[0199] The following binary path descriptor is also distinguished in the DES1 descriptor:

[0200] data_path: [

[0201] { type: TUPLE, offset: 1},

[0202] { type: STATIC_LEAF},

[0203] Together, these formatting, moving, and terminating commands mean here: "starting from element 0 of the CALLDATA block, skip 1 segment of 32 bytes, then read the value present in the segment. Display this value as an integer preceded by the label "Token

[0204] Similarly, the following formatting data can be distinguished in the DES2 descriptor:

[0205] name: "Beneficiary",

[0206] type: "TRUSTED_NAME",

[0207] param: {

[0208] value: {

[0209] type_family: address,

[0210] type_size: 20 bytes,

[0211] These elements mean, for the secure processor, that the transaction data to be extracted will be displayed to the user as "Beneficiary" type data. The other components of the formatting data tell the secure processor how to process this raw data to display it in an understandable form. The "TRUSTED_NAME" formatter chosen here is not in the Ethereum standard; the descriptor designer is free to design several types of formatters.

[0212] The following binary path descriptor is also distinguished in the DES2 descriptor:

[0213] data_path: [

[0214] { type: TUPLE, offset: 2},

[0215] { type: STATIC_LEAF},

[0216] Together these formatting, moving and terminating commands mean here: "starting from element 0 of the CALLDATA block, skip 2 segments of 32 bytes, then read the value present in the segment. Display this value as a name preceded by the label "Beneficiary".

[0217] Similarly, the following formatting data can be distinguished in the DES3 descriptor:

[0218] name: "Expiration thne",

[0219] type: "DATETIME",

[0220] param: {

[0221] value: {

[0222] type_family: uint,

[0223] type_size: 32 bytes,

[0224] The following binary path descriptor is also distinguished in the DES3 descriptor:

[0225] data_path: [

[0226] { type: TUPLE, offset: 3},

[0227] { type: STATIC_LEAF},

[0228] Together these formatting, moving and terminating commands mean here: "starting from element 0 of the CALLDATA block, skip 3 segments of 32 bytes, then read the value present in the segment. Display this value in date format and preceded by the label "Expiration Time".

[0229] Once all these operations are completed, the secure processor displays the following information on the DISP1 screen:

[0230] Action: Mint POAP

[0231] Token: 7163978

[0232] Beneficiary: speculos.eth (address 0xdad77910dbdfde764fc21fcd4e74d71 bbaca6d8d)

[0233] Expiry date: Thu Mar 03 2022 17:56:02 GMT + 0000

[0234] Displaying this information allows the user to verify the transaction details before approving the signature. This ensures a secure user experience, in line with the principles of "clear signing," which the present invention extends to complex transactions.

[0235] The commands just described constitute a simple and powerful tool for navigating a structured binary data block and are subject to various variations depending on the structure of the binary data block in question. The commands just described were initially designed to be applicable to an Ethereum transaction CALLDATA field but are suitable for various other applications. In particular, they are applicable to any similarly structured binary data block, regardless of the size of the segments. If the data block contains only a sequence of static data, only the TUPLE command will be necessary. If the binary data block contains static and indexed data, but no arrays, both the TUPLE and REF commands can be used.

[0236] Other move commands can be provided depending on the structuring rules of the binary data block to which the method of the invention is applied, and the components of this binary data block. Specific move and termination commands can be provided for specific components other than those just described. In the case of a CALLDATA type data structure, it is also possible to provide alternatives to the three move commands just described, in particular by providing a larger number of commands. The authors of the present invention thus initially provided a larger number of commands, which after various optimizations have been simplified by the prediction of the three basic commands just described, which are assumed to cover all possible scenarios. For example, other commands were initially planned, such as:

[0237] TUPLE_LEAF(int size), to indicate that the final location to select is the beginning of the encoding of an array whose number of elements is {size}. Example for an Ethereum CALLDATA: iterate from the current offset over {size} 32-byte values.

[0238] ARRAY_LEAF to indicate that the final location to select is the beginning of the encoding of an array with a dynamic number of elements. Example for an Ethereum CALLDATA: read the value of the current offset, then iterate from that offset over as many 32-byte values ​​as the value read.

[0239] In general, other movement or termination commands can be designed within the scope of the present invention. Furthermore, navigation within a transaction, as described above, can be initiated from the first transaction data item by using a command to jump from the envelope region, if one exists, to reach an area of ​​interest such as the binary data block mentioned above. Also, the step of formatting transaction data can, in certain embodiments, be reduced to associating a label with the extracted data, if the latter is directly presentable to a user.

[0240] It will thus be clear to those skilled in the art that the plaintext signature process for a transaction just described is susceptible to numerous variations, embodiments, and applications. The process is particularly applicable to any blockchain comprising binary data blocks structured into segments of a predetermined length, and especially those compatible with the Ethereum Virtual Machine (EVM). In some embodiments, a segment may represent only one byte, or even only one bit.In other embodiments, the method can be adapted to be applied to a transaction with segments of variable length, or even no segmentation, if the transaction is structured using components (static or indexed data, arrays or other type of component) and if such components allow, on the one hand, for providing movement commands to navigate through the transaction to targeted locations - possibly movements from one component to another without counting segments, whether segments are provided or not - and, on the other hand, for providing termination commands appropriate to the components used and allowing the extraction of transaction data to be displayed to a user.An advantageous characteristic specific to these various embodiments lies in the possibility of communicating to the secure processor, simultaneously with the communication of a raw transaction, transaction data descriptors including . Generic commands, such as those just described, allow the secure processor to extract transaction data from the received transaction. Displaying this data to a user is essential for transaction security related to obtaining the user's informed consent. Such real-time communication of data descriptors avoids overloading the secure processor's non-volatile memory with specialized, non-generic plugins.

Claims

1. Demands A method for signing a transaction in plain text using a crypto-asset hardware wallet (HW), the hardware wallet comprising a secure processor (SPROC) and a secure screen (DISP1) controlled by the secure processor, the method comprising the steps of: - provide (S10) the transaction to the secure processor in raw form (RTRAN) comprising a structured binary data block (CALLDATA) comprising segments of a defined length, - provide (S30) to the secure processor at least one transaction data descriptor (DES) relating to transaction data to be displayed in plain text to a user, the transaction data descriptor comprising: - at least one move command (NCMD, TUPLE, REF, ARRAY) in the structured binary data block, allowing the secure processor to reach at least one target segment from a starting segment, - at least one termination command (TCMD, STATIC_LEAF, DYNAMIC_LEAF, SLICE) indicating to the secure processor the location and extent of the transaction data in or from the target segment, and - Formatting data (FORM) for the transaction data, enabling the transaction data to be understood by a user, and - using the secure processor: - execute (S31) the move command (NCMD) to find the target segment, execute the terminate command (TCMD) to extract the transaction data from the structured binary data block, and format (S32) the transaction data with the formatting data (FORM), - display (S70) the formatted transaction data (FTDATA) on the secure screen, - receive (S 80) approval from a user, via an approval means (VB) controlled by the secure processor, and - generate (S81) a signature of the transaction using a private key (KO).

2. A method according to claim 1, comprising steps (S30, S40, S50) of successively providing the secure processor with a plurality of transaction data descriptors (DES1, DES2, DES3), and wherein the secure processor displays (S70) on the secure screen in formatted form (FTDATA1, FTDATA2, FTDATA3) each formatted transaction data targeted by a transaction data descriptor.

3. A method according to claim 2, wherein a subsequent transaction data descriptor (DES2) is provided to the secure processor only after the secure processor has stored the transaction data (FTDATA) extracted from the structured binary data block using a previous transaction data descriptor (DES1).

4. A method according to any one of claims 2 and 3, wherein the secure processor (SPROC) temporarily stores a transaction data descriptor (DES) in volatile memory (MEM2) and then erases it from volatile memory after using it to extract (S31) from the structured binary data block the transaction data targeted by the transaction data descriptor.

5. A method according to any one of claims 2 to 4, comprising a step (S24) of providing the secure processor with an overall hash (INSHASH) of the set of transaction data descriptors (DES) provided to it, and steps (S33, S43, S53) of iteratively calculating (S25, S34, S44) an internal hash (INTHASH) of the set of transaction data descriptors provided to it by means of the secure processor, and then verifying (S60) that the iterative internal hash is equal to the overall hash.

6. A method according to any one of claims 1 to 5, further comprising the steps of: - providing (S20) to the secure processor an information block (TINFO) including information (TINFO 1, TINFO2) about the transaction, - using the secure processor, verifying (S21) in the raw transaction the first information (TINFO 1) present in the information block, and - displaying on the secure screen information (UTINFO, TINFO 1, TINFO2) present in the information block, which may include all or part of the first information.

7. A method according to claim 6, wherein the information verified by the secure processor includes at least one of the following: a blockchain identifier (CHAIN_ID), a smart contract address (CONTRACT_ADDR), and a function selector (SELECTOR) in the smart contract.

8. A method according to claim 5 and according to any one of claims 6 and 7, wherein the overall hash (INSHASH) is included in the information block (TINFO).

9. A method according to claim 8, wherein the information block (TINFO) includes a signature (SIGN) of all the data it comprises including the global hash (INSHASH), the signature being generated by means of a private key of a certification authority (HSM1), and comprising a verification step (S21), by the secure processor, of the signature by means of a public key (PUBK) of the certification authority.

10. A method according to any one of claims 1 to 9, comprising: - a step (S 100) of developing a plurality of transaction data descriptors (DES) comprising move commands (NCMD) and terminate commands (TCMD) expressed in a high-level language, the transaction data descriptors (DES) being stored in a key / value structured file (JSON), - a step (SI 10) of converting the transaction data descriptors into binary, where each move command (NCMD) and terminate command (TCMD) is converted into a binary format, and - a step (S150, S170) of communicating the transaction data descriptors to the secure processor in their binary form.

11. A method according to claim 10, wherein the transaction data descriptors are communicated to the secure processor in their binary form encapsulated in APDUs conforming to ISO7816.

12. A method according to any one of claims 10 and 11, wherein the step (S 100) of developing a plurality of transaction data descriptors (DES) further comprises a step of calculating an overall hash (INSHASH) of the set of transaction data descriptors (DES).

13. A method according to any one of claims 1 to 12, wherein a move command (NCMD) in the structured binary data block is chosen from a group of move commands for which a location in the structured binary data block corresponds to the location of a segment, the group of move commands comprising: - a first command (TUPLE), for moving, from a current location, a predetermined number of segments specified ("offset") by the command, to reach a new location, - a second command (REF), for moving, from a current location, a number of segments determined by a number that is read at the current location, to reach a new location, and - a third command (ARRAY), for moving in an array composed of elements,the command specifying the number of segments ("itemSize") that each element of the array comprises and implicitly or explicitly designating ("start", "end") one or more elements of the array to be accessed in order to reach one or more new locations.

14. A method according to claim 13, wherein a transaction data descriptor (DES) comprises a binary path (BPATH) comprising a combination of at least two of said first, second and third move commands.

15. A method according to any one of claims 1 to 14, wherein a termination command (TCMD) is chosen from a group of termination commands comprising: - a first termination command (STATIC_LEAF) indicating that the segment reached contains the transaction data to be extracted, and - a second termination command (DYNAMIC_LEAF) indicating that the segment reached contains a number indicating the length of the transaction data to be extracted, the transaction data to be extracted immediately following this number.

16. A method according to claim 15, also comprising a third termination command (SLICE) that can be combined with the first or second termination command, indicating that transaction data identified by the first or second termination command should be sliced ​​to retain only bytes of the transaction data between a first and last byte specified in the command.

Images