We are implementing key handling for the nRF5340 and have come across an inconsistency between the CC312 and Oberon key management drivers. I wanted to verify if this inconsistency is purposeful, and if so I am curious as to what the reasoning for the difference is. This behavior was observed on both NCS 3.2.0 and NCS 3.4.0.
I was writing a quick test to ensure that if we passed a raw public key to psa_import_key() that did not belong on the curve of the specified algorithm, then we would be able to catch it before we attempted any asymmetric operation with it. The test was similar to the the following:
static bool is_public_key_rejected(const uint8_t raw[PUBKEY_SIZE])
{
/* Start from a non-NULL handle so the check shows that a failed import clears it */
psa_key_id_t key_handle = STALE_KEY_HANDLE;
psa_key_attributes_t attrs = PSA_KEY_ATTRIBUTES_INIT;
psa_set_key_lifetime(&attrs, PSA_KEY_LIFETIME_VOLATILE);
psa_set_key_type(&attrs, PSA_KEY_TYPE_ECC_PUBLIC_KEY(PSA_ECC_FAMILY_SECP_R1));
psa_set_key_bits(&attrs, 256U);
psa_set_key_usage_flags(&attrs, PSA_KEY_USAGE_VERIFY_MESSAGE);
psa_set_key_algorithm(&attrs, PSA_ALG_ECDSA(PSA_ALG_SHA_256));
/* psa_import_key rejects an off-curve point and sets *key_handle to PSA_KEY_ID_NULL on failure */
psa_status_t status = psa_import_key(&attrs, raw, PUBKEY_SIZE, key_handle);
psa_reset_key_attributes(&attrs);
if (status == 0)
{
/* PSA accepted faulty key, don't let it stick around */
(void)psa_destroy_key(key_handle);
return false;
}
return (key_handle == PSA_KEY_ID_NULL);
}
We had two test cases: One was feeding a zeroized buffer to is_public_key_rejected, the other was taking a valid point on the curve and flipping a bit and then feeding it to is_public_key_rejected.
When CONFIG_PSA_USE_CC3XX_KEY_MANAGEMENT_DRIVER=y, then psa_import_key returns 0 for both of those cases, meaning that key import was successful. When CONFIG_PSA_USE_CC3XX_KEY_MANAGEMENT_DRIVER=n, then psa_import_key returns PSA_ERROR_INVALID_ARGUMENT, meaning that key import was rejected (the behavior I was expecting).
We would prefer using the CC312 whenever possible for crypto operations, but this gap in functionality between CC312 and Oberon drivers is frustrating. Is this gap a byproduct of CC312 capabilities or is this a bug in the CC312 driver? If neither, why does the Oberon driver validate keys on import more strictly than the CC312 driver?