Mbed TLS 4 a déplacé sa cryptographie dans TF-PSA-Crypto et l’API PSA Crypto (psa_sign_message, psa_verify_message, psa_generate_key), la même API que celle de Trusted Firmware d’Arm. Les faits présentés ici ont été vérifiés sur le paquet Alpine 3.24.2, Mbed TLS 4.1.1 (le projet amont en était à la 4.2.0) ; les fonctionnalités dépendent de la configuration du build, comme pour toute bibliothèque embarquée.
C’est l’encodage des signatures qui diffère du code dérivé d’OpenSSL : PSA renvoie la forme r‖s brute, 64 octets sur P-256, et non du DER. Les signatures destinées à X.509, à CMS ou à un vérificateur OpenSSL doivent être converties en DER, et les signatures DER provenant de ces pairs doivent être reconverties en r‖s brut avant psa_verify_message, qui renvoie sinon PSA_ERROR_INVALID_SIGNATURE, le même statut que pour une signature contrefaite ou un bloc de 3 octets. Convertissez-les avec le convertisseur DER ⇄ brut.
Chaque clé porte une politique qui n’autorise qu’un seul algorithme : le choix entre PSA_ALG_ECDSA (nonce aléatoire) et PSA_ALG_DETERMINISTIC_ECDSA (RFC 6979, dont le vecteur de test a été reproduit) se fait donc à la création de la clé, comme le montre l’exemple. s n’est pas normalisé et la vérification accepte high-S. psa_sign_hash signe un condensat précalculé.
Ce build a signé et vérifié avec P-256, P-384, P-521, secp256k1 et les courbes Brainpool r1 ; P-224 n’était pas disponible, et la génération de clés Ed25519 a été refusée (PSA_ERROR_NOT_SUPPORTED). La prise en charge post-quantique se limite à la vérification de signatures fondées sur le hachage LMS (MBEDTLS_LMS_C) ; il n’existe aucun type de clé ML-KEM ou ML-DSA, et le pilote ML-DSA expérimental issu de mldsa-native (TF_PSA_CRYPTO_PQCP_MLDSA_ENABLED) est commenté dans la configuration de ce build. Les clés publiques s’exportent via PSA en points SEC1 sous forme non compressée, et en SPKI DER via la couche pk.