epass2003 RSA/2048 Failed to Generate Key on OSX, VirtualBOX

[rvalle]

Hi!
I am having trouble generating RSA 2048 keys on epass2003.
I get:

./pkcs15-init --auth-id 1 --generate-key rsa/2048 --key-usage sign,decrypt --label "MyRSAKey"
Using reader with a card: Feitian ePass2003 00 00
Failed to generate key: Transmit failed

The problem does not seem to happen when generating an RSA/1024 key

I am testing by building the tag: 0.14.0 and the HEAD
I have tried to include also configure with --enable-sm

Any idea what could be about?

[dengert]

On 10/16/2014 6:48 AM, Rafael wrote:

Hi!
I am having trouble generating RSA 2048 keys on epass2003.
I get:

|./pkcs15-init --auth-id 1 --generate-key rsa/2048 --key-usage sign,decrypt --label "MyRSAKey"
Using reader with a card: Feitian ePass2003 00 00
Failed to generate key: Transmit failed
|

The problem does not seem to happen when generating an RSA/1024 key

I am testing by building the tag: 1.4.0 and the HEAD
I have tried to include also configure with --enable-sm

Any idea what could be about?

A opensc debug trace would help.

This suggests that you must us the --pin option.
http://www.gooze.eu/howto/smartcard-quickstarter-guide/scenario-3-creating-a-self-signed-certificate-using-embedded

Could be related to:
#294

What system?
What version of pcsc-lite?

—
Reply to this email directly or view it on GitHub #301.

Douglas E. Engert DEEngert@gmail.com

[rvalle]

Ok,

To make things easier I downloaded and built the latest versions of the following modules:

OpenSC 0.14.0
ccid-1.4.18
pcsc-lite-1.8.12

you can find the trace here:

http://pastebin.com/nqZV9vZ2

hope that it helps,
Rafael

[dengert]

On 10/18/2014 2:33 AM, Rafael wrote:

Ok,

To make things easier I downloaded and built the latest versions of the following modules:

|OpenSC 0.14.0
ccid-1.4.18
pcsc-lite-1.8.12
|

you can find the trace here:

http://pastebin.com/nqZV9vZ2

line 1653 has:
0xb72bc6c0 09:22:33.669 [pkcs15-init] reader-pcsc.c:182:pcsc_internal_transmit: called
0xb72bc6c0 09:22:36.737 [pkcs15-init] reader-pcsc.c:208:pcsc_internal_transmit: Feitian ePass2003 00 00:SCardTransmit/Control failed: 0x80100016

http://blog.gmane.org/gmane.comp.lib.muscle/month=20120901
implies that this may be in the "ccid.readTimeout which has DEFAULT_COM_READ_TIMEOUT value (2s)."
(The timeout maybe different now.)

A 2048 key gen may take longer then expected. The time stamps indicate 3.068 second delay.

ON my virtual Ubuntu system running under Virtual box on W7, I can generate a 2048 kwt on a Feitian ePass2003 using:
pcsc-lite-1.8.10-1ubuntu1
libccid-1.4.15-1

0x7ffaf1ee4740 13:41:47.857 [pkcs15-init] ../../../src/src/libopensc/reader-pcsc.c:182:pcsc_internal_transmit: called
0x7ffaf1ee4740 13:41:50.421 [pkcs15-init] ../../../src/src/libopensc/apdu.c:185:sc_apdu_log:
Incoming APDU data [ 16 bytes] =====================================

99 02 90 00 8E 08 9B 8D 19 B6 62 8F EE 3C 90 00 ..........b..<..

which is 2.564 seconds, but it read in the response.

So this may be a timing problem, that is covered up by Virtual Box on my system.

A pcscd debug would be the next place to look.

hope that it helps,
Rafael

—
Reply to this email directly or view it on GitHub #301 (comment).

Douglas E. Engert DEEngert@gmail.com

[dengert]

Looking closer, I don't see where you verified the PIN.

What is the command line you used?

What is the profile you are using?

Is your card out of memory?

On 10/18/2014 8:09 AM, Douglas E Engert wrote:

On 10/18/2014 2:33 AM, Rafael wrote:

Ok,

To make things easier I downloaded and built the latest versions of the following modules:

|OpenSC 0.14.0
ccid-1.4.18
pcsc-lite-1.8.12
|

you can find the trace here:

http://pastebin.com/nqZV9vZ2

line 1653 has:
0xb72bc6c0 09:22:33.669 [pkcs15-init] reader-pcsc.c:182:pcsc_internal_transmit: called
0xb72bc6c0 09:22:36.737 [pkcs15-init] reader-pcsc.c:208:pcsc_internal_transmit: Feitian ePass2003 00 00:SCardTransmit/Control failed: 0x80100016

http://blog.gmane.org/gmane.comp.lib.muscle/month=20120901
implies that this may be in the "ccid.readTimeout which has DEFAULT_COM_READ_TIMEOUT value (2s)."
(The timeout maybe different now.)

A 2048 key gen may take longer then expected. The time stamps indicate 3.068 second delay.

ON my virtual Ubuntu system running under Virtual box on W7, I can generate a 2048 kwt on a Feitian ePass2003 using:
pcsc-lite-1.8.10-1ubuntu1
libccid-1.4.15-1

0x7ffaf1ee4740 13:41:47.857 [pkcs15-init] ../../../src/src/libopensc/reader-pcsc.c:182:pcsc_internal_transmit: called
0x7ffaf1ee4740 13:41:50.421 [pkcs15-init] ../../../src/src/libopensc/apdu.c:185:sc_apdu_log:
Incoming APDU data [ 16 bytes] =====================================

99 02 90 00 8E 08 9B 8D 19 B6 62 8F EE 3C 90 00 ..........b..<..

which is 2.564 seconds, but it read in the response.

So this may be a timing problem, that is covered up by Virtual Box on my system.

A pcscd debug would be the next place to look.

hope that it helps,
Rafael

—
Reply to this email directly or view it on GitHub #301 (comment).

Douglas E. Engert DEEngert@gmail.com

[LudovicRousseau]

@rvalle, generate a pcscd log as described in http://pcsclite.alioth.debian.org/ccid.html#support

[rvalle]

pcsc timeout sounds like possible cause to me.

I can consistently generate 1024 bit keys, and 2048 consistently fail.

for the same reason I don't think the PIN should be the problem.

I am runing on a macbookpro OSX/debian 7 under virtual box.

Will try capturing those logs.
R.

[rvalle]

Actually, the communication with the token is far from great.

many times pkcs15-tool reports token not found, and I have to re-insert several times until it is finally detected (I dont know up to which point this is normal / the software is stable).

here you can find the requested logs:

http://pastebin.com/wGTdX4GF

the command used for generating the key and its output is:

 pkcs15-init --auth-id 1 --generate-key rsa/2048 --use-default-transport-key --key-usage sign,decrypt --label "TestRootKey"
Using reader with a card: Feitian ePass2003 00 00
Failed to generate key: Transmit failed

thanks!
R.

[LudovicRousseau]

The command at line 804 is taking around 10 seconds and you can see the time requests sent by the reader:

01102953 <- 000000 80 00 00 00 00 00 43 80 03 00
00000042 commands.c:1519:CCID_Receive() Time extension requested: 0x03
00000010 commands.c:1525:CCID_Receive() New timeout: 9000 ms

Then the next APDU is sent and the reader do not replay before the driver timout of 3000 ms. So we get a:

03061708 ccid_usb.c:798:ReadUSB() read failed (2/6): -7 Invalid argument

-7 is LIBUSB_ERROR_TIMEOUT

After looking in the CCID driver I note that the timout of 3000 ms is the default timeout and is not calculated from the card ATR. The calculated timeout would be 94930 ms so much more than 3000 ms.

Can you edit the file ccid/src/defs.h and change the definition of DEFAULT_COM_READ_TIMEOUT to something like 100_1000 instead of 3_1000?
Then rebuild and reinstall the CCID driver. And redo your test.

[rvalle]

I did the test, and it is still failing.
It takes much longer to fail. May be there is some kind of deadlock.

Its actually very hard to get the system to a point in which the token is recognized.

I randomly restart pcscd, and insert/remove the token till I can get its serial via opensc-tool and then, only sometimes will accept to try generating the key.

I get a lot of card not present, or empty slot, binding failed, unsupported card etc.

I test my setup with an older token (ePass PKI) and it looks more robust, but still with lots of similar problems.

I wonder if I have something too old in my environment. I have lib-usb-1.0-0_1.0.11, on Debian 3.2.60-1+deb7u3.

I might just replicate your environment and test. Which ubuntu is it? any particular version?

[LudovicRousseau]

I moved the Feitian ePass2003 token from the "supported" to the "should work" list. http://pcsclite.alioth.debian.org/ccid/shouldwork.html#0x096E0x0807

Maybe I have a ePass2003 and will be able to make tests myself and then maybe move the token in the "unsupported" list.

I don't think you have a software problem with libusb or another component. Maybe you have a USB hardware problem. Test on another computer. Or maybe your token is broken.

[dengert]

On 10/20/2014 3:31 PM, Rafael wrote:

I did the test, and it is still failing.
It takes much longer to fail. May be there is some kind of deadlock.

Its actually very hard to get the system to a point in which the token is recognized.

I randomly restart pcscd, and insert/remove the token till I can get its serial via opensc-tool and then, only sometimes will accept to try generating the key.

This could also be hardware. Defective token, dirty or bent USB plug or port. Power to USB not left on?

I get a lot of card not present, or empty slot, binding failed, unsupported card etc.

I test my setup with an older token (ePass PKI) and it looks more robust, but still with lots of similar problems.

I wonder if I have something too old in my environment. I have lib-usb-1.0-0_1.0.11, on Debian 3.2.60-1+deb7u3.

I might just replicate your environment and test. Which ubuntu is it? any particular version?

$ uname -a
Linux XUbuntu-14 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/lsb-release

Ubuntu 14.04.1 LTS 64 bit
Virtual Box 4.3.12
Windows 7 64 on i5.

Its xubuntu, simpler graphics, look more like windows or the Xwindows I like.

If you have an old PC, try running Linux on it, native.

—
Reply to this email directly or view it on GitHub #301 (comment).

Douglas E. Engert DEEngert@gmail.com

[marcrt]

No problem generating 2048 key on an old PC "Ubuntu 12.04.4 LTS" native 32bits
it takes about 10sec.

[gertvdijk]

No problem here either. Compared to other cards/tokens it's slow, but it works very reliably in my environment.

However, USB forwarding to a virtual machine (KVM, libvirt) made my VM crash as soon as I accessed it using any tool. I'm not sure what's going on there, but I guess this VM-passthrough is more libusb/libccid related than OpenSC. Using regular smart card forwarding should just work, by the way (unsure of non-Windows guest support).

[frankmorgner]

@rvalle can you test with a different token or setup?

[rvalle]

I finally got a real HW PC to test with. will give it a try.