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

Для протоколов A-GDH.2 и SA-GDH.2 исходя из практических соображений было определено подтверждение ключа как подтверждение ключа для контролирующего группы (участника M_n ) . Это может быть легко достигнуто в обоих протоколах путем добавления

 ^{F (Sn (Mn ))}

в последнее сообщение протокола (рассылка всем участникам группы), где S_n (M_n ) обозначает ключ, вычисленный M_n , а F – хэш-функцию, как это было определено выше.

Таким образом, участник группы M_i вычисляет S_n (M_i ) и проверяет равенство:

 ^{F (Sn (Mi ))} =? ^{F (Sn (Mn ))} .

В [2,5] замечено, что в A-GDH.2 и SA-GDH.2 подтверждение и неявная аутентификация ключа образуют полезный в некоторых случаях побочный эффект – аутентификацию участника M_n для всех участников группы. Это еще раз доказывает необходимость выделения M_n как отдельного лица – контролирующего группы.

Включение подтверждения ключа в протокол SA-GDH.2 приводит к интересному результату, а именно:

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

Это следует непосредственно из свойств полной аутентификации группового ключа и подтверждения ключа . Если бы отсутствовало подтверждение ключа, то участники группы не могли бы убедиться в истинности своего ключа.

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

Опр. 2.3.2. (неформ.) Групповой протокол обмена для выработки общего ключа является проверяемо контрибутивным (verifiable contributory) , если каждый участник протокола уверен, что каждый другой участник сделал вклад в групповой ключ.

Свойство проверямой контрибутивности включает в себя свойство целостности группы. Обратное утверждение неверно, поскольку целостность группы может быть обеспечена, если участник группы M_i будет просто подписывать сообщение отсылать его дальше. Проверяемой контрибутивности в данном случае нет. В то же время проверяемая контрибутивность может выполняться, если в формировании ключа участвовало лицо, стороннее по отношению к группе. Таким образом противник может влиять на протокол.

Однако следует заметить, что даже если выполняются свойства (неявной, полной) аутентификации и подтверждения ключа, свойство целостности ключа в вышеприведенном протоколе SA-GDH.2 не достигается.

Рассмотрим приведенный на рис. 2 пример для трех участников.

Предположим, что имеется активный противник, который может вмешиваться в передачу, подменять и модифицировать данные. Он может провести какое-либо экспоненцирование данных на этапе (1) и/или (2) и это останется незамеченным. Пусть он просто возводит в квадрат все величины на этапе (2). Тогда M₃ получит следующие значения: a ^{2r 1K 12} , a ^{2r 1r 2K 13K 23} , a ^{2r 2K 21} .

В результате M₃ вычислит S₃ (3)= a ^{2r 1r 2 r 3} , т.е. квадрат предполагавшегося ключа. Все остальные участники группы получат то же самое. Подтверждение ключа здесь не помогает, поскольку злоумышленник вторгается в протокол перед тем, как M₃ вычисляет свой групповой ключ.

Как было справедливо замечено в [1], протокол SA-GDH.2 подвержен (пока) только мультипликативному (экспоненциальному) влиянию противника на ключ, т.е. можно получить ключ K^c , где с - некоторая константа, а К -ключ, предполагаемый в протоколе. Авторы задаются вопросом: так ли важна целостнось ключа в протоколе обмена с проверяемой контрибутивностью?

Для обеспечения целостности можно воспользоваться сторонними средствами обеспечения целостности данных во время передачи – например, проверять целостность пакетов при отправке по сети. На последнем же широковещательном этапе никаких сторонних средств не требуется, т.к любое вмешательство будет обнаружено из-за свойства подтверждения ключа для контролирующего группы.

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
Всего экспоненцирований	(n 2 +3n )/2-1	(n 2 +3n )/2-1	n 2
Вычисления обр. элементов для Mi			1
Вычисления обр. элементов для Mn			1
Всего вычислений обр. элементов			n
Умножений для Mi		1	2n -2
Умножений для Mn		n -1	2n -2
Всего умножений		2n -2	2n 2 -2n

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

3 Проект CLIQUES

Целью данного проекта являлась разработка протокола обмена для выработки ключа для групп. Такой протокол должен поддерживать все групповые операции по удалению, включению новых участников в группу. На основе этого протокола необходимо было создать специальный прикладной программный интерфейс (CLQ-API) , позволяющий работать приложениям в неких абстрактных группах. Протокол во многом основывается на вышеописанных протоколах аутентичного обмена. Ограничимся рассмотрением только математических принципов проекта. Не будем рассматривать полученные результаты (по эффективности), программные реализации.

В качестве базового протокола обмена для выработки общего ключа был выбран протокол A-GDH.2 (однако возможно использование и SA-GDH.2). Предполагается, что участники группы уже сформировали общий ключ.

Рассмотрим основные операции, которые позволяет выполнять разработанный протокол.

1. Операции для одного участника группы: включают в себя добавление или удаление одного участника группы. Данные ситуации появляются, когда кто-то хочет присоединиться к группе или покинуть ее. Эти операции могут проводится контролером группы или по согласию каждого участника группы (в зависимости от используемой политики безопасности).

2. Операции для нескольких участников: также включают в себя добавление и удаление. Однако есть отличия, обусловленные желанием проводить операции с несколькими участниками сразу, а не с каждым в отдельности:

· массовое присоединение: несколько участников хотят присоединиться к существующей группе;

· слияние групп: две или более групп желают соединиться в одну;

· массовый выход из группы: несколько участников хотят покинуть группу;