Smartphone integrating a hardware wallet for storing cryptographic keys, implementing hardware multiplexing of the smartphone's display.

Abstract

The invention relates to a connected terminal comprising an application processor (APP PROC); an embedded secure element (eSE) connected to the application processor by a secure wired bus (SPI), configured to perform cryptographic calculations, with a secret stored in the secure element, on a transaction initiated by an application running on the application processor; a human-machine interface including a display (DISP) connected by a control bus (MIPI DSI) to the application processor; a transaction validation device (B) actuable by a user and accessible exclusively by the secure element (eSE);and a multiplexer (MUX) controlled by the secure element to: (i) in an idle mode where the secure element is not processing any transactions, connect the display bus so that it is managed by the application processor, and (ii) in an active mode where the secure element is processing a transaction, connect the display bus so that it is managed exclusively by the secure element. Figure for the abstract: Fig. 5;

Description

Title of the invention: Smartphone integrating a hardware wallet for storing cryptographic keys implementing hardware multiplexing of the smartphone display Technical field

[0001] The invention relates to secure portable devices for storing and implementing private cryptographic keys in a manner partitioned from a network ("cold" storage), in particular keys enabling transactions to be carried out on a blockchain. Background

[0002] In recent years, the development of cryptocurrencies or other types of cryptoassets managed by the blockchain, such as non-fungible tokens ("NFTs") and smart contracts, has given rise to various means of storing and preserving the private keys attached to these different types of cryptoassets. This is how the notions of "wallet", "cold storage" and "hot" storage of private keys appeared. A "wallet", also called a "currency holder", is a device or program whose function is to manage cryptoassets, and therefore to store the private keys attached to them. So-called "hot wallets" are connected to the Internet and susceptible to hacker attacks or exposure to viruses and malware. These may be wallets managed by centralized exchange platforms, which do not offer the highest level of security.For example, many centralized platforms have been looted of hundreds of millions of dollars by hackers over the years. Hot wallets can also take the form of programs installed on mobile phones, tablets, or personal computers ("software wallets"). Such wallets are permanently connected to the Internet and integrate many insecure applications, making them themselves susceptible to attack.

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

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

[0005] Hardware wallets are a convenient alternative to passive wallets for storing private keys. They are also typically configured to generate recovery phrases to restore private keys if they are lost. Remember that crypto assets are never stored in a hardware wallet, but are recorded on the blockchain. The hardware wallet only stores the private keys used to manage transactions on the blockchain. The public keys corresponding to the private keys point to an address on the blockchain where the assets are actually located.

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

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

[0008] [Fig.2] shows the architecture of a hardware wallet HW1 of the type marketed by the applicant under the name "Nano S", described in more detail in the document https: / / developers.ledger.com / docs / nano-app / bolos-hardware-architecture / . The HW 1 hardware wallet features an SE1 secure element combined with a micro MCU1 controller. The MCU1 processor has a USB interface U1 and acts as a proxy device for the SE1 secure element, for communication with an external host device HDV running companion software (see [Fig.l]). The SE1 secure element has its own secure OS operating system (firmware) allowing it to execute programs, and integrates a CRY cryptographic coprocessor. The HW1 hardware wallet also has a DISP1 display and two buttons Bl, B2 managed by the MCUL microcontroller. These two buttons play an important role in securing certain operations: the user must press both buttons at the same time to express his agreement or consent for the performance or completion of these operations.

[0009] Hardware wallets as described above are generally detached portable devices that are temporarily connected to a "connected" host device, such as a mobile terminal or smartphone, when making a transaction. The detached nature of these hardware wallets offers a higher degree of security because they are most of the time inaccessible via public networks, and therefore less exposed to attacks. However, this characteristic makes these hardware wallets not very ergonomic and likely to be misplaced or forgotten.

[0010] Blockchain smartphones are known, which are designed to securely store certain virtual assets such as cryptocurrencies and have an internal storage space inaccessible via the Internet to constitute a cold wallet: the Galaxy S10 model from Samsung®, the Exodus 1 model from HTC®, or the Finney model from Sirin Labs®. These smartphones are equipped with an embedded secure element (designated by eSE for "Embedded Secure Element") which is a chip specially designed to store sensitive data and share it only with authorized applications and people.

