1

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 :)

Ishan
  • 325
  • 2
  • 9

3 Answers3

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.

Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263
  • Note that if the .jar files do not contain any signatures they may run on the OpenJDK/JRE, but not on the Oracle JDK/JRE. – Maarten Bodewes Aug 22 '12 at 18:20
  • Thanks, owlstead. What had happened was that a naive tool extracted all the classes from the (signed, valid) provider jar, and packed them in a new jar - excluding all info from the original META-INF/. Your confirmation about obfuscation is what I wanted. – Ishan Aug 22 '12 at 18:35
  • Added the third reason to my reply, glad you found the problem, thanks for the accept. – Maarten Bodewes Aug 22 '12 at 18:57
0

Your third party cryto provider should signed all the jar files especially provider jar. That signature should be trusted by SUN (now oracle).

Siva Arunachalam
  • 7,582
  • 15
  • 79
  • 132
  • Thanks, Siva. That sheds more light on the original issue - a misconfigured build process extracted all the classes from the provider jar, and bundled them (together with other classes from other libs) into a new jar - destroying the signature. Still - why the "strange" stacktrace? – Ishan Aug 22 '12 at 17:49
  • Doesn't address the OP's question. Could have been added as a comment? – Duncan Jones Aug 22 '12 at 17:52
0

Isn't it an elliptic call signature (variable arguments number) ?

Benj
  • 1,184
  • 7
  • 26
  • 57
  • Yes, it looks very much like that - but inside the parentheses here I'm expecting to see File:line information - as you can see in one example line I've typed in (BusinessLib.java:NN). – Ishan Aug 22 '12 at 18:30