[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: CKA_ALWAYS_AUTHENTICATE usability issues
In §4.9 of the v2.40 specification, it states of CKA_ALWAYS_AUTHENTICATE that "This attribute may only be set to CK_TRUE when CKA_PRIVATE is also CK_TRUE." So in order to perform a C_FindObjects() to locate a key, and then immediately use it for a crypto operation, it would be necessary for the user to provide the same PIN twice in quick succession. If the key did not suffer the CKA_PRIVATE attribute, and was permitted to have only the CKA_ALWAYS_AUTHENTICATE attribute, then this would not be a problem. It would be *visible* to the C_FindObjects() call without a C_Login(), and then the user is required to provide the PIN once for each actual *usage* of the key. Surely that seems like a reasonable usage model? Why do we require that CKA_PRIVATE be set? Can this restriction be relaxed? A nasty workaround exists for this situation: Some tokens set CKA_ALWAYS_AUTHENTICATE on a key when the word 'always' in it isn't actually true — under *some* circumstances they might actually permit a crypto operation to complete without returning CKR_USER_NOT_LOGGED_IN. The popular PIV token can be operated this way — the *hardware* needs a VERIFY operation immediately prior to use of the SIGN key, but doesn't care whether at the PKCS#11 level that VERIFY operation was triggered by a CKU_USER login, or a CKU_CONTEXT_SPECIFIC one. So if the PKCS#11 usage flow involves C_Login(CKU_USER), C_FindObjects(), C_Sign(), then as far as the PIV hardware is concerned that final C_Sign() can actually happen *without* any reauthentication. The PKCS#11 provider in that case can simply let it succeed without returning CKR_USER_NOT_LOGGED_IN. One can also imagine hardware devices which require reauthentication after a timeout — so having entered the PIN, the device can be used for a number of crypto operations for a number of seconds or minutes, before it demands the PIN again. Applications can happily support this model by simply pretending they 'forgot' the CKA_ALWAYS_AUTHENTICATE attribute was set, and attempting the crypto operation anyway. If it works, all well and good. And if it return CKR_USER_NOT_LOGGED_IN, they go ahead with the CKU_CONTEXT_SPECIFIC login as required. Is this workaround a reasonable one — or are tokens *required* to return CKR_USER_NOT_LOGGED_IN in that case? Or are applications *required* to perform the CKU_CONTEXT_SPECIFIC login, and never to actually trigger the CKR_USER_NOT_LOGGED_IN response that is defined in the spec? If not considered reasonable, can it be *made* so in a subsequent update to the spec? Perhaps by a CKA_SOMETIMES_REAUTHENTICATE option (with a better name, perhaps), or by some other method? From the token's point of view, one potential justification (albeit somewhat tongue-in-cheek) for the "sometimes I make you reauthenticate, sometimes I don't" model is to claim that the CKA_ALWAYS_AUTHENTICATE attribute has temporarily been set to CK_FALSE on the key in question... -- -- Sent with Evolution's ActiveSync support. David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]