1. 项目概述与核心价值

在物联网设备开发中，安全启动和固件认证是构建产品信任基石的起点。想象一下，你生产的智能门锁、工业传感器或医疗设备，如果启动时加载的代码可以被任意替换，后果将不堪设想。德州仪器（TI）的SimpleLink Wi-Fi系列芯片（如CC3220S/SF, CC3235S/SF）提供了一套基于硬件的多层安全机制，其中最关键的一环就是供应商设备认证。这不仅仅是“把代码锁起来”，而是建立一套从芯片出厂到设备报废全生命周期的、可验证的信任链。

这套机制的核心，是允许设备制造商（即供应商）摆脱对TI预设信任根的依赖，建立自己的“数字王国”。你可以用自己的根证书（Root CA）来签名你的应用程序、服务包甚至整个证书目录，并将这个根证书的公钥“熔断”到芯片的一次性可编程（OTP）存储器中。一旦写入，无法更改，这就将你的信任根与具体的硬件芯片进行了物理绑定。任何试图在设备上运行的、未经你私钥签名的代码，都会被芯片在启动阶段无情拒绝。这对于防止供应链攻击、克隆设备以及确保固件升级的合法性至关重要。

我经历过不止一个项目，早期为了赶进度跳过了安全启动配置，结果在量产阶段遇到了固件被恶意替换的风险，不得不全部返工，代价巨大。因此，无论你的产品目前对安全的需求看似高低，我都强烈建议在项目初期就理解和部署这套供应商认证流程。它不仅仅是TI提供的一个“可选功能”，而是现代物联网设备，尤其是那些涉及用户数据、关键控制或联网功能的设备，所应具备的“出厂标配”。

2. 核心概念与架构深度解析

在深入实操之前，我们必须把几个核心概念和它们之间的关系彻底理清。很多开发者卡在配置步骤上，根本原因是对底层逻辑一知半解。

2.1 信任链的构建：从TI到供应商的权杖交接

默认情况下，SimpleLink设备启动时，其网络处理器（NWP）的ROM中固化了TI的根证书公钥。所有TI官方的服务包（Service Pack）和系统文件都使用对应的私钥签名。设备上电后，Bootloader会用TI的公钥去验证这些文件的签名，确保它们来自TI且未被篡改。这构成了最基础的信任链，其“信任根”是TI。

供应商认证的本质，就是进行一次“信任根交接”。你将一个属于你自己的RSA公钥（对应你的根证书）写入OTP区域。从此，设备Bootloader在验证某些关键文件（特别是你的应用程序和供应商证书目录）时，将转而使用你的公钥。TI的信任根依然存在，并继续用于验证TI自身的服务包，但对你自定义内容的验证权，已经移交到你手中。

2.2 核心组件三位一体：OTP、证书目录与签名

整个供应商认证体系依赖于三个核心文件的协同工作，理解它们的关系是成功配置的关键：

1. OTP信息文件（.inf）：这是最终要烧录到芯片OTP存储区的二进制文件。它不单单包含你的公钥，而是一个结构化的数据块，其中核心是“OTP元数据”和对其的“数字签名”。元数据包含了你的公钥、设备MAC地址等信息。签名则用你的私钥对元数据生成，用于在设备端验证元数据本身的完整性和真实性。你可以把OTP文件想象成一块不可篡改的“数字基石”，上面刻着你的公章（公钥）和一段自述（元数据），并且这段自述盖有你的骑缝章（签名）来防伪。

2. 供应商证书目录：这是一个经过签名的列表文件，里面包含了你信任的所有根证书（CA Certificates）。你的应用程序在建立TLS连接（例如连接你的云服务器）时，需要用这里面的证书来验证服务器身份。更重要的是，你的应用程序镜像文件本身，也需要由这个目录中的某个证书链（或你的根证书直接）签名，设备才会执行它。证书目录就像你公司的“合作伙伴白名单”或“内部公章使用授权书”，它定义了哪些证书有资格在你的设备上“办事”。

3. 私钥：这是整个安全体系的命脉，必须离线妥善保管。它用于：

   • 签名你的应用程序。
   • 签名你的供应商证书目录。
   • 签名OTP元数据文件。私钥绝不能出现在任何可能分发给终端用户或生产线的文件中。它的泄露意味着攻击者可以伪造任何你的设备信任的软件。

它们三者的关系如下图所示（概念性流程）：

[你的根证书私钥] | | 用于签名 ↓ [供应商证书目录] + [你的应用程序] + [OTP元数据] | | | | | | 打包并签名 | ↓ ↓ | [签名的应用镜像] [OTP信息文件(.inf)] | | | ↓ ↓ ↓ 烧录到设备文件系统 ----> 设备启动时验证 ----> 烧录到芯片OTP

