Zero know­ledge

Ok, on a expliqué comment fonc­tionne le gestion­naire de mots de passe, mais est-ce du zero know­ledge ?

La réponse est « ça dépend », ou plus préci­sé­ment « ça dépend de ce qu’on entend par zero know­ledge.

Sur le prin­cipe, le contrôle du serveur ne suffit pas pour récu­pé­rer les mots de passe en clair. C’est une inca­pa­cité tech­nique impos­sible à contour­ner.

En pratique c’est plus déli­cat. L’en­tité qui gère vos mots de passe chif­frés gère aussi l’ap­pli­ca­tion web, les exten­sions navi­ga­teurs et les clients lourds sur vos ordi­na­teurs de bureau. Elle peut à tout moment déclen­cher une mise à jour logi­cielle avec un code mali­cieux qui fera fuiter vos mots de passe ou la clef de chif­fre­ment à la prochaine utili­sa­tion.

Est-ce du zero know­ledge si on ne peut pas relire vos mots de passe actuel­le­ment mais qu’on sait à tout moment déployer un nouveau logi­ciel qui le permet­trait ? à vous de dire.

À un moment quelqu’un va vous propo­ser de télé­char­ger un logi­ciel ou une mise à jour et il va vous falloir faire confiance. Ceux qui contrôlent ce logi­ciel et les mises à jour peuvent théo­rique­ment faire ce qu’ils veulent avec vos données.


Les accès à des appli­ca­tions web sont parti­cu­liè­re­ment problé­ma­tiques — les mises à jour sont instan­ta­nées, silen­cieuses, et peuvent cibler des utili­sa­teurs précis — mais le problème est plus géné­ral.

Les exten­sions navi­ga­teurs sont vali­dées par l’édi­teur du navi­ga­teur en ques­tion. Ça peut ajou­ter un peu de sécu­rité en plus mais ça ajoute une seconde entité au cercle de confiance. Désor­mais non seule­ment il faut faire confiance à l’au­teur de l’ex­ten­sion — il est probable qu’il arrive à faire passer une porte déro­bée à travers la vali­da­tion s’il le veut vrai­ment — mais aussi à Mozilla, Google et Apple qui peuvent à tout moment déployer d’eux-même une exten­sion corrom­pue.

Même chose pour les mises à jour via l’App Store d’Apple ou le Play Store d’An­droid.


Alors quoi ?

Une solu­tion serait de couper toutes les mises à jour auto­ma­tiques. On s’ex­pose alors à d’autres problèmes bien plus probables, comme l’im­pos­si­bi­lité de corri­ger rapi­de­ment un problème de sécu­rité invo­lon­taire.

La fiabi­lité peut venir du fait de docu­men­ter les API entre les logi­ciels clients et le serveur. Chacun peut alors ne pas faire confiance à l’édi­teur d’ori­gine et utili­ser des logi­ciels clients alter­na­tifs. C’est une preuve de bonne foi de la part de l’en­tité qui contrôle le serveur mais on ne fait cepen­dant que dépor­ter le problème : Il faut alors faire confiance aux éditeurs de ces logi­ciels alter­na­tifs.

La seule solu­tion si on a une vision jusque boutiste du zero know­ledge serait de compi­ler soi-même son logi­ciel à partir des codes sources. Bien entendu cela implique d’avoir le temps et les compé­tences pour audi­ter ce code source et toutes ses évolu­tions. 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 lais­ser choi­sir en qui vous faites confiance.


Plutôt qu’un oui ou non je vous propose des niveaux :

0Il n’y a aucun chif­fre­ment
1Les données sont chif­frées mais le serveur sait accé­der aux clef de façon pérenne
2Les données sont chif­frées mais le serveur a accès aux clefs de façon tempo­raire le temps d’in­te­ra­gir avec les données
3Les données sont chif­frées ; le serveur n’a pas accès aux clefs de déchif­fre­ment, mais il est possible de déployer une nouvelle version du logi­ciel qui donne accès aux clefs ou aux données
4Les données sont chif­frées ; les API de commu­ni­ca­tion entre le serveur et les clients sont docu­men­tées ; il est possible d’uti­li­ser des clients alter­na­tifs de son choix
5Les données sont chif­frées ; les API de commu­ni­ca­tion entre le serveur et les clients sont docu­men­tées ; le code source d’un client est dispo­nible et audi­table ; il est possible de compi­ler 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écu­rité 2 à 4 sont déjà tout à fait perti­nents. La diffé­rence se fait en fonc­tion de ce contre quoi on cherche à se proté­ger et de en qui on a confiance.

Se retreindre au niveau théo­rique où les enti­tés tierces n’ont réel­le­ment aucune capa­cité à récu­pé­rer les mots de passe même indi­rec­te­ment implique le niveau 5, mais ce n’est proba­ble­ment pas réaliste pour grand monde. Il faut savoir relire du code source, avec suffi­sam­ment de compé­tence et de temps pour savoir iden­ti­fier quelqu’un qui cherche à y cacher une porte déro­bée, mais aussi toutes les dépen­dances de ce code source. En pratique on a vu des anoma­lies ou portes déro­bées dans des logi­ciels open source cœur dans la sécu­rité de quasi­ment tous les serveurs (ssh, openssl) rester des années. Autant dire que c’est un niveau de sécu­rité plus théo­rique 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

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *