Compass Investments

– Similarly : Les experts de Brave, développeur de navigateurs axés sur la protection de la vie privée, affirment que la méthode d’authentification sans connaissance, largement utilisée, peut présenter de graves menaces pour la sécurité et la vie privée, même si elle est présentée comme étant à la pointe des solutions d’identité de la blockchain.

Dans un article récent et un billet de blog qui l’accompagne, Sophia Selye, chercheuse en sécurité chez Brave, et ses collègues ont analysé zkLogin, un système d’authentification basé sur ZK impliqué dans l’écosystème de la blockchain Sui.

Les scientifiques de Brave ont identifié des failles dans zkLogin, un moyen courant de valider les transactions sur la blockchain.

NNos résultats révèlent des problèmes plus courants inhérents aux solutions de preuve à connaissance nulle.

L’analyse montre que la fiabilité du système est largement due à des hypothèses externes que le protocole lui-même ne garantit pas.

L’équipe a également noté que ses résultats fournissent des conclusions plus larges pour le segment croissant des outils d’identité et d’accès basés sur ZK pour les portefeuilles de crypto-monnaie, les justificatifs numériques et les applications décentralisées.

Les preuves à divulgation nulle permettent à une personne de confirmer la véracité d’une affirmation sans révéler les données sous-jacentes. En termes d’identité, cela signifie qu’un utilisateur peut prouver l’existence d’une autorité légitime sans révéler l’autorité elle-même.

Dans le contexte de zkLogin, un utilisateur se connecte via un fournisseur OpenID Connect (OIDC) standard, tel que Google ou un autre service d’authentification basé sur le web. Le fournisseur génère un jeton Web JSON (JWT) signé, à la suite de quoi l’utilisateur crée une preuve ZK qui confirme que le jeton contient certaines informations et une signature valide. L’autorité de vérification accepte la preuve sans voir l’intégralité du jeton.

À première vue, cette structure semble sûre : si la preuve ZK est correcte et que la signature de l’émetteur est valide, l’autorisation devrait être sécurisée. Cependant, les experts de Brave affirment que cette approche ne tient pas compte d’hypothèses critiques sur le comportement des systèmes d’authentification réels.

Comme d’autres systèmes de preuve ZK, zkLogin peut vérifier que vous êtes un utilisateur valide sans vous identifier personnellement.

Toutefois, au cours du processus d’autorisation, zkLogin émet un certain nombre d’hypothèses qui le rendent vulnérable aux attaques.

Selon l’étude, zkLogin dépend de fichiers et de services externes dont l’exactitude et la validité ne sont pas garanties par le protocole lui-même. Cela crée des risques qui ne peuvent être éliminés par les seules méthodes cryptographiques.

Les chercheurs ont regroupé trois grandes catégories de problèmes dans l’architecture actuelle de zkLogin.

La première concerne la manière dont le système gère les JWT.

Au lieu d’utiliser un analyseur JSON conforme aux normes, le schéma ZK recherche des informations textuelles spécifiques telles que l’émetteur, le destinataire, le sujet et le nonce. Selon les chercheurs, il ne contrôle pas le formatage JSON canonique, l’unicité de la clé ou la correspondance exacte des types de données.

Cette approche peut conduire à ce que des jetons ambigus ou mal formés soient traités différemment par différents nœuds. Par exemple, un jeton peut contenir des informations répétitives ou contradictoires : une valeur sera extraite par le système de preuve, tandis que l’autre sera interprétée par les portefeuilles ou les services d’arrière-plan.

Étant donné que le vérificateur ne peut pas voir l’intégralité du contenu, de telles divergences peuvent passer inaperçues.

La deuxième série de vulnérabilités est liée à l’absence de lien clair entre l’authentification et l’autorisation.

Selon les experts, zkLogin transforme des jetons de connexion temporaires en identifiants d’accès à long terme sans les relier étroitement à la session d’origine ou au contexte de l’application.

Dans certains cas, les attaquants peuvent tirer parti de la faiblesse des contrôles de l’émetteur, voler des clés API à partir d’applications basées sur un navigateur et demander des preuves pour des identités ou des programmes donnés.

L’équipe a décrit un scénario complet d’usurpation d’identité qui ne viole pas les principes cryptographiques fondamentaux mais exploite les lacunes dans la manière dont le système relie les émetteurs, les utilisateurs et les parties qui se fient les uns aux autres.