You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Silicon Labs crypto callback port: wc_SilabsSe_*UseWrappedKey() cannot bind wrapped keys created with other flags #11686
wc_SilabsSe_AesUseWrappedKey() and wc_SilabsSe_EccUseWrappedKey() (PR #11267) hard-code the descriptor flags of the key they bind: NON_EXPORTABLE for AES, and HAS_PRIVATE_KEY | NON_EXPORTABLE for ECC. The Secure Engine checks a wrapped key's flags against the flags it was wrapped with. So a wrapped blob created by the application through the SE Manager with any other flags cannot be bound:
an exportable key, which the application still needs to read back in plaintext;
an ECC key marked SIGNING_ONLY (see the companion issue on signing).
The ECC bind fails outright. The AES bind returns 0, and the first cipher operation then fails.
/* P-256, exportable private key, flags HAS_PRIVATE_KEY only *//* ... sl_se_generate_key() into a wrapped descriptor with those flags ... */ecc_keykey;
wc_ecc_init_ex(&key, NULL, WOLFSSL_SILABS_DEVID);
wc_SilabsSe_EccUseWrappedKey(&key, wrapped, 32+SLI_SE_WRAPPED_KEY_OVERHEAD,
ECC_SECP256R1); /* fails: the public-point export in silabs_ecc_bind_pubkey() is refused */
Expected
A way to bind a wrapped key the application created with its own flags, so the Secure Engine uses it through wolfCrypt with the flags it was wrapped with.
The Secure Engine refuses the mismatched key, which the port reports as a wolfCrypt error (WC_HW_E for the AES operation). Binding the same blobs with descriptors that carry their real flags works: AES-ECB reproduces the FIPS-197 vector, and ECDH gives the expected shared secret, both run on the Secure Engine.
Why it matters
The port's own generators only make non-exportable keys, which suits keys that must never leave the device. Applications can also have keys that are wrapped at rest but must remain exportable, for example a key store whose contract includes reading the plaintext back. For those, the flags belong to the application. Today the only way to bind such a key is to fill in the ecc_key / Aes fields the port sets internally (cmd_ctx, key, silabsKeySet, key_raw, keyInstalled, ctx.keySet) and replicate silabs_ecc_bind_pubkey(), which depends on internals.
Suggested fix
Variants that take the flags, or the caller's own sl_se_key_descriptor_t, for example:
The same Ex form could carry the signing/agreement choice from the companion issue. Alternatively, document that the binders only accept keys from the port's own generators.
Contact Details
lucas.holzen@mmbnetworks.com
Version
commit f6a75d4
Description
wc_SilabsSe_AesUseWrappedKey()andwc_SilabsSe_EccUseWrappedKey()(PR #11267) hard-code the descriptor flags of the key they bind:NON_EXPORTABLEfor AES, andHAS_PRIVATE_KEY | NON_EXPORTABLEfor ECC. The Secure Engine checks a wrapped key's flags against the flags it was wrapped with. So a wrapped blob created by the application through the SE Manager with any other flags cannot be bound:SIGNING_ONLY(see the companion issue on signing).The ECC bind fails outright. The AES bind returns 0, and the first cipher operation then fails.
Environment
f6a75d4aaf2a50eabf30b5718300d68578e26101(merge of Add Silicon Labs EFR32xG25 Secure Element crypto callback port #11267)arm-none-eabi-gcc14.2.rel1, FreeRTOSuser_settings.h:WOLFSSL_SILABS_CRYPTOCB(all engines),HAVE_ECC,HAVE_AES_ECB,WOLFSSL_AES_DIRECTReproduction steps
Wrap a key with the SE Manager, without
SL_SE_KEY_FLAG_NON_EXPORTABLE, then bind it through the port:Expected
A way to bind a wrapped key the application created with its own flags, so the Secure Engine uses it through wolfCrypt with the flags it was wrapped with.
Actual
The descriptor always carries the port's flags:
silabs_key.cL240,wc_SilabsSe_AesUseWrappedKey():NON_EXPORTABLEsilabs_key.cL492-L493,wc_SilabsSe_EccUseWrappedKey():HAS_PRIVATE_KEY | NON_EXPORTABLEThe Secure Engine refuses the mismatched key, which the port reports as a wolfCrypt error (
WC_HW_Efor the AES operation). Binding the same blobs with descriptors that carry their real flags works: AES-ECB reproduces the FIPS-197 vector, and ECDH gives the expected shared secret, both run on the Secure Engine.Why it matters
The port's own generators only make non-exportable keys, which suits keys that must never leave the device. Applications can also have keys that are wrapped at rest but must remain exportable, for example a key store whose contract includes reading the plaintext back. For those, the flags belong to the application. Today the only way to bind such a key is to fill in the
ecc_key/Aesfields the port sets internally (cmd_ctx,key,silabsKeySet,key_raw,keyInstalled,ctx.keySet) and replicatesilabs_ecc_bind_pubkey(), which depends on internals.Suggested fix
Variants that take the flags, or the caller's own
sl_se_key_descriptor_t, for example:The same
Exform could carry the signing/agreement choice from the companion issue. Alternatively, document that the binders only accept keys from the port's own generators.Relevant log output