Комментарии 88
63-ФЗ Статья 5. Виды электронных подписей пункт 4:
«Квалифицированной электронной подписью является электронная подпись, которая соответствует всем признакам неквалифицированной электронной подписи и следующим дополнительным признакам:
1) ключ проверки электронной подписи указан в квалифицированном сертификате;
2) для создания и проверки электронной подписи используются средства электронной подписи, имеющие подтверждение соответствия требованиям, установленным в соответствии с настоящим Федеральным законом.»
КриптоПро CSP таким средством электронной подписи является, Java KeyStore нет.
Эта схема конечно будет работать. Но первая же проверка может аннулировать все подписи, которые были выполнены этой системой.
Я писал про юридическую сторону вопроса и последствия. Вы можете нарушать закон и скрывать это как угодно. Только факт нарушения это не отменяет. И от ответственности не освобождает.
Есть отсылка на некие требования к средствам электронной подписи.
для создания и проверки электронной подписи используются средства электронной подписи, имеющие подтверждение соответствия требованиям, установленным в соответствии с настоящим Федеральным законом.
Сами требования к средствам электронной подписи:
Статья 12. Средства электронной подписи
1. Для создания и проверки электронной подписи, создания ключа электронной подписи и ключа проверки электронной подписи должны использоваться средства электронной подписи, которые:
1) позволяют установить факт изменения подписанного электронного документа после момента его подписания;
2) обеспечивают практическую невозможность вычисления ключа электронной подписи из электронной подписи или из ключа ее проверки.
…
4. Средства электронной подписи, предназначенные для создания электронных подписей в электронных документах, содержащих сведения, составляющие государственную тайну, или предназначенные для использования в информационной системе, содержащей сведения, составляющие государственную тайну, подлежат подтверждению соответствия обязательным требованиям по защите сведений соответствующей степени секретности в соответствии с законодательством Российской Федерации. Средства электронной подписи, предназначенные для создания электронных подписей в электронных документах, содержащих информацию ограниченного доступа (в том числе персональные данные), не должны нарушать конфиденциальность такой информации.
Т.е. специальное подтверждение нужно для гос.тайны, что логично.
Из всего этого проистекает, что нельзя использовать BC?
Прочие мысли вслух:
А если я подписал документ в помощью устройства, которое сейчас недоступно, и доказать что на том устройстве был КРиптоПро, подписал я с помощью КриптоПро у меня возможности нет. То все, подписанный документ нелегитимен?
И как доказать что документ подписан именно в BC, а не в КриптоПро?
Приказ ФСБ РФ от 27 декабря 2011 г. № 796 «Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра» — https://www.garant.ru/products/ipo/prime/doc/70039150/
Как именно будет действовать суд или регулятор я не берусь предсказывать. Могу только предположить. Так как СКЗИ в России подлежат учету, то Вам необходимо будет как минимум показать, что на Ваши паспортные данные записана лицензия сертифицированной версии того или иного СКЗИ.
А используешь ли ты данный скзи для создания эцп, и не используешь — для юридической значимости эцп значения не имеет?
Я же написал, что это только мое предположение, с чего начнут проверку. Проверить наличие лицензии очень просто. И если ее нет, то уж точно было не сертифицированное СКЗИ. Если лицензия была, то можно уже копать дальше.
Ещё раз отмечу, как это будет происходить в реальной жизни я не знаю.
Вот два субъекта в судебном порядке выясняют между собой кто прав. Один (или оба, неважно) предоставляет электронный документ с электронной же подписью, под капотом которой ГОСТ. И прилагает еще лицензию о законном приобретении СКЗИ.
Как судья будет выяснять значимость представленного документа? Наверно судья пригласит эксперта в этой области. Пусть будет экспертом сотрудник какого-нибудь Всероссийского Национального Удостоверяющего Центра. Что будет делать данный эксперт с электронным документом и подписью? Наверно проведет экспертизу и вынесет официальным вердикт о соответствии документа подписи, и действительности сертификата подписанта в момент подписи.
Будет ли эксперт выяснять, а запускалось ли СКЗИ в момент подписания?
далее сугубо имхо.
Мне лично понятна идея для чего нужна сертификация СКЗИ. Ровно для того же, для чего нужна сертификация бытовой электроники. Чтобы у обывателей не возникало вопросов, а выполняет ли свою основную функцию продаваемое изделие. Я как обыватель совершенно не понимаю, а всем ли стандартам связи соответствует покупаемой мной мобильный телефон. Пусть специалисты в этой области выясняют это.
Но сертификация СКЗИ из средства защиты потребителей, превратилась в средство оказания давления на потребителей же.
У потребителя цель — получать юридически значимые электронные документы и подписи. Если на выходе документы валидны, то способ их получения становится вторичным.
(оставляем за скобками разные специфичные кейсы, вроде гостайн)
Пример того что сертефикация СКЗИ могла бы делать(неуверен что она реально это делает): если взять подпись на эллиптической кривых. И у вас 1) есть возможность подписывать произвольные данные. 2) в реализации алгоритма подписи используется предсказуемый генератор случайных чисел то возможна утечка приватного ключа(привет PlayStation 3).
И возможно еще есть какието моменты.
en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Signature_generation_algorithm
ПДн почти приравняли гостайне тихой сапой.
Запрещать использовать без сертификации — плохо.
Например, продавать можно только сертифицированные холодильники.
Но не запрещенно эксплуатировать DIY холодильник.
Проводим аналогию.
Продавать можно только сертифицированные СКЗИ. Вроде все логично.
Но если очень хочется, можно эксплуатировать на свой страх и риск любые прочие СКЗИ, за исключением специальных случаев (например, уверен холодильники для лекарств должны быть со специальной сертификацией, никакой самодеятельности). Вроде тоже все логично.
А насчет всего остального…
При открытии кафе действительно проверяют всякое: наличие места для хранения охлажденных и замороженных продуктов, вытяжка, жироуловитель, и прочее. Но это именно проверка на соответствие общим требованиям. Откуда холодильник — СЭС мало волнует.
Идем на сайт авторов и покупаем новую.
Зашел на сайт, посмотрел цену. Смысл побега из Крипто Про стал не совсем ясен.
BouncyCastle:
3к в год на организацию. И все.
На любом количестве виртуалок или докеров будет работать любое количество ЭЦП.
КриптоПро:
Лицензия на право использования СКЗИ «КриптоПро CSP» версии 5.0 на одном рабочем месте
Лицензия на рабочее место не позволит использовать КриптоПро CSP в среде серверных операционных систем 2700 Без НДС.
Лицензия на право использования СКЗИ «КриптоПро CSP» версии 5.0 на сервере 37500 Без НДС.
Разница по деньгам более чем на порядок.
Удобство
Разница в удобстве просто несравнима.
Один раз экспортнули и дальше везде типовой софт VS платная проприетарщина на каждом сервере.
СКЗИ «КриптоПро CSP» версии 5.0
насколько я знаю на данный момент она не сертифицирована, странно что они ее продают…
А вообще, ветер дует в сторону HSM. Там уже будет не обойтись без покупки лицензии.
BouncyCastle:
3к в год на организацию. И все.
Она же вроде под MIT идет?
Описанный вами сценарий применим в случае использования в каком-то внутреннем документообороте, где не важно, квалифицированная у вас подпись или нет.
К вопросу о цене. Что мешает вам найти УЦ, который выпускает ЭП под ViPNet CSP, или выпускает ЭП со вшитой лицензией для КриптоПРО?
Подписи получаются технически абсолютно валидные. Остальное к юристам. Я, как уже и говорил, не специалист в юридических вопросах.
VipNet не менее платный и не менее проприетарный чем КриптоПро. Соответственно с теми же проблемами. Как лицензировать и да и вообще как оно будет себя вести при автодеплое кучи инстансов непонятно. Да и платить за каждый сервер не очень идея.
.pfx файл. И он получается не совместимым ни с чем
правда чудесно быть монополистом?) (всякие лисси, агавы и прочее не конкуренты, единственный кто пытается посоперничать — випнет)
Подписи получаются технически абсолютно валидные
Я вам верю, но вряд-ли получится убедить в этом ФСБ
VipNet не менее платный и не менее проприетарный
VipNet CSP бесплатный. По поводу поведения при автодеплое — сталкивался с организациями, в которых ПО деловая почта, используя VipNet CSP, автопроцессингом подписывала и шифровала около 1000 писем в час. (такс… читаю что написал, и даже самому показалось что я топлю за випнет… нене, это не так)
И он получается не совместимым ни с чем. Претензия именно к этому. Раз делаете стандартное расширение используйте стандартный формат.
Предположу, что слово стандартный Вами и государством трактуется по разному. Вы ожидаете PKCS #12: Personal Information Exchange Syntax, а КриптоПро обязано соблюдать Р 50.1.112–2016 Транспортный ключевой контейнер
Подписи получаются технически абсолютно валидные
Строго говоря, да, технически, добросовестный пользователь с трудом сможет отличить одни подписи от других.
Однако если взглянуть на потенциальные каналы взаимодействия с нарушителем, то всё не так однозначно. Ясное дело, чисто формально не проведена сертификация КС1, КС2,… (помнится в начале 2000-х Волчков из ЛанКрипто бегал по всем форумам и площадкам за Репаном из Бифита (или наоборот) и доказывал на конкретных примерах и испытаниях, что Java криптография не так проста, как кажется)
Но и по сути, прошёл год, другой, срок действия закрытого ключа истёк, наверное надо что-то стереть. Вопрос что стереть и как стереть не так уж тривиален, как может показаться.
Может быть неизвлекаемым — да. Обязан — нет. Есть море вариантов когда документы надо подписывать на сервере без участия человека.
Например, выписки из любых гос реестров. Они должны быть подписаны, но участие человека в этом процессе не нужно.
Возьмем для примера простенький сервис. Он крутится на виртуалках в 3 разных ЦОДах. Цоды географически расположены в разных регионах. Сервис работает в рид онли режиме и формирует выписки из абстрактного реестра. Онлайн. Человек оплатил услугу, ему тут же упала выписка. Обновление реестра с задержкой в сутки нас устраивает, синхронизация тривиальна.
Как будем подписывать неизвлекаемым ключом? Сертификат, естественно, должен быть везде одинаковым.
Пользователь вообще не в курсе что там куча нод стоит. Не надо его нагружать лишней информацией.
Сертификаты разные. Пользователь запрашивает 2 одинаковые выписки и получает подписи с разными сертификатами. Пользователь негодует и начинает писать в техподдержку. Мол какой из них настоящий?
Hcm не взлетит. Он не совместим с виртуализацией, докерами и прочими автодеплоями нод.
Вот просто первые которые нашел.
crt.sh/?id=1214370195
crt.sh/?id=1214423012
Просто тут зависит от того что на этих подписях завязанно. Если это просто сайтик то тогда там естественно нет смысла в hsm.
И прокинуть hsm в докер не проблемма. Просто нода которая у вас отвечает за подпись будет всегда в в на конкретном сервере. Если мы говорим совсем про полностью облачную стуктуру, то тут вопрос в том, что на ключе этом завязанно, так-ка вы его посторонним отдаете. А если инфраструктура ваша, то воткнуть в сервер hsm не кажется большой проблеммой.
Посылк к тому, что спроектировать инфраструктуру сервиса с hsm на неизвлекаемых ключах вполне реально.
Спроектировать можно все. Только делать так не надо. Вылазит куча проблем и несовместимостей. Часть из которых вообще нерешаемы. Виртуалки гвоздями прибивать к железкам очень плохо. И конский прайс за все будет.
При этом плюсов ее видно. Злоумышленник получивший рут и так и так сможет все подписывать, а при обнаружении и так и так сертификат отзывается и перевыпускается. Одни минусы от железок.
Как будем подписывать неизвлекаемым ключом?
Эээээ… PKCS#11? Не, не слышал. Java с аппаратными токенами тоже умеет работать через JCE, насколько помню.
У вас токен с ключепарой. Он сам по себе может подписывать, шифровать, проверять. Это криптоустройство, а не тупая флэшка с хранением ключей.
Единственный минус — производительность. ruToken ГОСТ, афаик, пару секунд тратил на вычисление подписи файла в несколько килобайт.
Ну так для описанных случаев, как вам выше сказали — покупается сертифицированный HSM, и долбитесь в него как положено.
Всё уже придумано до вас.
Актуальная модель Рутокен ЭЦП 2.0 вычисляет подпись за 0.3сек, а аппаратно хэширует со скоростью порядка 100Кб\с. Есть и более быстрые модели — 0.1 секунды и 250Кб\с соответственно. Можно сделать и быстрее, но это просто никому не нужно.
Более быстрые модели нужны всегда. Скорость — это ресурс, его много не бывает.
Более быстрые модели нужны всегда
Рынок говорит об обратном. Люди просто не готовы платить лишние деньги за скорость.
Для личного использования скорости вашей Рутокен ЭЦП 2.0 хватает с головой. Продукт замечательный.
Для серверного использования любая железка для эцп получается плохой и неудобной. Хочется все программно делать.
И в итоге быстрые железки рынку действительно не нужны.
ps. Я, если что, абсолютно без наезда. Правда интересна Ваша позиция.
А что даст железка? Я реально не понимаю. Берем ваш Рутокен ЭЦП 2.0. Считаем что пин введен и сохранен заранее. Нам надо подписывать регулярно, каждый раз пин требовать пользователи взбунтуются. Процесс подписи выглядит ровно так же как и с BC. Берем буфер и отправляем его на подпись на токен. Получаем готовую подпись и сохраняем. Вся разница в том кто математику считает BC или железка. Ну и в том что токен можно вынуть и унести.
Подмена буфера выглядит одинаково при любом из двух процессов подписи. Он и в том и в другом случае успешно подпишется.
Дополнительная защита только в возможности вынуть токен физически. Для серверов она не применима.
Я, как разработчик, не участвую в прибылях и соответственно не беру на себя риски за потери.
Позиция понятно. Вот только бизнес в таких вопросах обычно не компетентен. И идет на поводу у разработчиков. А страдают потом пользователи. Вам на них, похоже, наплевать.
Я уже писал, что удобство и безопасность всегда противоречат друг другу. Мы даем средства, которые позволяют сделать безопасно. У нас есть тот же Рутокен ЭЦП PINPad, который защищает от подмены буфера.
Там суммы существенно больше 10 млн…
Увы в российских реалиях это не так работает.
Чтобы далеко за примером не ходить: У меня на полисе Е-ОСАГО написано что его выдал менеджер Иванов И.И. и транзакция в РСА наверняка была заверена его ЭЦП.
То что другие совершают ошибки реализации и делают проблемные системы, это не повод их копировать. Сами сетуете на то, что УЦ не умеют или не могут что-то сделать и одновременно продвигаете свои костыли. А где-то потом другой разработчик будет страдать.
1. ЭЦП, шифрование и СЗКИ это практичеки панацения от всех без в области защиты информации.
2. Работа с ПДн, договорами и т.д. в бизнесе это как работа с грифованными документами только в электронном виде.
Иначе такой результат мог выдать только сумрачный гений лоббирующий услуги УЦ =)
Резюмировл это ещё Виктор Степаныч: «Хотели как лучше, а получилось как всегда».
Судя по комментариям вы со СМЭВ не работали =)
Попробуйте прикинуть на примере крупного банка во сколько обойдется реализации идентификации клиентов по уприд с соблюдением духа и буквы соотв. законов, подзаконных актов и многочисленных регламентов и инструкций. А главное взвесте с ценностью, которую получит бизнес.
Подсказка, каждому оператору ПД (сиречь операционисту) понадобится ЭП-ОВ, рабочее место с СЗКИ и т.д. и тп… В этом случае без бумажки ты букашка, даже продлить такую ЭЦП удаленно без доставки бумажного заявления с подписью и печатью нельзя, даже когда ничего не менялось.
А проверку через уприд надо делать не раз в жизни клиента, ПОД-ФТ может по такой пьянке захотеть перестраховаться и проверять при оформлении каждого нового как минимум кредитного продукта, также минимум раз в год для каждого клиента (это уже требовния закона).
Сколько таких Ивановых потребуется для Сбера к примеру, сколько это будет стоить так чтобы уровень сервиса не просел?
Проблем много, я с этим не спорю. Писать комментарии на Хабре просто, что-то реально изменить — куда сложнее. ТК26 принимает желающих, только почему-то очереди туда вступить я не видел.
Воспринимайте систему не как исключительно техническую, но и охватите весь процесс целиком в котором присутствуют и люди.
Требуемое на практике усложнение и удорожание процедур работы с такими данными приводит к тому, что потребуется больше низкоквалицированных людей (вставить ключ, нажать несколько кнопок и ввести пин код ключа — вы же призываете понижать защищённость и отказываться от пинкода или упаси боже запоминать его?) и больше затрат на обеспечение их деятельности, чтобы полностью соблюсти все требования. В итоге первый кто будет выполнять все-все требования как вы за них пропагандируете, да ещё и будет перестраховываться в мутных нечётко сформулированных местах (а это практически best-practice в законодательстве) — сильно обрушит уровень обслуживания клиентов, повысит издержки на процесс и закономерно потеряет долю рынка или вообще вылетит.
Но самое печальное, что защищённости данных это не повысит, так как сейчас доминирующие каналы утечки ПДн — это люди. А людей в такой системе станет больше, они будут менее квалифицированы и менее оплачиваемы, соответственно, у них будет больше соблазнов подзаработать на сливе ПДн.
Т.е. по факту ухудшается и безопасность и удобство всей системы в целом.
Причем здесь ТК26? Я не говорю что стандарты криптографической защиты серии ГОСТ плохие, я говорю что регламенты и процедуры излишне усложнены и требования к мерам криптозащиты во многих местах неразумно завышены, также по факту навязывается не самая их лучшая реализация.
Как-то так кристаллизуются мои мысли по опыту работы со СМЭВ почти пару лет.
Не говоря уже про обычные косяки работы госзаказами и монополистами. Сначала правой рукой ставим сроки перехода на ГОСТ Р 34.10-2012, левой их срываем, для себя правой рукой подмахиваем поблажку, а проблемами обычных пользователей при этом особо никого не волнуют.
Сертификаты без проблем экспортируются в нормальные открытые форматы. Я не понимаю в чем проблема? openssl справится.
Проблема только с приватными ключами.
#!/bin/bash
end_date=`openssl x509 -noout -enddate -in name.cer | cut -d '=' -f 2`
if [ -n "$end_date" ]; then
end_date_seconds=`date '+%s' --date "$end_date"`
now_seconds=`date '+%s'`
echo "($end_date_seconds-$now_seconds)/86400" | bc
fi
В результате даст вам к-во дней до окончания сертификата.
Мой вопрос был как раз как перебрать и получить даты окончания срока действия из сертификатов лежащих ВНУТРИ контейнеров CRyptoPro.
Использовать ключ от чужого СКЗИ в отрыве от этого СКЗИ довольно странно: кто обеспечит контроль корректности его использования?
На вопрос «да что там использовать, берешь описание алгоритма да реализуешь» можете обратиться к простым материалам:
cryptopro.ru/blog/2014/08/25/nemnogo-ob-atakakh-po-pobochnym-kanalam
cryptopro.ru/blog/2017/05/17/o-nagruzke-na-klyuch-chast-1
cryptopro.ru/blog/2017/05/29/o-nagruzke-na-klyuch-chast-2
Получите ошибку, а не ожидаемый ответ.
Соответственно, не сможете проверить, а правильно ли всё реализовали.
Тогда не очень понятно следующее:
1) Автор предлагает выгрузить закрытый ключ, подпись которым обладает юридической значимостью, на десятки (сотни) машин? Если только на одну «эталонную» для тестирования, то опять же разницы между покупкой КриптоПро CSP и этой хакерской тулзы нет никакой. А если на огромное количество, как будет контролироваться то, что ключ никто не использует для «неподходящих» действий. Если бы для тестовой системы, которую разрабатывает моя компания, потребовалось положить на десятки машин мой ключ с квалифицированным сертификатом для Госуслуг, я бы, мягко говоря, остерёгся.
2) Почему нельзя приобрести ключ со встроенной в сертификат лицензией на CSP? Тогда не нужны кучи лицензий на машины.
3) Почему нельзя вести разработку с тестовым окружением (сделанный на коленке стенд, эмулирующий сервер), а затем уже доводить напильником на машине с легальным CSP?
1) Ну если строго следовать букве и духу то да, надо получать тысячи ключей и т.д.
А вас не напрягает необходимость подписывать вашей ЭЦП тысячи сообщений в час, где этапа подписи человеком вообще не должно быть? =)
2) CSP — это windows, который кстати при подключении рутокена на котором это ключ распространяется иногда начинает жутко тормозить и делает еще некоторые выкрутасы. Вы же покупате лицензию в составе ключа, как не нужна? :) Только платите не сразу а по факту за 2 года стоимость лицензий.
3) эм… Ну после таких предложений хочется поступить как поддержка смэв с ответом на любой конкретный вопрос и адресовать вас к документации, вас ждут там сюрпризы =) Готов поклониться 100 раз в ноги если быстро на коленке сделаете стенд эмулирующий сервер смэв, включая проверку реализации подписи согласно всем методическим материалам =)
Корень проблемы в другом. Есть в некоторых случаях весьма нагруженный обмен сервер — сервер, для которого какой-то сумрачный гений придумал требовать усиленную эцп на должностное лицо и соблюдать кучу других требований и прописал это в законах и подзаконных актах.
Такой порядок уместен для работы с секретными бумажками именно как бумажками, но не для случая работы ИС на потоке с большой нагрузкой.
gostcrypto.com/demo-cp-keys.html тоже умеет выдавать pfx файл. При этом, он делает это бесплатно.
На токен записан контейнер КриптоПро с приватным ключом и сертификатом. При экспорте ключа через CryptoPro CSP он экспортируется в особый «КриптоПро pfx» не совместимый ни с чем.
Вы правильно подметили, что на токен записывается особый не совместимый ни с чем контейнет. Хотя токен может быть настоящим токеном PKCS#11 с поддержкой российской криптографии, у которого стардартные механизмы, есть генерация ключа и т.д И людей создается иллюзия, что они используют токен, а на самом деле этот токен используется как обычная флэшка. И как показано в статье нет никаких проблем (в отличии от аппаратного токена) получить закрытый ключ.
Побег из Крипто Про. ГОСТ 34.10-2012 edition