Comments 98
UFO just landed and posted this here
… и считать число Пи равное 3
В военное время значение синуса может достигать четырёх
Но дело в том, что этим сертификатам соответствуют сами ключи ЭП, которые тоже имеют собственные сроки действия
Чего? Где это для пары приватный-публичный ключ указывается срок действия?
Это скорее из серии навязанных услуг УЦ «а у вас USB-токен протух, купите новый», как и «вот вам и ключ и сертификат, какой такой CSR, ничего не знаем»
Где это для пары приватный-публичный ключ указывается срок действия?
Учите матчасть, читайте документы ТК-26!
Р 50.1.112-2016? Р 1323565.1.023-2018? Вроде как, не содержат явных ссылок на срок действия закрытого ключа (ключа подписи).
Может российская криптография и отличается где-то кардинально от DSA/RSA/EC***, но в моем представлении матчасти у самого приватного и публичного ключей, в том числе на аппаратных носителях, нет никакого срока действия, это исключительно числа, там нет полей.
Поля с датами есть только в сертификате.
Поля с датами есть только в сертификате.
Понимаете время действия ключа придумали не от хорошей жизни. Закрытый ключ это в принципе случайное определенной длины (для ГОСТ-ов 256 и 512 бит).
Следовательно их можно подобрать простым перебором, так как открытый ключ получается из закрытого ключа.
Следовательно, имея достаточно времени, злоумышленник может получить закрытый ключ для нужного сертификата. Дальше дело техники.
А продлевая срок действия сертификаа мы даем злоумышленникам дополнительный шанс.
Возникает вопрос, кто будет нести ответственность, если случится компроментация ключа?
Первоначально вопрос был, где в самой ключевой паре (не беря в расчет выданный сертификат) указан срок действия. А вы уже на вероятность подбора и ответственность перешли, так и не ответив на изначальный вопрос.
Все зависит от того где и как хранится ключевая пара. При чем открытый и закрыты ключи могут хранится и отдельно. Открытый ключ может вообще нигде (кроме сертификата) не хранится, он вычисляется. А если вы посмотрите с какими параметрами (CKA_ ) ключи могут хранится на токенах PKCS#11, то много интересного увидите. Вопрос в том, все ли приложения их обрабатывают и проверяют.
А вопрос то в том, насколько я понимаю, продлить-то сертификаты можно, а вот о последствиях кто подумает. Или хотели как лучше, а вышло как всегда.
Однако, это не отменяет того, что закрытый ключ не протухает. Никак.
Т.е. субъекту всего-то надо выпустить CSR с тем же открытым ключом, подписать его, и передать в УЦ, который подпишет CSR, выпустив (sic!) новый сертификат той же ключепары с другим сроком действия.
Всё.
Сама ключепара протухнуть не может. И такой финт ушами можно повторять неограниченно долго.
Т.е. субъекту всего-то надо выпустить CSR с тем же открытым ключом, подписать его, и передать в УЦ, который подпишет CSR, выпустив (sic!) новый сертификат той же ключепары с другим сроком действия.
Всё.
Сама ключепара протухнуть не может. И такой финт ушами можно повторять неограниченно долго.
Сама ключепара протухнуть не может.
Еще как протухает! И ваш способ это именно финт, направленный против вас же. Самое страшное то, что запрос остается в УЦ и недобросовестный сотрудник УЦ может им воспользоваться и выпустить фактически поддельный сертификат. А если еще и закрытый ключ "протух", то жди беды!
Еще как протухает!
Нет. Ключепара — это просто числа большой разрядности. Причем выведение закрытого ключа из открытого — задача вычислительно сложная. Даже для 128-разрядных эллиптических ключей, а ГОСТ-34.10 оперирует 256- и 512-разрядными. Прикинуть к носу вероятность компрометации закрытого ключа можете самостоятельно, для меня достаточно, что она стремится к нулю.
Самое страшное то, что запрос остается в УЦ и недобросовестный сотрудник УЦ может им воспользоваться и выпустить фактически поддельный сертификат.
Баюс-баюс. Ну выпустит. И что? Мы же говорим о генерации ключепары локально, и передаче в УЦ только CSR. Ну выпустит он еще один сертификат к моему ключу — закрытый то ключ у меня. И дальше что?
Надо читать внимательней, владелец закрытого ключа!
Вам стоит изучить криптографию для начала! Ключ и сертификат — АБСОЛЮТНО разные вещи!
Сертификат имеет срок действия, ключ никак со сроком не связан. Давайте еще скажите, что число 1234 имеет срок действия?
Три месяца, по сравнению со сроками действия сертификата ничтожно малы, а особенно по сравнению с теоретическим брутфорсом ключа.
Сертификат имеет срок действия, ключ никак со сроком не связан. Давайте еще скажите, что число 1234 имеет срок действия?
Три месяца, по сравнению со сроками действия сертификата ничтожно малы, а особенно по сравнению с теоретическим брутфорсом ключа.
Вам стоит изучить криптографию для начала! Ключ и сертификат — АБСОЛЮТНО разные вещи!
Правильно, почитайте! Что такое сертификат, как он связан с ключами и вообще зачем нужен!
Три месяца, по сравнению со сроками действия сертификата ничтожно малы
Это с каких пор 3 по сравнению с 12 или даже 15 стало ничтожно малым. Изучаем математику, что такое ничтожно малое. Далее дикуссия бессмысленна.
Учите матчасть) Такой бред несете, если честно.
Во-первых, есть как минимум рутовые сертификаты, сроки службы которых 20-30 лет. Это уже разница 2 порядка с 3 месяцами!
НО, во-вторых, вы даже невнимательно читаете! Криптостойкость зависит конечно же не от срока действия сертификата и в современных алгоритмах понадобятся сотни-тысячи лет для брутфорса!
Во-первых, есть как минимум рутовые сертификаты, сроки службы которых 20-30 лет. Это уже разница 2 порядка с 3 месяцами!
НО, во-вторых, вы даже невнимательно читаете! Криптостойкость зависит конечно же не от срока действия сертификата и в современных алгоритмах понадобятся сотни-тысячи лет для брутфорса!
А где ключ от рутовых сертификатов хранится?
И вообще вы о каких сертификатах говорите? Если об SSL-ых то бог с вами, а если о тех, с помощью которых у людей все отбирают, то это две большие разницы!!!
А кто вам сказал, что криптостойкость зависит от срока действия сертификата!!! Это исходя из криптостойкости в том числе и определяется срок действия сертификата.
А где ключ от рутовых сертификатов хранится?
Обычно в HSM-е.
И вообще вы о каких сертификатах говорите? Если об SSL-ых то бог с вами, а если о тех, с помощью которых у людей все отбирают, то это две большие разницы!!!
Я вас расстрою — разницы никакой. Что RSA, что ГОСТ-34, который суть цельнотянутый ECDSA с немного другими параметрами.
А отбирают не с помощью сертификатов, а с помощью мошенничества и раздолбайства прокладок между стулом и монитором, которых в УЦ набирают за мелкий прайс по объявлению, и которым до звезды принадлежность ключа реальному владельцу.
Это исходя из криптостойкости в том числе и определяется срок действия сертификата.
Конечно-конечно, ведь за год ключ в 256 бит обязательно подберут злые враги в враждебных УЦ. А за 20 лет — обязательно скомпрометируют ключи корневых сертификатов. Хотя корневики те же 256 бит.
Нет, это вам стоит внимательней изучить проблему дискретного логарифма в группе точек эллиптической кривой. Время подбора закрытого ключа разрядностью 256 бит по открытому стремится к бесконечности.
UFO just landed and posted this here
Я тоже так думаю… Но вот какая странность в 63-ФЗ, статья 14, пункт 6.1, часть 2:
Т.е. выпуск нового сертификата не аннулирует старый, а считается недействительным.
Что вдвойне странно…
Во-первых, когда переводили все юрлица на усиленную квалифицированную подпись, то УЦ «Такском» просто выпустил дополнительные сертификаты и мы скачали их.
Во-вторых, несколько лет назад, когда происходил переход с ГОСТ 34.10-2001 на ГОСТ 34.10-2012, УЦ «СКБ Контур» выпускал сертификаты парами — по обоим ГОСТам. Можно было пользоваться некоторое время старым, а потом купить новую версию «Крипто Про» с поддержкой ГОСТ 34.10-2012 и перейти на новый.
Получается, они нарушали этот пункт закона? Или воспринимали его как рекомендацию?
6.1. Удостоверяющий центр аннулирует сертификат ключа проверки электронной подписи в следующих случаях:
…
2) установлено, что содержащийся в таком сертификате ключ проверки электронной подписи уже содержится в ином ранее созданном сертификате ключа проверки электронной подписи;
Т.е. выпуск нового сертификата не аннулирует старый, а считается недействительным.
Что вдвойне странно…
Во-первых, когда переводили все юрлица на усиленную квалифицированную подпись, то УЦ «Такском» просто выпустил дополнительные сертификаты и мы скачали их.
Во-вторых, несколько лет назад, когда происходил переход с ГОСТ 34.10-2001 на ГОСТ 34.10-2012, УЦ «СКБ Контур» выпускал сертификаты парами — по обоим ГОСТам. Можно было пользоваться некоторое время старым, а потом купить новую версию «Крипто Про» с поддержкой ГОСТ 34.10-2012 и перейти на новый.
Получается, они нарушали этот пункт закона? Или воспринимали его как рекомендацию?
ЕМНИП, основной прелестью ГОСТ Р 34.10-2012 была удвоенная длина ключей (типа оценки меняются, квантовая «криптография»/квантовые вычисления приближаются...).
Так что, быть может, это не нарушение рекомендаций, а маркетинговый ход: «два сертификата ключей подписи по цене одного»?
Так что, быть может, это не нарушение рекомендаций, а маркетинговый ход: «два сертификата ключей подписи по цене одного»?
UFO just landed and posted this here
… подобрать простым перебором ...Простой перебор?! Если немного ближе к теме, то оценки различных методов дискретного логарифмирования на эллиптических кривых, скажем, начиная с Шанкса и более изощрённых, а так же с учётом оценок предполагаемого прогресса вычислительной техники и т.п., обещают сроки криптографической защиты десятки лет. (Имеется ввиду, что если начать логарифмировать прямо сейчас открытый ключ рекомендованной размерности, то в течении пары десятилетий вероятность успешного подбора не превысит разумно малой границы.)
Типичные же сроки действия сертификатов пользователей порядка одного года больше вызваны организационными аспектами. Например, если организация доверяет человеку ключ, то, как бы, разумно иметь с этим человеком трудовой договор не короче срока действия сертификата (ключа), что б не отзывать сертификат лишний раз.
Кроме того, оценки более сложных атак (физических, по побочным каналам, и т.п.), а так же оценки влияния отказов оборудования, как бы, намекают, что сохранить закрытый ключ в тайне с разумной вероятность больше пары-тройки лет достаточно непросто. Лучше бы его надёжно стереть, по окончании разумно небольшого срока действия, что б врагу не достался.
… кто будет нести ответственность, если случится компроментация ключа?За всё отвечает владелец сертификата ключа подписи. Это его риски.
в контейнере
«Координация профанации»…Хм. На мой непросвещённый взгляд, «внешние» электронные подписи (подписи других пользователей) проверяются не с помощью своего сертификата, а с помощью «внешних» сертификатов (сертификатов других пользователей).
… пользователей сертификаты открытых ключей могут протухнуть при нахождении пользователей в режиме самоизоляции и они не смогут проверять с их помощью внешние электронные подписи...
… привязанный к этому сертификату, у которого (ключа) срок уже тоже истек и по приказу министерства продлить его невозможно технически...Обычно, привязка сертификата с закрытым/открытым ключом пользователя изменяется легко, или очень легко:
- Если сертификат пользователя передаётся в подписанном сообщении, достаточно легко установить «продлённый сертификат» в «личное хранилище сертификатов» и/или в соответствующий атрибут ключевого контейнера/токена (технически легко, другой вопрос как обучить этому пользователя);
- Если сертификат пользователя не передаётся в подписанном сообщении, а в сообщении передаётся ссылка на сертификат по keyed, то достаточно легко изменить централизованный каталог сертификатов;
- И т.д. и т.п.
P.S.
Там есть правовая коллизия, вроде в требованиях ФСБ на УЦ есть пожелание контролировать уникальность сертификатов на открытые ключи, а здесь законодатели предлагают выпустить второй. Кто главнее ФСБ или законодатели?
В хранилище то вы поставите и свяжете сертификат и ключом. Но если будет проверяться подпись, например, то может проверяться и срок действия сертификата и срок действия ключа. А если это так, то ...
Как бы, действительно, срок действия закрытого ключа, в принципе, может быть задан соответствующим атрибутом X.509 в сертификате отправителя.
Однако, в тех системах, в которых этот атрибут используется, при выпуске продлённого сертификата можно и нужно расширить, как срок действия сертификата, так и срок действия закрытого ключа.
Однако, в тех системах, в которых этот атрибут используется, при выпуске продлённого сертификата можно и нужно расширить, как срок действия сертификата, так и срок действия закрытого ключа.
А можете подсказать, какой такой атрибут не позволит мне использовать пару ключей повторно для подписи нового сертификата?
Если пара ключей не скомпроментирована, то 3 месяца не сделают никакой погоды в принципе.
Если пара ключей не скомпроментирована, то 3 месяца не сделают никакой погоды в принципе.
Это не техническое ограничение, а юридическое. Я выше приводил пункт ФЗ, согласно которому нельзя выпускать сертификат на уже ранее использовавший в другом сертификате открытый ключ.
Хотя, я не юрист и могу чего-то не знать…
Хотя, я не юрист и могу чего-то не знать…
… не позволит мне использовать пару ключей повторно для подписи нового сертификатаВ вопросе, наверное, небольшая путаница. Вероятно, имелось ввиду "… для подписи нового запроса на сертификат к УЦ".
Есть, как минимум, два момента, которые могут мешать Вам в деле повторного использования пары ключей:
- Контроль со стороны УЦ по реестру сертификатов;
- Реализация СКЗИ, которое ограничивает срок действия закрытого ключа.
Человеке, конечо, за всегда преодолеет железяку чёртову, но зачем?
Я не в теме, поясните мне плиз. Вот у меня ЭЦП от Контура, когда у меня подпись близка к окончанию, я захожу на их сайт, оплачиваю продление, потом в личном кабинете нажимаю что-то типа залить новый ключ на носитель. Вставляю флешку и новый ключ заливается на нее. Это же так и должно работать или это несекурно?
Под капотом, конечно, немного иначе происходит, но это уже детали.
Если таков регламент, значит «секурно», его ж проверяли и утверждали умные и ответственные товарищи.
Если таков регламент, значит «секурно», его ж проверяли и утверждали умные и ответственные товарищи.
и ответственные
Это шутка такая?
У меня к ответственным товарищам вопрос: доколе пару ключей будут генерить сами уц, и любезно предоставлять всё скопом на флешке (и по большим праздникам галактического масштаба на токене)?
Используйте вменяемые УЦ.
Тензор мне сам генерил (а вот продление — на следующий год — было удаленным и соответственно генерация уже мной).
Контур — генерация мной была (еще и инструкцию дали, понятную даже полной блондинке, да, win-only все было).
Тензор мне сам генерил (а вот продление — на следующий год — было удаленным и соответственно генерация уже мной).
Контур — генерация мной была (еще и инструкцию дали, понятную даже полной блондинке, да, win-only все было).
Используйте вменяемые УЦ.
А такие точно есть?
Тензор мне сам генерил (а вот продление — на следующий год — было удаленным и соответственно генерация уже мной).
Не вижу такого соответствия. Перевыпуск сертификата возможен без перегенерации ключевой пары.
Контур — генерация мной была (еще и инструкцию дали, понятную даже полной блондинке, да, win-only все было).
Да ладно? Прям можно было сгенерить пару самостоятельно (лучше вообще непосредственно в защищенном хранилище аппаратного токена в неизвлекаемом виде), отправить им CSR и в ответ получить сертификат? Или генерация выполнялась закрытым непонятно как работающим, что делающим и что кому расссылающим софтом, который предоставил сам УЦ? И да, различным вариациям криптопро я не сильно доверяю, особенно учитывая их специфическое лицензирование для организации, предоставляющих услуги криптографии, а не конечных клиентов.
Что до инструкций — я считаю, что раз ЭЦП является полным аналогом собственноручной подписи, то УЦ надо обязывать на законодательном уровне объяснять «блондинкам» как работает непосредственно технология, и как и чем им угрожает. А простые «инструкции для блондинок» в этой сфере — первейший инструмент обмана.
Было бы здорово найти из тысяч такого регистратора который работает именно с запросом сертификата, а не присылает мутный софт или просит мутный плагин к браузеру.
Как ни странно, УЦ Федерального Казначейства работает по правильной схеме — по запросам (сотрудницы, вообще похоже и не знают, что это такое — закрытый ключ)) )
но этот УЦ только для Гос организаций, с физ. лицами не работают
но этот УЦ только для Гос организаций, с физ. лицами не работают
Давно там ключи получали?
Это раньше, при использовании АРМ ГК генерилось на компе пользователя.
А сейчас, при работе через портал — та же самая схема с "мутным софтом" и "мутным плагином".
Хотя это не отменяет нынешнего удобства (особенно по сравнению с запросами и выпуском ЭП на FDD как раньше).
А что тут мутного? Не думаю, чтобы ФСБ не заинтересовалось плагином, который может сливать закрытые ключи в неизвестном или известном направлении.
Плагины на то и плагины, чтобы выполняться на стороне пользователя. Отправляются в УЦ открытый ключ и регистрационные данные владельца сертификата. Если бы были намеренные утечки из плагина, их бы давно обнаружили.
Плагины на то и плагины, чтобы выполняться на стороне пользователя. Отправляются в УЦ открытый ключ и регистрационные данные владельца сертификата. Если бы были намеренные утечки из плагина, их бы давно обнаружили.
ну, поскольку речь о государственном УЦ, то думаю плагин если и сливает, то «только в известном ФСБ направлении»
а возможность использовать АРМ ГК до сих пор имеется, рекомендуется через портал, но если вдруг не работает, или нет интернета — то можно и по-старинке запрос на флешке принести, по регламенту обязаны и такой обработать. Например, запросы на сертификаты для КонтинентАП я до сих пор на флешке отношу
а возможность использовать АРМ ГК до сих пор имеется, рекомендуется через портал, но если вдруг не работает, или нет интернета — то можно и по-старинке запрос на флешке принести, по регламенту обязаны и такой обработать. Например, запросы на сертификаты для КонтинентАП я до сих пор на флешке отношу
ГосОблако во всех мониторах страны, ключ тебе даже не дадут, только кнопку «Подписать».
А толку от работы без криптопровайдеров и плагинов, если на госуслуги без них не зайти, в большинство банков тоже? Для себя можно и самому ключ выпустить.
Как бы, ЕМНИП, в пожеланиях ФСБ к УЦ был контроль уникальности сертификата для одного ключа подписи.
При изготовлении ключа под контролем УЦ, эта выполнение этого пожелания заметно упрощается.
При изготовлении ключа под контролем УЦ, эта выполнение этого пожелания заметно упрощается.
Мне, как гражданину, для которого вся система электронных подписей, существующая в стране, представляет угрозу, которую я ни контролировать, ни избегать толком не могу, абсолютно наплевать на пожелания фсб. Хотя пожелание-то, в общем то, резонное, т.к. тоже направлено на безопасность конечного пользователя, но если оно ведёт к таким последствиям — "хотели как лучше, а получилось как всегда".
...«хотели как лучше, а получилось как всегда».Ну, дык, практика Вам не теория. На мой непросвещённый взгляд, только медленной эволюцией можно контролируемо подправить «как всегда» в нужную сторону.
Как бы, в данном случае:
- УЦ создаёт ключ — плохо, по 33 причинам;
- Пользователь предоставляет запрос на сертификат — очень хреново по 33 причинам, например, у некоторых карточек/токенов ДСЧ — мама не горюй. И не говоря уж об тех или иных финтах: https://habr.com/ru/news/t/503424/#comment_21651088 ;
- Пользователь создаёт ключ безопасным контролируемым образом используя как свой ДСЧ, так и ДСЧ от УЦ — такой протокол, да, возможен (аналогично созданию разделённого между несколькими HSM/токенами/карточками ключа таким образом, что вообще нигде нет информации для получения закрытого ключа «в сборе», но только в завершении УЦ отдаёт свою часть пользователю), но… Сложно, непонятно и профессиональные параноики с обеих сторон ходят по потолку;
- Пользовать создаёт ключ на СКЗИ той системы, которая удовлетворяет УЦ, и заверяет запрос предыдущим ключом подписи — компромиссный паллиативный вариант, но многие используют.
Для решения этих проблем существуют стандарты, которые по всему миру работают нормально и универсально, и только в РФ с "финтами".
Всё, что нужно — чётко и ясно разделить ответсвенность, а дальше пусть каждый сам о себе заботится в рамках своей ответсвенности. Это не вопрос технологии, технология позволяет это сделать гарантированно и без проблем — это вопрос административного решения.
В нынешней ситуации ответсвенность за храниние закрытого ключа целиком и полностью возлагается на пользователя непосредственно по закону, но на практике пользователь никак не может свой закрытый ключ проконтролировать непосредственно с момента его создания! Фарс и абсурд.
Хм. И этот подход, создание ключа на УЦ, вполне соответствует стандартам, и многие УЦ по всему миру его используют.
Мало того, один из буржуйских УЦ мне, лет 7-8 назад, вообще закрытый ключ по почте присылал. ;)
И подход с заверенным предыдущим ключом подписи запросами, тоже используют, и в мире, и в РФ.
Мало того, один из буржуйских УЦ мне, лет 7-8 назад, вообще закрытый ключ по почте присылал. ;)
И подход с заверенным предыдущим ключом подписи запросами, тоже используют, и в мире, и в РФ.
чётко и ясно разделить ответсвенность,Хм-хм. Но, строго говоря, с УЦ нельзя разделить ответственность! Он Бог и царь, по-любому! Скажем, регулярно ж, какие надо, спецслужбы с помощью различных УЦ выпускают сертификаты и подписывают то, что им надо от имени Microsoft, Google и т.п.
существуют стандартыМогу ошибаться, но мне кажется, что просто избранные в некоторых конкретных российских УЦ наборы стандартов Вас не удовлетворяют. Как там в Талмуде? Говорят: «Ему нравится тыква, а жене его огурцы»?
Вы не оплачиваете продление, на самом деле. Вы формируете новую пару закрытого и открытого ключей и оплачиваете выпуск сертификата открытого ключа.
Закрытый ключ записывается на флешку или в реестр, а сертификат выпускается УЦ и отсылается Вам. затем Вы его можете внедрить в контейнер закрытого ключа (это даже может автоматически делаться при скачивании) и установить в системе.
Разумеется, все это секурно, т.к. закрытым ключом Вы нигде не светите, а открытый ключ на то и открытый, чтобы его можно было пересылать и выкладывать.
Закрытый ключ записывается на флешку или в реестр, а сертификат выпускается УЦ и отсылается Вам. затем Вы его можете внедрить в контейнер закрытого ключа (это даже может автоматически делаться при скачивании) и установить в системе.
Разумеется, все это секурно, т.к. закрытым ключом Вы нигде не светите, а открытый ключ на то и открытый, чтобы его можно было пересылать и выкладывать.
Ну вот в статье написано «изменить срок действия созданного ключа ЭП технически невозможно — после первичного создания ключа никакие изменения в нем не допускаются». Это же получается никак не мешает мне получить новый ключ и записать его на носитель? Тогда о чем говорит статья?
Так то в «ключе». Ни в открытом, ни в закрытом ключе изменения невозможны. Но в контейнер закрытого ключа можно вносить дополнительную информацию (иначе как бы внедрять в него сертификат открытого ключа?).
Точно так же на открытый ключ технически возможен выпуск нескольких сертификатов. Ведь сертификат открытого ключа не является частью открытого ключа. Это просто электронный документ, удостоверяющий легитимность этого ключа.
Точно так же на открытый ключ технически возможен выпуск нескольких сертификатов. Ведь сертификат открытого ключа не является частью открытого ключа. Это просто электронный документ, удостоверяющий легитимность этого ключа.
Думаю что обяжут УЦ перевыпустить бесплатно ключи со сроком действия на 3 месяца тем, кто попросит, и этим дело кончится. Если конечно это всё примут.
Госдуме бы стоило просто постановить считать 2020 год 2019ым.
Кто-то чего-то недопонимает…
1. Пара закрытого и открытого ключей формируется одновременно.
2. Открытый ключ передается в УЦ для выпуска сертификата.
3. После улаживания формальностей (предоставления документов, оплата услуги УЦ) происходит выпуск сертификата открытого ключа.
4. При этом между п.1 и п.3 может пройти значительное время.
5. Обычно это значительное время для организаций, работающих по ФЗ-44 и ФЗ-223 около 2-х недель (необходимо подготовить кучу бумажек, внести изменения в план закупок, утвердить их, дать отмашку бухгалтерии на оплату счета и т.д), но однажды у меня эта канитель растянулась на без малого два месяца.
6. Сертификат имеет срок начала действия на момент выпуска, а не на момент формирования пары ключей.
7. Т.е. в закрытом ключе не может и не должна содержаться информация о сроках действия.
8. Собственно говоря, она и в открытом ключе не содержится. Для этого и нужен сертификат.
Так что, утверждение о необходимости продления закрытого ключа не верно.
Другое дело, что в контейнере закрытого ключа для удобства переноса часто записывается сразу и сертификат открытого (если это не запрещено). Кроме того, т.к. в закрытом ключе нет информации о владельце, выпускающей организации и сроках действия (хотя это может быть неявно присутствовать в названии контейнера), то осуществляется привязка закрытого ключа и сертификата для удобства пользования.
Таким образом, для обеспечения работы необходимо не просто продлить срок действия сертификата, но перевыпустить его и обязать пользователя скачать его и произвести необходимые манипуляции, как минимум, по привязке нового сертификата и старого закрытого ключа.
Технически в этом ничего невозможного нет. Несколько лет назад, когда юрлица массово переводили то ли с простой ЭЦП на квалифицированную, то ли с квалифицированной на усиленную квалифицированную, как раз ровно это и происходило. Были выпущены новые сертификаты и разосланы оповещения с требованиями скачать их и установить.
Вот только с физлицами может быть все не так просто. Многие из них могут не обладать достаточной квалификацией для выполнения этих действий. А для многих даже оповещение не дойдет.
1. Пара закрытого и открытого ключей формируется одновременно.
2. Открытый ключ передается в УЦ для выпуска сертификата.
3. После улаживания формальностей (предоставления документов, оплата услуги УЦ) происходит выпуск сертификата открытого ключа.
4. При этом между п.1 и п.3 может пройти значительное время.
5. Обычно это значительное время для организаций, работающих по ФЗ-44 и ФЗ-223 около 2-х недель (необходимо подготовить кучу бумажек, внести изменения в план закупок, утвердить их, дать отмашку бухгалтерии на оплату счета и т.д), но однажды у меня эта канитель растянулась на без малого два месяца.
6. Сертификат имеет срок начала действия на момент выпуска, а не на момент формирования пары ключей.
7. Т.е. в закрытом ключе не может и не должна содержаться информация о сроках действия.
8. Собственно говоря, она и в открытом ключе не содержится. Для этого и нужен сертификат.
Так что, утверждение о необходимости продления закрытого ключа не верно.
Другое дело, что в контейнере закрытого ключа для удобства переноса часто записывается сразу и сертификат открытого (если это не запрещено). Кроме того, т.к. в закрытом ключе нет информации о владельце, выпускающей организации и сроках действия (хотя это может быть неявно присутствовать в названии контейнера), то осуществляется привязка закрытого ключа и сертификата для удобства пользования.
Таким образом, для обеспечения работы необходимо не просто продлить срок действия сертификата, но перевыпустить его и обязать пользователя скачать его и произвести необходимые манипуляции, как минимум, по привязке нового сертификата и старого закрытого ключа.
Технически в этом ничего невозможного нет. Несколько лет назад, когда юрлица массово переводили то ли с простой ЭЦП на квалифицированную, то ли с квалифицированной на усиленную квалифицированную, как раз ровно это и происходило. Были выпущены новые сертификаты и разосланы оповещения с требованиями скачать их и установить.
Вот только с физлицами может быть все не так просто. Многие из них могут не обладать достаточной квалификацией для выполнения этих действий. А для многих даже оповещение не дойдет.
А технически разве связка вручную требуется? Исключаем кривой софт («если на токене несколько пар, сертификат для нашего суперсофта обязательно должен быть первым/в первом контейнере»), по идее же криптотокен сам может сопоставлять приватный-публичный ключи, нет? Т.е. условно, софт говорит «а подпиши мне вот это вот публичным ключом таким-то» и токен сам ищет у себя соответствующий приватный ключ, или нет?
Технически это возможно. Только вот неудобно до чертиков.
Во-первых, «голым» открытым ключом пользоваться реально неудобно. Это же просто набор больших чисел. Поэтому сертификат, помимо прочего, представляет собой удобную «обертку» для открытого ключа. Т.е. сертификат по-любому придется скачивать. Хотя бы потому, что ПО (в т.ч. и браузерные плагины) не умеет работать с голыми ключами. Зато с сертификатами работают за милую душу. Например, не отображают в списках просроченные сертификаты.
Во-вторых, при подписании документа в его ЭЦП входит как сам зашифрованный закрытым ключом хеш, так и сертификат, содержащий открытый ключ. Так что, сертификат так и так придется скачивать.
В-третьих, контейнер закрытого ключа может храниться не на криптотокене, а на простой флешке или даже в реестре. Конечно, это не по фен-шую и некошерно секурно, но пока что плагины с такими контейнерами работают.
В четвертых, асимметричное шифрование-дешифрование — достаточно ресурсозатратная штука. Поэтому даже на десктопах и серверах оно применяется для работы с небольшими порциями информации — хешами или ключами симметричного шифрования. Заставлять убогий процессор криптотокена перебором выявлять, какой закрытый ключ соответствует открытому — дело безнадежное.
Т.е. теоретически возможно автоматизировать подписание нужным закрытым ключом по заданному открытому. Практически — лучше даже не пытаться это делать.
Во всяком случае, новый сертификат всё равно нужно будет скачивать.
Во-первых, «голым» открытым ключом пользоваться реально неудобно. Это же просто набор больших чисел. Поэтому сертификат, помимо прочего, представляет собой удобную «обертку» для открытого ключа. Т.е. сертификат по-любому придется скачивать. Хотя бы потому, что ПО (в т.ч. и браузерные плагины) не умеет работать с голыми ключами. Зато с сертификатами работают за милую душу. Например, не отображают в списках просроченные сертификаты.
Во-вторых, при подписании документа в его ЭЦП входит как сам зашифрованный закрытым ключом хеш, так и сертификат, содержащий открытый ключ. Так что, сертификат так и так придется скачивать.
В-третьих, контейнер закрытого ключа может храниться не на криптотокене, а на простой флешке или даже в реестре. Конечно, это не по фен-шую и не
В четвертых, асимметричное шифрование-дешифрование — достаточно ресурсозатратная штука. Поэтому даже на десктопах и серверах оно применяется для работы с небольшими порциями информации — хешами или ключами симметричного шифрования. Заставлять убогий процессор криптотокена перебором выявлять, какой закрытый ключ соответствует открытому — дело безнадежное.
Т.е. теоретически возможно автоматизировать подписание нужным закрытым ключом по заданному открытому. Практически — лучше даже не пытаться это делать.
Во всяком случае, новый сертификат всё равно нужно будет скачивать.
О! Вот еще возможна ситуация с коллизией, когда на криптотокене теоретически могут находиться несколько контейнеров с разными закрытыми ключами, но соответствующими одному открытому. И как автоматически обрабатывать такую ситуацию?
Т.е., в принципе, наверное, все равно каким ключом в таком случае шифровать… но могут быть нюансы.
Т.е., в принципе, наверное, все равно каким ключом в таком случае шифровать… но могут быть нюансы.
«… несколько контейнеров с разными закрытыми ключами, но соответствующими одному открытому...»
Заметим, что для большинства систем и алгоритмов это должно звучать как:«несколько контейнеров с одинаковыми закрытыми и открытыми ключами». Если же не ограничивать божественную милость, то: «несколько контейнеров с функционально эквивалентными закрытыми ключами и одинаковыми открытыми».
Заметим, что для большинства систем и алгоритмов это должно звучать как:«несколько контейнеров с одинаковыми закрытыми и открытыми ключами». Если же не ограничивать божественную милость, то: «несколько контейнеров с функционально эквивалентными закрытыми ключами и одинаковыми открытыми».
вы слишком вольно интерпретируете всю схему.
1. — да, так и есть.
2. в УЦ передается запрос, содержащий открытый ключ, сведения о владельце ключа, информацию об алгоритме и т.д., а не просто открытый ключ.
3-5 не буду комментировать, зависит от многих факторов.
6. так и есть.
7. сам закрытый ключ — это всего лишь массив, вычисляемый по определенным алгоритмам. Контейнер ключа не есть закрытый ключ, контейнер ключа кроме ЗК содержит достаточно большое количество информации, в т.ч. сроки действия. (можете в криптопро нажать кнопку «протестировать»)
8. вы опять упрощаете. Сертификат кроме открытого ключа содержит массу информации.
далее вы пишете дичь. контейнер — это не то же самое, что ЗК. и я не знаю каким образом можно запретить записывать серт в контейнер. ограничение по перевыпуску связано не с техническими ограничениями. один запрос теоретически можно обработать сколько угодно раз и даже в разных УЦ, при этом срок действия можно указать любой. Все ограничения связаны с приказами ФСБ, МКС и иных органов.
Ситуация с перевыпуском неквалов для ФЭТП на квалы — это другой случай, там перевыпускались ЭП в рамках активных контрактов, а тут хотят чтобы истекающие подписи продлили, причем на 3 месяца. Разумеется УЦ этого не будут делать, и никакими распоряжениями их не получится заставить это сделать.
1. — да, так и есть.
2. в УЦ передается запрос, содержащий открытый ключ, сведения о владельце ключа, информацию об алгоритме и т.д., а не просто открытый ключ.
3-5 не буду комментировать, зависит от многих факторов.
6. так и есть.
7. сам закрытый ключ — это всего лишь массив, вычисляемый по определенным алгоритмам. Контейнер ключа не есть закрытый ключ, контейнер ключа кроме ЗК содержит достаточно большое количество информации, в т.ч. сроки действия. (можете в криптопро нажать кнопку «протестировать»)
8. вы опять упрощаете. Сертификат кроме открытого ключа содержит массу информации.
далее вы пишете дичь. контейнер — это не то же самое, что ЗК. и я не знаю каким образом можно запретить записывать серт в контейнер. ограничение по перевыпуску связано не с техническими ограничениями. один запрос теоретически можно обработать сколько угодно раз и даже в разных УЦ, при этом срок действия можно указать любой. Все ограничения связаны с приказами ФСБ, МКС и иных органов.
Ситуация с перевыпуском неквалов для ФЭТП на квалы — это другой случай, там перевыпускались ЭП в рамках активных контрактов, а тут хотят чтобы истекающие подписи продлили, причем на 3 месяца. Разумеется УЦ этого не будут делать, и никакими распоряжениями их не получится заставить это сделать.
Я не упрощал и не вольничал. Но опустил несущественные моменты для понимания того, что сам ЗК не может содержать в себе информацию о сроках действия.
А я где-то утверждал обратное? Как раз я на этом и делал акцент.
Только если провести тестирование контейнера ЗК средствами Крипто Про, то можно увидеть, что информация о сроках действия берется не просто из него, а из записанного в него сертификата ОК.
Я тоже не знаком с подробностями, но мне один раз попался аппаратный криптотокен, на который нельзя не только записать сертификат ОК, но и посмотреть уже записанный. Во всяком случае, извлечь его при помощи Крипто Про не получилось — ругался, что это запрещено. Наверное, для этого было нужно специализированное для этого криптотокена ПО.
Для чего так было сделано — не знаю. Ведь сертификат, по идее, можно извлечь из подписанного документа. Наверное, чтобы УЦ брал еще денежку за обслуживание токена.
Что касается п.п. 3-5, то бывало и за пол дня сертификат выпускали, когда приспичило. Но обычно это затягивается. То секретарь шибко занят, то директор на совещании (объезде, сексуальном часе в горадминистрации), то человек, на которого сертификат оформляется, неделю забывает паспорт принести, то в ОК не могут найти приказ о назначении на должность, то в УЦ документы не принимают, потому что закорючка подписи в заявлении отличается от закорючки в паспорте… или дату заверения копии не проставили… или еще что, то съездить в представительство УЦ не на чем — машину другой отдел одолжил.
Так что, если особо задницу не рвать, то от момента формирования криптопары до момента получения и установки сертификата как раз дней 11-12 проходит. Может быть больше, реже — меньше. Проверено веками…
Контейнер ключа не есть закрытый ключ, контейнер ключа кроме ЗК содержит достаточно большое количество информации, в т.ч. сроки действия. (можете в криптопро нажать кнопку «протестировать»)
А я где-то утверждал обратное? Как раз я на этом и делал акцент.
Только если провести тестирование контейнера ЗК средствами Крипто Про, то можно увидеть, что информация о сроках действия берется не просто из него, а из записанного в него сертификата ОК.
я не знаю каким образом можно запретить записывать серт в контейнер.
Я тоже не знаком с подробностями, но мне один раз попался аппаратный криптотокен, на который нельзя не только записать сертификат ОК, но и посмотреть уже записанный. Во всяком случае, извлечь его при помощи Крипто Про не получилось — ругался, что это запрещено. Наверное, для этого было нужно специализированное для этого криптотокена ПО.
Для чего так было сделано — не знаю. Ведь сертификат, по идее, можно извлечь из подписанного документа. Наверное, чтобы УЦ брал еще денежку за обслуживание токена.
Что касается п.п. 3-5, то бывало и за пол дня сертификат выпускали, когда приспичило. Но обычно это затягивается. То секретарь шибко занят, то директор на совещании (объезде, сексуальном часе в горадминистрации), то человек, на которого сертификат оформляется, неделю забывает паспорт принести, то в ОК не могут найти приказ о назначении на должность, то в УЦ документы не принимают, потому что закорючка подписи в заявлении отличается от закорючки в паспорте… или дату заверения копии не проставили… или еще что, то съездить в представительство УЦ не на чем — машину другой отдел одолжил.
Так что, если особо задницу не рвать, то от момента формирования криптопары до момента получения и установки сертификата как раз дней 11-12 проходит. Может быть больше, реже — меньше. Проверено веками…
Во всяком случае, извлечь его при помощи Крипто Про не получилось — ругался, что это запрещено.
Не показатель. Особенно с каким-нибудь относительно стареньким eToken.
Не помню уже. Это было 2,5 года назад, когда к нам присоединили другую организацию. И надо было буквально последний раз зайти, чтобы подписать распоряжение о ликвидации в связи с объединением. Но все оборудование уже отсоединили от сети и свалили в кучу в ожидании переезда. Был такой вот токен. Но что он из себя представлял, какой марки — не помню. Да и не так уж это было надо — кажется всё в бумажном виде оформили.
Походу нужна статья о том что такое цифровые подписи…
Я в шоке от того, что многие Хабравчане не знают этого. По идее это уже давно всеми используется повсюду…
Да, реально нужна статья с ч-ч-чудными картинками:
Что такое открытый и закрытый ключи и из чего они состоят?
Из чего состоит контейнер закрытого ключа?
В чем отличие открытого ключа от сертификата и из чего состоит сертификат?
Что такое цепочка доверия и что такое самоподписанные сертификаты?
И т.д.
Кстати, я вот действительно не знаю, что представляет собой ключевая пара на эллиптических кривых?
Вот в RSA каждый ключ из пары — это 2 числа: d и n для закрытого ключа, e и n для открытого. А для ГОСТ 34.10-2012 как обстоит?
Пойду почитаю… Где-то я тут статью видел.
Что такое открытый и закрытый ключи и из чего они состоят?
Из чего состоит контейнер закрытого ключа?
В чем отличие открытого ключа от сертификата и из чего состоит сертификат?
Что такое цепочка доверия и что такое самоподписанные сертификаты?
И т.д.
Кстати, я вот действительно не знаю, что представляет собой ключевая пара на эллиптических кривых?
Вот в RSA каждый ключ из пары — это 2 числа: d и n для закрытого ключа, e и n для открытого. А для ГОСТ 34.10-2012 как обстоит?
Пойду почитаю… Где-то я тут статью видел.
Вот эта статья, наверное? habr.com/ru/post/335906
Нет, вот эти:
habr.com/ru/post/188958
habr.com/ru/post/191240
Ничего не понимаю… Может быть по Вашей ссылке попроще будет?
habr.com/ru/post/188958
habr.com/ru/post/191240
Ничего не понимаю… Может быть по Вашей ссылке попроще будет?
Ну судя по информации из второй ссылки, можно считать всем известными параметры кривой D=(p,a,b,G,n,h), т.е. фактически используемую эллиптическую кривую и точку-генератор G на ней, а также точку Q = d * G.
d — число, которое должно быть известно только владельцу ключа. Вычислить d по Q и G, и зная параметры кривой — сложная задача. При подписи используется d, при проверке подписи используется Q, G и кривая.
d — число, которое должно быть известно только владельцу ключа. Вычислить d по Q и G, и зная параметры кривой — сложная задача. При подписи используется d, при проверке подписи используется Q, G и кривая.
UFO just landed and posted this here
Скорее всего в итоге будет: заплати за год, получи подпись на 1 год 3 месяца.
Или если хочешь получить только 3 месяца бесплатно — заплати за работы.
Подпись бесплатна, но ее изготовление стоит денег (работа сотрудников УЦ). Ни кто же не запрещает брать за это деньги, даже закон.
Некоторые УЦ в сертификатах прописывают срок действия закрытого ключа. И опять же в формулярах на СКЗИ указано, что срок действия закрытого ключа не более 1 год и 3 месяца. Поэтому выпуская сертификат по старому запросу, т.е. в той же связке открытый закрытый ключ можно подвести пользователя под нарушение требований ФСБ к СКЗИ
Ну вообще-то проверку выполняет ПО на компьютере. Считывает из сертификата его дату протухания и сравнивает её с системной и если что-то не так, то отказывается принимать эту подпись. Чисто технически ничто не мешает выпустить обновление ПО, которое будет к сертификатам с датой истечения в определённом диапазоне прибавлять несколько месяцев к дате протухания и проверять уже её. Костыль? Костыль. Но реализовать то можно. На счёт безопасности это ничем не отличается от ситуации, что человеку просто сразу выдали сертификат действительный год и эти пару дополнительных месяцев, а не просто год.
Простите, а где, собственно, в тексте законопроекта по ссылке статья 19³? Там идет 19^2 и затем сразу 20^1, а по слову «центры» ищется только «Удостоверяющие центры, получившие аккредитацию до дня вступления в силу настоящего Федерального закона, вправе создавать и выдавать квалифицированные сертификаты в течение всего срока действия аккредитации, но не позднее чем до 1 июля 2021 года».
Как же это смешно — наблюдать со стороны. Как государственные мужи требуют продлить то, чего они не понимают. Они даже спросить не удосужились. Первый же вопрос человеку, связанному с IT — и будет ответ, что это невозможно. Напоминает ситуацию с оконечным шифрованием на устройствах, ключ к которому надо выдать для расшифровки переписки на сервере
Первый же вопрос человеку, связанному с IT — и будет ответ, что это невозможно
Почему невозможно то? Вот же, положил.
У сертификата открытого ключа есть атрибуты момента вступления в действие и момента истечения срока действия. Пока сертификат действует (согласно атрибутам) — можно с тем же открытым ключом сделать новый CSR и запросить у УЦ подписание.
Дык, для этого нужно перевыпустить сертификат с тем же ключем и новым сроком действия и заставить пользователя установить его в системе и настроить привязку к закрытому ключу.
А оне ж хотят, чтобы пользователи ничего не делали (ибо не умеют в массе своей). Чтобы старый сертификат просто продолжал действовать и после окончания срока действия. Я так понимаю.
А оне ж хотят, чтобы пользователи ничего не делали (ибо не умеют в массе своей). Чтобы старый сертификат просто продолжал действовать и после окончания срока действия. Я так понимаю.
Sign up to leave a comment.
Госдума постановила продлить криптографические сертификаты на три месяца