Connection terminal comprising a secure clipboard memory controlled by a secure processor

Abstract

An electronic terminal (TL1) is provided, comprising an application processor (AP1), a secure processor (SP1), at least one display device (D3) and a selection device (TMD) enabling a user to select all or part of an image displayed on the display device by the application processor. The terminal is configured to perform, upon request from the user, a copy function (SCB1a) of data (ADD, IMADD) selected by the user from the image displayed by the application processor into a secure clipboard memory (CB2) accessible only by the secure processor.

Description

Technical Field

[0001] This invention relates to a connected electronic terminal comprising an application processor and a secure processor having cryptographic computing capabilities. The invention particularly relates to such electronic terminals, wherein the secure processor is configured as a cryptographic asset hardware wallet, and the application processor is configured as a host device for the cryptographic asset hardware wallet. Background Technology

[0002] In recent years, the development of cryptocurrencies or other types of blockchain-managed crypto assets, such as non-fungible tokens (“NFTs”) and smart contracts, has led to various ways of storing and safeguarding private keys belonging to these different types of crypto assets. This has resulted in the concepts of “wallets,” “cold storage,” and “hot storage” for private keys. A “wallet” is a device or program whose function is to store private keys belonging to a crypto asset account. So-called “hot wallets” are connected to the internet and are vulnerable to hacking or exposure to viruses and malware. These can be wallets managed by trading platforms, which do not provide the highest level of security. As a result, many trading platforms have been hacked and robbed of hundreds of millions of dollars over the years. “Hot” wallets can also take the form of programs installed on mobile phones, tablets, or personal computers (“software wallets”). Such wallets are permanently connected to the internet and integrate insecure applications, and are therefore vulnerable to attack themselves.

[0003] Cold wallets constitute the most secure solution for cold storage of private keys, avoiding direct internet access, which reduces the attack surface and thus lowers the risk of being stolen by hackers. Signing transactions involving private keys occurs in an offline environment. Any online-initiated transaction is temporarily transferred to an offline hardware wallet and then digitally signed there before being sent to the online network. Because the private key is not transmitted to the online server during the signing process, it is inaccessible to hackers.

[0004] The simplest form of cold storage is a passive storage device. A passive wallet can be a paper document or image file on which the user's public and private keys are written. Passive storage devices typically include an embedded QR code that can be scanned later to sign transactions. The disadvantage of this medium is that if the passive storage device is lost, unidentifiable, or damaged, the user can no longer access their funds.

[0005] Hardware wallets are a practical replacement for passive wallets used to store private keys. Furthermore, they are typically configured to generate recovery phrases, allowing the recovery of private keys in the event of their loss.

[0006] like Figure 1As shown, the hardware wallet HW is never directly connected to the internet. To be usable, the hardware wallet HW must connect to the host device HDV via a data link LNK (e.g., USB or Bluetooth). The host device HDV can be a computer, mobile phone, or tablet, and runs so-called "complementary" software for conducting transactions on the blockchain BCN, such as the "Ledger Live" software developed by the applicant. Alternatively, the hardware wallet HW can be used via the host device HDV using a decentralized exchange (DEX), where users can conduct transactions while keeping their keys in the hardware wallet.

[0007] The host device HDV has a screen D1 that allows users to prepare transactions, and the hardware wallet HW itself has a screen or display D2 that is specifically used to present information to the user related to the transactions that will be signed and therefore should be verified.

[0008] Figure 2 It shows that the applicant used Nano S ® The architecture of the hardware wallet HW, marketed under the name of [the company name], is described in more detail in the document https: / / developers.ledger.com / docs / nano-app / bolos-hardware-architecture. The hardware wallet HW includes a secure element (SE) associated with a microcontroller (MCU). The secure element is a hardware platform comprising a cryptographic computing device (CRY), typically a cryptographic coprocessor, capable of storing and processing data according to security rules and requirements set by a trusted management authority. The secure element takes the form of a semiconductor chip that implements various countermeasures designed to combat attacks by fraudsters. The secure element SE has a secure operating system (OS) (firmware) designed to allow the installation and execution of applications (APPs), such as BOLOS developed by the applicant. ® Operating system. The microcontroller MCU includes a USB interface U1, which enables the secure element to communicate with an external host device HDV running the accompanying software (see...). Figure 1 The hardware wallet HW also includes a display D2 and two buttons B1 and B2 managed by a microcontroller MCU for securing certain operations through user actions on these buttons. Other hardware wallet models sold by the applicant (such as Stax) ® This includes large touchscreens instead of simple displays.

[0009] Therefore, the hardware wallets mentioned above are portable, separate devices that do not connect to the internet. To conduct transactions, they require a temporary connection to a "connected" host device, such as a mobile terminal or smartphone. This separate nature of hardware wallets provides a high level of security because they are not accessible via public networks most of the time and are therefore less vulnerable to attack. However, this characteristic makes these hardware wallets ergonomically inconvenient and prone to being misplaced or forgotten.

[0010] Therefore, it is necessary to integrate hardware wallets into mobile terminal platforms (e.g., mobile phones) to transform them into mobile terminals with embedded hardware wallets. Such connected electronic terminals will include, on the one hand, a secure processor configured to implement hardware wallet functionality, arranged in the same housing, and on the other hand, an application processor that includes an internet-connected device capable of executing complementary applications (e.g., Ledger Live) designed to implement transactions on the blockchain.

[0011] Simultaneously, solutions are needed to protect users from the consequences of attacks on insecure processors, which have allowed fraudsters to control accompanying software. Once compromised, the accompanying software could potentially forge transactions without the user's knowledge.

[0012] Crypto asset transactions do indeed have the following specific characteristics: users are required to provide the accompanying application CAP with the address of the destination account they wish to use for the transaction. However, this address is typically long and complex. It is generated from elliptic curve cryptography algorithms and hash functions, and consists of a set of alternating letters and numbers, for example:

[0013] 0x388c818ca8b9251b393131c08a736a67ccbl9297

[0014] Therefore, users rarely risk manually entering such addresses, which carries the risk of error. Instead, users retrieve the address from the messaging application using the host device's clipboard and then paste it into the companion application. The messaging application can be a website (internet browser), a messaging application (the address received in a message), email, a Web3 application, a game, etc.

[0015] This transfer of information from the source application to the companion application via the application processor's clipboard constitutes a potential security vulnerability in transactions, which will be referenced. Figure 3 and Figure 4 To understand better.

[0016] Figure 3A typical configuration for implementing crypto asset transactions is illustrated. The hardware wallet HW (e.g., NANO S) mentioned above connects to the host device HDV (e.g., a mobile phone) mentioned above via a link LNK (e.g., Bluetooth). The secure element SE of the hardware wallet HW executes the hardware wallet application WAP, which is configured to sign transactions when the host device HDV requests them. The host device HDV includes an application processor AP, such as the baseband processor of a mobile phone, which runs a companion application CAP, such as the Ledger Live application.

[0017] Figure 4 The steps for preparing a transaction until its execution are described. In step S00, the user consults an information source application (ISAP), such as an email in a messaging application. Figure 5A In step S05, as illustrated, the user selects an address ADD for a crypto asset account in the application ISAP and activates the functionality to copy the address ADD to the clipboard. In step S10, the application processor AP then stores the selected address ADD in the clipboard memory. In step S15, the user switches to the companion application CAP and initiates the steps for creating a transaction. Figure 5B In the illustrated step S20, the application CAP prompts the user to indicate the address ADD of the beneficiary account for the transaction in the transaction descriptor. To do this, the user activates the clipboard paste function of the application processor AP to paste the address ADD into the transaction descriptor displayed by the accompanying application CAP, such as... Figure 5C As illustrated. In step S25, the user completes the transaction descriptor in the accompanying application CAP and requests the execution of the transaction. For example, in addition to the address ADD, the transaction descriptor also includes the type of cryptographic asset (“currency”) and the transaction amount (“amount”). In step S30, the application processor transmits the transaction descriptor including the address ADD to the secure element SE and requests it to be signed. In step S35, the secure processor SE running the hardware wallet application WAP displays the address ADD it has received from the application processor on display D2 and requests the user to confirm the transaction. In step S40, the user returns to the information source application ISAP to display the address ADD on screen D1. Figure 5D In the illustrated step S45, the user verifies that the address ADD displayed on screen D1 by the application ISAP and the address ADD displayed on display D2 by the security processor are the same, and confirms the transaction, for example, using the two buttons B1 and B2 of the hardware wallet HW. Figure 2In step S50, the security processor SE signs the transaction using the user's private key and sends the cryptographic signature to the processor AP. Typically, the signature covers the complete transaction descriptor, which includes at least the target account's address (ADD), the type of cryptographic asset, and the transaction amount. In step S55, the application processor AP places the signed transaction (i.e., the transaction accompanied by its signature) on the relevant blockchain. If the user does not confirm the transaction within a defined time after step S40, or if the user decides to abandon the transaction, the security processor SE may also refuse to sign the transaction in step S60.

[0018] In such methods used to generate and sign transactions, if the accompanying application has been compromised by malware, an attack is foreseeable the moment the user pastes the address into the accompanying application (step S20). Figure 5B If the companion application has been corrupted by malware, the copied address may not be the address the user initially retrieved from the information source application ISAP and stored in the clipboard memory. Due to the complexity of the address, the user may not notice that the address copied to the companion application has been changed. Subsequently, the companion application will provide a spoofed address to the security element SE. Then, in Figure 5D During the illustrated comparison step S45, the malware can display an address identical to the corrupted address in the application ISAP in order to guide the user to discover that the two addresses are the same and to confirm the transaction.

[0019] Therefore, particularly in the context of integrating crypto asset hardware wallets into connected terminals, it may be desirable to provide a device that offers an additional level of security in the preparation and execution of transactions. Summary of the Invention

