Suggested enhancement
Allow an X.509 certificate's public key to be a reference to a key held in PSA crypto storage (mbedtls_svc_key_id_t). With a reference, signature verification could be performed by key ID and delegated to the backing PSA driver, instead of the current pattern of storing the raw key, importing it into a transient PSA slot for every operation, and destroying it afterwards.
Two new capabilities are requested:
- Store public key reference for a parsed certificate: Allow a public key to live in PSA storage and be referenced by ID, instead of being imported on demand for each verification
- Verify by key ID: Make a verify path available to call
psa_verify_hash(key_id,...) directly for a referenced public key.
Currently, a private key can already be referenced for for cryptographic operations directly. For X.509 signature verification, however, the public key is stored in raw form in the application and imported into PSA before each verification operation. Additionally, an opaque ECDSA verify wrapper exists (ecdsa_opaque_verify_wrap) but does not delegate: it calls psa_export_public_key and then verifies locally by importing the key into PSA again.
Justification
The primary use case is a trust store provisioned by the integrator directly into crypto storage. By referencing keys with an ID, the trust anchor could reside in a secure tamper-resistant element and verification could be delegated to dedicated crypto hardware.
Confidentiality is not the goal. The strong use case is using an HSM or secure element to store cryptographic keys and offloading verification operations from software to dedicated hardware.
Suggested enhancement
Allow an X.509 certificate's public key to be a reference to a key held in PSA crypto storage (
mbedtls_svc_key_id_t). With a reference, signature verification could be performed by key ID and delegated to the backing PSA driver, instead of the current pattern of storing the raw key, importing it into a transient PSA slot for every operation, and destroying it afterwards.Two new capabilities are requested:
psa_verify_hash(key_id,...)directly for a referenced public key.Currently, a private key can already be referenced for for cryptographic operations directly. For X.509 signature verification, however, the public key is stored in raw form in the application and imported into PSA before each verification operation. Additionally, an opaque ECDSA verify wrapper exists (
ecdsa_opaque_verify_wrap) but does not delegate: it callspsa_export_public_keyand then verifies locally by importing the key into PSA again.Justification
The primary use case is a trust store provisioned by the integrator directly into crypto storage. By referencing keys with an ID, the trust anchor could reside in a secure tamper-resistant element and verification could be delegated to dedicated crypto hardware.
Confidentiality is not the goal. The strong use case is using an HSM or secure element to store cryptographic keys and offloading verification operations from software to dedicated hardware.