Connected terminal including means for embedding a secure image into an insecure image.

Abstract

A method for conducting a secure operation using a connected terminal (SPH6) comprising an application processor (APROC), a secure element (eSE) configured to perform the operation using a private key, and a display (DISP) receiving insecure images from the application processor relating to the progress of the secure operation. The method includes a step of overlaying, into at least one insecure image provided by the application processor and displayed on the display, a secure image provided by the secure element and not accessible to the application processor, the secure image containing information about the secure operation and extending into at least one defined region (10) of the display. Fig. 8

Description

Title of the invention: Connected terminal comprising means for embedding a secure image into an insecure image. technical field

[0001] The present invention relates to the integration of a secure function into a connected terminal such as a smartphone, and in particular the integration of a hardware crypto-asset wallet function. The present invention also relates to the control of information presented to a user on a terminal screen during the execution of a secure operation. Background

[0002] In recent years, the development of cryptocurrencies and other types of crypto-assets managed by blockchain, such as non-fungible tokens (NFTs) and smart contracts, has given rise to various methods of storing and safeguarding the private keys associated with these different types of crypto-assets. This has led to the emergence of the concepts of "wallet," "cold storage," and "hot storage" of private keys. A "wallet," also called a "cash wallet," is a device or program whose function is to manage crypto-assets and thus store the private keys associated with them. So-called "hot wallets" are connected to the internet and are susceptible to attacks by hackers or exposure to viruses and malware. These may be wallets managed by centralized exchange platforms, which do not offer 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 constantly connected to the internet and integrate numerous insecure applications, making them susceptible to attack.

[0003] Cold wallets are the most secure solution for the cold storage of private keys, that is, without 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 it.

[0004] Hardware wallets are a practical alternative to passive wallets for storing keys private keys. Furthermore, they are generally configured to generate recovery phrases, allowing the private keys to be restored if lost. It's important to remember that cryptocurrencies are never stored in a hardware wallet but are recorded on the blockchain. A hardware wallet only stores the private keys used to manage transactions on the blockchain. The public keys, corresponding to the private keys, point to an address on the blockchain where the assets are actually located.

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

[0006] The hardware wallets marketed by the applicant have enjoyed significant commercial success due to the high degree of security they offer, thanks to the use of a secure element to store private keys and sign transactions. A secure element is a hardware platform capable of storing and manipulating data in accordance with the rules and security requirements established by a trusted authority. It takes the form of a semiconductor chip implementing various countermeasures designed to thwart attacks by fraudsters.

[0007] Figure 2 shows the architecture of a hardware wallet HW1 of the type marketed by the applicant under the name "Nano S". The hardware wallet HW1 comprises a secure element SE1 associated with a microcontroller MCU1. The microcontroller MCU1 has a USB interface U1 and acts as a proxy device for the secure element SE1, for communication with an external host device HDV running companion software (see Figure 1). The secure element SE1 has its own secure operating system (firmware) allowing it to execute APP programs, and integrates a cryptographic coprocessor CRY. The hardware wallet HW1 also includes a display DISP1 and two buttons B1 and B2 controlled by the microcontroller MCU1. The user must press both buttons simultaneously to indicate their agreement or consent for the execution or completion of these operations.

[0008] Hardware wallets of the type just described lack internet connectivity and must be paired with a host device such as a mobile terminal or smartphone when making a transaction. They offer a high degree of security because they are mostly inaccessible via public networks and therefore less exposed to attacks. However, this characteristic makes them somewhat inconvenient and prone to being misplaced or forgotten.

[0009] So-called "blockchain" smartphones have been proposed which, while offering the usual functionalities of a mobile phone, integrate a hardware cryptocurrency wallet, such as the Samsung® Galaxy S10, the HTC® Exodus 1, or the Sirin Labs® Finney. Such smartphones are commonly called "blockchain smartphones" or "crypto-smartphones." Like hardware wallets, such smartphones are equipped with an embedded secure element and internal storage inaccessible via the Internet, allowing the creation of a cryptocurrency wallet. In other embodiments, the main processor has a secure enclave or Trusted Execution Environment (TEE) instead of the secure element.

[0010] Despite these precautions, implementing a hardware wallet within a smartphone inevitably increases the wallet's exposure to internet attacks and does not offer the same security advantages as a true cold wallet. Furthermore, it is not possible for the user to reliably verify the trustworthiness of displayed data, as it could be provided by malicious software.

[0011] It might therefore be desirable to improve the security offered by connected portable terminals such as smartphones integrating a hardware cryptocurrency wallet. Summary

[0012] Embodiments relate to a connected terminal configured to perform a secure operation, the terminal comprising an application processor configured to initiate the secure operation, a secure element to perform the secure operation, and a display accessible via a hardwired bus and receiving image data from the application processor to be displayed to a user, the terminal comprising means controlled by the secure element and configured to, at the request of the secure element and at least during the execution of the secure operation, alternately apply to the display's hardwired bus image data provided by the application processor and image data provided by the secure element, such that the image data provided by the secure element replaces image data provided by the application processor and forms a secure image embedded within an insecure image supplied by the application processor, the secure image extending into at least one specified region of the display.

[0013] According to one embodiment, the terminal includes at least one light indicator activated by the secure element when the secure element overlays a secure image into an insecure image provided by the application processor.

[0014] According to one embodiment, the terminal includes means for indicating to the user the location and extent of the region in which the embedded secure image is displayed.

[0015] According to one embodiment, the means for indicating the location and extent of the region in which the embedded secure image is displayed include a row of light indicators controlled by the secure element and arranged at the edge of the display.

[0016] According to one embodiment, the means for indicating the location of the region in which the embedded secure image is displayed include a region of the display which is permanently under the control of the secure element, and which displays a determined appearance, and a border of the region in which the embedded secure image is displayed, which has the same appearance as the region of the display which is permanently under the control of the secure element.

[0017] According to one embodiment, the means configured to alternately apply to the wired bus of the display image data provided by the application processor and image data provided by the secure element, comprise a multiplexer receiving on a first input the image data provided by the application processor and on a second input the image data provided by the secure element, a control circuit for the multiplexer, configured to control the multiplexer according to a configuration data provided by the secure element.

[0018] According to one embodiment, the control circuit is configured to control the multiplexer with a determined overlay fineness of the image data provided by the secure element, said overlay fineness being at the scale of a line or at the scale of a pixel of the image data provided by the application processor.

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

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

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

[0022] According to one embodiment, the terminal includes a physical button that can be operated by the user and is monitored by the secure element, in which the secure element is configured not to perform the operation in the absence of an action by the user on the physical button.

[0023] According to one embodiment, the secure element and the means for alternately applying image data provided by the application processor and image data provided by the secure element to the wired bus of the display are integrated in whole or in part into a system-in-a-box or into a system-on-a-chip mounted on an interconnection support of the terminal.

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

[0025] Embodiments also relate to a method for conducting a secure operation using a connected terminal, in particular the signing of data using a secret key, the terminal comprising an application processor configured to initiate the secure operation, a secure element holding a private key and configured to execute the secure operation, and a display accessible via a wired bus and receiving from the application processor insecure images relating to the progress of the secure operation, the method comprising a step of embedding, in at least one insecure image provided by the application processor and presented on the display, a secure image provided by the secure element and not accessible to the application processor, the secure image comprising information on the operation and extending into at least one determined region of the display,The embedding step is under the control of the secure element and cannot be prevented or corrupted by the application processor.

[0026] According to one embodiment, the terminal includes the method comprising the step of providing in the terminal means controlled by the secure element and configured to, at the request of the secure element, alternately apply to the wired bus of the display image data provided by the application processor and image data provided by the secure element, so that the image data provided by the secure element replaces image data provided by the application processor and forms said secure image embedded in the unsecure image provided by the application processor.

