Способ отправки ключа шифрования через небезопасное соединение?

Я использую утилиту Botan для выполнения шифрования. Когда я инициализирую свое соединение с удаленным компьютером с помощью SSH, я могу обмениваться ключами через безопасное соединение SSH. Однако иногда я использую inetd для установки соединения, и в этом случае соединение inetd не защищено, но мне нужно использовать его для обмена ключами с удаленной машиной.

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

Что может быть примером такого протокола, который поддерживает Botan?


ssh public-key-encryption botan inetd
person WilliamKF    schedule 21.11.2010    source источник
comment
Вам нужно сделать обмен ключами, Диффи-Хеллман или открытый ключ или что-то в этом роде. Нашел это: files.randombit.net/botan/tutorial.pdf генерация пары ключей на странице 12.   -  person AndreKR    schedule 21.11.2010
comment
Проблема здесь классическая MITM: при начальной передаче удаленная сторона не имеет возможности проверить, принадлежит ли полученный ею ключ вашему или злоумышленнику. Если удаленная сторона решит довериться ему, возможно, она доверилась ключу злоумышленника, который затем может перехватить их ответ и подставить свой собственный. Поскольку канал небезопасен, нет возможности проверить, произошло это или нет, используя только этот канал.   -  person Piskvor left the building    schedule 21.11.2010
comment
@AndreKR: вам нужно заранее установить какое-то доверие (или через доверенный канал), иначе все, что вы устанавливаете, это то, что вы общаетесь с одной и той же удаленной конечной точкой при последующих попытках, но DH kex не дает вам никаких гарантий относительно другой стороны, просто позволяет безопасно обмениваться ключами.   -  person Piskvor left the building    schedule 21.11.2010

Ответы (2)


arrow_upward
4
arrow_downward

Без предварительного доверия или общения через побочный канал сделать это невозможно. Kex Diffie-Hellman позволяет вам установить канал, защищенный от других, которые не участвуют в соединении, но вы не можете проверить, что вы общаетесь с предполагаемым получателем.

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

Чтобы быть уверенным, что вы действительно взаимодействуете с предполагаемой конечной точкой, вам необходимо заранее или по защищенному каналу обменяться какой-либо идентификацией хоста. SSH делает это с помощью «отпечатков пальцев» — он спрашивает вас при первом подключении, доверяете ли вы этому хосту, и вы должны проверить отпечаток пальца через независимый канал.

person Piskvor left the building    schedule 21.11.2010

arrow_upward
2
arrow_downward

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

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

Но для этого нужно было что-то делать заранее.

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

Одна статья, которая показалась мне очень полезной в подобных вопросах, называлась *Programming Satan's Computer", http://www.cl.cam.ac.uk/~rja14/Papers/satan.pdf, где вы пытаетесь установить безопасную связь с ненадежным системным администратором.

person James Black    schedule 21.11.2010