Алгоритм валидации открытых ключей

Вы наверняка знаете, что такое алгоритм асимметричного шифрования, который используется в обмене шифрованными сообщениям, в частности в протоколе https. Если кто не в курсе, прочитайте статью в Википедии:

Криптосистема с открытым ключом ^[1]

В этой же статье описана атака на соединение с помощью посредника, контролирующего все исходящие и входящие соединения между двумя узлами, которые устанавливают защищенное соединение. Сейчас устранение этой уязвимости решается с помощью обмена сертификатами открытых ключей, что очень неудобно. Хотелось бы иметь защищенную возможность обмениваться ключами через сеть. Казалось бы, поиски решения схожи с задачей нахождения вечного двигателя, однако здесь все же есть несколько лазеек.

Я предлагаю вашему вниманию алгоритм валидации ключа выбранного сервера, который, возможно, поможет свести вероятность подмены ключей к минимуму:

Пусть через определенный промежуток времени, сервер валидации (В) генерирует таблицу, которая содержит множество записей из двух пар ключей А и Б, и привязывает ее к уникальному идентификатору.

Пользователь, который желает получить открытый ключ одного из серверов, поддерживающих такую валидацию (ПВ-сервер), отправляет В-серверу запрос на получение информации. В-сервер возвращает список открытых ключей Бn, а также идентификатор таблицы. Затем пользователь случайным образом выбирает ключ и начинает вычисление закрытого ключа Бn. После этого он генерирует свою пару ключей C, шифрует открытый ключ С и адрес нужного ПВ-сервера полученным закрытым ключом Бn и отправляет шифр вместе с идентификатором таблицы обратно серверу.

Сервер проверяет подбирает открытый ключ из таблицы с полученным идентификатором к шифрованному блоку. Затем он расшифровывает найденным закрытым ключом Бn шифр, и отправляет ПВ-серверу зашифрованный открытым ключом ПВ-сервера адрес пользователя, идентификатор таблицы и открытый ключ поьзователя С.

ПВ-сервер принимает данные, расшифровывает их своим ключом, шифрует идентификатор таблицы и свой открытый ключ полученным ключом и отправляет на адрес пользователя. Пользователь расшифровывает своим закрытым ключом С данные и получает проверенный открытый ключ ПВ-сервера и идентификатор таблицы. Если идентификатор совпадает с полученным изначально, значит ключ подтвержден.

На основе бенчмарка системы и сетевого подключения пользователя, а также максимального времени подбора ключа от сервера, вычисляется максимальное время, которое может пройти с момента запроса таблицы до валидации. Если в результате времени было потрачено больше, можно сделать вывод либо о перегрузке сервера либо о возможной успешно проведенной сетевой атаке. В этом случае лучше автоматически повторить процесс валидации с другим сервером.

Рассмотрим возможные способы вклинивания посредника по стандартной схеме. Прежде всего, ему нужно подменить открытый ключ, который посылается ПВ-сервером пользователю. Для того, чтобы зашифровать поддельный открытый ключ ПВ-сервера, нужно знать открытый ключ С. В свою очередь, этот ключ может быть получен только перехватом шифрованного блока с ключом и идентификатором таблицы и расшифровкой первого из них. Для этого нужно знать закрытый ключ Бn. Его можно вычислить, но для этого нужно знать открытый ключ Бn. Так как посредник не знает, какую запись выбрал пользователь, ему придется вычислять закрытые ключи с помощью открытых из таблицы и пробовать расшифровывать блок шифрованных проверочных данных. Но на это потребуется много ресурсов и времени и валидация сорвется.

Для уменьшения вероятности случайного “попадания” посредника, когда ему удается угадать выбранную запись и вовремя вычислить ключ, можно увеличивать количество записей, увеличивать сложность ключа и уменьшать интервал генерации таблиц.

Автор: MattMerkulov

Источник ^[2]