Secure JTAG instead of Secure Boot

[moogambika]

Can we consider the code protection feature (Secure JTAG) as an alternative for Secure Boot?

What additional attack points are eliminated with Secure Boot?
Need info on memory tampering other than through JTAG for Secure Boot.

[Julián_AragónM]

Hi @moogambika,

You can refer to both AN5401 and AN12130, for basic descriptions between secure boot vs secured JTAG:

From AN12130, secured part (JTAG):

"Secured part: The JTAG/SWD interface will be disabled when the part is secured. This means that a debug controller cannot read or write to SOC memory-mapped addresses when the part is in this state. The part is secure when the FTFC_FSEC byte is in a secure state in the flash configuration field. Once this happens, you can’t run any CMD_DBG_CHAL and CMD_DBG_AUTH commands via JTAG/SWD.

So, customer application code must have the flow shown in Mass Erase and CSEc considerations embedded in their application and trigger the routine from a different interface such as CAN or UART/Serial interfaces, for example."

From AN5401, secure boot:

"The CSEc has a mechanism which allows users to authenticate boot code in flash. The MCU can be configured so that on every boot, a section of code is authenticated, and the generated MAC is compared with a value previously stored in a secure memory slot"

In short, secured JTAG interface simply protects the debug port, while secure boot protects the code being ran. 

For example, many S32K1 applications use a bootloader through serial/UART/CAN, etc. —without secure boot, a new firmware could be installed through these side-channels, even if JTAG is locked. Please refer to the application notes and reference manual for further information.

Best regards,
Julián

[moogambika]

hi,

As per the Flash Security Register (FSEC),
If the FTFC module is unsecured using backdoor key access, the SEC bits are forced to 10b.
Mass Erase Enable Bits  -- When the SEC field is set to unsecure, the MEEN setting does not matter.

Question:

• Even if MEEN = 0b10 (mass erase disabled), Once the device is unsecured via backdoor key, mass erase becomes possible?
  Note: Production Settings : MEEN = 0b10
• What should be the FSLACC?
  Pls mention on the Different settings of FSLACC when MEEN is enabled or disabled, FSEC Sec is Secured or Unsecured?

[Julián_AragónM]

Hi @moogambika,

1. Yes. If you unsecure the chip by backdoor key without resetting the chip, it may be mass erased.

2. The Factory Failure Analysis Access configuration (FSLACC) is only relevant when the part is secure (SEC: 00b or 01b or 11b) and it does not affect MEEN nor KEYEN. This depends on your policy, whether to allow or deny factory access if a return is requested.

Best regards,
Julián

[moogambika]

hi @Julián_AragónM ,

Thanks for the response.

We currently have the Bootloader in DFlash and Csec disabled.
Q's:
1.Do we need to enable Csec if Backdoor Key need to be used ?
2.Where will it be stored? 
3.How it is related to Security setting and Mass erase setting?

Regards
Moogambika.

[Julián_AragónM]

Hi @moogambika,

1. No. You can refer to this community example: Example S32K144 Verify Backdoor Access Key S32DS1.3 - NXP Community.

2. Inside the FTFC module:

3. I don't understand this question. When S32K144 MCU is secured (SEC bits != 0b10), it can be unsecure using either Mass Erase or Verify Backdoor Access Key command, if they are enabled.

FTFC module contains the flash protection and system security settings. Please refer to chapter 36 from the S32K1 reference manual, and related application notes: AN5401, AN12130, AN11983.

Best regards,
Julián

[moogambika]

thanks for the response.

got a question on the below point.
For example, many S32K1 applications use a bootloader through serial/UART/CAN, etc. —without secure boot, a new firmware could be installed through these side-channels, even if JTAG is locked

-- if the input received via UART is verified before reaching Bootloader, Can Secure boot be excluded ?

[Julián_AragónM]

Hi @moogambika,

Yes, verification through signature or MACs on incoming firmware is okay, as long as the verification code is never bypassed, of course. However, it does not completely replace secure boot.

Keep in mind that implementing secure boot is up to you and your application's requirements.

Best regards
Julián

[moogambika]

For S32K118