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 de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

À propos de ce site, du contenu, de l'auteur
Je poste parfois ici des humeurs ou des pensées. Parfois je change, parfois je me trompe, parfois j'apprends, et souvent le contexte lui-même évolue avec le temps. Les contenus ne sont représentatifs que de l'instant où ils ont été écrits. J'efface peu les contenus de ce site, merci de prendre du recul quand les textes sont anciens. Merci

À toutes fins utiles, ce site est hébergé par Scaleway, ONLINE SAS, joignable par téléphone au +33 (0)1 84 13 00 00 et joignable par courrier à l'adresse BP 438 - 75366 Paris Cedex 08.