Введення в pki

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

Спочатку визначимо ключові терміни, використовувані в Інфраструктурі Відкритого Ключа (Public Key Infrastructure – PKI) і основні історичні моменти розробки PKI. Потім розглянемо архітектуру PKI, визначимо основні формати даних і протоколи взаємодії учасників PKI.

Однією з вимог до алгоритмів цифрового підпису є вимога, щоб було розрахунково неможливо, знаючи відкритий ключ KU, визначити закритий ключ KR. Здавалося б, відкритий ключ KU можна поширювати по небезпечних мережах і зберігати в небезпечних репозиторіях. Але при цьому варто пам'ятати, що при використанні цифрового підпису необхідно бути впевненим, що суб'єкт, з яким здійснюється взаємодія з використанням алгоритму відкритого ключа, є власником відповідного закритого ключа. У противному випадку можлива атака, коли опонент заміняє відкритий ключ законного учасника своїм відкритим ключем, залишивши при цьому ідентифікатор законного учасника без зміни. Це дозволить йому створювати підпису від імені законного учасника й читати зашифровані повідомлення, послані законному учасникові, використовуючи для цього свій закритий ключ, що відповідає підміненому відкритому ключу. Для запобігання такої ситуації варто використовувати сертифікати, які є структурами даних, що зв'язують значення відкритого ключа із суб'єктом. Для зв'язування необхідна наявність довіреного центра, що засвідчує (або сертифікаційного) (Certification Authority – СА), який перевіряє ідентифікацію суб'єкта й підписує його відкритий ключ і деяку додаткову інформацію своїм закритим ключем.

Метою PKI є надання довіреного й дійсного відкритого ключа учасника, а також керування всім життєвим циклом сертифіката відкритого ключа.

Основним поняттям Інфраструктури Відкритого Ключа є поняття сертифіката.

Сертифікат учасника, створений СА, має наступні характеристики:

1. Будь-який учасник, що має відкритий ключ СА, може відновити відкритий ключ учасника, для якого СА створив сертифікат.

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

Ми будемо розглядати сертифікати Х.509, хоча існує досить багато сертифікатів інших форматів.

CCITT (Consultative Committee for International Telegraphy and Telephony) розробив серію рекомендацій для створення так званого сервісу Директорії. Директорія є сервером або розподіленим набором серверів, які підтримують розподілену базу даних, що містить інформацію про користувачів і інші об'єкти, що називається Інформаційною Базою Директорії (Directory Information Base - DIB). Дана інформація може включати ім'я користувача або об'єкта, а також інші атрибути. Ці рекомендації звуться стандарту Х.500.

Стандарт Х.509 спочатку був частиною стандарту Х.500 і описував основні вимоги до автентифікації в Х.500 Директорії. Але Х.509 використовується не тільки в контексті сервісу Директорії Х.500. Сертифікати, обумовлені даним стандартом, використовуються практично всіма програмними продуктами, що ставляться до забезпечення мережної безпеки. Стандарти ITU-T X.509 і ISO/IEC 9594-8, вперше були опубліковані в 1988 році як частина рекомендацій Х.500 Однак розширення стандарту ISO/IEC, ITU-T і ANSI X9 є дуже загальними, щоб застосовувати їх на практиці. Для того щоб розробляти інтероперабельні реалізації систем, що взаємно використовують сертифікати Х.509 v3, необхідно чітко специфікувати формат сертифіката Х.509 v3. Фахівці IETF розробили профіль сертифіката X.509 v3 і опублікували його в RFC 3280.

У таблиці 10.1 розглянуто основні елементи сертифіката.

Часто використовується наступна нотація для позначення сертифіката:

СА << A >>

– сертифікат користувача А, виданий сертифікаційним центром СА.

СА підписує сертифікат своїм закритим ключем. Якщо відповідний відкритий ключ відомий користувачеві, то користувач може перевірити, що сертифікат, підписаний СА, дійсний.

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

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

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

Таблиця 13.1 – Основні елементи сертифіката

Параметри сертифіката	Пояснення
Серійний номер	Ціле число, що ідентифікує даний сертифікат, що повинне бути унікальним серед всіх сертифікатів, випущених даним СА
Ім'я СА, що випустило сертифікат	СА, що створив і підписав сертифікат
Не раніше	Період дійсності складається із двох часових значень, у проміжку між якими сертифікат вважається дійсним
Не пізніше
Ім'я суб'єкта (кінцевого учасника)	Кінцевий учасник, для якого створений даний сертифікат
Алгоритм	Відкритий ключ суб'єкта й алгоритм, для якого цей ключ був створений
Параметри
Відкритий ключ суб'єкта
Унікальний ідентифікатор СА
Унікальний ідентифікатор суб'єкта
Розширення
Підпис, створений закритим ключем СА для всіх полів сертифіката	Підпис охоплює всі інші поля сертифіката й складається з хеш-коду інших полів, зашифрованого закритим ключем СА

Тепер припустимо, що А одержав сертифікат від уповноваженого органа Х1, і В одержав сертифікат від уповноваженого органа Х2. Якщо А не знає безпечним способом відкритий ключ Х2, то сертифікат В, отриманий від Х2, для нього марний. А може прочитати сертифікат В, але не в змозі перевірити підпис. Проте, якщо два САs можуть безпечно обмінюватися своїми відкритими ключами, можлива наступна процедура для одержання А відкритого ключа В.

1. А одержує з директорії сертифікат Х₂, підписаний Х₁. Так як А знає відкритий ключ Х₁ надійним способом, А може одержати відкритий ключ Х₂ з даного сертифіката й перевірити його за допомогою підпису Х₁ у сертифікаті.

2. Потім А вертається назад у директорію й одержує сертифікат В, підписаний Х². Так як А тепер має відкритий ключ Х² надійним способом, А може перевірити підпис і безпечно одержати відкритий ключ В.

Для одержання відкритого ключа В А використовує ланцюжок сертифікатів. У наведеній вище нотації цей ланцюжок виглядає в такий спосіб:

Х₁ << Х² >> Х² << B >>

Аналогічно В може одержати відкритий ключ А с допомогою такого ж ланцюжка:

Х² << Х¹ >> Х¹ << А >>

Дана схема не обов'язково обмежена ланцюжком із двох сертифікатів. Для одержання ланцюжка може використовуватися шлях CАs довільної довжини. Ланцюжок, що містить N елементів, виглядає в такий спосіб:

Х¹ << Х² >> Х² << Х³ >> . . . Х^N << B >>

У цьому випадку кожна пара САs у ланцюжку (Хⁱ , Хⁱ⁺¹) повинна створити сертифікати друг для друга.

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