---

SSCD

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

У випадку використання автентифікації джерела SVD міститься в сертифікаті, якому усе ще до­віряє верифікатор, хоча це не посилений сертифікат. Підпис усе ще має «юридичну ефективність і до­пустимість як доказ у процесуальних діях», але він може не мати такого самого юридичного ефекту, як рукописний підпис.

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

Випадок використання анонімності дає змогу підписувачу підписуватися з використанням SSCD і залишатися певною мірою анонімним, наприклад у разі використання псевдоніма в сертифікаті. За­звичай у верифікатора немає прямих доказів того, хто цей підписувач.

Випадок використання «прямого відношення» заснований на припущенні, що підписувач іденти­фікує себе, надає відкритий ключ і доказ володіння в прямому контакті з верифікатором. Типовий при­клад — церемонія обміну ключами з досить гарною конфіденційністю (PGP),

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

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

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

У цьому разі систему використовують для підписання в цифровій формі й перевірки бінарних да­них, складених з випадкового числа, «попсе». Зазначимо, що цей цифровий підпис також не є «елект­ронним підписом», оскільки не пов’язаний з жодними даними.

У кількох державах — членах ЄС у законах про підпис заборонено використовувати SSCDs з ме­тою, відмінною від створення кваліфікованих електронних підписів, і у жодному разі від застосування різних ключів для кваліфікованих електронних підписів на документах, а для підписання «попсе» ува­жають «гарною практикою». Проте «SCDev, використовуваний для підписання в цифровій формі попсе» може дотепер входити в аналогічний SSCD фізичний пристрій, a SCDev — оцінювати щодо вимог SSCD і тому мати високий рівень безпеки. Проте формально SCDev, що містить SCD для підписання «попсе», не є SSCD, а створюваний цифровий підпис не є електронним підписом.

Цей випадок використання описано тут лише для завершеності.

У цьому випадку використання верифікатор знає, що «попсе» не змінено, що підписувач підписав «попсе» і що SCD належним чином захищений в SCDev. Однак верифікатор не знає, чи має «попсе» даних яке-небудь значення для підписувана.

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

з використанням окремого ключа з відповідним сертифікатом, що вказує, як ключ застосовують тільки для підписання великих бінарних об’єктів/BLOBs. Один із прикладів такого індикатора використання клю­ча — це «використання ключа digitalSignature» в Х.509 для автентифікації.

Ідентифікація

Посилений

Дані

Рисунок 4

Зазначимо, що використання SCD для інших засобів, крім підписання документів, може обійти таємність SCD. Наприклад якщо алгоритми підпису в SCD уразливі для окремих атак на відкритий текст, застосовуючи такі варіанти використання, варто пам’ятати про це. їх можна запобігти, наприклад за­безпечивши гешування «попсе» до використання SCD.

Типове використання цієї системи — схема доказу володіння або автентифікації підписувана. Тоді «попсе» — це просто випадкове число. У разі перевірки виробленого цифрового підпису-«попсе» ве­рификатор знає, що підписувач контролював SCDev і авторизував підписання «попсе». Цього досить, щоб довести верифікатору, що підписувач брав участь у процесі підписання; отже, верифікатор може підтвердити ідентичність, оголошену в сертифікаті.

Приклад такого використання — це ID-картка компанії, що є SSCD, а також містить належним чи­ном створений SCDev з SCD і SVD. Якщо застосування автентифікації надсилає SCDev для підписання «попсе», належним чином підписаний «попсе» доводить, що підписувач має картку й що він лише ав­торизував використання SCDev. Це забезпечує зовсім безпечну автентифікацію користувача.

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

7 ДОКАЗ ДЛЯ ЕЛЕКТРОННИХ ПІДПИСІВ

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

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

• взагалі заперечує виконання підпису;

• визнає виконання підпису, але для іншого повідомлення.

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

• підпис як волевиявлення/оголошення про наміри вимагає доказу контексту, у якому підпис ство­рено. Це описано в останньому підрозділі цього розділу.

• .1 Докази, наявні у підписаних даних

Підписані дані самі по собі містять такі основні елементи доказу, потрібні для встановлення за­конності підпису:

• документ підписувана: електронні дані, до яких приєднано чи з якими логічно пов’язано елект­ронний підпис;

• підпис: рядок битів, отриманий у процесі підписання з використанням SSCD або SCDev;

• ознака застосування алгоритмів для гешування документа й підписання значення геш-функції;

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

Підписані дані можуть також містити такі додаткові докази:

• ознака використання SSCD для створення підпису. Хоча нині його застосовують не так широ­ко, цього можна досягти, наприклад за допомогою додаткового підпису, створеного залежним від кон­кретного засобу ключем у SSCD. У загальному випадку політика сертифікації, на яку посилається сер­тифікат підписувана або інші специфікатори у сертифікаті, може вказувати на використання SSCD;

• штемпель часу, застосований у цифровому підписі, випущено надійним Органом штемпелювання часу (TSA), що вказує час, до якого створено підпис;

• інформація про шлях сертифіката до одного надійного вказівника, як визначено політикою підпи­сання;

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

• тип фіксації транзакції, що відображає семантику підпису. Тип фіксації транзакції можна вказу­вати в електронному підписі неявно або явно, використавши «ознаки типу фіксації транзакції» у фор­маті електронного підпису, або явно — у семантиці підписаних даних;

• Індикатор місця розташування, що задає конкретне місце розташування підписувана під час, коли він або вона наклав підпис;

• індикатор часу підписувана, що задає конкретний час застосування підпису;

• роль, під якою застосовано підпис;

• посилання на політику підписання, під якою затверджено підпис (див. далі).

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

• ознака того, чи випущено сертифікат як посилений, чи ні (додаток І);

• позначення органу, що випустив сертифікат, наприклад провайдер послуг сертифікації й держава, у якому він діє (додаток І);

• посилання на політику сертифікації й/або припис практики сертифікації, які виконує СА у разі ви­пуску сертифіката;

• ім’я підписувана або псевдонім, які ідентифікують підписувана як такого (додаток І);

• дані верифікації підпису, що відповідають даним створення підпису під керуванням підписува­на (додаток І);вказівка початку й кінця терміну дії сертифіката (додаток І);

• неявне або явне посилання на інформацію про статус сертифіката (listCRL скасування сертифі­ката або мережний протокол статусу сертифікатів OCSP);

• код ідентичності сертифіката (додаток І);

• розширений електронний підпис випускального провайдера послуг сертифікації (додаток І).

Опціонально сертифікат може також містити:

• обмеження на сферу використання сертифіката, якщо вони застосовні (додаток І);

• границі значень транзакцій, у яких використовують сертифікат, якщо вони застосовні (додаток І).

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

• вказівка, чи випущено сертифікат як посилений чи ні;

• опис процедур для встановлення ідентичності власника сертифіката;

• вказівка, чи підтверджує СА, що секретний ключ (SCD) зберігається в SSCD чи ні;

• опис процедур безпеки для СА, наприклад пов’язаних Із захистом ключа СА.

Під час перевірки підписаного повідомлення варто встановити статус сертифіката (скасований або чинний) на момент створення підпису. Цей тил доказу можна надати двома способами:

• Після одержання повідомлення одержувач підписаного повідомлення перевіряє статус сертифі­ката (використовуючи CRL або OCSP) і зберігає цю інформацію разом з повідомленням (можливо, та­кож штемпелем часу; див. також 7.1, де описано штемпелі часу як додатковий доказ). Зазначимо, що одержувачеві може знадобитися інформація про статус у два різних моменти часу: один раз — безпо­середньо після одержання підписаного повідомлення, а другий — після певного пільгового періоду, що допускає будь-яке можливе скасування для передачі службі інформації про статус сертифіката. Потім одержувач переконується в одержанні доступу до відповідної інформації про статус, у разі виникнення подальших суперечок.

• СА зберігає «історичну» інформацію про статус сертифіката й за запитом надає таку інформа­цію. CRL має містити таку історичну Інформацію протягом періоду чинності сертифіката, але її можна видалити з CRL після закінчення періоду чинності сертифіката.

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