[0020] The implementation scheme relates to an electronic terminal, comprising, within the same housing: an application processor; means for connecting the application processor to a public or private network; a security processor including encrypted computing means; a data link between the application processor and the security processor; at least one display device enabling the application processor and the security processor to display images; and a selection device enabling a user to select all or part of an image displayed by the application processor on the display device. The terminal is configured to, upon a request from the user, perform a copy function to copy data selected by the user from the image displayed by the application processor to a secure clipboard memory accessible only to the security processor.

[0021] According to one embodiment, the display device includes at least one secure display area controlled by a secure processor, and the secure processor is configured to display data copied to a secure clipboard memory on the secure display area.

[0022] According to one implementation, the terminal is configured to, when performing a copy function to copy to a secure clipboard memory: use the application processor to read text-type data selected by the user from an image displayed by the application processor in the application processor's system memory and transfer the text-type data to the secure processor; and use the secure processor to store the text-type data in the secure clipboard memory.

[0023] According to one implementation, the application processor is configured to send a request to a security processor for an cryptographic signature of data provided by the application processor, and the security processor is configured to, in response to the request for a cryptographic signature, determine whether the data existing in the secure clipboard memory is the same as the data provided by the application processor; and if the data existing in the secure clipboard memory is not the same as the data provided by the application processor, refuse to provide the cryptographic signature.

[0024] According to one implementation, the application processor is configured to, when performing a copy function to copy to secure clipboard memory: use the application processor to read an image portion selected by the user from an image displayed by the application processor in the application processor's image memory, and transfer the image portion selected by the user to the secure processor; and use the secure processor to store the image portion in secure clipboard memory.

[0025] According to one implementation, the application processor is configured to send a request to the security processor for a cryptographic signature of data provided by the application processor, and the security processor is configured to, in response to the request for a cryptographic signature, present the data residing in a secure clipboard memory on a display device; and wait for authorization from the user before providing the cryptographic signature.

[0026] According to one implementation, the terminal is configured to simultaneously display: data provided by an application processor on a first area of ​​the display device; and data provided by a security processor on a second area of ​​the display device.

[0027] According to one embodiment, the terminal includes: a first display driver connected to an application processor to provide first image data; a second display driver connected to a security processor to provide second image data; and a display selection circuit controlled by the security processor, the display selection circuit including a first input connected to an output of the first display driver, a second input connected to an output of the second display driver, and an output connected to a display device, the security processor being configured to control the display selection circuit to display data provided by the application processor via the first display driver on a first area of ​​the display device, and data provided by the security processor via the second display driver on a second area of ​​the display device.

[0028] According to one embodiment, the terminal includes an auxiliary processor that is configured with a display driver connected to a display device. The auxiliary processor is connected to an application processor and a security processor and is controlled by the security processor to display data provided by the application processor on a first area of ​​the display device and data provided by the security processor on a second area of ​​the display device.

[0029] According to one embodiment, the selected device includes a touch module connected to an application processor and a security processor via a touch data routing circuit, the routing circuit being configured to send touch data to the application processor or the security processor depending on a command issued by the security processor.

[0030] According to one implementation, the security processor is a security element in the form of an integrated circuit.

[0031] According to one implementation, a security processor is a trusted execution environment for an application processor.

[0032] According to one implementation, the security processor is configured to execute a crypto asset hardware wallet application, and the application processor is configured to execute a companion application designed to work in conjunction with the crypto asset hardware wallet application.

[0033] According to one implementation, the application processor executing the companion application is configured to send a request to the security processor for a cryptographic signature of a transaction descriptor including a cryptographic asset account address; and the security processor executing the hardware wallet application is configured to verify, before providing the cryptographic signature, that the cryptographic asset account address appearing in the descriptor is the same as the cryptographic asset account address existing in the secure clipboard memory.

[0034] The implementation also relates to a method for conducting cryptocurrency-related transactions using a terminal of the type described above, the method comprising the following steps: configuring a security processor to execute a cryptocurrency hardware wallet application; providing a companion application and a source application designed to work in conjunction with the cryptocurrency hardware wallet application in the application processor's program memory; using the application processor executing the source application to display an image including a cryptocurrency account address on a display device; copying the cryptocurrency account address to the security processor's secure clipboard memory; and using the application processor executing the companion application to send a transaction descriptor to the security processor and request the security processor to provide a cryptographic signature of the transaction.

[0035] According to one implementation, the method includes the following steps: displaying the address of an encrypted asset account copied to a secure clipboard memory on a secure display area of ​​a display device controlled by a secure processor.

[0036] According to one implementation, the method includes the following steps: using a security processor that executes a crypto asset hardware wallet application, verifying that the crypto asset account address in the transaction descriptor provided by the accompanying application is the same as the crypto asset account address in the secure clipboard memory, and if the two addresses are different, no cryptographic signature is provided.

[0037] According to one implementation, the method includes the following steps: using a secure processor that executes a crypto asset hardware wallet application, displaying an image portion stored in the secure clipboard memory of the secure processor, and waiting for authorization from the user before providing a cryptographic signature. Attached Figure Description

[0038] The embodiments will now be described by way of non-limiting examples in connection with the accompanying drawings, in which:

[0039] Figure 1 This demonstrates a typical example of using a hardware wallet via a host device.

[0040] Figure 2 This illustrates a typical hardware wallet architecture.

[0041] Figure 3 This illustrates the association between the hardware wallet and the host device used to conduct crypto asset transactions.

[0042] Figure 4 Describes the use of Figure 3 The standard steps for preparing and executing transactions using hardware wallets and host devices.

[0043] Figure 5A , Figure 5B , Figure 5C and Figure 5D Described Figure 4 The steps of the method

[0044] Figure 6 The first embodiment of a terminal implementing the secure clipboard function according to the first embodiment and the second embodiment is shown.

[0045] Figure 7 It shows that it exists Figure 6 Screen sharing between the application processor and the security processor in the terminal.

[0046] Figure 8 Described for use via Figure 6 The method for preparing and executing crypto asset transactions using a terminal and a first implementation using a secure clipboard function.

[0047] Figure 9 Described for use via Figure 6 A second implementation method for preparing and executing crypto asset transactions using a terminal and a secure clipboard function.

[0048] Figure 10A , Figure 10B , Figure 10C , Figure 10D and Figure 10E Examples Figure 8 , Figure 9 , Figure 12 , Figure 13 , Figure 15 , Figure 16 At least one of the steps,

[0049] Figure 11 A second embodiment of a terminal implementing the secure clipboard function, based on the third and fourth embodiments, is shown.

[0050] Figure 12 Described for use via Figure 11 A third implementation method for preparing and executing crypto asset transactions using a terminal and a secure clipboard function.

[0051] Figure 13 Described for use via Figure 11 The fourth implementation method uses a terminal and a secure clipboard function to prepare and execute crypto asset transactions.

[0052] Figure 14 A third embodiment of a terminal implementing the secure clipboard function, based on the fifth and sixth embodiments, is shown.

[0053] Figure 15 Described for use via Figure 14The fifth implementation method uses a terminal and a secure clipboard function to prepare and execute crypto asset transactions.

[0054] Figure 16 Described for use via Figure 14 The sixth implementation method uses a terminal and a secure clipboard function to prepare and execute crypto asset transactions.

[0055] Figure 17 Another embodiment of a terminal implementing the secure clipboard function according to any of the foregoing embodiments is shown.

[0056] Figure 18 Another embodiment of a terminal implementing the secure clipboard function according to any of the foregoing embodiments is shown.

[0057] Figure 19 Another embodiment of a terminal implementing the secure clipboard function according to any of the foregoing embodiments is shown, and

[0058] Figure 20 Another embodiment of a terminal implementing the secure clipboard function according to any of the foregoing embodiments is shown. Detailed Implementation

[0059] As noted above, one object of this disclosure is to integrate crypto-asset hardware wallets into mobile electronic terminals such as smartphones, tablets, or other types of connected mobile devices. To this end, a terminal architecture is provided that includes at least one application processor to which a security processor is added. The security processor is configured to act as a crypto-asset hardware wallet, and the application processor is configured to act as a host device relative to the security processor. This reconstructs the functional separation between the hardware wallet and the host device within the terminal, providing the highest level of security because it ensures that the security processor is not connected to the internet during cryptographic computation, with only the host device exposed to attacks. This protects the private keys of the crypto-asset accounts held by the security processor from attacks.

[0060] A secure processor can be a standalone secure element on a semiconductor chip or a Trusted Execution Environment (TEE) for an application processor, as will be seen with the help of examples below. In such an architecture, each processor can have its own display, or conversely, two processors can share the same screen. Similarly, regarding user selection of information on the screen or input of text, each processor can have its own selection and input device, such as a hardware keyboard associated with a touchpad, or a touchscreen that implements both selection and text input functions. In an implementation that reduces manufacturing costs and simplifies the ergonomics of the terminal, two processors share the same input device.

[0061] Another objective of this disclosure is to limit the risk of attacks of the types described above at the moment data in the clipboard is transmitted to the companion application. To this end, the idea of ​​this disclosure is to enable a user to copy information displayed by an insecure application to a secure storage location accessible only to a secure processor at any time. For convenience, such storage will be referred to hereinafter as "secure clipboard storage" or more simply as "secure clipboard" because it is inaccessible to the application processor and therefore inaccessible to attackers. In the context of a transaction, the address of the target account displayed in the source application can then be copied to the secure clipboard. If the companion application has been compromised by malware and the account address transmitted to it has been altered, the true version of that address will be preserved in the secure clipboard, having been "captured" or "shot" at a time when the malware controlling the companion application is inactive, since the copy was made before the companion software was requested. Furthermore, this copy is made at a random moment that cannot be predicted by an attacker, who will remain vigilant at the moment the user copies the account address to the companion application in order to replace the address with that of a fake account.

