Очевидно, что протокол обладает свойством контрибутивности, поскольку в результирующем ключе S_n есть вклад i-го участника группы в виде степени r_i.

Теорема 2.1.2 Протокол A-GDH.2 обеспечивает свойство PFS.

Док-во: Предположим, что долговременные ключи K_in, i[1,n] скомпрометированы, тогда противник в состоянии вычислить подмножество V={^П(S)| S{r₁,…,r_n}}. Но, как было показано в [2], по такому V не возможно восстановить сеансовый ключ S_n. #

Рассмотрим устойчивость описанного протокола к атакам по известным ключам.

Пусть S_n(M_i) – сеансовый ключ, вычисленный каждым M_i. Для 0<i<n-1 можно записать его как ^C_i^r_i^K-1_in. Для M_n S_n(M_n)=^C_n^r_n, где c_i возможно известно противнику C. C также знает подмножество {^П(S)| S{r₁,…,r_n}}. В данных условиях нахождение ^Kin или ^K-1_in невозможно, если вычислительно трудно решить проблему “распознавания Диффи-Хеллмана” [1].

Однако, некоторые из атак возможны. Если С попытается послать M₁ некоторое ^c1 на последнем этапе протокола (где с₁ выбирается противником), то M₁ в результате получит неверный ключ S_n(M₁)=^c₁^r₁^K-1_1n, обнаружит проблему и просто заново запустит протокол обмена. Допустим, что противник каким-то образом получил этот неверный ключ (заметим, что на практике это маловероятно). При повторном выполнении протокола С может подменить сообщение от M_n-1 к M_n на

^c₁^r₁^K_1n^-1,…,^c1r1.

С подменил первое и последнее слово в сообщении, остальные слова не изменялись. Тогда M_n вычислит ключ S_n(M_n)=(^c₁^r₁)^r_n. M_n также вычислит

(^c₁^r₁^K_1n^-1)^r_n^K_1n=^c₁^r₁^r_n

и отошлет это значение M₁ в последнем этапе протокола. В результате С будет знать ключ M₁. Но (хотя в работе [1] это и не отмечается), общий групповой ключ опять не совпадет, и через некоторое время протокол придется повторить снова. Все дело во времени определения конфликта ключей. Однако, в такого типа атаке очень много условностей, и поэтому ее можно отнести к разряду теоретических, а не к реально осуществимым атакам. Кроме того, как указано в [1], простым средством предотвращения таких атак является вычисление в качестве ключа S_n=h(S_n(M_i ), где h() – любая хеш-функция.

Необходимо заметить, что вышеупомянутый протокол A-GDH.2 выполняет неявную аутентификацию ключа, причем в довольно слабой форме, поскольку ключ не аутентифицируется непосредственно между каждыми любыми двумя M_i и M_j участниками (ij). Последний участник M_n (будем далее называть его контролирующим группы, поскольку через него проводятся ключевые операции протокола) отвечает за использование аутентичных ключей K_in, i=1 ... n-1, от которых и зависит аутентификация. Следовательно, участник M_n должен быть лицом, которому все доверяют. Это может быть схема с доверенным сервером в качестве M_n. В противном случае M_n сможет разбить группу на две части без обнаружения этого (поскольку он может перехватывать все сообщения и таким образом получить необходимую информацию в виде  ^r₁^…r_i ^{/ r}_j для i,j).

Поэтому необходимо трансформировать протокол, что и было сделано в работе [1].

2.2 Протокол SA-GDH.2

Для описания протокола требуется несколько дополнительных определений.

Опр. 2.2.1. Пусть R – протокол обмена для n участников и M – множество участников. Мы будем говорить, что R является протоколом, обеспечивающим полную(complete) аутентификацию группового ключа, если для каждых i,j (0< ij n) участники M_i и M_j вычислят общий ключ S_i,j, только если S_i,j был получен при участии каждого M_p M.

Другими словами, полная аутентификация группового ключа есть аутентичный обмен для выработки ключа между всеми парами (M_i, M_j) при (0< ij n).

Для выполнения этого определения можно модифицировать протокол A-GDH.2 в следующий:

П ротокол SA-GDH.2. Этап i (0< i <n): Mi получает множество промежуточных величин { Vk | 1 k n}. (в данном контексте можно сказать, что M1 получает пустое множество на первом этапе):  (r1…ri-1 / rk)(K k1…K k(i-1)) при k (i-1) Vk =  (r1…ri-1)(K k1…K k(i-1)) при k > (i-1) . 2. Mi обновляет каждое Vk следующим образом: (Vk ) riK ik =  (r1…ri / rk)(K k1…K ki) при k < i Vk = (Vk ) riK ik =  (r1…ri)(K k1…K ki) при k > i . Vk при k = i (Замечание: на первом этапе M1 выбирает V1 = .) Этап n: Mn рассылает множество всех Vk участникам группы. 2. При получении Mi выбирает свое Vi = (r1…rn / ri)(K1i…K ni). Mi вычисляет (Vk ) ri(K1i-1… K ni-1)= r1…rn . Заметим, что вместо того, чтобы вычислять n обратных элементов, Mi может вычислять 1 обратный элемент Pi-1=(K1i-1… Kni-1), где Pi=(K1i… Kni).

В протоколе SA-GDH.2 требуется, чтобы каждый участник группы имел некоторый общий ключ с любым другим участником (это значение K_ji). Однако, как уже было замечено для каждого такого ключа K_ji не требуется нахождение обратного K_ji^-1. Таким образом, достаточно получить такие ключи перед началом работы в группе и затем эти ключи могут оставаться постоянными, не добавляя лишних действий в протокол.

Протокол основан на кольцевой схеме взаимодействия, т.е. данные проходят по кругу и лишь на последнем этапе идет широковещательная рассылка. Данные, которые передаются, представляют собой множество из n элементов. i-й элемент содержит своеобразное «накопление ключа» для i-го участника. Во время обновления ключа каждый из участников вносит свой вклад в формирование ключа. Только пройдя полный круг, i-й элемент множества будет иметь вклады всех участников и их секретные ключи для связи с i-м абонентом (рис. 1). Это позволяет избежать явной замены противником одного из значений на какое-то другое, выгодное ему (возможное вмешательство противника рассмотрим далее)

Однако SA-GDH.2 имеет более высокую «вычислительную стоимость» по сравнению с A-GDH.2. Прежде всего, он требует (n-1) экспоненцирование для каждого M_i (кроме первого), в отличие от i экспоненцирований в A-GDH.2. К этому еще добавляется работа по формированию общих ключей для каждой пары абонентов (если они не вычислены заранее): на последнем этапе проводится одно экспоненцирование – как и в A-GDH.2. На рис. 1 приведены примеры протоколов A-GDH.2 и SA-GDH.2.

Как показано в [1], протокол SA-GDH.2 обеспечивает полную аутентификацию группового ключа.

Теорема 2.2.1 Протокол SA-DH обеспечивает полную аутентификацию группового ключа.

Док-во: предположим, M_i и M_j вычислили одинаковый ключ в результате выполнения протокола. Пусть K_n=S_n(M_i)=S_n(M_j), и предположим, что некто M_p M (pi,j) не сделал вклада в этот ключ. Пусть V_i и V_j обозначают величины, полученные M_i и M_j на последнем этапе протокола. Напомним, что в соответствии с протоколом

S_n(M_i)=(V_i)^(K_1i^-1…K_ni^-1)r_i и S_n(M_j)=(V_j)^(K_1j^-1…K_nj^-1)r_j .

Поскольку все участники группы сделали вклад в ключ, то можно записать, что

V_i= ^(r₁^…r_n^/r_p^r_i^)(K_1i^-1…K_ni^-1/K_pi^-1) (для V_j аналогично), и

S_n(M_i)=  ^(r₁^…r_n^/r_p^)K_pi^-1, что должно равняться S_n(M_j)=  ^(r₁^…r_n^/r_p^)K_pj^-1.

Но поскольку K_pi^-1 и K_pj^-1 являются секретными, то получаем противоречие. #

В работе [1] также отмечается, что обсуждаемый протокол обладает устойчивостью к атакам по известному ключу (known key attacks), однако строгого формального доказательства не приведено, авторы лишь отмечают, что это легко пронаблюдать на приведенной выше атаке на A-GDH.2.

2.3 Особенности ключей протоколов A-GDH.2 и SA-GDH.2

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

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

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

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

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

 ^F(S_n^(M_n⁾⁾

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

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

 ^F(S_n^(M_i⁾⁾ =? ^F(S_n^(M_n⁾⁾ .

В [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₃ получит следующие значения: ^2r₁^K₁₂, ^2r₁^r₂^K₁₃^K₂₃, ^2r₂^K₂₁.

В результате M₃ вычислит S₃(3)= ^2r₁^r₂ ^r₃, т.е. квадрат предполагавшегося ключа. Все остальные участники группы получат то же самое. Подтверждение ключа здесь не помогает, поскольку злоумышленник вторгается в протокол перед тем, как 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
Всего экспоненцирований	(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) , позволяющий работать приложениям в неких абстрактных группах. Протокол во многом основывается на вышеописанных протоколах аутентичного обмена. Ограничимся рассмотрением только математических принципов проекта. Не будем рассматривать полученные результаты (по эффективности), программные реализации.

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

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

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

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

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

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

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

• разделение групп: группа распадается на две или более частей.

3. Операции по обновлению ключа обусловлены двумя причинами:

• ограничением шифртекста, получаемого на одном ключе для ограничения возможности получения пар открытый текст/шифртекст для проведения криптоанализа (время жизни ключа определяется выбранной политикой);

• предохранением от компрометации текущего ключа или вклада каждого участника.

Итак, список операций, выполняемых протоколом, выглядит следующим образом:

• присоединение (JOIN): новый участник добавляется в группу;

• слияние (MERGE): один или более участников добавляются в группу;

• выход из группы (LEAVE): один или более участников покидают группу;

• обновление ключа (KEY REFRESH): генерация нового ключа для группы.

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

Присоединение

Операция добавляет нового участника M_n+1 к группе из n участников. Во время операции вычисляется новый групповой ключ S_n+1 , и M_n+1 становится новым контролирующим группы. Предполагая, что M_n является текущим контролирующим группы, протокол выглядит следующим образом:

1. M_n вырабатывает новое значение r_n^’ и получает множество² чисел

M={g ^r1…r_n^’/r_i | i[1,n-1]} { g ^r1…r_n-1 }{ g ^r1…r_n^’ }

Затем M посылается M_n+1.

1. После получения сообщения M_n+1 вырабатывает число r_n+1 и вычисляет значение g ^K_i,n+1^r₁^…r_n^’r_n+1^/r_i для всех i из [1,n]. Затем это множество рассылается всей группе.

2. При получении каждый M_i вычисляет групповой ключ как

(g ^K_i,n+1^r₁^…r_n^’r_n+1^/r_i)^K-1_i,n+1^r_i= g ^r₁^…r_n^’r_n+1= S_n+1. А M_n+1 вычисляет ключ, используя сообщение из шага (1).

Шаги (1) и (2) требуют n экспоненцирований, шаг (3) требует одно экспоненцирование для каждого участника группы. Общее число экспоненцирований для получения ключа равно 2n+1 (считается, что на третьем шаге экспоненцирования происходят одновременно и по времени равны одному).

Слияние

Операция используется для добавления k>0 участников к существующей группе из n>1 участников. Пусть m=n+k. Во время операции вырабатывается новый групповой ключ S_m, и M_m становится новым контролирующим группы. Предполагая, что M_n является текущим контролирующим группы, протокол выглядит следующим образом:

1. M_n вырабатывает новое значение r_n^’ и вычисляет³ g ^r₁^…r_n-1^r_n^’. Затем это сообщение отправляется к M_n+1.

2. Каждый участник M_j , j=n+1,…,m-1 вырабатывает число r_j и вычисляет g^r₁^…_.^r_n^’…r_j . Это сообщение посылается M_j+1.

3. После получения сообщения, M_m рассылает полученное значение всей группе

4. После получения сообщения каждый участник M_i, i=1,2,…,m-1 группы вычисляет g^(r₁^…_.^r_n^’…r_m-1^)/r_i и посылает его M_m.

5. M_m вырабатывает r_m и получает множество

M={ g ^K_i,m ^r₁^…r_n^{’ … r}_m^/r_i | i[1,m-1]}.

Затем оно посылается группе.

1. При получении сообщения шага (5) каждый M_i , i=1,2…m-1 вычисляет групповой ключ как (g^r₁^…r_n^’…r_m^K_im ^{/ r}_i)^K_im^-1r_i= g ^r₁^…r_n^’…r_m= S_m. Аналогично, M_m вычисляет ключ, используя сообщение из шага (3).

Если k=2, то шаг (2) не нужен, в остальном протокол выглядит также.

Шаги требуют всего k модульных экспоненцирований. Также, как и ранее, шаги (4) и (6) требуют по одному для каждого участника. Шаг (5) требует n+k-1 экспоненцирований. Число экспоненцирований для присоединения k участников равно n+2k+1.

Операция присоединения также может быть использована для добавления k участников к группе. Это потребует повторить операцию присоединения k раз – соответственно возрастает трудоемкость операции. Таким образом для массового добавления участников группы лучше использовать операцию слияния. Если использовать операцию слияния для добавления одного участника к группе, то получается на два экспоненцирования больше, чем для операции присоединения. Итак, присоединение используется для добавления одного участника к группе, а слияние – нескольких.

Выход из группы

Операция выхода из группы удаляет k участников из n участников текущей группы. Во время операции вычисляется новый групповой ключ S_n-k. M_n-k становится новым контролирующим группы, если M_n покидает группу. Для простоты предположим, что только один участник M_d выходит из состава группы. Протокол выглядит следующим образом:

1. M_n вырабатывает новое r_n^’ и получает множество

M={ g ^K_in ^r₁^…r_n^{’/ r}_i | i[1,n-1] и id}

Затем М рассылается всем.

1. При получении сообщения M_i вычисляет

(g ^K_in^r₁^…r_n^’/r_i)^K_in^-1r_i= g ^r₁^…r_n^’= S_n. M_n вычисляет новый групповой ключ g^r₁^…r_n^’=S_n используя старое значение.

Участник M_d не может вычислить новый групповой ключ, т.к. контролирующий группы не вычислил вспомогательный ключ g^K_dn^r₁^…r_n^’/r_d для M_d. Если несколько участников покидают группу, то контролирующий группы не вычисляет нужные значения для выходящих из группы участников на шаге (1).

Если из группы выходит контролирующий, то вышеописанные операции выполняет предпоследний участник группы M_n-1. Более того, поскольку новый контролирующий группы не может удалить из ключа долговременные ключи (они были у прошлого контролирующего группы), каждый участник M_i должен заново вычислить свой случайный сеансовый ключ как r_i= r_i(K_in^-1 mod q) перед выполнением шага (2).

Шаг (1) требует n-k экспоненцирований. Шаг (2) требует одно экспоненцирование от каждого участника группы. Таким образом, операция выхода из группы требует n-k+1 модульных экспоненцирований.

Обновление ключа

Операция обновления ключа выполняет замену группового ключа на новый. Использование этой операции зависит от используемой политики приложения, использующего CLIQUES или политики работы с ключами для предприятия. Эта операция выглядит также, как и операция выхода из группы с k=0, т.е. на первом шаге M_n вырабатывает множество

M={ g ^K_in ^r₁^…r_n^{’/ r}_i | i[1,n-1]}

для всех участников группы.

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

Таким образом, с использованием приведенных выше операций достигается полноценная работы группы. На основе приведенного протокола был разработан интерфейс прикладного программирования (Application Programming Interface - API). В работах [3,5] приводятся форматы заголовков сообщений и принципы построения приложений на основе CLIQUES-API. Он принят как проект стандарта для Internet. Программные реализации математических принципов, используемых в протоколах, можно найти в крипто-библиотеках Crypto++[6] и RSAREF[7].

Между тем, приведенная схема работы не лишена недостатков. Во-первых – и это, наверное, самый главный из них – приходится менять ключ для всей группы при изменении ее состояния. Это может подходить для небольших групп, но при большом числе участников становится серьезной трудностью. В этом случае все будет зависеть от динамики группы. На решение этой задачи были направлены усилия разработчиков. Также решающую роль играет пропускная способность каналов связи между участниками, поскольку в случае появления участника со слабым каналом (тем более, если это контролирующий группы) встает вопрос о временных факторах формирования ключа. Возможна ситуация непроизвольного «выкидывания» (в случае отсутствия необходимых механизмов) участника, использующего канал с низкой пропускной способностью в случае высокой динамики группы. Он просто не будет успевать получать новые данные для формирования ключа.

Во-вторых – довольно высокое число экспоненцирований в операциях протокола.

Заключение

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

Вкратце опишем, что не вошло в данную работу.

1. Цифровые подписи – данный раздел довольно велик по своему объему.

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

1. Взаимодействие протоколов с сетевыми технологиями. Ввиду сугубо практических аспектов данные материалы не учитывались

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

Используемые работы:

[1] G. Ateniese, M. Steiner, G. Tsudik “Authenticated Group Key Agreement and Friends”, in ACM Symposium on Computer and Communication Security, November 1998.

[2] M. Steiner, G. Tsudik, M. Waidner “Diffie-Hellman key distribution extended to groups”, in ACM Conference on Computer and Communications Security, pp.31-37, ACM Press, Mar. 1996.

[3] G. Ateniese, D. Hasse, O. Chevassut, Y. Kim, G. Tsudik “The Design of a Group Key Agreement API”, IBM Research Division, Zurich Research Laboratiry.