Key /Config-authentication используется для решения проблемы аутентификации ключей человека (например, «человека А»), с которым общается или пытается общаться другой человек («человек Б»). Другими словами, это процесс обеспечения того, что ключ «человека А», находящийся у «человека Б», действительно принадлежит «человеку А» и наоборот.
Обычно это делается после того, как ключи были переданы обеим сторонам по некоторому защищенному каналу. Однако некоторые алгоритмы делятся ключами во время аутентификации.
Простейшим решением для такого рода проблем является общение двух заинтересованных пользователей и обмен ключами. Однако для систем, в которых имеется большое количество пользователей или в которых пользователи лично не знают друг друга (например, интернет-магазины), это непрактично. Существуют различные алгоритмы как для симметричных ключей, так и для асимметричной криптографии с открытым ключом для решения этой проблемы.
Для аутентификации ключей с использованием традиционной симметричной криптографии ключей это проблема обеспечения того, что нет злоумышленника-посредника , который пытается прочитать или подделать сообщение. Существуют различные алгоритмы, используемые в настоящее время для предотвращения таких атак. Наиболее распространенными среди алгоритмов являются обмен ключами Диффи-Хеллмана , аутентификация с использованием центра распределения ключей , Kerberos и протокол Нидхэма-Шредера . Другие методы, которые могут быть использованы, включают протоколы согласования ключей с аутентификацией паролем и т. д. [1]
Криптосистемы, использующие алгоритмы асимметричного ключа , также не избегают этой проблемы. То, что открытый ключ может быть известен всем без ущерба для безопасности алгоритма шифрования (для некоторых таких алгоритмов, хотя и не для всех), безусловно, полезно, но не предотвращает некоторые виды атак. Например, атака спуфинга, в которой открытый ключ A публично заявляется как ключ пользователя Алисы, но на самом деле является открытым ключом, принадлежащим злоумышленнику-посреднику Маллету , вполне возможна. Ни один открытый ключ не привязан изначально к какому-либо конкретному пользователю, и любой пользователь, полагающийся на дефектную привязку (включая саму Алису, когда она отправляет себе защищенные сообщения), будет иметь проблемы.
Наиболее распространенным решением этой проблемы является использование сертификатов открытых ключей и центров сертификации (CA) для них в системе инфраструктуры открытых ключей (PKI). Центр сертификации (CA) действует как «доверенная третья сторона» для взаимодействующих пользователей и, используя методы криптографической привязки (например, цифровые подписи ), представляет обеим вовлеченным сторонам, что открытые ключи, которые каждая из них держит, которые якобы принадлежат другой, на самом деле таковыми являются. Цифровая нотариальная служба, если хотите. Такими CA могут быть частные организации, предоставляющие такие гарантии, или государственные учреждения, или некоторая комбинация этих двух. Однако в существенном смысле это просто перемещает проблему аутентификации ключа на один уровень назад, поскольку любой CA может добросовестно сертифицировать какой-то ключ, но из-за ошибки или злого умысла ошибиться. Любая зависимость от дефектного сертификата ключа, «аутентифицирующего» открытый ключ, вызовет проблемы. В результате многие люди считают все конструкции PKI неприемлемо небезопасными.
Соответственно, активно изучаются ключевые методы аутентификации.