Smart phone integrated hardware wallet for encryption key storage and software multiplexing of smart phone display

Abstract

A portable electronic device for performing a secure transaction, comprising an application processor (APP PROC), an auxiliary processor, and an embedded secure element (eSE) connected to the application processor and the auxiliary processor (PROC2), configured to perform certain steps of the transaction, comprising at least one cryptographic calculation step involving a secret stored in the secure element. During execution of a transaction, the secure element (eSE) sends display data to the auxiliary processor (PROC2), and the auxiliary processor is configured to display the display data sent by the secure element at a higher priority than the display data sent by the application processor.

Description

Technical Field

[0001] The present invention relates to a secure portable device for storing and implementing private cryptographic keys (in particular keys allowing transactions to be executed on a blockchain) in an isolated manner with respect to a network ("cold" storage). Background Art

[0002] In recent years, the development of cryptocurrencies or other types of cryptographic assets managed by blockchains, such as non-fungible tokens (NFTs) and smart contracts, has given rise to various ways of storing and maintaining the private keys attached to these different types of cryptographic assets. Concepts such as "wallets", "cold storage", and "hot storage" of private keys have thus emerged. A "wallet" is a device or program whose function is to manage cryptographic assets and thus store the private keys attached to them. So-called "hot wallets" are connected to the Internet and exposed to hacking attacks or viruses and malware. These hot wallets can be wallets managed by centralized exchanges, which do not offer the highest level of security. Thus, over the years, many centralized platforms have been plundered by hackers for hundreds of millions of dollars. "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 insecure applications, and thus they themselves are exposed to attacks.

[0003] Cold wallets are the most secure solution for cold storage of private keys, i.e., avoiding direct access to the Internet, which reduces the risk of attack and thus the risk of being stolen by hackers. Transactions involving private keys are signed in an offline environment. Any transaction initiated online is temporarily transferred to an offline hardware wallet and then digitally signed at the offline hardware wallet before being sent to the online network. Since the private key is not transferred to the online server during the signature process, hackers cannot access it.

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

[0005] Hardware wallets are a convenient replacement for passive wallets for storing private keys. Additionally, hardware wallets are typically configured to generate a recovery phrase to recover the private key in case they are lost. Note that the cryptographic assets are never stored in the hardware wallet, but are recorded on the blockchain. The hardware wallet only stores the private key 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.

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

[0007] The hardware wallets HW sold by the applicant are commercially successful because they provide a high level of security 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 attacker attacks.

[0008] Figure 2 The architecture of the hardware wallet HW1 sold by the applicant under the name "Nano S" is shown, which is described in more detail in the document at https: / / developers.ledger.com / docs / nano-app / bolos-hardware-architecture / . The hardware wallet HW1 has a secure element SE1 paired with a microcontroller MCU1. The processor 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 Figure 1 ). The secure element SE1 has its own secure operating system OS (firmware) that allows it to run application programs and incorporate a cryptographic coprocessor CRY. The hardware wallet HW1 also has a display DISP1 and two buttons B1, B2 managed by the microcontroller MCU1. These two buttons play an important role in ensuring the security of certain operations: the user must press both buttons simultaneously to prove their consent or authorization to execute or complete an operation.

[0009] When conducting a transaction, the hardware wallets as described above are typically separate portable devices that are temporarily connected to a "connected" host device (such as a mobile terminal or smartphone). The separate nature of these hardware wallets provides a high degree of security because most of them cannot be accessed via a public network and are therefore rarely attacked. However, this characteristic makes these hardware wallets less ergonomic and prone to being misplaced or forgotten.

[0010] Blockchain smart phones are known, which are designed to securely store certain virtual assets (such as cryptocurrencies) and have an internal storage space that is not accessible from the Internet to form a cold wallet: the Galaxy S10 model of the Exodus 1 model or Sirin the Finney model. These smart phones are equipped with an embedded security element (designated as eSE), which is a chip specifically designed to store sensitive data and share the sensitive data only with authorized applications and personnel.

[0011] In terms of virtual currency, a very high level of security is required. The above blockchain smart phones provide a certain degree of security by using a secure enclave or a trusted execution environment TEE, but the digital hardware wallet function, which is not the main function of such phones, requires more security. In fact, implementing a hardware wallet within a smart phone partially eliminates the security advantages of a separate hardware wallet that is only connected 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 executed on the blockchain side, and specifically can execute applications (such as the Ledger Live application or equivalents) designed to execute transactions on the blockchain side, while providing a high level of security for the preservation of the secret keys of the cryptographic asset accounts used to sign transactions.

[0013] Such a connected portable electronic device will necessarily include an application processor connectable to the Internet, which is capable of executing applications (e.g., Ledger Live) designed to execute transactions on the blockchain, and a display managed by the application processor to present transaction-related information to the user. To enable such a device to provide a high level of security, it may be desirable that the information presented to the user during transaction execution cannot be forged by a fraudulent program that takes control of the application processor.

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

[0015] Document WO2015180581 teaches the use of a switching module controlled by a button to share the 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 where 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. Additionally, in practice, each processor must be able to address control signals to the display driver, thus requiring the provision of hardware connections such as conductive tracks. Such hardware connections increase the attack surface (also known as the exposed surface) of the hybrid architecture and in particular increase the attack surface of the security chip.

[0016] Therefore, there is also a need to improve the security of the hybrid architecture in which multiple processors share access to the display screen.

[0017] 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

