Connected terminal comprising means for embedding secure images in non-secure images

Abstract

A method for performing a secure operation using a connected terminal (SPH6) that includes an application processor (APROC), a secure element (eSE) configured to perform the operation using a private key, and a display (DISP) that receives a non-secure image related to a process of the secure operation from the application processor. The method comprises a step of embedding, in at least one non-secure image provided by the application processor and presented on the display, a secure image provided by the secure element and inaccessible to the application processor, the security image comprises information about the security operation and extends in at least one determined area (10) of the display.

Description

Technical Field

[0001] The present invention relates to the integration of security functions in connected terminals (such as smartphones), and in particular to the integration of hardware wallet functions for crypto assets. The invention also relates to the control of information presented to the user on the terminal screen during the execution of security operations. Background Art

[0002] In recent years, the development of cryptocurrencies or other types of crypto assets managed by blockchains, such as non-fungible tokens (NFTs) and smart contracts, has given rise to various ways of storing and keeping private keys attached to these different types of crypto assets. This is how the concepts of "wallets", "cold storage" and "hot storage" of private keys emerged. A "wallet" is a device or program whose role is to manage crypto assets and therefore store private keys attached to them. So-called "hot wallets" are connected to the Internet and exposed to hacker attacks or viruses and malware. These can be wallets managed by centralized exchanges, which do not provide the highest level of security. "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 many unsafe applications, and are therefore themselves exposed to attacks.

[0003] Cold wallets are the safest solution for cold storage of private keys, i.e. removed from direct access to the internet, which reduces attack exposure and therefore reduces the risk of being hacked. Transactions involving private keys are signed in an offline environment. Any transaction initiated online is temporarily transferred to an offline hardware wallet, where it is then digitally signed before being sent to the online network. Since the private key is not communicated to the online server during the signing process, hackers cannot access it.

[0004] Hardware wallets are a convenient alternative to passive wallets for storing private keys. In addition, they are usually configured to generate a recovery phrase to recover the private key in case the private key is lost. It is important to note that crypto assets are never stored in hardware wallets, but are recorded on the blockchain. Hardware wallets only store private keys to manage transactions on the blockchain side. The public key corresponding to the private key points to the address on the blockchain where the asset is effectively located.

[0005] As shown in Figure 1, the hardware wallet HW is never directly connected to the Internet. In order to be used, the hardware wallet HW must be connected to the host device HDV via a data link LNK (e.g., USB or Bluetooth). The host device HDV can be a computer, mobile phone or tablet, and runs a so-called "matching" software for trading on the blockchain end BCN, such as the "Ledger Live" software developed by the applicant. Alternatively, the hardware wallet HW can be used through the HDV host device using a decentralized exchange or DEX, where the user can trade while keeping his key in the hardware wallet.

[0006] The hardware wallets sold by the applicant are commercially successful due to the high level of security they provide by using a "secure element" to store private keys and sign transactions. A secure element is a hardware platform that can store and manipulate data in accordance with security rules and requirements set by a trusted authority. It comes in the form of a semiconductor chip that implements various countermeasures against fraud attacks.

[0007] FIG2 shows the architecture of a hardware wallet HW1 sold by the applicant as “Nano S”. The hardware wallet HW1 has a secure element SE1 paired with a microcontroller MCU1. The microcontroller MCU1 has a USB interface U1 and acts as a proxy device for the secure element SE1 for communicating with an external host device HDV running a companion application (see FIG1 ). The secure element SE1 has its own secure operating system OS (firmware) that allows it to run the application APP and incorporates a cryptographic coprocessor CRY. The hardware wallet HW1 also has a display DISP1 and two buttons B1, B2 managed by the microcontroller MCU1. The user must press both buttons at the same time to prove that they have agreed or agreed to perform or complete the operation.

[0008] Hardware wallets of the type just described lack Internet connectivity and must be coupled to a host device such as a mobile terminal or smartphone when performing transactions. They offer a high degree of security, as they are mostly not accessible via public networks and therefore have limited exposure to attacks. However, this characteristic makes them less ergonomic and easy to be misplaced or forgotten.

[0009] Therefore, so-called “blockchain” smartphones have been proposed, which integrate hardware wallet functionality for cryptocurrencies while providing the usual functions of a mobile phone, such as Galaxy S10 models, Exodus 1 model or Sirin Finney model. Such smartphones are often referred to as "blockchain smartphones" or "crypto smartphones". Similar to hardware wallets, such smartphones are equipped with an embedded secure element and internal storage space that is not accessible to the Internet, allowing the creation of virtual currency wallets. In other specific implementations, the main processor has a secure enclave or trusted execution environment (TEE) instead of a secure element.

[0010] Despite these precautions, implementing a hardware wallet inside a smartphone inevitably increases the wallet's exposure to Internet attacks and does not provide the same security advantages as a true cold wallet. In addition, it is impossible for the user to know for sure whether the data displayed is reliable, as it may be provided by malware.

[0011] When it comes to virtual currencies, a very high degree of security is required. Blockchain smartphones provide a certain degree of security through the use of secure enclaves or trusted execution environments TEEs, but digital hardware wallet functionality, which is not the primary function of such phones, requires more security. In fact, implementing a hardware wallet within a smartphone partially eliminates the security advantages of a detached hardware wallet that is connected only when needed. This inevitably increases the wallet's exposure to Internet attacks.

[0012] Therefore, there is a need to provide a portable electronic device connected to the Internet that allows transactions to be performed on the blockchain side, and specifically is capable of executing applications designed to perform transactions on the blockchain side (such as the Ledger Live application or equivalent), while providing a high degree of security regarding the preservation of the secret keys of the crypto asset accounts used to sign transactions.

[0013] Document WO2015124088A1 describes a mobile terminal including a secure transaction system equipped with a secure display unit and a physical confirmation button, so that when the mobile terminal displays sensitive information during an electronic transaction, the sensitive information is displayed separately on the secure display unit. A separate physical confirmation button is used as a secure element unit, so that key transaction data can be implemented via the secure element, its secure display unit, and its physical confirmation button, without passing through a general operating system in the mobile terminal.

[0014] Document WO2015180581 teaches the use of a switch module controlled by a button to share display between a main chip and a security chip ( Figure 3). The switching module receives the display data and applies them to a display driver that controls the display screen. In such a hybrid architecture in which multiple processors share access to the display screen, the display driver arranged at the output of the switching module is vulnerable to attacks aimed at controlling the display. Furthermore, in practice, each processor must be able to address the control signal to the display driver, thereby requiring the provision of hardware connections such as conductive tracks. Such hardware connections increase the attack surface (also called exposure surface) of the hybrid architecture and in particular increase the attack surface of the security chip.

[0015] Therefore, there is also a need to improve the security of hybrid architectures where multiple processors share access to a display screen.

[0016] There is also a need to integrate a hardware wallet into a conventional mobile terminal platform to convert it into a mobile terminal with an embedded hardware wallet, with minimal modification to the mobile terminal platform. Summary of the invention

[0017] An embodiment relates to a connected terminal configured to perform a security operation, the terminal comprising: an application processor configured to initiate the security operation; a security element (eSE) for performing the security operation; and a display accessible via a wired bus and receiving image data to be displayed to a user from the application processor, the terminal comprising a component controlled by the security element and configured to alternately apply image data provided by the application processor and image data provided by the security element to the wired bus of the display at the request of the security element and at least during the execution of the security operation, so that the image data provided by the security element replaces the image data provided by the application processor and forms a security image embedded in a non-security image provided by the application processor, the security image extending in at least one determined area of ​​the display.

[0018] According to one embodiment, the terminal comprises at least one light indicator activated by the secure element when the secure element embeds a secure image in a non-secure image provided by the application processor.

[0019] According to one embodiment, the terminal comprises means for indicating to the user the position and extent of the area in which the embedded security image is displayed.

[0020] According to one embodiment, the means for indicating the position and extent of the area where the embedded security image is displayed comprises a row of light indicators controlled by the security element and arranged along an edge of the display.

[0021] According to one embodiment, the component for indicating the position of the area where the embedded security image is displayed includes: an area of ​​the display that is permanently under the control of the security element and displays a certain appearance; and a border of the area where the embedded security image is displayed, which has the same appearance as the area of ​​the display that is permanently under the control of the security element.

