Method for switching a terminal to a secure mode for processing a transaction

Abstract

An electronic terminal includes an application processor (APP PROC) configured to execute at least one transaction; and a secure element (eSE) configured to execute at least one cryptographic calculation required to complete the transaction under a request of the application processor, and to provide a result of the cryptographic calculation to the application processor. The terminal comprises: a transaction verification device (B) operable by a user and specifically accessible by a secure element (eSE); and a physical bistable switch (S) which is operable by the user and is specifically accessible by the secure element. The secure element is configured to enter an active mode in a first position of the switch, in which the secure element is responsive to a command from the application processor, and to enter an inactive mode in a second position of the switch, in which the secure element does not receive or is not responsive to a command from 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 crypto-assets managed by blockchains, such as non-fungible tokens (NFTs) and smart contracts, has given rise to various ways of storing and keeping private keys attached to these different types of crypto-assets. 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 crypto-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 are themselves 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 an 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 drawback of such a 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 crypto-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 able to be used, 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, a mobile phone, or a 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 use the hardware wallet HW through 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 degree of security by using a "secure element" to store private keys and sign transactions. The 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 appears 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 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 incorporates 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 that they consent or authorize the execution or completion of an operation.

[0009] When conducting a transaction, the hardware wallets as described above are usually separate portable devices that are temporarily connected to a "connected" host device (such as a mobile terminal or a smart phone). 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 feature makes these hardware wallets less ergonomic and tend to be 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 via 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 secure element unit, such that key transaction data can be implemented via the secure element, 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 secure 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] Accordingly, there is a need to improve the security of a hybrid architecture where multiple processors share access to a 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 an electronic terminal that, within the same housing, includes: an application processor configured to perform at least one transaction via a connection to an Internet network or to a local network; a security element connected to the application processor by a wired bus and configured to, upon request of the application processor, perform at least one cryptographic calculation required to complete the transaction using a secret held by the security element and provide the result of the cryptographic calculation to the application processor; a transaction verification device operable by a user and specifically accessible by the security element, the security element being configured to perform the cryptographic calculation after the transaction has been verified by the user by means of the transaction verification device; and a physical bistable switch operable by the user and specifically accessible by the security element. The security element is configured to enter an active mode in a first position of the switch, in which the security element responds to commands received from the application processor via the wired bus, and to enter an inactive mode in a second position of the switch, in which the security element does not receive or respond to commands from the application processor.

[0019] According to one embodiment, the application processor is configured to prompt the user to switch the switch to the active mode position when the switch is in the inactive mode position and the security element must perform the cryptographic calculation, and the security element is configured to prompt the user to switch the switch to the inactive mode position after performing the cryptographic calculation and providing the result of the cryptographic calculation to the application processor.

[0020] According to one embodiment, the terminal further includes an input device commanded by a corresponding bus and a demultiplexer commanded by the security element, the security element being configured to: when the security element is in the inactive mode, connect the input device bus to the application processor; and when the security element is in the active mode, connect the input device bus to the security element.

[0021] According to one embodiment, in the active mode, the input device is a touchpad and the transaction verification device is a virtual button on the touchpad.

[0022] According to one embodiment, the transaction verification device is a physical button.

[0023] According to one embodiment, the terminal includes a display device, and the application processor and the security element are connected to the display device by means of a multiplexer commanded by the security element, the multiplexer including a first input receiving display data provided by the application processor, a second input receiving display data provided by the security element, and an output providing the display data received on its first input or second input to the display device, the security element being configured to command the multiplexer such that: when the security element is in the inactive mode, the multiplexer provides the display data provided by the application processor to the display device, and when the security element is in the active mode, the multiplexer provides the display data provided by the security element to the display device.

