125 Кібербезпека / 5 Курс / 5.2_Методи побудови і аналізу криптосистем / Література / пiдручник

Протокол обеспечивает защиту только от пассивного противни­ ка и не обеспечивает аутентификацию. В сущности, он решает ту же самую задачу, что и классический, хорошо известный протокол об­ мена ключами Диффи - Хеллмана (о котором мы еще раз напомним в подразд. 2.2.4), но путем транспортировки ключей, а не обмена ключами, и используя для этого три пересылки сообщений вместо

двух.

Рассмотрение протоколов с центром доверия начнем с прото­ кола Needham - Schroeder, предложенногов 1978 г. Он был первым протоколом этого класса, опубликованным в научной литературе. Начальные условия для него таковы: Т - это центр доверия, А и Т имеют общий секретный ключ КАТ, В И Т имеют общий секретный ключ КВТ; NA - неповторяющаяся ни в одном сеансе протокола вели­ чина, чаще всего это случайное число; s - сеансовый ключ, выраба­ тываемый сервером; А,В - идентификаторы участников протокола. Протокол выполняется следующим образом:

(1)А -? Т: »»:

(2)Т7 А : Еклт(Nл,В,«,EKnт(s, А)),

(3)А -? В: EKuг(s, А),

(4)В 7 А: Es(NB ) ,

(5)А -? В: Es(NB -1).

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

К недостаткам можно отнести тот факт, что противник имеет

неограниченноевремя для компрометацииключа s.

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

сключомs*:

(1)А -? Т: А.в.н;

