pkcs11-tool --login --test fails with C_Verify() returned CKR_GENERAL_ERROR (0x5) with CardOS 5.3

[Silvanoc]

Problem Description

I have a smartcard with **CardOS 5.**3 that is failing to verify signatures created with the card.

Following works:

• Decrypting e-mails with Evolution.
• Authentication with Firefox and Chromium.

Following doesn't:

• Test the card with pkcs11-tool --login --test (fails with RSA-PKCS: ERR: C_Verify() returned CKR_GENERAL_ERROR (0x5)).
• Sign with pkcs11-tool --sign -m SHA1-RSA-PKCS ... and verify with openssl dgst -keyform PEM -verify $SIGN_KEY.pub -sha1 ....
• Sign and verify programmatically via PyKCS11 or python-pkcs11.

Proposed Resolution

Steps to reproduce

Logs

Extract of the output filtering only "key 0".

Signatures (currently only for RSA)
  testing key 0 (Auth 12.11.18 10:09:10 - 12.11.21) 
  all 4 signature functions seem to work
  testing signature mechanisms:
    RSA-PKCS: ERR: verification failed
    SHA1-RSA-PKCS: ERR: verification failed
    MD5-RSA-PKCS: ERR: verification failed
    RIPEMD160-RSA-PKCS: ERR: verification failed
    SHA256-RSA-PKCS: ERR: verification failed
Verify (currently only for RSA)
  testing key 0 (Auth 12.11.18 10:09:10 - 12.11.21)
    RSA-PKCS:   ERR: C_Verify() returned CKR_GENERAL_ERROR (0x5)

More verbose output can be provided, but filtering out certificates and pins from a 12kL document is too cumbersome. Any specific portion needed?

[frankmorgner]

use gist, pastebin or similar to provide a log (remove your PIN first!)

[frankmorgner]

It could indeed be your certificate that's the problem...

@Jakuje ?

[frankmorgner]

In #1918, 642a3ee was identified as being problematic

[Silvanoc]

use gist, pastebin or similar to provide a log (remove your PIN first!)

Removing the PIN is easy (sed -i 's/<PIN>/XXX/'). But making sure that there are no other sensitive data in the rest of the 12kL log that I get with debug level 3 is a different story...

[loblik]

I've just noticed that adding SC_ALGORITHM_RSA_RAW back to the flags solves the issue for me. But I have no idea if it's right or not.

This is one of the flags removed in 642a3ee .

