Протоколы, основанные на симметричных криптосхемах

Протоколы, основанные на симметричных криптосхемах делятся на протоколы без центра доверия (двусторонние) и протоколы с центром доверия.

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

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

Самым простым примером этого рода протоколов служит однопроходный протокол между сторонами, А и В, у которых уже имеется долговременный ключ К (табл. 4.15). В результате они вырабатывают новый сеансовый ключ s.

Таблица 4.15

Простой однопроходный протокол обновления сеансового ключа.

Записи протоколов теперь можно упростить, опуская очевидные действия участников: например, достаточно записать, что один из участников зашифровывает некоторые данные и отправляет шифртекст в канал связи — при этом очевидно, что вторая сторона должна его расшифровать и выполнить необходимые проверки извлеченного из шифртекста сообщения.

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

Двухпроходный протокол (табл. 4.16) уже обеспечивает двустороннюю аутентификацию сторон, но для его выполнения участники должны иметь синхронизированные часы.

Простой двухпроходный протокол обновления сеансового ключа.

Протоколы транспортировки ключа методом «запрос — ответ» строятся на основе аналогичных протоколов аутентификации. В табл. 4.17 показан протокол, который обеспечивает одностороннюю аутентификацию методом «запрос — ответ». В нем ключ целиком определяется одним участником — абонентом, А — и транспортируется второму участнику.

Таблица 4.17

Протокол транспортировки ключа методом «запрос — ответ».

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

Таблица 4.18

Протокол транспортировки ключа, построенный на базе «протокола рукопожатия».

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

Среди протоколов этого рода рассмотрим однопроходный протокол (табл. 4.19). В нем сеансовый ключ s вычисляется каждым участником самостоятельно из долговременного ключа и случайного числа, вырабатываемого участником, А в каждом раунде протокола. Правильность вычисления ключа проверяется каждым из участников, но факту получения осмысленной информации в последующих сеансах связи. А может контролировать ключ в этом протоколе, выбирая его в виде r_A = D_K(x). Протокол уязвим к атаке методом повтора сообщений.

Таблица 4.19

Однопроходный протокол выработки производного ключа.

Все рассмотренные ранее протоколы обеспечивали лишь ограниченный набор свойств защиты, будучи подвержены тем или иным атакам. Задача построения доказуемо безопасного протокола распределения ключей без центра доверия была решена М. Белларе (М. Bellare) и Ф. Рогуэем (Р. Rogaway). Ими был предложен протокол АКЕР2 — Authenticated Key Exchange Protocol (протокол аутентифицированного обмена ключами), показанный в табл. 4.20. Здесь h_K — хэш-функция с ключом, h'_K — псевдослучайная перестановка или хэш-функция с ключом.

Доказано, что этот протокол обеспечивает взаимную аутентификацию участников и неявную аутентификацию ключа, т. е. является протоколом аутентичного распределения ключей в смысле введенного ранее определения.

Это единственный в своем роде протокол транспортировки ключей, который, используя только методы симметричной криптографии (но привлекая операцию модульного экспонепцирования),.

Таблица 4.20

Протокол АКЕР2.

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

Таким образом, очевидно, что протоколов без центра доверия существует довольно много, и такое многообразие обусловлено отсутствием одного-единственного «идеального» протокола: в различных ситуациях и различных приложениях бывает удобно использовать разные протоколы.

Рассмотрение протоколов с центром доверия начнем с протокола Нидхэма — Шредера (Needham — Schroeder), предложенного в 1978 г. Он был первым протоколом этого класса, опубликованным в научной литературе. Начальные условия для него таковы: Т — это центр доверия, А и Т имеют общий секретный ключ K_AV В и Т имеют общий секретный ключ К_ВТ N_A — неповторяющаяся ни в одном сеансе протокола величина, чаще всего это случайное число; s — сеансовый ключ, вырабатываемый сервером; А, В — идентификаторы участников протокола. Протокол выполняется следующим образом:

• (1) А —? Т: А, В, N_a,
• (2) Т-А :Е_Кат(М_а, В,8,Е_Квт(8,А)У,
• (3) А-В :E_Kbt(s, A);
• (4) В-A :E_S(N_B);
• (5) А -> В: E?N_B — 1).

