Hi again Igor,

I'm glad to hear that you found a solution to your specific problem.
I will look into your suggestion about using SHA-256 instead. Thanks for the info.

We did already release a new official version of JCAPI (v2.1.0), which includes the changes made for msamblanet, at the 28th of November.
Please download it from your customer account:
http://pheox.com/customer/download/products

Regards,
Tommy

Hi,

You're correct. The CSP must in this case provide a PKCS#11 DLL for JCAPI to work with.

I have put the "silent password callback for CAPI CSP" as a requirement on our road map, since apparently you're not the only one who wants to have it now.

Sincerely,
Tommy

Hi,

Yes, you're correct. One can use KP_KEYEXCHANGE_PIN or KP_SIGNATURE_PIN through the CAPI function CryptSetKeyParam. The problem though is that this functionality is not supported by all CSPs. If you're using Microsoft's own software based CSPs then there is no possibility at all to override the password dialog. Most people use these default CSPs, so I don't like to implement support for functionality that will most often fail anyway. It's very simple to implement this, so it might turn up in JCAPI some day, just have to think it through a bit.

However, if you use a hardware based CSP which has a PKCS#11 compliant DLL to access the token, then you can use JCAPI to override the dialog that is shown by the CSP, please see the interface JCAPIPKCS11PINCallback for more information on how to implement it.

Regards,
Tommy

JCAPI version 2.1.0 has been released today.

This is a minor update containing:

• Added new helper methods in class JCAPIKeyStoreProperties to support setting of exportable and/or protected private keys when they are imported into MS CAPI.
• JCAPI can now be executed on Windows Server 2008 (32-bit) without disabling the Data Execution Prevention (DEP).
• Bugfix: JCAPI caused 'Invalid access to memory location' error when started on 32-bits platforms with Java 7.

For a complete list of enhancements and bug fixes made, please read the version history.

Our customers can download the commercial (unrestricted) version from the customers download page. Others are welcome to download the evaluation version from our public download page.

Hi Igor,

Thanks for your file. It helped me a lot.
It's just as I assumed, it seems that your JCAPI.jar file is damaged in some way. The SHA-1 hash on your JCAPI.jar file is:
21446FDCF4E0412570483FA5B8B095FB42E02BE5

The SHA-1 hash on the JCAPI.jar file I made for msamblanet is:
12E0520FDFC4946BA1CA5815F5A5681C7487D4D6

As you can see they are not same. When I replaced your JCAPI.jar file with the other one, then your test program works as expected.

Please download the patched JCAPI.jar file again and verify that its SHA-1 hash is:
12E0520FDFC4946BA1CA5815F5A5681C7487D4D6

Regards,
Tommy

Hi Igor,

Your problem should not be possible to have

There must be something wrong with your jar file. Can you please put your small test program + the compiled class file and the jar file inside a directory and then zip it into a single file, and post it here?

What java version are you using on your XP machine?

Regards,
Tommy

Hi Igor,

I've tested the patched jcapi.jar (the one I made for msamblanet) through an applet on the 32-bit platforms without any problems occurring.

By looking through your console outputs, I can see that your original problem was solved by the patched jcapi.jar. The first console output displays an exception were the cause of it stems from an illegal memory access. The second output (when you use the patched jcapi.jar file) show a totally different exception:

java.lang.SecurityException: invalid SHA1 signature file digest for com/pheox/jcapi/m.class

It seems like your patched jcapi.jar file has been damaged in some way since it cannot be successfully verified by JCAPI itself.
Can you please download it again and create a test program (not an applet) which will do the following:
1. Turn on the internal JCAPI logging.
2. Load the JCAPI provider i.e execute Security.addProvider(new JCAPIProvider());
3. Post the output to this forum thread.

Thanks.

Regards,
Tommy

Hi Igor,

Sorry for my late reply. Your post fell in between two other posts, so I managed to miss yours. I'll try to be more observant in the future.

Your problem seem a bit strange. I'll take a look at it asap.

Regards,
Tommy

Hi,

The problem you have is due to the third party obfuscation tool that we use for JCAPI. We have updated the tool to resolve your problem.
You can find a new jcapi.jar build attached to this post.

We'll fix a new official release soon.

Let us know if you have any other problems.

Regards,
Tommy

Hi Chris,

A key pair generator is already on our top list together with CNG support and some other utility features.
The biggest problem right now is actually to decide where it should be deployed i.e. in a minor release or together with CNG support in a major release of JCAPI.
But I can tell you that it will come.

Thanks for your constructive input. It's much appreciated.

Regards,
Tommy

Hi Chris,

Thank you. You're most welcome.
Glad to here you like it, and that it solves your problem.
I've already tested the remaining permutations, so they should work fine too

Just let us know if you find other problems or limitations.

Regards,
Tommy

Hi Chris,

I've found a nice solution to your problem.
A private key can have two different properties when imported into MS CAPI:
1. Enable strong private key protection. You will be prompted every time the private key is used by an application.
2. Mark the key as exportable. This will allow you to back up or transaport your keys at a later time.

I've added these two properties as methods into the existing class JCAPIKeyStoreProperties to be used when you want to override the default behavior of the SetKeyEntry method in JCAPI KeyStore. The methods are:

public boolean isCreateExportablePrivateKeysInMsCapi()

public void setCreateExportablePrivateKeysInMsCapi(boolean flag)

public boolean isCreateProtectedPrivateKeysInMsCapi()

public void setCreateProtectedPrivateKeysInMsCapi(boolean flag)

Here is an example of how to reconfigure the key store to import all private keys as non-exportable and no extra protection (no dialog).

KeyStore ks = KeyStore.getInstance("msks", "JCAPI");

ks.load(null, null);



JCAPIKeyStoreProperties ksprop = new JCAPIKeyStoreProperties(ks);

ksprop.setCreateExportablePrivateKeysInMsCapi(false);

ksprop.setCreateProtectedPrivateKeysInMsCapi(false);

The patched JCAPI jar file has been attached to this post.

Let me know what you think about it.

Regards,
Tommy

Hi Chris,

Unfortunately JCAPI will tell MS CAPI to display a dialog for the user to decide the level of protection whenever the password parameter is not null. It's a binary behavior for this method, so in other words, your requirement is not supported here.
However, I do see a point here with your request. Give me a couple of days to think this through. I'll see if I can find a nice "fits all" solution without violating the JCE interface. Of course, if you have any good suggestions yourself, then just let me know and we'll have a creative discussion about it.

Regards,
Tommy

The new major release of JCAPI v2.0 has now replaced the former major release of JCAPI (known as v1.x). This means that JCAPI v1.x will enter EOL (End Of Life) from today.
The result from this is that JCAPI v1.x will enter maintenance mode only (no new functions will be added) for three (3) years starting from today.
After three (3) years, JCAPI v1.x will be taken out from maintenance mode and no support or upgrades will be available at all.

We do suggest our current customers to upgrade to JCAPI v2.0 within the coming three years to avoid support problems with legacy software.

Thanks.

Welcome to the main release of our new JCAPI version 2.0.0.

The road has been long and much work has been done along the way. But we think you will appreciate our efforts, and we do also hope that you will enjoy this release as much as we do.

Here's a list of the most interesting features included:

• The JCAPI DLL has been re-written from scratch to increase performance, produce a smaller memory foot print, and to better handle security- and memory management.
• Full native 64-bit support.
• Improved SSL/TLS support. Now JCAPI can be integrated with other SSL/TLS frameworks without the need of a special plug-in. It can now handle protected private keys as well i.e. the private does not have to be exported out of MS CAPI to make it work.
• New PKCS#11 CSPs supported, such as SafeNet RSA CSP, Advanced Card Systems CSP etc.
• New license model available. You can now purchase a Single Runtime License which will bind your license to one machine only. In return you only have to pay a fraction of the price as for an Unlimited Runtime License.
• More supported operating systems:
  • Windows XP (x64)
  • Windows Vista (x64)
  • Windows 7 (x64)
  • Windows Server 2003 (x64)
  • Windows Server 2003 (x86)
  • Windows Server 2008 (x64)
  • Windows Server 2008 (x86)
• Full native support for DSA keys and signatures.
• Full native support for the following additional hash algorithms:
  • SHA-256
  • SHA-384
  • SHA-512
• Full native support for the following additional signature algorithms:
  • SHA512withRSA
  • SHA384withRSA
  • SHA256withRSA
  • SHAMD5withRSA
  • NONEwithRSA
  • SHA1withDSA
• Full native support for symmetric encryption/decryption using the algorithms:
  • AES
  • 3DES
  • DES
  • RC2
  • RC4
• New native PKCS#7 framework available. Supporting encoding/decoding of signed or enveloped data messages.
• Create and delete MS CAPI system (certificate) stores with arbitrary names.
• New support for OAEP padding.
• List and use MS CAPI CSP supported cryptographic algorithms and key lengths in runtime.
• Create java.security.KeyStore instances which maps to one specific MS CAPI system store only. This is very handy when SSL/TLS is to be used for handling private keys and trusted certificates. The following additional key store types are supported:
  • msks-MY
  • msks-ROOT
  • msks-KEYSTORE
  • msks-TRUSTSTORE
• Get the key usage information about each DSA/RSA private key stored in a MS CAPI system store.
• Base64 encode & decode data.
• Create a dynamic JCAPI cryptographic instance wrapped into one of the following Java Cryptography Extension (JCE) interfaces:
  • javax.crypto.Cipher
  • java.security.KeyStore
  • java.security.MessageDigest
  • java.security.SecureRandom
  • java.security.Signature
  Being able to dynamically create and wrap an arbitrary cryptographic algorithm in MS CAPI into a standardized JCE interface, is an extremely powerful feature.
  It gives the programmer the possibility to query MS CAPI in runtime about what algorithms that can be used for encryption and decryption (symmetric/asymmetric), and for creating signatures and message digests. When a desired algorithm has been found, it can then be wrapped into a standard JCE class.

For a full explanation of all new features available, and binary- & source compatibility issues, please read our JCAPI 2.0 - Delta Description document:
http://pheox.com/products/jcapi/2.0.0/JCAPI_v2_Delta_Description.pdf

You can find the JCAPI User's Guide here:
http://pheox.com/products/jcapi/2.0.0/JCAPI_Users_Guide.pdf

Here you can explore the Javadoc information:
http://pheox.com/products/jcapi/2.0.0/javadoc/index.html

You can of course test our new release by downloading it from our public download page:
http://pheox.com/download

A note worth to mention here is that our current customers of JCAPI v1.x can enjoy an upgrade discount of 40% when upgrading to the 32-bit version of JCAPI v2.0.0.

Thanks.