Стр. 1
 

32 страницы

456.00 ₽

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

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

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

Способы доставки

  • Срочная курьерская доставка (1-3 дня)
  • Курьерская доставка (7 дней)
  • Самовывоз из московского офиса
  • Почта РФ

Настоящий стандарт:

- определяет формат информации аутентификации, хранимой справочником;

- описывает способ получения из справочника информации аутентификации;

- устанавливает предпосылки о способах формирования и размещения в справочнике информации аутентификации;

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

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

Оглавление

Введение

Глава 1. Общие описание

1 Область применения

2 Нормативные ссылки

3 Определения

4 Сокращения

5 Соглашения

Глава 2. Простая аутентификация

6 Процедура простой аутентификации

Глава 3. Строгая аутентификация

7 Основы строгой аутентификации

8 Получение ключа общего пользования

9 Цифровые подписи

10 Процедуры строгой аутентификации

11 Административное управление ключами и сертификатами

Приложение А (обязательное). Основы аутентификации в АСН.1

Приложение В (справочное). Требования к защите информации

Приложение С (справочное). Введение в криптографию ключей общего пользования

Приложение D (справочное). Криптосистема ключа общего пользования RSA

Приложение Е (справочное). ХЕШ-функции

Приложение F (справочное). Защита от угроз методом строгой аутентификации

Приложение G (справочное). Конфиденциальность данных

Приложение H (справочное). Эталонное определение идентификаторов объектов алгоритма

Приложение J (справочное). Библиография

Показать даты введения Admin

Страница 1

ГОСТ Р ИСО/МЭК 9594-8-98 ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ

ВЗАИМОСВЯЗЬ ОТКРЫТЫХ СИСТЕМ СПРАВОЧНИК

ЧАСТЬ 8 ОСНОВЫ АУТЕНТИФИКАЦИИ

Издание официальное

БЗ 3-98/482


ГОССТАНДАРТ РОССИИ Москва

Страница 2

I OCI Р ИСО/МЭК 9594-8-98

Предисловие

1    РАЗРАБОТАН Московским научно-исследовательским центром (МНИЦ) Государственного Комитета Российской Федерации по связи и информатизации

ВНЕСЕН Техническим Комитетом по стандартизации ТК 22 «Информационные технологии»

2    ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 19 мая 1998 г. № 215

3    Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК 9594-8—94 «Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 8. Основы аутентификации*

4    ВВЕДЕН ВПЕРВЫЕ

© ИПК Издательство стандартов. 1998

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

II

Страница 3

ГОСТ Р ИСО/МЭК 9594-8-98

Введение

Настоящий стандарт разработан с целью обеспечения взаимосвязи систем обработки информации. предназначенных для предоставления услуг справочника. Совокупность подобных систем вместе с содержащейся в них информацией справочника может рассматриваться как единое целое, называемое справочником. Информация, хранимая справочником и называемая в целом «информационной базой справочника» (ИБС), используется обычно для обеспечения обмена данными между такими объектами, как логические объекты прикладного уровня, персонал, терминалы и дистрибутивные списки.

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

-    поставляемых от различных изготовителей;

-    использующих различные методы административного управления:

-    имеющих различные уровни сложности;

-    использующих различные технологии.

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

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

В обязательном приложении Л представлен модуль ЛСН.1. в котором содержатся все определения, используемые в основных положениях аутентификации.

В приложении В изложены требования защиты.

В приложении С приведены вводные сведения о криптографии на основе ключа общего пользования.

В приложении D изложена криптосистема ключа общего пользования RSA.

В приложении Е описаны хеш-функции.

В приложении F описана зашита ог угроз методом строгой аутентификации.

В приложении G изложена информация относительно конфиденциальности данных.

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

Ill

Страница 4

ГОСТ Р ИСО/МЭК 9594-8-98 ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология ВЗАИМОСВЯЗЬ ОТКРЫТЫХ СИСТЕМ СПРАВОЧНИК Ч а с т ь 8 Основы аутентификации Information technology. Open Systems Interconnection. The directory. Part 8. Authentication framework

Дата введения 1999— 01—01

Г Л А В A I. ОБЩЕЕ ОПИСАНИЕ

1 Область применения

Настоящий стандарт:

-    определяет формат информации аутентификации, хранимой справочником;

-    описывает способ получения из справочника информации аутентификации;

-    устанавливает предпосылки о способах формирования и размещения в справочнике инфор

мации аутентификации;

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

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

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

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

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

Изданис официальное

I

Страница 5

ГОСТ Р ИСО/МЭК 9594-8-98

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

Краткое описание криптографии ключа общего пользования приведено в приложении С.

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

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

2 Нормативные ссылки

В настоящем стандарте содержатся ссылки на следующие документы:

ГОСТ Р ИСО/МЭК 8824—93 Информационная технология. Взаимосвязь открытых систем. Спецификация абстрактно-синтаксической нотации версии один (АСН.1).

ГОСТ Р ИСО/МЭК 8825—93 Системы обработки информации. Взаимосвязь открытых систем. Спецификация базовых правил кодирования для нотации абстрактного синтаксиса версии один (АСН.1)

ГОСТ Р ИСО/МЭК 9594-1—95 Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 1. Общее описание принципов, моделей и услуг

ГОСТ Р ИСО/МЭК 9594-3—97 Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 3. Определение абстрактных услуг

ГОСТ Р ИСО/МЭК 9594-5—97 Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 5. Спецификации протокола

ГОСТ Р ИСО/МЭК 9594-6—97 Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 6. Выбранные типы атрибутов

ГОСТ Р ИСО/МЭК 9594-7—95 Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 7. Выбранные классы объектов

ИСО 7498-2—89* Системы обработки информации. Взаимосвязь открытых систем. Вазовая эталонная модель. Часть 2. Архитектура защиты информации

ИСО/МЭК 9594-2—93* Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 2. Модели

ИСО/МЭК 9594-4—93* Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 4. Процедуры распределенных операций

ИСО/М ЭК 9594-9—93* Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 9. Дублирование

2

1

Оригиналы стандартов и проектов ИСО/МЭК — во ВНИИКИ Госстандарта России.

2— 11JX

Страница 6

ГОСТ Р ИСО/МЭК 9594-8-98

ИСО/МЭК 13712-1—941 Информационная технология. Взаимосвязь открытых систем. Удаленные операции. Часть I. Концепции, модель и нотация

ИСО/МЭК 13712-2—94* Информационная технология. Взаимосвязь открытых систем. Удаленные операции. Часть 2. Определение услуг сервисного элемента удаленных операций

3 Определения

3.1. В настоящем стандарте применяют следующие термины, определенные в ГОСТ Р ИСО 7498-2:

a)    асимметричное (шифрование);

b)    обмен аутентификацией;

c)    информация аутентификации;

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

e)    удостоверение личности;

О криптография;

g)    аутентификация отправителя данных;

h)    дешифрование;

i)    шифрование; j) ключ;

к) пароль;

I) аутентификация равноправного логического объекта; т) симметричное (шифрование).

3.2    В настоящем стандарте используют следующие термины, определенные в ИСО/МЭК 9594-2:

a)    атрибут;

b)    информационная база справочника;

c)    дерево информации справочника;

d)    агент системы справочника;

e)    агент пользователя справочника;

f)    различительное имя;

g)    запись;

h)    обьект;

i)    корень.

3.3    В настоящем стандарте применимы следующие определения:

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

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

