Platform SCP03 key rotation on SE050C1 — PUT KEY rejected (6A80 / 6982) We cannot rotate the Platform SCP03 keys on SE050C1 from the NXP factory (OEF) keys to our own device-derived keys. PUT KEY is rejected in every variation we have tried, on a factory-fresh part, with both Plug&Trust 3.0.6 and 4.7.1. A Platform SCP03 session with the factory keys works correctly — we can open it and run applet commands (GetVersion, GetRandom, ReadObject, WriteBinary) successfully. Only PUT KEY fails. We would like to know the correct APDU sequence to rotate Platform SCP03 keys on this part, and ideally a reference implementation. Setup: Secure element SE050C1 (SSS_PFSCP_ENABLE_SE050C1 = 1) ATR 00 A0 00 00 03 96 04 03 E8 00 FE 02 0B 03 E8 08 01 00 00 00 00 64 00 00 0A 4A 43 4F 50 34 20 41 54 50 4F ("JCOP4 ATPO") Host MCU ESP32-S3, ESP-IDF v5.3.4 Transport T=1 over I2C (T1oI2C) Middleware Plug&Trust — tested 3.0.6 and 4.7.1, identical behaviour both mini Auth SE05X_Auth=PlatfSCP03, SSS_HAVE_SE05X_AUTH_PLATFSCP03 Host crypto mbedTLS The part is factory-fresh: it has never been successfully rotated , and it authenticates with the SE050C1 OEF keys from ex_sss_tp_scp03_keys.h. what are we trying to do: Rotate the Platform SCP03 key set (ENC / MAC / DEK) from the factory OEF keys to device-unique keys derived on the ESP32 (PBKDF2-HMAC-SHA256 over the ESP32's eFuse-resident HMAC key), so that only that specific host MCU can open a Platform SCP03 session with its SE050. what is working: Opening a Platform SCP03 session with the factory keys succeeds, and commands inside it work:scp :DEBUG:Authentication Successful!!! APDU :DEBUG:GetVersion [] -> 90 00 APDU :DEBUG:GetRandom [] -> 90 00 APDU :DEBUG:WriteBinary [] -> 90 00 So the channel, keys, and secure messaging are all functioning. waht fails: case A : PUT KEY is rejected with 6A80(Wrong data). Command header and plaintext data field (before SCP03 wrapping): hdr : 80 D8 0B 81 Lc=70 data: 0B <- key version number 88 11 10 <16 bytes ENC enc. under DEK> 03 <3-byte KCV> 88 11 10 <16 bytes MAC enc. under DEK> 03 <3-byte KCV> 88 11 10 <16 bytes DEK enc. under DEK> 03 <3-byte KCV> Key values are encrypted with the current (factory) DEK using AES-CBC with a zero IV; KCV is the first 3 bytes of the AES encryption of a 16-byte block of 0x01 under the new key. Case B: ISD Selected If we first select the ISD: GP_Select(A0 00 00 01 51 00 00 00) -> 90 00 response: 6F 10 84 08 A0000001 51000000 A5 04 9F 65 01 FF then the same PUT KEY is rejected with 6982(security not satisfied) instead of 6A80. This suggests the ISD does recognise the command but requires a secure channel — and that in Case A the command was going to the SE050 applet, which has no D8 instruction. However, GP_Select() in the middleware sends a plaintext APDU, which tears down the existing SCP03 channel. Our attempts to re-establish SCP03 after selecting the ISD (calling nxScp03_AuthenticateChannel() again, having reset fp_Transform / authType / pdynScp03Ctx on the session) fail: scp :WARN :nxEnsure:'status == kStatus_SSS_Success' failed. At Line:148 Function:nxScp03_AuthenticateChannel case C: Sending via DoAPDUTxRx_s_Case4_ext (with Le) returns 6700 (wrong length), consistent with the ISD's FCI advertising 9F 65 01 FF (max data field 255). waht already ruled out: Each of these was tested and made no difference to the result: Variable Values tried P1 0x00 (create new), 0x0B (replace current), 0x11 (target version) Leading KVN byte in data field present / absent APDU case Case4 (short) / Case4_ext (extended) Key block structure 88 11 10 03 Key wrapping AES-CBC zero IV under current DEK (equivalent to ECB for one block) KCV method AES of 16×0x01 under the new key, first 3 bytes Middleware version Plug&Trust 3.0.6 and 4.7.1 DEK source verified the KEK is the same key set that opens the session With the applet selected all variants give 6A80; with the ISD selected all short-form variants give 6982. Question: What is the correct APDU sequence to rotate the Platform SCP03 keys on SE050C1? Specifically: is PUT KEY expected to be sent to the Issuer Security Domain, or to the SE050 applet? If it must go to the ISD, how should the Platform SCP03 channel be established against the ISD using the Plug&Trust middleware? Is EX_SSS_BOOT_SKIP_SELECT_APPLET the intended mechanism, and if so what is the correct call sequence (SELECT ISD → INITIALIZE UPDATE → EXTERNAL AUTHENTICATE → PUT KEY)? Is the key data field format above correct for this part, in particular the key type coding, the length encoding, the DEK wrapping mode, and the KCV algorithm? Our Plug&Trust package defines INS_GP_PUT_KEY (0xD8) in nxScp03_Const.h and global_platf.h, but contains no implementation and no example that uses it. Could you provide the Platform SCP03 key rotation example / demo (the equivalent of what se05x_Delete_and_test_provision is for provisioning), or point us to it in the full SDK? Could you provide AN12436 (referenced in ex_sss_auth.h as the source of the OEF Platform SCP03 keys), or the application note that documents key rotation for this part? Background — why this went unnoticed For transparency, this is a problem we created for ourselves and only recently detected. Our provisioning code called PUT KEY and then discarded the return status: sw = gp_put_key_using_nxp_middleware(se, DERIVED_SCP03_KEYVER, ...); /* status never checked */ mark_rotated(se, DERIVED_SCP03_KEYVER); /* writes "rotated" marker */ ESP_LOGI(TAG, "SCP03 keys rotated successfully"); /* printed unconditionally */ Because the marker write (WriteBinary) does succeed, every device ends up with a "rotated" flag set while its Platform SCP03 keys are still the factory ones, and provisioning reported success. We have since added the status check, which is how we discovered PUT KEY has never actually succeeded on any unit. We are not asking for help with that part — it is fixed. We mention it only to explain why we are raising this now rather than at bring-up, and to make clear that the part is genuinely unrotated rather than in some partially-rotated state. SE050 Re: Platform SCP03 key rotation on SE050C1 — PUT KEY rejected (6A80 / 6982) Hi @Rutwik0409 ,
Based on the information provided, the SE050C1 appears to be working correctly at the applet level: SELECT , GetVersion , GetRandom , ReadObject , and WriteBinary all succeed over Platform SCP03. Therefore, this does not look like a basic transport, T=1, SCP03 key, or secure-messaging failure.
Since you are using ESP32-S3 with a custom T=1 over I²C transport, this is likely a porting/integration issue around the GlobalPlatform Security Domain SCP03 session, not evidence that SE050C1 does not support Platform SCP03 key rotation.
For Platform SCP03 key rotation , the PUT KEY command is a GlobalPlatform Security Domain operation , not an SE050 IoT applet command. The documented sequence is:
Select the Security Domain / SSD.
Open the Platform SCP03 secure channel using INITIALIZE UPDATE / EXTERNAL AUTHENTICATE .
Send PUT KEY to update the Platform SCP03 key set.
This also matches the behavior observed:
When the SE050 applet is selected, PUT KEY returns 6A80 , which is consistent with sending a GlobalPlatform command to the wrong target.
When the ISD is selected but no secure channel is established to that domain, PUT KEY returns 6982 , which is consistent with “security status not satisfied.”
So the main point to check is not only whether Platform SCP03 works to the SE050 applet , but whether the middleware is opening Platform SCP03 against the correct Security Domain before issuing PUT KEY .
NXP provides a reference demo for this exact operation:
se05x_RotatePlatformSCP03Keys
The demo is specifically described as demonstrating authentication with the default Platform SCP keys and rotation of those keys to user-defined keys.
Our recommendation is to avoid manually constructing the PUT KEY APDU at first, and instead compare against the NXP reference implementation.
Here I would first suggest that you verify the implementation using NXP's official reference paths—such as the `se05x_RotatePlatformSCP03Keys` demo found in the Zephyr + nano package so that your ESP32 MCU is well supported without any porting work. This demo serves as NXP's reference implementation for platform SCP03 key rotation. The current issue suggests that the `PUT KEY` command is being sent to the wrong target, or that the corresponding platform SCP03 secure channel was not correctly established after selecting the ISD/SSD. The fact that SCP03 communication with the SE050 applet is functioning correctly does not guarantee that the `PUT KEY` process at the GlobalPlatform Security Domain level has been correctly set up.
Please refer to https://github.com/NXPPlugNTrust/nano-package/blob/master/zephyr/readme.rst for more details.
Hope that helps,
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: Platform SCP03 key rotation on SE050C1 — PUT KEY rejected (6A80 / 6982) hi @Kan_Li, is there a retry or lockout counter on failed Platform SCP03 EXTERNAL AUTHENTICATE? Is a "try key set A, fall back to key set B" pattern supported for Platform SCP03, or does NXP recommend a different approach for a mixed fleet — for example recording the key-set state host-side and never attempting the wrong one? regards, rutwik Re: Platform SCP03 key rotation on SE050C1 — PUT KEY rejected (6A80 / 6982) Hi @Rutwik0409 ,
Please have my comments as below:
Is there a retry or lockout counter on failed Platform SCP03 EXTERNAL AUTHENTICATE?
No. There is no brute-force lockout counter at the Platform SCP03 (GlobalPlatform ISD) level on SE050C1. A failed EXTERNAL AUTHENTICATE simply returns a non-9000 status word (e.g. 6300 or 6982) and the channel is not opened. The SE is fully available for a fresh INITIALIZE UPDATE immediately after. No persistent lockout state is written.
Note this is different from SE05x applet-level Authentication Objects (AES keys, ECKeys, UserID), which do have a configurable authentication attempts counter in their object policy. Platform SCP03 via the ISD/GlobalPlatform layer does not use that mechanism.
Is a "try key set A, fall back to key set B" pattern supported?
It is not natively supported, and we would not recommend it as the normal operating flow. The reasons:
The INITIALIZE_UPDATE command carries the key version number (KVN) in P2. If you send INITIALIZE UPDATE with KVN=0x01 but the device holds KVN=0x11, the SE returns 6A88 (referenced key not found). You can then retry with the correct KVN — there is no lockout — but each failed INITIALIZE UPDATE is an incomplete authentication attempt and can cause sequence counter desynchronisation over time.
It also leaks information about which key version is present on the device.
Recommended approach for a mixed fleet
The cleanest pattern is to track key-set state host-side and never attempt the wrong KVN:
After a successful PUT KEY rotation, write a marker (e.g. a flag in your host backend, keyed by the SE050 Unique ID / CPLC serial number) recording which KVN is now active.
On every subsequent boot, look up that marker before issuing INITIALIZE UPDATE so you always open the session with the correct KVN.
The se05x_rotate_scp03_keys demo in the nano-package (https://github.com/NXPPlugNTrust/nano-package/tree/master/examples/se05x_rotate_scp03_keys) is a good starting point for the PUT KEY mechanics, but note that by design it reverts back to the old keys at the end — the second ex_se05x_change_keys call is a development safety rollback. The documentation states: "For development testing, we rollback to original keys. It is left to customer to comment out this line." For production use, comment out that second call. Once you do, the SE holds only the new keys, so your host firmware must be updated accordingly to always open the session with the new KVN from that point forward.
One important practical note: always verify the return status word of PUT KEY before writing the rotation marker. If PUT KEY fails silently (e.g. returns 6A80 as you are seeing), writing the "rotated" marker anyway will cause every subsequent connection attempt to use the wrong KVN.
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. -------------------------------------------------------------------------------
記事全体を表示
