Страница 7: ДСТУ CWA 14355:2009. Настанова щодо реалізації безпечних засобів створення підписів (61471)

Застосування SSCD реалізує:

(a)FDP_ACC.1 функціональні вимоги безпеки керування доступом (політика керування доступом) і FDP_ACF.1 (керування доступом, засноване на атрибутах безпеки) за визначенням SSCD РР SFP через атрибути безпеки (наприклад, права доступу до файлу для смарт-карток), засновані на властивостях безпеки операційної системи;

(b)SFP для імпорту й експорту даних згідно з FDP_ETC.1 (експорт користувацьких даних без атрибутів безпеки) і FDP_ITC.1 (імпорт ззовні TSF керування);

(с) функції FMT_MOF.1 керування безпекою (керування поведінкою функцій безпеки), FMT_MSA.1 (керування атрибутами безпеки), FMT_MSA.2 (безпечні атрибути безпеки), FMT_MSA.3 (статична ініціалізація атрибута), FMTJVITD.1 (керування даними TSF) і FMT_SMR.1 (безпечні ролі), засновані на властивостях безпеки операційної системи

(d)визначене абстрактне машинне тестування FPT_AMT.1 (абстрактне машинне тестуван­ня), засноване на властивостях безпеки операційної системи, можливо, удосконаленої згідно з [SSCD РР] політикою функціональної безпеки з використанням атрибутів безпеки.

6.2.3 Оцінювання SSCD як складеного засобу

Апаратні засоби, програмне забезпечення й застосування зазвичай надають різні продавці. Це визначає оцінювання складеного продукту, заснованого на оцінених компонентах. Далі об­говорено загальні підходи до оцінювання (рисунок 7). Мета всіх цих оцінювань полягає в тому, щоб одержати сертифікат для SSCD, що відповідає SSCD РР.

Р

Рівень
застосування

з

системи

РР SSCD

Оцінювання SSCD на відповідність вимогам РР SSCD

Випадок 1

Рисунок 7

Випадок 2

Випадок З

ТОЕ — закінчений SSCD, а цілі безпеки вимагають відповідності з SSCD РР. Жоден із ком­понентів ТОЕ не оцінюють окремо. Спонсор оцінювання SSCD гарантує, що розробники різних компонентів забезпечують необхідне оцінювання вузлів і їхніх компонентів.

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

• ST апаратної платформи включає відповідні цілі безпеки й вимоги безпеки SSCD РР;

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

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

• наданий TSF, що комбінує апаратну платформу й операційну систему, тобто TSF, що реалізує FPT_EMSEC.1,

• коректність і ефективність TSF, наданого операційною системою й застосуванням,

• продукт у цілому, виконуючий SSCD РР.

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

Описаний підхід до оцінювання широко використовують для смарт-карток. Приклади конфі­гурацій захисту, які можна розглянути як підставу для оцінок апаратури:

• профіль захисту інтегральної схеми смарт-картки [РР 9806];

• профіль захисту платформи смарт-картки ІС [РР 0002].

Але зазначимо, що SSCD РР, із одного боку, РР [РР 9806] і [РР 0002], з іншого боку, не відпо­відають повністю один одному. Більш детально див. додаток І цього стандарту.

Оцінювання смарт-карток як комбінації чипа, з одного боку, і операційної системи й засто­сування, з іншого, — обговорено в чартерній ініціативі по смарт-картках eEurope, ТВЗ, включа­ючи органи сертифікації, засоби оцінювання й продавців смарт-картки.

6.2.3.3 Випадок 3 — Оцінювання SSCD, що використовує оцінки апаратної складової й операційної системи

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

1. ST продукт включає відповідні цілі безпеки й вимоги безпеки SSCD РР;

2. прикладний компонент ТОЕ використовує сертифікований продукт сертифікованим спо­собом, тобто як вимагає настанова.

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

3. застосування використовує властивості безпеки, надані сертифікованим продуктом для реалізації TSF, необхідного SSCD РР, тобто використовує керування доступом для ключів, на­даних операційною системою, щоб реалізувати SVD передачу SFP, ініціалізацію SFP, персона- лізацію SFP і створення підпису SFP;

4. продукт у цілому виконує SSCD РР.

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

Описаний підхід до оцінювання також можна використовувати для смарт-карток. Приклади профілів захисту, які можна розглянути як підставу для оцінювання:

• профіль захисту інтегральної схеми смарт-картки з убудованим програмним забезпечен­ням [РР 9911];

• група користувачів безпечної смарт-картки: профіль захисту смарт-картки [SCSUG], Проте зазначимо, що SSCD РР, з одного боку, РР [РР 9911] і [SCSUG], з іншого боку, не відповідають один одному повністю. Детальніше див. додаток І цього стандарту.

7 ЗАГАЛЬНІ НАСТАНОВИ З РЕАЛІЗАЦІЇ ПЛАТФОРМИ

Процес створення підпису, описаний в [CWA 14170], визначає систему створення підписів (SCS) як складену із застосування накладання підпису (SCA) і безпечного засобу створення підпису (SSCD). Універсальний процес накладання електронного підпису такий (див. рисунок 8):

Рисунок 8

• компонент подання документа особи, що підписує (SDP), використовує SCA, щоб зробити огляд документа;

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

• із даних гешування компонента (DHC) SCA створює подання (геш) DTBS, згадуване як DTBSR;

• SCA посилає DTBSR у SSCD;

• SSCD створює підпис, використовуючи SCD;

