RE: C_SetPIN with multiple PINs; authenticated CKO

All,

I canât answer since after reading the base spec Iâve more questions than answersâ

3.0 spec talks about CKU_CONTEXT_SPECIFIC in the context of the CKA_ALWAYS_AUTHENTICATE attribute only and says: âRe-authentication occurs by calling C_Login with userType set to CKU_CONTEXT_SPECIFIC immediately after a cryptographic operation using the key has been initiated (e.g. after C_SignInit). In this call, the actual user type is implicitly given by the usage requirements of the active key. If C_Login returns CKR_OK the user was successfully authenticated and this sets the active key in an authenticated state that lasts until the cryptographic operation has successfully or unsuccessfully been completed (e.g. by C_Sign, C_SignFinal,..).â

CKA_ALWAYS_AUTHENTICATE says that âthe user has to supply the PIN for each use (sign or decrypt) with the keyâ. I would assume now that this is the PIN of the cryptographic user. Thus, I donât see how âmultiple PIN codesâ can be supported here. Moreover, there is no way to initially specify these additional PINs. Or is it missing? Or outside of the standard?

Why does the standard say âthe actual user type is implicitly given by the usage requirements of the active keyâ? If âuseâ means âa cryptographic operation such as sign or decryptâ this is always the CU and never the SO. The only modification to a key a SO can perform is setting the CKA_TRUSTED attribute, but this is a public key object for which the CKA_ALWAYS_AUTHENTICATE attribute does not exist. Is there a contradiction in the standard?

Itâs interesting that CKA_ALWAYS_AUTHENTICATE does not exist for secret key objects. Does this make sense?

Access control of CKO_DATA objects is done through the CKA_PRIVATE available to every storage object. But there are not special sensitive attributes and âsensitivity controlâ such as CKA_SENSITIVE. I donât think itâs necessary.

Can someone comment?

Best,

Daniel

From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> On Behalf Of Fenwick, Valerie
Sent: Mittwoch, 5. Juni 2019 17:43
To: pkcs11@lists.oasis-open.org
Subject: [pkcs11] FW: C_SetPIN with multiple PINs; authenticated CKO_DATA handling

Hi folks

I didnât see this come by the reflector, so I am forwarding it.

Is someone willing to generate a response for Wouter?

Valerie

From: pkcs11-comment@lists.oasis-open.org <pkcs11-comment@lists.oasis-open.org> On Behalf Of Wouter Verhelst
Sent: Wednesday, April 10, 2019 6:14 AM
To: pkcs11-comment@lists.oasis-open.org
Subject: [pkcs11-comment] C_SetPIN with multiple PINs; authenticated CKO_DATA handling

Hi,

PKCS#11 v2.30 introduces a new CKU_CONTEXT_SPECIFIC user, which is useful for tokens that have multiple PIN codes; a user of the PKCS#11 module can do C_SignInit followed by C_Login with user type CKU_CONTEXT_SPECIFIC so as to allow the PKCS#11 module to know which PIN code is being requested.

This works well for signature operations, but it does not define how a user should select which PIN to change with C_SetPIN. A method of C_Login with CKU_CONTEXT_SPECIFIC followed by a C_SetPIN would seem to be the obvious answer, except that this would result in having to send the PIN code to the PKCS#11 module twice; or, in the case of a token with CKF_PROTECTED_AUTHENTICATION_PATH being set, in the user being asked the same (old) PIN code twice. This is not an ideal situation.

The CKU_CONTEXT_SPECIFIC method could also be used to authenticate to a token that requires a PIN code in order to be able to access sensitive data through CKO_DATA object searches. However, in order to be able to do that properly, either C_FindObjectsInit or C_FindObjects (or, preferably, both) should be able to return CKR_USER_NOT_LOGGED_IN. In version 2.40 of the standard, this is not allowed.

I have been looking for a draft version of PKCS#11 v3.0, but have only been able to find the github repository, which contains a whole lot of new identifiers but no actual standard text.

Is the PKCS#11 committee aware of these issues? If so, are there any plans to remedy them?

Thanks,

pkcs11 message