We Keep Coding

BouncyCastleProvider not found by JAR on Lucee

We are successfully using the AmazonPay API for Java (amazon-pay-api-sdk-java-2.2.2.jar) in Adobe ColdFusion. We recently introduced Lucee (on Jetty, also running on OpenJDK 8) and attempted to run the same code (relevant excerpt):
payConfig = createObject("java", "com.amazon.pay.api.PayConfiguration").init();
payConfig.setPrivateKey("...");
However, upon calling setPrivateKey, which will arrive at Security.addProvider(new BouncyCastleProvider()); through PayConfiguration, we receive a java.lang.ClassNotFoundException:
lucee.runtime.exp.NativeException: org.bouncycastle.jce.provider.BouncyCastleProvider
at com.amazon.pay.api.PayConfiguration.setPrivateKey(PayConfiguration.java:77)
[...]
at java.lang.Thread.run(Thread.java:823)
Caused by: java.lang.NoClassDefFoundError: org.bouncycastle.jce.provider.BouncyCastleProvider
... 57 more
Caused by: java.lang.ClassNotFoundException: org.bouncycastle.jce.provider.BouncyCastleProvider not found by amazon.pay.api.sdk.java.2.2.2 [49]
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1597)
at org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1982)
at java.lang.ClassLoader.loadClass(ClassLoader.java:881)
... 57 more
We have placed all dependencies (bcprov-jdk15on-1.65.jar being BouncyCastle) in /lucee-server/context/lib. Creating BouncyCastleProvider within a .cfm/.cfc does work as expected:
createObject("java", "org.bouncycastle.jce.provider.BouncyCastleProvider").init()
I don't understand what Lucee's classloader is doing here. What am I missing?

I don't know what Lucee's classloader is doing either to be honest, but this kind of error seems to be quite common when loading certain more complex jars via the Lucee /lib path. It's likely there are "class clashes" going on somewhere.
Lucee is now OSGi based which means the best way of avoiding this is to load third-party java libraries as OSGi bundles. Some libraries are already packaged for OSGi and others can be converted fairly easily. More details here.
The Amazon library doesn't seem to be OSGi friendly, although it could probably be converted without too much effort.
For now, I would look at JavaLoader as the simplest way of getting it working. I don't have any valid Amazon keys to test fully with, but using JavaLoader I was able to at least call the payConfig.setPrivateKey() method without getting a ClassNotFoundException error.

Problems with jCifs authentication on oracle RDMS embedded jvm

I'm using jCifs 1.3.17 to connect and list files on remote windows share.
Everything works fine on my local JRE(5,6,7), but the same code executed on oracle 11g database (11.2.0.3.0) crashes with following stack:
jcifs.smb.SmbAuthException: Logon failure: unknown user name or bad
password. at
jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:546) at
jcifs.smb.SmbTransport.send(SmbTransport.java) at
jcifs.smb.SmbSession.sessionSetup(SmbSession.java) at
jcifs.smb.SmbSession.send(SmbSession.java:218) at
jcifs.smb.SmbTree.treeConnect(SmbTree.java:176) at
jcifs.smb.SmbFile.doConnect(SmbFile.java:911) at
jcifs.smb.SmbFile.connect(SmbFile.java:954) at
jcifs.smb.SmbFile.connect0(SmbFile.java:880) at
jcifs.smb.SmbFile.exists(SmbFile.java) at
pl.openlife.CifsConnect.listCIFSFiles(CifsConnect.java:49)
I found out, that user password lenght might cause the problem:
1. Windows env jdk1.5.0_22 -> works with long passwords
2. Oracle linux, RDMS embeded JVM -> works with short password only (8 characters)
3. Oracle linux, RDMS embeded JVM -> long password fails with error shown above.
Sample code:
NtlmPasswordAuthentication auth = new NtlmPasswordAuthentication(domain,
username,
password);
SmbFile dir = new SmbFile(path,auth);
if(!dir.exists()){
// ABOVE CHECK FAILS
}
I heard somewhere about problems with oracle embedded jvm and bugs in JCE, but this shouldn't be the case, as jcifs have its own implementation of algorithms such as RC4 or DES. Does anyone have a clue what can be the case? Is there a way to walk this around?

Unfortunately I didn't find any answer to the issue mentioned above.
As a walkaround, I have used older version of jcifs (jcifs-1.2.25), which seems to work properly with oracle db embedded jvm.
UPDATE:
I have imported jcifs lib again (1.3.17) and it is working like a charm. I ended up with conclusion, that the java library was not imported properly. Reimport (loadjava) with option "-force" and manual compilation of invalid objects solves the problem always, but (I cant't figure why) in my case it must be loaded in following order :
1. Load my program lib (will cause errors)
2. Load jcifs lib with force option
3. compile and resolve
It seems that oracle jvm is unpredictable :)

SSHJ and the Maven shade plugin

