FR 3140458 A1 20240405 FR 2304933 A 20230517 Procédé pour conduire une opération sécurisée au moyen d'un terminal connecté (SPH6) comprenant un processeur d'application (APROC), un élément sécurisé (eSE) configuré pour réaliser l'opération au moyen d'une clé privée, et un afficheur (DISP) recevant du processeur d'application des images non sécurisées relatives au déroulement de l'opération sécurisée. Le procédé comprend une étape consistant à incruster, dans au moins une image non sécurisée fournie par le processeur d'application et présentée sur l'afficheur, une image sécurisée fournie par l'élément sécurisé et non accessible au processeur d'application, l'image sécurisée comprenant des informations sur l'opération sécurisée et s'étendant dans au moins une région (10) déterminée de l'afficheur. Fig. 8 Terminal connecté comprenant des moyens pour incruster une image sécurisée dans une image non sécurisée. La présente invention concerne l'intégration d'une fonction sécurisée dans un terminal connecté tel un smartphone, et notamment l'intégration d'une fonction de portefeuille matériel de cryptoactifs. La présente invention concerne également le contrôle d'informations présentées à un utilisateur sur un écran du terminal pendant la réalisation d'une opération sécurisée. Arrière-plan Ces dernières années, le développement des cryptomonnaies ou autres types de cryptoactifs gérés par la blockchain, tels que les jetons non fongibles (« NFT ») et les contrats intelligents ("Smart Contracts"), a donné naissance à divers moyens de stockage et de conservation des clés privées attachées à ces différents types de cryptoactifs. C’est ainsi que sont apparues les notions de "portefeuille", de "stockage à froid" et de stockage "à chaud" de clés privées. Un "portefeuille", appelé aussi "porte-monnaie", est un appareil ou un programme dont la fonction est de gérer des cryptoactifs, et donc de stocker les clés privées qui y sont attachées. Les portefeuilles dits "chauds" ("hot wallets") sont connectés à Internet et susceptibles d’attaques de pirates ou d’exposition à des virus et malwares. Il peut s’agir de portefeuilles gérés par des plateformes d’échange centralisé, qui n’offrent pas le plus haut niveau de sécurité. Les portefeuilles "chauds" peuvent aussi prendre la forme de programmes installés sur des téléphones mobiles, tablettes ou ordinateurs personnels ("software wallets"). De tels portefeuilles sont en permanence connectés à Internet et intègrent de nombreuses applications non sécurisées, donc eux-mêmes susceptibles d’attaques. Les portefeuilles froids ("cold wallets") constituent la solution la plus sûre pour le stockage à froid ("cold storage") de clés privées, c'est-à-dire hors de tout accès direct à Internet, ce qui réduit la surface d'attaque et donc le risque de vol par piratage informatique. Les transactions mettant en jeu des clés privées sont signées dans un environnement hors ligne. Toute transaction initiée en ligne est temporairement transférée vers le portefeuille matériel hors ligne, où elle est ensuite signée numériquement avant d'être transmise au réseau en ligne. Comme la clé privée n’est pas communiquée au serveur en ligne pendant le processus de signature, un pirate informatique ne peut pas y accéder. Les portefeuilles ou portes-monnaies matériels appelés "hardware wallets" constituent une alternative pratique aux portefeuilles passifs pour stocker des clés privées. De plus, ils sont généralement configurés pour générer des phrases de récupération ("recovery phrases") permettant de restaurer les clés privées s’ils sont perdus. Rappelons que les cryptoactifs ne sont jamais stockés dans un portefeuille matériel, mais se trouvent enregistrés sur la blockchain. Un portefeuille matériel ne fait que stocker les clés privées permettant de gérer les transactions sur la blockchain. Les clés publiques correspondant aux clés privées pointent vers une adresse sur la blockchain où se trouvent réellement les actifs. Comme montré sur la , un portefeuille matériel HW n’est jamais directement connecté à Internet. Pour être utilisable, le portefeuille matériel HW doit être relié à un dispositif hôte HDV au moyen d’une liaison de données LNK, par exemple USB ou Bluetooth. Le dispositif hôte HDV peut être un ordinateur, un téléphone mobile ou une tablette, et exécute un logiciel dit "compagnon" permettant de conduire des transactions sur la blockchain BCN, tel que le logiciel "Ledger Live" développé par la demanderesse. Alternativement, le portefeuille matériel HW peut être utilisé, par l'intermédiaire du dispositif hôte HDV avec des plateformes d’échange décentralisées ou "DEX", sur lesquelles l’utilisateur peut réaliser des transactions tout en conservant ses clés dans le portefeuille matériel. Les portefeuilles matériels commercialisés par la demanderesse ont connu un important succès commercial en raison du haut degré de sécurité qu’ils offrent, grâce à l’utilisation d’un élément sécurisé ou "secure element" pour conserver les clés privées et signer les transactions. Un élément sécurisé est une plate-forme matérielle capable de stocker et de manipuler des données en conformité avec les règles et les exigences de sécurité fixées par une autorité de confiance. Il se présente sous la forme d’une puce de semi-conducteur mettant en œuvre diverses contre-mesures visant à contrer des attaques de fraudeurs. La montre l’architecture d’un portefeuille matériel HW1 du type commercialisé par la demanderesse sous l’appellation "Nano S". Le portefeuille matériel HW1 comporte un élément sécurisé SE1 associé à un microcontrôleur MCU1. Le microcontrôleur MCU1 comporte une interface USB U1 et agit comme un dispositif mandataire (proxy) à l’égard de l’élément sécurisé SE1, pour la communication avec un dispositif hôte externe HDV exécutant un logiciel compagnon (Cf. ). L’élément sécurisé SE1 possède son propre système d’exploitation OS sécurisé (micrologiciel) lui permettant d’exécuter des programmes APP, et intègre un coprocesseur cryptographique CRY. Le portefeuille matériel HW1 comporte également un afficheur DISP1 et deux boutons B1, B2 gérés par le microcontrôleur MCU1. L’utilisateur doit appuyer en même temps sur les deux boutons afin de manifester son accord ou consentement pour la réalisation ou la finalisation de ces opérations. Les portefeuilles matériels du type qui vient d'être décrit sont dépourvus de connectivité Internet et doivent être couplés à un dispositif hôte comme un terminal mobile ou smartphone au moment d'effectuer une transaction. Ils offrent un haut degré de sécurité du fait qu'ils sont la plupart du temps inaccessibles via les réseaux publics et donc peu exposés aux attaques. Cependant, cette caractéristique les rend peu ergonomiques et susceptibles d'égarement ou d'oubli. On a ainsi proposé des smartphones dits "blockchain" qui, tout en offrant les fonctionnalités habituelles d'un téléphone mobile, intègrent une fonctionnalité de portefeuille matériel de cryptomonnaies. tels le modèle Galaxy S10 de Samsung®, le modèle Exodus 1 de HTC®, ou le modèle Finney de Sirin Labs®. De tels smartphones sont communément appelés "smartphones blockchain" ou "crypto-smartphones". A l'instar des portefeuilles matériels, de tels smartphones sont équipés d’un élément sécurisé embarqué et d'un espace de stockage interne inaccessible par l’Internet, permettant de constituer un portefeuille de cryptomonnaies. Dans d'autres réalisations, le processeur principal dispose d'une enclave sécurisée ou environnement d'exécution de confiance TEE ("Trusted Execution Environment") en lieu et place de l'élément sécurisé. Malgré ces précautions, la mise en œuvre d'un portefeuille matériel à l'intérieur d'un smartphone augmente inévitablement l'exposition du portefeuille aux attaques par Internet, et n'offre pas les mêmes avantages en termes de sécurité qu'un véritable portefeuille froid. Par ailleurs, il n'est pas possible pour l'utilisateur de savoir de façon sûre si des données affichées sont fiables, car elles pourraient être fournies par un programme malveillant. Il pourrait donc être souhaité d'améliorer la sécurité offerte par les terminaux portatifs connectés de type smartphone intégrant un portefeuille matériel de cryptomonnaies. Résumé Des modes de réalisations concernent un terminal connecté configuré pour exécuter une opération sécurisée, le terminal comprenant un processeur d'application configuré pour initier l'opération sécurisée, un élément sécurisé pour exécuter l'opération sécurisée, et un afficheur accessible par l'intermédiaire d'un bus câblé et recevant du processeur d'application des données d'image à afficher à l'attention d'un utilisateur, le terminal comprenant des moyens contrôlés par l'élément sécurisé et configurés pour, à la demande de l'élément sécurisé et au moins pendant l'exécution de l'opération sécurisée, appliquer alternativement sur le bus câblé de l'afficheur des données d'image fournies par le processeur d'application et des données d'image fournies par l'élément sécurisé, de manière à ce que les données d'image fournies par l'élément sécurisé remplacent des données d'image fournies par le processeur d'application et forment une image sécurisée incrustée dans une image non sécurisée fournie par le processeur d'application, l'image sécurisée s'étendant dans au moins une région déterminée de l'afficheur. Selon un mode de réalisation, le terminal comprend au moins un indicateur lumineux activé par l'élément sécurisé lorsque l'élément sécurisé incruste une image sécurisée dans une image non sécurisée fournie par le processeur d'application. Selon un mode de réalisation, le terminal comprend des moyens pour indiquer à l'utilisateur l'emplacement et l'étendue de la région dans laquelle est affichée l'image sécurisée incrustée. Selon un mode de réalisation, les moyens pour indiquer l'emplacement et l'étendue de la région dans laquelle est affichée l'image sécurisée incrustée comprennent une rangée d'indicateurs lumineux contrôlée par l'élément sécurisé et agencée en bordure de l'afficheur. Selon un mode de réalisation, les moyens pour indiquer l'emplacement, de la région dans laquelle est affichée l'image sécurisée incrustée comprennent une région de l'afficheur qui est en permanence sous le contrôle de l'élément sécurisé, et qui affiche une apparence déterminée, et une bordure de la région dans laquelle est affichée l'image sécurisée incrustée, qui présente la même apparence que la région de l'afficheur qui est en permanence sous le contrôle de l'élément sécurisé. Selon un mode de réalisation, les moyens configurés pour appliquer alternativement sur le bus câblé de l'afficheur des données d'image fournies par le processeur d'application et des données d'image fournies par l'élément sécurisé, comprennent un multiplexeur recevant sur une première entrée les données d'image fournies par le processeur d'application et sur une seconde entrée les données d'image fournies par l'élément sécurisé, un circuit de commande du multiplexeur, configuré pour commander le multiplexeur en fonction d'une donnée de configuration fournie par l'élément sécurisé. Selon un mode de réalisation, le circuit de commande est configuré pour commander le multiplexeur avec une finesse d'incrustation déterminée des données d'image fournies par l'élément sécurisé, ladite finesse d'incrustation étant à l'échelle d'une ligne ou à l'échelle d'un pixel des données d'image fournies par le processeur d'application. Selon un mode de réalisation, l'élément sécurisé est configuré pour, avant de réaliser l'opération, incruster dans une image non sécurisée fournie par le processeur d'application une image sécurisée comprenant des informations sur l'opération sécurisée. Selon un mode de réalisation, le terminal comprend en outre un dispositif de saisie fournissant des données tactiles sur un bus de données, et un démultiplexeur commandé par l'élément sécurisé et configuré pour relier le bus de données du dispositif de saisie à un bus du processeur d'application ou à un bus de l'élément sécurisé. Selon un mode de réalisation, l'élément sécurisé est configuré pour se relier au dispositif de saisie pendant l'affichage d'informations sur l'opération dans l'image sécurisée. Selon un mode de réalisation, le terminal comprend un bouton physique actionnable par l'utilisateur et surveillé par l'élément sécurisé, dans lequel l'élément sécurisé est configuré pour ne pas réaliser l'opération en l'absence d'une action de l'utilisateur sur le bouton physique. Selon un mode de réalisation, l'élément sécurisé et les moyens pour appliquer alternativement sur le bus câblé de l'afficheur des données d'image fournies par le processeur d'application et des données d'image fournies par l'élément sécurisé, sont intégrés en tout ou en partie dans un système-en-boîtier ou dans un système-sur-puce monté sur un support d’interconnexion du terminal. Selon un mode de réalisation, l'opération secrète comprend une étape de signature d'une donnée au moyen d'une clé secrète. Des modes de réalisation concernent également un procédé pour conduire une opération sécurisée au moyen d'un terminal connecté, notamment la signature d'une donnée au moyen d'une clé secrète, le terminal comprenant un processeur d'application configuré pour initier l'opération sécurisée, un élément sécurisé détenant une clé privée et configuré pour exécuter l'opération sécurisée, et un afficheur accessible par l'intermédiaire d'un bus câblé et recevant du processeur d'application des images non sécurisées relatives au déroulement de l'opération sécurisée, le procédé comprenant une étape consistant à incruster, dans au moins une image non sécurisée fournie par le processeur d'application et présentée sur l'afficheur, une image sécurisée fournie par l'élément sécurisé et non accessible au processeur d'application, l'image sécurisée comprenant des informations sur l'opération et s'étendant dans au moins une région déterminée de l'afficheur, l'étape d'incrustation étant sous le contrôle de l'élément sécurisé et ne pouvant pas être empêchée ou corrompue par le processeur d'application. Selon un mode de réalisation, le terminal comprend le procédé comprend l'étape consistant à prévoir dans le terminal des moyens contrôlés par l'élément sécurisé et configurés pour, à la demande de l'élément sécurisé, appliquer alternativement sur le bus câblé de l'afficheur des données d'image fournies par le processeur d'application et des données d'image fournies par l'élément sécurisé, de manière à ce que les données d'image fournies par l'élément sécurisé remplacent des données d'image fournies par le processeur d'application et forment ladite image sécurisée incrustée dans l'image non sécurisée fournie par le processeur d'application. Selon un mode de réalisation, le procédé comprend la prévision dans le terminal d'au moins un indicateur lumineux, et comprenant une étape d'activation de l'indicateur lumineux par l'élément sécurisé lorsque l'élément sécurisé incruste une image sécurisée dans une image non sécurisée fournie par le processeur d'application. Selon un mode de réalisation, le procédé comprend une étape consistant à indiquer à l'utilisateur l'emplacement et l'étendue de la région dans laquelle est affichée l'image sécurisée incrustée. Selon un mode de réalisation, l'emplacement et l'étendue de la région dans laquelle est affichée l'image sécurisée incrustée sont indiqués au moyen d'une rangée d'indicateurs lumineux contrôlée par l'élément sécurisé et agencée en bordure de l'afficheur. Selon un mode de réalisation, l'emplacement et l'étendue de la région dans laquelle est affichée l'image sécurisée incrustée sont indiqués au moyen d'une région de l'afficheur qui est en permanence sous le contrôle de l'élément sécurisé et qui présente une apparence déterminée, et d'une bordure de la région dans laquelle est affichée l'image sécurisée incrustée, qui présente la même apparence que la région de l'afficheur en permanence sous le contrôle de l'élément sécurisé. Selon un mode de réalisation, le dispositif comprend un dispositif de saisie fournissant des données tactiles sur un bus de données, et le procédé comprend comprenant l'étape consistant à relier le dispositif de saisie à l'élément sécurisé pendant l'affichage d'informations sur l'opération sécurisée dans l'image sécurisée incrustée. Selon un mode de réalisation, le dispositif comprend un bouton physique actionnable par l'utilisateur et surveillé par l'élément sécurisé, et le procédé comprend une étape consistant à configurer l'élément sécurisé de manière à ce qu'il n'exécute pas l'opération sécurisée en l'absence d'une action de l'utilisateur sur le bouton physique. Description sommaire des dessins Des exemples d'architectures de terminaux connectés incluant un portefeuille matériel de cryptomonnaie seront décrits dans ce qui suit à titre non limitatif en relation avec les figures jointes parmi lesquelles : - la illustre des exemples classiques d’utilisation d’un portefeuille matériel par l’intermédiaire d’un dispositif hôte, - la montre une architecture classique de portefeuille matériel froid, - la montre un premier mode de réalisation d'un terminal connecté embarquant un portefeuille matériel, - la montre un deuxième mode de réalisation d'un terminal connecté embarquant un portefeuille matériel, - la montre un troisième mode de réalisation d'un terminal connecté embarquant un portefeuille matériel, - la montre un quatrième mode de réalisation d'un terminal connecté embarquant un portefeuille matériel, - la montre un cinquième mode de réalisation d'un terminal connecté embarquant un portefeuille matériel, - la montre un sixième mode de réalisation d'un terminal connecté embarquant un portefeuille matériel et comprenant un multiplexeur dynamique pour incruster une image sécurisée dans une image non sécurisée, - la , la , la , la et la montrent divers modes de réalisation d'un procédé d'incrustation d'une image sécurisée dans une image non sécurisée, - la montre un premier mode de réalisation du multiplexeur dynamique, - la montre un deuxième mode de réalisation du multiplexeur dynamique, - la montre un troisième mode de réalisation du multiplexeur dynamique, - la montre un quatrième mode de réalisation du multiplexeur dynamique, - la montre un cinquième mode de réalisation du multiplexeur dynamique, - la montre un sixième mode de réalisation du multiplexeur dynamique, et - la montre un agencement de composants d'un terminal mobile connecté selon l'un des modes de réalisation des figures 4 à 8, 10 à 14. Description détaillée Dans ce qui suit seront décrites des architectures de terminal connecté incluant un portefeuille matériel embarqué et conçues pour éviter sinon limiter des attaques rendues possibles par une telle configuration. Pour ne pas créer un écosystème entièrement nouveau et ne pas nuire à l'expérience utilisateur, on recherche une compatibilité avec le matériel et les systèmes d'exploitation existants (Android, iOS), et à utiliser les voies traditionnelles de distribution des applications. Ainsi, il est supposé que le terminal connecté considéré est en mesure d'installer et exécuter des applications pouvant provenir de sources inconnues, voire douteuses, ce qui augmente le défi de la sécurisation des transactions avec le portefeuille matériel embarqué. Il est également supposé que des applications installables peuvent gagner un accès à des ressources matérielles intervenant lors d'une communication avec un élément sécurisé mettant en œuvre le portefeuille matériel. Par exemple, un logiciel malveillant pourrait enregistrer des touches appuyées pour voler un code secret, simuler des touches appuyées pour fausser une transaction, modifier l’affichage pour tromper l’utilisateur sur la transaction qu'il est en train d'effectuer, etc. Plus spécifiquement, la validation d’une transaction sur un téléphone par un clavier virtuel peut être interceptée par un logiciel espion de bas niveau ayant accès à l'interface de l'écran tactile en relevant les coordonnées des appuis sur la dalle tactile. Sans savoir ce qui est affiché, le logiciel espion peut se baser sur l'hypothèse que le clavier virtuel affiché est l'un des nombreux claviers traditionnels disponibles sur la plateforme, de sorte que les coordonnées des appuis révèlent les touches du clavier. Le logiciel espion peut également avoir accès aux accéléromètres ou autres capteurs habituellement présents dans un terminal mobile - les appuis sur différentes positions de la dalle se traduisent par des valeurs d'accélération différentes en rotation sur deux axes, de sorte que les positions des appuis peuvent être déduites. Pour y remédier partiellement, les applications classiques affichent, pour la saisie des codes d'identification personnels, un clavier virtuel numérique avec des touches aléatoirement positionnées. Cependant, bien que cette mesure soit utile pour entraver la déduction d'un code d'identification, un logiciel malveillant pourrait déduire qu'une transaction est en cours et, avant que l'utilisateur n'ait terminé, modifier le montant ou le destinataire et simuler la validation de la transaction par l'utilisateur en modifiant les entrées de l'application sans modifier l'application elle-même. La représente un mode de réalisation SPH1 d'un terminal mobile ou autre dispositif connecté embarquant un portefeuille matériel. Le terminal mobile comprend un processeur d'application APROC relié à divers dispositifs périphériques, notamment un afficheur tactile incluant un afficheur DISP et une dalle tactile KBD. Le processeur d'application est par exemple un processeur en bande de base assurant des communications téléphoniques et comprenant une connectivité Internet. Le processeur gère l'afficheur par l'intermédiaire d'un bus DISPB mettant en œuvre un protocole d'interface vidéo déterminé, par exemple le protocole MIPI DSI ("Display Serial Interface"). Le protocole MIPI-DSI a été largement adopté par l'industrie et est actuellement omniprésent dans les smartphones. Il est également largement utilisé dans les tablettes, les ordinateurs portables et les hybrides ordinateur portable/tablette. Le processeur gère ici la dalle tactile KBD par une autre interface, par exemple un bus de données DB1 de type I2C. Pour des raisons de lisibilité du dessin, tous les éléments d'un terminal mobile ne sont pas représentés. Le processeur d'application APROC intègre par ailleurs une enclave sécurisée ou un environnement d'exécution de confiance TEE ("Trusted Execution Environment"). Une telle enclave comprend généralement un processeur, une mémoire et un gestionnaire d'afficheur tactile dédiés et est conçue pour mettre en œuvre une interface utilisateur de confiance TUI ("Trusted User Interface"), par exemple comme le préconise le document "Trusted User Interface API" de GlobalPlatform® disponible à l'adresse suivante : https://globalplatform.org/wp-content/uploads/2013/06/GlobalPlatform_Trusted_User_Interface_API_v1.0.pdf Ainsi, cette enclave peut, selon les instructions exécutées par l'application, gérer l'affichage DISP et la saisie sur la dalle tactile KBD, comme cela est représenté. Le terminal mobile inclut également un élément sécurisé embarqué eSE mettant en œuvre un portefeuille matériel de cryptoactifs. L'élément eSE peut être semblable à celui intégré dans les portefeuilles matériels détachés exposés précédemment. Il peut s'agir du microcontrôleur sécurisé ST33 de STMicroelectronics® qui possède, entre autres, une interface SPI sécurisée ("Serial Peripheral Interface"), deux interfaces I2C ("Inter-Integrated Circuit") et diverses broches d'entrée/sortie programmables GPIO. Le lien désigné par LNK à la entre le terminal mobile HDV et le portefeuille matériel détaché HW, par exemple une interface USB ou Bluetooth, est ici réalisé par une liaison câblée permanente entre l'élément sécurisé eSE et le processeur d'application, ici un bus de données DB2. Le bus DB2 est par exemple un bus SPI relié à l'interface éponyme du microcontrôleur ST33. Pour assurer une meilleure sécurité de la communication, l'autre extrémité du bus DB2 peut être reliée à l'enclave TEE. La réalisation de la fonction de portefeuille matériel dans l'élément eSE et les échanges entre l'élément eSE et le processeur d'application peuvent être en tout point similaires à ce qui est connu des figures 1 et 2 et ne seront pas décrites plus en détail. Par ailleurs, une des broches d'entrée/sortie GPIO1 de l'élément sécurisé eSE est reliée à un bouton physique B prévu pour valider des transactions par une opération mécanique. La broche GPIO1 est exclusivement gérée par l'élément sécurisé et son changement d'état est impossible à simuler par un logiciel exécuté sur le processeur d'application. Une autre broche d'entrée/sortie GPIO2 de l'élément sécurisé eSE commande un indicateur lumineux LD formé ici par une diode LED pour signaler qu'une opération sécurisée est en cours avec le portefeuille matériel dans l'élément eSE. Le bouton B est un bouton physique dédié agencé, par exemple, sur une paroi latérale du terminal mobile, qui se distingue visuellement des autres boutons habituellement prévus sur le terminal mobile. L'indicateur lumineux LD est également dédié et ostensible par rapport aux autres indicateurs lumineux habituellement prévus sur le terminal mobile. Avec cette configuration, une transaction est préparée de façon usuelle par une application officielle, comme "Ledger Live", exécutée par le processeur d'application. A partir du moment où l'utilisateur doit valider la transaction, l'application passe par l'enclave TEE pour afficher la transaction sur l'afficheur DISP et, le cas échéant, gérer une phase de saisie sur la dalle tactile KBD, comme la saisie d'un code d'identification pour déverrouiller l'élément sécurisé. La validation et la signature de la transaction sont déléguées à l’élément sécurisé eSE (le portefeuille matériel) par des commandes émises sur le bus DB2 par l'intermédiaire de l'enclave TEE. Le cas échéant, la saisie du code de déverrouillage est transmise à l'élément sécurisé par le bus DB2. L’élément sécurisé eSE réagit à ces commandes par l'activation de l'indicateur lumineux LD et par l'attente d'un appui sur le bouton B. Lorsque l'utilisateur appuie sur le bouton B, l’élément sécurisé eSE calcule la signature de la transaction avec les clés privées stockées dans le portefeuille et transmet la signature à l'application par le bus DB2. L'élément sécurisé, ayant réalisé sa tâche, désactive l'indicateur lumineux LD et attend de nouvelles commandes. L'application met à jour la blockchain à travers un service réseau, affiche les informations utiles, et attend une nouvelle interaction avec l'utilisateur. Si aucune action n'est détectée sur le bouton B après l'écoulement d'un délai, la transaction est annulée. L'élément sécurisé le signale à l'application par le bus DB2, désactive l'indicateur lumineux LD, et attend de nouvelles commandes. Le bouton physique B a une fonction similaire à celle des boutons B1, B2 d'un portefeuille matériel détaché du type de la . Un logiciel malveillant, s'il parvient à modifier le montant ou l'adresse de la transaction, ne pourra pas simuler une validation, qui nécessite l'actionnement d'un bouton physique détectable seulement par l’élément sécurisé eSE. Ainsi, l'utilisateur, avant de valider, pourra confirmer que la transaction telle qu'affichée est bien celle qu'il a initiée. Si la transaction a été modifiée, l'utilisateur peut en principe le constater sur l'affichage et annuler la transaction. L'annulation pourra être effectuée classiquement par un appui sur un bouton virtuel sur l'afficheur tactile. La fonction du bouton d'annulation ne peut pas être détournée en une fonction de validation, puisqu'une validation n'est possible qu'à l'aide du bouton B géré exclusivement par l'élément sécurisé eSE. L'indicateur lumineux LD est activé et confirme à l'utilisateur que l'élément sécurisé est en train de prendre en charge les opérations et que les demandes qui lui sont faites par le terminal sont de source sûre. Selon une variante un peu plus coûteuse en termes de fabrication du boîtier du terminal mobile, deux boutons physiques peuvent être prévus, sur lesquels il faut appuyer simultanément pour valider une transaction. Malgré le contrôle de l'afficheur par l'enclave TEE, un logiciel malveillant sophistiqué pourrait modifier les données d'entrée et/ou de sortie de l'application pour les détourner et notamment modifier l'affichage des informations relatives à la transaction devant être vérifiées par l'utilisateur. Par exemple, le logiciel pourrait intercepter des données de transaction saisies par l'application pour les remplacer par des données frauduleuses, comme le montant de la transaction et l'adresse de la transaction. Même si cela est difficile lorsque la saisie est faite en mode sécurisé via l'enclave TEE, une telle attaque n'est pas impossible compte tenu du degré de sécurité offert par une enclave de type TEE. L'application génère alors une transaction avec des données modifiées à l'attention de l’élément sécurisé eSE et un affichage erroné correspondant. L'affichage, qui trahit alors la modification, peut aussi être intercepté et modifié, pour qu'il corresponde à la transaction initialement souhaitée par l'utilisateur. Ainsi, l'utilisateur verra des données de transaction apparemment correctes sur l'afficheur et validera la transaction, mais cette validation s'appliquera à la transaction frauduleuse modifiée qui a été déléguée sournoisement à l’élément sécurisé eSE. Dans un portefeuille matériel détaché classique, ce type de fraude est déjoué par le fait que le portefeuille matériel reproduit sur son propre afficheur la transaction qu'il va exécuter : l'utilisateur se fie à la transaction affichée par le portefeuille détaché, et peut la comparer à celle affichée par l'application sur le terminal. Une telle fonctionnalité n'est pas envisageable lorsque le portefeuille matériel est embarqué dans un smartphone, compte tenu de la difficulté de prévoir un deuxième afficheur et du surcoût que cela entraînerait. La montre un mode de réalisation SPH2 d'un terminal mobile intégrant un portefeuille matériel et mettant en échec ce type de manipulation de l'affichage. Le processeur d'application APROC incluant l'enclave TEE est ici intégré dans un système-sur-puce SoC recevant un processeur secondaire SPROC. Le SoC peut être le circuit i.MX 8M Plus de NXP®. L'élément sécurisé eSE est comme précédemment relié à l'enclave TEE par le bus DB2, par exemple un bus SPI. Le processeur SPROC dispose de son propre gestionnaire d'affichage et peut être considéré comme ayant un degré de sécurité élevé du fait qu'il est cloisonné par rapport aux autres circuits du SoC, de façon semblable à un élément sécurisé. Ainsi, à l'instar de l'élément sécurisé, le processeur SPROC peut recevoir des commandes de l'enclave TEE par l'intermédiaire du bus DB2. Le gestionnaire d'affichage du processeur SPROC est seul maître du bus DISPB et comporte une mémoire de trame FB1 que le processeur SPROC peut remplir à partir d'une mémoire de trame FB2 du processeur d'application ou d'une mémoire de trame FB3 de l'enclave TEE (flèches CPY), ou encore à partir de données d'affichage générées par lui-même, selon les besoins. Dans un autre mode de réalisation, le processeur SPROC peut afficher directement des données de la mémoire FB2 ou FB3 à partir d'un pointeur qui lui a été fourni. De tels mécanismes d'affichage sont documentés et ne seront pas décrits plus en détail. Ainsi, selon les besoins d'une application en cours d'exécution, l'afficheur DISP reçoit ses données du processeur d'application, de l'enclave TEE, ou du processeur SPROC lui-même. Avec cette configuration, une transaction est préparée de façon usuelle par une application officielle, telle "Ledger Live", exécutée par le processeur d'application APROC. La dalle tactile KBD est toujours gérée par l'enclave TEE pour sécuriser la saisie par l'utilisateur de données intervenant au cours d'une transaction, par exemple un code de déverrouillage ou un montant de transaction accepté, et délègue le traitement de la transaction à l'élément sécurisé par l'intermédiaire du bus DB2. Afin de pallier des failles potentielles reconnues d'un affichage géré par l'enclave TEE, l'élément sécurisé eSE, qui est lui-même relié au processeur SPROC par le bus DB2, est configuré pour fournir à celui-ci les données de la transaction devant être validées par l'utilisateur. L'élément sécurisé eSE est configuré pour, après avoir reçu les données de la transaction qu’il doit valider en signant la transaction au moyen d'une clé privée, transmettre au processeur SPROC via le bus DB2 les données d'affichage correspondantes, et demander au processeur SPROC de les afficher via le gestionnaire d'affichage FB1, à la place des données qui pourraient être présentes dans les mémoires de trame FB2 et FB3. Ainsi, même si l'application officielle est configurée pour générer de telles données et les transmettre au gestionnaire d'affichage de l'enclave TEE pour remplir la mémoire de trame FB3, ou les transmettre au gestionnaire d'affichage du processeur d'application pour remplir la mémoire de trame FB2, ces données ne seront pas affichées et seront remplacées par des données fournies par l'élément sécurisé. En conséquence, si des données compromises produites par l'application se trouvent dans la mémoire de trame FB2 ou FB3, ces données seront ignorées et ce sont les données produites par l'élément sécurisé dans la mémoire de trame FB1 qui seront effectivement affichées. Ce mode de réalisation SPH2 repose sur l'utilisation d'un système-sur-puce particulier qui pourrait ne pas convenir à certains fabricants de smartphones. De plus il est susceptible d'un type d'attaque qui consisterait à faire croire à l'élément sécurisé qu'il dialogue avec le processeur SPROC alors qu'il dialogue avec une enclave TEE ayant été piratée. L'élément sécurisé n'a donc pas la certitude absolue d'avoir accès à l'afficheur lorsqu'il croit y avoir accès. On décrira dans ce qui suit des modes de réalisation pouvant être mis en œuvre avec des composants plus conventionnels, tout en offrant un haut niveau de sécurité en ce qui concerne le contrôle des données affichées à l'utilisateur. La montre un mode de réalisation SPH3 d'un terminal mobile qui est dérivé du mode de réalisation SPH1 de la et comporte comme précédemment le processeur d'application APROC et l'enclave TEE, l'afficheur DISP, la dalle tactile KBD, l'élément sécurisé eSE, le bouton physique B relié à la broche GPIO1 pour valider des transactions et l'indicateur lumineux LD commandé par la broche GPIO2, pour signaler qu'une opération sécurisée est en cours dans l'élément eSE. Comme précédemment la dalle tactile KBD est contrôlée par l'enclave TEE via le bus DB1, par exemple un bus I2C. L'enclave TEE est reliée à l'élément sécurisé eSE par le bus DB2, par exemple un bus SPI. Le terminal SPH3 se distingue principalement du terminal SPH1 en ce qu'il comprend un gestionnaire d'affichage DMCU au service exclusif de l'élément sécurisé eSE, et un multiplexeur MUX dont la sortie est reliée au bus DISPB de l'afficheur DISP. Ce multiplexeur reçoit sur une première entrée, par l'intermédiaire d'un bus DISPB1, les données d'affichage produites par le processeur d'application APROC. Ces données d'affichage n'ont plus besoin d'être gérées par l'enclave TEE, comme cela est représenté, mais peuvent l'être si cela est souhaité. Une deuxième entrée du multiplexeur reçoit par l'intermédiaire d'un bus DISPB2 des données d'affichage générées par le gestionnaire d'affichage DMCU. Une borne d'entrée/sortie GPIO3 de l'élément sécurisé eSE fournit un signal SEL de sélection de l'entrée du multiplexeur qui sera reliée à la sortie de ce dernier. Ainsi, en fonction de la valeur sur signal SEL, le multiplexeur MUX relie le bus DISPB de l'afficheur au bus DISPB1 du processeur d'application APROC ou au bus DISPB2 du gestionnaire d'affichage DMCU. Dans une variante, le signal SEL peut aussi être prélevé sur la borne GPIO2 qui commande l'indicateur lumineux LD. Le gestionnaire d'affichage DMCU reçoit des commandes d'affichage de l'élément sécurisé eSE par l'intermédiaire d'un bus DB3, par exemple un bus I2C. Le protocole I2C offre un débit de données relativement bas, mais est utilisé ici pour véhiculer seulement des commandes d'affichage textuelles et vectorielles, utilisant une faible bande passante. L’élément sécurisé eSE est ainsi programmé pour générer des commandes d'affichage basiques pour les transactions qu'il traite et les transmettre au gestionnaire d'affichage DMCU. Le gestionnaire d'affichage DMCU est ici un circuit séparé, car les éléments sécurisés couramment disponibles dans le commerce ne sont pas dotés d'un processeur graphique et n'ont pas suffisamment de bande passante pour générer les images matricielles attendues sur le bus d'un afficheur tel que celui d'un smartphone moderne. Le gestionnaire d'affichage DMCU est par exemple un microcontrôleur de type STM32 de STMicroelectronics® incluant un contrôleur d'afficheur LCD-TFT équipé d'une interface MIPI-DSI. L’élément sécurisé eSE est configuré pour commander le multiplexeur MUX de manière à ce qu'il applique par défaut à l'afficheur DISP les données d'affichage provenant du processeur d'application APROC. Lorsqu'une application demande à l’élément sécurisé eSE de signer une transaction, celui-ci envoie des commandes d'affichage des données de la transaction au gestionnaire d'affichage DMCU et commute le multiplexeur MUX pour que les données graphiques produites par le gestionnaire DMCU parviennent à l'afficheur DISP. L'indicateur lumineux LD est activé et l’élément sécurisé eSE attend la validation de l'utilisateur en scrutant l'état du bouton B. Ainsi, l'afficheur DISP présente à l'utilisateur des données de transaction effectivement reçues et traitées par l’élément sécurisé eSE. Si ces données ont été modifiées par un programme malicieux, l'utilisateur ne manquera pas de le constater et pourra annuler la transaction. Il est par ailleurs préférable que la capture des informations saisies par l'utilisateur sur la dalle tactile KBD, par exemple un code de déverrouillage ou autre information sensible telle qu'un montant de transaction visé, présentent un degré de sécurité qui soit au moins de même niveau que celui de l'affichage. Dans les modes de réalisation SPH1, SPH2, SPH3 qui viennent d'être décrits, cette capture est assurée par l'enclave TEE et offre donc un degré de sécurité inférieur à celui de l'affichage. Un plus haut niveau de sécurité pourrait donc être souhaité. La est un schéma bloc d'un mode de réalisation SPH4 d'un terminal mobile qui se distingue de celui SPH3 de la en ce que le bus DB1 en sortie de la dalle tactile KBD, ici de type I2C, est relié à l'entrée d'un démultiplexeur DMUX à deux sorties. Une première sortie du démultiplexeur DMUX est reliée au processeur d'application APROC par l'intermédiaire d'un bus DB11, et une deuxième sortie du démultiplexeur est reliée à l'élément sécurisé eSE par l'intermédiaire d'un bus DB12. La sélection du démultiplexeur DMUX peut être opérée par le même signal SEL que celui appliqué au multiplexeur MUX par l'élément sécurisé. Les deux bus DB11 sont de préférence de même type que le bus DB1 pour éviter de prévoir un convertisseur de protocole dans le démultiplexeur DMUX. Dans ce mode de réalisation, aucune enclave TEE n'est prévue pour exécuter tout ou partie des applications faisant intervenir l'élément sécurisé, lesquelles sont donc exécutées par le processeur d'application APROC à l'exception des étapes déléguées à l'élément sécurisé. Toutefois, rien n'empêche de prévoir une enclave TEE et de l'utiliser pour commander les bus DISPB1 et de réception de données tactiles DB11 lors de l'exécution des phases non sensibles de l'application. L’élément sécurisé eSE est configuré pour positionner par défaut le multiplexeur MUX et le démultiplexeur DMUX en sorte qu'ils relient l'afficheur DISP et la dalle tactile KBD au processeur d'application, notamment au cours d'une phase préparatoire d'une transaction. L'élément sécurisé modifie ensuite la valeur du signal SEL pendant des phases sensibles d'exécution d'une transaction, afin de recevoir lui-même les informations éventuelles fournies par l'utilisateur via la dalle tactile KBD, et afin de fournir lui-même, par l'intermédiaire du gestionnaire d'affichage DMCU, les données de transaction devant être présentées à l'utilisateur. Ainsi, la dalle tactile échappe au contrôle de l'application lors de sa connexion à l'élément sécurisé, et l'application ne peut plus mettre en œuvre la phase de saisie. La phase de saisie est déléguée à l'élément sécurisé, qui est ici configuré pour gérer un clavier virtuel quant à la saisie et l'affichage de celui-ci. Dans un mode de réalisation, le bus DB12 est connecté à des broches d'entrée/sortie du gestionnaire d'affichage DMCU, au lieu d'être connecté à l'élément sécurisé. Ce mode de réalisation peut être avantageux si le gestionnaire d'affichage est un microcontrôleur du type proposé plus haut, ayant une capacité de traitement de données supérieure à celle de l'élément sécurisé. Le gestionnaire d'affichage DMCU étant sous le contrôle de l'élément sécurisé, il peut alors recevoir et traiter pour le compte de l'élément sécurisé une grande quantité de données que ce dernier ne pourrait peut-être pas traiter, par exemple des données issues d'un clavier tactile, et lui communiquer le résultat de ce traitement par l'intermédiaire du bus DB3. Quand une transaction est déléguée par l'application à l'élément sécurisé par le bus DB2, sans passer cette fois par l'enclave TEE, l’élément sécurisé eSE commande le multiplexeur et le démultiplexeur de manière à relier l'afficheur DISP au gestionnaire d'affichage DMCU et à relier la dalle tactile KBD à l’élément sécurisé eSE. L’élément sécurisé eSE met en œuvre la phase de saisie, si une saisie est requise. La saisie sur la dalle tactile ne peut plus être interceptée ou modifiée par un logiciel s'exécutant sur le processeur d'application, tandis que toute tentative de modification de l'affichage par un logiciel s'exécutant sur le processeur d'application est ignorée. Compte tenu de cette configuration, un logiciel s'exécutant sur le processeur d'application ne peut pas simuler des fausses validations sur la dalle tactile, de sorte que le bouton physique B est optionnel : la validation peut être faite en toute sécurité à l'aide de la dalle tactile. La sécurisation de la dalle tactile KBD qui vient d'être décrite comme un perfectionnement du mode de réalisation SPH3 de la est également applicable au mode de réalisation SPH2 de la dans lequel, en mode sécurisé, le bus DB1 de la dalle tactile sera aiguillé vers l'élément sécurisé au lieu d'être relié à l'enclave TEE. Dans un mode de réalisation, le signal SEL, ou tout autre indicateur du mode sécurisé (comme le signal de commande de l'indicateur lumineux LD), peut être utilisé pour inhiber des circuits en principe inutilisés pendant le mode sécurisé. Comme montré sur la , le signal SEL est par exemple appliqué à une borne INHIB du processeur d'application. Il peut être prévu que le basculement du signal SEL dans sa valeur correspondant au mode sécurisé provoque la réinitialisation du processeur en coupant son signal d'horloge ou en coupant son alimentation. Dans ce cas, tout logiciel malveillant s'exécutant sur le processeur d'application effectuant des analyses pour déduire des clés cryptographiques ou autres informations sensibles est rendu inopérant pendant la transaction sécurisée. L'inactivation totale du processeur d'application est notamment possible dans la configuration de la , où toutes les fonctions devant rester actives pendant la transaction sont déportées sur l’élément sécurisé eSE. Dans des cas où le processeur d'application ne peut être désactivé, on peut utiliser le signal SEL pour désactiver des circuits annexes pouvant servir à la déduction d'informations sensibles, comme les accéléromètres permettant de déduire les positions des appuis sur la dalle tactile. Les accéléromètres sont généralement intégrés dans un circuit dédié de centrale inertielle ou IMU ("Inertial Measurement Unit"). Une telle centrale inertielle peut être désactivée en arrêtant son horloge, en coupant son alimentation ou en coupant son lien de communication avec le processeur d'application, généralement un bus I2C. Un logiciel malveillant peut être conçu pour initier des transactions alors que l'élément sécurisé est dans une configuration où il ne demande pas de code de déverrouillage, par exemple pendant une durée limitée après avoir effectué une transaction précédente. Le logiciel malveillant tente dans ce cas de modifier l'affichage, mais cette tentative échoue du fait que c'est l’élément sécurisé eSE qui est maître de l'affichage dans les modes de réalisation des figures 5 et 6. Ainsi, l'affichage reflète la transaction effectivement initiée par le logiciel malveillant, tandis que l’élément sécurisé eSE attend la validation de l'utilisateur sur la dalle tactile (dans la configuration de la ), ou sur le bouton physique B (dans la configuration de la ou 5). Dans le cas de la , la modification frauduleuse de l'affichage est possible, de sorte que l'utilisateur peut être trompé quant à la nature de la transaction. Si la transaction frauduleuse est initiée à un moment où l'utilisateur a son terminal mobile en vue, il voit, sans l'avoir sollicité, passer le terminal mobile en mode sécurisé (indicateur lumineux LD), afficher la transaction et demander sa validation. L'utilisateur pourra vérifier l'affichage et annuler la transaction, mais cela demande à l'utilisateur d'être attentif et ne pas valider la transaction par mégarde. Si l'utilisateur n'a pas le terminal mobile en vue, la transaction est en principe annulée automatiquement à l'expiration d'un délai d'attente. Toutefois, si le terminal mobile est soumis à des secousses dans une poche ou un sac, une validation intempestive pourrait survenir avant l'expiration du délai d'attente, soit par un appui sur le bouton physique B (figures 3 à 5), soit par un appui sur la dalle tactile ( ) qui pourrait être configuré pour être opérant sur l'écran de veille du terminal mobile au moment de demander une validation. La montre un mode de réalisation SPH5 d'un terminal mobile mettant en échec ce type de fraude. En plus des éléments du mode de réalisation de la , un commutateur bistable S physique est connecté à une broche d'entrée/sortie GPIO4 de l'élément sécurisé eSE. Dans une première position, le commutateur S relie l'entrée GPIO4 à un niveau logique haut, par exemple une tension d'alimentation Vcc, et dans une deuxième position, le commutateur S relie l'entrée GPIO4 à un niveau logique bas, par exemple un potentiel de masse GND. Le commutateur S est agencé, par exemple, sur l'une des parois latérales du terminal mobile. L’élément sécurisé eSE est programmé pour ne pas traiter les commandes reçues via le bus DB3 dans l'une des positions du commutateur S, par exemple la première, et accepter les demandes de transactions reçues via le bus DB3 dans l'autre position. Le terminal SPH5 est conçu pour que le commutateur S soit le seul moyen disponible pour commuter le mode de l'élément sécurisé, c'est-à-dire qu'une application ne peut plus à elle seule déléguer le traitement d'une transaction. Ainsi, le mode de l'élément sécurisé est exclusivement sous le contrôle de l'utilisateur qui choisit le mode à l'aide du commutateur S selon les besoins. Le commutateur S étant initialement dans la position du mode inactif, une application susceptible d'initier des transactions est alors conçue pour solliciter l'utilisateur à changer de mode lorsqu'elle s'apprête à déléguer le traitement de la transaction à l’élément sécurisé eSE. Elle peut envoyer à l'afficheur DISP un message du type "Veuillez placer le téléphone en mode sécurisé à l'aide du commutateur", de préférence avec les informations relatives à la transaction en cours. Ce message est analogue à un message invitant l'utilisateur à connecter son portefeuille détaché classique au terminal mobile. L'utilisateur bascule alors le commutateur pour passer en mode actif. L’élément sécurisé eSE réagit en prenant diverses mesures protectrices, comme basculer le signal SEL pour relier l'afficheur DISP et la dalle tactile KBD respectivement au gestionnaire d'affichage dédié DMCU et à l’élément sécurisé eSE. L'indicateur lumineux LD est aussi activé pour signaler à l'utilisateur que le terminal mobile est en mode sécurisé. L'élément sécurisé eSE envoie un acquittement à l'application qui reprend l'exécution en transmettant les informations de la transaction à l’élément sécurisé. L’élément sécurisé eSE opère la phase de saisie sur la dalle tactile KBD, le cas échéant, et demande la validation à l'utilisateur en affichant de nouveau les informations relatives à la transaction. Lorsque la transaction est validée et signée, l’élément sécurisé eSE communique la transaction signée à l'application qui l'inscrit sur la blockchain. L'élément sécurisé sollicite l'utilisateur à changer de mode, en envoyant à l'afficheur DISP un message du type "Veuillez quitter le mode sécurisé en basculant le commutateur". Ce message est analogue à celui indiquant que l'utilisateur peut retirer son portefeuille détaché classique. Lorsque le commutateur est basculé, les connexions initiales de l'afficheur et de la dalle tactile sont rétablies, et l'indicateur lumineux LD est désactivé. Le commutateur S peut aussi être mis en œuvre dans les structures des figures 4 et 5, où la dalle tactile KBD n'est pas reliée à l'élément sécurisé. Dans ce cas, c'est l'application qui opère la phase de saisie avant de solliciter le basculement du commutateur S. Bien entendu, le commutateur S, à la merci de l'utilisateur, pourrait être basculé à des moments où ce n'est pas requis, ou ne pas être basculé quand c'est requis. Différentes combinaisons ne sont ainsi pas "normales", et cela peut être signalé à l'utilisateur par des messages affichés ou des alarmes, incitant l'utilisateur à basculer le commutateur pour que les opérations puissent reprendre normalement. Un logiciel malveillant pourrait également se comporter comme une application officielle en demandant le basculement de mode. Toutefois, comme l'utilisateur n'a pas initié la transaction et qu'on lui demande une action relativement contraignante, il est susceptible d'être plus vigilant. Le logiciel malveillant ne peut plus afficher un message trompeur hors propos dans ce contexte, puisque l'utilisateur s'attend à voir des informations de transaction. De telles informations de transaction seront difficiles à rendre crédibles, d'autant plus si elles sont vraies - typiquement un transfert d'un montant élevé à une adresse inconnue. Si le logiciel malveillant tente de cacher la nature de la transaction, celle-ci sera révélée et différente au moment où elle est affichée pour validation par l’élément sécurisé eSE, si l'utilisateur a quand même été incité à basculer en mode sécurisé. En tout cas, une transaction en attente, qu'elle soit frauduleuse ou non, ne peut plus être validée par un appui intempestif sur un bouton physique ou virtuel, car l'utilisateur doit intentionnellement basculer le terminal mobile en mode sécurisé pour valider la transaction. Dans les modes de réalisation qui viennent d'être décrits en relation avec les figures 5 à 7, l'élément sécurisé prend le contrôle de l'afficheur DISP lorsque qu'il bascule dans le mode sécurisé, le processeur d'application APROC ou le cas échéant l'enclave TEE n'ayant alors plus accès à celui-ci. Or, dans certaines applications sécurisées et notamment celles qui s'exécutent sur des portefeuilles matériels détachés, il est prévu que les données de la transaction soient affichées simultanément sur l'écran du dispositif hôte (téléphone mobile ou PC exécutant par exemple le logiciel "Ledger Live") et sur l'afficheur du portefeuille matériel. Ainsi, l'utilisateur peut d'un seul coup d'œil vérifier que les données de transaction présentées par l'application sont identiques à celles présentées par le portefeuille matériel et sur le point d'être exécutées par l'élément sécurisé. Dans ce qui précède, on a relevé qu'une telle fonctionnalité n'est pas envisageable lorsque le portefeuille matériel est embarqué dans un smartphone, compte tenu de la difficulté de prévoir un deuxième afficheur et du surcoût que cela entraînerait. On a ainsi proposé que l'affichage des données de transaction passe sous le contrôle de l'élément sécurisé. Dans un mode de réalisation SPH6 d'un terminal connecté intégrant un portefeuille matériel tel que montré sur la , un multiplexeur dynamique DYMUX est prévu pour permettre à l'élément sécurisé eSE et au processeur d'application APROC de présenter en même temps des informations sur l'afficheur, par une incrustation d'une image sécurisée fournie par l'élément sécurisé dans une image non sécurisée fournie par le processeur d'application. L'image sécurisée est incrustée dans une région 10 de l'afficheur DISP. Le reste de la surface d'affichage disponible forme une région 9 qui reçoit la partie de l'image non sécurisée qui n'est pas masquée par l'image sécurisée incrustée. Les régions 9 et 10 sont de préférence telles qu'elles couvrent ensemble l'intégralité de la surface d'affichage disponible. Une telle incrustation d'image améliore considérablement la sécurité offerte par le terminal et son ergonomie lors de la conduite d'une transaction. Par exemple, le processeur d'application peut afficher dans la région 9 l'information suivante : "vous souhaitez acheter 2 bitcoins pour une valeur de 50 000 USD" tandis que l'élément sécurisé affiche dans la région 10 de l'afficheur l'information suivante "veuillez confirmer votre achat de 2 bitcoins pour une valeur de 50 000 USD" ainsi qu'une représentation d'un bouton de validation sur lequel l'utilisateur doit exercer une action tactile pour déclencher la transaction. Comme autre exemple, le processeur d'application peut afficher dans la région 9 l'information suivante : "veuillez confirmer votre demande d'achat de 2 bitcoins pour une valeur de 50 000 USD en confirmant sur le clavier tactile sécurisé le nombre de bitcoins que vous voulez acheter puis la valeur de cette transaction" tandis que l'élément sécurisé affiche dans la région 10 un clavier virtuel permettant à l'utilisateur de saisir les deux données de la transaction, ici le nombre de bitcoins et la valeur de la transaction. Dans encore une variante, le bouton B est utilisé pour confirmer la transaction, le processeur d'application affiche dans la région 9 l'information suivante : "veuillez confirmer votre demande d'achat de 2 bitcoins pour une valeur de 50 000 USD en appuyant sur le bouton B" tandis que l'élément sécurisé affiche dans la région 10 la même information " veuillez confirmer votre demande d'achat de 2 bitcoins pour une valeur de 50 000 USD en appuyant sur le bouton B". Toute différence entre les données de transactions affichées par le processeur d'application et l'élément sécurisé sera perçue par l'utilisateur en raison de la simultanéité de ces affichages. Le mode de réalisation SPH6 montré sur la , permettant de réaliser une telle incrustation d'image, se distingue de celui SPH5 montré sur la en ce que le multiplexeur matériel MUX précédemment décrit est remplacé par un multiplexeur dynamique DYMUX. Le multiplexeur dynamique DYMUX comprend un multiplexeur matériel MUXi qui comporte comme le multiplexeur MUX de la une première entrée reliée au bus DISPB1 du processeur d'application, une second entrée reliée au bus DISPB2 du gestionnaire d'affichage DMCU de l'élément sécurisé eSE et une sortie reliée au bus DISPB qui contrôle l'afficheur. Le multiplexeur dynamique DYMUX comprend également un circuit de synchronisation SYNCT qui fournit le signal SEL au multiplexeur MUXi et reçoit un signal d'autorisation de superposition d'image PIP fourni par la borne GPIO3 de l'élément sécurisé. Le signal PIP présente une valeur active et une valeur inactive, correspondant en pratique à deux valeurs logiques de ce signal, par exemple 0 et 1 ou l'inverse. Lorsqu'il n'est pas sollicité pour une transaction, ou lorsqu'il n'a pas besoin - ou plus besoin - d'interfacer avec l'utilisateur, l'élément sécurisé porte le signal PIP à la valeur inactive. Dans ce cas, le circuit de synchronisation SYNCT commande le multiplexeur MUXi de manière à ce que le bus DISPB en sortie de celui-ci soit en permanence relié au bus DISPB1 du processeur d'application. Le processeur d'application a alors le plein contrôle de l'intégralité de l'afficheur. Lorsqu'il bascule dans le mode sécurisé pour participer à l'exécution d'une transaction, et/ou lorsqu'il a besoin d'interfacer avec un utilisateur, l'élément sécurisé met le signal PIP à sa valeur active, ce qui déclenche la superposition de données d'image fournies par le processeur d'application et de données d'image fournies par l'élément sécurisé par l'intermédiaire du gestionnaire d'affichage DMCU, au rythme des modifications de la valeur du signal SEL fourni par le circuit SYNCT. Les données d'image fournies par le processeur d'application APROC sont alors affichées dans la région 9 de l'afficheur et les données d'image fournies par le gestionnaire d'affichage DMCU sont affichées dans la région 10. Plus précisément, les données d'image fournies par le processeur d'application et qui correspondent à la région 10 sont remplacées - ou "écrasées" ("overwritted") - par les données d'images fournies par l'élément sécurisé, de sorte que les données d'image qui s'affichent dans la région 9 sont celles qui n'ont pas été écrasées par celles fournies par le gestionnaire d'affichage DMCU. Pour fournir le signal SEL, le circuit SYNCT prend en compte une donnée de configuration SDT ("Setup Data") qui détermine la taille, la forme et l'emplacement de la région 10 occupée par l'image incrustée. Le circuit SYNCT prend également en compte des informations de synchronisation prélevées sur les bus DISPB1 et DISPB2 et DISPB ou extraites de ceux-ci, afin de les transitions sur le bus DISPB entre les données d'image fournies par le processeur d'application APROC et données d'image fournies par le gestionnaire d'affichage DMCU, ne provoquent pas l'apparition de parasites ou de cisaillements de l'image (appelés classiquement "déchirement d'image" ou "tearing"). Dans un mode de réalisation, la taille de la région 10 est fixe et la donnée de configuration SDT est enregistrée "en dur" dans un registre de configuration SREG du multiplexeur DYMUX. La donnée SDT comprend par exemple le rang de la première ligne et le rang de la dernière ligne de la région 10, qui détermine la hauteur h de la région 10, ou, de façon équivalente, le rang de la première ligne et le nombre de lignes suivantes. Alternativement, la donnée SDT peut ne comprendre que le rang de la première ligne de la région 10 si celle-ci occupe toute la partie basse de l'afficheur. Dans un autre mode de réalisation, le registre de configuration est au contraire configurable et reçoit la donnée de configuration SDT de l'extérieur, celle-ci étant par exemple fournie par le gestionnaire d'affichage DMCU à la demande de l'élément sécurisé, ou directement fournie par l'élément sécurisé. Le bus DB1 en sortie de la dalle tactile KBD, ici de type I2C, est comme précédemment relié à l'entrée du démultiplexeur DMUX dont la première sortie est reliée au processeur d'application APROC par le bus DB11 et la deuxième sortie reliée à l'élément sécurisé eSE par le bus DB12. La sélection du démultiplexeur DMUX est opérée ici par le signal PIP de sorte que pendant toute la période où le terminal fonctionne en mode sécurisé et où les parties d'image fournies par l'élément sécurisé remplacent celles fournies par le processeur d'application, l'élément sécurisé a le contrôle exclusif du pavé tactile. Il n'est donc pas envisageable - et en pratique peu nécessaire - que pendant le fonctionnement en mode sécurisé, le processeur d'application propose à l'utilisateur des fonctionnalités tactiles dans la région 9 , sauf à prévoir que celles-ci soient prises en charge par l'élément sécurisé qui répercutera ensuite l'information tactile au processeur d'application. Si cela peut avoir un intérêt pratique ou ergonomique, l'homme de l'art pourra toutefois prévoir un mode de réalisation plus complexe afin que le processeur d'application reçoive en temps réel les données tactiles correspondant à la région 9 de l'afficheur où il peut afficher des informations. A cet effet le démultiplexeur DMUX pourrait par exemple être contrôlé par le signal SEL fourni par le circuit SYNCT. L'analyse du risque attaché à chaque configuration de terminal proposée dans la présente demande fait apparaître ici le risque qu'un programme malveillant ayant pris le contrôle du processeur d'application ou du bus DISPB1, affiche dans la région 10 des informations qui simulent celles affichées par l'élément sécurisé pendant l'exécution d'une transaction. Ainsi, l'utilisateur, après avoir lui-même sollicité une transaction, pourrait être tenté de penser que cette transaction est en cours d'exécution par l'élément sécurisé alors que la région 10 est encore sous le contrôle du processeur d'application et que l'élément sécurisé n'a pas encore été sollicité. Il convient donc de s'assurer que l'utilisateur est pleinement informé que l'information affichée dans la région 10 provient réellement de l'élément sécurisé. Afin de surmonter ce problème, deux cas doivent être distingués : 1) la région 10 est d'une hauteur fixe h0 et occupe un emplacement fixe sur l'afficheur, sur toute la largeur de l'afficheur. Par exemple, la région 10 occupe les "N" dernières lignes de l'afficheur correspondant à la hauteur h0, comme montré sur la . 2) la région 10 est d'une hauteur h variable et peut éventuellement être située dans un emplacement variable sur tout ou partie de la hauteur de l'afficheur, la hauteur h de la région 10 et son emplacement étant définis par la donnée de configuration SDT. Dans un exemple montré sur la , la région 10 présente une hauteur h1 et occupe toute la partie inférieure de l'afficheur. Dans un autre exemple montré sur la , la région 10 présente une hauteur h2 supérieure à h1 et s'étend sensiblement sur les deux tiers de la moitié inférieure de l'afficheur sans occuper la partie inférieure de celui-ci. Dans un mode de réalisation correspondant au premier cas, l'élément sécurisé est configuré pour activer l'indicateur lumineux LD lorsqu'il porte le signal PIP à la valeur active. Dans ce cas, et comme schématisé sur la , l'utilisateur est pleinement informé au moyen de l'indicateur lumineux LD, qui est sous le contrôle exclusif de l'élément sécurisé via la broche GPIO2, que l'élément sécurisé contrôle la région 10. Comme moyen d'information supplémentaire de l'utilisateur, l'emplacement de la région 10 peut être indiqué au moyen d'un repère visuel tel qu'une barre de couleur VM prévue sur le boîtier du terminal, à côté de l'afficheur, sur toute la hauteur de la région 10. Dans un mode de réalisation correspondant au second cas, une rangée LR d'indicateurs lumineux L i formés chacun par une diode LED, est prévue le long de l'afficheur, et s'étend sur tout ou partie de sa hauteur. La rangée d'indicateurs lumineux est pilotée par des broches d'entrée/sortie GPIOi de l'élément sécurisé, et est prévue pour indiquer l'emplacement précis de la région 10, chaque indicateur lumineux étant contrôlé individuellement par l'élément sécurisé. Ainsi, dans l'exemple de la , l'élément sécurisé allume les 7 premières diodes L1 à L7, et dans l'exemple de la , l'élément sécurisé allume les diodes L6 à L15. L'utilisateur est donc pleinement informé que l'élément sécurisé contrôle la région 10, et est également informé de l'emplacement de cette région 10. Dans un tel mode de réalisation, la rangée LR d'indicateurs lumineux remplace l'indicateur lumineux unique LD précédemment décrit, qui n'est plus nécessaire. Dans un autre mode de réalisation, correspondant au second cas et illustré sur les figures 9D, 9E, deux mesures sont prévues pour délimiter la région 10 et informer l'utilisateur que l'élément sécurisé contrôle cette région : i) une ou plusieurs lignes de l'afficheur, par exemple la dernière ligne ou les dernières lignes de celui-ci, forment une région de référence 101 qui est sous le contrôle permanent de l'élément sécurisé, grâce à une configuration correspondante du multiplexeur dynamique DYMUX. Une telle configuration, indépendante de la valeur du signal PIP, empêche le processeur d'application d'afficher des informations dans cette région. ii) lorsque l'élément sécurisé bascule dans le mode sécurisé et prend le contrôle de la région 10, il encadre celle-ci d'une bordure 102 ayant une apparence déterminée qui doit être identique à celle de la région 101. Si la région 10 n'est pas dans le prolongement immédiat de la région 101, l'élément sécurisé peut également et optionnellement afficher une région de liaison 103 reliant la bordure 102 à la région 101, dont l'apparence est identique à celle de la région 101. L'apparence susmentionnée de la région de référence 101 est de préférence variable et aléatoire. Elle peut consister en une couleur déterminée ou en une combinaison de couleurs déterminée, en un motif déterminé comprenant une combinaison de couleurs ou un dégradé de gris, en une texture visuelle déterminée, en des extraits de photographies, etc. Etant donné qu'un programme malicieux ne peut avoir accès aux informations envoyées par l'élément sécurisé au gestionnaire d'affichage DMCU, qui déterminent l'apparence de la région de référence 101, un tel programme malicieux sera dans l'incapacité, s'il veut simuler la région 10, d'encadrer celle-ci avec une bordure 102 ayant la même apparence que la région de référence 101. La mise en œuvre du multiplexeur dynamique DYMUX peut se faire de diverses manières à la portée de l'homme de l'art. Certaines seront décrites dans ce qui suit en relation avec les figures 10 à 15, qui montrent des modes de réalisation DYMUX1, DYMUX2, DYMUX3, DYMUX4, DYMUX5 et DYMUX6 de ce multiplexeur. Le multiplexeur dynamique DYMUX1 de la comprend un multiplexeur matériel MUX1, un circuit de synchronisation SYNCT1 et le registre de configuration SREG. Dans le mode de réalisation considéré ici, les bus DISPB1, DISPB2 véhiculent chacun des paquets de données formant des pixels, respectivement IPAQ1, IPAQ2, ainsi qu'un signal d'horloge, respectivement CLK1, CLK2, et un signal de synchronisation, respectivement TE1, TE2 ("Tearing Effect Signal"), utilisé classiquement comme un moyen permettant d'éviter le déchirement de l'image. Selon la valeur du signal SEL, les données d'image IPAQ fournies en sortie du multiplexer MUX1 sont les données IPAQ1 ou les données IPAQ2, le signal d'horloge CLK est le signal CLK1 ou le signal CLK2, et le signal de fin de trame TE est le signal TE1 ou le signal TE2. Ce dernier signal est émis par exemple toutes les 20 ms pour une image rafraîchie à la fréquence de 50 Hz. Le circuit SYNCT1 comporte un compteur de ligne LCPT qui compte les lignes affichées sur le bus DISPB et est configuré pour déterminer, à partir des données de configuration SDT présentes dans le registre SREG, les instants T1 où les paquets présents sur le bus DISPB1 doivent être fournis sur le bus DISPB, et les instants T2 où les paquets présents sur le bus DISPB2 doivent être fournis sur le bus DISPB à la place des paquets présents sur le bus DISPB1, soit les instants où le signal SEL doit changer de valeur. Pour permettre un contrôle précis des instants T1 et T2, le circuit de synchronisation SYNCT1 prélève sur les bus DISPB1, DISPB2 et DISPB des informations de synchronisation SI1, SI2, SI. Les informations de synchronisation SI1, SI2, SI comprennent par exemple les signaux d'horloge CLK1, CLK2, CLK et de fin de trame TE1, TE2, TE. Le circuit de synchronisation SYNCT1 comporte également des compteurs de pixels PCPT1, PCPT2, PCPT associés respectivement aux bus DISPB1, DISPB2, DISPB, qui fournissent chacun un signal de fin de ligne, respectivement LEP1, LEP2, LEP ("Line End Pulse"). Chaque compteur est remis à zéro après la détection d'une fin de ligne, puis compte de nouveau un nombre de pixels jusqu'à atteindre le nombre de pixels que comprend une ligne, à la suite de quoi il émet de nouveau le signal de fin de ligne et se remet à zéro, et ainsi de suite. Le fonctionnement de ces compteurs est à la portée de l'homme de l'art et repose sur des principes connus d'analyse du signal vidéo. En effet, on peut connaître la longueur d'une ligne en analysant le contenu de tous les paquets de données qu'elle comporte. Un signal de fin de ligne peut aussi être détecté via un système de mesure analogique, car une fin de ligne sur un signal MIPI correspond à une transition de la tension d'un signal électrique d'une valeur de l'ordre de 200 mV à une valeur de l'ordre de 2 V. Une bascule de Schmitt peut donc également être utilisée pour déterminer la fin d'une ligne. Le circuit de synchronisation SYNCT1 envoie au gestionnaire d'affichage DMCU des données de synchronisation SYNCDT1 concernant le bus DISPB1 et le bus DISPB, et envoie au processeur d'application APROC des données de synchronisation SYNCDT2 concernant le bus DISPB2 et le bus DISPB. Les données de synchronisation SYNCDT1 comprennent par exemple les signaux de fin de trame TE1, TE, les signaux de fin de ligne LEP1, LEP et les signaux d'horloge CLK1, CLK. Les données de synchronisation SYNCDT2 comprennent par exemple les signaux de fin de trame TE2, TE, les signaux de fin de ligne LEP2, LEP et les signaux d'horloge CLK2, CLK. Ainsi, le processeur d'application APROC reçoit des informations sur l'état du bus DISPB2 contrôlé par le gestionnaire d'affichage DMCU et réciproquement le gestionnaire d'affichage DMCU reçoit des informations sur l'état du bus DISPB1 contrôlé par le processeur d'application APROC. Le processeur d'application et le gestionnaire d'affichage peuvent ainsi mettre en œuvre une stratégie de synchronisation commune permettant au circuit SYNCT1 d'appliquer le signal SEL au multiplexeur matériel MUX1 sans provoquer l'apparition de parasites ou un déchirement de l'image affichée. Il n'est toutefois pas indispensable en pratique de prévoir un basculement immédiat entre les deux bus DISPB1, DISPB2. Il est en effet possible avec la plupart des écrans de disposer d'une certaine latence dans la fourniture des données de ligne. La commutation du multiplexeur peut donc présenter une telle "latence" entre l'arrêt du flux véhiculé par le bus DISPB1 et l'application du flux véhiculé par le bus DISPB2, ou réciproquement, sans toutefois que cette latence soit trop importante au risque d'altérer la fréquence d'affichage. Le mode de réalisation du multiplexeur DYMUX1 qui vient d'être décrit est générique et peut être simplifié en n'utilisant qu'une partie des signaux de synchronisation susmentionnés. A titre d'exemple, le multiplexeur dynamique DYMUX2 de la comprend un multiplexeur matériel MUX2 de même type que le multiplexeur MUX1 et un circuit de synchronisation simplifiée SYNCT2. Ce dernier ne comporte que le compteur de pixels PCPT fournissant le signal de fin de ligne LEP, et extrait le signal de fin de trame TE des données circulant sur le bus de sortie DISPB. Le signal de fin de ligne LEP et le signal de fin de trame TE sont envoyés au gestionnaire d'affichage DMCU et au processeur d'application APROC pour qu'ils se recalent sur la même référence à chaque nouvelle ligne et à chaque nouvelle image. Le gestionnaire d'affichage DMCU reçoit par ailleurs le signal d'horloge CLK1 du bus DISPB1 et assure lui-même la fourniture du signal SEL au multiplexeur matériel MUX2. A cet effet, le gestionnaire d'affichage DMCU est équipé du registre de configuration SREG, du compteur de ligne LCPT et reçoit le signal PIP. Le signal PIP lui permet de déterminer, à partir des données de configuration SDT présentes dans le registre SREG, les instants T1 où les paquets présents sur le bus DISPB1 doivent être fournis sur le bus DISPB, et les instants T2 où les paquets présents sur le bus DISPB2 doivent être fournis sur le bus DISPB à la place des paquets présents sur le bus DISPB1. Dans ce mode de réalisation, le gestionnaire d'affichage DMCU s'adapte automatiquement au signal d'horloge CLK1 du bus DISPB1 contrôlé par le processeur d'application, et peut remplacer des données d'image fournies par ce dernier par des données d'image fournies par le gestionnaire d'affichage DMCU de l'élément sécurisé, sans provoquer l'apparition de parasites ou un déchirement de l'image affichée. Le multiplexeur dynamique DYMUX3 de la comprend un multiplexeur matériel MUX3, un circuit de synchronisation SYNCT3, le registre SREG, un circuit de réception RX1 relié au bus DISPB1, un circuit de réception RX2 relié au bus DISPB2, un tampon de ligne LBUF1 dont l'entrée est reliée à la sortie du circuit RX1 et dont la sortie est reliée à une première entrée du multiplexeur MUX3, un tampon de ligne LBUF2 dont l'entrée est reliée à la sortie du circuit RX2 et dont la sortie est reliée à une seconde entrée du multiplexeur MUX3, et un circuit de transmission TX dont l'entrée est reliée à la sortie du multiplexeur MUX3 et dont la sortie est reliée au bus DISPB. A la différence des multiplexeurs MUX1, MUX2 des figures 10, 11, le multiplexeur MUX3 est un multiplexeur de données numériques brutes et non un multiplexeur de données d'image reçues sous une forme encapsulée dans une trame codée selon un protocole déterminé. En effet, les données brutes véhiculées sur le bus DISPB1 sont décodées - ou plus précisément désencapsulées - par le circuit de réception RX1, puis chargées dans le tampon de ligne LBUF1 pour être ensuite appliquées sur la première entrée du multiplexeur MUX3 . De même, les données brutes véhiculées sur le bus DISPB2 sont désencapsulées par le circuit de réception RX2 puis chargées dans le tampon de ligne LBUF2 pour être ensuite appliquées sur la seconde entrée du multiplexeur MUX3. A cet effet, le circuit SYNCT3 applique aux tampons LBUF1, LBUF2 des signaux d'écriture W1, W2 et de lecture R1, R2. Les circuits de réception RX1, RX2 fournissent au circuit SYNCT3 des informations de synchronisation SI1, SI2 lui permettant de compter le nombre de lignes d'une image ayant été affichées et de déterminer les instants T1 où le contenu du tampon LBUF1 doit être appliqué à l'entrée du circuit de transmission TX ainsi que les instants T2 où le contenu du tampon LBUF2 doit être appliqué à l'entrée du circuit de transmission TX. Le circuit de transmission TX reconstitue sur le bus DISPB, à partir des données brutes fournies par les tampons LBUF1, LBUF2, une trame vidéo codée selon le protocole désiré, qui peut être le même que celui des bus DISPB1, DISPB2 ou un autre protocole. Le circuit TX communique également au circuit SYNCT3 des informations de synchronisation SI3 lui permettant de parfaire le contrôle du multiplexeur MUX3. Le multiplexeur dynamique DYMUX4 de la comprend un multiplexeur matériel MUX4 identique ou de même type que le multiplexeur MUX3, et un circuit de synchronisation SYNCT4. Il diffère principalement du multiplexeur DYMUX3 en ce que le circuit de réception RX2 est supprimé, le tampon de ligne LBUF2 étant remplacé par un tampon de ligne étendu ELBUF2 pouvant recevoir des données brutes correspondant à plusieurs lignes de l'image à incruster. Le gestionnaire d'affichage DMCU accède directement au tampon de ligne étendu ELBUF2 sans passer par la fourniture d'un signal vidéo. A cet effet le bus DISPB2, au lieu d'être un bus véhiculant des trames vidéo selon le protocole MIPI-DSI ou autre protocole vidéo, peut être simplement un bus I2C ou SPI. Lorsque le tampon ELBUF2 a été rempli par gestionnaire d'affichage DMCU, le circuit de synchronisation SYNCT4 réalise plusieurs cycles de lecture du tampon pour la fourniture de son contenu au multiplexeur MUX4, en appliquant successivement au tampon des adresses de ligne LAD2 suivies d'un signal de lecture READ2. Afin d'éviter l'apparition d'artefacts visuels dus à la mise à jour des données dans le tampon de ligne étendu ELBUF2, un système à double tampon peut être prévu, un premier tampon étant utilisé pendant que le second tampon est rempli, le second tampon, une fois plein, étant ensuite utilisé pendant que le premier tampon est rempli, et ainsi de suite. Le multiplexeur dynamique DYMUX5 de la comprend un multiplexeur matériel MUX5 identique ou de même type que les multiplexeurs MUX3, MUX4, et un circuit de synchronisation SYNCT5. Il diffère principalement du multiplexeur DYMUX4 en ce que le tampon de ligne étendu ELBUF2 est remplacé par un tampon de page PBUF2 dans lequel le gestionnaire d'affichage DMCU a préalablement chargé l'intégralité des lignes de la région 10 ( ). Dans une variante de réalisation montrée sur la et applicable également aux modes de réalisation des figures 12 et 13, le multiplexeur dynamique DYMUX6 comprend un multiplexeur MUX6 dont la sortie , au lieu d'être appliquée directement au circuit de transmission TX, est appliquée à un tampon de page PBUF3 qui est préalablement rempli avec la totalité des lignes d'une page avant que son contenu ne soit appliqué au circuit TX pour la génération du signal vidéo sur le bus DISPB. Cette page intégrale préalablement mémorisée peut comprendre des lignes fournies par le processeur d'application et des lignes fournies par le gestionnaire d'affichage DMCU, occupant la région 10. Dans ce cas le multiplexeur MUX6 n'est plus du même type que les multiplexeurs précédemment décrit, et bien que toujours désigné ici par l'appellation multiplexeur car il procure le même effet technique, il constitue plutôt un système de copie de tampon à tampon à deux canaux d'entrée et un canal de sortie. Bien que les modes de réalisation du multiplexeur dynamique qui viennent d’être décrits assurent une incrustation des données d'image fournies par l'élément sécurisé avec une finesse d'incrustation, ou pas d'incrustation ("embedding pitch"), qui est à l'échelle d'une ligne des données d'image fournie par le processeur d'application, l'homme de l'art pourra modifier ce pas d'incrustation en fonction des objectifs visées en matière d'ergonomie et d'expérience utilisateur. Dans des modes de réalisation, le pas d'incrustation peut notamment être à l'échelle du pixel des données d'image fournie par le processeur d'application. Dans le mode de réalisation de la par exemple, le multiplexeur MUX5 peut être configuré pour sélectionner pixel par pixel les données d'image contenues dans les tampons LBUF1 et PBUF2, et ainsi remplir le tampon de sortie PBUF3 pixel par pixel. La illustre un agencement de composants d'un terminal mobile (smartphone) selon l'une des figures 4 à 8, 10 à 14. Le processeur d'application APROC et son éventuelle enclave TEE peuvent faire partie d'un système-sur-puce SoC ("System-on-Chip"). Le processeur d'application APROC ou le SoC qui le reçoit comporte des broches soudées à des pistes respectives d'un circuit imprimé ou autre support d’interconnexion recevant un certain nombre d'autres composants. Des groupes respectifs de broches sont associés aux différents liens de communication entre les composants, notamment les bus DISPB, DISPB1, DB1, DB2, DB11 précédemment mentionnés. L'afficheur DISP et la dalle tactile KBD sont généralement déportés et parallèles au circuit imprimé. Leurs bus de commande sont alors reliés au circuit imprimé par des connecteurs soudés sur des pistes du circuit imprimé. Dans un mode de réalisation, les éléments décrits ci-dessus, permettant de mettre en œuvre un portefeuille matériel embarqué, notamment les éléments eSE, DMCU, MUX ou DYMUX et DMUX, ainsi que les bus qui les relient et éventuellement les connecteurs de tout ou partie des éléments B, S, LD, LR peuvent être intégrés dans un système-en-boîtier SiP ("System-in-Package") conçu pour être monté sur un circuit imprimé. Alternativement, ces éléments peuvent être intégrés dans un autre SoC. Ainsi, pour intégrer un portefeuille matériel dans un terminal mobile, on aménage une place sur le circuit imprimé pour souder le système-en-boîtier SiP, on redessine les pistes des différents bus utilisés en les interrompant pour qu'elles passent par le SiP, et on prévoit des pistes pour établir la liaison sécurisée entre le processeur APROC et l'élément sécurisé eSE. Les différents éléments physiques discrets gérés par les circuits du SiP (le bouton B, le commutateur S, l'indicateur lumineux LD) peuvent être fixés sur le boîtier du terminal et reliés à des connecteurs du SiP, ou à des connecteurs déportés sur le circuit imprimé, eux-mêmes reliés par des pistes à des broches dédiées du SiP. Avec cette configuration, un terminal mobile classique peut être transformé en un terminal mobile incluant un portefeuille matériel embarqué par le simple ajout d'un SiP sur un circuit imprimé portant les composants du terminal classique. Bien que la conception d'un circuit imprimé adapté représente un certain coût de développement et de production, ce coût reste négligeable du fait qu'il n'y a pas d'adaptation à faire au niveau de la plateforme matérielle du terminal classique. La description qui précède a été effectuée essentiellement dans le contexte des smartphones embarquant un portefeuille matériel pour signer des transactions sur la blockchain (“smartphones blockchain”). Il apparaîtra clairement à l'homme de l'art que les moyens et procédés qui viennent d'être décrits pour assurer le contrôle de l'affichage par l'élément sécurisé pendant la signature d'une transaction s’appliquent à toute opération sécurisée nécessitant ce même contrôle. Les moyens et procédés décrits s’appliquent également à tout type de terminal connecté à Internet ou à un réseau local stockant des secrets servant à diverses utilisations impliquant des calculs cryptographiques, comme la signature de transactions en général et l’authentification, y compris l’authentification “zero knowledge”. Dans d’autres types de terminaux connectés, l’interface homme-machine peut être un afficheur associé à un clavier physique, ou à un joystick. Terminal connecté (SPH6) configuré pour exécuter une opération sécurisée, le terminal comprenant : - un processeur d'application (APROC) configuré pour initier l'opération sécurisée, - un élément sécurisé (eSE) pour exécuter l'opération sécurisée, et - un afficheur (DISP) accessible par l'intermédiaire d'un bus câblé (DISPB) et recevant du processeur d'application des données d'image à afficher à l'attention d'un utilisateur, caractérisé en ce qu'il comprend des moyens (DYMUX, MUXi) contrôlés par l'élément sécurisé et configurés pour, à la demande (PIP) de l'élément sécurisé et au moins pendant l'exécution de l'opération sécurisée, appliquer alternativement sur le bus câblé (DISPB) de l'afficheur des données d'image (IPAQ1) fournies par le processeur d'application et des données d'image (IPAQ2) fournies par l'élément sécurisé, de manière à ce que les données d'image fournies par l'élément sécurisé remplacent des données d'image fournies par le processeur d'application et forment une image sécurisée incrustée dans une image non sécurisée fournie par le processeur d'application, l'image sécurisée s'étendant dans au moins une région (10) déterminée de l'afficheur. Terminal selon la revendication 1, comprenant au moins un indicateur lumineux (LD, LR) activé par l'élément sécurisé lorsque l'élément sécurisé incruste une image sécurisée dans une image non sécurisée fournie par le processeur d'application. Terminal selon l'une des revendications 1 et 2, comprenant des moyens (VM, LR, 101, 102, 103) pour indiquer à l'utilisateur l'emplacement et l'étendue de la région (10) dans laquelle est affichée l'image sécurisée incrustée. Terminal selon la revendication 3, dans lequel les moyens pour indiquer l'emplacement et l'étendue de la région (10) dans laquelle est affichée l'image sécurisée incrustée comprennent une rangée (LR) d'indicateurs lumineux (L i ) contrôlée par l'élément sécurisé et agencée en bordure de l'afficheur. Terminal selon la revendication 3, dans lequel les moyens pour indiquer l'emplacement, de la région (10) dans laquelle est affichée l'image sécurisée incrustée comprennent : - une région (101) de l'afficheur (LR) qui est en permanence sous le contrôle de l'élément sécurisé, et qui affiche une apparence déterminée, - une bordure (102) de la région (10) dans laquelle est affichée l'image sécurisée incrustée, qui présente la même apparence que la région (101) de l'afficheur qui est en permanence sous le contrôle de l'élément sécurisé. Terminal selon l'une des revendications 1 à 5, dans lequel les moyens (DYMUX, MUXi) configurés pour appliquer alternativement sur le bus câblé (DISPB) de l'afficheur des données d'image (IPAQ1) fournies par le processeur d'application et des données d'image (IPAQ2) fournies par l'élément sécurisé, comprennent : - un multiplexeur (MUXi, MUX1-MUX5) recevant sur une première entrée les données d'image (IPAQ1) fournies par le processeur d'application et sur une seconde entrée les données d'image (IPAQ2) fournies par l'élément sécurisé, et - un circuit de commande (SYNCT, SYNCT1-SYNCT5, SREG, DMCU) du multiplexeur, configuré pour commander (SEL) le multiplexeur en fonction d'une donnée de configuration (SDT) fournie par l'élément sécurisé. Terminal selon la revendication 6, dans lequel le circuit de commande (SYNCT, SYNCT1-SYNCT5, SREG, DMCU) est configuré pour commander le multiplexeur avec une finesse d'incrustation déterminée des données d'image fournies par l'élément sécurisé, ladite finesse d'incrustation étant à l'échelle d'une ligne ou à l'échelle d'un pixel des données d'image fournies par le processeur d'application. Terminal selon l'une des revendications 1 à 7, dans lequel l'élément sécurisé est configuré pour, avant de réaliser l'opération, incruster dans une image non sécurisée fournie par le processeur d'application une image sécurisée comprenant des informations sur l'opération sécurisée. Terminal selon l'une des revendications 1 à 8, comprenant en outre un dispositif de saisie (KBD) fournissant des données tactiles sur un bus de données (DB1), et un démultiplexeur (DMUX) commandé par l'élément sécurisé (eSE) et configuré pour relier le bus de données (DB1) du dispositif de saisie à un bus (DB11) du processeur d'application ou à un bus (DB12) de l'élément sécurisé. Terminal selon les revendications 8 et 9, dans lequel l'élément sécurisé est configuré pour se relier au dispositif de saisie (KBD) pendant l'affichage d'informations sur l'opération dans l'image sécurisée. Terminal selon l'une des revendications 1 à 10, comprenant un bouton physique (B, S) actionnable par l'utilisateur et surveillé par l'élément sécurisé (eSE), dans lequel l'élément sécurisé est configuré pour ne pas réaliser l'opération en l'absence d'une action de l'utilisateur sur le bouton physique (B, S). Terminal selon l'une des revendications 1 à 11, dans lequel l'élément sécurisé (eSE) et les moyens (DYMUX, MUXi) pour appliquer alternativement sur le bus câblé (DISPB) de l'afficheur des données d'image (IPAQ1) fournies par le processeur d'application et des données d'image (IPAQ2) fournies par l'élément sécurisé, sont intégrés en tout ou en partie dans un système-en-boîtier (SiP) ou dans un système-sur-puce (Soc) monté sur un support d’interconnexion du terminal. Terminal selon l'une des revendications 1 à 12, dans lequel l'opération sécurisée comprend une étape de signature d'une donnée au moyen d'une clé secrète. Procédé pour conduire une opération sécurisée au moyen d'un terminal connecté (SPH6), notamment la signature d'une donnée au moyen d'une clé secrète, le terminal comprenant : - un processeur d'application (APROC) configuré pour initier l'opération sécurisée, - un élément sécurisé (eSE) détenant une clé privée et configuré pour exécuter l'opération sécurisée, et - un afficheur (DISP) accessible par l'intermédiaire d'un bus câblé (DISPB) et recevant du processeur d'application des images non sécurisées relatives au déroulement de l'opération sécurisée, procédé caractérisé en ce qu'il comprend une étape consistant à incruster, dans au moins une image non sécurisée fournie par le processeur d'application et présentée sur l'afficheur, une image sécurisée fournie par l'élément sécurisé et non accessible au processeur d'application, l'image sécurisée comprenant des informations sur l'opération et s'étendant dans au moins une région (10) déterminée de l'afficheur, l'étape d'incrustation étant sous le contrôle de l'élément sécurisé et ne pouvant pas être empêchée ou corrompue par le processeur d'application. Procédé selon la revendication 14, comprenant l'étape consistant à prévoir dans le terminal des moyens (DYMUX, MUXi) contrôlés par l'élément sécurisé et configurés pour, à la demande (PIP) de l'élément sécurisé, appliquer alternativement sur le bus câblé (DISPB) de l'afficheur des données d'image (IPAQ1) fournies par le processeur d'application et des données d'image (IPAQ2) fournies par l'élément sécurisé, de manière à ce que les données d'image fournies par l'élément sécurisé remplacent des données d'image fournies par le processeur d'application et forment ladite image sécurisée incrustée dans l'image non sécurisée fournie par le processeur d'application. Procédé selon l'une des revendications 14 et 15, comprenant la prévision dans le terminal d'au moins un indicateur lumineux (LD, LR), et comprenant une étape d'activation de l'indicateur lumineux par l'élément sécurisé lorsque l'élément sécurisé incruste une image sécurisée dans une image non sécurisée fournie par le processeur d'application. Procédé selon l'une des revendications 14 à 15, comprenant une étape consistant à indiquer à l'utilisateur l'emplacement et l'étendue de la région (10) dans laquelle est affichée l'image sécurisée incrustée. Procédé selon la revendication 17, l'emplacement et l'étendue de la région (10) dans laquelle est affichée l'image sécurisée incrustée sont indiqués au moyen d'une rangée (LR) d'indicateurs lumineux (L i ) contrôlée par l'élément sécurisé et agencée en bordure de l'afficheur. Procédé selon la revendication 17, dans lequel l'emplacement et l'étendue de la région (10) dans laquelle est affichée l'image sécurisée incrustée sont indiqués au moyen : - d'une région (101) de l'afficheur (LR) qui est en permanence sous le contrôle de l'élément sécurisé et qui présente une apparence déterminée, et - d'une bordure (102) de la région (10) dans laquelle est affichée l'image sécurisée incrustée, qui présente la même apparence que la région (101) de l'afficheur en permanence sous le contrôle de l'élément sécurisé. Procédé selon l'une des revendications 14 à 19, dans lequel le dispositif comprend un dispositif de saisie (KBD) fournissant des données tactiles sur un bus de données (DB1), et comprenant l'étape consistant à relier le dispositif de saisie (KBD) à l'élément sécurisé pendant l'affichage d'informations sur l'opération sécurisée dans l'image sécurisée incrustée. Procédé selon l'une des revendications 14 à 20, dans lequel le dispositif comprend un bouton physique (B, S) actionnable par l'utilisateur et surveillé par l'élément sécurisé (eSE), et comprenant une étape consistant à configurer l'élément sécurisé de manière à ce qu'il n'exécute pas l'opération sécurisée en l'absence d'une action de l'utilisateur sur le bouton physique (B, S).