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

• Название: 1. 9 Вимоги та їх реалізація при побудування засобів криптографічного захисту інформації
• Дата: 11.01.2022
• Размер: 227.06 Kb.
• Имя файла: 19 мон ГЮІ 2015.docx
• Тип: Документы; #328148
• страница: 3 из 29

згідно ISO / IEC 15408 відповідає гарантійному рівні оцінки EAL4 (абооцінюється вище).

Також може використовуватися затверджена довірена операційна система

2.1.3 Завдання функціонального захисту

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

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

• захисту криптографічного модуля від несанкціонованої експлуатації або використання;

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

• запобігання несанкціонованій і не виявляємої модифікації криптографічного модуля і криптографічних алгоритмів, включаючи несанкціоновану модифікацію, заміну, вставку і видалення CSP параметрів і / або PSP параметрів;

• забезпечення індикації операційного стану криптографічного модуля;

• гарантії правильного виконання криптографічного модуля при роботі в затвердженому режимі операції;

• виявлення помилок в роботі модуля і запобігання компрометації CSP параметрів і / або PSP параметрів в результаті таких помилок.

2.1.4 Вимоги захисту

Розглянемо вимоги, які повинні задовольнятися шляхом забезпечення відповідності криптографічного модуля стандарту. Вимоги захисту охоплюють області, що пов'язані з проектуванням і реалізацією криптографічного модуля. Ці області включають специфікацію криптографічного модуля; порти і інтерфейси модуля; ролі, послуги і автентифікацію; модель кінцевого стану; фізичний захист; експлуатаційну середовище; управління криптографічними ключами; самотестування; та проектні гарантії. . У Таблиці 2.1 представлені вимоги захисту в кожній з таких областей. Модуль повинен тестуватися на відповідність вимогам кожній області, що розглядається в цьому пункті. Криптографічний модуль в кожній області має піддаватися незалежній оцінці. Області передбачають зростаючі рівні захисту з кумулятивними вимогами захисту для кожного рівня захисту, тобто включенням попередніх вимог до наступних рівнів.. У цих областях криптографічний модуль повинен отримувати оцінку, що відображає максимальний рівень захисту, для якого модуль забезпечує всі вимоги цієї області. В областях, які не передбачають різні рівні захисту (тобто стандартний набір вимог), криптографічний модуль повинен отримувати оцінку, порівнянну з повним рівнем захисту. Крім отримання незалежних оцінок по кожній області захисту, криптографічний модуль також повинен отримувати повну оцінку. Повна оцінка буде вказувати мінімум незалежних оцінок, одержуваних у відповідних галузях захисту.
Багато з вимог захисту [ 9 ] включають спеціальні вимоги до документації, представлені в Додатку A. Вся документація, включаючи копії користувацького керівництва та керівництва з інсталяції, повинна бути представлена для оцінки.

2.1.5 Специфікація криптографічного модуля

