Connected terminal including a secure clipboard memory exclusively controlled by a secure processor.

Abstract

Electronic terminal (TL2), comprising an application processor (AP1), a secure processor (SP1) including cryptographic computing means, at least one display device (D3), a selection device (TMD) enabling a user to select all or part of an image displayed on the display device by the application processor or by the secure processor, the terminal being configured to, at the user's request, perform a copy function into a secure clipboard memory (CB2) accessible only by the secure processor, of data (ADD) selected by the user in an image displayed by the application processor, the copy function comprising the following steps performed by the secure processor: copying into an image memory (FBUF2) of the secure processor an image (IMG1) displayed on the display device by the application processor, displaying the copied image on the display device,Select from the copied image data (ADD) designated by the user-operated selection device (TMD), and store the selected data in the secure clipboard memory. Figure 11,

Description

Title of the invention: Connected terminal comprising a secure clipboard memory exclusively controlled by a secure processor. Technical field

[0001] The invention relates to a connected electronic terminal comprising an application processor and a secure processor comprising cryptographic calculation means. The invention relates in particular to such an electronic terminal in which the secure processor is configured as a hardware wallet of cryptoassets and the application processor configured as a host device for the hardware wallet of cryptoassets. Background

[0002] In recent years, the development of cryptocurrencies or other types of cryptoassets managed by the blockchain, such as non-fungible tokens ("NFTs") and smart contracts, has given rise to various means of storing and preserving the private keys attached to these different types of cryptoassets. This is how the notions of "wallet", "cold storage" and "hot" storage of private keys appeared. A "wallet", also called a "currency holder", is a device or program whose function is to store the private keys attached to cryptoasset accounts. So-called "hot wallets" are connected to the Internet and susceptible to hacker attacks or exposure to viruses and malware. These may be wallets managed by exchange platforms, which do not offer the highest level of security.For example, many exchanges have been robbed of hundreds of millions of dollars by hackers 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 themselves susceptible to attack.

[0003] Cold wallets are the most secure solution for cold storage of private keys, i.e. away from any direct access to the Internet, which reduces the attack surface and therefore the risk of theft by hacking. Transactions involving private keys are signed in an offline environment. Any transaction initiated online is temporarily transferred to the offline hardware wallet, where it is then digitally signed before being transmitted to the online network. Since the private key is not communicated to the online server during the signing process, a hacker cannot access.

[0004] The simplest form of cold storage is passive storage. A passive wallet can be a paper document or an image file on which the user's public and private keys are written. Passive storage usually has an embedded QR code that can then be scanned to sign a transaction. The disadvantage of this medium is that if the passive storage is lost, illegible, or destroyed, the user can no longer access their funds.

[0005] Hardware wallets are a convenient alternative to passive wallets for storing private keys. Additionally, they are typically configured to generate recovery phrases to restore private keys if they are lost.

[0006] As shown in [Fig.l], an HW hardware wallet is never directly connected to the Internet. To be usable, the HW hardware wallet must be connected to an HDV host device by means of a LNK data link, for example USB or Bluetooth. The HDV host device may be a computer, a mobile phone or a tablet, and runs so-called "companion" software for conducting transactions on a BCN blockchain, such as the "Ledger Live" software developed by the applicant. Alternatively, the HW hardware wallet can be used, via the HDV host device with decentralized exchange platforms or "DEX", on which the user can carry out transactions while keeping his keys in the hardware wallet.

[0007] The host device HDV has a screen DI allowing the user to prepare transactions, and the hardware wallet HW itself has a screen or display D2, allowing in particular to present to the user information relating to a transaction about to be signed and therefore to be verified.

[0008] [Fig.2] shows the architecture of a HW hardware wallet of the type marketed by the applicant under the name Nano S®, described in more detail in the document https: / / developers.ledger.com / docs / nano-app / bolos-hardware-architecture. The HW hardware wallet comprises a secure element SE ("secure element") associated with a microcontroller MCU. Let us recall here that a secure element is a hardware platform comprising cryptographic calculation means CRY, generally a cryptographic coprocessor, and capable of storing and manipulating data in compliance with the security rules and requirements set by a trusted authority. A secure element is in the form of a semiconductor chip implementing various countermeasures aimed at countering attacks by fraudsters.The SE secure element has a secure OS operating system (firmware) designed to allow the installation and execution of APP applications (also called "application programs"), for example the . BOLOS® operating system developed by the applicant. The MCU microcontroller includes a USB interface U1 and has the function of allowing the secure element to communicate with an external host device HDV running companion software (see [Fig. 1]). The HW hardware wallet also includes a display D2 and two buttons B1, B2 managed by the MCU microcontroller for securing certain operations by user actions on these buttons. Other models of hardware wallets marketed by the applicant, such as the Stax®, include a large touch screen instead of a simple display.

[0009] Hardware wallets of the type mentioned above are therefore detached portable devices that do not include any means of connecting to the internet. To carry out a transaction, they must be temporarily connected to a "connected" host device, such as a mobile terminal or smartphone. The detached nature of these hardware wallets offers a higher degree of security because they are most of the time inaccessible via public networks, and therefore less exposed to attacks. However, this characteristic makes these hardware wallets not very ergonomic and likely to be misplaced or forgotten.

[0010] There is therefore a need to be able to integrate a hardware wallet into a mobile terminal platform, for example a mobile phone, to transform it into a mobile terminal with an embedded hardware wallet. Such a connected electronic terminal will comprise, arranged in the same housing, on the one hand a secure processor configured to fulfill the hardware wallet function and on the other hand an application processor comprising means for connecting to the Internet, capable of executing the companion application designed to carry out transactions on the blockchain, for example Ledger Live.

[0011] There is simultaneously a need to provide a solution to protect the user from the consequences of an attack on the unsecured processor that has allowed a fraudster to take control of the companion software. This, once corrupted, could then falsify the transaction without the user's knowledge.

[0012] Cryptoasset transactions have the specific feature of requiring the user to provide the CAP companion application with the address of the destination account with which they wish to carry out the transaction. However, this address is generally long and complex. It is generated from elliptic curve cryptography algorithms and hash functions and is composed of a set of alternating letters and numbers, for example: 0x388c818ca8b925 lb39313 lc08a736a67ccbl9297

[0013] Thus, the user rarely risks entering such an address manually, at the risk of making mistakes. Instead, he takes the address from a source application information, using the clipboard function of the host device, and then pasting it into the companion application. The information source application can be a website (internet browser), a messaging software (address received in a message), an email, a Web3 application, a game, etc.

[0014] This transfer of information from the source application to the companion application, via the application processor's clipboard, constitutes a potential vulnerability for the security of the transaction, which will be better understood by referring to Figures 3 and 4.

[0015] [Fig.3] shows a typical configuration for performing a cryptoasset transaction. The aforementioned hardware wallet HW, for example a NANO S, is connected to the aforementioned host device HDV, for example a mobile phone, via the LNK link, for example Bluetooth. The secure element SE of the hardware wallet HW executes a WAP hardware wallet application configured to sign a transaction when requested to do so by the host device HDV. The host device HDV comprises an application processor AP, for example the baseband processor of a mobile phone, which executes a companion application CAP, for example the Ledger Live application.

[0016] [Fig.4] describes steps for preparing the transaction up to its execution. In a step S00, the user “USER” goes to the ISAP information source application, for example an email in a messaging software. In a step S05, illustrated in [Fig.5A], the user selects in the ISAP application an ADD address of a crypto-asset account and activates the function of copying the ADD address to the clipboard. In a step S10, the application processor AP therefore stores the selected ADD address in a clipboard memory. In a step S15, the user goes to the companion application CAP and initiates steps for creating a transaction. In a step S20, illustrated in [Fig.5B], the user is invited by the CAP application to indicate in a description of the transaction what is the ADD address of the beneficiary account of the transaction.For this purpose, the user activates a paste function from the clipboard of the application processor AP to paste the ADD address into the transaction description displayed by the companion application CAP, as illustrated in [Fig.5C]. In a step S25, the user completes the transaction description in the companion application CAP and requests the execution of the transaction. The transaction description includes, for example, in addition to the ADD address, the crypto-asset type (“Currency”) and the transaction amount (“Amount”). In a step S30, the application processor sends the transaction description including the ADD address to the secure element SE and asks it to sign it. In a step S35, the secure processor SE executing the hardware wallet application WAP displays on the display D2 the ADD address that it received from the application processor, and . asks the user to validate the transaction. In a step S40, the user returns to the ISAP information source application to display the ADD address on the screen D1. In a step S45 illustrated in [Fig.5D], the user verifies that the ADD addresses displayed respectively on the screen D1 by the ISAP application and on the display D2 by the secure processor are identical, and validates the transaction, for example by means of the two buttons B1, B2 of the hardware wallet HW ([Fig.2]). In a step S50, the secure processor SE signs the transaction with the user's private key and sends the cryptographic signature to the processor AP. Generally, the signature relates to the complete description of the transaction, including at least the ADD address of the target account, the type of cryptoasset and the amount of the transaction. In a step S55, the application processor AP places the signed transaction, i.e. the transaction accompanied by its signature, on the blockchain concerned.The secure processor SE may also refuse to sign the transaction at a step S60, if the user does not validate the transaction within a determined time after step S40, or if the user decides to abandon the transaction.

[0017] In such a process of generating and signing a transaction, if the companion application has been corrupted by malware, an attack is possible at the moment when the user pastes the address into the companion application (step S20, [Fig. 5B]). If the companion application has been corrupted by malware, the copied address might not be the one that the user initially took from the ISAP information source application and stored in the clipboard memory. Due to the complexity of the address, the user may not notice that the address copied into the companion application has been altered. Subsequently, the companion application will provide the fraudulent address to the secure element SE. Then, during the comparison step S45 illustrated in [Fig.5D], the malware can display an address on the ISAP application that is identical to the corrupted address to trick the user into seeing that the two addresses are identical so that they validate the transaction.

[0018] It might therefore be desirable, particularly in the context of the integration of a hardware wallet of cryptoassets in a connected terminal, to provide a means of offering an additional degree of security in the preparation and execution of a transaction. Summary

[0019] Embodiments relate to an electronic terminal comprising, in the same housing, an application processor, means for connecting the application processor to a public or private network, a secure processor comprising cryptographic calculation means, a data link between the application processor and the secure processor, at least one display device, for enabling the application processor and the secure processor to display images, and a selection device enabling a user to select all or part of an image displayed on the display device by the application processor or by the secure processor, the terminal being configured to, upon request from the user, execute a copy function into a secure clipboard memory accessible only to the secure processor, of data selected by the user in an image displayed by the application processor, the copy function comprising the following steps executed by the secure processor: copying into an image memory of the secure processor an image displayed on the display device by the application processor, displaying on the display device the copied image, selecting in the copied image data designated by the selection device manipulated by a user,and store the selected data in the secure clipboard memory. ,

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

[0021] According to one embodiment, the secure processor is configured to take control of the display device and display the copied image on the display device in place of the original image displayed by the application processor on the display device.

[0022] According to one embodiment, the application processor is configured to provide the secure processor with the content of an image memory containing the image displayed on the display device by the application processor, and the secure processor is configured to copy into an image memory of its own the content received from the image memory of the application processor.

[0023] According to one embodiment, the secure processor is configured to take image data provided by the application processor to the display device and reconstruct the image displayed by the application processor from the taken data, to obtain the copied image, and store the copied image in its image memory.

[0024] According to one embodiment, the secure processor is configured to apply an optical character recognition algorithm to the copied image or to a portion thereof, to extract therefrom text-type data designated by the selection device manipulated by a user, and to store the text-type data in the secure clipboard memory.

[0025] According to one embodiment, the secure processor is configured to cut or crop the copied image, so as to retain only a portion of the image designated by the selection device manipulated by a user.

[0026] According to one embodiment, the secure processor is configured to apply an optical character recognition algorithm to the image portion, to obtain the text-type data, and store the text-type data in the secure clipboard memory.

[0027] According to one embodiment, the secure processor is configured to store the image portion in the secure clipboard memory.

[0028] According to one embodiment, the application processor is configured to address to the secure processor a request for cryptographic signature of data provided by the application processor, and the secure processor is configured to, in response to the cryptographic signature request, determine whether the data present in the secure clipboard memory is identical to data provided by the application processor, and refuse to provide the cryptographic signature if the data present in the secure clipboard memory is not identical to the data provided by the application processor.

[0029] According to one embodiment, the application processor is configured to send to the secure processor a cryptographic signature request, and wherein the secure processor is configured to, in response to the cryptographic signature request, present on the display device the data stored in the secure clipboard memory, and wait for authorization from the user before providing the cryptographic signature.

[0030] According to one embodiment, the terminal is configured to simultaneously display, on a first area of ​​the display device, data provided by the application processor, and on a second area of ​​the display device, the data provided by the secure processor.

[0031] According to one embodiment, the terminal comprises a first display driver connected to the application processor, providing first image data, a second display driver connected to the secure processor, providing second image data, a display selection circuit controlled by the secure processor, comprising a first input connected to an output of the first display driver and a second input connected to an output of the second display driver, and an output connected to the display device, the secure processor being configured to control the display selection circuit so as to display on the first zone of the display device the data provided by the application processor via the first display driver, and on the second zone of the display device the data provided by the secure processor via the second display driver.

[0032] According to one embodiment, the terminal comprises an auxiliary processor provided of a display driver connected to the display device, the auxiliary processor being connected to the application processor and to the secure processor and configured to display on the first area of ​​the display device the data provided by the application processor, and on the second area of ​​the display device the data provided by the secure processor.

[0033] According to one embodiment, the selection device comprises a touch module connected to the application processor and to the secure processor via a touch data bypass circuit, the bypass circuit being configured to send touch data to the application processor or to the secure processor according to a command issued by the secure processor.

[0034] According to one embodiment, the secure processor is a secure integrated circuit element.

[0035] According to one embodiment, the secure processor is a trusted execution environment of the application processor.

[0036] According to one embodiment, the secure processor is configured to execute a cryptoasset hardware wallet application and the application processor is configured to execute a companion application intended to cooperate with the cryptoasset hardware wallet application.

[0037] According to one embodiment, the application processor executing the companion application is configured to send to the secure processor a request for cryptographic signature of a description of a transaction including a cryptoasset account address, and the secure processor executing the hardware wallet application is configured to, before providing the cryptographic signature, verify that the cryptoasset account address appearing in the description of the transaction is identical to a cryptoasset account address present in the secure clipboard memory.

[0038] Embodiments also relate to a method for conducting a transaction relating to cryptoassets, by means of a terminal as described above, the method comprising the steps of configuring the secure processor to execute a cryptoasset hardware wallet application, providing in a program memory of the application processor a companion application intended to cooperate with the cryptoasset hardware wallet application, and an information source application; by means of the application processor executing the information source application, displaying on the display device an image comprising an address of a cryptoasset account; copying into the image memory of the secure processor, the image displayed by the application processor and comprising the address of the cryptoasset account;using the secure processor, displaying on the display device the copied image, instead of the original image; selecting, at; by means of the selection device manipulated by a user, in the copied image displayed by the secure processor, the address of the cryptoasset account, and store the address of the cryptoasset account in the secure clipboard memory of the secure processor; by means of the application processor executing the companion application, send to the secure processor a description of the transaction containing the address of the cryptoasset account, and request the secure processor to provide a cryptographic signature of the transaction.

[0039] According to one embodiment, the method comprises the step of displaying on a secure display area of ​​the display device controlled by the secure processor, the address of the cryptoasset account copied into the secure clipboard memory.

[0040] According to one embodiment, the step of selecting the address of the cryptoasset account comprises the step of applying an optical character recognition algorithm to the copied image or to a part thereof, to extract the address of the cryptoasset account therefrom.

[0041] According to one embodiment, the step of selecting, in the image displayed by the secure processor, the address of the cryptoasset account, comprises the step of cutting or cropping the copied image so as to retain only a part of the image designated by the selection device manipulated by a user.

[0042] According to one embodiment, the method further comprises the step of applying an optical character recognition algorithm to the image portion obtained by cutting or cropping the copied image.

[0043] According to one embodiment, the method comprises, by means of the secure processor executing the cryptoasset hardware wallet application, verifying that the address present in the description of the transaction provided by the companion application is identical to the address present in the secure clipboard memory, and not providing the cryptographic signature of the transaction if the two addresses are different.

[0044] According to one embodiment, the method comprises the steps of, by means of the secure processor executing the cryptoasset hardware wallet application, presenting on the display device the address of the cryptoasset account stored in the secure clipboard memory of the secure processor, and waiting for authorization from the user before providing the cryptographic signature of the transaction. Brief description of the drawings

[0045] Embodiments will be set out in the following description, given without limitation in relation to the attached figures among which:

[0046] [Fig.l] shows a typical example of using a hardware wallet through a host device,

[0047] [Fig.2] shows a classic hardware wallet architecture,

[0048] [Fig.3] shows the association of a hardware wallet and a host device for carrying out a cryptoasset transaction,

[0049] [Fig.4] depicts steps of a typical method of preparing and executing a transaction using the hardware wallet and host device of [Fig.3],

[0050] [Fig.5A], [Fig.5B], [Fig.5C] and [Fig.5D] depict steps of the method of [Fig.4],

[0051] [Fig.6] shows a first example embodiment of a terminal implementing a secure clipboard function according to a first and a second embodiment,

[0052] [Fig.7] shows a screen share between an application processor and a secure processor present in the terminal of [Fig.6],

[0053] [Fig.8] describes a method for preparing and executing a cryptoasset transaction using the terminal of [Fig.6] and using the first embodiment of the secure clipboard function,

[0054] [Fig.9] describes a method for preparing and executing a cryptoasset transaction using the terminal of [Fig.6] and using the second embodiment of the secure clipboard function,

[0055] [Fig.lOA], [Fig.lOB], [Fig.lOC], [Fig.lOD] and [Fig.lOE] illustrate steps of at least one of figures 8, 9, 12, 13, 15, 16,

[0056] [Fig. 11] shows a second exemplary embodiment of a terminal implementing a secure clipboard function according to a third and fourth embodiment,

[0057] [Fig. 12] describes a method for preparing and executing a cryptoasset transaction using the terminal of [Fig. 11] and using the third embodiment of the secure clipboard function,

[0058] [Fig. 13] describes a method for preparing and executing a cryptoasset transaction using the terminal of [Fig. 11] and using the fourth embodiment of the secure clipboard function,

[0059] [Fig. 14] shows a third exemplary embodiment of a terminal implementing a secure clipboard function according to a fifth and a sixth embodiment,

[0060] [Fig. 15] describes a method for preparing and executing a cryptoasset transaction using the terminal of [Fig. 14] and using the fifth embodiment of the secure clipboard function,

[0061] [Fig. 16] describes a method for preparing and executing a cryptoasset transaction using the terminal of [Fig. 14] and using the sixth embodiment of the secure clipboard function.

[0062] [Fig. 17] shows another exemplary embodiment of a terminal implementing a secure clipboard function according to any of the aforementioned embodiments,

[0063] [Fig. 18] shows yet another exemplary embodiment of a terminal implementing a secure clipboard function according to any of the aforementioned embodiments,

[0064] [Fig. 19] shows yet another exemplary embodiment of a terminal implementing a secure clipboard function according to any of the aforementioned embodiments, and

[0065] [Fig.20] shows yet another exemplary embodiment of a terminal implementing a secure clipboard function according to any of the aforementioned embodiments. Detailed description

[0066] As indicated above, an objective of the present disclosure is to integrate a hardware wallet of cryptoassets into a mobile electronic terminal such as a smartphone, tablet, or other type of connected mobile terminal. To this end, a terminal architecture is provided comprising at least one application processor, to which a secure processor is added. The secure processor is configured to play the role of a hardware wallet of cryptoassets, and the application processor is configured to play the role of host device with respect to the secure processor. This reconstitutes, inside the terminal, the functional separation between hardware wallet and host device, which is the one that offers the highest level of security because it allows the secure processor not to be connected to the internet during the cryptographic calculation, only the host device being exposed to attacks.Thus, the private key(s) of crypto-asset accounts held by the secure processor are protected against attacks.

[0067] The secure processor may be an independent secure element on a semiconductor chip or a trusted execution environment (TEE) of the application processor, as will be seen later with the help of examples. In such an architecture, each processor may have its own display screen or, on the contrary, the two processors may share the same screen. Similarly, regarding the selection of information on the screen or the entry of text by the user, each processor may have its own selection and entry device, such as a hardware keyboard associated with a touchpad, or a touch screen fulfilling the two functions of selection and entry of text. In an embodiment making it possible to reduce manufacturing costs and simplify the ergonomics of the terminal, the two processors share the same entry device.

