How to revert Platform SCP03 keys back to default using se05x_TP_PlatformSCP03keys.c?

[Uc_S]

Hello NXP Community,

I am working with the SE051 secure element and would like to ask how to properly revert the Platform SCP03 keys back to their default values using the Plug and Trust Middleware.

What I have done so far:

1. I modified demos/se05x/se05x_RotatePlatformSCP03Keys/se05x_TP_PlatformSCP03keys.c by commenting out the key reversion section (between doc:start:revert-scp03-keys and doc:end:revert-scp03-keys).
2. I built and executed the application on my setup.
3. The execution was successful, showing the message: "Congratulations !!! Key Rotation Successful!!!!"
4. To verify the key change, I updated /tmp/SE05X/plain_scp.txt with the new key value (0x4041... for ENC, MAC, and DEK) and successfully connected via ssscli connect.
5. Subsequent operations (ssscli generate rsa, ssscli set aes, and ssscli se05x readidlist) were all completed successfully, confirming that keys were written and IDs were retrieved without issues.
6. Now, I would like to restore the Platform SCP03 keys back to the default keys (defined in sss/ex/inc/ex_sss_tp_scp03_keys.h).

Could anyone guide me on how to modify se05x_TP_PlatformSCP03keys.c or what the correct process is to perform this key reversion?

Environment:

• Board: MCIMX8M-WEVK with OM-SE051ARD
• Plug and Trust MW Version: v04.07.01
• OP-TEE OS Version: 3.19.0
• Linux Kernel: 6.1.151
• OEF ID: A8FA

Any advice or code pointers would be greatly appreciated.

[Kan_Li]

Hi @Uc_S ,

Rotating the Platform SCP03 keys back to the default values is only possible when the current keys are known, as a successfully authenticated SCP03 session is required before any key update (PutKey) command can be issued to the SE051.

If the current keys have been lost or forgotten, it is not possible to authenticate to the SE051 and perform the key rotation. There is no backdoor or override mechanism — this is by design to preserve the security model of the device.

Additionally, a factory reset does not help, as Platform SCP03 keys are explicitly unaffected by the factory reset procedure.

In this situation, the only option is to replace the SE051 with a new device that still carries the default NXP-provisioned keys.

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

[Uc_S]

@Kan_Li 

Thank you for the clarification.

In my case, the current keys are known (0x4041... for ENC, MAC, and DEK), and I can successfully establish an SCP03 session using these keys via ssscli.

Since I have the current keys available to authenticate, could you please provide details on how to modify se05x_TP_PlatformSCP03keys.c to perform the key rotation back to the default values?

Specifically, I would like to know:

• Which variables or macros should be updated with the current keys (0x4041...) for authentication during session setup.
• Which variables or structures should hold the target default key values (ex_sss_tp_scp03_keys.h) for the PutKey operation.

Any code snippets or specific line references in se05x_TP_PlatformSCP03keys.c (or related boot/auth headers) would be greatly appreciated.

[Kan_Li · Accepted solution]

Hi @Uc_S ,

If you just need to rotate the keys back to the default, the nano-package example is the recommended simpler path — only the three scp03_* arrays (current keys for auth) and the three NEW_scp03_* arrays (default keys as target) need to be updated, and the revert call within ex_se05x_rotate_scp03_keys() needs to be commented out. Please refer to the following for details.

Change 1 — Set the current keys (used to open the SCP03 session)

Lines 38–43 are the auth keys passed to ex_set_scp03_keys(). Replace the placeholder 0xABCD... values with your current keys (0x4041...

uint8_t scp03_enc_key[AES_KEY_LEN_nBYTE] = {
    0x40, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47,
    0x48, 0x49, 0x4A, 0x4B, 0x4C, 0x4D, 0x4E, 0x4F };

uint8_t scp03_mac_key[AES_KEY_LEN_nBYTE] = {
    0x40, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47,
    0x48, 0x49, 0x4A, 0x4B, 0x4C, 0x4D, 0x4E, 0x4F };

uint8_t scp03_dek_key[AES_KEY_LEN_nBYTE] = {
    0x40, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47,
    0x48, 0x49, 0x4A, 0x4B, 0x4C, 0x4D, 0x4E, 0x4F };

c

Change 2 — Set the NEW target keys (the default SE051C A8FA keys)

Lines 45–50 are the keys that will be written into the SE051 via PutKey. Replace the 0x4041... placeholder with the SE051C OEF A8FA default values:

uint8_t NEW_scp03_enc_key[AES_KEY_LEN_nBYTE] = {
    0xbf, 0xc2, 0xdb, 0xe1, 0x82, 0x8e, 0x03, 0x5d,
    0x3e, 0x7f, 0xa3, 0x6b, 0x90, 0x2a, 0x05, 0xc6 };

uint8_t NEW_scp03_mac_key[AES_KEY_LEN_nBYTE] = {
    0xbe, 0xf8, 0x5b, 0xd7, 0xba, 0x04, 0x97, 0xd6,
    0x28, 0x78, 0x1c, 0xe4, 0x7b, 0x18, 0x8c, 0x96 };

uint8_t NEW_scp03_dek_key[AES_KEY_LEN_nBYTE] = {
    0xd8, 0x73, 0xf3, 0x16, 0xbe, 0x29, 0x7f, 0x2f,
    0xc9, 0xc0, 0xe4, 0x5f, 0x54, 0x71, 0x06, 0x99 };

c

Change 3 — Comment out the revert block

In ex_se05x_rotate_scp03_keys(), comment out lines 85–90 so the code does a single rotation only (current → default) and does not try to rotate back again:

/* -- Comment out the revert block below -- */
// SMLOG_I("Reverting SCP03 keys(version - %02x) to OLD KEYS \n", KEY_VERSION);
// ret = ex_se05x_change_keys(&se05x_session, &scp03_enc_key[0], &scp03_mac_key[0], &scp03_dek_key[0]);
// if (ret != 0) {
//     SMLOG_E("Error in ex_se05x_change_keys \n");
//     return 1;
// }

c

 

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

[Uc_S]

@Kan_Li 

Thank you for providing the detailed guidance.

Following your instructions, I updated the keys, commented out the revert block, and successfully built and executed the nano-package example.

However, during execution, the SCP03 key update operation failed with a SW status code 6A80 during the PUT KEY APDU command. Here is the summary of the execution log:

Plug and Trust nano package - version: 1.6.1
...
Establish Secure Channel to SE05x !
Sending GP Initialize Update Command !!!
...
CardCryptogram verified successfully...Calculate HostCryptogram
Sending GP External Authenticate Command !!!
APDU Tx> :84 82 33 00 10 ...
APDU Rx< :69 82
Authentication Successful!!!

Created scp03 Session
Changing SCP03 keys(version - 0b) to NEW KEYS
APDU Tx> :84 d8 0b 81 58 ...
APDU Rx< :6a 80
Error in DoAPDUTxRx
Error in ex_se05x_change_keys
SE05x Rotate SCP03 keys Example Failed !

Regarding potential root causes, I suspect that either the OpenSSL version (OpenSSL 3.x is used on both the build PC and the target evaluation board) is affecting key derivation/formatting during PutKey, or the DEK value in particular might have been mismatched/rewritten previously.

At this moment, I do not have sufficient bandwidth to investigate or address these possibilities further. I will look into them separately if time permits later.

Thank you again for your assistance.

[Kan_Li]

Hi @Uc_S ，

Thank you for the detailed execution log — it provides exactly what is needed to pinpoint the issue. Your two suspects are both valid and well-reasoned. Here is a breakdown of what is most likely happening.

---

What the 6A80 Error Tells Us

SW 6A80 (SW_WRONG_DATA) means the SE051 rejected the data field of the PUT KEY APDU as cryptographically invalid. Since your log shows that authentication completed successfully (CardCryptogram verified + External Authenticate passed), the ENC and MAC keys are confirmed correct. The failure is isolated specifically to the PUT KEY step, which points directly to an issue with the DEK key or the AES encryption used to wrap the new key material.

---

Suspect 1: DEK Key Mismatch — Most Likely Primary Cause

Inside the PUT KEY command, each new key is encrypted under the current DEK before being sent to the SE. If the DEK value in the host code does not exactly match the DEK stored on the device, the SE decrypts garbage and returns 6A80.

A near-identical case from a prior SE051C1 customer concluded:

"If the minimal example works with PlatformSCP, then ENC and MAC keys are correct. As key rotation still fails, this means the DEK key needs to be wrong... the DEK key may have been set wrongly in the past."

This is the most probable root cause given your history — a prior incomplete or incorrect rotation may have left the SE051's DEK in a state that no longer matches 0x4041....

Confirmation step: Test the same code on a brand-new, factory-fresh SE051 sample. If it succeeds immediately, this confirms that the current device's DEK state is corrupted/unknown, and the chip should be replaced — there is no recovery path without the correct DEK.

---

Suspect 2: OpenSSL 3.x Compatibility — Real Risk, Secondary Cause

The nano-package's SCP03 crypto path uses the legacy low-level OpenSSL API:

AES_set_encrypt_key((uint8_t *)key, keylen * 8, &AESKey);
AES_ecb_encrypt(srcData, destData, &AESKey, AES_ENCRYPT);

The nano-package was designed and tested with OpenSSL 1.1.1 only. In OpenSSL 3.x, these APIs are deprecated and require the legacy provider to be explicitly loaded at runtime. If it is not loaded, these calls can silently produce incorrect output — which would corrupt the DEK-encrypted payload and also trigger 6A80.

Recommended fix: Switch the nano-package to use mbedTLS as the host crypto backend (-DEX_SE05X_USE_MBEDTLS=1), which does not rely on deprecated OpenSSL APIs and is fully supported for this use case. Alternatively, rebuild against OpenSSL 1.1.1 to test the OpenSSL version hypothesis in isolation.

---

Recommended Action Sequence

1. Test on a fresh SE051 first — this is the fastest way to confirm whether the current device's DEK is the root cause.
2. Switch to mbedTLS for the host crypto backend to eliminate any OpenSSL 3.x risk going forward.
3. If the fresh device also fails with mbedTLS, please share the build environment details (OS, compiler, mbedTLS version) for further investigation.

Please note: if the current device's DEK is confirmed to be in an unknown state, there is no way to recover it — a replacement chip with factory-default keys will be required.

Please let us know the result of the fresh sample test and we will be happy to assist 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.
-------------------------------------------------------------------------------