Идея использования статических пар ключей действительно заключается в том, что данные в обмене ключами подписываются. Не имеет большого значения, что будет подписано, если противник не может выполнить обмен ключами.
Для проверки подписи необходимо, чтобы открытый ключ подписавшего был доверенный. Это то, чего вам не хватает в описании. Если верификатор принимает только этот один ключ или один набор ключей, то подпись злоумышленника отклоняется, проверка подписи завершается неудачно, и ключи не устанавливаются и не используются.
Следующей проблемой становится то, как доверять открытому ключу. Это не является частью протокола ключевого соглашения. Один из способов — явно доверять одному открытому ключу, например, путем проверки отпечатка пальца открытого ключа по телефону. Также может случиться так, что ключ загружен по доверенному каналу; это то, что, например, часто выполняется с открытыми ключами SSH.
Для TLS доверие устанавливается путем доверительных (корневых) сертификатов центров сертификации. Затем они несут ответственность только за создание сертификатов для объектов, которые могут показать, что они контролируют определенный домен. Эти сертификаты содержат этот домен, а также открытый ключ, используемый для проверки. Эта структура называется PKIX: инфраструктура открытых ключей с использованием сертификатов X.509 и списков отзыва сертификатов.
Некоторые примечания:
- Я удалил любое упоминание об алгоритмах согласования ключей или генерации/проверки подписи - используемые алгоритмы не важны для этого вопроса.
- Также можно доверять (статическому) открытому ключу Диффи-Хеллмана, но вы потеряете прямая секретность - если произойдет утечка долгосрочного закрытого ключа этой пары ключей, злоумышленник может воспроизвести соглашение о ключах и расшифровать все сообщения (и это также усложняет PKI).
- Генерация подписи — это не то же самое, что подписание сообщения или хэша сообщения, а проверка — это не то же самое, что «расшифровка с помощью открытого ключа» — открытый ключ Диффи-Хеллмана будет просто отправить в ясном виде вместе с подписью над ним.
- После установления сеанса может потребоваться дополнительный контроль доступа, поэтому сертификат, используемый для создания соединения, часто передается серверной части и используется в какой-либо системе управления доступом.
