Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Получить ГОСТ TLS-сертификат для домена (SSL-сертификат)
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

Опции
К последнему сообщению К первому непрочитанному
Offline Power_Gen  
#1 Оставлено : 28 декабря 2021 г. 19:38:44(UTC)
Power_Gen

Статус: Участник

Группы: Участники
Зарегистрирован: 27.05.2015(UTC)
Сообщений: 10
Российская Федерация
Откуда: Санкт-Петербург

Сказал(а) «Спасибо»: 1 раз
Добрый день!

Подскажите, пожалуйста.

В нашей системе клиенты подписывают данные посредством CAdES BES. Затем подпись отправляется от клиента на сервер, где валидируется с использованием JCP (точная версия - 2.0.39014). Пример валидации:

Код:
cadesSignature = new CAdESSignature(cadesInDer, null, null); // cadesInDer = байтовый массив с ЭП
cadesSignature.verify(caCertificates, crls);                 // caCertificates и crls = все корневые сертификаты и СОС по цепочке вплоть до МинКомСвязи


До недавнего времени все клиенты получали ключи через один УЦ. Но в ближайшем будущем это ограничение будет снято и нужно ожидать, что клиент может получить любую квалифицированную ЭП и подписать данные. На серверной стороне будет работать утилита, скачивающая со всех акредитованных УЦ СОСы с заданной периодичностью. В итоге будет получен файловый массив из корневых сертификатов УЦ и СОС:

Код:
Сертификат УЦ 1
СОС УЦ 1
...
Сертификат УЦ N
СОС УЦ N


Есть ли в КриптоПро JCP возможность самостоятельно разобрать наборы Set<X509Certificate> и Set<X509CRL>, выстроить цепочки доверия и проверять сертификат пользователя только на той цепочке, к которой он принадлежит? Условно говоря:

1. Закинули все корневые сертификаты всех известных системе УЦ в Set<X509Certificate> allCaCertificates.
2. Закинули все СОС всех известных системе УЦ в Set<X509CRL> allCrls.
3. Вызвали в JCP какой-нибудь init(allCaCertificates, allCrls), JCP построила цепочки доверия.
4. Вызвали в JCP verify(...), JCP провалидировала ЭП и сертификат пользователя по ранее выстроенной цепочке доверия (и только одной цепочке, не перебирая остальные).

Если такая возможность есть, подскажите, пожалуйста, где можно было бы посмотреть пример реализации.

Заранее спасибо!
Offline Андрей *  
#2 Оставлено : 28 декабря 2021 г. 20:15:39(UTC)
Андрей *

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 26.07.2011(UTC)
Сообщений: 12,630
Мужчина
Российская Федерация

Сказал «Спасибо»: 494 раз
Поблагодарили: 2035 раз в 1579 постах
Здравствуйте.

Цитата:

На серверной стороне будет работать утилита, скачивающая со всех акредитованных УЦ СОСы с заданной периодичностью.



Просьба "так не делать".

Используйте только те сертификаты УЦ и их CRL, которые реально у Вас будут в ИС использоваться (до отключения пользователя\замены им сертификата от другого УЦ).

А не "всех известных УЦ". Аккредитованных остаётся 40 на конец года по новым правилам.

При регистрации клиента - регистрируйте его УЦ и URL CRL для мониторинга.
Также надеюсь, что мониторинг использует предварительно HEAD, сверяя данные с ранее полученным ответом,
а не только GET в цикле по известным CRL (надеюсь не в цикле по клиентам).
Техническую поддержку оказываем тут
Наша база знаний
thanks 2 пользователей поблагодарили Андрей * за этот пост.
Power_Gen оставлено 29.12.2021(UTC), two_oceans оставлено 29.12.2021(UTC)
Offline Андрей *  
#3 Оставлено : 28 декабря 2021 г. 20:16:37(UTC)
Андрей *

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 26.07.2011(UTC)
Сообщений: 12,630
Мужчина
Российская Федерация

Сказал «Спасибо»: 494 раз
Поблагодарили: 2035 раз в 1579 постах
Техническую поддержку оказываем тут
Наша база знаний
Offline Power_Gen  
#4 Оставлено : 29 декабря 2021 г. 1:13:17(UTC)
Power_Gen

Статус: Участник

Группы: Участники
Зарегистрирован: 27.05.2015(UTC)
Сообщений: 10
Российская Федерация
Откуда: Санкт-Петербург

Сказал(а) «Спасибо»: 1 раз
Андрей, спасибо за ответ!

В первом приближении мы так и делаем. Когда появляется новый пользователь, регистрируем в системе его УЦ: корневой сертификат + точки распространения CRL. Далее утилита подхватывает данные УЦ и регулярно обновляет CRL-и.

