Comments 56
Как резервируется коробка (точнее информация на ней)?
Что делает ЕЭТП, когда подписант идет в отказ — SMS не получал, в телефоне кнопку не нажимал, это все злые хакеры или ваш админ, я не причем и т.д.?
Да и на сколько я знаю в Южной Корее уже давно используются ОЭП, только УЦ является не какая-то кантора, а банк. Т.е. помимо денег вы доверяете банку хранение своей подписи, что кажется довольно логично, так как пользователь банка сможет подписывать любые транзакции своей ЭП и гарантом будет выступать банк. А банки при обнаружении фактов потери данных или злоупотреблением могут лицензию потерять и большое количество денег.
Что будем использовать ЕЭТП в суде для доказательства, что сделка совершена по волеизъявлению клиента? Как будет ЕЭТП доказывать, что это не ее админ подписал вместо клиента электронный документ?
Кроме того в личном кабинете у каждого пользователя идет логирование и аудит его действий с ключом, где он может самостоятельно убедиться, что его ключ не использовали третьи лица.
Резерв информации — это хранение backup'a.
Там вверху было, что железка обвешана датчиками, вскрыть нельзя, доступ к информации очень ограничен.
Делаем бекап — бекап где лежит? В каком виде? Кто к нему имеет доступ?
Опять же, вверху пишут про отсутствие управляющего api по сети. Как делаем бекап? Подходим к железке и ручками?
неограниченное количество
какой-то неайтишный ответ ;)
КриптоПро HSM 2.0 позволяет безопасно хранить до 500 000 секретных ключей с возможностью расширения до 20 000 000 и более.
1. Какой используется HSM?
2. Какими ключами выполняется подпись — 2001 или 2012?
Не автор статьи, но судя по фото это HSM от фирмы КриптоПро (совместимый с CPS от Крипто Про)
Сертифицированных поставщиков таких продуктов в России можно пересчитать по пальцем одной руки фрезировщика с большим опытом.
Если квалифицированная усиленная — то как выполняются требования раздела 1.5, 2.7 формуляра ЖТЯИ.00096-01 30 01?
От вашей отличается тем, что в мобильном приложении находится одна часть ключа, на сервере другая, подпись ставится «гибридная», там какая-то хитрая математика для этого используется. Можете посмотреть вот тут подробнее.
Вопрос, почему вы не пошли таким путём? Он же намного более безопасный, чем доверять только сертифицированному ФСБ ящику?
Скорее всего здесь не важно более безопасный или нет. А важно, что думает и что сертифицировало ФСБ
Этот аргумент будет работать если закрытый ключе будет не в мобилке, а отдельном устройстве. Тогда у нас будет 3 устройства — мобилка для интерактива, хранилка закрытого ключа у клиента, железка провайдера. Наверно в Эстонии такая схема. Если нет, то идея с разделением классная, но результата от нее нет.
Короче говоря, такое гибридное решение позволяет иметь уровень безопасности как у смарт-карты или мобильного-ид (сим-карты). Из которых нельзя вытащить приватный ключ и им распоряжаться, но если подломить машину, на которой они используются, то можно наворотить делов.
Но вообще, мне не нравятся 2ФА завязанные на мобильник, потому что это зачастую никакой не 2ФА получается. Я захожу в банк через мобильный, и на этом же мобильном аутентифицируюсь. Cейчас достаточно частое явление то, что производители перестают выпускать апдейты (например, на мой Huawei P9 апдейты уже не выпускают, а там незакрытая уязвимость Blueborne). В результате безопасность почти никакая.
Если при всех академических красотах технической реализации возникают элементарные проблемы, когда мобилка в чужих руках, то это означает, что решение красивое, но не рабочее.
Ничем. То есть прикол smart-id не в двухфакторной аутентификации, а в том, что можно хранить приватный ключ в мобильнике в незащищённом хранилище.
Но представим, приложением пользуется ваша мама.
Какой ПИН будет она использовать?
ПИН будет регулярно меняться?
Кто кроме нее будет знать этот ПИН?
Понятно, что можно сказать, что это не проблема приложения и выбранного подхода к хранению ключей. Но если не решаем проблемы людей, это удачное решение?
Я такие видел для криптовалютных кошельков, или например рутокен пин-пад.
1. можно чуть поподробнее - что за устройство ?
2. можно ли как-то на девайсе с экранчиком просмотреть содержимое документа, перед его подписанием ?
А если это многостраничный текстовый двуязычный документ ?
А если это PDF-ка ?
Исходим из того, что существует угроза подмены документа, передаваемого из ПК в девайс, и просмотр документа перед подписанием призван нивелировать эту угрозу.
+500
При обычной ЭП, закрытым ключём владел я и нёс всю ответственность я за него. При ОЭП закрытый ключ, хранится на сервере, а мне лишь доверяют ПЭП (смс или иной способ). Удобство да, безопасность нет.
А каким образом вы прошли сертификацию решения с подтверждением через СМС? На сколько мне известно даже КриптоПро в своем решении "рекомендует" использовать только свое приложение с заточенными под него push уведомлениями.
Я соглашусь со скептиками в комментариях к посту. Как слегка параноик и автор поста про наболевшее, Похождения электронной подписи в России, хочу поинтересоваться: почему владелец ключа должен доверять его вам? Или другому поставщику «облачной подписи»? Что, если в вашем middle-ware произошёл MITM, в том числе из-за злоупотреблений? Закрытый ключ запросто можно изготовить не на HSM (к которому тоже вопросы), а в ПО и эмулировать работу HSM для всей инфраструктуры. Что делать с перехватом SMS? Этот канал вообще не предназначен ни для чего серьёзного: начиная от банальной кражи или манипулирования SIM-картами, кончая убогостями SS7. О том, что пароль в лёгкую был, да сплыл, тоже можно особо не спорить. И принципиальный вопрос: какой вообще практический смысл в криптографии там, где аутентификация и авторизация производится предъявлением практически публичных и воспроизводимых значений? Давайте тогда выпилим весь этот УКЭП и просто будем в качестве закрытого ключа использовать значения пароля и одноразовой SMS. Не нужны будут токены, ключи ГОСТ, hsm и прочий убогий проприетарный софт от CSP №1 в РФ.
А где вы в статье увидели упоминание смс? На сколько я понимаю, решение построено на вполне себе сертифицированном КриптоПро DSS и в качестве второго фактора аутентификации используется myDSS.
Существуют какие то вопросы к HMAC?
Про SMS извинюсь. Это было навеяно иным решением "облачной подписи". Да, тут на сколько я понял TOTP а'ля Google Authenticator и иже с ними. Это тоже не совсем гуд и не защищает от компрометации со стороны поставщика "облачной подписи", так как вектор инициальзации TOTP он и предоставил.
Не знаю насчёт конкретно описанной системы, но используемый автором DSS позволяет, во-первых, дополнительно шифровать ключи на ПИНе пользователя, а во-вторых не просто высылать одноразовые коды, а отправлять на телефон непосредственно подписываемые данные. Так что можно быть уверенным, что ни выполнить операцию ни подменить её без участия пользователя нельзя.
Как противоположная сторона будет доказывать, что у админа возможности что либо подписать вместо клиента нет?
Могу только фантазировать. А чем этот кейс отличается от, например интернет-банка. Как клиент докажет, что транзакцию с переводом выполнил он, а не админ банка? Кажется, что журналов сервера должно быть достаточно, если есть механизм проверки их подлинности.
В интернет-банке речь идет о нескольких тысячах.
В ЕЭТП — суммы на миллионы.
Я про идейную сторону. Как в принципе должно выглядеть удалённое совершение операций, чтобы ему поверили?
Если суд, то суд обычно верит ЭЦП, но если закрытый ключ не у тебя, возникает вопрос, как доказать что подписал именно ты. Диалектика…
На ЕЭТП заключена сделка. Заверена облачной ЭЦП.
Далее клиент идет в отказ — я не подписывал. И забивает на сделку.
Кто идет в суд? ЕЭТП или клиент?
Уходящий в отказ человек- технологически и юридически более слабая сторона, и, именно поэтому противоположная сторона в споре (облачный сервис) должна собирать и предъявлять доказательства виновности пользователя-клиента облачного сервиса.
Юристы- поправьте меня.
Суд проверяет выполнение требований №63-ФЗ. В случае, если это не квалифицированная усиленная ЭП — еще и условий договора.
В рассматриваемом случае квалифицированной усиленной ЭП быть не может, т.к. используется не сертифицированное СКЗИ ( вернее сертифицированное СКЗИ используется с нарушением требований эксплуатационной документации, сертификат не действует). Следовательно, ответ на ваш вопрос лежит в договоре — нужно читать, пот чем там у них пользователи подписываются.
+500
Добро пожаловать :)
Годы уже работает в более развитых странах с ЭП (Израиль).
Клиент получает приложение с ОТР на телефон и маленькое софт на комп (связывающий клиента к центральному HSM хранящему ключи сертифекатов).
При каждом входе через браузер (не важно какой) всплывает прога требущая ввести ОТР с телефона.
Есть ли страховка от "чужого" использования ОЭП, кражи, компроментации и т.д.? По сути, это такие же "деньги из воздуха", как и ssl-сертификаты, но УЦ что-то страхуют и плаьят
223ФЗ, 223ФЗМСП, 44ФЗ, Росатом, ТРИД?
FAQ про облачную [электронную] подпись