Абсолютно с Вами согласен, не смотря на то, что закону об ЭЦП уже 20 лет, очень мало кто понимает как это работает и в результате очень много путаницы. Меня удивляет что об этом важном аспекте жизни всех наших граждан не рассказывают ни в школах, ни в университетах (кроме узких специальностей).
Да, процедура подключения неоднозначная, но на странице сервиса есть административные и технические контакты.
Спасибо за то, что рассказали о не задокументированных возможностях!
По поводу багов в приложениях, такое бывает. Кстати в предпоследнем релизе eGov mobile для Android CMS подписи без вложенных данных формировались не на сами данные, а на их base64 представление. То есть не соответствовали подписываемым документам. Так что очень важно всегда выполнять проверки подписей! Мы сообщили о проблеме, в последнем релизе это починили.
В ЦОН Вы, скорее всего, на ПК общего пользования подаете заявку на выпуск сертификатов. Может быть Вам помогает консультант. То же самое Вы можете сделать дома - откройте https://pki.gov.kz/, выберите "Получение ключей ЭЦП", потом нужный тип сертификата и следуйте инструкциям. В результате у Вас на ПК будут сохранены два файла с ключами (один для аутентификации, другой для подписи), если Вы будете использовать защищенный носитель, то ключевые пары будут сформированы у него в защищенной памяти. Так же Вам предложат распечатать заявление на выпуск сертификатов, распечатать его, подписать и отнести в ЦОН.
После того, как Вы отнесете заявление в ЦОН, Вам на почту отправят ссылку на скачивание сертификатов. То есть из НУЦ Вам присылают только сертификат, в нем нет закрытого ключа. А закрытые ключи были в самом начале сформированы на Вашем ПК, соответствующие открытые ключи были отправлены в УЦ в рамках подачи заявки на выпуск сертификатов.
Пару лет назад появилась новая функция - пройти биометрическую идентификацию дома и вообще не ходить в ЦОН, чтобы этим воспользоваться пройдите по ссылке Получите ключи ЭЦП не выходя из дома ᶰᵉʷ там же.
О том, как процедура получения сертификатов (ключей ЭЦП) реализована в eGov mobile я не знаю, но в "классическом" варианте - с использованием NCALayer, ключевая пара (закрытый и открытый ключи) формируются на ПК пользователя (или защищенном носителе) и закрытый ключ не покидают его. Более того есть защищенные носители (токены и карты), они вообще не предоставляют возможности экспортировать закрытые ключи.
А в ЦОН Вы приносите заявление, на основании которого Вам выпускают сертификат. В сертификате закрытого ключа нет, только открытый, с его помощью ничего не подпишешь.
Во первых речь про Казахстан, тут нет КриптоПро, но реализации облачной подписи существуют. Во вторых ключевое отличие в том, что закрытый ключ не в облаке, он на персональном мобильном устройстве пользователя.
На мой взгляд главным плюсом является то, что пользователь имеет возможность перепроверить что именно он подписывает в самом приложении eGov mobile. То есть даже если злоумышленник смог подменить данные в процессе их передачи, пользователь имеет возможность выявить это изучив что именно предлагает подписать приложение.
В том то и дело что принципиальной разницы нет. QR используется только для того, чтобы передать на мобильное устройство ссылку по которой мобильное приложение сможет скачать данные которые нужно подписать.
По поводу удостоверений личности - на мой взгляд даже в таком формате, который Вы описываете, удостоверение личности лучше файловой системы, так как файл можно скопировать (то есть копия файла может быть у злоумышленника в то время, когда пользователь об этом ничего не подразумевает), а закрытый ключ из удостоверения личности не получится (по крайней мере нам так говорят).
По поводу того, что NCALayer воспринимает другие устройства как KAZTOKEN, к сожалению ничего пояснить не смогу, тут нужно смотреть код NCALayer. С практической точки зрения KAZTOKEN - это сертифицированные (по СТ РК 1073-2007) в РК устройства.
Очень сомнительная штука. Сервер подписей на сокетах
На сколько я понимаю, Вы про NCALayer. Прошу заметить, что это ПО — официальное средство формирования цифровых подписей, распространяемое Национальным Удостоверяющим Центром РК и именно его следует использовать всем тем, кто собирается интегрировать свои системы с этим УЦ. То есть то, что я использую именно это ПО, это не прихоть, это необходимость. Сам я к НУЦ прямого отношения не имею.
По поводу самого NCALayer, я с Вами согласен, что при таком подходе возможны нюансы.
Из хорошего могу рассказать то, что текущий рекомендуемый API NCALayer не позволяет автоматически подписывать что-либо, вместо этого на каждый запрос на подписание отображается GUI приложения с запросом выбора хранилища и ввода пароля. Предыдущий API позволял автоматически подписывать данные, обещают его в скором времени отключить.
То, что подписываемые данные могут быть подменены, это смущает не только Вас. Хотя если посмотреть на текущую ситуацию под другим углом, то получается что пользователи, зачастую, вообще не знают что именно подписывают: веб страница формирует какое-то визуальное представление и какое-то подписываемое представление, на сколько они пересекаются — открытый вопрос. Как я уже писал в соседней ветке комментариев, было бы замечательно, если бы NCALayer позволял просматривать то, что было передано на подписание, это пытались обсуждать на форуме НУЦ: https://forum.pki.gov.kz/t/pochemu-v-ncalayer-netu-vizualizaczii-podpisyvaemyh-dannyh/590
Полностью солидарен, дополню статью рекомендацией не применять CDNы на боевых системах.
А данные, которые js ему передает (а он ведь передает)? Вы им доверяете?
Я понимаю к чему Вы клоните, но ведь мы продолжаем пользоваться множеством систем, которым не имеем никаких оснований доверять. Тут нужен баланс между практичностью и безопасностью.
Для подписания достаточно NCALayer, комплект разработчика НУЦ не обязателен. Как я писал в статье, подписать можно командой createCAdESFromBase64. Имейте в виду что после того, как NCALayer получит сообщение, он отобразит несколько окон для: выбора файлового хранилища (в том случае, если указан тип хранилища 'PKCS12'), ввода пароля/ПИН, выбора сертификата в хранилище.
Вы можете все это испробовать в живую на странице https://kaztoken.kz/mobile-docs/ — достаточно выбрать в меню слева createCAdESFromBase64 и нажать на кнопку отправки запроса внизу справа (NCALayer должен быть локально запущен).
Но важный момент заключается в том, что подписывать автоматически не правильно — это противоречит законодательству: Закрытые ключи электронной цифровой подписи не могут быть переданы другим лицам. (http://adilet.zan.kz/rus/docs/Z030000370_).
Автоматически подписывать документы сертификатами НУЦ не хорошо по следующим причинам:
речь идет о юридически значимой подписи, но подписывающий (сам человек) не имеет представления о том, что именно он подписывает — все равно что заставить человека не глядя подписывать документы, причем не просто не глядя, а принудительно запретить ему просматривать что именно он подписывает;
стандартные сертификаты юридических и физических лиц не ограничены в применении какими-то информационными системами, то есть если каким-то образом ваша система вместо документа для университета сформирует договор дарения квартиры (в ИТ всякое бывает), то он так же будет автоматически подписан и будет иметь юридическую значимость — квартира перейдет другому собственнику;
в том случае, если кто-то имеет доступ к серверу вашей системы, то он сможет получить доступ и к закрытому ключу — то есть как минимум сможет воспользоваться им (а то и скопировать себе в том случае, если ключ в файловом хранилище, а не на токене или карте).
Очень много рисков для того, кто передаст свой ключ ЭЦП для автоматизации подписания.
По хорошему Вам стоит поступить так:
реализовать интерфейс автоматизирующий формирование документов и отображение их пользователям;
в этом интерфейсе реализовать интеграцию с NCALayer — то есть дать пользователям возможность просматривать и подписывать сформированные документы;
сформированную подпись проверять на стороне вашего сервера (в соответствии с законодательством РК не проверенная подпись юридической значимости не имеет).
Вы можете взять все эти задачи на себя, либо ограничиться первой а для всего остального использовать готовое решение, к примеру https://sigex.kz (он бесплатный, не требует регистрации). В этом случае будет примерно следующая схема:
Ваша система формирует документ в каком-то формате (к примеру PDF или DOC или XLSX — как Вам удобнее);
пользователь получает этот документ (скачивает с вашего веб интерфейса, либо получает готовый по почте, либо получает сразу на файловой системе в том случае, если ваша система — это десктопное приложение);
в процессе подписания пользователь указывает электронный адрес университета для отправки уведомления (вероятно еще какой-то адрес для хранения отчетности на вашей стороне);
сервис проверяет подпись в соответствии с законодательством и отправляет уведомления о подписании в университет и остальным указанным получателям.
И вот еще вопрос, сможет ли обычный разработчик-любитель, работающий для себя и в своё удовольствие, получить комплект разработчика?
На это я Вам ответить не смогу — я не знаю какие у НИТ критерии. Попробуйте отправить им запрос (https://pki.gov.kz/developers/), думаю они Вас проконсультируют.
По поводу модуля для NCALayer — это интересная идея.
Для подписания файлов на данный момент существует SIGEX Desktop for Windows и ему для работы нужен NCALayer. Если же писать свой модуль, то можно будет расширить функционал — к примеру реализовать подписание нескольких файлов одним махом.
Понятно, согласен, через голый NCALayer подписывать массу документов пользователям не очень удобно — нужно при каждом подписании вводить пароль/ПИН и выбирать сертификат.
Хотя для XML существует kz.gov.pki.knca.commonUtils.signXmls — можно несколько XML документов за раз подписать.
Да, согласен, в SDK НУЦ присутствует несколько сертифицированных библиотек, можно пользоваться ими. Но статья сфокусирована на ИС на базе веб технологий, для этого сценария НУЦ предоставляет NCALayer.
Смею предположить что вы используете Java библиотеку — на сколько мне известно, поддержка токенов и карт реализована только в ней.
This format is used by many of the OpenSSL commands, and to initialize the libraries when used by any application.
В Ubuntu он расположен по пути /etc/ssl/openssl.cnf
Мы занимались разработкой движка (engine) для OpenSSL, я добавил его в конфигурационный для того, чтобы функционал был доступен из утилит командной строки. Естественно забыл об этом, удалил бинарную сборку и перезагрузил рабочую станцию. Точно в чем именно проявлялась проблема уже и не помню, но до графики ОС после этого не смогла загрузиться. На то, чтобы понять что проблема с конфигурацией OpenSSL, ушло некоторое время.
Так у вас в LXC контейнеры тоже изначально пусты и туда нужно софт доставлять. Или вы что то другое имели ввиду?
Контейнеры LXD включают в себя полноценную систему инициализации (systemd, init и т.д.) и рассчитаны на то, что в контейнере будет выполняться одновременно множество приложений. Благодаря этому можно запустить контейнер и достаточно быстро запустить в нем необходимое количество сервисов, входящих в состав дистрибутива. Так же можно запустить и необходимое количество собственных приложений или сервисов.
В случае с Docker потребовалось бы либо оборачивать все в контейнеры по отдельности (в том случае, если нет готовых образов), либо прибегать к костылям позволяющим запускать в контейнере Docker несколько приложений одновременно. Конечно же в том случае, если процессы разработки, внедрения и сопровождения уже интегрированы с Docker, то это не должно быть большой проблемой, но так оно не всегда.
Абсолютно с Вами согласен, не смотря на то, что закону об ЭЦП уже 20 лет, очень мало кто понимает как это работает и в результате очень много путаницы. Меня удивляет что об этом важном аспекте жизни всех наших граждан не рассказывают ни в школах, ни в университетах (кроме узких специальностей).
Да, процедура подключения неоднозначная, но на странице сервиса есть административные и технические контакты.
Спасибо за то, что рассказали о не задокументированных возможностях!
По поводу багов в приложениях, такое бывает. Кстати в предпоследнем релизе eGov mobile для Android CMS подписи без вложенных данных формировались не на сами данные, а на их base64 представление. То есть не соответствовали подписываемым документам. Так что очень важно всегда выполнять проверки подписей! Мы сообщили о проблеме, в последнем релизе это починили.
В ЦОН Вы, скорее всего, на ПК общего пользования подаете заявку на выпуск сертификатов. Может быть Вам помогает консультант. То же самое Вы можете сделать дома - откройте https://pki.gov.kz/, выберите "Получение ключей ЭЦП", потом нужный тип сертификата и следуйте инструкциям. В результате у Вас на ПК будут сохранены два файла с ключами (один для аутентификации, другой для подписи), если Вы будете использовать защищенный носитель, то ключевые пары будут сформированы у него в защищенной памяти. Так же Вам предложат распечатать заявление на выпуск сертификатов, распечатать его, подписать и отнести в ЦОН.
После того, как Вы отнесете заявление в ЦОН, Вам на почту отправят ссылку на скачивание сертификатов. То есть из НУЦ Вам присылают только сертификат, в нем нет закрытого ключа. А закрытые ключи были в самом начале сформированы на Вашем ПК, соответствующие открытые ключи были отправлены в УЦ в рамках подачи заявки на выпуск сертификатов.
Пару лет назад появилась новая функция - пройти биометрическую идентификацию дома и вообще не ходить в ЦОН, чтобы этим воспользоваться пройдите по ссылке Получите ключи ЭЦП не выходя из дома ᶰᵉʷ там же.
Если Вам интересны подробности работы с электронными документами и ЭЦП, то можете записаться на бесплатный вебинар: https://sigex.kz/blog/2022-04-04-free-digital-documents-webinars/
О том, как процедура получения сертификатов (ключей ЭЦП) реализована в eGov mobile я не знаю, но в "классическом" варианте - с использованием NCALayer, ключевая пара (закрытый и открытый ключи) формируются на ПК пользователя (или защищенном носителе) и закрытый ключ не покидают его. Более того есть защищенные носители (токены и карты), они вообще не предоставляют возможности экспортировать закрытые ключи.
А в ЦОН Вы приносите заявление, на основании которого Вам выпускают сертификат. В сертификате закрытого ключа нет, только открытый, с его помощью ничего не подпишешь.
Законодательство РК значительно отличается от законодательства РФ в этой области. У нас есть только один тип цифровой подписи - ЭЦП и она законодательно приравнена к подписи от руки на бумажном носителе: Закон Республики Казахстан Об электронном документе и электронной цифровой подписи
Во первых речь про Казахстан, тут нет КриптоПро, но реализации облачной подписи существуют.
Во вторых ключевое отличие в том, что закрытый ключ не в облаке, он на персональном мобильном устройстве пользователя.
На мой взгляд главным плюсом является то, что пользователь имеет возможность перепроверить что именно он подписывает в самом приложении eGov mobile. То есть даже если злоумышленник смог подменить данные в процессе их передачи, пользователь имеет возможность выявить это изучив что именно предлагает подписать приложение.
В том то и дело что принципиальной разницы нет. QR используется только для того, чтобы передать на мобильное устройство ссылку по которой мобильное приложение сможет скачать данные которые нужно подписать.
Сожалению что не понятно, если подскажете, постараюсь дополнить публикацию.
По поводу удостоверений личности - на мой взгляд даже в таком формате, который Вы описываете, удостоверение личности лучше файловой системы, так как файл можно скопировать (то есть копия файла может быть у злоумышленника в то время, когда пользователь об этом ничего не подразумевает), а закрытый ключ из удостоверения личности не получится (по крайней мере нам так говорят).
По поводу того, что NCALayer воспринимает другие устройства как KAZTOKEN, к сожалению ничего пояснить не смогу, тут нужно смотреть код NCALayer. С практической точки зрения KAZTOKEN - это сертифицированные (по СТ РК 1073-2007) в РК устройства.
На сколько я понимаю, Вы про NCALayer. Прошу заметить, что это ПО — официальное средство формирования цифровых подписей, распространяемое Национальным Удостоверяющим Центром РК и именно его следует использовать всем тем, кто собирается интегрировать свои системы с этим УЦ. То есть то, что я использую именно это ПО, это не прихоть, это необходимость. Сам я к НУЦ прямого отношения не имею.
По поводу самого NCALayer, я с Вами согласен, что при таком подходе возможны нюансы.
Из хорошего могу рассказать то, что текущий рекомендуемый API NCALayer не позволяет автоматически подписывать что-либо, вместо этого на каждый запрос на подписание отображается GUI приложения с запросом выбора хранилища и ввода пароля. Предыдущий API позволял автоматически подписывать данные, обещают его в скором времени отключить.
То, что подписываемые данные могут быть подменены, это смущает не только Вас. Хотя если посмотреть на текущую ситуацию под другим углом, то получается что пользователи, зачастую, вообще не знают что именно подписывают: веб страница формирует какое-то визуальное представление и какое-то подписываемое представление, на сколько они пересекаются — открытый вопрос. Как я уже писал в соседней ветке комментариев, было бы замечательно, если бы NCALayer позволял просматривать то, что было передано на подписание, это пытались обсуждать на форуме НУЦ: https://forum.pki.gov.kz/t/pochemu-v-ncalayer-netu-vizualizaczii-podpisyvaemyh-dannyh/590
Точно, в разных случаях разные средства.
Но, как минимум, хотя бы такие курьезы хотелось бы предотвратить: https://ct.kz/hall-of-fame-eds/elicensekz/
Полностью солидарен, дополню статью рекомендацией не применять CDNы на боевых системах.
Я понимаю к чему Вы клоните, но ведь мы продолжаем пользоваться множеством систем, которым не имеем никаких оснований доверять. Тут нужен баланс между практичностью и безопасностью.
На мой взгляд хорошим решением, в данном случае, было бы доработать NCALayer так, чтобы он позволял просматривать подписываемые данные перед подписанием, вопрос этот поднимали: https://forum.pki.gov.kz/t/pochemu-v-ncalayer-netu-vizualizaczii-podpisyvaemyh-dannyh/590
Но в данной статье нет ни слова о криптографии на базе JS. Криптографией занимается нативное приложение NCALayer.
Согласен, было бы надежнее не использовать CDNы, благо сделать это не сложно. В данном случае я использую CDNы для простоты, так как это пример.
Добрый день,
Для подписания достаточно NCALayer, комплект разработчика НУЦ не обязателен. Как я писал в статье, подписать можно командой
createCAdESFromBase64. Имейте в виду что после того, как NCALayer получит сообщение, он отобразит несколько окон для: выбора файлового хранилища (в том случае, если указан тип хранилища'PKCS12'), ввода пароля/ПИН, выбора сертификата в хранилище.Вы можете все это испробовать в живую на странице https://kaztoken.kz/mobile-docs/ — достаточно выбрать в меню слева
createCAdESFromBase64и нажать на кнопку отправки запроса внизу справа (NCALayer должен быть локально запущен).Но важный момент заключается в том, что подписывать автоматически не правильно — это противоречит законодательству:
Закрытые ключи электронной цифровой подписи не могут быть переданы другим лицам.(http://adilet.zan.kz/rus/docs/Z030000370_).Автоматически подписывать документы сертификатами НУЦ не хорошо по следующим причинам:
Очень много рисков для того, кто передаст свой ключ ЭЦП для автоматизации подписания.
По хорошему Вам стоит поступить так:
Вы можете взять все эти задачи на себя, либо ограничиться первой а для всего остального использовать готовое решение, к примеру https://sigex.kz (он бесплатный, не требует регистрации). В этом случае будет примерно следующая схема:
На это я Вам ответить не смогу — я не знаю какие у НИТ критерии. Попробуйте отправить им запрос (https://pki.gov.kz/developers/), думаю они Вас проконсультируют.
По поводу модуля для NCALayer — это интересная идея.
Для подписания файлов на данный момент существует SIGEX Desktop for Windows и ему для работы нужен NCALayer. Если же писать свой модуль, то можно будет расширить функционал — к примеру реализовать подписание нескольких файлов одним махом.
Понятно, согласен, через голый NCALayer подписывать массу документов пользователям не очень удобно — нужно при каждом подписании вводить пароль/ПИН и выбирать сертификат.
Хотя для XML существует kz.gov.pki.knca.commonUtils.signXmls — можно несколько XML документов за раз подписать.
Подскажите, пожалуйста, почему ключи должны храниться в открытом виде? В частности по какой причине не получается использовать токены или карты?
Добрый день,
Да, согласен, в SDK НУЦ присутствует несколько сертифицированных библиотек, можно пользоваться ими. Но статья сфокусирована на ИС на базе веб технологий, для этого сценария НУЦ предоставляет NCALayer.
Смею предположить что вы используете Java библиотеку — на сколько мне известно, поддержка токенов и карт реализована только в ней.
Но у нее есть глобальный конфигурационный файл https://www.openssl.org/docs/manmaster/man5/config.html, обратите внимание на следующее предложение:
В Ubuntu он расположен по пути /etc/ssl/openssl.cnf
Мы занимались разработкой движка (engine) для OpenSSL, я добавил его в конфигурационный для того, чтобы функционал был доступен из утилит командной строки. Естественно забыл об этом, удалил бинарную сборку и перезагрузил рабочую станцию. Точно в чем именно проявлялась проблема уже и не помню, но до графики ОС после этого не смогла загрузиться. На то, чтобы понять что проблема с конфигурацией OpenSSL, ушло некоторое время.
Контейнеры LXD включают в себя полноценную систему инициализации (systemd, init и т.д.) и рассчитаны на то, что в контейнере будет выполняться одновременно множество приложений. Благодаря этому можно запустить контейнер и достаточно быстро запустить в нем необходимое количество сервисов, входящих в состав дистрибутива. Так же можно запустить и необходимое количество собственных приложений или сервисов.
В случае с Docker потребовалось бы либо оборачивать все в контейнеры по отдельности (в том случае, если нет готовых образов), либо прибегать к костылям позволяющим запускать в контейнере Docker несколько приложений одновременно. Конечно же в том случае, если процессы разработки, внедрения и сопровождения уже интегрированы с Docker, то это не должно быть большой проблемой, но так оно не всегда.