Як обмінюється ключ у протоколі шифрування приватного ключа?

Windows NT використовував протокол "точка-точка", коли клієнт може "безпечно" спілкуватися з сервером, використовуючи шифр потоку для шифрування масиву повідомлень за допомогою деякого ключа . Сервер також шифрує свою відповідь тим самим ключем . Але як усвідомлює цей ключ?$k$$k$

Більш загальне: якщо Аліса та Боб використовують якийсь алгоритм шифрування / дешифрування, який працює на тому ж приватному ключі , який безпечний спосіб обміну цим ключем? (без використання іншого ключа курсу)$k$

Це те, про що я завжди питав себе, вивчаючи криптографію приватного ключа.

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

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

Звичайно, як ви зазначаєте, безпечний обмін ключами залишається проблемою, яку певною мірою можна вирішити:

• Обмін ключами Diffie-Hellman : Використовує модульну артиметику для надійного обміну ключами.
• Центр розповсюдження одного / декількох ключів (KDC) : використовує надійну систему продажу квитків на основі сторонніх розробників
• Протокол автентифікації Kerberos : відносно складний протокол, заснований на KDC.

Щоразу, коли Аліса та Боб хочуть домовитись про один і той же приватний ключ, найпопулярнішим методом є використання Діффі-Хеллмана . Він працює наступним чином:

1. Спочатку вибираються дві загальнодоступні значення, скажімо, і . (Зазвичай це дуже великі прості числа і відомі всім, хто користується цим протоколом).г = $n=13$$g=17$

2. Аліса вибирає приватне значення а Боб обирає приватне значення . Вони приватні для себе.b = $a = 3$$b = 7$

3. Алісі обчислює: і Bob обчислює: , в цьому випадку і і вони обмінюються значеннями один одного (можливо, через чат), тобто всі знають значення і .$A = g^a\mod n$$B = g^b\mod n$$A = 12$$B = 4$$A$$B$

4. Алісі обчислює: і Bob обчислює: , в цьому випадку .$K = B^a \mod n$$K = A^b\mod n$$K = 12$

Тепер Аліса та Боб домовились значення як свого ключа. Зауважте, що оскільки значення і та дуже великі прості числа, підслуховувач майже неможливо їх розподілити та обчислити ключ.$K$$n$$g$

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

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

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

Існують способи обміну секретним ключем, для якого не потрібен секретний канал зв'язку. Найпопулярнішим є протокол обміну ключами Diffie-Hellman. Принцип Діффі-Хеллмана полягає в тому, що кожен учасник генерує свою власну пару ключів, і існує математична операція, яка конструює велику кількість з одного відкритого ключа та одного приватного ключа. Ця математична операція має дуже цікаву властивість: велика кількість може бути побудована з приватного ключа Аліси та відкритого ключа Боба, або з приватного ключа Боба та відкритого ключа Аліси; ви отримуєте однакове число в будь-якому випадку. Тож Аліса і Боб обмінюються своїми відкритими ключами, і обидві сторони знають велику кількість, яку потім можна використовувати як секретний ключ. Підслуховувач може знайти і відкритий ключ, але неможливо знайти велику кількість лише з відкритих ключів.

Обмін ключами Diffie-Hellman дозволяє двом сторонам обмінюватися секретом, незалежно від того, хто їх слухає. Однак це не автентифікує Алісу на Боба чи навпаки. Тому це може бути піддано нападу чоловіка в середині : Меллорі здійснює обмін ключовими словами з Еліс (яка вважає, що вона розмовляє з Боб) і окремо з Боб (хто вважає, що він розмовляє з Алісою), і, таким чином, отримує рішення або на принаймні знати секрет.

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

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

Існує багато варіантів, які використовують один із цих методів (або ще один варіант) в одному напрямку, або той самий, або інший метод в іншому напрямку, або автентифікують лише в одному напрямку. Наприклад, SSL / TLS (рівень криптографії для багатьох протоколів -s, таких як HTTPS, SMTPS, IMAPS тощо) може використовувати декілька різних комбінацій шифрів і, як правило, аутентифікувати сервер для клієнта, але може також і автентифікувати клієнта. Діффі-Хеллман повільний і громіздкий для цієї програми; Найпоширенішим алгоритмом з розподілом відкритих ключів є RSA .

Звичайно, Аліса та Боб, можливо, не знали публічного ключа один одного заздалегідь. Тож вони замість цього покладаються на ланцюжок довіри: Боб надсилає Алісі свій відкритий ключ, поряд із підписаною заявою третьої сторони, яка підтверджує, що цей ключ є дійсно відкритим ключем Боба. Ця підписана заява називається сертифікатом, а третя частина - органом сертифікації . Третя сторона може бути відома Боб, або її особа може бути підтверджена четвертою стороною тощо. Врешті-решт, ця ланцюжок довіри (… поручає на Домініка ваучери за Чарлі, який поручається на Боба) повинен дійти до якоїсь партії Рона, якій Боб уже довіряє, що означає, що Боб має відкритий ключ Рона і довіряє Рона лише підписувати дійсні сертифікати.

Є протоколи, які не покладаються на криптографію з відкритим ключем. Зокрема, протокол Kerberos використовується як в мережах на базі Unix, так і в Windows, щоб встановити з'єднання між клієнтом і сервером. Kerberos використовує центральний сервер аутентифікації, який називається центром розподілу ключів (KDC). У KDC повинен бути збережений пароль користувача в базі даних, а клієнт зазвичай запитує користувача про введення пароля. Щоб уникнути викриття пароля, протокол використовує пароль не безпосередньо, а криптографічний хеш або загалом ключову функцію виведення, застосовану до пароля.

За допомогою цієї спільної таємниці клієнт та KDC встановлюють захищений канал, і KDC надсилає клієнту "квиток". Білет містить сесійний ключ (тобто новостворений секретний ключ), а також копію ключа, зашифрованого іншим симетричним ключем, спільним між KDC та сервером, з яким клієнт хоче зв’язатися. Потім клієнт пересилає цю зашифровану копію на сервер. Сервер розшифровує це повідомлення, щоб отримати ключ сеансу, і генерує поняття, що воно шифрується за допомогою сеансового ключа та відправляє назад клієнту. Потім клієнт ініціює захищений канал із сервером, зашифрований ключем сеансу, і починається з показу, що він може розшифрувати ніколи: це автентифікує клієнта на сервері. Встановлення сесії в Керберосі - це варіант протоколу Needham-Schroeder .

¹ _{У тому сенсі, що криптографи намагалися дуже наполегливо, але найкращий спосіб, який вони знайшли, це вимагає недосяжної кількості обчислювальної потужності.}

Можливий спосіб - спочатку використовувати криптографію відкритого ключа для обміну приватним ключем. Однак, коли це неможливо, є деякі конкретні протоколи обміну ключами, мабуть, найбільш відомим є протокол Діффі-Гелмана .

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

Окрім протоколу обміну ключами Diffie-Hellman (DH), існують також протоколи квантового розподілу ключів . Один з найвідоміших протоколів QKD - це протокол Bennett-Brassard, BB84 .

Перевага BB84 перед DH полягає в тому, що DH є безпечним лише в тому випадку, якщо дискретний логарифм не може бути виконаний ефективно (див. Припущення щодо дискретного логарифму , а також відповідне припущення DDH ). Однак BB84 є теоретично безпечним для інформації. Тобто, навіть якщо , BB84 все одно буде безпечним (але DH не буде).$P=NP$

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