E2EE & SSO : comment faire du chiffrement de bout en bout et de l'authentification unique?

Le chiffrement de bout en bout et l’authentification unique sont deux fonctionnalités très intéressantes dans un contexte d’hébergement alternatif, mais à première vue elles apparaissent mutuellement exclusives.

D’une part le chiffrement de bout en bout se base sur le principe que les fournisseurs de service ne connaissent pas la clé secrète de ses utilisateurs. Par conséquent c’est aux utilisateurs de la conserver et son utilisation ne doit être faite que côté client.

D’autre part, l’authentification unique se base sur le principe que l’utilisateur ne transmet pas son mot de passe aux fournisseurs de services, mais un jeton qu’il aura obtenu auprès d’un fournisseur d’identité.

Naïvement, la clé secrète la plus évidente pour permettre à un utilisateur de chiffrer des données est son mot de passe, qu’on cherche justement à éviter de transmettre aux services lorsqu’on fait du SSO. On se doute que pour faire fonctionner ensemble ces deux concepts, ça ne va pas être si simple. Un inconvénient notable d’utiliser le mot de passe utilisateur comme clé secrète est que si le mot de passe est perdu, alors les données chiffrées sont perdues également.

Je suis tombé sur ce très bon article qui explique comment le protocole matrix s’en sort, en conjuguant E2EE, appareils multiples, et éventuellement SSO. L’astuce réside dans le fait qu’un travail supplémentaire est demandé aux utilisateurs, puisqu’ils doivent d’une part retenir une clé de chiffrement qui est indépendante de leur mot de passe, et d’autre part valider l’identité de leurs interlocuteurs de manière « déconnectée » (c’est à dire sans passer par le réseau matrix). In fine, ça ressemble à ce qui se passe lorsqu’on souhaite chiffrer des emails : on doit se rencontrer en vrai pour échanger ses clés GPG.

Je suis curieux de savoir si vous connaissez d’autres manières de faire, d’autres implémentations de ces deux concepts dans un même contexte. Si vous avez de bonnes lectures, j’en veux :slight_smile:

Éloi

1 Like

Bonjour Éloi,

Je ne connais pas de méthode « clé-en-main » mais le W3C (World Wide Web Consortium) a plusieurs spécifications en cours de rédaction (did, verifiable credentials, etc.) qui pourraient peut-être jeter les bases d’un système d’authentification unique (SSO) différent qui rendrait le chiffrement de bout en bout (E2EE) plus simple à mettre en oeuvre.

l’écosystème - Ces specs sont aujourd’hui beaucoup promues/regardées/implémentées par les communautés blockchain et aussi les États. On peut facilement les regrouper sous le terme self-sovereign identity. Un exemple d’un projet avancé par exemple est sovrin qui se base sur hyperledger indy, une « blockchain permissioned », c’est à dire géré par un nombre défini d’acteurs.

mes réserves - Ma réserve principale par rapport au travail d’implémentation précédent se situe au niveau de la blockchain, permissioned ou public : dans tous les cas, c’est une base de donnée distribuée qui définit une seule vérité unique. Cette seule et unique vérité est gérée soit par l’argent et des règles froides (pensez aux gens qui se font voler leurs NFTs sans recours possible par exemple) ou par une seule organisation qui décide de qui a le droit de gérer la base de données (dans le cas des permissioned blockchains). Je trouve que cette vérité unique donne beaucoup trop de pouvoir à l’entité qui la définie, et qui plus est, n’est pas nécessaire ni même souhaitable (je tiens à mon pseudonymat qui est une identité parallèle).

application à l’E2EE - Si on repart de la spec du W3C, il n’est pas nécessaire d’avoir une blockchain/ledger pour bénéficier de certaines propriétés/avantages de DID, et ce n’est pas dit que c’est la vision blockchain/ledger qui l’emportera. Pour notre problème de E2EE & SSO, il y a un certains nombre de propositions qui pourraient même être intéressantes.

did est flexible - D’abord pour se convaincre de la flexibilité du protocole, il y a plein de « méthodes » d’authentification envisagées, en plus de toutes les blockchains, comme via une paire de clef publique/privée (did:key), via Tor (did:onion), via des endpoints web (did:web), via ActivityPub (did:orb), etc. Quelques unes de ces méthodes sont implémentées et testables via l’outil/bibliothèque didkit. Dans notre cas, did:key est tout à fait suffisante pour imaginer avancer sur l’E2EE.

did en pratique - En pratique, il est prévu que les identités des usagers soient stockés dans un wallet logiciel sur leurs terminaux. Ces identités sont des fichiers JSON signés par l’utilisateur lui-même ou une autorité de confiance et des clés publiques/privées. On pourrait imaginer une primitive rendue accessible par ces wallets pour chiffrer/déchiffrer du contenu, en plus de l’auth. Un peu comme une extension des « trousseaux de clés » qu’on trouve sur nos OS aujourd’hui (eg. gnome-keyring sur Linux). Le projet DIDKit a un prototype Android nommé Credible sur le sujet. Mais aussi un outil CLI avec une procédure pas à pas pour prendre les concepts en main.

perte des identifiants - Se pose la question de la perte/casse/inaccessibilités des terminaux. Il y a une spec identity hub qui parle de ce problème, c’est pas encore bien clair pour moi son rôle. Si tu ne donnes pas les identifiants & clés, alors pas très utile, si tu les donnes, bye bye pour l’E2EE. Sinon, l’autre approche que j’ai cru comprendre, c’est que tes identités doivent pouvoir être facilement regénérables depuis les fournisseurs d’identité, mais clairement bye bye la E2EE ici… C’est peut-être là où il y a encore le plus de travail. On pourrait imaginer un service standardisé qui permettrait de stocker ses identifiants/clés chiffrés avec un mot de passe fort, et, au choix de l’utilisateur, d’avoir une copie de ces clés chiffrée avec un secret réparti entre les administrateur-ices de la plateforme (ou entre tes ami-es/famille), ce qui permettrait une « récupération » par un groupe d’humains.

intégration avec l’existant - Pour la question de l’intégration avec les technologies existantes, il y a une spec qui permet d’utiliser DID avec OpenID : Self-Issued OpenID Provider v2. Mais ça ne donne pas l’E2EE qui nécessite de reconcevoir largement les applications.

en conclusion - Je ne sais pas si DID est une bonne ou une mauvaise idée, mais c’est le seul projet que je connaisse qui propose de formaliser/standardiser une base qui pourrait servir pour de l’E2EE et du SSO.

1 Like

Tu décris ici une méthode pour y parvenir.
Il y a des SSO qui sont en mesure de transmettre le mot de passe à l’app. Et puis on peut aussi distinguer authentification unique et authentification centralisée (via ldap par exemple).