Как предотвратить атаку «человек посередине» в случае взлома сервера? - PullRequest
3 голосов
/ 28 августа 2010

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

В любом случае - представьте, что сервер взломан и отправляет не запрошенные открытые ключи:

Алиса запрашивает открытый ключ Боба
Сервер отправляет открытый ключ Евы

Боб запрашивает открытый ключ Алисы
Сервер отправляет открытый ключ Евы

Алиса отправляет сообщение Бобу
Сервер распаковывает сообщение, читает и перепаковывает его -> отправляет Бобу ...

Боб отправляет сообщение Алисе
Сервер распаковывает сообщение, читает его и перепаковывает -> отправляет Алисе ...

Мой вопрос - как предотвратить такое злоупотребление? Как Алиса может быть уверена, что она использует открытый ключ Боба, и наоборот?

Ответы [ 4 ]

8 голосов
/ 28 августа 2010

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

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

PGP (он же GPG) пытаетсярешить проблему другим, но похожим способом - ключи могут быть подписаны любым количеством других ключей, образуя граф (называемый сеть доверия ).Вы выбираете некоторые ключи, которые вы подтвердили действительными, например, проверяя их лично , и помечаете их как доверенные.Тогда любые ключи, достигаемые менее чем за N шагов (и / или из M различных путей из разных доверенных корней), также считаются действительными.

Если вы действительно параноик, вы, конечно, можете физически вручить ключдругому человеку.Конечно, они должны быть уверены, что это не кто-то, замаскированный под вас ...

Тем не менее, единственный действительно надежный способ проверки правильности ключа - это его генерация самостоятельно ... если только ваше оборудование / ОС/ компилятор / мозг тоже взломан:)

2 голосов
/ 28 августа 2010

Здесь отсутствует ключевая часть аутентификация .Алисе нужен способ узнать, что она действительно использует открытый ключ Бобса.Один из способов - обменяться ключами лично, но это не всегда возможно.

Для этого и нужна Сеть доверия .Другие стороны могут подписать открытый ключ пользователя, если они уверены, что этот ключ принадлежит ему.Если достаточно (3) из ваших других контактов (которым вы доверяете) подписали открытый ключ Боба, вы можете быть относительно уверены, что это его ключ.

0 голосов
/ 28 августа 2010

Часто задаваемые вопросы для PGP (Pretty Good Privacy) объясняет эту проблему.

Я также рекомендовал бы прочитать превосходную книгу Брюса Шнайера " Прикладная криптография " для "дружественных и удобных" обсуждений этих тем.

0 голосов
/ 28 августа 2010

Это основная проблема с шифрованием с открытым ключом.У вас нет никакого способа проверить, что полученный вами открытый ключ действительно является открытым ключом для вашего предполагаемого получателя.HTTPS / SSL обходит это путем использования доверенных центров сертификации.Центр сертификации подписывает открытый ключ соответствующей стороны своим закрытым ключом, гарантируя, что открытый ключ не был изменен, так как он был предоставлен центру сертификации.Даже в этом случае гарантируется, что ключ, предоставленный вам при запросе, является тем же ключом, который был первоначально предоставлен центру сертификации.Однако, если сервер, предоставляющий эти сертификаты, скомпрометирован, у вас все еще есть проблемы.Даже то, что сервер подписывает ключи, как предложено выше, не является надежной защитой, если сам сервер скомпрометирован.В конечном счете, безопасность, если ваш сервер распространения ключей должен поддерживаться этой системой для работы.

...