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

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

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

О чём это

Статья посвящена поддержке электронной цифровой подписи (ЭЦП) документов в ОС ALT , а также специфике применения ЭЦП в Российской федерации.

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

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

Как всё это работает

Для того, чтобы зайти на сайт, не вводя при этом логин и пароль, а просто подсоединив к разъёму USB аппаратный токен, необходимо, чтобы в операционной системе корректно работал специализированный стек программных средств: обеспечивалась бы поддержка физических устройств, криптографических алгоритмов, программных интерфейсов, форматов и протоколов обмена данными. При этом совместимость криптографических алгоритмов, форматов и протоколов должна обеспечиваться также и за пределами области ответственности ОС - в удостоверяющем центре, выдающем сертификат, и на сайте, доступ к которому необходимо обеспечить.

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

Основные механизмы

В основе технологии ЭЦП, официально применяемой в РФ, находится инфраструктура открытых ключей . Рассмотрим её работу на примере.

Для наглядности рассмотрим механизм действия универсальных алгоритмов, пригодных как для электронной подписи, так и для шифрования. К таким алгоритмам, в том числе, относятся принятый в качестве стандарта Интернет RSA и российский ГОСТ Р 34.10-94 , действовавший в РФ в качестве стандарта электронной подписи до 2001 года. Более современные алгоритмы ЭЦП, к которым относятся, в том числе, действующие в настоящий момент ГОСТ Р 34.10-2001 и ГОСТ Р 34.10-2012, как правило, специализированы. Они предназначены исключительно для подписи документов, и непригодны для шифрования. Технически, отличие специализированных алгоритмов в том, что хэш в их случае не шифруется. Вместо шифрования над ним также с помощью закрытого ключа производятся другие вычисления, результат которых сохраняется в качестве подписи. При проверке подписи соответствующие комплиментарные вычисления производятся с помощью открытого ключа. Потеря универсальности в данном случае - плата за более высокую криптостойкость. Приведённый ниже пример с универсальным алгоритмом, возможно, чуть менее актуален, но, наверняка более понятен неподготовленному читателю.

Подпись документа

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

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

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

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

Проверка подписи

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

Ситуация с проверкой сертификата УЦ ровно такая же - он тоже подписан каким-то ключом. В итоге цепочка подписанных сертификатов заканчивается «корневым» сертификатом, который подписан сам собой. Такой сертификат называется самоподписанным. Для официально аккредитованных удостоверяющих центров Российской Федерации корневым сертификатом является сертификат Головного удостоверяющего центра Минкомсвязи.

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

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

Услуги удостоверяющих центров

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

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

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

Угрозы и атаки

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

По стандартам, принятым в Российской Федерации, при электронной подписи документов применяются криптографические алгоритмы, соответствующие Государственному стандарту РФ (ГОСТ Р). На момент написания данного текста (вторая половина 2016 года) ни для одного из алгоритмов, имеющих отношение к ЭЦП и имеющих в РФ статус стандарта, неизвестны способы атак, существенно отличающиеся по трудоёмкости от простого перебора. На практике это означает, что для атакующего, чей уровень доступа к вычислительным ресурсам ниже, чем у крупного государства, проще попытаться украсть ключ, чем взламывать алгоритм и подделывать подпись.

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

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

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

Токены

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

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

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

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

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

Ниже приведены списки поддерживаемых криптографических механизмов для токенов eToken и JaCarta ГОСТ. Для запроса списка механизмов применена открытая утилита pkcs11-tool с параметром «-M» (от слова «mechanism»), которая может выступать в роли клиентского приложения для любой библиотеки, реализующей в её сторону интерфейс PKCS#11. В качестве библиотек PKCS#11 применены libeToken.so и libjcPKCS11.so.1 для eToken и JaCarta соответственно. Библиотека для eToken распространяется в составе ПО «SafeNet», библиотека для JaCarta доступна для загрузки с сайта компании «Аладдин Р.Д.»

$ pkcs11-tool --module /usr/local/lib64/libeToken.so.9.1.7 -M Supported mechanisms: DES-MAC, keySize={8,8}, sign, verify DES-MAC-GENERAL, keySize={8,8}, sign, verify DES3-MAC, keySize={24,24}, sign, verify DES3-MAC-GENERAL, keySize={24,24}, sign, verify AES-MAC, keySize={16,32}, sign, verify AES-MAC-GENERAL, keySize={16,32}, sign, verify RC4, keySize={8,2048}, encrypt, decrypt DES-ECB, keySize={8,8}, encrypt, decrypt, wrap, unwrap DES-CBC, keySize={8,8}, encrypt, decrypt, wrap, unwrap DES-CBC-PAD, keySize={8,8}, encrypt, decrypt, wrap, unwrap DES3-ECB, keySize={24,24}, hw, encrypt, decrypt, wrap, unwrap DES3-CBC, keySize={24,24}, hw, encrypt, decrypt, wrap, unwrap DES3-CBC-PAD, keySize={24,24}, hw, encrypt, decrypt, wrap, unwrap AES-ECB, keySize={16,32}, encrypt, decrypt, wrap, unwrap AES-CBC, keySize={16,32}, encrypt, decrypt, wrap, unwrap AES-CBC-PAD, keySize={16,32}, encrypt, decrypt, wrap, unwrap mechtype-0x1086, keySize={16,32}, encrypt, decrypt, wrap, unwrap mechtype-0x1088, keySize={16,32}, encrypt, decrypt, wrap, unwrap RSA-PKCS-KEY-PAIR-GEN, keySize={1024,2048}, hw, generate_key_pair RSA-PKCS, keySize={1024,2048}, hw, encrypt, decrypt, sign, sign_recover, verify, verify_recover, wrap, unwrap RSA-PKCS-OAEP, keySize={1024,2048}, hw, encrypt, decrypt, wrap, unwrap RSA-PKCS-PSS, keySize={1024,2048}, hw, sign, verify SHA1-RSA-PKCS-PSS, keySize={1024,2048}, hw, sign, verify mechtype-0x43, keySize={1024,2048}, hw, sign, verify mechtype-0x44, keySize={1024,2048}, hw, sign, verify mechtype-0x45, keySize={1024,2048}, hw, sign, verify RSA-X-509, keySize={1024,2048}, hw, encrypt, decrypt, sign, sign_recover, verify, verify_recover, wrap, unwrap MD5-RSA-PKCS, keySize={1024,2048}, hw, sign, verify SHA1-RSA-PKCS, keySize={1024,2048}, hw, sign, verify SHA256-RSA-PKCS, keySize={1024,2048}, hw, sign, verify SHA384-RSA-PKCS, keySize={1024,2048}, hw, sign, verify SHA512-RSA-PKCS, keySize={1024,2048}, hw, sign, verify RC4-KEY-GEN, keySize={8,2048}, generate DES-KEY-GEN, keySize={8,8}, generate DES2-KEY-GEN, keySize={16,16}, generate DES3-KEY-GEN, keySize={24,24}, generate AES-KEY-GEN, keySize={16,32}, generate PBE-SHA1-RC4-128, keySize={128,128}, generate PBE-SHA1-RC4-40, keySize={40,40}, generate PBE-SHA1-DES3-EDE-CBC, keySize={24,24}, generate PBE-SHA1-DES2-EDE-CBC, keySize={16,16}, generate GENERIC-SECRET-KEY-GEN, keySize={8,2048}, hw, generate PBA-SHA1-WITH-SHA1-HMAC, keySize={160,160}, hw, generate PBE-MD5-DES-CBC, keySize={8,8}, generate PKCS5-PBKD2, generate MD5-HMAC-GENERAL, keySize={8,2048}, sign, verify MD5-HMAC, keySize={8,2048}, sign, verify SHA-1-HMAC-GENERAL, keySize={8,2048}, sign, verify SHA-1-HMAC, keySize={8,2048}, sign, verify mechtype-0x252, keySize={8,2048}, sign, verify mechtype-0x251, keySize={8,2048}, sign, verify mechtype-0x262, keySize={8,2048}, sign, verify mechtype-0x261, keySize={8,2048}, sign, verify mechtype-0x272, keySize={8,2048}, sign, verify mechtype-0x271, keySize={8,2048}, sign, verify MD5, digest SHA-1, digest SHA256, digest SHA384, digest SHA512, digest mechtype-0x80006001, keySize={24,24}, generate $ pkcs11-tool --module /usr/local/lib64/libjcPKCS11.so.1 -M Supported mechanisms: GOSTR3410-KEY-PAIR-GEN, hw, generate_key_pair GOSTR3410, hw, sign, verify GOSTR3410-WITH-GOSTR3411, hw, sign, verify mechtype-0x1204, hw, derive GOSTR3411, hw, digest mechtype-0x1220, generate mechtype-0xC4321101 mechtype-0xC4321102 mechtype-0xC4321103 mechtype-0xC4321104 mechtype-0xC4900001

