Comments 8
В значительной степени такое сомнение касается вообще всей криптографии на базе JS.
В значительной степени такое сомнение касается вообще всей криптографии на базе JS.
Но в данной статье нет ни слова о криптографии на базе JS. Криптографией занимается нативное приложение NCALayer.
Вы не можете доверять своему коду, так как он у вас где? Правильно, вот тут: cdn.jsdelivr.net/npm/vue@2.
Согласен, было бы надежнее не использовать CDNы, благо сделать это не сложно. В данном случае я использую CDNы для простоты, так как это пример.
А данные, которые js ему передает (а он ведь передает)? Вы им доверяете?
>В данном случае я использую CDNы для простоты, так как это пример.
Ну ок, как пример — нет вопросов. Я просто к тому, что по-хорошему, вот такое вот приложение — оно должно быть строго замкнуто, все ресурсы — только по https, со своих серверов, а если можем подписать каждый ресурс электронной подписью — то сделать это и проверить (и не факт, что это можно). Только тогда ему реально можно будет доверять.
все ресурсы — только по https, со своих серверов
Полностью солидарен, дополню статью рекомендацией не применять CDNы на боевых системах.
А данные, которые js ему передает (а он ведь передает)? Вы им доверяете?
Я понимаю к чему Вы клоните, но ведь мы продолжаем пользоваться множеством систем, которым не имеем никаких оснований доверять. Тут нужен баланс между практичностью и безопасностью.
На мой взгляд хорошим решением, в данном случае, было бы доработать NCALayer так, чтобы он позволял просматривать подписываемые данные перед подписанием, вопрос этот поднимали: https://forum.pki.gov.kz/t/pochemu-v-ncalayer-netu-vizualizaczii-podpisyvaemyh-dannyh/590
Просто юридическая значимость — это даже не столько про доверие ваше к системе, сколько про доверие к вам условных специалистов по ИБ. Ну или юристов. Ну т.е. скажем от меня при внедрении похожей системы, которая выдает финансово значимые документы типа банковской выписки, потребовали зашифровать канал между приложением и базой данных.
Мы правда потом убедили коллег, что шифрование не обеспечивает целостность документа все равно, оно скорее от подслушивания спасет, или кражи данных, а нас не это волновало — но все равно, когда у вас юридические требования, или скажем участвует регулятор — то все происходит немножко иначе :)
Точно, в разных случаях разные средства.
Но, как минимум, хотя бы такие курьезы хотелось бы предотвратить: https://ct.kz/hall-of-fame-eds/elicensekz/
Очень сомнительная штука. Сервер подписей на сокетах
На сколько я понимаю, Вы про NCALayer. Прошу заметить, что это ПО — официальное средство формирования цифровых подписей, распространяемое Национальным Удостоверяющим Центром РК и именно его следует использовать всем тем, кто собирается интегрировать свои системы с этим УЦ. То есть то, что я использую именно это ПО, это не прихоть, это необходимость. Сам я к НУЦ прямого отношения не имею.
По поводу самого NCALayer, я с Вами согласен, что при таком подходе возможны нюансы.
Из хорошего могу рассказать то, что текущий рекомендуемый API NCALayer не позволяет автоматически подписывать что-либо, вместо этого на каждый запрос на подписание отображается GUI приложения с запросом выбора хранилища и ввода пароля. Предыдущий API позволял автоматически подписывать данные, обещают его в скором времени отключить.
То, что подписываемые данные могут быть подменены, это смущает не только Вас. Хотя если посмотреть на текущую ситуацию под другим углом, то получается что пользователи, зачастую, вообще не знают что именно подписывают: веб страница формирует какое-то визуальное представление и какое-то подписываемое представление, на сколько они пересекаются — открытый вопрос. Как я уже писал в соседней ветке комментариев, было бы замечательно, если бы NCALayer позволял просматривать то, что было передано на подписание, это пытались обсуждать на форуме НУЦ: https://forum.pki.gov.kz/t/pochemu-v-ncalayer-netu-vizualizaczii-podpisyvaemyh-dannyh/590
Юридически значимый электронный документ (для РК) из веб формы без серверного кода