设备启动时，Bootloader首先用OTP中的公钥验证证书目录的签名，再用证书目录中的证书（或直接用OTP公钥）验证应用程序的签名。环环相扣，缺一不可。

2.3 基础认证流程与定制认证流程的对比

官方文档中提到了两种流程，这里我用更直白的语言解释其区别：

• 基础认证流程：设备完全信任TI。你的应用程序和文件如果需要签名，必须使用TI证书目录中已有的CA颁发的证书。这相当于你开发的应用需要找TI认可的“公证处”盖章才能运行。灵活性低，但配置简单。
• 定制认证流程（即本文核心）：设备信任你（供应商）。你用自己生成的根证书（或自己信任的CA）建立证书目录，并签名你的应用。OTP中存储你的公钥。TI的服务包仍由TI的流程验证，但你的应用生态完全由你掌控。这是实现设备品牌化安全和独立安全策略的唯一途径。

3. OTP详解：硬件信任根的熔断与配置

OTP是一次性可编程存储器，顾名思义，每个比特位只能从1编程为0一次（或初始为0，编程为1，取决于工艺），之后不可逆转。在CC32xx芯片中，用于供应商认证的OTP块大小为1008字节，其结构布局是理解后续命令参数的关键。

3.1 OTP内存布局拆解

根据文档，OTP块包含以下部分，我将其重新梳理并加入解读：

3.2 生成OTP文件的三步实操命令

生成最终的.inf文件需要三个步骤，必须在UniFlash的ImageCreator安装目录下的命令行中执行。假设你的工具安装在C:\ti\uniflash，你的证书和密钥放在C:\secure\vendor_certs。

步骤一：创建元数据（.meta）文件此步骤提取公钥并与MAC地址等信息打包。

SLImageCreator.exe tools meta --cert "C:\secure\vendor_certs\vendor_root-ca.pem" --out_file "C:\secure\otp\vendor_otp.meta" --mac "000000000000"

• --cert: 指定你的PEM格式的根证书文件（包含公钥）。
• --mac: 如上所述，000000000000表示通用文件。量产绑定设备时，此处需传入从芯片读取的真实MAC。
• --usechain: 如果使用，则要求提供OTP RSA签名2（当前版本通常不用）。

步骤二：签名元数据文件用你的私钥对刚生成的.meta文件进行签名，生成.sig文件。

SLImageCreator.exe tools sign --file "C:\secure\otp\vendor_otp.meta" --priv "C:\secure\vendor_certs\vendor_private_key.pem" --out_file "C:\secure\otp\vendor_otp.meta.sig" --fmt "BINARY_SHA2"

• --fmt: 签名算法格式。这是关键选择！CC3220系列使用BINARY_SHA1，CC3235系列使用BINARY_SHA2。用错会导致验证失败。

步骤三：生成OTP信息（.inf）文件将元数据文件和其签名打包成最终的OTP二进制文件。

SLImageCreator.exe tools inf --algo 2 --sign1 "C:\secure\otp\vendor_otp.meta.sig" --meta "C:\secure\otp\vendor_otp.meta" --out_file "C:\secure\otp\vendor_otp.inf"

• --algo: 必须与上一步的--fmt对应。1对应BINARY_SHA1，2对应BINARY_SHA2。
• --sign1: 指定第一步生成的签名文件。
• --sign2: 如需OTP RSA签名2则指定（当前通常留空或指向同一文件，但文档指出不支持）。

至此，vendor_otp.inf文件已准备就绪，可用于烧录。

实操心得：OTP烧录的“一次性”陷阱OTP的“一次性”特性意味着测试阶段必须极其谨慎。绝对不要在第一批样品芯片上直接烧录最终的、带特定MAC地址的OTP文件。建议：

1. 开发阶段：始终使用MAC为000000000000的通用OTP文件进行测试。这样一块开发板报废了，文件还能用于下一块。
2. 小批量试产：使用通用OTP文件或使用编程器先读取芯片MAC再生成对应OTP文件。确保流程万无一失。
3. 大规模量产：与生产方案商紧密合作，通常采用“先烧录序列号/MAC，再读取并实时生成对应OTP文件，最后烧录”的自动化流程。一旦批量烧错，芯片将永久性不可用，损失巨大。

4. 供应商证书目录的创建与管理

证书目录是你的设备所信任的“证书宇宙”。它不仅用于验证你的应用签名，也用于TLS连接时验证服务器证书。

4.1 创建证书目录列表（.lst）

你需要将所有信任的根证书（CA证书）以DER格式放在一个文件夹中。DER格式是二进制的证书编码格式，通常以.der或.cer为后缀（但需确认是DER，而非PEM）。可以使用OpenSSL进行格式转换。

假设你的证书在C:\secure\trusted_cas文件夹内。

