2399763_en-US

はい

SE051C2: all Secure Object operations return 0x6985 while GetRandom works over the same authenticate

## The problem in one line

On an **SE051C2**, every command that touches the applet's object store returns
**0x6985 (CONDITIONS NOT SATISFIED)** — while `GetRandom` succeeds on the *same*
session, including over the armed Platform SCP03 channel.

## Our questions

**Q1. Is this part in a "mandate platform SCP" / RESTRICTED / transport state?**
Both of our samples are as-delivered, and one is factory-fresh. If SE051C2 ships with
the object store locked until the Platform SCP03 keys are rotated off the NXP
defaults, that would explain every observation below exactly. If so, what is the
documented procedure to leave that state?

**Q2. Do object operations require customer-key (rotated) Platform SCP03, rather than
the default platform keys?** Our channel authenticates with the defaults and
demonstrably carries traffic — but every object command over it is refused.

**Q3. If Q1/Q2 are yes: how do we read UNIQUE_ID first?**
This is a chicken-and-egg that blocks us completely. Our platform-key derivation takes
the chip UID as its input, but `ReadObject(UNIQUE_ID)` is itself one of the refused
commands. What is the intended order of operations on a fresh part?

**Q4. Is there a GET DATA / GET STATUS we can issue that reports the applet's
lifecycle / VC state?** Stateless commands *do* work for us, so if such a query exists
we can confirm the part's state ourselves instead of guessing.

**Q5. What makes THIS part refuse ordinary object creation, when it evidently works
for others?** In the DeleteAll/0x6985 thread (m-p/1648349), step 1 was
`Se05x_API_WriteUserID(... FACTORY_RESET ...)` returning **0x9000** — a
WriteSecureObject succeeding on the default session with only platform SCP03. That is
precisely the class of command that fails for us. So object writes are *not* inherently
session-gated. Is the difference the variant/configuration (SE051C2 vs SE050), or the
platform keys still being NXP defaults?

**Q6. Is m-p/1716555 the same root cause?** There, another user reports
`Se05x_API_WriteUserID` returning `SM_ERR_CONDITIONS_OF_USE_NOT_SATISFIED` — our exact
symptom — and that question appears to have gone unanswered.

**Q7. Does `kSE05x_ECCurve_NIST_P256` require an explicit `Se05x_API_CreateECCurve` on
SE051C2, or is it built in?** (Minor — but we tried it, and even the CreateECCurve is
refused.)

## What we measured

| Check | Result | Meaning |
|---|---|---|
| `Se05x_API_SELECT` applet | **0x9000** | IoT applet selected |
| `Se05x_API_GetRandom` (plain) | real entropy | session + transport work |
| Platform SCP03 authenticate | **succeeds** | default key set matched |
| **GetRandom OVER the SCP03 channel** | **succeeds, real entropy** | encrypt + C-MAC + decrypt verified |
| Second wrapped command back-to-back | **succeeds** | command counter stays in sync |
| `WriteECKey` NIST P-256 (generate) | **0x6985** | |
| `WriteECKey` secp256k1 (import) | **0x6985** | `CreateCurve_secp256k1` IS called first |
| `WriteECKey` Ed25519 (import) | **0x6985** | built-in curve, no CreateCurve needed |
| `ReadObject(UNIQUE_ID)` | **0x6985** | no policy argument involved |
| `WriteBinary_Ver` (with file policy) | **0x6985** | file objects fail too |
| `CreateECCurve(NIST_P256)` | **0x6985** | even creating a curve is refused |
| `CheckObjectExists` | **0x6985** | cannot even test for an object |

**`GetRandom` is the only command that works.** Every object-store operation returns
0x6985 — on both samples, plain or SCP03-wrapped.

## Already ruled out by experiment

1. **Not the part.** A second, factory-fresh SE051C2 behaves identically.
2. **Not the transport or session.** SELECT returns 0x9000; GetRandom returns real
entropy on the same session.
3. **Not a broken or missing Platform SCP03 channel.** Authenticate succeeds against
the default key set and — decisively — a `GetRandom` issued **over the armed
channel** returns real entropy, as does a second back-to-back (command counter in
sync). Encrypt + C-MAC + response decrypt all verified. The failing object commands
are carried by a channel we have proven functional.
4. **Not a missing key policy.** We passed a real `Se05xPolicy_t`
(`ALLOW_SIGN|VERIFY|KA|READ|WRITE|GEN`, authID 0) to every `WriteECKey`. No change.
(It could not explain the UNIQUE_ID read anyway — `ReadObject` takes no policy.)
5. **Not a missing curve.** `CreateCurve_secp256k1` is called before the secp256k1
import, Ed25519 is built in, and `Se05x_API_CreateECCurve(NIST_P256)` **also**
returns 0x6985.
6. **Not command ordering.** Same 0x6985 whether issued on the plain session or on the
authenticated SCP03 channel.
7. **Not the middleware auth build configuration.** Rebuilt with
`SSS_HAVE_SE05X_AUTH_PLATFSCP03=1`, `SSS_HAVE_SE05X_AUTH_NONE=0` and
`SSSFTR_SE05X_AuthSession=1` (they had been NONE / 0). No change.

