AnsweredAssumed Answered

BF-706 Secure Boot

Question asked by bls_dk on Aug 9, 2018

Hello Analog Devices support

I have designed a custom board build around a BF-706 processor and successfully developed and tested an application for it. Now I’m working on implementing secure boot, using EE-366 as a guide and have encountered a problem.

According to EE-366 the steps listed below must be completed in order to make the system secure.

  1. Generate the keys.
  2. Develop the application and generate the boot stream file.
  3. Convert the loader stream file to a secure boot stream file.
  4. Program the boot stream into the storage device.
  5. Program the keys into OTP memory.
  6. Lock the device to enable security.

 My actions during each step and the commands executed are listed below

  1. Keys generated by running the makefile in the keygen example project.
  2. Boot stream (ldr file) generated by making the application project.
  3. Loader stream converted to a secure boot stream, (signed and encrypted) with the below execution of the signtool:

    signtool

    sign

    -type BLx (Sign & Encrypt the boot stream file)

    -prikey auth_key.bin (Sign Key – Generated by keygen project)

    -enckey encrypt_key.bin (Encryption key – Generated by keygen project)

    -infile Proportional.ldr (Bootstream file to be Signed & Encrypted)

    -outfile ProportionalSecBoot.bin (Signed & Encrypted bootstream file

  4. Programmed the secure bootstream into the Flash memory on the board, with the below execution of the CLDP

    cldp

    -proc ADSP-BF706 (Processor on the board)

    -emu 1000 (ICE-100 emulator)

    -driver bf706_w25q32bv_dpia.dxe (Driver for the Flash on the board)

    -cmd prog (Program Flash)

    -erase affected (Erase before programming)

    -format bin (Bootstream format: Binary)

    -file ProportionalSecBoot.bin  (Secured bootstream to be programmed into Flash)

  5. Programmed the keys into the OTP memory by making and running the Program_OTP example project.

    The main() function used in the OTP programming  is listed below

    int main(void)

    {

                 adi_initComponents();

    /*****************************************************************************

                  *  The following three functions will program the applicable OTP fields

                  *  for the associated image type. Only one can be used on a single part

                  *

                  *  All the keys used are generated from the keygen project. The keygen

                  *  project will only generate keys once, and used to program the loader

                  *  stream and program the OTP fields

     *****************************************************************************/

                 //setupBlp();

                 //setupBlw();

                 setupBlx();

     

                 return 0;

    }

     As I read the Program_OTP source code the setupBlx(); function call results in the Authentication Public Key, the Encryption Key and the Secure Debug key being programmed into the OTP memory.

    Is this correct?

    When trying to debug the application, with the signed and encrypted boot stream programmed in the Flash and the Blx keys programmed into the OTP I get the error shown in the attached photo.

    If I try to run a debug session on another board where none of the “secure boot” steps has been performed, the application is loaded without problems and I can debug it without problems.

    Since I have not yet locked the part with the error yet, why does the debug session no longer load correctly?

     

    According to EE-366, in order to allow debug access on a locked part, the Secure Debug key  stored in the OTP memory is compared to the Secure Debug Key read from the ADSP-BF706-resets.xml  file.

    The example key from the xml file is shown below.

    <register name=”userkey0” reset-value=”0x00001111” core=”Common” />

    <register name=”userkey1” reset-value=”0x22223333” core=”Common” />

    <register name=”userkey2” reset-value=”0x44445555” core=”Common” />

    <register name=”userkey3” reset-value=”0x66667777” core=”Common” />  

     The h file containing the Secure Debug key generated by the keygen project is shown below.

    const static uint8_t jtag_key[] = {

                 0xd6,

                 0x1,

                 0x8a,

                 0x1,

                 0x26,

                 0x0,

                 0xa4,

                 0x1,

                 0xe4,

                 0x0,

                 0x9e,

                 0x0,

                 0x43,

                 0x0,

                 0xab,

                 0x1 };

    const static uint8_t jtag_key_bytes_sz = 16;

    How should the format for the Secure Debug key used in the h file be translated to the format used for the Secure Debug key used in the xlm file i.e. which parts of the key in the h file corresponds to the four parts of the key in the xlm file?

Attachments

Outcomes