+7 (495) 943-14-01
info@cnt-i.ruГОСТ Р ИСО/МЭК 9594-8-98. ИТ. ВОС. Справочник. Часть 8. Основы аутентификации.
ГОСТ Р ИСО/МЭК 9594-8-98
Группа П85
ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Информационная технология
ВЗАИМОСВЯЗЬ ОТКРЫТЫХ СИСТЕМ
СПРАВОЧНИК
Часть 8
Основы аутентификации
Information technology. Open Systems Interconnection. The directory. Part 8.
Authentication framework
ОКС 35.100.70
ОКСТУ 4002
Дата введения 1999-01-01
Предисловие
1 РАЗРАБОТАН Московским научно-исследовательским центром (МНИЦ) Государственного Комитета Российской Федерации по связи и информатизации
ВНЕСЕН Техническим Комитетом по стандартизации ТК 22 "Информационные технологии"
2 ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 19 мая 1998 г. N 215
3 Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК 9594-8-94 "Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 8. Основы аутентификации"
4 ВВЕДЕН ВПЕРВЫЕ
Введение
Настоящий стандарт разработан с целью обеспечения взаимосвязи систем обработки информации, предназначенных для предоставления услуг справочника. Совокупность подобных систем вместе с содержащейся в них информацией справочника может рассматриваться как единое целое, называемое справочником. Информация, хранимая справочником и называемая в целом "информационной базой справочника" (ИБС), используется обычно для обеспечения обмена данными между такими объектами, как логические объекты прикладного уровня, персонал, терминалы и дистрибутивные списки.
Справочник играет существенную роль во взаимосвязи открытых систем (ВОС), цель которой состоит в том, чтобы при минимуме технических согласований вне стандартов по ВОС обеспечить взаимосвязь систем обработки информации:
- поставляемых от различных изготовителей;
- использующих различные методы административного управления;
- имеющих различные уровни сложности;
- использующих различные технологии.
Для многих применений требуются средства защиты от угроз нарушения обмена информацией. Некоторые наиболее известные угрозы вместе с услугами защиты и механизмами, которые могут быть использованы для защиты от них, кратко изложены в приложении В. Фактически все услуги защиты зависят от идентичности взаимодействующих сторон хорошо друг другу известных, то есть от их аутентичности.
Настоящий стандарт определяет основы услуг аутентификации, предоставляемых справочником своим пользователям. К этим пользователям относится сам справочник, а также другие прикладные программы и услуги. Справочник может оказаться полезным при обеспечении других потребностей в аутентификации и других услуг защиты, поскольку он представляет собой естественное место, из которого взаимодействующие стороны могут получить информацию друг о друге, то есть сведения, являющиеся основой аутентификации. Справочник - это естественное место потому, что он хранит и другую информацию, необходимую для обмена и полученную до его осуществления. При таком подходе получение из справочника информации аутентификации потенциального партнера подобно получению адреса. Предполагается, что вследствие широкой доступности справочника для целей обмена эти основы аутентификации будут широко использованы многими прикладными программами.
В обязательном приложении A представлен модуль АСН.1, в котором содержатся все определения, используемые в основных положениях аутентификации.
В приложении B изложены требования защиты.
В приложении C приведены вводные сведения о криптографии на основе ключа общего пользования.
В приложении D изложена криптосистема ключа общего пользования RSA.
В приложении Е описаны хеш-функции.
В приложении F описана защита от угроз методом строгой аутентификации.
В приложении G изложена информация относительно конфиденциальности данных.
В приложении H приведены идентификаторы объектов, присвоенные в алгоритмах аутентификации и шифрования при отсутствии формального регистра.
ГЛАВА 1. ОБЩЕЕ ОПИСАНИЕ
1 Область применения
Настоящий стандарт:
- определяет формат информации аутентификации, хранимой справочником;
- описывает способ получения из справочника информации аутентификации;
- устанавливает предпосылки о способах формирования и размещения в справочнике информации аутентификации;
- определяет три способа, с помощью которых прикладные программы могут использовать такую информацию аутентификации для выполнения аутентификации, и описывает, каким образом с помощью аутентификации могут быть обеспечены другие услуги защиты.
В настоящем стандарте изложены два вида аутентификации: простая, использующая пароль как проверку заявленной идентичности, и строгая, использующая удостоверения личности, созданные с использованием криптографических методов. Если простая аутентификация предлагает некоторые ограниченные возможности защиты от несанкционированного доступа, то в качестве основы услуг, обеспечивающих защиту, должна использоваться только строгая аутентификация. Здесь не ставится задача установить эти методы в качестве общей основы аутентификации, но они могут получить общее применение со стороны тех прикладных программ, которые рассматривают эти методы адекватными.
Аутентификация (и другие услуги защиты) могут быть предложены только в контексте определенной стратегии защиты. Пользователи прикладной программы должны сами определить свою собственную стратегию защиты, которая может быть ограничена услугами, предусмотренными стандартом.
Задача стандартов, определяющих прикладные программы, которые используют основы аутентификации, состоит в том, чтобы установить правила протокольных обменов, которые необходимо осуществить для обеспечения аутентификации, основываясь на информации аутентификации, полученной из справочника. Протоколом, используемым прикладными программами для получения удостоверения личности из справочника, является протокол доступа к справочнику (ПДС), определенный в ИСО/МЭК 9594-5.
Метод строгой аутентификации, определенный в настоящем стандарте, основан на криптосистемах ключа общего пользования. Главное преимущество таких систем состоит в том, что сертификаты пользователей могут храниться в справочнике в виде атрибутов, свободно участвовать в обмене внутри системы справочника и могут быть получены пользователями справочника таким же способом, как и любая другая информация справочника. Предполагается, что сертификаты пользователей должны формироваться "автономными" средствами и вводиться в справочник их создателями. Выработка сертификатов пользователей выполняется некоторыми автономными уполномоченными по сертификации (УС), которые полностью отделены от агентов системы в справочнике. В частности, поставщикам справочника не предъявляется никаких специальных требований по записи или обмену сертификатами пользователей надежным способом.
Краткое описание криптографии ключа общего пользования приведено в приложении С.
В общем случае основы аутентификации не зависят от использования конкретного алгоритма криптографии, при условии, что он обладает свойствами, приведенными в 7.1. Потенциально может быть использовано несколько различных алгоритмов. Однако два пользователя, желающие осуществить аутентификацию, должны придерживаться одного и того же алгоритма криптографии. Таким образом, в контексте набора соответствующих прикладных программ выбор одного алгоритма позволит расширить семейство пользователей, способных к аутентификации и надежной передаче. Пример алгоритма криптографии ключа общего пользования приведен в приложении D.
Точно также два пользователя, желающие осуществить аутентификацию, должны поддерживать одну и ту же хеш-функцию (см. 3.3f), используемую при формировании удостоверений личности и маркеров аутентификации. Опять-таки, в принципе может быть использован ряд альтернативных хеш-функций ценой уменьшения числа пользователей, способных к аутентификации. Краткое описание хеш-функций приведено в приложении Е.
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. Дублирование
_________________
* Оригиналы стандартов и проектов ИСО/МЭК - во ВНИИКИ Госстандарта России.
ИСО/МЭК 13712-1-94* Информационная технология. Взаимосвязь открытых систем. Удаленные операции. Часть 1. Концепции, модель и нотация
_________________
* Оригиналы стандартов и проектов ИСО/МЭК - во ВНИИКИ Госстандарта России.
ИСО/МЭК 13712-2-94* Информационная технология. Взаимосвязь открытых систем. Удаленные операции. Часть 2. Определение услуг сервисного элемента удаленных операций
_________________
* Оригиналы стандартов и проектов ИСО/МЭК - во ВНИИКИ Госстандарта России.
3 Определения
3.1. В настоящем стандарте применяют следующие термины, определенные в ГОСТ Р ИСО 7498-2:
a) асимметричное (шифрование);
b) обмен аутентификацией;
c) информация аутентификации;
d) конфиденциальность;
e) удостоверение личности;
f) криптография;
g) аутентификация отправителя данных;
h) дешифрование;
i) шифрование;
j) ключ;
k) пароль;
l) аутентификация равноправного логического объекта;
m) симметричное (шифрование).
3.2 В настоящем стандарте используют следующие термины, определенные в ИСО/МЭК 9594-2:
a) атрибут;
b) информационная база справочника;
c) дерево информации справочника;
d) агент системы справочника;
e) агент пользователя справочника;
f) различительное имя;
g) запись;
h) объект;
i) корень.
3.3 В настоящем стандарте применимы следующие определения:
a) маркер аутентификации (маркер) - информация, передаваемая во время обмена строгой аутентификацией, которая может быть использована для аутентификации отправителя;
b) сертификат пользователя (сертификат) - ключи общего пользования вместе с некоторой другой информацией, к которой применено шифрование личным ключом УС, выдавшим эту информацию;
c) уполномоченный по сертификации - уполномоченный, которому один или несколько пользователей доверяют создавать и присваивать сертификаты. Факультативно УС может создавать ключи пользователя;
d) путь сертификации - упорядоченная последовательность сертификатов объектов в дереве информации справочника (ДИС), которая может обрабатываться вместе с ключом общего пользования начального объекта пути для достижения конечного объекта пути;
e) криптографическая система (криптосистема) - совокупность преобразований простого текста в шифротекст и обратно, где конкретное(ые) преобразование(я) должно(ы) использоваться выбранными ключами. Преобразования обычно определяются математическим алгоритмом;
f) хеш-функция - функция (математическая), которая преобразует значения из большой (возможно очень большой) области в область меньшего масштаба. "Хорошей" считается такая хеш-функция, результаты применения которой к (большому) набору значений в области будут равномерно распределены (и очевидно на случайной основе) по всему диапазону;
h) ключ общего пользования (в криптосистеме ключей общего пользования) - общеизвестный ключ пары ключей пользователя;
i) личный ключ (не рекомендуется "секретный ключ") - ключ пары ключей пользователей (в криптосистеме ключей общего пользования), известный только данному пользователю;
j) простая аутентификация - аутентификация, осуществляемая путем назначения простого пароля;
k) стратегия защиты - набор правил, установленных уполномоченными защиты, которые управляют использованием и предоставлением услуг и средств защиты;
l) строгая аутентификация - аутентификация, осуществляемая удостоверениями личности, полученными криптографическим способом;
m) доверие - в общем случае один логический объект может сообщить другому логическому объекту о "доверии", если он (первый объект) исходит из предположения о том, что этот другой логический объект будет вести себя в точности так, как ожидает первый логический объект. Такое доверие можно применять только для некоторой конкретной функции. Роль ключа доверия в основах аутентификации состоит в отражении взаимоотношений между аутентифицирующим логическим объектом и УС; аутентифицирующий логический объект должен убедиться в том, что он может доверять уполномоченному по сертификации в создании действительных и надежных сертификатов;
n) порядковый номер сертификата - значение целого числа, уникальное для выдающего УС, которое недвусмысленно связано с сертификатом, выданным этим УС.
4 Сокращения
АСС - агент системы справочника
АПС - агент пользователя справочника
ДИС - дерево информации справочника
ИБС - информационная база справочника
ККОП - криптосистема ключа общего пользования
ПДС - протокол доступа к справочнику
УС - уполномоченный по сертификации
5 Соглашения
В настоящем стандарте под понятием "спецификация справочника" следует понимать ГОСТ Р ИСО/МЭК 9594-8, а под понятием "спецификации справочника" - части 1-9 ГОСТ Р ИСО/МЭК 9594.
Если элементы списков пронумерованы (в противоположность использованию дефиса "-" или букв), то такие элементы должны рассматриваться как шаги процедуры.
Обозначения, используемые в настоящем стандарте, приведены в таблице 1.
Таблица 1 - Обозначения
|
|
|
|
Обозначение |
Назначение |
|
Х
 |
