FAQ про облачную [электронную] подпись

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



    — Что это такое?

    Раньше была бумажная подпись на документе. Она не очень удобна, не очень безопасна и требует физического наличия бумаги. Потом появилась флешка с сертификатом и обвесом вокруг (вплоть до антивируса). Её сначала назвали ЭЦП — электронная цифровая подпись. Потом она стала просто ЭП. Теперь эту флешку положили в облако, и она стала ОЭП.

    — Как работает ОЭП?

    Предположим, вы подаёте свое предложение на тендер. Раньше, чтобы подписать документ, надо было поставить плагин для браузера, который умел связываться с софтом на локальном компьютере пользователя. Этот софт обращался к софту на флешке, софт на флешке выдавал ключ, этим ключом подписывалась транзакция и передавалась в готовом виде в плагин в браузер. Теперь мы вынимаем из этой цепочки флешку: софт обращается в облачное хранилище по шифрованному туннелю.

    — А можно без софта на локальной машине?

    Да, если на площадке есть промежуточный сервер, который фактически проксирует запросы и представляется этим самым локальным компьютером, то всё можно сделать из любого браузера. Но это требует переработки бэкенда площадки (в нашем случае мы сделали отдельный сервер для проведения торгов с мобильных телефонов). Если этот путь не работает — выбирается стандартный. Предполагается, что в будущем этот вариант будет наиболее распространённым. Как пример одной из подобных реализаций — площадка МСП «Росэлторг» (Закупки среди субъектов малого и среднего предпринимательства).



    — ОЭП и ЭП — это одно и то же, но лежит в разных местах, так?

    У подписей общее ядро с сертификатом и защитой. Функционально это одно и то же, просто меняется метод внутреннего API для шифрования транзакции. Один метод берёт ключ из локального устройства, другой — с удалённого.

    — Погодите, но ведь всё равно нужна авторизация?

    Да. Но теперь она двухфакторная и без привязки к устройству. Обычная схема: установить приложение на телефон или плагин браузера на десктоп, затем ввести логин и пароль для начала работы, потом при совершении транзакции — отправляемый с сервера авторизации ПИН-код. То есть, чтобы подписать документ за вас, нужно будет украсть пароль + логин и перехватить SMS или push-уведомление с кодом.

    — В чём тогда профит?

    1. Если вы потеряете флешку, то надо получать новый ключ. В случае с ОЭП — достаточно поменять пароль к подписи.
    2. Нет привязки к рабочему месту: раньше ЭП ставилась на один конкретный компьютер.
    3. Нет привязки к браузеру: раньше это был IE. Что вызывало ряд проблем ещё на уровне выбора ОС: Linux-админы обходили это, а вот на Mac-устройствах было сложнее.
    4. Нет привязки к географии: авторизация работает из любой страны (в силу особенностей защиты ЭП на флешках часто работали только в российских сетях).
    5. Предполагается, что всё стало безопаснее из-за двухфакторной идентификации по умолчанию без возможности «упростить себе жизнь».
    6. Уничтожение флешки с подписью не ставит под угрозу текущие сделки.
    7. В целом всё это более правильно, особенно из-за возможности быстро подписывать с мобильных телефонов.

    — Где хранится сертификат на стороне удостоверяющего центра?

    Есть специальная железка, называется HSM (hardware security module). Технически, это хранилище, разбитое на закрытые ячейки без возможности массового доступа ко всем сразу.

    Несколько упрощая: вы авторизуетесь, создаёте транзакцию, она отправляется в HSM подписываться, оттуда на выходе — защищённый объект. Закрытый ключ наружу не выдаётся.

    То есть HSM выступает в роли третьей стороны, вроде нотариуса, подтверждающей в сделке, что вы — это вы. Точнее, что вы имеете право подписывать документ.

    В каждом удостоверяющем центре свой HSM.

    Каждое решение лицензируется ФСБ. Железка снабжена большим количеством уровней безопасности, в частности, датчиками антивзлома. Терминал физически встроен в сам сервер, никаких внешних подключений для управления не поддерживается, веб-интерфейса нет. Нужно что-то настроить — свитер, машзал, большой железный ящик с маленьким LCD-экраном.



    — Как с обратной совместимостью?

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

    — Как выглядит первое подключение?

    При настройке на устройстве конечного пользователя указываются два адреса DSS-сервера. Это, собственно, вся настройка и есть. После этого нужно будет авторизоваться на сервере. Пользователь вводит уникальный логин и пароль, которые выдаются ему в удостоверяющем центре. После ввода логина и пароля нужно пройти двухфакторную авторизацию. Обычно пользователь сканирует выданный ему QR-код и устанавливает приложение. Это одно общее приложение вендора подписей, которое кастомизируется под конкретный удостоверяющий центр. Сканируется второй код со ссылкой на свою ячейку в HSM. Отправляется ПИН-код на конкретную транзакцию на телефон абонента, он его использует и подтверждает себя. После этого нужно сменить пароль доступа.



    Следующие транзакции могут быть проще: ПИН отправляется push-уведомлением. Предполагается, что если телефон защищён FaceID или распознаванием отпечатка пальца, то этого второго фактора (в сочетании с вводом логина и пароля) достаточно.

    Если телефон утерян, нужно проходить процедуру с QR-кодами заново.

    Заблокированный телефон без ПИНа бесполезен.

    ПИН без пароля-логина бесполезен.

    Если вы потеряли разблокированный телефон с фотографией логина и пароля, записанных на бумажке (реальный случай в нашем УЦ), то можно запросить блокировку доступа до выяснения.

    — Как получить конверт с доступами к ОЭП?

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

    Сложный случай: приходит сотрудник с заверенной доверенностью, соответствующей требованиям 63-ФЗ (Об электронной подписи) и требованиям службы безопасности удостоверяющего центра.

    — Это уже массовое явление?

    Да. За первый месяц работы УЦ «ЕЭТП» было выпущено около тысячи сертификатов по новой технологии ОЭП. Около 70 % пользователей, оформивших электронные подписи, — это юридические лица, ещё 23 % — ИП. Более 60 % пользователей новой услуги — компании из Москвы. Есть сертификаты и в Санкт-Петербурге, Новосибирске, Хабаровске, Ростове-на-Дону.
    РОСЭЛТОРГ
    33,79
    №1 по электронным закупкам в России
    Поделиться публикацией

    Комментарии 52

      +1
      Сколько в такую коробку влезает закрытых ключей?
      Как резервируется коробка (точнее информация на ней)?

      Что делает ЕЭТП, когда подписант идет в отказ — SMS не получал, в телефоне кнопку не нажимал, это все злые хакеры или ваш админ, я не причем и т.д.?
        0
        По моему все эти вопросы довольно легко решаются, особенно про «кнопку не нажимал»
        Да и на сколько я знаю в Южной Корее уже давно используются ОЭП, только УЦ является не какая-то кантора, а банк. Т.е. помимо денег вы доверяете банку хранение своей подписи, что кажется довольно логично, так как пользователь банка сможет подписывать любые транзакции своей ЭП и гарантом будет выступать банк. А банки при обнаружении фактов потери данных или злоупотреблением могут лицензию потерять и большое количество денег.
          +2
          Вопрос про отказ не в плоскости «доверяет ли клиент УЦ (или банку)», а в плоскости, как разрешается спор, если одна из сторон утверждает что сделку не она подписывала.
          Что будем использовать ЕЭТП в суде для доказательства, что сделка совершена по волеизъявлению клиента? Как будет ЕЭТП доказывать, что это не ее админ подписал вместо клиента электронный документ?
            0
            думаю получить однозначный ответ на этот вопрос можно будет только после появления первых примеров судебной практики в этой области. Любая другая информацию будет либо предположениями, либо красивыми обещаниями того что все будет в порядке.
            0
            в Литве тоже электронная подпись через банк идет
            0
            Ключей может влезть неограниченное количество, все зависит от объема и мощности HSM. Хранящаяся в нем информация — это закрытый ключ, который хранится внутри в зашифрованном виде. Резерв информации — это хранение backup'a. Если есть подозрение на компрометацию ключа — пользователь может сам удалить ключ или обратиться в службу поддержки, где сотрудник ЕЭТП моментально заблокирует учетку и по заявлению отзовет сертификат.

            Кроме того в личном кабинете у каждого пользователя идет логирование и аудит его действий с ключом, где он может самостоятельно убедиться, что его ключ не использовали третьи лица.
              0
              Резерв информации — это хранение backup'a.

              Там вверху было, что железка обвешана датчиками, вскрыть нельзя, доступ к информации очень ограничен.
              Делаем бекап — бекап где лежит? В каком виде? Кто к нему имеет доступ?
              Опять же, вверху пишут про отсутствие управляющего api по сети. Как делаем бекап? Подходим к железке и ручками?

              неограниченное количество

              какой-то неайтишный ответ ;)
                0
                Бекапы мы делаем не самого HSM, а сервера DSS. Для поддержания отказоустойчивости используем горизонтальное масштабирование.

                КриптоПро HSM 2.0 позволяет безопасно хранить до 500 000 секретных ключей с возможностью расширения до 20 000 000 и более.
                  0
                  Какую функцию выполняет DSS-сервер?
                    0
                    Программно-аппаратный комплекс КриптоПро DSS предназначен для централизованного, защищенного хранения закрытых ключей пользователей, а также для удаленного выполнения операций по созданию электронной подписи с использованием ПАКМ КриптоПро HSM.
                      +2
                      Та-а-ак, как-то запутано…
                      На схеме выше DSS не упоминается.
                      В самой статье говорится, что закрытые ключи в HSM, который очень сильно защищен.
                      Далее, здесь в комментах упоминается что закрытые ключи в DSS сервере.

                      Так закрытые ключи внутри HSM или внутри DSS сервера?
                    0
                    Получается, если сервер HSM выходит из строя, то необходимо перевыпускать все сертификаты ЭП?
                      +1
                      Вероятность того, что он выйдет из строя минимальная, также существует режим хранения ключей вне HSM в зашифрованном виде в SQL, что обеспечивает отказоустойчивость.
                        +1

                        Скажите пожалуйста, а что такое "зашифрованный режим в SQL"? То есть, ключ генерируется не на HSM? Или генерируется на HSM, но HSM позволяет экспортировать ключевую пару?

              0
              Интересная технология. Как юрист не соглашусь с тезисом, что ЭП достовернее физической подписи. Вот оцифровали Росреестр и стал он принимать документы по сделкам в электронке. Документы (договоры купли-продажи, акты приема-передачи и проч.) заверены ЭЦП. Фишка в том, что полученные Росреестром эл. документы «теряются», т.е. не попадают в реестровые дела)))) Хотя собственник недвижимости меняется. И таких инцидентов было несколько по рассказам коллег.
                0
                Так виновата не ЭП как таковая, а система хранения данных Росреестра.
                +1
                Интересует два вопроса:
                1. Какой используется HSM?
                2. Какими ключами выполняется подпись — 2001 или 2012?
                  0

                  Не автор статьи, но судя по фото это HSM от фирмы КриптоПро (совместимый с CPS от Крипто Про)
                  Сертифицированных поставщиков таких продуктов в России можно пересчитать по пальцем одной руки фрезировщика с большим опытом.

                    0
                    Разве 2001 еще выдают?
                      0
                      В случаях, когда ключи нужны не для выполнения требований законодательства — кто же вам помешает их выдать или получить? =)
                        0
                        Я как-то думал, что 2001 уже никто из УЦ просто не выдает. Собственно, Зачем?
                          0
                          Из аккредитованных УЦ — да, не выдает с начала 2019г. Из неаккредитованых — для поддержки legacy, для чего же еще…
                      0
                      Крипто HSM, 2012.
                      0
                      Не могли бы вы уточнить, какая ЭП применяется у вас в этой облачной схеме — квалифицированная усиленная или просто усиленная?

                      Если квалифицированная усиленная — то как выполняются требования раздела 1.5, 2.7 формуляра ЖТЯИ.00096-01 30 01?
                        +1
                        В Эстонии запилена система облачной подписи через приложение на мобильник, называется Smart-ID.
                        От вашей отличается тем, что в мобильном приложении находится одна часть ключа, на сервере другая, подпись ставится «гибридная», там какая-то хитрая математика для этого используется. Можете посмотреть вот тут подробнее.
                        Вопрос, почему вы не пошли таким путём? Он же намного более безопасный, чем доверять только сертифицированному ФСБ ящику?
                          0

                          Скорее всего здесь не важно более безопасный или нет. А важно, что думает и что сертифицировало ФСБ

                            0
                            эта система по всей Прибалтике. Что любопытно, в Литве заходить на местные Госуслуги нужно через банк. А в личный кабинет банка нужен Smart ID
                              +1
                              Судя по описанию, части приватного ключа разделены между мобилкой и железкой провайдера. Аргумент в пользу такого подхода приводится «невозможность скомпрометировать закрытый ключ при компрометации одного устройства». Что в целом логично. Но есть нюанс. Весь интерактив выполняется через мобилку. В мобилке же лежит часть приватного ключа. Соответственно тот кто владеет мобилкой, может совершать все доступные операции. Что сводит на нет аргумент про «невозможность скомпрометировать закрытый ключ при компрометации одного устройства».
                              Этот аргумент будет работать если закрытый ключе будет не в мобилке, а отдельном устройстве. Тогда у нас будет 3 устройства — мобилка для интерактива, хранилка закрытого ключа у клиента, железка провайдера. Наверно в Эстонии такая схема. Если нет, то идея с разделением классная, но результата от нее нет.
                                +1
                                Не совсем так. На сколько я понял, плюс в том, что при компрометации облачного хранилища не будут скомпроментированы все ключи в государстве. А облачное хранилище защищает от перебора пин кодов, потому что в мобильнике хранить приватный ключ защищённый пятизначным пином несекъюрно от слова совсем. Есть, конечно, мобильники с хранилищем приватных ключей, но они, на сколько я понимаю, не стандартизированы.
                                Короче говоря, такое гибридное решение позволяет иметь уровень безопасности как у смарт-карты или мобильного-ид (сим-карты). Из которых нельзя вытащить приватный ключ и им распоряжаться, но если подломить машину, на которой они используются, то можно наворотить делов.
                                Но вообще, мне не нравятся 2ФА завязанные на мобильник, потому что это зачастую никакой не 2ФА получается. Я захожу в банк через мобильный, и на этом же мобильном аутентифицируюсь. Cейчас достаточно частое явление то, что производители перестают выпускать апдейты (например, на мой Huawei P9 апдейты уже не выпускают, а там незакрытая уязвимость Blueborne). В результате безопасность почти никакая.
                                  0
                                  Про это и речь.
                                  Если при всех академических красотах технической реализации возникают элементарные проблемы, когда мобилка в чужих руках, то это означает, что решение красивое, но не рабочее.
                                    0
                                    Если мобилка в чужих руках, злоумышленник должен знать пин-коды. Если он знает, то чем это отличается от того, что смарт-карта попадёт в чужие руки с пин-кодами?
                                    Ничем. То есть прикол smart-id не в двухфакторной аутентификации, а в том, что можно хранить приватный ключ в мобильнике в незащищённом хранилище.
                                      0
                                      Так то оно так.
                                      Но представим, приложением пользуется ваша мама.
                                      Какой ПИН будет она использовать?
                                      ПИН будет регулярно меняться?
                                      Кто кроме нее будет знать этот ПИН?
                                      Понятно, что можно сказать, что это не проблема приложения и выбранного подхода к хранению ключей. Но если не решаем проблемы людей, это удачное решение?
                                        0
                                        На смарт-карту или токен вы не сможете случайно установить троян, который взломает ваше устройство изнутри. А на смартфон — легко!
                                          0
                                          Это верно. Зато вы сможете поставить троян на компьютер, на котором пользуетесь смарт-картой. Уровень безопасности тот же самый, что и требовалось доказать. Следующий уровень безопасности это не смарт-карта или токен, а девайс с экранчиком, который получает документы на подпись, подписывает их внутри, и выдаёт обратно.
                                          Я такие видел для криптовалютных кошельков, или например рутокен пин-пад.
                                0

                                При обычной ЭП, закрытым ключём владел я и нёс всю ответственность я за него. При ОЭП закрытый ключ, хранится на сервере, а мне лишь доверяют ПЭП (смс или иной способ). Удобство да, безопасность нет.

                                  0

                                  А каким образом вы прошли сертификацию решения с подтверждением через СМС? На сколько мне известно даже КриптоПро в своем решении "рекомендует" использовать только свое приложение с заточенными под него push уведомлениями.

                                    +5

                                    Я соглашусь со скептиками в комментариях к посту. Как слегка параноик и автор поста про наболевшее, Похождения электронной подписи в России, хочу поинтересоваться: почему владелец ключа должен доверять его вам? Или другому поставщику «облачной подписи»? Что, если в вашем middle-ware произошёл MITM, в том числе из-за злоупотреблений? Закрытый ключ запросто можно изготовить не на HSM (к которому тоже вопросы), а в ПО и эмулировать работу HSM для всей инфраструктуры. Что делать с перехватом SMS? Этот канал вообще не предназначен ни для чего серьёзного: начиная от банальной кражи или манипулирования SIM-картами, кончая убогостями SS7. О том, что пароль в лёгкую был, да сплыл, тоже можно особо не спорить. И принципиальный вопрос: какой вообще практический смысл в криптографии там, где аутентификация и авторизация производится предъявлением практически публичных и воспроизводимых значений? Давайте тогда выпилим весь этот УКЭП и просто будем в качестве закрытого ключа использовать значения пароля и одноразовой SMS. Не нужны будут токены, ключи ГОСТ, hsm и прочий убогий проприетарный софт от CSP №1 в РФ.

                                      +1
                                      Абсолютно точно всё описано, жаль, что не могу плюсануть. Очередной театр абсурда в нашем государстве. Как обычно, все делается чиновниками для галочки и здесь это очевидно на все 100%.
                                        0

                                        А где вы в статье увидели упоминание смс? На сколько я понимаю, решение построено на вполне себе сертифицированном КриптоПро DSS и в качестве второго фактора аутентификации используется myDSS.
                                        Существуют какие то вопросы к HMAC?

                                          0

                                          Про SMS извинюсь. Это было навеяно иным решением "облачной подписи". Да, тут на сколько я понял TOTP а'ля Google Authenticator и иже с ними. Это тоже не совсем гуд и не защищает от компрометации со стороны поставщика "облачной подписи", так как вектор инициальзации TOTP он и предоставил.

                                            0

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

                                              +1
                                              Допустим клиент пошел в отказ — смс не получал, ничего не подписывал, это ваш админ все без моего ведома сделал.
                                              Как противоположная сторона будет доказывать, что у админа возможности что либо подписать вместо клиента нет?
                                                0

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

                                                  0
                                                  Размером рисков.
                                                  В интернет-банке речь идет о нескольких тысячах.
                                                  В ЕЭТП — суммы на миллионы.
                                                    0

                                                    Я про идейную сторону. Как в принципе должно выглядеть удалённое совершение операций, чтобы ему поверили?

                                                      0
                                                      Тут надо ответить на вопрос «поверили — кто».
                                                      Если суд, то суд обычно верит ЭЦП, но если закрытый ключ не у тебя, возникает вопрос, как доказать что подписал именно ты. Диалектика…
                                                        0
                                                        Отвечая на ваш исходный вопрос. Если пользователь заявляет, что он не подписывал ничего, это эквивалентно обвинению в преступлении со стороны сотрудников облачного сервиса. Так что доказательства уходящему в отказ от операции человеку, вроде как, нужно собирать самому.
                                                          0
                                                          Как вы себе это представляете?
                                                          На ЕЭТП заключена сделка. Заверена облачной ЭЦП.
                                                          Далее клиент идет в отказ — я не подписывал. И забивает на сделку.
                                                          Кто идет в суд? ЕЭТП или клиент?
                                                          0
                                                          Суд ЭЦП не верит. Хотя бы потому что с 2011 года в РФ никакой ЭЦП нету, а есть электронная подпись (ЭП).
                                                          Суд проверяет выполнение требований №63-ФЗ. В случае, если это не квалифицированная усиленная ЭП — еще и условий договора.
                                                          В рассматриваемом случае квалифицированной усиленной ЭП быть не может, т.к. используется не сертифицированное СКЗИ ( вернее сертифицированное СКЗИ используется с нарушением требований эксплуатационной документации, сертификат не действует). Следовательно, ответ на ваш вопрос лежит в договоре — нужно читать, пот чем там у них пользователи подписываются.
                                          0

                                          Добро пожаловать :)


                                          Годы уже работает в более развитых странах с ЭП (Израиль).
                                          Клиент получает приложение с ОТР на телефон и маленькое софт на комп (связывающий клиента к центральному HSM хранящему ключи сертифекатов).
                                          При каждом входе через браузер (не важно какой) всплывает прога требущая ввести ОТР с телефона.

                                            +1

                                            Есть ли страховка от "чужого" использования ОЭП, кражи, компроментации и т.д.? По сути, это такие же "деньги из воздуха", как и ssl-сертификаты, но УЦ что-то страхуют и плаьят

                                              0
                                              А для каких типов торгов допускается применение такой ЭП?
                                              223ФЗ, 223ФЗМСП, 44ФЗ, Росатом, ТРИД?

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

                                              Самое читаемое