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

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

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

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

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

X {Инф} = Инф, Xл [h (Инф)]

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

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

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

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

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

Шифрование некоторого элемента данных может быть описано в АСН.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 {
      algorithmidentifier           Algorithmidentifier,
      encrypted                     ENCRYPTED {HASHED {OfSignature}}}

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

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

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

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

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

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

f) если булев тип имеет значение «истинно», то в результате кодирования содержимое октета должно быть установлено в <<FF>>_{16} ;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. A создает r^{A} (неповторяющийся номер), который используется для обнаружения повторных угроз и предотвращения подделок;

2. A посылает следующее сообщение к B:

B \rightarrow A,A{t^{A},r^{A},B} ,

где t^{A} — отметка времени, которая состоит из одной или двух дат: даты создания маркера (который является факультативным) и даты истечения срока действия. Как вариант, если аутентификация отправителя данных «sgnData» должна обеспечиваться цифровой подписью, сообщение будет иметь вид:

B \rightarrow A,A{t^{A},r^{A},B,sgnData} .

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

B \rightarrow A,A{t^{A},r^{A},B,sgnData,B_{o}[encData]} .

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

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

a) получает A_{o} от B -> A, проверяя, что срок сертификата пользователя A не истек;

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

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

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

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

r^{A} имеет силу до истечения даты, указанной t^{A} . r^{A} всегда сопровождается последовательной частью, которая указывает, что A не должен повторять маркер в течение временного диапазона t^{A} , и поэтому проверка значения самого r^{A} не требуется.

В любом случае для стороны B целесообразно хранить в течение временнуго диапазона t^{A} последовательную часть вместе с отметкой времени t^{A} в открытом состоянии и вместе с хешированной частью маркера.

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

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

1. Как и в 10.2.

2. Как и в 10.2.

3. Как и в 10.2.

4. B создает r^{B} (неповторяющийся номер), используемый для тех же целей, что и r^{A} .

5. B посылает к A маркер последующей аутентификации:

B{t^{B},r^{B},A,r^{A}} ,

где t^{B} — отметка времени, определенная тем же самым способом, что и t^{A} .

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

B{t^{B},r^{B},A,r^{A},sgnData} .

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

B{t^{B},r^{B},A,r^{A},sgnData,Ap[encData]} .

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

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

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

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

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

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

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

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

1. Как и в 10.3.

2. Как и в 10.3. Отметка времени t^{A} может быть нулевой.

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

4. Как и в 10.3.

5. Как и в 10.3. Отметка времени t^{B} может быть нулевой.

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

7. Проверяет, идентичен ли полученный r^{A} переданному r^{A} .

8. A посылает к B следующий маркер аутентификации:

A{r^{B},B} .

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

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

b) проверяет, что полученный r^{B} идентичен r^{B} , переданному стороной B.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ответственность за поддержание записей справочника, подверженных воздействию отмененных УС из списка, возлагается на справочник и его пользователей, действующих в соответствии со стратегией защиты. Например, пользователь может модифицировать свою запись объекта, заменяя старый сертификат на новый. После этого последний может использоваться для аутентификации пользователя в справочнике;
• списки отмененных сертификатов («черные списки») хранятся в записях в виде атрибутов типа «CertificateRevocation» и «authorityRevocationList». Эти атрибуты могут обрабатываться с использованием тех же операций, что и другие атрибуты. Эти типы атрибутов определяются следующим образом:

    certificateRevocationList         ATTRIBUTE :: = {
        WITH SYNTAX                   CertificateList
        ID                            id-at-certificateRevocationList}
    authorityRevocationList           ATTRIBUTE :: = {
        WITH SYNTAX                   CertificateList
        ID                            id-at-authorityRevocationList}
    CertificateList                   :: =    SIGNED {SEQUENCE {
        signature                     Algorithmidentifier,
        issuer                        Name
        thisUpdate                    UTCTime,
        nextUpdate                    UTCTime OPTIONAL,
        revokedCertificates           SEOUENCE OF SEQUENCE {
            userCertificate             CertificateSerialNumber,
            revocationDate              UTCTime} OPTIONAL}}

Примечания

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

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

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

AuthentificationFramework {joint-iso-ccitt ds(5) module(1)

authentificationFramework(7) 2}

DEFINITIONS :: =

BEGIN

• - EXPORTS ALL -
• - Определенные в этом модуле типы и значения экспортируются для
• • использования в других модулях АСН.1, содержащихся в спецификациях
• • справочника, и в других прикладных программах, которые, в свою очередь,
• • будут использовать их для доступа к услугам справочника. Другие
• • прикладные программы могут использовать эти типы и значения для своих
• • собственных целей, но это не должно препятствовать расширениям и
• • модификациям, необходимым при обслуживании или усовершенствовании услуг
• • справочника.

