— Что это такое?
Раньше была бумажная подпись на документе. Она не очень удобна, не очень безопасна и требует физического наличия бумаги. Потом появилась флешка с сертификатом и обвесом вокруг (вплоть до антивируса). Её сначала назвали ЭЦП — электронная цифровая подпись. Потом она стала просто ЭП. Теперь эту флешку положили в облако, и она стала ОЭП.
— Как работает ОЭП?
Предположим, вы подаёте свое предложение на тендер. Раньше, чтобы подписать документ, надо было поставить плагин для браузера, который умел связываться с софтом на локальном компьютере пользователя. Этот софт обращался к софту на флешке, софт на флешке выдавал ключ, этим ключом подписывалась транзакция и передавалась в готовом виде в плагин в браузер. Теперь мы вынимаем из этой цепочки флешку: софт обращается в облачное хранилище по шифрованному туннелю.
— А можно без софта на локальной машине?
Да, если на площадке есть промежуточный сервер, который фактически проксирует запросы и представляется этим самым локальным компьютером, то всё можно сделать из любого браузера. Но это требует переработки бэкенда площадки (в нашем случае мы сделали отдельный сервер для проведения торгов с мобильных телефонов). Если этот путь не работает — выбирается стандартный. Предполагается, что в будущем этот вариант будет наиболее распространённым. Как пример одной из подобных реализаций — площадка МСП «Росэлторг» (Закупки среди субъектов малого и среднего предпринимательства).
— ОЭП и ЭП — это одно и то же, но лежит в разных местах, так?
У подписей общее ядро с сертификатом и защитой. Функционально это одно и то же, просто меняется метод внутреннего API для шифрования транзакции. Один метод берёт ключ из локального устройства, другой — с удалённого.
— Погодите, но ведь всё равно нужна авторизация?
Да. Но теперь она двухфакторная и без привязки к устройству. Обычная схема: установить приложение на телефон или плагин браузера на десктоп, затем ввести логин и пароль для начала работы, потом при совершении транзакции — отправляемый с сервера авторизации ПИН-код. То есть, чтобы подписать документ за вас, нужно будет украсть пароль + логин и перехватить SMS или push-уведомление с кодом.
— В чём тогда профит?
- Если вы потеряете флешку, то надо получать новый ключ. В случае с ОЭП — достаточно поменять пароль к подписи.
- Нет привязки к рабочему месту: раньше ЭП ставилась на один конкретный компьютер.
- Нет привязки к браузеру: раньше это был IE. Что вызывало ряд проблем ещё на уровне выбора ОС: Linux-админы обходили это, а вот на Mac-устройствах было сложнее.
- Нет привязки к географии: авторизация работает из любой страны (в силу особенностей защиты ЭП на флешках часто работали только в российских сетях).
- Предполагается, что всё стало безопаснее из-за двухфакторной идентификации по умолчанию без возможности «упростить себе жизнь».
- Уничтожение флешки с подписью не ставит под угрозу текущие сделки.
- В целом всё это более правильно, особенно из-за возможности быстро подписывать с мобильных телефонов.
— Где хранится сертификат на стороне удостоверяющего центра?
Есть специальная железка, называется HSM (hardware security module). Технически, это хранилище, разбитое на закрытые ячейки без возможности массового доступа ко всем сразу.
Несколько упрощая: вы авторизуетесь, создаёте транзакцию, она отправляется в HSM подписываться, оттуда на выходе — защищённый объект. Закрытый ключ наружу не выдаётся.
То есть HSM выступает в роли третьей стороны, вроде нотариуса, подтверждающей в сделке, что вы — это вы. Точнее, что вы имеете право подписывать документ.
В каждом удостоверяющем центре свой HSM.
Каждое решение лицензируется ФСБ. Железка снабжена большим количеством уровней безопасности, в частности, датчиками антивзлома. Терминал физически встроен в сам сервер, никаких внешних подключений для управления не поддерживается, веб-интерфейса нет. Нужно что-то настроить — свитер, машзал, большой железный ящик с маленьким LCD-экраном.
— Как с обратной совместимостью?
Опять же, упрощая, новые версии ПО для работы с ЭП теперь умеют делать что-то вроде эмуляции этой самой флешки для всего старого софта. То есть не важно, что вы используете: токен на физическом носителе или доступ к HSM. Обновлённый софт подпишет всё, как в старые добрые времена.
— Как выглядит первое подключение?
При настройке на устройстве конечного пользователя указываются два адреса DSS-сервера. Это, собственно, вся настройка и есть. После этого нужно будет авторизоваться на сервере. Пользователь вводит уникальный логин и пароль, которые выдаются ему в удостоверяющем центре. После ввода логина и пароля нужно пройти двухфакторную авторизацию. Обычно пользователь сканирует выданный ему QR-код и устанавливает приложение. Это одно общее приложение вендора подписей, которое кастомизируется под конкретный удостоверяющий центр. Сканируется второй код со ссылкой на свою ячейку в HSM. Отправляется ПИН-код на конкретную транзакцию на телефон абонента, он его использует и подтверждает себя. После этого нужно сменить пароль доступа.
Следующие транзакции могут быть проще: ПИН отправляется push-уведомлением. Предполагается, что если телефон защищён FaceID или распознаванием отпечатка пальца, то этого второго фактора (в сочетании с вводом логина и пароля) достаточно.
Если телефон утерян, нужно проходить процедуру с QR-кодами заново.
Заблокированный телефон без ПИНа бесполезен.
ПИН без пароля-логина бесполезен.
Если вы потеряли разблокированный телефон с фотографией логина и пароля, записанных на бумажке (реальный случай в нашем УЦ), то можно запросить блокировку доступа до выяснения.
— Как получить конверт с доступами к ОЭП?
Простой случай: заявитель (гендиректор юрлица) приходит лично с паспортом в удостоверяющий центр и получает конверт.
Сложный случай: приходит сотрудник с заверенной доверенностью, соответствующей требованиям 63-ФЗ (Об электронной подписи) и требованиям службы безопасности удостоверяющего центра.
— Это уже массовое явление?
Да. За первый месяц работы УЦ «ЕЭТП» было выпущено около тысячи сертификатов по новой технологии ОЭП. Около 70 % пользователей, оформивших электронные подписи, — это юридические лица, ещё 23 % — ИП. Более 60 % пользователей новой услуги — компании из Москвы. Есть сертификаты и в Санкт-Петербурге, Новосибирске, Хабаровске, Ростове-на-Дону.
Комментарии (41)
TrialLawyer
19.09.2019 12:50Интересная технология. Как юрист не соглашусь с тезисом, что ЭП достовернее физической подписи. Вот оцифровали Росреестр и стал он принимать документы по сделкам в электронке. Документы (договоры купли-продажи, акты приема-передачи и проч.) заверены ЭЦП. Фишка в том, что полученные Росреестром эл. документы «теряются», т.е. не попадают в реестровые дела)))) Хотя собственник недвижимости меняется. И таких инцидентов было несколько по рассказам коллег.
tikale
19.09.2019 12:55Интересует два вопроса:
1. Какой используется HSM?
2. Какими ключами выполняется подпись — 2001 или 2012?mmMike
19.09.2019 14:21Не автор статьи, но судя по фото это HSM от фирмы КриптоПро (совместимый с CPS от Крипто Про)
Сертифицированных поставщиков таких продуктов в России можно пересчитать по пальцем одной руки фрезировщика с большим опытом.
UltrabootCD
19.09.2019 15:17Разве 2001 еще выдают?
elobachev
19.09.2019 18:45В случаях, когда ключи нужны не для выполнения требований законодательства — кто же вам помешает их выдать или получить? =)
UltrabootCD
20.09.2019 17:04Я как-то думал, что 2001 уже никто из УЦ просто не выдает. Собственно, Зачем?
elobachev
22.09.2019 15:17Из аккредитованных УЦ — да, не выдает с начала 2019г. Из неаккредитованых — для поддержки legacy, для чего же еще…
elobachev
19.09.2019 18:35Не могли бы вы уточнить, какая ЭП применяется у вас в этой облачной схеме — квалифицированная усиленная или просто усиленная?
Если квалифицированная усиленная — то как выполняются требования раздела 1.5, 2.7 формуляра ЖТЯИ.00096-01 30 01?
kommari
19.09.2019 21:31В Эстонии запилена система облачной подписи через приложение на мобильник, называется Smart-ID.
От вашей отличается тем, что в мобильном приложении находится одна часть ключа, на сервере другая, подпись ставится «гибридная», там какая-то хитрая математика для этого используется. Можете посмотреть вот тут подробнее.
Вопрос, почему вы не пошли таким путём? Он же намного более безопасный, чем доверять только сертифицированному ФСБ ящику?
buldo
19.09.2019 22:11Скорее всего здесь не важно более безопасный или нет. А важно, что думает и что сертифицировало ФСБ
krylov_sn
19.09.2019 23:56эта система по всей Прибалтике. Что любопытно, в Литве заходить на местные Госуслуги нужно через банк. А в личный кабинет банка нужен Smart ID
ggo
20.09.2019 09:52Судя по описанию, части приватного ключа разделены между мобилкой и железкой провайдера. Аргумент в пользу такого подхода приводится «невозможность скомпрометировать закрытый ключ при компрометации одного устройства». Что в целом логично. Но есть нюанс. Весь интерактив выполняется через мобилку. В мобилке же лежит часть приватного ключа. Соответственно тот кто владеет мобилкой, может совершать все доступные операции. Что сводит на нет аргумент про «невозможность скомпрометировать закрытый ключ при компрометации одного устройства».
Этот аргумент будет работать если закрытый ключе будет не в мобилке, а отдельном устройстве. Тогда у нас будет 3 устройства — мобилка для интерактива, хранилка закрытого ключа у клиента, железка провайдера. Наверно в Эстонии такая схема. Если нет, то идея с разделением классная, но результата от нее нет.kommari
21.09.2019 00:40+1Не совсем так. На сколько я понял, плюс в том, что при компрометации облачного хранилища не будут скомпроментированы все ключи в государстве. А облачное хранилище защищает от перебора пин кодов, потому что в мобильнике хранить приватный ключ защищённый пятизначным пином несекъюрно от слова совсем. Есть, конечно, мобильники с хранилищем приватных ключей, но они, на сколько я понимаю, не стандартизированы.
Короче говоря, такое гибридное решение позволяет иметь уровень безопасности как у смарт-карты или мобильного-ид (сим-карты). Из которых нельзя вытащить приватный ключ и им распоряжаться, но если подломить машину, на которой они используются, то можно наворотить делов.
Но вообще, мне не нравятся 2ФА завязанные на мобильник, потому что это зачастую никакой не 2ФА получается. Я захожу в банк через мобильный, и на этом же мобильном аутентифицируюсь. Cейчас достаточно частое явление то, что производители перестают выпускать апдейты (например, на мой Huawei P9 апдейты уже не выпускают, а там незакрытая уязвимость Blueborne). В результате безопасность почти никакая.ggo
23.09.2019 10:16Про это и речь.
Если при всех академических красотах технической реализации возникают элементарные проблемы, когда мобилка в чужих руках, то это означает, что решение красивое, но не рабочее.kommari
23.09.2019 10:36Если мобилка в чужих руках, злоумышленник должен знать пин-коды. Если он знает, то чем это отличается от того, что смарт-карта попадёт в чужие руки с пин-кодами?
Ничем. То есть прикол smart-id не в двухфакторной аутентификации, а в том, что можно хранить приватный ключ в мобильнике в незащищённом хранилище.
Sedekus
19.09.2019 22:05При обычной ЭП, закрытым ключём владел я и нёс всю ответственность я за него. При ОЭП закрытый ключ, хранится на сервере, а мне лишь доверяют ПЭП (смс или иной способ). Удобство да, безопасность нет.
alrdev
19.09.2019 22:05А каким образом вы прошли сертификацию решения с подтверждением через СМС? На сколько мне известно даже КриптоПро в своем решении "рекомендует" использовать только свое приложение с заточенными под него push уведомлениями.
Pas
19.09.2019 22:22Я соглашусь со скептиками в комментариях к посту. Как слегка параноик и автор поста про наболевшее, Похождения электронной подписи в России, хочу поинтересоваться: почему владелец ключа должен доверять его вам? Или другому поставщику «облачной подписи»? Что, если в вашем middle-ware произошёл MITM, в том числе из-за злоупотреблений? Закрытый ключ запросто можно изготовить не на HSM (к которому тоже вопросы), а в ПО и эмулировать работу HSM для всей инфраструктуры. Что делать с перехватом SMS? Этот канал вообще не предназначен ни для чего серьёзного: начиная от банальной кражи или манипулирования SIM-картами, кончая убогостями SS7. О том, что пароль в лёгкую был, да сплыл, тоже можно особо не спорить. И принципиальный вопрос: какой вообще практический смысл в криптографии там, где аутентификация и авторизация производится предъявлением практически публичных и воспроизводимых значений? Давайте тогда выпилим весь этот УКЭП и просто будем в качестве закрытого ключа использовать значения пароля и одноразовой SMS. Не нужны будут токены, ключи ГОСТ, hsm и прочий убогий проприетарный софт от CSP №1 в РФ.
Vplusplus
19.09.2019 23:06Абсолютно точно всё описано, жаль, что не могу плюсануть. Очередной театр абсурда в нашем государстве. Как обычно, все делается чиновниками для галочки и здесь это очевидно на все 100%.
HechiceroR
20.09.2019 18:23А где вы в статье увидели упоминание смс? На сколько я понимаю, решение построено на вполне себе сертифицированном КриптоПро DSS и в качестве второго фактора аутентификации используется myDSS.
Существуют какие то вопросы к HMAC?Pas
21.09.2019 01:28Про SMS извинюсь. Это было навеяно иным решением "облачной подписи". Да, тут на сколько я понял TOTP а'ля Google Authenticator и иже с ними. Это тоже не совсем гуд и не защищает от компрометации со стороны поставщика "облачной подписи", так как вектор инициальзации TOTP он и предоставил.
grey42
22.09.2019 17:21Не знаю насчёт конкретно описанной системы, но используемый автором DSS позволяет, во-первых, дополнительно шифровать ключи на ПИНе пользователя, а во-вторых не просто высылать одноразовые коды, а отправлять на телефон непосредственно подписываемые данные. Так что можно быть уверенным, что ни выполнить операцию ни подменить её без участия пользователя нельзя.
ggo
23.09.2019 10:20Допустим клиент пошел в отказ — смс не получал, ничего не подписывал, это ваш админ все без моего ведома сделал.
Как противоположная сторона будет доказывать, что у админа возможности что либо подписать вместо клиента нет?grey42
23.09.2019 10:25Могу только фантазировать. А чем этот кейс отличается от, например интернет-банка. Как клиент докажет, что транзакцию с переводом выполнил он, а не админ банка? Кажется, что журналов сервера должно быть достаточно, если есть механизм проверки их подлинности.
PaulNemiroff
20.09.2019 12:09Добро пожаловать :)
Годы уже работает в более развитых странах с ЭП (Израиль).
Клиент получает приложение с ОТР на телефон и маленькое софт на комп (связывающий клиента к центральному HSM хранящему ключи сертифекатов).
При каждом входе через браузер (не важно какой) всплывает прога требущая ввести ОТР с телефона.
mvs
21.09.2019 16:08Есть ли страховка от "чужого" использования ОЭП, кражи, компроментации и т.д.? По сути, это такие же "деньги из воздуха", как и ssl-сертификаты, но УЦ что-то страхуют и плаьят
ggo
Сколько в такую коробку влезает закрытых ключей?
Как резервируется коробка (точнее информация на ней)?
Что делает ЕЭТП, когда подписант идет в отказ — SMS не получал, в телефоне кнопку не нажимал, это все злые хакеры или ваш админ, я не причем и т.д.?
CDCrom
По моему все эти вопросы довольно легко решаются, особенно про «кнопку не нажимал»
Да и на сколько я знаю в Южной Корее уже давно используются ОЭП, только УЦ является не какая-то кантора, а банк. Т.е. помимо денег вы доверяете банку хранение своей подписи, что кажется довольно логично, так как пользователь банка сможет подписывать любые транзакции своей ЭП и гарантом будет выступать банк. А банки при обнаружении фактов потери данных или злоупотреблением могут лицензию потерять и большое количество денег.
ggo
Вопрос про отказ не в плоскости «доверяет ли клиент УЦ (или банку)», а в плоскости, как разрешается спор, если одна из сторон утверждает что сделку не она подписывала.
Что будем использовать ЕЭТП в суде для доказательства, что сделка совершена по волеизъявлению клиента? Как будет ЕЭТП доказывать, что это не ее админ подписал вместо клиента электронный документ?
krylov_sn
в Литве тоже электронная подпись через банк идет
alexxdegt Автор
Ключей может влезть неограниченное количество, все зависит от объема и мощности HSM. Хранящаяся в нем информация — это закрытый ключ, который хранится внутри в зашифрованном виде. Резерв информации — это хранение backup'a. Если есть подозрение на компрометацию ключа — пользователь может сам удалить ключ или обратиться в службу поддержки, где сотрудник ЕЭТП моментально заблокирует учетку и по заявлению отзовет сертификат.
Кроме того в личном кабинете у каждого пользователя идет логирование и аудит его действий с ключом, где он может самостоятельно убедиться, что его ключ не использовали третьи лица.
ggo
Там вверху было, что железка обвешана датчиками, вскрыть нельзя, доступ к информации очень ограничен.
Делаем бекап — бекап где лежит? В каком виде? Кто к нему имеет доступ?
Опять же, вверху пишут про отсутствие управляющего api по сети. Как делаем бекап? Подходим к железке и ручками?
какой-то неайтишный ответ ;)
alexxdegt Автор
Бекапы мы делаем не самого HSM, а сервера DSS. Для поддержания отказоустойчивости используем горизонтальное масштабирование.
КриптоПро HSM 2.0 позволяет безопасно хранить до 500 000 секретных ключей с возможностью расширения до 20 000 000 и более.
ggo
Какую функцию выполняет DSS-сервер?
alexxdegt Автор
Программно-аппаратный комплекс КриптоПро DSS предназначен для централизованного, защищенного хранения закрытых ключей пользователей, а также для удаленного выполнения операций по созданию электронной подписи с использованием ПАКМ КриптоПро HSM.
ggo
Та-а-ак, как-то запутано…
На схеме выше DSS не упоминается.
В самой статье говорится, что закрытые ключи в HSM, который очень сильно защищен.
Далее, здесь в комментах упоминается что закрытые ключи в DSS сервере.
Так закрытые ключи внутри HSM или внутри DSS сервера?
leftleg
Получается, если сервер HSM выходит из строя, то необходимо перевыпускать все сертификаты ЭП?
alexxdegt Автор
Вероятность того, что он выйдет из строя минимальная, также существует режим хранения ключей вне HSM в зашифрованном виде в SQL, что обеспечивает отказоустойчивость.
Pas
Скажите пожалуйста, а что такое "зашифрованный режим в SQL"? То есть, ключ генерируется не на HSM? Или генерируется на HSM, но HSM позволяет экспортировать ключевую пару?