<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Kinetis Bootloader v2.0.0 - SB boot image authentication code in Kinetis Microcontrollers</title>
    <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/Kinetis-Bootloader-v2-0-0-SB-boot-image-authentication-code/m-p/755001#M46055</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello folks,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;According to Kinetis Bootloader v2.0.0 Reference Manual, Rev. 0, 04/2016 - 5.18 ReceiveSBFile command, page 64:&lt;/P&gt;&lt;P&gt;&lt;EM&gt;'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.'&lt;/EM&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;Just one entry in the section table.&lt;/LI&gt;&lt;LI&gt;A single entry in the DEK dictionary.&lt;/LI&gt;&lt;LI&gt;Just one section (section 0, bootable) along with its corresponding boot tag.&lt;/LI&gt;&lt;LI&gt;A single boot command: ROM_LOAD_CMD.&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;As far as I have understood, the SB loader state machine does the following:&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;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.&lt;/LI&gt;&lt;LI&gt;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.&lt;/LI&gt;&lt;LI&gt;Search the boot tag paired with the bootable section by sequentially calling the functions ldr_GoToNextSection,&amp;nbsp;ldr_DoCommand and ldr_DoTagCmd.&lt;/LI&gt;&lt;LI&gt;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.&lt;/LI&gt;&lt;LI&gt;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.&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Is there anything I am missing concerning the authentication code? Any information concerning this issue would be really appreciated. Thanks in advance.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Keep on rocking!&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Tue, 15 May 2018 10:27:57 GMT</pubDate>
    <dc:creator>embeddeddavid</dc:creator>
    <dc:date>2018-05-15T10:27:57Z</dc:date>
    <item>
      <title>Kinetis Bootloader v2.0.0 - SB boot image authentication code</title>
      <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/Kinetis-Bootloader-v2-0-0-SB-boot-image-authentication-code/m-p/755001#M46055</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello folks,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;According to Kinetis Bootloader v2.0.0 Reference Manual, Rev. 0, 04/2016 - 5.18 ReceiveSBFile command, page 64:&lt;/P&gt;&lt;P&gt;&lt;EM&gt;'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.'&lt;/EM&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;Just one entry in the section table.&lt;/LI&gt;&lt;LI&gt;A single entry in the DEK dictionary.&lt;/LI&gt;&lt;LI&gt;Just one section (section 0, bootable) along with its corresponding boot tag.&lt;/LI&gt;&lt;LI&gt;A single boot command: ROM_LOAD_CMD.&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;As far as I have understood, the SB loader state machine does the following:&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;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.&lt;/LI&gt;&lt;LI&gt;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.&lt;/LI&gt;&lt;LI&gt;Search the boot tag paired with the bootable section by sequentially calling the functions ldr_GoToNextSection,&amp;nbsp;ldr_DoCommand and ldr_DoTagCmd.&lt;/LI&gt;&lt;LI&gt;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.&lt;/LI&gt;&lt;LI&gt;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.&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Is there anything I am missing concerning the authentication code? Any information concerning this issue would be really appreciated. Thanks in advance.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Keep on rocking!&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 15 May 2018 10:27:57 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Microcontrollers/Kinetis-Bootloader-v2-0-0-SB-boot-image-authentication-code/m-p/755001#M46055</guid>
      <dc:creator>embeddeddavid</dc:creator>
      <dc:date>2018-05-15T10:27:57Z</dc:date>
    </item>
    <item>
      <title>Re: Kinetis Bootloader v2.0.0 - SB boot image authentication code</title>
      <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/Kinetis-Bootloader-v2-0-0-SB-boot-image-authentication-code/m-p/755002#M46056</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;Yes, it seems kboot doesn't use m_digest field to check sb file head.&lt;BR /&gt;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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Regards,&lt;/P&gt;&lt;P&gt;Jing&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 29 May 2018 10:08:37 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Microcontrollers/Kinetis-Bootloader-v2-0-0-SB-boot-image-authentication-code/m-p/755002#M46056</guid>
      <dc:creator>jingpan</dc:creator>
      <dc:date>2018-05-29T10:08:37Z</dc:date>
    </item>
    <item>
      <title>Re: Kinetis Bootloader v2.0.0 - SB boot image authentication code</title>
      <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/Kinetis-Bootloader-v2-0-0-SB-boot-image-authentication-code/m-p/755003#M46057</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi Jing,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks a lot for your time. In that case I guess, as you suggest in your post, that Kinetis Flash &lt;SPAN style="font-size: 11.0pt;"&gt;Tool authenticates the *.sb file before sending it to Kinetis MCU.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN style="font-size: 11.0pt;"&gt;Best Regards,&lt;/SPAN&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 30 May 2018 05:15:39 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Microcontrollers/Kinetis-Bootloader-v2-0-0-SB-boot-image-authentication-code/m-p/755003#M46057</guid>
      <dc:creator>embeddeddavid</dc:creator>
      <dc:date>2018-05-30T05:15:39Z</dc:date>
    </item>
  </channel>
</rss>

