Come puoi forzare una parte a essere onesta (obbedire alle regole del protocollo)?
Ho visto alcuni meccanismi come impegni, prove ecc., Ma semplicemente non sembrano risolvere l'intero problema. Mi sembra che la struttura della progettazione del protocollo e tali meccanismi debbano fare il lavoro. Qualcuno ha una buona classificazione di quello.
Modifica
Quando si progettano protocolli sicuri, se si obbliga una parte a essere onesta, la progettazione sarebbe molto più semplice anche se questa applicazione ha i suoi vantaggi. Durante la progettazione di protocolli sicuri, i progettisti presumono qualcosa che non mi sembra realistico, ad esempio per assumere tutte le parti oneste nel peggiore dei casi o assumendo l'onestà del server che mantiene i dati dell'utente. Ma quando si guarda alla progettazione di protocolli in modelli più rigorosi, raramente si vedono tali ipotesi (almeno non l'ho visto - studio principalmente protocolli suQuadro UC di Canetti che penso non sia ancora del tutto formalizzato). Mi chiedevo, c'è una buona classificazione dei modi in cui puoi forzare una parte a essere onesta o c'è qualche compilatore che può convertire il protocollo di input in uno con parti oneste?
Ora spiegherò perché penso che questo semplicemente non faccia il lavoro sebbene possa sembrare irrilevante. Quando si progettano protocolli nel framework UC, che beneficia del paradigma ideale / reale, ogni collegamento di comunicazione nel modello ideale viene autenticato, il che non è vero nel modello reale. Quindi i progettisti di protocolli cercano metodi alternativi per implementare questo canale attraverso l'assunzione di PKI o un CRS (Common Reference String). Ma quando si progettano protocolli di autenticazione, supporre che i canali autenticati sia sbagliato. Supponiamo che stiamo progettando un protocollo di autenticazione nel framework UC, c'è un attacco in cui l'avversario forgia l'identità di una parte, ma a causa dell'assunzione di collegamenti autenticati nel modello ideale questo attacco non è ipotizzato in questo framework! Puoi fare riferimento aModellazione di attacchi interni a protocolli di scambio di chiavi di gruppo . Si può notare che Canetti nel suo lavoro fondamentale Le nozioni universalmente compostabili di scambio di chiavi e canali sicuri menzionano una precedente nozione di sicurezza chiamata SK-Security che è semplicemente sufficiente per garantire la sicurezza dei protocolli di autenticazione. In qualche modo confessa (affermando che questa è la questione della tecnicità) che la definizione di UC in questo contesto è troppo restrittiva e fornisce una variante rilassata chiamata oracolo di non informazione (che mi ha confuso, perché non ho visto questo modello di sicurezza da nessuna parte , Non posso associare questo modello di sicurezza a nessun altro modello di sicurezza, probabilmente la mia mancanza di conoscenza: D).
[Come nota a margine, puoi quasi avere qualsiasi protocollo Sk-secure convertito in un protocollo UC sicuro indipendentemente dal tempo del simulatore. Ad esempio, puoi semplicemente rimuovere le firme dei messaggi e far simulare in modo fittizio l'intera interazione. Vedi Scambio di chiavi per gruppi di contributori universalmente compostabili come prova! Supponiamo ora che questo sia un protocollo di scambio di chiavi di gruppo con polinomialmente molte parti, quale sarebbe l'efficienza del simulatore ?? Questa è l'origine della mia altra domanda in questo forum .]
Comunque, a causa della mancanza di impegno nel modello semplice (rispetto a UC), ho cercato altri mezzi per rendere sicuro il protocollo semplicemente aggirando la necessità di quel rilassamento. Questa idea è molto semplice nella mia mente e mi è venuta in mente solo dopo aver studiato l'ultimo schema di impegno di canetti nel modello semplice: Durezza adattiva e Sicurezza componibile nel modello normale da Assunti standard .
A proposito, non cerco prove a conoscenza zero perché a causa di motivi che non conosco, ogni volta che qualcuno ha usato uno di loro in un protocollo simultaneo (su framework UC), gli altri hanno menzionato il protocollo come inefficiente (potrebbe essere a causa del riavvolgimento del simulatore).