[0011] When it comes to cryptocurrency, a very high degree of security is required. The blockchain smartphones discussed above offer a certain degree of security through the use of a secure enclave or Trusted Execution Environment (TEE), but the function of a digital hardware wallet, which is not the primary function of such a phone, requires more. Indeed, implementing a hardware wallet inside a smartphone partly eliminates the security advantages of a detached hardware wallet that is connected only when needed. This inevitably increases the wallet's exposure to attacks over the Internet. Summary

[0012] A connected terminal is generally provided comprising an application processor; an embedded secure element connected to the application processor by a secure wired bus, configured to perform cryptographic calculations, with a secret stored in the secure element, on a transaction initiated by an application executed on the application processor; a human-machine interface including a display connected by a control bus to the application processor; a transaction validation device operable by a user and accessible exclusively by the secure element; and a multiplexer controlled by the secure element for: in an inactive mode where the secure element is not processing a transaction, connecting the display bus so that it is managed by the application processor, and in an active mode where the secure element is processing a transaction, connecting the display bus so that it is managed exclusively by the secure element.

[0013] The terminal may further comprise a display manager configured to receive display commands exclusively from the secure element and convert them into information compatible with the display bus, and connected by the multiplexer to the display bus in the active mode.

[0014] The human-machine interface may further include an input device controlled by a corresponding bus, the terminal further comprising a demultiplexer controlled by the secure element for: in the inactive mode, connecting the bus of the input device so that it is managed by the application processor, and in the active mode, connecting the bus of the input device so that it is exclusively managed by the secure element.

[0015] The input device may be a touch screen and the transaction validation device a virtual button on the touch screen in the active mode.

[0016] The transaction validation device may be a physical button.

[0017] The terminal may further comprise a bistable physical switch actuable by the user and accessible exclusively by the secure element, configured to, in a first position, switch the secure element to active mode and, in a second position, switch the secure element to inactive mode; and means for requesting the user to actuate the switch.

[0018] The secure element can be configured to, in active mode, inhibit circuits capable of measuring parameters of the terminal to deduce sensitive information.

[0019] The terminal may further comprise a dedicated indicator perceptible by the user, controlled exclusively by the secure element to be activated during the active mode and deactivated during the inactive mode.

[0020] A method for validating and signing a transaction on the blockchain using a terminal of the aforementioned type is also provided, comprising the following steps: the switch being in the inactive mode position, requesting by the application using a message on the display that the user switches the switch to the active mode position; when the switch switches, sending by the secure element an acknowledgment to the application; upon receipt of the acknowledgment, transmitting transaction information to the secure element by the application; in the secure element, managing the display, validation and signing of the transaction, and sending the result to the application; and requesting by the secure element using a message on the display that the user switches the switch to the inactive mode position.

[0021] The application processor may be integrated into a system-on-chip mounted on an interconnect carrier; the touchscreen is then connected to the interconnect carrier; and the secure element, the multiplexer, and the demultiplexer are integrated into a system-in-package mounted on the interconnect carrier. Summary description of the drawings

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

[0023] [Fig.l] illustrates typical examples of using a hardware wallet through a host device;

[0024] [Fig.2] illustrates a classic hardware wallet architecture;

[0025] [Fig. 3] represents a partial block diagram of a first embodiment of mobile terminal or other connected device incorporating a hardware wallet;

[0026] [Fig.4] represents a block diagram of a first terminal embodiment connected, thwarting a first type of fraud which could target a terminal of the type shown in [Fig.3];

[0027] [Fig.5] represents a block diagram of a second terminal embodiment connected, defeating the first type of fraud that could target a terminal of the type shown in [Fig.3];

[0028] [Fig.6] represents a block diagram of an embodiment of a connected terminal thwarting a second type of fraud targeting a terminal of the type shown in [Fig.5];

