LPC5528 - how to reach code security equal to CRP2 in previous LPC series ?

[alexey]

UM and ANs describe cases only with Secure boot enabled 'S' chips, but i deal with unsecure LPC5528.

I need only to permanently switch off SWD interface and disable all ISP command except full flash erase.

It is called "CRP2" in old LPC24xx/LPC17xx/LPC18xx/LPC40xx MCUs.

I don't need TZ, signed or enciphered flash image, updates, authentificated debug and so on.

Only to protect flash content from being read from outside.

I tried wrote to CMPA and CFPA such combinations but didn't got success:

 CMPA.CC_SOCU_DFLT =

  FLASH_CMPA_CC_SOCU_DFLT_NIDEN(0) |

  FLASH_CMPA_CC_SOCU_DFLT_DBGEN(0) |

  FLASH_CMPA_CC_SOCU_DFLT_SPNIDEN(0) |

  FLASH_CMPA_CC_SOCU_DFLT_SPIDEN(0) |

  FLASH_CMPA_CC_SOCU_DFLT_TAPEN(1) |

  FLASH_CMPA_CC_SOCU_DFLT_CPU1_DBGEN(0) |

  FLASH_CMPA_CC_SOCU_DFLT_ISP_CMD_EN(1) |

  FLASH_CMPA_CC_SOCU_DFLT_FA_CMD_EN(1) |

  FLASH_CMPA_CC_SOCU_DFLT_ME_CMD_EN(1) |

  FLASH_CMPA_CC_SOCU_DFLT_CPU1_NIDEN(0);

 CMPA.CC_SOCU_DFLT |= FLASH_CMPA_CC_SOCU_DFLT_INVERSE_VALUE( ~CMPA.CC_SOCU_DFLT );

 CMPA.CC_SOCU_PIN =

  FLASH_CMPA_CC_SOCU_PIN_NIDEN(1) |

  FLASH_CMPA_CC_SOCU_PIN_DBGEN(1) |

  FLASH_CMPA_CC_SOCU_PIN_SPNIDEN(1) |

  FLASH_CMPA_CC_SOCU_PIN_SPIDEN(1) |

  FLASH_CMPA_CC_SOCU_PIN_TAPEN(1) |

  FLASH_CMPA_CC_SOCU_PIN_CPU1_DBGEN(1) |

  FLASH_CMPA_CC_SOCU_PIN_ISP_CMD_EN(1) |

  FLASH_CMPA_CC_SOCU_PIN_FA_CMD_EN(1) |

  FLASH_CMPA_CC_SOCU_PIN_ME_CMD_EN(1) |

  FLASH_CMPA_CC_SOCU_PIN_CPU1_NIDEN(1);

  CMPA.CC_SOCU_PIN |= FLASH_CMPA_CC_SOCU_DFLT_INVERSE_VALUE( ~CMPA.CC_SOCU_PIN );

  CMPA.SECURE_BOOT_CFG = FLASH_CMPA_SECURE_BOOT_CFG_TZM_IMAGE_TYPE(1);

 CFPA_scratch.VERSION = 1;

 CFPA_scratch.NS_FW_VERSION = 1;

  CFPA_scratch.DCFG_CC_SOCU_DFLT =

  FLASH_CFPA_DCFG_CC_SOCU_DFLT_NIDEN(0) |

  FLASH_CFPA_DCFG_CC_SOCU_DFLT_DBGEN(0) |

  FLASH_CFPA_DCFG_CC_SOCU_DFLT_SPNIDEN(0) |

  FLASH_CFPA_DCFG_CC_SOCU_DFLT_SPIDEN(0) |

  FLASH_CFPA_DCFG_CC_SOCU_DFLT_TAPEN(1) |

  FLASH_CFPA_DCFG_CC_SOCU_DFLT_CPU1_DBGEN(0) |

  FLASH_CFPA_DCFG_CC_SOCU_DFLT_ISP_CMD_EN(1) |

  FLASH_CFPA_DCFG_CC_SOCU_DFLT_FA_CMD_EN(1) |

  FLASH_CFPA_DCFG_CC_SOCU_DFLT_ME_CMD_EN(1) |

  FLASH_CFPA_DCFG_CC_SOCU_DFLT_CPU1_NIDEN(0);

 CFPA_scratch.DCFG_CC_SOCU_DFLT |= FLASH_CFPA_DCFG_CC_SOCU_DFLT_INVERSE_VALUE( ~ CFPA_scratch.DCFG_CC_SOCU_DFLT );

  CFPA_scratch.DCFG_CC_SOCU_PIN =

  FLASH_CFPA_DCFG_CC_SOCU_PIN_NIDEN(1) |

  FLASH_CFPA_DCFG_CC_SOCU_PIN_DBGEN(1) |

  FLASH_CFPA_DCFG_CC_SOCU_PIN_SPNIDEN(1) |

  FLASH_CFPA_DCFG_CC_SOCU_PIN_SPIDEN(1) |

  FLASH_CFPA_DCFG_CC_SOCU_PIN_TAPEN(1) |

  FLASH_CFPA_DCFG_CC_SOCU_PIN_CPU1_DBGEN(1) |

  FLASH_CFPA_DCFG_CC_SOCU_PIN_ISP_CMD_EN(1) |

  FLASH_CFPA_DCFG_CC_SOCU_PIN_FA_CMD_EN(1) |

  FLASH_CFPA_DCFG_CC_SOCU_PIN_ME_CMD_EN(1) |

  FLASH_CFPA_DCFG_CC_SOCU_PIN_CPU1_NIDEN(1);

 CFPA_scratch.DCFG_CC_SOCU_PIN |= FLASH_CFPA_DCFG_CC_SOCU_DFLT_INVERSE_VALUE( ~ CFPA_scratch.DCFG_CC_SOCU_PIN );

