Все_лекции_Горбенко

У моделі IND-CPA, безпека ECIES-KEM може бути поліпшена. Безпека схеми, у

випадковій моделі оракула, може бути скорочена до проблеми CDH у групі P. Формально,

якщо існує (t, ) криптоаналітик для ECIES-KEM, то існує алгоритм, що за час t виводить список елементів L і містить рішення CDH проблеми з імовірністю не менш ніж із

функцію вироблення ключів. Звичайно, ми можемо тепер використати методи Пункту 1.2.2, щоб створити (t , ) вирішальний пристрій для CDH проблеми з

Здається, що єдиними атаками для котрих ECIES-KEM уразливий, це атака побічного каналу, атака промаху [37] й силова атака, заснована на використанні груп еліптичної кривої

[6].

3.6«Електронні цифрові підписи з відновленням повідомлень.

-Цифровий підпис Ніберга-Рюпеля в скінченному полі (Nyrberg–Rueppel message recovery signature)

-Цифровий підпис Ніберга-Рюпеля в групі точок еліптичних кривих (Elliptic Curve Nyrberg–Rueppel (ECNR) message recovery signature)

-Цифровий підпис Міяджі з відновленням повідомлення в групі точок еліптичної кривої (Elliptic Curve Miyaji message recovery signature (ECMR))

-Цифровий підпис Абі-Окамото з відновленням повідомлення в групі точок еліптичної кривої (Elliptic Curve Abe-Okamoto message recovery signature (ECAO))

-Цифровий підпис Пінтсова-Ванстона в групі точок еліптичних кривих (Elliptic Curve Pintsov-Vanstone (ECPV) message recovery signature)

-Цифровий підпис KC-DSA в групі точок еліптичної кривої

(Elliptic Curve KC DSA/Nurberg-Rueppel (ECKNR) message recovery signature)

3.1 Технічні специфікації форматів представлення базових об’єктів. Формат електронного цифрового підпису

1.Вступ

1.1.Специфікація визначає порядок представлення (кодування) даних в електронній формі, які є електронним цифровим підписом (далі - ЕЦП).

1.2.Встановлення єдиного формату ЕЦП має на меті визначення технічних умов щодо забезпечення сумісності надійних засобів ЕЦП, які використовуються відповідно до Закону України „Про електронний цифровий підпис”.

1.3.Формат ЕЦП, що визначений у Специфікації,представлений у нотації ASN.1 (ISO/IEC 8824 „Information technology – Open Systems Interconnection – Specification of Abstract Syntax Notation One (ASN.1)”).

Усі структури даних кодують за правилами DER згідно з ISO/IEC 8825-1:2002 «Information technology – ASN.1 encoding Rules – Part 1: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)» & AMD1:2004 «Support for EX-TENDED-XER».

1.4. Специфікація заснована на:

RFC 3852 "Cryptographic Message Syntax (CMS)";

ETSITS 101 733 “TechnicalSpecification. Electronic Signatures and Infrastructures (ESI); CMS Advanced Electronic Signatures (CAdES)”.

2. Терміни та визначення.

Терміни, які вживаються у Специфікації, мають таке значення:

атрибут, що підписується – кодоване за встановленими правилами поле даних ЕЦП, яке разом з електронними даними, у відношенні яких формується підпис, є вхідним параметром криптографічного алгоритму цифрового підпису. Криптографічні перетворення за алгоритмом цифрового підпису здійснюються по відношенню до електронних даних, що підписуються (електронного документу) та атрибутів, що підписуються;

атрибут, що не підписується – кодоване за встановленими правилами поле даних ЕЦП, що призначене для встановлення дійсності ЕЦП;

верифікатор – суб’єкт (особа), що здійснює перевірку ЕЦП та встановлює його дійсність;

дані перевірки – кодовані за встановленими правилами поля даних ЕЦП, що призначені для встановлення дійсності ЕЦП, у тому числі в довгостроковому(достроковому) періоді;

довгостроковий період – період часу, який починається після закінчення терміну дії або скасування сертифікатів (сертифікату) відкритих ключів, які використовуються для перевірки цифрового підпису та встановлення дійсності ЕЦП;

період відстрочки – період часу, за який стає доступною для користувачів оновлена інформація про статус сертифікатів.

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

позначка часу – об’єкт даних, який призначений для зв’язування представлення певних даних з часом. Позначка часу забезпечує доказ, що електронні дані, пов’язані з позначкою часу, існували до моменту часу, зазначеному у позначці часу;

політика підпису – визначені правила, що встановлюють технічні і процедурні умови формування та перевіряння ЕЦП, для забезпечення можливості однозначного встановлення його дійсності;

формат ЕЦП – блок електронних даних, представлений у визначеному вигляді, що містить цифровий підпис та набір даних перевірки;

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

3.Загальний опис форматів ЕЦП

3.1. Специфікація визначає наступні формати ЕЦП:

„Базовий ЕЦП” (CAdES Basic Electronic Signature - CAdES-BES, відповідно до

ETSITS 101 733) або „Базовий ЕЦП із визначеною політикою підпису” (Explicit PolicybasedElectronic Signature - CAdES-EPES, відповідно до ETSITS 101 733), у разі якщо в блок даних „Базового ЕЦП” включається ідентифікатор, який вказує на політику підпису;

„ЕЦП з посиланням на повний набір даних, перевірки” (ES with Complete validation data references (CAdES-C),відповідно до ETSITS 101 733);

„ЕЦП з повним набором даних перевірки” (CAdES-X Long,відповідно до ETSITS 101 733 ).

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

Останні два формати ЕЦП забезпечують встановлення дійсності підпису у достроковому періоді.

3.2. Формат „Базовий ЕЦП” (CAdES-BES)

3.2.1.Формат „Базовий ЕЦП” включає цифровий підпис і окремі дані перевірки. Формат „Базовий ЕЦП” може бути створений без доступу до on-line послуг центру сертифікації ключів, зокрема послуги фіксування часу. Використання зазначеного формату дозволяє підтвердити підписувача електронного документу та перевірити його цілісність в період чинності сертифікату(сертифікатів) відкритого ключа. Формат „Базовий ЕЦП” не надає можливість встановити дійсність підпису, у випадку, якщо ЕЦП перевіряється після закінчення терміну дії сертифікату (сертифікатів) відкритого ключа або скасування сертифікату відкритого ключа після формування ЕЦП.

3.2.2.Формат „Базовий ЕЦП” (мал. 1) містить:

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

набір обов’язкових атрибутів, що підписуються;

криптографічне значення ЕЦП (цифровий підпис), обчислений за електронними даними та набором атрибутів, що підписуються;

Додатково, формат „Базовий ЕЦП” може включати:

набір необов’язкових атрибутів, що підписуються;

набір необов’язкових атрибутів, що не підписуються, відповідно до CMS (RFC

3852).

Базовий ЕЦП (CAdES-BES)

Мал. 1. Структура формату „Базовий ЕЦП”.

3.2.3. Обов’язковими атрибутами, що підписуються є:

Сontent-Type-атрибут, що визначає тип структури EncapsulatedContentInfo,за значенням якого обчислюється підпис.

Message-digest- атрибут, що містить геш-значення структури eContent OCTET STRING, в encapContentInfo,за значенням якої обчислюється цифровий підпис.

ESS signing-certificate v2-атрибут, що містить посилання на сертифікат підписувача.

3.2.4. Необов’язковими атрибутами, що підписуються, є:

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

content-time-stamp -атрибут, що містить позначку часу відносно даних, що підписуються. Зазначений атрибут дозволяє забезпечити доказ того, що дані, у відношенні яких обчислюється підпис, існували до моменту формування підпису.

signature-policy-identifier - атрибут, що вказує на політику підпису, дотримання якої є обов’язковим під час формування та перевірки ЕЦП.

3.3. Політика підпису

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

3.4. Формати ЕЦП, що містять дані перевірки, які забезпечують встановлення дійсності підпису у достроковому(довгостроковому) періоді.

3.4.1. Встановлення дійсності підпису у достроковому(довгостроковому) періоді потребує використання наступних додаткових даних перевірки:

позначка часу відносно цифрового підпису;

сертифікати відкритих ключів або посилання на сертифікати відкритих ключів;

інформація про статус для кожного сертифікату або посилання на таку інформацію;

Дані перевірки, що забезпечують встановлення дійсності підпису у достроковому періоді можуть бути включені до формату ЕЦП підписувачем та/або суб’єктом, що перевіряє підпис (верифікатором).Дані перевірки включають сертифікати центрів сертифікації ключів, а також інформацію про статус сертифікатів або посилання на зазначені дані. Інформацію про статус сертифікатів може бути представлена у формі списків відкликаних сертифікатів або відповідей за протоколом OCSP (RFC 2560) про статус сертифікатів, отриманого через он-лайн послугу центра сертифікації ключів. Використання позначки часу забезпечує доказ