[0029] [Fig.7] represents a block diagram of an embodiment of a connected terminal in which the use of an embedded secure element is under the control of the user; and

[0030] [Fig.8] illustrates an arrangement of components of a mobile terminal connected according to one of figures 4 to 6. Detailed description

[0031] In the present application, the aim is to embed a hardware wallet in a connected terminal (smartphone or other connected device) while avoiding attacks made possible given this configuration. In order not to create an entirely new ecosystem and not to harm the user experience, compatibility with existing hardware and operating systems is also sought. (Android, iOS), and to use traditional application distribution channels. Such mobile devices can therefore install and run applications that may come from unknown or even dubious sources, which increases the challenge of securing transactions with the embedded hardware wallet.

[0032] It is therefore assumed that installable applications can gain access to hardware resources occurring during communication with a secure element implementing the hardware wallet.

[0033] In general, official applications of relevant services, particularly financial services (banks, cryptocurrencies), are certified and signed and are more complicated to modify by malicious code. When they are loaded for execution, signature verification fails if they have been modified. On the other hand, malware can infer certain interactions of the official application with the hardware and modify the inputs and outputs of the official application.

[0034] For example, it is possible for the malware to record keystrokes to steal a secret code, simulate keystrokes to falsify a transaction, modify the display to deceive the user about the transaction he is carrying out, etc.

[0035] More specifically, the validation of a transaction on a telephone by a virtual keyboard can be intercepted by low-level spyware having access to the touchscreen interface by recording the coordinates of the presses on the touchscreen. Without knowing what is displayed, the spyware can assume that the virtual keyboard displayed is one of the many traditional keyboards available on the platform, so that the coordinates of the presses reveal the keys on the keyboard. The spyware can also have access to accelerometers or other sensors usually present in a mobile terminal - presses on different positions of the screen result in different acceleration values ​​in rotation on two axes, so that the positions of the presses can be deduced.

[0036] To partially address this, applications display a numeric virtual keyboard with randomly positioned keys for entering personal identification codes. However, although this measure is useful for hindering the deduction of an identification code, it does not prevent malware from deducing that a transaction is in progress and, before the user has finished, modifying the amount or recipient and simulating validation (modifications of application inputs without modifying the application itself).

[0037] [Fig. 3] represents a partial block diagram of a first embodiment of a mobile terminal or other connected device incorporating a hardware wallet.

[0038] A mobile terminal traditionally integrates an application processor APP PROC connected to various peripheral devices, in particular a touch screen including a DISP display and a KBD touchscreen. The processor manages the display via a dedicated interface, often MIPI DSI. The processor manages the touchscreen via another interface, usually I2C. For clarity, not all elements of a mobile terminal are shown.

[0039] When the mobile terminal is designed to perform secure transactions, as most mobile terminals do today, the application processor generally integrates a secure enclave or a trusted execution environment TEE ("Trusted Execution Environment"). Such an enclave generally comprises a dedicated processor, memory and touch screen manager and is designed to implement a trusted user interface TUI ("Trusted User Interface"), for example as recommended in the document "Trusted User Interface API" from GlobalPlatform® (https: / / globalplatform.org / wp-content / uploads / 2013 / 06 / GlobalPlatform_Trusted_User _Interface_API_vLO.pdf). Thus, this enclave can, depending on the instructions executed by the application, manage the display DISP and input on the KBD touch screen, as shown.

[0040] Such an enclave is distinct from a secure element usually used in hardware wallets, and does not provide a sufficient degree of security on its own for transactions involving cryptoassets managed by the blockchain. Indeed, since hardware wallets can provide access to very high values ​​in cryptoassets, the means implemented by hackers are commensurate with the sums they can extort.

[0041] According to the embodiments described here, the mobile terminal further includes an embedded secure element eSE implementing a hardware wallet. The eSE element may be similar to that integrated in the detached hardware wallets previously described. It may be the ST33 microcontroller from STMicroelectronics® which has, among other things, a secure SPI interface ("Serial Peripheral Interface"), two I2C interfaces and various programmable input / output pins GPIO. The link designated by LNK in [Fig. 1] between the mobile terminal HDV and the detached hardware wallet HW, generally a USB or Bluetooth interface, is here achieved by a permanent wired link between the secure element eSE and the application processor via the SPI interface. To ensure better communication security, the link may be managed by the TEE enclave, as shown.

