Цифровая подпись «человек посередине» для предотвращения атак

У меня на стороне клиента сгенерирована цифровая подпись (JavaScript). Затем подпись проверяется на серверной части Java. Для проверки подписи я передаю на серверную часть - (значение подписи, открытый ключ и сообщение для проверки). Пока все хорошо, но тогда возникает вопрос - а что, если кто-то выполнит атаку "человек посередине"? Он может легко сгенерировать подпись и отправить свою - (значение подписи, открытый ключ и сообщение.). Так что в некотором смысле это делает мою текущую реализацию недостаточно безопасной.

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

Должен ли я сгенерировать сертификат открытого ключа на стороне клиента и отправить его вместе с открытым ключом? Можно ли генерировать самозаверяющие сертификаты на стороне клиента, а затем проверять их на сервере?


certificate client-certificates cryptography digital-signature man-in-the-middle
person Ne7WoRK    schedule 13.04.2019    source источник
comment
Итак, вы спрашиваете, как убедиться, что этот открытый ключ действительно исходит от вашего клиента, верно?   -  person hackape    schedule 13.04.2019
comment
Теперь, прежде чем эта проверка произойдет, как вы определите, что любой запрос к серверу исходит от авторизованного клиента? Должен ли клиент сначала зарегистрироваться, чтобы считаться авторизованным лицом?   -  person hackape    schedule 13.04.2019
comment
Должны быть какие-то правила дискриминации, иначе я мог бы также утверждать, что человек посередине также является действительным клиентом, вы не можете сказать.   -  person hackape    schedule 13.04.2019
comment
@hackape Да, я спрашиваю, как убедиться, что открытый ключ исходит от моего клиента. Что вы подразумеваете под правилами дискриминации?   -  person Ne7WoRK    schedule 13.04.2019
comment
@hackape Является ли SSL / TLS достаточно безопасным, чтобы предотвратить человека посередине?   -  person Ne7WoRK    schedule 13.04.2019
comment
Да, SSL/TLS достаточно для предотвращения MITM.   -  person hackape    schedule 14.04.2019
comment
Под правилами дискриминации я имею в виду, что вам нужна дополнительная информация, чтобы убедиться, что другая сторона заслуживает доверия. Как и в случае с SSL-сертификатом, любой может выдать самозаверяющий сертификат, но как определить, какой сертификат заслуживает доверия? Вы устанавливаете правило, доверяя только тем, которые подписаны CA. Точно так же 3 клиента отправляют запрос на ваш сервер, один из них использует MITM, как узнать? Вы отдаете своим клиентам нечто, заранее недоступное для MITM, общий секрет.   -  person hackape    schedule 14.04.2019
comment
Дело в том, что для предотвращения MITM необходимо заранее провести обмен доверенным образом. В примере с SSL/TLS белый список доверенных центров сертификации обменивается заранее.   -  person hackape    schedule 14.04.2019

Ответы (1)


arrow_upward
3
arrow_downward

Что, если кто-то выполнит атаку «человек посередине»

MITM может заменить подпись и открытый ключ

Как я могу этого избежать?

В основном используйте SSL/TLS и/или...

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

Если вы используете центр сертификации, каждый сертификат подписывается закрытым ключом сертификата корневого ЦС (или субЦС), поэтому MITM не может создать действительный сертификат, поскольку он не владеет корневым закрытым ключом.

На стороне сервера вы можете проверить, что подпись была выполнена с помощью закрытого ключа, соответствующего сертификату, выданному ЦС. Обратите внимание, что в этом случае вы работаете с сертификатами, а не только с открытыми ключами (сертификат заключает в себе открытый ключ).

Я делаю это как последний проект в университете, и я не уверен, как подойти к этой проблеме.

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

Должен ли я сгенерировать сертификат открытого ключа на стороне клиента и отправить его вместе с открытым ключом?

Прочитайте мой предыдущий комментарий

Можно ли генерировать самозаверяющие сертификаты на стороне клиента, а затем проверять их на сервере?

Да, конечно. Вы можете сгенерировать пару ключей на стороне клиента и связать открытый ключ с учетной записью пользователя в процессе регистрации (используя безопасный канал).

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

person pedrofb    schedule 14.04.2019
comment
Можете ли вы указать мне несколько хороших источников о том, как я могу реализовать самозаверяющие сертификаты на стороне клиента? - person Ne7WoRK; 18.04.2019
comment
Начните с самого начала, прочитав об PKI (инфраструктуре открытых ключей) en.m.wikipedia.org/wiki/ Public_key_infrastructure и взгляните на W3C Web Authentication API w3.org/TR/webauthn - person pedrofb; 18.04.2019
comment
@ Ne7Work, твой вопрос закрыт? Вам нужны дополнительные разъяснения? - person pedrofb; 24.04.2019