[0027] According to one embodiment, the method includes providing at least one light indicator in the terminal, and including a step of activating the light indicator by the secure element when the secure element overlays a secure image into an insecure image provided by the application processor.

[0028] According to one embodiment, the method includes a step of indicating to the user the location and extent of the region in which the embedded secure image is displayed.

[0029] According to one embodiment, the location and extent of the region in which the embedded security image is displayed are indicated by means of a row of light indicators controlled by the security element and arranged at the edge of the display.

[0030] According to one embodiment, the location and extent of the region in which the embedded secure image is displayed are indicated by means of a region of the display which is permanently under the control of the secure element and which has a determined appearance, and a border of the region in which the embedded secure image is displayed, which has the same appearance as the region of the display permanently under the control of the secure element.

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

[0032] According to one embodiment, the device includes a physical button that can be operated by the user and is monitored by the secure element, and the method includes a step of configuring the secure element so that it does not perform the secure operation in the absence of an action by the user on the physical button. Brief description of the drawings

[0033] Examples of connected terminal architectures including a hardware cryptocurrency wallet will be described below, without limitation, in relation to the attached figures, among which:

[0034] - Fig. 1 illustrates classic examples of the use of a hardware wallet via a host device,

[0035] - [Fig.2] shows a classic architecture of a cold hardware wallet,

[0036] - Figure 3 shows a first embodiment of a connected terminal including a physical portfolio,

[0037] - Figure 4 shows a second embodiment of a connected terminal including a physical portfolio,

[0038] - Figure 5 shows a third embodiment of a connected terminal including a physical portfolio,

[0039] - Figure 6 shows a fourth embodiment of a connected terminal including a physical portfolio,

[0040] - Figure 7 shows a fifth embodiment of a connected terminal including a physical portfolio,

[0041] - Figure 8 shows a sixth embodiment of a connected terminal incorporating a hardware wallet and including a dynamic multiplexer to embed a secure image within an insecure image,

[0042] - Fig. 9A, Fig. 9B, Fig. 9C, Fig. 9D and Fig. 9E show various methods of embedding a secure image into an unsecure image,

[0043] - Figure 10 shows a first embodiment of the dynamic multiplexer,

[0044] - Figure

[11] shows a second embodiment of the dynamic multiplexer,

[0045] - Figure 12 shows a third embodiment of the dynamic multiplexer,

[0046] - Figure 13 shows a fourth embodiment of the dynamic multiplexer,

[0047] - Figure 14 shows a fifth embodiment of the dynamic multiplexer,

[0048] - Figure 15 shows a sixth embodiment of the dynamic multiplexer, and

[0049] - Figure 16 shows an arrangement of components of a connected mobile terminal according to one of the embodiments of figures 4 to 8, 10 to 14. Detailed description

[0050] The following will describe connected terminal architectures including an embedded hardware wallet, designed to prevent or at least mitigate attacks made possible by such a configuration. To avoid creating an entirely new ecosystem and to preserve the user experience, compatibility with existing hardware and operating systems (Android, iOS) is sought, along with the use of traditional application distribution channels. Thus, it is assumed that the connected terminal in question is capable of installing and running applications that may originate from unknown or even dubious sources, which increases the challenge of securing transactions with the embedded hardware wallet. It is also assumed that installable applications may gain access to hardware resources during communication with a secure element implementing the hardware wallet.

[0051] For example, malicious software could record key presses to steal a secret code, simulate key presses to falsify a transaction, modify the display to deceive the user about the transaction he is carrying out, etc.

[0052] More specifically, the validation of a transaction on a telephone using a virtual keyboard can be intercepted by low-level spyware having access to The spyware can access the touchscreen interface by recording the coordinates of touches on the touch panel. Without knowing what is displayed, the spyware can assume that the virtual keyboard shown is one of the many traditional keyboards available on the platform, so that the contact coordinates reveal the keyboard keys. The spyware can also access accelerometers or other sensors typically found in a mobile device—touches in different positions on the screen result in different rotational acceleration values ​​on two axes, so the positions of the touches can be deduced.

[0053] To partially address this, conventional applications display a virtual numeric keypad with randomly positioned keys for entering personal identification codes. However, while this measure is useful in hindering the deduction of an identification code, malicious software could deduce that a transaction is in progress and, before the user has completed it, change the amount or the recipient and simulate the user's validation of the transaction by modifying the application's input without modifying the application itself.

[0054] Figure 3 represents an SPH1 embodiment of a mobile terminal or other connected device incorporating a hardware wallet. The mobile terminal includes an APROC application processor connected to various peripheral devices, notably a touchscreen display including a DISP display and a KBD touch panel. The application processor is, for example, a baseband processor providing telephone communications and including Internet connectivity. The processor manages the display via a DISPB bus implementing a specific video interface protocol, for example, the MIPI DSI ("Display Serial Interface") protocol. The MIPLDSI 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 here manages the KBD touchscreen via another interface, for example a DB1 I2C data bus. For the sake of clarity in the drawing, not all elements of a mobile terminal are shown.

[0055] The APROC application processor also incorporates a secure enclave or a Trusted Execution Environment (TEE). Such an enclave typically includes a dedicated processor, memory, and touchscreen manager and is designed to implement a Trusted User Interface (TUI), for example as recommended in the GlobalPlatform® "Trusted User Interface API" document available at the following address:

[0056] https: / / globalplatform.org / wp-content / uploads / 2013 / 06 / GlobalPlatform_Trusted_U ser_Interface_API_v 1.0.pdf

[0057] Thus, this enclave can, according to the instructions executed by the application, manage the DISP display and the input on the KBD touch panel, as shown.

[0058] The mobile terminal also includes an embedded secure element (eSE) implementing a hardware wallet for crypto-assets. The eSE can be similar to that integrated into the detached hardware wallets described previously. It could be the STMicroelectronics® ST33 secure microcontroller, which has, among other things, a secure SPI (Serial Peripheral Interface), two I2C (Inter-Integrated Circuit) interfaces, and various programmable GPIO input / output pins. The link designated LNK in [Fig. 1] between the HDV mobile terminal and the detached hardware wallet (HW), for example, a USB or Bluetooth interface, is here achieved by a permanent wired connection between the secure eSE and the application processor, in this case a DB2 data bus. The DB2 bus is, for example, an SPI bus connected to the eponymous interface of the ST33 microcontroller.To ensure better communication security, the other end of the DB2 bus can be connected to the TEE enclave.

[0059] The realization of the hardware wallet function in the eSE element and the exchanges between the eSE element and the application processor can be in every respect similar to what is known from Figures 1 and 2 and will not be described in further detail.

[0060] Furthermore, one of the GPIO1 input / output pins of the eSE secure element is connected to a physical button B designed to validate transactions by a mechanical operation. The GPIO1 pin is exclusively controlled by the secure element, and its state change cannot be simulated by software running on the application processor. Another GPIO2 input / output pin of the eSE secure element controls an indicator light LD, in this case an LED, to signal that a secure operation is in progress with the hardware wallet in the eSE element. Button B is a dedicated physical button arranged, for example, on a side panel of the mobile terminal, and is visually distinct from the other buttons typically found on the mobile terminal. The indicator light LD is also dedicated and conspicuous compared to the other indicator lights typically found on the mobile terminal.

