STM32H573 Secure Manager: psa_generate_key() returns PSA_ERROR_NOT_PERMITTED (-129) for volatile ECC/AES keys
Hello,
I am using an STM32H573 with Secure Manager and Mbed TLS / PSA Crypto for a TLS 1.3 implementation.
Persistent private keys provisioned into the Secure Manager work correctly. For example, I have a persistent P-256 private key provisioned through the ITS Factory Blob and can successfully use it for ECDSA signing.
The problem occurs when Mbed TLS tries to dynamically generate temporary keys during the TLS 1.3 handshake.
For example, a call similar to:
psa_key_attributes_t attributes = PSA_KEY_ATTRIBUTES_INIT;
psa_key_id_t keyId;
psa_set_key_type(
&attributes,
PSA_KEY_TYPE_ECC_KEY_PAIR(PSA_ECC_FAMILY_SECP_R1));
psa_set_key_bits(&attributes, 256U);
psa_set_key_usage_flags(
&attributes,
PSA_KEY_USAGE_DERIVE);
psa_set_key_algorithm(
&attributes,
PSA_ALG_ECDH);
status = psa_generate_key(
&attributes,
&keyId);returns:
PSA_ERROR_NOT_PERMITTED
-129The same behavior can also be reproduced with dynamically generated AES keys, so it does not seem to be specific to ECC.
Some additional observations:
psa_generate_random()works correctly.- ECDSA signing with persistent provisioned P-256 keys works correctly.
- Communication with the Secure Manager is working.
- The request reaches the Secure Manager and the returned PSA status itself is
-129. - Dynamically creating volatile PSA keys using
psa_generate_key()fails. psa_import_key()for dynamically created keys also fails in our configuration.
This becomes a problem with TLS 1.3 because Mbed TLS normally creates an ephemeral ECDHE key using PSA Crypto during the handshake.
As an experiment, I provisioned an additional persistent P-256 key into the Secure Manager with:
Key type: SECP_R1 / P-256
Usage: DERIVE
Algorithm: PSA_ALG_ECDH
Lifetime: PersistentThe stock ITSBuilder does not allow SECP_R1 + DERIVE, although PSA itself uses the same PSA_KEY_TYPE_ECC_KEY_PAIR(PSA_ECC_FAMILY_SECP_R1) key type for ECDSA and ECDH. Therefore, I extended the ITSBuilder to permit this combination.
The resulting ITS entry is:
SECP_R1 ECDH KEY PAIR key -256b
Id: 0x00000054
owner: 0xFFFFFFFF
persistence: PERSISTENT
usage(s): DERIVE
algorithm: 0x09020000
data length: 32I then tested this key directly with:
status = psa_raw_key_agreement(
PSA_ALG_ECDH,
(psa_key_id_t)0x54U,
peerPublicKey,
peerPublicKeyLength,
sharedSecret,
sizeof(sharedSecret),
&sharedSecretLength);and this call returns:
PSA_SUCCESSwith a valid 32-byte ECDH shared secret.
So the Secure Manager is clearly capable of performing P-256 ECDH with a persistent key, while dynamically generating the same kind of key using psa_generate_key() is rejected.
My questions are:
- Is dynamic/volatile key generation using
psa_generate_key()intentionally unsupported by the STM32H573 Secure Manager? - Is this a limitation of the supplied Secure Manager binary/configuration?
- Is there a configuration option or provisioning setting required to enable volatile ECC/AES key generation?
- Is there an officially supported way to use TLS 1.3 ECDHE with Mbed TLS when PSA Crypto is routed through Secure Manager?
- Is provisioning a persistent P-256 ECDH key and using
psa_raw_key_agreement()the intended workaround, or is there another recommended approach?
The main issue is that standard Mbed TLS TLS 1.3 expects to create ephemeral ECDHE keys dynamically. At the moment, this fails because psa_generate_key() returns PSA_ERROR_NOT_PERMITTED.
Any information about the Secure Manager's supported PSA key-management operations or limitations would be very helpful.
Thanks!
