epass2003 elliptic cryptography support

[popovec]

Problem Description

I have epass2003 token:

$ pkcs11-tool -T
Available slots:
Slot 0 (0x4): Feitian ePass2003 00 00
  token label        : OpenSC Card (User PIN)
  token manufacturer : EnterSafe
  token model        : PKCS#15
  token flags        : login required, rng, token initialized, PIN initialized
  hardware version   : 0.0
  firmware version   : 0.0
  serial num         : 3307011617051201
  pin min/max        : 4/16

according to OpenSC, this token supports elliptic encryption:

pkcs11-tool -M
Using slot 1 with a present token (0x4)
Supported mechanisms:
  SHA-1, digest
  SHA224, digest
  SHA256, digest
  SHA384, digest
  SHA512, digest
  MD5, digest
  RIPEMD160, digest
  GOSTR3411, digest
  ECDSA, keySize={256,256}, hw, sign, verify
  ECDSA-SHA224, keySize={256,256}, sign, verify
  ECDSA-SHA384, keySize={256,256}, sign, verify
  ECDSA-SHA512, keySize={256,256}, sign, verify
  ECDSA-SHA1, keySize={256,256}, hw, sign, verify
  ECDSA-SHA256, keySize={256,256}, hw, sign, verify
  ECDSA-KEY-PAIR-GEN, keySize={256,256}, hw, generate_key_pair
  RSA-X-509, keySize={512,2048}, hw, decrypt, sign, verify
.
.
.  (snipped)

An attempt to generate a key ends with an error:

$ pkcs15-init --generate-key ec/prime256v1 --pin 1234 --auth-id 01
Using reader with a card: Feitian ePass2003 00 00
Failed to generate key: Incorrect parameters in APDU

I assume that from the information about the token it is possible to correctly generate whether the token has/does not support elliptic encryption.

My token lists the following parameters:

00 CA 01 86 00
80 01 01 81 02 1D D5 82 01 03 90 00

I found several other answers to this APDU in logs available on the Internet, the answer is TLV organized.

I tried to deduce from the epass2003 driver in OpenSC which TAG corresponds to what, but without further help I cannot find which TAG signals support for elliptical encryption. Analysis of the relevant tags is available in my epass2003 simulator:

https://github.com/popovec/epass2003_sim/blob/main/epass2003_doc/get_data.txt

Can anyone help me with information about this problem?

[popovec]

If anyone can advise, there is also a question regarding longer RSA keys (4096...) ... #1736 (comment)

[Jakuje]

My output:

./src/tools/pkcs11-tool -T --module ./src/pkcs11/.libs/opensc-pkcs11.so 
Available slots:
Slot 0 (0x0): Feitian ePass2003 00 00
  token label        : OpenSC Card (User PIN)
  token manufacturer : EnterSafe
  token model        : PKCS#15
  token flags        : login required, rng, token initialized, PIN initialized
  hardware version   : 0.0
  firmware version   : 0.0
  serial num         : 2cb8042680198009

My response is

Outgoing APDU (5 bytes):
00 CA 01 86 00 .....

P:2283567; T:0x140649322143232 13:47:28.540 [opensc-pkcs11] reader-pcsc.c:244:pcsc_internal_transmit: called
P:2283567; T:0x140649322143232 13:47:28.541 [opensc-pkcs11] reader-pcsc.c:335:pcsc_transmit:•
Incoming APDU (34 bytes):
80 01 01 81 02 1D D5 82 01 00 83 02 00 00 84 01 ................
01 85 0A 00 58 2C B8 04 26 80 19 80 09 86 01 00 ....X,..&.......
90 00                                           ..

decoded as follows:

80 01 01
81 02 1D D5
82 01 00
83 02 00 00
84 01 01
85 0A 00 58 2C B8 04 26 80 19 80 09
86 01 00

but I do not know if I can shed more light into what these mean.

But I went ahead to see if the FIPS certification does not "leak" some info and it does:
https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp3202.pdf

See table 4:

• Tag 80: value 0x01 stands for FIPS Approved Mode
• Tag 81: the value of each two bits of bit0‐‐‐‐bit13 correspond to 3DES, AES, RSA Pub, RSA
  Pri, ECC Pub and ECC Pri, and it also indicates whether these keys can be imported and exported.
• Tag 82 and 82: Reserved
• Tag 84: ciphertext communication -- sounds like SM to me

I think this should be enough to get the algorithm support for the epass driver.

Regarding to the 4k RSA support, the nist certificate does not say anything about that and only 2k keys are "certified".

Thats probably the only useful part in the document for me now. But there is also description of the operations which might come handy too in the end.

[popovec]

Thanks for the information and the link to the document. I'm trying to understand where the problem is. My token returns the following info:

Outgoing APDU (5 bytes):
00 CA 01 86 00 .....
P:150126; T:0x139718643613184 15:34:11.336 [pkcs15-tool] reader-pcsc.c:244:pcsc_internal_transmit: called
P:150126; T:0x139718643613184 15:34:11.337 [pkcs15-tool] reader-pcsc.c:335:pcsc_transmit: 
Incoming APDU (12 bytes):
80 01 01 81 02 1D D5 82 01 03 90 00 ............

The token I have returns exactly the same information for TAG 0x81 as your token = 1D D5.

I would assume that both have support for ECDSA, but my attempt to generate a key goes like this:

OPENSC_DEBUG=255 pkcs15-init --generate-key ec/prime256v1 -a 01 -i 03 --pin 123456

Outgoing APDU (35 bytes):
0C 46 00 00 1D 87 11 01 FD 01 D6 EE 29 CC C0 4D .F..........)..M
29 11 E7 EF 98 D2 83 54 8E 08 96 5D 12 3C 28 4C )......T...].<(L
07 EF 00                                        ...

P:150433; T:0x139811876240896 15:39:50.690 [pkcs15-init] reader-pcsc.c:244:pcsc_internal_transmit: called
P:150433; T:0x139811876240896 15:39:50.719 [pkcs15-init] reader-pcsc.c:335:pcsc_transmit: 
Incoming APDU (16 bytes):
99 02 6A 80 8E 08 03 B9 EA 2D CC BB 89 F7 6A 80 ..j......-....j.

P:150433; T:0x139811876240896 15:39:50.719 [pkcs15-init] apdu.c:382:sc_single_transmit: returning with: 0 (Success)
P:150433; T:0x139811876240896 15:39:50.719 [pkcs15-init] apdu.c:539:sc_transmit: returning with: 0 (Success)
P:150433; T:0x139811876240896 15:39:50.719 [pkcs15-init] card.c:523:sc_unlock: called
P:150433; T:0x139811876240896 15:39:50.719 [pkcs15-init] card-epass2003.c:1558:epass2003_sm_free_wrapped_apdu: called
P:150433; T:0x139811876240896 15:39:50.720 [pkcs15-init] card-epass2003.c:1518:epass2003_sm_unwrap_apdu: called
P:150433; T:0x139811876240896 15:39:50.720 [pkcs15-init] card-epass2003.c:256:epass2003_check_sw: Incorrect parameters in the data field
P:150433; T:0x139811876240896 15:39:50.720 [pkcs15-init] card-epass2003.c:1544:epass2003_sm_unwrap_apdu: unwrapped APDU: resplen 0, SW 6A80

[Jakuje]

Sounds like you are right. Could it be some defective/old/pre-production token?

The SW1 6A 80 is wrong parameters in data, which points to the data field of the APDU (which is proprietary). The rest of the return data sounds like proprietary according to the ISO specs so I am not sure if there is something more we can get from that.

In any case, if you will need to run/test something on a newer epass token, please let me know. I got some recently from Feitian.

[popovec]

I received that token as a gift in 2017, a colleague bought about 5 of them, but they were never used. I don't think that it was a pre-production or test tokens. I will check with him more precisely the origin of these tokens.

The proprietary APDU is like this: 00 46 00 00 07 02 29 00 30 00 (wrapped in SM, tag 0x087, original data field padded and encrypted by AES-CBC and tag 0x8e - MAC (AES-CBC_MAC) ). Details: 02 - EC key, 2900 ID of the private key file, 3000 is the ID of the public key file. The response is classic SM, where the return code is 6a80 in TLV - TAG 0x99, and another TLV with tag 0x8e as MAC for this response.

Too bad the token you got from Feitian doesn't support MAC in AES_CMAC mode (it should report TAG 0x87 with value 1 in response for get capabilities..). I wanted to try it first because we don't have a MAC verification code for this mode in the card driver.

OpenSC/src/libopensc/card-epass2003.c

Lines 1381 to 1385 in 33351d9

	/* no documentation/real hardware to test, the response is accepted without MAC check */
	if (exdata->bFipsCertification) {
	sc_log(card->ctx, "Warning, MAC is not checked");
	return 0;
	}

Anyway, your token at least supports Elliptical operations, so you can test what my token does not support.

If you have an EC key generated on the token, you can try the test script: https://github.com/popovec/epass2003_sim/blob/main/tests/ec_sign_test.sh

I assume that ECDSA operations with SHA384 and SHA512 will fail on your token. It should be possible to solve it by adding the code that allows to perform the operation SC_ALGORITHM_ECDSA_RAW. (you can find the patch proposal in my analysis of the EC operation for the epass2003 token available at https://github.com/popovec/epass2003_sim/blob/main/epass2003_doc/EC.txt )

Thank you.

[dengert]

The proprietary APDU is like this: 00 46 00 00 07 02 29 00 30 00

The Lc=7 does not match the 5 bytes. Is that a misprint?https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-epass2003.c#L3037-L3055
would have added the len=256: 00 46 00 00 07 02 01 00 29 00 30 00

The epass2003 I have was obtained from Gooze in 2014.
They also provided a CD with does does not talk about EC. All the files on the CD are from 2011. The OpenSC source they provided was from opensc-0.12.2.tar.gz from 7/15/2011.

apdu: 00 CA 01 86 00
returns:
80 01 01 81 02 1D D5 82 01 03 90 00
The same as @popovec

So does not have tags 83, 84, 85 or 86

https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-epass2003.c#L1724-L1748
appear to not parse the get_data response but expects tags at specific offsets.

Note lines 1731-1732:

if(memcmp(&data[32],"\x87\x01\x01" , 3)==0 && memcmp(&data[0],"\x80\x01\x01", 3)==0){
           exdata->bFipsCertification = 0x01;

Also note line 1772:

flags = SC_ALGORITHM_ONBOARD_KEY_GEN|SC_ALGORITHM_ECDSA_HASH_SHA1|SC_ALGORITHM_ECDSA_HASH_SHA256|SC_ALGORITHM_ECDSA_HASH_NONE|SC_ALGORITHM_ECDSA_RAW;

Does the card actually support SC_ALGORITHM_ECDSA_HASH_SHA1?

pkcs11-tool -M shows these EC mechanisms:
ECDSA, keySize={256,256}, hw, sign, verify
ECDSA-SHA224, keySize={256,256}, sign, verify
ECDSA-SHA384, keySize={256,256}, sign, verify
ECDSA-SHA512, keySize={256,256}, sign, verify
ECDSA-SHA1, keySize={256,256}, hw, sign, verify
ECDSA-SHA256, keySize={256,256}, hw, sign, verify
ECDSA-KEY-PAIR-GEN, keySize={256,256}, hw, generate_key_pair

I will try and generate an EC key later today.

[dengert]

./pkcs15-init --generate-key ec/prime256v1 -a 01 -i 03 --pin XXXXXXXX gives the same
99 02 6A 80 8E 08 58 CD D3 B4 32 D1 4F F4 6A 80 response.

This card may be too old to do EC. Note different ATR in comment:
https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-epass2003.c#L50-L59

My card has ATR: 3b:9f:95:81:31:fe:9f:00:66:46:53:05:01:00:11:71:df:00:00:03:90:00:80

This is not the only OpenSC card driver's "init" routine that does not check version numbers of the token and sets all the flags, capabilities, key types and sizes to latest version of the token.

[dengert]

ECDSA support was added to OpenSC c34caeb in 2010-11-30 which Precedes: 0.12.2-rc1. The first card to use it was PIV c2fe460

ECDSA was first added to card-epass2003.c 8d73464 2017-09-04.

So I strongly doubt the older epass2003 cards support ECDSA.

[popovec]

The proprietary APDU is like this: 00 46 00 00 07 02 29 00 30 00

@dengert you are right .. I quickly copied this from my notes. There should be one more piece of information - how many bits the generated key should have:
00 46 00 00 07
02 => EC key or 01 RSA key
0100 => 256 for EC key secp256r1
2900 => ID of private key file
3000 => ID of public key file

I also discovered the origin of the key, it also comes from Gooze, but from around October 2012.

Thanks for the hint about the ATR version, it would probably be appropriate to take firmware version from ATR (historical bytes, tag 6) ?

[dengert]

it would probably be appropriate to take firmware version from ATR (historical bytes, tag 6) ?

Yes, but do we know all the different versions that may have been produced and what has changed over the years?
The vendor would know. But AFASK there have been 3 vendors, and in was never obvious what Gooze did with the tokens. Did then change the applet or the ATR?