IMPORTS

id-at, informationFramework, upperBounds, selectedAttributeTypes,

basicAccessControl

FROM UsefulDefinitions {joint-iso-ccitt ds(5) module(1)

usefulDefinitions(0) 2}

Name, ATTRIBUTE

FROM InformationFramework informationFramework

ub-user-password

FROM UpperBounds upperBounds

AuthentificationLevel

FROM BasicAccessControl basicAccessControl

Uniqueidentifier, octetStringMatch

FROM SelectedAttributeTypes selectedAttributeTypes;

• - Типы — -

  Certificate               :: =   SIGNED {SEQUENCE{
      version                      [0] Version DEFAULT v1,
      serialNumber                   CertificateSerialNumber,
      signature                      Algorithmidentifier,
      issuer                         Name,
      validity                       Validity,
      subject                        Name,
      subjectPublicKeyinfo           SubJectPublicKeyinfo,
      issuerUniqueIdentifier       [1] IMPLICIT Uniqueidentifier OPTIONAL,

          - <a id="p100515"></a>- при его наличии, должна быть версия v2 - -}}

subjectUniqueidentifier [2] IMPLICIT Uniqueidentifier OPTIONAL, - - при его наличии, должна быть версия v2 — -}}

  Version                   :: =   INTEGER { v1(0), v2(1) }
  CertificateSerialNumber   :: =   INTEGER
  Algorithmidentifier       :: =   SEQUENCE {
    algorithm               ALGORITHM.&id ({SupporteadAlgorithms}),
    parameters              ALGORITHM.&Type ({SupporteadAlgorithms}

{Algorithms}) OPTIONAL}

• Определение следующего набора информационных объектов отложено,
• возможно, до разработки стандартизованных профилей или заявок о
• соответствии реализации протоколу. Такой набор необходим для
• определения табличных ограничений на компоненту «параметры» атрибута
• Algorithmidentifier.
• SupporteadAlgorithms ALGORITHM :: = {...I...}

  Validity                  :: =   SEQUENCE {
    notBefore        UTCTime,
    notAfter         UTCTime }
  SubjectPublicKeyinfo      :: =   SEQUENCE {
    algorithm                      Algorithmidentifier,
    subjectPublicKey               BIT STRING }
  Certificates              :: =   SEQUENCE {
    userCertificate                Certificate,
    certificationPath              ForwardCertificationPath OPTIONAL}
  ForwardCertificationPath  :: =   SEQUENCE OF CrossCertificates
  CertificationPath         :: =   SEQUENCE {
    userCertificate                Certificate,
    theCACertificates              SEQUENCE OF CertificatePairOPTIONAL }
  CrossCertificates         :: =   SET OF Certificate
  CertificateList           :: =   SIGNED {SEQUENCE{
    signature                      Algorithmidentifier,
    issuer                         Name,
    this Update                    UTCTime,
    nextUpdate                     UTCTime OPTIONAL,
    revokedCertificates            SEQUENCE OF SEQUENCE {
      userCertificate                CertificateSerialNumber,
      revocationDate                 UTCTime } OPTIONAL}}
  CertificatePair           :: =   SEQUENCE (
    forward        [0]      Certificate OPTIONAL,
    reverse        [1]      Certificate OPTIONAL

  - <a id="p100551"></a>- Должна иметь место, по меньшей мере, одна из пар - -}
- <a id="p100552"></a>- Типы атрибутов - -

  userPassword                     ATTRIBUTE :: = {
    WITH SYNTAX                    OCTET STRING (SIZE

(O..ub-user-password))

    EQUALITY MATCHING RULE         octetStringMatch
    ID                               id-at-userPassword }
userCertificate             ATTRIBUTE :: = {
  WITH SYNTAX               Certificate
  ID                        id-at-userCertificate }
cACertificate               ATTRIBUTE :: = {
  WITH SYNTAX               Certificate
  ID                        id-at-cAcertificate }
authorityRevocationList     ATTRIBUTE :: = {
  WITH SYNTAX               CertificateList
  ID                        id-at-authorityRevocationList }
certificateRevocationList   ATTRIBUTE :: = {
  WITH SYNTAX               CertificateList
  ID                        id-at-CertificateRevocationList }
crossCertificatePair        ATTRIBUTE :: = {
      WITH SYNTAX               CertificatePair
      ID                        id-at-crossCertificatePair }

• - Классы информационных объектов — -

