Comment pouvez-vous forcer une partie à être honnête (obéir aux règles du protocole)?
J'ai vu certains mécanismes tels que les engagements, les preuves, etc., mais ils ne semblent tout simplement pas résoudre tout le problème. Il me semble que la structure de la conception du protocole et de tels mécanismes doivent faire l'affaire. Quelqu'un a-t-il une bonne classification de cela?
Modifier
Lors de la conception de protocoles sécurisés, si vous forcez une partie à être honnête, la conception serait beaucoup plus facile, bien que cette application ait son propre avantage. J'ai vu lors de la conception de protocoles sécurisés, les concepteurs supposent quelque chose qui ne me semble pas réaliste, par exemple pour supposer que toutes les parties sont honnêtes dans le pire des cas ou en supposant l'honnêteté du serveur qui conserve les données des utilisateurs. Mais quand on regarde la conception de protocoles dans des modèles plus stricts, on voit rarement de telles hypothèses (au moins je ne l'ai pas vu - j'étudie surtout les protocoles surFramework UC de Canetti dont je pense qu'il n'est pas encore totalement formalisé). Je me demandais, existe-t-il une bonne classification des façons dont vous pouvez forcer une partie à être honnête ou existe-t-il un compilateur capable de convertir le protocole d'entrée en un protocole avec des parties honnêtes?
Maintenant, je vais expliquer pourquoi je pense que cela ne fait tout simplement pas l'affaire, même si cela peut sembler non pertinent. Lors de la conception de protocoles dans le cadre UC, qui bénéficie du paradigme idéal / réel, chaque lien de communication dans le modèle idéal est authentifié, ce qui n'est pas vrai dans le modèle réel. Les concepteurs de protocoles recherchent donc des méthodes alternatives pour implémenter ce canal via l'hypothèse PKI ou un CRS (Common Reference String). Mais lors de la conception de protocoles d'authentification, supposer que les canaux authentifiés sont incorrects. Supposons que nous concevions un protocole d'authentification dans le cadre UC, il y a une attaque dans laquelle l'adversaire forge l'identité d'une partie, mais en raison de l'hypothèse de liens authentifiés dans le modèle idéal, cette attaque n'est pas supposée dans ce cadre! Vous pouvez vous référer àModélisation des attaques internes sur les protocoles d'échange de clés de groupe . Vous remarquerez peut-être que Canetti, dans son ouvrage fondateur, Notions universellement composables d'échange de clés et de canaux sécurisés, mentionne une notion antérieure de sécurité appelée SK-Security, qui suffit simplement à assurer la sécurité des protocoles d'authentification. Il avoue en quelque sorte (en déclarant que c'est une question de technicité) que la définition de l'UC dans ce contexte est trop restrictive et fournit une variante détendue appelée oracle de non-information (ce qui m'a dérouté, car je n'ai vu ce modèle de sécurité nulle part où , Je ne peux pas associer ce modèle de sécurité à un autre modèle de sécurité, probablement mon manque de connaissances: D).
[En remarque, vous pouvez presque faire convertir n'importe quel protocole Sk-secure en un protocole sécurisé UC indépendamment de l'heure du simulateur. Par exemple, vous pouvez simplement supprimer les signatures des messages et demander au simulateur de simuler toutes les interactions de manière fictive. Voir Échange de clés de groupe contributif universellement composable pour la preuve! Supposons maintenant qu'il s'agit d'un protocole d'échange de clés de groupe avec de nombreuses parties polynomiales, quelle serait l'efficacité du simulateur ?? C'est l'origine de mon autre question dans ce forum .]
Quoi qu'il en soit, en raison du manque d'engagement dans le modèle simple (sur UC), j'ai cherché d'autres moyens de sécuriser le protocole en contournant simplement le besoin de cette relaxation. Cette idée est donc très basique dans mon esprit et m'est venue à l'esprit juste après avoir étudié le dernier schéma d'engagement de canetti dans le modèle simple: Dureté adaptative et sécurité composable dans le modèle simple à partir d'hypothèses standard .
BTW, je ne cherche pas de preuves de connaissance zéro parce que pour une raison que je ne connais pas, chaque fois que quelqu'un a utilisé l'un d'eux dans un protocole simultané (sur le cadre UC), les autres ont mentionné le protocole comme inefficace (peut être en raison du rembobinage du simulateur).