Страница 5: ДСТУ ISO/IEC 11770-1:2009. Інформаційні технології. Методи захисту. Керування ключами. Частина 1. Загальні положення (62145)

иДОДАТОК D

(довідковий)

КЕРУВАННЯ ЖИТТЄВИМ ЦИКЛОМ СЕРТИФІКАТА

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

D.1 Повноважна організація з сертифікування (СА)

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

СА має нести відповідальність за:

1. ідентифікування об'єктів, інформацію про відкритий ключ яких надано для сертифікування;

2. забезпечення якості пари асиметричних ключів, використовуваних для формування сертифіка­та відкритого ключа;

3. захист процесу сертифікування, а також особистого ключа, використовуваного для підписуван­ня інформації щодо відкритого ключа;

4. керування системно-залежними даними, які мають містити інформацію щодо відкритого ключа — порядковий номер сертифіката відкритого ключа, ідентифікатор САтощо;

5. призначення та перевіряння строку дії;

6. оповіщення об'єкта, ідентифікованого інформацією відкритого ключа, що сертифікат відкрито­го ключа видано. Засоби, використані для пересилання цього повідомлення, мають бути незалежни­ми від методу, використаного для пересилання до СА інформації відкритого ключа;

7. забезпечення того, що два різних об'єкти не будуть тотожними і зможуть належним чином роз­пізнаватися;

8. супроводження та видання списків відкликання;

9. внесення до журналу всіх кроків процесу генерування сертифіката відкритого ключа.

Одна СА для видання сертифіката відкритого ключа може сертифікувати інформацію відкритого ключа іншої СА. Отже, автентифікування може містити ланцюг сертифікатів відкритих ключів. Перший сертифікат відкритого ключа в цьому ланцюгу має бути одержаним і автентифікованим деякими спо­собами, відмінними від сертифікатів відкритих ключів.

D.1.1 Асиметрична ключова пара повноважної організації з сертифікування

СА повинен мати засіб безпечного керування ключами, спроможний генерувати асиметричну клю­чову пару для використання цією СА. Процес генерування має забезпечувати непередбачуваність клю­чових даних. Жоден зловмисник не повинен одержувати переваги від знання процесу генерування.

Особистий ключ СА використовують для підписування інформації відкритого ключа об'єкта. Має бути забезпечений високий рівень захисту особистого ключа СА, оскільки володіння ним дало б змо­гу зловмиснику маскуватися під СА і генерувати підроблені сертифікати відкритих ключів. Отже, осо­бистий ключ СА має бути добре захищений під час використання всередині засобу керування ключами. Його треба вводити або виводити із засобу керування ключами захищеним та під контролем самої СА.

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

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

D.2 Процес сертифікування

Цей розділ описує вимоги та процедури, застосовні в процесі сертифікування.

D.2.1 Модель сертифікування відкритого ключа

Цей розділ визначає базову модель сертифікування відкритих ключів. Модель розподіляє основні функції за логічними об’єктами (рисунок D.1):

1. повноважна організація з сертифікування (СА) — об єкт, що несе відповідальністо за серти- фікування інформації відкритого ключа об'єкта — користувача,

2. довідник (ДОВ) — об єкт, що несе відповідальність за надання інтерактивного доступу до серти­фікатів відкритих ключів для оперативного використання їх об’єктами — користувачами,

3. генератор ключів (ГК) — об’єкт, що несе відповідальність за генерування асиметричної ключової пари,

4. повноважний реєстратор (ПР) — об’єкт, що несе відповідальність за забезпечення СА засві­дченими ідентифікаторами користувачів,

5. об’єкт — користувач (А)

Нижче розглянуто відносини між логічними об єктами моделі та відповідні вимоги щодо безпеки стосовно цих відносин Логічні об'єкти можуть бути суміщеними Наприклад А і ГК можна об єднати, якщо об’єкт-користувач сам генерує асиметричну ключову пару, або СА і ГК можна об’єднати якщо СА генерує ключову пару для об’єкта — користувача

Примітка Треба подбати щоб сертифікат згенеровании об єднаними ПР і СА був однаковим із сертифікатом створеним розподіленими різними ПР і СА

Рисунок D 1 — Базова модель сертифікування відкритих ключів

D.2.1.1 Сертифікаційні відносини

Цей розділ надає опис деяких сертифікаційних відносин базової моделі й відповідні вимоги щодо безпеки В окремій системній реалізації не всі відносини мають бути активними Наприклад, завдання ПР, СА і ГК можна об єднувати

А-ГК Об єкт А просить генератора ключів ГК згенерувати асиметричну ключову пару ГК довіре­не генерування асиметричних ключових пар високої якості ГК генерує ключову пару (S_A,V_A) таким чи­ном, що S_A є ключем підписуванням, a V_A є ключем верифікації, і вертає їх А Це пересилання треба виконувати з автентифікуванням і конфіденційно ГК і А мають бути абсолютно впевненими в тому що під час пересилання третя сторона не зможе модифікувати асиметричну ключову пару та прочитати її значення

А-ПР Об'єкт А замовляє реєстрування у повноважного реєстратора ПР Об єкт А повинен подати свою особисту інформацію ПР ПР перевіряє автентичність інформації А і можливо додає деяк^! си­стемно-залежні дані Інфоомацію після цього передають до СА безпечним шляхом

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

