Sign and Decrypt operations failing on new epass2003 devices but not on an older one

[drodgers-immt]

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:

pkcs15-init.exe -E
pkcs15-init.exe -C --profile pkcs15+onepin --pin <pin> --puk <puk>
pkcs15-init.exe -G rsa/2048 -a 01 -i 01 --pin <pin> -u decrypt -u sign -l <label> --public-key-label <label>

Then, running this command:

pkcs15-crypt.exe -c --key 01 -p <pin> -i <signed file>

Produces the correct output on the old card, and Compute signature failed: Card command failed on 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 -f had 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 +0100

Logs

<snip>
P:26832; T:28232 2023-08-25 16:45:09.564 [pkcs15-crypt] Unknown SWs; SW1=6F, SW2=83
P:26832; T:28232 2023-08-25 16:45:09.564 [pkcs15-crypt] card-epass2003.c:2195:epass2003_decipher: returning with: -1200 (Card command failed)
P:26832; T:28232 2023-08-25 16:45:09.564 [pkcs15-crypt] sec.c:66:sc_compute_signature: returning with: -1200 (Card command failed)
P:26832; T:28232 2023-08-25 16:45:09.564 [pkcs15-crypt] card.c:530:sc_unlock: called
P:26832; T:28232 2023-08-25 16:45:09.564 [pkcs15-crypt] reader-pcsc.c:740:pcsc_unlock: called
P:26832; T:28232 2023-08-25 16:45:09.580 [pkcs15-crypt] pkcs15-sec.c:169:use_key: returning with: -1200 (Card command failed)
P:26832; T:28232 2023-08-25 16:45:09.580 [pkcs15-crypt] pkcs15-sec.c:771:sc_pkcs15_compute_signature: use_key() failed: -1200 (Card command failed)
P:26832; T:28232 2023-08-25 16:45:09.580 [pkcs15-crypt] pkcs15-sec.c:784:sc_pkcs15_compute_signature: returning with: -1200 (Card command failed)
Compute signature failed: Card command failed

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).

[popovec]

Your token uses AES_CMAC for MAC in SM mode (TAG 0x87 in response to capabilities)

00 CA 01 86 00 .....
Incoming APDU (37 bytes):
80 01 01 81 02 1D D4 82 01 00 83 02 00 00 84 01 ................
01 85 0A 00 9A 2E 81 08 96 00 1A 00 1D 86 01 00 ................
87 01 01 90 00                                  .....

This token was probably not available to anyone except @xaqfan, who wrote support for this type of MAC (commit 622e6e2469c67b4fdbbf7c9268bf865e77e61f85)

I'm afraid the only one who will know how to do something about it is @FeitianSmartcardReader or @xaqfan.

[dengert]

Other Secure Messaging (SM) commands appear to work, but the decipher at line 2800 99 02 6F 83 8E 08 59 74 29 E1 22 A6 56 30 6F 83 is returning 6F 83. 6F 00 says: "No precise diagnosis" Not sure what the 83 is saying.

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?

[popovec]

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).

[drodgers-immt]

Thanks for the responses. We had some difficulty building the binary ourselves, but I grabbed OpenSC-0.23.0-411-g33351d91, rev: 33351d91, commit-time: 2023-08-17 15:21:21 +0200 from the nightly repository. The error changed to a PIN code verification failed: Card command failed. Erasing and re-initializing the card I'm back to Failed to create PKCS #15 meta structure: Card command failed:

pkcs15-init.exe -r 0 -C --profile pkcs15+onepin --pin <pin> --puk <puk>

