I was wondering how would it be possible to make KeyStore Explorer use PKCS11 keystores on SmartCards. At least for signing, not necessarily all SmartCard management features.
Java jarsigner can use certificate on my SmartCard by providing these additional command line parameters:
(linebreaks added here for readability, file smartcard.cfg contains location of DLL of my smart card driver)
Can such keystore be used somehow? Where can I set driver-specific parameters?
this is not currently possible. PKCS#11 support might however be added in one of the next releases. Feel free to add a feature request.
Thanks, I just created feature request:
(whoa, it was assigned a matching number 11 for PKCS#11) :)
This could be done via Windows-MY keystore if the PKCS11 drivers are set up correctly... but during a brief look in the code I noticed PrivateKey object being passed around for signing, which might be a problem.
Any ideas/opinions about this approach?
Alright, maybe a bit of background knowledge first:
There are 2 alternatives for accessing smart cards (or crypto hardware devices in general) on a windows machine:
If you have a PKCS#11 library for your smart card, you most probably have a CSP for it as well.
Java has built-in support for both of these in the form of JCE providers:
Those JCE providers abstract from actual hardware access and wrap everything in well known Java classes (KeyStore, PublicKey, PrivateKey etc.). So a PrivateKey object might be either a key in memory or a reference to a key on a smart card or a HSM.
KSE already uses the SunMSCAPI provider for accessing the Windows keystore, but only the CA keystore "Windows-ROOT", not the user keystore "Windows-MY", which would contain the certificates and keys of your smart card. So at first look this seems to be the easiest route for hardware support in KSE. Unfortunately it's not that easy because the feature set changes with these providers. For example the private key export feature is simply not possible when the key is on a smart card. Also the availability of signature algorithms depends on what the smart card OS supports. Currently KSE is not able to dynamically adapt its GUI to provider capabilities.
However, I have made the first steps towards this in the soon-to-be-released KSE version 5.1 and I am pretty confident that hardware support (i.e. both PKCS#11 and MSCAPI) will make it into release 5.2.
I would like to point to a problem with the SunMSCAPI/Windows-MY Store and with the Java Internal Key Store Interfaces in generally. Unfortunately the Windows Store and the Smart Card does not fit perfectly with the Java Store concept. The java.security.KeyStore provides actually a simple map between Alias (name) on the one side and a single Certificate/Key on the other side, which requires an unique Alias-Name for each certificate!!
Unfortunately windows does not have such unique mapping, it simply supports a free list of certificates, and thus it does not provide unique certificate aliases. The SunMSCAPI just uses one of the certificate attributes as an Alias, usually the subject name. If in the Windos Store respectevly on the Smart Card are more the one certificate with the same subject, the KeyStore using the SunMSCAPI will just provide only one of it and completely hide the others. This is often the case, if you have a current and a list or expired personal certificates. Or as usually on the smart card - I have one certificate for encryption and one for signing - both with the same subject. When I use the Windows-MY store I am able to get only one of them.
Thus, in order to use the "Windows-MY" I have been forced to "hack" the SunMSCAPI by using reflection and to search for multiple certificates by directly accessing the internal enty list, which contains all Windows certificates.
There is also a possibility to directly access the Smart Card using a PCKS Wrapper (https://jce.iaik.tugraz.at/sic/Products/Core-Crypto-Toolkits/PKCS_11_Wrapper), but it is a quite different approach and will require a lot of adaption work.
Yeah, I am aware of that problem. Very annoying. I was planning to use the workaround you mentioned, adding a hash of the certificate to the aliases to make them unique (and accepting the risk of Oracle changing sun.security.mscapi.KeyStore$MY).
Thanks, looking forward to that one!
I don't mind getting an exception when user tries to export private key from smart card. If the error message is nice it would be understandable to all users without the need for KSE to detect the specific provider's feature set :)
May I suggest that the only proper way of accessing smart cards in this context is PKCS11? Because IMHO the goal & purpose of this project is being as platform-independent as possible, and CAPI would tie KSE to Windows like a chained cannonball.
The primary goal of this project is to provide a GUI replacement for keytool and jarsigner (and obviously it already does a lot more than that). This means that KSE should on the long run be able to utilize not only SunMSCAPI (where available) and SunPKCS11 but also third party providers (for example JCE providers for Thales or Utimaco HSMs) - and on the Mac platform the Apple provider as well.
Anyways, support for PKCS#11 and MSCAPI is already implemented in the master branch, however still in a really buggy state (including at least one data loss bug).
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.