3.6.2 У випадку, якщо особа, яка перевіряє підпис для забезпечення встановлення дійсності підпису у достроковому періоді, створює формат CAdES-С, на основі ЕЦП у форматі „Базовий ЕЦП”, для підтвердження факту, що сертифікат підписувача не був скасований під час формування позначки часу, отримання даних перевірки, повинне бути здійснено після закінчення періоду відстрочки.

Період відстрочки

Позначка часу у відношенні підпису

Мал. 3. Пояснення щодо періоду відстрочки

3.7. Формат „Розширений довгостроковий підпис” (CAdES-X Long)

Формат „Розширений довгостроковий підпис” формується шляхом додавання до формату (CAdES-С) наступних атрибутів,що не підписуються (мал. 4):

certificate-values -атрибутмістить всі сертифікати відкритих ключів, крім сертифікату підписувача, необхідних для перевірки підпису.

revocation-values атрибут містить списки відкликаних сертифікатів або відповіді за протоколом OCSP щодо сертифікатів, які використовуються для перевірки підпису (крім сертифіката підписувача).

Мал. 4. Структура формату „Розширений довгостроковий підпис” (CAdES-X Long)

4.Процедура встановлення дійсності підпису

4.1.Під час перевірки ЕЦП встановлюється дійсність або недійсність підпису. Результатом перевірки ЕЦП може бути один з наступних:

5.2 Подання структуриSignedData ASN.1 структура SignedData

SignedData ::= SEQUENCE {

Поля структури SignedDataмають наступні значення:

підписувача та інші додаткові атрибути, необхідні для перевірки цифрового підпису.

SignerInfos ::= SET OF SignerInfo

5.2.1. Кодування структури AlgorithmIdentifierдля алгоритму гешування ГОСТ

34.311-95

Об’єктний ідентифікатор, який вказує на використання алгоритму гешування, що визначений ГОСТ 34.311-95:

iso(1) member-body(2) Ukraine(804 ) root (2) security(1) cryptography(1) pki(1) pkialg(1) pki-alg-hash (2) Gost34311 (1)

Параметри криптоалгоритму ГОСТ 34.311-95

Gost34311Params ::= OCTET STRING OPTIONAL

Gost34311Params використовується в якості поля parameters структури

AlgorithmIdentifier.

Gost34311Params містить єдиний елемент - OCTET STRING що містить ДКЕ для функції гешування, що задані в упакованому форматі згідно розділу Таблиці заповнення вузлів заміни блоків підстановки (ДКЕ). Упакований формат документу «Національна система електронного цифрового підпису. Технічні специфікації форматів представлення базових об’єктів».

При обчисленні значення геш-функції (в т.ч. при обчисленні електронного цифрового підпису), значення стартового вектору H функції гешування за ГОСТ 34.311-95 встановлюється рівним 256-м нульовим бітам.

5.3 Подання структура EncapsulatedContentInfo

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

ASN.1 структура EncapsulatedContentInfo

EncapsulatedContentInfo ::= SEQUENCE {

Поля структури EncapsulatedContentInfoмають наступні значення:

електронні дані, що підписуються. eContentне потребує DER кодування.

Поле eContentвизначене як необов’язкове (OPTIONAL).У випадку присутності поля eContent в структурі EncapsulatedContentInfo,електронні дані у відношенні яких було обчислено цифровий підпис можуть бути доступні тільки, якщо існує можливість декодувати

ASN.1 код структури SignedData.

В залежності від присутності зазначеного поля в структурі EncapsulatedContentInfo,DER – кодований блок формату ЕЦПвизначається як:

„криптографічне повідомлення” - (eContentприсутнє та містить дані, що підписуються);

„зовнішній підпис” (eContentвідсутнє, цифровий підпис обчислюється за окремим файлом, незалежно від його типу або за даними представленими в іншому вигляді). У такому випадку, дані, у відношенні яких був обчислений цифровий підпис, повинні надаватися окремо.

5.4 Подання структуриSignerInfo ASN.1 структураSignerInfo

SignerInfo ::= SEQUENCE {

Поля структури SignerInfo мають наступні значення: