Ok, on a expliqué comment fonctionne le gestionnaire de mots de passe, mais est-ce du zero knowledge ?
La réponse est « ça dépend », ou plus précisément « ça dépend de ce qu’on entend par zero knowledge.
Sur le principe, le contrôle du serveur ne suffit pas pour récupérer les mots de passe en clair. C’est une incapacité technique impossible à contourner.
En pratique c’est plus délicat. L’entité qui gère vos mots de passe chiffrés gère aussi l’application web, les extensions navigateurs et les clients lourds sur vos ordinateurs de bureau. Elle peut à tout moment déclencher une mise à jour logicielle avec un code malicieux qui fera fuiter vos mots de passe ou la clef de chiffrement à la prochaine utilisation.
Est-ce du zero knowledge si on ne peut pas relire vos mots de passe actuellement mais qu’on sait à tout moment déployer un nouveau logiciel qui le permettrait ? à vous de dire.
À un moment quelqu’un va vous proposer de télécharger un logiciel ou une mise à jour et il va vous falloir faire confiance. Ceux qui contrôlent ce logiciel et les mises à jour peuvent théoriquement faire ce qu’ils veulent avec vos données.
Les accès à des applications web sont particulièrement problématiques — les mises à jour sont instantanées, silencieuses, et peuvent cibler des utilisateurs précis — mais le problème est plus général.
Les extensions navigateurs sont validées par l’éditeur du navigateur en question. Ça peut ajouter un peu de sécurité en plus mais ça ajoute une seconde entité au cercle de confiance. Désormais non seulement il faut faire confiance à l’auteur de l’extension — il est probable qu’il arrive à faire passer une porte dérobée à travers la validation s’il le veut vraiment — mais aussi à Mozilla, Google et Apple qui peuvent à tout moment déployer d’eux-même une extension corrompue.
Même chose pour les mises à jour via l’App Store d’Apple ou le Play Store d’Android.
Alors quoi ?
Une solution serait de couper toutes les mises à jour automatiques. On s’expose alors à d’autres problèmes bien plus probables, comme l’impossibilité de corriger rapidement un problème de sécurité involontaire.
La fiabilité peut venir du fait de documenter les API entre les logiciels clients et le serveur. Chacun peut alors ne pas faire confiance à l’éditeur d’origine et utiliser des logiciels clients alternatifs. C’est une preuve de bonne foi de la part de l’entité qui contrôle le serveur mais on ne fait cependant que déporter le problème : Il faut alors faire confiance aux éditeurs de ces logiciels alternatifs.
La seule solution si on a une vision jusque boutiste du zero knowledge serait de compiler soi-même son logiciel à partir des codes sources. Bien entendu cela implique d’avoir le temps et les compétences pour auditer ce code source et toutes ses évolutions. Pour la plupart des gens ce n’est pas réaliste.
À un moment donné il faut faire confiance, tout ce qu’on peut faire c’est vous laisser choisir en qui vous faites confiance.
Plutôt qu’un oui ou non je vous propose des niveaux :
| 0 | Il n’y a aucun chiffrement |
| 1 | Les données sont chiffrées mais le serveur sait accéder aux clef de façon pérenne |
| 2 | Les données sont chiffrées mais le serveur a accès aux clefs de façon temporaire le temps d’interagir avec les données |
| 3 | Les données sont chiffrées ; le serveur n’a pas accès aux clefs de déchiffrement, mais il est possible de déployer une nouvelle version du logiciel qui donne accès aux clefs ou aux données |
| 4 | Les données sont chiffrées ; les API de communication entre le serveur et les clients sont documentées ; il est possible d’utiliser des clients alternatifs de son choix |
| 5 | Les données sont chiffrées ; les API de communication entre le serveur et les clients sont documentées ; le code source d’un client est disponible et auditable ; il est possible de compiler soi-même son propre client auprès audit si on en a le temps et les compétences |
Pour la plupart des gens les niveaux de sécurité 2 à 4 sont déjà tout à fait pertinents. La différence se fait en fonction de ce contre quoi on cherche à se protéger et de en qui on a confiance.
Se retreindre au niveau théorique où les entités tierces n’ont réellement aucune capacité à récupérer les mots de passe même indirectement implique le niveau 5, mais ce n’est probablement pas réaliste pour grand monde. Il faut savoir relire du code source, avec suffisamment de compétence et de temps pour savoir identifier quelqu’un qui cherche à y cacher une porte dérobée, mais aussi toutes les dépendances de ce code source. En pratique on a vu des anomalies ou portes dérobées dans des logiciels open source cœur dans la sécurité de quasiment tous les serveurs (ssh, openssl) rester des années. Autant dire que c’est un niveau de sécurité plus théorique qu’autre chose. Même les experts finissent par faire confiance à d’autres experts, avec le risque qu’un des maillons de la chaîne ne mérite pas cette confiance.
Laisser un commentaire