[0042] The implementation of the hardware wallet function in the eSE element and the exchanges between the eSE element and the application processor may be in all respects similar to what is known from Figures 1 and 2 and will not be described in further detail.

[0043] Furthermore, one of the input / output pins GPIO1 is connected to a physical button B intended to validate transactions by a mechanical operation. The GPIO1 pin is exclusively managed by the secure element and its change of state is impossible to simulated by software running on the application processor. Another input / output pin GPI02 controls an LED indicator to signal that a secure transaction is in progress with the hardware wallet in the eSE element. Button B is a dedicated physical button arranged, for example, on a side wall of the mobile terminal, which is visually distinguished from other buttons usually provided on the mobile terminal. The LED indicator is also dedicated and conspicuous compared to other light indicators usually provided on the mobile terminal.

[0044] 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 must validate the transaction, the application goes through the TEE enclave to display the transaction on the DISP display and, if necessary, manage an input phase on the KBD touch screen, such as entering an identification code to unlock the secure element. The validation and signing of the transaction are delegated to the eSE secure element (the hardware wallet) by commands issued on the SPI bus via the TEE enclave. If necessary, the entry of the unlocking code is transmitted to the secure element by the SPI bus. The eSE secure element reacts to these commands by activating the LED indicator and waiting for a press on the B button.

[0045] When button B is pressed, the secure element eSE calculates the transaction signature with the private keys stored in the wallet and transmits the signature to the application via the SPI bus. The secure element, having completed its task, deactivates the LED indicator and waits for new commands. The application updates the blockchain through a network service, displays the useful information, and waits for further interaction with the user.

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

[0047] Button B has a function similar to that of buttons B1, B2 of a detached hardware wallet of the type in [Fig.2]. Malware, if it manages to modify the amount or address of the transaction, will not be able to simulate a validation, which requires the actuation of a physical button detectable only by the eSE secure element. Thus, the user, before validating, will be able to confirm that the transaction as displayed is indeed the one he initiated. If the transaction has been modified, the user can in principle see this on the display and cancel the transaction. Cancellation can be carried out conventionally by pressing a virtual button on the touch screen. The function of the cancellation button cannot be diverted into a validation function, since validation is only possible using the physical button B managed exclusively by the eSE secure element.

[0048] The LED indicator reassures the user that the secure element is taking over operations and that, in principle, the requests made to it are from a trusted source.

[0049] According to a slightly more expensive variant in terms of manufacturing the mobile terminal housing, two physical buttons can be provided which must be pressed simultaneously to validate a transaction, as is done with detached hardware wallets.

[0050] Now, more sophisticated malware, as previously indicated, can modify the application's input and / or output data to divert them. For example, the software can intercept transaction data entered into the application to replace it (such as the amount and address). Although this is difficult when the entry is made in secure mode using the TEE enclave, it is not impossible given the degree of security offered by a conventional TEE enclave. The application then generates a transaction with this modified data for the eSE secure element and a corresponding display. The display, which then betrays the modification, can also be intercepted and modified, although this is difficult, to correspond to the transaction initially intended by the user.So the user will see apparently correct transaction data on the display and validate the transaction, but this validation then operates on the modified fraudulent transaction that has been surreptitiously delegated to the eSE secure element.

[0051] In a conventional detached hardware wallet, this type of fraud is thwarted by the fact that the wallet reproduces the transaction on its own display: the user relies on the transaction displayed by the detached wallet, and can compare it to that displayed by the application on the terminal. Such functionality is not possible when the hardware wallet is embedded in a smartphone, given the difficulty of providing a second screen and the additional cost.

[0052] [Fig.4] is a block diagram of a first embodiment of a mobile terminal integrating a hardware wallet and thwarting this type of display manipulation.

