opensc-devel — discussion of developement of OpenSC and related projects

Re: [Opensc-devel] Typical smartcard response times

[<J.W...@mi...>]

Time pkcs11-tool –module (modulename) –O takes 6.6 seconds
Time pkcs11-tool –module (modulename) –O –l –pin xxxxxx takes 8,7 seconds
Internal readers (Alcor Mikro 9560) in some laptops ARE noticibly slower.

From: Marian Ďurkovič <md...@bt...>
Sent: Monday, February 10, 2020 3:46 PM
To: OpenSC Development <ope...@li...>
Subject: Re: [Opensc-devel] Typical smartcard response times

Tested on Linux with the same HW and here it works much better:

time pkcs11-tool -login -O

real    0m6.766s
user    0m0.064s
sys    0m0.012s

Time to complete PKCS#11 function only 72 msec (instead of 575 msec on MAC):

11: C_GetAttributeValue
2020-02-10 14:45:04.525

12: C_GetAttributeValue
2020-02-10 14:45:04.597

APDU times starting from 6 msec

OK, so it looks like MAC-specific problem...
Any debugging possibilities on MAC?

Thanks & kind regards,
MD


On Mon, 10 Feb 2020 09:10:38 +0100, Peter Popovec wrote
> Hi
>
> There is a way to determine exact timing of all operations .. (linux):
>
> 1. using OPENSC_DEBUG=255 -> exact timing of APDUs
>
> 2. using tcpdump to sniff USB traffic from/to reader (modprobe usbmon, tcpdump -i usbmon1 ....  )
>
> 3. Oscilloscope on reader pins ..
>
> questions:
> - how many APDUs are exchanged between card/reader (for pkcs11-tool -O... ) ?
> - average time for one APDU?
>
> - is there some of APDUs who wants to prolong the working time ?
> - algorithm in pkcs#11 library - is it efficient enough? i.e.  pkcs11 requests lot of operations / data transfers from card, even so result of these operations is not really needed.
>
> And another reason that can lead to slowdown of card operations ..  is the card accessed from exact one application ? (for example chrome/firefox may poll the card ... this can lead to deselect card or even  card reset that lead to new PPS exchange etc..)
>
> Peter
>
>
>
>
> On Mon, Feb 10, 2020 at 8:30 AM Marian Ďurkovič <md...@bt...<mailto:md...@bt...>> wrote:
>

>
> Hello,
>
>
> thanks for the results, if I run "time pkcs11-tool -login -p ..... -O" with Slovak eID on MAC, I get:
>
>
> Using slot 0 with a present token (0x1)
> Private Key Object; RSA
>   label:      Podpisovy kluc
>   ID:         11
>   Usage:      sign
>   Access:     always authenticate, sensitive, always sensitive, never extractable, local
>   Allowed mechanisms: RSA-PKCS
> Certificate Object; type = X.509 cert
>   label:      Certifikat k podpisovemu klucu
>   subject:   .....
>   ID:         11
>
>
>
>
> real    0m25.794s  (!)
> user    0m0.128s
> sys    0m0.059s
>



Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

Re: [Opensc-devel] Typical smartcard response times

[<md...@bt...>]

Tested on Linux with the same HW and here it works much better:

time pkcs11-tool -login -O

real    0m6.766s
user    0m0.064s
sys    0m0.012s

Time to complete PKCS#11 function only 72 msec (instead of 575 msec on MAC):

11: C_GetAttributeValue
2020-02-10 14:45:04.525

12: C_GetAttributeValue
2020-02-10 14:45:04.597

APDU times starting from 6 msec

OK, so it looks like MAC-specific problem...

Any debugging possibilities on MAC?

Thanks & kind regards,

MD

On Mon, 10 Feb 2020 09:10:38 +0100, Peter Popovec wrote

> Hi
> 
> There is a way to determine exact timing of all operations .. (linux):
> 
> 1. using OPENSC_DEBUG=255 -> exact timing of APDUs 
> 
> 2. using tcpdump to sniff USB traffic from/to reader (modprobe usbmon, tcpdump -i usbmon1 ....  )
> 
> 3. Oscilloscope on reader pins .. 
> 
> questions:
> - how many APDUs are exchanged between card/reader (for pkcs11-tool -O... ) ?
> - average time for one APDU?
> 
> - is there some of APDUs who wants to prolong the working time ?
> - algorithm in pkcs#11 library - is it efficient enough? i.e.  pkcs11 requests lot of operations / data transfers from card, even so result of these operations is not really needed. 
> 
> And another reason that can lead to slowdown of card operations ..  is the card accessed from exact one application ? (for example chrome/firefox may poll the card ... this can lead to deselect card or even  card reset that lead to new PPS exchange etc..)
> 
> Peter
> 
> 
> 
> 
> On Mon, Feb 10, 2020 at 8:30 AM Marian Ďurkovič <md...@bt...> wrote:
> 
> 
> Hello,
> 
> 
> thanks for the results, if I run "time pkcs11-tool -login -p ..... -O" with Slovak eID on MAC, I get:
> 
> 
> Using slot 0 with a present token (0x1)
> Private Key Object; RSA 
>   label:      Podpisovy kluc
>   ID:         11
>   Usage:      sign
>   Access:     always authenticate, sensitive, always sensitive, never extractable, local
>   Allowed mechanisms: RSA-PKCS
> Certificate Object; type = X.509 cert
>   label:      Certifikat k podpisovemu klucu
>   subject:   .....
>   ID:         11
> 
> 
> 
> 
> real    0m25.794s  (!)
> user    0m0.128s
> sys    0m0.059s
>

 

Re: [Opensc-devel] Typical smartcard response times

[<J.W...@mi...>]

for linux, there is also something else you can do:
Do an strace of the complete command (exporting a certificate, or signing some data) and write the result to file.
Ofcourse this is far slower than when working normally, but can disclose “some unexpected” behavior.

I noticed that our proprietary middleware is re-reading its own configuration file several thousand times. Very time consuming.

From: Peter Popovec <pop...@gm...>
Sent: Monday, February 10, 2020 9:11 AM
To: OpenSC Development <ope...@li...>
Subject: Re: [Opensc-devel] Typical smartcard response times

Hi


There is a way to determine exact timing of all operations .. (linux):

1. using OPENSC_DEBUG=255 -> exact timing of APDUs
2. using tcpdump to sniff USB traffic from/to reader (modprobe usbmon, tcpdump -i usbmon1 ....  )
3. Oscilloscope on reader pins ..

questions:
- how many APDUs are exchanged between card/reader (for pkcs11-tool -O... ) ?
- average time for one APDU?
- is there some of APDUs who wants to prolong the working time ?
- algorithm in pkcs#11 library - is it efficient enough? i.e.  pkcs11 requests lot of operations / data transfers from card, even so result of these operations is not really needed.

And another reason that can lead to slowdown of card operations ..  is the card accessed from exact one application ? (for example chrome/firefox may poll the card ... this can lead to deselect card or even  card reset that lead to new PPS exchange etc..)

Peter




On Mon, Feb 10, 2020 at 8:30 AM Marian Ďurkovič <md...@bt...<mailto:md...@bt...>> wrote:
Hello,

thanks for the results, if I run "time pkcs11-tool -login -p ..... -O" with Slovak eID on MAC, I get:

Using slot 0 with a present token (0x1)
Private Key Object; RSA
  label:      Podpisovy kluc
  ID:         11
  Usage:      sign
  Access:     always authenticate, sensitive, always sensitive, never extractable, local
  Allowed mechanisms: RSA-PKCS
Certificate Object; type = X.509 cert
  label:      Certifikat k podpisovemu klucu
  subject:   .....
  ID:         11

real    0m25.794s  (!)
user    0m0.128s
sys    0m0.059s


Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

Re: [Opensc-devel] Typical smartcard response times

[Peter P. <pop...@gm...>]

Hi


There is a way to determine exact timing of all operations .. (linux):

1. using OPENSC_DEBUG=255 -> exact timing of APDUs
2. using tcpdump to sniff USB traffic from/to reader (modprobe usbmon,
tcpdump -i usbmon1 ....  )
3. Oscilloscope on reader pins ..

questions:
- how many APDUs are exchanged between card/reader (fo*r pkcs11-tool -O...*
) ?
- average time for one APDU?
- is there some of APDUs who wants to prolong the working time ?
- algorithm in pkcs#11 library - is it efficient enough? i.e.  pkcs11
requests lot of operations / data transfers from card, even so result of
these operations is not really needed.

And another reason that can lead to slowdown of card operations ..  is the
card accessed from exact one application ? (for example chrome/firefox may
poll the card ... this can lead to deselect card or even  card reset that
lead to new PPS exchange etc..)

Peter




On Mon, Feb 10, 2020 at 8:30 AM Marian Ďurkovič <md...@bt...> wrote:

> *Hello,*
>
> *thanks for the results, if I run "time pkcs11-tool -login -p ..... -O"
> with Slovak eID on MAC, I get:*
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Using slot 0 with a present token (0x1) Private Key Object; RSA
> label:      Podpisovy kluc   ID:         11   Usage:      sign
> Access:     always authenticate, sensitive, always sensitive, never
> extractable, local   Allowed mechanisms: RSA-PKCS Certificate Object; type
> = X.509 cert   label:      Certifikat k podpisovemu klucu   subject:
> .....   ID:         11 *
>
>
>
> *real    0m25.794s  (!) user    0m0.128s sys    0m0.059s*
>
>

Re: [Opensc-devel] Typical smartcard response times

[<md...@bt...>]

Hello,

thanks for the results, if I run "time pkcs11-tool -login -p ..... -O" with Slovak eID on MAC, I get:

Using slot 0 with a present token (0x1)
Private Key Object; RSA 
  label:      Podpisovy kluc
  ID:         11
  Usage:      sign
  Access:     always authenticate, sensitive, always sensitive, never extractable, local
  Allowed mechanisms: RSA-PKCS
Certificate Object; type = X.509 cert
  label:      Certifikat k podpisovemu klucu
  subject:   .....
  ID:         11

real    0m25.794s  (!)
user    0m0.128s
sys    0m0.059s

and function calls follow like this:

10: C_GetAttributeValue
2020-02-10 08:24:59.048

11: C_GetAttributeValue
2020-02-10 08:24:59.626

12: C_GetAttributeValue
2020-02-10 08:25:00.202

13: C_GetAttributeValue
2020-02-10 08:25:00.777

The same happens also with official eID pkcs11 library...

With kind regards,

MD