Но всё же остаётся вопрос: как нам избежать лишней работы при проверке ЭП. Сейчас у нас в тесте около пары десятков зарегистрированных реальных УЦ и мы (особо не парясь) попросту закидываем сертификаты всех УЦ и CRL-и в:

Код:
cadesSignature.verify(caCertificates, crls);


Что видим. В целом проверка занимает миллисекунды, наше нагрузочное тестирование будущего релиза проходит успешно, требуемые к системе тайминги мы соблюдаем. Но:

1. Во-первых, чисто эстетически эта реализация совершенно не нравится: зачем заставлять КриптоПро проверять сертификат пользователя по тем спискам отзыва, к которым он не имеет никакого отношения.
2. Во-вторых, есть пользователи, у которых уже приобретена ЭП и которые планируют эту ЭП использовать при работе с нашей ИС. У УЦ достаточно большие списки отзыва (6-7 Мб). И тут проверка ЭП (тот самый, указанный выше API КриптоПро verify(...)) начинает занимать не миллисекунды, а до нескольких секунд, что для нас становится абсолютно недопустимым.

В связи с этим и возник вопрос: а умеет ли КриптоПро самостоятельно выбирать из массы корневых сертов и CRL-ей то, что ему нужно? Задача то на мой взгляд типовая.

Отредактировано пользователем 29 декабря 2021 г. 2:14:33(UTC)  | Причина: Не указана

Offline Санчир Момолдаев  
#5 Оставлено : 29 декабря 2021 г. 3:26:19(UTC)
Санчир Момолдаев

Статус: Сотрудник

Группы: Модератор, Участники
Зарегистрирован: 03.12.2018(UTC)
Сообщений: 1,038
Российская Федерация

Сказал(а) «Спасибо»: 88 раз
Поблагодарили: 223 раз в 211 постах
Добрый день!

в любом случае будет итерация. либо сразу в коде внутри jcp, либо снаружи в вашем коде

Код:
        CAdESSigner[] signers = cadesToVerify.getCAdESSignerInfos();
        for (CAdESSigner walk : signers) {
            System.out.println(walk.getSignerCertificate().getIssuerDN());
        }

сравнивайте по имени издателя сертификата и издателя crl

попробуйте замерить разницу в производительности. мне кажется она останется неизменной.

Если вас не затруднит, оставьте потом обратную связь.

способ через Authority Key Identifier (oid 2.5.29.35) будет не совсем надежной, т.к. crl может быть подписан другим ключом ЦС, отличным от издателя сертификата, но с теми же компонентами имени.
Техническую поддержку оказываем тут
Наша база знаний
Offline two_oceans  
#6 Оставлено : 29 декабря 2021 г. 7:02:30(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,602
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Автор: Power_Gen Перейти к цитате
2. Во-вторых, есть пользователи, у которых уже приобретена ЭП и которые планируют эту ЭП использовать при работе с нашей ИС. У УЦ достаточно большие списки отзыва (6-7 Мб). И тут проверка ЭП (тот самый, указанный выше API КриптоПро verify(...)) начинает занимать не миллисекунды, а до нескольких секунд, что для нас становится абсолютно недопустимым.

В связи с этим и возник вопрос: а умеет ли КриптоПро самостоятельно выбирать из массы корневых сертов и CRL-ей то, что ему нужно? Задача то на мой взгляд типовая.
Добрый день. Простите, что-то не улавливаю разницу - с чего такой скачок в скорости? Имеется в виду быстро для зарегистрированных пользователей, которые уже в мониторинге и долго для незарегистрированных, которые так сказать "промах кэша СОСов" и иницируют скачивание СОС при проверке?

К слову, по DN мне кажется тоже способ не лучший - сейчас АУЦ меняют сертификат примерно раз в год из-за ограничения год и 3 месяца на использование закрытого ключа. При этом для каждого ежегодного сертификата отдельный список отзыва, а срок действия сертификата уходит далеко в будущее. Если искать по DN, то будут выбраны все они, так как компоненты имени АУЦ особо не меняются. Конечно если использовать совет Андрея, мониторить только используемые УЦ, то выберется меньше, но все равно для крупных УЦ с огромными СОС будут почти всегда выбираться по 2 сертификата и по 2 СОС (так как пока еще действуют сертификаты прошлого года уже получают новый сертификат УЦ и начинают выдавать новые сертификаты). Компромисс мне кажется будет если сравнивать по первому адресу публикации СОС из сертификата, так можно более точно выбрать нужный СОС. Понятно, что такого указания адреса в самом СОС нет, но если система где-то хранит "кэш" СОСов, то можно добавить такое свойство и подцеплять по нему.
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.