Электронная цифровая подпись.

- Обеспечение целостности и авторства в электронном документообороте

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

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

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

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

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

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

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

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

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

Подсистема безопасности системы электронного документооборота должна защищать ее легальных пользователей от следующих злоумышленных действий (рис. 15).

2. Модификация принятого сообщения и попытка утверждать, что оно принято именно в таком виде от кого-либо.

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

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

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

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

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

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

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

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

Цель преобразования – доказать неоспоримость текста документа и факта преобразования данных конкретным лицом.

Основной метод – проверка факта использования секретного параметра (ключа) подписи проверяющим, без знания ключа.

Обычно подпись представляет собой один или два блока данных.

Подписанное сообщение представляет собой исходное сообщение, передаваемое совместно с ЦП.

Известно много схем цифровой подписи, наиболее просто принцип ее построения иллюстрируется на примере алгоритма RSA.

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

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

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

В этом случае используется схема, изображенная на рис. 16.

Первым шагом вычисляется дайджест сообщения.

Для этого используется некоторая хэш-функция. Далее (шаг 2) дайджест шифруется секретным ключом отправителя. Полученная последовательность символов – электронная цифровая подпись – объединяется с исходным документом и направляется абоненту Б (шаг 3). Получатель с помощью открытого ключа отправителя расшифровывает дайджест (шаг 4) и вычисляет заново хэш-код принятого сообщения (шаг 5). Полученные значения

В случае совпадения, считается подтвержденным авторство абонента А и отсутствие искажений (целостность) сообщения.

Хэш-функции являются одним из важнейших элементов криптосистем, реализующих ЭЦП.

Реальные хэш-функции представляют собой сложные алгоритмы, рекомендованные в соответствующих стандартах. Хэш-функция z = h(m) – преобразование битовой строки произвольной длины в битовую строку (блок) фиксированной длины (обычно, 128-512 битов).

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

Их называют кодами аутентификации сообщений – Message Authentication Code (MAC). Коды MAC могут быть построены как хэш-функции с секретным параметром K в виде h = h(m, K).

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

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

В компьютерных системах и сетях широко используется типовой алгоритм HMAC вычисления кода МАС, с использованием произвольной встроенной хэш-функции h.

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

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

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

Характеристики некоторых стандартизованых хэш-функций приведены в таблице 6.

Наиболее известные из хэш-функций: MD2, MD4, MD5 и SHA-1.

Три алгоритма серии MD разработаны Ривестом в 1989-м, 90-м и 91-м годах соответственно. Все они преобразуют битовые строки произвольной длины произвольной длины в 128-битный хеш-код (дайджест).

В алгоритме MD4 довольно быстро были найдены слабые места, поэтому он был заменен алгоритмом MD5, в котором каждый блок участвует не в трех, а в четырех различных циклах.

Алгоритм SHA (Secure Hash Algorithm), разработанный NIST, повторяет идеи серии MD. В SHA используются тексты более 2⁶⁴ битов. Данный алгоритм первоначально предназначался использования в рамках государственной программы США – «Capstone», предполагающей централизованное хранение всех ключей, используемых организациями,

Алгоритм SHA (Secure Hash Algorithm) является частью стандарта SHS, принятого АНБ и Национальным институтом стандартов и технологий США в 1993 году. Для версии SHA-1 длина хэш-кода H = H(M) составляет 160 битов.

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

Далее формируется сообщение, состоящее из N блоков длиной 512 битов, в последнем блоке которого зарезервировано поле длиной в 64 бита.

В этом поле размещается число, равное исходной длине сообщения M (без дописок).

Расширенное сообщение M обрабатывается блоками по 512 битов.

При этом отдельный блок рассматривается как массив, состоящий из 16 слов, каждое длиной в 32 бита.

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

Блок V является конкатенцией пяти зарезервированных начальных значений

каждое длиной в 32 бита, которые в шестнадцатиричной системе счисления имеют следующий вид: A = 67452301, B = EFCDAB 89, С = 98 ВАDCFE,
D = 10325476, E = C 3 D 2 E 1 F 0.

После обработки очередного блока M_i сообщения M, значения переменных A,B,C,D,E модифицируются.

Результатом работы каждого цикла H_i = f (M_i, H_i-1) является конкатенация модифицированных значений переменных A,B,C,D,E.

Результат работы последнего цикла дает значение хэш-кода H = H(M).

Каждый цикл состоит из 80 шагов. На шаге j цикла с номером i обрабатывается слово M_i(j), длиной в 32 бита.

В начале каждого цикла создаются копии переменных A,B,C,D,E: А 1 = А, В 1 = В, С 1= С, D 1 = D, E 1 = E.

- Протоколы взаимодействия и сертификаты в стандарте Х.509

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

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

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

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

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

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

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

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

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

Подобные криптосистемы называются комбинированными (смешанными, гибридными).

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

Если используется короткий сеансовый ключ (например, 40-битовый DES), то не имеет значения, насколько велики асимметричные ключи. Атаке будут подвергнуты не они, а сеансовые ключи алгоритма DES.

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

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

Безопасно создаются и распространяются открытые и секретные ключи асимметричных алгоритмов.

Секретный ключ передается его владельцу. Открытый ключ хранится в базе данных, соответствующей стандарту X.500, и администрируется центром сертификации ключей (Certification Authority или ЦСК).

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

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

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

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

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

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

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

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

Стандарт X.509 описывает ряд методов для получения пользователями открытых ключей от ЦCК, однако практически ни один из них не может с 100% гарантией защитить от подмены открытого ключа, что является определенным ограничением для применения систем с открытым распределением ключей (Д.Чандлер в однозначно утверждает, что нет такой системы, в которой можно было бы гарантировать подлинность открытого ключа ЦСК).

Итак, отправитель запрашивает у ЦСК открытый ключ получателя сообщения. Этот процесс уязвим к атаке, в ходе которой атакующий вмешивается во взаимодействие между отправителем и получателем и может модифицировать трафик, передаваемый между ними. Поэтому открытый ключ получателя «подписывается» ЦСК.

Это означает, что ЦCК использовал свой секретный ключ для шифрования открытого ключа получателя.

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

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

Затем сеансовый ключ шифруется с использованием асимметричного криптоалгоритма (например, алгоритма Эль Гамаля) и открытого ключа получателя (полученного от ЦCК и проверенного).

Зашифрованный сеансовый ключ объединяется с шифртекстом, который включает в себя добавленную ранее ЭЦП.

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

Так как зашифрованный сеансовый ключ передается по незащищенной сети, он является очевидным объектом различных атак.

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

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

Далее получатель запрашивает у ЦСК открытый ключ ЭЦП отправителя.

После получения этого ключа, он проверяет его с помощью открытого ключа ЦСК и соответствующего асимметричного криптоалгоритма.

Затем с помощью алгоритма ЭЦП и открытого ключа адресанта проверяется подлинность сообщения.

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

Сертификат открытого ключа (public key certificate -PKC) представляет собой некоторую совокупность данных, правильное использование которых минимизирует риски атак на инфраструктуру открытых ключей (public key infrastructure - PKI).

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

В зависимости от конкретного приложения используются различные виды сертификатов. Среди них можно отметить такие, как сертификаты PGP (Pretty Good Privacy) и сертификаты IPSec (Internet Protocol Security), используемые соответствующими средствами.

Наибольшее распространение получил формат сертификата, определенного стандартом Х.509v3 Международного союза по телекоммуникациям. Примерная структура сертификата приведена на рис. 17.

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

В поле «Версия» заносится информация об используемой версии стандарта Х.509: версия 1, 2 или 3.

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

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

Пример сертификата в технологии Fortezza. Технология Fortezza была разработана для создания полно связных корпоративных вычислительных сетей, предназначенных для защищенного обмена документальной информацией органов федерального управления США. Аналогичные системы разработаны в Украине (средство КЗИ «Автограф» и др.) и России (средство КЗИ «Верба»).

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

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

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

В качестве основы системы аутентификации Fortezza использует схему аутентификации сертификатов X.509 и соглашения о наименовании объектов X.500. Общая длина сертификата 2820 байтов.

Технология Fortezza различает две структуры сертификатов.

Под «сертификатом Fortezza» понимается внутренняя структура данных технологии Fortezza, под «сертификатом X.509» - блок данных стандарта X.509, содержащийся в сертификате Fortezza (рис. 18).

Рис. 18. Структура сертификата в технологи Fortezza

Каждый сертификат Fortezza состоит из двух пар открытых/секретных ключей (одна из них предназначена для использования в KEA, другая – в DSA) и соответствующих им значений параметров P, Q и G.

Сертификат X.509 содержит открытые компоненты этих ключей. Открытые ключи всегда доступны пользователю криптокарты.

Ключи хранятся в закодированном виде: секретные – с помощью локальных ключей пользователя K_s (ключ K_s имеет размер 80 бит, находится в специальном регистре криптокарты и становится доступным после успешного ввода PIN пользователя), открытые – с помощью кодировки ASN.1.

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

Сертификаты X.509 могут быть размещены в базу данных специализированного «сертификационного» сервера (нескольких серверов) или распределены по сети и сохранены локально в криптокартах всех участников информационного обмена. Единственным условием является доступность сертификата для криптографических функций приложений Fortezza.

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

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

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

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

предоставляются в комплексные решения в области создания инфраструктуры открытых ключей (Public Key Infrastructure – PKI), описанной рабочей группой PKIX (Public Key Infrastructure Working Group).

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

На мировом рынке программных продуктов, поддерживающих инфраструктуру PKI, представлены следующие решения, получившие наиболее широкое распространение:

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

Деление продуктов, реализующих системы ЭЦП, на сервисы (услуги, модули) достаточно условно. Вместе с тем, при анализе архитектуры различных систем можно выделить некоторые общие черты, в том числе:

Сервис регистрации, обеспечивающий поддержку процедур обслуживания пользователей систем ЭЦП, включая:

- проверка данных пользователя, аутентификация и контроль полномочий;

- запись данных на электронные носители (смарт-карты, флэш-память и т.д.);

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

- проверка поступления запросов на сертификацию;

- отправка сертификата к сервису баз данных;

- создание перечня блокированных и отмененных сертификатов.

Сервис ведения баз данных, обеспечивающий:

- хранение и опубликование сертификатов, а также списков блокированных или отмененных сертификатов.

Сервис статуса сертификата (on-line certificate status protocol - OCSP), входящий в режиме on-line в состав сервиса баз данных и обеспечивающий:

- создание сообщений о статусе сертификатов;

- поддержку инфраструктуры открытых ключей PKI.

Сервис фиксации времени, ориентированный на:

- создание отметок времени для документов и сообщений;

- удостоверение существования документа или сообщения до определенного времени.

Сервис блокирования и отмены, включающий функции:

- проверки запросов на блокировку или отмену сертификата;

- передачи указаний на блокировку или отмену в сервис сертификации.

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

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

- управление ключами для Сервиса ведения баз данных и Сервиса фиксации времени;

Протоколы сервиса баз данных, в том числе:

а) Протокол опроса открытых сертификатов (LDAP);

2) ведомости об уникальности запрашиваемого сертификатом перечня;

3) в случае уникальности - проверка на блокирование или отмену;

4) подлежат проверке с помощью усиленной цифровой подписи.

1) проверка с помощью усиленной цифровой подписи, возможен on-line доступ.

Наиболее привлекательно при сравнении по критерию «модульность» выглядят решения Entrust и UniCERT, предоставляющие модули для всех областей использования инфраструктуры открытых ключей.

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

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

Существуют две модели доверия, схематично изображенные на рис. 19 и рис. 20:

– иерархическая модель, устанавливающая единую точку доверия двум или более Центрам сертификации ключей (ЦСК - Сertificate Authority, СА).

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

Основные различия между двумя моделями доверия заключаются в методах построения цепочек сертификатов и методах верификации сертификатов, выданных различными ЦСК.

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

Предпочтительнее по этим параметрам выглядят продукты Entrust, RSA и UniCert, которые обеспечивают гибридную модель доверия.

MCS и iPlanet поддерживают только иерархическую модель доверия.

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

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

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

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

Недостатком этой архитектуры является то, что в случае нарушения работы корневого центра сертификации ключей (ЦУО) практически нарушается работа всей системы.

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

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

