В последнее время государство пытается максимально перенести все госуслуги в электронный формат. Активно выдаются адресные справки, и другие справки выдаются через Портал электронного правительства. Даже можно зарегистрировать брак пожениться через портал. На самом деле, очень удобно. Есть конечно же минусы, в основном — организационные, нормативные на уровне законов, на уровне реализации. Но это уже другой вопрос, главное очень хорошие начинания. Это все хорошо, но пост не про это.
Очевидно, чтобы пользоваться госуслугами, нужно как-то подтверждать свою личность. Для этого когда-то давно законодательно закрепили использование ЭЦП. Основная формулировка применения ЭЦП такая — ЭЦП приравнивается к собственноручной подписи. Многие не знают, но за передачу ключей ЭЦП (здесь и далее буду использовать термин — ключи ЭЦП. Все называют просто ЭЦП, а по факту это две пары ключей — для аутентификации и подписи). За передачу третьим лицам даже есть какая-то ответственность. Очевидно, что многим людям это без разницы, не понимают всей серьезности.
Вообще тема поста про NCALayer, прослойка между браузером и ключами ЭЦП. По безопасности — это уязвимый механизм использования ЭЦП.
Что такое NCALayer
Так как основная реализация криптопровайдера на Java и в последних версиях браузеров нет возможности использовать апплеты, то НУЦ придумал оригинальное решение для использования ЭЦП в браузерах. Это решение называется — NCALayer. NCALayer — посредник между браузером, криптопровайдером и ключами ЭЦП.
NCALayer устанавливается локально на компьютере пользователя. Работает NCALayer следующим образом — открывается вебсокет сервер на определенном порту, куда отправляется разного рода запросы.
Опуская все детали подключения, рассмотрим пока два запроса, чтобы иметь общее представление как NCALayer работает:
- Выбрать ключ на файловой системе.
{
'method': "browseKeyStore",
'args': ['PKCS12', 'P12', '/home/user']
}После отправки запроса, на машине где стоит NCALayer, открывается диалоговое окно, которое предлагает выбрать файл ключей ЭЦП.
Соответственно, после выбора ключа, через сокет получаем следующий ответ.
{"result":"/home/user/AUTH_RSA.p12","errorCode":"NONE"}
{"errorCode":"NONE"}Внимание: при использовании NCALayer, получаешь реальный путь к файлу на машине клиента.
- Если у вас есть путь к хранилищу ключей, то для последующей работы обязательно нужно предоставлять пароль от этого хранилища. Обычно сайт как-то забирает этот пароль через формочку. Вот пример, как подписать или поставить ЭЦП на какие-нибудь данные.
{
"method": "signXml",
"args": [
'PKCS12',
'/home/user/AUTH_RSA.p12',
'1874abcef234',
'ПАРОЛЬ!!!',
'<login><timeTicket>1517997213006</timeTicket></login>'
]
}Не буду публиковать ответ, но там содержится подписанная часть xml, которая была в запросе.
Повторюсь, получить пароль от хранилища ключей ЭЦП, ложится на плечи сайта. То есть, сайт всегда знает где лежат ключи и пароль у пользователя, иначе работать нельзя.
Минусы реализации текущего варианта NCALayer
- Здесь один большой минус — путь к файлу и паролю доступен любому разработчику сайта, где используется ЭЦП. Даже пользуясь всякими токенами, при использовании NCALayer, пароль от устройства-токена также передаются на сайт. По крайней мере, текущая реализация позволяет это сделать.
- Хранение путей к ключам и пароль каждый сайт может хранить у себя в базе. Может и не хранить. Вообще, хранить или же не хранить пути и пароли — опять же, все это лежит на совести разработчиков сайтов.
- Любой сайт может за вас подписывать данные без вашего ведома в фоновом режиме, если он знает про путь где хранятся ключи и пароль. Опять таки, Если вы хоть раз использовали ЭЦП на сайте, то сайт уже знает путь к файлу и паролю. Если сайт-злоумышленник, то он гарантированно сохранит пароль где-то у себя.
- Хочу заметить, что прямой доступ к носителю с ключами не предоставляется. Доступ ограничен только функциями NCALayer.
Реальный пример, как получить доступ к egov.kz, если ты не владеешь ЭЦП человека
Не буду углубляться глубоко в технические детали и реализацию. Опишу как можно это сделать.
Теперь, чтобы эту уязвимость эксплуатировать, нужно понимать как работаем механизм входа на egov.kz через ЭЦП. Для входа на egov.kz, xml от egov.kz подписывается пользователем и передается на сервер, где проверяется. Если подпись валидна, то осуществляется вход. Со стороны NCALayer, процесс входа состоит из следующих шагов:
Портал запрашивает следующие данные из NCALayer — loadSlotList (здесь можно ответить ошибкой), getKeys, getSubjectDN, getNotBefore, getNotAfter и signXml. Если NCALayer правильно подставит эти данные от другого пользователя, то соответственно мы удачно войдем в систему. Здесь очень важно правильно получить от NCALayer только subjectDN и xml для подписи.
Теперь как получить доступ к egov.kz от другого человека, механизм:
- У себя на компьютере, извлекаешь xml строку, которую нужно подписать чтобы войти на egov.kz. Это делается так, просто в консоли разработчика на idp.egov.kz, нужно запросить следующие данные —
document.getElementById('xmlToSign').value. - Отправляешь xml строку на подпись нужному человеку, который сидит на сайте-злоумышленнике. Он у себя на компьютере, в фоновом режиме подписывает нужную xml строку. Дополнительно получаешь subjectDN.
- Сейчас в наличии есть subjectDN и подписанный xml.
- Теперь самое интересное, у себя на компьютере эмулируешь работу NCALayer, который отдает необходимые данные.
Некоторые утверждения
- Пост не рассчитан на широкую аудиторию, больше на технарей, которые понимают принципы веб-разработки.
- Уязвимы ВСЕ ресурсы, которые используют NCALayer.
- Познания в криптографии не нужны.
- Для эксплуатации этой уязвимости не нужно получать SDK от НУЦ. Соответственно, НУЦ не в состоянии выявить сайты-злоумышленники.
- Разработчики NCALayer не могут дать гарантии, что злоумышленники не смогут использовать такой механизм. Это будет глупо отвечать за всех. Технически возможность есть.
- Уязвимы ключи не только на файловой системе, но также на токенах.
- Вы гарантированно засветили пароль от носителя ключей ЭЦП, даже от токенов. Достаточно войти всего один раз на egov.kz. Как используется пароль на сайте, это на совести разработчиков.
- Насколько я слышал, уже есть системы, которые хранят путь к ключам ЭЦП и пароль в настройках.
- На сайтах нет уязвимостей, просто схема использования ЭЦП через NCALayer небезопасна.
Update:
Что можно сделать
- Будет неудобно — но при каждом использовании ключей, запрашивать хотя бы пароль.
- Продвигать web crypto api
- ...
Эмулятор NCALayer
Приложение, которое без ведома пользователя, в фоновом режиме подписывает данные
Комментарии (133)
TrllServ
07.02.2018 16:00Вы слали уведомления об этой проблеме на egov.kz или иным уполномоченным?
Что-то ответили?maratkalibek Автор
07.02.2018 16:01Это не проблема egov.kz. Такой механизм реализовать сейчас считаю сомнительным, так как ЭЦП мало где внедрено и в основном госорганы. Если же начнут появлятся разные сайты с ЭЦП от компаний, тогда эта проблема становится актуальной.
Equinox
07.02.2018 16:32+2Не понимаю, зачем сделали передачу пароля на сайт?
По идее, криптопровайдер локально на компе пользователя должен запросить пароль от закрытой части ключа ЭЦП при попытке что-то подписать со стороны сайта, а не передавать ему (сайту) пароль в открытом виде…maratkalibek Автор
07.02.2018 16:39видать было удобней один раз запросить и позже все время подставлять программно.
Kolyuchkin
07.02.2018 16:42+4Требования информационной безопасности и «удобней» — понятия в большинстве случаев несовместимые.
Protos
08.02.2018 05:20А никто не думал что разрабы просто взяли и реализовали это без согласований?
questor
08.02.2018 13:01Эта сфера слишком зарегулирована, чтобы подозревать подобные вольности.
4680864
10.02.2018 12:53Сомнительно. Приходилось писать код для гос. структур (правда не криптографию). Очень расплывчатые у них тех. задания, и очень много приходилось «доделывать от себя» (без согласований).
Kolyuchkin
07.02.2018 16:39А проходило ли это «поделие» (NCALayer) сертификацию у регуляторов? Есть ли предписание на эксплуатацию в гос. органах?
maratkalibek Автор
07.02.2018 16:45+4Щекотливый вопрос. Контора которая изготавливала это "поделие", также проводит аттестацию информационных систем для использования в госорганах на соответствие информационной безопасности. Думаю вопрос снят.
inkvizitor68sl
07.02.2018 16:43А зачем вообще эту бурду придумали, почему не ключи в браузере?
maratkalibek Автор
07.02.2018 16:44основное требование для работы с ЭЦП — использование своего, сертифицированного криптопровайдера. Криптопровайдеры, которые использует браузер — не сертифицированные.
inkvizitor68sl
07.02.2018 16:46Сертифицированы они, небось, во времена повсеместного rsa…
Ясно-понятно.maratkalibek Автор
07.02.2018 16:47Нет, помимо RSA, также есть ГОСТ алгоритмы. Но только для юридических лиц. Для физлиц — RSA.
inkvizitor68sl
07.02.2018 16:48Ну я про физлиц и говорю.
То есть ЭЦП использовать небезопасно не только потому, что софт делает бредовые вещи, но и потому, что крипта в нём алгоритмически уязвима.dabar347
07.02.2018 20:15Хм, а когда RSA стал алгоритмически уязвим? (учитывая что размеры ключа нормальные)
inkvizitor68sl
07.02.2018 20:16Упс, да, с DSA перепутал. Что-то в голове 2 новости сложились в одну.
RSA только при ключе <=1024 уязвим.
vsb
09.02.2018 10:46У ключей в браузере, насколько я помню, нет никакого API для использования. Просто аутентифицируется HTTPS-сессия и всё. Вот придёт пользователь в суд и скажет, мол не подписывал я этот договор, предъявите мне доказательства того, что я подписывал. Сейчас ему предъявят XML-документ с его подписью, причём всё это согласно стандартам. А так — что ему предъявят? Записывать весь его шифрованный трафик? В общем ключи в браузере мягко говоря не очень удобны для данного применения. Был бы в браузерах нормальный API для этого дела, тогда хотя бы был бы шанс на такое (да и то учитывая то, что до сих пор используется нестандартные для запада криптоалгоритмы ГОСТ, реально шанса не было бы).
Хотя в целом после того, как Java-плагин перестал работать, во многих странах появилась похожая проблема и есть шансы того, что API в браузерах всё же появится.VolCh
09.02.2018 10:54Показывать логи запроса на "подпись" с данными его сертификатов. Практически по тем же стандартам. WebMoney применяет(ло?) такой способ лет 10 назад точно.
Dido_kz
07.02.2018 18:03Браузерные криптопровайдеры же тоже передают эцп на сайт, в нашем случае тем более сверка с сервером НУЦ необходима
Предлагайте варианты… смс авторизация опять не внушает оптимизмаmaratkalibek Автор
07.02.2018 18:14Казахстану инвестировать в развитие браузеров Chrome, Firefox, чтобы можно было нормальное ЭЦП внутри браузеров. Ну чтобы было правильно. Ну и еще криптопровайдер нормально прикрутить к браузерам.
webkumo
08.02.2018 13:47Я конечно скажу бред с точки зрения государственных ИБ Казахстана… но почему нельзя использовать поделие КриптоПро? Да там тоже не всё радужно (при разработке — не единожды умоешься кровью), но откровенных косяков хотя бы нет…
И мстится мне, что ГОСТ-алгоритмы шифрования были придуманы до разделения СССР, и, соответственно, взаимозаменяемы между РФ и Казахстаном...khim
08.02.2018 18:33ГОСТ — он, как бы, не один. Бывает ГОСТ 28147-89/ГОСТ Р 34.11-94, а бывает ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012. И ещё промежуточные.
В виде RFC, почему-то, есть только ГОСТ Р 34.11-2012.
По хорошему-то нужно просто их добавить в брайзеры и всё — но дальше возниктнут проблемы с сертификацией, так что пляски с бубнами неизбежны.
Но это в чистом виде потому, что кому-то нужна «шашечки», а не «ехать».
Juma
07.02.2018 18:44Есть некоторые ресурсы котороые используют сертификаты для входа или подписи. Можно использовать сертификаты выданные НУЦ РК, причем NSALayer не используется. Как используются сертификаты на этих сайтах? Получается, что и сертификат и пароль отправляются на сервер? Т.е. они будут доступны админам сайта?
Juma
07.02.2018 19:32Сейчас проверил один сайт. Вся работа с ключами просиходит в браузере с помощью библиотеки «forge» (извлекается публичный ключ, срок действия сертификата и прочая информация). Но все равно, получается что все зависит от честности разработчика сайта.
maratkalibek Автор
08.02.2018 08:42Да, все зависит от честности разработчиков сайта. Также, эту библиотеку не могут использовать на государственном уровне, так как она не сертифицирована. Хотя, насколько знаю, выдает валидные подписи.
chyngys_94
07.02.2018 19:01Думаю проблему можно решить через oAuth. Сторонние сайты запрашиват инфо, временные ключи или одноразовые токены через сам eGov.kz. Сейчас когда ЭЦП пользуются только госорганы все более менее нормально, а когда подключатся частные компаний к сети, то возможность того что ЭЦП "своруют" увеличивается.
maratkalibek Автор
07.02.2018 19:02а как подписывать документы? здесь без разницы, достаточно один раз засветить свои ключи на сайте.
chyngys_94
07.02.2018 19:14Подписывать токенами которые дает eGov (можно потом этот токен проявить как QR код). Потом egov где то себя сохранять этот токен и рядом записывает заметку, и через этот QR или токен в виде строки можно проверить подлинность запросив у egov. Возникает только одна проблема, со временем egov должен генерить очень оооочень длинные токены, либо задавать подписанным документам срок годности. Слышал что Казпочта хочет сделать электронную почту, письма которых может иметь законную силу, их тоже таким образом можно подписывать и задать какой то срок жизни достоверности.
just_i
08.02.2018 08:59Если не менять алгоритм работы с NCALayer, то oAuth в данном случае можно использовать так:
— Используя oAuth можно авторизвать юзера и получить токен для работы с апи egov от его имени, при этом вход через текущий механизм произойдет только на стороне egov
— Используя полученный токен, дергаем апи egov'a, куда посылаем файл для подписи, в ответ получаем ссылку куда должен пойти юзер
— Редиректим юзера на эту ссылку (ссылка на домен егова ведет), он видит файл для подписи, использует эцп для подписи, после успеха/неаудачи возвращаем юзера на сайт
— Делаем опять апи вызов к егову, проверяем что файл подписан, забираем его себе
Из плюсов в этой схеме, все манипуляции с ЭЦП происходят на стороне egov, стороннему сайту нужно использовать только всем известный oAuth и реализовать три не сложных апи вызова к egov
Из минусов, проблема с NCALayer остается, но по крайней мере она будет существовать только в пределах самого egov, которому придется доверять
chyngys_94
07.02.2018 19:21И есть еще одна проблема, у 80% с кем я сталкивался в ЦОНах ЭЦП имеет стандартный пароль 123456. И карту памяти на которым записан ихние ключи доверяют кому попало.
seytzhan
07.02.2018 20:58А web crypto api разве уже имеет поддержку в браузерах?
maratkalibek Автор
07.02.2018 20:59Судя по https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API, только в Chrome и Opera.
seytzhan
07.02.2018 21:06По этой ссылке судя по описанию «This is an experimental technology», инвестировать в развитие браузеров слишком «долгосрочно» получается. Сейчас же в тренде «быстрые победы» :)
TOLK
07.02.2018 23:16+1Мои пять копеек:
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$.Kolyuchkin
08.02.2018 00:57По п.9: проще говоря, ЭП — это зашифрованный на ключе ЭП (в простонародии, секретный ключ) ХЭШ данных. Так что наличие у Вас п.9 меня смутило.
TOLK
08.02.2018 06:10Я наверное не совсем ясно написал. Имелся в виду файл который находится на сервере. Не передается клиенту, немало, ребят передают на сторону клиента, хеш файла. И подписывают именно этот хеш, инода даже md5. В итоге подписывается «хеш-хеша» )
vsb
09.02.2018 11:06Ну в этом проблем нет (если не 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. Почему государственный софт обязательно должен быть таким уродливый?
faiwer
09.02.2018 16:29+1- В чём профит? Сейчас там хотя бы WSS, а не WS. А вы предлагаете по HTTP. Не совсем понятно что/зачем. 127.0.0.1 там и так.
- У них так исторически сложилось. ЕМНИП, ещё пока applet был на java работало всё также. Отдали всё на откуп программистам, сняв с себя ответственность. Удобно, чо :)
- Ну к чёрту. Серьёзно. Сейчас это хоть как-то работает, причём везде. А займутся C#, Objective C, GTK — мы получим зоопарк полурабочих решений. Если они даже tray-icon-у нормальную сделать за пару лет не осилили (в linux mint это какой-то аномальный прямоугольник с иконкой в углу, ещё и не с прозрачным фоном)… Боюсь что занявшись рюшечками linux вообще пропадёт из доступных решений.
vsb
09.02.2018 16:39+11. Никакой безопасности https при соединении с локалхостом не даёт, думаю, это очевидно. Зачем- браузеру нужен валидный сертификат, чтобы wss работал. Сейчас у них в приложении поставляется ключ и подписанный НУЦем сертификат на 127.0.0.1. Я не могу сформулировать, чем это плохо, но тот факт, что публичные УЦ запрещают такое делать (и отзывали сертификаты тех, кто так делал, например HP) говорит о том, что так лучше не делать.
2. Это работало неправильно и когда applet на Java был. Надо же делать правильно когда-нибудь.
4. Ну это ваше желание. Я линуксом не пользуюсь для подписи, в любом случае тот же KNPPlugin под линуксом не работает, например. Я бы предпочёл компактный и приятный софт, заточенный под платформу. Впрочем это так, мечты вслух. Не люблю я кроссплатформенный софт за редкими исключениями.
VolCh
09.02.2018 17:15Я не могу сформулировать, чем это плохо
Как минимум, это формальная попытка ввести пользователя в заблуждение. Заходит он на 127.0.0.1, видит сертификат, читает в нём, что сертификат выдан одной организацией, которой он доверяет, другой организации, которой он тоже доверяет. Начинает пользоваться, не подозревая, что ни одна, ни другая организация адрес 127.0.0.1 не контролируют. Контролирует его он сам, его админы, или хакеры, которые локально вырезали сертификат и прицепили его к своему сервису.
khim
08.02.2018 04:599. Из-за проблем со скоростью подписывался и до сих пор некоторые подписывают хеш большого файла а не сам файл.
Не некоторые, а все. Потому что подписывать напрямую RSA файл в мегабайт — вам нужна будет не одна чашка кофе.
Если используется достаточно надёжных хеш (тот же SHA-3 сегодня), то это достаточно надёжно и быстро.TOLK
08.02.2018 06:13Ответил выше, имелось в виду, подписание хеша(на усмотрение разработчика) подготовленного сторонним-несетифицированным ПО.
Methos
08.02.2018 00:13-1пожениться — пишется через мягкий знак
Demon_i
08.02.2018 02:08-1Предложение начинается с заглавной и заканчивается точкой. А вообще в личку такое принято писать.
Methos
09.02.2018 20:54-1пока будут бездарно писать с ошибками, буду писать прямо в комментариях
Demon_i
09.02.2018 23:47Вас не смущает, что автор из Казахстана и русский для него не родной язык? Вы бы стали читать этот пост на казахском? Пусть уж с ошибками, но лучше так, чем никак.
Пы.Сы. Тут, кстати, принято минусовать не понравившийся комментарий, а не сливать карму.
postgree
08.02.2018 03:081. И самое главное. Те, кто работал с генерацией эцп в РК давно об этом знали. Причина для работы по такому принципу не существенная, но была — чуваки реализовали так же, как было реализовано у них в апплете, когда НУЦ разосрался с гаммой.
2.Уязвимы ВСЕ ресурсы, которые используют NCALayer.
Опрометчивое заявление. Сейчас есть возможность в NCALayer добавить свой подключаемый модуль. Использовать короткоживущие токены. Ну и т.д. и т.п. Т.е. вероятность проведения успешной атаки будет в несколько процентов. Как инструмент для коммерческих махинаций не подойдёт.
3.Насколько я слышал, уже есть системы, которые хранят путь к ключам ЭЦП и пароль в настройках.
Хотелось бы узнать примеры…
4.Продвигать web crypto api
Эм, каким образом? Неужели вы думаете, что даже совместными усилиями в рамках Таможенного Союза участники смогут производителей браузеров добавить различные алгоритмы генерации, которые у них прописаны в законах.
Я отлично понимаю, что у некоторых бомбит по этому поводу. Для параноиков, имеющих навыки программирования посоветую просто реализовать свою прилажуху, которая будет эмулировать NCALayer. Работы не так уж и много. Можно кучкануться и замутить открытый проект. Ну а в НУЦ, конечно, относятся к таким вещам весьма расслаблено. Знаю на собственном опыте.khim
08.02.2018 05:05Неужели вы думаете, что даже совместными усилиями в рамках Таможенного Союза участники смогут производителей браузеров добавить различные алгоритмы генерации, которые у них прописаны в законах.
Разработчики браузеров что — ангелы, живущие на небе? Попробуйте предложить patch'и и посмотрите на реакцию. Если сошлётесь на требования закона — с вероятностью 90% будут вопросы только к технической реализации. Но вот тут — да, поблажек не будет. Дикие идеи типа «удобней один раз запросить и позже все время подставлять программно» будут посланы лесом.
maratkalibek Автор
08.02.2018 08:47По вопросу 3 — не утверждаю, но насколько слышал, Документолог хранит пароли у себя в базе. Используется в НИТ, Самруке, Зерде. Еще знаю одну АОшку, где Документолог у них облачный, т.е. не на площадке АО, а где-то на площадке самого Документолога. Скорей всего, доступа к этим данным, на совести админов и разработчиков уже Документолога.
postgree
08.02.2018 10:34Документолог, на сколько я знаю, вообще не имеет права заниматься разработкой таких вещей. Да и не проходили они никакой аттестации и т.п.
seytzhan
08.02.2018 07:50Что можно сделать
А как же 3-й вариант: разработать кастомный Государственный Браузер со встроенной заменой NCALayer?maxpy
08.02.2018 08:13Уверен, в таком случае появится другие статьи, где будут писать о недовольных пользователей этим браузером, то что браузер не безопасен, и что они вообще хотят право выбора.
TJey
08.02.2018 08:04Вот такой вариант тоже есть:
вырезка из этого форума
если этот JS библиотека будет отдаваться с pki.gov.kz
и даже сам процесс считывания подписи с браузера только со страницы pki.gov.kz, аля sso.gov.kz сделать бы…
я вижу это так
1) есть сайт который использует функционал ЭЦП авторизация/подпись, пользователь нажимает НАЧАТЬ ПОДПИСЬ
2) его перекидывает на страницу подконтрольную НУЦу типа sso.gov.kz, там включен js скрипт который может считывать и подписывать, клиент подписывает файловым сертификатом ну или оттуда же ему предлагается что то типа NCALayer'а для хардвейрных ЭЦП
3) после успешной подписи его перекидывает на изначальную страницу
Такой же процесс используется в интернет оплатах — epay.kkb.kzmaratkalibek Автор
08.02.2018 08:05Добавлю, чтобы было надежно, это ресурс полностью выложить в opensource и устанавливать через какой-то static site gen. Для повышения доверия.
malishich
08.02.2018 08:15Тоже смотрел механизмы работы наших NCALayer. У меня касательно организации нашего egov напрашивается один вывод — очень небезопасно. По моему, ошибка в том, что нельзя было выпускать даже публичные ключи из рук госорганов. Всё подписывание должно быть на pki.gov.kz, все сайты работающие с ЭЦП должны обращаться не к локальному NCALayer, а к pki.gov.kz. А pki.gov.kz должен сертифицировать сайты на работу с ЭЦП, сайты должны быть в его списках. А вот аутентификация физ/юр лица на pki.gov должна быть многофакторной — скажем пароль + одноразовый код по СМС (номер телефона зарегистрирован на pki.gov.kz) + одноразовый код по электронной почте. То есть — вам надо с 3-х мест правильно ответить. И пусть в течение скажем 3 минут. Потом по новой авторизация.
seytzhan
08.02.2018 08:25Насколько я понимаю, здесь узкое место в самом процессе подписывания, так как средства джаваскрипта браузера не позволяют ему работать с ключами (rsa, gost). И в любом случае нужен аналог NCALayer.
А вот возможности многофакторной авторизации на доверенном сайте действительно были бы весьма кстати.malishich
08.02.2018 08:42По моему мнению, пользователь (физ/юр) не должен иметь доступа к средствам подписывания и даже к открытым ключам. Вся работа должна делаться на закрытом госсайте, который по своим каналам авторизует пользователя, и по своим каналам принимает документы, и возвращает подписанные рабочему сайту. Пользователь только авторизуется и отправляет заявки на госуслуги, и получает подписанные «государством» доки. На компьютере пользователя не должно быть ничего компроментирующего, через его компьютер не должно проходить ничего, кроме его документов. Еще меня убивает поведение народа и «помощников» при выдаче ЭЦП в ЦОНах — эти пары ключей просто в открытую на свободных компьютерах лежат. Пароли ставятся как попало. Копируй что хочешь на флешку и пользуйся чужой личность и его мат ценностями.
seytzhan
08.02.2018 09:35Насчет поведения тоже согласен: смысл криптографической защиты обесценивается за счет безответственного отношения к своим и чужим ключам.
Но думаю это до первого прецедента. Например, пока кто-то таким образом «законно» не переоформит на себя чужую собственность. Напрямую это вроде как пока сделать нельзя, но можно к примеру женить кого-то на себе, а потом при разводе вымогать деньги :)
faiwer
08.02.2018 08:52так как средства джаваскрипта браузера не позволяют ему работать с ключами (rsa, gost)
А в чём это заключается? Не совсем понимаю, как такое может быть. Вы имеете ввиду, что нет готовой реализации? Я всё время думал, что NCALayer используется из-за:
- Лени писать нормальное решение, когда есть старый Java-криптопровайдер и можно взять потроха от него.
- Проблемы поддержки различных USB-устройств с токенами на стороне браузера через JavaScript. В эту сторону не копал, возможно тут и правда всё грустно.
seytzhan
08.02.2018 09:30Да, я имел в виду что нет готовой реализации. Есть Web Crypto API, но у них написано что это «экспериментальная технология».
khim
08.02.2018 12:53И что теперь? Думаете это обозначает, что её поддерживать не будут, а NPAPI и Java — будут?
Ну-ну.
ggo
08.02.2018 09:55Как из браузера общаться с внешним устройством (да, обычно это USB)?
Приватный ключ лежит на пластике с чипом.
Раньше был NPAPI. Потом его выпилили. Начали пилить Web Crypto. Но и с ним есть проблема. Ниже опишу какая.faiwer
08.02.2018 10:21Много ли народу имеет это внешнее USB устройство? Больше 1%? Мне кажется ради них можно было бы и какой-нибудь плагин в Chrome написать (каких там только сейчас нет...). А для остальных всё реализовать средствами JS или WASM.
ggo
08.02.2018 10:57Я там ниже комментировал.
Все крутится вокруг того, что если хочется честную безопасность, то приватный ключ должен быть на отдельном устройстве, и никогда его не покидать. Все остальное это компромиссы, вплоть до того, а давайте создадим «простую электронную подпись», которая к криптографии никакого отношения не имеет.faiwer
08.02.2018 11:10Ясно. Т.е. сыр-бор в том, чтобы в JS окружение не попало содержимое файла, и его обрабатывало что-то предустановленное, а следовательно "надёжное"? Это я могу понять, хотя на мой взгляд, толку с этого примерно нисколько. Тот же HTTPS подделать вроде нельзя, т.е. надёжная технология, и какая разница между:
- доверить содержимое файла JS-коду с pki.gov.kz через https
- доверить содержимое файлу какой-то софтине скачанной опять же с pki.gov.kz через тот же TLS (wss)
не ясно.
VolCh
08.02.2018 14:55В случае предустановленного ПО закрытый ключ не покидает (если верить производителю и органу сертификации) локального компа. В вашем случае, как я понял, он туда даже не попадает, что полностью убивает смысл ЭЦП.
faiwer
08.02.2018 15:20Вы вероятно меня не поняли. А я вас. Сейчас у нас (у казахстанцев) запущено на фоне java-приложение. С ключами работает оно. В случае если этот же код (но уже JS) будет отрабатывать не в Java, а в браузерной вкладке, ключи не начнут куда-то ходить. Все операции также будут выполняться локально. Только теперь в JS VM, а не в Java VM. Они всё также останутся на вашей стороне. По сети пойдёт лишь результат.
А код Java-приложения, так же как и потенциальное JS решение, вы всё равно из одного источника берёте.
ggo
08.02.2018 09:50Фундаментально неверно.
Криптография так не работает.
Это все равно что сказать, а давайте всех нотариусов закроем, и откроем одного, и когда нужно будет выпустить доверенность, пусть граждане по почте шлют свои заявки, а тот нотариус обрабатывает заявки и в ответ высылает по почте готовые доверенности. Оптимизация деятельности налицо.
Подписание должно быть на доверенном устройстве (нотариус должен быть вам очно доступен).
Приватный ключ из доверенного устройства не должен уходить (ваша подпись должна ставиться на довереность только при очном присутствии нотариуса).
Если не хотите, чтобы кто-то вместо вас подписывал электронные документы (выпускал от вашего имени доверенности), эти два требования нужно соблюдать.
capslocky
08.02.2018 08:20А я хочу попросить НУЦ включить https на своем сайте. Его отсутствие режет глаза, тем более с него скачивается тот самый NCALayer. Причем он устанавливает в систему корневые сертификаты НУЦ РК (GOST + RSA). Кому интересно вот инструкция по установке. Только прошу использовать глобально доверенный CA в отличие от https://egov.kz/cms/ru, чей TLS подписан тем самым корневым RSA c вашего http сайта.
askar13
08.02.2018 08:22Некоторые ресурсы вообще не используют NCALayer, как обстоят дела с безопасностью в этом случае? например podpishi.kz
Получается они через javascript сертификат загружают в браузер?maratkalibek Автор
08.02.2018 09:03Насколько я понял, они загружают файл к себе на страничку (но не на сервер) и там уже работают.
Но ничего не мешает им выборочно тайно передавать ключ к себе на сервер. Плюс пароль известен. Опять на совести разработчиков.
И потом, это мне кажется намного небезопасней чем использовать NCALayer. Так как NCALayer хотя бы не дает доступ к файлу с ключами.
capslocky
08.02.2018 09:46Наложить RSA подпись можно в браузере через Web Crypto API.
vsb
08.02.2018 16:07+2Если мы работаем с файлами, тут вообще ничего сложного нет. Файл можно открыть JavaScript-ом, распарсить ключ, взять реализацию RSA на JS и ей подписать что надо. Web Crypto API тут никаким боком не нужен. Проблемы начинаются, когда надо работать с USB-криптоключами.
baiterek
08.02.2018 09:45А есть ли на егове услуги, ради которых можно украсть чужой эцп?
П.С. Пожениться на егове нельзя, а только лишь подать заявку, а потом уже ножками идёшь в ЗАГС.maratkalibek Автор
08.02.2018 09:47Дело не только в егове. Проблема везде где используется NCALayer. Но чтобы эксплуатировать эту уязвимость, нужно чтобы были выполнены заранее определенные условия.
bars_arseniy
09.02.2018 12:29Можно получить информацию о человеке.
Какая собественность у него есть, какие штрафы, налоги платит. Через судебный кабинет можно получить доступ к документам по судебным делам. Уже не мало.
ggo
08.02.2018 10:12Главная проблема подписания (где угодно, хоть в браузере) — отделить собственно подписание от всего остального. Подписание должно выполняться на доверенном устройстве, в отдельном процессе (threads в ит терминах). Все манипуляции с приватным ключом должны выполняться в этом отдельном процессе, в том числе ввод пина для приватного ключа.
И вот тут главная проблема, пользовательский опыт. Люди открывая сайт, ожидают взаимодействия с этим сайтом, а не отдельным приложением. Собственно поэтому компромиссы: ввод пути до приватного файла из браузера, ввод пина из браузера, и т.д… Если сделать все канонически правильно, то таким решением смогут воспользоваться меньшее количество людей. Не видел ни одного канонически правильного решения, которое успешно работает с аудиторий от нескольких миллионов обычных людей. Приходится выбирать либо аудитория, либо каноны безопасности.faiwer
08.02.2018 10:27Если сделать все канонически правильно, то таким решением смогут воспользоваться меньшее количество людей.
А что подразумевается под канонически правильным решением? Мне вот видится простое решение:
- Встраиваемый через HTTPS Iframe (ну или напрямую) через
https://pki.gov.kzили другую гос. площадку - Загрузка файла традиционным образом в этот
<iframe/>через<input type="file"/> - Вся криптография средствами frontend JS (даже без
webcrypto)
Какие недостатки? С точки зрения пользователя (без USB устройств) всё стало только проще.
VolCh
08.02.2018 15:17Канонически правильное решение предполагает, как минимум, что приватный ключ доступен исключительно пользователю и коду, которому он доверяет. Веб-технологии не предполагают доверия коду, он изменяется без уведомления пользователя.
faiwer
08.02.2018 15:25и коду, которому он доверяет
А где взять такой код? Что нужно сделать, чтобы к нему появилось доверие?
Веб-технологии не предполагают доверия коду, он изменяется без уведомления пользователя.
Сейчас всё точно так же. Нам выдаётся чёрный ящик. Выдаётся через те самые "веб-технологии". Нет не на флешке в гос. учреждении, а качаешь по сети. Плюс оно обновляется периодически. И нет, исходников, я нигде не встречал (впрочем это же Java, можно развернуть байт-код во что-то худо бедно читаемое).
Замечу, что это java-приложение качается по HTTP (не HTTPS). Я сейчас проверил — HTTPS редиректит на HTTP.
Вот если бы за этим ПО ещё и ногами с флешкой топать в гос.дома нужно было бы, тогда я бы понял, что какая-то разница всё таки есть. А так...
VolCh
08.02.2018 16:16И никакой сертификации нет? Типа ФСБ/ФСТЭК в России?
faiwer
08.02.2018 16:28Понятия не имею. Вот страница загрузки NCLayer-а. Принудительный HTTP. Внутри архива баш-скрипт.
- Встраиваемый через HTTPS Iframe (ну или напрямую) через
seytzhan
08.02.2018 10:34Четкое отделение собственно подписания от всего остального порождает другое, на мой взгляд лаконичное, решение, которое уже привязывается к смартфонам.
Подробнее описал ниже.
faiwer
08.02.2018 10:38Подписание должно выполняться… в отдельном процессе
Должно кому? Прямо в ТЗ такая строчка? С чьей точки зрения это требование настолько критично, что теперь нужно ставить отдельную левую софтину на свой ПК, ставить к ней JAVA, предварительно запускать и ещё сертификаты от гос-ва принудительно в браузеры подсовывать (в противном случае лезут wss ошибки).
в отдельном процессе (threads в ит терминах).
Так в отдельном потоке (thread) или процессе (process)? Если хватает потока — ну подпишите его в webworker-е. Если процессе — то да, браузер так вывернуться не даст.
ggo
08.02.2018 11:20в линуксе особой разницы между thread и process нет. но, да, в других ос thread/process серьезно различают.
для них разные process. в идеале браузер не должен ничего знать ни про приватный ключ, ни про пин, ни про алгоритмы подписи.
Web Crypto по сути должен предоставить доступ к api, который все это (в том числе подписание) реализует в виде отдельного приложения/драйвера. А это опять потенциальная дыра — NPAPI, Flash, java applet потому и выпилили из браузеров, что давали доступ к ресурсам ОС через браузер. В общем замкнутый круг.faiwer
08.02.2018 11:29Web Crypto по сути должен предоставить доступ к api, который все это (в том числе подписание) реализует в виде отдельного приложения/драйвера
Который всё равно будет запущен этим самым браузером. Разве что изоляция будет большая. Но всё равно предполагается, что мы доверяем браузеру.
в идеале браузер не должен ничего знать ни про приватный ключ, ни про пин, ни про алгоритмы подписи.
Ну вот сейчас это реализовывается путём скачивания java-приложения через internet. Какого рода уязвимости мы таким образом "победили"? В чём разница между
- "мы запускаем неизвестный нам код, скачав его из сети, предоставляя ему доступ к содержимому файлов с ключами".
- "мы запускаем неизвестный нам код через https-сайт, предоставляя ему доступ к содержимому файлов с ключами".
Разница в том, что соседняя вкладка потенциально может иметь доступ к адресному пространству ОЗУ "секъюрной" вкладки? Скорее разница в том, что все эти бубны и танцы приводят к тому, что старшее поколение не осилив весь перечень предварительных действий по любому поводу продолжит ходить ногами в ЦОН-ы и прочие заведения.
Впрочем туда так и так ходить приходится, ибо сложно найти на egov хоть что-то, что хоть как-то работает (кроме разве что выдачи адресной справки).
VolCh
08.02.2018 15:29Ну вот сейчас это реализовывается путём скачивания java-приложения через internet. Какого рода уязвимости мы таким образом "победили"? В чём разница между
Использование конкретной версии софта, которой пользователь доверяет, в том числе по причине сертификации её государством. Традиционные веб-технологии не предполагают возможности контролируемого изменения версии используемого софта. Нет способа гарантирования того, что в данный момент исполняется именно та версия кода, которая прошла сертификацию, даже локально на браузере пользователя. А уж отправка приватного ключа на сервер для подписи им от лица пользователя вообще вообще сродни его публикации.
faiwer
08.02.2018 15:33Вы сами в это верите? Вот если бы я грузил исходный код из репозитория (причём без всяких blob-ов) через TLS, и собирал это "руками". Тогда можно было бы заикаться про какую-то конкретную версию софта, которой пользователь "доверяет". На деле я гружу чёрный ящик, который ещё и сам обновляется, да ещё и по незащищённому каналу.
А уж отправка приватного ключа на сервер для подписи им от лица пользователя вообще вообще сродни его публикации.
Вы уже второй раз об этом пишете. Но я об этом и не заикался. Зачем?
faiwer
08.02.2018 15:35Вдобавок — оно ещё и не работает из коробки. Нужно всем браузерам прописывать дополнительные удостоверяющие центры сертификации "Большого брата". За это отдельный "respect" государству :)
khim
08.02.2018 13:02А это опять потенциальная дыра — NPAPI, Flash, java applet потому и выпилили из браузеров, что давали доступ к ресурсам ОС через браузер.
Нет. Их выпилили потому, что они давали возможность доступа к ресурсам ОС без явного уведомления пользователя. А если это происходит по инициативе пользователя — проблем нет, Native Messaging же есть.
khim
08.02.2018 12:56Не видел ни одного канонически правильного решения, которое успешно работает с аудиторий от нескольких миллионов обычных людей.
А искали? Вот, например.ggo
09.02.2018 10:50Это устройство. Их (устройств) немало.
А я спрашивал про проекты с миллионной аудиторией, которые бы в один прекрасный день сказали, так, ребята, пользователи, в течении года переходим на использование устройства Х. Кто не перешел, мы не виноваты. Воспользоваться нашими услугами не сможете.
При этом, использование устройства Х было бы реализовано канонически верно, без компромиссов.khim
09.02.2018 15:03Кто не перешел, мы не виноваты. Воспользоваться нашими услугами не сможете.
А. Это пожалуйста. Или вы хотите совсем принудительно. Как «онлай-кассы» в России. Ндравится?
Всё-таки мне кажется, что с дополнительной стадией, когда какое-то время у вас есть выбор — оно… человечнее.
seytzhan
08.02.2018 10:32Есть еще такой вариант решения.
1. Создаются отдельные приложения для смартфонов, единственной функцией которых будет подписывание. Ключи пользователя будут хранится только на его смартфоне.
2. Далее все заинтересованные сайты-сервисы именно на этапе подписывания генерируют какой-нибудь qr-код с хэшем документа.
3. Пользователь сканирует этот код через свое приложение и подписывает.
4. Далее приложение на смартфоне передает сервису-источнику публичный ключ с подписью для проверки.
Для конечного пользователя здесь похожий принцип, по которому пользователь открывает ватсап на своем десктопе.
На мой взгляд, это будет и удобно, и с точки зрения безопасности все нормально должно быть.
Также и дорабатывать много чего не надо, так как уже похожие приложения тот же egov выпускает кажется.ggo
08.02.2018 11:05Такие приложения уже есть.
Но и с ними свои сложности. Без интернета не подпишешь, как безопасно хранить приватный ключ (разработчики мобильных ОСей предоставляют специальный API, но большинство соглашается, это не гарантирует неразглашения). В общем использование мобилок привносит свои компромиссы.seytzhan
08.02.2018 11:31Интернет все-таки тут обязательное требование, без него все остальные сервисы не имеют смысла. Исключение это только какие-нибудь корпоративные системы документооборота.
Насчет хранения ключей, конечно до аппаратных токенов будет далеко, но получше будет чем сейчас, когда на флэшке всё. Да и пароль самого ключа никто не отменял.khim
08.02.2018 13:10Насчет хранения ключей, конечно до аппаратных токенов будет далеко
А почему далеко? Почему, блин, GitHub может, а Казахстан — не может? В чём разница?seytzhan
08.02.2018 13:17FIDO U2F выглядит интересной технологией для авторизации. А как его можно применить для подписания документа?
khim
08.02.2018 18:44+2Никак. Но Yubiko можно ставить дополнительные аплеты. SSH, например.
Для Github'а — этого достаточно. Для подписи документов нужно будет что-то другое сделать. Но для этого нужно делать, а не плакать, что технологии экспериментальные. Конечно экспериментальные — кто ж их неэксперементальными должен сделать? Марсиане?
Не можете договориться с Оперой или Гуглом? Обратитесь в Yandex, пусть они в свой браузер вкрутят, все остальные встанут перед фактом: или госпредприятия в России и Казахстане все поголовно переходят на Yandex-браузер, либо Гугл берёт патчи от Yandex'а и Chrome — тоже начинает поддерживаться.
А под лежачий камень вода не течёт… шевелиться надо.
TIMOHIUS
08.02.2018 16:11На самом деле, есть возможность хранить ключи на сим-карте. И в таком случае интернет-соединение не нужно, но нужна связь в принципе. На сим-карте просто будет аплет, который будет обрабатывать запросы, а пользователю останется отвечать(да\нет). При чем у этого решения есть как плюсы, так и минусы. Из плюсов, работает даже на самых простых(кнопочных телефонах). Минусы — как минимум необходимы специальные сим-карты.
VolCh
08.02.2018 17:06- Как пользователь убедится, что qr-код соответствует тому, что он собирается подписать, а не договор дарения квартиры это?
seytzhan
08.02.2018 17:17Тут тогда нужно усложнять логику.
1. Можно идти в сторону унификации формата документов: например, использовать markdown или другой похожий несложный формат. В таком случае во время подписи, он будет загружать текст документа на смартфон, там уже можно сверять хэши. В случае с бинарными данными даже не знаю как будет лучше.
2. Также можно работать на сертификацией самих онлайн-сервисов, т.е. не принимать документы от кого попало.
vsb
08.02.2018 15:57У ЭЦП в Казахстане 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 попытки и казтокен превратится в бесполезную пластмасску, например. Хз, может с тех пор исправили, техническая возможность есть, но не уверен.
black888
09.02.2018 10:15+1Спасибо за прекрасный материал, показывающий как на самом деле выглядит наша безопасность «под капотом». Согласен про двустороннюю проблему пользователи-разработчики. Хотелось бы отметить пару практических моментов со стороны пользователей.
1) «с ЭЦП ничего не сделаешь». Мантра разработчиков. С самой ЭЦП ничего, но в составе других преступных деяний, ЭЦП очень даже поможет реализовать замысел. Получить подробности недвижимости которой вы владеете например,… «информация правит миром». Или жениться/развестись без ведома второй стороны. Да, выше правильно указано — заявление подали, а дальше в ЗАГС идти надо. Но в ЗАГСЕ вам бумажки отдадут не поднимая головы. Они же уверены — человек ЭЦП подписал — нафига его с личностью сверять?
А уж произвольному гражданину временную прописку организовать по случайному адресу — это прям вообще легко.
Дело осложняется еще больше, если у гражданина есть собственность в виде компании…
2) хотелось бы услышать такой же анализ про налоговый КНП плагин. Подозреваю, что это какой-то вариант NCLayer. По-крайней мере вместе в одном компе они не живут. Думаю дерутся за общий порт сокета. Но нафига нужно было отдельную софтину городить? Вот вопрос. А что со Статистическим Управлением? Нафига они на странице входа требуют не подпись для аутентификации? Это «стиль такой»?
3) умиляет разделение на «государственные и частные» сайты. Как будто тот факт, что вы зашли на государственный сайт вас от чего-то защищает. Наоборот. Именно из государственных недров достаются всякие «базы ГАИ» и прочие вещи, продающиеся на базарах. Именно против государственных органов бессмысленно подавать иски, хотя частные компании сравнительно легко разорить до копейки, если они «жульничали» или «халявили безопасность». База «путей и паролей» полагаю могла бы стать реальным объектом заработка несчастных админов из страны с минимальной заработной платой в USD 70.
Эта же цифра стоит у меня перед глазами, когда я представляю «государственные органы» в виде заказчиков какого-либо решения с ЭЦП. Сначала «надо чтобы выглядело дорого-богато»: отдельная инфраструктура, бюджет на аппаратное решение, напишем собственный вариант NCLayer. А потом: «а можете вот эту ваши смету поделить на 4. А то дорого очень...». «Конечно можем — но безопасность будет никакая»… Никакой конкретной информацией не владею. Но виртуальный диалог выглядит очень правдоподобно.
4) Можно ли создать общие рекомендации для пользователей ключей на текущий момент?
Что-то в духе меняйте пути к ключам после каждого использования на подозрительных государственных сайтах? Меняйте пароли по понедельникам? Перевыпускайте ключи раз в месяц? Что-нибудь из перечисленного имеет смысл?maratkalibek Автор
09.02.2018 10:24По второму вопросу — это решение называется CryptoSocket от Гамма Технологии. В ближайшее время также постараюсь его рассмотреть. Предварительно скажу, если оно запрашивает пароль всего один раз и то через формочки на сайте. То там такая же ситуация. К сожалению моментально посмотреть не смогу, так как пользуюсь ОС Linux под которую нет версий CryptoSocket.
http://gamma.kz/product/21
maratkalibek Автор
09.02.2018 10:27По четвертому вопросу — все предложенные механизмы для параноиков. А если честно, даже предложенные механизмы не защитят Вас от атак, которые предложены в статье.
vsb
09.02.2018 10:38По п.4. Во-первых используйте аппаратные токены. Самое простое это Казтокен (около 10 000 тенге) или удостоверение с чипом и специальный кард-ридер. Во-вторых задавайте хороший пароль для ключа и никуда на компьютере его не сохраняйте (разве что в хороший менеджер паролей). В-третьих не держите устройство включенным в компьютер, если не пользуетесь им. В-четвёртых используйте отдельный компьютер или хотя бы отдельную виртуальную машину для работы с ЭЦП и другими важными сайтами.
Если получали ключи как попало (пришли со своей флешкой, там их вам сгенерировали и скопировали с ЦОН-овского компьютера), выпустите другие ключи через pki.gov.kz, а те отзовите. А вообще ключи получать надо безопасно, благо у нас для этого всё работает как положено: генерируете ключ на своём устройстве, через pki.gov.kz подаёте заявку, распечатываете, подписываете и в ЦОН предъявляете, потом через тот же pki.gov.kz скачиваете сертификаты.maratkalibek Автор
09.02.2018 10:55Атака в статье, позволяет даже эксплуатировать уязвимость при использовании казтокена. Да, если вы вытащите казтокен когда не работаете, это позволит в то время не пользоваться от вашего имени ключами. Но в промежутках между использованием ЭЦП, такая атака все равно возможна.
ggo
09.02.2018 10:59Это не помогает от перехвата пина.
И это не помогает от подмены информации перед подписью.
Справедливости ради, этим страдает большинство реализаций. Т.к. решения этих недостатков — не юзерфрендли.vsb
09.02.2018 11:13В текущей ситуации от этого ничего не поможет. Разве что писать свой аналог NCALayer без его недостатков. Но вряд-ли за это кто-то заплатит. Но это гипотетические атаки, а вот тупо скопировать файл с ключом это, на мой взгляд, более реальная атака.
VolCh
09.02.2018 11:034) В целом, рекомендация часто менять ключи/пароли минимизирует риски "отложенных" атак типа "мы знаем, что есть инфраструктура, постоянно хранящая эти данные, и наконец-то смогли получить доступ к ним", но не защищает от "реал-тайм" атак типа "мы знаем, что есть инфраструктура, периодически имеющая доступ к этим данным, и наконец-то смогли внедриться в неё".
maratkalibek Автор
09.02.2018 10:19По второму вопросу — это решение называется CryptoSocket от Гамма Технологии. В ближайшее время также постараюсь его рассмотреть. Предварительно скажу, если оно запрашивает пароль всего один раз и то через формочки на сайте. То там такая же ситуация. К сожалению моментально посмотреть не смогу, так как пользуюсь ОС Linux под которую нет версий CryptoSocket.
http://gamma.kz/product/21maratkalibek Автор
09.02.2018 10:55Здесь я ошибаюсь, здесь используется какое-то другое решения для КНП.
vsb
09.02.2018 11:25KNPPlugin написан на Java (и то, что сделали сборку только для Windows, на мой взгляд, большое свинство). В исходниках светится строка com.firstlinesoftware.smartauthclient предполагаю, что это их софт.
TrllServ
09.02.2018 11:23Тем временем, уже проектируется еще одна, возможно, дырявая система habrahabr.ru/post/348488
black888
09.02.2018 22:16Еще раз хотел бы подтвердить для себя некоторые моменты. Простите за повтор — информация важная.
1) атака возможна только если ключ вставлен в компьютер в этот момент?
у меня ключ на удостоверении. Получал безопасно. Никогда не оставляю кардридер вставленным в компьютер. Сами ключи можно забрать с удостоверения через NCLayer? Если нет, это сильно снижает вероятность атаки.
2) если я правильно понимаю, атака не оставляет записи в логах о полученной услуге? Или…? То есть, смогу ли я в суде оспорить эту подпись, ссылаясь на то, что по получению этой «услуги» нет записи в логе? (я понимаю, что если это целый «сайт злоумышленник» то они все логи сделают как положено, но по крайней мере, я не могу посетить сторонний сайт, а в этот момент за меня подпишут что-то на egov, чтобы в логах егов значилась запись? или это тоже возможно?)
3) почему конфликтует КНП плагин и NCLayer? я думал, что на сервере используется примерно одинаковый протокол, и поэтому они «дерутся за порт». Но раз писала его совсем другая контора, они что, тоже для «собственного удобства» пароли и пути к ключам сливают? Понимаю, что это вопрос сложный, однако достаточно важный для пользователей. Рискну предположить, что в некоторой степени вопрос отношений с налоговой может быть даже более важным, чем для физических лиц. Там замешаны гораздо более большие деньги. Там есть коммерческие интересы, конкурренция, рейдерство и прочие вещи, где можно использовать кибератакаи, как составную часть более всеобъемлящего процесса.
4) ну и маленькое предположение. Раз это «полный аналог ручной подписи», кто-нибудь рассматривал вариант применения к потенциальным нарушителям, иска о подделке документов? Кажется это что-то там до 5 лет тюрьмы. Я понимаю, что ситуация виртуальная на текущий момент.
Всем большое спасибо за ответы. Надеюсь это поможет не только мне, но и другим пользователям.maratkalibek Автор
10.02.2018 12:29- Атака возможна тогда, когда есть доступ к носителю, ну и зловредный ресурс запущен. Также известны пароль и путь к носителю. Все происходит незаметно для пользователя.
- Можно увидеть в логах, но все будет по правилам. Нельзя будет отличить от настоящего пользователя. Ну может быть только позже по ip, откуда поступали запросы.
- Не могу сказать, наверное "висят" на одном порту.
- Администритивная ответственность есть. По уголовному кодексу ничего сказать не могу.
maratkalibek Автор
10.02.2018 13:06по 2 вопросу еще раз, Вам точно придется доказывать что это не Вы произвели действие. Но я не вижу как это можно будет доказать. ЭЦП ведь ваша. В логах это будет выглядеть так, как будто вы зашли на егов и запросили все по правилам.
TrllServ
10.02.2018 13:54Т.е. единственный вариант защитить себя от кривой реализации — не получать ЭЦП?
maratkalibek Автор
10.02.2018 14:27- Сама по себе реализация не кривая. Механизм как это предалагается использовать, не совершеннен. Потенциально уязвим.
- Не заходите на левые ресурсы. А вообще сейчас желательно используйте только на егове.
- Обновляйте NCALayer сразу же при выходе обновлений. Я жду чтобы они побыстрей выпустили обновление.
maratkalibek Автор
Это не проблема egov.kz. Такой механизм реализовать сейчас считаю сомнительным, так как ЭЦП мало где внедрено и в основном госорганы. Если же начнут появлятся разные сайты с ЭЦП от компаний, тогда эта проблема становится актуальной.
awlbrut1
В Казахстане до конца февраля 2018 владельцев электронных ресурсов обязали заключать с читателями письменные соглашения с использованием ЭЦП или sms-идентификации. Пруф.
Через смс мало кто внедрять будет, так как каждое смс будет стоить 6 тенге (1 рубль), затраты должны взять на себя владельцы интернет ресурсов. Про стоимость пруф не искал, рассказал знакомый который работает админом на один из информационных порталов в казнете.
maratkalibek Автор
тогда такие варианты атак, вполне реальны.