[0053] Compared to [Fig.3], the application processor APP PROC is integrated in a system-on-chip SoC also integrating a secondary processor PROC2. The SoC can be the i.MX 8M Plus circuit from NXP®. The processor PROC2 has its own display manager and can be considered as having a high degree of security because it is partitioned from the other circuits of the SoC, similar to a secure element. Like a secure element, the processor PROC2 can receive a set of commands from the TEE enclave via an SPI bus. The display manager of the processor PROC2 is the sole master of the MIPI DSI bus of the display and includes an FBI frame memory that the processor PROC2 can fill from a memory from an application processor FB2 frame memory, from an FB3 frame memory in the TEE enclave (CPY arrows), or from internally generated display data, as needed. In another mode, the PROC2 processor can directly display data from FB2 or FB3 memory from a pointer provided to it. The display mechanisms are documented and will not be described in further detail. Thus, depending on the needs of a running application, the DISP display receives its data from the application processor, from the TEE enclave, or from the PROC2 secondary processor itself.

[0054] One objective of this type of SoC is to overcome recognized potential flaws in a display managed by the TEE enclave.

[0055] In this embodiment, the secure element eSE is further connected by the SPI bus to the processor PROC2, with the aim of managing the display according to the methods set out below. The KBD touch screen can still be managed by the TEE enclave to carry out secure input.

[0056] With this configuration, a transaction is prepared in the usual way by an official application, such as "Ledger Live", running on the application processor. From the moment the user must validate the transaction, the application preferably uses the TEE enclave if an unlock code entry is required and delegates the processing of the transaction to the secure element via the SPI bus.

[0057] As for the display of the transaction before validation, the display data produced by the application can, as in [Fig.3], be transmitted to the display manager of the TEE enclave, which fills the frame memory FB3 of the enclave with the corresponding graphic data, but they could also be transmitted to the display manager of the application processor and the frame memory FB2. Regardless, this data will not be displayed.

[0058] At the same time, the secure element eSE, having received the transaction data, transmits display data via the SPI bus to the processor PROC2 so that it displays them via its display manager FBI in place of the data which would be present in the frame memories FB2 and FB3.

[0059] If by chance the transaction display data produced by the application is compromised, this data is found in the frame memory FB2 or FB3, but it is ignored, because it is the data produced by the secure element in the frame memory FBI which is actually displayed.

[0060] The architecture of [Fig.4] requires the use of a system-on-chip integrating a particular set of processor cores, which may not be suitable for certain smartphone manufacturers.

[0061] [Fig.5] is a block diagram of a second embodiment of a mobile terminal integrating a hardware wallet, preventing manipulation of the display, and offering a solution compatible with a multitude of chipsets available for smartphones. Compared to [Fig.3], the MIPI DSI bus of the DISP display is connected to the output of a switch in the form of a multiplexer MUX. This multiplexer receives on a first input the display data produced by the application processor APP PROC. This display data no longer needs to be managed by the TEE enclave, as shown. A second input of the multiplexer receives display data generated by a display manager DISP CTRL managed exclusively by the secure element eSE. An input / output terminal GPI03 of the secure element eSE is programmed to operate the SEL selection of the multiplexer. The SEL signal could also be taken from the terminal GPI02 which controls the LED indicator.

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

[0063] The DISP CTRL display manager is a separate circuit here, because the chips of commonly available secure elements do not have it or do not have sufficient bandwidth to generate the matrix images expected on the bus of a display such as that of a modern smartphone.

[0064] While waiting for a transaction, the secure element eSE commands the multiplexer MUX to send the display data from the processor to the display.

[0065] When an application delegates a transaction to the secure element eSE, the latter sends the display commands corresponding to the transaction to the display manager DISP CTRL and switches the multiplexer MUX so that the data produced by this display manager reaches the display DISP. The LED indicator is activated and the secure element eSE waits for validation by button B.

[0066] With this configuration, the DISP display shows the transaction data actually received by the eSE secure element. If they have been modified compared to the initial request, the user will see this and can cancel the transaction.

[0067] It is of course preferable that any entries of unlocking codes or other sensitive information used for managing the eSE secure element have a degree of security at least at the same level as the display.

[0068] [Fig. 6] is a block diagram of an embodiment of a mobile terminal using the secure element eSE instead of a TEE enclave to manage the KBD touch screen, and raising the degree of security to that of a secure element. Compared to [Fig. 5], the output I2C bus of the KBD touch screen is connected to a switch in the form of a DMUX demultiplexer, a first output of which is connected to the processor application interface APP PROC and a second output is connected to the I2C interface of the secure element eSE. The selection of the demultiplexer DMUX can be operated by the same SEL signal as the multiplexer MUX. In this structure, the physical validation button B is optional, as will be understood below. In addition, the TEE enclave is no longer required and is no longer represented.

[0069] While waiting for a transaction to be processed, the secure element eSE positions the multiplexer MUX and the demultiplexer DMUX to connect the display DISP and the touch screen KBD to the application processor, in a traditional configuration.

[0070] Since the touch keyboard escapes the control of the application during delegation to the secure element, the application can no longer implement the input phase. Thus, the input phase is also delegated to the secure element, which is for the occasion programmed to manage a virtual keyboard for input and display.

[0071] When a transaction is delegated by the application to the secure element via the SPI bus, without this time passing through the TEE enclave, the secure element eSE switches the multiplexer and the demultiplexer to connect the display DISP and the touch screen KBD respectively to the display manager DISP CTRL and to the secure element eSE. The secure element eSE implements the input phase, if an input is required (provision of an unlocking code). The input on the touch screen can no longer be intercepted or modified by software running on the application processor, while any attempt to modify the display by software running on the application processor is ignored.

[0072] Given this configuration, software running on the application processor cannot simulate false validations on the touchpad, so that the physical button B is optional; validation can be done safely using the touchpad.

[0073] The securing of the KBD touch screen has been described starting from the structure of [Fig.5], but it is applicable to the structure of [Fig.4] where in secure mode, the management of the touch screen is switched to the secure element instead of the TEE enclave.

[0074] According to one embodiment, the SEL signal, or any other indicator of the secure mode (such as the LED indicator control signal), is used to inhibit circuits that are normally unused during the secure mode. The SEL signal is connected, for example, to an INHIB terminal used to stop the application processor. A stop can be achieved by activating a reset input of the processor, by cutting off its clock signal, or by cutting off its power supply. In this case, any malicious software running on the application processor performing analyses to deduce cryptographic keys or other sensitive information is rendered inoperative during the secure transaction.

[0075] Total inactivation of the application processor is possible in the configuration of [Fig.6], where all functions that must remain active during the transaction are transferred to the secure element eSE. In cases where the application processor cannot be deactivated, the SEL signal can be used to deactivate additional circuits that can be used to deduce sensitive information, such as accelerometers used to deduce the positions of presses on the touch screen. Accelerometers are generally integrated into a dedicated inertial measurement unit or IMU ("Inertial Measurement Unit") circuit. Such an inertial measurement unit can be deactivated and stopped its clock, by cutting its power supply or by cutting its communication link with the application processor, generally an I2C bus.

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

[0077] If the fraudulent transaction is initiated at a time when the user has his mobile terminal in view, he sees, without having requested it, the mobile terminal switch to secure mode (LED indicator), display the transaction and request its validation. The user will be able to check the display and cancel the transaction, but this requires the user to be attentive and not validate the transaction by mistake.

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

[0079] [Fig.7] is a block diagram of an embodiment of a mobile terminal that thwarts this type of fraud. The aim here is to simulate, as it were, the operation of attachment and detachment of a conventional detached wallet. In addition to the elements of [Fig.6], a physical bistable switch S is connected to connect an input / output pin GPIO4 of the secure element eSE to a low logic level in a first position, and at 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.

[0080] The secure element eSE is programmed to be silent to commands received by the SPI bus (inactive mode) in one of the positions of the switch S, for example in the first position, and to accept transactions by the SPI bus (active or secure mode) in the other position. The terminal is designed so that the switch S is the only means available for switching the mode of the secure element, that is to say that an application can no longer delegate the processing of a transaction on its own.

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