ALGORITHM :: = TYPE-IDENTIFIER

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

HASHED {ToBeHashed} :: = OCTET STRING (CONSTRAINED-BY {

• - должно быть результатом применения процедуры хеширования к октетам значения параметра ToBeHashed, закодированным в соответствии с базовыми правилами кодирования (см. 8.7}) — -

ENCRYPTED {ToBeEnciphered} :: = BIT STRING (CONSTRAINED BY {

• - должно быть результатом применения процедуры шифрования к октетам значения параметра ToBeEnciphered, закодированным в соответствии с базовыми правилами кодирования (см. 8.7) }) — -

SIGNED {ToBeSigned}           :: =    SEQUENCE {
      toBeSigned                      ToBeSigned,
      COMPONENTS OF                   SIGNATURE {ToBeSigned}}
SIGNATURE {OfSignature}       :: =    SEQUENCE {
      algorithmidentifier             Algorithmidentifier,
      encrypted                       ENCRYPTED {HASHED {OfSignature}}}

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

id-at-userPassword                    OBJECT IDENTIFIER :: = {id-at 35}
id-at-userCertificate                 OBJECT IDENTIFIER :: = {id-at 36}
id-at-cAcertificate                   OBJECT IDENTIFIER :: = {id-at 37}
id-at-authorityRevocationList         OBJECT IDENTIFIER :: = {id-at 38}
id-at-certificateRevocationList       OBJECT IDENTIFIER :: = {id-at 39}
id-at-crossCertificatePair            OBJECT IDENTIFIER :: = {id-at 40}

END

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

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

B.1. Угрозы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

B.3. Механизмы защиты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Однако в криптографических системах ключей общего пользования (ККОП) ключи вводятся парами: один для шифрования, другой для дешифрования. Каждая пара ключей связана с конкретным пользователем X. Один из ключей, общеизвестный как ключ общего пользования (X_{o}) , может быть использован любым пользователем для шифрования данных. Только X, который обладает дополнительным личным ключом (X_{\text{л}}) , может расшифровать данные. (В нотации это представлено в виде: D = X_{\text{л}}[X_{o}[D]] ). Вычислительным путем невозможно получить личный ключ, зная ключ общего пользования. Любой пользователь может таким образом обмениваться частью информации, обнаружить которую может только X, зашифровав ее с помощью X_{\text{л}} . С помощью некоторого расширения два пользователя могут обмениваться секретно, используя ключ общего пользования друг друга для шифрования данных, как показано на рисунке C.1.

Пользователь A имеет ключ общего пользования A_{o} и личный ключ A_{\text{л}} , а пользователь B имеет другой набор ключей: \text{В}_{o} и B_{\text{л}} . A и B знают ключи общего пользования друг друга, но не знают личный ключ другой стороны. Поэтому A и B могут обмениваться секретной информацией друг с другом, используя следующие шаги (см. рисунок B.1).

1. Пользователь A желает послать некоторую секретную информацию x к B. Для этого A шифрует x, используя ключ шифрования B, и посылает зашифрованную информацию e к B. Это представлено в виде:

e = Bp[x|.

2. Пользователь B может теперь расшифровать зашифрованную информацию e для получения информации x, используя секретный ключ расшифрования B_{\text{л}} . Заметим, что поскольку B является единственным владельцем ключа B_{\text{л}} и этот ключ никогда не может быть раскрыт или передан, то для любой другой стороны невозможно получить информацию x. Владелец B_{\text{л}} определяет идентичность B. Операцию расшифрования можно представить в виде:

x = B_{\text{л}}[e] или x = B_{\text{л}}[\text{В}_{o}[x]] .

3. Теперь B может точно так же послать A некоторую секретную информацию x', используя секретный ключ A, A_{o} :

e\prime = A_{o}[x\prime]

4. A получает x' путем дешифрования e'.

x\prime = A_{\text{л}}[e\prime] или x\prime = A_{\text{л}}{A_{o}[x\prime]} .

Таким способом A и B обмениваются секретной информацией x и x'. Эта информация не может быть получена никем другим, кроме A и B, при условии, что их личные ключи не раскрыты.

Такой обмен, как и передача секретной информации между сторонами, может быть использован для проверки их идентичности. В частности, A и B идентифицируются по обладанию ими секретными ключами дешифрования A_{\text{л}} и B_{\text{л}} соответственно. A может определить, обладает ли B секретным ключом дешифрования B_{\text{л}} , получая возвращаемую часть своей информации x в сообщении x'. Это показывает A, что обмен происходит с обладателем B_{\text{л}} . B аналогично может проверить идентичность A.

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

Примечания

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

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

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

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

D.2. Определения

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

Примечание. Элемент данных в АСН.1 "subjectPublicKey", определенный в виде битовой строки (см. Приложение A), должен интерпретироваться в случае RSA как:

SEOUENCE (INTEGER, INTEGER),

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

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

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

X, Y - блоки данных, которые арифметически меньше модуля

n - арифметический модуль

e - показатель степени общего пользования

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

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

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

lcm - наименьший множитель

mod n - арифметический модуль n.

D.4. Описание

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

Y = X^{e}modn при 0 <= X < n

X = Y^{e}modn при 0 < Y < n

Эти условия могут быть выполнены, например, при

ed mod lcm(p - 1, q - 1) = 1 или

ed mod (p - l) (q - 1) = 1

Чтобы этот процесс действовал, блок данных должен интерпретироваться как целое число. Это достигается рассмотрением всего блока данных в виде упорядоченной последовательности битов (длиной \lambda ). При этом целое число формируется как сумма битов после назначения первому биту веса 2\lambda^{- 1} к первому биту и делением на 2 каждого последующего бита (последний бит имеет вес 1).

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

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

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

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

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

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

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

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

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

d) lp - q должен иметь большое значение;

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

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

g) (p - 1) должен иметь большую величину первичного фактора, например, r,

