Register /
Login
|
Desktop view
|
General Issues
»
Re:iKey 2000 Decrypt problem
Author:
tommy, Visitor
09/10/2009 00:01:49
Hi Igor,
Thank you for the files.
I've installed your v3.4.1 driver on an XP system and took a chance it might work with my iKey 2032 device, but unfortunately the certificates don't show up at all. In this case, it seems impossible to get the problem reproduced without an iKey 2000 device.
I've searched the internet and discussed this matter with people who has more insight in this than me, and the message is clear; it's not possible to use/patch CryptDecryptMessage to mimic CryptDecrypt. Looks like a dead end.
However, I think the big problem here is that I've looked at it from a technician's perspective only, trying to get CryptDecryptMessage to work as CryptDecrypt in order to keep JCAPI strictly compliant with the JCE framework and solve your problem at the same time. The real problem here is actually that you want to encrypt/decrypt a session key still supporting the old CSP drivers for hardware tokens.
Can I propose the following solution instead? We can implement a new JCAPI method which will decrypt the enveloped data and thus use the CryptDecryptMessage function which works with your hardware token. This method won't of course be JCE compliant, but it will solve your problem.
Regards,
Tommy
Author:
igor.conti, Visitor
09/10/2009 11:30:08
Hi Tommy,
OK, we now have to take a decision.
The ideal solution would be to find a mean to get the private key container but it's today impossible.
The solution you propose has several drawbacks :
- the JCAPI would not be JCE compliant any more : i don't realise exactly what it means (if you can explain me ?) but i think i can deal with it,
- the JCAPI would use CryptDecryptMessage : this is more problematic because i quit using the previous DLL because of the erratic behaviour of this method in term of compatibility with the PKCS7 standard and of processing time.
Moreover the best solution would be to use the standard method of JCAPI and if an error occurs toggle to the new method but if the error comes from a real problem (token not present or bad pin code or another thing we can't manage) the JCAPI will toggle to the new method that will not work and loose the real origin of the problem.
So before any progress we have to evaluate in term of statistic how many persons will be touched by the problem. At this time i have tested 6 persons and only 2 have the problem. I will have to test more people and if only a few persons (less than 10% for example) have the problem the developpement of the new method for you and the adaptation of the application for me would be too important compared to the benefice gained ; i will simply tell these persons to buy a more recent token.
It will take several days to make these tests so i will tell you as soon as i could have subsequent results.
Thank you a lot for the time you gave to me.
Regards,
Igor
Author:
tommy, Visitor
12/10/2009 22:11:37
Hi Igor,
Not being JCE compliant means that your code would have to call a method in JCAPI which is not part of the Java Cryptography Extension (JCE) API since JCE's Cipher class don't define a method which takes the data required for CryptDecryptMessage. It means that you can't just replace JCAPI with another JCE provider without changing and recompiling your source code.
Regarding your problems encountered with CryptDecryptMessage, I'm sure most of them can be circumvented. I guess the major problem is that we have to count for a performance penalty though, but I don't know how big it will be.
I agree that the simplest solution would be for your customers to just upgrade their drivers or change to another hardware key model, but it would be nice to support their keys too.
I'll do it like this; I'll make a test implementation to support CryptDecryptMessage in JCAPI to see if it solves your problem, and if it can be used in terms of performance and ease of use.
Regards,
Tommy
Author:
igor.conti, Visitor
13/10/2009 11:58:43
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
Author:
tommy, Visitor
18/10/2009 22:21:20
Hi Igor,
Now I'm done with the implementation. I'm very satisfied with the result since the API got really easy to use, and the performance is very good.
Here are the new methods that I have added into class com.pheox.jcapi.JCAPICipher:
/**
* Encrypts the given message into a PKCS#7 enveloped data blob.
* The symmetric key algorithm used is Triple DES (3DES) with CBC
* block mode and PKCS#7 padding.
* The asymmetric key algorithm used is RSA with ECB block mode and
* PKCS#1 type 2 padding.
*
* @param recipients an array of X.509 certificates i.e one for each recipient.
* @param msg the message to be encrypted.
*
* @return the encrypted message.
*
* @throws GeneralSecurityException if <CODE>msg</CODE> cannot be encrypted. There might
* be many reasons for this e.g. the parameter <CODE>recipients</CODE> is null or
* any given certificate doesn't contain a RSA public key.
* @throws JCAPIJNIRuntimeException if an unexpected error occur inside MS CAPI.
*/
static public byte[] encryptMessage(X509Certificate[] recipients, byte[] msg)
throws GeneralSecurityException
/**
* Decrypts a PKCS#7 enveloped data blob.
* The recipient's certificate(s) must be stored in the MS CAPI system store MY.
*
* @param encryptedMsg the PKCS#7 encoded enveloped message to be decrypted.
*
* @return the decrypted message.
*
* @throws GeneralSecurityException if <CODE>encryptedMsg</CODE> cannot be encrypted.
* There might be many reasons for this e.g. the encrypted message is corrupt,
* or no private key can be found, or decryption algorithm is not supported
* by the MS CAPI CSP etc.
* @throws JCAPIJNIRuntimeException if an unexpected error occur inside MS CAPI.
*/
static public byte[] decryptMessage(byte[] encryptedMsg)
throws GeneralSecurityException
Here is an example program
import java.security.*;
import java.security.cert.X509Certificate;
import com.pheox.jcapi.*;
public class Example
{
public static void main(String[] args)
{
try {
Security.addProvider(new JCAPIProvider());
KeyStore ks = KeyStore.getInstance("msks", "JCAPI");
ks.load(null, null);
String alias = null;
//Get the alias of first available key entry.
for(java.util.Enumeration e = ks.aliases(); e.hasMoreElements(); )
{
alias = (String)e.nextElement();
if(ks.isKeyEntry(alias))
break;
else
alias = null;
}
if(alias == null)
throw new Exception("No key entry alias found.");
//Only use one recipient.
X509Certificate[] recipients = new X509Certificate[1];
recipients[0] = (X509Certificate)ks.getCertificate(alias);
//Encrypt message.
String msg = "This is a secret message.";
byte[] encryptedData = JCAPICipher.encryptMessage(recipients, msg.getBytes("UTF-8"));
//Decrypt message.
byte[] decryptedData = JCAPICipher.decryptMessage(encryptedData);
//Sanity check.
if(!msg.equals(new String(decryptedData, "UTF-8")))
throw new Exception("Decrypted message is not the same as the original message.");
else
System.out.println("Test succeded!");
} catch(Throwable t) {
System.err.println("Example program failed.");
t.printStackTrace();
}
}
}
Please verify that it works for your iKey as well.
Since you are a customer, you can download the new unrestricted version from:
https://pheox.com/customer/download/personalfiles
Regards,
Tommy
Author:
tommy, Visitor
21/10/2009 13:12:12
Hi Igor,
Have you had the possibility yet to test the new methods? We would like to have your response before we put the next release of JCAPI into system test.
Thanks.
Regards,
Tommy
Author:
igor.conti, Visitor
26/10/2009 18:11:40
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
Author:
tommy, Visitor
27/10/2009 12:24:18
Hi Igor,
I can get hold of an Omnikey CardMan 6121 dongle, but that product is just a card reader -> USB dongle i.e it doesn't support cryptographic functions itself, instead it's done by the SIM card to be inserted into that dongle.
Can you provide a SIM card and associated drivers (MS CAPI CSP etc)?
Regarding the memory problems using the new methods, yes, it should be used as a convenient solution for smaller messages. I'll check if there are any other better block based candidates available.
Regards,
Tommy
Author:
igor.conti, Visitor
27/10/2009 14:04:25
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
Author:
tommy, Visitor
28/10/2009 21:14:34
Hi Igor,
Ok, no worries. If you find a retail channel for the card and the MS CAPI CSP, then please let me know the details about it.
Meanwhile I've found a block based solution that is very fast for large files. I've even succeeded to use my old Telia smart card (with SmartTrust CSP) together with it without the need of any PKCS#11 drivers. I think you'll like the solution. The problem is that I have to create a new Java class for it since there must be support for init, update, and final operations. It will take me a couple of days to fix it.
Stay tuned.
Regards,
Tommy
Author:
igor.conti, Visitor
30/10/2009 11:03:52
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
Author:
igor.conti, Visitor
30/10/2009 16:54:35
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 ?
Author:
tommy, Visitor
08/11/2009 22:41:45
Hi Igor,
Now I have finished the implementation. It was far more complex than I anticipated from the beginning, but now it works really good. I think you'll like it. As you'll see, it's very fast and neat to use.
You can download the upgraded version of JCAPI (v1.2.5 RC-2) from:
https://pheox.com/customer/download/personalfiles
I have also attached an example program to this post that shows how to use this new block based implementation.
Regarding your problem with your GemSafe card, you can see what CSP JCAPI is using by:
1. Find the alias name of the certificate that is stored on your card.
2. Use that alias as parameter when calling the JCAPI method JCAPIUtil.getCSP(alias)
I did check the web link you posted, but it doesn't mention any GemSafe Classic V2 TPC WR card. I would like to get my hands on the same card as you have, so can you please give me more information about how to get it?
Alright, can you please test the new JCAPI version together with your iKey token and see that everything is working for you? Please come back with your results and opinions.
Thanks.
Regards,
Tommy
| Filename |
Pkcs7Envelope.java |
| Description |
JCAPI PKCS#7 Envelope Test |
| Filesize |
7 Kbytes
|
| Downloaded |
694 time(s) |
Download
|
Author:
igor.conti, Visitor
09/11/2009 11:23:04
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
Author:
tommy, Visitor
09/11/2009 21:20:59
Hi Igor,
Good, I'm looking forward to hear from you again after the test.
Btw, I did find a silly bug in my example test program. I've attached a corrected version now, please use that one instead.
Also, I made a performance test during encoding/decoding of a 1 Gb large file. I ran the test 3 times and took the average from it. The results are pretty good:
Encoding/encryption time: 103.48 seconds
Decoding/Decryption time: 140.94 seconds
For the test I used a 1024 bits RSA key and a 3DES key on a multi-core CPU (2.4 GHz), 4 Gb memory with a single disk.
Regards,
Tommy
| Filename |
Pkcs7Envelope.java |
| Description |
JCAPI PKCS#7 Example Program |
| Filesize |
7 Kbytes
|
| Downloaded |
704 time(s) |
Download
|
Register /
Login
|
Desktop view
|