Главная страница

19 мон ГЮІ 2015. 1. 9 Вимоги та їх реалізація при побудування засобів криптографічного захисту інформації


Скачать 227.06 Kb.
Название1. 9 Вимоги та їх реалізація при побудування засобів криптографічного захисту інформації
Дата11.01.2022
Размер227.06 Kb.
Формат файлаdocx
Имя файла19 мон ГЮІ 2015.docx
ТипДокументы
#328148
страница19 из 29
1   ...   15   16   17   18   19   20   21   22   ...   29

2.2.18 Управління чутливими параметрами безпеки



Загальні вимоги до управління чутливими параметрами безпеки. Чутливі Параметри Безпеки (SSP) складаються з Критичних Параметрів Безпеки (CSP) і Відкритих Параметрів Безпеки (PSP) [10]. Вимоги безпеки до управління SSP охоплюють весь життєвий цикл SSP, що використовуються модулем. Управління SSP охоплює генератори випадкових біт (RBG), генерацію SSP, встановлення SSP, введення / виведення SSP, зберігання SSP та обнуління незахищених SSP.

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

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

PSP в межах модуля повинні бути захищені від несанкціонованої зміни і заміни.

Модуль повинен пов'язувати SSP, які генерується, вводяться в або виводяться з модуля з об'єктом (тобто особою, групою, роллю або процесом), для якого ці SSP призначені.

Хеш-значення паролів, інформація про стан RBG і проміжні значення генерації ключа повинні розглядатися як захищені CSP. Повинні виконуватися вимоги до документації.

2.2.19 Генератори випадкових біт



Криптографічний модуль може містити RBG, ланцюг RBG, або може сам бути RBG. Затверджені RBG перераховані в Додатку В стандарту

Якщо затверджені функції безпеки, методи генерації SSP або встановлення SSP вимагають випадкових значень, то для надання цих значень повинні використовуватись затверджені RBG [10].

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

Генерація чутливих параметрів безпеки. Модуль може генерувати SSP внутрішньо або вони можуть бути отримані із SSP, введених в модуль.

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

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

Встановлення чутливих параметрів безпеки. Встановлення SSP може складатися з

  • методів автоматичного транспортування SSP або узгодження SSP або

  • ручного введення або виведення SSP прямими або електронними методами.

Автоматичне встановлення SSP повинне використовувати затверджені методи, перелічені в Додатку Г стандарту. Ручне встановлення SSP повинне відповідати вимогам.

Введення та виведення чутливих параметрів безпеки. SSP можуть бути вручну введені або виведені безпосередньо з модуля (наприклад, вводяться через клавіатуру або цифрову панель, або виводяться на монітор) або в електронному вигляді (наприклад, через смарт-карти / токени, PC-карти та інші електронні пристрої завантаження ключа, або операційну систему модуля). Якщо SSP вручну вводяться або виводяться з модуля, введення та виведення повинні здійснюватися через визначені інтерфейси HMI, SFMI, HFMI або HSMI.

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

При безпосередньому введенні SSP введені значення можуть тимчасово відображатися, щоб дозволити візуальний контроль і підвищити точність. Якщо в модуль безпосередньо вводяться зашифровані SSP, то значення SSP у вигляді відкритого тексту не повинне відображатися. Безпосередньо введені (відкриті або зашифровані) SSP повинні бути перевірені під час введення до модуля на точність за допомогою умовного тестування ручного введення.

Для запобігання ненавмисного виведення критичної (чутливої) інформації, повинні вимагатися дві незалежні внутрішні дії, для того, щоб вивести будь-які CSP у вигляді відкритого тексту. Ці дві незалежні внутрішні дії повинні регулювати виведення CSP.

При електронному введенні або виведенні через бездротове з'єднання CSP, ключові компоненти і дані автентифікації повинні бути зашифровані.

Введені вручну PSP не потребують криптографічної автентифікації.

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

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

Рівень безпеки 3. На додаток до Рівнів безпеки 1 і 2, для рівня безпеки 3 CSP, ключові компоненти і дані автентифікації повинні вводитися і виводитися з модуля або в зашифрованій формі або через довірений канал.

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

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

Рівень безпеки 4. На додаток до Рівня безпеки 3, для Рівня безпеки 4 модуль повинен використовувати окремі процедури багатофакторної особистісної автентифікації оператора для введення або виведення кожного ключового компонента.

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

Доступ до CSP у вигляді відкритого тексту неуповноваженими операторами повинен заборонятися. Зміна PSP неуповноваженими операторами повинна заборонятися.

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

Обнулені SSP не повинні відновлюватися або повторно використовуватися.

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

SSP не повинні відповідати цим вимогам щодо обнуління, якщо вони використовуються виключно щоб представляти дані у вигляді відкритого тексту процесам, які є проксі-серверами автентифікації (наприклад, CSP, що є ключем ініціалізації модуля).

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

Рівень безпеки 1. Обнуління незахищених SSP може бути виконане процедурно оператором модуля, без керування модулем (наприклад, переформатування жорсткого диска, атмосферне руйнування модуля при повторному введенні і т.д.).

Рівні безпеки 2 і 3. Криптографічний модуль повинен виконувати обнуління незахищених SSP (наприклад, шляхом перезапису нулями або одиницями або випадковими даними). Обнуління повинне виключати можливість перезапису незахищених SSP іншими незахищеними SSP. Тимчасові SSP повинні бути обнулені, коли вони більше не потрібні. Модуль повинен надавати індикацію статусу, коли обнуління завершене.

Рівень безпеки 4. На додаток до вимог рівнів безпеки 2 і 3, пред'являються наступні вимоги:

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

  • всі незахищені SSP, і у відкритій формі, і криптографічно захищені, повинні обнулятися, так, щоб модуль повертався в заводський стан.



1   ...   15   16   17   18   19   20   21   22   ...   29


написать администратору сайта