В [ 9 ] вказується, що криптографічний модуль може являти собою набір апаратних, програмно-апаратних засобів, ПЗ або деяку комбінацію з них, що реалізовує криптографічні функції або процеси і міститься в межах заданих криптографічних кордонів. Криптографічний модуль повинен реалізувати, щонайменше, одну затверджену функцію, що використовується в затвердженому режимі операції. Незатверджені функції захисту також можуть бути включені для використання в незатвердженому режимі операції (тобто не пов'язаному із захистом). Оператор повинен вміти визначати, коли вибирається затверджений режим операції.

Для Рівнів Захисту 1 і 2 політика захисту криптографічного модуля може задавати, коли криптографічний модуль повинен виконувати операції у затвердженому режимі операції. Для Рівнів Захисту 3 і 4 криптографічний модуль повинен вказувати, коли повинен вибиратися затверджений режим операцій.

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

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

Відносно документації посинні виконуватись такі вимоги.

1. Документація повинна описувати апаратні, програмні та програмно-апаратні компоненти криптографічного модуля, задавати криптографічні кордони, оточуючі компоненти, і описувати фізичну конфігурацію модуля.

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

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

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

Документація повинна описувати:

• 
  блок-схему, що позначає всі основні апаратні компоненти криптографічного модуля і взаємозв'язку компонентів, включаючи будь-які мікропроцесори, буфери введення / виведення, буфери відкритого тексту / шифртексту, керуючі буфери, сховище ключів, робочу пам'ять і програмну пам'ять;
  
• 
  проектну схему апаратних, програмних та програмно-апаратних компонентів криптографічного модуля.
  

Мови опису високого рівня для програмно / програмно-апаратного забезпечення повинні використовуватися для документування проектування.

1. 
   Документація повинна описувати всю інформацію, пов'язану з захистом, включаючи CSP, PSP параметри та іншу інформацію, що захищається, розкриття або модифікація яких може скомпрометувати захист криптографічного модуля.
   
2. 
   Документація повинна описувати політику захисту криптографічного модуля. Політика захисту повинна включати правила, одержувані з вимог цього стандарту, і правила, одержувані з будь-яких додаткових вимог, що накладаються протягом розробки продукту.
   

Таблиця 2.1 — Перелік вимог захисту

	Рівень захисту 1	Рівень захисту 2			Рівень захисту 3				Рівень захисту 4
Специфікація крипатографічного модуля	Специфікація криптографічного модуля, криптографічних границь, затверджених алгоритмів і затверджених режимів виконання операцій, Опис криптографічного модуля, включаючи апаратні, програмні та програмно – апаратні компоненти. Формулювання політики захисту модуля.
Порти і інтерфейси криптографічного модуля	Специфікація усіх інтерфейсів і усіх каналів введення / виведення даних.			Порти даних для критичних параметрів захисту, логічно відокремлених від інших портів даних
Ролі, послуги і автентифікація	Логічне розділення необхідних і опціональних ролей і послуг	Автентифікація оператора на базі ролі або ідентифікації			Автентифікація оператора на базі ідентифікації
Модель кінцевого стану	Специфікація моделі кінцевого стану. Необхідні стани і опціональні стани. Діаграма переходів станів і специфікація переходів станів
Фізичний захист	Устаткування промислового класу		Замки або запобіжники	Механізми детектування і реагування на вторгнення для кришок та люків.				Оболонки з детектуванням і реагуванням на вторгнення. EFP або EFT
Експлуатаційне середовище	Один оператор. Виконуваний код. Затверджений метод контролю цілісності		Довідкові PP, оцінені на EAL2 рівні за допомогою заданих механізмів розмежувального управління доступом та аудиту.	Довідкові PP додати довірений канал, оцінений на EAL3 рівні додати моделювання політики захисту				Довідкові PP додати довірений канал, оцінений на EAL4 рівні.
Управління криптографічними ключами	Механізми управління ключами: генерація випадкових бітів і ключів, встановлення, розподіл, введення / висновок, збереження і обнулення кл.
	Секретні і особисті ключі, які транспортуються з використанням ручних методів передачі, можуть вводитися і виводитися у відкритому вигляді.					Секретні і особисті ключі, які транспортуються з використанням ручних методів транспортування, повинні вводитися або виводитися зашифрованими або за допомогою процедур розділення знань.
Самотестування	Тестування мережевого живлення: програмне / програмно-апаратне тестування цілісності і критичне тестування функцій. Умовне тестування.
Проектні гарантії.	Управління конфігурацією (CM). Інсталяція та генерація захисту. Відповідність проектної схеми і політики. Керівна документація.	СМ система. Розподіл захисту, функціональна специфікація.					Реалізація на мові високого рівня.		Формальна модель. Детальне пояснення (неформальне доказ). Передумови і постумови.
Придушення інших атак	Специфікація придушення атак, для яких поки немає тестованих вимог.

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

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

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

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

Інтерфейс виводу стану. Усі сигнали виведення, покажчики і дані стану (включаючи коди повернення та фізичні покажчики, такі як світло-еміттерние діоди і дисплеї), що використовуються для вказівки стану криптографічного модуля, повинні виводитися через інтерфейс «виведення стану».

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

Криптографічний модуль повинен розрізняти дані від керуючих даних (для введення і дані і стан для виводу). Всі вхідні дані, які вводяться в криптографічний модуль через інтерфейс «введення даних», повинні проходити тільки через вхідний канал даних. Всі вихідні дані, що виходять з криптографічного модуля через інтерфейс "виведення даних", повинні проходити тільки через вихідний канал даних. Вихідний канал даних повинен бути логічно від'єднаний від схеми і процесів під час виконання генерації ключів, ручного введення ключів або обнулення ключів. Для запобігання ненавмисному виведення конфіденційної інформації повинні вимагатися два незалежних внутрішніх дії (напр., встановлюються два різних програмних прапора, один з яких може бути ініційований користувачем; або два апаратних вентиля послідовно встановлюються в результаті двох окремих дій) для виведення відкритих криптографічних ключів, CSP параметрів або конфіденційних даних через будь-який вихідний інтерфейс.


2.1.7 Ролі, послуги і аутентифікація