16.2 (6.2.2) Формати сертифікату відкритого ключа згідно дсту itu-t Rec. X.509 | iso/iec 9594-8.
Як у практичному, так і в теоретичному плані вирішення вказаних задач безпосередньо пов’язане з рекомендаціями Х.509 [13, 14] Міжнародного союзу телекомунікації (ITU — International Telecommunication Union). Ці рекомендації є частиною рекомендацій серії Х.500, що визначають стандарт служби каталогів. Каталог, по суті, є сервером або розподіленою системою серверів, що підтримують базу даних з інформацією про користувачів [13]. У цій інформації міститься відповідність імен користувачів та їхніх мережних адрес, а також інші атрибути користувачів.
У цілому документ Х.509 визначає каркас схеми надання послуг автентифікації каталогом Х.500 своїм користувачам. Цей каталог може служити сховищем сертифікатів відкритих ключів, що обговорювались. Кожен сертифікат містить відкритий ключ користувача й підписується за допомогою секретного ключа надійного центру сертифікації. Окрім того, Х.509 визначає альтернативні протоколи автентифікації, що будуються на використанні сертифікатів відкритих ключів. Стандарт Х.509 виявляється важливим через те, що структура сертифікатів і протоколів автентифікації, обумовлених у Х.509, використовується в багатьох випадках. Наприклад, формат сертифіката Х.509 прийнятий у протоколах S/MIME, IP Security, SET [51, 63, 7] тощо.
Стандарт Х.509 з’явився в 1988 році. Пізніше він був переглянутий, і в ньому були виправлені деякі недоліки захисту, що відображено в [51, 7]; виправлені рекомендації були опубліковані в другі версії в 1993 році. Проект третьої версії з’явився в 1995 році. Нині чиною, у тому числі в Україні, є версія ДСТУ ITU-T Rec. X.509 | ISO/IEC 9594-8»Основні положення сертифікації ключів та сертифікації атрибутів». Рекомендації цього стандарту (у подальшому рекомендації Х.509) базуються на використанні методів криптографії з відкритим ключем і цифровими підписами. Стандарт не змушує використовувати конкретний алгоритм. Схема цифрового підпису припускає використання функції гешування. Знову ж таки, стандарт не обумовлює наявності конкретного алгоритму гешування. Рекомендації 1988 року включали опис алгоритму гешування, що рекомендується, але згодом з’ясувалося, що цей алгоритм ненадійний, і тому в рекомендації 1993 року він не ввійшов.
З 1 квітня 2007 року ISO/IEC 9594-8 | ITU-T Rec. X.509 прийнятий в Україні як національний стандарт та визначений як ДСТУ ISO/IEC 9594-8:2006»Інформаційні технології – Взаємодія відкритих систем – Каталог. Частина 8. Основні положення щодо сертифікації відкритих ключів та атрибутів». Наказ Держспоживстандарту від 26.12.2006 № 372.
Сертифікати
Головним елементом схеми Х.509 є сертифікати відкритих ключів, що зв’язуються з кожним користувачем. Передбачається, що ці сертифікати користувача видаються деяким надійним центром сертифікації (СА — Certification Authority) і розміщаються в каталозі або центром сертифікації, або користувачем. Сервер каталогів безпосередньо не відповідає за створення відкритих ключів або функції сертифікації; а просто надає легко доступне користувачам місце одержання сертифікатів.
Згідно ДСТУ ITU-T Rec. X.509 | ISO/IEC 9594-8 [13, 14] допускається існування трьох типів сертифікатів – безпосередньо сертифіката, сертифіката дворазового застосування та сертифіката шифрування. Розглянемо їх визначення згідно з наведеним у [13].
Сертифікат являє собою цифрове зображення інформації, яке щонайменше:
- ідентифікує вповноважений орган видачі сертифіката;
- містить імена або ідентифікатори його абонента;
- містить відкритий ключ ЕЦП абонента;
- вказує на його операційний період, тобто період дійсності;
- у цифровій формі підписується центром сертифікації ключів, що видає його, з використанням особистого ключа цього центру.
Сертифікат дворазового використання – сертифікат, призначений для застосування як при наданні послуги ЕЦП так і послуги направленого шифрування даних. Такий сертифікат містить два відкритих ключі – перевірки ЕЦП та направленого зашифрування.
Сертифікат шифрування – сертифікат, що містить відкритий ключ, який використовується для направленого шифрування електронних повідомлень, файлів, документів або передачі даних, або для встановлення чи обміну ключів сеансу для таких самих цілей.
Головним елементом схеми Х.509 є сертифікати відкритих ключів, що зв'язуються з кожним користувачем. Передбачається, що ці сертифікати користувача видаються деяким надійним центром сертифікації (СА — Certification Authority) і розміщаються в каталозі або центром сертифікації, або користувачем. Сервер каталогів безпосередньо не відповідає за створення відкритих ключів або функції сертифікації; а просто надає легко доступне користувачам місце одержання сертифікатів.
На мал. 16.1 показаний загальний формат сертифіката, що включає наступні елементи.
■ Версія. Указує версію формату сертифіката; за замовчуванням вибирається версія 1. При наявності унікального ідентифікатора ініціатора (Initiator Unique Identifier) або унікального ідентифікатора суб'єкта (Subject Unique Identifier) значенням версії повинне бути 2. Якщо мається одне або кілька розширень, повинна бути зазначена версія 3.
Порядковий номер. Ціле значення, унікальне для даного центра, сертифікації, зв'язується однозначно з даним сертифікатом.
Ідентифікатор алгоритму підпису. Алгоритм, що служить для створення підпису сертифіката, разом із усіма необхідними параметрами. Через те, що ця інформація дублюється в полі підпису наприкінці посвідчення, дане поле виявляється не занадто корисним.
Ім'я об'єкта, що видав сертифікат. Ім'я за стандартом Х.500 центра сертифікації, що створили та підписали сертифікат.
Термін дії. Включає дві дати: початку і закінчення терміну дії сертифіката.
Ім'я суб'єкта. Ім'я користувача, якому направляється сертифікат, тобто даний сертифікат засвідчує відкритий ключ суб'єкта, якому належить відповідний особистий ключ.
Інформація про відкритий ключ суб'єкта. Відкритий ключ суб'єкта плюс ідентифікатор алгоритму, з яким повинний використовуватися цей ключ, а також усі необхідні параметри.
Унікальний ідентифікатор об'єкта, що видав сертифікат. Необов'язковий рядок бітів, використовувана для однозначної ідентифікації центра сертифікації, що видали сертифікат, у випадку, коли ім'я Х.500 потрібно використовувати для різних об'єктів.
Унікальний ідентифікатор суб'єкта. Необов'язковий рядок бітів, що служить для однозначної ідентифікації суб'єкта у випадку, коли ім'я Х.500 потрібно використовувати для різних об'єктів.
Розширення. Одне або більше полів розширення. Розширення були додані у версії 3 і розглядаються в цьому розділі нижче.
Підпис. Охоплює всі інші поля сертифіката, містить геш-код інших полів, шифрований за допомогою особистого ключа центра сертифікації. Це поле включає й ідентифікатор алгоритму підпису.
Поля унікальних ідентифікаторів були включені у версію 2, щоб забезпечити можливість багаторазового застосування імен суб'єкта і/або об'єкта, що видав сертифікат. Ці поля використовуються рідко.
Для визначення сертифіката у стандарті прийнята наступна формула:
СА « А » = СА {V, SN, AI, СА, ТА, А, Ар},
де
Y « X » - посвідчення користувача X, видане центром сертифікації Y,
Y{I} - підпис I об'єктом Y. Він складається з I з доданим шифрованим геш-кодом.
(а) Сертифікат Х.509 (б) Параметри відкликання сертифіката
Рис. 1. Формати Х.509
Центр сертифікації підписує сертифікат за допомогою свого особистого ключа. Якщо відповідний відкритий ключ відомий користувачеві, то він може перевірити, що підписаний центром сертифікації сертифікат є дійсним. Це типова схема використання цифрового підпису.
Одержання сертифіката користувача
Сертифікат користувача, що генерується центром сертифікації, має наступні характеристики.
Будь-який користувач, що має відкритий ключ центра сертифікації, може відновити сертифікований відкритий ключ користувача.
Ніхто, крім уповноваженого центра, не може змінити сертифікат без того, щоб це було виявлено.
Оскільки сертифікати фальсифікувати не можна, вони можуть бути розміщені в каталозі без застосування спеціальних засобів захисту.
Якщо всі користувачі звертаються до того самого центра сертифікації, це вказує на загальну довіру даному центрові сертифікації. Усі сертифікати користувача можуть розміщатися в одному каталозі, доступному всім користувачам. Крім того, користувач може передати свій сертифікат безпосередньо іншому користувачеві. У будь-якому випадку, якщо В має сертифікат А, те В може бути упевнений у тім, що повідомлення, що він шифрує відкритим ключем А, будуть захищені від прочитання і що повідомлення, підписані особистим ключем А, захищені від фальсифікації.
У великому співтоваристві користувачів звертання всіх користувачів до того самого центра сертифікації може бути практично неприйнятно. Оскільки сертифікати підписуються центром сертифікації, кожен користувач повинний мати власний екземпляр відкритого ключа центра сертифікації, щоб перевіряти підписи. Цей відкритий ключ повинний бути доставлений кожному користувачеві абсолютно захищеним способом (що забезпечує цілісність і автентичність), щоб користувач мав повну впевненість у сертифікатах, що надходять. Таким чином, у випадку великого числа користувачів може виявитися більш зручним мати ряд центрів сертифікації, кожний з яких повинний буде захищеним способом доставити відкритий ключ деякої частини користувачів.
Тепер припустимо, що А одержує сертифікат від уповноваженого центра сертифікації X1 а В — від X2. Якщо користувачеві А не був наданий відкритий ключ Х2, то сертифікат Y, виданий центром сертифікації Х2, виявляється для А марним. Користувач А може прочитати сертифікат Y, але не може перевірити підпис. Однак, якщо два центри сертифікації по якій-небудь захищеній схемі обмінялися своїми відкритими ключами, що випливає процедура дає можливість А одержати відкритий ключ В.
Користувач А одержує з каталогу сертифікат Х2, підписаний X1. Оскільки А с упевненістю знає відкритий ключ Х1, з отриманого сертифіката А може витягти відкритий ключ Х2 і перевірити його за допомогою підпису, що була створена X1 для цього сертифіката.
Потім А знову звертається до каталогу й одержує сертифікат Y, підписаний Х2. Оскільки тепер А має екземпляр відкритого ключа X2, А може перевірити підпис і одержати відкритий ключ В.
Користувач А використовував ланцюжок сертифікатів, щоб одержати відкритий ключ В. У позначеннях Х.509 цей ланцюжок записується у виді
X1 « Х2 » X2 « Y » .
Точно так само В може одержати відкритий ключ А, але по зворотному ланцюжку:
Х2 « X1 » X1 « А » .
Ця схема необов'язково повинна обмежуватися на випадок ланцюжка з двох сертифікатів. У створенні ланцюжка може брати участь довільне число центрів сертифікації. Ланцюжок з N елементів буде мати такий вигляд:
X1 « Х2 » Х2 « X3 » ... ХN « В » .
У цьому випадку парa центрів сертифікації в кожній ланці (Xi Хi+1) повинна мати вже готові сертифікати один одного.
Усі ці сертифікати центрів сертифікації повинні розміщатися в каталозі, а користувачеві необхідно знати, як вони з'єднані, щоб проїхати по підходящому маршруті до потрібного сертифіката відкритого ключа іншого користувача. Стандарт Х.509 пропонує, щоб центри сертифікації підпорядковувались ієрархії так, щоб шлях при цьому виявлявся прямим.
На рис.16. 2, узятому з документації Х.509, показаний приклад такої ієрархії. З'єднані окружності позначають ієрархічно зв'язані центри сертифікації, а в зазначених поруч прямокутних блоках приводяться сертифікати, що підтримуються в каталозі відповідного центра сертифікації. Каталог центра сертифікації включає два типи сертифікатів.
Прямі сертифікати. Сертифікати X, видані іншими центрами сертифікації.
Зворотні сертифікати. Сертифікати, видані X для сертифікації інших центрів сертифікації.
У даному прикладі користувач А може запросити наступні сертифікати з каталогу, щоб побудувати сертифікаційний маршрут до В:
X « W » W « V » V « Y » Y « Z » Z « В » .
Коли користувач А одержить ці сертифікати, він зможе розгорнути сертифікати по маршруту один за іншим і відновити надійний екземпляр відкритого ключа В. Використовуючи цей відкритий ключ, А зможе послати В шифровані повідомлення. Якщо ж А знадобиться одержувати шифровані повідомлення від В або ж підписувати повідомлення, що посилаються адресатові В, то В буде потрібно відкритий ключ А, що може бути отриманий по наступному ланцюжку сертифікатів:
Рис.16.2. Ієрархія Х.509: гіпотетичний приклад
Z « Y » Y « V » V « W » W « X » X « А ».
Користувач В може одержати цей набір сертифікатів з каталогу, або А може включити такий набір сертифікатів у своє вихідне повідомлення для В.
Відкликання сертифікатів
Згадаєте з мал. 11.3, що кожен сертифікат включає інформацію про термін його дії, що багато в чому подібно кредитній картці. Звичайно новий сертифікат видається безпосередньо перед закінченням терміну дії старого. Крім того, у деяких ситуаціях бажано мати можливість скасувати дію сертифіката до того, як термін його дії мине, по одній з наступних причин.
Секретний ключ користувача виявляється скомпрометованим.
Користувач більше не сертифікується даним центром сертифікації.
Сертифікат даного центра сертифікації виявляється скомпрометованим.
Кожен центр серифікації повинний підтримувати список, у якому указуються усі відкликані, але, ті що не вичерпали термін своєї дії сертифікати, видані даним центром сертифікації, включаючи як сертифікати, видані користувачам, так і сертифікати, видані іншим центрам сертифікації. Ці списки повинні розміщатися ще й у каталозі.
Будь-який список відкликаних сертифікатів (CRL — Certificate Revocation List), розташовуваний у каталозі, підписується центром сертифікації і включає ім'я такого центра (див. мал. 11.3 (б)), дату створення списку, дату виходу наступної версії CRL і відповідний запис для кожного відкликаного сертифіката. Будь-який такий запис складається з порядкового номера сертифіката і дати відкликання цього сертифіката. Через те, що порядкові номери сертифікатів унікальні усередині даного центра сертифікації, порядкового номера виявляється досить для того, щоб розпізнати сертифікат.
Коли користувач одержує сертифікат у повідомленні, користувач повинний з'ясувати, чи не був цей сертифікат відкликаний. Користувач може перевіряти це по каталогу щоразу, коли одержує сертифікат. Щоб уникнути затримок (і можливих додаткових витрат), пов'язаних з пошуком інформації в каталозі, цілком імовірно, що користувач зволіє використовувати локальний кэш для збереження сертифікатів і списків відкликаних сертифікатів.