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

Приложение С
(рекомендуемое)

Спецификация криптографических функциональных возможностей

С.1 Введение

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

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

Руководство по применению отдельных функциональных компонентов из класса FCS (Криптографическая поддержка) приведено в приложении Е ИСО/МЭК 15408-2. Криптографические функциональные возможности могут использоваться для удовлетворения ФТБ, определенных с использованием других классов и семейств (например, класса FCO и семейств FDP_DAU, FDP_SDI, FDP_UCT, FDP_UNT, FIA_SOS, и FIA_UAU). В этих случаях отдельные функциональные компоненты определяют требования безопасности, которые можно удовлетворить с использованием криптографических функциональных возможностей. Класс FCS следует использовать, если криптографические функциональные возможности ОО востребованы потребителями.

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

Дополнительная информация и руководства по криптографии и криптографическим алгоритмам содержатся в [4] - [9].

С.2 Термины и определения

Терминология, используемая в настоящем приложении, базируется на терминах и определениях, приведенных в подразделе 2.3 ИСО/МЭК 15408-1 и в ИСО 2382-8. В целях обеспечения понимания представленных в настоящем стандарте понятий ниже определен ряд дополнительных терминов.

С.2.1 Режим доступа

Тип операции, определенный некоторым правом на доступ. Примеры: чтение, запись, выполнение, модификация, удаление, создание и т.д. Также см. "Тип доступа" в соответствии с ИСО 2382-8.

С.2.2 Закрытые данные

Данные, информационное содержание которых не доступно напрямую, так как защищено шифрованием.

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

С.2.3 Криптографический алгоритм

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

С.2.4 Криптографическая контрольная сумма

Относительно короткая последовательность, полученная из исходных данных посредством использования криптографического алгоритма, которая представляет собой функцию от данных, секретного ключа и, возможно, вектора инициализации и главным образом прикрепляется к данным для контроля целостности данных. Также см. "Код установления подлинности сообщения" по ИСО 2382-8.

С.2.5 Генерация криптографической контрольной суммы

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

С.2.6 Проверка криптографической контрольной суммы

Процесс генерации криптографической контрольной суммы в целях проверки прикрепленной криптографической контрольной суммы.

С.2.7 Криптографическая функция

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

С.2.8 Криптографические функциональные возможности

Одна или более криптографических функций, реализованных в ОО.

С.2.9 Криптографический ключ

Цифровая последовательность, управляющая выполнением криптографического алгоритма и влияющая на его результат. Также см. "Ключ" по ИСО 2382-8.

С.2.10 Доступ к криптографическому ключу

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

С.2.11 Согласование криптографических ключей

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

С.2.12 Архивирование криптографического ключа

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

С.2.13 Резервное копирование криптографического ключа

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

С.2.14 Уничтожение криптографического ключа

Процесс удаления (обнуления) криптографического ключа.

С.2.15 Распределение криптографических ключей

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

С.2.16 Депонирование (передача на хранение) криптографического ключа

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

С.2.17 Генерация криптографического ключа

Функция создания криптографического ключа.

С.2.18 Управление криптографическими ключами

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

С.2.19 Восстановление криптографического ключа

Процесс восстановления криптографического ключа из какого-либо источника, включая архив, резервную копию или депонент.

С.2.20 Криптографический механизм

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

С.2.21 Криптографическая операция

См. Криптографическая функция.

С.2.22 Криптографическая переменная

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

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

С.2.23 Маршрут данных

Логический или физический маршрут, по которому (или через который) проходят данные.

С.2.24 Цифровая подпись

См. "Цифровая подпись" в ИСО 2382-8.

С.2.25 Генерация цифровой подписи

Процесс генерации цифровой подписи.

С.2.26 Верификация (проверка) цифровой подписи

Процесс проверки цифровой подписи.

С.2.27 Хэширование или значение хэша

См. Безопасная хэш-последовательность.

С.2.28 Вектор инициализации

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

С.2.29 Параметр обращения

"Секрет" (например, пароль или личный идентификатор), который предоставляется ОО для получения доступа к криптографической функции.

С.2.30 Дайджест сообщения

См. Безопасная хэш-последовательность.

С.2.31 Неотказуемость

Невозможность для некоторой сущности отрицать участие во взаимодействии.

С.2.32 Другой критичный параметр безопасности

См. Параметр обращения.

С.2.33 Частный ключ

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

С.2.34 Публичный ключ

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

С.2.35 Публичная ключевая пара

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

С.2.36 Открытые данные

Данные, информационное содержание которых доступно напрямую, потому что не защищено шифрованием.

Например, сообщения, файлы, криптографические ключи и т.д.

С.2.37 Разделение отрытых/закрытых данных

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

С.2.38 Секретный ключ

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

С.2.39 Безопасная хэш-последовательность

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

С.2.40 Зона обнаружения вмешательств

Область, окружающая ОО, в которой вмешательство (нарушение или попытка вторжения) может быть обнаружено.

С.2.41 Обнуление

Метод электронного стирания хранимых данных путем изменения данных таким образом, чтобы первоначально хранимые данные не могли быть восстановлены.

С.2.42 Операции по обнулению

Последовательность электронных операций, направленных на обнуление.

С.2.43 Схема обнуления

См. "Операции по обнулению".

С.3 Краткий обзор криптографии

С.3.1 Понятие криптографии

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

a) генерацию и/или верификацию цифровой подписи;

b) генерацию криптографической контрольной суммы для контроля целостности и/или для проверки контрольной суммы;

c) вычисление безопасной хэш-последовательности (дайджест сообщения или файла);

d) шифрование и/или расшифровывание данных;

e) шифрование и/или расшифровывание криптографического ключа;

f) согласование криптографических ключей.

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

a) конфиденциальность;

b) целостность;

c) идентификацию и аутентификацию;

d) неотказуемость;

e) доверенный маршрут;

f) доверенный канал;

g) разделение данных.

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

С.3.2 Использование криптографии

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

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

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

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

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

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

С.3.3 Использование криптографических стандартов

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

a) стандарт может способствовать установлению общепризнанного приемлемого уровня безопасности;

b) стандарт может способствовать широкому взаимодействию;

c) стандарт может способствовать взаимному признанию;

d) стандарт может требоваться политикой безопасности конкретной организации;

e) стандарт может способствовать реализации необходимых функциональных возможностей.

С.4 Формирование требований безопасности

С.4.1 Покрытие

В разделе C.4 определяются связанные с криптографией аспекты, которые необходимо рассматривать при спецификации угроз, политик безопасности организаций и целей безопасности для ОО, содержащих криптографические функциональные возможности, а также при рассмотрении криптографических потребностей при формировании требований безопасности и предположений, которые должны быть определены в ПЗ или ЗБ. Настоящий раздел стандарта отражает только вопросы, необходимые при формировании требования безопасности для ОО, содержащих криптографические функциональные возможности, и может не охватывать сопутствующие некриптографические вопросы.

C.4.2 Угрозы

C.4.2.1 Спецификация угроз

Известные типовые или предполагаемые угрозы ИТ-активам в ОО, содержащем криптографические функциональные возможности, должны быть определены в ПЗ или ЗБ. Этим угрозам ОО может противостоять или может не противостоять.

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

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

C.4.2.2 Типовые источники угроз

Типовые источники угроз (или агенты угроз) для ОО, содержащих криптографические функциональные возможности, включают в себя (но не ограничиваются):

a) уполномоченных пользователей ОО;

b) неуполномоченных лиц.

Примечание - В данном контексте уполномоченным пользователем является тот, кто уполномочен (авторизован) иметь доступ к определенным активам ИТ.

C.4.2.3 Типовые ИТ-активы, связанные с криптографией

Типовые виды ИТ-активов в ОО, связанные с криптографией, требующие защиты, включают в себя (но не ограничиваются):

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

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

c) реализация криптографического алгоритма в аппаратных средствах, программном обеспечении и/или программно-аппаратных средствах;

d) параметры вызовов (также известные как "другие критические параметры безопасности").

C.4.2.4 Типовые виды атак (реализации угроз)

ИТ-активы, связанные с криптографией, обычно нуждаются в защите от нескольких видов атак. Они включают в себя (но не ограничиваются):

a) обнаружение электромагнитного излучения, исходящего от ОО;

b) маскировку под уполномоченных пользователей ОО;

c) внесение ошибок в ОО;

d) неправильное использование (то есть эксплуатацию или администрирование) ОО;

e) сбои (отказы) аппаратных, программно-аппаратных или программных средств, составляющих ОО;

f) физическое воздействие.

Примечание - Данные атаки не обязательно ограничиваются криптографическими активами.

C.4.2.5 Типовые угрозы

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

Таблица С.1 - Типовые угрозы, относящиеся к криптографическим активам

Идентификатор угрозы	Типовая угроза
T.EMI	Связанные с криптографией активы ИТ могут быть раскрыты неуполномоченному лицу или пользователю через электромагнитные излучения ОО
N.IMPERSON	Нарушитель (внешний или внутренний) может выдавать себя за уполномоченного пользователя ОО
T.ERROR	Неуполномоченное лицо или пользователь ОО, инициируя ошибки в ОО, может добиться несанкционированного раскрытия или модификации связанных с криптографией активов ИТ
T.MODIFY	Целостность информации может быть поставлена под угрозу (скомпрометирована) из-за несанкционированной модификации или уничтожения информации нарушителем
Т.АTTАСК	Необнаруженная компрометация связанных с криптографией активов ИТ может произойти в результате попыток нарушителя (внутреннего или внешнего) выполнения действий, на выполнение которых нарушитель не уполномочен
T.ABUSE	Необнаруженная компрометация связанных с криптографией активов ИТ может произойти в результате преднамеренного или непреднамеренного выполнения любым уполномоченным пользователем ОО действий, на выполнение которых уполномочено конкретное лицо
T.MAL	Связанные с криптографией активы ИТ могут быть модифицированы или раскрыты неуполномоченному лицу или пользователю ОО в результате сбоя (отказа) ОО
T.PHISICAL	Критичные с точки зрения безопасности части ОО могут быть подвержены физическим атакам, которые могут поставить под угрозу (скомпрометировать) безопасность

С.4.3 Политика безопасности организации

Правила ПБОр (если заданы), которыми должен руководствоваться ОО, также должны быть изложены в ПЗ или ЗБ. Следует документировать изложение ПБОр относительно криптографических функциональных возможностей ОО, которое не может быть включено или подразумеваться в описании угроз. Изложение ПБОр включает в себя (но не ограничивается) изложение:

a) политики идентификации и аутентификации;

b) политики управления доступом пользователей;

c) политики аудита и учета;

d) политики управления криптографическими ключами;

e) политики физической безопасности;

f) политики управления излучениями.

Разработчики ПЗ и ЗБ также могут применить изложение этих ПБОр к аспектам ОО, не связанным с криптографией.

Дополнительная информация различных составляющих политики безопасности для ОО, содержащего криптографические функциональные возможности, а также способ их представления в соответствии со стандартами серии ИСО/МЭК 15408 представлены в С.5.5.

С.4.4 Цели безопасности и обоснование

Типовые цели безопасности приведены в таблице С.2.

Таблица С.2 - Типовые цели безопасности для ОО

Идентификатор цели	Цель безопасности
O.I&A	ОО должен выполнять уникальную идентификацию всех пользователей и аутентификацию (проверку подлинности) идентификационной информации до предоставления пользователю доступа к сервисам ОО
O.DAC OO	ОО должен предоставлять своим пользователям средства управления и ограничения доступа других пользователей (или идентифицированных групп пользователей) к объектам и ресурсам, по отношению к которым первые являются владельцами или ответственными, в соответствии с набором правил, определенных дискреционной политикой безопасности
О.РНР	ОО должен защищать себя и связанные с криптографией активы ИТ от несанкционированного физического доступа, модификации или использования
O.INTEGRITY	ОО должен иметь средства обнаружения нарушения целостности информации
O.FAILSAFE	В случае возникновения ошибки ОО должен сохранять безопасное состояние
O.ADMIN	ОО должен предоставить уполномоченному администратору средства, позволяющие ему эффективно управлять ОО и его (ОО) функциями безопасности, а также гарантировать, что только уполномоченные администраторы могут получить доступ к таким функциональным возможностям
OE.EMI	Должны быть предприняты процедурные и физические меры для предотвращения раскрытия связанных с криптографией активов ИТ неуполномоченным лицам или пользователям через электромагнитные излучения ОО
OE.PHYSICAL	Ответственные за ОО должны обеспечить, чтобы части ОО, являющиеся критичными по отношению к реализации политики безопасности, были защищены от физического нападения, которое могло бы поставить под угрозу безопасность ИТ
Примечание - Цели безопасности OE.EMI и OE.PHYSICAL являются целями безопасности для среды. Остальные цели являются целями безопасности для ОО. Другие цели безопасности для среды могут быть связаны: a) с процедурами обработки и хранения связанных с криптографией активов ИТ, вводимых в и выводимых из ОО; b) с процедурами эксплуатации и поддержки ОО; c) с уровнем доверия к уполномоченным пользователям ОО; d) с обучением уполномоченных пользователей (например, держателей криптографических ключей, обслуживающего персонала, основных пользователей), которые должны каким-либо образом взаимодействовать с ОО; e) с физическими мерами, необходимыми для защиты ОО; f) с ограничениями, связанными со средой эксплуатации ОО (включая ограничения, связанные с электромагнитными излучениями); g) с ИТ-средой безопасности ОО (например, ограничениями по типу программного обеспечения, по использованию базовой доверенной операционной системы для реализации политики управления доступом к ОО).

Обоснование целей безопасности для противостояния угрозам приведена в таблице С.3. Данная таблица не отражает уровень детализации, необходимый для обоснования целей безопасности в ЗБ или ПЗ.

Таблица С.3 - Обоснование целей безопасности

Идентификатор угрозы	Соответствующая цель безопасности и обоснование
T.EMI	OE.EMI - требование использования процедурных и физических мер (например, экранирование помещения, размещение на определенном расстоянии от общедоступной зоны) должно уменьшить риск раскрытия связанных с криптографией активов ИТ через излучения ОО
T.IMPERSON	O.I&A - требование надежной идентификации и аутентификации пользователя должно уменьшить риск маскировки под уполномоченного пользователя
T.ERROR	O.FAILSAFE - требование ОО сохранять безопасное состояние в случае возникновения ошибки должно уменьшить риск негативного воздействия из-за случайной модификации или раскрытия связанных с криптографией активов ИТ
T.ABUSE	O.DAC - требование о соответствии процедуры предоставления доступа к ОО установленной политике управления доступом должно уменьшить риск того, что пользователи будут, выполнять операции, доступ к которым им не требуется
T.MAL	O.INTEGRITY - требование к ОО по обнаружению нарушения целостности увеличивает возможности по обнаружению ошибок. O.FAILSAFE - требование ОО сохранять безопасное состояние в случае возникновения ошибки должно уменьшить риск негативного воздействия из-за случайной модификации или раскрытия связанных с криптографией активов ИТ
T.PHYSICAL	О.РНР - требование по защите от физических атак должно уменьшить риск физических атак. OE.PHYSICAL - требование по использованию процедурных и физических мер для ограничения физического доступа к ОО только пользователями, уполномоченными на физический доступ и которым это требуется, должно уменьшить риск физической атаки на ОО
T.MODIFY	O.INTEGRITY - возможность обнаружения нарушения целостности должна уменьшить возможности нарушителя по модификации связанных с криптографией активов ИТ. O.ADMIN - надлежащая конфигурирование и администрирование ОО должны уменьшить риск модификации
T.ATTACK	O.I&A - требование надежной идентификации и аутентификации пользователя должно уменьшить риск несанкционированного доступа. O.DAC - требование о соответствии процедуры предоставления доступа к ОО установленной политике управления доступом должно уменьшить риск того, что пользователи будут выполнять операции, доступ к которым им не требуется

С.4.5 Требования безопасности

Цели безопасности могут быть уточнены в требованиях безопасности ИТ в соответствии с таблицей С.4.

Таблица С.4 - Формирование требований безопасности на основе целей безопасности

Идентификатор цели	Цель безопасности	Компонент в соответствии со стандартами серии ИСО/МЭК 15408
O.I&A	OO должен выполнять уникальную идентификацию всех пользователей и аутентификацию (проверку подлинности) идентификационной информации до предоставления пользователю доступа к ОО и связанным с криптографией активам ИТ	FIA_UID.1-2, FIA_UAU.1-5
O.DAC	OO должен предоставить своим пользователям средства управления и ограничения доступа к связанным с криптографией активам ИТ в соответствии с установленной политикой управления доступом	FDP_ACC.1-2, FDP_ACF.1
О.РНР	OO должен защищать себя и связанные с криптографией активы ИТ от несанкционированного физического доступа, модификации или использования	FPT_PHP.1-3
O.INTEGRITY	OO должен иметь средства обнаружения нарушения целостности информации	FPT_AMT.1, FPT_TST.1.
O.FAILSAFE	В случае возникновения ошибки ОО должен сохранять безопасное состояние	FPT_FLS.1-4
O.ADMIN	OO должен предоставить функциональные возможности, которые позволят уполномоченному администратору управлять криптографическими ключами в соответствии с установленной политикой управления криптографическими ключами	FCS_CKM.1-4, FCS_COP.1
OE.EMI	Должны быть предприняты процедурные и физические меры для предотвращения раскрытия связанных с криптографией активов ИТ неуполномоченным лицам или пользователям через электромагнитные излучения ОО	AGD_ADM.1, AGD_USR.1, процедуры безопасной эксплуатации
OE.PHYSICAL	Ответственные за ОО должны обеспечить, чтобы те части ОО, которые являются критичными по отношению к реализации политики безопасности, были защищены от физического нападения, которое могло бы поставить под угрозу безопасность ИТ	Процедуры безопасной эксплуатации

С.5 Изложение требований безопасности ИТ

С.5.1 Введение

В данном разделе объясняется, каким образом на основе стандартов серии ИСО/МЭК 15408 в ПЗ или ЗБ могут быть выражены требования безопасности ИТ, которые предъявляются к ОО, содержащему криптографические функциональные возможности.

