Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
INFO2.doc
Скачиваний:
9
Добавлен:
17.04.2019
Размер:
1.22 Mб
Скачать

Проблемы использования открытых/закрытых ключей

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

Однако, условием этого является обмен открытыми ключами между сторонами (участвующими в обмене информацией). А как пользователь С сможет проверить, что полученный ключ - это ключ D, а не злобного E (который перехватил оригинальное письмо D, а вместо него отправил письмо со своим открытым ключом, и получая все сообщения от D, он их расшифровавает/меняет, шифрует/подписывает своим ключом и отправляет дальше к C)? Каким образом мы можем узнать, что данный ключ принадлежит данному пользователю? Опять шифроблокнотики, личные встречи и бумаги с печатами? (Кстати, это не самый сложный метод: люди обмениваются нотариально заверенными бумагами с распечатанными открытыми ключами - и никакой "злобный Е" не сможет притвориться одним из них. Главная проблема подобного метода - плохое масштабирование. Если 300 человек решат так сделать со всеми остальными 299 человеками, то потребуется 300*299=89700 нотариально заверенных распечаток откртых ключей).

Проблема получения правильного открытого ключа - это первая проблема. Вторая проблема: предположим, что закрытый ключ пользователя украли. Как ему оповестить всех людей, с кем у него защищённый обмен информацией о краже? А об утрате? Если он это сделает с помощью незащищённых каналов связи, то и злоумышленник может заявить (якобы от лица пользователя): "ключ украли, компьютер сломали, не слушайте больше писем с этим ключом". Т.е. вся защита держится на личном доверии, каких-то других каналах связи? Или вообще ни на чём не держится?

Главная проблема, которую можно выделить из этих примеров: пользователь не имеет возможности проверить, что ключ Aпринадлежит пользователю A. Любой другой пользователь (злоумышленник) может сделать то же самое, что пользователь A, и назвать себя пользователем A.

Как решить эту задачу?

Главная "правда" PKI состоит в том, что подобная задача не может быть решена только средствами криптографии. Необходима некая договорённость между использующими ключи людьми о том, как именно доказывать связь ключа и пользователя. Решение этого вопроса - и есть суть PKI. Дополнительно же, помимо "главной задачи" решается ещё несколько очень важных задач, позволяющих обеспечить множество видов дополнительного криптографического сервиса.

Сертификат

Определение сертификата очень простое:

сертификат - подписанная доверенной стороной связь между идентичностью и её открытым ключом (-ами).

На самом деле в этом определении очень много того, о чём мы пока не говорили. Оставим в стороне "подписанная доверенной стороной" (об этом позже). Сфокусируемся на "связь между идентичностью и открытым ключом".

Фактически, сертификат - это ключ, к которому дописали, чей это ключ. Мы открываем сертификат и видим, что он принадлежит Васе Пупкину. Значит, подписи сообщения от Васи Пупкина следует проверять указанным открытым ключом, и шифровать письма Васе Пупкину надо так же этим открытым ключом.

Однако, просто указание на имя (емейл) и открытый ключ не достаточно - такая конструкция ничем не отличается от предыдущей (электронное письмо "мой открытый ключ XXX-XXX-XXX-XXX, С уважением, Вася Пупкин"). Нужны какие-то объективные доказательства того, что ключ Васи Пупкина - это таки ключ Васи Пупкина. И Вася Пупкин - это именно ТОТ Вася, о котором мы думаем.

В принципе, если подумать, то если связь "вася пупкин + открытый ключ" подпишет кто-то из тех, чей ключ мы знаем (уже), то это добавит нам уверенности. Но только в том случае, если этот "кто-то" нам знаком и мы ему доверяем. А если нет?

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]