OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11-comment message

[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

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

                  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]