[0068] Another objective of the present disclosure is to limit the risk of an attack of the type described above, at the time when data in the clipboard is transferred into the companion application. To this end, one idea of ​​the present disclosure is to allow a user to copy at any time, into a secure memory accessible only to the secure processor, information displayed by an unsecured application. Such a memory will subsequently be called, for convenience, "secure clipboard memory" or more simply "secure clipboard" because it is inaccessible to the application processor and therefore to an attacker. In the context of carrying out a transaction, it then becomes possible to copy into the secure clipboard the address of a target account displayed in an information source application.If the companion application has been corrupted by malware and alters the account address communicated to it, there will remain, in the secure clipboard, a genuine version of this address, having been "captured" or "photographed" at a time when the malware that took control of the companion application was not active since the copy was made before the companion software was called upon. In addition, this copy was made at a random time that is unpredictable for an attacker, who will instead be on the lookout for the moment when the user is going to copy the address of an account into the companion application, to substitute the address of a fraudulent account.

[0069] This secure version of the address can then be used to verify that the address communicated by the companion application to the secure processor to request it to sign the transaction is correct. Such verification involves a comparison between the address in the secure clipboard and the address presented by the companion application. Such a comparison can be visual, or be conducted by the secure processor, or both, as will be seen later.

[0070] Three main embodiments SCB1, SCB2, SCB3 of a method for implementing a secure clipboard in a device comprising an application processor and a secure processor will be described below. The secure processor comprises cryptographic calculation means and offers a level of security against physical or software attacks higher than that offered by the application processor. Each embodiment of the secure clipboard can be declined in two variants. Although described separately in the following, these embodiments and their variants are not mutually exclusive and can be implemented jointly in the same mobile terminal. They are distinguished only by the manner in which data is placed in the secure clipboard memory:

[0071] 1) In the SCB1 embodiment of the method, the secure processor stores in the secure clipboard a data that has been selected by the user in a image displayed by the application processor and which is provided to the secure processor by the application processor. In the first variant, this data is text data, for example an ADD address of a crypto-asset account. In the second variant, this data is an image part, for example an IMADD image part showing the ADD address of a crypto-asset account.

[0072] 2) In the SCB2 embodiment of the method, the secure processor receives from the application processor a complete image that is being displayed by the application processor. This image is then displayed by the secure processor, and the user selects the data that he wishes to place in the secure clipboard. In the first variant, this data is text data, for example an ADD address of a crypto-asset account. In the second variant, this data is part of an image, for example an IMADD image part showing the ADD address of a crypto-asset account.

[0073] 3) In the SCB3 embodiment of the method, the secure processor stores in the secure clipboard a complete image that is not provided by the application processor but is generated by itself, by "spying" on the image that the application processor is currently displaying. This image is then displayed by the secure processor, and the user selects the data that he wishes to place in the secure clipboard. In a first variant, this data is text data, for example an ADD address of a crypto-asset account. In a second variant, this data is part of an image, for example an IMADD image part showing the ADD address of a crypto-asset account.

[0074] [Table] Comparative table of different versions of secure clipboard Type Summary SCB1 text option Text data ADD is extracted by the application processor from the image it is displaying and then supplied by the application processor to the secure processor, which stores it in the secure clipboard memory SCB1 image option A part of an image IMADD is extracted by the application processor from the image it is displaying and then supplied by the application processor to the secure processor, which stores it in the secure clipboard memory SCB2 text option The application processor provides the secure processor with the complete image it is displaying. The secure processor then displays this image. Text data ADD is extracted by the secure processor from the image it is displaying and then stored in the secure clipboard memory. SCB2 image option The application processor provides the secure processor with the complete image that it displays. The secure processor then displays this image. An image part IMADD is extracted by the secure processor from the image it displays and is then stored in the secure clipboard memory. SCB3 text option The secure processor spies on the application processor and reconstructs the image that the latter displays. The secure processor then displays the copied image. Text data ADD is extracted by the secure processor from the copied image that it displays and is then stored in the secure clipboard memory. SCB3 image option The secure processor spies on the application processor and reconstructs the image that the latter displays. The secure processor then displays the copied image. An image part IMADD is extracted by the secure processor from the image that it displays and is then stored in the secure clipboard memory.

[0075] Various combinations of the above-mentioned variants may be provided, not all of which will be described below. For example, a variant with an image option may become a variant with a text option by applying an optical character recognition OCR function to the image portion, to extract text-type data therefrom, as will be seen below. This “text option” variant resulting from the “image option” variant through the intervention of an OCR function will be described below in relation to the second and third embodiments but is also applicable to the first embodiment.

[0076] [Fig.6] shows a first embodiment of a mobile terminal TL1 configured to implement the secure clipboard SCB1. The terminal comprises, arranged in the same housing (not shown), an API application processor, a secure processor SP1, and a touch screen. The touch screen comprises the superposition of a screen D3, for example LED or OLED, and a touch panel TMD. The API application processor comprises a port 101 connected to a port IO10 of the secure processor SP1 by a data bus DB1, for example of the SPI type.

[0077] The application processor comprises a central processing unit UC, a communication circuit COMCT, a non-volatile memory NVM, a volatile memory RAM, and a display driver circuit DD1 (Display Driver). The COMCT circuit allows 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 Wifi, GSM EDGE, 3G, 4G, 5G, etc.

[0078] The NVM memory comprises an operating system OS1, a companion application CAP (application program), and at least one source application information (messaging, web browser, game, etc.) through which the user can find information he will need, for example the ADD address of a crypto-asset account. The RAM memory includes an image buffer FBUF1 ("Frame Buffer"), a system memory SMEM1 and a clipboard memory CB1 or more simply a "clipboard" CB1. The image buffer FBUF1 contains pixel data PIX1 provided by the central unit, together forming an image IMG1 displayed by the application processor. This pixel data corresponds to source data stored in the system memory SMEM1. Thus, for example, text present in the form of an image in the image buffer FBUF1 can be extracted as editable text from the system memory SMEM1 by the application processor.The DD1 display driver receives the PIX1 data and provides IDT1 image data on a port 102 of the application processor, formatted according to a specific protocol compatible with the D3 screen, here the MIPI DSL format.

[0079] The operating system OS1 includes a conventional clipboard function, or non-secure clipboard NSCB, and a secure clipboard function SCBla. The secure clipboard function SCBla is a subroutine of the operating system which determines the actions assigned to the application processor for the implementation of the secure clipboard SCB1.

[0080] The secure processor SP1 comprises a central processing unit UC, a non-volatile memory receiving an operating system OS2 and a hardware wallet application WAP (application program), and a volatile memory comprising an image buffer FBUF2 and a secure clipboard memory CB2. The operating system OS2 itself comprises a secure clipboard function SCBlb, intended to cooperate with the function SCBla of the application processor to implement the secure clipboard SCB1. The secure clipboard function SCBlb is a subroutine of the operating system which determines the actions assigned to the application processor for the implementation of the secure clipboard SCB1.

[0081] The secure processor SP1 is equipped with a display driver DD2, here external to the processor SP1 but which can also be provided as a component integrated in the processor. The display driver DD2 provides the screen D3 with image data IDT2 in the appropriate format, here MIPI DSI, from pixel-type data PIX2 provided by the image buffer FBUF2 on a port IO11 of the secure processor to which the driver DD2 is connected. This data PIX2 forms an image IMG2 to be displayed provided by the secure processor. The secure processor is also equipped with at least one physical monostable button B and a visual indicator LD such as an LED. The monostable button B is operable by the user and is connected between a port input / output port 1020 of the secure processor and a low logic level, such as circuit ground. The visual indicator LD is connected between an input / output port 1021 and ground. In one embodiment, the secure processor is also equipped with a physical bistable switch S connecting an input / output port 1022 of the secure element eSE to a low logic level in a first position, and to a high logic level in a second position.

[0082] The use of the screen D3 is here shared between the application processor API and the secure processor SP1. Thus, the image data IDT1 supplied by the application processor via the display driver DD1 and the image data IDT2 supplied by the secure processor SP1 via the display driver DD2 are applied respectively to a first and a second input of a display selection circuit MUX, the output of which is applied to an input of the screen D3. The circuit MUX is controlled by a signal SEL supplied by a port IO12 of the secure processor SP1 which can therefore decide at any time to take control of the display and impose the display of the images IMG2 which it places in the buffer FBUF2.

[0083] In one embodiment of the MUX circuit, the signal SEL is a digital signal coded on several bits which allows the secure processor to indicate to the MUX circuit the number of lines of the screen which it wants to use to display its own information. The secure processor may thus wish to display an image which occupies the entire screen and replaces that which the secure processor wants to display, or an image which only occupies a few lines of the screen, for example to simultaneously display data held by the secure processor and data held by the application processor. In this second case, as shown in [Fig.7], the screen is divided into a non-secure display area NSD, in which the information provided by the application processor is displayed, and a secure display area SD, in which the information provided by the secure processor is displayed.This secure display area may in particular allow the contents of the secure clipboard to be displayed. Depending on the embodiment chosen, the extent of the secure area SD may be predetermined and fixed or variable. If this extent is fixed, it may be signaled to the user by a visual cue VM provided at the edge of the screen, for example a determined color bar. If this extent is variable, it may be signaled to the user by a row of LED diodes forming the visual cue VM, by lighting only the diodes which are located opposite the secure area, as shown for example in Figures 10A and 10D where a visual cue of variable extent is represented. Finally, when the secure processor uses the entire screen, it may signal this to the user by lighting the light indicator LD or any other indicator if the indicator LD is already used to signal to the user that the application processor is active.

[0084] In other embodiments, when the secure processor is running the WAP hardware wallet application and the application processor is running the CAP companion application, the secure processor uses only a portion of the screen and the other portion is reserved for the secure processor, thereby preventing the secure processor from overwriting certain data that the application processor would like to display while it is using the screen.

[0085] In still other embodiments where the SEL signal is coded on several bits to indicate the number of lines of the screen that the secure processor wants to use, the SEL signal is provided to the application processor ([Fig.6]) which is configured to dynamically adjust the size of the image that it provides to the MUX circuit in order to avoid that parts of these images are overwritten by the images provided concurrently to the MUX circuit by the secure processor.

[0086] The touch data TDT emitted by the touch panel TMD are here also shared between the application processor API and the secure processor SP1. Thus, the touch data TDT provided by the touch panel TMD are applied to the input of a bypass circuit DMUX1 having a first output connected to an input / output port IO3 of the application processor and a second output connected to an input / output port IO13 of the secure processor. The circuit DMUX1 is controlled by a signal SEL provided by the secure processor SP1 or a part of the signal SEL if the latter comprises several bits. Thus, in one embodiment, the signal SEL comprises a first signal SEL1 for controlling the circuit MUX, and a second signal SEL2 for controlling the circuit DMUX1 independently of the control of the circuit MUX. The secure processor can therefore decide at any time to receive the touch data TDT instead of the application processor.In one variation, the DMUX1 bypass circuit is not provided and the TDT touch data is provided to both the application processor and the secure processor, each knowing whether this data is relevant to it or not depending on what it is doing.

[0087] As indicated above, the application processor and the secure processor are configured to cooperate in order to implement the first embodiment SCB1 of the secure clipboard.

[0088] As illustrated in [Fig.7], when an application source of information ISAP displays information on the non-secure screen portion NSD, the user can select text or a part of an image (here the text "xyzxyzxyz"), with his finger using the touch panel TMD (or in other embodiments, with a pen or a mouse). The application processor then displays an extended clipboard menu ECBM ("Extended ClipBoard Menu") comprising, in addition to conventional "cut" or "copy" functions, a "copy SCB1" key for copying the selected text into the secure clipboard. The "copy SCB1" key can itself offer two options, namely copying the selection as text data or copying the selection as part of an image (not shown).

[0089] If the user opts for copying SCB1 to the secure clipboard, it is provided, in one embodiment, that the text or part of the image copied to the secure clipboard is automatically displayed by the secure processor in the secure display area SD, as shown in [Fig.7]. Thus, the user can immediately verify that the text or part of the image copied to the secure clipboard and displayed on the area SD is identical to the text or part of the image that he has selected in the ISAP application.

[0090] With reference to Figures 6 and 7, when the secure copy function SCB1 with the “text” option is activated by the user after the latter has selected a data item in an image displayed by the application processor (here “xyzxyzxyz”), the application processor identifies in its system memory SMEM1 the text type data item corresponding to the data item selected in the image, and copies this data item into the clipboard memory CB1. The application processor then indicates to the secure processor, via the bus DB1, that the user has requested to copy a data item into the secure clipboard. After approval by the secure processor, the application processor transfers the data item “xyzxyzxyz” to it as text type data item and the secure processor saves it in the secure clipboard memory CB2.Then, preferably, the secure processor displays the data "xyzxyzxyz" in the secure display area SD, which allows the user to ensure that the copied data is identical to the data displayed by the ISAP application in the non-secure display area NSD ([Fig.7]).

[0091] In some embodiments, a user action may be required to validate the definitive recording of the data in the secure clipboard. This action is preferably an action on a secure organ, i.e. controlled by the secure processor, for example button B. It will be noted here that the action of validating the definitive recording of the data in the secure clipboard may cover various embodiments, for example an embodiment in which the data is placed in a buffer register of the secure processor during its display, instead of being directly placed in the secure clipboard memory. In this case, the secure processor only stores it in the secure clipboard memory after receiving the user's agreement.

[0092] The display of the data in the SD display area may be interrupted at any time after receipt of the user's consent, or, alternatively, according to one of the following options or combination of these options:

[0093] - the display is maintained for a time Tdmax determined by the processor secure, or

[0094] - the display ends when the user requests it by means of a key unsecured function provided for this purpose, or

[0095] - the display in the SD display area ends when the user exits the information source application in the NDS display area to go to another application, for example the CAP companion application.

[0096] Once copied into the secure clipboard, the data is completely secure and cannot be altered by an attack targeting the application processor and in particular the CAP companion application.

[0097] In the above-mentioned variant of the secure clipboard function, the user activates the secure copy function SCB1 with the "image" option after having selected, in an image displayed by the application processor, an image part containing an address ADD. In this case, the application processor identifies in the image buffer FBUF1 the image part IMADD selected by the user and copies it into its clipboard memory CB1. The application processor then establishes communication with the secure processor via the bus DB1, and indicates to it that the user has requested to copy an image type data item into the secure clipboard. After approval by the secure processor, the secure processor transfers the image part IMADD to it and the secure processor saves it in its secure clipboard memory CB2 and displays it on the secure display area SD.From this moment on, the IMADD image part copied by the user is completely secure and cannot be altered by an attack targeting the application processor and in particular the CAP companion application.

[0098] The secure clipboard function can have various uses and in particular the securing of the preparation and execution of a transaction, which will be described further now.

[0099] In the context of preparing and executing a transaction, the user uses the secure clipboard memory to place an ADD address of a crypto-asset account with which he wishes to carry out the transaction. Depending on the chosen embodiment of the secure clipboard, this ADD address will be copied into the secure clipboard as text data, or as part of an IMADD image containing the ADD address.

[0100] Schematically, the application processor and the secure processor work together to prepare and execute the transaction as follows:

[0101] 1) the application processor executing the companion CAP application prepares the transaction by asking the user to provide a description of the transaction,

[0102] 2) the application processor then sends the description of the transaction to the secure processor, so that it signs the transaction.

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

[0104] Generally, before being signed, the description of the transaction is first transformed by the secure processor into a “raw transaction”, namely a string of binary or hexadecimal data capable of being signed.

[0105] The description of the transaction can take various forms depending on the type of transaction concerned. For example, the description of a transaction concerning rEthereum can take the following form:

[0106] {

[0107] "coin": "eth"

[0108] "addr": "0x388c818ca8b9251b393131c08a736a67ccbl9297",

[0109] "sender": "0x473780deaf4a2ac070bba936b0cdefe7f267dfc",

[0110] "amount": "0.000567202182620675", [YES] "maxGas": "0.00000005"

[0112] }

[0113] The transaction description according to the example above, when transformed into a raw transaction, can for example be presented as follows (in hexadecimal):

[0114] f86e826f4a8505f901eadd826b6c94388c818ca8b9251b393131c08a736a67ccbl92978 801167140fda3d0818025a0dcbal464c58f31892bd0ae8e6271f83 8189cd344d98e928f3 194efe4bce9ebc6a04fOfc71bee74ala6fafbel7cde3c35981c93b58703856ef5dd53884alb 153773

[0115] The signature algorithm used by the secure processor is specific to the blockchain in question. For example, Bitcoin and Ethereum blockchains use the ECDSA / secp256kl / SHA256 algorithm as a means of signature, i.e. a signature generated with the ECDSA algorithm (Elliptic Curve Digital Signature Algorithm) configured with the secp256kl parameter, including a prior hashing of the raw transaction using the SHA-256 (Secure Hash Algorithm) function to obtain the “hashcode” or digest of the transaction. This algorithm produces signatures of the following type:

[0116] {

[0117] "r"

[0118] "0xb91467e570a6466aa9e9876cbcd013baba02900b8979d43fe208a4a4f339f5fd",

[0119] "s":

[0120] "0x60 07e7 4cd82e037b8 0018 6422fc2dal67c7 4 7ef04 5e5dl8a5f5d4 300f8ela02 9"

[0121] "v": 28

[0122] }

[0123] The transaction description and the transaction signature are then transmitted by the application processor to a broadcast service which ensures the broadcast of the transaction on the relevant blockchain.

[0124] For the sake of simplification of the language, the terms “transaction”, “descriptions of the transaction”, or “raw form of the transaction” may here or hereinafter have the same meaning. Furthermore, no limiting meaning is given to the terms “description of the transaction”, “transaction”, “signature of the transaction”, which may vary widely depending on the cryptoasset considered and the blockchain concerned. In the case in particular of a cryptoasset of the “smart contract” type, the description of the transaction may include a higher number of parameters than the description of a simple transaction in Bitcoin or Ethereum. In all cases, the secure processor is preferably configured to present to the user all of the parameters of the transaction in application of the “WYSIWYS” principle (“What You See Is What You Sign”).

[0125] The use of the secure clipboard in the preparation and execution of a cryptoasset transaction will be better understood by referring to the flowcharts in Figures 8 and 9 which describe two examples of preparing and executing a cryptoasset transaction. The following notation is used in Figures 8 and 9:

[0126] - “USER” means a user,

[0127] - “AP1-USER” refers to an action of the API application processor in response to a user request,

[0128] - “API-CAP” refers to an action of the API application processor executing the companion application, or an action performed by the companion application using the API application processor,

[0129] - “SP1-WAP” refers to an action of the SP1 secure processor executing the WAP hardware wallet application, or an action performed by the WAP hardware wallet application using the secure processor API,

[0130] - "goes into" or "returns into" means that the user goes into or returns in the graphical interface of the application concerned (display in a window or in full screen) to do something: read information, select displayed data, delete it, copy it to a clipboard memory, or paste data stored in a clipboard memory.

[0131] In the embodiment of [Fig.8], the secure clipboard function SCB1 is used to copy an ADD address as text data. In a step S100, the user goes to an ISAP information source application, for example a web page or an email containing the ADD address of a cryptoasset account. In a step S102, illustrated in [Fig.10A], the user selects the ADD address as text data, and activates the NSCB copy function in the unsecured clipboard. In a step S103, the API application processor reads the selected address ADD from its system memory SMEM1. In a step S104, the API application processor stores the address ADD in the clipboard memory CB1. In a step S109, also illustrated in [Fig. 10A], the user activates the function SCB1 for copying to the secure clipboard. In a step SI 10, the API application processor establishes communication with the secure processor SP1. In a step SI 11, the API application processor transmits the address ADD present in the clipboard memory CB1 to the secure processor SP1. At a step SI 12, the secure processor SP1 stores the address ADD in the secure clipboard memory CB2 and preferably displays it on the secure area SD of the screen, as shown in [Fig. 10A], so that the user can verify that the source address and the copied address are identical.As mentioned above, user consent may be required here to validate the saving of the ADD address to the secure clipboard. This consent is preferably given via a secure device such as the B button.

[0132] In a step S115, the user goes to the companion application CAP. In a step S120, the application processor API, at the request of the user, pastes the address ADD into a description of the transaction to be entered by the user and displayed by the companion application CAP. The address ADD is pasted into the companion application CAP from the unsecured clipboard memory CB1, as illustrated by FIGS. 10B and 10C. In a step S125, the user completes the description of the transaction proposed by the companion application CAP and requests the execution of the transaction. The entry of information by the user is here done by means of a virtual keyboard displayed on the screen D3, the touch panel TMD being here used both as a means of selecting information and as a means of entering information.In other variants, the terminal may be equipped with a physical keyboard and the information selection may be made by means of a touchpad separate from the screen D3. In a step S135, the application processor API executing the companion application CAP sends the secure processor SP1 the transaction description including the ADD address and asks it to sign it. In a step S136, the secure processor SP1 executing the hardware wallet application WAP verifies that the received ADD address is identical to the ADD address in the secure clipboard memory CB2. If the addresses are different, the secure processor goes to a step S160, otherwise goes to a step S140. In step S140, illustrated in [Fig.lOD], the secure processor SP1 running the WAP hardware wallet application displays on the secure display area SD the description of the transaction including the ADD address, and optionally the ADD address present in the secure clipboard, and asks the user to validate the transaction. In a step S145, the user verifies. optionally that the ADD address displayed on the non-secure display area NSD and the ADD address displayed on the secure display area SD are identical, before validating the transaction using button B, otherwise indicates to the secure processor that it refuses the transaction, for example by means of a touch key since the TDT data provided by the touch panel TMD are received by the secure processor during this validation phase. In a step S150, if the user has validated the transaction, the secure processor SP1 executing the WAP hardware wallet application signs the transaction and sends the signature to the API application processor. In a step S155, the API application processor executing the companion application CAP places the transaction on the relevant blockchain. In step S160, the secure processor SP1 refuses to sign the transaction.This step is executed if the user has rejected the transaction, or if a maximum time limit for waiting for their agreement has been exceeded, or if the secure processor has found that the address presented to it is different from the one present in the secure clipboard.

[0133] Those skilled in the art will note that the embodiment of the secure clipboard uses the non-secure clipboard memory of the application processor as an intermediate storage memory for the ADD data, before transmitting its contents to the secure processor for storage in the secure clipboard memory. In variants, the ADD data, before being transmitted to the secure processor, could be stored in a memory area other than that serving as non-secure clipboard memory. In other variants, the data could be encrypted before being communicated to the secure processor via the DB1 bus.

[0134] In the embodiment of [Fig.9], the secure clipboard function SCB1 is used to copy an address as an image part IMADD. The steps already described in relation to [Fig.8] are designated by the same references. In step S100, the user goes to an information source application ISAP. In a step S202, the user selects the address ADD of a cryptoasset account as an image part IMADD, and activates a function NSCB of the secure processor, for copying an image to the non-secure clipboard. In a step S203, the application processor API reads the image part IMADD from its image buffer FBUF1. In a step S204, the application processor API stores the image part IMADD in the clipboard memory CB1. In step S209, the user activates the SCB1 function for copying to the secure clipboard.In step S110, the application processor API establishes communication with the secure processor SP1. In a step S211, the application processor API transmits the image portion IMADD to the secure processor SP1. In a step S212, the secure processor SP1 stores the image portion IMADD in the secure clipboard memory CB2 and displays it on the secure display area SD, so that the user can check it. As pre . Previously, the user's agreement may here be required to validate the recording of the address ADD in the secure clipboard. This agreement is preferably given via a secure device such as button B. The user then repeats steps S102, S103 and S104 described in relation to [Fig. 8] to copy the address ADD as text data into the unsecure clipboard CB1 of the application processor. In step S115, the user goes to the companion application CAP. In step S120, the application processor API, at the user's request, pastes the address ADD into the companion application CAP from the unsecure clipboard memory CB1, as previously described. In a step S125, the user completes the description of the transaction in the companion application CAP and requests the execution of the transaction.In step S135, the application processor API executing the companion application CAP sends to the secure processor SP1 the description of the transaction to be signed and including the address ADD. In a step S240 illustrated in [Fig. 10D], the secure processor SP1 executing the hardware wallet application WAP displays on the secure display area SD the description of the transaction including the address ADD, as well as the image part IMADD, and requests the user to validate the transaction. In a step S245, the user verifies that the address ADD in the description of the transaction and the address ADD appearing in the image part IMADD are identical, and validates the transaction, otherwise indicates to the secure processor that he wants to cancel it. In step S150, the secure processor SP1 executing the hardware wallet application WAP signs the transaction and sends the signature to the application processor API.In a step S155, the API application processor executing the companion application CAP places the transaction on the blockchain. In step S160, the secure processor SP1 refuses to sign the transaction if a maximum waiting time for user validation is exceeded or if the user has indicated that he is canceling the transaction.

[0135] Like the previous one, this embodiment is susceptible to variations with regard to the storage of the IMADD image part before its transfer to the secure processor. Furthermore, the secure processor could apply an OCR processing to the IMADD image part to extract the ADD address as text type data, then execute the comparison step S136 which was described in relation to [Fig.8] and which is absent in the flowchart of [Fig.9].

[0136] [Fig. 11] shows an embodiment of a terminal TL2 configured to implement the secure clipboard method SCB2, in which the entirety of an image IMG1 displayed by the application processor is transferred to the secure processor. The terminal TL2 has the same structure as the terminal TL1 which will not be described again. It differs from the terminal TL1 in that the operating system OS1 of the application processor comprises, in addition to the functions of non-secure clipboard NSCB and secure clipboard SCBla, a secure clipboard SCB2a function. This SCB2a function is intended to cooperate with a complementary SCB2b function provided in the OS2 operating system of the secure processor. As a further difference, the secure processor SP1 includes in its non-volatile memory a system memory area SMEM2 intended to receive a copy of a part of the system memory area SMEM1 of the secure processor containing the system data associated with the image IMG1 transferred by the application processor to the secure processor when the user activates the copy function SCB2.

[0137] The activation of the SCB2 copy function in the secure clipboard CB2 is as before under the control of the application processor, which for example displays the option "SCB2 copy" in the extended clipboard ECBM menu, as illustrated in the modified [Fig.7] or in [Fig.10A]. The user can choose in the ECBM menu between the unsecure clipboard, the secure clipboard SCB1 or the secure clipboard SCB2.

[0138] Activation of the secure clipboard SCB2 causes the application processor to transfer to the application processor, via the bus DB1, the entire displayed image IMG1, which is located in the image buffer FBUF1. The application processor then transfers to the secure processor the corresponding system data that it holds in its system memory SMEM1. The secure processor stores the image IMG1 in its image buffer FBUF2 and the data retrieved from the system memory SMEM1 in its own system memory SMEM2. The secure processor then takes control of the entire screen D3 as well as control of the touch panel TMD by giving the signal SEL the appropriate value, then displays the image IMG1 and invites the user, by means of a floating or retractable message, to select the part of this image that interests him.It should be noted that when the user activates the copy function in the secure clipboard SCB2, the switching from the image IMG1 displayed by the application processor to the same image IMG1 displayed by the secure processor which has taken control of the screen D3, is not perceptible by the user. In order to reassure the user and confirm to him that he is in a secure space where he can extract the data ADD or cut out the part of image IMADD which interests him, the secure processor can light the visual indicator LD, or activate any other means allowing the user to know that the displayed image is under the control of the secure processor.

[0139] The use of the SCB2 secure clipboard in the preparation and execution of a cryptoasset transaction will be better understood by referring to the flowcharts in Figures 12 and 13 which describe two examples of preparation and execution of a cryptoasset transaction.

[0140] In the embodiment of [Fig. 12], the secure clipboard function SCB2 is used to copy an ADD address as text data. The steps already described in relation to [Fig. 8] or 9 are designated by the same references.

[0141] In step S100, the user goes to an ISAP information source application. In a step S300, the user activates the SCB2 function for copying to the secure clipboard. In step S110, the application processor API establishes communication with the secure processor SP1. In a step S310, the application processor API transfers to the secure processor SP1 the image IMG1 present in the image buffer FBUF1. In a step S311, the secure processor SP1 stores the image IMG1 in the image buffer FBUF2. In a step S312, the application processor API transfers to the secure processor SP1 system data linked to the image IMG1 present in the system memory SMEM1. In a step S313, the secure processor SP1 stores the system data in its system memory SMEM2. At a step S320, the secure processor SP1, after taking control of the screen D3, displays on the screen D3 the copied image IMG1 instead of the original image. As illustrated in [Fig.lOE], the entire screen becomes in this case the secure display area SD, as shown by the indicator VM. In a step S322, the user selects in this image the ADD address of a cryptoasset account as text data, and validates his selection. The touch data are here received by the secure processor which has taken control of the branch circuit DMUX1. In a step S340, the secure processor SP1 reads from the system memory SMEM2 the ADD address selected by the user. In step SI 12, the secure processor SP1 stores the ADD address in the secure clipboard memory CB2 and displays it on the lower part of the secure display area SD. The result is therefore the same as in step SI 12 of [Fig.8] but from an extraction of the ADD data made in an image displayed by the secure processor.It should be noted, however, that since the selection of the ADD address is made by the secure processor, the display of the ADD address in the lower part of the secure display area SD might not be expected. Similarly, user agreement via a secure organ might not be required to validate the recording of the ADD address in the secure clipboard.

[0142] At a step S345, the user returns to the ISAP information source application. The user then repeats steps S102, S103 and S104 described in relation to [Fig. 8], to copy the ADD address as text data into the unsecured clipboard. After this step, the method comprises steps S115, S120, S125, S135, S136, S140, S145, S150, S155 and S160 already described in relation to [Fig. 8].

[0143] In the embodiment of [Fig. 13], the secure clipboard function SCB2 is used to copy an address as part of an IMADD image. The steps already described in connection with Figures 8, 9 and 12 are designated by the same references.

[0144] In step S100, the user goes to an ISAP information source application. In a step S300, the user activates the SCB2 function for copying to the secure clipboard with the “image copy” option. In step S110, the application processor API establishes communication with the secure processor SP1. In a step S310, the application processor API transfers to the secure processor SP1 the image IMG1 present in the image buffer FBUF1. In a step S311, the secure processor SP1 stores the image IMG1 in the image buffer FBUF2. In step S320, the secure processor SP1 takes control of the screen and displays on the screen D3 the copied image IMG1 instead of the original image. As illustrated in [Fig.10E], the entire screen in this case becomes the SD secure display area, as shown by the VM indicator.In a step S422, the user selects in the copied image the address ADD of a cryptoasset account as image part IMADD, and validates his selection, which is received by the secure processor in the form of touch data TDT. In step S341, the secure processor SP1 by means of the function TRIM ([Fig.l 1]) for cutting or cropping an image, cuts out the image part IMADD selected by the user in the copied image IMG1. In step S212, the secure processor SP1 stores the image part IMADD in the secure clipboard memory CB2 and displays it on the lower part of the secure display area SD. The result is therefore the same as in step S212 of [Fig.9] but from an extraction of the ADD data made in an image displayed by the secure processor. As before, the display of the ADD address in the lower part of the SD secure display area might not be expected.Similarly, user consent may not be required to validate saving the ADD address to the secure clipboard.

[0145] The method then comprises the succession of steps S345, S102, S103, S104, S115, S120, S125, S135, S240, S245, S150, S155, and S160 already described in relation to [Fig.9].

[0146] In one embodiment of the secure clipboard SCB1 or the secure clipboard SCB2, the user first places the secure processor in an active mode by means of the bistable switch S. Once in the active mode, the secure processor activates a communication channel with the application processor via the bus DB1 so that the two processors are ready to communicate. The user then indicates to the secure processor that he wants to copy to the secure clipboard SCB1 or SCB2 by pressing the button B which is under the control of the secure processor. The secure processor then sends to the application processor a request to copy to the secure clipboard, following which the application processor displays the function icon SBC1 or SCB2 (or both) in the extended clipboard menu ECBM (“Extended ClipBoard Menu”) as shown in [Fig.7] or [Fig.10A].

[0147] This activation mode allows the secure processor to control the triggering of the copy process in the secure clipboard and to ensure that the copy request actually comes from the user. This makes it possible, for example, to prevent a malicious program from initiating the copy in the secure clipboard itself and / or from carrying out an endless loop of recordings in the secure clipboard. For this purpose, the secure processor can be configured to accept only a single action of storing data after a user action on button B followed by an action on the function icon SBC1 or SCB2 displayed by the application processor.

[0148] It will be noted that several other buttons such as button B or other switches such as switch S may be provided for the purposes of implementing the secure clipboard. The secure processor, once placed in the active mode, may also control data provided by a touchscreen keyboard in which dedicated function keys for the secure clipboard are provided, which replace button B. A touchscreen keyboard dedicated to the secure processor may also be provided.

[0149] [Fig. 14] shows an embodiment of a terminal TL3 configured to implement the secure clipboard function SCB3 with the text copy option or the image copy option. The terminal TL3 has the same structure as the terminals TL1, TL2 which will not be described again. The terminal TL3 differs from the terminal TL2 in that the operating system OS2 of the secure processor includes, in addition to the secure clipboard functions SCBlb, SCB2b which have been retained here but could be omitted, the secure clipboard function SCB3. This function is independent of the application processor which therefore does not have any corresponding function in its operating system OS1.Indeed, as explained above, this embodiment of the secure clipboard function is based on the reconstitution of the image IMG1 displayed by the application processor without its knowledge, by taking the image data provided by the application processor on the screen D3. The user will then select from this image, with the exclusive help of the secure processor and without intervention of the application processor, an address ADD of text type or a part of image IMADD comprising this address.

[0150] Therefore, the SCB3 copy function cannot be activated from a virtual button displayed by the D3 / TMD touch screen, since it operates without the knowledge of the application processor. A specific button connected to the secure processor is therefore preferably provided to activate the SCB3 function. For example, as illustrated in [Fig.14], button B can again be used as the activation button of the SCB3 function. It will be noted that this use of button B does not prevent it from being used later as a transaction validation button, although other similar buttons could also be provided. In one embodiment, the secure processor has been previously placed in the active mode described above, by means of switch S.

[0151] As another difference, the secure processor SP1 is equipped with a decoding circuit DECCT of an intermediate image buffer FBUF3. The decoding circuit DECCT is used as a spy circuit and has an input connected to the first input of the selection circuit MUX, which receives the image data IDT1 in MIPI DSI format supplied by the application processor. This data is decoded by the circuit DECCT which extracts pixel type data PIX1, i.e. those supplied by the application processor to its display driver DD1, and analyzes this data to deduce the start and end of the image IMG1. The circuit DECCT thus reconstructs line by line the image IMG1 which it stores in the intermediate buffer FBUF3.When the image IMG1 has been completely reconstructed, the secure processor transfers it into the buffer FBUF2, takes control of the screen D3 via the selection circuit MUX, configures the circuit DMUX1 to receive the touch data and invites the user to select the area of ​​his choice. The secure processor also includes a TRIM function for cutting or cropping the reconstructed image, similar to that used by the terminal TL2 of [Fig. 11], and providing the image part IMADD. The secure processor also includes an OCR function applicable to the text copy option, allowing it to extract text data, in particular an address ADD, from the image part IMADD selected by the user.

[0152] The use of the SCB3 secure clipboard in the context of carrying out a cryptoasset transaction will be better understood by referring to the flowcharts in Figures 15 and 16 which describe two examples of preparing and executing a cryptoasset transaction.

[0153] In the embodiment of [Fig. 15], the secure clipboard function SCB3 is used to copy an ADD address as text data. The steps already described in relation to FIGS. 8, 9, 12, 13 are designated by the same references.

[0154] In step S100, the user goes to an information source application ISAP. In a step S400, the user activates with button B the function SCB3 for copying to the secure clipboard. In a step S410, the circuit DECCT takes the image data IDT1 supplied by the application processor API, decodes them and reconstructs the image IMG1 in the intermediate image buffer FBUF3. In a step S420, the secure processor SP1 transfers the copied image IMG1 into the image buffer FBUF2. In step S320, the secure processor SP1 displays on the screen D3 the image copied image IMG1 instead of the original image. As illustrated in [Fig.10E], the entire screen in this case becomes the secure display area SD, as shown by the indicator VM. In a step S422, the user selects in the copied image the address ADD of a crypto-asset account as the image part IMADD, and validates his selection. In step S341, the secure processor SP1 with the function TRIM cuts the image part IMADD in the copied image IMG1 according to the selection by USER. In a step S443, the secure processor SP1 extracts the address ADD from the image part IMADD with the function OCR. In step SI 12, the secure processor SP1 stores the address ADD in the secure clipboard memory CB2 and displays it on the lower part of the secure display area SD, the result being similar to that of steps SI 12 of the other embodiments of the method, but being obtained in a different way.Since this embodiment is end-to-end secure, the display of the copied address on the lower part of the secure display area SD is here purely optional, although it can be provided for user information reasons. Similarly, the user's agreement to validate the recording of the ADD address in the secure clipboard is purely optional from a security perspective, but can be provided for ergonomic reasons.

[0155] The following steps have already been described. Before being executed, the secure processor temporarily returns control of the screen D3 to the application processor. In step S345, the user returns to the information source application ISAP. The user then repeats steps S102, S103 and S104 described in relation to [Fig. 8] to copy the address ADD as text data into the unsecured clipboard. In step S115, the user goes to the companion application CAP. In step S120, the application processor API, at the user's request, pastes the address ADD into the companion application CAP from the unsecured clipboard memory CB1. In step S125, the user completes the transaction description in the companion application CAP and requests execution of the transaction.In step S135, the application processor API executing the companion application CAP sends to the secure processor SP1 the description of the transaction to be signed and including the ADD address. In step S136, the secure processor SP1 executing the hardware wallet application WAP verifies that the received ADD address is identical to the ADD address in the secure clipboard memory CB2. In step S140, the secure processor SP1 executing the hardware wallet application WAP displays on the secure display area SD the description of the transaction containing the ADD address, and optionally displays the ADD address present in the secure clipboard, then asks the user to validate the transaction. In step S145, the user optionally verifies that the ADD address displayed on the non-secure display area NSD and the ADD address displayed on the display area . secure SD are identical, before validating the transaction. In step S150, the secure processor SP1 running the WAP hardware wallet application signs the transaction and sends the signature to the API application processor. In step S155, the API application processor running the CAP companion application places the transaction on the blockchain. If the user's waiting time has been exceeded, or if the user cancels the transaction, or if the displayed ADD addresses are different, the secure processor SP1 refuses to sign the transaction in step S160.

[0156] In a variant of the method which has just been described, the secure processor applies an OCR treatment to the whole of the image IMG1 before proposing to the user to cut out the text type data which he wishes.

[0157] In the embodiment of [Fig. 16], the secure clipboard function SCB3 is used to copy an address as part of an IMADD image. The steps already described in connection with FIGS. 8, 9, 12, 13, 15 are designated by the same references.

[0158] The first steps S100, S400, S410, S420, S320, S422, S341 of the method of [Fig. 16] are the same as those of the method of [Fig. 15]. After the cutting step S341, the OCR processing step S443 is deleted. After step S341, the image part IMADD is stored in the secure clipboard memory CB2 in step S212 and is displayed on the lower part of the secure display area SD. Since this embodiment is also end-to-end secure, the display of the image part IMADD on the lower part of the secure display area SD is also optional here, as well as the user's agreement to validate the saving of the image part IMADD in the secure clipboard. The following steps S345, S102, S103, S104, S15, S120, S125, S135, S240, S245, S150, S155 and S160 are identical to those of the method of [Fig. 13].

[0159] It will be apparent to those skilled in the art that the secure clipboard method just described is susceptible to various other variants. Although this method was designed in relation to the integration of a hardware wallet function in a terminal, in order to make the preparation and execution of a transaction more secure, the secure clipboard function just described is susceptible to various other applications. Furthermore, the application processor may be any known component of the microcontroller type or set of components forming a semiconductor system on chip or "SOC" ("System on Chip"). The secure processor may itself be a secure element on a semiconductor chip, to which certain peripheral elements have been added if it does not include them originally. The secure processor may also be a trusted execution environment TEE ("Trusted Execution Environment") of the application processor.

[0160] The mobile terminal architecture which has just been described is itself capable many variants of execution. In a TL4 variant of the terminal shown in [Fig. 17], the MUX selection circuit has been replaced by an auxiliary processor AUXP which drives the screen D3 via a display driver DD3 providing image data in MIPI DSI format. The auxiliary processor AUXP receives the pixel-type data PIX1 supplied by the buffer FBUF1 of the application processor, and the pixel-type data PIX2 supplied by the buffer FBUF2 of the secure processor. It is configured by programming to form a kind of software multiplexer under the control of the secure processor and giving priority to the pixel-type data supplied by the latter.

[0161] In a TL5 variant of the terminal shown in [Fig.18], the secure processor SP1 is a trusted execution environment TEE within the application processor API. The data bus DB1 is replaced by an exchange memory EXMEM through which the TEE environment can receive the data provided by the application processor.

[0162] In a TL6 variant of the terminal shown in [Fig. 19], the provision of an auxiliary processor of [Fig. 17] as a software multiplexer under the control of the secure processor is combined, and the realization of the secure processor in the form of a trusted environment TEE of the application processor.

[0163] In a TL7 variant of the terminal shown in [Fig.20], the application processor API is connected to a screen D4 of its own and the secure processor SP1 is connected to a screen D5 of its own. The terminal TL7 is equipped with a touchpad TPD and a keyboard KBD separate from the screens D4 and D5. The touchpad TPD provides touch data TDT and the keyboard KBD provides text type data TXDT, which are supplied to one or other of the processors by a dual channel bypass circuit DMUX2 under the control of the secure processor and controlled by a signal SEL3.

[0164] The embodiments SCB1, SCB2, SCB3 which have just been described of the secure clipboard allow a user to save an address of a crypto-asset account at a time before the transaction is initiated by means of the companion application. Since the action of copying the address ADD or its image IMADD is initiated at an arbitrary time before the call to the companion application, it is less susceptible to attack by a fraudster, unless the latter has taken total control of the terminal, which remains very unlikely. In any case, total control of the terminal will concern the application processor and will not be able to reach the secure processor. Thus, the embodiment SCB3 of the secure clipboard will itself remain inviolable since it is totally independent of the application processor.

[0165] APPENDIX forming an integral part of 1 description: complete description of the figures 8,9, 12,13, 15, 16

[0166] [Fig.8]:

[0167] (S 100) USER goes to ISAP

[0168] (S102) USER selects the ADD address of an account as type data text, and enables the NSCB function to copy to the unsecured clipboard

[0169] (S103) API reads from SMEM1 the selected address ADD

[0170] (S 104) API stores ADD in clipboard memory C' 1

[0171] (S 109) User activates SCB1 function for copying to secure clipboard

[0172] (SI 10) API establishes communication with SP1

[0173] (SI 11) API transmits ADD to SP 1

[0174] (SI 12) SP1 stores ADD in CB2 and displays it on SD

[0175] (SI 15) USER goes to CAP

[0176] (S 120) AP1-USER pastes ADD into CAP from unsecured clipboard memory CB 1

[0177] (S 125) USER completes the transaction description in CAP and requests the transaction execution

[0178] (S 135) API-CAP sends to SP1 the description of the transaction to be signed and including ADD

[0179] (S 136) SP1-WAP verifies that ADD received is identical to ADD in CB2

[0180] (S 140) SP 1-WAP displays on SD the description of the transaction and optionally the copied address ADD and asks USER to validate the transaction

[0181] (S145) USER optionally checks that ADD displayed on NSD and ADD displayed on SD are identical before validating the transaction

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

[0183] (S155) API-CAP places the transaction on the blockchain

[0184] (S 160) SP1 refuses to sign the transaction if:

[0185] - Timeout or user action, or

[0186] - Different ADD addresses

[0187] [Fig.9]:

[0188] (S100) USER goes to ISAP

[0189] (S202) USER selects an account's ADD address as part of image IMADD, and enables the NSCB function of copying images to the unsecured clipboard

[0190] (S203) API reads from FBUF1 the image part IMADD

[0191] (S204) API stores IMADD in clipboard memory CB1

[0192] (S209) User enables SCB1 secure clipboard copy function

[0193] (SI 10) API establishes communication with SP1

[0194] (S211) API transmits IMADD to SP1

[0195] (S212) SP1 stores IMADD in CB2 and displays it on SD

[0196] (S 102) (S 103) (S 104)

[0197] (SI 15) USER goes to CAP

[0198] (S 120) AP1-USER pastes ADD into CAP from unsecured clipboard memory CB 1

[0199] (S 125) USER completes the transaction description in CAP and requests the transaction execution

[0200] (S 135) API-CAP sends to SP1 the description of the transaction to be signed and including ADD

[0201] (S240) SP 1-WAP displays on SD the description of the transaction and IMADD and asks USER to validate the transaction

[0202] (S245) USER checks that ADD in the transaction description and ADD in IMADD are identical, and validates the transaction

[0203] (S 150) SP1-WAP signs the transaction and sends the signature to API

[0204] (S 155) API-CAP places the transaction on the blockchain

[0205] (S 160) SP1 refuses to sign the transaction if timeout exceeded or user action

[0206] [Fig. 12]:

[0207] (S 100) USER goes to ISAP

[0208] (S300) USER enables SCB2 secure clipboard copy function

[0209] (SI 10) API establishes communication with SP1

[0210] (S310) API transfers to SP1 the image IMG1 present in FBUF1

[0211] (S311) SP1 stores IMG1 in FBUF2

[0212] (S312) API transfers to SP1 system data related to IMG1 present in SMEM1

[0213] (S313) SP1 stores system data in SMEM2

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

[0215] (S322) USER selects the ADD address of an account as type data text, and validates its selection

[0216] (S340) SP1 reads the selected address ADD from SMEM2

[0217] (SI 12) SP1 stores ADD in secure clipboard memory CB2 and displays it on SD

[0218] (S345) USER returns to ISAP

[0219] (S 102) (S 103) (S 104)

[0220] (S 115) USER goes to CAP

[0221] (S 120) AP1-USER pastes ADD into CAP from unsecured clipboard memory CB 1

[0222] (S 125) USER completes the transaction description in CAP and requests execution of the transaction

[0223] (S 135) API-CAP sends to SP1 the description of the transaction to be signed and including ADD

[0224] (S 136) SP1-WAP verifies that ADD received is identical to ADD in CB2

[0225] (S 140) SP1-WAP displays on SD the description of the transaction and optionally the copied address ADD and asks USER to validate the transaction

[0226] (S 145) USER optionally checks that ADD displayed on NSD and ADD displayed on SD are identical before validating the transaction

[0227] (S 150) SP1-WAP signs the transaction and sends the signature to API

[0228] (S 155) API-CAP places the transaction on the blockchain

[0229] (S 160) SP1 refuses to sign the transaction if:

[0230] - Timeout or user action, or

[0231] - Different ADD addresses

[0232] [Fig. 13]:

[0233] (S 100) USER goes to ISAP

[0234] (S300) USER enables SCB2 secure clipboard copy function

[0235] (SI 10) API establishes communication with SP1

[0236] (S310) API transfers to SP1 the image IMG1 present in FBUF1

[0237] (S311) SP1 stores IMG1 in FBUF2

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

[0239] (S341) SP1 with the TRIM function cuts IMADD in the copied image IMG1 in function of selection by USER

[0240] (S212) SP1 stores IMADD in the secure clipboard memory CB2 and the poster on SD

[0241] (S345) USER returns to ISAP

[0242] (S 102) (S 103) (S 104)

[0243] (SI 15) USER goes to CAP

[0244] (S 120) AP1-USER pastes ADD into CAP from clipboard memory not secure CB 1

[0245] (S 125) USER completes the transaction description in CAP and requests execution of the transaction

[0246] (S 135) API-CAP sends to SP1 the description of the transaction to be signed and including ADD

[0247] (S240) SP1-WAP displays on SD the description of the transaction and IMADD and asks USER to validate the transaction

[0248] (S245) USER checks that ADD in the transaction description and ADD in IMADD are identical, and validates the transaction

[0249] (S 150) SP1-WAP signs the transaction and sends the signature to API

[0250] (S 155) API-CAP places the transaction on the blockchain

[0251] (S 160) SP1 refuses to sign the transaction if waiting time exceeded or action of the user

[0252] [Fig. 15]:

[0253] (S 100) USER goes to ISAP

[0254] (S400) USER activates with button B the SCB3 copy function in the clipboard secure papers

[0255] (S410) DECCT takes the image data IDT1 provided by API, decodes it and reconstructs image IMG1 in FBUF3

[0256] (S420) SP1 transfers the copied image IMG1 into FBUF2

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

[0258] (S422) USER selects in the copied image IMG1 the ADD address of an account in as part of IMADD image, and validates its selection

[0259] (S341) SP1 with the TRIM function cuts IMADD in the copied image IMG1 in function of selection by USER

[0260] (S443) SP1 with OCR function extracts ADD from image part IMADD

[0261] (SI 12) SP1 stores ADD in secure clipboard memory CB2 and displays it on SD

[0262] (S345) USER returns to ISAP

[0263] (S 102) (S 103) (S 104)

[0264] (S 115) USER goes to CAP

[0265] (S 120) AP1-USER pastes ADD into CAP from clipboard memory not secure CB 1

[0266] (S 125) USER completes the transaction description in CAP and requests execution of the transaction

[0267] (S 135) API-CAP sends to SP1 the description of the transaction to be signed and including ADD

[0268] (S 136) SP1-WAP verifies that ADD received is identical to ADD in CB2

[0269] (S 140) SP1-WAP displays on SD the description of the transaction and optionally the copied address ADD and asks USER to validate the transaction

[0270] (S 145) USER optionally checks that ADD displayed on NSD and ADD displayed on SD are identical before validating the transaction

[0271] (S 150) SP1-WAP signs the transaction and sends the signature to API

[0272] (S 155) API-CAP places the transaction on the blockchain

[0273] (S 160) SP1 refuses to sign the transaction if:

[0274] - Timeout or user action, or

[0275] - Different ADD addresses

[0276] [Fig. 16]:

[0277] (S 100) USER goes to ISAP

[0278] (S400) USER activates with button B the SCB3 copy function in the clipboard secure papers

[0279] (S410) DECCT takes the image data IDT1 provided by API, decodes it and reconstructs image IMG1 in FBUF3

[0280] (S420) SP1 transfers the copied image IMG1 into FBUF2

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

[0282] (S422) USER selects from the copied image the ADD address of an account as as part of the IMADD image, and validates its selection

[0283] (S341) SP1 with the TRIM function cuts IMADD in the copied image IMG1 in function of selection by USER

[0284] (S212) SP1 stores IMADD in the secure clipboard memory CB2 and the poster on SD

[0285] (S345) USER returns to ISAP

[0286] (S 102) (S 103) (S 104)

[0287] (SI 15) USER goes to CAP

[0288] (S 120) AP1-USER pastes ADD into CAP from unsecured clipboard memory CB 1

[0289] (S 125) USER completes the transaction description in CAP and requests the execution of the transaction and requests the execution of the transaction

[0290] (S 135) API-CAP sends to SP1 the description of the transaction to be signed and including ADD

[0291] (S240) SP 1-WAP displays on SD the description of the transaction and IMADD and asks USER to validate the transaction

[0292] (S245) USER checks that ADD in the transaction description and ADD in IMADD are identical, and validates the transaction

[0293] (S 150) SP1-WAP signs the transaction and sends the signature to API

[0294] (S 155) API-CAP places the transaction on the blockchain

[0295] (S 160) SP1 refuses to sign the transaction if timeout exceeded or user action

Claims

Claims

1. Electronic terminal (TL1-TL7) comprising, in the same housing: - an application processor (API), - means (COMCT) for connecting the application processor to a public or private network, - a secure processor (SP1) including cryptographic calculation means, - a data link (DB1, EXMEM) between the application processor and the secure processor, - at least one display device (D3), to enable the application processor and the secure processor to display images, and - a selection device (TMD, TPD) allowing a user to select all or part of an image displayed on the display device (D3) by the application processor or by the secure processor, terminal characterized in that it is configured to, at the user's request, execute a copy function (SCB2a, SCB2b, SCB3, S112, S212) into a secure clipboard memory (CB2) accessible only to the secure processor (SP1), of data (ADD, IMADD) selected by the user in an image displayed by the application processor, the copy function comprising the following steps executed by the secure processor: - copying (S311, S420) into an image memory (FBUF2) of the secure processor an image (IMG1) displayed on the display device (D3) by the application processor, - display (S320) on the display device (D3) the copied image (IMG1), - select (OCR, TRIM, S341, S443) in the copied image (IMG1) data (IMADD, ADD) designated by the selection device (TMD, TPD) manipulated by a user, and - store (S 112, S212) the selected data (IMAD, ADD) in the secure clipboard memory (CB2).

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

3. Terminal according to one of claims 1 and 2, wherein the secure processor (SP1) is configured to take control (MUX, SEL) of the display device and display (S320) the copied image on the display device (D3) instead of the original image displayed by the application processor (API) on the display device.

4. Terminal according to one of claims 1 to 3, in which the application processor (API) is configured to provide (S310) to the secure processor (SP1) the content of an image memory (FBUF1) containing the image (IMG1) displayed on the display device (D3) by the application processor, and the secure processor is configured to copy (S311) into an image memory (FBUF2) of its own the content received from the image memory (FBUF1) of the application processor.

5. Terminal according to one of claims 1 and 2, in which the secure processor (SP1) is configured to: - take (S410) image data (IDT1) supplied by the application processor to the display device (D3) and reconstruct (S410) the image (IMG1) displayed by the application processor from the taken data, to obtain the copied image (IMG1), and - store (S420) the copied image in its image memory (FBUF2).

6. Terminal according to one of claims 1 to 5, in which the secure processor (SP1) is configured to: - apply (S443) an optical character recognition (OCR) algorithm to the copied image (IMG1) or to a part thereof, to extract therefrom text type data (ADD) designated by the selection device (TMD, TPD) manipulated by a user, and - store the text type data (ADD) in the secure clipboard memory (CB2).

7. Terminal according to one of claims 1 to 5, in which the secure processor (SP1) is configured to cut or trim (TRIM) the copied image (IMG1), so as to retain only a part of the image (IMADD) designated by the selection device (TMD, TPD) manipulated by a user.

8. Terminal according to claim 7, in which the secure processor (SP1) is configured to: - apply an optical character recognition (OCR) algorithm to the image part (IMADD), to obtain the data of type text (ADD), and - store text type data (ADD) in the secure clipboard memory (CB2).

9. Terminal according to claim 7, wherein the secure processor (SP1) is configured to store the image portion (IMADD) in the secure clipboard memory (CB2).

10. Terminal according to one of claims 1 to 6, in which the application processor (API) is configured to address to the secure processor (SP1) a request (S 135) for cryptographic signature of data provided by the application processor, and in which the secure processor is configured to, in response to the cryptographic signature request: - determine (S 136) whether the data (ADD) present in the secure clipboard memory is identical to data (ADD) provided by the application processor, and - refuse (S 160) to provide the cryptographic signature if the data (ADD) present in the secure clipboard memory is not identical to the data (ADD) provided by the application processor.

11. Terminal according to one of claims 1 to 10, in which the application processor (API) is configured to send to the secure processor (SP1) a request (S 135) for a cryptographic signature, and in which the secure processor is configured to, in response to the request for a cryptographic signature: - present on the display device (D3) the data stored in the secure clipboard memory, and - wait for authorization from the user before providing the cryptographic signature.

12. Terminal according to one of claims 1 to 11, configured to simultaneously display: - on a first zone (NSD) of the display device (D3), data provided by the application processor, and - on a second zone (SD) of the display device (D3), the data (IMAD, ADD) provided by the secure processor (SP1).

13. Terminal according to claim 12, comprising: - a first display driver (DD1) connected to the application processor (API), providing first image data (IDT1), - a second display driver (DD2) connected to the secure processor (SP1), providing second image data (IDT2), - a display selection circuit (MUX) controlled (SEL) by the secure processor, comprising a first input connected to an output of the first display driver (DD1) and a second input connected to an output of the second display driver (DD2), and an output connected to the display device (D3), and in which the secure processor is configured to control the display selection circuit (MUX) so as to display on the first zone (NSD) of the display device (D3) the data supplied by the application processor via the first display driver (DD1), and on the second zone (SD) of the display device (D3) the data (IMAD, ADD) supplied by the secure processor via the second display driver (DD2).

14. Terminal according to claim 12, comprising an auxiliary processor (AUXP) provided with a display driver (DD3) connected to the display device (D3), the auxiliary processor being connected to the application processor (API) and to the secure processor (SP1) and configured to display on the first zone (NSD) of the display device (D3) the data provided by the application processor, and on the second zone (SD) of the display device (D3) the data (IMAD, ADD) provided by the secure processor.

15. Terminal according to one of claims 1 to 14, in which the selection device comprises a touch module (TMD, TPD) connected to the application processor (API) and to the secure processor (SP1) via a touch data branch circuit (DMUX1, DMUX2), the branch circuit being configured to send touch data (TDT) to the application processor or to the secure processor according to a command (SEL, SEL2) issued by the secure processor.

16. Terminal according to one of claims 1 to 15, in which the secure processor (SP1) is a secure integrated circuit element.

17. Terminal according to one of claims 1 to 15, in which the secure processor (SP1) is a trusted execution environment (TEE1, TEE2) of the application processor (API).

18. Terminal according to one of claims 1 to 17, wherein the secure processor (SP1) is configured to execute a cryptoasset hardware wallet application (WAP) and the application processor (API) is configured to execute a companion application (CAP) intended to cooperate with the wallet application. cryptoasset hardware sheet.

19. Terminal according to claim 18, wherein: - the application processor (API) executing the companion application (CAP) is configured to send to the secure processor (SP1) a request (S 135) for cryptographic signature of a description of a transaction including a cryptoasset account address (ADD), and - the secure processor (SP1) executing the hardware wallet application (WAP) is configured to, before providing the cryptographic signature, verify (S 136) that the cryptoasset account address (ADD) appearing in the description of the transaction is identical to a cryptoasset account address present in the secure clipboard memory.

20. Method for conducting a transaction relating to cryptoassets, by means of a terminal according to one of claims 1 to 19, comprising the steps of: - configure the secure processor (SP1) to execute a cryptoasset hardware wallet application (WAP), - provide in a program memory (NVM) of the application processor (API) a companion application (CAP) intended to cooperate with the cryptoasset hardware wallet application, and an information source application (ISAP), - by means of the application processor (API) executing the information source application (ISAP), display (S 100) on the display device (D3) an image (IMG1) comprising an address (ADD) of a cryptoasset account, - copying (S311, S420) into the image memory (FBUF2) of the secure processor, the image (IMG1) displayed by the application processor and including the address (ADD) of the cryptoasset account, - by means of the secure processor, display (S320) on the display device (D3) the copied image (IMG1), in place of the original image, - select (S422), by means of the selection device (TMD, TPD) manipulated by a user, in the copied image (IMG1) displayed by the secure processor, the address (IMADD, ADD) of the cryptoasset account, and - storing (S 112, S212) the address (IMADD, ADD) of the cryptoasset account in the secure clipboard memory (CB2) of the secure processor, and - by means of the application processor running the application companion, send the secure processor a description of the transaction containing the address of the cryptoasset account, and request the secure processor to provide a cryptographic signature of the transaction.

21. Method according to claim 20, comprising the step of displaying (S 112, S212) on a secure display area (SD) of the display device (D3) controlled by the secure processor (SP1), the address (IMADD, ADD) of the cryptoasset account copied into the secure clipboard memory (CB2).

22. Method according to one of claims 20 and 21, wherein the step of selecting the address (ADD) of the crypto-asset account comprises the step of applying (S443) an optical character recognition (OCR) algorithm to the copied image (IMG1) or to a part thereof, to extract therefrom the address of the crypto-asset account.

23. Method according to one of claims 20 and 21, in which the step of selecting, in the image (IMG1) displayed by the secure processor (SP1), the address (ADD) of the crypto-asset account, comprises the step of cutting or trimming (S341, TRIM) the copied image so as to retain only a part of the image (IMADD) designated by the selection device (TMD, TPD) manipulated by a user.

24. The method of claim 23, further comprising the step of applying (S443) an optical character recognition (OCR) algorithm to the image portion (IMADD) obtained by cutting or trimming (TRIM) the copied image (IMG1).

25. Method according to one of claims 20 to 24, comprising the step of, by means of the secure processor (SP1) executing the cryptoasset hardware wallet (WAP) application, verifying (S 136) that the address (ADD) present in the description of the transaction provided by the companion application is identical to the address (ADD) present in the secure clipboard memory (CB2), and not providing the cryptographic signature of the transaction if the two addresses are different.

26. Method according to one of claims 20 to 25, comprising the steps of, by means of the secure processor (SP1) executing the cryptoasset hardware wallet application (WAP): - presenting (S 140, S240) on the display device (D3) the address (IMADD, ADD) of the cryptoasset account stored in the memory of secure processor secure clipboard (CB2), and - wait for user authorization before providing the cryptographic signature of the transaction.

Images