Pour la gestion des utilisateurs, des rôles et des droits dans l’utilisation productive des contrats intelligents, il est important de résoudre au mieux le trilemme de la technologie blockchain décentralisée. Il existe plusieurs façons de procéder, notamment pour la zone « hors chaîne ».

Dans la première partie de l’article, le problème fondamental des implémentations de blockchain gérées de manière décentralisée a été analysé. Dans cette optique, il est nécessaire d’évaluer les caractéristiques inhérentes aux applications décentralisées. Par exemple, l’évolutivité et la sécurité sont toujours en contradiction, c’est-à-dire que toute amélioration de l’évolutivité entraîne une réduction de la sécurité.

La deuxième partie d’aujourd’hui traite des approches visant à résoudre ce problème. Il existe différentes variantes de solutions, dont l’applicabilité dépend du contexte de l’entreprise : quelle est la taille de l’entreprise, dans quel domaine est-elle active, est-elle fortement réglementée ou soumise à des exigences externes ?

Certaines options sont présentées ci-dessous, mais l’implémentation évidente d’un concept d’utilisateur, de rôles et de droits « on-chain », c’est-à-dire dans le contrat intelligent, n’a pas été envisagée, car cette solution est problématique pour diverses raisons :

• La logique des contrats intelligents ne peut pas être facilement adaptée et les concepts de rôles et de droits sont complexes à mettre en œuvre.
• Les processus internes de l’entreprise pour la gestion des utilisateurs, des rôles et des droits sont réimplémentés de manière redondante et doivent être maintenus en parallèle.
• La solution n’est pas compatible avec les DLT, c’est-à-dire qu’une solution distincte, potentiellement sujette à des erreurs et nécessitant une maintenance importante, doit être mise en œuvre pour chaque implémentation DLT ou blockchain.

Si, malgré ces compromis, la variante « on-chain » est la meilleure possible, il existe un très bon support pour la mise en œuvre sous Ethereum.

Trois variantes de solutions « hors chaîne

Les variantes possibles de la solution « hors chaîne » sont les suivantes :

1. Portefeuille non gardiendes mises en œuvre propres de la gestion des clés
2. Portefeuilles à signature multiple (MultiSig) ou des solutions de gestion de clés propriétaires telles qu’EthSigner (avec des implémentations pour Azure Vault ou HashiCorp Vault).
3. Autorisation basée sur OAuth2/OIDC dans le Smart Contract avec échange automatique de clés

Variante 1 : Portefeuilles non conservateurs à clé privée et développements internes propriétaires

Un développement propriétaire basé sur la garde sécurisée de la clé privée non cryptée n’est certainement possible qu’avec des entreprises non réglementées telles que les FinTechs sans licence spéciale, bien que là aussi l’application spécifique doive être examinée. L’idée de base est d’utiliser un portefeuille, par exemple pour Ethereum le plugin MetaMask pour navigateur, qui stocke les informations d’identification. La clé privée, puisqu’elle est le seul moyen d’accès au smart contract, doit alors être stockée dans un périphérique externe.

Le processus de gestion de cette clé n’est pas considéré ici. Cela donne lieu à toute une série de problèmes et de questions qui ne peuvent être clarifiés de manière concluante et adéquate. Fondamentalement, cette variante équivaut à stocker le mot de passe d’un utilisateur en texte clair dans une base de données d’administration spéciale.

Cette variante n’a de sens qu’au stade du prototype et est déjà exclue s’il faut s’assurer qu’un utilisateur a effectivement obtenu lui-même une action et que la clé privée n’a pas été utilisée sans autorisation.

Variante 2 : les portefeuilles à signatures multiples (MultiSig), très efficaces, mais aussi « centrés sur la blockchain ».