On Mon, 10 Feb 2020 07:53:51 +0100, Peter Popovec wrote

> Hi,
> 
> Response time depends on card/reader, communication speed (card-reader) is not really important .... example for two readers, two cards:
> 
> Readers used for tests:
> 
> This reader run at 4.8MHz
> 
> $ opensc-tool -l 
> # Detected readers (pcsc)
> Nr.  Card  Features  Name
> 0    Yes             Gemalto PC Twin Reader (031048A2) 00 00
> 
> This reader run at 3.7MHz 
> 
> $ opensc-tool -l
> # Detected readers (pcsc)
> Nr.  Card  Features  Name
> 0    No              Alcor Micro AU9560 00 00
> 
> It can be expected that gemalto reader will be faster than alcor ..  (in ratio 4.8:3.7)  but please check results below....
> 
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
> ATR: 3B F5 96 00 00 81 31 FE 45 4D 79 45 49 44 14 
> 
> MyEID 4.0.1 at  250000 bits/s at 4 MHz, fMax for Fi = 5 MHz => 312500 bits/s
> 
> $ time pkcs11-tool -O
> Using slot 0 with a present token (0x0)
> Public Key Object; RSA 1024 bits
>   label:      1024
>   ID:         5ce20cc5323aae9fbc376c46e4b151bf63af049b
>   Usage:      encrypt, verify, wrap
>   Access:     none
> Public Key Object; EC  EC_POINT 256 bits
>   EC_POINT:   044104d9eefc471020c11fe2669e6fb53c64e8b77a1c0986a5006bced3a62348e4d0702faec486333e1bbd2cf4d9d6b04e74a6633f1fcafe74decea48ac2de58984059
>   EC_PARAMS:  06082a8648ce3d030107
>   label:      
>   ID:         ef5e53813f8cbafcc971fc4ad85824abce67f2da
>   Usage:      verify
>   Access:     none
> 
> // gemalto
> 
> real    0m2.490s
> user    0m0.008s
> sys     0m0.016s
> // alcor
> real    0m2.646s
> user    0m0.008s
> sys     0m0.012s
> 
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
> ATR: 3B F5 18 00 02 10 80 4F 73 45 49 44 
> 
> OsEID card, 129032 bits/s at 4 MHz, fMax for Fi = 5 MHz => 161290 bits/s
> 
>  $time pkcs11-tool -O
> Using slot 0 with a present token (0x0)
> Public Key Object; RSA 1024 bits
>   label:      key_1024
>   ID:         64f282187ba98229e1112c50e1aeb03f962a116d
>   Usage:      encrypt, verify, wrap
>   Access:     none
> Public Key Object; EC  EC_POINT 256 bits
>   EC_POINT:   044104219708c09cba1c64b0b93c531cdd4f14f3a8771363b5f8400fce5b29f6d8672bd3b14a8f2ed72498d4fbc3129c3e49ea55f6e8f97bf0117b57963df045013d75
>   EC_PARAMS:  06082a8648ce3d030107
>   label:      Private Key
>   ID:         c49daee3660e5c513a8e1ed9270375afb888025a
>   Usage:      verify
>   Access:     none
> 
> //gemalto
> 
> real    0m1.837s
> user    0m0.012s
> sys     0m0.016s
> // alcor
> 
> real    0m1.992s
> user    0m0.016s
> sys     0m0.008s
> 
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
> Another test, pkcs15-tool -D  (5 RSA keys on OsEID/MyEID 4.0.1) card took 1.9/2.8 sec... 
> 
> Peter
> 
> On Sun, Feb 9, 2020 at 10:25 AM Marian Ďurkovič <md...@bt...> wrote:
> Hi all,
> 
> during experiments with Slovak eID cards it became apparent, that every single operation takes > 500 msec.
> 
> When the eID is not inserted in USB reader, everything works quite fast:
> 
> time pkcs11-tool --module /Library/OpenSC/lib/pkcs11-spy.so -L
> Available slots:
> Slot 0 (0x0): Gemalto PC Twin Reader
>   (empty)
> 
> real    0m0.060s
> user    0m0.007s
> sys     0m0.009s
> 
> However, as soon as the eID is inserted, it changes significantly:
> 
> real    0m2.586s
> user    0m0.053s
> sys     0m0.046s
> 
> Spy library shows, that with inserted eID, every single operation (C_Initialize, C_GetSlotList, C_GetSlotInfo, C_GetTokenInfo) takes > 500 msec. The same happens with official drivers.
> 
> As a result, the whole procedure to e.g. pull a certificate from this eID takes about 7 seconds...
> 
> Is this expected behaviour? What are typical response times for other smartcards?
> 
> Thanks & kind regards,
> MD
> 
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

 

Re: [Opensc-devel] Typical smartcard response times

[Peter P. <pop...@gm...>]

Hi,

Response time depends on card/reader, communication speed (card-reader) is
not really important .... example for two readers, two cards:

Readers used for tests:

This reader run at 4.8MHz
$ opensc-tool -l
# Detected readers (pcsc)
Nr.  Card  Features  Name
0    Yes             Gemalto PC Twin Reader (031048A2) 00 00

This reader run at 3.7MHz
$ opensc-tool -l
# Detected readers (pcsc)
Nr.  Card  Features  Name
0    No              Alcor Micro AU9560 00 00

It can be expected that gemalto reader will be faster than alcor ..  (in
ratio 4.8:3.7)  but please check results below....
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ATR: 3B F5 96 00 00 81 31 FE 45 4D 79 45 49 44 14
MyEID 4.0.1 at  250000 bits/s at 4 MHz, fMax for Fi = 5 MHz => 312500 bits/s

$ time pkcs11-tool -O
Using slot 0 with a present token (0x0)
Public Key Object; RSA 1024 bits
  label:      1024
  ID:         5ce20cc5323aae9fbc376c46e4b151bf63af049b
  Usage:      encrypt, verify, wrap
  Access:     none
Public Key Object; EC  EC_POINT 256 bits
  EC_POINT:
044104d9eefc471020c11fe2669e6fb53c64e8b77a1c0986a5006bced3a62348e4d0702faec486333e1bbd2cf4d9d6b04e74a6633f1fcafe74decea48ac2de58984059
  EC_PARAMS:  06082a8648ce3d030107
  label:
  ID:         ef5e53813f8cbafcc971fc4ad85824abce67f2da
  Usage:      verify
  Access:     none
// gemalto
real    0m2.490s
user    0m0.008s
sys     0m0.016s
// alcor
real    0m2.646s
user    0m0.008s
sys     0m0.012s
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

ATR: 3B F5 18 00 02 10 80 4F 73 45 49 44
OsEID card, 129032 bits/s at 4 MHz, fMax for Fi = 5 MHz => 161290 bits/s

 $time pkcs11-tool -O
Using slot 0 with a present token (0x0)
Public Key Object; RSA 1024 bits
  label:      key_1024
  ID:         64f282187ba98229e1112c50e1aeb03f962a116d
  Usage:      encrypt, verify, wrap
  Access:     none
Public Key Object; EC  EC_POINT 256 bits
  EC_POINT:
044104219708c09cba1c64b0b93c531cdd4f14f3a8771363b5f8400fce5b29f6d8672bd3b14a8f2ed72498d4fbc3129c3e49ea55f6e8f97bf0117b57963df045013d75
  EC_PARAMS:  06082a8648ce3d030107
  label:      Private Key
  ID:         c49daee3660e5c513a8e1ed9270375afb888025a
  Usage:      verify
  Access:     none

//gemalto
real    0m1.837s
user    0m0.012s
sys     0m0.016s
// alcor
real    0m1.992s
user    0m0.016s
sys     0m0.008s

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Another test, pkcs15-tool -D  (5 RSA keys on OsEID/MyEID 4.0.1) card took
1.9/2.8 sec...


Peter

On Sun, Feb 9, 2020 at 10:25 AM Marian Ďurkovič <md...@bt...> wrote:

> Hi all,
>
> during experiments with Slovak eID cards it became apparent, that every
> single operation takes > 500 msec.
>
> When the eID is not inserted in USB reader, everything works quite fast:
>
> time pkcs11-tool --module /Library/OpenSC/lib/pkcs11-spy.so -L
> Available slots:
> Slot 0 (0x0): Gemalto PC Twin Reader
>   (empty)
>
> real    0m0.060s
> user    0m0.007s
> sys     0m0.009s
>
> However, as soon as the eID is inserted, it changes significantly:
>
> real    0m2.586s
> user    0m0.053s
> sys     0m0.046s
>
> Spy library shows, that with inserted eID, every single operation
> (C_Initialize, C_GetSlotList, C_GetSlotInfo, C_GetTokenInfo) takes > 500
> msec. The same happens with official drivers.
>
> As a result, the whole procedure to e.g. pull a certificate from this eID
> takes about 7 seconds...
>
> Is this expected behaviour? What are typical response times for other
> smartcards?
>
>
> Thanks & kind regards,
> MD
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

Re: [Opensc-devel] Typical smartcard response times

[Ludovic R. <lud...@gm...>]

Le dim. 9 févr. 2020 à 18:13, Marian Ďurkovič <md...@bt...> a écrit :
> Thanks for the info - yes, ATR is exactly as mentioned above.
>
> It's quite strange, since there is very little difference in response times for common functions regardless of result size:
> - C_GetAttributeValue for CKA_ID (i.e. just a few bytes) takes 571 msec
> - C_GetAttributeValue for CKA_VALUE (2048 bytes certificate) takes 580 msec
> - C_FindObjectsInit+C_FindObjects also takes 576 msec

This indicates that the card/reader communication speed is not that important.

> Any tips what to look for (on MAC)?

I would have suggested to use PCSC API spy to get some timing information
https://ludovicrousseau.blogspot.com/2011/11/pcsc-api-spy-third-try.html

But that will not work on macOS.

> The above is a serious problem with some applications - for example signing a document in Acrobat results in 2.5 minutes of waiting, since after C_Sign completes, Acrobat tries to verify the signature and pulls all 3 certificates from eID 6 times (once for each level in certification hierarchy).
>
> Perhaps I should try to modify pkcs11-spy.so into a caching library, serving repeated requests for static objects from memory cache and not from slow eID card...

You can use pkcs11-spy to know what functions are used.
Maybe pkcs11-spy could be updated to include the *duration* of each
PKCS#11 call so it is possible/easy to identify the slow functions.

Have you tried to play with the "use_file_caching = " parameter of
OpenSC in /usr/local/etc/opensc.conf ?
See opensc.conf manpage.

Bye

-- 
 Dr. Ludovic Rousseau