Детальное рассмотрение содержания частей ПЗ и ЗБ, связанных со средой безопасности ОО (угрозы, ПБОр и предположения безопасности) и целями безопасности.

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

С.5.2 Традиционные вопросы проектирования и реализации криптографии

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

Таблица С.5 - Традиционные уязвимости и связанные с ними традиционные решения

Уязвимость	Традиционное решение в терминах ИСО/МЭК 15408
Смешивание (неразделение) данных и ключей	Отдельные физические точки доступа
Использование служебных точек доступа	Установление служебных ролей
Смешивание (неразделение) открытого и зашифрованного текста	Отдельные каналы ввода и вывода. Разделение открытых/закрытых данных
Утечка чувствительной информации вследствие криптографического сбоя	Два внутренних, независимых действия для передачи чувствительной информации. Отключение каналов вывода данных от системы генерации ключей, ввода ключей и обнуления ключей
Несанкционированный доступ	Идентификация и аутентификация. Управление доступом к функциях, сервисам и данным
Ошибки в проекте	Проектирование конечных автоматов
Физическая атака	Меры физической безопасности
Сбои аппаратных средств	Самотестирование
Электромагнитные излучения	Стандарты управления электромагнитными излучениями

Представление традиционных решений, связанных с традиционными уязвимостями, в терминах стандартов серии ИСО/МЭК 15408 рассматривается в таблице С.6.

Таблица С.6 - Представление традиционных решений в терминах стандартов серии ИСО/МЭК 15408

Уязвимость	Представление решения в терминах ИСО/МЭК 15408
Смешивание (неразделение) данных и ключей	Модульность (ADV_INT)
Использование служебных точек доступа	Поддержка ПФБ управления доступом (FDP_ACC, FDP_ACF)
Смешивание (неразделение) открытого и зашифрованного текста	Модульность и сокрытие информации (ADV_INT)
Утечка чувствительной информации вследствие криптографического сбоя	Безопасность при отказе (FPT_FLS). Модульность и сокрытие информации (ADV_INT)
Несанкционированный доступ	Идентификация и аутентификация (FIA_UID, FIA_UAU, FIA_ATD). ПФБ управления доступом пользователей (FDP_АСС, FDP_ACF)
Ошибки в проекте	Полуформальный и формальный проект (ADV_HLD, ADV_LLD)
Физическая атака	Физическая безопасность (FPT_PHP)
Сбои аппаратных средств	Безопасность при отказе (FPT_FLS). Самотестирование (FPT_AMT, FPT_TST)
Электромагнитные излучения	Предположения, связанные с политикой управления излучениями

Для упрощения пояснений по представлению решений на основе стандартов серии ИСО/МЭК 15408, а также типовых представлений в соответствии с таблицей С.4, выражение типовых требований безопасности ОО, содержащих криптографические функциональные возможности, рассматривается под следующими шестью заголовками:

1) "Определение ОО";

2) "Проект и реализация ОО";

3) "Политика безопасности ОО";

4) "Функциональные возможности безопасности ОО";

5) "Тестирование ОО";

6) "Эксплуатация ОО".

С.5.3 Определение объекта оценки

С.5.3.1 Руководство

Объект оценки, его компоненты, функции и интерфейсы должны быть полностью определены в ПЗ и ЗБ, то есть должна быть функциональная спецификация ОО, что должно гарантировать, что все функциональные требования, определенные в ПЗ и ЗБ, учтены и ПБО реализована в ФБО. Должна быть определена также политика безопасности ОО, согласованная с функциональной спецификацией (см. также 5.5).

ГАРАНТ:

По-видимому, в тексте предыдущего абзаца допущена опечатка. Вместо слов "5.5" следует читать "С5.5"

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

С.5.3.2 Представление в соответствии со стандартами серии ИСО/МЭК 15408

Компонент(ы) из семейства ADV_FSP (функциональная спецификация) следует использовать для выражения требований для высокоуровневого описания видимых пользователю интерфейсов и режима выполнения ФБО.

При наличии требования к полуформальному проекту (например, проект конечного автомата) следует использовать компонент ADV_FSP.3 (полуформальная функциональная спецификация). Если есть требование по модели политики безопасности, то должно использоваться семейство ADV_SPM (моделирование политики безопасности).

С.5.4 Проект и реализация объекта оценки

С.5.4.1 Общее доверие

С.5.4.1.1 Руководство

Необходимо уделить внимание тому, чтобы минимизировать и (где возможно) устранить ошибки проектирования и реализации. В ПЗ и ЗБ должно быть продемонстрировано, что, по крайней мере, высокоуровневая архитектура ОО является надлежащей для реализации установленных функциональных требований.

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

С.5.4.1.2 Представление в соответствии со стандартами серии ИСО/МЭК 15408

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

a) ADV_HLD (проект верхнего уровня);

b) ADV_LLD (проект нижнего уровня);

c) ADV_RCR (соответствие представлений);

d) ALC_TAT (инструментальные средства и методы).

Компоненты из семейства ADV_HLD должны использоваться для выражения требований к описанию ФБО в терминах основных структурных частей (то есть подсистем) и связи этих частей с функциями, которые они выполняют. Компонент ADV_HLD.2 (детализация вопросов безопасности в проекте верхнего уровня) следует использовать, если есть требование по отделению криптографических границ ОО от границ ОО в целом.

Компоненты из семейства ADV_LLD следует использовать для выражения требований к описанию внутреннего содержания ФБО в терминах модулей, их взаимосвязей и зависимостей.

Компоненты из семейства ADV_RCR следует использовать при наличии требований к демонстрации соответствия между различными представлениями проекта.

Компонент ALC_TAT.2 следует использовать при наличии требования к выполнению разработки в соответствии с конкретным стандартом реализации (например, стандарт кодирования).

С.5.4.2 Модульный проект

С.5.4.2.1 Руководство

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

a) все входные данные, поступающие в ОО через интерфейс ввода данных, должны пройти только через маршрут ввода данных;

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

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

d) OO должен поддерживать отдельные маршруты для открытых и закрытых данных.

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

С.5.4.2.2 Представление в соответствии со стандартами серии ИСО/МЭК 15408

Для выражения требований к модульному проекту ОО в ПЗ и ЗБ следует выбрать компонент(ы) из следующих семейств:

a) ADV_FSP (функциональная спецификация);

b) ADV_HLD (проект верхнего уровня);

c) ADV_INT (внутренняя структура ФБО);

d) ADV_LLD (проект нижнего уровня).

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

В этом направлении существуют следующие элементы компонента ADV_INT.3 (минимизация сложности) из семейства ADV_INT (внутренняя структура ФБО):

a) ADV_INT.3.3C - описание архитектуры должно содержать изложение, каким образом проект ФБО обеспечивает большую независимость модулей, чтобы избежать ненужного взаимодействия;

b) ADV_INT.3.5C - описание архитектуры должно показать, что взаимные связи были минимизированы, и содержать строгое обоснование оставшихся связей;

с) ADV_INT.3.6C - описание архитектуры должно показывать, каким образом все ФБО структурированы для минимизации сложности.

С.5.5 Политика безопасности объекта оценки

С.5.5.1 Введение

В ПЗ и ЗБ должна быть описана политика безопасности ОО. Политика безопасности ОО, содержащего криптографические функциональные возможности, должна включать в себя следующие аспекты (но может ими не ограничиваться):

a) политика идентификации и аутентификации;

b) политика управления доступом пользователей;

c) политика аудита и учета;

d) политика управления криптографическими ключами;

e) политика физической безопасности;

f) политика управления электромагнитными излучениями.

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

С.5.5.2 Политика идентификации и аутентификации

С.5.5.2.1 Руководство

В ПЗ и ЗБ следует определить типы пользователей и/или ролей, а также способов/средств их аутентификации.

Типовые роли, связанные с криптографией, включают в себя:

a) ответственного за криптографию;

b) ответственного за сопровождение системы;

c) аудитора системы;

d) ответственного за безопасность системы;

e) пользователя/оператора.

С.5.5.2.2 Представление в соответствии со стандартами серии ИСО/МЭК 15408

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

a) FIA_UID (идентификация пользователя);

b) FIA_UAU (аутентификация пользователя);

c) FIA_ATD (определение атрибутов пользователя).

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

Компонент(ы) из семейства FIA_UAU должен(ы) быть использован(ы) для определения механизмов аутентификации пользователя, предоставляемые ФБО.

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

Защита аутентификационной информации от перехвата и повторного использования может быть достигнута с использования компонентов из семейства FTP_TRP (доверенный маршрут) и/или FIA_UAU (FIA_UAU.3 - аутентификация, защищенная от подделок и FIA_UAU.4 - механизмы одноразовой аутентификации).

С.5.5.3 Политика управления доступом пользователей

С.5.5.3.1 Руководство

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

a) роли пользователей;

b) сервисы, к которые может осуществляться доступ;

c) критичные параметры безопасности, например, криптографические ключи (как незашифрованные, так и зашифрованные), другие критичные параметры безопасности (такие, например, как аутентификационные данные);

d) виды доступа (например, чтение, запись, выполнение, удаление и т.д.) к сервисам и критичным параметрам безопасности.

Управление доступом пользователей к ОО может быть основано на ролевой политике управления доступом (RBAC), политике управления доступом, основанной на идентификаторе (IBAC), или на сочетании этих двух политик.

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

До того, как персоналу, ответственному за сопровождение, будет разрешен доступ к ОО:

a) вся открытый информация должна быть зашифрована с использованием мастер-ключа;

b) мастер-ключ должен быть изъят, а его копия внутри ОО должна быть обнулена.

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

С.5.5.3.2 Представление в соответствии со стандартами серии ИСО/МЭК 15408

Следует выбирать компонент(ы) из следующих семейств:

a) FDP_ACC (политика управления доступом);

b) FDP_ACF (функции управления доступом);

c) FDP_IFC (политика управления информационными потоками).

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

Как минимум, следует использовать компонент FDP_ACC.1. С использованием этого компонента следует определять ПФБ для управления доступом всех субъектов к активам ИТ, связанным с криптографией. В зависимости от других функций и ПФБ для ОО в целом компонент FDP_ACC.2 может оказаться более подходящим.

FDP_ACF.1 следует использовать для определения требования по реализации ПФБ управления доступом пользователей:

FDP_ACF.1 Управление доступом, основанное на атрибутах безопасности

FDP_ACF.1.1 ФБО должны осуществлять политику управления доступом пользователей к объектам, основываясь на [назначение: атрибуты безопасности, именованные группы атрибутов безопасности].

FDP_ACF.1.2 ФБО должны реализовать следующие правила определения того, разрешена ли операция управляемого субъекта на управляемом объекте: субъекту разрешено выполнение криптографических операций, используя [назначение: объекты].

FDP_ACF.1.3 ФБО должны явно разрешать доступ субъектов к объектам, основываясь на следующих дополнительных правилах: [назначение: правила, основанные на атрибутах безопасности, которые явно разрешают доступ субъектов к объектам].

FDP_ACF.1.4 ФБО должны явно отказывать в доступе субъектов к объектам, основываясь на следующих дополнительных правилах: [назначение: правила, основанные на атрибутах безопасности, которые явно запрещают доступ субъектов к объектам].

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

Каждый субъект имеет атрибут-идентификатор пользователя, текущую роль(и) и текущее время (если применимо).

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

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

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

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

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

С.5.5.4 Политика аудита и учета

С.5.5.4.1 Руководство

Требования к ОО, связанные с аудитом и учетом (если предъявляются), следует определить в ПЗ и ЗБ.

Процедурные требования могут включать в себя:

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

b) способ обнаружения и отчета о физическом вмешательстве или ошибках.

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

С.5.5.4.2 Представление в соответствии со стандартами серии ИСО/МЭК 15408

Для выражения процедурных требований к аудиту и учету в ПЗ и ЗБ следует использовать предположения безопасности.

Минимальный и базовый уровни аудита определены как для для семейства FCS_CKM, так и для семейства FCS_COP. Подробная информация по использованию компонентов аудита, а также требований аудита для других поддерживающих функциональных требований представлена в ИСО/МЭК 15408-2. События и действия, подвергаемые аудиту, должны быть тщательно отобраны так, чтобы важные события аудита регистрировались и могли быть проанализированы, не затерявшись в чрезмерных данных аудита.

С.5.5.5 Политика управления криптографическими ключами

С.5.5.5.1 Руководство

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

С.5.5.5.2 Представление в соответствии со стандартами серии ИСО/МЭК 15408

Для спецификации требований политики управления криптографическими ключами в ПЗ и ЗБ следует выбирать компонент(ы) из семейства FCS_CKM (управление криптографическими ключами).

Семейство FCS_CKM определяет требования для различных функций управления криптографическими ключами. Если ОО выполняет одну или более из этих функций управления криптографическими ключами, то следует выбрать соответствующий(ие) компонент(ы) из семейства FCS_CKM.

С.5.5.6 Политика физической безопасности

С.5.5.6.1 Руководство

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

Политика физической безопасности должна учитывать следующие аспекты:

a) предположения относительно среды (они должны быть теми же, что и общие предположения относительно среды для любых ПЗ и ЗБ независимо от того, включают ли они криптографию или нет). Эти предположения должны быть выражены типовым способом (см. раздел 8). Однако, если они относятся непосредственно к требованиям к программным средствам, программно-аппаратным средствам и/или аппаратным средствам среды ИТ, то они должны быть оформлены как требования безопасности для среды ИТ;

b) обязанности разных типов пользователей и администраторов по физической защите ОО (данная информация также должна быть задокументирована в руководствах пользователя и администратора).

С.5.5.6.2 Представление в соответствии со стандартами серии ИСО/МЭК 15408

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

a) AGD_USR (руководство пользователя);

b) AGD_ADM (руководство администратора).

Компонент(ы) из семейства AGD_ADM следует использовать для выражения требования по документированию физических ограничений и ограничений относительно среды, в соответствии с которыми ФБО должны находиться под управлением администратора.

Компонент(ы) из семейства AGD_USR следует использовать для выражения требования по документированию физических ограничений и ограничений относительно среды, в соответствии с которыми ФБО должны находиться под управлением пользователя.

Если сам ОО реализует требования по физической безопасности, то для включения в ПЗ и ЗБ следует выбрать компонент(ы) из семейства FPT_PHP (физическая защита ФБО). Эти компоненты могут использоваться для выражения требований к физической безопасности, которые будут реализованы в ФБО для предотвращения физического вмешательства, а также реагирования на такие нападения.

В приведенном ниже примере компонент FPT_PHP.2 выражает требования к физической безопасности для защиты аппаратных и программно-аппаратных средств ОО. Компонент FPT_PHP.3 определяет действия, предпринимаемые для защиты связанных с криптографией активов ИТ при обнаружении вмешательства:

FPT_PHP.2 Оповещение о физическом нападении

FPT_PHP.2.1 ФБО должны обеспечить однозначное обнаружение физического воздействия, которое может угрожать выполнению ФБО. Реализация ФБО должна быть полностью внутри оболочки, позволяющей обнаруживать вмешательства путем сверления, дробления или измельчение содержимого ОО или его покрытия.

FPT_PHP.2.2 ФБО должны предоставить возможность определить, произошло ли физическое воздействие на устройства или элементы, реализующие ФБО.

FPT_PHP.2.3 Для устройств/элементов, реализующих ФБО, ФБО должны постоянно контролировать устройства, элементы и оповещать пользователя ОО о том, что произошло физическое воздействие на устройства или элементы, реализующие ФБО.

FPT_PHP.3 Противодействие физическому нападению

FPT_PHP.3.1 ФБО должны противодействовать следующим сценариям физического воздействия на устройства и элементы, реализующие ФБО, автоматически реагируя так, чтобы предотвратить нарушение ПБО:

a) ОО должен содержаться в пределах крепкого несъемного корпуса. Корпус должен быть спроектирован таким образом, чтобы попытки удалить его или проникнуть через него приводили с высокой вероятностью к серьезному повреждению ОО (то есть ОО станет неработоспособным);

b) если покрытие ОО или корпус содержат какие-нибудь вентиляционные отверстия или щели, то они должны быть маленькими и выполнены таким образом, чтобы предотвратить необнаруженное физическое вмешательство внутрь корпуса;

c) после обнаружения вмешательства все открытые криптографические ключи и другие незащищенные критические параметры безопасности должны быть немедленно обнулены.

С.5.5.7 Политика управления электромагнитными излучениями

С.5.5.7.1 Руководство

Уровень электромагнитных излучений ОО должен быть ограничен с тем, чтобы предотвратить раскрытие связанных с криптографией активов ИТ неуполномоченными лицами или пользователями. Кроме того, также должны быть приняты процедурные и физические меры для предотвращения обнаружения электромагнитных излучений неуполномоченными лицами или пользователями. Также могут быть заданы требования по физической защите, касающейся предотвращения побочных электромагнитных излучений (ЭМИ)/ радиочастотных излучений от нежелательных источников, по причине обеспечения их целостности или доступности.

Оценка технических физических аспектов безопасности ИТ, например таких, как управление электромагнитными излучениями, не рассматривается в стандартах серии ИСО/МЭК 15408 (см. ИСО/МЭК 15408-1), хотя многие из этих понятий будут применимы и в этой области. В частности, в стандартах серии ИСО/МЭК 15408 рассматриваются некоторые аспекты физической защиты ОО.

С.5.5.7.2 Представление в соответствии со стандартами серии ИСО/МЭК 15408

Правила политики безопасности организации (см. С.4.3) должны использоваться для определения способов управления электромагнитными излучениями ОО.

Учитывая то, что требования к оценке электромагнитных излучений исключены из стандартов серии ИСО/ МЭК 15408, должен быть использован механизм предположений безопасности для четкого формулирования требований к ОО по реализации этой политики безопасности. Предположения должны также использоваться для спецификации процедурных и физических мер, которые должны быть приняты для предотвращения обнаружения электромагнитных излучений неуполномоченными лицами или пользователями, или предотвращения нежелательных излучений ЭМИ или в радиочастотном диапазоне.

С.5.6 Функциональные возможности безопасности объекта оценки

С.5.6.1 Введение

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

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

1) криптографические функциональные требования безопасности;

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

Способы выражения политики безопасности ОО на базе стандартов серии ИСО/МЭК 15408 изложены в C.5.5.

