Menu
▾
▴
signserver-develop
|
From: Antoine L. <ant...@yo...> - 2014-03-18 03:00:05
|
Hi everyone, Is there a way not to create a new instance of the pkcs11 builder for each signing with a HSM ? In this way, it takes a lot of time (20 seconds) with 300 pairs of keys just to load the keystore... Thanks for your help ! Antoine |
|
From: Markus K. <ma...@pr...> - 2014-03-18 07:54:37
|
Hi Antoine, In my mind that is not how it works. Can you give some more details in how you observe this and what signer you are using? BR, Markus On 2014-03-18 01:30, Antoine Louiset wrote: > Hi everyone, > > Is there a way not to create a new instance of the pkcs11 builder for > each signing with a HSM ? > > In this way, it takes a lot of time (20 seconds) with 300 pairs of keys > just to load the keystore... > > Thanks for your help ! > > > > Antoine > > > ------------------------------------------------------------------------------ > 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 > |
|
From: Antoine L. <ant...@yo...> - 2014-03-18 08:41:02
|
Hi Markus, Thanks for your answer. I use signserver 3.2.4 with a PDF Signer. I make some tests and I see that the getKeystore() is very long. You are right, this is not exactly how it works. I made some changes to call the getKeystore() method because the private key changes for every signing. I see that in the new version of signserver, you use the cesecore library. Maybe there is an optimization for that ? Have a nice day ! Antoine Le 18/03/2014 08:54, Markus Kilås a écrit : > Hi Antoine, > In my mind that is not how it works. > Can you give some more details in how you observe this and what signer > you are using? > > > BR, > Markus > > > > On 2014-03-18 01:30, Antoine Louiset wrote: >> Hi everyone, >> >> Is there a way not to create a new instance of the pkcs11 builder for >> each signing with a HSM ? >> >> In this way, it takes a lot of time (20 seconds) with 300 pairs of keys >> just to load the keystore... >> >> Thanks for your help ! >> >> >> >> Antoine >> >> >> ------------------------------------------------------------------------------ >> 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 |
|
From: Markus K. <ma...@pr...> - 2014-03-18 09:09:57
|
On 2014-03-18 09:32, Antoine Louiset wrote: > Hi Markus, > > Thanks for your answer. I use signserver 3.2.4 with a PDF Signer. I make > some tests and I see that the getKeystore() is very long. > > You are right, this is not exactly how it works. I made some changes to > call the getKeystore() method because the private key changes for every > signing. I see. Normally the worker only calls getPrivateKey() before performing the signing. The getKeystore() method is only used for other operations such as key generation or listing keys etc. Those operations are normally not on the "fast path". This is probably why we haven't experienced any performance problem. > > I see that in the new version of signserver, you use the cesecore > library. Maybe there is an optimization for that ? 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. Best regards, Markus > > Have a nice day ! > > > Antoine > > Le 18/03/2014 08:54, Markus Kilås a écrit : >> Hi Antoine, >> In my mind that is not how it works. >> Can you give some more details in how you observe this and what signer >> you are using? >> >> >> BR, >> Markus >> >> >> >> On 2014-03-18 01:30, Antoine Louiset wrote: >>> Hi everyone, >>> >>> Is there a way not to create a new instance of the pkcs11 builder for >>> each signing with a HSM ? >>> >>> In this way, it takes a lot of time (20 seconds) with 300 pairs of keys >>> just to load the keystore... >>> >>> Thanks for your help ! >>> >>> >>> >>> Antoine >>> >>> >>> ------------------------------------------------------------------------------ >>> 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 > |
|
From: Antoine L. <ant...@yo...> - 2014-03-18 11:10:59
|
Thanks a lot Markus !! See you Antoine Le 18/03/2014 10:09, Markus Kilås a écrit : > 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. |
|
From: Luis M. <lm...@ro...> - 2014-03-18 13:10:56
|
Em 18/03/2014 09:10, "Markus Kilås" <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... Maybe casting the pkcs11 provider to authprovider and calling the method logout() will produce the desired result if the underlying implementation honors the session invalidation (some pkcs11 middleware is buggy). You won't need to instantiate a new keystore then. |
|
From: Markus K. <ma...@pr...> - 2014-03-18 14:35:52
|
On 2014-03-18 14:10, Luis Maia wrote: > > Em 18/03/2014 09:10, "Markus Kilås" <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? // Markus > > Maybe casting the pkcs11 provider to authprovider and calling the method > logout() will produce the desired result if the underlying > implementation honors the session invalidation (some pkcs11 middleware > is buggy). > > You won't need to instantiate a new keystore then. > -- 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 |
|
From: Markus K. <ma...@pr...> - 2014-03-19 08:33:36
|
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 |
|
From: Tomas G. <to...@pr...> - 2014-03-19 09:04:08
|
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. >> >> >> >> > > > |
|
From: Luis M. <lui...@gm...> - 2014-03-19 15:45:54
|
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 |
|
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 |
|
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> |
|
From: Markus K. <ma...@pr...> - 2014-04-28 07:18:39
|
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 |
Thanks for helping keep SourceForge clean.
X