---

• для використання SCD SSCD має бути здатним розрізнити підписувана й інших, тобто має бути засіб ідентифікувати законного підписувана;

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

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

Додаток III Директиви 93/1999/ЕС

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

Положення 9. Підписувач може вирішувати, чи переглядати "дані, які будуть підписані".

Додаток III 2 гарантує, що підписувач здатний переглянути дані, які будуть підписані, до підписання їх і гарантує, що ці дані не змінив SSCD. Немає жодної отриманої вимоги, щоб SSCD гарантував, що подання DTBS фактично мало місце. В SSCD може, наприклад, бути опція, що підписувач може створити серію підписів для різних DTBS, не переглядаючи їх, також підпису­вач може переглядати кожний DTBS. З іншого боку, якщо певна реалізація представляє кожний DTBS тому, хто підписався без підписувана, здатного знищити подання, це — також валідний підхід відповідно до додатка 1112.

4.4 Пов’язані з SSCD заходи щодо посилених сертифікатів і CSP

Додаток І Директиви 93/1999/ЕС

Посилені сертифікати мають містити:

(е) дані верифікації підпису, які відповідають даним створення підпису під керуванням підписувана;

J Положення 10. SSCD має бути здатним допомогти в доказі відповідності між SVD і SCD. |

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

Додаток II Директиви 93/1999/ЕС

Провайдер послуг сертифікації має:

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

(j) не зберігати або копіювати дані створення підписів особи, якій провайдер послуг сер­тифікації надавав послуги керування ключами.

Наведені вище заходи, хоча безпосередньо не пов’язані з додатком III, підтримують поло­ження 4, що SCD має залишитися секретним. Доказ відповідності між SCD і SVD надано вико­ристанням SSCD, коли обговорено вище положення 10.

5 ПОЯСНЕНІ ЗМІНИ ДО CWA 14169

У цьому розділі пояснено [SSCD РР]. По-перше, наведено загальні настанови з реалізації, пояснені щодо [SSCD РР] у 5.1. Детальне обговорення головних проблем, які мають покрити реалізатори, наведено в 5.2.

• цьому розділі наведено короткий огляд [SSCD РР] нейтральним безпосередньо до тех­нології чином [SSCD РР]. Це зроблено з двох причин:

• це має зберегти документ модульним, хоча через тісні зв’язки його неможливо розгля­нути окремо від [SSCD РР];

• короткий огляд дає розширення описових частин [SSCD РР] і цим допомагає конструк­торам в одержанні початкового розуміння, як SSCD-вимоги перевели в Загальні критерії [ISO 15408] розробники [SSCD РР].

Т

5.1.1 Короткий огляд SSCD

Рисунок 1

ому підрозділ так структуровано. У 5.1.1 наведено подання високого рівня для процесу створення підписів. Наведено короткий огляд залучених компонентів і інтерфейсів. Різні типи SSCD обговорено в 5.1.2, а в 5.1.3 продовжено обговорення розмежування для поділу між ТОЕ та його середовищем.

Процес створення підписів, що використовує SSCD, спрощено опи­шемо так:

• генерація пари SCD-SVD (ключів) і відповідного сертифіката, створеного на фазі ініціалізації. Це проілюстровано внизу праворуч на рисунку 1;

• на фазі використання DTBS має вигляд підписаного підписува- чем документа. На підтримку одно­осібного контролю над властивостями треба використати автентифікацію підписувана, наприклад, уводячи PIN-код.

Навіть на цьому поверхневому рисунку, що поки нехтує різними опціями реалізації SSCD, можна ідентифікувати кілька основних загроз:

• SCD — це первинне майно, захищене (конфіденційне) під час ініціалізації й використання, оскільки атакувальник, одержавши керування над SCD, може створити будь-яке число підписів без згоди підписувача;

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

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

• дані, повідомлені на фазі використання, мають бути захищені для перешкоджання роз­криття PIN-коду атакувальником або заміни на DTBSR дані, обрані атакувальником.

5.1.2 Типи SSCD

Під час розробки [SSCD РР] розходження зроблено залежно від двох основних альтернатив на фазі ініціалізації (генерації ключів):

• пари SCD-SVD можна згенерувати в SSCD, що використовує підписувач для підписування,

• використовують спеціалізований засіб генерації пари SCD/SVD, що передає SCD в SSCD, застосовуване для підписання.

Це призвело до трьох основних типів SSCD, для яких загальні аспекти реалізації обговорено в наступних підрозділах:

• SSCD типу 1 — генерація пари SCD/SVD,

• SSCD типу 2 — створення підписів,

• SSCD типу 3 — генерація пари SCD/SVD і створення підписів.

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

• генерація ключів і тестування їхньої сили зазвичай витратно в обчислювальному відношенні;

• вимога для достатньої ентропії (див. положення 5) вимагає таких якісних фізичних гене­раторів випадкових чисел, як якісні джерела шуму.

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

Щодо положення 2 засіб генерації SCD, можливо, є SSCD. Тоді в термінах [SSCD РР] SSCD має тип 1. Його основні функціональні блоки проілюстровано на рисунку 2:

• генерація SCD/SVD;

• SCD експорт підписувана у засіб створення підписів, названий SSCD типу 2 у термінах [SSCD РР];

— SVD експорт або безпосередньо в CGA для генерації сертифіката, або в SSCD типу 2, що зв’язує SVD із CGA на пізнішій стадії.

5

5.1.2.2 SSCD типу 2

Копія SSCD типу 1 є SSCD типу 2, що є особистим засобом, використовуваним підписува- чем для створення підписів. Це індивідуальний засіб, і його основні функціональні блоки проілю­стровано на рисунку 3:

SSCD типу З

.1.2.3 SSCD типу З

Якщо пару SCD/SVD згенеровано «у межах» SSCD, використовуваного підписувачем для підписування, то ре­зультуючим засобом у термінах [SSCD РР] є SSCD типу 3. SSCD типу 3 є повністю виокремлений засіб, який можна роз­глядати як комбінацію SSCD типу 1 і типу 2.

Основна очевидна розбіжність полягає у тому, що SCD не можна передати за межі SSCD, як показано на рисунку 4. Основні «будівельні» блоки SSCD типу 3:

• генерація SCD/SVD;

• SVD експорт в CGA для генерації сертифіката, a SCD залишається в SSCD;

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

• створення підписів;

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

З огляду на три різні типи SSCD, описаних вище, три різних РР розроблено в [SSCD РР] — по одному для кожного типу SSCD. Конструктори й автори ST повинні вибрати конкретний РР для відповідності. У цьому розділі обговорено обмеження ТОЕ.

[SSCD РР] одержали компоненти, які є необхідними частинами ТОЕ згідно з додатком III Директиви. Конструктор має право інтегрувати в ТОЕ такі інші компоненти, як засіб перегляду документів, що однак лежить поза описом цього загального розділу, але далі обговорено в цьому стандарті.

Розбіжність між ТОЕ і його середовищем залежить від типу SSCD. Тому далі обговорено це розходження для SSCD типу 1 і SSCD типу 2. Наступний розділ обумовлює межі ТОЕ, загальні для всіх типів SSCD.

Щ

5.1.3.1 SSCD типу 1 і SSCD типу 2

Рисунок 5

одо розбіжності між ТОЕ та його сере­довищем, вочевидь, є взаємозв’язок між SSCD типу 1 і SSCD типу 2.

— У разі SSCD типу 1 ТОЕ експортує SCD у SSCD типу 2, тобто SSCD типу 2 є ІТ-сере- довищем ТОЕ. Це стосується SVD, коли SVD передається від ТОЕ в SSCD типу 2.

— З іншого боку, у разі SSCD типу 2, SCD імпортується з SSCD типу 1. Отже, SSCD типу 1 є IT-середовищем ТОЕ. Те саме стосується SVD, коли SVD передається від ТОЕ в SSCD.

Обговорений сценарій проілюстровано на рисунку 5. Щоб виконати вимогу таємності SCD, так званий «надійний канал» визначено в [SSCD РР] між SSCD типу 1 і SSCD типу 2. Мета надійного каналу полягає в тому, щоб підтримати конфіденційність SCD і цілісність SCD протягом передачі. Для опціональної передачі SVD визначено надійний канал, що має підтримати цілісність SVD. Надійні кана­ли обговорено далі в 5.2.1.

Зазначимо, що за визначенням у 3.1 SSCD типу 1 є не обов’язково оцінюваним [SSCD РР] засобом, оскільки можна використовувати інші засоби, які відповідають [Dir. 1999/93/ЕС].

В

Рисунок 6

важаючи, що SSCD типу 3 може бути комбінацією SSCD типу 1 і SSCD типу 2, розбіжність між ТОЕ як конкретний тип SSCD і його середовище проілюстровано на рисунку 6. Зазначимо, що, вочевидь, немає прямого інтерфейсу до SCA і НІ для SSCD типу 1. З іншого боку, інтерфейс між SSCD типу 2 і CGA потрібен тільки для випадків, коли SSCD типу 2 містить SVD й експор­тує його для генерації сертифіката.

На додаток до взаємозв’язку між SSCD типу 1 і SSCD типу 2, TOE спілкується з багатьма застосуваннями, які становлять IT-середовище ТОЕ:

• SVD переданий від SSCD в CGA для генерації сертифіката. Тому надійний канал визна­чено в [SSCD РР] на підтримку цілісності SVD;

• DTBSR переданий від SCA в SSCD для створення підпису. Тому надійний канал визна­чено на підтримку цілісності DTBSR;

• технічні засоби для створення можливості підписувану ініціювати створення підпису під його одноосібним контролем надала автентифікація користувача. Тому так званий «надійний шлях» до інтерфейсу користувача (НІ) визначено в [SSCD РР]. Під час розробки [SSCD РР] ство­рені засоби, які інтегрують НІ в ТОЕ, тому не потрібен надійний шлях у цій ситуації.

У цьому розділі обговорено аспекти, які конструктори вважають особливо цікавими. Ці аспекти викликають підвищену увагу до результатів, які неодноразово цікавили конструкторів чи були джерелом інтенсивного інтересу впродовж розробки SSCD РР.