SE050Sim: add SE050E applet personality, fix GetFreeMemory reply width - #14
Merged
Conversation
Bench-probed an SE050E on the hardware rig. The part runs IoT applet 7.2.0 and matches the SE051 on the entire probe matrix (GetRandom cap 1018, curve-specific ReadType codes, duplicate CreateECCurve refused 0x6985, ECDSA digest-length enforcement, identical cipher/MAC vectors, stateful curves) except for three differences, now modelled as a third applet personality selected with SE050_SIM_APPLET=e / se050e: - Version blob 07 02 00 3f 9f ff ff: the appletConfig word clears exactly RSA_PLAIN (0x0020) and RSA_CRT (0x0040). - No RSA at all: keygen refused 0x6985 for every size and format, key import refused 0x6a80. The wolfCrypt suite against real SE050E silicon passes through AES-GCM then fails RSA with WC_HW_E and aborts; there is no software fallback. - GetFreeMemory values 32767/796/784, PERSISTENT clamped at 0x7fff. Also fixes the 7.2.0 personality's GetFreeMemory reply width: all bench applets reply with a 2-byte value. The earlier 4-byte encoding came from misreading the v04.07.01 middleware, whose U32 parse path is gated on SE05X_CHECK_52F_VERSION (applet minor 0x10-0x1f, the SE052F family) and never runs for these applets; tlvGet_U16 rejects TLV values longer than 2 bytes, so the U32 reply would make Se05x_API_GetFreeMemory fail host-side.
There was a problem hiding this comment.
Pull request overview
This PR extends the SE050Sim personality model to cover SE050E (applet 7.2.0 with RSA feature bits disabled) and corrects the GetFreeMemory response encoding to match bench-verified behavior across all supported parts.
Changes:
- Add an SE050E applet personality (
SE050_SIM_APPLETtokens ending ine) and model RSA refusal semantics for keygen/import. - Fix GetFreeMemory replies to always return 2-byte values (U16) for all personalities, and update tests to pin per-personality values.
- Update per-version behavior tables/tests (GetVersion blob, GetRandom cap, duplicate curve create behavior).
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| SE050Sim/se050-sim/src/handlers/rsa.rs | Add personality-gated RSA key write behavior and tests for SE050E refusal vs SE051 support. |
| SE050Sim/se050-sim/src/handlers/management.rs | Update GetFreeMemory documentation/tests to assert U16 width and SE050E-specific values; extend GetRandom tests for SE050E. |
| SE050Sim/se050-sim/src/handlers/curve.rs | Treat SE050E like SE051 for duplicate curve creation refusal behavior. |
| SE050Sim/se050-sim/src/dispatch.rs | Pass applet version into RSA write handler (and should treat SE050E as “v7” for read semantics). |
| SE050Sim/se050-sim/src/applet.rs | Add SE050E personality, version bytes, GetRandom cap mapping, RSA support trait, and updated GetFreeMemory width/value modeling + tests. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
The dispatch v7 flag was computed as version == V7_2_0, so the SE050E personality would have received the 3.1.1 generic ReadType codes. Bench runs show the SE050E reports the same curve-specific codes as the SE051 (P-256 pair 0x29, P-521 pair 0x31); add is_v7() covering both 7.2 parts and use it in dispatch. Split token parsing out of from_env into from_token with the ending-in-e rule taking precedence over the leading-3 rule, matching the documented behavior for tokens like 3e, and rewrite the parsing test against from_token so it no longer mutates the process environment.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to #13: an SE050E was probed on the same hardware rig with the same raw
Se05x_API_*probe set, plus a new RSA-surface probe and a full wolfCrypt-suite run on the silicon. Two outcomes: a third applet personality, and a hardware-verified fix to the existing 7.2.0 personality.SE050E personality (new)
SE050_SIM_APPLET=e/se050e(any value ending ine) selects an SE050E: IoT applet 7.2.0 with the RSA feature bits disabled. On the bench it matched the SE051 on the entire existing probe matrix (GetRandom cap 1018, curve-specific ReadType codes, duplicate CreateECCurve refused 0x6985 with the curve intact, ECDSA digest-length enforcement, identical NIST/RFC cipher and MAC vectors, stateful curves with parameterized P-521/P-192 fully working; even the ATR historical bytes read "eSE051"). The modelled differences:07 02 00 3f ff ff ff07 02 00 3f 9f ff ffThe appletConfig delta (0x3f9f vs 0x3fff) clears exactly
kSE05x_AppletConfig_RSA_PLAIN(0x0020) andkSE05x_AppletConfig_RSA_CRT(0x0040): the SE050E has no RSA at all. Running the full wolfCrypt suite (--with-se050Pass-B build) against the real part passes every test up to and including AES-GCM, then fails the RSA test withWC_HW_E(-248) and aborts - there is no software fallback. wolfSSL builds targeting SE050E parts must disable RSA offload; the simulator now reproduces that failure mode faithfully (keygen 0x6985, import 0x6A80, ops on the never-created objects 0x6985).GetFreeMemory reply width fix (7.2.0 personality)
The 7.2.0 personality previously replied with a 4-byte value, from a misreading of the v04.07.01 middleware. The middleware's U32 parse path is gated on
SE05X_CHECK_52F_VERSION(applet minor 0x10-0x1F, the SE052F family) and never runs for these applets; itstlvGet_U16rejects TLV values longer than 2 bytes and succeeded against all three bench parts, proving they all reply U16. The 4-byte reply would makeSe05x_API_GetFreeMemoryfail host-side against the simulator. All personalities now reply with 2-byte values.Test plan
cargo test -- --test-threads=1: 76 lib + 14 driver integration tests pass.SE050_SIM_APPLETtoken parsing.