[0022] According to one embodiment, the component configured to alternately apply image data provided by the application processor and image data provided by the security element to the wired bus of the display includes: a multiplexer, which receives the image data provided by the application processor on a first input part and receives the image data provided by the security element on a second input part; a control circuit of the multiplexer, which is configured to control the multiplexer according to configuration data provided by the security element.

[0023] According to one embodiment, the control circuit is configured to control the multiplexer by a determined embedding granularity of the image data provided by the secure element, the embedding granularity being a ratio of rows or a ratio of pixels of the image data provided by the application processor.

[0024] According to one embodiment, the secure element is configured to embed a secure image including information about the secure operation in a non-secure image provided by the application processor before performing the operation.

[0025] According to one embodiment, the terminal further comprises: an input device providing touch data on a data bus and a demultiplexer, the demultiplexer being controlled by the secure element and configured to connect the data bus of the input device to a bus of the application processor or a bus of the secure element.

[0026] According to one embodiment, the secure element is configured to be connected to the input device during display of information about the operation in the secure image.

[0027] According to one embodiment, the terminal comprises a physical button operable by the user and monitored by the secure element, wherein the secure element is configured to bypass the operation in the absence of a user action on the physical button.

[0028] According to one embodiment, the security element and the component for alternately applying image data provided by the application processor and image data provided by the security element to the wired bus of the display are fully or partially integrated in a system-level package or a system-on-chip mounted on an interconnect support of the terminal.

[0029] According to one embodiment, the secret operation comprises a step of signing the data using a secret key.

[0030] According to one embodiment, the terminal has no display controller between the display and the component controlled by the security element, and the image data alternately applied to the wired bus of the display by the component controlled by the security element is in a format compatible with the display and does not need to be converted into another format in order to be displayed.

[0031] An embodiment also relates to a method for performing a security operation using a connected terminal, in particular signing data using a secret key, the terminal comprising: an application processor configured to initiate the security operation; a security element that holds a private key and is configured to perform the security operation; and a display that is accessible via a wired bus and receives from the application processor a non-secure image related to the progress of the security operation, the method comprising the step of embedding a security image provided by the security element and inaccessible to the application processor in at least one non-secure image provided by the application processor and presented on the display, the security image comprising information about the operation and extending in at least one determined area of ​​the display, the embedding step being under the control of the security element and unable to be blocked or destroyed by the application processor.

[0032] According to one embodiment, the method includes the step of providing a component in the terminal, which is controlled by the security element and is configured to alternately apply image data provided by the application processor and image data provided by the security element to the wired bus of the display at the request of the security element, so that the image data provided by the security element replaces the image data provided by the application processor and forms the secure image embedded in the non-secure image provided by the application processor.

[0033] According to one embodiment, image data in a format compatible with the display and not requiring conversion into another format in order to be displayed is alternately applied to the wired bus of the display, and no display controller is provided between the display and the component controlled by the secure element.

[0034] According to one embodiment, the method comprises providing at least one light indicator in the terminal and comprising the step of activating the light indicator by the secure element when the secure element embeds a secure image in a non-secure image provided by the application processor.

[0035] According to one embodiment, the method comprises the step of indicating to the user the location and extent of the area in which the embedded security image is displayed.

[0036] According to one embodiment, the position and extent of the area in which the embedded security image is displayed is indicated by a row of light indicators controlled by the security element and arranged along an edge of the display.

[0037] According to one embodiment, the position and extent of the area in which the embedded security image is displayed is indicated by: an area of ​​the display that is permanently under the control of the security element and has a certain appearance; and a boundary of the area in which the embedded security image is displayed, which boundary has the same appearance as the area of ​​the display that is permanently under the control of the security element.

[0038] According to one embodiment, the device comprises an input device providing touch data on a data bus, and the method comprises the step of connecting the input device to the security element during display of information about the security operation in the embedded security image.

[0039] According to one embodiment, the device includes a physical button operable by the user and monitored by the security element, and the method includes the step of configuring the security element so that the security element bypasses the execution of the security operation in the absence of user action on the physical button. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] An example of an architecture of a connected terminal including a virtual currency hardware wallet will be described below in a non-limiting manner with reference to the accompanying drawings, in which:

[0041] - Figure 1 illustrates an example of conventional use of a hardware wallet via a host device,

[0042] - Figure 2 shows the general architecture of a cold hardware wallet,

[0043] - Figure 3 A first embodiment of a connected terminal embedded with a hardware wallet is shown,

[0044] - Figure 4 A second embodiment of a connected terminal embedded with a hardware wallet is shown,

[0045] - Figure 5 A third embodiment of a connected terminal embedded with a hardware wallet is shown,

[0046] - Figure 6 A fourth embodiment of a connected terminal embedded with a hardware wallet is shown,

[0047] - Figure 7 A fifth embodiment of a connected terminal embedded with a hardware wallet is shown,

[0048] - Figure 8showing a sixth embodiment of a connected terminal embedded in a hardware wallet and comprising a dynamic multiplexer for embedding a secure image in a non-secure image,

[0049] - Fig. 9A , Fig. 9B , Fig. 9C , Fig.9D and Fig.9E Various embodiments of methods for embedding a secure image into a non-secure image are shown,

[0050] - Fig.10 A first embodiment of a dynamic multiplexer is shown,

[0051] - Fig.11 A second embodiment of a dynamic multiplexer is shown,

[0052] - Fig.12 A third embodiment of a dynamic multiplexer is shown,

[0053] - Fig.13 A fourth embodiment of a dynamic multiplexer is shown,

[0054] - Fig.14 A fifth embodiment of a dynamic multiplexer is shown,

[0055] - Fig.15 A sixth embodiment of a dynamic multiplexer is shown, and

[0056] - Fig.16 Shown according to Figures 4 to 8 , Figures 10 to 14 An arrangement of components of a connected mobile terminal in one of the implementation schemes. DETAILED DESCRIPTION

[0057] The architecture of a connected terminal including an embedded hardware wallet designed to avoid or limit attacks made possible by such a configuration will be described below. In order to avoid creating a completely new ecosystem and not to compromise the user experience, compatibility with existing hardware and operating systems (Android, iOS) is sought, as well as the use of traditional application distribution channels. It is therefore assumed that the considered connected terminal is capable of installing and executing applications that may come from unknown or even suspicious sources, which increases the challenge of protecting transactions through an embedded hardware wallet. It is also assumed that the installable application can gain access to the hardware resources involved in the communication with the secure element implementing the hardware wallet.

[0058] For example, malware can record keys pressed to steal passwords, simulate keys pressed to forge transactions, modify displays to deceive users about transactions they are performing, etc.

[0059] More specifically, the authentication of transactions on the phone by a virtual keyboard can be intercepted by low-level spyware that has access to the touch screen interface by detecting the coordinates of touches on the touch screen. Without knowing what is displayed, the spyware can rely on the assumption that the displayed virtual keyboard is one of many traditional keyboards available on the platform, so that the touch coordinates reveal the keyboard keys. The spyware can also access the accelerometer or other sensors that are typically present in mobile terminals - touches at different locations on the screen translate into different acceleration values ​​rotating on two axes, so that the touch location can be inferred.

[0060] To partially remedy this, conventional applications display a numeric virtual keyboard with randomly positioned keys for personal identification code entry. However, while this measure is useful for preventing the deduction of the identification code, malware can infer that a transaction is in progress and, before the user completes it, modify the amount or recipient and simulate verification of the transaction by modifying the application's input without modifying the application itself.

[0061] Figure 3 An embodiment SPH1 of a mobile terminal or other connected device in which a hardware wallet is embedded is represented. The mobile terminal comprises an application processor APROC connected to various peripherals, in particular a touch screen comprising a display DISP and a touchpad KBD. The application processor is, for example, a baseband processor providing telephone communications and including Internet connectivity. The processor manages the display via a bus DISPB, which implements a determined video interface protocol, such as the MIPI DSI protocol (“Display Serial Interface”). The MIPI-DSI protocol has been widely adopted by the industry and is currently ubiquitous in smartphones. It is also widely used in tablets, laptops and laptop / tablet hybrids. The processor manages the touchpad KBD via another interface, for example a data bus DB1 of I2C type. For the sake of readability of the drawings, not all elements of the mobile terminal are represented.

[0062] The application processor APROC also integrates a secure enclave or trusted execution environment TEE. Such an enclave typically includes a dedicated processor, memory and a touch screen manager (also called a display controller). It is designed to implement a trusted user interface TUI, such as the one from The Trusted User Interface API document recommends:

[0063] https: / / globalplatform.org / wp-content / uploads / 2013 / 06 / GlobalPlatform_ Trusted_User_Interface_API_v1.0.pdf

[0064] Thus, as shown, the enclave can manage user input on the display DISP and the touchpad KBD according to the instructions executed by the application.

[0065] The mobile terminal also includes an embedded secure element eSE that implements a virtual currency hardware wallet. The element eSE may be similar to the element integrated in the separate hardware wallet described previously. It may be from The ST33 secure microcontroller has a secure serial peripheral interface (SPI), two inter-integrated circuit interfaces I2C and various programmable input / output pins GPIO, etc. The link between the mobile terminal HDV and the separate hardware wallet HW (for example, a USB interface or a Bluetooth interface), which is represented by LKK in FIG. 1 , is realized here by a long-term wired connection between the secure element eSE and the application processor (here the data bus DB2). The bus DB2 is, for example, an SPI bus connected to the interface of the same name of the ST33 microcontroller. In order to ensure better communication security, the other end of the bus DB2 can be connected to the TEE enclave.

[0066] The implementation of the hardware wallet functionality in the element eSE and the exchanges between the element eSE and the application processor may be completely similar to what is known from FIGS. 1 and 2 and will not be described in further detail.

[0067] In addition, one of the input / output pins GPIO1 of the secure element eSE is connected to a physical button B, which is provided to verify the transaction by mechanical operation. Pin GPIO1 is managed exclusively by the secure element, and its state change cannot be simulated by software executed on the application processor. Another input / output pin GPIO2 of the secure element eSE controls a light indicator LD formed here by an LED diode to signal that a secure operation is being performed using the hardware wallet in the element eSE. Button B is a dedicated physical button, for example, arranged on the side wall of the mobile terminal, which is visually different from other buttons typically provided on the mobile terminal. The light indicator LD is also dedicated and is obvious compared to other light indicators typically provided on the mobile terminal.

[0068] With this configuration, transactions are prepared in the usual way by an official application such as "Ledger Live" executed by the application processor. From the moment the user has to verify the transaction, the application passes through the enclave TEE to display the transaction on the display DISP and, if applicable, manages the user input phase on the touchpad KBD, such as entering an identification code to unlock the secure element. The verification and signing of the transaction are delegated to the element eSE (hardware wallet) by commands issued on the bus DB2 via the enclave TEE. If applicable, the entered unlocking code is sent to the secure element via the bus DB2. The element eSE responds to these commands by activating the light indicator LD and waiting for a press on the button B.

[0069] When the user presses button B, the element eSE calculates the transaction signature by means of the private key stored in the wallet and sends the signature to the application via bus DB2. The secure element having completed its task deactivates the light indicator LD and waits for new commands. The application updates the blockchain via the web service, displays useful information, and waits for new user interaction.

[0070] If after a timeout no action is detected on button B, the transaction is canceled. The secure element signals this to the application via bus DB2, deactivates the light indicator LD, and waits for a new command.

[0071] Button B has a similar functionality as buttons B1, B2 of a separate hardware wallet of the type of FIG. 2. If malware manages to modify the amount or address of a transaction, it will not be able to simulate a verification, which requires the actuation of a physical button that can only be detected by element eSE. Therefore, before verification, the user can confirm that the displayed transaction is indeed the transaction they initiated. If the transaction has been modified, the user can in principle notice the transaction on the display and cancel it. Cancellation can conventionally be performed by pressing a virtual button on the touch screen. The cancel button functionality cannot be hijacked into the verification functionality, because verification is only possible using button B, which is exclusively managed by element eSE.

[0072] The light indicator LD is activated and confirms to the user that the secure element is handling the operation and that the request made to it by the terminal comes from a trusted source.

[0073] According to a variant that is slightly more expensive in terms of manufacturing the mobile terminal housing, two physical buttons may be provided that have to be pressed simultaneously to authenticate the transaction.

[0074] Regardless of the enclave TEE's control over the display, sophisticated malware can modify the application's input and / or output data to hijack them, and in particular modify the display of information related to transactions to be confirmed by the user. For example, the software can intercept transaction data entered by the application to replace them with fraudulent data (such as transaction amounts and addresses). Even if this is difficult when the input is performed via the enclave TEE in secure mode, such attacks are not impossible given the degree of security provided by the TEE enclave. The application then generates a transaction with the modified data for the element eSE and the corresponding erroneous display. The traitorously modified display can then also be intercepted and modified so that it corresponds to the transaction originally desired by the user. Thus, the user will see apparently correct transaction data on the display and verify the transaction, but the verification will be applied to the fraudulently modified transaction that has been secretly entrusted to the element eSE.

[0075] In conventional separate hardware wallets, this type of fraud is hindered by the fact that the hardware wallet reproduces on its own display the transactions it will perform: the user relies on the transactions displayed by the separate wallet and can compare them with the transactions displayed by the application on the terminal. When the hardware wallet is embedded in a smartphone, such functionality is not feasible given the difficulty of providing a second display and the additional costs this would entail.

[0076] Figure 4 An embodiment SPH2 of a mobile terminal integrating a hardware wallet and eliminating this type of display manipulation is shown. The application processor APROC including the enclave TEE is here integrated into a system-on-chip SoC receiving a secondary processor SPROC. The SoC may be from i.MX 8M Plus circuitry. As previously mentioned, the element eSE is connected to the enclave TEE via a bus DB2 (e.g., an SPI bus). The processor SPROC has its own display controller and can be considered highly secure because it is separated from the other circuits of the SoC, similar to a secure element. Therefore, like a secure element, the processor SPROC can receive commands from the enclave TEE via the bus DB2. The display controller of the processor SPROC is the only master of the bus DISPB and includes a frame buffer FB1, which the processor SPROC can fill as needed from the frame buffer FB2 of the application processor or the frame buffer FB3 of the enclave TEE (arrow CPY) or even from display data generated by itself. In another embodiment, the processor SPROC can use a pointer that has been provided to it to directly display data from the memory FB2 or FB3. Such a display mechanism is documented and will not be described in more detail. Therefore, according to the needs of the running application, the display DISP receives its data from the application processor, the enclave TEE or the processor SPROC itself.

[0077] With this configuration, transactions are prepared in the usual way by an official application (such as "Ledger Live") executed by the application processor APROC. The touchpad KBD is still managed by the enclave TEE to protect the user input of the data involved during the transaction, such as the unlocking code or the amount of the transaction accepted, and the transaction processing is delegated to the secure element via the bus DB2. In order to overcome potential identification defects of the display managed by the enclave TEE, the secure element eSE (which itself is connected to the processor SPROC via the bus DB2) is configured to provide the latter with the transaction data to be verified by the user.

[0078] The secure element eSE is configured to, after receiving transaction data that it must verify by signing the transaction using a private key, send corresponding display data to the processor SPROC via the bus DB2 and request the processor SPROC to display them via the display controller FB1 instead of the data that may be present in the frame buffers FB2 and FB3.

[0079] Therefore, even if the official application is configured to generate such data and send them to the display controller of the enclave TEE to fill the frame buffer FB3, or to the display controller of the application processor to fill the frame buffer FB2, these data will not be displayed and will be replaced by the data provided by the secure element. Therefore, if the corrupted data generated by the application is in the frame buffer FB2 or FB3, these data will be ignored and the data generated by the secure element in the frame buffer FB1 will actually be displayed.

[0080] This implementation, SPH2, relies on the use of a specific system-on-chip that may not be suitable for some smartphone manufacturers. In addition, it is susceptible to attacks that would make the secure element believe that it is communicating with the processor SPROC when it is actually communicating with a hacked TEE enclave. Thus, the secure element does not have absolute certainty of accessing the display when the secure element believes it has access.

[0081] Embodiments are described below that may be implemented using more conventional components while providing a high level of security with respect to control of data displayed to the user.

[0082] Figure 5 An implementation SPH3 of a mobile terminal is shown, which Figure 3 The embodiment SPH1 is derived and comprises, as previously described, an application processor APROC and an enclave TEE, a display DISP, a touchpad KBD, a secure element eSE, a physical button B connected to pin GPIO1 to authenticate a transaction, and a light indicator LD controlled by pin GPIO2 to signal that a security operation is in progress in the element eSE. As previously described, the touchpad KBD is controlled by the enclave TEE via a bus DB1 (e.g., an I2C bus). The enclave TEE is connected to the secure element eSE via a bus DB2 (e.g., an SPI bus).

[0083] The terminal SPH3 differs from the terminal SPH1 mainly in that it comprises a display controller DMCU dedicated to the secure element eSE, and a multiplexer MUX whose output is connected to the bus DISPB of the display DISP. This multiplexer receives on a first input, via the bus DISPB1, display data generated by the application processor APROC. These display data no longer need to be managed by the enclave TEE, as shown, but can be managed by the enclave TEE if necessary. The second input of the multiplexer receives, via the bus DISPB2, display data generated by the display controller DMCU. An input / output pin GPIO3 of the secure element eSE provides a selection signal SEL to the multiplexer input, which will be connected to the output of the latter. Thus, depending on the value on the signal SEL, the multiplexer MUX connects the bus DISPB of the display to the bus DISPB1 of the application processor APROC or to the bus DISPB2 of the display controller DMCU. In a variant, the signal SEL can also be taken from the pin GPIO2 controlling the light indicator LD.

[0084] The display controller DMCU receives display commands from the secure element eSE via bus DB3 (e.g., I2C bus). The I2C protocol provides relatively low data throughput, but is used here to carry only text and vector display commands using low bandwidth. The secure element eSE is therefore programmed to generate basic display commands for the transactions it handles and send them to the display controller DMCU.

[0085] The display controller DMCU is a separate circuit here, because the secure elements commonly available on the market are not equipped with a graphics processor and do not have sufficient bandwidth to generate the desired bitmap image on the bus of a display (such as the display of a modern smartphone). The display controller DMCU is, for example, from An STM32 microcontroller including an LCD-TFT display controller equipped with a MIPI-DSI interface.

[0086] The secure element eSE is configured to command the multiplexer MUX so that it applies the display data from the application processor APROC to the display DISP by default. When the application requests the secure element eSE to sign a transaction, the latter transmits a display command of the transaction data to the display controller DMCU and switches the multiplexer MUX so that the graphic information generated by the controller DMCU reaches the display DISP. The light indicator LD is activated and the secure element eSE waits for user verification by monitoring the state of the button B.

[0087] Thus, the display DISP presents to the user the transaction data actually received and processed by the secure element eSE. If these data have been modified by a malicious program, the user will not notice it and can cancel the transaction.

[0088] It is also preferred that the capture of information entered by the user on the touch panel KBD (e.g., an unlock code or other sensitive information such as the target transaction amount) presents a security level at least of the same level as that of the display. In the embodiments SPH1, SPH2, SPH3 just described, this capture is performed by the enclave TEE and therefore provides a lower security level than that of the display. A higher level of security may therefore be desired.

[0089] Figure 6 is a block diagram of an implementation scheme SPH4 of a mobile terminal, which is Figure 5 The SPH3 differs in that the output bus DB1 (here of I2C type) from the touchpad KBD is connected to the input of a demultiplexer DMUX having two outputs. A first output of the demultiplexer DMUX is connected to the application processor APROC via a bus DB11 and a second output of the demultiplexer is connected to the secure element eSE via a bus DB12. The selection of the demultiplexer DMUX can be operated by the same signal SEL as the signal applied by the secure element to the multiplexer MUX. Preferably, the two buses DB11 are of the same type as the bus DB1 to avoid providing a protocol converter in the demultiplexer DMUX.

[0090] In this embodiment, no enclave TEE is provided to execute all or part of the application involving the secure element, so the application is executed by the application processor APROC, except for the steps delegated to the secure element. However, there is nothing to prevent providing a TEE enclave and using it to control the bus DISPB1 and receive touch data DB11 during the execution of the non-sensitive phases of the application.

[0091] The secure element eSE is configured to position by default the multiplexer MUX and the demultiplexer DMUX so that they connect the display DISP and the touchpad KBD to the application processor, in particular during the preparation phase of the transaction. The secure element then modifies the value of the signal SEL during the sensitive phase of the transaction execution so that it itself receives any information provided by the user via the touchpad KBD and so that it itself provides the transaction data to be presented to the user through the display controller DMCU.

[0092] The touchpad is thus out of the control of the application during its connection to the secure element, and the application is no longer able to implement the input phase. The input phase is delegated to the secure element, which is here configured to manage a virtual keyboard for both input and display.

[0093] In one embodiment, the bus DB12 is connected to the input / output pins of the display controller DMCU, rather than to the security element. This embodiment can be advantageous if the display controller is a microcontroller of the above type whose data processing capabilities are superior to those of the security element. Since the display controller DMCU is under the control of the security element, it can receive and process a large amount of data for the security element, such as data from a touch keyboard, which the security element may not be able to process, and communicate the results of the processing to it via the bus DB3.

[0094] When the application delegates the transaction to the secure element via bus DB2, this time without passing through the enclave TEE, the secure element eSE controls the multiplexers and demultiplexers to connect the display DISP to the display controller DMCU and the touchpad KBD to the secure element eSE. If input is required, the secure element eSE implements the input phase. Input on the touchpad can no longer be intercepted or modified by software running on the application processor, while any attempt to modify the display by software running on the application processor is ignored.

[0095] Given this configuration, software running on the application processor cannot simulate false authentication on the touchpad, so the physical button B is optional: the touchpad can be used to safely perform authentication.

[0096] Just described as Figure 5 The improved touch pad KBD fixation of the embodiment SPH3 is also applicable to Figure 4 An implementation of SPH2, where in secure mode, the touchpad's bus DB1 will be routed to the secure element instead of connected to the enclave TEE.

[0097] In one embodiment, the signal SEL or any other indicator of the safe mode (such as a control signal of the light indicator LD) can be used to disable circuits that are not used in principle during the safe mode. Figure 6 As shown, the signal SEL is applied, for example, to the INHIB pin of the application processor. It can be provided that switching the signal SEL to its value corresponding to the secure mode causes the processor to be reset by cutting off its clock signal or cutting off its power supply. In this case, any malware running on the application processor that performs analysis to infer cryptographic keys or other sensitive information is rendered inoperative during secure transactions.

[0098] Specifically, in Figure 6In a configuration of , complete deactivation of the application processor is possible, where all functions that must remain active during a transaction are moved to the secure element eSE. In the case where the application processor cannot be deactivated, the signal SEL can be used to deactivate auxiliary circuits that can be used to infer sensitive information, such as an accelerometer that allows inferring the touch position of the touchpad. Accelerometers are usually integrated into dedicated inertial measurement units or IMUs. Such inertial measurement units can be deactivated by stopping their clocks, cutting off their power supply, or cutting off their communication link with the application processor (usually an I2C bus).