P:28884; T:40392 2023-08-29 14:44:38.791 [pkcs15-init] apdu.c:382:sc_single_transmit: returning with: 0 (Success)
P:28884; T:40392 2023-08-29 14:44:38.792 [pkcs15-init] apdu.c:539:sc_transmit: returning with: 0 (Success)
P:28884; T:40392 2023-08-29 14:44:38.793 [pkcs15-init] card.c:523:sc_unlock: called
P:28884; T:40392 2023-08-29 14:44:38.795 [pkcs15-init] card-epass2003.c:1558:epass2003_sm_free_wrapped_apdu: called
P:28884; T:40392 2023-08-29 14:44:38.796 [pkcs15-init] card-epass2003.c:1518:epass2003_sm_unwrap_apdu: called
P:28884; T:40392 2023-08-29 14:44:38.797 [pkcs15-init] Warning, MAC is not checked
P:28884; T:40392 2023-08-29 14:44:38.798 [pkcs15-init] Conditions of use not satisfied
P:28884; T:40392 2023-08-29 14:44:38.799 [pkcs15-init] unwrapped APDU: resplen 0, SW 6985
P:28884; T:40392 2023-08-29 14:44:38.801 [pkcs15-init] card-epass2003.c:1547:epass2003_sm_unwrap_apdu: returning with: 0 (Success)
P:28884; T:40392 2023-08-29 14:44:38.803 [pkcs15-init] card-epass2003.c:1579:epass2003_sm_free_wrapped_apdu: returning with: 0 (Success)
P:28884; T:40392 2023-08-29 14:44:38.805 [pkcs15-init] sm.c:173:sc_sm_single_transmit: returning with: 0 (Success)
P:28884; T:40392 2023-08-29 14:44:38.806 [pkcs15-init] apdu.c:374:sc_single_transmit: returning with: 0 (Success)
P:28884; T:40392 2023-08-29 14:44:38.807 [pkcs15-init] apdu.c:539:sc_transmit: returning with: 0 (Success)
P:28884; T:40392 2023-08-29 14:44:38.808 [pkcs15-init] card.c:523:sc_unlock: called
P:28884; T:40392 2023-08-29 14:44:38.809 [pkcs15-init] Conditions of use not satisfied
P:28884; T:40392 2023-08-29 14:44:38.811 [pkcs15-init] card-epass2003.c:2772:epass2003_create_file: APDU sw1/2 wrong: -1209 (Not allowed)
P:28884; T:40392 2023-08-29 14:44:38.812 [pkcs15-init] card.c:595:sc_create_file: returning with: -1209 (Not allowed)
P:28884; T:40392 2023-08-29 14:44:38.814 [pkcs15-init] pkcs15-epass2003.c:65:epass2003_pkcs15_init_card: Create MF failed: -1209 (Not allowed)
P:28884; T:40392 2023-08-29 14:44:38.815 [pkcs15-init] pkcs15-lib.c:874:sc_pkcs15init_add_app: Card specific init failed: -1209 (Not allowed)
P:28884; T:40392 2023-08-29 14:44:38.817 [pkcs15-init] pkcs15-lib.c:969:sc_pkcs15init_add_app: returning with: -1209 (Not allowed)
P:28884; T:40392 2023-08-29 14:44:38.819 [pkcs15-init] card.c:523:sc_unlock: called
P:28884; T:40392 2023-08-29 14:44:38.820 [pkcs15-init] reader-pcsc.c:742:pcsc_unlock: called
Failed to create PKCS #15 meta structure: Not allowed

[popovec]

Does pkcs15-init -E -T run correctly? Several times I ran into a situation where epass2003 reported Failed to create meta structure PKCS #15: Not allowed', but usingpkcs15-init -E -T' still helped.

[drodgers-immt]

pkcs15-init -E -T runs without any errors, but doesn't change the behavior of the following command:

$ ./pkcs15-init.exe -r 0 -C --profile pkcs15+onepin --pin PIN --puk PUK
Connecting to card in reader FS USB Token 0...
Using card driver epass2003.
Failed to create PKCS #15 meta structure: Card command failed

[popovec]

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 ?

[zepingouin]

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! Serial numbers are in the 2e6f44eb001aXXXX series and plastic case color is red. OpenSC built from source, OS is Ubuntu 22.04.3 LTS.

$ /opt/local/bin/opensc-tool --card-driver default --send-apdu 00:CA:01:86:00
Using reader with a card: Feitian ePass2003 00 00
Sending: 00 CA 01 86 00 
Received (SW1=0x90, SW2=0x00):
80 01 01 81 02 1D D4 82 01 00 83 02 00 00 84 01 ................
01 85 0A 05 6A 2E 6F 44 EB 00 1A 00 03 86 01 00 ....j.oD........
87 01 01

