Menu
▾
▴
Re: [SignServer-develop] HSM slow
|
From: Antoine L. <ant...@yo...> - 2014-04-27 19:49:04
|
Hi, I upgrade to signserver 3.5.0. The HSM is quite slow. If I do not call PKCS11CryptoToken activate method, I can not get the certificate (and the private key) in the keystore so I can not sign anymore. If I call PKCS11CryptoToken activate method, it takes 13 seconds. So it's quiet long, the getKeystore() method is now very fast. In PKCS11CryptoToken.java in Cesecore, we could see that in the activate method, the keystore is created for each call : final KeyStore keyStore = createKeyStore(authCode); setKeyStore(keyStore); Is there a way tu just update the keystore and not create it each time ? Or another idea to accelerate the process ? Thanks for your help, Antoine Le 19/03/2014 21:35, Tomas Gustavsson a écrit : > 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 > > ------------------------------------------------------------------------------ > 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 photo *Antoine Louiset* Co-founder Yousign t: 33 6 76 66 80 34 | e: ant...@yo... | w: yousign.fr Facebook <http://s.wisestamp.com/links?url=https%3A%2F%2Fwww.facebook.com%2Fpages%2FYousign%2F172490519609309> Twitter <http://s.wisestamp.com/links?url=https%3A%2F%2Ftwitter.com%2FYousignfr> LinkedIn <http://s.wisestamp.com/links?url=http%3A%2F%2Ffr.linkedin.com%2Fpub%2Fyousign-sas%2F89%2F556%2F9a6> YouTube <http://s.wisestamp.com/links?url=https%3A%2F%2Fwww.youtube.com%2Fchannel%2FUCwIeklozHF4J85SBsbwAT5Q> Notre dernier article : Découvrez l’API Yousign <http://s.wisestamp.com/links?url=http%3A%2F%2Fblog.yousign.fr%2Fdecouvrez-lapi-yousign%2F%3Futm_source%3Drss%26utm_medium%3Drss%26utm_campaign%3Ddecouvrez-lapi-yousign> Designed with WiseStamp - <http://s.wisestamp.com/links?url=http%3A%2F%2Fr1.wisestamp.com%2Fr%2Flanding%3Fu%3D72825a891bdebde7%26v%3D3.13.31%26t%3D1398604529412%26promo%3D10%26dest%3Dhttp%253A%252F%252Fwww.wisestamp.com%252Femail-install%253Futm_source%253Dextension%2526utm_medium%253Demail%2526utm_campaign%253Dpromo_10>Get yours <http://s.wisestamp.com/links?url=http%3A%2F%2Fr1.wisestamp.com%2Fr%2Flanding%3Fu%3D72825a891bdebde7%26v%3D3.13.31%26t%3D1398604529412%26promo%3D10%26dest%3Dhttp%253A%252F%252Fwww.wisestamp.com%252Femail-install%253Futm_source%253Dextension%2526utm_medium%253Demail%2526utm_campaign%253Dpromo_10> |
