Все_лекции_Горбенко

–повинні бути визначені у ЧТЗ на КЗЗ комплексу.

5.1.8 Додаткові вимоги

1 Загальні вимоги до засобів КЗІ

– 3.8.1.1 В програмних та апаратних засобах комплексу повинні використовуватися такі криптографічні алгоритми та протоколи:

шифрування за ГОСТ 28147-89 (режим простої заміни, режим гамування та режим вироблення імітовставки);

ЕЦП за ДСТУ 4145-2002;

гешування за ГОСТ 34.311-95; протокол розподілу ключових даних Діффі-Гелмана в групі точок

еліптичної кривої.

–3.8.1.2 Методика розподілу ключових даних на основі протоколу Діффі- Гелмана в групі точок еліптичної кривої повинна бути погоджена з ДСТСЗІ СБ України у встановленому порядку.

–3.8.1.3 У комплексі повинні бути виділені дві підгрупи ключових даних:

1)службові ключові дані;

2)ключові дані користувачів.

–3.8.1.4 До складу службових відносяться:

особистий ключ та сертифікат відкритого ключа ЦСК; особисті ключі та сертифікати адміністраторів реєстрації та віддалених

адміністраторів реєстрації;

–3.8.1.5 Особистий ключ ЦСК повинен зберігатися та застосовуватися тільки у апаратному модулі сертифікації, що входить до складу сервера ЦСК.

–3.8.1.6 Особистий ключ ЦСК повинен використовуватися для формування ЕЦП сертифікатів, списків відкликаних сертифікатів, відміток часу, інформації про статус сертифікатів, а також для запитів в інші ЦСК.

–3.8.1.7 Сертифікат відкритого ключа ЦСК повинен використовуватися для перевірки ЕЦП зазначеної у п. 3.8.1.6 інформації.

–3.8.1.8 Особисті ключі адміністраторів реєстрації та віддалених адміністраторів реєстрації призначені для формування ЕЦП запитів на формування сертифікатів, а також запитів на блокування, поновлення та скасування, а сертифікати – для перевірки ЕЦП від вказаних типів даних.

–3.8.1.9 Ключі віддалених адміністраторів реєстрації призначені також для шифрування даних, що передаються між РС віддаленого адміністратора реєстрації та ЦСК (сервером ЦСК).

–3.8.1.10 До ключових даних користувачів відносяться особисті ключі та сертифікати користувачів.

–3.8.1.11 Особисті ключі повинні захищатися на паролях шляхом вироблення імітовставки за ГОСТ 28147-89 та зашифрування в режимі простої заміни ГОСТ 28147-89 на ключах, які отримані шляхом гешування строки пароля за ГОСТ 34.311-95. Паролі повинні відповідати наступним вимогам:

алфавіт символів пароля – англійські букви “a” – “z”, “A” – “Z”, цифри “0” – “9” та символи “-”, “+” (потужність алфавіту – 26, 6 біт/символ);

довжина пароля – мінімальна 8, максимальна 42 символи (48-252 біт, потужність системи паролювання 246-2252);

обмеження до появлення символів в паролі – не допускається введення більш ніж 2-ох символів, що розташовані поруч на розкладці клавіатури РС чи сервера, не допускається введення більш ніж 2-ох однакових символів на всій довжині пароля.

–3.8.1.12 Параметри криптографічних алгоритмів та протоколів

