Minidriver EC Changes for private keys that do not need a PIN and/or ECDSA failure to sign

[dengert]

@llogar has been working on EOI cards with minidriver and has run into two problems which can be problem with other cards such as PIV.

A private key that does not need a PIN does not work.
ECDSA signatures failing because minidriver passed SC_ALGORITHM_RSA_PAD_PKCS1 or other SC_ALGORITHM_RSA_PAD_* flags to sc_pkcs15_compute_signature.

This PR is being submitted to take advantage of the Appveyor build for testing with PIV card.

Checklist

• Documentation is added or updated
• New files have a LGPL 2.1 license statement
• PKCS#11 module is tested
• [todo] Windows minidriver is tested
• macOS tokend is tested

[llogar]

My problem with encoding flags is not covered with this. See my log in #2718:

P:20188; T:12200 2023-02-23 09:27:00.238 [cardmod] padding.c:622:sc_get_encoding_flags: iFlags 0x100002, card capabilities 0x100100

caps doesn't have SC_ALGORITHM_RSA_PAD_PKCS1 set.

I'd rather fix this in minidriver code with something like:

--- minidriver.c
+++ minidriver.c
@@ -4978,6 +4978,7 @@
         dwret = SCARD_E_INVALID_VALUE;
         goto err;
     }
+    opt_crypt_flags &= ~SC_ALGORITHM_RSA_PADS;
   } else {
     logprintf(pCardData, 0, "invalid private key\n");
     dwret = SCARD_E_INVALID_VALUE;

and exclude any padding flags there when doing ECDSA?

[dengert]

Well it does. And it looks like minidriver sets it when it should not.

In minidriver.c (line numbers):
4692 DWORD WINAPI CardSignData(__in PCARD_DATA pCardData, __inout PCARD_SIGNING_INFO pInfo)
4699 int opt_crypt_flags;

In one of you logs I see: "CARD_PADDING_INFO_PRESENT not set:

4789 logprintf(pCardData, 3, "CARD_PADDING_INFO_PRESENT not set\n");
4791 opt_crypt_flags = SC_ALGORITHM_RSA_PAD_PKCS1;

This code is from cardmod when Windows only supported RSA. This looks like the problem.

4947 r = sc_pkcs15_compute_signature(vs->p15card, pkey, opt_crypt_flags, dataToSign, dataToSignLen, pbuf, lg, NULL);

In logL sc_pkcs15_compute_signature: ECDSA using SC_ALGORITHM_ECDSA_RAW flags before 0x00000002

the "before" is the flags before they are change. which is SC_ALGORITHM_RSA_PAD_PKCS1

So my change sort of fixed it (but may break something else), but the real fix need to be in minidriver around line 4791 which should not not do any of that if not RSA.

Is that where you wanted to make the change?

[llogar]

Yes, See this commit:

llogar@4c31a1d

Altough this clears padding flags post festum rather than prevents setting them in the first place...

[dengert]

@llogar have a look at the revised changes based on your work in this PR. They fix EC minidriver problems for any token and not just EOI.

[llogar]

At least in my case, when there is no PIN, it still returns SCARD_E_INVALID_PARAMETER, as this condition is met (dwFlags == 0 && vs->pin_objs[dwFlags] == NULL)

Possibly it should return "empty" PIN info for all vs->pin_objs[dwFlags] == NULL cases, as there may even be cards with ROLE_ADMIN and/or ROLE_USER (and not just ROLE_EVERYONE) without a PIN?

[dengert]

OK, it should be:
if (dwFlags && !vs->pin_objs[dwFlags])
or to make it more readable:
if (dwFlags != ROLE_EVERYONE) && (vs->pin_objs[dwFlags] == NULL))

As for none real pins vs->pin_objs is filled in from PKCS15 structures.

Then if dwFlags == ROLE_EVERYONE it will fall through to the case ROLE_EVERYONE:' and log a message and endup
6510 with another log message and hexdump or *p

Will update and try again today.

[llogar]

Thanks. It works now.

[dengert]

With updated (forced pushed) if statement: md_log shows:

returning info on PIN ROLE_EVERYONE [0]
returns 'PIN Information' --- 00000265ED666550:36
 0000  06000000 00000000 00000000 00000000  00000000 06000000 02000000 00000000
 0020  00000000 
MD_Function:CardGetProperty:6511 returning with: 0x00000000

certutil -scinfo shows all 4 certificates, where Certificate 3 does not require a PIN
Note: "Private key verifies"

================ Certificate 3 ================
--- Reader: Identiv SCR3500 A Contact Reader 0
---   Card: NIST DEMO Oberthur test cards
Provider = Microsoft Smart Card Key Storage Provider
Key Container = Certificate for Card Authentication

Serial Number: 01f6
Issuer: CN=Test ECC P-384 CA for Test PIV Cards, OU=Test CA, O=Test Certificates 2010, C=US
 NotBefore: 10/1/2010 2:30 AM
 NotAfter: 10/1/2030 2:30 AM
Subject: SERIALNUMBER=D650185A13422C2267829D916CD89080501E649C86501843E2, OU=Test Agency, OU=Test Department, O=Test Government, C=US
Non-root Certificate
Cert Hash(sha1): 59618196f7713320e2c758117903141d415282f0

Performing  public key matching test...
Public key matching test succeeded
  Key Container = Certificate for Card Authentication
  Provider = Microsoft Smart Card Key Storage Provider
  ProviderType = 0
  Flags = 1
    0x1 (1)
  KeySpec = 0 -- XCN_AT_NONE
Private key verifies
Microsoft Smart Card Key Storage Provider: KeySpec=0
AES256+RSAES_OAEP(ECC:CNG) test skipped

[Jakuje]

Whats the status of this PR? Should we merge the ECC part and drop/postpone the discussed/disputed role_everyone as it is already discussed in #2721?

[dengert]

This PR replaces #2721 and adds some additional changes. It was tested using PIV card and certutil.exe as noted in #2722 (comment)

@llogar author of #2712 says it worked in #2722 (comment)

I think it is ready to to be committed.

[Jakuje]

ok, I am not much happy how the flags are handled in the minidriver, but I do not know anything about the minidriver so if you believe it is working, please merge this. Its in the limbo for long enough already.

[dengert]

Main problem with old code is:#define ROLE_EVERYONE 0 which means there is no PIN_ID. This PR takes this into account.