CC BY
68
УДК 004.056.55
П.Н. Васильев, А.В. Артамонов, Е.Б. Маховенко
КЛАССИФИКАЦИОННАЯ СХЕМА ГРУППОВЫХ ПОДПИСЕЙ ДЛЯ ПОСТРОЕНИЯ РАСПРЕДЕЛЕННЫХ ПРИЛОЖЕНИЙ
Групповые подписи - относительно новая концепция, представленная впервые в работе [1], - могут быть использованы для скрытия организационных структур некоторой организации, т. к. обеспечивают анонимность подписывающих. Любой член группы может подписать сообщение, но подпись не позволяет узнать личность подписавшего. Обычно в схемах групповой подписи также присутствует третья сторона, которая может узнать личность подписавшего сообщение, воспользовавшись специальной лазейкой.
Благодаря своим свойствам схемы групповой подписи являются очень важным криптографическим средством, применимым во множестве специализированных областей и приложений. К примеру, групповые подписи могут быть использованы какой-либо организацией для удостоверения прайс-листов, пресс-релизов или при представлении тендера на рассмотрение; для проведения удаленной проверки программного обеспечения компьютера с сохранением конфиденциальности стороны [2], что может найти применение в таких сферах, как хоум-банкинг или онлайн-игры. Широко известный проект, в рамках которого используются групповые подписи, -организация безопасного движения транспортных средств, - совместный проект большинства
крупнейших производителей автомобилей и Министерства транспорта США [3].
Схема групповой подписи оперирует следующими сущностями (рис. 1): А - менеджер группы ОМ, который создает группу, добавляет в нее новых членов или лишает членства в группе, выпуская или отзывая сертификаты. Также он может раскрыть любую групповую подпись, тем самым отменив ее свойство анонимности. Иногда функции формирования группы и раскрытия подписи разделяются между двумя субъектами: менеджером группы ОМ и раскрывающим менеджером ОМ; Б - члены группы; В - внешние по отношению к группе субъекты, имеющие доступ к ее открытому ключу.
Обычно схема групповой подписи подразумевает выполнение следующих процедур:
1) формирование группы - генерация основных ключей: открытого ключа (ОК) группы и секретного ключа менеджера группы. Секретные ключи членов группы становятся известны им в результате выполнения менеджером действий определенного протокола с каждым из них;
2) подписывание сообщения одним из членов группы;
3) проверка подписи на основании сообщения и ОК группы;
Секретные ключи членов группы
Секретный ключ менеджера группы
Открытый ключ группы
Рис. 1. Обобщенная схема групповой подписи
4) идентификация раскрывающим менеджером члена группы, подписавшего данное сообщение. Раскрытие подписи производится только в случае возникновения споров.
Групповые подписи являются обобщением механизма удостоверения личности (credential mechanism) и схем аутентификации, в которых член группы может доказать проверяющему, что он принадлежит к определенной группе, не раскрывая свой идентификатор.
Чаум и ван Хейст впервые предложили решения, связанные с групповой подписью, а именно четыре различные схемы [1]. С момента первой публикации, посвященной протоколам групповой подписи, было разработано еще несколько схем. Одни были впоследствии «взломаны», другие оказались непрактичными из-за длинных открытых ключей и/или длинных подписей, в то время как третьи предложили недоказанную безопасность [4]. Но это относится, скорее, к схемам, появившимся в течение 1990-х гг. Первой доказуемо безопасной и устойчивой к сговору является схема ACJT [5]. В 2004 г. была представлена BBS - очень эффективная схема короткой групповой подписи, использующая билинейные отображения [3].
Общая тенденция, прослеживаемая по мере создания новых схем, - сокращение вычислительной стоимости и размера итоговой подписи. В частности, BBS - одна из наиболее эффективных по этим показателям. В данной статье предложена классификационная схема групповых подписей, разработана эффективная реализация схемы BBS на основе библиотеки MIRACL, а также представлено распределенное приложение, демонстрирующее возможности этой схемы.
Классификация схем групповой подписи
Чтобы иметь возможность сравнивать схемы групповой подписи, выделим признаки, по которым их можно классифицировать:
1) криптографические предположения, лежащие в основе безопасности:
предположение о сложности разложения на множители (2-я и 3-я схемы Чаума и ван Хейста);
предположение о сложности дискретного логарифмирования (4-я схема Чаума и ван Хейста); предположение Strong-RSA (схема ACJT); предположение о задаче распознавания Диффи-Хеллмана - DDH (схема ACJT);
сильное предположение Диффи-Хеллмана -
Strong-DH (схема BBS);
предположение о линейной задаче распознавания Диффи-Хеллмана - DL (схема BBS); безусловно безопасная схема;
2) роль, необходимость и возможность распределять обязанности доверенной стороны в схеме;
3) возможность динамического членства в группе;
4) тип подписи (есть ли аналог среди традиционных электронно-цифровых подписей (ЭЦП), что включается в подпись и т. п.):
классическая ЭЦП (1-я схема Чаума и ван Хейста);
неопровержимая ЭЦП - подразумевает интерактивный процесс проверки подписи и наличие протокола отказа от нее (2-4 схемы Чаума и ван Хейста);
специфическая ЭЦП - в схемах ACJT и BBS подпись включает в себя зашифрованную на открытом ключе OM группы часть сертификата пользователя, а также элементы, доказывающие знание пользователем этого сертификата, что определяет его принадлежность к группе;
5) свойства, обеспечиваемые схемой, - уровень ее безопасности:
корректность: подпись, созданная честным членом группы, принимается проверяющим, алгоритм раскрытия правильно идентифицирует подписавшего;
невозможность фальсификации: только члены группы могут подписывать сообщения от лица группы;
анонимность: идентификация члена группы, создавшего подпись, является вычислительно сложной задачей для всех, кроме OM группы;
отслеживаемость: невозможно выпустить корректную подпись, по которой честный OM не смог бы идентифицировать подписывающего;
устойчивость к сговору: даже при участии в сговоре GM и OM невозможно создать подпись, которая была бы неотслеживаемой или указывала бы на пользователя, не участвующего в сговоре;
несопоставимость: для данных двух групповых подписей невозможно определить, были ли они сформированы одним и тем же пользователем;
невозможность обвинения: ни GM, ни OM не могут создать подпись от имени других существующих членов группы;
6) эффективность: размер открытого доверенного хранилища, содержащего ОК группы,
длина результирующей подписи, количество операций, необходимых при формировании и проверке подписи;
7) механизмы, лежащие в основе схемы (например, билинейные отображения).
Такой набор признаков оказывается вполне достаточным для выбора схемы групповой подписи при решении практических задач. При этом он является общим для того чтобы производить сравнение различающихся схем.
Построить какую-либо четкую классификацию всех групповых подписей не представляется возможным из-за многогранности даже обозначенных выше простейших схем. Следует создать классификационную схему, на основании которой можно будет проводить классификацию каж-
дой конкретной групповой подписи (рис. 2).
Схема короткой групповой подписи BBS
В качестве примера использования данной классификационной схемы рассмотрим ее применение к схеме групповой подписи BBS.
Для описания схемы групповой подписи BBS будем использовать следующие обозначения: G -мультипликативная циклическая группа простого порядка p; G2 - мультипликативная группа, порядок которой - некоторая степень числа p; у - гомоморфизм из G2 в Gp g2 & G2 - элемент порядка p; ^gj) = Gj - образующая группы Gj, такая что
У( g2) = gj.
Выбором элемента g2 обычно ограничивают рассмотрение группы G2 до ее циклической под-
Криптографические предложения
Разложение на множители
Дискретное логарифмирование
Strong-RSA
DDH
Strong-DH
PL_
Безусловно безопасная схема
Свойства схемы
Корректность
Невозможность фальсификации
Анонимность
Отслеживаемость
Устойчивость к сговору
Несопоставимость
Невозможность обвинения
Доверенная сторона
СМ—только для инициализации
СМ- для инициализации и раскрытия
Может/не может подписывать от имени члена
Не является необходимой
Возможно разделить обязанности СМ и ОМ
Эффективность схемы
Динамическое членство в группе
Группа фиксируется при создании
Возможно увеличение количества членов
Возможно эффективное исключение из членов группы
Неактуально для схемы - группа формируется динамически
Механизмы
Все или часть параметров линейно зависят от количества членов
«Традиционная» криптография
Параметры не зависят от размера группы
Количество
вычислительных
операций
Криптография на билинейных отображениях
Тип подписи
Классическая ЭЦП
Неопровержимая ЭЦП
Специфическая: включает зашифрованный сертификат и доказательство его знания
Безопасность
Доказуемо безопасная схема
Предположительно безопасная схема
Рис. 2. Классификационная схема групповых подписей
группы (g 2 ^ порядка p. При этом имеет место изоморфизм ^g = Gj.
Инициализация схемы производится менеджером группы GM. В базовом варианте он лично генерирует все используемые в схеме ключи и раздает менеджеру OM и пользователям их секретные ключи.
Алгоритм генерации ключей BBS
Вход: n - число членов группы.
Выход: gpk - открытый ключ группы, gmsk -секретный ключ менеджера группы, gsk., где 1 < i < n - секретные ключи членов группы.
1. Случайным образом выбрать образующую g е G и вычислить g ^ g ).
22 R J- 1 -J 2 R
2. Выбрать h^Gj\{1G }, ^ Z* и вычислить u, ve G,, такие что u^ = v^ = h.
1R
3. Выбрать у ^ Z* и вычислить w ^ g 2.
4. Используя у, сгенерировать для каждого пользователя - члена группы - пару (A, x) : вы-
R
брать x. ^Z* и вычислить A. ^ g^+x e G1.
5. Результат: gpk ^ (g1, g2, h, u, v, w); gmsk ^ ^2); gsk. ^ (A., x.), где 1 < i < n.
Ни одной из сторон не разрешается знать значение y. Оно может быть известно только центру, выпускающему секретные ключи, т. е. GM.
Идея групповой подписи BBS состоит в доказательстве знания пары (A, x), такой что (Ax+Yj = G1.
Чтобы предоставить другому менеджеру OM возможность раскрывать подпись (идентифицировать подписавшего), доказательство только отчасти должно быть с нулевым разглашением: OM должен уметь восстанавливать значение A.
Поэтому чтобы подписать сообщение m, член группы сначала шифрует A на открытом ключе зашифрования менеджера OM - (u, v, h), а затем предоставляет доказательство с нулевым разглашением того, что открытый текст на самом деле содержит A , для которого он знает соответствующее значение x. Для зашифрования используется алгоритм линейного шифрования, при этом пара значений (£ у, которой обладает OM, является секретным ключом расшифрования, что дает ему возможность раскрывать групповую подпись. Полное описание схемы групповой подписи BBS приведено в работе [3].
Применим предложенную классификационную схему к схеме групповой подписи BBS.
1. Схема групповой подписи BBS основана на сильном предположении Диффи-Хеллмана
(Strong-DH) и на предположении о линейной задаче распознавания Диффи-Хеллмана (DL).
2. Схема BBS, единственная из рассматриваемых, позволяет распределить обязанности руководства группой между GM и раскрывающим менеджером OM. В обязанности GM входит создание группы, формирование всех необходимых ключей и их безопасная доставка до членов группы и OM. В обязанности OM входит раскрытие подписей в случае необходимости разрешения конфликтных ситуаций. В базовой схеме BBS предполагается, что GM самостоятельно генерирует все ключи, используемые в схеме. То есть существует сторона, которая знает секретные ключи всех пользователей и может формировать подпись от чужого имени. Однако схема BBS может быть расширена, чтобы предоставить пользователю возможность самому влиять на свой секретный ключ, делая его неизвестным для GM.
3. BBS поддерживает как динамическое вступление в группу, так и возможность эффективного отзыва членства в группе.
4. Групповая подпись BBS основана на доказательстве (с нулевым разглашением) знания решения задачи Strong-DH, т. е. знания пары (A, x). Подпись также включает в себя зашифрованную часть сертификата пользователя на открытом ключе OM группы (безопасность линейного шифрования основана на задаче DL).
5. BBS, расширенная путем включения в нее протокола совместного формирования секретных ключей членов, удовлетворяет всем семи требованиям, предъявляемым к групповой подписи.
6. В схеме BBS длина открытого ключа не зависит от количества членов группы. Для нее не актуальна передача каких-либо значений при проверке корректности подписи. При формировании подписи выполняется восемь операций возведения в степень, при проверке подписи - шесть возведений в степень и одно вычисление билинейного отображения.
Групповая подпись BBS включает в себя три элемента группы G1 и шесть элементов кольца Zp. При использовании суперсингулярных эллиптических кривых в качестве p можно взять 170-битное простое число и использовать группу G1, в которой каждый элемент задается 171 битом. Поэтому длина всей групповой подписи будет составлять 1533 бита или 192 байта. С такими параметрами стойкость подписи будет приблизитель-
но такой же, как и у стандартной подписи RSA длиной 1024 бита или 128 байтов.
Для сравнения: длина подписи ACJT, сравнимая по стойкости с 1024-битной подписью RSA, составляет 8696 бит без учета открытых ключей и параметров схемы [6].
7. Схема BBS использует билинейные отображения (спаривания).
8. Безопасность схемы BBS доказана в рамках модели со случайным оракулом. Случайный оракул (random oracle) - теоретический «черный ящик», который отвечает на каждый запрос истинно случайным ответом, выбранным из некоторого множества выходных значений, за исключением некоторых специфических запросов, на которые он отвечает одинаково каждый раз, как получает такой запрос.
Таким образом, схема групповой подписи BBS, предложенная в 2004 г., с некоторыми усовершенствованиями, позже внесенными в нее, до сих пор является одной из лучших схем групповой подписи по совокупности свойств, которыми она обладает. Поэтому в данной работе основное внимание уделяется ее рассмотрению.
С помощью приведенного выше механизма классификации можно лаконично и ёмко охарактеризовать предположительно любую схему групповой подписи, сравнить ее объективные параметры с параметрами других схем и выбрать лучшую для решения некоторой задачи. Приведенная классификационная схема не претендует на полноту - она составлена на основании шести рассмотренных типовых схем групповой подписи. Возможно, в ряде случаев ее придется некоторым образом дополнить, чтобы новая для нее схема групповой подписи адекватно в нее вписалась. Недостатком классификационной схемы является то, что она не отражает субъективную сложность понимания классифицируемой схемы подписи, что означает, что на ее основе невозможно предсказать время разработки программного продукта, реализующего заданную схему.
Реализация схемы групповой подписи BBS
На базе библиотеки NuimCrypto [7], разработанной Национальным Университетом Ирландии, а также библиотеки MIRACL [8] авторами были созданы различные реализации схемы BBS. Сравнение этих подходов между собой, а также с существующей реализацией схемы на основе библиотеки PBC - Pairing-Based Cryptography
Library [9] - показало, что реализация схемы групповой подписи BBS на основе библиотеки MIRACL является наиболее эффективной. Библиотека NuimCrypto, как и реализация схемы BBS на ее основе, - менее эффективны, но зато полностью написаны на языке Java, что обеспечивает их переносимость. Результаты тестирования временных параметров библиотек представлены в таблице.
При работе с библиотекой PBC использовались стандартные параметры классов A (нацелены на эффективность вычислений) и F (нацелены на короткую подпись) [10]. При работе с библиотеками NuimCrypto и MIRACL использовались рекомендуемые параметры: размер характеристики простого поля 512 бит, размер порядка группы точек эллиптической кривой 160 бит и 170 / 160 бит.
В таблице также приведены размеры подписи, получающиеся при использовании определенной библиотеки и размеров параметров. В ходе исследования не ставилась задачи минимизировать эти показатели.
Таким образом, переносимая реализация на Java оказалась неконкурентоспособной по сравнению с двумя другими библиотеками. Это объясняется слабой приспособленностью Java для выполнения такого рода задач, а также реализацией «в лоб» низкоуровневых алгоритмов, на базе которых уже строилась схема групповой подписи BBS.
Библиотека PBC - многоплатформенная, наиболее всеобъемлющая и проработанная из всех существующих библиотек, позволяющая реализовать криптосистему на спариваниях, имея для этого минимальные знания. Однако из-за своей достаточно узкой направленности и абстрактности интерфейса, предоставляемого разработчику, она не позволяет, не вдаваясь в детали реализации, повлиять на используемые параметры системы. По скорости PBC проигрывает библиотеке MIRACL.
Наиболее эффективная реализация - на основе библиотеки MIRACL во многом благодаря очень хорошей оптимизации низкоуровневых примитивов и ее универсальности. Поэтому разработанная библиотека групповой подписи BBS на основе MIRACL была выбрана в качестве основной. Она предоставляет высокоуровневое API для языков Си и Java, что обеспечивает удобство ее применения для создания как распределенных, так и обычных приложений, использующих возможности групповой подписи.
Сравнение реализаций схемы групповой подписи BBS
Библиотека РВС NuimCrypto MIRACL
Язык с Java C/C++
Платформы Unix-like Ограниченно: Windows(x86) WinCE(ARM) Linux (ARM) Java SE Java EE Windows Linux x86
Время генерации параметров системы, мс 512/160 - 6093 766
170/160 - 657 31
Время генерации ключей, мс А/512/160 453 87125 546
F/170/160 1837 13297 157
Время формирования подписи, мс А/512/160 270 8750 265
F/170/160 627 1938 78
Время проверки подписи, мс А/512/160 198 18656 250
F/170/160 477 3547 78
Время раскрытия подписи, мс А/512/160 296 20485 297
F/170/160 1571 3906 79
Размер подписи, байт А/512/160 504 509 320
F/170/160 240 254 192
Далее были рассмотрены возможные варианты архитектур распределенных приложений, построенных на базе технологии J2EE, использующих возможности разработанной библиотеки схемы групповой подписи BBS:
1. Взаимодействие по протоколу HTTP. В роли клиентов выступает Web Browser. Недостатком этого подхода является необходимость передачи по сети программного кода JavaScript и апплетов, входящих в HTML-страницу для обеспечения функциональности приложения.
2. Взаимодействие по протоколу HTTP. Клиентом является специализированное приложение Java. При сетевом взаимодействии программный код не передается. Недостатком является необходимость разработки собственного HTTP-клиента.
3. Взаимодействие по протоколу RMI. Клиентом является специализированное приложение Java. Этот подход устраняет необходимость разработки HTTP-клиента. Недостатком является обеспечение возможности удаленного доступа к EJB-контейнеру для клиентской части приложения.
4. Использование технологии Java Web Start для запуска клиентского приложения. Взаимодействие осуществляется по протоколам JNLP и RMI. В данном подходе браузер не является принципиально необходимым звеном для работы приложения. Исполняемый код за время сеанса работы с приложением загружается с сервера при необходимости и не более одного раза, при этом он защищен от постороннего вмешательства цифровой подписью.
Среди всех подходов выделим архитектуру 4, т. к. только она обеспечивает наибольшее удобство конечных пользователей таких систем, наименьшее время разработки, а также соответствует требованиям безопасности, предъявляемым к приложениям, в которых используется групповая подпись. Данную архитектуру можно применить для построения широкого класса распределенных приложений, реализующих такие функции безопасности как аутентификация пользователей, разграничение доступа к функциям приложения, обеспечение целостности передаваемых по сети данных и исполняемого кода, а также ведение журналов аудита.
В соответствии с выбранной архитектурой было разработано демонстрационное приложение, использующее ранее реализованную схему групповой подписи на основе библиотеки MIRACL. Оно моделирует отдельный компонент информационной системы, применяемой предприятиями, осуществляющими техническую поддержку выпускаемой ими продукции. Данный компонент предоставляет средство взаимодействия агентов с конечными пользователями, в котором каждое сообщение, передаваемое от агента клиенту, подписывается посредством групповой подписи. Группой в данном случае является группа агентов -сотрудников обозначенного предприятия.
Использование языка Java и технологии J2EE
позволяет несколько упростить реализацию защищенного распределенного приложения, решающего задачу, специфика которой влечет использование групповой подписи, за счет применения встроенных и проверенных механизмов обеспечения безопасности.
Предложенные в настоящей статье теоретические и практические результаты, могут эффективно применяться при разработке защищенного распределенного приложения, специфика которого предполагает использование групповой подписи как на этапе анализа требований, поиска и исследования существующих механизмов, так и на этапе реализации.
СПИСОК ЛИТЕРАТУРЫ
1. Chaum, D. Group signatures [Текст] / D. Chaum, E. van Heyst // Proc. of Eurocrypt 1991. -Springer-Verlag, Apr. 1991. -P. 257-265.
2. Организация Trusted Computing Group [Электронный ресурс] www.trustedcomputinggroup.org
3. Shacham, H. Collected Papers where Every Theorem Is Filled with Grief. Dec. 2005 [Электронный ресурс]/Н. Shacham//http:// cseweb.ucsd.edu/~hovav/dist/ thesis-hyperref.pdf
4. Ateniese, G. Quasi-Efficient Revocation of Group Signatures [Электронный ресурс] / G. Ateniese, D. Song, G. Tsudik // http: www.cs.jhu.edu/~ateniese/papers/fc02.pdf
5. Ateniese, G. A Practical and Provably Secure Coalition-Resistant Group Signature Scheme [Электронный ресурс] / G. Ateniese, J. Camenisch, M. Joye [et al.] // Advances in Cryptology-CRYPTO 2000. -Springer Verlag, 2000. -LNCS. -Vol. 1880. -P. 255-270.
http://www.zurich.ibm.com/~jca/papers/ group2000.pdf
6. Yao, D. Cascaded Authorization with Anonymous-Signer Aggregate Signatures [Электронный ресурс] /D. Yao, R. Tamassia//Proc. of the 7 Annual IEEE Systems, Man and Cybernetics Information Assurance Workshop (IAW '06). - United States Military Academy, West Point, NY. - June 2006. http://www.cs.brown.edu/cgc/stms/ papers /anonymity.pdf
7. Библиотека NuimCrypto [Электронный ресурс] http://www.google.com.my/codesearch/ p?hl=en&sa= N%20&cd=1&ct=rc#vE_ES1OPacI/software/&q=http:// www.crypto.cs.nuim.ie/
8. MIRACL, Multiprecision Integer and Rational Arithmetic C/C++ Library [Электронный ресурс] http:// www. shamus.ie/
9. The Pairing-Based Cryptography Library [Электронный ресурс] http://crypto.stanford.edu/pbc/
УДК 004.052.42
М.Ю. Моисеев
АВТОМАТИЧЕСКОЕ ОБНАРУЖЕНИЕ ДЕФЕКТОВ В МНОГОПОТОЧНЫХ ПРОГРАММАХ МЕТОДАМИ СТАТИЧЕСКОГО АНАЛИЗА
Статический анализ (СА) - группа методов, использующих исходный код программы для определения требуемых свойств [1]. Одной из областей применения СА является обнаружение
программных дефектов - нефункциональных ошибок, внесенных на стадии разработки программной системы. Наиболее распространенными типами программных дефектов в последователь-
