Menu
▾
▴
Re: [SignServer-develop] HSM slow
|
From: Antoine L. <ant...@yo...> - 2014-04-28 07:36:09
|
Thanks for your answer. In my case, this is not really the configuration which changes but the private key changes for each request. So I need to activate the cryptotoken each time. It s still slow as in earlier versions, not slower. This is not a problem of changing the configuration of the worker. I do not update the configuration of the worker, I send the alias directly in the request. Le 28 avr. 2014 09:18, =?ISO-8859-1?Q?Markus_Kil=E5s?= <ma...@pr...> a écrit : > > > On 2014-04-27 19:22, Antoine Louiset wrote: > > Hi, > > > > I upgrade to signserver 3.5.0. The HSM is quite slow. > > You mean that activation is still slow as in earlier versions or slower now? > > > > > 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. > > Yes, you need to call activate if the configuration changed. Normally > this doesn't happen so often. > > Do you change configuration of the workers frequently? > > > > > 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 ? > > I think the issue is that after a configuration change of the worker a > new instance is created. This also means a new instance of the > PKCS11CryptoToken (both the SignServer one and the CESeCore one it uses > internally). This means that we could not cache any KeyStore instance there. > > We have some open tickets for separating the worker and crypto token > which would mean that a worker could be changed and the crypto token > stay active: > https://jira.primekey.se/browse/DSS-716 > > > Regards, > Markus > > > > > 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> > > > > > > ------------------------------------------------------------------------------ > > Start Your Social Network Today - Download eXo Platform > > Build your Enterprise Intranet with eXo Platform Software > > Java Based Open Source Intranet - Social, Extensible, Cloud Ready > > Get Started Now And Turn Your Intranet Into A Collaboration Platform > > http://p.sf.net/sfu/ExoPlatform > > > > > > > > _______________________________________________ > > SignServer-develop mailing list > > Sig...@li... > > https://lists.sourceforge.net/lists/listinfo/signserver-develop > > > > > > -- > 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 > > |
