В Казахстане опасно использовать ЭЦП

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


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


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


    Что такое NCALayer


    Так как основная реализация криптопровайдера на Java и в последних версиях браузеров нет возможности использовать апплеты, то НУЦ придумал оригинальное решение для использования ЭЦП в браузерах. Это решение называется — NCALayer. NCALayer — посредник между браузером, криптопровайдером и ключами ЭЦП.


    NCALayer устанавливается локально на компьютере пользователя. Работает NCALayer следующим образом — открывается вебсокет сервер на определенном порту, куда отправляется разного рода запросы.


    Опуская все детали подключения, рассмотрим пока два запроса, чтобы иметь общее представление как NCALayer работает:


    1. Выбрать ключ на файловой системе.

    {
      'method': "browseKeyStore",
      'args': ['PKCS12', 'P12', '/home/user']
    }

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


    Соответственно, после выбора ключа, через сокет получаем следующий ответ.


    {"result":"/home/user/AUTH_RSA.p12","errorCode":"NONE"}
    {"errorCode":"NONE"}

    Внимание: при использовании NCALayer, получаешь реальный путь к файлу на машине клиента.


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

    {
      "method": "signXml",
      "args": [
          'PKCS12',
          '/home/user/AUTH_RSA.p12',
          '1874abcef234',
          'ПАРОЛЬ!!!',
          '<login><timeTicket>1517997213006</timeTicket></login>'
      ]
    }

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


    Минусы реализации текущего варианта NCALayer


    1. Здесь один большой минус — путь к файлу и паролю доступен любому разработчику сайта, где используется ЭЦП. Даже пользуясь всякими токенами, при использовании NCALayer, пароль от устройства-токена также передаются на сайт. По крайней мере, текущая реализация позволяет это сделать.
    2. Хранение путей к ключам и пароль каждый сайт может хранить у себя в базе. Может и не хранить. Вообще, хранить или же не хранить пути и пароли — опять же, все это лежит на совести разработчиков сайтов.
    3. Любой сайт может за вас подписывать данные без вашего ведома в фоновом режиме, если он знает про путь где хранятся ключи и пароль. Опять таки, Если вы хоть раз использовали ЭЦП на сайте, то сайт уже знает путь к файлу и паролю. Если сайт-злоумышленник, то он гарантированно сохранит пароль где-то у себя.
    4. Хочу заметить, что прямой доступ к носителю с ключами не предоставляется. Доступ ограничен только функциями NCALayer.

    Реальный пример, как получить доступ к egov.kz, если ты не владеешь ЭЦП человека


    Не буду углубляться глубоко в технические детали и реализацию. Опишу как можно это сделать.
    Теперь, чтобы эту уязвимость эксплуатировать, нужно понимать как работаем механизм входа на egov.kz через ЭЦП. Для входа на egov.kz, xml от egov.kz подписывается пользователем и передается на сервер, где проверяется. Если подпись валидна, то осуществляется вход. Со стороны NCALayer, процесс входа состоит из следующих шагов:



    Портал запрашивает следующие данные из NCALayer — loadSlotList (здесь можно ответить ошибкой), getKeys, getSubjectDN, getNotBefore, getNotAfter и signXml. Если NCALayer правильно подставит эти данные от другого пользователя, то соответственно мы удачно войдем в систему. Здесь очень важно правильно получить от NCALayer только subjectDN и xml для подписи.
    Теперь как получить доступ к egov.kz от другого человека, механизм:


    1. У себя на компьютере, извлекаешь xml строку, которую нужно подписать чтобы войти на egov.kz. Это делается так, просто в консоли разработчика на idp.egov.kz, нужно запросить следующие данные — document.getElementById('xmlToSign').value.
    2. Отправляешь xml строку на подпись нужному человеку, который сидит на сайте-злоумышленнике. Он у себя на компьютере, в фоновом режиме подписывает нужную xml строку. Дополнительно получаешь subjectDN.
    3. Сейчас в наличии есть subjectDN и подписанный xml.
    4. Теперь самое интересное, у себя на компьютере эмулируешь работу NCALayer, который отдает необходимые данные.

    Некоторые утверждения


    1. Пост не рассчитан на широкую аудиторию, больше на технарей, которые понимают принципы веб-разработки.
    2. Уязвимы ВСЕ ресурсы, которые используют NCALayer.
    3. Познания в криптографии не нужны.
    4. Для эксплуатации этой уязвимости не нужно получать SDK от НУЦ. Соответственно, НУЦ не в состоянии выявить сайты-злоумышленники.
    5. Разработчики NCALayer не могут дать гарантии, что злоумышленники не смогут использовать такой механизм. Это будет глупо отвечать за всех. Технически возможность есть.
    6. Уязвимы ключи не только на файловой системе, но также на токенах.
    7. Вы гарантированно засветили пароль от носителя ключей ЭЦП, даже от токенов. Достаточно войти всего один раз на egov.kz. Как используется пароль на сайте, это на совести разработчиков.
    8. Насколько я слышал, уже есть системы, которые хранят путь к ключам ЭЦП и пароль в настройках.
    9. На сайтах нет уязвимостей, просто схема использования ЭЦП через NCALayer небезопасна.

    Update:


    Что можно сделать


    1. Будет неудобно — но при каждом использовании ключей, запрашивать хотя бы пароль.
    2. Продвигать web crypto api
    3. ...



    Эмулятор NCALayer
    Приложение, которое без ведома пользователя, в фоновом режиме подписывает данные

    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 138
    • +1

      Это не проблема egov.kz. Такой механизм реализовать сейчас считаю сомнительным, так как ЭЦП мало где внедрено и в основном госорганы. Если же начнут появлятся разные сайты с ЭЦП от компаний, тогда эта проблема становится актуальной.

      • +2
        В Казахстане до конца февраля 2018 владельцев электронных ресурсов обязали заключать с читателями письменные соглашения с использованием ЭЦП или sms-идентификации. Пруф.
        Через смс мало кто внедрять будет, так как каждое смс будет стоить 6 тенге (1 рубль), затраты должны взять на себя владельцы интернет ресурсов. Про стоимость пруф не искал, рассказал знакомый который работает админом на один из информационных порталов в казнете.
        • 0

          тогда такие варианты атак, вполне реальны.

      • +1
        Вы слали уведомления об этой проблеме на egov.kz или иным уполномоченным?
        Что-то ответили?
        • 0

          Это не проблема egov.kz. Такой механизм реализовать сейчас считаю сомнительным, так как ЭЦП мало где внедрено и в основном госорганы. Если же начнут появлятся разные сайты с ЭЦП от компаний, тогда эта проблема становится актуальной.

        • +4
          Не понимаю, зачем сделали передачу пароля на сайт?
          По идее, криптопровайдер локально на компе пользователя должен запросить пароль от закрытой части ключа ЭЦП при попытке что-то подписать со стороны сайта, а не передавать ему (сайту) пароль в открытом виде…
          • 0

            видать было удобней один раз запросить и позже все время подставлять программно.

            • +10
              Требования информационной безопасности и «удобней» — понятия в большинстве случаев несовместимые.
              • 0
                А никто не думал что разрабы просто взяли и реализовали это без согласований?
                • 0

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

                  • 0
                    Сомнительно. Приходилось писать код для гос. структур (правда не криптографию). Очень расплывчатые у них тех. задания, и очень много приходилось «доделывать от себя» (без согласований).
          • 0
            А проходило ли это «поделие» (NCALayer) сертификацию у регуляторов? Есть ли предписание на эксплуатацию в гос. органах?
            • +6

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

          • +1
            А зачем вообще эту бурду придумали, почему не ключи в браузере?
            • 0

              основное требование для работы с ЭЦП — использование своего, сертифицированного криптопровайдера. Криптопровайдеры, которые использует браузер — не сертифицированные.

              • +1
                Сертифицированы они, небось, во времена повсеместного rsa…
                Ясно-понятно.
                • 0

                  Нет, помимо RSA, также есть ГОСТ алгоритмы. Но только для юридических лиц. Для физлиц — RSA.

                  • 0
                    Ну я про физлиц и говорю.
                    То есть ЭЦП использовать небезопасно не только потому, что софт делает бредовые вещи, но и потому, что крипта в нём алгоритмически уязвима.
                    • +1
                      Хм, а когда RSA стал алгоритмически уязвим? (учитывая что размеры ключа нормальные)
                      • 0
                        Упс, да, с DSA перепутал. Что-то в голове 2 новости сложились в одну.

                        RSA только при ключе <=1024 уязвим.
              • 0
                У ключей в браузере, насколько я помню, нет никакого API для использования. Просто аутентифицируется HTTPS-сессия и всё. Вот придёт пользователь в суд и скажет, мол не подписывал я этот договор, предъявите мне доказательства того, что я подписывал. Сейчас ему предъявят XML-документ с его подписью, причём всё это согласно стандартам. А так — что ему предъявят? Записывать весь его шифрованный трафик? В общем ключи в браузере мягко говоря не очень удобны для данного применения. Был бы в браузерах нормальный API для этого дела, тогда хотя бы был бы шанс на такое (да и то учитывая то, что до сих пор используется нестандартные для запада криптоалгоритмы ГОСТ, реально шанса не было бы).

                Хотя в целом после того, как Java-плагин перестал работать, во многих странах появилась похожая проблема и есть шансы того, что API в браузерах всё же появится.
                • 0

                  Показывать логи запроса на "подпись" с данными его сертификатов. Практически по тем же стандартам. WebMoney применяет(ло?) такой способ лет 10 назад точно.

              • +1

                Браузерные криптопровайдеры же тоже передают эцп на сайт, в нашем случае тем более сверка с сервером НУЦ необходима
                Предлагайте варианты… смс авторизация опять не внушает оптимизма

                • +1

                  Казахстану инвестировать в развитие браузеров Chrome, Firefox, чтобы можно было нормальное ЭЦП внутри браузеров. Ну чтобы было правильно. Ну и еще криптопровайдер нормально прикрутить к браузерам.

                  • 0

                    Я конечно скажу бред с точки зрения государственных ИБ Казахстана… но почему нельзя использовать поделие КриптоПро? Да там тоже не всё радужно (при разработке — не единожды умоешься кровью), но откровенных косяков хотя бы нет…
                    И мстится мне, что ГОСТ-алгоритмы шифрования были придуманы до разделения СССР, и, соответственно, взаимозаменяемы между РФ и Казахстаном...

                    • 0
                      ГОСТ — он, как бы, не один. Бывает ГОСТ 28147-89/ГОСТ Р 34.11-94, а бывает ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012. И ещё промежуточные.

                      В виде RFC, почему-то, есть только ГОСТ Р 34.11-2012.

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

                      Но это в чистом виде потому, что кому-то нужна «шашечки», а не «ехать».
                • +1
                  Есть некоторые ресурсы котороые используют сертификаты для входа или подписи. Можно использовать сертификаты выданные НУЦ РК, причем NSALayer не используется. Как используются сертификаты на этих сайтах? Получается, что и сертификат и пароль отправляются на сервер? Т.е. они будут доступны админам сайта?
                  • 0
                    Сейчас проверил один сайт. Вся работа с ключами просиходит в браузере с помощью библиотеки «forge» (извлекается публичный ключ, срок действия сертификата и прочая информация). Но все равно, получается что все зависит от честности разработчика сайта.
                    • +1

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

                  • 0

                    Думаю проблему можно решить через oAuth. Сторонние сайты запрашиват инфо, временные ключи или одноразовые токены через сам eGov.kz. Сейчас когда ЭЦП пользуются только госорганы все более менее нормально, а когда подключатся частные компаний к сети, то возможность того что ЭЦП "своруют" увеличивается.

                    • 0

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

                      • 0
                        Подписывать токенами которые дает eGov (можно потом этот токен проявить как QR код). Потом egov где то себя сохранять этот токен и рядом записывает заметку, и через этот QR или токен в виде строки можно проверить подлинность запросив у egov. Возникает только одна проблема, со временем egov должен генерить очень оооочень длинные токены, либо задавать подписанным документам срок годности. Слышал что Казпочта хочет сделать электронную почту, письма которых может иметь законную силу, их тоже таким образом можно подписывать и задать какой то срок жизни достоверности.
                        • 0
                          Если не менять алгоритм работы с NCALayer, то oAuth  в данном случае можно использовать так:
                          — Используя oAuth можно авторизвать юзера и получить токен для работы с апи egov от его имени, при этом вход через текущий механизм произойдет только на стороне egov
                          — Используя полученный токен, дергаем апи egov'a, куда посылаем файл для подписи, в ответ получаем ссылку куда должен пойти юзер
                          — Редиректим юзера на эту ссылку (ссылка на домен егова ведет), он видит файл для подписи, использует эцп для подписи, после успеха/неаудачи возвращаем юзера на сайт
                          — Делаем опять апи вызов к егову, проверяем что файл подписан, забираем его себе

                          Из плюсов в этой схеме, все манипуляции с ЭЦП происходят на стороне egov, стороннему сайту нужно использовать только всем известный oAuth и реализовать три не сложных апи вызова к egov
                          Из минусов, проблема с NCALayer остается, но по крайней мере она будет существовать только в пределах самого egov, которому придется доверять
                      • +2
                        И есть еще одна проблема, у 80% с кем я сталкивался в ЦОНах ЭЦП имеет стандартный пароль 123456. И карту памяти на которым записан ихние ключи доверяют кому попало.
                        • 0
                          начиная с прошлого года, в новых ключах это нет так. При получении ключа задаётся свой пароль
                          • +2

                            Хз в этом году получал, пароль был тупо мой год Рождения

                            • 0
                              который будет 1q2w3e, а при продлении ключа станет 1q2w3e2019…
                          • +1
                            А web crypto api разве уже имеет поддержку в браузерах?
                          • +5
                            Мои пять копеек:
                            1. В 2008х годах когда дали указание срочно «популяризировать» девушки ходили с дисками на которых записаны ЭЦП, и массово раздавали по гос и около-гос конторам. У меня на столе оставили диск, просто потому что коллеги сказали TOLK сидит там, пришлось срочно отзывать ключ.
                            2. До прошлого года ставили всем пароль 123456, в исключительных случаях дату рождения.
                            3. Люди до сих пор не осознают, и как только не работает что-то с радостью передают ключи оператору ТП, у наших были до 150чужих ключей на оператора.
                            4. Самый из распространенных сайтов Госзакуп, где использовался ЭЦП, на заре становления, номинально принадлежит не госконторе. Минфин ни сном ни духом, о БД, о ПО.
                            5. Не понятно почему NCALAyer вдруг «виноват», хотя к нему немало других претензии, мы и раньше гипотетический могли с попощью апплета, вырвать и ключ и пароль.
                            6. Сейчас чтобы было удобно и честно, мы путь храним в кукисах пользюка, для быстрого выбора.
                            7. <зануда моде он :) > NCALayer не передает сайтам пароль, это сайт дергает API NCALayer и передает ему пароль введенный пользователем.
                            8. Есть немало проблем с НПА, например до сих пор нет, четкого ответа какое преобразование файла(например base64, файлов PDF) допустимо.
                            9. Из-за проблем со скоростью подписывался и до сих пор некоторые подписывают хеш большого файла а не сам файл.
                            10. Некоректные подписи есть даже на гос сайтах.
                            11. Если Вы не знаете не надо говорить о том что частные конторы не используют ЭЦП, у нас только есть десяток порталов(закуп, аукционы, е-документ, и пр), с сотней тысячи пользователей, не говоря уже о конкурентах.
                            12. Открыто заявлять о уязвимости никто не будет, рынок маленький, завтра кислород перекроют и все.
                            13. Вроде не было еще ни одного прецендента с разбором подписи. И главное здесь в суде не будут вызывать экспертов, будет прав тот кто прав. Менталитет у нашего народа такой, вся система достойна народа своего.

                            Не касающееся ЭЦП, СМС дейтвительно стоит около 6тенге, не считая «подписи»(типа просто INFO KAZ вместо имени вашей компании), но при больших оборотах снижается до 4тенге. Но даже 6тенге на одного пользователя это же копейки, 100тыщ пользователей 1800$.
                            • +1
                              По п.9: проще говоря, ЭП — это зашифрованный на ключе ЭП (в простонародии, секретный ключ) ХЭШ данных. Так что наличие у Вас п.9 меня смутило.
                              • +1
                                Я наверное не совсем ясно написал. Имелся в виду файл который находится на сервере. Не передается клиенту, немало, ребят передают на сторону клиента, хеш файла. И подписывают именно этот хеш, инода даже md5. В итоге подписывается «хеш-хеша» )
                                • +2
                                  Ну в этом проблем нет (если не md5, а нормальный хеш). Пользователь всегда может скачать файл (я надеюсь) и проверить подпись. Я бы сказал, что проблема в другом — обычно подписывается некий XML-документ. А вот что в этом XML-документе, пользователь не висит совсем. Т.е. это выглядит так, если проводить аналогию с реальным миром: вы пришли в банк, заполнили договор (на получение кредита, например), но подписываете вы не его. Вам дают бумажку с иероглифами и вы её подписываете. Оператор клятвенно уверяет, что эти иероглифы это и есть тот самый договор.

                                  Если вдруг эту дискуссию читает кто-нибудь из НУЦ и хотите сделать по-человечески, а не как сейчас, я бы дал такие советы:

                                  1. Концепция NCALayer как сервера с вебсокетом нормальная. Но рекомендую слушать на другом порту по HTTP и жаваскриптом сначала пытаться коннектиться туда. Коннект на 127.0.0.1 должен разрешаться с https-сайтов, если сейчас это в каких-то браузерах не так, то в будущем это будет исправлено и самой проблемы с 127.0.0.1 не будет в принципе.

                                  2. Жаваскрипт не должен задавать ни пароль, ни путь к файлу. У вас уже запущена GUI-программа. JavaScript должен посылать запрос на подпись, ваша программа должна получить соединение и сообщение с этим запросом, проверить, что сайт, с которого жаваскрипт пытается соединиться, находится в списке доверенных (заголовок Origin), вывести пользователю своё окно, в котором он уже выберет и ключ и всё остальное, помимо прочего вывести в этом окне сайт, который хочет подписать данные.

                                  3. Стандартизируйте XML-документы, которые подписываются пользователем. В целом концепция такая: пользователь должен видеть то, что он подписывает. В худшем случае хотя бы покажите ему этот самый XML-документ, как он есть. Хотя бы примерно можно будет понять, куда я ставлю свою подпись. А в нормальном случае подумайте о стандартизации этих документов, чтобы по документу можно было автоматически сгенерировать читабельное представление документа (но в любом случае оставьте возможность просмотра исходного XML, подписываем ведь его).

                                  4. Напишите свою программу на нормальном языке. Java для пользователя неудобна. Напишите общий код на C, напишите GUI на C#, Objective C, Gtk. Почему государственный софт обязательно должен быть таким уродливый?
                                  • +1
                                    1. В чём профит? Сейчас там хотя бы WSS, а не WS. А вы предлагаете по HTTP. Не совсем понятно что/зачем. 127.0.0.1 там и так.
                                    2. У них так исторически сложилось. ЕМНИП, ещё пока applet был на java работало всё также. Отдали всё на откуп программистам, сняв с себя ответственность. Удобно, чо :)
                                    3. Ну к чёрту. Серьёзно. Сейчас это хоть как-то работает, причём везде. А займутся C#, Objective C, GTK — мы получим зоопарк полурабочих решений. Если они даже tray-icon-у нормальную сделать за пару лет не осилили (в linux mint это какой-то аномальный прямоугольник с иконкой в углу, ещё и не с прозрачным фоном)… Боюсь что занявшись рюшечками linux вообще пропадёт из доступных решений.
                                    • +1
                                      1. Никакой безопасности https при соединении с локалхостом не даёт, думаю, это очевидно. Зачем- браузеру нужен валидный сертификат, чтобы wss работал. Сейчас у них в приложении поставляется ключ и подписанный НУЦем сертификат на 127.0.0.1. Я не могу сформулировать, чем это плохо, но тот факт, что публичные УЦ запрещают такое делать (и отзывали сертификаты тех, кто так делал, например HP) говорит о том, что так лучше не делать.

                                      2. Это работало неправильно и когда applet на Java был. Надо же делать правильно когда-нибудь.

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

                                      • 0
                                        Я не могу сформулировать, чем это плохо

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

                              • +2
                                9. Из-за проблем со скоростью подписывался и до сих пор некоторые подписывают хеш большого файла а не сам файл.
                                Не некоторые, а все. Потому что подписывать напрямую RSA файл в мегабайт — вам нужна будет не одна чашка кофе.

                                Если используется достаточно надёжных хеш (тот же SHA-3 сегодня), то это достаточно надёжно и быстро.
                                • +1
                                  Ответил выше, имелось в виду, подписание хеша(на усмотрение разработчика) подготовленного сторонним-несетифицированным ПО.
                              • –3
                                пожениться — пишется через мягкий знак
                                • +4
                                  Предложение начинается с заглавной и заканчивается точкой. А вообще в личку такое принято писать.
                                  • –2
                                    пока будут бездарно писать с ошибками, буду писать прямо в комментариях
                                    • 0
                                      Вас не смущает, что автор из Казахстана и русский для него не родной язык? Вы бы стали читать этот пост на казахском? Пусть уж с ошибками, но лучше так, чем никак.

                                      Пы.Сы. Тут, кстати, принято минусовать не понравившийся комментарий, а не сливать карму.
                                      • –4
                                        Дураки всегда минусуют правду
                                • +1
                                  1. И самое главное. Те, кто работал с генерацией эцп в РК давно об этом знали. Причина для работы по такому принципу не существенная, но была — чуваки реализовали так же, как было реализовано у них в апплете, когда НУЦ разосрался с гаммой.
                                  2.
                                  Уязвимы ВСЕ ресурсы, которые используют NCALayer.
                                  Опрометчивое заявление. Сейчас есть возможность в NCALayer добавить свой подключаемый модуль. Использовать короткоживущие токены. Ну и т.д. и т.п. Т.е. вероятность проведения успешной атаки будет в несколько процентов. Как инструмент для коммерческих махинаций не подойдёт.
                                  3.
                                  Насколько я слышал, уже есть системы, которые хранят путь к ключам ЭЦП и пароль в настройках.
                                  Хотелось бы узнать примеры…
                                  4.
                                  Продвигать web crypto api
                                  Эм, каким образом? Неужели вы думаете, что даже совместными усилиями в рамках Таможенного Союза участники смогут производителей браузеров добавить различные алгоритмы генерации, которые у них прописаны в законах.
                                  Я отлично понимаю, что у некоторых бомбит по этому поводу. Для параноиков, имеющих навыки программирования посоветую просто реализовать свою прилажуху, которая будет эмулировать NCALayer. Работы не так уж и много. Можно кучкануться и замутить открытый проект. Ну а в НУЦ, конечно, относятся к таким вещам весьма расслаблено. Знаю на собственном опыте.
                                  • +1
                                    Неужели вы думаете, что даже совместными усилиями в рамках Таможенного Союза участники смогут производителей браузеров добавить различные алгоритмы генерации, которые у них прописаны в законах.
                                    Разработчики браузеров что — ангелы, живущие на небе? Попробуйте предложить patch'и и посмотрите на реакцию. Если сошлётесь на требования закона — с вероятностью 90% будут вопросы только к технической реализации. Но вот тут — да, поблажек не будет. Дикие идеи типа «удобней один раз запросить и позже все время подставлять программно» будут посланы лесом.
                                    • 0

                                      По вопросу 3 — не утверждаю, но насколько слышал, Документолог хранит пароли у себя в базе. Используется в НИТ, Самруке, Зерде. Еще знаю одну АОшку, где Документолог у них облачный, т.е. не на площадке АО, а где-то на площадке самого Документолога. Скорей всего, доступа к этим данным, на совести админов и разработчиков уже Документолога.

                                      • 0
                                        Документолог, на сколько я знаю, вообще не имеет права заниматься разработкой таких вещей. Да и не проходили они никакой аттестации и т.п.
                                    • 0
                                      Что можно сделать

                                      А как же 3-й вариант: разработать кастомный Государственный Браузер со встроенной заменой NCALayer?
                                      • +1
                                        Уверен, в таком случае появится другие статьи, где будут писать о недовольных пользователей этим браузером, то что браузер не безопасен, и что они вообще хотят право выбора.
                                      • +1
                                        Вот такой вариант тоже есть:
                                        вырезка из этого форума

                                        если этот JS библиотека будет отдаваться с pki.gov.kz
                                        и даже сам процесс считывания подписи с браузера только со страницы pki.gov.kz, аля sso.gov.kz сделать бы…

                                        я вижу это так
                                        1) есть сайт который использует функционал ЭЦП авторизация/подпись, пользователь нажимает НАЧАТЬ ПОДПИСЬ
                                        2) его перекидывает на страницу подконтрольную НУЦу типа sso.gov.kz, там включен js скрипт который может считывать и подписывать, клиент подписывает файловым сертификатом ну или оттуда же ему предлагается что то типа NCALayer'а для хардвейрных ЭЦП
                                        3) после успешной подписи его перекидывает на изначальную страницу

                                        Такой же процесс используется в интернет оплатах — epay.kkb.kz
                                        • 0

                                          Добавлю, чтобы было надежно, это ресурс полностью выложить в opensource и устанавливать через какой-то static site gen. Для повышения доверия.

                                        • 0
                                          Тоже смотрел механизмы работы наших NCALayer. У меня касательно организации нашего egov напрашивается один вывод — очень небезопасно. По моему, ошибка в том, что нельзя было выпускать даже публичные ключи из рук госорганов. Всё подписывание должно быть на pki.gov.kz, все сайты работающие с ЭЦП должны обращаться не к локальному NCALayer, а к pki.gov.kz. А pki.gov.kz должен сертифицировать сайты на работу с ЭЦП, сайты должны быть в его списках. А вот аутентификация физ/юр лица на pki.gov должна быть многофакторной — скажем пароль + одноразовый код по СМС (номер телефона зарегистрирован на pki.gov.kz) + одноразовый код по электронной почте. То есть — вам надо с 3-х мест правильно ответить. И пусть в течение скажем 3 минут. Потом по новой авторизация.
                                          • 0
                                            Насколько я понимаю, здесь узкое место в самом процессе подписывания, так как средства джаваскрипта браузера не позволяют ему работать с ключами (rsa, gost). И в любом случае нужен аналог NCALayer.
                                            А вот возможности многофакторной авторизации на доверенном сайте действительно были бы весьма кстати.
                                            • 0
                                              По моему мнению, пользователь (физ/юр) не должен иметь доступа к средствам подписывания и даже к открытым ключам. Вся работа должна делаться на закрытом госсайте, который по своим каналам авторизует пользователя, и по своим каналам принимает документы, и возвращает подписанные рабочему сайту. Пользователь только авторизуется и отправляет заявки на госуслуги, и получает подписанные «государством» доки. На компьютере пользователя не должно быть ничего компроментирующего, через его компьютер не должно проходить ничего, кроме его документов. Еще меня убивает поведение народа и «помощников» при выдаче ЭЦП в ЦОНах — эти пары ключей просто в открытую на свободных компьютерах лежат. Пароли ставятся как попало. Копируй что хочешь на флешку и пользуйся чужой личность и его мат ценностями.
                                              • +1
                                                Насчет поведения тоже согласен: смысл криптографической защиты обесценивается за счет безответственного отношения к своим и чужим ключам.
                                                Но думаю это до первого прецедента. Например, пока кто-то таким образом «законно» не переоформит на себя чужую собственность. Напрямую это вроде как пока сделать нельзя, но можно к примеру женить кого-то на себе, а потом при разводе вымогать деньги :)
                                                • +1
                                                  Теряется весь смысл ЭЦП как аналога собственноручной подписи
                                                • 0
                                                  так как средства джаваскрипта браузера не позволяют ему работать с ключами (rsa, gost)

                                                  А в чём это заключается? Не совсем понимаю, как такое может быть. Вы имеете ввиду, что нет готовой реализации? Я всё время думал, что NCALayer используется из-за:


                                                  • Лени писать нормальное решение, когда есть старый Java-криптопровайдер и можно взять потроха от него.
                                                  • Проблемы поддержки различных USB-устройств с токенами на стороне браузера через JavaScript. В эту сторону не копал, возможно тут и правда всё грустно.
                                                  • 0
                                                    Да, я имел в виду что нет готовой реализации. Есть Web Crypto API, но у них написано что это «экспериментальная технология».
                                                    • 0
                                                      И что теперь? Думаете это обозначает, что её поддерживать не будут, а NPAPI и Java — будут?

                                                      Ну-ну.
                                                    • 0
                                                      Как из браузера общаться с внешним устройством (да, обычно это USB)?

                                                      Приватный ключ лежит на пластике с чипом.
                                                      Раньше был NPAPI. Потом его выпилили. Начали пилить Web Crypto. Но и с ним есть проблема. Ниже опишу какая.
                                                      • 0

                                                        Много ли народу имеет это внешнее USB устройство? Больше 1%? Мне кажется ради них можно было бы и какой-нибудь плагин в Chrome написать (каких там только сейчас нет...). А для остальных всё реализовать средствами JS или WASM.

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

                                                            Ясно. Т.е. сыр-бор в том, чтобы в JS окружение не попало содержимое файла, и его обрабатывало что-то предустановленное, а следовательно "надёжное"? Это я могу понять, хотя на мой взгляд, толку с этого примерно нисколько. Тот же HTTPS подделать вроде нельзя, т.е. надёжная технология, и какая разница между:


                                                            • доверить содержимое файла JS-коду с pki.gov.kz через https
                                                            • доверить содержимое файлу какой-то софтине скачанной опять же с pki.gov.kz через тот же TLS (wss)

                                                            не ясно.

                                                            • 0

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

                                                              • 0

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


                                                                А код Java-приложения, так же как и потенциальное JS решение, вы всё равно из одного источника берёте.

                                                  • +1
                                                    Фундаментально неверно.
                                                    Криптография так не работает.
                                                    Это все равно что сказать, а давайте всех нотариусов закроем, и откроем одного, и когда нужно будет выпустить доверенность, пусть граждане по почте шлют свои заявки, а тот нотариус обрабатывает заявки и в ответ высылает по почте готовые доверенности. Оптимизация деятельности налицо.

                                                    Подписание должно быть на доверенном устройстве (нотариус должен быть вам очно доступен).

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

                                                    Если не хотите, чтобы кто-то вместо вас подписывал электронные документы (выпускал от вашего имени доверенности), эти два требования нужно соблюдать.
                                                  • 0

                                                    А я хочу попросить НУЦ включить https на своем сайте. Его отсутствие режет глаза, тем более с него скачивается тот самый NCALayer. Причем он устанавливает в систему корневые сертификаты НУЦ РК (GOST + RSA). Кому интересно вот инструкция по установке. Только прошу использовать глобально доверенный CA в отличие от https://egov.kz/cms/ru, чей TLS подписан тем самым корневым RSA c вашего http сайта.

                                                    • 0
                                                      Некоторые ресурсы вообще не используют NCALayer, как обстоят дела с безопасностью в этом случае? например podpishi.kz
                                                      Получается они через javascript сертификат загружают в браузер?
                                                      • 0

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


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

                                                        • 0

                                                          Наложить RSA подпись можно в браузере через Web Crypto API.

                                                          • +2
                                                            Если мы работаем с файлами, тут вообще ничего сложного нет. Файл можно открыть JavaScript-ом, распарсить ключ, взять реализацию RSA на JS и ей подписать что надо. Web Crypto API тут никаким боком не нужен. Проблемы начинаются, когда надо работать с USB-криптоключами.
                                                        • 0
                                                          А есть ли на егове услуги, ради которых можно украсть чужой эцп?
                                                          П.С. Пожениться на егове нельзя, а только лишь подать заявку, а потом уже ножками идёшь в ЗАГС.
                                                          • 0

                                                            Дело не только в егове. Проблема везде где используется NCALayer. Но чтобы эксплуатировать эту уязвимость, нужно чтобы были выполнены заранее определенные условия.

                                                            • 0
                                                              Можно получить информацию о человеке.
                                                              Какая собественность у него есть, какие штрафы, налоги платит. Через судебный кабинет можно получить доступ к документам по судебным делам. Уже не мало.
                                                            • +1
                                                              Главная проблема подписания (где угодно, хоть в браузере) — отделить собственно подписание от всего остального. Подписание должно выполняться на доверенном устройстве, в отдельном процессе (threads в ит терминах). Все манипуляции с приватным ключом должны выполняться в этом отдельном процессе, в том числе ввод пина для приватного ключа.

                                                              И вот тут главная проблема, пользовательский опыт. Люди открывая сайт, ожидают взаимодействия с этим сайтом, а не отдельным приложением. Собственно поэтому компромиссы: ввод пути до приватного файла из браузера, ввод пина из браузера, и т.д… Если сделать все канонически правильно, то таким решением смогут воспользоваться меньшее количество людей. Не видел ни одного канонически правильного решения, которое успешно работает с аудиторий от нескольких миллионов обычных людей. Приходится выбирать либо аудитория, либо каноны безопасности.
                                                              • 0
                                                                Если сделать все канонически правильно, то таким решением смогут воспользоваться меньшее количество людей.

                                                                А что подразумевается под канонически правильным решением? Мне вот видится простое решение:


                                                                • Встраиваемый через HTTPS Iframe (ну или напрямую) через https://pki.gov.kz или другую гос. площадку
                                                                • Загрузка файла традиционным образом в этот <iframe/> через <input type="file"/>
                                                                • Вся криптография средствами frontend JS (даже без webcrypto)

                                                                Какие недостатки? С точки зрения пользователя (без USB устройств) всё стало только проще.

                                                                • 0

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

                                                                  • 0
                                                                    и коду, которому он доверяет

                                                                    А где взять такой код? Что нужно сделать, чтобы к нему появилось доверие?


                                                                    Веб-технологии не предполагают доверия коду, он изменяется без уведомления пользователя.

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


                                                                    Замечу, что это java-приложение качается по HTTP (не HTTPS). Я сейчас проверил — HTTPS редиректит на HTTP.


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

                                                                    • 0
                                                                      exe-файл инсталлятора подписан валидной подписью, без разницы, как его качать.
                                                                      • 0

                                                                        Проверил. Скачал — там zip архив и bash-скрипт. Какая подпись? Внутри груда bash-кода в KOIR8 или типа того.

                                                                        • 0
                                                                          Я про Windows писал. С Linux хз.
                                                                      • 0

                                                                        И никакой сертификации нет? Типа ФСБ/ФСТЭК в России?

                                                                        • 0

                                                                          Понятия не имею. Вот страница загрузки NCLayer-а. Принудительный HTTP. Внутри архива баш-скрипт.

                                                                  • 0
                                                                    Четкое отделение собственно подписания от всего остального порождает другое, на мой взгляд лаконичное, решение, которое уже привязывается к смартфонам.
                                                                    Подробнее описал ниже.
                                                                    • 0
                                                                      Подписание должно выполняться… в отдельном процессе

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


                                                                      в отдельном процессе (threads в ит терминах).

                                                                      Так в отдельном потоке (thread) или процессе (process)? Если хватает потока — ну подпишите его в webworker-е. Если процессе — то да, браузер так вывернуться не даст.

                                                                      • 0
                                                                        в линуксе особой разницы между thread и process нет. но, да, в других ос thread/process серьезно различают.
                                                                        для них разные process. в идеале браузер не должен ничего знать ни про приватный ключ, ни про пин, ни про алгоритмы подписи.

                                                                        Web Crypto по сути должен предоставить доступ к api, который все это (в том числе подписание) реализует в виде отдельного приложения/драйвера. А это опять потенциальная дыра — NPAPI, Flash, java applet потому и выпилили из браузеров, что давали доступ к ресурсам ОС через браузер. В общем замкнутый круг.
                                                                        • 0
                                                                          Web Crypto по сути должен предоставить доступ к api, который все это (в том числе подписание) реализует в виде отдельного приложения/драйвера

                                                                          Который всё равно будет запущен этим самым браузером. Разве что изоляция будет большая. Но всё равно предполагается, что мы доверяем браузеру.


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

                                                                          Ну вот сейчас это реализовывается путём скачивания java-приложения через internet. Какого рода уязвимости мы таким образом "победили"? В чём разница между


                                                                          • "мы запускаем неизвестный нам код, скачав его из сети, предоставляя ему доступ к содержимому файлов с ключами".
                                                                          • "мы запускаем неизвестный нам код через https-сайт, предоставляя ему доступ к содержимому файлов с ключами".

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


                                                                          Впрочем туда так и так ходить приходится, ибо сложно найти на egov хоть что-то, что хоть как-то работает (кроме разве что выдачи адресной справки).

                                                                          • 0
                                                                            Ну вот сейчас это реализовывается путём скачивания java-приложения через internet. Какого рода уязвимости мы таким образом "победили"? В чём разница между

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

                                                                            • 0

                                                                              Вы сами в это верите? Вот если бы я грузил исходный код из репозитория (причём без всяких blob-ов) через TLS, и собирал это "руками". Тогда можно было бы заикаться про какую-то конкретную версию софта, которой пользователь "доверяет". На деле я гружу чёрный ящик, который ещё и сам обновляется, да ещё и по незащищённому каналу.


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

                                                                              Вы уже второй раз об этом пишете. Но я об этом и не заикался. Зачем?

                                                                              • 0

                                                                                Вдобавок — оно ещё и не работает из коробки. Нужно всем браузерам прописывать дополнительные удостоверяющие центры сертификации "Большого брата". За это отдельный "respect" государству :)

                                                                                • 0

                                                                                  Это как раз вполне разумно, ожидаемо и вызывает вопросы, если этого нет.

                                                                            • 0
                                                                              А это опять потенциальная дыра — NPAPI, Flash, java applet потому и выпилили из браузеров, что давали доступ к ресурсам ОС через браузер.
                                                                              Нет. Их выпилили потому, что они давали возможность доступа к ресурсам ОС без явного уведомления пользователя. А если это происходит по инициативе пользователя — проблем нет, Native Messaging же есть.
                                                                          • 0
                                                                            Не видел ни одного канонически правильного решения, которое успешно работает с аудиторий от нескольких миллионов обычных людей.
                                                                            А искали? Вот, например.
                                                                            • 0
                                                                              Это устройство. Их (устройств) немало.
                                                                              А я спрашивал про проекты с миллионной аудиторией, которые бы в один прекрасный день сказали, так, ребята, пользователи, в течении года переходим на использование устройства Х. Кто не перешел, мы не виноваты. Воспользоваться нашими услугами не сможете.
                                                                              При этом, использование устройства Х было бы реализовано канонически верно, без компромиссов.
                                                                              • 0
                                                                                Кто не перешел, мы не виноваты. Воспользоваться нашими услугами не сможете.
                                                                                А. Это пожалуйста. Или вы хотите совсем принудительно. Как «онлай-кассы» в России. Ндравится?

                                                                                Всё-таки мне кажется, что с дополнительной стадией, когда какое-то время у вас есть выбор — оно… человечнее.
                                                                          • 0
                                                                            Есть еще такой вариант решения.
                                                                            1. Создаются отдельные приложения для смартфонов, единственной функцией которых будет подписывание. Ключи пользователя будут хранится только на его смартфоне.
                                                                            2. Далее все заинтересованные сайты-сервисы именно на этапе подписывания генерируют какой-нибудь qr-код с хэшем документа.
                                                                            3. Пользователь сканирует этот код через свое приложение и подписывает.
                                                                            4. Далее приложение на смартфоне передает сервису-источнику публичный ключ с подписью для проверки.

                                                                            Для конечного пользователя здесь похожий принцип, по которому пользователь открывает ватсап на своем десктопе.
                                                                            На мой взгляд, это будет и удобно, и с точки зрения безопасности все нормально должно быть.
                                                                            Также и дорабатывать много чего не надо, так как уже похожие приложения тот же egov выпускает кажется.
                                                                            • 0
                                                                              Такие приложения уже есть.
                                                                              Но и с ними свои сложности. Без интернета не подпишешь, как безопасно хранить приватный ключ (разработчики мобильных ОСей предоставляют специальный API, но большинство соглашается, это не гарантирует неразглашения). В общем использование мобилок привносит свои компромиссы.
                                                                              • 0
                                                                                Интернет все-таки тут обязательное требование, без него все остальные сервисы не имеют смысла. Исключение это только какие-нибудь корпоративные системы документооборота.
                                                                                Насчет хранения ключей, конечно до аппаратных токенов будет далеко, но получше будет чем сейчас, когда на флэшке всё. Да и пароль самого ключа никто не отменял.
                                                                                • 0
                                                                                  Насчет хранения ключей, конечно до аппаратных токенов будет далеко
                                                                                  А почему далеко? Почему, блин, GitHub может, а Казахстан — не может? В чём разница?
                                                                                  • 0
                                                                                    FIDO U2F выглядит интересной технологией для авторизации. А как его можно применить для подписания документа?
                                                                                    • +2
                                                                                      Никак. Но Yubiko можно ставить дополнительные аплеты. SSH, например.

                                                                                      Для Github'а — этого достаточно. Для подписи документов нужно будет что-то другое сделать. Но для этого нужно делать, а не плакать, что технологии экспериментальные. Конечно экспериментальные — кто ж их неэксперементальными должен сделать? Марсиане?

                                                                                      Не можете договориться с Оперой или Гуглом? Обратитесь в Yandex, пусть они в свой браузер вкрутят, все остальные встанут перед фактом: или госпредприятия в России и Казахстане все поголовно переходят на Yandex-браузер, либо Гугл берёт патчи от Yandex'а и Chrome — тоже начинает поддерживаться.

                                                                                      А под лежачий камень вода не течёт… шевелиться надо.
                                                                                  • 0
                                                                                    На самом деле, есть возможность хранить ключи на сим-карте. И в таком случае интернет-соединение не нужно, но нужна связь в принципе. На сим-карте просто будет аплет, который будет обрабатывать запросы, а пользователю останется отвечать(да\нет). При чем у этого решения есть как плюсы, так и минусы. Из плюсов, работает даже на самых простых(кнопочных телефонах). Минусы — как минимум необходимы специальные сим-карты.
                                                                                • 0
                                                                                  1. Как пользователь убедится, что qr-код соответствует тому, что он собирается подписать, а не договор дарения квартиры это?
                                                                                  • 0
                                                                                    Тут тогда нужно усложнять логику.
                                                                                    1. Можно идти в сторону унификации формата документов: например, использовать markdown или другой похожий несложный формат. В таком случае во время подписи, он будет загружать текст документа на смартфон, там уже можно сверять хэши. В случае с бинарными данными даже не знаю как будет лучше.
                                                                                    2. Также можно работать на сертификацией самих онлайн-сервисов, т.е. не принимать документы от кого попало.
                                                                                • +3
                                                                                  У ЭЦП в Казахстане 2 проблемы: пользователи и разработчики. Пользователи вообще в большинстве своём не понимают, что такое ЭЦП и ничтоже сумнящеся готовы раздавать ключи всем подряд, пароли «123456» и всё такое. Разработчики не понимают, что от них требуется, нет каких-то формальных требований по использованию ЭЦП. Вот если сайт elicense.kz, он не поддерживает Kaztoken (usb-крипто ключ, хоть какая-то гарантия от того, что стырят ключ), для входа на сайт (то бишь аутентификации) используется SIGN-сертификат. А это государственный сайт, которым все пользуются. Кто его писал, кто принимал — хз. Я сам писал несколько проектов с использованием ЭЦП, я пытался разобраться, что от меня требуется, я читал законы. Никаких нормативных актов я не нашёл. В итоге реализовывал все детали как мне казалось правильным. API аплета убогое и неполное было на тот момент, скорей всего таким и осталось (например нельзя подписать бинарную данные, только ASCII), для своих целей, впрочем, его хватало. В гос-документах частенько встречаются QR-коды, на которые чиновники молятся, вон мол эцп она самая. И требуют эти QR-коды от разработчиков. Что внутри QR-кодов? Да где как, где-то URL какой-то, где-то зазипованная XML с подписью, где-то ещё что-то.

                                                                                  В общем бардак. И от всеобщего коллапса спасает только то, что хакеры в Казахстане, видимо, не лучше. Да и ничего не сделать с этой ЭЦП моему. Навредить человеку можно, а получить от этого выгоду?

                                                                                  Кстати ещё один камень в огород. Раньше в апплете был прописан список сайтов, на которых его можно было использовать. Другие сайты его использовать никак не могли (Java проверяла подпись). Ну т.е. могли, конечно, купить подпись и переподписать, но в исходном виде не могли. Надо было связываться с разработчиками (pki.gov.kz) и просить их включить сайт в список разрешённых. Насколько я понимаю, тот апплет был единственным сертифицированным КНБ софтом для работы с ЭЦП, поэтому если хочешь что-то делать сам, тебе надо было бы проходить сертификацию, а кому это надо, в общем апплет безальтернативен, лол. Так вот, когда я последний раз расковыривал NCALayer, в нём не было никаких проверок того сайта, который с ним связывается (он слушает на 127.0.0.1: чего-то и общается через websocket), то бишь habrahabr.ru может легко связаться с NCALayer-ом, поподбирать путь к сертификату, поподбирать пароль и тд. Если у меня сейчас воткнут казтокен, он может легко исчерпать 3 попытки и казтокен превратится в бесполезную пластмасску, например. Хз, может с тех пор исправили, техническая возможность есть, но не уверен.
                                                                                  • +1
                                                                                    Спасибо за прекрасный материал, показывающий как на самом деле выглядит наша безопасность «под капотом». Согласен про двустороннюю проблему пользователи-разработчики. Хотелось бы отметить пару практических моментов со стороны пользователей.

                                                                                    1) «с ЭЦП ничего не сделаешь». Мантра разработчиков. С самой ЭЦП ничего, но в составе других преступных деяний, ЭЦП очень даже поможет реализовать замысел. Получить подробности недвижимости которой вы владеете например,… «информация правит миром». Или жениться/развестись без ведома второй стороны. Да, выше правильно указано — заявление подали, а дальше в ЗАГС идти надо. Но в ЗАГСЕ вам бумажки отдадут не поднимая головы. Они же уверены — человек ЭЦП подписал — нафига его с личностью сверять?

                                                                                    А уж произвольному гражданину временную прописку организовать по случайному адресу — это прям вообще легко.

                                                                                    Дело осложняется еще больше, если у гражданина есть собственность в виде компании…

                                                                                    2) хотелось бы услышать такой же анализ про налоговый КНП плагин. Подозреваю, что это какой-то вариант NCLayer. По-крайней мере вместе в одном компе они не живут. Думаю дерутся за общий порт сокета. Но нафига нужно было отдельную софтину городить? Вот вопрос. А что со Статистическим Управлением? Нафига они на странице входа требуют не подпись для аутентификации? Это «стиль такой»?

                                                                                    3) умиляет разделение на «государственные и частные» сайты. Как будто тот факт, что вы зашли на государственный сайт вас от чего-то защищает. Наоборот. Именно из государственных недров достаются всякие «базы ГАИ» и прочие вещи, продающиеся на базарах. Именно против государственных органов бессмысленно подавать иски, хотя частные компании сравнительно легко разорить до копейки, если они «жульничали» или «халявили безопасность». База «путей и паролей» полагаю могла бы стать реальным объектом заработка несчастных админов из страны с минимальной заработной платой в USD 70.

                                                                                    Эта же цифра стоит у меня перед глазами, когда я представляю «государственные органы» в виде заказчиков какого-либо решения с ЭЦП. Сначала «надо чтобы выглядело дорого-богато»: отдельная инфраструктура, бюджет на аппаратное решение, напишем собственный вариант NCLayer. А потом: «а можете вот эту ваши смету поделить на 4. А то дорого очень...». «Конечно можем — но безопасность будет никакая»… Никакой конкретной информацией не владею. Но виртуальный диалог выглядит очень правдоподобно.

                                                                                    4) Можно ли создать общие рекомендации для пользователей ключей на текущий момент?
                                                                                    Что-то в духе меняйте пути к ключам после каждого использования на подозрительных государственных сайтах? Меняйте пароли по понедельникам? Перевыпускайте ключи раз в месяц? Что-нибудь из перечисленного имеет смысл?
                                                                                    • 0

                                                                                      По второму вопросу — это решение называется CryptoSocket от Гамма Технологии. В ближайшее время также постараюсь его рассмотреть. Предварительно скажу, если оно запрашивает пароль всего один раз и то через формочки на сайте. То там такая же ситуация. К сожалению моментально посмотреть не смогу, так как пользуюсь ОС Linux под которую нет версий CryptoSocket.
                                                                                      http://gamma.kz/product/21

                                                                                      • 0
                                                                                        CryptoSocket будет работать только с теми сайтами, у кого есть apiKey либо на локалхосте, в таком случае ключ не требуется. Каждый сайт должен иметь свой ключ апи. По факту «узявимости» — если пользователь использует ключи с файловой системы, то пользователь уязвим и для этого не нужен ни криптосокет, ни ncalayer — достаточно выдать форму с выбором файла ключа и полем для ввода пароля, которые тупо отправятся на сервер. Можно сравнить с пожертвованиями волонтерам на улице — деньги пойдут либо на те цели, которые объявлены, либо кому-то в карман. Или с формами оплаты в интернете, куда вы вводите данные от своей карты. В общем, зависит от доверия.
                                                                                      • 0

                                                                                        По четвертому вопросу — все предложенные механизмы для параноиков. А если честно, даже предложенные механизмы не защитят Вас от атак, которые предложены в статье.

                                                                                        • 0
                                                                                          По п.4. Во-первых используйте аппаратные токены. Самое простое это Казтокен (около 10 000 тенге) или удостоверение с чипом и специальный кард-ридер. Во-вторых задавайте хороший пароль для ключа и никуда на компьютере его не сохраняйте (разве что в хороший менеджер паролей). В-третьих не держите устройство включенным в компьютер, если не пользуетесь им. В-четвёртых используйте отдельный компьютер или хотя бы отдельную виртуальную машину для работы с ЭЦП и другими важными сайтами.

                                                                                          Если получали ключи как попало (пришли со своей флешкой, там их вам сгенерировали и скопировали с ЦОН-овского компьютера), выпустите другие ключи через pki.gov.kz, а те отзовите. А вообще ключи получать надо безопасно, благо у нас для этого всё работает как положено: генерируете ключ на своём устройстве, через pki.gov.kz подаёте заявку, распечатываете, подписываете и в ЦОН предъявляете, потом через тот же pki.gov.kz скачиваете сертификаты.
                                                                                          • 0

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

                                                                                            • 0
                                                                                              Это не помогает от перехвата пина.
                                                                                              И это не помогает от подмены информации перед подписью.

                                                                                              Справедливости ради, этим страдает большинство реализаций. Т.к. решения этих недостатков — не юзерфрендли.
                                                                                              • 0
                                                                                                В текущей ситуации от этого ничего не поможет. Разве что писать свой аналог NCALayer без его недостатков. Но вряд-ли за это кто-то заплатит. Но это гипотетические атаки, а вот тупо скопировать файл с ключом это, на мой взгляд, более реальная атака.
                                                                                            • 0

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

                                                                                            • 0

                                                                                              По второму вопросу — это решение называется CryptoSocket от Гамма Технологии. В ближайшее время также постараюсь его рассмотреть. Предварительно скажу, если оно запрашивает пароль всего один раз и то через формочки на сайте. То там такая же ситуация. К сожалению моментально посмотреть не смогу, так как пользуюсь ОС Linux под которую нет версий CryptoSocket.
                                                                                              http://gamma.kz/product/21

                                                                                              • 0

                                                                                                Здесь я ошибаюсь, здесь используется какое-то другое решения для КНП.

                                                                                                • 0
                                                                                                  KNPPlugin написан на Java (и то, что сделали сборку только для Windows, на мой взгляд, большое свинство). В исходниках светится строка com.firstlinesoftware.smartauthclient предполагаю, что это их софт.
                                                                                                  • 0
                                                                                                    Как я понимаю, в целом весь кроссплатформенный проект потерпел фиаско. Я помню как это продавали: говорили что вот буквально через 5 лет Windowsу конец, что Windows — это дорого, что в ЦОНах надо ставить Линукс и т.п. К сожалению ни в одном месте я так Линукса «для экономии» и не увидел. Ни в Налоговой, ни в ЦОНах. Плюс реализация на Java принесла много «ужасов настройки», дыр, непрерывные security fix, которые нужно было «немедленно ставить». В общем, это было заведомо мертвое решение. По мне так изначальная архитектура всего этого мероприятия была выбрана с учетом того, что мы нефтяной монстр и денег на все хватит и еще останется. Та же Эстония и Дания, которых мы теперь приглашаем рулить инфраструктурой и упоминаем в государственных программах — многие из наших граблей избежали. Хотя у них есть свои.

                                                                                                    Вероятно и причина ссоры с Гаммой была в том, что «кроссплатформенное решение» не хотело без бубна переносится даже между Windows 8 и Windows 8.1. И у меня были подозрения, что это неспроста. Впрочем — это все догадки неспециалиста.
                                                                                                    • 0
                                                                                                      Вероятно и причина ссоры с Гаммой была в том, что «кроссплатформенное решение» не хотело без бубна переносится даже между Windows 8 и Windows 8.1. И у меня были подозрения, что это неспроста. Впрочем — это все догадки неспециалиста.
                                                                                                      Догадки, близкие к истине, тем не менее.

                                                                                                      Я это много лет назад наблюдал в американской конторе. Которой тоже захотелось кроссплатформенности и они заказали на оутсорс решение на Java «для кросс-платформенности». Беда в том, что это было во времена, когда у Microsoft ещё была своя Java, а MS IE занимал 90% рынка браузеров — ну и решение в решение в результате только под MS IE и работало… потому что там от java был только запускач, который загружал нативную DLL'ку.

                                                                                                      Всплыло это через неск