What is the right error code of C_DeriveKey if the derivation key has CKA_DERIVE=0 - pkcs#11

Question

I am developer of the PKCS#11 library. I think that the function C_DeriveKey should fail with the error code
CKR_KEY_FUNCTION_NOT_PERMITTED
if the key has CKA_DERIVE=0.But this error code is not listed as a possible return value for C_DeriveKey in the specification document . What is the right error code to be returned by C_DeriveKey in this case?

Answer 1

I agree that the specification is not very clear on this case. There is a newer version of the specification available (v3.0 from March 2020, link), but it does not bring more clarity on this. I would make the following considerations:
General note on return values
The introduction on return values in section 5.1 gives the following disclaimer (link):
Because of the complexity of the Cryptoki specification, it is recommended that Cryptoki applications attempt to give some leeway when interpreting Cryptoki functions’ return values. We have attempted to specify the behavior of Cryptoki functions as completely as was feasible; nevertheless, there are presumably some gaps. For example, it is possible that a particular error code which might apply to a particular Cryptoki function is unfortunately not actually listed in the description of that function as a possible error code.
The last part directly acknowledges that the list of possible return values for each function may be incomplete. For that reason, C_DeriveKey not listing CKR_KEY_FUNCTION_NOT_PERMITTED as a possible return code may not be authoritative, if there are other reasons for why the function should return this value.
Definition of the return codes
Section 5.1.6 gives the following definitions (link):
CKR_KEY_FUNCTION_NOT_PERMITTED: An attempt has been made to use a key for a cryptographic purpose that the key’s attributes are not set to allow it to do. For example, to use a key for performing encryption, that key MUST have its CKA_ENCRYPT attribute set to CK_TRUE (the fact that the key MUST have a CKA_ENCRYPT attribute implies that the key cannot be a private key). This return value has lower priority than CKR_KEY_TYPE_INCONSISTENT.
CKR_KEY_TYPE_INCONSISTENT: The specified key is not the correct type of key to use with the specified mechanism. This return value has a higher priority than CKR_KEY_FUNCTION_NOT_PERMITTED.
From this definition I would conclude that CKR_KEY_TYPE_INCONSISTENT is not the right return code for the scenario we are discussing, because it relates the mechanism to the "type" of the key. If we understand "type" in the sense of CKA_KEY_TYPE, it is completely unrelated to the attribute CKA_DERIVE.
Moreover, the attribute CKA_ENCRYPT is given as an example in the definition of CKR_KEY_FUNCTION_NOT_PERMITTED. This attribute is very similar to CKA_DERIVE, i.e. CKA_ENCRYPT controlling whether the key can be used for encryption and CKA_DERIVE controlling whether the key can be used for deriving. Thus, if CKR_KEY_FUNCTION_NOT_PERMITTED is the right return code for the case when CKA_ENCRYPT is not set, it seems reasonable that it would also be the right return code for the case when CKA_DERIVE is not set.
Reference implementations
I looked at some PKCS#11 libraries to check how they handle the case that C_DeriveKey is called on a key with CKA_DERIVE set to CK_FALSE. Most of the implementations I found do not implement the C_DeriveKey function at all (i.e. they always return CKR_FUNCTION_NOT_SUPPORTED). For the libraries that do implement this function, I observed the following behaviors:
OpenSC returns CKR_KEY_TYPE_INCONSISTENT (reference):
CK_ATTRIBUTE derive_attribute = { CKA_DERIVE, &can_derive, sizeof(can_derive) };
...
rv = object->ops->get_attribute(session, object, &derive_attribute);
if (rv != CKR_OK || !can_derive) {
rv = CKR_KEY_TYPE_INCONSISTENT;
goto out;
}
I also checked how OpenSC handles the other attributes that are similar to CKA_DERIVE. It seems the C_EncryptInit function is not implemented in OpenSC (presumably because this is a public key operation?), but C_DecryptInit is. This function implements a check for CKA_DECRYPT (reference), but returns CKR_KEY_TYPE_INCONSISTENT, which goes against the example that was given in the specification of CKR_KEY_FUNCTION_NOT_PERMITTED.
SoftHSMv2 returns CKR_KEY_FUNCTION_NOT_PERMITTED (reference):
// Check if key can be used for derive
if (!key->getBooleanValue(CKA_DERIVE, false))
return CKR_KEY_FUNCTION_NOT_PERMITTED;
openCryptoki: I could not find any check for CKA_DERIVE. They do check CKF_DERIVE against the feature flags of the mechanism and return CKR_MECHANISM_INVALID if the flag is not set (reference), i.e. if the mechanism does not support derivation, but this is not the same as checking CKA_DERIVE against the flags of the key.
illumos-gate (IllumOS being a fork of the discontinued OpenSolaris) also returns CKR_KEY_FUNCTION_NOT_PERMITTED in their soft-key implementation (reference):
/* Check to see if key object allows for derivation. */
if (!(basekey_p->bool_attr_mask & DERIVE_BOOL_ON)) {
rv = CKR_KEY_FUNCTION_NOT_PERMITTED;
goto clean_exit1;
}
Interestingly, in older version of their code they returned CKR_KEY_TYPE_INCONSISTENT instead, and then changed it to CKR_KEY_FUNCTION_NOT_PERMITTED in this commit. The relevant part of the commit message seems to be 6177650 Wrong error code returned when key does not allow requested operation. The ID refers to a ticket in the OpenSolaris bug tracker, which is no longer online. There is an archive of the bug tracker here, but it does not contain any information on this ticket, unfortunately.
Of these reference implementations, I would consider OpenSC to be the most authoritative, in terms of how widely they are used.
Conclusion
Based on the above considerations, I would consider CKR_KEY_FUNCTION_NOT_PERMITTED to be the appropriate return code for the scenario we are discussing. This is supported by the following arguments:
The specification explicitly acknowledges that the list of possible return code for each function might be incomplete. Therefore, CKR_KEY_FUNCTION_NOT_PERMITTED not being listed for C_DeriveKey is not a strong counter-argument.
The specification explicitly lists CKA_ENCRYPT as an example for when CKR_KEY_FUNCTION_NOT_PERMITTED is an appropriate return code. The attribute CKA_ENCRYPT is similar to CKA_DERIVE, so it seems plausible that the return code is also appropriate for CKA_DERIVE.
The specification of CKR_KEY_TYPE_INCONSISTENT suggest that it is about the relation between the mechanism and the key type, not about other key attributes.
OpenSC uses CKR_KEY_TYPE_INCONSISTENT for the scenario we are discussing, but also uses this return code for C_DecryptInit in the case that CKA_DECRYPT is not set, which goes against the example given in the specification of CKR_KEY_FUNCTION_NOT_PERMITTED.
OpenSolaris/IllumOS deliberately switched from CKR_KEY_TYPE_INCONSISTENT to CKR_KEY_FUNCTION_NOT_PERMITTED as the return code for the scenario we are discussing. This suggests they also considered the latter the more fitting return code.