Как работает обмен ключами в протоколе Диффи-Хеллмана
Рассказывает Сеид Садат Назрул. Днём он ловит киберпреступников с помощью машинного обучения, а по ночам ведёт блоги 🙂
Обмен ключами с помощью протокола Диффи-Хеллмана (DH) — это метод безопасного обмена криптографическими ключами по общедоступному каналу. Это один из первых протоколов с открытым ключом, который изначально был концептуализирован Ральфом Мерклем и назван в честь Уитфилда Диффи и Мартина Хеллмана. DH является одним из первых практических примеров обмена открытыми ключами. Сегодня DH используется для многих приложений, таких как, например, Proton Mail, SSH, GPG и так далее. В статье мы рассмотрим принципы работы этого протокола и проблемы, которые он решает.
Проблема в сквозном шифровании
Давайте возьмём простейшую ситуацию. Представьте, Майкл и я решили обменяться информацией. А хакер по имени Мистер Робот пытается перехватить наше сообщение.
Логичный способ помешать Мистеру Роботу прочитать наше сообщение — шифрование.
Чтобы расшифровать сообщение Майкла, мне нужно, чтобы он отправил мне ключ по сети. Проблема в том, что Мистер Робот следит за перепиской и обязательно увидит ключ. Получив ключ, он легко сможет расшифровать все наши сообщения! Эта проблема обмена ключами решается с помощью алгоритма Диффи-Хеллмана.
Как Диффи-Хеллман решает проблему?
Диффи-Хеллман работает по принципу неполного обмена ключом шифрования по сети. У каждой стороны есть открытый ключ (который может видеть каждый, включая Мистера Робота) и закрытый ключ (его может видеть только пользователь компьютера). У меня нет доступа к личному ключу Майкла. У Майкла — к моему.
Теперь давайте предположим, что мы оба используем общий алгоритм шифрования, и нам нужно каким-то образом восстановить общий ключ шифрования, не передавая слишком много информации через сеть.
Создание базового класса
Ниже приведён предварительный базовый класс одной стороны, использующей шифрование DH. Пока не беспокойтесь о деталях, так как мы подробно рассмотрим каждую функцию!
class DH_Endpoint():
def __init__(self, public_key1, public_key2, private_key):
self.public_key1 = public_key1
self.public_key2 = public_key2
self.private_key = private_key
self.full_key = None
def generate_partial_key(self):
partial_key = self.public_key1 ** self.private_key
partial_key = partial_key % self.public_key2
return partial_key
def generate_full_key(self, partial_key_r):
full_key = partial_key_r ** self.private_key
full_key = full_key % self.public_key2
self.full_key = full_key
return full_key
def encrypt_message(self, message):
encrypted_message = ""
key = self.
Давайте определим секретное сообщение, которое Майкл планирует отправить мне, а также наши закрытые и открытые ключи, установленные на компьютерах. В реальной жизни обычно используются большие простые числа, здесь мы будем использовать небольшие значения для простого отображения математической части.
message = "This is a very secret message!!!"
s_public = 197
s_private = 199
m_public = 151
m_private = 157
Sadat = DH_Endpoint(s_public, m_public, s_private)
Michael = DH_Endpoint(s_public, m_public, m_private)
Частичный обмен ключами
Давайте предположим, что мы ничего не видим внутри сервера Майкла (включая его личный ключ).
Теперь мне нужно создать частичный ключ шифрования, используя 3 доступные единицы информации: мой закрытый и открытый ключи и открытый ключ Майкла. Алгоритмически мы согласились использовать мой открытый ключ в качестве базы и его открытый ключ в качестве модуля.
Если мы посмотрим на нашу функцию для генерации частичного ключа, то она именно эти вычисления и делает:
class DH_Endpoint():
def __init__(self, public_key1, public_key2, private_key):
self.public_key1 = public_key1
self.public_key2 = public_key2
self.private_key = private_key
self.full_key = None
def generate_partial_key(self):
partial_key = self.public_key1 ** self.private_key
partial_key = partial_key % self.public_key2
return partial_key
def generate_full_key(self, partial_key_r):
full_key = partial_key_r ** self.private_key
full_key = full_key % self.public_key2
self.full_key = full_key
return full_key
def encrypt_message(self, message):
encrypted_message = ""
key = self.
Теперь давайте сгенерируем этот частичный ключ и отправим его Майклу по сети.
s_partial = Sadat.generate_partial_key()
print(s_partial) # 147Таким же образом Майкл посылает мне свой частичный ключ по сети.
m_partial = Michael.generate_partial_key()
print(m_partial) # 66Сравнение обоих вычислений частичного ключа:
Мистер Робот, естественно, увидел обмен частичными ключами.
Он также знает оба открытых ключа. Теперь ему нужно взломать наши соответствующие закрытые ключи.
Всё, что знает Мистер Робот, — это частичные ключи и соответствующие открытые ключи, а также формула, используемая для получения частичных ключей. Особенность вычисления по модулю в том, что функция заставляет значение циклически изменяться. Если у вас есть модуль 151, значение будет между 0 и 151-1.
Существует бесконечное число возможных значений, которые по модулю 151 будут равны либо 66, либо 147. В результате информации для получения закрытых ключей пользователей недостаточно (если не считать грубый перебор безумно большого числа всевозможных вариантов). Кроме того, в примере используются небольшие числа для закрытых и открытых ключей, что делает подбор реальным. В реальной жизни это было бы почти невозможно!
Генерация полного ключа
Теперь, когда мы успешно обменялись частичными ключами, давайте снова применим операторы степени и деления с остатком к частичному ключу другого человека, используя наши собственные закрытые ключи следующим образом:
Реализация этого в Python:
class DH_Endpoint():
def __init__(self, public_key1, public_key2, private_key):
self.public_key1 = public_key1
self.public_key2 = public_key2
self.private_key = private_key
self.full_key = None
def generate_partial_key(self):
partial_key = self.public_key1 ** self.private_key
partial_key = partial_key % self.public_key2
return partial_key
def generate_full_key(self, partial_key_r):
full_key = partial_key_r ** self.private_key
full_key = full_key % self.public_key2
self.full_key = full_key
return full_key
def encrypt_message(self, message):
encrypted_message = ""
key = self.
s_partial = Sadat.generate_partial_key()
print(s_partial) # 147
def generate_full_key(self, partial_key_r):
full_key = partial_key_r ** self. private_key
full_key = full_key % self.public_key2
self.full_key = full_key
return full_key
private_key
full_key = full_key % self.public_key2
self.full_key = full_key
return full_keyКод с моей стороны:
s_full = Sadat.generate_full_key(m_partial)
print(s_full) # 75И то же самое для Майкла, использующего мой частичный ключ:
m_full=Michael.generate_full_key(s_partial)
print(m_full) # 75
Сравнивая их:
Заметили что-нибудь интересное? Мы оба получили одинаковые полные ключи, равные 75! Причина заключается в следующем математическом соотношении:
Здесь a и b — закрытые ключи, а g и p — открытые. Нам удалось обменяться друг с другом по сети достаточным количеством информации, чтобы сгенерировать общий ключ шифрования, не ставя под угрозу наши закрытые ключи.
Время шифрования!
Теперь, когда у нас есть общий ключ шифрования, пришло время начать обмен сообщениями! Как объяснялось в начале этого раздела, Майкл хочет отправить мне зашифрованное сообщение.
Вот простой алгоритм, который я написал для шифрования сообщения Майкла:
def encrypt_message(self, message):
encrypted_message = ""
key = self.full_key
for c in message:
encrypted_message += chr(ord(c) + key)
return encrypted_message
Ничего особенного. Каждый символ кодируется в целое число, значение ключа добавляется, а затем целое число преобразуется обратно в символ. Этот процесс повторяется для каждого символа в сообщении. Первоначальное сообщение, которым хотел поделиться Майкл:
Прим. пер.: это шифр простой замены, которым в реальной жизни пользоваться не стоит. Взламывается чуть сложнее классического, но всё равно достаточно быстро.
m_encrypted = Michael.encrypt_message(message)
print(m_encrypted) # '\x9f³´¾k´¾k¬kÁ°½Äk¾°®½°¿k¸°¾¾¬²°lll'Зашифрованное сообщение — «\x9f³´¾k´¾k¬kÁ°½Äk¾°®½°¿k¸°¾¾¬²°lll», что при чтении выглядит как бессвязный набор символов.
Мистер Робот понятия не имеет, чем Майкл делится со мной по сети.
Теперь пришло время расшифровать сообщение с моей стороны.
def decrypt_message(self, encrypted_message): decrypted_message = "" key = self.full_key for c in encrypted_message: decrypted_message += chr(ord(c) — key) return decrypted_messages_full = Sadat.generate_full_key(m_partial) print(s_full) # 75
Эта функция делает обратное преобразование. На этапе шифрования было добавлено значение ключа, на этапе расшифровки будет вычтено то же самое значение.
message = Sadat.decrypt_message(m_encrypted)
print(message) # 'This is a very secret message!!!'Получил сообщение! Хорошая попытка, Мистер Робот. Нам удалось обмениваться зашифрованными сообщениями, не поставив под угрозу наши ключи шифрования.
Удачи с Evil Corp!
Мы рассмотрели механику работы алгоритма Диффи-Хеллмана на примерах с цифрами и кодом на Python. Если вы хотите закрепить полученные знания, будет полезно посмотреть это видео:
Перевод статьи «Diffie-Hellman Key Exchange explained (Python)»,
Варвара Николаева
SSH обмен ключами — CodeRoad
У меня есть 2 сервера, с которыми я работаю: первый-сервер приложений, а второй-архивный сервер. Я получаю доступ к обоим этим серверам с помощью клиента F-Secure SSH, используя один и тот же идентификатор пользователя и пару открытых и закрытых ключей для аутентификации. Это означает, что закрытый ключ хранится на машине Windows, а открытый ключ — на обоих серверах.
Теперь мне нужно получить доступ к архивному серверу с сервера приложений. Для этого я должен сначала сделать обмен ключами.
Что такое стандартный подход в этом случае? Должен ли я просто скопировать свой закрытый ключ с Windows на сервер приложений? Не поставит ли это под угрозу безопасность? Или мне нужно сгенерировать новый ключ pare?
Я ценю вашу помощь!
P.
S. я относительно новичок в администрации Unix, так что не будьте очень строги ко мне 🙂
Поделиться Источник Dima 29 июня 2011 в 17:05
2 ответа
- Perl Net::SSH::Any с обменом ключами
Мне нужно иметь возможность использовать Perl для определения версии python, работающей на удаленных серверах, с которыми у меня есть обмен ключами. Чтобы попытаться сделать это, я использую Net::SSH::Any , но хочу использовать обмен ключами вместо указания пароля в скрипте. Я посмотрел на пример…
- RSA Шифрование Java, Обмен Ключами
Попытка зашифровать текстовое сообщение с помощью алгоритма RSA. Для шифрования сообщения требуется ключ от клиента. Как происходит обмен ключами. Я изучил несколько алгоритмов обмена ключами, но не смог найти ни одного примера кода. Может быть, кто-то один руководство к учебнику, о том, как.
..
..
5
Стандартный подход заключается в:
- Создайте на каждой машине/пользователе новую пару закрытых/открытых ключей
- Используйте файл авторизованных ключей в .ssh и добавьте каждый открытый ключ
- Скопируйте этот файл авторизованных ключей на каждый удаленный хост
Примечание: Файл авторизованного ключа, а также пары ключей связаны user@machine
Sidenote2: Обычно ppl полностью блокирует корень из этого процесса. Root не должен быть доступен ни через pw auth, ни с помощью ключа auth.
Поделиться fyr 29 июня 2011 в 17:09
1
Ответ @fyr верен, однако вам не нужно ничего добавлять или копировать вручную. Вы можете сделать это с ssh-copy-id .
Предполагая, что сервер SSH на вашей новой машине уже запущен, с вашей старой машины (которая уже имеет пару ключей SSH, если не запустить ssh-keygen) выполните
ssh-copy-id -i ~/. ssh/mykey user@host
ssh/mykey user@host
где параметр -i обозначает местоположение вашего открытого ключа. Инструмент ssh-copy-id при необходимости добавит расширение .pub, поэтому он не будет пытаться отправить ваш закрытый ключ.
Реальный пример этого, скажем, обмен ключами с A Raspberry Pi, будет следующим:
ssh-copy-id -i ~/.ssh/id_rsa [email protected]
Он запросит ваш пароль, но только один раз. Если обмен ключами пройдет успешно,вы сможете войти в него без пароля.
Поделиться kjekk 29 мая 2020 в 16:49
Похожие вопросы:
Как отключить обмен ключами сервера из кода?
Я запускаю пример сервера HTTP2 (libevent-server.c) из nghttp2 на Ubuntu 15.04. Я хотел бы обнюхать пакет HTTP2 между клиентом и сервером с помощью Wireshark. Я не использую какой-либо веб-браузер в…
Обмен ключами с использованием ECDH против ECIES
Я новичок в криптопрограммировании ECC.
Кто-нибудь объяснит мне разницу между использованием ECDH для обмена общими ключами и использованием ECIES путем шифрования общего ключа с открытым ключом…
Windows / Linux автоматический обмен ключами
У меня есть коробка сборки, которую я использую для создания непрерывных сборок, а также для запуска ночных модульных тестов. Я использую Jenkins для выполнения сценариев сборки/модульного…
Perl Net::SSH::Any с обменом ключами
Мне нужно иметь возможность использовать Perl для определения версии python, работающей на удаленных серверах, с которыми у меня есть обмен ключами. Чтобы попытаться сделать это, я использую…
RSA Шифрование Java, Обмен Ключами
Попытка зашифровать текстовое сообщение с помощью алгоритма RSA. Для шифрования сообщения требуется ключ от клиента. Как происходит обмен ключами. Я изучил несколько алгоритмов обмена ключами, но не…
Kerberized ssh-обмен ключами происходит медленно
После нескольких дней работы над этим у меня есть работающая система CentOS 6.
3, привязанная к домену AD под управлением Windows 2008R2. Мой метод-pam на основе sssd с использованием аутентификации…
Диффи-Хеллман ssh keyxchange
Я задался целью сделать примитивный клиент SSH в C#; вы, возможно, помните меня из таких постов, как примитивное соединение ssh (lowlevel) хе-хе. Во всяком случае, все идет отлично вплоть до того…
Как ssh использовать RSA и DH
Я слышал, как SSH использует RSA и Диффи Хеллман. Я также знаю процесс обмена ключами следующим образом. Клиент инициализации Сервер инициализации Запрос на обмен ключами Ответить Новые ключи Он…
Как запустить контейнер LXD на другом узле и обменяться ключами ssh с контейнером?
Как запустить и LXD контейнер на другом узле и обменять ssh Ключей с контейнером? То есть как дать Ansible прямой доступ к контейнеру LXD с помощью SSH? Я знаю о модуле authorized_key, однако это…
SSH обмен ключами с альтернативным пользователем
Поэтому я использую RHEL 7.
У меня есть два сервера со следующими учетными записями пользователей корень (очевидный) администратор Я хочу, чтобы установка работала следующим образом. беспарольный…
Перевод %d0%be%d0%b1%d0%bc%d0%b5%d0%bd%20%d0%ba%d0%bb%d1%8e%d1%87%d0%b0%d0%bc%d0%b8 на турецкий
Я знала, как высоко Бог ценит человека и его тело, но даже это не останавливало меня. Дженнифер, 20 лет
Tanrı’nın insan bedenine büyük değer verdiğini biliyordum, ama bu bile beni durdurmadı” (Ceren, 20).
jw2019
Спорим на 20 баксов, что ты не сможешь провести целый день одна.
Yirmi dolara bahse girerim bir gün boyunca yalnız başına kalamazsın.
OpenSubtitles2018.v3
Когда мы помогаем другим, мы и сами в какой-то мере испытываем счастье и удовлетворение, и наше собственное бремя становится легче (Деяния 20:35).
Başkalarına kendimizden verdiğimizde, sadece onlara yardım etmiş olmayız, kendi yüklerimizi daha kolay taşınır kılan bir mutluluk ve doyum da tadarız.
—Resullerin İşleri 20:35.
jw2019
Он уехал 20 минут назад.
OpenSubtitles2018.v3
20 Я приведу их в землю, о которой клялся их предкам+, в землю, где течёт молоко и мёд+, и они будут есть+ досыта, разжиреют+ и повернутся к другим богам+.
+ 20 Çünkü atalarına yeminle vaat ettiğim+ süt ve bal akan topraklara+ onları getireceğim, orada yiyip+ doyacaklar, semirecekler+ ve başka tanrılara yönelecekler,+ onlara kulluk edecek, Bana saygısızlık yaparak ahdimi bozacaklar.
jw2019
Я был женат 20 лет.
OpenSubtitles2018.v3
20 Оставлена родителями, но любима Богом
20 Bunları Biliyor Musunuz?
jw2019
20 Даже преследование или заключение в тюрьму не может закрыть уста преданных Свидетелей Иеговы.
20 Zulüm ve hapsedilme bile Yehova’nın sadık Şahitlerini susturamaz.
jw2019
Ты был в отключке минут 20.
Yaklaşık 20 dakikadır buradasın..
OpenSubtitles2018.v3
Есть ещё кое- что в начале 20— го века, что усложняло вещи ещё сильнее.
Şimdi 20. yüzyılın başlarında herşeyi daha da karışık hale getiren başka birşey daha var.
QED
б) Чему мы учимся из слов, записанных в Деяниях 4:18—20 и Деяниях 5:29?
(b) Elçiler 4:18-20 ve 5:29’daki sözlerden ne öğreniyoruz?
jw2019
«К одинадцати Апостолам» был причислен Матфий, чтобы служить с ними (Деяния 1:20, 24—26).
Bunun üzerine, “on bir resuller ile” birlikte hizmet etmek üzere Mattias tayin edildi.—Resullerin İşleri 1:20, 24-26.
jw2019
Большинство местных органов при планировании развития на следующие 5, 10, 15, 20 лет начинают с предпосылки, что можно ожидать больше энергии, больше автомобилей, больше домов, больше рабочих мест, больше роста и т.
д.
Gelecekteki 5, 10, 15, 20 yılı hesaplamak için masaya oturduklarında yerel yetkililerin çoğu daha fazla enerji daha fazla araba ve ev daha fazla iş ve daha fazla kalkınma vb. olacağını farzederek işe başlıyorlar.
ted2019
Именно это приводит к счастью, как было сказано царем Соломоном: «Кто надеется на Господа, тот блажен [счастлив, НМ]» (Притчи 16:20).
Kral Süleyman’ın açıkladığı gibi bu, mutluluğa katkıda bulunur: “RABBE güvenen mutlu olur.”—Süleymanın Meselleri 16:20.
jw2019
20 Тогда Ио́в встал, разорвал+ на себе верхнюю одежду, остриг свою голову+, упал на землю+, поклонился+ 21 и сказал:
20 Eyüp kalktı, üstündeki kaftanı yırttı,+ saçını kesti+ ve eğilip+ yere kapanarak+ 21 şunları söyledi:
jw2019
Будьте щедрыми и заботьтесь о благополучии других (Деяния 20:35).
Cömert olmak ve başkalarını mutlu etmek için çaba harcamak (Elçiler 20:35).
jw2019
Два важнейших события 20 века:
20.yy en önemli iki olayı:
OpenSubtitles2018.v3
Это забавно, когда тебе 20 лет.
İnsan 20 yaşındayken ne kadar saf oluyor.
OpenSubtitles2018.v3
Он хочет 20 кусков и Иксбокс
20 bin dolar ve bir Xbox oldu diyor.
OpenSubtitles2018.v3
Исследователи провели эксперимент с учащимися колледжа — юношами и девушками. В течение 20 минут одна группа играла в жестокие видеоигры, а другая — в обычные.
Araştırmacılar rastgele seçilen kız ve erkek öğrencilerden 20 dakika boyunca şiddet içeren ya da içermeyen video oyunları oynamalarını istediler.
jw2019
Он мертв уже 20 лет.
OpenSubtitles2018.v3
В 1300-х годах бубонная чума убила около 20% населения Земли.
1300’lü yıllarda veba salgını dünya nüfusunun% 20‘sini yok etti.
OpenSubtitles2018.v3
Я попросил кофе 20 минут назад.
20 dakika önce kahve istemiştim.
OpenSubtitles2018.v3
Ему всего 20, но он уже живая легенда.
Daha yirmisinde ama yaşayan bir efsane.
OpenSubtitles2018.v3
Хорошо, подумайте об этих 20-25 минутах.
Şimdi o 20-25 dakikayı düşün.
OpenSubtitles2018.v3
keepassxc-browser 🚀 — бесполезная ошибка «Обмен ключами не прошел успешно». когда собственный хост обмена сообщениями не настроен
Просто для записи … давно сходил с ума от этой проблемы и только что нашел время, чтобы отладить и выяснить это … я использую хром , (ungoogle-chromium) + Linux … но Я опубликую решение в соответствии с Firefox и другими системами .
.. это может помочь кому-то с аналогичной проблемой …
Прежде всего, это подробная документация (чтение — вот что привело меня к решению …)
Также в Chrome простой способ отладки — открыть режим разработчика в правом верхнем углу, затем щелкнуть Проверить фон представлений … под квадратом расширения KeepassXC … также под кнопкой подробностей вы можете выбрать сбор ошибок …
Прежде чем двигаться дальше, первое, что нужно сделать, это следовать вики-странице по устранению неполадок KeepassXC-браузера и обновить / исправить файл манифеста json, как описано там.
Затем (и здесь моя конфигурация / ошибка меня застряла) в собственной системе и / или ограничивать / запрещать, например, для chromium + linux политика json в манифесте под /etc/chromium/policies/managed/manifest.json которая содержит "NativeMessagingUserLevelHosts": false, полностью заблокирует систему и приведет к выдаче ошибки Key exchange was not successful в этом случае просто измените значение на true или просто удалите эту строку и вуаля 🙂
В понравившейся документации описываются разные места для разных политик, разных браузеров и ОС.
Я, вероятно, обновлю вики, чтобы обеспечить полное устранение неполадок собственной системы сообщений, иногда для некоторой расширенной настройки манифеста в местоположении пользователя недостаточно (как в моем случае)
Также во время отладки вы можете оставить диспетчер задач открытым, чтобы увидеть, запускает ли браузер двоичный файл keepassxc-proxy … также эту функцию необходимо включить в настройках KeepassXC.
Что такое TLS-рукопожатие и как оно устроено
TLS — это один из наиболее часто встречающихся инструментов безопасности, используемых в интернете, — пишет tproger.ru в своем переводе статьи Taking a Closer Look at the SSL/TLS Handshake. Протокол активно работает со многими процессами сетевого взаимодействия: передачей файлов, VPN-подключением (в некоторых реализациях для обмена ключами), службами обмена мгновенными сообщениями или IP-телефонией.
Один из ключевых аспектов протокола — это рукопожатие. Именно о нём мы поговорим в этой статье.
«Рукопожатие SSL/TLS» — это название этапа установки HTTPS-соединения. Большая часть работы, связанной с протоколом SSL/TLS, выполняется именно на этом этапе. В прошлом году IETF доработал TLS 1.3, полностью обновив процесс рукопожатия.
В статье будут освещены два вида рукопожатия — для протоколов TLS 1.2 и TLS 1.3, которые мы рассмотрим, начиная с абстрактного уровня и постепенно углубляясь в особенности:
- согласование криптографических протоколов;
- аутентификация с помощью SSL-сертификата;
- генерация сеансового ключа.
Как происходит TLS-рукопожатие
В HTTPS-соединении участвуют две стороны: клиент (инициатор соединения, обычно веб-браузер) и сервер. Цель рукопожатия SSL/TLS — выполнить всю криптографическую работу для установки безопасного соединения, в том числе проверить подлинность используемого SSL-сертификата и сгенерировать ключ шифрования.
Согласование шифронабора
Каждое программное обеспечение уникально.
Поэтому даже самые популярные веб-браузеры имеют различную функциональность. Аналогично и на стороне сервера — Windows Server, Apache и NGINX также отличаются друг от друга. Всё становится ещё сложнее, когда вы добавляете пользовательские конфигурации.
Именно поэтому первый шаг TLS-рукопожатия — обмен информацией о своих возможностях между клиентом и сервером для дальнейшего выбора поддерживаемых криптографических функций.
Как только клиент и сервер согласовывают используемый шифронабор, сервер отправляет клиенту свой SSL-сертификат.
Аутентификация
Получив сертификат, клиент проверяет его на подлинность. Это чрезвычайно важный шаг. Чтобы соединение было безопасным, нужно не только зашифровать данные, нужно ещё убедиться, что они отправляются на правильный веб-сайт. Сертификаты SSL/TLS обеспечивают эту аутентификацию, а то, как они это делают, зависит от используемого шифронабора.
Все доверенные SSL-сертификаты выпускаются центром сертификации (ЦС).
ЦС должен следовать строгим правилам выдачи и проверки сертификатов, чтобы ему доверяли. Вы можете считать ЦС кем-то вроде нотариуса — его подпись значит, что данные в сертификате реальны.
Во время аутентификационной части TLS-рукопожатия клиент выполняет несколько криптографически безопасных проверок с целью убедиться, что выданный сервером сертификат подлинный. Процесс включает в себя проверку цифровой подписи и того, выдан ли сертификат доверенным ЦС.
На этом этапе клиент косвенно проверяет, принадлежит ли серверу закрытый ключ, связанный с сертификатом.
В RSA, самой распространённой криптосистеме с открытым ключом, клиент с помощью открытого ключа шифрует случайные данные, которые будут использоваться для генерации сеансового ключа. Сервер сможет расшифровать и использовать эти данные, только если у него есть закрытый ключ, наличие которого обеспечивает подлинность стороны.
Если используется другая криптосистема, алгоритм может измениться, но проверка другой стороны на подлинность всё равно останется.
Обмен ключами
Последняя часть TLS-рукопожатия включает создание «сеансового ключа», который фактически будет использоваться для защищённой связи.
Сеансовые ключи являются «симметричными», то есть один и тот же ключ используется для шифрования и дешифрования.
Симметричное шифрование производительнее, чем асимметричное, что делает его более подходящим для отправки данных по HTTPS-соединению. Точный метод генерации ключа зависит от выбранного шифронабора, два самых распространённых из них — RSA и Диффи-Хеллман.
Чтобы завершить рукопожатие, каждая сторона сообщает другой, что она выполнила всю необходимую работу, а затем проверяет контрольные суммы, чтобы убедиться, что рукопожатие произошло без какого-либо вмешательства или повреждения.
Всё SSL-рукопожатие происходит за несколько сотен миллисекунд. Это первое, что произойдёт при HTTPS-соединении, даже до загрузки веб-страницы. После SSL-рукопожатия начинается зашифрованное и аутентифицированное HTTPS-соединение, и все данные, отправляемые и получаемые клиентом и сервером, защищены.
Вплоть до TLS 1.3 каждый раз, когда вы посещали сайт, рукопожатие происходило заново. Рукопожатие TLS 1.3 поддерживает 0-RTT или нулевое время возобновления приёма-передачи, что значительно увеличивает скорость для вернувшегося посетителя.
Пошаговый процесс рукопожатия в TLS 1.2
Рассмотрим TLS-рукопожатие с использованием RSA подробнее. Использование алгоритма Диффи-Хеллмана будет описано ниже.
- Первое сообщение называется «Client Hello». В этом сообщении перечислены возможности клиента, чтобы сервер мог выбрать шифронабор, который будет использовать для связи. Также сообщение включает в себя большое случайно выбранное простое число, называемое «случайным числом клиента».
- Сервер вежливо отвечает сообщением «Server Hello». Там он сообщает клиенту, какие параметры соединения были выбраны, и возвращает своё случайно выбранное простое число, называемое «случайным числом сервера». Если клиент и сервер не имеют общих шифронаборов, то соединение завершается неудачно.
- В сообщении «Certificate» сервер отправляет клиенту свою цепочку SSL-сертификатов, включающую в себя листовой и промежуточные сертификаты. Получив их, клиент выполняет несколько проверок для верификации сертификата. Клиент также должен убедиться, что сервер обладает закрытым ключом сертификата, что происходит в процессе обмена/генерации ключей.
- Это необязательное сообщение, необходимое только для определённых методов обмена ключами (например для алгоритма Диффи-Хеллмана), которые требуют от сервера дополнительные данные.
- Сообщение «Server Hello Done» уведомляет клиента, что сервер закончил передачу данных.
- Затем клиент участвует в создании сеансового ключа. Особенности этого шага зависят от метода обмена ключами, который был выбран в исходных сообщениях «Hello». Так как мы рассматриваем RSA, клиент сгенерирует случайную строку байтов, называемую секретом (pre-master secret), зашифрует её с помощью открытого ключа сервера и передаст обратно.
- Сообщение «Change Cipher Spec» позволяет другой стороне узнать, что сеансовый ключ сгенерирован и можно переключиться на зашифрованное соединение.
- Затем отправляется сообщение «Finished», означающее, что на стороне клиента рукопожатие завершено. С этого момента соединение защищено сессионным ключом. Сообщение содержит данные (MAC), с помощью которых можно убедиться, что рукопожатие не было подделано.
- Теперь сервер расшифровывает pre-master secret и вычисляет сеансовый ключ. Затем отправляет сообщение «Change Cipher Spec», чтобы уведомить, что он переключается на зашифрованное соединение.
- Сервер также отправляет сообщение «Finished», используя только что сгенерированный симметричный сеансовый ключ, и проверяет контрольную сумму для проверки целостности всего рукопожатия.
После этих шагов SSL-рукопожатие завершено. У обеих сторон теперь есть сеансовый ключ, и они могут взаимодействовать через зашифрованное и аутентифицированное соединение.
На этом этапе могут быть отправлены первые байты веб-приложения (данные, относящиеся к фактическому сервису, — HTML, Javascript и т. д.).
Пошаговый процесс рукопожатия в TLS 1.
3Рукопожатие TLS 1.3 значительно короче, чем его предшественник.
- Как и в случае TLS 1.2, сообщение «Client Hello» запускает рукопожатие, но на этот раз оно содержит гораздо больше информации. TLS 1.3 сократил число поддерживаемых шифров с 37 до 5. Это значит, что клиент может угадать, какое соглашение о ключах или протокол обмена будет использоваться, поэтому в дополнение к сообщению отправляет свою часть общего ключа из предполагаемого протокола.
- Сервер ответит сообщением «Server Hello». Как и в рукопожатии 1.2, на этом этапе отправляется сертификат. Если клиент правильно угадал протокол шифрования с присоединёнными данными и сервер на него согласился, последний отправляет свою часть общего ключа, вычисляет сеансовый ключ и завершает передачу сообщением «Server Finished».
- Теперь, когда у клиента есть вся необходимая информация, он верифицирует SSL-сертификат и использует два общих ключа для вычисления своей копии сеансового ключа. Когда это сделано, он отправляет сообщение «Client Finished».
Издержки TLS-рукопожатия
Исторически одна из претензий к SSL/TLS заключалась в том, что он перегружал серверы дополнительными издержками. Это повлияло на ныне несуществующее представление, что HTTPS медленнее, чем HTTP.
Рукопожатия до TLS 1.2 требовали много ресурсов и в больших масштабах могли серьёзно нагрузить сервер. Даже рукопожатия TLS 1.2 могут замедлить работу, если их происходит много в один момент времени. Аутентификация, шифрование и дешифрование — дорогие процессы.
На небольших веб-сайтах это скорее всего не приведёт к заметному замедлению работы, но для корпоративных систем, куда ежедневно приходят сотни тысяч посетителей, это может стать большой проблемой. Каждая новая версия рукопожатия существенно облегчает процесс: TLS 1.2 совершает две фазы, а TLS 1.3 укладывается всего в одну и поддерживает 0-RTT.
Улучшения рукопожатия TLS 1.3 по сравнению с TLS 1.2
В приведённом выше объяснении рукопожатие разделено на десять отдельных этапов.
В действительности же многие из этих вещей происходят одновременно, поэтому их часто объединяют в группы и называют фазами.
У рукопожатия TLS 1.2 можно выделить две фазы. Иногда могут потребоваться дополнительные, но когда речь идёт о количестве, по умолчанию подразумевается оптимальный сценарий.
В отличие от 1.2, рукопожатие TLS 1.3 укладывается в одну фазу, хотя вернее будет сказать в полторы, но это всё равно значительно быстрее, чем TLS 1.2.
Сокращение шифронаборов
Никто никогда не собирался использовать 37 наборов для шифрования данных, так эволюционировал протокол. Каждый раз, когда добавлялся новый алгоритм, добавлялись новые комбинации, и вскоре IANA администрировала 37 различных шифронаборов.
Это плохо по двум причинам:
- Такая варьируемость приводит к ошибочным конфигурациям, которые делают интернет-пользователей уязвимыми для известных эксплойтов.
- Это сделало настройку SSL более запутанной.
IETF исключил в TLS 1.
3 поддержку всех алгоритмов, кроме самых безопасных, убирая путаницу за счёт ограничения выбора. В частности, был убран выбор метода обмена ключами. Эфемерная схема Диффи-Хеллмана стала единственным способом, позволяющим клиенту отправить информацию о своём ключе вместе с «Client Hello» в первой части рукопожатия. Шифрование RSA было полностью удалено вместе со всеми другими схемами обмена статическими ключами.
При этом есть одна потенциальная ахиллесова пята в TLS 1.3.
Нулевое время возобновления приёма-передачи — 0-RTT
0-RTT — это то, к чему стремился весь технологический мир, и вот оно здесь с TLS 1.3. Как уже было упомянуто, рукопожатие TLS исторически было не быстрым, так что было важно ускорить его. 0-RTT делает это путём сохранения некоторой секретной информации о клиенте, обычно идентификатора сеанса или сеансовых тикетов, чтобы использовать их при следующем соединении.
Несмотря на все преимущества 0-RTT, он содержит пару потенциальных подводных камней.
Режим делает клиентов восприимчивыми к атакам воспроизведения, когда злоумышленник, которому каким-то образом удаётся получить доступ к зашифрованному сеансу, может получить данные 0-RTT, включая первый запрос клиента, и снова отправить их на сервер.
Тем не менее, использовать эксплойт непросто. Вероятно, такой риск — небольшая цена за чрезвычайно полезную функцию.
Безопасность
С самого начала вызывало опасение количество информации, отправляемой в виде открытого текста во время рукопожатия. Очевидно, что это небезопасно, поэтому чем больше шагов рукопожатия происходит в зашифрованном виде, тем лучше.
В рукопожатии TLS 1.2 этапы согласования не были защищены, вместо этого использовалась простая MAC-функция, чтобы никто не вмешался в передачу. В этап согласования входят сообщения «Client Hello» и «Server Hello».
MAC-функция действует как индикатор, но не даёт никаких гарантий безопасности. Возможно, вы слышали об атаке, которая вынуждает стороны использовать менее безопасные протоколы и функции (downgrade attack).
Если и сервер, и клиент поддерживают устаревшие шифронаборы — информацию об этом легко получить, прослушивая соединение, — злоумышленник может изменить шифрование, выбранное сервером, на более слабое. Такие атаки не опасны сами по себе, но открывают дверь для использования других известных эксплойтов тех шифронаборов, на которые был изменён выбранный изначально.
Рукопожатие TLS 1.3 использует цифровую подпись на ранних стадиях соединения, что делает его более безопасным и защищает от атак, меняющих шифронабор. Подпись также позволяет быстрее и эффективнее аутентифицировать сервер.
Теперь посмотрим, как эти обновления для рукопожатия TLS 1.3 будут реализованы во всех трёх основных функциях самого рукопожатия SSL/TLS.
Шифронаборы TLS-рукопожатия
Шифронабор — это набор алгоритмов, определяющих параметры безопасного соединения.
В начале любого соединения самое первое взаимодействие, «Client Hello», представляет собой список поддерживаемых шифронаборов.
Сервер выбирает лучший, наиболее безопасный вариант, который поддерживается им и отвечает его требованиям. Вы можете посмотреть на шифронабор и выяснить все параметры рукопожатия и соединения.
Шифронаборы TLS 1.2
- TLS — протокол.
- ECDHE — алгоритм обмена ключами.
- ECDSA — алгоритм аутентификации.
- AES 128 GCM — алгоритм симметричного шифрования.
- SHA256 — алгоритм хеширования.
В приведённом выше примере используется эфемерная система Диффи-Хеллмана (DH) с эллиптической кривой для обмена ключами и алгоритм цифровой подписи эллиптической кривой для аутентификации. DH также может быть соединен с RSA (функционирующим как алгоритм цифровой подписи) для выполнения аутентификации.
Вот список наиболее широко поддерживаемых шифронаборов TLS 1.2: Шифронаборы
Шифронаборы TLS 1.3
- TLS — протокол.
- AES 256 GCM — алгоритм аутентифицированного шифрования с присоединёнными данными (AEAD).
- SHA384 — алгоритм функции формирования хешированного ключа (HKFD).
Мы уже знаем, что будем использовать какую-то версию обмена эфемерными ключами Диффи-Хеллмана, но не знаем параметров, так что первые два алгоритма в шифронаборе TLS 1.2 больше не нужны. Эти функции всё ещё выполняются, их просто больше не нужно согласовывать во время рукопожатия.
Из приведённого выше примера видно, что используется AES (Advanced Encryption Standard) для шифрования большого объёма данных. Он работает в режиме счётчика Галуа с использованием 256-битных ключей.
Вот пять шифронаборов, которые поддерживаются в TLS 1.3:
- TLS_AES_256_GCM_SHA384;
- TLS_CHACHA20_POLY1305_SHA256;
- TLS_AES_128_GCM_SHA256;
- TLS_AES_128_CCM_8_SHA256;
- TLS_AES_128_CCM_SHA256.
Что изменилось в TLS 1.3 по сравнению с TLS 1.2?
Важно помнить, что при создании версии 1.3 главным было повышение безопасности и производительности. Для этого в TLS 1.
3 был переработан алгоритм генерация ключей и исправлены известные уязвимости.
В рукопожатии TLS 1.3 также стали лучше некоторые процессы, например аутентификация сообщений и цифровые подписи.
Наконец, в дополнение к постепенному отказу от старых алгоритмов генерации ключей или обмена ими, TLS 1.3 устраняет старые симметричные шифры. В TLS 1.3 полностью исключили блочные шифры. Единственный разрешённый в TLS 1.3 тип симметричных шифров называется шифрованием с проверкой подлинности с использованием дополнительных данных (AEAD). Он объединяет шифрование и проверку подлинности сообщений (MAC) в одну функцию.
Аутентификация в TLS-рукопожатии
Исторически двумя основными вариантами обмена ключами являются RSA и Диффи-Хеллман (DH), в наши дни DH часто ассоциируется с эллиптическими кривыми (ECDH). Несмотря на некоторые основные сходства, между этими двумя подходами к обмену ключами есть фундаментальные различия.
Иными словами, TLS-рукопожатие RSA отличается от TLS-рукопожатия ECDH.
Краткая история RSA и DH/ECC
Аутентификация в рукопожатии TLS 1.2
Как было только что сказано, дополнительная функциональность RSA для аутентификации с помощью цифровых подписей требует больших ключей, устойчивых к атакам перебором. Размер этих ключей сильно увеличивает затраты на их вычисление, шифрование и дешифрование во время рукопожатия.
С другой стороны, если Диффи-Хеллман не выполняет аутентификацию, то что он делает? Как было сказано выше, DH часто используют совместно с криптографией на основе эллиптических кривых, чтобы обеспечить аутентификацию и обмен ключами.
Эллиптическая криптография (ECC) имеет гораздо меньшие размеры ключей, которые соответствуют эллиптической кривой, на которой они основаны. Для этого контекста есть пять подходящих кривых:
- 192 бит;
- 224 бита;
- 256 бит;
- 384 бит;
- 521 бит.
Но это не единственное различие между открытыми/закрытыми ключами ECC и ключами RSA. Они используются для двух совершенно разных целей во время рукопожатия TLS.
В RSA пара открытый/закрытый ключ используется как для проверки подлинности сервера, так и для обмена симметричным ключом сеанса. Фактически, именно успешное использование секретного ключа для расшифровки секрета (pre-master secret) аутентифицирует сервер.
С Диффи-Хеллманом пара открытый/закрытый ключ НЕ используется для обмена симметричным сеансовым ключом. Когда задействован Диффи-Хеллман, закрытый ключ фактически связан с прилагаемым алгоритмом подписи (ECDSA или RSA).
RSA-аутентификация
Процесс RSA-аутентификации связан с процессом обмена ключами. Точнее обмен ключами является частью процесса аутентификации.
Когда клиенту предоставляется SSL-сертификат сервера, он проверяет несколько показателей:
- цифровую подпись с использованием открытого ключа;
- цепочку сертификатов, чтобы убедиться, что сертификат происходит от одного из корневых сертификатов в хранилище доверенных сертификатов;
- срок действия, чтобы убедиться, что он не истёк;
- статус отзыва сертификата.
Если все эти проверки прошли, то проводится последний тест — клиент шифрует pre-master secret с помощью открытого ключа сервера и отправляет его. Любой сервер может попытаться выдать любой SSL/TLS-сертификат за свой. В конце концов, это общедоступные сертификаты. А так клиент может провести аутентификацию сервера, увидев закрытый ключ «в действии».
Таким образом, если сервер может расшифровать pre-master secret и использовать его для вычисления сессионного ключа, он получает доступ. Это подтверждает, что сервер является владельцем используемой пары из открытого и закрытого ключа.
DH-аутентификация
Когда используются Диффи-Хеллман и ECDSA/RSA, аутентификация и обмен ключами разворачиваются бок о бок. И это возвращает нас к ключам и вариантам их использования. Открытый/закрытый ключ RSA используется как для обмена ключами, так и для аутентификации. В DH + ECDSA/RSA асимметричная пара ключей используется только для этапа цифровой подписи или аутентификации.
Когда клиент получает сертификат, он всё ещё проводит стандартные проверки:
- проверяет подпись на сертификате,
- цепочку сертификатов,
- срок действия,
- статус отзыва.
Но владение закрытым ключом подтверждается по-другому. Во время обмена ключами TLS-рукопожатия (шаг 4) сервер использует свой закрытый ключ для шифрования случайного числа клиента и сервера, а также свой DH-параметр. Он действует как цифровая подпись сервера, и клиент может использовать связанный открытый ключ для проверки, что сервер является законным владельцем пары ключей.
Аутентификация в рукопожатии TLS 1.3
В TLS 1.3 аутентификация и цифровые подписи всё ещё играют важную роль, но они были исключены из шифронаборов для упрощения согласования. Они реализованы на стороне сервера и используют несколько алгоритмов, поддерживаемых сервером, из-за их безопасности и повсеместного распространения. В TLS 1.3 разрешены три основных алгоритма подписи:
- RSA (только подпись),
- алгоритм цифровой подписи эллиптической кривой (ECDSA),
- алгоритм цифровой подписи Эдвардса (EdDSA).
В отличие от рукопожатия TLS 1.2, аутентификационная часть рукопожатия TLS 1.3 не связана с самим обменом ключами. Скорее она обрабатывается параллельно с обменом ключами и аутентификацией сообщений.
Вместо запуска симметричной схемы MAC для проверки целостности рукопожатия, сервер подписывает весь хеш расшифровки, когда возвращает «Server Hello» со своей частью общего ключа.
Клиент получает всю информацию, передающуюся с «Server Hello», и выполняет стандартную серию проверок подлинности сертификата SSL/TLS. Она включает в себя проверку подписи на сертификате, а затем проверку на соответствие подписи, которая была добавлена в хеш расшифровки.
Совпадение подтверждает, что сервер владеет секретным ключом.
Обмен ключами в TLS-рукопожатии
Если выделить главную мысль этого раздела, она будет звучать так:
RSA облегчает обмен ключами, позволяя клиенту шифровать общий секрет и отправлять его на сервер, где он используется для вычисления соответствующего сеансового ключа. Обмен ключами DH на самом деле вообще не требует обмена открытым ключом, скорее обе стороны создают ключ вместе.
Если сейчас это звучит немного абстрактно, к концу этого раздела всё должно проясниться.
Обмен ключами RSA
Называть это обменом ключами RSA на самом деле неправильно. На самом деле это RSA-шифрование. RSA использует асимметричное шифрование для создания ключа сеанса. В отличие от DH, пара открытого/закрытого ключей играет большую роль.
Вот как это происходит:
- Клиент и сервер обмениваются двумя простыми числами (x и y), которые называют случайными числами.
- Клиент генерирует pre-master secret (a), а затем использует открытый ключ сервера для его шифрования и отправки на сервер.
- Сервер расшифровывает pre-master secret с помощью соответствующего закрытого ключа. Теперь обе стороны имеют все три входных переменных и смешивают их с некоторыми псевдослучайными функциями (PRF) для создания мастер-ключа.
- Обе стороны смешивают мастер-ключ с ещё большим количеством PRF и получают совпадающие сеансовые ключи.
Обмен ключами DH
Вот как работает ECDH:
- Клиент и сервер обмениваются двумя простыми числами (x и y), которые называют случайными числами.
- Одна сторона выбирает секретный номер, называемый pre-master secret (a), и вычисляет: xa mod y. Затем отправляет результат (A) другому участнику.
- Другая сторона делает то же самое, выбирая свой собственный pre-master secret (b) и вычисляет xb mod y, а затем отправляет обратно своё значение (B).
- Обе стороны заканчивают эту часть, принимая заданные значения и повторяя операцию. Один вычисляет ba mod y, другой вычисляет ab mod y.
Существует свойство показателей по модулю, которое говорит, что каждая сторона получит одно и то же значение, которое будет ключом, используемым для симметричного шифрования во время соединения.
Рукопожатие TLS 1.2 для DH
Теперь, когда мы узнали, чем DH отличается от RSA, посмотрим, как выглядит рукопожатие TLS 1.2 на основе DH.
Опять же, между этими двумя подходами существует множество сходств. Мы будем использовать ECDHE для обмена ключами и ECDSA для аутентификации.
- Как и в случае с RSA, клиент начинает с сообщения «Client Hello», которое включает в себя список шифронаборов, а также случайное число клиента.
- Сервер отвечает своим сообщением «Server Hello», которое включает в себя выбранный шифронабор и случайное число сервера.
- Сервер отправляет свой SSL-сертификат. Как и при TLS-рукопожатии RSA клиент выполнит серию проверок подлинности сертификата, но, поскольку сам DH не может аутентифицировать сервер, необходим дополнительный механизм.
- Чтобы провести аутентификацию, сервер берёт случайные числа клиента и сервера, а также параметр DH, который будет использоваться для вычисления сеансового ключа, и шифрует их с помощью своего закрытого ключа. Результат будет выполнять роль цифровой подписи: клиент использует открытый ключ для проверки подписи и того, что сервер является законным владельцем пары ключей, и ответит своим собственным параметром DH.
- Сервер завершает эту фазу сообщением «Server Hello Done».
- В отличие от RSA, клиенту не нужно отправлять pre-master secret на сервер с использованием асимметричного шифрования, вместо этого клиент и сервер используют параметры DH, которыми они обменялись ранее, чтобы получить pre-master secret. Затем каждый использует pre-master secret, который он только что рассчитал, для получения одинакового сеансового ключа.
- Клиент отправляет сообщение «Change Cipher Spec», чтобы сообщить другой стороне о своём переходе на шифрование.
- Клиент отправляет финальное сообщение «Finished», чтобы сообщить, что он завершил свою часть рукопожатия.
- Аналогично, сервер отправляет сообщение «Change Cipher Spec».
- Рукопожатие завершается сообщением «Finished» от сервера.
Преимущества DHE перед RSA
Существует две основные причины, по которым сообщество криптографов предпочитает использовать DHE, а не RSA: совершенная прямая секретность и известные уязвимости.
Совершенная прямая секретность
Ранее вы, возможно, задавались вопросом, что означает слово «эфемерный» в конце DHE и ECDHE. Эфемерный буквально означает «недолговечный». И это может помочь понять совершенную прямую секретность (Perfect Forward Secrecy, PFS), которая является особенностью некоторых протоколов обмена ключами. PFS гарантирует, что сессионные ключи, которыми обмениваются стороны, не могут быть скомпрометированы, даже если скомпрометирован закрытый ключ сертификата. Другими словами, он защищает предыдущие сессии от извлечения и дешифрования. PFS получила высший приоритет после обнаружения ошибки Heartbleed. Это основной компонент TLS 1.3.
Уязвимость обмена ключами RSA
Существуют уязвимости, которые могут использовать заполнение (padding), используемое во время обмена ключами в старых версиях RSA (PKCS #1 1.5). Это один из аспектов шифрования. С RSA pre-master secret должен быть зашифрован открытым ключом и расшифрован закрытым ключом. Но когда этот меньший по длине pre-master secret помещается в больший открытый ключ, он должен быть дополнен. В большинстве случаев попытавшись угадать заполнение и отправив поддельный запрос на сервер, вы ошибётесь, и он распознает несоответствие и отфильтрует его. Но есть немалая вероятность, что вы сможете отправить на сервер достаточное количество запросов, чтобы угадать правильное заполнение. Тогда сервер отправит ошибочное законченное сообщение, что, в свою очередь, сузит возможное значение pre-master secret. Это позволит злоумышленнику рассчитать и скомпрометировать ключ.
Вот почему RSA был удалён в пользу DHE в TLS 1.3.
Обмен ключами в рукопожатии TLS 1.3
В рукопожатии TLS 1.3 из-за ограниченного выбора схем обмена ключами клиент может успешно угадать схему и отправить свою часть общего ключа во время начального этапа (Client Hello) рукопожатия.
RSA была не единственной схемой обмена ключами, которая была удалена в TLS 1.3. Неэфемерные схемы Диффи-Хеллмана тоже были ликвидированы, как и перечень недостаточно безопасных параметров Диффи-Хеллмана.
Что имеется в виду под недостаточно безопасными параметрами? Не углубляясь в математику, сложность Диффи-Хеллмана и большинства криптосистем с открытым ключом — это сложность решения задач дискретного логарифма. Криптосистема должна быть достаточно сложной для вычисления, если неизвестны входные параметры (случайные числа клиента и сервера), иначе вся схема окажется бесполезной. Схемы Диффи-Хеллмана, которые не могли обеспечить достаточно большие параметры, были исключены в TLS 1.3.
- В начале рукопожатия TLS 1.3, зная, что будет использоваться DHE-схема соглашения о ключах, клиент включает свою часть общего ключа на основе предполагаемой схемы обмена ключами в своё сообщение «Client Hello».
- Сервер получает эту информацию и, если клиент угадал, возвращает свою часть общего ключа в «Server Hello».
- Клиент и сервер вычисляют сеансовый ключ.
Это очень похоже на то, что происходит с DH в рукопожатии TLS 1.2, кроме того, что в TLS 1.3 обмен ключами происходит раньше.
Вместо заключения
SSL/TLS-рукопожатие — это увлекательный процесс, который имеет ключевое значение для безопасного интернета, и всё же он происходит так быстро и незаметно, что большинство людей даже никогда не задумывается об этом.
По крайней мере, пока что-то не пойдёт не так, как нужно.
Почему обмен ключами нужно вообще?
Есть много шагов, необходимых для понимания причин и я постараюсь, чтобы направлять вас через каждый.
1) правильно использовать шифрование…
с алгоритмом RSA, Алиса и Боб могут просто обменяться открытыми ключами (public_a, public_b) и держать их закрытыми ключами (private_a, private_b). Алиса может просто послать Бобу сообщения, которые зашифрованы по private_a, и Боб может расшифровать его по public_a. Они еще могут общаться в незащищенной сети, без ключа Диффи–Хелмана В обмен на все.
Это в корне неверные. Что вы делаете в этой части подписи, а не шифрования. Поскольку public_key_a является общедоступным, ваши сообщения не будут зашифрованы все. Вместо этого, нужно, быть шифрования сообщений с public_key_b и тогда б может расшифровать их с private_key_b. Поскольку private_key_b знаю только б, знает, что только б его можно было расшифровать.
Цифровая подпись доказывает, что приходят сообщения от конкретного человека. Шифрование доказывает, что только вы, держатель ключа, и человек, что зашифрованные сообщения, отправитель сообщения, знаю сообщении. Вы должны иметь шифрования и подписи при использовании асимметричного шифрования. Шифрование для обеспечения конфиденциальности сообщений и подписи, чтобы доказать, что ты тот, кто послал это сообщение.
Но, есть еще что-то… например, по-прежнему необходимо для защиты от атак воспроизведения.
2) Боб, как правило, не’т иметь публичный ключ
Позвольте’ы сказать, что Алис (а) это сервер и Боб (Б) клиента. Как правило, клиент не’т иметь открытый ключ. Например, знаете ли вы публичный ключ? Ответ, скорее всего, нет. Таким образом, Вася может получить сообщение от Алиса и убедитесь, что они действительно пришло от Алисы, но Алиса не может быть уверен, что получает действительно от Боба пришло от Боба.
Эта проблема является одной из первопричин, почему мы добавили протокол обмена ключами вроде Диффи-Хеллмана.
3) ОГА только один блок.
Существует метод, используемый, чтобы зашифровать длинное сообщение, которое называется сцепления блоков шифра. К сожалению, этот метод не может быть использован с РСА. Это’s не то, что он’s совершенно невозможно, а то, что никто не знает, если это’ы очень безопасно, если мы делаем это. Следовательно, он ограничивает шифрования RSA в один блок. С другой стороны, симметричные алгоритмы шифрования, такой как AES работает как шарм с блоком сцепления и почему мы их используем.
Для дальнейшего чтения : https://crypto.stackexchange.com/a/126/16369
4) Диффи-Хеллман-это протокол обмена ключами
Диффи-Хеллмана-это просто способ, чтобы «создавать и обмениваться» а ключ, который затем может быть использован для симметричного шифрования. В сила Диффи-Хеллмана заключается в том, что все беседы, чтобы создать этот ключ может произойти в обычный текст и ключ остались бы наедине.
Примечание : Диффи-Хелмана не’т решить проблему MITM атак, поскольку он не может проверить подлинность участники общаются друг с другом. Эта проблема вместо того, чтобы решить с цифровая подпись.
5) эфемерный открытый ключ Диффи-Хеллмана обеспечивает совершенную прямую секретность
Эфемерный открытый ключ Диффи-Хеллмана-это просто красивое название, чтобы сказать, что вы создаете новый ключ Диффи-Хеллмана-пара каждой сессии и вы не’т сохранить их. Поскольку вы никогда не сохранить их, злоумышленник не сможет извлечь их.
Смотреть на это очень хороший ответ для более подробной информации : https://security.stackexchange.com/a/38142/50051
6) эфемерный открытый ключ Диффи-Хеллмана защищает от атаки воспроизведения
Очень хороший побочный эффект использования эфемерный открытый ключ Диффи-Хеллмана заключается в том, что он также защищает от атаки воспроизведения. Поскольку сервер и клиент выбирает новый случайный закрытый ключ Диффи-Хелмана каждой сессии, вы не можете повторить сообщение из другой сессии, чтобы выдать себя за сервер или клиент.
Вывод
Это очень краткий обзор того, как TLS работает и все эти части обязаны обеспечить безопасное соединение. Без симметричного шифрования вы не можете зашифровать длинное сообщение и без асимметричного шифрования вы не сможете использовать ключ шифрования и обеспечивает совершенную прямую секретность.
Что такое обмен ключами Диффи-Хеллмана и как он работает?
Обмен ключами Диффи-Хеллмана был одна из самых важных разработок в криптографии с открытым ключом и он до сих пор часто применяется в ряде современных протоколов безопасности.
Это позволяет двум сторонам, которые ранее не встречались, безопасно установить ключ, который они могут использовать для защиты своих сообщений. В этой статье мы объясним, для чего он используется, как он работает поэтапно, его различные варианты, а также соображения безопасности, которые необходимо учитывать для безопасной реализации..
Что такое обмен ключами Диффи-Хеллмана?Обмен ключами Диффи-Хеллмана был первый широко используемый метод безопасной разработки и обмена ключами по небезопасному каналу.
В приведенных выше терминах это может показаться не таким захватывающим или новаторским, поэтому давайте приведем пример, который объясняет, почему обмен ключами Диффи-Хеллмана был такой важной вехой в мире криптографии, и почему он до сих пор так часто используется сегодня.
Допустим, вы совершенно секретный шпион, и вам нужно отправить важную информацию в вашу штаб-квартиру. Как бы вы помешали своим врагам овладеть посланием??
Наиболее распространенным решением было бы зашифровать сообщение с помощью кода. Самый простой способ — заранее подготовить код и ключ, которые вы планируете использовать заранее, или сделать это по безопасному каналу связи..
Допустим, вы особенно плохой шпион, и вы и ваша штаб-квартира решили использовать слабый шифр для шифрования ваших сообщений. В этом коде каждое «a» становится «b», каждое «b» становится «c», каждое «c» становится «d» и так далее, вплоть до «z», становящегося «a».
Под этим шифром смены сообщение «Давай поужинаем» становится «Mfu’t hfu ejoofs». К счастью, в нашей гипотетической ситуации ваши противники так же некомпетентны, как и вы, и не могут взломать такой простой код, который не позволяет им получить доступ к содержанию сообщения..
Но что произойдет, если вы не смогли заранее согласовать код с получателем?
Допустим, вы хотите общаться с шпионом из союзной нации, которого вы никогда не встречали раньше. У вас нет безопасного канала для общения с ними. Если вы не зашифруете свое сообщение, то любой злоумышленник, который его перехватит, сможет прочитать содержимое. Если вы зашифруете его, не сообщив союзнику код, тогда враг не сможет прочитать его, но и союзник не сможет.
Эта проблема была одной из самых больших загадок в криптографии до 1970-х годов:
Как вы можете безопасно обмениваться информацией с кем-то, если у вас не было возможности поделиться ключом заранее?
Обмен ключами Диффи-Хеллмана был первым публично используемым механизмом решения этой проблемы. Алгоритм позволяет тем, кто никогда ранее не встречался, безопасно создавать общий ключ, даже по небезопасному каналу, который могут отслеживать противники..
История обмена ключами Диффи-ХеллманаОбмен ключами Диффи-Хеллмана уходит корнями в 1970-е годы. Хотя область криптографии значительно развивалась в начале двадцатого века, эти достижения были в основном сосредоточены в области криптографии с симметричным ключом..
Лишь в 1976 году в публичной сфере появились алгоритмы с открытым ключом, когда Уитфилд Диффи и Мартин Хеллман опубликовали свою статью., Новые направления в криптографии. В рамках сотрудничества были определены механизмы, лежащие в основе новой системы, которая станет известна как Обмен ключами Диффи-Хеллмана.
Работа была частично вдохновлена более ранними событиями, сделанными Ральфом Мерклом. Так называемой Пазлы Меркля привлекать одну сторону, создавая и отправляя множество криптографических головоломок другой. Эти головоломки потребуют умеренного количества вычислительных ресурсов для решения.
Получатель будет случайным образом выбирать одну головоломку для решения и затем затрачивать необходимые усилия для ее завершения.. После того, как загадка решена, получателю передаются идентификатор и ключ сеанса. Затем получатель передает идентификатор обратно исходному отправителю, что позволяет отправителю узнать, какая головоломка была решена.
Поскольку исходный отправитель создал головоломки, идентификатор сообщает им, какой сеансовый ключ обнаружил получатель, и обе стороны могут использовать этот ключ для более безопасной связи. Если злоумышленник прослушивает взаимодействие, он получит доступ ко всем головоломкам, а также к идентификатору, который получатель передает обратно исходному отправителю..
Идентификатор не сообщает злоумышленнику, какой ключ сеанса используется, поэтому лучший способ расшифровки информации — это решить все головоломки, чтобы найти правильный ключ сессии. Так как злоумышленнику в среднем придется решить половину головоломок, ему будет гораздо сложнее раскрыть ключ, чем получателю..
Такой подход обеспечивает большую безопасность, но это далеко не идеальное решение. Обмен ключами Диффи-Хеллмана взял некоторые из этих идей и сделал их более сложными, чтобы создать безопасный метод криптографии с открытым ключом.
Хотя он стал известен как обмен ключами Диффи-Хеллмана, Мартин Хеллман предложил вместо этого назвать алгоритм обмена ключами Диффи-Хеллмана-Меркля, чтобы отразить работу, которую Ральф Меркл проделал в области криптографии с открытым ключом..
Публично считалось, что Меркл, Хеллман и Диффи были первыми, кто разработал криптографию с открытым ключом до 1997 года, когда британское правительство рассекретило работу, проделанную в начале 1970-х годов Джеймс Эллис, Клиффорд Кокс и Малкольм Уильямсон.
Оказывается, трио разработало первую схему шифрования с открытым ключом между 1969 и 1973 годами, но их работа была засекречена на два десятилетия. Он проводился в правительственном штабе связи (GCHQ), разведывательном агентстве Великобритании.
Их открытие было фактически алгоритмом RSA, поэтому Диффи, Хеллман и Меркл все еще были первыми, кто разработал обмен ключами Диффи-Хеллмана, но уже не были первыми изобретателями криптографии с открытым ключом..
Где используется обмен ключами Диффи-Хеллмана?Основной целью обмена ключами Диффи-Хеллмана является надежно разрабатывать общие секреты, которые можно использовать для получения ключей. Эти ключи могут затем использоваться с алгоритмами симметричного ключа для передачи информации защищенным способом.. Симметричные алгоритмы обычно используются для шифрования большей части данных, поскольку они более эффективны, чем алгоритмы с открытым ключом..
Технически обмен ключами Диффи-Хеллмана может использоваться для установления открытых и закрытых ключей. Однако на практике вместо этого обычно используется RSA. Это связано с тем, что алгоритм RSA также способен подписывать сертификаты открытых ключей, в то время как обмен ключами Диффи-Хеллмана не.
Алгоритм Эль-Гамаля, который активно использовался в PGP, основан на обмене ключами Диффи-Хеллмана, поэтому любой протокол, который его использует, эффективно реализует своего рода Диффи-Хеллмана..
Одним из наиболее распространенных методов безопасного распределения ключей является обмен ключами Диффи-Хеллмана. часто применяется в протоколах безопасности, таких как TLS, IPsec, SSH, PGP и многих других. Это делает его неотъемлемой частью нашей безопасной связи.
В рамках этих протоколов обмен ключами Диффи-Хеллмана часто используется для обеспечения безопасности вашего соединения с веб-сайтом, для удаленного доступа к другому компьютеру и для отправки зашифрованных электронных писем.
Как работает обмен ключами Диффи-Хеллмана?Обмен ключами Диффи-Хеллмана сложен, и может быть сложно понять, как он работает. Он использует очень большие числа и много математики, то, что многие из нас до сих пор боятся тех долгих и скучных уроков в средней школе.
Чтобы сделать вещи немного проще для понимания, мы начнем с объяснения обмена ключами Диффи-Хеллмана с аналогией. Как только у вас появится общее представление о том, как это работает, мы перейдем к более техническому описанию основных процессов..
Лучшая аналогия для схемы Диффи-Хеллмана — думать о два человека смешивают краску. Давайте использовать стандарт криптографии и скажем, что их зовут Алиса и Боб. Они оба договариваются о случайном цвете, чтобы начать с. Допустим, они отправляют друг другу сообщение и выбрать желтый как их общий цвет, как на схеме ниже:
Сам по себе свой секретный цвет. Они не говорят другой стороне свой выбор. Допустим, Алиса выбирает красный, в то время как Боб выбирает слегка зеленовато-синий.
Следующий шаг для Алисы и Боба — смешать их секретный цвет (красный для Алисы, зеленовато-синий для Боба) с желтым, с которым они взаимно согласились. Согласно диаграмме, Алиса заканчивается Оранжевая смесь, в то время как результат Боба глубокий синий.
Как только они закончили смешивание, они отправляют результат другой стороне.. Алиса получает более глубокий синий, пока Бобу посылают оранжевую краску.
Как только они получили смешанный результат от своего партнера, они затем добавляют свой секретный цвет к нему. Алиса берет более глубокий синий цвет и добавляет свою секретную красную краску, пока Боб добавляет свой секретный зеленовато-синий к апельсиновой смеси, которую он только что получил.
Результат? Они оба выходят с одинаковым цветом, который в этом случае отвратительный коричневый. Это может быть не тот цвет, которым вы хотели бы покрасить свою гостиную, но, тем не менее, это общий цвет. Этот общий цвет называется общий секрет.
Важнейшей частью обмена ключами Диффи-Хеллмана является то, что обе стороны получают один и тот же результат без необходимости передавать весь общий секрет по каналу связи.. Выбор общего цвета, их собственных секретных цветов, обмен миксом, а затем добавление их собственного цвета еще раз, дает обеим сторонам возможность прийти к одному и тому же общему секрету, не прибегая к передаче всей информации..
Если злоумышленник слушает обмен, все, что он может получить, это общий желтый цвет, с которого начинаются Алиса и Боб, а также смешанные цвета, которыми обмениваются. Поскольку это действительно сделано с огромными числами вместо краски, этих кусочков информации недостаточно, чтобы атака могла различить либо исходные секретные цвета, либо общий секрет (технически возможно вычислить общий секрет из этой информации, но в безопасной реализации обмена ключами Диффи-Хеллмана для этого потребуется неоправданное количество времени и вычислительных ресурсов).
Эта структура обмена ключами Диффи-Хеллмана делает его таким полезным. Это позволяет обеим сторонам общаться по потенциально опасному соединению и при этом придумывать общий секрет, который они могут использовать для создания ключей шифрования для своих будущих коммуникаций.. Не имеет значения, прослушивают ли какие-либо злоумышленники, потому что общий секретный секрет никогда не передается по соединению.
Технические детали обмена ключами Диффи-ХеллманаВремя для математики …
Не волнуйтесь, мы сделаем это медленно и постараемся сделать весь процесс как можно более понятным. Это следует той же предпосылке, что и аналогия, показанная выше, но вместо смешивания и отправки цветов, схема Диффи-Хеллмана на самом деле делает вычисления на основе исключительно больших простых чисел, а затем отправляет их через.
Для обеспечения безопасности рекомендуется, чтобы премьер (п) длиной не менее 2048 бит, который является двоичным эквивалентом десятичного числа примерно такого размера:
415368757628736598425938247569843765827634879128375827365928736 84273684728938572983759283475934875938475928475928739587249587 29873958729835792875982795837529876348273685729843579348795827 93857928739548772397592837592478593867045986792384737826735267 3547623568734869386945673456827659498063849024875809603947902 7945982730187439759284620950293759287049502938058920983945872 0948602984912837502948019371092480193581037995810937501938507913 95710937597019385089103951073058710393701934701938091803984091804 98109380198501398401983509183501983091079180395810395190395180935 8109385019840193580193840198340918093851098309180019
Чтобы никто не взорвал голову, мы объясним это объяснение гораздо меньшими цифрами. Быть в курсе, что обмен ключами Диффи-Хеллмана был бы небезопасным, если бы он использовал такие же маленькие числа, как в нашем примере. Мы используем только такие небольшие числа, чтобы продемонстрировать концепцию более простым способом..
В самой основной форме обмена ключами Диффи-Хеллмана, Алиса и Боб начинают с взаимного выбора двух чисел, чтобы начать с, в отличие от единой общей краски в примере выше. Эти модуль (п) и база (грамм).
В практическом использовании, модуль (р) является очень большим простым числом, пока база (грамм) является относительно небольшим для упрощения расчетов. База (грамм) является производным от циклической группы (грамм) обычно генерируется задолго до того, как будут выполнены другие шаги.
Для нашего примера, скажем, что модуль (п) является 17, пока база (грамм) является 4.
После того, как они взаимно определились с этими числами, Алиса выбирает секретный номер () для себя, а Боб выбирает свой секретный номер (б). Допустим, они выбирают:
а = 3
б = 6
Затем Алиса выполняет следующие вычисления, чтобы дать ей номер, который она отправит Бобу:
A = ga mod p
В приведенном выше расчете, модификация означает операцию по модулю. По сути, это расчеты, чтобы выяснить остаток после деления левой части на правую. В качестве примера:
15 мод 4 = 3
Если вы понимаете, как работают операции по модулю, вы можете выполнить их самостоятельно в следующих расчетах, в противном случае вы можете использовать онлайн-калькулятор..
Итак, давайте введем наши числа в формулу:
А = 43 мод 17
A = 64 мод 17
А = 13
Когда мы делаем то же самое для Боба, мы получаем:
B = 46 мод 17
B = 4096 мод 17
B = 16
Алиса затем отправляет свой результат () Бобу, пока Боб отправляет свою фигуру (ВАлисе. Алиса затем вычисляет общий секрет (s) используя номер, который она получила от Боба (В) и ее секретный номер (), используя следующую формулу:
s = Ба мод п
s = 163 мод 17
s = 4096 мод 17
s = 16
Затем Боб выполняет то же самое, что и вычисление, но с номером, который ему прислала Алиса.), а также его собственный секретный номер (б):
s знак равно б модификация п
s = 136 мод 17
s = 4,826,809 мод 17
с = 16
Как видите, обе стороны получили одинаковый результат для s, 16. Это общий секрет, который знают только Алиса и Боб. Затем они могут использовать это, чтобы установить ключ для симметричного шифрования, позволяя им безопасно передавать информацию между собой таким образом, чтобы только они могли получить к ней доступ.
Обратите внимание, что хотя В и s одинаковы в приведенном выше примере, это просто совпадение, основанное на небольших числах, которые были выбраны для этой иллюстрации. Обычно эти значения не будут одинаковыми в реальной реализации обмена ключами Диффи-Хеллмана.
Несмотря на то, что большая часть вышеуказанных данных передается по каналу в открытом виде (р, г, А и Ви могут быть прочитаны потенциальными злоумышленниками, общий секрет (s) никогда не передается. Для злоумышленника было бы непрактично вычислять общий секрет (s) или любой из секретных номеров ( и б) из информации, которая отправляется в открытом тексте.
Конечно, это предполагает, что обмен ключами Диффи-Хеллмана реализован правильно и используются достаточно большие числа. Пока эти положения соблюдаются, обмен ключами Диффи-Хеллмана считается безопасным способом установления общего секрета, который можно использовать для обеспечения безопасности будущих сообщений..
Создание общего ключа между несколькими сторонамиОбмен ключами Диффи-Хеллмана также можно использовать для настройки общего ключа с большим числом участников. Он работает таким же образом, за исключением того, что дальнейшие раунды расчетов необходимы для каждой стороны, чтобы добавить свой секретный номер и в конечном итоге с тем же общим секретом.
Как и в двусторонней версии обмена ключами Диффи-Хеллмана, некоторые части информации передаются по незащищенным каналам, но недостаточно для того, чтобы злоумышленник смог вычислить общий секрет.
Почему обмен ключами Диффи-Хеллмана безопасен?На математическом уровне обмен ключами Диффи-Хеллмана опирается на односторонние функции в качестве основы своей безопасности. Это вычисления, которые просто сделать одним способом, но гораздо сложнее вычислить в обратном порядке..
В частности, он опирается на проблему Диффи-Хеллмана, которая предполагает, что при правильных параметрах невозможно рассчитать граммаб из отдельных значений грамм, грамм и граммб. В настоящее время нет общеизвестного способа легко найти граммаб из других значений, поэтому обмен ключами Диффи-Хеллмана считается безопасным, несмотря на то, что злоумышленники могут перехватить значения п, грамм, , и В.
Аутентификация & обмен ключами Диффи-ХеллманаВ реальном мире обмен ключами Диффи-Хеллмана редко используется сам по себе. Основная причина этого заключается в том, что он не обеспечивает аутентификацию, что делает пользователей уязвимыми для атак «человек посередине».
Эти атаки могут иметь место, когда обмен ключами Диффи-Хеллмана осуществляется сам по себе, поскольку у него нет возможности проверить, действительно ли другая сторона в соединении является тем, кем они себя называют. Без какой-либо формы аутентификации, пользователи могут фактически соединяться с злоумышленниками когда они думают, что общаются с доверенной стороной.
По этой причине обмен ключами Диффи-Хеллмана обычно реализуется наряду с некоторыми средствами аутентификации. Это часто включает в себя использование цифровых сертификатов и алгоритма открытого ключа, такого как RSA, для проверки личности каждой стороны.
Вариации обмена ключами Диффи-ХеллманаОбмен ключами Диффи-Хеллмана может быть реализован несколькими различными способами, и он также послужил основой для нескольких других алгоритмов. Некоторые из этих реализаций обеспечивают авторизацию, в то время как другие имеют различные криптографические функции, такие как совершенная прямая секретность.
Эллиптическая кривая Диффи-ХеллманаЭллиптическая кривая Диффи-Хеллман использует преимущества алгебраической структуры эллиптических кривых, что позволяет его реализациям достигать аналогичного уровня безопасности с меньшим размером ключа. 224-битный ключ эллиптической кривой обеспечивает тот же уровень безопасности, что и 2048-битный ключ RSA. Это может сделать обмены более эффективными и снизить требования к хранилищу.
Помимо меньшей длины ключа и того факта, что он основан на свойствах эллиптических кривых, эллиптическая кривая Диффи-Хеллмана работает аналогично стандартному обмену ключами Диффи-Хеллмана.
TLSПротокол TLS, который используется для защиты большей части Интернета, может использовать обмен Диффи-Хеллмана тремя различными способами: анонимным, статическим и эфемерным. На практике должен быть реализован только эфемерный Диффи-Хеллман, потому что другие варианты имеют проблемы с безопасностью.
- Аноним Диффи-Хеллман — Эта версия обмена ключами Диффи-Хеллмана не использует никакой аутентификации, что делает ее уязвимой для атак «человек посередине». Это не должно быть использовано или реализовано.
- Статический Диффи-Хеллман — Статический Диффи-Хеллман использует сертификаты для аутентификации сервера. Он не аутентифицирует клиента по умолчанию и не обеспечивает прямую секретность.
- Эфемерный Диффи-Хеллман — Это считается наиболее безопасной реализацией, поскольку она обеспечивает идеальную секретность. Обычно он объединяется с алгоритмом, таким как DSA или RSA, для аутентификации одной или обеих сторон в соединении. Эфемерный Диффи-Хеллман использует разные пары ключей при каждом запуске протокола. Это обеспечивает полную секретность переадресации соединения, потому что даже если ключ будет взломан в будущем, его нельзя будет использовать для расшифровки всех прошлых сообщений..
ElGamal — это алгоритм с открытым ключом, построенный на основе обмена ключами Диффи-Хеллмана. Как и Диффи-Хеллман, он не содержит каких-либо положений для аутентификации сам по себе и, как правило, объединяется с другими механизмами для этой цели..
ElGamal в основном использовался в PGP, GNU Privacy Guard и других системах, потому что его основной конкурент, RSA, был запатентован. Срок действия патента RSA истек в 2000 году, что позволило его свободно применять после этой даты. С тех пор Эль-Гамаль не был реализован так часто.
STSПротокол «от станции к станции» (STS) также основан на обмене ключами Диффи-Хеллмана. Это еще одна ключевая схема соглашения, однако она обеспечивает защиту от атак «человек посередине», а также совершенную секретность для пересылки..
Это требует, чтобы обе стороны в соединении уже имели пару ключей, которая используется для аутентификации каждой стороны. Если стороны еще не известны друг другу, сертификаты могут быть использованы для проверки личности обеих сторон..
Обмен ключами Диффи-Хеллмана & RSAКак мы обсуждали ранее, обмен ключами Диффи-Хеллмана часто реализуется вместе с RSA или другими алгоритмами для обеспечения аутентификации соединения. Если вы знакомы с RSA, вам может быть интересно почему кто-то потрудится использовать обмен ключами Диффи-Хеллмана?, поскольку RSA позволяет сторонам, которые ранее никогда не встречались, безопасно общаться.
RSA позволяет своим пользователям шифровать сообщения открытым ключом своего корреспондента, чтобы их можно было расшифровать только с помощью соответствующего закрытого ключа. Однако на практике, RSA не используется для шифрования всей связи — это было бы слишком неэффективно.
Вместо этого RSA часто используется только как средство аутентификации обеих сторон. Это делает это с цифровые сертификаты каждой стороны, которые будут проверены центром сертификации доказать, что владелец сертификата действительно тот, кем они себя называют, и что открытый ключ сертификата действительно принадлежит им.
Для взаимной аутентификации, каждая сторона подпишет сообщение, используя свой закрытый ключ, а затем отправит его партнеру по коммуникации. Каждый получатель может затем проверить личность другой стороны, проверив подписанные сообщения по открытому ключу на цифровом сертификате партнера по связи (см. вышеупомянутую статью о RSA для более подробной информации о том, как это работает, особенно Подписание сообщений раздел).
Теперь, когда обе стороны прошли проверку подлинности, технически возможно продолжать использовать RSA для безопасной отправки зашифрованных сообщений между собой, однако это окажется слишком неэффективным..
Чтобы обойти эту неэффективность, многие протоколы безопасности используют такой алгоритм, как обмен ключами Диффи-Хеллмана, чтобы придумать общий секрет, который можно использовать для создания общего симметричного ключа. Этот симметричный ключ затем используется в алгоритме симметричного ключа, таком как AES, для шифрования данных что обе стороны намерены безопасно переслать между собой.
Это может показаться сложным и запутанным процессом, но в итоге он оказывается намного быстрее и менее требователен к ресурсам по сравнению с использованием алгоритма с открытым ключом для всего обмена. Это потому что шифрование с симметричным ключом на несколько порядков эффективнее шифрования с открытым ключом.
В дополнение к неэффективности, о которой мы только что говорили, есть и другие недостатки, которые могут возникнуть только благодаря использованию RSA.. RSA нуждается в заполнении, чтобы сделать его безопасным, таким образом, дополнительный алгоритм должен быть реализован соответствующим образом вместе с ним, чтобы сделать его безопасным.
RSA не обеспечивает идеальной секретности форварда, либо, что является еще одним недостатком по сравнению с эфемерным обменом ключами Диффи-Хеллмана. В совокупности эти причины являются причиной того, что во многих ситуациях лучше применять RSA только в сочетании с обменом ключами Диффи-Хеллмана..
Альтернативно, обмен ключами Диффи-Хеллмана может быть объединен с алгоритмом, таким как Стандарт цифровой подписи (DSS), для обеспечения аутентификации, обмена ключами, конфиденциальности и проверки целостности данных. В такой ситуации RSA не требуется для защиты соединения.
Вопросы безопасности обмена ключами Диффи-ХеллманаБезопасность обмена ключами Диффи-Хеллмана зависит от того, как он реализован, а также от выбранных для него чисел. Как мы указали выше, у него нет средств для аутентификации другой стороны, но на практике используются другие механизмы, чтобы гарантировать, что другая сторона в соединении не является самозванцем.
Параметры для выбора номераЕсли бы в реальной реализации обмена ключами Диффи-Хеллмана использовались такие же малые числа, как в нашем примере, это сделало бы процесс обмена тривиальным для взломщика. Но важен не только размер чисел — числа также должны быть достаточно случайными. Если генератор случайных чисел производит предсказуемый результат, он может полностью подорвать безопасность обмена ключами Диффи-Хеллмана.
Число п должен быть длиной 2048 бит обеспечить безопасность. База, грамм, может быть относительно небольшим числом, как 2, но это должно исходить из порядка грамм это имеет большой главный фактор
Атака LogjamОбмен ключами Диффи-Хеллмана был разработан на основе проблемы дискретного логарифма, которую трудно решить. Наиболее эффективным общеизвестным механизмом поиска решения является алгоритм сита числового поля.
Возможности этого алгоритма были приняты во внимание при разработке обмена ключами Диффи-Хеллмана. К 1992 году стало известно, что для данной группы, грамм, три из четырех шагов алгоритма потенциально могут быть вычислены заранее. Если этот прогресс был сохранен, последний шаг может быть рассчитан за сравнительно короткое время.
Это не слишком беспокоило, пока не стало понятно, что значительная часть интернет-трафика использует те же группы, которые имеют размер 1024 бита или меньше. В 2015 году академическая группа провела расчеты для наиболее распространенного 512-разрядного простого числа, используемого при обмене ключами Диффи-Хеллмана в TLS..
Они также смогли понизить рейтинг 80% TLS-серверов, поддерживающих DHE-EXPORT, чтобы принять 512-битный обмен ключами Диффи-Хеллмана экспортного уровня для соединения. Это означает, что каждый из этих серверов уязвим для атаки со стороны хорошо обеспеченного противника.
Исследователи продолжили экстраполировать свои результаты, оценивая, что национальное государство может сломать 1024-битное простое число. Сломав единственное наиболее часто используемое 1024-битное простое число, академическая команда подсчитала, что злоумышленник может отслеживать 18% из миллиона самых популярных веб-сайтов HTTPS..
Далее они сказали, что второе простое число позволит злоумышленнику расшифровать соединения 66% серверов VPN и 26% серверов SSH. Позже в отчете ученые предположили, что АНБ может уже иметь эти возможности.
«Внимательное прочтение опубликованных сведений об утечках АНБ показывает, что атаки агентства на VPN соответствуют достижению такого перерыва».
Несмотря на эту уязвимость, обмен ключами Диффи-Хеллмана все еще может быть безопасным, если он реализован правильно. Пока используется 2048-битный ключ, атака Logjam не будет работать. Обновленные браузеры также защищены от этой атаки.
Безопасен ли обмен ключами Диффи-Хеллмана??Хотя обмен ключами Диффи-Хеллмана может показаться сложным, он является фундаментальной частью безопасного обмена данными в Интернете. Пока он реализован вместе с соответствующим методом аутентификации и числа были выбраны правильно, он не считается уязвимым для атаки.
Обмен ключами Диффи-Хеллмана был инновационным методом, помогающим двум неизвестным сторонам безопасно общаться, когда он был разработан в 1970-х годах. В то время как мы сейчас внедряем новые версии с большими ключами для защиты от современных технологий сам протокол выглядит так, как будто он будет оставаться безопасным до появления квантовых вычислений и продвинутые атаки, которые придут с ним.
Кибербезопасность бизнес-технологии от TheDigitalArtist по лицензии СС0
Sorry! The Author has not filled his profile.
Обновления метода обмена ключами(KEX) и рекомендации для Secure Shell (SSH) Обновления метода обмена ключами
(KEX) и рекомендации для Secure Shell (SSH)| Интернет-проект | Обновления метода KEX / Рекомендации для S | Ноябрь 2020 |
| Баушке | Срок действия истекает 27 мая 2021 г. | [Страница] |
Этот документ предназначен для обновления рекомендованного набора ключей. методы обмена для использования в протоколе Secure Shell (SSH), чтобы удовлетворить растущие потребности в усилении безопасности.Этот документ обновляет RFC 4250.¶
Данный Интернет-проект представлен в полном соответствии с положения BCP 78 и BCP 79.¶
Интернет-проекты являются рабочими документами Инженерного задания Интернет. Force (IETF). Обратите внимание, что другие группы также могут распространять рабочие документы как Интернет-проекты. Список текущих Интернет-проектов: на https://datatracker.ietf.org/drafts/current/.¶
Интернет-проекты — это проекты документов, срок действия которых составляет не более шести месяцев. и могут быть обновлены, заменены или отменены другими документами в любое время время.Неуместно использовать Интернет-черновики в качестве справочника. материала или цитировать их иначе, как «незавершенное производство». ¶
Срок действия этого Интернет-проекта истекает 27 мая 2021 года.
Авторские права (c) 2020 IETF Trust и лица, указанные в качестве авторы документа. Все права защищены.
Этот документ подпадает под действие BCP 78 и Правового регулирования IETF Trust. Положения, касающиеся документов IETF (https: // попечитель.ietf.org/license-info) действует на дату публикация этого документа. Пожалуйста, просмотрите эти документы внимательно, поскольку они описывают ваши права и ограничения с с уважением к этому документу. Компоненты кода, извлеченные из этого документ должен включать упрощенный текст лицензии BSD, как описано в Раздел 4.e Правовых положений о трасте и предоставляется без гарантия, как описано в Упрощенной лицензии BSD.
Secure Shell (SSH) — распространенный протокол для безопасного общение в Интернете.В [RFC4253], Первоначально SSH определил два имени метода обмена ключами (KEX). это ДОЛЖНО быть реализовано. Со временем то, что когда-то считалось secure больше не считается безопасным. Цель этого RFC рекомендуется, чтобы некоторые опубликованные обмены ключами были устарел, а также рекомендовать некоторые, что ДОЛЖНЫ, и один это ДОЛЖНО быть принято. Этот документ обновляется [RFC4250] .¶
Обмен ключами состоит из двух компонентов: алгоритма хеширования и алгоритм открытого ключа.В следующих подразделах описывается, как для выбора каждого компонента.
1.1. Выбор подходящего алгоритма хеширования
Хэш SHA-1 не рекомендуется для много причин. Были атаки на SHA-1, которые показали, что в алгоритме есть слабые места. Следовательно, желательно отказаться от его использования до приступов посерьезнее ».
В настоящее время атаки на SHA-1 являются атаками с коллизией. которые полагаются на человеческую помощь, а не на атаку прообразов.Так, все еще можно разрешить обратную совместимость по времени использование SHA-1 во время обмена ключами SSH для перехода к более сильное хеширование. Однако любой такой обмен ключами должен быть указан последним в списке предпочтений.
Использование семейства хэшей SHA-2, найденных в [RFC6234] настоятельно рекомендуется использовать не хэш SHA-1.
Когда дело доходит до семейства SHA-2 безопасного хеширования функции, SHA2-224 имеет уровень безопасности 112 бит; SHA2-256 имеет 128 бит защиты; SHA2-384 имеет 192 бит прочности безопасности; а SHA2-512 имеет 256 бит сила безопасности.Поскольку такая же вычислительная мощность требуется для как SHA2-224, так и SHA2-256, и в настоящее время KeX не использует SHA2-224, рекомендуется, чтобы минимальное безопасное хеширование функция, которую следует использовать для методов обмена ключами, SHA2-256.¶
Чтобы избежать комбинаторного взрыва имен обмена ключами, новые обмены ключами ограничивают использование * -sha256 и * -sha512.¶
1.2. Выбор подходящего алгоритма открытого ключа
SSH использует математически сложные задачи для выполнения ключа Обмен: ¶
- Криптография эллиптических кривых (ECC) имеет семейства кривых для методов обмена ключами для SSH.Простые кривые NIST с именами и другие кривые доступно с использованием идентификатора объекта (OID) с Elliptic Кривая Диффи-Хеллмана (ECDH) через [RFC5656]. Обмен ключами Curve25519 и Curve448 используется с ECDH через [RFC8731] .¶
- Криптография с конечным полем (FFC) используется для Диффи-Хеллмана (DH) обмен ключами с «безопасными простыми числами» либо из указанный список найден в [RFC3526] или генерируется динамически через [RFC4419] как обновлено [RFC8270].¶
- Криптография с целочисленной факторизацией (IFC) с использованием RSA алгоритм предусмотрен в [RFC4432] .¶
Желательно по прочности ключа биржа должна быть сопоставима с ценной бумагой сила других элементов рукопожатия SSH. Злоумышленники могут атаковать самый слабый элемент SSH. рукопожатие.
Желательно выбрать минимум 112 бит безопасности. сила.Основываясь на потребностях разработчиков в безопасности, более сильная минимум может быть желательным.
1.2.1. Криптография эллиптических кривых (ECC)
Для ECC рекомендуется выбрать один с приблизительно 128 бит защиты.
| Название кривой | Расчетная сила безопасности |
|---|---|
| нистп256 | 128 бит |
| нистп384 | 192 бит |
| нистп521 | 512 бит |
| Кривая 25519 | 128 бит |
| Кривая 448 | 224 бит |
1.2.2. Криптография с конечным полем (FFC)
Для FFC модуль 2048 бит (112 бит уровня защиты).
| Размер основного поля | Расчетная сила безопасности | Пример группы MODP |
|---|---|---|
| 2048-бит | 112 бит | группа14 |
| 3072-бит | 128 бит | группа15 |
| 4096 бит | 152 бит | группа16 |
| 6144-бит | 176 бит | группа 17 |
| 8192-бит | 200 бит | группа 18 |
Минимальная группа MODP, которая МОЖЕТ быть использована, — это 2048-битная Группа MODP 14.Реализации ДОЛЖНЫ поддерживать 3072-битный Группа MODP или больше.
1.2.3. Криптография с целочисленной факторизацией (IFC)
Единственный алгоритм IFC для обмена ключами — это RSA. алгоритм через [RFC4432]. Минимальный размер модуля составляет 2048 бит. Использование SHA-2 Семейный хеш с 2048-битными ключами RSA имеет достаточно безопасность.
Ключевые слова «ДОЛЖНЫ», «НЕ ДОЛЖНЫ», «ОБЯЗАТЕЛЬНО», «ДОЛЖНЫ», «ДОЛЖНЫ» НЕ »,« ДОЛЖЕН »,« НЕ ДОЛЖЕН »,« РЕКОМЕНДУЕТСЯ »,« НЕ РЕКОМЕНДУЕТСЯ «,» МОЖЕТ «и» ДОПОЛНИТЕЛЬНО «в этом документе должны быть интерпретируется как описано в BCP 14 [RFC2119] [RFC8174] когда и только когда они появляются заглавными буквами, как показано здесь.¶
Эта памятка принимает стиль и условности [RFC4253] в указании того, как использование обмена ключами данных указывается в SSH.¶
Этот RFC также собирает имена методов обмена ключами в различных существующие RFC [RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656], [RFC8268], [RFC8731], [RFC8732] и [RFC8308], и обеспечивает предполагаемую пригодность для реализации ДОЛЖЕН, ДОЛЖЕН, НЕ ДОЛЖЕН и НЕ ДОЛЖЕН.Любой метод не явно перечисленные МОГУТ быть реализованы.
Этот документ предназначен для предоставления руководства относительно того, какие ключевые алгоритмы обмена подлежат рассмотрению на предмет новых или обновленных Реализации SSH.¶
3.1. Хеширование SHA-1 и SHA-2
Все обмены ключами с использованием алгоритма хеширования SHA-1 следует исключить из употребления, поскольку SHA-1 имеет проблемы безопасности, представленные в [RFC6194].Семейство хэшей SHA-2 [RFC6234] единственный, который более безопасен, чем SHA-1, и был стандартизирован для использования с обменом ключами SSH.
diffie-hellman-group1-sha1 и diffie-hellman-group14-sha1 в настоящее время являются обязательными для реализации (MTI). diffie-hellman-group14-sha1 — более сильный из двух. Группа 14 (2048-битная группа MODP) определена в [RFC3526]. Разумно сохранить группу diffie-hellman-group14-sha1. Exchange для взаимодействия с устаревшими реализациями.Следовательно, СЛЕДУЕТ реализовать diffie-hellman-group14-sha1 и все другие обмены ключами * -sha1 НЕ ДОЛЖНЫ быть реализовано.¶
3.2. Криптография эллиптических кривых (ECC)
3.2.1. curve25519-sha256 и gss-curve25519-sha256- *
Curve25519 эффективен в широком спектре архитектур. со свойствами, обеспечивающими более высокую производительность реализации по сравнению с традиционными эллиптическими кривыми.Использование SHA2-256 (также известного как SHA-256 и sha256) в качестве определено в [RFC6234] для целостности является разумным для этого метода. Эти методы обмена ключами описаны в [RFC8731] и [RFC8732] и аналогичен соглашению о ключах IKEv2, описанному в [RFC8031]. Метод обмена ключами curve25519-sha256 имеет несколько реализации и ДОЛЖНЫ быть реализованы. Метод обмена ключами gss-curve25519-sha256- * ДОЛЖЕН также быть реализованным, потому что он имеет ту же производительность и характеристики безопасности как curve25519-sha2.¶
3.2.2. curve448-sha512 и gss-curve448-sha512- *
Curve448 обеспечивает большую безопасность, чем Curve25519 при более высоких затратах на вычисления и пропускную способность. Оно использует SHA2-512 (также известный как SHA-512), определенный в [RFC6234] для целостности. Этот метод обмена ключами описан в [RFC8731] и аналогичен соглашению о ключах IKEv2, описанному в [RFC8031]. Этот метод МОЖЕТ быть реализован.Метод обмена ключами gss-curve448-sha512- * также МОЖЕТ быть реализован, потому что он имеет ту же производительность и характеристики безопасности как curve448-sha512.¶
3.2.3. ECC diffie-hellman с использованием ecdh- *, ecmqv-sha2 и gss-nistp *
Пространство имен ecdh-sha2- * позволяет другим кривым быть определенный для эллиптической кривой ключ Диффи-Хеллмана обмен. В настоящее время в этом пространство имен, которое ДОЛЖНО поддерживаться.Они появляются в [RFC5656] в разделе 10.1 Требуемые кривые все кривые NISTP named являются обязательными для реализации, если какой-либо из этих RFC реализовано. Этот набор методов МОЖЕТ быть реализован. Если реализовано, названные кривые СЛЕДУЕТ всегда включать, если только специально отключено локальной политикой безопасности. В [RFC5656], раздел 6.1, метод наименования других кривых ECDH с использованием Указаны OID.Эти другие кривые МОГУТ быть реализовано.¶
Пространство имен GSS-API с gss-nistp * -sha * отражает алгоритмы, используемые именами ecdh-sha2- *. В таблице представлены руководство по внедрению.
ECDH снижает пропускную способность обмена ключами по сравнению с FFC DH с аналогичной степенью защиты.
В следующей таблице перечислены алгоритмы, СЛЕДУЮЩИЕ, где реализации могут быть более эффективными или более широкими развернут.Элементы, перечисленные как МОГУТ потенциально меньше эффективная.¶
| Имя метода обмена ключами | Руководство |
|---|---|
| ecdh-sha2- * | МАЯ |
| ecdh-sha2-nistp256 | ДОЛЖЕН |
| gss-nistp256-sha256- * | ДОЛЖЕН |
| ecdh-sha2-nistp384 | ДОЛЖЕН |
| gss-nistp384-sha384- * | ДОЛЖЕН |
| ecdh-sha2-nistp521 | ДОЛЖЕН |
| gss-nistp521-sha512- * | ДОЛЖЕН |
| ecmqv-sha2 | МАЯ |
Желательно согласовать алгоритмы ECDSA и ECDH. использовать одну и ту же кривую для обоих, чтобы поддерживать одинаковую прочность безопасности в соединении.¶
3.3. Криптография с конечным полем (FFC)
3.3.1. FFC diffie-hellman с использованием сгенерированных групп MODP
Этот случайный выбор из набора предварительно сгенерированных модулей для обмена ключами используется SHA2-256, как определено в [RFC4419]. [RFC8270] требует, чтобы реализации избегали любой группы MODP, чьи размер модуля менее 2048 бит. Осторожность должна быть взятые в предварительной генерации модулей P и генератор G такой, что генератор обеспечивает Q-упорядоченный подгруппа P.В противном случае набор параметров может протечь. бит общего секрета, оставляющий группу MODP наполовину сильный. Этот обмен ключами МОЖЕТ быть использован.
3.3.2. FFC diffie-hellman с использованием именованных групп MODP
diffie-hellman-group14-sha256 представляет собой самый маленький Метод обмена ключами FFC DH считается безопасным. Это — это достаточно простой переход от SHA-1 к SHA-2. diffie-hellman-group14-sha256 метод ДОЛЖЕН быть реализовано.Остальные группы FFC MODP МОГУТ быть реализовано. В таблице ниже приведены подробные инструкции. по имени.¶
| Имя метода обмена ключами | Руководство |
|---|---|
| diffie-hellman-group14-sha256 | ДОЛЖЕН |
| gss-group14-sha256- * | ДОЛЖЕН |
| diffie-hellman-group15-sha512 | МАЯ |
| gss-group15-sha512- * | МАЯ |
| diffie-hellman-group16-sha512 | ДОЛЖЕН |
| gss-group16-sha512- * | МАЯ |
| diffie-hellman-group17-sha512 | МАЯ |
| gss-group17-sha512- * | МАЯ |
| diffie-hellman-group18-sha512 | МАЯ |
| gss-group18-sha512- * | МАЯ |
3.4. Криптография с целочисленной факторизацией (IFC)
Метод обмена ключами rsa2048-sha256 определен в [RFC4432]. Использует 2048-битный модуль RSA с хешем SHA2-256. Этот ключ Exchange соответствует минимальному уровню безопасности 112 бит. Этот метод МОЖЕТ быть реализован.
3.5. Согласование расширений Secure Shell
Существует два метода обмена ключами: ext-info-c и ext-info-s, определенный в [RFC8308] которые на самом деле не являются ключевыми биржами.Они предоставляют метод для поддержки других переговоров по Secure Shell. Быть способным желательно расширить функциональность. Этот метод ДОЛЖЕН быть реализовано.¶
В столбце «Орудие» представлены текущие рекомендации этого RFC. Имена методов обмена ключами перечислены в алфавитном порядке.
| Имя метода обмена ключами | Номер ссылки | Орудие |
|---|---|---|
| кривая25519-sha256 | RFC8731 | ДОЛЖЕН |
| кривая448-sha512 | RFC8731 | МАЯ |
| diffie-hellman-group-exchange-sha1 | RFC4419 | НЕ ДОЛЖЕН |
| diffie-hellman-group-exchange sha256 | RFC4419 | МАЯ |
| diffie-hellman-group1-sha1 | RFC4253 | НЕ ДОЛЖЕН |
| diffie-hellman-group14-sha1 | RFC4253 | ДОЛЖЕН |
| diffie-hellman-group14-sha256 | RFC8268 | ДОЛЖЕН |
| diffie-hellman-group15-sha512 | RFC8268 | МАЯ |
| diffie-hellman-group16-sha512 | RFC8268 | ДОЛЖЕН |
| diffie-hellman-group17-sha512 | RFC8268 | МАЯ |
| diffie-hellman-group18-sha512 | RFC8268 | МАЯ |
| ecdh-sha2- * | RFC5656 | МАЯ |
| ecdh-sha2-nistp256 | RFC5656 | ДОЛЖЕН |
| ecdh-sha2-nistp384 | RFC5656 | ДОЛЖЕН |
| ecdh-sha2-nistp521 | RFC5656 | ДОЛЖЕН |
| ecmqv-sha2 | RFC5656 | МАЯ |
| ext-info-c | RFC8308 | ДОЛЖЕН |
| ext-info-s | RFC8308 | ДОЛЖЕН |
| gss- * | RFC4462 | МАЯ |
| gss-curve25519-sha256- * | RFC8732 | ДОЛЖЕН |
| gss-curve448-sha512- * | RFC8732 | МАЯ |
| gss-gex-sha1- * | RFC4462 | НЕ ДОЛЖЕН |
| gss-group1-sha1- * | RFC4462 | НЕ ДОЛЖЕН |
| gss-group14-sha256- * | RFC8732 | ДОЛЖЕН |
| gss-group15-sha512- * | RFC8732 | МАЯ |
| gss-group16-sha512- * | RFC8732 | ДОЛЖЕН |
| gss-group17-sha512- * | RFC8732 | МАЯ |
| gss-group18-sha512- * | RFC8732 | МАЯ |
| gss-nistp256-sha256- * | RFC8732 | ДОЛЖЕН |
| gss-nistp384-sha384- * | RFC8732 | ДОЛЖЕН |
| gss-nistp521-sha512- * | RFC8732 | МАЯ |
| rsa1024-sha1 | RFC4432 | НЕ ДОЛЖЕН |
| rsa2048-sha256 | RFC4432 | МАЯ |
Полный комплект официальных [IANA-KEX] имена методов ключевого алгоритма, не упомянутые иначе в этом документ МОЖЕТ быть реализован.¶
[БУДЕТ УДАЛЕН: Эта регистрация должна происходить в следующий URL-адрес местоположения: http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-16 ] ¶
Благодарим следующих людей за обзор и комментарии: Денис Бидер, Питер Гутманн, Дэмиен Миллер, Нильс Меллер, Мэтт Джонстон, Ивамото Коуичи, Саймон Йозефссон, Дэйв Дугал, Даниэль Миго, Анна Джонстон, Теро Кивинен и Трэвис Финкенауэр.¶
Благодарю следующих людей за код для реализации совместимые обмены с использованием некоторых из этих групп, как показано в этот черновик: Даррен Такер для OpenSSH и Мэтт Джонстон для Dropbear. И спасибо Ивамото Коити за информацию о Реализации RLogin, Tera Term (ttssh) и Poderosa также принятие новых групп Диффи-Хеллмана на основе этого проекта
Этот протокол SSH обеспечивает безопасный зашифрованный канал через небезопасная сеть.Выполняет аутентификацию хоста сервера, ключ обмен, шифрование и проверки целостности. Он также получает уникальный идентификатор сеанса, который может использоваться протоколами более высокого уровня.
Рекомендации по полной безопасности для этого протокола приведены в [RFC4251] .¶
Желательно исключить или удалить название метода обмена ключами которые считаются слабыми. Метод обмена ключами может быть слабым потому что используется слишком мало бит или алгоритм хеширования считается слишком слабым.¶
IANA просят аннотировать записи в [IANA-KEX] которые НЕ ДОЛЖНЫ быть реализованы как устаревшие этим документ.¶
8.1. Нормативные ссылки
- [RFC2119]
- Браднер, С., «Ключевые слова для использования в RFC для обозначения уровней требований», BCP 14, RFC 2119, DOI 10.17487 / RFC2119, ,
- [RFC3526]
- Кивинен, Т.и М. Коджо, «Более модульные экспоненциальные (MODP) группы Диффи-Хеллмана для обмена ключами в Интернете (IKE)», RFC 3526, DOI 10.17487 / RFC3526, ,
- [RFC4250]
- Lehtinen, S. и C. Lonvick, Ed., «Номер, присвоенный протоколу Secure Shell (SSH)», RFC 4250, DOI 10.17487 / RFC4250, ,
- [RFC4253]
- Илонен, Т.и C. Lonvick, Ed., «Протокол транспортного уровня Secure Shell (SSH)», RFC 4253, DOI 10.17487 / RFC4253, ,
- [RFC8031]
- Нир, Й. и С. Йозефссон, «Curve25519 и Curve448 для соглашения о ключах протокола обмена ключами Интернета версии 2 (IKEv2)», RFC 8031, DOI 10.17487 / RFC8031, ,
- [RFC8174]
- Лейба, Б., «Неоднозначность прописных и строчных букв в ключевых словах RFC 2119», BCP 14, RFC 8174, DOI 10.17487 / RFC8174, ,
- [RFC8268]
- Баушке, М., «Группы обмена ключами Диффи-Хеллмана (DH) (KEX) для Secure Shell (SSH) с более модульным возведением в степень (MODP)», RFC 8268, DOI 10.17487 / RFC8268, ,
- [RFC8270]
- Вельвиндрон, Л.и М. Баушке, «Увеличьте минимальный рекомендуемый размер модуля Диффи-Хеллмана для безопасной оболочки до 2048 бит», RFC 8270, DOI 10.17487 / RFC8270, ,
- [RFC8308]
- Бидер, Д., «Согласование расширений в протоколе Secure Shell (SSH)», RFC 8308, DOI 10.17487 / RFC8308, ,
8.2. Информативные ссылки
- [IANA-KEX]
- Internet Assigned Numbers Authority (IANA), «Параметры протокола Secure Shell (SSH): имена методов обмена ключами», ,
- [RFC4251]
- Ylonen, T. и C. Lonvick, Ed., «Архитектура протокола Secure Shell (SSH)», RFC 4251, DOI 10.17487 / RFC4251, ,
- [RFC4419]
- Фридл, М., Провос, Н. и В. Симпсон, «Групповой обмен Диффи-Хеллмана для протокола транспортного уровня Secure Shell (SSH)», RFC 4419, DOI 10.17487 / RFC4419, ,
- [RFC4432]
- Харрис Б., «Обмен ключами RSA для протокола транспортного уровня Secure Shell (SSH)», RFC 4432, DOI 10.17487 / RFC4432, ,
- [RFC4462]
- Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, «Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol», RFC 4462, DOI 10.17487 / RFC4462, ,
- [RFC5656]
- Стебила, Д. и Дж. Грин, «Интеграция алгоритма эллиптической кривой на транспортном уровне защищенной оболочки», RFC 5656, DOI 10.17487 / RFC5656, ,
- [RFC6194]
- Полк Т., Чен Л., Тернер С. и П. Хоффман, «Соображения безопасности для алгоритмов дайджеста сообщений SHA-0 и SHA-1», RFC 6194, DOI 10.17487 / RFC6194, ,
- [RFC6234]
- Истлейк 3-й, Д. и Т. Хансен, «Безопасные хеш-алгоритмы США (HMAC и HKDF на основе SHA и SHA)», RFC 6234, DOI 10.17487 / RFC6234, ,
- [RFC8731]
- А. Адамантиадис, С. Йозефссон и М. Баушке, «Метод обмена ключами Secure Shell (SSH) с использованием Curve25519 и Curve448», RFC 8731, DOI 10.17487 / RFC8731, ,
- [RFC8732]
- Сорс, С. и Х. Карио, «Общий интерфейс прикладного программного интерфейса службы безопасности (GSS-API), обмен ключами с SHA-2», RFC 8732, DOI 10.17487 / RFC8732, ,
Баушке Марк Д.
Juniper Networks, Inc.
Обмен ключамиDiffie-Hellman vs.Шифрование RSA | Venafi
Какой алгоритм вам подходит?
Шифрование не следует рассматривать как окончательный ответ на любую проблему информационной безопасности, а только как часть уравнения безопасности. Эту концепцию всегда следует учитывать при выборе алгоритма открытого ключа. Однако, прежде чем углубляться в какой-либо проект шифрования, проведите тщательный анализ рисков ваших данных и систем, чтобы определить, что вам нужно. Очевидно, что данные с высоким уровнем риска, такие как конфиденциальные данные клиентов, нуждаются в лучшем шифровании, чем маркетинговые планы, которые в случае разглашения окажут гораздо меньшее влияние на бизнес.
Во-вторых, с точки зрения производительности, тщательный анализ сетевой архитектуры и нагрузки, которую она может выдерживать, поможет решить, какой маршрут шифрования выбрать. В общем, шифрование с открытым ключом или асимметричное шифрование примерно в 10 000 раз медленнее, чем шифрование с закрытым ключом. Это связано с тем, что при асимметричном шифровании создаются и обмениваются два ключа по сравнению с одним ключом при частном или симметричном шифровании.
Обмен ключами Диффи-Хеллмана и RSA (названный в честь своих изобретателей Ривест-Шамир-Адлеман) — два самых популярных алгоритма шифрования.Чем они отличаются друг от друга? Какой из них следует использовать организации? Чтобы дать ответ, давайте кратко рассмотрим как
Обмен ключами Диффи-Хеллмана
Обмен ключами Диффи-Хеллмана, также называемый экспоненциальным обменом ключами, представляет собой метод цифрового шифрования, который использует числа, возведенные в определенную степень, для создания ключей дешифрования на основе компонентов, которые никогда не передаются напрямую, что делает задачу предполагаемого взломщика кода математически ошеломляюще.Обмен ключами Диффи-Хеллмана устанавливает общий секрет между двумя сторонами, который может использоваться для секретной связи для обмена данными по общедоступной сети, и фактически использует методы открытого ключа, позволяющие обмениваться частным ключом шифрования.
Чтобы упростить объяснение того, как работает алгоритм, мы будем использовать небольшие положительные целые числа. На самом деле алгоритм использует большие числа. Кроме того, вы можете найти довольно простые объяснения в Википедии и Академии Хана.
Общаясь открыто, Алиса и Боб договариваются о двух положительных целых числах, простом числе и генераторе.Генератор — это число, которое при возведении в степень целого положительного числа, меньшего, чем простое число, никогда не дает одинаковый результат для любых двух таких целых чисел. Предположим, что Алиса будет использовать простое число 17, а Боб — генератор 3. Затем Алиса выбирает частное случайное число, скажем 15, и вычисляет 3 15 mod17 , что равно 6, и отправляет результат Бобу публично.
Затем Боб выбирает свое частное случайное число, скажем 13, вычисляет 3 13 mod17 и отправляет результат (который равен 12) публично Алисе.Суть уловки — это следующее вычисление. Алиса берет публичный результат Боба (= 12) и вычисляет 12 15 mod17 . Результат (= 10) — их общий секретный ключ. С другой стороны, Боб берет публичный результат Алисы (= 6) и вычисляет 6 13 mod17 , что снова приводит к тому же общему секрету. Теперь Алиса и Боб могут общаться, используя симметричный алгоритм по своему выбору и общий секретный ключ, который никогда не передавался по незащищенной цепи.
Если третья сторона прослушивает обмен, этой стороне будет сложно определить секретный ключ с вычислительной точки зрения. Фактически, при использовании больших чисел это действие требует больших вычислительных ресурсов для современных суперкомпьютеров, чтобы выполнить его за разумное время.
RSA
RSA — это криптосистема для шифрования с открытым ключом, которая широко используется для защиты конфиденциальных данных, особенно при передаче по незащищенной сети, такой как Интернет. RSA был впервые описан в 1977 году Роном Ривестом, Ади Шамиром и Леонардом Адлеманом из Массачусетского технологического института.Криптография с открытым ключом, также известная как асимметричная криптография, использует два разных, но математически связанных ключа, один открытый и один закрытый. Открытый ключ может быть передан всем, а закрытый ключ должен храниться в секрете. В криптографии RSA как открытый, так и закрытый ключи могут шифровать сообщение; ключ, противоположный тому, который использовался для шифрования сообщения, используется для его расшифровки. Этот атрибут является одной из причин, по которой RSA стал наиболее широко используемым асимметричным алгоритмом: он обеспечивает метод обеспечения конфиденциальности, целостности, подлинности и неуверенности в электронных коммуникациях и хранении данных.
RSA обеспечивает свою безопасность из-за сложности факторизации больших целых чисел, которые являются произведением двух больших простых чисел. Умножить эти два числа легко, но определение исходных простых чисел из общей суммы, то есть факторинг, считается невозможным из-за того, что на это потребуется время даже при использовании современных суперкомпьютеров. Алгоритм RSA включает четыре этапа: генерация ключа, распределение ключей, шифрование и дешифрование. Алгоритмы генерации открытого и закрытого ключей являются наиболее сложной частью криптографии RSA и выходят за рамки этой статьи.Вы можете найти пример на Tech Target.
Какие отличия?
И RSA, и алгоритм Диффи-Хеллмана являются алгоритмами шифрования с открытым ключом, достаточно сильными для коммерческих целей, поскольку они оба основаны на предположительно неразрешимых проблемах, сложности факторизации больших чисел и возведения в степень и модульной арифметики соответственно. Минимальная рекомендуемая длина ключа для систем шифрования составляет 128 бит, и обе они превышают длину ключа с 1024-битными ключами. Оба они были тщательно изучены математиками и криптографами, но при правильной реализации ни один из них не является значительно менее безопасным, чем другой.
Однако характер обмена ключами Диффи-Хеллмана делает его уязвимым для атак «человек посередине» (MITM), поскольку он не аутентифицирует ни одну из сторон, участвующих в обмене. Маневр MITM также может создавать пару ключей и ложные сообщения между двумя сторонами, которые думают, что они оба общаются друг с другом. Вот почему метод Диффи-Хеллмана используется в сочетании с дополнительным методом аутентификации, обычно с цифровыми подписями.
В отличие от алгоритма Диффи-Хеллмана, алгоритм RSA может использоваться для подписания цифровых подписей, а также для обмена симметричным ключом, но он требует предварительного обмена открытым ключом.Однако недавнее исследование показало, что даже 2048-битные ключи RSA могут быть эффективно понижены с помощью атаки «человек в браузере» или «дополнения» оракула. В отчете говорится, что самой безопасной контрмерой является отказ от обмена ключами RSA и переход на обмен ключами Диффи-Хеллмана (эллиптическая кривая).
Заключение
Какой из них лучший? На этот вопрос сложно ответить, и на различных форумах было много дискуссий. Итак, ответ, как обычно, — «смотря по обстоятельствам».Обычно вы предпочитаете RSA, а не протокол Диффи-Хеллмана, или алгоритм Диффи-Хеллмана, а не RSA, исходя из ограничений взаимодействия и в зависимости от контекста. Производительность редко имеет значение, а что касается безопасности, с точки зрения высокого уровня, 1024-битный ключ Диффи-Хеллмана так же устойчив к криптоанализу, как 1024-битный ключ RSA. Выбор остается за вами.
Подробнее о защите личных данных машины. Исследуй сейчас.
Похожие сообщения
Internet Key Exchange | Руководство пользователя IPsec VPN для устройств безопасности
Протокол IKE версии 2 является преемником метода IKEv1.Это обеспечивает безопасный канал связи VPN между одноранговыми устройствами VPN и определяет согласование и аутентификация для сопоставлений безопасности IPsec (SA) в защищенном виде.
IKEv2 не включает фазы 1 и 2, аналогичные IKEv1, но для согласования туннеля IPsec происходит четыре обмена сообщениями с IKEv2. Обмен сообщениями в IKEv2:
Согласовывает атрибуты безопасности для установления IPsec туннель. Это включает в себя обмен используемыми протоколами / параметрами и Группы Диффи-Хеллмана.
Каждый одноранговый узел устанавливает или аутентифицирует свою личность пока установлен туннель IPsec.
Одноранговые узлы для создания дополнительных ассоциаций безопасности между друг с другом.
Одноранговые узлы выполняют обнаружение активности, удаляя связи SA, и сообщения об ошибках.
Полезная нагрузка конфигурации IKEv2
Полезная нагрузка конфигурации — это вариант IKEv2, предлагаемый для распространения предоставление информации от ответчика инициатору.IKEv2 полезная нагрузка конфигурации поддерживается только для VPN на основе маршрутов.
RFC 5996, Протокол обмена ключами в Интернете, версия 2 (IKEv2) , определяет 15 различных атрибутов конфигурации который может быть возвращен инициатору ответчиком.
Смена ключей и повторная аутентификация IKEv2
В IKEv2 смена ключей и повторная аутентификация являются отдельными процессами.
Смена ключей устанавливает новые ключи для сопоставления безопасности IKE (SA) и сбрасывает счетчики идентификаторов сообщений, но не выполняет повторную аутентификацию сверстники.
Повторная аутентификация подтверждает, что одноранговые узлы VPN сохраняют свой доступ к учетным данным аутентификации. Повторная аутентификация устанавливает новые ключи для IKE SA и дочерних SA; rekeys любых ожидающих IKE SA или дочерних SA больше не нужны. После создания нового IKE и дочерних SA, старые IKE и дочерние SA удаляются.
Повторная аутентификация IKEv2 по умолчанию отключена. Вы включаете повторную аутентификацию путем настройки значения частоты повторной аутентификации от 1 до 100. Частота повторной аутентификации — это количество повторных ключей IKE, которое происходит. перед повторной аутентификацией.Например, если настроенная повторная аутентификация частота равна 1, повторная аутентификация происходит каждый раз при IKE смены ключа. Если настроенная частота повторной аутентификации равна 2, повторная аутентификация происходит при каждой второй смене ключа IKE. Если настроенная повторная аутентификация частота равна 3, повторная аутентификация происходит при каждой третьей смене ключа IKE, и так далее.
Фрагментация IKEv2
При использовании проверки подлинности на основе сертификатов пакеты IKEv2 может превышать MTU пути, если передано несколько сертификатов.Если размер сообщения IKE превышает MTU пути, сообщения фрагментируются. на уровне IP. Некоторое сетевое оборудование, например устройства NAT, не пропускать IP-фрагменты, что препятствует установлению туннелей IPsec.
Фрагментация сообщений IKEv2, как описано в RFC 7383, Интернет Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation, позволяет IKEv2 для работы в средах, где IP-фрагменты могут быть заблокированы и одноранговые узлы не смогут установить сопоставление безопасности IPsec (SA).При фрагментации IKEv2 большое сообщение IKEv2 разбивается на набор. более мелких, чтобы не было фрагментации на уровне IP. Фрагментация происходит до того, как исходное сообщение будет зашифровано. и аутентифицирован, так что каждый фрагмент отдельно зашифрован и аутентифицирован. На приемнике фрагменты собраны, проверены, расшифрованы и объединены в исходное сообщение.
Селекторы трафика для IKEv2
Вы можете настроить селекторы трафика в IKEv2, используемые во время IKE Переговоры.Селектор трафика — это соглашение между одноранговыми узлами IKE. разрешить трафик через VPN-туннель, если трафик соответствует указанному пара локальных и удаленных адресов. Только трафик, который соответствует к селектору трафика разрешено через связанную безопасность ассоциация (SA). Селекторы трафика используются при создании туннеля. настроить туннель и определить, какой трафик разрешен через туннель.
Internet Key Exchange
Internet Key Exchange — это протокол, используемый для установки сопоставления безопасности (SA) в IPsec.В брандмауэр поддерживает IKE, как определено в RFC 2409.
Обмен ключами состоит из следующих этапов:- Аутентификация (этап 1). На этапе 1 одноранговые узлы аутентифицируют себя, используя предварительный доступ. ключ или цифровой сертификат. Безопасный канал связи с аутентификацией создается с использованием алгоритма Диффи – Хеллмана для генерации общего секретного ключа для дальнейшего шифрования. коммуникации. Это согласование приводит к созданию ключей сеанса и ассоциации безопасности.
- Обмен ключами (этап 2). На этапе 2 узлы используют канал безопасности, установленный на этапе 1 для согласования сопоставления безопасности IPsec. Создан ключевой материал для этой ассоциации. используя ключи фазы 1 IKE или выполняя новый обмен ключами в соответствии с настройками PFS. Этот ассоциация шифрует фактические данные пользователя, которые передаются между одноранговыми узлами.
Обмен ключами Диффи – Хеллмана
Обмен ключами Диффи – Хеллмана — это метод безопасного обмена криптографическими ключи по незащищенному каналу.Алгоритм Диффи – Хеллмана был создан для предотвратить атаки защищенных зашифрованных ключей через Интернет во время передачи. Использование обмена ключами Диффи – Хеллмана с алгоритмом аутентификации обеспечивает защиту против спуфинга и атак типа «злоумышленник посередине».
Perfect Forward Secrecy
Perfect Forward Secrecy (PFS) — это метод получения ключей фазы 2, не зависящий от предыдущие ключи.Когда вы указываете PFS, новый ключ будет генерироваться для каждого согласования и новый ключ DH. обмен включен. PFS предлагает улучшенную безопасность, поскольку требует, чтобы злоумышленник взломал дополнительный ключ.
Обзор фильма «Обмен ключами» и краткое содержание фильма (1985)
«Обмен ключами» рассказывает о двух людях, которые имеют отношения, но не должны, о двух людях, которые женаты, но не должны состоять в браке, и о том, как все они приходят к необычно неубедительному счастливый конец.В кино снимается Брук Адамс в роли телепродюсера, чей любовник (Бен Мастерс) хочет, чтобы она была верна, но не видит причин, по которым он должен быть верен. У писателя Мастерс есть друг-юрист (Дэниел Стерн), который только что женился на молодой балерине.
Адамс продюсирует шоу под названием «Доброе утро, Нью-Йорк», которое ведет Тони Робертс, и одно из небольших удовольствий этого фильма — то, как мало он знает о телевидении. (Робертса информируют о своих гостях всего за несколько секунд до интервью, а программа ведется так небрежно, что почти любой может войти и стать гостем.В какой-то момент, если у меня правильная временная схема фильма, «Доброе утро, Нью-Йорк» даже выходит в эфир вечером.)
Сюжет несколько прост. Адамс и Мастерс спорят, стоит ли им обмениваться ключами от квартир друг друга — современная форма истинного обязательства. Мастера дурачатся. У жены-балерины Стерна роман через несколько дней после свадьбы. Стерн, подавленный, находит утешение в Адамсе, и, поскольку они — единственная пара в фильме с истинной, сладкой химией, конечно, фильм делает все возможное, чтобы их разлучить.Тем временем телеведущий должен решить, переезжать ли в Калифорнию, и это решение осложняется визитами в Чикаго, чтобы поговорить с представителями сети, которые, как мы все знаем, никогда бы не оказались на Манхэттене.
Некоторые персонажи, кажется, страдают крайней эмоциональной близорукостью, особенно Мастерс, который однажды вечером приходит в квартиру Адамса и обнаруживает ее на полу, заключенную в объятия со Стерном. Мастерс не упоминает им об этом событии или даже, кажется, замечает его.
У персонажей тоже короткая память.Вскоре после того, как Мастерс имел жестокий и ожесточенный спор с Адамсом, она, кажется, рада его видеть, как будто драки не было. Также есть крайне маловероятная сцена, в которой Мастерс использует свой велосипед, чтобы преследовать лимузин, везущий Адамса и Робертса в аэропорт; такое развитие событий можно увидеть в мультфильме Road Runner.
Что такое обмен ключами Диффи – Хеллмана и как он работает?
Обмен ключами Диффи-Хеллмана был одним из самых важных достижений в криптографии с открытым ключом , и он до сих пор часто реализуется в ряде различных протоколов безопасности сегодня.
Это позволяет двум сторонам, которые ранее не встречались, надежно установить ключ, который они могут использовать для защиты своих сообщений. В этой статье мы объясним, для чего он используется, как он работает на пошаговой основе, его различные варианты, а также соображения безопасности, которые необходимо учитывать для его безопасной реализации.
Что такое обмен ключами Диффи-Хеллмана?Обмен ключами Диффи-Хеллмана был первым широко используемым методом для безопасной разработки и обмена ключами по незащищенному каналу .
Это может показаться не таким захватывающим или новаторским в приведенных выше терминах, поэтому давайте приведем пример, который объясняет, почему обмен ключами Диффи-Хеллмана стал такой важной вехой в мире криптографии и почему он все еще так часто используется сегодня.
Допустим, вы совершенно секретный шпион, и вам нужно отправить важную информацию в свой штаб. Как бы вы помешали вашим врагам получить сообщение?
Наиболее распространенное решение — зашифровать сообщение кодом.Самый простой способ — заранее назначить любой тип кода и ключа, которые вы планируете использовать, или сделать это по безопасному каналу связи.
Допустим, вы очень плохой шпион, и вы и ваш штаб решили использовать слабый шифр шифрования для кодирования ваших сообщений. В этом коде каждый «a» становится «b», каждый «b» становится «c», каждый «c» становится «d» и так далее, вплоть до того, что «z» становится «a».
Под этим шифром смены сообщение «Давай пообедаем» превращается в «Mfu’t hfu ejoofs».К счастью, в нашей гипотетической ситуации ваши противники так же некомпетентны, как и вы, и не могут взломать такой простой код, который не позволяет им получить доступ к содержимому сообщения.
Но что произойдет, если вы не смогли заранее согласовать код с получателем?
Допустим, вы хотите пообщаться со шпионом из союзной страны, которого вы никогда раньше не встречали. У вас нет безопасного канала, по которому можно с ними поговорить. Если вы не зашифруете свое сообщение, любой злоумышленник, который его перехватит, сможет прочитать его содержимое.Если вы зашифруете его, не сообщив союзнику код, то противник не сможет его прочитать, как и союзник.
Эта проблема была одной из самых больших загадок в криптографии до 1970-х годов:
Как вы можете безопасно обмениваться информацией с кем-то, если у вас не было возможности поделиться ключом заранее?
Обмен ключами Диффи-Хеллмана был первым публично используемым механизмом для решения этой проблемы. Алгоритм позволяет тем, кто никогда раньше не встречался, безопасно создать общий ключ, даже по незащищенному каналу, за которым могут следить злоумышленники.
История обмена ключами Диффи-ХеллманаОбмен ключами Диффи-Хеллмана восходит к 1970-м годам. Хотя область криптографии значительно развивалась в начале двадцатого века, эти достижения были в основном сосредоточены в области криптографии с симметричным ключом.
Алгоритмы с открытым ключом появились в публичной сфере только в 1976 году, когда Уитфилд Диффи и Мартин Хеллман опубликовали свою статью Новые направления в криптографии .В ходе сотрудничества были определены механизмы, лежащие в основе новой системы, которая стала известна как обмен ключами Диффи-Хеллмана .
Работа частично вдохновлена более ранними разработками Ральфа Меркла. Так называемые головоломки Меркла предполагают, что одна сторона создает и отправляет несколько криптографических головоломок другой. Для решения этих головоломок потребуется умеренное количество вычислительных ресурсов.
Получатель случайным образом выбирает одну головоломку для решения и затем прилагает необходимые усилия для ее решения. Как только головоломка решена, получателю раскрываются идентификатор и сеансовый ключ . Затем получатель передает идентификатор обратно исходному отправителю, который позволяет отправителю узнать, какая загадка была решена.
Поскольку исходный отправитель создал головоломки, идентификатор позволяет им узнать, какой сеансовый ключ обнаружил получатель, и обе стороны могут использовать этот ключ для более безопасной связи. Если злоумышленник подслушивает взаимодействие, он получит доступ ко всем головоломкам, а также к идентификатору, который получатель передает обратно исходному отправителю.
Идентификатор не сообщает злоумышленнику, какой сеансовый ключ используется, поэтому лучший подход для расшифровки информации — это решить все головоломки, чтобы найти правильный сеансовый ключ . Так как злоумышленнику в среднем придется решать половину головоломок, раскрыть ключ для него будет намного сложнее, чем для получателя.
Такой подход обеспечивает большую безопасность, но это далеко не идеальное решение. Обмен ключами Диффи-Хеллмана взял некоторые из этих идей и усложнил их, чтобы создать безопасный метод криптографии с открытым ключом.
Хотя он стал известен как обмен ключами Диффи-Хеллмана, Мартин Хеллман предложил вместо этого назвать алгоритм обменом ключами Диффи-Хеллмана-Меркла, чтобы отразить работу, проделанную Ральфом Мерклом в области криптографии с открытым ключом.
Публично считалось, что Меркл, Хеллман и Диффи были первыми людьми, которые разработали криптографию с открытым ключом до 1997 года, когда британское правительство рассекретило работу, выполненную в начале 1970-х годов Джеймсом Эллисом, Клиффордом Коксом и Малкольмом Уильямсоном .
Оказывается, трио разработало первую схему шифрования с открытым ключом между 1969 и 1973 годами, но их работа была засекречена в течение двух десятилетий. Оно проводилось при правительственном управлении связи (GCHQ), разведывательном агентстве Великобритании.
Их открытие на самом деле было алгоритмом RSA, поэтому Диффи, Хеллман и Меркл все еще были первыми, кто разработал обмен ключами Диффи-Хеллмана, но уже не первыми изобретателями криптографии с открытым ключом.
Где используется обмен ключами Диффи-Хеллмана?Основная цель обмена ключами Диффи-Хеллмана — безопасно разработать общие секреты, которые можно использовать для получения ключей.Эти ключи затем могут использоваться с алгоритмами симметричного ключа для передачи информации защищенным образом . Симметричные алгоритмы, как правило, используются для шифрования большей части данных, поскольку они более эффективны, чем алгоритмы с открытым ключом.
Технически обмен ключами Диффи-Хеллмана может использоваться для создания открытых и закрытых ключей. Однако на практике вместо него обычно используется RSA. Это связано с тем, что алгоритм RSA также может подписывать сертификаты с открытым ключом, а обмен ключами Диффи-Хеллмана — нет.
Алгоритм Эль-Гамаля, который активно использовался в PGP, основан на обмене ключами Диффи-Хеллмана, поэтому любой протокол, который его использует, эффективно реализует своего рода Диффи-Хеллмана.
Как один из наиболее распространенных методов безопасного распространения ключей, обмен ключами Диффи-Хеллмана часто реализуется в протоколах безопасности, таких как TLS, IPsec, SSH, PGP и многих других . Это делает его неотъемлемой частью нашей безопасной связи.
В рамках этих протоколов обмен ключами Диффи-Хеллмана часто используется для защиты вашего подключения к веб-сайту, для удаленного доступа к другому компьютеру и для отправки зашифрованных сообщений электронной почты.
Как работает обмен ключами Диффи-Хеллмана?Обмен ключами Диффи-Хеллмана сложен, и может быть трудно понять, как он работает. В нем используются очень большие числа и много математики. — это то, чего многие из нас все еще боятся после долгих и скучных уроков в средней школе.
Чтобы упростить понимание, мы начнем с объяснения обмена ключами Диффи-Хеллмана с помощью аналогии . Когда вы получите общее представление о том, как это работает, мы перейдем к более техническому описанию основных процессов.
Лучшая аналогия схемы Диффи-Хеллмана — представить двух человек, смешивающих краску .Давайте воспользуемся стандартом криптографии и скажем, что их зовут Алиса и Боб. Они оба согласны выбрать случайный цвет для начала с . Допустим, они отправляют друг другу сообщение, и выбирает желтый в качестве своего общего цвета , как на диаграмме ниже:
Устанавливают свой цвет. Они не сообщают другой стороне о своем выборе. Допустим, Алиса выбирает красный , а Боб выбирает слегка зеленовато-синий .
Следующий шаг для Алисы и Боба — смешать свой секретный цвет (красный для Алисы, зеленовато-синий для Боба) с желтым, о котором они договорились.Согласно диаграмме, Алиса получает оранжево-оранжевый микс , а результат Боба — более глубокий синий цвет .
После того, как они закончили микширование, они отправляют результат другой стороне. Алиса получает более глубокий синий цвет , а Боб получает оранжевую краску .
Как только они получили смешанный результат от своего партнера, они затем добавляют к нему свой секретный цвет. Алиса берет более глубокий синий цвет и добавляет свою секретную красную краску , в то время как Боб добавляет свой секретный зеленовато-синий цвет к оранжевой смеси, которую он только что получил .
Результат? Они оба имеют один и тот же цвет , который в данном случае является отвратительным коричневым. Возможно, это не тот цвет, которым вы хотели бы покрасить свою гостиную, но, тем не менее, это общий цвет. Этот общий цвет называется общим секретом .
Важнейшей частью обмена ключами Диффи-Хеллмана является то, что обе стороны получают один и тот же результат без необходимости отправлять весь общий секрет по каналу связи .Выбор общего цвета, их собственных секретных цветов, замена смеси и последующее добавление собственного цвета дает обеим сторонам возможность прийти к одному и тому же общему секрету без необходимости пересылать все это целиком.
Если злоумышленник прослушивает обмен, все, к чему он может получить доступ, — это общий желтый цвет, с которого начинают Алиса и Боб, а также смешанные цвета, которыми обмениваются. Поскольку на самом деле это делается огромными числами, а не краской, этих частей информации недостаточно для атаки, чтобы различить либо начальные секретные цвета, либо общий секрет (технически можно вычислить общий секрет из этого информации, но в безопасной реализации обмена ключами Диффи-Хеллмана для этого потребовалось бы невероятное количество времени и вычислительных ресурсов).
Именно такая структура обмена ключами Диффи-Хеллмана делает его таким полезным. Это позволяет двум сторонам обмениваться данными через потенциально опасное соединение и при этом придумывать общий секрет, который они могут использовать для создания ключей шифрования для своих будущих сообщений. . Не имеет значения, подслушивают ли злоумышленники, потому что полный общий секрет никогда не пересылается по соединению.
Технические подробности обмена ключами Диффи-ХеллманаВремя для математики…
Не волнуйтесь, мы сделаем это медленно и постараемся сделать весь процесс максимально простым для понимания.Он следует той же посылке, что и приведенная выше аналогия, но вместо смешивания и отправки цветов, схема Диффи-Хеллмана фактически выполняет вычисления на основе исключительно больших простых чисел, а затем отправляет их через .
Для обеспечения безопасности рекомендуется, чтобы простое число ( p ) имело длину не менее 2048 бит , что является двоичным эквивалентом десятичного числа примерно такого размера:
41536875762873659842593824756984376582763487
75827365928736 84273684728938572983759283475934875938475928475928739587249587 29873958729835792875982795837529876348273685729843579348795827 93857928739548772397592837592478593867045986792384737826735267 354762356873486938694567345682765949806384Чтобы никому не взорваться головой, мы проведем это объяснение с гораздо меньшими числами.Имейте в виду, что для обмен ключами Диффи-Хеллмана был бы небезопасным, если бы он использовал такие маленькие числа, как в нашем примере . Мы используем такие маленькие числа только для более простой демонстрации концепции.
В самой простой форме обмена ключами Диффи-Хеллмана Алиса и Боб начинают с взаимного определения двух чисел, которые должны начинаться с , в отличие от единственной общей раскраски в приведенном выше примере. Это модуль ( p ) и основание ( g ) .
На практике модуль упругости ( p ) представляет собой очень большое простое число , тогда как основание ( g ) относительно мало для упрощения вычислений . Основание ( g ) происходит от циклической группы ( G ), которая обычно образуется задолго до того, как будут иметь место другие стадии.
В нашем примере предположим, что модуль ( p ) равен 17 , а базовый ( g ) равен 4 .
После того, как они обоюдно определились с этими числами, Алиса выбирает для себя секретный номер ( a ), а Боб выбирает свой собственный секретный номер ( b ).Допустим, они выбирают:
a = 3
б = 6
Алиса затем выполняет следующие вычисления, чтобы дать ей номер, который она отправит Бобу:
A = g a мод p
В приведенном выше вычислении mod означает операцию по модулю. По сути, это вычисления для вычисления остатка от деления левой части на правую. Например:
15 мод 4 = 3
Если вы понимаете, как работают операции по модулю, вы можете выполнить их самостоятельно в следующих вычислениях, в противном случае вы можете использовать онлайн-калькулятор.
Давайте представим наши числа в формуле:
A = 4 3 мод 17
A = 64 мод 17
А = 13
Проделав то же самое с Бобом, мы получим:
B = 4 6 мод 17
B = 4096 мод 17
В = 16
Алиса затем отправляет свой результат ( A ) Бобу, а Боб отправляет свою цифру ( B ) Алисе. Затем Алиса вычисляет общий секрет ( s ), используя номер, который она получила от Боба ( B ), и свой секретный номер ( a ), используя следующую формулу:
s = B a мод p
с = 16 3 мод 17
с = 4096 мод 17
с = 16
Боб затем выполняет то же самое вычисление, но с номером, который ему прислала Алиса ( A ), а также своим собственным секретным номером ( b ):
s = A b mod p
с = 13 6 мод 17
с = 4826809 мод 17
с = 16
Как видите, обе стороны дали одинаковый результат для s , 16 .Это общий секрет, который знают только Алиса и Боб. Затем они могут использовать это для настройки ключа для симметричного шифрования, позволяющего им безопасно передавать информацию между собой таким образом, чтобы только они могли получить к ней доступ.
Обратите внимание, что хотя B и s одинаковы в приведенном выше примере, это просто совпадение, основанное на небольших числах, которые были выбраны для этой иллюстрации. Обычно эти значения не будут одинаковыми в реальной реализации обмена ключами Диффи-Хеллмана.
Несмотря на то, что большая часть вышеперечисленных данных передается по каналу в виде открытого текста ( p, g, A и B ) и может быть прочитана потенциальными злоумышленниками, общий секрет ( s ) никогда не передается. Для злоумышленника было бы непрактично вычислить общий секрет ( s ) или любое из секретных чисел ( a и b ) из информации, которая отправляется в открытом виде.
Конечно, это предполагает, что обмен ключами Диффи-Хеллмана реализован должным образом и используются достаточно большие числа.Пока эти положения соблюдаются, обмен ключами Диффи-Хеллмана считается безопасным способом установления общего секрета, который может использоваться для защиты будущих коммуникаций.
Установление общего ключа между несколькими сторонамиОбмен ключами Диффи-Хеллмана также может использоваться для установки общего ключа с большим количеством участников. Он работает таким же образом, за исключением того, что для каждой стороны требуются дальнейшие раунды вычислений, чтобы добавить свой секретный номер и получить один и тот же общий секрет.
Как и в двухсторонней версии обмена ключами Диффи-Хеллмана, некоторые части информации пересылаются по незащищенным каналам, но этого недостаточно для того, чтобы злоумышленник мог вычислить общий секрет.
Почему обмен ключами Диффи-Хеллмана безопасен?На математическом уровне обмен ключами Диффи-Хеллмана полагается на односторонние функции как основу своей безопасности. Это вычисления, которые просто выполнить в одну сторону, но гораздо сложнее произвести в обратном порядке.
Более конкретно, он основан на проблеме Диффи-Хеллмана, которая предполагает, что при правильных параметрах невозможно вычислить г ab из отдельных значений г , г a и г б . В настоящее время нет публично известного способа легко найти g ab из других значений, поэтому обмен ключами Диффи-Хеллмана считается безопасным, несмотря на то, что злоумышленники могут перехватить значения p , g , A и B .
Аутентификация и обмен ключами Диффи-ХеллманаВ реальном мире обмен ключами Диффи-Хеллмана редко используется сам по себе. Основная причина этого заключается в том, что не обеспечивает аутентификации, что делает пользователей уязвимыми для атак типа «злоумышленник посередине» .
Эти атаки могут иметь место, когда обмен ключами Диффи-Хеллмана реализован сам по себе, поскольку он не имеет средств проверки, действительно ли другая сторона в соединении является тем, кем они себя называют .Без какой-либо формы аутентификации пользователи могут фактически подключаться к злоумышленникам , когда они думают, что общаются с доверенной стороной.
По этой причине обмен ключами Диффи-Хеллмана обычно реализуется вместе с некоторыми средствами аутентификации. Это часто связано с использованием цифровых сертификатов и алгоритма открытого ключа, такого как RSA, для проверки личности каждой стороны.
Варианты обмена ключами Диффи-ХеллманаОбмен ключами Диффи-Хеллмана может быть реализован множеством различных способов, и он также стал основой для нескольких других алгоритмов.Некоторые из этих реализаций обеспечивают авторизацию, в то время как другие имеют различные криптографические функции, такие как совершенная прямая секретность.
Эллиптическая кривая Диффи-ХеллманаЭллиптическая кривая Диффи-Хеллмана использует преимущества алгебраической структуры эллиптических кривых, чтобы позволить своим реализациям достичь аналогичного уровня безопасности с меньшим размером ключа. 224-битный ключ с эллиптической кривой обеспечивает тот же уровень безопасности, что и 2048-битный ключ RSA. Это может сделать обмены более эффективными и снизить требования к хранилищу.
За исключением меньшей длины ключа и того факта, что он основан на свойствах эллиптических кривых, эллиптическая кривая Диффи-Хеллмана работает аналогично стандартному обмену ключами Диффи-Хеллмана.
TLS ПротоколTLS, который используется для защиты большей части Интернета, может использовать обмен Диффи-Хеллмана тремя различными способами: анонимным, статическим и эфемерным. На практике следует использовать только эфемерный метод Диффи-Хеллмана, поскольку другие варианты имеют проблемы с безопасностью.
- Анонимный Diffie-Hellman — Эта версия обмена ключами Диффи-Хеллмана не использует никакой аутентификации, что делает ее уязвимой для атак типа «злоумышленник в середине». Его не следует использовать или реализовывать.
- Статический Диффи-Хеллман — Статический Диффи-Хеллман использует сертификаты для аутентификации сервера. По умолчанию он не аутентифицирует клиента и не обеспечивает прямой секретности.
- Ephemeral Diffie-Hellman — считается наиболее безопасной реализацией, поскольку она обеспечивает идеальную прямую секретность.Обычно он сочетается с таким алгоритмом, как DSA или RSA, для аутентификации одной или обеих сторон в соединении. Эфемерный Диффи-Хеллман использует разные пары ключей при каждом запуске протокола. Это обеспечивает идеальную прямую секретность соединения, потому что даже если ключ будет скомпрометирован в будущем, его нельзя будет использовать для расшифровки всех прошлых сообщений.
ElGamal — это алгоритм с открытым ключом, построенный на основе обмена ключами Диффи-Хеллмана.Как и Diffie-Hellman, он не содержит никаких положений для аутентификации как таковой, и для этой цели обычно комбинируется с другими механизмами.
ElGamal в основном использовался в PGP, GNU Privacy Guard и других системах, потому что его главный конкурент, RSA, был запатентован. Срок действия патента RSA истек в 2000 году, что позволило свободно применять его после этой даты. С тех пор ЭльГамал внедрялся не так часто.
СТСПротокол «Станция-Станция» (STS) также основан на обмене ключами Диффи-Хеллмана.Это еще одна ключевая схема соглашения, однако она обеспечивает защиту от атак «злоумышленник посередине», а также обеспечивает совершенную прямую секретность.
Требуется, чтобы обе стороны в соединении уже имели пару ключей, которая используется для аутентификации каждой стороны. Если стороны еще не известны друг другу, сертификаты могут использоваться для подтверждения личности обеих сторон.
Обмен ключами Диффи-Хеллмана и RSAКак мы обсуждали ранее, обмен ключами Диффи-Хеллмана часто реализуется вместе с RSA или другими алгоритмами для аутентификации соединения. Если вы знакомы с RSA, вам может быть интересно, , зачем кому-то понадобилось использовать обмен ключами Диффи-Хеллмана, а также , поскольку RSA позволяет сторонам, которые никогда ранее не встречались, безопасно общаться.
RSA позволяет своим пользователям шифровать сообщения с помощью открытого ключа своего корреспондента, так что они могут быть расшифрованы только соответствующим закрытым ключом. Однако на практике RSA не используется для шифрования всей связи — это было бы слишком неэффективно .
Вместо этого RSA часто используется только как средство для аутентификации обеих сторон. Он делает это с цифровыми сертификатами каждой стороны, которые будут проверены центром сертификации , чтобы доказать, что владелец сертификата действительно является тем, кем они себя называют, и что открытый ключ сертификата действительно принадлежит им.
Для взаимной аутентификации каждая сторона подпишет сообщение, используя свой закрытый ключ, а затем отправит его своему партнеру по коммуникации. Каждый получатель может затем проверить личность другой стороны, сверяя подписанные сообщения с открытым ключом в цифровом сертификате своего партнера по обмену данными (см. Вышеупомянутую статью о RSA для получения более подробной информации о том, как это работает, в частности, подпись сообщения раздела).
Теперь, когда обе стороны прошли аутентификацию, технически возможно продолжить использование RSA для безопасной передачи зашифрованных сообщений между собой, однако это окажется слишком неэффективным.
Чтобы обойти эту неэффективность, многие протоколы безопасности используют алгоритм, такой как обмена ключами Диффи-Хеллмана, чтобы придумать общий секрет, который можно использовать для создания общего симметричного ключа. Этот симметричный ключ затем используется в алгоритме симметричного ключа, таком как AES, для шифрования данных , которые обе стороны намерены безопасно пересылать между собой.
Это может показаться сложным и запутанным процессом, но в конечном итоге он оказывается намного более быстрым и менее требовательным к ресурсам по сравнению с использованием алгоритма с открытым ключом для всего обмена.Это связано с тем, что шифрование с симметричным ключом на несколько порядков эффективнее, чем шифрование с открытым ключом .
В дополнение к неэффективности, о которой мы только что упомянули, есть и другие недостатки, связанные с использованием только RSA. RSA нуждается в заполнении, чтобы сделать его безопасным, , поэтому, чтобы сделать его безопасным, необходимо соответствующим образом реализовать дополнительный алгоритм.
RSA также не обеспечивает идеальной прямой секретности , что является еще одним недостатком по сравнению с эфемерным обменом ключами Диффи-Хеллмана.В совокупности эти причины объясняют, почему во многих ситуациях лучше всего применять RSA только в сочетании с обменом ключами Диффи-Хеллмана.
В качестве альтернативы обмен ключами Диффи-Хеллмана может быть объединен с таким алгоритмом, как Стандарт цифровой подписи (DSS), для обеспечения аутентификации, обмена ключами, конфиденциальности и проверки целостности данных. В такой ситуации RSA не требуется для защиты соединения.
Проблемы безопасности обмена ключами Диффи-ХеллманаБезопасность обмена ключами Диффи-Хеллмана зависит от того, как он реализован, а также от выбранных для него номеров.Как мы заявили выше, у него нет средств аутентификации другой стороны самостоятельно, но на практике используются другие механизмы, чтобы гарантировать, что другая сторона в соединении не является самозванцем.
Параметры для выбора номераЕсли бы реальная реализация обмена ключами Диффи-Хеллмана использовала такие же маленькие числа, как в нашем примере, это сделало бы процесс обмена тривиальным для взлома злоумышленником. Но важен не только размер чисел — числа также должны быть достаточно случайными.Если генератор случайных чисел дает предсказуемый результат, он может полностью подорвать безопасность обмена ключами Диффи-Хеллмана.
Номер p должен иметь длину 2048 бит для обеспечения безопасности. Основание, г , может быть относительно небольшим числом, например 2 , но оно должно происходить из порядка G с большим простым множителем
Атака тупикаОбмен ключами Диффи-Хеллмана был разработан на основе проблемы дискретного логарифмирования, которую трудно решить .Наиболее эффективным общеизвестным механизмом поиска решения является алгоритм сита числового поля.
Возможности этого алгоритма были учтены при проектировании обмена ключами Диффи-Хеллмана. К 1992 году было известно, что для данной группы, G , три из четырех шагов, задействованных в алгоритме, потенциально могут быть вычислены заранее. Если бы этот прогресс был сохранен, последний шаг можно было бы рассчитать за сравнительно короткое время.
Это не сильно беспокоило, пока не стало ясно, что значительная часть интернет-трафика использует те же группы размером 1024 бита или меньше.В 2015 году академическая группа провела расчеты для наиболее распространенного 512-битного простого числа, используемого при обмене ключами Диффи-Хеллмана в TLS.
Они также смогли понизить версию 80% серверов TLS, поддерживающих DHE-EXPORT, чтобы они принимали 512-битный обмен ключами Диффи-Хеллмана экспортного уровня для соединения. Это означает, что каждый из этих серверов уязвим для атаки хорошо обеспеченного противника .
Исследователи продолжили экстраполировать свои результаты, оценив, что национальное государство может нарушить 1024-битное простое число. Взломав единственное наиболее часто используемое 1024-битное простое число, академическая группа подсчитала, что злоумышленник может отслеживать 18% из миллиона самых популярных веб-сайтов HTTPS.
Далее они заявили, что второе простое число позволит злоумышленнику расшифровать соединения 66% серверов VPN и 26% серверов SSH. Позже в отчете ученые предположили, что АНБ, возможно, уже имеет эти возможности.
«Внимательное изучение опубликованных утечек АНБ показывает, что атаки агентства на VPN соответствуют достижению такого прорыва.”
Несмотря на эту уязвимость, обмен ключами Диффи-Хеллмана может быть безопасным, если он реализован правильно. Пока используется 2048-битный ключ, атака Logjam работать не будет. Обновленные браузеры также защищены от этой атаки.
Безопасен ли обмен ключами Диффи-Хеллмана?Хотя обмен ключами Диффи-Хеллмана может показаться сложным, это фундаментальная часть безопасного обмена данными в Интернете. Если он реализован вместе с соответствующим методом аутентификации и номера были выбраны правильно, он не считается уязвимым для атаки.
Обмен ключами Диффи-Хеллмана был инновационным методом, помогающим двум неизвестным сторонам безопасно общаться, когда он был разработан в 1970-х годах. Хотя сейчас мы внедряем более новые версии с более крупными ключами для защиты от современной технологии , сам протокол выглядит так, как будто он будет оставаться безопасным до появления квантовых вычислений и продвинутых атак, которые будут сопровождать его.
Как квантовые вычисления повлияют на обмен ключами Диффи-Хеллмана?
Квантовые вычисления — это развивающаяся отрасль вычислений, которая продолжает совершать прорывы.Специфика того, как работают квантовые компьютеры, сложны и выходят за рамки этой статьи, однако технология действительно представляет значительные проблемы для области криптографии.
Простое объяснение состоит в том, что квантовые компьютеры, как ожидается, будут способны решать определенные проблемы, которые в настоящее время невозможны для классических компьютеров. Это откроет множество дверей и откроет новые возможности. Достаточно мощные квантовые компьютеры смогут запускать квантовые алгоритмы, которые могут более эффективно решать различные математические задачи.
Хотя это может показаться отличным, безопасность многих из наших текущих криптографических механизмов зависит от того, что эти проблемы трудно решить. Если эти математические задачи станет легче вычислить, также станет легче взломать эти криптографические механизмы.
Одним из таких квантовых алгоритмов является алгоритм Гровера. Когда квантовые компьютеры станут достаточно мощными, это ускорит атаки на шифры с симметричным ключом, такие как AES. Однако ее можно легко уменьшить, удвоив размер ключа.
Наибольшую озабоченность вызывает то, как алгоритм Шора повлияет на криптографию с открытым ключом. Это связано с тем, что безопасность наиболее распространенных алгоритмов с открытым ключом зависит от огромной сложности решения одного из этих трех вычислений:
Особенности каждого из них не имеют особого значения, но вы можете перейти по ссылкам, если вам нужна дополнительная информация. Важно то, что как только появятся достаточно мощные квантовые компьютеры, решение этих проблем с помощью алгоритма Шора станет гораздо более практичным.По мере того, как эти проблемы станет легче решать, криптографические системы, которые на них работают, станут менее безопасными.
Криптография с открытым ключом играет фундаментальную роль в защите наших коммуникаций, поэтому квантовые вычисления представляют собой огромную проблему для криптографов.
В случае обмена ключами Диффи-Хеллмана его безопасность зависит от непрактичности возможности решить проблему дискретного логарифмирования с использованием современных технологий и ресурсов. Однако угрозы, исходящие от алгоритма Шора, становятся все ближе с каждым прогрессом в квантовых вычислениях.
Трудно назвать приблизительный график того, когда квантовые вычисления будут серьезно угрожать обмену ключами Диффи-Хеллмана, потому что некоторые исследователи настроены гораздо более оптимистично, чем другие. Несмотря на это, разрабатываются замены для обмена ключами Диффи-Хеллмана и других алгоритмов с открытым ключом, чтобы мы были готовы к тому, когда придет время.
Возможные замены для обмена ключами Диффи-Хеллмана
Опасность со стороны квантовых компьютеров не является непосредственной, поэтому криптографическое сообщество еще не определилось с конкретными альтернативами обмену ключами Диффи-Хеллмана.Однако предстоит пройти по многим путям. К ним относятся:
Мы до сих пор не знаем точно, как постквантовый мир будет искать криптографию, но сообщество специалистов по безопасности активно работает над проблемами и идет в ногу с достижениями в мире квантовых вычислений. Хотя в будущем произойдут большие изменения, обычному человеку нечего бояться — вы, вероятно, даже не заметите, когда какие-либо изменения действительно произойдут.
Обмен ключами в Интернете в сетевой безопасности
Internet Key Exchange (также известный как IKE , IKEv1 или IKEv2 ) — это протокол, который используется для создания ассоциации безопасности в пакете Internet Protocol Security protocol .В этой статье мы подробно обсудим Internet Key Exchange и объясним, почему это важно для сетевой безопасности .
Если ваша должность требует определенной степени знаний о кибербезопасности и / или интернет-безопасности , вы должны хотя бы слышать о Internet Key Exchange . Сокращенно IKE, Internet Key Exchange — это особый протокол, который призван предложить дополнительный уровень безопасности для виртуальных частных сетей (также известных как VPN s).В этой статье мы объясним, как работает Internet Key Exchange и как он может быть полезен для обеспечения кибербезопасности вашей организации.
Что такое Интернет-обмен ключами?
Проще говоря, Internet Key Exchange — это гибридный протокол , который часто используется для целей управления ключами в сетях IPSec . Он часто используется в качестве метода обмена ключами шифрования и / или ключами аутентификации через незащищенный носитель, такой как Интернет.Другими словами, Internet Key Exchange стремится обеспечить безопасное и надежное шифрование для небезопасных или уязвимых сред.
Internet Key Exchange восходит к концу 90-х годов. Он был определен Инженерной группой Internet Engineering Task Force (также известной как IETF ) в ноябре 1998 года. В публикациях IETF под названием Request for Comments, цель и объем Internet Key Exchange были подробно объяснены (см. RFC 2407, RFC 2408 и RFC 2409 для подробностей). Позже, в декабре 2005 г., октябре 2006 г. и октябре 2014 г., эти описания обмена ключами в Интернете были обновлены и отредактированы в соответствии с потребностями, предъявляемыми новыми технологиями.
Протокол Internet Key Exchange берет свое начало в протоколах Oakley Protocol , SKEME и ISAKMP , поэтому его часто называют гибридным протоколом. Протокол Oakley строго определяет механизм для обмена ключами в течение сеанса протокола обмена ключами Интернета и устанавливает алгоритм обмена ключами по умолчанию как алгоритм Диффи-Хеллмана .
Internet Key Exchange предлагает множество дополнительных функций и определенную степень гибкости.Вот почему часто выбирают для улучшения IPsec.
Каковы преимущества обмена ключами в Интернете?
Internet Key Exchange предлагает множество дополнительных преимуществ, включая гибкость. Ниже вы можете найти некоторые из этих преимуществ:
- Internet Key Exchange предлагает изменение шифрования во время сеансов IPsec.
- Благодаря использованию Internet Key Exchange отпадает необходимость в ручном указании всех параметров безопасности IPSec .
- Internet Key Exchange позволяет центру сертификации , в результате он предлагает дополнительный уровень безопасности.
- Определенное время жизни может быть установлено для сопоставления безопасности IPsec , когда используется Internet Key Exchange.
- Internet Key Exchange разрешает динамическую аутентификацию одноранговых узлов .
Какие существуют методы одноранговой аутентификации в IKE?
Internet Key Exchange использует три различных метода для обеспечения аутентификации однорангового узла:
- Аутентификация с использованием подписей RSA
- Аутентификация с использованием определенного предварительно общего секрета
- Аутентификация с использованием зашифрованных одноразовых номеров RSA
Если вы заинтересованы в улучшении сетевой безопасности или безопасности вашей организации, обратите внимание на наши решения SIEM и SOAR .