[0018] An embodiment relates to a connected terminal, the connected terminal comprising: a human-machine interface, the human-machine interface comprising a display that can be managed by a control bus; an application processor, the application processor comprising components for connecting to a public or local network, configured to execute a transaction; an auxiliary processor, the auxiliary processor integrally connecting a display controller of the control bus connected to the display, the application processor being configured to provide data to be displayed to the auxiliary processor; an embedded security element, the embedded security element being connected to the application processor and the auxiliary processor via a wired bus, the security element being configured to execute certain steps of the transaction, including at least one cryptographic calculation step involving a secret stored in the security element, the application processor being configured to request the security element to execute the transaction steps assigned to the security element during execution of the transaction; a transaction control device, the transaction control device being operable by a user and specifically accessible by the security element. The security element is configured to send display data related to the transaction for which the application processor requests the security element to the auxiliary processor, and the auxiliary processor is configured to display the display data sent by the security element with a higher priority than the display data sent by the application processor, whereby the user does not see forged display data that the application processor may want to display under the influence of malware.

[0019] According to one embodiment, the transaction control device that is operable by the user and specifically accessible by the security element comprises a monostable button, the monostable button being operable by the user at the moment when the security element requests transaction verification for transaction verification.

[0020] According to one embodiment, the monostable button is a virtual button on a touchpad.

[0021] According to one embodiment, the transaction control device includes a bistable physical switch operable by the user, and the security element is configured to switch to an active mode in a first position of the switch and to a non-active mode in a second position of the switch.

[0022] According to one embodiment, the application processor is configured to request the user to actuate the switch during execution of a transaction to place the security element in the active mode, and the security element is configured to request the user to actuate the switch again to place it in the non-active mode after having executed the transaction step assigned to it.

[0023] According to one embodiment, the human-machine interface further includes an input device controlled by a corresponding bus, and the terminal further includes a demultiplexer arranged to connect the input device bus to the application processor or the security element, the demultiplexer being controlled by the security element.

[0024] According to one embodiment, the security element is configured to prohibit, during execution of the transaction step assigned to it, circuits or components in the terminal that can be used by an attacker to obtain information about actions performed by the user or computations performed by the security element, such as accelerometers, inertial measurement units, cameras, current sensors, voltage sensors, or other components that would allow an attacker to perform a side-channel attack.

[0025] According to one embodiment, the terminal further includes a visual indicator visible to the user, the visual indicator being specifically controlled by the security element to be activated during execution of the transaction step assigned to the security element.

[0026] According to one embodiment, the application processor and the auxiliary processor are integrated in the same system-on-chip.

[0027] According to one embodiment, the terminal is connected to the Internet and is configured to perform encrypted asset transactions on the blockchain.

[0028] The embodiment also relates to a method for performing a secure transaction on a public or local network by means of a connected terminal, the connected terminal including: a human-machine interface including a display manageable by a control bus; an application processor including components for connecting to the public or local network; an auxiliary processor integrating a display controller of the control bus connected to the display, the application processor being configured to provide data to be displayed to the auxiliary processor, the method including the following steps: providing an embedded security element connected to the application processor and the auxiliary processor via a wired bus, and configuring the security element to perform certain steps of the transaction, including at least one cryptographic calculation step involving a secret stored in the security element; configuring the application processor to request the security element to perform the transaction steps assigned to the security element during execution of the transaction; providing a transaction control device operable by a user and specifically accessible by the security element; configuring the security element to send display data related to the transaction for which the application processor requests the security element to the auxiliary processor; and configuring the processor to display the display data sent by the security element with a higher priority than the display data sent by the application processor, whereby the user does not see display data including forged information about the transaction that the application processor might want to display under the influence of malware.

[0029] According to one embodiment, the method includes the following steps: providing a bistable physical switch operable by the user, which forms all or part of the transaction control device; configuring the security element such that when the bistable physical switch is in a first position, the security element places itself in an active operating mode, and when the bistable physical switch is in a second position, the security element places itself in an inactive operating mode.

[0030] According to one embodiment, the method includes the following steps: configuring the application processor to request the user to actuate the switch during execution of the transaction to place the security element in the active mode; and configuring the security element to request the user to actuate the switch again after having performed the transaction steps assigned to it to place it in the inactive mode.

[0031] According to one embodiment, the method includes the following steps: providing an input device controlled by a corresponding bus as an element of the human-machine interface, providing a demultiplexer to connect the input device bus to the application processor or the security element, and controlling the demultiplexer by means of the security element.

[0032] According to one embodiment, the method comprises the steps of: configuring the secure element to prohibit, during execution of the transaction steps assigned to it, circuitry or components in the terminal that can be used by an attacker to obtain information about actions performed by the user or calculations performed by the secure element, such as accelerometers, inertial measurement units, cameras, current sensors, voltage sensors, or other components that would permit an attacker to perform side-channel attacks.

[0033] According to one embodiment, the method comprises the steps of: providing a visual indicator perceptible by the user, specifically controlled by the secure element, and configuring the secure element such that it activates the visual indicator during execution of the transaction steps assigned to it. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Embodiments will be described in the following description of non-limiting examples in connection with the drawings, in which:

[0035] Figure 1 Illustrates a conventional example of using a hardware wallet via a host device;

[0036] Figure 2 Illustrates a conventional hardware wallet architecture;

[0037] Figure 3 Is a partial block diagram of a first embodiment of a mobile terminal or other connected device incorporating a hardware wallet;

[0038] Figure 4 Is a block diagram of a first embodiment of a connected terminal that defeats a first type of fraud that may target a terminal of the type Figure 3 ;

[0039] Figure 5 Is a block diagram of a first embodiment of a connected terminal that defeats a first type of fraud that may target a terminal of the type Figure 3 ;

[0040] Figure 6 Is a block diagram of an embodiment of a connected terminal that defeats a second type of fraud that targets a terminal of the type Figure 5 ;

[0041] Figure 7 Is a block diagram of an embodiment of a connected terminal in which the use of an embedded secure element is under user control; and

[0042] Figure 8 Illustrates the component arrangement of a connected mobile terminal according to Figures 4 to 6 one of DETAILED DESCRIPTION

[0043] As indicated above, the aim is to integrate a hardware wallet into a connected terminal (smartphone or other connected device), while avoiding attacks that may be possible due to this configuration. To avoid creating a completely new ecosystem and not harm the user experience, compatibility with existing hardware and operating systems (Android, iOS) is also sought, as well as the use of traditional application distribution channels. Thus, such mobile terminals can install and execute applications that may come from unknown or even suspicious sources, which increases the challenge of protecting transactions through an embedded hardware wallet.

[0044] Thus, it is assumed that the installable application can gain access to the hardware resources involved in the communication with the secure element implementing the hardware wallet.

[0045] Generally, official applications of relevant services (especially financial services (banks, cryptocurrencies)) are certified and signed and are more difficult to modify with malicious code. When they are loaded for execution, if they have been modified, the signature verification fails. However, malware can infer the specific interactions of the official application with the hardware and modify the inputs and outputs of the official application.

[0046] For example, malware may record the keys pressed to steal passwords, simulate the keys pressed to forge transactions, and modify the display to deceive the user about the transactions they are performing.

[0047] More specifically, the verification of a transaction on the phone by a virtual keyboard can be intercepted by low-level spyware capable of accessing the touchscreen interface by detecting the coordinates of touches on the touchscreen. Without knowing what is being displayed, the spyware can rely on the assumption that the virtual keyboard displayed is one of the many traditional keyboards available on the platform, such that the touch coordinates reveal the keyboard keys. The spyware can also access the accelerometer or other sensors that are typically present in a mobile terminal - touches at different positions on the screen translate into different acceleration values rotating on two axes, such that the touch position can be inferred.

[0048] To remedy this partially, the application displays a numeric virtual keyboard with randomly positioned keys for personal identification code entry. However, although this measure is useful for preventing the inference of the identification code, it does not prevent malware from inferring that a transaction is in progress and, before the user finishes, modifying the amount or recipient and simulating the verification (modifying the inputs of the application without modifying the application itself).

[0049] Figure 3 Partial block diagram representing a first implementation of a mobile terminal or other connected device embedding a hardware wallet.

[0050] The mobile terminal integrates an application processor APP PROC that is connected to various peripheral devices, particularly a touch screen including a display DISP and a touchpad KBD. The processor manages the display through a dedicated display interface bus (usually the MIPI DSI bus). The processor manages the touchpad through another interface (usually I2C). For the sake of clarity, not all elements of the mobile terminal are shown.

[0051] When the mobile terminal is designed to perform secure transactions, like most current mobile terminals, the application processor usually integrates a secure enclave or a Trusted Execution Environment TEE. Such an enclave typically includes a processor, a memory, and a display manager or a display controller DC1 for managing the touch screen. It is designed to implement a Trusted User Interface TUI, such as recommended by the "Trusted User Interface API" document from (see the references in the appendix). Thus, as shown in the figure, the enclave can manage the input section on the display DISP and the touchpad KBD according to the instructions executed by the application.

[0052] Such an enclave is different from the secure element usually used in a hardware wallet and does not provide a sufficient level of security for password asset transactions managed by the blockchain alone. In fact, since a hardware wallet can provide access to very high values in password assets, the means employed by hackers are commensurate with the values they can extort.

[0053] According to the embodiments described herein, the mobile terminal further includes an embedded secure element eSE that implements a hardware wallet. The element eSE can be similar to the element integrated in the previously described separate hardware wallet (also known as a cold hardware wallet). It can be an ST33 microcontroller that has a secure serial peripheral interface (SPI), two I2C interfaces, and various programmable input / output pins GPIO, etc. The link (generally a USB interface or a Bluetooth interface) between the mobile terminal HDV and the separate hardware wallet HW represented by LKK in Figure 1 is here implemented through a permanent wired connection (via the SPI interface) between the secure element eSE and the application processor. To ensure better communication security, the connection can be managed by the TEE enclave, as shown in the figure.

[0054] The implementation of the hardware wallet function in the element eSE and the exchange between the element eSE and the processor APP PROC can be completely similar to what is Figure 1 known, so that by analogy, considering the secure element here forms Figure 1 the separate wallet HW and the application processor here forms Figure 1 the host device HDV.

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

[0056] With this configuration, a transaction is prepared in the usual way by an official application (such as "Ledger Live") executed on 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 input phase on the touchpad KBD, such as entering an identification code to unlock the security element. The verification and signing of the transaction are delegated to the element eSE by commands issued via the enclave TEE on the SPI bus. If applicable, the entered unlock code is sent to the security element via the SPI bus. The element eSE responds to these commands by activating the indicator LED and waiting for a press on the button B.

[0057] When the button B is pressed, the element eSE calculates the transaction signature using the private key stored in the wallet and sends the signature to the application via the SPI bus. The security element that has completed its task deactivates the indicator LED and waits for a new command. The application updates the blockchain via a network service, displays useful information, and waits for new user interactions.

[0058] If no action is detected on the button after a timeout, the transaction is cancelled. The security element signals this to the application via the SPI bus, deactivates the indicator LED, and waits for a new command.