[0062] This secure version of the address can then be used to verify that the address sent by the companion application to the security processor to request its signing of the transaction is correct. This verification involves comparing the address in the secure clipboard with the address presented by the companion application. This comparison can be visual, performed by the security processor, or both, as will be seen below.

[0063] The following describes three main implementation schemes, SCB1, SCB2, and SCB3, for implementing a secure clipboard in a device including an application processor and a security processor. The security processor includes cryptographic computing devices and provides a higher level of security against physical or logical attacks than that offered by the application processor. Each implementation scheme of the secure clipboard can have two variations. Although described separately below, these implementation schemes and their variations are not mutually exclusive and can be implemented together in the same mobile terminal. They are distinguished only by the manner in which data is placed in the secure clipboard memory:

[0064] 1) In implementation SCB1 of this method, the security processor stores data selected by the user from an image displayed by the application processor and provided to the security processor by the application processor in a secure clipboard. In a first variant, this data is text-type data, such as the address ADD of a crypto asset account. In a second variant, this data is an image portion, such as the image portion IMADD showing the address ADD of a crypto asset account.

[0065] 2) In implementation SCB2 of this method, the security processor receives a complete image that is being displayed by the application processor. This image is then displayed by the security processor, and the user selects data from it that they wish to place in the security clipboard. In a first variant, this data is text-type data, such as the address ADD of a crypto asset account. In a second variant, this data is an image portion, such as the image portion IMADD showing the address ADD of a crypto asset account.

[0066] 3) In implementation SCB3 of this method, the security processor stores a complete image, generated by itself rather than provided by the application processor, in a secure clipboard by "spying" on the image currently being displayed by the application processor. This image is then displayed by the security processor, and the user selects data from it that they wish to place in the secure clipboard. In a first variant, this data is text-type data, such as the address ADD of a crypto asset account. In a second variant, this data is an image portion, such as the image portion IMADD showing the address ADD of a crypto asset account.

[0067] [Table] Comparison of different versions of the secure clipboard

[0068]

[0069] Various combinations of the variants mentioned above can be provided, and not all of these combinations will be described below. For example, by applying OCR (Optical Character Recognition) functionality to the image portion, the variant with an image option can be transformed into a variant with a text option to extract text-type data, as will be seen below. This "text option" variant, derived from the "image option" variant by applying OCR functionality, will be described below with respect to the second and third embodiments, but the same applies to the first embodiment.

[0070] Figure 6 A first embodiment of a mobile terminal TL1 configured to implement a secure clipboard SCB1 is shown. The terminal includes an application processor AP1, a secure processor SP1, and a touchscreen arranged in the same housing (not shown). The touchscreen includes a superposition of a screen D3 (e.g., LED or OLED) and a touch panel TMD. The application processor AP1 includes port IO1 connected to port IO10 of the secure processor SP1 via a data bus DB1 (e.g., of the SPI type).

[0071] The application processor includes a central processing unit (UC), a communication circuit (COMCT), non-volatile memory (NVM), volatile memory (RAM), and a display driver circuit (DD1). The COMCT circuit enables the application processor to connect to a private network or a public network such as the Internet. It can implement one or more wired or wireless communication technologies, such as Wi-Fi, GSM EDGE, 3G, 4G, 5G, etc.

[0072] The non-volatile memory (NVM) includes an operating system (OS1), accompanying application programs (CAPs), and at least one information source application (message sending and receiving, web browser, game, etc.) through which the user can find the information they need, such as the address of an encrypted asset account (ADD). The volatile memory (RAM) includes a frame buffer (FBUF1), system memory (SMEM1), and clipboard memory (CB1), or more simply, a "clipboard" (CB1). The frame buffer (FBUF1) contains pixel-type data (PIX1) provided by the central processing unit, which together form an image (IMG1) displayed by the application processor. This pixel-type data corresponds to the source data stored in the system memory (SMEM1). Therefore, for example, text existing as an image in the frame buffer (FBUF1) can be extracted by the application processor from the system memory (SMEM1) as editable text. The display driver (DD1) receives the data (PIX1) and provides image data (IDT1) formatted according to a defined protocol compatible with the screen (D3) (here, the MIPI DSI format) on port IO2 of the application processor.

[0073] Operating system OS1 includes a regular clipboard function or an insecure clipboard (NSCB), and a secure clipboard function (SCB1a). The secure clipboard function SCB1a is a subroutine of the operating system that determines which operations are assigned to the application processor to implement the secure clipboard SCB1.

[0074] The security processor SP1 includes a central processing unit UC, non-volatile memory that receives the operating system OS2 and the hardware wallet application WAP (application), and volatile memory including a frame buffer FBUF2 and a secure clipboard memory CB2. The operating system OS2 itself includes a secure clipboard function SCB1b, designed to cooperate with the application processor function SCB1a to implement the secure clipboard SCB1. The secure clipboard function SCB1b is a subroutine of the operating system that determines the actions assigned to the application processor to implement the secure clipboard SCB1.

[0075] The security processor SP1 is equipped with a display driver DD2, which is external to the processor SP1, but can also be provided as a component integrated into the processor. The display driver DD2 provides image data IDT2 to the screen D3 in an appropriate format (here, MIPI DSI) from pixel-type data PIX2 provided by the frame buffer FBUF2. This data PIX2 forms an image IMG2 to be displayed as provided by the security processor. The security processor is also equipped with at least one monostable physical button B and a visual indicator LD, such as an LED diode. The monostable button B is user-actuable and connected between the security processor's input / output port IO20 and a low logic level (such as circuit ground). The visual indicator LD is connected between input / output port IO21 and ground. In one embodiment, the security processor is also equipped with a physical bistable switch S that connects the security element eSE's input / output port IO22 to a low logic level in a first position and to a high logic level in a second position.

[0076] Here, the use of screen D3 is shared between application processor AP1 and security processor SP1. Therefore, image data IDT1 provided by application processor via display driver DD1 and image data IDT2 provided by security processor SP1 via display driver DD2 are respectively applied to the first and second input terminals of display selection circuit MUX, the output of which is applied to the input terminal of screen D3. Circuit MUX is controlled by signal SEL provided by port IO12 of security processor SP1, thus the security processor can decide to control the display at any time and force the display of image IMG2 placed in buffer FBUF2.

[0077] In one implementation of the circuit MUX, the signal SEL is a digital signal encoded over several bits, enabling the security processor to indicate to the circuit MUX the number of screen lines it wishes to display its own information. Therefore, the security processor might wish to display an image that occupies the entire screen and replaces the image it wishes to display, or an image that occupies only a few lines of the screen, for example, to simultaneously display data held by the security processor and data held by the application processor. In this second case, such as... Figure 7As shown, the screen is divided into a non-secure display area (NSD) and a secure display area (SD). Information provided by the application processor is displayed in the NSD, while information provided by the secure processor is displayed in the SD. This secure display area may specifically allow the display of the contents of the secure clipboard. Depending on the chosen implementation, the extent of the secure area SD can be predetermined and fixed or variable. If the extent is fixed, it can be indicated to the user by visual markers (VMs) provided at the edge of the screen (e.g., bars indicating color). If the extent is variable, it can be indicated to the user by a row of LEDs forming the visual markers (VMs), where only the diodes facing the secure area are illuminated, as in, for example, in... Figure 10A and Figure 10D As shown in the diagram, a variable-range visual marker is illustrated. Finally, when the security processor uses the entire screen, if the indicator LD has already been used to signal to the user that the application processor is active, it can signal this to the user by illuminating the light indicator LD or any other indicator.

[0078] In other implementations, when the security processor executes the hardware wallet application WAP and the application processor executes the companion application CAP, the security processor uses only a portion of the screen, while the other portion is reserved for the security processor. This prevents the security processor from overwriting data that the application processor might want to display while the application processor is using the screen.

[0079] In other embodiments where the signal SEL is encoded on several bits to indicate the number of screen rows that the security processor wishes to use, the signal SEL is provided to the application processor. Figure 6 The application processor is configured to dynamically adjust the size of the images it provides to the circuit MUX in order to prevent parts of these images from being covered by images simultaneously provided to the circuit MUX by the security processor.

[0080] Touch data TDT emitted by the touch panel TMD is also shared between the application processor AP1 and the security processor SP1. Therefore, the touch data TDT provided by the touch panel TMD is applied to the input of the routing circuit DMUX1, which has a first output connected to the application processor's input / output port IO3 and a second output connected to the security processor's input / output port IO13. Circuit DMUX1 is controlled by a signal SEL provided by the security processor SP1, or, if the signal SEL comprises several bits, by a portion of the signal SEL. Thus, in one embodiment, the signal SEL includes a first signal SEL1 for controlling the circuit MUX, and a second signal SEL2 for controlling circuit DMUX1 independently of the control of the circuit MUX. Therefore, the security processor can decide at any time to receive the touch data TDT, rather than the application processor. In a variant, the routing circuit DMUX1 is not provided, and the touch data TDT is provided to both the application processor and the security processor, each depending on what it is currently doing to know whether this data is relevant to it.

[0081] As noted above, the application processor and the security processor are configured to cooperate to implement the first implementation scheme SCB1 for a secure clipboard.

[0082] like Figure 7 As illustrated, when the information source application ISAP displays information on a non-secure portion of the NSD screen, the user can select a text or image portion (here, the text "xyzxyzxyz") with their finger via the touch panel TMD (or, in other implementations, a stylus or mouse). The application processor then displays an extended clipboard menu ECBM, which, in addition to the regular "cut" or "copy" functions, includes a "Copy SCB1" key for copying the selected text to the secure clipboard. The "Copy SCB1" key itself provides two options: selecting to copy as text-type data or selecting to copy as an image portion (not shown).