## Environment

* Part: **SE051C2** — two samples, one factory-fresh, identical behaviour
* Host: STM32L562, bare-metal, TrustZone secure world, I2C1 @ 100 kHz, T=1
* Middleware: vendored NXP Plug & Trust `Se05x_API_*` over a custom
`smCom_TransceiveRaw` transport (our own T=1 framing — SELECT and GetRandom prove
it works). Full middleware, **not** nano-package.
* Platform SCP03: NXP default keys; authenticate succeeds and carries traffic

SE050

Re: SE051C2: all Secure Object operations return 0x6985 while GetRandom works over the same authenti

Hi Kan, thanks for the quick reply.

Yes — tested without platform SCP, and that's actually our normal case. Our object operations run before se051_scp03_open() is called, so they're already on a plain session, and they fail there. Arming platform SCP03 afterwards makes no difference — same 0x6985 either way.

Here is the APDU log. Plain session, no SCP03 (CLA=0x80, no 0x04 secure-messaging bit; the response is a bare status word, not wrapped):

TX (11): 80 04 00 27 06 41 04 20 00 F0 30

RX ( 2): 69 85

That is CheckObjectExists (INS 04 MGMT, P2 27, TAG_1 objectID 0x2000F030) — a read-only existence test — refused with CONDITIONS NOT SATISFIED.

The same 0x6985 comes back for every object-store command we try, any object ID: CheckObjectExists, WriteBinary_Ver (with file policy), WriteECKey (generate and import; P-256, secp256k1 with CreateCurve_secp256k1 first, and Ed25519), CreateECCurve(NIST_P256), and ReadObject(UNIQUE_ID).

On that same plain session, these work fine:

SELECT of the IoT applet → 0x9000
GetRandom → real entropy

So the transport and applet selection are good; only object-store commands are refused.

Question: what would make a factory-fresh SE051C2 refuse even CheckObjectExists on a plain session? We see identical behaviour on two samples, one brand new and never written to.

Is there a GET DATA (or similar) query that reports the applet's lifecycle / configuration state? Stateless commands work for us, so we can run it right away and report back.

Setup: SE051C2, STM32L562 bare-metal host, I2C 100 kHz, our own T=1 framing (SELECT and GetRandom prove it), full Plug & Trust middleware Se05x_API_*, not nano-package.

Re: SE051C2: all Secure Object operations return 0x6985 while GetRandom works over the same authenti

Hi @winetime ，

Did you try the same process without platformSCP enabled? SE051C doesn't require a mandate platform SCP by default. If you may share the APDU command log for this issue, we may check it further.

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.
-------------------------------------------------------------------------------

Re: SE051C2: all Secure Object operations return 0x6985 while GetRandom works over the same authenti

Hi @Kan_Li — closing this out. **It was our side, and the diagnosis was wrong from the

start.** Posting the resolution in case it helps someone else.

The part is fine. Once I instrumented a whole-boot APDU trace instead of reading

individual results, a clean power-up gave 83 APDUs with 80 of them 0x9000 — object

creation, secp256k1 key generation, `ReadObject` and ECDSA signing all working. The only

non-0x9000 responses were benign and already handled by our own code:

80 01 0B 04 CreateECCurve(secp256k1) -> 6985 curve already exists

80 01 61 00 WriteECKey -> 6A80 object exists, wrong type

80 04 00 27 CheckObjectExists -> 9000

80 04 00 28 DeleteSecureObject -> 9000

80 01 61 00 WriteECKey -> 9000 succeeds after the delete

**What I was actually looking at.** The SE was already in a wedged state when each of my

test boots started, left there by an earlier session. Once wedged, *every* APDU returns

0x6985 — `GetRandom`, `GetVersion`, `GetFreeMemory` included — and the state survives an

MCU reset, a T=1 interface reset, and a re-`SELECT` that itself returns 0x9000. Only

removing power clears it. So every measurement I reported was of the wedge, not of a

blocked feature, and my "GetRandom is the only command that works" and "GetVersion is

refused" claims were both artifacts of that. Apologies for the noise.

For the record, on a healthy boot this part reports:

* `GetVersion` → `07 02 00 3F FF FF FF` — applet **7.2.0**, AppletConfig `0x3FFF`

* `GetFreeMemory(PERSISTENT)` → `0x3E0C` = **15,884 bytes** free

* Platform SCP03 authenticates on the default key set for **OEF 0005A8FA (SE051C)**

**One thing that may still be worth your comment**, since it is the part I do not

understand and it has shipping implications for us:

While wedged, GP security-domain commands keep working — `80 50 00 00` INITIALIZE

UPDATE and `84 82 33 00` EXTERNAL AUTHENTICATE both return 0x9000 — while the IoT

applet refuses everything. Is there a documented applet error state with that shape,

and is there any way to detect or clear it **without cutting power**? A deployed device

cannot power-cycle its secure element independently, so if a host can drive the applet

into this state we need to know how to get back out.

Thanks for the quick response earlier.