Подпись прикладного сервера казахстан что это
Интеграция ЭЦП НУЦ РК в информационные системы на базе веб технологий
Я расскажу о тонкостях внедрения электронной цифровой подписи (ЭЦП) в информационные системы (ИС) на базе веб технологий в контексте Национального Удостоверяющего Центра Республики Казахстан (НУЦ РК).
В центре внимания будет формирование ЭЦП под электронными документами и, соответственно, NCALayer — предоставляемое НУЦ РК криптографическое программное обеспечение. В частности уделю внимание вопросам связанным с UX и объемом поддерживаемого функционала NCALayer.
Процесс разделю на следующие этапы:
Формирование неизменного представления подписываемого документа
Разработчикам важно понимать то, что любое изменение подписанного документа приведет к тому, что подпись под ним перестанет проходить проверку. При этом изменения могут быть вызваны не только редактированием самих данных документа, но и обновлением структуры документа или механизма его сериализации.
Рассмотрим простой пример — документы хранятся в виде записей в базе данных. Для подписания документа необходимо сформировать его представление в виде единого блока данных (конечно можно подписывать каждое поле записи поотдельности, но обычно так не делают), сделать это можно, к примеру, следующими способами:
Далее возможны два сценария каждый из которых имеет свои подводные камни:
В том случае, если ИС не хранит сформированного представления, разработчикам необходимо гарантировать что в будущем формируемые представления будут бинарно идентичны тем, которые были сформированы в первый раз не смотря на:
В том случае, если на каком-то этапе бинарная идентичность перестанет соблюдаться, то проверки цифровых подписей перестанут выполняться и юридическая значимость документов в ИС будет утеряна.
Подход с хранением сформированного представления в базе данных ИС надежнее с точки зрения обеспечения сохранности юридической значимости, но и тут есть нюанс — необходимо гарантировать эквивалентность данных в подписанном документе данным в записи в базе данных иначе может возникнуть такая ситуация когда ИС принимает решение (выполняет расчет) на основании информации не соответствующей тому, что было подписано. То есть нужно либо так же, как и в предыдущем случае, обеспечивать бинарную идентичность формируемого представления, тогда при проверках в первую очередь следует формировать представление из текущего содержимого записи в базе данных и бинарно сравнивать новое представление с сохраненным. Либо необходим механизм позволяющий разобрать сохраненное сформированное представление и сравнить данные из него с текущим содержимым записи в базе данных. Этот механизм так же придется дорабатывать постоянно параллельно с доработками основного функционала ИС.
Подписание документа в веб интерфейсе с помощью NCALayer
Описание API NCALayer доступно в составе комплекта разработчика. Для того, чтобы поэкспериментировать со взаимодействием с NCALayer по WebSocket можно воспользоваться страницей интерактивной документации KAZTOKEN mobile (KAZTOKEN mobile повторяет API NCALayer).
Взаимодействовать с NCALayer из браузера можно напрямую с помощью класса WebSocket, либо можно воспользоваться библиотекой ncalayer-js-client которая оборачивает отправку команд и получение ответов в современные async вызовы.
Модуль kz.gov.pki.knca.commonUtils берет на себя взаимодействие с пользователем связанное с выбором конкретного хранилища, которое нужно использовать для выполнения операции (так же он берет на себя выбор конкретного сертификата и соответствующего ключа, а так же ввод пароля или ПИН кода), но ему необходимо указать какой тип хранилищ нужно использовать. Типы хранилищ стоит разделить на два класса:
Таким образом для того, чтобы предоставить пользователю возможность работать с любым поддерживаемым NCALayer хранилищем, можно воспользоваться одним из следующих подходов:
Для подписания данных рекомендую использовать следующие запросы (опять же чтобы снизить вероятность выстрела в ногу):
В качестве параметров каждому из них нужно будет передать тип хранилища, тип сертификата, подписываемые данные и дополнительные модификаторы.
Модуль kz.gov.pki.knca.commonUtils поддерживает следующие типы сертификатов:
NCLayer предоставит пользователю выбирать только из тех сертификатов, которые соответствуют указанному типу.
Упрощенный пример подписания произвольного блока данных с использованием ncalayer-js-client:
Проверка подписи на стороне сервера
Тема проверки цифровых подписей обширна и я не планировал раскрывать ее в этот раз, но упомянуть о необходимости выполнения проверок как с технической, так и юридической точки зрения счел необходимым.
С технической точки зрения проверка цифровой подписи на стороне сервера в первую очередь гарантирует целостность полученного документа, во вторую — авторство, а так же неотказуемость. То есть даже в том случае, если ИС получает подписанный документ не напрямую от пользователя, а через какие-то дополнительные слои программного обеспечения, уверенность в том, что было получено именно то, что отправлял пользователь сохраняется. Поэтому в ситуации когда подписание на стороне клиента реализовано, а возможность проверки подписи на стороне сервера отсутствует, внедрение цифровой подписи теряет смысл.
С юридической точки зрения ориентироваться следует на Приказ Министра по инвестициям и развитию Республики Казахстан “Об утверждении Правил проверки подлинности электронной цифровой подписи”. В Приказе перечислены необходимые проверки которые должны выполнять информационные системы для обеспечения юридической значимости подписанных электронной цифровой подписью документов. Анализу этого документа, а так же некоторым техническим вопросам посвящена заметка Проверка цифровой подписи.
Выполнять проверки необходимо с применением сертифицированных средств, к примеру с помощью библиотек входящих в состав комплекта разработчика НУЦ РК, либо можно воспользоваться готовым решением SIGEX.
Подготовка подписи к долгосрочному хранению
Проверка подписи под электронным документом включает в себя проверку срока действия сертификата и проверку статуса отозванности сертификата. В том случае, когда необходимо обеспечить юридическую значимость подписанного документа по истечению срока действия сертификата или в том случае, когда сертификат был отозван через некоторое время после подписания, следует собирать дополнительный набор доказательств фиксирующий момент подписания и подтверждающий то, что на момент подписания сертификат не истек и не был отозван.
Для фиксации момента подписания принято использовать метки времени TSP. Метку времени на подпись можно получить либо на клиенте (запрос createCMSSignatureFromBase64 интегрирует метку времени в CMS), либо на сервере. Метка времени позволит удостовериться в том, что момент подписания попадает в срок действия сертификата.
Для того, чтобы удостовериться в том, что сертификат не был отозван в момент подписания, следует использовать CRL или OCSP ответ. Этот нюанс и рекомендации по реализации описаны в разделе APPENDIX B — Placing a Signature At a Particular Point in Time документа RFC 3161.
Приказ Министра финансов Республики Казахстан от 04.05.2021 № 425 «Об утверждении Правил подтверждения органами государственных доходов факта уплаты налога на добавленную стоимость по импортированным товарам и акциза по импортированным подакцизным товарам с территории государств-членов Евразийского экономического союза в заявлении о ввозе товаров и уплате косвенных налогов путем проставления соответствующей отметки либо мотивированного отказа в подтверждении, а также случаи подтверждения органами государственных доходов факта уплаты налога на добавленную стоимость по импортированным товарам либо мотивированного отказа в подтверждении»
В соответствии с пунктом 7 статьи 456 и пунктом 5 статьи 475 Кодекса Республики Казахстан «О налогах и других обязательных платежах в бюджет» (Налоговый кодекс) ПРИКАЗЫВАЮ:
1) Правила подтверждения органами государственных доходов факта уплаты налога на добавленную стоимость по импортированным товарам и акциза по импортированным подакцизным товарам с территории государств-членов Евразийского экономического союза в заявлении о ввозе товаров и уплате косвенных налогов путем проставления соответствующей отметки либо мотивированного отказа в подтверждении согласно приложению 1 к настоящему приказу;
2) случаи подтверждения органами государственных доходов факта уплаты налога на добавленную стоимость по импортированным товарам либо мотивированного отказа в подтверждении согласно приложению 2 к настоящему приказу.
2. Признать утратившим силу приказ Министра финансов Республики Казахстан от 6 февраля 2018 года N 134 «Об утверждении Правил подтверждения органами государственных доходов факта уплаты налога на добавленную стоимость по импортированным товарам и акциза по импортированным подакцизным товарам с территории государств-членов Евразийского экономического союза» (зарегистрирован в Реестре государственной регистрации нормативных правовых актов под N 16428).
3. Комитету государственных доходов Министерства финансов Республики Казахстан в установленном законодательством Республики Казахстан порядке обеспечить:
1) государственную регистрацию настоящего приказа в Министерстве юстиции Республики Казахстан;
2) размещение настоящего приказа на интернет-ресурсе Министерства финансов Республики Казахстан;
3) в течение десяти рабочих дней после государственной регистрации настоящего приказа в Министерстве юстиции Республики Казахстан представление в Департамент юридической службы Министерства финансов Республики Казахстан сведений об исполнении мероприятий, предусмотренных подпунктами 1) и 2) настоящего пункта.
4. Настоящий приказ вводится в действие по истечении десяти календарных дней после дня его первого официального опубликования.
Министр финансов
Республики Казахстан
Е. Жамаубаев
Приложение 1
к приказу
Министра финансов
Республики Казахстан
от 4 мая 2021 года N 425
Правила подтверждения органами государственных
доходов факта уплаты налога на добавленную стоимость
по импортированным товарам и акциза по импортированным
подакцизным товарам с территории государств-членов
Евразийского экономического союза в заявлении о ввозе
товаров и уплате косвенных налогов путем проставления
соответствующей отметки либо мотивированного
отказа в подтверждении
Глава 1. Общие положения
1. Настоящие Правила подтверждения органами государственных доходов факта уплаты налога на добавленную стоимость по импортированным товарам и акциза по импортированным подакцизным товарам с территории государств-членов Евразийского экономического союза в заявлении о ввозе товаров и уплате косвенных налогов путем проставления соответствующей отметки либо мотивированного отказа в подтверждении (далее – Правила) разработаны в соответствии с пунктом 7 статьи 456 и пунктом 5 статьи 475 Кодекса Республики Казахстан «О налогах и других обязательных платежах в бюджет» (Налоговый кодекс) (далее – Налоговый кодекс) и определяют порядок подтверждения органами государственных доходов факта уплаты налога на добавленную стоимость и акциза по импортированным с территории государств-членов Евразийского экономического союза товарам, путем проставления соответствующей отметки либо мотивированного отказа в подтверждении (далее – косвенные налоги) в заявлении о ввозе товаров и уплате косвенных налогов (далее – Заявление).
2. Представление Заявления производится на бумажном носителе (в четырех экземплярах) и в электронной форме в соответствии с пунктом 3 статьи 456 Налогового кодекса, либо только в электронной форме согласно пункту 4 статьи 456 Налогового кодекса.
3. Подтверждение органами государственных доходов факта уплаты косвенных налогов в Заявлении, представленного на бумажном носителе (в четырех экземплярах) и в электронной форме, заверенное электронной цифровой подписью, производится в течение 10 (десяти) рабочих дней со дня поступления Заявления на бумажном носителе и в электронной форме и документов, предусмотренных пунктом 2 статьи 456 Налогового кодекса, путем проставления соответствующей отметки на четырех экземплярах Заявления.
4. Отметка о подтверждении факта уплаты косвенных налогов проставляется во втором разделе Заявления и заверяется:
подписью должностного лица, проставившего отметку, с указанием его фамилии, имени и отчества (при его наличии), даты проставления отметки;
подписью руководителя (заместителя руководителя) органа государственных доходов, с указанием его фамилии, имени и отчества (при его наличии), даты подписи;
печатью органа государственных доходов.
5. Один экземпляр Заявления остается в органе государственных доходов, три экземпляра с отметками возвращаются налогоплательщику (налоговому агенту) либо его законному или уполномоченному представителю (далее – представитель).
При этом налогоплательщик либо его представитель получают соответствующие три экземпляра Заявления под роспись в журнале регистрации заявлений о ввозе товаров и уплате косвенных налогов по форме согласно приложению 1 к настоящим Правилам.
6. Мотивированный отказ в подтверждении факта уплаты косвенных налогов производится органом государственных доходов в течение 10 (десяти) рабочих дней со дня поступления Заявления на бумажном носителе и в электронной форме путем направления налогоплательщику (налоговому агенту) мотивированного отказа в подтверждении факта уплаты косвенных налогов на бумажном носителе по форме согласно приложению 2 к настоящим Правилам.
В мотивированном отказе в подтверждении указываются выявленные несоответствия (нарушения), а также обязанность представления налогоплательщиком Заявления с устранением нарушений в течение 15 (пятнадцати) календарных дней с даты получения мотивированного отказа в подтверждении.
Мотивированный отказ в подтверждении выдается в двух экземплярах, один экземпляр которого остается в органе государственных доходов, второй экземпляр мотивированного отказа в подтверждении с тремя экземплярами Заявления вручается налогоплательщику (налоговому агенту) либо его представителю.
7. Подтверждение органами государственных доходов факта уплаты косвенных налогов по Заявлениям, представленным только в электронной форме, заверенной электронной цифровой подписью, в соответствии с пунктом 4 статьи 456 Налогового кодекса, производится в течение 3 (трех) рабочих дней со дня его поступления путем направления налогоплательщику (налоговому агенту) уведомления о подтверждении факта уплаты косвенных налогов в электронной форме, заверенной электронной цифровой подписью должностного лица, по форме согласно приложению 3 к настоящим Правилам.
8. Мотивированный отказ в подтверждении факта уплаты косвенных налогов производится органом государственных доходов в течение 3 (трех) рабочих дней со дня поступления Заявления в электронной форме, заверенной электронной цифровой подписью, путем направления налогоплательщику (налоговому агенту) мотивированного отказа в подтверждении в электронной форме, заверенной электронной цифровой подписью должностного лица, по форме согласно приложению 2 к настоящим Правилам.
В мотивированном отказе в подтверждении указываются выявленные несоответствия (нарушения), а также обязанность представления налогоплательщиком (налоговым агентом) в органы государственных доходов Заявления с устранением нарушений в соответствии с пунктом 9 статьи 456 Налогового кодекса в течение 15 (пятнадцати) календарных дней с даты получения мотивированного отказа в подтверждении.
Приложение 1
к Правилам
подтверждения органами
государственных доходов факта
уплаты налога на добавленную
стоимость по импортированным
товарам и акциза по
импортированным подакцизным
товарам с территории
государств-членов Евразийского
экономического союза в
заявлении о ввозе товаров и
уплате косвенных налогов путем
проставления соответствующей
отметки либо мотивированного
отказа в подтверждении
Тема: Подтверждение уплаты ндс покупателем из Казахстана
Опции темы
Поиск по теме
Подтверждение уплаты ндс покупателем из Казахстана
Добрый день. Отгрузили товар на Казахстан с 0 % ставкой ндс.
Покупатель прислал заявление о ввозе товаров, но без отметки налоговой и уведомление о подтверждении факта уплаты косвенных налогов, как я понимаю электронное, внизу стоит подпись прикладного сервера и какой то код.
Нам это уведомление подойдет для подтверждения экспорта? или ждать заявления?
Правильно я понимаю, что уведомление они с сайта налоговой распечатали, а заявление со штампом тоже будет, но позже.
Такие электронные уведомления могут все участники ТС предоставить?
А еще для понимания, можете разъяснить, члены ТС у себя ндс платят и потом берут его к вычету?
Да. Но в пакете документов предоставляете не его, а Перечень заявлений о ввозе товаров и уплате налогов, заполняемый на основании данного уведомления.
Да. Или не берут, если нет права/обязанности.
Спасибо за ответ. Не совсем понятно «Да. Но в пакете документов предоставляете не его, а Перечень заявлений о ввозе товаров и уплате налогов, заполняемый на основании данного уведомления.» Все таки нужно заявление о ввозе и уплате косвенных налогов с отметкой из их налоговой?
Не обязательно, для заполнения Перечня (откройте форму, посмотрите) достаточно данных из скана Уведомления. Перечень подается вместо заявлений.
Коллеги, извините что влезаю в тему со своим вопросом. Мне сейчас Казахстан прислали экспресс почтой уведомление и заявление о ввозе товаров и уплате косвенных налогов. Причем уплатили все 30.06.2016, те во 2 квартале. Я очень не хочу принимать к учету НДС по закупке экспортных товаров 2-м кварталом (когда товар был куплен и продан сразу в казахстан), НДС за квартал у меня уже сделан и не особо есть время сейчас заниматься этим, да и сумма эта не нужна к уменьшению. Могу ли я несмотря на то, что уплачен ндс казахами 2 кварталом и присланы все уведомления до сдачи отчетности за 2 квартал всю эту свистопляску с поездками в ифнс и принятием к учету перенести на 3 квартал?
Проверка цифровой подписи
Эта заметка посвящена деталям проверок цифровых подписей: причинам, нормативным документам и реализации в SIGEX.
Тем, кого интересуют юридические подробности подтверждения легитимности электронных документов, рекомендуем обратить внимание на статью “Как предоставлять документы, подписанные электронной цифровой подписью, в суд”.
# Зачем проверять электронные цифровые подписи
В первую очередь стоит разобраться с тем, что такое цифровая подпись. Закон “Об электронном документе и электронной цифровой подписи” вводит следующее определение:
16) электронная цифровая подпись – набор электронных цифровых символов, созданный средствами электронной цифровой подписи и подтверждающий достоверность электронного документа, его принадлежность и неизменность содержания;
На википедии в статье Электронная подпись приведено более развернутое определение:
ЭЦП — это реквизит электронного документа, полученный в результате криптографического преобразования информации с использованием закрытого ключа подписи и позволяющий проверить отсутствие искажения информации в электронном документе с момента формирования подписи (целостность), принадлежность подписи владельцу сертификата ключа подписи (авторство), а в случае успешной проверки подтвердить факт подписания электронного документа (неотказуемость).
Важно уточнить что фразу реквизит электронного документа не следует воспринимать в том смысле, что цифровая подпись становится частью электронного документа. В продолжении вышеупомянутой статьи описаны принципы формирования цифровых подписей из которых становится понятно что термин реквизит тут используется для того, чтобы явно ассоциировать цифровую подпись с документом, так как цифровую подпись вычисляют на основании содержимого документа.
Итак, электронная цифровая подпись может быть полезна для таких вещей, как подтверждение целостности электронного документа, подтверждение авторства и обеспечение неотказуемости.
До тех пор пока не будет выполнена проверка цифровой подписи нельзя быть уверенными ни в том, к какому электронному документу относится эта подпись, ни в том, кто подписывал документ. Таким образом можно заключить что в разрезе обеспечения значимости цифровой подписи ее проверка является не менее важной задачей, чем ее формирование.
# Кто и когда выполняет проверки цифровых подписей
Классический сценарий взаимодействия предполагает двух участников первый из которых готовит цифровой документ, подписывает его и передает его второму участнику. Второй участник хочет убедиться в том, что документ не был изменен в процессе передачи, а так же в том, что именно первый участник его составил и подписал. Для этого он выполняет проверку переданной вместе с электронным документом цифровой подписи. Так как проверка цифровой подписи, как было описано выше, не может быть выполнена человеком вручную, то обоим участникам необходимо иметь идентичное, либо совместимое программное обеспечение установленное на своих рабочих местах.
При этом нужно понимать что участники доверяют проверку цифровой подписи программному обеспечению, в значительной степени на него полагаются. В том случае, если программное обеспечение разработано не добросовестно, либо работает некорректно, либо было модифицировано компьютерным вирусом или вредоносным программным обеспечением, то оно может выдавать положительный результат проверки даже тогда, когда он на самом деле отрицательный. Это, в купе с тем, что участники могут не быть квалифицированными специалистами в области информационных технологий и с тем, что обслуживанием их рабочих мест может вообще никто не заниматься, то есть на них может присутствовать сомнительное нелицензионное программное обеспечение, может внушать сомнения в возможности установления доверия между участниками взаимодействия.
Стоит уточнить что обмен цифровыми подписями в таком сценарии достаточно сложен: помимо того что каждый участник должен передать свою подпись всем остальным участникам, каждый участник должен убедиться в том, что он получил подписи всех остальных участников и проверил их. Если участников, к примеру, пятеро, то каждый из этих пяти участников должен проверить четыре подписи остальных участников.
Современные сценарии, зачастую, отличаются от классических тем, что они не одноранговые, а клиент-серверные. То есть вместо того, чтобы взаимодействовать напрямую друг с другом, участники взаимодействуют с выделенным сервером. Их можно разделить на два случая:
После того, как один из участников зарегистрировал цифровую подпись документа в SIGEX, остальным участникам уже не обязательно выполнять проверки самостоятельно, им достаточно убедиться в том что сервис принял эту подпись.
Участники взаимодействия в любом случае доверяют выполнение проверок цифровых подписей программному обеспечению. Разница заключается в том что либо это программное обеспечение размещено на локальных рабочих станциях, либо на централизованном сервере, обслуживанием которого занимаются квалифицированные специалисты.
# Какие бывают проверки цифровой подписи и чем они регламентированы
В Приказе Министра по инвестициям и развитию Республики Казахстан “Об утверждении Правил проверки подлинности электронной цифровой подписи” указаны следующие проверки, которые необходимо выполнить для того, чтобы электронный документ был признан равнозначным документу, подписанному собственноручной подписью:
Так же в Приказе упоминаются две дополнительные проверки необязательные для признания юридической значимости документа:
Далее мы разберем каждую из перечисленных проверок по отдельности.
## Проверка ЭЦП в электронном документе
Речь идет о криптографической проверке цифровой подписи, той, о которой мы упоминали в начале данной заметки.
Механизм выполнения этой проверки для разных криптографических алгоритмов может отличаться. Тот механизм, который описан в Приказе, подходит для RSA. Для ГОСТ 34.310 он немного отличается, общее представление можно получить из статьи про российский ГОСТ 34.10.
Отличие в обработке CMS подписей заключается в том, что в этом случае цифровая подпись вычисляется не от хеш-значения документа, а от хеш-значения специального блока данных CMS, которое, в свою очередь, включает в себя хеш-значение документа.
В случае не упакованной в CMS подписи вычисление подписи осуществляется следующим образом:
В случае упакованной в CMS подписи вычисление подписи осуществляется следующим образом:
Процедуры проверки подписи отличаются подобным образом, нужно просто заменить последний шаг с вычисления цифровой подписи из хеш-значения и закрытого ключа на проверку цифровой подписи на основании хеш-значения, открытого ключа и цифровой подписи.
Стоит упомянуть то, что в CMS подпись так же может быть упакован и сам электронный документ, но этот случай мы рассматривать не будем в связи с тем, что такие CMS подписи получаются достаточно большими и извлекать из них электронные документы проблематично так как для этого необходимо специализированное программное обеспечение.
## Проверка срока действия регистрационного свидетельства
Сертификат открытого ключа (регистрационное свидетельство), помимо данных о субъекте сертификата и открытого ключа, обычно включает в себя данные о сроке действия этого сертификата. Срок действия сертификата устанавливает удостоверяющий центр во время выпуска сертификата. Обычно началом срока действия сертификата является момент его выпуска, окончание устанавливается через регламентированный промежуток времени, к примеру, через год с момента выпуска.
В процессе проверки цифровой подписи информационная система должна убедиться в том, что срок действия сертификата еще не истек, а так же в том, что он уже наступил, так как такое тоже может случиться.
## Проверка регистрационного свидетельства на отозванность (аннулирование)
Для тех случаев, когда действие сертификата (регистрационного свидетельства) необходимо досрочно прекратить, в инфраструктуре открытых ключей предусмотрена возможность отзыва сертификатов по требованию субъекта сертификата (либо в другом порядке предусмотренном регламентом удостоверяющего центра). Для этого субъект (либо кто-то, кто имеет подобные полномочия) должен обратиться в удостоверяющий центр с просьбой отозвать сертификат.
В процессе проверки цифровой подписи информационная система должна убедиться в том, что сертификат отсутствует в списке отозванных сертификатов. На самом деле процедура несколько сложнее, за деталями можно обратиться к соответствующему разделу RFC 5280.
Существует два общепринятых способа проверки наличия сертификата в списке отозванных:
Как уже упоминалось выше, OCSP позволяет запросить у удостоверяющего центра информацию о текущем состоянии определенного сертификата. Очевидные преимущества:
В данном случае принято пропускать проверку отозванности сертификатов служб CRL и OCSP, так как ответы были бы подписаны теми же службами, что привело бы к зацикливанию.
До того как эти проверки будут выполнены, доверять информации в CRL и OCSP нельзя, так как их передают, зачастую, по незащищенным каналам связи и злоумышленники могут организовать атаку человек посередине.
## Проверка области использования ЭЦП регистрационного свидетельства
В Приказе приведено следующее пояснение к данной проверке:
Проверка заключается в проверке значения поля регистрационного свидетельства «использование ключа» (KeyUsage). Значения «Цифровая подпись» и «Неотрекаемость», содержащиеся в поле «использование ключа», означают что, это регистрационное свидетельство используется для ЭЦП. Значения «Цифровая подпись» и «Шифрование ключей», содержащиеся в поле «использование ключа», означают что, это регистрационное свидетельство используется для аутентификации;
Фактически информационная система должна удостовериться в том, что в расширении сертификата KeyUsage установлены флаги digitalSignature и nonRepudiation. В том случае, если один из этих флагов не установлен, то данный сертификат не предназначен для цифровой подписи и информационная система не должна принимать подписанные данные.
## Проверка номера политики регистрационного свидетельства и разрешенных способах его использования
Расширение сертификата Certificate Policies содержит информацию о том, на основании какой политики удостоверяющий центр выпустил данный сертификат. Перечень политик и правила выпуска сертификатов по каждой из них описаны в регламентирующих документах удостоверяющего центра. В случае Национального удостоверяющего центра эта информация доступна в документе Правила применения регистрационных свидетельств подписчиков Национального удостоверяющего центра Республики Казахстан который можно найти на портале НУЦ в разделе Документация. В частности в подразделе 7.1.СТРУКТУРА РЕГИСТРАЦИОННОГО СВИДЕТЕЛЬСТВА ПОДПИСЧИКА НУЦ РК приведены структуры всех выпускаемых сертификатов, информацию о политике можно найти в поле Ceritifcate Policy структуры каждого сертификата. Сама политика тут указана в виде OID (объектного идентификатора), за текстовым представлением можно обратиться в реест OID РК.
Политика выпуска сертификата позволяет информационной системе лучше разобраться с тем, подходит ли использованный сертификат для подписания данного документа. К примеру в том случае, если информационная система ожидает что документ должен быть подписан представителем юридического лица, то ей следует принимать только подписи, которые были сформированы с использованием сертификатов выпущенных по политике 1.2.398.3.3.2.1 Политика применения регистрационных свидетельств электронной цифровой подписи юридических лиц Республики Казахстан.
В Приказе отдельно упоминается о том, что сертификаты информационной системы “Казначейство-клиент” разрешено применять только в информационной системе “Казначейство-клиент”, в реестре OID РК эти политики выглядят следующим образом:
## Построение цепочки сертификатов
Обычно информационная система настроена на доверие ограниченному количеству удостоверяющих центров. Их называют доверенными корневыми удостоверяющими центрами. В Республике Казахстан существует Корневой удостоверяющий центр Республики Казахстан. Зачастую корневые удостоверяющие центры не выпускают сертификатов конечным пользователям, они выпускают сертификаты промежуточных удостоверяющих центров, примером такого удостоверяющего центра может служить Национальный удостоверяющий центр РК.
Таким образом для того, чтобы удостовериться в том, что сертификату конечного пользователя можно доверять, информационной системе необходимо построить цепочку доверия, к примеру:
Процедура построения цепочки сертификатов описана в соответствующем разделе RFC 5280. Процедура достаточно сложная, с многими нюансами, помимо других моментов она включается в себя:
## Проверка метки времени
Протокол TSP позволяет получить метку времени от доверенного источника подтверждающую существование определенного блока данных на текущий момент времени. Такая метка может использоваться в дальнейшем для доказательства того, что определенный документ уже был подписан в определенный момент времени. Проще говоря метка времени позволяет фиксировать момент подписания электронного документа.
## Проверка полномочий лица подписавшего документ
К примеру в подразделе 7.1.5.Структура регистрационного свидетельства пользователя (юридическое лицо) Национального удостоверяющего центра Республики Казахстан (для подписи) указаны следующие возможные полномочия:
OIDы полномочий присутствуют в реесте OID РК.
Информационная система может использовать перечисленные в сертификате полномочия для того, чтобы определить обладает ли субъект необходимыми полномочиями для подписания электронного документа.
# Какие проблемы могут возникать в случае не выполнения или некорректного выполнения проверок
Обсуждать последствия некорректной криптографической проверки подписи (проверки ЭЦП в электронном документе) особого смысла нет, очевидно что это приведет к полностью неработоспособной системе. Вероятно по этой причине в статье 10 3-ей главы Закона “Об электронном документе и электронной цифровой подписи” приведено требование к аккредитации удостоверяющих центров, в рамках которой требуется сертификация средств криптографической защиты информации к которым относятся криптографические библиотеки.
Отзыв сертификатов (регистрационных свидетельств) может быть связан как с административной необходимостью (к примеру сотрудник уволился из организации), так и с проблемами с безопасностью (к примеру утерей защищенного носителя ключевой информации с наклеенным на него ПИН кодом) и с другими неожиданными ситуациями. Чаще всего неспособность информационной системы вовремя среагировать на отзыв сертификата (проверка регистрационного свидетельства на отозванность (аннулирование)) повлечет за собой то, что информационная система воспримет подписанный электронный документ как легитимный юридически значимый, в то время как он мог быть подписан либо человеком уже не занимающим свою должность, либо злоумышленником получившим доступ к закрытому ключу жертвы. Последствия могут быть более чем печальными, так как этим документом может быть, к примеру, договор купли-продажи имущества, либо доверенность на управление юридическим лицом.
Неспособность удостовериться в том, что в сертификате установлены корректные флаги расширения использования ключа, то есть выполнить проверку области использования ЭЦП регистрационного свидетельства, опять же приведет к тому, что фактически не легитимный документ будет воспринят системой как легитимный. Вероятность злого умысла в данном случае не очень высока, скорее всего произошла ошибка, но в том случае, если документ необходимо будет предоставить для разбирательства, к примеру, в суд, то могут возникнуть вопросы о том по какой причине информационная система некорректно уведомила пользователей о значимости документа.
Подобное случится и в случае проблем с проверкой номера политики регистрационного свидетельства и разрешенных способах его использования.
Некорректное построение цепочки сертификатов может предоставить злоумышленникам широкий простор для деятельности, так как в этом случае злоумышленнику не нужно будет похищать закрытый ключ. Все, что ему нужно сделать, это выпустить поддельный сертификат пользователя самостоятельно так, чтобы информационная система восприняла его как выпущенный доверенным удостоверяющим центром. К примеру в том случае, если информационная система сверяет поля subject и issuer, но не проверяет подпись под проверяемым сертификатом, то злоумышленник может создать сертификат пользователя в котором в поле issue укажет содержимое поля subject доверенного удостоверяющего центра а подпись добавит произвольную. Такая информационная система воспримет подготовленный злоумышленником сертификат как легитимный сертификат выпущенный удостоверяющим центром и, соответственно, будет принимать подписанные злоумышленником электронные документы.
В разрезе проверки метки времени информационная система может допускать следующие ошибки:
Некорректное выполнение проверки полномочий лица подписавшего документ, хоть и не относится к проверкам, необходимым к признанию юридической значимости документа, все-таки может негативно сказаться на бизнес процессах, так как информационная система не сможет определить того, что вместо первого руководителя организации документ был подписан обычным сотрудником.
# Реализации проверок цифровой подписи в SIGEX
Для выполнения криптографической проверки подписи сервис SIGEX использует сертифицированные библиотеки из состава SDK Национального удостоверяющего центра Республики Казахстан. Благодаря этому мы можем быть уверенными в том что используем точно те же реализации криптографических алгоритмов, которые использует удостоверяющий центр.
В процессе регистрации новой цифровой подписи сервис выполняет следующие действия:
Последующие проверки цифровой подписи инициированные пользователями информационной системы включают в себя следующие действия:
Таким образом мы можем утверждать что сервис SIGEX выполняет все необходимые проверки для того, чтобы выполнялось следующее положение Приказа Министра по инвестициям и развитию Республики Казахстан “Об утверждении Правил проверки подлинности электронной цифровой подписи”:
8. При удостоверении (установлении) подлинности ЭЦП с использованием СКЗИ удостоверяющего центра после проведения процедуры проверки ЭЦП (определен положительный результат проверки ЭЦП и регистрационного свидетельства), а также при соответствии условиям согласно подпунктам 2), 3) и 4) пункта 1 статьи 10 Закона, электронный документ, полученный посредством информационной системы, признается равнозначным документу, подписанному собственноручной подписи с одинаковыми юридическими последствиями.
Благодарим вас за внимание!
Портал SIGEX использует файлы cookie и другие технологии хранения данных в браузере только для персонализации пользовательского опыта: отображения уведомлений, напоминаний и подсказок, а так же хранения некоторых настроек. Мы не используем этих технологий для слежения за своими пользователями, сбора о них информации или отображения рекламы и не предоставляем подобных возможностей третим сторонам. Детали изложены в Политике конфиденциальности.
Я разрешаю использовать файлы cookie и другие технологии хранения данных в браузере в соответствии с описанными выше условиями ×
Мы разыгрываем два устройства KAZTOKEN каждую неделю!