Противодействие активному перехвату открытых ключей

← →
xayam © (2010-06-11 17:47) [0]

http://ru.wikipedia.org/wiki/Файл:Криптосистема_с_открытым_ключом_и_активным_перехватчиком.png
В этой модели Ева перехватывает открытый ключ e, посланный Бобом Алисе. Затем создает пару ключей e" и d", «маскируется» под Боба, посылая Алисе открытый ключ e", который, как думает Алиса, открытый ключ, посланный ей Бобом. Ева перехватывает зашифрованные сообщения от Алисы к Бобу, расшифровывает их с помощью секретного ключа d", заново зашифровывает открытым ключом e Боба и отправляет сообщение Бобу. Таким образом, никто из участников не догадывается, что есть третье лицо, которое может как просто перехватить сообщение m, так и подменить его на ложное сообщение m". Это подчеркивает необходимость аутентификации открытых ключей. Для этого обычно используют сертификаты.
Можно ли обойтись без третьей стороны, подписывающей сертификат?
В примерно таком протоколе обмена между сервером и клиентом на основе xml, где открытые сеансовые ключи уязвимы:
<message> <key>Передача открытого ключа от клиента к серверу (сразу после подключения, иначе от сервера вернется ошибка type=1) и от сервера клиенту (сразу после получения сервером ключа игрока); После такого обмена ключами взаимодействие должен осуществляться через тег crypt(body, signature), остальные теги нужно игнорировать. Содержимое тега body всегда подписывается цифровой подписью, которая создается с помощью закрытого ключа Отправителя и помещается в тег signature. После этой операции содержимое тега crypt шифруется открытым ключом Сервера при передаче данных на Сервер от Клиента и открытым ключом Клиента при передаче с Сервера. После этого Получатель должен: 1) расшифровать содержимое тега crypt с помощью своего закрытого ключа. 2) выполнить проверку соответствия содержимого тега body и его цифровой подписи в теге signature TRUE. Если проверка прошла успешно, то Получатель должен обработать все запросы query от Оправителя, описанные в теге body, и отослать Отправителю ответы в теге answer, то Клиент должен дополнительно обработать все события, описанные в теге event. FALSE. Если проверка не удалась, то Сервер должен отослать Клиенту ошибку type=2 </key> <error type="1">Нужно указать Ваш открытый ключ!</error> <error type="2">Содержимое тега body не соответствует цифровой подписи! Возможно сообщение было искажено при передачи по сети.</error> <crypt> <body> <answer id="ID запроса" type="getrooms | "> <error type="0 - ОК (запрос успешно выполнен); 1 - нужен тег key (при передаче открытого ключа); 2 - cодержимое тега body не соответствует цифровой подписи! Возможно сообщение было искажено при передачи по сети. 3 - Неправильная структура тега query; 4 - в теге login допускается использование только латинских букв, тире, подчеркивания и цифр; 5 - обнаружен пустой тег (login и/или password и/или email, если он должен быть указан); ..."> Описание ошибки </error> <rooms>Ответ на запрос getrooms <room id="ID комнаты1">Название комнаты1</room> <room id="ID комнаты2">Название комнаты2</room> <room id="ID комнаты..">Название комнаты..</room> <room id="ID комнатыN">Название комнатыN</room> </rooms> </answer> <query id="ID запроса, формируется отправителем" type="newplayer | remindpassword | logon | getrooms"> <newplayer> <login>Логин (латинские буквы, тире, подчеркивание, цифры)</login> <password>Пароль</password> <name>Фамилия Имя Отчество</name> <email>Электронная почта (необязательный тег, необходимо указать, если хотите иметь возможность восстанавливать пароль и/или получать уведомления от администрации сервера)</email> <birthday>ГГГГ.ММ.ДД (необязательный тег)</birthday> <description>Дополнительная информация о пользователе</description> </newplayer> <remindpassword>Восстановление утерянного пароля на email <login>Логин (латинские буквы, тире, подчеркивание, цифры)</login> <email>Электронная почта</email> </remindpassword> <logon>Вход на сервер <login>Логин (латинские буквы, тире, подчеркивание, цифры)</login> <password>Пароль</password> </logon> </query> <event type="">События, передаваемые от сервера клиенту при игре или входе/выходе в/из комнату/ы игрока </event> </body> <signature>Цифровая подпись тела сообщения (содержимое тега body), создается с помощью закрытого ключа Отправителя</signature> </crypt> </message>
Клиент и Сервер имеют открытый исходный код.

← →
Empleado © (2010-06-11 18:05) [1]

Аппараты Watchuard давно позволяют читать https траффик, активно работая с сертификатами.
Принцип немного другой, зато кайф :)

А в чем вопрос-то?

← →
Kerk © (2010-06-11 18:09) [2]

> Empleado © (11.06.10 18:05) [1]
>
> Аппараты Watchuard давно позволяют читать https траффик,
> активно работая с сертификатами.

А как?

← →
xayam © (2010-06-11 18:13) [3]

> Empleado © (11.06.10 18:05) [1]
> активно работая с сертификатами.
> А в чем вопрос-то?

как обойтись без сертификатов?

← →
xayam © (2010-06-11 18:16) [4]

т.е. как проверить, что открытый ключ пришел именно от того пользователя, который знает пару login/password для доступа к серверу, без использования сертификатов.

← →
xayam © (2010-06-11 18:32) [5]

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

← →
Медвежонок Пятачок © (2010-06-11 20:15) [6]

Можно ли обойтись без третьей стороны, подписывающей сертификат?

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

Третья сторона в этом случае не нужна.

Сервер верит только тем клиентам, в которых уверен.
А клиент либо доверяет серверу, либо не работает с ним.

← →
xayam © (2010-06-11 22:30) [7]

а исходники нельзя подписать серверным сертификатом?

← →
Медвежонок Пятачок © (2010-06-11 22:42) [8]

в каком смысле подписать исходники?

← →
Медвежонок Пятачок © (2010-06-11 22:51) [9]

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

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

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

Если боб повелся на этот запрос и выпустит сертификат на основе поддельного запроса, то получится следующее:

у третьего лица ест его приватный ключ и сертификат в котором написано, что он принадлежит алисе. Причем паблик и приват ключи бьют меж собой.

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

← →
xayam © (2010-06-11 23:00) [10]

> Медвежонок Пятачок © (11.06.10 22:42) [8]
> в каком смысле подписать исходники?

вот допуcтим такая ситуация. Сервер и Клиент пишет одна организация. Весь код и Сервера, и Клиента выкладывает для всех, не ограничивая его использование/изменение/распространение. НО. Если с помощью клиента пользователь подключается к исходному Серверу этой самой организации (теоретически программу можно установить на любой сервер), то у Сервера организации появляется такая задача-проблема: определить с помощью его исходников идет подключение или нет (исходники изменены/переписаны с нуля)? Вот для этого в принципе и нужно как-то "подписать" исходники (php)

> там описан не сам сеанс а момент когда издателю сертификата
> приходит запрос на выпуск сертификата

это ты где вычитал такое?

это ты где вычитал такое?

я не вычитал, я не теоретик.
я лет 10 как проектирую подобные системы.
и до сих пор ни одной осечки не было.

если сервер и клиент самописный, и серверная сторона занимается выпуском клиентских сертификатов, то проблемы вообще нет.

главное для вас - это принять запрос на выпуск клиентского сертификата от того, кто действительно является тем, на кого выпускается сертификат.

когда дойдет дело до информационного обмена, то на сервер придет посылка зашифрованная в адрес сервера и подписанная клиентом.

из этой посылки тебе будет доступно:
- имя издателя клиентского сертификата
- отпечаток (хеш) сертификата издателя.
- имя владельца и отпечаток клиентского сертификата.

этого достаточно чтобы убедится, что автор посылки обладает сертификатом, который был выпущен сервером.

> Медвежонок Пятачок © (11.06.10 23:08) [11]
> я не вычитал, я не теоретик.
> я лет 10 как проектирую подобные системы.
> и до сих пор ни одной осечки не было.
> Медвежонок Пятачок © (11.06.10 22:51) [9]
> по приведенной цитате из педивикии описано нечто иное. там
> описан не сам сеанс а момент когда издателю сертификата
> приходит запрос на выпуск сертификата

????

> если сервер и клиент самописный, и серверная сторона занимается
> выпуском клиентских сертификатов, то проблемы вообще нет.

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

ну фик знает как объяснить.

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

если данные при этом не подписаны, то сервер без понятия кто именно является автором этих данных.

если же данные подписаны, то :
сервер проверяет эцп и делает вывод о их целостности.

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

Но этого тоже мало.

Допустим я еще спер логин и пароль у легального участника системы.
Формирую посылку серверу, указываю логин и пароль.

Сервер расшифрует посылку, проверит эцп, получит логин и пароль.
И все будет в норме как и у любого другого участника системы.

Но если сервер посмотрит данные сертификата которым все это было подписано, то он увидит что:

1. отпечаток моего сертификата не тот, что прописан в свойствах юзера с переданным мной краденым логином

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

вот типа и все.

если точнее, то все еще проще.

я - злоумышленник.
у меня допустим есть :

имя владельца сертификата легитимного участника.
имя владельца серверного сертификата.

я делаю поддельный сертификат, подставляя эти имена в его поля subject и issuer, затем подписываю сертификат своим левым приватным ключом.

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

вот по этому-то атрибуту сервер и в состоянии отличить настоящего участника от поддельного.

Противодействие активному перехвату открытых ключей Найти похожие ветки