Под катом рассказ как можно модифицировать свой софт на Bouncy Castle для поддержки работы с ключами по новым гостам.
Disclaimer
О юридических тонкостях подписывания документов через Bouncy Castle и прочих СКЗИ я ничего не знаю и общаться не готов. Перед использованием кода в продакшене проконсультируйтесь с юристом.
А зачем это вообще надо? хорошо написанно оригинальной статье. Повторяться не буду.
Получение ключа с Токена
Все известные мне УЦ выдают ключи с сертификатами на подобных токенах. На токен записан контейнер КриптоПро с приватным ключом и сертификатом. При экспорте ключа через CryptoPro CSP он экспортируется в особый «КриптоПро pfx» не совместимый ни с чем.
Просьбы выдать ключ в стандартном pfx или любом другом типовом контейнере УЦ игнорируют.
Если кто знает УЦ выдающие подписи в стандартных контейнерах поделитесь координатами в комментариях. Хороших людей не стыдно попиарить.
Для преобразования контейнера КриптоПро в стандартный pfx мы как и в оригинальной статье будем использовать P12FromGostCSP. Старые взломанные версии не работают с ключами по 2012 Госту. Идем на сайт авторов и покупаем новую.
Итак мы получили стандартный pfx с ключом и сертификатом.
Обновление Bouncy Castle
Обновляем Bouncy Castle до 1.60 Старые версии могут не поддерживать алгоритмы ГОСТ 2012.
<dependency>
<groupId>org.bouncycastle</groupId>
<artifactId>bcprov-jdk15on</artifactId>
<version>1.60</version>
</dependency>
<dependency>
<groupId>org.bouncycastle</groupId>
<artifactId>bcpkix-jdk15on</artifactId>
<version>1.60</version>
</dependency>
Инициализация Bouncy Castle
static {
BouncyCastleProvider bcProvider = new BouncyCastleProvider();
String name = bcProvider.getName();
Security.removeProvider(name); // remove old instance
Security.addProvider(bcProvider);
}
Разбор pfx
KeyStore keyStore = KeyStore.getInstance("PKCS12", "BC");
ByteArrayInputStream baos = new ByteArrayInputStream(pfxFileContent);
keyStore.load(baos, password.toCharArray());
Enumeration<String> aliases = keyStore.aliases();
while (aliases.hasMoreElements()) {
String alias = aliases.nextElement();
if (keyStore.isKeyEntry(alias )) {
Key key = keyStore.getKey(alias , keyPassword.toCharArray());
java.security.cert.Certificate certificate = keyStore.getCertificate(alias );
addKeyAndCertificateToStore((PrivateKey)key, (X509Certificate)certificate);
}
}Алиасы обязательно изменяем. Утилита P12FromGostCSP задает всегда один и тот же алиас «csp_exported» и при обработке уже второго ключа будут проблемы.
Для удобства работы ключ из pfx необходимо загрузить в стандартный Java KeyStore и дальше работать только с ним.
Загрузка KeyStore
FileInputStream is = new FileInputStream(keystorePath);
keystore = KeyStore.getInstance(KeyStore.getDefaultType());
char[] passwd = keystorePassword.toCharArray();
keystore.load(is, passwd);Сохранение ключа с сертификатом в KeyStore
public void addKeyAndCertificateToStore(PrivateKey key, X509Certificate certificate) {
synchronized (this) {
keystore.setKeyEntry(alias.toLowerCase(), key, keyPassword.toCharArray(), new X509Certificate[] {certificate});
FileOutputStream out = new FileOutputStream(keystorePath);
keystore.store(out, keystorePassword.toCharArray());
out.close();
}
}
Загрузка ключей и сертификатов из KeyStore
Enumeration<String> aliases = keystore.aliases();
while (aliases.hasMoreElements()) {
String alias = aliases.nextElement();
if (keystore.isKeyEntry(alias)) {
Key key = keystore.getKey(alias, keyPassword.toCharArray());
keys.put(alias.toLowerCase(), key); //any key,value collection
Certificate certificate = keystore.getCertificate(alias);
if (certificate instanceof X509Certificate)
certificates.put(alias.toLowerCase(), (X509Certificate) certificate); //any key,value collection
}
}Подпись файла
CMSProcessableByteArray msg = new CMSProcessableByteArray(dataToSign);
List certList = new ArrayList();
certList.add(cert);
Store certs = new JcaCertStore(certList);
CMSSignedDataGenerator gen = new CMSSignedDataGenerator();
ContentSigner signer = new org.bouncycastle.operator.jcajce.JcaContentSignerBuilder("GOST3411WITHECGOST3410-2012-256").setProvider("BC").build(privateKey);
gen.addSignerInfoGenerator(new JcaSignerInfoGeneratorBuilder(new JcaDigestCalculatorProviderBuilder().setProvider("BC").build()).build(signer, certificate));
gen.addCertificates(certs);
CMSSignedData sigData = gen.generate(msg, false);
byte[] sign = sigData.getEncoded(); //result here
Есть вариант JcaContentSignerBuilder(«GOST3411WITHECGOST3410-2012-512») для 512 битовых ключей. Мои УЦ выдают 256 битные ничего не спрашивая и игнорируют уточняющие вопросы.
Проверка подписи
byte[] data = ...; //signed file data
byte[] signature = ...;//signature
boolean checkResult = false;
CMSProcessable signedContent = new CMSProcessableByteArray(data);
CMSSignedData signedData;
try {
signedData = new CMSSignedData(signedContent, signature);
} catch (CMSException e) {
return SIGNATURE_STATUS.ERROR;
}
SignerInformation signer;
try {
Store<X509CertificateHolder> certStoreInSing = signedData.getCertificates();
signer = signedData.getSignerInfos().getSigners().iterator().next();
Collection certCollection = certStoreInSing.getMatches(signer.getSID());
Iterator certIt = certCollection.iterator();
X509CertificateHolder certHolder = (X509CertificateHolder) certIt.next();
X509Certificate certificate = new JcaX509CertificateConverter().getCertificate(certHolder);
checkResult = signer.verify(new JcaSimpleSignerInfoVerifierBuilder().build(certificate));
} catch (Exception ex) {
return SIGNATURE_STATUS.ERROR;
}
Проверка подписи полностью аналогична проверке по Госту 2001 года. Можно ничего не менять.
Резюме
В результате всех вышеописанных действий мы получили относительно легий способ избавиться от тяжкой ноши Крипто Про в 2019 году.
Комментарии (72)
leveler
19.02.2019 17:00Идем на сайт авторов и покупаем новую.
Зашел на сайт, посмотрел цену. Смысл побега из Крипто Про стал не совсем ясен.
BugM Автор
19.02.2019 17:25Деньги
BouncyCastle:
3к в год на организацию. И все.
На любом количестве виртуалок или докеров будет работать любое количество ЭЦП.
КриптоПро:
Лицензия на право использования СКЗИ «КриптоПро CSP» версии 5.0 на одном рабочем месте
Лицензия на рабочее место не позволит использовать КриптоПро CSP в среде серверных операционных систем 2700 Без НДС.
Лицензия на право использования СКЗИ «КриптоПро CSP» версии 5.0 на сервере 37500 Без НДС.
Разница по деньгам более чем на порядок.
Удобство
Разница в удобстве просто несравнима.
Один раз экспортнули и дальше везде типовой софт VS платная проприетарщина на каждом сервере.
insomnium-r
19.02.2019 17:48СКЗИ «КриптоПро CSP» версии 5.0
насколько я знаю на данный момент она не сертифицирована, странно что они ее продают…
А вообще, ветер дует в сторону HSM. Там уже будет не обойтись без покупки лицензии.
insomnium-r
19.02.2019 17:35Вообще формат pfx по отношению к ГОСТ не совсем применим. К тому же КриптоПро в плане pfx на данный момент не придерживается рекомендации ТК26, потому контейнеры и нельзя использовать скажем в ViPNet CSP, который тоже поддерживает pfx. А стандартный контейнер под КриптоПРО CSP — это папка с 6 файлами вида exampl.000
Описанный вами сценарий применим в случае использования в каком-то внутреннем документообороте, где не важно, квалифицированная у вас подпись или нет.
К вопросу о цене. Что мешает вам найти УЦ, который выпускает ЭП под ViPNet CSP, или выпускает ЭП со вшитой лицензией для КриптоПРО?BugM Автор
19.02.2019 17:49Из КриптоПро CSP можно экспортировать ключ в .pfx файл. И он получается не совместимым ни с чем. Претензия именно к этому. Раз делаете стандартное расширение используйте стандартный формат.
Подписи получаются технически абсолютно валидные. Остальное к юристам. Я, как уже и говорил, не специалист в юридических вопросах.
VipNet не менее платный и не менее проприетарный чем КриптоПро. Соответственно с теми же проблемами. Как лицензировать и да и вообще как оно будет себя вести при автодеплое кучи инстансов непонятно. Да и платить за каждый сервер не очень идея.insomnium-r
19.02.2019 18:05.pfx файл. И он получается не совместимым ни с чем
правда чудесно быть монополистом?) (всякие лисси, агавы и прочее не конкуренты, единственный кто пытается посоперничать — випнет)
Подписи получаются технически абсолютно валидные
Я вам верю, но вряд-ли получится убедить в этом ФСБ
VipNet не менее платный и не менее проприетарный
VipNet CSP бесплатный. По поводу поведения при автодеплое — сталкивался с организациями, в которых ПО деловая почта, используя VipNet CSP, автопроцессингом подписывала и шифровала около 1000 писем в час. (такс… читаю что написал, и даже самому показалось что я топлю за випнет… нене, это не так)
Neraverin
19.02.2019 19:52И он получается не совместимым ни с чем. Претензия именно к этому. Раз делаете стандартное расширение используйте стандартный формат.
Предположу, что слово стандартный Вами и государством трактуется по разному. Вы ожидаете PKCS #12: Personal Information Exchange Syntax, а КриптоПро обязано соблюдать Р 50.1.112–2016 Транспортный ключевой контейнер
Serge3leo
20.02.2019 14:24Подписи получаются технически абсолютно валидные
Строго говоря, да, технически, добросовестный пользователь с трудом сможет отличить одни подписи от других.
Однако если взглянуть на потенциальные каналы взаимодействия с нарушителем, то всё не так однозначно. Ясное дело, чисто формально не проведена сертификация КС1, КС2,… (помнится в начале 2000-х Волчков из ЛанКрипто бегал по всем форумам и площадкам за Репаном из Бифита (или наоборот) и доказывал на конкретных примерах и испытаниях, что Java криптография не так проста, как кажется)
Но и по сути, прошёл год, другой, срок действия закрытого ключа истёк, наверное надо что-то стереть. Вопрос что стереть и как стереть не так уж тривиален, как может показаться.
Igorjan
19.02.2019 19:33+1Разве закрытый ключ не должен быть неизвлекаемым?
Neraverin
19.02.2019 19:43+1Должен. Но мечта каждого программиста положить его на сервер в pfx и подписывать все подряд потоком без просмотра. Им же потом не отвечать за деньги\имущество и прочее, что можно присвоить подписав левый документ КЭП
BugM Автор
19.02.2019 19:58+1Может быть неизвлекаемым — да. Обязан — нет. Есть море вариантов когда документы надо подписывать на сервере без участия человека.
Например, выписки из любых гос реестров. Они должны быть подписаны, но участие человека в этом процессе не нужно.
a1ien_n3t
19.02.2019 20:01А как связана извлекаемость ключа и возможность автоматического подписания?
BugM Автор
19.02.2019 20:12Возьмем для примера простенький сервис. Он крутится на виртуалках в 3 разных ЦОДах. Цоды географически расположены в разных регионах. Сервис работает в рид онли режиме и формирует выписки из абстрактного реестра. Онлайн. Человек оплатил услугу, ему тут же упала выписка. Обновление реестра с задержкой в сутки нас устраивает, синхронизация тривиальна.
Как будем подписывать неизвлекаемым ключом? Сертификат, естественно, должен быть везде одинаковым.
Пользователь вообще не в курсе что там куча нод стоит. Не надо его нагружать лишней информацией.
a1ien_n3t
19.02.2019 20:28А что мешает взять выпустить 3 сертефиката для разных приватных ключей. И в каждом цоде у вас будет свой hsm со свои приватным ключем. Это если у вас очень критично к отказоустойчивости и доступности. Если нет делаем сервис который просто подписывает то, что ему прислали.
BugM Автор
19.02.2019 20:33Сертификаты разные. Пользователь запрашивает 2 одинаковые выписки и получает подписи с разными сертификатами. Пользователь негодует и начинает писать в техподдержку. Мол какой из них настоящий?
Hcm не взлетит. Он не совместим с виртуализацией, докерами и прочими автодеплоями нод.
a1ien_n3t
19.02.2019 21:07А в чем проблемма то разных сертефикатов. У вас когда срок сертефиката заканчивается он у вас тоже другой. У вас в этих сертефикатов отличие будет только в публичном ключе. У тогоже гугла куча сертов которые отличаются только публиным ключем ну и немного временем выпуска.
Вот просто первые которые нашел.
crt.sh/?id=1214370195
crt.sh/?id=1214423012
Просто тут зависит от того что на этих подписях завязанно. Если это просто сайтик то тогда там естественно нет смысла в hsm.
И прокинуть hsm в докер не проблемма. Просто нода которая у вас отвечает за подпись будет всегда в в на конкретном сервере. Если мы говорим совсем про полностью облачную стуктуру, то тут вопрос в том, что на ключе этом завязанно, так-ка вы его посторонним отдаете. А если инфраструктура ваша, то воткнуть в сервер hsm не кажется большой проблеммой.
Посылк к тому, что спроектировать инфраструктуру сервиса с hsm на неизвлекаемых ключах вполне реально.BugM Автор
19.02.2019 21:22Подавляющее большинство (если не все) российских УЦ не способны csr подписать. А вы от них космических технологий хотите.
Спроектировать можно все. Только делать так не надо. Вылазит куча проблем и несовместимостей. Часть из которых вообще нерешаемы. Виртуалки гвоздями прибивать к железкам очень плохо. И конский прайс за все будет.
При этом плюсов ее видно. Злоумышленник получивший рут и так и так сможет все подписывать, а при обнаружении и так и так сертификат отзывается и перевыпускается. Одни минусы от железок.
ne_kotin
19.02.2019 21:45Как будем подписывать неизвлекаемым ключом?
Эээээ… PKCS#11? Не, не слышал. Java с аппаратными токенами тоже умеет работать через JCE, насколько помню.
У вас токен с ключепарой. Он сам по себе может подписывать, шифровать, проверять. Это криптоустройство, а не тупая флэшка с хранением ключей.
Единственный минус — производительность. ruToken ГОСТ, афаик, пару секунд тратил на вычисление подписи файла в несколько килобайт.
Ну так для описанных случаев, как вам выше сказали — покупается сертифицированный HSM, и долбитесь в него как положено.
Всё уже придумано до вас.Neraverin
20.02.2019 10:00Модели ruToken ГОСТ никогда не существовало, путаете с etoken.
Актуальная модель Рутокен ЭЦП 2.0 вычисляет подпись за 0.3сек, а аппаратно хэширует со скоростью порядка 100Кб\с. Есть и более быстрые модели — 0.1 секунды и 250Кб\с соответственно. Можно сделать и быстрее, но это просто никому не нужно.ne_kotin
20.02.2019 12:59Да, eToken. У меня как раз он, модель которая лет пять назад выдавалась в УЦ Ростелекома для доступа к Госуслугам.
Более быстрые модели нужны всегда. Скорость — это ресурс, его много не бывает.Neraverin
20.02.2019 13:23Более быстрые модели нужны всегда
Рынок говорит об обратном. Люди просто не готовы платить лишние деньги за скорость.BugM Автор
20.02.2019 13:36Ну действительно а зачем платить больше?
Для личного использования скорости вашей Рутокен ЭЦП 2.0 хватает с головой. Продукт замечательный.
Для серверного использования любая железка для эцп получается плохой и неудобной. Хочется все программно делать.
И в итоге быстрые железки рынку действительно не нужны.Neraverin
20.02.2019 13:40Мне вот просто любопытно, Вы как разработчик системы, были бы готовы подписаться на личную финансовую ответственность за работу своей системы? Скажем когда вашей программе умелые люди подпихнут лишний документ на перевод 10 млн. с одного счета на другой, будете готовы компенсировать из своего кармана? Или Вы и правда считаете, что подменить в памяти один буфер на другой это большая проблема?
ps. Я, если что, абсолютно без наезда. Правда интересна Ваша позиция.BugM Автор
20.02.2019 13:55Я, как разработчик, не участвую в прибылях и соответственно не беру на себя риски за потери.
А что даст железка? Я реально не понимаю. Берем ваш Рутокен ЭЦП 2.0. Считаем что пин введен и сохранен заранее. Нам надо подписывать регулярно, каждый раз пин требовать пользователи взбунтуются. Процесс подписи выглядит ровно так же как и с BC. Берем буфер и отправляем его на подпись на токен. Получаем готовую подпись и сохраняем. Вся разница в том кто математику считает BC или железка. Ну и в том что токен можно вынуть и унести.
Подмена буфера выглядит одинаково при любом из двух процессов подписи. Он и в том и в другом случае успешно подпишется.
Дополнительная защита только в возможности вынуть токен физически. Для серверов она не применима.Neraverin
20.02.2019 14:12Я, как разработчик, не участвую в прибылях и соответственно не беру на себя риски за потери.
Позиция понятно. Вот только бизнес в таких вопросах обычно не компетентен. И идет на поводу у разработчиков. А страдают потом пользователи. Вам на них, похоже, наплевать.
Я уже писал, что удобство и безопасность всегда противоречат друг другу. Мы даем средства, которые позволяют сделать безопасно. У нас есть тот же Рутокен ЭЦП PINPad, который защищает от подмены буфера.BugM Автор
20.02.2019 14:27Мы говорим про использование на серверах.
Там по определению жать кнопочку на устройстве некому.
Для работы у пользователей вариант интересный. А как именно он визуализирует? Подписываем pdf или docx или вообще xml. Что он будет отображать?
ggo
20.02.2019 14:51А как банки свои платежки между банками гоняют?
Там суммы существенно больше 10 млн…
Neraverin
19.02.2019 20:05КЭП — это личная подпись. А выписки из любых гос.реестров по хорошему должны быть подписаны не лично человеком, а гос. органом. В этом случае КЭП не нужен.
BugM Автор
19.02.2019 20:30Увы в российских реалиях это не так работает.
Чтобы далеко за примером не ходить: У меня на полисе Е-ОСАГО написано что его выдал менеджер Иванов И.И. и транзакция в РСА наверняка была заверена его ЭЦП.Neraverin
19.02.2019 21:23Иванов И.И. видел, что подписывает ваш полис Е-ОСАГО, а не документы о продаже своей квартиры. И делалось это скорее всего не потоком, без его участия.
BugM Автор
19.02.2019 21:33+1Ага, аж 2 раза видел. Именно в те 10 секунд которые прошли от момента оплаты до момента появления полиса в почте. Вроде взрослые люди, в сказки верить поздно уже.
Neraverin
19.02.2019 21:46То что другие совершают ошибки реализации и делают проблемные системы, это не повод их копировать. Сами сетуете на то, что УЦ не умеют или не могут что-то сделать и одновременно продвигаете свои костыли. А где-то потом другой разработчик будет страдать.
astralNord
20.02.2019 13:17Разработчики таких систем вынуждены выкручиваться из иезуитских требований законодателей, регуляторов и экспертов у которых в голове похоже следующая каша:
1. ЭЦП, шифрование и СЗКИ это практичеки панацения от всех без в области защиты информации.
2. Работа с ПДн, договорами и т.д. в бизнесе это как работа с грифованными документами только в электронном виде.
Иначе такой результат мог выдать только сумрачный гений лоббирующий услуги УЦ =)
Резюмировл это ещё Виктор Степаныч: «Хотели как лучше, а получилось как всегда».
Судя по комментариям вы со СМЭВ не работали =)
Попробуйте прикинуть на примере крупного банка во сколько обойдется реализации идентификации клиентов по уприд с соблюдением духа и буквы соотв. законов, подзаконных актов и многочисленных регламентов и инструкций. А главное взвесте с ценностью, которую получит бизнес.
Подсказка, каждому оператору ПД (сиречь операционисту) понадобится ЭП-ОВ, рабочее место с СЗКИ и т.д. и тп… В этом случае без бумажки ты букашка, даже продлить такую ЭЦП удаленно без доставки бумажного заявления с подписью и печатью нельзя, даже когда ничего не менялось.
А проверку через уприд надо делать не раз в жизни клиента, ПОД-ФТ может по такой пьянке захотеть перестраховаться и проверять при оформлении каждого нового как минимум кредитного продукта, также минимум раз в год для каждого клиента (это уже требовния закона).
Сколько таких Ивановых потребуется для Сбера к примеру, сколько это будет стоить так чтобы уровень сервиса не просел?Neraverin
20.02.2019 13:31Безопасность и удобство это всегда противоречащие друг друга требования. Вы хотите сделать удобно и небезопасно, и еще чтобы это небезопасно вам ФСБ разрешило. Так, очевидно, никогда не будет.
Проблем много, я с этим не спорю. Писать комментарии на Хабре просто, что-то реально изменить — куда сложнее. ТК26 принимает желающих, только почему-то очереди туда вступить я не видел.astralNord
20.02.2019 14:28Ну вот про это я и писал в п1. — «панацея». Посмотрите более широко на проблему защиты скажем тех же персональных данных в банках / телекоме / фин. орг. и т.д. где много клиентов и нужно реализовать сценарии массового обслуживания.
Воспринимайте систему не как исключительно техническую, но и охватите весь процесс целиком в котором присутствуют и люди.
Требуемое на практике усложнение и удорожание процедур работы с такими данными приводит к тому, что потребуется больше низкоквалицированных людей (вставить ключ, нажать несколько кнопок и ввести пин код ключа — вы же призываете понижать защищённость и отказываться от пинкода или упаси боже запоминать его?) и больше затрат на обеспечение их деятельности, чтобы полностью соблюсти все требования. В итоге первый кто будет выполнять все-все требования как вы за них пропагандируете, да ещё и будет перестраховываться в мутных нечётко сформулированных местах (а это практически best-practice в законодательстве) — сильно обрушит уровень обслуживания клиентов, повысит издержки на процесс и закономерно потеряет долю рынка или вообще вылетит.
Но самое печальное, что защищённости данных это не повысит, так как сейчас доминирующие каналы утечки ПДн — это люди. А людей в такой системе станет больше, они будут менее квалифицированы и менее оплачиваемы, соответственно, у них будет больше соблазнов подзаработать на сливе ПДн.
Т.е. по факту ухудшается и безопасность и удобство всей системы в целом.
Причем здесь ТК26? Я не говорю что стандарты криптографической защиты серии ГОСТ плохие, я говорю что регламенты и процедуры излишне усложнены и требования к мерам криптозащиты во многих местах неразумно завышены, также по факту навязывается не самая их лучшая реализация.
Как-то так кристаллизуются мои мысли по опыту работы со СМЭВ почти пару лет.
Не говоря уже про обычные косяки работы госзаказами и монополистами. Сначала правой рукой ставим сроки перехода на ГОСТ Р 34.10-2012, левой их срываем, для себя правой рукой подмахиваем поблажку, а проблемами обычных пользователей при этом особо никого не волнуют.
DonAlPAtino
19.02.2019 20:05+1А можно вопрос немного не в тему (просто увидел ключевые слова CryptoPro и сертификаты) — есть какой-нибудь простой способ из командной строки получить сроки валидности сертификатов из контейнеров Crypto Pro? Очень хочется в zabbix дату окончания сертификата запихнуть для мониторинга, а то пользователи за ними не смотрят, а потом децибеллы извергают ;-(
BugM Автор
19.02.2019 20:35Сертификаты без проблем экспортируются в нормальные открытые форматы. Я не понимаю в чем проблема? openssl справится.
DonAlPAtino
20.02.2019 10:22CryptoPro хранит все в своих специфических контейнерах. Способо экспортировать из этого контейнера в cer, например, я не нашел
BugM Автор
20.02.2019 13:20Сертификат можно скопировать в стандартный .cer. И дальше можно делать с ним что угодно любым типовым ПО.
Проблема только с приватными ключами.DonAlPAtino
20.02.2019 14:18Чем? Вернее чем из командной строки? Приватные ключи мне не интересны. Вернее с ними как раз замечательно справилась стандартная криптопрошная тулза.
astralNord
20.02.2019 14:38Как и написали — экспортируйте ручками через крипто-про 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
В результате даст вам к-во дней до окончания сертификата.
Neraverin
19.02.2019 21:50DonAlPAtino
20.02.2019 10:20-1ну я спрашивал про «простой» способ. А тут получается надо устанавливать сертификат в систему, прочитать дату, удалить. И так каждый день.
Neraverin
20.02.2019 11:35Почему каждый день? Если сертификат в систему импортировать, то потом его можно экспортировать как cer. Windows это вполне штатными средствами умеет. Насчет командной строки не помню (в mmc точно можно), но скорее всего certutil может.
DonAlPAtino
20.02.2019 11:46У меня сертификаты в контейнерах для пол-сотни юрлиц. Обновляют их рядовые сотрудники когда их система (КриптоПро, Такском, 1С) спросит. А не спросит — не обновят. Так что там все меняется динамически мне надо как-то это контролировать.
Neraverin
20.02.2019 12:26Рядовые сотрудники в Windows все равно не смогут пользоваться контейнером пока не установят его в систему. Каждый день запускаете 1 раз certutil перебирая все сертификаты. Если у сертификата приближается срок действия — поднимаете сигнал. Если появился новый сертификат, когда его обновили, то как только его установят в систему, Вы будете и его мониторить.
DonAlPAtino
20.02.2019 13:21Благополучно пользуются — контейнеры CryptoPro все подключены, а обновление сертификатов внутри контейнеров особых прав не требует. Для работы устанавливать эти сертификаты в систему не надо, их и не ставят.
Мой вопрос был как раз как перебрать и получить даты окончания срока действия из сертификатов лежащих ВНУТРИ контейнеров CRyptoPro.
Greyushko
20.02.2019 15:01Я не эксперт, но ведь в статье на которую вы ссылаетесь явно сказано «Поэтому все нижеописанное относится девелоперскому или тестовому окружению, где мы сами себе хозяева.». А что мешает взять для тестового окружения ключ сгенерированный самостоятельно на коленке с самоподписанным сертификатом?
Использовать ключ от чужого СКЗИ в отрыве от этого СКЗИ довольно странно: кто обеспечит контроль корректности его использования?
На вопрос «да что там использовать, берешь описание алгоритма да реализуешь» можете обратиться к простым материалам:
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-2astralNord
20.02.2019 15:09В среду разработки/тестирования СМЭВ, к примеру, вы не сможете успешно отправить сообщение подписанное ключом сгенерированным самостоятельно на коленке с самоподписанным сертификатом.
Получите ошибку, а не ожидаемый ответ.
Соответственно, не сможете проверить, а правильно ли всё реализовали.
Greyushko
20.02.2019 15:29То есть, я правильно понимаю, что вопрос в том, что есть некоторая тестовая удаленная система с документированным интерфейсом, которая принимает только запросы, подписанные ключом с квалифицированным сертификатом?
Тогда не очень понятно следующее:
1) Автор предлагает выгрузить закрытый ключ, подпись которым обладает юридической значимостью, на десятки (сотни) машин? Если только на одну «эталонную» для тестирования, то опять же разницы между покупкой КриптоПро CSP и этой хакерской тулзы нет никакой. А если на огромное количество, как будет контролироваться то, что ключ никто не использует для «неподходящих» действий. Если бы для тестовой системы, которую разрабатывает моя компания, потребовалось положить на десятки машин мой ключ с квалифицированным сертификатом для Госуслуг, я бы, мягко говоря, остерёгся.
2) Почему нельзя приобрести ключ со встроенной в сертификат лицензией на CSP? Тогда не нужны кучи лицензий на машины.
3) Почему нельзя вести разработку с тестовым окружением (сделанный на коленке стенд, эмулирующий сервер), а затем уже доводить напильником на машине с легальным CSP?astralNord
20.02.2019 16:07Ну как документированным… В лучших традициях госзаказчиков. Неполно, неактуально, не для людей, зато формально по ГОСТ.
1) Ну если строго следовать букве и духу то да, надо получать тысячи ключей и т.д.
А вас не напрягает необходимость подписывать вашей ЭЦП тысячи сообщений в час, где этапа подписи человеком вообще не должно быть? =)
2) CSP — это windows, который кстати при подключении рутокена на котором это ключ распространяется иногда начинает жутко тормозить и делает еще некоторые выкрутасы. Вы же покупате лицензию в составе ключа, как не нужна? :) Только платите не сразу а по факту за 2 года стоимость лицензий.
3) эм… Ну после таких предложений хочется поступить как поддержка смэв с ответом на любой конкретный вопрос и адресовать вас к документации, вас ждут там сюрпризы =) Готов поклониться 100 раз в ноги если быстро на коленке сделаете стенд эмулирующий сервер смэв, включая проверку реализации подписи согласно всем методическим материалам =)
Корень проблемы в другом. Есть в некоторых случаях весьма нагруженный обмен сервер — сервер, для которого какой-то сумрачный гений придумал требовать усиленную эцп на должностное лицо и соблюдать кучу других требований и прописал это в законах и подзаконных актах.
Такой порядок уместен для работы с секретными бумажками именно как бумажками, но не для случая работы ИС на потоке с большой нагрузкой.
Neraverin
Давайте я вместо юриста сразу проконсультирую:
63-ФЗ Статья 5. Виды электронных подписей пункт 4:
«Квалифицированной электронной подписью является электронная подпись, которая соответствует всем признакам неквалифицированной электронной подписи и следующим дополнительным признакам:
1) ключ проверки электронной подписи указан в квалифицированном сертификате;
2) для создания и проверки электронной подписи используются средства электронной подписи, имеющие подтверждение соответствия требованиям, установленным в соответствии с настоящим Федеральным законом.»
КриптоПро CSP таким средством электронной подписи является, Java KeyStore нет.
Эта схема конечно будет работать. Но первая же проверка может аннулировать все подписи, которые были выполнены этой системой.
MisterParser
А кто даст копаться в коде проприетарного проекта частной компании?
Neraverin
Я писал про юридическую сторону вопроса и последствия. Вы можете нарушать закон и скрывать это как угодно. Только факт нарушения это не отменяет. И от ответственности не освобождает.
matabili1973
Любой судья, если сочтет необходимым вынести такое решение. Представьте себе, что вам потребовалось подтвердить юридическую значимость подписи.
ggo
Что означает «имеющие подтверждение соответствия требованиям»?
Neraverin
Имеет сертификат ФСБ на соответствие требованиям к средствам криптографической защиты информации и средствам электронной подписи
ggo
Такое ощущение, что закон про соответствие требованиям имеет ввиду следующее.
Есть отсылка на некие требования к средствам электронной подписи.
Сами требования к средствам электронной подписи:
Т.е. специальное подтверждение нужно для гос.тайны, что логично.
Из всего этого проистекает, что нельзя использовать BC?
Прочие мысли вслух:
А если я подписал документ в помощью устройства, которое сейчас недоступно, и доказать что на том устройстве был КРиптоПро, подписал я с помощью КриптоПро у меня возможности нет. То все, подписанный документ нелегитимен?
И как доказать что документ подписан именно в BC, а не в КриптоПро?
Neraverin
Требования, они так и называются. А Статья 12 требованиями не является.
Приказ ФСБ РФ от 27 декабря 2011 г. № 796 «Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра» — https://www.garant.ru/products/ipo/prime/doc/70039150/
Как именно будет действовать суд или регулятор я не берусь предсказывать. Могу только предположить. Так как СКЗИ в России подлежат учету, то Вам необходимо будет как минимум показать, что на Ваши паспортные данные записана лицензия сертифицированной версии того или иного СКЗИ.
ggo
Т.е. юридическая значимость эцп зависит от лицензии на скзи?
А используешь ли ты данный скзи для создания эцп, и не используешь — для юридической значимости эцп значения не имеет?
Neraverin
Конечно нет.
Я же написал, что это только мое предположение, с чего начнут проверку. Проверить наличие лицензии очень просто. И если ее нет, то уж точно было не сертифицированное СКЗИ. Если лицензия была, то можно уже копать дальше.
Ещё раз отмечу, как это будет происходить в реальной жизни я не знаю.
ggo
Ну давайте пофантазируем.
Вот два субъекта в судебном порядке выясняют между собой кто прав. Один (или оба, неважно) предоставляет электронный документ с электронной же подписью, под капотом которой ГОСТ. И прилагает еще лицензию о законном приобретении СКЗИ.
Как судья будет выяснять значимость представленного документа? Наверно судья пригласит эксперта в этой области. Пусть будет экспертом сотрудник какого-нибудь Всероссийского Национального Удостоверяющего Центра. Что будет делать данный эксперт с электронным документом и подписью? Наверно проведет экспертизу и вынесет официальным вердикт о соответствии документа подписи, и действительности сертификата подписанта в момент подписи.
Будет ли эксперт выяснять, а запускалось ли СКЗИ в момент подписания?
далее сугубо имхо.
Мне лично понятна идея для чего нужна сертификация СКЗИ. Ровно для того же, для чего нужна сертификация бытовой электроники. Чтобы у обывателей не возникало вопросов, а выполняет ли свою основную функцию продаваемое изделие. Я как обыватель совершенно не понимаю, а всем ли стандартам связи соответствует покупаемой мной мобильный телефон. Пусть специалисты в этой области выясняют это.
Но сертификация СКЗИ из средства защиты потребителей, превратилась в средство оказания давления на потребителей же.
У потребителя цель — получать юридически значимые электронные документы и подписи. Если на выходе документы валидны, то способ их получения становится вторичным.
(оставляем за скобками разные специфичные кейсы, вроде гостайн)
Neraverin
Вы ошибаетесь, на мой взгляд, с идеей сертификации СКЗИ. Это только не про выполнение основной функции, а про Вашу безопасность. Если грубо сравнить это как автомашина. Важна не только, чтобы она выполняла свои функции, но и не взрывалась в случайный момент с гибелью сотен людей вокруг. И это не менее важно, чем выполнения функции перевозки из одного места в другое. Именно поэтому даже если машина вас везет (документы валидны), то безопасность взрыва (способ получения) не становится вторичным.
a1ien_n3t
Как правильно выше написали сертефикацией СКЗИ хотят обезопасить вас. Саму идея сертефикации СКЗИ я не точтобы сильно приветствую, но если бы она была реализованна адекватно то ее назначения понять можно.
Пример того что сертефикация СКЗИ могла бы делать(неуверен что она реально это делает): если взять подпись на эллиптической кривых. И у вас 1) есть возможность подписывать произвольные данные. 2) в реализации алгоритма подписи используется предсказуемый генератор случайных чисел то возможна утечка приватного ключа(привет PlayStation 3).
И возможно еще есть какието моменты.
BugM Автор
Подпись произвольных данных это обычный юзкейс. Используется везде. docx это самые что ни на есть произвольные данные для любой библиотеки реализующей подпись.
a1ien_n3t
Почитайте алгоритм подписи на эллиптической кривых. Я же специально в комментариях про них упомянул.
en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Signature_generation_algorithm