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

Питання OT.SCD_Secrecy стверджує «розумна впевненість», а де "розумна" — неясно.

OT.SCD_Secrecy заявляє «розумно впевнений», а де "розумно" — неясно.

Відповідь Це формулювання взято з додатка III 1(a) Директиви. У його фактичному

використанні в OT.SCD_Secrecy, "розумна" означає, що мета полягає в забез­печенні засобу, що достатньо забезпечує секрет SCD як первинне майно, навіть розглядаючи атакувальника з високим потенціалом атаки.

Питання Стан відображення FMT_MOF.1 на OT.Sigy_SigF та OT.SCD_Secrecy є мало-

з’ясований.

Відповідь Функції керування доступом гарантують, що тільки законний підписувач може

використовувати SCD для створення підпису, як задано в OT.Sigy_Sig, визна­ченому в додатку III Директиви, конкретно 1(c) («SSCD гарантує, що SCD може надійно захистити законний підписувач проти інших користувачів»). Відобра­ження OT.SCD_Secrecy має запобігти таким атакам на SCD, заснованих на процесі створення підпису, який може бути початий як атака апаратного збою чи [DFA].

Питання [SSCD РР] задають певне сімейство FPT_EMSEC, щоб покрити загрози, які

випливають із спостереження за інтерфейсом або складовими випромінювання. Це розширення [ISO 15408]. Чому неможливість спостереження (FPR_UNO) недостатня для покриття таких загроз?

Відповідь FPT_EMSEC уведено, щоб покрити загрози, які випливають із витоку під час

обробки або передачі даних. Такий витік можна помітити через електромаг­нітне випромінювання SSCD, інтерфейси даних, явища споживаної потужності тощо. Зв’язані атаки, наприклад, SPA, ГРРА1, [DFA] тощо, обговорено докладно в 5.2.2.

FPR_UNO — сімейство, що покриває захист приватності, щоб уникнути спостереження за використанням послуги користувачем. У контексті SSCD це було б, наприклад, спостереженням за ситуацією, коли підписувач створює підпис, що лежить поза сферою застосування [SSCD РР]. На противагу атакам, до яких звертається FPT_EMSEC і які засновані на спостереженні за такими побічними ефектами, як фізичні явища, що показують конфіденційні дані під час використання SSCD, не є фактом використання безпосередньо SSCD. Тому FPR_UNO вважають недостатнім, щоб покрити ці загрози.

6 ВІДНОШЕННЯ SSCD РР ДО ІНШИХ СТАНДАРТІВ

У цьому розділі наведено настанову конструкторам, які прагнуть відповідати іншим зв’язаним профілям захисту. В 6.1 наведено короткий огляд різних стандартів, розширений детальним обговоренням у додатку І цього документа.

У 6.2 обговорено оцінювання SSCD як комбінації апаратних засобів і програмного забезпе­чення, використовуючи різні pro.

SSCD РР порівнювали з такими пов’язаними профілями захисту.

— Eurosmart РР-документи [РР 9806] [РР 9911] [РР 0002] і [РР 0010];

— РР-документ SC-групи користувачів NIST [SCSUG].

Повне порівняння SSCD РР та інших має в ідеалі містити такі теми порівняння:

— Який ТОЕ може задовольнити різні РР?

— Які загрози взято до уваги?

— Які SFR враховано та які основні розбіжності є в концепції?

Рівнем оцінювання CWA 14169 є EAL4, аргументований

— AVA_VLA.4,

— AVA_MSU.3.

Необхідна сила функції — «SOF— HIGH»

Рівнем оцінювання [РР 9911] є також EAL4 +, але аргументований концепціями:

— ADVJMP.2,

— ALC_DVS.2,

• AVA_VLA.4.

Ці РР ураховують етап розробки й фазу використання продукту. Отже, покрито активи:

• специфікації ІС, дизайн, інструментальні засоби розробки й технологія,

• програмне забезпечення для ІС;

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

• прикладні дані ТОЕ (ІС, дані конкретної системні, дані ініціалізації, вимоги попередньої персоналізації ІС і дані персоналізації).

Розбіжності зроблені в описі ТОЕ між модулем обробки, блоками пам’яті й уводом-виводом.

Активи треба захищати в термінах конфіденційності й цілісності.

Загрози відрізняються між фазами.

Як в [SSCD РР], немає жодного визначення організаційної політики безпеки, тому що її вважають занадто залежною від контексту використання ТОЕ (тобто застосування).

Цілі безпеки включають мету для ТОЕ, що має працювати завжди, навіть якщо змінюєть­ся середовище.

Цей РР включає вимогу FPR_UNO безпеки замість SSCD РР як специфічної функціональ­ної вимоги безпеки FPT EMSEC.1.

Рівнем оцінювання [РР 0002] є також EAL4 +, але аргументований концепціями:

• ADVJMP.2 (Реалізація TSF);

• ALC_DVS.2 (Достатність заходів безпеки);

• AVA_MSU.3 (Аналіз і тестування на небезпечні стани);

• AVA_VLA.4 (Дуже стійкий).

[РР 0002] головним чином націлений на смарт-картки ІС. [РР 0002] також покриває таке програмне забезпечення, як убудоване програмне забезпечення ІС, яке постачають зі смарт- картками виготовники ІС.

Єдина організаційна політика безпеки — P.Process-TOE, що покриває захист під час розробки й виготовлення.

Рівень оцінювання — також EAL4+, але аргументований концепціями:

• ADV_IMP.2 (Реалізація TSF);

• ALC_DVS.2 (Достатність заходів безпеки);

• AVA_VLA.4 (Дуже стійкий).

Що стосується [РР 9911], то [РР 0010] має сильну залежність від [РР 9806]. Фактично ТОЕ має впливати на апаратну платформу, сумісну з [РР 9806].

Як у [SSCD РР], немає жодного визначення організаційної політики безпеки, тому що її вважають занадто залежною від контексту використання ТОЕ (тобто застосування).

Рівень оцінювання — також EAL4+, але аргументований концепціями:

• AVA_VLA.3 (Оцінка уразливості — Аналіз уразливості — Помірковано стійкий);

• ADVJNT.1 (Розробка — внутрішня організація TSF — модульність).

[SCSUG] включає коментар про надійний канал. "ТОЕ складається з достатніх апаратних і програмних елементів, щоб бути здатним до встановлення надійного каналу до надійного джерела для завантаження застосування або для інших потенційно привілейованих команд." ([SCSUG], підрозділ 2.2, параграф 5).

РР покривають користувача й застосування ТОЕ, таким чином, активи складені з даних користувача, а також коду застосування.

РР включає організаційну політику безпеки:

• P.Audit;

• P.Crypt_Std — Криптографічні стандарти;

• P.Data_Acc — Доступ до даних;

• P.File_Str — Структура файлу;

• Rldent — Ідентифікація;

• P.Sec_Com — Безпечний зв’язок.

Детальне обговорення цих стандартів порівняно з [SSCD РР] наведено в додатку І цього стандарту. Наступний розділ звернено до аспектів, які конструктори розглядають, прагнучи відпо­відати різним РР.

6.2 Аспекти оцінювання SSCD як комбінації HW-SW

У цьому підрозділі розглянуто оцінку SSCD як комбінації апаратних засобів і програмного забезпечення. Тому 6.2.1 звертається до тих аспектів, коли бажана апаратна реалізація. У 6.2.2 зазначено програмні аспекти. Нарешті в 6.2.3 обговорено, як можна виконати комбіновані оцінки.

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

SSCD має здійснити заходи безпеки, щоб виконати функціональні вимоги безпеки FPT_PHR1 (пасивне виявлення фізичної атаки) і FPT_PHP.3 (опір фізичній атаці). TSF, необхідний FPT_PHP.1, має виявити фізичне втручання, що може поставити під загрозу TSF, і забезпечити доказ втру­чання. Це зазвичай здійснюють покриттями, блокуваннями, ізоляціями й/або інкапсуляцією апаратури непрозорим герметичним матеріалом. Крім того, SSCD згідно з FPT_PHP.3 має пру­чатися фізичним атакам втручання, відповідаючи автоматично у такий спосіб, що TSF не пору­шено. Цього можна досягти датчиками виявлення втручання й властивостями занулення SCD та інших секретів, захистом від відмови середовища (EFP) або запуском перевірки захисту EFT від відмови середовища. Ці TSF можна здійснити повністю апаратними засобами, але їх також можна реалізувати програмним забезпеченням (наприклад, активні екрани чипа мікропроцесорної картки, які перевіряє операційна система). Засіб створення підпису, повністю реалізований програмно, не може в такий спосіб окремо захистити SCD від фізичної атаки втручання. Для SSCD, реалізованого на мікропроцесорній картці, де є тільки доступна напруга, коли картка вставле­на в засіб читання карток, опір втручанню й занулення SCD могли, наприклад, відбутися як частина початкової процедури самотестування разом із вмиканням живлення.

