11.5. Асимметричные протоколы

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

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

11.5.1. Протокол Деннинг Сакко

sequencediagram TrentTrent 2.5AliceAlice 2.5BobBob callAlice $A, B$ Trent $S_T( A, K_A, T_T )$, $S_T( B, K_B, T_T )$ Alice $E_B( S_A ( K, T_A ) )$, $S_T( A, K_A, T_T )$, $S_T( B, K_B, T_T )$ Bob
Рис. 11.23 — Протокол Деннинг Сакко

Протокол был предложен в 1981 году сотрудниками Университета Пердью Дороти Деннинг и Джованни Марией Сакко (англ. Dorothy E. Denning, Giovanni Maria Sacco, [28]). В данном протоколе к доверенному центру (Тренту) за сертификатами сразу обоих участников обращается инициатор (Алиса, рис. 11.23). Этот же участник отвечает и за формирование нового сессионного ключа $K$.

samepage==
  • $Alice \to \left\{ A, B \right\} \to Trent$
  • $Trent \to \left\{ S_T( A, K_A, T_T ), S_T( B, K_B, T_T ) \right\} \to Alice$
  • Алиса генерирует новый сессионный ключ $K$
  • $\begin{array}{lll} Alice \to \{ & E_B( S_A ( K, T_A ) ), & \\ & S_T( A, K_A, T_T ), & \\ & S_T( B, K_B, T_T ) & \} \to Bob \end{array}$
  • Боб проверяет подпись доверенного центра на сертификате $S_T( A, K_A, T_T )$, расшифровывает сессионный ключ $K$ и проверяет подпись Алисы.

В протоколе отсутствует как аутентификация второй стороны (Боба), так и подтверждение владения новым сессионным ключом.

Кроме того, отсутствие в сообщении $E_B( S_A ( K, T_A ) )$ каких-либо идентификаторов делает протокол уязвимым к атаке с известными сеансовым ключом и позволяет второй стороне (Бобу) выдать себя за инициатора (Алису) в сеансе с третьей стороной (Кларой, рис. 11.24).

sequencediagram TrentTrent 2.5BobBob 2.5ClaraClara callBob $ B, C $ Trent $S_T( B, K_B, T_{T2} )$, $S_T( C, K_C, T_{T2} )$ Bob $ E_C( S_A ( K, T_A ) )$, $S_T( A, K_A, T_{T1} )$, $S_T( C, K_C, T_{T2} )$ Clara
Рис. 11.24 — Атака на протокол Деннинг Сакко с известным разовым ключом. Опущены шаги взаимодействия Алисы, Трента и Боба, в процессе которых Боб запомнил полученные им $E_C( S_A ( K, T_A ) )$ и $S_T( A, K_A, T_{T1} )$.
samepage==
  • Алиса и Боб провели сеанс протокола, выработав новый сессионный ключ $K$.
  • $Bob \to \left\{ B, C \right\} \to Trent$
  • $Trent \to \left\{ S_T( B, K_B, T_T ), S_T( C, K_C, T_T ) \right\} \to Bob$
  • Боб воспроизводит сообщения $S_A ( K, T_A )$ и $S_T( A, K_A, T_T )$ от Алисы в сеансе с Кларой:
  • $\begin{array}{lll} Bob~(Alice) \to \{ & E_C( S_A ( K, T_A ) ), & \\ & S_T( A, K_A, T_T ), & \\ & S_T( C, K_C, T_T ) & \} \to Clara \end{array}$
  • Клара проверяет подпись доверенного центра $T$ на сертификате $S_T( A, K_A, T_T )$, расшифровывает сессионный ключ $K$ и проверяет подпись Алисы.

В результате Клара уверена, что получила от Алисы новый сессионный ключ $K$.

11.5.2. Протокол DASS

sequencediagram AliceAlice 2.5TrentTrent 2.5BobBob callAlice $B$ Trent $S_T \left( B, K_B \right)$ Alice$ E_K \left( T_A \right), S_A \left( L, A, K_P \right), S_{K_P} \left( E_B \left( K \right) \right) $Bob callBob$A$Trent $S_T ( A, K_A )$ Bob$ E_K \left( T_B \right) $Alice
Рис. 11.25 — Протокол DASS

Протокол DASS являлся составной частью сервиса распределённой аутентификации DASS (англ. Distributed Authentication Security Service), разработанного компанией DEC и описанного в RFC 1507 [52] в сентябре 1993 года.

В протоколе DASS, по аналогии с протоколами Wide-Mouth Frog и Деннинг Сакко, инициатор (Алиса) генерирует и новый сеансовый ключ, и, для каждого сеанса протокола, новую пару открытого и закрытого ключей отправителя. Доверенный центр (Трент) используется как хранилище сертификатов открытых ключей участников. Но в отличие от Деннинг Сакко к доверенному центру обращаются по очереди оба участника.

samepage==
  • $Alice \to \left\{ B \right\} \to Trent$
  • $Trent \to \left\{ S_T \left( B, K_B \right) \right\} \to Alice$
  • $Alice \to \left\{ E_K \left( T_A \right), S_A \left( L, A, K_P \right), S_{K_P} \left( E_B \left( K \right) \right) \right\} \to Bob$
  • $Bob \to \left\{ A \right\} \to Trent$
  • $Trent \to \left\{ S_T \left( A, K_A \right) \right\} \to Bob$
  • $Bob \to \left\{ E_K \left( T_B \right) \right\} \to Alice$

С помощью $S_T \left( B, K_B \right)$ и $S_T \left( A, K_A \right)$ – сертификатов открытых ключей, которые отправляет Трент, и дальнейшего подтверждения владения соответствующими ключами, участники могут аутентифицировать друг-друга. Успешная расшифровка временных меток из сообщений $E_K \left( T_A \right)$ и $E_K \left\{ T_B \right\}$ обеспечивает подтверждение владением сеансовым ключом.

sequencediagram MelloryMellory (Alice) 2TrentTrent 2BobBob Mellory$ E_K \left( T_M \right), S_A \left( L, A, K_P \right), S_{K_P} \left( E_B ( K ) \right) $Bob callBob$A$Trent $S_T ( A, K_A )$ Bob$ E_K \left( T_B \right) $Mellory
Рис. 11.26 — Атака на протокол DASS с известным сеансовым ключом (англ. known-key attack)

В протоколе используется время жизни ($L$) сеансового ключа $K_P$, однако в сообщение не включена метка времени. В результате протокол остаётся уязвимым к атаке с известным сеансовым ключом (KN). Предположим, что Меллори смогла записать полностью прошедший сеанс связи между Алисой и Бобом, а потом смогла получить доступ к сеансовому ключу $K$. Это позволяет Меллори аутентифицировать себя как Алиса перед Бобом (рис. 11.26).

samepage==
  • $Mellory~(Alice) \to \left\{ E_K \left( T_M \right), S_A \left( L, A, K_P \right), S_{K_P} \left( E_B \left( K \right) \right) \right\} \\ \to Bob$
  • $Bob \to \left\{ A \right\} \to Trent$
  • $Trent \to \left\{ S_T \left( A, K_A \right) \right\} \to Bob$
  • $Bob \to \left\{ E_K \left( T_B \right) \right\} \to Mellory~(Alice)$

На первом проходе Меллори меняет только первое сообщение, содержащее метку времени $E_K \left( T_M \right)$. Всё остальное Меллори копирует из записанного сеанса связи. Если Боб не записывает используемые ключи, он не заметит подмены. Простейшее исправление данной уязвимости состоит во включении метки времени в сообщение $S_A \left( T_A, L, A, K_P \right)$.

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

Ни Трент, ни Боб не участвуют в формировании новых сеансовых ключей. Поэтому Алиса может заставить Боба использовать старый сеансовый ключ, как в протоколах Wide-Mouth Frog (раздел 11.1.1) и Yahalom (раздел 11.1.2).

11.5.3. Протокол Ву Лама

sequencediagram AliceAlice 1.5TrentTrent 4BobBob callAlice $A, B$ Trent $S_T( K_B )$ Alice$ E_B ( A, R_A ) $Bob callBob$A, B, E_T( R_A )$Trent $S_T( K_A ), E_B ( S_T ( R_A, K, A, B ) )$ Bob$ E_A (S_T (R_A, K, A, B), R_B) $Alice Alice$ E_K( R_B ) $Bob
Рис. 11.27 — Протокол Ву Лама

Протокол Ву Лама, предложенный в 1992 году (англ. Thomas Y. C. Woo, Simon S. Lam, [109, 110], рис. 11.27), добавляет к сообщениям случайные числа участников, что позволяет защитить протокол в том числе от атак повтором, а также обеспечивает подтверждение владения ключами.

Также это единственный из рассмотренных в этом разделе протоколов, в котором новый ключ формируется доверенной стороной (Трентом).

samepage==
  • $Alice \to \left\{ A, B \right\} \to Trent$
  • $Trent \to \left\{ S_T( K_B ) \right\} \to Alice$
  • $Alice \to \left\{ E_B ( A, R_A ) \right\} \to Bob$
  • $Bob \to \left\{ A, B, E_T( R_A ) \right\} \to Trent$
  • $Trent \to \left\{ S_T( K_A ), E_B ( S_T ( R_A, K, A, B ) ) \right\} \to Bob$
  • $Bob \to \left\{ E_A (S_T (R_A, K, A, B), R_B) \right\} \to Alice$
  • $Alice \to \left\{ E_K( R_B ) \right\} \to Bob$

Так как в сертификате сессионного ключа $S_T (R_A, K, A, B)$ присутствует случайное число Алисы $R_A$, то злоумышленник не сможет использовать старый сертификат в новом сеансе от имени Боба. Следовательно 6-й проход протокола позволяет Алисе убедиться, что Боб знает новый сессионный ключ $K$, и, следовательно владеет своим «мастер»-ключом $K_B$ (так как это единственный способ получить сертификат из сообщения $E_B ( S_T ( R_A, K, A, B ) ))$).

Сообщение $E_K( R_B )$ от Алисы к Бобу на седьмом проходе позволяет одновременно гарантировать, что Алиса знает и свой «мастер»-ключ $K_A$ (так как смогла расшифровать $E_A(\dots, R_B)$), и новый сессионный ключ $K$, так как смогла корректно зашифровать $R_B$ этим ключом.