Sign and Decrypt operations failing on new epass2003 devices but not on an older one #2843
Comments
|
Your token uses AES_CMAC for MAC in SM mode (TAG 0x87 in response to capabilities) This token was probably not available to anyone except @xaqfan, who wrote support for this type of MAC (commit 622e6e2) I'm afraid the only one who will know how to do something about it is @FeitianSmartcardReader or @xaqfan. |
|
Other Secure Messaging (SM) commands appear to work, but the decipher at There have been a lot of changes to card-epass2003.c since 0.23.0 was released. Are you able build OpenSC from github master? |
|
Is there a proprietary pkcs11 module for epass2003 (Windows or Linux)? Can you test something like that with your token? I wonder if the signing/decrypting operation works with this (if the log was available it would be possible to analyze and fix the driver in opensc). |
|
Thanks for the responses. We had some difficulty building the binary ourselves, but I grabbed
|
|
Does |
|
|
|
I am afraid that only its supplier can help with this (new) token. It will be necessary to fix several operations, unfortunately it will not work without documentation. @FeitianSmartcardReader ? |
|
After struggling a while, I found this discussion and understood why the recently bought ePass2003 tokens from Feitian were not working for signing and decrypting (x509 certificate used with Thunderbird). I should have found this thread sooner! |
|
@zepingouin, would you suggest to add some clarificaition to https://github.com/OpenSC/OpenSC/wiki/Feitian-ePass2003? |
@zepingouin may be I'm blind, but what conclusion do you get from this thread? I'm having the same "Card command failed" error when creating pkcs#15 structure. @frankmorgner the issue was closed as completed, but i haven't seen any information how to resolve the issue? What should i do? |
|
Sorry, I may have misread one comment. I don't think we currently have a solution for this. I think you should (again) contact the vendor. |
|
Thanks @frankmorgner for reopening the issue. I wrote an inquiry on @FeitianSmartcardReader websites contact form. I'll get back to you guys when I've got an answer. |
|
@zepingouin @faryon93 Where did you buy these tokens? All the Feitian web site I can find do not have any "red" tokens. |
|
I can provide a bit of an update on this. We liaised with staff at Feitian and reached the conclusion that as part of their switch to supporting FIPS 140-2 Level 3 they had changed to a different token (same reader), which appeared to not be compatible with the OpenSC API, at least with respect to RSA-2048 signing operations. They sent me a batch of red-cased devices without the FIPS marking using an alternate (I think the old) token, which worked as before. We've since received purple-cased devices with the FIPS marking that are continuing to work as before, however I've been providing the instruction "None-FIPS or Standard-FIPS please" when ordering which may be causing them to vary the token contained within. I haven't followed up yet to see if they made a change to their FIPS-compliant token to support the OpenSC API, or if I'm continuing to get older tokens. In our context we don't care about the later FIPS standard so it hasn't been a high priority to follow up. Note with respect to the colors, it's just a decorative aspect as far as I'm aware - in large orders you used to be able to choose the casing color. Hope that clears some things up! |
|
@dengert I purchased the token at a local Austrian reseller, not directly via the feitian webstore. I think the color can be customized when you order a big enough lot. So the color may not be a hint of the version. @dengert found out that my token is indeed a FIPS certified token #3034 (comment), despite there not beeing any markings on the case:
@drodgers-immt did your tokens had a designated FIPS marking on them? |
|
Hi @dengert et al, I bought this token in september 2023 on Feitian web store. Specifications effectively indicate a FIPS-140-2 Level 3 certified token.
|
|
@drodgers-immt @faryon93 @zepingouin Thanks for the updates. And @xaqfan who has made several changes to OpenSC in this area. To get a handle on what each of us have and what OpenSC can support is to get the ATR from each of. It appears to have a versions number. Using my old epass2003 from Gooze in 2011 Dark blue, only "CE" "FCC" Certification Requirements marks. Can each of you and anyone else with a epass2003 post the output of the above for any of their devices, as well as any wording ion the token? ATR can be parsed using: https://smartcard-atr.apdu.fr/ The historical bytes is mine show 'Tag: 6, Len: 6 (pre-issuing data) The From @faryon93 post above: There may be more but OpenSC only tests the above few.
|
|
There is no specific wording on the token as seen on the above picture. |
|
Mine was bought 02/2024 and also has CE and FCC markings on the back. On the front there is "ePass2003" written.
|
|
@drodgers-immt Can you try running |
|
Sorry for the delay, had a busy week! Device purchased around Feb-2022Device chassis is black with no FIPS marking on it. These devices have been working fine for our use case. Device purchased around Aug-2023Device chassis is black, marked with Device purchased around Oct-2023Device chassis is red, no FIPS marking. This was a replacement sent by Feitian when we discovered the issues with the previous dongle. These devices have been working fine for our use case. Device purchased around Jan-2023Device chassis is purple, marked with (not sure why the output is much shorter on this one) |
|
@drodgers-immt Thanks for the info. I am working on a spreadsheet with all the info. |
|
We seem to have multiple problems with epass2003 devices as shown in #3034, (This issue) #2843 and #2572 from 2022 that I forgot about. All the comments in Other issues and comments in the code indicate OpenSC initialized cards do not work with Feitian minidriver. The life cycle bits in ATR are different. i.e. OpenSC is not telling card to reset the LCS byte in ATR Historical bytes "Mandatory status indicator (3 last bytes): to zero, but leaving is as 0x03, The code defines: |
|
https://github.com/dengert/OpenSC/tree/epass2003-sm-new has been forced pushed with only debugging code to show what data is being encrypted and decrypted and mac'ed. This will help see what is going on. Here is the spreedsheet [230303-Feitian-tokens.xls] (https://github.com/OpenSC/OpenSC/files/14488291/230303-Feitian-tokens.xls) covering ePass2003 info from @zepingouin @drodgers-immt @faryon93 and myself and the ATRs listed in card-epass2003.c. I received my two ePass2003 tokens today March 3, 2023 with no documentation. They appear to match the tokens that are failing from the three of you. All of the failing tokens have the T80 and T87 set to one. @zepingouin Your card is failing to initialize. But @drodgers-immt and @faryon93, you both say yours are failing doing sign and/or decipher. https://shop.ftsafe.us/products/epass2003-pki#:~:text=FEITIAN%20ePass2003%20is%20a%20FIPS,technology%20and%20standards%20available%20today. Looking for how any of you initialized one of these tokens. |
|
Hi @dengert, what I am doing is mentioned in the OP at the top of this thread. We are using OpenSC for everything. |
I will pull the changes and record logs this evening and post here.
I initialized the token with your proposed workaround of commenting out the call to
|
|
Correction, initialization worked with OpenSC 0.23.0, only sign and/or decipher failed. Also for Also for Then I applied the following patch (#3034 comment): |
@dengert Here are my collected traces with a version built from your branch: https://pastebin.com/YvZk2Zxk (without patch) https://pastes.io/otjqcddd56 (token initilized with workaround) |
|
@FeitianSmartcardReader As OpenSC developer, trying to solve 3 problems reported by al least four others, included one hos has contacted Feitian support. In this effort, I purchased 2 "Epass2003FIPS" "Feitian ePass2003 PKI USB-A Token FIPS 140-2" These tokens match the tokens that are failing with brand new ATR I would like to work with @FeitianSmartcardReader to solve these problem but there is very little documentation on specific card versions. I have also committed https://github.com/dengert/OpenSC/tree/epass2003-sm-new That include additional debugging code and some comments that shows some of the things I have tried to solve these problems. The main problem appear to be in Any other people with ideas? |
|
Pushed a commit to get epass2003 past |
Thank you @dengert for all your work :) I can confirm that OpenSC built from your commit is able to successfully initialize the token. I got a weird compiler error, about |
|
No compiler error, your commit successfully initialized the token, thanks @dengert for the work! 👍 |
|
@FeitianSmartcardReader are you reading these messages? Some progress with epass2003 FIPS tokens and sig/decipher commands. Good news: creating an EC key, signing some data and verifying the signature work. The problems is with RSA 2048 bit keys, require more then 256 bytes of data need to be sent to the card. EC and RSA 1024 (but token does not support it) do not need to use extended APDUs. It appears the card is very limited in which EC curves it supports. I am still working on this. |
|
I confirm @dengert , EC sign/verify works . |
|
Hi @dengert, |
|
Hi @dengert , |
|
@xaqfan @FeitianSmartcardReader I have sent the following to https://ftsafe.us/support/ Feitian web pages advertise their devices work with OpenSC: https://shop.ftsafe.us/products/epass2003-pki As an OpenSC open software developer, I recently purchased 2 "EPass2003FIPS" "FIPS 140-2" tokens because recent OpenSC bug reports these tokens do not work with OpenSC. The primary discussion has been on: #2843 I am seeking technical information so OpenSC (or Feitian developers) can address the problem. ECDSA p-256 works with one minor change: RSA 2048 operations fail. RSA 2048 requires sending more then 256 bytes of data to the token so uses extended APDUs. The problem appears to be on the token which has some problem with extended APDU, CMAC, TLVs or padding. I have tried many possible changes and combinations of changes. including rewriting "aes128_encrypt_cmac_ft" and testing with 4 test cases from NIST 800-30B. "aes128_encrypt_cmac" which uses OpenSSL also pass the tests. All of the failing tokens have: The Tags are from first object read from the token using APDU:00 CA 01 86 00 and on my token reads: Incoming APDU (37 bytes): The FIPS tokens use AES-128-CMAC rather then aes-128-CBC or AES-128-ECB. Developers that may be from Feitian include: AlexBear xaqfan@163.com (last OpenSC update: 2023-04-22) Feitian Technologies hongbin@ftsafe.com (last OpenSC update: 2020-06-03) AKA https://github.com/FeitianSmartcardReader |
Problem Description
A set of recently manufactured epass2003 devices (sourced from Feitian) are erroring with
Card command failed(1200) when attempting a sign or decrypt operation. An older epass2003 device initialized using the same procedure is performing correctly.Proposed Resolution
Unclear what the problem is!
We've also reached out direct to Feitian, will update this issue if they come through with something, but I thought I'd try my luck here as well in case there is an OpenSC toolset change I've not spotted that could be causing this.
Steps to reproduce
On both devices, I have done the following procedure:
Then, running this command:
Produces the correct output on the old card, and
Compute signature failed: Card command failedon the new ones. Same thing for the decipher operation. Public key is accessible and is the same format between the two cards.Diffing the output of
./opensc-tool.exe -fhad a difference in the serial numbers and in the final block which I assume is the public key data, otherwise everything else is the same. The old device had been previously initialized using an older version of OpenSC (0.16 I think) and had a much smaller file contents, but after erasing and re-init'ing the card in the new OpenSC version (0.23) it now looks the same.OpenSC-0.23.0, rev: 5497519e, commit-time: 2022-11-29 09:34:43 +0100Logs
https://gist.github.com/drodgers-immt/eea221465190b979a37f95f96b60c263 for the full run log.
(Note that I have both the old and new smartcard connected to my system, I'm actually using
-r <id>on the commands to target each one, but I left it out of the commands above to avoid confusion. Problem still occurs individually).The text was updated successfully, but these errors were encountered: