La présente invention concerne un système et un procédé de gestion mutualisée de comptes de cryptoactifs, dans lequel 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 approbateur et satisfait une règle de gouvernance.
Arrière-plan
Ces dernières années, le développement des cryptomonnaies ou autres types de cryptoactifs gérés par 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 et publiques attachées à ces différents types de cryptoactifs. C’est ainsi que sont apparus les portefeuilles de cryptoactifs communément appelés "wallets" permettant le stockage et la conservation de ces clés. Un portefeuille de cryptoactifs est un dispositif matériel ou logiciel 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 montre schématiquement un exemple de portefeuille matériel de cryptoactifs HW, par exemple le dispositif commercialisé par la demanderesse sous l’appellation "Nano" ou "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 HW 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 une blockchain BCN. Le dispositif hôte HDV est par exemple un ordinateur, un téléphone mobile, une tablette ou équivalent. La connexion entre le dispositif HW 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 HW, 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 HW peut interagir avec le logiciel compagnon pour permettre à un utilisateur USR de réaliser des transactions sur la blockchain BCN ou sur des sites d’échange décentralisé. Le dispositif HW peut par ailleurs communiquer avec un module de sécurité matérielle HSM ("Hardware Security Module") situé dans un datacenter. Un tel module de sécurité matérielle 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érielle HSM ne stocke pas les clés privées de l’utilisateur et assure seulement le contrôle de l’authenticité du dispositif HW, sa mise en service, la mise à jour de son système d’exploitation, le téléchargement de programmes d’application certifiés, etc.
Une exception à cette règle doit être faite dans le cas d’une gestion mutualisée de comptes de cryptoactifs, dans laquelle 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 approbateur et satisfait une règle de gouvernance. On prévoit dans ce cas un module de sécurité matérielle pour exécuter un service de gouvernance de transactions et signer les transactions. A cet effet, le module de sécurité matérielle doit détenir la clé maître et/ou les clés privées des comptes de cryptoactifs concernés. Lorsque la réalisation d’une transaction est demandée au module de sécurité matérielle, celui-ci identifie la règle de gouvernance qui s’applique à la transaction demandée, puis sollicite l’accord d'opérateurs désignés par cette règle de gouvernance. Lorsque l’accord des opérateurs est reçu, le module de sécurité matérielle signe la transaction avec la clé privée appropriée puis la diffuse sur la blockchain concernée.
Ainsi, dans le cadre d’une gestion mutualisée de comptes de cryptoactifs, la sécurité de ces comptes repose sur l’inviolabilité du module de sécurité matérielle. Celui-ci protège les clés privées, valide les processus d'autorisation et génère des signatures de transaction conformément à des règles de gouvernance prédéterminées.
On connaît également, par WO2023046409A1, un système d’approbation de transactions relatives à des comptes de cryptoactif non mutualisés, dans lequel un portefeuille matériel (« wallet ») adresse une transaction à signer à des services de politique. Les services de politique fournissent des autorisations de signature à un service de signature. Le service de signature signe la transaction et la renvoie au portefeuille matériel, qui place la transaction signée sur une blockchain. Les services de politique et le service de signature ne sont pas exécutés par un module de sécurité matérielle mais utilisent un module de sécurité matérielle commun. Après une phase d'intégration de secrets de construction et de déploiement, le module de sécurité matérielle commun fournit aux services de politique des clés publiques que ces derniers envoient au service de signature sous une forme cryptée par les secrets de construction et de déploiement. Le module de sécurité matérielle commun fournit également au service de signature la signature de la transaction approuvée par des services de politique.
La demanderesse utilise des modules de sécurité matérielle 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.
Elle conduit par ailleurs divers travaux de recherche permettant de maintenir au plus haut niveau la sécurité offerte par les modules de sécurité matérielle. En 2019, la demanderesse a ainsi découvert 14 vulnérabilités dans un module HSM. L'exploitation de ces vulnérabilités aurait pu permettre à un attaquant distant d'obtenir une exécution de code arbitraire dans le HSM et éventuellement d'extraire toutes les clés secrètes, sans aucune authentification. Ce problème a été divulgué de manière responsable et correctement corrigé par les fournisseurs de HSM, ce qui a permis de relever le niveau de sécurité pour l'ensemble de l'industrie du HSM. Voir : https:/donjon.ledger.com/BlackHat2019-presentation.
Malgré l’absence connue à ce jour d’un quelconque problème de sécurité qui aurait pu conduire à une attaque sur des clés de comptes mutualisés détenues par de tels modules de sécurité matérielle, la demanderesse est sans cesse en recherche de perfectionnements visant à augmenter le niveau de sécurité des systèmes qu’elle développe (Cf. https:/donjon.ledger.com).
Il pourrait donc être souhaité d’augmenter le niveau de sécurité offert par un système de gestion mutualisée de comptes de cryptoactifs du type qui vient d’être décrit.
Résumé
Des modes de réalisation concernent un système de gestion mutualisée de comptes de cryptoactifs, dans lequel 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 approbateur et satisfait une règle de gouvernance relative à la réalisation de la transaction, le système comprenant : une plateforme de transaction exécutée par un serveur, sur laquelle des descriptions de transactions peuvent être créées, la plateforme de transaction étant configurée pour, après création d’une transaction, émettre une demande de réalisation de la transaction ; un premier module de sécurité matérielle couplé à la plateforme de transaction, configuré pour exécuter des règles de gouvernance relatives à la réalisation de transactions ; un service de signature configuré pour générer une signature d’une transaction à partir d’une donnée secrète ; un second module de sécurité matérielle ayant accès à la donnée secrète, configuré pour exécuter le service de signature, et une mémoire recevant la donnée secrète, la mémoire étant accessible en lecture et écriture au second module de sécurité matérielle et inaccessible au premier module de sécurité matérielle. Le premier module de sécurité matérielle est configuré pour, en réponse à une demande de réalisation d’une transaction émise par la plateforme de transaction, solliciter l'approbation d’au moins un dispositif approbateur et vérifier si une règle de gouvernance applicable à la transaction demandée est satisfaite, puis, lorsque la règle de gouvernance est satisfaite, transmettre une demande de signature de la transaction au second module de sécurité matérielle, le second module de sécurité matérielle étant configuré pour fournir la signature de la transaction.
Selon un mode de réalisation, le premier module de sécurité matérielle est configuré pour inclure la transaction dans la demande de signature de la transaction.
Selon un mode de réalisation, le premier module de sécurité matérielle est configuré pour ne pas inclure la transaction dans la demande de signature de la transaction et y inclure seulement un condensat de la transaction produit par une fonction de hachage, et des données complémentaires permettant au second module de sécurité matérielle de générer la signature de la transaction à partir de ce condensat.
Selon un mode de réalisation, les données complémentaires comprennent un chemin de dérivation déterministe hiérarchique et une fonction de signature à utiliser pour générer la signature de la transaction, ou un identifiant de cette fonction.
Selon un mode de réalisation, le second module de sécurité matérielle n’a jamais connaissance du contenu de la transaction, le système comprenant un service de diffusion de transactions sur une blockchain, recevant la signature de la transaction fournie par le second module de sécurité matérielle et la transaction fournie par le premier module de sécurité matérielle.
Selon un mode de réalisation, le premier module de sécurité matérielle est agencé dans un premier lieu à accès restreint, et le second module de sécurité matérielle agencé dans un second lieu à accès restreint différent du premier lieu.
Selon un mode de réalisation, la donnée secrète est une graine permettant de générer une clé maître permettant elle-même de générer des clés privées de comptes de cryptoactifs, ou une clé maître permettant de générer des clés privées de comptes de cryptoactifs.
Selon un mode de réalisation, une règle de gouvernance définit au moins un nombre d'approbations à recevoir de dispositifs approbateurs pour qu’une transaction soit signée et exécutée.
Selon un mode de réalisation, le système comprend au moins un dispositif approbateur, le dispositif approbateur comprenant des moyens de calcul cryptographique pour établir un canal de communication sécurisé avec le premier module de sécurité matérielle.
Selon un mode de réalisation, le premier module de sécurité matérielle et le dispositif approbateur sont membres d'une même infrastructure à clé publique comprenant une autorité de certification fournissant ladite clé publique, et dans lequel le dispositif approbateur et le premier module de sécurité matérielle sont configurés pour établir entre eux un canal de communication sécurisé en exécutant les étapes suivantes vérification mutuelle par chaque entité que l'autre entité possède un certificat statique valide au regard de la clé publique de l'infrastructure à clé publique, génération par chaque entité d'un certificat éphémère comprenant une clé publique éphémère signée avec une clé privée de l'entité, vérification mutuelle par chaque entité que le certificat éphémère de l'autre entité est valide au regard de son certificat statique, génération d'une clé de session par échange de clés Diffie-Hellman entre les deux entités, et utilisation de la clé de session pour crypter le canal de communication sécurisé.
Selon un mode de réalisation, le premier module de sécurité matérielle est configuré pour collecter une approbation émise par le dispositif approbateur de la façon suivante envoyer un challenge aléatoire et le descriptif de la transaction au dispositif approbateur, et attendre une réponse, recevoir du dispositif approbateur, sous une forme signée, le challenge ou une donnée comprenant le challenge, puis vérifier la validité de la signature, la transaction étant réputée approuvée si la signature est valide, et, pour adresser une approbation de transaction au premier module de sécurité matérielle, le dispositif approbateur est configuré pour afficher à un utilisateur personne physique une description de la transaction, recueillir l'approbation de l'utilisateur, signer le challenge ou une donnée comprenant le challenge avec une clé privée, puis envoyer la signature obtenue au premier module de sécurité matérielle.
Des modes de réalisation concernent également un procédé de gestion mutualisée de comptes de cryptoactifs, dans lequel 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 approbateur et satisfait une règle de gouvernance relative à la réalisation de la transaction, procédé caractérisé en ce qu’il est mis en œuvre au moyen d’un système comprenant : une plateforme de transaction exécutée par un serveur, sur laquelle des descriptions de transactions peuvent être créées, la plateforme de transaction étant configurée pour, après création d’une transaction, émettre une demande de réalisation de la transaction ; un premier module de sécurité matérielle couplé à la plateforme de transaction, configuré pour exécuter des règles de gouvernance relatives à la réalisation de transactions ; un service de signature configuré pour générer une signature d’une transaction à partir d’une donnée secrète ; un second module de sécurité matérielle ayant accès à la donnée secrète, configuré pour exécuter le service de signature, et une mémoire recevant la donnée secrète, la mémoire étant accessible en lecture et écriture au second module de sécurité matérielle et inaccessible au premier module de sécurité matérielle, le procédé comprenant, en réponse à une demande de réalisation d’une transaction émise par la plateforme de transaction, les étapes consistant à : au moyen du premier module de sécurité matérielle, solliciter l'approbation d’au moins un dispositif approbateur et vérifier si une règle de gouvernance applicable à la transaction demandée est satisfaite, et lorsque la règle de gouvernance est satisfaite, transmettre, au moyen du premier module de sécurité matérielle, une demande de signature de la transaction au second module de sécurité matérielle, et générer la signature de la transaction au moyen du second module de sécurité matérielle et à partir de la donnée secrète.
Selon un mode de réalisation, la demande de signature de la transaction inclut la transaction.
Selon un mode de réalisation, la demande de signature de la transaction transmise au second module de sécurité matérielle n’inclut pas la transaction et comprend seulement un condensat de la transaction produit par une fonction de hachage, et des données complémentaires permettant au second module de sécurité matérielle de générer la signature de la transaction à partir de ce condensat.
Selon un mode de réalisation, les données complémentaires comprennent un chemin de dérivation déterministe hiérarchique et une fonction de signature à utiliser pour générer la signature de la transaction, ou un identifiant de cette fonction.
Selon un mode de réalisation, le second module de sécurité matérielle ne reçoit jamais la transaction, et le procédé comprend les étapes consistant à prévoir un service de diffusion de transactions sur une blockchain exécuté par un serveur, fournir au service de diffusion la signature de la transaction fournie par le second module de sécurité matérielle, fournir au service de diffusion la transaction connue du premier module de sécurité matérielle mais inconnue du second module de sécurité matérielle, et diffuser la transaction sur la blockchain au moyen du service de diffusion.
Selon un mode de réalisation, le procédé comprend les étapes consistant à agencer le premier module de sécurité matérielle dans un premier lieu à accès restreint, et agencer le second module de sécurité matérielle dans un second lieu à accès restreint différent du premier lieu.
Selon un mode de réalisation, la donnée secrète est une graine permettant de générer une clé maître permettant elle-même de générer des clés privées de comptes de cryptoactifs, ou une clé maître permettant de générer des clés privées de comptes de cryptoactifs.
Selon un mode de réalisation, le procédé comprend au moins un dispositif approbateur, le dispositif approbateur comprenant des moyens de calcul cryptographique pour établir un canal de communication sécurisé avec le premier module de sécurité matérielle, dans lequel le premier module de sécurité matérielle et le dispositif approbateur sont membres d'une infrastructure à clé publique comprenant une autorité de certification fournissant ladite clé publique, et dans lequel l'établissement d'un canal de communication sécurisé entre le dispositif approbateur et le premier module de sécurité matérielle comprend les étapes suivantes vérification mutuelle par chaque entité que l'autre entité possède un certificat statique valide au regard de la clé publique de l'infrastructure à clé publique, génération par chaque entité d'un certificat éphémère comprenant une clé publique éphémère signée avec une clé privée de l'entité, vérification mutuelle par chaque entité que le certificat éphémère de l'autre entité est valide au regard de son certificat statique, génération d'une clé de session par échange de clés Diffie-Hellman entre les deux entités, et utilisation de la clé de session pour crypter le canal de communication sécurisé.
Selon un mode de réalisation, le procédé comprend une étape de collecte par le premier module de sécurité matérielle d'une approbation émise par le dispositif approbateur, l'étape de collecte comprenant les étapes consistant à au moyen du premier module de sécurité matérielle, envoyer un challenge aléatoire et le descriptif de la transaction au dispositif approbateur, au moyen du dispositif approbateur, afficher à un utilisateur personne physique une description de la transaction, recueillir l'approbation de l'utilisateur, signer le challenge ou une donnée comprenant le challenge avec une clé privée puis envoyer la signature obtenue au premier module de sécurité matérielle, et au moyen du premier module de sécurité matérielle, vérifier la validité de la signature, la transaction étant réputée approuvée si la signature est valide.
Description sommaire des dessins
Des modes de réalisation d'un procédé et d'un système de gestion mutualisée de comptes de cryptoactifs seront décrits dans ce qui suit à titre non limitatif en relation avec les figures jointes parmi lesquelles :
- la précédemment décrite représente schématiquement un système classique de gestion non mutualisée de comptes de cryptoactifs,
- la montre un système de gestion mutualisée de comptes de cryptoactifs selon un premier mode de réalisation,
- la montre plus en détail le système de la ,
- la montre un premier procédé de signature de transaction mis en œuvre dans le système de la ,
- la montre un second procédé de signature de transaction mis en œuvre dans le système de la ,
- la montre une configuration du système de la lors de la création de règles de gouvernance,
- la est un organigramme décrivant des étapes de création de règles de gouvernance,
- la montre une configuration du système de la lors d’une cérémonie de clés,
- la est un organigramme décrivant des étapes de la cérémonie de clés,
- la est un diagramme de séquence décrivant la réalisation d’une transaction au moyen du système de la ,
- la est un organigramme décrivant des étapes du diagramme de séquence de la ,
- la est un diagramme de séquence décrivant des étapes de création d’un canal sécurisé dans le système de la ,
- la est un organigramme décrivant des étapes du diagramme de séquence de la ,
- la est un diagramme de séquence décrivant des étapes d’approbation d’une transaction dans le système de la ,
- la est un organigramme décrivant des étapes du diagramme de séquence de la ,
- la montre un système de gestion mutualisée de comptes de cryptoactifs selon un second mode de réalisation,
- la , la , la et la montrent quatre modes de réalisation d’un procédé de signature de transaction mis en œuvre dans le système de la ,
- la est un diagramme de séquence décrivant la réalisation d’une transaction au moyen du système de la , et
- la est un organigramme décrivant des étapes du diagramme de séquence de la .
Description détaillée
La montre l’architecture générale d’un premier mode de réalisation d’un système de transaction à sécurité améliorée pour la gestion mutualisée de comptes de cryptoactifs.
Pour au moins un ensemble de comptes de cryptoactifs dérivés d’une clé maître K0, le système est prévu pour être utilisé par un ensemble de participants PAi dans lequel on distingue des copropriétaires des comptes OWNi ("shared-owner"), des administrateurs ADMi, et des opérateurs OPi. Il comprend plateforme de transaction TPF permettant à une pluralité d’opérateurs OPi (OP1… OPN) de réaliser des opérations sur de tels comptes de cryptoactifs, sous réserve de l'accord d’un nombre déterminé d’opérateurs défini par des règles de gouvernance.
Les administrateurs définissent les règles de gouvernance. Ils peuvent également, dans un mode 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 K0i qui leur sont propres. Les opérateurs OPi initient des transactions ou approuvent des transactions initiées par d'autres opérateurs. Chaque participant ADMi, OWNi ou OPi comprend des moyens de calcul cryptographique.
Le système représenté comprend avantageusement deux modules de sécurité matérielle HSM1, HSM2. Le premier module de sécurité matérielle HSM1 est couplé à un premier serveur SRV1 et le second module de sécurité matérielle HSM2 est couplé à un second serveur SRV2. Le terme "module de sécurité matérielle" désigne un module du type discuté plus haut, généralement logé dans un datacenter, offrant un haut niveau de sécurité matérielle et logicielle, par exemple conforme à norme FIPS 140-2 de niveau III.
Les participants PAi (ADMi, OWNi ou OPi) peuvent se relier au serveur SRV1 via une liaison de données sécurisée https1. Le serveur SRV1 peut se relier au serveur SRV2 via une liaison de données sécurisée https2. Les copropriétaires OWNi peuvent également se relier au serveur SRV2 via les liaisons de données sécurisées https1 et https2, le serveur SRV1 étant de préférence utilisé comme serveur intermédiaire ou serveur proxy pour leur permettre de se relier au module de sécurité HSM2.
Il sera noté que bien que des liaisons de type https soient citées à titre d’exemple dans la présente description, ces liaisons de données sécurisées peuvent être de tout autre type connu, par exemple VPN, TLS, etc.
Le serveur SRV1 comprend et exécute la plateforme de transaction TPF, ainsi qu’un service de notification NOTIF et un service orchestrateur ORCH. Le module HSM1 comprend et exécute un service de gouvernance GOV. Le serveur SRV2 comprend et exécute un service de liaison LKS permettant d’établir la liaison https2 avec le module HSM2. Le module HSM2 comprend et exécute un service de signature SIGN1. Le module HSM2 comprend et exécute également un service de cérémonie de clés KCER1, permettant d’enregistrer la clé maître K0 dans une mémoire MEM. Enfin, le système comprend un service BCAST de diffusion de transactions signées sur des réseaux de blockchains BCN.
Le service BCAST est montré ici à titre non limitatif comme exécuté par le serveur SRV1 mais pourrait aussi être exécuté par le serveur SRV2, comme montré en traits pointillés, ou tout autre serveur ou dispositif associé au système.
La mémoire MEM recevant la clé maître K0 peut être interne ou externe au module HSM2. Le système est conçu pour que la mémoire MEM soit inaccessible au module HSM1 et ne puisse être lue et écrite que par le module HSM2. En pratique, les modules HSM1 et HSM2 sont de préférence agencés dans des lieux sécurisés différents, pouvant être très éloignés l’un de l’autre.
Trois types d’opérations peuvent être réalisées avec le système : l’enregistrement de règles de gouvernance, la génération de la clé maître K0 au cours d’une cérémonie de clés, et des transactions sur des comptes de cryptoactifs. Le système offre un niveau de sécurité plus élevé que les systèmes classiques grâce à la prévision des deux modules de sécurité matérielle HSM1, HSM2 et la séparation de la fonction de gouvernance - c'est-à-dire la gestion des processus d'approbation de transaction - et de la fonction de signature des transactions.
La montre un mode de réalisation plus détaillé du système de la . Chaque participant PAi comprend ici :
- un dispositif de sécurité personnel PSDi, associé à un dispositif hôte HDVi exécutant une application compagnon HSW, par exemple l’application "Ledger Live" développée par la demanderesse, et
- un utilisateur personne physique USRi, qui peut agir à la fois sur une interface homme-machine du dispositif hôte HDVi ou sur une interface homme-machine du dispositif de sécurité personnel PSDi.
Dans un mode de réalisation, le dispositif de sécurité personnel PSDi est un dispositif ayant une architecture de type porte-monnaie matériel de cryptoactifs et comprenant un élément sécurisé en circuit intégré associé à un microcontrôleur en circuit intégré, le microcontrôleur étant configuré pour permettre à l'élément sécurisé d’établir un canal de communication sécurisé avec le module de sécurité matérielle HSM1 par l’intermédiaire du dispositif hôte HDVi exécutant l’application compagnon HSW. Un tel dispositif de sécurité est par exemple le dispositif commercialisé par la demanderesse sous l’appellation "Ledger BLue", "Nano" ou "Stax", ou un dispositif équivalent.
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é réalisé à partir d'un élément sécurisé en circuit intégré ou à partir d'un environnement d'exécution de confiance TEE qui émule un élément sécurisé. Un tel téléphone exécute une application sécurisée qui assure la conduite des étapes décrites dans ce qui suit.
Dans d'autres modes de réalisation, les dispositifs participants PAi peuvent être des dispositifs informatiques portatifs ou non qui se relient au serveur SRV1 par l'intermédiaire d'une interface de programmation d'application ("API").
Ces différents types de dispositifs participants peuvent naturellement coexister dans le système présentement décrit.
Dans un mode de réalisation, les dispositifs de sécurité personnels PSDi, le module HSM1 et le module HSM2 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, dH2, une clé publique statique, respectivement PPi, PH1, PH2, et un certificat, respectivement CPi, CH1, CH2. Ce certificat est fourni par l’autorité de certification CA et comprend leur clé publique 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 établir un canal de communication sécurisé SC1i avec le module HSM1. Le module HSM1 peut établir un canal de communication sécurisé SC2 avec le module HSM2. Chaque dispositif PSDi peut également établir un canal de communication sécurisé SC3i avec le module HSM2. Le canal de communication sécurisé SC1i entre un PSDi et le module HSM1 est établi ici à travers la liaison de données sécurisée https1. Le canal de communication sécurisé SC3i entre un PSDi et le module HSM1 est établi ici à travers la liaison de données sécurisée https1 et la liaison de données sécurisée https2. Le canal de communication sécurisé SC2 entre les modules HSM1 et HSM2 est établi ici à travers la liaison de données sécurisée https2.
Les figures 4A, 4B illustrent deux modes de réalisation d’un procédé de signature de transaction mis en œuvre au moyen du système de la . Sur la , le module HSM1, après avoir reçu un descriptif de la transaction et vérifié que la règle de gouvernance associée est satisfaite, transmet la transaction T au module HSM2, généralement sous une forme brute appelée « transaction brute » (« raw transaction »)
À 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"
}
La transaction selon l'exemple ci-dessus, lorsqu'elle est transformée en transaction brute, peut par exemple avoir la valeur suivante (en hexadécimal) :
f86e826f4a8505f901eadd826b6c94388c818ca8b9251b393131c08a736a67ccbl92978801167140fda3d0818025a0dcbal464c58f31892bd0ae8e6271f838189cd344d98e928f3194efe4bce9ebc6a04fOfc71bee74ala6fafbel7cde3c35981c93b58703856ef5dd53884albl53773
Le module HSM2, au moyen de son service de signature SIGN1, signe ensuite la transaction brute T à l'aide d'une clé privée du compte de cryptoactif concerné, dérivée de la clé maître K0 détenue dans la mémoire MEM, et produit une signature SIG1(T, K0) fonction de la transaction brute T et du secret K0. Chaque algorithme de signature est spécifique à la blockchain BCN considérée. À titre d'exemple, les deux principales chaînes de blocs (Ethereum et Bitcoin) utilisent 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
}
La transaction T et sa signature SIG1 sont ensuite transmises au service de diffusion BCAST pour qu’il diffuse la transaction sur la blockchain BCN concernée. Dans ce mode de réalisation, le module HSM2 a connaissance de la transaction puisqu’elle lui a été communiquée pour génération de la signature SIG1. Le service de diffusion BCAST peut donc être exécuté par le serveur SRV2 couplé au module HSM2, comme montré en traits pointillés sur la , et recevoir la transaction T du module HSM2. Il peut également être exécuté par le serveur SRV1 couplé au module HSM1. Dans ce cas, la signature SIGN1 est communiquée au module HSM1 par le module HSM2. Dans ce procédé, les liaisons de données entre les modules HSM1 et HSM2 se font à travers des canaux de communications sécurisés, dont des exemples de réalisation seront décrits plus loin.
Le mode de réalisation de la se distingue de celui de la en ce que le module HSM1 ne communique pas la transaction brute T au module HSM2, mais le condensat ou « hashcode » HT de celle-ci ou d’une partie de celle-ci, produit par une fonction de hachage, par exemple la fonction SHA-256. En d’autres termes, la première étape de production de la signature, à savoir le calcul de son condensat, est réalisé par le module HSM1. Dans ce cas le module HSM1 transmet également au module HSM2 des informations qui lui sont nécessaires pour générer la signature de la transaction, tel que le chemin de dérivation DRV applicable (chemin de dérivation déterministe hiérarchique) et la fonction de signature ECDSA ou un identifiant de celle-ci (le module HSM2 ayant généralement en mémoire un catalogue de fonctions pouvant être nécessaires pour générer des signatures). Ensuite, la transaction T et sa signature SIG1 sont comme précédemment transmises au service de diffusion BCAST pour qu’il diffuse la transaction sur la blockchain BCN.
Dans ce mode de réalisation, le module HSM2 n’a pas, à ce stade, connaissance de la transaction T puisqu’elle ne lui a pas été communiquée pour la génération de la signature SIG1. Il peut donc être décidé, pour augmenter la sécurité du système, de faire en sorte que la transaction ne lui soit jamais communiquée, puisqu’il n’en a pas besoin, et qu’elle ne soit également jamais communiquée au serveur SRV2 couplé au module HSM2. Ainsi, le service de signature ne peut que communiquer la signature SIG1 au service de diffusion BCAST. La transaction T est alors communiquée au service BCAST par le module HSM1. Dans ce cas, le service de diffusion BCAST ne peut pas être exécuté par le serveur SRV2, et est exécuté par le serveur SRV1, comme montré en traits continus sur la , puisque celui-ci a connaissance de la transaction T.
En résumé, l’architecture de système de gestion mutualisée de transaction qui vient d’être proposée comprend deux modules de sécurité matérielle distincts, le premier pour appliquer des règles de gouvernance et autoriser la signature de transactions lorsque les règles de gouvernance sont satisfaites, le second pour signer les transactions. Selon le mode de réalisation de la , le module de sécurité matérielle qui autorise la signature de transactions ne peut pas les signer lui-même car il ne possède pas le secret K0 permettant de les signer, et le module de sécurité matérielle qui signe les transactions n’a pas connaissance de celles-ci.
La montre la configuration du système de la lors de la mise en œuvre d'un procédé d'enregistrement de règles de gouvernance. Le serveur SRV2 et le module HSM2 n'interviennent pas dans ce processus et ne sont pas représentés. L'organigramme de la décrit un mode de réalisation de ce procédé. A une étape G1, un administrateur ADMi se connecte au service ORCH du serveur SRV1 et sollicite la configuration du service de gouvernance GOV. A une étape G2, un canal de communication sécurisé SC1i est créé entre le module HSM1 et le dispositif de sécurité personnel PSDi de l'administrateur ADMi, et le dispositif de sécurité personnel PSDi se connecte au service de gouvernance GOV. A une étape G3, l'administrateur définit une ou plusieurs règles de gouvernance. A une étape G4, le dispositif de sécurité personnel PSDi de l'administrateur adresse les règles de gouvernance souhaitées au service de gouvernance via le canal SC1i. A une étape G5, le service de gouvernance demande au service de notification NOTIF du serveur SRV1 d'envoyer aux autres administrateurs ADMi une notification de vote des règles de gouvernance. A une étape G6, des canaux de communication sécurisés SC1i sont établis entre les modules de sécurité personnels PSDi des autres administrateurs ADMi et le service de gouvernance. A une étape G7, les dispositifs de sécurité personnels PSDi des autres administrateurs communiquent au service de gouvernance leur accord ou leur refus de chaque règle proposée. A une étape G8, les règles sont adoptées en tout ou en partie, en fonction du vote des administrateurs.
Les règles de gouvernance peuvent être définies et adoptées selon divers procédés autres que celui qui vient d'être décrit. Des règles d'adoption définissant un quorum et une règle de majorité pour l'adoption de règles de gouvernance peuvent être inscrites "en dur" dans le service de gouvernance. Les règles de gouvernance peuvent être simples, complexes, uniques ou multiples. Elles peuvent par exemple définir un nombre minimal d'opérateurs non identifiés devant approuver une transaction par type de cryptoactif concerné et/ou en fonction du montant de la transaction, ou définir nommément les opérateurs qui peuvent approuver une transaction par type de cryptoactif concerné et/ou en fonction du montant de la transaction. Elles peuvent également définir les opérateurs autorisés à créer une transaction sur la plateforme TPF pour tel ou tel type de cryptoactif, et ceux qui ne sont pas autorisés et ne peuvent qu'être approbateurs de transactions.
Dans un mode de réalisation, la sollicitation puis la collecte, par le service de gouvernance, d'une approbation d'une règle de gouvernance émise par un administrateur comprend les étapes suivantes :
- le service de gouvernance envoie un challenge aléatoire et le descriptif de la règle de gouvernance aux autres dispositifs de sécurité PSDi des administrateurs concernés,
- chaque dispositif de sécurité PSDi de chaque administrateur affiche ensuite à l'utilisateur administrateur correspondant USRi la description de la règle de gouvernance, recueille l'approbation de l'utilisateur, puis signe le challenge avec sa clé privée dPi, en envoie le challenge signé au service de gouvernance,
- le service de gouvernance vérifie la validité de la signature, la règle de gouvernance étant réputée approuvée par l'administrateur concerné si la signature est valide.
La montre une configuration du système de la lors d’une cérémonie de clés. L'organigramme de la décrit des étapes d'un mode de réalisation de cette cérémonie de clés. A une étape K1, un copropriétaire OWNi se connecte au service orchestrateur ORCH du serveur SRV1. A une étape K2, le copropriétaire OWNi active le service de cérémonie de clés KCER1 via le service orchestrateur. A une étape K3, le service de notification NOTIF du serveur SRV1 envoie à chaque autre copropriétaire OWNi une notification d'invitation à la cérémonie. A une étape K4, des canaux de communications sécurisés SC3i sont établis entre le dispositif de sécurité personnel PSDi de chaque copropriétaire OWNi et le service de cérémonie de clés KCER1. A une étape K5, le service KCER1 reçoit la clé maître K0i ou une partie de la clé maître de chaque dispositif PSDi. A une étape K6 le service KCER1 génère la clé privée K0 à partir des clés maîtres ou des parties de clés maîtres reçues, et la stocke dans la mémoire MEM.
Dans un mode de réalisation, des fragments des clés maîtres sont générés au moyen d'une fonction de dérivation BIP32 m/code1'/key dans laquelle
"m" est la clé maître
"/" : indique la séparation entre les niveaux de dérivation
"code1'" est un code spécifique du procédé, pouvant être arbitraire,
"key" indique la clé de niveau suivant, dérivée de la clé parente.
La clé maître K0 est ensuite obtenue en calculant le OU EXCLUSIF de tous les fragments dérivés des clés maîtres des dispositifs PSDi des copropriétaires OWNi. Les clés des comptes de cryptoactif sont ensuite dérivées de cette clé. Par exemple la clé privée étendue ou clé maître xprv d'un compte Bitcoin est générée classique en appliquant à la clé K0 l'algorithme de hachage HMAC-SHA512 en utilisant comme clé les termes "Bitcoin Seed" et comme message les termes "master seed".
La décrit la réalisation d’une transaction au moyen du système de la et la décrit des étapes montrées par la . Dans ce qui suit, des opérateurs sollicités pour l'approbation de la transaction seront appelés "approbateurs APi" pour les distinguer de l'opérateur OPi à l'origine de la demande de transaction, ou opérateur créateur.
A une étape S1, un opérateur OPi se connecte à la plateforme de transaction TPF. A une étape S2, l’opérateur crée la description de la transaction. A une étape S3, la plateforme TPF envoie au service de gouvernance GOV une demande de transaction comprenant la description de la transaction. A une étape S4, le service de gouvernance génère une demande d’approbation de la transaction à l’attention d’approbateurs APi qui sont désignés par la règle de gouvernance applicable comme aptes à approuver la demande de transaction. Un exemple de réalisation d’une telle demande d’approbation, à partir d’un challenge aléatoire, sera décrit plus loin.
A une étape S5, le service de gouvernance informe le service de notification NOTIF qu'une transaction est demandée. A une étape S6, le service de notification envoie une notification de transaction à tous les opérateurs approbateurs APi concernés, désignés par la règle de gouvernance applicable. A une étape S7, le dispositif de sécurité personnel PSDi de chaque approbateur APi crée un canal sécurisé SC1i avec le service de gouvernance ( ). A une étape S8, le service de gouvernance envoie à chaque dispositif de sécurité personnel PSDi de chaque approbateur APi la description de la transaction et la demande d'approbation. A une étape S9, chaque approbateur APi examine et approuve la transaction. Il s'agit ici de l'utilisateur USRi personne physique qui vérifie la transaction telle qu'affichée par le dispositif de sécurité personnel PSDi. Cette étape met en œuvre un principe de sécurité connu appelé "WYSIWYS", qui signifie "vous ne signez que ce que vous voyez" ("What-You-See-Is-What-You-Sign"). A une étape S10, chaque approbateur APi confirme son approbation à son dispositif de sécurité personnel PSDi. Il s'agit toujours ici de la personne physique qui agit sur l'interface homme-machine de son dispositif de sécurité personnel pour lui confirmer son approbation. A une étape S11, le dispositif de sécurité personnel PSDi de chaque approbateur génère une approbation de la transaction. A une étape S12, le dispositif de sécurité personnel de chaque approbateur envoie son approbation de la transaction au service de gouvernance GOV. Comme montré sur la au moyen d'un cadre portant le libellé "SC1i", les transmissions de données entre le service de gouvernance et chaque dispositif PSDi au cours des étapes S8 et S12 sont réalisées au moyen du canal sécurisé SC1i. A une étape S13, le service de gouvernance GOV vérifie l'approbation de la transaction reçue de chaque dispositif PSDi.
Si les conditions d'approbation de la transaction sont réunies, notamment si le quorum d'approbateurs requis est atteint, le système exécute des étapes figurant dans un cadre "QR" qui signifie "Quorum atteint" ("Quorum Reached"), sinon le système exécute des étapes figurant dans un cadre "QNR" qui signifie "Quorum non atteint" (Quorum Not Reached"). On décrira en premier lieu des étapes figurant dans le cadre QR.
A une étape S20, le service de gouvernance génère une transaction brute ("raw transaction") à partir de la description de la transaction. Ce calcul de la transaction brute montré ici comme réalisé par le service de gouvernance peut toutefois être confié au serveur SRV1 ou à tout service externe approprié.
Une fois la transaction brute générée, le service de gouvernance crée à une étape S30 le canal de communication sécurisé SC2 avec le service de signature SIGN1 exécuté par le module HSM2, via la liaison https2.
A une étape S31, le service de gouvernance envoie au service de signature SIGN1 la transaction brute T (mode de réalisation de la ), ou lui envoie le condensat HT de la transaction brute accompagné du chemin de dérivation DRV et de l’identifiant IDF de la fonction de signature (mode de réalisation de la ). La transmission de ces données peut être accompagnée d’une demande de signature, qui peut être implicite ou prendre la forme d’une commande. A une étape S32, le service de signature SIGN1 signe la transaction brute.
A une étape S33, la transaction T et sa signature SIG1 sont envoyées au service de diffusion BCAST. La transaction T est fournie par le service de signature SIGN1 en même temps que sa signature SIG1 si le service de signature a connaissance de la transaction (mode de réalisation de la ). Si le service de signature n’a pas connaissance de la transaction T (mode de réalisation de la ), celle-ci est communiquée par le service de gouvernance GOV du module HSM1 au cours d’une étape S33’. A une étape S34, le service BCAST place la transaction signée sur la blockchain BCN concernée.
Dans le cas où les conditions d'approbation prévues par la règle de gouvernance applicable ne seraient pas satisfaites (cadre QNR), le service de gouvernance efface la transaction de sa mémoire à une étape S50. A une étape S51, il envoie au service de notification NOTIF une information d'échec de l'approbation de la transaction. A une étape S52, le service de notification envoie des notifications d'échec à la plateforme de transaction, au créateur et aux approbateurs.
La décrit des étapes de création d’un canal sécurisé entre deux entités du système de la . La décrit des étapes du diagramme de séquence de la . Les deux entités sont désignées X et Y. Si l'entité X est un dispositif de sécurité personnel PSDi, l'entité Y peut être le module HSM1 (service de gouvernance GOV) pour la création du canal SC1i, ou le module HSM2 (service de signature ou de cérémonie de clés) pour la création du canal SC3i. L'entité X peut aussi être le module HSM1 et l'entité Y être le module HSM2 pour la création du canal SC2.
Chaque entité X, Y possède une clé privée dX, dY, une clé publique PX, PY, et un certificat CX, CY comprenant sa clé publique et une signature de celle-ci au moyen de la clé privée dA de l'autorité de certification CA :
CX = [PX, sign(PX, dA)]
CY = [PY, sign(PY, dA)]
A une étape S60, l'entité X génère une paire de clés éphémères privée et publique deX, PeX. A une étape S61, l'entité X génère un certificat éphémère CeX comprenant sa clé publique éphémère PeX et une signature de celle-ci avec sa clé privée dX :
CeX = [PeX, sign(PeX, dX)]
A une étape S62, l'entité X envoie à l'entité Y sa clé publique éphémère PeX, le certificat éphémère CeX , sa clé publique PX et son certificat CX. A une étape S63, l'entité Y vérifie la chaîne de certification de l'entité X :
PA → CX(PX) → CeX(PeX)
En effet, la clé publique PA de l'autorité de certification lui permet de vérifier la validité de la signature de la clé publique PX figurant dans le certificat CX, puis la clé publique vérifiée PX lui permet de vérifier la validité de la signature de la clé publique éphémère PeX figurant dans le certificat éphémère.
Si la vérification est concluante, à une étape S64 l'entité Y génère une paire de clés éphémères privée et publique deY, PeY. A une étape S65, l'entité Y génère un certificat éphémère CeY comprenant sa clé publique éphémère PeY et une signature de celle-ci avec sa clé privée dY :
CeY = [PeY, sign(PeY, dY)]
A une étape S66, l'entité Y génère une clé de session éphémère k à partir de sa clé privée éphémère deY et de la clé publique éphémère PeX de l'entité X, au moyen d'une fonction d'échange de clés telle que par exemple la fonction ECDH (échange de clé Diffie Hellman basée sur les courbes elliptiques ou "Elliptic Curve Diffie–Hellman"), soit :
k = ECDH(deY , PeX)
A une étape S67, l'entité Y envoie à l'entité X sa clé publique éphémère PeY ainsi que, sous une forme cryptée au moyen de la clé k, son certificat éphémère CeY et son certificat CY contenant sa clé publique PY :
PeY, {CeY , CY}k
A une étape S68, l'entité X génère elle-même la clé de session k à partir de sa clé privée éphémère deX et de la clé publique éphémère PeY de l'entité Y, au moyen de la même fonction que celle utilisée par l'entité Y, ici la fonction ECDH :
k = ECDH(deX , PeY)
A une étape S69, l'entité X est donc en mesure de décrypter le message {CeY, CY}k.
A une étape S70, l'entité X vérifie la chaîne de certification de l'entité Y :
PA → CY(PY) → CeY(PeY)
En d'autres termes, et comme précédemment, la clé publique PA de l'autorité de certification lui permet de vérifier la validité de la signature de la clé publique PY figurant dans le certificat CX, puis la clé publique certifiée PY lui permet de vérifier la validité de la signature de la clé publique éphémère PeY figurant dans le certificat éphémère.
A une étape S71, les deux entités se sont authentifiées mutuellement comme appartenant à la même infrastructure à clé publique. La clé de session éphémère k qu'elles ont communément générée n'est pas rejouable et n'est pas non plus susceptible d'une attaque de l'homme du milieu. Elle peut donc être utilisée en toute sécurité pour crypter les messages échangés.
Bien que l'on ait décrit ici une méthode avantageuse de création de canaux sécurisés à base d'un échange de clé Diffie-Hellman, diverses autres méthodes pourraient être prévues par l'homme de l'art pour former les canaux sécurisés SC1i, SC3i et SC2, notamment des techniques à base de cryptographie symétrique utilisant des clés privées enregistrées dans les modules HSM1, HSM2.
La décrit un mode de réalisation d'un procédé d’approbation d’une transaction par un approbateur APi, et montre les étapes S4, S7 à S13 de la , plus des étapes S100 et S101 intervenant en cas de non-approbation de la transaction par l'opérateur. La décrit les étapes de la selon ce mode de réalisation.
À l'étape S4, le service de gouvernance GOV génère un challenge C pour l'approbation de la transaction :
C = RandomBytes(32)
"RandomBytes(32)" étant une fonction connue qui génère une chaîne de 32 octets (256 bits) de données aléatoires.
À l'étape S7, le service de gouvernance crée le canal sécurisé SC1i avec le dispositif personnel de sécurité PSDi de l'approbateur APi. À l'étape S8, le service de gouvernance envoie la description de la transaction et le challenge C au dispositif PSDi. À l'étape S9, l'approbateur APi examine et approuve la transaction. Comme précisé plus haut, il s'agit ici de l'utilisateur USRi personne physique qui vérifie la transaction. À l'étape S10, si l'approbateur personne physique a approuvé la transaction, il confirme son approbation au dispositif de sécurité personnel PSDi par une action sur celui-ci (cadre "Approve" sur la ). À l'étape S11, le dispositif PSDi signe le challenge C avec sa clé privée dPi :
S = Sign(dPi, C)
Dans une variante, la description de la transaction pourrait être concaténée avec le challenge, ou toute autre donnée :
S = Sign(dPi, C ||T)
À l'étape S12 le dispositif PSDi envoie le challenge signé au service de gouvernance. À l'étape S13, le service de gouvernance vérifie la signature S du challenge. Si l'approbateur personne physique, à une étape S100, indique au dispositif PSDi qu'il refuse la transaction, le dispositif renvoie un message d'erreur au service de gouvernance au cours d'une étape S101.
La montre l’architecture d’un second mode de réalisation d’un système de transaction pour la gestion mutualisée de comptes de cryptoactifs. Le système se distingue de celui de la en ce qu’il met en œuvre un algorithme de signature multipartite, également appelé algorithme de signature MPC (« Multi-Party Computation »), par lequel une signature est générée par au moins deux parties. Ainsi, en sus du second module de sécurité matérielle HSM2 couplé au serveur SRV2, le système comprend au moins ’un dispositif de signature supplémentaire SIGNDV.
Le dispositif SIGNDV est un dispositif sécurisé, par exemple de type HSM, ou un dispositif de type PSD, accessible via un service de liaison LKS’ exécuté par un dispositif DV3. Le dispositif DV3 est par exemple un serveur si le dispositif SIGNDV est de type HSM ou un dispositif hôte si le dispositif SIGNDV est de type PSD. Le service de liaison LKS’ permet d’établir une liaison de données sécurisée https3 entre le dispositif SIGNDV et le serveur SRV1. Cette liaison permet par ailleurs aux dispositifs de sécurité personnels PSDi des opérateurs OPi d’établir avec le module HSM2 un canal de communication sécurisé SC4i via les liaisons https1 et https3. À cet effet, le dispositif SIGNDV est ici membre de l’infrastructure à clé publique PA et comprend une clé privée dD, une clé publique PD et un certificat CD.
Le dispositif SIGNDV comprend et exécute un service de signature MSIGN1 utilisant une part (« share ») SH1 de signature MPC qui est stockée dans une mémoire MEM1. De même, le module HSM2 comprend et exécute un service de signature MSIGN2 qui remplace le service SIGN1 précédemment décrit et utilise une part SH2 de signature stockée dans une mémoire MEM2. Le module HSM1 n'a accès à aucune des mémoires MEM1, MEM2. Le module HSM2 n'a pas accès à la mémoire MEM1 du dispositif SIGNDV et le dispositif SIGNDV n'a pas accès à la mémoire MEM2 du module HSM2.
Chaque part SH1, SH2 est de façon classique une partie d’un secret partagé et est générée au cours d’une cérémonie de clés au cours de laquelle les services MSIGN1 et MSIGN2 échangent des informations via des canaux sécurisés. Dans certains modes de réalisation, la cérémonie de clés peut inclure une étape de tirage d’un nombre aléatoire permettant de générer les parts SH1, SH2. Dans d’autres modes de réalisation, des copropriétaires OWNi peuvent participer à la cérémonie de clés afin que les clés maîtres K0i de leurs dispositifs PSDi respectifs soient utilisées pour générer les parts SH1, SH2.
Les figures 16A, 16B, 16C et 16D illustrent plusieurs modes de réalisation d’un procédé de signature MPC mis en œuvre par le système de la . Dans les modes de réalisation illustrés sur les figures 16A et 16B, la signature MPC d’une transaction est produite par accumulation, le service de signature MSIGN2 fournissant une signature SIG2 qui est fonction d’une signature SIG1 fournie par le service de signature MSIGN1 et qui constitue la signature de la transaction. Dans les modes de réalisation illustrés sur les figures 16A et 16B, la signature MPC d’une transaction est produite par combinaison, le service de signature MSIGN1 fournissant une signature partielle SIG1 et le service de signature MSIGN2 fournissant une signature partielle SIG2. Les deux signatures partielles sont combinées au moyen d’une fonction de combinaison Fmpc pour obtenir la signature de la transaction. Cette fonction de combinaison peut être exécutée par le service de diffusion BCAST ou tout autre service pouvant être prévu en amont du service BCAST pour la préparation des transactions signées devant être diffusées.
Dans le mode de réalisation de la , le module HSM1 fournit la transaction T au service de signature MSIGN1 du dispositif SIGNDV, et ce dernier fournit au module HSM2 la signature SIG1 qui est fonction de la transaction et de la part SH1. Le service de signature MSIGN1 fournit la transaction T et la signature SIG1 au service de signature MSIGN2, et ce dernier fournit au service de diffusion BCAST la signature SIG2 qui est fonction de la transaction T, de la signature SIG1 et de la part SH2. Alternativement, la transaction T peut être fournie au service MSIGN2 par le module HSM1. Le service BCAST reçoit la transaction du service MSIGN2 mais pourrait aussi la recevoir directement du module HSM1.
Dans ce mode de réalisation où la transaction T est connue des différentes parties du système, le service de diffusion BCAST peut être exécuté par le serveur SRV1 couplé au module HSM1, comme illustré en traits pleins sur la , ou encore par le serveur SRV2 couplé au module HSM2 ou par le dispositif DV3 couplé au dispositif de signature SIGNDV, comme illustré en traits pointillés sur la .
Dans le mode de réalisation de la , le module HSM1 fournit au service de signature MSIGN1 le condensat HT de la transaction, le chemin de dérivation DRV approprié et l’identifiant IDF de la fonction de signature appropriée (ou la fonction de signature elle-même). Le service de signature MSIGN1 fournit au module HSM2 la signature SIG1 qui est fonction du condensat HT et de la part SH1. Le service de signature MSIGN1 fournit le condensat HT, le chemin de dérivation DRV, l’identifiant IDF et la signature SIG1 au service de signature MSIGN2, qui fournit au service de diffusion BCAST la signature SIG2 qui est fonction du condensat HT, de la signature SIG1 et de la part SH2. Alternativement, le condensat HT, le chemin de dérivation DRV, l’identifiant IDF peuvent être fournis au service MSIGN2 par le module HSM1. Le service BCAST reçoit ici la transaction du module HSM1, le service MSIGN2 ne le connaissant pas.
Dans ce mode de réalisation où la transaction T n’est pas connue des deux services de signature MSIGN1, MSIGN2, le service de diffusion BCAST peut être exécuté par le serveur SRV1 couplé au module HSM1. On obtient ainsi comme précédemment une architecture de système dans laquelle le module de sécurité matérielle qui autorise la signature de transactions ne peut pas les signer lui-même car il ne possède pas les secrets SH1, SH2 permettant de les signer, et les services de signature qui signent les transactions n’ont pas connaissance de celles-ci.
Dans le mode de réalisation de la , le module HSM1 fournit la transaction T au service de signature MSIGN1 du dispositif SIGNDV et au service de signature MSIGN2 du module HSM2. Le service de signature MSIGN1 fournit au service de diffusion BCAST une signature partielle SIG1 qui est fonction de la transaction et de la part SH1. Le service de signature MSIGN2 fournit au service de diffusion BCAST une signature partielle SIG2 qui est fonction de la transaction et de la part SH2. Le service BCAST combine les deux signatures partielles au moyen de la fonction Fmpc pour obtenir la signature de la transaction. La transaction T peut être fournie au service BCAST par l’un ou l’autre des dispositifs signataires ou par le module HSM1.
Dans ce mode de réalisation, bien que la transaction T soit connue des différentes parties du système, aucune des deux parties signataires ne peut signer la transaction si elle n’a pas connaissance de la signature partielle fournie par l’autre partie. On pourra préférer de faire exécuter le service de diffusion BCAST par le serveur SRV1 couplé au module HSM1, comme illustré en traits pleins sur la , plutôt que de le faire exécuter par l’une ou l’autre des deux parties signataires.
Dans le mode de réalisation de la , le module HSM1 fournit le condensat HT de la transaction, le chemin de dérivation DRV et l’identifiant IDF de la fonction de signature au service de signature MSIGN1 du dispositif SIGNDV et au service de signature MSIGN2 du module HSM2. Le service de signature MSIGN1 fournit au service de diffusion BCAST une signature partielle SIG1 qui est fonction du condensat HT et de la part SH1. Le service de signature MSIGN2 fournit au service de diffusion BCAST une signature partielle SIG2 qui est fonction du condensat HT et de la part SH2. Le service BCAST combine les deux signatures partielles au moyen de la fonction Fmpc pour obtenir la signature de la transaction. La transaction T est fournie ici au service BCAST par le module HSM1.
Dans ce mode de réalisation, on pourra faire exécuter le service de diffusion BCAST par le serveur SRV1 couplé au module HSM1, comme illustré en traits pleins sur la , pour obtenir comme précédemment une architecture de système dans laquelle le module de sécurité matérielle qui autorise la signature de transactions ne peut pas les signer lui-même car il ne possède pas les secrets SH1, SH2 permettant de les signer, et les services de signature qui signent les transactions n’ont pas connaissance de celles-ci.
La est un diagramme de séquence décrivant la réalisation d’une transaction au moyen du système de la selon l’un des modes de réalisation des figures 16C ou 16D. La décrit des étapes du diagramme de séquence de la . Le procédé de signature tel que montré sur la et décrit par la comprend des étapes identiques à celles du diagramme de la , à savoir les étapes S1 à S20, S50 à S52. Ce procédé se distingue essentiellement du procédé de la en ce que les étapes S30 à S34 de signature de la transaction et de diffusion de celle-ci sont remplacées par des étapes S40 à S46. A l'étape S40, le service de gouvernance GOV crée un canal de communication sécurisé SC2a, via la liaison https3, avec le service de signature MSIGN1, et un canal de communication sécurisé SC2b, via la liaison https2, avec le service de signature MSIGN2. A une étape S41, le service de gouvernance envoie au service de signature MSIGN1, via le canal sécurisé SC2a, la transaction brute T ( ) ou lui envoie son condensat HT, le chemin de dérivation DRV et l’identifiant IDF ( ). Ces données sont éventuellement accompagnées d’une demande de signature (qui peut être implicite ou prendre la forme d’une commande). A une étape S41’, le service de gouvernance envoie au service de signature MSIGN2, via le canal sécurisé SC2b, la transaction brute T ( ) ou lui envoie son condensat HT, le chemin de dérivation DRV et l’identifiant IDF ( ). Ces données sont éventuellement accompagnées d'une demande de signature (qui peut être implicite ou prendre la forme d’une commande).
A une étape S42, le service de signature MSIGN1 génère la signature partielle SIG1 au moyen de la part SH1. A une étape S43, le service de signature MSIGN1 envoie la signature partielle SIG1 au service de diffusion BCAST.
A une étape S44, le service de signature MSIGN2 génère la signature partielle SIG2 au moyen de la part SH2. A une étape S45, le service de signature MSIGN1 envoie la signature partielle SIG1 au service de diffusion BCAST.
À ce stade, le processus est sécurisé par la signature partielle de la transaction de sorte que si la transaction est interceptée et altérée par un attaquant, la signature partielle sera erronée et la signature finale le sera aussi. En effet, ni le module HSM2, ni le dispositif SIGNDV ne peuvent signer la transaction seuls. Pour signer la transaction, il faut les deux signatures.
A une étape S46, le service BCAST assemble les signatures partielles SIG1, SIG2 au moyen de la fonction Fmpc pour obtenir la signature de la transaction, puis diffuse la transaction signée sur la blockchain BCN concernée. Si les signatures SIG1, SIG2 ont été générées à partir du condensat HT, les services de signature MSIGN1, MSIGN2 ne peuvent pas communiquer la transaction brute T au service BCAST. Une étape de transmission de la transaction T au module BCAST, par le module HSM1, non représentée sur la , peut alors être prévue (Cf. ).
Il apparaîtra clairement à l'homme de l'art que les modes de réalisation qui viennent d'être décrits d’un système de transaction à sécurité améliorée pour la gestion mutualisée de comptes de cryptoactifs, sont susceptibles de diverses variantes. En particulier, un troisième voire un quatrième dispositif de signature partielle pourraient être prévus pour générer une signature multipartite comprenant trois composantes ou plus.