(2)Т-7 А : Еклт(NА'в».EKur (s, А)),

(3)Е -? В: е; (s*, А),

вт

ограничивает срок, в течение которого возможно осуществить атаку

на протокол. Схема взаимодействия участников для протокола Kerberos версии 4 показана на рис. 2.10.

Сервер аутентпфнкашш

(Щ

Сервер б'

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

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

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

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

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

K c•rgs - предустановленный системный секретный ключ, общий для сервера аутентификации и сервера выдачи билетов;

Kc:.rgs - общий секретный ключ для клиента и сервера выдачи би­ летов, выдаваемый сервером аутентификации;

Kc•s - общий для клиента и сервера приложений секретный КЛЮЧ, выдаваемый сервером выдачи билетов;

kc•s - общий сеансовый секретный ключ, вырабатываемый клиен­ том и сервером приложений;

Tc,tg.f' Te,s - билеты для доступа клие1:!та к серверу выдачи биле­

тов и к серверу приложений соответственно;

Ac,tgs, Ас,! - аутентификаторы клиента для сервера выдачи биле­

.тов и сервера приложений соответственно;

te> t,gs - метки времени, получаемые клиентом и сервером выдачи билетов соответственно;

1, ['- сроки действия билетов.

Ниже приведена спецификация сообщений, передаваемых В про­ токоле (обозначения аналогичны тем, что использовались в преды­ дущей спецификации):

(1)С ~ лок. AS: с, tgs, N" ... ,

(2)лок. AS ~ С :

EK~ (N~,Kr,tgs,tns,...), ~./gS =:; {tgs, EK,g, (c,tgs,tns,l, Ko Ks ) } ,

(3)С ~ лок. TGS: Ac,tgs :::: Екщ.,(с,tc,...),tgs - пет. Nc,T(',rgs'

(4)лок. TGS ~ С: Ек"..к>(KC,'8s-геm,tgs - пет,Nc,trss'··.} Т~,/gs-геJII'

(5) С ~ удал. TGS: Ac.,ss-rem' Tc,rgS-ГСIlI' s - пет, N c, ... ,

(6)удал.ТGS ~ С:ЕкcJк,_"щ(Kc.s- rem' s - rem, н..t,gs-rem ,.. .} Tc.s-rem'

(7)с~ удал.S: Ar.s-rcm :::: EKr.s_,.ml (с,tc ' kc,s-rem,"')'

(8)* удал. S ~ С: As-rcm,r :::: ЕК... _иm(s - петл, + 1, ks- rcm,(', ...).

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

Билеты в этом варианте протокола имеют такую структ)'ру:

Tc"ss-rem =:; {tgs - rem, EK't.•_" , (C,tgs -l-em,ttgs,l, K1:,rg-r-геJII)}'

rr

~.s-rl'm ={s - пет;ЕК,_,.... (C,S - rem,trgS_relll,l, Kc.s-rem)}'

с целью устранения уязвимостей, присущих протоколу Needham - Schroeder (и основанных на нем протоколов), был пред­ ложен протокол Otway - Rees. Начальные условия для него таковы: т - центр доверия; А и Т имеют общий секретный ключ КАТ; в и Т имеют общий секретный ключ КВТ; 1 обозначает идентификатор се­ анса связи; s - сеансовый ключ, выработанный в протоколе. Прото­ кол выполняется следующим образом:

(1) А ~ В: I,А,В,Еклт(NA,I,A,B),

134Запечников С. В. Криптографическиепротоколы и их Пр'Lllеllеиllе

(2)В -7 Т: 1, А,В,ЕкАт(NA,I,A,B), EKFfТ(NB,I,A,B),

(3) Т-7 В: I,EK'IT (Nл,s), ЕкlIт(NB,s),

. (4) В -7 А: I,Еклт (Nл,s).

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

предложено следующее расширение протокола:

(4)В-7А: EKAТ(NA,s),Es(I,NB)'

(5)А-7В: Es(NB ) .

На протокол возможна атака методом «смещения доверия с сер­ вера». Пусть Е - другой авторизованный пользователь системы. Он может деперсонифицировать В:

(l)A -7 В: I,A,B,EK,IT (Nл,I,А,В),

(2) В -7 Е: I,A,B,EKАТ (Nл,I,А,В),Екнт (NB,I,A,B),

(2*) Е -7 Т: I,А,Е,Еклт(Nл,1, А,В),ЕкЕ:Г (N Е' I,A,B),

(3) Т-7 Е: I,ЕКАт(Nл,s),ЕКЕТ(NЕ'S)'

(4)Е-7А: I,ЕкАт(Nл,s).

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

(2) В -7 Т: I,A,B,EKАТ (Nл,I,А,В),ЕкffГ (NB,I,A,B),

2. Протоколы. комбинирующие открытое шифрование и цифро­ вую подпись. К этому классу относятся протоколы стандарта ITU Х.509: ОДНОПрОХОДНЫЙ, ДВУХПРОХОДНЫЙ и трехпроходный. Во всех протоколах приняты следующие обозначения: ТА, ТВ - это метки времени, Rh RB - случайные числа, Хл, ХВ - произвольиые данные, для которых требуется обеспечить целостность и подлинность, УА> УВ - произвольные данные, для которых требуется обеспечить еще и

секретность (в том числе это могут быть сеансовые ключи), { ..}к

х

означает зашифровку данных с помощью схемы открытого шифро-

вания участником Х, {"}Гl означает подписание данных участии­

х

ком Х. (Аналогичные обозначения используются в записи после­ дующих протоколов.)

Однопроходный протокол обеспечивает одностороннюю аутен­ тификацию:

(l)A -7 В: А,{тл,RЛ'В'ХЛ'{УЛ}КВ}К,iI'

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

тентификацию:

(2) В -7 А: в,{тв,Rв,А,Rл,хв,{ув}к,JКjjl .

Добавлением еще одной пересылки получается трехпроходный

протокол из этого же стандарта:

(З)А -7 В: A,{B,RB}K-1 '

А

в трехстороннем протоколе полагают ТА = ТВ = О, так как указа­ ние меток времени является избыточным.

Во всех трех протоколах используется либо схема цифровой подписи с восстановлением сообщения, либо предварительное хе­

ширование данных перед подписанием.

Так как участники протокола для формирования сообщений должны знать открытые ключи друг друга, стандартом Х.509 пред­ полагается использование метода сертификации открытых ключей:

до начала выполнения протокола каждый из них должен получить

138 Залечииков С. В. Криптографическиепротоколы и их примененив

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

К этому же классу принадлежит широко известный протокол SSL (Secure Sockets Layer), используемый на сеансовом уровне ком­ муникационной архитектуры TCPIIP. Пусть А - клиент, В - сервер. Клиент желает установить защищенное соединение с сервером. А генерирует сеансовый ключ SAB, который должен стать общим ДЛЯ

клиента и сервера, и инициирует протокол:

(1) А ~ В : {sАВ}К '

в

(2)В ~ А : {NB}SAII'

(3)А ~ В : {CertA.{ NB}K,~1}SЛВ ' где CertA={KA}K':,i .

Приведенная запись соответствует версии 2 протокола SSL. Од- нако на такой протокол транспортировки ключа возможна атака злоумышленника. Пусть Е - другой сервер, находящийся в том же домене, но контролируемый злоумышленником. Тогда Е может про­ вести атаку методом включения в канал, в результате чего будет контролировать трафик между клиентом и сервером:

(6)Е ~ В: {CA,{NB}K;l}КЕВ .

сцелью исключения возможности ее осуществления в версии 3 этого протокола было изменено содержание сообщения, передавае­ мого на шаге (3):

СА