Indeed !!!

That's cool.

See you next problem (I hope not but we all know computers and Murphy's law).

Regards,
Igor

Hi Tommy,

Of course no problem I've also published it on www.codes-sources.com.

What "Qui quaerit invenit" means I'm not used with this language (latin ?).

Regards,
Igor

Hi Tommy,

I've worked on my side and you can stop searching a solution to my problem. Thanks to the code you wrote on your post i've managed to adapt mine to your implementation.

I've verified the solutions i told you before and the only thing that works was :

System.out.println("Jar file = "+JCAPIProvider.class.getClassLoader().getResource(JCAPIProvider.class.getCanonicalName().replace('.', '/')+".class"));

because the other methods returned null.

But after a good thinking i decided that i had to adapt to you and not the inverse.

So i managed to apply to good ProtectionDomain to the class i defined but another problem has appeared : i couldn't defined the good package for the class. So i made an hybrid code between my classloader and Java's URLClassLoader and i managed to pass the JCAPI initialization.

I've also verified that my classloader was compatible with Bouncycastle (another Provider) and with your plugins.

For your curiosity i've joined to this post the new jars that worked.

Thanks for your help.

Regards,
Igor

Hi Tommy,

OK I understand the problem : when you use the method getProtectionDomain() you get the ProtectionDomain of the class JCAPIProvider that is an object that represents a domain name associated with a set of permissions that are given to the applet.

Then the getCodeSource() method gives you a Code Source object which is the equivalent to a sort of codebase that encapsulate not only the location (URL) but also the certificate chains that were used to verify signed code originating from that location (PheoxInterbatLoader).

Here i am the signer of the applet and the location associated with the CodeSource object is the location of the class whose certificates are used to make the verification.

Your code will work as soon as you're the only signer of the class JCAPIProvider but because i'm cosigning your jar your signature is not verified by the JVM and the location of your jar is not stored in the CodeSource and the ProtectionDomain object.

Of course if i don't sign your jar the problem will disappear but the user will be asked to accept the signature of all the jars i'm using in my applets (the user will have to click in 7 or 8 dialog boxes).

I'm going to make some tests to see how you can get the location of your jar easily : i have several ideas such as using the getSigners() method (to direrectly get the signer certificate), the getPackage() method or the findResource method (with the name of the jar as an argument) of the Class object.

Regards,
Igor

Hi Tommy,

Indeed that's strange : when you list the certificates of a JarFile that is not signed by me you get 2 certificates that belongs to me.

I think that when you try to get the JarFile JCAPI.jar then you get another JarFile that is signed by me.

I'm going to look at my code from my side but it will help me if you could tell me which method you use to access to the JCAPI.jar.

Thanks.

Regards,
Igor

Hi Tommy,

I've made a simplier code for you.

I have removed all the parts that managed the download and cache of the jars.

I've joined to this post a zip file (pheox.zip) that contains 3 jars :
- JCAPI.jar signed with my certificate (in addition to yours) because for better deployment all the jars should be signed with the same certificate
- LaunchJCAPI.jar a small applet that contains only the line Security.addProvider(new JCAPIProvider());
- PheoxInterbatLoader.jar that contains the code of the classloader that launch the LaunchJCAPI applet

You can launch the PheoxInterbatLoader applet from any location but you'll have to store the 2 other jars in your C:\ directory. If you can't this can be configured in the Java Code of the PheoxInterbatLoader class.

I've made some research and i think that you use in the init code of the JCAPI the default system classloader (instead of the classloader of the JCAPIProvider class) to access to a ressource of the JCAPI.jar or that you you access a method of the JCAPIProvider classloader that i've forgotten to overload. That is just an idea i've had but perhaps it's something totally different.

Don't hesitate if you have more precisions to ask me.

Thanks.

Regards,
Igor

Hi Tommy,

Since last time we discussed, I have decided to develop a personnalized ClassLoader for my applets.

In fact the new classloader loads all the jars needed for the applets in a subdirectory of the home directory of the user, then as needed it loads classes from this location.

Everything is working well except when i try to initialize the JCAPI with Security.addProvider(new JCAPIProvider()); then I get an error :

java.security.ProviderException: Verification of JCAPI JAR file integrity failed.
Reason: JAR file not signed by Pheox, Sweden.

I think that the problem doesn't come from the JCAPI.jar itself because when i use the jar without the new classloader (ie when i use the Java default classloader) there's no problem with the integrity.

I join to this post the file console.txt that contains the output of the console with the logging of JCAPI activated and the file InterbatLoader.java that contains the new personalized ClassLoader.

I'm sure that something is wrong with the classloader and i hope that you could help me.

Regards,
Igor

Hi Tommy,

That's OK to close this case and mark it as RESOLVED.

Thank you very much for all the time you have spent for me, I'll will continue developement by myself for now.

As you can see, like most of French people, my english is not totally fluent, and sometimes I search my words, so I could have been misunderstood but you can be sure that I've never meant to be aggressive or condescending.

Bye !

Regards,
Igor

Hi Tommy,

The test works perfectly with the iKey 2000.

So i have a few questions :
- i have studied the crypted file produced and it is really closed to the ones i create with my applet using BouncyCastle so i would know if you have used BouncyCastle to encapsulate in PKCS7 ?
- when i crypt for two recipients (one with private key on a USB token and the other with private key in Windows store), whatever the order of the certificates it always ask me for the PIN code, so do you uncrypt for all the recipients ?
- your new version works very well and is compliant with some tokens which didn't worked with the previous one so do you think that it could be possible to make this new version the default one and become JCE compliant ? (your static methods encryptMessage and decryptMessage could be used to implements wrap and unwrap of the Cipher abstract class)
- there's no mean to choose the private key to use for decryption when there are several ones possible so when the PIN code is asked you don't know which one you have to enter (it's dangerous when 5 Pin codes are possible (ie a file crypted with 5 certificates) thinking that most of the cards block after 3 tries.

To conclude i wanted to tell you that your test program has a little bug : I've launched it as an applet and when the processing is finished but the applet still loaded i can't delete it (in Windows explorer : i've commented your deleteFiles method). This is corrected by closing the FileOutputStream after the BufferedOutputStream, for example :

//Close resources.
bos.close();
bis.close();

becomes

//Close resources.
bos.close();
fos.close();
bis.close();
fis.close();

And in your filesAreEqual method you don't close any FileInputStream nor BufferedInputStream.

I always make such bugs all the time. So don't worry about it.

Regards,
Igor

Hi Tommy,

I'll try the new version today or tomorrow.

For the GemSafe token, in fact this is a card given by Certinomis to try their new Certificates. It 's a test card they lent to me so i don't know exactly which card it is, the model i mentionned was given by a JavaCard explorer but it can be wrong.

The link i gave you points to Gemalto Webstore but it didn't find the card either.

Anyway the card has a problem : the software given by GemSafe that i use to configure it (import certificates, change pin, ...) says that the card is missing when to token with the card is actually plugged on an USB port.

I think that there is a bug with this card so i will tell you when i get much more information.

Regards,
Igor

Hi Tommy,

I've made the tests with your more recent JCAPI.jar.

For the Rainbow iKey 2000 the test succeeded.

For the GemSafe Classic V2 TPC WR the test failed here is the log of the Java Console :

Example program failed.
java.security.GeneralSecurityException: Decryption failed.
Exception raised in JCAPI.DLL:
CAPICipher_decryptMessage() - Could not decrypt message.
Error code: 0x80090005
at com.pheox.jcapi.d.a(Unknown Source)
at com.pheox.jcapi.JCAPICipher.decryptMessage(Unknown Source)
at testapplet.process.Kernel.traite(Kernel.java:194)
at testapplet.ui.MainPanel.actionPerformed(MainPanel.java:132)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)


Should that confirm what i said before : the MS CAPI CSP for this card doesn't exist and Windows let the Gemsafe's tool manage directly the card ?

Hi Tommy,

I didn't manage to join Pheox website yesterday.

I'm not sure i have well understood what do you mean when you say "retail channel channel for the card", my english is not really fluent but if you mean "a link to a webstore for buying the card" i can help you : try http://store.gemalto.com/is-bin/INTERSHOP.enfinity/eCS/Store/en/-/EUR/BrowseCatalog-Start;sid=oErkWrzjhMTkWvYJFrkk8tnnqp3GWcrbnWg=?CatalogCategoryID=dT3AqGXo1M8AAAER27gR2Hop&BuyerClass=&Template=category_2B2C

That's cool if you can find a mean to create block based solution. I've got the iKey back and i'm going to test your last version or JCAPI : i'll tell you if it works.

Regards,
Igor

Hi Tommy,

Oups sorry, i bugged, the card is a GemSafe Classic V2 TPC WR and the CSP is Gemalto Classic Card CSP.

The problem is i don't know where to find the MS CAPI CSP and i don't know if there exists one because it seems that Windows let the regtool manage the card directly but i'm not sure.

Regards,
Igor

Hi Tommy,

Sorry for the wait but i had to take some holidays and i didn't read your answer before.

In fact a friend took the key and it will come back at the end of the week so i'll do the test as soon as i could.

I have found another dongle USB, more recent that makes exactly the same problem : it's the Omnikey CardMan 6121. This dongle is given by Certinomis to contain their certificates, maybe could you get this model and try to solve the problem ?

Before having testing them i can see that there is a probleme with your new static methods using CryptDecryptMessage : if i have a file whose size is almost 100 MB the method will have to process a lot of data and it will give a memory problem.

With the previous version i could use the CipherInputStream class or the CMSEnveloppedDataStreamGenerator and the CMSEnveloppedDataParser that make the work "on the fly".

Regards,
Igor

Hi Tommy,

In fact the big problem with CryptDecryptMessage, if it can help you, was to determine which sort of file i had to process.

Indeed, my program takes as entry a PKCS7 file that can be a signed file or an enveloped file, the tag that design the type of file is in the 20 first bytes of the file but the dll i used before, took sometimes more than 30 minutes to discover the type of the file (the files usually are 20 - 100 Mo long).

This problem reappears 2 times more during the decryption (call to GetMessageType method, i saw it on the log of the dll) so it can take more than a hour for processing the file, but the decryption process takes only 5 minutes (i started the time count as soon as Windows asks me to use the private key).

The others problems are not so bad and i can deal with them but if you can walk through the time problem i would be the happiest man.

Regards,
Igor