Предотвращение MITM-атак на сервер - PullRequest
6 голосов
/ 17 февраля 2010

Два клиента Алиса и Боб используют сервер для входа и обмена сообщениями через сервер. При входе в систему они оба отправляют свои открытые ключи для хранения на сервере. Когда Алиса хочет поговорить с Бобом, она шифрует симметричный ключ открытым ключом Боба и отправляет его Бобу через сервер.

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

Спасибо

Ответы [ 4 ]

5 голосов
/ 17 февраля 2010

Поскольку Алиса и Боб не могут доверять серверу, они должны найти другой способ подтверждения ключей друг друга. Одна возможность полагаться на другую сторону. Если Боб доверяет Кэндис (и знает открытый ключ Кэндис), который знает Алису, Кэндис может подписать открытый ключ Алисы и затем отправить подписанную версию Бобу. Это называется сеть доверия .

5 голосов
/ 17 февраля 2010

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

И то и другое понимает, что должен означать сертификат Боба. Вы доверяете только тому, что сертификат Боба является сертификатом Боба, потому что тот, кому вы доверяете, сертифицировал его. Этим «кем-то» может быть сам Боб или доверенная третья сторона, которая подписывает сертификат Боба. Вы можете доверять этому столько, сколько доверяете сертификатору.

2 голосов
/ 17 февраля 2010

В криптографии вы - то, что знаете. Если вы хотите избежать MITM, то Алиса должна иметь представление о том, кто такой «Боб», что означает, что Боб должен знать некоторый элемент данных, который злоумышленник не знает. Здесь ваш злоумышленник - это сервер, который идеально расположен для монтирования атаки.

Итак, вопрос в том, кто такой Боб? Как работает сервер "не-боб"?

Например, «Боб» может быть определен как: «Боб - это человек, у которого есть водительские права с надписью« Боб »на нем». Или: «Боб - тот парень, с которым я познакомился в баре и пил пиво».

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

Основным решением является прямой обмен открытым ключом. Когда Алиса встретила Боба в баре, они дали друг другу свои открытые ключи. Таким образом, Алиса может доверять открытому ключу Боба «по определению». Для более легкого обмена (особенно после нескольких видов пива) Алиса и Боб могут обмениваться только «отпечатками пальцев», то есть значениями хеш-функции, вычисленными для открытых ключей. Эти значения короче открытых ключей (например, 128 бит вместо более тысячи бит для типичного открытого ключа RSA) и достаточны для проверки того, что данный открытый ключ соответствует. В этой настройке на сервере есть хранилище для открытых ключей, и Алиса и Боб только пересчитывают отпечатки пальцев, чтобы убедиться, что сервер не играет в фальшивые игры.

Более продвинутым решением, которое устраняет необходимость прямого употребления алкоголя, является использование сертификатов . Сертификат представляет собой ящик, который содержит идентификатор (например, имя, такое как "Bob") и открытый ключ. Поле подписано Удостоверяющим центром (CA): CA утверждает, что открытый ключ действительно принадлежит Бобу, применяя его подпись. Если Алиса знает открытый ключ CA, она может проверить подпись на сертификате, а затем завоевать доверие к связи между открытым ключом и удостоверением, содержащимся в сертификате.

Сертификация - это делегирование доверия. Алиса делегирует свое доверие к СА; предположительно, СА (назовем это Чарли) пошел в бар, чтобы встретиться с Бобом; через сертификат Чарли говорит Алисе: «Да, это действительно ключ Боба, он показал его мне после своей третьей пинты». Здесь все становится немного мрачно, потому что делегировать доверие нелегко (особенно если Чарли имеет привычку пьянствовать). Делегирование может пойти дальше, когда CA подписывает сертификат для другого CA. Здесь Чарли говорит Алисе: «Я не встречал Боба, но я встретил Дафну, которая, возможно, встречалась с Бобом и действовала как CA». Алиса, используя как сертификат, выданный Чарли Дафни, так и сертификат, выданный Дафни Бобу, может проверить, что цепочка подписей.

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

При использовании сертификатов возможны в основном две структуры:

  • Иерархический ЦС: существует один или несколько «корневых ЦС», которые всем известны по построению.CA делегирует другому CA (т. Е. Он подписывает сертификат с использованием в удостоверении обычного флага, который говорит: «этот открытый ключ может быть доверенным для проверки подписей на сертификатах») только в рамках договорного соглашения, которое устанавливает юридическоеобязанности обоих CA в отношении сертификации.Это означает, что делегирование формально определено, и так получается, что это нелегко.Совместимый с адвокатом договор о сертификации, обычно называемый «Заявление о политике сертификации» (CPS), представляет собой документ длиной в 200 страниц.

  • Сеть доверия: каждый действует как CA.В отсутствие «формальной достоверности» каждая отдельная цепочка дает лишь очень небольшое количество доверия.Это должно быть компенсировано огромным количеством.Алиса примет ключ Боба, только если она сможет проверить несколько (много) различных цепочек, которые ведут к Бобу, проходя через разных участников.Например, Алисе потребуются цепочки Чарли-Дафни-Боба, а также цепочки Илия-Фиона-Боб и Джеральд-Хиллари-Иван-Боб.Все они пьяницы, но они могут быть в совокупности надежными, так как фальшивому Бобу придется заплатить много раундов, чтобы повредить одного участника каждой из цепочек, которые использует Алиса (если Алиса требует * 1043)* n цепочки с различными сертификатами, тогда злоумышленник должен испортить как минимум n участников).

Таким образом, сертификационный бизнес в основном является процедурным вопросом:кто такой CA, что CA проверяет перед выдачей (подписанием) сертификата, как все обстоит с юридической точки зрения и так далее.Эти процедуры по своей сути сложны и должны поддерживаться деталями в формате сертификата (например, флаг «этот открытый ключ является ключом CA»).В настоящее время определены два основных стандартных формата: X.509 и PGP .X.509 широко поддерживает иерархическую CA и представляет собой очень запутанную путаницу стандартов, форматов, практик и комитетов.PGP (стандартизированный под названием «OpenPGP») не имеет реальной поддержки иерархического CA;он предназначен для использования с сетью доверия.OpenPGP проще, чем X.509, но более ограничен, особенно если вы хотите иметь сильное юридическое значение для сертификатов.

Для IM-сервера все это может быть излишним.Понятие идентичности, которое действительно хочет Алиса, вероятно, является понятием повторения : «что Боб - это тот же Боб, что и тот, с кем я болтал вчера».Алиса не знает Боба заранее, но разговор с ним однажды устанавливает его личность в глазах Алисы.Она просто хочет, чтобы ее не обманул другой Боб.Для этого простой процесс, такой как «программное обеспечение Алисы, сохраняет объявленный открытый ключ любой новой болтовни и использует его впоследствии».Помните, что ключевой вопрос заключается в том, чтобы правильно определить какое у вас представление о личности.

0 голосов
/ 17 февраля 2010

Если вы не контролируете сервер, вы не можете. Если, конечно, вы уже знаете открытый ключ Боба, но потом ... Я думаю, что у вас проблема с курицей и яйцом.

...