h) (q - 1) должен иметь большую величину первичного фактора, например, s;

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

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

После создания ключа общего пользования и личного ключа, например "X_{o}" и "X_{\text{л}}" , как определено в разделах 3 и 4 настоящего стандарта, содержащих d, e и n, значения p и q вместе со всеми другими данными, полученными в результате умножения (p - 1) (q - 1), и первичные факторы, имеющие большие значения, должны быть аннулированы. Однако, сохраняя p и q локально, можно повысить производительность дешифрования в два - четыре раза. Считается, что сохранение p и q должно решаться локально.

Должно быть обеспечено соотношение e>log_{2}(n) . Если оно не обеспечено, то простая операция извлечения корня целочисленной степени e блока шифротекста может раскрывать открытый текст.

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

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

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

F_{4} = 2^{2^{4}} + 1

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

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

Примечания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

G.1. Введение

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

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

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

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

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

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

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

Данное приложение определяет идентификаторы объектов, используемых в алгоритмах аутентификации и шифрования, при отсутствии формального регистра. Предполагается использовать такой регистр, как только он станет доступным. Определения используют форму модуля АСН.1, "AlgorithmObjectidentifiers".

AlgorithmObjectidentifiers joint-iso-ccitt ds(5) module(1)

algorithmObjectIdentifiers(8) 2}

DEFINITIONS :: =

BEGIN

• EXPORTS ALL -
• - Определенные в этом модуле типы и значения экспортируются
• • для использования в других модулях АСН.1, содержащихся в
• • спецификациях справочника, и другими прикладными программами,
• • которые будут, в свою очередь, использовать их для доступа к услугам
• • справочника. Другие прикладные программы могут использовать их для
• • своих собственных целей, но это не препятствует расширениям и
• • модификациям, необходимым при обслуживании или усовершенствовании
• • справочной службы.

IMPORTS

algorithm, authenticationFramework

FROM UsefulDefinitions {joint-iso-ccitt ds(5) module(1)

usefulDefinitions(0) 2}

ALGORITHM

FROM AuthentificationFramework authentificationFramework;

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

encryptionAlgorithm     OBJECT IDENTIFIER  :: = {algorithm 1}
hashAlgorithm           OBJECT IDENTIFIER  :: = {algorithm 2}
signatureAlgorithm      OBJECT IDENTIFIER  :: = {algorithm 3}

• - Синонимы — -

id-ea OBJECT IDENTIFIER    :: =   encryptionAlgorithm
id-ha OBJECT IDENTIFIER    :: =   hashAlgorithm
id-sa OBJECT IDENTIFIER    :: =   signatureAlgorithm

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

rsa ALGORITHM :: = {

KeySize

    IDENTIFIED BY       id-ea-rsa }
KeySize        :: =     INTEGER

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

id a-rsa OBJECT IDENTIFIER :: = {id-ea 1}

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

предназначенные для предупреждающих функций

id-ha-sqMod-n OBJECT IDENTIFIER            :: = {id-ha 1}
id-sa-sqMod-nWithRSA OBJECT IDENTIFIER     :: = {id-sa 1}

END

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 Couvreur, c. Fast Decipherment Algorithm for RSA Public-key Cryptosystems, Electronics Letters, 18 — 21 (October 14, 1982), 905 — 907