Видно, что список поддерживаемых механизмов для eToken очень длинный, но не включает алгоритмы ГОСТ. Список поддерживаемых механизмов JaCarta включает только алгоритмы ГОСТ, но зато в объёме, необходимом для реализации функциональности ЭЦП на аппаратном токене.

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

В качестве примеров исключительно программных токенов можно привести «Рутокен S» и «Рутокен Lite». В качестве примеров аппаратных токенов, не поддерживающих сертифицированные в России криптографические алгоритмы, - устройства «eToken»; в качестве поддерживающих российскую криптографию - «Рутокен ЭЦП», «JaCarta ГОСТ».

Криптопровайдеры

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

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

К сертифицированным на территории Российской Федерации для ЭЦП криптопровайдерам относятся, в частности: «Рутокен ЭЦП», «JaCarta ГОСТ», «КриптоПро CSP», «ЛИССИ-CSP», «VipNet CSP». Первые два реализованы непосредственно на аппаратных токенах, остальные - в виде пользовательских приложений. Важно понимать, что при приобретении сертифицированного в РФ аппаратного токена мы уже приобретаем сертифицированный в РФ криптопровайдер, и необходимости - технологической и юридической - в покупке ещё одного криптопровайдера нет.

Кроме набора поддерживаемых алгоритмов, криптопровайдеры различаются также набором криптографических функций - зашифрованию и расшифрованию документов, подписанию и проверке подписи, наличию графического интерфейса пользователя и так далее. Причём, из всего этого набора функций сертифицированный криптопровайдер должен выполнять только те, которые относятся непосредственно к реализации криптографических алгоритмов. Всё остальное может быть выполнено сторонним приложением. Именно так и работают криптопровайдеры на аппаратных токенах: пользовательский интерфейс реализуется сторонним приложением, не подлежащим обязательной сертификации. Приложение, реализующее пользовательский интерфейс общается с криптопровайдером на токене через другой стандартный интерфейс - PKCS#11. При этом с точки зрения пользователя работа с ключами происходит, например, непосредственно из html-браузера Firefox. На самом же деле браузер через интерфейс PKCS#11 задействует специальную программную прослойку, в которой реализованы механизмы доступа к конкретному аппаратному токену.

Кроме термина «криптопровайдер» существует ещё один близкий по смыслу термин - «средство криптографической защиты информации» (СКЗИ). Чёткого различия между этими двумя понятиями нет. Первый термин менее официальный, второй чаще используется применительно к сертифицированным техническим решениям. Так как в данном документе, в основном, описываются технологические, а не формальные аспекты, мы чаще будем пользоваться термином «криптопровайдер».

Реализация механизмов

Алгоритмы электронной подписи

В данный момент в Российской Федерации для квалифицированной электронной подписи официально разрешено использовать только два алгоритма подписи и два алгоритма хэширования. До конца 2017 года разрешено использовать ГОСТ Р 34.10-2001 совместно с алгоритмом хэширования ГОСТ Р 34.11-94 . С начала 2018 года разрешено использовать только ГОСТ Р 34.10-2012 и хэши по ГОСТ Р 34.11-2012 . В ситуациях, когда не требуется обязательное использование алгоритмов ГОСТ, можно пользоваться любыми доступными алгоритмами.

Например, сейчас большинство веб-сайтов, доступных по протоколу HTTP, не умеет использовать алгоритмы ГОСТ для взаимной аутентификации клиента и сервера. В случае взаимодействия с одним из таких сайтов, клиентской стороне также придётся применить алгоритмы «иностранного производства». Но, например, если хочется использовать аппаратный токен в качестве хранилища ключей для аутентификации на сайте Госуслуг, придётся выбирать токен с поддержкой ЭЦП по ГОСТ.

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

Интерфейсы, форматы и протоколы

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

• PC/SC - низкоуровневый интерфейс доступа к криптографическим устройствам, в том числе - программным и аппаратным токенам;
• PKCS#11 - высокоуровневый интерфейс для взаимодействия с аппаратными криптографическими модулями, можно рассматривать как унифицированный интерфейс доступа к криптопровайдерам;
• PKCS#15 - формат контейнера с ключами электронной подписи, предназначенный для хранения на физическом устройстве;
• PKCS#12, PEM - форматы контейнеров с ключами электронной подписи предназначенные для хранения в файлах, бинарных и текстовых соответственно;
• PKCS#10 - формат документа - запроса на подпись, отправляемого клиентом в УЦ для получения подписанного сертификата.

Важно понимать, что такие стандарты, как PKCS#11 или PKCS#15 первоначально разрабатывались без учёта специфики сертифицированных в Российской федерации криптосредств. Поэтому для реализации полноценной поддержки отечественной криптографии стандарты пришлось, и приходится, дорабатывать. Процесс принятия поправок к стандартам долгий, поэтому, пока доработанные стандарты не были окончательно приняты, появились их реализации, несовместимые между собой. В том числе, это касается сертифицированных в РФ криптопровайдеров. Так, сейчас все сертифицированные криптопровайдеры имеют несовместимые между собой реализации контейнера для хранения ключей на токене. Что касается стандартов обмена данными - PKCS#10, PKCS#12, PEM - их реализации, к счастью, обычно между собой совместимы. Также, обычно не возникает разночтений в трактовке стандарта PC/SC.

Вопросами доработки стандартов, выработки рекомендаций, обеспечения совместимости в области ЭЦП в Российской Федерации в данный момент занимается специальная организация - Технический комитет по стандартизации «Криптографическая защита информации» (TK 26), в которую входят эксперты, представители государственных структур, разработчики криптопровайдеров и другие заинтересованные лица. Об эффективности работы комитета можно спорить, но даже сам факт существования такой площадки крайне важен.

Программная часть

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

• реализации интерфейса для низкоуровневого доступа к хранилищам контейнеров с ключами - например, интерфейса PC/SC для доступа к физическим устройствам - токенам;
• модуля, реализующего интерфейс PKCS#11 для взаимодействия с криптопровайдером - например, выполненном на аппаратном токене;
• криптопровайдера, реализующего соответствующие криптографические алгоритмы и выполняющего действия с ними - например, электронную подпись или шифрование данных;
• пользовательского приложения, взаимодействующего с другой - по отношению к криптопровайдеру - стороны с модулем PKCS#11, и выполняющего от имени пользователя такие операции, как электронная подпись или аутентификация.

Пример стека:

• приложение командной строки cryptcp из состава ПО «КриптоПро CSP» взаимодействует с библиотекой libcppksc11.so через интерфейс PKCS#11 и осуществляет возможность подписания документов секретным ключом пользователя; при этом функции криптопровайдера полностью реализованы в компонентах ПО «КриптоПро CSP», криптопровайдер аппаратного токена не задействуется.

Другой пример:

• открытое программное обеспечение pcsc-lite реализует интерфейс PC/SC для взаимодействия с аппаратным токеном «Рутокен ЭЦП»;
• библиотека libcppksc11.so из состава ПО «КриптоПро CSP» обеспечивает взаимодействие с размещённым на токене контейнером, в котором хранится закрытый ключ и сертификат пользователя;
• приложение «КриптоПро ЭЦП Browser plugin», работающее в составе html-браузера Firefox взаимодействует с библиотекой libcppksc11.so через интерфейс PKCS#11 и осуществляет возможность подписания документов в интерфейсе браузера на сайтах электронных торговых площадок; при этом функции криптопровайдера полностью реализованы в компонентах ПО «КриптоПро CSP», криптопровайдер аппаратного токена не задействуется.

Третий пример:

• открытое программное обеспечение pcsc-lite реализует интерфейс PC/SC для взаимодействия с аппаратным токеном «Рутокен ЭЦП»;
• библиотека librtpksc11.so производства компании «Актив» обеспечивает взаимодействие с криптопровайдером токена;
• криптопровайдер токена осуществляет функции подписи секретным ключом передаваемых ему данных; секретный ключ при этом не покидает пределов токена;
• приложение «Рутокен Плагин», работающее в составе html-браузера Firefox взаимодействует с библиотекой librtpksc11.so через интерфейс PKCS#11 и осуществляет возможность подписания документов в интерфейсе браузера на совместимых сайтах; при этом функции криптопровайдера полностью реализованы на аппаратном токене.

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

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

Если удостоверяющий центр, в котором мы планируем получить сертификат, не готов работать с запросами на подпись в формате PKCS#10 и умеет работать только с программными токенами (то есть, воспринимает любой токен как программный), у нас не остаётся выбора. Как правило, в этом случае ПО УЦ сгенерирует для нас пару ключей, запишет её на токен, тут же сгенерирует на базе открытого ключа и наших персональных данных запрос на подпись, подпишет его, и сохранит сертификат на токене. Сертификат и ключ при этом будут находиться в контейнере закрытого формата, известного только разработчику ПО УЦ. Соответственно, для доступа к контейнеру с ключами придётся покупать криптопровайдер того же разработчика. И область применения ЭЦП будет ограничена возможностями ПО одного конкретного разработчика. Покупать в этом случае аппаратный токен смысла нет - можно обойтись программным. Токен в этом случае обязательно придётся нести в УЦ.

Если удостоверяющий центр, в котором мы планируем получить сертификат, готов работать с запросами на подпись в формате PKCS#10, то нам не важно, какое именно ПО используется в этом УЦ. Мы сможем использовать у себя тот криптопровайдер, который совместим с нашими целевыми приложениями. Например, с электронными торговыми площадками или сайтом Госуслуг. Нести токен в УЦ в этом случае не нужно, достаточно сгенерировать запрос на подпись и предъявить его там вместе со своими бумажными документами; получить сертификат, и самостоятельно сохранить его на токене с помощью выбранного криптопровайдера.

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

Аппаратная часть

Среди представленных на российском рынке токенов можно отметить следующие:

Аппаратные носители с поддержкой российской криптографии: Рутокен ЭЦП , JaСarta ГОСТ , MS_KEY K .

Рассмотрим в качестве примера списки поддерживаемых криптографических механизмов аппаратного Рутокен ЭЦП и программного Рутокен_Lite:

$ pkcs11-tool --module /usr/local/lib64/librtpkcs11ecp.so -M Supported mechanisms: RSA-PKCS-KEY-PAIR-GEN, keySize={512,2048}, hw, generate_key_pair RSA-PKCS, keySize={512,2048}, hw, encrypt, decrypt, sign, verify RSA-PKCS-OAEP, keySize={512,2048}, hw, encrypt, decrypt MD5, digest SHA-1, digest GOSTR3410-KEY-PAIR-GEN, hw, generate_key_pair GOSTR3410, hw, sign, verify mechtype-0x1204, hw, derive GOSTR3411, hw, digest GOSTR3410-WITH-GOSTR3411, hw, digest, sign mechtype-0x1224, hw, wrap, unwrap mechtype-0x1221, hw, encrypt, decrypt mechtype-0x1222, hw, encrypt, decrypt mechtype-0x1220, hw, generate mechtype-0x1223, hw, sign, verify $ pkcs11-tool --module /usr/local/lib64/librtpkcs11ecp.so -M Supported mechanisms:

Как видим, списки поддерживаемых криптографических механизмов Рутокен Lite пуст, в отличие от Рутокен ЭЦП, который включает алгоритмы ГОСТ и RSA.

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

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

Из недавних разработок хотелось бы отметить Рутокен ЭЦП 2.0 с поддержкой стандарта ГОСТ Р 34.10-2012.

Применение

Инструменты пользователя

Открытые инструменты

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

PCSC lite

Реализация PC/SC, разработанная в рамках проекта PCSC lite , является эталонной для ОС семейства Linux. Она входит в состав любого из рассматриваемых в настоящем документе вариантов программного стека для работы с ЭЦП. В дальнейшем, если конкретный вариант реализации не указан, будем считать её задействованной по умолчанию.

OpenSC

Библиотека, реализующая интерфейс PKCS#11, а также набор прикладных инструментов, задействующих её функциональность, была разработана в рамках проекта OpenSC . Инструментарием поддерживается множество аппаратных токенов, среди которых Рутокен ЭЦП, поддержка которого была добавлена специалистами компании «Актив», разрабатывающей токены семейства Рутокен.

С помощью утилит OpenSC можно выполнить на аппаратном токене, в частности, следующие действия:

• инициализировать токен - сбросить настройки к первоначальному состоянию;
• установить PIN-коды администратора и пользователя (если поддерживаются);
• сгенерировать пару ключей (если поддерживается библиотекой PKCS#11);
• импортировать на токен сертификат, подписанный удостоверяющим центром.

Библиотека PKCS#11 из комплекта OpenSC позволяет выполнять на поддерживаемых токенах полный набор операций с электронной подписью. К поддерживаемым токенам относится также Рутокен ЭЦП.

Здесь важно понимать, что для Рутокен ЭЦП существует два разных варианта поддержки программным обеспечением, не совместимых между собой по формату хранения ключей на токене. При использовании библиотеки PKCS#11 из состава OpenSC мы можем пользоваться открытым стеком ПО, а при использовании бесплатно распространяемой закрытой библиотеки производства компании «Актив», - закрытым стеком «Актива».

OpenSSL

Чтобы полноценно использовать возможности ЭЦП, кроме собственно библиотеки PKCS#11 должны быть реализованы пользовательские приложения, предоставляющие оператору доступ к функциям библиотеки и возможностям токена. Ярким примером такой реализации является открытое ПО из проекта OpenSSL . В нём поддерживаются, в частности, следующие функции:

• зашифрование данных;
• расшифрование данных;
• подпись документа;
• проверка подписи;
• формирование запроса на подпись сертификата;
• импорт сертификата;
• экспорт сертификата.

Кроме того, с помощью OpenSSL можно реализовать функциональность полноценного удостоверяющего центра, в том числе:

• выдачу клиентских сертификатов путём подписания запросов на подпись в формате PKCS#10;
• отзыв клиентских сертификатов;
• учёт выданных и отозванных сертификатов.

Единственная на текущий момент недоработка OpenSSL, не позволяющая пока реализовать полнофункциональный вариант программного стека ЭЦП на базе открытого ПО - отсутствие открытого модуля для взаимодействия с библиотеками PKCS#11 с поддержкой алгоритмов ГОСТ. Существует закрытая реализация такого модуля, выполненная в компании «Актив», но она не входит в базовую поставку OpenSSL, и поэтому с выходом новых версий OpenSSL совместимость периодически нарушается. Открытая реализация этого модуля пока не поддерживает алгоритмы ГОСТ.

Firefox

Кроме OpenSSL взаимодействовать с библиотеками PKCS#11 умеет также всем известный html-браузер Firefox . Для подключения библиотеки PKCS#11 нужно зайти в меню управления настройками «Preferences», далее - в вертикальном списке слева выбрать «Advanced», в горизонтальном списке выбрать «Certificates», нажать кнопку «Security Devices», в появившемся диалоговом окне нажать кнопку «Load». Появится ещё одно окно с возможностью выбора пути к файлу с библиотекой PKCS#11 и возможностью ввода локального имени для этой конкретной библиотеки. Можно таким образом загрузить несколько разных модулей PKCS#11 для разных типов физических и виртуальных устройств.

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

КриптоПро

В версиях КриптоПро CSP до 4.0 включительно применяется ручное управление локальными кэшами для хранения пользовательских сертификатов и сертификатов УЦ. Для полноценной работы с пользовательским сертификатом необходимо, чтобы его копия лежала в одном локальном кэше, а полная цепочка сертификатов УЦ до корневого включительно - в другом. Технологически эта особенность КриптоПро, строго говоря, не вполне обоснована: цепочку имеет смысл проверять при аутентификации; собственно факт валидности сертификата на возможность подписи не влияет. Тем более, если это наш собственный сертификат и мы знаем, откуда он взялся. В свежих на момент написания статьи бета-версиях КриптоПро CSP, по словам разработчиков, реализована автоматическая загрузка цепочки сертификатов УЦ. Но за тем, чтобы в локальном кэше пользовательских сертификатов находился только тот, который в данный момент используется, похоже, всё ещё приходится следить вручную.

Сторонние разработчики предпринимают попытки написания графических интерфейсов к КриптоПро CSP, облегчающие проведение рутинных пользовательских операций. Примером такой утилиты может служить rosa-crypto-tool , автоматизирующий подписание и зашифрование документов. Пакет в дистрибутивах ALT.

КриптоПро УЦ

Для ПО «Лисси СОФТ» характерно строгое соблюдение стандартов и технических спецификаций. Криптопровайдеры, в том числе уникальные, оформлены в виде библиотек PKCS#11. По заявлениям разработчиков, они хорошо стыкуются с открытым программным обеспечением, также ориентированным на поддержку стандартов. Например, с html-браузерами и утилитами из комплекта OpenSSL.

Применительно к организации доступа к сайтам государственных услуг продукты «Лисси СОФТ» также представляют интерес. В первую очередь - совместимостью с «IFCPlugin» - браузерным плагином, реализующим механизмы ЭЦП на портале Госуслуг. Во-вторых - возможностью ПО удостоверяющих центров работать с запросами на подпись сертификата в формате PKCS#10.

Браузеры

Иногда, для доступа к сайтам, на которых мы планируем применять механизмы электронной подписи, приходится задействовать другие технологии, использующие российскую криптографию. Например, алгоритмы ГОСТ могут использоваться для организации шифрованного канала передачи данных. В этом случае необходима поддержка соответствующих алгоритмов в браузере. К сожалению, официальные сборки Firefox и Chromium пока не поддерживают российскую криптографию в полной мере. Поэтому приходится пользоваться альтернативными сборками. Такие сборки есть, например, в арсенале криптосредств компаний «КриптоПро» и «Лисси СОФТ», а также, в дистрибутивах Альт.

Сайты

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

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

Госуслуги

В результате исследования выяснилось, что по состоянию на 14 декабря 2016 года большинство федеральных торговых площадок - « », «РТС-тендер » и «Сбербанк-АСТ » готовы к использованию на рабочих местах под управлением ОС семейства Linux. Оставшиеся две площадки пока не обеспечивают даже возможность входа по клиентскому сертификату. Планируются ли их разработчиками какие-то меры по обеспечению совместимости, к сожалению, пока выяснить не удалось.

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

В обобщённом виде результаты исследования приведены в таблице:

Для ЭТП, обеспечивающих совместимость с Linux, единственным поддерживаемым криптосредством в данный момент является Cades plugin, который умеет использовать в качестве криптопровайдера только КриптоПро CSP. Таким образом, хорошая новость заключается в том, что получить токен для доступа к электронным торговым площадкам очень просто - большинство УЦ выдают именно их. Плохие новости - токен будет программным и не будет совместим с сайтом Госуслуг.

Для остальных торговых площадок пока единственным средством доступа к функциональности ЭЦП является компонент ОС Windows под названием CAPICOM . Специалистами компании «Этерсофт » проведена исследовательская работа, в результате которой выяснена теоретическая возможность запуска CAPICOM в среде Wine .

Прочие сайты

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

Пример готового решения

К сожалению, на текущий момент авторам данного документа неизвестен способ применения одного и того же токена одновременно на сайте Госуслуг и на электронных торговых площадках. Поэтому придётся сделать два токена с двумя парами ключей и двумя сертификатами соответственно. Законодательно это не запрещено, технически - осуществимо. Финансово тоже вполне реально: одним токеном будет, например, аппаратный Рутокен ЭЦП, другим - какая-нибудь старая модель eToken, которую сейчас вполне можно найти за символическую плату.

Доступ к сайту Госуслуг

Для доступа к Госуслугам возьмём Рутокен ЭЦП и выполним следующие действия:

1. загрузим ПО «Рутокен плагин» со страницы по ссылке ;
2. установим Рутокен плагин - скопируем файлы плагина (npCryptoPlugin.so и librtpkcs11ecp.so) в ~/.mozilla/plugins/ ;
3. зайдём на сайт с ПО «Центр регистрации» и по инструкции выполним следующие действия - проинициализируем токен, сгенерируем пару ключей, сгенерируем и сохраним локально файл с запросом на подпись в формате PKCS#10;
4. обратимся в УЦ, готовый выдать нам сертификат по запросу на подпись, получим сертификат в виде файла;
5. в интерфейсе «Центра регистрации» сохраним сертификат из полученного файла на токене;
6. по ссылке загрузим пакет формата «deb» - файл IFCPlugin-x86_64.deb ;
7. с помощью ПО «Midnight Commander» (команда mc ) «зайдём» в файл пакета как в каталог;
8. скопируем содержимое каталога CONTENTS/usr/lib/mozilla/plugins в локальный каталог ~/.mozilla/plugins ;
9. в браузере Firefox на сайте Госуслуг пройдём последовательно по ссылкам «Войти» и «Войти с помощью электронных средств».

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

Доступ к электронным торговым площадкам

Для доступа к сайтам электронных торговых площадок, поддерживающих работу в Linux, выполним следующие действия:

1. с любым официально продававшимся в РФ токеном обратимся в любой удостоверяющий центр, использующий по «КриптоПро УЦ», и получим сохранённые на токене пользовательский сертификат и секретный ключ в контейнере формата, поддерживаемого ПО КриптоПро;
2. в соответствии с инструкцией установим ПО «CryptoPro CSP» и «Cades plugin» для браузера Chromium;
3. с помощью браузера Chromium зайдём на сайты электронных торговых площадок и начнём работу с ними согласно официальным инструкциям.

Возможность подписи документов в виде файлов будет доступна через консольные утилиты КриптоПро и через сторонние приложения-обёртки типа уже упоминавшегося rosa-crypto-tool .

РЕГЛАМЕНТ

Удостоверяющего центра

-Софт»

1. Сведения об Удостоверяющем центре................................................................................... 2

2. Термины и определения.......................................................................................................... 2

3. Общие положения.................................................................................................................... 4

4. Права и обязанности сторон................................................................................................... 6

5. Правила пользования услугами Удостоверяющего Центра............................................... 9

6. Прочие условия....................................................................................................................... 13

7. Вознаграждение Удостоверяющего Центра........................................................................ 21

8. Разрешение споров................................................................................................................. 21

9. Ответственность сторон......................................................................................................... 21

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

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

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

Квалифицированный сертификат ключа проверки электронной подписи (далее - сертификат) - сертификат ключа проверки электронной подписи, выданный аккредитованным Удостоверяющим центром или доверенным лицом аккредитованного Удостоверяющего центра.

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

Ключ электронной подписи - уникальная последовательность символов, предназначенная для создания электронной подписи.

Ключ проверки электронной подписи - уникальная последовательность символов, однозначно связанная с ключом электронной подписи и предназначенная для проверки подлинности электронной подписи (далее - проверка электронной подписи).

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

Единый реестр – общий структурированный справочник, включающий:

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

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

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

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

Псевдоним – вымышленное имя физического лица, которое это лицо сознательно и легально принимает для регистрации в Удостоверяющем Центре .

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

Рабочий день Удостоверяющего Центра (далее – рабочий день) – промежуток времени с 09:00 до 18:00 каждого дня недели за исключением выходных и праздничных дней. Выходные и праздничные дни определяются с учетом переносов дней на основании решений Правительства РФ.

Реестр Удостоверяющего Центра – набор документов Удостоверяющего Центра в электронной и/или бумажной форме, включающий следующую информацию:

· реестр заявлений о присоединении к Регламенту Удостоверяющего Центра ;

· реестр заявлений на регистрацию пользователя в Удостоверяющем Центре ;

· реестр зарегистрированных пользователей УЦ;

· реестр заявлений на изготовление сертификата ключа проверки электронной подписи;

· реестр заявлений на аннулирование (отзыв) сертификата ключа проверки электронной подписи;

· реестр заявлений на приостановление/возобновление действия сертификата ключа проверки электронной подписи;

· реестр заявлений на подтверждение подлинности электронной подписи в электронном документе;

· реестр заявлений на подтверждение электронной подписи уполномоченного лица Удостоверяющего Центра в изданных сертификатах;

· реестр сертификатов ключей проверки электронной подписи;

· реестр изготовленных списков отозванных сертификатов.

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

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

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

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

3. Общие положения

3.1. Предмет Регламента

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

3.2. Присоединение к Регламенту

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

3.2.2. Под регистрацией пользователей УЦ понимается внесение регистрационной информации о пользователях УЦ в реестр Центра регистрации Удостоверяющего Центра.

3.3. Изменение Регламента

3.3.1. Внесение изменений (дополнений) в Регламент, включая приложения к нему, производится Удостоверяющим Центром в одностороннем порядке.

3.3.2. Уведомление о внесении изменений (дополнений) в Регламент осуществляется Удостоверяющим Центром путем обязательного размещения указанных изменений (дополнений) на сайте Удостоверяющего Центра по адресу –
http://ca. soft. ***** с обязательным внесением номера редакции и даты внесения изменений.

3.3.3. Все изменения (дополнения), вносимые Удостоверяющим Центром в Регламент по собственной инициативе и не связанные с изменением действующего законодательства Российской Федерации вступают в силу и становятся обязательными по истечении двух месяцев с даты размещения указанных изменений и дополнений в Регламенте на сайте Удостоверяющего Центра по адресу - http://ca. soft. *****

3.3.4. Все изменения (дополнения), вносимые Удостоверяющим Центром в Регламент в связи с изменением действующего законодательства Российской Федерации вступают в силу одновременно с вступлением в силу изменений (дополнений) в указанных актах.

3.3.5. Любые изменения и дополнения в Регламенте с момента вступления в силу равно распространяются на всех лиц, присоединившихся к Договору публичной оферты на оказание услуг Удостоверяющего центра , в том числе присоединившихся к Договору ранее даты вступления изменений (дополнений) в силу. В случае несогласия с изменениями (дополнениями) Сторона Договора имеет право до вступления в силу таких изменений (дополнений) на расторжение Договора публичной оферты в порядке, предусмотренном п.11 Договора публичной оферты.

3.3.6. Все приложения, изменения и дополнения к настоящему Регламенту являются его составной и неотъемлемой частью.

3.4. Услуги, предоставляемые Удостоверяющим Центром

В процессе своей деятельности Удостоверяющий Центр предоставляет потребителям (пользователям УЦ) следующие виды услуг:

· Внесение в реестр Удостоверяющего Центра регистрационной информации о пользователях Удостоверяющего Центра (далее – пользователях УЦ).

· Изготовление сертификатов ключей проверки электронной подписи пользователей УЦ в электронной форме и копий сертификатов ключей проверки электронной подписи пользователей УЦ на бумажном носителе.

· Ведение реестра изготовленных сертификатов ключей проверки электронной подписи пользователей УЦ.

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

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

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

· Предоставление пользователям УЦ сведений об аннулированных и приостановленных сертификатах ключей проверки электронной подписи.

· Подтверждение подлинности электронных подписей в электронных документах по обращениям пользователей УЦ.

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

4. Права и обязанности сторон

4.1. Удостоверяющий Центр имеет право:

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

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

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

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

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

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

4.2. Пользователь Удостоверяющего Центра имеет право:

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

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

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

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

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

4.2.6. Обратиться в Удостоверяющий Центр за подтверждением подлинности электронных подписей в электронных документах.

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

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

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

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

4.2.11. Обратиться в Удостоверяющий Центр для приостановления действия сертификата ключа проверки электронной подписи в течение срока действия соответствующего ключа электронной подписи.

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

4.3. Обязанности Удостоверяющего Центра

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

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

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

4.3.4. Удостоверяющий Центр обязан организовать свою работу по GMT (Greenwich Mean Time) с учетом часового пояса города Москва. Удостоверяющий Центр обязан синхронизировать по времени все свои программные и технические средства обеспечения деятельности.

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

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

4.3.7. Удостоверяющий Центр обязан:

· обеспечить уникальность серийных номеров изготавливаемых сертификатов ключей проверки электронной подписи пользователей УЦ;

· обеспечить уникальность значений ключей проверки электронной подписи в изготовленных сертификатах пользователей УЦ;

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

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

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

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

4.3.12. Удостоверяющий Центр обязан вести реестр Удостоверяющего Центра.

4.4. Обязанности пользователя Удостоверяющего Центра

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

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

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

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

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

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

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

4.4.8. Пользователь УЦ обязан регулярно, не реже чем один раз в 10 дней, просматривать Internet страницу Удостоверяющего Центра , расположенную по адресу http://ca. soft. ***** на предмет изменения Регламента.

5. Правила пользования услугами Удостоверяющего Центра

5.1. Регистрация пользователей

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

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

Форма заявления на регистрацию приведена в Приложениях №№ 2.1, 2.2 к настоящему Регламенту. Пользователь, являющийся уполномоченным представителем Стороны, присоединившейся к Регламенту (если Сторона Регламента - юридическое лицо), должен предоставить доверенность, выданную на его имя по форме Приложения № 3.1 настоящего Регламента.

Регистрация пользователя в Удостоверяющем Центре может быть осуществлена уполномоченным представителем пользователя УЦ, действующим на основании доверенности на осуществление регистрации в Удостоверяющем Центре . Доверенность на осуществление регистрации в Удостоверяющем Центре должна быть составлена по форме Приложений №№4.1, 4.2 настоящего Регламента.

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

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

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

5.2. Изготовление и получение сертификата ключа проверки электронной подписи

Формирование сертификата ключа проверки электронной подписи пользователя осуществляется Удостоверяющим Центром на основании запроса на изготовление сертификата ключа проверки электронной подписи. Запрос на изготовление сертификата пользователя подается в электронном виде с использованием программного обеспечения пользователя УЦ.

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

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

Форма заявления на изготовление сертификата ключа проверки электронной подписи приведена в Приложениях № 5.1, 5.2 к настоящему Регламенту.

5.3. Аннулирование (отзыв) сертификата ключа проверки электронной подписи Пользователя УЦ

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

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

Бумажная форма заявления на аннулирование (отзыв) сертификата ключа проверки электронной подписи приведена в Приложении № 7.1, 7.2 к настоящему Регламенту.

Сторона, присоединившаяся к Регламенту, являющаяся юридическим лицом, вправе аннулировать (отозвать) сертификаты ключей проверки электронной подписи своих полномочных представителей, зарегистрированных в Удостоверяющем центре. Аннулирование (отзыв) сертификатов ключей проверки электронной подписи Пользователей УЦ, являющихся полномочными представителями Стороны, присоединившейся к Регламенту, осуществляется путем отзыва доверенности, на основании которой Пользователю УЦ предоставлялись услуги Удостоверяющего центра. Форма заявления об отзыве доверенности приведена в Приложении №11 к настоящему Регламенту.

Заявление на аннулирование (отзыв) сертификата ключа проверки электронной подписи в электронной форме формируется и подается в Удостоверяющий Центр с использованием программного обеспечения пользователя УЦ и представляет собой электронный документ формата PKCS#7. В качестве подписываемых данных используется запрос на отзыв сертификата, а электронная подпись осуществляется на действующем ключе электронной подписи пользователя.

Прием заявления и его рассмотрение осуществляется только в течение рабочего дня Удостоверяющего центра.

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

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

Информация о размещении списка отозванных сертификатов заносится в изданные Удостоверяющим центром сертификаты ключей подписи в поле CRL Distribution Point.

5.4. Приостановление/возобновление действия сертификата ключа проверки электронной подписи

5.4.1. Приостановление действия сертификата ключа проверки электронной подписи

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

Бумажная форма заявления на приостановление сертификата ключа проверки электронной подписи приведена в Приложении № 8.1, 8.2 к настоящему Регламенту.

Заявление на приостановление действия сертификата ключа проверки электронной подписи в электронной форме формируется и подается в Удостоверяющий Центр с использованием программного обеспечения пользователя УЦ и представляет собой электронный документ формата PKCS#7. В качестве подписываемых данных используется запрос на приостановление действия сертификата, а электронная подпись осуществляется на действующем ключе электронной подписи пользователя.

Действие сертификата приостанавливается на исчисляемый в календарных днях срок. Минимальный срок приостановления действия сертификата составляет 10 дней.

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

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

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

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

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

5.4.2. Возобновление действия сертификата ключа проверки электронной подписи

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

Бумажная форма заявления на возобновление сертификата ключа проверки электронной подписи приведена в Приложении № 9.1, 9.2 к настоящему Регламенту.

Заявление на возобновление действия сертификата ключа проверки электронной подписи в электронной форме формируется и подается в Удостоверяющий Центр с использованием программного обеспечения пользователя УЦ и представляет собой электронный документ формата PKCS#7. В качестве подписываемых данных используется запрос на возобновление действия сертификата, а электронная подпись осуществляется на действующем ключе электронной подписи пользователя.

Системные требования

• Доступ в интернет
• Операционная система: Windows 8, 7, XP SP 3/2
• Процессор: 1.6 Ггц или выше
• Оперативная память: 512 Мб
• Наличие одного из поддерживаемых криптопровайдеров: КриптоПро CSP не ниже 3.6, ЛИССИ CSP, VIPNet CSP, Signal-COM CSP
• Разрешение экрана: не менее 800х600 px

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

Для работы программы Екей.Подпись наличие на рабочем месте средства криптографической защиты информации (СКЗИ), выполняющего шифрование документов согласно ГОСТ алгоритмам обязательно. В качестве СКЗИ могут использоваться системы КриптоПро CSP не ниже 3.6, ЛИССИ CSP, VIPNet CSP, Signal-COM CSP.

Средства криптографической защиты информации совместимы с Екей.Подпись, однако несовместимы друг с другом. На одном рабочем месте может быть установлено только одно СКЗИ.

Пользуйтесь антивирусом

Установите на вашем рабочем месте популярный антивирус и регулярно обновляйте его. Антивирус защищает от вирусов, программ-шпионов и самостоятельно устраняет большинство угроз безопасности.

Защищайте доступ к электронной подписи и рабочему месту паролем

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

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

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

Используйте только лицензионные и актуальные программы

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

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

Установка Екей.Подпись

1. Загрузите

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

Подготовка файлов для Росреестра

1. Выберите тип операции «Росреестр» в главном окне программы или в контекстном меню файла.

Подготовка контейнера для ФСФР России, Службы банка России, Центробанка

1. Выберите тип операции «ФСФР России».

2. Выберите личный сертификат.

3. Добавьте отчет с расширением xtdd или smcl с помощью кнопки «Прикрепить файл(ы)» или перетащите файл с помощью мыши.

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

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

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

ФГИС ТП Минрегион России

1. Выберите тип операции «ФГИС ТП».

2. Выберите личный сертификат.

3. Добавьте отчет с помощью кнопки «Прикрепить файл(ы)» или перетащите файл с помощью мыши.

4. Нажмите кнопку «Сформировать».

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

6. В появившемся меню сохранения выберите место сохранения результата операции.

Роскомнадзор реестр (zapret-info.gov.ru)

1. Выберите операцию Роскомнадзор реестр

2. Выберите личный сертификат

3. Чтобы узнать время последнего обновления реестра нажмите «Время последнего обновления выгрузки из реестра»

4. Чтобы отправить запрос нажмите «отправить запрос»

Заполните поля, для генерации запроса.

5. Чтобы получить результат обработки запроса нажмите «Запрос на получение результата»

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

ИСЭД

1. Выберите тип операции «ИСЭД».

2. Добавьте отчет с помощью кнопки «Прикрепить файл(ы)» или перетащите файл с помощью мыши.

3. Выберите сертификаты получателей

4. Нажмите кнопку «Сформировать».

5. В появившемся меню сохранения выберите место сохранения результата операции.

Подпись файлов

1. Выберите тип операции «Подписать вручную».

2. Выберите личный сертификат.

4. Выберите необходимые параметры подписи.

5. Нажмите кнопку «Подписать».

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

Пояснения:

Сохранить подпись в отдельном файле

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

Архивировать файлы

Нужно ли архивировать файлы после подписания

Расширение - Расширение файла подписи по умолчанию sig, также можно указать свое расширение

Кодировка - Выберите необходимую вам кодировку Der или Base-64

Отключить служебные заголовки - Если выбрана кодировка Base-64 (Заголовки используются для совместимости со сторонним программным обеспечением).

Шифрование файлов

1. Выберите тип операции «Зашифровать вручную».

2. Выберите личный сертификат.

3. Добавьте файл с помощью кнопки «Прикрепить файл(ы)» или перетащите файл с помощью мыши.

4. Выберите необходимые параметры шифрования.

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

6. Нажмите кнопку «Зашифровать».

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

8. В появившемся меню сохранения выберите место сохранения результата операции. Пояснения:

Кодировка

Выберите необходимую вам кодировку Der или Base-64

Расширение

Расширение, которое будет иметь конечный файл (по умолчанию enc), также можно указать свое расширение. Отключить служебные заголовки — Если выбрана кодировка Base-64 (необходимо для совместимости со сторонним программным обеспечением).

Архивировать файлы перед шифрованием

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

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

Расшифровка файлов

1. Выберите тип операции «Расшифровать».

2. Выберите личный сертификат.

3. Добавьте файл с помощью кнопки «Прикрепить файл(ы)» или перетащите файл с помощью мыши.

4. Нажмите кнопку «Расшифровать».

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

6. В появившемся меню сохранения выберите место сохранения результата операции.

Проверка подписи

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

• Через двойной клик на файле содержащем подпись.
• Выберите тип операции «Проверить подпись» в основном меню программы.
• Через контекстное меню файла который необходимо проверить.

2. Добавьте файл с помощью кнопки «Прикрепить файл(ы)» или перетащите файл с помощью мыши.

3. Нажмите кнопку « Проверить».

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

Также во время проверки можно просмотреть содержимое файлов, имеющих расширение: doc xls csv pdf html htm txt xml zip png jpeg jpg bmp gif.

Пояснения:

Снять подпись с файлов

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

Добавить подпись

1. Выберите тип операции «Добавить подпись».

2. Выберите личный сертификат.

4. Нажмите кнопку «Подписать».

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

6. В появившемся меню сохранения выберите место сохранения результата операции.

Заверить подпись

1. Выберите тип операции «Заверить подпись».

2. Выберите личный сертификат.

3. Добавьте файл подписи с помощью кнопки «Прикрепить файл(ы)» или перетащите файл с помощью мыши.

4. Нажмите кнопку «Заверить».

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

6. В появившемся меню выберите подпись, которую необходимо заверить

7. В появившемся меню сохранения выберите место сохранения результата операции.

Автоматическое обновление

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

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

Автоматическая установка корневых сертификатов

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

Удостоверяющий Центр CAFL63 создан на базе . Для хранения данных (запросы, сертификаты, настройки и т.п.) используется СУБД SQLite3. Удостоверяющий центр имеет графический интерфейс, разработанный на Tcl/Tk.

УЦ CAFL63 разрабатывался с учетом требований Федерального закона от 6 апреля 2011г. №63-ФЗ "Об электронной подписи", а также «Требований к форме квалифицированного сертификата ключа проверки электронной подписи», утвержденных приказом ФСБ России от 27.12.2011 № 795.

В его состав УЦ входит Центр Регистрации (ЦР), который ответственен за прием от граждан заявок на сертификаты. Сегодня сертификаты выпускаются для юридических лиц, физических лиц и индивидуальных предпринимателей. Заявки принимаются в электронном виде в формате PKCS#10, CSR (Certificate Signing Request) или SPKAC. Отметим, что формат CSR – это запрос PKCS#10 в PEM-кодировке с заголовком -----BEGIN REQUEST CERTIFICATE-----.

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

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

В том случае, если заявитель пришел без готового запроса, то он вместе с сотрудником ЦР идет на отдельное рабочее место, где готовится запрос на сертификат. Подготовленный запрос на электронном носителе, о чем уже говорилось, поступает в ЦР. Что здесь нужно помнить заявителю? Первое и главное: заявитель должен забрать носитель со сгенерированным закрытым ключом!

Утвержденный запрос на электронном носителе передается в ЦС, где на его основе выпускается сертификат.

Это принципиальная схема работы УЦ. Детали станут понятны ниже. Одно замечание, в целях удобства демонстрации утилита подготовки запроса, ЦР и ЦС объединены в один демонстрационный комплекс. Но никаких проблем с разнесением функционала нет. Самое простое решение - на каждом рабочем месте иметь по экземпляру CAFL63 и задействовать только требуемый функционал.

Когда реализация проекта шла полным ходом, на глаза попался проект SimpleCA . Изучение этого проекта очень помогло при окончательной реализации УЦ CAFL63.

Скачать дистрибутив CAFL63 для платформ Win32/Win64, Linux_x86/Linux_x86_64 .

Итак, запускаем утилиту CAFL63 - на экране появляется стартовая страница CAFL63:

Работу мы начинаем с нажатия кнопки «Создать БД». База данных УЦ создается средствами кроссплатформенной СУБД SQLite3 . БД УЦ содержит несколько таблиц. Главная таблица - mainDB - содержит всего одну запись, в которой хранится корневой сертификат, закрытый ключ, зашифрованный на пароле, и настройки УЦ. Есть две таблицы, связанные с запросами на сертификаты: текущие запросы reqDB и архив запросов reqDBArc. Для сертификатов создаются три таблицы: таблица новых сертификатов certDBNew, таблица архива сертификатов CertDB и таблица отозванных сертификатовCertDBRev. Все таблицы запросов и сертификатов в качестве ключа (primary key) используют значение хэш (sha1) от открытого ключа. Это оказалось очень удобным, например, при поиске сертификата по запросу или наоборот. В БД есть еще одна таблица crlDB, в которой хранятся списки отозванных сертификатов. И так, мы нажали кнопку «Создать БД»:

Создание УЦ начинается с выбора каталога, в котором будем хранить БД, и задания пароля для доступа к закрытому ключу УЦ. Нажав клавишу «След», мы переходим к странице выбора типа и параметров ключевой пары для УЦ:

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

Отметим, что утилита CAFL63 обладает определенным «интеллектом» и поэтому контролирует не только наличие данных в полях, но и правильность (красная подсветка - неправильно) заполнения таких полей как ИНН, ОГРН, СНИЛС, ОГРНИП, адрес электронной почты и др.

После заполнения полей информацией о владельце УЦ будет предложено определиться с системными настройками УЦ:

Если вы не собираетесь работать с российской криптографией, то можете использовать обычный OpenSSL. Для работы с российской криптографией, необходимо указать соответствующую версию, модификацию OpenSSL. Более подробно читайте README.txt в скаченном дистрибутиве. Также, в соответствии с ФЗ-63, предлагается задать информацию о сертификации самого УЦ и используемым им СКЗИ.

После правильного заполнения всех полей, еще раз будет предложено проверить их достоверность и нажать кнопку «Finish»:

После нажатия кнопки «Готово» будет создана БД УЦ, в которую будут сохранены: корневой сертификат УЦ, закрытый ключ, системные настройки. А на экране вновь появится стартовая страница утилиты CAFL63. Теперь, когда у нас создана база данных вновь создаваемого УЦ, мы нажимаем кнопку «Открыть БД», выбираем каталог с БД и попадаем в главное рабочее окно УЦ:

Нажав кнопку «Просмотр CA УЦ», мы убеждаемся в том, что именно это именно наш корневой сертификат.

Следующим шагом мы подготавливаем шаблоны/профили заявок для юридический лиц, физических лиц и индивидуальных предпринимателей (Средства->Настройки->Типы Сертификатов->Новый ):

После задания имени нового профиля будет предложено определить его состав:

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

Если заявитель пришел с готовой заявкой, то после проверки его документов, заявка импортируется в БД УЦ. Для этого необходимо на главном рабочем окне выбрать вкладку «Запросы на сертификаты», нажать кнопку «Импорт запроса/CSR» и выбрать файл с запросом. После этого появится окно с информацией о запросе:

Просмотрев запрос и убедившись в его правильном заполнении, можно нажимать кнопку «Import» для занесения его в базу данных. Сразу отметим, что при попытке повторного внесения запроса в БД УЦ будет выдано сообщение:

Запросы в БД УЦ помечаются (колонка «Type») либо как «Locale», созданные на УЦ, либо как «Import», созданные самим заявителем, а также фиксируется время поступления заявки в УЦ. Это может оказаться полезным при разборе конфликтных ситуаций.

Если заявитель пришел без заявки и просит ее создать, то прежде всего необходимо определиться (Настройки->Типы Сертификатов->Физ.лицо->Редактировать ) с типом ключевой пары (->Key Pair ), для каких целей ( ->Key Usage ) необходим сертификат:

Ключевая пара может создаваться как как средствами СКЗИ "ЛИРССЛ-CSP" (кнопка OpenSSL) и сохранятся в файле, так и на токене PKCS#11 (кнопка PKCS#11). В последнем случае необходимо также указать библиотеку для доступа к токену(например, rtpkcs11ecp для токена RuToken ECP или ls11cloud для ).

После того, как вы определились с профилем и нажали кнопку «След», дальнейшая процедура мало чем отличается от выпуска корневого сертификата. Одно важное замечание: запомните место хранение закрытого ключа и пароль для доступа к ключу. Если в качестве СКЗИ для генерации ключевой пары используется токен/смаркарта PKCS#11, то необходимо его доключить к компьютеру:

Созданная или импортированная заявка находится в БД УЦ и отображается в главном окне на вкладке «Запросы на сертификаты». Поступившие запросы находятся в стадии «рассмотрения» (колонка «Status» вкладки «Запросы на сертификат» и «Архив Запросов»). По каждому вновь поступившему запросу должно быть принято решение (контекстное меню при нажатии правой клавиши мышки на выбранном запросе):

Каждый запрос может быть отклонен или утвержден:

Если запрос отклоняется, то он перемещается из таблицы текущих запросов reqDB в таблицу архива запросов reqDBArc и, соответственно, исчезает на вкладке «Запросы на сертификаты» и появляется на вкладке «Архив Запросов».

Утвержденная заявка остается в таблице reqDB и на вкладке «Запросы на сертификаты» до выпуска сертификата, а потом тоже попадает в архив.

Процедура выпуска сертификата пункт меню «Выпустить сертификат») мало отличается от процедуры создания заявки:

Выпущенный сертификат сразу же появляется на вкладке «Сертификаты». При этом сам сертификат попадает в таблицу certDBNew БД УЦ и остается там до тех пор, пока он не будет опубликован. Сертификат считается опубликованным после его экспорта в SQL-дамп новых сертификатов, который передается на публичный сервис. Опубликование сертификата приводит к перемещению его из таблицы certDBNew в таблицу certDB.

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

Если запрос создавался на УЦ с генерацией ключа и его сохранением в файле, то нужно сформировать контейнер PKCS#12 и передать его заявителю:

Следует обратить внимание на «friendly name» - кавычки в нем должны экранироваться:

После создания защищенного контейнера PKCS#12 файл с закрытым ключом заявителя уничтожается.

Итак, УЦ начал свою жизнь, выпустил первый сертификат. Одна из задач УЦ – это организация свободного доступа к выпускаемым сертификатам. Публикация сертификатов, как правило, идет через веб-сервисы. Есть такой сервис и у CAFL63:

Для публикации сертификатов и списков отозванных сертификатов на публичном сервисе УЦ либо предварительно выгружает сертификаты в файлы (Сертификаты->Экспорт сертификатов), либо делает SQL–дамп всей таблицы сертификатов, из которой можно создать БД сертификатов и загрузить в нее список сертификатов, а в последующем делать SQL-дамп новых сертификатов, из которого они будут добавляться в БД публичного сервиса:

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

Для отзыва сертификата достаточно выбрать его на вкладке «Сертификаты», нажать правую кнопку мыши и выбрать пункт меню «Отзыв сертификата»:

Процедура отзыва не отличается от процедуры создания запроса или выпуска сертификата. Отозванный сертификат попадает в таблицу cerDBRev базы данных УЦ и появляется во вкладке «Отозванные сертификаты».

Осталось рассмотреть последнюю функцию УЦ – выпуск CRL - списка отозванных сертификатов. Список CRL формируется на вкладке «Отозванные сертификаты» при нажатии кнопки «Создать СОС/CRL». Все что потребуется здесь от администратора - это ввести пароль УЦ и подтвердить свое намерение выпустить CRL:

Выпущенный CRL попадает в таблицу crlDB базы данных и отображается на вкладке «CRL/СОС». Для просмотра CRL или его экспорта с целью публикации на публичном сервисе необходимо, как всегда, выбрать нужную строку, нажать правую кнопку мыши и выбрать пункт меню:

Скачать дистрибутив CAFL63 для платформ Win32/Win64, Linux_x86/Linux_x86_64 . Более того, это все успешно работает и на платформе Android.