前言

概述

本文档主要是指导使用本安全启动方案的相关人员了解整个安全方案的流程，再通过一定的操作步骤和方法来使用本安全启动方案。主要介绍本安全启动的规格和特性，包括安全启动基本流程和key的层级结构与验签逻辑，及其整个安全启动方案的使用。

说明： 本文以SS928V100描述为例，未有特殊说明，SS927V100与SS928V100内容一致。

产品版本

与本文档相对应的产品版本如下。

产品名称

产品版本

SS928

V100

SS927

V100

读者对象

本文档（本指南）主要适用于以下工程师：

  • 技术支持工程师

  • 软件开发工程师

符号约定

在本文中可能出现下列标志，它们所代表的含义如下。

符号

说明

表示如不避免则将会导致死亡或严重伤害的具有高等级风险的危害。

表示如不避免则可能导致死亡或严重伤害的具有中等级风险的危害。

表示如不避免则可能导致轻微或中度伤害的具有低等级风险的危害。

用于传递设备或环境安全警示信息。如不避免则可能会导致设备损坏、数据丢失、设备性能降低或其它不可预知的结果。

“须知”不涉及人身伤害。

对正文中重点信息的补充说明。

“说明”不是安全警示信息，不涉及人身、设备及环境伤害信息。

修改记录

文档版本

发布日期

修改说明

00B01

2025-09-15

第1次临时版本发布。

安全特性

芯片提供了基于硬件可信根的各种丰富的安全特性，满足不同应用场景、不同安全级别的需求，便于客户产品安全启动方案的实施和落地。关键特性如下：

芯片内置OTP资源

OTP是一种特殊的非易失性存储器，允许编程一次，数据永久有效。利用OTP一次性编程的物理特性保存一些不可逆控制开关、硬件根密钥等。其中，密钥区域提供多个对称根密钥Slot，用于存储多个对称根密钥。密钥区域只能一次烧写，自动锁定，且不可回读。状态控制区域和用户自定义区域，可多次烧写，对应Bit位只能由0编程为1，已经为1的比特不可更新；如果需要一次烧写后，其内容不可更改，则可在数据写入后，锁定该区域。版本控制区域可多次烧写，所有比特只能由0写为1，不可逆，也不可锁定。

内置密钥管理模块

对于已经烧写进OTP的每一个对称根密钥，密钥管理模块会根据相应的外部输入（密钥派生材料），进行多级派生，生成对应的工作密钥，并将工作密钥直接送到加解密引擎（SPACC），实现对最终的数据进行加解密运算。整个密钥派生过程都在硬件逻辑内部完成，根密钥、密钥保护密钥、工作密钥都不会在内存中出现，也不能通过软件读取，提升了密钥的安全性。

内置硬件密码算法引擎

芯片硬件加解密算法引擎，支持多种常见的非对称密码算法、对称密码算法和哈希算法。安全启动方案采用RSA4096和SHA256算法，对镜像的签名校验。安全启动还可根据客户需求，决定是否支持对镜像进行加密保护，加解密算法为AES256。

安全信任链条

芯片支持基于硬件可信根的安全启动，实现从硬件可信根开始逐级校验，以保证启动过程可信。客户可以通过OTP保存公钥哈希值，并由芯片BOOTROM完成根公钥的完整性、真实性校验，以及下级公钥和镜像的逐级校验。

版本防回退

芯片OTP中预留版本控制区域，以便安全启动、安全升级中，实现版本防回滚控制，防止攻击者利用某个有缺陷的历史版本，回退替换新版本对设备进行攻击。

镜像结构统一

安全启动涉及较多的密钥和签名，需要附加在最终镜像中。为避免镜像制作和使用过程因多个版本而引入的各种问题，降低使用难度，本启动方案将安全启动、非安全启动的所使用的镜像统一为一种格式。在SoC不使能安全启动的情况下，非加密的安全启动镜像（带有对应的密钥和签名），仍可正常启动。

启动方案

  • 支持快速启动、非安全启动和安全启动3种启动方案。

  • 快速启动只有U-Boot一级Bootloader，由U-Boot直接引导Linux启动。

  • 非安全启动、安全启动包含两级Bootloader。

    • GSL为一级Bootloader；

    • U-Boot为二级Bootloader，客户根据产品需要，可在U-Boot中配置、开发对应的功能，如Flash驱动，Linux系统的引导等。

  • 表1比较各种启动方案特点，“√”表示启动方案具备该特点，反之不具备。

表 1 各启动方案特点比较

特点

快速启动

非安全启动

安全启动

使用U-Boot

√

√

√

使用GSL

-

√

√

解密验签镜像

-

-

√

须知： 芯片使用何种启动方案由OTP控制。出厂时，OTP被默认配置为非安全启动，可通过配置OTP来更改启动方案，OTP的配置方法参考下文的“OTP配置与烧写”章节。

快速启动

为兼容传统的启动方案，芯片支持快速启动方案。快速启动的流程如图1所示，直接从U-Boot启动，然后引导Linux启动。该方案不会校验启动镜像的合法性，是非安全的。快速启动的速度快于安全启动和非安全启动，在不需要安全启动且有速度要求的场景下，可以使用该启动方案。

图 1 快速启动流程

非安全启动

在非安全启动模式下，芯片从GSL启动，流程如图1所示。该方案不会校验启动镜像的合法性，是非安全的。

图 1 非安全启动流程

安全启动

与非安全启动方案相比，安全启动方案会校验启动镜像的合法性，方案在 “镜像解密和验签”有具体介绍，镜像的解密校验环节层层依赖，若中间某个环节校验失败，则启动失败，从而保证镜像的合法性、完整性，以及敏感数据的机密性。

安全启动在非安全启动的基础上，增加了镜像的合法性校验步骤，流程如图1所示。

图 1 安全启动流程

须知： 其中U-Boot验签Kernel和Rootfs环节未实现，客户可参考“内核及文件系统安全启动验签方案参考”，并结合应用场景调用Cipher API接口实现。

安全启动镜像布局和结构

安全启动模式镜像布局

安全启动镜像在启动介质上主要分为3大块：

  • 第一块为Boot image，整合了GSL和U-Boot二进制文件以及DDR表格的内容，布局如图1所示。

  • 第二块为Linux内核。

  • 第三块为文件系统。

图 1 安全启动镜像布局图

须知： 布局图标号1：Boot image 区域需放在启动介质0x00地址的起始位置，其余区域放置无特殊要求，可根据使用场景自行分配。

镜像结构细分图

Vendor_Root_Public_Key Area

其镜像分布图，如图1所示。

图 1 Vendor_Root_Public_Key Area

OEM_Root_Public_Key Area

其镜像分布图，如图1所示。

图 1 OEM_Root_Public_Key Area

Third_party_Root_Public_Key Area

其镜像分布图，如图1所示。

图 1 Third_party_Root_Public_Key Area

GSL Flash Mapping

GSL third party Key Area

其镜像分布，如图1所示。

图 1 GSL third party Key Area

GSL Key Area

其镜像分布图，如图1所示。

图 1 GSL Key Area

GSL Code Area

其镜像分布图，如图1所示。

图 1 GSL Code Area

Boot Flash Mapping

Key Area

其镜像分布图，如图1所示。

图 1 Key Area

Params Area

其镜像分布图，如图1所示。

图 1 Params Area

Unchecked Area for Vendor

其镜像分布图，如图1所示。

图 1 Unchecked Area for Vendor

须知： 该SCS_simulate_flag标志为在安全启动情况下，调试 “Boot Flash Mapping”区域预留的一个开关，当OTP相应KEY等信息位烧写后，OTP相应的安全启动标志位（字段：secure_boot_en）在未使能的情况下，该标志位生效。其作用为当用户烧写OTP后，不使能安全启动标志位，可通过配置该标志位模式来模拟使能安全启动标志位的情况进行调试“Boot Flash Mapping”区域。

U-Boot Area

其镜像分布图，如图1所示。

图 1 U-Boot Area

镜像解密和验签

本安全启动方案支持对镜像完整性校验，支持使用加密镜像。每一级镜像是否加密，以及使用的加密密钥都可以独立控制。对于加密的镜像，启动流程遵循先解密后验签的原则。安全启动方案支持第三方进行再次签名，双重确认镜像完整性。

根据“安全启动镜像布局和结构”所述，一个安全启动镜像被划分为了多个区域。每个区域中数据的内容，数据内容的加解密与完整性校验，都由此区域的Owner负责。如表1下各区域的归属情况。

表 1 区域Owner

区域名称

E安全启动

Vendor_Root_Public_Key Area

区域内数据无效

OEM_Root_Public_Key Area

OEM

Third_party_Root_Public_Key Area

Third party

GSL third party Key Area

GSL Key Area

OEM

GSL Code Area

Key Area

OEM

Params Area

Uncheck Area for Vendor

U-Boot Area

SoC安全启动公钥框架

SoC公钥层级架构设计支持芯片启动过程中，从OTP根公钥哈希值开始，对每一级镜像进行完整性校验，以及对下一级公钥进行完整性校验。以此实现启动流程中，各个阶段的信任传递。安全启动的验签使用的是RSA4096算法和HASH256。

安全启动方案提供了3个信任链，基于三个根公钥哈希值（存储在OTP中）。它们分别为Vendor、OEM和Third Party三方，对应的根公钥分别为Vendor_Root_Public_Key、OEM_Root_Public_Key和Third_party_Root_Public_Key。

在安全启动模式下，镜像的验签由OEM负责，其验签关系层次如图1所示。

图 1 安全启动模式公钥验签关系图

对称密钥管理

对于需要使用镜像解密功能的安全启动，芯片OTP需内置对应的对称密码算法（AES）根密钥。芯片OTP中预留4个128比特的根密钥空间，用于派生对应的密钥保护密钥，以及最终的工作密钥。客户可根据实际需要烧录其中一个或者多个根密钥。另外，芯片已预置一个128比特的Vendor 根密钥，存放在独立的OTP空间中（见《安全子系统使用说明》2.2章节“SSxxxx OTP字段定义”）。

芯片密钥派生

SoC提供三级密钥派生，其工作原理如图1所示。RKP从OTP中获得RKP保护的根密钥（OTP KEY），在RKP硬件内部生成实际的根密钥并通过安全通道送到KLAD。KLAD可以完成两级的密钥派生，每一级的密钥派生材料都可以从内存中输入。其中，一级密钥派生材料ProtectionKey_L1为128比特，二级密钥派生材料ProtectionKey_L2为256比特。KLAD基于OTP KEY和密钥派生材料，最终输出真正的工作密钥到硬件加解密引擎。

图 1 密钥派生

安全启动模式下密钥管理及镜像解密

安全启动的对称密钥层次结构和镜像解密关系，如图1所示。

其中根密钥源于OTP，由OEM负责生成和烧录。

图 1 安全启动模式解密关系图

启动镜像制作及烧写

SS928V100支持多种启动方案，启动镜像的制作和烧写步骤需要与启动方案相配套。此外，SS928V100的OTP控制着启动方案选择、镜像合法性校验、版本校验等启动流程，要根据启动方案来进行配置和烧写。

本章阐述了SS928V100镜像制作步骤、OTP烧写步骤、镜像烧写方法，以及给出了环境变量配置参考值。

开始操作前，需要明确的以下内容：

  • 使用哪种启动方案？启动方案的介绍请参考“启动方案”；

  • 是否需要双签名（Third_party对镜像签名）功能，相关介绍请参考“SoC安全启动公钥框架”。

启动镜像制作步骤

快速启动方案的镜像制作方法与传统的启动方案相同；若要制作非安全启动和安全启动的启动镜像，则需要借助“image_map”镜像制作脚本。本节将阐述SS928V100各启动方案的镜像制作步骤。

快速启动

使用快速启动方案，需要制作以下镜像：

  • U-Boot镜像

  • ATF+Kernel镜像

  • 文件系统镜像

镜像的编译和制作方法可参考“osdrv/readme_cn.txt”。

非安全启动

使用非安全启动方案，需要制作以下镜像：

  • ATF+Kernel镜像

  • 文件系统镜像

  • Boot image

镜像特点以及制作说明如下：

  • ATF+Kernel镜像、文件系统镜像的编译和制作方法可参考“osdrv/readme_cn.txt”。

  • Boot image包含GSL和U-Boot的二进制代码，要用“image_map”镜像制作脚本来制作。

以下是Boot image的具体制作步骤：

  1. 进入osdrv/components/目录，解压boot.tar.gz，得到GSL代码和“image_map”镜像制作脚本。

    tar xf boot.tar.gz

    GSL源码和“image_map”镜像制作脚本分别存放在boot/gsl/目录和boot/image_map/目录。

  2. 编译GSL，得到GSL镜像gsl.bin。

    cd boot/gsl/
make CHIP=ss928v100

    在pub/目录下会生成GSL的二进制镜像gsl.bin。

  3. 进入open_source/u-boot/目录，编译U-Boot得到U-Boot镜像u-boot-ss928v100.bin。

    编译方法请参考“osdrv/readme_cn.txt”。

  4. 将编译好的GSL、U-Boot镜像，以及U-Boot表格拷贝到image_map/目录。

    cp osdrv/components/boot/gsl/pub/gsl.bin osdrv/components/boot/image_map/
