МИСЗКИ книга (1085503), страница 34
Текст из файла (страница 34)
Согласно принятой терминологии субъект и объект называются принципалзми (англ. Рппс)рай), а доверенный сервер называют центром распределения ключей — ЦРК (англ. Кеу Из1г(Ьп11оп Сеп1ег — КОС). 201 ку ЦРК обеспечивает серьезную Работу в распре ределенной сети„в том чис р аут убъ в и объектов, к нему выдвигают ся аутеитифвцируемых субъектов и повышенные тр-""вания -""вания по безопасности: ме енин с контролируе— он должен быть размещен в помещении с ко и цессы, не относящиеся к его пряпосторонние программы и процессы, мой ф;...*' " ф; ... *'иональности; ся для хранения посторонних — он не должен использоваться данных и т.
и. е а ентификации. Клиент хочет Рассмотрим общую схему аугенти . ет т. е. для простоты— . для простоты — ключи симметричного ши рован схема выглядит следующим обр образом: — доверенный сервер генерирует некии сесси нн — шифрует с — шифрует сессио фр ессионный ключ ключом сервера и отправляет серверу. ают единым сессионным ом к ый, с одной стороны, позволяет им доверять друг другу так й стороны, позволяет построить защисионный ключ), с друго стар сое нение для обмена данными.
й в коле КегЬегоз терминологии сессион.) зыпифрованный ключом прин- пала, в— ременной штамп и т. п., зепи рованны ается билетом (англ. 6скег), или манд атом. цнпала, называется иная возможная схема При реализации протокола указанная обеспечения скорости и ввдеж была несколъко усложнена для ч асср ности. Ведь, если клиент уж лучил е по сессионныи ключ, 202 вер из-за особенностей соти сщс нет, то клиент не сможет работать с сервером. С другой стороны, если у доверенного сервера достаточно много клиентов, которые продолжают запрашивать доступ к различным серверам ресурсов, то ему очень часто придется искать в своей базе ключи этих клиентов, а клиенту, соответственно, придется все время держать наготове свой постоянный ключ для связи с доверенным сервером, что небезопасно. В рабочей схеме КегЬегоз доверенный сервер, во-первых, формирует дополнительный билет для доступа клиента к самому доверенному серверу (с другим сессионным ключом).
Теперь клиенту достаточно помнить только этот новый сессионный ключ, а свой основной ключ он может убрать до следующей регистрации на доверенном сервере. Во-вторых, все билеты (как к серверам ресурсов, так и к самому доверенному серверу) отсылаются только клиенту. Теперь уже забота клиента предоставить вместе с запросом на предоставление ресурса и билет для данного сервера. А уж сервер, используя свой постоянный ключ, извлечет из билета сессионный ключ, который будет использовать для работы с клиентом.
Если клиент хочет, чтобы сервер также аугентифицировал себя, он требует от сервера, чтобы тот извлек из клиентского запроса (зашифрованного сессионным ключом) определенные данные (временную метку) и вернул ее клиенту. Таким образом, клиент сможет убедиться, что сервер успешно дешифровал свой билет и, значит, является тем, за кого себя выдает (во всяком случае, по мнению доверенного сервера). Доверенный сервер тоже не должен искать постоянный ключ клиента в базе, клиент сам при новом запросе предоставит ему билет, в котором находится сессионный ключ для доверенного сервера.
В принятой в протоколе КегЬегоз терминологии билет для работы с доверенным сервером называется билетом на получение билетов (англ. 11с1гес-йгап11пй-6с(сеш — ТОТ), а билет для сервера ресурсов — билетом на получение сервиса (англ. 11с1се~- ягап11пя-зепчсе — ТОБ).
Все указанные билеты и связанные с ними ключи действительны только до срока истечения билета или до выхода клиента из сети. Они сохраняются только в оперативной памяти; в т.н. кэш-памяти билетов (англ. сгедеп11а1з 203 сас е) и удаля Ь) ются по истечении срока или окончании работы клиента в сети. Таким образом, работа клиента складывается из следующих шагов, каждый из которых составляет отдельный подпротокол протокола КегЬегоз. 1.
Регис ия в сети: п сети: по отокол «Обмен анными со ой а нти и нн». 1.1. При первой регистрации клиента (пользователя) тре- ( а ный метод преобразования — РЕЗ-СВС-МР5, но момы). Этот ключ, кото- гут ыт б ь использованы н другие алгоритмы). Этот осто . ей рыи считается посто остоянным нлн долговременным (до следующ " смены пароля пользователем), сохраняется в юш-памятн. 1.2. Клиент формирует запрос на аутентификацию (ККВ АЗ КЕΠ— Ке<Ьегоз Ап<Ьеп<1са<1оп Бег<осе Кес)пезс), в ко- торый включаются идентификатор пользователя (для поиска его лужб ыдачи билетов, а также предварительные аугентификационвые данные, которые могут предотвратить ращение злоумышл ышленника за билетом от имени клиента (напри- мер, зашифр в ф о анная ключом клиента временная метка).
КЕ 1.3. Клиент отсылает ЦРК запрос ККВ АЗ Я. зе соответствующий клиенту ключ н проверяет предварительные аутентификационные данные. 1.5. После успешной проверки ЦРК формирует сессион- ный ключ и готовит ответ на запрос клиента, (ККВ АЗ КЕР— КегЬегоз Аи<Ьеп<1са6оп Зег<лсе Кер1у), куда включает копию сес- сионного ключа, зашифрованного ключом клиента, и билет ТОТ, зашифрованный своим постоянным ключом, содержащий еще одну копию сессионного ключа для себя и авторизационные данные клиента.
1.6. Доверенный сервер отсылает клиенту ответ ККВ АЗ КЕР. 1.7. Клиент, получив ответ, дешифрует сессионный ключ, сохраняет ТОТ-билет в юш-памяти, откуда удаляет свой посто- янный ключ. Теперь общаться с ЦРК он будет, используя сесси- онный ключ, л С~6 .,' "'"''" чуи к-серве ес сов:по в токол « ми< Ьии«<мп п < иолу <мин<, сорви а 2.1. К»поит роище< поработать с сервером ресурсов. < этого клнс<п формнрусг запрос ККВ ТОЗ К٠— КегЬС включаются имя пользо Т1СЬег-Огап6пл-Зсг<исс Ке<)ием, куда включаются ванные сесси< тела н аутентификационные данные, зашич ванные нование сервера рес) ным ключом для ЦРК, билет ТОТ, наименование с 2.2.
Клиент отсылает запрос ККВ ТОЗ КЩ доверениоз серверу. 2.3. ПРК, по лучив запрос, извлекает с помощью своего п стоянного ключа сессионный ключ из ТОТ, а с помощью это< сессионного ключа проверяет аутентификационные данные кш енга. 2.4. К ген генерирует второи сессионный ключ для рабоп клиента и сервера ресурсов. 2.5. ЦРК формирует ответ ККВ ТОЗ КЕР— КегЬего Т1С1<ег-Огап<ш -Зе ' е ' я- г<чс Кер!у, куда помещает новый сессионньп ключ, зашифрованный сессионным ключом клиента, и ТОЗ, ко торый состоит из того же нового сессионного ключа, а таю<с< его на сервере данные о клиенте, необходимые для авторизации е ресурсов, — все это зашифровано постоянным ключом сервера ресурсов.
2.б. Доверенный сервер отсылает ответ ККВ ТОЗ КЕР клиенту. 2.7. иент, получив ответ, с помощью своего сессионнора с сервего ключа извлекжт новый сессионный ключ для р боты ром ресурсов и сохраняет его в кэш-памятн вместе с ТОЗ для ТОТ сервера ресурсов. Теперь у клиента есть сессионный кл для доверенного сервера и сессионный ключ и ТОЗ для онный ключ и :' ,сервера ресурсов. ИспОльэоваНИЕ С клиентом н О„'овейр > ~Л Клиент формнр р са о" Ке<)цел'* в который он ш,л „ ПИОННЫЕ даННЫЕ, Зацщф, а Нгн Няа 205 в ТОБ для данного сервера, а такж (о~ цнонвлъно) требование про~э~сети взаимную 3.2. Клиент отправляет запрос сур сов. ес ов с помощью своего постоянного клк~ 3.. Сервер Ресурсов ча извлекает авторизац онные данные для о ТОБ с помощью этог< ч для клиента из сеансового ключа дешифрует ау-тенти ебование взаимнои ауте клиента и проверяет тр ванне присутствует, он вкл ключ лет в отво АР ' ' Ке 1 ) временную метку, АР ВЕР (КегЬегоз Аррйсайоп ер у сессионным ключОм для клиенга.
ответ КВВ АР КЕР клиенту. 3 4. Сервер Отсылает ответ (и проверив м бог ( его подлинности) о убеждается в готовности ер с вера кра е него анные могут шнф аЫту с сервером. При этом данны бо се ве мо ого чом, ли кли вориться о другом ключе. отокола КегЬегоз Ха истики прото заключается в том, ч ~ Одно из преимущ прото есгв поотокола закл ить доступ к сер пересылке данных между го же сервера ресурсов, клиента в качестве такого же ступает для ющего сервис трансляпин и только удал енного и предоставля омственным ему серверам ресурсов.
Щюсов клиента подведОмственным , возможна ситуация, когда к о" 1~К1 доверительных о которой у его 1~ нет (фК обеих областей имеют довере ношений, но (~~К е также может быть аупз с третьим ЦР КЗ. В этом случае клиент " области аутентификации. отокол КегЬегоз служит толъко для аутсл на вере вне своеи пр ( пред ленни кого себя выдает), но не для авторизации о 20б рамках каких прзв клис~гг можсг работать). Однако протокол предусматривасг в билсгс лолс данных, необходимых для применения авторизационных правил системой, в которой клиент будет аутентифицирован. К недостаткам протокола можно отнести необходимость обеспечения синхронизации часов всех участников системы. Протокол Яеспге-НТТР.
Бесиге-НТТР (исполъзуются сокращения 3-НТТР и ЗНТТР) — протокол, разработанный для обеспечения безопасности сообщений при исполъзоваиин протокола НТТР и облегченной интеграции с приложениями, ориентированными на НТТР. Сохраняя все характеристики НТТР, протокол позволяет производить аутентификацию, шифрование, электронно- цифровую подпись сообщений в любой комбинации. При этом протокол поддерживает как криптографическую схему с открытыми ключами, так и симметричную схему шифрования. Протокол поддерживает гибкое определение алгоритмов шифрования с помощью возможности, называемой переговоры о параметрах (англ, орйол пейойайол).
В ней определяются три составлпощих протокола. — Транзакционный модуль — т. е. будет ли запрос н/или ответ зашифрован и/или подписан. — Криптографические алгоритмы — какие алгоритмы будут использованы для шифрования и электронно-цифровой подписи. — Выбор сертификата — какой из цифровых сертификатов использовать. Следует учесть, что как протокол прикладного уровня он защищает Ьгш)-документы, но оставляет открытой информацию нюкележапшх уровней.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
