Інфраструктура відкритих ключів

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до навігації Перейти до пошуку

Інфраструктура відкритих ключів (англ. public key infrastructure, PKI) — інтегрований комплекс методів та засобів (набір служб), призначених забезпечити впровадження та експлуатацію криптографічних систем із відкритими ключами[1].

Інфраструктура відкритих ключів складається з програмного забезпечення, кртиптографічних технологій та служб, які дозволяють підприємствам та організаціям захищати канали зв'язку в комп'ютерних мережах. Вона поєднує електронні цифрові сертифікати, асиметричні алгоритми шифрування, та центри сертифікації у єдину мережеву архітектуру[2].

Інфраструктура відкритих ключів побудована на криптосистемах з відкритим ключем. Ця технологія має властивості, які відіграють важливу роль у захисті даних в розподілених системах[2]. Технологія PKI полягає у використанні двох математично пов'язаних цифрових ключів, що мають такі властивості:[1]

  • один ключ може бути використаний для шифрування повідомлення, що може бути розшифровано тільки за допомогою другого ключа;
  • навіть якщо відомий один ключ, за допомогою обчислень практично неможливо визначити другий. Один із ключів відкритий для всіх, а другий має приватний характер і зберігається в захищеному місці. Ці ключі можуть бути використані для автентифікації чи шифрування цифрового підпису електронних даних.

PKI служить не лише для створення цифрових сертифікатів, але і для зберігання великої кількості сертифікатів і ключів, забезпечення резервування і відновлення ключів, взаємної сертифікації, ведення списків анульованих сертифікатів і автоматичного відновлення ключів та сертифікатів після закінчення терміну їхньої дії[1].

Підходи до реалізації

[ред. | ред. код]

Відомі таки приклади підходів до реалізації інфраструктури відкритих ключів:[3]

  • інфраструктура відкритих ключів, основана на сертифікатах у форматі X.509 — PKIX,
  • проста інфраструктура відкритих ключів SPKI/SDSI[en],
  • захищена система домених імен DNS (DNSSEC, TSIG[en]),
  • система захищеної електронної пошти PGP (англ. Pretty Good Privacy),
  • система захищених електронних транзакцій SET[en].

Архітектура PKIX розглянута докладніше в решті статті, інші — нижче в цьому розділі.

Проста інфраструктура відкритих ключів

[ред. | ред. код]
Докладніше: SPKI[en]

Задача простої інфраструктури відкритих ключів SPKI (англ. Simple Public Key Infrastructure) полягає в поширенні сертифікатів для авторизації, а не автентифікації власників відкритих ключів. Основою для SPKI стали ідеї простої розподіленої інфраструктури безпеки SDSI (англ. Simple Distributed Security Infrastructure), тому зазвичай цю технологію називають SPKI/SDSI[en][3].

Центральними об'єктами SDSI є самі ключі, а не імена. Саме ключі можуть ідентифікувати об'єкти[3].

Основна мета сертифіката SPKI — авторизація певних дій, видача дозволів, надання можливостей, тощо власнику ключа. Сертифікати для авторизації мають бути згенеровані власником ключа, якому дозволено надавати або делегувати повноваження. Власник ключа може використовувати глобальне сховище інформації, наприклад, LDAP, сервер ключів PGP, або систему домених імен DNS[3].

В такій системі сертифікат SPKI можна порівняти із звичайним ключем (на противагу зв'язці ключів). Власник ключа SPKI має випускати сертифікати, які містять мінімум необхідної інформації. Оскільки одним із варіантів застосування сертифікатів SPKI є таємне голосування та аналогічних застосунках, сертифікати повинні надавати можливість надавати атрибут ключу знеособленого підпису. Одним з атрибутів ключа є його ім'я. У одного власника ключа може бути декілька імен: ті, якими власник віддає перевагу бути названим, й ті, під якими він відомий іншим власникам ключів. Сертифікат SPKI має забезпечувати можливість пов'язувати ключі з такими іменами[3].

Захищена система домених імен DNS

[ред. | ред. код]

Доменна система імен DNS (англ. Domain Name System) є розподіленою базою даних з децентралізованим керуванням, яка зберігає узагальнену інформацію про ресурси мережі та задає схему іменування, основану на ієрархічно структурованих доменних іменах. Структура даних DNS — інвертоване дерево з коренем нагорі. Кожен вузел дерева є розділом загальної бази даних або домен. Кожен домен має доменне ім'я, яке ідентифікує його розташування в базі даних DNS[3].

Для захисту інформації при передачі даних може бути використаний механізм TSIG[en]. Цей механізм дозволяє автентифікувати будь-які повідомлення DNS: передачі зони, динамічне оновлення та звичайні запити й відповіді, але тільки між хостами, що знають таємний ключ (кожна пара хостів може мати власний таємний ключ)[3].

Для забезпечення достовірною передачі даних DNS в масштабах мережі Інтернет використовують розширення протоколу відомі як DNSSEC. Основна ідея полягає у використанні криптографії з відкритими ключами для додавання цифрового підпису до даних. Таємний ключ відомий лише адміністратору первинного сервера зони. Цифровий підпис додається до бази даних у вигляді запису спеціального типу SIG. Дані передають у відкритому вигляді, а відкритий ключ з пари ключів доступний всім охочим[3].

Для реалізації механізму DNSSEC введено три нових типи записів: KEY, SIG та NXT. Запис типу KEY містить відкритий ключ зони, а SIG — цифровий підпис для набору записів[3].

Система захищеної електронної пошти PGP

[ред. | ред. код]

Система PGP (англ. Pretty Good Privacy) створена для захисту таємниці повідомлень електронної пошти в глобальному інформаційному середовищі. PGP є гібридною системою, яка комплексно використовує переваги асиметричних та симетричних криптографічних алгоритмів. З точки зору користувачів виглядає як система з відкритим ключем. Вона забезпечує безпечний обмін повідомленнями через канали відкритого зв'язку без наявності захищеного каналу для обміну ключами. PGP дозволяє шифрувати, засвідчувати електронним цифровим підписом, розшифровувати та перевіряти повідомлення при відправці та отриманні електронної пошти[3].

Перед використанням PGP користувач має згенерувати пару ключів: відкритий та особистий. Відкритий ключ може бути переданий іншим через електронну пошту, розташований на сервері ключів, тощо. Інші абоненти можуть переконатись у вірності відкритого ключа звіривши його відбиток. Після перевірки дійсності ключа користувач підписує його, чим підтверджує безпеку та ступінь довіри до нього. Інформація про ступінь довіри зберігається у зв'язці ключів, але при експорті ключа не передається, оскільки вважається конфеденційною[3].

Система надає можливість всім користувачам виступати посередниками у поширенні інформації про ступені довіри до ключів. Таким чином утворена мережа довіри[en]. Як окремий випадок загальної моделі PGP підтримує централізований сценарій, коли сертифікати ключів користувачів засвідчує власним підписом особа, що користується загальною довірою — засвідчувальний центр. Система PGP пропонує інтегровані засоби для поширення та пошуку ключів на серверах ключів[3].

Система захищених електронних транзакцій SET

[ред. | ред. код]
Докладніше: Secure Electronic Transaction[en]

Протокол SET (англ. Secure Electronic Transaction — захищені електронні транзакції) оснований на технічному стандарті, який був розроблений компаніями VISA та MasterCard, та забезпечує безпеку електронних розрахунків за пластиковими картками через Інтернет: гарантує конфіденційність та цілісність інформації про платежі, автентифікацію рахунку власника картки та надає можливість підтвердити право продавця здійснювати фінансові опреації з фінансовими установами[3].

В середовищі SET інфраструктура відкритих ключів є фундаментом, на якій основана вся система автентифікації учасників розрахунків. Цифрові сертифікати, які тут також називають електронними мандатами або цифровими посвідченнями особи, використовують для зв'язування відкритих ключів та суб'єктів. Їх випускає довірена третя сторона або компанія — засвідчувальний центр[3].

Конфіденційність та цілісність повідомлень, якими обмінюються учасники захищених електронних транзакцій, забпезпечена механізмом подвійних підписів. Вміст кожного повідомлення шифрується із допомогою випадково згенерованого симетричного ключа шифрування. Цей ключ, в свою чергу, шифрується із використанням відкритого ключа отримувача повідомлення. Отриманий в результаті останньої операції так званий цифровий конверт відправляється отримувачу разом із зашифрованим повідомленням. Після отримання цифрового конверту, отримувач розшифровує його своїм особистим ключем, аби отримати випадково згенерований симетричний ключ для розшифровування вмісту повідомлення відправника[3].

Протокол SET надає послугу автентифікації для учасників завдяки використанню сертифікатів формату X.509 та має засоби анулювання, реалізовані у вигляді списку анульованих сертифікатів. В SET визначені власні специфічні доповнення сертифікатів, які мають підтримку лише в SET-сумісних системах[3].

Основні складові

[ред. | ред. код]

Основними складовими інфраструктури відкритих ключів є центри сертифікації, центри реєстрації (засвідчення), репозиторії та архіви сертифікатів. Основними користувачами інфраструктури є: держателі (англ. Certificate Holders) та користувачі сертифікатів (англ. Certificate User) — також відомі як «сторона, що довіряє» (англ. Relying party)[4].

Центр сертифікації ключів (англ. Certificate Authority, CA) — юридична особа незалежно від форми власності або фізична особа, яка є суб'єктом підприємницької діяльності, що надає послуги щодо сертифікації відкритих ключів[5]. Центр сертифікації складається з апаратного, програмного забезпечення та обслуги. Центри сертифікації мають два важливих атрибути: назву та відритий ключ. Центри сертифікації виконують чотири основні завдання:

  • видача сертифікатів (тобто, центр створює та підписує електронний цифровий сертифікат);
  • оброблення статусу сертифікатів та підтримання списків анульованих сертифікатів (англ. CRL);
  • поширення поточного списку дійсних та анульованих сертифікатів, аби користувачі мали можливість перевірити стан сертифікату;
  • підтримання архівних даних про сертифікати та їхній стан.

Центри сертифікації інколи можуть делегувати відповідальність за деякі з цих задач до інших складових інфраструктури[6].

Центр сертифікації ключів разом із об'єктами, яким видано сертифікати цього центру утворюють домен (ЦСК-домен)[7].

Центр реєстрації (англ. Registration Authority, RA) — об'єкт, що відповідає за ідентифікацію та аутентифікацію суб'єктів сертифікатів, але не підписує і не випускає сертифікати (тобто, RA делегуються деякі задачі від імені центру сертифікації)[4][5].

Архів — це база даних, яка зберігає та захищає інформацію для розв'язання різних суперечок, які можуть виникнути у майбутньому. Основним завданням архіву є безпечне зберігання інформації, необхідної для встановлення вірності «старих» електронних підписів[4].

Центр сертифікації формує цифрові сертифікати ключа. Цифровий сертифікат електронного ключа зазвичай містить відкритий ключ, основні дані (реквізити) підписувача — власника особистого ключа, термін дії сертифікату, найменування та реквізити центру сертифікації ключів та електронний цифровий підпис самого центру сертифікації. Крім того, сертифікат може містити додаткову інформацію про центр сертифікації, власника сертифіката, або інформацію про передбачені способи використання відкритого ключа. Підписувачі звертаються до центрів сертифікації аби отримати свій сертифіакт електронного ключа, аби в подальшому користуватись електронним ключем для підтвердження своєї особи та мати можливість засвідчувати документи електронним цифровми підписом[4].

Користувачами інфраструктури відкритих ключів є організації та фізичні особи, які користуються послугами інфраструктури, але не видають цифрові сертифікати. Користувачі інфраструктурою покладаються на інші її складові для отримання сертифікатів, та для верифікації сертифікатів інших користувачів[4].

Моделі

[ред. | ред. код]

Побудова ЦСК-доменів основана на таких типах центрів сертифікації ключів:[7]

  • Ізольований/Одноранговий ЦСК (англ. Isolate/Peer CA);
  • Кореневий ЦСК (англ. Root CA);
  • Підпорядкований ЦСК (англ. Subordinate CA);
  • Шлюзовий ЦСК (англ. Bridge/Gateway CA).

Інфраструктура відкритих ключів окремого підприємства, відомства тощо може бути побудована за однією з відомих моделей:[7]

  • Одноранговий ЦСК-домен (англ. Peer Domain PKI);
  • Ієрархічний ЦСК-домен (англ. Hieratic Domain PKI).

Реалізації таких моделей часто утворюють замкнену групу, утворену в межах одного підприємства/організації та призначену для відокремленого від інших ЦСК застосування локальної інфраструктури ЕЦП[7].

Архітектура ЕЦП для об'єднання окремих ЦСК-доменів підприємств, відомств тощо в єдину довірчу інфраструктуру може бути за однією з відомих моделей:

  • Ієрархічна модель (англ. Hieratic model);
  • Мережена модель (англ. Mesh model);
  • Шлюзова модель (англ. Bridge model)[7].

Одноранговий домен

[ред. | ред. код]

Ізольований/Одноранговий ЦСК–домен має центр сертифікації ключів з автопідписаним сертифікатом (англ. self-signed СА-certificate), який не засвідчений (не підписаний) будь-яким іншим ЦСК вищого рівня. Шлях сертифікації у цьому випадку дорівнює 2, тобто ЦСК-сертифікат та сертифікат клієнта цього ЦСК. Ізольований ЦСК не видає сертифікати іншим ЦСК (не має підпорядкованих ЦСК)[7].

Такий ЦСК-домен складається лише з ізольованого центру сертифікації ключів та клієнтів-держателів сертифікатів, яким видано сертифікати цим ЦСК. Такий домен ще називають ізольованим/одноранговим ЦСК-доменом (англ. Peer Domain PKI)[7].

Приєднати ізольований ЦСК-домен до деякої інфраструктури ЕЦП (до іншого ЦСК-домену) можна двома способами:[7]

  • Через ієрархічні відносини, як підпорядкований ЦСК (див. Ієрархічний ЦСК-домен);
  • Через відносини рівноправних ЦСК (англ. peer-to-peer: кросс-сертифікацію).

В першому випадку вимагається обов'язково перевипустити (замінити) ЦСК-сертифікат, а отже здійснити повний перевипуск усіх сертифікатів держателів[7].

В другому випадку це не потрібне — усі сертифікати держателів залишаються чинними після приєднання Ізольованого ЦСК до деякого довірчого ЦСК-домену через механізм кросс-сертифікації[7].

Переваги Ізольованого ЦСК:[7]

  • мінімальна вартість та простота впровадження.

Особливо приваблива така структура для малих та середніх організацій, у яких усі клієнти ЦСК належать до однієї групи/категорії, наприклад, працівники організації.

Недоліки Ізольованого ЦСК:[7]

  • усі клієнти ЦСК з однаковим профілем сертифікату мають однакові довірчі відносини;
  • не можна «відокремити» довірчий сертифікат, початок довірчого шляху сертифікації (ЦСК-сертифікат), який є найбільш важливим з точки зору безпеки домену, від сертифікатів інших користувачів;
  • компрометація ЦСК-сертифікату чи приєднання Ізольованого ЦСК до Ієрархічного домену призводить до необхідності повного перевипуску усіх сертифікатів цього ЦСК;
  • деякі стандарти РКІ (наприклад, стандарт банківського РКІ Європейського Співтовариства Identrus) не допускають видачу сертифікатів клієнтам Ізольованими ЦСК.

Центр сертифікації ключів з само-підписаним сертифіктом також називають «кореневим» (англ. Root CA)[7].

Ієрархічна модель

[ред. | ред. код]

Ієрархічна модель об'єднує ЦСК-домени в структуру зв'язного графа у вигляді дерева, що має одну головну вершину (Кореневий ЦСК — англ. Root CA), з якої будується структура Підпорядкованих ЦСК. В Ієрархічній моделі є один головний ЦСК, якому довіряють усі користувачі — це Кореневий ЦСК, тобто для усіх держателів сертифікатів ієрархічної моделі шлях сертифікації починається з одного Кореневого ЦСК[7].

Кореневий ЦСК не випускає сертифікатів для Клієнтів, окрім виключно Підпорядкованих ЦСК. Кожен з Підпорядкованих ЦСК може випустити сертифікат як своїм Клієнтам, так і підпорядкованому йому іншому ЦСК — Підпорядковані ЦСК другого рівня[7].

В Ієрархічній моделі довірчі відносини визначені лише в одному напрямку — від вищого рівня до нижчого рівня ЦСК, тобто Підпорядковані ЦСК не випускають сертифікати для ЦСК вищого рівня[7].

Політики сертифікатів визначаються Кореневим ЦСК для усього домену, і можуть додатково визначатися (у межах, що не суперечать політиці вищого рівня ЦСК) Підпорядкованими ЦСК для власних ЦСК-доменів[7].

Переваги Ієрархічної моделі:[7]

  • головною перевагою ієрархічної моделі є простота її початкової побудови;
  • наявність Кореневого ЦСК, який видає сертифікати лише Підпорядкованим ЦСК, тобто «працює» періодично, що дозволяє забезпечити вищий рівень безпеки;
  • дозволяє розмежувати повноваження (права) доступу груп користувачів до сервісів;
  • дозволяє просто додавати нові довірчі групи держателів сертифікатів шляхом підключення нового Підпорядкованого ЦСК;

Недоліки Ієрархічної моделі є наслідками довіри єдиній точці (вищому рівню — Кореневому ЦСК) в структурі ієрархії:[7]

  • компрометація «кореня» (ключа Кореневого ЦСК) призводить до компрометації усього Ієрархічного «дерева» та необхідності заміни (перегенерації) усіх без винятку ключів держателів, причому не віддалено, а згідно з процедурою видачі першого сертифікату (особистий контакт), що може мати фатальні наслідки для організації. Інших безпечних методів відновлення роботи домену та усіх підпорядкованих йому під-доменів не існує;
  • єдиний Кореневий ЦСК може бути неможливим із «політичних» міркувань — конкуренція, міжвідомчі перепони тощо;
  • перехід як від Ізольованих ЦСК, так і від інших окремих Ієрархічних доменів до єдиної Національної ієрархічної моделі інфраструктури ЕЦП є логічно непрактичним, оскільки усі користувачі сертифікатів вже наявних ЦСК-доменів повинні внести зміни до їх довірчих точок (шляхів), а усі держателі сертифікатів замінити їх та відповідно ключі підпису на нові, які відповідатимуть новій ієрархічній структурі.

Додатково необхідно підкреслити, що в ієрархічній структурі при перевірці ланцюжків сертифікатів не передбачана перевірка сертифікату «кореня» домену, бо він є само-підписаним, а тому при компрометації ключа кореня публікація списку анульованих сертифікатів (CRL) стає неможливою, оскільки цей список необхідно підписати вже скомпрометованим ключем, до якого немає довіри[7].

Мережена модель

[ред. | ред. код]

Мережена модель ІВК — це модель встановлення довірчих відносин між окремими Ізольованими та Ієрархічними ЦСК — доменами без довірчого посередника. Довірчі відносини встановлюються через механізм кросс-сертифікації між Головними ЦСК (англ. Principal CA) в кожному з доменів[7].

Переваги мереженої моделі:[7]

  • відносна простота встановлення довірчих відносин: достатньо застосувати механізм кросс-сертифікації між Головними ЦСК в існуючому домені ЦСК, не торкаючись при цьому Клієнтів ЦСК, тобто не вимагаються будь які зміни в середині кожного ЦСК-домену;
  • дуже еластична структура щодо того, що існує багато точок довіри;
  • компрометація окремого ЦСК не може скомпрометувати усю структуру;
  • відновлення після компрометації простіше, ніж для Ієрархічної моделі;
  • може бути легко створена з набору Ізольованих ЦСК чи доменів різної структури, оскільки держателі та користувачі сертифікатів не повинні змінювати їх точку довіри.

Недоліки цієї моделі пов'язані із дво-направленністю моделі довіри (на відміну від одно-направленої у Ієрархічній моделі):[7]

  • при компрометації будь — якого з Головних ЦСК учасників, він самостійно має оповістити решту;
  • розширення шляху сертифікації складніше, ніж в Ієрархічній моделі.

На відміну від ієрархії, побудова шляху сертифікації від сертифіката держателя до точки довіри не детермінована (не жорстко визначена). Це ускладнює встановлення шляху сертифікації, оскільки можуть бути альтернативні шляхи. Деякі з них приведуть до допустимого шляху, а інші до глухого кута. Також можуть виникати «петлі» (цикли, які починаються та закінчуються на одному і тому ж ЦСК)[7].

Шлюзова модель

[ред. | ред. код]

Шлюзова модель складається із окремих незалежних ізольованих та ієрархічних доменів (часткових графів, окремих «дерев»), в тому числі інших структур зі шлюзовою моделлю, які об'єднані довірчими відносинами через довірчого посередника, Шлюзовий ЦСК (англ. Gateway CA), за допомогою механізму кросс-сертифікації[7].

Головна особливість цієї моделі — можливість додавати нові домени через довірчого посередника, Шлюзовий ЦСК або інша назва — «міст» (англ. Bridge СА), який відмінний від Кореневого ЦСК. Така модель об'єднує переваги Ієрархічної та Мереженої моделей[7].

Шлюзовий ЦСК не випускає сертифікатів для окремих користувачів, а лише здійснює кросс-сертифікацію між доменами на рівні однорангових відносин. Це дозволяє встановити прості та прозорі відносини довіри між різними об'єднаннями користувачів через Шлюзовий ЦСК з визначеним рівнем довіри.

Переваги шлюзової моделі в порівнянні з мережевою моделлю:[7]

  • можливість застосувати суворішу процедуру реєстрації учасників, в тому числі з урахуванням вимог для ієрархічних ЦСК;
  • при компрометації будь-якого з ЦСК-учасників, цей ЦСК інформує Шлюзовий ЦСК і йому не потрібно «множити» інформацію на всіх ЦСК-учасників, оскільки цю функцію виконує Шлюзовий ЦСК.

Інші переваги Шлюзової моделі:[7]

  • дозволяє легко підключити новий ЦСК;
  • держателі та користувачі сертифікатів не повинні змінювати їх точку довіри чи свої ключі;
  • компрометація окремого ЦСК, не може скомпрометувати усю структуру;
  • відновлення після компрометації простіше в шлюзовій моделі, ніж в ієрархічній.

Недоліки шлюзової моделі подібні тим, які є у мереженої. Але шляхи сертифікації значно коротші[7].

Проблема появи циклічних шляхів сертифікації в Шлюзовій моделі існує, але вона менш гостра, оскільки тут є єдина структура (Шлюзовий ЦСК), що може контролювати появу (наявність) циклічних шляхів і відповідно не допускати їх[7].

Приклади інфраструктури відкритих ключів

[ред. | ред. код]

Україна

[ред. | ред. код]

Прийняття у 2003 році Закону України «Про електронний цифровий підпис», відповідних постанов Кабінету Міністрів України та декількох актів уповноважених державних органів які були спрямовані на забезпечення регулювання з боку держави впровадження в Україні технології електронного цифрового підпису в першу чергу в державному секторі. Створена на основі цього Закону Національна система електронного цифрового підпису (НСЕЦП) від імені держави гарантує якість та надійність послуг електронного цифрового підпису (ЕЦП)[8].

НСЕЦП в Україні розвивалась під керівництвом Державної служби спеціального зв'язку та захисту інформації України і Державного агентства з питань науки інновацій та інформатизації України. Паралельно розбудовується ініційована Національним банком України система ЕЦП у банківській сфері[8].

Станом на 2014 рік відповідно до Переліку центральних органів виконавчої влади, на які покладено функції технічного регулювання у визначених сферах діяльності, затвердженого постановою Кабінету Міністрів України від 13 березня 2002 р. № 288, на Міністерство юстиції України покладено функцію технічного регулювання у сфері електронного цифрового підпису[8].

Відповідно до Положення про Міністерство юстиції України, затвердженого Указом Президента України від 6 квітня 2011 № 395, Мін'юст виконує функції центрального засвідчувального органу (ЦЗО), регулює сферу електронного цифрового підпису шляхом акредитації та державного нагляду за діяльністю центрів сертифікації, а також формує основні напрямки та засади політики НСЕЦП України[8].

Діюча в Україні НСЕЦП за схемою сертифікації та ієрархією належить до кореневих. Кореневий центр сертифікації ЦЗО видає сертифікати підлеглим центрам сертифікації (відповідно — засвідчувальним органам або акредитованим/зареєстрованим центрам сертифікації ЦСК/АЦСК/АЗЦ НБУ) і йому безпосередньо довіряють кінцеві користувачі підлеглих центрів сертифікації. Використовуючи загальний сертифікат кореневого–центрального засвідчувального органу, можна перевірити всі сертифікати користувачів зареєстрованих та АЦСК, а також АЗЦ НБУ[8].

Згідно зі статтею 17 Закону України «Про електронний цифровий підпис» іноземні сертифікати ключів, засвідчені відповідно до законодавства тих держав, де вони видані, визнаються в Україні чинними у порядку, встановленому законом. Однак, станом на 2014 рік, правовий механізм регулювання визнання іноземних сертифікатів ключів відсутній. У зв'язку з цим однією з ключових проблем, які постали перед державою у сфері надання послуг електронного цифрового підпису, є відсутність інтероперабельності Національної системи електронного цифрового підпису як у межах України, так і з іншими державами[8].

Головною проблемою, яка постала перед Україною у сфері надання послуг електронного цифрового підпису, є відсутність сучасної інтероперабельної Національної системи електронного цифрового підпису. Національна система ЦСК в Україні має поєднувати в собі функції обслуговування громадян та організацій України і забезпечувати можливість їх взаємодії з громадянами й організаціями ЄС. При її розбудові виникли завдання, зокрема, забезпечення взаємодії державних органів України з офіційними органами та недержавними організаціями держав ЄС[8].

Досвід країн Європейського Союзу щодо розбудови національних інфраструктур електронного цифрового підпису базується на положеннях Директиви 1999/93/ЄС та стандартах розроблених на її основі. Національні системи об'єднані в систему континентального масштабу і мають технічну спорідненість та алгоритмічну сумісність застосованих програмно-технічних рішень в сфері ЕЦП[8].

Зокрема прийнята у ЄС комітетом JTC1 система ISO/IEC відкрита за визначенням і має властивості інтероперабельності, масштабованості, мобільності, унормованості. Інфраструктура інформаційного суспільства має забезпечити дві складові подання даних та засоби довіри до цих даних[8].

З розвитком програми електронного уряду в країнах ЄС органи державного управління все ширше використовують електронні сертифікати для безпеки комунікацій, шифрування та електронного підпису, в тому числі в міждержавних відносинах в межах ЄС. Виникла необхідність встановлення відносин довіри між ЦСК, які використовуються національними органами державного управління. Це необхідно для того, щоб державні службовці держав ЄС могли використовувати електронні сертифікати, випущені їх національними ЦСК, в зальноєвропейській (pan-European) державній мережі[8].

У зв'язку з цим основною метою є встановлення системи взаємної довіри між ЦСК європейських державних (недержавних) органів. Це дасть змогу підприємствам і громадянам, які володіють електронними сертифікатами, випущеними національними ЦСК (державними та недержавними), взаємодіяти в межах ЄС як між собою, так і з державними органами та в електронній комерції ЄС[8].

Традиційна модель інфраструктури з відкритими ключами (PKI — Public Key Infrastructure) дає змогу вирішити питання щодо встановлення відносин довіри між ЦСК через механізм «крос-сертифікації» («cross-certification»). Для побудових Національних ІВК в США, Канаді, ЄС, тощо, використано модель Шлюзового ЦСК (англ. Bridge СА або англ. Gateway CA)[8].

В ЄС ініціатива «European Bridge-CA» була ініційована Дойче банком (Deutsche Bank) та Дойче Телекомом (Deutsche Telekom)[8].

Зоркема в ЄС використовується Державний шлюзовий ЦСК, «Bridge СА» (BGCA — англ. Bridge Government Certificate Authority), призначений забезпечити такий ступінь довіри, який необхідний для використання електронних сертифікатів як на національному, так і на європейському рівнях[8].

Відповідна робоча програма ЄС щодо створення «Bridge СА» (ВСА) на рівні ЄС була розпочата в 2001 р. Базою для програми «Bridge СА» був проект РКІ для замкнутих груп (PKICUG — англ. Public Key Infrastructure for Closed User Groups) користувачів ЄС, який був розпочатий в січні 1999 р., як частина програми Обміну даними між урядами (IDA — англ. Interchange of Data between administrations), що призначена для розвитку та виконання між урядами країн ЄС електронного обміну даними через транс'європейські мережі[8].

Мінімальними вимогами ЄС щодо стандартів і специфікацій для Довірчого центру є:[8]

  • послуги (сертифікації та списки відкликаних сертифікатів) Довірчого центру повинні відповідати Інтернет-стандартам, необхідним для підтримки інфраструктури відкритого ключа та відповідним специфікаціям;
  • служби каталогу (мережі/домену) Довірчого центру мають бути сумісні щонайменше зі стандартом X.500 та підтримувати LDAP запити;
  • дотримання стандартів ETSI (European Telecommunications Standards Institute) щодо центрів сертифікації ключів, які випускають «прості» (не регульовані державою) сертифікати відкритих ключів та посилені сертифікати.

Примітки

[ред. | ред. код]
  1. а б в Гончарова Л. Л., Возненко А. Д., Стасюк О. І., Коваль Ю. О. (2013). 4.5. Алгоритми з використанням ключів. Основи захисту інформації в телекомунікаційних та комп'ютерних мережах (PDF). Державний економіко-технологічний університет транспорту. Архів оригіналу (PDF) за 16 травня 2017. Процитовано 14 липня 2017. [Архівовано 16 травня 2017 у Wayback Machine.]
  2. а б 3. Public Key Infrastructures. Introduction to Public Key Technology and the Federal PKI Infrastructure (PDF). Т. 800—32. NIST. 26 February 2001. Архів оригіналу (PDF) за 5 червня 2018. Процитовано 14 липня 2017.
  3. а б в г д е ж и к л м н п р с т Горбатов В.С., Полянская О.Ю. (2004). 2. Структура, сервисы и архитектура PKI. Основы технологии PKI. М.: Горячая линия – Телеком. с. 248. ISBN 5-93517-154-6.
  4. а б в г д NIST 800-32; 3.1 PKI Components
  5. а б к. ф.-м.н. Мартиненко С. В. Національна система PKI України (UaPKI). Архітектура національної PKI (PDF). Архів оригіналу (PDF) за 21 січня 2022. Процитовано 18 липня 2017.
  6. NIST 800-32; 3.1.1 Certification Authorities
  7. а б в г д е ж и к л м н п р с т у ф х ц ш щ ю я аа аб ав аг ад ае Сергій Валентинович Бєлов, Сергій Васильович Мартиненко (2005). Моделі побудови національної інфраструктури центрів сертифікації ключів та їх ризики (PDF). Збірник наукових праць ІПМЕ ім. Г. Є. Пухова, НАН України (28): 68—79. Архів оригіналу (PDF) за 5 березня 2017. Процитовано 18 липня 2017.
  8. а б в г д е ж и к л м н п р с т Костенко О. В. (2014). Створення Довірчого центру Міністерства юстиції України – вікно держави у світовий простір електронного цифрового підпису. Бюлетень Міністерства юстиції України (3): 142—149.

Література

[ред. | ред. код]

Див. також

[ред. | ред. код]

Посилання

[ред. | ред. код]