Comments 88
Давайте я вместо юриста сразу проконсультирую:
63-ФЗ Статья 5. Виды электронных подписей пункт 4:
«Квалифицированной электронной подписью является электронная подпись, которая соответствует всем признакам неквалифицированной электронной подписи и следующим дополнительным признакам:
1) ключ проверки электронной подписи указан в квалифицированном сертификате;
2) для создания и проверки электронной подписи используются средства электронной подписи, имеющие подтверждение соответствия требованиям, установленным в соответствии с настоящим Федеральным законом.»
КриптоПро CSP таким средством электронной подписи является, Java KeyStore нет.
Эта схема конечно будет работать. Но первая же проверка может аннулировать все подписи, которые были выполнены этой системой.
63-ФЗ Статья 5. Виды электронных подписей пункт 4:
«Квалифицированной электронной подписью является электронная подпись, которая соответствует всем признакам неквалифицированной электронной подписи и следующим дополнительным признакам:
1) ключ проверки электронной подписи указан в квалифицированном сертификате;
2) для создания и проверки электронной подписи используются средства электронной подписи, имеющие подтверждение соответствия требованиям, установленным в соответствии с настоящим Федеральным законом.»
КриптоПро CSP таким средством электронной подписи является, Java KeyStore нет.
Эта схема конечно будет работать. Но первая же проверка может аннулировать все подписи, которые были выполнены этой системой.
А кто даст копаться в коде проприетарного проекта частной компании?
Я писал про юридическую сторону вопроса и последствия. Вы можете нарушать закон и скрывать это как угодно. Только факт нарушения это не отменяет. И от ответственности не освобождает.
Любой судья, если сочтет необходимым вынести такое решение. Представьте себе, что вам потребовалось подтвердить юридическую значимость подписи.
Что означает «имеющие подтверждение соответствия требованиям»?
Имеет сертификат ФСБ на соответствие требованиям к средствам криптографической защиты информации и средствам электронной подписи
Такое ощущение, что закон про соответствие требованиям имеет ввиду следующее.
Есть отсылка на некие требования к средствам электронной подписи.
Сами требования к средствам электронной подписи:
Т.е. специальное подтверждение нужно для гос.тайны, что логично.
Из всего этого проистекает, что нельзя использовать BC?
Прочие мысли вслух:
А если я подписал документ в помощью устройства, которое сейчас недоступно, и доказать что на том устройстве был КРиптоПро, подписал я с помощью КриптоПро у меня возможности нет. То все, подписанный документ нелегитимен?
И как доказать что документ подписан именно в BC, а не в КриптоПро?
Есть отсылка на некие требования к средствам электронной подписи.
для создания и проверки электронной подписи используются средства электронной подписи, имеющие подтверждение соответствия требованиям, установленным в соответствии с настоящим Федеральным законом.
Сами требования к средствам электронной подписи:
Статья 12. Средства электронной подписи
1. Для создания и проверки электронной подписи, создания ключа электронной подписи и ключа проверки электронной подписи должны использоваться средства электронной подписи, которые:
1) позволяют установить факт изменения подписанного электронного документа после момента его подписания;
2) обеспечивают практическую невозможность вычисления ключа электронной подписи из электронной подписи или из ключа ее проверки.
…
4. Средства электронной подписи, предназначенные для создания электронных подписей в электронных документах, содержащих сведения, составляющие государственную тайну, или предназначенные для использования в информационной системе, содержащей сведения, составляющие государственную тайну, подлежат подтверждению соответствия обязательным требованиям по защите сведений соответствующей степени секретности в соответствии с законодательством Российской Федерации. Средства электронной подписи, предназначенные для создания электронных подписей в электронных документах, содержащих информацию ограниченного доступа (в том числе персональные данные), не должны нарушать конфиденциальность такой информации.
Т.е. специальное подтверждение нужно для гос.тайны, что логично.
Из всего этого проистекает, что нельзя использовать BC?
Прочие мысли вслух:
А если я подписал документ в помощью устройства, которое сейчас недоступно, и доказать что на том устройстве был КРиптоПро, подписал я с помощью КриптоПро у меня возможности нет. То все, подписанный документ нелегитимен?
И как доказать что документ подписан именно в BC, а не в КриптоПро?
Требования, они так и называются. А Статья 12 требованиями не является.
Приказ ФСБ РФ от 27 декабря 2011 г. № 796 «Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра» — https://www.garant.ru/products/ipo/prime/doc/70039150/
Как именно будет действовать суд или регулятор я не берусь предсказывать. Могу только предположить. Так как СКЗИ в России подлежат учету, то Вам необходимо будет как минимум показать, что на Ваши паспортные данные записана лицензия сертифицированной версии того или иного СКЗИ.
Приказ ФСБ РФ от 27 декабря 2011 г. № 796 «Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра» — https://www.garant.ru/products/ipo/prime/doc/70039150/
Как именно будет действовать суд или регулятор я не берусь предсказывать. Могу только предположить. Так как СКЗИ в России подлежат учету, то Вам необходимо будет как минимум показать, что на Ваши паспортные данные записана лицензия сертифицированной версии того или иного СКЗИ.
Т.е. юридическая значимость эцп зависит от лицензии на скзи?
А используешь ли ты данный скзи для создания эцп, и не используешь — для юридической значимости эцп значения не имеет?
А используешь ли ты данный скзи для создания эцп, и не используешь — для юридической значимости эцп значения не имеет?
Конечно нет.
Я же написал, что это только мое предположение, с чего начнут проверку. Проверить наличие лицензии очень просто. И если ее нет, то уж точно было не сертифицированное СКЗИ. Если лицензия была, то можно уже копать дальше.
Ещё раз отмечу, как это будет происходить в реальной жизни я не знаю.
Я же написал, что это только мое предположение, с чего начнут проверку. Проверить наличие лицензии очень просто. И если ее нет, то уж точно было не сертифицированное СКЗИ. Если лицензия была, то можно уже копать дальше.
Ещё раз отмечу, как это будет происходить в реальной жизни я не знаю.
Ну давайте пофантазируем.
Вот два субъекта в судебном порядке выясняют между собой кто прав. Один (или оба, неважно) предоставляет электронный документ с электронной же подписью, под капотом которой ГОСТ. И прилагает еще лицензию о законном приобретении СКЗИ.
Как судья будет выяснять значимость представленного документа? Наверно судья пригласит эксперта в этой области. Пусть будет экспертом сотрудник какого-нибудь Всероссийского Национального Удостоверяющего Центра. Что будет делать данный эксперт с электронным документом и подписью? Наверно проведет экспертизу и вынесет официальным вердикт о соответствии документа подписи, и действительности сертификата подписанта в момент подписи.
Будет ли эксперт выяснять, а запускалось ли СКЗИ в момент подписания?
далее сугубо имхо.
Мне лично понятна идея для чего нужна сертификация СКЗИ. Ровно для того же, для чего нужна сертификация бытовой электроники. Чтобы у обывателей не возникало вопросов, а выполняет ли свою основную функцию продаваемое изделие. Я как обыватель совершенно не понимаю, а всем ли стандартам связи соответствует покупаемой мной мобильный телефон. Пусть специалисты в этой области выясняют это.
Но сертификация СКЗИ из средства защиты потребителей, превратилась в средство оказания давления на потребителей же.
У потребителя цель — получать юридически значимые электронные документы и подписи. Если на выходе документы валидны, то способ их получения становится вторичным.
(оставляем за скобками разные специфичные кейсы, вроде гостайн)
Вот два субъекта в судебном порядке выясняют между собой кто прав. Один (или оба, неважно) предоставляет электронный документ с электронной же подписью, под капотом которой ГОСТ. И прилагает еще лицензию о законном приобретении СКЗИ.
Как судья будет выяснять значимость представленного документа? Наверно судья пригласит эксперта в этой области. Пусть будет экспертом сотрудник какого-нибудь Всероссийского Национального Удостоверяющего Центра. Что будет делать данный эксперт с электронным документом и подписью? Наверно проведет экспертизу и вынесет официальным вердикт о соответствии документа подписи, и действительности сертификата подписанта в момент подписи.
Будет ли эксперт выяснять, а запускалось ли СКЗИ в момент подписания?
далее сугубо имхо.
Мне лично понятна идея для чего нужна сертификация СКЗИ. Ровно для того же, для чего нужна сертификация бытовой электроники. Чтобы у обывателей не возникало вопросов, а выполняет ли свою основную функцию продаваемое изделие. Я как обыватель совершенно не понимаю, а всем ли стандартам связи соответствует покупаемой мной мобильный телефон. Пусть специалисты в этой области выясняют это.
Но сертификация СКЗИ из средства защиты потребителей, превратилась в средство оказания давления на потребителей же.
У потребителя цель — получать юридически значимые электронные документы и подписи. Если на выходе документы валидны, то способ их получения становится вторичным.
(оставляем за скобками разные специфичные кейсы, вроде гостайн)
Вы ошибаетесь, на мой взгляд, с идеей сертификации СКЗИ. Это только не про выполнение основной функции, а про Вашу безопасность. Если грубо сравнить это как автомашина. Важна не только, чтобы она выполняла свои функции, но и не взрывалась в случайный момент с гибелью сотен людей вокруг. И это не менее важно, чем выполнения функции перевозки из одного места в другое. Именно поэтому даже если машина вас везет (документы валидны), то безопасность взрыва (способ получения) не становится вторичным.
Как правильно выше написали сертефикацией СКЗИ хотят обезопасить вас. Саму идея сертефикации СКЗИ я не точтобы сильно приветствую, но если бы она была реализованна адекватно то ее назначения понять можно.
Пример того что сертефикация СКЗИ могла бы делать(неуверен что она реально это делает): если взять подпись на эллиптической кривых. И у вас 1) есть возможность подписывать произвольные данные. 2) в реализации алгоритма подписи используется предсказуемый генератор случайных чисел то возможна утечка приватного ключа(привет PlayStation 3).
И возможно еще есть какието моменты.
Пример того что сертефикация СКЗИ могла бы делать(неуверен что она реально это делает): если взять подпись на эллиптической кривых. И у вас 1) есть возможность подписывать произвольные данные. 2) в реализации алгоритма подписи используется предсказуемый генератор случайных чисел то возможна утечка приватного ключа(привет PlayStation 3).
И возможно еще есть какието моменты.
Подпись произвольных данных это обычный юзкейс. Используется везде. docx это самые что ни на есть произвольные данные для любой библиотеки реализующей подпись.
Почитайте алгоритм подписи на эллиптической кривых. Я же специально в комментариях про них упомянул.
en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Signature_generation_algorithm
en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Signature_generation_algorithm
Основная проблема в том, что государство навязывает использование шифрования, ЭЦП и СЗКИ, часто там где это не нужно и излишне. А не оставляет этот вопрос на усмотрение бизнеса, сторон и т.д. Т.е. влезает с регулированием туда, куда не следует.
ПДн почти приравняли гостайне тихой сапой.
ПДн почти приравняли гостайне тихой сапой.
Сертификация — это хорошо.
Запрещать использовать без сертификации — плохо.
Например, продавать можно только сертифицированные холодильники.
Но не запрещенно эксплуатировать DIY холодильник.
Проводим аналогию.
Продавать можно только сертифицированные СКЗИ. Вроде все логично.
Но если очень хочется, можно эксплуатировать на свой страх и риск любые прочие СКЗИ, за исключением специальных случаев (например, уверен холодильники для лекарств должны быть со специальной сертификацией, никакой самодеятельности). Вроде тоже все логично.
Запрещать использовать без сертификации — плохо.
Например, продавать можно только сертифицированные холодильники.
Но не запрещенно эксплуатировать DIY холодильник.
Проводим аналогию.
Продавать можно только сертифицированные СКЗИ. Вроде все логично.
Но если очень хочется, можно эксплуатировать на свой страх и риск любые прочие СКЗИ, за исключением специальных случаев (например, уверен холодильники для лекарств должны быть со специальной сертификацией, никакой самодеятельности). Вроде тоже все логично.
Так сейчас так и есть. Хотите КЭП — только сертифицированные СКЗИ. Хотите, например, простую или усиленную подпись — используйте всё, что хотите. Хотите дома что-то шифровать — используйте всё, что хотите.
Хм. В кафе только сертифицированные холодильники, огнетушители и т.п., иначе могут быть (будут) проблемы. И это ж нормально, да?
Огнетушители, да, это как раз тот самый «специальный случай».
А насчет всего остального…
При открытии кафе действительно проверяют всякое: наличие места для хранения охлажденных и замороженных продуктов, вытяжка, жироуловитель, и прочее. Но это именно проверка на соответствие общим требованиям. Откуда холодильник — СЭС мало волнует.
А насчет всего остального…
При открытии кафе действительно проверяют всякое: наличие места для хранения охлажденных и замороженных продуктов, вытяжка, жироуловитель, и прочее. Но это именно проверка на соответствие общим требованиям. Откуда холодильник — СЭС мало волнует.
Идем на сайт авторов и покупаем новую.
Зашел на сайт, посмотрел цену. Смысл побега из Крипто Про стал не совсем ясен.
Деньги
BouncyCastle:
3к в год на организацию. И все.
На любом количестве виртуалок или докеров будет работать любое количество ЭЦП.
КриптоПро:
Лицензия на право использования СКЗИ «КриптоПро CSP» версии 5.0 на одном рабочем месте
Лицензия на рабочее место не позволит использовать КриптоПро CSP в среде серверных операционных систем 2700 Без НДС.
Лицензия на право использования СКЗИ «КриптоПро CSP» версии 5.0 на сервере 37500 Без НДС.
Разница по деньгам более чем на порядок.
Удобство
Разница в удобстве просто несравнима.
Один раз экспортнули и дальше везде типовой софт VS платная проприетарщина на каждом сервере.
BouncyCastle:
3к в год на организацию. И все.
На любом количестве виртуалок или докеров будет работать любое количество ЭЦП.
КриптоПро:
Лицензия на право использования СКЗИ «КриптоПро CSP» версии 5.0 на одном рабочем месте
Лицензия на рабочее место не позволит использовать КриптоПро CSP в среде серверных операционных систем 2700 Без НДС.
Лицензия на право использования СКЗИ «КриптоПро CSP» версии 5.0 на сервере 37500 Без НДС.
Разница по деньгам более чем на порядок.
Удобство
Разница в удобстве просто несравнима.
Один раз экспортнули и дальше везде типовой софт VS платная проприетарщина на каждом сервере.
СКЗИ «КриптоПро CSP» версии 5.0
насколько я знаю на данный момент она не сертифицирована, странно что они ее продают…
А вообще, ветер дует в сторону HSM. Там уже будет не обойтись без покупки лицензии.
BouncyCastle:
3к в год на организацию. И все.
Она же вроде под MIT идет?
Утилита для экпорта ключей P12FromGostCSP платная. Без нее совсем никак.
А что MIT? MIT даже не требует предоставлять исходные тексты (попробуй их ещё и собери, если (когда) получишь), а брать денежку за готовые производные продукты и GPL не запрещает ;)
я про BC а не про P12FromGostCSP писал.
А есть разница? Если у BC лицензия MIT, то никто не может мне, или кому ещё либо, запретить его продавать, тем более если я, или кто-то ещё, приделал к нему «ручку», документацию или просто обработал javac — имею право на продажу согласно лицензии MIT практически без каких-либо дополнительных обременений. Так что цена 3 к₽ — выглядит нормальной, на мой взгляд, конечно.
Вообще формат pfx по отношению к ГОСТ не совсем применим. К тому же КриптоПро в плане pfx на данный момент не придерживается рекомендации ТК26, потому контейнеры и нельзя использовать скажем в ViPNet CSP, который тоже поддерживает pfx. А стандартный контейнер под КриптоПРО CSP — это папка с 6 файлами вида exampl.000
Описанный вами сценарий применим в случае использования в каком-то внутреннем документообороте, где не важно, квалифицированная у вас подпись или нет.
К вопросу о цене. Что мешает вам найти УЦ, который выпускает ЭП под ViPNet CSP, или выпускает ЭП со вшитой лицензией для КриптоПРО?
Описанный вами сценарий применим в случае использования в каком-то внутреннем документообороте, где не важно, квалифицированная у вас подпись или нет.
К вопросу о цене. Что мешает вам найти УЦ, который выпускает ЭП под ViPNet CSP, или выпускает ЭП со вшитой лицензией для КриптоПРО?
Из КриптоПро CSP можно экспортировать ключ в .pfx файл. И он получается не совместимым ни с чем. Претензия именно к этому. Раз делаете стандартное расширение используйте стандартный формат.
Подписи получаются технически абсолютно валидные. Остальное к юристам. Я, как уже и говорил, не специалист в юридических вопросах.
VipNet не менее платный и не менее проприетарный чем КриптоПро. Соответственно с теми же проблемами. Как лицензировать и да и вообще как оно будет себя вести при автодеплое кучи инстансов непонятно. Да и платить за каждый сервер не очень идея.
Подписи получаются технически абсолютно валидные. Остальное к юристам. Я, как уже и говорил, не специалист в юридических вопросах.
VipNet не менее платный и не менее проприетарный чем КриптоПро. Соответственно с теми же проблемами. Как лицензировать и да и вообще как оно будет себя вести при автодеплое кучи инстансов непонятно. Да и платить за каждый сервер не очень идея.
.pfx файл. И он получается не совместимым ни с чем
правда чудесно быть монополистом?) (всякие лисси, агавы и прочее не конкуренты, единственный кто пытается посоперничать — випнет)
Подписи получаются технически абсолютно валидные
Я вам верю, но вряд-ли получится убедить в этом ФСБ
VipNet не менее платный и не менее проприетарный
VipNet CSP бесплатный. По поводу поведения при автодеплое — сталкивался с организациями, в которых ПО деловая почта, используя VipNet CSP, автопроцессингом подписывала и шифровала около 1000 писем в час. (такс… читаю что написал, и даже самому показалось что я топлю за випнет… нене, это не так)
И он получается не совместимым ни с чем. Претензия именно к этому. Раз делаете стандартное расширение используйте стандартный формат.
Предположу, что слово стандартный Вами и государством трактуется по разному. Вы ожидаете PKCS #12: Personal Information Exchange Syntax, а КриптоПро обязано соблюдать Р 50.1.112–2016 Транспортный ключевой контейнер
Подписи получаются технически абсолютно валидные
Строго говоря, да, технически, добросовестный пользователь с трудом сможет отличить одни подписи от других.
Однако если взглянуть на потенциальные каналы взаимодействия с нарушителем, то всё не так однозначно. Ясное дело, чисто формально не проведена сертификация КС1, КС2,… (помнится в начале 2000-х Волчков из ЛанКрипто бегал по всем форумам и площадкам за Репаном из Бифита (или наоборот) и доказывал на конкретных примерах и испытаниях, что Java криптография не так проста, как кажется)
Но и по сути, прошёл год, другой, срок действия закрытого ключа истёк, наверное надо что-то стереть. Вопрос что стереть и как стереть не так уж тривиален, как может показаться.
UFO just landed and posted this here
Должен. Но мечта каждого программиста положить его на сервер в pfx и подписывать все подряд потоком без просмотра. Им же потом не отвечать за деньги\имущество и прочее, что можно присвоить подписав левый документ КЭП
Может быть неизвлекаемым — да. Обязан — нет. Есть море вариантов когда документы надо подписывать на сервере без участия человека.
Например, выписки из любых гос реестров. Они должны быть подписаны, но участие человека в этом процессе не нужно.
А как связана извлекаемость ключа и возможность автоматического подписания?
Возьмем для примера простенький сервис. Он крутится на виртуалках в 3 разных ЦОДах. Цоды географически расположены в разных регионах. Сервис работает в рид онли режиме и формирует выписки из абстрактного реестра. Онлайн. Человек оплатил услугу, ему тут же упала выписка. Обновление реестра с задержкой в сутки нас устраивает, синхронизация тривиальна.
Как будем подписывать неизвлекаемым ключом? Сертификат, естественно, должен быть везде одинаковым.
Пользователь вообще не в курсе что там куча нод стоит. Не надо его нагружать лишней информацией.
А что мешает взять выпустить 3 сертефиката для разных приватных ключей. И в каждом цоде у вас будет свой hsm со свои приватным ключем. Это если у вас очень критично к отказоустойчивости и доступности. Если нет делаем сервис который просто подписывает то, что ему прислали.
Сертификаты разные. Пользователь запрашивает 2 одинаковые выписки и получает подписи с разными сертификатами. Пользователь негодует и начинает писать в техподдержку. Мол какой из них настоящий?
Hcm не взлетит. Он не совместим с виртуализацией, докерами и прочими автодеплоями нод.
А в чем проблемма то разных сертефикатов. У вас когда срок сертефиката заканчивается он у вас тоже другой. У вас в этих сертефикатов отличие будет только в публичном ключе. У тогоже гугла куча сертов которые отличаются только публиным ключем ну и немного временем выпуска.
Вот просто первые которые нашел.
crt.sh/?id=1214370195
crt.sh/?id=1214423012
Просто тут зависит от того что на этих подписях завязанно. Если это просто сайтик то тогда там естественно нет смысла в hsm.
И прокинуть hsm в докер не проблемма. Просто нода которая у вас отвечает за подпись будет всегда в в на конкретном сервере. Если мы говорим совсем про полностью облачную стуктуру, то тут вопрос в том, что на ключе этом завязанно, так-ка вы его посторонним отдаете. А если инфраструктура ваша, то воткнуть в сервер hsm не кажется большой проблеммой.
Посылк к тому, что спроектировать инфраструктуру сервиса с hsm на неизвлекаемых ключах вполне реально.
Вот просто первые которые нашел.
crt.sh/?id=1214370195
crt.sh/?id=1214423012
Просто тут зависит от того что на этих подписях завязанно. Если это просто сайтик то тогда там естественно нет смысла в hsm.
И прокинуть hsm в докер не проблемма. Просто нода которая у вас отвечает за подпись будет всегда в в на конкретном сервере. Если мы говорим совсем про полностью облачную стуктуру, то тут вопрос в том, что на ключе этом завязанно, так-ка вы его посторонним отдаете. А если инфраструктура ваша, то воткнуть в сервер hsm не кажется большой проблеммой.
Посылк к тому, что спроектировать инфраструктуру сервиса с hsm на неизвлекаемых ключах вполне реально.
Подавляющее большинство (если не все) российских УЦ не способны csr подписать. А вы от них космических технологий хотите.
Спроектировать можно все. Только делать так не надо. Вылазит куча проблем и несовместимостей. Часть из которых вообще нерешаемы. Виртуалки гвоздями прибивать к железкам очень плохо. И конский прайс за все будет.
При этом плюсов ее видно. Злоумышленник получивший рут и так и так сможет все подписывать, а при обнаружении и так и так сертификат отзывается и перевыпускается. Одни минусы от железок.
Спроектировать можно все. Только делать так не надо. Вылазит куча проблем и несовместимостей. Часть из которых вообще нерешаемы. Виртуалки гвоздями прибивать к железкам очень плохо. И конский прайс за все будет.
При этом плюсов ее видно. Злоумышленник получивший рут и так и так сможет все подписывать, а при обнаружении и так и так сертификат отзывается и перевыпускается. Одни минусы от железок.
Как будем подписывать неизвлекаемым ключом?
Эээээ… PKCS#11? Не, не слышал. Java с аппаратными токенами тоже умеет работать через JCE, насколько помню.
У вас токен с ключепарой. Он сам по себе может подписывать, шифровать, проверять. Это криптоустройство, а не тупая флэшка с хранением ключей.
Единственный минус — производительность. ruToken ГОСТ, афаик, пару секунд тратил на вычисление подписи файла в несколько килобайт.
Ну так для описанных случаев, как вам выше сказали — покупается сертифицированный HSM, и долбитесь в него как положено.
Всё уже придумано до вас.
Модели ruToken ГОСТ никогда не существовало, путаете с etoken.
Актуальная модель Рутокен ЭЦП 2.0 вычисляет подпись за 0.3сек, а аппаратно хэширует со скоростью порядка 100Кб\с. Есть и более быстрые модели — 0.1 секунды и 250Кб\с соответственно. Можно сделать и быстрее, но это просто никому не нужно.
Актуальная модель Рутокен ЭЦП 2.0 вычисляет подпись за 0.3сек, а аппаратно хэширует со скоростью порядка 100Кб\с. Есть и более быстрые модели — 0.1 секунды и 250Кб\с соответственно. Можно сделать и быстрее, но это просто никому не нужно.
Да, eToken. У меня как раз он, модель которая лет пять назад выдавалась в УЦ Ростелекома для доступа к Госуслугам.
Более быстрые модели нужны всегда. Скорость — это ресурс, его много не бывает.
Более быстрые модели нужны всегда. Скорость — это ресурс, его много не бывает.
Более быстрые модели нужны всегда
Рынок говорит об обратном. Люди просто не готовы платить лишние деньги за скорость.
Ну действительно а зачем платить больше?
Для личного использования скорости вашей Рутокен ЭЦП 2.0 хватает с головой. Продукт замечательный.
Для серверного использования любая железка для эцп получается плохой и неудобной. Хочется все программно делать.
И в итоге быстрые железки рынку действительно не нужны.
Для личного использования скорости вашей Рутокен ЭЦП 2.0 хватает с головой. Продукт замечательный.
Для серверного использования любая железка для эцп получается плохой и неудобной. Хочется все программно делать.
И в итоге быстрые железки рынку действительно не нужны.
Мне вот просто любопытно, Вы как разработчик системы, были бы готовы подписаться на личную финансовую ответственность за работу своей системы? Скажем когда вашей программе умелые люди подпихнут лишний документ на перевод 10 млн. с одного счета на другой, будете готовы компенсировать из своего кармана? Или Вы и правда считаете, что подменить в памяти один буфер на другой это большая проблема?
ps. Я, если что, абсолютно без наезда. Правда интересна Ваша позиция.
ps. Я, если что, абсолютно без наезда. Правда интересна Ваша позиция.
Я, как разработчик, не участвую в прибылях и соответственно не беру на себя риски за потери.
А что даст железка? Я реально не понимаю. Берем ваш Рутокен ЭЦП 2.0. Считаем что пин введен и сохранен заранее. Нам надо подписывать регулярно, каждый раз пин требовать пользователи взбунтуются. Процесс подписи выглядит ровно так же как и с BC. Берем буфер и отправляем его на подпись на токен. Получаем готовую подпись и сохраняем. Вся разница в том кто математику считает BC или железка. Ну и в том что токен можно вынуть и унести.
Подмена буфера выглядит одинаково при любом из двух процессов подписи. Он и в том и в другом случае успешно подпишется.
Дополнительная защита только в возможности вынуть токен физически. Для серверов она не применима.
А что даст железка? Я реально не понимаю. Берем ваш Рутокен ЭЦП 2.0. Считаем что пин введен и сохранен заранее. Нам надо подписывать регулярно, каждый раз пин требовать пользователи взбунтуются. Процесс подписи выглядит ровно так же как и с BC. Берем буфер и отправляем его на подпись на токен. Получаем готовую подпись и сохраняем. Вся разница в том кто математику считает BC или железка. Ну и в том что токен можно вынуть и унести.
Подмена буфера выглядит одинаково при любом из двух процессов подписи. Он и в том и в другом случае успешно подпишется.
Дополнительная защита только в возможности вынуть токен физически. Для серверов она не применима.
Я, как разработчик, не участвую в прибылях и соответственно не беру на себя риски за потери.
Позиция понятно. Вот только бизнес в таких вопросах обычно не компетентен. И идет на поводу у разработчиков. А страдают потом пользователи. Вам на них, похоже, наплевать.
Я уже писал, что удобство и безопасность всегда противоречат друг другу. Мы даем средства, которые позволяют сделать безопасно. У нас есть тот же Рутокен ЭЦП PINPad, который защищает от подмены буфера.
А как банки свои платежки между банками гоняют?
Там суммы существенно больше 10 млн…
Там суммы существенно больше 10 млн…
КЭП — это личная подпись. А выписки из любых гос.реестров по хорошему должны быть подписаны не лично человеком, а гос. органом. В этом случае КЭП не нужен.
Увы в российских реалиях это не так работает.
Чтобы далеко за примером не ходить: У меня на полисе Е-ОСАГО написано что его выдал менеджер Иванов И.И. и транзакция в РСА наверняка была заверена его ЭЦП.
Иванов И.И. видел, что подписывает ваш полис Е-ОСАГО, а не документы о продаже своей квартиры. И делалось это скорее всего не потоком, без его участия.
Ага, аж 2 раза видел. Именно в те 10 секунд которые прошли от момента оплаты до момента появления полиса в почте. Вроде взрослые люди, в сказки верить поздно уже.
То что другие совершают ошибки реализации и делают проблемные системы, это не повод их копировать. Сами сетуете на то, что УЦ не умеют или не могут что-то сделать и одновременно продвигаете свои костыли. А где-то потом другой разработчик будет страдать.
Разработчики таких систем вынуждены выкручиваться из иезуитских требований законодателей, регуляторов и экспертов у которых в голове похоже следующая каша:
1. ЭЦП, шифрование и СЗКИ это практичеки панацения от всех без в области защиты информации.
2. Работа с ПДн, договорами и т.д. в бизнесе это как работа с грифованными документами только в электронном виде.
Иначе такой результат мог выдать только сумрачный гений лоббирующий услуги УЦ =)
Резюмировл это ещё Виктор Степаныч: «Хотели как лучше, а получилось как всегда».
Судя по комментариям вы со СМЭВ не работали =)
Попробуйте прикинуть на примере крупного банка во сколько обойдется реализации идентификации клиентов по уприд с соблюдением духа и буквы соотв. законов, подзаконных актов и многочисленных регламентов и инструкций. А главное взвесте с ценностью, которую получит бизнес.
Подсказка, каждому оператору ПД (сиречь операционисту) понадобится ЭП-ОВ, рабочее место с СЗКИ и т.д. и тп… В этом случае без бумажки ты букашка, даже продлить такую ЭЦП удаленно без доставки бумажного заявления с подписью и печатью нельзя, даже когда ничего не менялось.
А проверку через уприд надо делать не раз в жизни клиента, ПОД-ФТ может по такой пьянке захотеть перестраховаться и проверять при оформлении каждого нового как минимум кредитного продукта, также минимум раз в год для каждого клиента (это уже требовния закона).
Сколько таких Ивановых потребуется для Сбера к примеру, сколько это будет стоить так чтобы уровень сервиса не просел?
1. ЭЦП, шифрование и СЗКИ это практичеки панацения от всех без в области защиты информации.
2. Работа с ПДн, договорами и т.д. в бизнесе это как работа с грифованными документами только в электронном виде.
Иначе такой результат мог выдать только сумрачный гений лоббирующий услуги УЦ =)
Резюмировл это ещё Виктор Степаныч: «Хотели как лучше, а получилось как всегда».
Судя по комментариям вы со СМЭВ не работали =)
Попробуйте прикинуть на примере крупного банка во сколько обойдется реализации идентификации клиентов по уприд с соблюдением духа и буквы соотв. законов, подзаконных актов и многочисленных регламентов и инструкций. А главное взвесте с ценностью, которую получит бизнес.
Подсказка, каждому оператору ПД (сиречь операционисту) понадобится ЭП-ОВ, рабочее место с СЗКИ и т.д. и тп… В этом случае без бумажки ты букашка, даже продлить такую ЭЦП удаленно без доставки бумажного заявления с подписью и печатью нельзя, даже когда ничего не менялось.
А проверку через уприд надо делать не раз в жизни клиента, ПОД-ФТ может по такой пьянке захотеть перестраховаться и проверять при оформлении каждого нового как минимум кредитного продукта, также минимум раз в год для каждого клиента (это уже требовния закона).
Сколько таких Ивановых потребуется для Сбера к примеру, сколько это будет стоить так чтобы уровень сервиса не просел?
Безопасность и удобство это всегда противоречащие друг друга требования. Вы хотите сделать удобно и небезопасно, и еще чтобы это небезопасно вам ФСБ разрешило. Так, очевидно, никогда не будет.
Проблем много, я с этим не спорю. Писать комментарии на Хабре просто, что-то реально изменить — куда сложнее. ТК26 принимает желающих, только почему-то очереди туда вступить я не видел.
Проблем много, я с этим не спорю. Писать комментарии на Хабре просто, что-то реально изменить — куда сложнее. ТК26 принимает желающих, только почему-то очереди туда вступить я не видел.
Ну вот про это я и писал в п1. — «панацея». Посмотрите более широко на проблему защиты скажем тех же персональных данных в банках / телекоме / фин. орг. и т.д. где много клиентов и нужно реализовать сценарии массового обслуживания.
Воспринимайте систему не как исключительно техническую, но и охватите весь процесс целиком в котором присутствуют и люди.
Требуемое на практике усложнение и удорожание процедур работы с такими данными приводит к тому, что потребуется больше низкоквалицированных людей (вставить ключ, нажать несколько кнопок и ввести пин код ключа — вы же призываете понижать защищённость и отказываться от пинкода или упаси боже запоминать его?) и больше затрат на обеспечение их деятельности, чтобы полностью соблюсти все требования. В итоге первый кто будет выполнять все-все требования как вы за них пропагандируете, да ещё и будет перестраховываться в мутных нечётко сформулированных местах (а это практически best-practice в законодательстве) — сильно обрушит уровень обслуживания клиентов, повысит издержки на процесс и закономерно потеряет долю рынка или вообще вылетит.
Но самое печальное, что защищённости данных это не повысит, так как сейчас доминирующие каналы утечки ПДн — это люди. А людей в такой системе станет больше, они будут менее квалифицированы и менее оплачиваемы, соответственно, у них будет больше соблазнов подзаработать на сливе ПДн.
Т.е. по факту ухудшается и безопасность и удобство всей системы в целом.
Причем здесь ТК26? Я не говорю что стандарты криптографической защиты серии ГОСТ плохие, я говорю что регламенты и процедуры излишне усложнены и требования к мерам криптозащиты во многих местах неразумно завышены, также по факту навязывается не самая их лучшая реализация.
Как-то так кристаллизуются мои мысли по опыту работы со СМЭВ почти пару лет.
Не говоря уже про обычные косяки работы госзаказами и монополистами. Сначала правой рукой ставим сроки перехода на ГОСТ Р 34.10-2012, левой их срываем, для себя правой рукой подмахиваем поблажку, а проблемами обычных пользователей при этом особо никого не волнуют.
Воспринимайте систему не как исключительно техническую, но и охватите весь процесс целиком в котором присутствуют и люди.
Требуемое на практике усложнение и удорожание процедур работы с такими данными приводит к тому, что потребуется больше низкоквалицированных людей (вставить ключ, нажать несколько кнопок и ввести пин код ключа — вы же призываете понижать защищённость и отказываться от пинкода или упаси боже запоминать его?) и больше затрат на обеспечение их деятельности, чтобы полностью соблюсти все требования. В итоге первый кто будет выполнять все-все требования как вы за них пропагандируете, да ещё и будет перестраховываться в мутных нечётко сформулированных местах (а это практически best-practice в законодательстве) — сильно обрушит уровень обслуживания клиентов, повысит издержки на процесс и закономерно потеряет долю рынка или вообще вылетит.
Но самое печальное, что защищённости данных это не повысит, так как сейчас доминирующие каналы утечки ПДн — это люди. А людей в такой системе станет больше, они будут менее квалифицированы и менее оплачиваемы, соответственно, у них будет больше соблазнов подзаработать на сливе ПДн.
Т.е. по факту ухудшается и безопасность и удобство всей системы в целом.
Причем здесь ТК26? Я не говорю что стандарты криптографической защиты серии ГОСТ плохие, я говорю что регламенты и процедуры излишне усложнены и требования к мерам криптозащиты во многих местах неразумно завышены, также по факту навязывается не самая их лучшая реализация.
Как-то так кристаллизуются мои мысли по опыту работы со СМЭВ почти пару лет.
Не говоря уже про обычные косяки работы госзаказами и монополистами. Сначала правой рукой ставим сроки перехода на ГОСТ Р 34.10-2012, левой их срываем, для себя правой рукой подмахиваем поблажку, а проблемами обычных пользователей при этом особо никого не волнуют.
А можно вопрос немного не в тему (просто увидел ключевые слова CryptoPro и сертификаты) — есть какой-нибудь простой способ из командной строки получить сроки валидности сертификатов из контейнеров Crypto Pro? Очень хочется в zabbix дату окончания сертификата запихнуть для мониторинга, а то пользователи за ними не смотрят, а потом децибеллы извергают ;-(
Сертификаты без проблем экспортируются в нормальные открытые форматы. Я не понимаю в чем проблема? openssl справится.
CryptoPro хранит все в своих специфических контейнерах. Способо экспортировать из этого контейнера в cer, например, я не нашел
Сертификат можно скопировать в стандартный .cer. И дальше можно делать с ним что угодно любым типовым ПО.
Проблема только с приватными ключами.
Проблема только с приватными ключами.
Чем? Вернее чем из командной строки? Приватные ключи мне не интересны. Вернее с ними как раз замечательно справилась стандартная криптопрошная тулза.
Как и написали — экспортируйте ручками через крипто-про CSP сам сертификат в name.cer, далее можно таким скриптиком в bash
#!/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
В результате даст вам к-во дней до окончания сертификата.
#!/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
В результате даст вам к-во дней до окончания сертификата.
ну я спрашивал про «простой» способ. А тут получается надо устанавливать сертификат в систему, прочитать дату, удалить. И так каждый день.
Почему каждый день? Если сертификат в систему импортировать, то потом его можно экспортировать как cer. Windows это вполне штатными средствами умеет. Насчет командной строки не помню (в mmc точно можно), но скорее всего certutil может.
У меня сертификаты в контейнерах для пол-сотни юрлиц. Обновляют их рядовые сотрудники когда их система (КриптоПро, Такском, 1С) спросит. А не спросит — не обновят. Так что там все меняется динамически мне надо как-то это контролировать.
Рядовые сотрудники в Windows все равно не смогут пользоваться контейнером пока не установят его в систему. Каждый день запускаете 1 раз certutil перебирая все сертификаты. Если у сертификата приближается срок действия — поднимаете сигнал. Если появился новый сертификат, когда его обновили, то как только его установят в систему, Вы будете и его мониторить.
Благополучно пользуются — контейнеры CryptoPro все подключены, а обновление сертификатов внутри контейнеров особых прав не требует. Для работы устанавливать эти сертификаты в систему не надо, их и не ставят.
Мой вопрос был как раз как перебрать и получить даты окончания срока действия из сертификатов лежащих ВНУТРИ контейнеров CRyptoPro.
Мой вопрос был как раз как перебрать и получить даты окончания срока действия из сертификатов лежащих ВНУТРИ контейнеров 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
Использовать ключ от чужого СКЗИ в отрыве от этого СКЗИ довольно странно: кто обеспечит контроль корректности его использования?
На вопрос «да что там использовать, берешь описание алгоритма да реализуешь» можете обратиться к простым материалам:
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) Автор предлагает выгрузить закрытый ключ, подпись которым обладает юридической значимостью, на десятки (сотни) машин? Если только на одну «эталонную» для тестирования, то опять же разницы между покупкой КриптоПро CSP и этой хакерской тулзы нет никакой. А если на огромное количество, как будет контролироваться то, что ключ никто не использует для «неподходящих» действий. Если бы для тестовой системы, которую разрабатывает моя компания, потребовалось положить на десятки машин мой ключ с квалифицированным сертификатом для Госуслуг, я бы, мягко говоря, остерёгся.
2) Почему нельзя приобрести ключ со встроенной в сертификат лицензией на CSP? Тогда не нужны кучи лицензий на машины.
3) Почему нельзя вести разработку с тестовым окружением (сделанный на коленке стенд, эмулирующий сервер), а затем уже доводить напильником на машине с легальным CSP?
Ну как документированным… В лучших традициях госзаказчиков. Неполно, неактуально, не для людей, зато формально по ГОСТ.
1) Ну если строго следовать букве и духу то да, надо получать тысячи ключей и т.д.
А вас не напрягает необходимость подписывать вашей ЭЦП тысячи сообщений в час, где этапа подписи человеком вообще не должно быть? =)
2) CSP — это windows, который кстати при подключении рутокена на котором это ключ распространяется иногда начинает жутко тормозить и делает еще некоторые выкрутасы. Вы же покупате лицензию в составе ключа, как не нужна? :) Только платите не сразу а по факту за 2 года стоимость лицензий.
3) эм… Ну после таких предложений хочется поступить как поддержка смэв с ответом на любой конкретный вопрос и адресовать вас к документации, вас ждут там сюрпризы =) Готов поклониться 100 раз в ноги если быстро на коленке сделаете стенд эмулирующий сервер смэв, включая проверку реализации подписи согласно всем методическим материалам =)
Корень проблемы в другом. Есть в некоторых случаях весьма нагруженный обмен сервер — сервер, для которого какой-то сумрачный гений придумал требовать усиленную эцп на должностное лицо и соблюдать кучу других требований и прописал это в законах и подзаконных актах.
Такой порядок уместен для работы с секретными бумажками именно как бумажками, но не для случая работы ИС на потоке с большой нагрузкой.
1) Ну если строго следовать букве и духу то да, надо получать тысячи ключей и т.д.
А вас не напрягает необходимость подписывать вашей ЭЦП тысячи сообщений в час, где этапа подписи человеком вообще не должно быть? =)
2) CSP — это windows, который кстати при подключении рутокена на котором это ключ распространяется иногда начинает жутко тормозить и делает еще некоторые выкрутасы. Вы же покупате лицензию в составе ключа, как не нужна? :) Только платите не сразу а по факту за 2 года стоимость лицензий.
3) эм… Ну после таких предложений хочется поступить как поддержка смэв с ответом на любой конкретный вопрос и адресовать вас к документации, вас ждут там сюрпризы =) Готов поклониться 100 раз в ноги если быстро на коленке сделаете стенд эмулирующий сервер смэв, включая проверку реализации подписи согласно всем методическим материалам =)
Корень проблемы в другом. Есть в некоторых случаях весьма нагруженный обмен сервер — сервер, для которого какой-то сумрачный гений придумал требовать усиленную эцп на должностное лицо и соблюдать кучу других требований и прописал это в законах и подзаконных актах.
Такой порядок уместен для работы с секретными бумажками именно как бумажками, но не для случая работы ИС на потоке с большой нагрузкой.
не в ту ветку — del
Разве обязательно использовать платный P12FromGostCSP?
gostcrypto.com/demo-cp-keys.html тоже умеет выдавать pfx файл. При этом, он делает это бесплатно.
gostcrypto.com/demo-cp-keys.html тоже умеет выдавать pfx файл. При этом, он делает это бесплатно.
Интересно все ли пользователи P12FromGostCSP извлекают ключ в изолированной среде?
На токен записан контейнер КриптоПро с приватным ключом и сертификатом. При экспорте ключа через CryptoPro CSP он экспортируется в особый «КриптоПро pfx» не совместимый ни с чем.
Вы правильно подметили, что на токен записывается особый не совместимый ни с чем контейнет. Хотя токен может быть настоящим токеном PKCS#11 с поддержкой российской криптографии, у которого стардартные механизмы, есть генерация ключа и т.д И людей создается иллюзия, что они используют токен, а на самом деле этот токен используется как обычная флэшка. И как показано в статье нет никаких проблем (в отличии от аппаратного токена) получить закрытый ключ.
Sign up to leave a comment.
Побег из Крипто Про. ГОСТ 34.10-2012 edition