[0061] With this configuration, a transaction is prepared in the usual way by an official application, such as "Ledger Live," executed by the application processor. When the user needs to validate the transaction, the application uses the TEE enclave to display the transaction on the DISP display and, if necessary, manage an input phase on the KBD touchscreen, such as entering an identification code to unlock the secure element. Transaction validation and signing are delegated to the eSE secure element (the hardware wallet) by commands issued on the DB2 bus via the TEE enclave. If necessary, the unlock code is transmitted to the secure element via the DB2 bus. secure eSE reacts to these commands by activating the LD indicator light and waiting for a press of the B button.

[0062] When the user presses button B, the eSE secure element calculates the transaction signature using the private keys stored in the wallet and transmits the signature to the application via the DB2 bus. Having completed its task, the secure element turns off the LD indicator light and awaits further commands. The application updates the blockchain via a network service, displays relevant information, and awaits further interaction with the user.

[0063] If no action is detected on button B after a certain time has elapsed, the transaction is canceled. The secure element signals this to the application via the DB2 bus, deactivates the LD indicator light, and waits for new commands.

[0064] The physical button B has a function similar to that of buttons B1 and B2 on a standalone hardware wallet of the type shown in [Fig. 2]. If malicious software manages to modify the amount or address of the transaction, it will not be able to simulate validation, which requires the activation of a physical button detectable only by the secure eSE element. Thus, before validating, the user can confirm that the transaction as displayed is indeed the one they initiated. If the transaction has been modified, the user can, in principle, see this on the display and cancel the transaction. Cancellation can be performed conventionally by pressing a virtual button on the touchscreen display. The function of the cancel button cannot be repurposed as a validation function, since validation is only possible using button B, which is managed exclusively by the secure eSE element.

[0065] The LD indicator light is activated and confirms to the user that the secure element is taking over operations and that the requests made to it by the terminal are from a trusted source.

[0066] According to a slightly more expensive variant in terms of manufacturing the mobile terminal casing, two physical buttons can be provided, which must be pressed simultaneously to validate a transaction.

[0067] Despite the display being controlled by the TEE enclave, sophisticated malware could modify the application's input and / or output data to divert it, and in particular to alter the display of transaction information that the user is supposed to verify. For example, the malware could intercept transaction data entered by the application and replace it with fraudulent data, such as the transaction amount and address. Although this is difficult when data entry is done securely via the TEE enclave, such an attack is not impossible given the level of security offered by a TEE enclave. The application would then generate a transaction with modified data for the secure element eSE and a display The incorrect corresponding transaction is displayed. The display, which then reveals the modification, can also be intercepted and altered to match the transaction initially intended by the user. Thus, the user will see seemingly correct transaction data on the display and validate the transaction, but this validation will apply to the fraudulently modified transaction that was surreptitiously delegated to the secure eSE element.

[0068] In a conventional standalone hardware wallet, this type of fraud is thwarted because the hardware wallet displays the transaction it is about to execute on its own screen: the user relies on the transaction displayed by the standalone wallet and can compare it to the one displayed by the application on the terminal. Such functionality is not feasible when the hardware wallet is embedded in a smartphone, given the difficulty of providing a second display and the additional cost this would entail.

[0069] Figure 4 shows an SPH2 embodiment of a mobile terminal integrating a hardware wallet and thwarting this type of display manipulation. The APROC application processor, including the TEE enclave, is integrated into a system-on-a-chip (SoC) that receives a secondary SPROC processor. The SoC can be the NXP® i.MX 8M Plus. The secure element (eSE) is, as before, connected to the TEE enclave via the DB2 bus, for example, an SPI bus. The SPROC processor has its own display manager and can be considered to have a high degree of security because it is isolated from the other circuits of the SoC, similar to a secure element. Thus, like the secure element, the SPROC processor can receive commands from the TEE enclave via the DB2 bus.The SPROC processor's display manager is the sole master of the DIS PB bus and includes an FBI frame memory that the SPROC processor can populate from an FB2 frame memory of the application processor or an FB3 frame memory of the TEE enclave (CPY arrows), or from display data generated by itself, as needed. In another embodiment, the SPROC processor can directly display data from FB2 or FB3 memory using a provided pointer. Such display mechanisms are documented and will not be described in further detail. Thus, depending on the needs of a running application, the DISP display receives its data from the application processor, the TEE enclave, or the SPROC processor itself.

[0070] With this configuration, a transaction is prepared in the usual way by an official application, such as "Ledger Live", executed by the APROC application processor. The KBD touchscreen is still managed by the TEE enclave to secure the user's input of data occurring during a transaction, for example an unlock code or an accepted transaction amount, and delegates The transaction processing is handled by the secure element via the DB2 bus. In order to mitigate known potential vulnerabilities in a display managed by the TEE enclave, the secure element eSE, which is itself connected to the SPROC processor via the DB2 bus, is configured to provide the latter with the transaction data to be validated by the user.

[0071] The secure eSE element is configured to, after receiving the transaction data which it must validate by signing the transaction using a private key, transmit the corresponding display data to the SPROC processor via the DB2 bus, and request the SPROC processor to display them via the FBI display manager, instead of the data which might be present in the FB2 and FB3 frame memories.

[0072] Thus, even if the official application is configured to generate such data and transmit it to the TEE enclave display manager to fill frame memory FB3, or to the application processor display manager to fill frame memory FB2, this data will not be displayed and will be replaced by data provided by the secure element. Consequently, if compromised data produced by the application is present in frame memory FB2 or FB3, this data will be ignored, and the data produced by the secure element in frame memory FB1 will be the one actually displayed.

[0073] This SPH2 embodiment relies on the use of a specific system-on-a-chip that may not be suitable for some smartphone manufacturers. Furthermore, it is susceptible to a type of attack that would trick the secure element into believing it is communicating with the SPROC processor when it is actually communicating with a compromised TEE enclave. The secure element therefore does not have absolute certainty of having access to the display when it believes it does.

[0074] We will describe in what follows embodiments that can be implemented with more conventional components, while offering a high level of security with regard to the control of the data displayed to the user.

[0075] Figure 5 shows an SPH3 embodiment of a mobile terminal derived from the SPH1 embodiment of Figure 3. As before, it comprises the APROC application processor and the TEE enclave, the DISP display, the KBD touchscreen, the eSE secure element, the physical button B connected to GPIO pin 1 for validating transactions, and the LD indicator light controlled by GPIO pin 2 to signal that a secure operation is in progress in the eSE. As before, the KBD touchscreen is controlled by the TEE enclave via the DB1 bus, for example, an I2C bus. The TEE enclave is connected to the eSE secure element via the DB2 bus, for example, an SPI bus.

[0076] The SPH3 terminal differs primarily from the SPH1 terminal in that it includes a DMCU display manager exclusively for the eSE secure element, and a MUX multiplexer whose output is connected to the DISPB bus of the DISP display. This multiplexer receives, via a DISPB1 bus, the display data produced by the APROC application processor on a first input. This display data no longer needs to be managed by the TEE enclave, as shown, but can be if desired. A second input of the multiplexer receives, via a DISPB2 bus, display data generated by the DMCU display manager. A GPIO3 input / output pin of the eSE secure element provides a SEL signal to select the multiplexer input that will be connected to its output.Thus, depending on the value of the SEL signal, the MUX multiplexer connects the DISPB bus of the display to the DISPB 1 bus of the APROC application processor or to the DISPB2 bus of the DMCU display manager. In a variant, the SEL signal can also be taken from the GPIO2 pin which controls the LD indicator light.

[0077] The DMCU display manager receives display commands from the eSE secure element via a DB3 bus, for example, an I2C bus. The I2C protocol offers a relatively low data rate, but is used here to carry only textual and vector display commands, using low bandwidth. The eSE secure element is thus programmed to generate basic display commands for the transactions it processes and transmit them to the DMCU display manager.

[0078] The DMCU display manager is a separate circuit here, because commercially available secure components do not have a graphics processor and do not have sufficient bandwidth to generate the expected raster images on the bus of a display such as that of a modern smartphone. The DMCU display manager is, for example, an STMicroelectronics® STM32 microcontroller including an LCD-TFT display controller equipped with a MIPI-DSI interface.

[0079] The secure element eSE is configured to control the multiplexer MUX so that it applies display data from the application processor APROC to the display DISP by default. When an application requests the secure element eSE to sign a transaction, the eSE sends commands to display the transaction data to the display manager DMCU and switches the multiplexer MUX so that the graphics data produced by the DMCU reaches the display DISP. The LD indicator light is activated, and the secure element eSE awaits user confirmation by monitoring the state of button B.

[0080] Thus, the DISP display presents the user with transaction data actually received and processed by the secure eSE element. If this data has been modified by a malicious program, the user will certainly notice and will be able to cancel the transaction.

[0081] It is also preferable that the capture of information entered by the user on the KBD touchscreen, for example an unlock code or other sensitive information such as a target transaction amount, have a level of security at least equal to that of the display. In the SPH1, SPH2, and SPH3 embodiments just described, this capture is performed by the TEE enclave and therefore offers a lower level of security than the display. A higher level of security might therefore be desirable.

[0082] Figure 6 is a block diagram of an SPH4 embodiment of a mobile terminal that differs from the SPH3 embodiment of Figure 5 in that the DB1 bus output from the KBD touchscreen, here of the I2C type, is connected to the input of a two-output DMUX demultiplexer. A first output of the DMUX demultiplexer is connected to the APROC application processor via a DB11 bus, and a second output of the demultiplexer is connected to the eSE secure element via a DB12 bus. The DMUX demultiplexer can be selected using the same SEL signal as that applied to the MUX multiplexer by the secure element. Preferably, the two DB11 buses are of the same type as the DB1 bus to avoid the need for a protocol converter in the DMUX demultiplexer.

[0083] In this embodiment, no TEE enclave is provided to execute all or part of the applications involving the secure element; these are therefore executed by the APROC application processor, with the exception of the steps delegated to the secure element. However, there is nothing preventing the provision of a TEE enclave and its use to control the DISPB1 and DB11 touch data reception buses during the execution of the non-sensitive phases of the application.

[0084] The secure element eSE is configured to position the multiplexer MUX and the demultiplexer DMUX by default so that they connect the display DISP and the touch panel KBD to the application processor, particularly during a preparatory phase of a transaction. The secure element then modifies the value of the SEL signal during sensitive phases of transaction execution, in order to receive any information provided by the user via the touch panel KBD, and to provide, via the display manager DMCU, the transaction data to be presented to the user.

[0085] Thus, the touchscreen escapes the application's control when it connects to the secure element, and the application can no longer implement the input phase. The input phase is delegated to the secure element, which is configured here to manage a virtual keyboard for input and display.

[0086] In one embodiment, the DB12 bus is connected to input / output pins of the DMCU display manager, instead of being connected to the secure element. This embodiment can be advantageous if the display manager is a microcontroller of the type described above, having a data processing capacity greater than that of the secure element. Since the DMCU display manager is under the control of the secure element, it can then receive and process, on behalf of the secure element, a large amount of data that the latter might not be able to process itself, for example, data from a touchscreen keyboard, and communicate the result of this processing to it via the DB3 bus.

[0087] When a transaction is delegated by the application to the secure element via the DB2 bus, bypassing the TEE enclave, the secure element eSE commands the multiplexer and demultiplexer to connect the DISP display to the DMCU display manager and the KBD touch panel to the secure element eSE. The secure element eSE implements the input phase, if input is required. Input on the touch panel 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.

[0088] Given this configuration, software running on the application processor cannot simulate false validations on the touch panel, so the physical button B is optional: validation can be done safely using the touch panel.

[0089] The securing of the KBD touch panel which has just been described as an improvement of the SPH3 embodiment of [Fig.5] is also applicable to the SPH2 embodiment of [Fig.4] in which, in secure mode, the DB1 bus of the touch panel will be routed to the secure element instead of being connected to the TEE enclave.

[0090] In one embodiment, the SEL signal, or any other secure mode indicator (such as the LD indicator light control signal), can be used to inhibit circuits that are generally not used during secure mode. As shown in [Fig. 6], the SEL signal is, for example, applied to an INHIB terminal of the application processor. It can be provided that switching the SEL signal to its value corresponding to secure mode causes the processor to reset by cutting off its clock signal or its power supply. In this case, any malicious software running on the application processor that performs scans to deduce cryptographic keys or other sensitive information is rendered inoperative during the secure transaction.

[0091] Complete inactivation of the application processor is possible, in particular, in the configuration of [Fig. 6], where all functions that must remain active during the transaction are offloaded to the secure eSE element. In cases where the application processor cannot be deactivated, the SEL signal can be used to disable auxiliary circuits that can be used to infer sensitive information, such as accelerometers used to deduce the positions of touches on the touchscreen. Accelerometers are generally integrated into a dedicated inertial measurement unit (IMU) circuit. Such an IMU can be deactivated by stopping its clock, cutting off its power supply, or severing its communication link with the application processor, typically an I2C bus.

[0092] Malicious software can be designed to initiate transactions while the secure element is in a configuration where it does not require an unlock code, for example, for a limited time after completing a previous transaction. In this case, the malicious software attempts to modify the display, but this attempt fails because the secure element (eSE) is the display master in the embodiments of Figures 5 and 6. Thus, the display reflects the transaction actually initiated by the malicious software, while the secure element (eSE) awaits user validation on the touchscreen (in the configuration of [Fig. 6]), or on the physical button B (in the configuration of [Fig. 4] or [Fig. 5]). In the case of [Fig. 3], fraudulent modification of the display is possible, so that the user can be misled as to the nature of the transaction.

[0093] If the fraudulent transaction is initiated while the user has their mobile terminal in sight, they will see, without being prompted, the mobile terminal switch to secure mode (LD indicator light), display the transaction, and request its validation. The user can check the display and cancel the transaction, but this requires the user to be attentive and not validate the transaction inadvertently.

[0094] If the user does not have the mobile terminal in sight, the transaction is in principle automatically cancelled upon expiry of a waiting period. However, if the mobile terminal is subjected to jostling in a pocket or bag, an unintended validation could occur before the expiry of the waiting period, either by pressing the physical button B (Figures 3 to 5), or by pressing the touch panel ([Fig. 6]) which could be configured to be operational on the mobile terminal's standby screen when requesting validation.

[0095] Figure 7 shows an SPH5 embodiment of a mobile terminal that thwarts this type of fraud. In addition to the elements of the embodiment of Figure 6, a physical bistable switch S is connected to a GPIO4 input / output pin of the eSE security element. In a first position, the switch S connects the GPIO4 input to a logic high, for example a supply voltage Vcc, and in In a second position, switch S connects the GPIO4 input to a low logic level, for example, a ground potential (GND). Switch S is arranged, for example, on one of the side panels of the mobile terminal.

[0096] The secure element eSE is programmed not to process commands received via the DB3 bus in one of the positions of switch S, for example the first, and to accept transaction requests received via the DB3 bus in the other position. The SPH5 terminal is designed so that switch S is the only available means for switching the mode of the secure element; that is, an application can no longer delegate the processing of a transaction on its own.

[0097] Thus, the mode of the secure element is exclusively under the control of the user who chooses the mode using the S switch as needed.

[0098] Since the switch S is initially in the inactive mode, an application capable of initiating transactions is designed to prompt the user to change mode when it is about to delegate transaction processing to the secure element eSE. It can send a message such as "Please put the phone in secure mode using the switch" to the DISP display, preferably with information about the ongoing transaction. This message is similar to a message prompting the user to connect their traditional detachable wallet to the mobile terminal.

[0099] The user then flips the switch to activate mode. The eSE secure element reacts by taking various protective measures, such as switching the SEL signal to connect the DISP display and the KBD touchscreen to the dedicated DMCU display manager and the eSE secure element, respectively. The LD indicator light is also activated to signal to the user that the mobile terminal is in secure mode. The eSE secure element sends an acknowledgment to the application, which resumes execution by transmitting the transaction information to the secure element. The eSE secure element performs the data entry phase on the KBD touchscreen, if applicable, and requests user confirmation by displaying the transaction information again.

[0100] When the transaction is validated and signed, the eSE secure element communicates the signed transaction to the application, which records it on the blockchain. The secure element prompts the user to switch modes by sending a message to the DISP display such as "Please exit secure mode by toggling the switch." This message is similar to the one indicating that the user can remove their standard detached wallet. When the switch is toggled, the initial connections of the display and the touch panel are re-established, and the LD indicator light is turned off.

[0101] The S switch can also be implemented in the structures shown in Figures 4 and 5, where the KBD touch panel is not connected to the safety element. In this case, It is the application that performs the input phase before requesting the switching of the S switch.

[0102] Of course, the switch S, at the user's mercy, could be toggled at times when it is not required, or not toggled when it is required. Various combinations are therefore not "normal," and this can be signaled to the user by displayed messages or alarms, prompting the user to toggle the switch so that operations can resume normally.

[0103] Malware could also behave like a legitimate application by requesting a mode switch. However, since the user did not initiate the transaction and is being asked for a relatively binding action, they are likely to be more vigilant. The malware can no longer display an irrelevant misleading message in this context, since the user expects to see transaction information. Such transaction information will be difficult to make credible, especially if it is true—typically a transfer of a large sum to an unknown address. If the malware attempts to hide the nature of the transaction, it will be revealed and different when displayed for validation by the secure eSE element, if the user was nevertheless prompted to switch to secure mode.

[0104] In any case, a pending transaction, whether fraudulent or not, can no longer be validated by an untimely press of a physical or virtual button, because the user must intentionally switch the mobile terminal into secure mode to validate the transaction.

[0105] In the embodiments just described in relation to Figures 5 to 7, the secure element takes control of the DISP display when it switches to secure mode, at which point the APROC application processor or, where applicable, the TEE enclave no longer having access to it. However, in certain secure applications, particularly those running on detached hardware wallets, the transaction data is intended to be displayed simultaneously on the screen of the host device (mobile phone or PC running, for example, the "Ledger Live" software) and on the display of the hardware wallet. Thus, the user can verify at a glance that the transaction data presented by the application is identical to that presented by the hardware wallet and about to be executed by the secure element.

[0106] In the preceding discussion, it was noted that such functionality is not feasible when the hardware wallet is embedded in a smartphone, given the difficulty of providing a second display and the additional cost this would entail. It was therefore proposed that the display of transaction data be controlled by the secure element.

[0107] In an SPH6 embodiment of a connected terminal integrating a hardware wallet as shown in [Fig. 8], 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 overlaying a secure image provided by the secure element onto an insecure image provided by the application processor. The secure image is overlaid in a region 10 of the DISP display. The remainder of the available display area forms a region 9 that receives the portion of the insecure image that is not masked by the overlaid secure image. Regions 9 and 10 are preferably such that together they cover the entire available display area.

[0108] Such image overlay significantly improves the security offered by the terminal and its ergonomics when conducting a transaction. For example, the application processor can display the following information in region 9: "you wish to buy 2 bitcoins for a value of USD 50,000" while the secure element displays the following information in region 10 of the display: "please confirm your purchase of 2 bitcoins for a value of USD 50,000" as well as a representation of a validation button which the user must touch to trigger the transaction.

[0109] As another example, the application processor can display in region 9 the following information: "please confirm your request to purchase 2 bitcoins for a value of USD 50,000 by confirming on the secure touch keyboard the number of bitcoins you want to buy and then the value of this transaction" while the secure element displays in region 10 a virtual keyboard allowing the user to enter the two transaction data, here the number of bitcoins and the value of the transaction.

[0110] In yet another variant, button B is used to confirm the transaction. The application processor displays the following information in region 9: "Please confirm your request to purchase 2 bitcoins for a value of USD 50,000 by pressing button B," while the secure element displays the same information in region 10: "Please confirm your request to purchase 2 bitcoins for a value of USD 50,000 by pressing button B." Any difference between the transaction data displayed by the application processor and the secure element will be perceived by the user due to the simultaneous display of these data.

[0111] The SPH6 embodiment shown in [Fig. 8], which enables such image overlay, differs from the SPH5 embodiment shown in [Fig. 7] in that the previously described hardware multiplexer MUX is replaced by a dynamic multiplexer DYMUX. The dynamic multiplexer DYMUX comprises a hardware multiplexer MUXi which, like the MUX multiplexer of [Fig. 7], includes a first The DYMUX dynamic multiplexer has three inputs: one connected to the DISPB1 bus of the application processor, a second connected to the DISPB2 bus of the DMCU display manager of the eSE secure element, and an output connected to the DISPB bus that controls the display. The DYMUX also includes a SYNCT synchronization circuit that provides the SEL signal to the MUXi multiplexer and receives a PIP picture overlay authorization signal from the GPIO3 pin of the secure element.

[0112] The PIP signal has an active value and an inactive value, corresponding in practice to two logical values ​​of this signal, for example 0 and 1 or vice versa. When it is not requested for a transaction, or when it does not need—or no longer needs—to interface with the user, the secure element sets the PIP signal to the inactive value. In this case, the SYNCT synchronization circuit controls the MUXi multiplexer so that its output DISPB bus is permanently connected to the DISPB 1 bus of the application processor. The application processor then has full control of the entire display.

[0113] 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 PIP signal to its active value, which triggers the superposition of image data provided by the application processor and image data provided by the secure element via the DMCU display manager, at the rate of changes in the value of the SEL signal provided by the SYNCT circuit.

[0114] The image data provided by the APROC application processor is then displayed in region 9 of the display and the image data provided by the DMCU display manager is displayed in region 10. More specifically, the image data provided by the application processor and which correspond to region 10 are replaced - or "overwritten" - by the image data provided by the secure element, so that the image data which is displayed in region 9 is that which has not been overwritten by that provided by the DMCU display manager.

[0115] To provide the SEL signal, the SYNCT circuit takes into account a configuration data SDT ("Setup Data") which determines the size, shape and location of the region 10 occupied by the embedded image. The SYNCT circuit also takes into account synchronization information taken from or extracted from the DISPB 1 and DISPB2 buses, so that the transitions on the DISPB bus between the image data provided by the APROC application processor and the image data provided by the DMCU display manager do not cause the appearance of noise or image shearing (conventionally called "image tearing").

[0116] In one embodiment, the size of region 10 is fixed and the SDT configuration data is hard-coded into a configuration register (SREG) of the DYMUX multiplexer. The SDT data includes, for example, the position of the first and last lines of region 10, which determines the height h of region 10, or, equivalently, the position of the first line and the number of subsequent lines. Alternatively, the SDT data may include only the position of the first line of region 10 if the region occupies the entire lower portion of the display. In another embodiment, the configuration register is configurable and receives the SDT configuration data from an external source, for example, from the DMCU display manager at the request of the secure element, or directly from the secure element.

[0117] The DB1 bus at the output of the KBD touch panel, here of type I2C, is as before connected to the input of the DMUX demultiplexer whose first output is connected to the APROC application processor by the DB11 bus and the second output connected to the eSE secure element by the DB12 bus.

