Re: [SignServer-develop] HSM slow

[Markus K. <ma...@pr...>]

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.
> 
> 
> 
> 



-- 
Kind regards,
Markus Kilås
PKI Specialist

PrimeKey Solutions AB

Anderstorpsv. 16
171 54 Solna
Sweden

Phone: +46 70 424 94 85
Skype: markusatskype
Email: mar...@pr...

www.primekey.se