Лекции по криптологии / Y38_M01_L21

8

Лекция 21

Прикладные аспекты современных методов КЗИ

Цель данной лекции - изучить схемы аутентификации, предназначенные для поддержки аутентификации и цифровых подписей на прикладном уровне: схему Керберос и сервис аутентификации Х.509.

21.1. Общие сведения.

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

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

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

Для решения этих задач предназначена система Керберос (далее – КВ), которая выполняет функции службы аутентификации. В этой системе для взаимной аутентификации пользователей и прикладных серверов применяется центральный сервер.

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

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

1. Сервер Керберос должен хранить в своей базе данных идентификаторы (UID) пользователей паролей хэш-коды соответствующих паролей.

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

Такая среда называетcя областью (realm).

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

Система Керберос версии 4 требует применения алгоритма DES, а также использования адресации IP. Другие типы сетевых адресов не распознаются.

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

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

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

Функционально сервер Керберос удобно разделить разделяется на два сервера: сервер аутентификации AS и сервер выдачи мандатов TGS (Ticket-Granting Server).

Идею протокола с использованием мандатов поясним на следующем примере.

	Направление	Передаваемые данные	Комментарий
1	От C к AS	IDc, Pc, IDv	C – клиент (пользователь), V – прикладной сервер. Pc – пароль клиента C. IDc – идентификатор клиента C, IDv – идентификатор сервера V.
2	От AS к C	E[AS,V]M	[AS,V] – секретный ключ, общий для AS и V. М – мандат. М= E[AS,V](IDc, ADc, IDv) – зашифрованное на ключе [AS,V] сообщение (IDc, ADc, IDv). ADc – сетевой алрес клиента C.
3	От C к V	IDc, M	Запрос прикладному серверу на предоставление услуг.

В данном сценарии пользователь входит в систему и представляет идентификатор сервера, к которому запрашивает доступ. Сервер AS аутентифицирует пользователя и проверяет, разрешен ли тому доступ к серверу V. Если все в порядке, сервер AS отправляет пользователю мандат, содержащий зашифрованную информацию, предназначенную для сервера V.

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

21.2. Обмен сообщениями по протоколу Керберос версии 4.

	Направление	Передаваемые данные	Комментарий
1	От C к AS	IDc, IDtgs, TS1	Мандат на обращение к TGS. IDtgs - идентификатор сервера TGS. TS – Временная метка (цифровой штамп даты-времени отправки сообщения).
2	От AS к C	E[AS,C]([C,TGS], IDtgs, TS2, Срок1, Мtgs)	Зашифрованное на ключе [AS,C] сообщение. [C,TGS] – ключ, общий для C и TGS. Срок – интервал времени, в течение которого действует мандат, например, 6 часов. Mtgs – мандат, предназначенный для предъявления пользователем серверу TGS. В частности, в нем содержится зашифрованный ключ [C,TGS]. Mtgs = E[AS,TGS] ([C,TGS], IDc, ADc, IDtgs, TS2, Срок1)
3	От C к TGS	IDv, TS2, Мtgs, AUTc	Мандат на получение сервиса. AUTc – т.н. аутентификатор С - действует очень короткое время, предназначен для исключения атак типа воспроизведения информации, перехваченной в предыдущих сеансах связи. AUTc = E[C,TGS]( IDc, ADc, TS3).
4	От TGS к C	E[C,TGS] ([C,V], IDv, TS4, Мv)	Зашифрованное на ключе [C,TGS] сообщение, содержащее мандат Мv для предъявления серверу V и ключ для обмена между C и V. Мv= E[TGS,V] ([C,V], IDc, ADc, IDv, TS4, Срок2).
5	От C к V	Мv, AUTc	Взаимная аутентификация клиента и прикладного сервера. Аутентификация клиента. Мv= E[TGS,V] ([C,V], IDc, ADc, IDv, TS4, Срок2). AUTc = E[C, V]( IDc, ADc, TS5).
6	От V к C	E[C, V](TS25+1).	При необходимости аутентификации прикладного сервера.

Протоколу Керберос версии 5 описан в документе RFC 1510 и содержит ряд усовершенствований, по сравнению с версией 4.

В частности, в мандате присутствует поле флагов мандата, каждый бит которого соответствует тому или иному событию, происшедшему в ходе протокола;

для шифрования можно использовать криптоалгоритм по выбору пользователя, поскольку к шифртексту присоединяется идентификатор системы шифрования;

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

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

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

21.3. Преобразование паролей ключи в системе Керберос 4.

1. В системе Керберос используются символы представимые в семибитовом коде ASCII. Каждый символ исходного пароля W занимает байт (правый крайний разряд байта, в котором хранится символ, не является информационным и равен нулю). Длина n пароля s произвольна.

2. Пароль рассматривается как строка b записанных подряд симибитовых информационных комбинаций. Бит символа s[i] с номером m равен b[7i+m], 0  m  6, 0 i  n-1.

3. Строка b разбивается на блоки по 56 битов, последний блок может быть короче.

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

Затем все блоки складываются по модулю два поразрядно, что дает 56-ти битовый блок, используемый далее как ключ К для алгоритма DES.

4. Пароль W играет роль открытого текста и зашифровывается с помощью алгоритма DES в режиме СВС на ключе К, с вектором инициализации шифртекста Iv=0.

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

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

5. В результате зашифрования пароля W получается 64-битовый блок k, который принимается в качестве ключа, ассоциированного с паролем.

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

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

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

Полагается, что самому первому блоку открытого текста предшествует дополнительный блок открытого текста равный некоторому несекретному блоку – вектору инициализации.