[0118] The DMUX demultiplexer selection is performed here by the PIP signal so that, for the entire period during which the terminal operates in secure mode and the image portions provided by the secure element replace those provided by the application processor, the secure element has exclusive control of the touchpad. It is therefore not feasible—and in practice, hardly necessary—for the application processor to offer the user touch functionalities in region 9 during operation in secure mode, unless it is provided that these functionalities are handled by the secure element, which then relays the touch information to the application processor.

[0119] While this may have practical or ergonomic advantages, those skilled in the art could nevertheless devise a more complex embodiment so that the application processor receives in real time the touch data corresponding to region 9 of the display where it can display information. For this purpose, the DMUX demultiplexer could, for example, be controlled by the SEL signal provided by the SYNCT circuit.

[0120] The risk analysis associated with each terminal configuration proposed in this application reveals the risk that a malicious program, having gained control of the application processor or the DISPB1 bus, could display information in region 10 that simulates the information displayed by the secure element during the execution of a transaction. Thus, after requesting a transaction, the user might be tempted to believe that this transaction is being executed by the secure element when region 10 is still under the control of the application processor and the secure element has not yet been accessed. It is therefore necessary to ensure that the user is fully informed that the information displayed in the Region 10 actually originates from the secured element. To overcome this problem, two cases must be distinguished:

[0121] 1) the region 10 has a fixed height h0 and occupies a fixed location on the display, across the entire width of the display. For example, region 10 occupies the last "N" lines of the display corresponding to the height h0, as shown in [Fig.9A],

[0122] 2) the region 10 has a variable height h and may possibly be located in a The location of region 10 is variable across all or part of the display's height, with its height h and location defined by the SDT configuration data. In an example shown in [Fig. 9B], region 10 has a height hl and occupies the entire lower portion of the display. In another example shown in [Fig. 9C], region 10 has a height h2 greater than hl and extends approximately two-thirds of the lower half of the display without occupying its bottom portion.

[0123] In an embodiment corresponding to the first case, the secure element is configured to activate the LD indicator light when it brings the PIP signal to the active value. In this case, and as schematically shown in [Fig. 9A], the user is fully informed by means of the LD indicator light, which is under the exclusive control of the secure element via the GPIO2 pin, that the secure element controls region 10. As an additional means of informing the user, the location of region 10 can be indicated by means of a visual marker such as a VM color bar provided on the terminal housing, next to the display, spanning the entire height of region 10.

[0124] In an embodiment corresponding to the second case, a row LR of indicator lights L, each formed by an LED, is provided along the display and extends over all or part of its height. The row of indicator lights is driven by GPIO input / output pins of the safety element and is intended to indicate the precise location of region 10, each indicator light being individually controlled by the safety element. Thus, in the example of [Fig. 9B], the safety element illuminates the first 7 LEDs L1 to L7, and in the example of [Fig. 9C], the safety element illuminates LEDs L6 to L15. The user is therefore fully informed that the safety element controls region 10 and is also informed of the location of this region 10. In such an embodiment, the row LR of indicator lights replaces the single indicator light LD described previously, which is no longer required.

[0125] In another embodiment, corresponding to the second case and illustrated in Figures 9D, 9E, two measures are provided to delimit the region 10 and inform the user that the secure element controls this region:

[0126] i) One or more lines of the display, for example the last line or lines thereof, form a reference region 101 which is under the permanent control of the secure element, thanks to a corresponding configuration of the DYMUX dynamic multiplexer. Such a configuration, independent of the value of the PIP signal, prevents the application processor from displaying information in this region.

[0127] ii) when the secure element switches to secure mode and takes control of region 10, it frames it with a border 102 having a determined appearance which must be identical to that of region 101. If region 10 is not in the immediate extension of region 101, the secure element may also and optionally display a link region 103 connecting border 102 to region 101, the appearance of which is identical to that of region 101.

[0128] The aforementioned appearance of the reference region 101 is preferably variable and random. It may consist of a specific color or combination of colors, a specific pattern comprising a combination of colors or a gradient of gray, a specific visual texture, extracts from photographs, etc. Since a malicious program cannot access the information sent by the secure element to the DMCU display manager, which determines the appearance of the reference region 101, such a malicious program will be unable, if it wishes to simulate the region 10, to frame it with a border 102 having the same appearance as the reference region 101.

[0129] The implementation of the DYMUX dynamic multiplexer can be carried out in various ways within the reach of a person skilled in the art. Some will be described below in relation to Figures 10 to 15, which show DYMUX1, DYMUX2, DYMUX3, DYMUX4, DYMUX5 and DYMUX6 embodiments of this multiplexer.

[0130] The dynamic multiplexer DYMUX1 of [Fig. 10] comprises a hardware multiplexer MUX1, a synchronization circuit SYNCT1, and the configuration register SREG. In the embodiment considered here, the buses DISPB1 and DISPB2 each carry pixel-forming data packets, IPAQ1 and IPAQ2 respectively, as well as a clock signal, CLK1 and CLK2 respectively, and a synchronization signal, TE1 and TE2 respectively ("Tearing Effect Signal"), conventionally used as a means of preventing image tearing. Depending on the value of the SEL signal, the IPAQ image data supplied at the output of the multiplexer MUX1 is either IPAQ1 or IPAQ2 data, the clock signal CLK is either CLK1 or CLK2, and the end-of-frame signal TE is either TE1 or TE2. This last signal is emitted, for example, every 20 ms for an image refreshed at a frequency of 50 Hz.

[0131] The SYNCT1 circuit includes an LCPT line counter which counts the lines displayed on the DISPB bus and is configured to determine, from the SDT configuration data present in the SREG register, the times T1 when packets present on the DISPB 1 bus should be provided on the DISPB bus, and the times T2 when packets present on the DISPB2 bus should be provided on the DISPB bus instead of packets present on the DISPB 1 bus, i.e. the times when the SEL signal should change value.

[0132] To enable precise control of times T1 and T2, the SYNCT1 synchronization circuit retrieves SU, SI2, and SI synchronization information from the DISPB 1, DISPB2, and DISPB buses. This SU, SI2, and SI synchronization information includes, for example, the clock signals CLK1, CLK2, and CLK, and the frame end signals TE1, TE2, and TE. The SYNCT1 synchronization circuit also includes pixel counters PCPT1, PCPT2, and PCPT, associated respectively with the DISPB 1, DISPB2, and DISPB buses, each of which provides a line end signal, respectively LEP1, LEP2, and LEP ("Line End Puise"). Each counter is reset after a line end is detected, then counts pixels again until it reaches the number of pixels in a line, after which it emits the line end signal again and resets itself, and so on.The operation of these counters is within the grasp of a skilled technician and relies on known principles of video signal analysis. Indeed, the length of a line can be determined by analyzing the content of all the data packets it contains. An end-of-line signal can also be detected via an analog measurement system, as an end-of-line signal in MIPI corresponds to a voltage transition from approximately 200 mV to approximately 2 V. A Schmitt flip-flop can therefore also be used to determine the end of a line.

[0133] The SYNCT1 synchronization circuit sends SYNCDT1 synchronization data for DISPB 1 and DISPB buses to the DMCU display manager, and SYNCDT2 synchronization data for DISPB 2 and DISPB buses to the APROC application processor. The SYNCDT1 synchronization data includes, for example, the TE1 and TE frame end signals, the LEP1 and LEP line end signals, and the CLK1 and CLK clock signals. The SYNCDT2 synchronization data includes, for example, the TE2 and TE frame end signals, the LEP2 and LEP line end signals, and the CLK2 and CLK clock signals. Thus, the APROC application processor receives information on the state of the DISPB2 bus controlled by the DMCU display manager and conversely the DMCU display manager receives information on the state of the DISPB1 bus controlled by the APROC application processor.The application processor and the display manager can thus implement a synchronization strategy. This common feature allows the SYNCT1 circuit to apply the SEL signal to the MUX1 hardware multiplexer without causing interference or image tearing. However, in practice, an immediate switchover between the two DISPB1 and DISPB2 buses is not essential. Indeed, most displays allow for some latency in the line data delivery. The multiplexer switching can therefore exhibit such "latency" between the cessation of the data stream carried by the DISPB1 bus and the application of the data stream carried by the DISPB2 bus, or vice versa, without this latency being so significant as to degrade the display frequency.

[0134] The embodiment of the DYMUX1 multiplexer just described is generic and can be simplified by using only a portion of the aforementioned synchronization signals. For example, the dynamic multiplexer DYMUX2 of [Fig. 1 1] comprises a hardware multiplexer MUX2 of the same type as the multiplexer MUX1 and a simplified synchronization circuit SYNCT2. The latter includes only the pixel counter PCPT, which provides the end-of-line signal LEP, and extracts the end-of-frame signal TE from the data circulating on the DISPB output bus. The end-of-line signal LEP and the end-of-frame signal TE are sent to the display manager DMCU and the application processor APROC so that they realign to the same reference at each new line and each new frame. The DMCU display manager also receives the CLK1 clock signal from the DISPB 1 bus and itself provides the SEL signal to the MUX2 hardware multiplexer.For this purpose, the DMCU display manager is equipped with the SREG configuration register, the LCPT line counter, and receives the PIP signal. The PIP signal allows it to determine, from the SDT configuration data present in the SREG register, the times T1 when packets present on the DISPB 1 bus should be provided on the DISPB bus, and the times T2 when packets present on the DISPB2 bus should be provided on the DISPB bus instead of packets present on the DISPB 1 bus.

[0135] In this embodiment, the DMCU display manager automatically adapts to the CLK1 clock signal of the DISPB 1 bus controlled by the application processor, and can replace image data provided by the latter with image data provided by the DMCU display manager of the secure element, without causing the appearance of noise or tearing of the displayed image.

[0136] The DYMUX3 dynamic multiplexer of [Fig. 12] comprises a hardware multiplexer MUX3, a synchronization circuit SYNCT3, the SREG register, a receive circuit RX1 connected to the DISPB 1 bus, a receive circuit RX2 connected to the DISPB2 bus, a line buffer LBUF1 whose input is connected to the output of the RX1 circuit and whose output is connected to a first input of the MUX3 multiplexer, a buffer The MUX3 multiplexer consists of two lines: LBUF2, whose input is connected to the output of the RX2 circuit and whose output is connected to a second input of the MUX3 multiplexer; and a TX transmission circuit, whose input is connected to the output of the MUX3 multiplexer and whose output is connected to the DISPB bus. Unlike the MUX1 and MUX2 multiplexers shown in Figures 10 and 11, the MUX3 multiplexer handles raw digital data, not image data received in encapsulated form within a frame coded according to a specific protocol. The raw data carried on the DISPB1 bus is decoded—or more precisely, decapsulated—by the RX1 receiver circuit, then loaded into the LBUF1 line buffer before being applied to the first input of the MUX3 multiplexer.Similarly, the raw data carried on the DISPB2 bus is decapsulated by the RX2 receiver circuit and then loaded into the LBUF2 line buffer to be subsequently applied to the second input of the MUX3 multiplexer. For this purpose, the SYNCT3 circuit applies write signals W1, W2 and read signals RI, R2 to the LBUF1 and LBUF2 buffers.

[0137] The receiver circuits RX1 and RX2 provide the SYNCT3 circuit with synchronization information SU and SI2, enabling it to count the number of lines of an image that have been displayed and to determine the times T1 and T2 when the contents of buffer LBUF1 should be applied to the input of the transmission circuit TX, as well as the times T2 when the contents of buffer LBUF2 should be applied to the input of the transmission circuit TX. The transmission circuit TX reconstructs, on the DISPB bus, from the raw data provided by buffers LBUF1 and LBUF2, a video frame encoded according to the desired protocol, which may be the same as that of buses DISPB1 and DISPB2, or another protocol. The TX circuit also communicates synchronization information SI3 to the SYNCT3 circuit, enabling it to refine the control of the multiplexer MUX3.

[0138] The DYMUX4 dynamic multiplexer of [Fig. 13] comprises a hardware multiplexer MUX4 identical or of the same type as the multiplexer MUX3, and a synchronization circuit SYNCT4. It differs principally from the DYMUX3 multiplexer in that the RX2 receiver circuit is omitted, the LBUF2 line buffer being replaced by an extended line buffer ELBUF2 capable of receiving raw data corresponding to several lines of the image to be keyed. The DMCU display manager accesses the extended line buffer ELBUF2 directly without requiring a video signal. For this purpose, the DISPB2 bus, instead of being a bus carrying video frames according to the MIPLDSI protocol or another video protocol, can simply be an I2C or SPI bus.When the ELBUF2 buffer has been filled by the DMCU display manager, the SYNCT4 synchronization circuit performs several buffer read cycles to provide its contents to the MUX4 multiplexer, successively applying LAD2 line addresses followed by a READ2 read signal to the buffer. This is to avoid the appearance of artifacts. Due to visuals resulting from the updating of data in the extended line buffer ELBUF2, a dual buffer system can be envisaged, with a first buffer being used while the second buffer is being filled, the second buffer, once full, then being used while the first buffer is being filled, and so on.

[0139] The DYMUX5 dynamic multiplexer of [Fig. 14] comprises a hardware multiplexer MUX5 identical or of the same type as the MUX3, MUX4 multiplexers, and a SYNCT5 synchronization circuit. It differs principally from the DYMUX4 multiplexer in that the extended line buffer ELBUF2 is replaced by a page buffer PBUF2 into which the DMCU display manager has previously loaded all the lines of region 10 ([Fig. 8]).

[0140] In an alternative embodiment shown in [Fig. 15] and also applicable to the embodiments of Figures 12 and 13, the dynamic multiplexer DYMUX6 comprises a multiplexer MUX6 whose output, instead of being applied directly to the TX transmission circuit, is applied to a page buffer PBUF3 which is pre-filled with all the lines of a page before its contents are applied to the TX circuit for generating the video signal on the DISPB bus. This pre-stored full page may include lines provided by the application processor and lines provided by the display manager DMCU, occupying region 10.In this case, the MUX6 multiplexer is no longer of the same type as the multiplexers previously described, and although still referred to here as a multiplexer because it provides the same technical effect, it is rather a buffer-to-buffer copy system with two input channels and one output channel. Although the embodiments of the dynamic multiplexer just described ensure the embedding of the image data provided by the secure element with an embedding pitch that is on the scale of a line of image data provided by the application processor, a person skilled in the art can modify this embedding pitch according to the objectives in terms of ergonomics and user experience. In some embodiments, the embedding pitch can, in particular, be on the scale of the pixel of the image data provided by the application processor. In the embodiment of [Fig.

[14] For example, the MUX5 multiplexer can be configured to select pixel by pixel the image data contained in the LBUF1 and PBUF2 buffers, and thus fill the PBUF3 output buffer pixel by pixel.

[0141] Figure 16 illustrates a component arrangement of a mobile terminal (smartphone) according to one of Figures 4 to 8 or 10 to 14. The APROC application processor and its optional TEE enclave can be part of a system-on-chip (SoC). The APROC application processor or the SoC that incorporates it has pins soldered to respective traces on a printed circuit board or other substrate. interconnecting a number of other components. Respective groups of pins are associated with the different communication links between the components, including the previously mentioned DISPB, DISPB1, DB1, DB2, and DB11 buses.

[0142] The DISP display and the KBD touch panel are generally located remotely and parallel to the printed circuit board. Their control buses are then connected to the printed circuit board by connectors soldered onto traces of the printed circuit board.

[0143] In one embodiment, the elements described above, enabling the implementation of an embedded hardware portfolio, including the eSE, DMCU, MUX or DYMUX and DMUX elements, as well as the buses that connect them and optionally the connectors of all or part of the B, S, LD, LR elements, can be integrated into a System-in-Package (SiP) designed to be mounted on a printed circuit board. Alternatively, these elements can be integrated into another SoC.

[0144] Thus, to integrate a hardware wallet into a mobile terminal, a space is provided on the printed circuit board to solder the system-in-a-box SiP, the traces of the different buses used are redesigned by interrupting them so that they pass through the SiP, and traces are provided to establish the secure link between the APROC processor and the secure eSE element.

[0145] The various discrete physical elements managed by the SiP circuits (button B, switch S, indicator light LD) can be fixed to the terminal housing and connected to connectors of the SiP, or to remote connectors on the printed circuit board, themselves connected by traces to dedicated pins of the SiP.

[0146] With this configuration, a conventional mobile terminal can be transformed into a mobile terminal including an embedded hardware wallet simply by adding a SiP to a printed circuit board containing the components of the conventional terminal. Although the design of a suitable printed circuit board represents a certain development and production cost, this cost remains negligible because no adaptation is required to the hardware platform of the conventional terminal.

[0147] The preceding description was made primarily in the context of smartphones incorporating a hardware wallet for signing transactions on the blockchain (“blockchain smartphones”). It will be obvious to those skilled in the art that the means and methods just described for ensuring control of the display by the secure element during the signing of a transaction apply to any secure operation requiring this same control. The means and methods described also apply to any type of terminal connected to the Internet or a local network storing secrets used for various purposes involving cryptographic calculations, such as signing transactions in general and authentication, including zero-knowledge authentication. In other types of terminals When connected, the human-machine interface can be a display associated with a physical keyboard, or a joystick.

Claims

Demands

1. A connected terminal (SPH6) configured to perform a secure operation, the terminal comprising: - an application processor (APROC) configured to initiate the secure operation, - a secure element (eSE) to perform the secure operation, and - a display (DISP) accessible via a wired bus (DISPB) and receiving image data from the application processor to be displayed to a user, characterized in that it comprises means (DYMUX, MUXi) controlled by the secure element and configured to, at the request (PIP) of the secure element and at least during the execution of the secure operation, alternately apply to the wired bus (DISPB) of the display image data (IPAQ1) provided by the application processor and image data (IPAQ2) provided by the secure element,in such a way that the image data provided by the secure element replaces image data provided by the application processor and forms a secure image embedded within an insecure image provided by the application processor, the secure image extending into at least one determined region (10) of the display.

2. Terminal according to claim 1, comprising at least one light indicator (LD, LR) activated by the secure element when the secure element overlays a secure image into an insecure image provided by the application processor.

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

4. Terminal according to claim 3, wherein the means for indicating the location and extent of the region (10) in which the embedded secure image is displayed comprise a row (LR) of light indicators (L;) controlled by the secure element and arranged at the edge of the display.

5. Terminal according to claim 3, wherein the means for indicating the location of the region (10) in which the embedded secure image is displayed include: - a region (101) of the display (LR) which is permanently under the control of the secure element, and which displays a determined appearance, - a border (102) of the region (10) in which the embedded secure image is displayed, which has the same appearance as the region (101) of the display which is permanently under the control of the secure element.

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

7. Terminal according to claim 6, wherein the control circuit (SYNCT, SYNCT1-SYNCT5, SREG, DMCU) is configured to control the multiplexer with a determined overlay fineness of the image data provided by the secure element, said overlay fineness being on the scale of a line or on the scale of a pixel of the image data provided by the application processor.

8. Terminal according to any one of claims 1 to 7, wherein the secure element is configured to, before performing the operation, overlay into an insecure image provided by the application processor a secure image comprising information about the secure operation.

9. Terminal according to any one of claims 1 to 8, further comprising an input device (KBD) providing touch data on a data bus (DB1), and a demultiplexer (DMUX) controlled by the secure element (eSE) and configured to link the data bus (DB1) of the input device to a bus (DB11) of the application processor or to a bus (DB12) of the secure element.

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

11. Terminal according to any one of claims 1 to 10, comprising a physical button (B, S) actuable by the user and monitored by the secure element (eSE), wherein the secure element is configured not to perform the operation in the absence of a user action on the physical button (B, S).

12. Terminal according to any one of claims 1 to 11, wherein the secure element (eSE) and the means (DYMUX, MUXi) for alternatively applying to the wired bus (DISPB) of the display image data (IPAQ1) supplied by the application processor and image data (IPAQ2) supplied by the secure element, are integrated in whole or in part into a system-in-a-box (SiP) or into a system-on-a-chip (SoC) mounted on an interconnect carrier of the terminal.

13. Terminal according to any one of claims 1 to 12, wherein the secure operation includes a step of signing data using a secret key.

14. A method for conducting a secure operation using a connected terminal (SPH6), in particular the signing of data using a secret key, the terminal comprising: - an application processor (APROC) configured to initiate the secure operation, - a secure element (eSE) holding a private key and configured to execute the secure operation, and - a display (DISP) accessible via a wired bus (DISPB) and receiving from the application processor insecure images relating to the progress of the secure operation, a method characterized in that it comprises a step of embedding, in at least one insecure image provided by the application processor and presented on the display, a secure image provided by the secure element and not accessible to the application processor, the secure image comprising information on the operation and extending into at least one determined region (10) of the display,the inlay stage being under the, control of the secure element and cannot be prevented or corrupted by the application processor.

15. A method according to claim 14, comprising the step of providing in the terminal means (DYMUX, MUXi) controlled by the secure element and configured to, at the request (PIP) of the secure element, alternately apply to the wired bus (DISPB) of the display image data (IPAQ1) provided by the application processor and image data (IPAQ2) provided by the secure element, such that the image data provided by the secure element replaces image data provided by the application processor and forms said secure image embedded in the insecure image provided by the application processor.

16. A method according to any one of claims 14 and 15, comprising providing in the terminal at least one light indicator (LD, LR), and comprising a step of activating the light indicator by the secure element when the secure element overlays a secure image into an insecure image provided by the application processor.

17. A method according to any one of claims 14 to 15, comprising a step of indicating to the user the location and extent of the region (10) in which the embedded secure image is displayed.

18. Method according to claim 17, the location and extent of the region (10) in which the embedded security image is displayed are indicated by means of a row (LR) of light indicators (L;) controlled by the security element and arranged at the edge of the display.

19. A method according to claim 17, wherein the location and extent of the region (10) in which the embedded security image is displayed are indicated by means of: - a region (101) of the display (LR) which is permanently under the control of the security element and which has a determined appearance, and - a border (102) of the region (10) in which the embedded security image is displayed, which has the same appearance as the region (101) of the display which is permanently under the control of the security element.

20. A method according to any one of claims 14 to 19, wherein the terminal comprises an input device (KBD) providing touch data on a data bus (DB1), and comprising the step consisting of linking the input device (KBD) to the secure element during the display of secure operation information in the embedded secure image.

21. A method according to any one of claims 14 to 20, wherein the terminal includes a physical button (B, S) actuable by the user and monitored by the secure element (eSE), and comprising a step of configuring the secure element so that it does not perform the secure operation in the absence of a user action on the physical button (B, S).

Images