12

Лекція 9. Цифровий підпис

Вимоги до цифрового підпису

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

Наприклад, припустимо, що Абонент А посилає Абоненту В автентифіковане повідомлення, і автентифікація здійснюється на основі загального секрету. Розглянемо можливі непорозуміння, які можуть при цьому виникнути:

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

• Абонент А може заперечувати, що він посилав повідомлення Абоненту В. Так як Абонент В може підробити повідомлення, у нього немає способу довести, що Абонент А дійсно посилав його.

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

1. Повинна бути можливість перевірити автора, дату й час створення підпису.

2. Повинна бути можливість автентифікувати вміст під час створення підпису.

3. Підпис повинний бути перевіряємий третьою стороною для рішення спору.

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

На підставі цих властивостей можна сформулювати наступні вимоги до цифрового підпису:

1. Підпис повинний бути бітовим зразком, що залежить від повідомлення, що підписується.

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

3. Створювати цифровий підпис повинно бути відносно легко.

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

5. Цифровий підпис повинний бути досить компактним й не займати багато пам'яті.

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

Існує кілька підходів до використання функції цифрового підпису. Всі вони можуть бути розділені на дві категорії: прямі й арбітражні.

Прямі й арбітражна цифрові підписи

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

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

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

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

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

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

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

Симетричне шифрування, арбітр бачить повідомлення:

Х A: M || E_Kxa [ ID_X || H (M)]

Передбачається, що відправник Х и арбітр А розділяють секретний ключ K_ХА й що А и Y розділяють секретний ключ K_АY.. Х створює повідомлення М и обчислює його хеш-значення Н (М). Потім Х передає повідомлення й підпис А. Підпис складається з ідентифікатора Х и хеш-значення, усе зашифровано з використанням ключа K_ХА. А дешифрує підпис і перевіряє хеш-значение.

A Y: Е_Кay [ ID_X || M || E_Kxa [ID_X || H (M)], T ]

Потім А передає повідомлення до Y, шифруючи його K_AY. Повідомлення включає ID_X, первісне повідомлення від Х, підпис і мітку часу. Y може дешифрувати його для одержання повідомлення й підпису. Мітка часу інформує Y про те, що дане повідомлення не застаріло й не є повтором. Y може зберегти М и підпис до нього. У випадку суперечки Y, що затверджує, що одержав повідомлення М від Х, посилає наступне повідомлення до А:

Е_Кay [ ID_X || M || E_Kxa [ID_X || H (M)] ]

Арбітр використовує K_AY для одержання ID_Х, М и підпису, а потім, використовуючи K_ХА, може дешифрувати підпис і перевірити хеш-код. За цією схемою Y не може прямо перевірити підпис Х; підпис використовується винятково для вирішення спору. Y вважає повідомлення від Х автентифікованим, так як воно пройшло через А. У даному сценарії обидві сторони повинні мати високий ступінь довіри до А:

1. Х повинен довіряти А в тому, що той не буде розкривати K_ХА й створювати фальшиві підписи у формі Е_Kха [ID_X || H (M)].

2. Y повинен довіряти А в тому, що він буде посилати Е_Kay [ ID_X || M || E_Kxa [ID_X || H (M)] ] тільки в тому випадку, якщо хеш-значення є коректним і підпис була створений Х.

3. Обидві сторони повинні довіряти А в рішенні спірних питань.

Симетричне шифрування, арбітр не бачить повідомлення:

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

X A: ID_X || E_Kхy [M] || E_Kxa [ID_X || H (E_Kxy [M]) ]

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

A Y: E_Kay [ ID_X || E_Kxy[M] || E_Kxa [ ID_X || H ( E_Kxy [M])], T]

А передає Y усе, що він одержав від Х плюс мітку часу, всі шифруючи з використанням ключа K_AY.

Хоча арбітр і не може прочитати повідомлення, він у стані запобігти підробці кожного з учасників, Х або Y. Залишається проблема, як і в першому сценарії, що арбітр може зговоритися з відправником, що заперечує підписане повідомлення, або з одержувачем, для підробки підпису відправника.

Шифрування відкритим ключем, арбітр не бачить повідомлення:

Всі обговорювані проблеми можуть бути вирішені за допомогою схеми відкритого ключа.

X A: ID_X || E_KRх [ ID_X || E_KUy [E_KRx [M] ] ]

У цьому випадку Х здійснює подвійне шифрування повідомлення М, спочатку своїм закритим ключем KR_X, а потім відкритим ключем Y   KU_Y. Виходить підписана секретна версія повідомлення. Тепер це підписане повідомлення разом з ідентифікатором Х шифрується KR_X і разом з ID_X посилає А. Внутрішнє, двічі зашифроване, повідомлення недоступно арбітрові (і всім, крім Y). Однак А може дешифрувати зовнішнє шифрування, щоб переконатися, що повідомлення прийшло від Х (так як тільки Х має KR_X). Перевірка дає гарантію, що пара закритий/відкритий ключ законна, і тим самим верифікує повідомлення.

A Y: E_KRa [ ID_X || E_KUy [E_KRx [M] ] || T ]

Потім А передає повідомлення Y, шифруючи його KR_A. Повідомлення включає ID_X, двічі зашифроване повідомлення й мітку часу.

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