21.4. Служба аутентификации Х.509 v.3.

Рекомендации Х.509 Международного союза телекоммуникаций (ITU) являются частью рекомендаций серии Х.500, которая определяет стандарт службы каталогов.

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

Стандарт Х.509 определяет каркас схемы предоставления услуг аутентификации каталогом Х.500. Первая версия стандарта появилась в 1988 году, третья версия – в 1995.

Каталог Х.500 может осуществлять хранение т.н. сертификатов открытых ключей.

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

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

Рекомендации Х.509 базируются на использовании асимметричной криптографии и рекомендует (но не обязывает) использовать криптосистему RSA.

Главным элементом схемы Х.509 являются сертификаты открытых ключей, характеризующие конкретного пользователя.

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

Это эквивалентно тому, что расшифрование данных можно будет выполнить только секретным ключом нужного адресата.

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

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

Сертификаты выдаются некоторым центром сертификации (Certification Authority – CA), которому доверяют пользователи.

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

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

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

Общий формат сертификата Х.509.

N	Вер- сия	Поле сертификата	Комментарий
1	1,2,3	Версия формата сертификата (1,2,3) По умолчанию – версия Формата =1.	Если задано поле 7 или поле 8, то версия Формата =2. Если к тому же имеются рас- ширения (поле 9) то версия Формата =3 .
2	1,2,3	Номер сертификата.	Целое значение, уникальное в рам- ках данного центра сертификации.
3	1,2,3	Идентификатор алгоритма центра сертификации (объекта, источника) выдавшего сертификат. Эта информация дублируется в последнем поле.	Идентифицирует алгоритм и параметры Для создания подписи сертификата центром сертификации.
		Параметры.
4	1,2,3	Имя центра сертификации (объекта, источника) выдавшего сертификат.	Имя в формате Х.509 центра серти- фикации создавшего и подписавшего сертификат.
5	1,2,3	Не ранее.	Две даты: начала и окончания действия сертификата.
		Не позже.
6	1,2,3	Имя субъекта (пользователя).	Имя в формате Х.509 пользователя, открытый ключ которого удостоверяет данный сертификат.
		Алгоритмы.	Информация об открытом ключе пользова- теля. Алгоритмы и параметры, с которыми должен использоваться этот ключ.
		Параметры.
		Открытый ключ субъекта (пользователя).
7	2,3	IUI (используется редко). Уникальный идентификатор центра сертификации (объекта, источника), выдавшего сертификат.	Необязательная строка битов, однозначно идентифицирующая центр сертификации, выдавший сертификат, в случае, когда его имя в формате Х.509 использовалось для разных объектов.
8	2,3	SUI (используется редко). Уникальный идентификатор субъекта (пользователя).	Необязательная строка битов, однозначно идентифицирующая пользователя, в случае, когда его имя в формате Х.509 использова- лось для разных субъектов.
9	3	Расширения, добавляемые к формату версии 2 (необязательные).	Существенная информация, которую можно разделить на три категории: информация о ключах и политиках безо- пасности, атрибуты субъекта и СА, ограничения маршрута сертификации. Каждое расширение состоит из идентифика- тора расширения, значения расширения и индикатора критичности. Если этот инди- катор имеет значение TRUE, то проверяется корректность значения и включаются пре- дусмотренные ограничения. Например, может быть ограничен срок действия секретного ключа, соответствующего данному открытому (отмена права подписи), разрешено применение других форматов имен (например, для электронной почты), ограничены маршруты сертификации, огра- ничены типы сертификатов, требуется про- верка полномочий центра сертификации…
10	1, 2,3	Алгоритм подписи (идентификатор).
		Параметры.
		Зашифрованный с помощью личного ключа центра сертификации хэш-код всех предыдущих полей.

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

При большом числе пользователей (типичный случай) удобно иметь ряд центров сертификации. Однако при этом пользователи А и В, получившие сертификаты от разных центров сертификации Ха, Хb, не могут предъявлять сертификаты друг другу, поскольку для поверки необходим открытый ключ соответствующего центра сертификации. Этот ключ выдается пользователям при регистрации в виде, защищенном от подделки.

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

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

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

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

Таким образом, возникает иерархическая структура центров сертификации.

Для записи сертификатов и их цепочек в стандарте Х.509 используются условные обозначения, например, сертификат открытого ключа абонента Х, выданный центром сертификации Y, записывается как Y<<X>>, а запись Y{I} означает подпись созданная объектом Y для совокупности данных I. Подпись является зашифрованным хэш-кодом данных (как в ЦП, основанной на криптосистеме RSA).

Удобно читать выражение Y<<X>> как «Y удостоверяет открытый ключ X».

Например, использованная абонентом А цепочка имеет вид Xa<<Xb>> Xb<<B>>.

Цепочка для получения ключа А абонентом В следующая: Xb<<Xа>> Xа<<А>>.

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

Таким образом, существуют сертификаты пользователей и сертификаты центров сертификации. Есть еще третий тип сертификатов: отозванные сертификаты.

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

Каждый центр сертификации поддерживает список отозванных сертификатов (Certificate Revocation List – СRL).

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

Заметим, что система сертификации, рекомендуемая Х.509, не единственная.

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

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

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

Система сертификации, рекомендуемая стандартом Х.509, входит составной частью в стандарт РЕМ (Privacy Enhanced Mail) в котором предусмотрены методы и форматы сообщений для передачи информации (текстовые, мультимедийные, двоичные) а также системы их аутентификации и шифрования.