FR 3156561 A1 20250613 FR 2313694 A 20231206 Procédé de gestion d’un processus d’approbation d’au moins une action par au moins un utilisateur, dans lequel le processus d’approbation de l’action est associé à une série de vues à l’attention de l’utilisateur, le procédé comprenant les étapes consistant à, au moyen d’un module de sécurité matériel (HSM1), générer la série de vues du processus d’approbation et communiquer la série de vues à un service orchestrateur (ORC, SRV1); au moyen du service orchestrateur, fournir à un dispositif de sécurité personnel (PSDi) tout ou partie de la série de vues. Figure 3 Procédé de gestion centralisée d’au moins un processus d’approbation d’une action La présente invention concerne un procédé de gestion d’un processus d’approbation d’une action par au moins un utilisateur, dans lequel le processus d’approbation de l’action est associé à une série de vues à l’attention de l’utilisateur, le procédé étant mis en œuvre au moyen d’un système comprenant un module de sécurité matériel, pour gouverner le processus d’approbation et initier la réalisation de l’action après son approbation par l’utilisateur, et un dispositif de sécurité personnel pour afficher des vues de la série de vues et recevoir l’approbation de l’utilisateur. Arrière-plan Ces dernières années, le développement des cryptomonnaies ou autres types de cryptoactifs gérés par des blockchains, 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 et publiques attachées à ces différents types de cryptoactifs. C’est ainsi que sont apparus les portefeuilles de cryptoactifs communément appelés "hardware wallets" ou « dispositifs de sécurité personnels » PSD (« Personal Security Devices »), permettant le stockage et la conservation de ces clés. Un dispositif de sécurité personnel est un dispositif matériel dont la fonction est de stocker les clés privées et publiques attachées à des comptes de cryptoactifs, et de signer des transactions au moyen de ces clés. La FIG. 1 montre schématiquement un exemple de dispositif de sécurité personnel PSD, par exemple le dispositif commercialisé par la demanderesse sous l’appellation "Ledger Blue" ou "Ledger Stax", et un dispositif hôte HDV exécutant une application compagnon HSW, par exemple l’application "Ledger Live" développée par la demanderesse. Le dispositif de sécurité personnel PSD ne pouvant pas se connecter directement à l’Internet pour des raisons de sécurité, il est associé au dispositif hôte HDV pour réaliser des transactions sur la blockchain. Le dispositif hôte HDV est par exemple un ordinateur, un téléphone mobile, une tablette ou équivalent. La connexion entre le dispositif de sécurité personnel PSD et le dispositif hôte HDV peut être de type USB ou Bluetooth par exemple. Lors de la première mise en service du dispositif de sécurité personnel PSD, celui-ci génère une clé maître K0 à partir de laquelle il pourra ultérieurement dériver des clés privées Kj de comptes de cryptoactifs, et fournit à l’utilisateur une phrase de récupération de 24 mots que celui-ci devra conserver sur un support physique approprié, par exemple une feuille de papier ou un support inaltérable tel une plaque de métal gravée, qu'il devra conserver en lieu sûr. Une fois relié au dispositif hôte, le dispositif de sécurité personnel PSD peut interagir avec le logiciel compagnon pour permettre à un utilisateur USR de réaliser des transactions sur une blockchain BCN ou sur des sites d’échange décentralisé. Le dispositif de sécurité personnel PSD peut par ailleurs communiquer avec un module de sécurité matériel HSM ("Hardware Security Module") situé dans un datacenter. Un tel module de sécurité matériel est également appelé en français "boîte noire transactionnelle" BTN (https://fr.wikipedia.org/wiki/Hardware_Security_Module). Il est généralement de règle que le module de sécurité matériel HSM ne stocke pas les clés privées de l’utilisateur et assure seulement le contrôle de l’authenticité du dispositif de sécurité personnel PSD, sa mise en service, la mise à jour de son système d’exploitation, le téléchargement de programmes d’application certifiés, etc. Toutefois, une exception à cette règle est faite dans le cas d’une gestion mutualisée de comptes de cryptoactifs, dans laquelle une demande de réalisation d’une transaction sur un compte de cryptoactif ne peut être exécutée qu’après avoir reçu l’accord d’au moins un utilisateur approbateur et satisfait une règle de gouvernance. Comme illustré sur la FIG. 2 , on prévoit dans ce cas un serveur d’administration de transaction SRV0 couplé à un module de sécurité matériel HSM0 ayant accès à une mémoire MEM dans laquelle est enregistrée la clé maître K0 permettant de générer les clés dérivées Kj des comptes de cryptoactifs dont la gestion est mutualisée. Le module de sécurité matériel HSM0 exécute un service de gouvernance GOV dans lequel ont été enregistrées des règles de gouvernance, permettant d’attribuer des rôles à des opérateurs OPi (OP 1 … OP N ), par exemple un rôle de copropriétaire ("shared-owner"), d’administrateur, d’approbateur de transaction, etc. Le serveur SRV0 héberge une plateforme d'administration de transaction TPF permettant à certains opérateurs de demander l’engagement d'actions. Il sera subsidiairement noté que pour assurer un très haut degré de sécurité aux titulaires de comptes faisant l’objet d’une telle gestion mutualisée, la demanderesse utilise des modules de sécurité matériels HSM hébergés dans des data centers sécurisés se trouvant en diverses parties du monde, et offrant une sécurité de très haut niveau conforme par exemple à la norme FIPS 140-2 niveau 3, et dans lesquels diverses sécurités matérielles et logicielles supplémentaires sont en outre mises en œuvre. Lorsqu’un opérateur OPi se connecte à la plateforme de transaction TPF et demande la réalisation d’une action, l’action demandée est communiquée au module de sécurité matériel HSM0. Le module HSM0 identifie la règle de gouvernance qui s’applique à l’action demandée, puis sollicite l’accord d'opérateurs OPi désignés par cette règle de gouvernance. Lorsque l’accord des opérateurs est reçu, le module HSM0 réalise l’action demandée ou initie sa réalisation. Si cette action est la réalisation d’une transaction, le module HSM0 signe la transaction avec la clé privée appropriée Kj puis la diffuse sur la blockchain concernée. Dans le cadre d’une telle gestion mutualisée de comptes de cryptoactifs, un opérateur OPi comprend généralement un utilisateur personne physique USRi équipé d’un dispositif de sécurité personnel PSDi qui est relié à un dispositif hôte HDVi. Le dispositif hôte HDVi permet au dispositif de sécurité personnel PSDi d’être relié au serveur d’administration SRV0 et au module de sécurité matériel HSM0. Dans ce type d’application, la réalisation d’actions nécessite généralement que les utilisateurs USRi naviguent dans des pages, ou « vues », qui s’affichent sur leurs dispositifs de sécurité personnels PSDi. De façon générale, à chaque action pouvant être réalisée est associé un processus d’approbation de l’action et au moins une règle de gouvernance. Le processus d’approbation de l’action est matérialisé par un ensemble de vues chaînées que chaque utilisateur USRi peut parcourir en faisant des choix, lui permettant de bifurquer, d’avancer ou de faire marche arrière, jusqu’à ce qu’il arrive à une vue finale qui clôture le processus d’approbation. Lorsque la vue finale est atteinte, la possibilité est offerte à l’utilisateur de donner ou non son accord sur l’action à réaliser, par exemple en appuyant sur un bouton d’approbation ou un bouton de refus. En définitive, comme un système de gestion mutualisée de comptes de cryptoactifs permet de réaliser diverses actions et qu’à chaque action est associée une série de vues permettant de mettre en œuvre le processus d’approbation de l’action, la mise en œuvre d’un tel système implique de gérer un très grand nombre de vues différentes. Or, il s’avère que les dispositifs de sécurité personnels PSDi ont parfois un espace mémoire limité qui limite le nombre de vues pouvant être générées et limite également la taille du programme leur permettant de générer de telles vues et de les lier entre elles. En effet, un dispositif de sécurité personnel comprend généralement un élément sécurisé (« secure element ») pour exécuter un tel programme, et un microcontrôleur pour assurer les communications avec le monde extérieur. Un élément sécurisé est une puce de semi-conducteur comprenant des moyens de calcul cryptographiques et mettant en œuvre diverses contre-mesures visant à contrer des attaques de fraudeurs, 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. En raison des nombreuses contre-mesures qu’il met en œuvre, l’espace mémoire d’un élément sécurisé est limité, qu’il s’agisse de sa mémoire non volatile ou de sa mémoire volatile . De plus, chaque mise à jour du service de gouvernance GOV du module HSM0 implique des mises à jour des dispositifs de sécurité personnels PSDi, pour que ceux-ci soient capables de générer de nouvelles séries de vues correspondant à de nouvelles actions offertes par le service de gouvernance. Il pourrait donc être souhaité de prévoir un procédé de gestion d’un processus d’approbation d’actions qui réduise considérablement l’espace mémoire nécessaire aux dispositifs de sécurité personnels pour la génération des vues permettant de mettre en œuvre le processus d’approbation. Résumé Des modes de réalisation concernent un procédé de gestion d’un processus d’approbation d’une action par au moins un utilisateur, dans lequel le processus d’approbation de l’action est associé à une série de vues à l’attention de l’utilisateur, le procédé étant mis en œuvre au moyen d’un système comprenant un module de sécurité matériel, pour gouverner le processus d’approbation et initier la réalisation de l’action après son approbation par l’utilisateur, et un dispositif de sécurité personnel pour afficher des vues de la série de vues et recevoir l’approbation de l’utilisateur. Le procédé comprend les étapes consistant à prévoir un service orchestrateur exécuté par un serveur ; au moyen du module de sécurité matériel, générer la série de vues du processus d’approbation et communiquer la série de vues au service orchestrateur, et au moyen du service orchestrateur, fournir au dispositif de sécurité personnel tout ou partie des vues générées par le module de sécurité matériel. Selon un mode de réalisation, le procédé comprend l’étape consistant à, au moyen du service orchestrateur, fournir au dispositif de sécurité personnel une première vue de la série de vues, puis une ou des vues suivantes ou précédentes de la série de vues, à la demande du dispositif de sécurité personnel. Selon un mode de réalisation, la fourniture d’au moins une vue au dispositif de sécurité personnel comprend le découpage de la vue par le service orchestrateur en une pluralité de blocs de données, l’envoi de chaque bloc de données au dispositif de sécurité personnel, et la reconstitution de la vue par le dispositif de sécurité personnel lorsque la pluralité de blocs de données a été reçue, par concaténation des blocs de données. Selon un mode de réalisation, le module de sécurité matériel communique chaque vue au service orchestrateur sous une forme chiffrée avec une clé de chiffrement connue du dispositif de sécurité personnel mais inconnue du service orchestrateur. Selon un mode de réalisation, le procédé comprend les étapes consistant à, au moyen du service orchestrateur, découper chaque vue dans sa forme chiffrée et fournir au dispositif de sécurité personnel des blocs de données chiffrés, et au moyen du dispositif de sécurité personnel, concaténer les blocs de données chiffrés reçus et déchiffrer la chaîne de bits obtenue, pour reconstituer la vue. Selon un mode de réalisation, les vues sont envoyées au dispositif de sécurité personnel par le service orchestrateur par l’intermédiaire de commandes de carte à puce du type APDU défini par la norme ISO/IEC 7816. Selon un mode de réalisation, le procédé comprend une étape d’authentification du dispositif de sécurité personnel par le module de sécurité matériel, l’étape d’authentification comprenant les étapes consistant à, au moyen du module de sécurité matériel, envoyer un challenge au dispositif de sécurité personnel, et au moyen du dispositif de sécurité personnel, générer une réponse au challenge et l’envoyer au module de sécurité matériel. Selon un mode de réalisation, l’étape de calcul et d’envoi d’une réponse au challenge n’est réalisée que si l’utilisateur communique au dispositif de sécurité personnel son approbation sur l’action à effectuer. Selon un mode de réalisation, le module de sécurité matériel est configuré pour que la réception d’une réponse au challenge valide ait valeur d‘approbation de l’utilisateur quant à la réalisation de l’action. Selon un mode de réalisation, le challenge est envoyé au dispositif de sécurité personnel comme une vue fictive de la série de vues, ayant un rang supérieur au rang de la dernière vue de la série de vues. Selon un mode de réalisation, le challenge est envoyé au dispositif de sécurité personnel en même temps qu’une vue, en tant que donnée liée à un élément se trouvant à l’intérieur de la vue. Selon un mode de réalisation, le dispositif de sécurité personnel est configuré pour, après avoir reçu l’approbation de l’utilisateur sur l’action à effectuer, envoyer au module de sécurité matériel tout ou partie d’une donnée secrète du dispositif de sécurité personnel ou une donnée dérivée de cette donnée secrète. Selon un mode de réalisation, une vue fournie par le module de sécurité matériel consiste dans un descriptif de la vue selon une structure de vue, le descriptif étant transformé en une chaîne de données binaires. Selon un mode de réalisation, le procédé comprend une étape de découpage de la chaîne de données binaires formant un descriptif de la vue en une pluralité de blocs de données, l’envoi de chaque bloc de données au dispositif de sécurité personnel, la reconstitution du descriptif de la vue par le dispositif de sécurité personnel lorsque la pluralité de blocs de données a été reçue, par concaténation des blocs de données, et la reconstitution de la vue par le dispositif de sécurité personnel, à partir du descriptif de la vue. Selon un mode de réalisation, la structure de vue comprend une pluralité d’objets. Selon un mode de réalisation, la structure de vue comprend au moins deux conteneurs principaux contenant chacun des objets. Selon un mode de réalisation, le procédé est mis en œuvre pour l’approbation d’actions d’administration de comptes de cryptoactifs, lesdites actions d'administration comprenant au moins l’une des actions suivantes : l’approbation d’une transaction au moyen d’un compte de cryptoactifs ; l’approbation d’une action de génération d’une clé maître de compte de cryptoactif ; l’approbation d’actions d’acceptation ou de révocation d’opérateurs aptes à participer à des actions d’administration de comptes de cryptoactifs. Des modes de réalisation concernent également un système de gestion d’un processus d’approbation d’une action par au moins un utilisateur, dans lequel le processus d’approbation de l’action est associé à une série de vues prévues à l’attention de l’utilisateur, le système comprenant un module de sécurité matériel, pour gouverner le processus d’approbation et initier la réalisation de l’action après son approbation par l’utilisateur, et un dispositif de sécurité personnel pour afficher des vues de la série de vues et recevoir l’approbation de l’utilisateur, le système comprenant également un service orchestrateur exécuté par un serveur, le module de sécurité matériel étant configuré pour générer la série de vues du processus d’approbation et communiquer la série de vues au service orchestrateur, et le service orchestrateur étant configuré pour fournir au dispositif de sécurité personnel tout ou partie des vues générées par le module de sécurité matériel. Selon un mode de réalisation, le service orchestrateur est configuré pour découper au moins une vue en une pluralité de blocs de données, et envoyer la pluralité de blocs de données au dispositif de sécurité personnel, le dispositif de sécurité personnel étant configuré pour reconstituer la vue lorsque la pluralité de blocs de données a été reçue, par concaténation des blocs de données. Selon un mode de réalisation, le module de sécurité matériel est configuré pour communiquer chaque vue au service orchestrateur sous une forme chiffrée avec une clé de chiffrement connue du dispositif de sécurité personnel mais inconnue du service orchestrateur. Selon un mode de réalisation, les vues sont envoyées au dispositif de sécurité personnel par le service orchestrateur par l’intermédiaire de commandes de carte à puce du type APDU défini par la norme ISO/IEC 7816. Selon un mode de réalisation, une vue fournie par le module de sécurité matériel consiste dans un descriptif de la vue selon une structure de vue déterminée. Selon un mode de réalisation, la structure de vue comprend une pluralité d’objets. Selon un mode de réalisation, le système est configuré pour l’approbation d’actions d’administration de comptes de cryptoactifs, lesdites actions d'administration comprenant au moins l’une des actions suivantes : l’approbation d’une transaction au moyen d’un compte de cryptoactifs, l’approbation d’une action de génération d’une clé maître de compte de cryptoactifs, l’approbation d’actions d’acceptation ou de révocation d’opérateurs aptes à participer à des actions d’administration de comptes de cryptoactifs. Description sommaire des dessins Des modes de réalisation d'un procédé et d’un système de gestion de processus d’approbation d’actions seront décrits dans ce qui suit à titre non limitatif, en relation avec les figures jointes parmi lesquelles : - la FIG. 1 précédemment décrite représente schématiquement un système classique de gestion non mutualisée de comptes de cryptoactifs, - la FIG. 2 précédemment décrite représente schématiquement un système classique de gestion mutualisée de comptes de cryptoactifs, - la FIG. 3 montre un mode de réalisation d’un système de gestion mutualisée de comptes de cryptoactifs permettant la mise en œuvre du procédé, - la FIG. 4 montre plus en détail un dispositif de sécurité personnel présent dans le système de la FIG. 3 , - la FIG. 5 est un diagramme de séquences décrivant des étapes du procédé de gestion du processus d’approbation d’actions, - la FIG. 6 et la FIG. 6 décrivent les étapes du diagramme de la FIG. 5 , - la FIG. 7 montre une structure de vue utilisée dans un mode de réalisation du procédé, - la FIG. 8 montre un descripteur d’une vue réalisée selon la structure de vue de la FIG. 7 , - la FIG. 9 , la FIG. 9 , la FIG. 9 , la FIG. 9 , la FIG. 9 , la FIG. 9 , la FIG. 9 , la FIG. 9 , la FIG. 9 , la FIG. 9 , la FIG. 9 , montrent des exemples d’objets présents dans la structure de vue de la FIG. 7 , - la FIG. 10 montre un premier exemple d’une série de vues associées à la réalisation d’une action, et - la FIG. 11 montre un deuxième exemple d’une série de vues associées à la réalisation d’une action. Description détaillée La FIG. 3 montre l’architecture générale d’un premier mode de réalisation d’un système de gestion mutualisée de comptes de cryptoactifs mettant en œuvre le procédé de gestion de processus d’approbation d’action selon la présente divulgation. Le système comprend un module de sécurité matériel HSM1, un serveur SRV1 et des opérateurs OPi (OP 1 … OP N ). Le terme "module de sécurité matériel" désigne un module du type mentionné plus haut, offrant un haut niveau de sécurité matériel et logiciel, par exemple conforme à la norme FIPS 140-2 de niveau III. Les opérateurs OPi peuvent se relier au serveur SRV1 via une liaison de données sécurisée https1. Le serveur SRV1 peut se relier au module HSM1 via une liaison de données sécurisée https2. Ces liaisons de données sécurisées peuvent être de tout autre type connu, par exemple VPN, TLS, etc. Le module de sécurité matériel HSM1 a accès à une mémoire sécurisée MEM dans laquelle est stockée une clé maître K0 et des clés Kj dérivées de la clé maître K0, correspondant à un ensemble de comptes de cryptoactifs faisant l’objet d’une gestion mutualisée. Un opérateur OPi peut être un copropriétaire ("shared-owner"), un administrateur, un approbateur de transaction, ou tout autre rôle pouvant être défini. Les administrateurs définissent des règles de gouvernance. Ils peuvent également, dans certains modes de réalisation, approuver, voire désigner des copropriétaires. Les copropriétaires génèrent la clé maître K0 de l’ensemble de comptes de cryptoactifs, à partir de clés maîtres qui leur sont propres. Les opérateurs approbateurs approuvent des transactions initiées par eux-mêmes ou d'autres opérateurs. Dans un mode de réalisation, un opérateur OPi comprend un dispositif de sécurité personnel PSDi associé à un dispositif hôte HDVi exécutant une application compagnon CAP, par exemple l’application "Ledger Live" développée par la demanderesse. L’opérateur comprend également un utilisateur personne physique USRi qui peut agir à la fois sur le dispositif hôte HDVi ou sur le dispositif de sécurité personnel PSDi. Dans un mode de réalisation montré sur la FIG. 4 , un dispositif de sécurité personnel PSDi a une architecture de type portefeuille matériel (« Hardware Wallet ») et comprend un élément sécurisé SE1 et un microcontrôleur MCU1. Le microcontrôleur gère une interface USB1 de type USB. Dans certains modes de réalisation, le microcontrôleur gère également une interface BT1 de type Bluetooth. Le dispositif de sécurité personnel PSDi comprend également un écran tactile TS (« Touch Screen ») directement contrôlé par l’élément sécurisé SE1, et comprenant un afficheur DISP recouvert par un module tactile TM (« Touch Module »). L’élément sécurisé SE1 comprend une mémoire SMEM recevant son système d’exploitation OS1 ainsi qu’un programme application OAP permettant d’utiliser le dispositif de sécurité personnel en tant qu’opérateur du système de gestion mutualisée de comptes de cryptoactifs. Une telle architecture est celle, par exemple, du dispositif Ledger Stax, qui est équipé d’un écran tactile directement contrôlé par l’élément sécurisé. Un tel dispositif de sécurité personnel PSDi est donc l’équivalent d’une carte à puce (l’élément sécurisé) équipée d’un écran tactile et d'une interface de communication USB/Bluetooth (le microcontrôleur). Dans un autre mode de réalisation, le dispositif de sécurité personnel PSDi et le dispositif hôte HDVi ne forment qu’un seul dispositif, par exemple un téléphone dit « blockchain », comprenant un portefeuille matériel intégré dans le téléphone. On dispose dans ce cas d’une plus grande puissance de calcul, offerte par le processeur d’application du téléphone. Dans d'autres modes de réalisation, les opérateurs OPi peuvent être des entités informatiques exécutées par des ordinateurs personnels ou des serveurs. Ces différents types de dispositifs opérateurs peuvent coexister dans le système présentement décrit. De retour à la FIG. 3 , le serveur SRV1 héberge une plateforme de transaction TPF, un service orchestrateur ORC et un service BCAST de diffusion de transactions sur des réseaux de blockchains BCN. Le module HSM1 comprend et exécute un service de gouvernance GOV et un service de signature SIGN1 de transactions. Le service de signature SIGN1 assure la signature d’une transaction au moyen de l’une des clés Kj auxquelles le module HSM1 a accès, lorsque la transaction a été approuvée par des utilisateurs approbateurs dont l’identité et le nombre sont définis par une règle de gouvernance mise en œuvre par le service de gouvernance GOV. Le service BCAST est montré ici à titre non limitatif comme exécuté par le serveur SRV1 mais pourrait aussi être exécuté par tout autre serveur ou dispositif associé au système. La mémoire MEM recevant la clé maître K0 et les clés Kj peut être interne ou externe au module HSM1. Le système est conçu pour que la mémoire MEM ne puisse être lue et écrite que par le module HSM1. Dans un mode de réalisation, les dispositifs de sécurité personnels PSDi et le module HSM1 sont membres d’une infrastructure à clé publique PA gérée par une autorité de certification CA fournissant une clé publique PA. Ils comprennent chacun une clé privée, respectivement dPi, dH1, une clé publique, respectivement PPi, PH1, et un certificat, respectivement CPi, CH1. Le certificat CPi ou CH1 comprend la clé publique PPi ou PH1 et une signature de celle-ci produite par l’autorité de certification au moyen de sa clé privée dA. Grâce à ces certificats, dont la validité peut être vérifiée au moyen de la clé publique PA de l’autorité de confiance, chaque dispositif PSDi peut apporter la preuve de son caractère authentique au module HSM1. Le système peut être configuré pour permettre divers types d’actions, comme des actions d’intégration ou d’exclusion d’opérateurs, par exemple des approbateurs, des copropriétaires, ou des administrateurs, une action de génération d’une clé maître K0 à partir de clés maîtres propres à des copropriétaires, ou encore une action de réalisation d’une transaction. A chaque action est associée une série de vues nécessaires à la mise en œuvre du processus d’approbation de l’action, destinées à être affichées par les dispositifs de sécurité personnels PSDi à la discrétion de l’utilisateur. Lorsqu’une action doit être effectuée, le système met en œuvre le procédé de gestion de processus d’approbation d’actions selon la présente divulgation. Ce procédé se distingue d’un procédé classique en ce qu’il réduit considérablement l’espace mémoire nécessaire à la génération des vues par les dispositifs de sécurité personnels PSDi. Selon ce procédé, au lieu de laisser chaque dispositif de sécurité personnel PSDi générer la série de vues d’un processus d’approbation déterminé, cette série de vues est générée par le module HSM1. Une fois la série de vues générée par le module HSM1, ce dernier la fournit au service orchestrateur ORC du serveur SRV1. Ensuite, le service orchestrateur ORC transmet les vues aux dispositifs de sécurité personnels PSDi, les unes après les autres, au fur et à mesure que ces derniers les demandent. A chaque type d'action peut aussi être associé un type d’approbation. Il peut s’agir d’une approbation expresse ou implicite, pouvant être accompagnée de la fourniture d’une donnée. Dans des modes de réalisation, la seule fourniture de cette donnée vaut approbation implicite. Par exemple, l’approbation d’une action d’acceptation ou d’exclusion d’un opérateur peut être associée à la fourniture, par chaque dispositif de sécurité personnel sollicité, d’une réponse à un challenge précédemment envoyé par le module de sécurité matériel. Une telle réponse à un challenge peut par exemple consister dans la signature du challenge. L’envoi de cette signature peut valoir approbation implicite de l’action soumise à approbation. Comme autre exemple, l’approbation d’une action de génération d’une clé maître K0 peut se traduire par la fourniture au module de sécurité matériel, par chaque dispositif de sécurité personnel sollicité, d’une donnée permettant de générer cette clé maître K0. La donnée fournie par chaque dispositif de sécurité personnel peut par exemple être sa propre clé maître ou une partie de celle-ci, éventuellement sous une forme chiffrée, ou encore une donnée, chiffrée ou non, générée à partir de sa clé maître. L’envoi de cette donnée peut valoir approbation implicite de l’action de génération de la clé maître K0. Dans un mode de réalisation, des liaisons de données entre le serveur SRV1 et les dispositifs PSDi pour la communication à ces derniers des vues générées par le module HSM1, sont établies grâce à des commandes et des réponses APDU (« Application Protocole Data Unit ») du type décrit par le protocole ISO/IEC 7816 pour cartes à puce. Il sera rappelé ici qu’une commande APDU comprend un en-tête de quatre octets CLA (Classe), INS (Instruction), P1, P2, et un corps conditionnel de longueur variable qui comprend des champs [Lc field] [Data field] [Le field]. Le nombre d'octets présents dans le champ de données d’une commande APDU est indiqué par le champ Lc. Le nombre maximal d'octets attendus dans le champ de données de la réponse APDU est indiqué par le champ Le (longueur des données attendues). Lorsque le champ Le est égal à zéro, cela signifie que le nombre maximal d'octets de données disponibles est demandé. Enfin, le champ Data field comprend les données véhiculées par la commande. Il sera également rappelé qu’une réponse APDU comprend un champ de données de longueur variable et un message de fin obligatoire, appelé « trailer », de deux octets SW1, SW2. Dans l’exemple de mise en œuvre du procédé décrit plus loin, les notations et valeurs suivantes seront utilisées : SW1,SW2 = 9000 : envoi d’une réponse APDU ne comprenant que les deux octets SW1, SW2 portée à la valeur 9000 signifiant « No further qualification », soit « rien à signaler ». Ce type de réponse est utilisé comme accusé de réception de données présentes dans une commande APDU. P1 = 80(MORE) or 00 (END) : lorsque le champ P1 d’une commande est égal à 80, cela signifie que les données fournies dans la commande ne sont pas complètes et que d’autres données vont suivre. Lorsque le champ P1 est égal à 00, cela signifie que toutes les données ont été transmises. SW1, SW2 = 6100 or 9000 : lorsque les octets SW1, SW2 d’une réponse sont égaux à 6100, cela signifie que les données figurant dans le champ de données de la réponse ne sont pas complètes et que d’autres données doivent être envoyées pour que la réponse soit complète. Lorsque les octets sont égaux à 9000, cela signifie que toutes les données ont été envoyées. GET RESPONSE : la commande GET RESPONSE est par exemple envoyée lorsqu’une réponse précédemment reçue comprend le champ SW1, SW2 égal à 6100, ce qui signifie que l’entité qui envoie les réponses a encore des données à fournir, à la suite de quoi l’entité qui envoie des commandes envoie la commande GET RESPONSE. Cette commande permet à l’entité qui doit envoyer des données de les envoyer dans une réponse à cette commande. Lorsque cette commande est codée « 00C0000000 » avec un champ Le égal à 0, cela signifie que l’émetteur de la commande attend qu’on lui envoie une réponse avec un nombre maximum d’octets. La FIG. 5 est un diagramme de séquence qui montre un exemple de réalisation du procédé en relation avec la réalisation d’une action qui est approuvée ici par l’envoi d’une réponse à un challenge reçu précédemment, cette réponse consistant ici dans la signature du challenge. Les étapes représentées sur la FIG. 5 sont détaillées sur les figures 6A, 6B et seront décrites plus en détail dans ce qui suit. S01 - Exec Action Aj A une étape S01, un opérateur se connecte à la plateforme TPF et demande l’exécution d’une action Aj. La plateforme TPF transfère cette demande d’exécution au service orchestrateur ORC. S02 - Prepare Action Aj A une étape S02, le service orchestrateur demande au service de gouvernance GOV du module HSM1 de préparer l’action Aj. Le service de gouvernance détermine alors la règle de gouvernance applicable et les opérateurs OPi dont l’approbation devra être recueillie pour l’exécution de l’action. On supposera dans ce qui suit, dans un souci de simplification de l’exposé, que l’accord d’un seul opérateur OPI, équipé d’un dispositif de sécurité personnel PSDi, doit ici être requis. Toutefois, les étapes qui sont décrites dans ce qui suit peuvent être réalisées en même temps avec plusieurs opérateurs différents, et donc plusieurs dispositifs de sécurité personnel PSDi, si la règle de gouvernance applicable nécessite plusieurs approbations. S03 - k = ECDH (PSDi, HSM1) A une étape S03, une poignée de main (« handshake ») est réalisée entre le dispositif de sécurité personnel PSDi et le service de gouvernance GOV, afin de définir entre le dispositif de sécurité personnel PSDi et le module HSM1 une clé de session éphémère k qui permettra au service de gouvernance GOV d’envoyer au dispositif PSDi, via le service orchestrateur ORC, des données chiffrées au moyen de cette clé de session. Dans un mode de réalisation, cette étape consiste en un échange de clés Diffie-Hellman basé sur les courbes elliptiques ECDH (Elliptic Curve Diffie–Hellman), au cours duquel les deux entités PSDi et HSM1 s’échangent des clés publiques éphémères et des certificats éphémères, chacune combinant une clé privée éphémère qui lui est propre avec la clé publique éphémère ou statique de l’autre entité pour obtenir la clé de session éphémère k. De plus, le module HSM1 peut avoir été configuré de manière à connaître la clé publique du dispositif de sécurité personnel PSDi, ce qui lui permet de vérifier que la signature présente dans le certificat éphémère du dispositif PSDi, générée à partir de la clé privée statique de ce dernier, est valide. Dans une variante, cette étape met en œuvre le procédé « Noise Protocol Framework » (http://www.noiseprotocol.org/noise.html) avec la courbe elliptique Curve25519, une fonction de chiffrement AES-GCM utilisant une clé AES (Advanced Encryption Standard) et l’algorithme de chiffrement GCM (Galois/Counter Mode), et l’algorithme de hachage SHA-256 (Secure Hash Algorithm) sur 256 bits. L’authentification du dispositif PSDi et du module HSM1 est faite au moyen d’une fonction de signature ECDSA (Elliptic Curve Digital Signature Algorithm) et des clés publiques de chaque entité. Dans un mode de réalisation appelé « K Pattern », la poignée de main « handshake » est du type à sens unique (« one way handshake pattern ») entre le dispositif de sécurité personnel PSDi et le service orchestrateur ORC. S04 – PREPARE [V1,V2,...V N ]Aj ; GEN CHALLENGE A une étape S04, le service de gouvernance GOV prépare un ensemble de vues V1 à V N nécessaires à la mise en œuvre du processus d’approbation de l’action Aj par l’opérateur OPi. Par ailleurs, il génère un challenge au moyen d’un générateur de mots binaires aléatoires. S05 – ENC(V1,k), ENC(V2,k),... ENC(V N ,k), ENC(CHALLENGE, k) A une étape S05, le service de gouvernance GOV chiffre chaque vue V1 à V N avec la clé de session éphémère k. Le service de gouvernance GOV chiffre également le challenge avec la clé k, comme s’il s’agissait d’une vue supplémentaire V N+1 . La fonction de chiffrement ENC utilisée est par exemple la fonction AES ou la fonction AES-GCM. S06 – Send ENC(V1,k), ... ENC(V N ,k), ENC(CHALLENGE,k) A une étape S06, le service de gouvernance GOV envoie au service orchestrateur ORC chacune des vues chiffrées ainsi que le challenge chiffré. S10 – CUT{ENC(Vi,k)} = DT1//DT2//DT3//..//DTn A une étape S10, le service orchestrateur ORC découpe chaque vue Vi chiffrée en une pluralité de blocs de données DT1, DT2… DTn, ou « morceaux » (« chunk ») de la vue Vi. S11 – [DTi, P1] (i = 1→n) A une étape S11, le service orchestrateur ORC initie la première étape d’une boucle « VIEWLOOP(Vi) » d’envoi au dispositif de sécurité personnel PSDi d’une vue Vi, à commencer par la première vue V1 de la série de vues. Le service orchestrateur ORC envoie au dispositif de sécurité personnel PSDi le premier bloc de donnée DT1 de l’ensemble de blocs de données DTi issus du découpage de la vue Vi chiffrée au cours de la première exécution de la étape S11, puis les blocs de données suivants au cours des itérations suivantes. Chaque bloc de données DTi est envoyé dans une commande APDU comprenant le champ P1 qui peut être égal à 80 ou 00 comme vu plus haut. S12 – SW1, SW2 = 9000 A une étape S12, le dispositif de sécurité personnel PSDi renvoie une réponse APDU égale à 9000, qui confirme la bonne réception du bloc de données DTi. S13 - P1 = 80(MORE) or 00 (END)? A une étape S13, le dispositif de sécurité personnel PSDi détermine si le champ P1 est égal à 80 ou à 00. Si P1 est égal à 80, le dispositif de sécurité personnel PSDi réitère l’étape S11 pour recevoir un nouveau bloc de données DTi, et ainsi de suite jusqu’à ce que tous les blocs de données DT1 à DT N aient été reçus. La répétition des étapes S11, S12 et S13 forme la boucle « VIEWLOOP(Vi) ». Lorsque P1 est égal à 00, tous les blocs de données DTi ont été reçus et le dispositif de sécurité personnel PSDi sort de la boucle VIEWLOOP pour la vue Vi considérée. S14 – Vi=DEC((DT1//DT2//DT3//...//DTn), k) A une étape suivante S14, le dispositif de sécurité personnel PSDi concatène l’ensemble des blocs de données DTi reçus, pour reconstituer la vue Vi chiffrée ENC(Vi, k), et décode la vue chiffrée au moyen de la clé de session éphémère k, pour obtenir la vue Vi. Le dispositif de sécurité personnel PSDi affiche ensuite cette vue. Dans certains modes de réalisation, la taille des vues à envoyer, ou de certaines vues à envoyer, est suffisamment petite pour ne former qu’un seul bloc de données DT1. Dans ce cas l’étape S10 n’est pas réalisée, l’étape S11 n’est exécutée qu’une seule fois pour l’envoi de l’unique bloc de données, et l’étape S14 ne comprend que l’opération de déchiffrement du bloc de données. U10 – USR CHOICE A une étape U10, l’utilisateur USRi effectue un choix dans la vue affichée par son dispositif de sécurité personnel PSDi. Ce choix consiste par exemple, à appuyer sur un bouton matériel ou sur un bouton tactile qui est affiché dans la vue, par exemple un bouton « précédent » s’il veut revenir à la vue précédente, « suivant » s’il veut la vue « suivante », « refuser » s’il refuse de donner son accord sur la réalisation de l’action, ou au contraire « accepter » s’il l’accepte. Divers autres moyens de réception de l’approbation de l’utilisateur par le dispositif de sécurité personnel pourraient bien entendu être prévus, comme une approbation vocale au moyen d’un mot ou d’une phrase de passe spécifique avec de préférence identification de la voix de l’utilisateur, la saisie manuelle d’un mot de passe, etc. Il sera par ailleurs noté que le choix entre « refuser » et « accepter » n’est généralement proposé que sur la dernière vue de la série de vues. Les différentes vues ayant été chaînées par le service de gouvernance GOV, les choix « précédent » et « suivant » désignent sans ambiguïté la prochaine vue devant être affichée par le dispositif de sécurité personnel PSDi. S15 – USR CHOICE = New Vi or REFUSE or AGREE ? A une étape S15, le dispositif de sécurité personnel PSDi détermine si le choix que l’utilisateur a fait à l’étape U10 consiste en une demande d’affichage d’une nouvelle vue ou si ce choix consiste dans une décision finale d’acceptation ou de refus qui met fin au processus de décision. Si ce choix consiste en une demande d’affichage d’une nouvelle vue (« New Vi »), le dispositif PSDi va à une étape S16A. Si l’utilisateur refuse l’action (« REFUSE »), le dispositif PSDi va à une étape S16B. Si l’utilisateur accepte de réaliser l’action (« AGREE »), le dispositif PSDi va à une étape S16C. S16A – Next Action = [i, 9000] A l’étape S16A, le dispositif de sécurité personnel PSDi détermine quel est le rang i de la prochaine vue devant être affichée à l’utilisateur et indique ce choix au service orchestrateur ORC en lui envoyant une réponse APDU « Next Action » dont le champ de données indique le rang i de la nouvelle vue Vi demandée et dont les champs SW1, SW2 sont égaux à 9000 pour indiquer que la vue précédente a été bien reçue et a été traitée. Le procédé est ensuite renvoyé à l’étape S10 où le service orchestrateur ORC découpe en blocs de données DTi la nouvelle vue demandée, puis répète la boucle « VIEWLOOP(Vi) ». Les étapes S14, U10 et S15 sont de nouveau exécutées. La répétition de la boucle « VIEWLOOP(Vi) » et des étapes S14, U10 et S15 jusqu’à la décision finale de l’utilisateur forme une boucle « ACTIONLOOP(Ai) » d’envoi au dispositif de sécurité personnel PSDi de toutes les vues de la série de vues associée à l’action Ai qui ont été demandées par l’utilisateur. Il sera noté que certaines vues de la série de vues peuvent n’être jamais affichées en fonction des choix et des chemins empruntés par l’utilisateur pour arriver à la vue au moyen de laquelle il prend une décision finale. S16B – SW1, SW2 = REFUSE A l’étape S16B, le dispositif de sécurité personnel PSDi envoie au service orchestrateur ORC une réponse APDU sans champ de données dans laquelle les champs SW1, SW2 sont portés à une valeur déterminée qui signifie que l’utilisateur refuse l’action. Le service orchestrateur ORC en informe le service de gouvernance GOV qui décide si ce refus provoque ou non l’annulation de l’action Aj. En effet dans le cas d’une action associée à une règle de gouvernance qui prévoit que l’accord d’une majorité simple d’opérateurs est suffisant pour réaliser l’action, le refus d’un opérateur n’entraîne pas nécessairement l’annulation de l’action. S16C – Next Action = [N+1, 9000] A l’étape S16, le dispositif de sécurité personnel PSDi envoie au service orchestrateur ORC une réponse APDU qui lui demande de lui adresser une vue de rang N+1. Cette vue est fictive puisque la série de vues ne comprend que N vues. Cette vue fictive n’est rien d’autre que le challenge considéré comme une dernière vue de la série de vues. S110 – CUT{ENC(CHALLENGE,k)} = DT1//DT2//DT3//..//DTn A une étape S110, si la longueur du challenge dépasse la taille prédéterminée d’un bloc de données DTi, le service orchestrateur ORC découpe le challenge chiffré en une pluralité de blocs de données DT1, DT2… DTn, ou « morceaux » (« chunk ») du challenge chiffré. Dans le présent mode de réalisation, le challenge chiffré est en effet traité de la même manière qu’une vue, en accord avec ce qui a été indiqué au sujet de l’étape S16C. S111 – [DTi, P1] (i = 1→n) A une étape S111, le service orchestrateur ORC initie la première étape d’une boucle « CHALOOP » d’envoi du challenge au dispositif PSDi. Au cours de la première étape S11, le service orchestrateur ORC envoie au dispositif PSDi le premier bloc de données DTi de l’ensemble de blocs de données issus du découpage du challenge. Le bloc de données DTi est envoyé dans une commande APDU comprenant le champ P1 qui peut être égal à 80 ou 00. S112 – SW1, SW2 = 9000 A une étape S112, le dispositif PSDi renvoie une réponse APDU égale à 9000, qui confirme la bonne réception du bloc de données DTi. S113 - P1 = 80(MORE) or 00 (END)? A une étape S113, le dispositif PSDi détermine si le champ P1 est égal à 80 ou à 00. Si P1 est égal à 80, le dispositif PSDi réitère l’étape S11 pour recevoir un nouveau bloc de données DTi de rang i=i+1, et ainsi de suite jusqu’à ce que tous les blocs de données DT1 à DT N aient été reçus. La répétition des étapes S111, S112 et S113 forme la boucle « CHALOOP ». Lorsque P1 est égal à 00, tous les blocs de données DTi ont été reçus et le dispositif de sécurité personnel PSDi sort de la boucle CHALOOP pour aller à une étape S114. S114 – CHALLENGE=DEC((DT1//DT2//DT3//..//DTn), k) A l’étape S114, le dispositif de sécurité personnel PSDi concatène l’ensemble des blocs de données DTi reçus pour reconstituer le challenge chiffré, et le déchiffre au moyen de la clé k. Dans certains modes de réalisations la taille du challenge est suffisamment petite pour ne former qu’un seul bloc de données DT1. Dans ce cas l’étape S110 n’est pas réalisée, l’étape S111 n’est exécutée qu’une seule fois et l’étape S114 ne comprend que l’opération de déchiffrement de l’unique bloc de données. S20 – SIGN=SIGN(CHALLENGE)dPi A une étape S20 ( FIG. 6 ), le dispositif de sécurité personnel PSDi génère une réponse au challenge. Cette réponse est ici une signature du challenge avec sa clé privée dPi, par exemple au moyen de la fonction de signature ECDSA. S21 – [SIGN, SW1, SW2] A une étape S21, le dispositif de sécurité personnel PSDi envoie une réponse APDU comprenant dans son champ de données la réponse au challenge, ici la signature SIGN ou une partie de celle-ci, accompagnée des octets SW1, SW2. Comme indiqué plus haut, si les octets SW1, SW2 sont égaux à 6100, cela signifie que les données de signature SIGN figurant dans le champ de données de la réponse APDU ne sont pas complètes et que d’autres données doivent être envoyées. Lorsque les octets SW1, SW2 sont égaux à 9000, cela signifie que toutes les données ont été envoyées. S22 - SW1, SW2 = 6100 or 9000 ? A une étape S22, le service orchestrateur ORC détermine si SW1, SW2 est égal à 6100 ou 9000. Si SW1, SW2 est égal à 6100, le service orchestrateur ORC va à une étape S23. Si SW1, SW2 est égal à 9000 le service orchestrateur ORC va à une étape S30. S23 – GET RESPONSE (00C0000000) A l’étape S23, le service orchestrateur ORC envoie au dispositif PSDi la commande GET RESPONSE codée « 00C0000000 », ce qui signifie qu’il attend que le dispositif PSDi lui envoie la prochaine réponse avec un nombre maximum d’octets. Le service orchestrateur ORC retourne ensuite à l’étape S21. La répétition des étapes S21, S22 et S23 forme une boucle SIGNLOOP de réception par le service orchestrateur ORC de la signature SIGN, par le biais de réponses à des commandes GET RESPONSE. S30 – Send {SIGN} A une étape S30, le service orchestrateur ORC a reçu l’intégralité de la signature SIGN et l’envoie au service de gouvernance GOV du module HSM1. S31 – INITIATE Action Aj A une étape S31, le service de gouvernance GOV du module HSM1, après avoir vérifié que la signature SIGN est valide au moyen de la clé publique du dispositif de sécurité personnel PSDi, engage l’initialisation de l’action Aj si les autres conditions prévues par la règle de gouvernance associée à l’action Aj sont satisfaites. Si l’une de ces conditions est de recevoir l’accord de plusieurs opérateurs, la réception de l’accord d’un seul utilisateur ne sera pas suffisante pour engager l’action Aj. Il découle de ce qui précède que selon le mode de réalisation qui vient d’être décrit, l’envoi par le dispositif de sécurité personnel PSDi d’une signature valide du challenge est utilisé pour faire savoir au service de gouvernance GOV que l’utilisateur a donné son accord pour la réalisation de l’action Aj, de sorte qu’aucun message spécifique est nécessaire pour marquer l’accord de l’utilisateur. Comme indiqué plus haut, dans certains modes de réalisation aucun challenge n’est envoyé aux dispositifs de sécurité personnels PSDi participant au processus d’approbation de l’action. Leur approbation peut alors être accompagnée de l’envoi d’une donnée qui leur est propre, ou consister dans l’envoi d’une donnée qui leur est propre, notamment une donnée secrète, sous forme chiffrée ou non, comme leur clé maître, une fraction de celle-ci, ou une donnée dérivée de leur clé maître. Dans d’autres modes de réalisation, on combine l’envoi d’une réponse à un challenge avec l’envoi d’une donnée propre aux dispositifs de sécurité personnels, notamment une donnée secrète. En résumé, le procédé de gestion de processus d’approbation d’action qui vient d’être décrit décharge les dispositifs de sécurité personnels PSDi de la nécessité de générer les vues nécessaires à la conduite du processus d’approbation d’une action. Les dispositifs de sécurité personnels ne remplissent plus qu’une fonction passive d’affichage et de collecte des actions des opérateurs. En plus de ces mesures, selon un mode de réalisation du procédé, les vues sont conçues selon une structure de vue qui réduit considérablement leur encombrement et réduit de manière correspondante le nombre de blocs de données DTi à transmettre aux dispositifs PSDi pour la transmission de chaque vue. Un exemple d‘une structure de vue est montré sur la FIG. 7 . La vue comprend des conteneurs CT et des objets OB. Un conteneur CT peut comprendre une pluralité d’objets OB mais peut aussi comprendre un autre conteneur comprenant lui-même des objets. Dans l’exemple représenté, la vue comprend un conteneur haut CT1, un conteneur milieu CT2 et un conteneur bas CT3. Dans cet exemple, le conteneur CT1 reçoit des objets OB1 et OB10, le conteneur CT2 reçoit des objets OB7, OB8 et l’objet OB10, le conteneur CT3 reçoit des objets OB2, OB3, OB4. Chaque vue construite conformément à cette structure de vue est matérialisée sous une forme binaire par un descripteur constitué par la concaténation de descripteurs de conteneurs et de descripteurs des objets contenus dans les conteneurs. La FIG. 8 montre à titre non limitatif un exemple de descripteur d’un conteneur CTi contenant des objets OBi, OBj, OBk, OBl. Le descripteur contient tout d’abord un champ d’identification du conteneur [CONTAINER CTi] accompagné d’un champ [SIZE, LOCATION] qui indique la taille et l’emplacement du conteneur dans la vue, puis d’un champ [DATA] dans lequel il est possible de placer des données. Le descripteur du conteneur contient ensuite des descripteurs des objets que le conteneur contient. Le descripteur de chaque objet, par exemple l’objet OBi, contient par exemple : - un champ d’identification de l’objet [OBJECT], - un champ [SIZE, LOCATION] qui indique la taille et l’emplacement de l’objet dans le conteneur, - un champ [TEXT] qui indique le texte affiché dans l’objet, - un champ [ACTION] qui indique une action devant être effectuée si l’utilisateur exerce une pression sur l’objet (utilisable dans le cas d’un écran tactile), par exemple « vue suivante », «vue précédente », « recevoir le challenge », - un champ [DATA] dans lequel il est possible d’insérer des données qui pourront dans certains cas être affichées à côté de données de type texte mais qui pourront dans d’autres cas ne pas être affichées et utilisées pour contrôler des processus. Par exemple, dans un mode de réalisation, on insère le challenge chiffré dans le champ [DATA] d’un objet de type bouton dont le champ [TEXT] invite l’utilisateur à accepter une action Aj, et on programme dans le champ [ACTION] du bouton, l’action « lire le challenge chiffré dans le champ [DATA] » . Au final, la concaténation de tous les descripteurs de conteneurs et de tous les descripteurs d’objets que contient chaque descripteur de conteneur permet d’obtenir un descripteur de vue formant une chaîne binaire de longueur raisonnable. Ce descripteur de vue est chiffré au moyen de la clé k par le service de gouvernance GOV avant d’être envoyé au service orchestrateur ORC et découpé en blocs de données DTi par celui-ci. Lorsque les dispositifs de sécurité personnels ont reconstitué les descripteurs par concaténation des blocs de données DTi et déchiffrement de l’ensemble, il reconstituent la vue en interprétant le descripteur. A cet effet un programme de reconstitution de vue à partir d’un descripteur est prévu dans chaque dispositif de sécurité personnel. Un tel programme occupe un espace mémoire très inférieur à celui qu’occupe un programme classique de génération de vues. Pour fixer les idées, les figures 9A à 9K montrent des exemples d’objets. La FIG. 9 montre un objet de type « bouton » dont le champ [TEXT] est « Yes, Cancel » (« oui supprimer ») et dont le champ [ACTION] indique que le challenge doit être demandé au service orchestrateur ORC (cas d’une action de type « suppression » qui a été acceptée par l’opérateur). La FIG. 9 montre un objet de type « bouton d’appui long » dont le champ [TEXT] est « Hold to Sign » (« presser longuement pour signer ») et dont le champ [ACTION] indique que le challenge doit être demandé au service orchestrateur (cas d’une action de type « signer une transaction » qui a été acceptée par l’opérateur). La FIG. 9 montre un objet de type « texte seul » dont le champ [TEXT] est « Whitelist creation canceled » (« annulation de la création de la liste blanche »). La FIG. 9 montre un objet de type « valeur de champ » (« Tag Value ») dont le champ [TEXT] est « number of addresses » soit « nombre d’adresses », et dont le champ [DATA] contient ici la valeur d’une variable représentative d’un nombre d’adresses, ici la valeur « 24 ». La FIG. 9 montre un objet de type « barre de navigation » offrant trois options « annuler » « vue précédente » et « vue suivante » et dont le champ [ACTION] définit trois actions différentes correspondant à chacune de ces options. La FIG. 9 montre un objet de type « barre de texte avec icône » dont le champ [TEXT] est « Removed addresses » soit « adresses supprimées ». La FIG. 9 montre un objet de type « barre de bouton gauche dont le champ [TEXT] est « Whitelist edition» soit « édition de la liste blanche » et dont le champ [ACTION] est « vue précédente ». La FIG. 9 montre un objet de type « barre d’indication de page » dont le champ [TEXT] est « of » et dont le champ [DATA] contient la variable « numéro de la page (ici « 2 ») et la variable « nombre de page » (ici « 14 »). La FIG. 9 montre un objet de type « Bouton de fractionnement » dont le champ [TEXT] contient les mots « Cancel » (« Annuler ») et « Skip » (« sauter ») et dont le champ [ACTION] définit les deux actions correspondantes. La FIG. 9 montre un objet de type « vue » dont le champ [TEXT] est vide. La FIG. 9 montre un objet de type QR Code dont le champ [TEXT] est vide et dont le champ [DATA] contient la valeur numérique du QR code. Toujours pour fixer les idées, les figures 10 et 11 montrent des exemples simplifiés de vues chaînées qui peuvent être générées par le module HSM1 au moyen de la structure de vue qui vient d’être décrite. La FIG. 10 montre une vue V01 qui est chaînée à une vue finale V02 invitant l’utilisateur à accepter la suppression de l’invitation d’un administrateur gestionnaire de comptes de cryptoactifs. La vue V01 est également chaînée à une vue intermédiaire V03. La vue V03 est chaînée à une vue finale V03 invitant l’utilisateur à prendre une décision concernant le fait d’inviter cet administrateur. La FIG. 11 montre une vue V05 relative à l’édition d’une nouvelle règle d’administration de comptes de cryptoactifs, qui est chaînée à une vue intermédiaire V06 qui indique les règles de majorité et de quorum pour l’adoption de cette règle. La vue V06 est chaînée à une vue finale V07 invitant l’utilisateur à accepter la règle d’administration. Bien qu’ayant été décrit dans le cadre d’un système de gestion mutualisée de comptes de cryptoactifs, il apparaîtra clairement à l’homme de l’art que le procédé de gestion de processus d’approbation selon la présente divulgation est applicable à la gestion de tout type de processus d’approbation d’action, dans de nombreux domaines d’applications où une décision peut être prise par un groupe de personnes équipées de dispositifs de sécurité personnels. De même, le terme « approbation » ne revêt, à la lumière des exemples cités, aucun caractère limitatif. Notamment, ce terme ne signifie pas seulement qu’une approbation passive est envoyée par les dispositifs de sécurité personnels sollicités. Une approbation peut également consister, comme cela a été vu plus haut, dans le fait de contribuer à la réalisation d’une action, par exemple par l’envoi d’une donnée permettant de réaliser l’action soumise à approbation. Enfin, l’architecture du système qui a été décrite dans ce qui précède est susceptible de modification avec l’évolution des technologies. Notamment, il pourrait être prévu de faire exécuter le programme orchestrateur ORC par le module de sécurité matériel HSM1, ou au moins certaines fonctionnalités de celui-ci telle que la transmission des vues aux dispositifs de sécurité personnels. Dans ce cas le module de sécurité matériel HSM1 peut être considéré comme le serveur exécutant le service orchestrateur, même si d’autres fonctionnalités du service orchestrateur sont exécutées par un serveur distinct du module de sécurité matériel. Procédé de gestion d’un processus d’approbation d’une action par au moins un utilisateur (USR), dans lequel le processus d’approbation de l’action est associé à une série de vues à l’attention de l’utilisateur, le procédé étant mis en œuvre au moyen d’un système comprenant : - un module de sécurité matériel (HSM1, GOV), pour gouverner le processus d’approbation et initier la réalisation de l’action après son approbation par l’utilisateur, et - un dispositif de sécurité personnel (PSDi) pour afficher des vues de la série de vues et recevoir l’approbation de l’utilisateur, procédé caractérisé en ce qu’il comprend les étapes consistant à : - prévoir un service orchestrateur (ORC) exécuté par un serveur (SRV1), - au moyen du module de sécurité matériel (HSM1), générer la série de vues (Vi) du processus d’approbation et communiquer la série de vues au service orchestrateur (ORC), et - au moyen du service orchestrateur, fournir (S11-S13) au dispositif de sécurité personnel tout ou partie des vues générées par le module de sécurité matériel (HSM1). Procédé selon la revendication 1, comprenant l’étape consistant à, au moyen du service orchestrateur, fournir (S11-S13) au dispositif de sécurité personnel une première vue de la série de vues, puis une ou des vues suivantes ou précédentes de la série de vues, à la demande (S16A) du dispositif de sécurité personnel. Procédé selon l’une des revendications 1 et 2, dans lequel la fourniture d’au moins une vue au dispositif de sécurité personnel comprend le découpage (S10) de la vue par le service orchestrateur en une pluralité de blocs de données (DTi), l’envoi de chaque bloc de données au dispositif de sécurité personnel, et la reconstitution (S14) de la vue par le dispositif de sécurité personnel lorsque la pluralité de blocs de données a été reçue, par concaténation des blocs de données. Procédé selon l’une des revendications 1 à 3, dans lequel le module de sécurité matériel communique chaque vue (Vi) au service orchestrateur sous une forme chiffrée (ENC(Vi, k)) avec une clé de chiffrement (k) connue du dispositif de sécurité personnel mais inconnue du service orchestrateur. Procédé selon la revendication 4, comprenant les étapes consistant à : - au moyen du service orchestrateur, découper (S10) chaque vue dans sa forme chiffrée et fournir au dispositif de sécurité personnel des blocs de données (DTi) chiffrés, et - au moyen du dispositif de sécurité personnel, concaténer les blocs de données chiffrés reçus et déchiffrer (S14) la chaîne de bits obtenue, pour reconstituer la vue. Procédé selon l’une des revendications 1 à 5, dans lequel les vues sont envoyées au dispositif de sécurité personnel (PSDi) par le service orchestrateur (ORC) par l’intermédiaire de commandes de carte à puce du type APDU défini par la norme ISO/IEC 7816. Procédé selon l’une des revendications 1 à 6, comprenant une étape d’authentification du dispositif de sécurité personnel par le module de sécurité matériel, l’étape d’authentification comprenant les étapes consistant à : - au moyen du module de sécurité matériel (GOV, HSM1), envoyer (S111-S113) un challenge au dispositif de sécurité personnel, et - au moyen du dispositif de sécurité personnel, générer (S20) une réponse (SIGN) au challenge et l’envoyer (S21-S23) au module de sécurité matériel (GOV, HSM1). Procédé selon la revendication 7, dans lequel l’étape de calcul et d’envoi d’une réponse au challenge n’est réalisée que si l’utilisateur communique au dispositif de sécurité personnel son approbation sur l’action à effectuer. Procédé selon la revendication 8, dans lequel le module de sécurité matériel est configuré pour que la réception (S30) d’une réponse au challenge valide ait valeur d‘approbation de l’utilisateur quant à la réalisation de l’action. Procédé selon l’une des revendication 7 à 9, dans lequel le challenge est envoyé au dispositif de sécurité personnel comme une vue fictive de la série de vues, ayant un rang (N+1) supérieur au rang (N) de la dernière vue de la série de vues. Procédé selon l’une des revendication 7 à 9, dans lequel le challenge est envoyé au dispositif de sécurité personnel en même temps qu’une vue, en tant que donnée ([DATA]) liée à un élément (OBi, OBj, OBk, OBl) se trouvant à l’intérieur de la vue. Procédé selon l’une des revendications 1 à 11, dans lequel le dispositif de sécurité personnel (PSDi) est configuré pour, après avoir reçu l’approbation de l’utilisateur sur l’action à effectuer, envoyer au module de sécurité matériel (GOV, HSM1) tout ou partie d’une donnée secrète du dispositif de sécurité personnel ou une donnée dérivée de cette donnée secrète. Procédé selon l’une des revendication 1 à 12, dans lequel une vue fournie par le module de sécurité matériel (HSM1) consiste dans un descriptif de la vue selon une structure de vue, le descriptif étant transformé en une chaîne de données binaires. Procédé selon la revendication 13, comprenant : - une étape de découpage (S10) de la chaîne de données binaires formant un descriptif de la vue en une pluralité de blocs de données (DTi), - l’envoi de chaque bloc de données au dispositif de sécurité personnel, - la reconstitution (S14) du descriptif de la vue par le dispositif de sécurité personnel lorsque la pluralité de blocs de données a été reçue, par concaténation des blocs de données, et - la reconstitution de la vue par le dispositif de sécurité personnel, à partir du descriptif de la vue. Procédé selon l’une des revendications 13 et 14, dans lequel la structure de vue comprend une pluralité d’objets (OBi, OBj, OBk, OBl). Procédé selon la revendication 15, dans lequel la structure de vue comprend au moins deux conteneurs principaux (CT1-CT3) contenant chacun des objets (OBi, OBj, OBk, OBl). Procédé selon l’une des revendications 1 à 16, pour l’approbation d’actions d’administration de comptes de cryptoactifs, lesdites actions d'administration comprenant au moins l’une des actions suivantes : - l’approbation d’une transaction au moyen d’un compte de cryptoactifs, - l’approbation d’une action de génération d’une clé maître de compte de cryptoactif, - l’approbation d’actions d’acceptation ou de révocation d’opérateurs aptes à participer à des actions d’administration de comptes de cryptoactifs. Système de gestion d’un processus d’approbation d’une action par au moins un utilisateur (USR), dans lequel le processus d’approbation de l’action est associé à une série de vues prévues à l’attention de l’utilisateur, le système comprenant : - un module de sécurité matériel (HSM1, GOV), pour gouverner le processus d’approbation et initier la réalisation de l’action après son approbation par l’utilisateur, et - un dispositif de sécurité personnel (PSDi) pour afficher des vues de la série de vues et recevoir l’approbation de l’utilisateur, système caractérisé en ce qu’il comprend un service orchestrateur (ORC) exécuté par un serveur (SRV1), en ce que : - le module de sécurité matériel (HSM1) est configuré pour générer la série de vues (Vi) du processus d’approbation et communiquer la série de vues au service orchestrateur (ORC), et - le service orchestrateur est configuré pour fournir (S11-S13) au dispositif de sécurité personnel tout ou partie des vues générées par le module de sécurité matériel (HSM1). Système selon la revendication 18, dans lequel le service orchestrateur est configuré pour découper (S10) au moins une vue en une pluralité de blocs de données (DTi), et envoyer la pluralité de blocs de données au dispositif de sécurité personnel, le dispositif de sécurité personnel étant configuré pour reconstituer (S14) la vue lorsque la pluralité de blocs de données a été reçue, par concaténation des blocs de données. Système selon l’une des revendications 18 et 19, dans lequel le module de sécurité matériel (HSM1) est configuré pour communiquer chaque vue (Vi) au service orchestrateur sous une forme chiffrée (ENC(Vi, k)) avec une clé de chiffrement (k) connue du dispositif de sécurité personnel (PSDi) mais inconnue du service orchestrateur. Système selon l’une des revendications 18 à 20 dans lequel les vues sont envoyées au dispositif de sécurité personnel (PSDi) par le service orchestrateur (ORC) par l’intermédiaire de commandes de carte à puce du type APDU défini par la norme ISO/IEC 7816. Système selon l’une des revendication 18 à 21, dans lequel une vue fournie par le module de sécurité matériel (HSM1) consiste dans un descriptif de la vue selon une structure de vue déterminée. Système selon la revendication 22, dans lequel la structure de vue comprend une pluralité d’objets (OBi, OBj, OBk, OBl). Système selon l’une des revendications 18 à 23, configuré pour l’approbation d’actions d’administration de comptes de cryptoactifs, lesdites actions d'administration comprenant au moins l’une des actions suivantes : - l’approbation d’une transaction au moyen d’un compte de cryptoactifs, - l’approbation d’une action de génération d’une clé maître de compte de cryptoactifs, - l’approbation d’actions d’acceptation ou de révocation d’opérateurs aptes à participer à des actions d’administration de comptes de cryptoactifs.