• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 51 subscribers
  • Views 287 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LAUNCHXL-CC26X2R1: bimVerifyImage_ecc() on CC26X2R during secure OAD

kazola
Guru 18645 points

Part Number: LAUNCHXL-CC26X2R1

Tool/software:

Hi,

I am using Simplelink Connect app to perform OAD to my CC26X2R-based custom board. Everything works fine. The NOR memory driver works fine.

SDK version is v7.40.

I receive the image from the phone perfectly.

Next, I run the BIM from the CCS debugger (DEBUG configuration with macro SECURITY ENABLED), the following happens:

  • It checks the EXTernal memory. It finds the one I just sent just OK, nice.
  • The Bim_authenticateImage() for external image returns SUCCESS.
  • Then the external image is copied to internal memory, returns SUCCESS.
  • CRC is OK.

Next, when calling Bim_authenticateImage() for the INTERNAL image, it fails. My question is twofold:

  1. When generating the firmware image, my post-build OAD tool uses new keys I generated. I know I need to copy these keys to the BIM source code structure. What I cannot find is if I can copy the normal order or what your python code calls REVERSED format. I guess this is NOT the problem because as I said above, the Bim_authenticateImage() for external image returns SUCCESS but I would like a confirmation.
  2. Maybe, because of some unknown reason, it is expected when debugging BIM from CCS?
  3. Maybe I can even skip such BIM_authenticateImage() for INTERNAL image? It seems redundant if everything else seems to work.

Please let me know any ideas / thoughts.

Have a nice day.

  • 0
    Guru 18645 points

    Some support info comes next Slight smile


    This is the output file (key_info.txt) generated by running your script key_generate.py. Since these are tests, I don't mind you having the keys.
    Last 3 lines (ones saying 'in C format') are generated by me, they help out copy-pasting to the C code. These are the ones I copy-paste to BIM. These are the ones I am asking the REVERSED format question about. For now, I am NOT using reversed format. But again, I don't think this is the error. Please check the Signer info format too, thanks.

    Private key: b'f02903c841667d602b98bbf77cdcd0d30f225e04331a0be5473d8449e5933b9a'
    Public Key b'535d4ac698e85fcd57a6abcd0e754421b733826f1be86a2ea17a5b56349e57ffe9af966c9360f4a8c8dcecf2f10cc2359aff69af3374d20f1cf8298b4ecaacd9'
    Public key X: b' 53 5d 4a c6 98 e8 5f cd 57 a6 ab cd 0e 75 44 21 b7 33 82 6f 1b e8 6a 2e a1 7a 5b 56 34 9e 57 ff '
    Public key Y : b' e9 af 96 6c 93 60 f4 a8 c8 dc ec f2 f1 0c c2 35 9a ff 69 af 33 74 d2 0f 1c f8 29 8b 4e ca ac d9 '
    Public key X in reversed format : b'ff579e34565b7aa12e6ae81b6f8233b72144750ecdaba657cd5fe898c64a5d53'
    Public key Y in reversed format: b'd9acca4e8b29f81c0fd27433af69ff9a35c20cf1f2ecdcc8a8f460936c96afe9'
    Signer Info: b0 73 d4 64 6a 71 1a fa
    Public key X in C format : {0x53,0x5d,0x4a,0xc6,0x98,0xe8,0x5f,0xcd,0x57,0xa6,0xab,0xcd,0x0e,0x75,0x44,0x21,0xb7,0x33,0x82,0x6f,0x1b,0xe8,0x6a,0x2e,0xa1,0x7a,0x5b,0x56,0x34,0x9e,0x57,0xff}
    Public key Y in C format : {0xe9,0xaf,0x96,0x6c,0x93,0x60,0xf4,0xa8,0xc8,0xdc,0xec,0xf2,0xf1,0x0c,0xc2,0x35,0x9a,0xff,0x69,0xaf,0x33,0x74,0xd2,0x0f,0x1c,0xf8,0x29,0x8b,0x4e,0xca,0xac,0xd9}
    Signer info  in C format : {0xb0,0x73,0xd4,0x64,0x6a,0x71,0x1a,0xfa}

  • 0 in reply to kazola
    TI__Genius 16825 points

    Hello Kazola,

    Thanks for reaching out.

    I will look into this issue on my side. Have you been able to reproduce with a custom TI launchap?

    BR,

    David.

  • 0 in reply to David
    Guru 18645 points

    Hi David,

    Thanks! Yes, this happens everywhere. The hardware works fine. It is something on the firmware side on that function I mention. Maybe my 3 questions above can bring some light on what can be happening. Maybe I don't need this function at all?

    Please let me know.

  • 0 in reply to kazola
    TI__Genius 16825 points

    Hello Kazola,

    Could we check the difference between the internal and external generated image, I would suspect a difference on the header section that we can inspect to see if the internal one requires authentication. It might be that it is not needed and only the external one is encrypted to avoid eavesdrop on the SPI lines.

    BR,

    David