Защита ECDH от MITM-атак - PullRequest
       9

Защита ECDH от MITM-атак

1 голос
/ 02 сентября 2011

Я работаю над проектом, который требует обмена ключами ECDH.Я пытаюсь понять, как защититься от атак MITM.Я могу подписать открытый ключ и отправить подпись вместе с передачей открытого ключа, чтобы гарантировать, что ключ не был подделан, но это не останавливает атаку MITM от того же самого действия.Я понимаю, что обмен ключами должен каким-то образом проверяться третьей стороной, но мне трудно понять, почему третья сторона может быть решением, предполагая, что кто-то может провести MITM-атаку.Почему они не могли просто сделать MITM на сторонней проверке тоже?Есть ли действительно надежный способ полностью устранить все возможные атаки MITM без какого-либо предварительного уведомления обеих сторон?

Ответы [ 3 ]

1 голос
/ 02 сентября 2011

Для подписи обоих ключей требуется доверенное третье лицо.

Без каких-либо знаний или утверждений о личности предполагаемого партнера, просто невозможно отличить его ² от кого-либо еще.

¹ один или несколько ² Боб

0 голосов
/ 09 сентября 2011

Похоже, вы идете по пути развертывания своего собственного крипто-протокола.Не делай этого.Это плохая идея.Это приводит к небезопасным системам.

Вместо этого используйте SSL или TLS.Это сделано для того, чтобы позаботиться о тонких проблемах при разработке такого типа крипто-протокола, и это было тщательно проверено.Вам понадобится способ проверить сертификат другой конечной точки.Вы можете использовать центр сертификации, или в некоторых случаях может быть целесообразно жестко закодировать открытый ключ объекта, с которым вы собираетесь общаться.

Вы можете получить лучшие ответы, если спросите в Crypto стек обмена.

0 голосов
/ 04 сентября 2011

В системе PKI «сертифицирующие органы» являются важной частью инфраструктуры. Сертифицирующие органы подписывают открытый ключ и идентификационную информацию, чтобы вы знали, что соответствующее частное лицо действительно принадлежит к предполагаемой личности. Это верно как для ключей EC, так и для RSA.

Кстати, Я искал CA, которые выдают сертификаты EC, и, видимо, они не используются на практике.

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

Во-первых, у большинства пользователей нет эффективного способа проверки целостности этих сертификатов. Это довольно сложная проблема, потому что в корне у вас должен быть 100% надежный канал для канала проверки - между пользователем и пользователем, с которым злоумышленник не может вмешаться. Когда пользователь загружает новый браузер с коллекцией корневых сертификатов, он не может знать, что программное обеспечение не было подделано при передаче или даже не создано с поддельным сертификатом CA в коллекции.

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

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

...