НОУ ИНТУИТ | Защита информации в электронных платежных системах. Лекция 3: Методы защиты информации в компьютерных системах и сетях

Учитесь и получайте официальные документы БЕСПЛАТНО. Вы можете поддержать наш проект.

Регистрация Вход

Твой путь к знаниям!

Опубликован: 24.10.2016 | Доступ: свободный | Студентов: 1353 / 467 | Длительность: 21:30:00

Темы: Безопасность, Менеджмент

Специальности: Администратор информационных систем, Специалист по безопасности

|

Вам нравится? Нравится 27 студентам

| Поделиться |

Поддержать курс

| Скачать электронную книгу

3.9. Методы аутентификации информации

3.9.1. Идентификация, аутентификация и авторизация

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

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

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

Процесс распознавания законного пользователя в схематичном виде представлен на рис. 3.29.

увеличить изображение
Рис. 3.29. Процессы идентификации, аутентификации и авторизации

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

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

Существуют различные механизмы реализации разграничения доступа. Например, каждому ресурсу (или компоненту) системы может быть сопоставлен список управления доступом ACL (Access Control List), в котором указаны идентификаторы всех пользователей, которым разрешен доступ к данному ресурсу, а также определено, какой именно доступ разрешен. При обращении пользователя к конкретному ресурсу система проверяет наличие у данного ресурса списка управления доступом и, если он существует, выясняет, разрешено ли этому пользователю работать с данным ресурсом в запрошенном режиме. Другим примером реализации механизма авторизации пользователя является профиль пользователя - список, ставящий в соответствие всем идентификаторам пользователей перечень объектов, к которым разрешен доступ данному пользователю с указанием типа доступа. Может быть организована системная структура данных, так называемая матрица доступа, которая представляет собой таблицу, столбцы которой соответствуют идентификаторам всех системных ресурсов, а строки - идентификаторам всех зарегистрированных пользователей. На пересечении i-го столбца и j-й строки таблицы администратор системы указывает разрешенный тип доступа владельца i-го идентификатора к j-му ресурсу.

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

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

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

3.9.2. Аутентификация субъекта

Цель субъекта взаимодействия при аутентификации - доказать верификатору подлинность предъявленного идентификатора.

Классическим средством аутентификации субъекта являются парольные схемы. При этом для устранения последствий несанкционированного доступа противника к информации, хранящейся в памяти компьютера верификатора, хранится не сам пароль PW (password), а его хеш-образ q = h (PW).

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

увеличить изображение
Рис. 3.30. Парольная схема аутентификации, защищенная от повтора

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

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

Проверка подлинности предполагает использование:

неповторяющихся блоков данных, в качестве которых выступают временные метки;
механизма "запрос-ответ";
процедуры рукопожатия (handshake).

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

Механизм "запрос-ответ" предполагает включение пользователем А в сообщение для пользователя В запроса x_A - некоторого случайного числа. Перед ответом пользователь В обязан выполнить над числом x_A некоторую операцию, например вычислить хеш-образ h (x_A) . Получив ответ с правильным результатом вычислений, пользователь А может быть уверен, что В - подлинный. Процедура рукопожатия заключается во взаимной проверке ключей, используемых субъектами взаимодействия. Последние признаются законными партнерами, если докажут друг другу, что обладают правильными ключами. На рис. 3.31 схематично представлен процесс опознания субъекта при задействовании механизма "запрос - ответ".

увеличить изображение
Рис. 3.31. Механизм «запрос - ответ» и процедура handshake

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

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

На рис. 3.32 показана схема процедуры взаимной аутентификации субъектов А и В с использованием доверенной третьей стороны - субъекта С, обладающего секретными ключами $K_{AC}$ и $K_{BC}$ соответственно для взаимодействия с А и В.

увеличить изображение
Рис. 3.32. Схема симметричной аутентификации с доверенной третьей стороной

Протокол Нидхема—Шредера:

субъект А, который хочет взаимодействовать с субъектом В, посылает С сообщение, содержащее идентификаторы субъектов запрашиваемого взаимодействия
$\{ID_A, ID_B\}$ ;
субъект С, получив сообщение,формирует сеансовый ключ KAB для взаимодействия субъектов А и В и посылает А зашифрованное сообщение
$K_{AC}\{ID_B, K_{AB}, K_{BC}\{ID_A, K_{AB}\}\}$ ,

содержащее сеансовый ключ для работы с В и шифровку, которая по сути является разрешением для А на работу с В;
субъект А, расшифровав полученное сообщение, определяет ключ $K_{AB}$ и разрешение
$K_{BC}\{ID_A, K_{AB}\}$ ,

которое он расшифровать не может, так как не знает ключа KBC; после этого А отправляет В сообщение

$K_{AB}\{ID_A, x_A\}, K_{BC}\{ID_A, K_{AB}\}$ ,

содержащее зашифрованный запрос и разрешение, полученное от С;
субъект В, прочитав шифровку
$K_{BC}\{ID_A, K_{AB}\}$ ,

узнает идентификатор субъекта взаимодействия и сеансовый ключ для работы с ним, читает запрос ; после этого В формирует ответ на запрос и отправляет А сообщение
$K_{AB}\{ID_A, h (x_A)\}$ ;
субъект А, получив сообщение, расшифровывает его и проверяет ответ В; в случае положительного результата проверки, процесс аутентификации успешно завершается.

3.9.4. Схема Kerberos

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

увеличить изображение
Рис. 3.33. Схема Kerberos

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

Клиент С, который хочет обратиться к прикладному серверу для получения его услуг, должен получить разрешение от AS. Разрешение - это зашифрованная информация, которую клиент передает серверу S или серверу TGS. Разрешение позволяет серверу убедиться в подлинности клиента. Все разрешения, кроме первого, клиент получает от сервера TGS. Первое разрешение, разрешение на доступ к самому TGS, клиент получает от сервера AS. Разрешение - это шифровка, полученная на секретном ключе, известном только серверу S и серверу Kerberos, поэтому первый, получив разрешение, может быть уверен, что оно поступило именно от сервера Kerberos. Разрешения являются многоразовыми, имеющими определенный срок жизни (несколько часов). Когда этот срок истекает, клиент должен вновь пройти процедуру аутентификации. При установлении каждого соединения используется временная метка, поэтому в сети должна действовать служба единого времени. Необходимость в сервере TGS объясняется стремлением сократить число сообщений, зашифрованных с использованием секретного ключа клиента, которому требуются услуги нескольких серверов. Именно поэтому сервер Kerberos "раздваивается" на сервер AS, с которым клиент взаимодействует при помощи секретного ключа $K_{C, AS}$ , и сервер TGS, с которым клиент осуществляет дальнейшее взаимодействие при помощи только сеансовых ключей $K_{C, TGS}$ . Компрометация сеансового ключа, имеющего очень короткое время жизни, вещь значительно менее опасная, чем раскрытие секретного ключа.

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

