Question

While troubleshooting some cryptographic code, I saw a strange hierarchy of stacktraces. I’ve solved the orignal problem, but became curious about how a stacktrace like this could be generated. Can anyone enlighten me?

Please note that I can’t copy-paste the stacktrace verbatim. I must elide frames that can expose proprietary code.

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

Why method names like a and b (SunJCE_c.a, SunJCE_b.b) and file/line information as DashoA13*?

Oracle Java 6 32-bit, running on 64-bit Linux and 32-bit Windows.

Could this be because some information is unavailable, perhaps due to runtime optimizations? Or some willful obfuscation? JNI?

The issue that caused this was that a third-party crypto provider was packaged incorrectly in a jar file.

EDIT: The original issue (NoSuchProviderException: JCE cannot authenticate the provider...) was caused by a naive build process that extracted the crypto provider classes from their original jar and repackaged them in a new, pristine jar – but without the required signature information.
Thanks to Siva and owlstead for reminding me of signed jars 🙂

Answer 1

There are a few options here (and I’m assuming that before this the signature did verify):

1. The certificate/private key that was used to generate the signature is now out of date;
2. The signature is not compatible with a newer version of the Oracle Java runtime;
3. The signature over the contents of the .jar was removed or the contents / signature were altered.

As for the weird names; those names are names of classes that have been obfuscated with a code obfuscator. The are not part of the public API, so there is no reason for you to know the contents. They contain the code to verify the signature and are therefore security relevant.