[0099] The malware can be designed to initiate a transaction when the secure element is in a configuration where it does not request an unlock code, such as during a limited time after a previous transaction was performed. In this case, the malware attempts to modify the display, but this attempt fails because Figure 5 and Figure 6 In the embodiment of the present invention, the secure element eSE is the master of the display. Therefore, the display reflects the transaction actually initiated by the malware, while the secure element eSE waits for the touch pad (in Figure 6 configuration) or on physical button B (in Figure 4 or Figure 5 In the configuration of Figure 3 In such cases, fraudulent modification of the display is possible, making it possible to deceive the user about the nature of the transaction.

[0100] If a fraudulent transaction is initiated when the user has the mobile terminal in view, the user sees the mobile terminal enter security mode (light indicator LD), display the transaction and request verification without request. The user can confirm the display and cancel the transaction, but this requires the user to be focused and not mistakenly verify the transaction.

[0101] If the user does not have the mobile terminal in view, the transaction is automatically cancelled at the expiration of the timeout period in principle. However, if the mobile terminal is vibrated in a pocket or bag, the transaction may be cancelled before the expiration of the timeout period by pressing the physical button B ( Figures 3 to 5 ) or by pressing the touchpad ( Figure 6 ) and unintentional authentication occurs, the touch panel can be configured to operate on the lock screen of the mobile terminal when requesting authentication.

[0102] Figure 7 An embodiment SPH5 of a mobile terminal is shown which eliminates this type of fraud. Figure 6In addition to the elements of the embodiment of the present invention, a physical bistable switch S is connected to the input / output pin GPIO4 of the security element eSE. In a first position, the switch S connects the input GPIO4 to a high logic level, such as a power supply voltage Vcc, and in a second position, the switch S connects the input GPIO4 to a low logic level, such as a ground voltage GND. The switch S is arranged, for example, on one of the side walls of the mobile terminal device.

[0103] The secure element eSE is programmed not to process commands received via the bus DB3 in one of the positions of the switch S (e.g. the first position) and to accept transaction requests received via the bus DB3 in the other position. The terminal SPH5 is designed so that the switch S is the only component that can be used to switch the mode of the secure element, which means that the application can no longer delegate the processing of transactions itself.

[0104] Thus, the mode of the secure element is exclusively under the control of the user who uses the switch S to select the mode as desired.

[0105] The switch S is initially in the inactive mode position, and the application that may initiate the transaction is then designed to prompt the user to change mode when it is about to delegate the transaction processing to the secure element eSE. It may transmit a message like "Please use the switch to put the phone in secure mode" to the display DISP, preferably with information about the ongoing transaction. This message is similar to the message inviting the user to connect their conventional split wallet to the mobile terminal.

[0106] The user then switches the switch to enter active mode. The secure element eSE responds by taking various protective measures, such as switching the signal SEL to connect the display DISP and the touch panel KBD to the dedicated display controller DMCU and the secure element eSE, respectively. The light indicator LD is also activated to signal to the user that the mobile terminal is in secure mode. The secure element eSE transmits a confirmation to the application, which resumes execution by sending transaction information to the secure element. The secure element eSE operates the user input stage from the touch panel KBD (if applicable) and requests verification from the user by displaying the transaction information again.

[0107] When the transaction is verified and signed, the secure element eSE communicates the signed transaction to the application which records it on the blockchain. The secure element prompts the user to change mode by transmitting a message to the display DISP such as "Please exit secure mode by switching the switch". This message is similar to the message indicating that the user can remove his conventional detached wallet. When the switch is switched, the initial connection of the display and the touchpad is restored and the light indicator LD is deactivated.

[0108] Switch S can also be Figure 4 and Figure 5In the structure of , the touch pad KBD is not connected to the security element. In this case, the application operates the input phase before requesting the switching of the switch S.

[0109] Of course, at the user's discretion, switch S may be switched when not needed, or not switched when needed. Thus, various combinations are not "normal", and this may be signaled to the user via a displayed message or alert, encouraging the user to switch the switch so operation can resume normally.

[0110] Malware can also behave like an official application by requesting a mode change. However, since the user has not yet initiated a transaction and is being asked for relatively restrictive actions, they may be more wary. Malware may no longer display misleading off-topic messages because the user expects to see transaction information. Such transaction information will be difficult to trust, especially if it is authentic - typically large transfers to unknown addresses. If the malware attempts to hide the nature of the transaction, then when the transaction is displayed for verification by the secure element eSE, if the user is still guided to switch to secure mode, the transaction will be revealed and different.

[0111] In any case, a pending transaction (whether fraudulent or not) can no longer be verified by an inadvertent press on a physical or virtual button, as the user must intentionally switch the mobile terminal to the secure mode to verify the transaction.

[0112] In just about Figures 5 to 7 In the described embodiment, the secure element controls the display DISP when the secure element switches to secure mode, where the application processor APROC or the enclave TEE no longer has access to it. However, in certain secure applications, in particular those running on a separate hardware wallet, provision is made for transaction data to be displayed simultaneously on the screen of the host device (a mobile phone or PC running, for example, the "Ledger Live" software) and on the display of the hardware wallet. Thus, the user is able to verify at a glance that the transaction data presented by the application are identical to those presented by the hardware wallet and will be executed by the secure element.

[0113] It was noted above that when a hardware wallet is embedded in a smartphone, such functionality is not feasible given the difficulty of providing a second display and the additional cost this would entail. It is therefore proposed that the display of transaction data be placed under the control of a secure element.

[0114] In such Figure 8In the embodiment SPH6 of the connected terminal with integrated hardware wallet shown in , a dynamic multiplexer DYMUX is provided to allow the secure element eSE and the application processor APROC to simultaneously present information on the display by embedding the secure image provided by the secure element in the non-secure image provided by the application processor. The secure image is embedded in an area 10 of the display DISP. The rest of the available display surface forms an area 9, which receives the part of the non-secure image that is not masked by the embedded secure image. Areas 9 and 10 are preferably such that they together cover the entire available display surface.

[0115] Such image embedding significantly improves the security provided by the terminal and its ergonomics when conducting transactions. For example, the application processor may display the following information in area 9: "You wish to purchase 2 Bitcoins for 50,000 USD", while the secure element displays the following information in area 10 of the display: "Please confirm your purchase of 2 Bitcoins for 50,000 USD" and a representation of a verification button on which the user must perform a touch action to trigger the transaction.

[0116] As another example, the application processor may display the following message in area 9: "Please confirm your request to purchase 2 bitcoins worth 50,000 USD by confirming the number of bitcoins you want to purchase on the secure touch keypad and then confirming the value of the transaction," while the secure element displays a virtual keyboard in area 10 allowing the user to enter two transaction details (here, the number of bitcoins and the transaction value).

[0117] In yet another variation, button B is used to confirm the transaction, the application processor displays the following information in area 9: "Please confirm your request to purchase 2 bitcoins worth 50,000 USD by pressing button B", while the secure element displays the same information in area 10: "Please confirm your request to purchase 2 bitcoins worth 50,000 USD by pressing button B". Any difference between the transaction details displayed by the application processor and the secure element will be perceived by the user due to the simultaneity of these displays.

[0118] Figure 8 The implementation scheme SPH6 shown in FIG. 6 that allows such image embedding is similar to Figure 7 The embodiment SPH5 shown in FIG. 5 differs in that the previously described hardware multiplexer MUX is replaced by a dynamic multiplexer DYMUX. The dynamic multiplexer DYMUX comprises a hardware multiplexer MUXi similar to Figure 7The multiplexer MUX has a first input connected to the bus DISPB1 of the application processor, a second input connected to the bus DISPB2 of the display controller DMCU of the secure element eSE, and an output connected to the bus DISPB controlling the display. The dynamic multiplexer DYMUX also includes a synchronization circuit SYNCT, which provides a signal SEL to the multiplexer MUXi and receives an image overlay authorization signal PIP provided by the pin GPIO3 of the secure element.

[0119] The signal PIP has an active value and an inactive value which in practice correspond to two logical values ​​of this signal (for example 0 and 1, or vice versa). The secure element sets the signal PIP to an inactive value when it is not requested for a transaction or when it is not or no longer required to interface with the user. In this case, the synchronization circuit SYNCT commands the multiplexer MUXi so that the bus DISPB is permanently connected at its output to the bus DISPB1 of the application processor. The application processor then has full control over the entire display.

[0120] When it switches to secure mode to participate in the execution of a transaction, and / or when it needs to interface with a user, the secure element sets the signal PIP to its active value, which triggers the superposition of the image data provided by the application processor and the image data provided by the secure element through the display controller DMCU, in the rhythm of the change of the value of the SEL signal provided by the SYNCT circuit.

[0121] The image data provided by the application processor APROC are then displayed in area 9 of the display and the image data provided by the display controller DMCU are displayed in area 10. More precisely, the image data provided by the application processor and corresponding to area 10 are replaced or overwritten by the image data provided by the security element, so that the image data displayed in area 9 are those that are not overwritten by the image data provided by the display controller DMCU.

[0122] To provide the SEL signal, the SYNCT circuit takes into account the configuration data SDT (“Setup Data”) which determine the size, shape and position of the area 10 occupied by the embedded image. The SYNCT circuit also takes into account the synchronization information obtained or extracted from the buses DISPB1, DISPB2 and DISPB so that the transition between the image data provided by the application processor APROC on the bus DISPB and the image data provided by the display controller DMCU does not cause the appearance of artifacts or image tearing.

[0123] In one embodiment, the size of the area 10 is fixed and the configuration data SDT is hard-coded in the configuration register SREG of the multiplexer DYMUX. For example, the SDT data comprises the position of the first row of the area 10 and the position of the last row (which determines the height h of the area 10), or equivalently, the position of the first row and the number of subsequent rows. Alternatively, if it occupies the entire bottom part of the display, the data SDT may only comprise the position of the first row of the area 10. In another embodiment, the configuration register is instead configurable and the configuration data SDT is received from the outside, for example provided by the display controller DMCU at the request of the secure element, or directly by the secure element.

[0124] As previously mentioned, the output bus DB1 of the touch panel KBD (here of I2C type) is connected to the input of a demultiplexer DMUX, a first output of which is connected via a bus DB11 to the application processor APROC and a second output via a bus DB12 to the secure element eSE.

[0125] The selection of the demultiplexer DMUX is here operated by the signal PIP so that the secure element has exclusive control of the touch panel during the entire period when the terminal operates in secure mode and the image portion provided by the application processor is replaced by the image portion provided by the secure element. It is therefore impossible and in practice hardly necessary for the application processor to provide touch functionality to the user in area 9 during operation in secure mode, unless provision is made for these to be handled by the secure element which then relays the touch information to the application processor.

[0126] If this may have practical or ergonomic significance, a person skilled in the art may still provide a more complex implementation so that the application processor receives in real time the touch data corresponding to the area 9 of the display on which it can display information. For this purpose, the demultiplexer DMUX may be controlled, for example, by a signal SEL provided by the SYNCT circuit.

[0127] The risk analysis attached to each terminal configuration proposed in this application reveals here the following risk: a malicious program that has gained control of the application processor or the bus DISPB1 can display information in area 10 that simulates the information displayed by the secure element during the execution of a transaction. Therefore, after requesting a transaction from the user himself, the user may be induced to believe that the transaction is being executed by the secure element, while area 10 is still under the control of the application processor and the secure element has not been requested. Therefore, it is necessary to ensure that the user is fully informed that the information displayed in area 10 does come from the secure element. In order to overcome this problem, two cases are distinguished:

[0128] 1) Region 10 has a fixed height h0 and occupies a fixed position on the display across the width of the display. For example, region 10 occupies "N" of the display corresponding to height h0.

[0129] The last line, such as Fig. 9A shown.

[0130] 2) The area 10 has a variable height h and may be located at a variable position over all or part of the height of the display, the height h of the area 10 and its position being defined by the configuration data SDT. Fig. 9B In the example shown, region 10 has a height h1 and occupies the entire lower portion of the display. Fig. 9C In another example shown, region 10 has a height h2 greater than h1 and extends substantially over the lower two thirds of the display without occupying the lower portion of the display.

[0131] In an embodiment corresponding to the first case, the safety element is configured to activate the light indicator LD when it sets the signal PIP to an active value. Fig. 9A As shown, the user is fully informed of the secure element control area 10 by a light indicator LD under the exclusive control of the secure element via pin GPIO2. As an additional means of informing the user, the position of the area 10 can be indicated by a visual mark (such as a color bar VM provided on the terminal housing close to the display over the entire height of the area 10).

[0132] In an embodiment corresponding to the second case, a row LR of light indicators Li, each formed by an LED, is arranged along the display and extends over all or part of its height. The row of light indicators is driven by an input / output pin GPIOi of the security element and is provided to indicate the precise position of the area 10, each light indicator being individually controlled by the security element. Thus, in Fig. 9B In the example shown in Figure 1, the safety element lights up the first seven diodes L1 to L7 and Fig. 9C In the example of , the security element lights up diodes L6 to L15. Thus, the user is fully informed that the security element controls the area 10 and is also informed of the location of this area 10. In such an embodiment, the row LR of light indicators replaces the previously described single light indicator LD, which is no longer necessary.

[0133] In corresponds to the second case and Fig.9D , Fig.9E In another embodiment illustrated in , two measures are provided to define the area 10 and to inform the user that the secure element controls the area:

[0134] i) One or more rows of the display (e.g. the last row or rows) form a reference area 101 under permanent control of the secure element due to a corresponding configuration of the dynamic multiplexer DYMUX. This configuration, independent of the value of the signal PIP, prevents the application processor from displaying information in this area.

[0135] ii) When the security element switches to secure mode and controls area 10, it frames it with a border 102 having the same determined appearance as area 101. If area 10 is not in a direct extension of area 101, the security element may also and optionally display a linking area 103 connecting border 102 to area 101, having the same appearance as area 101.

[0136] The above-mentioned appearance of the reference area 101 is preferably variable and random. It may have a determined color or a determined color combination, a determined pattern including a color combination or grayscale gradient, a determined visual texture, an extract of a photo, etc. Assuming that a malicious program cannot access the information transmitted by the security element to the display controller DMCU (which determines the appearance of the reference area 101), such a malicious program will not be able to frame it by a border 102 having the same appearance as the reference area 101 if it wants to simulate the area 10.

[0137] The specific implementation of the dynamic multiplexer DYMUX can be realized in various ways within the capabilities of those skilled in the art. Figures 10 to 15 Some embodiments are described and the figures show embodiments of the multiplexer DYMUX1, DYMUX2, DYMUX3, DYMUX4, DYMUX5 and DYMUX6.

[0138] Fig.10 The dynamic multiplexer DYMUX1 comprises a hardware multiplexer MUX1, a synchronization circuit SYNCT1 and a configuration register SREG. In the embodiment considered here, the buses DISPB1, DISPB2 each convey data packets (respectively IPAQ1, IPAQ2) forming pixels, as well as clock signals (respectively CLK1, CLK2) and synchronization signals (respectively TE1, TE2) conventionally used as a means to prevent image tearing ("tearing effect signals"). Depending on the value of the signal SEL, the image data IPAQ provided at the output of the multiplexer MUX1 is the data IPAQ1 or the data IPAQ2, the clock signal CLK is the signal CLK1 or the signal CLK2, and the frame end signal TE is the signal TE1 or the signal TE2. For example, for an image refreshed at a frequency of 50 Hz, this last signal is emitted every 20 ms.

[0139] The SYNCT1 circuit has a row counter LCPT that counts rows displayed on the bus DISPB and is configured to determine a time T1 at which a packet present on the bus DISPB1 is provided on the bus DISPB, and a time T2 at which a packet present on the bus DISPB2 is provided on the bus DISPB to replace the packet present on the bus DISPB1 (i.e., a time at which the signal SEL changes value) based on configuration data SDT present in the register SREG.

[0140] In order to allow precise control of the times T1 and T2, the synchronization circuit SYNCT1 obtains synchronization information SI1, SI2, SI from the buses DISPB1, DISPB2 and DISPB. The synchronization information SI1, SI2, SI comprises, for example, clock signals CLK1, CLK2, CLK and frame end signals TE1, TE2, TE. The synchronization circuit SYNCT1 also comprises pixel counters PCPT1, PCPT2, PCPT respectively associated with the buses DISPB1, DISPB2, DISPB, each of which provides an end-of-line signal (respectively LEP1, LEP2, LEP) ("end-of-line pulse"). Each counter is reset after detecting the end of a line and then counts the number of pixels again until the number of pixels of the line is reached, after which it again issues an end-of-line signal and resets to zero, etc. The operation of these counters is within the capabilities of a person skilled in the art and relies on known principles of video signal analysis. In practice, the length of a line is known by analyzing the content of all the data packets it contains. The end-of-line signal may also be detected via an analog measurement system, since the end-of-line on a MIPI signal corresponds to a transition in the voltage of the electrical signal from a value of approximately 200 mV to a value of approximately 2 V. Thus, a Schmitt trigger may also be used to determine the end-of-line.

[0141] The synchronization circuit SYNCT1 transmits synchronization data SYNCDT1 related to the bus DISPB1 and the bus DISPB to the display controller DMCU, and transmits synchronization data SYNCDT2 related to the bus DISPB2 and the bus DISPB to the application processor APROC. The synchronization data SYNCDT1 includes, for example, frame end signals TE1, TE, line end signals LEP1, LEP, and clock signals CLK1, CLK. The synchronization data SYNCDT2 includes, for example, frame end signals TE2, TE, line end signals LEP2, LEP, and clock signals CLK2, CLK. Therefore, the application processor APROC receives information about the state of the bus DISPB2 controlled by the display controller DMCU, and conversely, the display controller DMCU receives information about the state of the bus DISPB1 controlled by the application processor APROC. The application processor and the display controller can therefore implement a common synchronization strategy that allows the circuit SYNCT1 to apply the signal SEL to the hardware multiplexer MUX1 without causing the appearance of artifacts or tearing of the displayed image. However, it is not necessary in practice to provide an immediate switch between the two buses DISPB1, DISPB2. In practice, for most screens it is possible to have a certain delay in supplying the row data. Therefore, the multiplexer switching may have such a "delay" between stopping the stream conveyed by the bus DISPB1 and applying the stream conveyed by the bus DISPB2, or vice versa, which delay is however not too important at the risk of changing the display frequency.