c)    уполномоченный по сертификации — уполномоченный, которому один или несколько пользователей доверяют создавать и присваивать сертификаты. Факультативно УС может создавал, ключи пользователя;

d)    путь сертификации - упорядоченная последовательность сертификатов объектов в дереве информации справочника (ДИС), которая может обрабатываться вместе с ключом общего пользования начального объекта пути для достижения конечного объекта пути:

e)    криптографическая система (криптосистема) — совокупность преобразований простого текста в шнфротекст и обратно, где конкретное(ые) преобразование(я) должно(ы) нспользо-

3

1

Оригиналы стандартов и проектов ИСО/МЭК — во ВНИИКИ Госстандарта России.

Страница 7

ГОСТ Р ИСО/МЭК 9594-8-98

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

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

g)    однонаправленная функция — функция (математическая) f которую легко вычислить, но для обшего значения у из области значений функций трудно вычислительным путем найти такое значение х при котором /(л) = у. Возможно существует несколько значений >•. для которых вычислить а- несложно;

h)    ключ обшего пользования (в криптосистеме ключей общего пользования) — общеизвестный ключ пары ключей пользователя;

i)    личный ключ (не рекомендуется «секретный ключ*) — ключ пары ключей пользователей (в

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

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

1) строгая аутентификация — аутентификация, осуществляемая удостоверениями личности.

полученными криптографическим способом; т) доверие - в общем случае один логический объект может сообщить другому логическому объекту о «доверии*, если он (первый объект) исходит из предположения о том, что этот другой логический объект будет вести себя в точности так, как ожидает первый логический объект. Такое доверие можно применять только для некоторой конкретной функции. Роль ключа доверия в основах аутентификации состоит в отражении взаимоотношений между аутентифицирующим логическим объектом и УС; аутентифицирующий логический объект должен убедиться в том. что он может доверять уполномоченному по сертификации в создании действительных и надежных сертификатов; п) порядковый номер сертификата — значение целого числа, уникальное для выдающего УС, которое недвусмысленно связано с сертификатом, выданным этим УС.

4    Сокращения

АСС    —    агент системы справочника

АПС    —    агент пользователя справочника

ДИС    —    дерево информации справочника

ИБС    —    информационная база справочника

ККОП — криптосистема ключа общего пользования

ПДС    —    протокол доступа к справочнику

УС    —    уполномоченный по сертификации

5    Соглашения

В настоящем стандарте под понятием «спецификация справочника* следует понимать ГОСТ Р ИСО/МЭК 9594-Х. а под понятием «спецификации справочника* — части 1—9 ГОСТ I’ ИСО/МЭК 9594.

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

Обозначения, используемые в настоящем стандарте, приведены в таблице I.

Примечание — Символы X. X,, X, и т. д. в таблице обозначают имена пользователей, а символ I — I ipon звол ьную и ш jw рм ;ши ю.

4

Страница 8

ГОСТ Р ИСО/МЭК 9594-8-98

Таблица!— Обозначения

Обозначение

На жаченкс

X.

Ключ общего пользования (пользователя X)

X,

Личный ключ (пользователя X)

х.ш

Шифрование некоторой информации (I) с использованием ключа общего пользования пользователя X

Х.1И

Шифрование (1) с использованием личного ключа пользователя X

XIII

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

УС ОС)

Уполномоченный по сертификации пользователя X

УС"(Х)

(где л> 1): УС (УС (... я раз... (X)))

х,«х:»

Сертификат пользователя Х3, выданный уполномоченным по сертификации пользователя X,.

х,«х,»х,«х,»

Цепочка сертификатов (может иметь произвольную длину), где каждый элемент — это сертификат для уполномоченного по сертификации, который выдает следующий сертификат. Это функциональный эквивалент следующему сертификату X, «X,. ,». Например, обладание А «В» В «С» обеспечивает те же возможности. что и А «С», а именно, способность найти Со данного А,

# Х,«Х1»

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

А * А «В» В «С» означает операцию, использующую ключ общего пользования пользователя А для получения ключа общего пользования В пользователя В из его сертификата с последующим использованием В для развертывания сертификата С. Результатом операции является ключ общего пачьзования Сь пользователя С

А-» В

Путь сертификации or А к В. сформированный из цепочки сертификатов, начинающийся с УС (А) «УС: (А)» и заканчивающийся с УС (В) «В».

ГЛАВ А 2. ПРОСТАЯ АУТЕНТИФИКАЦИЯ

6 Процедура простой аутентификации

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

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

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

c)    передачей защищенной информации, описанной в Ь), вместе со случайным числом и/или отметкой времени и всего того, что защищено применением однонаправленной функции.

5

Страница 9

ГОСТ Р ИСО/МЭК 9594-8-98

П р и м с ч а н н я

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

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

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

Обшая процедура простой аутентификации приведена на рисунке 1.

Она состоит из следующих шагов:

1)    пользователь — отравитель А посылает свои различительное имя и пароль пользователю — получателю В;

2)    пользователь В посылает предполагаемое различи*

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

справочника:

3)    справочник подтверждает пользователю В (или отрицает) действительность удостоверения личности;

4)    результат положительной (или отрицательной) аутентификации может быть передан пользователю А.

Самая простая форма аутентификации включает только шаг I, а после проверки пользователем В различительного имени и пароля может выполняться шаг 4.

6.1 Генерация защищенной идентифицирующей информации

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

ОГкмначен ия:

А    —    Различительное имя    пользователя

I*    -    Отметка времени

Пароль* -    пароль аольи>ва1еля    А

qA    -    Случайные числа, с    факультативным счетчиком

Рисунок 2 — Защищенная простая аутентификация

6

э-шк

Страница 10

ГОСТ Р ИСО/МЭК 9594-8-98

6.2    Процедура защищенной простой аутентификации На рисунке 3 показана процедура защищенной простой аутентификации.

Процедура защищенной простой аутентификации включает следующие шаги (первоначально использующие только/j):

О

I) пользователь — отправитель Л посылает свою защищенную идентифицирующую информацию (аутентификатор!) пользо-вателю В. Защита обеспечивается применением однонаправ-ленной функции (/^), как на рисунке 2, где отметка времени

„    , п    и/или случайное число (при его использовании) используют-

Рисунок 3 — Процедура    '    _    J    '    *

защищенной простой    ся-    что6ы    уменьшить ответ и скрыть пароль,

аутентификации    Защита    пароля пользователя А имеет вид:

Защита! = fx (tlA, qIA, А, парольА)

Информация, переданная пользователю В, имеет вид:

Аутентификатор! = tl\ q!A, А, Защита!

Пользователь В проверяет защищенную идентифицирующую информацию, предлагаемую пользователем А путем создания (используя различительное имя и факультативно отметку времени и/илн случайное число, обеспечиваемые пользователем А. вместе с локальной копией пароля пользователя Л) локальной защищенной копии пароля пользователя Л (в виде Защита 1). Пользователь В сравнивает идентифицирующую информацию (Защита!) с локально созданным значением;

2) пользователь В подтверждает пользователю Л (или отрицает) наличие защищенной идентифицирующей информации.

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

1)    А посылает В дополнительно защищенную идентифицирующую информацию (Аутентнфи-катор2). Дополнительная защита достигается путем применения далее однонаправленной функции/;, как показано на рисунке 2. Последующая защита имеет вид:

Защитл2 =/г (t2\ q2A. Защита! >

Информация, переданная В. имеет вид:

Аутентификатор2 = tl\ t2\ qlA, q2\ А, Зашита2 При выполнении операции сравнения В генерирует локальное значение дополнительно защищенного пароля и сравнивает его с значением Защита2 (в принципе это аналогично шагу I в 6.2).

2)    В подтверждает или отрицает для А верификацию защищенной идентифицирующей информации.

Примечание— Процедуры, описываемые в этих пунктах, определены в понятиях пользователей А и В. Применительно к справочнику (определенного в ГОСТ Р ИСО/МЭК 9594-3 и ИСО/МЭК 9594-4). ДПС может быть привязана к АСС пользователя В: как вариант, пользователем А может быть АСС. связанный с другим АСС пользователя В.

6.3    Тип атрибута «пароль пользователя»

Этот тип атрибута содержит пароль объекта. Значение атрибута для пароля пользователя — это строка, определенная объектом.

userP^swond ATTRIBUTE    ::={

WITH SYNTAX    OCTET STRING    (SIZE

(O.. ub-user-password))

EQUALITY MATCHING RULE octetStringMatch

ID    id-at-userPassword    }

ГЛАВА 3. СТРОГАЯ АУТЕНТИФИКАЦИЯ

7 Основы строгой аутентификации

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

7

Страница 11

ГОСТ Р ИСО/МЭК 9594-8-98

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

В приложении С приведено краткое описание таких криптосистем и свойств, которые делают их полезными при выполнении аутентификации. Для того, чтобы ККОП могли использоваться в настоящее время в основах такой аутентификации, они должны обладать таким свойством, чтобы при шифровании использовались оба ключа ключевой нары, то есть, чтобы для дешифрования использовался личный ключ, если ключ общего пользования уже применен, и использовался ключ общего пользования, если личный ключ уже применен. Другими словами, Ха * X, =    * Хл, где

XJ Xt — функции шифрования / дешифрования, использующие ключ обшего пользования / личный ключ пользователя X.

Примечание — В будущем возможно введение других дополнительных типов KKOI1, которые не должны требовать такого свойства перестановки и которые могут быть поддержаны этой спецификацией справочника без особых изменений.

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

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

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

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

X Получение ключа общего пользования

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

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

8

Страница 12

ГОСТ Р ИСО/МЭК 9594-8-98

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

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

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

Уполномоченный по сертификации создает сертификат пользователя, подписывая (см. раздел 9) собранную информацию, которая включает различительное имя пользователя и его ключ общего пользования, а также факультативный уникальный идентификатор, содержащий дополнительную информацию о пользователе. Точная форма содержимого уникального идентификатора здесь не определяется и оставлена на усмотрение уполномоченного по сертификации; она может иметь вид. например, идентификатора обьекта. сертификата, даты или некоторый другой вид сертификата достоверности различительного имени. В частности, сертификат пользователя с различительным именем А и уникальным идентификатором УЛ. созданный уполномоченным по сертификации с именем УС и уникальным идентификатором УУС, имеет вид:

УС «А» = УС {В. ПН, ИЛ. УС, УУС, УА, А, Л,, ТА},

где В — версия сертификата, ПН — порядковый номер сертификата. ИЛ — идентификатор алгоритма, используемый для подписания сертификата. УУС - факультативный уникальный идентификатор УС, УЛ — факультативный уникальный идентификатор пользователя А, ТЛ указывает время действия сертификата и состоит из двух дат: начала и конца действия сертификата. Поскольку Т' может изменяться не чаше, чем через 24 ч, предполагается, что системы должны использовать в качестве базового эталонного времени Всемирное координированное время. Действительность подписи на сертификате может быть проверена любым пользователем, знающим СУо. Ятя представления сертификатов может быть использован следующий тип данных АСН.1:

Certificate    ::=    S1GNED|SEQUENCE {

version    |01    Version DEFAULT vi,

serialNumber    CertificateSeriaIN umber,

signature    Algorithm Identifier,

issuer    Name,

validity    Validity,

subject    Name,

subject Public Key I nfo    Subject Public Key I nfo.

issuerUniqueldentifier |l| IMPLICIT Uniqueldentifier OPTIONAL,

-    - при его наличии, должна быть версия v2 subjectUniqueldentifier |2J IMPLICIT Uniqueldentifier OPTIONAL

-    - при его наличии, должна быть версия v2 - - }}

Version    :: = INTEGER |vl(0), v2(!)}

CertificateSerialNumber : : = INTEGER

Algorithm Identifier    :: = SEQUENCE {

algorithm    ALGORITHM. &id ({SupportedAlgorithms}),

parameters    ALGORITHM. &Tvpe ((SupportedAlgorithms)

{Algorithm}) OPTIONAL }

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

-    Такой набор необходим для определения таблицы ограничений на компоненту «параметр»

-    атрибута Algorithm Identifier.

-    SupportedAlgorithms ALGORITHM :: = {... I...}

Validity    ::= SEQUENCE    ]

not Before    UTCTime.

notAfter    UTCTime }

Subject Public Key 1 nfo    ::= SEQUENCE |

9

Страница 13

ГОСТ Р ИСО/МЭК 9594-8-98

algorithm    Algorithm Identifier,

subject Public Key    BIT STRING }

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

Запись справочника каждого пользователя Л, участвующего в строгой аутентификации, содержит сертификаты) А. Такой сертификат создается уполномоченным по сертификации пользователя А, являющимся логическим объектом в ДИС. Уполномоченный по сертификации пользователя А. который может быть не уникальным, обозначается УС(А), или просто УС, если А подразумевается. Поэтому ключ общего пользования пользователя А может быть открыт любым пользователем, который знает ключ общего пользования УС. Таким образом, процесс раскрытия ключей общего пользования является рекурсивным.

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

Список сертификатов, необходимый для того, чтобы конкретный пользователь мог получить общий ключ другого пользователя, называется «путь сертификации*. Каждый элемент такого списка является сертификатом уполномоченного по сертификации следующего элемента в списке. Путь сертификации от А к В (обозначаемый Л —> В)

-    начинается от сертификата, созданного УС (А), а именно, УС (А)«Х'>> для некоторого логического объекта Х‘:

-    продолжается последующими сертификатами X1 «X1 *'»;

-    заканчивается сертификатом В.

Логически путь сертификации формирует непрерывную цепочку доверительных точек в дереве информации справочника между двумя пользователями, желающими выполнить аутентификацию. Точный метод, применяемый пользователями А и В для получения пути сертификации А — -В и В — -А. может изменяться. Один из способов, ведущих к упрощению, состоит в том, чтобы построить иерархию УС, совпадающую с иерархией ДИС полностью или частично. Преимущество такого подхода состоит в том, что пользователи, имеющие УС в иерархии, могут, используя справочник, установить между ними путь сертификации без какой-либо предварительной информации. Для того, чтобы достичь этого, каждый такой УС может хранить один сертификат и один реверсивный сертификат, предназначенный для передачи своему старшему УС.

Сертификаты хранятся в записях справочника в виде атрибутов типа UserCertificate. CACertificate и CrossCenificatePair. Эти типы атрибутов известны справочнику. Такие атрибуты могут действовать при использовании тех же операций протокола, которые используют другие атрибуты. Определения этих типов приведены в 3.3; спецификация этих типов атрибутов имеет следующий вид: userCertificate    ATTRIBUTE :: = {

WITH SYNTAX    Certificate

ID    id-at-userCertificate}

cACertificate    ATTRIBUTE: := {

WITH SYNTAX    Certificate

ID    id-at-cAcertificate |

crossCertificatePair    ATTRIBUTE::3 {

WITH SYNTAX    CertificatePair

ID    id-at -c rossCe rt i ficate Pai r}

CertificatePair    : =    SEQUENCE {

forward    |0|    Certificate OPTIONAL,

reverse    |1|    Certificate OPTIONAL

4-1138

10

Страница 14

ГОСТ Р ИСО/МЭК 9594-8-98

- - Должна иметь место, по меньшей мере, одна из пар - - }

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

Certificates    ::= SEQUENCE (

userCertificate    Certificate,

certif icat ion Path    ForwardCertificationPath    OPTIONAL )

Certification Path    :: = SEQUENCE |

userCertificate    Certificate,

theCACeitificates    SEQUENCE OF Certificate Pair OPTIONAL )

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

Forward Certification Path : : =    SEQUENCE OF CrossCertificates

CrossCertificates    :: =    SET OF Certificate

X. I Оптимизация количества информации, получен но Й и з справочника

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

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

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

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

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

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

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

8.2 Пример

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

Если УС пользователей расположены иерархически, пользователь А для установления пути сертификации к пользователю В может получать из справочника следующие сертификаты:

X«W», W«V», V«Y», Y«Z», Z«B»

Пользователь А, получив такие сертификаты, может развернуть путь сертификации в такой последовательности, которая представляет содержимое сертификата пользователя В, включая В,:

В = X • Х«Л\» W«V>> V <Y» Y«Z» Z«B»

о    p

Страница 15

В общем случае, пользователь А должен получить следующие сертификаты из справочника, чтобы установить обратный путь сертификации от В к А:

Z«Y», Y«V», V«W», W«X», Х«А»

ГОСТ Р ИСО/МЭК 9594-8-98

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

о

А, = Z* Z«Y» Y«V» V«W» W«X» Х«А».

Применяя оптимизацию в соответствии с 8.1:

a)    возьмем, например, А и С: оба знают Хо, так что А должен прямо получить сертификат С. Развернутый путь сертификации сводится к

С, = X/ Х«С», а развернутый обратный путь сертификации сводится к

Ац = X • Х«А»;

b)    предполагая, что А может таким образом знать W«X>>. W , V«W>>, Vo, U«V>> и т. д., тогда информация, которую Л должен получить из справочника для формирования пути сертификации, сводится к

V«Y>>, Y«Z», Z«B»,

а информация, которую А должен получить из справочника для формирования обратного пути сертификации, сводится к Z«Y>>, Y«V>>;

c)    предполагая, что А часто взаимодействует с пользователями, получившими сертификаты от Z, он может узнать (дополнительно к ключам общего пользования, известных из Ь)| V«Y>>, Y«V», Y«Z>>, и Z«Y>>. Для того, чтобы связаться с В. ему, следовательно, необходимо только получить из справочника Z«B>>:

d)    предполагая, что пользователи, получившие сертификаты от X и Z. часто взаимодействуют между собой, X«Z» должен храниться в записи справочника для X, и наоборот (как приведено на рисунке 4). Если А желает выполнить аутентификацию с В. ему необходимо только получить:

X«Z», Z«B» для формирования пути аутентификации и

Z«X»

для формирования обратного пути аутентификации;

12

V

Страница 16

ГОСТ Р ИСО/МЭК 9594-8-98

А = X * Х«А».

о    а

е) предполагая, что пользователи А и С уже взаимодействовали ранее и знают сертификаты друг друга, они могут использовать непосредственно ключ общего пользования друг друга, го есть,

С. = X • х«с»


W

Рисунок 5 — Пример 1 к*иерархического пути сертификации

В более общем случае уполномоченные по сертификации иерархически не взаимосвязаны. Обращаясь к гипотетическому примеру на рисунке 5, предположим, что пользователь D, получивший сертификат от U, желает выполнить аутентификацию с пользователем Е, получившим сертификат от W. Запись пользователя D в справочнике должна содержать сертификат U«D>>, а запись пользователя Е — сертификат W«E>>.

в

Пусть V — это УС, с которым уполномоченные по сертификации U и W в предыдущий раз обменялись ключами общего пользования доверительным способом. В результате были созданы сертификаты U«V>>, V«U>>, W«V»h V«W>> и занесены в справочник. Предположим, что U«V>> и W«V>> содержатся в записи V, V«U>> — в записи U, a V«W» — в записи W.

Пользователь D должен найти путь сертификации к Е. Могут быть использованы различные стратегии. Одна из таких стратегий - рассматривать пользователей и УС как узлы, а сертификаты как дуги в направленном графе. В таких понятиях D должен выполнить поиск в графе для нахождения пути от U к Е, которым в данном случае является путь U«V>>, V«W>>, W«E>>. После того, как этот путь будет найден, может быть построен и обратный путь W«V». V«L'», U«D>>.

9 Цифровые подписи

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

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

Таким образом

X {Инф) = Инф. Хл |h < Инф)]

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

Mod кжп

чк.


Щ

* (*,) *

! ги-

it


I    I

,ЖЛМ»»)Ц


<Х>

Рисунок 6 — Цифровые подписи

13

Страница 17

ГОСТ Р ИСО/МЭК 9594-8-98

Получатель подписанной информации проверяет подпись путем:

-    применения к информации однонаправленной хеш-функпни,

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

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

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

Шифрование некоторого элемента данных может быть описано в ЛСН. 1 следующим образом:

ENCRYPTED {То Be Enciphered): : = BIT STRING (CONSTRAINED BY {

-    - применение процедуры шифрования должно приводить - -

-    - к закодированным по базовым правилам кодирования

-    - октетам значения - - ToBeEnciphered })

Это значение строки битов образуется из октетов, которые создают полное кодирование (используя базовые правила кодирования ЛСН.1 по ГОСТ Р ИСО/МЭК 8825) значения типа ToBeEnciphered, путем применения процедуры шифрования к этим октетам.

П р и м с ч а н и я

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

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

3    Механизмы согласования защиты по алгоритму шифрования и их параметрам отправителем и получателем данных не входит в предмет рассмотрения настоящего стандарта.

В случае, когда подпись может быть присоединена    к    типу данных,    то для определения    типа

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

пользовано следующее описание АСН.1

SIGNED {ToBeSignedJ    ::= SEQUENCE    {

toBeSigned    ToBeSigned,

COMPONENTS OF    SIGNATURE {ToBeSigned}}

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

SIGNATURE {OfSignature} ::= SEQUENCE    {

algorithmldentifier    Algorithmldentifier,

encrypted    ENCRYPTED {HASHED {OfSignature}}}

Чтобы иметь возможность проверить правильность типов SIGNED и SIGNATURE в распределенной среде, требуется различительное кодирование. Различительное кодирование значения данных SIGNED или SIGNATURE может быть получено путем применения базовых правил кодирования. определенных в ГОСТ Р ИСО/МЭК 8825, с учетом следующих ограничений:

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

b)    созданная форма кодирования не должна использоваться для последовательных типов;

c)    если значение типа — это значение по умолчанию, оно должно отсутствовать;

d)    компоненты типа Set должны кодироваться в порядке возрастания значений их тегов;

e)    компоненты типа Set должны кодироваться в порядке возрастания значений их октетов;

О если булев тип имеет значение «истинно», то в результате кодирования содержимое октета должно быть установлено в «FF*lb;

14

Страница 18

ГОСТ Р ИСО/МЭК 9594-8-98

