SSCD типу З
SSCD типу 3 визначає ролі адміністратора й підписувана аналогічно SSCD типу 2, див. 5.2.3.2. Атрибути безпеки, визначені в [SSCD РР], перелічено в наступній таблиці. Знову визначено різні групи атрибутів: користувацька група атрибутів, загальна група атрибутів і група атрибутів створення підпису.
Атрибути безпеки для SSCD типу З ([SSCD РР] тип З, FDP_ACF.1)
|
Користувач, суб’єкт або об'єкт, із яким асоційовано атрибут |
Атрибут |
Стан |
|
Користувацька група атрибутів |
||
|
Користувач |
Роль |
Адміністратор, Підписувач |
|
Загальна група атрибутів |
||
|
Користувач |
Керування SCD / SVD |
дозволено, не дозволено |
|
Група атрибутів створення підписів |
||
|
SCD |
робочий SCD |
ні, так |
|
DTBS |
Відіслано авторизованим SCA |
ні, так |
Як комбінація SSCD типу 1 і SSCD типу 2, визначено чотири SFP для SSCD типу 3 у [SSCD РР] у такий спосіб:
«ініціалізація SFP» покриває генерацію пари SCD-SVD і головним чином використовується, щоб обмежити «керування SCD/SVD» тільки користувачем, який може бути адміністратором або підписувачем (FDP_ACC.1 керування доступом підмножини й FDP_ACF.1 керування доступом, засноване на атрибутах безпеки). Модифікацію атрибута безпеки «керування SCD/SVD» обмежує тільки адміністратор (FMT_MSA.1 керування атрибутами безпеки), а обмежувальні значення визначено за промовчанням (FMT_MSA.3 статична ініціалізація атрибута);
«персоналізація SFP» покриває генерацію RAD адміністратором. Тому її використовують відповідним керуванням доступом SFR (FDP_ACC.1 керування доступом підмножини й FDP_ACF.1 керування доступом, засноване на атрибутах безпеки);
«SVD передача SFP» покриває експорт SVD в CGA адміністратором або підписувачем (FDP_ACC.1 керування доступом підмножини, FDP_ACF.1 керування доступом, засноване на атрибуті безпеки й FDP_ETC.1 експорт користувацьких даних без атрибутів безпеки) для цілісності даних повідомлення (FDP_UIT.1 цілісність обміну даними) і для потрібного надійного каналу до CGA (FTPJTC.1 надійний канал між TSF);
«створення підпису SFP» визначено для підписання DTBS підписувачем. Відповідні SFR керування доступом — FDP_ACC.1 (керування доступом підмножини) і FDP_ACF.1 (керування доступом, засноване на атрибутах безпеки). Створення підпису SFP також використовують для імпорту DTBSR (FDP_ITC.1 імпорт користувацьких даних без атрибутів безпеки) і підтримки цілісності DTBS (FDP_UIT.1 обмін даними із цілісністю). Модифікацію атрибута безпеки «робочий SCD» обмежує тільки підписувач (FMTJVISA.1 керування атрибутами безпеки), а обмежувальні значення визначено за промовчанням (наприклад, «робочий SCD» установлено в «ні» після створення) (FMT_MSA.3 статична ініціалізація атрибута). Надійний канал до SCA визначено для імпорту DTBSR (FTPJTC.1 надійний канал міжТЗР), як і надійний шлях (FTP_TRP надійний шлях) до НІ, якщо НІ не надає безпосередньо ТОЕ.
Перехід у робочий стан
Для персоніфікованих засобів, тобто SSCD типу 2 і SSCD типу 3, атрибут «робочий SCD» визначено, щоб ідентифікувати, чи є SCD робочим для створення підпису, чи ні. Мета полягає в тому, щоб здійснити єдине керування підписувачем, як визначено для розширених електронних підписів у статті 2 [Dir. 1999/93/ЕС] і Додатку III. Не може бути жодної можливості використовувати SCD для створення підпису, перш ніж підписувач досяг такого одноосібного керування.
Можливі численні організаційні й технічні засоби, що реалізують цю особливість. Дві можливості — наступні:
початковий PIN-код. SSCD можна постачати з «початковим PIN-кодом» (І-PIN), що недвозначно відрізняється від VAD ( PIN-коду), використовуваного для створення підпису. Цього можна досягти, визначивши довжину І-PIN коду коротшою за мінімальну довжину PIN-коду, наприклад, п’ять символів І-PIN коду проти мінімум шести символів для PIN-коду. Коли підписувач спочатку вибирає PIN-код, І-PIN код не валідний і SCD установлено у робочий. Тоді підписувач може виявити, якщо SCD використовували до постачання SSCD, оскільки валідний І-PIN указує, що SCD не був робочим;
імпорт сертифікатів. Оскільки кваліфіковані підписи вимагають SSCD і посиленого сертифіката, SSCD може надавати функції, які дозволяють підписувану імпортувати посилений сертифікат. Якщо SSCD перевіряє валідність сертифіката, а передачу між SVD у сертифікаті й SCD реалізує SSCD, то факт, що підписувачу призначено посилений сертифікат, можна використати для установки SCD у робочий стан.
Знищення ключа (FCS_CKM.4)
Для SSCD типу 1 SCD треба знищити після експорту в SSCD типу 2.
Для SSCD типу 2 або SSCD типу З SCD треба знищити на вимогу адміністратора або підписувана. Крім того, SCD треба знищити, перш ніж SCD повторно згенерований (SSDC типу 3) або повторно імпортований (SSCD типу 2).
Взагалі конструктори мають гарантувати, що знищення є постійним у тому сенсі, що відсутній будь-який засіб відновлення SCD або частини його на більш пізній стадії. Це означає, що конструктори мають відзначити, що:
недостатньо тільки відключити доступ до SCD із даними SCD, що залишаються в пам’яті;
необхідно розглянути дегенеративні ефекти, які випливають із тривалого зберігання даних. Приклад — «гарячі електрони» або окислювання, які можна виміряти після видалення даних;
такі методики, як E2PROM, які періодично поширюють дані між результатом сторінок у ситуаціях, коли дані можна видалити в активній сторінці, але контент залишається в неактивних сторінках.
Незважаючи на зазначені вище проблеми, фізично знищення SSCD бажано з погляду підписувана. Залежно від використовуваної технології, конструктор повинен дати подання про те, який "знешкоджувач" необхідно використовувати для певної реалізації SSCD. Як яскравий приклад, для широкої публіки, можливо, не очевидно, що поломка пластмаси в «схожій на кредитну картку» мікропроцесорній картці зазвичай не руйнує SSCD.
Оброблення невдач автентифікації (FIA_AFL)
[SSCD РР] визначають для обробки невдалих автентифікацій (FIA_AFL.1), оскільки після невдалого числа спроб автентифікації RAD необхідно блокувати й у такий спосіб забороняти автентифікацію підписувана, що вимагає створити підпис.
Була несуттєва невизначеність про те, що мали на увазі автори РР щодо розблокування RAD, оскільки FMT_MTD.1 (керування даними TSF) визначає, що тільки одна роль може змінити RAD, це — підписувач, який у разі заблокованого RAD більше не може автентифікувати себе.
Фактично персоналізація SFP визначає для РБР_АСС.1/Персоналізація SFP (керування доступом підмножини) і РОР_АСР.1/Персоналізація SFP (керування доступом, засноване на атрибутах безпеки), що адміністратор може створити новий RAD. Цю звичайну практику використовують, наприклад, із банківськими картками.
Запити про роз’яснення
Цей розділ дає відповіді на «запити про роз’яснення про SSCD РР». Такі запити отримано під час зростаючого інтересу до стандартів. Запити згруповано за їх основними твердженнями і обговорено далі способом питання/відповідь.
5.3.1 Статус SSCD РР
|
Питання Відповідь |
Зараз видані SSCD РР — це єдині «стандарти безпеки» для всього SSCD? Можливість кількох стандартів, які виконують вимоги SSCD, неявно подано в Директиві. Процедура, визначена в статтях 3 (5), 9 і 10, забезпечує, що Комісія може видати (будь-яке число) таких еталонів в офіційному європейському журналі. |
|
Співтовариство |
Коли продукт відповідає одному такому стандарту, зазначеному в офіційному журналі, це означає тільки, що продукт, як автоматично припускають, відповідає вимогам у додатку III Директиви. Однак продукт можна також безпосередньо визначити, як відповідний додатку III (не використовуючи такий стандарт), «відповідним суспільним або приватним органом, уповноваженим державою-членом. Таке визначення відповідності мають також визнати всі інші держави-члени. |
|
Питання Відповідь |
Чи реєструють РР у реєстрі, як визначено в статті 3 (5) Директиви? Так, CWA 14169, що містить РР, уведено до реєстру Єврокомісією в офіційному журналі 15 липня 2003 року. |
|
Питання Відповідь |
Кожний із SSCD РР (Тип 1-3; EAL 4, EAL4 +) оцінено? Усі три SSCD РР (Типи 1, Тип 2 і Тип 3) оцінено, a EAL 4+ дипломовано. |
5.3.2 Генерація ключа в CSP
|
Питання |
Є засіб SSCD РР для генерації SCD типу 1. Через те, що генерацію ключа зазвичай виконує CSP у фізично захищеному середовищі, хіба це не занадто високі вимоги для відповідності Додатка III? |
|
Відповідь |
Це було джерелом спірного обговорення під час розробки SSCD РР. Щодо положення 1 у цьому документі генерацію SCD за визначенням виконує SSCD. Проте оскільки SSCD РР дотримує загального підходу, який не розглядає середовища, надані в засобах CSP, зазвичай можуть бути інші стандарти генерації ключа й більше запобіжних заходів для засобів підписувана. |
5.3.3 Використання для підписання CSP
|
Питання |
Можна [SSCD РР] використовувати для того, щоб підписати засіб, використовуваний в CSP для штемпелювання часу або підписання посилених сертифікатів? |
|
Відповідь |
Це не було метою розробки [SSCD РР]. Проте область застосування CWA указує, що стандарт застосовний й у таких цілях. РР для криптографічного модуля конкретно звертається до вимог CSP засобу підписання, розроблених EESSI в області D2 [CMCSO РР] і зазначених Єврокомісією в офіційному журналі 15 липня 2003 року, як визначено в додатку II (f) Директиви [Dir. 1999/93/ЕС]. |
5.3.4 Відновлення та депонування ключів, спільне використання секретів SSCD
|
Питання |
Чи можна засіб з SCD, спільно використовуваний кількома особами, оцінити як SSCD РР? |
|
Відповідь |
Такі сценарії не підтримує SSCD РР, заснований на визначенні підписувача, наведеному в Директиві (стаття 2(3): підписувач — особа, яка підтримує засіб створення підписів) і визначення розширеного підпису (стаття 2(2): розширений підпис створюється з використанням засобу, які підписувач може підтримувати під своїм одноосібним контролем). Це не передбачає множини осіб, при цьому єдине керування не можна взяти на себе, якщо кілька людей спільно використовують SCD. |
|
Питання Відповідь |
Чи може CSP забезпечити функції резервування для SCD? Резервну копію SCD не підтримує SSCD РР, як обговорено у «положенні 3» у цьому стандарті. |
|
Питання |
Спільні секрети можуть бути корисними для CSP, наприклад, для резервування ключів із посиланням на застосування РР також для CSP. |
|
Відповідь |
Доки сфера застосування стверджує, що РР застосовно, коли первинна сфера застосування є SSCD підписувача. Тому SSCD РР обмежили сферу застосування визначенням підписувача як єдиного об’єкта. Жодні спільні секрети не передбачено. |
5.3.5 Надання послуги підписування
|
Питання |
SSCD РР застосовно до такого надання послуги підписування, як провайдер послуг, що підтримує SCD дистанційно, наприклад, через Інтернет? |
|
Відповідь |
Такі сценарії не розглянуто в [SSCD РР]. Однак вони важливі для розгляду й тому обговорені докладно в розділі 12. |
5.3.6 SVD експорт-імпорт для типу 2
|
Питання Відповідь |
Чому на рисунку 3 немає блоків для імпорту й експорту SVD? Ці блоки дійсно не відображено. Усе ще імпорт і експорт SVD надано SVD передачею SFP. Зазначимо, що зміст SVD або відповідного сертифіката не обов’язковий ані для типу 2, ані для типу 3 SSCD. Для типу 3 його треба експортувати в CGA для сертифікації й можна вилучити згодом. Для типу 2 або відповідного SSCD типу 1, що згенерував SCD, SVD може надати CGA або SVD може бути імпортований із SCD для подання в CGA. У кожному разі SSCD має бути здатним довести, чи відповідає SVD наданий SSCD SCD. |
5.3.7 Криптографічні атаки
|
Питання |
Як розкривають атаки, засновані на основних криптографічних операціях, як атаки на геш-функцїі чи протоколи підписування? Зокрема оскільки SCA може обчислити значення геш-функцїі, можуть бути атаки на схеми доповнення тощо. |
|
Відповідь |
Набори програм підписування, що підходять для кваліфікованих підписів, визначено в [ALGO], 3 тих пір є набори програм, стійкі проти атак доповнення, тому можна гешувати поза SSCD. |
5.3.8 Автентифікація й ідентифікація
|
Питання |
SSCD-CTP обговорює автентифікацію підписувача (опис ТОЕ або OE.HI_VAD), поки Директива говорить про розширені підписи як ідентифікацію підписувача. |
|
Відповідь |
Автентифікацію підписувача, використовувану SSCD РР, застосовують для втілення додатка III, конкретно 1(c) з вимогою, щоб SSCD гарантував, що SCD може надійно захистити підписувач від використання інших осіб. |
|
Питання |
Здається недостатнім, що CGA в OE.SVD_Auth_CGA верифікує SSCD відправник SVD щодо атак "людина усередині". |
|
Відповідь |
Крім того, потрібно в OE.SVD_Auth_CGA, щоб CGA верифікував передачу між SVD і SCD в SSCD підписувача, відповідно OE.CGA_QCert, вказуючий на SVD, відповідає SCD, реалізованому в ТОЕ під одноосібним контролем підписувача. Таким чином, дане чітке посилання на підписувача. |
