Как вы можете заставить партию быть честной (подчиняться правилам протокола)?
Я видел некоторые механизмы, такие как обязательства, доказательства и т. Д., Но они просто не решают всей проблемы. Мне кажется, что структура дизайна протокола и такие механизмы должны выполнять свою работу. У кого-нибудь есть хорошая классификация этого.
Редактировать
При разработке защищенных протоколов, если вы заставляете сторону быть честной, дизайн будет намного проще, хотя у этого принуждения есть свои преимущества. Я видел, что при разработке безопасных протоколов дизайнеры предполагают что-то, что мне не кажется реалистичным, например, что все стороны честны в худшем случае или предполагают честность сервера, который хранит пользовательские данные. Но, глядя на дизайн протоколов в более строгих моделях, вы редко видите такие предположения (по крайней мере, я этого не видел - я в основном изучаю протоколы надUC Framework Canetti, который, я думаю, еще не полностью формализован). Мне было интересно, есть ли хорошая классификация способов, которыми вы можете заставить сторону быть честной, или есть какой-нибудь компилятор, который может преобразовать входной протокол в протокол с честными сторонами?
Теперь я собираюсь объяснить, почему я думаю, что это просто не делает работу, хотя это может показаться неуместным. При разработке протоколов в структуре UC, которая использует идеальную / реальную парадигму, каждая линия связи в идеальной модели аутентифицируется, что не соответствует действительности в реальной модели. Поэтому разработчики протоколов ищут альтернативные методы для реализации этого канала с помощью предположения PKI или CRS (Common Reference String). Но при разработке протоколов аутентификации допущение аутентифицированных каналов неверно. Предположим, что мы разрабатываем протокол аутентификации в структуре UC, есть атака, в которой злоумышленник подделывает личность стороны, но из-за допущения аутентифицированных ссылок в идеальной модели эта атака не предполагается в этой структуре! Вы можете обратиться кМоделирование инсайдерских атак на групповые протоколы обмена ключами . Вы можете заметить, что Канетти в своей оригинальной работе Универсально составляемые понятия обмена ключами и безопасных каналов упоминает предыдущее понятие безопасности, называемое SK-Security, которого достаточно просто для обеспечения безопасности протоколов аутентификации. Он каким-то образом признается (заявляя, что это вопрос технического характера), что определение UC в этом контексте является слишком ограничительным и предоставляет смягченный вариант, называемый неинформационным оракулом (который смутил меня, потому что я не видел эту модель безопасности где-либо в другом месте). Я не могу сопоставить этот шаблон безопасности с каким-либо другим шаблоном безопасности, вероятно, с моим отсутствием знаний: D).
[В качестве примечания, вы можете почти любой протокол Sk-secure преобразовать в протокол UC, независимо от времени симулятора. Например, вы можете просто удалить подписи сообщений и сделать так, чтобы симулятор имитировал все взаимодействия фиктивным способом. См. Универсальный составляемый обмен ключами в группе взносов для доказательства! Теперь предположим, что это протокол обмена групповыми ключами с полиномиальным числом сторон, какова будет эффективность симулятора? Это источник моего другого вопроса на этом форуме .]
В любом случае, из-за отсутствия приверженности в простой модели (через UC), я искал другие способы сделать протокол безопасным, просто обойдя необходимость в этом ослаблении. Эта идея настолько проста в моем сознании и пришла мне в голову, просто изучив последнюю схему обязательств canetti в простой модели: Адаптивная твердость и Composable Security в простой модели из стандартных допущений .
Кстати, я не ищу доказательства с нулевым разглашением, потому что по причине, которую я не знаю, всякий раз, когда кто-то использовал одно из них в параллельном протоколе (в рамках UC), другие упоминали протокол как неэффективный (может быть из-за перемотки симулятора).