[0059] The button B has a function similar to that of the buttons B1, B2 of the Figure 2 separate hardware wallet of the type shown. If malware manages to modify the amount or address of the transaction, it will not be able to simulate the verification, which requires the actuation of a physical button that can only be detected by the element eSE. Thus, 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 this on the display and cancel the transaction. The cancellation can be routinely performed by pressing a virtual button on the touch screen. The cancellation button function cannot be hijacked into the verification function because verification is only possible using the physical button B specifically managed by the element eSE.

[0060] The indicator LED reassures the user that the secure element is handling the operation and that, in principle, the requests made to it come from a trusted source.

[0061] According to a slightly more expensive variant in manufacturing the mobile terminal housing, two physical buttons that must be pressed simultaneously to verify a transaction can be provided, as is done with a separate hardware wallet.

[0062] Now, as previously indicated, more sophisticated malware can modify the input and / or output data of an application to hijack it. For example, the malware can intercept the transaction data entered in an application to replace it (such as the amount and address). Even when it is difficult to do this when using the enclave TEE in a secure mode to perform the input, given the level of security provided by a conventional TEE enclave, it is not impossible. Then, the application will generate a transaction with forged data, which will communicate the transaction to the element eSE. To prevent the user from noticing the forgery by observing the displayed transaction data, the display itself can be controlled by the malware (even if this is difficult) so that the data displayed corresponds to the transaction that the user initially expected. Thus, the user will see apparently correct transaction data and verify the transaction, but the verification will operate on a fraudulently modified transaction that has been secretly entrusted to the element eSE.

[0063] In a conventional separate hardware wallet, this type of fraud is hindered by the fact that the hardware wallet has its own display and presents the necessary characteristics of the transaction on that display: the user relies on the information displayed by the separate hardware wallet and can compare it with the information displayed by the application on the terminal. When the hardware wallet is embedded in a connected terminal of the smart phone type or the like, given the difficulty of providing a second display and the additional cost this would entail, such functionality is not feasible.

[0064] Figure 4 It is a block diagram of a first embodiment of a mobile terminal that integrates a hardware wallet and eliminates this type of display manipulation.

[0065] In comparison with Figure 3 the processor APP PROC is associated with a secondary processor PROC2. The processor PROC2 has its own display controller DC2. In one embodiment, the application processor APP PROC has a TEE enclave as before, and the processor PROC2 has a command set that allows it to control the enclave TEE via the SPI bus. In one embodiment, the application processor APP PROC and the processor PROC2 are integrated into a system-on-chip SoC, such as the i.MX 8M Plus circuit from

[0066] The display controller DC2 of the processor PROC2 uses the frame buffer FB1 to control the MIPI DSI bus of the display DISP. The processor PROC2 can fill this frame buffer as needed from the content of the frame buffer FB2 of the application processor, from the content of the frame buffer FB3 of the enclave TEE (arrow CPY) (if such an enclave is provided), or from display data received through another channel or generated internally.

[0067] In another embodiment, the processor PROC2 uses the pointers provided to it to directly display data from the memories FB2 or FB3. The display mechanism is documented and will not be described in more detail. In general, regardless of the selected embodiment, the processor PROC2 is designed to be the master of the MIPI DSI bus because it can decide which data it provides to the display depending on the source of the data.

[0068] Therefore, depending on the needs of the running application, the display DISP receives display data from the application processor, the enclave TEE, or the secondary processor PROC2 itself. Since the display controller DC2 is controlled by the processor PROC2, the processor PROC2 can select the information to be sent to the display DISP in order to display the information it deems to be a priority according to its configuration.

[0069] In this embodiment, the element eSE is connected to the processor PROC2 via the SPI bus for the purpose of managing the display according to the method described below, and the processor PROC2 is configured via software to give priority to the display commands issued by the element eSE.

[0070] In addition, the touchpad KBD can still be managed by the enclave TEE for secure input, but other control modes applicable to this embodiment will be described below.

[0071] With this configuration, transactions are prepared in the usual way by official applications (such as "LedgerLive") executed by the processor APP PROC. The application delegates the processing of sensitive transaction steps to the element eSE via the SPI bus, for example, during the steps where the user must verify the transaction and where the private key of the cryptographic asset account held by the element eSE must be used to sign the transaction. The application can also use the enclave TEE (if provided), for example, if a unlock code input is required.

[0072] Regarding the display of transaction-related information for user verification, as Figure 3As shown, the display data generated by the application can be sent to the display controller DC2 via the frame buffer FB3 of the enclave TEE or the frame buffer FB2 of the application processor, which is then filled with corresponding graphics data and its contents are then sent to the frame buffer FB1 of the display controller DC2.

[0073] In parallel, the element eSE which has itself received the transaction data sends display data to the processor PROC2 via the bus SPI for display via its display controller FB1 , instead of the data present in the frame buffers FB2 and FB3 .

[0074] If the transaction display data generated by the application are accidentally corrupted by malware, these data end up in frame buffers FB2 or FB3, but they are ignored because it is the data generated by element eSE in frame buffer FB1 that is actually displayed.