Re: [Opensc-devel] Typical smartcard response times

[<md...@bt...>]

On Sun, 9 Feb 2020 15:33:36 +0100, Ludovic Rousseau wrote
> Le dim. 9 févr. 2020 à 14:32, Pali Rohár <pal...@gm...> a 
> écrit :
> >
> > On Sunday 09 February 2020 13:53:46 Ludovic Rousseau wrote:
> > > Le dim. 9 févr. 2020 à 10:25, Marian Ďurkovič <md...@bt...> a écrit :
> 
> > > > Is this expected behaviour? What are typical response times for other smartcards?
> > >
> > > The speed depends on many factors. One of them is the speed between
> > > the card and the reader.
> > > Some cards are faster than others.
> > > Some readers are faster than others.
> > >
> > > What is the ATR of your cards?
> >
> > Hello!
> >
> > In OpenSC project on github is already an open issue for Slovak eID
> > cards: https://github.com/OpenSC/OpenSC/issues/208
> >
> > There is also posted ATR of a card.
> 
> ATR from the github issue is 3B DF 18 00 81 31 FE 58 00 31 B9 64 05 0E
> 01 00 73 B4 01 D3 00 00 00 22
> https://smartcard-atr.apdu.fr/parse?ATR=3BDF18008131FE580031B964050E010073B401D300000022
> 
> So a TA1 of 0x18
> https://ludovicrousseau.blogspot.com/2016/04/atr-statistics-ta1-global-
> encodes-fi.html Fi=372, Di=12, 31 cycles/ETU (129032 bits/s at 4.00 
> MHz, 161290 bits/s for fMax=5 MHz)
> 
> 129032 bits/s s not terribly fast.
> The reader you use, Gemalto PC Twin Reader, can do dwMaxDataRate: 
> 344086 bps https://ccid.apdu.fr/ccid/readers/GemPCTwin.txt
> 
> My next point is the card processing speed. Maybe the card OS and
> application is slow.
> 
> Or maybe OpenSC (and the official driver) is sub-optimal.
> But that is a lot of work to work on that.

Thanks for the info - yes, ATR is exactly as mentioned above.

It's quite strange, since there is very little difference in response times for common functions regardless of result size:
- C_GetAttributeValue for CKA_ID (i.e. just a few bytes) takes 571 msec
- C_GetAttributeValue for CKA_VALUE (2048 bytes certificate) takes 580 msec
- C_FindObjectsInit+C_FindObjects also takes 576 msec

Any tips what to look for (on MAC)?

The above is a serious problem with some applications - for example signing a document in Acrobat results in 2.5 minutes of waiting, since after C_Sign completes, Acrobat tries to verify the signature and pulls all 3 certificates from eID 6 times (once for each level in certification hierarchy).

Perhaps I should try to modify pkcs11-spy.so into a caching library, serving repeated requests for static objects from memory cache and not from slow eID card...


Thanks & kind regards,
MD

Re: [Opensc-devel] Typical smartcard response times

[Ludovic R. <lud...@gm...>]

Le dim. 9 févr. 2020 à 14:32, Pali Rohár <pal...@gm...> a écrit :
>
> On Sunday 09 February 2020 13:53:46 Ludovic Rousseau wrote:
> > Le dim. 9 févr. 2020 à 10:25, Marian Ďurkovič <md...@bt...> a écrit :

> > > Is this expected behaviour? What are typical response times for other smartcards?
> >
> > The speed depends on many factors. One of them is the speed between
> > the card and the reader.
> > Some cards are faster than others.
> > Some readers are faster than others.
> >
> > What is the ATR of your cards?
>
> Hello!
>
> In OpenSC project on github is already an open issue for Slovak eID
> cards: https://github.com/OpenSC/OpenSC/issues/208
>
> There is also posted ATR of a card.

ATR from the github issue is 3B DF 18 00 81 31 FE 58 00 31 B9 64 05 0E
01 00 73 B4 01 D3 00 00 00 22
https://smartcard-atr.apdu.fr/parse?ATR=3BDF18008131FE580031B964050E010073B401D300000022

So a TA1 of 0x18
https://ludovicrousseau.blogspot.com/2016/04/atr-statistics-ta1-global-encodes-fi.html
Fi=372, Di=12, 31 cycles/ETU (129032 bits/s at 4.00 MHz, 161290 bits/s
for fMax=5 MHz)

129032 bits/s s not terribly fast.
The reader you use, Gemalto PC Twin Reader, can do dwMaxDataRate: 344086 bps
https://ccid.apdu.fr/ccid/readers/GemPCTwin.txt

My next point is the card processing speed. Maybe the card OS and
application is slow.

Or maybe OpenSC (and the official driver) is sub-optimal.
But that is a lot of work to work on that.

Bye

--
 Dr. Ludovic Rousseau

Re: [Opensc-devel] Typical smartcard response times

[Pali R. <pal...@gm...>]

