Криптографические протоколы (стр. 3 из 5)
Однако SA-GDH.2 имеет более высокую «вычислительную стоимость» по сравнению с A-GDH.2. Прежде всего, он требует (n-1) экспоненцирование для каждого Mi (кроме первого), в отличие от i экспоненцирований в A-GDH.2. К этому еще добавляется работа по формированию общих ключей для каждой пары абонентов (если они не вычислены заранее): на последнем этапе проводится одно экспоненцирование – как и в A-GDH.2. На рис. 1 приведены примеры протоколов A-GDH.2 и SA-GDH.2.
Как показано в [1], протокол SA-GDH.2 обеспечивает полную аутентификацию группового ключа.
Теорема 2.2.1 Протокол SA-DH обеспечивает полную аутентификацию группового ключа.
Док-во: предположим, Mi и Mj вычислили одинаковый ключ в результате выполнения протокола. Пусть Kn=Sn(Mi)=Sn(Mj), и предположим, что некто Mp ÎM (p¹i,j) не сделал вклада в этот ключ. Пусть Vi и Vj обозначают величины, полученные Mi и Mj на последнем этапе протокола. Напомним, что в соответствии с протоколом
Sn(Mi)=(Vi)(K1i-1…Kni-1)ri и Sn(Mj)=(Vj)(K1j-1…Knj-1)rj .
Поскольку все участники группы сделали вклад в ключ, то можно записать, что
Vi= (r1…rn/rpri)(K1i-1…Kni-1/Kpi-1) (для Vjаналогично), и
Sn(Mi)= (r1…rn/rp)Kpi-1, что должно равняться Sn(Mj)= (r1…rn/rp)Kpj-1.
Но поскольку Kpi-1 и Kpj-1 являются секретными, то получаем противоречие. #
В работе [1] также отмечается, что обсуждаемый протокол обладает устойчивостью к атакам по известному ключу (known key attacks), однако строгого формального доказательства не приведено, авторы лишь отмечают, что это легко пронаблюдать на приведенной выше атаке на A-GDH.2.
2.3 Особенности ключей протоколов A-GDH.2 и SA-GDH.2
Рассмотрим важное свойство протоколов – а именно подтверждение ключа. Не для каждого протокола это свойство является необходимым: например, оно не нужно, если взаимодействие с полученным ключом происходит немедленно. Но тем не менее свойство подтверждения ключа является желательным для протоколов обмена по следующим причинам:
1. Протоколы обмена становятся более сильными и автономными.
2. Исключается возможность вычисления неправильного ключа без обнаружения этого (в случае перерыва между выработкой общего ключа и непосредственно передачей данных).
С другой стороны, пока еще нет точного определения, что же такое подтверждение ключа для групп. Если брать полное подтверждение ключа, то это достигается путем получения каждым участником ключа и затем доказательства всем, что он знает этот ключ.
Для протоколов A-GDH.2 и SA-GDH.2 исходя из практических соображений было определено подтверждение ключа как подтверждение ключа для контролирующего группы (участника Mn). Это может быть легко достигнуто в обоих протоколах путем добавления
F(Sn(Mn))
в последнее сообщение протокола (рассылка всем участникам группы), где Sn(Mn) обозначает ключ, вычисленный Mn, а F – хэш-функцию, как это было определено выше.
Таким образом, участник группы Mi вычисляет Sn(Mi) и проверяет равенство:
F(Sn(Mi)) =?F(Sn(Mn)) .
В [2,5] замечено, что в A-GDH.2 и SA-GDH.2 подтверждение и неявная аутентификация ключа образуют полезный в некоторых случаях побочный эффект – аутентификацию участника Mn для всех участников группы. Это еще раз доказывает необходимость выделения Mn как отдельного лица – контролирующего группы.
Включение подтверждения ключа в протокол SA-GDH.2 приводит к интересному результату, а именно:
после выполнения протокола каждый участник группы Mi знает, что ключ, выработанный им, содержит вклад каждого участника группы.
Это следует непосредственно из свойств полной аутентификации группового ключа и подтверждения ключа. Если бы отсутствовало подтверждение ключа, то участники группы не могли бы убедиться в истинности своего ключа.
Опр. 2.3.1. (неформ.) Групповой протокол обмена для выработки общего ключа обеспечивает целостность группы, если каждый участник протокола уверен в участии каждого другого участника в протоколе.
Опр. 2.3.2. (неформ.) Групповой протокол обмена для выработки общего ключа является проверяемо контрибутивным (verifiable contributory), если каждый участник протокола уверен, что каждый другой участник сделал вклад в групповой ключ.
Свойство проверямой контрибутивности включает в себя свойство целостности группы. Обратное утверждение неверно, поскольку целостность группы может быть обеспечена, если участник группы Mi будет просто подписывать сообщение отсылать его дальше. Проверяемой контрибутивности в данном случае нет. В то же время проверяемая контрибутивность может выполняться, если в формировании ключа участвовало лицо, стороннее по отношению к группе. Таким образом противник может влиять на протокол.
Однако следует заметить, что даже если выполняются свойства (неявной, полной) аутентификации и подтверждения ключа, свойство целостности ключа в вышеприведенном протоколе SA-GDH.2 не достигается.
Рассмотрим приведенный на рис. 2 пример для трех участников.
Предположим, что имеется активный противник, который может вмешиваться в передачу, подменять и модифицировать данные. Он может провести какое-либо экспоненцирование данных на этапе (1) и/или (2) и это останется незамеченным. Пусть он просто возводит в квадрат все величины на этапе (2). Тогда M3 получит следующие значения: a 2r1K12, a 2r1r2K13K23, a 2r2K21.
В результате M3 вычислит S3(3)= a 2r1r2 r3, т.е. квадрат предполагавшегося ключа. Все остальные участники группы получат то же самое. Подтверждение ключа здесь не помогает, поскольку злоумышленник вторгается в протокол перед тем, как M3 вычисляет свой групповой ключ.
Как было справедливо замечено в [1], протокол SA-GDH.2 подвержен (пока) только мультипликативному (экспоненциальному) влиянию противника на ключ, т.е. можно получить ключ Kc, где с- некоторая константа, а К-ключ, предполагаемый в протоколе. Авторы задаются вопросом: так ли важна целостнось ключа в протоколе обмена с проверяемой контрибутивностью?
Для обеспечения целостности можно воспользоваться сторонними средствами обеспечения целостности данных во время передачи – например, проверять целостность пакетов при отправке по сети. На последнем же широковещательном этапе никаких сторонних средств не требуется, т.к любое вмешательство будет обнаружено из-за свойства подтверждения ключа для контролирующего группы.
2.4 Сравнение эффективности
Приведем таблицу сравнения протоколов (по вычислительным требованиям). Понятно, что различные реализации будут различаться по скорости выполнения и объему кода, а также типа используемых процессоров – это отдельная тема и с математической точки зрения не представляет интереса, нужные таблицы приведены в [2,3,4,5]. Поэтому ограничимся приведением лишь вычислительных характеристик в таблице 1.
| Стоимость вычислений | GDH.2 | A-GDH.2 | SA-GDH.2 |
| Экспоненцирований для Mi | I+1 | i+1 | n |
| Экспоненцирований для Mn | N | n | N |
| Всего экспоненцирований | (n2+3n)/2-1 | (n2+3n)/2-1 | n2 |
| Вычисления обр. элементов для Mi | 1 | ||
| Вычисления обр. элементов для Mn | 1 | ||
| Всего вычислений обр. элементов | n | ||
| Умножений для Mi | 1 | 2n-2 | |
| Умножений для Mn | n-1 | 2n-2 | |
| Всего умножений | 2n-2 | 2n2-2n |
Полученные в результате приведенных протоколов общие ключи могут использоваться как ключи для секретной связи внутри группы, служить для аутентификации участников группы, выполнять роль секретного ключа при формировании групповой подписи и т.д.
3 Проект CLIQUES
Целью данного проекта являлась разработка протокола обмена для выработки ключа для групп. Такой протокол должен поддерживать все групповые операции по удалению, включению новых участников в группу. На основе этого протокола необходимо было создать специальный прикладной программный интерфейс (CLQ-API) , позволяющий работать приложениям в неких абстрактных группах. Протокол во многом основывается на вышеописанных протоколах аутентичного обмена. Ограничимся рассмотрением только математических принципов проекта. Не будем рассматривать полученные результаты (по эффективности), программные реализации.