Петров А.А. Комп без-ть

•администрация привилегий пользователей в глобальных сетях может потребовать больших временных затрат со стороны администратора.

Все потенциальные угрозы требую т привлечения дополнительны х средств защиты информации в \УеЪ-технологиях. Подходы к обеспечению безопасности в ИВС, построенных по технологии «клиент-сервер», можно условно разделить иа следующие категории:

•создание средств защиты прикладного уровня, направленных на уста­ новление защищенного канала передачи данных между клиентом и сервером. В качестве применяемых решений можно отметить ис­ пользование криптографических протоколов 53 Ь и Р С Т и криптогра­ фических ядер типа «В ерба-О » и «В ерба» (о них уже говорилось ра­

нее). В этом разделе в качестве конечного продукта, предназначенного для установления защищенного канала передачи данных между \УеЪ сервером и \УеЪ клиентом, рассматривается С К З И «Ф о р т »;

•средства защиты, реализующие наряду с установлением защищенно­ го канала передачи данных прикладного уровня разграничение до­ ступа клиентов к защищаемым ресурсам сервера. Оптимальным в дан­ ном случае является использование криптографического протокола КегЬегоз, которому в этом разделе уделено особое внимание. В каче­ стве конечного продукта защиты информации рассматривается сис­ тема Тгиз1:ес1\УеЬ;

•применение средств защиты нижележащих уровней. Например, мож­ но использовать туннелирование трафика при помощи средств защи­ ты информации, являющихся реализацией 5К1Р-протокола. Такое решение позволяет эффективно устанавливать защищенный канал передачи данных, однако реализовать гибкую систему разграничения доступа к защищаемым ресурсам с использованием средств защиты информации подобного типа не представляется возможным.

Эффективность применения перечисленных средств зависит от того,

насколько их реализация удовлетворяет требованиям масштабируемости

иинтегрируемости с существующей инфраструктурой.

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

•ключевую инфраструктуру;

•систему аудита;

•систему администрирования средств защиты.

302 Компьютерная безопасность и практическое применение криптографии

Если говорить о конкретных видах средств, то при использовании средств защиты первого типа наиболее проблематичной представляется организация ключевой инфраструктуры. В случае применения симмет­ ричной ключевой системы управление ключами решается организацион­ ными методами, то есть создаются специальные центры безопасности, ко­ торые и оформляют распределение симметричных ключей, записанных на ключевые носители - дискеты, смарт-карты и 1юисЬ шетогу. Очевид­ но, что данная ключевая структура эффективна только в небольших организациях. Ш ирокое применение криптографических средств защи­ ты информации с симметричными ключами возможно только в случае дополнительного использования асимметричного распределения клю ­ чей. Поэтому проблема организации ключевой системы сводится к орга­ низации разветвленной структуры центров сертификации открытых ключей.

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

3.5.3. Криптографические протоколы, используемые для защиты технологии «клиент-сервер»

В этом разделе описывается архитектура построения, принципы действия, вопросы интеграции и практической стойкости таких известных крипто­ графических протоколов, как КегЬегоз и ЗЗЛ. Завершает раздел сравни­ тельный анализ практического применения этих протоколов для обеспе­ чения защиты информации в технологии «клиент-сервер».

Протокол КегЬегоз у 5

Протокол КегЬегоз используется для аутентификации и обмена ключами, предназначенными для установки защищенного канала связи между або­ нентами, работающими как в локальной сети, так и глобальных сетях. Кег­ Ьегоз разработан для сетей ТСР/1Р и построен на основе доверия участников

протокола к третьей стороне, роль которой выполняет серверная часть КегЬегоз. Создание КегЬегоз велось в рамках проекта «АШ епа» в Массачу­ сетском технологическом университете в середине 80-х годов, и с тех пор этот протокол претерпел ряд принципиальных изменений, которые отра­ зились в существующих ныне пяти версиях.

Основу КегЬегоз составляет протокол Нидхэма-Шредера с третьей дове­ ренной стороной. Служба КегЬегоз, находящаяся в сети, действует как ар­ битр, которому доверяют все участники. КегЬегоз обеспечивает безопасную сетевую аутентификацию пользователей (ресурсов) сети с последующей ав­ торизацией доступа клиента (клиентского приложения) к ресурсам сети. Защищенность установленных в рамках сессии КегЬегоз соединений обу­ словливается применением симметричных алгоритмов шифрования (Б Е З и ряда других алгоритмов, которые могут быть взаимозаменяемы). Основу аутентификации составляет знание абонентом своего декретного пароля (что является результатом хэширования секретного ключа пользователя).