[0075] In such embodiments, the processor PROC2 thus plays the role of a kind of software multiplexer, since it is configured via software to give priority to the display data provided by the secure element. For this reason, the processor PROC2 is preferably configured in hardware and / or software to provide a high degree of security. In hardware, similar to the secure element, the processor PROC2 is preferably "isolated" relative to other circuits communicating with it to reduce its attack surface. In particular, the number of hardware connections between the processor PROC2 and other circuits (e.g., connections to the processor APP PROC and the enclave TEE) can be reduced to a minimum to prevent attacks on these elements from allowing control of the processor PROC2 to be taken. Schematically, this minimum hardware connectivity can rely on the fact that the connection between the processor APP PROC and the processor PROC2 is reduced to a connection that allows the processor APP PROC to pass the content of the frame buffer FB2 to the processor PROC2. Similarly, the hardware connectivity between the enclave TEE and the processor PROC2 can be reduced to only the SPI bus, through which the content of the frame buffer FB3 is passed to the frame buffer FB1. The processor PROC2 can also execute software that is protected against various known attacks.

[0076] Figure 5 , Figure 6 and Figure 7Shows other embodiments of a mobile terminal that integrates a hardware wallet, also eliminates display manipulation by malware, and provides a solution compatible with multiple chipsets available for smartphones. In these embodiments, the display data conveyed on the display interface bus connected to the display DISP (here, as previously mentioned, the MIPI DSI bus) is controlled by the element eSE. Thus, the latter can decide to inject its own display data on the MIPI DSI bus while preventing the data provided by the application processor from reaching the display. This "injection" of display data by the element eSE is done through routing in the form of a multiplexer MUX controlled by the element eSE. The multiplexer MUX receives the display data provided by the processor APP PROC on a first input and the display data provided by the element eSE on a second input. The output of the multiplexer is directly connected to the display, which provides the display data in MIPI DSI format to the display, and the display data is either the data provided by the application processor or the data provided by the security element.

[0077] Such an architecture based on display control by a security element (using hardware multiplexing of a low-level bus (here MIPI DSI) to convey display data in a format directly usable by the display) minimizes the attack surface of all components of the connected terminal.

[0078] Specifically, security issues caused by placing a display controller that converts the unformatted data (or data formatted according to another protocol) provided by the multiplexer into MIPI DSI data at the multiplexer output are avoided. Such a display controller would be exposed to attacks, especially software attacks (aimed at corrupting the data it provides to the display). If such a display controller is connected to the application processor and the security element through a common control bus (such as a bus carrying synchronization signals), such a display controller can also provide a significant attack surface to fraudsters through this control bus.

[0079] Therefore, the solution proposed here involving switching low-level display signals (i.e., signals that do not require transformation before being provided to the display) allows avoiding this type of attack.

[0080] In Figure 5In an embodiment, the MIPI DSI bus of the display DISP is thus connected to the output of the multiplexer MUX. The multiplexer receives, on a first input, display data in MIPI DSI format that is generated by the display controller DC3 of the processor APP PROC and formatted according to the MIPI DSI protocol. Alternatively, this data can be provided by the display controller of the enclave TEE (which is not shown). However, in practice, these display data no longer need to be managed by the enclave TEE, as shown in the figure. In fact, the second input of the multiplexer receives display data in MIPI DSI format generated by the display controller DC4 that is specifically managed by the element eSE, thus allowing for the secure display of sensitive information. The input / output pin GPIO3 of the element eSE is programmed to provide a signal SEL to the multiplexer for selecting the first input or the second input of the multiplexer. The SEL signal can also be taken from the pin GPIO2 that controls the indicator LED.

[0081] The display controller DC4 receives display commands from the element eSE via, for example, an I2C bus. The I2C bus provides a relatively low data throughput, but this bus is used to carry only text and vector display commands using low bandwidth. The element eSE is thus programmed to generate basic display commands for the transactions it processes and send them to the display controller.

[0082] The display controller DC4 is a separate circuit here because the commonly available secure element chips do not have either one or do not have sufficient bandwidth to generate the bitmap images expected on the bus of a display (such as the display of a modern smartphone).

[0083] When waiting for a transaction signature request, the element eSE controls the multiplexer MUX to transfer MIPI DSI format display data from the application processor to the display DISP.

[0084] When an application executed by the processor APP PROC delegates the transaction signature to the element eSE, the latter transfers a transaction data display command to the display controller DC4 and switches the multiplexer MUX so that the MIPI DSI format data generated by the display controller DC4 reaches the display DISP. The indicator LED is activated and the element eSE waits for verification via the button B.

[0085] With this configuration, the display DISP presents the transaction data actually received by the element eSE. If they have been modified from the original intention, the user will see it and can cancel the transaction.

[0086] Of course, it is preferably that any unlock code entry or other sensitive information for managing the element eSE presents a security level that is at least equal to the security level of the display.

[0087] Figure 6 It is a block diagram of an implementation of a mobile terminal that uses the component eSE instead of the enclave TEE to manage the touchpad KBD and raises the security level to that of the secure component. Compared with Figure 5 the I2C output bus of the touchpad KBD is connected to a router in the form of a demultiplexer DMUX, whose first output is connected to the processor APP PROC and the second output is connected to the I2C interface of the component eSE. The demultiplexer DMUX is selected by the same signal SEL as the multiplexer MUX. In this structure, the physical verification button B is optional, as will be understood below. In addition, the enclave TEE is no longer needed and is no longer shown.

[0088] When waiting for transaction processing, in the traditional configuration, the component eSE positions the multiplexer MUX and the demultiplexer DMUX to connect the display DISP and the touchpad KBD to the application processor.

[0089] Since the touch screen is out of application control during delegation to the secure component, the application can no longer implement the user input phase. Therefore, the user input phase is also delegated to the secure component, which is temporarily programmed to manage the virtual keyboard for user input and display.