• виведено підписані формати (SDOC) композитора об’єкта даних SDO.

Кваліфікований електронний підпис визначено як розширений електронний підпис, заснова­ний на посиленому сертифікаті й створений SSCD. ETSI QCP [TS 101456] визначає два іденти­фікатори політики сертифікації, один із яких «публічний QCP + SSCD» гарантує, що посилений сертифікат, випущений для SVD (відкритий ключ), а відповідний SCD (особистий ключ) постійно перебуває в SSCD. Для залежних сторін одержання підписаного повідомлення, яке посилаєть­ся на такий сертифікат, завіряє їх, що підпис фактично є кваліфікований підпис.

Якщо замість цього посилений сертифікат тільки містить ідентифікатор політики «публічний QCP», то залежна сторона має через інші засоби одержати гарантію, що використано SSCD. Хоча цього можна досягти технічними або процедурними засобами, зазвичай це буде набагато склад­ніше, ніж якщо цю довіру надає СА, наприклад, визначаючи OID QCP у сертифікаті.

Щоб спростити потреби залежних сторін, можна чекати, що більшість СА захоче гаранту­вати й гарантує, що використано SSCD для зберігання SCD, навіть якщо SSCD не надано СА. У такому сценарії підписувач одержить свій SSCD із іншого джерела й потім на більш пізній стадії запросить сертифікат свого SVD. Це вже передбачено в [SSCD РР], який для експорту вимагає FTPJTC.1/SVD, щоб SSCD забезпечив надійний канал експорту SVD у застосування генерації сертифіката CGA. Проте не наведено подробиць реалізації для такого каналу й немає вимог для CGA з використання цього надійного каналу. Відомі такі рекомендації реалізації для надійних каналів:

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

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

• більш надійний механізм зберігає залежний від засобів секретний ключ на всіх SSCD разом із сертифікатом засобу, підписаним продавцем. Тоді CGA може також верифікувати дійсність SSCD.

Крім того, [SSCD PR] допомагає CGA, пропонуючи доказ передачі між SCD і SVD як крип­тографічну операцію (FCS_COP).

Під час генерації сертифіката SSCD спілкується з CGA. Взагалі існують дві альтернативи залежно від часу доставки SSCD підписувачу:

• сертифікат створено CSP разом із генерацією ключа й персоналізацією SSCD, до дос­тавки SSCD підписувачу;

• сертифікат створив у пізніший час й ініціював підписувач.

Які потреби треба розглянути? Що включає визначення посиленого сертифіката, що SCD перебуває під контролем підписувана ([Dir. 1999/93/ЕС], Додаток 1(e))? Таким чином, у першо­му випадку заходи мають гарантувати, що сертифікат «не зроблено доступним» до фактично­го одержання SSCD підписувачем, який має контроль над SCD.

В обох випадках експорт SVD через надійний канал необхідний, якщо генерація SCD/SVD виконана в SSCD або вона виконана на SSCD типу 1 і пізніше експортована в SSCD підписувана.

Якщо SCA і SSCD реалізовано на певній платформі, є дві можливості:

— SCA і SSCD спільно використовують обчислювальний механізм (клас 1 SCS),

— SCA і SSCD використовують два окремих обчислювальних механізми (клас 2 SCS).

Обидві можливості обговорено далі.

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

• захист SCD. Оскільки засіб діє як SSCD, треба забезпечити всі функції SSCD;

• захист DTBSR. Створення й передача DTBSR (тобто значення геш-функції) вимагають надійного каналу між SCA і SSCD. Надійний канал у засобі з єдиною метою може бути апарат­ним каналом на захищеній платформі;

• безпечний увід-вивід. SCA здатний відобразити належним чином повідомлення, щоб підпи­сати (DTBS) і дістати однозначну згоду користувача створити один або більше підписів.

Головні моменти атаки для реалізації класу 1 SCS пов’язані з відділенням SCA і SSCD від інших компонентів і захистом SCD. У засобах із єдиною метою не існує більшості цих проблем; однак у користувача є засіб, який виконує тільки одну операцію. Із загальнодоступними обчис­лювальними машинними й множинними процесами захист SCD і належна передача DTBSR стали важко розв’язуваними проблемами.

Для класу 2 SCS використовують окремі обчислювальні механізми SCA і SSCD. Окремі компоненти можна реалізувати на тій же фізичній платформі, але процеси спільно не викори­стовують один обчислювальний механізм. Це розташування вимагає вирішення наступних проблем:

• надійний канал. SCA і SSCD вимагають, щоб надійний канал повідомив команди й DTBSR. Команди включають вибір користувача SCD і однозначної згоди виконати один або більше підписів;

• ідентифікація SCA і SSCD. Належне створення надійного каналу вимагає ідентифікації й автентифікації двох кінцевих крапок;

• SCA належить мати безпечний шлях уводу-виводу, щоб належним чином відобразити повідомлення для підписання й дістати згоду користувача підписатися через надійний шлях;

• SSCD має повторно перевірити валідність згоди користувача виконати підпис.

Головні моменти атаки для реалізації класу 2 — надійний канал між SCA і SSCD. Тому що SSCD відповідає вимогам SSCD РР і колись DTBSR досягає SSCD, то виконано вимоги безпе­ки. Проблема — створення DTBSR і його передача.

У багатьох засобів є доступ до обмеженої кількості екранних засобів відображення. Це обмеження створює потребу мати два типи засобів підпису. Ці два типи відомі як «Відображення повідомлення» і «Відображення геша».