Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Безпека GRID – технологій.doc
Скачиваний:
0
Добавлен:
01.07.2025
Размер:
1.5 Mб
Скачать

3.1.5. Цифрові підписи: Цілісність в системах з відкритим ключем

Цілісність гарантується в системах з відкритим ключем, в яких використовуються цифрові підписи. Цифровий підпис – це частина даних, яка прикріпляється до повідомлення і яка може використовуватися, щоб з'ясувати чи було замінено повідомлення протягом діалогу (наприклад, через втручання зловмисника) (Рис.№8).

Рисунок 8. Цифровий підпис

Цифровий підпис для повідомлення генерується на двох етапах:

1. Генерується Резюме повідомлення. Резюме повідомлення – короткий звіт передаваного повідомлення, має дві важливі властивості: (1) Він завжди менший, ніж повідомлення безпосередньо (2) Навіть найлегша зміна в повідомленні проводить різне резюме. Резюме повідомлення генерується з використанням безлічі алгоритмів хешування.

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

Цифровий підпис прикріпляється до повідомлення, і відправляється одержувачеві. Одержувач потім виконує наступне:

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

2. Використовує той же алгоритм резюме повідомлення, використовуваний відправником, щоб генерувати резюме отриманого повідомлення.

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

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

3.1.6. Аутентифікація в системах із загальним ключем

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

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

3.1.7. Сертифікати і центри сертифікації (ca)

Цифровий сертифікат – це цифровий документ, який засвідчує, що певний загальний ключ належить конкретному користувачеві. Сертифікат підписує третя сторона іменована центр сертифікації (або CA). Мал. №9 ілюструє, що є цифровим свідоцтвом.

Рисунок 9. Цифровий сертифікат

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

Тому, можемо перевірити цілісність сертифікату, використовуючи загальний ключ CA.

3.1.8. Довіра

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

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

Потрібно буде вирішити який CA включити в цей список. Деякі CA добре відомі і їх включають за умовчанням в багатьох системах із загальним ключем (наприклад, веб-навігатори зазвичай включають VeriSign (http://www.verisign.com) і GlobalSign (http://www.globalsign.com) сертифікати, тому що багато веб-вузлів використовують сертифікати, випущені цими компаніями. Звичайно, є можливість додати і інший CA до “Довіреного списку”. Наприклад, якщо ваш відділ встановлює CA, і ви довіряєте, що CA відділ видаватиме свідоцтва тільки надійним людям, тому ви можете додати його до списку.