Особенности ключей протоколов 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 получит следующие значения:  2r1K12,  2r1r2K13K23,  2r2K21.
В результате M3 вычислит S3(3)=  2r1r2 r3, т.е. квадрат предполагавшегося ключа. Все остальные участники группы получат то же самое. Подтверждение ключа здесь не помогает, поскольку злоумышленник вторгается в протокол перед тем, как M3 вычисляет свой групповой ключ.
Как было справедливо замечено в [1], протокол SA-GDH.2 подвержен (пока) только мультипликативному (экспоненциальному) влиянию противника на ключ, т.е. можно получить ключ Kc, где с- некоторая константа, а К-ключ, предполагаемый в протоколе. Авторы задаются вопросом: так ли важна целостнось ключа в протоколе обмена с проверяемой контрибутивностью?
Для обеспечения целостности можно воспользоваться сторонними средствами обеспечения целостности данных во время передачи – например, проверять целостность пакетов при отправке по сети. На последнем же широковещательном этапе никаких сторонних средств не требуется, т.к любое вмешательство будет обнаружено из-за свойства подтверждения ключа для контролирующего группы.