Do S32k118 backdoor and csec function conflict?

[ZEROOO]

Hello,

    Does the Cryptographic Service Engine-Compressed (CSEc) function conflict with the backdoor key function on the S32K118? In particular, after CSEc is enabled, EEPROM cannot be erased, making mass erasures impossible. In this case, after unlocking the backdoor key through UDS (Unified Diagnostic Services), the unsecure command connecting to JTAG and using winIDEA cannot clear the backdoor key, resulting in the program failing to burn, as if forming an interlock between CSEc and backdoor key functions.

[lukaszadrapa]

Hi @ZEROOO 

Could you explain what you mean exactly by: "the unsecure command connecting to JTAG and using winIDEA cannot clear the backdoor key, resulting in the program failing to burn"

If CSEc is enabled, mass erase is blocked all the time. Backdoor key access will unsecure the device only temporarily until next reset. If your debugger resets the device, it's secured again. Maybe that's the reason of described behavior.

Regards,
Lukas

[ZEROOO]

Hi @lukaszadrapa 

    If the backdoor key function and Csec function are used at the same time, after the JTAG port is decrypted by UDS, winIDEA is connected to MCU by attach. At this time, Mass erase cannot be directly used by Csec, and the backdoor key is only temporarily unlocked without using unsecure command. Unable to directly burn the program, the current when the backdoor key and Csec function are enabled at the same time, the unsecure command will fail to execute, and the firmware program that unlocks the Csec partition cannot be burned. Therefore, I would like to ask whether the two functions are interlocked.

[lukaszadrapa]

No, there are no connections between CSEc and security/backdoor access. I even did some tests in the past:

https://community.nxp.com/t5/S32K/CAN-unresponsive-after-securing-S32K14x/m-p/1586660/highlight/true...

Isn't the debugger triggering a reset before the programming?

Regards,

Lukas

[ZEROOO]

reset does trigger before programming, which causes the unsafe state to return to the safe state, making programming fail. Do I need to undo the Csec partition before executing unsecure or mass erase to reset the chip state?

[lukaszadrapa · Accepted solution]

I can see following options:
1. Force your debugger to not use a reset during the programming of new application. Not sure if it is possible in winIDEA, please ask iSystem directly.
2. When you enter the debug mode using backdoor access, reprogram the FSEC manually by writing to flash registers (erase first sector, program the FSEC back...)
3. Next time, add a functionality to your application which will either reprogram FSEC or which will run CMD_DBG_CHAL and CMD_DBG_AUTH commands to disable CSEc. This can be done based on some command received from UDS, for example.