cp open_source/u-boot/u-boot-2020.01/u-boot-ss928v100.bin osdrv/components/boot/image_map/u-boot-original.bin
cp open_source/u-boot/u-boot-2020.01/.reg osdrv/components/boot/image_map/.reg

  5. 进入osdrv/components/boot/image_map/目录，制作非安全启动的Boot image。

    cd osdrv/components/boot/image_map/
python oem/oem_quick_build.py

    在image/oem/目录下生成的二进制文件boot_image.bin即非安全启动的Boot image。

安全启动

使用安全启动方案，需要制作以下镜像：

  • ATF+Kernel镜像

  • 文件系统镜像

  • Boot image

镜像特点以及制作说明如下：

  • 安全启动所使用的ATF+Kernel镜像、文件系统镜像与非安全启动相同，编译和制作方法可参考“osdrv/readme_cn.txt”。

  • 安全启动的Boot image不仅包含了GSL镜像和U-Boot镜像，还包含了用于保证Boot image完整性、合法性和机密性的数据，包括非对称秘钥、对称秘钥、MSID和版本号等，这些数据由每个区域的Owner来管理。

  • 在制作Boot image时，各Owner通过Json配置文件将数据传递给镜像制作脚本。

  • 不同的启动场景（例如GSL和U-Boot是否需要加密）依赖的配置项不同，所需配置文件会有差异。为方便使用，镜像制作脚本还提供了根据启动场景生成配置文件的功能。

以下是OEM制作Boot image的步骤：

  1. 编译GSL，得到GSL镜像gsl.bin。

    操作与“非安全启动”步骤1~2相同。

  2. 编译U-Boot，得到U-Boot镜像u-boot-ss928v100.bin。

    操作与“非安全启动”步骤3相同。

  3. 进入osdrv/components/boot/image_map/目录，生成OEM的Json配置文件oem_config.json。

    cd osdrv/components/boot/image_map/
python oem/oem_main.py gencfg oem/oem_config.json

    选项填写方法如下：

    Security Mode: 
0.Non-Secure 
1.Secure 
> 1 
Inpnt:1 
Start Flow: 
0.Non-TEE 
1.TEE 
> 0 
Inpnt:0 
Encrypt GSL Code: 
0.No 
1.YES 
>（填0表示GSL不加密，填1表示GSL加密） 
Encrypt Boot Code: 
0.No 
1.YES
>（填0表示U-Boot不加密，填1表示U-Boot加密）

    完成选项填写后，会生成配置文件oem/oem_config.json。

  4. 填写oem_config.json内未配置的字段（被“/* */”括住，填写时请删除“/* */”）。配置方法请参考《SS928V100/SS927V100安全启动脚本配置说明》文档。其中GSL_Code、Boot_Code字段，应分别填入步骤1和 2生成的gsl.bin和u-boot-ss928v100.bin的路径，Cfg_Param字段填U-Boot表格（步骤2中用于编译U-Boot的.reg文件）的路径。

  5. 制作具有OEM签名的Boot image。

    python oem/oem_main.py build oem/oem_config.json

    在image/oem/目录下的boot_image.bin为安全启动的Boot image。

如果Third_party需要对Boot image签名，须完成以下操作：

  1. 进入osdrv/components/boot/image_map/目录，确认OEM生成的单签名Boot image在image/oem/目录中，命名为“boot_image.bin”。

  2. 生成Third party的Json配置文件third_party_config.json。

    python third_party/third_party_main.py gencfg third_party/third_party_config.json 
Start Flow: 
0.Non-TEE 
1.TEE 
> 0 
Inpnt:0

    完成选项填写后，会生成配置文件third_party/third_party_config.json。

  3. 填写third_party_config.json中未配置的字段（被“/* */”括住，填写时请删除“/* */”）。配置方法请参考《SS928V100/SS927V100安全启动脚本配置说明》文档。

  4. 对Boot image签名。

    python third_party/third_party_main.py build third_party/third_party_config.json

    在image/third_party/目录下的boot_image.bin即为双签名（OEM和Third_party共同签名）的安全启动的Boot image。

OTP配置与烧写

SS928V100支持多种启动方案，芯片采用何种启动方案，需要通过OTP来配置。本节将介绍OTP的配置方法，以及如何利用U-Boot完成OTP烧写。

阅读前，请先了解以下事项：

  • OTP烧写操作无法撤销，不正确的OTP配置与烧写，可能会导致不可修复的启动失败问题，甚至带来安全风险，请谨慎操作。

  • “osdrv/components/boot.tar.gz”压缩包提供了OTP烧写代码示例，路径为“image_map/sample/write_otp_fun.c”，本节将利用此示例来完成OTP的配置与烧写。

  • 本节描述的操作将生成一个的Boot image，用于烧写OTP。请将本节生成Boot image与“启动镜像制作步骤”生成的Boot image做出区分。

以下是OTP配置、烧写的具体操作步骤：

  1. 进入osdrv/components/目录，创建用于制作Boot image的目录“boot-otp”

    cd osdrv/components/ 
mkdir boot-otp/ 
tar xf boot.tar.gz --strip-components=1 -C boot-otp/

  2. 进入open_source/u-boot/目录，创建用于编译U-Boot的目录“u-boot-otp”，并将osdrv/components/boot-otp/ image_map/sample/write_otp_fun.c拷贝到open_source/u-boot/u-boot-otp/cmd/目录。

    cd open_source/u-boot/ 
mkdir u-boot-otp/ 
tar xf u-boot-2020.01.tar.bz2 --strip-components=1 -C u-boot-otp/ 
cd u-boot-otp/ 
patch -p1 < ../u-boot-2020.01.patch
cp ../../../osdrv/components/boot-otp/image_map/sample/write_otp_fun.c ./cmd/

  3. 在./cmd/write_otp_fun.c文件中的g_otp_startup_burn_fields数组内配置要烧写的OTP字段。表1给定了不同启动方案下需配置的OTP字段，以及配置参考。其中“√”表示字段需配置，无“√”表示字段配置无效。请查阅《安全子系统使用说明》来确定各OTP字段值，然后在g_otp_startup_burn_fields数组内按需取消OTP字段的注释，填入字段的值（以“0x”开头的十六进字符串）。

    表 1 启动方案需配置的OTP

    字段名称

    快速启动

    非安全启动

    安全启动

    配置参考值和注意事项

    quick_boot

    √

    √

    √

    0x5：快速启动；

    0xF：非安全启动和安全启动。

    secure_boot_en

    -

    √

    √

    0x42：非安全启动；

    0xFF：安全启动。

    安全启动使能前，可利用镜像中的SCS_simulate_flag标志位来模拟secure_boot_en使能情况下对Boot Flash Mapping 区域的调试，防止OTP烧写不正确，导致芯片出现不可修复的错误。请参考《SS928V100/SS927V100安全启动脚本配置说明》中SCS_simulate_flag标志位的介绍。

    gsl_dec_en

    -

    √

    √

    0xF：GSL解密使能；

    0xA：是否解密GSL取决于镜像中的GSL_Code_Enc_Flag标志。

    《SS928V100/SS927V100安全启动脚本配置说明》介绍了GSL_Code_Enc_Flag的配置方法。仅当gsl_dec_en 配置为0xA，且GSL_Code_Enc_Flag配置为0x3C7896E1时，GSL不解密。

    bload_dec_en

    -

    √

    √

    0x1：U-Boot解密使能；

    0x0：是否解密U-Boot取决于镜像中的Boot_Enc_Flag标志。

    《SS928V100/SS927V100安全启动脚本配置说明》介绍了Boot_Enc_Flag的配置方法。仅当bload_dec_en配置为0x0，且Boot_Enc_Flag配置为0x3C7896E1时，U-Boot不解密。

    uboot_redundance

    -

    -

    √

    0x0：不使能Boot Image备份。

    0x1：使能Boot Image备份；

    oem_rk_deob_en

    -

    -

    √

    字段值与《SS928V100/SS927V100安全启动脚本配置说明》KDFTool工具所使用的oem_rk_deob_en值保持一致即可。若不一致，安全启动失败。

    oem_root_public_key_sha256

    -

    -

    √

    填写OEM_Root_Public_Key Area的SHA256校验值（相关原理请参考“OEM_Root_Public_Key Area”）。OEM在制作Boot image后，可从文件“osdrv/components/boot/image_map/oem/tmp/oem_root_public_key_area_checksum.txt”中获取该值。

    oem_root_symc_key0

    -

    -

    √

    该字段即“芯片密钥派生”中描述的OTP KEY，属于敏感信息，不可外泄。字段值与《SS928V100/SS927V100安全启动脚本配置说明》KDFTool工具所使用的oem_root_symc_key字段保持一致，且不能为全零，否则安全启动失败。

    oem_root_symc_key0_flag

    -

    -

    √

    oem_root_symc_key0的控制标志，填入0x00000000。

    oem_msid

    -

    -

    √

    OEM客户细分市场标识（ID），若与《SS928V100/SS927V100安全启动脚本配置说明》中的OEM_MSID_Ext不匹配，安全启动失败。

    oem_version

    -

    -

    √

    OEM版本号，字段中Bit 1的数量表示版本号，用于Boot Image防回滚。若《SS928V100/SS927V100安全启动脚本配置说明》中OEM_Version_Ext表示的版本号小于此字段表示的版本号，安全启动失败。

    double_sign_en

    -

    √

    √

    0xA：不使能双签名；

    0xF：使能双签名。

    使能双签名功能后，Third_party必须对启动镜像签名。Third_party的双签名操作在“安全启动”中有描述。

    tp_root_public_key_sha256

    -

    -

    √

    该字段与双签相关，仅double_sign_en使能时有效，填入Third_party_Root_Public_Key Area的SHA256校验值（相关原理请参考“Third_party_Root_Public_Key Area”）。Third_party在对Boot image双签名后，可从文件“osdrv/components/boot/image_map/third_party/ tmp/third_party_root_public_key_area_checksum.txt”中获取该值。

    third_party_msid

    -

    -

    √

    该字段与双签相关，仅double_sign_en使能时有效，表示为第三方细分市场标识（ID）。若与《SS928V100/SS927V100安全启动脚本配置说明》中的Third_party_MSID_Ext不匹配，安全启动失败。

    third_party_version

    -

    -

    √

    该字段与双签相关，仅double_sign_en使能时有效，字段中Bit 1的数量表示第三方版本号，用于Boot Image防回滚。若《SS928V100/SS927V100安全启动脚本配置说明》中Third_party_Version_Ext表示的版本号小于此字段所表示的版本号，安全启动失败。

  4. 在./cmd/Makefile文件中添加以下内容，以增加OTP烧写命令编译项。

    obj-y += write_otp_fun.o

  5. 在./include/configs/ss928v100.h文件添加以下宏定义，使能OTP驱动。

    #define CONFIG_OTP_ENABLE

  6. 编译带有OTP烧写命令的U-Boot。

    编译U-Boot前，需要用Windows系统进入osdrv/tools/pc/uboot_tools/目录，打开对应单板的Excel文件，选择main标签，点击“Generate reg bin file”按钮，生成对应平台的U-Boot表格文件reg_info.bin。然后回到Linux系统执行操作：

    cp configs/ss928v100_defconfig .config 
make ARCH=arm CROSS_COMPILE=aarch64-v01c01-linux-gnu- menuconfig 
make ARCH=arm CROSS_COMPILE=aarch64-v01c01-linux-gnu- -j 20 
cp ../../../osdrv/tools/pc/uboot_tools/reg_info.bin .reg 
make ARCH=arm CROSS_COMPILE=aarch64-v01c01-linux-gnu- u-boot-z.bin

    以上操作以SPI NOR/ NAND启动介质为例，如果启动介质为eMMC，则上述操作中的配置文件“configs/ss928v100_defconfig”改为“ss928v100_emmc_defconfig”。

  7. 检验 OTP 配置值（可选步骤）。

    进入osdrv/components/boot-otp/image_map/目录，打开 oem/otp_check.json，填充“步骤3”设置的 OTP 值，然后执行命令：

    # 获取 KDF 工具
cp ../../../tools/pc/kdf_customer/parameter.bin ./
tar xf ../../../tools/pc/kdf_customer/KDFTools_V1.0.3.tar.gz --strip-components=1
# 验证 OTP 配置值（以下命令根据启动场景二选一）
# 安全启动
python3 oem/oem_main.py check oem/otp_check.json <Boot Image路径>

    命令中的 “<Boot Image路径>”请用“启动镜像制作步骤”生成实际镜像路径替换。

    打印“Boot Image is OK.”表示 Boot Image 的OTP 配置值校验通过；执行报错表示 OTP 配置值有误。

  8. 进入osdrv/components/boot-otp/gsl/目录，编译GSL镜像，得到gsl.bin。

    make CHIP=ss928v100

  9. 进入osdrv/components/boot-otp/image_map制作Boot image。

    cp ../../../../open_source/u-boot/u-boot-otp/u-boot-ss928v100.bin ./u-boot-original.bin
