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

Инфраструктура Открытого Ключа (часть 1)

Разбить на страницы
Показывать лекцию целиком

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 – произвольная последовательность октетов;

NULL – 0 ;

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 }

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

Идентификаторы объектов и их значения
Величина идентификатора объекта Назначение
{ 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 является предоставление доверенного и действительного открытого ключа участника, а также управление всем жизненным циклом сертификата открытого ключа.

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

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

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

    Мы будем рассматривать сертификаты Х.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 рассмотрены основные элементы сертификата.

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

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

    СА << A >>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Registration Authority (RA) – регистрационный центр – необязательный участник, ответственный за выполнение некоторых административных задач, необходимых для регистрации конечных участников. Такими задачами могут быть: подтверждение идентификации конечного участника; проверка значений, которые будут указаны в создаваемом сертификате ; проверка, знает ли конечный участник закрытый ключ, соответствующий открытому ключу, указанному в сертификате. Заметим, что RA сам также является конечным участником.

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

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

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

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

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

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

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

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

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

  • Получатель подписанных данных должен убедиться, что предоставленная идентификация пользователя соответствует идентификации, содержащейся в PKC.
  • Получатель проверяет, не отменен ли в полученной цепочке сертификатов какой-либо PKC (например, посредством получения соответствующего текущего CRL или on-line запроса статуса сертификата ) и все ли PKCs находились в рамках своих периодов действительности в момент подписывания данных.
  • Получатель должен убедиться, что данные не содержат никаких значений, для которых подписывающая сторона не имеет авторизации.
  • Получатель проверяет, не изменялись ли данные после подписывания, используя открытый ключ в PKC.
  • Если все эти проверки проходят, получатель может считать, что данные были подписаны указанной подписывающей стороной. Процесс для ключей, используемых для шифрования, аналогичен.
    •

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

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

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

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

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

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

    (рис 13.1) Участники 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 – произвольная последовательность октетов;

    NULL – 0 ;

    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 }

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

    Идентификаторы объектов и их значения
    Величина идентификатора объекта Назначение
    { 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 является предоставление доверенного и действительного открытого ключа участника, а также управление всем жизненным циклом сертификата открытого ключа.

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

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

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

    Мы будем рассматривать сертификаты Х.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 рассмотрены основные элементы сертификата.

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

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

    СА << A >>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Registration Authority (RA) – регистрационный центр – необязательный участник, ответственный за выполнение некоторых административных задач, необходимых для регистрации конечных участников. Такими задачами могут быть: подтверждение идентификации конечного участника; проверка значений, которые будут указаны в создаваемом сертификате ; проверка, знает ли конечный участник закрытый ключ, соответствующий открытому ключу, указанному в сертификате. Заметим, что RA сам также является конечным участником.

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

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

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

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

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

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

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

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

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

  • Получатель подписанных данных должен убедиться, что предоставленная идентификация пользователя соответствует идентификации, содержащейся в PKC.
  • Получатель проверяет, не отменен ли в полученной цепочке сертификатов какой-либо PKC (например, посредством получения соответствующего текущего CRL или on-line запроса статуса сертификата ) и все ли PKCs находились в рамках своих периодов действительности в момент подписывания данных.
  • Получатель должен убедиться, что данные не содержат никаких значений, для которых подписывающая сторона не имеет авторизации.
  • Получатель проверяет, не изменялись ли данные после подписывания, используя открытый ключ в PKC.
  • Если все эти проверки проходят, получатель может считать, что данные были подписаны указанной подписывающей стороной. Процесс для ключей, используемых для шифрования, аналогичен.
    •

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

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

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

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

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

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

    (рис 13.1) Участники PKI
    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^