Kinetis Bootloader v2.0.0 - SB boot image authentication code

[embeddeddavid]

Hello folks,

I have been playing around with Kinetis Bootloader v2.0.0 for a while (flash bootloader configuration) and it seems pretty cool :smileycool: 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!

[jingpan]

Hi,

Yes, it seems kboot doesn't use m_digest field to check sb file head.
The image authentication code computed from the entire rest of the image. It isn’t particularly useful for the ROM, but can be used by host-resident utilities to verify and authenticate boot images before using them. It isn't a part of section data region. From the user manual, it seems that a bootable section is ended with a ROM_TAG_CMD with ROM_LAST_TAG.

Regards,

Jing

[embeddeddavid]

Hi Jing,

Thanks a lot for your time. In that case I guess, as you suggest in your post, that Kinetis Flash Tool authenticates the *.sb file before sending it to Kinetis MCU.

Best Regards,