Иванов М.А. КМЗИ сети

ное выше M' , и тогда пара x2 A , s будет также подписью и для сообщения M '.

6.6.3. Классификация атак на схемы электронной подписи

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

атака на основе известного открытого ключа (key-only attack) – самая слабая из атак, практически всегда доступная противнику;

атака на основе известных подписанных сообщений (knownmessage attack) – в распоряжении противника имеется некоторое (полиномиальное от k) число пар M , s , где M – неко-

торое сообщение, а s – допустимая подпись для него, при этом противник не может влиять на выбор M;

простая атака с выбором подписанных сообщений (generic chosen-message attack) – противник имеет возможность выбрать некоторое количество подписанных сообщений, при этом открытый ключ он получает после этого выбора;

направленная атака с выбором сообщений (directed chosenmessage attack) – выбирая подписанные сообщения, противник знает открытый ключ;

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

Каждая атака направлена на достижение определенной цели. Можно выделить следующие виды угроз для схем электронной подписи (в порядке возрастания силы):

экзистенциальная подделка (existential forgery) – создание противником подписи для какого-нибудь, возможно бессмысленного, сообщения M', отличного от перехваченного;

201

селективная подделка (selective forgery) – создание подписи для заранее выбранного сообщения;

универсальная подделка (universal forgery) – нахождение эффективного алгоритма формирования подписи, функционально эквивалентного S;

полное раскрытие (total break) – вычисление секретного ключа, возможно отличного от kАsecret , соответствующего открытому ключу kАpublic , что дает возможность формиро-

вать подписи для любых сообщений.

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

6.6.4. Процедура разрешения споров

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

щение-подпись была получена от абонента А, который отказывается признавать эту подпись своей. С юридической точки зрения основанием для разрешения подобных споров в суде является подписание (обычным образом) каждым пользователем при подключении к системе специального документа, в котором пользователь принимает все «правила игры», вплоть до судебной ответственности. При разборе дела в суде арбитр выступает в качестве эксперта, дающего заключение о подлинности электронной подписи [4].

202

Алгоритм арбитража

1.Абонент В предъявляет арбитру электронный документ и подпись.

2.Арбитр требует от абонента А предъявления своего секретного ключа. Если А отказывается, арбитр дает заключение, что подпись подлинная.

3.Арбитр выбирает из сертифицированного справочника открытый ключ абонента А и проверяет его соответствие секретному ключу, предъявленному А. Если они совпадают, арбитр переходит к шагу 5.

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

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

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

секретный ключ сформирован не самим абонентом А, а специальным центром генерации ключей; аппаратура, на которой выполняется алгоритм генерации

или проверки подписи, содержит какие-либо элементы, не контролируемые пользователем («черные ящики», защищенные участки памяти и т.п.).

Наконец, возможны безвыходные ситуации, в которых арбитр не может принять никакого обоснованного решения. Например, абонент В предъявляет s и утверждает это подпись под докумен-

203

том M. Абонент А признает, что это его подпись, но под документом M' ζ M, при этом выясняется, что хеш-образы этих документов совпадают, т.е. h M h M' . Арбитр понимает, что

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

6.6.5. Особые схемы электронной подписи

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

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

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

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

схема неоспоримой подписи, в которой подделка подписи может быть доказана.

6.7. Протоколы аутентификации удаленных абонентов

6.7.1. Симметричные методы аутентификации субъекта

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

204

ние симметричных методов требует введения в сеанс связи доверенной стороны, с которой разделяют секретные ключи все пользователи системы. На рис. 6.6 показана схема процедуры взаимной аутентификации субъектов А и В с использованием доверенной третьей стороны – субъекта С, обладающего секретными ключами kAC и kBC соответственно для взаимодействия с

А и В. Последовательность шагов процедуры следующая:

1) субъект А, который хочет взаимодействовать с субъектом В, посылает С сообщение, содержащее идентификаторы субъектов запрашиваемого взаимодействия

IDA, IDB`;

2) С, получив сообщение, формирует сеансовый ключ kAB для взаимодействия субъектов А и В и посылает А зашифро-

ванное сообщение

EAC IDB , kAB , EBC IDA, kAB ,

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

Рис. 6.6. Схема симметричной аутентификации Нидхэма-Шредера с доверенной третьей стороной

205

3) субъект А, расшифровав полученное сообщение, определяет ключ kAB и разрешение

EBC IDA , kAB ,

которое он расшифровать не может, так как не знает ключа

kBC ; после этого А отправляет В сообщение

EAB IDA, xA , EBC IDA, kAB `,

содержащее зашифрованный запрос xA и разрешение, полу-

ченное от С; 4) В, прочитав шифровку

EBC IDA, kAB ,

узнает идентификатор субъекта взаимодействия и сеансовый ключ kAB для работы с ним, читает запрос xA ; после этого В

формирует ответ на запрос h xA и отправляет А сообщение

EAB IDB , h xA ;

5) субъект А, получив сообщение, расшифровывает его и проверяет ответ В; в случае положительного результата проверки, процесс аутентификации успешно завершается.

Рис. 6.6. Схема симметричной аутентификации Нидхэма–Шредера с доверенной третьей стороной

206

6.7.2. Схема Kerberos

Решение задачи аутентификации в современных информационных системах, представляющих собой совокупность реализованных на различных аппаратно-программных платформах территориально разнесенных компонентов, в соответствии с технологией «клиент/сервер» заключается в использовании специального сервера аутентификации. В настоящее время роль фактического стандарта сервера аутентификации выполняет Kerberos, продукт разработанный в Массачусетском технологическом институте (MIT) в середине 1980-х гг. и претерпевший с тех пор ряд принципиальных изменений. Широкому распространению Kerberos способствовало то, что его версия, реализованная в MIT, является свободно распространяемым продуктом. Программные средства, выполняющие аутентификацию по схеме Kerberos, разработаны для всех популярных ОС. Поддержка службы Kerberos предусмотрена в некоторых современных сетевых ОС. Схема Kerberos – типичный пример реализации симметричных методов аутентификации.

Система (рис. 6.7) предусматривает взаимодействие между тремя программными компонентами – клиентом С, сервером Kerberos и прикладным сервером S. ПО сервера Kerberos разделено по своим функциям на две части: сервер аутентификации AS (Authentication Server) и сервер выдачи разрешений (билетов) TGS (Ticket Granting Server). Клиент С – это компьютер, на котором установлено клиентское ПО, способное участвовать во взаимодействии по протоколу Kerberos, и на котором зарегистрирован какой-либо пользователь. В некоторых случаях прикладной сервер может являться клиентом некоторого другого сервера (например, сервер печати может пользоваться услугами файлового сервера). Сервер S – субъект, предоставляющий ресурсы сетевым клиентам.

Клиент С, который хочет обратиться к прикладному серверу для получения его услуг, должен получить разрешение от AS. Разрешение – это зашифрованная информация, передаваемая клиентом серверу S или серверу TGS. Разрешение позволяет серверу убедиться в подлинности клиента. Все разрешения, кроме

207

первого, клиент получает от сервера TGS. Первое разрешение, разрешение на доступ к самому TGS, клиент получает от сервера AS. Разрешение – шифровка, полученная на секретном ключе, известном только серверу S и серверу Kerberos, поэтому первый, получив разрешение, может быть уверен, что оно поступило именно от серверу Kerberos. Разрешения – многоразовые, имеющие определенный срок жизни (несколько часов). Когда этот срок истекает, клиент должен вновь пройти процедуру аутентификации. При установлении каждого соединения используется временная метка, поэтому в сети должна действовать служба единого времени. Необходимость в сервере TGS объясняется стремлением сократить число сообщений, зашифрованных с использованием секретного ключа клиента, которому требуются услуги нескольких серверов. Именно поэтому сервер Kerberos «раздваивается» на сервер AS (с ним клиент взаимодействует при помощи секретного ключа kC, AS ) и сервер TGS, с которым

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

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

Рис. 6.7. Схема Kerberos

208

Процесс аутентификации состоит из пяти (односторонняя аутентификация) или шести (взаимная аутентификация) шагов.

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

2.Сервер аутентификации осуществляет поиск в базе данных Kerberos по идентификатору клиента и идентификатору услуги,

находит соответствующие ключи kC, AS и kAS ,TGS , формирует сеансовый ключ kC,TGS для взаимодействия клиента и сервера вы-

дачи разрешений. После этого сервер AS посылает ответ клиенту. Этот ответ содержит две шифровки. Первая, полученная на секретном ключе клиента kC, AS , содержит сеансовый ключ

kC,TGS для работы с сервером выдачи разрешений, идентификатор последнего и срок жизни разрешения клиенту на работу с сервером TGS. Вторая шифровка, полученная на ключе kAS ,TGS , –

это разрешение (ticket-granting ticket) клиенту на взаимодействие с сервером TGS. В состав второй шифровки, которую клиент прочесть не может, так как не знает ключа kAS ,TGS , входят иден-

тификаторы клиента и TGS, сеансовый ключ kC,TGS и срок жизни

этого разрешения.

3. Получив сообщение, клиент расшифровывает первую его половину на ключе kC, AS проверяет идентификатор запроса, уз-

нает сеансовый ключ kC,TGS и срок жизни разрешения на работу

с сервером TGS. Таким образом, в результате обмена сообщениями с сервером AS клиент получает разрешение на работу с сервером TGS. Затем клиент посылает запрос серверу выдачи разрешений. Сообщение для сервера TGS включает в себя две шифровки. Первая, полученная на сеансовом ключе kC,TGS ,

включает в себя идентификаторы клиента и сервера, идентификатор запроса и временную метку. Вторая – это «запечатанное» ключом kAS ,TGS разрешение на работу с сервером TGS.

209

4. Сервер выдачи разрешений расшифровывает разрешение, узнает сеансовый ключ kC,TGS , с помощью которого читает пер-

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

взаимодействия клиента С и сервера S. На знании этого ключа и основывается в будущем взаимная аутентификация C и S. После этого отправляет сообщение клиенту, содержащее зашифрованные на ключе kC,TGS сеансовый ключ и срок жизни разрешения

клиенту на работу с сервером, а также само это разрешение, зашифрованное на секретном ключе kS,TGS .

5. Клиент, получив сообщение, расшифровывает первую его часть, из которой извлекает сеансовый ключ kC,S для работы с сервером S и срок жизни разрешения на взаимодействие с сервером S. Само «запечатанное» ключом kS ,TGS разрешение клиент

прочесть не может. Таким образом, в результате обмена с сервером выдачи разрешений клиент получает разрешение на дальнейшее взаимодействие уже с прикладным сервером. Наконец, клиент посылает серверу S сообщение, содержащее зашифро-

ванные на сеансовом ключе kC,S свой идентификатор, иденти-

фикатор запроса и временную метку, а также разрешение, полученное от сервера TGS.

6. Приняв сообщение от клиента и «распечатав» разрешение, целевой сервер узнает сеансовый ключ kC,S и с его помощью

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

ключе kC,S результат хеширования метки времени.

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

идентификатор субъекта;

210