On Sunday 09 February 2020 13:53:46 Ludovic Rousseau wrote:
> Le dim. 9 févr. 2020 à 10:25, Marian Ďurkovič <md...@bt...> a écrit :
> >
> > Hi all,
> 
> Hello,
> 
> > during experiments with Slovak eID cards it became apparent, that every single operation takes > 500 msec.
> >
> > When the eID is not inserted in USB reader, everything works quite fast:
> >
> > time pkcs11-tool --module /Library/OpenSC/lib/pkcs11-spy.so -L
> > Available slots:
> > Slot 0 (0x0): Gemalto PC Twin Reader
> >   (empty)
> >
> > real    0m0.060s
> > user    0m0.007s
> > sys     0m0.009s
> >
> > However, as soon as the eID is inserted, it changes significantly:
> >
> > real    0m2.586s
> > user    0m0.053s
> > sys     0m0.046s
> >
> > Spy library shows, that with inserted eID, every single operation (C_Initialize, C_GetSlotList, C_GetSlotInfo, C_GetTokenInfo) takes > 500 msec. The same happens with official drivers.
> >
> > As a result, the whole procedure to e.g. pull a certificate from this eID takes about 7 seconds...
> >
> > Is this expected behaviour? What are typical response times for other smartcards?
> 
> The speed depends on many factors. One of them is the speed between
> the card and the reader.
> Some cards are faster than others.
> Some readers are faster than others.
> 
> What is the ATR of your cards?

Hello!

In OpenSC project on github is already an open issue for Slovak eID
cards: https://github.com/OpenSC/OpenSC/issues/208

There is also posted ATR of a card.

-- 
Pali Rohár
pal...@gm...

Re: [Opensc-devel] Typical smartcard response times

[Ludovic R. <lud...@gm...>]

Le dim. 9 févr. 2020 à 10:25, Marian Ďurkovič <md...@bt...> a écrit :
>
> Hi all,

Hello,

> during experiments with Slovak eID cards it became apparent, that every single operation takes > 500 msec.
>
> When the eID is not inserted in USB reader, everything works quite fast:
>
> time pkcs11-tool --module /Library/OpenSC/lib/pkcs11-spy.so -L
> Available slots:
> Slot 0 (0x0): Gemalto PC Twin Reader
>   (empty)
>
> real    0m0.060s
> user    0m0.007s
> sys     0m0.009s
>
> However, as soon as the eID is inserted, it changes significantly:
>
> real    0m2.586s
> user    0m0.053s
> sys     0m0.046s
>
> Spy library shows, that with inserted eID, every single operation (C_Initialize, C_GetSlotList, C_GetSlotInfo, C_GetTokenInfo) takes > 500 msec. The same happens with official drivers.
>
> As a result, the whole procedure to e.g. pull a certificate from this eID takes about 7 seconds...
>
> Is this expected behaviour? What are typical response times for other smartcards?

The speed depends on many factors. One of them is the speed between
the card and the reader.
Some cards are faster than others.
Some readers are faster than others.

What is the ATR of your cards?

Bye

-- 
 Dr. Ludovic Rousseau

[Opensc-devel] Typical smartcard response times

[<md...@bt...>]

Hi all,

during experiments with Slovak eID cards it became apparent, that every single operation takes > 500 msec.

When the eID is not inserted in USB reader, everything works quite fast:

time pkcs11-tool --module /Library/OpenSC/lib/pkcs11-spy.so -L
Available slots:
Slot 0 (0x0): Gemalto PC Twin Reader
  (empty)

real	0m0.060s
user	0m0.007s
sys	0m0.009s

However, as soon as the eID is inserted, it changes significantly:

real	0m2.586s
user	0m0.053s
sys	0m0.046s

Spy library shows, that with inserted eID, every single operation (C_Initialize, C_GetSlotList, C_GetSlotInfo, C_GetTokenInfo) takes > 500 msec. The same happens with official drivers.

As a result, the whole procedure to e.g. pull a certificate from this eID takes about 7 seconds...

Is this expected behaviour? What are typical response times for other smartcards?


Thanks & kind regards,
MD

Re: [Opensc-devel] pkcs15-init --store-certificate: Failed to store certificate: Non unique object ID

[Jakub J. <jj...@re...>]

On Wed, 2020-01-29 at 12:39 +0200, Graham Leggett wrote:
> > On 29 Jan 2020, at 11:00, Jakub Jelen <jj...@re...> wrote:
> > 
> > On Wed, 2020-01-29 at 10:05 +0200, Graham Leggett wrote:
> > > Hi all,
> > > 
> > > When an attempt is made to load a renewed certificate onto a
> > > properly
> > > formatted and otherwise working smartcard as follows, the error
> > > "Non
> > > unique object ID" is returned as follows:
> > > 
> > > [root@gatekeeper ~]# pkcs15-init --store-certificate john.cer --
> > > label 
> > > "John Smith (Globalsign)" --auth-id 01
> > > Using reader with a card: ACS ACR 38U-CCID 00 00
> > > Failed to store certificate: Non unique object ID
> > > 
> > > Can someone explain what this error is trying to tell me?
> > 
> > You are trying to write an object with the same ID that already
> > exists.
> 
> Can you explain further what this ID is? Is this something embedded
> in the new certificate, or is this something on the smartcard?

It is concept of the smart card. But there is a way to derive it from
the public key if you need to. See the manual page for pkcs15-init, the
--id switch describes this.

> > > What is an “object ID” when it comes to a certificate?
> > 
> > Object ID is a ID used to pair public, private and certificate
> > objects
> > in PKCS#11 layer and I believe also in PKCS#15 layer.
> 
> How do I set this ID, or control it?

pkcs15-init --id switch should do it.

