1.2. Безпосередній цифровий підпис

Безпосередній цифровий підпис означає участь лише сторін, які обмінюються даними (джерело, адресат). Передбачається, що адресат знає відкритий ключ джерела. Цифровий підпис може бути сформована за допомогою шифрування всього повідомлення особистим ключем відправника (див. рис. 11.1 (B)) або за допомогою шифрування хеш-коду повідомлення особистим ключем відправника (див. рис. 11.5 (B)).

Після цього конфіденційність може бути забезпечена шифруванням всього повідомлення разом з підписом - або за допомогою відкритого ключа одержувача (шифрування з відкритим ключем), або за допомогою загального секретного ключа (традиційне шифрування) (див. рис. 11.1 (г) і 11.5 (г) ). Зверніть увагу на те, що важливо спочатку виконати функцію підписи і тільки потім - зовнішню функцію, що забезпечує конфіденційність. У разі виникнення розбіжностей деяка третя сторона повинна розглянути повідомлення і підпис. Якщо обчислювати підпис для шифрованого повідомлення, то третій стороні, щоб прочитати оригінальне повідомлення, потрібно доступ до ключа дешифрування. Якщо ж підпис є внутрішньою операцією, одержувач зможе зберегти повідомлення у вигляді відкритого тексту і підпис для можливого використання в подальшому в процесі вирішення конфлікту.

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

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

1.3. Арбітражний цифровий підпис

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

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

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

У табл. 14.1, дані якої засновані на сценаріях, описаних в [AKL83] і [MITC92], представлено декілька прикладів схем арбітражних цифрових підписів. У першому прикладі використовується традиційне шифрування. Передбачається, що відправник X і арбітр А використовують загальний секретний ключ К_xa, а А і Y - загальний секретний ключ К_ay. Відправник X створює повідомлення М і обчислює значення хешування Н (М). Потім X передає повідомлення з доданим до нього підписом арбітру А. Підпис складається з ідентифікатора X і значення хешування, і все це шифрується з використанням К_хa. Арбітр А дешифрує підпис і перевіряє значення хешування, щоб переконатися в достовірності повідомлення. Потім А передає повідомлення адресату Y в зашифрованому за допомогою К_aу вигляді. Це повідомлення включає IDX, оригінальне повідомлення X і мітку дати / часу. Одержувач Y може дешифрувати його, щоб відновити повідомлення і підпис. Мітка дати / часу інформує Y, що це повідомлення отримано своєчасно і не є відтворенням. Тепер Y може зберегти М і підпис. У разі спору Y, який заявляє, що отримав М від X, відправить А повідомлення наступного змісту:

Арбітр використовує К_ау, щоб відновити ID_X, М і підпис, а потім звертається по допомогу К_xa, щоб дешифрувати підпис і перевірити хеш-код. У цій схемі Y не може безпосередньо перевірити підпис X - для нього підпис присутній виключно в якості елемента, до якого можна буде звернутися у разі виникнення конфлікту для його вирішення. Одержувач Y вважає повідомлення від X справжнім, оскільки воно прийшло від А. Цей сценарій передбачає, що обидві повинні мати дуже високий ступінь довіри до А.

• X повинен вірити, що А не розголосить К_xa і не буде генерувати фальшиві підписи виду Е_Кxa[ID_X || Н(М)].

• Y повинен вірити, що А буде посилати Е_Кaу [ID_X || М || Е_Кxа [ID_Х || Н(М)] || Т] тільки в тих випадках, коли значення хешування виявляється правильним і підпис дійсно був виконаний відправником X.

• Обидві сторони повинні бути впевнені, що А буде чесно вирішувати конфлікти.

Якщо арбітр дійсно відповідатиме таким очікуванням, то X може! бути впевнений, що ніхто не зможе фальсифікувати його підпис, a Y може! бути впевнений, що X не зможе дезавуювати свій підпис.

Таблиця 14.1. Методи використання арбітражного цифрового підпису

(а) Традиційне шифрування, арбітр може побачити повідомлення
(1) Х → А: (2) А → Y :
(б) Традиційне шифрування, арбітр не бачить повідомлення
(1) Х → А: (2) А → Y :
(в) Шифрування з відкритим ключем, арбітр не бачить повідомлення
(1) Х → А: (2) А → Y:

Позначення:

