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

Сергей Муругов
Генеральный директор ООО "Топ Кросс"

Распоряжением Правительства РФ № 872-р от 25 июня 2009 г. был утвержден перечень государственных услуг и (или) функций, осуществляемых с использованием информационных и телекоммуникационных технологий (в том числе в электронном виде), также обеспечивающих возможность применения электронной цифровой подписи (ЭЦП). Реализация таких услуг на практике означает, что госструктурам неизбежно придется отвечать на вопрос о технологической готовности собственных систем к "боевому" использованию сервисов на основе ЭЦП, задел которых создавался на протяжении последних нескольких лет.

Нормативный базис

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

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

На практике эти виды операций выполняются с использованием инструментов инфраструктуры открытых ключей (PKI), цифровых сертификатов. В части основных документов нормативного базиса они регулируются ФЗ-1 и Гражданским кодексом РФ.

Федеральный закон "Об электронной цифровой подписи" определяет условия, при которых использование ЭЦП на электронных документах признается равнозначной собственноручной подписи на бумажном носителе. В самом определении (статья 3 Федерального закона) понятий закрытого и открытого ключей электронной цифровой подписи однозначно указывается, что криптографические ключи должны использоваться для выработки и проверки ЭЦП. Если обратиться к международному опыту, то те же рекомендации содержатся в стандарте RFC 4491 (S. Leontiev, D. Shefanovski. Using the GOST R 34.10-94, GOST R 34.10-2001 and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile, May 2006). Стандарт прямо указывает, что сертификаты, предназначенные для работы с ЭЦП, не должны содержать флагов keyEn-cipherment и keyAgreement, то есть не должны быть использованы для шифрования и согласования ключей.

Сертификаты ключа подписи и сертификаты открытого ключа

Для операций авторизации и защиты от перлюстрации с использованием шифрования на различных порталах, в "личных кабинетах", системах Интернет-банкинга, торговых площадках в подавляющем большинстве случаев используется защищенный протокол TLS. В настоящий момент существует DRAFT-вер-сия дополнения к стандарту протокола TLS с учетом использования отечественных криптографических алгоритмов (http://to-ols.ietf.org/html/draft-chudov-cry-ptopro-cptls-04#page-6). Описанная в данном документе реализация TLS с отечественной криптографией подразумевает два режима. При этом в одном из режимов закрытый ключ, соответствующий открытому ключу из сертификата, используется в алгоритме Diffie-Hellman, который, к слову, формально не является национальным криптографическим стандартом.

Помимо различного назначения закрытых ключей для этих двух видов операций между ними существуют и другие важные отличия как правового, так и технологического характеров. Так, в соответствии с ФЗ-1 (ст. 8, п. 1) удостоверяющий центр (УЦ) для сертификатов ключей подписи должен обладать необходимыми материальными возможностями для страхования своей ответственности. Очевидно, что чем больше число сертификатов было выпущено УЦ, тем выше страховые суммы. К издателям сертификатов, ключи которых используются для шифрования или авторизации, такие требования законодательно не предъявляются.

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

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

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

1. Издателем квалифицированных сертификатов (КС) является самоподписанный сертификат оператора (в данном случае в его роли выступает Национальный банк Польши). Этот квалифицированный сертификат используется для выпуска сертификатов издателей КС второго уровня, которые в свою очередь предназначены для выдачи квалифицированных сертификатов конечным пользователям.
2. Издателем неквалифицированных сертификатов (НКС) может быть как УЦ публичного назначения, так и корпоративного. Такой сертификат, как правило, не связан условиями подчиненности или иными доверительными связями с издателем квалифицированных сертификатов и издается самостоятельно - на базе собственного УЦ организации.

Структура сертификатов

Что касается структуры сертификатов, то совсем недавно вышли два приказа, посвященных этой проблеме (в Минком-связи и Федеральной налоговой службе России). Позитивный сдвиг очевиден: профильные структуры сделали первый шаг к наведению порядка в том многообразии несовместимых и противоречащих международным рекомендациям профилей сертификатов, которыми наводнен наш рынок. С другой стороны, в обоих приказах чувствуется тягостное наследие уже существующих технических реализаций, от которых и отказаться сложно, а как модернизировать - неясно. Кроме того, предложенные профили не дают ответ на вопрос, каким образом указывать полномочия владельца сертификата: явное указание правомочности-должности в СКП - весьма неудачная идея, поскольку в деловой сфере деятельности существуют отпуска, болезни, замещения должностей и т.п. С организационной точки зрения весьма затратно осуществлять отзыв действительного СКП и издавать новый по каждой из перечисленных причин. Такой подход, по меньшей мере, нерентабелен. Ну и совсем плохая идея нагружать СКП, общедоступный по своей природе, персональными данными, необходимыми прикладной информационной системе, тем самым выхолащивая 152-ФЗ "О персональных данных".

Вернемся к техническим вопросам

В качестве криптографического средства и ключевого носителя, гарантирующего неизвлекаемость закрытых ключей (к слову, это является аналогом требований ФЗ-1 (ст. 12, п. 1) - "хранить в тайне закрытый ключ электронной цифровой подписи"), в европейских странах используются смарт-карты, причем как минимум в двухслотовом варианте исполнения. Такая техническая реализация позволяет разделять хранилища для сертификата ключа подписи (КС) и для сертификата ключа авторизации - "опознавания" (НКС).

Следует обратить внимание, что для задач оказания значимых услуг в электронном виде используется два вида стандартов на интерфейсы взаимодействия со средствами электронной цифровой подписи - это CSP и PKCS#11. Если реализаций интерфейса CSP с национальными криптографическими алгоритмами на отечественном рынке имеется достаточно, то для второго базового гетерогенного интерфейса - PKCS#11 - реализации фактически отсутствуют. Одна из причин, объясняющая такую ситуацию, кроется в отставании подготовки и публикации в официальных документах стандартодержателя - компании RSA (подразделение безопасности корпорации EMC) - описания отечественного профиля этого интерфейса. Справедливости ради следует отметить, что силами экспертов технического комитета по стандартизации ТК26 (ПК 2) подготовлено и отправлено в RSA описание профиля PKCS#11 с использованием отечественных криптографических алгоритмов. В настоящий момент соответствующая DRAFT-версия (ftp://ftp.rsasecuri-ty.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30m1-d3.doc) размещена на ресурсах RSA для обсуждения специалистами. Скорее всего, уже к осени данное описание будет включено в состав очередного релиза PKCS#11 2.30.

Стандартизирование состава, содержания и описания зон электронного сообщения

Практическая реализация оказания государственных услуг в электронном виде также потребует внесение ясности, как минимум, в следующие вопросы: что есть электронный документ, какого перечня связанных с ним метаданных достаточно, каков должен быть профиль и формат представления электронного документа. Особенно внимательно стоит подойти к решению задачи указания периода действия (актуальности) документа. Дело в том, что электронный документ, как конечный продукт услуги в электронном виде, в дальнейшем будет использоваться и обрабатываться уже вне системы электронного документооборота создавшего его ведомства. Это означает, что задачи его использования "в последующих операциях или в последующей деятельности", которые вытекают из требований к документу действующего стандарта ГОСТ Р ИСО 15489-1-2007, предстоит решить на техническом уровне. Проще говоря, для обеспечения доверия к содержанию документа далеко не всегда достаточно зафиксировать содержание документа в момент выработки ЭЦП (используя штамп времени или указав текущую дату в самой ЭЦП). Часто требуется еще и обеспечить актуальность содержания документа в момент его использования, то есть иметь достоверную информацию о том, что содержание документа не потеряло своей актуальности для использования спустя некоторое (неопределенное) время после его создания.

Следует заметить, что работы по попытке стандартизировать состав, содержание и описание зон электронного сообщения ведутся достаточно давно. Особого внимания на этом поприще заслуживает межкорпоративный стандарт 2004 г. "Взаимодействие систем автоматизации документационного обеспечения управления", разработанный силами организаций, объединенных Гильдией управляющих документацией. В настоящий момент техническим комитетом по стандартизации ТК 459 (ПК 6) внесена первая редакция проекта национального стандарта ГОСТ Р "Системы электронного документооборота. Взаимодействие систем автоматизации документационного обеспечения управления. Требования к электронным сообщениям", основанная на этом межкорпоративном стандарте. Однако поставленные задачи намного сложнее, чем может показаться на первый взгляд, и ключ к ним необходимо искать во взаимосвязанном решении ряда проблем. Взять хотя бы всеми любимый и удобный в обработке язык XML, являющийся основой представления электронного сообщения в проекте стандарта.

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

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

Заключение

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

Комментарий эксперта

Алексей Сабанов
Заместитель генерального директора Aladdin

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

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

Продолжая мысль автора, замечу, что сегодня на отечественном рынке мы наблюдаем двоякую ситуацию. С одной стороны, нормативную базу, регулирующую сферу предоставления услуг на основе ЭЦП, еще предстоит дополнить и конкретизировать, с другой - технически мы готовы к обеспечению соответствующего уровня безопасности электронных сервисов. Об этом, в частности, было сказано на VI Тверском социально-экономическом форуме "Информационное общество", в докладе руководителя Росинформтехнологии В.Г. Матюхина, который констатировал, что информационно-технологическая структура для электронного правительства уже создана.

В этом контексте особого внимания заслуживает вопрос обеспечения безопасности электронных сервисов. Согласно Федеральному закону № 1-ФЗ "Об электронной цифровой подписи", ЭЦП является аналогом собственноручной подписи на бумаге и подтверждает юридическую значимость документа. Для того чтобы подписывать электронные документы, необходимо иметь сертификат ключа ЭЦП и соответствующий ему закрытый ключ. Таким образом, приоритетной задачей является снижение риска компрометации закрытого ключа. В Европе это понимают и выделяют понятие "квалифицированный сертификат" в отдельную сущность. Справедливо поднятый автором вопрос неизвлекаемости закрытого ключа ЭЦП сегодня успешно решается и в России с помощью специализированных отчуждаемых носителей ключевой информации, реализованных на базе смарт-карт-технологий. Однако если на Западе ни один УЦ не выдаст квалифицированного сертификата без смарт-карты, в России ситуация пока не столь однозначная.

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

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