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-ом сообщении имя В на свое, например, С. Центр распределения ключей выдаст ключ для сеанса А с С. Так что далее А будет передавать сообщения В, но С будет их перехватывать и расшифровывать. Снова атака «подмена доверенного лица».

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