X — відправник, Y — одержувач, А — арбітр, М — повідомлення.

Якщо арбітр дійсно відповідатиме таким очікуванням, то X може! бути впевнений, що ніхто не зможе фальсифікувати його підпис, a Y може! бути впевнений, що X не зможе дезавуювати свій підпис.

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

Не маючи можливості прочитати повідомлення, арбітр все ж виявляється здатним запобігти оману і з боку X, і з боку Y. Проблемами, які залишаються тут від першого сценарію, є змова арбітра з відправником з метою заперечення факту відправки підписаного повідомлення, або змова арбітра з одержувачем з метою фальсифікації підпису відправника.

Всі щойно згадані складнощі можуть бути подолані за допомогою схеми з відкритим ключем, один з варіантів якої показаний в табл. 10.1 (B). У цьому випадку X двічі шифрує повідомлення М - спочатку за допомогою особистого ключа X (ключа KR_X), а потім за допомогою відкритого ключа Y (ключа KU_y). Це буде підписана секретна версія повідомлення. Дане підписане повідомлення разом з ідентифікатором X шифрується знову за допомогою KR_X і разом з ID_X надсилається А. Внутрішнє, двічі шифрування повідомлення захищене від арбітра (і будь-якої іншої особи, крім Y). Однак можна зняти зовнішнє шифрування і переконатися, що повідомлення напевно прийшло від X (оскільки тільки X має KR_X). Арбітр А повинен переконатися в тому, що пара особистий / відкритий ключі X ще дійсна і, якщо це так, перевірити саме повідомлення. Потім А передає повідомлення Y, шифруючи його за допомогою KR,. Повідомлення включає Шх, двічі шифрування повідомлення і мітку дати / часу.

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

Стандарт цифрового підпису DSS

Національний інститут стандартів і технології США (NIST) розробив федеральний стандарт цифрового підпису DSS. Для створення цифрового підпису використовується алгоритм DSA (Digital Signature Algorithm). В якості хеш-алгоритму стандарт передбачає використання SHA-1 (Secure Hash Algorithm). DSS спочатку був запропонований в 1991 році й переглянутий в 1993 році у відповідь на публікації, що стосуються безпеки його схеми. У 1996 році в нього були внесені незначні зміни.

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

Рис. 14.1 Створення й перевірка підпису згідно стандарту DSS.

Стандарт DSS використовує при створенні підпису хеш-функцію. Значення хешу повідомлення є входом функції підпису разом з випадковим числом k, створеним для цього конкретного підпису (рис. 9). Функція підпису також залежить від приватного ключа відправника KR_A і деякої множини параметрів, відомих усім учасникам. Можна вважати, що ця множина утворює глобальний відкритий ключ KU_G. Результатом є підпис, що складається з двох компонентів, позначених як s та r.

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

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

Спільні компоненти групи користувачів (глобальний відкритий ключ)

Існує три параметри, які є відкритими й можуть бути спільними для великої групи користувачів.

Вибирається 160-бітне просте число q, тобто 2¹⁵⁹ < q < 2¹⁶⁰.

Потім вибирається таке просте число p довжиною від 512 до 1024 бітів, так, щоб q було дільником (p-1).

Нарешті, вибирається число g виду , де h є цілим в проміжку від 1 до (p-1) з тим обмеженням, що g повинне бути більшим за 1.

Знаючи ці числа, кожний користувач вибирає приватний ключ і створює відкритий ключ.

Приватний ключ відправника.

Приватний ключ x повинен бути числом між 1 і (p-1) і повинен бути обраним випадково або псевдовипадково.

x – випадкове або псевдовипадкове ціле, 0<x<q.

Відкритий ключ відправника.

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

Випадкове число, унікальне для кожного підпису.

k – випадкове або псевдовипадкове ціле число, 0<k<q, унікальне для кожного підпису.

Підписування.

Для створення підпису відправник обчислює дві величини, r і s, які є функцією компонентів спільного відкритого ключа (p,q,g), приватного ключа користувача (x), хеш-коду повідомлення H(M) і цілого числа k, унікального для кожного підпису.

Перевірка підпису.

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

підпис коректний, якщо v=r.

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

При труднощі обчислення дискретних логарифмів для противника виявляється нереальним з погляду обчислень знайти k за відомим r або знайти x за відомим s.