[0082] With the switch S initially in the inactive mode position, an application capable of initiating transactions is then designed to request the user to change mode when it is about to delegate the processing of the transaction to the secure element eSE. It can send to the display DISP a message of the type "Please place the telephone in secure mode using the switch", preferably with information relating to the transaction in progress. This message is analogous to a message inviting the user to connect his conventional detached wallet to the mobile terminal.

[0083] The user then toggles the switch to active mode. The secure element eSE reacts by taking various protective measures, such as toggling the SEL signal to connect the DISP display and the KBD touch screen respectively to the dedicated display manager DISP CTRL and to the secure element eSE. The LED indicator is also activated to signal to the user that the mobile terminal is in secure mode. The secure element eSE sends an acknowledgment to the application which resumes execution by transmitting the transaction information to the secure element. The secure element eSE performs the input phase on the KBD touch screen, if applicable, and requests validation from the user by displaying the transaction information again.

[0084] When the transaction is validated and signed, the eSE secure element communicates the signed transaction to the application which writes it to the blockchain. The secure element requests the user to change mode, by sending to the DISP display a message of the type "Please exit secure mode by toggling the switch". This message is analogous to the one indicating that the user can remove their classic detached wallet. When the switch is toggled, the initial connections of the display and the touch screen are reestablished, and the LED indicator is deactivated.

[0085] The switch S can also be implemented in the structures of Figures 4 and 5, where the KBD touch screen is not connected to the secure element. In this case, it is the application which carries out the input phase before requesting the switching of the switch. mutator S.

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

[0087] Malware could also behave like an official application by requesting the mode switch. However, since the user did not initiate the transaction and is being asked for a relatively restrictive action, it is likely to be more vigilant. The malware can no longer display an irrelevant misleading message in this context, since the user expects to see transaction information. Such transaction information will be difficult to make credible, especially if it is real - typically a transfer of a large amount to an unknown address. If the malware attempts to hide the nature of the transaction, it will be revealed and different at the time it is displayed for validation by the eSE secure element, if the user has nevertheless been prompted to switch to secure mode.

[0088] In any case, a pending transaction, whether fraudulent or not, can no longer be validated by accidentally pressing a physical or virtual button, because the user must intentionally switch the mobile terminal to secure mode to validate the transaction.

[0089] [Fig. 8] illustrates an arrangement of components of a mobile terminal (smartphone) according to one of figures 4 to 7. The application processor APP PROC and its enclave TEE can be part of a system-on-chip SoC ("System-on-Chip"). The SoC has pins soldered to respective tracks of a printed circuit or other interconnection support receiving a certain number of other components. Respective groups of pins are associated with the different communication links between the components, in particular the MIPI DSI, SPI and I2C buses previously mentioned.

[0090] The DISP display and the KBD touch screen are generally remote and parallel to the printed circuit. Their control buses are then connected to the printed circuit by connectors soldered onto tracks on the printed circuit.

[0091] The various elements set out above for implementing an embedded hardware portfolio, selected from the eSE, DISP CTRL, MUX, DMUX elements, and connectors for the B, S and LED elements, depending on the embodiments, can be integrated into a system-in-package (SiP) designed to be mounted on a printed circuit, or in another SoC.

[0092] To adapt a conventional mobile terminal to the integration of a hardware wallet embedded, we arrange a place on the printed circuit to solder the SiP, we redraw the tracks of the different buses used by interrupting them so that they pass through the SiP, and we bring tracks to establish the secure SIP link between the APP PROC processor and the secure element eSE.

[0093] The various discrete physical elements managed by the SiP circuits (button B, switch S, LED indicator) can be fixed on the terminal housing and connected to connectors on the SiP, or to connectors located on the printed circuit, themselves connected by tracks to dedicated pins on the SiP.

[0094] With this configuration, a conventional mobile terminal can be transformed into a mobile terminal with an embedded hardware wallet by simply adding a SiP on a printed circuit carrying the components of the conventional terminal. Although the design of the adapted printed circuit represents a certain development and production cost, this cost remains negligible because there is no adaptation to be made at the level of the hardware platform of the conventional terminal.

[0095] The above description has been made essentially in the context of smartphones incorporating a hardware wallet for signing transactions on the blockchain (“blockchain smartphones”). The principles described apply, however, to any type of connected terminal (to the Internet or to a local network) storing secrets used for various uses involving cryptographic calculations, such as the signing of transactions in general and authentication, including “zero knowledge” authentication. In other types of connected terminals, the human-machine interface may be a display associated with a physical keyboard, or with a joystick.

Claims

Claims

1. Connected terminal comprising: an application processor (APP PROC) connected to a display control bus (MIPI DSI), and a human-machine interface including a display (DISP) connected to the display control bus (MIPI DSI); characterized in that it comprises: - an integrated device in the form of a system-in-package (SiP) or a system-on-chip (SoC), mounted on an interconnection support of the terminal, the integrated device comprising: - an embedded secure element (eSE) connected to the application processor by a secure wired bus (SPI), configured to perform cryptographic calculations with a secret stored in the secure element, on a transaction initiated by an application executed on the application processor; - a multiplexer (MUX) having a first input connected to the application processor via display control bus (MIPI DSI), an output connected to the display (DISP) via display control bus (MIPI DSI), - a display manager (DISP CTRL) of the secure element, connected to a second input of the multiplexer (MUX), configured to receive display commands exclusively from the secure element (eSE) and convert them into information compatible with the display control bus (MIPI DSI), the multiplexer (MUX) being controlled by the secure element, the secure element being configured to: in an inactive mode where the secure element is not processing a transaction, connecting the display to the application processor so that it is managed by the application processor, and in an active mode where the secure element is processing a transaction, connecting the display to the display manager (DISP CTRL) of the secure element so that it is exclusively managed by the secure element, and - a transaction validation device (B) operable by a user and accessible exclusively by the secure element (eSE).

2. Terminal according to claim 1, wherein the human-machine interface further includes an input device (KBD) controlled by a corresponding bus (I2C), the terminal further comprising: a demultiplexer (DMUX) controlled by the secure element (eSE) for: in the inactive mode, connecting the input device bus to be managed by the application processor, and in the active mode, connecting the input device bus to be exclusively managed by the secure element.

3. Terminal according to claim 2, in which the input device (KBD) is a touch screen and the transaction validation device is a virtual button on the touch screen in the active mode.

4. Terminal according to claim 1, wherein the transaction validation device is a physical button (B).

5. Terminal according to claim 1, further comprising: a bistable physical switch (S) actuable by the user and accessible exclusively by the secure element (eSE), configured to, in a first position, switch the secure element to active mode and, in a second position, switch the secure element to inactive mode; and means (DISP) for requesting the user to actuate the switch.

6. Terminal according to claim 1, in which the secure element is configured to, in active mode, inhibit (INHIB) circuits capable of measuring parameters of the terminal to deduce sensitive information.

7. Terminal according to claim 1, further comprising a dedicated indicator (LED) perceptible by the user, controlled exclusively by the secure element to be activated during the active mode and deactivated during the inactive mode.

8. Method for validating and signing a transaction on the blockchain using a terminal according to claim 5, comprising the following steps: the switch (S) being in the inactive mode position, requesting by the application using a message on the display (DISP) that the user switches the switch to the active mode position; upon switching the switch, sending an acknowledgment to the application by the secure element; upon receiving the acknowledgment, transmitting transaction information to the secure element by the application; in the secure element, managing the display, validation and signing of

9. the transaction, and send the result to the application; and request by the secure element using a message on the display (DISP) that the user toggles the switch to the inactive mode position. Mobile terminal according to claim 1, wherein: the application processor (APP PROC) is integrated in a second system-on-chip (SoC) mounted on the interconnection support; and the touch screen (DISP, KBD) is connected to the interconnection support.

Images