---

У статті 5 Директиви 93/1999/ЕС європейський законодавець визначив юридичну значимість:

• «5.1 підписам» надавати ту саму значимість, що й рукописним підписам, жадати від національ­ного законодавства гарантій того, що кваліфіковані електронні підписи виконують юридичні вимоги до підпису стосовно даних в електронній формі так, як рукописні підписи виконують ці вимоги щодо па­перових даних;

• «5.2 підписам» не можна відмовити в юридичній значимості винятково на такій підставі:

Стаття 5 Директиви 93/1999/ЕС

1. (Викладені вище)

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

— в електронній формі; або

• не заснований на посиленому сертифікаті;

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

• не створений надійним засобом накладання підпису.

Основна відмінність між юридичними визначеннями двох типів електронних підписів у статті 5 по­лягає в тому, що є позитивне визначення 5.1 підписів і лише відмінне визначення іншого електронно­го підпису, оскільки з юридичної точки зору 5.2 ПІДПИС — це будь-який електронний підпис, що не є 5.1 підписом.

Тому варто роз’яснити випадки, коли є тільки один тип або багато типів 5.2 підписів. Відповідь очевидна: є принаймні два типи 5.2 підписів, розширений І нерозширений.

Чи існують інші підписи, відмінні за формулюванням від двох типів 5.2 підписів? Раніше стверд­жувалося, що відмінність юридичної значимості не можна визначити окремо від конкретної юридичної системи. Юридична значимість підписів також значно відрізняється в кожній юридичній системі.

6 ВИПАДКИ ВИКОРИСТАННЯ НЕКВАЛІФІКОВАНОГО ЕЛЕКТРОННОГО ПІДПИСУ

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

Можливі багато які інші випадки некваліфікованих електронних підписів, але вони не залучені в розглядувану сферу застосування.Додана оброблянням вартість електронних підписів, якою користуються деякі, але не всі елементи, визначені в статті 5.1 для кваліфікованих електронних підписів, також явно сформульовані в доклад­ному описі (20) Директиви в такий спосіб.

Докладний опис (20) з Директиви 93/1999/ЄС

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

У цьому розділі спочатку описано випадок використання кваліфікованого електронного підпису, а потім — електронного підпису, у якому один компонент одноразово відсутній. По-перше, в 6.2 обго­ворено випадок використання, надрукований грубим шрифтом у цитаті наведеного вище докладно­го опису (20), а в 6.3 — електронні підписи, у яких відсутнє придатне подання документа. Нарешті, в 6.4 обговорено розширені електронні підписи, що використовують засоби SSCD, але не засновані на посилених сертифікатах.

Я

Посилений

сертифікат (QC)

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

Ідентифікація
підписувана

11(d)

Цс)

Це)

I REF J

2.2(b)

Підпису вам

Alice Smith

Дані
верифікації
підпису

Розширений
підпис (AS)

Верифікація AS

SSCD
Г енерація
SCD/SVD

2.2(c)

д~| підпис I 1(h)

Дані на підпис

SCA

Підписування за допомогою SCDev

ПІДПИС

створення AS верифікація AS G.

2.2(d)

генерація QC

■I підпис )

Підписаний об’єкт даних

_L

Дані
створення
' підпису

SSCD

AS, QC і SCDev пов’язують елементи формування сертифіката, створення й перевірки електрон­них підписів. Для простоти припустимо, що SCDev реалізує обидва криптографічних механізми: для формування пари SCD/SVD і цифрових підписів як частин AS.

QC містить ім’я підписувана або псевдонім, ідентифікований як такий (див. додаток І, с). Іден­тичність людини, для якої випускають QC, варто перевіряти за допомогою CSP (див. додаток II, d). CSP перевіряє відповідність SVD, включеного в QC, SCD, що перебуває під контролем підписувана (див. додаток І, е). Якщо CSP одержує SVD від SSCD, то CSP пов’язує підписувана й SSCD І просить SSCD забезпечити доказ відповідності MixSCD і SVD. CSP вживає заходи захисту від підроблення сертифікатів (див. додаток II, h) і підписує QC за допомогою AS (див. додаток I, h). QCP може визна­чати спеціальні правила для використання SSCD і наданих послуг SSCD.

Підписувач використовує SCA для підготовки даних, які підписують (DTBS) для створення розши­реного підпису (AS). AS пов’язує DTBS і AS таким чином, щоб виявляти будь-яку подальшу зміну да­них (стаття 2.2, d). Це посилання встановлює механізм цифрового підпису, складений з геш-функції й алгоритму підписання. Повний контроль підписувана SCD (стаття 2.2, с) приводить до:

1. асиметричних криптографічних методів для створення підпису за допомогою SCD і для пере­вірки підпису за допомогою SVD;

2. контролю над використанням SCD.

Зазначимо, що використовуючи код автентифікації повідомлення (МАС), заснований на таких си­метричних криптографічних механізмах, як ISO 9797, можна створити електронний, а не розширений електронний підпис. Той самий ключ використовують для формування й перевірки МАС і він не може перебувати під повним контролем підписувана. Контроль за використанням підписувачем SCD зале­жить від життєвого циклу SCD і SSCD, реалізованого SCD. Докладніше це питання обговорено у на­ступному підрозділі.

У статті 2(6) Директиви визначено засіб створення підпису, що відповідає встановленим у Додат­ку III вимогам, як «засіб надійного створення підпису». У преамбулі Директиви заявлено в докладно­му описі (15), що Додаток III покриває вимоги для надійних засобів створення підпису для гарантії функціональності розширених електронних підписів. Держави — члени ЄС визначають уповноважені органи влади, відповідальні за оцінку відповідності надійних засобів підпису відповідно до Додатка III.

Безпека SCD і створення підпису залежить від SSCD і методу його використання. Середовище SSCD визначає загрози, яких стосується SSCD за умови використання TOE. SSCD реалізує всі функції IT-безпеки, необхідні для гарантування таємниці SCD і заходів підтримки безпеки для захисту передачі SVD в CGA і середовище створення підпису.

Проте засіб створення підпису (SCDEV), використовуваний для накладання розширеного підпи­су, не можна розглядати як SSCD у контексті статті 5.2, оскільки:

1. у разі дуже високої безпеки й реального задоволення вимог Додатка НІ безпеку не оцінює й не схвалює вповноважений орган влади;

2. SCDev не в змозі забезпечити достатні заходи безпеки на виконання вимог Додатка III.

У першому випадку безпека електронного підпису не може залежати від гарантії властивостей безпеки SCDev, даної відповідно до оцінки безпеки вповноваженого органа влади. Гарантія властиво­стей безпеки SCDev може ґрунтуватися на оголошенні виробника або може бути відсутня. Підписувач, що скасовує свій підпис, може послатися на потенційні слабкості безпеки в життєвому циклі SCD, які уможливлюють підроблення підпису. Тому безпеку SCD і SCDev для неспростовності підписів важко продемонструвати. Проте розширений електронний підпис може все-таки послужити меті автентифікації джерела Й цілісності даних.

Другий випадок стосується широкої сфери практичних рішень із захисту SCD і процесу створен­ня підпису за додаткової умови використання SSCD. Ключова умова — безпечне IT-середовище. При­пустимо, що SCDev реалізовано як програмне забезпечення для стандартних персональних комп’ютерів. Тоді SCDev працює під операційною системою (OS), що забезпечує кожному процесу доступ до таких IT-ресурсів, як збережені дані, екран, клавіатура й пам’ять. Неактивний SCDev — це просто ряд даних, які можна читати й обробляти. Тому захист SCD і самозахист SCDev обмежені. Заходи безпеки SSCD від інших загроз істотно залежать від IT- і не IT-середовища. Підписувану варто гарантувати ці заходи безпеки. Це здійсненно, якщо SCD, SCDev і IT-середовище перебувають під його повним керуванням.Але повністю управляти IT-середовищем дуже важко або неможливо, навіть якщо на ПК підписувана працює SCDev. Отже, підписувач зобов’язаний домогтися компромісу між необхідною для його елект­ронного підпису безпекою й заходами безпеки середовища підписання, включаючи SCDev.

У профілі захисту в документі [SCDEV-CTP] описано один потенційний підхід, який можна проко­ментувати у такий спосіб:

1. SCDev перебуває під повним контролем підписувана. Підписувач — це єдиний зареєстрова­ний користувач SCDev, включаючи всі такі функції адміністратора, як інсталяція й ініціалізація;

2. SCDev використовує сильні криптографічні механізми для генерації пари SCD/SVD і для ци­фрових підписів;

3. SCDev забезпечує автентифікацію користувача й керування доступом для використання зге- нерованої пари SCD/SVD і створення підпису. Дані автентифікацїї (пароль) підписувана — це таємниця, не збережувана електронно;

4. SCDev реалізує елементарні заходи самоперевірок для захисту себе від помилок і маніпуляцій;

5. SCDev покладається на захист операційною системою поділу домену, не IT-середовище має фізично захистити SCD, SCDev та ІТ-платформу.

Тепер розглянемо випадок використання розширених підписів без SSCD, проілюстрований на ри­сунку.

Рисунок 2

Ідентифікація сертифікат (QC)

Посилений

Д

Дані створення підпису

Генерація SCD/SVD

ані
верифікації
підпису

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

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

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

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

Технічна якість і безпека SCDev суттєво залежать від визначення якості доказу. Із цієї причини варто розглянути застосування профілю захисту для визначення вимог безпеки SCDevs. Такі СТР, що визначають мінімальні вимоги до забезпечення цілісності й автентифікації джерела підписаних даних, наведено в [SCDEV-СТР]. СТР спроектовано як цілком програмну реалізацію. Іншими критеріями оці- нення, застосовними для забезпечення технічної якості SCDev, є [FIPS 140-2] або [ITSEC].

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

Посилений
сертифікат (QC)

Alice Smith

(S 1(c)

I REF І

d

2.2(b) t

Ідентифікація підписувана

П(Ф

Підписувач

ПІДПИС І

Дані
верифікації
підпису

Верифікація оїдпису

SSCD Г енерація SCD/SVD

1(h)

Підписування

2.2(c)

допомогою SCDev

SCA

2.2(d)

за

генерація QC

створення AS

ПІДПИС

верифікація AS

Бінарний об’єкт на підпис

Підписаний бінарний об'єкт

Розширений підпис (AST)

У

Дані
створення
підпису