I am using Windows KeyStore to sign with a USB Token.
When the method Signature.sign() is called, it pops up a screen asking the PIN to the user. But when it's called again, without remove the token, the signature is done without asking for any PIN.
Is there a way to "reset" the KeyStore or clear a kind of cache where the PIN is stored, so that forces KeyStore to ask user PIN everytime?
Here is a sample code, where it's made 2 signatures. The PIN is required on the first, but not on the last.
Unfortunately, this is outside the realm of the KeyStore class.
In your particular case, the Java code is talking to the Sun-MSCAPI Bridge, which in turn is talking to an MS-CAPI Cryptographic Service Provider (CSP) - the DLL supplied by the USB token manufacturer - which finally communicates to the token through a driver (also supplied by the token-manufacturer). KeyStore merely makes a call and the layers in between just pass it through; the firmware on the token is the one that throws up the authentication pop-up and maintains session-state, etc. Even though the token manufacturer may have an API call on their native CSP to logout from a session, the KeyStore class does not have anything equivalent.
You could try invalidating your KeyStore instance after you're done with the signing (by setting it to NULL). This may send a signal to the layers in between - and eventually to the token that's maintaining session-state - that a disconnect event was detected, and invalidate the session. However, because this is not the same as pulling out the token from the USB port (causing electrical signals to be sent on the USB bus and sent to the token) its unlikely setting the KeyStore object to null will have the same effect as pulling the token out.
However, you could go one step further (after setting the KeyStore instance to null), by instantiating a new instance of KeyStore using the same provider and then trying to sign something. This might be detected as a new session from the application program, and might cause the PIN pop-up to show again. This has a greater likelihood of working because token manufacturers support this capability when multiple applications on a PC are trying to talk to a hardware token - the token must present the PIN pop-up to every unique application, and maintain session status for each.
What I cannot predict is if the token driver and the token recognize a new instance of KeyStore instantiation from the same application as a new session connection and put up the authentication pop-up, or if they consider this to be an authenticated application (usually from the IP address + process ID + last-access-time values) and reconnect the application to the existing session the token is maintaining for that application. I, for one, would definitely be interested in your results on how this turns out. Thanks.