Додатки сертифіката

До курсу включені відомості, необхідні фахівцям у галузі інформаційної безпеки. Розглядається технологія інфраструктур відкритих ключів (Public Key Infrastructure – PKI), яка дозволяє використовувати сервіси шифрування та цифрового підпису відповідно до широкого кола додатків, що функціонують у середовищі відкритих ключів. Технологія PKI вважається єдиною, що дозволяє застосовувати методи підтвердження цифрової ідентичності під час роботи у відкритих мережах.

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

Інфраструктури відкритих ключів

Додатки сертифіката

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

Опціональне полеExtensions(доповнення) з'являється у сертифікатах третьої версії. Кожен додатокскладається з ідентифікатора типу доповненняExtension identifier,ознака критичностіCriticality flagі власне значення доповненняExtension value. Ідентифікатор типу доповнення визначає формат і семантику значення доповнення.Ознака критичностіповідомляє додатку, що використовує даний сертифікат, чи є істотною інформація про призначення сертифіката і чи може програма ігнорувати даний тип доповнення. Якщо додаток задано як критичний, а програма не розпізнає цей тип доповнення, то сертифікат не повинен використовуватися програмою. Програма може ігнорувати нерозпізнане некритичне доповнення та використовувати сертифікат.

* основні обмеження (Basic Constraints);

* призначення ключа (Key Usage);

* розширене призначення ключа (Extended Key Usage);

* політики застосування сертифікату (Certificates Policies,Policy Mappings,Policy Constraints);

* обмеження на імена (Name Constraints).

Доінформаційних доповненьналежать:

* ідентифікатори ключів (Subject Key Identifier,Authority Key Identifier);

* альтернативні імена (Subject Alternative Name,Issuer Alternative Name);

* пункт розповсюдження списку анульованих сертифікатів (CRL Distribution Point,Issuing Distribution Point);

* спосіб доступу до інформації УЦ (Authority Access Info).

Документ RFC 3280 Certificate & CRL Profile поки що не рекомендує використовувати доповненняSubject Directory Attributes, яке призначене для доставки будь-яких значень атрибутів каталогу X.500, що характеризуютьсуб'єкт даногосертифіката. Разом з цим стандарт X.509 дозволяє вводити будь-які інші доповнення, необхідність яких визначається їх використанням у конкретній системі (наприклад, у системіSET).

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

ДодатокKey Usage(призначення ключа) відображає області застосування секретного ключа, що відповідає вказаному всертифікаті відкритого ключа. У однойменній графі (таблиці 6.1) перелічені можливі сфери застосування ключа.

Користувачі також можуть володіти кількома парами ключів або кількома сертифікатами для одного ключа. ДодатокSubject Key Identifier(ідентифікатор ключа суб'єкта) використовується для розрізнення ключів підпису в сертифікатах одного і того ж власника.

ДодатокCRL Distribution Point(пункт поширення САС) визначає уніфікований ідентифікатор ресурсу (Uniform Resource Identifier - URI) для вказівки місцезнаходження списку анульованих сертифікатів, тобто визначає пункт поширення САС.

Організації можуть підтримувати широке коло програм, що використовують PKI. Деякі сертифікати бувають надійнішими за інші залежно від процедур їх випуску або типів криптографічних модулів користувачів. Різні організації (компанії чи урядові агентства) використовують різні політики застосування сертифікатів, користувачі у своїй який завжди здатні їх розрізнити, але за ухваленні рішення можуть орієнтуватися доповненняCertificate Policies(політики застосування сертифікату). Це доповнення містить абсолютно унікальний ідентифікатор об'єкта (Object Identifier - OID), що характеризує політику застосування сертифікатів, відповідно до якої було випущено цей сертифікат, та призначення сертифіката.Ознака критичностіу поліCertificate Policiesобмежує використання сертифіката однієї з політик, що ідентифікуються - тим самим УЦ декларує, що випущений ним сертифікат повинен застосовуватися відповідно до положень однієї із зазначених у списку політик. Це може захистити УЦ від матеріальних претензій сторони, що довіряє, яка використовувала сертифікат не за тим призначенням або не тим способом, які встановлені політикою застосування сертифікатів, зазначеною в сертифікаті.

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

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

Приклад 6.1. Нехай корпорація ACE укладає угоду з корпорацією ABC про крос-сертифікацію з метою захисту електронного обміну даними [167]. Кожна компанія має свою безпекову політику фінансових транзакцій. Очевидно, що просто генерація крос-сертифікатів не забезпечить необхідної функціональної сумісності, тому що в кожній компанії конфігурування фінансових додатків та випуск сертифікатів для службовців здійснюються відповідно до своєї політики. Одне з можливих рішень – переконфігурування всіх фінансових додатків та повторний випуск усіх сертифікатів відповідно до вимог обох політик. Іншим, більш простим рішенням може бути використання доповнення Policy Mappings . Якщо поле цього доповнення включає крос-сертифікат, випущений УЦ компанії ACE для УЦ компанії ABC, політика безпеки фінансових транзакцій компанії ABC вважається еквівалентною однойменній політиці компанії ACE.

Випуск сертифіката одним УЦ для іншого є підтвердженням надійності останнього сертифіката. Існує три основні способи підтвердити надійність деякої множини сертифікатів. По-перше, це можна зробити за допомогою доповненняBasic Constraints(описаного вище). Другий спосіб полягає в описі безлічі сертифікатів на підставі імен, зазначених у полі імені суб'єкта або альтернативного імені суб'єкта, у додаткуName Constraints(обмеження на імена). Це доповнення може використовуватися для завдання множини допустимих імен або множини недозволених імен.

По-третє, для опису безлічі сертифікатів на підставі обмежень політик можна використовувати додатокPolicy Constraints(обмеження політик). Це доповнення використовується тількиу сертифікатах УЦ та задає перевірку шляху до політики, запитуючи ідентифікатори політик та (або) забороняючи завдання відповідності політик >[2]. Якщо УЦ видає універсально надійні сертифікати, то не потрібно явно вказувати в них політики застосування сертифікатів. Якщо сертифікати УЦ, визнаного надійним у певному домені, використовуються поза цим доменом, то потрібна явна вказівка ​​політики застосування в усіх сертифікатах шляху сертифікації. За допомогою доповненняPolicy Constraintsможна оголосити неправомірним доповненняPolicy Mappingsу тому випадку, коли сертифікація виходить за межі певного домену. Це актуально для контролю ризиків, що виникають через "транзитивну" довіру, коли доменAдовіряє доменуВ, доменВдовіряє доменуС>, але доменAне хоче довіряти доменуС. Якщо обмеження політики застосування сертифікатів встановлені, то користувачі не будуть мати справу з сертифікатами, в яких не вказано певних політик або доповненняPolicy Constraintsвзагалі відсутнє.

ДодатокCertificate Policiesможе супроводжуватися специфікатором для зазначення в кожному сертифікаті додаткової інформації, незалежної від політики застосування сертифікатів. Стандарт X.509 жорстко не регламентує призначення та синтаксис цього поля. Типи специфікаторів політики можуть бути зареєстровані будь-якою організацією.

Стандартно використовуються такі специфікатори політики:

* б)User Noticeмістить покажчик на повідомлення та/або текст повідомлення, яке має з'являтися на екрані дисплея користувача сертифіката (включаючи передплатників та довіряючі сторони) до використання сертифіката та інформувати про політику застосування цього сертифіката.

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

---