[0024] According to one embodiment, the terminal is configured to perform the steps including: initializing a transaction using an application program executed by the application processor; in the case where the switch is in the inactive mode position, prompting the user to switch the switch to the active mode position using the application program and a message on the display device; upon switching the switch, transmitting an acknowledgement from the security element to the application program; upon receiving the acknowledgement, sending information about the transaction from the application program to the security element; using the security element, displaying the information related to the transaction, waiting for the user to verify the transaction, then performing the cryptographic calculation necessary to complete the transaction, and then transmitting the result of the cryptographic calculation to the application processor; and using the security element, prompting the user to switch the switch to the inactive mode position via a message on the display device.

[0025] According to one embodiment, the application processor is integrated in a system-on-chip mounted on an interconnect support, and the security element is integrated in a system-in-package mounted on the interconnect support.

[0026] According to one embodiment, the terminal forms a mobile phone, the secure element is configured to form a hardware wallet for encrypting an asset account, and the application processor is configured to execute an application program that allows transactions to be performed on the encrypted asset account.

[0027] The embodiment also relates to a method for integrating a hardware wallet for encrypted assets into a terminal, the method comprising the steps of: assembling an application processor, a secure element connected to the application processor via a wired bus, a transaction verification device operable by a user and specifically accessible by the secure element, and a physical bistable switch operable by the user and specifically accessible by the secure element in the same housing; configuring the application processor to perform at least one transaction via a connection to an Internet network or to a local network; configuring the secure element to, upon request of the application processor and after the user has verified the transaction by means of the transaction verification device, perform at least one cryptographic calculation required to complete the transaction using a secret held by the secure element, and provide the result of the cryptographic calculation to the application processor; and configuring the secure element to enter an active mode in the first position of the switch, in which the secure element responds to commands received from the application processor via the wired bus, and to enter an inactive mode in the second position of the switch, in which the secure element does not receive or respond to commands from the application processor.

[0028] According to one embodiment, the method comprises the steps of: configuring the application processor to prompt the user to switch the switch to the active mode position when the switch is in the inactive mode position and the secure element has to perform the cryptographic calculation; and configuring the secure element to prompt the user to switch the switch to the inactive mode position after performing the cryptographic calculation and providing the result of the cryptographic calculation to the application processor.

[0029] According to one embodiment, the method comprises the steps of: providing an input device, which is commanded by a corresponding bus; providing a demultiplexer, which is commanded by the secure element; and configuring the secure element such that: when the secure element is in the inactive mode, the secure element connects the input device bus to the application processor; and when the secure element is in the active mode, the secure element connects the input device bus to the secure element.

[0030] According to one embodiment, the method includes the following steps: providing a display device; connecting the application processor and the security element to the display device by means of a multiplexer commanded by the security element, the multiplexer including a first input for receiving display data provided by the application processor, a second input for receiving display data provided by the security element, and an output for providing to the display device the display data received on its first input or second input; and configuring the security element to command the multiplexer such that: when the security element is in the inactive mode, providing to the display device the display data provided by the application processor; and when the security element is in the active mode, providing to the display device the display data provided by the security element. Description of the Drawings

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

[0032] Figure 1 Illustrates a conventional example of using a hardware wallet by a host device;

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

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

[0035] Figure 4 Is Figure 3 A block diagram of a first embodiment of a connected terminal that defeats a first type of fraud targeting terminals of the type that may be

[0036] Figure 5 Is Figure 3 A block diagram of a second embodiment of a connected terminal that defeats a first type of fraud targeting terminals of the type that may be

[0037] Figure 6 Is Figure 5 A block diagram of an embodiment of a connected terminal that defeats a second type of fraud targeting terminals of the type that may be

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

[0039] Figure 8 Illustrates Figures 4 to 6 The component arrangement of a connected mobile terminal according to one of Detailed Description

[0040] 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 without compromising 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 with an embedded hardware wallet.

[0041] It is thus assumed that the installable application can gain access to the hardware resources involved in the communication with the secure element implementing the hardware wallet.

[0042] 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.

[0043] 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.

[0044] 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.

