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

Другий крок персоналізації — генерація сертифіката — описано в 7.1.3.

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

Надійний шлях/канал між засобом уводу даних і SSCD гарантує конфіденційність фрази проходу або іншої інформації автентифікації.

У разі множинних невдач автентифікації здійснюють політику блокування SSCD.

11.4.3 Надійний шлях і канали

Усі системи вимагають принаймні:

• для SSCD типу 2 надійний канал для імпорту SCD у SSCD;

• для SSCD типу 3 надійний канал для експорту SVD у CGA;

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

• для єдиного обчислювального засобу надійна лінія зв’язку між засобом уводу даних і SSCD. Тип лінії зв’язку (шлях або канал) залежить від конструкції ПК і того, як засіб уводу даних підключено до системи;

• надійний канал між обчислювальним механізмом і засобом виводу.

Система класу 1DH вимагає принаймні:

• надійний канал між відділеними частинами застосування SCA. Цей шлях — точка входу DTBSR у систему;

• надійний канал між SCA, що відображає геш засобу й SSCD.

Система класу 2DH вимагає принаймні:

• надійний шлях між відділеними частинами застосування SCA. Цей шлях — точка входу DTBSR у систему;

• надійний шлях між SCA, що відображає геш засобу й SSCD.

Система класу 1DM вимагає принаймні:

• надійний канал між SCA і SSCD.

Система класу 2DM вимагає принаймні:

• надійний шлях між SCA і SSCD.

12 ПОСЛУГИ ПІДПИСУВАННЯ

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

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

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

Іншою головною проблемою, що має вирішити послуга підписання, є створення надійного шляху між користувачем і SCA і надійного шляху між SCA і SSCD. Для послуги підписання надійний шлях, імовірно, доведеться встановити по відкритому Інтернету. Крім того, здатність належним чином дістати згоду користувача використовувати SCD зажадала б надійного шляху між SSCD і поточною платформою, де користувач постійно перебуває.

Ці проблеми технічно здійсненні; однак вибір обмежено з поточного покоління апаратних засобів і програмного забезпечення.

ДОДАТОК I
(довідковий)

ПОРІВНЯННЯ ПРОФІЛІВ ЗАХИСТУ

У 6.2 ідентифіковано багато зв’язаних профілів захисту, яким конструктор хотів би відпові­дати на додаток до [SSCD РР]. Кілька випадків, які можна було б розглянути щодо комбінації оцінювання цих РР, обговорено в 6.2. У цьому додатку наведено деталі зв’язаних РР. Тому в АІ.1 наведено порівняння об’єктів безпеки, які накладають різні РР. В АІ.2 описано вибір SFR у різних PP_S.

АІ.1 Порівняння об’єктів безпеки

Цей розділ проводить порівняння між об’єктами безпеки [SSCD РР] та Eurosmart РР [РР 0010] і [РР 0002] (відповідно РР [SCSUG]), відповідаючи на запитання: «Якщо потрібно було написа­ти об’єкти безпеки, вимагаючи відповідності з [SSCD РР] і Eurosmart [РР 0010] (resp. [РР 0002] або [SCSUG]) РР, які об’єкти безпеки кожного допомогли б гарантувати об’єкти безпеки один одного?».

Для кожного об'єкта безпеки відповіді на це питання можуть бути досить прямими або, що частіше, залежати від додаткових припущень або тверджень про розробку або наявність влас­тивостей SSCD. У контенті цього розділу виділено питання, на які потрібно відповісти, намага­ючись скласти ST, що відповідає обом Eurosmart [РР 0010] (resp. [РР 0002] або [SCSUG]) PP_S.

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

Розглянутий SSCD (його тип немає значення) здійснено на смарт-картці й призначено для вставлення й використання в терміналі (наприклад, пристрій прийняття карток CAD). Отже, фаза персоналізації SSCD відповідає фазі персоналізації смарт-картки, а фаза використання й зни­щення SSCD — закінченню використання смарт-картки. Автентифікацію підписувана виконує зовнішній засіб, підключений (можливо, як частина) до термінала.

Оскільки певне застереження треба надати щодо цих різних моделей життєвого циклу, поданих у різних РР і розглянутих у цьому розділі, рисунок АІ.1 ілюструє різні моделі життєвого циклу [РР] і Eurosmart РР ([РР 9806] і [РР 0010], resp. [РР 0002]).

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

Архітектура

Виготовлення

Ініціалізація

Персоналізація

Використання

Знищення

S ю о

co О Q.

с Ш

ш

[SSCD РР] Модель життєвого циклу

РР 0002

ТОЕ доставка

ю о О. го О О.

с то

ш

Етап
виробництва

Фаза 1: Розробка вбудованого програмного забезпечення для смарт-карток

Фаза 2: Розробка ІС

Фаза 3: ІС виробництво й тестування

Фаза 4: ІС атакування й тестування

Фаза 5: Процес закінчення продукту смарт-картки

Фаза 6: Персоналізація смарт-картки

Фаза 7: Кінцеве використання смарт-картки

Eurosmart РР Модель життєвого циклу (спрощена) [РР 9806]/
[РР 0010], resp. [РР 0002]

Рисунок АІ.1

АІ.1.1 SSCD проти Eurosmart РР0010

АІ.1.1.1 Сфера застосування ТОЕ

Профіль захисту Eurosmart [РР 0010] визначає вимоги для мультиприкладної платформи смарт-картки, вбудованої в інтегральну схему, так само як для її життєвого циклу, визначаючи фази, пронумеровані від 1 (впроваджена розробка програмного забезпечення) до 7 (закінчен­ня використання). Платформа включає операційну систему, завантажуваний інтерфейс прикладної системи, ІС спеціалізованого програмного забезпечення (поза ТОЕ, але підлеглий вимогам [РР 9806]) і, можливо, рідні застосування.

Операційна система платформи підтримує завантаження застосування протягом персона- лізації або на фазах кінцевого використання (фази 6 і 7 відповідно). Розробку й включення рідних застосувань можна пророкувати; вони вже виконані як фаза 1 і включені у фазу 3 (виробництво ІС), 6 (персоналізація) або 7 (кінцеве використання).

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

Проблеми безпеки мають справу з об’єктами безпеки, заявленими в цьому РР, їх можна одержати в підсумку:

— підробка або пасивне прослуховування функцій безпеки ТОЕ, даних TSF і користуваць­ких (завантажених і рідних застосувань) даних,

— захист від імітації,

— безпека розробки, усунення недоліків,

— мультиприкладне керування:

• відмовостійке завантаження,

• керування доступом у завантаженні застосування й операціях видалення,

• керування конфіденційністю, цілісністю, дійсністю завантажених застосувань,

• видалення залишкової інформації, асоційованої з вилученими застосуваннями,

• сегрегація й стримування ресурсів між застосуваннями.

Питання, на які потрібно відповісти:

— чи дійсно SSCD — рідне або завантажене застосування? На якій фазі воно вставлено? (життєвий цикл на рис. 5 в CWA, на рис. З в SSCD РР відповідно швидше вказує рідне застосу­вання, завантажене виробником картки);

— SSCD середовище функціонування (у значенні СС) починається з фази 6, a Eurosmart проектує його на фази 4-7. Потрібно бути обережним у контексті (SSCD або Eurosmart), чита­ючи такі терміни як «розробка», «операція» чи «життєвий цикл»;

— тут є додаткові застосування (завантажені чи рідні), яким дозволено перебувати разом із SSCD? Дозволено завантаження застосувань на фазі кінцевого використання?

— чи залежить знищення SSCD від операцій видалення застосування, передбачуваних Eurosmart РР, або це фізичне знищення (SSCD РР не погоджується із цим пунктом, однак зни­щення SCD обговорено докладно в 5.2.4 цього стандарту)?

— чи допускає автентифікацію користувача безпечний протокол комунікації з терміналом картки? Інші контрольні точки ідентифіковано нижче як умови для відповідності об’єктам безпеки.

АІ.1.1.2 Порівняння об’єктів безпеки

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

Деякі цілі безпеки для середовища Eurosmart РР частково відповідають об’єктам безпеки для ТОЕ від SSCD РР. Це означає, що відповідність із SSCD РР допомагає виконувати вимоги/при- пущення до середовища з позицій Eurosmart РР. Щоб зазначити об’єкти безпеки для середови­ща, їхні префікси змінено з 'О.' на 'ОЕ.'; для цілей TOE [SSCD РР] використано префікс 'ОТ'.

Об’єкт OT.EMSECJDesign (від SSCD РР) повністю відповідає об’єкту О.SIDE (від Eurosmart РР).

Об’єкт OT.Init може відповідати OE.INIT_ACS за умови, що область видимості останнього об’єкта («дані ініціалізації мають бути доступні тільки авторизованим особам (фізичними, пер­сональними, організаційними, технічними процедурами).») ефективно відповідають примітці SCD/SVD, що SCD не можна постачати жодній особі й також SCD не можна вважати даними ініціалізації, як визначено в [РР 9911]. Об’єкт OT.Lifecycle_Security відповідає О.FLAW за умови усунення помилок.

Об’єкт OT.SCD_Secrecy може відповідати O.DIS_MECHANISM2 за умови, що область засто­сування останнього об’єкта («захист механізмів безпеки ES від несанкціонованого розкриття») має на увазі нерозголошення SSCD.

Об’єкт OT.TamperJD перебуває в прямому протиріччі з O.TAMPER_ES, a O.Tamper_Resistance повністю відповідає йому. Протиріччя є між ‘запобіганням’ і ‘виявленням’ втручання. Певною мірою розходження відбувається через [SSCD РР], визначеного як нейтральний до технології, a Eurosmart РР строго стосуються смарт-карток.

Об єкт OT.DTBS_lntegrity_TOE відповідає O.MOD_MEMORY (наскільки допускає захист DTBS- подань, збережених у межах ТОЕ) і може відповідати OE.USE_DIAG (наскільки допускає захист DTBS-подань між SCA і SSCD). Потрібно розглянути вимоги [SSCD РР], щоб ТОЕ зберіг цілісність DTBS-подання, a O.USE_DIAG — об'єкт вимоги.

Об’єкт OT.Sigy_Sig може відповідати OE.USE_DIAG за умови, що «безпечні протоколи кому­нікації між смарт-карткою й терміналом», до якого звертається цей останній об’єкт, мають на увазі автентифікацію користувача. Зазначимо, що автентифікація користувача не є настільки явною в Eurosmart РР, як у [SSCD РР].

Об’єкт OE.HI_VAD може відповідати OE.USEJDIAG за умови, що «безпечні протоколи кому­нікації між смарт-карткою й терміналом», до якого звертається цей останній об’єкт, мають на увазі автентифікацію користувача й відповідний захист (конфіденційність і цілісність) даних автентифікації VAD для передачі між терміналом і смарт-карткою.

АІ.1.2 SSCD проти Eurosmart РР0002

АІ. 1.2.1 Сфера застосування ТОЕ

Профілі захисту [РР 0002] визначають вимоги для платформи смарт-картки ІС, що складаєть­ся із процесора, компонентів безпеки, портів уводу-виводу й пам’яті (енергозалежної й такої, що не руйнується). Програмне забезпечення покрите як „спеціалізоване програмне забезпечення» (убудоване програмне забезпечення) для розширення, оскільки воно існує внаслідок постачання виготовника ІС. Також РР головним чином зацікавлені в апаратному дизайні й стадіях розробки.

[РР 0002] стосуються Eurosmart РР у деякому розумінні, визначаючи ті самі «сім фаз» моделі життєвого циклу, обговореної в АІ. 1.1.1.

РР визначають користувацькі дані як первинний актив, захищений (крім таких інших, як убудоване програмне забезпечення, дані ініціалізації, дані попередньої персоналізації). Тому витік користувацької інформації підкреслено як загрозу, яку необхідно запобігти. Крім того, врахова­но якість генераторів випадкових чисел. Вторинні активи також покривають дизайн ІС і інфор­мацію фізичної реалізації.

[РР 0002] визначають три мети безпеки високого рівня:

• SG1: підтримати цілісність користувацьких даних і убудованого програмного забезпечення;

• SG2: підтримати конфіденційність користувацьких даних і убудованого програмного забезпечення;

— SG3: забезпечити випадкові числа.

АІ.1.2.2 Порівняння об’єктів безпеки

Порівнюючи об’єкти [SSCD РР] і [РР 0002], маємо певну відповідність, де користувацькі дані, насамперед SCD, мають бути захищені. Також [РР 0002] надає апаратну платформу для SSCD (подібно [РР 9806]).

Об’єкт OT.EMSEC_Design [SSCD РР] відповідає об’єкту O.LeakJnherent і O.Leak_Forced в [РР 0002].

OT.SCD_Secrecy [SSCD РР] відповідає O.LeakJnherent і O.Phys-Probing.

OT.TamperJD і OT.Tamper_Resistance [SSCD РР] стосуються O.Phys-Probing і O.Phys- Manipulation [РР 0002].