FR 3154519 A1 20250425 FR 2311335 A 20231019 Terminal électronique (TL1) comprenant un processeur d’application (AP1), un processeur sécurisé (SP1), au moins un dispositif d’affichage (D3) et un dispositif de sélection (TMD) permettant à un utilisateur de sélectionner tout ou partie d’une image affichée par le processeur d’application sur le dispositif d’affichage. Le terminal est configuré pour exécuter, sur demande de l’utilisateur, une fonction de copie (SCB1a) dans une mémoire (CB2) de presse-papiers sécurisé accessible uniquement au processeur sécurisé, de données (ADD, IMADD) sélectionnées par l’utilisateur dans une image affichée par le processeur d’application. Figure abrégé : Figure 6 Terminal connecté comprenant une mémoire de presse-papiers sécurisé contrôlée par un processeur sécurisé. L’invention concerne un terminal électronique connecté comprenant un processeur d’application et un processeur sécurisé comprenant des moyens de calcul cryptographique. L’invention concerne notamment un tel terminal électronique dans lequel le processeur sécurisé est configuré en portefeuille matériel de cryptoactifs et le processeur d'application configuré en dispositif hôte du portefeuille matériel de cryptoactifs. 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 stocker les clés privées attachées à des comptes de cryptoactifs. 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, qui n’offrent pas le plus haut niveau de sécurité. Ainsi, de nombreuses plateformes d'échange ont été pillées de centaines de millions de dollars par des pirates au fil des ans. 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 des applications non sécurisées, et sont 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. La forme la plus simple de stockage à froid est le stockage passif. Un portefeuille passif peut être un document papier ou un fichier image sur lequel sont inscrites des clés publiques et privées de l’utilisateur. Le stockage passif comporte généralement un code QR intégré qui peut ensuite être scanné pour signer une transaction. L'inconvénient de ce support est que si le stockage passif est perdu, illisible ou détruit, l'utilisateur ne peut plus accéder à ses fonds. 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. Comme montré sur la FIG. 1 , 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 une 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. Le dispositif hôte HDV dispose d’un écran D1 permettant à l’utilisateur de préparer des transactions, et le portefeuille matériel HW dispose lui-même d’un écran ou d’un afficheur D2, permettant notamment de présenter à l’utilisateur des informations relatives à une transaction sur le point d’être signée et devant donc être vérifiées. La FIG. 2 montre l’architecture d’un portefeuille matériel HW du type commercialisé par la demanderesse sous l’appellation Nano S ® , décrit plus en détail dans le document https://developers.ledger.com/docs/nano-app/bolos-hardware-architecture. Le portefeuille matériel HW comporte un élément sécurisé SE ("secure element") associé à un microcontrôleur MCU. Rappelons ici qu’un élément sécurisé est une plate-forme matérielle comprenant des moyens de calcul cryptographique CRY, généralement un coprocesseur cryptographique, et 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. Un élément sécurisé se présente sous la forme d’une puce de semi-conducteur mettant en œuvre diverses contre-mesures visant à contrer des attaques de fraudeurs. L’élément sécurisé SE possède un système d’exploitation OS sécurisé (micrologiciel) prévu pour permettre l’installation et l’exécution d’applications APP (appelés aussi « programmes-applications »), par exemple le système d’exploitation BOLOS ® développé par la demanderesse. Le microcontrôleur MCU comporte une interface USB U1 et a pour fonction de permettre à l’élément sécurisé de communiquer avec un dispositif hôte externe HDV exécutant un logiciel compagnon (Cf. FIG. 1 ). Le portefeuille matériel HW comporte également un afficheur D2 et deux boutons B1, B2 gérés par le microcontrôleur MCU pour la sécurisation de certaines opérations par des actions de l’utilisateur sur ces boutons. D’autres modèles de portefeuilles matériels commercialisés par la demanderesse, comme le Stax ® , comportent un écran tactile de large surface au lieu d’un simple afficheur. Les portefeuilles matériels du type mentionné ci-dessus sont donc des dispositifs portables détachés ne comprenant aucun moyen de connexion à internet. Pour réaliser une transaction, on doit les relier temporairement à un dispositif hôte "connecté", comme un terminal mobile ou smartphone. Le caractère détaché de ces portefeuilles matériels offre un degré supérieur 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 rend ces portefeuilles matériels peu ergonomiques et susceptibles d'égarement ou d'oubli. Il existe donc un besoin de pouvoir intégrer un portefeuille matériel dans une plateforme de terminal mobile, par exemple un téléphone mobile, pour la transformer en un terminal mobile avec un portefeuille matériel embarqué. Un tel terminal électronique connecté comprendra, agencés dans un même boîtier, d’une part un processeur sécurisé configuré pour remplir la fonction de portefeuille matériel et d’autre part un processeur d’application comprenant des moyens de connexion à l’Internet, capable d’exécuter l’application compagnon conçue pour réaliser des transactions sur la blockchain, par exemple Ledger Live. Il existe simultanément un besoin de prévoir une solution pour protéger l’utilisateur des conséquences d’une attaque sur le processeur non sécurisé ayant permis à un fraudeur de prendre le contrôle du logiciel compagnon. Celui-ci, une fois corrompu, pourrait alors fausser la transaction à l’insu de l’utilisateur. Les transactions de cryptoactifs présentent en effet la spécificité de nécessiter que l’utilisateur fournisse à l’application compagnon CAP l’adresse du compte de destination avec lequel il souhaite réaliser la transaction. Or, cette adresse est généralement longue et complexe. Elle est générée à partir d’algorithmes de cryptographie à courbes elliptiques et de fonctions de hachage et se compose d'un ensemble de lettres et de chiffres alternés, par exemple : 0x388c818ca8b9251b393131c08a736a67ccbl9297 Ainsi, l’utilisateur se hasarde rarement à saisir manuellement une telle adresse, au risque de faire des erreurs. Il prélève plutôt l’adresse dans une application source d’information, au moyen de la fonction de presse-papiers du dispositif hôte, pour ensuite la coller dans l’application compagnon. L’application source d’information peut être un site web (navigateur internet), un logiciel de messagerie (adresse reçue dans une message), un email, une application Web3, un jeu, etc. Ce transfert d’information de l’application source d’information vers l’application compagnon, via le presse-papiers du processeur d'application, constitue une faille potentielle pour la sécurité de la transaction, qui sera mieux comprise en se référant aux figures 3 et 4. La FIG. 3 montre une configuration classique permettant de réaliser une transaction de cryptoactifs. Le portefeuille matériel HW susmentionné, par exemple un NANO S, est relié au dispositif hôte HDV susmentionné, par exemple un téléphone mobile, par la liaison LNK, par exemple Bluetooth. L’élément sécurisé SE du portefeuille matériel HW exécute une application de portefeuille matériel WAP configurée pour signer une transaction lorsque le dispositif hôte HDV le lui demande. Le dispositif hôte HDV comporte un processeur d’application AP, par exemple le processeur en bande de base d’un téléphone mobile, qui exécute une application compagnon CAP, par exemple l’application Ledger Live. La FIG. 4 décrit des étapes de préparation de la transaction jusqu’à son exécution. A une étape S00, l’utilisateur « USER » va dans l’application source d’information ISAP , par exemple un email dans un logiciel de messagerie. A une étape S05, illustrée sur la FIG. 5 , l’utilisateur sélectionne dans l’application ISAP une adresse ADD d’un compte de cryptoactifs et active la fonction de copie de l’adresse ADD dans le presse-papiers. A une étape S10, le processeur d’application AP stocke donc l’adresse sélectionnée ADD dans une mémoire de presse-papiers. A une étape S15, l’utilisateur va dans l’application compagnon CAP et initie des étapes de création d’une transaction. A une étape S20, illustrée sur la FIG. 5 , l’utilisateur est invité par l’application CAP à indiquer dans un descriptif de la transaction quelle est l’adresse ADD du compte bénéficiaire de la transaction. A cet effet, l’utilisateur active une fonction de collage du presse-papiers du processeur d’application AP pour coller l’adresse ADD dans le descriptif de la transaction affiché par l’application compagnon CAP, comme illustré sur la FIG. 5 . A une étape S25, l’utilisateur complète le descriptif de la transaction dans l’application compagnon CAP et demande l’exécution de la transaction. Le descriptif de la transaction comprend par exemple, en plus de l’adresse ADD, le type de cryptoactif (« Currency ») et le montant de la transaction (« Amount »). A une étape S30, le processeur d’application envoie à l'élément sécurisé SE le descriptif de la transaction comprenant l’adresse ADD et lui demande de le signer. A une étape S35, le processeur sécurisé SE exécutant l’application de portefeuille matériel WAP affiche sur l’afficheur D2 l’adresse ADD qu’il a reçue du processeur d’application, et demande à l’utilisateur de valider la transaction. A une étape S40, l’utilisateur retourne dans l’application source d’information ISAP pour afficher l’adresse ADD sur l’écran D1. A une étape S45 illustrée sur la FIG. 5 , l’utilisateur vérifie que les adresses ADD affichées respectivement sur l’écran D1 par l’application ISAP et sur l’afficheur D2 par le processeur sécurisé sont identiques, et valide la transaction, par exemple au moyen des deux boutons B1, B2 du portefeuille matériel HW ( FIG. 2 ). A une étape S50, le processeur sécurisé SE signe la transaction avec la clé privée de l’utilisateur et envoie la signature cryptographique au processeur AP. Généralement la signature porte sur le descriptif complet de la transaction, comprenant au moins l’adresse ADD du compte cible, le type de cryptoactif et le montant de la transaction. A une étape S55, le processeur d’application AP place la transaction signée, soit la transaction accompagnée de sa signature, sur la blockchain concernée. Le processeur sécurisé SE peut aussi refuser de signer la transaction à une étape S60, si l’utilisateur ne valide pas la transaction dans un temps déterminée après l’étape S40, ou si l'utilisateur décide d’abandonner la transaction. Dans un tel processus de génération et de signature d’une transaction, si l’application compagnon a été corrompue par un logiciel malveillant, une attaque est envisageable au moment où l’utilisateur colle l’adresse dans l’application compagnon (étape S20, FIG. 5 ). Si l’application compagnon a été corrompue par un logiciel malveillant, l’adresse copiée pourrait ne pas être celle que l’utilisateur a initialement prélevée dans l’application source d’information ISAP et stockée dans la mémoire de presse-papiers. En raison de la complexité de l’adresse, l’utilisateur peut ne pas s’apercevoir que l’adresse copiée dans l’application compagnon a été altérée. Par la suite, l’application compagnon va fournir l’adresse frauduleuse à l'élément sécurisé SE. Ensuite, au cours de l’étape de comparaison S45 illustrée sur la FIG. 5 , le logiciel malveillant peut afficher sur l’application ISAP une adresse identique à l’adresse corrompue pour conduire l’utilisateur à constater que les deux adresses sont identiques afin qu’il valide la transaction. Il pourrait donc être souhaité, notamment dans le cadre de l’intégration d’un portefeuille matériel de cryptoactifs dans un terminal connecté, de prévoir un moyen permettant d’offrir un degré de sécurité supplémentaire dans la préparation et l’exécution d’une transaction. Résumé Des modes de réalisation concernent un terminal électronique comprenant, dans un même boîtier, un processeur d’application, des moyens de connexion du processeur d’application à un réseau public ou privé, un processeur sécurisé comprenant des moyens de calcul cryptographique, une liaison de données entre le processeur d’application et le processeur sécurisé, au moins un dispositif d’affichage, pour permettre au processeur d’application et au processeur sécurisé d’afficher des images, et un dispositif de sélection permettant à un utilisateur de sélectionner tout ou partie d’une image affichée par le processeur d’application sur le dispositif d’affichage, le terminal étant configuré pour exécuter, sur demande de l’utilisateur, une fonction de copie dans une mémoire de presse-papiers sécurisé accessible uniquement au processeur sécurisé, de données sélectionnées par l’utilisateur dans une image affichée par le processeur d’application. Selon un mode de réalisation, le dispositif d’affichage comprend au moins une zone d’affichage sécurisé contrôlée par le processeur sécurisé, et le processeur sécurisé est configuré pour afficher sur la zone d’affichage sécurisé les données copiées dans la mémoire presse-papiers sécurisé. Selon un mode de réalisation, le terminal est configuré pour, lors de l’exécution de la fonction de copie dans la mémoire de presse-papiers sécurisé : au moyen du processeur d’application, lire dans une mémoire système du processeur d’application, des données de type texte sélectionnées par l’utilisateur dans l’image affichée par le processeur d’application, et transférer les données de type texte au processeur sécurisé, et, au moyen du processeur sécurisé, stocker les données de type texte dans la mémoire de presse-papiers sécurisé. Selon un mode de réalisation, le processeur d’application est configuré pour envoyer au processeur sécurisé une demande de signature cryptographique de données fournies par le processeur d’application, et dans lequel le processeur sécurisé est configuré pour, en réponse à la demande de signature cryptographique, déterminer si les données présentes dans la mémoire de presse-papiers sécurisé sont identiques à des données fournies par le processeur d’application, et refuser de fournir la signature cryptographique si les données présentes dans la mémoire de presse-papiers sécurisé ne sont pas identiques aux données fournies par le processeur d’application. Selon un mode de réalisation, le processeur d’application est configuré pour, lors de l’exécution de la fonction de copie dans la mémoire de presse-papiers sécurisé : au moyen du processeur d’application, lire dans une mémoire d’image du processeur d’application, une partie d’image sélectionnée par l’utilisateur dans l’image affichée par le processeur d’application, et transférer au processeur sécurisé la partie d’image sélectionnée par l’utilisateur, et, au moyen du processeur sécurisé, stocker la partie d’image dans la mémoire de presse-papiers sécurisé. Selon un mode de réalisation, le processeur d’application est configuré pour envoyer au processeur sécurisé une demande de signature cryptographique de données fournies par le processeur d’application, et le processeur sécurisé est configuré pour, en réponse à la demande de signature cryptographique, présenter sur le dispositif d’affichage les données présentes dans la mémoire de presse-papiers sécurisé, et attendre une autorisation de l’utilisateur avant de fournir la signature cryptographique. Selon un mode de réalisation, le terminal est configuré pour afficher simultanément sur une première zone du dispositif d’affichage des données fournies par le processeur d’application, et sur une seconde zone du dispositif d’affichage des données fournies par le processeur sécurisé. Selon un mode de réalisation, le terminal comprend un premier pilote d’affichage relié au processeur d’application, fournissant des premières données d’image, un second pilote d’affichage relié au processeur sécurisé, fournissant des secondes données d’image, un circuit de sélection d’affichage commandé par le processeur sécurisé, comprenant une première entrée reliée à une sortie du premier pilote d’affichage et une seconde entrée reliée à une sortie du second pilote d’affichage, et une sortie reliée au dispositif d’affichage, le processeur sécurisé étant configuré pour commander le circuit de sélection d’affichage de manière à afficher sur la première zone du dispositif d’affichage les données fournies par le processeur d’application par l’intermédiaire du premier pilote d’affichage, et sur la seconde zone du dispositif d’affichage les données fournies par le processeur sécurisé par l’intermédiaire du second pilote d’affichage. Selon un mode de réalisation, le terminal comprend un processeur auxiliaire pourvu d’un pilote d’affichage relié au dispositif d’affichage, le processeur auxiliaire étant relié au processeur d’application et au processeur sécurisé et commandé par le processeur sécurisé pour afficher sur la première zone du dispositif d’affichage les données fournies par le processeur d’application, et sur la seconde zone du dispositif d’affichage les données fournies par le processeur sécurisé. Selon un mode de réalisation, le dispositif de sélection comprend un module tactile relié au processeur d’application et au processeur sécurisé par l’intermédiaire d’un circuit de dérivation de données tactiles, le circuit de dérivation étant configuré pour envoyer des données tactiles au processeur d’application ou au processeur sécurisé en fonction d’une commande émise par le processeur sécurisé. Selon un mode de réalisation, le processeur sécurisé est un élément sécurisé en circuit intégré. Selon un mode de réalisation, le processeur sécurisé est un environnement d’exécution de confiance du processeur d’application. Selon un mode de réalisation, le processeur sécurisé est configuré pour exécuter une application de portefeuille matériel de cryptoactifs et le processeur d’application est configuré pour exécuter une application compagnon prévue pour coopérer avec l’application de portefeuille matériel de cryptoactifs. Selon un mode de réalisation, le processeur d’application exécutant l’application compagnon est configuré pour envoyer au processeur sécurisé une demande de signature cryptographique d’un descriptif d’une transaction incluant une adresse de compte de cryptoactifs, et le processeur sécurisé exécutant l’application de portefeuille matériel est configuré pour, avant de fournir la signature cryptographique, vérifier que l’adresse de compte de cryptoactifs figurant dans le descriptif est identique à une adresse de compte de cryptoactifs présente dans la mémoire de presse-papiers sécurisé. Des modes de réalisation concernent également un procédé pour conduire une transaction relative à des cryptoactifs au moyen d’un terminal du type décrit ci-dessus, le procédé comprenant les étapes consistant à configurer le processeur sécurisé pour qu’il exécute une application de portefeuille matériel de cryptoactifs ; prévoir dans une mémoire programme du processeur d’application une application compagnon prévue pour coopérer avec l’application de portefeuille matériel de cryptoactifs, et une application source d’information ; au moyen du processeur d’application exécutant l’application source d’information, afficher sur le dispositif d’affichage une image comprenant une adresse d’un compte de cryptoactifs ; copier l’adresse de compte de cryptoactifs dans la mémoire de presse-papiers sécurisé du processeur sécurisé, et au moyen du processeur d’application exécutant l’application compagnon, envoyer le descriptif de la transaction au processeur sécurisé et lui demander de fournir une signature cryptographique de la transaction. Selon un mode de réalisation, le procédé comprend l’étape consistant à afficher sur une zone d’affichage sécurisé du dispositif d’affichage contrôlée par le processeur sécurisé, l’adresse du compte de cryptoactifs copiée dans la mémoire presse-papiers sécurisé. Selon un mode de réalisation, le procédé comprend les étapes consistant à, au moyen du processeur sécurisé exécutant l’application de portefeuille matériel de cryptoactifs, vérifier que l’adresse de compte de cryptoactifs présente dans le descriptif de la transaction fourni par l’application compagnon est identique à une adresse de compte de cryptoactifs présente dans la mémoire de presse-papiers sécurisé, et ne pas fournir la signature cryptographique si les deux adresses sont différentes. Selon un mode de réalisation, le procédé comprend les étapes consistant à, au moyen du processeur sécurisé exécutant l’application de portefeuille matériel de cryptoactifs, afficher une partie d’image présente dans la mémoire de presse-papiers sécurisé du processeur sécurisé, et attendre une autorisation de l’utilisateur avant de fournir la signature cryptographique. Description sommaire des dessins Des modes de réalisation seront exposés dans la description suivante, faite à titre non limitatif en relation avec les figures jointes parmi lesquelles : La FIG. 1 montre un exemple classique d’utilisation d’un portefeuille matériel par l’intermédiaire d’un dispositif hôte, La FIG. 2 montre une architecture classique de portefeuille matériel, La FIG. 3 montre l’association d’un portefeuille matériel et d’un dispositif hôte pour la réalisation d’une transaction de cryptoactifs, La FIG. 4 décrit des étapes d’un procédé classique de préparation et d’exécution d’une transaction au moyen du portefeuille matériel et du dispositif hôte de la FIG. 3 , La FIG. 5 , la FIG. 5 , la FIG. 5 et la FIG. 5 décrivent des étapes du procédé de la FIG. 4 , La FIG. 6 montre un premier exemple de réalisation d’un terminal mettant en œuvre une fonction de presse-papiers sécurisé selon un premier et un deuxième modes de réalisation, La FIG. 7 montre un partage d’écran entre un processeur d'application et un processeur sécurisé présents dans le terminal de la FIG. 6 , La FIG. 8 décrit un procédé de préparation et d’exécution d’une transaction de cryptoactifs au moyen du terminal de la FIG. 6 et en faisant appel au premier mode de réalisation de la fonction de presse-papiers sécurisé, La FIG. 9 décrit un procédé de préparation et d’exécution d’une transaction de cryptoactifs au moyen du terminal de la FIG. 6 et en faisant appel au deuxième mode de réalisation de la fonction de presse-papiers sécurisé, La FIG. 10 , la FIG. 10 , la FIG. 10 , la FIG. 10 et la FIG. 10 illustrent des étapes d’au moins une des figures 8, 9, 12, 13, 15, 16, La FIG. 11 montre un deuxième exemple de réalisation d’un terminal mettant en œuvre une fonction de presse-papiers sécurisé selon un troisième et quatrième modes de réalisation, La FIG. 12 décrit un procédé de préparation et d’exécution d’une transaction de cryptoactifs au moyen du terminal de la FIG. 11 et en faisant appel au troisième mode de réalisation de la fonction de presse-papiers sécurisé, La FIG. 13 décrit un procédé de préparation et d’exécution d’une transaction de cryptoactifs au moyen du terminal de la FIG. 11 et en faisant appel au quatrième mode de réalisation de la fonction de presse-papiers sécurisé, La FIG. 14 montre un troisième exemple de réalisation d’un terminal mettant en œuvre une fonction de presse-papiers sécurisé selon un cinquième et un sixième modes de réalisation, La FIG. 15 décrit un procédé de préparation et d’exécution d’une transaction de cryptoactifs au moyen du terminal de la FIG. 14 et en faisant appel au cinquième mode de réalisation de la fonction de presse-papiers sécurisé, La FIG. 16 décrit un procédé de préparation et d’exécution d’une transaction de cryptoactifs au moyen du terminal de la FIG. 14 et en faisant appel au sixième mode de réalisation de la fonction de presse-papiers sécurisé. La FIG. 17 montre un autre exemple de réalisation d’un terminal mettant en œuvre une fonction de presse-papiers sécurisé selon l’un quelconque des modes de réalisation précités, La FIG. 18 montre encore un autre exemple de réalisation d’un terminal mettant en œuvre une fonction de presse-papiers sécurisé selon l’un quelconque des modes de réalisation précités, La FIG. 19 montre encore un autre exemple de réalisation d’un terminal mettant en œuvre une fonction de presse-papiers sécurisé selon l’un quelconque des modes de réalisation précités, et La FIG. 20 montre encore un autre exemple de réalisation d’un terminal mettant en œuvre une fonction de presse-papiers sécurisé selon l’un quelconque des modes de réalisation précités. Description détaillée Comme indiqué plus haut, un objectif de la présente divulgation est d’intégrer un portefeuille matériel de cryptoactifs dans un terminal électronique mobile de type smartphone, tablette, ou autre type de terminal mobile connecté. A cet effet, on prévoit une architecture de terminal comprenant au moins un processeur d'application, à laquelle est ajouté un processeur sécurisé. Le processeur sécurisé est configuré pour jouer le rôle de portefeuille matériel de cryptoactifs, et le processeur d'application configuré pour jouer le rôle de dispositif hôte vis-à-vis du processeur sécurisé. On reconstitue ainsi, à l’intérieur du terminal, la séparation fonctionnelle entre portefeuille matériel et dispositif hôte, qui est celle qui offre le plus haut niveau de sécurité car elle permet au processeur sécurisé de ne pas être connecté à l’internet pendant le calcul cryptographique, seul le dispositif hôte étant exposé à des attaques. Ainsi, la ou les clés privées de comptes de cryptoactifs détenues par le processeur sécurisé sont protégées contre des attaques. Le processeur sécurisé peut être un élément sécurisé indépendant sur puce de semiconducteur ou un environnement d'exécution de confiance TEE ("Trusted Execution Environment") du processeur d'application, comme on le verra par la suite à l’aide d’exemples. Dans une telle architecture, chaque processeur peut disposer de son propre écran d’affichage ou au contraire les deux processeurs peuvent partager le même écran. De même, concernant la sélection d’information sur l’écran ou la saisie de texte par l’utilisateur, chaque processeur peut disposer de son propre dispositif de sélection et de saisie, tel un clavier matériel associé à un pavé tactile, ou encore un écran tactile remplissant les deux fonctions de sélection et de saisie de texte. Dans un mode de réalisation permettant de réduire les coûts de fabrication et de simplifier l’ergonomie du terminal, les deux processeurs partagent le même dispositif de saisie. Un autre objectif de la présente divulgation est de limiter le risque d’une attaque du type décrit plus haut, au moment où des données dans le presse-papiers sont transférées dans l’application compagnon. A cet effet, une idée de la présente divulgation est de permettre à un utilisateur de copier à tout instant, dans une mémoire sécurisée accessible uniquement au processeur sécurisé, une information affichée par une application non sécurisée. Une telle mémoire sera appelée par la suite, par commodité, « mémoire de presse-papiers sécurisé » ou plus simplement « presse-papiers sécurisé » car elle est inaccessible au processeur d'application et donc à un attaquant. Dans le cadre de la réalisation d’une transaction, il devient alors possible de copier dans le presse-papiers sécurisé l’adresse d’un compte cible affichée dans une application source d’information. Si l’application compagnon a été corrompue par un logiciel malveillant et altère l’adresse du compte qui lui est communiquée, il restera, dans le presse-papiers sécurisé, une version authentique de cette adresse, ayant été « capturée » ou « photographiée » à un instant où le logiciel malveillant ayant pris le contrôle de l’application compagnon n’était pas actif puisque la copie a été effectuée avant que le logiciel compagnon ne soit sollicité. De plus, cette copie a été effectuée à un instant aléatoire non prédictible pour un attaquant, qui sera plutôt à l’affût de l’instant où l’utilisateur va copier l’adresse d’un compte dans l’application compagnon, pour lui substituer l’adresse d’un compte frauduleux. Cette version sécurisée de l’adresse pourra ensuite être utilisée pour vérifier que l’adresse communiquée par l’application compagnon au processeur sécurisé pour lui demander de signer la transaction est correcte. Une telle vérification implique une comparaison entre l’adresse dans le presse-papiers sécurisé et l’adresse présentée par l’application compagnon. Une telle comparaison pourra être visuelle, ou être conduite par le processeur sécurisé, ou les deux, comme on le verra par la suite. On décrira dans ce qui suit trois modes de réalisations principaux SCB1, SCB2, SCB3 d’un procédé de mise en œuvre d’un presse-papiers sécurisé dans un dispositif comprenant un processeur d'application et un processeur sécurisé. Le processeur sécurisé comprend des moyens de calcul cryptographique et offre un niveau de sécurité contre des attaques physiques ou logicielles supérieur à celui offert par le processeur d'application. Chaque mode de réalisation du presse-papiers sécurisé peut être décliné en deux variantes. Bien que décrits séparément dans ce qui suit, ces modes de réalisation et leurs variantes ne s’excluent pas mutuellement et peuvent être mis en œuvre conjointement dans un même terminal mobile. Ils se distinguent seulement par la manière avec laquelle une donnée est placée dans la mémoire de presse-papiers sécurisé : 1) Dans le mode de réalisation SCB1 du procédé, le processeur sécurisé stocke dans le presse-papiers sécurisé une donnée qui a été sélectionnée par l’utilisateur dans une image affichée par le processeur d'application et qui est fournie au processeur sécurisé par le processeur d'application. Dans la première variante, cette donnée est une donnée de type texte, par exemple une adresse ADD d’un compte de cryptoactifs. Dans la deuxième variante, cette donnée est une partie d’image, par exemple une partie d’image IMADD montrant l’adresse ADD d’un compte de cryptoactifs. 2) Dans le mode de réalisation SCB2 du procédé, le processeur sécurisé reçoit du processeur d'application une image complète qui est en cours d’affichage par le processeur d'application. Cette image est ensuite affichée par le processeur sécurisé, et l’utilisateur y sélectionne la donnée qu’il souhaite placer dans le presse-papiers sécurisé. Dans la première variante, cette donnée est une donnée de type texte, par exemple une adresse ADD d’un compte de cryptoactifs. Dans la deuxième variante, cette donnée est une partie d’image, par exemple une partie d’image IMADD montrant l’adresse ADD d’un compte de cryptoactifs. 3) Dans le mode de réalisation SCB3 du procédé, le processeur sécurisé stocke dans le presse-papiers sécurisé une image complète qui n’est pas fournie par le processeur d'application mais qui est générée par lui-même, par « espionnage » de l’image que le processeur d'application est en train d’afficher. Cette image est ensuite affichée par le processeur sécurisé, et l’utilisateur y sélectionne la donnée qu’il souhaite placer dans le presse-papiers sécurisé. Dans une première variante, cette donnée est une donnée de type texte, par exemple une adresse ADD d’un compte de cryptoactifs. Dans une deuxième variante, cette donnée est une partie d’image, par exemple une partie d’image IMADD montrant l’adresse ADD d’un compte de cryptoactifs. [Tableau] Tableau comparatif des différentes versions de presse-papiers sécurisé Type Résumé SCB1 option texte Des données ADD de type texte sont extraites par le processeur d'application de l’image qu’il affiche puis sont fournies par le processeur d'application au processeur sécurisé, qui les stocke dans la mémoire de presse-papiers sécurisé SCB1 option image Une partie d’image IMADD est extraite par le processeur d'application de l’image qu’il affiche puis est fournie par le processeur d'application au processeur sécurisé, qui la stocke dans la mémoire de presse-papiers sécurisé SCB2 option texte Le processeur d'application fournit au processeur sécurisé l’image complète qu’il affiche. Le processeur sécurisé affiche ensuite cette image. Des données de type texte ADD sont extraites par le processeur sécurisé de l’image qu’il affiche puis sont stockées dans la mémoire de presse-papiers sécurisé. SCB2 option image Le processeur d'application fournit au processeur sécurisé l’image complète qu’il affiche. Le processeur sécurisé affiche ensuite cette image. Une partie d’image IMADD est extraite par le processeur sécurisé de l’image qu’il affiche puis est stockée dans la mémoire de presse-papiers sécurisé. SCB3 option texte Le processeur sécurisé espionne le processeur d'application et reconstitue l’image que ce dernier affiche. Le processeur sécurisé affiche ensuite l’image copiée. Des données de type texte ADD sont extraites par le processeur sécurisé de l’image copiée qu’il affiche puis sont stockées dans la mémoire de presse-papiers sécurisé. SCB3 option image Le processeur sécurisé espionne le processeur d'application et reconstitue l’image que ce dernier affiche. Le processeur sécurisé affiche ensuite l’image copiée. Une partie d’image IMADD est extraite par le processeur sécurisé de l’image qu’il affiche puis est stockée dans la mémoire de presse-papiers sécurisé. Diverses combinaisons des variantes mentionnées ci-dessus peuvent être prévues, qui ne seront pas toutes décrites dans ce qui suit. Par exemple, une variante avec option image peut devenir une variante avec option texte en appliquant à la partie d’image une fonction OCR de reconnaissance optique de caractères, pour en extraire une donnée de type texte, comme on le verra par la suite. Cette variante « option texte » issue de la variante « option image » grâce à l’intervention d’une fonction OCR sera décrite dans ce qui suit en relation avec les deuxième et troisième modes de réalisation mais est également applicable au premier mode de réalisation. La FIG. 6 montre un premier mode de réalisation d’un terminal mobile TL1 configuré pour mettre en œuvre le presse-papiers sécurisé SCB1. Le terminal comprend, agencés dans un même boîtier (non représenté), un processeur d'application AP1, un processeur sécurisé SP1, et un écran tactile. L’écran tactile comprend la superposition d’un écran D3, par exemple LED ou OLED, et d’un panneau tactile TMD. Le processeur d'application AP1 comporte un port IO1 relié à un port IO10 du processeur sécurisé SP1 par un bus de données DB1, par exemple de type SPI. Le processeur d'application comprend une unité centrale UC, un circuit de communication COMCT, une mémoire non volatile NVM, une mémoire volatile RAM, et un circuit pilote d’affichage DD1 (Display Driver). Le circuit de COMCT permet au processeur d'application de se connecter à un réseau privé ou à un réseau public tel qu’internet. Il peut mettre en œuvre une ou plusieurs technologies de communication avec ou sans fil , telles que Wifi, GSM EDGE, 3G, 4G, 5G, etc. La mémoire NVM comprend un système d’exploitation OS1, une application compagnon CAP (programme application), et au moins une application source d’information (messagerie, navigateur web, jeu, etc.) par l’intermédiaire de laquelle l’utilisateur peut trouver une information dont il va avoir besoin, par exemple l’adresse ADD d’un compte de cryptoactifs. La mémoire RAM comprend un tampon d’image FBUF1 (« Frame Buffer »), une mémoire système SMEM1 et une mémoire de presse-papiers CB1 ou plus simplement un « presse-papiers » CB1. Le tampon d’image FBUF1 contient des données de type pixel PIX1 fournies par l’unité centrale, formant ensemble une image IMG1 affichée par le processeur d'application. Ces données de type pixel correspondent à des données source stockées dans la mémoire système SMEM1. Ainsi par exemple, du texte présent sous forme d’image dans le tampon d’image FBUF1, peut être extrait en tant que texte éditable de la mémoire système SMEM1 par le processeur d'application. Le pilote d’affichage DD1 reçoit les donnés PIX1 et fournit sur un port IO2 du processeur d'application des données d’image IDT1 formatées selon un protocole déterminé compatible avec l’écran D3, ici le format MIPI DSI. Le système d’exploitation OS1 comprend une fonction de presse-papiers classique, ou presse-papiers non sécurisé NSCB, et une fonction de presse-papiers sécurisé SCB1a. La fonction de presse-papiers sécurisé SCB1a est un sous-programme du système d’exploitation qui détermine les actions dévolues au processeur d'application pour la mise en œuvre du presse-papiers sécurisé SCB1. Le processeur sécurisé SP1 comprend une unité centrale UC, une mémoire non volatile recevant un système d’exploitation OS2 et une application de portefeuille matériel WAP (programme application), et une mémoire volatile comprenant un tampon d’image FBUF2 et une mémoire de presse-papiers sécurisé CB2. Le système d’exploitation OS2 comprend lui-même une fonction de presse-papiers sécurisé SCB1b, destinée à coopérer avec la fonction SCB1a du processeur d'application pour mettre en œuvre le presse-papiers sécurisé SCB1. La fonction de presse-papiers sécurisé SCB1b est un sous-programme du système d’exploitation qui détermine les actions dévolues au processeur d'application pour la mise en œuvre du presse-papiers sécurisé SCB1. Le processeur sécurisé SP1 est équipé d’un pilote d’affichage DD2, ici externe au processeur SP1 mais pouvant aussi être prévu comme un composant intégré dans le processeur. Le pilote d’affichage DD2 fournit à l’écran D3 des données d’image IDT2 au format approprié, ici MIPI DSI, à partir de données PIX2 de type pixel fournies par le tampon d’image FBUF2 sur un port IO11 du processeur sécurisé auquel le pilote DD2 est connecté. Ces données PIX2 forment une image IMG2 à afficher fournie par le processeur sécurisé. Le processeur sécurisé est également équipé d’au moins un bouton physique monostable B et d’un indicateur visuel LD telle une diode LED. Le bouton monostable B est actionnable par l’utilisateur et est connecté entre un port d’entrée/sortie IO20 du processeur sécurisé et un niveau logique bas, telle la masse du circuit. L’indicateur visuel LD est connecté entre un port d’entrée/sortie IO21 et la masse. Dans un mode de réalisation, le processeur sécurisé est également équipé d’un commutateur bistable S physique reliant un port d'entrée/sortie IO22 de l'élément sécurisé eSE à un niveau logique bas dans une première position, et à un niveau logique haut dans une deuxième position. L’utilisation de l’écran D3 est ici partagée entre le processeur d'application AP1 et le processeur sécurisé SP1. Ainsi, les données d’image IDT1 fournies par le processeur d'application via le pilote d’affichage DD1 et les données d’image IDT2 fournies par le processeur sécurisé SP1 via le pilote d’affichage DD2 sont appliquées respectivement sur une première et une deuxième entrée d’un circuit de sélection d’affichage MUX, dont la sortie est appliquée sur une entrée de l’écran D3. Le circuit MUX est commandé par un signal SEL fourni par un port IO12 du processeur sécurisé SP1 lequel peut donc décider à tout instant de prendre la main sur l’affichage et imposer l’affichage des images IMG2 qu’il place dans le tampon FBUF2. Dans un mode de réalisation du circuit MUX, le signal SEL est un signal numérique codé sur plusieurs bits qui permet au processeur sécurisé d’indiquer au circuit MUX le nombre de lignes de l’écran qu’il veut utiliser pour afficher ses propres informations. Le processeur sécurisé peut ainsi souhaiter afficher une image qui occupe l’intégralité de l’écran et se substitue à celle que veut afficher le processeur sécurisé, ou une image qui n’occupe que quelques lignes de l’écran, par exemple pour afficher simultanément une donnée détenue par le processeur sécurisé et une donnée détenue par le processeur d'application. Dans ce deuxième cas, comme montré sur la FIG. 7 , l’écran se divise en une zone d’affichage non sécurisé NSD, dans laquelle sont affichées les informations fournies par le processeur d'application, et une zone d’affichage sécurisé SD, dans laquelle sont affichées les informations fournies par le processeur sécurisé. Cette zone d’affichage sécurisé peut notamment permettre d’afficher le contenu du presse-papiers sécurisé. Selon le mode de réalisation retenu, l’étendue de la zone sécurisée SD peut être prédéterminée et fixe ou variable. Si cette étendue est fixe, elle peut être signalée à l’utilisateur par un repère visuel VM prévu en bord d’écran, par exemple une barre de couleur déterminée. Si cette étendue est variable, elle peut être signalée à l’utilisateur par une rangée de diodes LED formant le repère visuel VM, en allumant uniquement les diodes qui se trouvent en regard de la zone sécurisée, comme montré par exemple sur les figures 10A et 10D où un repère visuel d’étendue variable est représenté. Enfin, lorsque le processeur sécurisé utilise l’intégralité de l’écran, il peut le signaler à l’utilisateur en allumant l’indicateur lumineux LD ou tout autre indicateur si l’indicateur LD est déjà utilisé pour signaler à l’utilisateur que le processeur d'application est actif. Dans d’autres modes de réalisation, lorsque le processeur sécurisé exécute l’application de portefeuille matériel WAP et le processeur d'application exécute l’application compagnon CAP, le processeur sécurisé n’utilise qu’une partie de l’écran et l’autre partie est réservée au processeur sécurisé, ce qui évite au processeur sécurisé d’écraser certaines données que le processeur d'application voudrait afficher pendant qu’il utilise l’écran. Dans encore d’autres modes de réalisation où le signal SEL est codé sur plusieurs bits pour indiquer le nombre de lignes de l’écran que le processeur sécurisé veut utiliser, le signal SEL est fourni au processeur d'application ( FIG. 6 ) qui est configuré pour ajuster dynamiquement la taille de l’image qu’il fournit au circuit MUX afin d’éviter que des parties de ces images ne soient écrasées par les images fournies concurrentiellement au circuit MUX par le processeur sécurisé. Les données tactiles TDT émises par le panneau tactile TMD sont ici également partagées entre le processeur d'application AP1 et le processeur sécurisé SP1. Ainsi, les données tactiles TDT fournies par le panneau tactile TMD sont appliquées à l’entrée d’un circuit de dérivation DMUX1 ayant une première sortie reliée à un port d’entrée/sortie IO3 du processeur d'application et une deuxième sortie reliée à un port d’entrée/sortie IO13 du processeur sécurisé. Le circuit DMUX1 est commandé par un signal SEL fourni par le processeur sécurisé SP1 ou une partie du signal SEL si celui-ci comprend plusieurs bits. Ainsi, dans un mode de réalisation, le signal SEL comprend un premier signal SEL1 pour commander le circuit MUX, et un deuxième signal SEL2 pour commander le circuit DMUX1 indépendamment de la commande du circuit MUX. Le processeur sécurisé peut donc décider à tout instant de recevoir les données tactiles TDT à la place du processeur d'application. Dans une variante, le circuit de dérivation DMUX1 n’est pas prévu et les données tactiles TDT sont fournies à la fois au processeur d'application et au processeur sécurisé, chacun sachant si ces données le concernent ou non en fonction de ce qu’il est en train de faire. Comme indiqué plus haut, le processeur d'application et le processeur sécurisé sont configurés pour coopérer afin de mettre en œuvre le premier mode de réalisation SCB1 du presse-papiers sécurisé. Comme illustré sur la FIG. 7 , lorsqu’une application source d’information ISAP, affiche des informations sur la partie d’écran non sécurisée NSD, l’utilisateur peut sélectionner du texte ou une partie d’image (ici le texte « xyzxyzxyz »), avec son doigt grâce au panneau tactile TMD (ou dans d’autres modes de réalisation, avec un stylo ou une souris). Le processeur d'application affiche alors un menu de presse-papiers étendu ECBM (« Extended ClipBoard Menu ») comprenant en sus des fonctions « couper » ou « copier » classiques, une touche « copie SCB1 » pour copier le texte sélectionné dans le presse-papiers sécurisé. La touche « copie SCB1 » peut elle-même offrir deux options, à savoir de copie de la sélection en tant que donnée de type texte ou de copie de la sélection en tant que partie d’image (non représentées). Si l’utilisateur opte pour la copie SCB1 dans le presse-papiers sécurisé, il est prévu, dans un mode de réalisation, que le texte ou la partie d’image copié dans le presse-papiers sécurisé soit automatiquement affiché par le processeur sécurisé dans la zone d’affichage sécurisé SD, comme montré sur la FIG. 7 . Ainsi, l’utilisateur peut vérifier immédiatement que le texte ou la partie d’image copié dans le presse-papiers sécurisé et affiché sur la zone SD, est identique au texte ou à la partie d’image qu’il a sélectionné dans l’application ISAP. En référence aux figures 6 et 7, lorsque la fonction de copie sécurisée SCB1 avec l’option « texte » est activée par l’utilisateur après que celui-ci a sélectionné une donnée dans une image affichée par le processeur d’application (ici « xyzxyzxyz »), le processeur d'application identifie dans sa mémoire système SMEM1 la donnée de type texte correspondant à la donnée sélectionnée dans l’image, et copie cette donnée dans la mémoire de presse-papiers CB1. Le processeur d'application indique alors au processeur sécurisé, via le bus DB1, que l’utilisateur a demandé de copier une donnée dans le presse-papiers sécurisé. Après approbation du processeur sécurisé, le processeur d'application lui transfère la donnée « xyzxyzxyz » en tant que donnée de type texte et le processeur sécurisé l’enregistre dans la mémoire de presse-papiers sécurisé CB2. Ensuite, de préférence, le processeur sécurisé affiche la donnée « xyzxyzxyz » dans la zone d'affichage sécurisé SD, ce qui permet à l’utilisateur de s’assurer que la donnée copiée est identique à la donnée affichée par l’application ISAP dans la zone d’affichage non sécurisé NSD ( FIG. 7 ). Dans certains modes de réalisation, une action de l’utilisateur peut être requise pour valider l’enregistrement définitif de la donnée dans le presse-papiers sécurisé. Cette action est de préférence une action sur un organe sécurisé, c'est-à-dire contrôlé par le processeur sécurisé, par exemple le bouton B. Il sera noté ici que l'action consistant à valider l’enregistrement définitif de la donnée dans le presse-papiers sécurisé peut couvrir divers modes de réalisation, par exemple un mode de réalisation dans lequel la donnée est placée dans un registre tampon du processeur sécurisé pendant son affichage, au lieu d’être directement placée dans la mémoire de presse-papiers sécurisé. Dans ce cas, le processeur sécurisé ne la stocke dans la mémoire de presse-papiers sécurisé qu’après réception de l’accord de l’utilisateur. L’affichage de la donnée dans la zone d’affichage SD peut être interrompu à tout instant après réception de l’accord de l’utilisateur, ou, alternativement, selon l’une des options suivantes ou combinaison de ces options : - l’affichage est maintenu pendant un temps Tdmax déterminé par le processeur sécurisé, ou - l’affichage se termine lorsque l’utilisateur le demande au moyen d’une touche de fonction non sécurisée prévue à cet effet, ou - l’affichage dans la zone d'affichage SD se termine lorsque l’utilisateur quitte l’application source d’information dans la zone d'affichage NDS pour aller dans une autre application, par exemple l’application compagnon CAP. Une fois copiée dans le presse-papiers sécurisé, la donnée est en parfaite sécurité et ne peut pas être altérée par une attaque visant le processeur d'application et notamment l’application compagnon CAP. Dans la variante précitée de la fonction de presse-papiers sécurisé, l'utilisateur active la fonction de copie sécurisée SCB1 avec l’option « image » après avoir sélectionné, dans une image affichée par le processeur d'application, une partie d’image contenant une adresse ADD. Dans ce cas, le processeur d'application identifie dans le tampon d’image FBUF1 la partie d’image IMADD sélectionnée par l’utilisateur et la copie dans sa mémoire de presse-papiers CB1. Le processeur d'application établit ensuite une communication avec le processeur sécurisé via le bus DB1, et lui indique que l’utilisateur a demandé de copier une donnée de type image dans le presse-papiers sécurisé. Après approbation du processeur sécurisé, le processeur sécurisé lui transfère la partie d’image IMADD et le processeur sécurisé l’enregistre dans sa mémoire de presse-papiers sécurisé CB2 et l’affiche sur la zone d’affichage sécurisé SD. A partir de cet instant, la partie d’image IMADD copiée par l’utilisateur est en parfaite sécurité et ne peut être altérée par une attaque visant le processeur d'application et notamment l’application compagnon CAP. La fonction de presse-papiers sécurisé peut avoir diverses utilisations et en particulier la sécurisation de la préparation et de l'exécution d’une transaction, qui va être décrite plus avant maintenant. Dans le cadre de la préparation et de l'exécution d’une transaction, l’utilisateur utilise la mémoire de presse-papiers sécurisé pour y placer une adresse ADD d’un compte de cryptoactifs avec lequel il souhaite réaliser la transaction. Selon le mode de réalisation retenu du presse-papiers sécurisé, cette adresse ADD sera copiée dans le presse-papiers sécurisé en tant que donnée de type texte, ou en tant que partie d’image IMADD contenant l’adresse ADD. Schématiquement, le processeur d'application et le processeur sécurisé s’associent pour préparer et exécuter la transaction de la façon suivante : 1) le processeur d'application exécutant l’application compagnon CAP prépare la transaction en demandant à l’utilisateur de renseigner un descriptif de la transaction, 2) le processeur d'application envoie ensuite le descriptif de la transaction au processeur sécurisé, pour qu’il signe la transaction. 3) le processeur sécurisé exécutant l’application portefeuille matériel WAP retourne la signature de la transaction au processeur d'application. Ce dernier peut ensuite placer la transaction signée sur la blockchain concernée. Généralement, avant d’être signé, le descriptif de la transaction est tout d’abord transformé par le processeur sécurisé en une « transaction brute » (« raw transaction »), à savoir une chaîne de données binaires ou hexadécimales apte à être signée. Le descriptif de la transaction peut prendre diverses formes selon le type de transaction concernée. À titre d'exemple, le descriptif d'une transaction concernant l'Ethereum peut prendre la forme suivante : { "coin": "eth" "addr": "0x388c818ca8b9251b393131c08a736a67ccbl9297", "sender": "0x473780deaf4a2ac070bbba936b0cdefe7f267dfc", "amount": "0.000567202182620675", "maxGas": "0.00000005" } Le descriptif de transaction selon l'exemple ci-dessus, lorsqu'il est transformé en transaction brute, peut par exemple se présenter ainsi (en hexadécimal) : f86e826f4a8505f901eadd826b6c94388c818ca8b9251b393131c08a736a67ccbl92978801167140fda3d0818025a0dcbal464c58f31892bd0ae8e6271f838189cd344d98e928f3194efe4bce9ebc6a04fOfc71bee74ala6fafbel7cde3c35981c93b58703856ef5dd53884albl53773 L’algorithme de signature utilisé par le processeur sécurisé est spécifique à la blockchain considérée. Les blockchains Bitcoin et Ethereum utilisent par exemple comme moyen de signature l'algorithme ECDSA/secp256k1/SHA256, soit une signature générée avec l’algorithme ECDSA (Algorithme de signature numérique à courbe elliptique) configuré avec le paramètre secp256k1, incluant un hachage préalable de la transaction brute au moyen de la fonction SHA-256 (Secure Hash Algorithm) pour obtenir le « hashcode » ou condensat de la transaction. Cet algorithme produit des signatures du type suivant : { "r" "0xb91467e570a6466aa9e9876cbcd013baba02900b8979d43fe208a4a4f339f5fd", "s" : "0x60 07e7 4cd82e037b8 0018 6422fc2dal67c7 4 7ef04 5e5dl8a5f5d4 300f8ela02 9" , "v": 28 } Le descriptif de la transaction et la signature de la transaction sont ensuite transmis par le processeur d'application à un service de diffusion qui assure la diffusion de la transaction sur la blockchain concernée. Dans un souci de simplification du langage, les termes « transaction », « descriptifs de la transaction », ou « forme brute de la transaction » peuvent ici ou dans ce qui suit avoir la même signification. De plus, aucune signification limitative n’est conférée aux termes « descriptif de la transaction », « transaction », « signature de la transaction », qui peuvent varier dans de larges proportions selon le cryptoactif considéré et la blockchain concernée. Dans le cas notamment d’un cryptoactif de type « smart contract », le descriptif de la transaction peut comprendre un nombre de paramètres plus élevé que le descriptif d’une transaction simple en Bitcoin ou Ethereum. Dans tous les cas, le processeur sécurisé est de préférence configuré pour présenter à l’utilisateur l’ensemble des paramètres de la transaction en application du principe « WYSIWYS » (« What You See Is What You Sign » soit « Ce que vous voyez est ce que vous signez »). L’usage du presse-papiers sécurisé dans le cadre de la préparation et de l’exécution d’une transaction de cryptoactifs sera mieux compris en se référant aux organigrammes des figures 8 et 9 qui décrivent deux exemples de préparation et d’exécution d’une transaction de cryptoactifs. La notation suivante est utilisée sur les figures 8 et 9 : - « USER » désigne un utilisateur, - « AP1-USER » se rapporte à une action du processeur d’application AP1 en réponse à une demande de l’utilisateur, - « AP1-CAP » se rapporte à une action du processeur d’application AP1 exécutant l’application compagnon, soit une action exécutée par l’application compagnon au moyen du processeur d’application AP1, - « SP1-WAP » se rapporte à une action du processeur sécurisé SP1 exécutant l’application de portefeuille matériel WAP, soit une action exécutée par l’application de portefeuille matériel WAP au moyen du processeur sécurisé AP1, - « va dans » ou « retourne dans » signifie que l’utilisateur se rend dans ou retourne dans l’interface graphique de l’application concernée (affichage dans une fenêtre ou en plein écran) pour faire quelque chose : lire des informations, sélectionner des données affichées, les supprimer, les copier dans une mémoire de presse-papiers, ou encore coller des données stockées dans une mémoire de presse-papiers. Dans le mode de réalisation de la FIG. 8 , la fonction de presse-papiers sécurisé SCB1 est utilisée pour copier une adresse ADD en tant que donnée de type texte. A une étape S100, l’utilisateur va dans une application source d’information ISAP, par exemple une page web ou un email contenant l’adresse ADD d’un compte de cryptoactifs. A une étape S102, illustrée sur la FIG. 10 , l’utilisateur sélectionne l’adresse ADD en tant que données de type texte, et active la fonction NSCB de copie dans le presse-papiers non sécurisé. A une étape S103, le processeur d’application AP1 lit dans sa mémoire système SMEM1 l’adresse sélectionnée ADD. A une étape S104, le processeur d’application AP1 stocke l’adresse ADD dans la mémoire de presse-papiers CB1. A une étape S109, également illustrée sur la FIG. 10 , l’utilisateur active la fonction SCB1 de copie dans le presse-papiers sécurisé. A une étape S110, le processeur d’application AP1 établit une communication avec le processeur sécurisé SP1. A une étape S111, le processeur d’application AP1 transmet l’adresse ADD présente dans la mémoire de presse-papiers CB1 au processeur sécurisé SP1. A une étape S112, le processeur sécurisé SP1 stocke l’adresse ADD dans la mémoire de presse-papiers sécurisé CB2 et de préférence l’affiche sur la zone sécurisée SD de l’écran, comme montré sur la FIG. 10 , afin que l’utilisateur puisse vérifier que l’adresse source et l’adresse copiée sont identiques. Comme indiqué plus haut, l’accord de l’utilisateur peut ici être requis pour valider l’enregistrement de l’adresse ADD dans le presse-papiers sécurisé. Cet accord est de préférence donné par l’intermédiaire d’un organe sécurisé comme le bouton B. A une étape S115, l’utilisateur va dans l’application compagnon CAP. A une étape S120, le processeur d’application AP1, à la demande de l’utilisateur, colle l’adresse ADD dans un descriptif de la transaction devant être renseigné par l’utilisateur et affiché par l’application compagnon CAP. L’adresse ADD est collée dans l’application compagnon CAP à partir de la mémoire de presse-papiers non sécurisé CB1, comme illustré par les figures 10B et 10C. A une étape S125, l’utilisateur complète le descriptif de la transaction proposé par l’application compagnon CAP et demande l’exécution de la transaction. La saisie des informations par l’utilisateur est ici faite au moyen d’un clavier virtuel affiché sur l’écran D3, le panneau tactile TMD étant ici utilisé à la fois comme moyen de sélection d’information et moyen de saisie d’information. Dans d’autres variantes, le terminal peut être équipé d’un clavier physique et la sélection d’information peut être faite au moyen d’un pavé tactile distinct de l’écran D3. A une étape S135, le processeur d’application AP1 exécutant l’application compagnon CAP envoie au processeur sécurisé SP1 le descriptif de la transaction comprenant l’adresse ADD et lui demande de le signer. A une étape S136, le processeur sécurisé SP1 exécutant l’application de portefeuille matériel WAP vérifie que l’adresse ADD reçue est identique à l’adresse ADD dans la mémoire de presse-papiers sécurisé CB2. Si les adresses sont différentes, le processeur sécurisé va à une étape S160, sinon va à une étape S140. A l’étape S140, illustrée sur la FIG. 10 , le processeur sécurisé SP1 exécutant l’application de portefeuille matériel WAP affiche sur la zone d’affichage sécurisé SD le descriptif de la transaction comprenant l’adresse ADD, et optionnellement l’adresse ADD présente dans le presse-papiers sécurisé, et demande à l’utilisateur de valider la transaction.. A une étape S145, l’utilisateur vérifie optionnellement que l’adresse ADD affichée sur la zone d’affichage non sécurisée NSD et l’adresse ADD affichée sur la zone d’affichage sécurisé SD sont identiques, avant de valider la transaction au moyen du bouton B, sinon indique au processeur sécurisé qu’il refuse la transaction, par exemple au moyen d’une touche tactile puisque les données TDT fournies par le panneau tactile TMD sont reçues par le processeur sécurisé pendant cette phase de validation. A une étape S150, si l’utilisateur a validé la transaction, le processeur sécurisé SP1 exécutant l’application de portefeuille matériel WAP signe la transaction et envoie la signature au processeur d’application AP1. A une étape S155, le processeur d’application AP1 exécutant l’application compagnon CAP place la transaction sur la blockchain concernée. A l’étape S160, le processeur sécurisé SP1 refuse de signer la transaction. Cette étape est exécutée si l’utilisateur a rejeté la transaction, ou si un temps maximal d’attente de son accord a été dépassé, ou encore si le processeur sécurisé a trouvé que l’adresse qui lui est présentée est différente de celle présente dans le presse-papiers sécurisé. L’homme de l’art notera ce que mode de réalisation du presse-papiers sécurisé utilise la mémoire de presse-papiers non sécurisée du processeur d'application comme mémoire de stockage intermédiaire de la donnée ADD, avant de transmettre son contenu au processeur sécurisé pour qu’il la stocke dans la mémoire de presse-papiers sécurisé. Dans des variantes, la donnée ADD avant d’être transmise au processeur sécurisé, pourrait être stockée dans une autre zone mémoire que celle servant comme mémoire de presse-papiers non sécurisé. Dans d’autres variantes, la donnée pourrait être chiffrée avant d’être communiquée au processeur sécurisé via le bus DB1. Dans le mode de réalisation de la FIG. 9 , la fonction de presse-papiers sécurisé SCB1 est utilisée pour copier une adresse en tant que partie d’image IMADD. Les étapes déjà décrites en relation avec la FIG. 8 sont désignées par les mêmes références. A l’étape S100, l’utilisateur va dans une application source d’information ISAP. A une étape S202, l’utilisateur sélectionne l’adresse ADD d’un compte de cryptoactifs en tant que partie d’image IMADD, et active un fonction NSCB du processeur sécurisé, de copie d’une image dans le presse-papiers non sécurisé. A une étape S203, le processeur d’application AP1 lit dans son tampon d’image FBUF1 la partie d’image IMADD. A une étape S204, le processeur d’application AP1 stocke la partie d’image IMADD dans la mémoire de presse-papiers CB1. A une étape S209, l’utilisateur active la fonction SCB1 de copie dans le presse-papiers sécurisé. A l’étape S110, le processeur d’application AP1 établit une communication avec le processeur sécurisé SP1. A une étape S211, le processeur d’application AP1 transmet la partie d’image IMADD au processeur sécurisé SP1. A une étape S212, le processeur sécurisé SP1 stocke la partie d’image IMADD dans la mémoire de presse-papiers sécurisé CB2 et l’affiche sur la zone d’affichage sécurisé SD, pour que l’utilisateur puisse la vérifier. Comme précédemment, l’accord de l’utilisateur peut ici être requis pour valider l’enregistrement de l’adresse ADD dans le presse-papiers sécurisé. Cet accord est de préférence donné par l’intermédiaire d’un organe sécurisé comme le bouton B. L’utilisateur répète ensuite les étapes S102, S103 et S104 décrites en relation avec la FIG. 8 pour copier l’adresse ADD en tant que donnée de type texte dans le presse-papiers non sécurisé CB1 du processeur d'application. A l’étape S115, l’utilisateur va dans l’application compagnon CAP. A l’étape S120, le processeur d’application AP1, à la demande de l’utilisateur, colle l’adresse ADD dans l’application compagnon CAP à partir de la mémoire de presse-papiers non sécurisé CB1, comme précédemment décrit. A une étape S125, l’utilisateur complète le descriptif de la transaction dans l’application compagnon CAP et demande l’exécution de la transaction. A l’étape S135, le processeur d’application AP1 exécutant l’application compagnon CAP envoie au processeur sécurisé SP1 le descriptif de la transaction devant être signée et comprenant l’adresse ADD. A une étape S240 illustrée sur la FIG. 10 , le processeur sécurisé SP1 exécutant l’application de portefeuille matériel WAP affiche sur la zone d’affichage sécurisé SD le descriptif de la transaction comprenant l’adresse ADD, ainsi que la partie d’image IMADD, et demande à l’utilisateur de valider la transaction. A une étape S245, l’utilisateur vérifie que l’adresse ADD dans le descriptif de la transaction et l’adresse ADD figurant dans la partie d’image IMADD sont identiques, et valide la transaction, sinon indique au processeur sécurisé qu’il veut l’annuler. A l’étape S150, le processeur sécurisé SP1 exécutant l’application de portefeuille matériel WAP signe la transaction et envoie la signature au processeur d'application AP1. A une étape S155, le processeur d’application AP1 exécutant l’application compagnon CAP place la transaction sur la blockchain. A l’étape S160, le processeur sécurisé SP1 refuse de signer la transaction si un temps maximal d'attente de la validation de l’utilisateur est dépassé ou si l'utilisateur a indiqué qu’il annulait la transaction. Comme le précédent, ce mode de réalisation est susceptible de variantes en ce qui concerne le stockage de la partie d’image IMADD avant son transfert au processeur sécurisé. Par ailleurs, le processeur sécurisé pourrait appliquer un traitement OCR à la partie d’image IMADD pour en extraire l’adresse ADD en tant que donnée de type texte, puis exécuter l’étape de comparaison S136 qui a été décrite en relation avec la FIG. 8 et qui est absente dans l’organigramme de la FIG. 9 . La FIG. 11 montre un mode de réalisation d’un terminal TL2 configuré pour mettre en œuvre le procédé de presse-papiers sécurisé SCB2, dans lequel l’intégralité d’une image IMG1 affichée par le processeur d'application est transférée au processeur sécurisé. Le terminal TL2 présente la même structure que le terminal TL1 qui ne sera pas décrite de nouveau. Il se distingue du terminal TL1 en ce que le système d’exploitation OS1 du processeur d'application comporte, en sus des fonctions de presse-papiers non sécurisé NSCB et de presse-papiers sécurisé SCB1a, une fonction SCB2a de presse-papiers sécurisé SCB2. Cette fonction SCB2a est prévue pour coopérer avec une fonction complémentaire SCB2b prévue dans le système d’exploitation OS2 du processeur sécurisé. Comme autre différence, le processeur sécurisé SP1 comporte dans sa mémoire non volatile une zone de mémoire système SMEM2 prévue pour recevoir copie d’une partie de la zone mémoire système SMEM1 du processeur sécurisé contenant les données système associées à l’image IMG1 transférée par le processeur d'application au processeur sécurisé lorsque l’utilisateur active la fonction de copie SCB2. L’activation de la fonction de copie SCB2 dans le presse-papiers sécurisé CB2 est comme précédemment sous le contrôle du processeur d'application, qui affiche par exemple l’option « copie SCB2 » dans le menu ECBM de presse-papiers étendu, comme illustré sur la FIG. 7 modifiée ou sur la FIG. 10 . L’utilisateur peut choisir dans le menu ECBM entre le presse-papiers non sécurisé, le presse-papiers sécurisé SCB1 ou le presse-papiers sécurisé SCB2. L’activation du presse-papiers sécurisé SCB2 conduit le processeur d'application à transférer au processeur d'application, via le bus DB1, l’intégralité de l’image IMG1 affichée, qui se trouve dans le tampon d’image FBUF1. Le processeur d'application transfère ensuite au processeur sécurisé les données système correspondantes qu’il détient dans sa mémoire système SMEM1. Le processeur sécurisé stocke l’image IMG1 dans son tampon d’image FBUF2 et les données extraites de la mémoire système SMEM1 dans sa propre mémoire système SMEM2. Le processeur sécurisé prend ensuite le contrôle de l’intégralité de l’écran D3 ainsi que le contrôle du panneau tactile TMD en conférant au signal SEL la valeur appropriée, puis affiche l’image IMG1 et invite l’utilisateur, par un message flottant ou escamotable, à sélectionner dans cette image la partie qui l’intéresse. Il est à noter que lorsque l’utilisateur active la fonction de copie dans le presse-papiers sécurisé SCB2, le basculement de l’image IMG1 affichée par le processeur d'application à la même image IMG1 affichée par le processeur sécurisé qui a pris le contrôle de l’écran D3, n’est pas perceptible par l’utilisateur. Afin de rassurer l’utilisateur et lui confirmer qu’il se trouve dans un espace sécurisé où il peut extraire la donnée ADD ou découper la partie d’image IMADD qui l’intéresse, le processeur sécurisé peut allumer le témoin visuel LD, ou activer tout autre moyen permettant à l’utilisateur de savoir que l’image affichée est sous le contrôle du processeur sécurisé. L’usage du presse-papiers sécurisé SCB2 dans le cadre de la préparation et de l’exécution d’une transaction de cryptoactifs sera mieux compris en se référant aux organigrammes des figures 12 et 13 qui décrivent deux exemples de préparation et d’exécution d’une transaction de cryptoactifs. Dans le mode de réalisation de la FIG. 12 , la fonction de presse-papiers sécurisé SCB2 est utilisée pour copier une adresse ADD en tant que donnée de type texte. Les étapes déjà décrites en relation avec la FIG. 8 ou 9 sont désignées par les mêmes références. A l’étape S100, l’utilisateur va dans une application source d’information ISAP. A une étape S300, l’utilisateur active la fonction SCB2 de copie dans le presse-papiers sécurisé. A l’étape S110, le processeur d’application AP1 établit une communication avec le processeur sécurisé SP1. A une étape S310, le processeur d’application AP1 transfère au processeur sécurisé SP1 l’image IMG1 présente dans le tampon d’image FBUF1. A une étape S311, le processeur sécurisé SP1 stocke l’image IMG1 dans le tampon d’image FBUF2. A une étape S312, le processeur d’application AP1 transfère au processeur sécurisé SP1 des données système liées à l’image IMG1 présentes dans la mémoire système SMEM1. A une étape S313, le processeur sécurisé SP1 stocke les données système dans sa mémoire système SMEM2 . A une étape S320, le processeur sécurisé SP1, après avoir pris le contrôle de l’écran D3, affiche sur l’écran D3 l’image copiée IMG1 à la place de l'image originale. Comme illustré sur la FIG. 10 , l’intégralité de l’écran devient dans ce cas la zone d’affichage sécurisé SD, comme le montre l’indicateur VM. A une étape S322, l’utilisateur sélectionne dans cette image l’adresse ADD d’un compte de cryptoactifs en tant que données de type texte, et valide sa sélection. Les données tactiles sont ici reçues par le processeur sécurisé qui a pris le contrôle du circuit de dérivation DMUX1. A une étape S340, le processeur sécurisé SP1 lit dans la mémoire système SMEM2 l’adresse ADD sélectionnée par l’utilisateur. A l’étape S112, le processeur sécurisé SP1 stocke l’adresse ADD dans la mémoire de presse-papiers sécurisé CB2 et l’affiche sur la partie inférieure de la zone d’affichage sécurisé SD. Le résultat est donc le même qu’à l’étape S112 de la FIG. 8 mais à partir d'une extraction des données ADD faite dans une image affichée par le processeur sécurisé. Il sera toutefois noté que comme la sélection de l’adresse ADD est faite par le processeur sécurisé, l’affichage de l’adresse ADD dans la partie inférieure de la zone d’affichage sécurisé SD pourrait ne pas être prévu. De même, l’accord de l’utilisateur via un organe sécurisé pourrait ne pas être requis pour valider l’enregistrement de l’adresse ADD dans le presse-papiers sécurisé. A une étape S345, l’utilisateur retourne dans l’application source d’information ISAP. L’utilisateur répète ensuite les étapes S102, S103 et S104 décrites en relation avec la FIG. 8 , pour copier l’adresse ADD en tant que donnée de type texte dans le presse-papiers non sécurisé. Après cette étape, le procédé comprend les étapes S115, S120, S125, S135, S136, S140, S145, S150, S155 et S160 déjà décrites en relation avec la FIG. 8 . Dans le mode de réalisation de la FIG. 13 , la fonction de presse-papiers sécurisé SCB2 est utilisée pour copier une adresse en tant que partie d’image IMADD. Les étapes déjà décrites en relation avec les figures 8, 9 et 12 sont désignées par les mêmes références. A l’étape S100, l’utilisateur va dans une application source d’information ISAP. A une étape S300, l’utilisateur active la fonction SCB2 de copie dans le presse-papiers sécurisé avec l’option « copie d’image ». A l’étape S110, le processeur d’application AP1 établit une communication avec le processeur sécurisé SP1. A une étape S310, le processeur d’application AP1 transfère au processeur sécurisé SP1 l’image IMG1 présente dans le tampon d’image FBUF1. A une étape S311, le processeur sécurisé SP1 stocke l’image IMG1 dans le tampon d’image FBUF2. A l’étape S320, le processeur sécurisé SP1 prend le contrôle de l’écran et affiche sur l’écran D3 l’image copiée IMG1 à la place de l'image originale. Comme illustré sur la FIG. 10 , l’intégralité de l’écran devient dans ce cas la zone d’affichage sécurisé SD, comme le montre l’indicateur VM. A une étape S422, l’utilisateur sélectionne dans l’image copiée l’adresse ADD d’un compte de cryptoactifs en tant que partie d’image IMADD, et valide sa sélection, qui est reçue par le processeur sécurisé sous forme de données tactiles TDT. A l’étape S341, le processeur sécurisé SP1 au moyen de la fonction TRIM ( FIG. 11 ) de découpe ou de rognage d’image, découpe la partie d’image IMADD sélectionnée par l’utilisateur dans l’image copiée IMG1. A l’étape S212, le processeur sécurisé SP1 stocke la partie d’image IMADD dans la mémoire de presse-papiers sécurisé CB2 et l’affiche sur la partie inférieure de la zone d’affichage sécurisé SD. Le résultat est donc le même qu’à l’étape S212 de la FIG. 9 mais à partir d'une extraction des données ADD faite dans une image affichée par le processeur sécurisé. Comme précédemment, l’affichage de l’adresse ADD dans la partie inférieure de la zone d’affichage sécurisé SD pourrait ne pas être prévu. De même, l’accord de l’utilisateur pourrait ne pas être requis pour valider l’enregistrement de l’adresse ADD dans le presse-papiers sécurisé. Le procédé comprend ensuite la succession des étapes S345, S102, S103, S104, S115, S120, S125, S135, S240, S245, S150, S155, et S160 déjà décrites en relation avec la FIG. 9 . Dans un mode de réalisation du presse-papiers sécurisé SCB1 ou du presse-papiers sécurisé SCB2, l’utilisateur place d’abord le processeur sécurisé dans un mode actif au moyen du commutateur bistable S. Une fois dans le mode actif, le processeur sécurisé active un canal de communication avec le processeur d'application via le bus DB1 de façon à ce que les deux processeurs soient prêts à communiquer. L’utilisateur indique ensuite au processeur sécurisé qu’il veut procéder à une copie dans le presse-papiers sécurisé SCB1 ou SCB2 en appuyant sur le bouton B qui est sous le contrôle du processeur sécurisé. Le processeur sécurisé envoie alors au processeur d'application une demande de copie dans le presse-papiers sécurisé, à la suite de quoi le processeur d'application affiche l’icône de fonction SBC1 ou SCB2 (ou les deux) dans le menu de presse-papiers étendu ECBM (« Extended ClipBoard Menu ») comme montré sur la FIG. 7 ou sur la FIG. 10 . Ce mode d’activation permet au processeur sécurisé de contrôler le déclenchement du processus de copie dans le presse-papiers sécurisé et de s’assurer que la demande de copie émane bien de l’utilisateur. Cela permet par exemple d’éviter qu’un programme malveillant initie lui-même la copie dans le presse-papiers sécurisé et/ou procède à une boucle sans fin d’enregistrements dans le presse-papiers sécurisé. A cet effet, le processeur sécurisé peut être configuré pour n’accepter qu’une seule action de stockage d’une donnée après une action de l’utilisateur sur le bouton B suivie d’une action sur l’icône de fonction SBC1 ou SCB2 affiché par le processeur d'application. Il sera noté que plusieurs autres boutons comme le bouton B ou d’autres commutateurs comme le commutateur S peuvent être prévus pour les besoins de mise en œuvre du presse-papiers sécurisé. Le processeur sécurisé, une fois placé dans le mode actif, peut aussi contrôler des données fournies par un clavier tactile dans lequel sont prévues des touches de fonction dédiées au presse-papiers sécurisé, qui remplacent le bouton B. Un clavier tactile dédié au processeur sécurisé peut aussi être prévu. La FIG. 14 montre un mode de réalisation d’un terminal TL3 configuré pour mettre en œuvre la fonction de presse-papiers sécurisé SCB3 avec l’option copie de texte ou l’option copie d’image. Le terminal TL3 présente la même structure que les terminaux TL1, TL2 qui ne sera pas décrite de nouveau. Le terminal TL3 se distingue du terminal TL2 en ce que le système d’exploitation OS2 du processeur sécurisé comporte, en sus des fonctions de presse-papiers sécurisé SCB1b, SCB2b qui ont été ici conservées mais pourraient être omises, la fonction de presse-papiers sécurisé SCB3. Cette fonction est indépendante du processeur d'application qui ne possède donc aucune fonction correspondante dans son système d’exploitation OS1. En effet, comme expliqué plus haut, ce mode de réalisation de la fonction de presse-papiers sécurisé repose sur la reconstitution de l’image IMG1 affichée par le processeur d'application à son insu, par prélèvement des données d’image fournies par le processeur d'application à l’écran D3. L’utilisateur va ensuite sélectionner dans cette image, avec l’aide exclusive du processeur sécurisé et sans intervention du processeur d'application, une adresse ADD de type texte ou une partie d’image IMADD comprenant cette adresse. De ce fait, la fonction de copie SCB3 ne peut pas être activée depuis un bouton virtuel affiché par l’écran tactile D3/TMD, puisqu’elle opère à l’insu du processeur d'application. Un bouton spécifique connecté au processeur sécurisé est donc de préférence prévu pour activer la fonction SCB3. Par exemple, comme illustré sur la FIG. 14 , le bouton B peut de nouveau être utilisé comme bouton d’activation de la fonction SCB3. Il sera noté que cet usage du bouton B n’empêche pas de l’utiliser ultérieurement comme bouton de validation d’une transaction, bien que d’autres boutons similaires pourraient aussi être prévus. Dans un mode de réalisation, le processeur sécurisé a été préalablement placé dans le mode actif décrit plus haut, au moyen du commutateur S. Comme autre différence, le processeur sécurisé SP1 est équipé d’un circuit de décodage DECCT d’un tampon d’image intermédiaire FBUF3. Le circuit de décodage DECCT est utilisé comme circuit espion et comporte une entrée reliée à la première entrée du circuit de sélection MUX, qui reçoit les données d’image IDT1 au format MIPI DSI fournies par le processeur d'application. Ces données sont décodées par le circuit DECCT qui en extrait des données de type pixel PIX1, soit celles fournies par le processeur d'application à son pilote d’affichage DD1, et analyse ces données pour en déduire le début et la fin de l’image IMG1. Le circuit DECCT reconstitue ainsi ligne après ligne l’image IMG1 qu’il stocke dans le tampon intermédiaire FBUF3. Lorsque l’image IMG1 a été entièrement reconstituée, le processeur sécurisé la transfère dans le tampon FBUF2, prend le contrôle de l’écran D3 par l’intermédiaire du circuit de sélection MUX, configure le circuit DMUX1 pour recevoir les données tactiles et invite l’utilisateur à sélectionner la zone de son choix. Le processeur sécurisé comporte aussi une fonction TRIM de découpage ou rognage de l’image reconstituée, similaire à celle utilisée par le terminal TL2 de la FIG. 11 , et fournissant la partie d’image IMADD. Le processeur sécurisé comporte aussi une fonction OCR applicable à l’option copie texte, lui permettant d’extraire une donnée de type texte, notamment une adresse ADD, de la partie d’image IMADD sélectionnée par l’utilisateur. L’usage du presse-papiers sécurisé SCB3 dans le cadre de la réalisation d’une transaction de cryptoactifs sera mieux compris en se référant aux organigrammes des figures 15 et 16 qui décrivent deux exemples de préparation et d’exécution d’une transaction de cryptoactifs. Dans le mode de réalisation de la FIG. 15 , la fonction de presse-papiers sécurisé SCB3 est utilisée pour copier une adresse ADD en tant que donnée de type texte. Les étapes déjà décrites en relation avec les figures 8, 9, 12, 13 sont désignées par les mêmes références. A l’étape S100, l’utilisateur va dans une application source d’information ISAP. A une étape S400, l’utilisateur active avec le bouton B la fonction SCB3 de copie dans le presse-papiers sécurisé. A une étape S410, le circuit DECCT prélève les données d’image IDT1 fournies par le processeur d’application AP1, les décode et reconstitue l’image IMG1 dans le tampon d’image intermédiaire FBUF3. A une étape S420, le processeur sécurisé SP1 transfère l’image copiée IMG1 dans le tampon d’image FBUF2. A l’étape S320, le processeur sécurisé SP1 affiche sur l’écran D3 l’image copiée IMG1 à la place de l'image originale. Comme illustré sur la FIG. 10 , l’intégralité de l’écran devient dans ce cas la zone d’affichage sécurisé SD, comme le montre l’indicateur VM. A une étape S422, l’utilisateur sélectionne dans l’image copiée l’adresse ADD d’un compte de cryptoactifs en tant que partie d’image IMADD, et valide sa sélection. A l’étape S341, le processeur sécurisé SP1 avec la fonction TRIM découpe la partie d’image IMADD dans l’image copiée IMG1 en fonction de la sélection par USER. A une étape S443, le processeur sécurisé SP1 extrait l’adresse ADD de la partie d’image IMADD avec la fonction OCR. A l’étape S112, le processeur sécurisé SP1 stocke l’adresse ADD dans la mémoire de presse-papiers sécurisé CB2 et l’affiche sur la partie inférieure de la zone d’affichage sécurisé SD, le résultat étant similaire à celui des étapes S112 des autres modes de réalisation du procédé, mais étant obtenu d’une différente manière. Ce mode de réalisation étant sécurisé de bout en bout, l’affichage de l’adresse copiée sur la partie inférieure de la zone d’affichage sécurisé SD est ici purement optionnel bien que pouvant être prévu pour des raisons d’information de l’utilisateur. De même, l’accord de l’utilisateur pour valider l’enregistrement de l’adresse ADD dans le presse-papiers sécurisé est purement optionnel sur le plan de la sécurité, mais peut être prévu pour des raison ergonomiques. Les étapes suivantes ont déjà été décrites. Avant d’être exécutées, le processeur sécurisé rend temporairement le contrôle de l’écran D3 au processeur d'application. A l’étape S345, l’utilisateur retourne dans l’application source d’information ISAP. L’utilisateur répète ensuite les étapes S102, S103 et S104 décrites en relation avec la FIG. 8 pour copier l’adresse ADD en tant que donnée de type texte dans le presse-papiers non sécurisé. A l’étape S115, l’utilisateur va dans l’application compagnon CAP. A l’étape S120, le processeur d’application AP1, à la demande de l’utilisateur, colle l’adresse ADD dans l’application compagnon CAP à partir de la mémoire de presse-papiers non sécurisé CB1. A l’étape S125, l’utilisateur complète le descriptif de la transaction dans l’application compagnon CAP et demande l’exécution de la transaction. A l’étape S135, le processeur d’application AP1 exécutant l’application compagnon CAP envoie au processeur sécurisé SP1 le descriptif de la transaction devant être signée et comprenant l’adresse ADD. A l’étape S136, le processeur sécurisé SP1 exécutant l’application de portefeuille matériel WAP vérifie que l’adresse ADD reçue est identique à l’adresse ADD dans la mémoire de presse-papiers sécurisé CB2. A l’étape S140, le processeur sécurisé SP1 exécutant l’application de portefeuille matériel WAP affiche sur la zone d’affichage sécurisé SD le descriptif de la transaction contenant l’adresse ADD, et affiche optionnellement l’adresse ADD présente dans le presse-papiers sécurisé, puis demande à l’utilisateur de valider la transaction. A l’étape S145, l’utilisateur vérifie optionnellement que l’adresse ADD affichée sur la zone d’affichage non sécurisée NSD et l’adresse ADD affichée sur la zone d’affichage sécurisé SD sont identiques, avant de valider la transaction. A l’étape S150, le processeur sécurisé SP1 exécutant l’application de portefeuille matériel WAP signe la transaction et envoie la signature au processeur d’application AP1. A l’étape S155, le processeur d’application AP1 exécutant l’application compagnon CAP place la transaction sur la blockchain. Si le temps d'attente de l’utilisateur a été dépassé, ou si l'utilisateur annule la transaction, ou encore si les adresses ADD affichées sont différentes, le processeur sécurisé SP1 refuse de signer la transaction à l’étape S160. Dans une variante du procédé qui vient d’être décrit, le processeur sécurisé applique un traitement OCR à l’ensemble de l’image IMG1 avant de proposer à l’utilisateur d’y découper les données de type texte qu’il souhaite. Dans le mode de réalisation de la FIG. 16 , la fonction de presse-papiers sécurisé SCB3 est utilisée pour copier une adresse en tant que partie d’image IMADD. Les étapes déjà décrites en relation avec les figures 8, 9, 12, 13, 15 sont désignées par les mêmes références. Les premières étapes S100, S400, S410, S420, S320, S422, S341 du procédé de la FIG. 16 sont les mêmes que celles du procédé de la FIG. 15 . Après l’étape de découpe S341, l’étape S443 de traitement OCR est supprimée. Après l’étape S341, la partie d’image IMADD est stockée dans la mémoire de presse-papiers sécurisé CB2 à l’étape S212 et est affichée sur la partie inférieure de la zone d’affichage sécurisé SD. Ce mode de réalisation étant également sécurisé de bout en bout, l’affichage de la partie d’image IMADD sur la partie inférieure de la zone d’affichage sécurisé SD est ici également optionnel, ainsi que l’accord de l’utilisateur pour valider l’enregistrement de la partie d’image IMADD dans le presse-papiers sécurisé. Les étapes qui suivent S345, S102, S103, S104, S115, S120, S125, S135, S240, S245, S150, S155 et S160 sont identiques à celles du procédé de la FIG. 13 . Il apparaîtra à l’homme du métier que le procédé de presse-papiers sécurisé qui vient d’être décrit est susceptible de diverses autres variantes. Bien que ce procédé ait été conçu en relation avec l’intégration d’une fonction de portefeuille matériel dans un terminal, afin de rendre plus sûres la préparation et l’exécution d’une transaction, la fonction de presse-papiers sécurisé qui vient d’être décrite est susceptible de diverses autres applications. Par ailleurs, le processeur d'application peut être tout composant connu de type microcontrôleur ou ensemble de composants formant un système sur puce semiconducteur ou « Soc » (« System on Chip »). Le processeur sécurisé peut lui-même être un élément sécurisé sur une puce de semiconducteur, auquel ont été adjoints certains élément périphériques s’il ne les inclut pas d’origine. Le processeur sécurisé peut également être un environnement d'exécution de confiance TEE ("Trusted Execution Environment") du processeur d'application. L’architecture de terminal mobile qui vient d’être décrite est elle-même susceptible de nombreuses variantes d’exécution. Dans une variante TL4 du terminal montrée sur la FIG. 17 , le circuit de sélection MUX a été remplacé par un processeur auxiliaire AUXP qui pilote l’écran D3 par l’intermédiaire d’un pilote d’affichage DD3 fournissant des données d’image au format MIPI DSI. Le processeur auxiliaire AUXP reçoit les données PIX1 de type pixel fournies par le tampon FBUF1 du processeur d'application, et les données PIX2 de type pixel fournies par le tampon FBUF2 du processeur sécurisé. Il est configuré par programmation pour former une sorte de multiplexeur logiciel sous le contrôle du processeur sécurisé et donnant la priorité aux données de type pixel fournies par ce dernier. Dans une variante TL5 du terminal montrée sur la FIG. 18 , le processeur sécurisé SP1 est un environnement d'exécution de confiance TEE au sein du processeur d'application AP1. Le bus de donnée DB1 est remplacé par une mémoire d’échange EXMEM par laquelle l’environnement TEE peut recevoir les données fournies par le processeur d'application. Dans une variante TL6 du terminal montrée sur la FIG. 19 , on combine la prévision d’un processeur auxiliaire de la FIG. 17 comme multiplexeur logiciel sous le contrôle du processeur sécurisé, et la réalisation du processeur sécurisé sous la forme d’un environnement de confiance TEE du processeur d'application. Dans une variante TL7 du terminal montrée sur la FIG. 20 , le processeur d'application AP1 est relié à un écran D4 qui lui est propre et le processeur sécurisé SP1 est relié à un écran D5 qui lui est propre. Le terminal TL7 est équipé d’un pavé tactile TPD et d’un clavier KBD distincts des écrans D4 et D5. Le pavé tactile TPD fournit des données tactiles TDT et le clavier KBD fournit des données de type texte TXDT, qui sont fournies à l’un ou l’autre des processeurs par un circuit de dérivation DMUX2 double canal sous le contrôle du processeur sécurisé et commandé par un signal SEL3. Les modes de réalisation SCB1, SCB2, SCB3 qui viennent d’être décrits du presse-papiers sécurisé permettent à un utilisateur de sauvegarder une adresse d’un compte de cryptoactifs à un moment précédant l’engagement de la transaction au moyen de l’application compagnon. L’action de copie de l’adresse ADD ou de son image IMADD étant engagée à un instant arbitraire précédant l’appel à l’application compagnon, elle est moins susceptible d’attaque par un fraudeur, à moins que celui-ci n’ait pris le contrôle total du terminal, ce qui reste très peu probable. Quoi qu’il en soit, un contrôle total du terminal concernera le processeur d'application et ne pourra pas atteindre le processeur sécurisé. Ainsi, le mode de réalisation SCB3 du presse-papiers sécurisé restera lui-même inviolable puisque totalement indépendant du processeur d'application. ANNEXE faisant partie intégrante de l description : description complète des figures 8, 9, 12,13, 15, 16 FIG. 8 : (S100) USER va dans ISAP (S102) USER sélectionne l’adresse ADD d’un compte en tant que données de type texte, et active la fonction NSCB de copie dans le presse-papiers non sécurisé (S103) AP1 lit dans SMEM1 l’adresse sélectionnée ADD (S104) AP1 stocke ADD dans la mémoire de presse-papiers C’1 (S109) L'utilisateur active la fonction SCB1 de copie dans le presse-papiers sécurisé (S110) AP1 établit une communication avec SP1 (S111) AP1 transmet ADD à SP1 (S112) SP1 stocke ADD dans CB2 et l’affiche sur SD (S115) USER va dans CAP (S120) AP1-USER colle ADD dans CAP à partir de la mémoire presse-papiers non sécurisé CB1 (S125) USER complète le descriptif de la transaction dans CAP et demande l’exécution de la transaction (S135) AP1-CAP envoie à SP1 le descriptif de la transaction devant être signée et comprenant ADD (S136) SP1-WAP vérifie que ADD reçue est identique à ADD dans CB2 (S140) SP1-WAP affiche sur SD le descriptif de la transaction et optionnellement l’adresse copiée ADD et demande à USER de valider la transaction (S145) USER vérifie optionnellement que ADD affichée sur NSD et ADD affichée sur SD sont identiques avant de valider la transaction (S150) SP1-WAP signe la transaction et envoie la signature à AP1 (S155) AP1-CAP place la transaction sur la blockchain (S160) SP1 refuse de signer la transaction si : - Temps d'attente dépassé ou action de l'utilisateur, ou - Adresses ADD différentes FIG. 9 : (S100) USER va dans ISAP (S202) USER sélectionne l’adresse ADD d’un compte en tant que partie d’image IMADD, et active la fonction NSCB de copie d’image dans le presse-papiers non sécurisé (S203) AP1 lit dans FBUF1 la partie d’image IMADD (S204) AP1 stocke IMADD dans la mémoire de presse-papiers CB1 (S209) L'utilisateur active la fonction SCB1 de copie dans le presse-papiers sécurisé (S110) AP1 établit une communication avec SP1 (S211) AP1 transmet IMADD à SP1 (S212) SP1 stocke IMADD dans CB2 et l’affiche sur SD (S102) (S103) (S104) (S115) USER va dans CAP (S120) AP1-USER colle ADD dans CAP à partir de la mémoire presse-papiers non sécurisé CB1 (S125) USER complète le descriptif de la transaction dans CAP et demande l’exécution de la transaction (S135) AP1-CAP envoie à SP1 le descriptif de la transaction devant être signée et comprenant ADD (S240) SP1-WAP affiche sur SD le descriptif de la transaction et IMADD et demande à USER de valider la transaction (S245) USER vérifie que ADD dans le descriptif de la transaction et ADD dans IMADD sont identiques, et valide la transaction (S150) SP1-WAP signe la transaction et envoie la signature à AP1 (S155) AP1-CAP place la transaction sur la blockchain (S160) SP1 refuse de signer la transaction si temps d'attente dépassé ou action de l'utilisateur FIG. 12 : (S100) USER va dans ISAP (S300) USER active la fonction SCB2 de copie dans le presse-papiers sécurisé (S110) AP1 établit une communication avec SP1 (S310) AP1 transfère à SP1 l’image IMG1 présente dans FBUF1 (S311) SP1 stocke IMG1 dans FBUF2 (S312) AP1 transfère à SP1 des données système liées à IMG1 présentes dans SMEM1 (S313) SP1 stocke les données système dans SMEM2 (S320) SP1 affiche sur D3 l’image copiée IMG1 à la place de l'image originale (S322) USER sélectionne l’adresse ADD d’un compte en tant que données de type texte, et valide sa sélection (S340) SP1 lit dans SMEM2 l’adresse sélectionnée ADD (S112) SP1 stocke ADD dans la mémoire de presse-papiers sécurisé CB2 et l’affiche sur SD (S345) USER retourne dans ISAP (S102) (S103) (S104) (S115) USER va dans CAP (S120) AP1-USER colle ADD dans CAP à partir de la mémoire presse-papiers non sécurisé CB1 (S125) USER complète le descriptif de la transaction dans CAP et demande l’exécution de la transaction (S135) AP1-CAP envoie à SP1 le descriptif de la transaction devant être signée et comprenant ADD (S136) SP1-WAP vérifie que ADD reçue est identique à ADD dans CB2 (S140) SP1-WAP affiche sur SD le descriptif de la transaction et optionnellement l’adresse copiée ADD et demande à USER de valider la transaction (S145) USER vérifie optionnellement que ADD affichée sur NSD et ADD affichée sur SD sont identiques avant de valider la transaction (S150) SP1-WAP signe la transaction et envoie la signature à AP1 (S155) AP1-CAP place la transaction sur la blockchain (S160) SP1 refuse de signer la transaction si : - Temps d'attente dépassé ou action de l'utilisateur, ou - Adresses ADD différentes FIG. 13 : (S100) USER va dans ISAP (S300) USER active la fonction SCB2 de copie dans le presse-papiers sécurisé (S110) AP1 établit une communication avec SP1 (S310) AP1 transfère à SP1 l’image IMG1 présente dans FBUF1 (S311) SP1 stocke IMG1 dans FBUF2 (S320) SP1 affiche sur D3 l’image copiée IMG1 à la place de l'image originale (S341) SP1 avec la fonction TRIM découpe IMADD dans l'image copiée IMG1 en fonction de la sélection par USER (S212) SP1 stocke IMADD dans la mémoire de presse-papiers sécurisé CB2 et l’affiche sur SD (S345) USER retourne dans ISAP (S102) (S103) (S104) (S115) USER va dans CAP (S120) AP1-USER colle ADD dans CAP à partir de la mémoire presse-papiers non sécurisé CB1 (S125) USER complète le descriptif de la transaction dans CAP et demande l’exécution de la transaction (S135) AP1-CAP envoie à SP1 le descriptif de la transaction devant être signée et comprenant ADD (S240) SP1-WAP affiche sur SD le descriptif de la transaction et IMADD et demande à USER de valider la transaction (S245) USER vérifie que ADD dans le descriptif de la transaction et ADD dans IMADD sont identiques, et valide la transaction (S150) SP1-WAP signe la transaction et envoie la signature à AP1 (S155) AP1-CAP place la transaction sur la blockchain (S160) SP1 refuse de signer la transaction si temps d'attente dépassé ou action de l'utilisateur FIG. 15 : (S100) USER va dans ISAP (S400) USER active avec le bouton B la fonction SCB3 de copie dans le presse-papiers sécurisé (S410) DECCT prélève les données d’image IDT1 fournies par AP1, les décode et reconstitue l’image IMG1 dans FBUF3 (S420) SP1 transfère l’image copiée IMG1 dans FBUF2 (S320) SP1 affiche sur D3 l’image copiée IMG1 à la place de l’image originale (S422) USER sélectionne dans l’image copiée IMG1 l’adresse ADD d’un compte en tant que partie d'image IMADD, et valide sa sélection (S341) SP1 avec la fonction TRIM découpe IMADD dans l’image copiée IMG1 en fonction de la sélection par USER (S443) SP1 avec la fonction OCR extrait ADD de la partie d'image IMADD (S112) SP1 stocke ADD dans la mémoire de presse-papiers sécurisé CB2 et l’affiche sur SD (S345) USER retourne dans ISAP (S102) (S103) (S104) (S115) USER va dans CAP (S120) AP1-USER colle ADD dans CAP à partir de la mémoire presse-papiers non sécurisé CB1 (S125) USER complète le descriptif de la transaction dans CAP et demande l’exécution de la transaction (S135) AP1-CAP envoie à SP1 le descriptif de la transaction devant être signé et comprenant ADD (S136) SP1-WAP vérifie que ADD reçue est identique à ADD dans CB2 (S140) SP1-WAP affiche sur SD le descriptif de la transaction et optionnellement l’adresse copiée ADD et demande à USER de valider la transaction (S145) USER vérifie optionnellement que ADD affichée sur NSD et ADD affichée sur SD sont identiques avant de valider la transaction (S150) SP1-WAP signe la transaction et envoie la signature à AP1 (S155) AP1-CAP place la transaction sur la blockchain (S160) SP1 refuse de signer la transaction si : - Temps d'attente dépassé ou action de l'utilisateur, ou - Adresses ADD différentes FIG. 16 : (S100) USER va dans ISAP (S400) USER active avec le bouton B la fonction SCB3 de copie dans le presse-papiers sécurisé (S410) DECCT prélève les données d’image IDT1 fournies par AP1, les décode et reconstitue l’image IMG1 dans FBUF3 (S420) SP1 transfère l’image copiée IMG1 dans FBUF2 (S320) SP1 affiche sur D3 l’image copiée IMG1 à la place de l’image originale (S422) USER sélectionne dans l’image copiée l’adresse ADD d’un compte en tant que partie d'image IMADD, et valide sa sélection (S341) SP1 avec la fonction TRIM découpe IMADD dans l'image copiée IMG1 en fonction de la sélection par USER (S212) SP1 stocke IMADD dans la mémoire de presse-papiers sécurisé CB2 et l’affiche sur SD (S345) USER retourne dans ISAP (S102) (S103) (S104) (S115) USER va dans CAP (S120) AP1-USER colle ADD dans CAP à partir de la mémoire presse-papiers non sécurisé CB1 (S125) USER complète le descriptif de la transaction dans CAP et demande l’exécution de la transaction et demande l’exécution de la transaction (S135) AP1-CAP envoie à SP1 le descriptif de la transaction devant être signé et comprenant ADD (S240) SP1-WAP affiche sur SD le descriptif de la transaction et IMADD et demande à USER de valider la transaction (S245) USER vérifie que ADD dans le descriptif de la transaction et ADD dans IMADD sont identiques, et valide la transaction (S150) SP1-WAP signe la transaction et envoie la signature à AP1 (S155) AP1-CAP place la transaction sur la blockchain (S160) SP1 refuse de signer la transaction si temps d'attente dépassé ou action de l'utilisateur Terminal électronique (TL1-TL7) comprenant, dans un même boîtier : - un processeur d’application (AP1), - des moyens de connexion (COMCT) du processeur d’application à un réseau public ou privé, - un processeur sécurisé (SP1) comprenant des moyens de calcul cryptographique, - une liaison de données (DB1, EXMEM) entre le processeur d’application et le processeur sécurisé (SP1), - au moins un dispositif d’affichage (D3), pour permettre au processeur d’application et au processeur sécurisé d’afficher des images, et - un dispositif de sélection (TMD, TPD) permettant à un utilisateur de sélectionner tout ou partie d’une image affichée par le processeur d’application sur le dispositif d’affichage, caractérisé en ce qu’il est configuré pour exécuter, sur demande de l’utilisateur, une fonction de copie (SCB1a, SCB1b, SCB2a, SCB2b, S112, S212) dans une mémoire (CB2) de presse-papiers sécurisé accessible uniquement au processeur sécurisé (SP1), de données (ADD, IMADD) sélectionnées par l’utilisateur dans une image affichée par le processeur d’application. Terminal selon la revendication 1, dans lequel le dispositif d’affichage (D3) comprend au moins une zone d’affichage sécurisé (SD) contrôlée par le processeur sécurisé (SP1), et dans lequel le processeur sécurisé est configuré pour afficher (S112, S212) sur la zone d’affichage sécurisé (SD) les données copiées dans la mémoire presse-papiers sécurisé (CB2). Terminal selon l’une des revendications 1 et 2, configuré pour, lors de l’exécution de la fonction de copie dans la mémoire (CB2) de presse-papiers sécurisé : - au moyen du processeur d’application (AP1), lire (S103) dans une mémoire système (SMEM1) du processeur d’application, des données de type texte (ADD) sélectionnées par l’utilisateur dans l’image affichée par le processeur d’application, et transférer (S111) les données de type texte au processeur sécurisé (SP1), et - au moyen du processeur sécurisé (SP1), stocker (S112) les données de type texte dans la mémoire (CB2) de presse-papiers sécurisé. Terminal selon l’une des revendications 1 à 3, dans lequel le processeur d’application (AP1) est configuré pour envoyer au processeur sécurisé (SP1) une demande (S135) de signature cryptographique de données fournies par le processeur d’application, et dans lequel le processeur sécurisé est configuré pour, en réponse à la demande de signature cryptographique : - déterminer (S136) si les données (ADD) présentes dans la mémoire de presse-papiers sécurisé sont identiques à des données (ADD) fournies par le processeur d’application, et - refuser (S160) de fournir la signature cryptographique si les données (ADD) présentes dans la mémoire de presse-papiers sécurisé ne sont pas identiques aux données (ADD) fournies par le processeur d’application. Terminal selon l’une des revendications 1 à 4, configuré pour, lors de l’exécution de la fonction de copie dans la mémoire de presse-papiers sécurisé : - au moyen du processeur d’application (AP1), lire (S203) dans une mémoire d’image (FBUF1) du processeur d’application, une partie d’image (IMADD) sélectionnée par l’utilisateur dans l’image affichée par le processeur d’application, et transférer (S211) au processeur sécurisé (SP1) la partie d’image (IMADD) sélectionnée par l’utilisateur, et - au moyen du processeur sécurisé (SP1), stocker (S212) la partie d’image (IMADD) dans la mémoire (CB2) de presse-papiers sécurisé. Terminal selon l’une des revendications 1 à 5, dans lequel le processeur d’application (AP1) est configuré pour envoyer au processeur sécurisé (SP1) une demande (S135) de signature cryptographique de données fournies par le processeur d’application, et dans lequel le processeur sécurisé (SP1) est configuré pour, en réponse à la demande de signature cryptographique : - présenter (S140, S240) sur le dispositif d’affichage les données (ADD, IMADD) présentes dans la mémoire de presse-papiers sécurisé, et - attendre une autorisation de l’utilisateur avant de fournir la signature cryptographique. Terminal selon l’une des revendications 1 à 6, configuré pour afficher simultanément (S140, S240) : - sur une première zone (NSD) du dispositif d’affichage (D3), des données fournies par le processeur d’application (AP1), et - sur une seconde zone (SD) du dispositif d’affichage (D3), des données (IMAD, ADD) fournies par le processeur sécurisé (SP1). Terminal selon la revendication 7, comprenant : - un premier pilote d’affichage (DD1) relié au processeur d’application (AP1), fournissant des premières données d’image (IDT1), - un second pilote d’affichage (DD2) relié au processeur sécurisé (SP1), fournissant des secondes données d’image (IDT2), - un circuit de sélection d’affichage (MUX) commandé (SEL) par le processeur sécurisé (SP1), comprenant une première entrée reliée à une sortie du premier pilote d’affichage (DD1) et une seconde entrée reliée à une sortie du second pilote d’affichage (DD2), et une sortie reliée au dispositif d’affichage (D3), et dans lequel le processeur sécurisé (SP1) est configuré pour commander (SEL) le circuit de sélection d’affichage (MUX) de manière à afficher sur la première zone (NSD) du dispositif d’affichage les données fournies par le processeur d’application (AP1) par l’intermédiaire du premier pilote d’affichage (DD1), et sur la seconde zone (SD) du dispositif d’affichage les données (IMAD, ADD) fournies par le processeur sécurisé (SP1) par l’intermédiaire du second pilote d’affichage (DD2). Terminal selon la revendication 7 comprenant un processeur auxiliaire (AUXP) pourvu d’un pilote d’affichage (DD3) relié au dispositif d’affichage (D3), le processeur auxiliaire étant relié au processeur d’application (AP1) et au processeur sécurisé (SP1) et commandé par le processeur sécurisé (SP1) pour afficher sur la première zone (NSD) du dispositif d’affichage (D3) les données fournies par le processeur d’application (AP1), et sur la seconde zone (SD) du dispositif d’affichage (D3) les données (IMAD, ADD) fournies par le processeur sécurisé (SP1). Terminal selon l’une des revendications 1 à 9, dans lequel le dispositif de sélection comprend un module tactile (TMD, TPD) relié au processeur d’application (AP1) et au processeur sécurisé (SP1) par l’intermédiaire d’un circuit de dérivation (DMUX1, DMUX2) de données tactiles, le circuit de dérivation étant configuré pour envoyer des données tactiles (TDT) au processeur d’application ou au processeur sécurisé en fonction d’une commande (SEL, SEL2) émise par le processeur sécurisé. Terminal selon l’une des revendication 1 à 10, dans lequel le processeur sécurisé (SP1) est un élément sécurisé en circuit intégré. Terminal (TL5, TL6) selon l’une des revendications 1 à 10, dans lequel le processeur sécurisé (SP1) est un environnement d’exécution de confiance (TEE1, TEE2) du processeur d’application (AP1). Terminal selon l’une des revendications 1 à 11, dans lequel le processeur sécurisé (SP1) est configuré pour exécuter une application de portefeuille matériel de cryptoactifs (WAP) et le processeur d’application (AP1) est configuré pour exécuter une application compagnon (CAP) prévue pour coopérer avec l’application de portefeuille matériel de cryptoactifs. Terminal selon la revendication 13, dans lequel : - le processeur d’application (AP1) exécutant l’application compagnon (CAP) est configuré pour envoyer au processeur sécurisé (SP1) une demande (S135) de signature cryptographique d’un descriptif d’une transaction incluant une adresse (ADD) de compte de cryptoactifs, et - le processeur sécurisé (SP1) exécutant l’application de portefeuille matériel (WAP) est configuré pour, avant de fournir la signature cryptographique, vérifier (S136) que l’adresse (ADD) de compte de cryptoactifs figurant dans le descriptif est identique à une adresse de compte de cryptoactifs présente dans la mémoire de presse-papiers sécurisé. Procédé pour conduire une transaction relative à des cryptoactifs, au moyen d’un terminal selon l’une des revendications 1 à 14, comprenant les étapes consistant à : - configurer le processeur sécurisé (SP1) pour qu’il exécute une application de portefeuille matériel de cryptoactifs (WAP), - prévoir dans une mémoire programme (NVM) du processeur d’application (AP1) une application compagnon (CAP) prévue pour coopérer avec l’application de portefeuille matériel de cryptoactifs, et une application source d’information (ISAP), - au moyen du processeur d’application (AP1) exécutant l’application source d’information (ISAP), afficher sur le dispositif d’affichage une image (IMG1) comprenant une adresse (ADD) d’un compte de cryptoactifs, - copier (S109-S112, S209, S211, S212) l’adresse (ADD, IMADD) de compte de cryptoactifs dans la mémoire (CB2) de presse-papiers sécurisé du processeur sécurisé (SP1), et - au moyen du processeur d’application (AP1) exécutant l’application compagnon, envoyer (S135) le descriptif de la transaction au processeur sécurisé (SP1) et lui demander de fournir une signature cryptographique de la transaction. Procédé selon la revendication 15, comprenant l’étape consistant à afficher (S112, S212) sur une zone d’affichage sécurisé (SD) du dispositif d’affichage (D3) contrôlée par le processeur sécurisé (SP1), l’adresse (IMADD, ADD) du compte de cryptoactifs copiée dans la mémoire presse-papiers sécurisé (CB2). Procédé selon l’une des revendications 15 et 16, comprenant les étapes consistant à, au moyen du processeur sécurisé (SP1) exécutant l’application de portefeuille matériel de cryptoactifs, vérifier (S136) que l’adresse de compte de cryptoactifs présente dans le descriptif de la transaction fourni par l’application compagnon (CAP) est identique à une adresse de compte de cryptoactifs présente dans la mémoire (CB2) de presse-papiers sécurisé, et ne pas fournir la signature cryptographique si les deux adresses sont différentes. Procédé selon l’une des revendications 15 à 17, comprenant les étapes consistant à, au moyen du processeur sécurisé (SP1) exécutant l’application de portefeuille matériel de cryptoactifs, afficher une partie d’image (IMADD) présente dans la mémoire (CB2) de presse-papiers sécurisé du processeur sécurisé (SP1), et attendre une autorisation de l’utilisateur avant de fournir la signature cryptographique.