[0045] To remedy this partly, the application displays a numeric virtual keyboard with keys in random positions for the input of personal identification codes. However, although this measure is useful for preventing the inference of identification codes, it does not prevent malware from inferring that a transaction is in progress and, before the user has finished, modifying the amount or the recipient and simulating the verification (modifying the inputs of the application without modifying the application itself).

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

[0047] The application processor APP PROC of the mobile terminal is integrally connected to various peripheral devices, particularly including a touch screen with 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 clarity, not all elements of the mobile terminal are shown.

[0048] 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 usually 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 parts on the display DISP and the touchpad KBD according to the instructions executed by the application.

[0049] 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 cryptographic asset transactions managed by the blockchain alone. In fact, since a hardware wallet can provide access to very high values in cryptographic assets, the means employed by hackers are commensurate with the values they can extort.

[0050] 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, which has a secure serial peripheral interface (SPI), two I2C interfaces, and various programmable input / output pins GPIO, etc. The link (usually a USB interface or a Bluetooth interface) between the mobile terminal HDV represented by LKK and the separate hardware wallet HW in Figure 1 is implemented herein by 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.

[0051] The implementation of the hardware wallet function in the element eSE and the exchanges 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.

[0052] 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 secure element, and its state change cannot be simulated by software executed on the application processor. Another input / output pin GPIO2 controls the indicator LED to signal that a secure operation is being performed using the hardware wallet in the element eSE. The button B is a dedicated physical button arranged, for example, 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.

[0053] 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 secure 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 secure 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.

[0054] 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 secure element that has completed its task deactivates the indicator LED and waits for a new command. The application updates the blockchain via the network service, displays useful information, and waits for new user interactions.

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

[0056] The button B has a function similar to that of the buttons B1, B2 of the separate hardware wallet of the type shown in Figure 2 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 performed routinely 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 dedicated physical button B managed by the element eSE.

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

[0058] 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 detached hardware wallet.

[0059] Now, as previously indicated, more sophisticated malware can modify the input and / or output data of applications to hijack them. 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 an 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 convey 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 displayed data 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.

[0060] In a conventional detached 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 detached 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 equivalent, given the difficulty of providing a second display and the additional cost this would entail, such functionality is not feasible.

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

[0062] Compared 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.

[0063] 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.

[0064] In another embodiment, the processor PROC2 uses a pointer provided to it to directly display data from the memory FB2 or FB3. The display mechanism is documented and will not be described in more detail. Generally, 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.

[0065] Thus, 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.

[0066] 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.

[0067] 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.

[0068] With this configuration, transactions are prepared in the usual way by an official application (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.

[0069] 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.

[0070] 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 .

[0071] 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.

[0072] 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.

[0073] 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 chip sets 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 display data in MIPI DSI format to the display, which is either the data provided by the application processor or the data provided by the security element.

[0074] 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.

[0075] Specifically, security issues resulting from 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 via a common control bus (such as a bus carrying synchronization signals), such a display controller could also provide a significant attack surface to fraudsters via that control bus.

[0076] 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 this type of attack to be avoided.

[0077] 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, formatted according to the MIPI DSI protocol, generated by the display controller DC3 of the processor APP PROC. Alternatively, these 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 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 either 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.

[0078] The display controller DC4 receives display commands from the element eSE, for example via 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 the basic display commands for the transactions it processes and send them to the display controller.

[0079] 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).

[0080] 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.

[0081] When the application program executed by the processor APP PROC delegates the transaction signature to the element eSE, the latter transfers the transaction data display commands 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.

[0082] 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.

[0083] Of course, it is preferably that any unlocking 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.

[0084] 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 can be 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.

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

[0086] Since the touch screen is taken 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.

[0087] 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 executes the user input phase. Inputs 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.

[0088] 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.

[0089] has been described starting from the Figure 5 structure of the touchpad KBD, 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.

[0090] 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 calculations 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.

[0091] 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 a cryptographic key or other sensitive information is rendered inoperative during a secure transaction.

[0092] 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.

[0093] 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 positions. 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).

[0094] Malware can be designed to initiate a transaction when the element eSE is in a configuration where it does not request an unlock code, such as 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.

[0095] 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 accidentally verify the transaction.

[0096] 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 accidental 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 locked screen of the mobile terminal when verification is requested.

[0097] 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 Figure 6 's 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 the first position and to a high logic level in the second position. The switch S is arranged, for example, on one of the sidewalls of the mobile terminal device.

[0098] 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 (active or safe mode) via the bus SPI in the other position. The terminal is designed such that the switch S is the only component available to switch the mode of the component, which means that the application can no longer delegate the transaction processing itself.

[0099] 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.

[0100] 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.

[0101] 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.

[0102] 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.

[0103] 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.

[0104] 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.

[0105] 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 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 different.

[0106] In any case, pending transactions (whether fraudulent or not) can no longer be verified by accidental presses on physical or virtual buttons, because the user must intentionally switch the mobile terminal to the secure mode to verify the transaction.

[0107] Figure 8 Illustrates according to Figures 4 to 6The component layout of a mobile terminal (smartphone) among the ones here. 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.

[0108] 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 a 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.

[0109] In addition, the display DISP and the touchpad KBD are typically 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.

[0110] 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 to be integrated into a conventional mobile terminal platform. The device DHW can be a system-in-package SiP designed to be mounted on a printed circuit board or form another SoC (SoC2).

[0111] To adapt the device DHW to a 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, and 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.

[0112] 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 connector of the SiP or to a connector offset on the printed circuit board, which are themselves connected to the dedicated pins of the SiP through tracks.

[0113] 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 MIPI DSI format image data.

[0114] 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 a 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 because no adaptation is made at the level of the conventional terminal hardware platform.

[0115] It should be noted that MIPI DSI is currently the most commonly used display interface bus standard between mobile terminal display controllers and 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.

[0116] It will also be obvious to those skilled in the art that, depending on 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 an I2C bus, it is not excluded that the security element may integrate such a display controller DC4 in the future.

[0117] 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.

[0118] Appendix

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

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

Claims

1. An electronic terminal, characterized in that, within the same housing, the electronic terminal comprises: - an application processor (APP PROC), configured to perform at least one transaction via a connection to an Internet network or to a local network, - a secure element (eSE), connected to the application processor via a wired bus (SPI), configured to perform at least one cryptographic calculation required to complete the transaction using a secret held by the secure element upon request of the application processor, and to provide the result of the cryptographic calculation to the application processor, - a transaction verification device (B), operable by a user and specifically accessible by the secure element (eSE), the secure element being configured to perform the cryptographic calculation after the transaction has been verified by the user by means of the transaction verification device, and - a physical bistable switch (S), operable by the user and specifically accessible by the secure element, wherein the secure element is configured to enter an active mode in a first position of the switch, in which the secure element responds to commands received from the application processor via the wired bus (SPI), and to enter an inactive mode in a second position of the switch, in which the secure element does not receive or respond to commands from the application processor.

2. The terminal according to claim 1, wherein: - the application processor is configured to prompt the user to switch the switch (S) to the active mode position when the switch is in the inactive mode position and the secure element has to perform the cryptographic calculation, and - the secure element is configured to prompt the user to switch the switch to the inactive mode position after performing the cryptographic calculation and providing the result of the cryptographic calculation to the application processor.

3. The terminal according to one of claims 1 and 2, the terminal further comprises: - an input device (KBD), controlled by a corresponding bus (I2C), and - a demultiplexer (DMUX), controlled by the secure element (eSE), the secure element being configured to: - connect the input device bus to the application processor when the secure element is in the inactive mode, and - connect the input device bus to the secure element when the secure element is in the active mode.

4. The terminal according to claim 3, wherein in the active mode, the input device (KBD) is a touchpad and the transaction verification device is a virtual button on the touchpad.

5. The terminal according to one of claims 3 to 4, wherein the transaction verification device is a physical button (B).