Клиент С посылает серверу аутентификации сообщение, содержащее идентификаторы клиента и требуемого сервера выдачи разрешений $ID_{TGS}$ , отвечающего за представление соответствующей услуги, а также информацию , предназначенную для идентификации конкретного запроса: время, свой сетевой адрес и т.п.
Сервер аутентификации осуществляет поиск в базе данных Kerberos по идентификатору клиента и идентификатору услуги, находит соответствующие ключи $K_{C, AS}$ и $K_{AS, TGS}$ , формирует сеансовый ключ $K_{C, TGS}$ для взаимодействия клиента и сервера выдачи разрешений. После этого сервер AS посылает ответ клиенту. Этот ответ содержит две шифровки. Первая, полученная на секретном ключе клиента $K_{C, AS}$ , содержит сеансовый ключ $K_{C, TGS}$ для работы с сервером выдачи разрешений, идентификатор последнего $ID_{TGS}$ и срок жизни $lt_{C, TGS}$ разрешения клиенту на работу с сервером TGS. Вторая шифровка, полученная на ключе $K_{AS, TGS}$ , - это разрешение $T_{C, TGS}$ (ticket-granting ticket) клиенту на взаимодействие с сервером TGS. В состав второй шифровки, которую клиент прочесть не может, так как не знает ключа $K_{AS, TGS}$ , входят идентификаторы и $ID_{TGS}$ , сеансовый ключ $K_{C, TGS}$ и срок жизни этого разрешения $lt_{C, TGS}$ .
Получив сообщение, клиент расшифровывает первую его половину на ключе $K_{C, AS}$ , проверяет отметку , узнает сеансовый ключ $K_{C, TGS}$ и срок жизни разрешения на работу с сервером TGS. Таким образом, в результате обмена сообщениями с сервером AS клиент получает разрешение на работу с сервером TGS. Затем клиент посылает запрос серверу выдачи разрешений. Сообщение для сервера TGS включает в себя две шифровки. Первая, полученная на сеансовом ключе $K_{C, TGS}$ , включает в себя идентификаторы и , идентификатор запроса и временную метку $ts_{C, TGS}$ . Вторая - это "запечатанное" ключом $K_{AS, TGS}$ разрешение $T_{C, TGS}$ .
Сервер выдачи разрешений расшифровывает разрешение $T_{C, TGS}$ , узнает сеансовый ключ $K_{C, TGS}$ , с помощью которого читает первую часть пришедшего сообщения и проверяет идентификатор и временную метку $ts_{C, TGS}$ . Удостоверившись в подлинности клиента, сервер TGS вырабатывает сеансовый ключ $K_{C, S}$ для взаимодействия клиента С и сервера S. На знании этого ключа и будет основываться в будущем взаимная аутентификация C и S. После этого сервер отправляет сообщение клиенту, содержащее зашифрованные на ключе $K_{C, TGS}$ сеансовый ключ и срок жизни разрешения клиенту на работу с сервером, а также само это разрешение $T_{C, S}$ , зашифрованное на секретном ключе $K_{S, TGS}$ .
Клиент, получив сообщение, расшифровывает первую его часть, из которой извлекает сеансовый ключ $K_{C, S}$ для работы с сервером S и срок жизни разрешения на взаимодействие с сервером S. Само "запечатанное" ключом $K_{S, TGS}$ разрешение $T_{C, S}$ клиент прочесть не может. Таким образом, в результате обмена с сервером выдачи разрешений клиент получает разрешение на дальнейшее взаимодействие уже с прикладным сервером. Наконец, клиент посылает серверу S сообщение, содержащее зашифрованные на сеансовом ключе $K_{C, S}$ свой идентификатор , идентификатор и временную метку $ts_{C, S}$ , а также разрешение $T_{C, S}$ , полученное от сервера TGS.
Приняв сообщение от клиента и "распечатав" разрешение $T_{C, S}$ , целевой сервер узнает сеансовый ключ $K_{C, S}$ и с его помощью проводит аутентификацию клиента, проверяя идентификатор и временную метку $ts_{C, S}$ . Ответ сервера клиенту посылается в том случае, когда требуется взаимная аутентификация. Ответ прикладного сервера в этом случае содержит зашифрованный на ключе $K_{C, S}$ результат преобразования $h (ts_{C, S})$ метки $ts_{C, S}$ .

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

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

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

Помимо серверов AS и TGS в системе имеется объект, отвечающий за управление базой данных, называемый диспетчером базы данных Kerberos DBM (Database Manager), а также сервер распространения ключей Kerberos KDS (Key Distribution Server).

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

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

Протокол Диффи—Хеллмана. Несимметричные методы аутентификации могут быть основаны на использовании механизма электронной подписи. Классическим примером несимметричной аутентификации может служить схема Диффи-Хэллмана, представляющая собой совокупность процедуры выработки общего секретного ключа и взаимной аутентификации субъектов взаимодействия. Допустим, w - примитивный элемент поля Галуа GF (p), где p - простое число. Абонент А владеет парой ключей: PK_A - открытым и SK_A - закрытым. Абонент В владеет парой ключей: PK_B - открытым и SK_B - закрытым. Тогда последовательность взаимной аутентификации состоит из трех шагов.

Схема аутентификации Диффи—Хеллмана.

Абонент А вырабатывает случайное число и отправляет абоненту В сообщение

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

сообщения

Затем В вычисляет сеансовый ключ

зашифровывает подпись на этом ключе и отправляет А сообщение

, ,
где
Абонент А вычисляет сеансовый ключ

с помощью своего секретного ключа создает подпись

сообщения

зашифровывает ее на ключе $K_{AB}$ и отправляет В сообщение
Если проверка подписи В абонентом А завершилась успешно, т.е. А убедился в справедливости равенства

он может быть уверен в подлинности абонента В.
Если проверка подписи А абонентом В завершилась успешно, т.е. В убедился в справедливости равенства

он в свою очередь может быть уверен в подлинности абонента А.

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

Для реализации схемы необходим центр доверия, который выбирает и публикует целое число вида N = pq, где p и q - простые числа, которые держатся в секрете. Предположим, абонент А является доказывающим, абонент В - проверяющим. Абонент А (или центр доверия) формирует открытый и секретный ключи:

выбирает m случайных чисел , i = 1, ..., m, и объявляет их секретным ключом ;
вычисляет m чисел , удовлетворяющих условию

и объявляет их открытым ключом PK_A .

Протокол аутентификации Э. Фиата и А. Шамира состоит в t-кратном повторении следующих шагов.

Схема Фиата—Шамира.

Абонент А выбирает случайное число , вычисляет

и посылает его В.
Абонент В выбирает случайную двоичную последовательность
$b_1, b_2, \ldots, b_m, b_j$ {0, 1}, j = 1, ..., m

и посылает ее А.
Абонент А вычисляет

и посылает его В.
Абонент В проверяет равенство

Абонент В принимает доказательство, если проверка закончилась успешно во всех t циклах. Вероятность обмана равна $Ѕ^{mt}$ .

3.9.6. Аутентификация объекта

В процессе аутентификации объекта, иногда называемой аутентификацией источника данных, проверяется подлинность идентификатора, представленного с некоторыми данными. В отличие от аутентификации субъекта в этой ситуации претенденту не нужно быть активным участником процесса аутентификации. Данный тип аутентификации по сути ничем не отличается от процедуры контроля целостности. Для аутентификации объекта применяются шифрование симметричным алгоритмом, выработка кода МАС или НМАС, формирование электронной подписи. Первые два варианта применяются в том случае, когда претендент и верификатор доверяют друг другу. Если необходимо иметь возможность доказательства подлинности идентификатора третьей стороне (при условии, что верификатор не имеет возможности изменить массив данных М), например необходима юридическая значимость пересылаемых электронных документов, требуется электронная подпись.

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

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

Существуют различные механизмы реализации разграничения доступа. Например, каждому ресурсу (или компоненту) системы может быть сопоставлен список управления доступом ACL (Access Control List), в котором указаны идентификаторы всех пользователей, которым разрешен доступ к данному ресурсу, а также определено, какой именно доступ разрешен. При обращении пользователя к конкретному ресурсу система проверяет наличие у данного ресурса списка управления доступом и, если он существует, выясняет, разрешено ли этому пользователю работать с данным ресурсом в запрошенном режиме. Другим примером реализации механизма авторизации пользователя является профиль пользователя - список, ставящий в соответствие всем идентификаторам пользователей перечень объектов, к которым разрешен доступ данному пользователю с указанием типа доступа. Может быть организована системная структура данных, так называемая матрица доступа, которая представляет собой таблицу, столбцы которой соответствуют идентификаторам всех системных ресурсов, а строки - идентификаторам всех зарегистрированных пользователей. На пересечении i-го столбца и j-й строки таблицы администратор системы указывает разрешенный тип доступа владельца i-го идентификатора к j-му ресурсу.

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

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

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

Дальше >>

Авторизоваться

Защита информации в электронных платежных системах

Методы защиты информации в компьютерных системах и сетях