10.4Аутентификация на основе открытого ключа

1 A -> B : K_b^o(A,R_a)

2 A <- B : K_a^o (R_a, R_b,K_ab)

3 A -> B : K_ab(R_b)

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

Передача некоторого случайного числа R, разного с обеих сторон, привязывают сообщения к одному сеансу. Уникальность передаваемых случайных чисел делает невозможной атаку «повторное использование прошлых пакетов».

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

10.5Аутентификация с использованием центра распределения ключей

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

1 А -> KDC : A, B

2 А <- KDC : K_a,kdc (K_ab)

3 KDC -> B : K_b,kdc (K_ab)

Центр распределения ключей некоторым образом заранее договаривается с А и с В об общих ключах. Сеансовый ключ для общения А с В центр распределения ключей отправляет обоим клиентам, но зашифровывает сообщения разными ключами.

В этой схеме есть недостатки. Первый состоит в том, что сообщение с данными, зашифрованными сеансовым ключом, от А к В может придти раньше, чем сообщение В от KDC. В таком случае для В есть два возможных поведения: 1) В хранит сообщение от А, дожидаясь ключа от KDC, 2) В отбрасывает пакет от А. Первый способ совершенно неприемлем в случае большого количества клиентов и пакетов. Второй способ лучше, хотя он, также как и первый, обладает еще одним недостатком: В необходимо хранить большое количество ключей клиентов. Это неожиданно, ведь мы пытались придумать алгоритм, не требующий хранения большого количества ключей.

Рассмотрим схему, в которой KDC передает А сообщение, содержащее сеансовый ключ дважды: один раз – зашифрованный ключом А с KDC, а второй – ключом В с KDC. Эта вторая часть называтся билетом ( в некоторой литературе – талоном). А хранит билет у себя и применяет при обращении к В: вкладывает его в передаваемое сообщение. Снова ключ хранится где-то помимо KDC. Но посмотрите внимательно: во-первых, хранится ключ в зашифрованном виде, а во-вторых, обычно А работает с небольшим количеством серверов, следовательно, хранение ключей для них не требует больших затрат.

1 А -> KDC : A, B

2 А <- KDC : K_a,kdc (K_ab), K_b,kdc (K_ab)

3 А -> B : А,K_b,kdc (K_ab)

Приведенный протокол является вариантом протокола аутентификации Нидхэма-Шредера (Needham – Schroeder). Более точное описание протокола Нидхэма-Шредера предполагает защиту от повторного использования ранее перехваченных пакетов.

1 А -> KDC : A, B, R_a

2 А <- KDC : K_a,kdc (В, R_a, K_ab, K_b,kdc (K_ab))

3 А -> B : K_ab( R_a2),K_b,kdc (А,K_ab)

4 А <- B : K_ab (R_a2-1, R_b)

5 А -> B : K_ab (R_b-1)

Обратите внимание на то, что А привязывает сообщение KDC к своему, передавая случайное число, которое KDC должен вернуть. Таким образом делается невозможной атака злоумышленника, который передает А когда-то ранее перехваченный пакет от KDC. Такая атака имеет смысл для злоумышленника в том случае, если он узнал ключ K_b,kdc, а В, догадываясь о компрометации этого ключа, создал новый ключ. Злоумышленник в результате атаки обманывает А и может общаться с А от имени В. Здесь фактически дважды проведена «подмена доверенного лица». Случайное число, генерируемое А, делает рассмотренную атаку невозможной.

Важно и то, что в возвращаемый KDC пакет вкладывается имя В. Это – защита от следующей атаки. Рассмотрим, что получится, если имя В не вкладывается в пакет. Если Злоумышленник может активно вмешаться в сетевой трафик, то он может подменить в открытом 1-ом сообщении имя В на свое, например, С. Центр распределения ключей выдаст ключ для сеанса А с С. Так что далее А будет передавать сообщения В, но С будет их перехватывать и расшифровывать. Снова атака «подмена доверенного лица».

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