Після одержання виданого сертифіката відкритого ключа А верифікує його коректність із викори­станням відкритого ключа верифікації V_CA повноважної організації з сертифікування. Доступ А до цього відкритого ключа верифікації V_CA має бути автентифікованим. Починаючи з цього часу, відкритий ключ А можна розповсюджувати як сертифікат відкритого ключа і використовувати кожному, хто має доступ до відкритого ключа верифікації СА.

Проте, якщо повноважна організація з сертифікування просить ГК згенерувати асиметричну клю­чову пару для об’єкта А, то ключову пару об'єкта А має бути переслано від ГК до А. Вимогами щодо безпеки для пересилання є конфіденційність, цілісність та автентичність. Крім того, СА довірено збе­рігати конфіденційність, цілісність та автентичність усіх асиметричних ключових пар протягом оброб­лення та зберігання. І, нарешті, СА має пересилати до А його особистий ключ, будучи абсолютно впев­неною у тому, що третя сторона не може ні модифікувати, ні прочитати величину, що пересилається.

А-ДОВ Об'єкт А пересилає сертифікат свого відкритого ключа в довідник ДОВ і реєструє його в довіднику. Для реєстрування сертифіката відкритого ключа в довіднику потрібно автентифікування об’єкта та контролювання доступу. Між А і ДОВ має бути узгоджено, хто уповноважений керувати за­писом стосовно цього об'єкта в довіднику. В одних застосунках довідник керує всіма довідниковими записами. В інших — кожний об'єкт X відповідає за керування своїм довідниковим записом.

ПР-СА ПР просить СА сертифікувати інформацію відкритого ключа А. Пересилання інформації відкритого ключа А від ПР до СА треба виконувати з автентифікацією. СА верифікує автентичність інформації відкритого ключа А, можливо, додає системно-залежні дані й потім підписує повну інфор­мацію відкритого ключа, щоб виробити сертифікат відкритого ключа А. СА повідомляє ПР про серти­фікацію.

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

СА-ДОВ СА пересилає вироблені сертифікати відкритих ключів безпосередньо в довідник ДОВ і реєструє їх у довідникові. Для реєстрування сертифікатів відкритих ключів у довіднику потрібно автентифікування об'єкта і контролювання доступу.

D.2.2 Реєстрування

Реєстрування ключа об’єкта охоплює подання об’єктом запиту на сертифікування та його підтвер­дження ПР або СА. У наступних підпунктах наведено вимоги щодо подання об'єктом запиту на серти­фікацію. Запит на сертифікування може містити чи не містити величину відкритого ключа.

D.2.2.1 Подання запиту на сертифікування фізичними особами

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

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

D.2.2.2 Подання юридичною особою запиту на сертифікацію

Приймання запиту на сертифікування повинно базуватися на доставленні інформації запиту на сертифікування врученням її принаймні одним представником об'єкта і:

1. Підписі й печатці (якщо застосовне) на титульному аркуші, якими завірено запит на сертифі­кат відкритого ключа

2. Використанні прийнятної комерційної практики ідентифікування підпису і печатки (якщо застосовне) об єкта

3. Використанні прийнятної комерційної практики ідентифікування представників які доставили інформацію запиту на сертифікування

D.2.3 Взаємовідносини між юридичними особами

У юридичних осіб може виникнути потреба у встановленні договірних відносин з іншими юридич­ними особами Це може бути влаштовано різними способами

1. Службовці компанії мають власні асиметричні ключові пари Юридична особа діє як СА для своїх службовців Транзакцп авторизуються службовцями з використанням їхніх персональних ключів, серти- фікованих СА компанії Одержувачі перевіряють, що джерело сертифіковане компанією, відкритий ключ якої, в свою чергу сертифікований СА вищого рівня ієрархи

2. Службовці компанії не мають власних асиметричних ключових пар Тільки юридична особа має одну або більше асиметричних ключових пар Одержувачі відкритим ключем компанії перевіряють узгодженість транзакцій Одержувачі не повинні обтяжувати себе ієрархією і політикою повноважень компани-джерела

D.2.4 Гэнерування сертифіката

Будь-якому використанню асиметричної ключової пари передує процес генерування сертифіката відкритого ключа

Процес генерування сертифіката має містити такі кроки

1. Перевіряння інформації відкритого ключа для виявлення помилок

2. Прийняття інформації відкритого ключа (вимоги стосовно приймання інформації відкритого клю­ча відповідно до D 2 2)

3. Підготовляння та долучення даних потрібних для керування сертифікатом відкритого ключа СА може генерувати асиметричну(і) ключову(і) пару(и) для об єкта (необов язково)

4. Обчислення підпису для сертифіката відкритого ключа Може містити геш-функцію

5. Запис до журналу аудиту Дії СА щодо генерування сертифіката відкритого ключа мають бути занесені до журналу

Для застосунків із високим ступенем ризику може бути бажаним до (1) вимагати декількох підписів СА на сертифікаті відкритого ключа, які містять підписи, виконані незалежними криптографічними за­собами (з різними особистими ключами), або до (2) вимагати декількох підписів інформації відкритого ключа різними СА

D.2.5 Відновлення/Життєвий цикл

Життєвий цикл сертифіката відкритого ключа зазначено строком дії, встановленим у сертифікаті відкритого ключа або визначено іншим чином політикою керування СА

D.3 Розподілення та використання сертифікатів відкритих ключів

Цей розділ описує вимоги та процедури, застосовні до розподілення та використання сертифікатів відкритих КЛЮЧІВ