$ /opt/local/bin/opensc-tool --info
OpenSC 0.23.0 [gcc  11.4.0]
Enabled features: locking zlib readline openssl pcsc(libpcsclite.so.1)

[frankmorgner]

@zepingouin, would you suggest to add some clarificaition to https://github.com/OpenSC/OpenSC/wiki/Feitian-ePass2003?

[faryon93]

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! Serial numbers are in the 2e6f44eb001aXXXX series and plastic case color is red. OpenSC built from source, OS is Ubuntu 22.04.3 LTS.

$ /opt/local/bin/opensc-tool --card-driver default --send-apdu 00:CA:01:86:00
Using reader with a card: Feitian ePass2003 00 00
Sending: 00 CA 01 86 00 
Received (SW1=0x90, SW2=0x00):
80 01 01 81 02 1D D4 82 01 00 83 02 00 00 84 01 ................
01 85 0A 05 6A 2E 6F 44 EB 00 1A 00 03 86 01 00 ....j.oD........
87 01 01

$ /opt/local/bin/opensc-tool --info
OpenSC 0.23.0 [gcc  11.4.0]
Enabled features: locking zlib readline openssl pcsc(libpcsclite.so.1)

@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?

[frankmorgner]

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.

[faryon93]

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.

[dengert]

@zepingouin @faryon93 Where did you buy these tokens? All the Feitian web site I can find do not have any "red" tokens. Maybe time to pitch these.

[drodgers-immt]

Hi @dengert, @faryon93 et al,

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!

[faryon93]

@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 https://github.com/OpenSC/OpenSC/issues/3034#issuecomment-1951508146, despite there not beeing any markings on the case:

@drodgers-immt did your tokens had a designated FIPS marking on them?

[zepingouin]

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.

[dengert]

@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.

opensc-tool --card-driver default -a --send-apdu 00:CA:01:86:00
Using reader with a card: Feitian ePass2003 00 00
3b:9f:95:81:31:fe:9f:00:66:46:53:05:01:00:11:71:df:00:00:03:90:00:80
Sending: 00 CA 01 86 00 
Received (SW1=0x90, SW2=0x00):
80 01 01 81 02 1D D5 82 01 03 ..........

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) Data: 46 53 05 01 00 11 "FS...."` which may be a clue.

The 80 01 01 81 02 1D D5 82 01 03 is simple TLV with multiple tags starting with 80 to 8n, one byte length and data. So mine has: 80 01 01 OpenSC code says this is KEY_TYPE_AES, 80 01 00 would be DES3, 81 02 1D D5 Unknown. 82 01 03 Unknown.

From @faryon93 post above: 85 0A 05 6A 2E 6F 44 EB 00 1A 00 03 looks like the serial number? 86 01 00 Unknown 87 01 01 OpenSC code says exdata->bFipsCertification = 0x01

There may be more but OpenSC only tests the above few.

git blame card-epass2003.c and git log -epass2003.c shows who, what and when changes have been made to card-epass2003.c and grep ftsafe.com to see copyrights Feitian has on OpenSC files.

[zepingouin]

There is no specific wording on the token as seen on the above picture.

$ /opt/testing/bin/opensc-tool --card-driver default -a --send-apdu 00:CA:01:86:00
Using reader with a card: Feitian ePass2003 00 00
3b:9f:95:81:31:fe:9f:00:66:46:53:05:10:11:31:71:df:00:00:03:90:00:a0
Sending: 00 CA 01 86 00 
Received (SW1=0x90, SW2=0x00):
80 01 01 81 02 1D D4 82 01 00 83 02 00 00 84 01 ................
01 85 0A 07 55 2E 6F 44 EB 00 1A 00 03 86 01 00 ....U.oD........
87 01 01

[faryon93]

Mine was bought 02/2024 and also has CE and FCC markings on the back. On the front there is "ePass2003" written.

opensc-tool --card-driver default -a --send-apdu 00:CA:01:86:00                                                                                                                                                             
Using reader with a card: Feitian ePass2003 00 00
3b:9f:95:81:31:fe:9f:00:66:46:53:05:10:52:39:71:df:00:00:03:90:00:eb
Sending: 00 CA 01 86 00 
Received (SW1=0x90, SW2=0x00):
80 01 01 81 02 1D D4 82 01 00 83 02 00 00 84 01 ................
01 85 0A 00 6B 2C EC 10 E0 80 7B 80 02 86 01 00 ....k,....{.....
87 01 01                                        ...

85 0A 05 6A 2E 6F 44 EB 00 1A 00 03 looks like the serial number?

pkcs11-tool -L command shows only byte 3-9 of tag 85 as serial number.

[dengert]

@drodgers-immt Can you try running opensc-tool --card-driver default -a --send-apdu 00:CA:01:86:00 any any of the cards you have, including the red ones "supporting FIPS 140-2 Level 3" if you still have them? (When you get up - you are 14 hours ahead of me).

[drodgers-immt]

Sorry for the delay, had a busy week!

Device purchased around Feb-2022

Device chassis is black with no FIPS marking on it. These devices have been working fine for our use case.

Using reader with a card: FS USB Token 0
3b:9f:95:81:31:fe:9f:00:66:46:53:05:10:04:31:71:df:00:00:03:90:00:b5
Sending: 00 CA 01 86 00
Received (SW1=0x90, SW2=0x00):
80 01 01 81 02 01 D5 82 01 03 83 02 00 00 84 01 ................
01 85 0A 00 2B 28 8C 03 67 00 3F 00 19 86 01 00 ....+(..g.?.....

Device purchased around Aug-2023

Device chassis is black, marked with FIPS 140-2 Level 3. This is one of the devices that caused me to open this issue, that we can't get RSA-2048 signing operations to work with.

Using reader with a card: FS USB Token 0
3b:9f:95:81:31:fe:9f:00:66:46:53:05:10:11:31:71:df:00:00:03:90:00:a0
Sending: 00 CA 01 86 00
Received (SW1=0x90, SW2=0x00):
80 01 01 81 02 1D D4 82 01 00 83 02 00 00 84 01 ................
01 85 0A 00 3E 2E 81 08 8F 00 1A 00 27 86 01 00 ....>.......'...
87 01 01

Device purchased around Oct-2023

Device 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.

Using reader with a card: FS USB Token 0
3b:9f:95:81:31:fe:9f:00:66:46:53:05:10:11:31:71:df:00:00:03:90:00:a0
Sending: 00 CA 01 86 00
Received (SW1=0x90, SW2=0x00):
80 01 00 81 02 1D D5 82 01 00 83 02 00 00 84 01 ................
01 85 0A 00 6C 2F 28 1D 32 00 7F 80 20 86 01 00 ....l/(.2... ...
87 01 01

Device purchased around Jan-2023

Device chassis is purple, marked with FIPS 140-2 Level 3. These devices have been working fine for our use case. They were purchased with the instruction "None-FIPS or Standard-FIPS please".

Using reader with a card: FS USB Token 0
3b:9f:95:81:31:fe:9f:00:66:46:53:05:01:00:11:71:df:00:00:03:90:00:80
Sending: 00 CA 01 86 00
Received (SW1=0x90, SW2=0x00):
80 01 01 81 02 01 D5 82 01 04 83 02 09 00 84 01 ................
01

(not sure why the output is much shorter on this one)

$ ./opensc-tool.exe --info
OpenSC 0.21.0-0.21.0 [Microsoft 1900]
Enabled features:pcsc openssl zlib

[dengert]

@drodgers-immt Thanks for the info. I am working on a spreadsheet with all the info.

[dengert]

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 card-epass2003 and the SM code appear to use SCP01 but best I can tell SCP01 never defined how to use AES keys. I have not found yet a document on how AES could be used with SCP01. It may be only by done in epass2003.

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: /#define KEY_TYPE_AES 0x01 /* FIPS mode */ aes128_encrypt_cmac and aes128_encrypt_cmac_ft. The aes128_encrypt_cmac_ft may be to fix a specific bug with one command on some cards. So as pointed out in https://github.com/OpenSC/OpenSC/issues/3034#issuecomment-1971977426 by @faryon93.

[dengert]

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.
OpenSC debug level must be >= 5 (SC_LOG_DEBUG_SM) and to show pin processing >= 8 (SC_LOG_DEBUG_PIN)

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. @drodgers-immt's others were requested as "None-FIPS" or as a replacement where T80 == 0. card-epass2003.c if (SC_SUCCESS != get_data(card, 0x86, data, datalen)) { is the source of the Tnn numbers.

@zepingouin Your card is failing to initialize. But @drodgers-immt and @faryon93, you both say yours are failing doing sign and/or decipher. How where these initialized? By OpenSC or by Feitian code? Can you provide the commands used to initialize them? Anything you can think of that would the initialize to fail?

https://shop.ftsafe.us/products/epass2003-pki#:~:text=FEITIAN%20ePass2003%20is%20a%20FIPS,technology%20and%20standards%20available%20today. Says: "With the combined compatibility of Microsoft Minidriver and OpenSC, the ePass2003 is compatible with applications running on Windows, Linux, and Mac" Have any of you found and used a Feitian minidriver? Best I can tell it has not been updated in years.

Looking for how any of you initialized one of these tokens.

[drodgers-immt]

Hi @dengert, what I am doing is mentioned in the OP at the top of this thread. We are using OpenSC for everything.

[faryon93]

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. OpenSC debug level must be >= 5 (SC_LOG_DEBUG_SM) and to show pin processing >= 8 (SC_LOG_DEBUG_PIN)

I will pull the changes and record logs this evening and post here.

How where these initialized?

I initialized the token with your proposed workaround of commenting out the call to get_external_key_retries() https://github.com/OpenSC/OpenSC/issues/3034#issuecomment-1951434129 as this is the only failing operation (and the only operation during initialization which uses the custom C-MAC algorithm and construct_mac_tlv_case1 function). When applying your proposed changes initialization succeeds. Generating keypairs on the token or uploading keypair from host works without errors. Listing them also works. But when trying to sign some data I get the same error as @drodgers-immt reported in this issue.

By OpenSC or by Feitian code? Can you provide the commands used to initialize them?

$: pkcs15-init -E -T
$: pkcs15-init --create-pkcs15 -T -p pkcs15+onepin --pin 123456 --puk 12345678 --label "Test"

[zepingouin]

Correction, initialization worked with OpenSC 0.23.0, only sign and/or decipher failed. Otherwise, I didn't use minidriver at all. Here are the logs for:

$ /opt/local/bin/opensc-tool --info
OpenSC 0.23.0 [gcc  11.4.0]
Enabled features: locking zlib readline openssl pcsc(libpcsclite.so.1)
$ OPENSC_DEBUG=8 /opt/local/bin/pkcs15-init -E -T 2>/tmp/init_0.23.0_debug_level_8.log
$ OPENSC_DEBUG=8 /opt/local/bin/pkcs15-init --create-pkcs15 -T -p pkcs15+onepin --pin 123456 --puk 12345678 --label "Test" 2>/tmp/create_0.23.0_debug_level_8.log

Also for OPENSC_DEBUG=5:

$ /opt/ePass2003-issue/bin/opensc-tool --info
OpenSC 0.25.0-rc1 [gcc  11.4.0]
Enabled features: locking zlib readline openssl pcsc(libpcsclite.so.1)
$ OPENSC_DEBUG=8 /opt/ePass2003-issue/bin/pkcs15-init -E -T 2>/tmp/init_0.25.0-rc1_debug_level_8.log
Connecting to card in reader Feitian ePass2003 00 00...
Using card driver epass2003.
$ OPENSC_DEBUG=8 /opt/ePass2003-issue/bin/pkcs15-init --create-pkcs15 -T -p pkcs15+onepin --pin 123456 --puk 12345678 --label "Test" 2>/tmp/create_0.25.0-rc1_debug_level_8.log
Connecting to card in reader Feitian ePass2003 00 00...
Using card driver epass2003.

Also for OPENSC_DEBUG=5:

ePass2003-issue.zip

Then I applied the following patch (#3034 comment):

diff --git a/src/libopensc/card-epass2003.c b/src/libopensc/card-epass2003.c
index e66a7840..655c8e4b 100644
--- a/src/libopensc/card-epass2003.c
+++ b/src/libopensc/card-epass2003.c
@@ -3430,7 +3430,8 @@ epass2003_pin_cmd(struct sc_card *card, struct sc_pin_cmd_data *data, int *tries
                                data->pin1.len);
                LOG_TEST_RET(card->ctx, r, "verify pin failed");

-               r = get_external_key_retries(card, 0x80 | kid, &retries);
+               //r = get_external_key_retries(card, 0x80 | kid, &retries);
+               retries = 5;
                if (retries < pin_low)
                        sc_log(card->ctx, "Verification failed (remaining tries: %d)", retries);

ePass2003-issue-patched.zip

[faryon93]

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. OpenSC debug level must be >= 5 (SC_LOG_DEBUG_SM) and to show pin processing >= 8 (SC_LOG_DEBUG_PIN)

@dengert Here are my collected traces with a version built from your branch:

$: OPENSC_DEBUG=8 pkcs15-init --create-pkcs15 -T -p pkcs15+onepin --pin 123456 --puk 12345678 --label "Test"

https://pastebin.com/YvZk2Zxk (without patch)

$: OPENSC_DEBUG=12 pkcs11-tool -auth-id1 -m SHA256-RSA-PKCS --sign --label="Testkey" -i data.txt -o data.sig

https://pastes.io/otjqcddd56 (token initilized with workaround)

[dengert]

@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 3b:9f:95:81:31:fe:9f:00:66:46:53:05:10:11:31:71:df:00:00:00:00:00:33 Which is changed by OpenSC to 3b:9f:95:81:31:fe:9f:00:66:46:53:05:10:11:31:71:df:00:00:03:90:00:a0 The difference between others that work is in the TAG 81 which has 1D:D4 from

00 CA 01 86 00
80 01 01 81 02 1D D4 82 01 00 83 02 00 00 84 01 ................
01 85 0A 00 76 2E 6F 45 50 00 1A 00 28 86 01 00 ....v.oEP...(...
87 01 01 90 00 

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 OpenSC debug level should be set to 10 to pickup Secure Messaging and PIN debug info.

The main problem appear to be in get_external_key_retries, construct_mac_tlv_case1 and aes128_encrypt_cmac_ft which produce an APDU 0C 82 01 81 0A 8E 08 2C 46 5A FC 6C 83 8B 3C 00 which returns 69 88

Any other people with ideas?

[dengert]

Pushed a commit to get epass2003 past get_external_key_retries problem. https://github.com/dengert/OpenSC/commit/84ce488355a58b2e86775a2022d71cd41497992b The sign and decrypt failure may be related, and may need a similar fix.

[faryon93]

Pushed a commit to get epass2003 past get_external_key_retries problem.

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 apdu.resplen maybe not being initialized (which is indeed not initialized) and I haven't figured out why this compiler error didn't come up before as I don't see why the latest changes should trigger this kind of an error. Nevertheless we are one step closer to get the new version to work, thank you! :+1:

[zepingouin]

No compiler error, your commit successfully initialized the token, thanks @dengert for the work! 👍

[dengert]

@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. @drodgers-immt @faryon93 @zepingouin can you verify EC works. You will need https://github.com/dengert/OpenSC/commit/84ce488355a58b2e86775a2022d71cd41497992b which has not changed. (although the following are from a hacked up version.)

./pkcs15-init --verify-pin -G EC:nistp256 --id 02 --key-usage sign --auth-id 01 --label "Key02"
echo "test data" > /tmp/data.txt
./pkcs11-tool --sign --id 02 -m ECDSA-SHA256 --input /tmp/data.txt --output-file /tmp/signature
./pkcs11-tool --verify --id 02 -m ECDSA-SHA256 --input /tmp/data.txt --signature-file /tmp/signature

The problems is with RSA 2048 bit keys, require more then 256 bytes of data need to be sent to the card. The code will then use extended APDUs which get a 69 88 error code with the FIPS tokens. This error message says the MAC does not agree with what is expected.

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.

[zepingouin]

I confirm @dengert , EC sign/verify works . Good job 👍

$ /opt/ePass2003-issue/bin/pkcs15-init -E -T
Using reader with a card: Feitian ePass2003 00 00
$ /opt/ePass2003-issue/bin/pkcs15-init --create-pkcs15 -T -p pkcs15+onepin --pin 123456 --puk 12345678 --label "Test"
Using reader with a card: Feitian ePass2003 00 00
$ /opt/ePass2003-issue/bin/pkcs15-init --pin 123456 -G EC:nistp256 --id 01 --key-usage sign --auth-id 01 --label "Key01"
Using reader with a card: Feitian ePass2003 00 00
$ /opt/ePass2003-issue/bin/pkcs11-tool --sign --id 01 -m ECDSA-SHA256 --pin 123456 --input signing-test.bin --output-file signing-test.bin.sig
Using slot 0 with a present token (0x0)
Using signature algorithm ECDSA-SHA256
$ /opt/ePass2003-issue/bin/pkcs11-tool --verify --id 01 -m ECDSA-SHA256 --input signing-test.bin --signature-file signing-test.bin.sig
Using slot 0 with a present token (0x0)
Using signature algorithm ECDSA-SHA256
Signature is valid

[faryon93]

Hi @dengert, I just tried sign/verify with EC and it works flawlessly. Thank you for all your support :)

$: pkcs15-init --verify-pin -G EC:nistp256 --id 02 --key-usage sign --auth-id 01 --label "Key02"                                                                                                                        Using reader with a card: Feitian ePass2003 00 00
User PIN required.
Please enter User PIN [User PIN]: 

$: echo "test data" > /tmp/data.txt                                                                                                                                                                                    

$: pkcs11-tool --sign --id 02 -m ECDSA-SHA256 --input /tmp/data.txt --output-file /tmp/signature                                                                                                                        
Using slot 0 with a present token (0x0)
Logging in to "Test (User PIN)".
Please enter User PIN: 
Using signature algorithm ECDSA-SHA256

$: pkcs11-tool --verify --id 02 -m ECDSA-SHA256 --input /tmp/data.txt --signature-file /tmp/signature                                                                                                                Using slot 0 with a present token (0x0)
Using signature algorithm ECDSA-SHA256
Signature is valid

[zepingouin]

Hi @dengert , To temper the joy, this was already working with OpenSC 0.23.0:

$ /opt/local/bin/opensc-tool --info
OpenSC 0.23.0 [gcc  11.4.0]
Enabled features: locking zlib readline openssl pcsc(libpcsclite.so.1)
$ /opt/local/bin/pkcs15-init -E -T
Using reader with a card: Feitian ePass2003 00 00
$ /opt/local/bin/pkcs15-init --create-pkcs15 -T -p pkcs15+onepin --pin 123456 --puk 12345678 --label "Test"
Using reader with a card: Feitian ePass2003 00 00
$ /opt/local/bin/pkcs15-init --pin 123456 -G EC:nistp256 --id 01 --key-usage sign --auth-id 01 --label "Key01"
Using reader with a card: Feitian ePass2003 00 00
$ /opt/local/bin/pkcs11-tool --sign --id 01 -m ECDSA-SHA256 --pin 123456 --input signing-test.bin --output-file signing-test.bin.sig
Using slot 0 with a present token (0x0)
Using signature algorithm ECDSA-SHA256
$ /opt/local/bin/pkcs11-tool --verify --id 01 -m ECDSA-SHA256 --input signing-test.bin --signature-file signing-test.bin.sig
Using slot 0 with a present token (0x0)
Using signature algorithm ECDSA-SHA256
Signature is valid

[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: https://github.com/OpenSC/OpenSC/issues/2843

I am seeking technical information so OpenSC (or Feitian developers) can address the problem.

ECDSA p-256 works with one minor change: https://github.com/OpenSC/OpenSC/commit/84ce488355a58b2e86775a2022d71cd41497992b

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:

ATR:3b:9f:95:81:31:fe:9f:00:66:46:53:05:10:11:31:71:df:00:00:00:00:00:33
Tag 80 01 01
Tag 81 02 1D D4
Tag 87 01 01 

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): 80 01 01 81 02 1D D4 82 01 00 83 02 00 00 84 01 ................ 01 85 0A 00 F9 2E 6F 45 50 00 1A 00 28 86 01 00 ......oEP...(... 87 01 01 90 00

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

[dengert]

See #3203 and https://github.com/OpenSC/OpenSC/issues/3034#issuecomment-2233366869