- •Н. М. Радько а. Н. Мокроусов
- •1. Принципы и основные типы
- •1.1. Протоколы с арбитражем.
- •1.2. Протокол с судейством.
- •1.3. Самоутверждающийся протокол.
- •1.4. Разновидности атак на протоколы.
- •1.5. Доказательство с нулевым разглашением
- •1.6. Параллельные доказательства с нулевым
- •1.7. Неинтерактивные протоколы доказательства с нулевым разглашением конфиденциальной информации.
- •1.8. Удостоверение личности с нулевым разглашением
- •1.9. Неосознанная передача информации.
- •1.10. Анонимные совместные вычисления.
- •1.11. Вычисление средней зарплаты.
- •1.12. Как найти себе подобного.
- •1.13. Депонирование ключей.
- •2. Криптографические протоколы
- •2.1 Основные определения и понятия
- •2.1.1. Основные определения
- •2.1.2. Используемые в протоколах термины и обозначения
- •2.2. Протоколы аутентичного обмена ключами
- •2.2.1. Протоколы a-dh, gdh.2 и a-gdh.2
- •Теорема 2.1.1 Протокол a-dh обеспечивает свойство pfs.
- •Рассмотрим теперь протокол Диффи-Хеллмана для групп [27].
- •2.2.2 Протокол sa-gdh.2
- •Для выполнения этого определения можно модифицировать протокол a-gdh.2 в следующий:
- •2.2.3. Особенности ключей протоколов a-gdh.2 и sa-gdh.2
- •2.2.4 Сравнение эффективности
- •2.3. Проект cliques
- •2.3.1. Присоединение
- •2.3.2. Слияние
- •2.3.3. Выход из группы
- •2.3.4. Обновление ключа
- •2.4. Перспективы использования.
- •Безопасность сетей на базе семейства протоколов tcp/ip
- •3.1. Особенности безопасности компьютерных сетей
- •3.2. Классификация компьютерных атак
- •3.3. Статистика самых распространенных атак
- •3.4. Анализ сетевого трафика сети Internet
- •3.5. Ложный arp-сервер в сети Internet
- •3.6. Навязывание хосту ложного маршрута с использованием
- •3.7. Подмена одного из субъектов tcp-соединения
- •3.8. Направленный шторм ложных tcp-запросов на создание соединения.
- •3.9.Атаки, использующие ошибки реализации сетевых служб.
- •3.10. Атака через www.
- •3.11. Методы защиты от удалённых атак в сети Internet.
- •4. Протоколы квантовой криптографии
- •4.1. Природа секретности квантового канала связи.
- •4.2. Проблемы и решения
- •4.3. Распределение/передача ключей
- •4.4. Введение в квантовую криптографию
- •4.5. Основы квантовой криптографии
- •4.5.1. Протокол bb84
- •4.5.2. Протокол b92
- •4.5.3. Уточнение чернового варианта ключа
- •4.6. Системы с квантовой передачей ключа
- •4.6.1. Системы с поляризационным кодированием
- •4.6.2. Системы с фазовым кодированием
- •4.8. Общие характеристики протоколов для квантово-криптографических систем распределения
- •4.9. Технологические проблемы и перспективы роста.
- •394026 Воронеж, Московский просп., 14
2.2.3. Особенности ключей протоколов a-gdh.2 и sa-gdh.2
Рассмотрим важное свойство протоколов – а именно подтверждение ключа. Не для каждого протокола это свойство является необходимым: например, оно не нужно, если взаимодействие с полученным ключом происходит немедленно. Но тем не менее свойство подтверждения ключа является желательным для протоколов обмена по следующим причинам:
Протоколы обмена становятся более сильными и автономными.
Исключается возможность вычисления неправильного ключа без обнаружения этого (в случае перерыва между выработкой общего ключа и непосредственно передачей данных).
С другой стороны, пока еще нет точного определения, что же такое подтверждение ключа для групп. Если брать полное подтверждение ключа, то это достигается путем получения каждым участником ключа и затем доказательства всем, что он знает этот ключ.
Для протоколов A-GDH.2 и SA-GDH.2 исходя из практических соображений было определено подтверждение ключа как подтверждение ключа для контролирующего группы (участника Mn). Это может быть легко достигнуто в обоих протоколах путем добавления
F(Sn(Mn))
в последнее сообщение протокола (рассылка всем участникам группы), где Sn(Mn) обозначает ключ, вычисленный Mn, а F – хэш-функцию, как это было определено выше.
Таким образом, участник группы Mi вычисляет Sn(Mi) и проверяет равенство:
F(Sn(Mi)) = F(Sn(Mn)) .
В [27,30] замечено, что в A-GDH.2 и SA-GDH.2 подтверждение и неявная аутентификация ключа образуют полезный в некоторых случаях побочный эффект – аутентификацию участника Mn для всех участников группы. Это еще раз доказывает необходимость выделения Mn как отдельного лица – контролирующего группы.
Включение подтверждения ключа в протокол SA-GDH.2 приводит к интересному результату, а именно:
после выполнения протокола каждый участник группы Mi знает, что ключ, выработанный им, содержит вклад каждого участника группы.
Это следует непосредственно из свойств полной аутентификации группового ключа и подтверждения ключа. Если бы отсутствовало подтверждение ключа, то участники группы не могли бы убедиться в истинности своего ключа.
Опр. 2.9. (неформ.) Групповой протокол обмена для выработки общего ключа обеспечивает целостность группы, если каждый участник протокола уверен в участии каждого другого участника в протоколе.
Опр. 2.10. (неформ.) Групповой протокол обмена для выработки общего ключа является проверяемо контрибутивным (verifiable contributory), если каждый участник протокола уверен, что каждый другой участник сделал вклад в групповой ключ.
Свойство проверямой контрибутивности включает в себя свойство целостности группы. Обратное утверждение неверно, поскольку целостность группы может быть обеспечена, если участник группы Mi будет просто подписывать сообщение отсылать его дальше. Проверяемой контрибутивности в данном случае нет. В то же время проверяемая контрибутивность может выполняться, если в формировании ключа участвовало лицо, стороннее по отношению к группе. Таким образом противник может влиять на протокол.
Однако следует заметить, что даже если выполняются свойства (неявной, полной) аутентификации и подтверждения ключа, свойство целостности ключа в вышеприведенном протоколе SA-GDH.2 не достигается.
Рассмотрим приведенный на рис.2.2 пример для трех участников.
Рис.2.2. Пример SA-GDH.2
для 3 участников.
Предположим, что имеется активный противник, который может вмешиваться в передачу, подменять и модифицировать данные. Он может провести какое-либо экспоненцирование данных на этапе (1) и/или (2) и это останется незамеченным. Пусть он просто возводит в квадрат все величины на этапе (2). Тогда M3 получит следующие значения: 2r1K12, 2r1r2K13K23, 2r2K21.
В результате M3 вычислит S3(3)= 2r1r2 r3, т.е. квадрат предполагавшегося ключа. Все остальные участники группы получат то же самое. Подтверждение ключа здесь не помогает, поскольку злоумышленник вторгается в протокол перед тем, как M3 вычисляет свой групповой ключ.
Как было справедливо замечено в [26], протокол SA-GDH.2 подвержен (пока) только мультипликативному (экспоненциальному) влиянию противника на ключ, т.е. можно получить ключ Kc, где с- некоторая константа, а К-ключ, предполагаемый в протоколе. Авторы задаются вопросом: так ли важна целостнось ключа в протоколе обмена с проверяемой контрибутивностью?
Для обеспечения целостности можно воспользоваться сторонними средствами обеспечения целостности данных во время передачи – например, проверять целостность пакетов при отправке по сети. На последнем же широковещательном этапе никаких сторонних средств не требуется, т.к любое вмешательство будет обнаружено из-за свойства подтверждения ключа для контролирующего группы.