Цифровий підпис в групових середовищах
Розглядаються питання генерації і перевірки цифрових підписів в динамічних рівноправних групових середовищах. Пропонується три можливі схеми побудови інфраструктури цифрового підпису, розглядаються їхні основні переваги та недоліки The paper considers questions on generation and validation of digita...
Збережено в:
| Дата: | 2008 |
|---|---|
| Автор: | |
| Формат: | Стаття |
| Мова: | Українська |
| Опубліковано: |
Інститут програмних систем НАН України
2008
|
| Теми: | |
| Онлайн доступ: | https://nasplib.isofts.kiev.ua/handle/123456789/1463 |
| Теги: |
Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
|
| Назва журналу: | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| Цитувати: | Цифровий підпис в групових середовищах / І.Ю. Іванов // Пробл. програмув. — 2008. — N 2-3. — С. 557-563. — Бібліогр.: 12 назв. — укp. |
Репозитарії
Digital Library of Periodicals of National Academy of Sciences of Ukraine| _version_ | 1860080254121410560 |
|---|---|
| author | Іванов, І.Ю. |
| author_facet | Іванов, І.Ю. |
| citation_txt | Цифровий підпис в групових середовищах / І.Ю. Іванов // Пробл. програмув. — 2008. — N 2-3. — С. 557-563. — Бібліогр.: 12 назв. — укp. |
| collection | DSpace DC |
| description | Розглядаються питання генерації і перевірки цифрових підписів в динамічних рівноправних групових середовищах. Пропонується три можливі схеми побудови інфраструктури цифрового підпису, розглядаються їхні основні переваги та недоліки
The paper considers questions on generation and validation of digital signatures in dynamic peer group environments. Three possible digital signature infrastructure schemas (with pluses and lacks described) are proposed.
|
| first_indexed | 2025-12-07T17:16:16Z |
| format | Article |
| fulltext |
Захист інформації
© І.Ю. Іванов, 2008
ISSN 1727-4907. Проблеми програмування. 2008. № 2-3. Спеціальний випуск 557
УДК: 004.056
ЦИФРОВИЙ ПІДПИС В ГРУПОВИХ СЕРЕДОВИЩАХ
І.Ю. Іванов
Київський національний університет імені Тараса Шевченка,
Київ, проспект Академіка Глушкова, 2, корп. 6.
Тел.: (050) 352 6648, e-mail: innokentiy@gmail.com
Розглядаються питання генерації і перевірки цифрових підписів в динамічних рівноправних групових середовищах. Пропонується
три можливі схеми побудови інфраструктури цифрового підпису, розглядаються їхні основні переваги та недоліки.
The paper considers questions on generation and validation of digital signatures in dynamic peer group environments. Three possible digital
signature infrastructure schemas (with pluses and lacks described) are proposed.
Вступ
Протягом останнього десятиліття проблема побудови захищених групових середовищ дуже активно
досліджується в літературі. Це пов’язано, насамперед, з всебічною комп’ютеризацією всіх сфер діяльності
людини, і, відповідно, надшвидким зростанням кількості обчислювальних мереж. Проте, більшість робіт у
даній галузі присвячено алгоритмам зміни складу групи та узгодження спільного групового ключа. Інші, не
менш важливі, аспекти функціонування захищеного групового середовища, як автентифікація, авторизація,
контроль доступу до ресурсів, та проблема створення довготермінових підписів, у літературі майже не
висвітлені. Тому вкрай важливим є питання окреслення проблем, що пов’язані з ними, дослідження існуючих та
розробка нових криптографічних алгоритмів, що надають можливість ефективно вирішувати дані проблеми.
У представленій роботі розглядаються питання створення та перевірки істинності цифрового підпису в
групових середовищах. Зазначимо, що термін “перевірка істинності” розуміємо в більш широкому сенсі, ніж
криптографічне встановлення коректності цифрового підпису над деякими даними. Окрім безпосереднього
встановлення коректності, “перевірка істинності” включає такі аспекти: легальність впровадження підпису (чи
мав автор право робити підпис документа в певний момент часу), можливість перевірки підписів, які зроблено
у минулому – незалежно від поточних характеристик середовища та статус автора підпису. Тому мова буде не
про підпис у криптографічному сенсі, а про інфраструктуру, що дозволяє ефективно перевіряти його істинність.
Незважаючи на те, що питання побудови такої інфраструктури для двосторонніх середовищ добре вивчено,
воно майже не розглянуто для рівноправних групових середовищ. Водночас, оскільки побудова будь-якого
захищеного середовища вимагає наявності механізму гарантування авторства, основою якого є інфраструктура
цифрових підписів, розробка такої інфраструктури для групових середовищ – досить актуальне питання на
сьогодні.
Означення та термінологія. Під обчислювальним груповим середовищем (або просто обчислювальною
групою) будемо розуміти множину обчислювальних пристроїв M={mi, i=1,...,n}, що володіють спільним
таємним ключем K, визначеним з використанням деякого алгоритму узгодження групового ключа, та можуть
передавати між собою дані з метою розв’язання певної спільної задачі [1]. Пристрої mi називаються членами
групи M, яка називається динамічною, якщо множина M не фіксована в часі, тобто до групи можуть
приєднуватися нові члени та відокремлюватись існуючі. Група є рівноправною, якщо всі її члени мають
однаковий вплив на функціонування групи. Рівноправність – суттєва вимога в багатьох випадках, оскільки вона
дозволяє мінімізувати залежність групи від деякого її члена чи підмножини членів, отже, зробити її більш
стабільною та надійною. Прикладами груп, в яких рівноправність має надвисоке значення, є об’єднання, в яких
рівність статусу принципова характеристика – міждержавні структури, військові блоки, міжбанківські системи.
Слід відмітити, що на сьогодні більшість існуючих групових криптографічних алгоритмів (насамперед,
алгоритмів узгодження спільного ключа) не забезпечують строгої рівноправності, тому задача виглядає скоріше
як максимізація рівноправності членів групи. У подальшому викладенні сконцентруємось на розгляді
динамічних груп, одночасно враховуючи принцип максимізації рівноправності її членів.
Під електронним цифровим підписом [2] (далі – цифровий підпис) будемо розуміти певну сутність, що
призначена для посвідчення автора або відправника повідомлення та захисту повідомлення від підроблення. На
цифровий підпис покладаються такі функції:
• свідчення авторства документа або права власності на нього;
• автентифікація автора;
• захист документа від модифікації;
• неможливість відмовлення від авторства.
Захист інформації
558
Стан проблеми
Стандартом де-факто при проектуванні інфраструктур цифрових підписів є використання криптографічних
алгоритмів з відкритим ключем. Це пояснюється, насамперед, тим, що такі алгоритми забезпечують
гарантований рівень безпеки, оскільки їхня стійкість базується на відомих математичних проблемах.
Прикладами алгоритмів, що лежать в основі багатьох інфраструктур, є алгоритми RSA [3] (в основі його
стійкості лежить проблема розкладання великих чисел на множники), Ель-Гамаля [4] (проблема обчислення
дискретного логарифму) та алгоритми, що базуються на застосуванні еліптичних кривих [5]. З кожною діючою
особою середовища асоціюється пара ключів – відкритий ключ Kpub, що доступний для всіх інших діючих осіб,
та закритий ключ Kpriv, що зберігається особою у таємниці. Підписування даних d полягає в виконанні деякої
функції S(d, Kpriv) з метою отримання підпису s. Перевірка підпису виконується шляхом виконання оберненої
функції V(d, s, Kpub).
В інфраструктурах цифрових підписів також використовуються такі поняття:
• сертифікат – цифрова сутність, що пов’язує відкритий ключ з інформацією про його власника.
Звичайно сертифікат містить такі дані: відкритий ключ, реквізити власника (ім’я, адреса, телефон, IP-адреса),
термін дії. Для запобігання несанкціонованій зміні реквізитів чи значення відкритого ключа, сертифікат
підписується закритими ключами інших діючих осіб (в їх якості може виступати як власник ключа – у такому
випадку сертифікат називається самопідписаним, так й інші особи). Підписи додаються до сертифіката та
розповсюджуються разом з ним;
• довірена третя сторона (ДТС) – діюча особа, якій явно або неявно довіряють учасники середовища;
• статус сертифікату (діючий, відкликаний, скомпроментований, призупинений). Відкликання
сертифіката – оголошення сертифіката недійсним у зв’язку з компрометацією ключа або його власника;
• повний підпис – цифрова сутність, що крім власне цифрового підпису, містить всі дані, які необхідні
для його перевірки. Такими даними є інформація про автора, дата та час створення підпису, інформація про
статус сертифіката. В деяких випадках до повного підпису включається і сам сертифікат автора (на випадок
його можливої відсутності у перевіряючого).
Повна перевірка підпису включає встановлення таких фактів:
• коректність цифрового підпису, тобто факт підписання даних саме закритим ключем автора;
• належність сертифіката автору та його дійсність на момент створення підпису;
• достовірність зазначеного у підписі часу його створення;
• інші умови, специфічні для конкретного середовища (наприклад, можливість застосування сертифіката
для тих цілей, для яких його було використано).
За своєю будовою інфраструктури розрізняються на централізовані та децентралізовані. Перші базуються
на використанні впорядкованої фіксованої множини довірених третіх сторін, що забезпечують можливість
повної перевірки підписів. Децентралізовані інфраструктури не передбачають використання фіксованих ДТС і
базуються на попарних довірчих зв’язках між своїми елементами. Розглянемо основні аспекти будови
централізованих та децентралізованих інфраструктур.
Централізовані інфраструктури передбачають наявність таких сутностей:
• множина авторизованих центрів сертифікації (ЦС). Авторизований центр сертифікації – це орган, що
наділений правом видавати сертифікати (тобто, підписувати сертифікати інших осіб своїм закритим ключем).
Найбільш зручним способом є впорядкування авторизованих центрів у вигляді дерева, у вершині якого
знаходиться кореневий центр сертифікації (представлений своїм сертифікатом), проміжні вершини
відповідають проміжним центрам сертифікації, а листя відображають сертифікати кінцевих користувачів, що
можуть використовуватися для загальних цілей (підписування, шифрування). Сертифікати, що відповідають
вершинам n-го рівня дерева, підписуються закритим ключем вищестоящого центру сертифікації (n-1)-го рівня.
Сертифікат кореневого центру сертифікації підписується його закритим ключем і вважається довіреним за
замовчуванням. Деревовидне впорядкування дозволяє ефективно розподілити задачі видачі сертифікатів між
центрами сертифікації за деякою ознакою (наприклад, за топологією мережі або географічним положенням);
• множина органів, що надають актуальну інформацію про статус конкретного виданого сертифіката
(діючий, відкликаний, призупинений) на деякий момент часу. Ця множина може збігатися з множиною центрів
сертифікації або відрізнятися від неї. У випадку компрометації закритого ключа або власника сертифіката, про
даний факт повідомляється центру сертифікації, що видав сертифікат. Останній уповноважує статус органи
змінити статус сертифіката на відкликаний. Інформація про статус, що видається, підписується закритими
ключами відповідних органів;
• множина органів, що мають право видавати часові мітки. Звичайно термін “видання часової мітки”
означає підписування органом переданих йому даних з додаванням до них значення поточного часу.
Задачу сертифікації вищенаведених органів (а саме, на якій підставі мають видаватися сертифікати тому чи
іншому органу) залишаємо поза викладенням, оскільки вона безпосередньо не стосується теми та лежить
скоріше у юридичній, ніж криптографічній, площині.
В умовах централізованої інфраструктури, створення підпису відбувається наступним чином. Автор
повідомлення підписує його своїм закритим ключем та, у разі необхідності, звертається до відповідного органу
для встановлення часової мітки, після чого передає повідомлення разом з підписами адресату(-ам). Адресат
Захист інформації
559
виконує повну перевірку підпису за наступною схемою. На першому кроці перевіряється коректність значення
підпису, використовуючи відкритий ключ автора. Якщо воно є вірним, перевіряється коректність підпису,
поставленого органом, що видав часову мітку. В разі успішного результату перевірки, виконується процедура
перевірки дійсності всіх використаних у процесі підписання сертифікатів (насамперед, автора та органу, що
встановив часову мітку). Дійсність сертифікатів встановлюється шляхом перевірки всього ланцюжку від
використаного сертифіката до кореневого центру сертифікації. При перевірці ланцюжка перевіряються як
цифрові підписи відповідних сертифікатів, так і їх статус у відповідні моменти часу. Отже, централізована
схема базується на явній довірі кореневому центру сертифікації, оскільки всі інші сертифікати, що
використовуються в середовищі, видаються за безпосередньою або непрямою його участю.
На сьогодні найбільш вживаною на практиці є централізована інфраструктура на базі цифрових
сертифікатів стандарту X.509 [6] та протоколу CMS [7]. Вона включає всі характерні для централізованих
середовищ органи, які забезпечуються протоколами TSP [8] (протокол запиту часових міток), OCSP [9]
(протокол перевірки статусу сертифікату) та CRL [6] (протокол публікації періодично поновлюваних списків
відкликаних сертифікатів).
Централізована схема має такий вигляд (рис. 1).
Автор
d, S(d)
Сервер часу
d, S(d), T(S(d))
Адресат
d, S(d), T(S(d))
V(S(d))
V(T(S(d)))
V(сертифікати)
ЦС
Сервер
статусу
КЦС
ЦС ЦС
Сервер
статусу
Сервер
часу
Кор. 1 Кор. 2
Рис. 1
На схемі використано такі позначення: S – функція цифрового підпису, що використовується автором
підпису; T – функція встановлення часової мітки (звичайно, вона теж базується на цифровому підписі); V –
функція перевірки підпису; ЦС – центр сертифікації; КЦС – кореневий центр сертифікації; Кор. 1 та Кор. 2 –
кінцеві пристрої-користувачі.
Децентралізований підхід, як ми вже говорили, передбачає відсутність будь-яких глобально довірених
органів. Звичайно в системах, що втілюють такий підхід, сертифікат конкретної діючої особи підписується
(завіряється) певною множиною інших осіб (утворюючи, так, середовище попарної довіри). За зберігання та
публікацію сертифікатів відповідають або певна множина серверів ключів, або самі власники сертифікатів. У
децентралізованих інфраструктурах, так само, як і в централізованих, можуть існувати органи, що видають
часові мітки та зберігають інформацію про статус сертифікатів, проте, рівень довіри тому чи іншому органу
відрізняється для кожного з учасників середовища, а тому повна перевірка підпису в таких середовищах є
набагато більш складним питанням, ніж у централізованому випадку. Фактично, питання довіри у
децентралізованих середовищах не може бути строго формалізованим, а тому важко охарактеризувати рівень
безпеки, що забезпечується такими середовищами. Окрім того, вони погано піддаються масштабуванню (так, у
випадку використання централізованої системи адресат, що перевіряє підпис, у випадку відсутності
безпосередньої довіри автору підпису, тим не менш, може зробити висновок щодо довіри йому, перевіривши
коректність підпису та всіх сертифікатів у ланцюжку. У випадку використання децентралізованої системи
перевіряючий має довіряти або безпосередньо автору підпису, або одній з осіб, що довіряють автору підпису).
Незважаючи на досить велику кількість недоліків, децентралізований підхід також досить активно
застосовується на практиці, проте спектр його застосування обмежується невеликими малодинамічними
середовищами, в яких можливість застосування принципу попарної довіри превалює над необхідністю мати
можливість встановлювати рівень довіри для будь-якого учасника середовища. Прикладом такої
інфраструктури є система OpenPGP [10].
Захист інформації
560
Будова децентралізованої схеми показана на рис. 2.
Автор
d, S(d)
Сервер часу
d, S(d), T(S(d))
Адресат
d, S(d), T(S(d))
V(S(d))
V(T(S(d)))
V(сертифікати)
Множина
довірених членів
інфраструктури
Сервер
статусу
Сервер
часу
Кор. 1
Кор. 2
Кор. 3
Сервер
ключів
Сервер
часу
Рис. 2
Обидві схеми мають переваги та недоліки. У централізованому випадку працездатність та безпека всієї
системи залежить від працездатності кореневих центрів сертифікації; компрометація кореневого ЦС може
призвести до серйозних негативних наслідків. Проте, вона забезпечує надійність, простоту та логічність у
використанні. Децентралізований випадок позбавлений таких вузьких місць, але він породжує інші задачі, як
складності, пов’язані з неоднозначною довірою між учасниками такого середовища.
Цифровий підпис в групових середовищах
Групові середовища відрізняються певними особливостями, які мають бути обов’язково враховані при
побудові інфраструктур цифрових підписів, що будуть в них використовуватись:
• груповий характер середовища;
• висока динамічність;
• прагнення забезпечити якомога більшу рівноправність всіх членів середовища.
Груповий характер середовища обумовлює специфіку перевірки підписів. Цілком ймовірно, що підпис,
створений одним з членів групи, буде перевірятися всіма іншими. Це робить застосування децентралізованого
підходу не дуже зручним, оскільки в цьому випадку доведеться встановлювати попарні довірчі відношення між
всіма членами групи, що у випадку великої кількості членів призведе до непотрібних затримок. Висока
динамічність призводить до необхідності створення чіткої стратегії зберігання інформації про статус
сертифікатів у відповідності з різними періодами існування групи в часі. Вимога рівноправності накладає певні
обмеження на ролі, які можуть виконувати члени групи в інфраструктурі підписів.
Можна виділити наступні підходи, що можуть бути використані для побудови інфраструктури цифрових
підписів у групових середовищах (рис. 3). Розглянемо їх детальніше.
Зовнішня централізована інфраструктура. Цей підхід є безпосереднім перенесенням класичного
централізованого підходу, було вище описано, на групові середовища (рис. 3, а). Він базується на використанні
всіма членами групи множини зовнішніх (тобто, тих, що не належать до групи) довірених третіх сторін для
встановлення часових міток та перевірки коректності підписів.
Цей підхід суттєво не відрізняється від звичайного централізованого підходу, тому детально зупинятися на
цьому не будемо. Відмітимо лише, що за всі довірчі операції (видання часових міток, сертифікатів, надання
інформації про статус сертифікату) відповідає множина зовнішніх ДТС. Це ставить групу в залежність від
зовнішнього середовища, що у деяких випадках не є прийнятним.
Зазначимо основні переваги і недоліки цього підходу.
Переваги:
• Збереження рівноправності групи. Дійсно, всі члени групи володіють однаковими можливостями та
виконують ті самі дії для створення та перевірки підписів. За умови довіри зовнішнім ДТС збоку всіх членів
групи, жоден з них не має переваги перед іншими.
• Централізований спосіб зберігання ключів і інформації про статус. Будь-яка інформація (поточна,
минула) в будь-який момент може бути отримана від відповідної ДТС.
• Мінімальне навантаження на мережу.
• Можливість використання однієї множини ДТС декількома групами.
Захист інформації
561
Недоліки:
• Залежність групи від зовнішнього середовища (технічно та політично). У багатьох випадках наявність
такої залежності є критичним фактором.
• Зовнішня централізована інфраструктура є вузьким місцем системи. У випадку виходу її з ладу, група
втрачає можливість функціонування.
• Необхідність попереднього узгодження множини ДТС, що буде використовуватись групою.
Внутрішня централізована інфраструктура. Підхід на базі внутрішньої централізованої інфраструктури
(рис. 3, б) базується на адаптації класичного централізованого підходу до використання в групових
середовищах. У даному випадку органи, що здійснюють видачу сертифікатів, генерацію часових міток та
видачу статусної інформації, обираються з множини поточних членів групи. Принцип, за яким на певні посади
обираються ті чи інші члени групи, може бути довільним. Єдиною вимогою до нього є детермінованість, тобто
кожний член групи у разі необхідності повинен мати можливість однозначно визначити, які саме члени групи
відповідають за ті чи інші послуги.
У порівнянні з попереднім підходом, даний підхід позбавлений залежності від зовнішнього середовища, а
отже, може бути застосований у будь-яких середовищах. Проте, факт покладення на певних членів групи
додаткових обов’язків порушує один з основних принципів – рівноправності членів групи. Але, незважаючи на
це, за певних умов він може бути застосований.
Розглянемо особливості використання цього підходу. При будь-якій зміні складу групи в першу чергу
вирішується задача “розподілу повноважень”. Як ми вже говорили, можна дотримуватись будь-якого
детермінованого принципу розподілу, проте бажаним, на наш погляд, є використання деякої односторонньої
функції (для запобігання зловживань збоку окремих членів групи). Після розподілу повноважень визначені
сертифікаційні центри здійснюють побудову дерева сертифікатів для всіх членів групи.
Слід відмітити, що для забезпечення можливості перевірки “старих” підписів (тих, що були зроблені за
часів існування попередніх складів групи), кожен член групи має зберігати в себе всі попередні дерева
сертифікатів разом з інформацією про їх статус. Це робить даний підхід неефективним у високодинамічних
групах, оскільки призводить до надлишкового використання ресурсів кожним членом групи. Окрім того, постає
питання надання попередніх дерев сертифікатів новим членам групи, що мають необхідність перевіряти “старі”
підписи.
Переваги:
• Централізований спосіб зберігання ключів і інформації про статус (протягом існування певного складу
групи).
• Мінімальне навантаження на мережу.
• Незалежність групи від зовнішнього середовища.
Недоліки:
• Порушення принципу рівноправності групи.
• Залежність працездатності групи від працездатності її “привілейованих” членів.
• Необхідність генерації нової інфраструктури при кожній зміні складу групи. Негативний вплив цього
недоліку може бути зменшено шляхом оптимізації алгоритмів зміни складу групи (наприклад, оминаючи
генерацію нової інфраструктури чи виконуючи її частково у певних випадках).
• Накладення підвищених вимог до обчислювальних ресурсів на звичайних членів групи. Оскільки будь-
який член групи може бути обраний на посаду будь-якого органу, він має володіти достатньою кількістю
обчислювальних ресурсів для виконання функцій всіх можливих органів.
Внутрішня розподілена інфраструктура. Найбільш привабливою, на наш погляд, в контексті
забезпечення підтримки повних підписів у групових середовищах, виглядає схема, що базується на
внутрішньому розподіленому підході (рис. 3, в). У цьому випадку відсутні органи, що здійснюють операції з
видачі сертифікатів та часових міток, а їхні функції виконуються певною підмножиною членів групи.
Для побудови такої системи пропонуємо використовувати групові підписи, що базуються на порогових
схемах [11]. Нагадаємо, що (m, n)-порогова схема дозволяє, маючи m часток секрету з n (m ≤ n), отримати
оригінальний секрет. Секретом може виступати будь-що: зашифроване повідомлення, закритий ключ або
можливість використання закритого ключа, що і буде застосовано в даному випадку.
Розглянемо питання функціонування такої групи детальніше.
Відразу після чергової зміни складу групи між n її членами розподіляється n часток закритого групового
ключа KG. Після цього відбувається генерація сертифікатів для кожного члена групи, кожен з яких підписується
ключем KG шляхом об’єднання часток довільних m членів групи. Порогове значення m обирається відповідно
до політики безпеки групи. Принцип, за яким обираються члени, що об’єднують свої частки, може бути
довільним, єдина умова, що накладається на нього, як у попередньому випадку, є детермінованість.
Аналогічно генерації та розподіленню часток ключа KG, генерується ключ KT та порогова схема (mT, nT), що
відповідають за створення часових міток (зауважимо, що для цього може використовуватися і сам ключ KG).
Коли член групи бажає підписати повідомлення, він просить mT довільних членів групи завізувати час його
підписання шляхом об’єднання своїх часток у KT. Гнучкість даного підходу полягає у можливості встановлення
різних порогових значень для підписання сертифіката та видання часових міток.
Захист інформації
562
КЦС
ЦС ЦС
СЧ СС
КЦС
ЦС
СЧ
СС
КЦС
“Сервер”
статусу
“Сервер”
часу
а б
в
Рис. 3
У випадку компрометації ключа, скомпрометований член групи повідомляє про цей факт всім іншим
членам групи, після чого m членів групи додають до його сертифіката підпис, що містить інформацію про час
та причину його відкликання. Кожен член групи зберігає цей “оновлений” сертифікат в себе для використання в
подальшому для перевірки підписів, зроблених відкликаним ключем. Отже, середовище не вимагає наявності
органів, що зберігають інформацію про статус сертифікатів, але накладає певні вимоги щодо об’єму ресурсів,
доступних рядовим членам групи.
Слід відмітити, що для реалізації даного підходу мають використовуватись порогові схеми без розкриття
долей для того, щоб запобігти розкриттю таємного ключа при виконанні операції групового підписування.
Часткові випадки таких схем розглянуті в [12].
Визначимо переваги та недоліки для внутрішньої розподіленої інфраструктури:
• Збереження рівноправності групи. Дійсно, запропонована схема передбачає повне збереження
рівноправності, оскільки на всіх членів групи накладаються однакові вимоги та обов’язки. Окрім того, завдяки
використанню порогових схем, запропонований підхід дозволяє зменшити навантаження на групу шляхом
використання лише певної підмножини членів групи для виконання підпису, та може бути використаний навіть
у дуже великих за обсягом групах.
• Незалежність від зовнішнього середовища. Всі обчислення, пов’язані з обрахунком та перевіркою
коректності підпису, виконуються членами групи без контакту з зовнішнім середовищем.
Недоліки:
• Суттєве навантаження на мережу, вимогливість до ресурсів. Створення групових підписів вимагає
великої кількості комунікацій між членами групи.
• Децентралізоване зберігання інформації про статус.
Висновки
У роботі розглянуті питання побудови інфраструктури цифрових підписів у групових середовищах. При
дослідженні проблеми ми виходили з таких властивостей середовища, як динамічність та рівноправність.
Розглянуто три інфраструктури, що можуть бути застосовані у рівноправних групах: зовнішня централізована,
внутрішня централізована та внутрішня розподілена. Остання, на наш погляд, найбільш повно відповідає
поставленій задачі, оскільки максимізує рівноправність членів групи та не ставить групу в залежність від
зовнішнього середовища. Більш того, вона відповідає духу групової комунікації, який, серед іншого,
передбачає наявність якомога менш централізованого підходу. Для реалізації внутрішньої розподіленої
інфраструктури було запропоновано використовувати порогову криптографічну схему.
Захист інформації
563
Задачами на майбутнє у дослідженні інфраструктур групових підписів ми вважаємо розробку протоколів,
що відповідають запропонованим підходам, та дослідження різноманітних атак, спрямованих як ззовні, так і
зсередини групи.
1. Vitenberg R., Keidar I., Chockler G. Group communication Specifications: A Comprehensive Study // ACM Computer Surveys. – 2001. – 33,
N4. – P. 427 – 469.
2. Merkle R., Brassard G. A certified digital signature // Advances in Cryptology – CRYPTO’89. – 1990. – 435. – P. 218 – 238.
3. Rivest R., Shamir A., Adleman L. A Method for Obtaining Digital Signatures and Public Key Cryptosystems // Communications of the ACM. –
1978. – 21, N2. – P. 120–126.
4. ElGamal T. A Public-Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms // Advances in Cryptology: proceedings of
CRYPTO’84. – 1985. – P.10–18.
5. Koblitz N. Elliptic Curve Cryptosystems // Mathematics of Computations. – 1987. – 48, N177. – P. 203–209.
6. Housley R., Ford W., Polk W., Solo D. Internet X.509 Public Key Infrastructure (RFC2459). – Network Working Group. – 1999. – 129 с.
7. Pinkas D. Electronic Signature Formats for long term electronic signatures (RFC3126). – Network Working Group. – 2001. – 84 с.
8. Adams C., Pinkas D., Zuccherato R. Internet X.509 Public Key Infrastructure: Time-Stamp Protocol (RFC3161). – Network Working Group. –
2001. – 26 c.
9. Myers M., Ankney R., Malpani A., Galperin S. X.509 Internet Public Key Infrastructure: Online Certificate Status Protocol (RFC2560). –
Network Working Group. – 1999. – 23 c.
10. Callas J., Donnerhacke L., Finney H., Thayer R. OpenPGP Message Format (RFC2440). – Network Working Group. – 1998. – 65 с.
11. Shamir A. How to Share a Secret // Communications of the ACM. – 1979. – 24, N11. – P. 612–613.
12. Desmedt Y., Frankel Y. Shared Generation of Authentication and Signatures // Advances in Cryptology – CRYPTO’91 Proceedings. – 1992. –
P. 457–469.
|
| id | nasplib_isofts_kiev_ua-123456789-1463 |
| institution | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| issn | 1727-4907 |
| language | Ukrainian |
| last_indexed | 2025-12-07T17:16:16Z |
| publishDate | 2008 |
| publisher | Інститут програмних систем НАН України |
| record_format | dspace |
| spelling | Іванов, І.Ю. 2008-07-31T12:06:26Z 2008-07-31T12:06:26Z 2008 Цифровий підпис в групових середовищах / І.Ю. Іванов // Пробл. програмув. — 2008. — N 2-3. — С. 557-563. — Бібліогр.: 12 назв. — укp. 1727-4907 https://nasplib.isofts.kiev.ua/handle/123456789/1463 004.056 Розглядаються питання генерації і перевірки цифрових підписів в динамічних рівноправних групових середовищах. Пропонується три можливі схеми побудови інфраструктури цифрового підпису, розглядаються їхні основні переваги та недоліки The paper considers questions on generation and validation of digital signatures in dynamic peer group environments. Three possible digital signature infrastructure schemas (with pluses and lacks described) are proposed. uk Інститут програмних систем НАН України Захист інформації Цифровий підпис в групових середовищах Digital signatures in group environments Article published earlier |
| spellingShingle | Цифровий підпис в групових середовищах Іванов, І.Ю. Захист інформації |
| title | Цифровий підпис в групових середовищах |
| title_alt | Digital signatures in group environments |
| title_full | Цифровий підпис в групових середовищах |
| title_fullStr | Цифровий підпис в групових середовищах |
| title_full_unstemmed | Цифровий підпис в групових середовищах |
| title_short | Цифровий підпис в групових середовищах |
| title_sort | цифровий підпис в групових середовищах |
| topic | Захист інформації |
| topic_facet | Захист інформації |
| url | https://nasplib.isofts.kiev.ua/handle/123456789/1463 |
| work_keys_str_mv | AT ívanovíû cifroviipídpisvgrupovihseredoviŝah AT ívanovíû digitalsignaturesingroupenvironments |