Ключ общего пользования (пользователя Х) |
|
Х
 |
Личный ключ (пользователя X) |
|
Х
[I]
|
Шифрование некоторой информации (I) с использованием ключа общего пользования пользователя Х |
|
Х
[I]
|
Шифрование (I) с использованием личного ключа пользователя Х |
|
Х[I] |
Подпись I пользователем X. Она включает I, к которой присоединены зашифрованные сводные сведения |
|
УС(Х) |
Уполномоченный по сертификации пользователя Х |
|
УС
(Х)
|
(где
>1):УС(УС(…
раз…(X)))
|
|
Х
<<X
>>
|
Сертификат пользователя X
, выданный уполномоченным по сертификации пользователя X
.
|
|
Х
<<X
>>Х
<<X
>>
|
Цепочка сертификатов (может иметь произвольную длину), где каждый элемент - это сертификат для уполномоченного по сертификации, который выдает следующий сертификат. Это функциональный эквивалент следующему сертификату Х
<<X
>>. Например, обладание А<<В>>В<<С>> обеспечивает те же возможности, что и А<<С>>, а именно, способность найти С
данного А
|
|
Х
*X
<<X
>>
|
Операция развертывания сертификата (или цепочки сертификатов) для извлечения ключа общего пользования. Это - инфиксная операция, где левый операнд - ключ общего пользования уполномоченного по сертификации, а правый - сертификат, выданный уполномоченным по сертификации. В результате получаем ключ общего пользования того пользователя, сертификат которого - правый операнд. Например: А
*А<<В>>В<<С>> означает операцию, использующую ключ общего пользования пользователя А для получения ключа общего пользования В
пользователя В из его сертификата с последующим использованием В
для развертывания сертификата С. Результатом операции является ключ общего пользования С
пользователя С
|
|
А
В
|
Путь сертификации от А к В, сформированный из цепочки сертификатов, начинающийся с УС(А)<<УС
(А)>> и заканчивающийся с УС(В)<<В>>.
|
ГЛАВА 2. ПРОСТАЯ АУТЕНТИФИКАЦИЯ
6 Процедура простой аутентификации
Простая аутентификация предназначена для предоставления локальных полномочий на основе различительного имени пользователя, двусторонне согласованного (факультативно) пароля и двустороннего понимания способов использования и обработки этого пароля в пределах одного региона. Простая аутентификация предназначена в основном для локального использования, то есть для аутентификации равноправных логических объектов между одним АПС и одним АСС или между двумя АСС. Простая аутентификация может быть выполнена несколькими способами:
а) передачей различительного имени пользователя и (факультативно) пароля в открытом (незащищенном) тексте получателю для оценки;
b) передачей различительного имени пользователя, пароля и случайного числа и/или отметкой времени и всего того, что защищено применением однонаправленной функции;
с) передачей защищенной информации, описанной в b), вместе со случайным числом и/или отметкой времени и всего того, что защищено применением однонаправленной функции.
Примечания
1 Не предъявляется никаких требований к тому, чтобы применение однонаправленных функций было различным.
2 Сигнализация процедур защищающих паролей может быть поводом для расширения документа.
Если пароли не защищены, то предполагается минимальная степень защиты от несанкционированного доступа. Это не должно рассматриваться как основа услуг защиты. Защита различительного имени пользователя и пароля обеспечивает большую степень защиты. Алгоритмы, которые должны использоваться для механизма защиты, обычно не шифруются однонаправленными функциями, которые очень просты в реализации.
Общая процедура простой аутентификации приведена на рисунке 1.
Рисунок 1 - Процедура незащищенной простой аутентификации
Она состоит из следующих шагов:
1) пользователь - отправитель А посылает свои различительное имя и пароль пользователю - получателю В;
2) пользователь В посылает предполагаемое различительное имя и пароль пользователя А в справочник, где пароль проверяется относительно того пароля, который сохранен в виде атрибута парольПользователя в записи справочника для пользователя А, используя операцию сравнения справочника;
3) справочник подтверждает пользователю В (или отрицает) действительность удостоверения личности;
4) результат положительной (или отрицательной) аутентификации может быть передан пользователю А.
Самая простая форма аутентификации включает только шаг 1, а после проверки пользователем В различительного имени и пароля может выполняться шаг 4.
6.1 Генерация защищенной идентифицирующей информации
Обозначения:
А = Различительное имя пользователя
Рисунок 2 - Защищенная простая аутентификация
6.2 Процедура защищенной простой аутентификации
На рисунке 3 показана процедура защищенной простой аутентификации.
Рисунок 3 - Процедура защищенной простой аутентификации
Защита пароля пользователя А имеет вид:
Информация, переданная пользователю В, имеет вид:
Пользователь В проверяет защищенную идентифицирующую информацию, предлагаемую пользователем А путем создания (используя различительное имя и факультативно отметку времени и/или случайное число, обеспечиваемые пользователем А, вместе с локальной копией пароля пользователя А) локальной защищенной копии пароля пользователя А (в виде Защита1). Пользователь В сравнивает идентифицирующую информацию (Защита1) с локально созданным значением;
2) пользователь В подтверждает пользователю А (или отрицает) наличие защищенной идентифицирующей информации.
Информация, переданная В, имеет вид:
При выполнении операции сравнения В генерирует локальное значение дополнительно защищенного пароля и сравнивает его с значением Защита2 (в принципе это аналогично шагу 1 в 6.2
).
2) В подтверждает или отрицает для А верификацию защищенной идентифицирующей информации.
Примечание - Процедуры, описываемые в этих пунктах, определены в понятиях пользователей А и В. Применительно к справочнику (определенного в ГОСТ Р ИСО/МЭК 9594-3 и ИСО/МЭК 9594-4). АПС может быть привязана к АСС пользователя В; как вариант, пользователем А может быть АСС, связанный с другим АСС пользователя В.
6.3 Тип атрибута "пароль пользователя"
Этот тип атрибута содержит пароль объекта. Значение атрибута для пароля пользователя - это строка, определенная объектом.
|
|
|
|
userPassword ATTRIBUTE |
: : = { |
|
WITH SYNTAX |
OCTET STRING (SIZE(О.. ub-user-password)) |
|
EQUALITY MATCHING RULE |
octetStringMatch |
|
ID |
id-at-userPassword } |
ГЛАВА 3. СТРОГАЯ АУТЕНТИФИКАЦИЯ
7 Основы строгой аутентификации
Принятый в настоящей спецификации справочника подход к строгой аутентификации основан на использовании свойств семейства криптографических систем, известных под названием "криптосистемы ключа общего пользования" (ККОП). Такие криптосистемы, описываемые также как асимметричные, используют пару ключей, один - секретный, а другой - общего пользования вместо одного ключа в соответствующих криптографических системах.
Примечание - В будущем возможно введение других дополнительных типов ККОП, которые не должны требовать такого свойства перестановки и которые могут быть поддержаны этой спецификацией справочника без особых изменений.
Эти основы аутентификации не предписывают использования конкретной криптосистемы. Задача состоит в том, чтобы эти основы могли быть применимы к любой приемлемой криптосистеме ключа общего пользования и тем самым поддерживали изменения в используемых методах, возникающие в результате дальнейших усовершенствований в криптографии, математических методах или вычислительных возможностях. Однако два пользователя, желающие осуществить аутентификацию, должны для правильного ее выполнения поддерживать один и тот же криптографический алгоритм. Таким образом, в контексте набора соответствующих применений выбор единственного алгоритма должен обеспечить расширение общества пользователей, способных к осуществлению аутентификации и обеспечению защищенного обмена. Пример криптографического алгоритма приведен в приложении D.
Аутентификация рассчитана на любого пользователя, обладающего уникальным различительным именем. За распределение различительных имен несут ответственность уполномоченные по присвоению имен. Поэтому каждый пользователь должен доверить уполномоченным по присвоению имен право не выдавать дубликаты различительных имен.
Каждый пользователь идентифицируется на основе владения личным ключом. Другой пользователь может определить, обладает ли его партнер по обмену личным ключом, и может использовать это для подтверждения того, что партнером по обмену действительно является данный пользователь. Достоверность этого подтверждения зависит от личного ключа, являющегося конфиденциальным для пользователя.
Для того, чтобы пользователь мог определить, что партнер по обмену обладает личным ключом другого пользователя, он должен сам обладать ключом общего пользования этого пользователя. Если процедура получения значения ключа общего пользования непосредственно из записи пользователя в справочнике является достаточно прямолинейной, то проверка его правильности более проблематична. Существует несколько способов решения этой проблемы: в разделе 8 описан процесс, с помощью которого ключ общего пользования может быть проверен путем обращения к справочнику. Такой процесс может действовать только в том случае, если между пользователями, нуждающимися в аутентификации, существует непрерывная цепочка доверительных точек в справочнике. Такая цепочка может быть построена путем идентификации общей точки доверия. Эта общая точка должна быть связана с каждым пользователем непрерывной цепочкой доверительных точек.
8 Получение ключа общего пользования
Для того, чтобы пользователь доверял процедуре аутентификации, он должен получить ключ общего пользования других пользователей от источника, которому он доверяет. Такой источник, называемый уполномоченным по сертификации (УС), для сертификации ключа общего пользования использует алгоритм ключа общего пользования. Сертификат, форма которого будет определена ниже в этом разделе, обладает следующими свойствами:
- любой пользователь, имеющий доступ к ключу общего пользования уполномоченного по сертификации, может восстановить ключ общего пользования, который был подтвержден;
- никто другой, кроме уполномоченного по сертификации, не может изменить сертификат без того, чтобы это не было обнаружено (сертификаты неподдельны).
Поскольку сертификаты неподдельны, их можно сделать общедоступными, поместив в справочнике без необходимости принятия специальных мер по их защите.
Примечание - Хотя уполномоченные по сертификации недвусмысленно определены по их различительным именам в ДИС, это еще не означает наличие какого-либо взаимоотношения между организацией СУ и ДИС.
Уполномоченный по сертификации создает сертификат пользователя, подписывая (см. раздел 9) собранную информацию, которая включает различительное имя пользователя и его ключ общего пользования, а также факультативный уникальный идентификатор, содержащий дополнительную информацию о пользователе. Точная форма содержимого уникального идентификатора здесь не определяется и оставлена на усмотрение уполномоченного по сертификации; она может иметь вид, например, идентификатора объекта, сертификата, даты или некоторый другой вид сертификата достоверности различительного имени. В частности, сертификат пользователя с различительным именем А и уникальным идентификатором УА, созданный уполномоченным по сертификации с именем УС и уникальным идентификатором УУС, имеет вид:
|
|
|
|
Certificate : : = |
SIGNED{SEQUENCE { |
|
version |
[0] Version DEFAULT v1, |
|
serialNumber |
CertificateSerialNumber, |
|
signature |
AlgorithmIdentifier, |
|
issuer |
Name, |
|
validity |
Validity, |
|
subject |
Name, |
|
subjectPublicKeyInfo |
SubjectPublicKeyInfo, |
|
issuerUniqueIdentifier [1] IMPLICIT Uniqueldentifier OPTIONAL, - - при его наличии, должна быть версия v2 |
|
|
subjectUniqueIdentifier [2] IMPLICIT Uniqueldentifier OPTIONAL - - при его наличии, должна быть версия v2 - - }} |
|
|
Version |
: : = INTEGER {v1(0), v2(l)} |
|
CertificateSerialNumber |
: : = INTEGER |
|
Algorithmldentifier |
: : = SEQUENCE { |
|
algorithm |
ALGORITHM. &id ({SupportedAlgorithms}), |
|
parameters |
ALGORITHM. &Type ({SupportedAlgorithms}{Algorithm}) OPTIONAL } |
- Определение следующего набора информационных объектов отложено, возможно, до раз-
- работки стандартизованных профилей или заявок о соответствии реализации протоколу.
- Такой набор необходим для определения таблицы ограничений на компоненту "параметр"
- атрибута Algorithmldentifier.
- SuрроrtedAlgorithms ALGORITHM : : = {…I...}
|
|
|
|
|
Validity |
:: = SEQUENCE { |
|
|
notBefore |
UTCTime, |
|
|
notAfter |
UTCTime } |
|
|
SubjectPublicKeyInfo |
: : = SEQUENCE { |
|
|
algorithm |
Algorithmldentifier, |
|
|
subjectPublicKey |
BIT STRING } |
|
Примечание - В случаях, когда различительное имя может быть повторно назначено другому пользователю уполномоченным по присвоению имен, УС могут использовать уникальный идентификатор различения имен при многократном использовании. Однако, если одного и того же пользователя сертификатами обеспечивают несколько УС, рекомендуется, чтобы УС координировали присвоение уникальных идентификаторов в процессе выполнения процедур по регистрации пользователей.
Запись справочника каждого пользователя А, участвующего в строгой аутентификации, содержит сертификат(ы) А. Такой сертификат создается уполномоченным по сертификации пользователя А, являющимся логическим объектом в ДИС. Уполномоченный по сертификации пользователя А, который может быть не уникальным, обозначается УС(А), или просто УС, если А подразумевается. Поэтому ключ общего пользования пользователя А может быть открыт любым пользователем, который знает ключ общего пользования УС. Таким образом, процесс раскрытия ключей общего пользования является рекурсивным.
Если пользователь А, пытаясь получить ключ общего пользования пользователя В, уже получил ключ общего пользования УС(В), то процесс заканчивается. Для того, чтобы А мог получить ключ общего пользования УС(В), запись справочника каждого уполномоченного по сертификации Х содержит несколько сертификатов. Существует два типа таких сертификатов. К первому типу относятся срочные сертификаты X, созданные другими уполномоченными по сертификации. Ко второму - реверсивные сертификаты, созданные самим X, которые являются заверенными общими ключами других уполномоченных по сертификации. Наличие таких сертификатов позволяет пользователям строить путь сертификации от одной точки к другой.
- заканчивается сертификатом В.
Сертификаты хранятся в записях справочника в виде атрибутов типа UserCertificate, CACertificate и CrossCertificatePair. Эти типы атрибутов известны справочнику. Такие атрибуты могут действовать при использовании тех же операций протокола, которые используют другие атрибуты. Определения этих типов приведены в 3.3; спецификация этих типов атрибутов имеет следующий вид:
|
|
|
|
userCertificate |
ATTRIBUTE : : = { |
|
WITH SYNTAX |
Certificate |
|
ID |
id-at-userCertificate} |
|
cACertificate |
ATTRIBUTE : : = { |
|
WITH SYNTAX |
Certificate |
|
ID |
id-at-cAcertificate} |
|
CrossCertificatePair |
ATTRIBUTE : : = { |
|
WITH SYNTAX |
CertificatePair |
|
ID |
id-at-crossCertificatePair} |
|
CertificatePair : = |
SEQUENCE { |
|
forward [0] |
Certificate OPTIONAL, |
|
reverse [1] |
Certificate OPTIONAL |
- - Должна иметь место, по меньшей мере, одна из пар - - }
Пользователь может получить один или несколько сертификатов от одного или нескольких уполномоченных по сертификации. Каждый сертификат носит имя того уполномоченного по сертификации, который его выдал. Для представления сертификатов и пути сертификации могут быть использованы следующие типы данных АСН.1:
|
|
|
|
|
Certificates |
: : = |
SEQUENCE { |
|
userCertificate |
|
Certificate, |
|
certificationPath |
|
ForwardCertificationPath OPTIONAL } |
|
CertificationPath |
: : = |
SEQUENCE { |
|
userCertificate |
|
Certificate, |
|
theCACertificates |
|
SEQUENCE OF CertificatePair OPTIONAL } |
Кроме того, для представления срочного пути сертификации может быть использован следующий тип данных АСН.1. Эта компонента содержит путь сертификации, который может привести обратно к отправителю.
|
|
|
|
|
Forward CertificationPath |
: : = |
SEQUENCE OF CrossCertificates |
|
CrossCertificates |
: : = |
SET OF Certificate |
8.1 Оптимизация количества информации, полученной из справочника
В общем случае, прежде чем пользователи выполнят взаимную аутентификацию, справочник должен выполнить полную сертификацию и выдать путь аутентификации. Однако практически объем информации, которая должна быть получена из справочника, может быть сведена к конкретному сеансу аутентификации следующим образом:
a) если два пользователя, желающие выполнить аутентификацию, обслуживаются одним и тем же уполномоченным по сертификации, то путь сертификации становится тривиальным, и пользователи сами непосредственно сертифицируют друг друга;
b) если УС пользователей расположены иерархически, то пользователь должен хранить ключи общего пользования, сертификаты и повторные сертификаты всех уполномоченных между пользователем и корнем ДИС. Обычно это требует от пользователя знания ключей общего пользования и сертификатов только трех или четырех уполномоченных по сертификации. При этом пользователю потребуется только получить путь сертификации от общей точки доверия;
c) если пользователь часто связывается с другими пользователями, получившими сертификаты от другого конкретного УС, то для того чтобы такой пользователь мог узнать путь сертификации к этому УС и обратный путь от него, ему необходимо только получить сертификат другого пользователя из справочника;
d) уполномоченные по сертификации могут пересекаться друг с другом при выдаче сертификатов на основе двустороннего соглашения. Результатом является более короткий путь сертификации;
e) если два пользователя взаимодействовали до этого и знают сертификаты друг друга, они могут выполнить аутентификацию без какого-либо обращения к справочнику.
В любом случае, определив сертификаты других из пути сертификации, пользователи должны проверить действительность полученных сертификатов.
8.2 Пример
На рисунке 4 приведен гипотетический пример фрагмента ДИС, где УС образуют иерархию. Считается, что кроме информации, приведенной в УС, каждый пользователь знает ключ общего пользования своего уполномоченного по сертификации, свои собственные ключ общего пользования и личный ключ.
Рисунок 4 - Иерархия. Гипотетический пример
Если УС пользователей расположены иерархически, пользователь А для установления пути сертификации к пользователю В может получать из справочника следующие сертификаты:
X<<W>>, W<<V>>, V<<Y>>, Y<<Z>>, Z<<B>>
В общем случае, пользователь А должен получить следующие сертификаты из справочника, чтобы установить обратный путь сертификации от В к А:
Z<<Y>>, Y<<V>>, V<<W>>, W<<X>>, X<<A>>
Применяя оптимизацию в соответствии с 8.1:
a) возьмем, например, А и С:
а развернутый обратный путь сертификации сводится к
V<<Y>>, Y<<Z>>, Z<<B>>,
а информация, которую А должен получить из справочника для формирования обратного пути сертификации, сводится к Z<<Y>>, Y<<V>>;
c) предполагая, что А часто взаимодействует с пользователями, получившими сертификаты от Z, он может узнать [дополнительно к ключам общего пользования, известных из b)] V<<Y>>, Y<<V>>, Y<<Z>>, и Z<<Y>>. Для того, чтобы связаться с В, ему, следовательно, необходимо только получить из справочника Z<<B>>;
d) предполагая, что пользователи, получившие сертификаты от Х и Z, часто взаимодействуют между собой, X<<Z>> должен храниться в записи справочника для X, и наоборот (как приведено на рисунке 4). Если А желает выполнить аутентификацию с В, ему необходимо только получить:
X<<Z>>, Z<<B>>
для формирования пути аутентификации и
Z<<X>>
для формирования обратного пути аутентификации;
е) предполагая, что пользователи А и С уже взаимодействовали ранее и знают сертификаты друг друга, они могут использовать непосредственно ключ общего пользования друг друга, то есть,
и
В более общем случае уполномоченные по сертификации иерархически не взаимосвязаны. Обращаясь к гипотетическому примеру на рисунке 5, предположим, что пользователь D, получивший сертификат от U, желает выполнить аутентификацию с пользователем Е, получившим сертификат от W. Запись пользователя D в справочнике должна содержать сертификат U<<D>>, а запись пользователя Е - сертификат W<<E>>.
Рисунок 5 - Пример неиерархического пути сертификации
Пусть V - это УС, с которым уполномоченные по сертификации U и W в предыдущий раз обменялись ключами общего пользования доверительным способом. В результате были созданы сертификаты U<<V>>, V<<U>>, W<<V>> и 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<<U>>, U<<D>>.
9 Цифровые подписи
В этом разделе не ставится задача создать общий стандарт по цифровым подписям, а только определить средства, с помощью которых маркеры подписываются в справочнике.
Информация (инф) подписывается путем добавления к ней зашифрованной сводки информации. Эта сводка вырабатывается с использованием однонаправленной хеш-функции, а шифрование выполняется с использованием личного ключа подписывающего лица (см. рисунок 6).
Таким образом
Х {Инф} = Инф, Хл [h (Инф)]
Рисунок 6 - Цифровые подписи
Примечание - Шифрование, использующее личный ключ, гарантирует, что подпись не может быть подделана. Свойство однонаправленности хеш-функции гарантирует, что ложная информация, которая вырабатывается так, чтобы иметь тот же результат хеширования (и, тем самым, подпись), не может послужить заменой.
Получатель подписанной информации проверяет подпись путем:
- применения к информации однонаправленной хеш-функции,
- сравнением результата с полученной после дешифрования подписью, используя общий ключ подписывающего лица.
Настоящий стандарт не предписывает использовать для подписания единственную однонаправленную хеш-функцию. Задача состоит в том, чтобы стандартизуемые здесь основы аутентификации могли быть применимы к любой подходящей хеш-функции и могли таким образом поддерживать изменения в используемых методах, которые могут появиться в результате будущих усовершенствований в криптографии, математических методах или вычислительных возможностях. Однако два пользователя, желающие выполнить правильно аутентификацию, должны обеспечивать одну и ту же хеш-функцию. Таким образом, в контексте набора соответствующих применений выбор единственной функции должен послужить максимизации количества пользователей, способных выполнить аутентификации и обеспечить надежный обмен данными.
Подписанная информация включает указатели, которые идентифицируют алгоритмы хеширования и шифрования, используемые для вычисления цифровой подписи.
Шифрование некоторого элемента данных может быть описано в АСН.1 следующим образом:
ENCRYPTED {ToBeEnciphered}: : = BIT STRING (CONSTRAINED BY {
- - применение процедуры шифрования должно приводить - -
- - к закодированным по базовым правилам кодирования
- - октетам значения - - ToBeEnciphered })
Это значение строки битов образуется из октетов, которые создают полное кодирование (используя базовые правила кодирования АСН.1 по ГОСТ Р ИСО/МЭК 8825) значения типа ToBeEnciphered, путем применения процедуры шифрования к этим октетам.
Примечания
1 Процедура шифрования требует наличия соглашения по применяемому алгоритму, включая все параметры алгоритма, такие как необходимые ключи, значения инициализации и инструкции заполнения. Процедуры шифрования несут ответственность за определение средств, с помощью которых достигается синхронизация отправителя и получателя данных, которые могут включать в передаваемые биты свою информацию.
2 Требуется, чтобы процедура шифрования воспринимала на входе строки октетов и вырабатывала результат в виде одной строки битов.
3 Механизмы согласования защиты по алгоритму шифрования и их параметрам отправителем и получателем данных не входит в предмет рассмотрения настоящего стандарта.
В случае, когда подпись может быть присоединена к типу данных, то для определения типа данных, полученного в результате применения подписи к данному типу данных, может быть использовано следующее описание АСН.1
|
|
|
|
SIGNED {ToBeSigned} |
:: = 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 должны кодироваться в порядке возрастания значений их октетов;
g) при наличии неиспользуемых битов в последнем октете закодированных строк битов они должны быть установлены в 0;
h) при кодировании типа Real не должны использоваться основания 8, 10, и 16, а коэффициент двоичного масштабирования должен быть нулевым.
Для получения полной версии документа обратитесь в нашу компанию Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в вашем браузере должен быть включен Javascript.