cp ../../../../open_source/u-boot/u-boot-otp/.reg ./
cp ../gsl/pub/gsl.bin ./  
python oem/oem_quick_build.py

    image/oem/目录下生成的boot_image.bin具备OTP烧写功能。

  10. 将新的image/oem/boot_image.bin烧写到存储介质。

  11. 烧写完成后，复位进入U-Boot，执行write_otp命令完成OTP烧写。

至此OTP烧写完成，之后可以依照“镜像烧写”中的描述，烧写“启动镜像制作步骤”中制作的启动镜像，并在U-Boot中依照“单板环境变量配置参考”配置环境变量。环境变量配置完成后请复位芯片，检验系统启动是否成功。

须知：

  • 烧入OTP的秘钥是敏感信息，必须保密。该示例代码只能用于烧写OTP，正式发布时，一定要把U-Boot中用于烧写OTP的write_otp_fun.c文件删除，否则会有密钥泄漏风险。

  • 另强烈建议客户在最终产品发布前，将所有的特性/功能开关位对应的值设置好，并且强制锁定！即使默认值满足要求，也要求锁定。

  • 烧写OTP后，OTP值在芯片断电后才生效，或者通过U-Boot中dog_reset命令使其生效，其通过芯片软复位的形式不会生效。

  • 镜像结构内Unchecked Area for Vendor 区域 SCS_simulate_flag 标志可在安全启动未使能的情况下进行安全启动调试。

镜像烧写

本节以SPI NOR存储介质为例，介绍如何使用ToolPlatform工具烧写启动镜像。

选用其它存储介质（SPI NAND、eMMC）时，文件系统的类型和烧写长度与SPI NOR不同，其余镜像的大小和烧写布局与SPI NOR相同。

快速启动

快速启动的镜像烧写布局如图1所示。

图 1 快速启动ToolPlatform烧写分区参考图

非安全启动和Non-TEE安全启动

镜像烧写布局如图1所示。

图 1 ToolPlatform烧写分区参考图

须知： 图1和图1中烧写的uImage_ss928v100文件是ATF+Kernel镜像。

单板环境变量配置参考

本节基于“镜像烧写”的镜像布局，提供SPI NOR、SPI NAND和eMMC作为启动介质时的环境变量配置示例。

  • SPI NOR

    setenv bootargs 'mem=128M console=ttyAMA0,115200 root=/dev/mtdblock2 rw rootfstype=jffs2 mtdparts=sfc:1M(boot),12M(kernel),18M(rootfs)';sa  setenv bootcmd 'sf probe 0;sf read 0x42000000 0x100000 0xc00000;bootm 0x42000000';sa

  • SPI NAND和并口NAND

    setenv bootargs 'mem=128M console=ttyAMA0,115200 clk_ignore_unused ubi.mtd=2 root=ubi0:ubifs rootfstype=ubifs rw mtdparts=nand:1M(boot),12M(kernel),32M(rootfs.ubifs)';sa   setenv bootcmd 'nand read 0x42000000 0x100000 0xc00000;bootm 0x42000000';sa

  • eMMC

    setenv bootargs 'mem=128M console=ttyAMA0,115200 clk_ignore_unused rw rootwait root=/dev/mmcblk0p3 rootfstype=ext4 blkdevparts=mmcblk0:1M(boot),12M(kernel),96M(rootfs)';sa  setenv bootcmd 'mmc read 0 0x42000000 0x800 0x6000; bootm 0x42000000';sa

安全 Boot 镜像备份功能

如需使用安全 Boot 镜像备份功能，请先烧写 OTP 的“uboot_redundance”字段（详见“OTP配置与烧写”章节）。

烧写的备份 Boot Image 起始地址要求64K对齐且位于存储介质前1MB以内。当主 Boot Image 校验失败，引导程序会从启动介质搜寻可用的备份 Boot Image，并引导启动。

注意： 当存储介质为NAND Flash时，请勿擦除介质的首个Block，否则有备份失败的风险。

内核及文件系统安全启动验签方案参考

该参考方案是基于上述安全启动方案的特性，在U-Boot验签通过后，再通过在U-Boot上实现验签内核的功能。前一阶段系统引导下一阶段系统前，先对待启动系统进行验签，如果验签成功，再启动Linux系统，否则系统启动失败。验签机制可以保证系统镜像的完整性，如果镜像被篡改或损坏，系统将不会被启动。

安全启动流程

本文中描述的只涉及BOOTROM验签后启动U-Boot，U-Boot验签后启动Kernel，如图1所示。其它文件系统等的验签流程，以及相关数据加解密保护可参照这种模式进行设计开发，本文不进行说明。

