Предыдущая страница реферата | 1  2  3  4  5  6  7 | Следующая страница реферата

1. Протоколы обмена становятся более сильными и автономными.

2. Исключается возможность вычисления неправильного ключа  без обнаружения этого (в случае перерыва между выработкой общего ключа и непосредственно передачей данных).

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

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

a F(Sn(Mn))

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

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

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

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

3 Проект CLIQUES

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

Рекомендуем скачать другие рефераты по теме: решебник по химии, реферат методы.





Предыдущая страница реферата | 1  2  3  4  5  6  7 | Следующая страница реферата