New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
epass2003 RSA/2048 Failed to Generate Key on OSX, VirtualBOX #301
Comments
On 10/16/2014 6:48 AM, Rafael wrote:
A opensc debug trace would help. This suggests that you must us the --pin option. Could be related to: What system?
Douglas E. Engert DEEngert@gmail.com |
Ok, To make things easier I downloaded and built the latest versions of the following modules:
you can find the trace here: hope that it helps, |
On 10/18/2014 2:33 AM, Rafael wrote:
line 1653 has: http://blog.gmane.org/gmane.comp.lib.muscle/month=20120901 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: 0x7ffaf1ee4740 13:41:47.857 [pkcs15-init] ../../../src/src/libopensc/reader-pcsc.c:182:pcsc_internal_transmit: called 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.
Douglas E. Engert DEEngert@gmail.com |
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:
Douglas E. Engert DEEngert@gmail.com |
@rvalle, generate a pcscd log as described in http://pcsclite.alioth.debian.org/ccid.html#support |
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. |
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: the command used for generating the key and its output is:
thanks! |
The command at line 804 is taking around 10 seconds and you can see the time requests sent by the reader:
Then the next APDU is sent and the reader do not replay before the driver timout of 3000 ms. So we get a:
-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 |
I did the test, and it is still failing. 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? |
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. |
On 10/20/2014 3:31 PM, Rafael wrote:
This could also be hardware. Defective token, dirty or bent USB plug or port. Power to USB not left on?
$ uname -a $ cat /etc/lsb-release Ubuntu 14.04.1 LTS 64 bit 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.
Douglas E. Engert DEEngert@gmail.com |
No problem generating 2048 key on an old PC "Ubuntu 12.04.4 LTS" native 32bits |
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). |
@rvalle can you test with a different token or setup? |
I finally got a real HW PC to test with. will give it a try. |
Just realized that there is now a download for OSX.
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. |
Yes, on a new server I can generate rsa/2048. it works. So I didn't manage to make it work on these platforms:
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. |
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. |
Sure.
|
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 On 12/29/2014 8:12 AM, Rafael wrote:
Douglas E. Engert DEEngert@gmail.com |
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.
(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. |
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. |
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):
|
Here is the summary: Token: epass2003 Working configurations: *) Metal amd64 server
*) Metal arm6 server (Raspberry PI)
Failing Configurations: *) Metal OSX (Macbook Pro late 2013)
*) Virtual amd64 server:
|
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:
Douglas E. Engert DEEngert@gmail.com |
@rvalle you can get pcscd debug on Mac OS X. For that
Then attach the last ~50 lines of logs. |
@LudovicRousseau here you have the logs. If it is a HW issue, you have workarround it in the past. So I have captured both logs, from working and failing token, here are those: epass2003RSA2048KeyGenFailure: http://pastebin.com/nwvAEzZf the epassPKI is super-low, but it finally gets a working RSA2048 key. (I have verified it by using it with SSH). |
@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 |
Line 694:
The driver timed out after 7.56 seconds. In lines 647-664 you have:
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. |
I haven't fixed anything, I have just tested on different environments. |
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 My company Logidata is distributor of Feitian in France we may also help with hardware or latest beta drivers. |
@marcrt I got this Feitian SDK quite recently. |
@LudovicRousseau , @marcrt pkcs15-init --auth-id 1 --generate-key rsa/2048 --key-usage sign,decrypt --label "My first RSA key pair" |
@rvalle |
@LudovicRousseau after some correspondence with ftsafe, they seem to have fixed this problem. |
@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 |
@FeitianSmartcardReader have you changed the firmware release bcdDevice to a value > 1.00 to differentiate from the bogus version? |
Yes, this is a common problem - no change in observable attributes if behaviour changes. This is a must have. |
Yes, our engineer already changed bcdDevice vaule, thanks |
Hi!
I am having trouble generating RSA 2048 keys on epass2003.
I get:
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?
The text was updated successfully, but these errors were encountered: