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

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


Скачать 227.06 Kb.
Название1. 9 Вимоги та їх реалізація при побудування засобів криптографічного захисту інформації
Дата11.01.2022
Размер227.06 Kb.
Формат файлаdocx
Имя файла19 мон ГЮІ 2015.docx
ТипДокументы
#328148
страница11 из 29
1   ...   7   8   9   10   11   12   13   14   ...   29

2.2.7 Режими експлуатації



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

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

Нормальний режим експлуатації. Нормальний режим експлуатації – це коли весь набір алгоритмів, функцій безпеки, послуг або процесів є доступним і / або настроюваним.CSP повинні бути окремі для затверджених і незатверджених послуг та режимів експлуатації (тобто, не бути загальними або доступними). Вихід затвердженого RBG (генератора випадкових бітів) може бути наданий незатвердженому алгоритму, функціям безпеки або процесам без обнуління ініціалізуючого значення RBG, поки ініціалізуюче значення не є доступним в незатвердженому режимі.

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

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

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

  • послаблений режим повинен] бути введений тільки після виходу зі стану помилки;

  • модуль повинен надавати інформацію про статус при повторному налаштуванні і вході в послаблений режим;

  • механізм або функції, які дали збій, повинні бути ізольовані;

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

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

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

2.2.8 Інтерфейси криптографічного модуля




Загальні вимоги до інтерфейсів криптографічного модуля. Криптографічний модуль повинен обмежувати всі логічні інформаційні потоки тільки до тих фізичних точок доступу і логічних інтерфейсів, які визначені як точки входу і виходу з криптографічної границі модуля. Логічні інтерфейси криптографічного модуля повинні бути відокремлені один від одного, хоча вони можуть спільно використовувати один фізичний порт (наприклад, вхідні дані можуть входити, а вихідні дані можуть виходити через той же порт) або можуть бути розподілені по одному або декільком фізичним портам (наприклад, вхідні дані можуть входити як через послідовний, так і через паралельний порт). Прикладний програмний інтерфейс (API) програмного компонента криптографічного модуля може бути визначений як один або декілька логічних інтерфейсів [10].

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

Інтерфейс програмного або програмно-апаратного модуля (SFMI): загальний набір інтерфейсів, що використовуються для запиту послуг програмного або програмно-апаратного модуля, в тому числі параметрів, які входять або виходять за межі криптографічної границі модуля як частина запитуваної послуги

Інтерфейс гібридного програмного або гібридного програмно-апаратного модуля (HSMI або HFMI): загальний набір інтерфейсів, що використовуються для запиту послуг гібридного програмного або гібридного програмно-апаратного модуля, в тому числі параметрів, які входять або виходять за межі криптографічної границі модуля як частина запитуваної послуги.

Визначення інтерфейсів. Криптографічний модуль повинен мати наступні п'ять інтерфейсів ("вхід" і "вихід" відображаються з точки зору модуля):

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

2. Інтерфейс виведення даних. Всі дані (за винятком даних про статус, які виводяться через інтерфейс виведення статусу і даних керування, які виводяться через інтерфейс виведення інформації керування), які виводяться з криптографічного модуля (в тому числі дані у вигляді відкритого тексту, шифр текст і SSP) повинні виводитися через інтерфейс "виведення даних". Виведення даних через інтерфейс "виведення даних" повинне бути заборонено коли виконується ручне введення, попереднє самотестування, завантаження програмного / програмно-апаратного забезпечення і обнуління, або коли криптографічний модуль знаходиться в стані помилки.

3. Інтерфейс введення інформації керування. Всі вхідні команди, сигнали (наприклад, тактовий вхід) та дані керування (включаючи виклики функцій і ручне аерування, наприклад, за допомогою перемикачів, кнопок і клавіатур), що використовуються для управління роботою криптографічного модуля, повиннівводитися через інтерфейс "введення інформації керування".

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

5. Інтерфейс виведення статусу. Всі вихідні сигнали, індикатори (наприклад, індикатор помилки) і дані про статус (в тому числі коди повернення та фізичні індикатори, такі як візуальні (монітор, лампи індикації), аудіо (зумер, гудок, дзвінок) та механічні (вібрації)), що використовується для індикації статусу криптографічного модуля, повинні виводитися через інтерфейс "виведення статусу". Виведення статусу може бути або явним, або неявним.

За винятком програмних криптографічних модулів, всі модулі повинні також мати наступний інтерфейс:

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

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

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

1   ...   7   8   9   10   11   12   13   14   ...   29


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