[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wss4j-dev
Subject:    RE: [dev-crypto] Bug in Cipher class - workaround found!
From:       <Michael.Davis () servicecanada ! gc ! ca>
Date:       2007-07-24 14:30:48
Message-ID: 70786C90113B6D4C89A76D69F151A041BE2BA3 () ONEV01 ! hrdc-drhc ! net
[Download RAW message or body]

Hi all,

I finally got my code working.

To recap, I was having trouble using secret key encryption in Rampart. More \
specifically, the trouble appeared to be related to the JCE cryptography library when \
using IBM's Java and WebSphere. I was getting a ClassCastException and some of you \
were helpful to suggest that it was a class loader problem.

I did write a custom classloader and used it to force the loading of the BouncyCastle \
classes, but that didn't seem to help - I still got the same error.

So I changed org.apache.security.encryption.XmlCipher such that now it uses the BC \
lightweight API instead of going through JCE.

I understand why this is not desirable as it creates a dependancy from xml-security \
to BC. But for me, it's a good enough fix for now.

I also changed a class in wss4j to not throw an exception if it can't find a keystore \
file, as I'm providing the secret key in a call back class and I'm not using \
certificates.

So now I've got it working the way I want it. I don't need to install certificate \
files on the client or server, and I don't have any JCE problems, so when it's time \
to deploy and I have to send my .ear file to the nasty department across town that \
will host our app, I'll be more confident that there won't be any issues.

It has been a lot of fun getting to know all of this code. Everything I've seen looks \
well written.

cheers,
Michael Davis
Ottawa
 

> -----Original Message-----
> From: Michael.Davis@servicecanada.gc.ca
> [mailto:Michael.Davis@servicecanada.gc.ca]
> Sent: Wednesday, July 18, 2007 1:53 PM
> To: rampart-dev@ws.apache.org
> Cc: wss4j-dev@ws.apache.org; dev-crypto@bouncycastle.org
> Subject: RE: [dev-crypto] Bug in Cipher class?
> 
> 
> Thanks once again!
> 
> > So to sum it up I see 3 ways to try to fix this:
> > 1. Follow david's advice and try to have BC loaded 
> alongside with the
> > IBM JCE. The WSS4J
> > will see its already loaded and not try to reaload it
> 
> I tried that. It seems to break other websphere stuff.
> 
> > 2. Try somehow to force usage of the BC implementation of 
> > javax.crypto.*
> > instead of IBM's - 
> > this will prevent cross-classloader issues.
> 
> I'm trying to figure out a way to do that.
> 
> > 3. Overload your thread classloader - and implement 
> protection of some
> > classes via the
> > loadClass(String) method and try to manually load the BC JCE 
> > in the JCE
> > classloader.
> 
> I'll try that if I can't do #2.
> 
> cheers,
> md
> 
> 
> > -----Original Message-----
> > From: George Stanchev [mailto:Gstanchev@serena.com]
> > Sent: Wednesday, July 18, 2007 1:44 PM
> > To: Davis, Michael; rampart-dev@ws.apache.org
> > Cc: wss4j-dev@ws.apache.org; dev-crypto@bouncycastle.org
> > Subject: RE: [dev-crypto] Bug in Cipher class?
> > 
> > 
> > 
> > Michael,
> > 
> > Unfortunately (or at least that's how I understand it)
> > in your case you don't have control over the classloader that 
> > is running
> > WSS4J to
> > do delegate the loading to the system classloader. In my 
> case, I have
> > implemented 
> > my own isolating classloader and I haveoverloaded the 
> > loadClass() method
> > to "protect" 
> > some classes - if they  are on the protection list, their loading is
> > delegated to the parent 
> > classloader. 
> > 
> > I am not familiar with
> > websphere but does it load the IBM JCE in a separate, higher 
> > classloader
> > then your
> > Thread.getCurrentThread().getContextClassloader()? And why is your
> > javax.crypto.Cipher
> > picked up from the websphere classloader instead of the 
> BC's  provided
> > javax.crypto.Cipher (they do provide an implementation withing their
> > JCE)?
> > If you can make your app to load javax.crypto.Cipher from the 
> > BC JCE in
> > the
> > application CL, I think woould fix your problem.
> > 
> > Best Regards,
> > George
> > 
> > -----Original Message-----
> > From: Michael.Davis@servicecanada.gc.ca
> > [mailto:Michael.Davis@servicecanada.gc.ca] 
> > Sent: Wednesday, July 18, 2007 10:53 AM
> > To: rampart-dev@ws.apache.org
> > Cc: wss4j-dev@ws.apache.org; dev-crypto@bouncycastle.org
> > Subject: RE: [dev-crypto] Bug in Cipher class?
> > 
> > Thanks very much, George.
> > 
> > First I'll try your solution to see if I can get it to work. If I
> > understand correctly, I need to do this:
> > 
> > ClassLoader cl = java.security.Security.class.getClassLoader();
> > Class bcClass = cl.loadClass(
> > "org.bouncycastle.jce.provider.BouncyCastleProvider" );
> > 
> > But I'm not sure how to do the next step:
> > "and then restricting the javax.crypto.* and 
> > org.bouncycastle.* packages
> > to be always loaded from the parent classloader."
> > 
> > I also tried doing:
> > 
> > Cipher cipher = Cipher.getInstance( algo, new 
> > BouncyCastleProvider() );
> > 
> > but it didn't work for the reasons you explain below.
> > 
> > cheers,
> > md
> > 
> > 
> > > -----Original Message-----
> > > From: George Stanchev [mailto:Gstanchev@serena.com]
> > > Sent: Wednesday, July 18, 2007 12:40 PM
> > > To: rampart-dev@ws.apache.org
> > > Cc: wss4j-dev@ws.apache.org
> > > Subject: RE: [dev-crypto] Bug in Cipher class?
> > > 
> > > 
> > > I ran into similar problem with the BC provider supplied 
> with axis2 
> > > since my app is running in an isolating classloader. For 
> me, I was 
> > > able to fix it by loading the BC JCE provider in the
> > > java.security.Security.class.getClassLoader()
> > > classloader and then restricting the javax.crypto.* and
> > > org.bouncycastle.* packages
> > > to be always loaded from the parent classloader. Of course if the 
> > > security restrictions forbid me of getting a hold of the JCE 
> > > classloader I am screwed and my users need to add the jars 
> > manually to
> > 
> > > the jre/lib/ext directory as David indicated below.
> > > 
> > > If WSS4J is relying on BC, then it should assure the proper 
> > > classloader picks up the package.
> > > 
> > > An alternative solution would be to not go via the 
> > > java.security.Security JCE registry and use the JCE 
> > provider directly 
> > > via XXX.getInstance(String transformation, Provider prov) 
> > calls. But 
> > > for some reason (and here the WSS4J developers can chime 
> in) WSS4J 
> > > relies on the Java 1.3 JCE interfaces which lack those 
> methods and 
> > > need to go via the security registry.
> > > 
> > > WSS4J devs, is there a reason to stay with the 1.3 BC 
> > provider or you 
> > > can switch to the BC's JDK 1.4 provider?
> > > 
> > > Michael, I think its worth submitting a JIRA against that issue.
> > > 
> > > Best Regards,
> > > George
> > > 
> > > -----Original Message-----
> > > From: David Hook [mailto:dgh@bund.com.au]
> > > Sent: Tuesday, July 17, 2007 5:00 PM
> > > To: Michael.Davis@servicecanada.gc.ca
> > > Cc: dev-crypto@bouncycastle.org; rampart-dev@ws.apache.org; 
> > > wss4j-dev@ws.apache.org
> > > Subject: RE: [dev-crypto] Bug in Cipher class?
> > > 
> > > 
> > > Try putting the provider jar in jre/lib/ext and add BC to the 
> > > java.security file as well.
> > > 
> > > Regards,
> > > 
> > > David
> > > 
> > > On Tue, 2007-07-17 at 11:03 -0400, 
> Michael.Davis@servicecanada.gc.ca
> > > wrote:
> > > > Thanks very much for your reply, David. Now I have 
> > something to work
> > > with.
> > > > 
> > > > I tried removing the BouncyCastle jar from my project, 
> > but it looks 
> > > > like wss4j requires it. When I remove it, I get an error
> > > saying that
> > > > Cipher can't find a provider supporting the algorithm. I
> > > tried it with
> > > 
> > > > the algorithms defined in wss4j, namely
> > > > 
> > > > AES/CBC/ISO10126Padding and DESede/CBC/ISO10126Padding.
> > > > 
> > > > this happens both on Sun's java with providers SUN, SunJSSE,
> > > SunRsaSign, SunJCE and SunJGSS, and on IBM's java with providers 
> > > IBMJCE, IBMJSSE, IBMJGSSProvider, IBMCertPath and 
> IBMPKCS11. (I get 
> > > those by printing out what's returned by 
> Security.getProviders() ).
> > > > 
> > > > I tried setting the algorithm to "AES" to see if that
> > > works, but that
> > > causes a null pointer exception in wss4j, so I figure I 
> need to use 
> > > the ones that are defined in wss4j.
> > > > 
> > > > So I'm stuck. With IBM's java, I get the class loader issue if I
> > > supply the BouncyCastle jar, and I get an UnsupportedAlgorithm 
> > > exception if I don't.
> > > > 
> > > > Any hints would be very gratefully appreciated!
> > > > 
> > > > cheers,
> > > > Michael Davis
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: David Hook [mailto:dgh@bund.com.au]
> > > > > Sent: Monday, July 16, 2007 8:35 PM
> > > > > To: Davis, Michael
> > > > > Cc: dev-crypto@bouncycastle.org
> > > > > Subject: Re: [dev-crypto] Bug in Cipher class?
> > > > > 
> > > > > 
> > > > > 
> > > > > It's a class loader issue - ciphers need to be loaded by
> > > the system
> > > > > class loader as the JCE is loaded by it. If the 
> > provider jar gets 
> > > > > loaded by another untrusted class loader the
> > > getInstance() call on
> > > > > Cipher will fail with either ClassNotFoundException 
> if no other 
> > > > > class loader can return the class, or 
> ClassCastException if the 
> > > > > class is returned by a class loader but isn't properly 
> > annotated.
> > > > > 
> > > > > You need to make sure the same class loader is picking up the 
> > > > > provider jars as is picking up the JCE classes.
> > > > > 
> > > > > Regards,
> > > > > 
> > > > > David
> > > > > On Mon, 2007-07-16 at 15:08 -0400,
> > > Michael.Davis@servicecanada.gc.ca
> > > > > wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > I've asked this question on the Apache xml security mailing
> > > > > list, but I got no answer. I figure you folks must be 
> > experts on 
> > > > > this stuff, so...
> > > > > > 
> > > > > > I'm developing a web service using Axis2. I'm using its
> > > > > WS-Security framework to encrypt the xml messages. This 
> > framework 
> > > > > ultimately uses the Apache XML Security library, which
> > > has this line
> > > 
> > > > > of code:
> > > > > > 
> > > > > > instance._contextCipher = Cipher.getInstance(jceAlgorithm);
> > > > > > 
> > > > > > This works fine using the Sun jdk1.4, which uses Sun's
> > > > > jce.jar and sunjce_provider.jar. It also works fine using the 
> > > > > BouncyCastle classes - Sun's Cipher class finds and 
> returns the 
> > > > > appropriate BC class.
> > > > > > 
> > > > > > However, when I try to run the app on WebSphere 5.1, I get
> > > > > this error:
> > > > > > 
> > > > > > java.lang.ClassCastException: 
> > > com.ibm.crypto.provider.AESCipher at
> > > 
> > > > > > javax.crypto.Cipher.getInstance(Unknown Source)
> > > > > > 
> > > > > > This is getting thrown by IBM's javax.crypto.Cipher class
> > > > > in ibmjcefw.jar.
> > > > > > 
> > > > > > This happens even if I manipuate the providers to load the
> > > > > BC classes first - in that case the class causing the 
> > > > > ClassCastException is 
> > > > > org.bouncycastle.jce.provider.JCEBlockCipher$AES.
> > > > > > 
> > > > > > Have any of you ever seen this problem before?
> > > > > > 
> > > > > > Many thanks,
> > > > > > Michael Davis
> > > > > > Ottawa
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > 
> **********************************************************************
> > > This email and any files transmitted with it are confidential and 
> > > intended solely for the use of the individual or entity to 
> > whom they 
> > > are addressed. Any unauthorized review, use, disclosure or 
> > > distribution is prohibited. If you are not the intended 
> recipient, 
> > > please contact the sender by reply e-mail and destroy all 
> copies of 
> > > the original message.
> > > 
> > 
> **********************************************************************
> > > 
> > > 
> > > 
> > 
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> > > 
> > > 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> > 
> > 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]