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

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

процедури звірення

У процесі перевірки справжності сертифіката для нього виконуються процедури звірення за наступними критеріями: цифровий підпис (digital signature), параметри відносин довіри (trust), тимчасові параметри (time), інформація про анулювання сертифіката (revocation) і параметри формату (formatting). Якщо з'ясовується, що сертифікат не відповідає вимогам хоча б одного з цих критеріїв, то він вважається недійсним. При звіряння цифрового підпису програма перевірки автентичності за допомогою заслуговує на довіру відкритого ключа перевіряє справжність цифрового підпису, доданої в сертифікат органом, що його центром Certificate Authority (CA). Як ключ використовується відкритий ключ видав сертифікат центру CA або іншого центру, що входить в ланцюжок сертифікатів відповідно до ієрархічної моделлю довірчих відносин.

Для перевірки справжності підпису недостатньо просто наявності відкритого ключа, він повинен бути вартим довіри. У інфраструктурах PKI систем Windows Server 2003 і Windows Server 2000 сертифікат і відкритий ключ вартого абсолютного довіри центру CA називаються трастовими якорями (trust anchor), а доступ до них здійснюється через контейнер Trusted Root Certification Authorities сховища сертифікатів клієнта Windows PKI. В процесі звірення параметрів довірчих відносин проводиться аутентифікація сертифіката довірених CA - цю процедуру також називають перевіркою достовірності ланцюжка сертифікатів. При виконанні даної процедури для кожного сертифіката ланцюжка можуть запускатися різні цикли перевірки автентичності. Детальніше процедура перевірки автентичності ланцюжка сертифікатів буде розглянута нижче.

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

Під час виконання процедури звірення терміну дії (revocation check) перевіряється, чи не анульований чи даний сертифікат органом, що його центром CA. У середовищах PKI систем Windows 2003 і Windows Server 2000 реалізована підтримка роботи з абсолютними списками анульованих сертифікатів (complete CRL) та вузлами поширення списків CRL (CRL Distribution Point, CDP). Крім цього, служба Windows 2003 Certificate Services може працювати і зі списками змін (delta CRL). Використовуючи списки CRL, списки змін CRL і вузли CDP, можна забезпечити перевірку терміну дії сертифікатів в автоматичному режимі. Більш детально питання, пов'язані з анулюванням сертифікатів, розглянуті в статті «Процедури анулювання сертифікатів в інфраструктурі Windows PKI» , Опублікованій в журналі Windows IT Pro / RE № 4 за 2006 р

При виконанні процедури звірення параметрів форматування перевіряється, чи відповідає формат сертифіката стандартним вимогам, визначеним в рекомендації X.509, випущеної комітетом International Telecommunications Union Telecom- munication Standardization Sector (ITU-T). При цьому також перевіряється коректність розширень сертифіката, що описують параметри довірчих відносин з регульованим ступенем довіри, таких як базові обмеження, обмеження імен, обмеження політик додатків і обмеження політик видачі. Більш детально ці розширення описані в статті «Принципи довіри PKI» , Опублікованій в Windows IT Pro № 7 за 2006 р Наприклад, велика частина додатків, що працюють з Secure MIME (S / MIME), перевіряє справжність параметра сертифіката subject's name, описаного в Internet Engineering Task Force (IETF) Request for Comments (RFC) 822 (по суті справи, це стандартне ім'я в форматі адрес пошти Internet, скажімо, [email protected]). Для цього значення даного параметра порівнюється з полем адреси відправника в заголовку повідомлення SMTP. У разі S / MIME така перевірка забезпечує захист від можливого запозичення прав (impersonation) і від атак типу man-in-the-middle. При проведенні подібних атак зловмисник зазвичай намагається ототожнити себе з реальним користувачем, щоб отримати доступ до системи або мережі. Подібні типи перевірок виконуються і в більшості реалізацій Secure Sockets Layer (SSL). Протокол SSL перевіряє відповідність параметра subject's RFC 822 name імені, що знаходиться в полі URL того захищеного Web-сайту, до якого звертається клієнт.

Стандартна процедура обробки ланцюжка сертифікатів

Що таке ланцюжок сертифікатів і чому її слід обробляти в процесі перевірки справжності сертифіката? За допомогою побудови ланцюжка можна організувати перевірку справжності всіх сертифікатів, з якими пов'язаний даний сертифікат. Для того щоб розібратися в тому, що являє собою ланцюжок сертифікатів, звернемося до ієрархічної моделі довірчих відносин в інфраструктурі PKI. У даній моделі (яка також обговорювалася в згаданій вище статті «Принципи довіри PKI») ланцюжок сертифікатів кожного користувача складається з сертифікатів всіх центрів CA, які утворюють в межах даної ієрархії шлях від користувача до кореневого (root) центру CA. При використанні ієрархічної моделі довірчих відносин кожен сертифікат містить покажчик на батьківський (або видав сертифікат) центр CA, який зберігається в поле issuer сертифіката X.509. На рис. 1 показаний приклад ланцюжка для призначеного для користувача сертифіката, виданого центром CA при наявності дворівневої ієрархії в інфраструктурі PKI. Рис. 1 ілюструє найпростіший приклад використання параметрів certificate subject (суб'єкт) і certificate issuer (видавець сертифіката). В даному прикладі суб'єктом призначеного для користувача сертифіката є користувач, а видавцем сертифіката - проміжний центр CA. У сертифікаті проміжного центру суб'єктом є сам цей центр, видавцем ж в даному випадку буде кореневої CA. В ієрархічній моделі довірчих відносин кореневої центр CA завжди сам підписує свій сертифікат, тому для свого сертифіката він є як суб'єктом, так і видавцем сертифіката.

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

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

Перевірка справжності ланцюжка сертифікатів.

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

Для ідентифікації сертифіката центру CA під час процедури перевірки справжності ланцюжка використовується розширення Authority Key Identifier (AKI) сертифікату, що перевіряється. В поле AKI міститься інформація наступних типів.

• Ім'я центру, який видав сертифікат і серійний номер сертифіката даного центру. Якщо ця інформація є в поле AKI, тоді програма перевірки автентичності виконує пошук збігається сертифіката, використовуючи поля Serial number і Subject. Даний метод ідентифікації сертифіката називається строгим збігом.
• Ідентифікатор відкритого ключа (KeyID) сертифіката центру, який видав сертифікат, що перевіряється. Якщо ця інформація є в поле AKI, тоді програма перевірки автентичності виконує пошук збігається сертифіката, використовуючи розширення сертифіката Subject Key Identifier (SKI), в якому зберігається унікальний ідентифікатор відкритого ключа сертифіката суб'єкта. Даний метод ідентифікації сертифіката називається збігом ключів.

Якщо в перевіряється сертифікаті поле AKI відсутня, програма перевірки автентичності намагається ідентифікувати сертифікат видав центру CA за допомогою перевірки збігу імені, взятого з поля Issuer сертифікату, що перевіряється, з вмістом поля Subject сертифіката. Даний метод ідентифікації сертифіката називається збігом імен.

У тих випадках коли перевіряється сертифікат недоступний локально, наявні в Windows програмні засоби перевірки автентичності використовують розширення Authority Information Access (AIA), з тим щоб отримати копію сертифіката шляхом його завантаження по мережі з відповідного вузла. Для цього використовується поле AIA, яке містить покажчик на вузол зберігання сертифікатів центрів CA для протоколів FTP, HTTP, Lightweight Directory Access Protocol (LDAP) або покажчик на відповідний файловий ресурс. Якщо поле AIA містить кілька посилань, програмні засоби перевірки автентичності намагаються задіяти всі ці посилання в порядку їх перерахування в даному полі. Всі сертифікати, які завантажуються з використанням поля AIA, кешуються програмою перевірки в профілі користувача PKI на локальному диску (а саме в папці Documents and SettingsusernameLocal SettingsTemporary Internet Files), а також в локальному сховищі сертифікатів користувача.

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

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

Якщо при завантаженні сертифіката використовується Web-інтерфейс центру CA систем Windows 2003 або Windows Server 2000, то в цьому випадку можна вибрати завантаження тільки самого сертифіката або завантаження даного сертифіката спільно з усіма сертифікатами, що утворюють ланцюжок. Можливість завантаження ланцюжка сертифікатів іноді буває дуже корисною, наприклад якщо для роботи використовується переносний комп'ютер. В цьому випадку всі сертифікати ланцюжка будуть доступні для програми перевірки автентичності навіть тоді, коли користувач знаходиться в дорозі.

Обробка ланцюжка списків CTL

Дана процедура є особливим випадком обробки ланцюжків сертифікатів. Список CTL містить завірений перелік сертифікатів, які заслуговують на абсолютного довіри кореневих центрів CA, отже, тут містяться сертифікати центрів CA, підписані ними самими. Формування списку CTL виконується через меню, що випадає контейнера об'єкта групової політики Enterprise Trust Group Policy Object. Доступ до даного контейнера здійснюється послідовним вибором Windows SettingsSecurity SettingsPublic Key Policies. Об'єкти GPO також виконують автоматичне завантаження списків CTL в контейнер Enterprise Trust сховища вмісту сертифікатів. Відзначимо, що контейнер Enterprise Trust не є контейнером трастових якорів - його вміст не вважається заслуговує абсолютної довіри за замовчуванням.

Для того щоб список CTL і його вміст вважалися такими, що заслуговують довіри, сертифікат, за допомогою якого підписувався цей список, повинен бути дійсним. Отже, даний сертифікат повинен повністю задовольняти вимогам перевірки процедурами звірення з усіх розглянутих вище параметрам (цифровий підпис, параметри відносин довіри, тимчасові параметри, інформація про анулювання сертифіката та параметри формату). Гарантією успішної перевірки цифрового підпису служить наявність сертифіката з контейнера Trusted Root Certification Authorities в ланцюжку того сертифіката, який використовувався для підпису сертифіката списку CTL. Як вже говорилося вище, визначити, чи є ланцюжок сертифікатів складовою частиною дійсного списку CTL, можна шляхом перегляду кожного з сертифікатів ланцюжка за допомогою закладки Certification Path вікна властивостей сертифіката.

Обробка ланцюжка крос-сертифікатів

Крос-сертифікація - це нова можливість встановлення відносин довіри, яка з'явилася в інфраструктурі PKI середовища Windows 2003 (докладніше вона розглянута в статті «Принципи довіри PKI»). На відміну від списків CTL, крос-сертифікація дозволяє встановлювати детальні відносини довіри в PKI між різними інфраструктурами центрів CA. При встановленні довірчих відносин через крос-сертифікацію між двома центрами CA, що входять в інфраструктури різних організацій, кожен з цих центрів стає одночасно як батьківським, так і підлеглим, при цьому в процесі побудови ланцюжків сертифікатів спостерігаються досить цікаві ефекти.

На рис. 3 показано, як працюють довірчі відносини на базі крос-сертифікації та як це відбивається на властивостях сертифікатів. Довірчих відносин між інфраструктурами CA в даному випадку відповідає зв'язок, показана у вигляді стрілки, яка спрямована на ліву половину малюнка. У розглянутому прикладі мають місце односторонні відносини довіри між OrgВ і OrgA. При цьому підлеглий центр SubCA видав крос-сертифікат центру HPCA (кореневого центру сертифікації організації OrgA), що дозволяє користувачам OrgB довіряти сертифікату з ім'ям Administrator, виданим центром HPCA. Інакше кажучи, в даній схемі користувачі організації OrgB безпосередньо довіряють центру RootCA, а також центру SubCA, оскільки від нього до RootCA побудована ланцюжок сертифікатів. Крім того, вони довіряють і центру HPCA (так як SubCA видав йому крос-сертифікат), а отже, довіряють сертифікату Administrator, виданим центром HPCA.

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

Жан де Клерк

( [email protected] ) - член Security Office компанії HP. Спеціалізується на управлінні ідентифікаційними параметрами і безпеки в продуктах Microsoft. Автор книги Windows Server 2003 Security Infrastructures (видавництво Digital Press)

Перевірка справжності цифрових сертифікатів в інфраструктурі Windows PKI