gh-Mbed-TLS/TF-PSA-Crypto

Watch

Fork 0

Custom key generation parameters for non-RSA key types to use in opaque drivers #650

New issue

Open

opened 2026-01-12 05:32:50 -06:00 by Harshal5 · 6 comments

Harshal5 commented

2026-01-12 05:32:50 -06:00

(Migrated from github.com)

Allow custom key generation parameters for non-RSA key types in `psa_generate_key_custom()`

Summary

While implementing an opaque ECDSA key generation driver, I ran into a limitation where custom key generation parameters are rejected for all non-RSA key types, even when psa_generate_key_custom() is called directly (i.e., not via psa_generate_key()).

This behavior currently prevents opaque drivers from supporting vendor-specific or hardware-specific key generation parameters (e.g., hardware key slot indices, key labels, security attributes) for key types such as ECDSA.

Background / Use Case

The opaque driver needs to accept custom production parameters for ECDSA key generation, for example:

Selecting a hardware key slot or handle
Applying vendor-specific security policies
Passing driver-specific metadata required by secure hardware

The driver is capable of validating and consuming these parameters, but the PSA core blocks them before the driver is invoked.

As a result, custom parameters are effectively unusable for ECDSA (and other non-RSA types).

Current Behavior

In psa_generate_key_custom() (psa_crypto.c), there is a blanket validation that rejects non-default custom parameters for all non-RSA key types, even when the API is called directly and not through psa_generate_key():

Core check:
https://github.com/Mbed-TLS/TF-PSA-Crypto/blob/development/core/psa_crypto.c#L8248-L8250
Similar validation in the driver wrapper template:
https://github.com/Mbed-TLS/TF-PSA-Crypto/blob/development/scripts/data_files/driver_templates/psa_crypto_driver_wrappers.h.jinja#L679-L681

Design Intent

The documentation for psa_custom_key_parameters_are_default() in psa_crypto_core.h states:

“Calls to a key generation driver with non-default custom production parameters require a driver supporting custom production parameters.”

This suggests that the intent is for drivers to decide whether they support custom parameters, rather than the PSA core enforcing a key-type-based restriction.

Proposed Solutions

Introduce an internal helper, for example: psa_generate_key_custom_internal(..., bool check_default_params);

psa_generate_key() would call this with check_default_params = true
psa_generate_key_custom() would call it with check_default_params = false

This preserves the stricter behavior of psa_generate_key() while allowing advanced use cases through psa_generate_key_custom().

## Allow custom key generation parameters for non-RSA key types in `psa_generate_key_custom()` ### Summary While implementing an **opaque ECDSA key generation driver**, I ran into a limitation where **custom key generation parameters are rejected for all non-RSA key types**, even when `psa_generate_key_custom()` is called directly (i.e., not via `psa_generate_key()`). This behavior currently prevents opaque drivers from supporting vendor-specific or hardware-specific key generation parameters (e.g., hardware key slot indices, key labels, security attributes) for key types such as ECDSA. ### Background / Use Case The opaque driver needs to accept **custom production parameters** for ECDSA key generation, for example: - Selecting a hardware key slot or handle - Applying vendor-specific security policies - Passing driver-specific metadata required by secure hardware The driver is capable of validating and consuming these parameters, but the PSA core blocks them before the driver is invoked. As a result, custom parameters are effectively unusable for ECDSA (and other non-RSA types). ### Current Behavior In `psa_generate_key_custom()` (`psa_crypto.c`), there is a blanket validation that rejects non-default custom parameters for all non-RSA key types, even when the API is called directly and not through `psa_generate_key()`: - Core check: https://github.com/Mbed-TLS/TF-PSA-Crypto/blob/development/core/psa_crypto.c#L8248-L8250 - Similar validation in the driver wrapper template: https://github.com/Mbed-TLS/TF-PSA-Crypto/blob/development/scripts/data_files/driver_templates/psa_crypto_driver_wrappers.h.jinja#L679-L681 --- ### Design Intent The documentation for `psa_custom_key_parameters_are_default()` in `psa_crypto_core.h` states: > “Calls to a key generation driver with non-default custom production parameters require a driver supporting custom production parameters.” This suggests that the intent is for **drivers to decide whether they support custom parameters**, rather than the PSA core enforcing a key-type-based restriction. --- ### Proposed Solutions Introduce an internal helper, for example: `psa_generate_key_custom_internal(..., bool check_default_params);` - `psa_generate_key()` would call this with `check_default_params` = true - `psa_generate_key_custom()` would call it with `check_default_params` = false This preserves the stricter behavior of `psa_generate_key()` while allowing advanced use cases through `psa_generate_key_custom()`.

gilles-peskine-arm commented

2026-01-12 13:13:48 -06:00

(Migrated from github.com)

Note that key import or unwrap does not use custom production parameters, because the key material is already fully determined.

Selecting a hardware key slot or handle

Applying vendor-specific security policies

Passing driver-specific metadata required by secure hardware

All of these are captured by attributes, when the core understands them. They would apply to any key creation method (import, generate, derive, unwrap, …). So this is really a request for supporting driver-specific attributes.

This was not an intended use case for custom production parameters, and I don't think they're the right tool for the job. The intent of production parameters is to choose between different ways of creating key material, for example picking a specific public exponent for an RSA key, or picking one of several ways of deriving key material deterministically. Furthermore, the meaning of production parameters is supposed to be the same on all implementations (assuming they support the specific parameters — that's what the note about “require a driver supporting custom production parameters” means). Note that key import or unwrap does not use custom production parameters, because the key material is already fully determined. > * Selecting a hardware key slot or handle > * Applying vendor-specific security policies > * Passing driver-specific metadata required by secure hardware All of these are captured by attributes, when the core understands them. They would apply to any key creation method (import, generate, derive, unwrap, …). So this is really a request for supporting driver-specific attributes.

👍 1

gilles-peskine-arm commented

2026-01-12 13:17:20 -06:00

(Migrated from github.com)

We may want to standardize the way drivers declare their attributes and the way they are related from applications through a core to a driver, so I've filed a companion issue against the PSA specifications (crypto API and crypto driver): https://github.com/ARM-software/psa-api/issues/326

❤️ 1

Harshal5 commented

2026-01-12 23:00:52 -06:00

(Migrated from github.com)

@gilles-peskine-arm Thanks for looking into this so quickly and for raising the companion issue with the PSA specifications. I’ll follow the discussion on https://github.com/ARM-software/psa-api/issues/326 and am happy to provide input if needed.

mpg commented

2026-01-13 03:44:23 -06:00

(Migrated from github.com)

Question: should we keep the present issue open, or close it as the discussion/work will be happening in the psa-api repo?

Harshal5 commented

2026-01-13 03:50:22 -06:00

(Migrated from github.com)

@mpg Sure since the discussion is moving to the psa-api repo, I’m fine with closing this issue and tracking updates there. We can always reopen or file a follow-up here if something actionable comes out of that discussion for this project. Thanks!

gilles-peskine-arm commented

2026-01-13 04:33:24 -06:00

(Migrated from github.com)

Regardless of whether this ends up being standardized or not, this is a feature request against TF-PSA-Crypto, so we should keep the issue opened. It might end up being resolved by implementing a standard feature or a proprietary feature.

👍 2

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

gh-Mbed-TLS/TF-PSA-Crypto#650

No description provided.

Rows
Columns

Custom key generation parameters for non-RSA key types to use in opaque drivers #650

Allow custom key generation parameters for non-RSA key types in psa_generate_key_custom()

Summary

Background / Use Case

Current Behavior

Design Intent

Proposed Solutions

Allow custom key generation parameters for non-RSA key types in `psa_generate_key_custom()`