PROTECTED_AUTHENTICATION_PATH flag

[MatthiasValvekens]

Hi, I have a question related to the eID PKCS#11 module. If my understanding is correct, the module ordinarily manages PIN entry dialogs separately from the Cryptoki/PKCS#11 interface, right? Unless compiled with NO_DIALOGS, that is.

Is there any particular reason why the PROTECTED_AUTHENTICATION_PATH flag is not set on the token (when not compiled with NO_DIALOGS)? The flag's description seems to be pretty fitting:

True if token has a “protected authentication path”, whereby a user can log into the token without passing a PIN through the Cryptoki library.

The reason I ask is because someone filed an issue on one of my repositories (MatthiasValvekens/pyHanko#133) with a proposed change to a piece of PKCS#11-related code, and in the process of investigating that, I noticed that the eID PCKS#11 module apparently doesn't set the LOGIN_REQUIRED flag, as an alternative for setting PROTECTED_AUTHENTICATION_PATH + LOGIN_REQUIRED. I was just wondering what the rationale behind that design choice was, so I can take it into account: it potentially affects the way I need to call python-pkcs11.

I have some guesses in mind, but I figured I might as well just ask.

Thanks a lot!

---

PS: Now, I actually wonder if setting PROTECTED_AUTHENTICATION_PATH would cause applications like Acrobat to hide their own PIN prompts---they don't do anything anyway. Maybe I should try building the module with that flag enabled, just to see what would happen...

[Frederikus]

Hello Matthias,

When building the pkcd#11 module without the NO_DIALOG flag set, it will handle the PIN dialog UI when needed. It will not show the UI in cases of a secure PINpad reader, as the PINpad reader will handle the PIN entry itself. ( The CKF_PROTECTED_AUTHENTICATION_PATH flag is used to indicate this usecase).

The reason that the pkcs#11 does not start by asking the PIN, is that the card itself remembers if the permission to use the authentication key (PIN protected) was granted. So if e.g. any other app. has already done this PIN verification for use of the authentication key, the card caches this permission, and no further PIN entry for use of the authentication key is needed. That is why the pkcs#11 first tries if it cannot use the authentication key without PIN verification, if it notices it cannot, then it will ask for the PIN.

I hope this clarifies the behaviour a bit

[MatthiasValvekens]

Thank you, @Frederikus , that answers most of my question.

So, would it be correct to say that CKF_PROTECTED_AUTHENTICATION_PATH is only used if the module handles its own PIN entry on calls to C_Login, and that the eID middleware doesn't require C_Login but will prompt for PIN entry when the card requests it? The PIN entry behaviour is also different for the signing and authentication keys, right?

---

PS: FWIW, the user who filed that issue I linked above wasn't actually asking about the eID specifically. The PKCS#11 signing code I wrote works with the eID, but not with that person's security device (one with a built-in PIN pad). I was trying to get to the bottom of why they behaved differently. I realise now that that wasn't clear from the question I asked.

[Frederikus]

Hi Mathias,

If the PIN pad reader handles the PIN, the pkcs#11 library only shows a UI stating to enter the PIN on the PIN pad reader, but in this case the pkcs#11 does no PIN handling itself. The middleware should ask for the PIN when you try to authenticate, but the card PIN was not entered before.

Indeed, usage of the non-repudiation key requires a PIN entry right before signing, it does not cache the permission.

[MatthiasValvekens]

Right, I think that answers everything. When maintaining a general-purpose signing lib that needs to be able to interoperate with many different PKCS#11 backends, it's sometimes difficult to match user expectations with what PKCS#11 libs does under the hood. Having this kind of background info helps me gauge what to expect, which is extremely helpful.

Thanks a lot; much appreciated!