В модели протокола КегЬегоз существуют два основных элемента - клиенты и серверы. Клиентами могут быть пользователи, а также неза­ висимое программное обеспечение, которое нуждается в авторизованных услугах по загрузке удаленных файлов, отправке сообщений или досту­ пу к принтерам либо в получении каких-либо привилегий у администра­ тора. КегЬегоз хранит базу данных о клиентах и их секретных ключах. Наличие в базе данных секретных ключей каждого пользователя и ресур­ сов сети, поддерживающих данный протокол, позволяет создавать за­ шифрованные сообщения, направляемые клиенту или серверу; их успеш­ ное расшифрование и является гарантией прохождения аутентификации всеми участниками протокола.

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

Описание работы протокола

Клиент, желающий пройти аутентификацию и выработать сеансовый ключ для установки защищенного соединения с ресурсом сети, посылает запрос на получение билета предоставления билета (Дске1;-§гап1;т§ Иске!) для службы предоставления билета (ТшкеЪ-Сгапйп^ Зепчсе, Т С З ). Запрошен­ ный билет пересылается пользователю в зашифрованном на секретном ключе клиента виде. Для получения доступа к конкретному серверу в сети клиент посылает полученный билет предоставления билета к серверу ТСЗ. Далее сервер ТС З после успешного прохождения билетом предоставле­ ния билета необходимых проверок высылает клиенту билет на доступ

304 Компьютерная безопасность и практическое применение криптографии

к интересующей его службе. Завершающая фаза состоит в пересылке кли­ ентом билета вместе с аутентификатором (аиИгепБса^ог) целевому серве­ ру и после успешного прохождения проверок клиент может получить от сервера доступ к службам, которые данный сервер предоставляет.

Протокол КегЬегоз поддерживает два типа вверителъиых грамот - биле­ ты и аутентификаторы. Билет используется для обеспечения безопасности при доступе клиента к целевому серверу. Существует большое количество типов билета: начальные, обновляемые, предварительные и недействи­ тельные. Принадлежность билета к тому или другому типу определяется параметрами, установленными в нем. В общем виде билет можно пред­ ставить так:

Тс,з = з, {с,а,у,Кс,з}Кз (см. табл. 3.8)

Таблица 3.8. Перечень сокращений

Билет предоставляется для доступа к строго определенному серверу

ина строго определенное время, причем время начала действия билета мо­ жет быть указано в будущем (предварительные билеты). Он содержит имя клиента, его сетевой адрес, начальное и конечное время действия клиента

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

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

Аутентификатор, используемый в КегЬегоз, имеет следующую форму:

Ас,з = {с4,кеу}Кс,з

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

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

В рамках протокола КегЬегоз у 5 используются следующие сообщения (рис. 3.18):

•от клиента аутентификационному серверу: сф^з;

•от аутентификационного сервера клиенту: {Кс,1:§з}Кс,{Тс,1:§з}К1:§з;

•от клиента к серверу ТОЗ: {Ас,з}Кс,1:§з,{Тс,1:§з}К1;§з,з;

•от сервера ТСЗ клиенту: {Кс,з}Кс,1:§8,{Тс,з}К8;

•от клиента целевому серверу: {Ас,з}Кс,з,{Тс,з}Кз.

После приема первого сообщения аутен­ тификационный сервер КегЬегоз пытается найти пользователя в своей базе данных и в случае, если поиск завершен удачно, со­ здает сеансовый ключ (1 шаг), который будет использоваться клиентом и сервером ТС З, отправляет его клиенту зашифрованным на секретном ключе клиента вместе с билетом предоставления билета (Нске1>§гап1;т§ йскеЪ (Т С Т )) (2 шаг). Т С Т зашифровывается на секретном ключе ТСЗ-сервера и содержит идентификаторы клиента и сервера, сеан­ совый ключ ТСЗ-клиент, а также начальное и конечное время действия ТС Т.

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

ключ и Т С Т в памяти компьютера (что может привести в случае исполь­ зования недоверенной программной среды к их компрометации). Теперь клиент имеет возможность пройти аутентификацию у ТСЗ-сервера при помощи полученного Т С Т и на протяжении времени жизни ТСТ, указан­ ного в нем.

Далее клиент может получить отдельный билет для каждой службы, в которой он нуждается. С этой целыо он должен послать запрос в службу ТС З (на практике программное обеспечение посылает запрос автома­ тически, то есть невидимо для пользователя), который состоит из Т С Т

306Компьютерная безопасность и практическое применение криптографии

иаутентификатора (третий шаг). Служба ТС З при приеме Т С Т расшиф­ ровывает его при помощи своего секретного ключа. Затем ТС З из расшиф­ рованного Т С Т получает сеансовый ключ и расшифровывает аутентифи­ катор. В завершение производится сравнение информации, содержащейся в аутентификаторе, с информацией в ТСТ. Точнее, сетевой адрес клиента в билете сличается с сетевым адресом, указанным в запросе, а также срав­ нивается метка времени с текущим временем.

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

