Комментарии 143
Вообще говоря, удивляет вот эта манера сертифицированных УЦ депонировать закрытые ключи. Речь конкретно про Ростелеком.
«Заполни заявление, вот тебе распечатка открытого ключа, и введи пин пожалуйста».
Почему я не могу прийти с запросом на сертификат? Дайте мне инструкцию какие OID-ы чем заполнять — я принесу. Нет, я не хочу чтобы вы как-то взаимодействовали с моим закрытым ключом.
«Заполни заявление, вот тебе распечатка открытого ключа, и введи пин пожалуйста».
Почему я не могу прийти с запросом на сертификат? Дайте мне инструкцию какие OID-ы чем заполнять — я принесу. Нет, я не хочу чтобы вы как-то взаимодействовали с моим закрытым ключом.
> Почему я не могу прийти с запросом на сертификат?
Можете, но надо искать. До сих пор мне это удавалось.
Можете, но надо искать. До сих пор мне это удавалось.
Почему я не могу прийти с запросом на сертификат?
Можете, но надо искать. До сих пор мне это удавалось.
Например, куда прийти?
Требования — Windows 7 и IE9. Печалити.
И выше. А что вы хотели? Linux'ы практически нереально завести под нашу ЭП.
Требования — Windows 7 и IE9. Печалити.
И выше. А что вы хотели? Linux'ы практически нереально завести под нашу ЭП.
Есть специальная версия Chrome в которую встроены все нужные для этого российские алгоритмы.
github.com/deemru/chromium-gost
Возможно, она смогёт.
а я хотел нормальное кроссплатформенное решение с поддержкой PKCS#11, чтоб можно было по человечески с токенами работать.
Я бы тоже хотел, но проблема не столько в том, чтобы зацепить какой-нибудь openssl к токену. Проблема уже гораздо более запущенная — куча сайтов написано под взаимодействие с конкретными плагинами, которые в свою очередь взаимодействуют с конкретными криптопровайдерами. Под линуксом ни один из этих плагинов не будет работать (
Так вышло по ряду причин, но все их вместе можно описать коротко — пидорасы.
Так вышло по ряду причин, но все их вместе можно описать коротко — пидорасы.
Про плагин от Тензора/СБИС понятно, а есть еще другие?
кто другие?
плагины. Вы писали «куча сайтов написано под взаимодействие с конкретными плагинами, которые в свою очередь взаимодействуют с конкретными криптопровайдерами. Под линуксом ни один из этих плагинов не будет работать „
Есть плагин КриптоПро Browser Plugin. Есть плагин у Контура. Есть плагин у Госуслуг (ростелекома). Имя им — легион.
Первый из них вполне работает под линуксом.
И причем здесь то, что один из 100 плагинов работает под линуксом? Не вы выбираете через какой плагин работает тот или иной сайт. Будете на трёх сайтах работать под линуксом, а потом переключаться в винду, чтобы работать на ещё 10 сайтах?
Кроме того работа плагина под линуксом, не заменяет того факта, что стандартные браузеры под Linux не умеет устанавливать соединение по TLS с использованием ГОСТ.
Кроме того работа плагина под линуксом, не заменяет того факта, что стандартные браузеры под Linux не умеет устанавливать соединение по TLS с использованием ГОСТ.
Сбис Плагин, на сколько я помню, таки делали кроссплатформенным и он точно есть под macOS, и, вроде, должен работать и на линуксах (но, вроде, его в основном делали под CentOS какую-то)
У Госуслуг честный плагин для работы с токенами PKCS#11 с ГОСТ-криптографией.
Для Рутокена есть плагин кросс-платформенный и для большого количества браузеров. Через PKCS#11 как раз работает.
Пожалуйста, утилита cryptoarmpkcs, при чем практически для всех платформ.
Да здравствует импортозамещенный дебиан! :))
VirtualBox не поможет?
Бумагу в ФАС, не?
Простите, но прийти вы конечно можете с запросом, но где гарантия, что во время генерации закрытого ключа на портале, он останется только на носителе? Раньше у казначейства была оффлайн программа, АРМ генерации ключей, которая на выходе давала файл запроса, который надо было нести в казначейство. А сейчас все через портал генерируется.
Если закрытый ключ генерируется у меня, то я могу обеспечить отсутствие его утечки… или Вы о чем? С запросом ведь генерируется открытая, несекретная часть. В чем и весь смысл
1) Если у вас умный носитель с неизвлекаемым ключем, то вам это не страшно. Усрутся извлекать, чтобы его переслать.
2) Если там требуется IE9, с большой вероятностью там используется компонент ActiveX. После загрузки страницы он может работать оффлайн.
Что значит если? Вы просто ссылку из гугла кинули? Автор в первом комменте написал что хочет все генерировать сам и принести запрос на бумажке в УЦ. Вы ему отвечаете, что вам до сих пор удавалось использовать именно такие УЦ, и в качестве примера приводите УЦ казначейства, который
- человеку с улицы ничего выпускать не будет;
- использует в н. в. практически идентичную остальным УЦ схему выпуска ЭП, описанную в упомянутом комментарии.
> человеку с улицы ничего выпускать не будет;
с чего вы это взяли? по-моему, любая организация там может сделать себе СКПЭП. С физиками могут быть проблемы. Но с физиками проблемы у очень большого кол-ва УЦ вне зависимости от регламента выпуска сертификата
> использует в н. в. практически идентичную остальным УЦ схему выпуска ЭП, описанную в упомянутом комментарии.
там используется схема практически идентичная той, что описана в посте. За исключением того, что там не занимаются (скорее всего) искусственным запретом использования умных токенов.
udc.zaozet.ru/sert.html — вот здесь я делал подпись с запросом на сертификат. Генерировал оффлайн утилитой, которую они дают. Но это только Питер.
Можно настрополить свою утилиту — я так делал. Сначала сгенерил запрос их утилитой, потом посмотрел asn.1 дампером OID'ы, и написал свою.
с чего вы это взяли? по-моему, любая организация там может сделать себе СКПЭП. С физиками могут быть проблемы. Но с физиками проблемы у очень большого кол-ва УЦ вне зависимости от регламента выпуска сертификата
> использует в н. в. практически идентичную остальным УЦ схему выпуска ЭП, описанную в упомянутом комментарии.
там используется схема практически идентичная той, что описана в посте. За исключением того, что там не занимаются (скорее всего) искусственным запретом использования умных токенов.
udc.zaozet.ru/sert.html — вот здесь я делал подпись с запросом на сертификат. Генерировал оффлайн утилитой, которую они дают. Но это только Питер.
Можно настрополить свою утилиту — я так делал. Сначала сгенерил запрос их утилитой, потом посмотрел asn.1 дампером OID'ы, и написал свою.
с чего вы это взяли?
Потому что я пользуюсь услугами этого УЦ. Если вы посмотрите на список сайтов, где применяются эти сертификаты, увидите что это госплощадки (некоторые закрытые), а сертификаты выдают муниципальным организациям для обеспечения документооборота, участия в торгах и регулятивных функций. И коммерческая организация получит ЭП там, если у нее, скажем, счет в казначействе открыт, что само по себе не произойдет. Ну, и вы наверняка не найдете стоимости выпуска сертификатов, потому что они бесплатны, потому что выпускаются тем, кому они нужны и положены. А иначе было бы отлично получить ЭП для госзакупок на шару, вместо того, чтобы платить тому же сбису условные 5к.
За исключением того, что там не занимаются (скорее всего) искусственным запретом использования умных токенов.
Да, скорее всего вы правы, используется обычный плагин КриптоПро ЭЦП Browser Plugin, но началу нити беседы это отношения не имеет, потому что там говорилось о самостоятельной генерации ЭП. Поэтому я и удивился второй раз приведенной ссылке на УЦ казначейства.
По первой части — принято. Просто я знаю несколько человек, у которых ключ казначейства есть. Они применяют его везде, где можно, а не только на этих сайтах. Но я никогда не задавался вопросом о том, как они его получили.
В целом ваш поинт теперь понятен. Надо искать. По Питеру я привел контору. Задачу найти все УЦ в России, которые нормально работают с запросами на сертификат, я перед собой никогда не ставил.
В целом ваш поинт теперь понятен. Надо искать. По Питеру я привел контору. Задачу найти все УЦ в России, которые нормально работают с запросами на сертификат, я перед собой никогда не ставил.
Если я пришел с запросом — значит закрытый ключ уже сгенерирован и он только у меня
> Нет, я не хочу чтобы вы как-то взаимодействовали с моим закрытым ключом.
Есть ещё такая проблема, что они почти все не умеют или не хотят уметь работать с умными токенами. То есть если им даже дать свой токен, то они не сгенерируют на нём неизвлекаемый ключ.
Есть ещё такая проблема, что они почти все не умеют или не хотят уметь работать с умными токенами. То есть если им даже дать свой токен, то они не сгенерируют на нём неизвлекаемый ключ.
Когда-то давно работал у партнеров сервиса, разрабатывающего аналогичное СБИСу ПО. Формально, у нас была инструкция, по которой мы генерировали ключевую пару, записывая ее сразу на токен без права ее копировать. Не уверен, что была возможность извлечь потом сертификат и сохранить у себя, однако исключать подобное я не могу. С тех пор прошло почти девять лет, а воз и нынче там: УЦ генерируют ключи и передают клиентам.
Мне тоже до сих пор непонятна логика, по которой недопустимо генерировать ключевую пару на стороне клиента и лишь подписывать получившийся сертификат на стороне УЦ. Если кто-нибудь сможет пояснить, почему такой подход до сих пор применяют (причем, судя по статье, зачастую безальтернативно), буду рад.
Мне тоже до сих пор непонятна логика, по которой недопустимо генерировать ключевую пару на стороне клиента и лишь подписывать получившийся сертификат на стороне УЦ. Если кто-нибудь сможет пояснить, почему такой подход до сих пор применяют (причем, судя по статье, зачастую безальтернативно), буду рад.
> генерировать ключевую пару на стороне клиента и лишь подписывать получившийся сертификат на стороне УЦ
Это и есть схема с запросом на сертификат (certificate request). В статье как раз речь о ней. Просто в отечественной индустрии ЭП сложился довольно печальный идиотизм — нет единого инструмента по генерации запроса. Его могли бы поставлять вместе с криптопровайдером, но не поставляют. Каждый УЦ извращается как может — пишет свое ПО. Статья в общем о том, что этому ПО нельзя доверять )
> Если кто-нибудь сможет пояснить, почему такой подход до сих пор применяют
Да в общем-то тут далеко ходить не надо, чтобы понять причину. Что такое ЭП и как она работает не понимают даже работники УЦ. Из клиентов УЦ хорошо если 1 из 100 — это знающий основы криптографии человек. В подавляющем большинстве случаев у юрлиц директор поручает получить сертификат кому-то из подчиненых, стряпается доверка, подчиненный получает ЭП и пользуется им (например, в бухгалтерии для подписания отчетов в органы). А директор этот ключ ни разу и не держал. Какая там криптография? О чём вы?
Работая с таким человеческим материалом, трудно ожидать от клиента того, что он разберется с тем, как правильно проинициализировать токен, что где установить и как сгенерировать запрос (и хотя бы банально вбить свои данные без ошибок) и т.д., и т.п. Соответственно все бизнес-процессы начинают выстраиваться подобным образом. А адванснутые клиенты оказываются внутри статистической погрешности и они становятся не интересны…
Это и есть схема с запросом на сертификат (certificate request). В статье как раз речь о ней. Просто в отечественной индустрии ЭП сложился довольно печальный идиотизм — нет единого инструмента по генерации запроса. Его могли бы поставлять вместе с криптопровайдером, но не поставляют. Каждый УЦ извращается как может — пишет свое ПО. Статья в общем о том, что этому ПО нельзя доверять )
> Если кто-нибудь сможет пояснить, почему такой подход до сих пор применяют
Да в общем-то тут далеко ходить не надо, чтобы понять причину. Что такое ЭП и как она работает не понимают даже работники УЦ. Из клиентов УЦ хорошо если 1 из 100 — это знающий основы криптографии человек. В подавляющем большинстве случаев у юрлиц директор поручает получить сертификат кому-то из подчиненых, стряпается доверка, подчиненный получает ЭП и пользуется им (например, в бухгалтерии для подписания отчетов в органы). А директор этот ключ ни разу и не держал. Какая там криптография? О чём вы?
Работая с таким человеческим материалом, трудно ожидать от клиента того, что он разберется с тем, как правильно проинициализировать токен, что где установить и как сгенерировать запрос (и хотя бы банально вбить свои данные без ошибок) и т.д., и т.п. Соответственно все бизнес-процессы начинают выстраиваться подобным образом. А адванснутые клиенты оказываются внутри статистической погрешности и они становятся не интересны…
А раньше схема с CSR работала исправно, и лишь в декабре обнаружилось, что подобный функционал перестал работать?
Грустно это все. С одной стороны, вероятно, затруднения у разработчиков и, возможно, отсутствие средств на разработку необходимого ПО (грубо говоря, непонятно, кто оплатит разработку пресловутого единого инструмента). С другой, оно действительно нужно небольшому количеству организаций, хотя они, вероятно, являются очень крупными налогоплательщиками. У меня вот юрлицо обслуживается бухгалтером на аутсорсе, и про мои просьбы дать копии сертификатов (один на физлицо, которым подписывалось заявление в налоговую/минюст, второй на юрлицо) почему-то в обслуживающей компании забывают. Не скажу, чтобы мне они очень были нужны, но «осадочек остался». Будь у меня больше оборот, я не стал бы делегировать подобные задачи на аутсорс и предпочел бы единолично владеть закрытыми ключами. Представить, как ведет документооборот крупный бизнес с такими сертификатами, вообще сложно.
>Что такое ЭП и как она работает не понимают даже работники УЦ.
А вот тут я не соглашусь. Мои коллеги в те времена понимали суть, а у некоторых было образование по профилю ИБ (в т.ч. работали студенты) и отличия ГОСТ 34.10.2001 (тогда еще) от RSA многие знали. Хотя, полагаю, наше высшее руководство не сильно в этом разбиралось.
Грустно это все. С одной стороны, вероятно, затруднения у разработчиков и, возможно, отсутствие средств на разработку необходимого ПО (грубо говоря, непонятно, кто оплатит разработку пресловутого единого инструмента). С другой, оно действительно нужно небольшому количеству организаций, хотя они, вероятно, являются очень крупными налогоплательщиками. У меня вот юрлицо обслуживается бухгалтером на аутсорсе, и про мои просьбы дать копии сертификатов (один на физлицо, которым подписывалось заявление в налоговую/минюст, второй на юрлицо) почему-то в обслуживающей компании забывают. Не скажу, чтобы мне они очень были нужны, но «осадочек остался». Будь у меня больше оборот, я не стал бы делегировать подобные задачи на аутсорс и предпочел бы единолично владеть закрытыми ключами. Представить, как ведет документооборот крупный бизнес с такими сертификатами, вообще сложно.
>Что такое ЭП и как она работает не понимают даже работники УЦ.
А вот тут я не соглашусь. Мои коллеги в те времена понимали суть, а у некоторых было образование по профилю ИБ (в т.ч. работали студенты) и отличия ГОСТ 34.10.2001 (тогда еще) от RSA многие знали. Хотя, полагаю, наше высшее руководство не сильно в этом разбиралось.
> А раньше схема с CSR работала исправно, и лишь в декабре обнаружилось, что подобный функционал перестал работать?
Да.
> Мои коллеги в те времена понимали суть, а у некоторых было образование по профилю ИБ
Вы имеете ввиду разрабов или менеджеров по продажам и поддержку? Я о последних. Мне приходится каждому краткий курс криптографии рассказывать для того, чтобы они иной раз поняли, что мне надо.
Да.
> Мои коллеги в те времена понимали суть, а у некоторых было образование по профилю ИБ
Вы имеете ввиду разрабов или менеджеров по продажам и поддержку? Я о последних. Мне приходится каждому краткий курс криптографии рассказывать для того, чтобы они иной раз поняли, что мне надо.
>Да.
Тогда происходящее выглядит каким-то натуральным вредительством. Сломали систему выдачи сертификатов по CSR, и не объясняют происходящее. Это сложно объяснить человеческой ошибкой или глупостью, поскольку видны намеренные шаги по отключению такого функционала, и остается только вариант с недобросовестным поведением. Спасибо. Из статьи было не совсем очевидно, сломали ли они это или просто не запилили, вкрутив тупую заглушку.
>Вы имеете ввиду
Исключительно поддержку. С продажниками не особо контактировал и уже не очень помню, занимались ли они выпуском сертификатов на токенах. Но помню, что периодически приходилось это делать, в том числе, в рамках установки ПО на оборудование клиентов. Видимо, в разных компаниях очень разный подход к тому, что должны знать сотрудники.
Тогда происходящее выглядит каким-то натуральным вредительством. Сломали систему выдачи сертификатов по CSR, и не объясняют происходящее. Это сложно объяснить человеческой ошибкой или глупостью, поскольку видны намеренные шаги по отключению такого функционала, и остается только вариант с недобросовестным поведением. Спасибо. Из статьи было не совсем очевидно, сломали ли они это или просто не запилили, вкрутив тупую заглушку.
>Вы имеете ввиду
Исключительно поддержку. С продажниками не особо контактировал и уже не очень помню, занимались ли они выпуском сертификатов на токенах. Но помню, что периодически приходилось это делать, в том числе, в рамках установки ПО на оборудование клиентов. Видимо, в разных компаниях очень разный подход к тому, что должны знать сотрудники.
В подавляющем большинстве случаев у юрлиц директор поручает получить сертификат кому-то из подчиненых, стряпается доверка, подчиненный получает ЭП и пользуется им (например, в бухгалтерии для подписания отчетов в органы). А директор этот ключ ни разу и не держал. Какая там криптография? О чём вы?
Это идиотизм наших проверяющих и контролирующих органов на мой взгляд. большая часть отчетных документов (если не все) должна быть за подписью директора. Зачем?! для чего?! Почему в тот же ФНС нельзя завести доверенное лицо для сдачи отчетности в электронном виде, например главбуха? Казначейство тоже туда же… В результате, если директор все будет подписывать ЭП, он только этим и будет заниматься, поэтому и передают ЭП кому ни попадя, типа юриста/главбуха… но это трэш угар и содомия, я согласен…
Не согласный я. Директор несет в конечном счете львиную долю ответственности. Поэтому его подпись там должна быть. Разводить цирк с доверенностями никто не хочет — это и понятно. В конце концов иногда всё же стоит взглянуть на то, что передаётся в отчете. Я несколько раз буха в ошибках уличал.
Несколько лет назад был период, когда всех массово загоняли на Госуслуги.
Прибегали директора бюджетных учреждений срочно зарегистрироваться и тащили свой коллектив.
Так сами директора с удивлением узнавали, что они то давно уже зарегистрированы на Портале и подтверждены с помощью ЭП. Потому что позиция директоров была — я что вам должен каждую бумажку на каких-то непонятных контурах и закупках подписывать?
Прибегали директора бюджетных учреждений срочно зарегистрироваться и тащили свой коллектив.
Так сами директора с удивлением узнавали, что они то давно уже зарегистрированы на Портале и подтверждены с помощью ЭП. Потому что позиция директоров была — я что вам должен каждую бумажку на каких-то непонятных контурах и закупках подписывать?
Есть такое подозрение, что кто-то из абонентов не смог расшифровать какой-нибудь огромный (гигабайт-два) важный файл (у встроенных ключей в этом плане могут быть свои особенности), соответственно не смог вовремя подготовить какой-то документ и крупно попал. Генерировать ключевую пару на стороне клиента можно. Но важно, чтобы для расшифровки не требовалось гонять здоровые файлы через USB-интерфейс хиленького защищённого носителя только потому, что закрытый ключ оттуда для этого не вытащишь и не сделаешь операцию на намного более производительном CPU.
Есть такое подозрение, что шифрование происходит на симметричных ключах )) ГОСТ 28147-89 и всё такое. А в процессе общения с поддержкой Рутокена и обсуждения таких вопросов я как-то выяснил, что после того, как добыт симметричный ключ, дешифрация происходит на хосте программно. Так что нет.
Кроме того, когда юзер добрался до таких тонкостей, о которых пишу я, то это означает, что он в курсе всего того, что он делает и сам себе дурак. В любом случае УЦ не отвечает за использование пользователем ключа и сертификата.
Кроме того, когда юзер добрался до таких тонкостей, о которых пишу я, то это означает, что он в курсе всего того, что он делает и сам себе дурак. В любом случае УЦ не отвечает за использование пользователем ключа и сертификата.
*удалено, не туда ответил*
НЛО прилетело и опубликовало эту надпись здесь
Специально для вас в посте жирным шрифтом выделена единственная фраза. Никто не простит УЦ поддерживать или не поддерживать ФКН. Для них это вообще говоря прозрачно. Они не знают и не должны знать о том, как и где вы храните свои ключи.
То, что возможность сгенерировать ключ не доступна — является не отсутствием действия по поддержке, а очевидным активным противодействием. В июне я выпускал сертификат и генерировал пару у себя и всё работало, как и предполагалось, потому что УЦ никак не парился о том, что у меня за носитель.
То, что возможность сгенерировать ключ не доступна — является не отсутствием действия по поддержке, а очевидным активным противодействием. В июне я выпускал сертификат и генерировал пару у себя и всё работало, как и предполагалось, потому что УЦ никак не парился о том, что у меня за носитель.
Обычный ход против конкурентов. Врядли они сливают ключи, банально обрубили возможность пользоваться другими криптопровайдерами.
Дружище, почитайте мои публикации. Я никакой не конкурент, я простой юзер. Ну ок, не простой, а понимающий как работает криптография. Более того, в этом посте я даже их хвалил и призывал им пользоваться.
> возможность пользоваться другими криптопровайдерами
Ох… криптопровайдер-то во всех случаях один — Крипто Про. Вы сколько раз в жизни пользовались электронной подписью по ГОСТу?
> возможность пользоваться другими криптопровайдерами
Ох… криптопровайдер-то во всех случаях один — Крипто Про. Вы сколько раз в жизни пользовались электронной подписью по ГОСТу?
Да разве? А инфотексовский VipNet CSP уже не в счёт?
Что инфотексовский VipNet CSP? В какой счёт вы предлагаете его включить? В счёт криптопровайдеров, доступных на рынке? Ок, включаем. Только у меня на компе его нет (стоял года четыре назад, но сейчас система новая). Поэтому хоть запрещай, хоть не запрещай его использование — это никак не относится к посту.
Можно ли запускать весь этот крипто-софт в виртуальной машине? Тогда на хосте ничего не сломается.
Был у нас с Тензором один неприятный случай до нового года. Написал о нем письмо в МинЦифру, попросил разъяснить :) На вопрос не ответили, но обещали когда нибудь разобраться :) Суть конфликта ниже (выдержка из письма):
Не знаю насколько это случай серьезный. Прав ли я в своих подозрениях, но бесит то что сам тензор никак не среагировал и ничего не объяснил :( Ну хоть бы успокоил, рассказал бы в чем я не прав :(
Наша организация является пользователем сервиса СБИС (http://sbis.ru/), компании Тензор. В середине октября 2019 года для ООО «ХХХ», в связи с изменением фамилии директора, в удостоверяющем центре (УЦ) компании Тензор в городе ХХХХ была сгенерирована ЭП на носитель рутокен. После этого, на портале СБИС появилась эта новая ЭП. При просмотре ее свойств мы обратили внимание на надпись: записан на реестр компьютера KOMPUKTER. Так как мы не копировали ЭП на какой-либо компьютер, я обратилась в службу техподдержки с вопросом, что это значит и как так получилось. Сотрудник техподдержки объяснил мне, что вероятно мы сделали копию в реестр ПК сами, что это за ПК сотрудник не знает.
Надпись «записан на реестр компьютера KOMPUKTER» являлась гиперссылкой и открывала окно в котором отображались все электронные подписи которые установлены в реестр компьютера «KOMPUKTER». Там множество ЭЦП различных ХХХ-ских фирм и предпринимателей. Исходя из полученных данных я предпологаю что сотрудники удостоверяющего центра компании Тензор в городе ХХХХ делают копии ключей на свои ПК.
Мной 24.10.2019 было написано письмо в компанию Тензор на эл. почту tensor@tensor.ru с просьбой разъяснить данную ситуацию. До настоящего времени ответа от компании Тензор не получено. Однако, в интерфейсе сервиса СБИС произошли изменения, надпись о копии в реестр постороннего ПК была исправлена компанией Тензор на другую. Таким образом, после моего обращения были произведены действия, которые убрали следы описанной мной проблемы.
Я считаю, что сотрудниками УЦ компании Тензор в г. ХХХХ были нарушены требования по хранению сертификатов ключей ЭП, а все указанные ЭП являются скомпрометированными и требуют отзыва.
Не знаю насколько это случай серьезный. Прав ли я в своих подозрениях, но бесит то что сам тензор никак не среагировал и ничего не объяснил :( Ну хоть бы успокоил, рассказал бы в чем я не прав :(
Подозреваю, что люди хотели сделать добро.
Стандартная вещь — люди приперлись со флешкой. Им ЭП туда записали. Придя к себе люди воткнули флешку в коротящий юсб порт.
Мы у себя специально человеку показываем, что запись на флешке есть. Также через криптопро, что контейнер есть. И предупреждаем — ребята — если вы что-то со флешкой сделаете, то это будет ваша проблема. Вам никто ничего не восстановит — будете покупать новую ЭП.
Здесь же граждане очевидно решили нести добро и делать бэкап ключа, чтобы можно было записать его людям снова. Что понятно неправильно.
Но как говорится: не делай добра, не получишь зла.
Думаю, что после жалобы так они делать не будут.
Стандартная вещь — люди приперлись со флешкой. Им ЭП туда записали. Придя к себе люди воткнули флешку в коротящий юсб порт.
Мы у себя специально человеку показываем, что запись на флешке есть. Также через криптопро, что контейнер есть. И предупреждаем — ребята — если вы что-то со флешкой сделаете, то это будет ваша проблема. Вам никто ничего не восстановит — будете покупать новую ЭП.
Здесь же граждане очевидно решили нести добро и делать бэкап ключа, чтобы можно было записать его людям снова. Что понятно неправильно.
Но как говорится: не делай добра, не получишь зла.
Думаю, что после жалобы так они делать не будут.
Такая мысль мне приходила. Возможно что на месте это решил делать какой то конкретный специалист, вряд ли это политика организации. Я посмотрел список ключей на той машине — там кого только не было, и ИП и муниципальные предприятия. А вдруг они с этим специалистом разойтись подоброму не смогут :) мало ли что он может этими ключами натворить в гневе.
И еще в ответном письме от Минцифры была отсылка к пункту 1 части 6 статьи 17 ФЗ №63-ФЗ:
Слово «обязан» меня пугает. Когда я вижу слово «обязан» и не делаю этого, либо знаю что кто то другой обязан — но не знает об этом, я чувствую себя преступником :)
Вот например кучка небольшая муниципальных организаций ключи которых были так же сохранены на том компе. можно же предположить что они тоже скомпрометированы? Но они об этом не знают — не буду же я каждым звонить и это рассказывать. Минцифра наверное тоже не будет это делать пока не убедится в этом хотя бы на основании моего заявления.
Нужно ли предупредить государство в лице прокуратуры о возможном преступлении? вот не знаю :(
И еще в ответном письме от Минцифры была отсылка к пункту 1 части 6 статьи 17 ФЗ №63-ФЗ:
6. Владелец квалифицированного сертификата обязан:
1) не использовать ключ электронной подписи и немедленно обратиться в аккредитованный удостоверяющий центр, выдавший квалифицированный сертификат, для прекращения действия этого сертификата при наличии оснований полагать, что конфиденциальность ключа электронной подписи нарушена;
Слово «обязан» меня пугает. Когда я вижу слово «обязан» и не делаю этого, либо знаю что кто то другой обязан — но не знает об этом, я чувствую себя преступником :)
Вот например кучка небольшая муниципальных организаций ключи которых были так же сохранены на том компе. можно же предположить что они тоже скомпрометированы? Но они об этом не знают — не буду же я каждым звонить и это рассказывать. Минцифра наверное тоже не будет это делать пока не убедится в этом хотя бы на основании моего заявления.
Нужно ли предупредить государство в лице прокуратуры о возможном преступлении? вот не знаю :(
Не нужно. Наше любимое государство сейчас хочет сделать супергосударственные УЦ.
Как все это будет работать, думаю многие представляют на примере УЦ от Федерального казначейства. И вот такие жалобы будут хорошим поводом для закрытия частных УЦ, сформировавших как и рынок, так и вообще пользовательскую базу.
Как все это будет работать, думаю многие представляют на примере УЦ от Федерального казначейства. И вот такие жалобы будут хорошим поводом для закрытия частных УЦ, сформировавших как и рынок, так и вообще пользовательскую базу.
В моей прошлой статье это разбирали. Государственный УЦ будет только для сертификатов юрлиц. Под документом будут требоваться две подписи — подпись юрлица и подпись ответственного физлица. Физики будут получать свои подписи в коммерческих УЦ. По крайней мере до эры электронного паспорта гражданина…
Интересно, есть ли где статистика по ЭП, полученных физлицами?
Т.е. для своих нужд как обычного гражданина? На моей памяти (мы в своей работе предлагаем народу в том числе рекламу определенного УЦ) — за последние три года физлицами было куплено 5 ЭП. 4 школьника, которым она была нужна для отправки документов в ВУЗ по электронке. И я сам один раз, чтобы также по электронке писать разные жалобы.
Обычно покупают именно конторы, для своих работников и для рабочих нужд. А это все улетает в государственный УЦ.
Т.е. для своих нужд как обычного гражданина? На моей памяти (мы в своей работе предлагаем народу в том числе рекламу определенного УЦ) — за последние три года физлицами было куплено 5 ЭП. 4 школьника, которым она была нужна для отправки документов в ВУЗ по электронке. И я сам один раз, чтобы также по электронке писать разные жалобы.
Обычно покупают именно конторы, для своих работников и для рабочих нужд. А это все улетает в государственный УЦ.
Дружба начинается с улыбки, а востребованность в ЭП — с возможности её применить. На текущий момент уже много вещей можно делать. Можно регать юрлица, можно подавать в суд (не ниже уровня районного, правда). В публикациях у меня гляньте про опыт с регистрацией недвижимости. Короче, со временем это будет наростать.
Организациям это тоже долго было бы не нужно, если бы не обязаловка сдавать отчетность в эл.виде (если не микропредприятие) и иный виды обязаловки.
Организациям это тоже долго было бы не нужно, если бы не обязаловка сдавать отчетность в эл.виде (если не микропредприятие) и иный виды обязаловки.
У ФНС есть ЭП для подписания заявлений в ЛК. Никто не мешает создать функционал ЭП на Госуслугах.
Тем более, что на госсайтах и так авторизация через Госуслуги.
Зачем тогда физику ЭП вообще? Вход через ЕСИА есть. Только для общения с кем-то негосударственным? Регистрация недвижимости? Так изначально предлагали изменения в 63-ФЗ именно о том, чтобы ЭП была одна. Чтобы не было всей этой порнографии, что в Росреестр нужна своя подпись, на закупки своя, в какой-нибудь там Сбер третья. Но вот именно этого, судя по вашему посту про изменения в 63-ФЗ так и нет.
Основной потребитель ЭП — это ИП и юрлица. И вот это все государство хочет отжать себе.
Тем более, что на госсайтах и так авторизация через Госуслуги.
Зачем тогда физику ЭП вообще? Вход через ЕСИА есть. Только для общения с кем-то негосударственным? Регистрация недвижимости? Так изначально предлагали изменения в 63-ФЗ именно о том, чтобы ЭП была одна. Чтобы не было всей этой порнографии, что в Росреестр нужна своя подпись, на закупки своя, в какой-нибудь там Сбер третья. Но вот именно этого, судя по вашему посту про изменения в 63-ФЗ так и нет.
Основной потребитель ЭП — это ИП и юрлица. И вот это все государство хочет отжать себе.
Физикам налоговый вычет получать…
> У ФНС есть ЭП для подписания заявлений в ЛК. Никто не мешает создать функционал ЭП на Госуслугах.
крайний раз, когда я использовал (точнее пытался) ФНСную неквалифицированную подпись, то у них не работала фича с хранением подписи у себя и работой через ViPNeT CSP. Только облако.
> Зачем тогда физику ЭП вообще?
Есть действия, которые влекут физику только профит. Например, подать заяву о назначении пособия. Тут ЭП не нужна. Точнее нужна «простая ЭП» (в терминах 63-ФЗ) — логин/пароль. А есть действия, которые на тебя накладывают некоторые обязательства или (потенциально) лишают тебя чего-то. Примеры
И так далее. То есть действия, которые ты потенциально затем захочешь опротестовать. И тогда тебе нужно будет сунуть под нос доказательство, что конкретно ты сделал конкретно это действие.
> Чтобы не было всей этой порнографии, что в Росреестр нужна своя подпись, на закупки своя, в какой-нибудь там Сбер третья.
Эту пидоросню развели УЦшки в сговоре с другими участниками.
> Но вот именно этого, судя по вашему посту про изменения в 63-ФЗ так и нет.
Это было и в старой редакции, но как я понимаю, было сформулировано с дыркой. Правка есть в новой редакции. Есть ли в ней дырка — покажет время.
> И вот это все государство хочет отжать себе.
Нет, цели тут другие. Государству от этого только доп.геморрой.
крайний раз, когда я использовал (точнее пытался) ФНСную неквалифицированную подпись, то у них не работала фича с хранением подписи у себя и работой через ViPNeT CSP. Только облако.
> Зачем тогда физику ЭП вообще?
Есть действия, которые влекут физику только профит. Например, подать заяву о назначении пособия. Тут ЭП не нужна. Точнее нужна «простая ЭП» (в терминах 63-ФЗ) — логин/пароль. А есть действия, которые на тебя накладывают некоторые обязательства или (потенциально) лишают тебя чего-то. Примеры
- Продажа квартиры
- Перевод накопительной части пенсии в другой фонд
И так далее. То есть действия, которые ты потенциально затем захочешь опротестовать. И тогда тебе нужно будет сунуть под нос доказательство, что конкретно ты сделал конкретно это действие.
> Чтобы не было всей этой порнографии, что в Росреестр нужна своя подпись, на закупки своя, в какой-нибудь там Сбер третья.
Эту пидоросню развели УЦшки в сговоре с другими участниками.
> Но вот именно этого, судя по вашему посту про изменения в 63-ФЗ так и нет.
Это было и в старой редакции, но как я понимаю, было сформулировано с дыркой. Правка есть в новой редакции. Есть ли в ней дырка — покажет время.
> И вот это все государство хочет отжать себе.
Нет, цели тут другие. Государству от этого только доп.геморрой.
Эх, влетел кто-то на огромную сумму :(
Почему-то некоторые люди считают, что если ключ генерируется оффлайн и наружу передаётся только запрос на сертификат, то утечка ключа невозможна. На самом деле, если код, генерирующий ключи, может содержать закладки, то ключ можно передать в самом запросе, причём так, что это будет невозможно обнаружить, если не производить полный анализ этого кода (в частности, такую закладку невозможно обнаружить, исследуя сам запрос). Если интересно, как это делается, рекомендую прочитать книгу Malicious Cryptography: Exposing Cryptovirology (к сожалению, я не нашёл русского перевода).
Впрочем, это далеко не единственная проблема ПО СБИС. Например, их плагин при установке добавляет в систему доверенный корневой сертификат, одинаковый для всех пользователей (см. инструкцию, там на скриншоте sha1-отпечаток сертификата, и он одинаковый для всех пользователей, то есть и сам сертификат один на всех). Поскольку этот сертификат используется для связи с работающим локально плагином, приватный ключ, скорее всего, тоже присутствует на компьютере пользователя. То есть, это плагин делает по сути то же самое, что и нашумевшее в своё время ПО Superfish: позволяет кому угодно прослушивать весь зашифрованный трафик.
Закрытый ключ можно передать прямо в открытом ключе: https://habr.com/ru/post/248269/
ЕМНИП, для этого требуется иметь доступ к коду генератора ключа. Тут есть два момента:
1) Крипто-Про сертифицирован ФСБ и конкретный релиз имеет конкретные контрольные суммы. Да, ФСБ доверять не нужно, но скорее всего это исключает то, что такая возможность есть у Тензора
2) В случае же с аппаратными ключами всё ещё сложнее — генерация происходит внутри. Такой трюк можно провернуть только работая в связке с производителем токена.
Но вообще я нигде не писал, что «если ключ генерируется оффлайн и наружу передаётся только запрос на сертификат, то утечка ключа невозможна». Просто это уже совсем другая модель злоумышленника.
1) Крипто-Про сертифицирован ФСБ и конкретный релиз имеет конкретные контрольные суммы. Да, ФСБ доверять не нужно, но скорее всего это исключает то, что такая возможность есть у Тензора
2) В случае же с аппаратными ключами всё ещё сложнее — генерация происходит внутри. Такой трюк можно провернуть только работая в связке с производителем токена.
Но вообще я нигде не писал, что «если ключ генерируется оффлайн и наружу передаётся только запрос на сертификат, то утечка ключа невозможна». Просто это уже совсем другая модель злоумышленника.
Про СБИС — спасибо. Не анализировал его работу на столько глубоко. Запускаю его только на видвой помойке, где нет ничего ценного. Интереса ради: где тебе пришлось так глубоко разобраться с этим СБИСом?
а скрин успели сдетать с компуктером?
наверное, вам стоит адресовать вопрос автору комментария, а не на верхний уровень
Успели
тогда ждем развития событий, хотя думаю просто промолчат и все.
Отмажутся тем, что автор видел реестр выданных сертификатов.
Судя по тому что tensor_sbis отметился в обсуждении по существу статьи, но не заметил некоторых комментариев, вариант «промолчат» — выглядит очень вероятным :) Либо это реальный косяк и втягиваться в диалог просто невыгодно.
Возможно на марсе есть жизнь, возможно мы все умрем от короновируса, возможно автор статьи не уступает место в автобусе пожилым людям и инвалидам, а возможно автор террорист. Мне вот кажется, что криптоправайдеры или операционные системы сливают всю инфу своим разработчикам, а гост шифрование нужно только для того, чтобы наши спецслужбы, а не пендосовские имели к нему доступ. У нас ведь не америка, можно плевать по сторонам без опасений что засудят или предъявят. Ведь так сложно посмотреть что и куда пересылается по «зашифрованному» каналу. Уверен автор не упустил бы возможность обратиться в компетентные органы если имел хоть какие то факты. Но зачем, ведь гораздо проще написать громкий заголовок и переживания за то чего не видно, но может быть на самом деле.
А давайте посмотрим кому это выгодно. Красная нить статьи о том, что злой СБИС, несмотря на усилия автора и криптоправайдера (который о чудо проникся подозрениями «рядового» пользователя), дважды отнял у бедных пользователей возможности нового продукта последнего. Теперь посмотрим о чем у нас большинство статей автора и подумаем где он работает.
Вам бы в комсомольскую правду публиковаться, здесь то зачем это.
P.S. Если уж автор и криптопровайдер не смогли посмотреть «зашифрованный» трафик, значит пора менять телеграм на СБИС )))
А давайте посмотрим кому это выгодно. Красная нить статьи о том, что злой СБИС, несмотря на усилия автора и криптоправайдера (который о чудо проникся подозрениями «рядового» пользователя), дважды отнял у бедных пользователей возможности нового продукта последнего. Теперь посмотрим о чем у нас большинство статей автора и подумаем где он работает.
Вам бы в комсомольскую правду публиковаться, здесь то зачем это.
P.S. Если уж автор и криптопровайдер не смогли посмотреть «зашифрованный» трафик, значит пора менять телеграм на СБИС )))
> Ведь так сложно посмотреть что и куда пересылается по «зашифрованному» каналу
В общем случае этого нельзя сделать. В частном случае, если они используют стандартный системный SSL, не юзают пиннинг сертификатов, то можно, конечно, поставить левый CA, подсунуть свой прокси и сдампить. Но это не предмет пятиминутного исследования. На серьезное исследование эта статья не претендует. Будет чего серьезнее, заголовок не будет начинаться со слова «возможно».
> Теперь посмотрим о чем у нас большинство статей автора и подумаем где он работает.
И где я работаю?
> Вам бы в комсомольскую правду публиковаться, здесь то зачем это.
Вам бы пройти в афедрон Жозефины Павловны с вашими советами о том, что мне делать )
В общем случае этого нельзя сделать. В частном случае, если они используют стандартный системный SSL, не юзают пиннинг сертификатов, то можно, конечно, поставить левый CA, подсунуть свой прокси и сдампить. Но это не предмет пятиминутного исследования. На серьезное исследование эта статья не претендует. Будет чего серьезнее, заголовок не будет начинаться со слова «возможно».
> Теперь посмотрим о чем у нас большинство статей автора и подумаем где он работает.
И где я работаю?
> Вам бы в комсомольскую правду публиковаться, здесь то зачем это.
Вам бы пройти в афедрон Жозефины Павловны с вашими советами о том, что мне делать )
Вы уж простите — совет что вам делать явно был лишним.
Где вы работаете я не знаю, да и не моё это дело, однако простой пользователь криптопрайдеру может только написать, а Вы за 5 минут и совместное расследование, что тут остается думать — как будто сидите рядом.
Я предлагаю прекратить эти предположения, обратиться к eatmore, т.к. он видимо знает как по «одинаковому корневому» весь зашифрованный трафик слушать, и вывести эти УЦ и криптопровайдеры на чистую воду.
Где вы работаете я не знаю, да и не моё это дело, однако простой пользователь криптопрайдеру может только написать, а Вы за 5 минут и совместное расследование, что тут остается думать — как будто сидите рядом.
Я предлагаю прекратить эти предположения, обратиться к eatmore, т.к. он видимо знает как по «одинаковому корневому» весь зашифрованный трафик слушать, и вывести эти УЦ и криптопровайдеры на чистую воду.
> а Вы за 5 минут и совместное расследование
Если бы. 4 дня переписывались. А так-то да. Криптопровайдер — птица гордая. Целый форум завела, чтобы им никто не писал. Ну или писал, но можно было б не отвечать.
> он видимо знает
Одно дело знать, другое дело — сделать. Вас почитать, так это так раз плюнуть — между двумя вашими каментами могли бы уже и сами весь СБИС на изнанку вывернуть и выпотрошить.
Если бы. 4 дня переписывались. А так-то да. Криптопровайдер — птица гордая. Целый форум завела, чтобы им никто не писал. Ну или писал, но можно было б не отвечать.
> он видимо знает
Одно дело знать, другое дело — сделать. Вас почитать, так это так раз плюнуть — между двумя вашими каментами могли бы уже и сами весь СБИС на изнанку вывернуть и выпотрошить.
Вы правда не понимаете, что генерация ключепары кроме как на токене, подключённом к изолированной от сети машине — небезопасна?
Ладно еще если у СБИСа HSMы. Но судя по всему, у них ключи просто валяются в незащищенном хранилище, что открытые, что закрытые.
В ситуации, когда ЭЦП придаётся юридическая значимость — это вопиющая халатность и некомпетентность.
Один раз случайно удалил закрытый ключ с Рутокена до момента генерации нового. Специалист из Тензора по удаленному рабочему столу откуда-то со своего рабочего места скопировал мне старый ключ на комп и установил в реестр. Хз что это было, но доступ я вернул не вставая с места.
А уважаемый автор не пояснит фразу "в конце декабря 2019-го, я обнаружил, что возможность генерации ключей на «умных» ключевых носителях каким-то образом отключена".? И что вы считаете "умными" носителями? Рутокен ЭЦП 2.0/Джакарта 2??
> А уважаемый автор не пояснит фразу «в конце декабря 2019-го, я обнаружил, что возможность генерации ключей на «умных» ключевых носителях каким-то образом отключена».?
В момент генерации предлагается выбрать на каком носителе сохранить ключевую пару. В этот момент выскакивает окно криптопровайдера. Так вот — криптопровайдер видел умные токены, но либо помечал их как запрещенными к использованию в системе, либо (как в случае Рутокен ЭЦП 2.0) предлагал использовать его, но только в режиме тупого носителя.
> И что вы считаете «умными» носителями? Рутокен ЭЦП 2.0/Джакарта 2??
Это носители, имеющие криптографию на борту. Рутокен ЭЦП 2.0 или даже ещё круче — Рутокен ЭЦП 2.0 3000. С джакартами не работал, но и у них должны быть и у аладина тоже.
В момент генерации предлагается выбрать на каком носителе сохранить ключевую пару. В этот момент выскакивает окно криптопровайдера. Так вот — криптопровайдер видел умные токены, но либо помечал их как запрещенными к использованию в системе, либо (как в случае Рутокен ЭЦП 2.0) предлагал использовать его, но только в режиме тупого носителя.
> И что вы считаете «умными» носителями? Рутокен ЭЦП 2.0/Джакарта 2??
Это носители, имеющие криптографию на борту. Рутокен ЭЦП 2.0 или даже ещё круче — Рутокен ЭЦП 2.0 3000. С джакартами не работал, но и у них должны быть и у аладина тоже.
На мой взгляд, в условиях отсутствия доверия к действиям УЦ нужно пользоваться защитой действующего законодательства, а именно:
1. Согласно 63-ФЗ УЦ (как юр. лицо) должно пользоваться сертифицированными средствами УЦ (софта) и электронной подписи (софта). Использование сертифицированных средств, это не только наличие софта с контрольными суммами, как у образцов предоставленных в ФСБ России при сертификации, но и обязательное соблюдение (требование ПКЗ-2005, ФАПСИ 152) документации к ним. В частности, плагины использующие СКЗИ должны пройти процедуру контроля корректности встраивания. ТЗ на встраиванием согласовывает ФСБ, саму процедуру проводит специализированная организация, как правило производитель СКЗИ, в частности ООО КриптоПро. Требования контроля корректности встраивания определены для всех (что я видел) СКЗИ и прописаны в документации на СКЗИ. Письмо ФСБ вам в помощь. В случае не реализации данных обращаться в ФСБ России.
2. Определить кто (какое ЮЛ) является разработчиком плагина. Определить имеется ли у данного лица лицензия по ПП-313 на право осуществления подобной деятельности. Даже не сколько лицензия, а соответствующий пункт в лицензии — 2 или 3 по Приложению 1 к ПП-313. Если подобного пункта нет, ст. 171 УК РФ вам в помощь.
3. В соответствии с 98-ФЗ ввести в отношении криптоключей и сведений о них режим коммерческой тайны. Проинформировать о данном перечне УЦ.
4. Если после (3) вы обнаружите факт того, УЦ обладает сведениями о том, на каком компьютере используются те или иные криптоключи, как в этом комментарии. И при этом вы эти сведения не передавали, то ст. 183 УК РФ вам в помощь.
5. Провести сверку действий УЦ с его регламентом, а также нормативными документами ПКЗ-2005, ФАПСИ 152. В случае наличий расхождений обращаться в жалобой в ФСБ России и МинКомСвязи.
1. Согласно 63-ФЗ УЦ (как юр. лицо) должно пользоваться сертифицированными средствами УЦ (софта) и электронной подписи (софта). Использование сертифицированных средств, это не только наличие софта с контрольными суммами, как у образцов предоставленных в ФСБ России при сертификации, но и обязательное соблюдение (требование ПКЗ-2005, ФАПСИ 152) документации к ним. В частности, плагины использующие СКЗИ должны пройти процедуру контроля корректности встраивания. ТЗ на встраиванием согласовывает ФСБ, саму процедуру проводит специализированная организация, как правило производитель СКЗИ, в частности ООО КриптоПро. Требования контроля корректности встраивания определены для всех (что я видел) СКЗИ и прописаны в документации на СКЗИ. Письмо ФСБ вам в помощь. В случае не реализации данных обращаться в ФСБ России.
2. Определить кто (какое ЮЛ) является разработчиком плагина. Определить имеется ли у данного лица лицензия по ПП-313 на право осуществления подобной деятельности. Даже не сколько лицензия, а соответствующий пункт в лицензии — 2 или 3 по Приложению 1 к ПП-313. Если подобного пункта нет, ст. 171 УК РФ вам в помощь.
3. В соответствии с 98-ФЗ ввести в отношении криптоключей и сведений о них режим коммерческой тайны. Проинформировать о данном перечне УЦ.
4. Если после (3) вы обнаружите факт того, УЦ обладает сведениями о том, на каком компьютере используются те или иные криптоключи, как в этом комментарии. И при этом вы эти сведения не передавали, то ст. 183 УК РФ вам в помощь.
5. Провести сверку действий УЦ с его регламентом, а также нормативными документами ПКЗ-2005, ФАПСИ 152. В случае наличий расхождений обращаться в жалобой в ФСБ России и МинКомСвязи.
И так придётся делать при продлении каждого сертификата. Каждый год. Год потратить на принуждение, год попользоваться )))
Это правильная инструкция. Если хочешь, чтобы всё было по закону, то и понуждать к исполнению инструкций тоже нужно по закону. А простой жизни никто не обещал, это да :)
Она весьма неполна. К примеру: как вы будете доказывать п. 4 по обвинению УЦ в нарушении ст. 183 УК РФ? Точнее не так. Доказывать-то будете не вы, а государственный обвинитель. А вы уверены, что он вообще въедет в тему с криптографией так, что сможет не мямлить, а резать правду матку? Я вот на 95% уверен, что нет.
Добрый день.
У автора, как и написано в заголовке, 100% оценочное суждение и небольшой недостаток информации. Будучи человеком, отвечающим в КриптоПро за работу с токенами, выскажу своё мнение. Думаю, оно не будет сильно отличаться от официального.
1) КриптоПро уже больше 10 лет выпускает провайдеры, работающие с неизвлекаемыми ключами. Они называются ФКН (Рутокен CSP, Jacarta CSP, Magistra CSP и т.д.). Если пользователей волновало именно использование неизвлекаемых ключей, они покупали ФКН. В CSP 5.0 просто объединили ФКН-провайдеры и "базовый".
2) Слухи о безопасности "обычных" неизвлекаемых ключей сильно преувеличены. Может, токен и не даёт ключу утечь, но без защищенного канала вредонос может послать пару команд и подписать на токене сам что-угодно, тк в большинстве случаев пароль предъявляется в "голом" виде и может быть заснифферен проще ключей. Хотите безопасности — используйте токены с защищённом каналом.
3) Не думаю, что у Тензора была какая-то злая воля (хотя, конечно, бесит, что до сих пор нам даже сроков исправления не назвали). Скорее, логика такая: людей с CSP 4.0 (там нет неизвлекаемых ключей) намного больше, поэтому пока, чтобы не получилось ситуации, в которой человек не может пользоваться ключом в старом провайдере, сделаем плавный переход, запретив работу с неизвлекаемыми ключами. О том, что это может мешать, никто не подумал. Собственно, я добавил функциональность, которой они так "злобно" пользуются, по просьбе других клиентов ровно для решения данной задачи.
4) Вообще говоря, возможность архивирования ключей — штатная вещь в интерфейсе криптографии CryptoAPI. Да, нельзя это делать без ведома пользователя, но учитывая низкую надёжность токенов (уж просто поверьте, постоянно отвечаем людям с такими проблемами) при должной защите это может быть неплохо. Например, почему бы не иметь шифрованный архив ключей корпоративного УЦ?
> 1) КриптоПро уже больше 10 лет выпускает провайдеры, работающие с неизвлекаемыми ключами.
Был у меня в своё время КриптоПро Рутен CSP. Иногда работал. На этом положительных отзывов больше нет. Обновлялся он отдельно от КриптоПро CSP. На версии 3.9, кажется, остановился. Для того, чтобы он работал, программа, которая использовала СКЗИ, должна была вызвать криптопровайдер с конкретным именем. У большинства софта (на то время по крайней мере) было захардкожено имя обычного (КриптоПро CSP) провайдера со всеми вытекающими.
Кроме того, для того, чтобы заиметь второй токен надо было покупать весь продукт, что тоже, имхо, бред. Только сейчас, с выпуском 5-й версии, идея ФКН стала жизнеспособной, пока не уперлась идиотизм УЦ.
> 2) Слухи о безопасности «обычных» неизвлекаемых ключей сильно преувеличены.
К сожалению у вас вообще всё на уровне слухов. Тот же протокол SESPAKE, которому вы целую RFCю написали, на самом деле не протокол, а концепция. Реальные реализации закрыты, протокол недокументирован. Провести аудит невозможно. Отличий от security by obscurity нет.
> 3) Не думаю, что у Тензора была какая-то злая воля (хотя, конечно, бесит, что до сих пор нам даже сроков исправления не назвали).
Выше уже пользователи написали кейсы, когда ключи, судя по всему становились достоянием Тензора.
> Скорее, логика такая: людей с CSP 4.0 (там нет неизвлекаемых ключей) намного больше, поэтому пока, чтобы не получилось ситуации, в которой человек не может пользоваться ключом в старом провайдере, сделаем плавный переход, запретив работу с неизвлекаемыми ключами.
Сейчас у вас это сделано вполне дуракоустойчиво. Купить по ошибке ФКН или переключить обычный Рутокен ЭЦП 2.0 в режим PKSC#11 довольно трудно. Кроме того, advanced-режим в таких случаях необходим.
> Собственно, я добавил функциональность, которой они так «злобно» пользуются, по просьбе других клиентов ровно для решения данной задачи.
И что? Может быть её как-то можно отключить через реестр? По типу EnabledOperationsForDisabledCarriers?
> Да, нельзя это делать без ведома пользователя
Не только ведома, но и его явного согласия или несогласия в таком случае.
> Например, почему бы не иметь шифрованный архив ключей корпоративного УЦ?
Мы не говорим о корпоративных УЦ. Ключ вполне себе имеет юридические последствия далеко за рамками организации.
Был у меня в своё время КриптоПро Рутен CSP. Иногда работал. На этом положительных отзывов больше нет. Обновлялся он отдельно от КриптоПро CSP. На версии 3.9, кажется, остановился. Для того, чтобы он работал, программа, которая использовала СКЗИ, должна была вызвать криптопровайдер с конкретным именем. У большинства софта (на то время по крайней мере) было захардкожено имя обычного (КриптоПро CSP) провайдера со всеми вытекающими.
Кроме того, для того, чтобы заиметь второй токен надо было покупать весь продукт, что тоже, имхо, бред. Только сейчас, с выпуском 5-й версии, идея ФКН стала жизнеспособной, пока не уперлась идиотизм УЦ.
> 2) Слухи о безопасности «обычных» неизвлекаемых ключей сильно преувеличены.
К сожалению у вас вообще всё на уровне слухов. Тот же протокол SESPAKE, которому вы целую RFCю написали, на самом деле не протокол, а концепция. Реальные реализации закрыты, протокол недокументирован. Провести аудит невозможно. Отличий от security by obscurity нет.
> 3) Не думаю, что у Тензора была какая-то злая воля (хотя, конечно, бесит, что до сих пор нам даже сроков исправления не назвали).
Выше уже пользователи написали кейсы, когда ключи, судя по всему становились достоянием Тензора.
> Скорее, логика такая: людей с CSP 4.0 (там нет неизвлекаемых ключей) намного больше, поэтому пока, чтобы не получилось ситуации, в которой человек не может пользоваться ключом в старом провайдере, сделаем плавный переход, запретив работу с неизвлекаемыми ключами.
Сейчас у вас это сделано вполне дуракоустойчиво. Купить по ошибке ФКН или переключить обычный Рутокен ЭЦП 2.0 в режим PKSC#11 довольно трудно. Кроме того, advanced-режим в таких случаях необходим.
> Собственно, я добавил функциональность, которой они так «злобно» пользуются, по просьбе других клиентов ровно для решения данной задачи.
И что? Может быть её как-то можно отключить через реестр? По типу EnabledOperationsForDisabledCarriers?
> Да, нельзя это делать без ведома пользователя
Не только ведома, но и его явного согласия или несогласия в таком случае.
> Например, почему бы не иметь шифрованный архив ключей корпоративного УЦ?
Мы не говорим о корпоративных УЦ. Ключ вполне себе имеет юридические последствия далеко за рамками организации.
1) Вообще говоря, большинство софта работает не с ключами, а с сертификатами. Имя провайдера находится в ссылке сертификата на закрытый ключ. Для низкоуровневой работы на уровне CryptoAPI 1.0, действительно, нужно писать другую константу (такое уж API), но пользовательский софт этого может и не знать.
2) SESPAKE — криптографический протокол, который прошел достаточные исследования и имеет доказанную стойкость (см., например, статью на Хабре). Аудит проводят сертифицирующие органы. В целом про исходники странный вопрос — у нас не open-source проект. Открытие реализации даже какой-то части (например, реализации SESPAKE) никак не позволит убедиться в том, что она вообще используется.
3) При большом количестве пользователей даже мера «не давать ошибиться в окне» не помогает.
4) Да, про архивацию полностью согласен. Одно дело, сохранять ключ, когда тебя просят (или когда ты делаешь это всегда, а пользователь в курсе), другое — кидать его втихую по почте.
2) SESPAKE — криптографический протокол, который прошел достаточные исследования и имеет доказанную стойкость (см., например, статью на Хабре). Аудит проводят сертифицирующие органы. В целом про исходники странный вопрос — у нас не open-source проект. Открытие реализации даже какой-то части (например, реализации SESPAKE) никак не позволит убедиться в том, что она вообще используется.
3) При большом количестве пользователей даже мера «не давать ошибиться в окне» не помогает.
4) Да, про архивацию полностью согласен. Одно дело, сохранять ключ, когда тебя просят (или когда ты делаешь это всегда, а пользователь в курсе), другое — кидать его втихую по почте.
> Имя провайдера находится в ссылке сертификата на закрытый ключ.
Осталось дело за малым — сгенирировать ключ. И тут-то вы и сталкиваетесь с тем, что:
1) УЦ открещивается от этого токена как от чумного
2) Для запроса на сертификат предоставляют ПО, которое:
> софт этого может и не знать.
> В целом про исходники странный вопрос — у нас не open-source проект.
Да нахрен ваши исходиники? ) Формата команд ISO 7816 достаточно. Я же говорю «протокол» — в смысле реализация SESPAKE (довольно абстрактной сущности) в виде конкретных полей команд и структур, а не реализация конретного протокола на языке программирования.
> Открытие реализации даже какой-то части (например, реализации SESPAKE) никак не позволит убедиться в том, что она вообще используется.
Думаю, что позволит. Wireshark с USB-pcap творят чудеса.
> При большом количестве пользователей даже мера «не давать ошибиться в окне» не помогает.
То есть вы находите, что защита идиотов важнее самой концепции «закрытый ключ знает только владелец»? )))
Осталось дело за малым — сгенирировать ключ. И тут-то вы и сталкиваетесь с тем, что:
1) УЦ открещивается от этого токена как от чумного
2) Для запроса на сертификат предоставляют ПО, которое:
> софт этого может и не знать.
> В целом про исходники странный вопрос — у нас не open-source проект.
Да нахрен ваши исходиники? ) Формата команд ISO 7816 достаточно. Я же говорю «протокол» — в смысле реализация SESPAKE (довольно абстрактной сущности) в виде конкретных полей команд и структур, а не реализация конретного протокола на языке программирования.
> Открытие реализации даже какой-то части (например, реализации SESPAKE) никак не позволит убедиться в том, что она вообще используется.
Думаю, что позволит. Wireshark с USB-pcap творят чудеса.
> При большом количестве пользователей даже мера «не давать ошибиться в окне» не помогает.
То есть вы находите, что защита идиотов важнее самой концепции «закрытый ключ знает только владелец»? )))
> Да нахрен ваши исходиники? ) Формата команд ISO 7816 достаточно. Я же говорю «протокол» — в смысле реализация SESPAKE (довольно абстрактной сущности) в виде конкретных полей команд и структур, а не реализация конретного протокола на языке программирования.
Ничего не понял. Команды реализуют токены, мы их зовем согласно документации. Вам станет легче, если я скажу, что команда 0x00, 0x80, 0x00, 0x01 делает первый шаг SESPAKE, а 0x00, 0x80, 0x00, 0x02 — второй? Как вы это верифицируете? Посмотрите на «похожесть» структур? А с чего вы будете уверены, что токен и провайдер установили именно тот ключ, что указан в протоколе, а не просто константу?
> То есть вы находите, что защита идиотов важнее самой концепции «закрытый ключ знает только владелец»? )))
Я живу в реальном мире, где нашим ПО пользуются в большинстве своем люди, которые не отличают закрытый ключ от открытого и на полном серьезе «подписывают сертификатами». Они относятся к переданному токену и криптопровайдеру не как к серьезному средству защиты, а как к формальности, навязанной «сверху». Для них, по моему мнению, важно максимально упростить переход на новые версии продукта по-максимуму обеспечивая совместимость.
Если же служба безопасности компании или сам пользователь понимают, чего они хотят и к чему это приведет в итоге, пусть выбирают неизвлекаемые режимы.
Повторюсь, вы напрасно считаете, что наличие закрытого ключа в памяти токена спасет от какого-то серьезного взлома. Утром вредонос перехватывает APDU для аутентификации на Рутокене и узнает пароль, вечером предъявляет его и подписывает документ. Это явно лучше обычного пассивного контейнера, т.к. нарушитель должен быть «активным», но я с трудом себе представляю адекватность подобного разделения возможностей в какой-либо худо-бедно близкой к реальности модели.
Ничего не понял. Команды реализуют токены, мы их зовем согласно документации. Вам станет легче, если я скажу, что команда 0x00, 0x80, 0x00, 0x01 делает первый шаг SESPAKE, а 0x00, 0x80, 0x00, 0x02 — второй? Как вы это верифицируете? Посмотрите на «похожесть» структур? А с чего вы будете уверены, что токен и провайдер установили именно тот ключ, что указан в протоколе, а не просто константу?
> То есть вы находите, что защита идиотов важнее самой концепции «закрытый ключ знает только владелец»? )))
Я живу в реальном мире, где нашим ПО пользуются в большинстве своем люди, которые не отличают закрытый ключ от открытого и на полном серьезе «подписывают сертификатами». Они относятся к переданному токену и криптопровайдеру не как к серьезному средству защиты, а как к формальности, навязанной «сверху». Для них, по моему мнению, важно максимально упростить переход на новые версии продукта по-максимуму обеспечивая совместимость.
Если же служба безопасности компании или сам пользователь понимают, чего они хотят и к чему это приведет в итоге, пусть выбирают неизвлекаемые режимы.
Повторюсь, вы напрасно считаете, что наличие закрытого ключа в памяти токена спасет от какого-то серьезного взлома. Утром вредонос перехватывает APDU для аутентификации на Рутокене и узнает пароль, вечером предъявляет его и подписывает документ. Это явно лучше обычного пассивного контейнера, т.к. нарушитель должен быть «активным», но я с трудом себе представляю адекватность подобного разделения возможностей в какой-либо худо-бедно близкой к реальности модели.
> Как вы это верифицируете?
Возьму и напишу тестовую программку, которая будет устанавливать с ключем соединение и просить его подписать тестовый хэш.
> Они относятся к переданному токену и криптопровайдеру не как к серьезному средству защиты, а как к формальности, навязанной «сверху»
Несомненно, сейчас так и есть. Но помните про «Создай систему, которой сможет пользоваться даже идиот, и только идиот захочет ей воспользоваться»?
> Если же служба безопасности компании или сам пользователь понимают, чего они хотят и к чему это приведет в итоге, пусть выбирают неизвлекаемые режимы.
Холмс, но как черт-возьми? Если вы сами даёте в руки этим варварам возможность отключать работу с неизвлекаемым режимом.
> Утром вредонос перехватывает APDU для аутентификации на Рутокене и узнает пароль
Выше, по-моему, вы писали, что ФКНы так не объегоришь.
Возьму и напишу тестовую программку, которая будет устанавливать с ключем соединение и просить его подписать тестовый хэш.
> Они относятся к переданному токену и криптопровайдеру не как к серьезному средству защиты, а как к формальности, навязанной «сверху»
Несомненно, сейчас так и есть. Но помните про «Создай систему, которой сможет пользоваться даже идиот, и только идиот захочет ей воспользоваться»?
> Если же служба безопасности компании или сам пользователь понимают, чего они хотят и к чему это приведет в итоге, пусть выбирают неизвлекаемые режимы.
Холмс, но как черт-возьми? Если вы сами даёте в руки этим варварам возможность отключать работу с неизвлекаемым режимом.
> Утром вредонос перехватывает APDU для аутентификации на Рутокене и узнает пароль
Выше, по-моему, вы писали, что ФКНы так не объегоришь.
> Возьму и напишу тестовую программку, которая будет устанавливать с ключем соединение и просить его подписать тестовый хэш.
Тогда запрашивайте у производителей описание APDU работы с токеном. Нам они передаются обычно под NDA.
> Холмс, но как черт-возьми? Если вы сами даёте в руки этим варварам возможность отключать работу с неизвлекаемым режимом.
Неочевидная аналогия. Сейчас весь мир для платежей использует чиповые EMV-карты, которые устанавливают SecureMessaging, аутентифицируют с помощью RSA и вообще прекрасны. Их проникновение в большинстве стран выше 90%. Кроме одной — США. Почему так? Ответ простой — США мощно развили систему платежей картами с магнитной полосой. Все понимают, что они менее безопасные, но перейти сходу на EMV невозможно — для этого требуются слишком большие затраты. Процесс перехода осторожно движется, но пока далек от завершения.
У нас ровно тоже самое. Криптопровайдер, который хранит ключи в пассивном виде, появился 20 лет назад. Вокруг него построено огромное количество софта. Люди накупили пассивных токенов (других тогда не было!). Взять сейчас и сказать «давайте все переходим на неизвлекаемые ключи и ФКН!» можно, но кто будет-то?
> Выше, по-моему, вы писали, что ФКНы так не объегоришь.
Точно так. ФКН — это мощь. Вот только этих носителей пока единицы. И ошибиться с ними намного сложнее, чем с простыми Рутокен ЭЦП или JaCarta ГОСТ.
Тогда запрашивайте у производителей описание APDU работы с токеном. Нам они передаются обычно под NDA.
> Холмс, но как черт-возьми? Если вы сами даёте в руки этим варварам возможность отключать работу с неизвлекаемым режимом.
Неочевидная аналогия. Сейчас весь мир для платежей использует чиповые EMV-карты, которые устанавливают SecureMessaging, аутентифицируют с помощью RSA и вообще прекрасны. Их проникновение в большинстве стран выше 90%. Кроме одной — США. Почему так? Ответ простой — США мощно развили систему платежей картами с магнитной полосой. Все понимают, что они менее безопасные, но перейти сходу на EMV невозможно — для этого требуются слишком большие затраты. Процесс перехода осторожно движется, но пока далек от завершения.
У нас ровно тоже самое. Криптопровайдер, который хранит ключи в пассивном виде, появился 20 лет назад. Вокруг него построено огромное количество софта. Люди накупили пассивных токенов (других тогда не было!). Взять сейчас и сказать «давайте все переходим на неизвлекаемые ключи и ФКН!» можно, но кто будет-то?
> Выше, по-моему, вы писали, что ФКНы так не объегоришь.
Точно так. ФКН — это мощь. Вот только этих носителей пока единицы. И ошибиться с ними намного сложнее, чем с простыми Рутокен ЭЦП или JaCarta ГОСТ.
P.S.: На этот вопрос: «И что? Может быть её как-то можно отключить через реестр? По типу EnabledOperationsForDisabledCarriers?» так и не ответили.
На этот вопрос я не ответил, потому что его не понял. Вы предлагаете завести ключ в реестр для отключения функциональности, которая включается ключом в реестре? А если они и о нем узнают?))
Нет. Ранее на вашем форуме вы (или ваши коллеги) сказали каким ключем в реестре хулиганит Тензор в своей программе СБИС — это EnabledCarrierTypes. Тогда было достаточно удалить этот ключ из реестра и всё работало. Кроме того, вы сообщили о ключе реестра EnabledOperationsForDisabledCarriers, который я тогда не протестил, т.к. удаление помогало (до перезагрузки, но и пёс с ним).
Утверждение следующее: после НГ Тензор выпустил новую версию своего ПО СБИС, в котором они умеют запрещать выбор защищенного носителя при генерации ключа, вне зависимости от значения EnabledCarrierTypes, а так же не помогает создание EnabledOperationsForDisabledCarriers со значением 3.
Есть идеи, как они умудряются это делать и как им это пообломать?
Утверждение следующее: после НГ Тензор выпустил новую версию своего ПО СБИС, в котором они умеют запрещать выбор защищенного носителя при генерации ключа, вне зависимости от значения EnabledCarrierTypes, а так же не помогает создание EnabledOperationsForDisabledCarriers со значением 3.
Есть идеи, как они умудряются это делать и как им это пообломать?
Очень непростая тема. Работал в одном известном УЦ, могу сказать по итогу слова бывшего начальника: "Не доверяете уц? Не выпускайте ключи...".
УЦ за компрометацию со своей стороны может нести достаточно суровое наказание. Да и кадрам обычно относятся как расходному материалу…
Обычно проблема как раз в том, что при передаче по незащищенному каналу запроса не удается 100% проверить неизменность запроса, от этого и придумывают такие сервисы.
> Не доверяете уц? Не выпускайте ключи…
На кой черт необходимо это дополнительное отношение доверия? Схема специально была придумана так, чтобы отношения доверия к УЦ было только в одном — он удостоверяет владельца ОТКРЫТОГО ключа.
> при передаче по незащищенному каналу запроса не удается 100% проверить неизменность запроса, от этого и придумывают такие сервисы.
Вот же блин проблема! Можно же юзеру формировать печатное заявление (которое и так формируется) со слепком ключа. А в УЦ его проверять. Вообще это христоматийная процедура.
На кой черт необходимо это дополнительное отношение доверия? Схема специально была придумана так, чтобы отношения доверия к УЦ было только в одном — он удостоверяет владельца ОТКРЫТОГО ключа.
> при передаче по незащищенному каналу запроса не удается 100% проверить неизменность запроса, от этого и придумывают такие сервисы.
Вот же блин проблема! Можно же юзеру формировать печатное заявление (которое и так формируется) со слепком ключа. А в УЦ его проверять. Вообще это христоматийная процедура.
Все банально. ФСБ и МВД хотят не париться с вашими ключами. Хотят открывать их не взломом, а просто получая ключ по умолчанию от криптопровайдера. Крипто про, Тензора и всех остальных.
Других истин нет. Расслабьтесь и не пользуйтесь богомерзким Тензором.
про непонятный обмен:
Любой шифр можно вскрыть. Пишите дампы, выкладывайте — здесь народ ушлый, вы**денного яйца не оставит от их «шифров».
Других истин нет. Расслабьтесь и не пользуйтесь богомерзким Тензором.
про непонятный обмен:
Любой шифр можно вскрыть. Пишите дампы, выкладывайте — здесь народ ушлый, вы**денного яйца не оставит от их «шифров».
> Любой шифр можно вскрыть. Пишите дампы, выкладывайте — здесь народ ушлый, вы**денного яйца не оставит от их «шифров».
Зеваю чё-та. Нашествие диванных криптографов?
Зеваю чё-та. Нашествие диванных криптографов?
нашествие «диванных шифровальщиков» на кормушке фсб? рИально?
ржучета-)))
малочета вас! рабочее время кончилось? так вы приходите исчо
P.S. Хотя так то вроде разумный человек, со взвешенными взглядами… пятниццо торкнуло?
ржучета-)))
малочета вас! рабочее время кончилось? так вы приходите исчо
P.S. Хотя так то вроде разумный человек, со взвешенными взглядами… пятниццо торкнуло?
Речь о вот этом вашем перле:
habr.com/en/post/487246/#comment_21245622
В конце концов, это же Хабр, здесь люди попрофессиональнее, чем те, кому вы эту байку можете протравить.
Ну да, «любой вскрыть можно», лет через 1000 работы алгоритма, да и то, если вам дадут доступ к суперкомпьютеру на эти 1000 лет.
Впрочем, квантовые компьютеры на подходе, они быстро вскроют современные шифры. Но тому времени и «квантовые шифры» появятся, сейчас уже есть разработки.
habr.com/en/post/487246/#comment_21245622
Любой шифр можно вскрыть. Пишите дампы, выкладывайте — здесь народ ушлый, вы**денного яйца не оставит от их «шифров».
В конце концов, это же Хабр, здесь люди попрофессиональнее, чем те, кому вы эту байку можете протравить.
Ну да, «любой вскрыть можно», лет через 1000 работы алгоритма, да и то, если вам дадут доступ к суперкомпьютеру на эти 1000 лет.
Впрочем, квантовые компьютеры на подходе, они быстро вскроют современные шифры. Но тому времени и «квантовые шифры» появятся, сейчас уже есть разработки.
Впрочем, квантовые компьютеры на подходе, они быстро вскроют современные шифры. Но тому времени и «квантовые шифры» появятся, сейчас уже есть разработки.
Вот здесь описаны принципы «квантовой связи» (осторожно, english):
www.nature.com/articles/s41598-018-24533-6
Байки травите своим родным дома. ок -) я травлю как раз от спецов. и компьютеры тоже есть. И не надо сильно преувеличивать криптостойкость алгоритмов. Ок? часть информации более чем известна (из тех что передается).
И уж господин хороший. не выпячивайте пожалуйста из себя таких вот ветеранских знаний местных. Мягко говоря бахвалиться то особо здесь некому и не зачем.
Поэтому почаще смотрите пожалуйста в зеркало чтобы невзначай не затрагивать людей своим домыслами.
Договорились?
И уж господин хороший. не выпячивайте пожалуйста из себя таких вот ветеранских знаний местных. Мягко говоря бахвалиться то особо здесь некому и не зачем.
Поэтому почаще смотрите пожалуйста в зеркало чтобы невзначай не затрагивать людей своим домыслами.
Договорились?
Если чаще и больше в каментах писать фсб, то камент от этого становится важнее и правильнее. Не прекращайте!
Чистой воды бред вся эта статья.
- Выбор носителя определяется пользователем. В случае если Рутокен ЭЦП не появляется для выбора, то скорее всего Вы не настроили/меняли настройки считывателей в настройках КриптоПро CPS.
- Генерация запроса и закрытого ключа происходит средствами СКЗИ, в Вашем случае КриптоПро.
- СБИС плагин — это многофункцианальное ПО, которое предназначено не только для передачи запроса на выпуск КЭП в УЦ.
Его задача изначально была не для этого, а для пользователей системы ЭДО, ЭО, так позволяет загружать отчеты из 1С, SAP и др ПО, для связи со сканером, и тд. - При написании своего поста Вы не думали, а кому нужны ваши закрытые ключи? Зачем это УЦ.
Я понимаю если бы Вы были руководителем компании с многомиллиардными оборотами и тут еще можно было подумать на планы мошенничества, НО, УЦ НЕСЕТ ОТВЕТСВЕННОСТЬ ЗА КАЖДЫЙ ВЫПУЩЕННЫЙ КЛЮЧ. В случае мошенничества, отвечать в первую очередь УЦ.
Вспомните нашумевший скандал с СКБ контур.
У них в 2019 году вообще была приостановка лицензии, и только потому что клиент УЦ подписал документы на выпуск КЭП собственноручно, но не знал что подписывает, а в итоге мошенники воспользовались этим. - По поводу восстановления удаленного ключа — при удалении ключа из консоли сертификата/из КриптоПро, КриптоПро спрашивает удалить ли контейнер ключа «ххх». Так вот если нажать нет, то и закрытая часть ключа останется на носителе/реестре, остается только установить повторно открытую часть ключа, что и сделала техподдержка (уверен на 99.99%).
- По поводу генерации ключа в офисе УЦ: все ключи генерируются в ОКЗ, там стоят компы которые не подключены к сети. Генерация происходит вручную, потом запрос направляется в ПАК УЦ, где происходит выпуск, и потом в обратном порядке происходит установка открытого ключа (сертификата) на носитель. Читайте требования ФСБ и ФАПСИ к УЦ и их ПО. Это Вам не мелкий УЦ с одним офисом где то в глуши, в котором не знают что такое oid.
- Если Вам нужен нежкспортируемый ключ на носителе, скажите об этом сотруднику который создает заявку на КЭП. В применениях вы увидите «нежкспортируемый ключ».
PS: я сам использую Рутокен ЭЦП, и проблем с выпуском ключа на него не было.
Последний раз выпускал 2 серта, 1 — в конце ноября, второй в серидине декабря — все отлично!
Итог: статья хрень для поднятия рейтинга.
> 1. Выбор носителя определяется пользователем. В случае если Рутокен ЭЦП не появляется для выбора, то скорее всего Вы не настроили/меняли настройки считывателей в настройках КриптоПро CPS.
Выше разработчик из КриптоПро подтвердил, что это не так. Вы, как и многие, кто здесь пишет каменты, с ЭП сталкивались, наверное, только пару раз в жизни и на этом строите свои выводы, попутно развешивая ярлыки «хрень» и «бред».
> СБИС плагин — это многофункцианальное ПО, которое предназначено не только для передачи запроса на выпуск КЭП в УЦ.
И что? Мне вообще по барабану какие там ещё у него функции. Они мне не нужны. Я пришел в УЦ не за ЭДО, 1С и связью со сканером.
> При написании своего поста Вы не думали, а кому нужны ваши закрытые ключи? Зачем это УЦ.
Вы бы почитали что ли каменты выше. Там есть варианты.
> НО, УЦ НЕСЕТ ОТВЕТСВЕННОСТЬ ЗА КАЖДЫЙ ВЫПУЩЕННЫЙ КЛЮЧ.
Это миф. УЦ несет ответственность за то, что он правильно или неправильно удостоверил личность владельца ключа. Если ваш ключ куда-то утечет и с помощью него будут совершенны юридически-значимые действия, то вы не докажете, что это произошло по вине УЦ, потому что у них была копия вашего ключа. Поэтому с т.з. ответственности — это для них безопасно.
> Читайте требования ФСБ и ФАПСИ к УЦ и их ПО
Механиз электронной подписи рожден таким образом, чтобы не нужно было доверять тому, как вы там у себя генерируете ключи в офисе, соблюдаете или не соблюдаете требования и так далее. Это отношение доверения лишнее и ненужное.
> Если Вам нужен нежкспортируемый ключ на носителе, скажите об этом сотруднику который создает заявку на КЭП. В применениях вы увидите «нежкспортируемый ключ».
Это не правда. Во-первых, я ему говорил. Во-вторых, на сколько мне известно такой OID прописывают только на тех ключах, которые прописывает сам УЦ. Удаленно так не сделать. В-третьих, когда речь касается выпуска в самом УЦ, то начинается ерунда — этот носитель мы не поддерживаем, тут мы не будем, берите Rutoken Lite и не парьтесь. Проходили.
> Последний раз выпускал 2 серта, 1 — в конце ноября, второй в серидине декабря — все отлично!
Я так подразумеваю в Тензоре? Давайте сюда скрин, где вы генеришь ключ на Рутокен ЭЦП 2.0 и выбираете в комбобоксе активный режим. Или (о внезапно!) Вы облажались и сгенерили извлекаемый ключ на Рутокен ЭЦП 2.0 (в тупом режиме)?
> Итог: статья хрень для поднятия рейтинга.
Итог: камент сотрудника Тензора )))
Выше разработчик из КриптоПро подтвердил, что это не так. Вы, как и многие, кто здесь пишет каменты, с ЭП сталкивались, наверное, только пару раз в жизни и на этом строите свои выводы, попутно развешивая ярлыки «хрень» и «бред».
> СБИС плагин — это многофункцианальное ПО, которое предназначено не только для передачи запроса на выпуск КЭП в УЦ.
И что? Мне вообще по барабану какие там ещё у него функции. Они мне не нужны. Я пришел в УЦ не за ЭДО, 1С и связью со сканером.
> При написании своего поста Вы не думали, а кому нужны ваши закрытые ключи? Зачем это УЦ.
Вы бы почитали что ли каменты выше. Там есть варианты.
> НО, УЦ НЕСЕТ ОТВЕТСВЕННОСТЬ ЗА КАЖДЫЙ ВЫПУЩЕННЫЙ КЛЮЧ.
Это миф. УЦ несет ответственность за то, что он правильно или неправильно удостоверил личность владельца ключа. Если ваш ключ куда-то утечет и с помощью него будут совершенны юридически-значимые действия, то вы не докажете, что это произошло по вине УЦ, потому что у них была копия вашего ключа. Поэтому с т.з. ответственности — это для них безопасно.
> Читайте требования ФСБ и ФАПСИ к УЦ и их ПО
Механиз электронной подписи рожден таким образом, чтобы не нужно было доверять тому, как вы там у себя генерируете ключи в офисе, соблюдаете или не соблюдаете требования и так далее. Это отношение доверения лишнее и ненужное.
> Если Вам нужен нежкспортируемый ключ на носителе, скажите об этом сотруднику который создает заявку на КЭП. В применениях вы увидите «нежкспортируемый ключ».
Это не правда. Во-первых, я ему говорил. Во-вторых, на сколько мне известно такой OID прописывают только на тех ключах, которые прописывает сам УЦ. Удаленно так не сделать. В-третьих, когда речь касается выпуска в самом УЦ, то начинается ерунда — этот носитель мы не поддерживаем, тут мы не будем, берите Rutoken Lite и не парьтесь. Проходили.
> Последний раз выпускал 2 серта, 1 — в конце ноября, второй в серидине декабря — все отлично!
Я так подразумеваю в Тензоре? Давайте сюда скрин, где вы генеришь ключ на Рутокен ЭЦП 2.0 и выбираете в комбобоксе активный режим. Или (о внезапно!) Вы облажались и сгенерили извлекаемый ключ на Рутокен ЭЦП 2.0 (в тупом режиме)?
> Итог: статья хрень для поднятия рейтинга.
Итог: камент сотрудника Тензора )))
> Я понимаю если бы Вы были руководителем компании с многомиллиардными оборотами и
> тут еще можно было подумать на планы мошенничества, НО, УЦ НЕСЕТ ОТВЕТСВЕННОСТЬ ЗА
> КАЖДЫЙ ВЫПУЩЕННЫЙ КЛЮЧ.
Вот этот аргумент — не понимаю и не признаю.
1. УЦ будет отвечать, только если на то будет воля государства. А если нет? Примеров, когда государство не было заинтересовано или прямо покрывало подозреваемых, выше крыши.
2. Чтобы привлечь УЦ к отвественности, необходимо доказать его вину в совершении противоправных действий. Сделать это намного сложнее, чем продемонстрировать возможность совершения таких действий.
3. Даже если УЦ привлекут к ответственности, это может не помочь владельцу сертификата.
4. Криптография — не та отрасль, где сомнения должны трактоваться в пользу обвиняемого.
> тут еще можно было подумать на планы мошенничества, НО, УЦ НЕСЕТ ОТВЕТСВЕННОСТЬ ЗА
> КАЖДЫЙ ВЫПУЩЕННЫЙ КЛЮЧ.
Вот этот аргумент — не понимаю и не признаю.
1. УЦ будет отвечать, только если на то будет воля государства. А если нет? Примеров, когда государство не было заинтересовано или прямо покрывало подозреваемых, выше крыши.
2. Чтобы привлечь УЦ к отвественности, необходимо доказать его вину в совершении противоправных действий. Сделать это намного сложнее, чем продемонстрировать возможность совершения таких действий.
3. Даже если УЦ привлекут к ответственности, это может не помочь владельцу сертификата.
4. Криптография — не та отрасль, где сомнения должны трактоваться в пользу обвиняемого.
После появления сертифицированной версии КриптоПро CSP 5.0 мы получили обращения от клиентов, что при использовании некоторых носителей КриптоПро CSP “зависает” примерно на 30 секунд в процессе поиска и перечисления присутствующих контейнеров.
Мы обратились в службу технической поддержки КриптоПро с данной проблемой, которая дала рекомендацию отключить работу КриптоПро CSP 5.0 с активными носителями путем создания параметра в реестре.
Проблема быстродействия таким образом решилась, но при этом все остальные программы потеряли возможность работать с некоторыми функциональными ключевыми носителями.
В итоге мы сами нашли иное решение, не мешающие другим программам использовать КриптоПро CSP.
Этот параметр никаким образом не влиял на безопасность закрытого ключа и возможность его копирования. Тип ключа — экспортируемый или неэкспортируемый определяет его владелец в момент формирования запроса на сертификат.
Предположение о том, что закрытый ключ куда-то копируется является не более чем домыслом.
Мы обратились в службу технической поддержки КриптоПро с данной проблемой, которая дала рекомендацию отключить работу КриптоПро CSP 5.0 с активными носителями путем создания параметра в реестре.
Проблема быстродействия таким образом решилась, но при этом все остальные программы потеряли возможность работать с некоторыми функциональными ключевыми носителями.
В итоге мы сами нашли иное решение, не мешающие другим программам использовать КриптоПро CSP.
Этот параметр никаким образом не влиял на безопасность закрытого ключа и возможность его копирования. Тип ключа — экспортируемый или неэкспортируемый определяет его владелец в момент формирования запроса на сертификат.
Предположение о том, что закрытый ключ куда-то копируется является не более чем домыслом.
>>> Предположение о том, что закрытый ключ куда-то копируется является не более чем домыслом.
Или пока недоказанной утечкой информации (ключей) налево в интересах заинтересованных лиц. И уверен что вы не докажете ни то ни другое. А кто-нибудь таки расшифрует ваши контейнеры которые уходят к вам в УЦ и вот тогда будет… «хорошая драка»
Или пока недоказанной утечкой информации (ключей) налево в интересах заинтересованных лиц. И уверен что вы не докажете ни то ни другое. А кто-нибудь таки расшифрует ваши контейнеры которые уходят к вам в УЦ и вот тогда будет… «хорошая драка»
у нас вроде не нужно доказывать свою невиновность. Вот если, ТС или другой пытливый ум докажет что имеет место быть утечка, то можно делать громкие заявления. Иначе это очень похоже на поклеп
В Китае недавно один доктор тоже развел поклеп… )
И это: жена цезаря должна быть вне подозрений )
ДА ну? На веру примете что добрые дядечки строящие свое благополучие на информации будут ТАК ДОБРЫ чтобы
не построить свое благополучие еще и таким «невинным» способом как угодить «кому то в погонах» наличием неучтенной копии ключа для беспрепятственного доступа к информации зашифрованной им?
ВЫ реально так думаете что ПРОСТОЙ пользователь, у которого по умолчанию типа должно быть доверие к структуре, видящий своими глазами какой то объемный обмен зашифрованной инфой с его компьютера на чужую сетку должен доказать виновность провайдера?
Будучи заведомо ущемленной стороной (слабой стороной) — говоря юридическим языком?
ВЫ в своем уме?
не построить свое благополучие еще и таким «невинным» способом как угодить «кому то в погонах» наличием неучтенной копии ключа для беспрепятственного доступа к информации зашифрованной им?
ВЫ реально так думаете что ПРОСТОЙ пользователь, у которого по умолчанию типа должно быть доверие к структуре, видящий своими глазами какой то объемный обмен зашифрованной инфой с его компьютера на чужую сетку должен доказать виновность провайдера?
Будучи заведомо ущемленной стороной (слабой стороной) — говоря юридическим языком?
ВЫ в своем уме?
> Этот параметр никаким образом не влиял на безопасность закрытого ключа и возможность его копирования.
Этот параметр влияет на то, что я в вашем УЦ не могу себе сгенерить ключи на ФКН. Если вы делаете такую настройку на блага пользователя, то нужно уметь её отключать. Вот, например, у меня сейчас есть действующий сертификат вашего УЦ на хардварном токене. Он был выпущен в тот период, когда вы этой проблемой ещё не озаботились. И получается теперь, что если я захочу воспользоваться вашими сервисами, я теперь не смогу этого сделать.
> Тип ключа — экспортируемый или неэкспортируемый определяет его владелец в момент формирования запроса на сертификат.
Этот маркетойдный буллшит оставьте кому-то ещё. Обращение к токену напрямую командами ISO 7816 позволяет начхать на эти атрибуты и скопировать с токена всё, что угодно. В том числе и вашему СБИС-плагину. Если мы говорим о тупом хранении ключа на токене, разумеется.
> Предположение о том, что закрытый ключ куда-то копируется является не более чем домыслом.
Домыслы решаются двумя вещами — открытостью или доверием. Открытости у вас нет. Доверять вам не понятно зачем.
Этот параметр влияет на то, что я в вашем УЦ не могу себе сгенерить ключи на ФКН. Если вы делаете такую настройку на блага пользователя, то нужно уметь её отключать. Вот, например, у меня сейчас есть действующий сертификат вашего УЦ на хардварном токене. Он был выпущен в тот период, когда вы этой проблемой ещё не озаботились. И получается теперь, что если я захочу воспользоваться вашими сервисами, я теперь не смогу этого сделать.
> Тип ключа — экспортируемый или неэкспортируемый определяет его владелец в момент формирования запроса на сертификат.
Этот маркетойдный буллшит оставьте кому-то ещё. Обращение к токену напрямую командами ISO 7816 позволяет начхать на эти атрибуты и скопировать с токена всё, что угодно. В том числе и вашему СБИС-плагину. Если мы говорим о тупом хранении ключа на токене, разумеется.
> Предположение о том, что закрытый ключ куда-то копируется является не более чем домыслом.
Домыслы решаются двумя вещами — открытостью или доверием. Открытости у вас нет. Доверять вам не понятно зачем.
Прочитал я и пост, и комментарии. Отвечу, пожалуй, как человек, который работает на ПО СБИС со СБИС в СБИС :)
Не встречал я эти Смарт фрэшки лично и не видел как генерация пары происходит на неё. Да, вообще в криптографии не более года (и то учёбы)
Но что хочу сказать
Ответ Тензора был по поводу данной ситуации и не верить ей у меня причин нет, так как:
Не встречал я эти Смарт фрэшки лично и не видел как генерация пары происходит на неё. Да, вообще в криптографии не более года (и то учёбы)
Но что хочу сказать
- Комментарий пользователя о возврате закрытого ключа через удалённую помощь — это бред/фигня/непонимание и др… Достать закрытый ключ — это полный бред (к сертификатам у нас есть доступ и перемещение было сертификата, а нашли его при помощи ИНН и даты выпуска сертификата, потому что сертификат В ОТКРЫТОМ доступе)
- Насчёт компуктеров куда был сгенерирован ключ — сотрудники идиоты и влетят они на сумму в 5 нолей за одну подпись. У Тензора что на внутренней сети, что в ЛК клиента видно на какой носитель сгенерирован ключ и какие ключи ещё генерировали на этот же носитель не спроста
- Да, Тензор работает на ПАКМ HSM 2.0
- Насчёт компании в целом — у компании техподдержка со знаниями и огромным опытом. Чтобы пойти выше, нужно столько выучить. Да, даже начать работать не очень легко — уже в первый месяц обязан знать основу основ криптографии даже если и близко к этому не подойдёшь.
- Нет, я не сотрудник маркетинга и в целом Тензора )
Ответ Тензора был по поводу данной ситуации и не верить ей у меня причин нет, так как:
- Следит за имиджем
- Компания огромная
- Сотрудники опытные и знающие в ГО
- Отвечает по закону
- Думает о пользователях
- Ею пользуются ГосОрганы, как пользователи
> Да, Тензор работает на ПАКМ HSM 2.0
Вот зачем мне, рядовому пользователю это знать и беспокоится об этом?
> у компании техподдержка со знаниями и огромным опытом.
Под новый год, когда проблема была обнаружена, ТП не смогла пояснить ровным счетом ничего по поводу данной проблемы. Это выяснили сотрудники Крипто Про после того как я им прямой наводкой сказал, после чего именно такое произошло. Тогда же Крипто Про предложили решение.
Вот зачем мне, рядовому пользователю это знать и беспокоится об этом?
> у компании техподдержка со знаниями и огромным опытом.
Под новый год, когда проблема была обнаружена, ТП не смогла пояснить ровным счетом ничего по поводу данной проблемы. Это выяснили сотрудники Крипто Про после того как я им прямой наводкой сказал, после чего именно такое произошло. Тогда же Крипто Про предложили решение.
ТП не смогла пояснить ровным счетом ничего по поводу данной проблемы.
Своих не сдают :D
Мне сейчас стал интересен ответ Крипто Про на ваш вопрос. От Тензора всё равно подробного ответа не увидем — они «сор из избы не выносят»
> Мне сейчас стал интересен ответ Крипто Про на ваш вопрос.
В посте есть ссылка на форум Крипто Про, где эта проблема обсуждалась.
Кроме того, представитель Крипто Про отписался выше в каментах, где написал, что его бесит поведение Тензора в данном случае.
> От Тензора всё равно подробного ответа не увидем
Тензор выше родил некий достаточно подробный ответ. Однако на это у тензора ушло один месяц и десять дней. И до сих пор это лишь тянет на объяснение того, зачем они это сделали, но никак не на то, как с этим жить.
В посте есть ссылка на форум Крипто Про, где эта проблема обсуждалась.
Кроме того, представитель Крипто Про отписался выше в каментах, где написал, что его бесит поведение Тензора в данном случае.
> От Тензора всё равно подробного ответа не увидем
Тензор выше родил некий достаточно подробный ответ. Однако на это у тензора ушло один месяц и десять дней. И до сих пор это лишь тянет на объяснение того, зачем они это сделали, но никак не на то, как с этим жить.
2. Насчёт компуктеров куда был сгенерирован ключ — сотрудники идиоты и влетят они на сумму в 5 нолей за одну подпись. У Тензора что на внутренней сети, что в ЛК клиента видно на какой носитель сгенерирован ключ и какие ключи ещё генерировали на этот же носитель не спроста
Там было 84 электронные подписи :)
Ох как сразу по диагонали виден умысел на создание благоприятного имиджа путем «якобы» самостийного коммента от «типа » незаинтересованного лица.
А уж если вчитаться, то прям откровенно «левыЙ» отзыв.
P.S. ГосОрганы ЭТИМ пользуются совершенно не потому, что САМИ выбрали ЭТО. И НЕ ПОТОМУ, ЧТО это лучшее решение на рынке…
Догадались почему? -))))
А уж если вчитаться, то прям откровенно «левыЙ» отзыв.
P.S. ГосОрганы ЭТИМ пользуются совершенно не потому, что САМИ выбрали ЭТО. И НЕ ПОТОМУ, ЧТО это лучшее решение на рынке…
Догадались почему? -))))
Ну, если считаете мною написанный комментарий умыслом в создании имиджа, то хочу огорчить; но Вы же не поверите)))
Да, продукт нравится. Общаюсь часто с сотрудниками самой компании напрямую. Нравится идеология. И что? Но у Вас сразу — «левый» коммент для имиджа. Всё, что мною написано, основано на собственном опыте
P.s.: Недавно в кое-какие ГосОрганы пришла бумага «из Москвы» о том, что переходят на определённый продукт. Так, сотрудники чуть ли не сами хотели оплачивать лицензию на СБИС чтоб продолжить работать. Вот, не могу догадаться со всей силы :)
Если бы не эта история, согласился с Вами бы
Да, продукт нравится. Общаюсь часто с сотрудниками самой компании напрямую. Нравится идеология. И что? Но у Вас сразу — «левый» коммент для имиджа. Всё, что мною написано, основано на собственном опыте
P.s.: Недавно в кое-какие ГосОрганы пришла бумага «из Москвы» о том, что переходят на определённый продукт. Так, сотрудники чуть ли не сами хотели оплачивать лицензию на СБИС чтоб продолжить работать. Вот, не могу догадаться со всей силы :)
Если бы не эта история, согласился с Вами бы
Приехали. Надёжность СКЗИ выбираем по принципу нравится/модно/удобно. Так победим!
>Надёжность СКЗИ выбираем по принципу нравится/модно/удобно.
Я не написал что это был выбор СКЗИ (коим разработчиком Тензор и не является). Это выбор продукта (отчётности), которое использует СКЗИ
Но тоже предложение что ГосОрганам сливает инфу Тензор, является не более чем вымыслом. Контур держит превосходство над Тензором на рынке в некоторых регионах, есть другие игроки, и ГосОрганы не штампуют «Переход на СБИС» (либо ГосОрган сам выбирает что использовать, либо приходит «из Москвы» требование о переходе на систему отличную от СБИС)
Я не написал что это был выбор СКЗИ (коим разработчиком Тензор и не является). Это выбор продукта (отчётности), которое использует СКЗИ
Но тоже предложение что ГосОрганам сливает инфу Тензор, является не более чем вымыслом. Контур держит превосходство над Тензором на рынке в некоторых регионах, есть другие игроки, и ГосОрганы не штампуют «Переход на СБИС» (либо ГосОрган сам выбирает что использовать, либо приходит «из Москвы» требование о переходе на систему отличную от СБИС)
Это выбор продукта (отчётности), которое использует СКЗИ
Которое вынуждает использовать СКЗИ вместе с не очень хорошими методами выработки и хранения ключевой информации
Но тоже предложение что ГосОрганам сливает инфу Тензор, является не более чем вымыслом.
Это предложение или предположение родилось в вашем мозгу. Я говорил про компрометацию ключей, а не про передачу их госорганам. Это у вас по Фрейду.
ГосОрганы не штампуют
Я не понимаю. У нас что? Госорганы стали вдруг эталоном мудрости и компетенции в ИБ? Вы хотя бы отдаёте себе отчёт, что ваши доводы по меркам Хабра — это несусветная чушь и гадание по облачность на Марсе?
Официальная позиция КриптоПро по данной истории.
Исходя из информации, полученной нами от Тензора, главная причина, по которой было использовано подобное решение, — серьезное замедление работы функции перечисления, связанное с большим количеством «неизвлекаемых» ключей на токенах Рутокен ЭЦП, которые используют пользователи.
Каких-либо подтверждений тому, что имел место какой-то злой умысел, подразумевающий неавторизованное копирование и/или передачу ключей, мы обнаружить не смогли.
Ситуация, с которой столкнулся автор статьи, скорее всего, является следствием неудачного стечения обстоятельств и недостатка коммуникации между разработчиками.
Все предположения, сделанные автором статьи, являются исключительно его собственными домыслами, не нашедшими подтверждения в действительности.
Исходя из информации, полученной нами от Тензора, главная причина, по которой было использовано подобное решение, — серьезное замедление работы функции перечисления, связанное с большим количеством «неизвлекаемых» ключей на токенах Рутокен ЭЦП, которые используют пользователи.
Каких-либо подтверждений тому, что имел место какой-то злой умысел, подразумевающий неавторизованное копирование и/или передачу ключей, мы обнаружить не смогли.
Ситуация, с которой столкнулся автор статьи, скорее всего, является следствием неудачного стечения обстоятельств и недостатка коммуникации между разработчиками.
Все предположения, сделанные автором статьи, являются исключительно его собственными домыслами, не нашедшими подтверждения в действительности.
Ложки нашлись, а осадочек остался (с)....
> Ситуация, с которой столкнулся автор статьи, скорее всего, является следствием неудачного стечения обстоятельств и недостатка коммуникации между разработчиками.
Если бы банально техподдержка не жевала бы сопли, а была бы в курсе того, как развивается индустрия, что есть Крипто Про 5, что есть ФКН и прочее, и прочее, скорее всего они бы смогли грамотно донести мысль до разрабов и сообщить ответ.
По факту, что такое ФКН поддержка не знает. «Крипто Про 5 мы не поддерживаем». Ну и всё такое в этом стиле, лишь бы проблемы не было.
Если бы банально техподдержка не жевала бы сопли, а была бы в курсе того, как развивается индустрия, что есть Крипто Про 5, что есть ФКН и прочее, и прочее, скорее всего они бы смогли грамотно донести мысль до разрабов и сообщить ответ.
По факту, что такое ФКН поддержка не знает. «Крипто Про 5 мы не поддерживаем». Ну и всё такое в этом стиле, лишь бы проблемы не было.
del
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Возможно, удостоверяющий центр компании Тензор компрометирует приватные ключи клиентов