Доказательство того, что протокол не подвергается атаке

Рассмотрим следующий протокол:

1. $A\стрелка вправо B: \{N_A,A\}_{pk(B)}$

2. $B\rightarrow A: \{N_B,N_A\}_{pk(A)}$

3. $A\стрелка вправо B: хэш(N_B, A, B)$

где предполагается, что когда либо $А$ или же $В$ выполнили свою роль в протоколе, они уверены, что другой участвовал в протоколе вместе с ними и что $N_A$ и $N_B$ являются случайными одноразовыми номерами, сгенерированными $А$ и $В$. $\{Х\}_{У}$ Значит это $Х$ шифруется под ключ $Y$.

Я точно знаю, что для этого протокола не существует атаки, но я не знаю, как это доказать.

Без четко определенных возможностей злоумышленника и гарантий безопасности различных компонентов (шифрование с открытым ключом, хэш-функция и т. д.). Нелегко сказать, является ли этот протокол «присоединяемым».

Учитывая, что нам дан «карт-бланш», я покажу две атаки PITM, основанные на различных моделях безопасности и атакующих.

Общая модель злоумышленника: я предполагаю, что злоумышленник имеет полный контроль над сетью, он может вводить, переупорядочивать, изменять и иным образом удалять сообщения. Кроме того, злоумышленнику разрешено «регистрировать» новых пользователей в любое время.

Атака 1: Неправильная привязка личности и потребность в защищенном PKE, выходящем за рамки CPA

Как написано, кажется, что протокол должен быть безопасным, пока используется «безопасная» схема PKE. Однако базового понятия безопасности как семантической безопасности недостаточно. На высоком уровне, в конце атаки, $А$ думает, что они разговаривают с $В$, пока $В$ думает, что они разговаривают с нападавшим $Е$.

Для этого мы покажем безопасный PKE CPA, для которого возможна атака. Позволять $\математический E$ быть «гибридной» схемой PKE (иначе основанной) на функции лазейки. Где шифрование сообщения $м$ под $пк$, примерно состоит из генерации случайного значения $s$ затем сгенерируйте симметричный ключ шифрования $к = Н(с)$. $к$ затем используется для шифрования сообщения с помощью алгоритма, подобного потоковому шифру, создавая зашифрованный текст $с$. Окончательный зашифрованный текст схемы PKE: $$\{m\}_{pk} = (enc_{PKE}(pk, s), c)$$ Атака работает следующим образом.

1. $ A\стрелка вправо B: c_1 = \{N_A,A\}_{pk(B)} $
2. Злоумышленник перехватывает это сообщение, создает нового пользователя $Е$, изменяет зашифрованный текст на значение $c_1'$ таким образом, чтобы он расшифровывал $N_A, Е$. Это возможно, поскольку мы используем потоковый шифр. (Мы также предполагаем, например, что одноразовый номер и идентификаторы имеют фиксированную длину и т. д.)
3. $В$ расшифровывает сообщение и кажется $Е$ личности, поэтому второе сообщение отправляется на $Е$
4. $B \rightarrow E: c_2 = \{N_A. N_B\}_{pk_E}$.
5. $Е$ расшифровывает $c_2$, и получает одноразовые номера.
6. $E \rightarrow A: c_2' = \{N_A, N_B\}_{pk_A}$
7. $A \rightarrow B: c_3 = H(N_B, A, B)$
8. $Е$ перехватывает капли $c_3$ и отправить $c_3' = H(N_B,E,B)$

Из потока выше вид на $А$ так же, как если бы он взаимодействовал с $В$, в то время как вид $В$ как будто взаимодействует с $Е$.

Атака 2: долгосрочное раскрытие секрета и компрометация целостности ключа

Здесь возможности злоумышленника усиливаются, и мы допускаем компрометацию долговременных секретных ключей. Теперь очевидно, если $sk_A$ скомпрометирован (и $А$ еще не знает) злоумышленник может выдать себя за $А$ по желанию; однако кажется нормальным ожидать, что если $А$ проводит сеанс с честным $В$, $А$ должна быть уверена в том, с кем она разговаривала. Однако в этой атаке компрометация $sk_A$ подразумевает, что злоумышленник может выдать себя за кого угодно $А$.

Основная идея, как указано выше, заключается в том, что злоумышленник PITM сможет расшифровать второе сообщение. $\{N_A, N_B\}_{pk_A}$. Злоумышленник теперь может завершить взаимодействие с $А$ и «перерезать провод» в направлении B. Как следствие, $А$ думает, что они разговаривают $В$ фактически разговаривая с Б.

Я предполагаю многое о протоколе, который не является явным в вопросе. Я заявляю об этом во втором разделе этого ответа. Также я не буду делать свои аргументы слишком подробными.

Желаемая страховка есть

(участники) уверены, что другой участвовал в протоколе с ними

но я удалю с ними, поскольку это неясно, и я не вижу точного определения, которому может соответствовать крипто (человек посередине всегда может передавать сообщения без изменений). я заменю его на с момента запуска протокола, который не следует путать с гораздо более сильным так, как обычно идет протокол.

На шаге 1 $N_A$ был случайно выбран $А$ и зашифровано под $пк(Б)$, как часть открытого текста $\{N_A,A\}_{pk(B)}$. Таким образом, только $А$ или какая-то сущность, обладающая некоторой степенью способности расшифровывать $\{N_A,A\}_{pk(B)}$, то есть только $В$, может знать что-нибудь о $N_A$ рядом с его длиной. Таким образом, когда по завершении шага 2 $А$ получает что-то, что расшифровывает $N_A$, и они знают, что не использовали $N_A$ для другой цели, кроме генерации сообщения шага 1, они уверены, что $В$ участвовал в протоколе. Я не буду делать это заверение количественным, оставив его для другого направления.

На шаге 2 $N_B$ был случайно выбран $В$ и зашифровано под $пк(А)$, как часть открытого текста $\{N_B,N_A\}_{пк(А)}$. Таким образом, только $В$ или объект, обладающий некоторой степенью способности расшифровывать $\{N_B,N_A\}_{пк(А)}$, то есть только $А$, может знать что-нибудь о $N_B$ рядом с его длиной. Предполагая
 (а) хеш — это случайный оракул с выходной шириной $k_H$,
(б) $N_B$ был выбран равномерно случайным образом и имеет ширину $k_N$,
 (c) любой противник имеет преимущество, ограниченное $\эпсилон$ против шифрования,
затем указанный противник как вероятность, ограниченная сверху $2^{-k_H}+2^{-k_N}+\эпсилон$ чтобы точно найти значение хеша шага 3. Таким образом, когда по завершении шага 3 $В$ находит такое значение для хэша, который они пересчитывают, и они знают, что не использовали $N_B$ для другой цели, кроме генерации сообщения шага 2, они уверены, что $А$ участвовал в протоколе.

Если это рассуждение верно, шаг 3 можно упростить до $A\стрелка вправо B:\ решетка (N_B)$. Если нет, то я хочу знать, почему! Это не следует рассматривать как предложение сделать это упрощение: включение идентификаторов в то, что хешируется, может только помочь, и я смутно вижу, что это может заблокировать некоторые преднамеренные изменения протокола, но не такие, которые нарушают гарантии безопасности, как я повторил. Это.

Частичный список предположений, не указанных в вопросе

• Позднее добавление: общедоступные ключи известны и доверительны до запуска протокола.
• Позднее добавление: шифр безопасен для IND-CCA2. Поскольку я не уверен в том, сможем ли мы обойтись меньшим имуществом, я предпочел бы ошибиться на всякий случай.
• Как часто не указывается при анализе протокола, получатели сообщений
  • попытаться расшифровать и прервать, если это не удается (как это делают многие шифры IND-CCA2)
  • анализировать расшифрованные сообщения в соответствии с соглашением, изложенным для их генерации, и прерывать, если это не удается
  • проверяйте полученные значения на соответствие их ожидаемому значению, если они известны из предыдущего шага или могут быть вычислены иным образом (как это происходит для хэша шага 3 на $В$ сторона) и прервать при отсутствии совпадений. Не кажется необходимым, чтобы такое сравнение производилось за постоянное время.
  • или/и повторно использовать указанное значение для переменных с тем же именем на следующих шагах.
• В открытом тексте зашифрованных сообщений знак запятой символизирует форму конкатенации с условием, что из результата остается возможность разделения в точке, где произошла конкатенация, например. потому что одно из двух объединенных сообщений имеет фиксированный размер. Это не кажется необходимым для знака запятой, используемого в сообщении, хешированном на шаге 3.
• В сообщениях, $А$ и $В$ являются личности одноименных участников.
• Объекты используют свои закрытые ключи только для расшифровки получаемых ими сообщений.
• После шага 1, $В$ решает, какой открытый ключ они используют для шифрования на шаге 2 и какому получателю отправить на этом шаге, на основе второй части $А$ расшифрованного сообщения шага 1, и прервать, если они не знают соответствующий открытый ключ. Это не обязательно для безопасности протокола, как указано, они проверяют, что эта вторая часть не является их собственной личностью.
• Если участники пытаются установить несколько одновременных подключений, как это обычно делают серверы, предполагается, что они сохраняют отдельные переменные для каждого экземпляра протокола. Я не вижу причин, по которым не было бы нормально, если бы множественные попытки подключения, в которые вовлечена сущность, были бы в потенциально разных направлениях.
• Я игнорирую побочные каналы, которые еще не обсуждались, атаки сбоев и ошибки реализации.