SE052 adoption questions: EdDSA/X25519 availability, non-FIPS variant roadmap, applet limits Hello, We currently use the SE050E2 (applet 7.2.0, die reports "SE051" in the ATR, AppletConfig 0x3F9F) in two designs, and we are evaluating the SE052 for the next hardware revision. Before committing, we read the SE052 data sheet (Rev 1.5), AN14028, AN14277, AN13904, AN12543 (Rev 4.5) and the Plug & Trust MW documentation (AN13030 Rev 2.7), and a few points block the decision. We would appreciate clarification. Our two use cases: A mesh/transport node (LoRa + Ethernet) whose identity is an X25519 + Ed25519 key pair generated and used inside the SE (ECDH via ECDHGenerateSharedSecret on ID_ECC_MONT_DH_25519, signing via EdDSASign with ED25519PURE_SHA_512). A signing device using secp256k1 ECDSA (pre-computed digest) and Ed25519 for different targets, with a UserID-protected session. Questions: Variants. AN14277 states that SE052F (OEF B501, FIPS 140-3) is "the only released variant", and its GetInfo shows WithOut EDDSA / WithOut DH_MONT. Is there any roadmap for a non-FIPS SE052 configuration (equivalent to SE050E / SE051 with CONFIG_EDDSA and CONFIG_DH_MONT enabled)? If so, approximate timeframe and OEF? Enabling EdDSA / Montgomery DH on SE052F. Since SetAppletFeatures requires RESERVED_ID_FEATURE (0x7FFF0204), which is NXP-owned, is there any customer path to enable Ed25519/X25519 on SE052F (e.g. a custom configuration through EdgeLock 2GO), accepting loss of FIPS-approved mode? Or does the FIPS OS build block those curves regardless of the applet feature bits? FIPS and EdDSA. FIPS 186-5 approves EdDSA. Is there a plan for a future SE052 applet/OS version (via SEMS Lite or a new OEF) that supports Ed25519 and X25519 while remaining FIPS 140-3 approved? APDU throughput limit. AN14028 §2.3.1 / AN13904 §8.4 describe the 1,000,000 APDU / 34-day limit (SW 66A6) and the FIPS self-test every 500,000 APDUs. Are these tied to the FIPS certification only, and would they be absent in a hypothetical non-FIPS SE052 variant? Is a reset via RST_N enough to clear the counter with no NVM impact? Applet feature roadmap for signing use cases. We could not find any of the following in AN12543 Rev 4.5. Are any planned for the 7.2.x line or a future applet? Hardened child-key derivation inside the SE (scalar addition mod n, BIP32-style), so derived private keys never leave the chip. Schnorr signatures (BIP340) on secp256k1. Deterministic ECDSA nonces (RFC 6979) and/or low-S normalisation. Pre-hashed Ed25519 (Ed25519ph) or a streaming EdDSA mode, so messages longer than the IFSC (0xFE) do not depend on T=1 chaining. UserID behaviour on applet 7.2.22. On SE050E2 (7.2.0) we observed that a UserID object whose TAG_MAX_ATTEMPTS is exhausted can no longer be deleted (DeleteSecureObject → 6986 even over Platform SCP03), and the attempts counter attribute always reads 0. AN14028 Table 1 says the attributes now show the maximum number of attempts. On 7.2.22: (a) is the remaining/used counter reported? (b) can an exhausted UserID be deleted by the SCP03 platform user? ECDH NVM wear (applies to our current SE050E2 too). AN12543 §4.10.3 says ECDHGenerateSharedSecret on MONT_DH_25519 writes NVM on each call when the public key is passed as a byte array (TAG_2), but not when passed via a transient ECPublicKey object (TAG_3). Can you confirm this also holds for SE050E with applet 7.2.0, and that updating the transient object's content with WriteECKey between calls does not itself write NVM? Longevity. Is the SE050E2 covered by NXP's product longevity program, and is there any planned EOL? This decides whether we stay on SE050E2 for the next revision. Thank you in advance. SE050 Re: SE052 adoption questions: EdDSA/X25519 availability, non-FIPS variant roadmap, applet limits Hi @cvaldess ,
Thank you for the reaching out! Let me work through each one.
Q1 — Non-FIPS SE052 variant roadmap
As you correctly identified, SE052F (OEF B501) is currently the only released SE052 variant, and its AppletConfig 0x26F2 does not include EdDSA or DH_MONT. We cannot share specific roadmap timelines on a public forum, but I recommend reaching out to your local Disti/NXP FAE to discuss your requirements under NDA, where roadmap details can be addressed directly.
Q2 — Enabling EdDSA / Montgomery DH on SE052F
There is no customer path to enable these algorithms on SE052F. RESERVED_ID_FEATURE (0x7FFF0204) is an NXP-owned object and cannot be modified or deleted by customers — EdgeLock2GO is not a mechanism for enabling it. More fundamentally, the SE052F FIPS 140-3 OS build excludes Twisted Edwards (Ed25519) and Montgomery (Curve25519) curve support at the OS/hardware level as part of the certified configuration. Even loading a custom applet via SEMS Lite cannot re-enable curves absent from the OS layer — and doing so would in any case render the module non-FIPS compliant, as AN14277 explicitly notes.
Q3 — FIPS 140-3 + EdDSA in a future SE052 applet/OEF
FIPS 186-5 (Feb 2023) does approve EdDSA, so the standards basis exists. However, any SE052 OEF supporting Ed25519/X25519 under a new FIPS 140-3 certificate would require a full CMVP recertification submission. We are not in a position to confirm plans or timelines on a public forum. Please check with your local Disti/NXP FAE for an NDA conversation on this point.
Q4 — APDU throughput limit (SW 66A6)
Yes, the 1,000,000-APDU / 34-day counter and the 500,000-APDU periodic self-test are FIPS 140-3 compliance requirements specific to SE052F. A hypothetical non-FIPS SE052 variant would not be subject to these constraints.
Regarding reset: a T=1oI2C chip reset (RST_N toggle or power cycle) is the documented recovery path. The APDU counter is a session-resident in-RAM value — it is cleared by the cold reset with no NVM write. The Plug & Trust MW includes an apdu_throughput_limit demo that demonstrates exactly this recovery using phNxpEse_reset . For your mesh/transport node use case, at ~340 APDUs/minute sustained this limit should not be a concern in practice, but please ensure your host driver handles SW_66A6 gracefully with an automatic reset.
Q5 — Applet feature roadmap (BIP32, Schnorr, RFC 6979, Ed25519ph)
None of the features you listed — BIP32 hardened child-key derivation on-chip, Schnorr/BIP340, deterministic ECDSA nonces (RFC 6979), low-S normalisation, or Ed25519ph — appear in AN12543 Rev 4.5 or any current SE05x documentation, and there are no public announcements for these in the 7.2.x line. I'd encourage you to submit a formal product enhancement request via your local Disti/NXP FAE so these can be tracked by our product team.
A note on the T=1 chaining concern for Ed25519: the applet does support multi-block T=1 chaining for APDU data beyond IFSC (0xFE), so message length is handled at the transport layer and is not a functional restriction on EdDSA operations.
Q6 — UserID behaviour on applet 7.2.22
(a) Counter readability: The GetAttributes response returns the configured TAG_MAX_ATTEMPTS value (the maximum), not the remaining count. The internal decrement counter is not exposed as a directly readable attribute in the current applet version.
(b) Deleting an exhausted UserID over SCP03: The 6986 error on deletion of a locked UserID that you observed on 7.2.0 is a known limitation. AN13904 does not explicitly document a change to this behaviour for 7.2.22 in the context of Platform SCP03 deletion. I recommend verifying this directly on the SE052F evaluation hardware (or an SE051 sample running 7.2.22). As a workaround, a Factory Reset via RESERVED_ID_FACTORY_RESET over Platform SCP03 is the confirmed path if a locked UserID blocks object management — though this clears all user objects, so object layout planning matters here.
Q7 — ECDH NVM wear (SE050E with applet 7.2.0)
Confirmed. AN12543 explicitly states that ECDHGenerateSharedSecret on ID_ECC_MONT_DH_25519 causes NVM writes per call only when the public key is passed as a byte array (TAG_2). When the public key is passed via a transient ECPublicKey object (TAG_3), no NVM write occurs. This behaviour applies to SE050E with applet 7.2.0, as the SE050E2 uses the same 7.x applet generation (the SE051 die and applet family, as your GetInfo ATR confirms).
WriteECKey on a transient object writes to SRAM only — there is no NVM wear from updating the transient object's content between calls. The recommended pattern for your node is: allocate one persistent transient ECPublicKey at startup, call WriteECKey (SRAM only) before each ECDH operation, then call ECDHGenerateSharedSecret with TAG_3 referencing that transient object. This fully avoids per-call NVM wear.
Q8 — SE050E2 product longevity
The SE050E2 was launched in 2022. NXP's Product Longevity Program commits to a minimum of 10 or 15 years' availability from launch date for enrolled products. For the definitive enrollment status and longevity horizon for SE050E2, please check the NXP Product Longevity page (sign-in required for the full table) or ask your NXP FAE to confirm.
Overall recommendation for your two use cases
Given that your designs rely on Ed25519 (EdDSASign) and X25519 (ECDHGenerateSharedSecret on MONT_DH_25519), SE052F does not currently satisfy your cryptographic requirements. The SE050E2 / SE051 family remains the appropriate choice until a SE052 variant with those algorithms is available. We recommend confirming SE050E2 longevity status with your NXP FAE and registering a product requirement for a non-FIPS SE052 equivalent.
Hope this helps clarify the decision. Please let me know if you have follow-up questions.
Have a great day, Kan
------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. -------------------------------------------------------------------------------
記事全体を表示
