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.

[rvalle]

Just realized that there is now a download for OSX.

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

As in the virtual machine, I can generate rsa 1024 keys but this error comes up with 2048 keys.

I am starting to think that may be there is something wrong with my tokens: I got them direct from Feitian shop the 5x SDK.

On HW I use debian, where the distribution is very old. I will have to compile the packages.

[rvalle]

Yes, on a new server I can generate rsa/2048. it works.

So I didn't manage to make it work on these platforms:

• Linux guest running on VirtualBOX/OSX host.
• OSX

My use case is running a private certificate authority, I dont want to share the same box with other services, so, a virtual server would be convenient.

[dengert]

If this is a timeing problem, or problem with USB power being turned off, the OSX host controls that in both cases: VirtualBOX/OSX host and OSX native. So I would point the finger at OSX, or the pcscd verison used on OSX.

You used the terms "new server" and "debian, where the distribution is very old", this does not help very much. Giving versions of hardware, OS (both host and virtual) , pcsc-lite (both host and virtual) , VirtualBox and opensc (virtual) in the future would help.

[rvalle]

Sure.
If you need an environment where to reproduce the problem here are the versions you need:

• HOST: OSX 10.9.5 (MacBook Pro, late 2013).
• Hypervensor: VirtualBOX 4.3.20
• Debian 7 with: OpenSC 0.14.0, ccid-1.4.18, pcsc-lite-1.8.12

[dengert]

Maybe someone with a MacBook can test this, I can not.

The epass2003 I have has a LED in it, and is always on. If the issue is the USB gets powered down, does the LED goo off?

Something simple to try is a a USB hub that has a LED to see if it stays powered up, and if the hub
has an external power try the hub with that too.

On 12/29/2014 8:12 AM, Rafael wrote:

Sure.
If you need an environment where to reproduce the problem here are the versions you need:

• HOST: OSX 10.9.5 (MacBook Pro, late 2013).
• Hypervensor: VirtualBOX 4.3.20
• Debian 7 with: OpenSC 0.14.0, ccid-1.4.18, pcsc-lite-1.8.12

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

Douglas E. Engert DEEngert@gmail.com

[gertvdijk]

FWIW, my ePass2003 LED keeps ON (and heats up a little) when I plug it into a USB power port when my notebook is OFF.

In a broader scope, isn't this discussion is a bit pointless in OpenSC here? I see USB level issues which are known with VirtualBox and other hypervisors. I'd report it there, like this one and this one.

@rvalle I'm curious why it won't work natively on your Mac OS X host. Did you create a proper pkcs15 profile on the card? I see the same errors when erasing the card, but failing to initialize the token properly before generating a keypair. E.g. this should work, but would fail if you'd omit the second line.

pkcs15-init --erase-card
pkcs15-init --create-pkcs15 --profile pkcs15+onepin --label "My ePass2003"
pkcs15-init --auth-id 1 --generate-key rsa/2048 --key-usage sign,decrypt --label "My first RSA key pair"

(as explained in this blog article).

Just wanted to point out this because ePass2003 tokens out of the box don't work with OpenSC, neither those initialized with the proprietary Feitian software.

[rvalle]

With regards to OSX, yes, I followed those steps. I add another parameter when initializing the token which is: --use-default-transport-key

I remember that in both cases (OSX & Virutal Machine) the LED blinks and when it fails (2048 bit keys) it remains off for some seconds before failing. Sometimes (or every time, I don't remember) the token is not detected after the error and software/hardware needs to be restarted/replugged.

With OSX native I can continue testing if you want. However I am unsure of which are all dependencies, I updated OpenSC to the last version 0.14.0 but I have had other tokens working here your years and I don't know if the required libraries are same as Linux. If you point me in the right direction I will do more testing. Meanwhile I will try the HUB and see if that changes something.

Also, If any in the dev team is willing to test but has no Macbook I could open an SSH tunnel into the Virtual Machine. Yes, it might be an USB issue, yet is making your software fail, you might want to check if there is an easy workaround.

I do a lot of USB/VirtualBox in this macbook, usually without much trouble, that includes using programmers for micro controllers and even an USB oscilloscope. Should be feasible to make it work.

Just let me know if I can help somehow.

[LudovicRousseau]

It looks like the problem is not in OpenSC but in a low level layer.

Can you detail (OS, pcsc-lite version, libccid version, virtual machine or not):

• the configuration(s) that work
• the configuration(s) that does not work

[rvalle]

Here is the summary:

Token: epass2003

Working configurations:

*) Metal amd64 server

• OS: Debian 7
• OpenSC: 0.14.0
• PCSC-LITE: 1.8.13
• LIBCCID: 1.4.18

*) Metal arm6 server (Raspberry PI)

• OS: Debian 7
• OpenSC: 0.14.0
• PCSC-LITE: 1.8.13
• LIBCCID: 1.4.18

Failing Configurations:

*) Metal OSX (Macbook Pro late 2013)

• OS: OSX 10.9 Mavericks
• OpenSC: 0.14.0

*) Virtual amd64 server:

• HOST OS: OSX 10.9.5
• HOST HW: MacBook Pro, late 2013.
• Hypervensor: VirtualBOX 4.3.20
• GUEST OS: Debian 7.
• OpenSC: 0.14.0
• PCSC-LITE: 1.8.13
• LIBCCID: 1.4.18

[dengert]

Looks like a problem with the MAC version of pcscd and long operations...

I have no way to test this, but VirtualBox runs well under Windows 7

On 1/2/2015 1:24 AM, Rafael wrote:

Here is the summary:

Token: epass2003

Working configurations:

*) Metal amd64 server

• OS: Debian 7
• OpenSC: 0.14.0
• PCSC-LITE: 1.8.13
• LIBCCID: 1.4.18

*) Metal arm6 server (Raspberry PI)

• OS: Debian 7
• OpenSC: 0.14.0
• PCSC-LITE: 1.8.13
• LIBCCID: 1.4.18

Failing Configurations:

*) Metal OSX (Macbook Pro late 2013)

• OS: OSX 10.9 Mavericks
• OpenSC: 0.14.0

*) Virtual amd64 server:

• HOST OS: OSX 10.9.5
• HOST HW: MacBook Pro, late 2013.
• Hypervensor: VirtualBOX 4.3.20
• GUEST OS: Debian 7.
• OpenSC: 0.14.0
• PCSC-LITE: 1.8.13
• LIBCCID: 1.4.18

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

Douglas E. Engert DEEngert@gmail.com

[LudovicRousseau]

@rvalle you can get pcscd debug on Mac OS X. For that

• connect your smart card reader
• kill any running pcscd process
• start pcscd in a terminal using "sudo LIBCCID_ifdLogLevel=0x000F /usr/sbin/pcscd -dfa"

Then attach the last ~50 lines of logs.

[rvalle]

@LudovicRousseau here you have the logs.

If it is a HW issue, you have workarround it in the past.
I have had tokens running on this MacBook since I got it.
The older token: epassPKI is working fine generating RSA 2048, while the epass2003 fails.

So I have captured both logs, from working and failing token, here are those:

epass2003RSA2048KeyGenFailure: http://pastebin.com/nwvAEzZf
epassPKIRSA2048KeyGenOK: http://pastebin.com/3D2SXrdB

the epassPKI is super-low, but it finally gets a working RSA2048 key. (I have verified it by using it with SSH).

[rvalle]

@LudovicRousseau also, for your information, not only KeyGeneration is failing on epass2003@MyMacbook.

I have also tried to use the generated RSA2048 keys on other working environments on this macbook, by using them with SSH, and I get a Signature Error like:

ssh user@server.lan
Enter PIN for '(User PIN)':
C_Sign failed: 5
ssh_rsa_sign: RSA_sign failed: unknown err

[LudovicRousseau]

Line 694:

-> 000000 6F 26 00 00 00 00 C0 00 00 00 8C B4 02 00 20 87 11 01 F0 5D 17 5C 7E 97 D9 0D 43 46 04 8C 71 4B 65 B7 97 01 00 8E 08 1C 5E 1F 3A E8 2D 54 8C 00
07562197 ccid_usb.c:798:ReadUSB() read failed (20/8): -7 Operation timed out
SW:
/SourceCache/SmartCardServices_Executables/SmartCardServices-55111/src/PCSC/ifdwrapper.c:741:IFDTransmit() Card not transacted: 612
/SourceCache/SmartCardServices_Executables/SmartCardServices-55111/src/PCSC/winscard.c:1325:SCardTransmit() IFDControl_v2/IFDTransmit result: 0x80100016, received: 0

The driver timed out after 7.56 seconds.

In lines 647-664 you have:

APDU: 0C 46 00 00 1D 87 11 01 DB 09 8B DD 18 00 10 19 CE 43 01 1A 0D 4B 18 53 8E 08 7A 5F 96 A3 E4 4B 34 77 00
00280137 ifdhandler.c:1283:IFDHTransmitToICC() Feitian ePass2003 (lun: 0)
00000007 commands.c:1590:CmdXfrBlockAPDU_extended() T=0 (extended): 35 bytes
-> 000000 6F 23 00 00 00 00 BE 00 00 00 0C 46 00 00 1D 87 11 01 DB 09 8B DD 18 00 10 19 CE 43 01 1A 0D 4B 18 53 8E 08 7A 5F 96 A3 E4 4B 34 77 00
<- 000000 80 00 00 00 00 00 BE 80 03 00
01067065 commands.c:1519:CCID_Receive() Time extension requested: 0x03
00000006 commands.c:1525:CCID_Receive() New timeout: 9000 ms
<- 000000 80 00 00 00 00 00 BE 80 03 00
01101870 commands.c:1519:CCID_Receive() Time extension requested: 0x03
00000007 commands.c:1525:CCID_Receive() New timeout: 9000 ms
<- 000000 80 00 00 00 00 00 BE 80 03 00
01099680 commands.c:1519:CCID_Receive() Time extension requested: 0x03
00000006 commands.c:1525:CCID_Receive() New timeout: 9000 ms
<- 000000 80 00 00 00 00 00 BE 80 03 00
01093607 commands.c:1519:CCID_Receive() Time extension requested: 0x03
00000013 commands.c:1525:CCID_Receive() New timeout: 9000 ms
<- 000000 80 10 00 00 00 00 BE 00 00 00 99 02 90 00 8E 08 68 D6 48 8A AB EC 2A AB 90 00
SW: 99 02 90 00 8E 08 68 D6 48 8A AB EC 2A AB 90 00 

So the token is correctly sending "time extension requests" in some cases.

I guess it is the same problem you talked about in #301 (comment)

I am surprised that the same token works fine on Debian and Raspberry Pi.
How have you solved the problem described in #301 (comment) ?

[rvalle]

I haven't fixed anything, I have just tested on different environments.
I am, in fact, considering to deploy this token in our company, so I am an end user.
What I can do is get you similar logs on the working environments.

[marcrt]

Could you give the serial number of failling ePass2003. Only the first 4 digits written on the USB connector YYMM. According to Feitian ePass2003 COS had an update which improved the support of 2048 certificate in Mac OS.

Currently I have got a similar problem on OSX 10.9 and 10.10 with Feitian proprietary middleware and old 1210 ePass2003. I will try with a recent one on OSX with both Feitan middleware and OpenSC and keep you informed.

The same ePass2003 is working fine with 2048 certificates on other plateforms
xubuntu 14.4 with OpenSC 0.14.0
Windows7 with both Feitan Middleware and OpenSC

My company Logidata is distributor of Feitian in France we may also help with hardware or latest beta drivers.

[rvalle]

@marcrt I got this Feitian SDK quite recently.
The YYMM on my tokens is: 1409

[rvalle]

@LudovicRousseau , @marcrt
Some more information on the OSX environment,
I just performed a Clean install of my Macbook with OSX 10.10.1 Yosemite: that is format the HD drive and reinstall from the scratch.
And the epass2003 continues to fail generating RSA/2048.
This time, however, the error message is slightly different:

pkcs15-init --auth-id 1 --generate-key rsa/2048 --key-usage sign,decrypt --label "My first RSA key pair"
Using reader with a card: Feitian ePass2003
Failed to generate key: Card removed

[marcrt]

@rvalle
Firefox TLS user authentication with 2048 bits certificate works on my side (certificate generated on another environment. Same transaction was failing with old ePass2003)
ePass2003 serial nb 1409xxxx
Feitian middleware 20141209
MacBook pro with OSX 10.10.1 Yosemite
@LudovicRousseau
I agree the problem is at low level. Recent COS is necessary for 2048 operations on Mac only, less chance to get a CCID error. I am also a bit confused with apple ctkpcsd implementation compared to pcsc-lite.
What version of ePass2003 hardware did you test in http://pastebin.com/nwvAEzZf ?

[rvalle]

@LudovicRousseau after some correspondence with ftsafe, they seem to have fixed this problem.

[FeitianSmartcardReader]

@LudovicRousseau The problem has fixed in firmware, and i just check web http://pcsclite.alioth.debian.org/ccid/section.html,It showed below, could you please change status of epass2003? thanks
"The device may fail at generating keys onboard. See #301"

[LudovicRousseau]

@FeitianSmartcardReader have you changed the firmware release bcdDevice to a value > 1.00 to differentiate from the bogus version?

[martinpaljak]

Yes, this is a common problem - no change in observable attributes if behaviour changes. This is a must have.

[FeitianSmartcardReader]

Yes, our engineer already changed bcdDevice vaule, thanks