SSI : le futur de la gestion d’identité, comment ca marche ?

Le problème à résoudre

"Internet a été conçu sans couche de sécurité."

Ce constat brutal, froid, mais factuel est le point de départ des réflexions qui ont conduit au concept de SSI, Self Sovereign Identity.

Internet a été conçu pour interconnecter de façon fiable et résiliente des machines, d'abord à l'échelle d'un continent puis rapidement à l'échelle de notre planète.

Internet est donc d'abord un réseau de machines, et non d'individus.

Ces machines ne sont pas dotées d'intentions (bonnes ou mauvaises), il était simplement nécessaire de pouvoir les localiser sur le réseau sans avoir à les authentifier ni les autoriser, TCP/IP est né de ce besoin.

D'abord utilisé par une communauté scientifique et universitaire, guidée par une certaine éthique, Internet c'est progressivement ouvert au début des années 90 au citoyen et aux entreprises.

Le besoin de gestion d'identité et de contrôle d'accès est alors de devenu prégnant.

La gestion d'identité locale

La première réponse s'est matérialisée sous la forme d'initiatives locales.

Chaque site, chaque service, chaque entreprise voir, chaque application s'est vue hériter d'un système de gestion d'identité et de contrôle d'accès.

D'abord intégré au niveau de l'application, il impliquait pour l'utilisateur la création (et la mémorisation) d'un compte pour chacune d'entre elles.

Peu commode, et d'un niveau de fiabilité / sécurité hétérogène il a rapidement montré ses limites.

Le SSO

L'évolution au sein des entreprises à alors accouché du SSO (Single Sign On) : un système commun d'identification pour l'ensemble du parc applicatif de l'entreprise.

Microsoft en a popularisé le principe avec son Active Directory, puis des normes ouvertes telles que SAML, SAMLv2 ou OpenID Connect ont prises le relais.

La fédération

Si le problème avait été globalement géré au sein des entreprises, le particulier ne pouvait en bénéficier.

Chaque nouveau service souscrit auprès d'une nouvelle entreprise impliquait un nouveau compte.

On à alors eu l'idée d'interconnecter les SSO d'entreprise (à commencer par celle qui offrent des services aux particuliers), OpenID Connect avait d'ailleurs été conçu dans cette optique.

Les "fédérations d'identités" permettent à un utilisateur de s'authentifier auprès du service de l'entreprise "B" avec un compte de l'entreprise "A".

C'est exactement ce qu'il se passe lorsque vous vous authentifiez avec votre compte Google, Twitter ou GitHub auprès de service(s) qui n'ont rien à voir avec ces entreprises.

La masse critique

Si le principe de gestion d'identité fédéré peut sembler satisfaisant du point de vue de l'utilisateur, il n'est pas sans poser un certain nombre de problèmes.

Tout d'abord pour fonctionner; il faut que le service "B" reconnaisse "A" comme fournisseur d'identité.

Par exemple que votre service de prise de rendez-vous médicaux en ligne reconnaisse Google ou FaceBook comme fournisseur d'identité.

Les sites et services ne pouvant proposer une liste infinie de fournisseurs d'identités reconnues, ils vont avoir tendance à sélectionner les plus représentatifs, tout le monde à un compte Google non ?

De facto, le système favorise une concentration des acteurs : les fournisseurs de service vont avoir tendance à choisir des fournisseurs d'identité qui regroupent un maximum d'utilisateurs potentiels, et les utilisateurs vont avoir tendance à choisir, pour la gestion de leur identité, des fournisseurs référencés sur un maximum de sites et applications, le système s'auto-entretient.

Les grands acteurs d'Internet se retrouvent par conséquent dans une position centrale.

Bien qu'ils ne monétisent pas directement leur service de gestion d'identité auprès des utilisateurs, chaque connexion, chaque authentification passant par eux est une source d'information énorme représentant une manne potentiellement financière colossale.

Si les fournisseurs d'identités n'ont (en théorie) pas accès à votre activité sur le service "B" une fois identifié, le simple fait de savoir que vous vous êtes authentifié pour y accéder tel jour à telle heure est une information monnayable.

Combien une société d'assurance serait-elle prête à payer pour connaître votre fréquence de connexion à un site de prise de rendez-vous médicaux en ligne ?

Cette hyperconcentration pose aussi un problème de sécurité, en cas de compromission des systèmes du fournisseur d'identité, l'impact est potentiellement catastrophique pour ses utilisateurs.

Ce qui a changé

Malgré les risques et inconvénients des systèmes fédérés, ils représentent à ce jour la majorité des systèmes de gestion d'identité en usage.

