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