Сервер криптографічних ключів

У термінах інформаційної безпеки , сервер криптографічних ключів — це хост, призначений для зберігання і передачі користувачам, а також іншим криптографічним серверам криптографічних ключів.

Ключі, поширювані даним видом сервера, найчастіше використовуються як частина цифрового сертифікату, що містить не тільки сам ключ, але також і інформацію про власника ключа. Як правило, в цьому випадку використовується сертифікат одного з поширених стандартів: OpenPGP, X. 509 або PKCS. Крім того, зазвичай дані ключі є відкритими ключами для використання в алгоритмах шифрування систем з відкритим ключем.

Історія ред.

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

Перший веборієнтований сервер ключів PGP був описаний і створений Марком Хоровитцем в результаті написання дисертації під час навчання в Массачусетському технологічному інституті. Даний сервер був названий «KHP» по найменуванню розробленого для нього протоколу (OpenPGP HTTP Keyserver Protocol). Користувачі могли отримувати, завантажувати ключі, а також шукати ключі на сервері, використовуючи цей протокол через 11371 порт, або вручну через браузер, запускаючи CGI-скрипти. До створення KHP, сервери ключів управлялися через обробник команд по e-mail.

Незалежний сервер ключів, відомий як Сервер сертифікації PGP був розроблений організацією PGP, Inc. і доступний як додаток (з версії 2.5.x як серверний додаток) для реалізацій функцій сервера ключів PGP починаючи з версії 8.x (клієнтських програм)[1]. 1 січня 2002 року корпорацією Network Associates Technology був виданий патент (United States Patent 6336186)[2] на концепцію сервера ключів.

Для заміни застаріваючого сервера сертифікації, корпорацією Network Associates був представлений сервер LDAP-ключів, що одержав назву PGP Keyserver 7.0. Після виходу PGP 6.0 ця реалізація сервера ключів стала базовим інтерфейсом для використання в реалізаціях PGP, що випускаються Network Associates. LDAP і LDAPS сервера ключів (з підтримкою KHP для зворотної сумісності) також стали основою для PGP Administration tools, які використовувалися для побудови приватного сервера ключів підприємства згідно зі схемою Netscape Directory Server. Пізніше, ця система була замінена на Global Directory компанії PGP Corporation.

Публічні та приватні сервера ред.

Існує безліч публічно доступних серверів ключів, розподілених по всьому світу, що дозволяють зберігати і передавати OpenPGP ключі через інтернет. В більшості своїй, ці сервера підтримуються приватними особами згідно концепції pro bono, реалізуючи тим самим у свою чергу модель використання PGP web of trustweb of trust[en].

Кілька публічно доступних серверів ключів S/MIME[3] також дозволяють додавати або відкликати ключі використовуються в S/MIME криптосистемах.

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

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

Сервера ключів OpenPGP, розроблені в 90-х роках зіткнулися з низкою проблем використання. Одного разу завантажений на сервер публічний ключ дуже важко видалити. З різних причин (наприклад, втрата або крадіжка парного приватного ключа) деякі користувачі припиняли використовувати свої публічні ключі. У цьому випадку було досить важко видалити публічний ключ, і, навіть якщо він був вилучений, нічого не заважало зловмиснику завантажити на сервер копію ключа знову. У такій ситуації на сервері накопичувалось велика кількість старих непотрібних публічних ключів, так звані «атеросклеротичні бляшки» сервера ключів.

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

Для вирішення даних проблем організація PGP Corporation розробила нове покоління серверів криптографічних ключів під назвою PGP Global Directory. У таких серверах при додаванні публічного ключа, на e-mail передбачуваного власника відсилали запит на підтвердження володіння завантаженим ключем. Якщо підтвердження було отримано, ключ приймався сервером як легітимний. Також для запобігання перетворення ключа в фіктивну «бляшку», подібний запит міг періодично надсилатися повторно. У результаті список ключів на сервері підтримувався в актуальному стані і при бажанні завжди можна було перевірити легітимність ключа запитом власнику по e-mail. На жаль, те, що перевірка легітимність здійснювалася без використання криптографічних методів у звичайному e-mail призвело до того, що будь-хто, хто має доступ до аккаунту e-mail міг, наприклад, видалити ключ або додати фіктивний.

В останньому проекті IETF для HKP була описана розподілена мережа серверів криптографічних ключів, заснована на DNS SRV-записах: при пошуку ключа для someone@example.com можна надіслати запит на сервер ключів example.com.

Приклади серверів ключів ред.

Нижче наведено кілька серверів ключів, які найчастіше використовуються для отримання ключа командою «gpg --recv-key»

Дивись також ред.

Примітки ред.

  1. PGP Global Directory. Архів оригіналу за 18 травня 2001. Процитовано 23 квітня 2018.
  2. United States Patent 6336186[недоступне посилання з травня 2019]
  3. KeyServers — CAcert Wiki. Архів оригіналу за 8 січня 2018. Процитовано 23 квітня 2018.

Посилання ред.