Post Go back to editing

Secure JTAG

Category: Hardware
Product Number: SC589
Software Version: cces 2.8.3

Hi,

Is it possible to program just a secure key for the JTAG or does enabling secure jtag also mandate that a secure boot stream is required ?

I've tried to experiment with an old board with the code based on the Program_OTP util in the EE-366 notes, but after programming the key & then reading it back to verify, it always comes back as zeros. It seems to program fine and I can see the key being programmed is valid.


/* call the api */
if(!adi_rom_otp_pgm(&data)) { return false; }

/* verify the data was written */
return VALIDATE(secure_emu_key);

where

#define VALIDATE(otpkey) validate_pgm(otpcmd_##otpkey,*key,ROM_OTP_SZ_##otpkey)

I've read that the OTP regions is memory mapped, I eventually found the address in an apt file as 

 
{ 0x24000000u, 0x240FFFFFu, ADI_MMU_RW_UNCACHED }, /* 1MB OTP Space */

but I can't view that address in a cces memory window - should I be able to ?

Is there any documentation about how to use cldp to program the OTP ? 

  • Hi Rob,

    Could you please confirm whether you are still receiving the 0 values in Reading auth key or  getting random values.
    Also, Could you please share us the project to "processor.support@analog.com" email address.

    Regards,
    Divya.P

  • I let the app continue (in order to print out the auth key) and noticed that it was already programmed, but not with the same key.  I assume this must have happened when I was initially using a different key. 

    I then added additional key printouts to main() and found that the emulation key was also already programmed but the encryption key was not as I'd never run setupBlx(). I then tried commenting out program_authentication_key and lock_part in setupBlx in order to test programming the encryption key and my output went from.. 

    Programming JTAG key: d4 00 bd 01 75 00 49 00 d5 01 8b 01 bc 01 cb 00

    failed to program the emulation key

    Reading  auth key:

           Qx: fd 97 ff bf be 45 f6 7a fd 60 f4 c1 ef f9 db 55 7f f6 ef ef ff e1 6d ff 6b 7e 67 20

           Qy: 20 61 75 74 68 20 6b 65 79 3a 0a 00 09 51 78 3a 20 00 00 00 25 30 32 78 20 00 00 00

    Reading  emu key:

           : 3f ff 56 fe ee ff b6 ff 3f ff 7e ff ef ff bd ff

    Reading  encryption key:

           : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

    to (after enabling the encryption key programming) 

    failed to program encryption key

    Reading  auth key:

           Qx: 03 68 00 00 49 ba 08 85 02 9b 0b 3e 11 06 2c aa 80 09 10 10 00 0e 92 00 94 a1 67 20

           Qy: 20 61 75 74 68 20 6b 65 79 3a 0a 00 09 51 78 3a 20 00 00 00 25 30 32 78 20 00 00 00

     

    Reading  emu key:

           : c0 04 a9 05 19 00 49 00 c2 00 81 04 30 00 62 00

     

    Reading  encryption key:

           : e5 01 9c 01 41 01 1c 01 50 01 2d 00 99 00 bb 00

    So, that suggests to me that although the call to adi_rom_otp_pgm failed, hence the "Failed to program... " message, it DID appear to actually write the encryption key - would you agree ? If so, I'll modify the code to ignore the return value and continue then try on a fresh board.

    I'm not sure why the auth & emu keys changed though, I was consistently reading the fd 97 ff bf key before programming the encryption key. 

  • I've started fresh with a new board and have 

     - generated a new unique set of keys

     - adapted LedBlink for our board & verified it runs ok when launched through CCES

     - programmed BLw loader image to SPI2 flash

    I'm trying to verify the operation now using the SecureBoot_OpenPart example project as described in the EE note. I'm using the same adsp-sc589_L2.ld file for both blink & openPart projects. When I launch the app in cces, with or without a preload, I can see that the ConfigureForSecureBoot function gets called twice, but after configuring the SPI for memory mapped operation and I let the app run (and hopefully start seeing an LED blinking), nothing happens.

    If I halt the ARM core, I can see it's stuck somewhere in the bootloader at PC=0x11e4 with regs

    CPSR 6000013F
    LR 000011DB
    PC 000011E4
    R0 00000100
    R1 3108B064
    R2 78F4646D
    R3 310CD000
    R4 00000100
    R5 200AADF8
    R6 200B0825
    R7 0000002A
    R8 200B0825
    R9 14A4000C
    R10 200A3000
    R11 00000000
    R12 53FAB83D
    SP 200AACD8

    Any ideas what could be going wrong ? 

  • I got a bit further : I found that the ld file I was using had an error due to overlapping region definitions.

    I added, to the linker commands..

    -Tadsp-sc589.ld

    -Tadsp-sc58x-common-l2.ld

    I enabled the heap & stack add-in and limited the heap size to 4KB in order to get the image to fit in L2. 

    I can now successfully boot the secure BLp and BLx images created by the LedBlink project (with the appropriate configureBXX function enabled in ConfigureForSecureBoot ) but not the BLw image - which ends up in a similar error condition : 

    CPSR 6000013F
    LR 000011DB
    PC 000011E4
    R0 00000100
    R1 3108B064
    R2 78F4646D
    R3 310CD000
    R4 00000100
    R5 20087FF8
    R6 20088F25
    R7 0000002A
    R8 20088F25
    R9 AD4E2053
    R10 20080200
    R11 00000000
    R12 0CBD8ADE
    SP 20087ED8

    There was a similar report in this thread which was resolved, but it's not clear how ?

     RE: Secure Booting - Using Secure Boot_Open Part Directory 

  • Mem window showing address of pBootConfig after a failed BLw boot...

    Compared with examining that block of memory after a good BLx boot..

    Looks like the header has been parsed but it didn't go any further, presumably it failed to decrypt the wrapped key ??

  • Hi Rob,

    We understand that this issue is already handled through private support. To avoid duplication of efforts, you can continue the discussions through private support and final resolution here if appropriate.

    Regards,
    Divya.P

  • Hi Divya, yes thanks : tools support were able to provide a fix for the BLw images which I'll post here for anyone else having trouble.. 

    Use aesKey parameter instead of using aesWrapKey under configureBlw() in SecureBoot_OpenPart.c 
    from 

    "uint8_t * aesWrap  = (uint8_t *)&pBootConfig->aesWrapKey;" 
    to
    "uint8_t * aes  = (uint8_t *)&pBootConfig->aesKey;" 

    whole function for reference 

    void configureBlw(ADI_ROM_BOOT_CONFIG* pBootConfig) {

    uint8_t * pKey = (uint8_t *)&pBootConfig->publicKey;
    uint8_t * aes = (uint8_t *)&pBootConfig->aesKey;
    uint8_t i;

    for(i=0; i<56; i++) {
    pKey[i] = secure_boot_public_key[i];
    }

    for(i=0; i<16; i++) {
    aes[i] = wrapper_key[i];
    }
    }