La variante multi-signatures provient de l’utilisation de la blockchain décentralisée de pair à pair pour les transactions qui nécessitent des actions ou des confirmations de la part de plusieurs acteurs. Une analogie avec la finance centralisée est un « compte et », qui nécessite 4 yeux pour une transaction donnée. Dans les portefeuilles MultiSig, ce n’est pas une seule mais M de N signatures qui sont vérifiées, ce qui a été fait avec les clés privées respectives. Ce n’est que si M signatures prescrites sont présentes que la transaction est effectuée.

Une telle variante est « blockchain-native », mais n’est pas correctement cartographiée par les processus d’entreprise existants. Par exemple, il n’est pas clair ce qui se passe lorsque des participants individuels quittent l’entreprise ou que de nouveaux participants la rejoignent. Si les cas sont entièrement cartographiés, le risque est grand de reconstruire des administrations de rôles et de droits complexes, coûteuses et sujettes aux erreurs.

Variante 3 : Utilisation d’applications et de processus IdAM établis

Sur une échelle allant de « avantage pratique » à « décentralisation complète », cette variante est nettement plus proche de l’avantage pratique, notamment dans un contexte d’entreprise, que les autres variantes. Le point de rupture de la décentralisation est la confiance dans les outils et processus IdAM existants des différentes entreprises participantes, mais pas dans les employés individuels de ces entreprises.

Dans notre exemple, un échange de clés pour Anna peut avoir lieu, mais pour cela, un processus interne à l’entreprise doit être mené à bien. Comme preuve de la réussite du processus, c’est une signature du système IdAM qui est reconnue dans le contrat intelligent, et non une clé individuelle d’un employé de l’entreprise. Ce compromis permet désormais, au détriment de la confiance, aux entreprises d’utiliser le fonctionnement de l’application décentralisée malgré des situations typiques telles que la perte de clés, la désactivation d’un employé, etc.

Ainsi, dans notre cas particulier, la confiance nécessaire en Anna se transforme en une confiance des participants du consortium dans les processus existants de l’entreprise participante respective, c’est-à-dire l’employeur d’Anna.

Pour rester dans le cas d’utilisation typique des applications de la blockchain « qui a fait quoi et quand », il est prévu dans le contrat intelligent qu’il fasse confiance à une signature des systèmes IdAM respectifs de chaque entreprise. Cette vérification est « sans confiance », c’est-à-dire que la logique de la vérification de la signature et de l’échange de clés qui s’ensuit ne peut être modifiée ni vérifiée par aucun participant. Cependant, au lieu d’un employé individuel, c’est un processus d’entreprise qui est mis en cause dans ce cas.

Un compromis pour une véritable décentralisation

Ce compromis avec une véritable décentralisation doit être évalué au cas par cas, mais si l’on se base sur la pratique générale des affaires, les processus internes des entreprises bénéficient généralement d’une grande confiance. Cette option de mise en œuvre permet de prouver et de sanctionner de manière irrévocable une violation du processus global convenu.

Du point de vue du risque, cette option est la moins risquée car les employés individuels n’ont pas de vecteur d’attaque. Il est supposé que l’entreprise a déjà minimisé ces risques en interne, par exemple en mettant en place les processus IdAM de manière sécurisée et en les contrôlant en permanence.

De nouvelles solutions pour les applications décentralisées

De vieux problèmes familiers tels que l’authenticité d’un acteur dans un consortium coopératif nécessitent de nouvelles solutions dans l’environnement décentralisé. Il ne s’agit pas de problèmes techniques, mais de défis conceptuels, et ils sont influencés par de nombreux facteurs et parties prenantes, car il ne peut y avoir de responsable central.

D’une manière générale, les problèmes dans l’environnement décentralisé ne peuvent plus être traités « à la main » par les participants individuels, mais nécessitent des accords et une coordination entre les participants. L’ensemble de ce nouveau champ de recherche se résume sous le terme de « gouvernance décentralisée » et en est encore à ses débuts.

Sur le plan technique, les frontières des entreprises sont désormais perméables, mais sur le plan administratif, opérationnel et politique, de nouvelles questions se posent. La résolution de ces problèmes constitue le véritable défi de la décentralisation des applications et des processus.