Secure DFU on RT600 Board: RT685 EVK Zephyr toolchain: zephyr-sdk-1.0.1, zsdk nxp-v4.4.1.1 Hi Team! I am working on a Zephyr-based RT600 application, which should include three images in total ( MCUBoot, ARM core image, and DSP core image). Since the RT600 is a flash-less MCU, those images have to live in the external flash, and I am looking for a proper way to protect them against read-back and other potential risks that could leak the image. On top of that, I would like to have the DFU feature to update both the ARM core and the DSP core images via SMP protocol (RT600 running as SMP server, or through MCUBoot serial recovery, or both) in an encrypted manner. I failed to find an example shipped with nxp-zsdk, could you please help me find a practical path to follow? Best regards, Yue Re: Secure DFU on RT600 Hi @YueZ ,
For the RT685 EVK, I recommend treating this as two related design tasks : securing what is stored in external flash, and securely updating the Arm and DSP firmware. An encrypted update alone does not establish that the active image is protected against external-flash read-back.
A practical starting point is to package the DSP firmware with the Arm application and update them as one signed image . That lets you bring up a single MCUboot primary/secondary-slot update path before taking on independent DSP image management. Zephyr’s SMP image-management flow uploads an update to a secondary slot for MCUboot to process at boot.(zephyr/doc/services/device_mgmt/smp_groups/smp_group_1.rst at main · zephyrproject-rtos/zephyr · GitHub) On RT600, the boot images reside outside internal flash, either for loading into SRAM or for execution from external memory, so the flash layout and boot chain need to be designed together. - https://www.nxp.com/docs/en/application-note/AN12985.pdf
I would proceed in this order:
Establish a trusted boot chain : authenticate the bootloader at startup, then have it verify signed application updates. Include production key provisioning and debug-access policy in the design.
Demonstrate a signed Arm-plus-DSP update through an application-side SMP server, with a defined primary and secondary flash slot. Confirm that the newly built DSP firmware is actually included in the image being uploaded.
Address confidentiality of the installed image separately . NXP’s RT600 secure-provisioning workflow describes writing an encrypted application and OTFAD key blobs,(mcuxpresso.nxp.com/secure/latest/_sources/06_processor_specific_workflow.md) and its RT600 FOTA note describes a signed-and-encrypted OTA approach. Those are useful RT600 references, but their procedures are not a ready-made Zephyr SMP integration. - https://www.nxp.com/docs/en/application-note/AN13478.pdf
If independent Arm and DSP updates are required, design separate image storage and verification, plus a way to prevent incompatible Arm/DSP versions from being activated together. I would treat that as a second integration milestone, not as a capability already demonstrated by the combined-image example.
Application-side SMP and bootloader-side serial recovery can both be considered, but they are distinct update paths; you do not need to implement both to validate the first DFU milestone.
Could you confirm whether the DSP must be updated independently, or whether updating Arm and DSP together is acceptable? That decision determines whether the simpler combined-image path meets your requirements or whether a multi-image boot and rollback design is necessary.
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: Secure DFU on RT600 Hi Kan, Thank you very much for the information, it is really clear and helpful! To answer your question, I am fine with packing the two images into one; they don't need to be separate. Additionally, I am eager to know your suggestions on a few more questions, and please correct me if I am wrong since I am new to the NXP secure-provisioning workflow: The two milestones are, if I understood it correctly: 1) verify FOTA image signing and boot chain; 2) verify OTFAD on the off-chip flash. It looks like the west build process only signs the image without encryption; the output hex(bin) image file remains in plaintext, which is supposed to be encrypted in the second step for OTFAD. On an OTA update, a signed image is received and then written into flash as OTFAD-encrypted. Does that mean the image in transit is exposed to attack? XIP or loading in RAM, which would you recommend for less workload in Zephyr if combined with signing and encryption? Is there an example available in Zephyr demonstrating the OTFAD feature on RT600 (and whether OTFAD is supported by MCUBoot serial recovery)? I found modules/hal/nxp/mcux/mcux-sdk-ng/drivers/otfad/fsl_otfad.h, but nothing has referred to it yet. A starting point would be very much appreciated! Best regards, Yue
View full article
