ГОСТ Р 56170-2014
12.2 Аутентификация приложений
Название профилей или задач «аутентификация приложения», не требующих соответствия с
функциональным эквивалентом, определено в [11] (15.6). Функциональный эквивалент должен обеспе
чить механизм установления кода, которому можно доверять, чтобы позволить предоставление любых
полномочий по запросу приложения МНР. Платформа безопасности должна содержать механизм под
писывания отдельных файлов или наборов файлов с сертификатом, который может быть отличающим ся
от любого, который используется, чтобы определить доверительный уровень приложения.
П р и м е ч а н и е - Файлы с данными, которые подписаны, могут иметь свои сертификаты для приложений,
используя методы getSigners. описанные в [11] (приложение Р, Р.2.1).
12.2.1 Обзор сообщений аутентификации
Используются три различных типов сообщений: хэш-коды, подписи и сертификаты. Каждое со
общение помещается в файл. Размещение файлов зависит от их функций и определяется под соот
ветствующими заголовками в соответствии с [11] (12.4).
12.2.1.1 Хэш-коды
В настоящем стандарте описывается применение хэш-кодов на следующие виды информации:
- файлы:
- директории.
При вычислении хэш рассматриваются содержание и атрибуты объектов, а не конкретная транс
портная информация. Аутентификация не зависит от базового транспортного протокола.
В случае директории значение хэш зависит от значения хэш обьектов, связанных сним, и обеспе
чивает хэш всех обьектов. которые должны быть аутентифицированы в «дереве» под ним.
12.2.1.2 Подписи
Аутентифицируемые данные являются иерархической файловой системой (например, ОС DSM-
СС). Корень аутентифицируемого «дерева» переносит одну или более подписей. Это позволяет одной
или более организациям подписывать набор информации.
Корень аутентифицируемого «дерева» может быть корневым каталогом файловой системы или
«главным» каталогом «поддерева».
12.2.1.3 Сертификаты
Сертификат содержит открытый ключ, который может использоваться для декодирования хэш-
кода. содержащегося в подписи, и обеспечить проверку «дерева»/«поддерева». Сам сертификат под
писан более высоким органом сертификации. Для правильной аутентификации «поддерево» должно
соответствовать «цепочке» сертификатов от подписи до корневого сертификата.
12.2.1.4 Аутентификация иерархических файловых систем
Решение аутентификации иерархических файловых систем основано на аутентификации иерар
хической структуры объектов. Хэш-коды вычисляются систематически и с накоплением через отдель
ные или через все объекты в иерархии.
Подпись наверху иерархии идентифицирует источник объектов. Платформа обеспечивает гиб
кий и нетрудоемкий метод, разрешающий аутентификацию «поддеревьев» файловой системы с един
ственной подписью. Начиная с проверки подписи, процесс становится более трудоемким, чем проверка
величин хэш-кода. Этот механизм более эффективен, чем подписание каждого объекта «поддерева».
Проверка хэш-кода в реальном времени необходима только загружаемым объектам. Данный ме
ханизм не требует аутентификации целого поддерева.
12.3 Параметры передачи сообщений безопасности
Сообщения аутентификации транспортируются в файлах. Службы передачи не должны получать
доступ к контенту файла. В том случае, если файловой системой является Карусель Объектов, то IOR
для файлов сообщения аутентификации должен использовать только тело профиля BIOP.
12.4 Детализация сообщений аутентификации приложения
Три структуры данных определены для передачи информации аутентификации:
- HashFile;
- SignatureFile;
- CertificateFile.
Они размещаются в файлах файловой системы. Расположение файла зависит от его функции.
91