方案在制作非安全的U-Boot原始镜像先使其镜像大小16字节对齐，对齐之后再往Boot原始镜像上追加内核的安全验签公钥Key的信息等信息至镜像尾部，再通过“启动镜像制作步骤”对追加信息后U-Boot生成新的安全启动镜像。

图 1 内核及文件系统启动验签流程框图

安全启动验签流程涉及的哈希值计算、非对称RSA加解密，请自行查询相关资料，本文不再进行说明。如果需要进一步开发加解密功能，可了解其它加密算法，例如对称AES加密算法。

附验证信息U-Boot镜像结构

附验证信息的U-Boot镜像结构如图1所示。在U-Boot镜像尾部追加Kernel相关安全信息，再将带Kernel验证信息的U-Boot镜像制作成安全启动镜像。

图 1 附验证信息U-Boot镜像结构

安全Kernel镜像结构

安全Kernel镜像由头部信息、Kernel镜像和签名信息等组成，如图1所示。在原有Kernel镜像结构进行拼接，其中Kernel镜像为压缩镜像。Kernel验签使用的RSA公钥信息保存在U-Boot原始镜像中，随安全镜像一起整合成安全启动镜像。

图 1 安全Kernel镜像结构图

功能实现

U-Boot验签Kernel部分功能实现请参考《CIPHER API 参考》文档内 RSA签名及验签使用流程章节调用相应API接口实现。

U-Boot表格增大后代码方案参考

注意： 本方法只适用于非安全启动和安全启动，对快速启动无效。 且修改须保证 gsl.bin大小（对应镜像GSL_Code_Area_Len）+ U-Boot 表格大小（16字节对齐） < 70.76KB大小。

目的

将U-Boot表格大小限制，从10.77KB（0x2B10字节）增至16.00KB（0x4000字节）。

方法

  1. 修改gsl/include/flash_map.h

    #define CFG_PARAM_SIZE 0x2B10

    修改为：

    #define CFG_PARAM_SIZE 0x4000

  2. 修改image_map/common/area_tool.py

    class AreaCfg:
CFG_PARAM_SIZE = 0x2B10     # reg table size

    修改为

    class AreaCfg:
CFG_PARAM_SIZE = 0x4000     # reg table size..

错误码列表

表 1 错误码列表

错误码

含义

E4D1

PCIe 从启动获取数据失败

E4D2

从 UART 下载数据失败

E4D3

从 SD 卡获取数据失败

E4D4

从 USB 下载数据失败

E4D5

从 Flash 获取备份失败

E4D6

从 Flash 获取数据失败

E4D7

从 eMMC 获取备份失败

E4D8

从 eMMC 获取数据失败

E6Dx

GSL_Third_party_Key Area 校验失败

E7Dx

GSL_Key_Area 校验失败

E8D1

从 Flash 获取 GSL Code Area 失败

E8D2

从 EMMC 获取 GSL Code Area 失败

E8D3

E9Dx

GSL_Code_Area 校验失败

G4S1

PCIe 从启动获取数据失败

G4S2

从 UART 下载数据失败

G4S3

从 SD 卡获取数据失败

G4S4

从 USB 下载数据失败

G4S5

从 Flash 获取数据失败

G4S7

G4S6

从 eMMC 获取数据失败

G4S8

G4S9

G4Sa

G4Sb

G5Sx

Boot Key Area 校验失败

G6Sx

Boot Params Area 校验失败

G8s1

PCIe 从启动获取数据失败

G8s2

从 UART 下载数据失败

G8s3

从 SD 卡获取数据失败

G8s4

从 USB 下载数据失败

G8s5

从 Flash 获取数据失败

G8s6

从 eMMC 获取数据失败

G8s7

G8s8

G8s9

G9Sx

Boot Area 校验失败

说明： 错误码表中，“x”替代任意数字，例如“G5Sx”指代 “G5S1”、“G5S2”、“G5S3”…

缩略语

A

AES

Advanced Encryption Standard

ATF

Arm Trust Firmware

C

CPU

Central Processing Unit

G

GSL

Secure Bootloader

J

JTAG

Joint Test Action Group

K

KeyLadder

A structured multi-level key mechanism that ensures secure transmission of control words.

M

MCipher

Multi-channel Cipher module

MSID

MarketSegmentID.

O

OS

Operating System

OEM

Original Equipment Manufacturer

OTP

One Time Programmable

R

REE

Rich Execution Environment

RKP

Root Key Process

S

SCS

Secure Chipset Startup

SMC

Secure Monitor Call