Regards,
-- 
Jakub Jelen
Senior Software Engineer
Security Technologies
Red Hat, Inc.

Re: [Opensc-devel] pkcs15-init --store-certificate: Failed to store certificate: Non unique object ID

[Graham L. <mi...@sh...>]

> On 29 Jan 2020, at 11:00, Jakub Jelen <jj...@re...> wrote:
> 
> On Wed, 2020-01-29 at 10:05 +0200, Graham Leggett wrote:
>> Hi all,
>> 
>> When an attempt is made to load a renewed certificate onto a properly
>> formatted and otherwise working smartcard as follows, the error "Non
>> unique object ID" is returned as follows:
>> 
>> [root@gatekeeper ~]# pkcs15-init --store-certificate john.cer --label 
>> "John Smith (Globalsign)" --auth-id 01
>> Using reader with a card: ACS ACR 38U-CCID 00 00
>> Failed to store certificate: Non unique object ID
>> 
>> Can someone explain what this error is trying to tell me?
> 
> You are trying to write an object with the same ID that already exists.

Can you explain further what this ID is? Is this something embedded in the new certificate, or is this something on the smartcard?

>> What is an “object ID” when it comes to a certificate?
> 
> Object ID is a ID used to pair public, private and certificate objects
> in PKCS#11 layer and I believe also in PKCS#15 layer.

How do I set this ID, or control it?

Which attribute of the certificate is treated as the “id”?

>> There is a previous certificate on the same smartcard that is being
>> renewed, does this previous certificate need to be removed before the
>> replacement is added?
> 
> Probably yes. Certainly it should not have the same ID as the new one.
> In that case, the applications would not know which of the certificates
> to use easily before parsing the whole blob.

Is the ID the subject? Fingerprint? Something else?

Regards,
Graham
—

Re: [Opensc-devel] pkcs15-init --store-certificate: Failed to store certificate: Non unique object ID

[Jakub J. <jj...@re...>]

On Wed, 2020-01-29 at 10:05 +0200, Graham Leggett wrote:
> Hi all,
> 
> When an attempt is made to load a renewed certificate onto a properly
> formatted and otherwise working smartcard as follows, the error "Non
> unique object ID" is returned as follows:
> 
> [root@gatekeeper ~]# pkcs15-init --store-certificate john.cer --label 
> "John Smith (Globalsign)" --auth-id 01
> Using reader with a card: ACS ACR 38U-CCID 00 00
> Failed to store certificate: Non unique object ID
> 
> Can someone explain what this error is trying to tell me?

You are trying to write an object with the same ID that already exists.

> What is an “object ID” when it comes to a certificate?

Object ID is a ID used to pair public, private and certificate objects
in PKCS#11 layer and I believe also in PKCS#15 layer.

> There is a previous certificate on the same smartcard that is being
> renewed, does this previous certificate need to be removed before the
> replacement is added?

Probably yes. Certainly it should not have the same ID as the new one.
In that case, the applications would not know which of the certificates
to use easily before parsing the whole blob.

Regards,
-- 
Jakub Jelen
Senior Software Engineer
Security Technologies
Red Hat, Inc.

[Opensc-devel] pkcs15-init --store-certificate: Failed to store certificate: Non unique object ID

[Graham L. <mi...@sh...>]

Hi all,

When an attempt is made to load a renewed certificate onto a properly formatted and otherwise working smartcard as follows, the error "Non unique object ID" is returned as follows:

[root@gatekeeper ~]# pkcs15-init --store-certificate john.cer --label "John Smith (Globalsign)" --auth-id 01
Using reader with a card: ACS ACR 38U-CCID 00 00
Failed to store certificate: Non unique object ID

Can someone explain what this error is trying to tell me?

What is an “object ID” when it comes to a certificate?

There is a previous certificate on the same smartcard that is being renewed, does this previous certificate need to be removed before the replacement is added?

Regards,
Graham
—

Re: [Opensc-devel] New release of pkcs11-helper?

[Alon Bar-L. <alo...@gm...>]

On Mon, Jan 20, 2020 at 10:52 PM John Ottander <joh...@gm...> wrote:
>
> Any plans for a new release of pkcs11-helper?
>
> The git master contains commit c192bb related to padding from last April which fixes configurations of openvpn with openssl 1.1.1 and a smartcard. It used to work with openssl 1.0, but that release is end of life as of the end of 2019.
>
> The error I got with openvpn which was fixed by using master of pkcs11-helper:

Sure[1]

[1] https://github.com/OpenSC/pkcs11-helper/releases/tag/pkcs11-helper-1.26

Re: [Opensc-devel] libp11 release

[Michał T. <Mic...@st...>]

On 1/21/20 5:57 PM, Ludovic Rousseau wrote:
> The best would be to discuss with Michał Trojnara (in Cc:) who is the
> current maintainer of libp11.

I intend to release libp11 0.4.11 before the end of January.

Best regards,
    Mike

Re: [Opensc-devel] libp11 release

[Ludovic R. <lud...@gm...>]

Le mar. 21 janv. 2020 à 16:47, Ondřej Surý <on...@su...> a écrit :
>
> Hi Ludovic,
>
> thanks for the offer.
>
> I could help with the release engineering in case, but it requires couple of things:
>
> 1. what is the current procedure to release new version
> 2. is there a plan for the next version? milestone? anything? how do you know that the release is complete?
> 3. is there an overall plan?

No idea.
I do not use libp11 myself. But I am admin of the github project.

The best would be to discuss with Michał Trojnara (in Cc:) who is the
current maintainer of libp11.

Bye

-- 
 Dr. Ludovic Rousseau

Re: [Opensc-devel] libp11 release

[Ondřej S. <on...@su...>]

Hi Ludovic,

thanks for the offer.

I could help with the release engineering in case, but it requires couple of things:

1. what is the current procedure to release new version
2. is there a plan for the next version? milestone? anything? how do you know that the release is complete?
3. is there an overall plan?

I do have a couple of real HSMs available for testing, and I am going to refactor BIND 9 to solely use engine_pkcs11 in the next development version, so most probably I will have some feedback, but I am not sure if I can be a real asset given my general lack of free time, but I would be happy to help since this is one of the projects BIND 9 will rely on.

Ondrej
--
Ondřej Surý
on...@su...



> On 21 Jan 2020, at 15:28, Ludovic Rousseau <lud...@gm...> wrote:
> 
> Le mar. 21 janv. 2020 à 15:09, Ondřej Surý <on...@su...> a écrit :
>> 
>> Hi,
> 
> Hello Ondrej,
> 
>> the master branch contains couple of PRs that are needed for BIND 9 integration with PKCS#11 and it would be nice to be able to recommend people a released version of libp11 instead of master branch. Is there any ETA? Can I help somehow? I understand we are all swamped with work, so no pressure implied. Thanks for all the work.
> 
> I can add you to the libp11 maintainer team if you want.
> Unless someone objects.
> 
> Bye,
> 
> -- 
> Dr. Ludovic Rousseau

Re: [Opensc-devel] libp11 release

[Ludovic R. <lud...@gm...>]

Le mar. 21 janv. 2020 à 15:09, Ondřej Surý <on...@su...> a écrit :
>
> Hi,

Hello Ondrej,

> the master branch contains couple of PRs that are needed for BIND 9 integration with PKCS#11 and it would be nice to be able to recommend people a released version of libp11 instead of master branch. Is there any ETA? Can I help somehow? I understand we are all swamped with work, so no pressure implied. Thanks for all the work.

I can add you to the libp11 maintainer team if you want.
Unless someone objects.

Bye,

-- 
 Dr. Ludovic Rousseau

[Opensc-devel] libp11 release

[Ondřej S. <on...@su...>]

Hi,

the master branch contains couple of PRs that are needed for BIND 9 integration with PKCS#11 and it would be nice to be able to recommend people a released version of libp11 instead of master branch. Is there any ETA? Can I help somehow? I understand we are all swamped with work, so no pressure implied. Thanks for all the work.

Thanks,
Ondrej
--
Ondřej Surý <on...@su...>

[Opensc-devel] New release of pkcs11-helper?

[John O. <joh...@gm...>]

Any plans for a new release of pkcs11-helper?

The git master contains commit c192bb related to padding from last April
which fixes configurations of openvpn with openssl 1.1.1 and a smartcard.
It used to work with openssl 1.0, but that release is end of life as of the
end of 2019.

The error I got with openvpn which was fixed by using master of
pkcs11-helper:

...

Sun Jan 12 16:57:44 2020 OpenVPN 2.4.8 x86_64-apple-darwin18.7.0 [SSL
(OpenSSL)] [LZO]

[LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on Nov  1 2019

Sun Jan 12 16:57:44 2020 library versions: OpenSSL 1.1.1d  10 Sep 2019, LZO
2.10
...

Sun Jan 12 16:57:47 2020 OpenSSL: error:141F0006:SSL
routines:tls_construct_cert_verify:EVP lib

Sun Jan 12 16:57:47 2020 TLS_ERROR: BIO read tls_read_plaintext error

Sun Jan 12 16:57:47 2020 TLS Error: TLS object -> incoming plaintext read
error

Sun Jan 12 16:57:47 2020 TLS Error: TLS handshake failed

Sun Jan 12 16:57:47 2020 SIGUSR1[soft,tls-error] received, process
restarting

[Opensc-devel] OpenSC 0.20.0 released

[Frank M. <fra...@gm...>]

Hi all!

I'm happy to finally announce the new release 0.20.0 of OpenSC. You can
read a full summary of the changes and get the release binaries on GitHub
<https://github.com/OpenSC/OpenSC/releases/tag/0.20.0>.

We've extended our continuous testing by fuzzing the code with OSS-Fuzz
<https://google.github.io/oss-fuzz>. It is running billions of tests each
weak and has found around 100 unique crashes, most notable the security
issues tracked as CVE-2019-6502, CVE-2019-15946, CVE-2019-15945,
CVE-2019-19480, CVE-2019-19481 and CVE-2019-19479. Getting our hands on all
the problems reported by the fuzzing was very challenging. Special thanks
to Jakub Jelen, who spend many hours on analyzing and fixing many of the
issues.

Regards,
Frank Morgner.

[Opensc-devel] Locking com.apple.ctkpcscd to a specific reader

[Dirk-Willem v. G. <di...@we...>]

com.apple.ctkpcscd keeps stealing the pcsc connection to a smart card reader -- leading to a sharing violation (e.g. when manipulating the card).

Does anyone know a way of locking com.apple.ctkpcscd to a specific port or reader ? So it ignores the other readers ?

DW.