[0142] The implementation of the multiplexer DYMUX1 just described is general and can be simplified by using only a portion of the synchronization signals described above. As an example, Fig.11The dynamic multiplexer DYMUX2 comprises a hardware multiplexer MUX2 of the same type as the multiplexer MUX1 and a simplified synchronization circuit SYNCT2. The latter comprises only a pixel counter PCPT which provides a line end signal LEP and extracts a frame end signal TE from the data circulating on the output bus DISPB. The line end signal LEP and the frame end signal TE are transmitted to the display controller DMCU and the application processor APROC so that they are recalibrated to the same reference at each new line and each new image. The display controller DMCU also receives the clock signal CLK1 from the bus DISPB1 and itself ensures that the signal SEL is provided to the hardware multiplexer MUX2. For this purpose, the display controller DMCU is provided with a configuration register SREG, a line counter LCPT, and receives a signal PIP. Signal PIP allows it to determine, from configuration data SDT present in register SREG, time T1 at which a packet present on bus DISPB1 will be provided on bus DISPB, and time T2 at which a packet present on bus DISPB2 will be provided on bus DISPB instead of a packet present on bus DISPB1.

[0143] In this embodiment, the display controller DMCU automatically adapts to the clock signal CLK1 of the bus DISPB1 controlled by the application processor and can replace the image data provided by the display controller DMCU of the security element without causing the occurrence of artifacts or tearing of the displayed image.

[0144] Fig.12 The dynamic multiplexer DYMUX3 includes a hardware multiplexer MUX3, a synchronization circuit SYNCT3, a register SREG, a receiving circuit RX1 connected to a bus DISPB1, a receiving circuit RX2 connected to a bus DISPB2, a line buffer LBUF1 whose input is connected to the output of the circuit RX1 and whose output is connected to a first input of the multiplexer MUX3, a line buffer LBUF2 whose input is connected to the output of the circuit RX2 and whose output is connected to a second input of the multiplexer MUX3, and a transmitting circuit TX whose input is connected to the output of the multiplexer MUX3 and whose output is connected to the bus DISPB. Fig.10 , Fig.11Unlike the multiplexers MUX1, MUX2 of the SYNCT3 circuit, the multiplexer MUX3 is a multiplexer of raw digital data and not of received image data encapsulated in frames decoded according to the determined protocol. In practice, the raw data conveyed on the bus DISPB1 are decoded or more precisely decapsulated by the receiving circuit RX1 and then loaded into the line buffer LBUF1 in order to then be applied to the first input of the multiplexer MUX3. Similarly, the raw data conveyed on the bus DISPB2 are decapsulated by the receiving circuit RX2 and then loaded into the line buffer LBUF2 in order to then be applied to the second input of the multiplexer MUX3. For this purpose, the SYNCT3 circuit applies the write signals W1, W2 and the read signals R1, R2 to the buffers LBUF1, LBUF2.

[0145] The receiving circuits RX1, RX2 provide the circuit SYNCT3 with synchronization information SI1, SI2, allowing it to count the number of lines of the image that have been displayed and to determine the time T1 at which the content of the buffer LBUF1 is applied to the input of the transmitting circuit TX and the time T2 at which the content of the buffer LBUF2 is applied to the input of the transmitting circuit TX. The transmitting circuit TX reconstructs, on the bus DISPB, from the raw data provided by the buffers LBUF1, LBUF2, a video frame decoded according to the desired protocol, which may be the same as the protocol of the buses DISPB1, DISPB2 or another protocol. The circuit TX also communicates synchronization information SI3 to the circuit SYNCT3, allowing it to perfect the control of the multiplexer MUX3.

[0146] Fig.13The dynamic multiplexer DYMUX4 comprises a hardware multiplexer MUX4 and a synchronization circuit SYNCT4 of the same or the same type as the multiplexer MUX3. It differs from the multiplexer DYMUX3 mainly in that the receiving circuit RX2 is removed and the line buffer LBUF2 is replaced by an extended line buffer ELBUF2, which can receive raw data corresponding to several lines of the image to be embedded. The display controller DMCU directly accesses the extended line buffer ELBUF2 without providing a video signal. For this purpose, the bus DISPB2 can simply be an I2C or SPI bus instead of a bus carrying video frames according to the MIPI-DSI protocol or other video protocols. When the buffer ELBUF2 has been filled by the display controller DMCU, the synchronization circuit SYNCT4 performs several buffer read cycles in order to provide its content to the multiplexer MUX4 by continuously applying the row address LAD2 (followed by the read signal READ2) to the buffer. To avoid visual artifacts due to updating data in the extended line buffer ELBUF2, a double buffer system may be provided, using the first buffer while the second buffer is filled, then using the second buffer (once filled) while the first buffer is filled, and so on.

[0147] Fig.14 The dynamic multiplexer DYMUX5 comprises a hardware multiplexer MUX5 and a synchronization circuit SYNCT5 which are the same or of the same type as the multiplexers MUX3 and MUX4. It differs from the multiplexer DYMUX4 mainly in that the extended line buffer ELBUF2 is replaced by the page buffer PBUF2, in which the display controller DMCU has previously loaded the area 10 ( Figure 8 )

[0148] Can also be applied to Fig.12 and Fig.13 Implementation of the Fig.15In the alternative embodiment shown, the dynamic multiplexer DYMUX6 comprises a multiplexer MUX6, the output of which is applied to a page buffer PBUF3, instead of being applied directly to the transmission circuit TX, which is previously loaded with all the rows of the page before its content is applied to the circuit TX for generating the video signal on the bus DISPB. This previously stored complete page may include rows provided by the application processor and rows provided by the display controller DMCU, which occupies the area 10. In this case, the multiplexer MUX6 is no longer of the same type as the multiplexer described previously, and although it is still represented here by the term "multiplexer" because it provides the same technical effect, it forms a buffer-to-buffer copy system with two input channels and one output channel. Although the embodiment of the dynamic multiplexer just described ensures that the image data provided by the security element is embedded with an embedding granularity or embedding pitch in proportion to the rows of the image data provided by the application processor, a person skilled in the art may modify this embedding pitch according to the ultimate goal in terms of ergonomics and user experience. In some embodiments, the embedding pitch may be partially in proportion to the pixels of the image data provided by the application processor. For example, in Fig.14 In an embodiment of the present invention, the multiplexer MUX5 can be configured to select image data from the buffers LBUF1 and PBUF2 pixel by pixel and thus fill the output buffer PBUF3 pixel by pixel.

[0149] Fig.16 Illustrated based on Figures 4 to 8 , Figures 10 to 14 Layout of the components of a mobile terminal (smartphone) of one of the above. The application processor APROC and its final enclave TEE may be part of a system-on-chip SoC ("system on a chip"). The application processor APROC or the SoC receiving it comprises pins soldered to corresponding tracks of a printed circuit board or other interconnection support receiving several other components. The corresponding sets of pins are associated with different communication links between the components, in particular the aforementioned buses DISPB, DISPB1, DB1, DB2, DB11.

[0150] The display DISP and the touch panel KBD are usually outside the printed circuit board and parallel to the printed circuit board. Their control buses are then connected to the printed circuit board through connectors soldered to the tracks of the printed circuit board.

[0151] In one embodiment, the above-mentioned elements (in particular the elements eSE, DMCU, MUX or DYMUX and DMUX) that allow the realization of an embedded hardware wallet, as well as the bus connecting them and possible connectors of all or part of the elements B, S, LD, LR, can be integrated into a system-in-package SiP designed to be mounted on a printed circuit board. Alternatively, these elements can be integrated in another SoC.

