mirror of
https://github.com/wolfSSL/wolfssl.git
synced 2026-08-22 20:33:26 +02:00
Andrew Hutchings
d75c09296c
The applet refuses to export a symmetric key object regardless of the policy attached at its creation: on SE051 applet 7.2.0 hardware, ReadObject on an HMACKey object whose attributes confirm an attached POLICY_OBJ_ALLOW_READ still fails with SW 0x6986, so a derived secret stored in an SE05x object can never be read back and the previous attach-a-read-policy approach cannot work (ZD 22212). Se05x_API_ECDHGenerateSharedSecret, which returns the shared secret directly in the APDU response, is accepted by the same applet. It is also what sss_se05x_derive_key_dh itself uses whenever the derived key object lives in a host keystore, so use it for the applet >= 7.2 ECDH offload instead of deriving into an SE05x object: pass the private key id and the peer public point, taken from the wolfSSL key when the peer is a software key or read back from the resident public key object otherwise. Montgomery points and secrets are byte swapped around the call, matching the middleware's own handling. The pre-7.2 flow is restructured but behaviorally unchanged (Binary derive target created by the middleware during the derive, read back afterwards), and drops fewer APDUs per derive on 7.2 since no target object is created, read or deleted. Verified on SE051 applet 7.2.0 hardware: ECC P-256 and X25519 shared secrets derive successfully in both directions, where the previous approach failed with SW 0x6986. The pre-7.2 path remains as validated on SE050C applet 3.1.1 hardware.