S32K3 Secure boot implement

最新推荐文章于 2024-08-15 10:58:02 发布

鸟枪涣大炮

最新推荐文章于 2024-08-15 10:58:02 发布

阅读量3.4k

点赞数 25

文章标签： linux

本文链接：https://blog.csdn.net/m0_54090930/article/details/134783454

版权

安全启动模式
有三种可用的机制来配置应用程序映像的安全引导流：
在这里插入图片描述

配置这些安全引导模式的过程如下图8所示：
在这里插入图片描述

(a) Basic Secure Boot (b) Advanced Secure Boot © SHE based Secure Boot

在实现secure boot前要先做好如下准备：
1.安装HSE FW
在使用HSE的任何服务之前，用户需要安装HSE FW。根据设备的配置，可以安装FULL_MEM 或 AB_SWAP 映像。HSE FW的安装是一次性的过程，HSE FW只能更新，安装后不能卸载。
在安装固件之前，必须启用UTEST区域中的“HSE FW特性标志”，并且有两种方法可在系统中安装HSE FW：
运行设置在0x004000000等码闪区起始位置的HSE FW的加密图像，并进行复位。复位后，SBAF将安装HSE FW。
运行IVT中HSE FW的地址加密图像，并在提供的地址对加密的HSE FW图像进行编程。在编程完成后，提供一个重置。
在这里插入图片描述

HSE FW安装与 IVT（FULL_MEM）
安全引导辅助闪存（又名SBAF）是NXP在生产过程中编程的一个软件组件。此软件组件位于HSE代码闪存区中，（SBAF）是重置后在HSE_B安全核心上运行的第一个代码，它完成必要的系统初始化，解析图像向量表（IVT），执行secure boot并启动应用程序核心。通过接口 HseResponse = EnableHSEFWUsage(); /* user has requested to program HSE FW feature flag */来实现安装设置。

ps：1.安装过程首先区分HSE_FW类型（AB or FULL_MEM）
2.安装过程可通过三种途径：
1）运行 IVT和加密的FW-IMG来安装HSE
2）加密的FW-IMG镜像在默认位置IVT_START运行（Application NVM location ），此过程在设备中没有运行IVT
3）通过在系统内存（RAM中）中放置加密的FW-IMG，加密的FW-IMG的起始地址必须通过MU通道0接口通过应用程序提供。
3.HSE需要配置：可以通过HSE管理服务提供一组安全NVM中的一组可编程HSE系统属性。其中一些属性，一旦设置好，就无法更新。
2. Format catalogs 格式目录
在图10中，NVM和RAM key 目录必须通过结构体 hseFormatKeyCatalogsSrv_t定义的密钥目录格式化服务进行处理，该服务只有在LC为CUST_DEL时才对主机可用。通过 hse_host_format_key_catalogs.c 中实现
在这里插入图片描述

图10 key目录、组、插槽
请注意，BSB模式使用ADKP作为“身份验证密钥”，ADKP是一个OTP属性，而不是目录中的一个公共密钥
密钥目录
密钥在三个关键目录中进行管理，ROM、NVM、RAM。每个关键目录都由一个唯一的标识符标识，并包含一组密钥组。ROM密钥目录由NXP定义，NVM和RAM密钥目录的结构由用户配置。
secure boot只能使用非易失性密钥来验证数据，因此身份验证密钥必须在NVM目录中。
密钥组
用户可以在目录中定义几个密钥组，每个组都是一组相同类型的加密密钥。
密钥槽
密钥槽是一个内存容器，它包含单个密钥及其值和属性。每个插槽都由声明它的键组中的一个索引来标识
上图显示了key目录、组和插槽之间的关系。键句柄的访问格式为：𝐶𝑂𝑁𝐶𝐴𝑇（0x00、目录类型、组索引、插槽索引）
3. Install keys
除密钥类型HSE_KEY_TYPE_SHE外，主机在NVM和RAM密钥目录中声明的所有加密密钥都可以通过由结构体hseImportKeySrv_t 结构体定义的密钥导入服务提供（即初始化和更新）。
SHE 密钥是由主机通过hseSheLoadKeySrv_t或hseSheLoadPlainKeySrv_t服务接口提供的。
在这里插入图片描述

密钥可以以纯文本或加密文本安装，如图所示，在附加的secure boot演示中，所有密钥都以纯文本安装
3.1.关键属性->使用情况标志
表2中的 key 使用标志（位字段）是一组定义如何使用一个key的标志。在SMR表中，身份验证密钥使用标志应该为HSE_KF_USAGE_VERIFY，而不能设置HSE_KF_USAGE_SIGN标志。
表2 key的使用标志
Enumerate 枚举
Influence on the key when set设置时对key的影响
HSE_KF_USAGE_SIGN 对于RSA/ECC密钥：该密钥可用于签名生成（仅适用于私钥部分）
对于AES/TDES/HMAC密钥：该密钥可用于MAC的生成。
HSE_KF_USAGE_VERIFY 对于RSA/ECC密钥：该密钥可用于签名验证（仅适用于公钥部分）。对于AES/TDES/HMAC密钥：该密钥可用于MAC验证。
3.2.关键属性-> SMR验证映射
如表3所示的SMR验证映射（位字段）是一组标志，它定义了在使用密钥之前必须验证哪些安全内存区域（SMR）。当核心复位表属性“对验证失败的制裁”'Sanctions on failed verification’设置为“HSE_CR_SANCTION_DIS_INDIV_KEYS”时，SMR验证映射将生效。

                      表3     密钥使用情况的SMR验证图

Enumerate 枚举
Influence on the key when set设置时对key的影响
HSE_KF_SMR_0 只有在安全内存区域#0已被成功验证时，才能使用该密钥。
HSE_KF_SMR_1 只有在安全内存区域#1已被成功验证时，才能使用该密钥。
… …
HSE_KF_SMR_7 只有在安全内存区域#7已被成功验证时，才能使用该密钥。

例如，只有当安全内存区域#2和#5被成功验证时，才能使用一个密钥，则SMR验证映射必须设置为：
HSE_KF_SMR_2 | HSE_KF_SMR_5。
4.修改链接文件 link file
要启用secure boot功能，必须修改链接文件，以配置IVT、AppBL、Cfg和App flash代码的内存位置。此外，在链接文件中可能还需要更改一些项目配置。
在这里插入图片描述

上面的图显示了Cfg和App链接文件之间的主要内容和关系。对于IVT和AppBL的详细信息，用户可以直接查看代码，并根据需要更改内容。
在这里插入图片描述

App工程二进制文件已被重新定位并放置在Cfg项目链接文件中，因此App和Cfg工程代码都将被一次性下载到FLASH中。

下载后，Cfg和App工程代码都在FLASH上，而BCW中的“BOOT_SEQ”位是“0”（非安全引导），因此Cfg项目程序将在开机时执行。
当在Cfg工程中完成安全引导的配置时，“BOOT_SEQ”位需要更改为“1”（安全引导），然后在重置后执行应用程序

4.1.IVT - Cfg工程
下图13显示了Cfg项目中的IVT内容，包括Cfg工程代码、应用程序工程代码、备份应用程序工程代码、安全引导配置后需要更改的 Boot Configuration Word （BCW）等地址。
需要注意的是，IVT需要放置在闪存块的开始位置，它通常占据一个完整的扇区（对于S32K344，擦除操作在扇区中进行，一个扇区是8KB，0x2000B），尽管它的大小只有256字节。
在这里插入图片描述

        图13.        Cfg代码中的IVT内容

IVT中的启动参数
在IVT中的BCW（引导配置Word）中，可以设置影响HSE和系统启动行为的一组可编程参数
在这里插入图片描述

当BOOT_SEQ等于0并且BOOT_TARGET被设置为与0不同的值时，应用程序的启动地址也必须在IVT中提供，因为选定的CPU子系统将被重置释放。
BOOT_TARGET中的多个位可以设置为1，就可以同时释放多个CPU子系统。

4.2. AppBL - App project
下图14显示了App工程中的AppBL内容，包括App代码启动地址、代码大小以及一些基本安全引导所需的信息。应用程序代码地址需要对齐，并通常放置在一个扇区的开始。

在这里插入图片描述

图14. App工程中的AppBL内容

Advance Secure Boot 实现
代码实现逻辑：
1.关闭cache
HSE服务结构是通过MU在S32K3xx和HSE之间传递的，HSE将根据结构中的服务ID和参数（可以是值或地址）来执行服务。
对于在双核之间传输的数据，将被至少一个内核修改，当启用Dcache时，将出现数据同步问题。
为了解决这个问题，用户可以选择简单地关闭 d-cache，尽管会失去性能，或者将可能有数据同步问题的数据放在不可缓存的内存区域。
在这里插入图片描述

HSE接口通信详情可查看手册2.2
2.硬件初始化
BSP_Init();
3.安装HSE FW
/* user has requested to program HSE FW feature flag /
HseResponse = EnableHSEFWUsage();
4.获取HSE-FW type
/ HSE-FW type , interface , A or B side , etc */
GetHseInfo( ) ;
5.检查HSE_FW安装后状态
a.检查NVM and RAM keys already formatted HseResponse = HSE_Config();
b.格式化NVM and RAM 密钥目录 srvResponse = HSE_ConfigKeyCatalogs();
c.检查用户是否有SU权限，如果没有则请求 HseResponse = Sys_Auth();
d.导入用于加密操作和安全启动的密钥 HseResponse = Generic_ImportKeys(); srvResponse = HSE_InstallNvmKeys();

6.secure boot配置
a.检查 IVT APPBL 是否有效（查看状态字pIvtPassive->IVT_header）
b.具体配置 HseResponse = SecureBootConfiguration();
1.配置HSE secure boot模式（BSB ASB SHE三种模式）

在这里插入图片描述

2.这里以ConfigureSHESecureBoot配置举例说明（SHE模式）
a）将长度为256B的IVT从BLOCK0段复制到数据闪存段
b) 从本地变量中拷贝应用程序的起始地址。在SHE安全启动的情况下，应该配置SMR#0，以便在本地变量中复制应用程序地址。 smrEntry[smr]结构体赋值
c) 配置CR 入口 crEntry[app_core]结构体赋值
d) 导入密钥 & 安装SMR 接口：srvResponse = HSE_InstallSmrEntry
1.清除位于共享内存中的服务描述符
2.填写服务描述符 pSmrEntryInstall结构体赋值
在这里插入图片描述

3.发送MU同步请求接口：srvResponse = HSE_Send(MU0, u8MuChannel, gSyncTxOption, pHseSrvDesc);

e) 安装 CR srvResponse = HSE_InstallCoreResetEntry( smr,&(crEntry[app_core]) );
1.清除位于共享内存中的服务描述符
2.填写服务描述符接口： pCrEntryInstallSrv结构体赋值
在这里插入图片描述

3.发送同步请求（通过MU共享内存）接口：srvResponse = HSE_Send(MU0, u8MuChannel, gSyncTxOption, pHseSrvDesc);

           f)   验签流程 通过接口：   srvResponse = GetAttr( HSE_SMR_CORE_BOOT_STATUS_ATTR_ID, sizeof(hseAttrSmrCoreStatus_t),(void *)(&smrCoreStatus_Get) );
         g）配置完成，最后一步使能安全启动   BOOT_SEQ = 1 在 IVT中的BCW  bit3 中设置；通过接口：UpdateIVT()进行配置

其中 IVT 架构：

在这里插入图片描述

根据上述代码实现对每个步骤的实现进行对应说明：
实现高级安全引导和基于SHE的安全引导模式，这些模式都通过SMR和CR表实现，通过HSE内存验证服务实现。由这些服务管理的安全内存区域（SMR）提供了在安全引导失败时应用不同类型的制裁的可能性。它支持多种认证方案（MAC、RSA/ECC签名），以保证应用程序映像的真实性，并可以通过依赖于HSE执行的真实性检查来加快启动时的验证时间。下图显示了基于SMR和CR表的内存验证服务的执行过程.
在这里插入图片描述

          说明内存验证服务(SMR) 
如图所示，安全内存区域（SMR）由起始地址和大小定义，即MAC或RSA/ECC签名，用来验证该区域的内容。主机最多可以定义8个集群到SMR表中的SMR。它还必须为除SMR #0之外的每个内存区域内容提供真实性证明。

对于已定义的所有SMR，HSE将验证内存内容的真实性：
1.设备启动阶段（复位后）
2.当应用程序（正在）在主机端运行时（在运行时期间）。
SMR的验证结果可转化为HSE对该系统实施的制裁：
1.不成功的验证可以使主机侧上的选定子系统处于重置状态，这些子系统在核心重启（CR）表中被引用。
2.同样地，如果不能验证某些SMR可能会使HSE中选择的密钥不可用，这些限制是通过SMR验证映射为每个密钥单独定义的。
4.1. Secure Memory Region (SMR)
4.1.1. SMR table
存储在HSE安全数据闪存中的SMR表的内部闪存允许主机定义最多8个内存区域，并将每个内存区域与安装和验证方法相关联。SMR表中的每个SMR条目都包含下表4中列出的一组属性。
表4 SMR表条目属性
在这里插入图片描述

SMR table配置通过接口进行配置 static void ConfigureSMR( hseAppHeader_t *ptr_AppHeader, uint32_t AppAddress)
在这里插入图片描述

Authentication strategy 认证策略
secure memory region （SMR）安装的必要准备是确定验证方案、验证密钥和初始验证证明。
• Scheme方案
如图16所示，在安装或验证阶段，支持MAC和签名等多个验证方案来验证SMR，每个不同方案还需要用户填写的具体参数。例如，当使用GMAC或rsaPss方案时，用户需要手动配置如图所示的具体参数。

• Key
真实性密钥必须存储在NVM密钥目录中，其身份验证密钥使用标志应该是HSE_KF_USAGE_VERIFY，而不是HSE_KF_USAGE_SIGN。

• Proof
初始真实性证明（pInstausttag[]）是一个包含两个指针的数组，它们指向MAC或SIGN的地址。如果设置了HSE_SMR_CFG_FLAG_INSTALL_AUTH标志，则它将指定初始身份验证证明的地址。如果清除，则不使用此数据字段（使用内部哈希摘要SHA2-256）。
需要注意的是，对于MAC和RSA签名身份验证方案，只使用pInstAuthTag[0]，而[0]和[1]都用于ECDSA和EDDSA签名（由（r，s）指定，索引0处为“r”，索引1处为“s”）。
在这里插入图片描述

SMR认证方案

Configuration flags配置标志
表5详细显示了“配置标志”在不同条件下的效果。
表5. SMR配置标志
在这里插入图片描述

如果数据字段“配置标志”设置为HSE_SMR_CFG_FLAG_INSTALL_AUTH，则用户在安装阶段提供的身份验证证明（pInstAusthTag）也将在验证阶段使用。身份验证证明必须写入到S32K3xx内部闪存（P-Flash或D-Flash）上。
如果数据字段“配置标志”被清除，HSE将在安装阶段使用身份验证证明的内部计算（不使用pinstausttag），并将其保存在内部，并在验证阶段使用认证标签进行验证。即使没有使用smr hseSmrEntryInstallSrv_t中的身份安装标签，当调用安装服务hseSmrEntryInstallSrv_t时，应用程序仍然需要提供hseSmrEntryInstallSrv_t和身份标签长度，以确保初始数据的完整性，SHE安全引导模式除外。
当“配置标志”被清除时，SMR验证将比“配置标志”被设置为HSE_SMR_CFG_FLAG_INSTALL_AUTH时要快得多，并且不需要额外的闪存空间存储。但是，如果用户需要使用smr在启用了OTA的设备（HSE AB交换固件）上完成安全引导，则配置必须设置为HSE_SMR_CFG_FLAG_INSTALL_AUTH。

在这里插入图片描述

SHE based Secure Boot (SMR #0)
SMR #0是唯一可以与SHE AES密钥BOOT_MAC_KEY（keyHandle密钥句柄）作为SMR认证密钥关联的SMR。在这种情况下，引用身份验证标记是被称为BOOT_MAC的CMAC（authScheme认证方案）值，它可以通过SHE密钥更新协议进行初始化和更新。
此外，当主机被授予SU权限时，BOOT_MAC可以自动计算如下所述。
在第一次使用BOOT_MAC_KEY安装SMR #0时，如果BOOT_MAC为空（即未初始化），并且BOOT_MAC_KEY已经配置，则由HSE计算并保存在BOOT_MAC中。在BOOT_MAC已经初始化时使用BOOT_MAC_KEY安装SMR #0时，在发布SMR安装服务之前，必须通过SHE密钥更新协议更新BOOT_MAC值。
在所有情况下，数据字段pinstausthtag总是被丢弃，应该设置为NULL。
在这里插入图片描述

SMR installation
主机可以通过结构体hseSmrEntryInstallSrv_t定义的HSE服务请求SMR安装，SMR安装服务主要接受以下输入，如表6所示：
Table 6. Parameters of structure hseSmrEntryInstallSrv_t
Data field Description
entryIndex 标识必须安装/更新的SMR条目的索引（在SMR表中）（请参见#HSE_NUM_OF_SMR_ENTRIES)。
pSmrEntry 包含要安装的配置属性的SMR入口结构的地址，它将在验证阶段被存储和使用（参考hseSmrEntry_t）。
accessMode 指定访问模式（一次通过、启动、更新、完成）
pSmrData 要安装SMR数据的地址。
smrDataLength The length of the SMR data.
pAuthTag 要验证的SMR原始认证标签所在的地址（在FLASH或SRAM上）。有必要提供由pSmrData和smr数据长度确定的数据的mac和符号。当该服务被执行时，将验证所提供的pAuthTag，以确保安装阶段的数据是正确的，因此引导除外。
authTagLength SMR身份验证证明（TAG或SIGN）的长度。
cipher.pIV 初始化向量/Nonce（16个字节）。
cipher.pGmacTag 用于AEAD的可选的GMAC标记（16个字节）。

在这里插入图片描述

 当LC设置为CUST_DEL时，可以执行SMR条目的首次定义。此外，只有当主机被授予SU权限时，才能修改SMR条目中的大部分数据字段。

在这里插入图片描述

通过此服务进行的SMR安装可以在一次通过或流媒体模式下完成。当安装开始时，要安装的SMR内容在系统内存中不完全可用时，流媒体模式很有用（OTA用例）。此服务不使用流ID，因为HSE在流模式下处理时使用内部上下文。

4.1.3.1.One-pass installation mode
当要安装的SMR内容在Flash或RAM中完全可用时，最方便的处理方式是以一次性模式运行服务，在这种情况下：

数据字段访问模式必须设置为HSE_ACCESS_MODE_ONE_PASS。
数据字段 pSmrData 必须等于 pSmrEntry.pSmrSrc，即需要从其中加载 SMR的源地址。
数据字段 SMR数据长度必须等于 pSmrEntry.smrSize，即要加载或验证的SMR的字节大小。
数据字段的数据长度[0]（respectively authTagLength[1]）必须设置为数据字段[0]指向的字节数组(respectively pAuthTag[1])

4.1.3.2.Streaming installation mode

即使整个内容还没有用Flash或RAM编程，也可以处理SMR安装。这种用例的一个典型例子是一个图像（代码或数据），它太大，不能完全适合可用的应用程序RAM，并通过通信接口以块的形式提供给主机，然后每个单独的块在Flash中编程，在这种情况下：

只能在启动调用中提供SMR号（入口索引）、配置（pSmrEntry）和解密初始化向量（cipher.pIV）。

对于开始、更新或完成调用，数据字段pSmrData必须指向下一个SMR块进行处理，并且数据字段smrData长度设置为该块的大小。最小块大小为64字节

4.2. Core Reset (CR)
4.2.1. CR table

Core Reset（CR）表允许主机将设备中可用的每个cpu驱动的子系统与多达8个SMR关联起来，以便在启动前和启动后阶段之后，根据SMR验证状态对这些子系统执行制裁。对于具有内部闪存的设备，用户可以安装最多2个核心重置入口。CR表中的每个条目都包含表7中列出的一组属性。
表7. CR表项属性
在这里插入图片描述

4.2.1.1.Core identifier
每个cpu驱动的子系统都由一个唯一的数字（coreId）来标识。下表8列出了S32K3x4设备中的子系统及其各自的核心标识符。
表8 Subsystem vs. core identifiers (coreId)

如果CPU子系统没有列在核心重置表中，则HSE不会从重置中释放。
4.2.1.2.Verification map
CPU子系统与一组SMR的关联是通过数据字段 preBootSmrMap 和 altPreBootSmrMap实现的：
当位#i被设置为1时，SMR #i与该CPU子系统相关联。当验证所有相关的SMR时，在预启动阶段结束时，CPU子系统的状态取决于如下表9所示的几个条件
Table 9. Status of the CPU subsystem (all SMR verified in pre-boot phase)
在这里插入图片描述

4.2.2. Sanctions 制裁
HSE对与验证失败的SMR相关联的CR条目所采取的制裁取决于应用它时的阶段（即启动前或启动后）。

4.2.2.1.Pre-boot sanctions

下表10总结了在启动前和启动阶段中应用的制裁方面的条件和HSE行为。如果制裁为HSE_CR_SANCTION_DIS_ALL_KEYS，则禁用所有 密钥 ；否则，通过smrFlags key 属性(参见部分错误！找不到引用源。）

                               表10.子系统的制裁（启动前阶段未验证主映射中至少一个SMR）

在这里插入图片描述

4.2.2.2.Post-boot sanctions
下表11总结了在启动后阶段应用的制裁方面的条件和HSE行为。
表11.对子系统的制裁（至少一个在启动后阶段未验证的SMR）

在这里插入图片描述

CR installation
主机可以通过结构体 hseCrEntryInstallSrv_t定义的服务请求在核心重置（CR）表中安装条目，CR表项安装服务主要接受以下输入，如表12所示：

                                 Table 12. Parameters of structure hseSmrCrEntryInstallSrv_t

在这里插入图片描述

当LC设置为CUST_DEL时，可以执行CR项的首次定义。一旦定义，只有在首先成功验证所有相关的SMR时，才能更新CR条目。此外，要修改已定义的CR条目中的任何值，必须授予主机SU权限。此外，还注意到，至少有一个SMR应该通过pCrEntry.preBootSmrMap或pCrEntry.postBootSmrMap链接到CR条目。

此部分通过接口 hseSrvResponse_t HSE_InstallCoreResetEntry(const uint8_t entryIndex, const hseCrEntry_t *pCrEntry)进行相应配置
在这里插入图片描述

SMR verification
4.3.1. One-time automatic SMR verification

 当IVT中BOOT_SEQ等于1时，HSE使用SMR和CR表中的配置安全地启动应用程序内核。因此，与CR表链接的SMR会在启动时由HSE自动验证一次
启动时的自动验证分为三个阶段：
预启动阶段，在此期间，在主机中的任何CPU子系统解除重置之前，将验证SMR；这是启动后的第一阶段。

启动阶段，在主机中的第一个CPU子系统解除重置（当允许时）之后验证SMR；这是启动后的第二个阶段。
启动后阶段，在此期间，在主机中的所有CPU子系统都已解除重置（当允许时）后，将验证SMR；这是启动后的第三个阶段
可以通过HSE_STATUS_BOOT_OK状态标志监控启动前和启动阶段的结束，启动后阶段的结束可以通过状态标志HSE_STATUS_INIT_OK进行监控，如下图17所示。
在这里插入图片描述

4.3.1.1.Pre-boot phase

在启动前阶段，HSE将CR表从最小的输入索引解析到最高的。对于每个CR条目，首先验证通过pCrEntry.preBootSmrMap数据字段链接的SMR。如果这些SMR验证失败，HSE将验证pCrEntry.altPreBootSmrMap数据字段指定的SMR。
如果所有的 SMR 都从任何一个 pre-boot SMR 映射验证成功，HSE 可以根据核心重置释放策略释放主机中的重置CPU子系统。
如果两个 pre-boot SMR映射（包括altPre-boot）都至少有一个验证失败的SMR，HSE将为该CR条目配置的制裁。

4.3.1.2.Boot phase and core reset release strategies
当在启动前阶段解析CR表时，HSE根据核心重置释放策略释放相关CPU的重置，可通过hseAttrCoreResetRelease_t属性进行配置：
ALL_AT_ONCE，HSE首先解析整个CR表，验证所有相关的预引导前SMR条目，然后从重置所有配置的CPU子系统中释放
ONE_BY_ONE，在成功验证相关的CR项和预启动SMR项后，HSE从重置每个CPU子系统中释放。
当第一个CPU子系统解除重置时，预启动阶段结束。
预引导和引导阶段的结束，这意味着所有已配置的CPU子系统都由HSE通过状态标志HSE_STATUS_BOOT_OK发出信号。

4.3.1.3.Post-boot phase 启动后阶段
在所有配置的应用程序CPU子系统从重置中释放并启动阶段结束后，HSE通过CR表重复，对于每个条目，它验证通过pCrEntry.postBootSmrMap数据字段链接的相关SMR。
如果在启动后阶段验证的任何SMR验证失败，HSE将对相关的CR条目应用配置的制裁。在这种情况下，HSE_CR_SANTCION_KEEP_CORE_IN_RESET不适用（即HSE不能将已启动的应用程序CPU保持在重置阶段）。

4.3.1.4.Secure boot flow
下图18详细说明了在启动前和启动后阶段的SMR验证过程，以及HSE在每个阶段结束时所采取的制裁。红线和蓝线分别代表纯PRE_BOOT模式和POST_BOOT模式的引导流。
在这里插入图片描述

        图18.对高级安全启动模式的SMR验证和制裁

4.3.2. On-demand SMR verification按需SMR验证

未链接到CR表的SMR条目将被验证，直到主机在运行时通过结构体 hseSmrVerifySrv_t定义的服务触发验证，
此服务只接受一个指定要验证的SMR的索引的数据字段（entryIndex）。
此服务还可以用于在运行时验证任何SMR。但是，当要验证的SMR处于Flash中时，必须确保在进行验证时主机没有触发并发编程操作

4.3.3. Recurrent automatic SMR verification循环自动SMR验证

当其数据字段pSmrEntry.checkPeriod设置为与0不同的值时，在运行时，即在正常操作条件下，在正常操作条件下，一旦启动前和启动后阶段结束，HSE会自动自动验证SMR。
验证递归由几个系统时钟周期定义，每个单元对应最大频率的10 ms。例如，如果smrEntry.checkPeriod = 200，对于系统时钟频率为400MHz，200Mhz等为4秒，每2秒触发一次验证过程。
它可以为任何加载在RAM中的SMR进行配置，并且由HSE生成的内部真实性证明用于验证（即没有设置HSE_SMR_CFG_FLAG_INSTALL_AUTH）。

4.3.4. SHE secure boot mode (only use SMR #0)
SMR #0是唯一可以与SHE AES密钥BOOT_MAC_KEY作为SMR认证密钥关联的SMR。在本例中，引用身份验证标记是被称为BOOT_MAC的CMAC值。
如果是BOOT_SEQ = 1，则会启动如REF02第8.7.2节中提到的身份验证过程。参考身份验证标签由HSE计算出来，并与保存的BOOT_MAC进行比较。如果是BOOT_SEQ = 0，则启动REF02 8.5.4.2节中提到的身份验证过程。
图19显示了基于SHE的安全引导模式的SMR验证过程，该模式也使用了SMR和CR表。
在这里插入图片描述

Basic Secure Boot

BSB是一种简化的引导方案，不像基于SMR的ASB。在这种情况下，HSE FW基于结构体 hseBootDataImageSignSrv_t定义的“引导数据签名”服务，一次只启用一个应用程序核心（已启动的核心可以启动其他核心）
另外，当验证失败，应用程序核心进入恢复模式，不执行任何程序时，BSB模式不能使用制裁。

5.1. Application debug key/password (ADKP)

ADKP是一个HSE OTP（一次性程序）属性，不像一个可以擦除的普通NVM密钥。它通过RAM中的AES-GMAC算法计算16字节的应用程序的GMAC，基于SHA256操作在用户定义的ADKP上生成一个256位的AES密钥，如下图20(a).所示此外，需要注意的是，在使用“引导数据签名/验证”服务或调试保护之前，必须先设置ADKP。
ADKP是一个由HSE_APP_DEBUG_KEY_ATTR_ID属性配置的128位值，它只能写入一次（UTEST属性），并且只在CUST_DEL生命周期中允许此操作。
在HSE中配置之前，ADKP可以选择使用设备UID进行多样化，如图20(b)，因此，使IVT / CFG认证密钥设备特定。

在这里插入图片描述

5.2. Configuration

主机（S32K344）可以通过由结构体 hseBootDataImageSignSrv_t定义的服务，通过主机系统映像请求计算认证标签（GMAC）。

在这里插入图片描述

只有当主机被授予超级用户（SU）权限（LC可以是CUST_DEL、OEM_PROD或IN_FIELD）并且被写入了ADKP时，主机才可使用此服务。

在这里插入图片描述

在向HSE发送服务请求之前，需要确认AppBL报头标签是正确的，否则将会发生错误。
“Boot Data Verify”服务需要一个用于存储GMAC（身份验证标记）值的缓冲区，并且还需要提供AppBL启动地址。
在该服务完成后，需要根据AppBL中的代码号，将从RAM中生成的GMAC复制到应用程序的末端，如下图21所示

在这里插入图片描述

为了确保上述配置完成并成功，可以调用结构体 hseBootDataImageVerifySrv_t  定义的“Boot Data Verify”服务，需要提供AppBL地址。
用户必须注意应用程序的起始地址必须对齐（在S32K3xx中需要128字节对齐），否则它将不能正常运行，并且在App代码之前有一个64字节的应用程序头。因此，用户可以通过这种方式设置应用程序的链接文件，应用程序头可以设置0x005040C0作为起始地址，在64字节之后，应用程序代码的起始地址为0x00504100。编译后的bin文件以应用程序头开头，需要写入FLASH地址0x005040C0。

Enable Secure Boot

6.1. Set BOOT_SEQ
要启用secure boot，如图21所示，IVT中BCW的位文件BOOT_SEQ必须设置为“1”，才能从默认的启动流更改为安全的启动流。
在这里插入图片描述

数据字段BOOT_SEQ，对引导序列流的影响：
当0：释放主机从重置，然后运行HSE固件
当1：保持主机重置，并首先运行HSE固件；必须设置为运行启动前验证

在这里插入图片描述

6.2. Update IVT
存储在Flash中的IVT内容需要更新，建议有一个备份IVT，以确保在另一个IVT的数据损坏时程序可以运行。
IVT的起始地址可以在下表15中提供的一个值中选择。在重置时，HSE从最低地址开始搜索第一个有效的IVT头标记
在这里插入图片描述

此步骤可以在安全引导配置完成并成功后执行，或者在安装SMR之前执行，以像任何其他内存区域一样通过SMR保护IVT。
IVT可以保护IVT内容免受基于服务“BOOT_DATA_SIGN”的未经授权的更改，该服务的工作原理类似于BSB模式。身份验证标签被计算并附加到IVT的末尾。要启用IVT认证，一次性可编程的HSE系统属性IVT_AUTH必须设置为1.