Как указано в комментариях под вопросом, RSA обычно не используется в качестве модульного возведения в степень симметричного ключа. Вместо этого либо ключ шифруется с использованием заполнения PKCS#1 v1.5, либо, что предпочтительнее, OAEP, либо общий секрет со случайным значением в диапазоне $\большой[0, N\большой)$ используется для модульного возведения в степень. В последнем случае фактический ключ получается с использованием KDF (функции получения ключа), иногда также называемой просто «PRF» (см., например, TLS 1.2). Это известно как RSA-KEM.
В основном есть два способа избежать подделки ключа с помощью атаки «человек посередине» (MitM):
- установление доверия к открытому ключу RSA;
- проверка общего секрета и/или производных ключей.
Если вы предварительно делитесь открытым ключом статической пары ключей и доверяете ему, тогда у вас будет обмен статическими ключами, т. е. открытый ключ является доверенным, но вы не обеспечите прямую безопасность. Это означает, что каждый последующий симметричный ключ может быть рассчитан, если злоумышленнику известен секретный ключ.
Доверие к открытому ключу можно установить разными способами. Для статической пары ключей можно доверять открытому ключу с помощью PKI. Если вам нужно доверять эфемерному открытому ключу, получатель может подписать его закрытым ключом, который является частью пары ключей, является доверял.
Другой способ — впоследствии проверить установленный сеансовый ключ. Это можно сделать как явно, так и неявно.
При явной проверке общего секрета сторона, расшифровавшая ключ, использует его для генерации MAC по статическим данным, известным обеим сторонам, и отправляет MAC. Теперь эта сторона может быть уверена, что установлен правильный симметричный ключ.
При неявной проверке ключ просто используется для отправки аутентифицированных сообщений туда и обратно. Проверка подлинности этих пакетов указывает на то, что был установлен правильный ключ.
Разумеется, аутентифицируется только та сторона, чей открытый ключ является доверенным. Точно так же, если какой-либо MAC-адрес проверен, это показывает только то, что сторона, владеющая закрытым ключом, смогла расшифровать. Поэтому, если вам нужна аутентификация оставшейся стороны, это нужно обрабатывать отдельно.
В TLS это выполняется путем простого создания другой стороной подписи, которую можно проверить. Это также требует, чтобы открытый ключ этой пары ключей был заранее доверенным; в конце концов, вам всегда нужно установить доверие к чему-либо, прежде чем вы сможете аутентифицировать партию.
Аутентификация клиента TLS почти никогда не используется. Вместо этого он заменяется системами аутентификации или аутентификацией на основе пароля. Либо личность клиента вообще никогда не устанавливается — до тех пор, пока не будет совершена покупка.
Обратите внимание, что аутентификация ключей, установленных с помощью установления ключа RSA, не отличается от установления ключей, например, с помощью Диффи-Хеллмана, хотя в последнем случае необходимо учитывать две пары ключей. В конце концов, можно использовать те же приемы.