Функціональну вимогу безпеки FDP_EMSEC.1 (випромінювання ТОЕ) часто здійснюють комбінацією апаратних і програмних засобів (заходів) безпеки. Апаратні співпроцесори викори­стовують не тільки для прискорення криптоалгоритмів, але й для забезпечення властивостей безпеки, щоб захистити SCC від простого й диференціального аналізу споживаної потужності, часових атак і інших атак, заснованих на поведінці фізичної реалізації. Програмна реалізація TSF згідно з FCS_CKM.1 (генерація криптографічного ключа) і FCS_COP.1 (криптографічна операція) має використовувати ці властивості безпеки для процесу створення підпису.

TSF генерації пари SCD/SVD, як вимагає FCS_CKM.1 для SSCD типу Ті типу 3, має вико­ристовувати фізичний генератор випадкових чисел. Програмне забезпечення має здійснити криптоалгоритм, який створює пару SCD/SVD, і виконати тести фізичного генератора випадко­вих чисел згідно з FPT_TST.1 (тестування TSF).

Усі інші функціональні вимоги безпеки в РР взагалі може здійснити програмне забезпечен­ня, незалежне від апаратних засобів.

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

Апаратні засоби SSCD реалізують TSF з вимогами:

(а) відповідь апаратних засобів на виявлені FPT_TST.1 апаратні відмови згідно з FPT_FLS.1 (відмова зі збереженням безпечного статусу),

(b)FPT_PHP.1 (пасивне виявлення фізичної атаки) і FPT_PHP.3 (опір фізичній атаці),

(с) самоперевірка апаратних ресурсів, як вимагає FPT_TST.1 (самоперевірка TSF).

Крім того, апаратні засоби, як передбачено, забезпечують функції, що підтримують FCS_CKM.1 (генерація криптоключа), FCS_COP.1 (криптооперація) і FPT_EMSEC.1 (випроміню­вання ТОЕ). Для FCS_CKM.1 необхідний такий генератор випадкових чисел, як апаратне дже­рело шуму, що відповідає умовам [ALGO].

Для функцій можна використовувати криптографічний співпроцесор, стандартний для смарт- карток, або універсальний процесор, що виконує криптооброблення. Крім аспектів продуктив­ності, конструктор може використати спеціалізований криптосопроцесор для розробки SSCD, стійкий проти таких атак, як [DPA] щодо FPT_EMSEC.

6.2.2.2 Операційна система

Програмне забезпечення операційної системи управляє апаратними ресурсами й надає послуги застосуванням. Програмне забезпечення операційної системи реалізує:

1. криптоалгоритми для FCS_CKM.1 і FCS_COP.1, у той час як параметри визначають дані TSF застосування. Ці TSF виконують FPT_EMSEC.1, використовуючи криптографічний співпро­цесор і генератор випадкових чисел апаратної платформи;

2. керування доступом до файлів, ключів і еталонних даних автентифікації, заснованих на даних TSF застосування;

3. ідентифікація згідно з FIA_UID.1 (синхронізація ідентифікації), автентифікація згідно з FIA_UAU.1 (синхронізація автентифікації) і керування еталонними даними автентифікації згідно з FIA_AFL.1 (обробка невдалої автентификації) і FIA_ATD.1 (визначення користувацьких атрибутів);

4. автоматична перевірка цілісності збережених даних згідно з FDP_SDL1 (моніторинг цілісності збережених даних);

5. повторне використанню об’єкта для криптографічних особистих і секретних ключів і даних автентификації згідно з FDP_RIP.1 (захист підмножини залишкової інформації);

6. відповідь операційної системи на виявлені FPT_TST.1 (самоперевірка TSF) апаратні або програмні відмови згідно з FPT_FLS.1 (відмова зі збереженням безпечного статусу);

(д) самотестування згідно з FPT_TST.1 (самотестування TSF) для реалізації криптоалго- ритмів, генератора випадкових чисел і властивостей керування доступом;

(h) кодування й криптографічні механізми контрольних сум для даних уводу-виводу на підтримку FDP_UIT.1 (цілісність обміну даними), FTPJTC.1 (надійний канал міжТЗР) і FTP_TRP.1 (надійний шлях) залежно від даних TSF (ключів) застосування.

6.2.2.3 SSCD застосування

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

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