Достоинства этого протокола состоят в том, что он обеспечивает взаимную аутентификацию участников, А и В, а также обладает свойством подтверждения ключа (Т является центром распределения ключей).

К недостаткам можно отнести тот факт, что противник имеет неограниченное время для компрометации ключа л Если же ключ 5 скомпрометирован, возможна атака на протокол методом повтора сеанса (берутся сообщения из прошлого сеанса с ключом s*):

• (1) А —? Т: A, B, N_a;
• (2) Т — А: Е_Клт(М_л, В, s, E_Kbt(s, А));
• (3) Е —? В: E_KJs А);
• (4) В -«• Е: E_S.(N_B)-,
• (5) Е —> В: E_S.(N_B — 1).

В выполнении шагов (1) и (2) протокола В не участвует и не видит их. На шаге (3) противник Е подставляет старое сообщение Ек_в7(⁵*, ^) — При выполнении шагов (3)—(5) участник В не имеет никаких гарантий «свежести» ключа, т. е. того, что он был сгенерирован именно в текущем сеансе. Следовательно, Е может участвовать в протоколе с В вместо А.

Если ключ К_АТ скомпрометирован, противник может повторять сеансовые ключи даже после смены участником, А своего долговременного ключа К_АГ> как показано ниже:

• (1) Е-Т:А,?, ЛГ_Л;
• (2) Т — Е: E_kJN_a, В, s E_kJs А)); ^

зная ключ, Е «добывает» N_A, В_у s*, E_Kbt(s*, А), из него берет E_Kbt(s*, А) и подставляет в следующее сообщение:

• (3) Е — В: E_Kbt(s А);
• (4) В — Е: E_S.(N_B);
• (5) Е —? В: E_S.(N_B — 1).

Несколько видоизмененный протокол Нидхэма — Шредера был положен в основу программного средства аутентификации пользователей распределенных вычислительных систем Kerberos, разработанного в Массачусетском технологическом институте в США и получившем широкое распространение. Модифицированный протокол также получил название протокол Kerberos.

В целях исключения возможности осуществления атаки, описанной выше, применяются технические меры. Клиент С, пройдя аутентификацию на сервере аутентификации AS, должен предварительно, до того как ему будет предоставлен доступ к серверам приложений, получить у специального сервера выдачи билетов TGS так называемые билеты — структуры данных, в которых указывается срок полномочий клиента для доступа к серверам приложений. По истечении этого срока клиент должен получать новый билет. Эта мера ограничивает срок, в течение которого возможно осуществить атаку на протокол. Схема взаимодействия участников для протокола Kerberos версии 4 показана на рис. 4.3.

Далее используются следующие обозначения:

с, s, tgs — идентификаторы клиента, сервера приложений и сервера выдачи билетов соответственно;

N_c — не повторяющаяся ни в одном сеансе протокола величина, чаще всего это случайное число;

Рис. 43. Взаимодействие участников протокола Kerberos v.4.

К_с — предустановленный секретный ключ, общий для клиента и сервера аутентификации (чаще пароль клиента, вводимый при входе в систему);

K_s tgs — предустановленный системный секретный ключ, общий для сервера аутентификации и сервера выдачи билетов;

К_с — общий секретный ключ для клиента и сервера выдачи билетов, выдаваемый сервером аутентификации;

К_{с s} — общий для клиента и сервера приложений секретный ключ, выдаваемый сервером выдачи билетов;

k_{c s} — общий сеансовый секретный ключ, вырабатываемый клиентом и сервером приложений;

T_{c t}, Т_{с s} — билеты для доступа клиента к серверу выдачи билетов и к серверу приложений соответственно;

A_c tgs1 A_cs — аутентификаторы клиента для сервера выдачи билетов и сервера приложений соответственно;

t_c, t_t — метки времени, получаемые клиентом и сервером выдачи билетов соответственно;

/, Г — сроки действия билетов.

Спецификация сообщений, передаваемых в протоколе, приведена ниже:

• (1) С -? AS: Су tgSy N_c;
• (2) AS — С: E_K(N, K. _lgK, T_ctgs = {tgs, E_KJc, tgs, t_as, /, K_c tgsM
• (3) C * TGS: A_c rgs = E_Kc J^Cy ?_c,…), 5, T_c tgs;
• (4) TGS — C: E_KcJK_cs> T_cs = {5, E_K$(c_y s_y t_tgs, Г у X,)});
• (5) С — S: A_cs = Е_к (с, t_c9 t_{c sJ}…), T_{c s}]
• (6) * S — C: A_sc = E_KJSy t_c+y k_5C,…).

Шаги (1)—(2) выполняются только во время первого входа клиента в систему. Шаги (3)—(4) выполняются всякий раз, когда клиент С хочет обратиться к новому серверу S. Шаг (5) выполняется всякий раз, когда С проходит аутентификацию для S. Шаг (6) является необязательным и выполняется, когда С требует от S взаимную аутентификацию.

С целью устранения уязвимостей, присущих протоколу Нидхэма — Шредера (и основанных на нем протоколов), был предложен протокол Отвэя — Риза (Otway — Rees). Начальные условия для него таковы: Т — центр доверия, А и Т имеют общий секретный ключ К_АТ, В и Т имеют общий секретный ключ К_вт I обозначает идентификатор сеанса связи, 5 — сеансовый ключ, выработанный в протоколе. Протокол выполняется следующим образом:

• (1) A^B:I, AyByE_K]T(N_vIyAyBy,
• (2) В — Т: /, А, В, Е_Клт(Ы_Ау /, Л, В), E_KJN_B, /, А, В);
• (3) Т —' В: I, E_kJN_a, s), E_kJN_b, s);
• (4) В — А: /, E_KJN_A, s).

Протокол обеспечивает неявную аутентификацию ключа s и дает гарантию его «свежести». Однако он не обеспечивает аутентификацию участников протокола и подтверждение ключа. Для этой цели предложено расширение протокола:

• (4) В — A: E_kJN_a, s), E_S(I, N_B);
• (5) А — В: E?N_B).
• 11а протокол возможна атака методом «смещения доверия с сервера». Пусть Е — другой авторизованный пользователь системы. Он может имперсонифицировать В:
  • (1) А —*• В: /, А, В, E_Kat(N_a, /, А, В);
  • (2) В — Е: /, А, В, E_kJN_a, I, А, В), E_Kbt(N_b, I, А. В);
  • (2*) Е —? Т: /, А, Е, E_KJN_V I, Л, В), E_Kn(N_p I, А, В);
  • (3) Т-Е: I, E_K]i(N_vs), E_Kn(N_ps);
  • (4) Е — Kat (N_a, s).

Атака возможна благодаря тому способу, которым, А выводит заключение об аутентичности В на шаге (4) протокола. А не имеет прямого указания на другого участника, которому Т сделал доступным ключ s, но полагается на случайное число N_A в сообщении (4) и на тот факт, что оно было ассоциировано с В в защищенной части сообщения на шаге (1). Таким образом, А полагается на то, что Т сделал ключ s доступным именно тому участнику В, которого запросил, А на шаге (1). А это может быть гарантировано Т только путем проверки совпадения содержимого полей, записанных в открытой и защищенной частях сообщения, пересылаемого на шаге (2). Наборы величин (/, А, В), трижды повторяющиеся в сообщении.

(2) В — Т: /, А, В, E_kJN_a, I, А, В), E_Kbt(N_b, /, А, В),.

должны быть абсолютно одинаковы. Это условие в явном виде должно проверяться при реализации протокола.

Долгая история конструирования все более стойких протоколов с центром доверия привела к созданию М. Белларе и Ф. Рогуэем доказуемо стойкого протокола аутентичного распределения ключей, получившего название протокол 3PKD — 3-party key distribution. Пусть К_А" ^С — общий секретный ключ шифрования, А и Т, К_в^пс — общий секретный ключ шифрования В и Т, К_А^ас — общий секретный ключ аутентификации, А и Т, К_в‘" — общий секретный ключ аутентификации В и Т. Тогда спецификация протокола имеет следующий вид:

• (1) А —? В: R_a,
• (2) В —> Т: R_a, R_b,
• (3) Т — А: Е_кГ(к), МАС_кГ (А, В, R _v Е_кТШ
• (4) ТВ: E_KT{k), МАС_кГ{А, В, R_B, В,_;г(/ф),

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