kiev-security.org.ua-Криптография.Наименование: проект рекомендаций х509 - справочник - структура аутентификации раздел I

РАЗДЕЛ I - ПРОСТАЯ АУТЕНТИФИКАЦИЯ 5. Процедура простой аутентификации 5.1. Простая аутентификация предназначена для обеспечения местной авторизации (санкционирования), основанной на взаимосогласованном пароле в рамках одного справочного домена. Она ограничивается только местным применением, т.е. для аутентификации однорангового объекта между одним справочным посредником (агентом) пользователя и одним справочным источником адреса, либо между одним справочным источником адреса и другим справочным источником адреса. Простую аутентификацию можно осуществить несколькими путями: а) передачей получателю характерного имени пользователя и пароля в открытом (незащищенном) виде для оценки; b) передачей характерного имени пользователя, пароля и случайного числа, либо временной метки, защищенных путем применения односторонней функции; с) передачей защищенной информации, описанной в b), вместе со случайным числом, защищенных путем применения односторонней функции. Примечание: не требуется, чтобы применяемые односторонние функции были различными. 5.2. Если пароли не защищены, то обеспечивается минимальная степень защиты от несанкционированного доступа. Этот случай нельзя рассматривать как основу безопасного сервиса. Защита характерного имени пользователя и пароля обеспечивает большую степень безопасности. В качестве механизмов защиты могут использоваться нешифрующие односторонние функции, достаточно простые для реализации. 5.3. Справочник может служить хранилищем защищенных паролей. зддддддддддддј ° Справочник ° юдддддбдбдддды ° ° 2° °3 здддддј 1 здададј ° А цдддддддддддд>ѓ В ° ° ц<ддддддддддддѓ ° юддддды 4 юддддды Рис.1. Процедура простой аутентификации 5.4. Общая процедура простой аутентификации показана на рис.1. 5.4.1. В общем случае выполняются следующие шаги: 1) пользователь-инициатор А посылает свое характерное имя и пароль пользователю-получателю В; 2) В отправляет данное характерное имя и пароль пользователя А в Справочник, где пароль сравнивается с атрибутом "Пароль пользователя" в разделе Справочника, отведенном для пользователя А (используя справочную операцию Compare (Сравнить)); 3) Справочник подтверждает (или отрицает) пользователю В достоверность верительных данных; 4) об успехе (или неудаче) аутентификации может сообщаться А. 5.4.2. В наиболее употребимой форме простой аутентификации используется только шаг 1), и после того, как В проверит характерное имя и пароль, может выполняться шаг 4). зддддддддддддддддддддддддддддддддј ° зддддддј °аутентификатор1 А дддедддд>ѓ ° зддддддддддддддддедддд> ° ° ° ° ° пароль А дддедддд>ѓ f1 цддѓ здддддддј ° ° ° ° юдд>ѓ ° ° дддедддд>ѓ ° ° ° °аутентификатор2 ° юдддддды ° f2 цддддедддд> ° ° ° ° дддедддддддддддддддддд>ѓ ° ° ° юддддддды ° ° ° юдддддддддддддддддддддддддддддддды Легенда А = характерное имя пользователя t = временная метка (ни А) парольA = пароль пользователя А q = случайное число с (необязательным) счетчиком (ни А) Рис.2. Простая аутентификация с защитой 5.4.3. В простом защищенном варианте выполняются следующие шаги: 1) пользователь-инициатор А посылает свою защищенную идентификационную информацию пользователю-получателю В. Защита достигается применением односторонней функции (f1) (рис.2); 2) В отправляет данную информацию пользователя А в Справочник. Справочник проверяет эту информацию, вырабатывая местную копию защищенной информации А, используя временную метку и характерное имя, предоставляемые исходно пользователем А, а также хранимую копию пароля А. Затем он проверяет на равенство результат с информацией, предоставленной В. Защита пароля А имеет вид: Аутентификатор1 = А, t , f1(А, парольА, t ); (ни А) 3) Справочник подтверждает (или отрицает) пользователю В достоверность верительных данных; 4) устанавливается аутентифицированная связь от А к В, либо В сообщает А о неудаче. 5.4.4. В другом защищенном варианте процедура сходна с 5.4.3. Основные отличия следующие: 1) А фактически посылает результат применения второй односторонней функции (f2) к результату первой функции вместе со случайным числом; 2) В отправляет данную информацию пользователя А в Справочник. Для сравнения Справочник производит те же вычисления, что и А: Аутентификатор2 = f2(А, t , f1(А, парольА, t ), q ); (ни А) 3) Справочник подтверждает (или отрицает) пользователю В достоверность верительных данных; 4) устанавливается аутентифицированная связь от А к В, либо В сообщает А о неудаче. 5.5. Атрибут "Пароль пользователя" содержит пароль объекта. Значением атрибута для пароля пользователя является строка, определяемая объектом. UserPassword ::= ATTRIBUTE SYNTAX octetStringSyntax. 5.6. Приводимое ASN.1-макро можно использовать для определения типа данных, возникающего в результате применения односторонней функции к другому заданному типу данных PROTECTED MACRO ::= SIGNATURE (ЗАЩИЩЕННОЕ МАКРО ::= ПОДПИСЬ) РАЗДЕЛ II - СИЛЬНАЯ АУТЕНТИФИКАЦИЯ 6. Основа сильной аутентификации 6.1. Принятый в Рекомендациях подход к сильной аутентификации использует свойства такой группы криптосистем, как криптосистемы с открытым ключом (КСОК). Эти криптосистемы, называемые также асимметричными, используют пару ключей, секретный и открытый, в отличие от традиционных одноключевых систем. В Приложении В дается краткое введение в эти криптосистемы и их свойства, используемые при аутентификации. Для применения КСОК в структуре аутентификации требуется, чтобы оба ключа ключевой пары могли бы использоваться для шифрования, причем секретный ключ использовался бы для дешифрования при применении открытого ключа, а открытый ключ - при использовании секретного ключа. 6.2. Данная структура аутентификации не привязана к конкретной криптосистеме. Предполагается, что структура будет применима для любой подходящей криптосистемы и, следовательно, будет поддерживать изменения в используемых методах с развитием криптографии, математических методов и вычислительных возможностей. Вместе с тем, два пользователя, желающие осуществлять аутентификацию, должны поддерживать единый криптоалгоритм аутентификации. Таким образом, в контектсте множества связанных применений выбор единого алгоритма служит для максимизации сообщества пользователей, способных осуществлять взаимную аутентификацию и безопасную связь. Пример криптоалгоритма с открытым ключом приводится в Приложении С. 6.3. Аутентификация основана на обладании каждым пользователем уникальным характерным именем. За назначение характерных имен отвечает система назначения полномочий. Следовательно, каждый пользователь должен доверять системе назначения полномочий в том, что она не продублирует характерные имена. 6.4. Каждый пользователь идентифицируется по его обладанию своим секретным ключом. Второй пользователь способен определить, обладает ли связующийся с ним партнер этим секретным ключом, и может использовать это для подтверждения того, что партнер действительно является пользователем. Достоверность этого подтверждения зависит от секретного ключа, который должен оставаться конфиденциальным для пользователя. 6.5. Пользователь, желающий определить, обладает ли связующийся с ним партнер секретным ключом другого пользователя, сам должен владеть открытым ключом пользователя. И если получение значения этого открытого ключа из пользовательского раздела в Справочнике несложно, то проверка его правильности весьма проблематична. Для этого имеется много возможных путей: в подразделе 7 описан процесс, посредством которого можно проверить открытый ключ пользователя при помощи справочника. Процесс выполним только в том случае, если в Справочнике существует неразрывная цепочка доверенных точек между пользователями, требующими аутентификации. Такую цепочку можно построить, идентифицировав общую точку доверия. Общая точка доверия должна быть связана с каждым пользователем неразрывной цепочкой доверенных точек. - 10 - 7. Получение открытого ключа пользователя 7.1. Для того, чтобы пользователь доверял процедуре аутентификации, он должен получать открытый ключ другого пользователя из источника, которому он доверяет. Такой источник, называемый сертификационным органом (СО), использует алгоритм с открытым ключом для сертификации открытого ключа, вырабатывая сертификат. Сертификат, вид которого определен в 7.2, имеет следующие свойства: * любой пользователь, имеющий доступ к открытому ключу сертификационного органа, может восстановить подвергшийся сертификации открытый ключ; * ни одна из сторон кроме сертификационного органа не может модифицировать сертификат без обнаружения этого факта (сертификаты неподделываемы). Ввиду того, что сертификаты неподделываемы, их можно опубликовать, поместив в Справочник, причем в последующем не требуется прилагать усилий для их защиты. Примечание: хотя сертификационные органы однозначно определяются характерным именем в ИДС, из этого не следует, что между организацией сертификационных органов и ИДС существует какая-либо связь. 7.2. Сертификационный орган вырабатывает сертификат пользователя путем подписания (см. подраздел 8) совокупности информации, включая характерное имя пользователя и открытый ключ. В частности, сертификат пользователя с характерным именем А, выработанный сертификационным органом СО, имеет вид: СО<<А>> = СО {СО, А, Аp, Та}, где Та указывает на период действия сертификата и состоит из двух дат, начальной и конечной даты срока действия. Поскольку Та предположительно будет изменяться за периоды, не меньшие 24 часов, ожидается, что системы будут использовать скоординированное всемирное время в качестве временного эталона. Достоверность подписи сертификата может быть проверена любым пользователем, знающим СОp. Для представления сертификатов можно использовать следующий тип данных ASN.1: Certificate ::= SIGNED SEQUENCE { signature AlgorithmIdentifier issuer Name validity Validity subject Name subjectPublicKeyInfo SubjectPublicKeyInfo}} (Сертификат ::= ПОДПИСАННАЯ ПОСЛЕДОВАТЕЛЬНОСТЬ { подпись ИдентификаторАлгоритма выпускающий Имя достоверность Достоверность субъект Имя информация_об_открытом_ Информация_об_открытом_ ключе_субъекта ключе_субъекта}} ) - 11 - Validity ::= SEQUENCE{ notBefore UTCTime notAfter UTCTime} (Достоверность ::= ПОСЛЕДОВАТЕЛЬНОСТЬ{ не_Раньше Скоординированное_Всемирное_Время не_Позже Скоординированное_Всемирное_Время} ) SubjectPublicKeyInfo ::= SEQUENCE{ subjectKey BIT STRING algorithm AlgorithmIdentifier} (Информация_об_открытом_ключе_субъекта ::= ПОСЛЕДОВАТЕЛЬНОСТЬ{ ключ_субъекта БИТОВАЯ СТРОКА алгоритм Идентификатор_алгоритма} ) AlgorithmIdentifier ::= SEQUENCE{ algorithm OBJECT IDENTIFIER parameters ANY DEFINED BY algorithm OPTIONAL} (Идентификатор_алгоритма ::= ПОСЛЕДОВАТЕЛЬНОСТЬ{ алгоритм ИДЕНТИФИКАТОР ОБЪЕКТА параметры ЛЮБЫЕ, ОПРЕДЕЛЕННЫЕ алгоритмом НЕОБЯЗАТЕЛЬНО} ) 7.3. Справочный раздел каждого пользователя, А, участвующего в сильной аутентификации, содержит сертификат(ы) А. Такой сертификат вырабатывается сертификационным органом пользователя А, являющимся объектом в ИДС. СО пользователя А, который может быть неединственным, обозначается СО(А) или просто СО, если А подразумевается. Таким образом, открытый ключ А может получить любой пользователь, знающий открытый ключ СО. Следовательно, получение открытых ключей рекурсивно. 7.4. Если пользователь А, пытаясь получить открытый ключ пользователя В, получил открытый ключ СО(В), то процесс завершается. Для получения открытого ключа СО(В) в помощь А справочный раздел каждого сертификационного органа, Х, содержит набор сертификатов. Эти сертификаты бывают двух типов. Во-первых, это сертификаты Х, выработанные другими сертификационными органами. Во-вторых, это обратные сертификаты, выработанные самим Х, которые являются сертифицированными открытыми ключами других сертификационных органов. Наличие этих сертификатов позволяет пользователям создавать сертификационные пути от одной точки к другой. 7.5. Список сертификатов, требуемый для получения некоторым пользователем открытого ключа другого пользователя, называют сертификационным путем. Каждый элемент списка является сертификатом сертификационного органа следующего элемента в списке. Сертификационный путь от А к В (обозначается АЖВ): - 12 - * начинается с сертификата, выработанного СО(А), а именно СО(А) <<Х >> для некторого объекта Х ; (ви 1) * продолжается другими сертификатами Х <<Х >; (ви i, i+1) * заканчивается сертификатом В. Логически сертификационный путь образует неразрывную цепочку доверенных точек Информационного дерева Справочника между двумя пользователями, желающими провести аутентификацию. Подробности метода, выполняемого А и В для получения сертификационных путей АЖВ и ВЖА, могут отличаться. Для облегчения можно установить иерархию СО, которая может совпадать или не совпадать частично или во всем с иерархией ИДС. Польза состоит в том, что пользователи, имеющие СО в иерархии, могут установить между собой сертификационный путь с помощью Справочника без какой-либо предварительной информации, причем на каждом СО может храниться один сертификат и один обратный сертификат, соответствующий старшему СО. 7.6.Сертификаты хранятся в разделах Справочника в виде атрибутов типа 'UserCertificate' ('Сертификат_Пользователя'), 'CACertificate' ('Сертификат_СО') и 'CrossCertificatePair' ('Пара_Кросс-сертификат'). Эти типы атрибутов известны Справочнику. Операции с этими атрибутами проводятся по тому же протоколу, как и с другими атрибутами. Спецификация данных типов атрибутов следующая: UserCertificate ::= ATTRIBUTE WITH ATTRIBUTE-SYNTAX certificateSyntax CACertificate ::= ATTRIBUTE WITH ATTRIBUTE-SYNTAX certificateSyntax CrossCertificatePair ::= ATTRIBUTE WITH ATTRIBUTE-SYNTAX certificatePairSyntax CertificateSyntax ::= ATTRIBUTE-SYNTAX Certificate CertificatePairSyntax ::= ATTRIBUTE-SYNTAX SEQUENCE{ forward Certificate OPTIONAL reverse Certificate OPTIONAL --at least one must be present--} ----------------------------------------------------------------Сертификат_Пользователя ::= АТРИБУТ С_СИНТАКСИСОМ_АТРИБУТА Синтаксис_сертификата Сертификат_СО ::= АТРИБУТ С_СИНТАКСИСОМ_АТРИБУТА Синтаксис_сертификата Пара_Кросс-Сертификат ::= АТРИБУТ С_СИНТАКСИСОМ_АТРИБУТА Синтаксис_пары_сертификатов Синтаксис_Сертификата ::= СИНТАКСИС_АТРИБУТА Сертификат - 13 - Синтаксис_Пары_Сертификатов ::= СИНТАКСИС_АТРИБУТА Сертификат ПОСЛЕДОВАТЕЛЬНОСТЬ{ прямой Сертификат НЕОБЯЗАТЕЛЬНО обратный Сертификат НЕОБЯЗАТЕЛЬНО --указывается хотя бы один из них--} ----------------------------------------------------------------Пользователь может получить более одного сертификата от разных сертификационных органов. В этом случае операция "Get Strong Credentials" ("Получить сильные верительные данные") идентифицирует требуемый сертификационный орган, если пользователи принадлежат более, чем к одному доверительному сообществу. 7.7. В общем случае перед осуществлением взаимной аутентифкации пользователей Справочник должен обеспечить полную сертификацию и возвратить сертификационные пути. Однако на практике количество информации, получаемое из Справочника, можно сократить с учетом конкретного случая аутентификации следующим образом: а) если два пользователя, желающие осуществить аутентификацию, обслуживаются одним сертификационным органом, то сертификационный путь становится тривиальным, и пользователи непосредственно развертывают сертификаты друг друга; b) если СО пользователей иерархично упорядочены, пользователь может хранить открытые ключи, сертификаты и обратные сертификаты всех сертификационных органов между ним и корнем ИДС. Обычно это требует от пользователя знания открытых ключей и сертификатов всего лишь трех или четырех сертификационных органов. Поэтому от пользователя требуется получить только сертификационные пути от общей точки доверия; с) если пользователь часто связывается с пользователями, сертифицированными некоторым другим СО, то он может изучить сертификационный путь к этому СО и обратный сертификационный путь от этого СО, после чего необходимо получить из Справочника только сертификат самого пользователя; d) сертификационные органы могут перекрестно сертифицировать друг друга (кросс-сертификация) по взаимному соглашению. В результате сокращается сертификационный путь; е) если два пользователя вступали в связь прежде и знают сертификаты друг друга, они способны провести аутентификацию вообще без обращения к Справочнику. В любом случае, узнав сертификаты друг друга из сертификационного пути, пользователи могут проверить достоверность полученных сертификатов. Рис.2. Иерархия СО - Гипотетический пример 7.8. (Пример). На рис.2 показан гипотетический пример фрагмента ИДС, в котором СО образуют иерархию. Помимо информации, указанной в СО, полагаем, что каждый пользователь знает открытые ключи своего СО и свои открытый и секретный ключи. - 14 - 7.8.1. Если сертификационные органы пользователей иерархично упорядочены, то для установления сертификационного пути к В А может получить из Справочника следующие сертификаты: X<>, W<>, V<>, Y<>, Z<>. Когда А получил эти сертификаты, он может развернуть сертификационный путь в последовательность для получения содержимого сертификата В, включая Bp: Bp = Xp * X<> W<> V<> Y<> Z<>. В общем случае, для установления обратного сертификационного пути от В к А последний кроме того должен получить из Справочника следующие сертификаты: Z<>, Y<>, V<>, W<>, X<>. Когда В получает эти сертификаты от А, он может развернуть обратный сертификационный путь в последовательность для получения содержимого сертификата А, включая Аp: Ap = Zp * Z<> Y<> V<> W<> X<>. 7.8.2. С применением оптимизации по п.7.7: а) например, возьмем А и С: оба знают Xp, поэтому А просто должен получить сертификат С. Развертывание сертификационного пути сокращается к виду: Cp = Xp * X<> и развертывание обратного сертификационного пути сокращается к виду: Аp = Xp * X<<А>>; b) предположение о том, что А знает W<>, Wp, V<>, Vp, U<>, Up и т.д. уменьшает объем информации, которую А должен получать из Справочника для формирования сертификационного пути: V<>, Y<>, Z<> и для формирования обратного сертификационного пути: Z<>, Y<>; с) предположим, что А часто связывается с пользователями, сертифицированными Z, и знает (кроме открытых ключей, указанных в пункте b)) V<>, Y<>, Y<> и Z<>. Для связи с В требуется получить из Справочника только Z<>; d) предполагая, что пользователи, сертифицированные X и Z, часто входят в связь, в Справочнике в разделе пользователя Х будет храниться X<> и наоборот (см. рис.2). Если А желает аутентифицировать В, то ему требуется получить только: - 15 - X<>, Z<> для формирования сертификационного пути и Z<> для формирования обратного сертификационного пути; е) предполагая, что пользователи А и С вступали в связь ранее и узнали сертификаты друг друга, они могут непосредственно использовать отукрытые ключи друг друга, т.е. Cp = Xp * X<> и Ap = Xp * X<>. 7.8.3. В более общем случае сертификационные органы не связаны иерархично. Обращаясь к гипотетическому примеру на рис.3, предположим, что пользователь D, сертифицированный U, желает аутентифицировать пользователя Е, сертифицированного W. Раздел Справочника пользователя D будет содержать сертификат U<>, а раздел пользователя Е - сертификат W<>. Пусть V будет СО, с которым сертификационные органы U и W ранее обменялись ключами доверенным образом. В результате были выработаны и сохранены в Справочнике сертификаты U<>, V<>, W<> и V<>. Полагаем, что U<> и W<> хранятся в разделе V, V<> хранится в разделе U, а V<> - в разделе W. Пользователь D должен найти сертификационный путь к Е. Можно использовать различные стратегии. По одной из стратегий пользователи и СО рассматриваются как узлы, а сертификаты как дуги направленного графа. Тогда D должен выполнить поиск по графу для отыскания направленного графа от U к Е, один из которых U<>, V<>, W<>. После обнаружения этого пути можно также построить обратный путь W<>, V<>, U<>. 8. Цифровые подписи Целью этого раздела является не определение стандарта для цифровых подписей в общем, а определение средств подписания полномочий (token) в Справочнике. 8.1. Информация (info) подписывается путем добавления к ней зашифрованной свертки информации. Свертка вырабатывается при помощи односторонней функции, а шифрование выполняется на секретном ключе подписанта (см. рис.4). Таким образом, - 15 - X{Info} = Info, Xs[h(Info)]. зд дд дд дд дд дд дд ддј зд дд дд дд дд дд дд ддј секретный ключ (Хs) открытый ключ (Хр) ° ° ° ° ° ° зддаддј зддаддј ° ° ° ° Xs[h(инф)]° ° ° ° здддд>ѓ Е цддддддддддддддддддддддддддд>ѓ D цддддддд> ° ° ° ° ° ° ° ° ° ° юддддды юдддддысравнить ° ° ° ° ° ° зддддддддддддддддддд> ° зддаддј ° ° зддаддј ° ° h ° ° h ° ° ° ° ° ° ° ° ° юддбдды юддбдды ° ° °информация ° ° ° дддддддддаддддддддддддддддддддддддддддддддддаддддддддддддддддддд> ° ° ° ° юд дд дд дд дд дд дд дды юд дд дд дд дд дд дд дды подписывающий (Х) получатель Рис.4. Цифровые подписи Примечание. Шифрование на секретном ключе обеспечивает защиту подписи от подделки. Односторонний характер хэш-функции обеспечивает то, что нельзя подставить фальшивую информацию, имеющую такой же хэш-результат. 8.2. Получатель подписанной информации проверяет подпись: - применением к информации односторонней хэш-функции; - сравнением результата с полученным путем дешифрования подписи на открытом ключе подписанта. 8.3. Данная структура аутентификации не привязана к одной хэшфункции, используемой для подписания. Предполагается, что структура будет применима для любой подходящей хэш-функции и, следовательно, будет поддерживать изменения в используемых методах с развитием криптографии, математических методов и вычислительных возможностей. Вместе с тем, два пользователя, желающие осуществлять аутентификацию, должны поддерживать единую хэш-функцию для правильного выполнения аутентификации. Таким образом, в контектсте множества связанных применений выбор единой функции служит для максимизации сообщества пользователей, способных осуществлять взаимную аутентификацию и безопасную связь. Пример хэш-функции приводится в Приложении D. Подписанная информация содержит указатели, идентифицирующие алгоритмы хэширования и шифрования, использованные для расчета цифровой подписи. - 15 - 8.4. В случае, когда подпись должна добавляться к типу данных, для определения типа данных, являющегося результатом приложения подписи к заданному типу данных, можно использовать слдующее макро АSN.1. SIGNED MACRO ::= BEGIN TYPE NOTATION ::= type (ToBeSigned) VALUE NOTATION ::= value (VALUE SEQUENCE { ToBeSigned, AlgorithmIdentifier, ENCRYPTED OCTET STRING } ) END ----------------------------------------------------------------МАКРО ПОДПИСАННОЕ ::= НАЧАТЬ ОПРЕДЕЛЕНИЕ ТИПА ::= тип (Подписываемое_значение) ОПРЕДЕЛЕНИЕ ЗНАЧЕНИЯ ::= значение (ЗНАЧЕНИЕ ПОСЛЕДОВАТЕЛЬНОСТЬ { Подписываемое_значение, Идентификатор_алгоритма, -- используемого для расчета подписи ЗАШИФРОВАННАЯ СТРОКА ОКТАД -- где строка октад - это результат хэширования -- Подписываемого_значения} ) КОНЕЦ --МАКРО ПОДПИСАННОЕ ----------------------------------------------------------------8.4. В случае, когда требуется только подпись, для определения типа данных, являющегося результатом приложения подписи к заданному типу данных, можно использовать слдующее макро АSN.1. - 17 - SIGNATURE MACRO ::= BEGIN TYPE NOTATION ::= type (OfSignature) VALUE NOTATION ::= value (VALUE SEQUENCE { AlgorithmIdentifier, ENCRYPTED OCTET STRING } ) END - 17 - ----------------------------------------------------------------МАКРО ПОДПИСЬ ::= НАЧАТЬ ОПРЕДЕЛЕНИЕ ТИПА ::= тип (Подписи) ОПРЕДЕЛЕНИЕ ЗНАЧЕНИЯ ::= значение (ЗНАЧЕНИЕ ПОСЛЕДОВАТЕЛЬНОСТЬ { Идентификатор_алгоритма, -- используемого для расчета подписи ЗАШИФРОВАННАЯ СТРОКА ОКТАД -- где строка октад - это функция (например, сжатая или -- хэшированная версия) значения "Подписи", которая мо-- жет включать идентификатор алгоритма, использованно-- го для расчета подписи--} ) КОНЕЦ --МАКРО ПОДПИСЬ ----------------------------------------------------------------8.6. Для обеспечения проверки типов SIGNED (ПОДПИСАННОЕ) и SIGNATURE (ПОДПИСЬ) в распределенной среде требуется характерное кодирование, получаемое при использовании основных правил кодирования, изложенных в Рекомендациях Х.209, со следующими ограничениями: а) должна использоваться конечная форма длины кодирования, результирующая в наименьшее число октад; b) для строчных (string) типов не должно использоваться конструктивное (constructive) кодирование; с) если используется значение типа по умолчанию, то оно не указывается; d) компоненты типа Set должны кодироваться в порядке возрастания значений их тегов (этикеток); е) компоненты типа Set-of должны кодироваться в порядке возрастания значений их октад; f) если значение булевого типа "истинно", то кодированное значение содержит октаду 'FF' ; g) каждый неиспользуемый бит последней октады кодового значения типа Bit String (строка битов) (при наличии) должен быть установлен в ноль; h) кодовое значение типа Real не должно иметь в основании 8, 10 и 16, а двоичный масштабный множитель должен быть равен нулю. 9. Процедуры сильной аутентификации 9.1. Обзор 9.1.1. Основной подход к аутентификации, описанный выше, заключается в подтверждении идентичности путем демонстрации обладания секретным ключом. При этом подходе возможны различные процедуры аутентификации. В общем случае соответствующие процедуры определяются конкретным применением и методикой безопасности. В данном подразделе описаны три процедуры аутентифкации, которые могут оказаться полезными в ряде применений. Примечание. Данные Рекомендации не определяют подробности реализации процедур. С этой целью можно использовать дополнительные стандарты, определяющие процедуры в общем виде или для конкретных задач. - 18 - 9.1.2. Три рассматриваемых процедуры используют разное количество операций обмена аутентификационной информацией и, следовательно, предоставляют разные типы гарантий участникам обмена, а именно: а) односторонняя аутентификация, описанная в 9.2, использует единственную передачу информации от одного пользователя (А) другому (В) и устанавливает следующее: - идентичность А и то, что аутентификационное полномочие было действительно выработано А; - идентичность В и то, что аутентификационное полномочие было действительно предназначено для отправки В; - целостность и "оригинальность" (свойство, состоящее в том, что полномочие не посылалось два или более раз) передаваемого аутентификационного полномочия. Указанные свойства справедливы и для произвольных дополнительных данных, сопровождающих передачу. b) двухсторонняя аутентификация, описанная в 9.3, использует кроме того ответ от В к А. Дополнительно она устанавливает следующее: - то, что аутентификационное полномочие, выработанное для ответа, было действительно выработано В и предназначалось для отправки А; - целостность и оригинальность передаваемого в ответе аутентификационного полномочия; - взаимную секретность полномочий. с) трехсторонняя аутентификация, описанная в 9.4, использует кроме того еще одну передачу от А к В. Она устанавливает те же свойства, что и двухсторонняя аутентификация, но при этом не требуется привязка к проверке временных меток. При каждом использовании сильной аутентификации А должен получить открытый ключ В и до какого-либо обмена информацией возвратить сертификационный путь от В к А. При этом может происходить обращение к Справочнику (подраздел 7). Ниже при описании процедур любое такое обращение не упоминается. Упоминаемая ниже проверка временных меток используется только в тех случаях, когда в местной среде применяются синхронизированные часы, либо когда часы логически синхронизированы по взаимному соглашению. В любом случае рекомендуется использовать скоординированное всемирное время. Для каждой из трех аутентификационных процедур, описанных ниже, предполагается, что сторона А проверила достоверность всех сертификатов сертификационного пути. - 19 - 9.2. Односторонняя аутентификация Используются следующие шаги (рис.5): 1 3 здддддј 2 здддддј ° А цдддддддддддд>ѓ В ° ° ° ° ° юддддды юддддды Рис.5. Односторонняя аутентификация 1. А вырабатывает r - случайное число, используемое для обнаружения атак типа "повторная передача" и предотвращения подделок. (ви А) 2. А посылает В следующее сообщение: В Ж А, А {t , r , В}, (ви А) где t - временная метка. t состоит из одной или двух дат: времени выработки полномочия (необязательный параметр) и срока действия. Другой вариант, когда используется цифровая подпись для аутентификации происхождения данных 'sgnData': В Ж А, А {t , r , В, sgnData}. При использовании в качестве секретного ключа 'encData': В Ж А, А {t , r , В, sgnData, Bp[encData]}. При использовании в качестве секретного ключа 'encData' необходимо осторожно выбирать эти данные. Они должны быть сильным ключом для криптосистемы, указанной в поле 'sgnData' полномочия. 3. В выполняет следующие действия: а) получает Ap из ВЖА, проверяя срок действия сертификата А; b) проверяет подпись и, следовательно, целостность подписанной информации; с) проверяет, что именно он является указанным получателем; d) проверяет временную метку; е) может проверить, что r не передается повторно. Это можно выполнить, например, если в r включена последовательная часть, проверяемая на месте на уникальность значения. r действует до истечения срока действия, определяемого t . r всегда сопровождается последовательной частью, указывающей, что А не будет повторять полномочие в течение t и, следовательно, проверка значения самого r не требуется. В любом случае для стороны В разумно хранить последовательную часть вместе с временной меткой t в открытом виде и вместе с хэшированной частью полномочия в течение t . - 20 - 9.3. Двухсторонняя аутентификация Используются следующие шаги (рис.6): 1 3 здддддј 2 здддддј ° А цдддддддддддд>ѓ В ° 6° ц<ддддддддддддѓ °4 юддддды 5 юддддды Рис.6. Двухсторонняя аутентификация 1. Как в 9.2. 2. Как в 9.2. 3. Как в 9.2. 4. В вырабатывает r - случайное число, используемое аналогично r . (ви В,А) 5. В посылает А следующее аутентифкационное полномочие: В {t , r , А, r }, (ви ВВА) где t - временная метка, аналогичная t . (ви ВА) Другой вариант, когда используется цифровая подпись для аутентификации происхождения данных 'sgnData': В {t , r , А, r , sgnData}. (ви ВВА) При использовании в качестве секретного ключа 'encData': В {t , r , А, r , sgnData, Аp[encData]}. (ви ВВА) При использовании в качестве секретного ключа 'encData' необходимо осторожно выбирать эти данные. Они должны быть сильным ключом для криптосистемы, указанной в поле 'sgnData' полномочия. 6. А выполняет следующие действия: а) проверяет подпись и, следовательно, целостность подписанной информации; b) проверяет, что А является указанным получателем; с) проверяет временную метку t ; (ви В) е) может проверить, что r не передается повторно (см. 9.2 шаг 3 d). 9.4. Трехсторонняя аутентификация Используются следующие шаги (рис.7): - 19 - 1 3 здддддј 2 здддддј ° цдддддддддддд>ѓ ° 6° А ц<ддддд5ддддддѓ В °4 ° цдддддддддддд>ѓ ° юддддды 8 юддддды 7 9 Рис.7. Трехсторонняя аутентификация 1. Как в 9.3. 2. Как в 9.3. Временная метка t может быть нулевой. (ви А) 3. Как в 9.3, за исключением того, что временную метку не требуется проверять. 4. Как в 9.3. 5. Как в 9.3. Временная метка t может быть нулевой. (ви В) 6. Как в 9.3, за исключением того, что временную метку не требуется проверять. 7. А проверяет на совпадение принятое и посланное r . (ви А) 8. А посылает В следующее аутентифкационное полномочие: А {r }. (ви В) 9. В выполняет следующие действия: а) проверяет подпись и, следовательно, целостность подписанной информации; b) проверяет на совпадение принятое и посланное r . (ви В) 10. Управление ключами и сертификатами 10.1. Выработка ключевых пар 10.1.1. Срок действия ключевых пар определяется общей методикой управления безопасностью и, следовательно, находится за рамками рассмотрения структуры аутентификации. Однако для общей безопасности жизненно важно, чтобы все секретные ключи оставались известными только законному пользователю. Человеку нелегко запомнить ключевые данные, поэтому требуется удобный способ для их хранения. Одним из возможных способов является интеллектуальная карточка (смарт-карточка). Она может хранить секретный и (возможно) открытый ключи пользователя, его сертификат и копию открытого ключа сертификационного органа. Применение такой карточки должно усиливаться дополнительными мерами, например, при помощи PIN-кода (персональный идентификационный номер). При этом безопасность усиливается за счет того, что от пользователя требуется обладать карточкой и знать, как получить к ней доступ. Описание способа хранения таких данных не рассматривается в Рекомендациях. - 21 - 10.1.2. В подразделах 10.1.2.1-3 описаны три способа выработки ключевой пары пользователя. 10.1.2.1. Пользователь вырабатывает свою собственную ключевую пару. Премущество способа в том, что секретный ключ пользователя никогда не раскрывается другому объекту, но при этом от пользователя требуется определенный уровень компетентности (приложение С). 10.1.2.2. Ключевая пара вырабатывается третьей стороной. Третья сторона должна предъявить ключ пользователю физически безопасным образом, а затем уничтожить всю информацию относительно создания ключевой пары и сами ключи. При этом должны обеспечиваться надлежащие меры физической безопасности, предотвращающие обманную подстановку как третьей стороны, так и операций над данными. 10.1.2.3. Ключевая пара вырабатывается сертификационным органом. Это особый случай 10.1.2.2. Примечание. Сертификационный орган уже функционирует в условиях доверия со стороны пользователя и имеет надлежащую физическую защиту. Преимущество метода состоит в том, что не требуется защищенная передача данных сертификационному органу для сертификации. 10.1.2.4. Используемая крипосистема налагает специфические (технические) ограничения на выработку ключей. 10.2. Управление сертификатами 10.2.1. Сертификат связывает открытый ключ и уникальное характерное имя описываемого пользователя. Следовательно: а) сертификационный орган должен получить идентификакторы пользователя до создания для него сертификата; b) сертификационный орган не должен выпускать сертификаты для двух пользователей под одним именем. 10.2.2. Выработка сертификатов происходит автономно и не должно выполняться автоматически по методу запрос/ответ. Преимущество такой сертификации в том, что секретный ключ сертификационного органа СО не выходит за пределы изолированного и физически защищенного СО. Следовательно, секретный ключ можно узнать только путем атаки на СО, что снижает риск компрометации. 10.2.3. Важно, чтобы передача информации сертификационному органу не была скромпрометирована, при этом должны применяться соответствующие меры физической безопасности. С этой точки зрения: а) серьезным нарушением безопасности является ситуация, когда СО выпускает сертификат для пользователя, открытый ключ которого был подделан; b) если для выработки ключевых пар используется метод 10.1.2.3, то не требуется безопасной передачи; - 22 - с) если для выработки ключевых пар используется метод 10.1.2.1 или 10.1.2.2, то пользователь может применять различные методы (онлайн или офлайн) для безопасной передачи своего открытого ключа СО. Онлайновые методы обеспечивают определенную гибкость при удаленном взаимодействии пользователя и СО. Например, сообщение от пользователя СО можно защитить на открытом ключе СО, а ответ пользователю от СО можно защитить на открытом ключе пользователя (после того, как он был передан СО). 10.2.4. Сертификат является общедоступной информацией, и для его транспортировки в Справочник не требуется принимать особых мер безопасности. Если он вырабатывается автономным сертификационным органом от имени пользователя, получающего копию, то от пользователя требуется всего лишь сохранить эту информацию в своем разделе Справочника при последующем обращении к Справочнику. Кроме того, СО может поместить сертификат вместо пользователя, при этом он должен обладать соответствующими правами доступа. 10.2.5. Сертификаты включают в себя срок действия. Для обеспечения связности сервиса СО должен обеспечить возможность своевременной замены отслуживших срок сертификатов. Ряд аспектов этой проблемы описан в 10.2.5.1-2. 10.2.5.1. Сертификат должен становиться действующим в момент истечения срока действия его предшественника, при этом допускается перекрытие. Перекрытие позволит избежать ситуации, когда СО требуется выработать и распределить большое число сертификатов, одновременно вышедших из действия. 10.2.5.2. Вышедшие из действия сертификаты обычно удаляются из Справочника. Методикой безопасности может определяться ответственность СО за хранение старых сертификатов в течение определенного периода времени, если не обеспечивается сервис непризнания участия (спорных ситуаций). 10.2.6. Сертификаты могут отменяться до истечения срока их действия, например, если предполагается, что секретный ключ пользователя скомпрометирован или пользователь более не подлежит сертификации СО, либо если предполагается, что скомпрометирован сертификат СО. Ряд аспектов этой проблемы описан в 10.2.6.1-х. 10.2.6.1. СО должен знать об отмене сертификата пользователя или СО, после чего новый сертификат делается доступным. Затем СО может проинформировать владельца сертификата об его отмене при помощи некоторой офлайновой процедуры. 10.2.6.2. СО должен вести: а) список выпущенных им и отмененных сертификатов с указанием временных меток; b) список отмененных сертификатов всех СО, известных данному СО и им сертифицируемым. Оба списка должны существовать даже, если они пусты. 10.2.6.3. За ведение разделов Справочника, которых коснулась отмена сертификатов, отвечает Справочник и все пользователи, действующие в соответствии с методикой безопасности. Например, пользова- 23 - тель может модифицировать свой раздел, заменяя старый сертификат новым. Новый сертификат будет использоваться Справочником для аутентификации пользователя. 10.2.6.4. Списки отмены ('черные списки') содержатся в разделах в виде атрибутов типа 'CertificationRevocationList' ('Список_Oтмены_ Сертификата') и 'AuthorityRevocationList' ('Список_Отмены_Сертификата_СО'). Операции с этими атрибутами аналогичны операциям с другими атрибутами. Типы атрибутов определяются следующим образом: CertificationRevocationList ::= ATTRIBUTE WITH ATTRIBUTE-SYNTAX certificateListSyntax AuthorityRevocationList ::= ATTRIBUTE WITH ATTRIBUTE-SYNTAX certificateListSyntax certificateListSyntax ::= ATTRIBUTE-SYNTAX CertificateList CertificateList ::= SIGNED SEQUENCE { signature AlgorithmIdentifier, issuer Name, lastUpdate UTCTime, revokedCertificates SIGNED SEQUENCE OF SEQUENCE { signature AlgorithmIdentifier, issuer Name, subject Certificate, revocationDate UTCTime} OPTIONAL} ----------------------------------------------------------------Список_Отмены_Сертификата ::= АТРИБУТ С СИНТАКСИСОМ-АТРИБУТА синтаксис_списка_сертификатов Список_Отмены_Сертификата_СО ::= АТРИБУТ С СИНТАКСИСОМ-АТРИБУТА синтаксис_списка_сертификатов синтаксис_списка_сертификатов ::= СИНТАКСИС-АТРИБУТА Список_сертификатов Список_сертификатов ::= ПОДПИСАННАЯ ПОСЛЕДОВАТЕЛЬНОСТЬ { подпись Идентификатор_алгоритма, выпускающий Имя, последняя корректировка Скоординированное_всемирное_время, отмененные_сертификаты ПОДПИСАННАЯ ПОСЛЕДОВАТЕЛЬНОСТЬ ПОСЛЕДОВАТЕЛЬНОСТИ { подпись Идентификатор_алгоритма, выпускающий Имя, субъект Сертификат время отмены Скоординированное_всемирное_время} НОБЯЗАТЕЛЬНЫЙ ПАРАМЕТР} Примечания. 1. Проверка всего списка сертификатов является местным делом. 2. Если сервис непризнания участия зависит от ключей, обеспечиваемых СО, то сервис должен обеспечивать, чтобы все соответствуцющие ключи (отмененные или вышедшие из действия) и списки отмены с временными метками архивировались и сертифицировались текущим органом.

41 Наименование: проект рекомендаций х.509 - справочник - структура аутентификации раздел I -простая аутентификация