[airios_arno]

I'm currently working on a project with the same processor (LPC5528JBD64) and it seems we want to achieve the same thing as the topic starter.

We would like to protect the chip from reading out its contents/attaching a debugger, but we would still like to be able to program it in a fast way (i.e. SWD) after unlocking/doing a full erase.
As I understand it to only way to do this, is to have our own bootloader/application that also offers a "fast" communication interface to send the new firmware and have the bootloader/application write it to flash. That way all other interfaces (SWD / ISP) can be disabled via the CMPA area.

Can someone (preferably from NXP) confirm that this is indeed the only way to secure the LPC5528?

The main use case for which we want this faster update is for reprogramming large batches/products still in stock.
Our products do have a firmware upgrade feature, but it was designed/created for updating the product in the field.
For that use case, it works very well, but when it comes to large batches, it will be less efficient to do it this way.
Especially since the production setup already has SWD programmers.

[tomas_voda]

Hello Aleksey,

Actually I do not have LPC5528 device for testing. I expect it was possible in your case to disable debug ports etc. but you had still working ISP mode. Below is complete overview of CMPA/CFPA and how to disable debug ports/ISP mode.

Here is description of CMPA/CFPA difference. CMPA has higher priority. CFPA should only reduce functionality.

DCFG_CC_SOCU -> DCFG_CC_SOCU_N

Fixed state enabled -> DAP to open (CFPA is reducing CMPA configuration to use debug authentication)

Fixed state enabled -> Fixed state disabled (CFPA is reducing CMPA configuration to disabled debug)

DAP to open -> Fixed state disabled (CFPA is reducing CMPA configuration to disabled debug)

Fixed state enabled -> PIN=1, DFLT=1

Fixed state disabled -> PIN=1, DFLT=0

DAP to open -> PIN=0, DFLT=x

In your case we setup all values to fixed state pin=1:

cc_socu_pin = 0b1111111111;
cc_socu_pin |= (~cc_socu_pin << 16);

And disable dflt=0 except Mass Erase and Fault Analysis through debug mailbox:   
cc_socu_dflt = 0b0110000000;
cc_socu_dflt |= (~cc_socu_dflt << 16);

Keep in mind if you want to disable ISP mode enter through ISP pin you need to setup

CMPA->BOOT_CFG-> Default ISP to DISABLED (0b111)

BOOT_CFG=0b1110000

cc_socu disable ISP enable through debugger and BOOT_CFG disable booting into ISP when ISP_PIN/invalid image is used.

Regards,

Tomas

[alexey]

How to process to 'mass erase through debug mail box' ?

Does it done through SWD interface ? 

How can i try it using jlink or cmsis-dap tools ? 

[tomas_voda]

Hello Aleksey,

Please see UM chapter Debug subsystem.

There is described debug mailbox. Please use SWD interface for communicating with DM-AP.

There is also described pseudo code for debugger connection.

Regards,
Tomas

[alexey]

Got it in UM 51.5.5 but it doesn't solve my problem.

What we have at this moment:

1. CC_SOCU_DFLT/CC_SOCU_PIN in CMPA turns off SWD to M33 cores (we can rewrite CMPA and SWD turns back).

cc_socu_pin = 0b1111111111;
cc_socu_pin |= (~cc_socu_pin << 16);

 cc_socu_dflt = 0b0111000000;
cc_socu_dflt |= (~cc_socu_dflt << 16);

2. Such script (enter ISP) for jlink...

connect
WriteDP 2 0x02000000
WriteAP 0 0x21
ReadAP 0
WriteAP 1 0x00010005
WriteAP 1 0xffffffff
ReadAP 0
exit

...really enters ISP if boot pins enabled also.

But if ISP_mode bits in BOOT_CFG set it doesn't work (ISP_CMD_EN=1 in CC_SOCU_DFLT).

boot_cfg = 0x00000070

3. Script for 'bulk erase' ...

connect
WriteDP 2 0x02000000
WriteAP 0 0x21
ReadAP 0
WriteAP 1 0x02
ReadAP 0
exit

...terminates without errors but don't do enything. Flash remains unchanged.

So i can disable SWD and ISP to protect flash content. But i don't got way to recover MCU to 'factory state' as were possible in LPC17xx - CRP2 to CRP0 security.

p.s. At this time i tried all above on LPC55S69.

[tomas_voda]

Hello Aleksey,

great to see that configuration is working. Regarding last point bulk erase, it looks like issue in documentation. Could you please test AP command 0x3 like bulk erase? It looks it is changed 0x2 and 0x3 command description.

Bulk erase only erase flash content, it is not related to device configuration. (PFR content like CMPA, CFPA etc.)

By design is not expected to have possibility to revert security protection. It is one way functionality.

Right now you are working in "development" mode. You are able to move from development mode into "released/secure" state by writing hash of the CMPA page. You will leave development mode and there is no possibility to revert it back. But you can keep some commands like bulk erase for erasing the flash or FA which will zeroize all settings but device is locked after that and not able to use it anymore.

Regards,

Tomas

[alexey]

If 'bulk erase' keeps CMPA restrictions unchanged it is useless for me.

The goal i try to reach is to get ability to recover chip to 'factory state' after unsuccessful update or bad firmware.

I realised that the only way to succeed is to load my own intermediate loader which can clear flash and CMPA area by asserting ISP pin. And lock SWD and ISP interfaces by CMPA after loading firmware.