Статус: Участник
Группы: Участники
Зарегистрирован: 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 провалидировала ЭП и сертификат пользователя по ранее выстроенной цепочке доверия (и только одной цепочке, не перебирая остальные). Если такая возможность есть, подскажите, пожалуйста, где можно было бы посмотреть пример реализации. Заранее спасибо!
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 13,340  Сказал «Спасибо»: 550 раз
Поблагодарили: 2212 раз в 1727 постах
|
Здравствуйте. Цитата:
На серверной стороне будет работать утилита, скачивающая со всех акредитованных УЦ СОСы с заданной периодичностью.
Просьба "так не делать". Используйте только те сертификаты УЦ и их CRL, которые реально у Вас будут в ИС использоваться (до отключения пользователя\замены им сертификата от другого УЦ). А не "всех известных УЦ". Аккредитованных остаётся 40 на конец года по новым правилам. При регистрации клиента - регистрируйте его УЦ и URL CRL для мониторинга. Также надеюсь, что мониторинг использует предварительно HEAD, сверяя данные с ранее полученным ответом, а не только GET в цикле по известным CRL (надеюсь не в цикле по клиентам).
(пример - 30 CRL УЦ проверяются за ... пару секунд + меньше сетевой нагрузки на ИС\УЦ).
Знаю некоторые ИС, которые до сих пор "мониторят" в цикле каждые 10-15 минут CRL УЦ,
которые закрылись несколько лет назад (и даже финальные CRL уже истекли).
|
|
 2 пользователей поблагодарили Андрей * за этот пост.
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 13,340 Сказал «Спасибо»: 550 раз
Поблагодарили: 2212 раз в 1727 постах
|
|
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 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)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Модератор, Участники Зарегистрирован: 03.12.2018(UTC) Сообщений: 1,193 Сказал(а) «Спасибо»: 100 раз
Поблагодарили: 274 раз в 254 постах
|
Добрый день! в любом случае будет итерация. либо сразу в коде внутри 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 может быть подписан другим ключом ЦС, отличным от издателя сертификата, но с теми же компонентами имени. |
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 395 раз в 366 постах
|
Автор: Power_Gen  2. Во-вторых, есть пользователи, у которых уже приобретена ЭП и которые планируют эту ЭП использовать при работе с нашей ИС. У УЦ достаточно большие списки отзыва (6-7 Мб). И тут проверка ЭП (тот самый, указанный выше API КриптоПро verify(...)) начинает занимать не миллисекунды, а до нескольких секунд, что для нас становится абсолютно недопустимым.
В связи с этим и возник вопрос: а умеет ли КриптоПро самостоятельно выбирать из массы корневых сертов и CRL-ей то, что ему нужно? Задача то на мой взгляд типовая. Добрый день. Простите, что-то не улавливаю разницу - с чего такой скачок в скорости? Имеется в виду быстро для зарегистрированных пользователей, которые уже в мониторинге и долго для незарегистрированных, которые так сказать "промах кэша СОСов" и иницируют скачивание СОС при проверке? К слову, по DN мне кажется тоже способ не лучший - сейчас АУЦ меняют сертификат примерно раз в год из-за ограничения год и 3 месяца на использование закрытого ключа. При этом для каждого ежегодного сертификата отдельный список отзыва, а срок действия сертификата уходит далеко в будущее. Если искать по DN, то будут выбраны все они, так как компоненты имени АУЦ особо не меняются. Конечно если использовать совет Андрея, мониторить только используемые УЦ, то выберется меньше, но все равно для крупных УЦ с огромными СОС будут почти всегда выбираться по 2 сертификата и по 2 СОС (так как пока еще действуют сертификаты прошлого года уже получают новый сертификат УЦ и начинают выдавать новые сертификаты). Компромисс мне кажется будет если сравнивать по первому адресу публикации СОС из сертификата, так можно более точно выбрать нужный СОС. Понятно, что такого указания адреса в самом СОС нет, но если система где-то хранит "кэш" СОСов, то можно добавить такое свойство и подцеплять по нему.
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
