Поставщики криптографии Java - странная трассировка стека

Question

При поиске неисправностей в некотором криптографическом коде я увидел странную иерархию трассировки стека. Я решил исходную проблему, но мне стало интересно, как можно сгенерировать стековую трассировку. Кто-нибудь может просветить меня?

Обратите внимание, что я не могу скопировать и вставить дословно стэктрейс. Я должен исключить фреймы, которые могут раскрыть проприетарный код.

businesscode.BusinessException: Failed while generating session key
        at businesscode.businessthing.BusinessMethod(BusinessApp.java:NN)
        ... NN more
Caused by: java.security.NoSuchProviderException: JCE cannot authenticate the provider XXX
        at javax.crypto.SunJCE_b.a(DashoA13*..)
        at javax.crypto.KeyGenerator.getInstance(DashoA13*..)
        at businesslib.generateKey(BusinessLib.java:NN)
        ... NN more
Caused by: javax.util.jar.JarException: Cannot parse X.jar
        at javax.crypto.SunJCE_c.a(DashoA13*..)
        at javax.crypto.SunJCE_b.b(DashoA13*..)
        at javax.crypto.SunJCE_b.a(DashoA13*..)
        ... 25 more

Почему имена методов, такие как a и b (SunJCE_c.a, SunJCE_b.b) и информация о файлах / строках как DashoA13 *?

Oracle Java 6 32-битная, работает на 64-битной Linux и 32-битной Windows.

Может ли это быть из-за того, что некоторая информация недоступна, возможно, из-за оптимизации во время выполнения? Или какое-то умышленное запутывание? JNI?

Проблема, которая вызвала это, была то, что сторонний поставщик криптографии был неправильно упакован в файл jar.

РЕДАКТИРОВАТЬ: оригинальный выпуск (NoSuchProviderException: JCE cannot authenticate the provider...) был вызван наивным процессом сборки, который извлек классы провайдера шифрования из их исходного jar -файла и переупаковал их в новый, нетронутый jar -файл, но без требуемой информации о подписи. Спасибо Шиве и Owlstead за напоминание о подписанных банках:)

Answer 1

Здесь есть несколько вариантов (и я предполагаю, что до этого подпись действительно проверялась):

1. Сертификат / закрытый ключ, который использовался для создания подписи, устарел;
2. Подпись несовместима с более новой версией среды выполнения Oracle Java;
3. Подпись над содержанием .jar был удален или содержимое / подпись были изменены.

Что касается странных имен; эти имена являются именами классов, которые были обфусцированы с помощью обфускатора кода. Они не являются частью общедоступного API, поэтому вам не нужно знать их содержание. Они содержат код для проверки подписи и, следовательно, имеют отношение к безопасности.

Answer 2

Разве это не эллиптическая сигнатура вызова (переменное число аргументов)?

Answer 3

Ваш сторонний провайдер криптографии должен подписать все файлы jar, особенно jar провайдера. Этой подписи должен доверять SUN (теперь oracle).