Современная криптография - Венбо Мао
ISBN 5-8459-0847-7
Скачать (прямая ссылка):
В большинстве случаев неправильная интерпретация проявляется в том, что пользователя путем обмана вынуждают неправильно интерпретировать случайно! число, метку времени, имя, зашифрованное в ключе, и т.п. Такая ошибка может< возникнуть вследствие неудачной разработки протокола. Продемонстрируем атаку] на основе неправильной интерпретации [69, 285] на примере протокола, предлся женного Нойманом (Neuman) и Стаблбайном (Stubblebine) [214]. Этот протокол выглядит следующим образом.
1. Алиса —> Бобу: A, NA.
2. Боб Тренту: В, [A, Na,Tb}Kbt , NB.
3. Трент Алисе: {В, NA, КАВ, Тв}Клт , {А, КАВ, Тв}Квт , NB.
4. Алиса - Бобу: {А,КАВ,Тв}Квт, {Nb}Kab -
Этот протокол должен обеспечить взаимную аутентификацию Алисы и Боба, а также генерацию аутентифицированного ключа с помощью доверенного посредника, Трента. Если случайное число и ключ имеют одинаковую длину, это! протокол позволяет Злоумышленнику организовать атаку на основе неправильно! интерпретации.
Глава 11. Протоколы аутентификации — принципы
429
1. Злоумышленник ("Алиса") —> Бобу: A, Na-
2. Боб —» Злоумышленнику("Тренту"): В, {А, ЛГд, Тд}к , Nb-
3. Ничего.
4. Злоумышленник ("Алиса") -> Бобу. {A, NA, Тв}Квт, {Nb}Na -
В ходе этой атаки Злоумышленник вместо сеансового ключа Кав использует одноразовое случайное число Na- Если Боб не способен различать тип информации, он может ошибочно принять это число в качестве сеансового ключа, и предотвратить этот обман невозможно.
Ошибочная интерпретация информации, как правило, зависит от особенностей реализации протокола. Если спецификация протокола недостаточно ясно описывает тип переменных, используемых в протоколе, ошибка практически неизбежна. Бойд (Boyd) [226] проиллюстрировал эту проблему на примере протокола аутентификации Отвея-Рииса (Otway-Rees) [256] и показал, насколько важно избегать при разработке криптографических протоколов предположений, принятых по умолчанию.
11.7.7 Атака на основе безымянных сообщений
В протоколах аутентификации имя автора сообщения и ключ шифрования, как правило, можно выяснить по контексту. Однако в ситуациях, когда это сделать невозможно, отсутствие имени порождает большие проблемы.
Эксперты в области криптографии, защиты информации и разработки протоколов весьма часто делают эту ошибку. Возможно, это связано с их желанием создать элегантный протокол, не страдающий избыточностью. Яркими примерами атаки на основе безымянных сообщений (attack due to name omission) являются две атаки на варианты протокола STS, рассмотренные в разделах 11.6.2 и 11.6.3 соответственно. Рассмотрим еще один пример.
Деннинг (Denning) и Сакко (Sacco) предложили протокол с открытым ключом, представляющий собой альтернативу протоколу аутентификации с симметричным ключом Нидхема-Шредера [94]. Протокол Деннинга-Сакко выглядит следующим образом.
1. Алиса —» Тренту: А, В.
2. Трент —» Алисе: Сеид, СеПд.
3. Алиса -> Бобу: Сепд, CertB, {sigA (КАв, Та)}кв ¦
В этом протоколе третье сообщение шифруется, чтобы обеспечить его секретность и аутентичность. Когда Боб получает сообщение от Алисы, он видит, что сеансовый ключ Кав должен быть разделен только между ним и Алисой, поскольку он видит подпись Алисы и следы применения ее открытого ключа.
К сожалению, протокол не гарантирует, что ключ будет разделен только между Бобом и Алисой. Абади и Нидхем изобрели простую, но впечатляющую атаку [1],
430
Часть IV. Аутентификация
в ходе которой Боб, получив сообщение от Алисы, может заставить другого пользователя поверить, будто имеет место следующее "свойство".
3'. Боб ("Алиса") -» Чарли: CertA, Certc, {sigA {КАВ,ТА)}Кс . Чарли поверит, что сообщение пришло от Алисы, и может послать ей ответ, зашифрованный сеансовым ключом КАВ. Увы, Боб сможет его прочитать!
Сообщение 3 имеет следующий смысл: "В момент ТА Алиса говорит, что ключ КАВ является правильным ключом для связи между Алисой и Бобом". Очевидно, что правильная спецификация должна выглядеть так.
3. Алиса Бобу: Сегхл, Certc, {ъщА (А,В,КАВ,ТА)}Кв .
Разрабатывая протоколы, проектировщики должны предусмотреть явное указание имен участников протокола, особенно при выполнении криптографических операций. Однако даже опытные конструкторы часто игнорируют это требование, поэтому Абади и Нидхем внесли это правило в список основных принципов разработки протокола.
Если имя автора существенно для понимания смысла, его необходимо указывать явно.
Наше навязчивое повторение этого принципа совершенно не излишне: в разделе 12.2 мы продемонстрируем, что протокол IKE [135] также страдает от этого недостатка, хотя его разрабатывали умудренные эксперты в области защиты информации, имеющие многолетний опыт разработки протоколов.
11.7.8 Атака на основе неправильного выполнения криптографических операций
В заключение рассмотрим очень распространенный дефект протоколов —I неправильное выполнение криптографических операций, которое заключается в отсутствии необходимой защиты. Этот недостаток проявляется в двух ситуациях.
1. Атака вследствие отсутствия защиты целостности данных. Мы продемонстрируем атаку на ослабленный протокол, которая становится возмож4 ной из-за отсутствия защиты целостности данных. Более многочисленные примеры атак на криптографические протоколы с открытым ключом содержатся в главе 14, в которой рассматривается понятие стойкости против адаптивных атак. Кроме того, этот дефект протоколов подробно изучается в разделе 17.2, посвященном формальному анализу протоколов аутентификации.
