Re: [SignServer-develop] HSM slow

[Tomas G. <to...@pr...>]

SunPKCS11 always keeps the session open and reuses it. Authentication is 
needed in order to create new sessions right, so even if SunPKCS11 would 
be able to create new sessions, it would have to store the PKCS#11 
password (i.e. autologin), preventing use of smart cards for PKCS#11 
login etc.

If the session is broken (network pulled) you usually need to restart 
Java in order for SunPKCS11 to create new sessions.

Cheers,
Tomas

On 2014-03-19 09:33, Markus Kilås wrote:
> On 2014-03-18 15:56, Luis Maia wrote:
>>
>>
>>
>> On Tue, Mar 18, 2014 at 2:35 PM, Markus Kilås <ma...@pr...
>> <mailto:ma...@pr...>> wrote:
>>
>>      On 2014-03-18 14:10, Luis Maia wrote:
>>      >
>>      > Em 18/03/2014 09:10, "Markus Kilås" <ma...@pr...
>>      <mailto:ma...@pr...>
>>      > <mailto:ma...@pr... <mailto:ma...@pr...>>> escreveu:
>>      >>
>>      >> On 2014-03-18 09:32, Antoine Louiset wrote:
>>      >> > call the getKeystore() method because the private key changes
>>      for every
>>      >> > signing.
>>      >
>>      >> Yes, a quick look in the CESeCore code seems to show that after
>>      >> activation the keystore is cached. So I believe it is likely that
>>      >> upgrading to SignServer 3.5 would resolve this issue for you.
>>      >
>>      > I am not so sure that caching is a solution, because the keystore
>>      would
>>      > return the cached private key...
>>
>>      In SignServer 3.5 (or if it was 3.4) we have the option to actually
>>      cache the PrivateKey instance which gives a different performance as
>>      compared to the normal way the getPrivateKey() method obtains the key
>>      (from the keystore) so I don't think the PrivateKey is completely cached
>>      only because the KeyStore is.
>>
>>      Anyway, would it be a problem if the PrivateKey was cached?
>>
>>
>> I have no idea how the underlying implementation should work, but i've
>> seen some EID pkcs#11 devices behaving erratically if the private key is
>> cached.
>
> I could imagine their would be problem if a cached PrivateKey instance
> tries to use some session not available anymore. Haven't experienced
> this yet when testing with Utimaco and SoftHSM but for sure their could
> be some issues.
>
>>
>> An explanation I've been told (feature not a bug) to throw exception's
>> on cached keys from their developers is due to the strict  non caching
>> policy in qualified signatures...
>> This would also mean that a session would remain established and the
>> card would try to reuse the session of a qualified signature and throw
>> an exception.
>>
>> Also, in a library I've been implementing, the pin would be cached for a
>> qualified signature and an exception thrown immediately IF the private
>> key object was reused (which is kind of stupid) instead of destroying
>> the previous session...
>>
>> Notice that I've no idea what should be the "right" implementation, but
>> i've had problems before with maintaining sessions and had to make some
>> workarounds.
>
> I think the SunPKCS11 implementation often re-uses old sessions, I tried
> some time to have it close all old session but it always seems to have
> at least one left open, but was some time ago.
>
>>
>>
>> Meanwhile using our HSM none of this problems have ever surfaced, but
>> thinking about what Antoine told :
>>
>> " the private key changes for every signing."
>>
>> I keep wondering if caching the private key will maintain the session on
>> the device and will work properly.
>
> Yes, I was wondering about this statement too and I thought it means
> that he selects a key from the keystore based on which user it is. In
> that case caching the PrivateKey instance would not help, however
> caching the KeyStore (assuming it works with the HSM/PKCS#11
> implementation) could give better performance as it might not have to
> ask the HSM to enumerate all keys every time.
>
>>
>>
>>
>> I know i'm getting in middle of the discussion here, but i think we will
>> have the same problem soon when we will rotate our keys and it is nice
>> to have a discussion before we hit the problems.
>
> I think this is a useful discussion. Your input is very welcome.
>
> We are also interested in the topic of how to make it useful for signers
> to have access to multiple key-pairs and certificates.
>
>
> Regards,
>
> Markus
>
>>
>>
>> Cheers,
>>
>> Luis.
>>
>>
>>
>>
>
>
>