[0090] When the application delegates a transaction to the secure component via the SPI bus, this time without passing through the enclave TEE, the component eSE switches the multiplexer and the demultiplexer to connect the display DISP and the touchpad KBD to the display controller DC4 and the component eSE respectively. If input is required (providing an unlock code), the component eSE performs the user input phase. Input on the touchpad can no longer be intercepted or modified by the software running on the application processor, and any attempt to modify the display by the software running on the application processor is ignored.

[0091] Given this configuration, the software running on the application processor cannot simulate an error verification on the touch screen, so the physical button B is optional; in addition, the touchpad can also be used for secure verification.

[0092] The security of the touchpad KBD has been described starting from the Figure 5 structure, but it applies to the Figure 4 structure, where in the secure mode, the touchpad management is switched to the secure component instead of the enclave TEE.

[0093] According to one embodiment, the signal SEL or any other security mode indicator (such as the control signal for an indicator LED) is used to disable circuits or components that are not normally used during the security mode and that could serve an attacker to obtain information about actions performed by the user or computations performed by the element eSE, such as accelerometers, inertial measurement units, cameras, current sensors, voltage sensors, or other components that could allow an attacker to perform a side-channel attack, or the application processor itself.

[0094] For example, the signal SEL is connected to the pin INHIB for stopping the application processor. The stop can be achieved by activating the processor reset input, cutting off its clock signal, or cutting off its power supply. In this case, any malware running on the application processor that attempts to perform an analysis to infer cryptographic keys or other sensitive information is rendered inoperative during a secure transaction.

[0095] Specifically, in a configuration (e.g., Figure 6 configuration), complete deactivation of the application processor is possible, where all functions that must remain active during a transaction are moved to the element eSE.

[0096] If it is not possible or not desirable to deactivate the application processor, the signal SEL can be used to deactivate auxiliary components or circuits that can be used to infer sensitive information that could allow a side-channel attack. For example, the information provided by an accelerometer allows the inference of touchpad touch locations. Accelerometers are typically integrated into dedicated inertial measurement units or IMU circuits. Such inertial measurement units can be deactivated by stopping their clock, cutting off their power supply, or cutting off their communication link with the application processor (usually an I2C bus).

[0097] Malware can be designed to initiate a transaction when the element eSE is in a configuration where it does not request an unlock code, for example, during a limited time period after a previous transaction. The malware attempts to modify the display, but this attempt fails because in Figure 5 and Figure 6 the element eSE is the master of the display. Thus, the display reflects the transaction actually initiated by the malware while the element eSE waits for user authentication on the touchpad (in the Figure 6 configuration) or on the physical button B (in the Figure 4 or Figure 5 configuration). In the case of Figure 3 fraudulent modification of the display is possible, and thus the user can be deceived regarding the nature of the transaction.

[0098] If a fraudulent transaction is initiated while the user has the mobile terminal in sight, the user sees the terminal enter the safe mode (LED indicator), display the transaction, and request verification without having requested it. The user can confirm the display and cancel the transaction, but this requires the user to be focused and not erroneously verify the transaction.

[0099] If the user does not have the mobile terminal in sight, the transaction is automatically cancelled in principle when the timeout period expires. However, if the mobile terminal is shaken in a pocket or a bag, an inadvertent verification may occur before the timeout period expires by pressing the physical button B ( Figures 3 to 5 ), or by pressing the touchpad ( Figure 6 ), which can be configured to operate on the lock screen of the mobile terminal when verification is requested.

[0100] Figure 7 is a block diagram of an embodiment of a mobile terminal that defeats this type of fraud. The aim here is to somehow simulate the connection and disconnection operations of a conventional separable wallet with its host device, i.e., to establish or disconnect the connection between the separable wallet and its host device, such as a Bluetooth or USB connection. In addition to the Figure 6 components, the physical bistable switch S is connected to link the input / output pin GPIO4 of the component eSE to a low logic level in a first position and to a high logic level in a second position. The switch S is arranged, for example, on one of the side walls of the mobile terminal device.

[0101] The component eSE is programmed to be silent (inactive mode) for commands received via the bus SPI in one of the positions of the switch S (e.g., in the first position), and to accept transactions via the bus SPI in the other position (active or safe mode). The terminal is designed such that the switch S is the only component available for switching the mode of the component, which means that the application can no longer itself delegate transaction processing.

[0102] Thus, the mode of the security component is specifically under the user's control, who uses the switch S as needed to select the mode.

[0103] In the case where the switch S is initially in the inactive mode position, an application that may initiate a transaction is then designed to prompt the user to change the mode when it is about to delegate the transaction processing to the component eSE. It can transmit a message such as "Please use the switch to put the phone in safe 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 separable wallet to the mobile terminal.

[0104] Then the user toggles the switch to enter the active mode. The component eSE responds by taking various protective measures, such as toggling the signal SEL to connect the display DISP to the display controller DC4 and connecting the touchpad KBD to the component eSE. The indicator LED is also activated to signal to the user that the mobile terminal is in the secure mode. The component eSE conveys an acknowledgement to the application, which resumes execution by sending transaction information to the component eSE. The component eSE operates the user input phase on the touchpad KBD (if applicable) and requests verification from the user by displaying the transaction information again.

[0105] When the transaction is verified and signed, the component eSE conveys the signed transaction to the application that records it on the blockchain. The component eSE prompts the user to change the mode by conveying a message such as "Please exit the secure mode by toggling the switch" to the display DISP. This message is similar to the message indicating that the user can remove their regular detached wallet. When the switch is toggled, the initial connections of the display and the touchpad are restored, and the indicator LED is deactivated.

