Menu
▾
▴
Re: [SignServer-develop] HSM slow
|
From: Tomas G. <to...@pr...> - 2014-03-19 20:35:41
|
Interesting, thanks for the info. On 19 mars 2014 16:45:23 CET, Luis Maia <lui...@gm...> wrote: >On 03/19/2014 09:04 AM, Tomas Gustavsson wrote: >> 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. >Actually if the card invalidates the session with the provider logout() > >method you do not have to restart JAVA. > >I've been developing a smartcard library (used in persistent applets >from the browser) using the SUNPKCS11 and taking care of issues like >terminal disconnection events, card removal, card insertion,etc. >I noticed that some middleware for smartcards do not invalidate >sessions >when the logout method is called, but apart from that (required a few >changes in the middleware source code) it works without restarting java > >for long-lived sessions interacting with the webapp (and multiple cards > >being removed and inserted, browser refreshed,etc). > >As i cache the keystore across multiple signatures, when a card is >removed if i call the logout method and reinsert a new card it works >fine, but i must catch the insertion events and force a logout >(SUNPKCS11 is not aware of cards being removed). > >To implement the card events we used Threads checking with the >smartcardio the card presence or absence from the terminal (you can >even >use blocking methods). >It may not be the nicest solution but it works with buggy middleware >and >since the session will only be reestablished when a card is absent it >is >fast. > > >Cheers, >Luís. > >> 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. >>>> >>>> >>>> >>>> >>> >>> >> >------------------------------------------------------------------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and >their >> applications. Written by three acclaimed leaders in the field, >> this first edition is now available. Download your free book today! >> http://p.sf.net/sfu/13534_NeoTech >> _______________________________________________ >> SignServer-develop mailing list >> Sig...@li... >> https://lists.sourceforge.net/lists/listinfo/signserver-develop > > >------------------------------------------------------------------------------ >Learn Graph Databases - Download FREE O'Reilly Book >"Graph Databases" is the definitive new guide to graph databases and >their >applications. Written by three acclaimed leaders in the field, >this first edition is now available. Download your free book today! >http://p.sf.net/sfu/13534_NeoTech >_______________________________________________ >SignServer-develop mailing list >Sig...@li... >https://lists.sourceforge.net/lists/listinfo/signserver-develop |