g)    при наличии неиспользуемых битов в последнем октете закодированных строк битов они должны быть установлены в 0;

h)    при кодировании типа Real не должны использоваться основания 8. 10. и 16. а коэффициент двоичного масштабирования должен быть нулевым.

10 Процедуры строгой аутентификации

10.1    О б ш е е описание

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

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

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

a)    однонаправленная аутентификация, описанная в 10.2, использует одну передачу информации от одного пользователя (А), предназначенную для другого (В), и устанавливает следующее:

-    подлинность пользователя А и подтверждение того, что маркер аутентификации был действительно сгенерирован Л;

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

-    целостность и новизну (передан не более одного раза) передаваемого маркера аутентифи

кации.

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

b)    двунаправленная аутентификация, описанная в 10.3, дополнительно использует ответ от В к А и кроме этого констатирует:

-    что маркер аутентификации в ответе действительно был сгенерирован В и предназначен для передачи к А;

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

-    (факультативно) взаимную секретность маркеров;

c)    трехнаправленная аутентификация, описанная в 10.4, дополнительно использует последующую передачу от А до В и устанавливает ге же свойства, что и дву направленная аутентификация. но делает это без необходимости соответствующей проверки отметок времени.

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

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

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

10.2    Однонаправленная аутентификация

При однонаправленной аутентификации (рисунок 7) выполняются следующие шаги:

1)    А создает rv (неповторяющийся номер), который используется для обнаружения повторных угроз и предотвращения подделок:

2)    А посылает следующее сообщение к В:

15

Страница 19

ГОСТ Р ИСО/МЭК 9594-8-98

В — -А. Л (tA, г', В},

Рисунок 7 — Однонаправленная аутентификация

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

В — -А. Л (t\ г*, В. sgnData }.

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

В — -A, A {tA, г\ В. sgnData, В |encData||.

Использование «encData» в виде личного ключа предполагает, что он должен очень внимательно выбираться, например, быть строгим ключом для любой используемой криптосистемы. как указано в поле «sgnData* маркера.

3) Пользователь В выполняет следующие действия:

a)    получает Ац от В - ”*А. проверяя, что срок сертификата пользователя А не истек;

b)    проверяет подпись, и тем самым целостность подписанной информации;

c)    проверяет, что он сам является назначенным получателем;

d)    проверяет, что отметка времени имеет значение «текущее*;

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

г' имеет силу до истечения даты, указанной г\ г' всегда сопровождается последовательной частью, которая указывает, что А не должен повторять маркер в течение временного диапазона tA, и поэтому проверка значения самого гЛ не требуется.

В любом случае для стороны В целесообразно хранить в течение временнбго диапазона t* последовательную часть вместе с отметкой времени 1А в открытом состоянии и вместе с хешированной частью маркера.

10.3 Двунаправленная аутентификация

При двунаправленной аутентификации (рисунок 8) выполняются следующие шаги:

1)    Как и в 10.2.

2)    Как и в 10.2.

3)    Как и в 10.2.

4)    В создает г1 (неповторяющийся номер), используемый для тех же целей, что и г*.

5)    В посылает к А маркер последующей аутентификации:    Рисунок    8    —    Двунаправ

ленная аутентификация

В {t\ г. А, Г*},

где t" — отметка времени, определенная тем же самым способом, что и i\

Как вариант, если аутентификация отправителя данных «sgnData* должна обеспечиваться цифровой подписью, маркер будет иметь вид:

В |t", г*. А. г*. sgnData).

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

В {t", г*. А, г', sgnData, Ap(encData)}.

Использование «encData» в виде личного ключа предполагает, что он должен очень внн-

16

Страница 20

ГОСТ Р ИСО/МЭК 9594-8-98

мателыю выбираться, например, быть строгим ключом для любой используемой криптосистемы. как указано в поле «sgnData» маркера.

6) Пользователь А выполняет следующие действия:

a)    проверяет подпись и. тем самым, целостность подписанной информации;

b)    проверяет, что он сам является назначенным получателем;

c)    проверяет, что отметка времени имеет значение «текущее»;

d)    проверяет факультативно, что г' повторно не использован (см. 10.2, шаг 3d).

10.4 Трех направленная аутентификация

При трехи аправлеи ной аутентификации (рисунок 9) выполняются следующие шаги:

1)    Как и в 10.3.

2)    Как и в 10.3. Отметка времени tA может быть нулевой.

3)    Как для 10.3 за исключением того, что отметка времени не

Рисунок 9 - Трехнаправлен-    должна    проверяться,

пая аутентификация    4)    Как и в 10.3.

5) Как и в 10.3. Отметка времени t* может быть нулевой.

6)    Как и в 10.3 за исключением того, что отметка времени не должна проверяться.

7)    Проверяет, идентичен ли полученный гА переданному г\

К) А посылает к В следующий маркер аутентификации:

А {г*. В}.

9) В выполняет следующие действия:

a)    проверяет подпись и, тем самым, целостность подписанной информации;

b)    проверяет, что полученный г идентичен г\ переданному стороной В.

11 Административное управление ключами и сертификатами

11.1 Генерация пары ключей

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

Данные ключа не просты для запоминания пользователю — человеку, поэтому приемлемым способом их хранения является обычный транспортабельный метод. Одним из возможных механизмов может быть использование «Smart Card*. В них можно хранить секретный и (факультативно) ключи общего пользования, сертификат пользователя и копии обших ключей уполномоченных по сертификации.

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

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

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

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

17

Страница 21

ГОСТ Р ИСО/МЭК 9594-8-98

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

Примем а н к с — Уполномоченный по сертификации уже проявил доверительные функциональные возможности относительно пользователя и должен действовать в зависимости от необходимых физических мер защиты. Этот метод имеет преимущество в том. что он не требует передачи к УС зашишенных данных для сертификации.

Используемая криптосистема налагает конкретные (технические) ограничения на создание ключей.

11.2 Административное управление сертификата м и

Сертификат логически увязывает ключ общего пользования и уникальное различительное имя соответствующего пользователя. Таким образом:

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

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

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

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

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

b)    если реализованы средства создания пары ключей 11.1с), защита передачи не требуется;

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

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

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

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

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

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

18

Страница 22

ГОСТ Р ИСО/МЭК 9594-8-98

имеет сертификата УС. или если предполагается, что сертификаты УС находятся под сомнением. Здесь следует отметить четыре момента:

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

-    УС должен поддерживать:

a)    список выданных им и отмененных сертификатов с отметкой времени;

b)    список аттестованных УС и отмененных сертификатов всех УС, известных данному УС. с

отметкой времени.

Оба списка сертификатов должны иметь место, даже если они пустые:

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

-    списки отмененных сертификатов («черные списки») хранятся в записях в виде атрибутов типа «CertificateRevocation» и «authorityRevocationList*. Эти атрибуты могут обрабатываться с использованием тех же операций, что и другие атрибуты. Эти типы атрибутов определяются следующим образом:

certificateRevocation List    AITRIBUTE :: = (

WITH SYNTAX    Certificate List

ID    id-ai-certificate Revocation List}

authorityRevocationList    ATTRIBUTE: := {

WITH SYNTAX    Certificate List

ID    id-at-authority Revocation List    }

CertificateList    ::=    SIGNED (SEQUENCE {

signature    Algorithmldentifier,

issuer    Name

thisUpdate    UTCTime,

nextUpdate    UTCTime OPTIONAL,

revokedCertificates    SEOUENCE OK SEQUENCE    {

userCertificate    CertificateSerialN umber,

revocationDate    UTCTime} OPTIONAL}}

Примечай и я

1    Проверка полного списка сертификатов является локальным вопросом.

2    Если услуга данных «безотказность отравителя» зависит or ключей, обеспечиваемых УС, то эта услуга должна гарантировать, что все соответствующие ключи УС (отмененные или с истекшим сроком действия) и списки отмененных ключей с отметкой времени архивируются и аттестуются действующим уполномоченным.

19

Страница 23

ГОСТ Р ИСО/МЭК 9594-8-98

ПРИЛОЖЕНИЕ А

(обязательное)

ОСНОВЫ АУТЕНТИФИКАЦИИ В АСИ. 1

В данном приложении приведены определения всех типов, значений и классов информационных объектов ACH.I, содержащихся в настоящем стандарте, в виде модуля ACH.I «AuthentificalionFramcwork* (Основы-Аутентификации).

AuthentificationFramework (joint-iso-ccitt сЫ5) module(l) authcntificatH>nFramework(7) 2|

DEFINITIONS :: -BEGIN

-    - EXPORTS ALL -

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

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

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

-    - препятствовать расширениям и модификациям, необходимым при обслуживании или усовершенствова-

-    - нии услуг справочника.

IMPORTS

id-at, information Framework. upperBounds, sclectedAttnbuteTypes. basicAccessC'ontrol FROM Useful Definitions {joint-iso-ccitt ds(5) module(l) useful Dctin it 101ЫО) 2)

Name. ATTRIBUTE

FROM InformationFramework informationPramework ub-user-password

FROM UpperBounds upperBounds Authentification Level

FROM BasjcAccessControl basicAcccssControl Unique Identifier, octetStringMatch

FROM SclectedAttnbuteTypes selcctcdAttributcTypes:

-    - Типы - -

Certificate    SIGNED (SEQUENCE!

version    |0| Version DEFAULT vl,

serialNumber    Certificate Serial Number,

signature    Algorithmldentifier.

issuer    Name,

validity    Validity,

subject    Name,

subject PublicKeylnfo    Subject Public Keylnfo.

issuerUniqueldcntificr    |I| IMPLICIT Uniqueldentifier    OPTIONAL.

-    - при его наличии, должна быть версия v2 - -}}

subject Uniqueldentifier    [2| IMPLICIT Uniqueldentifier OPTIONAL.

-    - при его наличии, лолжна быть версия v2 - -}}

Version    :    :    INTEGER ( vl(0). v2(l> }

CcrtificatcSerialNumber :    :    *■    INTEGER

Algorithmldentifier    :    :    SEQUENCE    (

algorithm    ALGORITHM.&id ({SupporteadAlgorithms}),

parameters    ALGORITHM.&Typc (1 SupportcadAlgorithms} {Algorithms}) OPTIONAL)

-    Определение следующего набора информационных объектов отложено, возможно, до разработки стан-

-    дартизованных профилей или заявок о соответствии реализации протоколу. Такой набор необходим для

-    определения табличных ограничений на компоненту «параметры» атрибута Algorithmldentifier.

-    SupporteadAlgorithms ALGORITHM :: * {... I...)

Validity    :    :    -    SEQUENCE    |

not Before    UTCTime.

not After    UTCTime }

Subject Public Kevlnfo    SEQUENCE (

algorithm    Algorithmldentifier.

subjectPublicKey    BIT STRING )

Certificates    SEQUENCE (

userCertificate    Certificate.

20

Страница 24

ГОСТ Р ИСО/МЭК 9594-8-98

ForwardCertificationPath OPTIONAL} SEQUENCE OF CrossCcrtificatcs SEQUENCE (

ccrtificationPath

ForwardCertificationPath

CcrtificationPath

uscrCcrtificatc

theCACertificalcs

CrossCcrtificatcs

CcrtificatcList

signature

issuer

this Update next Update re vokedCc rt ificatcs uscrCcrtificatc rcvocationDate CcrtificatcPair

forward    |0|

reverse    111

Certificate,

SEQUENCE OF CcrtificatcPairOPTIONAL } SET OF Certificate SIGNED {SEQUENCE!

Algorithmldcntificr.

Name,

UTCTimc.

UTCTimc OPTIONAL.

SEQUENCE OF SEQUENCE |

Certificate Serial Number.

UTCTimc ) OPTIONAL}}

:: - SEQUENCE(

Certificate OPTIONAL.

Certificate OP1IONAL

- - Должна иметь место, по меньшей мере, одна из пар - -}

- - Типы атрибутов - -uscrPassword    ATTRIBUTE    :: =    (

WITH SYNTAX    OCTET STRING (SIZE

(O.. ub-uscr-password)) EQUALITY MATCHING RULE octctString.Match

id-at-uscrPassword } ATTRIBUTE    - {

ID

uscrCcrtificatc WITH SYNTAX ID

cACcrtificate

WITH SYNTAX ID

authoritvRcvocationList WITH SYNTAX ID

ccrtificatcRevocationList WITH SYNTAX ID

crossCcrtificatePair

WITH SYNTAX

Certificate

id-at-uscrCcrtificatc } ATTRIBUTE    ::~ {

Certificate id-at-cAccrtificate }

ATTRIBUTE    {

CcrtificatcList

id-at-authorityRcvocationList } ATTRIBUTE    )

CcrtificatcList

id-at-Certificatc Revocation List J ATTRIBUTE

CcrtificatcPair id-at-crossCcrtificatcPair }

ID

-    - Классы информационных объектов - -ALGORITHM : : - TYPE-IDENTIFIER

-    - Параметризованные типы - -

HASHED <ToBcHashed|    : : -    OCTET STRING (CONSTRAINED-BY |

-    - должно быть результатом применения процедуры хеширования к октетам значения параметра ToBeHashcd.

закодированным в соответствии с базовыми правилами кодирования (см. 8.7 }) - -ENCRYPTED {ToBcEnciphercd}    :: -    BIT STRING (CONSTRAINED BY (

-    - должно быть результатом применения происдуры шифрования к октетам значения параметра ToBeEncip-

hcrcd. закодированным в соответствии с базовыми правилами кодирования (см. 8.7) )) - -

SIGNED {ToBeSigncd} toBcSigncd COMPONENTS OF SIGNATURE (OfSignaturc}    :    :    =

algorithmldcntificr encrypted

- - Присвоения объектных идентификаторов -

id-at - uscrPassword

{id-at 35J {id-at 36J (id-at 37) {id-at 38} (id-at 39} {id-at 40}

id-at-uscrCcrtificatc

id-at -cAcert ificatc

id-at-authorityRcvocationList

id-at-certificatc Revocation List

id-at-crossCcrtificatePair

END

SEQUENCE {

ToBcSigncd.

SIGNATURE {ToBcSigncdI) SEQUENCE (

Algorithmldcntificr.

ENCRYPTED (HASHED (OlSignaturc}})

OBJECT IDENTIFIER OBJECT IDENTIFIER OBJECT IDENTIFIER OBJECT IDENTIFIER OBJECT IDENTIFIER OBJECT IDENTIFIER


21

Страница 25

ГОСТ Р ИСО/МЭК 9594-8-98

ПРИЛОЖЕНИЕ В (справочное)

ТРЕБОВАНИЯ К ЗАЩИТЕ ИНФОРМАЦИИ

Примечание — Белее подробная информация относительно требований к защите информации приведена в ГОСТ Р ИСО 7498-2.

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

B.I Угрозы

К некоторым общеизвестным угрозам относятся:

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

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

c)    повторные действия — регистрация и последующее повторение действий по обмену данными в последующее время;

d)    перехват данных — просмотр данных пользователя несанкционированным пользователем в процессе обмена;

e)    манипулирование — замена, вставка, удаление или нарушение последовательности данных пользователя несанкционированным пользователем в процессе обмена данными;