Tout simplement parce que les technologies alors disponibles ne nous permettaient pas de faire mieux.

D'ailleurs, que pourrions-nous mieux faire ? Quelles seraient les caractéristiques d'un système optimum, à l'échelle d'Internet ?

Essayons de les imaginer :

• Un système qui permettrait aux individus, mais aussi aux machines de s'authentifier voir de fournir les éléments nécessaires pour prendre une décision d'autorisation.
• Un système qui éviterait aux utilisateurs de gérer / mémoriser un nombre important de comptes / mot de passes, quel que soit le nombre de services auprès desquels ils s'authentifient.
• Un système non centralisé, qui permettrait d'éviter le phénomène d'hyperconcentration évoqué au chapitre précédent.
• Un système qui permettrait aux utilisateurs de ne divulguer uniquement les informations nécessaires à la consommation du service visé (ex: je dois pouvoir prouver que je suis majeur sans divulguer ma date de naissance ou mon âge).
• Enfin, un système évidemment fiable (sécurisé) et facile à utiliser.

De nombreux chercheurs se sont penchés sur ce problème ces vingt dernières années sans trouver jusqu'à récemment de solution satisfaisante, le plus compliqué étant de concevoir un système à la fois décentralisé et "scalable" à l'échelle d'Internet.

En 2008, Internet a vu naître une nouvelle technologie : la blockchain.

Derrière son "démonstrateur applicatif" que représente la cryptomonnaie, la blockchain est avant tout le premier système de "base de données" entièrement distribué à l'échelle d'Internet.

Il s'agit précisément d'un registre distribué, c'est-à-dire une base de données dans laquelle il n'est possible que d'ajouter des données, mais pas d'en supprimer ni d'en modifier, à l'image d'un livre de comptes.

Bien que ces performances (en transactions par secondes) soient globalement très médiocres, elles sont tout à fait suffisantes pour ce qui nous intéresse : la création d'une PKI (Public Key Infrastructure).

La PKI est le système indispensable à la mise en oeuvre de systèmes d'authentification et de signature à base de cryptographie asymétrique.

Jusque là centralisées (ou hiérarchique ce qui revient au même) par nature, elles étaient sous le contrôle d'une entité (entreprise, organisme, gouvernement) ce qui rendait son passage à l'échelle d'Internet impossible.

La blockchain ouvre la voie au principe de PKI distribuée, plus d'organisme central de gestion des clés et des informations rattachées.

Cette PKI totalement distribuée est ce qui a rendu techniquement possible l'émergence du concept de SSI (Self Sovereign Identity), le nouveau mode de gestion des identités (il aura fallu 6 ans pour le comprendre).

SSI : Principes de fonctionnement

Le principe du SSI est relativement simple à comprendre, surtout pour des non spécialistes (qui sont généralement les plus perturbés par l'innovation de rupture qu'il représente) : on reproduit simplement dans le monde virtuel la façon dont vous gérez vos identifiants dans le monde réel.

Par "identifiant" je cible n'importe quelle information qui vous caractérise : nom et prénom, date de naissance, adresse physique, nationalité, couleur des yeux, des cheveux, taille, etc.

Monde réel

Dans le monde physique, la première étape consiste généralement à s'acheter un portefeuille.

Il devient "votre" portefeuille, mais ne contient intrinsèquement aucune information personnelle tant qu'il est vide.

C'est "votre" portefeuille parce qu'il est dans "votre" poche et que vous seul pouvez décider de ce que vous allez mettre dedans : vous en avez le contrôle.

Deuxième étape : vous commencez à y ranger des documents d'identités : votre carte d'identité, votre permis de conduire, votre passeport, votre carte de membre de club de sport, votre badge d'employé, votre carte de crédit, etc.

Ces documents représentent des informations délivrées par un émetteur.

Par exemple votre carte d'identité ou votre passeport représente des informations d'identité délivrées par l'état civil de votre pays.

Troisième et dernière étape : vous utilisez vos documents pour accéder à des services.

Pour louer un véhicule, vous sortez votre permis de conduire de votre portefeuille (dont vous avez toujours le contrôle) et le présentez au loueur. Pour accéder à votre salle de sport préférée, vous sortez votre carte de membre afin de la présenter. Pour entrer dans un nouveau pays, vous sortez votre passeport et le présentez.

Vous présentez des attributs d'identité à des personnes, des entités qui vont les vérifier.

Le douanier par exemple vérifie que la photo, la couleur des yeux, la taille présente sur votre passeport correspond bien à la personne qu'il a en fasse de lui, mais surtout, il vérifie que le document est authentique, c'est-à-dire qu'il a été émis par une entité (le gouvernement d'un pays dans le cas présent) auquel il (ou plutôt son pays) fait confiance et qu'il n'a pas été falsifié (que les informations ont été modifiées).

Il y a donc une relation transitive de confiance : le douanier fait confiance aux informations que vous lui présentez parce qu'il a confiance dans l'entité qui vous les a délivrés (votre gouvernement).

Il n'a pas besoin de vous connaître et encore moins de vous faire confiance.

Si nous résumons brièvement les acteurs en présence, cela pourrait donner le schéma suivant :

Dans le milieu nous appelons cela le "triangle de confiance".

C'est ce principe qui permet à des personnes qui ne se connaissent pas directement d'interagir entre elles en confiance, qu'il s'agisse d'information d'identité, mais aussi de monnaie (virtuelle ou physique).

Monde virtuel

Transposons cela dans le monde virtuel.

Pour la première étape il nous faut deux choses, un portefeuille, tout comme le monde réel, sauf que là, il s'agit d'un logiciel (qui peut être installé sur votre smartphone), mais aussi un support.

Dans le monde virtuel il n'y a pas de papier, par de carte plastifiée, pas de petit livret sécurisé, bref pas de support physique sur lequel imprimer l'information et que vous posséderais, sur lequel vous aurez le contrôle.

Ce support va prendre la forme d'un identifiant unique, aléatoire et créé par vous.

Il ne porte en lui absolument aucune information personnelle, c'est juste une suite aléatoire de chiffres et de caractères. MAIS il est "attaché" au moyen cryptographique que vous allez ensuite utiliser pour démontrer que vous avez le "contrôle" sur cet identifiant.

En clair cet identifiant numérique, ou DID, est lié à votre paire de clés privées / clé publique elles-mêmes créée par vos soins.

Lorsqu'un émetteur d'informations d'identité "fabriquera" l'équivalent de votre permis de conduire ou de votre passeport électronique, il le fera en indiquant que ces informations concernent ce DID en particulier (via le champ credentialSubject).

Si vous avez le contrôle sur le DID (c'est-à-dire la clé privée), alors vous pouvez démontrer cryptographiquement que les informations qui y font référence vous concernent.

Ce DID est un URI (Unique Ressource Identifier), et la ressource, c'est votre clé publique.

Ce couple DID / clé publique (stocké dans un DID-Document, lui-même enregistré dans une blockchain) constitue la base de la PKI distribuée évoquée précédemment.

La deuxième étape consiste, comme dans le monde réel à recevoir des informations certifiées vous caractérisant.

L'émetteur, l'état civil pour notre exemple, va émettre un ensemble d'attributs (nom, prénom, adresse, taille, couleur des yeux ...) qu'il va rattacher à votre DID (via le champ credentialSubject) et signer cryptographiquement avec sa clé privée.

Ce principe relativement simple permet de démontrer cryptographiquement que les informations :

• Ont étés émises par cet émetteur en particulier (par exemple un gouvernement).
• N'ont pas été modifiées ou falsifiées (la signature ne serait plus vérifiable).
• Qu'elles ont été émises pour vous (votre DID fait partis des informations signées).

Le "document" que vous recevez s'appelle un Verifiable Credential.

Lors de la troisième étape vous présentez des attributs à un vérificateur (un douanier par exemple) au travers d'une Verifiable Presentation.

Le douanier peut vérifier cryptographiquement que :

• Les informations qui lui sont présentées sont intègres (I.E. qu'elles n'ont pas été modifiées),
• Qu'elles sont authentiques (qu'elles ont été émise à votre gouvernent) grâce à la signature de l'émetteur,
• Qu'elles vous concernent (car vous allez signer votre présentation avec la clé privée correspondant au DID pour lequel les informations ont été émises).

Pour le vérifier, le douanier a besoin d'accéder à la clé publique de l'émetteur et à la vôtre.

C'est ici qu'entre en jeux la blockchain, elle sert simplement de support de stockage aux couples DIDs / clés publiques.

En utilisant le DID de l'émetteur et le vôtre contenus dans les attributs présentés il va "résoudre" ces identifiants auprès de ce support de stockage pour retrouver les clés publiques correspondantes et effectuer les contrôles de signature.

La blockchain étant inaltérable (l'information ne peut être modifiée une fois écrite) il a la garantie si les signatures correspondent aux clés publiques retrouvées que tout est en ordre.

Il ne lui reste plus qu'à déterminer s'il fait confiance ou non l'émetteur des Verifiable Credentials contenus dans votre Verifiable Presentation, dans notre exemple, à votre gouvernement.

Tout comme dans le monde réel, nous sommes en présence d'un triangle de confiance :