Комментарии 138
Это не проблема egov.kz. Такой механизм реализовать сейчас считаю сомнительным, так как ЭЦП мало где внедрено и в основном госорганы. Если же начнут появлятся разные сайты с ЭЦП от компаний, тогда эта проблема становится актуальной.
Через смс мало кто внедрять будет, так как каждое смс будет стоить 6 тенге (1 рубль), затраты должны взять на себя владельцы интернет ресурсов. Про стоимость пруф не искал, рассказал знакомый который работает админом на один из информационных порталов в казнете.
Что-то ответили?
По идее, криптопровайдер локально на компе пользователя должен запросить пароль от закрытой части ключа ЭЦП при попытке что-то подписать со стороны сайта, а не передавать ему (сайту) пароль в открытом виде…
основное требование для работы с ЭЦП — использование своего, сертифицированного криптопровайдера. Криптопровайдеры, которые использует браузер — не сертифицированные.
Ясно-понятно.
Браузерные криптопровайдеры же тоже передают эцп на сайт, в нашем случае тем более сверка с сервером НУЦ необходима
Предлагайте варианты… смс авторизация опять не внушает оптимизма
Казахстану инвестировать в развитие браузеров Chrome, Firefox, чтобы можно было нормальное ЭЦП внутри браузеров. Ну чтобы было правильно. Ну и еще криптопровайдер нормально прикрутить к браузерам.
Я конечно скажу бред с точки зрения государственных ИБ Казахстана… но почему нельзя использовать поделие КриптоПро? Да там тоже не всё радужно (при разработке — не единожды умоешься кровью), но откровенных косяков хотя бы нет…
И мстится мне, что ГОСТ-алгоритмы шифрования были придуманы до разделения СССР, и, соответственно, взаимозаменяемы между РФ и Казахстаном...
В виде RFC, почему-то, есть только ГОСТ Р 34.11-2012.
По хорошему-то нужно просто их добавить в брайзеры и всё — но дальше возниктнут проблемы с сертификацией, так что пляски с бубнами неизбежны.
Но это в чистом виде потому, что кому-то нужна «шашечки», а не «ехать».
Думаю проблему можно решить через oAuth. Сторонние сайты запрашиват инфо, временные ключи или одноразовые токены через сам eGov.kz. Сейчас когда ЭЦП пользуются только госорганы все более менее нормально, а когда подключатся частные компаний к сети, то возможность того что ЭЦП "своруют" увеличивается.
а как подписывать документы? здесь без разницы, достаточно один раз засветить свои ключи на сайте.
— Используя oAuth можно авторизвать юзера и получить токен для работы с апи egov от его имени, при этом вход через текущий механизм произойдет только на стороне egov
— Используя полученный токен, дергаем апи egov'a, куда посылаем файл для подписи, в ответ получаем ссылку куда должен пойти юзер
— Редиректим юзера на эту ссылку (ссылка на домен егова ведет), он видит файл для подписи, использует эцп для подписи, после успеха/неаудачи возвращаем юзера на сайт
— Делаем опять апи вызов к егову, проверяем что файл подписан, забираем его себе
Из плюсов в этой схеме, все манипуляции с ЭЦП происходят на стороне egov, стороннему сайту нужно использовать только всем известный oAuth и реализовать три не сложных апи вызова к egov
Из минусов, проблема с NCALayer остается, но по крайней мере она будет существовать только в пределах самого egov, которому придется доверять
Судя по https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API, только в Chrome и Opera.
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$.
- В чём профит? Сейчас там хотя бы WSS, а не WS. А вы предлагаете по HTTP. Не совсем понятно что/зачем. 127.0.0.1 там и так.
- У них так исторически сложилось. ЕМНИП, ещё пока applet был на java работало всё также. Отдали всё на откуп программистам, сняв с себя ответственность. Удобно, чо :)
- Ну к чёрту. Серьёзно. Сейчас это хоть как-то работает, причём везде. А займутся C#, Objective C, GTK — мы получим зоопарк полурабочих решений. Если они даже tray-icon-у нормальную сделать за пару лет не осилили (в linux mint это какой-то аномальный прямоугольник с иконкой в углу, ещё и не с прозрачным фоном)… Боюсь что занявшись рюшечками linux вообще пропадёт из доступных решений.
Я не могу сформулировать, чем это плохо
Как минимум, это формальная попытка ввести пользователя в заблуждение. Заходит он на 127.0.0.1, видит сертификат, читает в нём, что сертификат выдан одной организацией, которой он доверяет, другой организации, которой он тоже доверяет. Начинает пользоваться, не подозревая, что ни одна, ни другая организация адрес 127.0.0.1 не контролируют. Контролирует его он сам, его админы, или хакеры, которые локально вырезали сертификат и прицепили его к своему сервису.
9. Из-за проблем со скоростью подписывался и до сих пор некоторые подписывают хеш большого файла а не сам файл.Не некоторые, а все. Потому что подписывать напрямую RSA файл в мегабайт — вам нужна будет не одна чашка кофе.
Если используется достаточно надёжных хеш (тот же SHA-3 сегодня), то это достаточно надёжно и быстро.
2.
Уязвимы ВСЕ ресурсы, которые используют NCALayer.Опрометчивое заявление. Сейчас есть возможность в NCALayer добавить свой подключаемый модуль. Использовать короткоживущие токены. Ну и т.д. и т.п. Т.е. вероятность проведения успешной атаки будет в несколько процентов. Как инструмент для коммерческих махинаций не подойдёт.
3.
Насколько я слышал, уже есть системы, которые хранят путь к ключам ЭЦП и пароль в настройках.Хотелось бы узнать примеры…
4.
Продвигать web crypto apiЭм, каким образом? Неужели вы думаете, что даже совместными усилиями в рамках Таможенного Союза участники смогут производителей браузеров добавить различные алгоритмы генерации, которые у них прописаны в законах.
Я отлично понимаю, что у некоторых бомбит по этому поводу. Для параноиков, имеющих навыки программирования посоветую просто реализовать свою прилажуху, которая будет эмулировать NCALayer. Работы не так уж и много. Можно кучкануться и замутить открытый проект. Ну а в НУЦ, конечно, относятся к таким вещам весьма расслаблено. Знаю на собственном опыте.
Неужели вы думаете, что даже совместными усилиями в рамках Таможенного Союза участники смогут производителей браузеров добавить различные алгоритмы генерации, которые у них прописаны в законах.Разработчики браузеров что — ангелы, живущие на небе? Попробуйте предложить patch'и и посмотрите на реакцию. Если сошлётесь на требования закона — с вероятностью 90% будут вопросы только к технической реализации. Но вот тут — да, поблажек не будет. Дикие идеи типа «удобней один раз запросить и позже все время подставлять программно» будут посланы лесом.
По вопросу 3 — не утверждаю, но насколько слышал, Документолог хранит пароли у себя в базе. Используется в НИТ, Самруке, Зерде. Еще знаю одну АОшку, где Документолог у них облачный, т.е. не на площадке АО, а где-то на площадке самого Документолога. Скорей всего, доступа к этим данным, на совести админов и разработчиков уже Документолога.
Что можно сделать
А как же 3-й вариант: разработать кастомный Государственный Браузер со встроенной заменой NCALayer?
вырезка из этого форума
если этот JS библиотека будет отдаваться с pki.gov.kz
и даже сам процесс считывания подписи с браузера только со страницы pki.gov.kz, аля sso.gov.kz сделать бы…
я вижу это так
1) есть сайт который использует функционал ЭЦП авторизация/подпись, пользователь нажимает НАЧАТЬ ПОДПИСЬ
2) его перекидывает на страницу подконтрольную НУЦу типа sso.gov.kz, там включен js скрипт который может считывать и подписывать, клиент подписывает файловым сертификатом ну или оттуда же ему предлагается что то типа NCALayer'а для хардвейрных ЭЦП
3) после успешной подписи его перекидывает на изначальную страницу
Такой же процесс используется в интернет оплатах — epay.kkb.kz
А вот возможности многофакторной авторизации на доверенном сайте действительно были бы весьма кстати.
Но думаю это до первого прецедента. Например, пока кто-то таким образом «законно» не переоформит на себя чужую собственность. Напрямую это вроде как пока сделать нельзя, но можно к примеру женить кого-то на себе, а потом при разводе вымогать деньги :)
так как средства джаваскрипта браузера не позволяют ему работать с ключами (rsa, gost)
А в чём это заключается? Не совсем понимаю, как такое может быть. Вы имеете ввиду, что нет готовой реализации? Я всё время думал, что NCALayer используется из-за:
- Лени писать нормальное решение, когда есть старый Java-криптопровайдер и можно взять потроха от него.
- Проблемы поддержки различных USB-устройств с токенами на стороне браузера через JavaScript. В эту сторону не копал, возможно тут и правда всё грустно.
Приватный ключ лежит на пластике с чипом.
Раньше был NPAPI. Потом его выпилили. Начали пилить Web Crypto. Но и с ним есть проблема. Ниже опишу какая.
Много ли народу имеет это внешнее USB устройство? Больше 1%? Мне кажется ради них можно было бы и какой-нибудь плагин в Chrome написать (каких там только сейчас нет...). А для остальных всё реализовать средствами JS или WASM.
Все крутится вокруг того, что если хочется честную безопасность, то приватный ключ должен быть на отдельном устройстве, и никогда его не покидать. Все остальное это компромиссы, вплоть до того, а давайте создадим «простую электронную подпись», которая к криптографии никакого отношения не имеет.
Ясно. Т.е. сыр-бор в том, чтобы в JS окружение не попало содержимое файла, и его обрабатывало что-то предустановленное, а следовательно "надёжное"? Это я могу понять, хотя на мой взгляд, толку с этого примерно нисколько. Тот же HTTPS подделать вроде нельзя, т.е. надёжная технология, и какая разница между:
- доверить содержимое файла JS-коду с pki.gov.kz через https
- доверить содержимое файлу какой-то софтине скачанной опять же с pki.gov.kz через тот же TLS (wss)
не ясно.
В случае предустановленного ПО закрытый ключ не покидает (если верить производителю и органу сертификации) локального компа. В вашем случае, как я понял, он туда даже не попадает, что полностью убивает смысл ЭЦП.
Вы вероятно меня не поняли. А я вас. Сейчас у нас (у казахстанцев) запущено на фоне java-приложение. С ключами работает оно. В случае если этот же код (но уже JS) будет отрабатывать не в Java, а в браузерной вкладке, ключи не начнут куда-то ходить. Все операции также будут выполняться локально. Только теперь в JS VM, а не в Java VM. Они всё также останутся на вашей стороне. По сети пойдёт лишь результат.
А код Java-приложения, так же как и потенциальное JS решение, вы всё равно из одного источника берёте.
Криптография так не работает.
Это все равно что сказать, а давайте всех нотариусов закроем, и откроем одного, и когда нужно будет выпустить доверенность, пусть граждане по почте шлют свои заявки, а тот нотариус обрабатывает заявки и в ответ высылает по почте готовые доверенности. Оптимизация деятельности налицо.
Подписание должно быть на доверенном устройстве (нотариус должен быть вам очно доступен).
Приватный ключ из доверенного устройства не должен уходить (ваша подпись должна ставиться на довереность только при очном присутствии нотариуса).
Если не хотите, чтобы кто-то вместо вас подписывал электронные документы (выпускал от вашего имени доверенности), эти два требования нужно соблюдать.
А я хочу попросить НУЦ включить https на своем сайте. Его отсутствие режет глаза, тем более с него скачивается тот самый NCALayer. Причем он устанавливает в систему корневые сертификаты НУЦ РК (GOST + RSA). Кому интересно вот инструкция по установке. Только прошу использовать глобально доверенный CA в отличие от https://egov.kz/cms/ru, чей TLS подписан тем самым корневым RSA c вашего http сайта.
Получается они через javascript сертификат загружают в браузер?
Насколько я понял, они загружают файл к себе на страничку (но не на сервер) и там уже работают.
Но ничего не мешает им выборочно тайно передавать ключ к себе на сервер. Плюс пароль известен. Опять на совести разработчиков.
И потом, это мне кажется намного небезопасней чем использовать NCALayer. Так как NCALayer хотя бы не дает доступ к файлу с ключами.
Наложить RSA подпись можно в браузере через Web Crypto API.
П.С. Пожениться на егове нельзя, а только лишь подать заявку, а потом уже ножками идёшь в ЗАГС.
Дело не только в егове. Проблема везде где используется NCALayer. Но чтобы эксплуатировать эту уязвимость, нужно чтобы были выполнены заранее определенные условия.
Какая собественность у него есть, какие штрафы, налоги платит. Через судебный кабинет можно получить доступ к документам по судебным делам. Уже не мало.
И вот тут главная проблема, пользовательский опыт. Люди открывая сайт, ожидают взаимодействия с этим сайтом, а не отдельным приложением. Собственно поэтому компромиссы: ввод пути до приватного файла из браузера, ввод пина из браузера, и т.д… Если сделать все канонически правильно, то таким решением смогут воспользоваться меньшее количество людей. Не видел ни одного канонически правильного решения, которое успешно работает с аудиторий от нескольких миллионов обычных людей. Приходится выбирать либо аудитория, либо каноны безопасности.
Если сделать все канонически правильно, то таким решением смогут воспользоваться меньшее количество людей.
А что подразумевается под канонически правильным решением? Мне вот видится простое решение:
- Встраиваемый через HTTPS Iframe (ну или напрямую) через
https://pki.gov.kzили другую гос. площадку - Загрузка файла традиционным образом в этот
<iframe/>через<input type="file"/> - Вся криптография средствами frontend JS (даже без
webcrypto)
Какие недостатки? С точки зрения пользователя (без USB устройств) всё стало только проще.
Канонически правильное решение предполагает, как минимум, что приватный ключ доступен исключительно пользователю и коду, которому он доверяет. Веб-технологии не предполагают доверия коду, он изменяется без уведомления пользователя.
и коду, которому он доверяет
А где взять такой код? Что нужно сделать, чтобы к нему появилось доверие?
Веб-технологии не предполагают доверия коду, он изменяется без уведомления пользователя.
Сейчас всё точно так же. Нам выдаётся чёрный ящик. Выдаётся через те самые "веб-технологии". Нет не на флешке в гос. учреждении, а качаешь по сети. Плюс оно обновляется периодически. И нет, исходников, я нигде не встречал (впрочем это же Java, можно развернуть байт-код во что-то худо бедно читаемое).
Замечу, что это java-приложение качается по HTTP (не HTTPS). Я сейчас проверил — HTTPS редиректит на HTTP.
Вот если бы за этим ПО ещё и ногами с флешкой топать в гос.дома нужно было бы, тогда я бы понял, что какая-то разница всё таки есть. А так...
И никакой сертификации нет? Типа ФСБ/ФСТЭК в России?
Понятия не имею. Вот страница загрузки NCLayer-а. Принудительный HTTP. Внутри архива баш-скрипт.
Подробнее описал ниже.
Подписание должно выполняться… в отдельном процессе
Должно кому? Прямо в ТЗ такая строчка? С чьей точки зрения это требование настолько критично, что теперь нужно ставить отдельную левую софтину на свой ПК, ставить к ней JAVA, предварительно запускать и ещё сертификаты от гос-ва принудительно в браузеры подсовывать (в противном случае лезут wss ошибки).
в отдельном процессе (threads в ит терминах).
Так в отдельном потоке (thread) или процессе (process)? Если хватает потока — ну подпишите его в webworker-е. Если процессе — то да, браузер так вывернуться не даст.
для них разные process. в идеале браузер не должен ничего знать ни про приватный ключ, ни про пин, ни про алгоритмы подписи.
Web Crypto по сути должен предоставить доступ к api, который все это (в том числе подписание) реализует в виде отдельного приложения/драйвера. А это опять потенциальная дыра — NPAPI, Flash, java applet потому и выпилили из браузеров, что давали доступ к ресурсам ОС через браузер. В общем замкнутый круг.
Web Crypto по сути должен предоставить доступ к api, который все это (в том числе подписание) реализует в виде отдельного приложения/драйвера
Который всё равно будет запущен этим самым браузером. Разве что изоляция будет большая. Но всё равно предполагается, что мы доверяем браузеру.
в идеале браузер не должен ничего знать ни про приватный ключ, ни про пин, ни про алгоритмы подписи.
Ну вот сейчас это реализовывается путём скачивания java-приложения через internet. Какого рода уязвимости мы таким образом "победили"? В чём разница между
- "мы запускаем неизвестный нам код, скачав его из сети, предоставляя ему доступ к содержимому файлов с ключами".
- "мы запускаем неизвестный нам код через https-сайт, предоставляя ему доступ к содержимому файлов с ключами".
Разница в том, что соседняя вкладка потенциально может иметь доступ к адресному пространству ОЗУ "секъюрной" вкладки? Скорее разница в том, что все эти бубны и танцы приводят к тому, что старшее поколение не осилив весь перечень предварительных действий по любому поводу продолжит ходить ногами в ЦОН-ы и прочие заведения.
Впрочем туда так и так ходить приходится, ибо сложно найти на egov хоть что-то, что хоть как-то работает (кроме разве что выдачи адресной справки).
Ну вот сейчас это реализовывается путём скачивания java-приложения через internet. Какого рода уязвимости мы таким образом "победили"? В чём разница между
Использование конкретной версии софта, которой пользователь доверяет, в том числе по причине сертификации её государством. Традиционные веб-технологии не предполагают возможности контролируемого изменения версии используемого софта. Нет способа гарантирования того, что в данный момент исполняется именно та версия кода, которая прошла сертификацию, даже локально на браузере пользователя. А уж отправка приватного ключа на сервер для подписи им от лица пользователя вообще вообще сродни его публикации.
Вы сами в это верите? Вот если бы я грузил исходный код из репозитория (причём без всяких blob-ов) через TLS, и собирал это "руками". Тогда можно было бы заикаться про какую-то конкретную версию софта, которой пользователь "доверяет". На деле я гружу чёрный ящик, который ещё и сам обновляется, да ещё и по незащищённому каналу.
А уж отправка приватного ключа на сервер для подписи им от лица пользователя вообще вообще сродни его публикации.
Вы уже второй раз об этом пишете. Но я об этом и не заикался. Зачем?
Вдобавок — оно ещё и не работает из коробки. Нужно всем браузерам прописывать дополнительные удостоверяющие центры сертификации "Большого брата". За это отдельный "respect" государству :)
А это опять потенциальная дыра — NPAPI, Flash, java applet потому и выпилили из браузеров, что давали доступ к ресурсам ОС через браузер.Нет. Их выпилили потому, что они давали возможность доступа к ресурсам ОС без явного уведомления пользователя. А если это происходит по инициативе пользователя — проблем нет, Native Messaging же есть.
Не видел ни одного канонически правильного решения, которое успешно работает с аудиторий от нескольких миллионов обычных людей.А искали? Вот, например.
А я спрашивал про проекты с миллионной аудиторией, которые бы в один прекрасный день сказали, так, ребята, пользователи, в течении года переходим на использование устройства Х. Кто не перешел, мы не виноваты. Воспользоваться нашими услугами не сможете.
При этом, использование устройства Х было бы реализовано канонически верно, без компромиссов.
Кто не перешел, мы не виноваты. Воспользоваться нашими услугами не сможете.А. Это пожалуйста. Или вы хотите совсем принудительно. Как «онлай-кассы» в России. Ндравится?
Всё-таки мне кажется, что с дополнительной стадией, когда какое-то время у вас есть выбор — оно… человечнее.
1. Создаются отдельные приложения для смартфонов, единственной функцией которых будет подписывание. Ключи пользователя будут хранится только на его смартфоне.
2. Далее все заинтересованные сайты-сервисы именно на этапе подписывания генерируют какой-нибудь qr-код с хэшем документа.
3. Пользователь сканирует этот код через свое приложение и подписывает.
4. Далее приложение на смартфоне передает сервису-источнику публичный ключ с подписью для проверки.
Для конечного пользователя здесь похожий принцип, по которому пользователь открывает ватсап на своем десктопе.
На мой взгляд, это будет и удобно, и с точки зрения безопасности все нормально должно быть.
Также и дорабатывать много чего не надо, так как уже похожие приложения тот же egov выпускает кажется.
Но и с ними свои сложности. Без интернета не подпишешь, как безопасно хранить приватный ключ (разработчики мобильных ОСей предоставляют специальный API, но большинство соглашается, это не гарантирует неразглашения). В общем использование мобилок привносит свои компромиссы.
Насчет хранения ключей, конечно до аппаратных токенов будет далеко, но получше будет чем сейчас, когда на флэшке всё. Да и пароль самого ключа никто не отменял.
Насчет хранения ключей, конечно до аппаратных токенов будет далекоА почему далеко? Почему, блин, GitHub может, а Казахстан — не может? В чём разница?
Для Github'а — этого достаточно. Для подписи документов нужно будет что-то другое сделать. Но для этого нужно делать, а не плакать, что технологии экспериментальные. Конечно экспериментальные — кто ж их неэксперементальными должен сделать? Марсиане?
Не можете договориться с Оперой или Гуглом? Обратитесь в Yandex, пусть они в свой браузер вкрутят, все остальные встанут перед фактом: или госпредприятия в России и Казахстане все поголовно переходят на Yandex-браузер, либо Гугл берёт патчи от Yandex'а и Chrome — тоже начинает поддерживаться.
А под лежачий камень вода не течёт… шевелиться надо.
- Как пользователь убедится, что qr-код соответствует тому, что он собирается подписать, а не договор дарения квартиры это?
1. Можно идти в сторону унификации формата документов: например, использовать markdown или другой похожий несложный формат. В таком случае во время подписи, он будет загружать текст документа на смартфон, там уже можно сверять хэши. В случае с бинарными данными даже не знаю как будет лучше.
2. Также можно работать на сертификацией самих онлайн-сервисов, т.е. не принимать документы от кого попало.
1) «с ЭЦП ничего не сделаешь». Мантра разработчиков. С самой ЭЦП ничего, но в составе других преступных деяний, ЭЦП очень даже поможет реализовать замысел. Получить подробности недвижимости которой вы владеете например,… «информация правит миром». Или жениться/развестись без ведома второй стороны. Да, выше правильно указано — заявление подали, а дальше в ЗАГС идти надо. Но в ЗАГСЕ вам бумажки отдадут не поднимая головы. Они же уверены — человек ЭЦП подписал — нафига его с личностью сверять?
А уж произвольному гражданину временную прописку организовать по случайному адресу — это прям вообще легко.
Дело осложняется еще больше, если у гражданина есть собственность в виде компании…
2) хотелось бы услышать такой же анализ про налоговый КНП плагин. Подозреваю, что это какой-то вариант NCLayer. По-крайней мере вместе в одном компе они не живут. Думаю дерутся за общий порт сокета. Но нафига нужно было отдельную софтину городить? Вот вопрос. А что со Статистическим Управлением? Нафига они на странице входа требуют не подпись для аутентификации? Это «стиль такой»?
3) умиляет разделение на «государственные и частные» сайты. Как будто тот факт, что вы зашли на государственный сайт вас от чего-то защищает. Наоборот. Именно из государственных недров достаются всякие «базы ГАИ» и прочие вещи, продающиеся на базарах. Именно против государственных органов бессмысленно подавать иски, хотя частные компании сравнительно легко разорить до копейки, если они «жульничали» или «халявили безопасность». База «путей и паролей» полагаю могла бы стать реальным объектом заработка несчастных админов из страны с минимальной заработной платой в USD 70.
Эта же цифра стоит у меня перед глазами, когда я представляю «государственные органы» в виде заказчиков какого-либо решения с ЭЦП. Сначала «надо чтобы выглядело дорого-богато»: отдельная инфраструктура, бюджет на аппаратное решение, напишем собственный вариант NCLayer. А потом: «а можете вот эту ваши смету поделить на 4. А то дорого очень...». «Конечно можем — но безопасность будет никакая»… Никакой конкретной информацией не владею. Но виртуальный диалог выглядит очень правдоподобно.
4) Можно ли создать общие рекомендации для пользователей ключей на текущий момент?
Что-то в духе меняйте пути к ключам после каждого использования на подозрительных государственных сайтах? Меняйте пароли по понедельникам? Перевыпускайте ключи раз в месяц? Что-нибудь из перечисленного имеет смысл?
По второму вопросу — это решение называется CryptoSocket от Гамма Технологии. В ближайшее время также постараюсь его рассмотреть. Предварительно скажу, если оно запрашивает пароль всего один раз и то через формочки на сайте. То там такая же ситуация. К сожалению моментально посмотреть не смогу, так как пользуюсь ОС Linux под которую нет версий CryptoSocket.
http://gamma.kz/product/21
По четвертому вопросу — все предложенные механизмы для параноиков. А если честно, даже предложенные механизмы не защитят Вас от атак, которые предложены в статье.
Атака в статье, позволяет даже эксплуатировать уязвимость при использовании казтокена. Да, если вы вытащите казтокен когда не работаете, это позволит в то время не пользоваться от вашего имени ключами. Но в промежутках между использованием ЭЦП, такая атака все равно возможна.
И это не помогает от подмены информации перед подписью.
Справедливости ради, этим страдает большинство реализаций. Т.к. решения этих недостатков — не юзерфрендли.
4) В целом, рекомендация часто менять ключи/пароли минимизирует риски "отложенных" атак типа "мы знаем, что есть инфраструктура, постоянно хранящая эти данные, и наконец-то смогли получить доступ к ним", но не защищает от "реал-тайм" атак типа "мы знаем, что есть инфраструктура, периодически имеющая доступ к этим данным, и наконец-то смогли внедриться в неё".
По второму вопросу — это решение называется CryptoSocket от Гамма Технологии. В ближайшее время также постараюсь его рассмотреть. Предварительно скажу, если оно запрашивает пароль всего один раз и то через формочки на сайте. То там такая же ситуация. К сожалению моментально посмотреть не смогу, так как пользуюсь ОС Linux под которую нет версий CryptoSocket.
http://gamma.kz/product/21
Здесь я ошибаюсь, здесь используется какое-то другое решения для КНП.
Вероятно и причина ссоры с Гаммой была в том, что «кроссплатформенное решение» не хотело без бубна переносится даже между Windows 8 и Windows 8.1. И у меня были подозрения, что это неспроста. Впрочем — это все догадки неспециалиста.
Вероятно и причина ссоры с Гаммой была в том, что «кроссплатформенное решение» не хотело без бубна переносится даже между Windows 8 и Windows 8.1. И у меня были подозрения, что это неспроста. Впрочем — это все догадки неспециалиста.Догадки, близкие к истине, тем не менее.
Я это много лет назад наблюдал в американской конторе. Которой тоже захотелось кроссплатформенности и они заказали на оутсорс решение на Java «для кросс-платформенности». Беда в том, что это было во времена, когда у Microsoft ещё была своя Java, а MS IE занимал 90% рынка браузеров — ну и решение в решение в результате только под MS IE и работало… потому что там от java был только запускач, который загружал нативную DLL'ку.
Всплыло это через несколько лет, когда нас попросили починить их кросс-«платформенное» приложение, которое «почему-то» не хотело работать на маках.
В общем это было событием, которое на многое открыло мне глаза. Потому что руководители той компании на полном серьёзе показывали рекламу (из журнала), где Java рекламировалась как способ написания программ, работающих на Windows, SunOS и MacOS! Представить себе, что, тем не менее, на Java можно написать приложение, которое только на Windows в MS IE будет работать и, более того, в то время, когда они его заказали — других вариантов ещё не было… это было открытием для меня, а моё удивление — открытием для них: они что — всерьёз должны были предполагать, что так может быть? Что проспект говорит одно, другой — другое, третий — третье, а вместе — оно не работает?
Потом уже я понял — что всё это следствие пресловутого эффекта Айберга. Кнопочки выглядят одинаково — значит это одни и те же кнопочки! И как в той статье: Это не секрет. Секрет в том, что люди, которые не являются программистами, не понимают этого.
Они не понимают, что китайский смартфон за $100 содержит больше программных компонент, чем какой-нибудь Boeing 747 1969го года выпуска! Что количество проблем, которые могут возникнуть на стыках — сотни, а то и тысячи. Им кажется, что разьём для звука — это всего лишь три провода, по которым идёт звук… идеи о том, что туда же может идти что-то ещё — они просто не укладываются у них в голове.
Это одновременно смешно и грустно. Смешно, потому что показывает насколько наивными могут быть люди, когда дело касается современной техники… грустно, потому что, ещё раз — это не просто люди, это руководители! Предприятий, государств, неважно! Они делают выбор на основании не фактов, а каких-то отрывков фактов… ну и насколько он может быть осмысленным, этот выбор?
1) атака возможна только если ключ вставлен в компьютер в этот момент?
у меня ключ на удостоверении. Получал безопасно. Никогда не оставляю кардридер вставленным в компьютер. Сами ключи можно забрать с удостоверения через NCLayer? Если нет, это сильно снижает вероятность атаки.
2) если я правильно понимаю, атака не оставляет записи в логах о полученной услуге? Или…? То есть, смогу ли я в суде оспорить эту подпись, ссылаясь на то, что по получению этой «услуги» нет записи в логе? (я понимаю, что если это целый «сайт злоумышленник» то они все логи сделают как положено, но по крайней мере, я не могу посетить сторонний сайт, а в этот момент за меня подпишут что-то на egov, чтобы в логах егов значилась запись? или это тоже возможно?)
3) почему конфликтует КНП плагин и NCLayer? я думал, что на сервере используется примерно одинаковый протокол, и поэтому они «дерутся за порт». Но раз писала его совсем другая контора, они что, тоже для «собственного удобства» пароли и пути к ключам сливают? Понимаю, что это вопрос сложный, однако достаточно важный для пользователей. Рискну предположить, что в некоторой степени вопрос отношений с налоговой может быть даже более важным, чем для физических лиц. Там замешаны гораздо более большие деньги. Там есть коммерческие интересы, конкурренция, рейдерство и прочие вещи, где можно использовать кибератакаи, как составную часть более всеобъемлящего процесса.
4) ну и маленькое предположение. Раз это «полный аналог ручной подписи», кто-нибудь рассматривал вариант применения к потенциальным нарушителям, иска о подделке документов? Кажется это что-то там до 5 лет тюрьмы. Я понимаю, что ситуация виртуальная на текущий момент.
Всем большое спасибо за ответы. Надеюсь это поможет не только мне, но и другим пользователям.
- Атака возможна тогда, когда есть доступ к носителю, ну и зловредный ресурс запущен. Также известны пароль и путь к носителю. Все происходит незаметно для пользователя.
- Можно увидеть в логах, но все будет по правилам. Нельзя будет отличить от настоящего пользователя. Ну может быть только позже по ip, откуда поступали запросы.
- Не могу сказать, наверное "висят" на одном порту.
- Администритивная ответственность есть. По уголовному кодексу ничего сказать не могу.
по 2 вопросу еще раз, Вам точно придется доказывать что это не Вы произвели действие. Но я не вижу как это можно будет доказать. ЭЦП ведь ваша. В логах это будет выглядеть так, как будто вы зашли на егов и запросили все по правилам.
- Сама по себе реализация не кривая. Механизм как это предалагается использовать, не совершеннен. Потенциально уязвим.
- Не заходите на левые ресурсы. А вообще сейчас желательно используйте только на егове.
- Обновляйте NCALayer сразу же при выходе обновлений. Я жду чтобы они побыстрей выпустили обновление.
Прошу прощения за назойливость, но тема важная. Виртуальный сценарий: я- злоумышленник, создал сайт с аутентификацией по ЭЦП (например сайт страховой компании, продающий страховки на машины). Между делом пользуясь данными, подписываю какие -либо бумажки ЭЦП пользователя. Схему придумаю на ходу, чтобы интересно было: Предположим существует сайт ломбарда, назовем его WhiteLombard.kz. И суть того что я делаю — беру справку о недвижимости индивида на egov, предъявляю в WhiteLombard.kz, подписываю договор залога, подтверждаю обременение имущества на egov.
Что происходит, как я понимаю из текста выше:
1) через NCLayer получаем пути к ключам, а также пароль к ним.
2) в фоновом режиме, без диалогов, подписываем запрос на справку о недвижимости, на egov.
3) в фоновом режиме на WhiteLombard.kz заключаем договор залога, передаем недвижимость в залог и подтверждаем обременение на egov.
Еще раз, предположим весь функционал есть.
Вопросы:
1) Понимаю, что запрос справки на egov будет отражен в логах. Отличить его от настоящего будет невозможно.
2) Будет ли отражен в egov факт подписания чего либо на сайте «страховой компании» или «WhiteLombard.kz»? Или даже сам факт аутентификации? Кажется нет. Или?
Пожалуйста прокомментируйте мои догадки/предположения:
1.1) Раньше в NCLayer существовал какой-то режим отладки. Можно было создать какие-то файлы, которые как-то анализировать. Сейчас всего этого нет. Зато появились модули. Которые можно устанавливать… И больше ничего… Никаких настроек не видно. Может быть есть какие-то скрытые настройки? реестр? То есть — есть ли какой-то скрытый файлик протокола на стороне клиента где можно по-крайней мере обнаружить обращения и факты подписания чего либо? Ведь NCLayer не ВЫДАЕТ КЛЮЧ? Подписание происходит с его участием, и следовательно — может быть сохранено в логах. Локалных или удаленных.
2.1) Поможет ли разделение ключей? По умолчанию, оба ключа лежат в одном каталоге. А если разделить их? Положить ключ аутентификации в одно место, а секретный в другое? Ок, я аутентифицировался на «постороннем сайте», но подписать от моего имени запрос на egov — не удастся. Или…? Что в таком случае будет хранить/выдавать NCLayer? Место последнего использованного ключа?
3.1) КНП плагин и NCLayer больше не конфликтуют. Сегодня проверил. Тем более, раз у них теперь и порт разный, насколько вообще это разные миры? Мир «гражданский» и мир «налоговый»? :-) И насколько в «мире налоговом» нас ожидают теже проблемы? Этот вопрос пока не отвечен. А ведь в этой области кроется гораздо больше неприятностей для пользователей. Во-первых, по причине высокой концентрации ключей в одной машине. Там есть бухгалтерские фирмы, которые держат десятки и сотни ключей на одном компьютере. Во-вторых, область бизнеса потенциально более денежная — следовательно, магнит для злоумышленников. В-третьих, сфера бизнеса более регламентрованная. Вы не можете выбрать «заходить на этот левый сайт или нет» — вы обязаны.
Поэтому пожалуйста, если это возможно, прокомментируйте КНП плагин на предмет таких же «упрощений»…
4.1) теперь в NCLayer есть плагины/модули. Я сегодня видел там какие-то штуки, которые установлены/устарели-но-всеравно-установлены и которые можно установить. Что-то про министерство финансов например. Что это все? Имеем ли мы дело с зоопарком различных программ доступа и теперь безопасность каждого модуля надо обсуждать отдельно? Какое все это имеет оношение к инфраструктуре?
5.1) При всем при том, как существует управление статистики cabinet.stat.gov.kz которое модуля не имеет, и вообще никакой софт ему ставить отдельно не нужно (судя по инструкции), и аутентификацию оно хочет предоставить только при использовании ключа RSA? (https://cabinet.stat.gov.kz/OnlineReports/faces/instruction?_adf.ctrl-state=1afrzs3r6t_10&_afrLoop=5364477773078590). Зачем тогда весь этот зоопарк с NCLayer, его модулями, KNP Plugin? Ведь они говорили, что Java не поддерживается браузерами. А как тогда это работает у Статистиков? Они что RSA ключ на сторону сервера пересылают? Кстати — это тоже идея. так наверное «еще проше». (При этом их сертификат сайта, кажется не валидный. Вот где злоумышленники.)
А теперь о хорошем:
Бардак и хаос на рынке всегда рождает массу возможностей. В сложившейся ситуации я вижу не только возможность написать свой собственный NCLayer и продавать его за деньги, (и даже доагдываюсь кто его купит), но и сделать общедоступную платформу OAuth, которая обеспечит жителей Казахстана во-первых безопасным входом, когда все «левые сайты» смогут получить результаты аутентификации но не смогут манипулировать ключами, во-вторых, снизит входной порог для тех, кому нужно аутентифицировать человека, но не нужно слишком глубокого доступа к его «юридическим правоспособностям». Допустим теже Интернет-магазины получили бы более ответственных клиентов, если бы видели не обезличенного пользователя, а человека аутентифицированного государственным ЭЦП, хотя самого ЭЦП — не видели бы.
В общем, если кто-нибудь из присутствующих готов обсудить возможности бизнеса связанного с казахстанской ЭЦП, буду рад поучаствовать.
Ну и в конце концов — наверное есть патриоты. Или бужем ждать пока придут эстонцы и все поправят? А это уже обсуждается. (ничего плохого об эстонцах. Все кого знаю — грамотные специалисты. Просто в Казахстане, полагаю, тоже достаточно хороших специалистов)
Почему я не думаю, что оно «исправится само»? Власть в Казахстане разрозненна и децентрализована. Пример с ЭЦП — это пример удивительного продукта, когда у гибрида корни уже помидорные, а плоды уже вполне картофельные. То есть на текущий момент все преимущества решения — не работают, а все недостатки — работают на 100%.
Я не знаю когда прекратили отношения с Гаммой. Но и до этого не было единообразия в использовании ЭЦП. А сейчас — каждое министерство, ведомство, государственные и полугосударственные предприятия плодят «свои решения» на каждом шагу. Пользователи в афиге. Идея «один гражданин — одна ЭЦП» с самого начала была мертвая. Но теперь она обросла еще и безумным зоопарком, разобраться в котором нормальные люди не смогут. ЭЦП в целом начинает хромать на обе лапы. Даже если завтра утром все проблемы с NCLayer исчезнут, благодаря быстрой и слаженной работе программистов — проблемы никуда не исчезнут. Например перестанут работать «сторонние сайты» (кривой протокол поменялся же)… Может они и кривые, но какие-то полезные функции они несут же? Пока не очень верю в злоумышленников. Больше в разгильдяйство.
В Казахстане опасно использовать ЭЦП