19 мон ГЮІ 2015. 1. 9 Вимоги та їх реалізація при побудування засобів криптографічного захисту інформації
 Скачать 227.06 Kb.
|
2.2.9 Довірений каналДовірений канал – це зв'язок, встановлений між криптографічним модулем і відправником або одержувачем для безпечного повідомлення незахищених CSP у вигляді відкритого тексту, ключових компонентів і даних автентифікації. Довірений канал захищає від підслуховування, а також фізичного або логічного вторгнення небажаних операторів / об'єктів, процесів або інших пристроїв, між визначеними портами введення та виведення модуля, уздовж лінії зв'язку, та передбаченою кінцевою точкою відправника або отримувача [10]. Рівні безпеки 1 і 2. Для Рівнів безпеки 1 і 2 немає ніяких вимог до довіреного каналу. Рівень безпеки 3. Для Рівня безпеки 3: для передачі незахищених CSP у вигляді відкритого тексту, ключових компонентів і даних автентифікації між криптографічним модулем і кінцевою точкою відправника або одержувача, криптографічний модуль повинен реалізовувати довірений канал; довірений канал повинен запобігати несанкціонованій модифікації, заміни та розкриттю через лінії зв'язку; фізичні порти, що використовуються для довіреного каналу, повинні бути фізично відокремлені від усіх інших портів, а логічні інтерфейси, що використовуються для довіреного каналу, повинні бути логічно відокремлені від усіх інших інтерфейсів; особистісна автентифікація повинна застосовуватись для всіх послуг, що використовують довірений канал і коли довірений канал перебуває у використанні, повинен бути відображений індикатор статусу. Рівень безпеки 4. На додаток до вимог Рівня безпеки 3, для Рівня безпеки 4 для всіх послуг, що використовують довірений канал, повинна застосовуватись багатофакторна особистісна автентифікація. 2.2.10 Ролі, послугиЗагальні вимоги до ролей, послуг і автентифікації. Криптографічний модуль повинен підтримувати уповноважені ролі для операторів і відповідних послуг в рамках кожної ролі. Один оператор може приймати кілька ролей. Якщо криптографічний модуль підтримує декілька одночасних операторів, то модуль повинен внутрішньо підтримувати розділення ролей, що приймаються кожним оператором і відповідними послугами. Оператор не зобов'язаний приймати уповноважену роль для виконання послуг, які не змінюють, не розкривають і не замінюють CSP та PSP (наприклад, відображення статусу, самотестування, або інші послуги, які не впливають на безпеку модуля) [10]. Щоб автентифікувати оператора, що здійснює доступ до модуля, і перевірити, що оператор уповноважений приймати запитувану роль і виконувати послуги в межах даної ролі, можуть знадобитися механізми автентифікації. Повинні виконуватися вимоги до документації. Ролі. Криптографічний модуль повинен , як мінімум, підтримувати роль криптослужбовця. Роль криптослужбовця повинна прийматися для виконання функцій криптографічної ініціалізації або керування і виконаннч загальних послуг безпеки (наприклад, ініціалізація модуля, управління CSP, PSP, і функції аудиту). Криптографічний модуль може підтримувати роль користувача. Якщо криптографічний модуль підтримує роль користувача, то роль користувача повинна прийматися для виконання загальних послуг безпеки, в тому числі криптографічних операцій та інших затверджених функцій безпеки. Криптографічний модуль може підтримувати роль технічного обслуговування. Роль технічного обслуговування приймається для здійснення фізичного та / або логічного технічного обслуговування (наприклад, відкриття службових дверцят, виконання певної діагностики, такої як вбудоване самотестування (BIST)). Всі незахищені SSP повинні бути обнулені при вході або виході з ролі технічного обслуговування. Криптографічний модуль може підтримувати й інші ролі на додаток до ролей, зазначених вище. Послуги. Загальні вимоги до послуг Під "послугами" маються на увазі всі послуги, операції або функції, які можуть бути виконані за допомогою модуля. Вхід послуги повинен складатися з усіх вхідних у модуль даних або керуючої інформації, які ініціюють або забезпечують роботу певних послуг, операцій або функцій. Вихід послуги повинен складатися з усіх даних і статусів на виході, що є результатом послуг, операцій або функцій, ініційовані або забезпечені входом послуги. Кожен вхід послуги повинен давати результат на виході послуги. Криптографічний модуль повинен надавати операторам наступні послуги. 1. Показати інформацію про версію модуля. Криптографічний модуль повинен виводити ім'я або ідентифікатор модуля та інформацію про версію, яка може бути співвіднесена з записом про засвідчення (наприклад, інформацію про версію апаратного забезпечення, програмного забезпечення та / або програмно-апаратного забезпечення). 2. Показати статус. Криптографічний модуль повинен виводити поточний статус. Може також включати в себе виведення індикатора статусу у відповідь на запит послуги. 3. Виконати самотестування. Криптографічний модуль повинен ініціювати і запускати попереднє самотестування. 4. Виконати затверджені функції безпеки. Криптографічний модуль повинен виконувати принаймні одну затверджену функцію безпеки, що використовується в затвердженому режимі експлуатації. 5. Виконати обнуління. Криптографічний модуль повинен виконувати обнуління параметрів. Криптографічний модуль може надавати інші послуги, операції або функції - як затверджені, так і незатверджені, на додаток до послуг, зазначених вище. Конкретні послуги можуть надаватися для більш ніж однієї ролі (наприклад, послуга введення ключа може надаватися і для ролі користувача, і для ролі криптослужбовця). Можливість обходу. Можливість обходу – це є здатність послуги частково або повністю обійти криптографічну функцію або процес. Якщо модуль може виводити конкретні дані або елементи статусу в криптографічно захищеній формі, або (в результаті налаштування модуля або втручання оператора) може також виводити елементи в незахищеному вигляді, то повинна бути визначена можливість обходу. Якщо криптографічний модуль реалізує можливість обходу, то: Оператор повинен приймати уповноважену роль, перш ніж настроювати можливість обходу; Дві незалежні внутрішні дії повинні знадобитися для активації можливості, щоб запобігти випадковому виведенню відкритих даних через єдину помилку. Дві незалежні внутрішні дії повинні змінювати поведінку програмного та / або апаратного забезпечення, яка пов’язана з можливістю обходу (наприклад, встановлюються два різні програмні або апаратні флаги, один з яких може бути ініційований користувачем) і Модуль повинен показувати статус, який відображає, чи є можливість обходу: 1. не активованою, і модуль надає послуги виключно з криптографічною обробкою (наприклад, дані у вигляді відкритого тексту зашифровуються), або 2. активованою, і модуль надає послуги виключно без криптографічної обробки (наприклад, дані у вигляді відкритого тексту не зашифровуються), або 3. поперемінно активованою і деактивованою, і модуль надає деякі послуги з криптографічною обробкою, а деякі послуги без криптографічної обробки (наприклад, для модулів з декількома каналами зв'язку дані у вигляді відкритого тексту зашифровуються або не зашифровуються в залежності від конфігурації кожного каналу). Можливість самоініційованого криптографічного виведення. Можливість самоініційованого криптографічного виведення - це здатність модуля виконувати криптографічні операції та інші затверджені функції безпеки або методи управління SSP без зовнішнього запиту оператора. Можливість самоініційованого криптографічного виведення повинна бути налаштована криптослужбовцем і ці налаштування можуть зберігатися після перезавантаження, скидання, або перепадів живлення модуля. Якщо криптографічний модуль реалізує можливість самоініційованого криптографічного виведення, то: для активації можливості повинні знадобитися дві незалежні внутрішні дії, щоб запобігти випадковому виведенню через єдину помилку. Дві незалежні внутрішні дії повинні змінювати поведінку програмного та / або апаратного забезпечення, яка пов’язана з можливістю (наприклад, встановлюються два різні програмні або апаратні флаги, один з яких може бути ініційований користувачем) і модуль повинен показувати статус, який відображає, чи активована можливість самоініційованого криптографічного виведення. Завантаження програмного/програмно-апаратного забезпечення. Якщо криптографічний модуль має можливість завантаження програмного або програмно-апаратного забезпечення з зовнішнього джерела, то повинні виконуватися наступні вимоги: завантажене програмне/програмно-апаратне забезпечення повинне бути перевірене засвідчувальним органом до завантаження для отримання засвідчення; виведення даних через інтерфейс виведення даних повинне бути заборонене доки програмне / програмно-апаратне забезпечення завантажується і тестування завантаження не буде успішно завершене; тестування завантаження програмного/програмно-апаратного забезпечення повинне бути здійснене до того, як завантажений код буде виконаний; криптографічний модуль повинен затримати виконання будь-яких завантажених або змінених затверджених функцій безпеки, доки не буде успішно виконане попереднє самотестування. До інформації про версію модуля повинні бути внесені зміни, що відображають додавання та / або оновлення завантаженого нового програмного або програмно-апаратного забезпечення. Якщо завантаження нового програмного або програмно-апаратного забезпечення повністю замінює образ модуля, то модуль повинен розглядатися як зовсім новий модуль, який потребує перевірки засвідчувальним органом для отримання засвідчення. Новий образ програмного або програмно-апаратного забезпечення повинен виконуватися тільки після перезавантаження при увімкненому живленні. Всі SSP повинні бути обнулені перед виконанням нового образу. |