[0083] If the user chooses to copy SCB1 to the secure clipboard, in one implementation, the text or image portion copied to the secure clipboard is automatically displayed in the secure display area SD by the security processor, such as... Figure 7 As shown. Therefore, users can immediately verify that the text or image portion copied to the secure clipboard and displayed in the region SD is the same as the text or image portion selected in the application ISAP.

[0084] refer to Figure 6 and Figure 7When a user activates the secure copy function SCB1 with a "text" option after selecting data (here, "xyzxyzxyz") from an image displayed by the application processor, the application processor identifies the text-type data corresponding to the selected data in its system memory SMEM1 and copies this data to the clipboard memory CB1. The application processor then instructs the security processor via bus DB1 that the user has requested data to be copied to the secure clipboard. Upon approval by the security processor, the application processor transmits the data "xyzxyzxyz" as text-type data to the security processor, and the security processor stores it in the secure clipboard memory CB2. The security processor then preferably displays the data "xyzxyzxyz" in the secure display area SD, allowing the user to verify that the copied data is identical to the data displayed by the application ISAP in the non-secure display area NSD. Figure 7 ).

[0085] In some implementations, user action may be required to confirm the final recording of data in the secure clipboard. This action is preferably an action on a secure device, i.e., controlled by a secure processor, such as button B. It should be noted that the action of confirming the final recording of data in the secure clipboard can cover various implementations, such as those where the data is placed in a buffer register of the secure processor during its display rather than being placed directly in the secure clipboard memory. In this case, the secure processor stores the data in the secure clipboard memory only after receiving the user's consent.

[0086] At any time after receiving the user's consent, or alternatively, the display of data in the display area SD may be interrupted according to one or a combination of the following options:

[0087] - The display is maintained for a time Tdmax determined by the security processor, or

[0088] - The display ends when the user requests it using an insecure function key provided for this purpose, or

[0089] - The display in the display area SD ends when the user leaves the source application in the display area NDS to switch to another application (e.g., the companion application CAP).

[0090] Once copied to the secure clipboard, the data is completely safe and cannot be altered by attacks targeting the application processor (especially the accompanying application CAP).

[0091] In the aforementioned variant of the secure clipboard function, after the user selects an image portion containing the address ADD from an image already displayed by the application processor, the user activates the secure copy function SCB1 using the "Image" option. In this case, the application processor identifies the image portion IMADD selected by the user in the frame buffer FBUF1 and copies it to its clipboard memory CB1. The application processor then establishes communication with the secure processor via bus DB1, informing it that the user has requested to copy image type data to the secure clipboard. After approval by the secure processor, the secure processor transfers the image portion IMADD to itself, and the secure processor stores the image portion IMADD in its secure clipboard memory CB2 and displays it in the secure display area SD. From this point onward, the image portion IMADD copied by the user is completely secure and cannot be altered by attacks targeting the application processor (especially the accompanying application CAP).

[0092] The secure clipboard feature can have a variety of applications, particularly protecting the preparation and execution of transactions, which will be described further below.

[0093] In the context of preparing and executing a transaction, the user uses a secure clipboard storage to place the address ADD of the crypto asset account they wish to use for the transaction. Depending on the chosen implementation of the secure clipboard, this address ADD will be copied to the secure clipboard either as text-type data or as an image portion (IMADD) containing the address ADD.

[0094] Schematic representation: The application processor and security processor are combined to prepare and execute transactions as follows:

[0095] 1) The application processor executing the accompanying application CAP prepares a transaction by requesting the user to fill in a transaction descriptor;

[0096] 2) Then, the application processor sends a transaction descriptor to the security processor so that it can sign the transaction.

[0097] 3) The security processor executing the hardware wallet application WAP returns the transaction signature to the application processor. The latter can then place the signed transaction on the relevant blockchain.

[0098] Generally speaking, before being signed, a transaction descriptor is first transformed into a "raw transaction" by a security processor, which is a string of binary or hexadecimal data that can be signed.

[0099] Transaction descriptors can take various forms depending on the type of transaction involved. For example, a descriptor for an Ethereum transaction could take the following form:

[0100]

[0101] When the transaction descriptor from the example above is converted into a raw transaction, it can appear as follows (in hexadecimal):

[0102] f86e826f4a8505f901eadd826b6c94388c818ca8b9251b393131c08a736a67ccbl92978801167140fda3d0818025a0dcbal464c58f31892b d0ae8e6271f838189cd344d98e928f3194efe4bce9ebc6a04fOfc71bee74ala6fafbel7cde3c35981c93b58703856ef5dd53884albl53773

[0103] The signature algorithm used by the security processor is specific to the blockchain under consideration. The Bitcoin and Ethereum blockchains use algorithms such as ECDSA / secp256k1 / SHA256 as the signature means; that is, a signature generated using ECDSA (Elliptic Curve Digital Signature Algorithm) configured with the secp256k1 parameter, including a prior hash of the original transaction using the SHA-256 (Secure Hash Algorithm) function to obtain the transaction's "hash code" or digest. This algorithm produces the following types of signatures:

[0104]

[0105] The application processor then sends the transaction descriptor and transaction signature to a broadcast service, which ensures that the transaction is broadcast on the relevant blockchain.

[0106] For simplicity, the terms "transaction," "transaction descriptor," or "original form of a transaction" may have the same meaning here or below. Furthermore, the terms "transaction descriptor," "transaction," and "transaction signature" have no additional limiting meaning and can vary widely depending on the crypto asset in question and the blockchain involved. In particular, for crypto assets of the "smart contract" type, a transaction descriptor may include a greater number of parameters than a simple Bitcoin or Ethereum transaction descriptor. In all cases, the security processor is preferably configured to present all transaction parameters to the user when applying the "WYSIWYS" principle ("What You See Is What You Sign").

[0107] refer to Figure 8 and Figure 9The flowcharts will provide a better understanding of the use of the secure clipboard in the context of preparing and executing crypto asset transactions. These flowcharts illustrate two examples of preparing and executing crypto asset transactions. Figure 8 and Figure 9 The following symbols are used:

[0108] - "USER" refers to the user;

[0109] - "AP1-USER" refers to the action of application processor AP1 in response to a request from a user;

[0110] - "AP1-CAP" refers to the actions of the application processor AP1 that executes the accompanying application, that is, the actions performed by the accompanying application using the application processor AP1;

[0111] - "SP1-WAP" refers to the actions performed by the hardware wallet application WAP using the security processor SP1, i.e., actions performed by the hardware wallet application WAP using the security processor AP1.

[0112] "Go to" or "Return to" means that the user goes to or returns to the graphical interface of the relevant application (displayed in a window or full screen) to do something: read information, select displayed data, delete, copy to clipboard memory, or paste data stored in clipboard memory.

[0113] exist Figure 8 In the implementation scheme, the secure clipboard function SCB1 is used to copy the address ADD as text-type data. At step S100, the user accesses the information source application ISAP, such as a webpage or email containing the address ADD of the encrypted asset account. Figure 10A In step S102, the user selects address ADD as text type data and activates the NSCB function to copy it to the insecure clipboard. In step S103, application processor AP1 reads the selected address ADD from its system memory SMEM1. In step S104, application processor AP1 stores the address ADD in clipboard memory CB1. In step S109, the process is similar... Figure 10A As illustrated, the user activates the SCB1 function to copy to the secure clipboard. In step S110, the application processor AP1 establishes communication with the secure processor SP1. In step S111, the application processor AP1 sends the address ADD, which resides in the clipboard memory CB1, to the secure processor SP1. In step S112, the secure processor SP1 stores the address ADD in the secure clipboard memory CB2 and preferably displays it in the secure area SD of the screen, such as... Figure 10AAs shown, this allows the user to verify that the source address and the copied address are the same. As noted above, user consent may be required here to confirm the record of address ADD in the secure clipboard. This consent is preferably given via a secure device such as button B.

[0114] In step S115, the user is redirected to the companion application CAP. In step S120, at the user's request, application processor AP1 pastes the address ADD into the transaction descriptor to be filled in by the user and displayed by the companion application CAP. Figure 10B and Figure 10C As illustrated, the address ADD is pasted from the insecure clipboard memory CB1 into the accompanying application CAP. At step S125, the user completes the transaction descriptor proposed by the accompanying application CAP and requests transaction execution. Here, user input is performed via a virtual keyboard displayed on screen D3, with the touch panel TMD serving as both a means of selecting and inputting information. In other variations, the terminal may be equipped with a physical keyboard, and information selection may be performed using a touchpad separate from screen D3. At step S135, the application processor AP1 executing the accompanying application CAP transmits the transaction descriptor including the address ADD to the security processor SP1 and requests its signature. At step S136, the security processor SP1 executing the hardware wallet application WAP verifies that the received address ADD is the same as the address ADD in the secure clipboard memory CB2. If the addresses are different, the security processor proceeds to step S160; otherwise, it proceeds to step S140. Figure 10DAt step S140, the security processor SP1 executing the hardware wallet application WAP displays a transaction descriptor including the address ADD in the secure display area SD, and optionally displays the address ADD existing in the secure clipboard, and requests the user to confirm the transaction. At step S145, the user optionally verifies that the address ADD displayed in the non-secure display area NSD and the address ADD displayed in the secure display area SD are the same, and then confirms the transaction using button B; otherwise, the user instructs the security processor to reject the transaction, for example, by using a touch key, since the data TDT provided by the touch panel TMD is received by the security processor during this confirmation phase. At step S150, if the user has confirmed the transaction, the security processor SP1 executing the hardware wallet application WAP signs the transaction and sends the signature to the application processor AP1. At step S155, the application processor AP1 executing the companion application CAP places the transaction on the relevant blockchain. At step S160, the security processor SP1 refuses to sign the transaction. This step is executed if the user rejects the transaction, or if the maximum waiting time agreed upon by the user has been exceeded, or if the security processor has found that the address presented to it is different from the address in the security clipboard.