SLImageCreator.exe tools make_cert_catalog --cert_folder "C:\secure\trusted_cas" --out_file "C:\secure\catalog\my_cert_catalog.lst"

这个命令会读取文件夹内所有DER格式证书，生成一个列表文件。注意限制：最多支持100个根证书。

4.2 签名证书目录

生成的.lst文件本身是明文，必须经过签名，设备才会信任它。

# 对于CC3220S/SF设备 SLImageCreator.exe tools sign --file "C:\secure\catalog\my_cert_catalog.lst" --priv "C:\secure\vendor_certs\vendor_private_key.pem" --out_file "C:\secure\catalog\my_cert_catalog.lst.signed.bin" --fmt "BINARY_SHA1" # 对于CC3235S/SF设备 SLImageCreator.exe tools sign --file "C:\secure\catalog\my_cert_catalog.lst" --priv "C:\secure\vendor_certs\vendor_private_key.pem" --out_file "C:\secure\catalog\my_cert_catalog.lst.signed.bin" --fmt "BINARY_SHA2"

关键点：这里使用的私钥必须与将来烧录到OTP中的公钥相匹配。同时，签名算法格式（SHA1/SHA2）的选择必须与目标芯片型号严格对应，和之前OTP签名格式的选择逻辑一致。

注意事项：证书链的完整性你的应用程序在签名时，所使用的证书链必须能够被这个证书目录验证。例如，如果你用了一个由中间CA颁发的证书来签名应用，那么你的证书目录中必须包含签发该中间CA的根CA证书，或者直接包含该中间CA证书（如果目录支持中间CA，需确认）。最稳妥的方式是，直接用你的根证书（其公钥在OTP中）来签名应用，这样证书目录中只需要有根证书自身（或不需要额外证书，因为OTP公钥已是信任根）。在复杂PKI体系下，务必在测试阶段充分验证签名和验证链。

5. 集成与烧录：UniFlash ImageCreator实战

所有文件准备好后，需要在UniFlash ImageCreator工具中将其集成为一个可烧录的镜像或OTA升级包。

5.1 初始工程配置与OTP烧录

1. 创建或打开工程：启动UniFlash ImageCreator，创建一个新工程或打开现有工程。务必添加当前设备所需的服务包（Service Pack）文件，这是网络处理器运行的基础。
2. 切换到高级视图：在界面中找到并切换到“Advanced”视图。这是启用供应商认证功能的入口。
3. 配置供应商证书目录：
   • 找到“Trusted Root-Certificate Catalog”或类似选项。
   • 将“Catalog File”指向你生成的my_cert_catalog.lst。
   • 将“Signed Catalog File”指向你生成的my_cert_catalog.lst.signed.bin。
4. 启用供应商证书目录：勾选“Use Vendor Certificate Catalog”或类似的复选框。这告诉工具，在构建镜像时使用你提供的证书目录，而非TI默认的。
5. 添加OTP文件：勾选“Add OTP file”选项，然后浏览并选择你之前生成的vendor_otp.inf文件。
6. 生成并烧录镜像：配置好其他应用文件后，点击生成镜像并烧录到设备。此步骤会将OTP文件一次性写入芯片的OTP区域，之后无法修改。

5.2 生成带认证的OTA升级包

产品上市后，固件升级必须同样遵循安全认证。使用供应商认证后，OTA升级包的生成略有不同。

1. 准备工程：与上述步骤类似，在ImageCreator中创建一个用于OTA的工程，包含新的服务包（如果需要升级）、新的应用程序镜像（已用你的私钥签名）以及新的证书目录文件（如果需要更新）。
2. 关键配置：
   • 确保“Use Vendor Certificate Catalog”已启用。
   • 不要再次勾选“Add OTP file”。OTA升级不能也不应该再次烧录OTP。
   • 在“Advanced”视图中，确保所有配置正确。
3. 创建OTA Bundle：
   • 点击“Burn”选项，选择“Create OTA”。
   • 在弹出的对话框中，切勿勾选“Certificate catalog OTA bundle only”，除非你只想单独升级证书目录。
   • 在“Private Key”字段中，选择用于签名本次OTA bundle中应用程序镜像的私钥文件（.pem格式）。这个私钥必须能被设备当前信任的证书链所验证（即，要么是OTP中的根私钥，要么是由证书目录中CA颁发的证书对应的私钥）。
   • 点击“Create OTA”，工具会生成一个.bin文件，这个文件包含了所有内容，并用你指定的私钥进行了整体签名。

5.3 仅更新证书目录的OTA

在某些场景下，你可能需要更新设备信任的CA列表，而不更新应用。

1. 在OTA创建对话框中，勾选“Certificate catalog OTA bundle only”。
2. 选择用于签名新证书目录的私钥（同样，必须与设备当前OTP中的公钥或现有信任链匹配）。
3. 生成OTA包。设备收到后，会验证签名，并用新的证书目录替换旧的。

重要限制与实操陷阱文档中明确提到：一旦OTP被编程，将禁止对证书目录和服务包进行降级。这意味着：

• 证书目录版本号必须递增。你需要在证书目录的元数据中管理版本号，确保每次OTA的版本都比设备当前的高。
• 服务包版本不能降级。如果你给设备升级了新的服务包，以后不能再推送一个旧版本的服务包。TI的签名机制会阻止这种行为。
• 签名密钥必须一致。OTA Bundle的签名私钥必须有效，且设备能验证。如果OTP中的公钥丢失或错误，设备将拒绝任何OTA更新，可能变砖。因此，备份和安全管理你的根私钥是最高优先级。

6. 常见问题排查与调试经验实录

即使按照指南操作，在实际部署中依然会遇到各种问题。下面是我在多个项目中总结的典型问题及其排查思路。

6.1 设备启动失败，无法进入应用

• 症状：程序烧录后，设备重启卡住，串口无应用输出或提示认证失败。
• 排查步骤：
  1. 检查OTP烧录是否成功：使用UniFlash或调试命令读取OTP区域（如果支持），确认公钥已正确写入，且MAC地址字段符合预期（非全零则需匹配设备MAC）。
  2. 验证证书目录签名：确认.lst.signed.bin文件是使用正确的私钥（对应OTP公钥）和正确的哈希算法（SHA1/SHA2）签名的。可以用SLImageCreator.exe tools verify命令（如果提供）或编写小脚本用公钥验证签名。
  3. 检查应用签名：确认你的应用程序镜像（.bin）是否使用了正确的证书链进行签名，并且该链的根证书存在于你提供的证书目录中（或是OTP中的公钥本身）。使用openssl命令可以验证签名。
  4. 检查服务包兼容性：确认使用的服务包版本符合文档的“Minimum Requirements”。不兼容的服务包可能导致认证流程异常。

6.2 OTA升级失败，设备拒绝新固件

• 症状：OTA服务器推送升级包后，设备下载完成但验证失败，回滚到旧版本。
• 排查步骤：
  1. 确认OTA Bundle签名：用于签名OTA bundle的私钥必须有效。检查生成OTA时选择的私钥文件是否正确，且未被损坏。
  2. 检查版本号：确认新固件（或证书目录）的版本号高于设备当前版本。降级保护机制会阻止安装。
  3. 分析设备日志：如果设备端有安全相关的日志输出，查看具体的错误码。可能是签名无效、证书过期、证书链不完整等。
  4. 网络传输完整性：确保OTA包在传输过程中没有损坏。可以在服务器端计算OTA包的哈希值，与设备端下载后计算的哈希值进行对比。

6.3 如何管理多型号/多批次产品的密钥和证书

这是量产时面临的实际挑战。

• 策略一：统一根密钥：所有产品线使用同一个根CA证书和私钥。优点是管理简单，OTP文件通用（MAC设为全零）。缺点是“一把钥匙开所有锁”，一旦该私钥泄露，所有设备都面临风险。
• 策略二：型号/批次细分：为不同产品型号或生产批次生成不同的根证书。每个型号有自己对应的OTP文件和证书目录。安全性更高，但物料管理（需匹配烧录）和密钥管理更复杂。
• 推荐混合策略：使用一个顶级根CA，为不同产品线签发中间CA证书。将中间CA证书的公钥放入OTP，并将顶级根CA证书放入证书目录。这样可以在平衡安全和管理复杂度。但需彻底测试SimpleLink设备对复杂证书链的支持情况。

6.4 调试工具与技巧

• UniFlash命令行工具：除了GUI，多使用命令行工具执行sign,verify,meta等操作，便于集成到CI/CD流水线中自动化构建。
• 串口调试信息：在开发初期，确保应用程序能输出详细的启动和认证日志到串口。TI的SDK中通常有相关示例和API可以获取安全启动的状态信息。
• 备份与回滚计划：在进行任何OTP或关键安全更新前，务必有完整的备份和软件回滚方案。例如，保留一个已知良好的、未启用供应商认证的“安全模式”引导程序，在紧急情况下可以通过物理接口（如JTAG）恢复。

供应商证书认证与OTP配置是SimpleLink平台提供的一项强大而严肃的安全功能。它要求开发者对公钥基础设施有清晰的认识，并在开发、测试和生产各环节建立严谨的流程。投入时间理解其原理并正确实施，将为你的物联网产品构建起一道坚固的硬件级安全防线，有效抵御固件篡改、克隆和未经授权的软件更新等威胁。这个过程虽然初期有学习成本，但却是打造可靠、可信产品的必经之路。