19.3 Механізм повноважень як відображення політики цс

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

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

Мінімізувати ризик у цьому випадку можна за рахунок:

а) встановлення більш короткого терміну дії сертифікатів;

б) обмежити період використання конкретних програмних засобів генерації цифрового підпису;

в) максимально точно вказувати призначення сертифіката в його доповненнях.

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

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

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

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

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

При цьому, реєстраційний центр має повноваження на зміст сертифікатів і працює разом з ЦС, який тільки випускає сертифікати.

Слід враховувати, що модель ЦС+ЦР значно менш захищена, ніж система ІВК з одним тільки центром сертифікації.

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

19.4 Генерація та оновлення ключів. Публікація crl

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

а) генерація ключів;

б) збереження сертифікатів;

в) підтримка списків анульованих сертифікатів;

г) керування життєвим циклом сертифікатів і ключів.

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

Більш раціональним способом підвищення розширюваності вважається генерація пар ключів користувачами.

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

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

При функціонуванні ІВК надзвичайно важлива підтримка списків анульованих сертифікатів.

Слід враховувати, що вибір такого способу перевірки статусу сертифікатів (дійсний - недійсний), як онлайнова верифікація, значно підвищує вимоги до продуктивності сервера каталогів, тому система центру сертифікації повинна бути здатна керувати додатковим навантаженням при зростанні числа користувачів ІВК.

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

Щоб цьому запобігти, поновлення повинні відбуватися рівномірно, а не прив'язуватися до визначеної дати. Крім того, при проектуванні ІВК і організації її баз даних необхідно враховувати години пікового навантаження в роботі системи, тощо.

Важливим елементом системи є обслуговування недійсних сертифікатів.

Процедура блокування або скасування сертифікату призводить до внесення сертифікату до ССС - списку скасованих сертифікатів.

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

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

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

Для оптимізації перевірки статусу сертифікатів можна застосовувати розширення CRL Distribution Point (пункт поширення списків скасованих сертифікатів).

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