6. The terminal according to any one of claims 1 to 5, wherein the terminal includes a display device (DISP), and wherein the application processor and the security element are connected to the display device (DISP) by means of a multiplexer (MUX) controlled by the security element, the multiplexer (MUX) including a first input for receiving display data provided by the application processor, a second input for receiving display data provided by the security element, and an output for providing to the display device the display data received on its first input or second input. The security element is configured to control the multiplexer such that: - when the security element is in the inactive mode, the multiplexer provides to the display device the display data provided by the application processor, and - when the security element is in the active mode, the multiplexer provides to the display device the display data provided by the security element.

7. The terminal according to claim 6, wherein the terminal is configured to perform the following steps: - Initialize a transaction using an application executed by the application processor (APP PROC); - In the case where the switch (S) is in the inactive mode position, use the application and a message on the display device (DISP) to prompt the user to switch the switch to the active mode position; - When the switch is switched, transmit a confirmation from the security element to the application; - When the confirmation is received, send information about the transaction from the application to the security element; - Use the security element to display the information related to the transaction, wait for the user to verify the transaction, perform the cryptographic calculations necessary to complete the transaction, and then transmit the result of the cryptographic calculations to the application processor, and - Use the security element to prompt the user to switch the switch to the inactive mode position via a message on the display device (DISP).

8. The terminal according to one of claims 1 to 7, wherein: - The application processor (APP PROC) is integrated in a system-on-chip (SoC) mounted on an interconnect support, and - The security element (eSE) is integrated in a system-in-package (SiP) mounted on the interconnect support.

9. The terminal according to any one of claims 1 to 8, wherein the terminal forms a mobile phone, wherein the security element is configured to form a hardware wallet for encrypting an asset account, and the application processor is configured to execute an application that allows transactions to be performed on the encrypted asset account.

10. A method for integrating a hardware wallet for encrypted assets into a terminal, characterized in that the method includes the following steps: - Assemble an application processor (APP PROC), a secure element (eSE) connected to the application processor via a wired bus (SPI), a transaction verification device (B) operable by a user and specifically accessible by the secure element (eSE), and a physical bistable switch (S) operable by the user and specifically accessible by the secure element in the same housing. - Configure the application processor to execute at least one transaction via a connection to an Internet network or to a local network. - Configure the secure element to, upon request of the application processor and after the user verifies the transaction by means of the transaction verification device, perform at least one cryptographic calculation required to complete the transaction using a secret held by the secure element and provide the result of the cryptographic calculation to the application processor. - Configure the secure element to enter an active mode in the first position of the switch, in which the secure element responds to a command received from the application processor via the wired bus (SPI), and to enter an inactive mode in the second position of the switch, in which the secure element does not receive or respond to commands from the application processor.

11. The method according to claim 10, the method comprises the steps of: - Configure the application processor to prompt the user to switch the switch to the active mode position when the switch (S) is in the inactive mode position and the secure element has to perform the cryptographic calculation. - Configure the secure element to prompt the user to switch the switch to the inactive mode position after performing the cryptographic calculation and providing the result of the cryptographic calculation to the application processor.

12. The method according to one of claims 10 and 11, the method comprises the steps of: - Provide an input device (KBD) controlled by a corresponding bus (I2C). - Provide a demultiplexer (DMUX) controlled by the secure element (eSE). - Configure the secure element such that: - When the secure element is in the inactive mode, the secure element connects the input device bus to the application processor. - When the secure element is in the active mode, the secure element connects the input device bus to the secure element.

13. The method according to one of claims 10 to 12, the method comprises the steps of: - Provide a display device (DISP). - Connect the application processor and the secure element to the display device (DISP) by means of a multiplexer (MUX) controlled by the secure element, the multiplexer (MUX) comprising a first input receiving display data provided by the application processor, a second input receiving display data provided by the secure element, and an output providing the display data received on its first input or second input to the display device. - Configure the security element to control the multiplexer such that: - When the security element is in the inactive mode, provide display data provided by the application processor to the display device, and - When the security element is in the active mode, provide display data provided by the security element to the display device.

Images