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

1 Методи та механізми 2014. 1. 1 Основні послуги при застосуванні, уніфікація та стандартизація криптографічних перетворень


Скачать 1.75 Mb.
Название1. 1 Основні послуги при застосуванні, уніфікація та стандартизація криптографічних перетворень
Дата10.01.2022
Размер1.75 Mb.
Формат файлаdocx
Имя файла1 Методи та механізми 2014.docx
ТипПротокол
#327532
страница20 из 24
1   ...   16   17   18   19   20   21   22   23   24


1.9.3 Аналіз вимог до засобів КЗІ, що викладені у національному стандарті ДСТУ ISO/IEC 19790 - 2012


Міжнародний стандарт ДСТУ ISO/IEC 19790, версія 2012-08-15 [277] є суттєво переробленою версією міжнародного стандарту ISO/IEC 19790 ( версія 2005-03-30). Він також передбачає чотири наростаючі, якісні рівні вимог безпеки, що призначені для покриття широкого спектру потенційних застосувань і середовищ. При цьому можуть застосовуватись криптографічні методи однакові для всіх чотирьох рівнів безпеки. Вони охоплюють галузі проектування та створення криптографічних модулів. До таких галузей відносяться специфікації криптографічних модулів; інтерфейси криптографічних модулів; ролі, послуги і автентифікація; безпека програмного / програмно-апаратного забезпечення; експлуатаційне середовище, фізична безпека; неінвазивна безпека; управління чутливими параметрами безпеки; самотестування; гарантії життєвого циклу, а також відбиття інших атак.

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

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

  • фізичне керування та керування середовищем;

  • керування доступом;

  • розробка програмного забезпечення;

  • план відновлювальних робіт та план на випадок непередбачуваних обставин, а також

  • керування інформацією та даними.

Національний стандарт ДСТУ ISO/IEC 19790 : 2012 встановлює вимоги безпеки для криптографічних модулів, що використовуються в системі безпеки для захисту критичної (чутливої) інформації в комп'ютерних і телекомунікаційних системах. Стандарт ДСТУ ISO/IEC 19790 : 2012 визначає для модулів КЗІ чотири рівні безпеки для кожної з 11 областей вимог, забезпечуючи підвищення безпеки кожного рівня в порівнянні з попереднім рівнем.

Стандарт ДСТУ ISO/IEC 19790 : 2012 встановлює вимоги, що спрямовані на підтримання безпеки, що забезпечується криптографічним модулем; відповідність стандарту не є достатньою умовою, щоб гарантувати, що конкретний модуль є безпечним, або що безпека, забезпечувана модулем, є достатньою і прийнятною для власника інформації, яка захищається.

Нижче представлено огляд чотирьох рівнів безпеки[277]. Типові приклади, які наведені щоб проілюструвати як можуть бути задоволені ці вимоги, не вносять обмежень і не є вичерпними. Посилання на «модуль» повинне тлумачитися як «криптографічний модуль». Криптографічні методи однакові для всіх чотирьох рівнів безпеки. Кожен рівень безпеки об’єднує зростаючі рівні вимог до безпеки для захисту самого модуля (наприклад, доступ і знання внутрішніх компонентів і роботи) і SSP, що містяться і управляються усередині модуля.

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

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

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

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

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

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

Рівень безпеки 3. На додаток до фізичних механізмів безпеки, що доводять вторгнення, які необхідні для рівня безпеки 2, рівень безпеки 3 передбачає додаткові вимоги до відбиття несанкціонованого доступу до SSP, що зберігаються в криптографічних модулях. Фізичні механізми безпеки рівня безпеки 3 повинні мати високу ймовірність виявлення і реагування на спроби прямого фізичного доступу, використання або модифікації криптографічного модуля і зондування через вентиляційні отвори або прорізи. Фізичні механізми безпеки можуть включати використання міцних корпусів і схем доказу/реагування на вторгнення, які обнуляють всі СSP, коли знімні кришки / дверцята криптографічного модуля відкриті.

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

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

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

Методи відбиття неінвазивних атак, які реалізовані в модулі, на Рівні безпеки 3 проходять тестування.

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

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

Рівень безпеки 4. Рівень безпеки 4 забезпечує найвищий рівень безпеки, визначений у цьому стандарті. Цей рівень включає в себе всі необхідні функції безпеки нижчих рівнів, а також розширені можливості.

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

Рівень безпеки 4 вводить вимогу багатофакторної автентифікації оператора. Як мінімум, це вимагає двох з трьох наступних атрибутів:

  • щось, що ви знаєте, наприклад, секретний пароль,

  • щось, чим ви володієте, наприклад, фізичний ключ або токен,

  • фізичні властивості, наприклад, біометрики.

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

Методи відбиття неінвазивних атак, які реалізовані в модулі, на рівні безпеки 4 проходять тестування.

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

Проектування модулів рівня безпеки 4 перевіряється на відповідність умовам попереднього і наступного стану і функціональній специфікації.

Перелік відповідних вимог до модулів КЗІ згідно національного стандарту, що вводиться в дію з 01.01. 2016 р. наведено в таблиці 1.30.

Таблиця 1.30 – Перелік вимог безпеки




Рівень безпеки 1

Рівень безпеки 2

Рівень безпеки 3

Рівень безпеки 4

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

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

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

Обов’язкові та додаткові інтерфейси. Специфікація всіх інтерфейсів і всіх шляхів введення та виведення даних.

Довірений канал

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

Логічне розділення обов’язкових та додаткових ролей та послуг

Рольова або особистісна автентифікація оператора

Особистісна автентифікація оператора

Багатофакторна автентифікація

Безпека програмного/програмно-апаратного забезпечення

Затверджений метод контролю цілісності, визначені SFMI (інтерфейси програмного/програмно-апаратного модуля), HFMI (інтерфейси гібридного програмно-апаратного модуля), HSMI (інтерфейси гібридного програмного модуля)

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

Затверджений метод тестування цілісності, що базується на цифровому підписі

Експлуатаційне середовище

Незмінне, обмежене або змінне.

Керування SSP (чутливими параметрами безпеки).

Змінне.

Рольове або дискреційне керування доступом.

Механізм аудиту




Фізична безпека

Компоненти виробничого класу

Доказ вторгнення.

Непрозоре покриття або корпус

Механізми виявлення та реагування на вторгнення на кришках та дверцятах. Міцний корпус або покриття.

Захист від прямого зондування.

EFP (захист від помилок, спричинених середовищем) та EFT

(тестування на помилки, спричинені середовищем)

Оболонка з механізмами виявлення та реагування на вторгнення. EFP (захист від помилок, спричинених середовищем). Протидія помилковому введенню

Неінвазивна безпека

Модуль здатний відбивати неінвазивні атаки, визначені в Додатку Е

Документація і ефективність методів відбиття визначені в Додатку Е

Тестування на відбиття

Тестування на відбиття

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

Генерація випадкових бітів, генерація SSP, встановлення, введення та виведення, зберігання та обнуління

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

Встановлені вручну SSP можуть вводитися або виводитися у формі відкритого тексту

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

Самотестування

Попереднє: тестування цілісності програмного/програмно-апаратного забезпечення, обходу та критичних функцій

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

Гарантії життєвого циклу

Управління конфігурацією

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

Автоматизована система керування конфігурацією

Проектування

Модуль дозволяє тестування всіх функцій, пов’язаних з безпекою

FSM

Модель кінцевих станів

Розробка

Вихідний код з коментарями, схеми або

HDL (мова опису апаратних засобів)


Мова програмування високого рівня. Мова опису апаратних засобів високого рівня

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

Тестування

Функціональне тестування

Низькорівневе тестування

Постачання і експлуатація

Процедури ініціалізації

Процедура постачання

Автентифікація оператора з використанням інформації, наданої постачальником

Настанови

Настанови адміністратора і не-адміністратора

Відбиття інших атак

Специфікація відбиття атак, для яких наразі немає вимог по перевірці

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


1.9.4 Висновки та рекомендації у зв’язку зі введенням стандарту ДСТУ ISO/IEC 19790 : 2012 у дію

  1. Версія ДСТУ ISO/IEC 19790 : 2012 є суттєво переробленою версією міжнародного версії ДСТУ ISO/IEC 2005-03-30. В стандарті передбачено чотири наростаючі, якісні рівні вимог безпеки, що призначені для покриття широкого спектру потенційних застосувань і середовищ. Причому криптографічні методи та механізми однакові для всіх чотирьох рівнів безпеки. Вимоги безпеки стандарту охоплюють галузі специфікації модулів КЗІ; інтерфейси модулів КЗІ; ролі, послуги і автентифікація; безпека програмного / програмно-апаратного забезпечення; експлуатаційне середовище, фізична безпека; неінвазивна безпека; управління чутливими параметрами безпеки; самотестування; гарантії життєвого циклу, а також відбиття інших атак.

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

  3. Національний стандарт ДСТУ ISO/IEC 19790 2012-08- 15 встановлює вимоги, що спрямовані на підтримання безпеки, що забезпечується модулем КЗІ, але відповідність стандарту не є достатньою умовою, щоб гарантувати, що конкретний модуль КЗІ є безпечним, або що безпека, що забезпечується модулем, є достатньою і прийнятною для власника інформації, яка захищається.

  4. На 4 рівні забезпечується найвищий рівень безпеки, що визначений у стандарті ДСТУ ISO/IEC 19790 2012-08- 15. Він включає в себе всі необхідні функції безпеки нижчих рівнів, а також розширені можливості. На 4 рівні фізичні механізми безпеки забезпечують повний пакет захисту модуля КЗІ, що має на меті виявлення та реагування на всі несанкціоновані спроби фізичного доступу коли SSP містяться в модулі, незалежно від того подається зовнішнє живлення чи ні. Проникнення під корпус модуля КЗІ з будь-якого напрямку повинне бути виявлене з високою ймовірністю.

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

  • щось, що ви знаєте, наприклад, секретний пароль,

  • щось, чим ви володієте, наприклад, фізичний ключ або токен,

  • фізичні властивості, наприклад, біо метрика[224, 77].

  1. Вимоги до безпеки охоплюють області, що пов'язані з розробкою і випуском криптографічних модулів. До таких областей відносяться специфікації криптографічних модулів; інтерфейси криптографічних модулів; ролі, послуги і автентифікація; безпека програмного/програмно-апаратного забезпечення; експлуатаційне середовище, фізична безпека; неінвазивна безпеки; управління чутливими параметрами безпеки; самотестування; гарантії життєвого циклу, а також відбиття інших атак. У таблиці 1.30 наведені вимоги безпеки в кожній з цих областей. Модуль КЗІ повинен бути протестований на відповідність вимогам по кожній області, розглянутій в цьому розділі. Крім того, модуль КЗІ повинен бути незалежно оцінений по кожній області. Також, на додаток до отримання незалежної оцінки по кожній з областей безпеки, модуль КЗІ також повинен отримати загальну оцінку безпеки. Загальна оцінка безпеки буде відображати найменшу з незалежних оцінок, отриманих по областях.

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

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

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

  5. Довірений канал – це зв'язок, встановлений між модулем КЗІ і відправником або одержувачем для безпечного повідомлення незахищених CSP у вигляді відкритого тексту, ключових компонентів і даних автентифікації. При використанні довіреного каналу забезпечується захист від підслуховування, а також фізичного або логічного вторгнення небажаних операторів / об'єктів, процесів або інших пристроїв, між визначеними портами введення та виведення модуля, уздовж лінії зв'язку, та передбаченою кінцевою точкою відправника або отримувача.

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

  7. Середовище експлуатації модуля КЗІ пов’язане з управлінням програмним, програмно-апаратним та апаратним забезпеченням, що необхідне для роботи модуля. Експлуатаційне середовище програмних, програмно-апаратних та гібридних модулів включає в себе, як мінімум, компоненти модуля, обчислювальну платформу та операційну систему, яка керує або дозволяє виконання програмного або програмно-апаратного забезпечення на обчислювальній платформі.

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

  9. Критичні (чутливі параметри безпеки (SSP) складаються з критичних параметрів безпеки (CSP) і відкритих параметрів безпеки (PSP). Вимоги безпеки до управління SSP охоплюють весь життєвий цикл SSP, що використовуються модулем КЗІ. Управління SSP охоплює генератори випадкових біт (RBG), генерацію SSP, встановлення SSP, введення / виведення SSP, зберігання SSP та обнуління незахищених SSP. В якості зашифрованих повинні розглядатись CSP, які зашифровані з використанням затвердженої функції безпеки. CSP, зашифровані або скриті з використанням незатверджених функцій безпеки в рамках даного міжнародного стандарту вважаються незахищеними, у вигляді відкритого тексту. CSP в межах модуля повинні бути захищені від несанкціонованого доступу, використання, розкриття, зміни і заміни. PSP в межах модуля КЗІ повинні бути захищені від несанкціонованої зміни і заміни.

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

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

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

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

  14. Усі особи, що використовують модуль КЗІ , мають мати належні керівництва і процедури адміністрування та використання модуля КЗІ в затвердженому режимі експлуатації. Керівна документація, як правило, складається з керівництва адміністратора та інших, не є адміністраторами.

  15. Реальна вразливість криптографічного модуля КЗІ до атак, що не визначені, залежить від типу модуля КЗІ, реалізації та середовища функціонування. Такі атаки можуть мати особливе значення для модулів КЗІ, що функціонують в агресивному середовищі. В основу цих атак зазвичай покладено аналіз інформації, отриманої з джерел, які є фізично зовнішніми відносно модуля. У всіх випадках, атака направлена на визначення деяких відомості про CSP криптографічного модуля.



1.10 Побудування, аналіз та застосування загальних та загально - системних параметрів асиметричних крипто перетворень

Однією із основних необхідних умов забезпечення криптографічної стійкості асиметричних криптографічних перетворень є використання справжніх цілісних «сильних» загальних або загально - системних параметрів[ 236, 237, 218-219, 267,218,258,191,234,265,265]. При цьому під загальними параметрами асиметричних криптографічних перетворень будемо розуміти сукупність критичних параметрів, які є загальними для одного окремого користувача. Прикладом загальних параметрів є прості числа P та Q і модуль N, що використовуються в RSA криптографічних перетвореннях. Під загально - системними параметрами будемо розуміти критичні параметри криптографічного перетворення, які є загальними для домену xи системи [236, 237, 267,218,258,191,234,265,265]. Прикладами загально - системних параметрів є параметри (P, g) скінченного поля, де P - як правили «сильне» просте число, а G - первісний елемент, що породжує скінченне поле. Для криптографічних перетворень в групі точок еліптичних кривих також визначаються загально - системні параметри. Розглянемо перелік, сутність, вимоги та стан стандартизації загальних та загально - системних параметрів для криптографічних перетворень в кільці, скінченному полі та групі точок еліптичних кривих.

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

Перед безпосереднім застосуванням RSA криптографічного перетворення кожному користувачеві попередньо необхідно генерувати загальні параметри та асиметричну пару - ключ.

До загальних параметрів відносяться[ ]:

  • P та Q - прості числа, краще «сильні» прості числа;

  • N - модуль криптографічного перетворення, N = P * Q.

Значення P та Q - таємні параметри, які повинні бути знищеними після обчислення функції Ойлера

= ,

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

До асиметричної ключової пари відноситься пара , ключі якої пов’язані між собою згідно порівняння:

, (1.191)
Якщо (1.191) має розв’язок, рішення, тоб то існує єдина пара , то таке криптографічне перетворення є одно значним і при таких умовах RSA криптосистема забезпечує направлене шифрування чи електронний підпис.

При застосуванні RSA для електронного підпису один із ключів пари, як правило

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

При застосуванні RSA для направленого шифрування, один із ключів пари, як правило , є особистим (конфіденційним) і використовується для розшифрування , а - відкритим і використовується для зашифрування. Тобто розшифрування здійснюється за допомогою особистого ключа , а зашифрування за допомогою відкритого ключа - .

Для забезпечення необхідного рівня криптографічної стійкості, як для електронного підпису, так і для направленого шифрування, згідно [218] повинні бути виконані такі рекомендовані вимоги.

Вироблення та перевіряння електронного підпису повинні здійснюватись, як це описане у ANS X9.31 і PKCS #1. Хоча кожен з цих стандартів використовує алгоритм RSA, формат ANS X9.31 і PKCS #1 дані, згідно яких генерується виробляється електронний підпис, детально відрізняються, що робить їх не взаємозамінними. Тому рекомендується орієнтуватись на PKCS #1 дані та FIPS 186- 3[218].

Таким чином, RSA ключова пара складається з RSA особистого ключа , який використовується для обчислення цифрового підпису, і RSA відкритого ключа, який використовується для перевіряння (верифікації) електронного підпису. При чому, RSA ключова пара, що використовується електронних підписів,
1   ...   16   17   18   19   20   21   22   23   24


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