Протоколы безопасного сетевого взаимодействия
Лапонина Ольга Робертовна

Содержание


Лекция 1. Инфраструктура Открытого Ключа (часть 1)

Рассматривается стандартная нотация для определения типов и значений данных – Abstract Syntax Notation One (ASN.1). Определены простые и структурные типы. Введено понятие идентификатора объекта. Рассматриваются основные понятия, связанные с инфраструктурой открытого ключа: сертификат открытого ключа, удостоверяющий (сертификационный) центр, конечный участник, регистрационный центр, CRL, политика сертификата, регламент сертификационной практики, проверяющая сторона, репозиторий. Описана архитектура PKI.

ASN.1: спецификация базовой нотации

Введение

В этой лекции мы кратко рассмотрим стандартную нотацию для определения типов и значений данных – Abstract Syntax Notation One (ASN.1). Значение данных является экземпляром определенного типа. Стандарт ASN.1 определяет несколько базовых типов и синтаксис соответствующих им значений, а также правила для получения составных типов и значений.

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

Данная нотация, с одной стороны, интуитивно понятна, а с другой стороны, может использоваться как протоколами, так и программными системами. Неотъемлемой частью ASN.1 являются базовые правила представления BER (Basic Encoding Rules). BER описывает принцип представления любой величины в рамках стандарта ASN.1. Практически все величины представляются в виде последовательности 8-битных октетов. Восьмой бит октета считается самым старшим. BER позволяет представить величину в виде последовательности 8-битных октетов несколькими способами. Имеется также поднабор правил представления DER (Distinguished Encoding Rules), который определяют однозначные способы представления величин в ASN.1 .

Ниже приведены базовые правила обозначений в ASN.1. Все нотации ASN.1 будут печататься шрифтом Courier New.

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

[] – квадратные скобки указывают на то, что терм является необязательным;

{} – фигурные скобки группируют родственные термы;

| – вертикальная черта выделяет альтернативные значения;

... – многоточие обозначает повторения;

= – знак равенства описывает терм как подтерм.

ASN.1 определяет следующие разновидности типов: простые типы, не имеющие компонентов, структурные типы, имеющие компоненты, помеченные (тегированные – tagged) типы, которые получаются из других типов добавлением метки (тега), а также такие типы, как CHOICE, ANY и некоторые другие. Типам и значениям могут присваиваться имена с помощью оператора присваивания " ::= ". Эти имена в дальнейшем могут использоваться для определения других типов и значений.

Определены следующие простые типы:

INTEGER – любое целое число;

BIT STRING – произвольная строка бит;

OCTET STRING – произвольная последовательность октетов;

NULL0 ;

OBJECT IDENTIFIER – последовательность компонентов, однозначно идентифицирующих объект;

PrintableString – последовательность печатных символов;

IA5String – произвольная строка символов IA5 (ASCII);

UTCTime – универсальное время (по Гринвичу; GMT).

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

В ASN.1 определено четыре структурных типа:

SEQUENCE – упорядоченный набор из одного или более типов, некоторые из которых могут быть объявлены как необязательные.

SEQUENCE OF – упорядоченный набор из нуля или более значений данного типа.

SET – неупорядоченный набор из одного или более типов, некоторые из которых могут быть объявлены как необязательные.

SET OF – неупорядоченный набор из нуля или более значений данного типа.

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

Типы могут быть помечены явно или неявно. Неявно помеченные типы получаются из других типов путем изменения метки. Для неявной пометки используется ключевое слово IMPLICIT. Явно помеченные типы получаются из других типов путем добавления внешней метки. Для явной пометки используется ключевое слово EXPLICIT. Помеченный явно тип – это структурный тип, состоящий из одного существующего типа и тега. Пометка (тегирование) весьма удобна, чтобы различать типы в пределах одного приложения.

Тегированный тип является новым типом, который изоморфен старому, но имеет отличный от него тег.

TaggedType ::= Tag Type
             | Tag IMPLICIT Type
             | Tag EXPLICIT Type
Tag ::= [ Class ClassNumber ]
ClassNumber ::= Number | DefinedValue
Class ::= UNIVERSAL
        | APPLICATION
        | PRIVATE
        | empty

DefinedValue должно быть типом целого и иметь неотрицательное значение.

Битовые строки

Тип BIT STRING обозначает битовые последовательности произвольной длины (включая ноль). Нотация BIT STRING имеет формат.

BIT STRING

Например, тип SubjectPublicKeyInfo имеет компонент PublicKey типа BIT STRING :

SubjectPublicKeyInfo ::= SEQUENCE {
    Algorithm AlgorithmIdentifier,
    PublicKey BIT STRING
}

Строки IA5

Тип IA5String представляет любые последовательности IA5-символов (международный алфавит 5 – эквивалентно ASCII). Длина строки может быть любой, включая нуль. Этот тип используется для адресов электронной почты и неструктурированных имен. Нотация типа IA5String имеет простой формат.

IA5String

Целое

Тип INTEGER представляет любые целые числа (положительные, отрицательные или 0 ). Тип INTEGER используется для номеров версий, криптографических параметров (показателей, модулей и т.п.) и типов RSAPublicKey, RSAPrivatKey, DHParameter, PBEParameter. Нотация типа INTEGER имеет формат:

INTEGER [{identifier1(value1)
    ... identifiern(valuen) }]

где identifier1... identifiern являются необязательными идентификаторами, а value1... valuen целые значения. Например, Version является целым типом со значением 0:

Version ::= INTEGER { v1988(0) }

Идентификатору v1988 поставлено в соответствие значение 0. Тип Certificate использует идентификатор v1988 для присвоения значения по умолчанию компоненту version:

Certificate 
version Version DEFAULT v1988,
...

NULL

Тип NULL обозначает нулевую величину и предназначен для использования в качестве параметра алгоритмов. Нотация для типа NULL имеет формат:

NULL

Идентификаторы объектов

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

Нотация OBJECT IDENTIFIER имеет формат:

OBJECT IDENTIFIER

Нотация значения OBJECT IDENTIFIER имеет вид:

{ [identifier] component1 ... componentn}
componenti = identifieri |
             identifieri (valuei) |
             valuei

где identifier, identifier1, ... identifiern являются идентификаторами, а value1..., valuen – целые числа.

Например, приведенные ниже величины идентификаторов объектов присвоены RSA DATA Security, Inc.

{ iso(1) member-body(2) 840 113549 }
{ 1 2 840 113549 }

Ниже приведены некоторые идентификаторы объектов и их значения.

Таблица 13.1. Идентификаторы объектов и их значения
Величина идентификатора объектаНазначение
{ 1 2 }Члены ISO
{ 1 2 840 }US (ANSI)
{ 1 2 840 113549}RSA Data Security, Inc.

Строки октетов

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

OCTET STRING [SIZE ({size |
                     size1..size2})]

где size, size1 и size2 – необязательные ограничения размера. В формате OCTET STRING SIZE (size) строка октетов должна иметь size октетов. В формате OCTET STRING SIZE (size1 .. size2) строка должна содержать число октетов между size1 и size2. Например, тип PBEParameter имеет компоненту типа OCTET STRING :

PBEParameter ::= SEQUENCE {
    salt OCTET STRING SIZE (8),
    iterationCount INTEGER 
}

Здесь размер компоненты salt всегда равен 8 октетам.

Строки печатных символов

Тип PrintableString предназначен для описания произвольных последовательностей печатных символов из набора:

A,B,...,Z
a,b,...,z
0,1,...,9
(пробел) ‘ () +, – . / : = ?

Этот тип используется для представления атрибутов имен. Нотация типа PrintableString имеет вид:

PrintableString

Тип CHOICE

Этот тип служит для объединения одной или более альтернатив. Нотация типа CHOICE имеет формат

CHOICE {
    [identifier1] Type1,
    ...,
    [identifiern] Typen
}

где identifier1, ..., identifiern являются необязательными идентификаторами альтернатив, а типы Type1, ..., Typen – альтернативы. Идентификаторы нужны для документирования и не играют какой-либо роли при представлении. Рассмотрим пример типа ExtendedCertificateOrCertificate, который относится к типу CHOICE.

ExtendedCertificateOrCertificate ::=
    CHOICE {
        certificate Certificate, 
        extendedCertificate [0]
            IMPLICIT ExtendedCertificate
}

Здесь идентификаторами для альтернатив являются certificate и extendedCertificate, а сами альтернативы представлены типами Certificate и [0] IMPLICIT ExtendedCertificate.

Тип SEQUENCE

Тип SEQUENCE обозначает упорядоченную последовательность одного или более типов. Нотация типа SEQUENCE имеет вид:

SEQUENCE {
    [identifier1] Type1 [{OPTIONAL |
                 DEFAULT value1}],
    ...,
    [identifiern] Typen [{OPTIONAL |
                 DEFAULT valuen}],
}

где identifier1, ..., identifiern являются необязательными идентификаторами компонентов, Type1, ..., Typen – типы компонентов, а value1,..., valuen – необязательные значения компонентов по умолчанию. Квалификатор OPTIONAL указывает на то, что компонент является необязательным. Квалификатор DEFAULT говорит о том, что компонент является необязательным и ему присваивается определенное значение, если компонент отсутствует. Например, тип Validity относится к типу SEQUENCE и имеет два компонента.

Validity ::= SEQUENCE {
    start UTCTime,
    end UTCTime
}

Здесь start и end являются идентификаторами компонентов, а типом компонентов служит UTCTime.

Тип SEQUENCE OF

Тип SEQUENCE OF обозначает упорядоченную последовательность из нуля или более значений компонентов данного типа. Нотация SEQUENCE OF имеет вид:

SEQUENCE OF Type

Так, например, тип RNDSequence состоит из нуля или более значений компонентов типа RelativeDistinguishedName.

RNDSequence ::= SEQUENCE OF
    RelativeDistinguishedName

Тип SET

Тип SET представляет собой неупорядоченное объединение из одного или более типов. Нотация типа SET имеет вид.

SET {
    [identifier1] Type1
      [{OPTIONAL | DEFAULT value1}],
    ...,
    [identifiern] Typen
      [{OPTIONAL | DEFAULT valuen}],
}

где identifier1, ..., identifiern являются необязательными идентификаторами компонентов, Type1, ..., Typen – типы компонентов, а value1,..., valuen – необязательные значения компонентов по умолчанию. Квалификатор OPTIONAL указывает на то, что значения компонентов являются необязательными. Квалификатор DEFAULT говорит о том, что наличие компонента является необязательным, и ему присваивается определенное значение, если компонент отсутствует.

Тип SET OF

Тип SET OF является неупорядоченным набором, состоящим из нуля или более значений компонентов заданного типа. Нотация типа SET OF имеет вид:

SET OF Type

где Type – тип. Так, тип RelativeDistinguishedName состоит из нуля или более компонентов типа AttributeValueAssertion.

RelativeDistinguishedName ::= SET OF 
    AttributeValueAssertion

Тип ANY

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

ANY [DEFINED BY identifier]

где identifier – необязательный идентификатор. Форма ANY DEFINED BY identifier может появиться только в компоненте типа SEQUNCE или SET , для которого identifier определяет какой-то другой компонент и этот компонент имеет тип INTEGER или OBJECT IDENTIFIER . В этой форме настоящий тип задается значением этого компонента. Например, тип AlgorithmIdentifier имеет компонент типа ANY:

AlgorithmIdentifier ::= SEQUENCE {
    algorithm OBJECT IDENTIFIER,
    parameter ANY DEFINED BY
        algorithm OPTIONAL
}

Здесь настоящий тип компонента parameter зависит от значения компонента algorithm. Настоящий тип будет определен при регистрации идентификатора объекта для компонента algorithm.

Тип UTCTime

Тип UTCTime служит для обозначения универсального местного времени с привязкой по Гринвичу (GMT). Значение UTCTime определяет местное время с точностью минут или секунд и временной сдвиг по отношению к GMT. Оно может иметь следующие формы:

YYMMDDhhmmZ
YYMMDDhhmm+hh`mm`
YYMMDDhhmm-hh`mm`
YYMMDDhhmmssZ
YYMMDDhhmmss+ hh`mm`
YYMMDDhhmmss- hh`mm`

где

YY – младшие две цифры года

ММ – код месяца (01 – 12)

DD – код дня (01 – 31)

hh – код часа (00 – 23)

mm – код минут (00 – 59)

ss – код секунд (00 – 59)

Z – означает местное время по Гринвичу, + указывает на то, что местное время отстает от GMT, а указывает на то, что местное время опережает GMT.

hh` – абсолютное значение смещения по отношению к GMT в часах

mm` – абсолютное смещение по отношению к GMT в минутах.

Введение в PKI

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

Сначала определим ключевые термины, используемые в Инфраструктуре Открытого Ключа (Public Key Infrastructure – PKI) и основные исторические моменты разработки PKI. Затем рассмотрим архитектуру PKI, определим основные форматы данных и протоколы взаимодействия участников PKI.

Одним из требований к алгоритмам цифровой подписи является требование, чтобы было вычислительно невозможно, зная открытый ключ KU, определить закрытый ключ KR. Казалось бы, открытый ключ KU можно распространять по небезопасным сетям и хранить в небезопасных репозиториях. Но при этом следует помнить, что при использовании цифровой подписи необходимо быть уверенным, что субъект, с которым осуществляется взаимодействие с использованием алгоритма открытого ключа, является собственником соответствующего закрытого ключа. В противном случае возможна атака, когда оппонент заменяет открытый ключ законного участника своим открытым ключом, оставив при этом идентификатор законного участника без изменения. Это позволит ему создавать подписи от имени законного участника и читать зашифрованные сообщения, посланные законному участнику, используя для этого свой закрытый ключ, соответствующий подмененному открытому ключу. Для предотвращения такой ситуации следует использовать сертификаты, которые являются структурами данных, связывающими значения открытого ключа с субъектом. Для связывания необходимо наличие доверенного удостоверяющего (или сертификационного) центра (Certification Authority – СА), который проверяет идентификацию субъекта и подписывает его открытый ключ и некоторую дополнительную информацию своим закрытым ключом.

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

Основным понятием Инфраструктуры Открытого Ключа является понятие сертификата.

Сертификат участника, созданный СА, имеет следующие характеристики:

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

Мы будем рассматривать сертификаты Х.509, хотя существует достаточно много сертификатов других форматов.

CCITT (Consultative Committee for International Telegraphy and Telephony) разработал серию рекомендаций для создания так называемого сервиса Директории. Директория является сервером или распределенным набором серверов, которые поддерживают распределенную базу данных, содержащую информацию о пользователях и других объектах, которая называется Информационной Базой Директории (Directory Information Base – DIB). Данная информация может включать имя пользователя или объекта, а также другие атрибуты. Эти рекомендации носят название стандарта Х.500.

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

Стандарты ITU-T X.509 и ISO/IEC 9594-8, которые впервые были опубликованы в 1988 году как часть рекомендаций Х.500 Директории, определили формат сертификата Х.509. Формат сертификата в стандарте 1988 года называется форматом версии 1 (v1). Стандарт Х.500 был пересмотрен в 1993 году, в результате чего было добавлено несколько новых полей в формат сертификата Х.509, который был назван форматом версии 2 (v2).

Опыт реализации первой и второй версий говорит о том, что форматы сертификата v1 и v2 имеют ряд недостатков. Самое важное, что для хранения различной информации требуется больше полей. В результате ISO/IEC, ITU-T и ANSI X9 разработали формат сертификата Х.509 версии 3 (v3). Формат v3 расширяет формат v2 путем добавления заготовок для дополнительных полей расширения. Конкретные типы полей расширения могут быть определены в стандартах или определены и зарегистрированы любой организацией или сообществом. В июне 1996 года стандартизация базового формата v3 была завершена.

Однако расширения стандарта ISO/IEC, ITU-T и ANSI X9 являются очень общими, чтобы применять их на практике. Для того чтобы разрабатывать интероперабельные реализации систем, взаимно использующие сертификаты Х.509 v3, необходимо четко специфицировать формат сертификата Х.509 v3. Специалисты IETF разработали профиль сертификата X.509 v3 и опубликовали его в RFC 3280.

В табл. 13.2 рассмотрены основные элементы сертификата.

Таблица 13.2. Основные элементы сертификата
ПояснениеПараметры сертификатаВерсия
Целое число, идентифицирующее данный сертификат, которое должно быть уникальным среди всех сертификатов, выпущенных данным САСерийный номерv1v2v3
СА, который создал и подписал сертификатИмя СА, выпустившего сертификат
Период действительности состоит из двух временных значений, в промежутке между которыми сертификат считается действительнымНе раньше
Не позже
Конечный участник, для которого создан данный сертификатИмя субъекта (конечного участника)
Открытый ключ субъекта и алгоритм, для которого этот ключ был созданАлгоритм
Параметры
Открытый ключ субъекта
Уникальный идентификатор СА
Уникальный идентификатор субъекта
Расширения
Подпись охватывает все остальные поля сертификата и состоит из хэш-кода других полей, зашифрованного закрытым ключом САПодпись, созданная закрытым ключом СА для всех полей сертификатаВсе версии

Часто используется следующая нотация для обозначения сертификата:

СА << A >>

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

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

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

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

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

Теперь предположим, что А получил сертификат от уполномоченного органа Х1, и В получил сертификат от уполномоченного органа Х2. Если А не знает безопасным способом открытый ключ Х2, то сертификат В, полученный от Х2, для него бесполезен. А может прочитать сертификат В, но не в состоянии проверить подпись. Тем не менее, если два САs могут безопасно обмениваться своими открытыми ключами, возможна следующая процедура для получения А открытого ключа В.

  1. А получает из директории сертификат Х2, подписанный Х1. Так как А знает открытый ключ Х1 надежным способом, А может получить открытый ключ Х2 из данного сертификата и проверить его с помощью подписи Х1 в сертификате.
  2. Затем А возвращается обратно в директорию и получает сертификат В, подписанный Х2. Так как А теперь имеет открытый ключ Х2 надежным способом, А может проверить подпись и безопасно получить открытый ключ В.

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

Х1 << Х2 >> Х2 << B >>

Аналогично В может получить открытый ключ А с помощью такой же цепочки:

Х2 << Х1 >> Х1 << А >>

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

Х1 << Х2 >> Х2 << Х3 >> . . . ХN << B >>

В этом случае каждая пара САs в цепочке i , Хi+1) должна создать сертификаты друг для друга.

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

Терминология PKI

Мы будем использовать следующие термины и понятия.

  1. Public Key Infrastructure (PKI)инфраструктура открытого ключа – это множество аппаратуры, ПО, людей, политик и процедур, необходимых для создания, управления, хранения, распределения и отмены сертификатов, основанных на криптографии с открытым ключом.
  2. End-entity (ЕЕ) – конечный участник, для которого выпущен данный сертификат. Важно заметить, что здесь под конечными участниками подразумеваются не только люди и используемые ими приложения, но также и исключительно сами приложения (например, для безопасности уровня IP). Этот фактор влияет на протоколы, которые используют операции управления PKI ; например, ПО приложения следует более точно знать требуемые расширения сертификата, чем человеку.
  3. Certificate Authority (CA) – удостоверяющий (сертификационный) центр – это уполномоченный орган, который создает и подписывает сертификаты открытого ключа. Дополнительно СА может создавать пары закрытый/открытый ключ конечного участника. Важно заметить, что СА отвечает за сертификаты открытого ключа в течение всего времени их жизни, а не только в момент выпуска.
  4. Public Key Certificate (PKC) – сертификат открытого ключа или просто сертификат – это структура данных, содержащая открытый ключ конечного участника и другую информацию, которая подписана закрытым ключом СА, выпустившим данный сертификат.
  5. Registration Authority (RA)регистрационный центр – необязательный участник, ответственный за выполнение некоторых административных задач, необходимых для регистрации конечных участников. Такими задачами могут быть: подтверждение идентификации конечного участника; проверка значений, которые будут указаны в создаваемом сертификате ; проверка, знает ли конечный участник закрытый ключ, соответствующий открытому ключу, указанному в сертификате. Заметим, что RA сам также является конечным участником.

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

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

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

    • Может оказаться более эффективным сконцентрировать некоторую функциональность в оборудовании RA, чем иметь данную функциональность для всех конечных участников (особенно если используется специальное оборудование для инициализации токена).
    • Установление RАs в организации может уменьшить число необходимых СAs.
    • RAs могут быть лучше размещены для идентификации людей с их "электронными" именами, особенно если СА физически удален от конечного участника.
    • Для многих приложений уже существуют определенные административные структуры, которые могут играть роль RA.
  6. Выпускающий CRL - необязательный компонент, которому СА делегирует функции опубликования списков отмененных сертификатов.
  7. Certificate Policy (CP) – политика сертификата – поименованное множество правил, которое определяет применимость сертификата открытого ключа для конкретного сообщества или класса приложений с общими требованиями безопасности. Например, конкретная политика сертификата может указывать применимость типа сертификата открытого ключа для аутентификации транзакций данных при торговле товарами в данном ценовом диапазоне.
  8. Certificate Practice Statement (CPS) – регламент сертификационной практики, в соответствии с которой сотрудники удостоверяющего центра выпускают сертификаты открытого ключа.
  9. Relying party (RP) – проверяющая сторона – пользователь или агент (например, клиент или сервер), который использует сертификат для надежного получения открытого ключа субъекта и, быть может, некоторой дополнительной информации.
  10. Root CAСА, которому непосредственно доверяет ЕЕ ; это означает безопасное приобретение значения открытого ключа корневого СА, требующее некоторых внешних шагов. Этот термин не означает, что корневой СА обязательно должен быть вершиной иерархии, просто показывает, что СА является непосредственно доверенным. Заметим, что термин "доверенный якорь" имеет то же значение, что и корневой СА в данном документе.
  11. Subordinate CA – "подчиненный СА " представляет собой СА, который не является корневым СА для ЕЕ. Часто подчиненный СА не является корневым СА для любого участника, но это не обязательно.
  12. Top CA – вершина иерархии PKI. Замечание: часто он также называется корневым СА, так как в терминах структур данных и в теории графов узел на вершине дерева называется корнем. Однако во избежание путаницы в данном документе будем называть данный узел "вершиной СА ", а "корневой СА " зарезервируем за СА, непосредственно тем, кому доверяет ЕЕ. Данный термин не является общепринятым во всех документах PKIX и профилях PKI.
  13. Репозиторий - система или набор распределенных систем, которые хранят сертификаты и CRLs и предназначены для распределения этих сертификатов и CRLs между конечными участниками.

Архитектура PKI

Основой для достижения безопасности в Internet являлось создание протоколов безопасности, таких как TLS, SSH и IPSec. Все эти протоколы используют криптографию с открытым ключом для предоставления таких сервисов как конфиденциальность, целостность данных, аутентификация исходных данных и невозможность отказа. Целью PKI является предоставление доверенного и действительного ключа и управление сертификатом открытого ключа, который необходим для аутентификации, невозможности отказа и конфиденциальности.

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

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

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

Замечание: конечно, возможно, что данные были подписаны кем-то еще, если, например, закрытый ключ подписывающей стороны скомпрометирован. Безопасность зависит от всех частей системы, использующей сертификаты ; она включает: физическую безопасность размещения компьютеров; безопасность персонала (например, возможность доверять людям, которые реально разрабатывают, инсталлируют, выполняют и сопровождают систему); безопасность, обеспечиваемую СА. Нарушение в любой из этих областей может послужить причиной нарушения безопасности всей системы. PKIX ограничена в предметной области и адресована только результатам, относящимся к функционированию подсистемы PKI.

PKI определяется как:

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

PKI состоит из следующих типов компонентов:

На рис.13.1 показан упрощенный взгляд на архитектурную модель PKI.

Участники PKI


Рис. 13.1.  Участники PKI

Лекция 2. Инфраструктура Открытого Ключа (часть 2)

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

LDAP – Lightweight Directory Access Protocol

Введение в LDAP

История LDAP

CCITT (Consultative Committee for International Telegraphy and Telephony) разработал серию рекомендаций для создания так называемого сервиса Директории или Каталога. Каталог является сервером или распределенным набором серверов, которые поддерживают распределенную базу данных, содержащую информацию о различных субъектах, таких как пользователи, устройства и т.п. Эта распределенная база данных называется Информационной Базой Каталога (Directory Information Base – DIB). Информация включает имя субъекта, а также различные атрибуты, характеризующие этот субъект. Данные рекомендации носят название стандарта Х.500. Первоначально LDAP начал развиваться как программный продукт переднего плана (front end) для Каталога Х.500.

LDAP предоставляет большинство возможностей Х.500 при существенно меньшей стоимости реализации. Например, удалены избыточные и редко используемые операции. LDAP, в отличие от Х.500, использует стек ТСР, а не OSI.

Следует заметить, что базовые операции протокола могут быть отображены на подмножество сервисов Каталога Х.500. Однако не существует отображения один-к-одному между операциями протокола LDAP и операциями протокола DAP (Directory Access Protocol) стандарта Х.500.

Первая реализация LDAP написана в Мичиганском университете. Большинство ранних реализаций LDAP основано на ней.

Что такое LDAP

LDAP (Lightweight Directory Access Protocol) – это протокол, который используется для доступа к информации, хранящейся на распределенных в сети серверах.

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

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

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

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

Запись идентифицируется глобально уникальным именем ( Distinguished Name – DN ) – подобно имени домена в структуре DNS.

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

Преимущества LDAP

Основные причины роста популярности LDAP связаны с тем, что:

LDAP vs базы данных

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

Принципы развертывания серверов LDAP

При развертывании серверов LDAP необходимо выполнить следующие задачи:

Модели LDAP

Основными моделями LDAP, которые определяют характеристики сервиса, являются:

Информационная модель

Рассмотрим информационную модель Каталога LDAP.

Каталог, как определено в стандарте Х.500, есть набор открытых систем, взаимодействующих для предоставления сервисов Каталога. Информация, хранящаяся в Каталоге, называется Информационной Базой Каталога (Directory Information Base – DIB). Пользователь Каталога, который может быть как человеком, так и машиной, получает доступ к Каталогу посредством клиента. Клиент от имени пользователя Каталога взаимодействует с одним или более серверами. Сервер хранит фрагмент DIB.

DIB содержит два типа информации:

  1. Пользовательская информация – информация, предоставляемая пользователям и, быть может, изменяемая ими.
  2. Административная и функциональная информация – информация, используемая для администрирования и/или функционирования Каталога.

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

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

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

Запись объекта представляет конкретный объект. Запись alias обеспечивает альтернативное именование того же самого объекта.

Множество записей, представленных в DIB, организовано иерархически в структуру дерева, известную как Информационное Дерево Каталога – Directory Information Tree (DIT) .

Сначала мы рассмотрим DIT, затем обсудим именование записей, структуру записей, классы объектов, описания атрибутов и записи alias’ов.

Информационное дерево Каталога

DIB является композицией множества записей, организованных иерархически в структуру дерева, известную как информационное дерево Каталога (Directory Information Tree – DIT). Вершинами дерева являются записи.

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

В данном случае dc=msu и cn=oit – примеры записей. Запись dc=msu является родителем для записи dc=cmc, запись dc=cmc является подчиненной для записи dc=msu.

Пример дерева Каталога


Рис. 14.1.  Пример дерева Каталога

Модель именования

LDAP определяет иерархическую структуру данных, называемую DIT. Дерево Каталога в чем-то подобно файловой системе. Отличие от файловой системы состоит в следующем:

  1. Каждая запись в LDAP может как содержать данные, так и служить контейнером, т.е. содержать поддерево. В файловой системе каждая запись является либо файлом, либо Каталогом, но не тем и другим одновременно.
  2. Уникальные имена LDAP читаются от данной точки к корневой точке, в файловой системе наоборот, от корневой точки к данной.
Относительные уникальные имена

Каждая запись поименована относительно своей непосредственной вышестоящей записи. Данное относительное имя, известное как ее Relative Distinguished Name (RDN) является композицией неупорядоченного множества одного или более выражений значений атрибутов – attribute value assertions (AVA) – состоящих из описания атрибута и его значения. Эти AVAs выбраны из атрибутов записи.

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

Приведем примеры RDNs:

UID=12345
OU=Engineering
CN=Kurt Zeilenga+L=Redwood Shores

Последний вариант является примером RDN с несколькими значениями. Это означает, что RDN составлено из нескольких AVAs.

Принципы именования следующие:

Полные уникальные имена

Полное имя записи, известное как Distinguished Name (DN), является конкатенацией ее RDN и DN ее родителя. DN уникально определяет запись в дереве.

Приведем примеры DNs:

UID=nobody@example.com,
    DC=example,DC=com
cn=oit,ou=laboratories,
    dc=cmc,dc=msu,c=ru

В LDAPv3 для представления уникального имени ( DN ) используется строка UTF-8.

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

Уникальные имена имеют две части.

В приведенном выше примере RDN есть cn=oit.

Базовое уникальное имя есть ou=laboratories,dc=cmc,c=msu.

Для каждого базового DN каждый RDN является уникальным. Это гарантирует, что никакие две записи не имеют один и тот же DN.

Запись LDAP

Основные свойства записи:

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

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

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

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

Например, атрибут givenName может иметь более одного значения, эти значения должны быть Directory Strings и они нечувствительны к регистру. Поэтому атрибут givenName не может иметь одновременно значения John и JOHN, так как согласно правилу эквивалентности данного типа атрибута это эквивалентные значения.

Атрибуты

Атрибут состоит из описания атрибута и одного или более значений данного атрибута.

Attribute ::= 	SEQUENCE { 
  type AttributeDescription, 
  vals SET OF AttributeValue 
}

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

Описания атрибута

Описание атрибута состоит из типа атрибута и множества из нуля или более опций атрибута.

attributedescription =
    attributetype options
attributetype = oid
options = *( SEMI option )
option = 1*keychar

где <attributetype> определяет тип атрибута, и каждая <option> определяет опцию атрибута. И <attributetype>, и <option> нечувствительны к регистру. Порядок, в котором появляются <option>s, несущественен. Это означает, что любые два <attributedescription>s, которые состоят из одного и того же <attributetype> и одного и того же множества <option>s, являются эквивалентными.

Примеры допустимых описаний атрибутов:

2.5.4.0
cn;lang-de;lang-en
owner

Все атрибуты записи должны иметь различные описания атрибутов.

Типы атрибутов

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

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

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

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

Опции атрибутов

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

Описание атрибут а с N тегированными опциями считается непосредственным подтипом всех описаний атрибута того же самого типа атрибута. Если тип атрибута имеет супертип, то описание атрибута также считается непосредственным подтипом (описания) атрибута супертипа и N тегированных опций. Это означает, что cn; lang-de; lang-en считается непосредственным подтипом cn; lang-de и cn; lang-en и name; lang-de; lang-en ( cn является подтипом name ).

Значение атрибута

Значения атрибута соответствуют синтаксису, определенному для атрибута.

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

Поле типа AttributeValue является OCTET STRING, содержащей тип данных значения атрибута. Значение представлено в соответствии с определением представления для LDAP. Определение представления для LDAP для различных синтаксисов и атрибутов определяется при определении Синтаксиса.

AttributeValue ::= OCTET STRING

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

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

Таким образом, атрибуты имеют:

  1. Имя – уникальный идентификатор, нечувcтвительный к регистру.
  2. Идентификатор объекта (OID) – последовательность целых, разделенных точками.
  3. Синтаксис атрибута, который определяет:

    • тип данных, хранящихся в атрибуте: целые, строки и т.п;
    • как выполняется сравнение.
    • Может ли атрибут иметь несколько значений или только единственное значение.

Примеры имен атрибутов:

uid – User id

cn – Common Name

sn – Surname

l – Location

ou – Организационная единица

o – Организация

dc – Domain Component

st – Штат

c – Страна

Атрибуты функционирования

Атрибуты функционирования имеют следующие характеристики:

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

Записи аliases имеют следующие свойства:

  1. Используются для ссылки одной записи на другую.
  2. Позволяют иметь структуру, которая не является иерархической.
  3. Аналогичны использованию символьных ссылок в файловой системе UNIX.
  4. Не все серверы LDAP поддерживают aliases.
  5. Создаются с помощью:
    • записи с классом объекта alias'а;
    • атрибут, называемый aliasedObjectName, который указывает на DN alias'а.
Схема

Схема Каталога обладает следующими свойствами:

  1. Представляет собой множество правил, которые описывают хранимые данные.
  2. Предназначена для поддержки согласованности и качества данных.
  3. Снижает дублирование данных.
  4. Гарантирует, что приложения имеют согласованный интерфейс к данным.
  5. Атрибут класса объекта определяет правила схемы, которым должна удовлетворять запись.
  6. Схема содержит следующую информацию:
    • необходимые атрибуты ;
    • допустимые атрибуты ;
    • как сравнивать атрибуты ;
    • предел хранимых атрибутов, например ограничение на целые и т.п;
    • ограничение на хранение информации, например запрет дубликатов и т.п.

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

Таким образом, Схема обеспечивает следующие возможности Каталога:

  1. Предотвращение создания подчиненных записей от неправильного класса объекта (например, country как подчиненная person ).
  2. Предотвращение добавления типов атрибута к записи, не соответствующей классу объекта (например, serial number к записи person ).
  3. Предотвращение добавления значения атрибута, синтаксис которого не соответствует тому, который определен для типа атрибута (например, printable string к bit string ).

Формально Схема Каталога состоит из множества:

  1. Определений форм имени, которые характеризуют взаимоотношения именования для структурных классов объектов.
  2. Определений Правил Структуры DIT, описывающих имена, которые могут иметь записи, и способы взаимоотношений записей в DIT.
  3. Определений Правил Содержания DIT, которые расширяют спецификацию возможных принадлежащих записям атрибутов указанием структурных классов объектов для записей.
  4. Определений Классов Объектов, описывающих базовое множество обязательных и необязательных атрибутов, которые должны и могут присутствовать в записи данного класса, и которые указывают род определяемого класса объекта.
  5. Определений Типов Атрибутов, указывающих идентификатор объекта для атрибута, его синтаксис, связанные с ним правила соответствия, является он функциональным или пользовательским атрибутом, может ли он иметь несколько значений и происходит ли от другого атрибута.
  6. Определений Правил Соответствия.
  7. Определений синтаксиса LDAP, которые определяют правила представления, используемые в LDAP.
Расширение схемы

Расширение схем выполняется в определенной последовательности:

  1. Получить идентификатор объекта (OID).
  2. Выбрать префикс имени.
  3. Создать файл локальной схемы.
  4. Определить типы атрибутов пользователя (если необходимо).
  5. Определить классы объектов пользователя.
Класс объекта

Класс объекта есть идентифицированное семейство объектов, которые имеют общие характеристики.

Основные свойства классов объектов:

  1. Классы используются для группирования информации.
  2. Классы обеспечивают следующие возможности:
    • определяют необходимые атрибуты ;
    • определяют допустимые атрибуты ;
    • обеспечивают легкий способ группирования информации.
  3. Записи могут иметь несколько классов объектов. Необходимые и допустимые атрибуты при этом являются объединением атрибутов каждого класса.
  4. Классы также предназначены для управления функционированием Каталога.

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

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

Каждый класс объекта определяется как один из трех видов классов объектов: Abstract, Structural или Auxiliary.

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

Абстрактные классы объектов

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

Абстрактные классы объектов не могут происходить от структурных или вспомогательных классов объектов.

Все структурные классы объектов получены (прямо или косвенно) от top абстрактного класса объекта. Вспомогательные классы объектов необязательно получены от top.

Структурные классы объектов

Каждый структурный класс ( Structural ) объекта является (прямым или косвенным) подклассом top абстрактного класса объекта.

Структурные классы объектов не могут быть подклассом вспомогательных классов объектов.

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

Вспомогательные классы объектов

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

Вспомогательные классы объектов не могут быть подклассом структурных классов объектов.

Запись может принадлежать любому подмножеству множества вспомогательных классов объектов.

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

Наследование классов объектов

Наследование классов объектов обладает следующими свойствами:

Административная и функциональная информация Каталога

Рассмотрим некоторые аспекты Административной и Функциональной Информационной модели LDAP. Некоторые реализации LDAP могут поддерживать и другие аспекты данной модели.

Атрибут objectClass

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

Функциональные атрибуты

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

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

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

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

Серверы должны поддерживать creatorsName, createTimestamp, modifiersName и modifiersTimestamp для всех записей в DIT.

Синтаксисы

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

Сначала определим базовое множество синтаксисов LDAP, затем базовое множество правил соответствия для LDAP.

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

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

Правило присваивания значения атрибута

Определение типа AttrubuteValueAssertion содержит описание атрибута и соответствующее правило присваивания значения для данного типа.

AttributeValueAssertion ::= SEQUENCE { 
		attributeDesc
		  AttributeDescription, 
		assertionValue
		  AssertionValue 
} 
AssertionValue ::= OCTET STRING

Синтаксис AssertionValue зависит от контекста выполняемой операции LDAP. Например, синтаксис EQUALITY, соответствующий правилу для атрибута, используемого при выполнении операции Compare. Часто тот же самый синтаксис используется для значений типов атрибутов, но в некоторых случаях синтаксис присваивания отличается от синтаксиса значения.

Правила соответствия

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

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

Правило соответствия применяется к значениям атрибута посредством AttributeValueAssertion или MatchingRuleAssertion. Могут существовать определенные условия, при которых AttributeValueAssertion или MatchingRuleAssertion вычисляются как Undefined. Если утверждение не является Undefined, то результат утверждения есть результат применения выбранного правила соответствия. Правило соответствия вычисляется в TRUE и в некоторых случаях Undefined, как определено в описании правила соответствия, в противном случае оно вычисляется в FALSE.

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

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

Описание каждого правила соответствия указывает, применимо ли правило в качестве правила эквивалентности ( EQUALITY ), правила упорядоченности ( ORDERING ) или правила подстрок ( SUBSTR ) в определении типа атрибута.

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

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

Серверы должны публиковать в атрибуте matchingRules определения правил соответствия, ссылаясь на значения атрибутов attributeTypes и matchingRuleUse в той же записи подсхемы. Могут быть опубликованы и другие правила соответствия в атрибуте matchingRules.

Если сервер поддерживает extensibleMatch -фильтр, сервер может использовать атрибут matchingRuleUse для указания применимости (в extensibleMatch фильтре) выбранных правил соответствия к упомянутым типам атрибутов.

Правила содержимого DIT

Правило содержимого DIT есть правило управления содержимым записей конкретного структурного класса объекта.

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

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

Каждое правило содержимого идентифицируется OID, а также любыми короткими именами (дескрипторами) структурного класса объекта, к которому оно применено.

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

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

Запись может содержать любые незапрещенные атрибуты, допустимые классами объектов, которым принадлежит запись, а также все атрибуты, допустимые правилом управления содержимым.

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

Запись управляется (если присутствует и активна в подсхеме) правилом содержимого DIT, которое применяется к структурному классу объекта записи. Если неактивное правило присутствует для структурного класса объекта записи, содержимое записи управляется структурным классом объекта (и, возможно, другими аспектами схемы пользователя и системы).

Правила структуры DIT и формы имени

Следует определить, где записи объекта могут размещаться в DIT и как они могут именоваться, основываясь на структурном классе объекта.

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

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

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

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

Каждая форма имени идентифицируется OID и (необязательно) одним или более короткими именами (дескрипторами).

Записи подсхемы

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

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

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

Класс объекта "extensibleObject"

Вспомогательный класс объекта extensibleObject позволяет записям иметь любой тип атрибута. Множество допустимых атрибутов данного класса неявно является множеством всех пользовательских атрибутов.

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

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

LDIF

LDIF является форматом обмена данными и обладает следующими свойствами:

Пример LDIF:

dn: uid=olga, ou=people,
dc=cmc, dc=msu
uid: olga
Распределенное множество серверов LDAP

Протокол LDAP предполагает, что существует один или несколько серверов, которые сообща предоставляют доступ к Информационному Дереву Каталога (DIT).

Разработка топологии

Дерево Каталога может быть распределено по нескольким физическим серверам.

При определении топологии важно учитывать:

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

Данная структура во многом аналогична DNS.

Referrals

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

Код результата поиска referral указывает, что сервер, с которым осуществляется соединение, не содержит целевой записи для запроса. Поле referral представлено в LDAPResult, если значение поля LDAPResult.resultCode есть referral, и отсутствует с остальными кодами результата. Оно содержит одну или более ссылок на один или более серверов или сервисов, которые могут быть доступны посредством LDAP или других протоколов. Referrals могут быть возвращены в ответе для любого запроса операции (исключая unbind и abandon, которые не имеют ответа). По крайней мере, один URL должен быть представлен в Referral.

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

Referral ::= SEQUENCE OF LDAPURL
    -- один или более
LDAPURL ::= LDAPString
/* ограничено символами, 
   которые допустимы в URLs */

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

URLs для серверов, реализующих протокол LDAP, написаны в соответствии с определением DN. Если на alias ссылок нет, то часть <dn> URL должна присутствовать с новым именем целевого объекта. Если часть <dn> присутствует, клиент должен использовать данное имя в своих следующих запросах для продолжения операции, и если оно не представлено, клиент будет задействовать то же самое имя, что и в начальном запросе. Некоторые серверы (например, участвующие в распределенном индексировании) могут предоставить различные фильтры в referral для операции поиска. Если часть фильтра в URL присутствует в LDAPURL, клиент должен использовать этот фильтр в своем следующем запросе при продолжении поиска, и если он не присутствует, клиент должен применять тот же фильтр, что использовал для данного запроса. Другие аспекты нового запроса могут быть теми же самыми или отличаться от запроса, в котором был создан referral.

Каждый сервер должен содержать определенное поддерево


Рис. 14.2.  Каждый сервер должен содержать определенное поддерево

Поиск с использованием Referrals


Рис. 14.3.  Поиск с использованием Referrals

Заметим, что символы UTF-8, появляющиеся в DN или фильтре поиска, могут быть не разрешены для URLs (например, пробелы) и должны быть вырезаны с использованием метода, определенного для преобразования URLs.

Контекст корневого именования и данные сервера

Контекст корневого именования является записью верхнего уровня для серверов. Некоторые серверы могут иметь несколько контекстов корневого именования.

Сервер LDAP должен предоставлять информацию о самом себе, а также информацию, специфичную для каждого сервера. Это представлено как группа атрибутов, размещенная в корневом DSE (DSA-специфичная запись ), которая поименована LDAPDN нулевой длины. Эти атрибуты восстанавливаемы, являются предметом управления доступа и различных ограничений, если клиент выполнил поиск базового объекта для корня с фильтром ( objectClass=* ), запрашивая возвращаемые атрибуты. Следует заметить, что корневые атрибуты DSE являются функциональными, и, подобно другим функциональным атрибутам, не возвращаются для запросов поиска, пока не будут запрошены по имени.

Корневой DSE не должен включаться, если клиент выполнил поиск по поддереву, начиная с корня.

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

Определены следующие атрибуты корневого DSE.

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

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

Репликация

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

При использовании репликации происходит увеличение:

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

Лекция 3. Инфраструктура Открытого Ключа (часть 3)

Описаны основные свойства протокола LDAP, приведены типичные переговоры LDAP. Рассматриваются операции протокола LDAP: Bind, Unbind, Search, Modify, Add, Delete, Modify DN, Compare, Abandon.

Протокол LDAP

Основные свойства протокола LDAP:

Протокол LDAP описывается с использованием ASN.1, используя подмножество BER.

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

Клиент указывает версию, которую он использует, как часть запроса Bind . Клиенты могут определить версии протокола, которые поддерживает сервер, по атрибуту supportedLDAPVersion из корневой записи сервера. Серверы, которые реализуют версию 3, должны предоставлять данный атрибут.

Все операции протокола инкапсулированы в общий конверт LDAPMessage, который определяется следующим образом:

LDAPMessage ::= SEQUENCE { 
  messageID  MessageID, 
  protocolOp  CHOICE { 
    bindRequest     BindRequest, 
    bindResponse    BindResponse, 
    unbindRequest   UnbindRequest, 
    searchRequest   SearchRequest, 
    searchResEntry  SearchResultEntry, 
    searchResDone   SearchResultDone, 
    searchResRef    SearchResultReference,
    modifyRequest   ModifyRequest, 
    modifyResponse  ModifyResponse, 
    addRequest      AddRequest, 
    addResponse     AddResponse, 
    delRequest      DelRequest, 
    delResponse     DelResponse, 
    modDNRequest    ModifyDNRequest, 
    modDNResponse   ModifyDNResponse, 
    compareRequest  CompareRequest, 
    compareResponse CompareResponse, 
    abandonRequest  AbandonRequest, 
    extendedReq     ExtendedRequest, 
    extendedResp    ExtendedResponse, 
    ... }, 
  controls [0] Controls OPTIONAL 
} 
MessageID ::= INTEGER (0 .. maxInt) 
maxInt INTEGER ::= 2147483647 -- (231 – 1) --

LDAPMessage обеспечивает конверт, содержащий общие поля, необходимые всем обменам протокола. В настоящий момент общими полями являются только messageID и controls.

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

Ответы сервера содержат значение messageID из соответствующего запроса.

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

Controls ::= SEQUENCE OF Control 
Control ::= SEQUENCE { 
    controlType  LDAPOID, 
    criticality  BOOLEAN DEFAULT FALSE,
    controlValue OCTET STRING OPTIONAL 
}

Поле controlType должно быть представлено в UTF-8 в виде OBJECT IDENTIFIER, который однозначно идентифицирует control. Это предотвращает конфликты между именами control.

Поле criticality является либо TRUE, либо FALSE, и встречается в сообщениях запроса, которые имеют соответствующее сообщение ответа. Для всех других сообщений (например, abandonRequest, unbindRequest и всех сообщений ответа) поле criticality устанавливается в FALSE.

Если сервер распознает тип control, и он соответствует операции, сервер при выполнении операции будет использовать control.

Если сервер не распознает тип control, или он не соответствует операции, и поле criticality есть TRUE, сервер не должен выполнять операцию и вместо этого возвращает resultCode unavailableCriticalExtension.

Если control не распознан или соответствующий бит в поле criticality есть FALSE, сервер должен игнорировать control.

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

LDAPResult ::= SEQUENCE { 
  resultCode ENUMERATED { 
    success                      (0), 
    operationsError              (1), 
    protocolError                (2), 
    timeLimitExceeded            (3), 
    sizeLimitExceeded            (4), 
    compareFalse                 (5), 
    compareTrue                  (6), 
    authMethodNotSupported       (7), 
    strongAuthRequired           (8), 
-- 9 зарезервировано -- 
    referral                     (10), 
    adminLimitExceeded           (11), 
    unavailableCriticalExtension (12), 
    confidentialityRequired      (13), 
    saslBindInProgress           (14), 
    noSuchAttribute              (16), 
    undefinedAttributeType       (17), 
    inappropriateMatching        (18), 
    constraintViolation          (19), 
    attributeOrValueExists       (20), 
    invalidAttributeSyntax       (21), 
-- 22-31 не используются -- 
    noSuchObject                 (32), 
    aliasProblem                 (33), 
    invalidDNSyntax              (34), 
-- 35 зарезервировано для неопределенного --
-- isLeaf --
    aliasDereferencingProblem    (36), 
-- 37-47 не используются -- 
    inappropriateAuthentication  (48), 
    invalidCredentials           (49), 
    insufficientAccessRights     (50), 
    busy                         (51), 
    unavailable                  (52), 
    unwillingToPerform           (53), 
    loopDetect                   (54), 
-- 55-63 не используются -- 
    namingViolation              (64), 
    objectClassViolation         (65), 
    notAllowedOnNonLeaf          (66), 
    notAllowedOnRDN              (67), 
    entryAlreadyExists           (68), 
    objectClassModsProhibited    (69), 
-- 70 reserved for CLDAP -- 
    affectsMultipleDSAs          (71), 
-- 72-79 не используются -- 
    other                        (80), 
    ... }, 
-- 81-90 зарезервировано для APIs -- 
  matchedDN LDAPDN, 
  diagnosticMessage LDAPString, 
  referral [3] Referral OPTIONAL 
}

Коды результата являются расширяемыми.

Операции протокола LDAP

В протоколе определено 9 операций:

  1. Операции запроса информации.
    • Search
    • Compare
  2. Операции изменения информации.
    • Add
    • Delete
    • Modify
    • Rename
  3. Операции аутентификации и управления.
    • Bind
    • Unbind
    • Abandon
Типичные переговоры LDAP операции Bind

Типичные переговоры LDAP операции Bind


Рис. 15.0.  Типичные переговоры LDAP операции Bind

Операция Bind передает аутентификационную информацию от клиента к серверу.

Запрос Bind определен следующим образом:

BindRequest ::= [APPLICATION 0] SEQUENCE {
    version        INTEGER (1 .. 127), 
    name           LDAPDN, 
    authentication AuthenticationChoice 
} 
AuthenticationChoice ::= CHOICE { 
    simple [0] OCTET STRING, 
-- 1 и 2 зарезервированы 
    sasl [3] SaslCredentials, 
... } 
SaslCredentials ::= SEQUENCE { 
    mechanism   LDAPString, 
    credentials OCTET STRING OPTIONAL 
}

Параметрами запроса Bind являются:

Ответ Bind определяется следующим образом.

BindResponse ::= [APPLICATION 1] SEQUENCE { 
    COMPONENTS OF LDAPResult, 
    serverSaslCreds [7] OCTET STRING OPTIONAL 
}

BindResponse состоит из индикации от сервера статуса запроса клиента на аутентификацию.

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

Операция Unbind

Функция операции Unbind состоит в завершении сессии протокола. Операция Unbind определяется следующим образом:

UnbindRequest ::= [APPLICATION 2] NULL

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

Операция Search

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

SearchRequest определяется следующим образом:

SearchRequest ::= [APPLICATION 3] SEQUENCE {
  baseObject  LDAPDN, 
  scope  ENUMERATED { 
    baseObject   (0), 
    singleLevel  (1), 
    wholeSubtree (2) }, 
  derefAliases     ENUMERATED { 
    neverDerefAliases (0), 
    derefInSearching  (1), 
    derefFindingBaseObj (2), 
    derefAlways     (3) }, 
  sizeLimit INTEGER (0 .. maxInt), 
  timeLimit INTEGER (0 .. maxInt), 
  typesOnly BOOLEAN, 
  filter    Filter, 
  attributes AttributeDescriptionList 
} 
Filter ::= CHOICE { 
  and [0] SET SIZE (1..MAX) OF Filter, 
  or  [1] SET SIZE (1..MAX) OF Filter,
  not [2] Filter, 
  equalityMatch [3] AttributeValueAssertion,
  substrings    [4] SubstringFilter, 
  greaterOrEqual [5] AttributeValueAssertion, 
  lessOrEqual   [6] AttributeValueAssertion,
  present       [7] AttributeDescription, 
  approxMatch   [8] AttributeValueAssertion, 
  extensibleMatch [9] MatchingRuleAssertion 
} 
SubstringFilter ::= SEQUENCE { 
  type AttributeDescription, 
  -- по крайней мере один должен 
  -- присутствовать, initial и final могут
  -- быть только один раз
  substrings SEQUENCE OF CHOICE { 
    initial  [0] AssertionValue, 
    any      [1] AssertionValue, 
    final    [2] AssertionValue } 
} 
MatchingRuleAssertion ::= SEQUENCE { 
  matchingRule [1] MatchingRuleId OPTIONAL, 
  type         [2] AttributeDescription OPTIONAL, 
  matchValue   [3] AssertionValue, 
  dnAttributes [4] BOOLEAN DEFAULT FALSE 
}

Перечислим параметры SearchRequest:

Сервер должен вычислить фильтры. Результатом вычисления фильтра должно быть либо TRUE, либо FALSE, либо Undefined. Если фильтр вычисляет TRUE для конкретной записи, то атрибуты данной записи возвращаются как часть результата поиска. Если фильтр вычисляет FALSE или Undefined, то данная запись при поиске игнорируется.

Правило соответствия для элемента фильтра equalityMatch определяется правилом соответствия EQUALITY для типа атрибута.

Область baseObject


Рис. 15.1.  Область baseObject

Область singleLevel


Рис. 15.2.  Область singleLevel

Область wholeSubtree


Рис. 15.3.  Область wholeSubtree

Правило соответствия для AssertionValues фильтра определяется правилом соответствия SUBSTR для типа атрибута.

Правило соответствия для элементов фильтра greaterOrEqual и lessOrEqual определяется правилом соответствия ORDERING для типа атрибута.

Семантика соответствия для элементов фильтра approxMatch определяется реализацией.

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

Если клиент не хочет, чтобы возвращались какие-либо атрибуты, он может указать список, содержащий только атрибут с OID "1.1". Этот OID был выбран произвольно и не соответствует никакому используемому атрибуту.

Следует заметить, что если запрошены все атрибуты пользователя, некоторые атрибуты записи могут не включаться в результаты поиска в соответствии с политикой управления доступом или другими ограничениями. Более того, серверы не будут возвращать атрибуты выполнения, такие как objectClasses или attributeTypes, если они явно не перечислены, т.к. эти атрибуты могут иметь большое число значений.

Результаты поиска вычисляются сервером после получения им SearchRequest и возвращаются в SearchResponses, которые являются сообщениями LDAP, содержащими типы данных SearchResultEntry, либо SearchResultReference, либо SearchResultDone.

SearchResultEntry ::= [APPLICATION 4] SEQUENCE
{ 
    objectName LDAPDN, 
    attributes PartialAttributeList 
} 
PartialAttributeList ::= SEQUENCE OF SEQUENCE
{
    type AttributeDescription, 
    vals SET OF AttributeValue 
} 
-- следует заметить, что PartialAttributeList
-- может иметь ноль элементов (если ни один
-- из атрибутов затребованной записи не может
-- быть возвращен) и что множество vals может
-- также иметь ноль элементов (если запрошены
-- только типы или все значения были 
-- исключены из результата) 
SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL 
-- по крайней мере один элемент LDAPURL
-- должен присутствовать 
SearchResultDone ::= [APPLICATION 5] LDAPResult

После получения SearchRequest сервер будет выполнять необходимый поиск в DIT.

Сервер может возвращать как найденные записи ( SearchResultEntry ), так и ссылки на другие серверы для продолжения поиска ( SearchResultReference ).

Для завершения поиска клиент может создать новую операцию поиска для каждого полученного SearchResultReference.

Например, предположим, что сервер ( hosta ), с которым соединяются, имеет запись DC=Example, DC=NET и запись CN=Manager, DC=Example, DC=NET. Он знает, что один из LDAP-серверов, hostb или hostc, имеет поддерево OU=People, DC=Example, DC=NET и что LDAP-сервер hostd имеет поддерево OU=Roles, DC=Example, DC=NET. Если сделан запрос поиска по поддереву DC=Example, DC=NET, он может возвратить следующее:

SearchResultEntry for DC=Example,DC=NET 
SearchResultEntry for CN=Manager,DC=Example,
                      DC=NET 
SearchResultReference { 
    ldap://hostb/OU=People,DC=Example,DC=NET
    ldap://hostc/OU=People,DC=Example,DC=NET
} 
SearchResultReference { 
    Lightweight Directory Access Protocol 
	    Version 3 
    ldap://hostd/OU=Roles,DC=Example,DC=NET 
} 
SearchResultDone (success)

В качестве продолжения примера, если клиент соединяется с сервером hostb и создает запрос для поддерева "OU=People, DC=Example, DC=NET", сервер может вернуть следующее:

SearchResultEntry for OU=People,DC=Example,DC=NET 
SearchResultReference { 
    ldap://hoste/OU=Managers,OU=People,
    DC=Example,DC=NET 
} 
SearchResultReference { 
    ldap://hostf/OU=Consultants,OU=People,
    DC=Example,DC=NET 
} 
SearchResultDone (success)

Если сервер, с которым установлено соединение, не имеет базового объекта для поиска, то он возвращает клиенту ссылку ( referral ). Например, если клиент запросил у hosta поиск поддерева DC=Example, DC=ORG, сервер может вернуть только SearchResultDone, содержащий referral.

SearchResultDone (referral) { 
    ldap://hostg/DC=Example,DC=ORG??sub
}
Операция Modify

Операция Modify позволяет клиенту запросить модификацию записи на сервере. Запрос Modify определяется следующим образом:

ModifyRequest ::= [APPLICATION 6] SEQUENCE {
  object       LDAPDN, 
  modification SEQUENCE OF SEQUENCE { 
    operation ENUMERATED { 
      add     (0), 
      delete  (1), 
      replace (2) }, 
    modification AttributeTypeAndValues } 
} 
AttributeTypeAndValues ::= SEQUENCE { 
  type AttributeDescription, 
  vals SET OF AttributeValue 
}

Перечислим параметры запроса Modify :

Результат модификации, которую пытался выполнить сервер при получении ModifyRequest, возвращается в ModifyResponse, который определяется следующим образом:

ModifyResponse ::= [APPLICATION 7] LDAPResult

При получении ModifyRequest сервер выполняет необходимые модификации в DIT.

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

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

Операция Add

Операция Add позволяет клиенту запросить добавление записи в Каталог. AddRequest определяется следующим образом:

AddRequest ::= [APPLICATION 8] SEQUENCE {
    entry      LDAPDN, 
    attributes AttributeList 
} 
AttributeList ::= SEQUENCE OF SEQUENCE { 
    type AttributeDescription, 
    vals SET OF AttributeValue 
}

Параметрами AddRequest являются:

Запись, указанная в поле AddRequest, существовать не должна. Непосредственный родитель добавляемых записей объекта должен существовать. Например, если клиент пытается добавить CN=JS, DC=Example, DC=NET, а запись DC=Example, DC=NET не существует и запись DC=NET существует, то сервер вернет ошибку noSuchObject с полем matchedDN, содержащим DC=NET. Если родительская запись существует, но не находится в контексте именования, поддерживаемом сервером, сервер должен возвратить ссылку на сервер, содержащий родительскую запись.

При получении AddRequest сервер пытается добавить запрошенную запись. Результат попытки добавления будет возвращен клиенту в AddResponse, определенном следующим образом:

AddResponse ::= [APPLICATION 9] LDAPResult

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

Операция Delete

Операция Delete позволяет клиенту запросить удаление записи из директории. DeleteRequest определяется следующим образом:

DelRequest ::= [APPLICATION 10] LDAPDN

DeleteRequest состоит из Distinguished Name удаляемой записи. Заметим, что сервер по aliases не переходит и что только концевые записи (которые не имеют подчиненных записей) могут быть удалены с помощью данной операции.

Результат операции удаления, выполненной сервером при получении DeleteRequest, возвращается в DeleteResponse, определяемом следующим образом:

DelResponse ::= [APPLICATION 11] LDAPResult

При получении DeleteRequest сервер пытается выполнить удаление указанной записи. Результат возвращается клиенту в DeleteResponse.

Операция ModifyDN

Операция ModifyDN позволяет клиенту изменить левый компонент имени записи в Каталоге и/или переместить поддерево записей на новое место в Каталоге. ModifyDNRequest определяется следующим образом:

ModifyDNRequest ::= [APPLICATION 12] SEQUENCE
{
    entry        LDAPDN, 
    newrdn       RelativeLDAPDN, 
    deleteoldrdn BOOLEAN, 
    newSuperior  [0] LDAPDN OPTIONAL
}

Параметрами ModifyDNRequest являются:

Результат попытки изменения имени сервером при получении ModifyDNRequest возвращается в ModifyDNResponse, определенном следующим образом:

ModifyDNResponse ::= [APPLICATION 13] 
    LDAPResult

Например, если запись, указанная в параметре entry, была cn=Olga Laponina, c=RU, newdn параметр был cn=Olga R. Laponina и newSuperior параметр отсутствовал, то эта операция пытается переименовать запись, чтобы она имела вид cn= Olga R. Laponina, c=RU. Если запись с таким именем уже существует, то операция не завершится с кодом ошибки entryAlreadyExists.

Объект, указанный в newSuperior, должен существовать. Например, если клиент пытается добавить CN=JS, DC=EXAMPLE, DC=NET, запись DC=EXAMPLE, DC=NET не существует, запись DC=NET существует, то сервер возвратит ошибку noSuchObject с полем matchedDN, содержащим DC=NET.

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

Операция Compare

Операция Compare позволяет клиенту сравнить утверждение с записью в Каталоге. CompareRequest определяется следующим образом:

CompareRequest ::= [APPLICATION 14] SEQUENCE
{ 
  entry LDAPDN, 
  ava   AttributeValueAssertion 
}

Перечислим параметры CompareRequest:

Результат сравнения, выполненного сервером при получении CompareRequest, возвращается в CompareResponse, определяемом следующим образом:

CompareResponse ::= [APPLICATION 15] LDAPResult

При получении CompareRequest сервер пытается выполнить запрошенное сравнение, используя правило соответствия EQUALITY для типа атрибута. Результат сравнения возвращается клиенту в CompareResponse. Заметим, что как ошибки, так и результат сравнения возвращаются в одной и той же конструкции.

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

Операция Abandon

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

AbandonRequest ::= [APPLICATION 16] MessageID

MessageID должен быть тот же, что был в операции, запрошенной ранее для данного LDAP-соединения. Сам запрос Abandon не имеет собственного MessageID. Он должен отличаться от id более ранней операции, для которой выполнен Abandon .

Для операции Abandon ответ не определен. При передаче операции Abandon сервер может прервать операцию, идентифицированную MessageID в AbandonRequest. Ответы операции при успешном прерывании операции не посылаются. Клиенты могут определить, что операция прервана, выполняя последующую операцию Bind .

Операции Abandon и Unbind не могут быть прерваны. Возможность прервать другие операции (в частности, update ) определяется сервером.

В том случае, если сервер получил AbandonRequest для операции Search в середине передаваемых ответов на поиск, сервер должен немедленно прекратить передачу ответов и не должен посылать SearchResponseDone. Конечно сервер должен гарантировать, что передаются только корректные блоки данных LDAPMessage.

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

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

Расширенные операции

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

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

ExtendedRequest ::= [APPLICATION 23] SEQUENCE
{ 
  requestName  [0] LDAPOID, 
  requestValue [1] OCTET STRING OPTIONAL 
}

requestName есть разделенное точками представление OBJECT IDENTIFIER, соответствующего запросу. requestValue есть информация в форме, определенной данным запросом, инкапсулированная в OCTET STRING.

Сервер отвечает LDAPMessage, содержащим ExtendedResponse.

ExtendedResponse ::= [APPLICATION 24] SEQUENCE
{ 
    COMPONENTS OF LDAPResult, 
    responseName [10] LDAPOID OPTIONAL, 
    response     [11] OCTET STRING OPTIONAL 
}

Если сервер не распознал имя запроса, он должен вернуть только поля ответа из LDAPResult, содержащие код ошибки protocolError.

Лекция 4. Инфраструктура Открытого Ключа (часть 4)

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

Профили сертификата и списка отмененных сертификатов

Введение в Х.509v3

Рассмотрим форматы сертификата Х.509 v3 и списка отмененных сертификатов (Certificate Revocation List – CRL) Х.509 v2. Рассмотрим стандартные расширения сертификата и CRL и определим расширения, специфичные для Internet. Рассмотрим алгоритм проверки действительности сертификационного пути.

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

Пользователь сертификата должен просмотреть политику сертификата, созданную СА, прежде чем использовать сертификат.

Сертификат Х.509 версии 3

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

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

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

Сертификационные пути и доверие

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

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

  1. Регистрационный уполномоченный орган политики Internet (IPRA): данный уполномоченный орган, функционирующий под руководством Internet-сообщества, действует в качестве корневого органа в сертификационной иерархии. Он выпускает сертификаты только для уполномоченных органов следующего уровня, PCAs. Все сертификационные пути начинаются с IPRA.
  2. Уполномоченные органы сертификатов политики (PCAs): PCAs являются вторым уровнем иерархии, каждый PCAs сертифицирован IPRA. РСА должны установить и опубликовать утверждение о своей политике в отношении сертифицируемых пользователей или подчиненных уполномоченных органов сертификации. Различные PCAs могут удовлетворять те или иные потребности пользователей. Например, один РСА может выпускать сертификаты для электронной почты, другой РСА может иметь политику, которая удовлетворяет более строгим законодательным требованиям в отношении цифровых подписей.
  3. Уполномоченные органы сертификации (САs): САs являются третьим уровнем иерархии, но могут иметь и более низкий уровень. Те, что находятся на третьем уровне, сертифицируются PCAs. САs представляют, например, отдельные организации, отдельные единицы организации (департаменты, отделы, лаборатории) или отдельные географические единицы.

RFC 1422 определяет правило подчинения имен, которое требует, чтобы СА мог выпускать сертификаты только тем пользователям, чьи имена являются подчиненными (в дереве именования Х.500) по отношению к имени самого СА. Доверие, связанное с сертификационным путем, определяется именем РСА. Правило подчинения имен гарантирует, что САs, подчиняющиеся конкретному РСА, ограничены множеством участников, которых они могут сертифицировать (т.е. СА организации может сертифицировать только сотрудников данной организации). Системы сертификации пользователей должны иметь возможность автоматически проверять, выполняется ли правило подчинения имен.

RFC 1422 использует форматы сертификатов Х.509 v1. Ограничения Х.509 v1 требуют нескольких структурных ограничений на четкое связывание информации о политике или ограничения на использование сертификатов. Эти ограничения включают:

В Х.509 v3 большинство ограничений, определенных в RFC 1422, может быть указано в расширениях сертификата без необходимости иметь строгую иерархическую структуру САs. В частности, расширения сертификата, касающиеся политик, устраняют необходимость применения правила подчинения имен. Как результат, третья версия может поддерживать более гибкую архитектуру:

Отмена сертификата

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

Х.509 определяет один метод отмены сертификата. Данный метод предполагает, что каждый СА периодически выпускает подписанную структуру данных, называемую списком отмененных сертификатом (CRL). CRL является помеченным временем списком, который подписан СА или специальным выпускающим CRL и в котором перечислены отмененные сертификаты. Данный список становится свободно доступен в открытом репозитории. Каждый отмененный сертификат идентифицируется в CRL своим серийным номером. Когда использующая сертификат система получает сертификат (например, для проверки цифровой подписи удаленного пользователя), эта система не только проверяет подпись сертификата и действительность, но также получает свежий CRL и проверяет, не находится ли в этом CRL серийный номер сертификата. Понятие "свежий" может зависеть от локальной политики, но обычно означает самый последний выпущенный CRL. Новый CRL выпускается регулярно (например, каждый час, день или неделю). При получении уведомления об отмене запись добавляется в CRL.

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

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

Как и формат сертификата Х.509 v3, для того, чтобы обеспечить интероперабельность реализаций различных производителей, необходимо иметь строгий формат Х.509 CRL v2. Существуют также специальные протоколы и соответствующие им форматы сообщений, поддерживающих on-line оповещения об отмене. On-line методы оповещения об отмене могут применяться в некоторых окружениях как альтернатива CRL. On-line проверка отмены может существенно уменьшить промежуток между отправкой сообщения об отмене и получением этой информации проверяющей стороной. После того как СА принимает и аутентифицирует сообщение от субъекта сертификата или от RA о необходимости отмены данного сертификата, любой запрос к on-line сервису будет корректно отображать действительность сертификата. Однако эти методы навязывают новые требования безопасности: проверяющая сторона должна доверять on-line сервису действительности, в то время как репозиторий не обязательно должен быть доверяемым.

Профиль сертификата и расширений сертификата

Основные поля сертификата

Сертификат Х.509 v3 определяется следующим образом. Для вычисления подписи данные, которые должны быть подписаны, представляются с использованием ASN.1 однозначных правил представления (DER).

Certificate  ::=  SEQUENCE  {
    tbsCertificate     TBSCertificate,
    signatureAlgorithm AlgorithmIdentifier,
    signatureValue     BIT STRING  
}
TBSCertificate  ::= SEQUENCE  {
    version [0] EXPLICIT Version DEFAULT v1,
    serialNumber CertificateSerialNumber,
    signature AlgorithmIdentifier,
    issuer Name,
    validity Validity,
    subject Name,
    subjectPublicKeyInfo SubjectPublicKeyInfo,
    issuerUniqueID [1] IMPLICIT 
        UniqueIdentifier OPTIONAL,
    -- если присутствует, версия должна 
    -- быть v2 или v3
    subjectUniqueID [2] IMPLICIT 
        UniqueIdentifier OPTIONAL,
    -- если присутствует, версия должна быть
    -- v2 или v3 
    extensions [3] EXPLICIT Extensions OPTIONAL
    -- если присутствует, версия должна быть v3      
}
Version ::= INTEGER { v1(0), v2(1), v3(2) }
CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE {
    notBefore Time,
    notAfter  Time 
}
Time ::= CHOICE {
    utcTime     UTCTime,
    generalTime GeneralizedTime 
}
UniqueIdentifier ::= BIT STRING
SubjectPublicKeyInfo ::= SEQUENCE {
    algorithm        AlgorithmIdentifier,
    subjectPublicKey BIT STRING  
}
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
Extension ::= SEQUENCE  {
      extnID    OBJECT IDENTIFIER,
      critical  BOOLEAN DEFAULT FALSE,
      extnValue OCTET STRING  
}
Поля сертификата

Сертификат есть последовательность трех обязательных полей: tbsCertificate, signatureAlgorithm и signatureValue.

tbsCertificate

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

signatureAlgorithm

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

Идентификатор алгоритма определяется следующей ASN.1-структурой:

AlgorithmIdentifier ::= SEQUENCE  {
  algorithm  OBJECT IDENTIFIER,
  parameters ANY DEFINED BY algorithm OPTIONAL
}

Идентификатор алгоритма используется для определения криптографического алгоритма. Компонент OBJECT IDENTIFIER идентифицирует алгоритм (такой как DSA с SHA-1). Компоненты поля параметров изменяются в соответствии с указанным алгоритмом.

Поле должно содержать тот же самый идентификатор алгоритма, что и поле подписи в tbsCertificate.

signatureValue

Поле signatureValue содержит цифровую подпись, вычисленную для поля tbsCertificate, записанном в DER-представлении ASN.1. Это означает, что поле tbsCertificate, представленное как ASN.1 DER, используется в качестве входа в функцию подписи. Полученное значение подписи представлено как BIT STRING и включено в поле подписи. Детали данного процесса могут отличаться для каждого конкретного алгоритма подписи.

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

TBSCertificate

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

Version

Данное поле описывает версию представления сертификата. Если используются расширения, то версия должна быть 3 (значение – 2). Если расширения не указаны, но UniqueIdentifier представлен, версия может быть 2 (значение – 1); но версия может быть и 3. Если представлены только базовые поля, версия может быть 1 (значение в сертификате опущено как значение по умолчанию); но версия может быть 2 или 3.

Реализации должны быть готовы принимать любую версию сертификата. Как минимум конформные реализации должны распознавать версию 3 сертификатов.

Serial number

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

Signature

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

Данное поле должно содержать тот же самый идентификатор алгоритма, что и поле signatureAlgorithm в Certificate. Содержание необязательного поля параметров зависит от конкретного алгоритма.

Issuer

Поле issuer идентифицирует того, кто подписал и выпустил сертификат. Поле issuer должно содержать непустое уникальное имя (DN). Имя определяется в соответствии со следующей ASN.1 структурой:

Name ::= CHOICE { RDNSequence }
RDNSequence ::= SEQUENCE OF 
    RelativeDistinguishedName
RelativeDistinguishedName ::=
    SET OF AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
    type   AttributeType,
    value  AttributeValue 
}
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY DEFINED BY 
    AttributeType

Имя описывает иерархическое имя, состоящее из атрибутов, таких, например, как название страны, и соответствующих значений, таких как RU. Тип компонента AttributeValue определяется значением AttributeType.

Стандарт Х.509 не ограничивает набор типов атрибутов, которые могут появиться в имени. Тем не менее, стандартом рекомендуется поддерживать следующие типы атрибутов в именах выпускающего и субъекта:

Дополнительно могут присутствовать некоторые другие типы атрибутов в именах выпускающего и субъекта, например:

Также может присутствовать атрибут domainComponent. DNS предоставляет собой иерархическую систему обозначения ресурсов. Данный атрибут предоставляет удобный механизм для организаций, которые хотят использовать уникальные DN имена параллельно со своими DNS-именами. Это не заменяет dNSName компонент альтернативного поля имени. Стандарт не требует конвертировать такие имена в DNS-имена.

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

Действительность сертификата

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

САs должны всегда указывать даты действительности сертификата до 2049 года как UTCTime ; даты действительности сертификатов, начиная с 2050 года и далее, должны быть представлены как GeneralizedTime. Основная разница между представлениями времени в UTCTime и в GeneralizedTime заключается в том, что в UTCTime для значения года отводится две цифры, а в GeneralizedTime – четыре. В случае UTCTime, если год больше или равен 50, то он должен интерпретироваться как 19YY, а если год меньше 50, то он должен интерпретироваться как 20YY.

Период действительности сертификата является периодом времени от notBefore до notAfter включительно.

Subject

Поле subject идентифицирует участника, который является собственником сертификата и соответствующего закрытого ключа. Имя участника может быть указано в поле subject и/или в расширении subjectAltName . Если субъект является СА (т.е. основное обязательное расширение сА есть TRUE ), то поле subject должно содержать непустое уникальное имя, соответствующее содержимому поля issuer во всех сертификатах, выпущенных данным СА. Если субъект является выпускающим CRL (т.е. присутствует расширение использования ключа keyUsage , и значение cRLSign есть TRUE ), то поле субъекта должно содержать непустое уникальное имя, соответствующее содержимому поля issue во всех CRLs, выпущенных данным субъектом. Если информация именования субъекта представлена только расширением subjectAltName (т.е. ключ связан только с e-mail адресом или URI ), то имя субъекта должно быть пустой последовательностью, и расширение subjectAltName должно быть обязательным.

Поле subject, если оно не пусто, должно содержать уникальное имя в форме DN. СА может выпустить более одного сертификата с одним и тем же DN для одного и того же участника, определенного в subject.

Поле subject определено как тип Name в терминологии стандарта Х.501.

Следует учитывать, что существуют наследуемые реализации сертификационных центров, в которых имя из RFC 822 встроено в уникальное имя субъекта как атрибут EmailAddress. Значение атрибута для EmailAddress является типом IA5String, благодаря чему допускается включение символа "@", который не входит в набор символов PrintableString. Значения атрибута EmailAddress нечувствительны к регистру ( aaa@msu.ru – то же самое, что и AAA@MSU.RU ).

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

Информация открытого ключа субъекта

Данное поле используется для указания использования открытого ключа, в частности для идентификации алгоритма данного ключа (например, RSA, DSA или Diffie-Hellman). Алгоритм идентифицируется использованием AlgorithmIdentifier структуры. Идентификаторы объекта для поддерживаемых алгоритмов и методы представления материала открытого ключа (т.е. открытый ключ и параметры) определяются IANA.

Уникальные идентификаторы

Данные поля должны присутствовать только в том случае, если версия сертификата есть 2 или 3. Эти поля не должны присутствовать, если версия равна 1. Уникальные идентификаторы субъекта и выпускающего представлены в сертификате для получения возможности повторного использования имен субъекта и/или выпускающего в более позднее время. САs не должны создавать сертификаты с одинаковыми идентификаторами.

Расширения

Данное поле должно появляться только в том случае, если версия равна 3. Если оно присутствует, данное поле есть последовательность одного или более расширений сертификатов.

Расширения сертификата

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

Каждое расширение в сертификате может быть либо критичным, либо некритичным. Система, использующая сертификаты, должна отвергать сертификат, если она встретила критичное расширение, которое не в состоянии распознать; однако некритичные расширения могут игнорироваться, если они не распознаются. Рассмотрим рекомендуемые в Internet расширения сертификатов. Могут использоваться дополнительные расширения; однако следует осторожно устанавливать любые критические расширения в сертификаты, так как это может препятствовать проверке действительности сертификатов.

Каждое расширение должно иметь соответствующий OID и определяться ASN.1-структурой. Когда расширение появляется в сертификате, OID появляется как поле extnID, и соответствующая ASN.1 структура представления является значением строки октетов extnValue. Сертификат не должен включать более одного экземпляра конкретного расширения. Например, сертификат может содержать только одно расширение для идентификатора ключа уполномоченного органа. Расширение включает булево значение критичности со значением по умолчанию, равным FALSE. Для каждого расширения должны быть определены допустимые значения для поля критичности.

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

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

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

Стандартные расширения

Рассмотрим стандартные расширения сертификата, определенные в стандарте X.509. Каждое расширение имеет определенный OID. Эти OIDs являются элементами id-ce множества, которое определено следующим образом:

id-ce OBJECT IDENTIFIER ::=
    { joint-iso-ccitt(2) ds(5) 29 }
Идентификатор ключа сертификационного центра

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

Поле keyIdentifier расширения authorityKeyIdentifier должно быть включено во все сертификаты, выпущенные СА для обеспечения возможности создания сертификационного пути. Существует одно исключение: когда СА распространяет свой открытый ключ в форме самоподписанного сертификата, идентификатор ключа уполномоченного органа может быть опущен. Подпись для самоподписанного сертификата создается закрытым ключом, соответствующим открытому ключу субъекта. Это доказывает, что выпускающий обладает как открытым ключом, так и закрытым. В таком случае идентификаторы субъекта и уполномоченного органа должны быть одинаковыми, и идентификатор ключа может быть указан только для открытого ключа субъекта.

Значение поля keyIdentifier должно быть получено из открытого ключа, используемого для проверки подписи сертификата, или методом, который создает уникальные значения. Рассмотрим два метода создания идентификаторов ключей из открытого ключа и один метод создания уникальных значений для keyIdentifier. Если идентификатор ключа не был предварительно определен, рекомендуется использовать один из этих методов для создания keyIdentifiers. Если идентификатор ключа был предварительно определен, СА должен задействовать предварительно определенный идентификатор.

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

Данное расширение не должно помечаться как критичное.

id-ce-authorityKeyIdentifier OBJECT 
    IDENTIFIER ::= { id-ce 35 }
AuthorityKeyIdentifier ::= SEQUENCE {
  keyIdentifier [0] KeyIdentifier OPTIONAL,
  authorityCertIssuer [1] GeneralNames
      OPTIONAL,
  authorityCertSerialNumber [2] 
      CertificateSerialNumber OPTIONAL
}
KeyIdentifier ::= OCTET STRING
Идентификатор ключа субъекта

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

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

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

  1. keyIdentifier получается из 160-битного хэша SHA-1 значения битовой строки subjectPublicKey (исключая тег, длину и неиспользуемые биты).
  2. keyIdentifier получается из четырех битов поля типа со значением 0100, следующим за младшими 60 битами хэша SHA-1 значения битовой строки subjectPublicKey (исключая тег, длину и неиспользуемые биты).

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

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

Данное расширение не должно быть помечено как критичное.

id-ce-subjectKeyIdentifier OBJECT 
    IDENTIFIER ::=  { id-ce 14 }
SubjectKeyIdentifier ::= KeyIdentifier
Использование ключа

Расширение keyUsage определяет назначение (например, шифрование, подпись, подписывание сертификатов) ключа, содержащегося в сертификате. Ограничение использования должно применяться, когда ключ ограничивается использованием только в одной операции. Например, когда ключ RSA должен использоваться только для проверки подписей для объектов, отличных от сертификатов открытого ключа и CRLs, биты digitalSignature и/или nonRepudiation должны присутствовать. Также когда ключ RSA должен использоваться только для транспортировки ключа, бит keyEncipherment должен присутствовать.

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

id-ce-keyUsage OBJECT IDENTIFIER ::=
     { id-ce 15 }
keyUsage ::= BIT STRING {
    digitalSignature (0),
    nonRepudiation   (1),
    keyEncipherment  (2),
    dataEncipherment (3),
    keyAgreement (4),
    keyCertSign  (5),
    cRLSign      (6),
    encipherOnly (7),
    decipherOnly (8) 
}

Биты в keyUsage типе используются следующим образом:

Бит digitalSignature установлен, когда открытый ключ субъекта используется с механизмом цифровой подписи для поддержки сервисов безопасности, отличных от подписывания сертификата (бит 5) или подписывания CRL (бит 6). Например, если механизмы цифровых подписей используются для аутентификации участника или аутентификации и целостности исходных данных.

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

Более тонкое различие между битами digitalSignature и nonRepudiation может определяться конкретными политиками сертификации.

Бит keyEncipherment установлен, когда открытый ключ субъекта используется для пересылки ключа. Например, когда ключ RSA применяется для шифрования ключа сессии, этот бит должен быть установлен.

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

Бит keyAgreement установлен, когда открытый ключ субъекта используется для согласования ключа. Например, когда ключ Диффи-Хеллмана используется для управления ключом, этот бит установлен.

Бит keyCertSign установлен, когда открытый ключ субъекта используется для проверки подписи в сертификатах открытого ключа. Если бит keyCertSign установлен, то бит сА в расширении базовых ограничений также должен быть установлен.

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

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

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

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

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

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

Увеличение периода использования закрытого ключа позволяет выпускающему сертификат указать период действительности закрытого ключа, отличный от периода действительности сертификата. Данное расширение предназначено для использования с ключами цифровых подписей. Расширение состоит из двух необязательных компонентов, notBefore и notAfter. Закрытый ключ, связанный с сертификатом, не должен использоваться для подписывания объектов до и после времени, указанного соответственно этими двумя компонентами. САs не должны создавать сертификаты с расширениями периода использования закрытого ключа, если, по крайней мере, один из компонентов не присутствует; расширение является некритичным.

Если расширение используется, notBefore и notAfter представлены как GeneralizedTime.

id-ce-privateKeyUsagePeriod OBJECT 
    IDENTIFIER ::=  { id-ce 16 }
PrivateKeyUsagePeriod ::= SEQUENCE {
    notBefore [0] GeneralizedTime OPTIONAL,
    notAfter  [1] GeneralizedTime OPTIONAL 
}
Политики сертификата

Расширение политик сертификата certificatePolicies содержит последовательность из одного или более идентификаторов политики, каждый из которых может иметь квалификатор. Эти квалификаторы не должны изменять определение политики.

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

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

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

В настоящий момент определено два типа квалификаторов политики: CPS Pointer и User Notice.

Квалификатор CPS Pointer содержит указатель на Certification Practice Statement (CPS) – регламент сертификационной практики, опубликованный СА. Указатель должен быть представлен в виде URI.

Считается, что квалификатор User Notice будет показан соответствующему участнику при использовании сертификата. Данный квалификатор имеет два необязательных поля: поле noticeRef и поле explicitText.

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

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

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

id-ce-certificatePolicies OBJECT 
    IDENTIFIER ::=  { id-ce 32 }
anyPolicy OBJECT IDENTIFIER ::= {
    id-ce-certificate-policies 0 }
certificatePolicies ::= SEQUENCE SIZE (
    1..MAX) OF PolicyInformation
PolicyInformation ::= SEQUENCE {
  policyIdentifier CertPolicyId,
  policyQualifiers SEQUENCE SIZE (1..MAX) OF
      PolicyQualifierInfo OPTIONAL 
}
CertPolicyId ::= OBJECT IDENTIFIER
PolicyQualifierInfo ::= SEQUENCE {
  policyQualifierId  PolicyQualifierId,
  qualifier ANY DEFINED BY policyQualifierId
}
    -- policyQualifierIds для квалификаторов
	-- политики в Internet
  id-qt         OBJECT IDENTIFIER ::= { 
      id-pkix 2 }
  id-qt-cps     OBJECT IDENTIFIER ::= { 
      id-qt 1 }
  id-qt-unotice OBJECT IDENTIFIER ::= { 
      id-qt 2 }
PolicyQualifierId ::= OBJECT IDENTIFIER (
     id-qt-cps | id-qt-unotice )
Qualifier ::= CHOICE {
  cPSuri     CPSuri,
  userNotice UserNotice }
CPSuri ::= IA5String
UserNotice ::= SEQUENCE {
  noticeRef    NoticeReference OPTIONAL,
  explicitText DisplayText OPTIONAL
}
NoticeReference ::= SEQUENCE {
  organization  DisplayText,
  noticeNumbers SEQUENCE OF INTEGER 
}
DisplayText ::= CHOICE {
  ia5String     IA5String     (SIZE (1..200)),
  visibleString VisibleString (SIZE (1..200)),
  bmpString     BMPString     (SIZE (1..200)),
  utf8String    UTF8String    (SIZE (1..200)) 
}
Отображения политик

Данное расширение используется в сертификатах СА. Оно перечисляет одну или более пар OIDs; каждая пара включает issuerDomainPolicy и subjectDomainPolicy. Пара определяет, что выпустивший СА считает свою issuerDomainPolicy эквивалентной subjectDomainPolicy субъекта СА.

Отображение политик определяет список политик, связанных с субъектом СА, которые могут приниматься как эквивалентные issuerDomainPolicy.

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

Данное расширение может не поддерживаться САs и/или приложениями, и оно не должно быть критичным.

id-ce-policyMappings OBJECT IDENTIFIER ::= {
    id-ce 33 }
PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
  issuerDomainPolicy  CertPolicyId,
  subjectDomainPolicy CertPolicyId
}
Альтернативное имя субъекта

Расширение альтернативных имен субъекта допускает дополнительные идентификации, связанные с субъектом сертификата. Данная опция включает e-mail адрес, DNS-имя, IP-адрес и URI. Существуют и другие формы имени, в том числе полностью локальные определения. Может быть включено несколько форм имени и несколько экземпляров для каждой из них. Если подобные идентификации необходимо ввести в сертификат, должно использоваться расширение, описывающее альтернативное имя субъекта (или альтернативное имя выпускающего); однако DNS-имя может быть представлено в поле субъекта посредством атрибута domainComponent.

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

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

Когда расширение subjectAltName содержит электронный адрес, он должен иметь вид, определенный в RFC 822, т.е. иметь форму local-part@domain.

Когда расширение subjectAltName содержит iPAddress, адрес должен храниться в строке октетов в "сетевом порядке байтов", как определено в RFC 791. Для IP версии 4 строка октетов должна содержать строго четыре октета. Для IP версии 6 строка октетов должна содержать строго 16 октетов.

Когда расширение subjectAltName содержит метку доменного имени системы, доменное имя должно храниться в dNSName ( IA5String ). Имя должно иметь вид, определенный в RFC 1034. Заметим, что хотя буквы верхнего и нижнего регистров в доменном имени допустимы, регистр не имеет значения. Кроме того, хотя строка " " является допустимым доменным именем, расширения subjectAltName с dNSName в виде " " использоваться не должны. Наконец, использование DNS-представления для адресов e-mail ( xxx.cmc.msu.ru вместо xxx@cmc.msu.ru ) не допускается.

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

Когда расширение subjectAltName содержит URI, имя должно храниться в uniformResourceIdentifier (как IA5String ). Имя не должно быть относительным URL и должно следовать синтаксису URL и правилам представления, описанным в RFC 1738. Имя должно включать схему (например, HTTP или FTP ) и конкретную часть этой схемы. Конкретная часть схемы должна включать полностью определенное доменное имя или IP-адрес хоста.

Как указано в RFC 1738, имя схемы нечувствительно к регистру (т.е. http эквивалентно HTTP ). Часть хоста также нечувствительна к регистру, но остальные компоненты конкретной части схемы могут быть чувствительны к регистру.

Когда расширение subjectAltName содержит DN в directoryName, DN может не быть уникальным для субъекта, который сертифицируется СА, определяемым полем issuer name. СА может выпустить более одного сертификата с одним и тем же DN для некоторого субъекта.

subjectAltName может поддерживать дополнительные типы имен с помощью поля otherName. Формат и семантики имени определяются с помощью OBJECT IDENTIFIER. Само имя определяется как значение поля otherName. Например, имена формата Kerberos могут быть представлены в otherName с использованием OID-имени принципала Kerberos и последовательности Realm и PrincipalName.

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

Если расширение subjectAltName присутствует, последовательность должна содержать, по крайней мере, одну запись. В отличие от поля субъекта, САs не должны выпускать сертификаты с subjectAltNames, содержащими пустые поля GeneralName. Например, rfc822Name представляется как IA5String. Хотя IA5String допускает пустую строку, такое rfc822Name использоваться не должно.

id-ce-subjectAltName OBJECT IDENTIFIER ::= {
    id-ce 17 }
SubjectAltName ::= GeneralNames
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF
    GeneralName
GeneralName ::= CHOICE {
  otherName     [0] OtherName,
  rfc822Name    [1] IA5String,
  dNSName       [2] IA5String,
  x400Address   [3] ORAddress,
  directoryName [4] Name,
  ediPartyName  [5] EDIPartyName,
  uniformResourceIdentifier [6] IA5String,
  iPAddress     [7] OCTET STRING,
  registeredID  [8] OBJECT IDENTIFIER
}
OtherName ::= SEQUENCE {
  type-id OBJECT IDENTIFIER,
  value [0] EXPLICIT ANY DEFINED BY type-id
}
EDIPartyName ::= SEQUENCE {
  nameAssigner [0] DirectoryString OPTIONAL
  partyName    [1] DirectoryString 
}
Альтернативные имена выпускающего

Данное расширение используется для связывания идентификации в стиле Internet с выпускающим сертификаты. Альтернативные имена выпускающего должны иметь такое же представление, как альтернативные имена субъекта.

Когда данное расширение присутствует, оно не должно быть помечено как критичное.

id-ce-issuerAltName OBJECT IDENTIFIER ::= {
    id-ce 18 }
IssuerAltName ::= GeneralNames
Атрибуты директории субъекта

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

id-ce-subjectDirectoryAttributes OBJECT 
    IDENTIFIER ::= { id-ce 9 }
SubjectDirectoryAttributes ::= 
    SEQUENCE SIZE (1..MAX) OF Attribute
Базовые ограничения

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

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

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

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

САs не должны включать поле pathLenConstraint, если булевское значение сА не установлено и расширение использования ключа не имеет бит keyCertSign.

id-ce-basicConstraints OBJECT IDENTIFIER ::=
    { id-ce 19 }
BasicConstraints ::= SEQUENCE {
  cA  BOOLEAN DEFAULT FALSE,
  pathLenConstraint INTEGER (0..MAX) OPTIONAL
}
Ограничения имени

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

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

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

Для URIs ограничение применяется только к части хоста из имени. Ограничение может указывать хост или домен. Примерами могут служить cmc.msu.ru или .msu.ru. Когда ограничение начинается с точки, оно соответствует одному или более поддоменам. Это означает, что ограничению .msu.ru удовлетворяют как cmc.msu.ru, так и oit.cmc.msu.ru. Когда ограничение не начинается с точки, оно определяет хост.

Ограничение имени для e-mail адресов может специфицировать конкретный почтовый ящик, все адреса на конкретном хосте или все почтовые ящики в домене. Для указания конкретного почтового ящика ограничение должно содержать полный почтовый адрес. Например, xxx@cmc.msu.ru определяет почтовый ящик "xxx" на хосте cmc.msu.ru. Для указания любого адреса в домене ограничение указывается с ведущей точкой (как в URIs). Например, .msu.ru специфицирует все e-mail адреса в домене msu.ru, а не только e-mail адреса на хосте msu.ru.

Ограничения DNS имени выражены как cmc.msu.ru. Любое DNS-имя, которое может быть сконструировано простым добавлением слева, соответствует ограничению имени. Например, oit.cmc.msu.ru будет удовлетворять ограничению, а mm.msu.ru – нет.

Существуют наследуемые реализации, в которых имя RFC 822 встроено в уникальное имя субъекта в виде атрибута типа EmailAddress. Когда имена rfc822 имеют ограничения, но сертификат не содержит альтернативного имени субъекта, ограничение имени rfc822 должно применяться к атрибуту типа EmailAddress в уникальном имени субъекта.

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

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

id-ce-nameConstraints OBJECT IDENTIFIER ::=
    { id-ce 30 }
NameConstraints ::= SEQUENCE {
  permittedSubtrees [0] GeneralSubtrees 
      OPTIONAL,
  excludedSubtrees  [1] GeneralSubtrees 
      OPTIONAL 
}
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) 
    OF GeneralSubtree
GeneralSubtree ::= SEQUENCE {
  base        GeneralName,
  minimum [0] BaseDistance DEFAULT 0,
  maximum [1] BaseDistance OPTIONAL 
}
BaseDistance ::= INTEGER (0..MAX)
Ограничения политики

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

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

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

Конформные САs не должны выпускать сертификаты, в которых ограничения политики являются пустой последовательностью. Это означает, что, по крайней мере, одно из полей requireExplicitPolicy или inhibitPolicyMapping должно присутствовать.

Данное расширение может быть как критичным, так и некритичным.

id-ce-policyConstraints OBJECT IDENTIFIER ::=
    { id-ce 36 }
PolicyConstraints ::= SEQUENCE {
  requireExplicitPolicy [0] SkipCerts 
      OPTIONAL,
  inhibitPolicyMapping  [1] SkipCerts 
      OPTIONAL 
}
SkipCerts ::= INTEGER (0..MAX)
Расширенное использование ключа

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

id-ce-extKeyUsage OBJECT IDENTIFIER ::= 
    { id-ce 37 }
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX)
    OF KeyPurposeId
KeyPurposeId ::= OBJECT IDENTIFIER

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

Данное расширение может быть как критичным, так и некритичным.

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

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

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

Определены следующие цели использования ключа:

anyExtendedKeyUsage OBJECT IDENTIFIER ::=
    { id-ce-extKeyUsage 0 }
id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
id-kp-serverAuth OBJECT IDENTIFIER ::= 
    { id-kp 1 }
-- аутентификация сервера TLS  
-- биты использования ключа, которые могут
-- быть ограничением: digitalSignature,
-- keyEncipherment или keyAgreement
id-kp-clientAuth OBJECT IDENTIFIER ::= 
    { id-kp 2 }
-- аутентификация клиента TLS 
-- биты использования ключа, которые могут
-- быть ограничением: digitalSignature 
-- и/или keyAgreement
id-kp-codeSigning OBJECT IDENTIFIER ::= 
    { id-kp 3 }
-- подписывание загруженного выполняемого кода
-- биты использования ключа, которые могут 
-- быть ограничением: digitalSignature
id-kp-emailProtection OBJECT IDENTIFIER ::= 
    { id-kp 4 }
-- защита е-mail
-- биты использования ключа, которые могут 
-- быть ограничением: digitalSignature,
-- nonRepudiation, и/или (keyEncipherment 
-- или keyAgreement)
id-kp-timeStamping OBJECT IDENTIFIER ::= 
    { id-kp 8 }
-- связывание хэша объекта со временем 
-- биты использования ключа, которые могут 
-- быть ограничением: digitalSignature 
-- и/или nonRepudiation
id-kp-OCSPSigning OBJECT IDENTIFIER ::= 
    { id-kp 9 }
-- подписывание ответов OCSP
-- биты использования ключа, которые могут 
-- быть ограничением: digitalSignature 
-- и/или nonRepudiation
Точки распространения CRL

Расширение для точек распространения CRL определяет, как может быть получена информация CRL. Расширение должно быть некритичным, но рекомендуется, чтобы оно поддерживалось как САs, так и приложениями. Далее мы подробно рассмотрим управление CRL.

Расширение cRLDistributionPoints является последовательностью DistributionPoint. DistributionPoint состоит из трех полей, каждое из которых является необязательным: distributionPoint, reasons и cRLIssuer. Хотя каждое из этих полей является необязательным, DistributionPoint не должно состоять только из поля reasons ; либо distributionPoint, либо cRLIssuer должно присутствовать. Если выпускающий сертификата не является выпускающим CRL, то поле cRLIssuer должно присутствовать и содержать имя выпускающего CRL. Если выпускающий сертификата является также и выпускающим CRL, то поле cRLIssuer должно быть опущено, и поле distributionPoint должно присутствовать. Если поле distributionPoint опущено, cRLIssuer должно присутствовать и включать имя, соответствующее записи Каталога Х.500 или LDAP, в которой размещен CRL.

Когда поле distributionPoint присутствует, оно содержит либо последовательность общих имен, либо единственное значение nameRelativeToCRLIssuer. Если расширение cRLDistributionPoints содержит общее имя типа URI, предполагается следующая семантика: URI является указателем на текущий CRL для соответствующих кодов причин и выпускается соответствующим cRLIssuer.

Если DistributionPointName содержит несколько значений, каждое имя описывает определенный механизм получения одного и того же CRL. Например, один и тот же CRL может быть доступен как по LDAP, так и по HTTP.

Если DistributionPointName содержит единственное значение nameRelativeToCRLIssuer, значение представляет собой фрагмент уникального имени. Фрагмент присоединяется к уникальному имени Х.500 выпускающего CRL для получения уникального указателя имени. Если поле cRLIssuer в DistributionPoint присутствует, то фрагмент имени присоединяется к уникальному имени выпускающего сертификат. DistributionPointName не должно использовать альтернативное nameRelativeToCRLIssuer, когда cRLIssuer содержит более одного уникального имени.

Если в DistributionPoint поле reasons опущено, CRL должен включать информацию об отмене для всех кодов причин.

Поле сRLIssuer определяет участника, который подписал и выпустил CRL. Если оно присутствует, cRLIssuer должно содержать, по крайней мере, одно уникальное имя (DN) X.500 и может включать другие формы имени. Так как cRLIssuer сравнивается с именем выпускающего CRL,

id-ce-cRLDistributionPoints OBJECT 
    IDENTIFIER ::= { id-ce 31 }
CRLDistributionPoints ::= 
  SEQUENCE SIZE (1..MAX) OF DistributionPoint
DistributionPoint ::= SEQUENCE {
  distributionPoint [0] DistributionPointName
      OPTIONAL,
  reasons   [1] ReasonFlags OPTIONAL,
  cRLIssuer [2] GeneralNames OPTIONAL 
}
DistributionPointName ::= CHOICE {
  fullName  [0]   GeneralNames,
  nameRelativeToCRLIssuer [1]   
      RelativeDistinguishedName 
}
ReasonFlags ::= BIT STRING {
  unused               (0),
  keyCompromise        (1),
  cACompromise         (2),
  affiliationChanged   (3),
  superseded           (4),
  cessationOfOperation (5),
  certificateHold      (6),
  privilegeWithdrawn   (7),
  aACompromise         (8) 
}
Предотвращение anyPolicy

Расширение предотвращения anyPolicy может быть использовано в сертификатах, выпущенных САs. Предотвращение any-policy указывает, что конкретный anyPolicy OID со значениями { 2 5 29 32 0 } не считается явно соответствующим остальным политикам сертификата. Значение определяет количество дополнительных сертификатов, которые могут появиться в пути до того как anyPolicy будет запрещена. Например, значение, равное единице, указывает, что anyPolicy может быть обработана в сертификатах, выпущенных субъектом данного сертификата, но не в дополнительных сертификатах в пути.

Данное расширение должно быть критическим.

id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::=
    { id-ce 54 }
InhibitAnyPolicy ::= SkipCerts
SkipCerts ::= INTEGER (0..MAX)

Самый свежий CRL (точка распространения Delta CRL)

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

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

id-ce-freshestCRL OBJECT IDENTIFIER ::=
    { id-ce 46 }
FreshestCRL ::= CRLDistributionPoints
Частные расширения Internet

На сегодня определено два расширения для использования в PKI Internet. Эти расширения могут применяться для предоставления приложениям on-line информации о выпускающем СА или о субъекте. Так как информация может быть доступна в нескольких формах, каждое расширение является последовательностью IA5String значений, представляющих собой URI. URI неявно определяют размещение и формат информации, а также метод ее получения.

id-pkix  OBJECT IDENTIFIER ::=
  { iso(1) identified-organization(3) dod(6)
    internet(1) security(5) mechanisms(5)
	pkix(7) 
}
id-pe  OBJECT IDENTIFIER ::= { id-pkix 1 }
Доступ к информации уполномоченного органа

Расширение доступа к информации уполномоченного органа определяет, как получить доступ к информации и сервисам СА для сертификата, в котором расширение присутствует. Информация и сервисы могут включать on-line сервисы проверки действительности и данные политики СА. Расположение CRLs в данном расширении не указывается; эта информация предоставляется расширением cRLDistributionPoints. Данное расширение может включаться в сертификаты конечного участника или СА и не должно быть критичным.

id-pe-authorityInfoAccess OBJECT 
  IDENTIFIER ::= { id-pe 1 }
AuthorityInfoAccessSyntax  ::=
  SEQUENCE SIZE (1..MAX) OF AccessDescription
AccessDescription ::= SEQUENCE {
  accessMethod    OBJECT IDENTIFIER,
  accessLocation  GeneralName  
}
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-ad-caIssuers OBJECT IDENTIFIER ::= 
    { id-ad 2 }
id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }

Каждая запись в последовательности AuthorityInfoAccessSyntax описывает формат и размещение дополнительной информации, предоставляемой СА, который выпустил сертификат с данным расширением. Тип и формат информации определяется полем accessMethod ; в поле accessLocation указывается место размещения информации. Механизм получения может предполагаться accessMethod или указываться accessLocation.

В настоящий момент определено два accessMethod OIDs:

id-ad-caIssuers и id-ad-ocsp.

Когда accessMethod представляет собой id-ad-caIssuers, поле accessLocation определяет сервер и протокол доступа для получения указанного описания. Поле accessLocation определяется как GeneralName, которое может принимать несколько форм. Когда информация доступна через HTTP, FTP или LDAP, accessLocation должно быть uniformResourceIdentifier. Когда информация доступна через Протокол Доступа к Директории (DAP), accessLocation должно быть directoryName. Запись для этого directoryName содержит сертификаты СА в атрибуте crossCertificatePair. Когда информация доступна через e-mail, accessLocation должен быть rfc822Name.

id-ad-ocsp OID используется, когда информация отмены для сертификата, содержащего данное расширение, доступна с использованием Online Certificate Status Protocol (OCSP). В этом случае в поле accessLocation указывается размещение OCSP сервера.

Информационный доступ субъекта

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

id-pe-subjectInfoAccess OBJECT IDENTIFIER ::=
    { id-pe 11 }
SubjectInfoAccessSyntax ::=
    SEQUENCE SIZE (1..MAX) OF 
	    AccessDescription
AccessDescription ::= SEQUENCE {
    accessMethod    OBJECT IDENTIFIER,
    accessLocation  GeneralName  
}

Каждая запись в последовательности SubjectInfoAccessSyntax описывает формат и размещение дополнительной информации, предоставленной субъектом сертификата, в котором данное расширение появилось. Тип и формат информации определяется полем accessMethod ; в поле accessLocation указывается место размещения информации.

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

id-ad-caRepository OID используется, когда субъект является СА и публикует свои сертификаты и CRLs (если выпускает) в репозитории. Поле accessLocation определено как GeneralName, которое может иметь несколько форм. Когда информация доступна через HTTP, FTP или LDAP, accessLocation должен быть uniformResourceIdentifier. Когда информация доступна через Протокол Доступа к Директории (DAP), accessLocation должен быть directoryName. Когда информация доступна по e-mail, accessLocation должен быть rfc822Name. Семантики остальных форм имени для accessLocation (когда accessLocation есть id-ad-caRepository ) в настоящее время не определены.

id-ad-timeStamping OID используется, когда субъект предоставляет сервисы отметки времени, используя Протокол Отметки Времени. Когда сервисы отметки времени доступны по HTTP или FTP, accessLocation должен быть uniformResourceIdentifier. Когда сервисы отметки времени доступны по e-mail, accessLocation должен быть rfc822Name. Когда сервисы отметки времени доступны посредством TCP/IP, могут использоваться формы имен dNSName или ipAddress. Семантика других форм имени для accessLocation (когда accessLocation есть id-ad-timeStamping ) в настоящий момент не определена.

Лекция 5. Инфраструктура Открытого Ключа (часть 5)

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

Профиль CRL и расширений CRL

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

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

Каждый CRL имеет определенную область. Областью CRL является множество сертификатов, которые могут появиться в данном CRL . Например, область может быть "все сертификаты, выпущенные СА Х", "все сертификаты СА, выпущенные СА Х", "все сертификаты, выпущенные СА Х, которые отменены по причинам компрометации ключа и компрометации ключа СА" или может быть множество сертификатов, основанное на произвольной локальной информации, такой как "все сертификаты, выпущенные для сотрудников факультета ВМиК МГУ".

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

САs могут не выпускать CRLs, если предусмотрены другие механизмы отмены или предоставления статуса сертификата. CRLs должны иметь версию 2, включать дату в поле nextUpdate следующего выпуска CRL, расширение номера CRL и расширение идентификатора ключа уполномоченного органа.

Поля CRL

Рассмотрим синтаксис CRL v2. Для вычисления подписи подписываемые данные представлены в ASN.1 DER-представлении. ASN.1 DER-представление определяет систему представления тега, длины и значения для каждого элемента.

CertificateList ::= SEQUENCE  {
  tbsCertList        TBSCertList,
  signatureAlgorithm AlgorithmIdentifier,
  signatureValue     BIT STRING  
}
TBSCertList ::= SEQUENCE  {
  version    Version OPTIONAL,
  -- если присутствует, должно быть v2
  signature  AlgorithmIdentifier,
  issuer     Name,
  thisUpdate Time,
  nextUpdate Time OPTIONAL,
  revokedCertificates SEQUENCE OF SEQUENCE {
    userCertificate CertificateSerialNumber,
    revocationDate  Time,
    crlEntryExtensions Extensions OPTIONAL
    -- если присутствует, должно быть v2
 }   OPTIONAL,
 crlExtensions [0] EXPLICIT Extensions OPTIONAL
  -- если присутствует, должно быть v2
}
Поля CertificateList

CertificateList есть последовательность трех обязательных полей.

tbsCertList

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

signatureAlgorithm

Поле signatureAlgorithm содержит идентификатор алгоритма, использованного выпускающим CRL для подписи CertificateList. Данное поле должно содержать те же самые идентификаторы алгоритмов, что и поле signature в последовательности tbsCertList.

signatureValue

Поле signatureValue содержит цифровую подпись, вычисленную над ASN.1 DER-представлением tbsCertList. ASN.1 DER-представление tbsCertList используется в виде входа в функцию подписывания. Данное значение подписи представлено в виде строки битов и содержится в поле CRL signatureValue. Детали данного процесса для разных алгоритмов различны.

САs, которые выпускают и CRL, могут использовать один закрытый ключ для подписывания сертификатов и CRL или могут иметь разные закрытые ключи для подписывания сертификатов и CRL. Когда используются разные закрытые ключи, один имеет установленный бит keyCertSign в расширении использования ключа, другой имеет установленный бит cRLSign в расширении использования ключа. Когда используются разные закрытые ключи, соответствующие им сертификаты содержат разные идентификаторы ключа. Считается, что использование разных сертификатов СА для проверки действительности подписей сертификатов и подписей CRL должно повышать уровень безопасности; однако это усложняет приложения и может ограничивать интероперабельность. Многие приложения создают сертификационный путь и затем проверяют его действительность. Проверка CRL оборачивается требованием, чтобы отдельный сертификационный путь был создан и проверен для сертификата, которым подписан CRL. Приложения, которые выполняют проверку CRL, должны поддерживать проверку действительности сертификационного пути, когда сертификаты и CRLs подписаны закрытыми ключами различных СА.

Список сертификатов "To Be Signed"

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

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

Версия

Данное необязательное поле описывает версию представления CRL. Когда используются расширения, данное поле должно присутствовать и указывать версию 2.

Подпись

Данное поле содержит идентификатор алгоритма, использованного для подписывания CRL. Оно должно содержать тот же самый идентификатор алгоритма, что и поле signatureAlgorithm в последовательности CertificateList.

Имя выпускающего

Имя выпускающего определяет участника, который подписал и выпустил CRL. Идентификация выпускающего выполняется в поле issuerName. В расширении issuerAltName могут присутствовать альтернативные формы имени. Поле issuerName должно содержать уникальное имя (DN) X.500. Данное поле определено как Х.501 типа Name и должно следовать правилам представления для поля issuerName в сертификате.

Дата данного изменения

Данное поле указывает дату выпуска данного CRL. ThisUpdate может быть представлено как UTCTime или GeneralizedTime.

Следующее изменение

Данное поле определяет дату, когда будет выпущен следующий CRL. Следующий CRL может быть выпущен до указанной даты, но не может быть выпущен позднее указанной даты. Выпускающие CRL должны выпускать CRLs со временем nextUpdate равным или более поздним, чем все предыдущие CRLs. nextUpdate может быть представлено в виде UTCTime или GeneralizedTime.

Требуется включать nextUpdate во все CRLs, выпускаемые конкретным выпускающими. Заметим, что ASN.1 синтаксис TBSCertList описывает данное поле как OPTIONAL, которое состоит из ASN.1-структур, определенных в стандарте X.509.

Отмененные сертификаты

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

Расширения

Данное поле может появиться, если версия есть 2. Если данное поле присутствует, оно является последовательностью одного или более расширений CRL.

Расширения CRL

Расширения, определенные ANSI X9, ISO/IEC и ITU-T для X.509 v2 CRLs предоставляют методы для связывания дополнительных атрибутов с CRLs. Формат X.509 v2 CRL также позволяет определять частные расширения. Каждое расширение в CRL может быть обозначено как критичное или некритичное. Проверка действительности CRL не должна выполняться, если встречается критичное расширение, которое неизвестно как обрабатывать. Однако нераспознанные некритичные расширения могут игнорироваться. Рассмотрим наиболее часто используемые расширения. Следует заметить, что не рекомендуется устанавливать критичные расширения в CRLs, которые могут использоваться общими приложениями, так как невозможность обработать критичное расширение может привести к тому, что приложение не сможет получить полный список отмененных сертификатов.

Идентификатор ключа уполномоченного органа

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

Альтернативное имя выпускающего

Расширение альтернативных имен выпускающего позволяет задействовать дополнительные идентификаторы, которые связаны с выпускающим CRL. Альтернативными именами могут быть e-mail адрес, имя DNS, IP-адрес и URI. Могут быть включены несколько вариантов имен и несколько форм имени. Всякий раз, когда такие идентификаторы используются, должно применяться расширение для альтернативного имени; однако имя DNS может быть представлено в поле выпускающего посредством атрибута domainComponent.

Расширение issuerAltName не должно быть помечено как критичное.

Номер CRL

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

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

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

Индикатор дельта CRL

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

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

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

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

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

  1. Полный CRL и дельта CRL имеют одного и того же выпускающего.
  2. Полный CRL и дельта CRL имеют одну и ту же область. Два CRLs имеют одну и ту же область, если выполнено одно из следующих условий:
    1. Расширение issuingDistributionPoint опущено и в полном CRL, и в дельта CRL.
    2. Расширение issuingDistributionPoint присутствует и в полном CRL, и в дельта CRL, и значения каждого из этих полей одинаковы в обоих CRLs.
  3. Номер CRL полного CRL больше или равен BaseCRLNumber, указанному в дельта CRL. Это означает, что полный CRL включает (как минимум) всю информацию об отмене, которая содержится в упоминаемом базовом CRL.
  4. Номер CRL полного CRL меньше, чем номер CRL дельта CRL. Это означает, что в последовательной нумерации дельта CRL следует за полным CRL.

Считается, что статус сертификата изменяется, если он отменяется, приостанавливается, восстанавливается после приостановки или изменяется причина его отмены.

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

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

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

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

Точка распространения CRL

Точка распространения CRL является критичным расширением CRL, которое определяет точку распространения CRL и область для конкретного CRL ; она также указывает, охватывает ли CRL отмену только сертификатов конечных участников, только сертификатов СА или ограниченное множество кодов причин. Хотя расширение и является критичным, не требуется, чтобы все приложения поддерживали данное расширение.

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

Коды причин, связанные с точкой распространения, должны быть указаны в onlySomeReasons. Если onlySomeReasons не присутствует, точка распространения должна содержать отмены для всех кодов причин. САs могут использовать точки распространения CRL для разбиения CRL в соответствии с причиной отмены. В этом случае отмены с кодом причины keyCompromise (1), cACompromise (2) и aACompromise (8) появляются в одной точке распространения, а отмены с другими кодами причины появляются в другой точке распространения.

Если поле distributionPoint присутствует и содержит URI, должна предполагаться следующая семантика: объект является указателем на самый последний CRL, выпущенный данным выпускающим CRL. Для этой цели определены схемы URI FTP, HTTP, MAILTO и LDAP. URI должен быть абсолютным, а не относительным путем, и должен указывать хост.

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

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

id-ce-issuingDistributionPoint
  OBJECT IDENTIFIER ::= { id-ce 28 }

issuingDistributionPoint ::= SEQUENCE {
  distributionPoint [0]
    DistributionPointName OPTIONAL,
  onlyContainsUserCerts [1]
    BOOLEAN DEFAULT FALSE,
  onlyContainsCACerts [2] BOOLEAN
    DEFAULT FALSE,
  onlySomeReasons [3] ReasonFlags OPTIONAL,
  indirectCRL     [4] BOOLEAN DEFAULT FALSE,
  onlyContainsAttributeCerts [5] BOOLEAN
    DEFAULT FALSE 
}
Наиболее свежий CRL (точка распространения дельта CRL)

Расширение наиболее свежий CRL определяет, как получена информация дельта CRL для данного полного CRL. Расширение должно быть некритичным. Данное расширение не должно появляться в дельта CRLs.

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

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

Расширения записи CRL

Расширения записи CRL, определенные ISO/IEC, ITU-T и ANSI Х9 для Х.509 v2 CRLs, предоставляют методы для связывания дополнительных атрибутов с записями CRL. Формат Х.509 v2 CRL также позволяет определять частные расширения записей CRL для хранения информации, используемой конкретным сообществом. Каждое расширение в записи CRL может быть определено как критичное и некритичное. CRL не должен проходить проверку на действительность, если встретилось критичное расширение записи, которое неизвестно как обработать. Однако нераспознанное некритичное расширение записи CRL можно проигнорировать. Рассмотрим рекомендуемые расширения, используемые в записях CRL Internet, а также стандартное размещение информации.

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

Код причины

Расширение reasonCode является некритичным расширением записи CRL, которое указывает причину отмены сертификата. Выпускающие CRL должны включать важные коды причин в записи CRL ; однако расширение записи CRL кода причины должно быть опущено вместо использования неспецифицированного значения (0) reasonCode.

id-ce-cRLReason OBJECT IDENTIFIER ::=
  { id-ce 21 }
  -- reasonCode ::= { CRLReason }
CRLReason ::= ENUMERATED {
    unspecified            (0),
    keyCompromise          (1),
    cACompromise           (2),
    affiliationChanged     (3),
    superseded             (4),
    cessationOfOperation   (5),
    certificateHold        (6),
    removeFromCRL          (8),
    privilegeWithdrawn     (9),
    aACompromise           (10) 
}
Код инструкции приостановки

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

Дата недействительности

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

Проверка действительности сертификационного пути

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

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

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

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

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

Проверка действительности базового пути

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

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

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

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

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

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

  1. Для всех х в {1, ..., n-1} субъект сертификата х является выпускающим сертификата х+1.
  2. Сертификат 1 выпущен доверенным начальным сертификатом.
  3. Сертификат n является действительным сертификатом.
  4. Для всех х в {1, ..., n-1} сертификат был действительным в момент запроса.

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

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

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

Данный раздел описывает алгоритм, состоящий из четырех основных шагов:

  1. Инициализация.
  2. Базовая обработка сертификата.
  3. Подготовка для обработки следующего сертификата.
  4. Завершение (wrap-up).

Шаги (1) и (4) выполняются только один раз. Шаг (2) выполняется для всех сертификатов в пути. Шаг (3) выполняется для всех сертификатов в пути, за исключением последнего. На рис.17.1 представлена высокоуровневая диаграмма потока для данного алгоритма.

Входы

Данный алгоритм предполагает наличие следующих семи входов:

  1. Ожидаемый сертификационный путь длиной n.
  2. Текущие дата и время.
  3. User-initial-policy-set: множество идентификаторов политик сертификации, принимаемых пользователем сертификата. User-initial-policy-set имеет специальное значение anyРolicy, если пользователю политика сертификации не важна.
  4. Информация о доверенном начальном сертификате в сертификационном пути. Информация о доверенном начальном сертификате включает:
    1. Имя выпускающего.
    2. Алгоритм открытого ключа.
    3. Открытый ключ.
    4. Необязательно – параметры данного открытого ключа.
    Информация доверенного начального сертификата может быть предоставлена процедуре обработки пути в форме самоподписанного сертификата. Информации начального сертификата можно доверять, так как она предоставлена процедуре обработки пути некоторой внешней надежной процедурой. Если алгоритм доверенного открытого ключа требует параметров, то эти параметры предоставляются вместе с доверенным открытым ключом.
  5. Initial-policy-mapping-inhibit, который определяет, является ли отображение политики допустимым в сертификационном пути.
  6. Initial-explicit - policy, который определяет, что путь должен быть действительным для, по крайней мере, одной сертификационной политики в user-initial-policy-set.
  7. Initial-any-policy-inhibit, который определяет, должен ли OID anyPolicy обрабатываться, если он включен в сертификат.

Диаграмма потока при обработке сертификационного пути


Рис. 17.1.  Диаграмма потока при обработке сертификационного пути

Инициализация

Данная фаза инициализации устанавливает одиннадцать переменных состояния на основании семи входов:

  1. Valid_policy_tree: дерево политик сертификации с соответствующими необязательными квалификаторами; каждый из листьев дерева является действительной политикой на данной стадии в проверке действительности сертификационного пути. Если действительная политика существует на данной стадии в проверке действительности сертификационного пути, глубина дерева равна числу сертификатов в цепочке, которые обработаны. Если действительная политика не существует на данной стадии в проверке действительности сертификационного пути, дерево устанавливается в NULL. После того как дерево установлено в NULL, обработка политики прекращается.

    Каждый узел в valid_policy_tree включает четыре объекта данных: действительную политику, множество соответствующих квалификаторов политики, множество из одного или более ожидаемых значений политики и индикатор критичности. Если узел имеет глубину х, компоненты узла имеют следующую семантику:

    1. Valid_policy есть единственный OID политики, представляющий действительную политику для пути длиной х.
    2. Qualifier_set является множеством квалификаторов политики, связанных с действительной политикой в сертификате х.
    3. Criticality_indicator определяет, было ли расширение политики в сертификате х маркировано как критичное.
    4. Expected_policy_set содержит один или более OIDs политик, которые должны соответствовать данной политике в сертификате х+1.

      Начальным значением valid_policy_tree является единственный узел с valid_policy anyPolicy, пустым qualifier_set, expected_policy_set с единственным значением anyPolicy и criticality_indicator FALSE. Считается, что данный узел имеет глубину ноль.

      Рис. 17.2 графически представляет начальное состояние valid_policy_tree. Дополнительные рисунки будут использовать данный формат для описания изменений в valid_policy_tree при обработке пути.

  2. Permitted_subtrees: множество корневых имен для каждого типа имени (например, Х.500 уникальные имена, e-mail адреса или IP-адреса), определяющее множество поддеревьев, в которых все имена субъектов в последующих сертификатах в сертификационном пути должны считаться действительными. Данная переменная включает множество для каждого типа имени: начальное значение для множества Distinguished Names является множеством всех уникальных имен; начальное значение множества имен RFC822 является множеством всех RFC822 имен и т.д.
  3. Excluded_subtrees: множество корневых имен для каждого типа имени (например, Х.500 уникальное имя, email адреса или IP-адреса), определяющее множество поддеревьев, в которых имя субъекта в последующих сертификатах в сертификационном пути не может считаться действительным. Данная переменная включает множество для каждого типа имени, и начальное значение для каждого множества является пустым.
  4. Explicit_policy: целое, которое определяет требуемое ненулевое valid_policy_tree. Данное число определяет число несамовыпущенных сертификатов, которые будут обработаны до того, как данное требование должно быть выполнено. Однажды установленная, данная переменная может только уменьшаться, возрастать не может. Это означает, что если сертификат в пути требует ненулевого valid_policy_tree, следующие сертификаты данное требование удалить не могут. Если initial-explicit-policy установлено, то начальное значение есть 0, в противном случае начальное значение есть n+1.

    Начальное значение переменной состояния valid_policy_tree


    Рис. 17.2.  Начальное значение переменной состояния valid_policy_tree

  5. Inhibit_any-policy: целое, которое определяет, можно ли считать идентификатор политики anyPolicy принимаемым. Целое определяет число игнорируемых несамовыпущенных сертификатов, обрабатываемых до OID anyPolicy, если он присутствует в сертификате. Однажды установленная, данная переменная может уменьшаться, но не может возрастать. Это означает, что если сертификат в пути не допускает обработку anyPolicy, последующие сертификаты не могут разрешить принимать данную политику. Если initial-any-policy-inhibit установлено, то начальное значение есть 0, в противном случае начальное значение есть n+1.
  6. Policy_mapping: целое, которое определяет, допустимо ли отображение политики. Целое определяет число несамовыпущенных сертификатов, которые могут быть обработаны до запрещения отображения политики. Однажды установленная, данная переменная может уменьшаться, но не может возрастать. Таким образом, если сертификат в пути указывает, что отображение политики недопустимо, это не может быть перекрыто следующим сертификатом. Если initial-policy-mapping-inhibit установлено, то начальное значение есть 0, в противном случае начальное значение есть n+1.
  7. Working_public_key_algorithm: алгоритм цифровой подписи, используемый для проверки подписи сертификата. Working_public_key_algorithm инициализируется из алгоритма доверенного открытого ключа, указанного в информации доверенного начального сертификата.
  8. Working_public_key: открытый ключ, используемый для проверки подписи сертификата. Working_public_key инициализируется из доверенного открытого ключа, указанного в информации доверенного начального сертификата.
  9. Working_public_key_parameters: параметры, связанные с текущим открытым ключом, который может требоваться для проверки подписи (в зависимости от алгоритма). Переменная working_public_key_parameters инициализируется из параметров доверенного открытого ключа, указанных в информации доверенного начального сертификата.
  10. Working_issuer_name: уникальное имя выпускающего, ожидаемое в следующем сертификате в цепочке. Working_issuer_name инициализируется доверенным выпускающим, указанным в информации доверенного начального сертификата.
  11. Max_path_length: данное целое инициализируется в n, уменьшается для каждого несамовыпущенного сертификата в пути и может быть уменьшено до значения в поле ограничения длины пути с расширением базовых ограничений сертификата СА.

После завершения шагов инициализации выполняются основные шаги обработки, описываемые ниже.

Основная обработка сертификата

Действия по основной обработке сертификата, выполняемые для сертификата i (для всех i в [1..n] ), перечислены ниже.

  1. Проверить основную информацию сертификата. Сертификат должен удовлетворять каждому из следующих условий:
    1. Сертификат подписан working_public_key_algirithm, с использованием working_public_key и working_public_parameters.
    2. Период действительности сертификата включает текущее время.
    3. В текущий момент времени сертификат не отменен и не имеет статуса приостановленного. Это может быть определено получением соответствующего CRL, информации о статусе или внешними механизмами.
    4. Имя выпустившего сертификат есть working_issuer_name.
  2. Если сертификат i является самовыпущенным, и это не последний сертификат в пути, пропустить данный шаг для сертификата i. В противном случае убедиться, что имя субъекта расположено в одном из Permitted_subtrees для уникальных имен Х.500 и что каждое из альтернативных имен в расширении subjectAltName (критичном или некритичном) расположено в одном Permitted_subtrees для данного типа имени.
  3. Если сертификат i является самовыпущенным, и это не последний сертификат в пути, пропустить данный шаг для сертификата i. В противном случае убедиться, что имя субъекта не расположено ни в одном из Excluded_subtrees для уникальных имен Х.500 и что каждое альтернативное имя в расширении subjectAltName (критичное или некритичное) не расположено ни в одном из Excluded_subtrees для данного типа имени.
  4. Если в сертификате имеется расширение политик сертификации и valid_policy_tree не NULL, обработать информацию политики с помощью следующих шагов в указанном порядке:
    1. Для каждой политики 2, не эквивалентной 2, в расширении политик сертификации пусть P-OID обозначает OID политики Р и P-Q обозначает множество квалификаторов для политики Р. Выполняются следующие шаги в указанном порядке:
      1. Если valid_policy_tree включает узел глубины i-1, где P-OID принадлежит expected_policy_set, создать подчиненный узел следующим образом: установить valid_policy в OID-P ; установить qualifier_set в P-Q и установить expected_policy_set в {P-OID}.

        Например, рассмотрим valid_policy_tree с узлом глубины i-1, где expected_policy_set есть {Gold, White}. Предположим, что политики сертификации Gold и Silver присутствуют в расширении политик сертификации сертификата i. Это означает, что политика Gold соответствует, а политика Silver – нет. Данное правило будет создавать подчиненный узел глубины i для политики Gold. Результат показан на рис. 17.3.

      2. Если нет соответствия на шаге (1) и valid_policy_tree включает узел глубины i-1 с действительной политикой anyPolicy, создается подчиненный узел со следующими значениями: установить valid_policy в P-OID ; установить qualifier_set в P-Q и установить expected_policy_set в {P-OID}.

        Например, рассмотрим valid_policy_tree с узлом глубины i-1, где valid_policy есть anyPolicy. Предположим, что политики сертификации Gold и Silver присутствуют в расширении политик сертификации сертификата i. Политика Gold не имеет квалификатора, но политика Silver имеет квалификатор, Q-Silver. Если Gold и Silver не соответствуют (1), данное правило будет создавать два подчиненных узла глубины i, по одному на каждую политику. Результат показан на рис. 17.4.

    2. Если расширение политик сертификации включает политику anyPolicy с квалификатором, установленным в AP-Q и либо (а) inhibit_any_policy есть больше 0, либо (b) i<n и сертификат самовыпущенный, тогда:

      Для каждого узла в valid_policy_tree глубины i-1, для каждого значения в expected_policy_set (включая anyPolicy ), которое не присутствует в подчиненном узле, создается подчиненный узел со следующими значениями: установить valid_policy в значение из expected_policy_set в родительском узле; установить qualifier_set в AP-Q и установить множество expected_policy_set в значение в valid_policy из данного узла.

      Например, рассмотрим valid_policy_tree с узлом глубины i-1, где expected_policy_set есть {Gold, Silver}. Предположим, что anyPolicy присутствует в расширении политик сертификации сертификата i, но Gold и Silver нет. Данное правило будет создавать два подчиненных узла глубины i, по одному для каждой политики. Результат показан на рис. 17.5.

    3. Если существует узел в valid_policy_tree глубины i-1 или менее без каких-либо подчиненных узлов, удалить данный узел. Повторять этот шаг до тех пор, пока не останется узлов глубины i-1 или менее без подчиненных узлов.

      Например, рассмотрим valid_policy_tree, показанную на рис. 17.6. Два узла глубины i-1, которые помечены ‘X’, не имеющие подчиненных узлов, удаляются. Применяя данное правило к результирующему дереву, узел глубины i-2, помеченный как ‘Y’, будет удален. Следующее применение правила не вызовет удаления каких-либо узлов, и данный шаг завершится.

    4. Если расширение политик сертификации было помечено как критичное, установить criticality_indicator во всех узлах глубины i в TRUE. Если расширение политик сертификации было помечено как некритичное, установить criticality_indicator во всех узлах глубины i в FALSE.

    Обработка точного соответствия


    Рис. 17.3.  Обработка точного соответствия

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


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

    Обработка несоответствующих политик, когда расширение политик сертификации специфицирует anyPolicy


    Рис. 17.5.  Обработка несоответствующих политик, когда расширение политик сертификации специфицирует anyPolicy

    Сокращение valid_policy_tree


    Рис. 17.6.  Сокращение valid_policy_tree

  5. Если расширение политик сертификации не присутствует, установить valid_policy_tree в NULL.
  6. Проверить: либо explicit_policy больше нуля, либо valid_policy_tree не эквивалентно NULL ;

Если любой из шагов (1), (2), (3) или (6) не завершается успешно, процедура прекращается, возвращается индикация неудачной проверки и соответствующая причина.

Если i не равно n, продолжается выполнение подготовительных шагов. Если i равно n, выполняются шаги wrap-up.

Подготовка для сертификата i+1

Для подготовки обработки сертификата i+1 выполняются следующие шаги для сертификата i:

  1. Если представлено расширение отображений политики, проверяется, что специальное значение anyPolicy не присутствует в issuerDomainPolicy или subjectDomainPolicy.
  2. Если представлено расширение отображений политики, то для каждого issuerDomainPolicy ID-P в расширении отображений политики:
    1. Если переменная policy_mapping больше 0, для каждого узла в valid_policy_tree глубины i, где ID-P есть valid_policy, установить expected_policy_set и установить значения subjectDomainPolicy, которые определены, эквивалентными ID-P из расширения отображения политик.

      Если нет узлов глубины i в valid_policy_tree, имеющих valid_policy ID-P, но есть узел глубиной i с valid_policy anyPolicy, создать подчиненный узел для узла глубиной i-1, который имеет valid_policy anyPolicy, следующим образом:

      1. Установить valid_policy в ID-P ;
      2. Установить qualifier_set в множество квалификаторов политики anyPolicy в расширении политик сертификации сертификата i ;
      3. Установить criticality_indicator в значение критичности расширения политик сертификации сертификата i ;
      4. Установить expected_policy_set в множество значений subjectDomainPolicy, которое определено эквивалентным ID-P расширения отображений политик.
    2. Если переменная policy_mapping равна 0:
      1. Удалить каждый узел глубины i в valid_policy_tree, где ID-P есть valid_policy.
      2. Если есть узел в valid_policy_tree глубины i-1 или меньше без подчиненных узлов, удалить этот узел. Повторять этот шаг до тех пор, пока не будет узлов глубины i-1 или меньше без подчиненных узлов.
  3. Присвоить working_issuer_name имя субъекта сертификата.
  4. Присвоить working_public_key subjectPublicKey сертификата.
  5. Если поле subjectPublicKeyInfo сертификата содержит поле алгоритма с ненулевыми параметрами, присвоить параметры переменной working_public_key_parameters.

    Если поле subjectPublicKeyInfo сертификата содержит поле алгоритма с ненулевыми параметрами или параметры опущены, сравнить алгоритм subjectPublicKey сертификата с working_public_key_algorithm. Если алгоритм subjectPublicKey и working_public_key_algorithm различные, установить working_public_key_algorithm в null.

  6. Определить алгоритм subjectPublicKey сертификата для переменной working_public_key_algorithm.
  7. Если расширение ограничений имени включено в сертификат, модифицировать переменные состояния permitted_subtrees и excluded_subtrees следующим образом:
    1. Если permittedSubtrees присутствует в сертификате, установить переменную состояния permitted_subtrees в пересечение ее предыдущего значения и значения, указанного в поле расширения. Если permittedSubtrees не включает тип конкретного имени, переменная состояния permitted_subtrees для данного типа имени не изменяется. Например, пересечение msu.ru и cmc.msu.ru есть cmc.msu.ru. А пересечение cmc.msu.ru и mm.msu.ru есть пустое множество.
    2. Если excludedSubtrees присутствует в сертификате, установить переменную состояния excluded_subtrees в объединение ее предыдущего значения и значения, указанного в поле расширения. Если excludedSubtrees не включает тип конкретного имени, переменная состояния excluded_subtrees для данного типа имени не изменяется. Например, объединением пространства имен cmc.msu.ru и mm.msu.ru является пространство обеих имен.
  8. Если имена субъекта и выпускающего не идентичны:
    1. Если explicit_policy не 0, уменьшить explicit_policy на 1.
    2. Если policy_mapping не 0, уменьшить policy_mapping на 1.
    3. Если inhibit_any-policy не 0, уменьшить inhibit_any-policy на 1.
  9. Если расширение ограничений политики включено в сертификат, модифицировать переменные состояния 2 и policy_mapping следующим образом:
    1. Если requireExplicitPolicy присутствует и ее значение меньше, чем explicit_policy, установить explicit_policy в значение requireExplicitPolicy.
    2. Если inhibitPolicyMapping присутствует и ее значение меньше, чем policy_mapping, установить policy_mapping в значение inhibitPolicyMapping.
  10. Если расширение inhibitAnyPolicy присутствует в сертификате и меньше, чем inhibit_any-policy, установить inhibit_any-policy в значение inhibitAnyPolicy.
  11. Убедиться, что сертификат есть сертификат СА (если это не указано в расширении basicConstraints, проверить с помощью внешних средств).
  12. Если сертификат не является самовыпущенным, убедиться, что max_path_length больше нуля и уменьшить max_path_length на 1.
  13. Если pathLengthConstraint присутствует в сертификате и меньше, чем max_path_length, установить max_path_length в значение pathLengthConstraint.
  14. Если расширение использования ключа присутствует, проверить, установлен ли бит keyCertSign.
  15. Определить и обработать все остальные критичные расширения в сертификате. Обработать все другие распознанные некритичные расширения, представленные в сертификате.

Если проверки (1), (10), (11), (12) или (13) не прошли, процедура завершается, возвращается индикация недействительности сертификационного пути и соответствующая причина.

Если (1), (10), (11), (12) и (13) завершены успешно, увеличить i и выполнить базовую обработку сертификата, описанную в предыдущем пункте.

Wrap-up процедура

Для завершения обработки сертификата конечного участника выполнить следующие шаги для сертификата n:

  1. Если сертификат n не является самовыпущенным, и значение explicit_policy не 0, уменьшить explicit_policy на 1.
  2. Если расширение ограничений политики включено в сертификат и requireExplicitPolicy присутствует и имеет значение 0, установить переменную состояния explicit_policy в 0.
  3. Присвоить subjectPublicKey сертификата для working_public_key.
  4. Если поле subjectPublicKeyInfo сертификата содержит поле алгоритма с ненулевыми параметрами, определить параметры как переменную working_public_key_parameters.

    Если поле subjectPublicKeyInfo сертификата содержит поле алгоритма с нулевыми параметрами или параметры опущены, сравнить алгоритм subjectPublicKeyInfo сертификата с working_public_key_algorithm. Если subjectPublicKeyInfo и working_public_key_algorithm различны, установить working_public_key_parameters в null.

  5. Присвоить значение алгоритма из расширения subjectPublicKey сертификата переменной working_public_key_algorithm.
  6. Определить и обработать все другие критичные расширения, представленные в сертификате n. Обработать все другие распознанные некритичные расширения, представленные в сертификате n.
  7. Вычислить пересечение valid_policy_tree и user-initial-policy-set следующим образом:
    1. Если valid_policy_tree есть NULL, пересечение есть NULL.
    2. Если valid_policy_tree есть не NULL и user-initial-policy-set есть any-policy, пересечение есть valid_policy_tree.
    3. Если valid_policy_tree есть не NULL и user-initial-policy-set есть не any-policy, вычислить пересечение valid_policy_tree и user-initial-policy-set следующим образом:
      1. Определить множество узлов политики, у которых родительские узлы имеют valid_policy для anyPolicy. Это есть valid_policy_node_set.
      2. Если valid_policy любого узла в valid_policy_node_set установлено не в user-initial-policy-set и не в anyPolicy, удалить данный узел и все подчиненные узлы.
      3. Если valid_policy_tree включает узел глубины n с valid_policy anyPolicy и user-initial-policy-set есть не any-policy, выполнить следующие шаги:
        1. Установить P-Q в qualifier_set в узле глубины n с valid_policy anyPolicy.
        2. Для каждого P-OID в user-initial-policy-set, который не содержит значение valid_policy узла, создать подчиненный узел, чьим родителем является узел глубины n-1 с valid_policy anyPolicy. Установить значения в подчиненном узле следующим образом: установить valid_policy в P-OID ; установить qualifier_set в P-Q ; копировать criticality_indicator из узла глубины n с valid_policy anyPolicy ; установить expected_policy_set в {P-oid}.
        3. Удалить узел глубины n с valid_policy anyPolicy.
      4. Если существует узел с valid_policy_tree глубины n-1 или менее без подчиненных узлов, удалить этот узел. Повторять данный шаг до тех пор, пока не останется узлов глубины n-1 без подчиненных узлов.

Если либо (1) значение переменной explicit_policy больше нуля, либо (2) valid_policy_tree не есть NULL, то обработка пути выполнена.

Выходные значения

Если обработка пути выполнена, процедура завершается, возвращая индикатор успешного завершения вместе с заключительными значениями valid_policy_tree, working_public_key и working_public_key_algorithm working_public_key_parameters.

Использование алгоритма проверки действительности пути

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

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

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

Действительность CRL

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

Данный алгоритм предполагает, что все необходимые CRLs доступны в локальном кэше. Более того, если при следующем изменении CRL был получен, алгоритм предполагает, что текущий CRL будет получен и помещен в локальный кэш CRL.

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

Входы отмены

Для поддержки обработки отмены алгоритму требуется два входа:

  1. Сертификат: алгоритму требуется серийный номер сертификата и имя выпускающего, чтобы определить, содержится ли сертификат в конкретном CRL. С помощью расширения basicConstraints можно убедиться, что рассматриваемый сертификат связан с СА или с конечным участником. Если расширения cRLDistributionsPoint и freshestCRL присутствуют, алгоритм использует их для определения статуса отмены.
  2. Use-deltas: данный булевый вход определяет, применяются ли дельта CRLs к CRLs.
Инициализация и переменные состояния отмены

Для поддержки обработки CRL алгоритму требуются следующие переменные состояния:

  1. Reasons_mask: данная переменная содержит множество причин отмены, поддерживаемых для обрабатываемых CRLs и дельта CRLs. Допустимыми элементами множества являются следующие значения возможных причин отмены: unspecified, superseded, cessationOfOperation, certificateHold, privilegeWithdrawn и aACompromise. Специальное значение all-reasons используется для обозначения множества всех возможных членов. Данная переменная инициализируется в пустое множество.
  2. Cert_status: данная переменная содержит статус сертификата. Ей может быть присвоено одно из следующих значений: unspecified, keyCompromise, caCompromise, affiliationChanged, superseded, cessationWithdrawn, aACompomise, специальное значение UNREVOKED или специальное значение UNDETERMINED. Данная переменная инициируется в специальное значение UNREVOKED.
  3. Interim_reasons_mask: это множество причин отмены, поддерживаемых CRL или дельта CRL, обрабатываемых в настоящий момент.

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

Обработка CRL

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

Для каждой точки распространения (DP) в расширении сертификата точек распространения CRL, для каждого соответствующего CRL в локальном кэше CRL пока ( (reasons_mask не all-reasons) и (cert_status есть UNREVOKED) ) выполнить следующее:

  1. Изменить локальный кэш CRL получением полного CRL, дельта CRL или обоих, как определено локальной политикой:
    1. Если текущее время больше значения поля CRL next update, выполнить следующие действия:
      1. Если use-deltas установлен и либо сертификат, либо CRL содержат расширение freshest CRL, получить дельта CRL со значением next update, которое больше текущего времени.
      2. Изменить локальный кэш CRL текущим полным CRL, убедиться, что текущее время – меньше значения next update в новом CRL, и продолжить обработку с новым CRL.
    2. Если текущее время меньше значения поля next update и use-deltas установлен, получить текущий дельта CRL, который может быть использован для изменения локального кэшированного полного CRL.
  2. Проверить выпускающего и область полного CRL следующим образом:
    1. Если DP включает cRLIssuer, убедиться, что поле выпускающего в полном CRL соответствует cRLIssuer в DP, и что полный CRL содержит расширение, описывающее точки распространения выпускающего с установленным булевским значением indrectCRL. В противном случае убедиться, что выпускающий CRL соответствует выпускающему сертификат.
    2. Если полный CRL включает расширение CRL, описывающее точки распространения выпускающего (IDP), проверить следующее:
      1. Если присутствует имя точки распространения в расширении CRL IDP и присутствует поле распространения в DP, убедиться, что одно из имен в IDP соответствует одному из имен в DP. Если имя точки распространения представлено в расширении CRL IDP и поле распространения опущено в DP, убедиться, что одно из имен в IDP соответствует одному из имен в поле cRLIssuer DP.
      2. Если булевское onlyContainsUserCerts установлено в расширении CRL IDP, проверить, что сертификат не включает расширение базовых ограничений с установленным булевским сА.
      3. Если булевское onlyContainsCACerts установлено в расширении CRL IDP, проверить, включает ли сертификат расширение базовых ограничений с установленным булевским сА.
      4. Убедиться, что булевское onlyContainsAttributeCerts не установлено.
  3. Если установлен use-deltas, проверить выпускающего и область дельта CRL следующим образом:
    1. Проверить, соответствует ли выпускающий дельта CRL выпускающему полного CRL.
    2. Если полный CRL включает расширение CRL выпускающей точки распространения (IDP), убедиться, что дельта CRL содержит соответствующее расширение CRL IDP. Если в полном CRL расширение CRL IDP опущено, убедиться, что в дельта CRL также опущено расширение CRL IDP.
    3. Убедиться, что расширение идентификатора ключа уполномоченного органа дельта CR L соответствует расширению идентификатора ключа уполномоченного органа полного CRL.
  4. Вычислить interim_reasons_mask для данного CRL следующим образом:
    1. Если расширение CRL выпускающей точки распространения (IDP) присутствует, включает onlySomeReasons и DP включает reasons, то установить interim_reasons_mask в пересечение reasons в DP и onlySomeReasons в расширении CRL IDP.
    2. Если расширение CRL IDP включает бит onlySomeReasons, но в DP опущены reasons, то установить interim_reasons_mask в значение onlySomeReasons в расширении CRL IDP.
    3. Если расширение CRL IDP не присутствует или опущено onlySomeReasons, но DP включает reasons, то установить interim_reasons_mask в значение DP reasons.
    4. Если расширение CRL IDP не присутствует или опущено onlySomeReasons и в DP опущены reasons, то установить interim_reasons_mask в специальное значение all-reasons.
  5. Убедиться, что interim_reasons_mask включает одну или более reasons, которые не включены в reasons_mask.
  6. Получить и проверить действительность сертификационного пути для выпускающего полный CRL. Если расширение использования ключа в сертификате выпускающего CRL присутствует, проверить, установлен ли бит cRLSign.
  7. Проверить действительность подписи в полном CRL, используя открытый ключ, действительность которого проверена на шаге (6).
  8. Если use-deltas установлен, проверить действительность подписи для дельта CRL, используя открытый ключ, действительность которого проверена на шаге (6).
  9. Если use-deltas установлен, выполнить поиск для сертификата в дельта CRL. Если найдена запись, которая соответствует выпускающему сертификат и серийному номеру, как описано выше, установить переменную cert_status в значение, соответствующее указанной причине, следующим образом:
    1. Если расширение записи CRL кода причины присутствует, установить переменную cert_status в значение расширения записи CRL кода причины.
    2. Если расширение записи CRL кода причины не присутствует, установить переменную cert_status в значение unspecified.
  10. Если cert_status есть UNREVOKED, то выполнить поиск для сертификата в полном CRL. Если найдена запись, соответствующая выпускающему сертификат и серийному номеру, установить переменную cert_status в указанную причину, как описано в шаге (9).
  11. Если ( cert_status есть removeFromCRL ), то установить cert_status в UNREVOKED.

Если reasons_mask есть all-resons или cert_status не UNREVOKED, то статус отмены определен, так как возвращается cert_status.

Если статус сертификата не определен, повторить описанный выше процесс с любыми доступными CRLs, не указанными в точке распространения, но созданными выпускающим сертификат. Для обработки таких CRL предполагается DP с обеими причинами, и опущенные поля cRLIssuer, и имя точки распространения выпускающего сертификат. Это означает, что последовательность имен в fullName создается из поля выпускающего сертификат, а также расширения issuerAltName сертификата. Если статус отмены остается неопределенным, то возвращается cert_status UNDETERMINED.

Обсуждение проблем безопасности

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

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

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

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

К сожалению, некоторые наследуемые приложения (например, TLS/SSL) используют единственную пару ключей для подписывания и для управления ключом.

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

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

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

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

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

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

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

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

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

Кроме того, ограничения имени для уникальных имен должны быть установлены идентично представлениям, используемым в поле субъекта или расширении subjectAltName. Если это не так, то ограничения имени, установленные как excludedSubTrees, не будут соответствовать, и недействительные пути будут приниматься, и ограничения имени, выраженные как permittedSubtrees, не будут соответствовать, и действительные пути будут отвергаться. Для того, чтобы избежать приема недействительных путей, САs должны установить ограничения имени для уникальных имен как permittedSubtrees везде, где это возможно.

Лекция 6. Инфраструктура Открытого Ключа (часть 6)

Рассмотрены протоколы PKI управления сертификатом. Определены требования к управлению PKI, рассмотрены операции управления PKI: инициализация конечного участника, начальная регистрация/сертификация, доказательство обладания закрытым ключом, изменение ключа корневого СА, кросс-сертификация, запрос сертификата, изменение ключа. Также приведены соответствующие структуры данных.

Протоколы PKI управления сертификатом

Введение

В этой лекции будут рассматриваться управляющие протоколы PKI.

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

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

Протоколы управления требуются для поддержки on-line взаимодействия между компонентами PKI. Например, протокол управления должен использоваться между СА и системой клиента, с которым связана пара ключей, или между двумя САs, которые выпустили кросс-сертификаты друг для друга.

Все конечные участники требуют локального безопасного доступа к некоторой информации – как минимум к своему собственному имени и закрытому ключу, имени СА, который является доверенным для данного участника, и открытому ключу СА (или дайджесту открытого ключа, если допустима самосертифицированная версия). Может использоваться локальное безопасное хранение и для большего количества информации (например, сертификата конечного участника или информации, относящейся к приложению). Форма хранения также может быть различной – от файлов до неподделываемых криптографических токенов. Такое локальное доверенное хранение мы будем определять как персональное безопасное окружение (Personal Security Environment – PSE) конечного участника.

Хотя форматы PSE находятся вне рассматриваемой предметной области (в частности, они очень зависят от оборудования), здесь мы определим общий формат обмена для PSEs.

Требования к управлению PKI

Рассматриваемые протоколы должны удовлетворять следующим требованиям к управлению PKI.

  1. Управление PKI должно соответствовать стандарту ISO 9594-8 и связанным с ним расширениям сертификата.
  2. Управление PKI должно соответствовать остальным частям стандарта Х.509 v3.
  3. Должна быть возможность регулярного изменения любой пары ключей без влияния на какую-либо другую пару ключей.
  4. Использование сервисов, обеспечивающих конфиденциальность, в протоколах управления PKI должно быть сведено к минимуму, чтобы уменьшить связанные с этим проблемы.
  5. Протоколы управления PKI должны допускать использование различных криптографических алгоритмов, являющихся промышленными стандартами (специально включая только RSA, DSA, MD5, SHA-1). Это означает, что данный СА, RA или конечный участник могут в принципе использовать для своей пары ключей любой набор алгоритмов.
  6. Протоколы управления PKI не должны препятствовать созданию пары ключей как конечным участником, так и RA или СА –ключ может создаваться где-то еще, но в целях управления PKI мы можем предполагать, что генерация ключа происходит в тот момент, когда он впервые передан конечному участнику, RA или СА.
  7. Протоколы управления PKI должны поддерживать опубликование сертификатов, относящихся к конечным участникам, RA или СА.
  8. Протоколы управления PKI должны поддерживать создание CRLs, позволяя сертифицированным конечным участникам посылать запросы на отмену сертификатов – это должно быть организовано так, чтобы невозможно было предпринять DoS-атаку.
  9. Протоколы управления PKI должны использоваться поверх различных транспортных механизмов, включая LDAP, SMTP, HTTP, TCP/IP и FTP.
  10. Конечным уполномоченным органом при создании сертификата является СА; предполагается, что оборудование ни конечного участника, ни RA не может выпустить сертификат – СА может изменить значения полей сертификата или может добавить, удалить или изменить расширения в соответствии со своей политикой функционирования. Например, СА может уменьшить запрошенный период действительности. Заметим, что политика может определять, что СА не должен публиковать или каким-то другим образом распределять сертификат, пока участник не просмотрит и не получит заново созданный сертификат (обычно с использованием PKIConfirm -сообщения).
  11. Должна поддерживаться возможность гибкого изменения от одной нескомпрометированной пары ключей СА к следующей (заметим, что если ключ СА скомпрометирован, переинициализация должна выполняться для всех участников в домене данного СА). Конечный участник, чей PSE содержит новый открытый ключ СА (следуя изменению ключа СА ) должен также иметь возможность проверять сертификаты, с использованием старого открытого ключа. Конечные участники, которые непосредственно доверяют старой паре ключей СА, должны также иметь возможность проверять сертификаты, подписанные с использованием нового закрытого ключа СА. (Обычно это требуется в ситуациях, когда старый открытый ключ СА "встроен" в криптографическое оборудование конечного участника.)
  12. Функции RA в некоторых реализациях или окружениях выполняются самим СА. Протоколы должны быть разработаны так, чтобы конечные участники могли использовать тот же протокол (но, конечно, не тот же ключ!) независимо от существующей взаимосвязи RA или СА.
  13. При запросе конечным участником сертификата, содержащего данное значение открытого ключа, конечный участник должен быть готов продемонстрировать обладание соответствующим значением закрытого ключа. Это можно организовать по-разному, в зависимости от типа алгоритма открытого ключа.

Операции управления PKI

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

  1. Инициализация СА: при инициализации нового СА должны выполняться определенные шаги, такие как создание начальных CRLs, экспорт открытого ключа СА и т.п.
  2. Инициализация конечного участника; данная операция включает импорт открытого ключа корневого СА и запрошенной информации об опциях, поддерживаемых управляющим участником PKI.
  3. Сертификация: множество операций, в результате которых создается новый сертификат.
    1. Начальная регистрация / сертификация – это процесс, в результате которого конечный участник впервые сообщает о себе СА или RA, до того как СА выпустит сертификат или сертификаты для данного конечного участника. Конечным результатом данного процесса (если он успешен) является выпуск сертификата для открытого ключа участника и возврат этого сертификата конечному участнику и/или помещение его в открытый репозиторий. Данный процесс может включать (и обычно включает) несколько "шагов", таких как инициализация оборудования конечного участника. Например, оборудование конечного участника может быть безопасно инициализировано открытым ключом СА, который будет использоваться для проверки действительности сертификационных путей. Более того, конечному участнику обычно бывает необходима инициализация собственной пары ключей.
    2. Изменение пары ключей: каждая пара ключей должна регулярно изменяться (замещаться новой парой), и должен выпускаться новый сертификат.
    3. Изменение сертификата: после того, как срок действительности сертификата истек, он может быть обновлен, если было соответствующее уведомление.
    4. Изменение пары ключей СА: как и в случае конечных участников пара ключей СА должна регулярно изменяться; при этом требуются различные механизмы, позволяющие в течение некоторого времени использовать как новый, так и старый открытые ключи СА.
    5. Запрос кросс-сертификации: один СА запрашивает выпуск кросс-сертификата у другого СА. В данном стандарте определены следующие термины. Кросс-сертификат – это сертификат, в котором subject CA и issuer CA различны, и SubjectPublicKeyInfo содержит ключ проверки (например, сертификат выпущен для пары ключей подписывания subject CA). Когда необходимо более тонкое различие, могут использоваться следующие термины: кросс-сертификат называется междоменным кросс-сертификатом, если subject и issuer CA принадлежат различным административным доменам; в противном случае он называется внутридоменным кросс-сертификатом.

      Замечание 1. Во многих окружениях термин "кросс-сертификат", если не будет дальнейшего уточнения, обычно считается синонимом "междоменного кросс-сертификата ".

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

    6. Изменение кросс-сертификата: происходит аналогично обычному изменению сертификата, но операция относится к кросс-сертификату.
  4. Операции опубликования сертификата и/или CRL: результатом некоторых операций управления PKI является опубликование сертификатов или CRLs:
    1. Опубликование сертификата: способы включают использование определенных сообщений или применение конкретного протокола (LDAP, например).
    2. Опубликование CRL аналогично опубликованию сертификата.
  5. Операции восстановления: определенные операции управления PKI используются при потере конечным участником своего PSE.
    1. Восстановление пары ключей: в качестве дополнительной возможности материал ключа пользователя (например, закрытый ключ пользователя, применяемый для шифрования) может быть сохранен СА, RA или системой архивирования, связанной с СА или RA. Если данный материал ключа необходимо восстановить (например, был забыт пароль или потерян файл ключей), может потребоваться протокол для поддержки такого восстановления.
  6. Операции отмены: результатом определенных операций PKI является создание новых записей CRL и/или новых CRLs.
    1. Запрос отмены: авторизованная личность оповещает СА об исключительной ситуации, требующей отмены сертификата.
  7. PSE операции: хотя определение операций PSE (например, пересылка PSE, цепочка PIN и т.д.) находится вне данной предметной области, определено специальное сообщение, которое может служить основой для таких операций.

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

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

Инициализация конечного участника

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

Начальная регистрация/сертификация

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

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

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

Рассмотрим классификацию схем начальной регистрации / сертификации.

Используемые классификации схем
Инициализация регистрации/сертификации

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

Начальная аутентификация сообщения конечного участника

On-line сообщения, созданные конечным участником, запрашивающим сертификат, могут быть как аутентифицированы, так и нет. Требованием является аутентификация подлинности любых сообщений от конечного участника к PKI (CA/RA).

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

Мы можем таким образом классифицировать схемы начальной регистрации / сертификации в соответствии с тем, аутентифицированы on-line сообщения EE к PKI или нет.

Замечание 1: мы не рассматриваем аутентификацию сообщений PKI к EE, т.к. она требуется ВСЕГДА. В любом случае открытый ключ СА может быть инсталлирован в оборудовании конечного участника или аутентификация может быть основана на ключе начальной аутентификации.

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

Расположение генератора ключа

Будем считать, что "генерация ключа" происходит всякий раз, когда открытый или закрытый компоненты ключа впервые появляется в PKIMessage. Заметим, что это не препятствует централизованному сервису генерации ключа – реальная пара ключа может быть создана где-то еще и передана конечному участнику, RA или СА с использованием (собственного или стандартного) протокола запроса/ответа генератора ключа.

Существует три возможных размещения "генератора ключа": конечный участник, RA или СА.

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

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

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

Это дает две возможности: с подтверждением или без.

Обязательные схемы

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

Централизованная схема

В терминах приведенной выше классификации данная схема является самой простой:

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

Базовая схема аутентификации

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

В терминах потока сообщений базовая схема аутентификации будет следующей (см. рис.18.1).

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

Доказательство обладания (Proof of Possession – РОР) закрытым ключом

Для того чтобы предотвратить основные атаки и позволить CA/RA выполнить проверку соответствия конечного участника и пары ключей, определены операции управления PKI, которые дают конечному участнику возможность доказать, что он обладает закрытым ключом (и может использовать его), соответствующим открытому ключу, для которого запрошен сертификат. CA/RA самостоятельно выбирает, как выполнить РОР (например, с использованием внешних механизмов или специальных управляющих сообщений). Однако требуется, чтобы CAs/RАs выполняли РОР определенным способом, так как сейчас существует много не-PKI протоколов (в частности, протоколы e-mail), которые явно не проверяют связь между конечным участником и закрытым ключом. До тех пор, пока протоколы, которые выполняют проверку связывания (для пары ключей подписывания, шифрования и согласования ключа), используются не везде, предполагается, что такое связывание проверяется только CA/RA. Таким образом, если связывание не проверяется CA/RA, то сертификаты являются менее надежными.

Базовая схема аутентификации


Рис. 18.1.  Базовая схема аутентификации

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

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

Ключи подписывания

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

Ключи шифрования

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

Прямой метод состоит в том, что CA/RA создает случайный вызов, на который требуется немедленный ответ ЕЕ.

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

Рекомендуется задействовать косвенный метод, т.к. это не требует посылки дополнительных сообщений (т.е. доказательство может быть продемонстрировано с использованием трех сообщений {запрос, ответ, подтверждение}).

Ключи согласования ключа

Для ключей согласования ключа конечный участник и CA/RA должны установить разделяемый секретный ключ, чтобы доказать, что конечный участник обладает закрытым ключом.

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

Изменение ключа корневого СА

Данное обсуждение касается только САs, которые являются корневыми СА для некоторого конечного участника.

Основа описанной здесь процедуры состоит в том, что СА защищает свой новый открытый ключ, используя предыдущий закрытый ключ, и наоборот. Таким образом, если СА изменяет свою пару ключей, он должен создать два дополнительных значения атрибута сертификата cACertificate, если сертификаты доступны с использованием Х.500 директории (всего четыре сертификата: OldWithOld; OldWithNew; NewWithOld; NewWithNew).

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

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

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

Замечание 2: данная схема заставляет ЕЕ получать (внешними способами) новый открытый ключ СА по истечении срока действия последнего сертификата, с использованием которого был подписан старый закрытый ключ СА. Требуют ли этого операции изменения ключа и/или сертификата, зависит от оборудования ЕЕ.

Действия оператора СА

Для изменения ключа СА оператор СА должен сделать следующее:

  1. Создать новую пару ключей;
  2. Создать сертификат, содержащий старый открытый ключ, подписанный новым закрытым ключом ("старый с новым" сертификат);
  3. Создать сертификат, содержащий новый открытый ключ СА, подписанный старым закрытым ключом ("новый со старым" сертификат);
  4. Создать сертификат, содержащий новый открытый ключ СА, подписанный новым закрытым ключом ("новый с новым" сертификат).
  5. Опубликовать эти новые сертификаты в директории и/или другими способами (возможно, с использованием CAKeyUpdAnn -сообщения);
  6. Экспортировать новый открытый ключ СА так, чтобы конечные участники могли получить его, используя "внешний" механизм (если нужно).

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

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

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

Проверка сертификатов

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

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

Случай 1:

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

Случай 3:

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

Случай 5:

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

Случай 7:

В этом случае оператор СА не изменил директорию, и проверка не проходит
Сертификат подписавшего защищен с использованием старого открытого ключа

Случай 2:

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

Случай 4:

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

Случай 6:

Проверяющий думает, что это ситуация случая 2 и хочет получить доступ к директории; однако проверка не проходит

Случай 8:

Хотя оператор СА не изменил директорию, проверяющий может проверить сертификат непосредственно – случай аналогичен случаю 4
Проверка в случаях 1, 4, 5 и 8

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

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

Проверка в случае 2

В случае 2 проверяющий должен получить доступ к старому открытому ключу СА. Проверяющий делает следующее:

  1. Смотрит атрибут caCertificate в директории и получает OldWithNew- сертификат (определяемый на основе периода действительности);
  2. Проверяет, все ли в порядке, используя новый ключ СА (который он имеет локально);
  3. Если все нормально, проверяет сертификат подписавшего, используя старый открытый ключ СА.

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

Проверка в случае 3

В случае 3 проверяющий должен получить доступ к новому открытому ключу СА. Проверяющий делает следующее:

  1. Смотрит атрибут саCertificate в директории и получает NewWithOld- сертификат (определяемый на основе периода действительности);
  2. Проверяет, корректен ли он, используя старый открытый ключ СА (который хранится локально);
  3. В случае корректности проверяет сертификат подписавшего, используя новый открытый ключ СА.

Случай 3 имеет место, когда оператор СА выпускает сертификат проверяющего, затем изменяет ключ и выпускает сертификат подписавшего; таким образом, это вполне типичный случай.

Неудачная проверка в случае 6

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

Заметим, что невозможность проверки является ошибкой оператора СА.

Неудачная проверка в случае 7

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

Заметим, что невозможность проверки также является ошибкой оператора.

Отмена – изменение ключа СА

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

Анализ возможных альтернатив аналогичен проверке сертификата.

Кросс-сертификация

Запрашивающий СА является СА, который станет субъектом кросс-сертификата ; отвечающий СА станет выпускающим (issuer) кросс-сертификата.

Запрашивающий СА должен быть "up and running" до начала выполнения операции кросс-сертификации.

Односторонняя схема запроса-ответа

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

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

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

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

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

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

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

При получении PKIConfirm -сообщения отвечающий СА проверяет случайные числа и действительность МАС.

Замечания:

  1. Ccr сообщение должно содержать "завершенный" запрос сертификата, что означает, что все поля (включая расширения BasicConstraints ) должны быть указаны запрашивающим СА.
  2. Срр сообщение должно содержать сертификат проверки отвечающего СА – если он присутствует, то запрашивающий СА должен затем проверить данный сертификат (например, с помощью внешнего механизма).
Запрос сертификата

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

Изменение ключа

Когда период действительности пары ключей истекает, соответствующий конечный участник может запросить изменение ключа – это означает, что он может сделать запрос на создание СА нового сертификата для новой пары ключей. Запрос может быть сделан с использованием сообщения запроса изменения ключа ( kur ). Если конечный участник уже имеет пару ключей подписывания (с соответствующим сертификатом проверки), то данное сообщение обычно бывает защищено цифровой подписью участника. СА возвращает новый сертификат (если запрос успешен) в сообщении ответа изменения ключа ( kup ), которое синтаксически идентично CertRepMessage.

Структуры данных

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

Полное сообщение PKI

Все сообщения, используемые для управления PKI, имеют следующую структуру:

PKIMessage ::= SEQUENCE {
  header         PKIHeader,
  body           PKIBody,
  protection [0] PKIProtection OPTIONAL,
  extraCerts [1] SEQUENCE SIZE (1..MAX) OF
                 Certificate OPTIONAL
}

PKIHeader содержит информацию, которая является общей для многих сообщений PKI.

PKIBody содержит информацию, специфичную для сообщения.

PKIProtection, если используется, содержит биты, которые защищают сообщение PKI.

Поле extraCerts может содержать сертификаты, которые могут использоваться получателем. Например, оно может применяться СА или RA для предоставления конечному участнику сертификатов, которые он должен проверить с использованием собственного нового сертификата (если, например, СА, который выпустил сертификат конечного участника, не является для него корневым СА). Заметим, что данное поле не обязательно должно содержать сертификационный путь – получатель может отсортировать, выбрать или каким-то другим образом обработать дополнительные сертификаты, чтобы иметь возможность использовать их.

Заголовок сообщения PKI

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

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

PKIHeader ::= SEQUENCE {
  pvno   INTEGER   { ietf-version2 (1) },
  sender GeneralName,  
  --  идентификация отправителя

  recipient   GeneralName,  
  --  идентификация ожидаемого получателя

  messageTime  [0] GeneralizedTime OPTIONAL,
  --  время создания данного сообщения 
  --  (используется, если отправитель 
  --  считает, что транспорт должен быть 
  --  "соответствующим", например, что для 
  --  получателя важно время)

  protectionAlg [1] AlgorithmIdentifier 
                    OPTIONAL,
  --  алгоритм, используемый для вычисления
  --  защищенных битов 

  senderKID    [2]  KeyIdentifier OPTIONAL,
  recipKID     [3]  KeyIdentifier OPTIONAL, 
  --  идентифицирует конкретные ключи, 
  --  используемые для защиты 

  transactionID [4] OCTET STRING OPTIONAL,
  --  идентифицирует транзакцию; должно быть
  --  одним и тем же соответственно в 
  --  сообщениях запроса, ответа и 
  --  подтверждения

  senderNonce   [5] OCTET STRING  OPTIONAL,
  recipNonce    [6] OCTET STRING  OPTIONAL, 
  --  nonces, используемые для защиты от 
  --  replay-атак, senderNonce вставляется
  --  создателем данного сообщения; 
  --  recipNonce является nonce, предвари-
  --  тельно вставленным в соответствующее
  --  сообщение ожидаемым получателем 
  --  данного сообщения 

  freeText    [7] PKIFreeText  OPTIONAL, 
  --  может быть использовано для указания 
  --  контекстно-зависимых инструкций

  generalInfo [8] SEQUENCE SIZE (1..MAX) OF
                 InfoTypeAndValue  OPTIONAL 
  --  может быть использовано для указания 
  --  контекстно-зависимой информации
}
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF 
                UTF8String
  --  текст представлен как UTF-8 String 
  --  (замечание: каждый UTF8String должен 
  --  включать RFC 1766 language tag для
  --  указания языка, на котором 
  --  представлен текст)

Поле pvno для данной версии спецификации фиксировано.

Поле sender содержит имя отправителя PKIMessage.

Данное имя (в сочетании с senderKID, если оно используется) должно применяться для проверки защиты сообщения. Если об отправителе ничего не известно (например, в сообщении начальной регистрации, когда конечный участник может не знать собственный DN, e-mail, IP адрес и т.д.), то поле sender должно содержать значение NULL ; это означает, что последовательность RDN имеет нулевую длину. В таком случае поле senderKID должно содержать идентификатор (например, номер), указывающий получателю на информацию о соответствующем разделяемом секрете, который используется для проверки сообщения.

Поле recipient содержит имя получателя PKIMessage. Данное имя (в сочетании с recipKID, если он используется) должно применяться для проверки защиты сообщения.

Поле protectionAlg указывает алгоритм, используемый для защиты сообщения. Если биты защиты не применяются (заметим, что PKIProtection является OPTIONAL ), то данное поле должно быть опущено; если биты защиты применяются, то данное поле также должно использоваться.

SenderKID и recipKID используются для указания того, какие ключи были задействованы для защиты сообщения ( recipKID обычно требуется только в том случае, если для защиты сообщения используются ключи Диффи-Хеллмана).

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

Поля senderNonce и recipNonce защищают PKIMessage от replay-атак.

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

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

Поле generalInfo может применяться для передачи получателю дополнительных данных для машинной обработки.

Тело сообщения PKI
PKIBody ::= CHOICE {   
  --  элементы, специфичные для конкретного сообщения
    ir [0] CertReqMessages,             --  Initialization Request
    ip [1] CertRepMessage,              --  Initialization Response
    cr [2] CertReqMessages,             --  Certification Request
    cp [3] CertRepMessage,              --  Certification Response
    p10cr  [4]  CertificationRequest,   --  PKCS #10 
                                        --  Certification Request
    popdecc [5] POPODecKeyChallContent, --  pop Challenge
    popdecr [6] POPODecKeyRespContent,  --  pop Response
    kur [7]  CertReqMessages,           --  Key Update Request
    kup [8]  CertRepMessage,            --  Key Update Response
    krr [9]  CertReqMessages,           --  Key Recovery Request
    krp [10]  KeyRecRepContent,         --  Key Recovery Response
    rr  [11]  RevReqContent,            --  Revocation Request
    rp  [12]  RevRepContent,            --  Revocation Response
    ccr [13]  CertReqMessages,          --  Cross-Cert. Request
    ccp [14]  CertRepMessage,           --  Cross-Cert. Response
    ckuann [15]  CAKeyUpdAnnContent,    --  CA Key Update Ann.
    cann   [16]  CertAnnContent,        --  Certificate Ann.
    rann   [17]  RevAnnContent,         --  Revocation Ann.
    crlann [18]  CRLAnnContent,         --  CRL Announcement
    conf   [19]  PKIConfirmContent,     --  Confirmation
    nested [20]  NestedMessageContent,  --  Nested Message
    genm   [21]  GenMsgContent,         --  General Message
    genp   [22]  GenRepContent,         --  General Response
    error  [23]  ErrorMsgContent        --  Error Message
}
Листинг 18.1. Синтаксис тела сообщения PKI (html, txt)

Конкретные типы будут описаны ниже.

Синтаксис CertReqMessage

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

CertReqMessages ::= SEQUENCE SIZE
  (1..MAX) OF CertReqMsg
CertReqMsg ::= SEQUENCE {
  certReq   CertRequest,
  pop       ProofOfPossession  OPTIONAL,
  -- содержание зависит от типа ключа 
  regInfo   SEQUENCE SIZE(1..MAX) of 
      AttributeTypeAndValue OPTIONAL }

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

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

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

Защита сообщения PKI

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

При применении защиты используется следующая структура:

PKIProtection ::= BIT STRING

Входом для вычисления PKIProtection является DER-представление следующей структуры данных:

ProtectedPart ::=   SEQUENCE {
  header  PKIHeader,
  body    PKIBody
}

Могут быть ситуации, когда PKIProtection BIT STRING сознательно не используется для защиты сообщения (т.е. это OPTIONAL поле опущено), т.к. применяется другая, внешняя по отношению к PKI, защита. Это явно допускается. Примерами такой внешней защиты являются PKCS #7 и Security Multiparts (RFC 1847) инкапсуляция PKIMessage (или просто PKIBody, если безопасность информации PKIHeader обеспечивается посредством внешних механизмов). Следует заметить, однако, что многие такие внешние механизмы требуют, чтобы конечный участник уже имел сертификат открытого ключа и/или DN и/или другую аналогичную относящуюся к инфраструктуре информацию. Таким образом, это может не соответствовать начальной регистрации, восстановлению ключа или другому процессу, характеризующемуся "начальной загрузкой". Для таких случаев может быть необходимо, чтобы использовались PKIProtection -параметры. В будущем, если внешние механизмы будут модифицированы таким образом, чтобы соответствовать сценариям начальной загрузки, использование PKIProtection станет более редким или вовсе необязательным.

В зависимости от условий биты PKIProtection могут содержать МАС или подпись. Возможны следующие случаи:

  1. Разделяемая секретная информация

    В данном случае отправитель и получатель разделяют секретную информацию (установленную внешними способами или полученную из предыдущих операций PKI). PKIProtection будет содержать значение МАС и protectionAlg будет следующим:

    PasswordBasedMac ::=
      OBJECT IDENTIFIER 
        --  {1 2 840 113533 7 66 13}
    PBMParameter ::= SEQUENCE {
      salt  OCTET STRING,
      owf   AlgorithmIdentifier,
        --  AlgId для односторонней
        --  функции OWF 
        --  (рекомендуется SHA-1)
      iterationCount     INTEGER,
        --  количество применений OWF 
      mac     AlgorithmIdentifier
        --  AlgId MAC (например,
        --  DES-MAC, Triple-DES-MAC, 
        --  или HMAC)
    }

    В указанном выше protectionAlg значение salt присоединяется к разделяемому секрету. Затем OWF применяется iterationCount раз, где секрет с добавлением salt является входом в первую итерацию и вход каждой итерации является выходом предыдущей. Выход последней итерации (называемый BASEKEY ) используется для создания симметричного ключа. Если алгоритм МАС требует K -битного ключа и K < H, то используются младшие K бит BASEKEY. Если K > H, то весь BASEKEY используется для младших Н битов ключа, OWF ("2" || BASEKEY ) применяется для следующих Н битов ключа и т.д.

  2. Пара ключей DH

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

    PKIProtection будет содержать значение МАС с ключом, полученным из симметричного ключа и protectionAlg следующим образом:

    DHBasedMac ::= OBJECT IDENTIFIER 
        --  {1 2 840 113533 7 66 30}
    DHBMParameter ::= SEQUENCE {
      owf     AlgorithmIdentifier,
        --   AlgId для односторонней
        --   функции (OWF) 
        --   (рекомендуется SHA-1)
      mac       AlgorithmIdentifier
        --   the MAC AlgId (например,
        --   DES-MAC, 
        --   Triple-DES-MAC или НМАС)
    }

    protectionAlg OWF применяется к результату вычислений DH. Выход OWF (называемый BASEKEY ) используется для формирования симметричного ключа. Если алгоритм МАС требует K -битного ключа и K < H, то используются K младших битов BASEKEY. Если K > H, то используется весь BASEKEY для младших Н битов ключа, OWF ("1" || BASEKEY) применяется для следующих младших Н битов ключа и т.д.

  3. Подпись

    Если отправитель имеет пару ключей подписывания, он может просто подписать PKI-сообщение. PKIProtection будет содержать значение подписи, protectionAlg будет определяться значением AlgorithnIdentifier.

  4. Многократная защита

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

    NestedMessageContent ::= PKIMessage
Общие структуры данных

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

Содержимое запрашиваемого сертификата

Различные управляющие сообщения PKI требуют, чтобы инициатор сообщения указал некоторые поля, которые должны присутствовать в сертификате. Структура CertTemplate позволяет конечному участнику или RA указать как можно больше того, что должен содержать сертификат. CertTemplate аналогична Certificate, но все поля являются необязательными.

Заметим, что даже если инициатор полностью указал требуемое содержимое сертификата, СА имеет право модифицировать поля в сертификате, который он реально издает. Если модифицированный сертификат для запрашивающего неприемлем, можно задержать Confirmation -сообщение или послать Error -сообщение (с PKIStatus "rejection" ).

Зашифрованные значения

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

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

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

Коды статуса и информация о неудаче для PKI-сообщений

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

PKIStatus ::= INTEGER {
  Granted          (0),
      -- получено то, что запрашивалось
  grantedWithMods  (1),
      -- получено что-то подобное, что запрашивалось; 
	  -- запрашивающий несет ответственность за 
      -- установленные отличия 
  rejection        (2),
      -- не получено то, что запрашивалось,
	  -- более подробная информация в сообщении 
  waiting          (3),
      -- запрос не обработан,
      -- следует запросить позднее 
  revocationWarning  (4),
      -- данное сообщение содержит предупреждение, 
	  -- что скоро будет отмена 
  revocationNotification  (5),
      -- уведомление, что произошла отмена
  keyUpdateWarning   (6)
      -- изменение уже выполнено для oldCertId, 
      -- указанного в сообщении запроса изменения ключа
}
Листинг 18.2. Коды статуса PKI-сообщений (html, txt)

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

PKIFailureInfo ::= BIT STRING {
    -- причин неудачи может быть много
    -- при необходимости в будущем могут 
	-- быть добавлены другие коды причин.
  badAlg  (0),
    -- нераспознанный или неподдерживаемый
    -- Идентификатор Алгоритма 
  badMessageCheck  (1),
    -- сбой в процессе проверки целостности
	-- (например, подпись не верифицирована)
  badRequest       (2),
    -- транзакция не разрешена или не поддерживается 
  badTime          (3),
    -- messageTime недостаточно точно
    -- соответствует системному времени,
	-- как определено локальной политикой 
  badCertId        (4),
    -- сертификат не может быть найден в
	-- соответствии с предоставленным критерием 
  badDataFormat    (5),
    -- переданные данные имеют
    -- неправильный формат 
  wrongAuthority   (6),
    -- уполномоченный орган, указанный 
	-- в запросе, отличается от того, 
	-- который определен в токене ответа
  incorrectData    (7),
    -- данные из запроса являются некорректными 
    -- (используется для сервисов нотариуса)
  missingTimeStamp (8),
    -- когда timestamp опущена, но
    -- должна присутствовать 
    -- (в соответствии с политикой) 
  badPOP           (9)
    -- упал РОР 
}
PKIStatusInfo ::= SEQUENCE {
  status PKIStatus,
  statusString PKIFreeText OPTIONAL,
  failInfo PKIFailureInfo OPTIONAL
}
Листинг 18.3. Синтаксис для предоставления подробной информации о причинах неудачи PKI-сообщений (html, txt)
Идентификация сертификата

Для идентификации конкретных сертификатов используется структура данных CertId.

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

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

OOBCert ::= Certificate

Поля в данном сертификате имеют следующие ограничения:

OOBCertHash ::= SEQUENCE {
  hashAlg [0] AlgorithmIdentifier
    OPTIONAL,
  certId [1] CertId OPTIONAL,
  hashVal BIT STRING
    -- hashVal вычисляется для
    -- самоподписанного 
    -- сертификата с идентификатором
    -- certID.}

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

Опции архивации

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

Публикуемая информация

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

Структуры РОР

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

POPOSigningKeyInput ::= SEQUENCE {
  authInfo     CHOICE {
    sender        [0] GeneralName,
    -- из PKIHeader (используется только в
	-- том случае, если аутентифицированная
    -- идентификация установлена 
    -- отправителем (например, DN из ранее
	-- выпущенного и действительного 
	-- в данный момент сертификата))
    publicKeyMAC  [1] PKMACValue
    -- используется, если в настоящий момент
	-- не существует аутентифицированного 
	-- GeneralName для отправителя; 
	-- publicKeyMAC содержит основанный на 
    -- пароле MAC (используя protectionAlg 
	-- AlgId из PKIHeader) для
    -- DER-представления publicKey
  },
  publicKey     SubjectPublicKeyInfo
    -- из CertTemplate
}

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

  1. Включением закрытого ключа (шифрования) в CertRequest (в управляющей структуре PKIArchiveOptions ).
  2. Тем, что СА возвращает не сертификат, а зашифрованный сертификат (например, сертификат зашифрован случайно созданным симметричным ключом и симметричный ключ зашифрован открытым ключом, для которого выпущен запрошенный сертификат) – это "непрямой" метод, описанный ранее. Конечный участник доказывает знание закрытого ключа дешифрования, посылая МАС сообщения PKIConirm, используя ключ, полученный из данного симметричного ключа. Заметим, что если более одного CertReqMsg включено в PKIMessage, то СА использует разные симметричные ключи для каждого CertReqMsg, и МАС задействует ключ, полученный из конкатенации всех этих ключей. Процедура вычисления МАС использует PasswordBasedMacAlgId, определенный выше.
  3. Тем, что конечный участник обязан иметь что-то, что он указывает в протоколе вызов-ответ (используя сообщения POPODecKeyChall и POPODecKeyResp, см ниже) между CertReqMessages и CertRepMessages. Это "прямой" метод, как он определен выше. Данный метод обычно используется в окружении, в котором RA проверяет POP и затем осуществляет запрос сертификата у СА от имени конечного участника. В данном сценарии СА доверяет RA выполнять POP до того, как RA запросит сертификат для конечного участника. Полный протокол выглядит следующим образом (заметим, что req’ не обязательно должно инкапсулировать req в качестве вложенного сообщения):

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

Если запрос сертификата выполнен для пары ключей согласования ключа (Key Agreement Key – KAK), то POP может использовать любой из трех способов, описанных выше для пары ключей шифрования с учетом следующего:

  1. Сертификат зашифрован с помощью симметричного ключа, полученного из закрытого KAK СА и открытого ключа, для которого выполнен запрос сертификата.
  2. Вместо Challenge используется PreferredSymmAlg и симметричный ключ, полученный из закрытого KAK СА и открытого ключа, для которого выполнен запрос сертификата. В качестве альтернативы POP может использовать структуру POPOSigningKey, где поле alg есть DHBasedMAC и поле подписи есть МАС, в качестве четвертой альтернативы для демонстрации POP, если СА уже имеет D-H сертификат, который известен ЕЕ.

Сообщения вызова-ответа для доказательства обладания закрытым ключом шифрования определены следующим образом. Заметим, что обмен вызов-ответ связан с сообщением запроса сертификата (и тем самым с сообщениями ответа сертификата и подтверждением) с помощью nonces, используемых в PKIHeader, и защитой (МАС или подписыванием), примененной к PKIMessage.

POPODecKeyChallContent ::= SEQUENCE OF Challenge
    -- один Challenge на запрос сертификата ключа 
    -- шифрования (в той же последовательности, что и 
    -- другие запросы, появляющиеся в CertReqMessages).
Challenge ::= SEQUENCE {
  owf       AlgorithmIdentifier  OPTIONAL,
    -- должен присутствовать в первом Challenge; может 
    -- быть опущен в любом следующем Challenge в 
    -- POPODecKeyChallContent (если опущен, то owf 
    -- используется в немедленно создаваемом Challenge).
  witness   OCTET STRING,
    -- результат применения односторонней функции (owf) 
    -- к случайно созданному целому A. Заметим, что для 
    -- каждого Challenge должны использоваться различные 
    -- целые.
  challenge   OCTET STRING
    -- шифрование (с использованием открытого ключа, для 
    -- которого выполнен запрос сертификата) Rand, где 
    -- Rand специфицирован как 
    --   Rand ::= SEQUENCE {
    --   int      INTEGER,
    --   – случайно созданное целое A (определено выше)
    --   sender   GeneralName
    --   – имя отправителя (как определено в PKIHeader)
    --   }
  }
POPODecKeyRespContent ::= SEQUENCE OF INTEGER
    -- один INTEGER на каждый запрос сертификата для 
    -- ключа шифрования (в порядке появления этих 
    -- запросов в CertReqMessages). Восстановленный 
    -- INTEGER A возвращается отправителю в 
    -- соответствующем Challenge.
Листинг 18.4. Сообщения вызова-ответа для доказательства обладания закрытым ключом (html, txt)

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


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

Структуры данных, используемые для каждой операции
Запрос инициализации

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

Ответ инициализации

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

Далее приводится синтаксис CertRepMessage. Заметим, что если защитой сообщения PKI является "разделяемая секретная информация", то любой сертификат, передаваемый в поле caPubs, может быть непосредственно доверенным как сертификат корневого СА инициатора.

Запрос регистрации/сертификации

Сообщение запроса регистрации / сертификации содержит в PKIBody структуру данных CertReqMessages, которая специфицирует запрошенные сертификаты. Считается, что данное сообщение используется для существующих в PKI участников, которые хотят получить дополнительные сертификаты.

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

Ответ регистрации/сертификации

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

CertRepMessage ::= SEQUENCE {
  CaPubs [1] SEQUENCE SIZE (1..MAX)
    OF Certificate OPTIONAL,
  Response  SEQUENCE OF CertResponse }
CertResponse ::= SEQUENCE {
  CertReqId  INTEGER,
    -- для установления соответствия между
	-- ответом и запросом – 1 используется,
    -- если certReqId в соответствующем 
	-- запросе не указан)
  status  PKIStatusInfo,
  certifiedKeyPair CertifiedKeyPair
    OPTIONAL,
  rspInfo OCTET STRING OPTIONAL
    -- аналогично id-regInfo-asciiPairs
    -- OCTET STRING, 
    -- определенной для regInfo
    -- в CertReqMsg 
}
CertifiedKeyPair ::= SEQUENCE {
  certOrEncCert CertOrEncCert,
  privateKey [0] EncryptedValue OPTIONAL,
  publicationInfo [1] PKIPublicationInfo
    OPTIONAL
}
CertOrEncCert ::= CHOICE {
  certificate     [0] Certificate,
  encryptedCert   [1] EncryptedValue
}

Только одно из полей failInfoPKIStatusInfo ) и certificateCertifiedKeyPair ) может быть представлено в каждом CertResponse (в зависимости от статуса). Для некоторых значений статуса (например, waiting ) ни одно из дополнительных полей присутствовать не может.

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

Содержимое запроса изменения ключа

Для запросов изменения ключа используется синтаксис CertReqMessages. Обычно SubjectPublicKeyInfo, KeyId и Validity являются шаблонными полями, которые заполняются для каждого изменяемого ключа. Считается, что данное сообщение применяется для запроса изменения существующих (не отмененных и не истекших) сертификатов.

Содержимое ответа изменения ключа

Для ответов об изменении ключа используется синтаксис CertRepMessage. Ответ идентичен ответу инициализации.

Синтаксис CertRepMessage описан выше.

Содержимое запроса восстановления ключа

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

Содержимое ответа восстановления ключа

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

KeyRecRepContent ::= SEQUENCE { status
  PKIStatusInfo,
  newSigCert [0] Certificate OPTIONAL,
  caCerts [1] SEQUENCE SIZE (1..MAX) OF 
      Certificate OPTIONAL,
  keyPairHist [2] SEQUENCE SIZE (1..MAX) OF
      CertifiedKeyPair OPTIONAL
}
Содержимое запроса отмены

При запросе отмены сертификата (или нескольких сертификатов) используется следующая структура данных. Имя запрашивающего присутствует в PKIHeader -структуре.

RevReqContent ::= SEQUENCE OF RevDetails
  RevDetails ::= SEQUENCE {
  certDetails     CertTemplate,
  -- позволяет запрашивающему указать
  -- как можно больше 
  -- сведений о сертификате,
  -- для которого требуется отмена 
  -- (например, для случаев, когда
  -- serialNumber недоступен)
  revocationReason ReasonFlags OPTIONAL,
  -- причина запроса отмены 
  badSinceDate GeneralizedTime OPTIONAL,
  -- указывает максимальные знания
  -- отправителя 
  crlEntryDetails Extensions OPTIONAL
  -- запрошенные crlEntryExtensions
}
Содержимое ответа отмены

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

RevRepContent ::= SEQUENCE {
  status SEQUENCE SIZE (1..MAX)
    OF PKIStatusInfo,
    -- в той же последовательности,
    -- как было послано в RevReqContent
  revCerts [0] SEQUENCE SIZE
    (1..MAX) OF CertId OPTIONAL,
    -- Ids, для которых запрошена отмена
    -- (тот же порядок, что и status)
  crls [1] SEQUENCE SIZE (1..MAX)
    OF CertificateList OPTIONAL
    -- результирующие CRLs (может
    -- быть более одного)
}
Содержимое запроса кросс-сертификации

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

Содержимое ответа кросс-сертификации

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

Содержимое оповещения об изменении ключа СА

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

CAKeyUpdAnnContent ::= SEQUENCE {
  OldWithNew Certificate, 
    -- старый pub, подписанный новым priv
  NewWithOld Certificate, 
    -- новый pub, подписанный старым priv
  NewWithNew Certificate 
    -- новый pub, подписанный новым priv
}
Оповещение сертификата

Данная структура может использоваться для оповещения о существовании сертификатов.

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

CertAnnContent ::= Certificate
Оповещение об отмене

При выполнении СА отмены или предположении отмены может быть выпущен специальный сертификат для оповещения об этом событии.

RevAnnContent ::= SEQUENCE {
  status PKIStatus,
  certId CertId,
  willBeRevokedAt GeneralizedTime,
  badSinceDate GeneralizedTime,
  crlDetails Extensions OPTIONAL
    -- детали extra CRL (например,
    -- crl number, reason, location, etc.)
}

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

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

Оповещение о CRL

Когда СА выпускает новый CRL (или множество CRLs), для оповещения о данном событии может использоваться следующая структура данных.

CRLAnnContent ::= SEQUENCE
  OF CertificateList
Содержимое подтверждения PKI

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

PKIConfirmContent ::= NULL
Содержимое общего сообщения PKI
InfoTypeAndValue ::= SEQUENCE {
  infoType       OBJECT IDENTIFIER,
  infoValue       ANY DEFINED BY infoType  OPTIONAL
}
-- пример содержимого InfoTypeAndValue включает, но не 
-- ограничивается :
-- { CAProtEncCert       = {id-it 1}, Certificate       }
-- { SignKeyPairTypes     = {id-it 2}, SEQUENCE OF 
-- AlgorithmIdentifier }
-- { EncKeyPairTypes     = {id-it 3}, SEQUENCE OF 
-- AlgorithmIdentifier }
-- { PreferredSymmAlg   = {id-it 4}, AlgorithmIdentifier  }
-- { CAKeyUpdateInfo     = {id-it 5}, CAKeyUpdAnnContent  }
-- { CurrentCRL         = {id-it 6}, CertificateList   }
-- где {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4}
-- данная конструкция может также использоваться для 
-- определения новых сообщений запроса и ответа PKIX 
-- Certificate Management Protocol, или для сообщений, 
-- используемых для общих целей, которые могут 
-- понадобиться в будущем в конкретных окружениях.
GenMsgContent ::= SEQUENCE OF InfoTypeAndValue
  -- Может быть послано EE, RА или СA (в зависимости от 
  -- содержимого сообщения). Параметр OPTIONAL infoValue 
  -- для InfoTypeAndValue для примеров, приведенных 
  -- ниже, обычно опущен. Получатель может игнорировать 
  -- все, что содержит OBJ.IDs, которые не распознаны. 
  -- Если посылается от EE к CA, то пустое множество 
  -- указывает, что СA может послать всю/любую 
  -- интересующую информацию.
Листинг 18.5. Содержимое общего сообщения PKI (html, txt)
Содержимое общего ответа PKI
GenRepContent ::= SEQUENCE OF
  InfoTypeAndValue
  -- Получатель может игнорировать
  -- любое содержимое 
  -- OBJ.IDs, которое он не распознает.
Содержимое сообщения об ошибках
ErrorMsgContent ::= SEQUENCE {
  pKIStatusInfo PKIStatusInfo,
  errorCode INTEGER OPTIONAL,
  -- конкретные для реализации
  -- коды ошибок 
  errorDetails PKIFreeText OPTIONAL
  -- конкретные для реализации
  -- детали ошибок }
Синтаксис CertRequest

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

CertRequest ::= SEQUENCE {
  certReqId INTEGER,  
  -- ID для обеспечения соответствия
  -- между запросом и ответом
  certTemplate CertTemplate,  
  -- поля из сертификата, который
  -- должен быть выпущен 
  controls Controls OPTIONAL  
  -- атрибуты, используемые при
  -- выпуске сертификата 
}
CertTemplate ::= SEQUENCE {
  version [0] Version OPTIONAL,
  serialNumber [1] INTEGER OPTIONAL,
  signingAlg   [2] AlgorithmIdentifier OPTIONAL,
  issuer   [3] Name OPTIONAL,
  validity [4] OptionalValidity OPTIONAL,
  subject [5] Name OPTIONAL,
  publicKey [6] SubjectPublicKeyInfo OPTIONAL,
  issuerUID [7] UniqueIdentifier OPTIONAL,
  subjectUID [8] UniqueIdentifier OPTIONAL,
  extensions [9] Extensions OPTIONAL 
}
OptionalValidity ::= SEQUENCE {
  notBefore [0] Time OPTIONAL,
  notAfter [1] Time OPTIONAL 
} 
  -- по крайней мере, одно должно быть
  -- представлено 
Time ::= CHOICE {
  utcTime UTCTime,
  generalTime GeneralizedTime 
}
Листинг 18.6. Синтаксис CertRequest (html, txt)
Синтаксис доказательства обладания
ProofOfPossession ::= CHOICE {
  raVerified      [0] NULL,
    -- используется, если RA уже убедился, что 
    -- запрашивающий обладает закрытым ключом   
  signature       [1] POPOSigningKey,
  keyEncipherment [2] POPOPrivKey,
  keyAgreement    [3] POPOPrivKey 
}    
POPOSigningKey ::= SEQUENCE {
  poposkInput     [0] POPOSigningKeyInput OPTIONAL,
  algorithmIdentifier AlgorithmIdentifier,
  signature           BIT STRING 
    -- Подпись (используя "algorithmIdentifier") является 
    -- значением в DER-представлении poposkInput. 
    -- Замечание: если CertReqMsg certReq CertTemplate 
    -- содержит значения subject и publicKey, то poposkInput 
    -- должно быть опущено и подпись должна быть вычислена 
    -- для DER-представления значения CertReqMsg certReq. 
    -- Если CertReqMsg certReq CertTemplate не содержит 
    -- значения открытого ключа и субъекта, то poposkInput 
    -- должно присутствовать и должно быть подписано. Данная 
    -- стратегия гарантирует, что открытый ключ не 
    -- присутствует в полях poposkInput и CertReqMsg certReq 
    -- CertTemplate.
}
POPOSigningKeyInput ::= SEQUENCE {
  authInfo CHOICE {
  sender        [0] GeneralName,
    -- используется только если установлена 
    -- аутентифицированная идентификация для отправителя 
    -- (т.е. DN из ранее выпущенного или действительного 
    -- в настоящий момент сертификата)
  publicKeyMAC  PKMACValue },
    -- используется, если в настоящий момент нет 
    -- аутентифицированного GeneralName отправителя; 
    -- publicKeyMAC содержит MAC, основанный на пароле, 
    -- в DER-представлении значения publicKey
  publicKey     SubjectPublicKeyInfo  -- из CertTemplate
}
PKMACValue ::= SEQUENCE {
  algId  AlgorithmIdentifier,
    -- значение алгоритма должно быть PasswordBasedMac 
    -- {1 2 840 113533 7 66 13}, значение параметра есть 
    -- значение PBMParameter BIT STRING
}
POPOPrivKey ::= CHOICE {
  thisMessage       [0] BIT STRING,
    -- доказательство, представленное в данном сообщении 
    -- (содержит сам закрытый ключ, зашифрованный для СА)
  subsequentMessage [1] SubsequentMessage,
    -- доказательство приведено в следующем сообщении
dhMAC               [2] BIT STRING 
    -- для keyAgreement (только) доказательство 
    -- приведено в данном сообщении, которое содержит 
    -- MAC (для значения DER-представления параметра 
    -- certReq в CertReqMsg, которое должно включать и 
    -- subject, и publicKey), основываясь на ключе, 
    -- полученном из закрытого ключа DH конечного 
    -- участника и открытого ключа DH СА.
}
SubsequentMessage ::= INTEGER {
  encrCert (0),
    -- запросы, при которых результирующий сертификат 
    -- зашифрован для конечного участника (при этом POP 
    -- будет выполнен в подтверждающем сообщении)
  challengeResp (1) 
    -- запросы, при которых CA/RA обязан выполнить обмен 
    -- вызов-ответ с конечным участником, чтобы доказать, 
    -- что ему известен закрытый ключ
}
Листинг 18.7. Синтаксис доказательства обладания (html, txt)

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

Использование МАС, основанного на пароле

Следующий алгоритм должен применяться при использовании publicKeyMAC в POPOSigningKeyInput для доказательства аутентичности запроса.

PBMParameter ::= SEQUENCE {
  salt OCTET STRING,
  owf AlgorithmIdentifier,
    -- AlgId для One-Way Function
    -- (SHA-1 рекомендуется)
  iterationCount INTEGER,
    -- сколько раз применяется OWF 
  mac AlgorithmIdentifier
    -- the MAC AlgId (например,
    -- DES-MAC, Triple-DES-MAC,
    -- или HMAC) }

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

Инициализация первой стадии алгоритма предполагает существование разделяемого секрета, полученного надежным способом CA/RA и конечным участником. Значение salt присоединяется к разделяемому секрету, и односторонняя функция ( owf ) применяется iterationCount раз, где секрет и salt являются входом в первую итерацию, и для каждой следующей итерации вход есть множество выходов предыдущей итерации, включая ключ K.

На второй стадии K и открытый ключ являются входами в НМАС, в результате чего создается значение для publicKeyMAC следующим образом:

publicKeyMAC = Hash( K XOR opad,
  Hash( K XOR ipad, public key) )

где ipad и opad определены в RFC 2104.

Управление публикуемой информацией

Управление pkiPublicationInfo необходимо подписчикам для управления опубликованием СА сертификата. Определен следующий синтаксис:

PKIPublicationInfo ::= SEQUENCE {
  action INTEGER {
    dontPublish (0),
    pleasePublish 1) },
  pubInfos SEQUENCE SIZE (1..MAX)
    OF SinglePubInfo OPTIONAL }
  -- pubInfos не должно присутствовать,
  -- если действие есть "dontPublish" 
  -- (если действие есть 
  -- "pleasePublish" и pubInfos опущено,
  -- предполагается "dontCare")
SinglePubInfo ::= SEQUENCE {
  pubMethod    INTEGER {
    dontCare       (0),
    x500           (1),
    web           (2),
    ldap           (3) },
  pubLocation   GeneralName OPTIONAL }

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

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

Если запрашивающему нужно, чтобы сертификат появился, по крайней мере, в некоторых местах и при этом он хочет допустить, чтобы СА сделал сертификат доступным для других репозиториев, следует установить два значения SinglePubInfo для pubInfos: одно со значением x500, web или ldap, и другое – с dontCare.

Поле pubLocation, если имеется, указывает, где запрашивающий хочет разместить сертификат (заметим, что CHOICE в GeneralName включает, например, URL и IP адрес).

Управление опциями архивирования

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

PKIArchiveOptions ::= CHOICE {
  encryptedPrivKey [0] EncryptedKey,
    -- реальное значение закрытого ключа

  keyGenParameters [1] KeyGenParameters,
    -- параметры, которые допускают
    -- перегенерацию закрытого ключа 

  archiveRemGenPrivKey [2] BOOLEAN 
    -- установлено в TRUE, если отправитель
    -- хочет, чтобы получатель архивировал
    -- закрытый ключ или пару ключей,
    -- которые создал получатель в ответ
    -- на данный запрос; 
    -- установлено в FALSE, если архивация 
    -- не предполагается.
}
EncryptedKey ::= CHOICE {
  encryptedValue EncryptedValue,
  envelopedData [0] EnvelopedData 
    -- зашифрованный закрытый ключ должен
    -- быть размещен в 
    -- envelopedData encryptedContentInfo
    -- encryptedContent 
    -- OCTET STRING.
}
EncryptedValue ::= SEQUENCE {
  intendedAlg [0] AlgorithmIdentifier OPTIONAL,
    -- предполагаемый алгоритм, для
    -- которого будет 
    -- использоваться значение 

  symmAlg [1] AlgorithmIdentifier OPTIONAL,
    -- симметричный алгоритм, используемый
    -- для шифрования значения 

  encSymmKey [2] BIT STRING  OPTIONAL,
    -- (зашифрованный) симметричный ключ,
    -- используемый для шифрования значения

  keyAlg [3] AlgorithmIdentifier OPTIONAL,
    -- алгоритм, используемый для
    -- шифрования симметричного ключа 

  valueHint [4] OCTET STRING OPTIONAL,
    -- краткое описание или идентификатор
    -- содержимого encValue (может иметь 
    -- значение только для посылающего и
    -- использоваться только если 
    -- EncryptedValue должно перепроверяться
    -- посылающим в будущем)

  encValue BIT STRING 
}
KeyGenParameters ::= OCTET STRING
Листинг 18.8. Синтаксис управления опциями архивирования (html, txt)

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

Схема LDAPv2 для инфраструктуры открытого ключа Х.509

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

LDAPv2 является одним из протоколов для доступа к репозиторию PKI. Также определены другие протоколы, такие как HTTP. Если LDAP-сервер, доступный по LDAPv2, используется в качестве репозитория, минимальное требование состоит в том, что репозиторий должен поддерживать дополнительные записи каталога для сертификатов Х.509.

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

Объекты репозитория PKI

Объектами, представленными в репозитории, являются:

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

pkiUser OBJECT-CLASS ::= {
  SUBCLASS OF { top}
  KIND auxiliary
  MAY CONTAIN {userCertificate}
  ID joint-iso-ccitt(2) ds(5)
    objectClass(6) pkiUser(21)
}
userCertificate ATTRIBUTE ::=  {
  WITH SYNTAX Certificate
  EQUALITY MATCHING RULE
    certificateExactMatch
  ID  joint-iso-ccitt(2) ds(5)
    attributeType(4) 
    userCertificate(36) 
}

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

Следующий вспомогательный класс объекта может применяться для представления CAs:

pkiCA OBJECT-CLASS ::= {
  SUBCLASS OF { top}
  KIND auxiliary
  MAY CONTAIN {cACertificate |
      certificateRevocationList |
      authorityRevocationList |
      crossCertificatePair }
  ID   joint-iso-ccitt(2) ds(5)
    objectClass(6) pkiCA(22)
}
cACertificate ATTRIBUTE ::=  {
  WITH SYNTAX Certificate
  EQUALITY MATCHING RULE
    certificateExactMatch
  ID joint-iso-ccitt(2) ds(5)
     attributeType(4) 
     cACertificate(37) 
}
crossCertificatePairATTRIBUTE::={
  WITH SYNTAX   CertificatePair
  EQUALITY MATCHING RULE
    certificatePairExactMatch
  ID joint-iso-ccitt(2) ds(5)
     attributeType(4) 
     crossCertificatePair(40)
}

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

Forward -элементы crossCertificatePair -атрибута записи каталога СА должны использоваться для хранения всех сертификатов, выпущенных данным СА за исключением самоподписанных сертификатов. Дополнительно reverse элементы crossCertificatePair -атрибута записи каталога СА могут содержать подмножество сертификатов, выпущенных данным СА для других CAs. Когда присутствуют оба элемента, forward и reverse, в значении одного атрибута, имя выпускающего в одном сертификате должно соответствовать имени субъекта в другом и наоборот, и открытый ключ субъекта в одном сертификате должен иметь возможность проверять подпись в другом сертификате и наоборот.

Если присутствует элемент reverse, значение forward -элемента и значение reverse -элемента не обязательно должны являться значениями одного о того же атрибута; другими словами они могут являться значениями как одного атрибута, так и значениями двух атрибутов.

В случае v3 сертификатов ни один из перечисленных выше сертификатов не должен включать расширение basicConstraints со значением сА, установленным в FALSE.

Определение области относится исключительно к локальной политике.

certificateRevocationListATTRIBUTE::={
    WITH SYNTAX  CertificateList
    EQUALITY MATCHING RULE
      certificateListExactMatch
    ID joint-iso-ccitt(2) ds(5)
      attributeType(4)
      certificateRevocationList(39)
}

Атрибут certificateRevocationList, если присутствует в конкретной записи СА, содержит CRL(s).

authorityRevocationListATTRIBUTE::={
    WITH SYNTAX   CertificateList
    EQUALITY MATCHING RULE
      certificateListExactMatch
    ID joint-iso-ccitt(2) ds(5)
      attributeType(4)
    authorityRevocationList(38)
}

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

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

Если СА решает задействовать точки распространения CRL, для этого используется следующий класс объектов.

cRLDistributionPoint OBJECT-CLASS::= {
  SUBCLASS OF { top }
  KIND structural
  MUST CONTAIN { commonName }
  MAY CONTAIN {
     certificateRevocationList |
     authorityRevocationList |
     deltaRevocationList }
  ID joint-iso-ccitt(2) ds(5)
     objectClass(6) 
     cRLDistributionPoint(19) }

Атрибуты certificateRevocationList и authorityRevocationList определены выше.

Атрибут commonName и атрибуты deltaRevocationList, определенные в Х.509, продублированы ниже.

commonName   ATTRIBUTE::={
  SUBTYPE OF name
  WITH SYNTAX DirectoryString
  ID joint-iso-ccitt(2) ds(5)
    attributeType(4) 
    commonName(3) 
}
deltaRevocationList ATTRIBUTE ::= {
  WITH SYNTAX CertificateList
  EQUALITY MATCHING RULE
    certificateListExactMatch
  ID joint-iso-ccitt(2) ds(5)
    attributeType(4)
    deltaRevocationList(53) }

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

Если СА выбирает использование дельта CRLs, применяется представленный здесь класс объекта.

deltaCRL OBJECT-CLASS ::= {
  SUBCLASS OF { top }
  KIND auxiliary
  MAY CONTAIN { deltaRevocationList }
  ID joint-iso-ccitt(2) ds(5)
    objectClass(6) deltaCRL(23) 
}

Возможный транспорт

Транспортные протоколы, описанные ниже, позволяют конечным участникам, RAs и CАs передавать друг другу PKI-сообщения. Не существует требований относительно применения конкретных механизмов безопасности на данном уровне, если сообщения PKI соответствующем образом защищены (это так, если используется OPTIONAL PKIProtection параметр, как определено для каждого сообщения).

Протокол управления на основе файла

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

Такие файлы могут применяться для передачи PKI-сообщений, с помощью, например, FTP.

Протокол управления, основанный на ТСР

Используется следующий простой протокол, основанный на ТСР, для передачи PKI-сообщений. Данный протокол соответствует случаям, когда конечный участник (или RA) инициирует транзакцию и может принимать результаты.

Если транзакция инициируется PKI-участником (RA или СА), то конечный участник должен либо задействовать listener-процесс, либо иметь соответствующую ссылку, которая позволяет получать PKI-сообщения от компонента управления PKI.

Протокол предполагает существование listener-процесса на RA или СА, который может принимать PKI-сообщения на определенный порт (номер порта 829). Обычно инициатор связывается с данным портом и передает начальное PKI-сообщение для данного ID транзакции. Отвечающий передает PKI-сообщение и/или номер ссылки, который будет использоваться позднее для получения реального PKI- сообщения ответа.

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

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

Инициатор транзакции посылает получателю <<direct TCP-based PKI message>>. Получатель отвечает аналогичным сообщением.

<<direct TCP-based PKI message>> состоит из:

length (32 бита), flag (8 бит), value
Протокол управления по e-mail

Данный раздел описывает способы для пересылки сообщений в представлении ASN.1 для обменов, рассмотренных в предыдущем разделе, с помощью e-mail.

Простой MIME объект определяется следующим образом.

Content-Type: application/pkixcmp
Content-Transfer-Encoding: base64
<<the ASN.1 DER-encoded PKIX-CMP
   message, base64-encoded>>

Данный объект MIME может быть послан или получен с использованием общего MIME, предоставляя простой почтовый транспорт для PKIX-CMP сообщений. Реализации могут также распознавать и задействовать MIME-тип application/x-pkixcmp (определенный в более ранних версиях), чтобы обеспечить обратную совместимость.

Протокол управления по НТТР

Данный подраздел описывает способы для пересылки сообщений в ASN.1 представлении для обменов, описанных в предыдущем разделе, с помощью НТТР.

Простой MIME объект описывается следующим образом.

Content-Type: application/pkixcmp
<<the ASN.1 DER-encoded
    PKIX-CMP message>>

Данный MIME-объект может быть послан или получен с использованием НТТР, используя простой браузер-ориентированный транспорт для PKIX-CMP сообщений. Реализации могут также распознавать и использовать тип MIME application/x-pkixcmp (определенный в более ранних версиях), для обеспечения обратной совместимости.

Протоколы управления по LDAP v2

Данный протокол предназначен для предоставления доступа к репозиториям PKI для получения информации и управления этой информацией. Протокол основан на LDAP v2, определенном в RFC 1777.

Рассмотрим требования для получения информации PKI X.509 из репозитория, включая сертификаты и CRLs.

Конечные участники и САs, используя подмножество протокола LDAPv2, получают информацию PKI из репозитория.

САs помещает информацию PKI в репозиторий, также используя подмножество протокола LDAPv2.

Рассмотрим получение информации PKI из репозитория и управление информацией PKI в нем. Опишем профиль протокола LDAPv2 для выполнения этих функций.

Приведем требования для получения информации PKI (сертификат, CRL или другая представляющая интерес информация) из записи в репозитории, когда данная запись (либо конечного участника, либо СА) имеет известное имя. При этом используется термин "чтение репозитория".

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

Рассмотрим требования для САs для добавления, удаления и модификации информации PKI (сертификат, CRL или другая представляющая интерес информация) в репозитории. При этом используется термин "модификация репозитория".

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

LDAP чтение репозитория

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

BindRequest (и BindResponse)
SearchRequest (и SearchResponse)
UnbindRequest
Bind Request

Приложение, предоставляющее LDAP сервис чтения репозитория, должно реализовать следующее подмножество данной операции:

BindRequest ::= [APPLICATION 0] SEQUENCE {
    version  INTEGER (2),
    name     LDAPDN, 
     -- должен приниматься NULL LDAPDN
    simpleauth [0] OCTET STRING 
     -- должен приниматься NULL simple }

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

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

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

Bind Response

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

success                   (0),
operationsError           (1),
  protocolError           (2),
  authMethodNotSupported  (7),
  noSuchObject            (32),
  invalidDNSyntax         (34),
  inappropriateAuthentication (48),
  invalidCredentials      (49),
  busy                    (51),
  unavailable             (52),
  unwillingToPerform      (53),
  other                   (80)
Search Request

Приложение, предоставляющее LDAP сервис чтения репозитория, должно реализовывать следующее подмножество SearchRequest:

SearchRequest ::= [APPLICATION 3] SEQUENCE {
  baseObject  LDAPDN,
  scope       ENUMERATED {baseObject (0), },
  derefAliases ENUMERATED {
     neverDerefAliases (0),
  },
  sizeLimit  INTEGER (0),
  timeLimit  INTEGER (0),
  attrsOnly  BOOLEAN, -- FALSE only
  filter     Filter,
  attributes SEQUENCE OF AttributeType
}
Filter ::= CHOICE {
  present [7] AttributeType,
   -- только "objectСlass"
}

Данное подмножество LDAPv2 SearchRequest обеспечивает операцию " read " LDAPv2: поиск объекта с использованием фильтра для проверки существования атрибута objectClass.

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

Search Response

Приложение, предоставляющее LDAP сервис поиска в репозитории, должно полностью реализовать SearchResponse.

Заметим, что в том случае, когда атрибут имеет несколько значений, например, userCertificate, SearchResponse содержит все значения, предполагая, что запрашивающий имеет достаточно прав доступа. У приложения или доверяющей группы может возникнуть необходимость выбрать для использования соответствующее значение. Заметим также, что получение сертификата из именованной записи не гарантирует, что сертификат будет включать то же самое DN, и в некоторых случаях subjectDN в сертификате может быть NULL.

LDAP поиск в репозитории

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

BindRequest (и BindResponse), 
SearchRequest (и SearchResponse)
UnbindRequest

Далее приведено требуемое подмножество для каждой операции.

Search Request

Приложение, предоставляющее сервис поиска в репозитории LDAP, должно реализовать следующее подмножество протокола SearchRequest.

SearchRequest ::= [APPLICATION 3] SEQUENCE {
  baseObject   LDAPDN,
  scope ENUMERATED {
    baseObject   (0),
    singleLevel  (1),
    wholeSubtree (2)
  },
  
  derefAliases   ENUMERATED {
    neverDerefAliases (0),
  },
  
  sizeLimit INTEGER (0 .. maxInt),
  timeLimit INTEGER (0 .. maxInt),
  attrsOnly BOOLEAN,  -- FALSE only
  filter Filter,
  attributes SEQUENCE OF
  AttributeType 
}

Должны поддерживаться все аспекты SearchRequest, за исключением следующего:

Данное подмножество предоставляет более общие возможности поиска. Это надмножество подмножества SearchRequest, определенного выше. Элементами, добавляемыми в данный сервис, являются:

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

LDAP модификация репозитория

Для добавления, удаления и модификации PKI информации в репозитории требуется подмножество следующих операций LDAP:

BindRequest (и BindResponse), 
ModifyRequest (и ModifyResponse), 
AddRequest (и AddResponse)
DelRequest (и DelResponse),
UnbindRequest

Далее определяется требуемое подмножество для каждой операции.

Bind

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

BindRequest ::= [APPLICATION 0] SEQUENCE {
  version INTEGER (2),
  name    LDAPDN,
  simpleauth [0] OCTET STRING }

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

Необходимые подмножества BindResponse являются теми же, что были описаны выше.

ModifyRequest

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

ModifyRequest ::= [APPLICATION 6] SEQUENCE {
  object LDAPDN,
  modification SEQUENCE OF SEQUENCE {
    operation ENUMERATED   {
      add (0),
      delete (1)
    },
    modification SEQUENCE {
      type AttributeType,
      values SET OF
      AttributeValue
    }
  }
}

Необходимо поддерживать только значения add и delete для ModifyRequest.

Лекция 7. Инфраструктура Открытого Ключа (часть 7)

Рассмотрен on-line протокол определения статуса сертификата, определены требования к протоколу и описаны детали протокола. Рассмотрены понятия политики сертификата и регламента сертификационной практики. Описаны расширения сертификата CertificatePolicies, PolicyMappings и PolicyConstraints. Описано содержание множества постановлений, касающихся регламента сертификационной практики.

On-line протокол статуса сертификата

Обзор протокола

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

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

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

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

Запрос

Запрос OCSP содержит следующие данные:

При получении запроса OCSP Responder определяет, что:

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

Если хотя бы одно из этих условий не выполнено, OCSP Responder создает сообщение об ошибке; в противном случае он возвращает окончательный ответ.

Ответ

Ответы OCSP могут быть нескольких типов. Ответ OCSP состоит из типа ответа и байтов самого ответа. Существует один базовый тип ответа OCSP, который должен поддерживаться всеми клиентами и серверами OCSP. Далее мы будем рассматривать только данный базовый тип ответа.

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

Сообщение окончательного ответа состоит из:

Ответ для каждого сертификата в запросе состоит из:

Определены следующие варианты статуса сертификата в окончательных ответах:

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

Состояние revoked указывает, что сертификат отменен (либо постоянно, либо временно).

Состояние unknown указывает, что отвечающий не знает о сертификате, который был запрошен.

Исключительные случаи

В случае ошибок OCSP Responder может вернуть соответствующее сообщение. Оно не подписывается. Ошибки могут быть следующих типов:

Сервер создает malformedRequest ответ, если полученный запрос не соответствует OCSP -синтаксису.

Ответ internalError указывает, что OCSP Responder перешел в несогласованное внутреннее состояние. Запрос должен быть повторен с другим Responder.

Если OCSP Responder функционирует, но не может вернуть статус запрошенного сертификата, ответ tryLater может указывать на то, что сервис существует, но временно не может выдать ответ.

Ответ sigRequired возвращается в том случае, когда сервер для создания ответа требует, чтобы клиент подписал запрос.

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

Семантики thisUpdate, nextUpdate и producedAt

Ответы могут содержать три значения времени - thisUpdate, nextUpdate и producedAt. Смысл этих полей следующий:

Если nextUpdate не установлено, это означает, что более новая информация об отмене доступна постоянно.

Ответ Pre-production

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

Делегирование полномочий OCSP Responder'у

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

Компрометация ключа СА

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

Функциональные требования

Содержимое сертификата

Для того чтобы передавать клиентам OCSP точку доступа к информации, САs должны включать расширение AuthorityInfoAccess в сертификаты, которые могут быть проверены с использованием OCSP.

САs, которые поддерживают OCSP -сервис, либо размещающие его локально, либо предоставляющие его внешним клиентам с помощью Responder, должны обеспечивать включение значения URI accessLocation и значения OID id-ad-ocsp для accessMethod в последовательность AccessDescription выпускаемых сертификатов.

Значение поля accessLocation в сертификате субъекта определяет транспорт (например, НТТР), используемый для доступа к OCSP Responder, и может содержать другую относящуюся к транспорту информацию (например, URI).

Требования принятия подписанного ответа

Для того чтобы считать подписанный ответ действительным, клиенты OCSP должны убедиться, что:

  1. Сертификат, указанный в полученном ответе, соответствует тому, который был определен в запросе.
  2. Подпись в ответе действительна.
  3. Идентификация подписавшего соответствует ожидаемому получателю запроса.
  4. Подписавший в настоящий момент авторизован подписывать ответы.
  5. Время, когда статус был указан как корректный ( thisUpdate ), считается неустаревшим.
  6. Время, когда или до которого доступна более новая информация о статусе сертификата ( nextUpdate ), при этом оно должно быть больше текущего времени. Данная информация не является обязательной.

Детали протокола

Используется ASN.1-синтаксис. Для вычисления подписи подписываемые данные представлены с использованием ASN.1 DER.

Запросы

Здесь описывается ASN.1-спецификация запроса. Реальное форматирование сообщения может зависеть от используемого механизма транспорта (НТТР, SMTP, LDAP и т.д.).

Синтаксис запроса
OCSPRequest ::= SEQUENCE {
  tbsRequest   TBSRequest,
  optionalSignature [0] EXPLICIT Signature 
      OPTIONAL 
}
TBSRequest ::= SEQUENCE {
  version [0] EXPLICIT Version DEFAULT v1,
  requestorName [1] EXPLICIT GeneralName 
      OPTIONAL,
  requestList SEQUENCE OF Request,
  requestExtensions [2] EXPLICIT Extensions
      OPTIONAL 
}
Signature ::= SEQUENCE {
  signatureAlgorithm AlgorithmIdentifier,
  signature BIT STRING,
  certs [0] EXPLICIT SEQUENCE OF Certificate
      OPTIONAL
}
Version ::= INTEGER  {  v1(0) }
Request ::= SEQUENCE {
  reqCert   CertID,
  singleRequestExtensions [0] EXPLICIT
      Extensions OPTIONAL 
}
CertID ::= SEQUENCE {
  hashAlgorithm   AlgorithmIdentifier,
  issuerNameHash   OCTET STRING, 
  -- хэш DN выпускающего
  issuerKeyHash   OCTET STRING, 
  -- хэш открытого ключа 
  -- выпускающего
  serialNumber   CertificateSerialNumber
}

IssuerNameHash является хэшем уникального имени выпускающего. Хэш должен вычисляться поверх DER-представления поля имени выпускающего в проверяемом сертификате. IssuerKeyHash является хэшем открытого ключа выпускающего. Хэш должен быть вычислен поверх значения (включая тег и длину) поля открытого ключа субъекта в сертификате выпускающего. Хэш-алгоритм, используемый для вычисления обоих хэшей, указывается в hashAlgorithm. SerialNumber является последовательным номером сертификата, для которого запрашивается статус.

Замечания о синтаксисе запроса

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

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

Запрашивающий может подписать OCSP -запрос. В этом случае подпись вычисляется поверх tbsRequest -структуры. Если запрос подписан, то запрашивающий должен указать свое имя в поле requestorName. Также для подписанных запросов запрашивающий может включить сертификаты, которые помогут OCSP Responder проверить подпись запрашивающего.

Синтаксис ответа

Опишем ASN.1-спецификацию ответов. Реальное форматирование сообщения может зависеть от используемого механизма транспорта (НТТР, SMTP, LDAP и т.д.).

ASN.1 спецификация для OCSP ответа

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

OCSPResponse ::= SEQUENCE {
  responseStatus OCSPResponseStatus,
  responseBytes  [0] EXPLICIT ResponseBytes
OPTIONAL
}
OCSPResponseStatus ::= ENUMERATED {
  successful (0),
  -- ответ содержит подтверждение 
  -- действительности
  malformedRequest (1),
  --неправильно отформатированный запрос
  internalError (2),  
  --внутренняя ошибка
  tryLater (3),  
  --попытаться снова позднее
         --(4) не используется
  sigRequired  (5),  
  --запрос должен быть подписан
  unauthorized (6)   
  --неавторизованный запрос
}

Значение responseBytes состоит из OBJECT IDENTIFIER и синтаксиса ответа, определяющего, что OID представляется как OCTET STRING.

ResponseBytes ::= SEQUENCE {
  responseType OBJECT IDENTIFIER,
  response     OCTET STRING }

Для основного OCSP отвечающего responceType будет id-pkix-ocsp-basic.

id-pkix-ocsp OBJECT IDENTIFIER ::= {
    id-ad-ocsp }
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= {
    id-pkix-ocsp 1 }

OCSP отвечающие должны иметь возможность создавать ответы с типом id-pkix-ocsp-basic. Соответственно OCSP клиенты должны иметь возможность получать и обрабатывать ответы с типом id-pkix-ocsp-basic.

Значение ответа должно иметь DER-представление BasicOCSPResponse.

BasicOCSPResponse ::= SEQUENCE {
    tbsResponseData  ResponseData,
    signatureAlgorithm AlgorithmIdentifier,
    signature BIT STRING,
    certs [0] EXPLICIT SEQUENCE OF 
	    Certificate OPTIONAL }

Значение подписи должно вычисляться для хэша DER-представления ResponseData.

ResponseData ::= SEQUENCE {
  version [0] EXPLICIT Version DEFAULT v1,
  responderID ResponderID,
  producedAt  GeneralizedTime,
  responses   SEQUENCE OF SingleResponse,
  responseExtensions [1] EXPLICIT Extensions
      OPTIONAL 
}
ResponderID ::= CHOICE {
  byName [1] Name,
  byKey  [2] KeyHash 
}
KeyHash ::= OCTET STRING 
  -- SHA-1 хэш открытого ключа Responder'а 
  -- (включая поля тега и длины)
SingleResponse ::= SEQUENCE {
  certID     CertID,
  certStatus CertStatus,
  thisUpdate GeneralizedTime,
  nextUpdate [0]  EXPLICIT GeneralizedTime
      OPTIONAL,
  singleExtensions [1] EXPLICIT Extensions
      OPTIONAL 
}
CertStatus ::= CHOICE {
  good    [0]IMPLICIT NULL,
  revoked [1]IMPLICIT RevokedInfo,
  unknown [2]IMPLICIT UnknownInfo 
}
RevokedInfo ::= SEQUENCE {
  revocationTime GeneralizedTime,
  revocationReason [0] EXPLICIT CRLReason
      OPTIONAL 
}
UnknownInfo ::= NULL 
-- данное поле может быть изменено
Замечания об OCSP-ответах
Время

Поля thisUpdate и nextUpdate определяют рекомендуемый интервал повторной проверки действительности. Данный интервал соответствует {thisUpdate, nextUpdate} интервалу в CRLs. Ответы, у которых значение nextUpdate меньше значения локального системного времени, должны считаться ненадежными.

Ответы, у которых время thisUpdate больше, чем локальное системное время, должны считаться ненадежными. Ответы, у которых значение nextUpdate не установлено, эквивалентны CRL с отсутствием времени для nextUpdate.

Время producedAt - это время, когда ответ был подписан.

Отвечающие уполномоченные органы

Ключ, которым подписана информация о статусе сертификата, не должен быть тем же самым ключом, которым подписан сертификат. Тем не менее, необходимо гарантировать, что участник, подписавший данную информацию, авторизован делать это. Следовательно, выпускающий сертификат должен либо сам подписать ответы OCSP, либо явно делегировать соответствующие полномочия другому участнику. Делегирование подписывания OCSP должно быть выполнено путем включения id-kp-OCSPSigning в расширение extendedKeyUsage сертификата, подписывающего OCSP -ответ. Данный сертификат должен быть выпущен непосредственно СА.

id-kp-OCSPSigning OBJECT IDENTIFIER ::= 
    {id-kp 9}

Проверка отмены сертификата Responder

Так как Responder предоставляет информацию о статусе для одного или более САs, клиенты OCSP должны знать, как проверить, не отменен ли сертификат отвечающего уполномоченного органа. САs могут выбрать один из трех способов решения проблемы:

Обязательные и дополнительные криптографические алгоритмы

Клиенты, которые запрашивают сервис OCSP, должны иметь возможность обрабатывать ответы, подписанные с использованием ключей DSA. Клиенты также должны иметь возможность обрабатывать подписи RSA. Отвечающие OCSP должны поддерживать алгоритм хэширования SHA-1.

Расширения

Опишем некоторые стандартные расширения, основываясь на модели расширений, применяемой в сертификатах Х.509 v3. Поддержка всех расширений не обязательна как для клиентов, так и для Responder. Для каждого расширения укажем его синтаксис и обработку, выполняемую OCSP Responder. Также перечислим все расширения, которые включаются в соответствующий ответ.

Nonce

Nonce криптографически связывает запрос и ответ для предотвращения replay-атак. И в запросе, и в ответе nonce должен идентифицироваться идентификатором объекта id-pkix-ocsp-nonce, значением nonce является extnValue.

id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= 
    { id-pkix-ocsp 2 }
Ссылки на CRL

Может потребоваться для отвечающего OCSP указать CRL, в котором можно найти отмененный или приостановленный сертификат. Это может быть полезно, когда OCSP используется для взаимодействия между репозиториями, а также в качестве механизма аудита. CRL может указываться с помощью URL (по которому CRL доступен), номера (номер CRL) или времени (время, когда соответствующий CRL был создан). Эти расширения специфицируются как singleExtensions. Идентификатор для данного расширения есть id-pkix-ocsp-crl, значением должно быть CrlID.

id-pkix-ocsp-crl OBJECT IDENTIFIER ::= 
    { id-pkix-ocsp 3 }
CrlID ::= SEQUENCE {
  crlUrl  [0] EXPLICIT IA5String OPTIONAL,
  crlNum  [1] EXPLICIT INTEGER OPTIONAL,
  crlTime [2] EXPLICIT GeneralizedTime 
      OPTIONAL }

Для crlUrl IA5String указывает URL, по которому доступен CRL. Для crlNum INTEGER определяет значение расширения номера CRL соответствующего CRL. Для crlTime GeneralizedTime определяет время, когда был выпущен соответствующий CRL.

Типы принимаемых ответов

Клиент OCSP может захотеть указать типы ответов, которые он распознает. Для того чтобы сделать это, он должен использовать расширение с OID id-pkix-ocsp-response и значением AccepttableResponses. Данное расширение включается в одно из requestExtensions в ответах. OIDs, включенные в AccepttableResponses, являются OIDs различных типов ответов, которые данный клиент может принимать (например, id-pkix-ocsp-basic ).

id-pkix-ocsp-response OBJECT IDENTIFIER ::= 
    { id-pkix-ocsp 4 }
AcceptableResponses ::= SEQUENCE OF 
    OBJECT IDENTIFIER

Как отмечалось выше, OCSP отвечающий должен уметь создавать ответы типа id-pkix-ocsp-basic. Соответственно, OCSP клиенты должны уметь получать и обрабатывать ответы типа id-pkix-ocsp-basic.

Архивное хранение

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

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

OCSP -серверы, которые предоставляют поддержку таких исторических ссылок, должны включать в ответы расширение данных archive cutoff. Если оно включено, то данное значение должно быть предоставлено как OCSP singleExtensions расширение, идентифицируемое id-pkix-ocsp-archive-cutoff и имеющее синтаксис GeneralizedTime.

id-pkix-ocsp-archive-cutoff OBJECT 
    IDENTIFIER ::= { id-pkix-ocsp 6 }
ArchiveCutoff ::= GeneralizedTime

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

Расположение сервиса

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

id-pkix-ocsp-service-locator OBJECT 
    IDENTIFIER ::= { id-pkix-ocsp 7 }
ServiceLocator ::= SEQUENCE {
    issuer  Name,
    locator AuthorityInfoAccessSyntax 
	    OPTIONAL 
}

Обсуждение проблем безопасности

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

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

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

Запросы не содержат Responder, к которому они обращаются. Это позволяет атакующему повторить запрос к любому количеству OCSP Responder.

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

OCSP поверх НТТР

Опишем форматирование, которое должно быть выполнено, если запрос и ответ используют НТТР.

Запрос

НТТР, лежащий в основе OCSP -запросов, может использовать либо GET, либо POST метод для submit-запросов. Для возможности НТТР-кэширования небольшие запросы (меньше 255 байтов) могут пересылаться с использованием GET. Если НТТР-кэширование не требуется или размер запроса превышает 255 байтов, запрос должен пересылаться с использованием POST. Если требуется защита, то OCSP -транзакции, применяющие НТТР, могут быть защищены с помощью TLS/SSL или другого протокола более низкого уровня.

OCSP -запрос, использующий метод GET, конструируется следующим образом:

GET {url}/{url-encoding of base-64 encoding
  of the DER encoding of the OCSPRequest}

где {url} может быть получено из значения AuthorityInfoAccess или локальной конфигурации OCSP -клиента.

OCSP -запрос, использующий метод POST, конструируется следующим образом: заголовок Content-Type имеет значение application/ocsp-request, а тело сообщения является бинарным значением DER-представления OCSPRequest.

Ответ

Ответ OCSP, основанный на НТТР, создается в соответствии с заголовками НТТР, за которыми следует бинарное значение DER-представления OCSPResponse. Заголовок Content-Type имеет значение application/ocsp-response. Заголовок Content-Length должен специфицировать длину ответа. Остальные заголовки НТТР могут присутствовать и могут игнорироваться, если запрашивающим они не распознаются.

Понятие политики сертификата и регламента сертификационной практики

Введение

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

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

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

Детальное описание регламента, которому следует СА при выпуске и управлении сертификатами, содержится в регламенте сертификационной практики ( Certification Practice Statement - CPS ), публикуемом СА.

Рассмотрим взаимосвязь между политиками сертификата и CPS.

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

Мы ограничимся обсуждением понятий политики сертификата (как определено в Х.509) и CPS. В частности, опишем типы информации, которые могут быть включены в определение политики сертификата или CPSs. Хотя предполагается использование формата сертификата Х.509 версии 3, не обязательно ограничиваться применением только данного формата сертификата. Более того, считается, что данная основа может быть адаптирована для других форматов сертификата.

Основные понятия

Политика сертификата

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

Стандарт Х.509 определяет политику сертификата как "именованное множество правил, которые определяют применимость сертификата для конкретного сообщества и/или класса приложений с общими требованиями безопасности". Сертификат Х.509 v3 может содержать индикацию политики сертификата, которая может применяться пользователем сертификата при принятии решения о том, можно ли задействовать сертификат для той или иной цели.

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

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

Примеры политики сертификата

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

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

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

Поля сертификата Х.509

Следующие поля расширения в сертификате Х.509 используются для поддержки политик сертификата:

Расширение CertificatePolicies

Расширение CertificatePolicies имеет два варианта - один с полем, помеченным как некритичное, другой с полем, помеченным как критичное. Назначение поля в этих двух случаях различается.

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

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

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

Расширение PolicyMappings

Расширение PolicyMapping может использоваться только в сертификатах СА. Данное поле позволяет СА указать, что некоторые политики в его собственном домене могут считаться эквивалентными некоторым другим политикам в домене субъекта СА.

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

Расширение PolicyConstraints

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

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

Квалификаторы политики

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

В настоящий момент определены следующие типы квалификаторов политики:

  1. Квалификатор CPS Pointer содержит указатель на регламент практики сертифицирования ( CPS ), опубликованный СА. Указатель является URI.
  2. Квалификатор User Notice содержит текстовую строку, которая показывается пользователю сертификата перед тем, как он задействует сертификат.

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

Регламент практики сертификации

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

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

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

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

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

Понятия политики сертификата и CPS пришли из различных источников и были разработаны по разным причинам. Однако их взаимосвязь важна.

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

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

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

Основное различие между политикой сертификата и CPS заключается в следующем:

  1. Большинство организаций, которые выполняют роль публичных или межорганизационных САs, документируют свои регламенты. CPS является одним из организационных способов защиты себя и своей позиции при деловых отношениях с подписчиками и другими участниками.
  2. С другой стороны, не существует особых причин, чтобы политика сертификата применялась только в одной организации. Если конкретная политика сертификата широко распространена, имеются основания для автоматического принятия сертификата во многих системах, включая системы, не требующие участия человека, и системы, которые управляются людьми, но независимо решают вопрос действительности представленных сертификатов.
Множество постановлений

Множество постановлений определяет регламент практики сертификации.

Например, CPS может выражаться в виде сочетания следующих элементов:

  1. Список политик сертификата, поддерживаемых CPS.
  2. Каждой политики сертификата в (1) существует набор постановлений, которые уточняют политику сертификата деталями, обусловленными данной политикой ; такие постановления предназначены для установления того, как конкретный CPS реализует требования конкретной политики сертификата.
  3. Множество постановлений, которые содержат утверждения, относящиеся к регламенту сертификации СА независимо от политики сертификата.

Утверждения, приведенные в (2) и (3), могут уточнить условия применяемости определения политики сертификата, но не должны конфликтовать с другими условиями определения политики сертификата.

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

Далее компоненты могут быть поделены на подкомпоненты.

Содержание множества постановлений

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

Тем не менее, нет необходимости включать каждый раздел в конкретную политику сертификата или CPS. Скорее конкретная политика сертификата или CPS может указать "нет условий" для компонента, подкомпонента или элемента, для которых она не выдвигает требований. В этом случае список тем может рассматриваться как контрольный список при создании политики сертификата или CPS. Рекомендуется, чтобы все компоненты и подкомпоненты были включены в политику сертификата или CPS, даже если там определено "нет условий". Это защищает от случайного пропуска темы и обеспечивает возможность сравнения различных политик или CPSs.

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

Введение

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

Данный компонент имеет следующие подкомпоненты:

Общие постановления

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

  1. Обязательства - содержит для каждого типа участника все используемые постановления, относящиеся к обязательствам участника по отношению к другим участникам.
    • Обязательства СА и/или RA:
      • уведомление подписчика, который является субъектом выпущенного сертификата, о выпуске сертификата;
      • уведомление о выпуске сертификата других участников, которые не являются субъектами сертификата;
      • уведомление об отмене или приостановке сертификата подписчика, чей сертификат отменен или приостановлен;
      • уведомление об отмене или приостановке сертификата других участников, которые не являются субъектами отмененного или приостановленного сертификата.
    • Обязательства подписчика:
      • точность представлений в приложении сертификата;
      • защита закрытого ключа участника;
      • ограничения использования закрытого ключа и сертификата;
      • уведомление о компрометации закрытого ключа.
    • Обязательства доверяющей группы:
      • цели, для которых используется сертификат;
      • ответственность при проверке цифровой подписи;
      • ответственность при проверке отмены и приостановки;
      • признание применяемых законов и полномочий.
    • Обязательства репозитория:
      • своевременное опубликование сертификатов и информации об отмене.
  2. Ответственность.
  3. Финансовая отчетность.
  4. Интерпретация и претворение в жизнь.
  5. Оплата.
  6. Опубликование и хранение:
    • обязательства СА, касающиеся опубликования информации, относящейся к его практикам, сертификатам и текущему статусу сертификатов;
    • частота опубликования;
    • управление доступом к опубликованным информационным объектам, включая определения политики сертификата, CPS, сертификаты, статус сертификата и CRLs;
    • требования, относящиеся к использованию репозиториев.
  7. Согласованный аудит.
  8. Политика конфиденциальности:
    • типы информации, конфиденциальность которых должна обеспечиваться СА или RA;
    • типы информации, которые не считаются конфиденциальными;
    • кто имеет право сообщать о причинах отмены и приостановки сертификатов;
    • политика по сообщению информации об официальном вводе в действие законов;
    • условия, при которых СА или RA могут раскрыть информацию;
    • любые другие условия, при которых конфиденциальная информация может быть раскрыта.
  9. Права интеллектуальной собственности.
Идентификация и аутентификация

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

Данный компонент имеет следующие подкомпоненты:

  1. Начальная регистрация.
    • Типы имен, связанные с субъектом.
    • Являются имена значимыми или нет.
    • Правила интерпретации различных форм имени.
    • Должны ли имена быть уникальными.
    • Как разрешается конфликт имен.
    • Признание, аутентификация и роль торговых марок.
    • Как субъект должен доказывать обладание соответствующим закрытым ключом для зарегистрированного открытого ключа.
    • Требования аутентификации для идентификации организации субъекта (СА, RA или конечного участника).
    • Требования аутентификации для персональных действий от имени субъекта (СА, RA или конечного участника), включая:
    • Число требуемых элементов идентификации.
    • Как СА или RA проверяют действительность предоставленных элементов идентификации.
    • Должен ли конкретный человек персонально присутствовать для аутентификации СА или RA.
    • Как аутентифицируется конкретный человек в качестве представителя организации.
  2. Процедура создания нового ключа - описывает процедуры идентификации и аутентификации для процедуры создания нового ключа для каждого типа субъекта (СА, RA и конечного участника).
  3. Создание нового ключа после отмены - описывает процедуры идентификации и аутентификации при создании нового ключа для каждого типа субъекта (СА, RA и конечного участника) после того, как сертификат субъекта был отменен.
  4. Запрос отмены - описывает процедуры идентификации и аутентификации для запроса отмены для каждого типа субъекта (СА, RA и конечного пользователя).
Требования выполнения

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

Данный компонент состоит из следующих подкомпонентов:

  1. Применение сертификата - используется для установления требований, относящихся к регистрации субъекта и запроса на выпуск сертификата.
  2. Выпуск сертификата - используется для установления требований, относящихся к выпуску сертификата, и уведомления претендента об этом выпуске.
  3. Получение сертификата - используется для установления требований, относящихся к получению сертификата и к последующей его публикации.
  4. Приостановка и отмена сертификата.
    • Условия, при которых сертификат может быть отменен.
    • Кто может запросить отмену сертификата участника.
    • Процедуры, используемые для запроса отмены сертификата.
    • Допустимый период задержки запроса отмены для субъекта.
    • Условия, при которых сертификат может быть приостановлен.
    • Кто может запросить приостановку сертификата.
    • Процедуры запроса приостановки сертификата.
    • Как долго может продолжаться приостановка.
    • Если используется механизм CRL, то частота выпуска.
    • Требования доверяющим группам к проверке CRLs.
    • Возможность on-line проверки отмены/статуса.
    • Требования к доверяющим группам выполнять on-line проверки отмены/статуса.
    • Другие доступные формы объявления об отмене.
    • Требования для доверяющих групп проверять другие формы объявлений об отмене.
    • Любые варианты приведенных выше условий, когда приостановка или отмена являются результатом компрометации ключа (в противовес другим причинам приостановки или отмены).
  5. Процедуры аудита безопасности.
    • Типы записываемых событий.
    • Частота, с которой записи аудита сохраняются и обрабатываются.
    • Срок хранения записей аудита.
    • Процедура выполнения аудита:
      • Кто может просматривать записи аудита.
      • Защита от модификации записей аудита.
      • Защита от удаления записей аудита.
    • Процедуры back up записей аудита.
    • Является система анализа аудита для участника внутренней или внешней.
    • Оповещается ли субъект, который вызвал событие аудита, о действиях аудита.
    • Предполагаемые уязвимости.
  6. Архивация записей.
    • Типы зарегистрированных событий.
    • Период хранения архива.
    • Защита архива:
      • Кто может просматривать архив.
      • Защита от модификации архива.
      • Защита от удаления архива.
    • Процедуры back up архива.
    • Требования к отметкам времени записей.
    • Система хранения архива является внутренней или внешней.
    • Процедуры для получения и проверки архивной информации.
  7. Изменение ключа.
  8. Компрометация и восстановление.
    • Используемые процедуры восстановления, если вычислительные ресурсы, ПО или данные испорчены наверняка или предположительно. Эти процедуры описывают, как переустановить безопасное окружение, в котором отменены сертификаты или ключ участника, как предоставить новый открытый ключ участника пользователям и как субъекты сертифицируются повторно.
    • Процедуры восстановления, которые используются, если открытый ключ участника отменен. Эти процедуры описывают, как переустановить безопасное окружение, как предоставить новый открытый ключ участника пользователям и как субъекты сертифицируются повторно.
    • Процедуры восстановления, использующиеся в том случае, если открытый ключ скомпрометирован. Эти процедуры описывают, как переустановить безопасное окружение, как предоставить новый открытый ключ участника пользователям и как субъекты сертифицируются повторно.
    • Процедуры, СА, используемые для обеспечения безопасности при восстановлении безопасного окружения либо на исходном сайте, либо на удаленном сайте. Например, процедуры защиты от кражи секретных материалов.
  9. Завершение функционирования СА.

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

Создание и инсталляция пары ключей

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

  1. Кто создает пару открытый-закрытый ключи участника?
  2. Каким образом закрытый ключ безопасно доставляется участнику?
  3. Как открытый ключ участника безопасно доставляется выпускающему сертификат?
  4. Если участник является СА (выпускающий или субъект), то как открытый ключ участника безопасно доставляется пользователям?
  5. Каковы размеры ключей?
  6. Кто создает параметры открытого ключа?
  7. Качество параметров проверяется при создании ключа?
  8. Создание ключа выполняется аппаратно или программно?
  9. Для каких целей может использоваться ключ или для каких целей должно быть ограничено применение ключа?
Защита закрытого ключа

Необходимо рассмотреть требования для защиты закрытого ключа для выпускающего СА, репозиториев, субъектов САs, RAs и субъектов конечных участников. Для каждого из этих типов участников нужно ответить на следующие вопросы:

  1. Какие стандарты, если они есть, требуются для модулей, используемых для создания ключей? Если так, то каким должен быть уровень модуля?
  2. Находятся ли закрытые ключи под управлением нескольких человек?
  3. Является ли закрытый ключ распределенным? Если да, то кто является распределенными агентами, которые формируют распределенные ключи, и каково безопасное управление распределенных систем?
  4. Выполняется ли back up для закрытого ключа. Если да, то кто является back up агентом, который формирует back up ключ, и каково безопасное управление back up систем?
  5. Выполняется ли архивация закрытого ключа? Если да, то кто является агентом архивации, какая форма архивации ключа выполняется и каково безопасное управление системой архивации?
  6. Кто вводит закрытый ключ в криптографический модуль? В какой форме? Как закрытый ключ хранится в модуле?
  7. Кто может активизировать (использовать) закрытый ключ? Какие действия должны быть выполнены для активации закрытого ключа? После того как ключ активирован, он активирован на неопределенный срок, активирован для одного раза или активирован на определенный период времени?
  8. Кто может деактивировать закрытый ключ и как, автоматически или по истечении времени?
  9. Кто может уничтожить закрытый ключ?
Другие аспекты управления ключом

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

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

  1. Архивируется ли открытый ключ? Если да, то кто является агентом архивации и какие средства управления безопасностью предусмотрены для системы архивации? Система архивации должна обеспечивать контроль целостности, отличный от цифровых подписей, т.к. период архивации может быть больше, чем период криптоанализа для ключа, и архив требует дополнительной защиты, которая не обеспечивается цифровыми подписями.
  2. Каковы периоды использования или время жизни архива для открытого и закрытого ключа, соответственно?
Данные активации

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

Управление безопасностью компьютера

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

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

Управление безопасностью жизненного цикла

Данный подкомпонент адресован контролю за разработкой системы и контролю управления безопасностью.

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

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

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

Управление криптографическим модулем

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

Лекция 8. Безопасное сетевое взаимодействие (часть 1)

Рассматриваются наиболее распространенные на сегодня приложения, обеспечивающие безопасность сетевого взаимодействия. В первую очередь рассматривается аутентификационный сервис Kerberos. Рассматриваются требования, которым должен удовлетворять Kerberos, описан протокол Kerberos, определены функции AS и TGS, описана структура билета (ticket) и аутентификатора. Введено понятие области (realm) Kerberos. Описан протокол 5 версии.

Kerberos

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

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

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

Существует две версии Kerberos. Наиболее широко используется версия 4. Версия 5, в которой исправлены некоторые недостатки версии 4, описана в RFC 1510.

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

Причины создания Kerberos

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

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

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

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

Kerberos должен удовлетворять следующим требованиям:

  1. Безопасность: при просмотре трафика у оппонента не должно быть возможности получить необходимую информацию для того, чтобы сыграть роль законного пользователя.
  2. Надежность: для всех сервисов, которые используют Kerberos для управления доступом, отсутствие сервера Kerberos означает отсутствие поддерживаемых сервисов. Следовательно, Kerberos должен иметь высокую надежность и реализовывать распределенную серверную архитектуру, в которой одна система может быть вспомогательной для другой.
  3. Прозрачность: в идеале пользователь не должен знать, что имеет место аутентификация, кроме того случая, когда требуется ввести пароль.
  4. Масштабируемость: система должна иметь возможность поддерживать большое число клиентов и серверов. Это требование означает, что Kerberos должен иметь модульную, распределенную архитектуру.

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

Kerberos версии 4

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

Простой аутентификационный протокол

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

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

  1. C  -> AS: IDC, PC, IDS
  2. AS -> C: Ticket
  3. C  -> S: IDC, Ticket 
         Ticket = EKs [IDC, ADC, IDS]

Где:

С - клиент;

AS - аутентификационный сервер;

S - сервер;

IDC - идентификатор пользователя на С ;

IDS - идентификатор S ;

РС - пароль пользователя на С ;

ADC - сетевой адрес С ;

KS - секретный ключ шифрования, разделяемый AS и S.

В данном сценарии предполагается, что пользователь входит на рабочую станцию и хочет получить доступ к серверу S. Клиентский модуль С на пользовательской рабочей станции запрашивает пользовательский пароль и затем посылает сообщение AS , которое включает идентификатор пользователя, идентификатор сервера и пароль пользователя. AS проверяет в своей базе данных правильность пароля пользователя и то, что данному пользователю разрешен доступ к серверу S. Если обе проверки выполнены успешно, AS считает, что пользователь аутентифицирован, и должен теперь убедить сервер, что это так. Для того, чтобы это сделать, AS создает билет ( ticket ), который содержит идентификатор пользователя, сетевой адрес, с которого вошел пользователь, и идентификатор сервера. Этот билет шифруется с использованием секретного ключа, разделяемого AS и S. Он посылается С. Так как билет зашифрован, его не может изменить ни С, ни оппонент.

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

Каждая часть сообщения (3) важна. Билет зашифрован для предотвращения изменения или подделки. Идентификатор сервера IDS включается в билет, чтобы сервер мог убедиться, что он расшифровал билет корректно. IDC включается в билет, чтобы определить, что данный билет послан от имени С. Наконец, АDC служит для предотвращения следующей угрозы. Оппонент может перехватить билет, передаваемый в сообщении (2), затем использовать имя IDC и передать сообщение в форме (3) с другой рабочей станции. Сервер получит законный билет, который соответствует пользователю ID, и предоставит доступ пользователю с другой рабочей станции. Для предотвращения подобной атаки AS включает в билет сетевой адрес, с которого приходит первоначальный запрос. Теперь билет действителен только в том случае, если он передан с той же самой рабочей станции, с которой первоначально запрашивался.

Более безопасный аутентификационный протокол

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

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

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

Для решения этих проблем рассмотрим схему, которая не допускает незашифрованных паролей, и введем новый сервер, называемый сервером предоставления билетов (ticket-granting server - TGS ). Этот сценарий состоит в следующем:

Один раз при входе пользователя:

  1. C -> AS: IDC, IDtgs
  2. AS -> C: EKc [Tickettgs]

Один раз для каждого типа сервиса:

  1. C -> TGS: IDC, IDS, Tickettgs
  2. TGS -> C: TicketS

Один раз для каждого доступа к сервису:

  1. C -> S: IDC, TicketS
Tickettgs = EKtgs [IDC, ADC, IDtgs, TS1, LT1]
TicketS = EKs [IDC, ADC, IDS, TS2, LT2]

Пользователь первым делом получает билет, гарантирующий билет, Tickettgs от AS . Этот билет хранится в модуле клиента на рабочей станции пользователя. Сервер TGS выдает билеты пользователям, которые перед этим были аутентифицированы AS . Каждый раз, когда пользователю требуется новый сервис, клиентский модуль обращается к TGS , используя предоставленный AS билет, и TGS выдает билет для конкретного сервиса. Клиентский модуль хранит каждый гарантирующий сервис билет и использует его для аутентификации на сервере всякий раз, когда требуется конкретный сервис. Рассмотрим данную схему подробнее:

  1. Клиентский модуль запрашивает билет, гарантирующий билет, посылая идентификатор пользователя к AS вместе с идентификатором TGS , который будет в дальнейшем использоваться для получения билета, гарантирующего сервис.
  2. AS в ответ присылает билет, зашифрованный ключом, полученным из пароля пользователя. Когда этот ответ поступает в клиентский модуль, он просит пользователя ввести свой пароль, создает ключ и пытается расшифровать полученное сообщение. Если используется корректный пароль, то билет успешно извлекается.

    Так как только законный пользователь должен знать пароль, только законный пользователь и может получить билет. Таким образом, пароль используется для получения доверительной грамоты от Kerberos без передачи пароля в незашифрованном виде. Сам билет включает идентификатор и сетевой адрес пользователя и идентификатор TGS . Это соответствует первому сценарию. Необходимо, чтобы такой билет мог использоваться клиентским модулем для запроса нескольких билетов, гарантирующих предоставление сервиса. Следовательно, билет, гарантирующий билет, с одной стороны, должен быть переиспользуемым. Но с другой стороны, необходимо добиться того, чтобы оппонент не мог перехватывать этот билет и использовать его. Рассмотрим следующий сценарий: оппонент перехватывает билет и ждет до тех пор, пока пользователь не завершит регистрацию на своей рабочей станции. Тогда оппонент пытается получить доступ к этой рабочей станции или сконфигурировать свою рабочую станцию с тем же сетевым адресом, что и у законного пользователя. После этого оппонент будет иметь возможность переиспользовать билет для обмана TGS . Чтобы этого не произошло, билет включает отметку времени, определяющую дату и время, когда был получен билет, и время жизни, определяющую величину времени, в течение которого билет является действительным (например, 8 часов). Таким образом, теперь клиентский модуль имеет переиспользуемый билет, и нет необходимости требовать от пользователя ввода пароля для получения нового сервиса. В заключении заметим, что билет, гарантирующий билет, шифруется секретным ключом, известным только AS и TGS . Это предотвращает модификацию билета. Билет повторно зашифровывается ключом, основанным на пароле пользователя. Это гарантирует, что билет может быть восстановлен только законным пользователем, прошедшим аутентификацию.

    Теперь, когда клиентский модуль имеет билет, гарантирующий билет, доступ к любому серверу можно получить, выполнив шаги (3) и (4):

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

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

    Наконец, с билетом, гарантирующим сервис, клиентский модуль может получить доступ к соответствующему сервису:

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

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

Аутентификационный протокол версии 4

Хотя рассмотренный сценарий усиливает безопасность по сравнению с первым сценарием, остаются еще две проблемы. Первая проблема состоит в том, что время жизни связано с билетом, гарантирующем билет. Если это время жизни очень короткое (т.е. минуты), то пароль у пользователя будет запрашиваться повторно. Если время жизни большое (т.е. часы), то оппонент имеет больше возможностей для совершения различных replay-атак. Злоумышленник должен просматривать сеть и перехватить билет, гарантирующий билет, и затем ждать, когда законный пользователь выйдет. Затем оппонент может подделать сетевой адрес законного пользователя и послать сообщение шага (3) к TGS . Это откроет ему неограниченный доступ к ресурсам и файлам законного пользователя.

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

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

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

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

Рассмотрим технологию распределения ключа сессии.

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

  1. C -> AS: IDC, IDtgs, TS1 - клиентский модуль запрашивает билет, гарантирующий билет

    IDC: идентификатор пользователя.

    IDtgs: идентификатор TGS .

    TS1: отметка времени, позволяет AS проверить, синхронизированы ли часы клиента с часами AS .

  2. AS -> C: EKc [KC, tgs, IDtgs, TS2, LТ2, Tickettgs ] - AS возвращает билет, гарантирующий билет

    Tickettgs = EKas,tgs [KC,tgs, IDC, ADC, IDtgs, TS2, LТ2 ]

    Tickettgs: билет, используемый клиентом для доступа к TGS .

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

    КC, tgs: ключ сессии, созданный AS для обеспечения безопасного обмена между клиентским модулем и TGS .

    Kas,tgs: ключ, которым зашифрован билет и который известен только AS и TGS .

    IDtgs: подтверждение того, что данный билет предназначен для TGS .

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

    TS2: время создания билета.

    2: время жизни билета.

    Обмен с сервисом, гарантирующим билет, для получения билета, гарантирующего сервис

  3. C -> TGS: IDS, Tickettgs, AuthenticatorC - клиентский модуль запрашивает билет, гарантирующий сервис

    IDS: идентификатор сервера S.

    Tickettgs: гарантирует TGS , что данный пользователь аутентифицирован AS .

    Authenticatorc: создается клиентом для подтверждения законности ключа.

    AuthenticatorC = EKc,tgs [IDC, ADC, TS3 ]

    TS3: время создания аутентификатора.

  4. TGS -> C: EKс,tgs [KC, S, IDS, TS4, LT4, TicketS ] - TGS возвращает билет, гарантирующий сервис

    TicketS = EKtgs,s [KC,S, IDC, ADC, IDS, TS4, LТ4]

    TicketS: билет, используемый клиентом для доступа к серверу S.

    Кtgs,s: ключ, разделяемый S и TGS .

    КC,S: ключ сессии, который создается TGS для обеспечения безопасного обмена между клиентским модулем и сервером без необходимости разделения ими постоянного ключа.

    IDS: доказательство того, что этот ключ предназначен для сервера S.

    TS4: время создания билета.

    4: время жизни билета.

    Клиент/серверный аутентификационный обмен для получения сервиса

  5. C -> S: TicketS, AuthenticatorC - клиент запрашивает сервис

    TicketS = EKtgs,s [KC, S, IDC, ADC, IDS, TS4, LТ4 ]

    AuthenticatorC = EKc [IDC, ADC, TS5 ]

    TicketS: гарантирует серверу, что данный клиент аутентифицирован AS .

    Authenticatorc: создается клиентом для подтверждения законности ключа.

    TS5: время создания аутентификатора.

  6. S -> C: EKc [TS5 + 1] - дополнительная аутентификация сервера для клиента

    TS5 + 1: гарантирует С, что не было replay-атак.

Прежде всего, клиентский модуль посылает сообщение к AS с требованием доступа к TGS . AS отвечает сообщением, зашифрованным ключом, полученным из пароля пользователя, который содержит билет. Зашифрованное сообщение также содержит ключ сессии КC,tgs, где индексы определяют, что это ключ сессии между С и TGS . Таким образом, ключ сессии безопасно передан как С, так и TGS .

К первой фазе сценария добавлено несколько дополнительных элементов информации. Сообщение (1) включает отметку времени, так что AS знает, что сообщение своевременно. Сообщение (2) включает несколько элементов билета в форме, доступной С. Это необходимо С для подтверждения того, что данный билет предназначен для TGS и для определения момента истечения срока его действия.

Теперь, имея билет и ключ сессии, С может обратиться к TGS . Как и раньше, С посылает TGS сообщение, которое включает билет и идентификатор требуемого сервиса (сообщение (3)). Дополнительно С передает аутентификатор, который включает идентификатор и адрес пользователя С, а также отметку времени. В отличие от билета, который является переиспользуемым, аутентификатор применяется только один раз и не имеет времени жизни ( LT ). Теперь TGS расшифровывает билет с помощью ключа, который он разделяет с AS . Этот билет содержит ключ сессии КС,tgs. В действительности билет устанавливает, что любой, кто использует КС,tgs, должен быть С. TGS задействует ключ сессии для дешифрования аутентификатора. TGS может затем сравнить имя и адрес из аутентификатора с тем, которое содержится в билете, и с сетевым адресом входящего сообщения. Если все совпадает, то TGS может быть уверен, что отправитель билета является настоящим его собственником. В действительности аутентификатор устанавливает, что до времени TS3 возможно использование KС,tgs. Заметим, что билет не доказывает чью-либо идентичность, а является способом безопасного распределения ключей. Аутентификатор является доказательством идентификации клиента. Так как аутентификатор может быть использован только один раз, опасности, что оппонент украдет аутентификатор для пересылки его позднее, не существует.

Сообщение (4) от TGS имеет вид сообщения (2). Сообщение зашифровано ключом сообщения, разделяемым TGS и С, и включает ключ сессии, который разделяется С и сервером S, идентификатор S и отметку времени билета. Билет включает тот же самый ключ сессии.

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

Если требуется взаимная аутентификация, сервер посылает сообщение (6), в котором возвращает значение отметки времени из аутентификатора, увеличенное на единицу и зашифрованное ключом сессии. С может расшифровать это сообщение для получения увеличенной отметки времени. Так как сообщение может быть расшифровано ключом сессии, С уверен, что оно может быть создано только S. Это гарантирует С, что replay-атаки не было.

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

Области Kerberos

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

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

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

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

  3. Сервер Kerberos для каждой из взаимодействующих областей разделяет секретный ключ с сервером Kerberos в другой области. Другими словами, два сервера Kerberos регистрируют друг друга.

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

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

Протокол обмена является следующим:

  1. C -> AS: IDC, IDtgs, TS1
  2. AS -> C: EKc [KC, tgs, IDtgs, TS2, LТ2, Tickettgs]
  3. C -> TGS: IDtgsrem, Tickettgs, AuthenticatorC
  4. TGS -> C: EKc, tgs [KC, tgsrem, IDtgsrem, TS4, Tickettgsrem]
  5. C -> TGSrem: IDrem, Tickettgsrem, AuthenticatorC
  6. TGSrem -> C: EKc, tgsrem [KC, Srem, IDSrem, TS6, TicketSrem]
  7. C -> Srem: TicketSrem, AuthenticatorC

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

При таком подходе традиционная проблема состоит в том, что если существует N областей, то должно быть [N (N - 1)]/2 безопасных обменов ключей, чтобы каждый Kerberos области мог взаимодействовать со всеми остальными Kerberos.

Kerberos версии 5

Версия 5 Kerberos описана в RFC 1510 и предоставляет ряд улучшений по сравнению с версией 4. Сначала сделаем общий обзор изменений в версии 5 относительно версии 4, а затем рассмотрим протокол версии 5.

Различия между версиями 4 и 5

Версия 5 предназначена для преодоления недостатков проектирования и технических недоработок версии 4.

Версия 4 Kerberos была разработана для использования в окружении проекта Athena и, следовательно, не предназначалась для использования в общих целях. Это привело к следующим недостаткам проектирования:

  1. Зависимая система шифрования: версия 4 требует использования DES. Сначала существовали экспортные ограничения DES, в настоящий момент основным недостатком является сомнение в силе DES. В версии 5 зашифрованный текст помечен типом шифрования, что позволяет задействовать любой алгоритм симметричного шифрования. Ключ шифрования помечен типом и длиной, что также позволяет применять различные алгоритмы.
  2. Зависимость от Internet-протоколов: версия 4 требует использования IP-адресации. Другие типы адресов, такие как сетевые адреса ISO, не поддерживаются. В версии 5 сетевой адрес помечен типом и длиной, что позволяет задействовать любой тип сетевого адреса.
  3. Упорядочивание байтов сообщения: в версии 4 отправитель сообщения использует упорядочивание байтов по своему выбору и помечает сообщение, чтобы определить, левый или правый байт расположен в младшем адресе. В версии 5 структура всех сообщений определяется на основании ASN.1 и DER, что обеспечивает однозначную последовательность байтов.
  4. Время жизни билета: в версии 4 значения времени жизни хранятся в 8-битовых блоках по 5 минут. Таким образом, максимальное время жизни, которое может быть получено, есть 28 x 5 = 1280 минут или меньше 21 часа. Для некоторых приложений этого может быть недостаточно. В версии 5 билет включает явное время начала и время конца, допуская произвольное время жизни билета.
  5. Перенаправление аутентификации: версия 4 не позволяет, чтобы доверительные грамоты, полученные для одного клиента, были перенаправлены другому хосту и использовались другим клиентом. Эта особенность не дает клиенту возможность получить доступ к серверу, чтобы затем сервер получил доступ к другому серверу от имени данного клиента. Например, клиент сделал запрос на сервер печати, после чего необходим доступ к файл-серверу за файлом клиента, с помощью доверительной грамоты клиента. Версия 5 обеспечивает такую возможность.
  6. Аутентификация между областями: в версии 4 взаимосвязь N областей требует последовательности из N2 взаимосвязей Kerberos-to-Kerberos. Версия 5 поддерживает метод, который требует меньшего числа взаимосвязей.

Существуют также следующие технические недостатки в самом протоколе версии 4:

  1. Двойное шифрование: сообщения 2 и 4, которые поставляют клиентам билеты, зашифрованы дважды, один раз секретным ключом сервера назначения, а затем опять секретным ключом, известным клиенту. Второе шифрование не является обязательным и вычислительно расточительно.
  2. Ключи сессии: каждый билет включает ключ сессии, который используется клиентом для шифрования аутентификатора, посылаемого серверу. Дополнительно ключ сессии может впоследствии использоваться клиентом и сервером для защиты сообщений, передающихся в течение данной сессии. В версии 5 появилась возможность вести переговоры о ключе подсессии, который используется только для одного соединения. Для нового соединения будет применяться новый ключ шифрования.
  3. Атаки на пароль: одним из слабых мест, присущих обеим версиям, являются атаки на пароль. Сообщение от AS клиенту включает нечто, зашифрованное ключом, основанным на пароле клиента. Оппонент может перехватить это сообщение и попытаться расшифровать его, используя различные пароли. Если результат дешифрования будет иметь корректный формат, то это означает, что оппонент раскрыл пароль клиента и может последовательно использовать его для получения доверительной грамоты от Kerberos. Версия 5 обеспечивает механизм, называемый предаутентификацией, который затрудняет атаки на пароли, но не предотвращает их.
Аутентификационный протокол версии 5

Рассмотрим протокол версии 5.

       Получение билета, гарантирующего билет

  1. C -> AS: Options, IDC, RealmC, IDtgs, Times, Nonce1
  2. AS -> C: RealmC, IDC, Tickettgs, EKc [ KC,tgs, Times, Nonce1, Realmtgs, IDtgs]

    Tickettgs = EKtgs [ Flags, KC,tgs, RealmC, IDC, ADC, Times]

    Получение билета, гарантирующего сервис

  3. C -> TGS: Options, IDS, Times, Nonce2, Tickettgs, AuthenticatorC
  4. TGS -> C: RealmC, IDC, TicketS, EKc,tgs [ KC,S, Times, Nonce2, RealmS, IDS]

    Tickettgs = EKtgs [ Flags, KC,tgs, RealmC, IDC, ADC, Times]

    TicketS = EKs [ Flags, KC,S, RealmC, IDC, ADC, Times]

    AuthenticatorC = EKc,tgs [ IDC, RealmC, TS1]

    Получение сервиса

  5. C -> S: Options, TicketS, AuthenticatorC
  6. S -> C: EC, S [TS2, Subkey, Seq#]

    TicketS = EKs [ Flags, KC,S, RealmC, IDC, ADC, Times]

    AuthenticatorC = EKc, s [ IDC, RealmC, TS1, Subkey, Seq#]

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

Сообщение (2) возвращает билет, гарантирующий билет, который содержит информацию для клиента, и блок, зашифрованный с использованием ключа шифрования, основанного на пользовательском пароле. Этот блок включает ключ сессии, который будет использоваться между клиентом и TGS , время, указанное в сообщении 1, nonce из сообщения 1 и определяемую TGS информацию. Сам билет включает ключ сессии, идентифицирующую информацию клиента, требуемое значение времени и флаги, которые отражают статус данного билета и требуемые опции. Эти флаги вводят важные новые функциональности в версии 5.

Сравним получение билета, гарантирующего сервис, в версиях 4 и 5. Сообщение (3) в обеих версиях включает аутентификатор, билет и имя требуемого сервиса. Дополнительно версия 5 включает требуемое время, опции билета и nonce. Аутентификатор тот же самый, что используется в версии 4.

Сообщение (4) имеет ту же структуру, что и сообщение (2); оно возвращает билет и информацию, необходимую клиентскому модулю, зашифрованную ключом сессии, разделяемым к настоящему времени клиентским модулем и TGS .

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

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

Флаги билета

Поле флагов, введенное в билеты в версии 5, поддерживает расширенную функциональность по сравнению с версией 4. Рассмотрим флаги, которые могут быть определены в билете (см. таб. 20.1).

Флаг INITIAL определяет, что данный билет получен от AS , а не от TGS . Когда клиент требует билет, гарантирующий сервис, от TGS , он предоставляет билет, гарантирующий билет, полученный от AS . В версии 4 это был способ, в конечном счете, получить билет, гарантирующий сервис. Версия 5 предоставляет дополнительную возможность, чтобы клиент мог получить билет, гарантирующий сервис, непосредственно от AS . Это применяется в таких, например, случаях, когда сервер изменения пароля хочет убедиться, что пароль клиента был только что проверен.

Флаг PRE-AUTHENT, если установлен, определяет, что когда AS получит первоначальный запрос (сообщение 1), он аутентифицирует клиента, прежде чем выдать билет. Строгая форма этой предаутентификации остается неспецифицированной. Например, реализация MIT версии 5 имеет предаутентификацию в виде зашифрованной отметки времени. В этом случае клиентский модуль посылает AS предаутентификационный блок, содержащий случайное число, номер версии и отметку времени и зашифрованный с использованием пароля пользователя. AS расшифровывает блок и посылает билет, гарантирующий билет, если отметка времени находится в допустимом диапазоне. Другая возможность применения данного флага состоит в использовании смарт-карт, создаваемых с постоянно меняющимся паролем, который включается в предаутентификационное сообщение. Пароли, создаваемые картой, могут быть основаны на пользовательских паролях, но затем быть преобразованы смарт-картой так, чтобы в действительности использовались одноразовые пароли. Это предотвращает атаки, основанные на легко вскрываемых паролях. Если используется смарт-карта или аналогичное устройство, это определяется флагом HW-AUTHENT.

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

Клиент может выдать запрос на предоставление AS билета, гарантирующего билет, с установленным флагом MAY-POSTDATE. Клиент может затем использовать этот билет для запроса билета от TGS с установленными флагами POSTDATED и INVALID. Впоследствии клиент может подать подтверждение на просроченный билет, чтобы сделать его действительным. Эта схема может использоваться для выполнения долгих пакетных заданий на сервере, который периодически требует билет. Клиент может один раз получить некоторое число билетов для данной сессии с несколькими значениями времени. Все, кроме первого билета, первоначально являются недопустимыми. При наступлении момента, когда требуется новый билет, клиент может сделать соответствующий билет действительным. При таком подходе клиент не будет повторно использовать свой билет, гарантирующий билет, для получения билета, гарантирующего сервис.

В версии 5 стало возможным, чтобы сервер являлся proxy для клиента, в результате чего устанавливаются верительные грамоты и привилегии клиента при запросе сервиса от другого сервера. Если клиент хочет использовать данный механизм, он требует билет, гарантирующий билет, с установленным флагом PROXIABLE. Когда такой билет предоставляется от TGS , TGS разрешает получать билет, гарантирующий сервис, с различных сетевых адресов; этот последний билет имеет установленный флаг PROXY. Приложение, получившее такой билет, может принять его или требовать дополнительной аутентификации с тем, чтобы обеспечить след аудита.

Концепция proxy является ограниченным случаем более сильной процедуры перенаправления. Если в билете установлен флаг FORWARDABLE, TGS может выдать запрашивающему билет, гарантирующий билет с различными сетевыми адресами, и установить флаг FORWARDED. Этот билет может затем быть представлен удаленному TGS . Такая возможность позволяет клиенту получить доступ к серверу из другой области без требования того, чтобы каждый Kerberos поддерживал секретный ключ с серверами Kerberos во всех других областях. Например, области могут быть структурированы иерархически. Тогда клиент может просматривать дерево вверх до общего узла и затем спускаться обратно до нужной целевой области. Каждый шаг прохода включает перенаправление билета, гарантирующего билет, к следующему TGS в пути.

Таблица 20.1. Флаги билета
INITIALДанный билет получен с использованием AS-протокола и не получен на основе билета, гарантирующего билет
PRE-AUTHENTПри начальной аутентификации клиент был аутентифицирован прежде, чем был выдан билет
HW-AUTHENTПротокол, используемый для начальной аутентификации, требует использования аппаратуры, ожидая ввода исключительно имени клиента
RENEWABLEГоворит TGS о том, что данный используемый билет получен взамен билета, время действия которого истекло.
MAY-POSTDATEГоворит TGS о том, что просроченный билет мог быть получен на основании данного билета, гарантирующего билет
POSTDATEDОпределяет, что данный билет является просроченным; конечный сервер может проверить поле authtime, чтобы посмотреть, когда произошла первоначальная аутентификация.
INVALIDОпределяет, что данный билет является недействительным и что прежде чем он будет использоваться, его действительность должна быть подтверждена у TGS
PROXIABLEГоворит о том, что новый билет, гарантирующий сервис, с другим сетевым адресом может быть получен на основе существующего билета
PROXYОпределяет, что данный билет является агентом на другой сервис (proxy)
FORWARDABLEГоворит TGS, что новый билет, гарантирующий билет, может быть получен на основе данного билета, гарантирующего билет
FORWARDEDОпределяет, что данный билет является либо forwarded, либо получен на основе аутентификации, включающей forwarded билет, гарантирующий билет

Лекция 9. Безопасное сетевое взаимодействие (часть 2)

Рассматривается протокол TLS/SSL. Описаны протокол Записи и протокол Рукопожатия, определено понятие "состояние соединения". Описаны используемые криптографические операции и PRF. Рассматриваются расширения, которые могут использоваться для добавления функциональностей в TLS.

Протокол TLS/SSL

Введение

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

Протокол TLS (Transport Layer Security) разрабатывался на основе спецификации протокола SSL 3.0 (Secure Socket Layer), опубликованного корпорацией Netscape. Различия между данным протоколом и SSL 3.0 несущественны, но важно заметить, что TLS 1.0 и SSL 3.0 несовместимы, хотя в TLS 1.0 предусмотрен механизм, который позволяет реализациям TLS иметь обратную совместимость с SSL 3.0.

Перечислим задачи протокола TLS в порядке их приоритета:

  1. Криптографическая безопасность: TLS должен использоваться для установления безопасного соединения между двумя участниками.
  2. Интероперабельность: независимые разработчики могут создавать приложения, которые будут взаимодействовать по протоколу TLS, что позволит устанавливать безопасные соединения.
  3. Расширяемость: TLS формирует общий каркас, в который могут быть встроены новые алгоритмы открытого ключа и симметричного шифрования. Это также избавляет от необходимости создавать новый протокол, что сопряжено с опасностью появления новых слабых мест, и предотвращает необходимость полностью реализовывать новую библиотеку безопасности.
  4. Относительная эффективность: криптографические операции интенсивно используют ЦП, особенно операции с открытым ключом. Для этого вводится понятие сессии, для которой определяются алгоритмы и их параметры. В рамках одной сессии может быть создано несколько соединений (например, ТСР). TLS позволяет кэшировать сессии для уменьшения количества выполняемых действий при установлении соединения. Это снижает нагрузку как на ЦП, так и на трафик.

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

  1. Конфиденциальность соединения. Для защиты данных используется один из алгоритмов симметричного шифрования. Ключ для этого алгоритма создается для каждой сессии и основан на секрете, о котором договариваются в протоколе Рукопожатия. Протокол Записи также может использоваться без шифрования.
  2. Целостность соединения. Обеспечивается проверка целостности сообщения с помощью МАС с ключом. Для вычисления МАС используются безопасные хэш-функции SHA-1 и MD5. Протокол Записи может выполняться без вычисления МАС, но обычно функционирует в этом режиме.

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

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

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

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

Элементы протокола

Криптографические операции

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

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

При использовании алгоритма RSA подписывается 36-байтная структура, состоящая из конкатенации 20 байтов хэш-кода SHA-1 и 16 байтов хэш-кода MD5.

При использовании DSS 20 байтов хэш-кода SHA-1 подаются на вход алгоритму DSA без дополнительного хэширования. При этом создается два значения: r и s.

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

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

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

НМАС и псевдослучайная функция

Для получения МАС используется НМАС, поэтому если не знать секрета МАС, подделать МАС невозможно.

НМАС может использоваться с различными хэш-алгоритмами. TLS задействует при Рукопожатии два алгоритма, MD5 и SHA-1, обозначаемых как HMAC_MD5 (secret, data) и HMAC_SHA (secret, data). Могут быть определены дополнительные хэш-алгоритмы, но в настоящей версии используются только MD5 и SHA-1.

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

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

Во-первых, определяется функция расширения данных P_hash (secret, data), которая применяет единственную хэш-функцию для расширения секрета и "зерна":

P_hash (secret, seed) = 
    HMAC_hash (secret, A(1) + seed) +
    HMAC_hash (secret, A(2) + seed) +
    HMAC_hash (secret, A(3) + seed) + ...

Где

+ – обозначает конкатенацию.

А () – определяется следующим образом:

А (0) = seed

A (i) = HMAC_hash (secret, A (i – 1))

P_hash может иметь столько итераций, сколько необходимо для создания требуемого количества данных. Например, если P_SHA-1 используется для создания 64 байтов данных, то количество итераций должно быть равно 4, при этом будет создано 80 байтов данных; последние 16 байтов заключительной итерации будут отброшены, чтобы оставить только 64 байта выходных данных.

PRF создается путем расщепления секрета на две половины, одна половина используется для создания данных с помощью P_MD5, а другая – для создания данных с помощью P_SHA-1, после чего оба выхода этих функций складываются по модулю 2.

PRF определяется как результат сложения по модулю 2 этих двух псевдослучайных значений.

Label является фиксированной текстовой строкой.

Заметим, что поскольку MD5 создает 16-байтные значения, а SHA-1 создает 20-байтные значения, то границы внутренних итераций не будут совпадать. Например, для создания 80-байтного значения необходимо выполнить 5 итераций P_MD5 и 4 итерации P_SHA-1.

Протокол Записи

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

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

Состояния соединения

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

Параметры безопасности для состояний чтения и записи устанавливаются с помощью следующих значений (см. таб. 21.1).

Уровень записи использует параметры безопасности для создания следующих шести элементов:

client write MAC secret

server write MAC secret

client write key

server write key

client write IV – только для блочных алгоритмов

server write IV – только для блочных алгоритмов

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

Таблица 21.1. Параметры состояния соединения
Конец соединенияКаждый участник является либо "клиентом", либо "сервером"
Алгоритм симметричного шифрованияАлгоритм, используемый для симметричного шифрования. Данное описание включает размер ключа алгоритма, тип алгоритма (блочный или поточный), размер блока алгоритма и информацию о том, является ли он "экспортируемым"
МАС алгоритмАлгоритм, используемый для проверки целостности сообщения. Это описание включает размер хэша, который возвращается МАС-алгоритмом
Алгоритм сжатияАлгоритм, используемый для сжатия данных. Данное описание включает всю информацию, необходимую алгоритму сжатия
Мастер-секрет48-байтный секрет, разделяемый обоими участниками соединения
Случайное число клиента32-байтное значение, создаваемое клиентом
Случайное число сервера32-байтное значение, создаваемое сервером
Алгоритм МАСМАС-секрет
Последовательный номерКаждое состояние соединения содержит последовательный номер, который вычисляется независимо для состояний чтения и записи. Последовательный номер должен устанавливаться в ноль всякий раз, когда состояние соединения становится активным, т.е. текущим или ожидаемым. Последовательные номера не могут быть больше 264 - 1. Последовательный номер возрастает после каждой записи
Уровень Записи

Уровень Записи получает данные от более высоких уровней в блоках произвольной длины.

Фрагментация

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

Компрессия и декомпрессия

Все записи сжимаются с использованием алгоритма сжатия, определенного в текущем состоянии сессии. Первоначально он определяется как CompressionMethod.null. Алгоритм сжатия преобразует TLSPlaintext -структуру в TLSCompressed -структуру.

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

struct {
    ContentType type; 
    /* same as TLSPlaintext.type */
    
    ProtocolVersion version;
    /* same as TLSPlaintext.version */
    
    uint16 length;
    opaque fragment[TLSCompressed.length];
} TLSCompressed;

length – длина (в байтах) следующего TLSCompressed.fragment.

fragment – сжатая форма TLSPlaintext.fragment.

Защита полезной информации записи

Функции шифрования и МАС преобразуют TLSCompressed -структуру в TLSCiphertext. Функции дешифрования выполняют обратные преобразования. Применение МАС включает последовательный номер, поэтому потерю или повтор сообщений всегда можно обнаружить.

struct {
    ContentType type;
    ProtocolVersion version;
    uint16 length;
    select (CipherSpec.cipher_type) {
        case stream: GenericStreamCipher;
        case block: GenericBlockCipher;
    } fragment;
} TLSCiphertext;

МАС выполняется перед шифрованием. Потоковый шифратор шифрует весь блок, включая МАС. Если CipherSuite есть TLS_NULL_WITH_NULL_NULL, то шифрование состоит из тождественной операции, т.е. данные не шифруются и МАС не используется. TLSCiphertext.length есть сумма TLSCompressed.length и CipherSpec.hash_size.

Для блочных алгоритмов функции шифрования и МАС преобразуют TLSCompressed.fragment -структуру из блоков TLSCiphertext.fragment -структур.

Длина зашифрованных данных ( TLSCiphertext.length ) есть сумма TLSCompressed.length, CipherSpec.hash_size и padding_length.

Рассмотрим пример: если длина содержимого ( TLSCompressed.length ) равна 62 байтам и длина МАС равна 20 байтам, то длина перед добавлением равна 82 байтам. Таким образом, если длина блока равна 8 байтам, то длина добавления должна быть равна 6, чтобы общая длина была кратна 8. Длина добавления может быть 6, 14, 22 и т.д. до 254. Если добавление было сделано минимально необходимым, то добавляется 6 байтов, каждый из которых содержит значение 6.

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

Вычисление ключей

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

Из мастер-секрета с использованием хэш-функций создается последовательность байтов, которая представляет собой МАС-секреты, ключи и инициализационные вектора: client write MAC secret, server write MAC secret, client write key, server write key, client write IV и server write IV. Если некоторое значение не используется, то оно является пустым.

Для создания ключа вычисляется:

key_block = PRF (
    SecurityParameters.master_secret,
    "key expansion",
    SecurityParameters.server_random +
    SecurityParameters.client_random);

Вычисления производятся до тех пор, пока не получится выход заданной длины. Затем key_block разбивается на блоки для получения требуемых ключей следующим образом:

client_write_MAC_secret [
    SecurityParameters.hash_size]
server_write_MAC_secret [
    SecurityParameters.hash_size]
client_write_key [
    SecurityParameters.key_material_length]
server_write_key [
    SecurityParameters.key_material_length]
client_write_IV [SecurityParameters.IV_size]
server_write_IV [SecurityParameters.IV_size]

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

Для экспортируемых алгоритмов шифрования (для которых CipherSpec.is_exportable есть true ) требуется дополнительное вычисление ключей записи:

final_client_write_key =
    PRF (SecurityParameters.client_write_key,
        "client write key",
        SecurityParameters.client_random +
        SecurityParameters.server_random);
final_server_write_key =
    PRF (SecurityParameters.server_write_key,
        "server write key",
        SecurityParameters.client_random +
        SecurityParameters.server_random);

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

iv_block = PRF ("", "IV block", 
    SecurityParameters.client_random +
    SecurityParameters.server_random);

IV_block разделяется на два инициализационных вектора аналогично key_block:

client_write_IV [SecurityParameters.IV_size]
server_write_IV [SecurityParameters.IV_size]

Заметим, что в данном случае PRF используется без секрета: это означает, что секрет имеет нулевую длину и на результат вычисления PRF не влияет.

Протокол Рукопожатия TLS

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

В результате выполнения протокола Рукопожатия будут созданы элементы сессии показанные в таблице 21.3.

Протокол изменения шифрования

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

Таблица 21.3. Создаваемые элементы сессии
Идентификатор сессииПроизвольная последовательность байтов, выбираемая сервером для идентификации активного или возобновляемого состояния сессии
Сертификат участникаХ.509 v3 сертификат участника. Этот элемент может быть нулевым
Метод сжатияАлгоритм, используемый для сжатия данных перед шифрованием
Набор алгоритмовАлгоритм симметричного шифрования данных (такой как null, DES и т.д.), МАС-алгоритм (такой как MD5 или SHA) и различные криптографические атрибуты, такие как hash_size
Мастер-секрет48-байтный секрет, разделямый клиентом и сервером
ВозобновляемоФлаг, определяющий, может ли данная сессия использоваться для создания нового соединения

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

Alert протокол

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

Сообщения закрытия

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

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

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

Требуется, чтобы каждый участник посылал close_notify Alert перед закрытием стороны записи соединения. Это означает, что при получении ответа другого участника с Alert типа close_notify соединение немедленно закрывается и все ожидаемые состояния сбрасываются. Инициатору закрытия не обязательно ждать ответного close_notify Alert перед закрытием стороны чтения соединения.

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

Замечание: предполагается, что при закрытии соединения ожидающие доставки данные надежно доставляются перед разрушением транспорта.

Alerts ошибок

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

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

Таблица 21.4. Типы Alert ошибок
Unexpected_messageПолучено неожидаемое сообщение. Этот Alert всегда фатальный и никогда не должен возникать во взаимодействии корректных реализаций
Bad_record_macДанный Alert возвращается, если полученная запись имеет некорректный МАС. Данное сообщение всегда фатально
Decryption_failedTLSCiphertext дешифрован недопустимым способом: некратная длина блока или недопустимые добавленные значения. Данное сообщение всегда фатально
Record_overflowПолученная TLSCiphertext запись имеет длину больше 214 + 2048 байт, или дешифрованная TLSCompressed запись имеет длину больше 214 + 1024 байт. Данное сообщение всегда фатально
Decompression_failureФункция декомпрессии получила неправильные входные данные. Данное сообщение всегда фатально
Handshake_failureПолучение сообщения handshake_failure Alert говорит о том, что отправитель не смог договориться о приемлемом наборе параметров безопасности. Данное сообщение всегда фатально
Bad_certificateСертификат испорчен, например содержит некорректную подпись
Unsupported_certificateСертификат неподдерживаемого типа
Certificate_revokedСертификат отменен тем, кто его подписал
Certificate_expiredСрок действия сертификата истек и в настоящее время он недействителен
Certificate_unknownДругой результат (неопределенный), полученный в результате обработки сертификата, сертификат не принимается
Illegal_parameterНекоторое поле находится вне диапазона или не согласуется с другими полями. Данное сообщение всегда фатально
Unknown_caПолучена цепочка законных сертификатов или некоторая часть цепочки, но сертификат не принимается, потому что сертификат СА не соответствует известному СА, с которым установлены доверительные отношения. Данное сообщение всегда фатально
Access_deniedПолучен законный сертификат, но при применении контроля доступа отправитель решил не продолжать переговоры. Данное сообщение всегда фатально
Decode_errorСообщение не может быть декодировано, потому что некоторое поле находится вне специфицированного диапазона или некорректна длина сообщения. Данное сообщение всегда фатально
Decrypt_errorНе выполнена криптографическая операция Рукопожатия, которая включает проверку подписи, дешифрование обмена ключа и проверку правильности завершающего сообщения
Export_restrictionПереговоры не выполнены из-за экспортных ограничений; например, попытка передать 1024-битный ключ RSA для метода Рукопожатия RSA_EXPORT. Данное сообщение всегда фатально
Protocol_versionВерсия протокола, с которой клиент пытается вести переговоры, распознана, но не поддерживается. Например, старая версия протокола не должна использоваться по причинам безопасности. Данное сообщение всегда фатально
Insufficient_securityВозвращается вместо handshake_failure, когда переговоры прекращаются из-за того, что сервер требует более безопасных алгоритмов, чем предложены клиентом. Данное сообщение всегда фатально
Internal_errorВнутренняя ошибка, не относящаяся к участникам, но делающая невозможным дальнейшее ведение переговоров (например, невозможность распределения памяти). Данное сообщение всегда фатально
User_canceledДанное Рукопожатие прервано по некоторой причине, не относящейся к падению протокола. Если пользователь прервал операцию после завершения Рукопожатия, то для закрытия соединения больше подходит сообщение close_notify. Данное сообщение обычно является предупреждающим
No_renegotiationПосылается клиентом в ответ на запрос Hello или сервером в ответ на Hello клиента после начала Рукопожатия. Это приводит к невозможности вести новые переговоры; в этой точке тот, кто осуществил первоначальный запрос, может решить продолжать ли использовать данное соединение. Одним из случаев, который может соответствовать данной ситуации, может быть порождение сервером нового процесса для удовлетворения запроса; процесс должен при старте получить параметры безопасности (длину ключа, аутентификацию и т.д.), и возможности внести изменения в параметры после этой точки быть не должно. Данное сообщение всегда является предупреждающим
Обзор протокола Рукопожатия

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

Протокол Рукопожатия включает следующие шаги:

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

Заметим, что протоколы более высокого уровня всегда должны считать, что TLS выберет наиболее сильное соединение между двумя участниками. Протокол разработан для минимизации риска атак типа встреча посередине, но защита от атак, при которых злоумышленник может блокировать доступ к порту, где функционирует сервис безопасности, и попытаться стать участником переговоров аутентифицированного соединения, не предусмотрена. Фундаментальное правило состоит в том, что протоколы более высокого уровня должны учитывать свои требования к безопасности и никогда не передавать информацию по менее безопасному каналу, чем требуется. Протокол TLS является безопасным, и выбранный набор алгоритмов обеспечивает соответствующий уровень безопасности. Например, если в результате переговоров были выбраны 3DES, 1024-битный ключ RSA и сертификат сервера проверен, соединение можно считать безопасным.

Данные цели достигаются протоколом Рукопожатия, который можно просуммировать следующим образом. Клиент посылает сообщение Client Hello, на которое сервер должен ответить сообщением Server Hello или фатальной ошибкой и прерыванием соединения. Client Hello и Server Hello используются для определения максимального уровня безопасности между клиентом и сервером. Client Hello и Server Hello устанавливают следующие атрибуты: Protocol Version, Session ID, Cipher Suite и Compression Method. Дополнительно создаются и передаются два случайных значения: ClientHello.random и ServerHello.random.

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

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

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

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

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

Клиент посылает ClientHello, используя Session ID возобновляемой сессии. Сервер ищет соответствующий идентификатор сессии в своем кэше сессий. Если идентификатор найден, сервер устанавливает соединение с параметрами указанной сессии, после чего посылает ServerHello с тем же самым значением Session ID. В этой точке и клиент, и сервер должны послать сообщения об изменении состояния, после чего сразу послать завершающие сообщения. После этого клиент и сервер начинают обмен данными прикладного уровня. Если соответствующий Session ID не найден, сервер создает новый ID сессии, и клиент и сервер выполняют полное Рукопожатие.

Поток сообщений при сокращенном Рукопожатии

Рассмотрим в деталях каждое сообщение протокола Рукопожатия.

Последовательность сообщений при полном Рукопожатии

Клиент Сервер
ClientHello
ServerHello
Certificate *
ServerKeyExchange *
CertificateRequest *
ServerHelloDone
Certificate *
ClientKeyExchange
CertificateVerify *
[ ChangeCipherSpec ]
Finished
[ChangeCipherSpec ]
Finished
Прикладные данныеПрикладные данные
* указывает на необязательные или зависящие от ситуации сообщения, которые посылаются не всегда.

Протокол Рукопожатия

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

Сообщения протокола Рукопожатия представлены ниже в том порядке, в котором они должны посылаться. При нарушении данного порядка возникает фатальная ошибка. Тем не менее необязательные сообщения Рукопожатия можно опустить. Из этого правила существует одно исключение: сообщение Cеrtificate используется дважды при Рукопожатии (от сервера к клиенту, затем от клиента к серверу), но описано оно только один раз. Единственным сообщением, которое не связано данными правилами упорядоченности, является сообщение Hello Request. Оно может быть послано в любое время, но должно игнорироваться клиентом, если поступает в середине Рукопожатия.

Клиент  Сервер
ClientHello
ServerHello
[ ChangeCipherSpec ]
Finished
[ ChangeCipherSpec ]
Finished
Прикладные данныеПрикладные данные
Сообщения Hello

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

Hello Request

Сообщение Hello Request может быть послано сервером в любое время.

Hello Request является просто уведомлением о том, что клиент должен начать процесс переговоров заново посылкой сообщения Hello. Данное сообщение будет игнорироваться клиентом, если он находится в состоянии переговоров. Данное сообщение может игнорироваться клиентом, если он не хочет вести новые переговоры, при этом клиент может ответить no_renegotiation Alert. Если сервер посылает Hello Request, но не получает в ответ Client Hello, он может закрыть соединение с фатальным Alert.

После посылки Hello Request сервер не должен повторять запрос до тех пор, пока последующие переговоры Рукопожатия не будут завершены.

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

Client Hello

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

Сообщение Client Hello содержит случайные числа, которые используются при создании мастер-секрета.

Сообщение Client Hello может включать идентификатор сессии. Его значение определяет сессию между теми же клиентом и сервером, чьи параметры безопасности клиент хочет использовать. Идентификатор сессии может быть получен из ранее установленного соединения или другого текущего активного соединения. Это дает возможность установить несколько независимых безопасных соединений без повторения полного протокола Рукопожатия. Эти независимые соединения могут существовать как последовательно, так и одновременно. SessionID может использоваться после того, как протокол Рукопожатия завершится обменом Finished -сообщениями и сохраняется до тех пор, пока не будет удален или не произойдет фатальная ошибка в соединении, связанном с данной сессией.

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

Список CipherSuite, передаваемый от клиента серверу в сообщении Client Hello, содержит комбинации криптографических алгоритмов, поддерживаемых клиентом, упорядоченные согласно предпочтениям клиента. Каждый CipherSuite определяет алгоритм обмена ключа, алгоритм основного шифрования (включая длину секретного ключа) и алгоритм МАС. Сервер будет выбирать набор шифрования или, если приемлемый выбор невозможен, возвратит Alert падения Рукопожатия и закроет соединение.

Сlient Hello включает также список алгоритмов сжатия, поддерживаемых клиентом, упорядоченный согласно предпочтениям клиента.

После посылки сообщения Client Hello клиент ждет сообщения Server Hello. Любое другое сообщение, возвращаемое сервером, за исключением Hello Request, трактуется как фатальная ошибка.

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

Server Hello

Сервер посылает данное сообщение в ответ на сообщение Client Hello, для того чтобы выбрать конкретный набор алгоритмов. Если он не может сделать такой выбор, он отвечает handshake failure Alert.

Сертификат сервера

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

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

Все профили сертификатов, ключи и криптографические форматы определены рабочей группой IETF PKIX. Если допускается различное использование ключа, то должен быть установлен бит digitalSignature для ключа, который может применяться для подписывания, и должен быть установлен бит keyEncipherment для ключа, которым можно шифровать. Бит keyAgreement должен быть установлен для сертификатов Диффи-Хеллмана.

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

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

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

Сообщение сервера обмена ключа

Данное сообщение посылается непосредственно после сообщения Server Certificate (или сообщения Server Hello, если переговоры анонимные).

Сообщение сервера обмена ключа посылается сервером только тогда, когда сообщение Server Certificate (если оно послано) не содержит достаточно данных, чтобы клиент мог осуществить обмен премастер-секретом. Это верно для следующих методов обмена ключа:

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

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

Запрос сертификата

Неанонимный сервер может дополнительно запросить сертификат клиента, если это соответствует политике безопасности сервера. Это сообщение, если оно послано, должно следовать сразу же за сообщением Server Key Exchange, если оно послано; в противном случае – за сообщением Server Certificate.

Следует помнить, что запрос идентификации клиента от анонимного сервера является фатальным handshake_failure Alert.

Server Hello Done

Сообщение Server Hello Done посылается сервером для обозначения окончания фазы Server Hello и связанных с ней сообщений. После посылки данного сообщения сервер ждет ответа клиента.

Данное сообщение означает, что сервер завершил отправку сообщений, поддерживающих обмен ключа.

Таблица 21.5. Возможные алгоритмы обмена ключа и типа сертификата
Алгоритм обмена ключаТип ключа сертификата
RSAОткрытый ключ RSA; сертификат должен позволять задействовать ключ для шифрования
RSA_EXPORTУчтены экспортные ограничения, т.е. открытый ключ RSA длиной больше 512 бит может использоваться для подписывания, ключ 512 бит и короче может использоваться как для подписи, так и для шифрования. В первом случае следующим сообщением должно быть ServerKeyExchange, в котором этим ключом будут подписаны открытые ключи Диффи-Хеллмана или другой открытый ключ RSA
DH_DSSОткрытый ключ DSS. Обмен ключа осуществляется по алгоритму Диффи-Хеллмана
DH_RSAОткрытый ключ RSA, который может использоваться для подписывания. Обмен ключа осуществляется по алгоритму Диффи-Хеллмана

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

Сертификат клиента

Это первое сообщение, которое клиент посылает после получения сообщения Server Hello Done. Оно посылается только в том случае, если сервер требует сертификат. Если подходящий сертификат недоступен, клиент должен послать сообщение Certificate, не содержащее сертификатов. Если сервер требует аутентификации клиента для продолжения Рукопожатия, он может ответить фатальным handshake failure Alert. Структура сертификатов клиента такая же, как и сервера.

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

Сообщение Client Key Exchange

Данное сообщение посылается клиентом всегда. Оно следует сразу за сообщением Client Certificate, если таковое посылается. В противном случае это первое сообщение, посланное клиентом после получения сообщения Server Hello Done.

В данном сообщении устанавливается премастер-секрет, который передается либо с помощью RSA шифрования, либо с использованием алгоритма Диффи-Хеллмана, что позволяет каждой стороне вычислить один и тот же премастер-секрет. Когда методом обмена ключа является DH_RSA или DH_DSS и сертификат клиента запрашивается, клиент может ответить сертификатом, содержащим открытый ключ Диффи-Хеллмана, чьи параметры (группа и генератор) должны соответствовать тем, которые специфицированы в сертификате сервера. Никаких других данных это сообщение не содержит.

Структура сообщения зависит от выбранного метода обмена ключа.

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

Проверка целостности с помощью сертификата клиента

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

Здесь handshake_messages означает все сообщения Рукопожатия, посланные или полученные во время Рукопожатия, начиная с Client Hello, но не включая данное сообщение. Включаются поля типа и длины сообщений Рукопожатия. Хэш вычисляется от конкатенации всех структур, посланных и полученных в сообщениях Рукопожатия.

Сообщение Finished

Сообщение Finished всегда посылается непосредственно после сообщения Сhange Сipher Spec для проверки успешного выполнения обмена ключа и процессов аутентификации. Причем сообщение Change Cipher Spec должно быть получено после остальных сообщений Рукопожатия и перед Finished -сообщением.

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

Возникает фатальная ошибка, если сообщению Finished не предшествует сообщение Change Cipher Spec.

Хэш, содержащийся в сообщениях Finished, посылается сервером в Sender.server и клиентом – в Sender.client. Значение handshake_message включает все сообщения Рукопожатия, начиная от Client Hello, но не включая данное Finished -сообщение. Это может отличаться от handshake_message, которые включают сообщение проверки сертификата (если он посылается). Также handshake_message в сообщении Finished, посылаемом сервером, отличается от сообщения Finished, посылаемом клиентом, потому что сервер посылает его вторым, включая предшествующее сообщение.

Напомним, что сообщения о смене шифратора, Alerts и другие типы записей не являются сообщениями Рукопожатия и в вычисление хэша не включаются. Сообщения Hello Request в хэшах Рукопожатия также опущены.

Криптографические вычисления

Вычисление мастер-секрета

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

master_secret = PRF(pre_master_secret, 
    "master secret",
    ClientHello.random + ServerHello.random)     
    [0..47];

Длина мастер-секрета всегда равна 48 байтам. Длина премастер-секрета изменяется в зависимости от метода обмена ключа.

RSA

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

Диффи-Хеллман

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

Расширения TLS

Введение

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

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

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

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

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

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

Описываемые расширения могут использоваться клиентами TLS 1.0 и серверами TLS 1.0. Расширения поддерживают обратную совместимость – это означает, что клиенты TLS 1.0, которые поддерживают расширения, могут общаться с серверами TLS 1.0, не поддерживающими расширения, и наоборот.

Обратная совместимость достигается следующим образом.

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

Рассмотрим дополнительные функциональности в следующем порядке. Сначала опишем общие механизмы расширений для сообщений Рукопожатия Client Hello и Server Hello. Далее опишем конкретные расширения для TLS 1.0 и новые сообщения об ошибках при использовании расширений TLS.

Общие механизмы расширений

Рассмотрим общие механизмы расширений для сообщений Рукопожатия Client Hello и Server Hello.

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

Сначала опишем формат расширенного сообщения Client Hello, затем формат расширенного сообщения Server Hello и формат реально используемого расширения.

Расширенный Client Hello

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

struct {
    ProtocolVersion client_version;
    Random random;
    SessionID session_id;
    CipherSuite cipher_suites<2..2^16-1>;
    CompressionMethod 
      compression_methods<1..2^8-1>;
    Extension 
      client_hello_extension_list<0..2^16-1>;
} ClientHello;

Здесь новое поле client_hello_extension_list содержит список расширений.

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

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

Сервер, который поддерживает механизм расширений, должен принимать как исходный формат, так и расширенный формат Client Hello, и (как и для всех остальных сообщений) проверять, соответствует ли количество данных в сообщении одному из этих форматов; если это не так, он должен послать фатальный Alert decode_error.

Расширенный Server Hello

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

struct {
    ProtocolVersion server_version;
    Random random;
    SessionID session_id;
    CipherSuite cipher_suite;
    CompressionMethod compression_method;
    Extension 
      server_hello_extension_list<0..2^16-1>;
} ServerHello;

Здесь новое поле server_hello_extension_list содержит список расширений. Реальный формат расширения будет определен ниже.

Заметим, что расширенное сообщение Server Hello посылается только в ответ на расширенное сообщение Client Hello. Это позволит избежать ситуации, при которой расширенное сообщение Server Hello не даст установить соединение с существующими клиентами TLS 1.0.

Расширения Hello

Формат расширения для Client Hello и Server Hello следующий:

struct {
    ExtensionType extension_type;
    opaque extension_data<0..2^16-1>;
} Extension;

Где:

enum {
    server_name(0), max_fragment_length(1),
    client_certificate_url(2), 
    trusted_ca_keys(3), truncated_hmac(4), 
    status_request(5), (65535)
} ExtensionType;

Заметим, что для всех типов расширений (включая и те, которые будут определены в дальнейшем) тип расширения не должен появляться в расширенном Server Hello, пока не появится в соответствующем Client Hello. Таким образом, клиенты должны прерывать Рукопожатия, если получили расширенный тип в расширенном Server Hello, который не был запрошен в соответствующем Client Hello.

Расширения, инициируемые сервером (server initiated), могут присутствовать в будущем в рамках данного протокола, при этом требуется, чтобы клиент первым посылал пустое расширение, указывая тем самым, что он готов принимать подобное расширение.

Если в расширенном Client Hello или расширенном Server Hello присутствует несколько расширений различных типов, они могут появляться в произвольном порядке. Не должно быть более одного расширения каждого типа.

Наконец, заметим, что все расширения, определенные в настоящий момент, относятся только к инициализации сессии. Однако клиент, который послал запрос на возобновление сессии, не знает, будет ли принят данный запрос, и, следовательно, должен послать расширенный Client Hello, если это необходимо для новой сессии. Если запрос на возобновление отвергнут, будут вестись переговоры о новом множестве расширений. Если, с другой стороны, старая сессия возобновляется, то сервер должен игнорировать расширения, появившиеся в Client Hello, и послать Server Hello, не содержащий расширений. В этом случае используется расширение, о котором участники договорились при инициализации исходной сессии, возобновлением которой является данная сессия.

Расширения в протоколе Рукопожатия

Поддерживается использование двух новых сообщений Рукопожатия: CertificateURL и CertificateStatus. Новая структура сообщения рукопожатия:

enum {
    hello_request(0), client_hello(1), 
    server_hello(2), certificate(11), 
    server_key_exchange (12),
    certificate_request(13), 
    server_hello_done(14),
    certificate_verify(15), 
    client_key_exchange(16),
    finished(20), certificate_url(21), 
    certificate_status(22), (255)
} HandshakeType;
struct {
    HandshakeType msg_type; 
        /* handshake type */
    uint24 length;          
        /* bytes in message */
    select (HandshakeType) {
      case hello_request: HelloRequest;
      case client_hello: ClientHello;
      case server_hello: ServerHello;
      case certificate: Certificate;
      case server_key_exchange: ServerKeyExchange;
      case certificate_request: CertificateRequest;
      case server_hello_done: ServerHelloDone;
      case certificate_verify: CertificateVerify;
      case client_key_exchange: ClientKeyExchange;
      case finished: Finished;
      case certificate_url: CertificateURL;
      case certificate_status: CertificateStatus;
    } body;
} Handshake;
Используемые расширения

Рассмотрим используемые расширения TLS.

Заметим, что любые сообщения, соответствующие этим расширениям, посылаются при Рукопожатии и должны включаться в вычисления хэша в сообщение Finished.

Сначала рассмотрим расширение, позволяющее клиенту указать сервер, с которым он соединяется. Затем опишем расширение для указания максимальной длины фрагмента. Далее опишем расширение, которое позволяет клиенту указать URLs сертификатов, и расширение, позволяющее указать ключи корневых СА. Наконец, опишем расширение, которое позволяет задействовать урезанный HMAC, и расширение, поддерживающее интеграцию сообщения с информацией о статусе сертификата в Рукопожатие TLS.

Указание имени сервера

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

Для того чтобы указать имя сервера, клиент может включить расширение типа server_name в Client Hello. Поле extension_data должно содержать ServerNameList:

struct {
    NameType name_type;
    select (name_type) {
        case host_name: HostName;
    } name;
} ServerName;
enum {
    host_name(0), (255)
} NameType;
opaque HostName<1..2^16-1>;
struct {
    ServerName server_name_list<1..2^16-1>
} ServerNameList;

На сегодня в качестве имени сервера поддерживается только DNS hostname. Это не означает какой-либо зависимости TLS от DNS, в дальнейшем могут быть добавлены другие типы имен. TLS может трактовать имена серверов как данные неизвестной структуры (opaque) и передавать их приложению.

HostName содержит полностью определенное DNS hostname сервера. Hostname является байтовой строкой, представленной с использованием UTF-8.

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

Если сервер понимает расширение Client Hello, но не смог распознать имя сервера, он должен послать unrecognized_name Alert (который может быть фатальным).

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

Переговоры о максимальной длине фрагмента

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

Для этого клиент может указать расширение типа max_fragment_length в Client Hello. Поле extension_data данного расширения должно содержать:

enum{
    2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
} MaxFragmentLength;

значение которого является требуемой максимальной длиной фрагмента. Допустимыми значениями для данного поля являются: 29, 210, 211 и 212.

Сервер, получивший расширенный Client Hello с расширением max_fragment_length, может принять эту длину, включая расширение типа max_fragment_length в Server Hello. Поле extension_data данного расширения должно содержать MaxFragmentLength, которое является тем же самым, что и запрошенная максимальная длина фрагмента.

Если запрошена недопустимая длина фрагмента, сервер должен прервать Рукопожатие с Alert illegal_parameter. Аналогично, если клиент получил ответ с максимальной длиной фрагмента, отличной от запрошенной, он также должен прервать Рукопожатие с Alert illegal_parameter.

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

Новая длина применяется для продолжения сессии, включая возобновляющиеся сессии.

URLs сертификата клиента

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

Для ведения переговоров о посылке серверу URLs сертификата клиенты могут включать расширение типа client_certificate_url в Client Hello. Поле extension_data данного расширения должно быть пустым.

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

Сервер, получивший расширенный Client Hello, содержащий расширение client_certificate_url, может указать, что имеет возможность принимать URLs сертификата, указывая расширение типа client_certificate_url в Server Hello. Поле extension_data данного расширения должно быть пустым.

После успешного завершения переговоров об использовании URLs сертификата клиента клиент может посылать сообщение CertificateURL вместо сообщения Certificate:

enum {
    individual_certs(0), pkipath(1), (255)
} CertChainType;
enum {
    false(0), true(1)
} Boolean;
struct {
    CertChainType type;
    URLAndOptionalHash 
        url_and_hash_list<1..2^16-1>;
} CertificateURL;
struct {
    opaque url<1..2^16-1>;
    Boolean hash_present;
    select (hash_present) {
        case false: struct {};
        case true: SHA1Hash;
    } hash;
} URLAndOptionalHash;
opaque SHA1Hash[20];

Здесь url_and_hash_list содержит последовательность URLs и хэши (необязательно).

При использовании сертификатов Х.509 существует две возможности:

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

Хэш, соответствующий каждому URL, либо не присутствует, либо является SHA-1 хэшем сертификата или цепочки сертификатов (в случае сертификатов Х.509 DER-представлением сертификата или DER-представлением PkiPath ).

Заметим, что когда используется список URLs для сертификатов Х.509, упорядоченность URLs является той же самой, что и в сообщении Certificate, в противоположность упорядоченности, в которой сертификаты представлены в PkiPath. В любом случае самоподписанный корневой сертификат в цепочке может быть опущен, в предположении, что сервер уже проверил его действительность.

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

Серверы, которые поддерживают данное расширение, должны поддерживать http:URL схему для URLs сертификатов и могут поддерживать другие схемы.

Если протокол, используемый для получения сертификатов или цепочки сертификатов, возвращает MIME форматированный ответ (как делает НТТР), то должен применяться следующий MIME Content-Type: при возврате единственного сертификата Х.509v3 Content-Type есть application/pkix-cert, при возврате цепочки сертификатов Х.509v3 Content-Type есть application/pkix-pkipath.

Если для URL присутствует SHA-1 хэш, то сервер должен убедиться, что SHA-1 хэш содержимого объекта, полученного из URL (после декодирования произвольного MIME Content-Transfer-Encoding), соответствует данному хэшу. Если полученный объект не имеет корректного SHA-1 хэша, сервер должен прервать Рукопожатие с Alert bad_certificate_hash_value.

Заметим, что клиент может выбрать либо посылку Certificate, либо посылку CertificateURL после успешных переговоров о посылке URLs сертификатов. Опция посылки сертификата обеспечивает клиенту гибкость при обработке нескольких сертификатов.

Если сервер столкнулся с непредвиденной задержкой при получении сертификатов по указанному CertificateURL, он должен при истечении таймаута создать Alert ошибки certificate_unobtainable.

Указание доверенного СА

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

Для этого клиенты могут включить расширение типа trusted_ca_keys в Client Hello. Поле extension_data данного расширения должно содержать TrustedAuthorities, где:

struct {
    TrustedAuthority 
        trusted_authorities_list<0..2^16-1>;
} TrustedAuthorities;
struct {
    IdentifierType identifier_type;
    select (identifier_type) {
        case pre_agreed: struct {};
        case key_sha1_hash: SHA1Hash;
        case x509_name: DistinguishedName;
        case cert_sha1_hash: SHA1Hash;
    } identifier;
} TrustedAuthority;
enum {
    pre_agreed(0), key_sha1_hash(1), 
    x509_name(2), cert_sha1_hash(3), (255)
} IdentifierType;
opaque DistinguishedName<1..2^16-1>;

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

Заметим, что клиенты могут включать в данное расширение несколько или все ключи корневого СА, которыми они владеют, либо ни одного из них.

Также возможна ситуация, при которой хэш ключа или DN по отдельности не идентифицируют выпускающего сертификат – например, если конкретный СА имеет несколько пар ключей – однако здесь мы предполагаем, что в TLS DNs идентифицируют выпускающих сертификаты.

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

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

Урезанный НМАС

В настоящий момент набор шифрования использует в качестве МАС НМАС либо с MD5, либо с SHA-1 для аутентификации соединений уровня записи. Весь выход хэш-функции используется в качестве тега МАС. Однако может быть желательно в некоторых ограниченных окружениях обрезать выход хэш-функции до 80 битов при формировании тегов МАС.

Для того чтобы вести переговоры об использовании 80-битного урезанного МАС, клиенты могут включить расширение типа truncated_hmac в расширенный Client Hello. Поле extension_data данного расширения должно быть пустым.

При получении расширенного Hello, содержащего расширение truncated_hmac, сервер может согласиться использовать урезанный МАС путем включения расширения типа truncated_hmac с пустым extension_data в расширенный Server Hello.

Заметим, что если добавлен новый набор алгоритмов шифрования, который не использует НМАС, и при переговорах выбран один из этих наборов, то данное расширение ни на что не влияет. Рекомендуется, чтобы все новые наборы алгоритмов шифрования, использующие другие МАСs, рассматривали размер МАС как составную часть определения набора шифрования, имея в виду как безопасность, так и ограничения ширины полосы пропускания.

Если переговоры об урезанном МАС успешно завершены, клиент и сервер передают эту информацию на уровень записи в качестве параметров безопасности. Далее в данной сессии клиент и сервер должны использовать урезанный НМАС, соответствующим образом вычисляя его. Это означает, что CipherSpec.hash_size есть 10 байтов, и только первые 10 байтов выхода НМАС передаются и проверяются. Заметим, что данное расширение не влияет на вычисление PRF на часть получения ключа.

Размер урезанного МАС применяется к сессиям, в том числе возобновляемым.

Запрос статуса сертификата

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

Для указания возможности получения информации о статусе сертификата клиенты включают расширение типа status_request в Client Hello. Поле extension_data должно содержать CertificateStatusRequest, где:

struct {
    CertificateStatusType status_type;
    select (status_type) {
        case ocsp: OCSPStatusRequest;
    } request;
} CertificateStatusRequest;
enum {ocsp(1), (255)} CertificateStatusType;
struct {
    ResponderID responder_id_list<0..2^16-1>;
    Extensions  request_extensions;
} OCSPStatusRequest;
opaque ResponderID<1..2^16-1>;
opaque Extensions<0..2^16-1>;

В OCSPStatusRequest ResponderIDs указывает список отвечающих OCSP, которым доверяет клиент. Последовательность responder_id_list нулевой длины имеет специальное значение, указывающее, что отвечающие неявно известны серверу, например предварительно согласованы. Extensions являются DER-представлением расширений запроса OCSP.

Оба типа ResponderID и Extensions определены в OCSP. Extensions взято из PKI. Значение request_extension нулевой длины означает, что никаких расширений нет.

Сервер, получивший Client Hello с расширением status_request, может вернуть соответствующий статус сертификата вместе со своим сертификатом. При запросе OCSP следует использовать информацию, содержащуюся в расширении, и включать request_extensions в запрос OCSP.

Сервер возвращает ответ сертификата вместе со своим сертификатом, посылая сообщение CertificateStatus сразу после сообщения Certificate (и перед любым из сообщений ServerKeyExchange или CertificateRequest ). Если сервер вернул сообщение CertificateStatus, он должен включить расширение типа status_request с пустым extension_data в расширенный Server Hello.

struct {
    CertificateStatusType status_type;
    select (status_type) {
        case ocsp: OCSPResponse;
    } response;
} CertificateStatus;
opaque OCSPResponse<1..2^24-1>;

ocsp_response содержит полный OCSP-ответ в DER-представлении. Заметим, что может быть послан только один OCSP-ответ.

Сообщение CertificateStatus передается с использованием сообщения Рукопожатия типа certificate_status.

Заметим, что сервер может решить не посылать сообщение CertificateStatus, даже если он получил расширение status_request в сообщении Client Hello.

Наконец заметим, что сервер не должен посылать сообщение CertificateStatus, если он не получил расширение status_request в сообщении Client Hello.

Клиенты, запрашивающие OCSP-ответ и получающие его в сообщении CertificateStatus, должны проверять OCSP-ответ и прерывать Рукопожатие, если ответ не является удовлетворительным.

Alerts ошибок

В расширении протокола определены новые Alerts ошибок, использующиеся вместе с данными расширениями TLS.

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

Процедура определения новых расширений

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

Следовательно, запросы на определение новых расширений должны утверждаться стандартными действиями IETF.

При определении новых расширений следует помнить:

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

Обсуждение проблем безопасности

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

Безопасность server_name

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

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

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

Безопасность max_fragment_length

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

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

Безопасность client_certificate_url

Для данного расширения существует две проблемы.

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

Если в аутентификации клиента используется *without* в расширении client_certificate_url, цепочка сертификатов клиента охватывается хэшем сообщения Finished. Цель включения хэшей и проверки их при получении цепочки сертификатов состоит в том, чтобы гарантировать, что определенное свойство, указанное в данном расширении, используется, например, что вся информация в цепочке сертификатов, полученная сервером, соответствует той, что посылал клиент.

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

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

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

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

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

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

Кроме того, следует заметить, что в Internet часто используются НТТР кэширующие proxy, и некоторые из них не проверяют самую последнюю версию. Если запрос, использующий НТТР (или другой кэширующий протокол), сконфигурирован неправильно или прерван proxy, proxy сервер может возвратить ответ, не соответствующий текущему запросу.

Безопасность trusted_ca_keys

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

Использование в качестве альтернативы SHA-1 хэшей сертификатов гарантирует недвусмысленность каждого сертификата.

Безопасность truncated_hmac

Очевидно, что урезанные МАСs в целом являются более слабыми, чем полные МАСs. Тем не менее, на сегодня неизвестны особенно уязвимые места для НМАС как с MD5, так и с SHA-1, урезанных до 80 бит.

Заметим, что длина выхода НМАС не должна быть такой же, как длина ключа симметричного шифрования, так как подделка значений МАС не может быть выполнена off-line: в TLS единственный неверный МАС приводит к немедленному завершению сессии TLS.

Безопасность status_request

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

Использование расширения запроса nonce OCSP может усилить защиту в отношении атак, при которых осуществляется попытка повторить ответы OCSP.

Лекция 10. Безопасное сетевое взаимодействие (часть 3)

Рассматривается протокол удаленного безопасного входа SSH. Определяется понятие ключа хоста, описан алгоритм транспортного уровня, способ аутентификации сервера и вычисление разделяемого секрета. Описаны методы аутентификации пользователя и механизм канала, обеспечивающий интерактивные входные сессии, удаленное выполнение команд, перенаправление ТСР/IP-соединений, перенаправление Х11-соединений.

Протокол SSH

Архитектура протокола SSH

Основные понятия

SSH является протоколом для удаленного безопасного входа и других сетевых сервисов безопасности в недостаточно надежно защищенной сети. Рассмотрим архитектуру протокола SSH, а также основные обозначения, используемые при описании этого протокола. Кроме того, обсудим принципы именования объектов системы, принятые в протоколе SSH, что позволяет реализовывать локальные расширения протокола.

SSH состоит из трех компонентов.

  1. Протокол транспортного уровня ( SSH-TRANS ) обеспечивает аутентификацию сервера, конфиденциальность и целостность соединения. Также может дополнительно обеспечивать сжатие данных. Протокол транспортного уровня обычно выполняется поверх соединения TCP, но может использоваться и поверх любого другого надежного соединения.
  2. Протокол аутентификации пользователя ( SSH-USERAUTH ) аутентифицирует клиента для сервера. Он выполняется поверх протокола транспортного уровня.
  3. Протокол соединения ( SSH-CONN ), мультиплексирует несколько логических каналов в один зашифрованный туннель. Протокол выполняется поверх протокола аутентификации пользователя.

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

Протокол соединения создает каналы, которые могут использоваться для различных целей. Существуют стандартные методы установки безопасных сессий интерактивного shell и перенаправления ("туннелирования") произвольных портов TCP/IP и соединений Х11.

Ключи хоста

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

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

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

  1. Клиент имеет локальную базу данных, связывающую каждое имя сервера с соответствующим открытым ключом. Этот метод не требует централизованной административной инфраструктуры и трехсторонней координации. В то же время, такую базу данных тяжело поддерживать при большом количестве клиентов и серверов, с которыми они должны взаимодействовать.
  2. Взаимосвязь имя сервера – ключ проверяется некоторым доверенным сертификационным органом – СА. Клиент знает только ключ корневого CA и может проверить достоверность всех ключей серверов, сертифицированных этими СА.

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

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

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

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

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

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

Возможности дальнейшего развития SSH

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

Для идентификации алгоритмов, методов, форматов и протоколов расширения были выбраны текстовые имена определенного формата. Имена DNS используются для создания локального пространства имен, в котором могут быть определены экспериментальные или классифицированные расширения без риска конфликта с другими реализациями.

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

Определение политики безопасности

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

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

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

  1. Должны быть определены наиболее предпочтительные алгоритмы шифрования, целостности и сжатия для каждого направления и каждого порта.
  2. Должны быть определены используемые алгоритмы открытого ключа и метод обмена ключей для аутентификации сервера.
  3. Должны быть определены методы аутентификации, которые использует сервер для каждого пользователя. Может быть определено требование множественной аутентификации для некоторых или для всех пользователей. Методы и алгоритмы аутентификации могут также зависеть от того, с какого адреса пользователь пытается подключиться.
  4. Должны быть определены операции, которые пользователю разрешено выполнять, используя протокол соединения.
Размеры пакета и заголовка

Минимальный размер пакета SSH равен 28 байтам. Возрастание минимального размера по сравнению с заголовками TCP/IP незначительно для больших пакетов, но очень существенно для небольших, коими являются сессии telnet. Минимальный размер заголовка TCP/IP равен 32 байтам. Таким образом, реально заголовок пакета возрастает с 33 до 61 байта.

Общая доля данных типа telnet в Internet незначительна, поэтому общая нагрузка на трафик небольшая.

Только в одном случае возрастающий размер пакета имеет важное значение – при соединении по медленному модему. Протокол РРР сжимает заголовки TCP/IP, подчеркивая возрастание размера пакета.

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

Локализация и поддержка различных наборов символов

В большинстве случаев протоколы SSH непосредственно не выводят текст на терминал пользователя. Тем не менее, существует несколько случаев, в которых данные должны быть выведены на терминал. В этом случае набор символов должен быть указан явно. В большинстве случаев используется кодировка ISO 10646 UTF-8. При этом определяется поле для тега языка.

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

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

Хотя имя пользователя и клиент, и сервер определяют внутренне, оно должно быть показано в логах, отчетах и т.п. Имена должны иметь кодировку ISO 10646 UTF-8, но в некоторых случаях могут требоваться другие кодировки.

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

Способ именования объектов протокола

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

Для имен алгоритмов существует два формата:

  1. Имена, которые не содержат символ " @ ", зарезервированы для обозначений IANA. Примерами являются '3des-cbc', 'sha-1', 'hmac-sha1'. Имена данного формата не должны использоваться без регистрации в IANA. Зарегистрированные имена не должны содержать символов " @ " или " .".
  2. Можно определить дополнительные алгоритмы, используя имена в формате name@domainname. Часть, следующая за символом @, должна представлять собой полностью определенное доменное Internet-имя лица или организации, определяющих его. Каждый домен управляет своим локальным пространством имен.

Протокол транспортного уровня

Введение

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

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

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

Установление соединения

SSH работает поверх любого 8-битного надежного транспорта. Транспорт, расположенный ниже, должен защищать от ошибок передачи, чтобы при возникновении ошибки SSH -соединение прерывалось. Как обычно, соединение инициирует клиент.

Обмен версией протокола

Когда соединение уровня ТСР установлено, обе стороны должны послать информационную строку в форме SSH-protoversion-softwareversion comments.

Рассмотрим версию протокола 2.0.

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

Совместимость со старыми версиями SSH

При использовании протокола важно поддерживать совместимость с существующими SSH -клиентами и серверами, использующими более старую версию протокола. Поддерживается совместимость с версиями SSH 1.х.

Старый клиент, новый сервер

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

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

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

Новый клиент, старый сервер

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

Протокол бинарного пакета

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

Максимальная длина пакета

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

Компрессия

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

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

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

Шифрование

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

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

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

Таблица 22.1. Структура бинарного пакета
Рacket_lengthДлина пакета (в байтах), не включая поля МАС и packet_length.
Рadding_lengthДлина дополнения (в байтах).
PayloadПолезное содержимое пакета. Если договариваются о сжатии, это поле сжимается. Первоначально компрессия не устанавливается
PaddingДобавление произвольной длины такое, что общая длина ( packet_length || padding_length || payload || padding ) кратна размеру блока шифрования или 8 байтам, в зависимости от того, что больше. Должно быть, по крайней мере, четыре байта добавления. Добавление должно состоять из случайных байтов. Максимальная длина добавления равна 255 байтов
МАСАутентификационный код сообщения. Если договариваются об аутентификации сообщения, это поле содержит байты МАС. Первоначально алгоритм МАС должен быть "none"
Целостность данных

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

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

mac = MAC (key, sequence_numbеr || 
           unencrypted_packet)

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

Алгоритмы МАС для каждого направления должны выбираться независимо, и реализации должны позволять независимо изменять алгоритм для обоих направлений.

Байты МАС, полученные из алгоритма МАС, должны передаваться без шифрования как последняя часть пакета. Число байтов МАС зависит от выбранного алгоритма.

Методы обмена ключа

Метод обмена ключа определяет создание одноразовых ключей сессии для шифрования и вычисления МАС и определяет также метод аутентификации сервера.

В настоящей версии определен только один метод обмена ключей: diffie-hellman-groupl-shal.

Будем рассматривать именно этот метод.

Алгоритмы открытого ключа

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

Существует несколько аспектов, которые определяют тип открытого ключа:

  1. Формат ключа: как ключ шифрует и как представлены сертификаты. Некоторые ключи в данном протоколе могут содержать не только собственно ключ, но и сертификаты.
  2. Алгоритмы подписи и/или шифрования. Некоторые типы ключей не имеют возможности одновременно поддерживать и подпись, и шифрование. Использование ключа может также определяться ограничениями политики, например, требованием наличия сертификатов. В данном случае для различных альтернативных политик должны быть определены различные типы ключа.
  3. Представление подписи и/или зашифрованных данных. Должно быть специфицировано добавление, упорядочивание байтов, форматы данных и, быть может, дополнительные характеристики.
Обмен ключа

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

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

Переговоры об алгоритме

Обмен ключа начинается каждой стороной с посылки следующего пакета:

SSH_MSG_KEXINIT
cookie (random bytes)
kex_algorithms
server_host_key_algoritms
encryption_algorithms_client_to_server
encryption_algorithms_server_to_client
mac_algorithms_client_to_server
mac_algorithms_ server _to_client
compression_algorithms_client_to_server
compression_algorithms_ server _to_client
languages_client_to_server
languages_ server _to_client
first_kex_packet_follows
Таблица 22.2. Параметры переговоров
CookieДолжно быть случайным числом, созданным отправителем. Цель создания этого cookie следующая: сделать так, чтобы ни одна из сторон не могла полностью определить ключи и идентификатор сессии
Kex_algorithms

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

  • сервер также поддерживает данный алгоритм;
  • если алгоритм требует шифрования ключом сервера, существует алгоритм шифрования у серверной части server_host_key_algorithms, который также поддерживается клиентом;
  • если алгоритм требует подписи ключом сервера, существует алгоритм подписи у серверной части server_host_key_algoritms, который также поддерживается клиентом;
  • если нет алгоритма, который удовлетворяет всем этим условиям, соединение прерывается.
Server_host_key_algoritms

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

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

Encryption_algorithms

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

"none" должно быть явно указано в списке, если это принимается

Mac_algorithms

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

"none" должно быть явно указано в списке, если это принимаемо.

Compression_algorithms

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

"none" должно быть явно указано в списке, если это принимается

LanguagesСписок тегов языков в порядке предпочтения в соответствии с RFC-1766. Оба участника могут игнорировать этот список. Если нет предпочтений по языку, список должен быть пустым
First_kex_packet_followsПризнак того, что следующим пакетом будет обмен ключа. Если пакет с обменом ключа будет послан, значение должно быть true. Если нет, то значение должно быть false.

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

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

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

Выход из обмена ключа

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

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

Ключи шифрования должны вычисляться как HASH некоторого известного значения и общего секрета K следующим образом:

  1. Инициализационный вектор при шифровании в направлении от клиента к серверу:

    HASH (K || "A" || session_id) ( "A" означает единственный символ ASCII A).

  2. Инициализационный вектор при шифровании в направлении от сервера к клиенту:

    HASH (K || "B" || session_id)

  3. Ключ шифрования в направлении от клиента к серверу:

    HASH (K || "C" "" || session_id)

  4. Ключ шифрования в направлении от сервера к клиенту:

    HASH (K || "D" || session_id)

  5. Ключ целостности в направлении от клиента к серверу:

    HASH (K || "E" || session_id)

  6. Ключ целостности в направлении от сервера к клиенту:

    HASH (K || "F" || session_id)

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

K1 = HASH (K || X || session_id)
    (например, в первом случае Х есть "A")
K2 = HASH (K || K1) K3 = HASH (K || K1 || K2) и т.д.
Принятие ключей в использование

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

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

SSH_MSG_NEWKEYS
Обмен ключа Диффи-Хеллмана

Обмен ключа Диффи-Хеллмана обеспечивает разделяемый секрет, который не может быть определен оппонентом. При обмене ключа используется подпись, создаваемая закрытым ключом сервера для аутентификации сервера и защиты от атак "man-in-the-middle".

Будем использовать следующие обозначения:

С - клиент;
S - сервер;
р - простое число;
g - генератор для подгруппы GF (p);
V_S - строка версии S ;
V_C - строка версии С ;
K_S - открытый ключ сервера S ;
I_C - сообщение KEXINIT C ;
I_S - сообщение KEXINIT S, которыми участники обменялись перед данными сообщениями.
  1. С создает случайное число х и вычисляет e = gx mod p. C посылает e к S.
    SSH_MSG_KEXDH_INIT
    e
  2. S создает случайное число у и вычисляет f = gy mod p. S получает e и вычисляет K = еу mod p, H = hash (V_C || V_S || I_C || I_S || K_S || e || f || K) и подпись s для Н своим закрытым ключом сервера. S посылает {K_S || f || s} к С. Операция подписывания может включать вторую операцию хэширования.
    SSH_MSG_KEXDH_REPLY
    открытый ключ сервера и сертификаты (K_S)
    f s
  3. С проверяет, действительно ли K_S является ключом сервера S, используя сертификаты или локальную БД. С также может принимать ключ без проверки, однако это делает протокол небезопасным против активных атак (но это может быть сделано из практических соображений во многих окружениях). Затем С вычисляет K = fx mod p, H = hash (V_C || V_S || I_C || K_S || e || f || K) и проверяет подпись s для Н.

    Хэш Н вычисляется от конкатенации следующих значений:

    V_C – строка версии клиента (CR и NL исключаются)
    V_C – строка версии сервера (CR и NL исключаются)
    I_C – содержимое сообщения SSH_MSG_KEXINIT клиента
    I_S – содержимое сообщения SSH_MSG_KEXINIT сервера
    K_Sключ хоста
    e – значение, посылаемое клиентом
    f – значение, посылаемое сервером
    K – разделяемый секрет

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

Алгоритм подписи применяется к значению Н. Большинство алгоритмов подписи включают хэширование. Например, ssh-dss определяет использование SHA. В этом случае данные, во-первых, хэшируются HASH, в результате чего вычисляется Н, и затем Н хэшируется с использованием SHA как часть операции подписывания.

Повторный обмен ключа

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

Запрос сервиса

После выполнения обмена ключа клиент запрашивает один из следующих сервисов: ssh-userauth, ssh-connection.

Сервер должен ответить сообщением:

SSH_MSG_SERVICE_REQUEST
service name

Если сервер поддерживает сервис и разрешает клиенту использовать его, он должен ответить следующим сообщением:

SSH_MSG_SERVICE_ACCEPT
service name
Дополнительные сообщения

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

Сообщение разрыва соединения
SSH_MSG_DISCONNECT
reason code
description
language tag

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

Обсуждение проблем безопасности

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

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

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

Протокол аутентификации пользователя

Обзор протокола аутентификации

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

Имя сервиса для данного протокола – ssh-userauth.

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

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

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

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

Запросы на аутентификацию

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

SSH_MSG_USERAUTH_REQUEST
имя пользователя (UTF-8 кодировка)
имя сервиса (в US-ASCII)
имя метода (в US-ASCII)
остаток пакета определяется методом аутентификации

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

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

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

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

Ответы на запросы аутентификации

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

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

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

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

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

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

Когда сервер принимает аутентификацию, он должен ответить:

SSH_MSG_USERAUTH_SUCCESS

Заметим, что это сообщение не посылается после каждого шага, если аутентификация осуществляется последовательно несколькими методами.

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

Запрос на аутентификацию "none"

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

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

Но данный метод в списке поддерживаемых сервером методов не должен стоять по умолчанию.

Завершение аутентификации пользователя

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

После посылки SSH_MSG_USERAUTH_SUCCESS сервер запускает запрошенный сервис.

Баннерные сообщения

В некоторых случаях может допускаться посылка предупреждающего (warning) сообщения перед аутентификацией. Многие системы UNIX могут показывать текст из /etc/issue или использовать tcp wrappers или аналогичные программы для показа баннеров перед попыткой входа пользователя.

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

SSH_MSG_USERAUTH_BANNER
сообщение
language tag

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

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

Метод аутентификации с использованием открытого ключа: publickey

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

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

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

SSH_MSG_USERAUTH_REQUEST
имя пользователя
сервис
"publickey"
FALSE
имя алгоритма открытого ключа
public key blob

Алгоритмы открытого ключа определены в спецификации транспортного уровня. Public key blob может содержать сертификаты.

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

Сервер должен ответить на данное сообщение либо SSH_MSG_USERAUTH_FAILURE, либо

SSH_MSG_USERAUTH_PK_OK
имя алгоритма открытого ключа из запроса
public key blob из запроса

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

SSH_MSG_USERAUTH_REQUEST
имя пользователя
сервис
"publickey"
TRUE
имя алгоритма открытого ключа
открытый ключ, используемый для аутентификации
подпись

Подпись осуществляется для данных в следующем порядке:

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

Если обе проверки проходят, то данный метод считается успешным. Сервер может потребовать дополнительной аутентификации. Сервер должен ответить сообщением SSH_MSG_USERAUTH_SUCCESS, если больше никаких аутентификаций не требуется, или сообщением SSH_MSG_USERAUTH_FAILURE, если проверки не прошли или необходимы дополнительные аутентификации.

Метод аутентификации с использованием пароля: password

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

SSH_MSG_USERAUTH_REQUEST
имя пользователя
сервис
"password"
FALSE
незашифрованый пароль

Для пароля применяется кодировка ISO-10646 UTF-8. Сервер сам решает, как интерпретировать пароль и как проверять его законность в базе данных паролей. Однако если пользователь вводит пароль в некоторой другой кодировке, клиентское ПО должно перед пересылкой преобразовать пароль в кодировку ISO-10646 UTF-8; сервер должен преобразовать пароль в кодировку, используемую в данной системе для хранения паролей.

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

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

SSH_MSG_USERAUTH_PASSWD_CHANGEREQ
приглашение (ISO-10646 UTF-8)
тег языка

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

SSH_MSG_USERAUTH_REQUEST
имя пользователя
сервис
"password"
TRUE
незашифрованный старый пароль (ISO-10646 UTF-8)
незашифрованный новый пароль (ISO-10646 UTF-8)

Сервер должен ответить на это сообщение сообщениями SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, или другим сообщением SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. Эти ответы имеют следующий смысл:

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

Пароль не изменен. Это означает, что либо изменение пароля не поддерживается, либо старый пароль – неправильный. Заметим, что если сервер уже послал SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, то известно, что он поддерживает изменение пароля.

SSH_MSG_USERAUTH_CHANGEREQ

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

Метод аутентификации на основе адреса хоста: hostbased

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

Клиент запрашивает данную форму аутентификации, посылая сообщение, аналогично UNIX способам аутентификации rhosts и hosts.equiv. Отличие от этих способов аутентификации состоит в том, что идентификация хоста клиента выполняется более строго.

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

SSH_MSG_USERAUTH_REQUEST
имя пользователя
сервис
"hostbased"
алгоритм открытого ключа для ключа хоста
открытый ключ хоста и сертификаты для 
    клиента хоста
имя хоста клиента (FQDN; US-ASCII)
имя пользователя клиента на удаленном хосте
подпись

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

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

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

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

Обсуждение проблем безопасности

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

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

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

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

Протокол соединения

Рассмотрим протокол соединения SSH. Он обеспечивает интерактивные входные сессии, удаленное выполнение команд, перенаправление ТСР/IP-соединений и перенаправление Х11-соединений. Все эти каналы мультиплексируются в единственный зашифрованный туннель. Протокол соединения SSH разработан для выполнения выше транспортного уровня SSH и протоколов аутентификации пользователя. Данный сервис называется ssh-connection.

Общие запросы

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

SSH_MSG_GLOBAL_REQUEST
имя запроса (ограничено US-ASCII)
ждать ответа
. . .	данные, специфичные для запроса

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

SSH_MSG_REQUEST_SUCCESS

Если получатель не распознает или не поддерживает запрос, он просто отвечает:

SSH_MSG_REQUEST_FAILURE
Механизм канала

Все терминальные сессии, перенаправляемые соединения и т.п. являются каналами. Каждая из сторон может открыть канал. Несколько каналов мультиплексируются в единственное соединение.

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

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

Открытие канала

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

SSH_MSG_CHANNEL_OPEN
тип канала (ограничение US-ASCII)
канал отправителя
начальный размер окна
максимальный размер пакета
. . . 	данные, специфичные для типа канала

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

Затем удаленная сторона решает, может ли она открыть канал, и отвечает следующим сообщением

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

Где "канал получателя" есть номер канала, указанный в первоначальном запросе открытия, и "канал отправителя" есть номер канала на другом конце, или

SSH_MSG_CHANNEL_OPEN_FAILURE
канал отправителя
код причины
дополнительная текстовая информация 
    (ISO-10646 UTF-8)
тег языка

Если получатель SSH_MSG_CHANNEL_OPEN сообщения не поддерживает указанный тип канала, он отвечает SSH_MSG_OPEN_FAILURE.

Передача данных

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

SSH_MSG_CHANNEL_WINDOW_ADJUST
канал получателя
байты для добавления

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

Данные передаются в сообщении следующего типа:

SSH_MSG_CHANNEL_DATA
канал получателя
данные

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

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

SSH_MSG_CHANNEL_EXTENDED_DATA
канал получателя
код типа данных
данные
Закрытие канала

Когда участник не собирается больше передавать данные по каналу, он должен послать:

SSH_MSG_CHANNEL_EOF
канал получателя

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

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

SSH_MSG_CHANNEL_CLOSE
канал получателя

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

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

Запросы, специфичные для канала

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

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

SSH_MSG_CHANNEL_REQUEST
канал получателя
тип запроса (ограничено US-ASCII)
ждать ответа
. . . 	данные, специфичные для типа

Если ждать ответа есть FALSE, то никакого ответа на запрос послано не будет. В противном случае получатель отвечает либо SSH_MSG_CHANNEL_SUCCESS, либо SSH_MSG_CHANNEL_FAILURE, либо сообщениями, специфичными для запроса. Если запрос не распознан или не поддерживается каналом, возвращается SSH_MSG_CHANNEL_FAILURE.

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

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

SSH_MSG_CHANNEL_SUCCESS
канал получателя
SSH_MSG_CHANNEL_FAILURE
канал получателя

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

Интерактивные сессии

Сессией является удаленное выполнение программы. Программа может быть shell, приложением, командой системы или некоторой встроенной подсистемой. Она может иметь или не иметь tty, и может включать или не включать перенаправление Х11. Одновременно могут быть активны несколько сессий.

Открытие сессии

Сессия начинается с посылки следующего сообщения:

SSH_MSG_CHANNEL_OPEN
"session"
канал отправителя
начальный размер окна
максимальный размер пакета

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

Запрос псевдо-терминала

Псевдо-терминал может быть открыт для сессии после посылки следующего сообщения:

SSH_MSG_CHANNEL_REQUEST
канал получателя
"pty-req"
ждать ответа
значение переменной окружения TERM (т.е. vt100)
ширина терминала, символы (т.е. 80)
высота терминала, строки (т.е. 24)
ширина терминала, пикселы (т.е. 480)
высота терминала, пикселы (т.е. 640)
режимы кодировки терминала

Нулевая величина параметров должна игнорироваться. Значения символ/ строка перекрывает величины пикселов, если они не равны нулю.

Запросы на открытие pty клиент должен игнорировать.

Передача переменных окружения

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

SSH_MSG_CHANNEL_REQUEST
"env"
ждать ответа
имя переменной
значение переменной
Начало выполнения shell или команды

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

SSH_MSG_CHANNEL_REQUEST
канал получателя
"shell"
ждать ответа

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

SSH_MSG_CHANNEL_REQUEST
канал получателя
"exec"
ждать ответа
команда

Данное сообщение требует, чтобы сервер начал выполнение данной команды. Строка команды может содержать путь.

SSH_MSG_CHANNEL_REQUEST
канал получателя
"subsystem"
ждать ответа
имя подсистемы

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

Сервер не должен прерывать выполнение стека протокола после старта shell или программы. Весь ввод и вывод должны быть перенаправлены в канал, т.е. в зашифрованный туннель.

Передача данных сессии

Передача данных сессии выполняется с использованием пакетов SSH_MSG_CHANNEL_DATA и SSH_MSG_CHANNEL_EXTENDED_DATA и механизма окна. Тип расширенных данных SSH_MSG_CHANNEL_DATA_STDERR определен для stderr-данных.

Сообщение об изменении размеров окна терминала

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

SSH_MSG_CHANNEL_REQUEST
канал получателя
"window-change"
FALSE
ширина терминала, столбцы
высота терминала, строки
ширина терминала, пикселы
высота терминала, пикселы

На данное сообщение никакого ответа не требуется.

Управление локальным потоком

Во многих системах существует возможность определить, использует ли псевдо-терминал управление потоком ^S ^Q. ( ^S – останавливает вывод на экран; ^Q – перезапускает вывод на экран). Когда управление потоком разрешено, часто требуется поддерживать управление потоком на стороне клиента для быстрых ответов на запросы пользователя. Первоначально за управление потоком отвечает сервер.

Данное сообщение используется сервером для информирования клиента о том, может или не может он выполнять управление потоком, т.е. обработку ^S ^Q ). Если client can do равно TRUE, клиенту разрешается выполнять управление потоком, с использованием ^S ^Q. Клиент может игнорировать это сообщение.

SSH_MSG_CHANNEL_REQUEST
канал получателя
"xon-xoff"
FALSE
client can do

На это сообщение не посылается ответа.

Сигналы

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

SSH_MSG_CHANNEL_REQUEST
канал получателя
"signal"
FALSE
номер сигнала
Возвращаемый статус выхода

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

Клиент может игнорировать данное сообщение.

SSH_MSG_CHANNEL_CLOSE
канал получателя
"exit-status"
FALSE
статус выхода

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

SSH_MSG_CHANNEL_REQUEST
канал получателя
"exit-signal"
FALSE
номер сигнала
core dumped
сообщение об ошибке (ISO-10646 UTF-8)
тег языка

"Сообщение об ошибке" содержит дополнительное объяснение ошибки. Это сообщение может состоять из нескольких строк. Клиентское ПО может показать данное сообщение пользователю.

Перенаправление порта TCP/IP
Запрос перенаправления порта

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

SSH_MSG_GLOBAL_REQUEST
"tcpip-forward"
ждать ответа
адрес для связывания
номер порта для связывания

"Адрес для связывания" и "порт для связывания" определяют IP-адрес и порт, к которому будет привязан сокет. Можно фильтровать соединения на основе информации, полученной в запросе открытия.

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

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

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

SSH_MSG_GLOBAL_REQUEST
"cancel-tcpip-forward"
ждать ответа
адрес для связывания
номер порта для связывания

Реализации клиента должны отвергать данное сообщение; обычно оно посылается только клиентом.

Обсуждение проблем безопасности

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

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

Порты перенаправления могут потенциально допускать проникновение сквозь внешние границы безопасности, такие как firewalls.

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

Лекция 11. Архитектура безопасности для IP (часть 1)

Рассматривается архитектура семейства протоколов IPsec. Рассматриваются протоколы безопасности – Authentication Header (AH) и Encapsulating Security Payload (ESP), Безопасные Ассоциации – что это такое, как они работают и как ими управлять, управление ключом – ручное и автоматическое (Internet Key Exchange – IKE), а также алгоритмы, используемые для аутентификации и шифрования.

Введение

Рассмотрим архитектуру семейства протоколов IPsec. Цель данного семейства протоколов состоит в том, чтобы обеспечить различные сервисы безопасности на уровне IP в окружении как IPv4, так и IPv6. Кроме того, будут представлены сервисы безопасности, предоставляемые протоколами IPsec, и применение этих сервисов в IP окружении. Затем мы обсудим следующие компоненты архитектуры безопасности IPsec:

  1. Протоколы безопасности – Authentication Header ( AH ) и Encapsulating Security Payload ( ESP ).
  2. Безопасные Ассоциации – что это такое, как они работают и как ими управлять.
  3. Управление ключом – ручное и автоматическое (Internet Key Exchange – IKE).
  4. Алгоритмы, используемые для аутентификации и шифрования.

Цели разработки

IPsec предназначен для безопасного взаимодействия на основе криптографии для IPv4 и IPv6. Набор сервисов безопасности включает управление доступом, целостность соединения, аутентификацию исходных данных, защиту от replay-атак (целостность последовательности), конфиденциальность (шифрование) и конфиденциальный поток трафика. Эти сервисы предоставляются на уровне IP, обеспечивая защиту для IP и/или протоколов более высокого уровня.

IPsec поддерживает две формы целостности: целостность соединения и частичную целостность последовательности. Целостность соединения является сервисом безопасности, который определяет модификацию конкретной IP датаграммы, безотносительно последовательности датаграмм в потоке трафика. Частичная целостность последовательности является anti-reply сервисом, с помощью которого определяется получение дубликатов IP датаграмм.

Эти сервисы реализуются с использованием двух протоколов обеспечения безопасного трафика, Authentication Header ( AH ) и Encapsulating Security Payload ( ESP ), и с помощью процедур и протоколов управления криптографическим ключом. Множество применяемых IPsec протоколов и метод их использования определяются требованиями безопасности.

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

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

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

Обзор системы

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

IPsec выполняется на хосте или шлюзе безопасности, обеспечивая защиту IP- трафика. Термин "шлюз безопасности" используется для обозначения промежуточной системы, которая реализует IPsec -протоколы. Защита основана на требованиях, определенных в Базе Данных Политики Безопасности (Security Policy Database- SPD ), определяемой и поддерживаемой системным администратором. Пакеты обрабатываются одним из трех способов на основании соответствия информации заголовка IP или транспортного уровня записям в SPD. Каждый пакет либо отбрасывается сервисом безопасности IPsec, либо пропускается без изменения, либо обрабатывается сервисом IPsec на основе применения определенной политики.

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

Как работает IPsec

IPsec использует два протокола для обеспечения безопасности трафика – Authentication Header ( AH ) и Encapsulating Security Payload ( ESP ).

Эти протоколы могут применяться как по отдельности так и в комбинации с друг другом для обеспечения необходимого набора сервисов безопасности в IPv4 и IPv6. Каждый протокол поддерживает два режима использования: режим транспорта и режим туннелирования. В транспортном режиме протоколы обеспечивают защиту главным образом для протоколов более высокого уровня; в режиме туннелирования протоколы применяются для скрытия IP-заголовков исходных пакетов. Разница между двумя режимами рассматривается дальше.

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

Где может размещаться IPsec

Существует несколько способов реализации IPsec на хосте или в соединении с роутером или firewall (для создания безопасного шлюза). Приведем несколько общих примеров:

  1. Интеграция IPsec в конкретную реализацию IP. Это требует доступа к исходному коду IP и применимо как к хостам, так и к шлюзам безопасности.
  2. Bump-in-the-stack (BITS) реализации, где IPsec реализован "внизу" существующей реализации стека протоколов IP, между обычным IP и локальными сетевыми драйверами. Доступа к исходному коду стека IP в данном контексте не требуется, что делает такой подход пригодным для встраивания в существующие системы. Данный подход обычно реализуется на хостах.
  3. Использование внешнего криптопроцессора (обычно в военных и в некоторых коммерческих системах). Как правило, это является Bump-in-the-stack (BITS) реализацией. Такие реализации могут использоваться как на хостах, так и на шлюзах. Обычно BITS-устройства являются IP-адресуемыми.

Безопасные Ассоциации

Понятие " Безопасные Ассоциации " (Security Association – SA ) является фундаментальным в IPsec.

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

Определения

SA есть совокупность параметров соединения, которые дают возможность сервисам обеспечивать безопасный трафик. SA определяет использование AH или ESP. Если к потоку трафика применяются оба протокола, AH и ESP, то создаются две SA s. При двунаправленном соединении между двумя хостами или между двумя шлюзами безопасности требуется два SA (по одному на каждое направление).

SA однозначно определяется тройкой, состоящей из Security Parameter Index (SPI), IP Destination Address (адресом назначения) и идентификатора протокола безопасности ( AH или ESP ). В принципе адрес назначения может быть единственным адресом, широковещательным (broadcast) адресом или групповым (multicast) адресом. Однако механизм управления SA в настоящее время определяется только для единственной SA. Следовательно, SAs будут описаны в контексте point-to-point соединения, даже если концепция также применяется в случае point-to-multipoint.

Определены два режима SA: режим транспорта и режим туннелирования. Транспортный режим SA обеспечивает безопасную связь между двумя хостами. В IPv4 заголовок протокола безопасности транспортного режима появляется сразу после IP заголовка и всех опций и перед любыми протоколами более высокого уровня (ТСР или UDP). В случае ESP транспортный режим SA обеспечивает сервисы безопасности только для протоколов более высокого уровня, но не для IP-заголовка. В случае AH защита также распространяется на отдельные части IP-заголовка.

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

B туннелирующем режиме SA существует "внешний" IP заголовок, который определяет пункт назначения IPsec, и "внутренний" IP заголовок, который определяет конечный пункт назначения для пакета. Заголовок протокола безопасности расположен после внешнего IP заголовка и перед внутренним IP заголовком. Если AH используется в туннелирующем режиме, части внешнего IP заголовка являются защищенными, как и весь туннелируемый IP пакет, т.е. все внутренние заголовки защищены, как и все протоколы более высокого уровня. Если применяется ESP, защита обеспечивается только для туннелируемого пакета, а не для внешнего IP-заголовка.

Кратко подытожим:

  1. Хост может поддерживать оба режима, как транспортный, так и туннелирующий.
  2. Шлюз безопасности может использовать только туннелирующий режим. Если он поддерживает транспортный режим, то этот режим должен использоваться только тогда, когда безопасный шлюз является хостом, например, для управления сетью.

Функциональности SA

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

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

ESP обеспечивает конфиденциальность трафика. Сила сервиса конфиденциальности зависит от используемого алгоритма шифрования. ESP также может дополнительно обеспечивать аутентификацию. Область аутентификации, обеспечиваемая ESP, является более узкой по сравнению с AH, т.е. IP-заголовок (заголовки), "внешние" по отношению к ESP заголовку, не защищены. Если аутентификация нужна только протоколам более высокого уровня, то аутентификация ESP является подходящей альтернативой, причем более эффективной, чем использование AH, инкапсулирующего ESP. Если для ESP SA используется аутентификация, получатель также может выбрать усиление использованием анти-replay сервиса с теми же самыми возможностями, что и AH анти-replay сервис. Хотя и конфиденциальность, и аутентификация являются необязательными, оба сервиса не могут быть опущены. По крайней мере, один из них должен присутствовать.

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

Комбинации SA

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

Безопасные aссоциации могут комбинироваться в узлы двумя способами: транспортное соседство и повторное туннелирование.

Существует три основных варианта повторного туннелирования:

  1. Оба конца SAs являются одинаковыми – внутренний и внешний туннели могут быть каждый AH или ESP, хотя маловероятно, что протоколы будут одинаковые, например, AH внутри AH или ESP внутри ESP.

    Повторное туннелирование SAs – оба конца одинаковы


    Рис. 23.2.  Повторное туннелирование SAs – оба конца одинаковы

  2. Один конец нескольких SAs является одним и тем же – внутренний и внешний туннели могут оба быть AH или ESP.

    Повторное туннелирование SAs – один конец общий


    Рис. 23.3.  Повторное туннелирование SAs – один конец общий

  3. Ни один из концов нескольких SAs не является одним и тем же – каждый внутренний и внешний туннели могут быть AH или ESP.

    Повторное туннелирование SAs – оба конца разные


    Рис. 23.4.  Повторное туннелирование SAs – оба конца разные

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

Базы данных безопасной ассоциации

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

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

Каждый сетевой интерфейс, для которого необходима обработка IPsec, требует определения баз данных для входящего и исходящего трафика.

БД политики безопасности (SPD)

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

SPD должна рассматриваться при обработке всего трафика (входящего и исходящего), включая не- IPsec трафик. Для того чтобы это поддерживать, SPD требует различных записей для входящего и выходящего трафика. Можно считать, что это отдельные SPDs (входящая и выходящая). Кроме того, отдельная SPD должна существовать для каждого IPsec -интерфейса.

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

Каждая реализация IPsec должна иметь программный интерфейс, который позволяет системному администратору управлять SPD. SPD должна определять, какие действия должны быть выполнены в том или ином случае. Таким образом, программный интерфейс должен позволять специфицировать обработку, применяемую к любому пакету, входящему или выходящему из системы. Интерфейс управления для SPD должен допускать создание последовательности записей, и должна поддерживаться упорядоченность этих записей. Возможно использование символа "*" в различных полях.

Определим стандартный набор элементов SPD, который должны поддерживать все реализации IPsec.

SPD содержит упорядоченный список записей политики. Каждая запись политики является ключом для одного или более селекторов, которые определяют множество IP трафика, соответствующего данной записи политики. Это определяет детализированность политики и создаваемых SAs. Каждая запись включает индикатор, показывающий, что трафик, соответствующий данной политике, должен быть пропущен, отброшен или обработан IPsec . Если применяется обработка IPsec, запись содержит описание SA (или узла SA ), список применяемых протоколов, режимов и алгоритмов, включая любые дополнительные требования. Например, запись может указывать, что трафик защищается ESP в транспортном режиме, используя 3DES-CBC с явным IV, и вложен в AH в туннелирующем режиме с помощью НМАС /SHA-1.

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

Так как политика безопасности может требовать, чтобы более одной SA применялось к трафику в определенной последовательности, запись политики в SPD должна эту последовательность определять.

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

База данных Безопасной Ассоциации (SAD)

В IPsec существует База Данных Безопасных Ассоциаций, в которой каждая запись определяет параметры, связанные с конкретной SA. Соответственно, каждая SA имеет запись в SAD. Для выходящей обработки записи ссылаются на записи в SPD. Для входящей обработки каждая запись в SAD индексируется IP адресом назначения, типом протокола IPsec и SPI. Рассмотрим минимально необходимые элементы данных, требуемые для поддержки SA в реализации IPsec.

Для входящей обработки следующие поля пакета используются для поиска SA в SAD:

Следующие поля SAD используются для IPsec -обработки:

Примеры комбинаций SA

Приведем четыре примера комбинаций SA, которые должны поддерживаться IPsec -хостами и шлюзами безопасности. Дополнительные комбинации AH и/или ESP в туннелирующем и/или транспортном режимах могут поддерживаться по усмотрению разработчиков. Реализации должны иметь возможность создавать и обрабатывать эти четыре комбинации. Введем следующие обозначения:

=-одна или более SA ( AH или ESP, транспорт или туннель);
-соединение (или административная граница);
Нх-хост х;
SGx-шлюз безопасности х;
Х*-Х поддерживает IPsec.

Замечание: рассматриваемые ниже безопасные ассоциации могут быть как AH, так и ESP. Режим (туннель или транспорт) определяется характером конечных точек. Для host-to-host SAs режим может быть как транспортным, так и туннелирующим.

В данном случае как транспортный, так и туннелирующей режим могут быть хостами. Заголовки в пакете между Н1 и Н2 должны выглядеть как в таблице 23.1.



Вариант 1. Обеспечение end-to-end безопасности между двумя хостами через Internet (или intranet)

Таблица 23.1. Последовательность заголовков при соединении Host-Host
TransportTunnel
1. [IP1] [AH] [upper]1. [IP2] [AH] [IP1] [upper]
2. [IP1] [ESP] [upper]2. [IP2] [ESP] [IP1] [upper]
3. [IP1] [AH] [ESP] [upper]



Во втором варианте требуется только туннелирующий режим. При этом заголовки в пакете между SG1 и SG2 должны выглядеть как в таб. 23.2.



Вариант 2. Создание простых виртуальных частных сетей

Таблица 23.2. Последовательность заголовков при соединении SG-SG
Tunnel
1. [IP2] [AH] [IP1] [upper]
2. [IP2] [ESP] [IP1] [upper]



Вариант 3. Комбинация вариантов 1 и 2 путем добавления end-to-end безопасности между хостами отправителя и получателя. Для хостов или шлюзов безопасности не вводится новых требований, кроме требования, чтобы шлюз безопасности был сконфигурирован для прохождения IPsec -трафика (включая ISAKMP трафик) для хостов позади него.

Вариант 4. Рассматривается случай, когда удаленный хост ( Н1 ) использует Internet для достижения firewall'a организации ( SG2 ) и затем получает доступ к некоторому серверу или другой машине ( Н2 ). Удаленный хост может быть мобильным хостом ( Н1 ), подсоединяющимся по dial up к локальному РРР серверу (на диаграмме это не показано) по Internet и затем проходящему по Internet к firewall организации ( SG2 ) и т.д.

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

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

Поддержка дополнительных комбинаций AH и ESP не является обязательной. Дополнительные комбинации могут неблагоприятно сказываться на интероперабельности.

SA и Управление Ключом

IPsec поддерживает как ручные, так и автоматически созданные SA и соответствующее управление криптографическими ключами. Протоколы AH и ESP практически не зависят от используемых технологий управления ключом, хотя эти технологии могут некоторым образом влиять на сервисы безопасности, предоставляемые протоколами. Например, дополнительные anti-replay сервисы требуют автоматического управления SA. Более того, детализированность используемого распределения ключа определяет детализированность предоставляемой аутентификации.

Ручные технологии

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

Автоматические SA и Управление Ключом

Широкое использование IPsec требует стандартного для Internet, масштабируемого, автоматического протокола управления SA. Такая поддержка необходима для использования anti-replay возможностей AH и ESP и для возможности создания SAs.

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

Проблемы выполнения

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

Использование IPsec также увеличивает стоимость компонентов, осуществляющих пересылку и роутинг в инфраструктуре Internet, но не реализующих IPsec. Это происходит из-за возрастания размера пакета в результате добавления заголовков AH и/или ESP, AH и ESP туннелирования (который добавляет второй IP-заголовок) и возрастании трафика, связанного с протоколами управления ключом. Ожидается, что в большинстве примеров это возрастание не будет сильно влиять на инфраструктуру Internet.

Лекция 12. Архитектура безопасности для IP (часть 2)

Рассматривается Безопасная Ассоциация Internet и Протокол Управления Ключом (ISAKMP), который определяет общие процедуры и форматы пакетов для ведения переговоров об установлении, изменении и удалении SA. В качестве протокола аутентификации и обмена ключа рассмотрен протокол IKE.

Internet Security Association and Key Management Protocol (ISAKMP)

Введение

Рассмотрим Безопасную Ассоциацию Internet и Протокол Управления Ключом ( ISAKMP ). ISAKMP определяет общие процедуры и форматы пакетов для ведения переговоров об установлении, изменении и удалении SA. SAs содержат всю информацию, необходимую для выполнения различных сетевых сервисов безопасности. ISAKMP определяет содержимое обменов для создания ключей и аутентификации участников. Эти форматы обеспечивают взаимосогласованную основу для передаваемого ключа и аутентификационных данных, которая не зависит от технологии создания ключа, алгоритма шифрования и механизма аутентификации.

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

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

ISAKMP обеспечивает полную безопасность последующих обменов (Perfect Forward SecrecyPFS) – это означает, что при компрометации одного ключа возможен только доступ к данным, защищенным одним этим ключом. При PFS ключ, используемый для защиты передаваемых данных, не должен использоваться для получения любых дополнительных ключей, и если ключ, используемый для защиты передаваемых данных, был получен из некоторого другого ключевого материала, то этот ключевой материал не должен больше использоваться для получения других ключей.

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

Защита от DoS-атак является одной из наиболее трудных задач. Для этой цели в ISAKMP используются "Cookie" или знак анти-препятствия (anti-clogging token – ACT), которые предназначены для защиты вычислительных ресурсов от подобной атаки без расходования собственных ресурсов на ее обнаружение. Абсолютная защита от отказа в сервисе невозможна, но такой знак анти-препятствия предоставляет технологию для того, чтобы сделать защиту более надежной.

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

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

Атаки man-in-the-middle включают перехват, вставку, уничтожение и модификацию сообщений, отправку сообщений назад отправителю, повтор старых сообщений и перенаправление сообщений. ISAKMP предупреждает все эти типы атак. Объединение сообщений ISAKMP защищает от возможности встроить сообщения в обмены протокола. Протокол ISAKMP позволяет хосту обнаружить уничтоженные сообщения. Требование наличия нового cookie с новой отметкой времени для каждого нового установления SA предотвращает атаки, которые включают повтор старых сообщений. Требование ISAKMP сильной аутентификации предотвращает установление SA с кем-то, кроме заданного участника. Сообщения можно перенаправить к другому получателю или модифицировать, но это будет обнаружено, и SA установлена не будет.

Основные концепции

Терминология ISAKMP

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

Набор защиты: набор защиты является списком сервисов безопасности, которые могут быть применены к различным протоколам безопасности. Например, набор защиты может состоять из DES шифрования для ESP и MD5 с ключом для AH.

Безопасная ассоциация (SA): безопасная ассоциация определяет протокол безопасности и конкретный набор параметров сервисов и механизмов, необходимых для защиты трафика. Эти параметры могут включать идентификаторы алгоритмов, режимы, криптографические ключи и т.д. SA ссылается на связанный с ней протокол безопасности (например, "ISAKMP SA", "ESP SA").

ISAKMP SA: SA используется ISAKMP для обеспечения защиты собственного трафика.

Domain of Interpretation: Domain of Interpretation ( DOI ) определяет форматы содержимого, типы обменов и соглашения по именованию информации, относящейся к безопасности, такой как политики безопасности или криптографические алгоритмы и режимы. Идентификатор DOI используется для интерпретации содержимого ISAKMP. DOI определяет:

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

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

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

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

Фазы переговоров

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

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

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

Во-первых, ISAKMP серверы могут уменьшить время установления первой фазы до нескольких секунд. Это позволяет устанавливать несколько SAs между двумя участниками за одно и то же время с начала соединения.

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

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

Идентификация Безопасных Ассоциаций

Хотя при установлении безопасных каналов между системами ISAKMP не может предполагать существования сервисов безопасности, должна обеспечиваться некоторая степень защиты. Следовательно, SA ISAKMP отличается от остальных типов SA, и ее идентификация отличается от идентификации других типов SA. ISAKMP использует два поля cookie в заголовке ISAKMP для идентификации ISAKMP SAs. Message ID в ISAKMP Header и поле SPI в Proposal payload используются при установлении SA для идентификации SA других протоколов безопасности.

В приведенной ниже таблице показано наличие или отсутствие определенных полей при установлении SA. Следующие поля необходимы для различных операций, связанных с установлением SA: cookies в заголовке ISAKMP, поле Message ID в заголовке ISAKMP, поле SPI в Proposal payload. "X" в столбце означает, что значение должно присутствовать. "NA" в столбце означает, что значение в операции не применяется.

Таблица 24.1. Поля при установлении SA
ОперацияI-CookieR-CookieMessage IDSPI
1. Начало ISAKMP SA переговоровX000
2. Ответ ISAKMP SA переговоровXX00
3. Инициализация других SA переговоровХХХХ
4. Ответ других переговоров SAХХХХ
5. Другое (КЕ, ID и т.д.)ХХХ/0NA
6. Протокол безопасности (ESP, AH)NANANAX

Первая строка таблицы говорит о том, что инициатор включает поле Initiator Cookie в ISAKMP Header.

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

В течение первой фазы переговоров cookies инициатора и получателя определяют ISAKMP SA. Следовательно, поле SPI в Proposal payload избыточно и может быть установлено в 0 или может содержать cookie передаваемых сущностей.

Третья строчка таблицы говорит о том, что инициатор связывает Message ID с Protocols, содержащимися в SA Proposal. Это Message ID и SPI (s) инициатора связываются с каждым протоколом в Proposal и посылаются получателю. SPI (s) будут использоваться в протоколах безопасности сразу после завершения второй фазы переговоров.

В четвертой строке таблицы получатель включает тот же самый Message ID, и SPI (s) получателя связываются с каждым протоколом в принимаемом Proposal. Эта информация возвращается инициатору.

Пятая строка таблицы говорит о том, что инициатор и получатель используют поле Message ID в ISAKMP Header для отслеживания выполнения протокола переговоров. Это применяется на второй фазе обмена, и значение должно быть 0 для первой фазы обмена, потому что комбинированные cookies определяют ISAKMP SA. Поле SPI в Proposal payload не применяется, потому что Proposal payload используется только на протяжении обмена сообщениями переговоров SA (шаги 3 и 4).

В шестой строке таблицы фаза 2 переговоров завершается.

При установлении SA должно создаваться SPI. ISAKMP предполагает применение SPIs различных размеров. Это достигается путем использования поля SPI Size в Proposal payload при установлении SA.

При начальном установлении SA одна из сторон выступает в роли инициатора, а другая – в роли получателя. После того как SA установлена, как инициатор, так и получатель могут начать вторую фазу переговоров с противоположной сущностью. Таким образом, ISAKMP SAs по своей природе являются двунаправленными.

Дополнительные определения и понятия
Создание Token анти-препятствия ("Cookie")

Детали создания cookie зависят от реализации, но в целом должны выполняться следующие основные требования:

Кэрн (Karn) предложил метод создания cookie, основанный на выполнении быстрого хэша (например, MD5) над IP-адресами источника и получателя, портов UDP источника и получателя и локально созданного секретного случайного значения. ISAKMP требует, чтобы cookie были уникальными для каждой устанавливаемой SA для того, чтобы предотвратить replay-атаки и, следовательно, в хэшируемую информацию должны добавляться значения даты и времени. Созданные cookie помещаются в заголовок ISAKMP инициатора и получателя. Эти поля имеют длину 8 октетов, таким образом, создаваемые cookie должны быть длиной 8 октетов.

Содержимые ISAKMP

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

Формат заголовка ISAKMP

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

Поля заголовка ISAKMP определяются следующим образом:

Формат заголовка ISAKMP


Рис. 24.1.  Формат заголовка ISAKMP

Таблица 24.2. Типы содержимого
Тип Next PayloadЗначение
None0
Security Association (SA)1
Proposal (P)2
Transform (T)3
Key Exchange (KE)4
Identification (ID)5
Certificate (CERT)6
Certificate Request (CR)7
Hash (HASH)8
Signature (SIG)9
Nonce (NONCE)10
Notification (N)11
Delete (D)12
Vendor ID (VID)13
RESERED14 – 127
Private USE128 – 255
Таблица 24.3. Типы обменов
Тип обменаЗначение
NONE0
Base1
Identity Protection2
Authentication Only3
Aggressive4
Informational5
ISAKMP Future Use6 – 31
DOI Specific Use32 – 239
Private Use240 – 255
Общий заголовок содержимого

Каждое содержимое ISAKMP, определяемое далее, начинается с общего заголовка, показанного на рис. 24.2, который обеспечивает возможность "связывания" содержимых и позволяет явно определять границы содержимого.

Поля общего заголовка содержимого определяются следующим образом:

Общий заголовок содержимого


Рис. 24.2.  Общий заголовок содержимого

Атрибуты данных

Существует несколько случаев в ISAKMP, когда должны быть представлены атрибуты данных. Примером могут служить атрибуты SA, содержащиеся в Transform payload. Эти атрибуты данных не являются самостоятельным содержимым ISAKMP, а представляют собой часть некоторого содержимого. Формат атрибутов данных обеспечивает гибкость представления различных типов информации. В содержимом может существовать много атрибутов данных. Длина атрибутов данных или равна 4 октетам, или определяется полем Attribute Length. Это определяется битом формата атрибута, описанным ниже.

Поля атрибутов данных определяются следующим образом:

Атрибуты данных


Рис. 24.3.  Атрибуты данных

Бит Attribute Format ( AF ) указывает, будут ли атрибуты данных определяться форматом Type/Length/Value ( TLV ) или короткой формой формата Type/Value ( TV ). Если бит AF = 0, то атрибуты данных имеют форму TLV. Если бит AF = 1, то атрибуты данных имеют форму TV.

Содержимое SA

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

Содержимое SA


Рис. 24.4.  Содержимое SA

Содержимое Proposal

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

Формат Proposal Payload


Рис. 24.5.  Формат Proposal Payload

Поля Proposal Payload определяются следующим образом:

Тип содержимого для Proposal Payload равен 2.

Содержимое Transform

Transform Payload содержит информацию, используемую SA при переговорах. Transform Payload состоит из конкретных механизмов безопасности, или преобразований, которые используются для обеспечения безопасности информационного канала. Transform Payload также содержит атрибуты SA, связанные с конкретным преобразованием. Эти атрибуты SA определяются DOI. На рис. 24.6 показан формат Transform Payload.

Формат Transform Payload


Рис. 24.6.  Формат Transform Payload

Поля Transform Payload определяются следующим образом:

Тип полезной информации для Transform Payload есть 3.

Содержимое Key Exchange

Key Exchange Payload поддерживает различные технологии обмена ключа. Примерами обменов ключа являются Oakley, Diffie-Hellman, расширенный обмен ключа Diffie-Hellman, описанный в Х9.42, и обмен ключа на основе RSA, используемый в PGP. На рис. 24.7 показан формат Key Exchange рayload.

Формат Key Exchange Payload


Рис. 24.7.  Формат Key Exchange Payload

Поля Key Exchange Payload определяются следующим образом:

Тип полезной информации для Key Exchange Payload есть 4.v

Содержимое Identification

Identification Payload содержит данные, используемые при обмене идентификационной информацией.

Формат Identification Payload


Рис. 24.8.  Формат Identification Payload

Поля Identification Payload определяются следующим образом:

Тип полезной информации для Identification Payload есть 5.

Содержимое Certificate

Certificate Payload обеспечивает способ передачи сертификатов или другой информации, относящейся к сертификатам, с помощью ISAKMP и может появляться в любом сообщении ISAKMP. На рис. 24.9 показан формат Certificate Payload.

Формат Certificate Payload


Рис. 24.9.  Формат Certificate Payload

Поля Certificate Payload определяются следующим образом:

Тип содержимого для Certificate Payload есть 6.

Содержимое Certificate Request

Certificate Request Payload обеспечивает значение для запроса сертификатов с помощью ISAKMP и может появиться в любом сообщении. Certificate Request рayload должен приниматься в любой точке обмена. Получатель Certificate Request рayload должен послать свой сертификат. Если требуется несколько сертификатов, то должны передаваться несколько Certificate Request рayloads. На рис. 24.10 показан формат Certificate Request Payload.

Формат Сertificate Request Payload


Рис. 24.10.  Формат Сertificate Request Payload

Поля Certificate Payload определяются следующим образом:

Тип содержимого для Certificate Request Payload есть 7.

Содержимое HASH

Hash Payload содержит данные, создаваемые хэш-функцией (определенной во время обмена при установлении SA), для некоторой части сообщения и/или состояния ISAKMP. Данное содержимое может использоваться для проверки целостности данных в ISAKMP -сообщении или для аутентификации сущностей, ведущих переговоры. На рис. 24.11 показан формат Hash Payload.

Формат HASH Payload


Рис. 24.11.  Формат HASH Payload

Поля Hash Payload определяются следующим образом:

Содержимое Signature

Signature Payload содержит данные, созданные функцией цифровой подписи (выбранной при обмене во время установления SA) для определенной части сообщения и/или ISAKMP -состояния. Данное содержимое используется для проверки целостности данных в ISAKMP - сообщении, и может быть использовано для сервисов невозможности отказа. На рис. 24.12 показан формат Signature Payload.

Формат Signature Payload


Рис. 24.12.  Формат Signature Payload

Поля Signature Payload определяются следующим образом:

Тип содержимого для Signature Payload есть 9.

Содержимое Nonce

Nonce Payload содержит случайные данные, используемые для гарантии своевременности обмена и отсутствия replay-атак. На рис. 24.13 показан формат Nonce Payload. Если nonces используются в конкретном обмене ключа, то применение Nonce рayload определяется обменом ключа. Nonces могут передаваться как часть данных обмена ключа или как отдельное содержимое. Это, однако, определяется обменом ключа, а не ISAKMP.

Формат Nonce Payload


Рис. 24.13.  Формат Nonce Payload

Поля Nonce Payload определяются следующим образом:

Тип содержимого для Nonce Payload есть 10.

Содержимое Notification

Notification Payload может содержать как определяемые ISAKMP, так и определяемые DOI данные и использоваться при передаче информационных данных, таких как ошибочные условия. Можно послать несколько Notification Payload в одном сообщении ISAKMP. На рис. 24.14 показан формат Notification Payload.

Формат Notification Data


Рис. 24.14.  Формат Notification Data

Notification, которые возникают на Фазе 1 переговоров, идентифицируются парой cookie Инициатора и Получателя в заголовке ISAKMP. Идентификатором протокола в данном случае является ISAKMP, и значение SPI есть 0, потому что пара cookie в заголовке ISAKMP идентифицирует ISAKMP SA. Если notification имеет место перед завершением обмена ключевой информацией, то она не будет защищена.

Notification, которые возникают во время Фазы 2 переговоров, определяются парой cookie Инициатора и Получателя в заголовке ISAKMP, и Message ID и SPI связаны с текущими переговорами.

Поля Notification Data определяются следующим образом:

Тип содержимого для Notification Payload есть 11.

Содержимое Delete

Delete Payload содержит идентификатор SA которую отправитель удаляет из своей БД SA и которая, следовательно, более не доступна. На рис. 24.15 показан формат Delete Payload. Возможна посылка нескольких SPIs в Delete Payload, однако каждый SPI должен быть предназначен для того же самого протокола.

Формат Delete Payload


Рис. 24.15.  Формат Delete Payload

Удаление, которое относится к ISAKMP SA, содержит Protocol-Id для ISAKMP, и SPIs есть cookies отправителя и получателя из заголовка ISAKMP. Удаление, которое имеет дело с Protocol SA, такими как ESP или АН, будет содержать Protocol-Id протокола (т.е. ESP, AH), и SPI есть SPI(s) посылающей сущности.

Поля Delete Payload определены следующим образом:

Тип содержимого для Delete Payload есть 12.

Содержимое Vendor ID

Vendor ID Payload содержит константу, определяющую разработчика. Данная константа используется разработчиком для собственной идентификации и удаленной сущностью для распознавания разработчика. Данный механизм позволяет разработчику экспериментировать с новыми возможностями, сохраняя обратную совместимость. На рис. 24.16 показан формат Vendor ID Payload.

Формат Vendor ID Payload


Рис. 24.16.  Формат Vendor ID Payload

Поля Vendor ID Payload определяются следующим образом:

Тип содержимого Vendor ID есть 13.

Internet Key Exchange (IKE)

Используемая нотация

Используются следующие нотации.

HDR – это заголовок ISAKMP, который определяет тип обмена. Запись HDR* означает, что содержимое зашифровано.

SA – это содержимое переговоров SA с одним или более Proposals. Инициатор может предоставить несколько Proposals для переговоров; получатель должен выбрать только одну.

<P>_b – это тело содержимого <P>. Например, SA_b есть все тело содержимого SA (минус общий заголовок ISAKMP ), т.е. DOI, Situation, все Proposals и все Transforms, представленные Инициатором.

CKY-I и CKY-R есть cookie Инициатора и cookie Получателя, соответственно, из ISAKMP -заголовка.

g^x i и g^xr – это открытые значения Диффи-Хеллмана Инициатора и Получателя соответственно.

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

Nx – это содержимое nonce; x может быть i или r для ISAKMP Инициатора и Получателя соответственно.

IDx – есть содержимое идентификации для "х". Х может быть "ii" или "ir" для ISAKMP Инициатора и Получателя соответственно во время Фазы 1 переговоров ; или "ui" или "ur" для Инициатора и Получателя соответственно во время Фазы 2.

SIG – это содержимое подписи. Подписываемые данные зависят от обмена.

СERT – это содержимое сертификата.

HASH – это содержимое хэша, которое определяется методом аутентификации.

prf (key, msg) – это псевдослучайная функция, часто хэш-функция, основанная на ключе, используемая для создания детерминированного выхода, который можно рассматривать как псевдослучайный. Prf используется как для получения ключа, так и для аутентификации (т.е. как МАС с ключом).

SKEYID есть строка, полученная из секрета и известная только участникам обмена.

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

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

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

<x>y определяет, что х зашифровано ключом y.

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

указывает на направление взаимодействия от Получателя к Инициатору (ответ).

| обозначает конкатенацию информации.

[x] обозначает, что х не является обязательным.

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

Введение

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

В течение Фазы 1 участники устанавливают безопасный аутентифицированный канал, по которому они будут взаимодействовать. Это называется ISAKMP SA. Для фазы 1 определено два режима: Main Mode и Aggressive Mode.

Фаза 2 определяется тогда, когда уже установлены ISAKMP SA. "Quick Mode" определен для второй фазы обмена.

"New Group Mode" реально ни с Фазой 1, ни с Фазой 2 не связан. Он следует за Фазой 1, но служит для установления новой группы, которая может использоваться при будущих переговорах.

ISAKMP SA является двунаправленной. Это означает, что установив однажды, каждый участник может инициировать Quick Mode, Informational и New Group Mode-обмены. ISAKMP SA идентифицируется cookie Инициатора, которые следуют за cookie Получателя – роли каждого участника в Фазе 1 обмена определяют, какие cookie являются cookie Инициатора. Последовательность cookie, установленная в Фазе 1 обмена, продолжает идентификацию ISAKMP SA, независимо от направления обменов Quick Mode, Informational или New Group. Другими словами, cookie при изменении направления ISAKMP SA не должны меняться местами.

В результате использования фаз ISAKMP может выполнять обмен ключа достаточно быстро. Кроме того, может требоваться единственная фаза 2 переговоров для создания нескольких SAs. Main Mode для Фазы 1 обеспечивает защиту идентификации. Когда нет необходимости в защите идентификации, может использоваться Aggressive Mode для уменьшения числа взаимных передач. Также следует заметить, что при аутентификации шифрованием с открытым ключом в Aggressive Mode также обеспечивается защита идентификации.

Следующие атрибуты используются в IKE и о них договариваются участники ISAKMP SA. (Эти атрибуты принадлежат только ISAKMP SA, а не каким-то другим Безопасным Ассоциациям, для которых ISAKMP может вести переговоры от имени других сервисов.)

Все эти атрибуты обязательны, и о них должны вестись переговоры. Кроме того, возможны дополнительные переговоры о псевдослучайной функции ("prf"). Если prf в переговорах не участвует, то версия HMAC хэш-алгоритма, о котором договорились, используется в качестве псевдослучайной функции.

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

Обмены

Существует два основных режима, используемых для установления аутентифицированного обмена ключа: Main Mode и Aggressive Mode. Каждый из них создает аутентифицированный ключевой материал из обмена Диффи-Хеллмана. Обязательно должен быть реализован Main Mode. Кроме того, Quick Mode должен быть реализован в качестве механизма для создания нового материала ключа и переговоров не-ISAKMP SA (т.е. AH SA и ESP SA). В дополнение к этому New Group Mode может быть реализован в качестве механизма определения частных групп для обменов Диффи-Хеллмана.

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

Открытое значение Диффи-Хеллмана передается в содержимом КЕ в Фазе 1, оно может передаваться в Фазе 2 обмена, если требуется PFS. Длина открытого значения Диффи-Хеллмана определяется во время переговоров.

Длина содержимого nonce колеблется между 8 и 256 байтами.

Main Mode является реализацией обмена с защищенной идентификацией: в первых двух сообщениях договариваются о политике; в следующих двух сообщениях обмениваются открытыми значениями Диффи-Хеллмана и вспомогательными данными (т.е. nonces), необходимыми для обмена; последние два сообщения аутентифицируют обмен Диффи-Хеллмана. Метод аутентификации является частью переговоров начального ISAKMP -обмена, влияющий на композицию содержимых, но не на их цель.

В первых двух сообщениях Aggressive Mode договариваются о политике, обмениваются открытыми значениями Диффи-Хеллмана и вспомогательными данными, необходимыми для обмена, а также идентификациями. Второе сообщение аутентифицирует получателя. Третье сообщение аутентифицирует инициатора. Заключительное сообщение может не посылаться по ISAKMP SA, позволяя каждому участнику откладывать в случае необходимости вычисление экспоненты до завершения переговоров.

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

Допускаются четыре различных метода аутентификации как для Main Mode, так и для Aggressive Mode – цифровая подпись, две формы аутентификации шифрованием открытым ключом и предварительно распределенным секретом. Значение SKEYID вычисляется отдельно для каждого метода аутентификации.

Для подписей:

SKEYID = prf (Ni_b | Nr_b, g^xy)

Для шифрования открытым ключом:

SKEYID = prf ( HASH (Ni_b | Nr_b), CKY-I | CKY-R)

Для предварительно распределенного секрета:

SKEYID = prf (pre-shared-key, Ni_b | Nr_b)

Результатом как Main Mode, так и Aggressive Mode являются три группы аутентифицированного материала ключа:

SKEYID_d = prf (SKEYID, g^xy | CKY-I | CKY-R | 0)

SKEYID_a = prf (SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)

SKEYID_e = prf (SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)

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

Для аутентификации обмена инициатора протокола создается HASH _I и для получателя создается HASH _R, где

HASH_I = prf (SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b)

HASH_R = prf (SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b)

При аутентификации с помощью цифровых подписей HASH _I и HASH _R подписаны и верифицированы; при аутентификации либо шифрованием открытым ключом, либо pre-shared ключами HASH_I и HASH_R непосредственно аутентифицируют обмен. Все содержимое ID (включая тип ID, порт и протокол, но исключая общий заголовок) хэшировано как в HASH_I, так и в HASH_R.

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

IKE Фаза 1 с аутентификацией с помощью подписей

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

Main Mode с аутентификацией с помощью подписи


Рис. 24.17.  Main Mode с аутентификацией с помощью подписи

Aggressive Mode с аутентификацией с помощью подписи выполняется согласно рис.24.18.

Aggressive Mode с аутентификацией с помощью подписи


Рис. 24.18.  Aggressive Mode с аутентификацией с помощью подписи

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

В общем случае подпись выполняется поверх HASH_I и HASH_R, при этом используется prf или версия НМАС для хэш-функции (если участники не договорились о prf).

Могут быть дополнительно переданы один или более сертификатов.

Фаза 1 аутентификации шифрованием открытым ключом

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

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

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

При использовании для аутентификации шифрования Main Mode выполняется согласно рис.24.19.

Аутентификация шифрования Main Mode


Рис. 24.19.  Аутентификация шифрования Main Mode

Aggressive Mode выполняется согласно рис.24.20.

Где HASH (1) есть хэш сертификата, который инициатор использовал для шифрования nonce и идентификации.

Использование шифрования для аутентификации обеспечивает невозможность отказа от обмена.

Заметим, что в отличие от других методов аутентификации, аутентификация шифрованием открытым ключом допускает защиту идентификации в Aggressive Mode.

Аутентификация шифрования Aggressive Mode


Рис. 24.20.  Аутентификация шифрования Aggressive Mode

Фаза 1 аутентификации с Revised Mode шифрования открытым ключом

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

В данном режиме nonce все еще зашифрован с использованием открытого ключа противоположной стороны, однако идентификация противоположной стороны (и сертификат, если он послан) шифруется с использованием алгоритма симметричного шифрования, о котором договорились (из содержимого SA) с ключом, полученным из nonce. Это решение добавляет минимальную сложность, и на каждой стороне используется две операции открытого ключа. Дополнительно содержимое Key Exchange также зашифровано с использованием того же самого ключа. Это обеспечивает дополнительную защиту против криптоанализа обмена Диффи-Хеллмана.

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

При использовании для аутентификации пересмотренного режима шифрования Main Mode определяется согласно рис.24.21.

Аутентификация пересмотренного режима шифрования Main Mode


Рис. 24.21.  Аутентификация пересмотренного режима шифрования Main Mode

Aggressive Mode, аутентифицируемый с помощью пересмотренного метода шифрования, определяется согласно рис.24.22.

Аутентификация пересмотренного режима шифрования Aggressive Mode


Рис. 24.22.  Аутентификация пересмотренного режима шифрования Aggressive Mode

Где HASH (1) была определена выше. Ke_i и Ke_r являются ключами для алгоритма симметричного шифрования, о котором участники договорились при обмене содержимом SA. Шифруется только тело содержимых (как в операциях с открытым ключом, так и симметричного шифрования), общие заголовки содержимого не шифруются.

Симметричные ключи шифрования получаются из дешифрованных nonces следующим образом. Прежде всего вычисляются значения Ne_i и Ne_r:

Ne_i = prf (Ni_b, CKY-I)

Ne_r = prf (Nr_b, CKY-R)

Если длина выхода prf, о которой договорились, больше или равна длине ключа, необходимой для шифрования, Ke_i и Ke_r получаются из старших битов Ne_i и Ne_r, соответственно. Если требуемая длина Ke_i и Ke_r превышает длину выхода prf, необходимое количество битов получается после повторным применением prf и конкатенацией результата необходимое число раз. Например, если алгоритм шифрования требует 320 битов ключа и выход prf дает только 128 бит, в качестве Ke_i берутся старшие биты K, где

K = K1 | K2 | K3

K1 = prf (Ne_i, 0)

K2 = prf (Ne_i, K1)

K3 = prf (Ne_i, K2)

Для краткости показано получение только Ke_i ; Ke_r получается аналогично. Значение 0 при вычислении K1 является одним октетом. Заметим, что Ne_i, Ne_r, Ke_i и Ke_r после использования должны быть сброшены.

Существуют требования только на размещение дополнительного содержимого HASH и обязательного содержимого nonce, более никаких содержимых не требуется. Все содержимые – в любом порядке – следующие за зашифрованным nonce, должны быть зашифрованы с ключом Ke_i или Ke_r в зависимости от направления.

Фаза 1 аутентификации с Pre-Shared ключом

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

Когда выполняется pre-shared аутентификация, Main Mode определяется согласно рис.24.23.

Определение Main Mode при выполнении pre-shared аутентификации


Рис. 24.23.  Определение Main Mode при выполнении pre-shared аутентификации

Aggressive режим с pre-shared ключом описывается согласно рис.24.24.

При использовании аутентификации с pre-shared ключом с Main Mode ключ может только идентифицироваться по IP-адресу противоположной стороны, так как HASH_I должен быть вычислен до того, как инициатор обработает IDir. Aggressive Mode охватывает более широкий диапазон идентификаторов используемого pre-shared секрета. Дополнительно Aggressive Mode позволяет двум участникам поддерживать несколько различных pre-shared ключей и идентификаций для отдельного обмена.

Определение Aggressive Mode при выполнении pre-shared аутентификации


Рис. 24.24.  Определение Aggressive Mode при выполнении pre-shared аутентификации

Фаза 2 – Quick Mode

Quick Mode сам по себе законченным обменом не является (это означает, что он связан с фазой 1 обмена), он используется как часть процесса переговоров SA (фаза 2) для получения материала ключа и обсуждений разделяемой политики для не-ISAKMP SAs. Информация, которой обмениваются в Quick Mode, должна быть защищена ISAKMP SA, т.е. все содержимые за исключением заголовка ISAKMP должны быть зашифрованы. В Quick Mode содержимое HASH должно непосредственно следовать за заголовком ISAKMP и содержимое SA должно непосредственно следовать за HASH. Данный HASH аутентифицирует сообщение и обеспечивает доказательство существования.

Quick Mode проводит переговоры об SA и обменивается nonces, которые обеспечивают защиту от повторов. Nonces используются для создания нового материала ключа и предотвращения replay-атак, создающих ложные SA. Можно произвести обмен дополнительным содержимым KE, чтобы допустить дополнительный обмен экспонентами Диффи-Хеллмана при Quick Mode.

Базовый Quick Mode (без содержимого KE ) обновляет материал ключа, полученный из экспоненты в Фазе 1. Это не обеспечивает PFS. При использовании дополнительного содержимого KE вычисляется дополнительная экспонента и тем самым обеспечивается PFS для материала ключа.

Все предложения, сделанные в течение Quick Mode, являются логически взаимосвязанными и должны быть согласованы. Например, если послано содержимое KE, атрибут, описывающий группу Диффи-Хеллмана, должен быть включен в каждый Transform каждой Proposal каждой SA, о которой ведутся переговоры. Аналогично, если используются идентификации клиента, они должны применяться к каждой SA, о которой ведутся переговоры.

Quick Mode определяется согласно рис.24.25.

Определение Quick Mode


Рис. 24.25.  Определение Quick Mode

Где:

HASH (1) есть prf поверх сообщения id (M-ID) из ISAKMP заголовка, присоединенного ко всему сообщению.

HASH (2) идентичен HASH (1) за исключением nonce инициатора – Ni, минус заголовок содержимого – который добавляется после M-ID, но перед завершенным сообщением. Добавление nonce в HASH (2) сделано для доказательства существования.

HASH (3) – для доказательства существования – является prf поверх нулевого значения, представленного одним октетом, за которым следует конкатенация id сообщения и два nonces – инициатора и получателя – минус заголовок содержимого. Другими словами, хэши предыдущего обмена есть:

HASH (1) = prf (SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr ])

HASH (2) = prf (SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci | IDcr ])

HASH (3) = prf (SKEYID_a, 0 | M-ID | Ni_b | Nr_b)

За исключением содержимых HASH, SA и необязательных ID, не существует содержимых, для которых определены ограничения упорядоченности в Quick Mode. HASH (1) и HASH (2) могут отличаться от приведенных выше, если порядок содержимых в сообщении отличается от приведенного выше или если в сообщение включены дополнительные содержимые.

Если PFS не является необходимой и обмен содержимым KE не выполняется, то новый материал ключа определяется как

KEYMAT = prf (SKEYID_d, protocol | SPI | Ni_b | Nr_b)

Если PFS требуется и участники обмениваются содержимым KE, то новый материал ключа определяется как

KEYMAT = prf (SKEYID_d, g (qm) ^xy | protocol | SPI | Ni_b | Nr_b)

Где g (qm) ^xy является разделяемым секретом из одноразового обмена Диффи-Хеллмана для данного Quick Mode.

В любом случае protocol и SPI берутся из ISAKMP Proposal Payload, содержащим Transform, о котором договариваются.

Единственным результатом переговоров SA являются две безопасные ассоциации – одна входящая и одна выходящая. Различные SPIs для каждой SA (один выбирается инициатором, другой получателем) гарантируют различные ключи для каждого направления. SPI, выбираемые получателем, используются для получения KEYMAT для данной SA.

В ситуации, когда количество требуемого материала ключа больше, чем предлагается prf, KEYMAT расширяется конкатенацией результатов до тех пор, пока не будет получено необходимое количество материала ключа. Другими словами

KEYMAT = K1 | K2 | K3 | ѕ

Где

K1 = prf (SKEYID_d, [g (qm) ^xy | ] protocol | SPI | Ni_b | Nr_b)

K2 = prf (SKEYID_d, K1 | [g (qm) ^xy | ] protocol | SPI | Ni_b | Nr_b)

K3 = prf (SKEYID_d, K2 | [g (qm) ^xy | ] protocol | SPI | Ni_b | Nr_b)

Данный материал ключа (с PFS или без, полученный непосредственно или с помощью конкатенации) должен использоваться в SA, о которой ведутся переговоры. Это определяет ключи, которые получаются из материала ключа.

Используя Quick Mode, за один обмен можно договориться о нескольких SAs и ключах согласно рис.24.26.

Определение SAs и ключей при использовании Quick Mode


Рис. 24.26.  Определение SAs и ключей при использовании Quick Mode

New Group Mode

New Group Mode не должен использоваться до установления ISAKMP SA. Описание новой группы должно следовать только за фазой 1 переговоров. (Однако это не фаза 2 обмена).

Где HASH (1) является выходом prf с использованием SKEYID_a в качестве ключа, и message-ID из заголовка ISAKMP, присоединенного ко всему SA proposal, как телу, так и заголовку; HASH (2) есть выход prf с использованием SKEYID_a в качестве ключа, и message-ID из заголовка ISAKMP, присоединенного к ответу. Другими словами, хэшами для обменов являются:

HASH (1) = prf (SKEYID_a, M-id | SA )

HASH (2) = prf (SKEYID_a, M-id | SA)

Proposal определяется характеристиками группы. Описания группы для частных групп должны быть больше или равны 215. Если группа не принимается, получатель должен ответить сообщением с содержимым Notify, и тип сообщения установить в ATTRIBUTE-NOT-SUPPORTED (13).

Реализации ISAKMP могут требовать частных групп для устанавливаемых SA.

О группах можно непосредственно договариваться в SA Proposal в Main Mode. Чтобы это сделать, компоненты – MODP группы, тип, простое и генератор; тип для EC2N группы, несократимый полином, генератор группы One, генератор группы Two, группа эллиптической кривой А, группа эллиптической кривой В и порядок группы – передаются в качестве атрибутов SA.

Информационные обмены ISAKMP

Данный протокол, когда это возможно, защищает информационные обмены ISAKMP. После того как безопасная ассоциация ISAKMP установлена (и SKEYID_e и SKEYID_a созданы) информационные обмены ISAKMP при использовании данного протокола представляют собой следующее:

Где N/D есть либо ISAKMP Notify Payload, либо ISAKMP Delete Payload и HASH (1) есть выход prf с использованием SKEYID_a в качестве ключа, и M-ID, уникальный для данного обмена, присоединяется в качестве данных ко всему информационному содержимому (либо Notify, либо Delete). Другими словами, хэшем для предыдущего обмена является:

HASH (1) = prf (SKEYID_a, M-ID | N/D)

Как уже было замечено, ID сообщения в заголовке ISAKMP – и используемые в prf вычисления – являются уникальными для данного обмена и не должны повторять ID сообщения для другой фазы 2 обмена, во время которой был создан данный информационный обмен.

Если безопасная ассоциация ISAKMP ко времени информационного обмена еще не установлена, обмен выполняется в явном виде без сопутствующего HASH содержимого.



Обсуждение проблем безопасности

Сила ключа, полученная из обмена Диффи-Хеллмана, использующего определенную группу, зависит от силы самой группы, используемой длины экспоненты и энтропии, обеспечиваемой используемым генератором случайных чисел. Группа Диффи-Хеллмана по умолчанию (номер один) при использовании сильного генератора случайных чисел и экспоненты не менее 160 бит является достаточной при использовании для DES. Группы со второй по четвертую обеспечивают большую безопасность. Реализации должны помнить об этой общей оценке при определении политики и обсуждаемых параметрах безопасности.

Заметим, что это не является ограничением на сами группы Диффи-Хеллмана. Ничто не препятствует IKE использовать более сильные группы и ничто не ослабляет силу этих групп. Действительно, расширяемый каркас IKE поддерживает определение многих групп; использование групп эллиптических кривых увеличивает силу при использовании меньших чисел.

В ситуациях, когда определенные группы не обеспечивают необходимую силу, можно использовать New Group Mode для обмена группой Диффи-Хеллмана, которая обеспечит ее.

Предполагается, что экспоненты Диффи-Хеллмана для данного обмена после использования удаляются из памяти. В частности, эти экспоненты не должны получаться из долго живущих секретов, подобных seed для псевдослучайного генератора.

Хотя сообщения последней круговой передачи в Main Mode (и не обязательно последнее сообщение Aggressive Mode ) являются зашифрованными, они строго говоря не являются аутентифицированными. Активная атака замены для зашифрованного текста может привести к разрушению содержимого. Если такая атака имела место для обязательных содержимых, это будет определено и приведет к падении аутентификации, но если это произошло для дополнительных содержимых (например, для содержимых уведомления, измененных в последнем сообщении Main Mode обмена), это может быть не определено.

Дополнения


Литература

  1. James Nechvatal, Elaine Barker, Lawrence Bassham, William Burr, Morris Dworkin, James Foti, Edward Roback, Report on the Development of the Advanced Encryption Standard (AES), Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Technology Administration U.S. Department of Commerce. 2000г. 116c.
  2. , Государственный Стандарт Российской Федерации «ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. КРИПТОГРАФИЧЕСКАЯ ЗАЩИТА ИНФОРМАЦИИ. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма», 1994г.
  3. , Государственный Стандарт Российской Федерации «ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. КРИПТОГРАФИЧЕСКАЯ ЗАЩИТА ИНФОРМАЦИИ. Функция хэширования», 1994г.
  4. , Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation, ITU-T X.680 (07/2002) Series X: Data Networks and Open System Communocation, 2002г. 146с.
  5. , RFC 2251 «Lightweight Directory Access Protocol (v3)», 1997г. 50с.
  6. , RFC 2252 «Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions», 1997г. 32с.
  7. , RFC 2253 «The String Representation of LDAP Search Filters», 1997г. 8с.
  8. , RFC 2256 «A Summary of the X.500(96) User Schema for use with LDAPv3», 1997г. 20с.
  9. , RFC 2587 «Internet X.509 Public Key Infrastructure LDAPv2 Schema», 1999г. 8с.
  10. , RFC 2829 «Authentication Methods for LDAP», 2000г. 16с.
  11. , RFC 3383 «Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)», 2002г. 23с.
  12. , RFC 2246 «The TLS Protocol Version 1.0», 1999г. 80с.
  13. , RFC 3546 «Transport Layer Security (TLS) Extensions», 2003г. 29с.
  14. , RFC 3280 «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», 2002г. 129с.
  15. , RFC 3281 «An Internet Attribute Certificate Profile for Authorization», 2002г. 40с.
  16. , RFC 2510 «Internet X.509 Public Key Infrastructure Certificate Management Protocols», 1999г. 72с.
  17. , RFC 2511 «Internet X.509 Certificate Request Message Format», 1999г. 25с.
  18. , RFC 3369 «Cryptographic Message Syntax», 2002г. 60с.
  19. , RFC 2560 «X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP», 1999г. 23с.
  20. , RFC 2797 «Certificate Management Messages over CMS», 2000г. 47с.
  21. , RFC 3379 «Delegated Path Validation and Delegated Path Discovery Protocol Requirements», 2002г. 15с.
  22. , RFC 2401 «Security Architecture for the Internet Protocol», 1998г. 66с.
  23. , RFC 2408 «Internet Security Association and Key Management Protocol (ISAKMP)», 1998г. 86с.
  24. , RFC 2409 «The Internet Key Exchange (IKE)», 1998г. 41с.
  25. , RFC 2412 «The OAKLEY Key Determination Protocol», 1998г. 55с.
  26. В. Столлингс, Криптография и защита сетей. Принципы и практика, 2-е изд. 2001г., Издательский дом «Вильямс», 672 с.
  27. Б. Шнайер, Прикладная криптография. Протоколы, алгоритмы и исходные тексты на языке С, 2-е изд. 2003г.
  28. М.А. Иванов, Криптографические методы защиты информации в компьютерных системах и сетях, 2001г., «Кудиц-образ», 386с.