Масштабируемость. Критерий масштабируемости часто очень свободно трактуется производителями тех или иных продуктов. Характеристика этого показателя типа: «высокая масштабируемость – 1 миллионов сертификатов», что скорее свидетельствует скорее о весьма средней базе данных, нежели о качестве самого решения PKI.

Признано, что масштабируемое решение должно удовлетворять следующим условиям.

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

2. Поддерживать различные программные платформы – операционные системы.

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

4. При необходимости взаимодействия различных реализаций PKI поддерживать гибридную модель доверия.

5. Обеспечивать поддержку построения доверительных отношений с центром сертификации, не входящим в имеющуюся иерархию, в реальном масштабе времени. Данное условие минимизирует затраты на построение, управление и техническую поддержку инфраструктуры PKI. Этому условию удовлетворяют решения Entrust, UniCERT и MCS.

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

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

В целом, при сравнении по критерию масштабируемости наиболее предпочтительными выглядят решения Entrust и UniCERT. Решения RSA и iPlanet немного отстают по критериям модульности и поддержки построения доверительных отношений в реальном масштабе времени.

Кроме того, решение iPlanet, как и решение MCS, не имеет поддержки инфраструктуры управления привилегиями (PMI). Решение Microsoft можно назвать масштабируемым исключительно в пределах платформы Windows.

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

В этом вопросе наиболее преуспели решения Entrust и UniCERT, обеспечивающие управление сертификатов посредством Web и e-mail.

Решения iPlanet, Microsoft и RSA предоставляют возможность получения сертификатов лишь с помощью web интерфейса, хотя следует отметить, что MCS на уровне предприятия – может выпускать сертификаты автоматически (auto-enrollment).

Удаление или приостановление действия сертификатов в решениях iPlanet и RSA осуществляется при помощи Web или администратором. MСS предлагает удалять сертификаты лишь используя административную консоль.

При сравнении методов публикации сертификатов следует отметить, что все продукты поддерживают публикацию в Сервисы каталогов и Active Diretory по протоколу LDAP, продукты UniCERT и Entrust так же поддерживают DAP.

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

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

Проверка статуса сертификата может осуществляться с помощью списков отозванных сертификатов (CRL) или измененных списков отозванных сертификатов (Delta CRL), а также путем определения статуса сертификата в реальном времени.

В расширениях сертификатов, находится унифицированный указатель информационного ресурса – стандартизованная строка символов, указывающая адрес документа в сети Internet с информацией о месте расположения списков. Указатель информационного ресурса может быть ассоциирован с ресурсом LDAP, HTTP, FTP или Х.500. На основании этой информации пользователь может получать актуальные состояния списков.

При сравнении по возможностям публикации CRL складывается почти равная ситуация: списки отозванных сертификатов за исключением MCS поддерживаются во всех продуктах путем опубликования вручную или периодически в файловую систему (HTTP и FTP) или Сервис директорий (Active Directory) при помощи протокола LDAP. В продукте MCS возможна только периодическая публикация.

Измененный список отзыва сертификатов содержит только сертификаты с измененным статусом.

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

Измененные списки отзыва сертификатов поддерживают Entrust и MСS.

Протокол определения статуса сертификата в реальном времени (OCSP – on-line certificate status protocol) основан на использовании службы сетевых каталогов, которая предоставляет информацию о статусе сертификата в режиме реального времени.

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

Только один продукт предоставляет собственный полноценный сервис определения статуса сертификата в реальном времени – iPlanet. Решение RSA ограничилось сервисом OCSP (в терминах RSA – OCSP Responder), поддерживающим только http запросы. Остальные продукты используют надстройку в виде программного продукта ValiCert Global VA Service, обеспечивающего сервис OCSP.

При сравнении по критерию управления сертификатами все про

Что делать, если нет взаимности? А теперь спустимся с небес на землю. Приземлились? Продолжаем разговор...

Конфликты в семейной жизни. Как это изменить? Редкий брак и взаимоотношения существуют без конфликтов и напряженности. Через это проходят все...

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

Что будет с Землей, если ось ее сместится на 6666 км? Что будет с Землей? - задался я вопросом...

Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте: