<?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 S32K144 CSEc Application MAC Storage Options for Secure Boot Verification in S32K</title>
    <link>https://community.nxp.com/t5/S32K/S32K144-CSEc-Application-MAC-Storage-Options-for-Secure-Boot/m-p/2289948#M55973</link>
    <description>&lt;P&gt;&lt;SPAN&gt;&lt;STRONG&gt;Hardware:&lt;/STRONG&gt;&amp;nbsp;S32K144EVB-Q100&lt;BR /&gt;&lt;STRONG&gt;Software:&lt;/STRONG&gt;&amp;nbsp;S32 Design Studio, OpenBLT Bootloader, an5401-csec&lt;BR /&gt;&lt;BR /&gt;We intend to protect only the bootloader using BOOT_DEFINE (16KB protected) and want the bootloader to verify the application MAC on every reset to establish a proper chain of trust.&lt;BR /&gt;&lt;BR /&gt;We currently have a hardcoded CMAC value that we store and verify upon every reset as a proof of concept.&lt;BR /&gt;&lt;BR /&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;After bootloader verification (BOK=1), we need to verify application on every reset. For this, we need to:&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;Store application MAC&amp;nbsp;somewhere during programming&lt;/LI&gt;&lt;LI&gt;Verify application MAC&amp;nbsp;on every reset&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;We've considered these options but have concerns:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;P&gt;&lt;STRONG&gt;CSEc KEY slots (like KEY_2)&lt;/STRONG&gt;: Can't read back stored keys due to SHE protocol security - keys are write-only. How can we retrieve MAC for comparison?&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;&lt;STRONG&gt;Flash memory&lt;/STRONG&gt;: Not suitable because application area gets erased when new application is programmed, so stored MAC would be lost.&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;&lt;STRONG&gt;EEPROM&lt;/STRONG&gt;: Is this a good approach? Any recommended EEPROM addresses?&lt;/P&gt;&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;What other approaches would be suitable for storing application MAC that bootloader can reliably read for verification on every reset?&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;</description>
    <pubDate>Thu, 08 Jan 2026 07:38:15 GMT</pubDate>
    <dc:creator>Kishore_14</dc:creator>
    <dc:date>2026-01-08T07:38:15Z</dc:date>
    <item>
      <title>S32K144 CSEc Application MAC Storage Options for Secure Boot Verification</title>
      <link>https://community.nxp.com/t5/S32K/S32K144-CSEc-Application-MAC-Storage-Options-for-Secure-Boot/m-p/2289948#M55973</link>
      <description>&lt;P&gt;&lt;SPAN&gt;&lt;STRONG&gt;Hardware:&lt;/STRONG&gt;&amp;nbsp;S32K144EVB-Q100&lt;BR /&gt;&lt;STRONG&gt;Software:&lt;/STRONG&gt;&amp;nbsp;S32 Design Studio, OpenBLT Bootloader, an5401-csec&lt;BR /&gt;&lt;BR /&gt;We intend to protect only the bootloader using BOOT_DEFINE (16KB protected) and want the bootloader to verify the application MAC on every reset to establish a proper chain of trust.&lt;BR /&gt;&lt;BR /&gt;We currently have a hardcoded CMAC value that we store and verify upon every reset as a proof of concept.&lt;BR /&gt;&lt;BR /&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;After bootloader verification (BOK=1), we need to verify application on every reset. For this, we need to:&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;Store application MAC&amp;nbsp;somewhere during programming&lt;/LI&gt;&lt;LI&gt;Verify application MAC&amp;nbsp;on every reset&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;We've considered these options but have concerns:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;P&gt;&lt;STRONG&gt;CSEc KEY slots (like KEY_2)&lt;/STRONG&gt;: Can't read back stored keys due to SHE protocol security - keys are write-only. How can we retrieve MAC for comparison?&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;&lt;STRONG&gt;Flash memory&lt;/STRONG&gt;: Not suitable because application area gets erased when new application is programmed, so stored MAC would be lost.&lt;/P&gt;&lt;/LI&gt;&lt;LI&gt;&lt;P&gt;&lt;STRONG&gt;EEPROM&lt;/STRONG&gt;: Is this a good approach? Any recommended EEPROM addresses?&lt;/P&gt;&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;What other approaches would be suitable for storing application MAC that bootloader can reliably read for verification on every reset?&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Thu, 08 Jan 2026 07:38:15 GMT</pubDate>
      <guid>https://community.nxp.com/t5/S32K/S32K144-CSEc-Application-MAC-Storage-Options-for-Secure-Boot/m-p/2289948#M55973</guid>
      <dc:creator>Kishore_14</dc:creator>
      <dc:date>2026-01-08T07:38:15Z</dc:date>
    </item>
    <item>
      <title>Re: S32K144 CSEc Application MAC Storage Options for Secure Boot Verification</title>
      <link>https://community.nxp.com/t5/S32K/S32K144-CSEc-Application-MAC-Storage-Options-for-Secure-Boot/m-p/2290323#M55991</link>
      <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://community.nxp.com/t5/user/viewprofilepage/user-id/257154"&gt;@Kishore_14&lt;/a&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Common approach is to have CMAC stored in code flash, it can be appended to application which is being verified by this CMAC.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;“&lt;STRONG&gt;Flash memory&lt;/STRONG&gt;: Not suitable because application area gets erased when new application is programmed, so stored MAC would be lost.”&lt;/P&gt;
&lt;P&gt;- You don’t need old CMAC when updating the application. You need the new one for new application. I can’t see problem here. &amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Storing the CMAC to CSEc key slot is not an option, you can’t export it or use it as a CMAC.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Regards,&lt;/P&gt;
&lt;P&gt;Lukas&lt;/P&gt;</description>
      <pubDate>Thu, 08 Jan 2026 15:10:34 GMT</pubDate>
      <guid>https://community.nxp.com/t5/S32K/S32K144-CSEc-Application-MAC-Storage-Options-for-Secure-Boot/m-p/2290323#M55991</guid>
      <dc:creator>lukaszadrapa</dc:creator>
      <dc:date>2026-01-08T15:10:34Z</dc:date>
    </item>
  </channel>
</rss>

