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

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

Повідомлення подають на екрані засобу SDP (компонент відображення документа підпи­сувана) SCA, що постійно перебуває на засобі.

Якщо засіб підписання може відобразити тільки обмежену кількість даних, SCA фактично складена із двох частин: одна — на засобі, а інша — на віддаленому терміналі. Віддалена тер­мінальна частина SCA містить SDP так само, як компонент гешування даних (DHC — Data Hashing Component), що подасть дані, виконає гешування, відобразить результуюче значення геш-функції й також надішле значення геш-функції в засіб. Значення геш-функції буде відобра­жено також на засобі для гарантії цілісності DTBSR, відісланого з віддаленого термінала на засіб.

7.4 Випадки використання

Відомі такі випадки використання

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

Блок відображення повідомлень може однозначно відобразити повідомлення користувачеві й одержати його згоду виконати підпис.

Прикладом цього типу системи є спеціалізований продукт засобу підписання або ПК, що має безпечну операційну систему з надійним уводом-виводом для всіх засобів уводу й виводу. Інший приклад — SIM-карта, що містить SSCD і SCA, що тільки використовує мобільний телефон як засіб надійного вводу-виводу.

Система класу 1DM може також виконати ті самі функції, що й система класу 1DH, тобто відобразити геш замість закінченого повідомлення.

У цієї системи є два обчислювальних модулі: основний процесор і SSCD. Система забез­печує надійний шлях між SCA основної системи й SSCD.

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

Прикладом цієї системи є ПК або кишеньковий комп’ютер з SSCD, прикріпленим як смарт- картка чи засіб USB, або мобільний телефон з S/WIM, у якому повідомлення — досить коротке, щоб відобразити його на телефоні.

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

Однак блок відображення не здатний відобразити все повідомлення й відображає тільки геш повідомлення. Тому потрібен надійний канал між віддаленою частиною SCA (відображає повідом­лення й виконує гешування) і локальною частиною SCA.

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

SCA також містить віддалений компонент SDP і DHC. Система забезпечує надійний канал між DHC і SSCD.

Прикладом цього типу системи є мобільний телефон з SSCD в S/WIM (заснований на SIM WIM), що застосовують для підписання повідомлень, які неможливо відобразити безпосередньо на телефоні. Частина локального SCA постійно перебуває на S/WIM, використовуючи процесор мобільного телефону тільки, щоб відобразити значення геш-функції. Основна частина SDP і DHC утримується у віддаленому кінцевому застосуванні, наприклад, відображаючи повідомлення, що буде підписано в web-браузері.

8 НАСТАНОВИ З РЕАЛІЗАЦІЇ СМАРТ-КАРТОК

Смарт-картки зараз є очевидними SSCD. Вони безпечні, належать особі й дають користу­вачеві мобільність. Смарт-картки доступні як SSCD типу 2 і типу 3 (без і з убудованою генера­цією ключів).

Смарт-картки — природний компонент системи створення підписів класу 2, оскільки смарт- картки не містять SCA.

Персоналізація охоплює генерацію SCD/SVD і імпорт SCD або експорт SVD за потреби. Є дві можливості для генерації ключів:

• генерація ключа, виконана поза карткою. Це означає, що SSCD типу 2 згідно [SSCD РР], з вимогою до надійного каналу для імпорту SCD. У цьому випадку генерацію ключа зазвичай виконує виготовник смарт-картки або CSP, що пропонує послуги постачання SSCD. Тоді смарт- картку постачають користувачеві з попередньо згенерованими ключами;

• генерація ключа безпосередньо в смарт-картці, «убудована генерація ключа». Смарт- картка з убудованою генерацією ключа є SSCD типу 3 згідно з [SSCD РР]. Генерацію ключа може ініціювати виготовник, CSP або користувач безпосередньо після одержання смарт-картки.

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

Для смарт-картки автентифікація користувача виконана протягом уводу алфавітно-цифро­вого значення PIN-коду через інтерфейс користувача. Інтерфейс користувача може бути клавіа­турою, якою управляє SCA (наприклад, ПК або клавіатура кишенькового комп’ютера), або кла­віатурою PIN-коду безпосередньо на терміналі смарт-картки.

Надійний шлях установлюють між інтерфейсом користувача й смарт-карткою, гарантуючи конфіденційність коду. Природно, це легко зробити на клавіатурі PIN-коду термінала смарт-картки.

Після визначеного числа помилкових спроб картку буде блоковано. Її можна відкрити після вводу PIN-коду розблокування ключа (PUK — PIN Unblocking Key).

• класі 2 SCS важливе припущення для SSCD — надійний канал до SCA. Для смарт-карток це спричиняє автентифікацію SCA і механізм, що підтримує надійний канал. Наведені далі механізми для установки надійного каналу можна використовувати для смарт-карток:

• безпечний обмін повідомленнями, як визначено в [ISO 7816]; детальніше див. 5.2.1.2;

• зовнішня автентифікація, як визначено в [ISO 7816].