--- a/src/libopensc/card-cardos.c
+++ b/src/libopensc/card-cardos.c
@@ -173,7 +173,7 @@ static int cardos_init(sc_card_t *card)
        /* Set up algorithm info. */
        flags = 0;
        if (card->type == SC_CARD_TYPE_CARDOS_V5_0) {
-               flags |= SC_ALGORITHM_RSA_PAD_PKCS1;
+               flags |= SC_ALGORITHM_RSA_PAD_PKCS1 | SC_ALGORITHM_RSA_RAW;
        } else {
                flags |= SC_ALGORITHM_RSA_RAW
                        | SC_ALGORITHM_RSA_HASH_NONE

[fbezdeka]

Same here.
I reverted the flags part of 642a3ee and it works again.

[fbezdeka]

• SC_ALGORITHM_RSA_RAW seems to be required
• SC_ALGORITHM_RSA_PAD_PKCS1 produces 4 more errors when running pkcs11-tool --login --test

Maybe @Jakuje (author of 642a3ee) can tell us if it is really needed / the right flags.

[fbezdeka]

This one works with

• CardOS 5.3 (8 errors)
• CardOS 4.2c (no errors)

--- a/src/libopensc/card-cardos.c
+++ b/src/libopensc/card-cardos.c
@@ -171,15 +171,13 @@ static int cardos_init(sc_card_t *card)
        card->cla = 0x00;
 
        /* Set up algorithm info. */
-       flags = 0;
-       if (card->type == SC_CARD_TYPE_CARDOS_V5_0) {
+       if (card->type == SC_CARD_TYPE_CARDOS_V5_0)  
                flags |= SC_ALGORITHM_RSA_PAD_PKCS1;
-       } else {
-               flags |= SC_ALGORITHM_RSA_RAW
-                       | SC_ALGORITHM_RSA_HASH_NONE
-                       | SC_ALGORITHM_NEED_USAGE
-                       | SC_ALGORITHM_ONBOARD_KEY_GEN;
-       }
+
+       flags |= SC_ALGORITHM_RSA_RAW
+               | SC_ALGORITHM_RSA_HASH_NONE
+               | SC_ALGORITHM_NEED_USAGE
+               | SC_ALGORITHM_ONBOARD_KEY_GEN;

[Jakuje]

As the #1867 (and several issues before) say, the CardOS 5 really does not support raw RSA operations. As the attached output in the above PR says, it works fine with my CardOS 5 card. If it does not for your card, please, provide a trace at least with the logs around the error you are getting. The PIN is in the trace visible only in the APDU (hexadecimal, ascii).

Last comment from @fbezdeka indeed says that with reverting this patch, introduces some errors in the tests (but does not clarify which ones) so clarifying this would be also useful.

[fbezdeka]

Providing a trace seems to be quite hard for me.
The trace contains too many certificate data. Too many things can be extracted from there so blasting out this information to the public is not an option.

Any chance to identify the really important part(s) of the trace?

The following patch is fine (=no errors) for CardOS 4.2c and produces 4 errors on CardOS 5.
The number of failing tests was reduced to 4 by removing SC_ALGORITHM_RSA_PAD_PKCS1 from the flags.

--- a/src/libopensc/card-cardos.c
+++ b/src/libopensc/card-cardos.c
@@ -171,15 +171,10 @@ static int cardos_init(sc_card_t *card)
        card->cla = 0x00;
 
        /* Set up algorithm info. */
-       flags = 0;
-       if (card->type == SC_CARD_TYPE_CARDOS_V5_0) {
-               flags |= SC_ALGORITHM_RSA_PAD_PKCS1;
-       } else {
-               flags |= SC_ALGORITHM_RSA_RAW
-                       | SC_ALGORITHM_RSA_HASH_NONE
-                       | SC_ALGORITHM_NEED_USAGE
-                       | SC_ALGORITHM_ONBOARD_KEY_GEN;
-       }
+       flags |= SC_ALGORITHM_RSA_RAW
+               | SC_ALGORITHM_RSA_HASH_NONE
+               | SC_ALGORITHM_NEED_USAGE
+               | SC_ALGORITHM_ONBOARD_KEY_GEN;
 
        if (card->type == SC_CARD_TYPE_CARDOS_M4_2) {
                r = cardos_have_2048bit_package(card);

pkcs11-tool --login --test
Using slot 0 with a present token (0x0)
Logging in to "Siemens Corporate ID Card (V5)".
Please enter User PIN: 
...
... <ALL OK>
...
Decryption (currently only for RSA)
  testing key 0 (Encr 10.05.17 09:32:43 - 10.05.20)
    RSA-X-509: resulting cleartext doesn't match input
    Original: 00 7c c0 7c bb 22 fc e4 66 da 61 0b 63 af 62 bc 83 b4 69 2f 3a ff af 27 16 93 ac 07 1f b8 6d 11 34 2d 8d ef 4f 89 d4 b6 63 35 c1 c7 e4 24 83 67 d8 ed 96 12 ec 45 39 02 d8 e5 0a f8 9d 77 09 d1 a5 96 c1 f4 1f 95 aa 82 ca 6c 49 ae 90 cd 16 68 ba ac 7a a6 f2 b4 a8 ca 99 b2 c2 37 2a cb 08 cf 61 c9 c3 80 5e 6e 03 28 da 4c d7 6a 19 ed d2 d3 99 4c 79 8b 00 22 56 9a d4 18 d1 fe e4 d9 cd 45 a3 91 c6 01 ff c9 2a d9 15 01 43 2f ee 15 02 87 61 7c 13 62 9e 69 fc 72 81 cd 71 65 a6 3e ab 49 cf 71 4b ce 3a 75 a7 4f 76 ea 7e 64 ff 81 eb 61 fd fe c3 9b 67 bf 0d e9 8c 7e 4e 32 bd f9 7c 8c 6a c7 5b a4 3c 02 f4 b2 ed 72 16 ec f3 01 4d f0 00 10 8b 67 cf 99 50 5b 17 9f 8e d4 98 0a 61 03 d1 bc a7 0d be 9b bf ab 0e d5 98 01 d6 e5 f2 d6 f6 7d 3e c5 16 8e 21 2e 2d af 02 c6 b9 63 c9 8a
    Decrypted: 7c c0 7c bb 22 fc e4 66 da 61 0b 63 af 62 bc 83 b4 69 2f 3a ff af 27 16 93 ac 07 1f b8 6d 11 34 2d 8d ef 4f 89 d4 b6 63 35 c1 c7 e4 24 83 67 d8 ed 96 12 ec 45 39 02 d8 e5 0a f8 9d 77 09 d1 a5 96 c1 f4 1f 95 aa 82 ca 6c 49 ae 90 cd 16 68 ba ac 7a a6 f2 b4 a8 ca 99 b2 c2 37 2a cb 08 cf 61 c9 c3 80 5e 6e 03 28 da 4c d7 6a 19 ed d2 d3 99 4c 79 8b 00 22 56 9a d4 18 d1 fe e4 d9 cd 45 a3 91 c6 01 ff c9 2a d9 15 01 43 2f ee 15 02 87 61 7c 13 62 9e 69 fc 72 81 cd 71 65 a6 3e ab 49 cf 71 4b ce 3a 75 a7 4f 76 ea 7e 64 ff 81 eb 61 fd fe c3 9b 67 bf 0d e9 8c 7e 4e 32 bd f9 7c 8c 6a c7 5b a4 3c 02 f4 b2 ed 72 16 ec f3 01 4d f0 00 10 8b 67 cf 99 50 5b 17 9f 8e d4 98 0a 61 03 d1 bc a7 0d be 9b bf ab 0e d5 98 01 d6 e5 f2 d6 f6 7d 3e c5 16 8e 21 2e 2d af 02 c6 b9 63 c9 8a
    RSA-PKCS: OK
  testing key 1 (Encr 09.01.13 11:25:12 - 09.01.14)
    RSA-X-509: resulting cleartext doesn't match input
    Original: 00 46 8b 27 cd a3 58 3b 97 e3 16 14 e2 f8 28 92 46 7a 40 ff 32 67 12 79 cb 8e 62 02 39 10 72 45 56 fd 6c 23 a0 c4 5e 38 a7 75 4c 89 6d 74 1b b3 ef 5b b2 21 c2 c5 9a 8e 53 fd 90 8c 0d 03 d1 63 00 3d 86 a1 01 e4 d9 a8 59 25 31 c7 9a 4c 7a 89 a7 2d aa 6a f2 44 f8 45 41 88 d1 4e 8b a3 b1 8c e0 37 2d e2 1c 06 8a 75 2b bc 3c c5 08 b7 4e b0 e4 f8 1a d6 3d 12 1b 7e 9a ec cd 26 8f 7e b2 70 b6 df 52 d2 e5 dc 47 10 98 84 d6 a1 3b 24 51 1f 1d 6b f5 5a 7d 10 d8 17 fc a5 3d 8c 24 ef fc da ce 4e ac b3 2a f3 c4 c3 77 9a 64 b2 be b5 d1 db 20 c6 35 9d d6 0e b4 d3 b3 f2 5f d7 e1 5b b1 b0 a9 5d 63 d3 51 27 96 c8 c1 fa 7b 80 af 4c 5b cf 13 91 6c e9 9f 21 bc 52 13 1b 2a f4 76 db a4 1f 39 08 f3 8a 2f 89 52 f1 84 cd 71 33 1a cc 03 2d 5d 6f 16 fc 90 d3 4f a3 ee 79 98 65 54 3c 84 8d
    Decrypted: 46 8b 27 cd a3 58 3b 97 e3 16 14 e2 f8 28 92 46 7a 40 ff 32 67 12 79 cb 8e 62 02 39 10 72 45 56 fd 6c 23 a0 c4 5e 38 a7 75 4c 89 6d 74 1b b3 ef 5b b2 21 c2 c5 9a 8e 53 fd 90 8c 0d 03 d1 63 00 3d 86 a1 01 e4 d9 a8 59 25 31 c7 9a 4c 7a 89 a7 2d aa 6a f2 44 f8 45 41 88 d1 4e 8b a3 b1 8c e0 37 2d e2 1c 06 8a 75 2b bc 3c c5 08 b7 4e b0 e4 f8 1a d6 3d 12 1b 7e 9a ec cd 26 8f 7e b2 70 b6 df 52 d2 e5 dc 47 10 98 84 d6 a1 3b 24 51 1f 1d 6b f5 5a 7d 10 d8 17 fc a5 3d 8c 24 ef fc da ce 4e ac b3 2a f3 c4 c3 77 9a 64 b2 be b5 d1 db 20 c6 35 9d d6 0e b4 d3 b3 f2 5f d7 e1 5b b1 b0 a9 5d 63 d3 51 27 96 c8 c1 fa 7b 80 af 4c 5b cf 13 91 6c e9 9f 21 bc 52 13 1b 2a f4 76 db a4 1f 39 08 f3 8a 2f 89 52 f1 84 cd 71 33 1a cc 03 2d 5d 6f 16 fc 90 d3 4f a3 ee 79 98 65 54 3c 84 8d
    RSA-PKCS: OK
  testing key 2 (Encr 13.02.12 11:20:05 - 13.02.13)
    RSA-X-509: resulting cleartext doesn't match input
    Original: 00 03 e6 7f 23 18 82 85 29 a1 40 fc ff 37 2a a0 8a 65 f3 ed 86 78 f0 74 e1 72 b2 a1 0e 63 00 1a 66 e6 9a 8a fe 1c 0f 28 bd 4f 24 bc 86 4e 5c 11 b3 4f fe 3a c8 ee ae a9 60 60 4b 6e c3 4b 88 29 31 22 b3 30 3e c2 58 fb 12 7c b7 98 ca 14 a9 7d 63 a7 b7 2b 95 65 d5 f5 c5 20 63 88 6b ec b2 9c 0e 65 cc 4d 28 24 48 3a a0 00 d2 6a 14 7c e8 77 23 9f a3 b9 05 78 ae ca 98 12 53 03 fe 05 9f 0c 6a 6c 59 92 90 a2 cc 31 a2 9f 9b b6 1b 83 2d 3e 23 d0 f7 28 48 a6 f2 e0 b8 45 e3 b6 4a 83 c2 b5 ef 1c 47 7f be 14 b0 60 b3 4c 16 ce cf 43 0c f2 14 04 1a 5c aa 0d 3d 62 52 20 18 9d a3 da 52 92 f6 99 12 b4 ad c2 14 60 0e 2a 2e de 6e 3b d0 82 3f eb de e9 f8 1b 4b 4a 3c 63 e7 df 3d 39 72 34 d3 84 e8 80 46 fd e1 55 27 0f 33 95 4a 03 17 89 ee f6 72 e6 11 bd 31 4d 20 18 2d 5e 52 9f 92 25
    Decrypted: 03 e6 7f 23 18 82 85 29 a1 40 fc ff 37 2a a0 8a 65 f3 ed 86 78 f0 74 e1 72 b2 a1 0e 63 00 1a 66 e6 9a 8a fe 1c 0f 28 bd 4f 24 bc 86 4e 5c 11 b3 4f fe 3a c8 ee ae a9 60 60 4b 6e c3 4b 88 29 31 22 b3 30 3e c2 58 fb 12 7c b7 98 ca 14 a9 7d 63 a7 b7 2b 95 65 d5 f5 c5 20 63 88 6b ec b2 9c 0e 65 cc 4d 28 24 48 3a a0 00 d2 6a 14 7c e8 77 23 9f a3 b9 05 78 ae ca 98 12 53 03 fe 05 9f 0c 6a 6c 59 92 90 a2 cc 31 a2 9f 9b b6 1b 83 2d 3e 23 d0 f7 28 48 a6 f2 e0 b8 45 e3 b6 4a 83 c2 b5 ef 1c 47 7f be 14 b0 60 b3 4c 16 ce cf 43 0c f2 14 04 1a 5c aa 0d 3d 62 52 20 18 9d a3 da 52 92 f6 99 12 b4 ad c2 14 60 0e 2a 2e de 6e 3b d0 82 3f eb de e9 f8 1b 4b 4a 3c 63 e7 df 3d 39 72 34 d3 84 e8 80 46 fd e1 55 27 0f 33 95 4a 03 17 89 ee f6 72 e6 11 bd 31 4d 20 18 2d 5e 52 9f 92 25
    RSA-PKCS: OK
  testing key 3 (Auth 27.08.17 20:34:39 - 01.01.01)
    RSA-X-509: resulting cleartext doesn't match input
    Original: 00 08 89 95 20 86 11 37 75 4a 3f 8a 67 77 40 14 af fb a0 93 2b 77 e8 97 2c b4 02 27 6f 88 7d ae 90 06 43 b1 8c 54 e8 01 9e 28 8c 05 9f cc 19 4e c7 b9 e2 f2 31 ca 89 5d 7f 8c 84 ee 14 02 9c a5 08 df 56 95 34 3e 96 d2 66 22 d8 06 ee f1 54 b6 ab 36 a8 dc 01 32 39 80 be be 6e d2 c0 0a 77 c8 e9 cd 5d 1d 0c f4 f0 72 16 c8 78 05 b9 cd bb 64 03 63 40 04 95 7a 84 53 38 f2 26 f8 fc 9d c0 e6 6b 1e 03 77 12 f3 e9 28 bb 62 2d 75 2f e8 d9 32 4c 1a 37 e1 94 bb 35 cc ae 5b c4 aa f8 84 90 63 a2 94 da b4 87 c4 dd 43 26 0a b8 55 f3 91 87 3f ab be 20 3f 7a 55 0b 28 b0 cf d2 a9 54 63 0c f6 f7 e7 ab 7e ab 88 c1 d1 92 79 26 85 0b ad c4 b6 6c e5 f6 e6 3a 01 0e eb d1 e0 94 25 43 a0 1b 3a 87 c6 b9 32 4e 7a 03 e1 f4 29 66 ff d7 2b b5 43 10 ab 29 4a ad 37 35 7e 17 c9 a3 5b 6a be 95 f1
    Decrypted: 08 89 95 20 86 11 37 75 4a 3f 8a 67 77 40 14 af fb a0 93 2b 77 e8 97 2c b4 02 27 6f 88 7d ae 90 06 43 b1 8c 54 e8 01 9e 28 8c 05 9f cc 19 4e c7 b9 e2 f2 31 ca 89 5d 7f 8c 84 ee 14 02 9c a5 08 df 56 95 34 3e 96 d2 66 22 d8 06 ee f1 54 b6 ab 36 a8 dc 01 32 39 80 be be 6e d2 c0 0a 77 c8 e9 cd 5d 1d 0c f4 f0 72 16 c8 78 05 b9 cd bb 64 03 63 40 04 95 7a 84 53 38 f2 26 f8 fc 9d c0 e6 6b 1e 03 77 12 f3 e9 28 bb 62 2d 75 2f e8 d9 32 4c 1a 37 e1 94 bb 35 cc ae 5b c4 aa f8 84 90 63 a2 94 da b4 87 c4 dd 43 26 0a b8 55 f3 91 87 3f ab be 20 3f 7a 55 0b 28 b0 cf d2 a9 54 63 0c f6 f7 e7 ab 7e ab 88 c1 d1 92 79 26 85 0b ad c4 b6 6c e5 f6 e6 3a 01 0e eb d1 e0 94 25 43 a0 1b 3a 87 c6 b9 32 4e 7a 03 e1 f4 29 66 ff d7 2b b5 43 10 ab 29 4a ad 37 35 7e 17 c9 a3 5b 6a be 95 f1
    RSA-PKCS: OK
4 errors

[fbezdeka]

As pointed out earlier my/our cards require SC_ALGORITHM_RSA_RAW to be set.

Otherwise we would fail this way (see initial bug description):

Signatures (currently only for RSA)
  testing key 0 (Encr 10.05.17 09:32:43 - 10.05.20) 
  all 4 signature functions seem to work
  testing signature mechanisms:
    RSA-PKCS: ERR: verification failed
    SHA1-RSA-PKCS: ERR: verification failed
    MD5-RSA-PKCS: ERR: verification failed
    RIPEMD160-RSA-PKCS: ERR: verification failed
    SHA256-RSA-PKCS: ERR: verification failed
  testing key 1 (Encr 09.01.13 11:25:12 - 09.01.14) with 1 mechanism
    RSA-PKCS: ERR: verification failed
  testing key 2 (Encr 13.02.12 11:20:05 - 13.02.13) with 1 mechanism
    RSA-PKCS: ERR: verification failed
  testing key 3 (Auth 27.08.17 20:34:39 - 01.01.01) with 1 mechanism
    RSA-PKCS: ERR: verification failed
Verify (currently only for RSA)
  testing key 0 (Encr 10.05.17 09:32:43 - 10.05.20)
    RSA-PKCS:   ERR: C_Verify() returned CKR_GENERAL_ERROR (0x5)
  testing key 1 (Encr 09.01.13 11:25:12 - 09.01.14) with 1 mechanism
    RSA-PKCS:   ERR: C_Verify() returned CKR_GENERAL_ERROR (0x5)
  testing key 2 (Encr 13.02.12 11:20:05 - 13.02.13) with 1 mechanism
    RSA-PKCS:   ERR: C_Verify() returned CKR_GENERAL_ERROR (0x5)
  testing key 3 (Auth 27.08.17 20:34:39 - 01.01.01) with 1 mechanism
    RSA-PKCS:   ERR: C_Verify() returned CKR_GENERAL_ERROR (0x5)

As the #1867 (and several issues before) say, the CardOS 5 really does not support raw RSA operations. As the attached output in the above PR says, it works fine with my CardOS 5 card.

Where does the "really does not support raw RSA operations" come from?

[Jakuje]

This is actually interesting. If I do the same, my card already rejects the data to be signed as it is not a hash when using RSA-X-509 (it was the main reason why the change was introduced in the first place):

...
Signatures (currently only for RSA)
  testing key 0 (Digital Signature) 
error: PKCS11 function C_SignFinal failed: rv = CKR_DATA_INVALID (0x20)

The important flag that you changed also is SC_ALGORITHM_NEED_USAGE. It is trying to emulate the signatures using deciphering, which might work if the card allows this and also if the key and certificate has the correct usage flags. My card has first signature key which does not have encryption flags in pkcs11-tool -O --login listing and that will be probably reason why it does not work.

We can probably introduce some logic here to get failures earlier, but as this flag is set before reading any key, we really can not know whether we can use it.

The other issue is as you can see that the original data that it starts with one more zero byte. If you define OPENSC_DEBUG=9 and rerun the test, I would be interested in debug messages around cardos_compute_signature function and iso7816_decipher (including APDUs), which takes care of the signatures. Problem with this approach is that this can be stripping initial zero bytes.

[Silvanoc]

Debug messages for the function cardos_compute_signature with level 9: https://gist.github.com/Silvanoc/8d018c45299e6e4b1f7bebeafedac29b

Debug messages for the function iso7816_decipher with level 9:
https://gist.github.com/Silvanoc/3fb37b36d748ea49e8b3780c760a4cb2

Hopefully the same issue @fbezdeka and @loblik are facing...

[Jakuje]

Debug messages for the function cardos_compute_signature with level 9: https://gist.github.com/Silvanoc/8d018c45299e6e4b1f7bebeafedac29b

This is indeed a signature of some hash data, which worked fine. The data part is der encoded sha1 hash. Do you also get verification issues as @fbezdeka ?

Debug messages for the function iso7816_decipher with level 9:
https://gist.github.com/Silvanoc/3fb37b36d748ea49e8b3780c760a4cb2

Hopefully the same issue @fbezdeka and @loblik are facing...

The decipher indeed work only if the key also supports decryption (as I describe in the previous comment).

The question is how to get out of this. We can probably agree that using decipher operation for signature is ugly hack, but it looks like it is the only way how to get some newer and stricter cards and some older and unreasonable software to work together. I would certainly like to avoid using this by default, but the supported mechanisms need to be decided during card initialization.

[fbezdeka]

Still running the same patch as above, still 4 failures:

Debug messages for the iso7816_decipher function with level 9:
https://gist.github.com/fbezdeka/f0a3aa70ba1cec7877942a3916a66669

I guess I can not help out with debugs for cardos_compute_signature.
It looks like this function is never involved....

Searching for compute_signature delivers the following line:

P:11926; T:0x139838367020864 15:52:38.177 [opensc-pkcs11] pkcs15-sec.c:565:sc_pkcs15_compute_signature: called

[fbezdeka]

Debug messages for the iso7816_decipher function with level 9 (after adding SC_ALGORITHM_RSA_PAD_PKCS1 to the flags, 8 errors):
https://gist.github.com/fbezdeka/5c690f73b3a571a70c937b9c2e4e5b94

[Jakuje]

Still running the same patch as above, still 4 failures:

Debug messages for the iso7816_decipher function with level 9:
https://gist.github.com/fbezdeka/f0a3aa70ba1cec7877942a3916a66669

I guess I can not help out with debugs for cardos_compute_signature.
It looks like this function is never involved....

Right, this confirms what I wrote in previous comments -- what you do is not a signature, but decipher. CardOS 5 does not support raw RSA sign even for your card as you can see. I would also like to see the list of objects with pkcs11-tool -O ---login, but I assume that your keys will have both sign and decipher flags, which makes it working for you.

@fbezdeka The actual issue you have is a verification, which fails because something (openssl? or even the card?) is stripping the leading zero byte. I think this can happen in case the first byte of public key is zero or something like that. We already had similar issue with OpenPGP if I remember well. Not sure what was the solution though.

So now, we know mostly what is going on there, but we are not closer to solving it unless we will come with some creative solution. Neither you nor I want failing tests with my card and it looks like neither solution works now for both configurations.

[fbezdeka]

$pkcs11-tool -O --login
...
Private Key Object; RSA 
  label:      --some-label--
  ID:         --some-id--
  Usage:      decrypt, sign, unwrap
  Access:     sensitive, never extractable
...

Yes, failing tests are annoying, but the most important thing for me is that I can use the card for client-auth and mail signing/decryption. This requires SC_ALGORITHM_RSA_RAW to be set.

Not sure about SC_ALGORITHM_RSA_PAD_PKCS1. If set the number of failing tests is 8, unset 4.

[fbezdeka]

Btw: I went back to 0.19 and there were 4 failing tests for my card as well. So this is nothing new...

[Silvanoc]

Do you also get verification issues as @fbezdeka ?

Yes, I do. Look here: https://gist.github.com/Silvanoc/170113fb7f452d9d7e8c93888d3ade74

And here to see the flags of the different objects in the card: https://gist.github.com/Silvanoc/d3244352202982100bd8afc7b39c4243

[loblik]

Btw: I went back to 0.19 and there were 4 failing tests for my card as well. So this is nothing new...

I can also confirm this. I can make the card behave the same like with 0.19 just by adding SC_ALGORITHM_RSA_RAW .

Edit: And I'm also having verification and encryption errors. But that is also the case with 0.19. It actually seem it returns correct bytes just with some extra data in the beginning of PDU. Exactly like in the logs above.

[dengert]

The leading zero issue with a signature should have been fixed with #1319.
If decipher is being used it may have the same issue.

[Jakuje]

@dengert thank you for pointers. That is probably right think to fix also for deciphering. Not sure about the flags though. If we are going to put the NEEDS_USAGE back, we need to make sure it checks the decipher flags before attempting to do signature using decipher to fail somehow more sensibly.

[fbezdeka]

Using this one I have no errors for CardOS 5 and 4.2c

--- a/src/libopensc/card-cardos.c
+++ b/src/libopensc/card-cardos.c
@@ -173,7 +173,7 @@ static int cardos_init(sc_card_t *card)
        /* Set up algorithm info. */
        flags = 0;
        if (card->type == SC_CARD_TYPE_CARDOS_V5_0) {
-               flags |= SC_ALGORITHM_RSA_PAD_PKCS1;
+               flags |= SC_ALGORITHM_RSA_RAW;
        } else {
                flags |= SC_ALGORITHM_RSA_RAW
                        | SC_ALGORITHM_RSA_HASH_NONE
diff --git a/src/libopensc/pkcs15-sec.c b/src/libopensc/pkcs15-sec.c
index 42a3a6af..d2cafac4 100644
--- a/src/libopensc/pkcs15-sec.c
+++ b/src/libopensc/pkcs15-sec.c
@@ -266,6 +266,21 @@ int sc_pkcs15_decipher(struct sc_pkcs15_card *p15card,
        sc_security_env_t senv;
        const struct sc_pkcs15_prkey_info *prkey = (const struct sc_pkcs15_prkey_info *) obj->data;
        unsigned long pad_flags = 0, sec_flags = 0;
+       size_t modlen;
+
+       switch (obj->type) {
+               case SC_PKCS15_TYPE_PRKEY_RSA:
+                       modlen = prkey->modulus_length / 8;
+                       break;
+               case SC_PKCS15_TYPE_PRKEY_GOSTR3410:
+                       modlen = (prkey->modulus_length + 7) / 8 * 2;
+                       break;
+               case SC_PKCS15_TYPE_PRKEY_EC:
+                       modlen = ((prkey->field_length +7) / 8) * 2;  /* 2*nLen */
+                       break;
+               default:
+                       LOG_TEST_RET(ctx, SC_ERROR_NOT_SUPPORTED, "Key type not supported");
+       }
 
        LOG_FUNC_CALLED(ctx);
 
@@ -284,6 +299,12 @@ int sc_pkcs15_decipher(struct sc_pkcs15_card *p15card,
                        outlen);
        LOG_TEST_RET(ctx, r, "use_key() failed");
 
+       if (obj->type == SC_PKCS15_TYPE_PRKEY_RSA && (unsigned)r < modlen) {
+               memmove(out + modlen - r, out, r);
+               memset(out, 0, modlen - r);
+               r = modlen;
+       }
+
        /* Strip any padding */
        if (pad_flags & SC_ALGORITHM_RSA_PAD_PKCS1) {
                size_t s = r;

[fbezdeka]

When trying to bring back the SC_ALGORITHM_RSA_PAD_PKCS1 flag, some padding seems not to be removed:

    Original: 00 f2 0c 93 94 e9 0b 01 0c fb
    Decrypted: 00 02 9d 2a 61 7d 0b 20 9a ab ed 5d c5 6a 07 0e 65 ff f6 8a be aa dc 99 88 3e 07 d8 90 f5 44 91 17 c5 12 b4 9a b0 56 0d ff a9 fb e2 64 8c ed 0d 3c 9c ec 9d a6 af 57 3c 84 67 dd ea ad 81 f8 84 50 25 e0 42 27 1f 68 98 5a 6a 60 3e 13 dc 34 a7 01 12 bd b9 ae 57 6a b3 e6 1a a4 a0 6f e6 25 d7 20 74 79 4f 1d 89 f5 05 27 c2 e3 9a 15 a1 7a 9d 8c e2 e6 36 0f eb 80 57 b9 20 e5 12 ad d2 e0 ef a0 68 3c fa e0 fa 63 1a fe d0 e3 c7 e8 68 58 8e 82 18 65 3f e7 d8 0e 11 a1 d6 79 3e 6b 82 1a 98 2e 65 12 fd 40 01 7b 43 ec 22 bd 03 ac 90 51 73 93 a4 29 e1 50 04 c8 f8 37 9d cb 54 0e a1 38 4b 2d d5 e7 52 cf d0 a8 1b f3 40 b4 2e c0 94 5b fa d0 0c 2e 8e 6a 9b 35 c8 a6 96 3f 64 50 41 ee 15 ab a0 28 c2 33 c8 da 95 50 d5 ea 93 e9 d3 35 4a 9a 1d b4 a6 96 00 00 f2 0c 93 94 e9 0b 01 0c fb

[Jakuje]

See the cardos_compute_signature() function. It manually strips the padding of the signed data if provided using sc_pkcs1_strip_01_padding(). This is one trick how to simulate the RAW RSA support by stripping the padding, sending just the digestinfo and hoping the padding will be readded back in card.

I think you will have to write similar function that strips the 02 padding which is used with encryption. But this asks for reimplementing the ISO decipher function in cardos driver with these modifications, if you really want to go this path.

[loblik]

What would be the steps now? Do we already have enough information? I'm willing to help but not I'm probably not able to solve it on my own as I don't have enough background. Can you (@Jakuje) describe what was the logic behind that change? The commit message just says "fixes" which is not much descriptive. And it seems that change broke quite some users.

[fbezdeka]

Maybe we should split this into two tasks.

a) Adding the SC_ALGORITHM_RSA_RAW flag should remove the regression that some CardOS 5 cards are no longer working

b) Implement the failing tests, so fully support CardOS 5.x. Care about all the hints from @Jakuje

As @loblik I'm happy to help testing, but I'm not really familiar with the opensc code base.

[loblik]

I guess everyone having the issue has the same. Here is mine.

Using reader with a card: Generic Smart Card Reader Interface [Smart Card Reader Interface] (20070818000000000) 00 00
3b:d2:18:00:81:31:fe:58:c9:03:16
Sending: 00 CA 01 02 00 
Received (SW1=0x6A, SW2=0x88)

Not sure if @Jakuje has a different one.

In #1941 @bigon reports having also problems and he seems to have:

3b:d2:18:00:81:31:fe:58:c9:02:17

[dengert]

Any user who has any CardOS card please respond to this.

The above is a good start. (The attempt to read a version, did not work, and may not for 5.x)

We should also get some more information on ATR, card issuer (Gov issued, and what Country) and version number if printed on card from known users with CardOS cards.

@Jakuje @bigon https://github.com/eblis @https://github.com/Ragnar-von-Detroit
can you respond with the above? opensc-tool -a for ATR.

Any other user who has any CardOS card can respond too.

The goal is to isolate any changes to specific cards as needed. It is so easy with OpenSC to propose changes that work for "my" card but break others. This may require adding another
SC_CARD_TYPE_CARDOS_V5_XXX for some subset of cards or reading a version number to use to differentiate between cards.

Care must be taken when proposing changes like in #1916 (comment) to pkcs15-sec.c sc_pkcs15_decipher. This is used by all cards.

[Jakuje]

I am away from the office where the card I have is lying and because of coronavirus I do not expect getting there in coming weeks.

But the trace from my CardOS 5 card is available in https://github.com/OpenSC/OpenSC/blob/1742dfc04503111047db5ab45ca440ea747eb0d7/src/tests/fuzzing/corpus/fuzz_pkcs15_reader/7cf8e9b31dcee040ee438441aca2aecb523ed5e9 where the first block is ATR:

$ hexdump -C src/tests/fuzzing/corpus/fuzz_pkcs15_reader/7cf8e9b31dcee040ee438441aca2aecb523ed5e9  | head -n1
00000000  0b 00 3b d2 18 00 81 31  fe 58 c9 03 16 04 00 01  |..;....1.X......|

From there the ATR is 3b d2 18 00 81 31 fe 58 c9 03 16.

But I do not think this will solve anything. My understanding is that the difference is in the card enrolling and how keys are configured and whether they allow deciphering or not. Mine has strict Signature key, which fails on attempt to do the SKO:DECIPHER. This works on card that allow to do both operations with the key.

[dengert]

Thanks. I don't know much about CardOS, or who issues these cards.
Is there a way to query the card for the key attributes?

pkcs15-piv.c can set the pubkey and prkey usage attributes from the certificate keyUsage starting at:

OpenSC/src/libopensc/pkcs15-piv.c

Line 792 in dc29b0f

* get keyUsage if present save in ckis[i]

to L912. Then later in L1087-L1122 and L165-L1199
This could be made a routined usable by other drivers.

[Jakuje]

I don't know much either. They are normal access cards used by various companies in the wild, usually enrolled using proprietary software from Atos/Siemens. I don't have access to any more specs that what is available on the internet.

The card is quite pkcs15-compatible (it does not even have pkcs15-emulator). I do not understand much these parts, but if I remember well, the usage was set reasonably on the PKCS#15 layer, but the NEEDS_USAGE flag is really something that is set and goes into an effect earlier than we can have a look into the usage of the particular keys, which makes this functionality problematic. I will try to get remote access to the card tomorrow to share a debug log.

[dengert]

What is the NEEDS_USAGE flag? I don't see it any any source. Do you mean the PKCS15
usage KeyUsageFlags, Also see "Table 2 – Mapping between PKCS #15 key usage flags and X.509 keyUsage extension flags" in pkcs-15-v1.1

Those with CardOS 5.x cards may want to run:
pkcs15-tool --dump --short to see public and private key flags.
and for each certificate change XX to ID:
./pkcs15-tool --read-certificate XX | openssl x509 -noout -ext keyUsage
This would help see if the certificate keyUsage flags agree with the public and private key flags.

[loblik]

Private key flags:

	RSA[2048]  ID:_1  Ref:0x01  AuthID:01
	     Auth _BEFORE AFTER_ [0x26, decrypt, sign, unwrap]
	RSA[2048]  ID:_2  Ref:0x02  AuthID:01
	     Encr _BEFORE AFTER_ [0x26, decrypt, sign, unwrap]
	RSA[2048]  ID:_3  Ref:0x03  AuthID:01
	     Encr _BEFORE AFTER_ [0x26, decrypt, sign, unwrap]

X509v3 Key Usage:

id:_1
X509v3 Key Usage: critical
    Digital Signature
id:_2
X509v3 Key Usage: critical
    Key Encipherment, Data Encipherment
id:_3
X509v3 Key Usage: critical
    Key Encipherment, Data Encipherment

I'm not sure about public key flags though. The output says

Card has 0 Public key(s)

[Jakuje]

Sorry, the SC_ALGORITHM_NEED_USAGE flag in the above patches.

I got connected to the remote smart card so confirming the atr:

# opensc-tool --atr -r 1
3b:d2:18:00:81:31:fe:58:c9:03:16

And following up the last questions:

# pkcs15-tool --dump --short --reader 1
PKCS#15 Card [XX PKI Card]:
	Version        : 0
	Serial number  : 06760082
	Manufacturer ID: XX AG
	Flags          : EID compliant
Card has 1 Authentication object(s).
	PIN  ID:01  Ref:0x01  AuthID:12  Path:3f00  Card PIN
Card has 6 Private key(s).
	RSA[2048]  ID:11  Ref:0x01  AuthID:01
	     Digital Signatur [0x2C, sign, signRecover, unwrap]
	RSA[2048]  ID:55  Ref:0x02  AuthID:01
	     Encryption       [0x22, decrypt, unwrap]
	RSA[2048]  ID:56  Ref:0x03  AuthID:01
	     Encryption       [0x22, decrypt, unwrap]
	RSA[2048]  ID:57  Ref:0x04  AuthID:01
	     Encryption       [0x22, decrypt, unwrap]
	RSA[2048]  ID:58  Ref:0x05  AuthID:01
	     Encryption       [0x22, decrypt, unwrap]
	RSA[2048]  ID:59  Ref:0x06  AuthID:01
	     Encryption       [0x2E, decrypt, sign, signRecover, unwrap]
Card has 0 Public key(s).
Card has 9 Certificate(s).
	Path:3f0050154541  ID:11
	Path:3f0050154574  ID:55
	Path:3f0050154574  ID:56
	Path:3f0050154574  ID:57
	Path:3f0050154574  ID:58
	Path:3f0050154574  ID:59
	Path:3f0050154574  ID:2d32323432323930343936393231393930373736
	Path:3f0050154574  ID:33363233363931373936373331393231323431
	Path:3f0050154573  ID:39313639363435393236333832333039343138
Card has 1 Data object(s).
	Path:3f005015f001  Size:   55

(there is more certificates than keys, but the additional are CA certificates)

You can see that already on the PKCS#15 level, the first Signature Key has appropriate flags set (no decipher), which prevents using the decipher hack to provide raw RSA signatures in this particular case.

The lack of decipher flags is visible also in the certificates, which is matching the pkcs15 layer:

# pkcs15-tool --read-certificate 11 --reader 1 | openssl x509 -noout -ext keyUsage
X509v3 Key Usage: critical
    Digital Signature
# pkcs15-tool --read-certificate 55 --reader 1 | openssl x509 -noout -ext keyUsage
X509v3 Key Usage: critical
    Key Encipherment, Data Encipherment
# pkcs15-tool --read-certificate 56 --reader 1 | openssl x509 -noout -ext keyUsage
X509v3 Key Usage: critical
    Key Encipherment, Data Encipherment
# pkcs15-tool --read-certificate 57 --reader 1 | openssl x509 -noout -ext keyUsage
X509v3 Key Usage: critical
    Key Encipherment, Data Encipherment
# pkcs15-tool --read-certificate 58 --reader 1 | openssl x509 -noout -ext keyUsage
X509v3 Key Usage: critical
    Key Encipherment, Data Encipherment
# pkcs15-tool --read-certificate 59 --reader 1 | openssl x509 -noout -ext keyUsage
X509v3 Key Usage: critical
    Digital Signature, Key Encipherment, Data Encipherment

So my assumption is that this depends on the way how the card is enrolled and how precisely are all the key flags set so they match certificates.

[dengert]

The lack of a public key should not a problem. or at least not the problem of this issue. Some OpenSC card drivers extract the public key from the certificate (because it needs the algorithm (RSA, ECC) and parameters and sizes). The driver can also present the public key to PKCS15 layer. The public key is also contained in the certificate as the subjectPublicKeyInfo (SPKI). But if a PKCS11 application is depending on accessing the public key and this is the issue for CardOS, it can be added to driver or sc_pkcs_pubkey_*routines.

[bigon]

$ opensc-tool -a
Using reader with a card: Alcor Micro AU9560 00 00
3b:d2:18:00:81:31:fe:58:c9:02:17

The card is issued by AtoS itself to access AtoS internal stuff (Global IT) and it shows that it also supports RFID (never tried)

Card says "CardOS DI 5.3 v2"

$ pkcs15-tool --dump --short
Using reader with a card: Alcor Micro AU9560 00 00
PKCS#15 Card [Atos PKI + OTP Card  V5.3(016)]:
	Version        : 0
	Serial number  : SN
	Manufacturer ID: www.atos.net/cardos
	Flags          : Login required, PRN generation
Card has 5 Authentication object(s).
	PIN  ID:01  Ref:0x81  AuthID:02  PIN
	PIN  ID:02  Ref:0x82  SO-PIN
	Key  ID:08  Derived:1  SecretKeyID:VVV  Admin Key
	PIN  ID:04  Ref:0x85  AuthID:02  Path:WWW  Extra PIN #1
	PIN  ID:03  Ref:0x84  AuthID:02  Path:WWW  Extra PIN #0
Card has 3 Private key(s).
	RSA[2048]  ID:XXX1  Ref:0x02  AuthID:01
	     myname AUT 1 [0x26, decrypt, sign, unwrap]
	RSA[2048]  ID:XXX2  Ref:0x03  AuthID:01
	     myname ENC11 [0x26, decrypt, sign, unwrap]
	RSA[2048]  ID:XXX3  Ref:0x04  AuthID:01
	     myname ENC i21 [0x26, decrypt, sign, unwrap]
Card has 3 Public key(s).
	RSA[2048]  XXX1  Ref:0xFFFFFFFF  myname AUT 1 [0x51, encrypt, wrap, verify]
	RSA[2048]  XXX2  Ref:0xFFFFFFFF  myname ENC11 [0x51, encrypt, wrap, verify]
	RSA[2048]  XXX3  Ref:0xFFFFFFFF  myname ENC i21 [0x51, encrypt, wrap, verify]
Secret 3DES Key [Challenge/Response 3DES Key 01]
	Object Flags   : [0x03], private, modifiable
	Usage          : [0x40], verify
	Access Flags   : [0x09], sensitive, neverExtract
	Size           : 0 bits
	ID             : XXX
	Native         : yes
	Key ref        : KKK (0xKK)
	Path           : XXX
	GUID           : XXX

Card has 3 Certificate(s).
	Path:YYY2  ID:XXX1
	Path:YYY3  ID:XXX2
	Path:YYY4  ID:XXX3
Card has 2 Data object(s).
	Path:ZZZ1  Size:    8                      
	Path:ZZZ2  Size:    6                      

$ pkcs15-tool --read-certificate XXX1|openssl x509 -noout -ext keyUsage
Using reader with a card: Alcor Micro AU9560 00 00
X509v3 Key Usage: critical
    Digital Signature
$ pkcs15-tool --read-certificate XXX2|openssl x509 -noout -ext keyUsage
Using reader with a card: Alcor Micro AU9560 00 00
X509v3 Key Usage: critical
    Key Encipherment, Data Encipherment
$ pkcs15-tool --read-certificate XXX3|openssl x509 -noout -ext keyUsage
Using reader with a card: Alcor Micro AU9560 00 00
X509v3 Key Usage: critical
    Key Encipherment, Data Encipherment

[dengert]

Loblik's and Jakuje's cards both show certificate attributes consistent with private key attributes.
But Jakuje's card has much more restrictive attributes.

What we may be seeing is OpenSC software assuming the attributes define the limitation of the card. But this may not be the case. i.e. OpenSC enforcing the "policy" of the card issuer to not use the same key for sign and decrypt. https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-sec.c#L272

But the card may have been provisioned to not accept RAW RSA commands and always add PKCS1 padding on the card during sign and strip the padding during decrypt. So the card is enforcing the "policy".

If keys are created on a card, and not extractable, there must be a way to sign a certificate request for a decrypt only key. This might be part of the provisioning process and once the certificate is created and loaded then the provisioning process cause the card to enforce the "policy". If that is the case there is not much we can do.

But I suspect that is not the case. The PIV driver allows for a sign operation during provisioning for any key: https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-piv.c#L1152

A trick could be done for CardOS. This might require writing a pkcs15-cardos.c for this case or add code at the sc_pkcs15 level.

How to test...

One way it to use opensc-tool with multiple -s options with a set of carefully crafted APDUs.

We need opensc-debug log showing a decrypt and the preceding senv APDUs. One with SC_ALGORITHM_RSA_RAW set using a key which can sign and decrypt.

And a log without using SC_ALGORITHM_RSA_RAW with a key that can be used both for sign and decrypt.

pkcs11-tool --test --login could get the APDUs.

On the card with a sign only private key, we need to use pubkey to encrypt, paste the encrypted data into the APDUs and test against the card.

Something like pkcs15-tool --read-certificate XX then openssl pkeyutl -certin xxxx -encrypt...
(still looking a best way to do this.) anyone else have an idea?

[dengert]

@bigon 's card is interesting, and the certificate has Digital Signature but the matching private key has decrypt, sign, unwrap
This is different from the other two cards, where certificate is consistent with private key.

[dengert]

I would like to ask any of you who have a working solution or not (especially if it uses RAW RSA to run the following script. test.decipher.sh.txt

You will need to edit the script and change the path, and the ID= to point at key and cert to use.
It creates 5 files lie these:

-rw-r--r-- 1 doug doug 884598 Mar 17 11:40 opensc-debug.log
-rw-r--r-- 1 doug doug     14 Mar 17 11:40 TEST.CardOS.decrypted.txt
-rw-r--r-- 1 doug doug    784 Mar 17 11:40 TEST.CardOS.encrypted.txt
-rw-r--r-- 1 doug doug    256 Mar 17 11:40 TEST.CardOS.encrypted.DER
-rw-r--r-- 1 doug doug   1294 Mar 17 11:40 TEST.CardOS.cert.01.PEM
-rw-r--r-- 1 doug doug     14 Mar 17 11:40 TEST.CardOS.hello.txt

If it worked, the TEST.CardOS.hello.txt and TEST.CardOS.decrypted.txt will contain "Hello, World!"

If it worked or not, please send the TEST.CardOS.encrypted.txt and opensc-debug.log starting with "sc_pkcs15_decipher: called" and ending with "sc_pkcs15_decipher: returned" In may case testing with a Yubikey, that's 161 lines out of the 6997 lines. TEST.CardOS.encrypted.txt is specific to you key.

If your card does not have certificate but does have public key, the script can be changed. Let me know. pkcs15-tool can dump the pubkey and openssl pkeyutl can read a pubkey.

I will then look at the APDUs sent in both cases. For the cards that failed, I will come up with a set of APDUs to be used with the the encrypted data from your cards that failed the decipher to be used
with opensc-tool -s using the commands that worked, with the encrypted data for cases that failed. (I may have each of you do the actual cut-and-paste, and just send instructions.)
But I still need to see the partial opensc-debug.log with the APDUs that worked or failed.

The opensc-tool -s justs sends the APDUs and bypasses all the PKCS15 and OpenSC checks that maybe causing the problems. It will test the card to see if RAW RSA is supported or not or if card want to strip padding on the card, and if it can strip type 1 or 2 padding.
We can then look at what code changes are needed.

[Silvanoc]

@dengert the hereby reported issue is with signing/verifying. But what you and your script are focusing on is (en/de)-cryption, right? Is there a reason for it that I oversee?

I can probably provide you the desired information, once the script has been adapted for signing (assuming it's so).

[Silvanoc]

I could modify the script to use pkcs15-tool for signing and verifying with openssl dgst: test.sign.sh.txt

Would it give us the information that we need?

[dengert]

I wanted to focusing on what can card really do. Some say their card can do RAW RSA, some say the card must add or remove the padding on the card and the card only knows how to use PKCS1 padding.

If card can do SC_ALGORITHM_RSA_RAW, it can use same APDUs for signing or decryption. With signing, software does digest and padding and card SC_ALGORITHM_RSA_RAW. With decryption, card does SC_ALGORITHM_RSA_RAW, then software removes the padding revealing results.

OpenSC sets in cardos_init the flags SC_ALGORITHM_RSA_PAD_PKCS1, SC_ALGORITHM_RSA_RAW, based on card type. It is not clear if these are being set correctly for each card. A SC_CARD_TYPE_CARDOS_V5_0 maybe different then a SC_CARD_TYPE_CARDOS_V5_3 (not yet defined)

Depending on what flags are set, OPenSC will adjust what it does in software vs what is done on the card. If padding is added or removed on card, then only limited types of padding can be done.

If card does not support SC_ALGORITHM_RSA_RAW, Signing is easy. Decryption is harder. The encryption with public key is done on another machine and must use the type of padding the card can strip.

Some people look at SC_ALGORITHM_RSA_RAW and say it is a security risk because it is easy. Others say pkcs1 is a security risk and want to use other types of padding. which a card may not understand. But we must live with what our card supports. Question is what does it support?

No one has all the hardware devices to test with. Users assume if they make a mod and it works it must be a good mod. For them, but other cards may not be the same.

@Silvanoc Have you tried the script I sent? Even if it fails, you may have a card that has the wrong flags set in cardos_init. This is the type of input the group needs. What is ATR and what failed.
Yours may be a SC_CARD_TYPE_CARDOS_V5_3.

[Silvanoc]

@dengert your script works successfully for me and my signing script too. But I have applied the patch [1] from @fbezdeka. I suppose without the patch it wouldn’t work. [1] #1916 (comment) On 19. Mar 2020, at 13:44, Doug Engert <[email protected]> wrote:  I wanted to focusing on what can card really do. Some say their card can do RAW RSA, some say the card must add or remove the padding on the card and the card only knows how to use PKCS1 padding. If card can do SC_ALGORITHM_RSA_RAW, it can use same APDUs for signing or decryption. With signing, software does digest and padding and card SC_ALGORITHM_RSA_RAW. With decryption, card does SC_ALGORITHM_RSA_RAW, then software removes the padding revealing results. OpenSC sets in cardos_init the flags SC_ALGORITHM_RSA_PAD_PKCS1, SC_ALGORITHM_RSA_RAW, based on card type. It is not clear if these are being set correctly for each card. A SC_CARD_TYPE_CARDOS_V5_0 maybe different then a SC_CARD_TYPE_CARDOS_V5_3 (not yet defined) Depending on what flags are set, OPenSC will adjust what it does in software vs what is done on the card. If padding is added or removed on card, then only limited types of padding can be done. If card does not support SC_ALGORITHM_RSA_RAW, Signing is easy. Decryption is harder. The encryption with public key is done on another machine and must use the type of padding the card can strip. Some people look at SC_ALGORITHM_RSA_RAW and say it is a security risk because it is easy. Others say pkcs1 is a security risk and want to use other types of padding. which a card may not understand. But we must live with what our card supports. Question is what does it support? No one has all the hardware devices to test with. Users assume if they make a mod and it works it must be a good mod. For them, but other cards may not be the same. @Silvanoc<https://github.com/Silvanoc> Have you tried the script I sent? Even if it fails, you may have a card that has the wrong flags set in cardos_init. This is the type of input the group needs. What is ATR and what failed. Yours may be a SC_CARD_TYPE_CARDOS_V5_3. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#1916 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AB74RAAFIK7JFLCA55XO3QTRIIHSNANCNFSM4KMBWATA>.

[dengert]

CT_181026_LPM_CardOS_V5-3_Multifunctionality_FS_en3_web.pdf
In addition to many other features it says: "“Command chaining” in accordance with ISO/IEC 7816-4" (It may have been introduced earlier.)

This feature is used by many cards and allows for using short (or extended) APDUs to send blocks of data of any size. RSA decryption with key size 2048 and above needs to send 256 bytes plus other control bytes and can use "command chaining".

Both Extended APDU and command chaining are designed to get around the 255 send and 256 receive restrictions. But reader have size restrictions and some readers may not support extended APDUs.

As noted by @frankmorgner in one of these issues, the capabilities of the reader is not been considered in the code and support for extended APDU is assumed. We have not looked close at which readers each of you are using.

Also read comment: https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-cardos.c#L993 from 2017-11-27 bb4bdc8 when cardos_decipher was first added.

Much of the discussion has been RSA_RAW vs PKCS1. RSA 2048 and above signature operation with RAW needs to send > 256 bytes. (This then depends on your reader supporting extended APDUs.)
If PKCS1 is done on the card, only the digest info and hash are sent way less than 256. Decryption always needs to send encrypted data plus a control byte.

Some of you may be seeing failures of sign operations because of reader restrictions if RSA RAW is used but PKCS1 works, You may also see decipher fail because of reader restriction, or if only PKCS1 is used.

So what can be done?

I would like to propose the card-cardos.c be changed for V5.3 cards:

• Use command chaining. Atos says it is supported. This would be in the cardos_decipher, and do_compute_signature.

• Set both SC_ALGORITHM_RSA_PAD_PKCS1 and SC_ALGORITHM_RSA_RAW.

• use reader capabilities and max sizes as other cards drivers do.

I can write the mod if anyone is willing to test it. I do not have a CardOS card.

The "command chaining" may have been introduced after 2017-11-17. and work on cards less then V5.3. I will leave that up to someone who has one of these cards to research.

[Silvanoc]

Thanks all participants for fixing this issue! 👏 🎉

[henning-schild]

Well the regression remains because distros are waiting for a release. #2061

Fedora did backport https://bugzilla.redhat.com/show_bug.cgi?id=1830528

I am trying to get gentoo to do the same gentoo/gentoo#18285

Right now at least gentoo, arch, and ubuntu 20.04 are affected. debian bullseye is as well https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961123 and they will soon become "stable"

not sure how to fix all of them, but a release would certainly help ...

[Silvanoc]

@henning-schild the bug has been marked by @bigon as not found on Debian package opensc:0.20.0-4. Unfortunately the Debian bug tracker is IMO not so expressive as others...

I'm using Debian Testing and therefore version 0.20.0-4 of opensc and the issue appears to be fixed in that package as reported! Someone else facing the issue in Ubuntu right now should give it a try.

I have to admit I couldn't find neither the fix nor a patch in the source code. @bigon could you give us a hint on how it got fixed?

[bigon]

@Silvanoc Well, no

What I did is to say that it's also found in an earlier version (0.20.0-1). I didn't say that it was fixed in 0.20.0-4.

The debian bug tracker has a notion of version so if I say it's found in 0.20.0-1 it includes 0.20.0-4 as well as long as I don't mark it as fixed.

[Silvanoc]

Am I misunderstanding then the issue tracker reports?

Anyway, I've apparently built myself so long ago, that I already forgot it 😞

So I can confirm that no Debian package provides a fix yet. Not even patching! Although my issue reports that there is a patch... What a pity!

[henning-schild]

https://bugs.archlinux.org/task/68713

[henning-schild]

https://bugs.launchpad.net/ubuntu/+source/opensc/+bug/1905365