Статус: Новичок
Группы: Участники
Зарегистрирован: 28.01.2015(UTC) Сообщений: 2  Сказал(а) «Спасибо»: 1 раз
|
Добрый день. Столкнулся с проблемой в производительности JCP. Версия JCP 2.0.37985. Oracle JDK 1.7.0_25. Разрабатываю интеграционное решение на базе CXF + WSS4j и ЭЦП на базе гостовских алгоритмов. При нагрузочном тестировании выяснилось, что производительность веб-сервисов решения порядка 10-15 операций в секунду. Профилирование показало, что узким местом является работа с хранилищем сертификатов, в частности методы java.security.KeyStore.getKey() и java.security.KeyStore.getCertificateChain(). Используется хранилище HDImageStore. Отладка показала что: 1) Судя по всему, доступ к хранилищу синхронизирован: Код:java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000e42f26a0> (a ru.CryptoPro.JCP.tools.v)
at java.lang.Object.wait(Object.java:503)
at ru.CryptoPro.JCP.tools.h.lock(Unknown Source)
- locked <0x00000000e42f26a0> (a ru.CryptoPro.JCP.tools.v)
at ru.CryptoPro.JCP.tools.x.lock(Unknown Source)
at ru.CryptoPro.JCP.KeyStore.h.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at ru.CryptoPro.JCP.KeyStore.u.a(Unknown Source)
at ru.CryptoPro.JCP.KeyStore.u.e(Unknown Source)
at ru.CryptoPro.JCP.KeyStore.u.a(Unknown Source)
at ru.CryptoPro.JCP.KeyStore.ContainerStore.engineGetKey(Unknown Source)
at ru.CryptoPro.JCP.KeyStore.JCPKeyStore.engineGetKey(Unknown Source)
at java.security.KeyStore.getKey(KeyStore.java:792)
2) Получение закрытого ключа выполняется медленно из-за неких расчетов, происходящих при этом: Код:at ru.CryptoPro.JCP.Random.CertifiedRandom.getPRSGStatistics(Unknown Source)
at ru.CryptoPro.JCP.Random.CertifiedRandom.a(Unknown Source)
- eliminated <0x00000000fce07400> (a ru.CryptoPro.JCP.Random.CPRandom)
at ru.CryptoPro.JCP.Random.CertifiedRandom.b(Unknown Source)
- eliminated <0x00000000fce07400> (a ru.CryptoPro.JCP.Random.CPRandom)
at ru.CryptoPro.JCP.Random.CertifiedRandom.a(Unknown Source)
- locked <0x00000000fce07400> (a ru.CryptoPro.JCP.Random.CPRandom)
at ru.CryptoPro.JCP.Random.CertifiedRandom.<init>(Unknown Source)
at ru.CryptoPro.JCP.Random.CPRandom.<init>(Unknown Source)
at ru.CryptoPro.JCP.Random.CPRandom.<init>(Unknown Source)
at ru.CryptoPro.JCP.Key.PrivateKeySpec.<init>(Unknown Source)
at ru.CryptoPro.JCP.Key.PrivateKeySpec.createKeyForMac(Unknown Source)
at ru.CryptoPro.JCP.KeyStore.u.a(Unknown Source)
at ru.CryptoPro.JCP.KeyStore.u.a(Unknown Source)
at ru.CryptoPro.JCP.Key.PrivateKeySpec.a(Unknown Source)
at ru.CryptoPro.JCP.Key.PrivateKeySpec.read(Unknown Source)
at ru.CryptoPro.JCP.KeyStore.g.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at ru.CryptoPro.JCP.KeyStore.u.e(Unknown Source)
at ru.CryptoPro.JCP.KeyStore.u.a(Unknown Source)
at ru.CryptoPro.JCP.KeyStore.ContainerStore.engineGetKey(Unknown Source)
at ru.CryptoPro.JCP.KeyStore.JCPKeyStore.engineGetKey(Unknown Source)
at java.security.KeyStore.getKey(KeyStore.java:792)
3) Получение цепочки сертификатов также вызывает дополнительные действия: Код:at ru.CryptoPro.JCP.Random.CertifiedRandom.getPRSGStatistics(Unknown Source)
at ru.CryptoPro.JCP.Random.CertifiedRandom.a(Unknown Source)
- eliminated <0x00000000fcc85d10> (a ru.CryptoPro.JCP.Random.CPRandom)
at ru.CryptoPro.JCP.Random.CertifiedRandom.b(Unknown Source)
- eliminated <0x00000000fcc85d10> (a ru.CryptoPro.JCP.Random.CPRandom)
at ru.CryptoPro.JCP.Random.CertifiedRandom.a(Unknown Source)
- locked <0x00000000fcc85d10> (a ru.CryptoPro.JCP.Random.CPRandom)
at ru.CryptoPro.JCP.Random.CertifiedRandom.<init>(Unknown Source)
at ru.CryptoPro.JCP.Random.CPRandom.<init>(Unknown Source)
at ru.CryptoPro.JCP.Random.CPRandom.<init>(Unknown Source)
at ru.CryptoPro.JCP.Key.PrivateKeySpec.<init>(Unknown Source)
at ru.CryptoPro.JCP.KeyStore.u.m(Unknown Source)
at ru.CryptoPro.JCP.KeyStore.u.<init>(Unknown Source)
at ru.CryptoPro.JCP.KeyStore.ContainerStore.engineGetCertificateChain(Unknown Source)
at ru.CryptoPro.JCP.KeyStore.JCPKeyStore.engineGetCertificateChain(Unknown Source)
at java.security.KeyStore.getCertificateChain(KeyStore.java:817)
Это ожидаемо или я неправильно использую хранилище? Если правильно, то какова предполагаемая производительность KeyStore Крипто-Про? Насколько правильно будет кешировать в памяти приложения закрытие ключи и сертификаты чтобы избежать обращения к хранилищу? Отредактировано пользователем 28 января 2015 г. 13:17:04(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,963 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 704 раз в 665 постах
|
Здравствуйте. Да, в JCP может выполняться инициализация ДСЧ, она отнимает какое-то время. Посмотрите примеры в samples-sources.jar, в частности, пакет wss4j.wss4j1_6_3: в нем есть пример класса wss4j.wss4j1_6_3.ws.security.components.crypto.MerlinEx, кеширующего ключ. До какой-то версии wss4j позволял (может быть, и сейчас позволяет) переопределить класс, работающий с ключом, в специальном конфиге crypto.properties, который мог загружаться классом Crypto (кажется, тот расширял возможности Merlin), например, так: Код:
org.apache.ws.security.crypto.provider=wss4j.wss4j1_6_3.ws.security.components.crypto.MerlinEx // в параметре - наш класс
org.apache.ws.security.crypto.merlin.keystore.type=HDImageStore
org.apache.ws.security.crypto.merlin.keystore.password=my_password
org.apache.ws.security.crypto.merlin.keystore.alias=my_alias
Отредактировано пользователем 28 января 2015 г. 9:46:27(UTC)
| Причина: Не указана |
|
 1 пользователь поблагодарил Евгений Афанасьев за этот пост.
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 28.01.2015(UTC) Сообщений: 2 Сказал(а) «Спасибо»: 1 раз
|
Спасибо, это очень помогло. Правда, возник еще один вопрос - безопасно ли длительное время хранить PrivateKey, полученный из HDImageStore, в оперативной памяти? Судя по всему, объект PrivateKey, полученный из KeyStore, не хранит внутри себя сам ключ, а при обращении к нему обращается к хранилищу, так как, несмотря на все кеширование, обращение к ru.CryptoPro.JCP.KeyStore.HDImage.a.readFile() и ru.CryptoPro.JCP.KeyStore.HDImage.FatFolderEnumerator.<init>() сохраняются. То есть при каждом использовании закрытого ключа, он (или какая-то его часть) считывается из хранилища. Так ли это?
|
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы, Участники
Зарегистрирован: 24.11.2009(UTC)
Сообщений: 965
Откуда: Crypto-Pro
Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 174 раз в 152 постах
|
Безопасно. Ключи после операций над ними перемаскируются. |
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 21.11.2022(UTC)
Сообщений: 8
Сказал(а) «Спасибо»: 3 раз
|
Здравствуйте!
Столкнулся с подобной проблемой в примере samples-sources.jar/tls_proxy. Подскажите, возможно ли там по аналогии реализовать кеширование ключа?
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,963 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 704 раз в 665 постах
|
Да, код tls_proxy находится в samples-sources.jar. |
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 21.11.2022(UTC)
Сообщений: 8
Сказал(а) «Спасибо»: 3 раз
|
Видимо я не правильно выразился. Собственно код tls_proxy я видел (смотрю примеры в составе jcp-2.0.40035), но он судя по всему, также подвержен оверхеду инициализации ДСЧ. Есть ли обходное решение по кешированию ключа при использовании KeyManagerFactory?  example.png (396kb) загружен 4 раз(а).
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,963 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 704 раз в 665 постах
|
Здесь речь, видимо, идет не о закрытых ключах (они кэшируются менеджером ключей в каждом контексте SSLContext), а о сессионных. Последние создаются регулярно, избежать указанных вызовов нельзя.
Попробуйте использовать JCSP вместо JCP. |
|
1 пользователь поблагодарил Евгений Афанасьев за этот пост.
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 21.11.2022(UTC)
Сообщений: 8
Сказал(а) «Спасибо»: 3 раз
|
Евгений, спасибо за ответ! Уточните, пожалуйста, правильно ли я понимаю, что для этого нужно использовать КриптоПро Java CSP и JTLS (версия 5.0.41975)? Будет ли отличаться реализация примера tls_proxy для использования JCSP, можно ли где-то посмотреть? А также уточните, входит ли Java CSP в состав КриптоПро CSP?
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,963 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 704 раз в 665 постах
|
Да, надо Java CSP дистрибутив, там есть тот же tls_proxy. JCSP должен быть установлен, как провайдер по умолчанию. Для JCSP конфиг будет немного другой, например: Код:
<?xml version="1.0" encoding="UTF-8"?>
<Config>
<Parameters inactiveTimeout="60" checkInactiveTimeout="30" serverSoTimeout="600" provider="JCSP" protocol="GostTLS" /> <!-- провайдер JCSP для ключевых контейнеров -->
<CertStore path="test_ca.store" password="1" />
<Addresses>
...
<Address>
<ListenPort>9001</ListenPort>
<Host>host</Host>
<Port>443</Port>
<ClientAuthEnabled>true</ClientAuthEnabled>
<KeyType>HDIMAGE</KeyType> <!-- тип HDIMAGE для ключевых контейнеров -->
<KeyAlias>keyAlias</KeyAlias>
<KeyPassword>keyPassword</KeyPassword>
</Address>
...
</Addresses>
</Config>
|
|
1 пользователь поблагодарил Евгений Афанасьев за этот пост.
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
