Dear Realtek Team,
We are preparing mass production (~10,000 units) of a video doorbell based on the RTL8735B (AmebaPro2). Our setup:
- SDK release 9.6_r
- NOR flash, non-TrustZone (NTZ) build
- Secure boot manual UM0702
We plan to enable Secure Boot Level 3 (otp_secure_boot_enable(), sign_enc images) with:
- One shared ROTKEY, image signing keys (PARTAB/BOOT/FW) and HUK for all devices
- A unique SEC key per device
For production and OTA, we build the firmware once. Then, for each device, we run elf2bin secure sign+enc+hash with that device’s key file. Before finalizing, we’d appreciate your confirmation on the following points.
-
Per-device SEC key workflow
Is it a supported approach to keep key_private.json / key_public.json identical across devices and change only SEC.key1 per device, then run elf2bin secure sign+enc+hash+dbg=boot and …=fw for each device? Should certificate_signed.bin and partition_signed.bin be identical for all devices in this setup? -
AES-CTR IV and key derivation
encrypt_fw.json and encrypt_bl.json use a fixed IV (123456789ABCDEF0).
- (a) Can we use a different IV for each firmware release? Does the boot ROM/bootloader read the IV from the image manifest (ENCIV / encryption records)?
- (b) Is the AES-256-CTR key the SEC key itself, or is it derived from the SEC key together with ENCKN/ENCKS?
-
Image hash input
For sign_enc images, is the manifest HASH (step 5, “Image Payload Hash Check”) calculated over the encrypted payload as stored in flash, or over the plaintext? -
MP firmware boot flow
The manual’s MP phase describes a combined image: Key Certificate ‖ Partition Table ‖ Bootloader (plain) ‖ Application (encrypted) ‖ MP Firmware ‖ User Data (encrypted bootloader).
- (a) How does the boot flow select and boot the MP firmware first? (mp_trap, MP partition record, or another method?) In our partition table the mp record is only 4 KB and currently invalid.
- (b) Is it acceptable to place the MP firmware in the FW2 partition and stage the encrypted bootloader in the boot_s partition, with the MP firmware copying it to boot_p before enabling secure boot?
- (c) Is there a recommended order between “copy encrypted bootloader”, “write keys / SSZ lock”, and “enable secure boot”?
-
UART download after enabling secure boot
After otp_secure_boot_enable(), can we still flash the device with uartfwburn.exe (-U flash loader / UART download mode), for example for factory rework? -
JTAG/SWD protection
How do we permanently disable JTAG/SWD (secure and non-secure), or enable password mode, in OTP? We found hal_otp_s_jtag_key_write() / hal_otp_ns_jtag_key_write() and the AON S_JTAG_SWD_MODE / NS_JTAG_SWD_MODE fields, but no API or OTP address to set the mode permanently. -
Anti-rollback
What is the format of the firmware anti-rollback version in OTP (OTP_FW_VANTI_ADDR 0x570, enable bits around 0x5B4)? How does it relate to the manifest VERSION field, and is there an API to update it safely? -
Firmware slot fallback
If a newly updated FW1/FW2 slot fails signature, hash or decryption checks at boot, does the device automatically boot the other (previous) valid slot? Is this behaviour the same on chips where hal_sys_get_rom_ver() > 2, where slot selection is handled by the ROM? -
User crypto key after SSZ lock
Is the user crypto key in OTP (efuse_crypto_key_get() slot 0) still readable by application firmware after hal_otp_ssz_lock()? We’d like to use it (or HUK through the crypto engine) to protect per-device secrets stored in flash. -
Key generation
Is the random number generator used by elf2bin keygen suitable for production keys? Or do you recommend generating the keys externally (e.g. in an HSM) and writing key_private.json / key_public.json ourselves? -
Factory key provisioning
Do you or your distributors offer a factory key-provisioning service or tool for RTL8735B?
Thank you for your support.