Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Ничего не понял. Если он сейчас не делает резервных копий, отчего вдруг станет их делать на следующий раз?
Если сгенерировать ключ не токеном, а криптопром то он будет физически лежать в реестре винды.
Есть утилита которая позволяет убрать галочку не извлекаемый приватный ключ.
Далее штатным способом просите сделать бэкап приватного ключа и сертификата на флешку.
Далее можете вынуть оттуда приватный ключи и потом openssl-ем подписывать что угодно.
Либо просто использовать как резервную копию распечатав в виде qr-кода base64 от приватного ключа и т.п.
Но если вы сгенерировали приватный ключ токеном, то он его без боя не отдаст.
. Кривизна и ненадежность процедуры навели на мысли о том, что неплохо бы сделать резервную копию секретного ключа. Судя по тому, что 5110 аппаратно не поддерживает алгоритмы ГОСТ, а SafeNet Authentication Client Tools по-прежнему не видит на ключе никаких контейнеров/сертификатов, КриптоПро до сих пор держит закрытые ключи в файловой системе eToken в собственном формате, извлекая их оттуда при вычислении подписи.
В сети полно инструкций по извлечению секретного ключа с разных моделей РуТокен с помощью утилит Tokens и CertFix от Контура, но eToken 5110 и 72k эти утилиты не видят. Они принципиально не умеют с ними работать, или им нужны какие-то особые драйверы/службы для РуТокен?
Кто имел дело с файловыми системами ключей — посоветуйте, как проще это сделать. Может, есть какой хак для КриптоПро?
. Кривизна и ненадежность процедуры навели на мысли о том, что неплохо бы сделать резервную копию секретного ключа. Судя по тому, что 5110 аппаратно не поддерживает алгоритмы ГОСТ, а SafeNet Authentication Client Tools по-прежнему не видит на ключе никаких контейнеров/сертификатов, КриптоПро до сих пор держит закрытые ключи в файловой системе eToken в собственном формате, извлекая их оттуда при вычислении подписи.
ЕМ>В сети полно инструкций по извлечению секретного ключа с разных моделей РуТокен с помощью утилит Tokens и CertFix от Контура, но eToken 5110 и 72k эти утилиты не видят. Они принципиально не умеют с ними работать, или им нужны какие-то особые драйверы/службы для РуТокен?
ЕМ>Кто имел дело с файловыми системами ключей — посоветуйте, как проще это сделать. Может, есть какой хак для КриптоПро?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Судя по тому, что 5110 аппаратно не поддерживает алгоритмы ГОСТ, а SafeNet Authentication Client Tools по-прежнему не видит на ключе никаких контейнеров/сертификатов, КриптоПро до сих пор держит закрытые ключи в файловой системе eToken в собственном формате, извлекая их оттуда при вычислении подписи.
Вообще-то он умеет java и элептические кривые поддерживает, так что может быть и не извлекаемый. Тогда просто еще пару ключей создайте. (Не отзывая старых конечно же )
ЕМ>Кто имел дело с файловыми системами ключей — посоветуйте, как проще это сделать. Может, есть какой хак для КриптоПро?
Вообще криптопро если ключ извлекаемый умеет делать копию и потом бэкап на флешку и оттуда уже можно вынуть.
C 2022 года в РФ были отменены все сертификаты ФСТЭК, выданные на иностранное оборудование. По этой причине eToken 5110 пока не может быть сертифицирован ФСТЭК.
Спасибо, находил уже это в поиске. Но я с Java знаком только на уровне запуска полных готовых программ, а делать что-то свое на основе коротких примеров, боюсь, будет слишком геморройно.
BE>По нормальному на новых токенах ключ должен быть не извлекаем.
5110 как раз достаточно старый — я его покупал еще в 2017-м. В прошлом году мне на него записали сертификат в отделении ФНС, а вчера я туда же записал новый сертификат, полученный через браузер. Пока не могу понять, в каком формате там лежит секретный ключ.
Спасибо, видел. Если не найду более готового решения, то придется и так.
_>ps:
C 2022 года в РФ были отменены все сертификаты ФСТЭК, выданные на иностранное оборудование. По этой причине eToken 5110 пока не может быть сертифицирован ФСТЭК.
То есть, можно считать, что ключ просто лежит в контейнере, формально помеченном, как неизвлекаемый?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>То есть, можно считать, что ключ просто лежит в контейнере, формально помеченном, как неизвлекаемый?
Нет. Если бы вы генерировали ключ в браузере и сохранили его в контейнере на компьютере. Он бы лёг в реест. И тогда он элементарно извлекается даже если помечен как не извлекаемый.
Но если вы генерировали секретный ключ токеном, то он не покидал токена и он его низачто не отдаст ни при каких обстоятельствах. Только аппаратно, снимать компаунд, кислотой травить слой за слоем и коротить дорожки под микроскопом (и обычно даже там есть мины, чтоб так не делали). (При условии что это действительно токен, а не флешка).
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, BlackEric, Вы писали:
BE>>https://coderanch.com/t/646136/java/Extract-private-Key-Etoken
ЕМ>Спасибо, находил уже это в поиске. Но я с Java знаком только на уровне запуска полных готовых программ, а делать что-то свое на основе коротких примеров, боюсь, будет слишком геморройно.
Там принцип показан, так то можно на любом языке сделать. Все зависит от библиотеки токена и как был сгенерирован ключ.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, kov_serg, Вы писали:
_>>Если бы вы генерировали ключ в браузере извлекаемый. _>>Но если вы генерировали секретный ключ токеном
ЕМ>Так весь вопрос в том, как именно генерировался ключ на нижнем уровне. На верхнем-то всегда браузер.
Как обычно это происходит.
1. генерируется секретный ключ (точка на эллиптической кривой)
2. генерируется публичный ключ и запрос на сертификат.
3. этот запрос уходит на сторону, которая подписывает сертификат своим ключом и возвращает сертификат
4. в сертификате только открытый ключ, но он подписан удостоверяющим центром и там еще добавляют доп поля, типа назначения адреса явки инн и т.п.
5. вот этот сертификат тоже кладётся в токен. его он отдаёт без вопросом. но секретный ключ от него никогда (если специально не указано обратное).
Здравствуйте, Евгений Музыченко, Вы писали:
_>>Как обычно это происходит.
ЕМ>Точнее, "как это должно происходить". А я хочу узнать, как это происходило в конкретно моем случае.
Отзовите и сгенерируйте в криптопрошный контейнер новый. И потом делайте резервные копии на флекшу ( на диск и в сеть он не хочет, только флешки )
Здравствуйте, kov_serg, Вы писали:
_>Отзовите и сгенерируйте в криптопрошный контейнер новый.
Так он всегда кладет в новый контейнер. Старый контейнер остается.
_>И потом делайте резервные копии на флекшу ( на диск и в сеть он не хочет, только флешки )
Ничего не понял. Если он сейчас не делает резервных копий, отчего вдруг станет их делать на следующий раз?
Здравствуйте, BlackEric, Вы писали:
BE>можно на любом языке сделать. Все зависит от библиотеки токена
Ну вот экспорты C_OpenSession, C_FindObjects я в экспортах их DLL вижу. А где брать определения констант (Token.SessionType.SERIAL_SESSION, Token.SessionReadWriteBehavior.RW_SESSION и прочих)? В приведенных примерах их импортируют из каких-то известных библиотек. Если это SDK производителя, то где его брать? Просто так они его не дают.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, BlackEric, Вы писали:
BE>>можно на любом языке сделать. Все зависит от библиотеки токена
ЕМ>Ну вот экспорты C_OpenSession, C_FindObjects я в экспортах их DLL вижу. А где брать определения констант (Token.SessionType.SERIAL_SESSION, Token.SessionReadWriteBehavior.RW_SESSION и прочих)? В приведенных примерах их импортируют из каких-то известных библиотек. Если это SDK производителя, то где его брать? Просто так они его не дают.
У производителя обычно есть софт для работы с токеном. Если ключ извлекаем, то в этом софте будет такая функция. Если ключ не извлекаем, то его не извлечь, для того аппаратный токен и придумали, в общем-то.
Если там программное ограничение, то это жуткая халтура, я не думаю, что такое может существовать.
Здравствуйте, kov_serg, Вы писали:
_>Если сгенерировать ключ не токеном, а криптопром то он будет физически лежать в реестре винды.
Лежать он будет там, куда его положит сгенерировавший софт (в данном случае КриптоПро). И в том виде, который задаст КриптоПро, и который будет поддерживать токен.
_>Есть утилита которая позволяет убрать галочку не извлекаемый приватный ключ.
Если Вы про Tokens.exe, то она предназначена для РуТокен, а eToken она не видит. Возможно, ее можно как-то научить, но я не нашел.
_>Далее штатным способом просите сделать бэкап приватного ключа и сертификата на флешку.
Угу.
_>Но если вы сгенерировали приватный ключ токеном, то он его без боя не отдаст.
Да знаю я. А толку от этого знания? Сперва надо понять, как именно был сгенерирован ключ. Есть идеи?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Лежать он будет там, куда его положит сгенерировавший софт (в данном случае КриптоПро). И в том виде, который задаст КриптоПро, и который будет поддерживать токен.
Нет. Если его генерит криптопро то он будет лежать в контейнере криптопро. А если токен то внутри токена.
ЕМ>Если Вы про Tokens.exe, то она предназначена для РуТокен, а eToken она не видит. Возможно, ее можно как-то научить, но я не нашел.
Нет. Я про то что если вы получаете сертификат через интернет, то секретный ключ генерируете вы и потом отправляете запрос на получения сертификата, его подписывают и отдают вам.
У стороны которая подписывает сертификат нет понятия где у вас секретный ключ. На токене или на бумаге или еще где. Секретный ключ это просто случайное число, просто длинное.
_>>Но если вы сгенерировали приватный ключ токеном, то он его без боя не отдаст. ЕМ>Да знаю я. А толку от этого знания? Сперва надо понять, как именно был сгенерирован ключ. Есть идеи?
Еще раз получите сертификат, генерируйте ключ не токеном, а криптопрой. Его потом можно легко бэкапить и вынуть если хочется.
Здравствуйте, kov_serg, Вы писали:
_>Если его генерит криптопро то он будет лежать в контейнере криптопро. А если токен то внутри токена.
Что именно Вы называете "контейнером КриптоПро", и что именно понимаете под "внутри токена"? Контейнеры КриптоПро, записанные в память токена — это "внутри" или "не внутри"?
_>если вы получаете сертификат через интернет, то секретный ключ генерируете вы и потом отправляете запрос на получения сертификата
Вы описываете каноническую процедуру ("как должно быть"). Откуда у Вас сведения о фактически выполняемой процедуре ("как есть")?
_>Секретный ключ это просто случайное число, просто длинное.
Спасибо, кэп.
_>Еще раз получите сертификат, генерируйте ключ не токеном, а криптопрой.
Скажите, насколько Вы знакомы с техникой выпуска КЭП в ЛК ФНС? У меня крепнет подозрение, что Вы с нею попросту не сталкивались.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Что именно Вы называете "контейнером КриптоПро", и что именно понимаете под "внутри токена"? Контейнеры КриптоПро, записанные в память токена — это "внутри" или "не внутри"?
Чего не понятного, у крипто про есть внутренние контейнеры, которые хранятся на машие. А есть внешние которые хранятся в токенах.
Но токены если используются как токены, а не флешки. Генерируют приватные ключи сами и наружу ими не светят. А с теми что на машие можно делать что угодно.
ЕМ>Скажите, насколько Вы знакомы с техникой выпуска КЭП в ЛК ФНС? У меня крепнет подозрение, что Вы с нею попросту не сталкивались.
С последними веяньями именно ФНС незнаком. У них просто токены физически забирали. Но несколько лет сношались с технокадом, там такая же садомия, выпуск через личный кабинет, но только ещё надо всё в бумажном виде и для отзыва лично им юриста присылать в москву. В общем послали их лесом.
ps:
— Шеф у нас дыра в безопасности
— Слава богу, хоть что-то у нас в безопасности.
Спасибо, побаловался с PKCS#11 через eToken.dll. Только без толку — на токенах, где лежат сертификаты в формате КриптоПро, есть всего три объекта PKCS#11, и все они — CKO_MECHANISM, нулевого размера. И КриптоПро вообще не работает с eToken через eToken.dll — только через свою (safenet.dll), а как та взаимодействует с токеном — пока не понял.
Здравствуйте, Anton Batenev, Вы писали:
AB>И таких вендоров надо гноить и рассказывать всем, что они ни от чего не защищают и это просто профанация.
Вендоров чего именно? Если выяснится, что сам токен честно поддерживает нужные аппаратные функции, а тот же КриптоПро их не использует, просто организуя хранилище в памяти токена — кого будем гноить?
И рассказывать тоже без толку — после того, как ФНС стала требовать от УЦ выдавать КЭП только на токенах, их долгое время выдавали в том же "контейнерном" формате, когда секретный ключ можно было без проблем извлечь и сохранить средствами самого КриптоПро. И сами секретные ключи генерились, разумеется, на компьютерах УЦ. Все, кто мало-мальски интересовался, об этом знали, а толку?
Здравствуйте, kov_serg, Вы писали:
_>у крипто про есть внутренние контейнеры, которые хранятся на машие. А есть внешние которые хранятся в токенах. _>Но токены если используются как токены, а не флешки. Генерируют приватные ключи сами и наружу ими не светят. А с теми что на машие можно делать что угодно.
И с теми, что на "токенах, как флешках", тоже можно делать, что угодно. И без понимания внутренней кухни отличить те, что "как токены", от тех, что "как флешки", невозможно. Даже если интерфейс пользовательского режима отвечает, что секретный ключ неизвлекаемый, эту пометку может ставить и ядерный драйвер токена, и сам его контроллер, а при использовании нужных функций драйвера/контроллера ключ вполне себе может оказаться извлекаемым. А поскольку протоколов контроллера и драйвера производитель не раскрывает, понять это можно только предметным реверсингом.
_>С последними веяньями именно ФНС незнаком. У них просто токены физически забирали.
Тогда Вы должны помнить, что поначалу КЭП выдавали на дискете/флешке, без какой-либо защиты секретного ключа, затем стали выдавать только на токенах, мотивируя это "повышением уровня безопасности", но фактически ключи там лежали, "как на флешках", опять-таки без защиты. Теперь КриптоПро не позволяет копировать секретный ключ, но это не гарантирует того, что ключ нельзя извлечь на более низких уровнях.
А теперь, при перевыпуске КЭП через ЛК, они еще и не дают скачать новый сертификат, пока не отзовешь старый. То есть, если вдруг какой глюк с установкой/использованием нового, то решать его только ногами через отделение ФНС.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>И без понимания внутренней кухни отличить те, что "как токены", от тех, что "как флешки", невозможно. Даже если интерфейс пользовательского режима отвечает, что секретный ключ неизвлекаемый, эту пометку может ставить и ядерный драйвер токена, и сам его контроллер, а при использовании нужных функций драйвера/контроллера ключ вполне себе может оказаться извлекаемым. А поскольку протоколов контроллера и драйвера производитель не раскрывает, понять это можно только предметным реверсингом.
Я немогу до вас донести простую вещь. Генерируёте и сохраняёте ключ не на токене, а в контейнере криптопро. Тогда вы спокойно можете делать бэкапы ключей.
Если хочется как положено то, надо выпускать несколько ключей на разных токенах. То что это не даёт ФНС это не повод растраиваться. Т.к. вы можете выпустить ключ в другой акредетованной конторе. Там просто должно быть шифрование гост256 и ваш инн.
ЕМ>Тогда Вы должны помнить, что поначалу КЭП выдавали на дискете/флешке...
Теперь ФНС выдаёт токены с неизвлекаемым приватным ключом. Но если вы генерируете через личный кабинет у вас есть выбор использовать токен или просто файлк.
ЕМ>А теперь, при перевыпуске КЭП через ЛК, они еще и не дают скачать новый сертификат, пока не отзовешь старый. То есть, если вдруг какой глюк с установкой/использованием нового, то решать его только ногами через отделение ФНС.
Это притенении к бюрократии, эта ещё лайтовая версия. А вот когда на любоё отзыв сертификата надо лично с документами удостоверяющими личность и доверенностями ехать в центральный офис вот где каргокульт.
Здравствуйте, kov_serg, Вы писали:
_>Я немогу до вас донести простую вещь.
Я тоже не могу донести до Вас простую вещь — подобными предложениями Вы демонстрируете свою оторванность от текущей реальности, а упорством — нежелание эту реальность осознать.
_>Генерируёте и сохраняёте ключ не на токене, а в контейнере криптопро.
Когда мне требуется самоподписанный ключ, которым я распоряжаюсь по своему усмотрению, я именно так и делаю.
_>вы можете выпустить ключ в другой акредетованной конторе.
Не могу. Все, кто имеет к этому отношение, отлично знают, что еще прошлого года ключи выдает только ФНС.
_>если вы генерируете через личный кабинет у вас есть выбор использовать токен или просто файлк.
Здравствуйте, Anton Batenev, Вы писали:
vsb>> Если там программное ограничение, то это жуткая халтура, я не думаю, что такое может существовать. AB>И таких вендоров надо гноить и рассказывать всем, что они ни от чего не защищают и это просто профанация.
Гноить надо тех, кто не разобрался в технологии и бурлит на форумах. У всех токенов всегда четко сказано, какой именно алгоритм шифрования поддерживается аппаратно и очевидно что поддерживать все возможные варианты не будет примерно никто. В данном случае аппартно поддерживается только RSA определенной длины. Который по понятным причинам не соответствует требованиям российского законодательства. А поддерживать ГОСТ израильтяне не будут, зачем оно им надо особенно с учетом того, что константы надо явно запрашивать в ФСТЕК? Вот и используют этот токен как флешку. Нужна реальная зашита — рутокен берите, только именно со смарткартой, а не эмулятор ее на pic-е.
