Настройка браузера для эцп от нуц рк
Я расскажу о тонкостях внедрения электронной цифровой подписи (ЭЦП) в информационные системы (ИС) на базе веб технологий в контексте Национального Удостоверяющего Центра Республики Казахстан (НУЦ РК).
В центре внимания будет формирование ЭЦП под электронными документами и, соответственно, NCALayer — предоставляемое НУЦ РК криптографическое программное обеспечение. В частности уделю внимание вопросам связанным с UX и объемом поддерживаемого функционала NCALayer.
Процесс разделю на следующие этапы:
- формирование неизменного представления подписываемого документа (под подписываемым документом я буду подразумевать любые данные которые необходимо подписать, такие как: договор, бланк заказа, форма аутентификации и т.п.);
- подписание документа в веб интерфейсе с помощью NCALayer;
- проверка подписи на стороне сервера;
- (при необходимости) подготовка подписи к долгосрочному хранению.
Разработчикам важно понимать то, что любое изменение подписанного документа приведет к тому, что подпись под ним перестанет проходить проверку. При этом изменения могут быть вызваны не только редактированием самих данных документа, но и обновлением структуры документа или механизма его сериализации.
Рассмотрим простой пример — документы хранятся в виде записей в базе данных. Для подписания документа необходимо сформировать его представление в виде единого блока данных (конечно можно подписывать каждое поле записи поотдельности, но обычно так не делают), сделать это можно, к примеру, следующими способами:
- извлечь все поля записи, привести их к строкам и соединить в одну строку;
- сформировать XML или JSON представление;
- сформировать PDF документ на базе шаблона с каким-то оформлением содержащий данные из записи;
- и т.п.
Далее возможны два сценария каждый из которых имеет свои подводные камни:
- ИС не хранит сформированного представления и каждый раз для проверки подписи под документом (в частности проверки неизменности данных) формирует его;
- ИС хранит сформированное представление и использует его для проверки подписи.
В том случае, если ИС не хранит сформированного представления, разработчикам необходимо гарантировать что в будущем формируемые представления будут бинарно идентичны тем, которые были сформированы в первый раз не смотря на:
- изменения схемы базы данных;
- обновления механизма формирования представления (которое может так же зависеть от внешних библиотек которые, скорее всего, не стремятся к обеспечению бинарной идентичности).
В том случае, если на каком-то этапе бинарная идентичность перестанет соблюдаться, то проверки цифровых подписей перестанут выполняться и юридическая значимость документов в ИС будет утеряна.
Подход с хранением сформированного представления в базе данных ИС надежнее с точки зрения обеспечения сохранности юридической значимости, но и тут есть нюанс — необходимо гарантировать эквивалентность данных в подписанном документе данным в записи в базе данных иначе может возникнуть такая ситуация когда ИС принимает решение (выполняет расчет) на основании информации не соответствующей тому, что было подписано. То есть нужно либо так же, как и в предыдущем случае, обеспечивать бинарную идентичность формируемого представления, тогда при проверках в первую очередь следует формировать представление из текущего содержимого записи в базе данных и бинарно сравнивать новое представление с сохраненным. Либо необходим механизм позволяющий разобрать сохраненное сформированное представление и сравнить данные из него с текущим содержимым записи в базе данных. Этот механизм так же придется дорабатывать постоянно параллельно с доработками основного функционала ИС.
Для формирования цифровых подписей на стороне клиента НУЦ РК предоставляет единственный инструмент — сертифицированное программное обеспечение NCALayer которое представляет из себя WebSocket сервер, запускаемый на 127.0.0.1 , которому можно отправлять запросы на выполнение криптографических (а так же некоторых смежных) операций. При выполнении некоторых операций NCALayer отображает диалоговые окна — то есть берет часть работы по получению пользовательского ввода на себя.
Описание API NCALayer доступно в составе комплекта разработчика. Для того, чтобы поэкспериментировать со взаимодействием с NCALayer по WebSocket можно воспользоваться страницей интерактивной документации KAZTOKEN mobile (KAZTOKEN mobile повторяет API NCALayer).
- файловые, поддерживается единственный тип заданный константой 'PKCS12' ,
- аппаратные (токены и смарт-карты), для перечисления тех типов, экземпляры которых в данный момент подключены в ПК пользователя, следует использовать запрос getActiveTokens .
Таким образом для того, чтобы предоставить пользователю возможность работать с любым поддерживаемым NCALayer хранилищем, можно воспользоваться одним из следующих подходов:
Для подписания данных рекомендую использовать следующие запросы (опять же чтобы снизить вероятность выстрела в ногу):
- createCAdESFromBase64 — вычислить подпись под данными и сформировать CMS (CAdES);
- createCMSSignatureFromBase64 — вычислить подпись под данными, получить на подпись метку времени (TSP) и сформировать CMS (CAdES) с внедренной меткой времени;
- signXml — вычислить подпись под XML документом, сформированную подпись добавить в результирующий документ (XMLDSIG);
- signXmls — аналогично signXml , но позволяет за один раз подписать несколько XML документов.
В качестве параметров каждому из них нужно будет передать тип хранилища, тип сертификата, подписываемые данные и дополнительные модификаторы.
- 'AUTHENTICATION' — сертификаты для выполнения аутентификации;
- 'SIGNATURE' — сертификаты для подписания данных.
NCLayer предоставит пользователю выбирать только из тех сертификатов, которые соответствуют указанному типу.
Упрощенный пример подписания произвольного блока данных с использованием ncalayer-js-client:
Тема проверки цифровых подписей обширна и я не планировал раскрывать ее в этот раз, но упомянуть о необходимости выполнения проверок как с технической, так и юридической точки зрения счел необходимым.
С технической точки зрения проверка цифровой подписи на стороне сервера в первую очередь гарантирует целостность полученного документа, во вторую — авторство, а так же неотказуемость. То есть даже в том случае, если ИС получает подписанный документ не напрямую от пользователя, а через какие-то дополнительные слои программного обеспечения, уверенность в том, что было получено именно то, что отправлял пользователь сохраняется. Поэтому в ситуации когда подписание на стороне клиента реализовано, а возможность проверки подписи на стороне сервера отсутствует, внедрение цифровой подписи теряет смысл.
С юридической точки зрения ориентироваться следует на Приказ Министра по инвестициям и развитию Республики Казахстан “Об утверждении Правил проверки подлинности электронной цифровой подписи”. В Приказе перечислены необходимые проверки которые должны выполнять информационные системы для обеспечения юридической значимости подписанных электронной цифровой подписью документов. Анализу этого документа, а так же некоторым техническим вопросам посвящена заметка Проверка цифровой подписи.
Выполнять проверки необходимо с применением сертифицированных средств, к примеру с помощью библиотек входящих в состав комплекта разработчика НУЦ РК, либо можно воспользоваться готовым решением SIGEX.
Проверка подписи под электронным документом включает в себя проверку срока действия сертификата и проверку статуса отозванности сертификата. В том случае, когда необходимо обеспечить юридическую значимость подписанного документа по истечению срока действия сертификата или в том случае, когда сертификат был отозван через некоторое время после подписания, следует собирать дополнительный набор доказательств фиксирующий момент подписания и подтверждающий то, что на момент подписания сертификат не истек и не был отозван.
Для фиксации момента подписания принято использовать метки времени TSP. Метку времени на подпись можно получить либо на клиенте (запрос createCMSSignatureFromBase64 интегрирует метку времени в CMS), либо на сервере. Метка времени позволит удостовериться в том, что момент подписания попадает в срок действия сертификата.
Для того, чтобы удостовериться в том, что сертификат не был отозван в момент подписания, следует использовать CRL или OCSP ответ. Этот нюанс и рекомендации по реализации описаны в разделе APPENDIX B — Placing a Signature At a Particular Point in Time документа RFC 3161.
Инструкция по перевыпуску ключей (сертификатов) электронно-цифровой подписи НУЦ РК.
Если Вы предпочитаете в качестве инструкции просмотр видео, то перейдите в конец страницы, чтобы его просмотреть.
ШАГ 1. Уведомление.
Если Вы получили уведомление о скором истечении сроке действия сертификата по почте или в другом сервисе электронного правительства, то Вам необходимо пройти в личный кабинет сайта pki.gov.kz и подать заявку на перевыпуск сертификата.
Внимание! Если срок действия сертификатов уже истек, то рекомендуем перейти на >>>эту статью<<< по выпуску НОВЫХ сертификатов ключей НУЦ
ШАГ 2. Подача заявки.
Проверяем запущена ли утилита NCA LAyer.
Проверьте, запущена ли у Вас утилита NCA Layer. Значок этой утилиты отображается в области уведомлений системы (возле значка переключения языков).
Значок выглядит так:
Если область уведомлений свернута то так:
Если значок отсутствует, запускаем утилиту NCA Layer с рабочего стола.
Перевыпуск ключей
ШАГ 3. Получение ключей ЭЦП.
Проходим по ссылке, указанной в данном письме.
Получение ключей ЭЦП
Загрузка сертификатов
Как настроить браузер для дальнейшей работы с ключами (если не настроен), Вы можете посмотреть в статье >>>Настройка ключей ЭЦП от НУЦ РК в браузере<<<
В статье освещены основные проблемы при работе с сертификатами (ключами) ЭЦП НУЦ РК:
-невозможно зайти в кабинет налогоплательщика, в egov.kz и др. сервисы еПравительства РК.
В основе правильной работы большинства сервисов электронного правительства РК лежит установка утилиты NCA Layer, которая также содержит корневые сертификаты удостоверяющего центра. Поэтому, даже если какой-либо портал (например ЭСФ или кабинет налогоплательщика) не использует в работе данную утилиту, мы все же рекомендуем установить (обновить) ее.
ШАГ 1. Проверьте утилиту NCA Layer.
Необходимо проверить обновление утилиты, а также запущена ли она.
Значок этой уттилиты отображается в области уведомлений системы (возле значка переключения языков).
Значок выглядит так:
Если область уведомлений свернута то так:
В ДОПОЛНЕНИЕ ВАЖНО!
Если Вы используете Кабинет Налогоплательщика, то также в NCA Layer необходимо установить Модуль knpplugin.
Если Вы используете сайт Электронные счет-фактуры, то Вам необходимо установить модуль ЭСФ в NCA Layer
ШАГ 2. Проверяем настройки сертификатов и браузера
Выберите вариант браузера, с которым Вы работаете.
Если Вы используете Google Chrome, то дополнительные настройки не требуются.
Откройте браузер Mozilla Firefox
Зайдите на официальный сайт >>> НУЦ РК <<<, чтобы установить корневые сертификаты.
Прокрутите вниз страницы и скачайте корневые сертификаты.
Закрываем браузер Firefox , открываем заново и пробуем воспользоваться сервисом электронного правительства.
Вы можете также посмотреть короткое видео, как быстро проверить все настройки ЭЦП в компьютере (данное видео устарело, но в целом верно отражает настройки).
Не удалось решить проблему? Обращайтесь к нам через форму обратной связи.
Программное обеспечение NCALayer предоставляет возможность использовать средства ЭЦП НУЦ РК в веб-приложениях. Функционал NCALayer может быть расширен установкой дополнительных модулей, предоставляемых сторонними разработчиками.
Понятия и сокращения
НУЦ РК | Национальный удостоверяющий центр Республики Казахстан, обслуживающий участников «электронного правительства», государственных и негосударственных информационных систем |
КУЦ РК | Корневой удостоверяющий центр Республики Казахстан, осуществляющий подтверждение принадлежности и действительности открытых ключей электронной цифровой подписи удостоверяющих центров |
ЭЦП | Электронная цифровая подпись ‑ набор электронных цифровых символов, созданный средствами электронной цифровой подписи и подтверждающий достоверность электронного документа, его принадлежность и неизменность содержания |
Регистрационное свидетельство (сертификат) | Документ на бумажном носителе или электронный документ, выдаваемый НУЦ РК для подтверждения соответствия электронной цифровой подписи требованиям, установленным нормативно-правовыми актами Республики Казахстан |
Защищенный носитель | Устройство безопасного хранения информации, шифрование данных для которого выполняется непосредственно при записи информации на накопитель с использованием специализированного контроллера. Для доступа к информации пользователь должен указать персональный пароль. |
ОС | Операционная система ‑ комплекс взаимосвязанных программ, предназначенных для управления ресурсами компьютера и организации взаимодействия с пользователем |
ПК | Персональный компьютер |
Веб-приложение | Клиент-серверное приложение, в котором клиент взаимодействует с сервером при помощи браузера, а за сервер отвечает — веб-сервер |
Cистемные требования
Системные требования исходят из среды выполнения для Java 8. Более подробные описания указаны по ссылкам:
Для ОС Windows, Linux и Mac OS X не требуется устанавливать Java, так как среда выполнения поставляется вместе с NCALayer.
Читайте также: