Курс лекций по "Информатике"

Конспект лекций по дисциплине

«Программно-аппаратная защита информации»

специальность 090104 «Комплексная защита объектов информатизации»

 

Лекция № 1

Программные и аппаратные механизмы защиты

 

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

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

Программно-аппаратные средства идентификации и аутентификации пользователей

Парольные подсистемы идентификации и аутентификации

 

Реализуются в  открытых компьютерных системах. Являются наиболее распространенными. В качестве идентификации используется Login (имя пользователя), в качестве аутентификации – секретный пароль.

Преимущества: дешевизна, возможность использовать во всех компьютерных системах.

Недостаток: самые  уязвимые ко взлому:

- перебор пароля  в интерактивном режиме;

- подсмотр, кража  из общедоступного места;

- возможность  преднамеренной передачи пароля  другому лицу;

- кража БД учетных записей из общедоступного места;

- перехват вводимого  пароля путем внедрения в КС  программных закладок;

- перехват паролей  передаваемых по сети;

- возможность  применения социального инжиниринга.

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

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

Требования:

1. задавание минимальной длины пароля для затруднения перебора паролей в лоб;
2. использование для составления пароля различных групп символов для усложнения перебора;
3. проверка и отбраковка паролей по словарю;
4. установка максимальных и минимальных сроков действия паролей;
5. применения эвристических алгоритмов, бракующих нехорошие пароли;
6. определение попыток ввода паролей;
7. использование задержек при вводе неправильных паролей;
8. поддержка режима принудительной смены пароля;
9. запрет на выбор паролей самим пользователем и назначение паролей администратором, формирование паролей с помощью автоматических генераторов стойких паролей.

 

Количественная  оценка стойкости парольной защиты

А – мощность алфавита символов, из которых состоит пароль;

L – длина пароля;

V – скорость перебора паролей злоумышленником;

T – срок действия паролей;

P – вероятность подбора паролей злоумышленником за время t, меньшее срока действия паролей

 

 

Лекция №2

Хранение аутентифицирующей  информации в открытых компьютерных системах. Типовые схемы хранения ключевой информации. Защита БД аутентификации.

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

Эту информацию необходимо защищать от 2 основных видов угроз:

- угроза непосредственного доступа злоумышленника к БД аутентификации с целью ее копирования, модификации, удаления;

- угроза несанкционированного изучения БД аутентификации.

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

Поэтому при  защите БДА большее внимание уделяется  защите от несанкционированного исследования их содержимого.

Методы:

1). Шифрование

Такой подход к  закрытию содержимого БД аутентификации не является стойким,  так как:

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

2). Хэширование

Для защиты от исследования БДА используется две типовых  схемы хранения ключевой информации:

Схема 1

Пусть пользователь с N i имеет идентификатор и ключ идентификации , тогда первая типовая схема предполагает наличие в БД аутентификации двух основных полей:

№	Информация для идентификации	Информация  для аутентификации
1	ID1	E1
2	ID2	E2
…
n	IDn	En

 

 – функция хэширования.  Функция  должна удовлетворять следующим свойствам:

1). Необратимостью: восстановить возможно было бы только полным перебором

2). Вероятность  совпадения хэшей 2 произвольно взятых сообщений должна быть чрезмерно мала, если длина сообщения меньше длины хэша, то вероятность должна быть равна нулю.

3) Рассеивание  – при малейшем изменении сообщения  его хэш должен существенным  образом изменяться.

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

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

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

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

Для устранения этого вводится вторая схема аутентификации.

Схема 2

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

№	Информация для идентификации	Информация для аутентификации
1	ID1 , S1	E1
2	ID2, S2	E2
…
n	IDn, Sn	En

 

В этом случае хэши будут различны. Данная схема используется в системах класса Unix.

Утверждение о подмене эталона

Если злоумышленник имеет доступ на запись в БД аутентификации, то он может пройти аутентификацию как любой пользователь КС, отраженный в ней, в том числе и как администратор. Следовательно, доступ на запись в БД аутентификации должны иметь только привилегированные субъекты.

Защита баз  данных аутентификации операционных систем класса Windows NT.

В данных ОС БД аутентификации хранится в каталоге: winnt\system32\config

БДА носит название SAM, а файл System, в котором хранится ключ шифрования БД аутентификации.

В данной БД аутентификации хранится 2 вида хэшей:

- LANMAN, используемый для удаленной сетевой аутентификации с ранних версий Windows;

- NTLM, используется для локальной аутентификации.

 

Алгоритм  вычисления хэша LANMAN

 

Например, если пароль будет состоять из заглавных  букв английского алфавита (26), прописных  букв английского алфавита (26), цифр (10), специальных символов (13), то

Тогда время  подбора     сек

Используя хэш LANMAN, получим, что

Время подбора пароля

Минусы:

- все символы  пароля преобразуются в заглавные,  что уменьшает энтропию паролей,  сокращает пространство их перебора;

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

При выборе паролей больше 14 символов хэши LANMAN из БД исчезают, следовательно, необходимо выбирать пароли из 15-16 символов.

 

Хэш NTLM

 

Хэш NTLM имеет длину 16 байт. Каждому из паролей длины меньшей или равной 16 символов соответствует единственный хэш NTLM, по которому ОС будет определять корректность его ввода пользователем. Однако если выбрать пароли больше 17 символов, то для них найдутся другие с длинной меньше или равной 16 символам, которые будут иметь тот же самый хэш. В этом случае ОС будет пускать пользователя на пароле меньшей длины. Есть вероятность, что длина таких паролей будет очень мала. Поэтому в целях безопасности использование паролей длиной больше или равной 17 символов необходимо запретить. Для ОС, построенных на технологии NT, следует выбирать пароли 15-16 символов.

 

Лекция № 3

Протоколы стойкой удаленной  аутентификации пользователей. Протокол CHAP, S/KEY. Удаленная аутентификация в Windows с использованием хэша LANMAN

 

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

Для разрешения этих проблем требуется:

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

При построении протокола удаленной безопасной передачи для разрешения вышеперчисленных проблем используется 2 подхода:

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

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

Протокол CHAP

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

Протокол использования  одноразовых ключей S/KEY

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

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