С.5.6.2 Криптографические функциональные возможности

С.5.6.2.1 Руководство

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

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

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

a) функциональные требования безопасности по выполнению аспектов управления криптографическими ключами, например:

- генерация криптографического ключа,

- распределение криптографического ключа,

- доступ к криптографическому ключу,

- уничтожение криптографического ключа;

b) функциональные требования безопасности по выполнению криптографических операций, например:

- генерация и/или верификация цифровой подписи,

- генерация криптографической контрольной суммы для контроля целостности и/или для верификации контрольной суммы,

- вычисление хэш-функции (дайджеста сообщение или файла),

- шифрование и/или расшифровывание данных,

- шифрование и/или расшифровывание криптографического ключа,

- согласование криптографического ключа.

Как отмечалось во вводной части настоящего приложения, область применения данного руководства не включает в себя стойкость криптографии, включая длину ключа и стойкость алгоритма. Ни одно функциональное семейство или семейство требований доверия из стандартов серии ИСО/МЭК 15408 (включая AVA_SOF) не должно использоваться для оценки стойкости криптографических функций или длины используемых ключей. Это связано с тем, что стандарты серии ИСО/МЭК 15408 не предназначены для оценки криптографических алгоритмов и связанных с ними технических средств. Требуется независимая оценка математических свойств криптографии, включенной в ОО. Система, которая применяется в стандартах серии ИСО/МЭК 15408, должна создать условия для такой оценки (см. ИСО/МЭК 15408-1). Предполагается, что эта система может требовать соответствия дополнительным стандартам или критериям, регламентирующие область криптографии.

Реализация генератора псевдослучайных чисел также является критичной по безопасности криптографических ключей и криптографических операций. Должны быть выбраны алгоритм и параметры, связанные с генератором псевдослучайных чисел, позволяющие оптимизировать степень непредсказуемости и область значений случайного числа. Для реализации генератора псевдослучайных чисел следует обеспечить требуемую стойкость функции безопасности ОО (AVA_SOF). См. также [9].

С.5.6.2.2 Представление в соответствии со стандартами серии ИСО/МЭК 15408

В зависимости от криптографических функций, которые выполняет ОО, для включения их в ПЗ и ЗБ следует выбрать компонент(ы) из следующих семейств:

a) FCS_CKM (управление криптографическими ключами);

b) FMT_MSA (управление атрибутами безопасности);

c) FCS_COP (криптографические операции).

Необходимо отметить, что класс FCS включает в себя два семейства: FCS_CKM (управление криптографическими ключами) и FCS_COP (криптографические операции). Семейство FCS_CKM включает в себя аспекты управления криптографическими ключами, а семейство FCS_COP связано с использованием этих криптографических ключей. См. также [6].

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

При этом разработчики ПЗ и ЗБ должны учитывать, что:

a) семейство FCS_CKM не включает в себя компонент для защиты криптографических ключей при хранении. Рекомендуется для регламентации защиты криптографических ключей пользователей, сохраненных в ФБО (то есть, сохраненных как данные пользователя), использовать компоненты из семейств FDP_ACC (политика управления доступом) и FDP_ACF (функции управления доступом). Защита криптографических ключей ФБО (то есть, сохраненных как данные ФБО) должна быть регламентирована путем использования компонентов из семейства FPT_SEP (разделение домена) или семейства FMT_MTD (управление данными ФБО). Необходимо отметить, что классы FDP или FPT могут использоваться для обеспечения конфиденциальности и/или целостности криптографических ключей;

b) семейство FCS_CKM не содержит компонентов для защиты ввода криптографического ключа. Криптографические ключи могут вводиться в незашифрованной, зашифрованной или разделенной форме. Для спецификации этого требования следует использовать компонент из семейства FDP_ITC (импорт данных из-за пределов действия ФБО). Если компонент из семейства FDP_ITC используется, то для определения необходимости шифрования или разделения криптографических ключей должно быть выполнено назначение "дополнительные правила управления импортом";

c) на основе компонентов из семейства FCS_CKM должны быть выражены аспекты безопасности криптографических протоколов, в особенности те, которые касаются распределения криптографических ключей (FCS_CKM.2);

d) если необходимо предусмотреть возможность отзыва публичных криптографических ключей, то следует использовать компонент FCS_CKM.2 для регламентации отзыва публичного криптографического ключа. Аргументом использования компонента FCS_CKM.2 является то, что этот компонент определяет схему распределения криптографических ключей, а распространение информации об отзыве и аннулировании ключей рассматривается как неотъемлемая часть распределения криптографических ключей (например, это следует из стандарта Х.509 для списков аннулированных и отозванных сертификатов).

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

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

a) пользовательских приложений, для которых используется сервис безопасности;

b) использования различных криптографических алгоритмов и/или длин криптографических ключей;

c) использования различных типов и/или чувствительности обрабатываемых данных.

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

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

С.5.6.3.1 Руководство

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

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

С.5.6.3.2 Представление в соответствии со стандартами серии ИСО/МЭК 15408

Следует выбирать компонент(ы) из следующих семейств:

a) FDP_ITC (импорт данных из-за пределов действия ФБО);

b) FDP_ETC (экспорт данных за пределы действия ФБО);

с) FTP_ITC (доверенный канал передачи между ФБО), или FTP_TRP (доверенный маршрут).

Элемент(ы) компонента FDP_ITC.2 следует использовать для выражения требований безопасности по введению информации в ОО, что должно реализовываться использованием ПФБ Управления доступом пользователями.

Элемент(ы) компонента FDP_ETC.2 следует использовать для определения правил экспорта данных из ОО, что должно реализовываться использованием ПФБ Управления доступом пользователями.

Компонент(ы) из семейства FTP_ITC следует использовать для выражения требований безопасности по передаче криптографических активов между ФБО и ФБО другого ОО. В качестве альтернативы, для выражения требований для ввода и вывода криптографических активов от(к) человека(у)-пользователя(ю) может (могут) использоваться компонент(ы) из семейства FTP_TRP . Однако разработчики ПЗ и ЗБ должны учитывать, что использование семейств FTP_TRP и FTP_ITC является взаимоисключающим.

В представленном ниже примере использован компонент из FPT_TRP:

FTP_TRP.1 Доверенный маршрут

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

FTP_TRP.1.2 ФБО должны позволить ФБО и локальным пользователям инициировать связь через доверенный маршрут.

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

С.5.6.4 Поддержка безопасного состояния

С.5.6.4.1 Руководство

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

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

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

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

С.5.6.4.2 Представление в соответствии со стандартами серии ИСО/МЭК 15408

Для выражения требований к ОО по сохранению безопасного состояния при возникновении ошибок следует выбирать компонент(ы) из семейства FPT_FLS (безопасность при сбое). Например:

FPT_FLS.1 Сбой с сохранением безопасного состояния

FPT_FLS.1.1 ФБО должны сохранить безопасное состояние при следующих типах сбоев:

a) ОО некорректно попытается выдать незашифрованные криптографические ключи, чувствительные открытые данные или других незащищенные критичные параметры безопасности;

b) сбой криптографической функции;

c) сбой в тестировании абстрактной машины ОО (при запуске, по запросу и/или по условию);

d) обнаружение физического вмешательства в ОО (включая нарушение среды).

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

Разработчики ПЗ и ЗБ должны учесть, что этот компонент зависит от компонента ADV_SPM.1 (неформальная модель политики безопасности ОО). Кроме того, разработчики ПЗ и ЗБ должны будут также включить в ПЗ и ЗБ компоненты для спецификации функциональных возможностей, которые могут породить ошибку (например, функциональные возможности по самотестированию ОО).

Компонент(ы) из семейства FPT_RCV может (могут) использоваться для спецификации требований по возврату ОО к безопасному состоянию и/или предотвращения перехода к небезопасному состоянию.

С.5.6.5 Самотестирование криптографических функций

С.5.6.5.1 Руководство

Из потребности в обнаружении ошибок в ОО следует потребность для любого ОО сохранять безопасное состояние при возникновении этих ошибок.

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

a) самотестирование при запуске (при включении электропитания или загрузке):

- тестирование ожидаемого отклика,

- тестирование целостности программного обеспечения/программно-аппаратных средств,

- тестирование генератора случайных чисел;

b) тестирование по запросу:

- тестирование ожидаемого отклика,

- тестирование целостности программного обеспечения/программно-аппаратных средств,

- тестирование генератора случайных чисел;

c) тестирование при выполнении определенных условий:

- генерация пары (секретный/открытый) ключей, тестирование соответствия ключевой пары,

- загрузка программного обеспечения/ программно-аппаратных средств проверка целостности программного обеспечения/программно-аппаратных средств,

- ввод ключа, тестирование целостности ключа,

- генерация случайного числа, тестирование случайного числа.

С.5.6.5.2 Представление в соответствии со стандартами серии ИСО/МЭК 15408

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

a) FDP_SDI (целостность хранимых данных);

b) FPT_AMT (тестирование базовой абстрактной машины);

c) FPT_TST (самотестирование ФБО).

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

Компонент(ы) из семейства FPT_AMT следует использовать для спецификации тестов базовой абстрактной машины (например, при запуске, по запросу и условию).

Компонент(ы) из семейства FPT_TST следует использовать для выражения следующих требований: обнаружение искажения криптографического кода в результате различных сбоев, которые не обязательно приводят к нарушению работоспособности ОО; проверка, что ФБО работает корректно (например, при запуске, по запросу и условию).

С.5.6.6 Внешние зависимости

С.5.6.6.1 Руководство

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

С.5.6.6.2 Представление в соответствии со стандартами серии ИСО/МЭК 15408

В соответствии с разделом 10, ФТБ, которые должны быть удовлетворены применением других программных, программно-аппаратных или аппаратных средств, внешних по отношению к ОО, должны быть определены в подразделе ПЗ или ЗБ, относящемся к требованиям безопасности для среды ИТ.

С.5.8 Эксплуатация объекта оценки

С.5.8.1 Руководство

Должно быть предоставлено руководство по безопасной установке, администрированию и эксплуатации ОО со стороны уполномоченных пользователей ОО.

С.5.8.2 Представление в соответствии со стандартами серии ИСО/МЭК 15408

Для выражения этого требования в ПЗ и ЗБ следует выбрать компонент(ы) из следующих семейств:

a) AGD_ADM (руководство администратора);

b) AGD_USR (руководство пользователя).

Компонент(ы) из семейства AGD_ADM следует использовать для выражения требований документированию того, каким образом администратором должен правильно устанавливаться (инсталлироваться) и администрироваться ОО.

Компонент(ы) из семейства AGD_USR следует использовать для выражения требований документированию того, каким образом пользователем должен правильно эксплуатироваться ОО.

С.6 Руководство по применению требований доверия

Как упоминалось выше, вопросы стойкости криптографии, выбора размера ключа или стойкости какого-либо алгоритма не входят в область применения настоящего стандарта. Тем не менее, хотя вопросы выбора или пригодности криптографического алгоритма (и выбора размера ключа) находятся вне области применения стандартов серии ИСО/МЭК 15408, реализация алгоритма в ОО входит в его область применения.

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

a) предоставить соответствующую реализацию;

b) гарантировать соответствие реализации стандарту;

c) отказаться от требований по тестированию соответствия;

d) выполнить тестирование на соответствие;

e) потребовать проведения тестов на соответствие оценщиками. Эти тесты должны проводиться с использованием установленных в стандартах тестов на соответствие. Если в стандартах не установлены тесты на соответствие, заявитель может их предоставить или указать другой источник для получения тестов;

f) проанализировать реализацию (например, провести детальный анализ кода) в соответствии с компонентом ADV_RCR;

g) требовать, чтобы оценщики проанализировали реализацию (например, провели детальный анализ кода) в соответствии с компонентом ADV_RCR.

Примечание - Заявитель может отказаться от анализа реализации независимо от уровня доверия согласно стандартам серии ИСО/МЭК 15408, поскольку исходный код может быть недоступен для оценщиков вследствие чувствительности алгоритма. От тестирования соответствия алгоритма, вероятно, также может быть придется отказаться вследствие отсутствия пригодных тестов для оценки соответствия (это, в частности, может иметь место для новых алгоритмов).