19 мон ГЮІ 2015. 1. 9 Вимоги та їх реалізація при побудування засобів криптографічного захисту інформації
 Скачать 227.06 Kb.
|
|
Один оператор може приймати безліч ролей. Якщо криптографічний модуль підтримує паралельні оператори, то модуль повинен внутрішньо забезпечувати розподіл ролей, прийнятих кожним оператором, і відповідні послуги. Від оператора не потрібно прийняття санкціонованої ролі для виконання послуг, де CSP і PSP відповідних установок модифікуються, не розкриваються або замінюються (напр., послуг представлення стану «show status», самотестування «self-tests» або інших послуг, які не впливають на захист модуля). Механізми аутентифікації можуть знадобитися в межах криптографічного модуля для аутентифікації оператора, що здійснює доступ до модуля, і для верифікації того, що оператор санкціонований на прийняття запитуваної ролі та виконання послуг у межах ролі. 2.1.8 Модель кінцевого стану Операції криптографічного модуля повинні бути описані з використанням моделі кінцевого стану (або її еквівалента), представленої діаграмою переходу станів та / або таблицею переходу станів. Діаграма переходу станів та / або таблиця переходу станів включає: всі операційні і помилкові стану криптографічного модуля; відповідні переходи з одного стану в інший стан; вхідні події, які викликають переходи з одного стану в інший; вихідні події, створювані в результаті переходів з одного стану в інший. Криптографічний модуль повинен включати наступні операційні і помилкові стани. 1. Стани включення / виключення живлення. Стани для первинної, вторинної чи резервної потужності. Ці стани можуть різнитися між джерелами напруги, що подається на криптографічний модуль. 2. Стану кріптоінспектора. Стани, в яких виконуються послуги кріптоінспектора (напр., криптографічний ініціалізація і керування ключами). 3. Стану вводу CSP / PSP параметрів. Стани для введення CSP параметрів і PSP параметрів у криптографічний модуль. 4. Користувальницькі стани. Стани, в яких санкціоновані користувачі отримують послуги захисту, виконують криптографічні операції або виконують інші затверджені або незміцненої функції. 5. Стану самотестування. Стани, в яких криптографічний модуль виконує самотестування. 6. Помилкові стани. Стани, коли криптографічний модуль стикається з помилкою. Помилкові стани можуть включати «жорсткі» помилки, які вказують на неправильне функціонування обладнання, і які можуть вимагати експлуатаційної підтримки, обслуговування або відновлення криптографічного модуля, або відновлюваністю «м'які» помилки, які можуть вимагати ініціалізації або скидання модуля. Відновлення з помилкових станів повинно бути можливим, за винятком станів, викликаних «жорсткими» помилками і вимагають експлуатаційної підтримки, обслуговування або відновлення криптографічного модуля. Криптографічний модуль може містити інші стани, включаючи, але не обмежуючись, наступними: 1. Стани обходу. Стани, в яких активується здатність обходу, а послуги забезпечуються без криптографічного обробки (напр., передачі відкритого тексту за допомогою криптографічного модуля). 2. Стани експлуатаційної підтримки. Стани для експлуатаційної підтримки та обслуговування криптографічного модуля, включаючи фізичне і логічне експлуатаційне тестування. Якщо криптографічний модуль містить експлуатаційну роль, то має бути включено стан експлуатації. 2.1.9 Фізичний захист Криптографічний модуль повинен застосовувати механізми фізичного захисту для обмеження несанкціонованого фізичного доступу до вмісту модуля і для обмеження доступу для несанкціонованого використання або модифікації модуля (включаючи заміну всього модуля) при інсталяції. Всі апаратні, програмні, програмно-апаратні компоненти та компоненти даних у межах криптографічних кордонів повинні бути захищені. Криптографічний модуль, який повністю програмно реалізований так, щоб фізична захисту була забезпечена тільки головною платформою, не підкоряється вимогам фізичного захисту цього стандарту. Вимоги фізичного захисту задаються для трьох певних фізичних виконань криптографічного модуля. 1. Однокристальні криптографічні модулі - фізичні виконання, в яких єдиний ІС чіп може використовуватися як автономний пристрій або може бути вбудований в корпус або продукт, які можуть бути фізично не захищеними. Прикладами однокристальних криптографічних модулів можуть бути ІС чіпи або смарт-карти в одному ІС чіпі. 2. Багатокристальні вбудовані криптографічні модулі - фізичні виконання, в яких кілька ІС чіпів взаємопов'язані і вбудовані в корпус або продукт, які можуть бути фізично не захищеними. Прикладами багатокристальних вбудованих криптографічних модулів можуть бути адаптери або плати розширення. 3. Багатокристальні автономні криптографічні модулі - фізичні виконання, в яких кілька ІС чіпів взаємопов'язані і весь корпус є фізично захищеним. Прикладами багатокристальних автономних криптографічних модулів можуть бути маршрутизатори шифрування або захищена радіозв'язок. Залежно від механізмів фізичного захисту криптографічного модуля несанкціоновані спроби фізичного доступу або модифікації повинні мати високу ймовірність виявлення: після спроби по залишилися видимими ознаками (тобто, доказ вторгнення) та / або під час спроби доступу так, що криптографічним модулем можуть бути зроблені відповідні миттєві дії для захисту CSP параметрів і PSP параметрів (тобто реагування на вторгнення). Миттєві дії повинні застосовуватися для того, щоб пошук CSP параметрів і PSP параметрів був неможливим. Зазвичай Рівень Захисту 1 вимагає мінімальну фізичний захист. Рівень Захисту 2 вимагає додавання запобіжних механізмів. Рівень Захисту 3 додає вимоги щодо використання міцних корпусів з механізмами виявлення та реагування на вторгнення для знімних кришок і люків. Рівень Захисту 4 додає вимоги щодо використання міцних корпусів з механізмами виявлення та реагування на вторгнення для всього корпусу. На Рівні Захисту 4 потрібен захист від відмов, пов'язаних з навколишнім середовищем, (EFP) або тестування на відмови, пов'язані з навколишнім середовищем, (EFT). Детектування вторгнень і реагування на вторгнення не замінює доказ вторгнень. 2.1.10 Операційне середовище Операційне середовище криптографічного модуля пов'язана з управлінням програмними, програмно-апаратними та / або апаратними компонентами, необхідними для роботи модуля. Операційне середовище може бути не модифікованим (напр., програмно-апаратні засоби, що містяться в ROM, або ПЗ, що містяться в комп'ютері, що блокуються за допомогою пристроїв введення / виводу) або модифікується (напр., програмно-апаратні засоби, що містяться в RAM або ПЗ, виконувані комп'ютером загального призначення). пераційна система є важливим компонентом операційного середовища модуля. У цьому пункті описані три конкретні операційних середовища. Кожна середа відрізняється від іншої, і для неї може або не може вимагатися. 1. Операційне середовище загального призначення пов'язане з використанням комерційно доступною операційної системи загального призначення (тобто менеджера ресурсів), керуючої програмними та програмно-апаратними компонентами в межах криптографічних кордонів, а також керуючої процесами / потоками системи та оператора (-ів), включаючи прикладну програму загального призначення, таку як текстові процесори. 2. Обмежене операційнеа середовище пов'язане зі статичним немодіфікуємим операційним середовищем (напр., JAVA віртуальна машина на непрограмміруємой ПК карті) без використання базової операційної системи загального призначення, на якій унікально розміщене операційне середовище. 3. Операційне середовище, що може модифікуватись, може бути реконфігуріроване для додаве / видалене / модифікації функціональності і / або може включати можливості операційної системи загального призначення (напр., використання комп'ютерної ОС, конфігурується ОС смарт-карти або програмованих програмно-апаратних засобів). Операційні системи вважаються модифікуємими операційними середовищами, якщо програмні / програмно-апаратні компоненти можуть бути модифіковані оператором та / або якщо оператор може завантажувати і виконувати ПЗ або програмно-апаратні засоби (напр., текстовий процесор), які не були включені як частина атестації модуля. Якщо операційне середовище є модифікуємим операційним середовищем, то повинні застосовуватися вимоги по операційній системі . Якщо операційна середовище є немодіфіціруємим або є обмеженим операційним середовищем, вимоги по операційній системі не застосовуються. Документація повинна описувати операційне середу для криптографічного модуля, включаючи, якщо це доречно, операційну систему, застосовувану модулем, і для рівнів захисту 2, 3 і 4, профілю захисту та гарантійного рівня згідно ISO / IEC 15408 вимогам по операційній системі. 2.1.11 Управління криптографічними ключами Вимоги захисту для управління криптографічними ключами включають повний життєвий цикл CSP і PSP параметрів, застосовуваних криптографічним модулем. Управління ключами включає генерацію випадкових бітів і генерацію випадкових ключів, встановлення ключів, розподіл ключів, введення / виведення ключів, зберігання і обнулення ключів. Криптографічний модуль може також застосовувати механізми управління ключами іншого криптографічного модуля. Зашифрованими CSP називаються CSP параметри, які зашифровані з використанням затвердженого алгоритму або затвердженої функції захисту. ПРИМІТКА: CSP параметри, зашифровані з використанням незатвердженого алгоритму або власного (proprietary) алгоритму або методу, маються на увазі уявними у відкритому вигляді в межах цього стандарту. CSP параметри повинні бути захищені в межах криптографічного модуля від несанкціонованого розкриття, модифікації і заміни. PSP параметри повинні бути захищені в межах криптографічного модуля від несанкціонованої модифікації і заміни. Документація повинна описувати всі CSP параметри і PSP параметри, застосовувані криптографічним модулем. Документація повинна описувати операційну середу для криптографічного модуля, включаючи, якщо це доречно, операційну систему, застосовувану модулем, і для рівнів захисту 2, 3 і 4, профілю захисту та гарантійного рівня згідно ISO / IEC 15408 вимогам по операційній системі. 2.1.12 Самотестування |