(параметри еліптичних кривих та довгострокові ключові елементи (ДКЕ) повинні постачатися відповідно до вимог ДСТСЗІ СБ України.

– 3.8.1.13 В якості носіїв ключової інформації повинні використовуватися:

з’ємні диски (гнучкі диски 3,5”, електронні диски із внутрішнім ПЗП);

компакт-диски (CD-R, CD-RW, DVD-R або DVD-RW);

електронні ключі Aladdin eToken R2, PRO та інші.

– 3.8.1.14 Формати ключових даних та іншої спеціальної інформації повинні бути визначені в ході розробки та відповідати вимогам міжнародних стандартів, рекомендацій та діючих нормативних документів:

X.509 (ISO/IEC 9594-8:2002) та дод. 1,3 до правил посиленої сертифікації [1] – формати сертифікатів та списків відкликаних сертифікатів;

PKCS#7 та RFC 3369 – формати захищених даних (даних з ЕЦП та зашифрованих даних);

PKCS#8 – формати особистих ключів;

PKCS#10 – формати запитів на сертифікацію (формування сертифікатів) та скасування сертифікатів;

RFC 2560 – формати запитів на отримання інформації про статус сертифіката та інформації про статус;

RFC 3161 (ISO/IEC 18014) – формати запитів на формування відміток часу та відміток часу.

– 3.8.1.15 Формати даних повинні бути наведені у складі конструкторської або програмної документації на складові частини комплексу або погоджені у встановленому порядку з ДСТСЗІ СБ України в ході розробки комплексу.

5.2 ПОБУДОВА ТА АНАЛІЗ ШЛЯХІВ СЕРТИФІКАЦІЇ ІВК (ЕЦП)

5.2.1 Поняття та застосування сертифікатів відкритих ключів.

Головним елементом схеми Х.509 є сертифікати відкритих ключів, що зв'язуються з кожним користувачем. Передбачається, що ці сертифікати користувача видаються деяким надійним центром сертифікації (СА — Certification Authority) і розміщаються в каталозі або центром сертифікації, або користувачем. Сервер каталогів безпосередньо не відповідає за створення відкритих ключів або функції сертифікації; а просто надає легко доступне користувачам місце одержання сертифікатів.

На мал. 5.2.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 з доданим шифрованим геш-кодом.

Сертифікат користувача, що генерується центром сертифікації, має наступні характеристики.

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

■Ніхто, крім уповноваженого центра, не може змінити сертифікат без того, щоб це не було виявлено.

Оскільки сертифікати фальсифікувати не можна, вони можуть бути розміщені в каталозі без застосування спеціальних засобів захисту.

Якщо всі користувачі звертаються до того самого центра сертифікації, це вказує на загальну довіру даному центрові сертифікації. Усі сертифікати користувача можуть розміщатися в одному каталозі,

доступному всім користувачам. Крім того, користувач може передати

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

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

Тепер припустимо, що А одержує сертифікат від уповноваженого центра сертифікації X1 а В — від X2. Якщо користувачеві А не був наданий відкритий ключ Х2, то сертифікат Y, виданий центром сертифікації Х2, виявляється для А марним. Користувач А може прочитати сертифікат Y, але не може перевірити підпис. Однак, якщо два центри сертифікації по якій-небудь захищеній схемі обмінялися своїми відкритими ключами, що випливає процедура дає можливість А одержати відкритий ключ В.

1.Користувач А одержує з каталогу сертифікат Х2, підписаний X1. Оскільки А с упевненістю знає відкритий ключ Х1, з отриманого сертифіката

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

2.Потім А знову звертається до каталогу й одержує сертифікат Y,

підписаний Х2. Оскільки тепер А має екземпляр відкритого ключа X2, А може перевірити підпис і одержати відкритий ключ В.

Користувач А використовував ланцюжок сертифікатів, щоб одержати відкритий ключ В. У позначеннях Х.509 цей ланцюжок записується у виді

X1 « Х2 » X2 « Y » .

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

Х2 « X1 » X1 « А » .

Ця схема необов'язково повинна обмежуватися на випадок ланцюжка з двох сертифікатів. У створенні ланцюжка може брати участь довільне число центрів сертифікації. Ланцюжок з N елементів буде мати такий вигляд:

X1 « Х2 » Х2 « X3 » ... ХN « В » .

У цьому випадку парa центрів сертифікації в кожній ланці (Xi Хi+1) повинна мати вже готові сертифікати друг для друга.

Усі ці сертифікати центрів сертифікації повинні розміщатися в каталозі, а користувачеві необхідно знати, як вони з'єднані, щоб проїхати по підходящому маршруті до потрібного сертифіката відкритого ключа іншого користувача. Стандарт Х.509 пропонує, щоб центри сертифікації підпорядковувались ієрархії так, щоб шлях при цьому виявлявся прямим.

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

■Прямі сертифікати. Сертифікати X, видані іншими центрами сертифікації.

■Зворотні сертифікати. Сертифікати, видані X для сертифікації інших центрів сертифікаці

Уданому прикладі користувач А може запросити наступні сертифікати з каталогу, щоб побудувати сертифікаційний маршрут до В:

X « W » W « V » V « Y » Y « Z » Z « В » .

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

U<<V>

>

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

Відкликання сертифікатів

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

X<<C>> X<<A> Z<<B>

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

1.Секретний ключ користувача виявляється скомпрометованим.

2.Користувач більше не сертифікується даним центром сертифікації.

3.Сертифікат даного центра сертифікації виявляється скомпрометованим.

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

Будь-який список відкликаних сертифікатів (CRL — Certificate Revocation List), розташовуваний у каталозі, підписується центром сертифікації і включає ім'я такого центра (див. мал. 11.3 (б)), дату створення списку, дату виходу наступної версії CRL і відповідний запис для кожного відкликаного сертифіката. Будь-який такий запис складається з порядкового номера сертифіката і дати відкликання цього сертифіката. Через те, що порядкові номери сертифікатів унікальні усередині даного центра сертифікації, порядкового номера виявляється досить для того, щоб розпізнати сертифікат.

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

5.3. ПРИНЦИПИ ПОБУДУВАННЯ СИСТЕМИ ІВК ДЛЯ

МАШИНОЧИТАЄМИХ ДОКУМЕНТІВ (ПАСПОРТІВ)

– Інфраструктура відкритих ключів (далі – інфраструктура) створюється, як складова частина системи виготовлення та обігу електронних біометричних паспортів (далі – електронних паспортів) у відповідності до:

–технічних вимог ICAO “Machine Readable Travel Documents Technical Report, PKI for Machine Readable Travel Documents Offering ICC Read-Only Access, Version - 1.1, Date - October 01, 2004, published by authority of the secretary general, International Civil Aviation Organization” (ІВК для машинозчитуваних проїзних документів з безконтактним електронним чипом з доступом на читання, версія 1.1, видана 01.10.2004 р. з дозволу генерального секретаріату ICAO).

–технічних вимог BSI “Technical Guideline TR-03110. Advanced Security Mechanisms for Machine Readable Travel Documents – Extended Access Control (EAC), Version 1.11, 2008” (Технічні вимоги Федерального відомства Німеччини з безпеки в інформаційних технологіях TR-03110. Удосконалені механізми захисту для машинозчитуваних проїзних документів – EAC, версія 1.11, 2008 р.);

–державних нормативних документів у сфері криптографічного та технічного захисту інформації.

5.3.1Призначення та загальні вимоги до комплексу

–1 Призначення комплексу: реалізація регламентних процедур та механізмів функціонування інфраструктури відкритих ключів електронних паспортів (обслуговування сертифікатів відкритих ключів складових частин інфраструктури) та надання засобів КЗІ для використання у складових частинах інфраструктури під час виготовлення та перевірки електронних паспортів.

–2 Максимальний гриф інформації, що може оброблятися у комплексі – конфіденційна, що не є власністю держави.

–3 Комплекс в цілому відноситься до типу апаратно-програмних комплексів КЗІ виду “Б”, категорії “К” та “П”, класу Б2. Окремі засоби, що входять до його складу, відносяться до типів апаратно-програмних та програмних засобів КЗІ видів “Б” та “В”, категорії “К”, “Ш”, “П”, “Р”, класу Б2.

–4 Технічні засоби складових частин комплексу повинні бути об’єднані у окремі ЛОМ з використанням внутрішніх комунікаційних мереж та об’єднані у єдину систему з використанням зовнішньої комунікаційної мережі.

–5 Комплекс та його складові частини повинні відповідати технічним вимогам Міжнародної організації цивільної авіації (ICAO) та правилам посиленої сертифікації.

5.3.2 Вимоги до комплексу

1 Вимоги до функцій та складу комплексу

–1) Комплекс повинен забезпечити реалізацію регламентних процедур та механізмів функціонування інфраструктури відкритих ключів електронних паспортів щодо:

–обслуговування сертифікатів відкритих ключів (далі – сертифікатів) складових частин інфраструктури;

–надання засобів КЗІ для використання у складових частинах інфраструктури під час виготовлення та перевірки електронних паспортів.

–2) Для забезпечення функціонування комплекс також повинен виконувати наступні функції:

забезпечення адміністрування окремих апаратних та програмних засобів, що включає:

–налагодження параметрів засобів комплексу;

–діагностування роботи засобів;

–моніторинг стану засобів комплексу;

ведення журналів реєстрації окремими технічними засобами комплексу, що включає:

–запис реєстраційної інформації засобами комплексу до журналів реєстрації;

–збір та аналіз реєстраційної інформації у журналах;

9)забезпечення захисту інформації, що обробляється у комплексі, від НСД.

–2 Функціональна схема комплексу наведена на рис. 3.1.