5.9. Взаимодействие со Службой единого каталога

ЭЦП может быть проверена с использованием соответствующего откры­того ключа. Когда открытый ключ, содержащийся в СЕРТ|ИБ пользователя, представлен в Службе единого каталога, корректность ключа может быть про­верена путём обращения к известному УЦ с запросом о предоставлении его от­крытого ключа (проверить ЭЦП УЦ в сертификате ключа пользователя).

Так как УЦ, выпустивший СЕРТ|ИБ, может изменить свой открытый ключ уже после того, как был выдан СЕРТ|ИБ, необходимо иметь средства для проверки корректности «устаревшего» открытого ключа. А в связи с тем, что обычно известен только тот ключ, который является действующим открытым ключом УЦ, то необходимо наличие связи между действующим открытым ключом и «устаревшими» открытыми ключами. Вследствие того, что получа­тель не осведомлён об изменениях ключей УЦ, ответственность за предостав­ление возможности и способов проверки их «старых» СЕРТ|ИБ несут различ­ные УЦ. Это может быть достигнуто следующими двумя способами:

• путём заверения каждого устаревшего открытого ключа УЦ с помощью действующего открытого ключа УЦ;

• путём заверения каждого устаревшего открытого ключа УЦ с помощью следующего открытого ключа УЦ (применение последовательности (це­почки) сертификатов).

В первом случае существует возможность прямой проверки подлинности устаревшего открытого ключа УЦ, который соответствует закрытому ключу, используемому УЦ для выпуска оригинального СЕРТ|ИБ.

Во втором случае необходимо иметь возможность получения всей це­почки сертификатов для поэтапной проверки подлинности устаревшего откры­того ключа УЦ. Такая проверка будет выполнена путём поиска первого СЕРТ|ИБ, содержащего значение периода его действия, который соответствует дате и времени подписанного сообщения. Затем ведётся последовательный по­иск СЕРТ|ИБ, у которого период действия не перекрывает самый последний период, с целью определения значения предыдущего открытого ключа УЦ.

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

В Службе единого каталога УЦ не сохраняет записи о СЕРТ|СО других УЦ или об их пользователях, когда сроки действия сертификатов истекли. Бо­лее того, пользователь доказательством или ДТС должны накапливать всю не­обходимую доступную информацию (то есть, включающую списки аннулиро­ванных сертификатов, даже если они пустые), чтобы доказать, что конкретный открытый ключ был юридически действующим в некоторый момент времени.

СЕРТ|СО содержит дату своего выпуска УЦ. Кроме этого, он может со­держать и другую дату, которая могла бы оказать содействие при урегулирова­нии споров в некоторых ситуациях: дата, когда пользователь был ещё уверен в том, что его ключ не был скомпрометирован. Все подписи, сформированные пользователем до этой даты, будут определены им как действительные. Если такая дата не указана, полагая, что это наихудший случай, то все подписи, сформированные в течение реального срока действия СЕРТ|ИБ, могли бы рас­сматриваться как недействительные. Это имеет огромное значение в коммерче­ской сфере, особенно это важно для пользователя, подписавшего документ, ко­торый по-прежнему считается действительным, даже в случае, когда ключ, ис­пользуемый для подписи сообщения, был потерян. Несмотря на то, что наличие этой даты в СЕРТ|СО является не обязательным, эта дата будет востребована, если ключ соответствующего сертификата используется СЛНТ.

Доверенные взаимосвязи могут варьироваться со временем. Например, судья может доверять УЦ сегодня, но не обязательно — завтра. Такой тип до­верия должен быть приемлем и для получателя. В этом случае последний дол­жен знать, может ли потенциальный конфликт быть решён в его пользу или нет. Тип доверенных взаимосвязей, который был выбран конкретным судьёй, должен быть выражен точно и недвусмысленно. Такие доверительные условия могут быть смоделированы с использованием следующих терминов надёжно­сти:

• УЦ являются полностью надёжными и для них известен действующий от­крытый ключ;

• УЦ являются надёжными относительно выпуска сертификата УЦ и СЕРТ|ИБ пользователей;

• УЦ являются надёжными относительно выпуска только СЕРТ|ИБ пользова­телей (но не сертификата УЦ).

Таблица 5.2

Структура службы обеспечения неотказуемости		Элемент	Объект/субъект: Субъект доказательства, Объект (средство) формирования доказа­тельства, Объект (средство) проверки подлинности доказательства, Пользователь доказательством, ДТС в роли службы обеспечения неотказуемости, Судья
			Информационный объект: Доказательство
		Цель объектов: сбор, обработка, обеспечение доступности и признание неопровержимости дока­зательства
М Е Р О П Р И Я Т И Я	Объект/субъект	ДТС, Центр безопасности
	Функция	(не определена)
	Мероприятия, связанные с обеспечением процедуры неотказуемости	- Инсталляция; - Модификация;		- Удаление; - Регистрация.
	Объект/субъект	Объект (средство) формирования доказательства			Объект (средство) проверки подлинности доказательства	ДТС в роли службы обеспечения неотказуемости	Судья
	Функция	(не определена)			(не определена)	(не определена)	(не определена)
	Мероприятия функционально связанные с процедурой обеспечения неотказуемости	- формирование доказательства; - формирование нотари­ально заверенного дока­зательства			- формирование доказательства; - формирование нотариально заверенного доказательства	- формирование метки времени; - доставка через ДТС	(не определены)
И Н Ф О Р М А Ц И Я	Входные/выходные элементы данных, определяемые Центром безопасности сетевого сегмента	- Обеспечивающая информация, например, пароль или ключи; - Тип информации; - Политика обеспечения неотказуемости.
	Тип информации, используемой в процедуре обеспечения неотказуемости	- Доказательство; - ЭЦП; - Маркер безопасности; - Сертификат безопасности; - Метка времени.
	Контрольная информация	Запись (регистрация) события для проведения последующей аудиторской проверки и результа­тов урегулирования конфликта; отчёт о взаимосвязях между объектами/субъектами.

Такая информация должна быть свободно распространяемой и доступной для пользователя доказательством. Последний может выбрать форму СЕРТ|ИБ, в которой содержится период действия сертификата. Определены две формы сертификатов политики безопасности: сертификаты политики безопасности, в которых закреплена ответственность судьи за хранение записи о таких серти­фикатах, и сертификаты политики безопасности, в которых закреплена ответст­венность получателя за хранение записи о таких сертификатах.

Общая структура службы обеспечения неотказуемости представлена в форме Таблицы 5.2.

Глава 6.

Теоретические основы обеспечения конфиденциальности

Многие прикладные (открытые) системы ЭМВОС и Интернет-архитек­ту­ры предъяв­ляют определённые требования по обеспечению безопасности, ко­торые зависят от предотвращения раскрытия информации. Такие требования могут включать защиту информации, которая используется для информацион­ного обеспечения других СЛБ, например, СЛАУ, СЛУД или СЛЦЛ. Если же такая информация станет известна нарушителю, то эффективность таких служб обеспечения безо­пасности резко снизится или вообще будет сведена к нулю.

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

В данной главе определены общие основы создания и функционирования служб обеспечения конфиденциальности (СЛКН), а именно:

• базовые концепции обеспечения конфиденциальности;

• возможные классы способов обеспечения конфиденциальности (СПКН);

• классификация и описание средств для каждого класса СПКН;

• процедуры (вспомогательные и функциональные), необходимые для реали­зации того или иного класса СПКН;

• взаимодействие СЛКН и СПКН с другими службами и способами обеспече­ния безопасности.

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

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

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