Testing SSHJ in Eclipse and everything looks good. But When I use the Maven shade plugin to package SSHJ I get the following error:
Exception in thread "main" net.schmizz.sshj.userauth.UserAuthException: Exhausted available authentication methods
at net.schmizz.sshj.SSHClient.auth(SSHClient.java:217)
at net.schmizz.sshj.SSHClient.authPublickey(SSHClient.java:316)
at net.schmizz.sshj.SSHClient.authPublickey(SSHClient.java:365)
at net.schmizz.sshj.SSHClient.authPublickey(SSHClient.java:295)
at no.f12.SshRepository.executeTaskOnHost(SshRepository.java:23)
at no.f12.SshService.serviceCommand(SshService.java:22)
at no.f12.App.main(App.java:29)
Adding
Security.addProvider(new org.bouncycastle.jce.provider.BouncyCastleProvider());
changes the error message to:
Exception in thread "main" net.schmizz.sshj.transport.TransportException: Unable to reach a settlement: [] and [aes128-ctr, aes192-ctr, aes256-ctr, arcfour256, arcfour128, aes128-gcm#openssh.com, aes256-gcm#openssh.com, aes128-cbc, 3des-cbc, blowfish-cbc, cast128-cbc, aes192-cbc, aes256-cbc, arcfour, rijndael-cbc#lysator.liu.se]
at net.schmizz.sshj.transport.Proposal.firstMatch(Proposal.java:165)
at net.schmizz.sshj.transport.Proposal.negotiate(Proposal.java:147)
at net.schmizz.sshj.transport.KeyExchanger.gotKexInit(KeyExchanger.java:239)
at net.schmizz.sshj.transport.KeyExchanger.handle(KeyExchanger.java:364)
at net.schmizz.sshj.transport.TransportImpl.handle(TransportImpl.java:478)
at net.schmizz.sshj.transport.Decoder.decode(Decoder.java:127)
at net.schmizz.sshj.transport.Decoder.received(Decoder.java:195)
at net.schmizz.sshj.transport.Reader.run(Reader.java:72)
Any idea how to get around this?
A bit of background to why I want to use shade... I am trying to get to a point where usage of Java and distribution of small utils is dead simple. So I create a really executable jar using this: https://github.com/brianm/really-executable-jars-maven-plugin . That enables me to create one, executable file to distribute and add to the path of the user. A bit like how Go has one binary file with all dependencies.

I had this exact problem. I finally gave up on trying to put everything in a big "uberjar".
Instead I assembled all the jars using maven-assembly-plugin, and then extract and add them to the classpath in order to execute, e.g. 'java -cp all-needed-libs/* com.company.MainClass'.

Another approach that might work is to add bouncycastle to the JRE extension library.
E.g put 'bcprov-jdk15on-1.49.jar' in folder '$JAVA_HOME/jre/lib/ext/' on the host.

You have to sign jar, it's required by Javax.security. I got similar problem and there's stacktrace from my test:
Cannot init Cipher factory: blowfish-cbc
java.lang.SecurityException: JCE cannot authenticate the provider BC
at javax.crypto.Cipher.getInstance(Cipher.java:642)
at javax.crypto.Cipher.getInstance(Cipher.java:580)
at net.schmizz.sshj.common.SecurityUtils.getCipher(SecurityUtils.java:96)
at net.schmizz.sshj.transport.cipher.BaseCipher.init(BaseCipher.java:88)
....
Caused by: java.util.jar.JarException: file:/test-jar-with-dependencies.jar has unsigned entries - library.properties
at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:462)
at javax.crypto.JarVerifier.verifyJars(JarVerifier.java:322)
at javax.crypto.JarVerifier.verify(JarVerifier.java:250)
at javax.crypto.JceSecurity.verifyProviderJar(JceSecurity.java:161)
at javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:187)
at javax.crypto.Cipher.getInstance(Cipher.java:638)
at javax.crypto.Cipher.getInstance(Cipher.java:580)
at net.schmizz.sshj.common.SecurityUtils.getCipher(SecurityUtils.java:96)
at net.schmizz.sshj.transport.cipher.BaseCipher.init(BaseCipher.java:88)
at net.schmizz.sshj.DefaultConfig.initCipherFactories(DefaultConfig.java:152)
at net.schmizz.sshj.DefaultConfig.<init>(DefaultConfig.java:107)

Java Cryptography Providers - Strange Stack Trace

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

There are a few options here (and I'm assuming that before this the signature did verify):
The certificate/private key that was used to generate the signature is now out of date;
The signature is not compatible with a newer version of the Oracle Java runtime;
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.

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

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

Workaround on JCE can't authenticate the provider

I'm running a set of tests on my custom JCE provider implemention (XYZProvider).
Most of my tests are failing with the following error:-
java.lang.SecurityException: JCE cannot authenticate the provider XYZProvider
I have installed (i.e. placed provider's jar file) outside of system JRE (I need to stick to this, can't install in JRE) and maybe this is the reason I'm getting this error.
I have tried to search on this error without much success, tried using
grant codeBase "//location of my provider class files" { permission java.security.AllPermission; } in java.security file to give the necessary permission but with no luck.
Have already added the following line in java.security
security.provider.9=com.ingrian.security.nae.XYZProvider
Any ideas?
Thanks.