6. Хранение и распределение ключевой информации

1. Типовые схемы хранения ключевой информации

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

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

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

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

Базу данных аутентификации в КС необходимо защищать от двух основных видов угроз.

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

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

В ОС типа UNIX защита от подобных угроз реализуется путем соответствующего определения дискреционной политики безопасности.

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

2. Угрозы исследования содержимого базы данных аутентификации.

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

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

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

Схема 1. В компьютерной системе выделяется объект-эталон для идентификации и аутентификации. Структура объекта-эталона может быть представлена в виде таблицы 6.1.

Табл. 6.1. Первая типовая схема хранения ключевой информации

Номер пользователя	Информация для идентификации	Информация для аутентификации
1	ID1	E1
2	ID2	E2
…	…	…
N	IDN	EN

E_i=F(ID_i,К_i), где F – некоторая функция хэширования. При этом, зная E_i и ID_i вычислительно невозможно восстановить K_i.

Таким образом, в базе данных аутентификации вместо эталонных паролей K_i хранится результат их одностороннего преобразования. В качестве односторонней функции для хэша NTLM в Windows NT используется алгоритм хэширования MD4.