Втом случае, если запрос содержит отвечающий требованиям билет, сервер предоставляет клиенту билет для доступа к целевому серверу. ТСЗ также создает сеансовый ключ для сервера и клиента, зашифрованный на сеансовом ключе клиент-ТСЗ. Оба этих сообщения передаются клиенту, после чего он расшифровывает сообщение, содержащее сеансовый ключ (шаг 4).

Для успешного прохождения аутентификации у целевого сервера кли­ ент создает аутентификатор, зашифрованный на сеансовом ключе «кли ­ ент-сервер», и отправляет его вместе с билетом, зашифрованным на сек­ ретном ключе целевого сервера, который был передан от службы ТСЗ.

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

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

Вопросы безопасности КегЬегоз у5

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

Рассмотрение вопросов практической безопасности следует начать с на­ поминания, что КегЬегоз, как и любое другое программное средство крип­ тографической защиты, работает в недоверенной программной среде. Недо­ кументированные возможности или неправильная конфигурация данной среды может привести к тому, что произойдет утечка критической инфор­ мации, например выход в среду передачи сеансовых ключей, хранящихся на жестком диске, или данных открытой информации. Даже в случае хра­ нения ключей на время сеанса работы пользователя только в оперативной памяти сбой в О С может привести к тому, что ключи будут скопированы иа жесткий диск.

При использовании на рабочей станции с установленным П О КегЬегоз многопользовательского режима или при отсутствии контроля доступа к рабочей станции создается потенциальная возможность внесения про- грамм-закладок или модификации криптографического ПО. Поэтому бе­ зопасность КегЬегоз во многом зависит от надежности защиты рабочей станции, на которой установлен данный протокол.

Что касается самого протокола, здесь необходимо указать на конкрет­ ные уязвимости, которые могут стать причиной успешной удаленной ата­ ки. К ним относятся:

•повторное использование перехваченной информации. Злоумыш лен­ ник имеет возможность перехватывать аутентификаторы и использо­ вать их повторно. Это возможно в течение всего времени действия билета. В аутентификаторе имеется поле метки времени. Кроме того, для защиты от повторного использования следует кэшировать биле­ ты, что, к сожалению, не всегда осуществимо;

•синхронизация часов. Защитные свойства аутентификаторов основаны иа том, что часы субъектов системы жестко синхронизированы. Если сервер может быть введен в заблуждение относительно текущего сис­ темного времени, появляется возможность повторного использования перехваченных аутентификаторов. Ввиду того, что протоколы синхро­ низации часов (Ы ТР и др.) не обладают высокой степенью надежности, это иногда превращается в серьезную проблему;

308Компьютерная безопасность и практическое применение криптографии

•восстановление паролей. Применительно к системе КегЬегоз возможен целый класс атак, направленных на восстановление паролей пользо­ вателей. В самом простом случае злоумышленник может собирать пе­ рехваченные из сети билеты и пытаться дешифровать их. С учетом того, что пользователи обычно выбирают плохие пароли, атакующий, получив достаточное количество материала, имеет хорошие шансы восстановить пароль. Для успешного осуществления этой атаки сбор билетов не является обязательным. В силу того, что начальный запрос посылается в открытом виде, злоумышленник может генерировать его любое число раз и получать зашифрованные на ключе пользователя ТОТ-билеты;

•повторное использование идентификаторов субъектов. Теоретически возможна ситуация, когда новый субъект системы получит тот же идентификатор, которым был снабжен уже выбывший субъект. Если этот идентификатор остался в списках управления доступом какоголибо сервера, новый субъект унаследует права доступа выбывшего. Контроль за корректным удалением субъектов из системы целиком возлагается на администраторов;

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

•область действия билетов и механизм доверия. Реализованный в вер­ сии 5 механизм межкластерной аутентификации также порождает про­ блемы для безопасности. Специфика этого механизма такова, что все участвующие в доверительных отношениях кластеры должны иметь «таблицы маршрутизации» для перенаправления ответов иа запросы

ксерверам аутентификации. Эти таблицы должны быть статически­ ми, и для их настройки требуется какая-то другая защищенная техноло­ гия; что делает КегЬегоз зависимым от другой системы безопасности;

•файлы билетов. В системе ТЖ1Х файл с текущими билетами пользо­ вателя доступен только владельцу (маска доступа 0600). Однако хране­ ние билетов непосредственно на файловой системе открывает доступ

кним любому процессу с соответствующими привилегиями. Альтер­ натива - хранение билетов в памяти - также не является удачным вы­ ходом, так как память подлежит своппингу на диск. Еще более опас­ ной эта ситуация становится при использовании бездисковых машин, осуществляющих доступ к файлам по сети. При реализации КегЬегоз

для \Ушс1оду5 О Т это ограничение может быть легко устранено, так как данная О С обеспечивает механизм блокирования страниц в оператив­ ной памяти, а также позволяет создавать и использовать невыгружае­ мые области памяти.

В заключение хотелось бы отметить, что протокол КегЬегоз является перспективным средством аутентификации. На сегодняшний день он поддерживается в таких крупных проектах, как О ЗР БСЕ, ТОпйо^з О Т 5.0 и РгееВЗБ 2.0. КегЬегоз может использоваться в сочетании с различ­ ными криптографическими схемами, включая шифрование с открытым ключом.

Протокол Весите 8оске^ каует

Основная цель ЗЗЕ-протокола - обеспечить конфиденциальность и до­ стоверность между взаимодействующими приложениями. Данный про­ токол располагается между стеком протоколов ТС Р/1Р и прикладным ПО, обеспечивая тем самым инкапсуляцию трафика прикладного уров­ ня. Основу ЗЗЕ-протокола составляет протокол аутентификации (НапбзЬаке

Р г о 1:о с о 1 ), который позволяет не только удостовериться клиенту и сер­ веру в аутентичности друг друга, но и согласовать используемые алгорит­ мы, и распределить общий сеансовый ключ. Основное достоинство ЗЗЬпротокола - независимость от прикладного ПО.

Таким образом, ЗЗЬ-протокол обеспечивает безопасность сетевого со­ единения, которая основана иа использовании следующих криптографи­ ческих механизмов:

•алгоритмов шифрования, обеспечивающих конфиденциальность со­ единения. С их помощью зашифровываются данные, передаваемые сторонами информационного взаимодействия после успешного про­ хождения аутентификации и ключевого обмена. В рамках ЗЗЬ мо­ гут использоваться такие алгоритмы блочного шифрования, как БЕЗ, КС4 и др., и поддерживаться сразу несколько алгоритмов. Выбор кон­ кретного алгоритма, иа котором будет производиться зашифрование, осуществляется в ходе согласования контекста безопасности;

•двусторонней аутентификации с одновременным распределением сеан­ совых ключей. При этом используются методы асимметричной крип­

тографии (К ЗА, БЗЗ и др.);

•хэш-фуикций (М Б 5, 5И А и др.), которые используются для обеспече­ ния целостности и достоверности передаваемых сообщений на основе генерации МАС-кодов.

310 Компьютерная безопасность и практическое применение криптографии

Описание протокола аутентификации

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

Протокол аутентификационного обмена ключами содержит следую ­ щие шаги:

1.От клиента серверу (СНеп! Ье11о). Клиент пересылает случайное чис­ ло (СНепЕрагат), идентификатор сессии (ЗеззюпГО), список поддер­ живаемых криптографических алгоритмов и список поддерживаемых методов сжатия сообщений.

2.От сервера клиенту (Зегуег Ье11о). Сервер выбирает свое случайное число (Зегуег.рагат), проверяет ЗеззюпГО из сообщений СНеп!: Ье11о (на предмет уникальности, для этого сервер должен хранить список ранее использованных с данным клиентом идентификаторов сессии) и посылает Зегуег.рагат и ЗеззюпГО вместе с выбранным идентифи­ катором криптографического алгоритма и методом сжатия из списков, предоставленных клиентом.

3.От сервера клиенту (Сег1;Шса1;е). Сервер передает клиенту свой сер­ тификат, который кроме открытого ключа подписи может содержать открытый ключ шифрования, а также ряд параметров, используемых для последующего распределения сеансовых ключей, например пара­ метры сервера, в соответствии с протоколом Диффи-Хэлмана.

4.От сервера клиенту (Зегуег кеу ехскап^е). Данное сообщение ис­ пользуется, если оно не имеет сертификата или если сертификат сер­ вера содержит только открытый клю ч подписи. В нем находятся подписанные параметры, использую щ иеся для обмена ключами: 51§п(СНепЕрагат+5егуег.рагат+Рагат) (здесь и далее под знаком + будем подразумевать конкатенацию строк). Содержание Рагат зави­ сит от выбранного типа обмена ключами (К ЗА, РогЕжа или Диффи-

Хэлмана), например: в случае обмена ключами типа Диффи-Хэлмаиа

в нем присутствует значение X = шоб п.

5.От сервера клиенту (СегЕйса1:е гециез!:). В данном сообщении сервер запрашивает у клиента его сертификат.

6.От сервера клиенту (Зегуег ЬеПоБопе). Данное сообщение означает конец передачи данных в рамках протокола ЗЗЬ НапсЫгаке со сторо­ ны сервера.

7.От клиента серверу (СегЬШсаЬе). Серверу пересылается сертификат клиента в случае, если было передано сообщение (СегЕйса1;е гециез1:).