Atom Лента - Форум КриптоПро - Тема:СЕРТИФИКАТЫ ГОСТ2012 - 10Форум КриптоПро - Atom Лентаurn:https:--www-cryptopro-ru:AtomLenta:ForumKriptoPro:Tema:SERTIFIKATYGOST2012-10:1Copyright 2024 Форум КриптоПро2024-03-28T20:32:47Zhttps://www.cryptopro.ru/forum2/Images/YAFLogo.pngForum Adminhttps://www.cryptopro.ruforum@cryptopro.runikolkas_spbhttps://www.cryptopro.ru/forum2/default.aspx?g=profile&u=44318&name=nikolkas_spbnikolkas_spbhttps://www.cryptopro.ru/forum2/default.aspx?g=profile&u=44318&name=nikolkas_spbtwo_oceanshttps://www.cryptopro.ru/forum2/default.aspx?g=profile&u=36490&name=two_oceansnikolkas_spbhttps://www.cryptopro.ru/forum2/default.aspx?g=profile&u=44318&name=nikolkas_spbtwo_oceanshttps://www.cryptopro.ru/forum2/default.aspx?g=profile&u=36490&name=two_oceansСанчир Момолдаевhttps://www.cryptopro.ru/forum2/default.aspx?g=profile&u=50915&name=Санчир МомолдаевАлександр1488https://www.cryptopro.ru/forum2/default.aspx?g=profile&u=54410&name=Александр1488YetAnotherForum.NETurn:https:--www-cryptopro-ru:ftPosts:st1:meid108379:1СЕРТИФИКАТЫ ГОСТ2012<table class="content postContainer_Alt" width="100%"><tr><td><div class="quote"><span class="quotetitle">Автор: two_oceans <a href="/forum2/default.aspx?g=posts&m=108362#post108362"><img src="/forum2/Themes/soclean/icon_latest_reply.gif" title="Перейти к цитате" alt="Перейти к цитате" /></a></span><blockquote>P.S. Тем не менее я все еще считаю, что программисты программ, требующих явно указать криптопровайдер должны попасть в ад именно с такими смешанными сертификатами.</div></div><br /><br />Так точно!</td></tr></table>2019-10-25T08:29:53+03:002019-10-25T08:29:53+03:00nikolkas_spb<table class="content postContainer_Alt" width="100%"><tr><td><div class="quote"><span class="quotetitle">Автор: two_oceans <a href="/forum2/default.aspx?g=posts&m=108362#post108362"><img src="/forum2/Themes/soclean/icon_latest_reply.gif" title="Перейти к цитате" alt="Перейти к цитате" /></a></span><blockquote>P.S. Тем не менее я все еще считаю, что программисты программ, требующих явно указать криптопровайдер должны попасть в ад именно с такими смешанными сертификатами.</div></div><br /><br />Так точно!</td></tr></table>urn:https:--www-cryptopro-ru:ftPosts:st1:meid108362:1СЕРТИФИКАТЫ ГОСТ2012<table class="content postContainer" width="100%"><tr><td><div class="quote"><span class="quotetitle">Автор: nikolkas_spb <a href="/forum2/default.aspx?g=posts&m=108317#post108317"><img src="/forum2/Themes/soclean/icon_latest_reply.gif" title="Перейти к цитате" alt="Перейти к цитате" /></a></span><blockquote><div class="quote"><span class="quotetitle">Автор: two_oceans <a href="/forum2/default.aspx?g=posts&m=108312#post108312"><img src="/forum2/Themes/soclean/icon_latest_reply.gif" title="Перейти к цитате" alt="Перейти к цитате" /></a></span><blockquote>Если конечный сертификат будет гост-2012 512 бит, то на каком-то этапе цепочки должно быть совмещение разной длины ключа УЦ и ключа субъекта в одном сертификате (либо сертификате промежуточного УЦ либо конечном сертификате).</div></div>думаю, что это может дополнительно привести к проблемам при использовании в некоторых программах, например, 1С, где в настройках требуется явно указывать криптопровайдер. <br />при этом, четких указаний использовать 512 бит я не припомню. нафига эти приключения?</div></div>В целом согласен, кроме того, с большей длиной ключа и операции выполняются дольше. Конечно разница не критична для единичных подписаний (проверка сертификата по интернету все равно дольше, да и сотрудники КриптоПро хорошо оптимизировали вопрос), но разница все равно очень существенна при массовом подписании (когда результат проверки и пин-код закэшированы).<br /><br />P.S. Тем не менее я все еще считаю, что программисты программ, требующих явно указать криптопровайдер должны попасть в ад именно с такими смешанными сертификатами. Определить провайдер по алгоритму открытого ключа в сертификате гораздо проще (switch c тремя кейсами) чем накидать элементы управления для выбора провайдера и написать код перечисления провайдеров. Да и сделать класс автовыбирающий класс, вызывающий класс для определенного алгоритм не сложнее.<br /><br /></td></tr></table>2019-10-24T13:20:06+03:002019-10-24T13:20:06+03:00two_oceans<table class="content postContainer" width="100%"><tr><td><div class="quote"><span class="quotetitle">Автор: nikolkas_spb <a href="/forum2/default.aspx?g=posts&m=108317#post108317"><img src="/forum2/Themes/soclean/icon_latest_reply.gif" title="Перейти к цитате" alt="Перейти к цитате" /></a></span><blockquote><div class="quote"><span class="quotetitle">Автор: two_oceans <a href="/forum2/default.aspx?g=posts&m=108312#post108312"><img src="/forum2/Themes/soclean/icon_latest_reply.gif" title="Перейти к цитате" alt="Перейти к цитате" /></a></span><blockquote>Если конечный сертификат будет гост-2012 512 бит, то на каком-то этапе цепочки должно быть совмещение разной длины ключа УЦ и ключа субъекта в одном сертификате (либо сертификате промежуточного УЦ либо конечном сертификате).</div></div>думаю, что это может дополнительно привести к проблемам при использовании в некоторых программах, например, 1С, где в настройках требуется явно указывать криптопровайдер. <br />при этом, четких указаний использовать 512 бит я не припомню. нафига эти приключения?</div></div>В целом согласен, кроме того, с большей длиной ключа и операции выполняются дольше. Конечно разница не критична для единичных подписаний (проверка сертификата по интернету все равно дольше, да и сотрудники КриптоПро хорошо оптимизировали вопрос), но разница все равно очень существенна при массовом подписании (когда результат проверки и пин-код закэшированы).<br /><br />P.S. Тем не менее я все еще считаю, что программисты программ, требующих явно указать криптопровайдер должны попасть в ад именно с такими смешанными сертификатами. Определить провайдер по алгоритму открытого ключа в сертификате гораздо проще (switch c тремя кейсами) чем накидать элементы управления для выбора провайдера и написать код перечисления провайдеров. Да и сделать класс автовыбирающий класс, вызывающий класс для определенного алгоритм не сложнее.<br /><br /></td></tr></table>urn:https:--www-cryptopro-ru:ftPosts:st1:meid108317:1СЕРТИФИКАТЫ ГОСТ2012<table class="content postContainer_Alt" width="100%"><tr><td><div class="quote"><span class="quotetitle">Автор: two_oceans <a href="/forum2/default.aspx?g=posts&m=108312#post108312"><img src="/forum2/Themes/soclean/icon_latest_reply.gif" title="Перейти к цитате" alt="Перейти к цитате" /></a></span><blockquote>Если конечный сертификат будет гост-2012 512 бит, то на каком-то этапе цепочки должно быть совмещение разной длины ключа УЦ и ключа субъекта в одном сертификате (либо сертификате промежуточного УЦ либо конечном сертификате).</div></div><br /><br />думаю, что это может дополнительно привести к проблемам при использовании в некоторых программах, например, 1С, где в настройках требуется явно указывать криптопровайдер. <br />при этом, четких указаний использовать 512 бит я не припомню. нафига эти приключения?</td></tr></table>2019-10-24T09:30:04+03:002019-10-24T09:30:04+03:00nikolkas_spb<table class="content postContainer_Alt" width="100%"><tr><td><div class="quote"><span class="quotetitle">Автор: two_oceans <a href="/forum2/default.aspx?g=posts&m=108312#post108312"><img src="/forum2/Themes/soclean/icon_latest_reply.gif" title="Перейти к цитате" alt="Перейти к цитате" /></a></span><blockquote>Если конечный сертификат будет гост-2012 512 бит, то на каком-то этапе цепочки должно быть совмещение разной длины ключа УЦ и ключа субъекта в одном сертификате (либо сертификате промежуточного УЦ либо конечном сертификате).</div></div><br /><br />думаю, что это может дополнительно привести к проблемам при использовании в некоторых программах, например, 1С, где в настройках требуется явно указывать криптопровайдер. <br />при этом, четких указаний использовать 512 бит я не припомню. нафига эти приключения?</td></tr></table>urn:https:--www-cryptopro-ru:ftPosts:st1:meid108312:1СЕРТИФИКАТЫ ГОСТ20121) практически во всех ЭП включается сам сертификат, на бумажном оттиске отображается серийный номер сертификата или отпечаток сертификата. Достаточно доказать что УЦ на самом деле не выпускал сертификата с данным номером и отпечатком и все ЭП с поддельным сертификатом будут недействительными. Для УЦ имеющих OCSP-ответчик это будет определено при первой же проверке подписи через OCSP. Дальше УЦ может автоматически снести этот неизданный им сертификат (обнаруженный OCSP-ответчиком) в список отзыва и это уже будет доступно для проверки без OCSP-клиента через списки отзыва.<br />2) с шифрованием аналогично - хоть сертификат подделан, если Ваш контрагент использует Ваш сертификат, а не сделанный злоумышленником, то злоумышленник не сможет прочитать сообщение зашифрованное на Ваш сертификате. Если контрагент получает сертификаты из доверенного источника или хотя бы проверяет перед шифрованием сертификат через OCSP (что приводит к пункту 1), то злоумышленник не сможет добиться чтобы контрагент зашифровал данные на поддельный сертификат.<br />3) естественно зная ключ УЦ можно подделать ответ OCSP или список отзыва сертификатов, но это уже потребует доступа к сетевому маршруту между контрагентом и УЦ для подмены адресов, что потребует гораздо больше усилий от злоумышленника. С учетом отечественных требований к провайдерам о записи трафика так злоумышленнику гораздо проще выдать себя.<br /><br />Таким образом, при надлежащей системе безопасности у контрагентов и УЦ - подбор ключа УЦ и выпуск поддельного сертификата от чьего-то имени мало что дает. Конечно если злоумышленник захватит контроль над самим УЦ или контрагент отключил все проверки сертификата, то схема дает сбой. Именно поэтому для аккредитованных УЦ периодически проходит жесткая проверка требований безопасности. Для контрагентов везде сказано что нельзя отключать все проверки сертификатов, как минимум хотя бы ежемесячно нужно ставить свежие списки отзыва, а в идеале получать сертификаты в УЦ с OCSP и проверять сертификаты через OCSP в реальном времени (особенно это касается сертификатов с которыми контрагент встречается впервые).2019-10-24T07:23:12+03:002019-10-24T07:23:12+03:00two_oceans1) практически во всех ЭП включается сам сертификат, на бумажном оттиске отображается серийный номер сертификата или отпечаток сертификата. Достаточно доказать что УЦ на самом деле не выпускал сертификата с данным номером и отпечатком и все ЭП с поддельным сертификатом будут недействительными. Для УЦ имеющих OCSP-ответчик это будет определено при первой же проверке подписи через OCSP. Дальше УЦ может автоматически снести этот неизданный им сертификат (обнаруженный OCSP-ответчиком) в список отзыва и это уже будет доступно для проверки без OCSP-клиента через списки отзыва.<br />2) с шифрованием аналогично - хоть сертификат подделан, если Ваш контрагент использует Ваш сертификат, а не сделанный злоумышленником, то злоумышленник не сможет прочитать сообщение зашифрованное на Ваш сертификате. Если контрагент получает сертификаты из доверенного источника или хотя бы проверяет перед шифрованием сертификат через OCSP (что приводит к пункту 1), то злоумышленник не сможет добиться чтобы контрагент зашифровал данные на поддельный сертификат.<br />3) естественно зная ключ УЦ можно подделать ответ OCSP или список отзыва сертификатов, но это уже потребует доступа к сетевому маршруту между контрагентом и УЦ для подмены адресов, что потребует гораздо больше усилий от злоумышленника. С учетом отечественных требований к провайдерам о записи трафика так злоумышленнику гораздо проще выдать себя.<br /><br />Таким образом, при надлежащей системе безопасности у контрагентов и УЦ - подбор ключа УЦ и выпуск поддельного сертификата от чьего-то имени мало что дает. Конечно если злоумышленник захватит контроль над самим УЦ или контрагент отключил все проверки сертификата, то схема дает сбой. Именно поэтому для аккредитованных УЦ периодически проходит жесткая проверка требований безопасности. Для контрагентов везде сказано что нельзя отключать все проверки сертификатов, как минимум хотя бы ежемесячно нужно ставить свежие списки отзыва, а в идеале получать сертификаты в УЦ с OCSP и проверять сертификаты через OCSP в реальном времени (особенно это касается сертификатов с которыми контрагент встречается впервые).urn:https:--www-cryptopro-ru:ftPosts:st1:meid108291:1СЕРТИФИКАТЫ ГОСТ2012<table class="content postContainer_Alt" width="100%"><tr><td>Добрый день!<br />если речь идет о квалифицированных сертификатах, то такой возможности нет.<br />т.к. нет сертификата минкомсвязи с длиной ключа 512</td></tr></table>2019-10-23T14:17:34+03:002019-10-23T14:17:34+03:00Санчир Момолдаев<table class="content postContainer_Alt" width="100%"><tr><td>Добрый день!<br />если речь идет о квалифицированных сертификатах, то такой возможности нет.<br />т.к. нет сертификата минкомсвязи с длиной ключа 512</td></tr></table>urn:https:--www-cryptopro-ru:ftPosts:st1:meid108290:1СЕРТИФИКАТЫ ГОСТ2012<table class="content postContainer" width="100%"><tr><td>Добрый день!<br /><br />Работаем с рядом банков, для подписи/шифрования используем сертификат, выданный УЦ КриптоПРО.<br />Имеет длину открытого ключа 256 бит.<br />На данный момент имеется ли возможность получить сертификат с длиной ключа 512 бит, подписанный сертификатом с аналогичной длиной ключа?<br /></td></tr></table>2019-10-23T14:03:34+03:002019-10-23T14:03:34+03:00Александр1488<table class="content postContainer" width="100%"><tr><td>Добрый день!<br /><br />Работаем с рядом банков, для подписи/шифрования используем сертификат, выданный УЦ КриптоПРО.<br />Имеет длину открытого ключа 256 бит.<br />На данный момент имеется ли возможность получить сертификат с длиной ключа 512 бит, подписанный сертификатом с аналогичной длиной ключа?<br /></td></tr></table>