embeddeddavid

Kinetis Bootloader v2.0.0 - SB boot image authentication code

Discussion created by embeddeddavid on May 15, 2018

Hello folks,

 

I have been playing around with Kinetis Bootloader v2.0.0 for a while (flash bootloader configuration) and it seems pretty cool so far. I have carefully read Kinetis Elftosb User's Guide Rev. 1, 04/2016 - SB boot image file format, encryption and decryption processes and image authentication code in particular. Nevertheless, I suspect the Kinetis Bootloader ignores the encripted SHA-1 digest and therefore does check neither authentication nor integrity of the boot image.

 

According to Kinetis Bootloader v2.0.0 Reference Manual, Rev. 0, 04/2016 - 5.18 ReceiveSBFile command, page 64:

'The Receive SB File command (ReceiveSbFile) starts the transfer of an SB file to the target. [...] The SB file is processed as it is received by the bootloader. [...] The Receive SB file command has a data phase; the host sends data packets until the number of bytes of data specified in the byteCount parameter of the Receive SB File command are received by the target.'

 

I have gone through the sbloader API (provided within the source code), which handles the incoming chunks during the data phase. Assuming an SB file with the following elements:

  • Just one entry in the section table.
  • A single entry in the DEK dictionary.
  • Just one section (section 0, bootable) along with its corresponding boot tag.
  • A single boot command: ROM_LOAD_CMD.

 

As far as I have understood, the SB loader state machine does the following:

  1. Process the boot image header and generate the CBC-MAC using the KEK (input vector = 0) by sequentially calling the functions ldr_DoHeader, ldr_DoHeader1, ldr_DoHeader2 and ldr_DoHeaderMac.
  2. Look for the CBC-MAC entry in the DEK dictionary and decrypt the DEK using the KEK (input vector = header's SHA-1 digest) by sequentially calling the functions ldr_DoKeyTest, and ldr_DoGetDek.
  3. Search the boot tag paired with the bootable section by sequentially calling the functions ldr_GoToNextSection, ldr_DoCommand and ldr_DoTagCmd.
  4. Decrypt and process the ROM_LOAD_CMD boot command by sequentially calling function ldr_DoLoadCmd (and therefore functions ldr_DoLoadChunks and ldr_DoLoadBytes). This leads to the copy of the decrypted chunks into the backup application region.
  5. When function ldr_DoCommand is called by ldr_DoLoadBytes function, the image authentication code (consisting of three chunks) is attempted to be handled as a new boot command. How can it be that the boot command checksum is ok? Moreover, the command tag may have a random value resulting in no command handler being called or, in the worst case, the execution of the wrong command handler.

 

Is there anything I am missing concerning the authentication code? Any information concerning this issue would be really appreciated. Thanks in advance.

 

Keep on rocking!

Outcomes