minidriver.c pkcs15-piv.c - Support PinCacheAlwaysPrompt

[dengert]

(WIP may fix #3159 waiting to download the MSI artifacts for testing.)

PKCS11 supports CKA_ALWAYS_AUTHENTICATE and PKCS15 user_consent Windows minidriver supports PinCacheAlwaysPrompt

Mindriver has MD_ROLE_USER_SIGN for a pin which is taken to be a second user local pin to be used for signing.

A second user local pin was defined in pkcs15-piv.c which is a duplicate of the user pin except the sc_pkcs15_auth_info_auth_method set is set SC_AC_CONTEXT_SPECIFIC So when a key is used that requires "ALWAYS" authentication it will be be handled like framework-pkcs15.c handles CKA_ALWAYS_AUTHENTICATE

On branch minidriver-PinCacheAlwaysPrompt
Changes to be committed:
modified: libopensc/pkcs15-piv.c
modified: minidriver/minidriver.c

Checklist

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

[dengert]

This should be a fix for #3159 when PIV is used with the minidriver.
The code in pkcs15-piv.c defines a third pin, which is the same as the first pin, accept the auth_method is set to SC_AC_CONTEXT_SPECIFIC rather then SC_AC_CHV. The 9C key is listed as using the third pin in pkcs15-piv.c

Mindriver looks for a user_pin which is the default first pin in pkcs15-piv.c. It also looks for a sign_pin as the second type of user_pin and finds the new third pin in pkcs15-piv.c Because it is a "sign_pin" the minidriver sets PinCacheAlwaysPrompt for this pin. (This is one area which maybe a problem for other cards.)

So when an application like certutil wants to use the certificate which uses the 9C key, the CSP will always pops up a PIN which says: "Please enter your digital signature pin." The CSP then passes this PIN to minidriver to use the new third pin that has the auth_method = SC_AC_CONTEXT_SPECIFIC;.

(For PKCS11, framework-pkcs15.c also sets auth_method = SC_AC_CONTEXT_SPECIFIC; so that has been around for some time.)

The pkcs15-pin.c routines pass pin request to the card-piv.c which triggers card-piv.c to obtain an additional PC/SC lock so the verify and whatever APDU the application requests next (which should be the crypto instruction) to be in the same SCardTransaction. The PIV card keep track of the last verify it sees is just before the crypto operation as required by the specs.

This has been tested on Windows 11 PRO using an IDEMIA ID-One PIV 2.4.1 test card with ECDSA and RSA keys using certutil -v -scinfo And certutil popup says: ""Please enter your digital signature pin." and certutil says: Private key verifies` for all keys on the card.

I have been using opesc.conf so as to avoid any OpenSC caching and get PIN debugging:

app default {
	 debug = 9;
	 debug_file = \tmp\opensc-debug.txt;
		framework pkcs15 {
		use_pin_caching = false;
		use_file_caching = false;
	}
}

registry was modified like what https://github.com/ckahlo did to use the OpenSC minidriver for a PIV with the correct ATR.

Note that Windows is caching the user_pin and used it several times. There was only one use for the 'sign_pin`

What I have not done is test with others cards, especially with cards that have a user_pin and a sign_pin I don't expect any problems as then have the same restrictions as the PIV specs have.

[maciejsszmigiero]

Won't this force PIN re-prompts for every MD_ROLE_USER_SIGN PIN, not only the new PIV type?

Minidriver spec says that:

Note: Windows logon may not work properly if a PIN is not cached. This behavior is by design.
Therefore, careful consideration should be given when setting a PIN cache mode to any value other than PinCacheNormal.

I guess it really should be a special PKCS15 API PIN flag that says that this PIN needs re-sending before each operation. Or some other way to retrieve this information about PIN from the particular OpenSC card driver.

And then when this OpenSC API PIN flag is set the Minidriver can return PinCacheAlwaysPrompt for this PIN.

[dengert]

Won't this force PIN re-prompts for every MD_ROLE_USER_SIGN PIN, not only the new PIV type?

Maybe I have taken a different approach with the force push today:

   minidriver.c - Create shadow  MD_ROLE_USER_ALWAYS and MD_ROLE_USER_SIGN_ALWAYS

   PKCS11 defines CKA_ALWAYS_AUTHENTICATE attribute for private keys, which is converted
   to `user_consent` for PKCS15 for private keys. Windows has `PinCacheAlwaysPrompt`
   on PINS to accomplish the same thing - prompt user before using a key.

   But a key "is secured by" only one pin, but a pin may secure multiple keys where only
   a subset of keys need `PinCacheAlwaysPrompt`

   Two new pin roles are defined and use a sc_pkcs15_id auth_id of
   auth_id_md_role_user_always = {"MD_ROLE_USER_ALWAYS", 18};
   and
   auth_id_md_role_user_sign_always = {"MD_ROLE_USER_SIGN_ALWAYS", 18};

   When building containers for pkcs15 key objects, if user_consent > 0, the auth_id
   is set to one of the above. Thus when Windows CSP selects a key, it will find
   a pin that matches the correct role for the key.

This is still being tested. But should work for any card the has PKCS15 user_consent > 0 for
the User key and/or the Sign key.

[dengert]

Version 3 of this PR... minidriver.c was modified by bd9cdd2 in 2017 to support multiple pins for a card based on framework-pkcs15.c 10e1ad0 from 2012 which tries to create UserPIN, and SignPIN and some others based on pins define in PKCS15 . The concept of Global PIN and Local PIN come into play.

But none of these tried to address the PKCS11 CKA_ALWAYS_AUTHENTICATE attribute of a private key which is true or false, or the PKCS15 user_consent on an object which can define the number of times a pin can be used before it needs to be verified again.

Cards may have multiple pins, which may or may not have a user_consent limit. The general logic above assumes if the card supports more then one normal PIN i.e. not a PUK or SO_USER type PIN, then the first normal PIN is the UserPIN also
referred to as Authentication PIN and never or rarely has a user_consent limit.

pkcs15-esteid2018.c, pkcs15-idprime.c, pkcs15-jpki.c, pkcs15-skeid.c and pkcs15-piv.c all set user_consent for some key which is secured by the second pin i.e. SignPIN which may have a different value the the UserPIN.

The PIV card has just one PIN but if the 9C key is used the verify ADPU must immediately proceed the crytpo ADPU. So it needs CKA_ALWAYS_AUTHENTICATE and user_consent to signal the application to prompt for PIN. With Windows that is the
PinCacheAlwaysPrompt flag of a PIN.

pkcs15-piv.c defined 2 pins, the normal user pin and a PUK/SO_USER pin, but also set the SC_PKCS15_PIN_FLAG_LOCAL
flag on the PUK pin, which caused the minidriver to assume it was a SignPIN which is a bug.

In this version of the PR:

• pkcs15-piv.c now defines 3 pins, the UserPIN, a SignPIN and a PUK pin.

• minidriver.c while looking at keys and which PIN "is secured by" the SignPIN, will test if user_consent > 0.and set
  vs->need_pin_alway. Then when CSP picks a key to use, which is secured by the SignPIN i.e. MD_ROLE_USER_SIGN the minidriver.c will set PinCacheAlwaysPrompt causing the CSP to prompt the user for the PIN.

This should also work for the other 4 cards, but they should be tested.

"is secured by" is used in the debug logs with level 7.

@maciejsszmigiero can you have a look at this too?

Should fix #3156 and #3169

[dengert]

The PR has been rebased to a single commit, and tested with two PIV type cards with:

• certutil -scinfo on Windows 11 Pro
• pkcs15-tool on Windows with various list options
• pkcs11-tool --test --login on Windows and Ubuntu

Card drivers that do not use user_consent are not affected. PinCacheAlwaysPrompt is only set on the Sign PIN if there is a key that requires user_consent. There are 5 drivers that use user_consent:

• pkcs15-piv.c when not being called from minidriver sitll defines a User PIN or Global PIN (based on the cards preference for Global or Local) and a PUK PIN. When ctx->app_name == "cardmod" i.e. minidriver a Sign PIN is defined to be used only with the 9C key so Windows PinCacheAlwaysPrompt can be set on the Sign PIN.
• pkcs15-esteid.c defines a User PIN and Sign PIN but no PUK.
• pkcs15-idprime.c defines a User PIN and for 940 type cards a Sign PIN.
• pkcs15-dnie.c defines a User PIN but has its own dnie_ask_user_consent routine, so should not be affected by this PR.
• pkcs15-jpki.c defines a User PIN and Sign PIN but there is still the problem that the the public key is private and needs to be read and placed in the CCP_CONTAINER_INFO before the key is selected and PIN verified to allow the public key to be read.

So this PR will be useful for the 5 drivers. But registry entries for OpenSC with PIV are not installed be default and the JPKI still has problems. No bug reports (that I know of) with pkcs15-esteid.c or pkcs15-idprime.c may indicate a lack of use of these drivers with Windows.

[maciejsszmigiero]

The changes overall seem reasonable to me, but I don't have the ability to test them - my test setup for OpenSC minidriver is long gone by now

[maciejsszmigiero]

This seems to change the logic condition from (i == 0 AND pin.reference == 0x80) to (i == 0 OR cardmod).
Is this change intentional?

[dengert]

It logic may need some changes. The intent is when run by minidriver, the pins[i].cardmod is set on pin[2] which will be treated as the Sign PIN by minisriver with the same pin reference as PIN[0]. With PKCS11 or any application other than minidriver, lines 969-971 will cut the loop short and only two pins are defined: pin[0] as the auth pin, and pin[1] as the PUK PIN/Admin PIN.

((i == 0 || pins[i].cardmod)) { is really if (i == 0 || i == 2) set the auth_id of the PUK/ADMIN PIN on the other pin(s).
sp800-73-X (all version) only defines one PIN which when used with the 9C key, must be verified just before the APDU (00 87 XX 9C) crypto operation.

sp800-73-X also allows for a Global PIN with reference 00 or a local pin with reference 80 to be use for pin[0] It defines which is preferred or which is the only one to use from the DISCOVERY object. (The prompt to the user
will say USER PIN or Global PIN, just incase they are different.

NIST says only the local PUK PIN (key_ref 81) can be used by the user to unlock/change the pin. Some PIV like cards may allow a Global PUK/Admin pin (key_ref 01) to be used as a PUK. This restriction was relaxed by removing pin_info.attrs.pin.reference == 0x80 The card should enforce this.

The point is when not run with minidriver, pkcs15 tools and routines will list only two pins. Only the minidriver sees a copy of the pin[0] as pin[2] so minidriver uses pin[2] when the 9C key is being used: usrr_consent > 0. The minidriver tests for need_pin_always.

[maciejsszmigiero]

I guess this should print need_pin_always only when it is being set (inside that if block)?

This value can be deducted from the above user_consent printout anyway.

[dengert]

I left the logprintf outside to show value of need_pin_always after the test.
the need_pin_always could be an array for each ROLE, if there is ever a third type of Sign Pin.