[0106] The switch S can also be implemented in the Figure 4 and Figure 5 structure, where the touchpad KBD is not connected to the component eSE. In this case, the application operates the user input phase before requesting the toggling of the switch S.

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

[0108] Malware can also act like an official application by requesting a mode change. However, since the user has not initiated a transaction and is being asked for a relatively restrictive action, the user may be more vigilant. Malware may no longer display misleading off-topic messages as the user expects to see transaction information. Such transaction information will be difficult to be credible, especially if it is real - typically a large transfer to an unknown address. If the malware attempts to hide the nature of the transaction, when the transaction is displayed for verification by the component eSE, if the user still wants to switch to the secure mode, the transaction will be revealed and be different.

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

[0110] Figure 8 Illustrates according to Figures 4 to 6Component layout of a mobile terminal (smartphone) among them. The purpose here is to be able to "port" the hardware wallet function into a conventional mobile terminal platform to convert it into a mobile terminal with an embedded hardware wallet.

[0111] In a conventional mobile terminal, the processor APP PROC and potentially its enclave TEE can be implemented as a system-on-chip SoC. The SoC includes pins soldered to the corresponding tracks of the printed circuit board or other interconnect supports that receive several other components. Different communication links are associated with the corresponding pin groups and components, especially the aforementioned MIPI DSI, SPI, and I2C buses.

[0112] In addition, the display DISP and the touchpad KBD are usually outside the printed circuit board and parallel to the printed circuit board. Their different control buses are then connected to the printed circuit board through connectors soldered to the tracks on the printed circuit board.

[0113] According to the selected implementation, the various elements for implementing the embedded hardware wallet selected from the elements eSE, DC4, MUX, DMUX, and connectors for all or part of the elements B, S, and LED are implemented in the form of a device DHW integrated into the conventional mobile terminal platform. The device DHW can be a system-in-package SiP designed to be mounted on the printed circuit board or form another SoC (SoC2).

[0114] To make the device DHW suitable for the conventional mobile terminal platform and thus achieve the integration of the embedded hardware wallet, a space for soldering the device DHW is arranged on the printed circuit board, which is in the form of a SiP for example. The tracks of the different buses used are rerouted by interrupting them so that they pass through the device DHW, and the tracks are routed to establish an SPI bus between the processor APP PROC and the element eSE.

[0115] The different discrete physical elements (button B, switch S, indicator LED) managed by the circuit of the SiP can be fixed to the housing of the terminal and connected to the connectors of the SiP or to connectors offset on the printed circuit board, which are themselves connected to the dedicated pins of the SiP through tracks.

[0116] It should be noted that this integration of the device DHW into a conventional mobile terminal is significantly simplified by the fact that the multiplexer MUX is directly interposed on the MIPI DSI bus that connects the processor APP PROC to the display DISP, which allows intercepting the insecure stream of image data provided by the application processor to replace it with the secure stream of image data provided by the display controller DC4 of the element eSE. Therefore, there is no need to reverse-decode the MIPI DSI format image data, nor is it necessary to provide a display controller at the output of the multiplexer MUX to provide the MIPI DSI format image data.

[0117] With this configuration, a conventional mobile terminal can be transformed into a mobile terminal with an embedded hardware wallet by simply adding the device DHW in a SiP package or as an SoC on the printed circuit board carrying the conventional terminal components. Although designing the adapted printed circuit board poses specific development and production costs, this cost is still negligible as no adaptation is made at the level of the conventional terminal hardware platform.

[0118] It should be noted that MIPI DSI is currently the most commonly used display interface bus standard between the mobile terminal display controller and the display peripherals. It is obvious to those skilled in the art that if another type of display interface bus (if applicable) other than MIPI DSI is used, the ideas and principles just described regarding integrating the hardware wallet into the mobile terminal can be applied.

[0119] It will also be obvious to those skilled in the art that depending on the technological evolution, the described embodiments are susceptible to various substitutions. Specifically, although the element eSE has been described above as being associated with a different display controller DC4 to which it is connected via the I2C bus, it is not excluded that the secure element may integrate such a display controller DC4 in the future.

[0120] The foregoing description has been written essentially in the context of a smart phone ("blockchain smart phone") that embeds a hardware wallet for signing transactions on a blockchain. Then, the described principles apply to any type of connected terminal (to the Internet or a local network) that stores secrets for various purposes involving cryptographic computations, such as general signature transactions and authentication (including "zero-knowledge" authentication). In other types of connected terminals, the human-machine interface can be a display associated with a physical keyboard or a joystick.

[0121] Appendix

[0122] from the "Trusted User Interface API":

[0123] https: / / globalplatform.org / wp-content / uploads / 2013 / 06 / GlobalPlatform_Trusted_User_Interface_API_v1.0.pdf

Claims

1. A connected terminal, the connected terminal comprises: - A human-machine interface, the human-machine interface includes a display (DISP) that can be managed by a control bus (MIPI DSI), - An application processor (APP PROC), the application processor includes components for connecting to a public or local network and is configured to execute transactions, - An auxiliary processor (PROC2), the auxiliary processor integrates a display controller (DC2, FB1) that connects to the control bus of the display (DISP); wherein the application processor (APP PROC) is configured to provide (FB2) data to be displayed to the auxiliary processor (PROC2), characterized in that the terminal includes: - An embedded security element (eSE), the embedded security element is connected to the application processor and the auxiliary processor (PROC2) through a wired bus (SPI), the security element is configured to execute certain steps of the transaction, including at least one cryptographic calculation step involving a secret stored in the security element, the application processor is configured to request the security element to execute the transaction steps assigned to the security element during the execution of the transaction, - A transaction control device (B, S), the transaction control device can be operated by the user and can be specifically accessed by the security element (eSE), and wherein the security element (eSE) is configured to send display data related to the transaction requested by the application processor to the auxiliary processor (PROC2) for the application processor, and the auxiliary processor is configured to display the display data sent by the security element with a higher priority than the display data sent by the application processor, whereby the user does not see the forged display data that the application processor may want to display under the influence of malware.

2. The terminal according to claim 1, wherein the transaction control device (B) that can be operated by the user and can be specifically accessed by the security element (eSE) includes a monostable button (B), and the monostable button can be operated by the user at the moment when the security element requests transaction verification for transaction verification.

3. The terminal according to claim 2, wherein the monostable button is a virtual button on a touchpad.

4. The terminal according to any one of claims 1 to 3, wherein the transaction control device (B) includes a bistable physical switch (S) that can be operated by the user, and the security element (eSE) is configured to switch to an active mode in the first position of the switch and to a non-active mode in the second position of the switch.

5. The terminal according to claim 4, wherein the application processor is configured to request the user to actuate the switch during the execution of a transaction to place the security element in the active mode, and the security element is configured to request the user to actuate the switch again to place the security element in the inactive mode after having executed the transaction step assigned to the security element.

6. The terminal according to any one of claims 1 to 5, wherein the human-machine interface further comprises a user input device (KBD) controlled by a corresponding bus (I2C), and the terminal further comprises a demultiplexer (DMUX) arranged to connect the user input device bus to the application processor or the security element, the demultiplexer (DMUX) being controlled by the security element (eSE).

7. The terminal according to one of claims 1 to 6, wherein the security element is configured to inhibit, during the execution of the transaction step assigned to the security element, circuits or components in the terminal that can be used by an attacker to obtain information about the actions performed by the user or the calculations performed by the security element, such as an accelerometer, an inertial measurement unit, a camera, a current sensor, a voltage sensor, or other components that can allow an attacker to perform a side-channel attack.

8. The terminal according to one of claims 1 to 7, the terminal further comprising a visual indicator (LED) visible to the user, the visual indicator being specifically controlled by the security element to be activated during the execution of the transaction step assigned to the security element.

9. The terminal according to one of claims 1 to 8, wherein the application processor (APP PROC) and the auxiliary processor (PROC2) are integrated in the same system-on-chip.

10. The terminal according to any one of claims 1 to 9, the terminal being connected to the Internet and configured to perform encrypted asset transactions on a blockchain.

11. A method for performing a secure transaction on a public or local network by means of a connected terminal, the connected terminal comprising: - a human-machine interface comprising a display (DISP) that can be managed by a control bus (MIPIDSI), - an application processor (APP PROC) comprising components for connecting to the public or local network, - an auxiliary processor (PROC2) that integrates a display controller (FB1) connecting to the control bus of the display (DISP), wherein the application processor (APP PROC) is configured to provide (FB2) data to be displayed to the auxiliary processor (PROC2), characterized in that the method comprises the following steps: - Provide an embedded secure element (eSE) connected to the application processor and the auxiliary processor (PROC2) via a wired bus (SPI), and configure the secure element to perform certain steps of the transaction, including at least one cryptographic calculation step involving secrets stored in the secure element. - Configure the application processor to request the secure element to perform the transaction steps assigned to the secure element during the execution of the transaction. - Provide a transaction control device (B, S) that can be operated by the user and can be specifically accessed by the secure element (eSE). - Configure the secure element (eSE) to send display data related to the transaction for which the application processor requests the secure element to the auxiliary processor, and - Configure the processor to display the display data sent by the secure element with a higher priority than the display data sent by the application processor, so that the user does not see display data including forged information about the transaction that the application processor may want to display under the influence of malware.

12. The method according to claim 11, the method comprises the steps of: - Provide a bistable physical switch (S) that can be operated by the user, and the bistable physical switch forms all or part of the transaction control device. - Configure the secure element such that when the bistable physical switch is in the first position, the secure element places itself in the active operation mode, and when the bistable physical switch is in the second position, the secure element places itself in the inactive operation mode.

13. The method according to claim 12, the method comprises the steps of: - Configure the application processor to request the user to actuate the switch during the execution of the transaction to place the secure element in the active mode, and - Configure the secure element to request the user to actuate the switch again after the transaction steps assigned to the secure element have been executed to place the secure element in the inactive mode.

14. The method according to any one of claims 11 to 13, the method comprises the steps of: - Provide a user input device (KBD) controlled by a corresponding bus (I2C) as an element of the human-machine interface. - Provide a demultiplexer (DMUX) to connect the user input device bus to the application processor or the secure element, and - Control the demultiplexer (DMUX) by means of the secure element (eSE).

15. The method according to any one of claims 11 to 14, the method comprises the steps of: Configure the security element to inhibit, during execution of a transaction step assigned to the security element, circuitry or components in the terminal that can be used by an attacker to obtain information about actions performed by the user or computations performed by the security element, such as an accelerometer, an inertial measurement unit, a camera, a current sensor, a voltage sensor, or other components that can allow an attacker to perform a side-channel attack.

16. The method according to one of claims 11 to 15, the method comprising the steps of: - providing a visual indicator (LED) visible to the user, the visual indicator being specifically controlled by the security element, and - configuring the security element such that the security element activates the visual indicator during execution of a transaction step assigned to the security element.

Images