f)    самоотказ — отрицание пользователем своего частичного или полного участия в обмене:

g)    отклонение услуги — предотвращение или прерывание обмена, или задержка операций, критичных ко времени.

Примечание — Эта угроза защиты является одной из самых общих угроз и зависит от конкретного применения или намерения несанкционированного разрушения, и поэтому явно не рассматривается в основах аутентификации;

h)    ошибочная маршрутизация — ошибочная маршрутизация пути обмена данными, предназначенного для одного пользователя к другому пользователю

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

i)    анализ трафика — просмотр информации, относящейся к обмену между пользователями (например, отсутствие, наличие, частота, направление, последовательность, тип, объем, и т. д.).

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

В.2 Услуги защиты

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

a)    Аутентификация равноправного логического объекта — эта услуга обеспечивает подтверждение того, что пользователь в определенном сеансе обмена является заявленным. Могут быть запрошены две различные услуги аутентификации равноправного логического объекта:

-    аутентификация одного равноправного логического объекта (аутентификация логического объекта отправителя или получателя);

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

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

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

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

22

Страница 26

ГОСТ Р ИСО/МЭК 9594-8-98

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

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

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

В.З Механизмы защиты

Механизмы защиты выполняют услуги защиты, описанные в В.2:

а) обмен аутентификацией — существуют два вида механизма аутентификации, обеспечиваемых основами аутентификации:

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

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

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

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

c)    Целостность данных — этот механизм использует шифрование сжатой строки тех данных, которые должны быть переданы. Это сообщение вместе с открытыми данными посылается получателю. Чтобы убедиться в целостности данных, получатель повторяет сжатие и последующее шифрование открытых данных и сравнивает свой результат с результатом отправителя.

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

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

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

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

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

В.4 Зашита от угроз с помошью услуг зашиты

В таблице В.1 перечислении угрозы и соответствующие услуги защиты от них. Наличие помегки «*» указывает, что соответствующая услуга обеспечивает зашиту от определенной угрозы.

В.5 Согласование услуг и мехами змов защиты

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

23

Страница 27

ГОСТ Р ИСО/МЭК 9594-8-98

Т а б л и ц a BI — Угрозы и зашита

Угра ш

Аутем т мфикзимч логического объекта

Конфиденциальность

данных

Цел ОС I ность данных

Безотказность

Перехват

идентичности

* (Если требуется)

Перехват

данных

Маскирование

Повторные

действия

«

(Идентичность)

ж

(Данные)

Ж

Обработка

Ж

Самоотрицание

ж

ПРИЛОЖЕНИЕ С

(справочное)

ВВЕДЕНИЕ В КРИПТОГРАФИЮ КЛЮЧЕЙ ОБЩЕГО ПОЛЬЗОВАНИЯ

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

Однако в криптографических системах ключей общего пользования (ККОП) ключи вводятся парами: один для шифрования, другой для дешифрования. Каждая пара ключей связана с конкретным пользователем X. Один из ключей, общеизвестный как ключ общего пользования (X ), может быть использован любым пользователем для шифрования данных. Только X, который обладает дополнительным личным ключом (X ), может расшифровать данные. (В нотации это представлено в виде: /) * X \Х (/)])). Вычислительным путем невозможно получить личный ключ, зная ключ общего пользования. Любой пользователь может таким образом обмениваться частью информации, обнаружить которую может только X, зашифровав ее с помощью X . С помощью некоторого расширения два пользователя могут обмениваться секретно, используя ключ общего пользования друг друга л ля шифрования данных, как показано на рисунке C.I.

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

4 x'-AJV] a i'-AJ *']

1    Пользователь А желает послать некоторую Секретную информа-иию х к В. Для этого А шифрует .v, используя ключ шифрования В и посылает зашифрованную иж]юрмацию е к В. j>to представлено в виде:

Рисунок С.1 — Использование ККОП для обмена секретной

е „ Др|д.|    информации

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

х- В\е| или* - Я,|Я>1|.

3    Теперь В может точно также послать А некоторую секретную информацию х* используя секретный ключ А. А;

24

Страница 28

ГОСТ Р ИСО/МЭК 9594-5-98

е'-лу\.

4 А получает лг' путем дешифрования е\

Alf'l или х’- A {A (jr'l).

Таким способом А и В обмениваются секретной информацией .v и лг*. Эта информация не может быть получена никем другим, кроме А и В, при условии, что их личные ключи не раскрыты.

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

Некоторые ККОП обладают тем свойством, что шаги дешифрования и шифрования могут быть реверсивными как в D * X\X\D)\. Это позволяет любому пользователю (который обладает X ) читать часть информации. которая могла быть отправлена только X. Следовательно, эта возможность может быть использована при выполнении сертификации источника информации, и является основой для цифровых подписей. Только тс ККОГ1, которые обладают таким свойством (перестановки), пригодны для использования в этих основах аутентификации. Один из таких алгоритмов приведен в приложении D.

ПРИЛОЖЕНИЕ D (справочное)

КРИПТОСИСТЕМА КЛЮЧА ОБЩЕЮ ПОЛЬЗОВАНИЯ RSA

11 р и м е ч а н и я

1    Криптосистема, определенная в настоящем приложении, известна под названием RSA-Rivst-S!iamir-Adleman (Ривс-Шамир-Адлеман).

2    Более подробная информация относительно этой криптосистемы приведена в приложении J.

D.1 Назначение и область применения

Поднос рассмотрение криптосистемы RSA в данном приложении невозможно. Приведенное, однако, краткое ее описание предложено по методу, основанному на использовании модульного экспонирования. D.2 Определения

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

Г! р и м с ч а н и с — Элемент данных в ACH.l «subject Public Key*, определенный в виде битовой строки (см. Приложение А), должен интерпретироваться в случае RSA как:

SEOUENCE (INTEGER. INTEGER), где первое целое число — арифметический модуль, а второе — показатель степени общего пользования. Последовательность представляется базовыми правилах!и кодирования ACH.I.

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

D.3 Символы н сокращения

X. У — блоки данных, которые арифметически меньше модуля я — арифметический модуль е    — показатель степени общего пользования

d    — секретный показатель степени

р, q — простые числа, произведение которых образует арифметический модуль (я)

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

1сш — наименьший множитель mod п — арифметический модуль я.

D.4 Описание

Асимметричный алгоритм использует мощную функцию для преобразования блоков данных так. что У = X' mod я при ОйХ<п XК'mod п при 0<.У<п

Эти условия могут быть выполнены, например, при ed mod lcm(p—1, q— I) * I или ed mod (p— 1) (q— I) = 1

Чтобы этот процесс действовал, блок данных должен интерпретироваться как целое число. Это достигается рассмотрением всего блока данных в виде упорядоченной последовательности битов (длиной X). При этом

25

Страница 29

ГОСТ Р ИСО/МЭК 9594-8—98

целое число формируется как сумма битов после назначения первому биту веса 2V 1 к первому биту и делением на 2 каждого последующего бета (последний бит имеет вес 1).

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

D.5 Требования к зашито

D.5.1 Длины ключей

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

D.5.2 Генерация ключа

Защита RSA полагается на трудность факторизации параметра п. Существует несколько алгоритмов выполнения этой операции и. чтобы предотвратить использование какого-нибудь известного в настоящее время способа, значения р и д должны выбираться с особым вниманием согласно следующим правилам (см приложение J «Библиография*):

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

b)    они должны быть большими по значению;

c)    они должны быть простыми числами;

d)    Ip — 4 должен иметь большое значение;

<-•) (р +    1) должен    иметь большую    величину первичного    фактора;

0    (д +    1) должен    иметь большую    величину первичного    фактора:

g) (Я — И должен иметь большую величину первичного фактора, например, г,

h) (д — I) должен иметь большую величину первичного фактор:!, например, .v;

i)    (г —    I) должен    иметь большую    величину первичного    фактора;

j) (* —    I) должен    иметь большую    величину первичного    фактора.

После создания ключа общего пользования и личного ключа, например *Х/ и «X,», как определено в разделах 3 и 4 настоящего стандарта, содержащих Леия. значения р и q вместе со    всеми других!и    данными,

полученными в результате умножения (р — I) (д — 1).    и    первичные    факторы,    имеющие    большие    значения,

должны быть аннулированы. Однако, сохраняя р и д локально, можно повысить производительность дешифрования в два — четыре раза. Считается, что сохранение р и q должно решаться локально.

Должно быть обеспечено соотношение е > log.(w). Если оно не обеспечено, го простая операция извлечения корня целочисленной степени е блока шифрогекста может раскрывать открытый текст.

D.6 Показатель степени общего пользования

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

Показатель степени е должен быть достаточно большим, но до такой степени, чтобы экспонирование можно было выполнять достаточно эффективно относительно времени обработки и емкости памяти. Если требуется фиксированный показатель степени общего пользования е, следует учитывать значительные преимущества использования числа Ферми t\.

Fa - 2*+ I

= 65537 десятичное число, и

= I 0000 0000 0000 0001 двоичное число

П р и X! с ч а н и я

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

2    Фиксированный показатель сгспсни должен быть больших! и первичным, но он должен также обеспечивать эффективную обработку. Число Ферми f4 удовлегворяст этим требованиям, например, аутентификация требует только 17 умножений и в среднем в 30 раз быстрее, чем дешифрование.

D.7 Соответствие

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

26

Страница 30

ГОСТ Р ИСО/МЭК 9594-8-98

ПРИЛОЖЕНИЕ Е (справочное)

ХЕШ-ФУНКЦИИ

Требования к хеш-функииям

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

Строгая хеш-функния должна удовлетворять следующим требованиям:

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

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

ПРИЛОЖЕНИЕ Г (справочное)

ЗАЩИТА ОТ УГРОЗ МЕТОДОМ СТРОГОЙ АУТЕНТИФИКАЦИИ

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

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

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

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

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

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

Подделка сертификата — метод строгой аутентификации защищает от подделки сертификата наличием подписи УС. Этот метод зависит от сохранения секретности личного ключа УС.

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

Повторные действия маркера — одно- и двунаправленная аутентификация защищают от повторных действий маркера включением временной метки в маркер. Метод трехнаправленной аутентификации выполняет зто на основе проверки случайных чисел.

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

27

Страница 31

ГОСТ Р ИСО/МЭК 9594-8-98

ПРИЛОЖЕНИЕ G (справочное)

КОНФИДЕНЦИАЛЬНОСТЬ ДАННЫХ

G.I Введение

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

Конфиденциальность данных может быть обеспечена применением схемы асимметричного или симметричного шифрования.

G.2 Конфиденциальность данных асимметричным шифрованием

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

G.3 Конфиденциальность данных симметричным шифрованием

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

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

ПРИЛОЖЕНИЕ И (обязательное)

ЭТАЛОННОЕ ОПРЕДЕЛЕНИЕ ИДЕНТИФИКАТОРОВ ОБЪЕКТОВ АЛГОРИТМА

Данное приложение определяет идентификаторы объектов, используемых в алгоритмах аутентификации и шифрования, при отсутствии формального регистра. Предполагается использовать такой регистр, как только он станет доступным. Определения используют форму модуля ACH.I, «AlgorithmObjectIdentifiers*. AlgonthmObjectldcntifien; joint-iso-ccitt ds<5) module! 1) algorithmObject Identifiers^) 2j DEFINITIONS : : -BEGIN

-    EXPORTS ALL -

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

-    - АСН.1. содержащихся в спецификациях справочника, и другими прикладными программами, которые

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

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

-    - модификациям, необходимым при обслуживании или усовершенствовании справочной службы. IMPORTS

algorithm, authentication Framework

FROM UsefulDefmitions {joint-iso-ccitt ds(5) module! I) usciulDefinitions(O) 2}

ALGORITHM

FROM Authentifkat ion Framework authcntificationFramcwork;

-    - Категории идентификаторов объектов - -

encrvptionAIgorithm    OBJECT IDENTIFIER    :    :    =    {algorithm    I}

hashAlgorithm    OBJECT IDENTIFIER    :    :    =»    {algorithm    2}

signatureAlgonthm    OBJECT IDENTIFIER    {algorithm    3}

-    - Синонимы - -

id-еа OBJECT IDENTIFIER :: ■= cncrvptionAlgorithm id-ha OBJECT IDENTIFIER    hashAlgorithm

id-sa OBJECT IDENTIFIER    signatureAlgonthm

28

Страница 32

ГОСТ Р ИСО/МЭК 9594-8-98

-    - Алгоритмы - -

пи ALGORITHM    (

KcvSi^c

I гУеМ1 FI EL) BY    id-са-па }

KeySizc    :: -    INTEGER

-    - Присвоении идентификаторов объектов - -

ida-na    OBJECT    IDENTIFIER    ::= {id-ca 1}

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

id-ha-sqMod-n    OBJECT IDENTIFIER    {id-ha 1}

id-sa-sqMod-n\VithRSA    OBJECT IDENTIFIER    <id-a 1}

END

ПРИЛОЖЕНИЕ J

(справочное)

БИБЛИОГРАФИЯ

1    Rivest, R. L.. Shamir, A., and Adleman, L. A Method for Obtaining Digital Signatures and Public-key Cryptosystems, Communications of the ACM, 21,2 (Febrary 1978). 120—126

2    Gordon. J Strong RSA Keys, Electronics Letters, 20,5. 514—516. Quisquater, J. J.. and Couvrcur. c. Fast Decipherment Algorithm for RSA Public-key Cryptosystems, Electronics Letters, 18—21 (October 14, 1982), 905-907

УДК 681.324:(ККэ.354 ОКС 35.100.70 П85 ОКСТУ 4002

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

Редактор В. П. Огурцов

Технический редактор В. II Прусакоаа

Корректор О. Я. Чермечааа

Компьютерная верстка 3. И Мартыновой

И м. лиц. № 0211)07 от 10.08.95. Сдано в набор 28.05.9S. Подписана п печать 06.08.98

Уел. иеч. л. 3.72. Уч.'-над-л. 3.54.

Тираж 238 «з. С/Д S344. Зак. 425.

ИПК Издательство стандартов, 107076. Москва. Колоде muй пер., 14. Набран» в Калужской типографии стандартов иа ПЭВМ. Калужская типография стандартов, ул. Московская. 256.

ПЛР № 040138