Надійні канали й шляхи також установлюють у таких цілях:

• надійний канал необхідний для імпорту SCD у смарт-картку від SSCD типу 1, коли вико­нано генерацію ключа поза смарт-карткою;

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

• надійний шлях потрібен для вводу користувачем даних автентифікації (PIN-код) у смарт-картку.

8.2 Середовище SSCD

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

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

У другому випадку типове середовище таке, що SCA розташовано в такому публічному місці, як залізнична станція, банк або будь-який інший SCA, яким управляє провайдер послуг, не обов'язково пов’язаний з або під керуванням підписувана.

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

9 НАСТАНОВИ З РЕАЛІЗАЦІЇ МОБІЛЬНИХ ТЕЛЕФОНІВ

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

Далі «мобільний телефон» використовують, щоб позначити закінчений кишеньковий засіб, складений із мобільного обладнання (ME) безпосередньо й з будь-яких SIM-карток, чипів або інших смарт-карток, вставлених у нього.

Теоретично мобільний телефон може бути класом 1 або класом 2 SCS. Хоча можна вико­ристовувати телефон безпосередньо, щоб здійснити SSCD, очікується, що він зазвичай буде класу 2 SCS із SSCD, здійснюваним на SIM-карті, можливо, відповідно до стандарту WIM (картка S/WIM). Інша цікава можливість полягає в тому, що сама SIM-карта становить клас 1 SCS, використовуючи ME також як надійний засіб уводу-виводу для уводу PIN-коду й відображення.

Також можна здійснити SSCD на окремому чипі, відмінному від SIM-карти. Це рішення вимагає телефона з "двома слотами" або "двома чіпами", куди окрема смарт-картка або чип (що використовує WIM або інший стандарт) вставлено у телефон. Однак під час розробки цьо­го документа таке рішення, здається, не мало інтересу й тому далі не обговорено.

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

• як клас 1DM, де повідомлення досить мале для подання на дисплеї телефону. Тоді закінчені SCA, включаючи SDP і DHC, постійно перебувають на SIM-карті разом із SSCD;

• як клас 2DM, де повідомлення досить мале для подання на дисплеї телефону. Однак тоді SDP і DHC постійно перебувають на мобільному обладнанні, a SSCD — на SIM;

• як система класу 2DH, де повідомлення занадто велике для подання по телефону, тільки значення геш-функції подано й підписано.

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

У цьому разі фактично є два способи реалізації SCA:

— SCA на ME. Тоді SCA постійно перебуває на мобільному обладнанні й тільки передає зна­чення геш-функції SIM-карті, яка має встановити надійний канал з SCA, щоб одержати DTBSR і передати назад SDO (підписаний об’єкт даних). Також необхідний надійний канал для уводу даних автентифікації з клавіатури ME;

— SCA на SIM безпосередньо. Тоді SCA постійно перебуває на SIM разом з SSCD, спільно використовуючи обчислювальний механізм SIM. Через API SIM Toolkit телефону SCA використо­вує тільки дисплей телефону як SDP (засіб перегляду), а клавіатуру як засіб уводу даних для автентифікації (PIN-код). Тоді SIM-карта фактично здійснює тип 1DM системи.

Повідомлення, що буде підписано, є занадто великим для подання на екрані ME. Замість цього повідомлення подане, наприклад, в Web-браузері, що постійно перебуває на ПК. Засто­сування підписання тоді гешує повідомлення й посилає геш у телефон для підписання. Щоб гарантувати, що в значення геш-функції не втрутилися по шляху, частину значення геш-функції подано як шістнадцятковий рядок у браузері/засобі перегляду й на екрані телефону.

Коли тільки значення геш-функції посилають на телефон для підписання, SCA фактично складається із двох частин: одна — у мобільному телефоні, а інша — у віддаленому терміналі, кожна містить SDP, як і DHC. Разом дві частини SCA гарантують цілісність DTBSR (значення геш- функції), надіслане з віддаленого термінала на телефон. Це можна зробити, порівнюючи зна­чення геш-функції, подані в обох частинах SCA, таким чином дозволяючи користувачеві верифі- кувати їхню коректність.

Персоналізація охоплює генерацію SCD/SVD і імпорт SCD або експорт SVD за потреби. Є дві можливості виконати генерацію ключів:

• генерація ключа, виконана поза карткою. Це означає, що SSCD має тип 2 згідно [SSCD РР] із вимогою до надійного каналу для імпорту SCD. У цьому випадку генерацію ключа зазвичай виконує виготовник SIM-карти або оператор мобільного зв’язку. A SIM постачають користувачеві з попередньо згенерованими ключами;

• генерація ключа в смарт-картці безпосередньо, «убудована генерація ключа». SIM-карта з убудованою генерацією ключа є SSCD типу 3 згідно з [SSCD РР]. Генерацію ключа може тоді ініціювати виготовник, оператор або користувач безпосередньо після одержання SIM.

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

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