[0115] Those skilled in the art will note that this embodiment of the secure clipboard uses the application processor's insecure clipboard memory as intermediate storage for the data ADD before sending the contents of the data ADD to the secure processor for storage in the secure clipboard memory. In variations, the data ADD may be stored in a memory area other than the memory area used as insecure clipboard memory before being sent to the secure processor. In other variations, the data may be encrypted before being transmitted to the secure processor via bus DB1.

[0116] exist Figure 9 In the implementation scheme, the secure clipboard function SCB1 is used to copy the address as the image portion IMADD. [This is related to...] Figure 8The described steps are indicated by the same reference numerals. At step S100, the user navigates to the information source application ISAP. At step S202, the user selects the address ADD of the encrypted asset account as the image portion IMADD and activates the NSCB function of the security processor for copying the image to the insecure clipboard. At step S203, the application processor AP1 reads the image portion IMADD from its frame buffer FBUF1. At step S204, the application processor AP1 stores the image portion IMADD in the clipboard memory CB1. At step S209, the user activates the SCB1 function to copy to the secure clipboard. At step S110, the application processor AP1 establishes communication with the security processor SP1. At step S211, the application processor AP1 sends the image portion IMADD to the security processor SP1. At step S212, the security processor SP1 stores the image portion IMADD in the secure clipboard memory CB2 and displays it in the secure display area SD for user verification. As mentioned earlier, user consent may be required here to confirm the record of address ADD in the secure clipboard. This consent is preferably given via a secure device such as button B. The user then repeats the process regarding... Figure 8 Steps S102, S103, and S104 are described to copy the address ADD as text-type data to the application processor's insecure clipboard CB1. At step S115, the user navigates to the companion application CAP. At step S120, at the user's request, the application processor AP1 pastes the address ADD from the insecure clipboard memory CB1 into the companion application CAP, as previously described. At step S125, the user completes the transaction descriptor in the companion application CAP and requests transaction execution. At step S135, the application processor AP1 executing the companion application CAP transmits the transaction descriptor, which includes the address ADD, to the secure processor SP1 for signature. Figure 10DIn step S240, the security processor SP1 of the hardware wallet application WAP displays a transaction descriptor including the address ADD and an image portion IMADD in the secure display area SD, and requests the user to confirm the transaction. In step S245, the user verifies whether the address ADD in the transaction descriptor and the address ADD appearing in the image portion IMADD are the same, and confirms the transaction; otherwise, the user indicates to the security processor that they wish to cancel the transaction. In step S150, the security processor SP1 of the hardware wallet application WAP signs the transaction and sends the signature to the application processor AP1. In step S155, the application processor AP1 of the companion application CAP places the transaction on the blockchain. In step S160, if the maximum waiting time for user confirmation has been exceeded or if the user has indicated that they are canceling the transaction, the security processor SP1 refuses to sign the transaction.

[0117] Similar to the previous implementation, this implementation is prone to variations in the storage of the image portion IMADD before it is transferred to the secure processor. Furthermore, the secure processor can apply OCR processing to the image portion IMADD to extract the address ADD as text-type data, and subsequently perform [actions related to...]. Figure 8 The comparison step S136 described herein Figure 9 It does not exist in the flowchart.

[0118] Figure 11 An implementation of a terminal TL2 configured to implement the Secure Clipboard Method SCB2 is shown, wherein the entire image IMG1 displayed by the application processor is transmitted to the secure processor. Terminal TL2 has the same structure as terminal TL1 and will not be described further. Its difference from terminal TL1 lies in that the application processor's operating system OS1 includes a Secure Clipboard SCB2 function SCB2a in addition to the Non-Secure Clipboard (NSCB) and Secure Clipboard SCB1a functions. This SCB2a function is provided to cooperate with the supplementary function SCB2b provided in the secure processor's operating system OS2. As another distinction, the secure processor SP1 includes a system memory region SMEM2 in its non-volatile memory, which is provided to receive a copy of a portion of the secure processor's system memory region SMEM1 containing system data associated with the image IMG1 transmitted to the secure processor by the application processor when the user activates the copy function SCB2.

[0119] As mentioned earlier, activation of the SCB2 copy function of the secure clipboard CB2 is under the control of the application processor, which displays, for example, the option "Copy SCB2" in the extended clipboard menu ECBM, as shown in the modified version. Figure 7or Figure 10A As illustrated, users can select between the non-secure clipboard, secure clipboard SCB1, or secure clipboard SCB2 in the ECBM menu.

[0120] By activating the secure clipboard SCB2, the application processor transmits the entire display image IMG1 from the frame buffer FBUF1 to the secure processor via bus DB1. The application processor then transmits the corresponding system data stored in its system memory SMEM1 to the secure processor. The secure processor stores image IMG1 in its frame buffer FBUF2 and stores data extracted from system memory SMEM1 in its own system memory SMEM2. The secure processor then controls the entire screen D3 and the touch panel TMD by giving the signal SEL an appropriate value, then displays image IMG1 and invites the user to select the portion of interest from the image via a floating or collapsible message. It should be noted that when the user activates the copy function to the secure clipboard SCB2, the user is not aware of the switch from image IMG1 displayed by the application processor to the same image IMG1 displayed by the secure processor, which has already controlled screen D3. To reassure and confirm to the user that they are in a secure space where they can extract data ADD or crop the portion of the image of interest IMADD, the secure processor can activate the visual indicator LD or activate any other device that allows the user to know that the displayed image is under the control of the secure processor.

[0121] refer to Figure 12 and Figure 13 The flowcharts will provide a better understanding of the use of the Secure Clipboard SCB2 in the context of preparing and executing crypto asset transactions. These flowcharts illustrate two examples of a method for preparing and executing crypto asset transactions.

[0122] exist Figure 12 In the implementation scheme, the Secure Clipboard function SCB2 is used to copy the address ADD as text-type data. (Already regarding...) Figure 8 or Figure 9 The steps described are indicated by the same reference numerals in the accompanying drawings.

[0123] At step S100, the user navigates to the information source application ISAP. At step S300, the user activates the SCB2 function to copy to the secure clipboard. At step S110, application processor AP1 establishes communication with secure processor SP1. At step S310, application processor AP1 transmits image IMG1, which is stored in frame buffer FBUF1, to secure processor SP1. At step S311, secure processor SP1 stores image IMG1 in frame buffer FBUF2. At step S312, application processor AP1 transmits system data related to image IMG1, which is stored in system memory SMEM1, to secure processor SP1. At step S313, secure processor SP1 stores system data in its system memory SMEM2. At step S320, secure processor SP1, which has already controlled screen D3, displays the copied image IMG1 on screen D3 instead of the original image. Figure 10E As illustrated, in this case, the entire screen becomes the secure display area SD, as indicated by the indicator VM. At step S322, the user selects the address ADD of the encrypted asset account as text-type data from the image and confirms the selection. Touch data is received here by the security processor, which has controlled the routing circuit DMUX1. At step S340, the security processor SP1 reads the address ADD selected by the user from the system memory SMEM2. At step S112, the security processor SP1 stores the address ADD in the secure clipboard memory CB2 and displays it in the lower part of the secure display area SD. Therefore, the result is... Figure 8 Step S112 is the same, but it is obtained by extracting data ADD from the image displayed by the security processor. However, it should be noted that since the selection of the address ADD is made by the security processor, the address ADD may not be displayed in the lower part of the security display area SD. Similarly, it may not be necessary to confirm the recording of the address ADD in the security clipboard with user consent provided by the security device.

[0124] At step S345, the user returns to the information source application ISAP. Then, the user repeats the process regarding... Figure 8 Steps S102, S103, and S104 are described to copy the address ADD as text type data to the insecure clipboard. Following this step, the method includes steps already discussed... Figure 8 The steps described are S115, S120, S125, S135, S136, S140, S145, S150, S155 and S160.

[0125] exist Figure 13 In the implementation scheme, the secure clipboard function SCB2 is used to copy the address as the image portion IMADD. [This is related to...] Figure 8 , Figure 9 and Figure 12 The steps described are indicated by the same reference numerals in the accompanying drawings.

[0126] At step S100, the user navigates to the information source application ISAP. At step S300, the user activates the SCB2 function to copy an image to the secure clipboard using the "Image Copy" option. At step S110, application processor AP1 establishes communication with secure processor SP1. At step S310, application processor AP1 transmits the image IMG1, which is stored in frame buffer FBUF1, to secure processor SP1. At step S311, secure processor SP1 stores the image IMG1 in frame buffer FBUF2. At step S320, secure processor SP1 controls the screen and displays the copied image IMG1 on screen D3 in place of the original image. Figure 10E As illustrated, in this case, the entire screen becomes the secure display area SD, as indicated by the indicator VM. At step S422, the user selects the address of the encrypted asset account ADD from the copied image as the image portion IMADD and confirms this selection, which is received by the security processor in the form of touch data TDT. At step S341, the security processor SP1 uses TRIM (… Figure 11 The cropping function is used to crop the image portion IMADD selected by the user from the copied image IMG1. In step S212, the security processor SP1 stores the image portion IMADD in the secure clipboard memory CB2 and displays it in the lower part of the secure display area SD. Therefore, the result is... Figure 9 Step S212 is the same, but it is obtained by extracting the address ADD from the image displayed by the security processor. As mentioned earlier, the display of the address ADD in the lower part of the security display area SD may not be provided. Similarly, user consent may not be required to confirm the recording of the address ADD in the security clipboard.

[0127] Then, the method includes already regarding Figure 9 The described series of steps S345, S102, S103, S104, S115, S120, S125, S135, S240, S245, S150, S155 and S160.

[0128] In the implementation of either Secure Clipboard SCB1 or Secure Clipboard SCB2, the user first puts the secure processor into active mode via a bistable switch S. Once in active mode, the secure processor activates the communication channel with the application processor via bus DB1, preparing the two processors for communication. Then, the user, under the control of the secure processor, indicates to the secure processor that they wish to continue copying to Secure Clipboard SCB1 or SCB2. The secure processor then sends a request to the application processor to copy to the secure clipboard, and the application processor displays the function icon SCB1 or SCB2 (or both) in the extended clipboard menu ECBM, as shown below. Figure 7 or Figure 10A As shown.

[0129] This activation mode allows the security processor to control the copy method triggered to the secure clipboard and ensures that the copy request truly originates from the user. This prevents, for example, malicious programs from initiating endless loops of copying to the secure clipboard itself and / or recording to the secure clipboard. To this end, the security processor can be configured to accept only a single data storage action after a user action is performed on button B, followed by an action on function icons SBC1 or SCB2 displayed by the application processor.

[0130] It should be noted that, for the purpose of the secure clipboard, several other buttons (such as button B) or other switches (such as switch S) can be provided. Once in active mode, the secure processor can also control data provided by a touch keyboard, which provides dedicated function keys for the secure clipboard, replacing button B. A dedicated touch keyboard for the secure processor can also be provided.

[0131] Figure 14 An implementation of a terminal TL3 configured to implement a secure clipboard function SCB3 with text copy or image copy options is shown. Terminal TL3 has the same structure as terminals TL1 and TL2 and will not be described further. The difference between terminal TL3 and terminal TL2 is that the operating system OS2 of the secure processor includes secure clipboard functions SCB1b and SCB2b (which are retained here but can be omitted), as well as secure clipboard function SCB3. This function is independent of the application processor, therefore the application processor does not have a corresponding function in its operating system OS1. In fact, as explained above, this implementation of the secure clipboard function is based on reconstructing the image IMG1 displayed by the application processor without the user's knowledge by offloading image data provided by the application processor to screen D3. The user then selects either a text type address ADD or an image portion IMADD containing that address from the image with the dedicated assistance of the secure processor and without any intervention from the application processor.

[0132] Therefore, the SCB3 copy function cannot be activated from a virtual button displayed by the touchscreen D3 / TMD, as it operates without the application processor's knowledge. Therefore, it is preferable to provide a specific button connected to a secure processor to activate the SCB3 function. For example, as... Figure 14 As illustrated, button B can also be used again as a button to activate the SCB3 function. It should be noted that this use of button B does not preclude its subsequent use as a transaction confirmation button, although other similar buttons may also be provided. In one embodiment, the security processor has previously been placed into the activity mode described above using switch S.

[0133] As another distinction, the security processor SP1 is equipped with a decoding circuit DECCT for the intermediate frame buffer FBUF3. The decoding circuit DECCT acts as a detection circuit and includes an input connected to the first input of the selection circuit MUX, which receives MIPI DSI format image data IDT1 provided by the application processor. This data is decoded by the circuit DECCT, which extracts pixel-type data PIX1—those pixel-type data provided by the application processor to its display driver DD1—and analyzes this data to infer the start and end of the image IMG1. Therefore, the circuit DECCT reconstructs the image IMG1 line by line and stores it in the intermediate buffer FBUF3. When the image IMG1 has been fully reconstructed, the security processor transmits it to the buffer FBUF2, controls the screen D3 via the selection circuit MUX, configures the circuit DMUX1 to receive touch data, and invites the user to select their chosen area. The security processor also includes a TRIM function for cropping and reconstructing the image, similar to... Figure 11 The terminal TL2 uses the functions to provide the image portion IMADD. The security processor also includes OCR functionality for the text copy option, allowing it to extract text-type data, specifically address ADD, from the user-selected image portion IMADD.

[0134] refer to Figure 15 and Figure 16 The flowcharts will provide a better understanding of the use of the Secure Clipboard SCB3 in the context of implementing crypto asset transactions. These flowcharts illustrate two examples of a method for preparing and executing crypto asset transactions.

[0135] exist Figure 15 In the implementation scheme, the Secure Clipboard function SCB3 is used to copy the address ADD as text-type data. (Already regarding...) Figure 8 , Figure 9 , Figure 12 , Figure 13 The steps described are indicated by the same reference numerals in the accompanying drawings.

[0136] At step S100, the user navigates to the information source application ISAP. At step S400, the user activates the SCB3 function for copying to the secure clipboard via button B. At step S410, the circuit DECCT taps the image data IDT1 provided by the application processor AP1, decodes it, and reconstructs the image IMG1 in the intermediate frame buffer FBUF3. At step S420, the secure processor SP1 transfers the copied image IMG1 to the frame buffer FBUF2. At step S320, the secure processor SP1 displays the copied image IMG1 on screen D3 in place of the original image. Figure 10E As illustrated, in this scenario, the entire screen becomes the secure display area SD, as indicated by the indicator VM. At step S422, the user selects the address ADD of the encrypted asset account from the copied image as the image portion IMADD and confirms their selection. At step S341, the secure processor SP1 with TRIM functionality crops the image portion IMADD from the copied image IMG1 according to the user's selection. At step S443, the secure processor SP1 extracts the address ADD from the image portion IMADD using OCR functionality. At step S112, the secure processor SP1 stores the address ADD in the secure clipboard memory CB2 and displays it in the lower part of the secure display area SD, a result similar to that of step S112 in other implementation schemes, but obtained in a different manner. Since this implementation is end-to-end secure, displaying the copied address in the lower part of the secure display area SD is entirely optional here, although it can be provided for user information purposes. Similarly, from a security perspective, the user's consent to confirm the recording of the address ADD in the secure clipboard is entirely optional, but can be provided for ergonomic reasons.

[0137] The following steps have been described. Before executing the steps, the security processor temporarily returns control of screen D3 to the application processor. At step S345, the user returns to the information source application ISAP. Then, the user repeats the process regarding... Figure 8Steps S102, S103, and S104 are described to copy the address ADD as text-type data to the insecure clipboard. At step S115, the user navigates to the companion application CAP. At step S120, at the user's request, application processor AP1 pastes the address ADD from the insecure clipboard memory CB1 into the companion application CAP. At step S125, the user completes the transaction descriptor in the companion application CAP and requests transaction execution. At step S135, application processor AP1 executing the companion application CAP transmits the transaction descriptor, which includes the address ADD, to the security processor SP1 for signing. At step S136, the security processor SP1 executing the hardware wallet application WAP verifies that the received address ADD is identical to the address ADD in the secure clipboard memory CB2. At step S140, the security processor SP1 executing the hardware wallet application WAP displays the transaction descriptor containing the address ADD in the secure display area SD, and optionally displays the address ADD present in the secure clipboard, then requests user confirmation of the transaction. At step S145, before confirming the transaction, the user can optionally verify that the address ADD displayed in the non-secure display area NSD and the address ADD displayed in the secure display area SD are the same. At step S150, the security processor SP1 of the hardware wallet application WAP signs the transaction and sends the signature to the application processor AP1. At step S155, the application processor AP1 of the companion application CAP places the transaction on the blockchain. If the user's waiting time has expired, or if the user cancels the transaction, or if the displayed address ADD is different, the security processor SP1 refuses to sign the transaction at step S160.

[0138] In a variant of the method just described, the security processor applies OCR processing to the entire image IMG1 before providing the user with the option to crop the text-type data they desire.

[0139] exist Figure 16 In the implementation scheme, the secure clipboard function SCB3 is used to copy the address as the image portion IMADD. [This is related to...] Figure 8 , Figure 9 , Figure 12 , Figure 13 , Figure 15 The steps described are indicated by the same reference numerals in the accompanying drawings.

[0140] Figure 16 The first steps of the method, S100, S400, S410, S420, S320, S422, and S341, are... Figure 15The steps of the method are the same. After the cropping step S341, the OCR processing step S443 is omitted. After step S341, in step S212, the image portion IMADD is stored in the secure clipboard memory CB2 and displayed in the lower part of the secure display area SD. Since this implementation is also end-to-end secure, displaying the image portion IMADD in the lower part of the secure display area SD is also optional here, and user consent to confirm the recording of the image portion IMADD in the secure clipboard is also optional. The following steps S345, S102, S103, S104, S115, S120, S125, S135, S240, S245, S150, S155 and S160 are the same as those in the method. Figure 13 The steps are the same as the method.

[0141] It will be apparent to those skilled in the art that the secure clipboard method just described is susceptible to various other variations. Although the method is designed in conjunction with the integration of hardware wallet functionality into the terminal, the secure clipboard functionality just described is susceptible to various other applications in order to make transaction preparation and execution more secure. Furthermore, the application processor can be any known component of the microcontroller type or a collection of components forming a semiconductor system-on-a-chip (SoC). The secure processor itself can be a secure element on a semiconductor chip, to which certain peripheral components have been added if they were not initially included. The secure processor can also be a trusted execution environment (TEE) of the application processor.

[0142] The mobile terminal architecture just described is itself susceptible to many implementation variations. Figure 17 In the terminal variant TL4 shown, the selection circuit MUX has been replaced by an auxiliary processor AUXP, which drives the screen D3 via a display driver DD3 that provides MIPI DSI format image data. The auxiliary processor AUXP receives pixel-type data PIX1 provided by the application processor's buffer FBUF1 and pixel-type data PIX2 provided by the security processor's buffer FBUF2. The auxiliary processor is programmed to form a software multiplexer under the control of the security processor, thereby prioritizing the pixel-type data provided by the security processor.

[0143] exist Figure 18 In the terminal variant TL5 shown, the security processor SP1 is a Trusted Execution Environment (TEE) within the application processor AP1. The data bus DB1 is replaced by the transaction memory EXMEM, through which the TEE environment receives data provided by the application processor.

[0144] Figure 19The terminal variant TL6 shown combines the control of a security processor to... Figure 17 The auxiliary processor provides a software multiplexer, as well as a secure processor implemented in the form of a TEE trusted environment for the application processor.

[0145] exist Figure 20 In the terminal variant TL7 shown, the application processor AP1 is connected to its own screen D4, and the security processor SP1 is connected to its own screen D5. Terminal TL7 is equipped with a touchpad TPD and a keyboard KBD separate from screens D4 and D5. The touchpad TPD provides touch data TDT, and the keyboard KBD provides text data TXDT. Under the control of the security processor and controlled by signal SEL3, the touch data and text data are provided to one or more processors via a dual-channel routing circuit DMUX2.

[0146] The secure clipboard implementations SCB1, SCB2, and SCB3 described above allow users to save the address of their crypto asset account before submitting a transaction using the accompanying application. Because the action of copying the address (ADD) or its image (IMADD) is initiated at any time before the call to the accompanying application, it is less vulnerable to attacks by fraudsters, unless the fraudster has complete control over the terminal, which remains highly unlikely. In any case, complete control over the terminal would involve the application processor and cannot reach the secure processor. Therefore, the secure clipboard implementation SCB3 itself will remain inviolable because it is completely independent of the application processor.

[0147] Appendix that forms part of the overall instruction manual: Figure 8 , Figure 9 , Figure 12 , Figure 13 , Figure 15 , Figure 16 Description

[0148] Figure 8 :

[0149] (S100) User redirected to ISAP

[0150] (S102) The user selects the account address as text type data and activates the NSCB function to copy it to the insecure clipboard.

[0151] (S103) AP1 reads the selected address ADD in SMEM1.

[0152] (S104) AP1 stores ADD in clipboard memory CB1.

[0153] (S109) The user activates the SCB1 function to copy to the secure clipboard.

[0154] (S110) AP1 establishes communication with SP1

[0155] (S111) AP1 sends ADD to SP1

[0156] (S112) SP1 stores the ADD in CB2 and displays it in SD.

[0157] (S115) User redirected to CAP

[0158] (S120) AP1 - The user pastes an ADD from the insecure clipboard memory CB1 into CAP.

[0159] (S125) The user completes the transaction descriptor in CAP and requests to execute the transaction.

[0160] (S135) AP1-CAP sends a transaction descriptor, including ADD, to SP1 for signing.

[0161] (S136) SP1-WAP verifies that the received ADD is the same as the ADD in CB2.

[0162] (S140) SP1-WAP displays the transaction descriptor and optional replication address ADD in SD, and requests the user to confirm the transaction.

[0163] (S145) Before confirming a transaction, the user may optionally verify that the ADD displayed in the NSD and the ADD displayed in the SD are the same.

[0164] (S150) SP1-WAP signs the transaction and sends the signature to the API.

[0165] (S155) AP1-CAP places transactions on the blockchain.

[0166] (S160) SP1 refuses to sign the transaction if the following conditions are met:

[0167] - Exceeding the waiting time or user action, or

[0168] -Different ADD addresses

[0169] Figure 9 :

[0170] (S100) User redirected to ISAP

[0171] (S202) The user selects the account address ADD as the image portion IMADD and activates the NSCB function for copying the image to the insecure clipboard.

[0172] (S203) AP1 reads the image portion IMADD from FBUF1.

[0173] (S204) AP1 stores IMADD in clipboard memory CB1.

[0174] (S209) The user activates the SCB1 function to copy to the secure clipboard.

[0175] (S110) AP1 establishes communication with SP1

[0176] (S211) AP1 sends IMADD to SP1

[0177] (S212) SP1 stores IMADD in CB2 and displays it in SD.

[0178] (S102) (S103) (S104)

[0179] (S115) User redirected to CAP

[0180] (S120) AP1 - The user pastes an ADD from the insecure clipboard memory CB1 into CAP.

[0181] (S125) The user completes the transaction descriptor in CAP and requests to execute the transaction.

[0182] (S135) AP1-CAP sends a transaction descriptor, including ADD, to SP1 for signing.

[0183] (S240) SP1-WAP displays the transaction descriptor and IMADD in the SD and requests the user to confirm the transaction.

[0184] (S245) The user verifies that the ADD in the transaction descriptor and the ADD in the IMADD are the same, and confirms the transaction.

[0185] (S150) SP1-WAP signs the transaction and sends the signature to the API.

[0186] (S155) AP1-CAP places transactions on the blockchain.

[0187] (S160) If the waiting time or user action exceeds the limit, SP1 refuses to sign the transaction.

[0188] Figure 12 :

[0189] (S100) User redirected to ISAP

[0190] (S300) The user activates the SCB2 function to copy to the secure clipboard.

[0191] (S110) AP1 establishes communication with SP1

[0192] (S310) AP1 transmits the image IMG1, which exists in FBUF1, to SP1.

[0193] (S311) SP1 stores IMG1 in FBUF2.

[0194] (S312) AP1 transmits system data related to IMG1, which exists in SMEM1, to SP1.

[0195] (S313) SP1 stores system data in SMEM2.

[0196] (S320) SP1 displays a copied image IMG1 on D3 instead of the original image.

[0197] (S322) The user selects the account address as text type data and confirms the selection.

[0198] (S340) SP1 reads the selected address ADD in SMEM2.

[0199] (S112) SP1 stores ADD in the secure clipboard memory CB2 and displays it in SD.

[0200] (S345) The user returns to ISAP

[0201] (S102) (S103) (S104)

[0202] (S115) User redirected to CAP

[0203] (S120) AP1 - The user pastes an ADD from the insecure clipboard memory CB1 into CAP.

[0204] (S125) The user completes the transaction descriptor in CAP and requests to execute the transaction.

[0205] (S135) AP1-CAP sends a transaction descriptor, including ADD, to SP1 for signing.

[0206] (S136) SP1-WAP verifies that the received ADD is the same as the ADD in CB2.

[0207] (S140) SP1-WAP displays the transaction descriptor and optional replication address ADD in SD, and requests the user to confirm the transaction.

[0208] (S145) Before confirming a transaction, the user may optionally verify that the ADD displayed in the NSD and the ADD displayed in the SD are the same.

[0209] (S150) SP1-WAP signs the transaction and sends the signature to the API.

[0210] (S155) AP1-CAP places transactions on the blockchain.

[0211] (S160) SP1 refuses to sign the transaction if the following conditions are met:

[0212] - Exceeding the waiting time or user action, or

[0213] -Different ADD addresses

[0214] Figure 13 :

[0215] (S100) User redirected to ISAP

[0216] (S300) The user activates the SCB2 function to copy to the secure clipboard.

[0217] (S110) AP1 establishes communication with SP1

[0218] (S310) AP1 transmits the image IMG1, which exists in FBUF1, to SP1.

[0219] (S311) SP1 stores IMG1 in FBUF2.

[0220] (S320) SP1 displays a copied image IMG1 on D3 instead of the original image.

[0221] (S341) SP1 with TRIM function crops IMADD from the copied image IMG1 according to the user's selection.

[0222] (S212) SP1 stores IMADD in the secure clipboard memory CB2 and displays it in the SD.

[0223] (S345) The user returns to ISAP

[0224] (S102) (S103) (S104)

[0225] (S115) User redirected to CAP

[0226] (S120) AP1 - The user pastes an ADD from the insecure clipboard memory CB1 into CAP.

[0227] (S125) The user completes the transaction descriptor in CAP and requests to execute the transaction.

[0228] (S135) AP1-CAP sends a transaction descriptor, including ADD, to SP1 for signing.

[0229] (S240) SP1-WAP displays the transaction descriptor and IMADD in the SD and requests the user to confirm the transaction.

[0230] (S245) The user verifies that the ADD in the transaction descriptor and the ADD in the IMADD are the same, and confirms the transaction.

[0231] (S150) SP1-WAP signs the transaction and sends the signature to the API.

[0232] (S155) AP1-CAP places transactions on the blockchain.

[0233] (S160) If the waiting time or user action exceeds the limit, SP1 refuses to sign the transaction.

[0234] Figure 15 :

[0235] (S100) User redirected to ISAP

[0236] (S400) The user activates the SCB3 function for copying to the secure clipboard via button B.

[0237] (S410) DECCT extracts the image IDT1 provided by AP1, decodes it, and reconstructs the image IMG1 in FBUF3.

[0238] (S420) SP1 transmits the copied image IMG1 to FBUF2

[0239] (S320) SP1 displays a copied image IMG1 on D3 instead of the original image.

[0240] (S422) The user selects the account address ADD from the copied image IMG1 as the image part IMADD and confirms the selection.

[0241] (S341) SP1 with TRIM function crops IMADD from the copied image IMG1 according to the user's selection.

[0242] (S443) SP1 with OCR function extracts ADD from the image portion IMADD.

[0243] (S112) SP1 stores ADD in the secure clipboard memory CB2 and displays it in SD.

[0244] (S345) The user returns to ISAP

[0245] (S102) (S103) (S104)

[0246] (S115) User redirected to CAP

[0247] (S120) AP1 - The user pastes an ADD from the insecure clipboard memory CB1 into CAP.

[0248] (S125) The user completes the transaction descriptor in CAP and requests to execute the transaction.

[0249] (S135) AP1-CAP sends a transaction descriptor, including ADD, to SP1 for signing.

[0250] (S136) SP1-WAP verifies that the received ADD is the same as the ADD in CB2.

[0251] (S140) SP1-WAP displays the transaction descriptor and optional replication address ADD in SD, and requests the user to confirm the transaction.

[0252] (S145) Before confirming a transaction, the user may optionally verify that the ADD displayed in the NSD and the ADD displayed in the SD are the same.

[0253] (S150) SP1-WAP signs the transaction and sends the signature to the API.

[0254] (S155) AP1-CAP places transactions on the blockchain.

[0255] (S160) SP1 refuses to sign the transaction if the following conditions are met:

[0256] - Exceeding the waiting time or user action, or

[0257] -Different ADD addresses

[0258] Figure 16 :

[0259] (S100) User redirected to ISAP

[0260] (S400) The user activates the SCB3 function for copying to the secure clipboard via button B.

[0261] (S410) DECCT extracts the image IDT1 provided by AP1, decodes it, and reconstructs the image IMG1 in FBUF3.

[0262] (S420) SP1 transmits the copied image IMG1 to FBUF2

[0263] (S320) SP1 displays a copied image IMG1 on D3 instead of the original image.

[0264] (S422) The user selects the account address ADD from the copied image as the image portion IMADD and confirms the selection.

[0265] (S341) SP1 with TRIM function crops IMADD from the copied image IMG1 according to the user's selection.

[0266] (S212) SP1 stores IMADD in the secure clipboard memory CB2 and displays it in the SD.

[0267] (S345) The user returns to ISAP

[0268] (S102) (S103) (S104)

[0269] (S115) User redirected to CAP

[0270] (S120) AP1 - The user pastes an ADD from the insecure clipboard memory CB1 into CAP.

[0271] (S125) The user completes the transaction descriptor in CAP and requests to execute the transaction.

[0272] (S135) AP1-CAP sends a transaction descriptor, including ADD, to SP1 for signing.

[0273] (S240) SP1-WAP displays the transaction descriptor and IMADD in the SD and requests the user to confirm the transaction.

[0274] (S245) The user verifies that the ADD in the transaction descriptor and the ADD in the IMADD are the same, and confirms the transaction.

[0275] (S150) SP1-WAP signs the transaction and sends the signature to the API.

[0276] (S155) AP1-CAP places transactions on the blockchain.

[0277] (S160) If the waiting time or user action exceeds the limit, SP1 refuses to sign the transaction.

Claims

1. An electronic terminal (TL1-TL7), housed in the same casing, the electronic terminal comprising: - Application processor (AP1) - A device for connecting the application processor to a public or private network (COMCT). - Security processor (SP1), the security processor including a cryptographic computing device - Data link (DB1, EXMEM), the data link being between the application processor and the security processor (SP1), - At least one display device (D3), said at least one display device enabling the application processor and the security processor to display images, and - Select Device (TMD, TPD), which enables a user to select all or part of the image displayed on the display device by the application processor. The electronic terminal is characterized in that it is configured to perform a copy function (SCB1a, SCB1b, SCB2a, SCB2b, S112, S212) upon a request from the user to copy data (ADD, IMADD) selected by the user from an image displayed by the application processor to a secure clipboard memory (CB2) accessible only to the secure processor (SP1).

2. The terminal according to claim 1, wherein the display device (D3) includes at least one secure display area (SD) controlled by the secure processor (SP1), and wherein the secure processor is configured to display (S112, S212) the data copied to the secure clipboard memory (CB2) on the secure display area (SD).

3. The terminal according to any one of claims 1 and 2, wherein the terminal is configured to, when performing the copy function to copy to the secure clipboard memory (CB2): Using the application processor (AP1), the text type data (ADD) selected by the user from the image displayed by the application processor is read (S103) from the system memory (SMEM1) of the application processor, and the text type data is transmitted (S111) to the security processor (SP1). - Using the security processor (SP1), the text type data is stored (S112) in the security clipboard memory (CB2).

4. The terminal according to any one of claims 1 to 3, wherein the application processor (AP1) is configured to send a request (S135) to the security processor (SP1) for an encrypted signature of data provided by the application processor, and wherein the security processor is configured to respond to the request for an encrypted signature: - Determine (S136) whether the data (ADD) existing in the secure clipboard memory is the same as the data (ADD) provided by the application processor, and - If the data (ADD) existing in the secure clipboard memory is not the same as the data (ADD) provided by the application processor, then the cryptographic signature is rejected (S160).

5. The terminal according to any one of claims 1 to 4, wherein the terminal is configured to, when performing the copy function to copy to the secure clipboard memory: Using the application processor (AP1), the image portion (IMADD) selected by the user from the image displayed by the application processor is read (S203) from the image memory (FBUF1) of the application processor, and the image portion (IMADD) selected by the user is transmitted (S211) to the security processor (SP1). - Using the security processor (SP1), the image portion (IMADD) is stored (S212) in the security clipboard memory (CB2).

6. The terminal according to any one of claims 1 to 5, wherein the application processor (AP1) is configured to send a request (S135) to the security processor (SP1) for an encrypted signature of data provided by the application processor, and wherein the security processor (SP1) is configured to respond to the request for an encrypted signature: - Present (S140, S240) the data (ADD, IMADD) existing in the secure clipboard memory on the display device, and - Wait for authorization from the user before providing the cryptographic signature.

7. The terminal according to any one of claims 1 to 6, wherein the terminal is configured to simultaneously display (S140, S240): - Data provided by the application processor (AP1) on the first area (NSD) of the display device (D3), and - Data (IMADD, ADD) provided by the security processor (SP1) on the second area (SD) of the display device (D3).

8. The terminal according to claim 7, wherein the terminal comprises: - A first display driver (DD1), which is connected to the application processor (AP1) to provide first image data (IDT1). - A second display driver (DD2), which is connected to the security processor (SP1) to provide second image data (IDT2). - A display selection circuit (MUX), controlled by the security processor (SP1) (SEL), the display selection circuit including a first input terminal connected to the output of the first display driver (DD1), a second input terminal connected to the output of the second display driver (DD2), and an output terminal connected to the display device (D3). And wherein the security processor (SP1) is configured to control (SEL) the display selection circuit (MUX) to display the data provided by the application processor (AP1) via the first display driver (DD1) on the first area (NSD) of the display device, and to display the data (IMADD, ADD) provided by the security processor (SP1) via the second display driver (DD2) on the second area (SD) of the display device.

9. The terminal according to claim 7, the terminal comprising an auxiliary processor (AUXP), the auxiliary processor being provided with a display driver (DD3) connected to the display device (D3), the auxiliary processor being connected to the application processor (AP1) and the security processor (SP1), and being controlled by the security processor (SP1) to display the data provided by the application processor (AP1) on a first area (NSD) of the display device (D3), and to display the data (IMADD, ADD) provided by the security processor (SP1) on a second area (SD) of the display device (D3).

10. The terminal according to any one of claims 1 to 9, wherein the selection device includes a touch module (TMD, TPD) connected to the application processor (AP1) and the security processor (SP1) via touch data routing circuitry (DMUX1, DMUX2), the routing circuitry being configured to send touch data (TDT) to the application processor or the security processor depending on a command (SEL, SEL2) issued by the security processor.

11. The terminal according to any one of claims 1 to 10, wherein the security processor (SP1) is a security element in the form of an integrated circuit.

12. The terminal (TL5, TL6) according to any one of claims 1 to 10, wherein the security processor (SP1) is a trusted execution environment (TEE1, TEE2) of the application processor (AP1).

13. The terminal according to any one of claims 1 to 11, wherein the security processor (SP1) is configured to execute a crypto asset hardware wallet application (WAP), and the application processor (AP1) is configured to execute a companion application (CAP) designed to work in conjunction with the crypto asset hardware wallet application.

14. The terminal according to claim 13, wherein: - The application processor (AP1) executing the accompanying application (CAP) is configured to send a request (S135) to the security processor (SP1) for a cryptographic signature of a transaction descriptor including a cryptographic asset account address (ADD), and - The security processor (SP1) executing the hardware wallet application (WAP) is configured to verify (S136) that the crypto asset account address (ADD) appearing in the descriptor is the same as the crypto asset account address existing in the secure clipboard memory before providing the cryptographic signature.

15. A method for conducting transactions related to crypto assets using a terminal according to any one of claims 1 to 14, the method comprising the steps of: - Configure the security processor (SP1) to execute the crypto asset hardware wallet application (WAP). - The application processor (AP1) provides a companion application (CAP) and an information source application (ISAP) designed to work in conjunction with the crypto asset hardware wallet application in the application memory (NVM). - Using the application processor (AP1) that executes the Information Source Application (ISAP), an image (IMG1) including the encrypted asset account address (ADD) is displayed on the display device. - Copy the encrypted asset account address (ADD, IMADD) (S109-S112, S209, S211, S212) to the secure clipboard memory (CB2) of the secure processor (SP1), and - Using the application processor (AP1) that executes the accompanying application, send (S135) the transaction descriptor to the security processor (SP1) and request the security processor to provide the cryptographic signature of the transaction.

16. The method according to claim 15, wherein the method comprises the following steps: The encrypted asset account address (IMADD, ADD) copied to the secure clipboard memory (CB2) is displayed (S112, S212) on the secure display area (SD) of the display device (D3) controlled by the security processor (SP1).

17. The method according to any one of claims 15 and 16, the method comprising the steps of: Using the security processor (SP1) executing the crypto asset hardware wallet application, verification (S136) is performed to confirm that the crypto asset account address present in the transaction descriptor provided by the companion application (CAP) is the same as the crypto asset account address present in the secure clipboard memory (CB2), and if the two addresses are different, the cryptographic signature is not provided.

18. The method according to any one of claims 15 to 17, the method comprising the following steps: Using the security processor (SP1) that executes the crypto asset hardware wallet application, the image portion (IMADD) stored in the secure clipboard memory (CB2) of the security processor (SP1) is displayed, and authorization from the user is awaited before the cryptographic signature is provided.

Images