Статус: Новичок
Группы: Участники
Зарегистрирован: 23.10.2019(UTC) Сообщений: 3 Откуда: Novosibirsk
|
Добрый день!
Работаем с рядом банков, для подписи/шифрования используем сертификат, выданный УЦ КриптоПРО. Имеет длину открытого ключа 256 бит. На данный момент имеется ли возможность получить сертификат с длиной ключа 512 бит, подписанный сертификатом с аналогичной длиной ключа?
|
|
|
|
Статус: Сотрудник
Группы: Модератор, Участники Зарегистрирован: 03.12.2018(UTC) Сообщений: 1,040 Сказал(а) «Спасибо»: 88 раз Поблагодарили: 226 раз в 213 постах
|
Добрый день! если речь идет о квалифицированных сертификатах, то такой возможности нет. т.к. нет сертификата минкомсвязи с длиной ключа 512 |
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 394 раз в 366 постах
|
Добрый день. Мне даже стало интересно зачем требовать от УЦ такой же длины ключа? Дело в том, что при операции подписания/расшифрования будет использован Ваш закрытый ключ, а не ключ УЦ. Ключ УЦ только заверяет что открытый ключ в сертификате принадлежит Вам. Конечно, есть некий риск что кто-то подберет ключ УЦ и сделает сертифтикат на свой ключ от Вашего имени. Однако смотрите что из этого выйдет:
1) практически во всех ЭП включается сам сертификат, на бумажном оттиске отображается серийный номер сертификата или отпечаток сертификата. Достаточно доказать что УЦ на самом деле не выпускал сертификата с данным номером и отпечатком и все ЭП с поддельным сертификатом будут недействительными. Для УЦ имеющих OCSP-ответчик это будет определено при первой же проверке подписи через OCSP. Дальше УЦ может автоматически снести этот неизданный им сертификат (обнаруженный OCSP-ответчиком) в список отзыва и это уже будет доступно для проверки без OCSP-клиента через списки отзыва. 2) с шифрованием аналогично - хоть сертификат подделан, если Ваш контрагент использует Ваш сертификат, а не сделанный злоумышленником, то злоумышленник не сможет прочитать сообщение зашифрованное на Ваш сертификате. Если контрагент получает сертификаты из доверенного источника или хотя бы проверяет перед шифрованием сертификат через OCSP (что приводит к пункту 1), то злоумышленник не сможет добиться чтобы контрагент зашифровал данные на поддельный сертификат. 3) естественно зная ключ УЦ можно подделать ответ OCSP или список отзыва сертификатов, но это уже потребует доступа к сетевому маршруту между контрагентом и УЦ для подмены адресов, что потребует гораздо больше усилий от злоумышленника. С учетом отечественных требований к провайдерам о записи трафика так злоумышленнику гораздо проще выдать себя.
Таким образом, при надлежащей системе безопасности у контрагентов и УЦ - подбор ключа УЦ и выпуск поддельного сертификата от чьего-то имени мало что дает. Конечно если злоумышленник захватит контроль над самим УЦ или контрагент отключил все проверки сертификата, то схема дает сбой. Именно поэтому для аккредитованных УЦ периодически проходит жесткая проверка требований безопасности. Для контрагентов везде сказано что нельзя отключать все проверки сертификатов, как минимум хотя бы ежемесячно нужно ставить свежие списки отзыва, а в идеале получать сертификаты в УЦ с OCSP и проверять сертификаты через OCSP в реальном времени (особенно это касается сертификатов с которыми контрагент встречается впервые).
Совершенно другой вопрос если подобран Ваш закрытый ключ - в этом случае можно использовать Ваш действительный сертификат и это не обнаружится автоматическими проверками сертификата пока Вы сами не напишите заявление об аннулировании ключа, у злоумышленника нет необходимости вмешиваться в маршрут сетевого канала и как-то выдавать себя. Поэтому ключ конечного пользователя представляет собой более привлекательную цель для злоумышленника и увеличивать число бит имеет смысл именно в ключе конечного пользователя. Если говорить о зарубежных аналогиях, то при замене алгоритма хэширования sha1 на sha2-256 было специальное примечание, что корневой УЦ может продолжать работать сертификатом с алгоритмом хэширования sha1 при условии что сам корневой УЦ выпускает только сертификаты промежуточных УЦ (то есть не выпускает сертификаты конечных клиентов), а все промежуточные УЦ должны использовать новый алгоритм. Ключа Минкомсвязи гост-2012 512 бит не существует как пояснили выше. Если конечный сертификат будет гост-2012 512 бит, то на каком-то этапе цепочки должно быть совмещение разной длины ключа УЦ и ключа субъекта в одном сертификате (либо сертификате промежуточного УЦ либо конечном сертификате). В отношении гост-2012 для аккредитованных УЦ точной информации о возможности совместить не слышал. Отредактировано пользователем 24 октября 2019 г. 7:23:12(UTC)
| Причина: Не указана
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 31.01.2017(UTC) Сообщений: 219 Откуда: Санкт-Петербург Сказал(а) «Спасибо»: 11 раз Поблагодарили: 41 раз в 40 постах
|
Автор: two_oceans Если конечный сертификат будет гост-2012 512 бит, то на каком-то этапе цепочки должно быть совмещение разной длины ключа УЦ и ключа субъекта в одном сертификате (либо сертификате промежуточного УЦ либо конечном сертификате). думаю, что это может дополнительно привести к проблемам при использовании в некоторых программах, например, 1С, где в настройках требуется явно указывать криптопровайдер. при этом, четких указаний использовать 512 бит я не припомню. нафига эти приключения? |
Цена свободы - вечная бдительность! |
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 394 раз в 366 постах
|
Автор: nikolkas_spb Автор: two_oceans Если конечный сертификат будет гост-2012 512 бит, то на каком-то этапе цепочки должно быть совмещение разной длины ключа УЦ и ключа субъекта в одном сертификате (либо сертификате промежуточного УЦ либо конечном сертификате). думаю, что это может дополнительно привести к проблемам при использовании в некоторых программах, например, 1С, где в настройках требуется явно указывать криптопровайдер. при этом, четких указаний использовать 512 бит я не припомню. нафига эти приключения? В целом согласен, кроме того, с большей длиной ключа и операции выполняются дольше. Конечно разница не критична для единичных подписаний (проверка сертификата по интернету все равно дольше, да и сотрудники КриптоПро хорошо оптимизировали вопрос), но разница все равно очень существенна при массовом подписании (когда результат проверки и пин-код закэшированы). P.S. Тем не менее я все еще считаю, что программисты программ, требующих явно указать криптопровайдер должны попасть в ад именно с такими смешанными сертификатами. Определить провайдер по алгоритму открытого ключа в сертификате гораздо проще (switch c тремя кейсами) чем накидать элементы управления для выбора провайдера и написать код перечисления провайдеров. Да и сделать класс автовыбирающий класс, вызывающий класс для определенного алгоритм не сложнее.
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 31.01.2017(UTC) Сообщений: 219 Откуда: Санкт-Петербург Сказал(а) «Спасибо»: 11 раз Поблагодарили: 41 раз в 40 постах
|
Автор: two_oceans P.S. Тем не менее я все еще считаю, что программисты программ, требующих явно указать криптопровайдер должны попасть в ад именно с такими смешанными сертификатами. Так точно! |
Цена свободы - вечная бдительность! |
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close