[0152] Therefore, in order to integrate the hardware wallet into the mobile terminal device, a space for soldering the system-level package SiP is arranged on the printed circuit board, the tracks of the different buses used are rewired by interruption so that they pass through the SiP, and the tracks are set to establish a secure connection between the processor APROC and the secure element eSE.

[0153] The different discrete physical elements managed by the SiP's circuitry (buttons B, switches S, light indicators LD) can be fixed to the terminal's housing and connected to connectors of the SiP, or to connectors of a printed circuit board, themselves connected by tracks to dedicated pins of the SiP.

[0154] With this configuration, a conventional mobile terminal can be converted into a mobile terminal including an embedded hardware wallet by simply adding a SiP on a printed circuit board carrying the components of the conventional terminal. Although the design of the adapted printed circuit board presents certain development and production costs, the costs are still negligible because no adaptation is performed at the level of the hardware platform of the conventional terminal.

[0155] The foregoing description is substantially written in the context of a smartphone embedded with a hardware wallet for signing transactions on a blockchain (a "blockchain smartphone"). It will be apparent to one skilled in the art that the components and methods just described for ensuring control of a display by a secure element during the signing of a transaction are applicable to any security operation requiring that same control. The components and methods described are also applicable to any type of terminal connected to the Internet or a local network that stores secrets for various purposes involving cryptographic computations, such as signing and authentication of general transactions (including "zero-knowledge" authentication). In other types of connected terminals, the human-machine interface may be a display or joystick associated with a physical keyboard.

Claims

1. A connected terminal (SPH6) configured to perform a security operation, the terminal comprising: - an application processor (APROC) configured to initiate said security operation, - a secure element (eSE), the secure element being used to perform the secure operation, and a display (DISP) which is accessible via a wired bus (DISPB) and which receives from the application processor image data to be displayed to a user, Characterized in that the terminal comprises a component (DYMUX, MUXi) which is controlled by the security element and is configured to, at the request of the security element (PIP) and at least during the execution of the security operation, alternately apply image data (IPAQ1) provided by the application processor and image data (IPAQ2) provided by the security element to the wired bus (DISPB) of the display, so that the image data provided by the security element replaces the image data provided by the application processor and forms a security image embedded in the non-security image provided by the application processor, the security image extending in at least one determined area (10) of the display.

2. A terminal according to claim 1, comprising at least one light indicator (LD, LR), which is activated by the security element when the security element embeds a secure image in a non-secure image provided by the application processor.

3. Terminal according to one of claims 1 and 2, comprising means (VM, LR, 101, 102, 103) for indicating to the user the position and extent of the area (10) in which the embedded security image is displayed.

4. The terminal according to claim 3, wherein the means for indicating the position and extent of the area (10) where the embedded security image is displayed comprises: A row (LR) of light indicators (Li) controlled by the security element and arranged along the edge of the display.

5. The terminal according to claim 3, wherein the means for indicating the position of the area (10) where the embedded security image is displayed comprises: a region (101) of the display (LR) which is permanently under the control of the security element and which displays a determined appearance, - a border (102) of the area (10) showing the embedded security image, said border having the same appearance as the area (101) of the display permanently under the control of the security element.

6. The terminal according to any one of claims 1 to 5, wherein the component (DYMUX, MUXi) configured to alternately apply image data (IPAQ1) provided by the application processor and image data (IPAQ2) provided by the secure element to the wired bus (DISPB) of the display comprises: a multiplexer (MUXi, MUX1-MUX5) receiving on a first input the image data (IPAQ1) provided by the application processor and on a second input the image data (IPAQ2) provided by the secure element, and - a control circuit (SYNCT, SYNCT1-SYNCT5, SREG, DMCU) of the multiplexer, the control circuit being configured to control (SEL) the multiplexer as a function of configuration data (SDT) provided by the secure element.

7. A terminal according to claim 6, wherein the control circuit (SYNCT, SYNCT1-SYNCT5, SREG, DMCU) is configured to control the multiplexer by a determined embedding granularity of the image data provided by the security element, the embedding granularity being a ratio of a row or a ratio of a pixel of the image data provided by the application processor. 8 . The terminal according to claim 1 , wherein the secure element is configured to embed a secure image including information about the secure operation in a non-secure image provided by the application processor before performing the operation.

9. The terminal according to one of claims 1 to 8, further comprising: An input device (KBD) providing touch data on a data bus (DB1) and a demultiplexer (DMUX), the demultiplexer being controlled by the secure element (eSE) and configured to connect the data bus (DB1) of the input device to a bus (DB11) of the application processor or a bus (DB12) of the secure element.

10. Terminal according to claims 8 and 9, wherein said secure element is configured to be connected to said input device (KBD) during display of information about said operation in said secure image.

11. A terminal according to any one of claims 1 to 10, comprising a physical button (B, S) operable by the user and monitored by the security element (eSE), wherein the security element is configured to bypass the operation in the absence of a user action on the physical button (B, S).

12. A terminal according to any one of claims 1 to 11, wherein the security element (eSE) and the component (DYMUX, MUXi) for alternately applying the image data (IPAQ1) provided by the application processor and the image data (IPAQ2) provided by the security element to the wired bus (DISPB) of the display are fully or partially integrated in a system-in-package (SiP) or a system-on-chip (SoC) mounted on an interconnect support of the terminal.

13. Terminal according to one of claims 1 to 12, wherein said security operation comprises a step of signing data using a secret key.

14. A terminal according to one of claims 1 to 13, wherein there is no display controller between the display and the component (DYMUX, MUXi) controlled by the secure element, and the image data applied alternately to the wired bus (DISPB) of the display through the component (DYMUX, MUXi) controlled by the secure element is in a format compatible with the display (MIPIDSI) and does not need to be converted into another format in order to be displayed.

15. A method for performing a security operation using a connected terminal (SPH6), in particular signing data using a secret key, the terminal comprising: - an application processor (APROC) configured to initiate said security operation, - a secure element (eSE) holding a private key and configured to perform said secure operation, and a display (DISP) accessible via a wired bus (DISPB) and receiving from the application processor non-secure images relating to the progress of the secure operation, The method is characterized in that it comprises a step of embedding a secure image provided by the secure element and inaccessible to the application processor in at least one non-secure image provided by the application processor and presented on the display, the secure image comprising information about the operation and extending in at least one determined area (10) of the display, the embedding step being under the control of the secure element and not being able to be blocked or corrupted by the application processor.

16. The method according to claim 15 includes the step of providing a component (DYMUX, MUXi) in the terminal, which is controlled by the secure element and is configured to alternately apply image data (IPAQ1) provided by the application processor and image data (IPAQ2) provided by the secure element to the wired bus (DISPB) of the display under the request (PIP) of the secure element, so that the image data provided by the secure element replaces the image data provided by the application processor and forms the secure image embedded in the non-secure image provided by the application processor.

17. A method according to claim 16, wherein image data in a format compatible with the display (MIPIDSI) and not requiring conversion into another format in order to be displayed are applied alternately to the wired bus (DISPB) of the display, and no display controller is provided between the display and the component (DYMUX, MUXi) controlled by the secure element.

18. A method according to one of claims 15 to 17, comprising providing at least one light indicator (LD, LR) in the terminal and comprising a step of activating the light indicator by the security element when the security element embeds a secure image in a non-secure image provided by the application processor.

19. Method according to one of claims 15 to 18, comprising the step of indicating to the user the position and extent of the area (10) in which the embedded security image is displayed.

20. A method according to claim 19, wherein the position and extent of the area (10) displaying the embedded security image is indicated by a row (LR) of light indicators (Li) controlled by the security element and arranged along the edge of the display.

21. The method according to claim 19, wherein the position and extent of the area (10) where the embedded security image is displayed is indicated by: - a region (101) of the display (LR) which is permanently under the control of the security element and has a defined appearance, and - a border (102) of the area (10) showing the embedded security image, said border having the same appearance as the area (101) of the display permanently under the control of the security element.

22. A method according to one of claims 15 to 21, wherein the device comprises an input device (KBD) providing touch data on a data bus (DB1), and comprising the step of connecting the input device (KBD) to the security element during display of information about the security operation in the embedded security image.

23. A method according to one of claims 15 to 22, wherein the device comprises a physical button (B, S) operable by the user and monitored by the security element (eSE), and comprising a step of configuring the security element so that the security element bypasses the execution of the security operation in the absence of a user action on the physical button (B, S).

Images